色々なVPCピアリング接続でEC2インスタンス間のネットワークレイテンシを測定してみた
初めに
皆さんこんにちは、石橋です。今回は色々なVPCピアリング時のEC2インスタンス間のレイテンシを測定してみました。
*注意事項
測定値は公式の値ではなく、今回の環境における値ですので、あくまで参考に留めてください。
VPCピアリング接続とは
VPC ピアリング接続は、2 つの VPC 間でプライベートなトラフィックのルーティングを可能にするネットワーキング接続です。どちらの VPC のインスタンスも、同じネットワーク内に存在しているかのように、相互に通信できます。VPC ピアリング接続は、自分の VPC 間、別の AWS アカウントの VPC との間、または別の AWS リージョンの VPC との間に作成できます。
上記のように、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