プレイスメントグループ - Amazon Elastic Compute Cloud

プレイスメントグループ

ワークロードのニーズを対応するために、相互に依存する EC2 インスタンスのグループをプレイスメントグループ内に作成して、そのプレイスメントに影響を与えることができます。

ワークロードのタイプに応じて、以下のいずれかのプレイスメント戦略によりプレイスメントグループを作成できます。

  • [クラスター] – アベイラビリティーゾーン内でインスタンスをまとめます。この戦略により、ワークロードは、ハイパフォーマンスコンピューティング (HPC) アプリケーションで典型的な緊密に組み合わされたノード間通信に必要な低レイテンシーネットワークパフォーマンスを実現できます。

  • パーティション – インスタンスを複数の論理パーティションに分散させ、1 つのパーティション内のインスタンスのグループが基盤となるハードウェアを別のパーティション内のインスタンスのグループと共有しないようにします。この戦略は、Hadoop、Cassandra、Kafka などの大規模な分散および複製ワークロードで一般的に使用されます。

  • スプレッド 相関性のエラーを減らすために、少数のインスタンスを基盤となるハードウェア全体に厳密に配置します。

プレイスメントグループは任意で選択します。インスタンスをリプレイスメントグループに作成しない場合、EC2 は、関連する障害を最小限に抑えるために、すべてのインスタンスが基盤となるハードウェア全体に分散されるような方法でインスタンスを配置しようとします。

プレイスメントグループを作成するための料金は発生しません。

プレイスメント戦略

プレイスメントグループは、次のいずれかのプレイスメント戦略を使用して作成できます。

クラスタープレイスメントグループ

クラスタープレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。クラスタープレイスメントグループは、同じリージョン内の複数のピア接続 VPC にまたがることができます。同じクラスタープレイスメントグループ内のインスタンスは、TCP/IP トラフィックのフローあたりのスループット上限が高くなり、ネットワークの二分帯域幅の広い同じセグメントに配置されます。

次の図は、クラスタープレイスメントグループに配置されたインスタンスを示しています。


                    クラスタープレイスメントグループ。

低いネットワークレイテンシー、高いネットワークスループット、またはその両方からメリットを受けるアプリケーションの場合は、クラスタープレイスメントグループの使用をお勧めします。また、ネットワークトラフィックの大部分がグループ内のインスタンス間で発生している場合にもお勧めします。プレイスメントグループで、最も低いレイテンシーと最も高いネットワークパフォーマンス (1 秒あたりパケット数) を実現するためには、拡張ネットワーキングをサポートするインスタンスタイプを選択します。詳細については、拡張ネットワーキングを参照してください。

インスタンスは、次の方法で起動することをお勧めします。

  • プレイスメントグループ内で必要な数のインスタンスを起動するには、1 つの起動リクエストを使用します。

  • プレイスメントグループ内のすべてのインスタンスに同じインスタンスタイプを使用します。

後でプレイスメントグループにさらにインスタンスを追加しようとした場合、またはプレイスメントグループ内で複数のインスタンスタイプを起動しようとした場合、容量不足エラーが発生する可能性が高くなります。

プレイスメントグループ内のインスタンスを停止して再起動しても、そのインスタンスは同じプレイスメントグループ内で実行されます。ただし、インスタンスに対して十分な容量がない場合、起動は失敗します。

既にインスタンスを実行中のプレイスメントグループ内のインスタンスを起動するときに容量エラーを受け取った場合は、プレイスメントグループ内のすべてのインスタンスを停止して開始し、もう一度起動を試みてください。インスタンスを起動すると、すべてのリクエストしたインスタンスに応じた容量があるハードウェアにインスタンスが移行される場合があります。

パーティションプレイスメントグループ

パーティションプレイスメントグループは、アプリケーションに関連するハードウェア障害の頻度を軽減するために役立ちます。パーティションプレイスメントグループを使用する場合、Amazon EC2 は各グループをパーティションと呼ばれる論理的なセグメントに分割します。Amazon EC2 では、プレイスメントグループ内の各パーティションにそれぞれ一連のラックがあります。各ラックには独自のネットワークおよび電源があります。プレイスメントグループ内のパーティションどうしが同じラックを共有することはありません。これにより、アプリケーション内でのハードウェア障害による影響を隔離できます。

次のイメージは、単一のアベイラビリティーゾーン内のパーティションプレイスメントグループのシンプルな描写を示しています。ここでは、3 つのパーティション (パーティション 1パーティション 2パーティション 3) があるパーティションプレイスメントグループに配置されたインスタンスを示しています。各パーティションは複数のインスタンスで構成されています。各パーティション内のインスタンスは、他のパーティション内のラックを共有しないため、単一のハードウェア障害の影響は関連付けられたパーティションのみに留まります。


                    3 つのパーティションがあるパーティションプレイスメントグループ。

