🥥

ExpressRoute 仮想ネットワーク ゲートウェイ で ゾーン と SKU による レイテンシ の違い

2022/12/09に公開

ExpressRoute 利用時のレイテンシ、測定してみます!

ある日、なにげなく ExpressRoute ゲートウェイのSKU とパフォーマンスについてのドキュメントを見ていると...

image.png
https://learn.microsoft.com/ja-jp/azure/expressroute/expressroute-about-virtual-network-gateways#gwsku

おや.... レイテンシ についての言及がないな.... !?
運よく ExpressRoute の検証を行う機会を得られましたので、デプロイする ゾーン や SKU を変えながら、レイテンシの違いを調べてみました。
なお、本情報はあくまでも参考としていただきますようお願いいたします。

前置き1: ゾーン冗長ゲートウェイについて

Azure では可用性ゾーンという考え方があり、同一リージョン内の物理的に離れた場所での(ざっくり、データセンターレベルでの障害に対応可能な)可用性を提供しています。
可用性ゾーンを利用する際には、ゾーン1・ゾーン2・ゾーン3 という論理的に分割されたデプロイ先を指定して、ソリューションを展開できます。
これにより、仮に 1 つのゾーンに問題が発生した場合においても、残りの 2 つのゾーンによってサービスを継続するような設計が可能となっています。
 https://learn.microsoft.com/ja-jp/azure/reliability/availability-zones-overview

さて、ExpressRoute ゲートウェイ も可用性ゾーンに対応したサービスの一つです。
以下のSKUが、ゾーン冗長に対応しています。

  • ErGw1AZ
  • ErGw2AZ
  • ErGw3AZ

ゾーン冗長に対応したSKUの ExpressRoute ゲートウェイ は、デプロイする際に大きく2つの選択肢があります。
 ①ゾーンを指定せずにデプロイする
 ②ゾーンを指定してデプロイする

この違いについては以下のドキュメントで解説されていますが、
時々混乱してしまう方(私です…)もおられますので、それぞれどういったデプロイとなるのか、念のため確認しておきます。

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-zone-redundant-vnet-gateways

  • ①ゾーンを指定しないデプロイ
    ExpressRoute ゲートウェイ の ゾーン冗長対応SKU を、ゾーンを指定せずにデプロイした場合、インスタンスは複数のゾーンにまたがって展開されます。
    この場合のデプロイは、ゾーン冗長ゲートウェイのデプロイとなり、構成イメージは以下の通りとなっています。
    ゲートウェイが異なる Availability Zones に物理的かつ論理的に分離され、オンプレミス ネットワークの Azure への接続がゾーン レベルの障害から保護される形になります。

zone-redundant.png

  • ②ゾーンを指定するデプロイ
    一方、ExpressRoute ゲートウェイ の ゾーン冗長対応SKU を ゾーンを指定してデプロイを行った場合、単一ゾーンにインスタンスを展開できます。
    この場合のデプロイは、ゾーン ゲートウェイのデプロイとなり、構成イメージは以下の通りとなっています。

zonal.png

各ゾーン間は物理的に分離されているために、異なるゾーンに対しての通信は、一般的に、同一ゾーンに比べるとレイテンシが悪い傾向にあります。
ゾーン ゲートウェイはゾーンを指定してデプロイできることから、そういった異なるゾーン間での通信の発生を抑える設計ができるため、高いレイテンシが求められるシステムなどにおいて例えば近接配置グループなどと組み合わせて利用されるケースが多いのではないかと思います。

Azure Portal の画面上では、デプロイする際の [可用性ゾーン] の欄で選択が可能です。
プルダウンでゾーン冗長を選べば ①ゾーンを指定しないデプロイ になりますし、 特定のゾーンを選んだ場合は ②ゾーンを指定するデプロイ となります。
image.png

今回は、このゾーン指定有無によるレイテンシの違いがどの程度のものなのかも、計測してみます。

