Azureの仮想マシンは仮想マシンのサイズごとにネットワーク帯域幅の利用上限が決まっていますが「実際に利用できる帯域幅はどのくらいなのか？」が気になったのでiperfを利用して調べてみました。
今回は「Standard DS5 v2」という仮想マシンサイズを利用して調べてみました。
「Standard DS5 v2」の帯域幅は公開されている情報では12,000Mbpsとなっています。
今回の検証構成
今回の検証構成は以下の通りです。
仮想マシンの通信として以下の3つの通信経路で調べてみました。
iperfの準備
各仮想マシンにiperfをダウンロードします。
以下のリンク先からダウンロード可能です。
今回はwindowsOSを利用したので「Windows 64 bits」の最も新しいバージョンをダウンロードして測定しました。
ネットワーク帯域幅の上限を測定する
iperf3を実行して測定していきます。
iperfの実行（サーバ側）
以下のコマンドを入力してクライアントからトラフィックが流れてくるのを待ちます。
iperf3 -sコマンドを実行すると以下のような画面となり、デフォルトでは5201ポートで待ち受けます。
仮想マシンのOS内のFWで、今回利用するポートを許可することが必要になりますのでその点だけ注意してください。
iperfの実行（クライアント側）
以下のコマンドを入力してクライアントからトラフィックを流します。
iperf3 -c 10.2.0.4このコマンドを実行した直後から通信が流れます。
測定結果
①同一Vnet間（異なるsubnet間）での通信について
結果は以下のようになりました。
「856Mbps」出ていますが、上限値である[12,000Mbps]には届いていないのでオプション[-P]を指定し、[実行する並列クライアント スレッドの数]を増やして上限値に到達するまで実行してみます。
「‐P 16」での実行結果
「7.98Gbps ≒ 7,980Mbps」なので、まだスレッド数を増やして試すことができそうです。
「-P 32」での実行結果
「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] のメトリックを確認してみました。
![仮想マシンの[メトリック]の表示画面](https://bonjiri-blog.com/wp-content/uploads/measure-limit-of-network-bandwidth-between-vm-using-iperf-011.png)
上記は1分間の合計値までしか表示できないので、かなり大きなトラフィックが流れているように見えます。
Azureポータル上の[メトリック]からでは詳細な情報は取れなさそうであったので、あくまで参考程度に確認するのがいいのかもしれません。
②異なるVnet間でVnetpeeringを利用した通信について
「-P 32」のオプションをつけて実行し、「10.9Gbps ≒ 10,900Mbps」利用できることがわかりました。
①の結果に比べて、少しだけ利用できる帯域幅が少ない結果となりました。
念のため何回か実施してみましたが、平均しても②の結果はギリギリ11Gbpsに届かないくらいの結果ですが、①の結果は11Gbps以上の値が出ますので、この差は誤差ではなく明確にあることもわかりました。
Vnetpeeringをしているとはいえ、Vnetが異なるため距離的に少し遠くなることなどが影響しているのかもしれません。
③異なるVnet間でExpressRoute経由とした通信について
ExpressRouteは帯域100MbpsのSKUを利用しており、VPNGatewayは[Standard]を利用しているため帯域は1000Mbpsとなっています。
これらの制限もどう影響するのか含めて確認していきます。
結果は、①や②の結果より利用できる帯域幅が大幅に少ない「1.40Gbps」でした。
VPNGatewayの帯域上限値よりも少し高い値となっていますが、VPNGatewayの帯域上限値に影響を受けているのかなと感じました。
逆に言うとExpressRouteの帯域上限は影響がないように見受けられます。
[追加検証１]ERの帯域を上げるとどうなるのか
念のためExpressRouteの帯域を1Gbpsとして再度計測してみました。
![[追加検証１]ERの帯域を上げるとどうなるのかの測定結果](https://bonjiri-blog.com/wp-content/uploads/measure-limit-of-network-bandwidth-between-vm-using-iperf-018.png)
結果は上記と同じ「1.40Gbps」でした。
これで、異なるVnet間の通信がExpressrouteを経由する場合には、ExpressRouteの帯域上限値は影響がないということが分かりました。
[追加検証２]VPNGatewayの帯域を上げるとどうなるのか
今度はVPNGatewayの帯域を10Gbpsまで上げて再度測定します。
VPNGatewayのSKUを[Ultra Performance]として、ExpressRouteの帯域は１Gbpsのままとします。
![VPNGWが[Ultra Performance]である表示画面](https://bonjiri-blog.com/wp-content/uploads/measure-limit-of-network-bandwidth-between-vm-using-iperf-019.png)
![[追加検証２]VPNGatewayの帯域を上げるとどうなるのかの測定結果](https://bonjiri-blog.com/wp-content/uploads/measure-limit-of-network-bandwidth-between-vm-using-iperf-020.png)
結果は「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外との通信にのみ適用されるのかもしれません。
今回はすべての仮想マシンを東日本リージョンに構築して実施していましたが、リージョンが異なる仮想マシン間の通信などにはもっと利用できる帯域は低くなるのではないかとは思いました。
機会があれば、異なるリージョン間での計測もやってみたいと思います。
コメント