AWS Outposts のすゝめ（導入編）

花岡大輔 - 2023 APN AWS Top Engineer

はじめに

こんにちは、NRIでAWS（Amazon Web Services）の活用・導入推進を担当している花岡です。

私が現在担当しているプロジェクトにて、AWS Outposts （以降Outposts ）をデータセンター（以降 DC ）に導入する機会がありました。
本記事では、Outposts を実際に導入した際の流れやポイントをご紹介します。

Outposts とは？

Outposts は利用者が指定した DC でAWS サービスを稼働することが出来るサービスです。
以下のような特徴を持っています。

同じ DC 内のオンプレミスネットワークとOutposts 上のリソースとの低レイテンシー通信
データレジデンシーが必要なワークロードへの対応
AWS マネジメントコンソールを使ったハイブリッド環境の統合管理

Outposts の利用を申し込むとハードウェアが指定の住所に届き、電源やネットワークを接続することで利用できるようになります。Outposts にはラックマウント型サーバーが利用できる「AWS Outposts サーバー」と、ラック丸ごと届く「AWS Outposts ラック」の２種類があります。ここでは「AWS Outposts ラック」について取り上げます。

Outposts ラック導入の流れとポイント

Outposts ラック導入の流れは以下の通りです。

各Stepに沿って、簡単に解説します。

Step1 導入検討・計画

このステップでは、どういったOutposts ラック構成を、どのセンターに配置して、どういったワークロードを、いつから動かしたいか、こういったことを決めていきます。
検討開始にあたり、AWS の担当営業の方に相談するとOutposts スペシャリストをアサインしてもらえます。以降は基本的にOutposts スペシャリストと密に連携をとって進めていくことになります。

【ポイント①　Outposts 検討に必要なスキルセットを持った人材の確保】

Outposts の導入が以下にスムーズに進むかは、このポイントが非常に重要です。
Outposts は通常のAWS サービスと異なり、ネットワークとDCファシリティに対して要件が設定されています。※Outposts ラックのサイト要件 - AWS Outposts (amazon.com)
要件通りに環境を準備できるか確認・設計が必要になってくるため、有識者をプロジェクトに含めることをお勧めします。

【ポイント②　SKUの決定】

Outposts ラックには、コンピュートリソース、ディスクリソース、S3リソースを搭載できます。コンピュートリソースはEC2やRDSのインスタンスが稼働し、ディスクリソースはEBSディスク、S3リソースはS3オブジェクトやEBSスナップショットなどが保存できます。
ディスクリソース、S3リソースは利用する分確保すればよいのですが、コンピュートリソースのタイプと数量の選択には、EC2 Auto Recovery等の高可用性機能を利用するための余剰リソースを考慮しておく必要があります。
※ご参考：AWS Outposts でのキャパシティ管理戦略 | Amazon Web Services ブログ
稼働予定ワークロードの構成だけでなく可用性要件に注意して、Outposts 構成を決定しましょう。

【ポイント③　利用開始までのリードタイム】

通常、AWS 上で環境構築する場合、リードタイムは課題になるケースは少ないですが、Outposts は専用ハードウェアの準備があるため、従来のオンプレミスと同様の考え方が必要です。（利用開始まで３か月程度。構成によっては長くなる。）
ポイント②でSKUが決まり次第、利用開始時期感の確認を進めましょう。
また、ここで確認取れたスケジュールはすべてが順調に進んだ場合です。遅れてもよいようにある程度のバッファを持つことが重要になります。

Step2 発注

Step1で決めた内容に沿ってOutposts の発注を行います。発注操作は、AWS マネジメントコンソールで実施できます。
なかなか操作する機会がないオペレーションですので、きちんと記録を取りましょう。
※私はプロジェクトメンバーを集めて操作しました。

Step3 バリデーション

Outposts 導入に向けて課題がないか、ファシリティ観点のチェック（Site Validation）とネットワーク観点のチェック（Network Validation）を実施する必要があります。AWS のOutposts 担当者が、設置予定場所にオンサイトし、チェックが行われます。
私が同行したSite Validationでは搬入経路の通路の幅や高さ・段差などに問題ないか、電源ケーブル・ネットワークケーブルの取り回しの確認など、物理的な確認をされました。

【ポイント④　ネットワーク経路の先行構築】

Network Validationにおいては、Outposts とAWS の DC が接続出来ることを想定したチェックが行われます。設置予定の DC からAWS のOutposts エンドポイントまでのネットワーク経路構築が事前に必要になります。ネットワーク機器などの準備が必要なケースもあると思いますので、計画の早い段階で必要な対応内容や実現可能なスケジュールを整理しましょう。

Step4 設置

利用開始までに必要な最後のオンサイト作業です。
事前に取り決めた日時に、Outposts が設置場所の DC に運ばれてきます。Site Validationで確認した通りに搬入・設置を行い、ネットワークケーブルと電源ケーブルの接続を行い、電源を投入します。あとはAWS のOutposts エンドポイントと DC に設置したOutposts が通信を行うことが出来れば作業完了です。（通信可否はNetwork Validationで確認済み）

ちなみに、Outposts はバラバラの部品ではなく、すでにキッティングが完了したラックが丸ごと到着しました。現地で荷下ろし後、構成部品が輸送中に改ざん改変されていないことのチェックが行われ、問題ないことを確認して設置予定場所に搬入されていきました。
（チェックに合格しなかった場合、搬入されることなくラック丸ごと来たトラックに乗って送り返され、再度キッティングされて再搬送されるそうです。）

Step5 アクティベーション

AWS インフラストラクチャとしてのアクティベーションが行われます。特に実施することはなく待ち時間です。
私が担当した際は一か月ほどでしたが、最近は自動化が進み約2週間程度になっているそうです。

Step6 利用開始

利用予定日に「Order Completion」というメールが届きます。
これに合わせて、AWS マネジメントコンソールにOutposts リソースが登場し、EC2等リソースの構築を開始できます。

おわりに

今回は、導入の流れとポイントについてご紹介いたしました。
Outposts は、場所と電源とネットワークの準備が必要なワンラックソリューションでした。ラック内のサーバーやストレージ等ハードウェアはAWS マネージドのため、利用者はハードウェア運用管理の手間から解放されそうです。

導入したOutposts をどのように活用していくか、また別の機会にそのあたりをご紹介できればと思います。