色々なVPCピアリング接続でEC2インスタンス間のネットワークレイテンシを測定してみた

マルチAZ、マルチリージョン間のVPCピアリング接続の中のEC2インスタンス間で、どれくらいレイテンシが出るのか、実装して測定してみました。
2020.05.07

初めに

皆さんこんにちは、石橋です。今回は色々なVPCピアリング時のEC2インスタンス間のレイテンシを測定してみました。

*注意事項

測定値は公式の値ではなく、今回の環境における値ですので、あくまで参考に留めてください。

VPCピアリング接続とは

VPC ピアリング接続は、2 つの VPC 間でプライベートなトラフィックのルーティングを可能にするネットワーキング接続です。どちらの VPC のインスタンスも、同じネットワーク内に存在しているかのように、相互に通信できます。VPC ピアリング接続は、自分の VPC 間、別の AWS アカウントの VPC との間、または別の AWS リージョンの VPC との間に作成できます。

AWS公式ユーザーガイドより

上記のように、VPCピアリング接続とは、VPC同士を接続するサービスであり、リージョン間・アカウント間のVPCも接続可能です。接続の作成自体は無料ですが、VPC間の通信には費用がかかります。

実際の構築方法は、こちらのブログが参考になります。

構成図

測定の為に、以下のような構成を作りました。

今回測定する通信のケースは、以下の5ケースです。

  • caseA:同一AZ、別サブネット(VPCピアリング接続なし)
  • caseB:同一AZ、別サブネットのVPCピアリング接続
  • caseC:同一リージョン、別AZのVPCピアリング接続
  • caseD:別リージョンのVPCピアリング接続(TokyoからSeoul)
  • caseE:別リージョンのVPCピアリング接続(TokyoからLondon)

各ケースにおいて、VPC-AのprivateサブネットにあるEC2インスタンスから、対象サブネット内にあるEC2インスタンスにpingし、その応答時間でレイテンシを測定しました。

測定結果

以下がそれぞれの結果です。

caseA:同一AZ、別サブネット(VPCピアリング接続なし)

[ec2-user@ip-10-0-1-97 ~]$ ping -c 10 10.0.0.161
PING 10.0.0.161 (10.0.0.161) 56(84) bytes of data.
64 bytes from 10.0.0.161: icmp_seq=1 ttl=255 time=0.413 ms
64 bytes from 10.0.0.161: icmp_seq=2 ttl=255 time=0.440 ms
64 bytes from 10.0.0.161: icmp_seq=3 ttl=255 time=0.429 ms
64 bytes from 10.0.0.161: icmp_seq=4 ttl=255 time=0.479 ms
64 bytes from 10.0.0.161: icmp_seq=5 ttl=255 time=0.419 ms
64 bytes from 10.0.0.161: icmp_seq=6 ttl=255 time=0.394 ms
64 bytes from 10.0.0.161: icmp_seq=7 ttl=255 time=0.496 ms
64 bytes from 10.0.0.161: icmp_seq=8 ttl=255 time=0.461 ms
64 bytes from 10.0.0.161: icmp_seq=9 ttl=255 time=0.508 ms
64 bytes from 10.0.0.161: icmp_seq=10 ttl=255 time=0.393 ms

--- 10.0.0.161 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9195ms
rtt min/avg/max/mdev = 0.393/0.443/0.508/0.041 ms

caseB:同一AZ、別サブネットのVPCピアリング接続

[ec2-user@ip-10-0-1-97 ~]$ ping -c 10 10.10.0.121
PING 10.10.0.121 (10.10.0.121) 56(84) bytes of data.
64 bytes from 10.10.0.121: icmp_seq=1 ttl=255 time=0.419 ms
64 bytes from 10.10.0.121: icmp_seq=2 ttl=255 time=0.439 ms
64 bytes from 10.10.0.121: icmp_seq=3 ttl=255 time=0.360 ms
64 bytes from 10.10.0.121: icmp_seq=4 ttl=255 time=0.373 ms
64 bytes from 10.10.0.121: icmp_seq=5 ttl=255 time=0.405 ms
64 bytes from 10.10.0.121: icmp_seq=6 ttl=255 time=0.435 ms
64 bytes from 10.10.0.121: icmp_seq=7 ttl=255 time=0.444 ms
64 bytes from 10.10.0.121: icmp_seq=8 ttl=255 time=0.408 ms
64 bytes from 10.10.0.121: icmp_seq=9 ttl=255 time=0.440 ms
64 bytes from 10.10.0.121: icmp_seq=10 ttl=255 time=0.393 ms

