この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Amazon EC2にはプレイスメントグループと言う概念があり、ネットワークパフォーマンスの向上や物理サーバ障害時の影響範囲を限定させるために、インスタンスをグループ化することができます。
今回は、3種類あるプレイスメントグループ戦略について、説明します。
3種類の戦略
プレイスメントグループにはクラスター・分散・パーティションの3種類の戦略があります。
クラスター(cluster)
※ 図は公式ドキュメントから
- HPC のようなワークロード向け
- インスタンス群を高バイセクションバンド幅セグメントに配置
- ノード間通信で低レイテンシー、高スループットなネットワークパフォーマンスを実現
- 利用可能なインスタンスタイプに制限あり(対応インスタンス一覧)。例えば、T系インスタンスは利用不可。
AWS ParallelClusterを利用してHPCクラスターを構築している場合、設定ファイルで次の様に指定すると、クラスター型プレイスメントグループを利用できます。
[cluster]
...
placement_group = DYNAMIC ※ あるいは作成済みクラスターグループ名
...分散(spread)
※ 図は公式ドキュメントから
- 物理ラックの単位でインスタンスを配置。
- ハードウェア障害による影響を隔離。
パーティション(partition)
※ 図は公式ドキュメントから
- HDFS、HBase、Cassandra、Kafka、Aerospikeのような大規模な分散システム向け
- 各パーティションにはラックが対応。アプリケーション内でのハードウェア障害による影響を隔離。
分散とパーティションは似通っています。
AWS の公式ブログでは、パーティション型が追加された背景について、以下の通り記載されています。
While spread placement groups work well for small workloads, customers wanted a way to reduce correlated failures for large distributed and replicated workloads that required hundreds of EC2 instances. They also wanted visibility into how instances are placed relative to each other on the underlying hardware. To address these needs, we introduced partition placement groups.
戦略ごとの比較
大まかな違いは以下の通りです。
| 戦略 | クラスター | パーティション | 分散 |
|---|---|---|---|
| 用途 | 低いネットワークレイテンシー、高いネットワークスループット。 HPCなど |
プレイスメントグループ内のパーティションどうしが同じラックを共有しない。 アプリケーション内でのハードウェア障害による影響を隔離 HDFS、HBase、Cassandra、Kafka、Aerospikeなど |
各インスタンスを独自のネットワークおよび電源がある異なるラックに別々に配置 |
| 配置制限 | 複数AZにまたがることはできない。
ピアリングされた別VPCにまたげる。 |
AZあたり7パーティションまで持てる。 3AZあるリージョンなら最大21パーティション。 インスタンスをすべてのパーティションに均等に分散しようとするが、均等な配置を保証するものではない。 パーティションを指定してインスタンス配置できる。 |
複数AZにまたがることができる。 AZあたり7インスタンスまで、３AZあるリージョンなら21インスタンスまで起動可能 |
| ハードウェア専有インスタンス | . | 2パーティションまで | 未対応 |
| Dedicated Hosts | 未対応 | 未対応 | 未対応 |
プレイスメントグループ戦略の違いによるPING RTT時間の違い
M5a インスタンス上のAmazon Linux 2(拡張ネットワーキングは有効)を用いてpingを100回実行し($ sudo ping -f -c 100 172.31.1.123)、AZやプレイスメントグループ戦略(Cluster/Partition/Spread)の違いによる round trip time(RTT) 時間を計測しました。
| ping stats | 同AZ | 別AZ | 同Cluster内 | 同AZの同Partition | 同AZの別Partition | 別AZの別Partition | 同AZのSpread | 別AZのSpread |
|---|---|---|---|---|---|---|---|---|
| min | 0.242 | 0.582 | 0.034 | 0.029 | 0.042 | 0.58 | 0.067 | 0.583 |
| avg | 0.264 | 0.612 | 0.04 | 0.037 | 0.049 | 0.606 | 0.075 | 0.601 |
| max | 0.51 | 0.947 | 0.128 | 0.201 | 0.198 | 0.86 | 0.245 | 0.798 |
| mdev | 0.04 | 0.067 | 0.011 | 0.019 | 0.018 | 0.048 | 0.023 | 0.038 |
| ipg | 0.292 | 0.648 | 0.064 | 0.06 | 0.072 | 0.626 | 0.096 | 0.634 |
| ewma | 0.261 | 0.626 | 0.037 | 0.035 | 0.049 | 0.618 | 0.073 | 0.594 |
avg(平均)をグラフ化します。
次の様な傾向を読み取れます
- クラスター型、及び、パーティション型の同じパーティション間(=同一ラック)のRTTの短さは別格
- パーティション・分散型でも、同じAZ内であれば、プレイスメントグループ外のインスタンスとの通信よりもRTTは小さい
- AZをまたぐと、プレイスメントグループはRTTの軽減に寄与しない
インスタンスのプレイスメントグループ情報の確認方法
API から
EC2::DescribeInstances API で確認します。
https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html
メタデータから
2020/08 のアップデートにより、プレイスメントグループ情報をメタデータ(placement)から取得できるようになりました。
- availability-zone
- availability-zone-id
- group-name
- region
は全戦略共通で、パーティション型の場合、
- partition-number
も取得できます。
$ curl http://169.254.169.254/latest/meta-data/placement/
availability-zone
availability-zone-id
group-name
partition-number
region
# プレイスメントグループ名
$ curl http://169.254.169.254/latest/meta-data/placement/group-name
test-partition
# パーティション番号
$ curl http://169.254.169.254/latest/meta-data/placement/partition-number
2コスト
プレイスメントグループの利用に伴い、追加コストは発生しません。
まとめ
EC2 のプレイスメントグループを利用すると、インスタンス間の通信性能を向上させたり、データセンターでのハードウェア障害時の影響範囲をコントロールすることができます。
AWS外でも、Azureであれば Proximity Placement Group、GCPであれば Placement Policy という形で同等の機能を利用できます。
EC2インスタンスをたくさん並べて HPC や HDFS、HBase、Cassandra、Kafka、Aerospike のような分散システムを構築している場合、一度プレイスメントグループの利用を検討してみてはいかがでしょうか。
2
