【AWS SAP対策】EC2プレイスメントグループのまとめ
現在、AWS Certified Solutions Architect – Professional（SAP）の更新に向けて復習中です。
インプットした知識の定着の為、試験でも頻出の「EC2プレイスメントグループ」について整理してみます。
基本的なまとめとなりますので初学者向けです。
プレイスメントグループとは？
EC2インスタンスを物理ハードウェア上でどのように配置するかを制御する論理的なグループのこと。
「通信速度を極限まで上げたい」「物理障害の影響を分散させたい」といった、ワークロードごとの非機能要件に応じて、以下の3つの戦略から選択する。
1. クラスタープレイスメントグループ
近接配置戦略
単一のAZ内で、インスタンス同士を物理的に近い場所（同一または近接したラック群）に配置物理ハードウェア上でどのように配置するか。
-
特徴:
- 低レイテンシ・高スループットなネットワーク性能。
-
物理配置:
- 同一のネットワークセグメント（近接ラック群）。
-
向いている用途:
- HPC（ハイパフォーマンスコンピューティング）
- 機械学習の分散トレーニング
- 密結合なノード間通信が必要なワークロード
-
注意点:
- ラック障害時にグループ全体が影響を受ける（単一障害点のリスク）。
- 起動エラーを避けるため、「一度のリクエストでまとめて起動」するのが定石。
2. スプレッドプレイスメントグループ
完全分散戦略
各インスタンスを、それぞれ異なる物理ハードウェア（ラック）に厳格に分離して配置。
-
特徴:
- 最大限の障害隔離。
-
物理配置:
- 1インスタンスごとに異なるラック。
-
向いている用途:
- システムの核となるDBインスタンス
- 少数のクリティカルなEC2
-
制限:
- 1AZあたり最大7インスタンスまでという厳しい上限あり
3. パーティションプレイスメントグループ
「大規模分散と可用性」のバランス戦略
グループ内を「パーティション」という単位（論理的なラックの集まり）に分け、パーティション間で物理ラックを共有しないように配置。
-
特徴:
- 大規模な台数と耐障害性の両立。
-
物理配置:
- パーティションごとに異なるラック群。
-
向いている用途:
- HDFS、Hadoop、Cassandra、Kafkaなどの分散データストア
-
メリット:
- 数百台規模のインスタンスを管理可能。
- アプリケーション側で「どのパーティションにいるか」を識別し、データのレプリカ先を分散させるといった設計が可能。
比較まとめ
| 項目 | クラスター | スプレッド | パーティション |
|---|---|---|---|
| 主な目的 | ネットワーク性能 | 可用性重視 | 大規模分散（バランス） |
| 通信性能 | ◎ (極めて高い) | △ (通常) | ◯ (良好) |
| 耐障害性 | △ (ラック障害に弱い) | ◎ (最高) | ◯ (ラック単位で隔離) |
| 最大台数 | AZの空き容量に依存 | 7台 / AZ | 1パーティションに数十台 |
| キーワード | HPC、低遅延、密結合 | DB、少数精鋭、物理分離 | Hadoop、Kafka、ラック認識 |
SAP試験対策のポイント
試験で以下のキーワードに目ざとく反応するべし。
- 「低レイテンシ」「計算ノード間通信」
⇒クラスタープレイスメントグループを選択。 - 「物理ホストの障害から保護」「少数の重要なインスタンス」
⇒スプレッドプレイスメントグループを検討。ただし台数制限（7台）に注意。 - 「HDFS/Kafka」「大規模な分散」
⇒ パーティションプレイスメントグループを選択。 - 「マルチAZをまたげるか？」
⇒ クラスターは不可。スプレッドとパーティションは可能。
まとめ
プレイスメントグループは、
EC2インスタンスを物理ハードウェア上でどのように配置するかを制御する仕組み。
- ネットワーク性能重視なら「クラスタープレイスメントグループ」
- 可用性重視なら「スプレッドプレイスメントグループ」
- 大規模分散なら「パーティションプレイスメントグループ」
それぞれの特性を理解して、シナリオ問題で最適な構成を選べるようにしておく。
参考資料