Zenn
🐯

AWS ⇔ Google Cloud 間で Cross-Cloud Interconnect のパフォーマンスを測定してみた

2023/07/07に公開
AWS
network
Google Cloud
VPC
Cloud Interconnect
tech

はじめに

こんにちは、クラウドエースでSREディビジョンに所属している Shanks と申します。

2023/06/01 に Cross-Cloud Interconnect（以降、CCIと呼ぶ。）という Cloud Interconnect の派生機能が新たに追加されました。
これまで、CCI の概要をまとめた記事と、実際に構築をして手順と注意点を確認した記事を、それぞれ下記で公開してきました。

https://zenn.dev/cloud_ace/articles/cross-cloud-interconnect-ga
https://zenn.dev/cloud_ace/articles/cross-cloud-interconnect-howto-build

この記事では、上記の記事の付録として、実際にパフォーマンステストを行った結果をお伝えいたします。

検証概要

冒頭で記載したとおり、CCI の概要についてはドキュメントベースでまとめていますので、ここではパフォーマンステストに焦点をあてて検証をします。

方針

検証の方針は以下の通りとします。

  • AWS - Google Cloud 間で CCI を構成する
    • 構成は HA 構成とする
    • 東京リージョンを利用する
    • 契約する帯域幅は 10 Gbps とする
  • EC2 - GCE をエンドポイントとし、通信を発生させる
  • VPN 接続時との比較を行う
  • 各テストは5分間ずつ実施する

確認点

確認点は以下の通りとします。

確認観点 利用ツール 備考
疎通確認 ・ping
レイテンシ測定 ・ping
・Netperf
スループット測定 ・Iperf3 CCI の性能を最大限引き出すため、5つのコネクションを並列実行とする

環境情報

検証に用いる環境は以下の通りとします。

  • マシンスペック
    • EC2 インスタンス（サーバ）：m5n.large
    • GCE インスタンス（クライアント）：n2-standard-8

https://aws.amazon.com/jp/ec2/instance-types/m5/
https://cloud.google.com/compute/docs/general-purpose-machines?hl=ja#n2_series

  • OS
    • EC2 インスタンス（サーバ）：Ubuntu 20.04 LTS
    • GCE インスタンス（クライアント）：Ubuntu 20.04 LTS 
$ uname -v
#44~20.04.1-Ubuntu SMP Fri Jun 9 10:48:56 UTC 2023
  • コマンドバージョン
    • iperf3： 3.7
    • netperf： 2.6.0 
$ iperf3 -v
iperf 3.7 (cJSON 1.5.2)
Linux cci-aws-ubu 5.15.0-1036-gcp #44~20.04.1-Ubuntu SMP Fri Jun 9 10:48:56 UTC 2023 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication

$ netperf -V
Netperf version 2.6.0

アーキテクチャ

検証環境として以下の構成図のとおり環境を構成します。
環境の構成方法については、前述の記事をご確認ください。

CCI VPN
architecture
CCI 構成図 		vpn-architecture
VPN 構成図

検証結果

疎通確認

Compute Engine インスタンス（Google Cloud 側、以降 GCE と呼ぶ。）から EC2 インスタンス（AWS 側、以降 EC2 と呼ぶ。）へ ping を送り、想定どおりパケットが到達するかを確認します。
このとき、通常通り 0% packet loss と返ってくれば成功です。
CCI で成功したら、VPN 側でも同様に疎通確認を実施します。

$ ping -c 4 ${EC2の内部IPアドレス}
PING ${EC2の内部IPアドレス} (${EC2の内部IPアドレス}) 56(84) bytes of data.
64 bytes from ${EC2の内部IPアドレス}: icmp_seq=1 ttl=62 time=x.xx ms
64 bytes from ${EC2の内部IPアドレス}: icmp_seq=2 ttl=62 time=x.xx ms
64 bytes from ${EC2の内部IPアドレス}: icmp_seq=3 ttl=62 time=x.xx ms
64 bytes from ${EC2の内部IPアドレス}: icmp_seq=4 ttl=62 time=x.xx ms

--- ${EC2の内部IPアドレス} ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time xxxxxxms
rtt min/avg/max/mdev = x.xxx/x.xxx/x.xxx/x.xxx ms

レイテンシ測定結果

AWS - Google Cloud 間のレイテンシを測定します。
測定方法としては、ping と netperf を用いて 300 sec （5分間）の計測を実施します。

まずはじめに、ping を用いた計測を実施します。

$ ping -c 300 ${EC2の内部IPアドレス}
PING ${EC2の内部IPアドレス} (${EC2の内部IPアドレス}) 56(84) bytes of data.
64 bytes from ${EC2の内部IPアドレス}: icmp_seq=1 ttl=62 time=x.xx ms
64 bytes from ${EC2の内部IPアドレス}: icmp_seq=2 ttl=62 time=x.xx ms
64 bytes from ${EC2の内部IPアドレス}: icmp_seq=3 ttl=62 time=x.xx ms
64 bytes from ${EC2の内部IPアドレス}: icmp_seq=4 ttl=62 time=x.xx ms

===== 省略 =====

--- ${EC2の内部IPアドレス} ping statistics ---
300 packets transmitted, 300 received, 0% packet loss, time xxxxxxms
rtt min/avg/max/mdev = x.xxx/x.xxx/x.xxx/x.xxx ms

ping
ping測定結果

