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

初めに

皆さんこんにちは、石橋です。今回は色々な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の応答時間を表にまとめました。

それぞれ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