インスタンスのプレイスメント

Outposts のコンピューティングホストの数には限りがあります。アプリケーションが Outposts に複数の関連インスタンスをデプロイする場合、追加の設定を行わなくても、それらのインスタンスは同じホストまたは同じラックのホストにデプロイできます。現在、同じインフラストラクチャで関連するインスタンスを実行するリスクを軽減するために、インスタンスを分散するために使用できるメカニズムは 3 つあります。

マルチ Outpost デプロイ — リージョンのマルチ AZ 戦略と同様に、Outposts を個別のデータセンターにデプロイし、アプリケーションリソースを特定の Outposts にデプロイできます。これにより、目的のOutpost (ラックの論理セット) でインスタンスを実行できます。ダイレクト VPC ルーティングを使用した複数の Outposts 間の VPC 内通信は、Outpost ローカルゲートウェイ (LGW) を使用して Outposts 上のサブネット間にルートを作成し、同じ VPC 内の複数の Outposts にワークロードを分散するために使用できるもう 1 つの戦略です。ラックやデータセンターの障害モードを防ぐためにマルチ Outpost 戦略を採用でき、Outposts が別々の AZ またはリージョンにアンカーされている場合は、AZ またはリージョンの障害モードに対する保護も提供できます。マルチ Outpost アーキテクチャの詳細については、「大規模障害モード」を参照してください。

Outposts の Amazon EC2 プレイスメントグループ (シングル Outpost マルチラックインスタンスプレイスメント) – アカウントで作成した Outposts 上にプレイスメントグループを作成できます。これにより、自分のサイトにある Outpost において、基盤となるハードウェア全体でインスタンスを分散できるようになります。Outpost で分散戦略を使用してプレイスメントグループを作成する場合、プレイスメントグループがホストまたはラック全体でインスタンスを分散するように選択できます。

スプレッドプレイスメントグループの使用は、1 つのインスタンスを複数のラックまたはホストに分散させる簡単な方法となり、相互に関連する障害が発生する可能性が低くなります。グループにデプロイできるインスタンスの数は、Outpost にあるホストの数だけです。

3 台のラックがある Outpost の EC2 スプレッドプレイスメントグループ

パーティションプレイスメントグループを使用して、インスタンスを複数のラックに分散することもできます。自動分散を使用して、グループ内のパーティションにインスタンスを分散したり、選択したターゲットパーティションにインスタンスをデプロイしたりできます。インスタンスをターゲットパーティションにデプロイすると、選択したリソースを同じラックにデプロイしながら、他のリソースをラック全体に分散できます。例えば、3 台のラックで構成される論理 Outpost がある場合、3 つのパーティションで構成されるパーティションプレイスメントグループを作成すると、ラック全体にリソースを分散できます。

3 台のラックがある Outpost の EC2 パーティションプレイスメントグループ

クリエイティブサーバースロッティング — シングルラックの Outpost を使用している場合や、Outposts で使用しているサービスがプレイスメントグループをサポートしていない場合は、クリエイティブスロッティングを使用してインスタンスが同じ物理サーバーにデプロイされないようにすることができます。関連するインスタンスが同じ EC2 インスタンスサイズの場合、サーバーをスロットして、各サーバーに設定されるそのサイズのスロットの数を制限して、スロットをサーバー全体に分散できる場合があります。サーバースロッティングは、1 台のサーバーで実行できる (そのサイズの) インスタンスの数を制限します。

例として、先に図 13 に示したスロッティングレイアウトを考えてみましょう。アプリケーションがこのスロッティングレイアウトで設定された Outpost に 3 つの m5.4xlarge インスタンスをデプロイする必要がある場合、EC2 は各インスタンスを別々のサーバーに配置し、サーバーで追加の m5.4xlarge スロットを開くようにスロッティング設定が変更されない限り、これらのインスタンスを同じサーバーで実行される可能性はありません。

コンピューティングインスタンスプレイスメントの推奨プラクティス