EC2 拡張ネットワーキングとプレイスメントグループの効果を試す

アイキャッチ AWS EC2

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

AWSで最も基本的なサービスの1つともいえるEC2ですが、その設定の中で"拡張ネットワーキング"と"プレイスメントグループ"というのがあるのをご存知でしょうか?

目新しい機能ではありませんし、意識して設定しなくても不都合が発生するものでもありませんのでデフォルト状態で利用されている方もいるのではないでしょうか。

Linux の拡張ネットワーキング

拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。

プレイスメントグループ

プレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。サポートされているインスタンスタイプとともにプレイスメントグループを使用すると、アプリケーションが低レイテンシーの 10 Gbps (ギガビット/秒) ネットワークに参加できるようになります。

どちらもインスタンス間における低レイテンシな通信を実現するための機能オプションです。

クラスタコンピューティングやDBの同期レプリケーションのように、サーバ間の通信レイテンシがサービス品質に影響するような場合に効果を発揮します。

この機能により、どれだけレイテンシが改善するのかを検証しました。

検証構成

図のように以下のインスタンスの位置関係3パターンに対し拡張NWあり/なしそれぞれのケースで、通信のレイテンシを測定します。

placementgroup検証

  1. AZ内+プレイスメントグループあり
  2. AZ内+プレイスメントグループなし
  3. 別AZ

プレイスメントグループの適用

インスタンス作成時にプレスメントグループを指定するだけで適用されます。

placementgroup

新規に作成するか、作成済みのプレイスメントグループを指定します。

拡張ネットワーキングの有効化

OSへのモジュールインストールとEC2インスタンスへの有効化が必要となります。

VPC 内の Linux インスタンスにおける Intel 82599 VF インターフェイスを使用した拡張ネットワーキングの有効化

VPC 内の Linux インスタンスにおける Elastic Network Adapter (ENA) を使用した拡張ネットワーキングの有効化

今回はすでにモジュールがインストールされているCentOS6、インスタンスタイプはc3.largeを使用しました。

インスタンスで有効/無効を確認するにはCLIでsriovNetSupport属性を確認します。

$ aws ec2 describe-instance-attribute --instance-id i-0ca9170a183b62efe --attribute sriovNetSupport
{
    "InstanceId": "i-0ca9170a183b62efe",
    "SriovNetSupport": {}
}

CentOSのAMIではデフォルトで無効となっていますので、有効化します。 インスタンスを停止した状態で以下のコマンドを実行します。

$ aws ec2 modify-instance-attribute --instance-id i-0ca9170a183b62efe --sriov-net-support simple

再度状態を確認し、以下のようになれば有効化されています。

$ aws ec2 describe-instance-attribute --instance-id i-0ca9170a183b62efe --attribute sriovNetSupport
{
    "InstanceId": "i-0ca9170a183b62efe",
    "SriovNetSupport": {
        "Value": "simple"
    }
}

AmazonLinuxの最新AMIの場合は拡張ネットワーキングに対応したインスタンスタイプ(C3、C4、R3、I2、M4、D2)ではデフォルトで有効になるようです。

結果

各パターンで Ping を100回実行した結果です。(単位:msec)

拡張ネットワーキングなし

環境 min avg max mdev
プレイスメントグループ内 0.239 0.301 0.410 0.034
同一AZ内 0.318 0.385 0.814 0.075
別AZ 2.088 2.160 2.686 0.078

 

片方のインスタンスのみ拡張ネットワーキング有効化

環境 min avg max mdev
プレイスメントグループ内 0.201 0.252 0.347 0.029
同一AZ内 0.260 0.326 0.419 0.030
別AZ 2.015 2.102 2.768 0.121

 

対向のインスタンスで拡張ネットワーキング有効化

環境 min avg max mdev
プレイスメントグループ内 0.130 0.157 0.172 0.018
同一AZ内 0.202 0.220 0.389 0.023
別AZ 1.985 2.023 2.644 0.076

結論

結果的に、単純に同じAZ内にインスタンスを配置した場合と比べ、拡張ネットワーキングのみ、プレイスメントグループのみでも優位性はありますが、両方を有効にすることで平均で 0.385 ms -> 0.157 ms とレイテンシは半分以下に改善しています。

拡張ネットワーキングは前述のように、AmazonLinuxの対応インスタンスタイプではデフォルト有効ですが、RedHat/CentOS/Ubuntuなどを利用中の場合には有効化することでパフォーマンス改善につながる場合もあると思います。

プレイスメントグループは同一AZに限られるなど使いどころが限られますが、拡張ネットワーキングと組み合わせて通信レイテンシ低減に効果を発揮することがわかりました。