--- 10.10.0.121 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9198ms
rtt min/avg/max/mdev = 0.360/0.411/0.444/0.035 ms

caseC:同一リージョン、別AZのVPCピアリング接続

[ec2-user@ip-10-0-1-97 ~]$ ping -c 10 10.11.0.197
PING 10.11.0.197 (10.11.0.197) 56(84) bytes of data.
64 bytes from 10.11.0.197: icmp_seq=1 ttl=255 time=2.70 ms
64 bytes from 10.11.0.197: icmp_seq=2 ttl=255 time=2.68 ms
64 bytes from 10.11.0.197: icmp_seq=3 ttl=255 time=2.69 ms
64 bytes from 10.11.0.197: icmp_seq=4 ttl=255 time=2.69 ms
64 bytes from 10.11.0.197: icmp_seq=5 ttl=255 time=2.61 ms
64 bytes from 10.11.0.197: icmp_seq=6 ttl=255 time=2.74 ms
64 bytes from 10.11.0.197: icmp_seq=7 ttl=255 time=2.65 ms
64 bytes from 10.11.0.197: icmp_seq=8 ttl=255 time=2.68 ms
64 bytes from 10.11.0.197: icmp_seq=9 ttl=255 time=2.69 ms
64 bytes from 10.11.0.197: icmp_seq=10 ttl=255 time=2.67 ms

--- 10.11.0.197 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9017ms
rtt min/avg/max/mdev = 2.617/2.684/2.745/0.064 ms

caseD:別リージョンのVPCピアリング接続(TokyoからSeoul)

[ec2-user@ip-10-0-1-97 ~]$ ping -c 10 10.20.0.141
PING 10.20.0.141 (10.20.0.141) 56(84) bytes of data.
64 bytes from 10.20.0.141: icmp_seq=1 ttl=255 time=34.8 ms
64 bytes from 10.20.0.141: icmp_seq=2 ttl=255 time=34.8 ms
64 bytes from 10.20.0.141: icmp_seq=3 ttl=255 time=34.9 ms
64 bytes from 10.20.0.141: icmp_seq=4 ttl=255 time=34.8 ms
64 bytes from 10.20.0.141: icmp_seq=5 ttl=255 time=34.8 ms
64 bytes from 10.20.0.141: icmp_seq=6 ttl=255 time=34.8 ms
64 bytes from 10.20.0.141: icmp_seq=7 ttl=255 time=34.8 ms
64 bytes from 10.20.0.141: icmp_seq=8 ttl=255 time=34.7 ms
64 bytes from 10.20.0.141: icmp_seq=9 ttl=255 time=35.7 ms
64 bytes from 10.20.0.141: icmp_seq=10 ttl=255 time=34.8 ms

--- 10.20.0.141 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9015ms
rtt min/avg/max/mdev = 34.784/34.939/35.764/0.312 ms

caseE:別リージョンのVPCピアリング接続(TokyoからLondon)

