AWS EC2配置グループ（Placement Group）の設計｜クラスター・スプレッド・パーティション配置の使い分けとフォルトトレランス構成

宮崎智広 この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ AWS EC2配置グループ（Placement Group）の設計｜クラスター・スプレッド・パーティション配置の使い分けとフォルトトレランス構成
「インスタンスを複数起動しているのに、全部同じラックに乗っていて、ハードウェア障害で一気にダウンした。」「機械学習の分散トレーニングでインスタンス間通信が遅い。物理的な配置を変えて改善できないか。」
EC2のデフォルト起動では、AWSがインスタンスの配置先（物理ホスト・ラック）を自動決定します。通常のWebサーバーなら問題ありませんが、高可用性が必要な構成やレイテンシに敏感な並列処理ワークロードでは、Placement Group（配置グループ）を使った意図的な配置設計が重要になります。

この記事では、クラスター・スプレッド・パーティションの3種類の配置グループを解説し、ユースケースごとの使い分け基準とAWS CLIによる実践手順を説明します。

この記事のポイント

・ クラスター配置は低レイテンシ優先（HPC・ML向け）、スプレッドは最大限の物理分離
・ スプレッドはAZあたり最大7インスタンスのハードリミットに注意
・ パーティション配置はHadoop・Kafka向けで7パーティション/AZまで設定可能
・ Placement Groupは起動時のみ指定可能（既存の実行中インスタンスへの後付けは不可）


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

EC2のデフォルト配置が抱える問題

EC2をデフォルト設定で起動すると、AWSはリージョン内の利用可能なキャパシティを自動的に選択してインスタンスを配置します。この「ベストエフォート配置」では次の問題が起きる場合があります。

・複数インスタンスが同一ラックに集中する：意図せず全インスタンスが同じ物理ラックに配置される場合があり、ラック単位の障害時に全インスタンスが停止するリスクがある
・インスタンス間の通信レイテンシが不安定：並列処理ワークロードでは、物理的に離れたホスト間の通信がボトルネックになる場合がある

Placement Groupを使うと、AWSへの配置の「意図」を明示的に伝えることができます。ハードウェアの割り当てを設計者がコントロールする仕組みです。

3種類の配置グループを使い分ける

1. クラスター配置グループ（Cluster）

インスタンスを単一のアベイラビリティーゾーン内の同一ハードウェアクラスター（物理的に近いホスト群）に集中配置します。

・メリット：インスタンス間通信のネットワークレイテンシが最小になる。拡張ネットワーキング対応インスタンス（C5・R5・P3系など）では最大100Gbpsのスループットを確保できる
・デメリット：単一AZに集中するため、AZ障害で全インスタンスが停止するリスクがある。Insufficient Capacity Error（容量不足）が発生しやすい
・適した用途：機械学習の分散トレーニング、科学計算（HPC）、大規模データ処理、Apache Sparkクラスター

クラスター配置グループはAZ内に限定されるため、マルチAZ冗長設計とは本質的に相性が悪いです。パフォーマンスと可用性はトレードオフになります。パフォーマンスが最優先のバッチ処理や研究用クラスターに適した選択肢です。

2. スプレッド配置グループ（Spread）

各インスタンスを必ず異なる物理ラック（独立した電源・ネットワークを持つ）に配置します。

・メリット：1台のラック（ハードウェア）障害が他のインスタンスに波及しない。物理的な分離を保証できる
・デメリット：AZあたり最大7インスタンスのハードリミットがある。これを超えてインスタンスを起動しようとするとエラーになる
・適した用途：マスターDB（プライマリ＋レプリカ）、ZooKeeperノード、Kubernetesコントロールプレーン、少数の重要サービスの冗長化

スプレッド配置グループは複数のAZにまたがって使用できます。AZ-aとAZ-cのインスタンスをそれぞれスプレッド配置することで、ラック障害とAZ障害の両方を考慮した設計が可能です。たとえば3ノードのZooKeeperクラスターをAZ-a・AZ-c・AZ-dに1台ずつスプレッド配置すれば、どれか1台のラックが障害を起こしても残り2台で過半数クォーラムを維持できます。

3. パーティション配置グループ（Partition）

インスタンスを論理パーティションに分割し、各パーティションを異なる物理ラックに配置します。AZあたり最大7パーティションを設定できます。

・メリット：パーティション単位で障害を分離しつつ、スプレッドの7インスタンス制限を超えて多くのインスタンスを扱える。パーティション番号の情報をアプリケーション側（HadoopやKafkaのラックアウェアネス）に渡すことができる
・デメリット：パーティション間の通信は通常の拡張ネットワーキング速度になる（クラスターほどの超低レイテンシは期待できない）
・適した用途：Hadoop HDFS、Apache Kafka、Apache Cassandraなどの大規模分散ストレージ・メッセージングシステム

Kafkaを例にすると、ブローカーノードをパーティションA・B・Cに分散することで、1つのラック障害が他のパーティションのブローカーに影響しない構成を実現できます。Kafkaの `broker.rack` 設定にパーティション番号を渡すことで、Kafkaのラックアウェアネスレプリケーションと連携させることも可能です。

AWS CLIでPlacement Groupを設定する実践手順

1. Placement Groupを作成する

Strategy には `cluster`、`spread`、`partition` のいずれかを指定します。パーティション配置の場合は `--partition-count` でパーティション数も指定します。

