EC2のプレイスメントグループを活用するとネットワークパフォーマンスを向上したりハードウェア障害を軽減できます

Amazon EC2にはプレイスメントグループと言う概念があり、ネットワークパフォーマンスの向上や物理サーバ障害時の影響範囲を限定させるために、インスタンスをグループ化することができます。3種類のグルーピング戦略、クラスター、パーティション、分散の違いをおさらいします。

#HPC

#Amazon EC2

#AWS

quiver

2020.09.07

この記事は公開されてから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