パーティションプレイスメントグループは、HDFS、HBase、Cassandra などの大規模な分散および複製ワークロードを異なるラック間でデプロイするために使用できます。インスタンスをパーティションプレイスメントグループに起動すると、Amazon EC2 は、指定したパーティション数全体にインスタンスを均等に分散しようとします。インスタンスを特定のパーティションに起動して、インスタンスの配置場所をより細かく制御することもできます。

パーティションプレイスメントグループは、同じリージョン内の複数のアベイラビリティーゾーンにパーティションを持つことができます。パーティションプレイスメントグループは、アベイラビリティーゾーンごとに最大 7 つのパーティションを持つことができます。パーティションプレイスメントグループで起動できるインスタンス数の制限は、アカウントの制限のみです。

また、パーティションプレイスメントグループでは各パーティションが可視化されるため、どのインスタンスがどのパーティションにあるかを確認できます。この情報は、HDFS、HBase、Cassandra などトポロジー対応アプリケーションと共有できます。これらのアプリケーションはこの情報を利用してインテリジェントなデータレプリケーションの決定を行い、データの可用性と耐久性を向上します。

パーティションプレイスメントグループでインスタンスを開始または起動し、リクエストを実行するための固有のハードウェアが不足している場合、そのリクエストは失敗します。Amazon EC2 では、時間の経過とともに、より明確なハードウェアを利用できるようになるため、後でリクエストを再試行できます。

スプレッドプレイスメントグループ

スプレッドプレイスメントグループは、それぞれ異なるハードウェアに配置されるインスタンスのグループです。

スプレッドプレイスメントグループは、少数の重要なインスタンスが互いに分離して保持される必要があるアプリケーションに推奨されます。スプレッドレベルのプレイスメントグループでインスタンスを起動すると、インスタンスが同じ機器を共有するときに発生し得る同時障害のリスクが軽減されます。スプレッドレベルのプレイスメントグループは、異なるハードウェアへのアクセスを提供するため、長時間のインスタンスタイプの混合やインスタンスの起動に適しています。

スプレッドプレイスメントグループでインスタンスを開始または起動し、リクエストを実行するための固有のハードウェアが不足している場合、そのリクエストは失敗します。Amazon EC2 では、時間の経過とともに、より明確なハードウェアを利用できるようになるため、後でリクエストを再試行できます。プレイスメントグループは、ラックまたはホスト全体でインスタンスを分散できます。ラックレベルのスプレッドプレイスメントグループは、AWS リージョンおよび AWS Outposts で使用できます。ホストレベルのスプレッドプレイスメントグループは、AWS Outposts を使用する場合にのみ使用できます。

ラックレベルのスプレッドプレイスメントグループ

次の図は、1 つのアベイラビリティーゾーン内の、スプレッドプレイスメントグループに配置された 7 つのインスタンスを示しています。7 つのインスタンスは、7 つの異なるラックに配置され、各ラックは独自のネットワークおよび電源を備えています。


                    スプレッドプレイスメントグループ。

ラックレベルのスプレッドプレイスメントグループは、同じリージョン内の複数のアベイラビリティーゾーンに分散できます。リージョンでは、ラックレベルのスプレッドプレイスメントグループについては、グループごとのアベイラビリティーゾーンごとに、最大 7 つの実行中のインスタンスを持つことができます。Outposts では、ラックレベルのスプレッドプレイスメントグループは、Outpost デプロイメント内のラックと同じ数のインスタンスを保持できます。

ホストレベルのスプレッドプレイスメントグループ

ホストレベルのスプレッドプレイスメントグループは、AWS Outposts を使用する場合にのみ使用できます。ホストスプレッドレベル配置グループは、Outpost デプロイメント内のホストと同じ数のインスタンスを保持できます。詳細については、「AWS Outposts のプレイスメントグループ」を参照してください。

プレイスメントグループのルールと制限

一般的なルールと制限

プレイスメントグループを使用する前に、次のルールに注意してください。

  • リージョンごとにアカウントあたり、最大 500 個のプレイスメントグループを作成できます。

  • プレイスメントグループには、リージョンの AWS アカウント内で固有の名前を付ける必要があります。

  • プレイスメントグループをマージすることはできません。

  • インスタンスは、1 つのプレイスメントグループ内で一度に起動できます。複数のプレイスメントグループにまたがることはできません。

  • オンデマンドキャパシティ予約およびゾーンリザーブドインスタンスを使用すると、アベイラビリティーゾーンの EC2 インスタンスに対してキャパシティを予約できます。インスタンスを起動するときに、インスタンス属性がオンデマンドキャパシティ予約またはゾーンリザーブドインスタンスで指定された属性と一致する場合、リザーブドキャパシティはインスタンスによって自動的に使用されます。これは、プレイスメントグループにインスタンスを起動する場合にも当てはまります。

    クラスタープレイスメントグループにインスタンスを起動する場合は、クラスタープレイスメントグループでキャパシティを明示的に予約することをお勧めします。これを行うには、指定したクラスタープレイスメントグループにオンデマンドキャパシティ予約を作成します。この方法ではオンデマンドキャパシティ予約を使用してキャパシティを予約できますが、プレイスメントグループでキャパシティを明示的に予約できないため、ゾーンリザーブドインスタンスでは同じ操作を行うことはできません。

  • Dedicated Hosts をプレイスメントグループで起動することはできません。

  • プレイスメントグループの中断時に停止または休止するように設定されたスポットインスタンスは起動できません。

