Amazon EC2 — Compute

プレイスメントグループPlacement Group

EC2インスタンスの物理的な配置を制御して、レイテンシーまたは耐障害性を最適化する。
3つの戦略を「たとえ話」で理解しよう。

💡 サーバーの「席替え戦略」を理解しよう

プレイスメントグループは、AWS がサーバーを物理的にどこに配置するかの戦略。
学校や会社に例えると、一瞬で違いが分かります。

🔥
クラスター
Cluster Placement Group
📖 たとえ話
「全員が同じ会議室のテーブルに座る」イメージです。

隣同士だからヒソヒソ話（低レイテンシー通信）も一瞬。 資料の受け渡し（データ転送）も超高速。

ただし、もし会議室で火災が起きたら全員が影響を受けてしまう——これが単一障害点のリスクです。
✅全員が隣席 → 通信が最速（10Gbps+）
✅HPC・機械学習の分散処理に最適
⚠️1つの障害で全滅リスク（可用性は低い）
🏢 たとえ：1つの会議室に全員集合
📍 同一AZ ・ 同一ラック
i1
EC2
i2
EC2
i3
EC2
i4
EC2
i5
EC2
🗂️ 共有データ
⚡ 超高速通信
📡 10Gbps+
🤝 密な連携
全員が同じ部屋にいるから会話も速い。
でも部屋ごと壊れたら…全滅 💥
🧬 HPC
🤖 機械学習
📊 ビッグデータ
速度
可用性
🛡️
スプレッド
Spread Placement Group
📖 たとえ話
「大事な書類を別々の銀行の金庫に分散保管する」イメージです。

1つの銀行が災害で閉鎖しても、他の銀行の金庫は無傷。最大限のリスク分散ができます。

ただし、各銀行に置ける金庫はAZあたり最大7つまで。少数精鋭の重要サーバー向けの戦略です。
✅全インスタンスが異なるラック → 最高の可用性
✅1台が壊れても他は100%無影響
⚠️AZあたり最大7台の制限あり
🏦 たとえ：大事なものを別々の金庫に
🏦
AZ-1a
🔒
Rack A
🏦
AZ-1c
🔒
Rack B
🏦
AZ-1d
🔒
Rack C
それぞれ物理的に離れている ↔️↔️↔️
1つの銀行が被災しても他は完全に安全。
ただし金庫の数には上限あり（7台/AZ）
💎 クリティカルApp
🗄️ HDFS / Cassandra
🔄 高可用性クラスタ
速度
可用性
🧱
パーティション
Partition Placement Group
📖 たとえ話
「学校の教室を分ける」イメージです。

同じ学校（AZ）の中でも教室が分かれているので、1組が学級閉鎖になっても2組・3組は通常授業を続けられます。

各教室の生徒数（インスタンス数）に上限はなく、大規模な分散システムに最適です。
✅パーティション単位で障害を隔離
✅インスタンス数の制限なし → 大規模向き
⚠️最大7パーティション / AZ
🏫 たとえ：教室が分かれた学校
🏫 同一AZ内
1組 (P-1)
😵
😵
😵
障害発生！
2組 (P-2)
😊
😊
😊
✓ 影響なし
3組 (P-3)
😊
😊
😊
✓ 影響なし
1組で障害が起きても2組・3組は正常稼働。
教室ごとに「壁」で隔離されている
🗂️ HDFS / HBase
🔀 Cassandra / Kafka
📈 大規模分散
速度
可用性
⭐ SAP TIP — 試験頻出ポイント
▸ Cluster
「低レイテンシー」「ノード間通信」が問われたら → Cluster
HPC・機械学習
▸ Spread
「最大可用性」「少数重要インスタンス」が問われたら → Spread
7台/AZ制限
▸ Partition
「大規模分散」「HDFS / Cassandra」が問われたら → Partition
障害隔離・台数無制限
比較マトリクス
項目 Cluster Spread Partition
たとえ 🏢 同じ会議室 🏦 別々の銀行 🏫 別々の教室
配置スコープ 同一AZ・同一ラック 異なるAZ・異なるラック 複数AZ・パーティション単位
インスタンス上限 制限なし 7台 / AZ 制限なし
ネットワーク ★★★ 最高 ★☆☆ 標準 ★★☆ 高
耐障害性 ★☆☆ 低 ★★★ 最高 ★★☆ 高
EFA 対応 ✓ ✗ ✗

Created by SSuzuki1063

AWS SAP Learning Resources