# スプレッド配置グループを作成（重要なサービス向け）
aws ec2 create-placement-group \
  --group-name "critical-servers-spread" \
  --strategy spread \
  --region ap-northeast-1

# パーティション配置グループを作成（Kafka用・3パーティション）
aws ec2 create-placement-group \
  --group-name "kafka-partition" \
  --strategy partition \
  --partition-count 3 \
  --region ap-northeast-1

# 作成確認
aws ec2 describe-placement-groups \
  --group-names "critical-servers-spread" "kafka-partition" \
  --query 'PlacementGroups[].{Name:GroupName,Strategy:Strategy,State:State}'

# 出力例
[
    {
        "Name": "critical-servers-spread",
        "Strategy": "spread",
        "State": "available"
    },
    {
        "Name": "kafka-partition",
        "Strategy": "partition",
        "State": "available"
    }
]

2. Placement Group指定でインスタンスを起動する

Placement Groupへの登録はインスタンスの起動時にのみ指定できます。実行中のインスタンスをグループに追加したり、グループ間を移動させたりすることはできません（インスタンスを停止してから再起動する場合は変更可能です）。

# スプレッドグループにインスタンスを起動
aws ec2 run-instances \
  --image-id ami-0d7d86a9f4e9a3bae \
  --instance-type t3.medium \
  --key-name mykey-ap-northeast-1 \
  --subnet-id subnet-0aaa111111111111a \
  --placement "GroupName=critical-servers-spread" \
  --count 1

# パーティショングループのパーティション2番にインスタンスを3台起動
aws ec2 run-instances \
  --image-id ami-0d7d86a9f4e9a3bae \
  --instance-type r6i.2xlarge \
  --key-name mykey-ap-northeast-1 \
  --subnet-id subnet-0bbb222222222222b \
  --placement "GroupName=kafka-partition,PartitionNumber=2" \
  --count 3

3. インスタンスの配置グループ情報を確認する


# インスタンスの配置グループとパーティション番号を確認
aws ec2 describe-instances \
  --instance-ids i-0abc123def456ghi7 \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Placement:Placement}'

# 出力例
[
    {
        "ID": "i-0abc123def456ghi7",
        "State": "running",
        "Placement": {
            "AvailabilityZone": "ap-northeast-1a",
            "GroupName": "kafka-partition",
            "PartitionNumber": 2,
            "Tenancy": "default"
        }
    }
]

ユースケース別の配置グループ選定基準

どの配置グループを選ぶかは、ワークロードの性質によります。以下の判断軸を参考にしてください。

・インスタンス間通信速度が最優先：クラスター配置を選択する。ただしAZ障害リスクを許容できるワークロードに限定する
・少数の重要インスタンスを最大限に物理分離したい（7台以下）：スプレッド配置を選択する。複数AZにまたがって配置することでAZ障害にも対応できる
・大規模分散システムでラック障害を論理的に分離したい（7台超）：パーティション配置を選択する。Kafka・Hadoopのラックアウェアネスと組み合わせると効果的
・通常のWebサーバー・アプリサーバー：Placement Group不要。デフォルト配置で問題ない

よくある設定ミスとトラブルシュート

「InsufficientInstanceCapacity」エラーが出る場合

クラスター配置グループでは、指定したAZに連続した物理ハードウェアのキャパシティが必要です。需要が高い時間帯や大型インスタンスタイプでは容量不足エラーが発生する場合があります。

対処法は「インスタンスをすべて一度に起動する」ことです。バラバラに起動するより、同一のキャパシティリクエストとして一括起動する方がクラスター配置の要件を満たしやすくなります。また、インスタンスタイプを変更するか、異なるAZやリージョンで試みることも有効です。

インスタンスタイプの制約

クラスター配置グループで100Gbpsのネットワーク性能が発揮されるのは、拡張ネットワーキング（ENA）対応インスタンス（C5・R5・P3・M5・Hpc7a系など）に限られます。T2など旧世代インスタンスはクラスター配置グループに登録できない場合があります。起動前にインスタンスタイプのドキュメントで配置グループ対応を確認してください。

配置グループの削除はインスタンス終了後に

Placement Groupはインスタンスが存在する間は削除できません。グループに属するインスタンスをすべて終了させてから `aws ec2 delete-placement-group --group-name` で削除します。

本記事のまとめ

配置グループ 特徴 適したユースケース 主な制限
クラスター 同一クラスター内に集中配置・超低レイテンシ HPC、機械学習、Spark 単一AZ・AZ障害で全停止リスク
スプレッド 各インスタンスを異なるラックに分散 重要な少数インスタンス（DB・ZooKeeper等） AZあたり最大7インスタンス
パーティション パーティション単位でラックを分離 Hadoop、Kafka、Cassandra AZあたり最大7パーティション
EC2のPlacement Groupは、高可用性と高性能のどちらを優先するかでアーキテクチャが変わります。クラスターはパフォーマンス優先・可用性は二次、スプレッドとパーティションは可用性優先・ラック障害の分離が主目的です。システムの要件に合わせて適切に選択してください。

AWSでのLinuxサーバー運用の基礎はAWSでAmazon Linuxを活用する方法をご覧ください。マルチAZを活用した冗長構成の全体像はAWS冗長設計の実践ガイドも参考にしてください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Linux無料マニュアルを受け取る ＞＞

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。