結果は、CCI のほうが低レイテンシで通信ができることがわかりました。
これは、パブリックインターネットの経路上にある様々な要因でレイテンシに影響を与えられている VPN 接続に対し、物理接続を専用に確保している CCI のほうがより低遅延で通信できることを表しています。

続いて、netperf を用いた計測を実施します。

$ netperf -H ${EC2の内部IPアドレス} -p 11256 -l 300 -t TCP_RR -v 2 -- -o min_latency,mean_latency,max_latency,stddev_latency,transaction_rate
Minimum Latency Mean Latency Maximum Latency Stddev Latency Transaction Rate Tran
CCI/VPN の性能比 netperf_minimum_latency
0.41倍 		netperf_mean_latency
0.42倍 		netperf_maximum_latency
0.30倍 		netperf_stddev_latency
0.20倍 		netperf_transaction_rate
2.40倍

結果は、ping と同様に CCI のほうが低レイテンシで通信ができることがわかりました。
また、CCI では最大レイテンシ値についても低い結果でした。

スループット測定結果

AWS - Google Cloud 間のスループットを測定します。
測定方法としては、iperf3 を用いて 300 sec （5分間）の計測を実施します。
また、iperf3では並列試験が可能ですので、CCI の性能を最大限引き出すため、5つのコネクションを並列実行します。

確認できるそれぞれの項目を整理します。

項目 説明 備考
Transfer 秒間の転送バイト数
Bitrate 帯域幅
Retr 再送となったTCP セグメント数、再送回数が少ないほど回線の品質が高い
Cwnd 輻輳ウィンドウサイズ、輻輳を検知した際に値を小さくすることで輻輳を低減させる 輻輳検知の回数が少ないほど振れ幅が小さくなる
Ave-Cwnd 各コネクションの平均輻輳ウィンドウサイズ マルチコネクションのため手動算出
Min-Cwnd 各コネクションの最小輻輳ウィンドウサイズ マルチコネクションのため手動算出
Max-Cwnd 各コネクションの最大輻輳ウィンドウサイズ マルチコネクションのため手動算出 
$ iperf3 -c ${EC2の内部IPアドレス} -t 300 -p 5102 -P 5
Transfer Bitrate Retr
Transfer
Transfer測定結果 		Bitrate
Bitrate測定結果 		Retr
Retr測定結果
Ave-Cwnd Min-Cwnd Max-Cwnd
Ave-Cwnd
Ave-Cwnd測定結果 		Min-Cwnd
Min-Cwnd測定結果 		Max-Cwnd
Max-Cwnd測定結果

結果は、以下の通りとなりました。

  • Transfer
    • VPN に対し、CCI は概ね 1.33倍と CCI のほうがより大容量のデータ転送に成功している
    • CCI がほぼ一定の値で留まっているのに対し、VPN は振れ幅が大きくパフォーマンスが安定していない
  • Bitrate
    • VPN に対し、CCI は概ね 1.30倍と CCI のほうがより広い帯域幅を利用できている
    • CCI がほぼ一定の値で留まっているのに対し、VPN は振れ幅が大きくパフォーマンスが安定していない
  • Retr
    • VPN に対し、CCI は概ね 1.20倍と VPN のほうが再送セグメント数は少ない
  • Cwnd
    • VPN に比べ CCI のほうが振れ幅が小さく、輻輳制御が働いている回数（輻輳検知の回数）が少ない

おまけ

追加検証として、既存の検証結果に影響を与える要素があったかを為念で確認しました。

MTU

VPC と VLAN アタッチメントのMTUを変更することでスループット向上が望めるかを確認しました。

  • VPC：デフォルト値 1460 → 1500 へ変更
  • VLAN アタッチメント：デフォルト値 1440 → 1500 へ変更
Transfer Bitrate Retr
Transfer
Transfer測定結果 		Bitrate
Bitrate測定結果 		Retr
Retr測定結果
Ave-Cwnd Min-Cwnd Max-Cwnd
Ave-Cwnd
Ave-Cwnd測定結果 		Min-Cwnd
Min-Cwnd測定結果 		Max-Cwnd
Max-Cwnd測定結果

結論として、MTU を 1460（VPC のデフォルト値）→ 1500 へ変更した場合であっても大きなパフォーマンス向上は見られませんでした。
それどころか、輻輳制御がより多く発生する結果を記録しました。

また、Cloud VPN では MTU を変更することができない制約があります。
そのため、VPN 接続では検証不可としました。

ジャンボフレーム

february-14-2024-release-notes

各クラウドサービスではジャンボフレームに対応していることがあります。
Google Cloud では最大 8896 バイトまで拡張することができ、より効率の良い大容量通信が可能です。
しかし、MTU は双方で同じ値を示すのが最適ですので、対向となるパブリッククラウドの制限は別途ご確認ください。

まとめ

本記事では、新たに Cloud Interconnect へ追加された Cross-Cloud Interconnect のパフォーマンステスト測定結果についてまとめました。
本記事がマルチクラウド構成を検討されている方にとって一助となれば幸いです。

最後に、全体の検証結果をまとめます。

  • CCI のほうが全体的なパフォーマンスが高いことがわかった
    • 低遅延のデータ転送を記録した
    • 広帯域幅のデータ転送を記録した
    • 輻輳制御の発生回数が少なく安定した結果を記録した
  • MTU はパフォーマンス向上に大きくは関与しなかった

Discussion