前置き2: ExpressRoute FastPath

ExpressRoute 回線とExpressRoute ゲートウェイの接続オプションに、FastPath というオプションがあります。
これが有効になっていると、ゲートウェイがバイパスされ、ネットワーク トラフィックが仮想マシンに直接送信されるというものです。
利用できる ExpressRoute ゲートウェイ の SKU は限られますが、こちらがレイテンシーが最も低くなることが期待できるオプションです。

  • Ultra Performance
  • ErGw3AZ

https://learn.microsoft.com/ja-jp/azure/expressroute/about-fastpath

なお、FastPath は「接続」のオプションです。
なんとなく ExpressRoute 回線 や ExpressRoute ゲートウェイ の設定を確認してしまいがちですが、お間違えなく。
既存の接続で有効化する場合には、Azure Portal上部検索窓から「接続」で検索するなどして、構成したい接続リソースを探します。
[設定] -> [構成] でチェックボックスをオンにして有効化できます。

image.png

https://learn.microsoft.com/ja-jp/azure/expressroute/expressroute-howto-linkvnet-portal-resource-manager#configure-expressroute-fastpath

検証構成 と 測定方法

検証構成は以下の通りです。
ExpressRoute ゲートウェイ の SKU は ErGw1AZ(Standard相当)、VMサイズは Standard_D2s_v3 (高速ネットワーク有効)で、デプロイ先ゾーン指定の有無でパターンを変え、検証(①~⑦)を行います。
また、ExpressRoute ゲートウェイ の SKU が HighPerformance、UltraPerformance、UltraPerformance + FastPath利用 のパターンについても検証(⑧~⑩)を行います。
なお、ER Circuit の帯域は 50Mbps、Location は Tokyo 2 での検証です。

  • ゾーン指定有無でのレイテンシ差
    image.png

  • SKUによるレイテンシ差
    image.png

レイテンシの測定は、 Ethr を用いて行います。

https://github.com/Microsoft/Ethr

非常に便利なツールで、レイテンシ以外にも帯域幅の測定等のネットワークパフォーマンス測定ができ、Windowsに限らずLinuxなどクロスプラットフォーム利用が可能なツールです。
上記リンクの中ほどにある [Download] から各OS向けのzipをダウンロード&展開するとすぐ利用でき、不要になった場合の削除もフォルダを消すだけで非常に簡単です。
なおWindows版を PowerShell でダウンロード & 解凍する場合は以下でOKです。

wget https://github.com/microsoft/ethr/releases/latest/download/ethr_windows.zip -OutFile ethr_windows.zip Expand-Archive
.\ethr_windows.zip -DestinationPath . 

Ethr を Azure上のVMs と Clinet PC それぞれにダウンロードします。Port 8888 で通信するため、ファイアウォールの受信許可が別途必要です。
Ethr は実行時にサーバーモードかクライアントモードかを指定しますが、今回、Azure VM側をサーバーモード、Clinet PC側を クライアントモードで起動して測定しました。
実行例としては

# サーバー側
.\ethr.exe –s
# クライアント側
# 10.10.0.4 に対しTCPでデータを60秒間送信し続け、その間のレイテンシを計測する。 1000回の送信毎に結果を出力する。
\ethr.exe –c 10.10.0.4 -p tcp -t l -d 60s

といった形で実行しており、これでクライアント側からサーバー側で待ち受けるEthrに対してデータを送信してレイテンシが計測できます。
以下が実行結果の例ですが、最初の1000回のデータ送信において、平均してレイテンシは 2.642 ms であり、 99%の範囲でレイテンシは 6.001ms に収まっていたことが示されています。

image.png

測定は、60秒間の測定を一度と、10秒間x4回の測定を行い、参考レイテンシと実施のたび結果がどの程度変化し得るのかを確認してみています。

結果

image.png