クラスタープレイスメントグループのルールと制限

クラスタープレイスメントグループには、以下のルールが適用されます。

  • 以下のインスタンスタイプがサポートされています。

  • クラスタープレイスメントグループを、複数のアベイラビリティーゾーンで設定することはできません。

  • クラスタープレイスメントグループの 2 つのインスタンス間のトラフィックの最大ネットワークスループット速度は、2 つのインスタンスのうち遅い方に制限されます。高スループットの要件があるアプリケーションの場合、要件に適合するネットワーク接続を備えたインスタンスタイプを選択します。

  • 拡張ネットワーキングに対して有効になっているインスタンスには、以下のルールが適用されます。

    • クラスタープレイスメントグループ内のインスタンス間では、シングルフロートラフィックに最大 10 Gbps を使用できます。クラスタープレイスメントグループ内にないインスタンスは、シングルフロートラフィックに最大 5 Gbps を使用できます。

    • 同じリージョン内でのインスタンスと Amazon S3 バケットとの間では、パブリック IP アドレス空間または VPC エンドポイントを介したトラフィックに、使用可能なすべてのインスタンスの集計帯域幅を使用できます。

  • 複数のインスタンスタイプをクラスタープレイスメントグループに起動できます。ただし、これにより起動に成功するために必要な容量が使用可能になる可能性が低くなります。クラスタープレイスメントグループ内ですべてのインスタンスで同じインスタンスタイプを使用することをお勧めします。

  • インターネットへのネットワークトラフィックとオンプレミスリソースへの AWS Direct Connect 接続は、5 Gbps に制限されます。

パーティションプレイスメントグループのルールと制限

パーティションプレイスメントグループには、以下のルールが適用されます。

  • パーティションプレイスメントグループは、アベイラビリティーゾーンごとに最大 7 つのパーティションをサポートします。パーティションプレイスメントグループで起動できるインスタンス数の制限は、アカウントの制限のみです。

  • インスタンスをパーティションプレイスメントグループに起動すると、Amazon EC2 は、すべてのパーティションにインスタンスを均等に分散しようとします。Amazon EC2 では、すべてのパーティションにインスタンスが均等に分散されるとは限りません。

  • ハードウェア専有インスタンス を持つパーティションプレイスメントグループは、最大 2 つのパーティションを持つことができます。

  • [Capacity Reservations] (キャパシティー予約) を使用して、パーティションプレイスメントグループでキャパシティを予約することはできません。

スプレッドプレイスメントグループのルールと制限

スプレッドプレイスメントグループには、以下のルールが適用されます。

  • ラックスプレッドプレイスメントグループは、アベイラビリティーゾーンごとに最大 7 つの実行インスタンスをサポートします。例えば、3 つのアベイラビリティーゾーンがあるリージョンでは、グループ内で合計 21 個のインスタンスを実行でき、各アベイラビリティーゾーンに 7 個のインスタンスがあります。同じアベイラビリティーゾーンと同じスプレッドプレイスメントグループで 8 番目のインスタンスを開始しようとすると、インスタンスは起動しません。アベイラビリティーゾーンに 7 個を超えるインスタンスが必要な場合は、複数のスプレッドプレイスメントグループを使用することをお勧めします。複数のプレイスメントグループに分散しても、グループ間でインスタンスが分散されるとは限りませんが、グループごとの分散が確実になされるようにできるため、特定の障害クラスからの影響は制限されます。

  • ハードウェア専有インスタンス では、スプレッドプレイスメントグループはサポートされていません。

  • ホストレベルのスプレッドプレイスメントグループは、AWS Outposts のプレイスメントグループでのみサポートされます。ホストレベルのスプレッドプレイスメントグループは、Outpost デプロイメント内のホストと同じ数のインスタンスを保持できます。

  • リージョンでは、ラックレベルのスプレッドプレイスメントグループについては、グループごとのアベイラビリティーゾーンごとに、最大 7 つの実行中のインスタンスを持つことができます。AWS Outposts では、ラックレベルのスプレッドプレイスメントグループは、Outpost デプロイメント内のラックと同じ数のインスタンスを保持できます。

  • [Capacity Reservations] (キャパシティー予約) を使用して、スプレッドプレイスメントグループでキャパシティを予約することはできません。