[ec2-user@ip-10-0-1-97 ~]$ ping -c 10 10.30.0.208
PING 10.30.0.208 (10.30.0.208) 56(84) bytes of data.
64 bytes from 10.30.0.208: icmp_seq=1 ttl=255 time=209 ms
64 bytes from 10.30.0.208: icmp_seq=2 ttl=255 time=210 ms
64 bytes from 10.30.0.208: icmp_seq=3 ttl=255 time=209 ms
64 bytes from 10.30.0.208: icmp_seq=4 ttl=255 time=209 ms
64 bytes from 10.30.0.208: icmp_seq=5 ttl=255 time=209 ms
64 bytes from 10.30.0.208: icmp_seq=6 ttl=255 time=209 ms
64 bytes from 10.30.0.208: icmp_seq=7 ttl=255 time=209 ms
64 bytes from 10.30.0.208: icmp_seq=8 ttl=255 time=209 ms
64 bytes from 10.30.0.208: icmp_seq=9 ttl=255 time=209 ms
64 bytes from 10.30.0.208: icmp_seq=10 ttl=255 time=209 ms

--- 10.30.0.208 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 209.359/209.492/210.223/0.595 ms

測定結果(表とグラフ)

それぞれのcaseの応答時間を表にまとめました。

case min avg max mdev
caseA 0.393 0.443 0.508 0.041
caseB 0.360 0.411 0.444 0.035
caseC 2.617 2.684 2.745 0.064
caseD 34.784 34.939 35.764 0.312
caseE 209.359 209.492 210.223 0.595

それぞれ10回の応答時間をグラフ化してみます。

caseA,B,CとcaseD,caseEが離れすぎているので、縦軸を対数目盛にします。

考察

caseAとcaseBの比較

今回の場合、caseA(平均:0.443ms)とcaseB(平均:0.411ms)のレイテンシはそれほど変わりがありませんでした。 このことから、同一AZ間の通信であれば、VPCピアリング接続をする場合としない場合(単純に同じVPC内)では、それほど通信速度に変わりがないことが伺えます。

caseBとcaseCの比較

caseB(平均:0.411ms)とcaseC(平均:2.684ms)の比較から同一リージョンでも、AZが異なると同一AZの場合に比べてレイテンシが発生することが伺えます。

caseC,caseD,caseEの比較

caseC(平均:2.684ms)、caseD(平均:34.939ms)、caseE(平均:209.492ms)を比較すると、やはり同一リージョンでのVPCピアリング接続よりも、マルチリージョンでのVPCピアリング接続の方がレイテンシが高まり、日本から遠いほど(今回の場合だとソウルよりロンドンの方が)レイテンシが高まることが伺えます。

同一VPC間のEC2のネットワークパフォーマンスに影響する要因

EC2インスタンスの物理的近接性

  • 同一AZ内のインスタンスは地理的に最も近く、同一リージョンの別AZのインスタンス、同じ大陸の異なるリージョンのインスタンス、別大陸のリージョンのインスタンスの順で遠くなります。物理的な距離が生まれることでレイテンシが発生することが、今回の測定で確認することができました。

EC2のインスタンスサイズ

  • 通常インスタンスサイズが大きいほど、同じタイプのインスタンスサイズが小さい場合よりも、ネットワークパフォーマンスが向上します。 今回はネットワークパフォーマンスが「低~中」とされているt2.microのインスタンスを利用したため、他のインスタンスファミリーやインスタンスサイズを使用すると結果は変わってくるはずです。

拡張ネットワーキング、プレイスメントグループの有無

  • EC2インスタンス起動時にオプションとして、拡張ネットワーキングやプレイスメントグループを有効にすることで、高いネットワークパフォーマンスを実現することができます。以下のブログが参考になります。

最後に

今回様々なVPCピアリング接続を実装して、実際にレイテンシを測定してみた結果、AZやリージョンの地理的距離感を感じることができました。やっぱり、理論的には分かっていても、実際に手を動かして、動作を確認することで理解が深まりますね。また、VPCピアリング接続の有無で大きなレイテンシの差がなかったこと(caseAとcaseBの比較より)は意外でした。 この記事が誰かの参考になれば幸いです。

参考

https://aws.amazon.com/jp/premiumsupport/knowledge-center/network-throughput-benchmark-linux-ec2/

https://aws.amazon.com/jp/ec2/instance-types/

https://aws.amazon.com/jp/premiumsupport/knowledge-center/enable-configure-enhanced-networking/

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/placement-groups.html