パターン ER Gateway VMs 60秒間 Latency Avg (ms) 複数回 Latency 測定した際の幅 Avg (ms)
SKU: ERGw1Az ゾーン指定なし ゾーン指定なし 2.79 - 2.95 2.22 - 3.17
SKU: ERGw1Az ゾーン指定なし ゾーン1 2.73 - 3.01 2.16 - 3.43
SKU: ERGw1Az ゾーン指定なし ゾーン2 2.46 - 2.64 2.53 - 3.20
SKU: ERGw1Az ゾーン指定なし ゾーン3 3.04 - 3.20 2.83 - 3.20

ゾーン冗長ゲートウェイの検証パターン(①~④)では、平均して概ね 2.5 – 3.5 ms 程度のレイテンシ という結果が得られましたが、測定を実施するたびに測定結果にブレが見られました。(結果詳細を参照)
ERGateway を ゾーン指定なし(ゾーン冗長)でデプロイしている場合、ERGateway は複数ゾーンにデプロイされている状態となっています。
Ethrによる計測の都度、どのゾーンにある ERGatewayインスタンス を経由するかが変動するため、計測を実施するたびに結果が変動したと考えられます。

パターン ER Gateway VMs 60秒間 Latency Avg (ms) 複数回 Latency 測定した際の幅 Avg (ms)
SKU: ERGw1Az ゾーン1 ゾーン1 2.10 - 2.28 2.03 - 2.28
SKU: ERGw1Az ゾーン2 ゾーン2 1.78 - 1.97 1.78 - 1.97
SKU: ERGw1Az ゾーン3 ゾーン3 1.92 - 2.19 1.85 - 2.23

続いて、ゾーン ゲートウェイの検証パターン(⑤~⑦)の結果です。
ERGateway を ゾーン指定 してデプロイした場合、ERGateway は 指定したゾーンにのみデプロイされている状態となります。
ゾーンを指定してデプロイした場合には、計測を複数回実施しても、レイテンシにはほぼ変動がありませんでした。
概ね 1.8 – 2.3 ms 程度のレイテンシであり、ゾーン指定しない場合よりも低レイテンシであることが確認できるかと思います。

なお、今回の結果では比較的ゾーン2がレイテンシが低くなっていますが、この結果には注意が必要です。
今回の検証では ExpressRoute circuits のLocation は Tokyo2 であり、他のLocation からでは、またレイテンシは違ったものになると思われます。
また、サブスクリプションによって “ゾーン2” が指す物理的なデータセンターは変わることから、サブスクリプションによっても違いが生じると思われます。

image.png

パターン ER Gateway VMs 60秒間 Latency Avg (ms) 複数回 Latency 測定した際の幅 Avg (ms)
SKU: ERGw1Az(Standard に相当)ゾーン指定なし ゾーン指定なし 2.79 - 2.95 2.22 - 3.17
SKU: High Performance ゾーン指定なし ゾーン指定なし 2.46 - 2.89 2.46 - 3.89
SKU: Ultra Performance ゾーン指定なし ゾーン指定なし 2.27 - 2.57 2.19 - 2.57
SKU: Ultra Performance + FastPath 使用 ゾーン指定なし ゾーン指定なし 1.65 - 1.92 1.65 - 2.10

Standard 相当の結果として、パターン①の結果も記載しています。
SKU を 高めることで、レイテンシも若干ではあるが改善しているように見えます。
とはいえ、検証パターン①~④の範囲に近く、レイテンシ観点からはそこまで大きな差は無いようもに見えますね。
ゾーン指定した場合(⑤~⑦)の方が高速です。

しかしながら、Ultra Performance で FastPath を有効化した場合については、ゾーン指定した場合よりもレイテンシが低い結果となっています。
FastPathであれば、ERGateway をバイパスし、 VMに対して直接トラフィックが転送されるため、今回の検証パターンの中では最も低レイテンシな結果が得られました。

結果(サマリ)

表が分かれていると見づらいかもしれませんので、最後に表をまとめたものを貼っておきます。

