【Azure】仮想マシンのネットワーク帯域幅の上限を測定してみた

Azure VirtualMachine

Azureの仮想マシンは仮想マシンのサイズごとにネットワーク帯域幅の利用上限が決まっていますが「実際に利用できる帯域幅はどのくらいなのか?」が気になったのでiperfを利用して調べてみました。

今回は「Standard DS5 v2」という仮想マシンサイズを利用して調べてみました。

Standard DS5 v2」の帯域幅は公開されている情報では12,000Mbpsとなっています。

広告

今回の検証構成

今回の検証構成は以下の通りです。

perfを利用して仮想マシンのネットワーク帯域幅の上限を測定した際の構成図

仮想マシンの通信として以下の3つの通信経路で調べてみました。

iperfの準備

各仮想マシンにiperfをダウンロードします。
以下のリンク先からダウンロード可能です。

iPerf - Download iPerf3 and original iPerf pre-compiled binaries
iPerf3 binaries for Windows, Linux, MacOS X

今回はwindowsOSを利用したので「Windows 64 bits」の最も新しいバージョンをダウンロードして測定しました。

ネットワーク帯域幅の上限を測定する

iperf3を実行して測定していきます。

iperfの実行(サーバ側)

以下のコマンドを入力してクライアントからトラフィックが流れてくるのを待ちます。

iperf3 -s

コマンドを実行すると以下のような画面となり、デフォルトでは5201ポートで待ち受けます。

サーバ側の画面

仮想マシンのOS内のFWで、今回利用するポートを許可することが必要になりますのでその点だけ注意してください。

iperfの実行(クライアント側)

以下のコマンドを入力してクライアントからトラフィックを流します。

iperf3 -c 10.2.0.4

このコマンドを実行した直後から通信が流れます。

測定結果

①同一Vnet間(異なるsubnet間)での通信について

結果は以下のようになりました。

①同一Vnet間(異なるsubnet間)での通信についての測定結果

856Mbps」出ていますが、上限値である[12,000Mbps]には届いていないのでオプション[-P]を指定し、[実行する並列クライアント スレッドの数]を増やして上限値に到達するまで実行してみます。

「‐P 16」での実行結果
「‐P 16」での実行結果1
「‐P 16」での実行結果2

7.98Gbps ≒ 7,980Mbps」なので、まだスレッド数を増やして試すことができそうです。

「-P 32」での実行結果
「-P 32」での実行結果1
「-P 32」での実行結果2

11.2Gbps ≒ 11,200Mbps」となり上限値にかなり近づきました。

その他の実行結果

その他いろんなスレッド数で試しましたが「-P 32」が最も上限値に近い数値となりました。

  • 「-P 28」:8.65 Gbits/sec
  • 「-P 40」:10.6 Gbits/sec
  • 「-P 48」:9.57 Gbits/sec
  • 「-P 64」:9.67 Gbits/sec

スレッド数をあげてしまうと、仮想マシン側の処理が間に合わないので正確な値が計測できないのではないかと思いました。

ですが、公開されている情報の90%以上の上限値まで帯域を利用できることは確認することができました。

Azureポータル上の仮想マシンの [メトリック] でもトラフィックが流れていることが確認できます。
以下はiperfのクライアントのVM-A2の [Network Out Total] のメトリックを確認してみました。

仮想マシンの[メトリック]の表示画面

上記は1分間の合計値までしか表示できないので、かなり大きなトラフィックが流れているように見えます。

Azureポータル上の[メトリック]からでは詳細な情報は取れなさそうであったので、あくまで参考程度に確認するのがいいのかもしれません。

②異なるVnet間でVnetpeeringを利用した通信について

「-P 32」のオプションをつけて実行し、「10.9Gbps ≒ 10,900Mbps」利用できることがわかりました。

②異なるVnet間でVnetpeeringを利用した通信についての実行結果1
②異なるVnet間でVnetpeeringを利用した通信についての実行結果2

①の結果に比べて、少しだけ利用できる帯域幅が少ない結果となりました。

念のため何回か実施してみましたが、平均しても②の結果はギリギリ11Gbpsに届かないくらいの結果ですが、①の結果は11Gbps以上の値が出ますので、この差は誤差ではなく明確にあることもわかりました。

Vnetpeeringをしているとはいえ、Vnetが異なるため距離的に少し遠くなることなどが影響しているのかもしれません。

③異なるVnet間でExpressRoute経由とした通信について

ExpressRouteは帯域100MbpsのSKUを利用しており、VPNGatewayは[Standard]を利用しているため帯域は1000Mbpsとなっています。

これらの制限もどう影響するのか含めて確認していきます。

③異なるVnet間でExpressRoute経由とした通信についての実行結果1
③異なるVnet間でExpressRoute経由とした通信についての実行結果2

結果は、①や②の結果より利用できる帯域幅が大幅に少ない1.40Gbps」でした。

VPNGatewayの帯域上限値よりも少し高い値となっていますが、VPNGatewayの帯域上限値に影響を受けているのかなと感じました。

逆に言うとExpressRouteの帯域上限は影響がないように見受けられます。

[追加検証1]ERの帯域を上げるとどうなるのか

念のためExpressRouteの帯域を1Gbpsとして再度計測してみました。

ERが1Gbpsである表示画面
[追加検証1]ERの帯域を上げるとどうなるのかの測定結果

結果は上記と同じ「1.40Gbps」でした。

これで、異なるVnet間の通信がExpressrouteを経由する場合には、ExpressRouteの帯域上限は影響がないということが分かりました。

[追加検証2]VPNGatewayの帯域を上げるとどうなるのか

今度はVPNGatewayの帯域を10Gbpsまで上げて再度測定します。

VPNGatewayのSKUを[Ultra Performance]として、ExpressRouteの帯域は1Gbpsのままとします。

VPNGWが[Ultra Performance]である表示画面
[追加検証2]VPNGatewayの帯域を上げるとどうなるのかの測定結果

結果は「9.83Gbps」で、[Ultra Performance]の上限値まで利用できることが分かりました。

なので、異なるVnet間の通信がExpressrouteを経由する場合には、VPNGatewayの帯域上限値に影響を受けるということが分かりました。

まとめ

結果をまとめると以下のようになりました。

  • 同一Vnet間(異なるsubnet間)で通信した場合、公開されている情報の90%以上の上限値まで帯域を利用できる
  • ②異なるVnet間でVnetpeeringを利用して通信した場合、公開されている情報の90%以上の上限値まで帯域を利用できるが、同一Vnet間の通信よりも利用できる帯域は低くなる。
  • ③異なるVnet間でExpressRoute経由とした通信の場合、VPNGatewayの帯域上限値にのみ依存し、ExpressRouteの帯域上限値は関係ない

さいごに

公開されている帯域幅をすべてフルで利用できるとは思っていませんでしたし、実際に利用できる帯域はもっと少ないのかと思っていましたが、同一Vnet内や同一リージョンのVnetpeering間の通信では90%以上は利用できたので、少し驚きました。

また、Expressroute を経由した通信ではExpressroute の帯域は関係ないということについても驚きました。
ExpressRouteの帯域上限はPrivatepeeringなどのAzure外との通信にのみ適用されるのかもしれません。

今回はすべての仮想マシンを東日本リージョンに構築して実施していましたが、リージョンが異なる仮想マシン間の通信などにはもっと利用できる帯域は低くなるのではないかとは思いました。

機会があれば、異なるリージョン間での計測もやってみたいと思います。

コメント

タイトルとURLをコピーしました