Azure のリージョン間で接続するような要件はよくあると思いますが、リージョン間で接続する方法は様々な方法があります。
以下の 5 つの方法が利用可能な方法となりますが、どの手法が最も高速で低コストなのかは明確な情報を確認することができません。
- パブリック IP アドレス経由
- グローバル VNet ピアリング経由
- Private Link 経由
- VPN 経由
- ExpressRoute 経由 (Private Peering)
そこで実際にレイテンシ、スループットを検証し、利用にともなう料金を確認した結果を記載しております。
マイクロソフトの公式見解ではありませんが、検証のなかで確認できた結果として参考情報程度に見てもらえたらと思います。
検証前の考察
以下の公開ドキュメントからもリージョン間の接続では VNet ピアリングの方が高帯域、低レイテンシで推奨されていることが読み取れます。
仮想ネットワーク ピアリングは、低待機時間、高帯域幅の接続を実現します。 パスにゲートウェイが存在しないため、余分なホップがなく、低遅延の接続が保証されます。 これは、リージョン間のデータ レプリケーションやデータベース フェールオーバーなどのシナリオで役立ちます。
仮想ネットワークからのトラフィックは、配信元の Azure リージョンを出発し、ピアリングの場所にある MSEE デバイスを通過します。 その後、そのトラフィックは Microsoft のグローバル ネットワークを経由して、宛先の Azure リージョンに到達します。 VNet ピアリングでは、MSEE デバイスの追加ホップなしで、Microsoft のグローバル ネットワークを使用して、配信元の Azure リージョンから宛先の Azure リージョンにトラフィックが直接流れます。 余分なホップがデータ パスに存在しなくなったため、待機時間が短くなり、アプリケーションとネットワーク トラフィックの全体的なエクスペリエンスが向上します。
そのため、以下のような順序ではないかと推測しています。VNet ピアリング、パブリック IP、Private Link についてはなんとなくの予想で根拠はありません。
グローバル VNet ピアリング > パブリック IP > Private Link > ExpressRoute > VPN
検証の構成
以下の図のように 5 つの経路で東日本と米国東部の VM 同士を接続できるようにしておきます。VM の構成情報は以下です。
- Ubuntu 20.04 LTS
- サイズ Ds2_v3 (想定帯域幅 1Gbps)
- Premium SSD (OS)
- 高速ネットワーク無効
- 可用性セット、ゾーンなし
レイテンシ確認
以下の図から東日本、米国東部のレイテンシは 155msec 程度であることがわかります。
https://docs.microsoft.com/ja-jp/azure/networking/azure-network-latency#may-2021-round-trip-latency-figures
以下の情報を元に sockpert にてレイテンシを測定してみます。
https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-test-latency#test-vms-that-are-running-linux
sockpertf を導入し、以下のコマンドをそれぞれの VM で実行します。
サーバー側
sockperf sr --tcp -i 10.1.0.5 -p 12345
クライアント側
# sockperf ping-pong -i 10.1.0.5 --tcp -m 350 -t 101 -p 12345 --full-rtt
| 経路 | サマリ1 | サマリ2 | サマリ3 | Max (usec) | Min (usec) | Avg (msec) | |
|---|---|---|---|---|---|---|---|
| 1 | VNet Peering | 155460.631 | 155538.908 | 158239.736 | 160205.593 | 155105.229 | 156 |
| 2 | Public IP | 155723.336 | 162649.484 | 155775.021 | 171361.763 | 155198.143 | 158 |
| 3 | Private Link | 163260.164 | 163154.590 | 163288.061 | 198571.154 | 162729.371 | 163 |
| 4 | VPN | 170392.194 | 167775.068 | 167386.841 | 575189.968 | 158129.839 | 169 |
| 5 | ExpressRoute | 160862.487 | 160731.634 | 160378.854 | 170350.545 | 159647.335 | 161 |
結果だけを見てみると、公開情報の 155msec と大きな背離もなく、レイテンシの順位としても大差はついておりませんが、VPN はばらつきが大きく、レイテンシも少しだけ大きくなっていました。
Azure VPN Gateway では IPsec プロトコルにより VPN トンネルを張りますが、トンネルを張る経路としては VPN Gateway の Public IP を経由するため、ホップ数が増えたことと、IPsec プロトコルのオーバーヘッドが影響していると考えられます。
スループット確認
NTTTCP を使ってスループットを測定してみます。
ntttcp を導入し、以下のコマンドをそれぞれの VM で実行します。
サーバー側
ntttcp -r -t 180 -p 12345
クライアント側
ntttcp -s10.1.0.5 -t 180 -p 12345
| 経路 | サマリ1 | サマリ2 | サマリ3 | Avg (Mbps) | |
|---|---|---|---|---|---|
| 1 | VNet Peering | 906.39 | 906.39 | 906.43 | 906 |
| 2 | Public IP | 946.43 | 946.28 | 946.29 | 946 |
| 3 | Private Link | 909.37 | 907.58 | 909.22 | 909 |
| 4 | VPN | 896.29 | 898.05 | 897.36 | 897 |
| 5 | ExpressRoute | 911.85 | 911.84 | 911.83 | 911 |
こちらの結果も VPN だけは少し性能低下が大きいように見えます。また、理由はわかりませんが、Public IP だけ顕著に性能が良かったです。1Gbps が VM サイズから想定される帯域なので、理想的な結果に近い結果が得られていると言えると思いますが、構成や測定方法によっては異なる結果が得られる可能性はあります。
料金
それぞれの経路で東日本から米国東部に一か月間で計 300GB のデータ転送を行った場合にどのくらいの料金がかかるかを参考情報として算出してみます。(202208 時点)
| 経路 | 1GBあたりの追加料金 (円) | 料金 (円) | |
|---|---|---|---|
| 1 | VNet Peering | 17.16 (In+Out) | (3,705 (JPE>EUS Out [12.35/GB]) + 1,440 (JPE>EUS In [4.8/GB])) = 5,148 |
| 2 | Public IP | 10.983 | 501 (Std) x2 + 3,240 (Bandwidth 10.983/GB) = 4,242 |
| 3 | Private Link | 13.543 (Out+LB+Bandwidth) | 1,002 (PE) + 412 (Out Data 1.37/GB) + 2,505 (Std LB rule) + 206 (LB Data 0.686/GB) + 3,240 (Bandwidth 10.983/GB) = 7,365 |
| 4 | VPN | 12.355 | 125,263 (vpngw3) x2 + 3,706 (12.355/GB) = 250,832 |
| 5 | ExpressRoute | 6.864 | 258,901 (ER Prem 1G 従量) + 2,060 (Zone2 Out Data 6.864/GB) + 49,103 (ERGW High) x2 = 359,167 |
総論
測定方法や構成によっては異なる結果になる可能性はありますが、今回の検証結果をまとめると以下です。
| 経路 | レイテンシ | スループット | GB あたりの転送費用 | 総費用 | |
|---|---|---|---|---|---|
| 1 | VNet Peering | ◎ | ○ | △ | ○ |
| 2 | Public IP | ◎ | ◎ | ○ | ○ |
| 3 | Private Link | ○ | ○ | ○ | ○ |
| 4 | VPN | △ | △ | ○ | △ |
| 5 | ExpressRoute | ○ | ○ | ◎ | △ |
要件次第なので、どの手法も善し悪しがあり適材適所にすべきではありますが、特別な要件がない場合、Public IP アドレスが最も安定した性能かつ低コストと言えます。
セキュリティ要件等で Pubilc IP は原則 NG である場合、転送量に応じた費用と構成を考慮したうえで、要件に応じて VNet Peering/Private Link を利用するのがよいでしょう。すでに ExpressRoute/VPN の環境が構成されている場合は、要件に応じて ExpressRoute/VPN を選択することもできると思います。