パターン ER Gateway VMs 60秒間 Latency Avg (ms) 複数回 Latency 測定した際の幅 Avg (ms)
SKU: ERGw1Az ゾーン指定なし ゾーン指定なし 2.79 - 2.95 2.22 - 3.17
SKU: ERGw1Az ゾーン指定なし ゾーン1 2.73 - 3.01 2.16 - 3.43
SKU: ERGw1Az ゾーン指定なし ゾーン2 2.46 - 2.64 2.53 - 3.20
SKU: ERGw1Az ゾーン指定なし ゾーン3 3.04 - 3.20 2.83 - 3.20
SKU: ERGw1Az ゾーン1 ゾーン1 2.10 - 2.28 2.03 - 2.28
SKU: ERGw1Az ゾーン2 ゾーン2 1.78 - 1.97 1.78 - 1.97
SKU: ERGw1Az ゾーン3 ゾーン3 1.92 - 2.19 1.85 - 2.23
SKU: High Performance ゾーン指定なし ゾーン指定なし 2.46 - 2.89 2.46 - 3.89
SKU: Ultra Performance ゾーン指定なし ゾーン指定なし 2.27 - 2.57 2.19 - 2.57
SKU: Ultra Performance + FastPath 使用 ゾーン指定なし ゾーン指定なし 1.65 - 1.92 1.65 - 2.10

今回の検証では
 FastPath 使用 > ゾーン ゲートウェイ > ゾーン冗長ゲートウェイ Ultra Performance > High Performance > Standard
という順当な結果となりました。
環境によって異なりますので、ご参考まで。

結果(詳細)

以下には検証の結果をそのまま載せておきます。

ER Gateway をゾーン指定せずにデプロイした場合、複数回(10秒 x 4回)のレイテンシー測定結果がブレる傾向にあることが確認できます。
また、1回の測定の範囲では、そこまで大きなレイテンシーの変動があるわけではないこともわかります。
なお各検証パターンにおける 99パーセンタイル 及び 99.9パーセンタイル での最大/最少レイテンシーを確認し、概ねどういった範囲にレイテンシーが収まりそうかが見えるようにしてあります。

  • パターン① ERGateway SKU: ERGw1Az ゾーン指定なし / VMs ゾーン指定なし
    image.png

  • パターン② ERGateway SKU: ERGw1Az ゾーン指定なし / VMs ゾーン1
    image.png

  • パターン③ ERGateway SKU: ERGw1Az ゾーン指定なし / VMs ゾーン2
    image.png

  • パターン④ ERGateway SKU: ERGw1Az ゾーン指定なし / VMs ゾーン3
    image.png

  • パターン⑤ ERGateway SKU: ERGw1Az ゾーン1 / VMs ゾーン1
    image.png

  • パターン⑥ ERGateway SKU: ERGw1Az ゾーン2 / VMs ゾーン2
    image.png

  • パターン⑦ ERGateway SKU: ERGw1Az ゾーン3 / VMs ゾーン3
    image.png

  • パターン⑧ ERGateway SKU: High Performance ゾーン指定なし / VM ゾーン指定なし
    image.png

  • パターン⑨ ERGateway SKU: Ultra Performance ゾーン指定なし / VM ゾーン指定なし
    image.png

  • パターン⑩ ERGateway SKU: Ultra Performance + FastPath ゾーン指定なし / VM ゾーン指定なし
    image.png

参考

https://www.attokyo.co.jp/connectivity/cloudlab.html

https://learn.microsoft.com/ja-jp/azure/expressroute/expressroute-about-virtual-network-gateways

https://learn.microsoft.com/ja-jp/azure/expressroute/about-fastpath

https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/management/azure-subscription-service-limits?toc=%2Fazure%2Fexpressroute%2Ftoc.json#expressroute-gateway-performance-limits

https://github.com/Microsoft/Ethr

Microsoft (有志)

Discussion