AWS Outposts でのキャパシティ管理戦略

このブログ記事では、AWS Outposts ラックを複数のワークロードで利用する際の Amazon Elastic Compute Cloud (Amazon EC2) のキャパシティプランニングと、その管理の方法を紹介します。これにより、お客様は Outposts ラック上で稼働するワークロードに求められる可用性を維持しながら、効率的に Outposts ラックのリソースを利用できます。

株式会社野村総合研究所では、このキャパシティ管理戦略を用いて、Outposts で稼働するワークロードに求められる可用性を維持しながら、効率的に Outposts のリソースを利用しています。

AWS Outposts の特徴

Outposts は、フルマネージド型の AWS インフラストラクチャ、ネイティブな AWS のサービス、API、およびツールを、お客様のオンプレミス施設で提供します。これにより、今までクラウドへの移行が困難であった低遅延ネットワーク要件のワークロードや、特定のロケーションでデータを保存する、データレジデンシーの要件があるワークロードを稼働させることができます。Outpostsは、オンプレミスのインフラストラクチャの調達、管理、アップグレードのために必要なお客様の作業を取り除きます。

AWS Outposts ラックの注文

Outposts ラックを注文する際は、Amazon EC2 のインスタンスタイプのうち、汎用 (M5)、コンピューティング最適化(C5)、高速コンピューティング (G4dn)、メモリ最適化 (R5)、ストレージ最適化 (I3en) の中から、必要なインスタンス数を算出し、それに見合った Outposts ラック上のサーバーの台数を指定して注文します。サーバー1台は、24xlarge のインスタンスサイズに相当します。

AWS Outposts のキャパシティプランニング

Outposts は、物理的に接続された 1 つ以上の Outposts ラックを 1 つの論理 Outpost (以下 Outpost) として管理できます。これにより、コンピューティング容量とストレージ容量のプールを提供します。 Outpost は、単一の目的のワークロードだけでなく、特性の異なる複数のワークロードを集約することができます。Outposts 活用のユースケースとして、オンプレミスのリソースとの低遅延接続、データレジデンシーに留まらず、その周辺ワークロードを含めた、ハイブリッドワークロードにおける中継環境、クラウドへの段階的移行のための環境など、複数のニーズに応えることができます。

AWS リージョンにおける Amazon EC2 の容量は限りがないように見えますが、Outpost の容量には限りがあり、注文したコンピューティング容量の合計によって制約されます。

Outpost で高可用性の設計とする場合、N+M 可用性モデルをサポートするのに十分なコンピューティングキャパシティを注文する必要があります。N は必要なサーバー数、M はサーバー障害に対応するためにプロビジョニングされたスペアサーバーの数です。N+1 と N+2 が最も一般的な可用性レベルです。

Outpost では、各サーバー (C5 、 M5 、 R5 など) は、単一ファミリーの Amazon EC2 インスタンスをサポートします。Amazon EC2 でインスタンスを起動する前に、各サーバーが提供する Amazon EC2 インスタンスサイズを指定するスロッティングレイアウトを準備する必要があります。スロッティングレイアウトの例として、m5.large インスタンスを 48 台起動できる単一インスタンスサイズのレイアウトや、m5.large が 4 台、m5.xlarge が 4 台、m5.2xlarge が 3 台、m5.4xlarge が 1 台、m5.8xlarge が 1 台起動できるサイズ混在のレイアウトが挙げられます。

Outpost で N + M 可用性モデルを実現するためには、各サーバーごとにスロッティングレイアウトを設定し、インスタンスサイズ別に Amazon EC2 の容量プールとして管理します。例えば、サーバーが 4 台あった場合、Amazon EC2 のキャパシティ容量は 4 × 24xlarge です。すべて m5.xlarge を割り当てた場合は合計 96 台の m5.xlarge インスタンスが起動ができます。ただし、全ての Amazon EC2 容量プールを消費する形でインスタンスを起動してしまうと、⼀つのサーバーで障害が発⽣した際に、別のサーバーでインスタンスを再起動することができなくなってしまいます。そのため、Amazon EC2 容量プールで N + M サーバーの可⽤性を考慮する場合は、容量プールの使⽤率が 100 % にならないように設計します。例えば N + 1 可用性の場合、4 台のサーバーの内、 1 台のサーバーを余剰リソースとして確保することになるため、実際に利用できる Amazon EC2 のキャパシティ容量は 3 × 24xlarge となります。

このような設計は、単一のワークロードや必要なリソース量の変化が激しくない場合には難しくはないと考えられます。しかし、複数のワークロードを Outpost で稼働させる場合、リソースへの要求が重複したり、他のワークロードが過剰にリソースを消費してしまう可能性を考慮しなくてはなりません。そこで、Outpost ではキャパシティ予約とリソース共有を使うことで、ワークロードごとのリソースを確保する仕組みを作る事ができます。

Outpost でのキャパシティ予約とリソース共有

AWS Organizations を利用すると、1 つの Outpost のリソースを複数の AWS アカウントで利用することができます。Outpost のオーナーアカウントである Organizations の管理アカウントと、メンバーアカウントの間で、Outpost のリソースを共有できます。Organizations の管理アカウントでは、Outpost でのキャパシティ予約を利用して、メンバーアカウントに配分するリソースのプールを作成します。

この Outpost でのキャパシティ予約を、リソース共有機能を使って、Organizations のメンバーアカウントに割り振ることができます。これにより、特定の AWS アカウントで意図しない Amazon EC2 インスタンスの過剰な消費が発生しても、該当のワークロードで割り当てているキャパシティ予約済みのリソースを保護できます。

Outpost オーナーアカウントである Organizations 管理アカウントで、Outpost 上の全てのリソースのキャパシティ予約を作成すれば、共有先のメンバーアカウントでは一切割り当てた分以上のインスタンスを起動させない、厳密な管理も可能です。しかし、リソース割り当て量を増減したり、キャパシティ予約では管理されない Elastic Load Balancing (ELB) や Amazon Relational Database Service (Amazon RDS) のインスタンスを起動したい場合は、その都度全てのキャパシティ予約を変更する必要があり、運用が煩雑になります。そのため、メンバーアカウントに割り当てるキャパシティ予約は本番環境のみとしたり、最低限確保したい容量のみとして、予約されないリソースをバッファとして用意しておくこともできます。その場合、意図しないリソース消費が発生した際は、そのバッファ分の Amazon EC2 インスタンスは起動できるため、これを Amazon CloudWatch で監視するといった工夫をすることも必要でしょう。

このように、Outpost 全体のキャパシティへの影響の考慮が必要なユースケースとして、例えば本番環境と開発環境を同じ Outpost 上に展開しても、ワークロードごとの影響を抑えることができます。

本ブログの著者について

Yuki Taniguchi

Yuki は AWS のソリューションアーキテクトとして、日本の金融業界を担当しています。2011年から銀行システムの設計・開発・プロジェクトマネジメントに携わる。2019年から現職。