Microsoft Azure のネットワーク性能について考察する (東日本~米国西部編)
Microsoft Azure の場合、リージョン間の内部通信は以下の3つの形態が考えられます。
(1) インターネット経由
(2) VNet to VNet (VPN GatewayがEnd-to-Endに必要)
(3) Azure バックボーン経由
- Azure VM@東日本 → Azure VM@米国西部(パブリックIPアドレス)
- Azure VM@米国西部 → Azure VM@東日本(パブリックIPアドレス)
- Azure VM@東日本 → Azure Blob ストレージ@米国西部
- Azure VM@米国西部 → Azure Blob ストレージ@東日本
この3つの形態で、Microsoft Azure のネットワーク性能、つまり、どの程度のスループットとレイテンシーの差が出てくるものか検証してみます。
ツールは、nuttcp / Apache Bench / Azure Throughput Analyzer の3種類を使い、計5回測定した平均値で比較します。
- クライアント / サーバー型のアーキテクチャーを採用しているネットワーク帯域幅を測定するツール
- 測定するネットワークの両端にあるLinux 仮想マシン(今回の場合はUbuntu 14.04)にインストール
- 最新バージョンである nuttcp ver6.1.2を使用
### nuttcpをインストール ###
$ sudo apt-get install nuttcp
### 172.17.1.5のサーバーに対して接続した場合 ###
$ sudo nuttcp 172.17.1.5
187.0524 MB / 10.16 sec = 154.5096 Mbps 0 %TX 4 %RX 0 retrans 108.32 msRTT
※上記の出力結果だと、以下のことが分かります。
・10.16秒 で 187.0524MB のデータを送信
・通信速度は『154.5096Mbps』で、RTT(Round-Trip Time)は『108.32ミリ秒』
・送信側(TX)のCPU使用率が0%、受信側(RX)のCPU使用率が4%
送信元⇒送信先 | 通信速度(Mbps) | RTT(ミリ秒) | |
インターネット経由 | Azure VM@東日本 ⇒ AWS EC2@米国西部 | 56.41 | 172.03 |
AWS EC2@米国西部 ⇒ Azure VM@東日本 | 100.30 | 172.36 | |
VNet-to-VNet経由 | Azure VM@東日本 ⇒ Azure VM@米国西部 | 146.71 | 108.28 |
Azure VM@米国西部 ⇒ Azure VM@東日本 | 144.37 | 119.16 | |
Azureバックボーン経由 | Azure VM@東日本 ⇒ Azure VM@米国西部 | 209.04 | 106.22 |
Azure VM@米国西部 ⇒ Azure VM@東日本 | 135.84 | 106.25 |
Apache Bench による HTTP応答時間 (Webサーバーへの負荷計測)
- http リクエスト に対する性能を測定するツール
- 100ユーザーが同時に 10リクエスト(合計1,000リクエスト) を Webサーバーに送信したケースを想定
- テストで使用したドキュメント(index.html)のデータサイズは一律で 『11,510バイト』
- Apache Bench は、最新バージョンである ver 2.3 <Revision: 1528965> を使用
- Apache は、最新バージョンである ver 2.4.7 (Ubuntu) を使用
### apache2-utilsをインストール ###
$ sudo apt-get install apache2-utils
### 100ユーザーがhttp://www.hogehoge.com/index.htmlというWebサイトに10リクエスト同時接続した場合 ###
$ sudo ab -n 1000 -c 100 http://www.hogehoge.com/index.html
(※主要な箇所のみ抜粋)
Requests per second: 166.72 [#/sec] (mean)
# 1秒間に処理したリクエスト数の平均値
Time per request: 599.801 [ms] (mean)
# 全てのリクエストに要した処理時間(ミリ秒)
Time per request: 5.998 [ms] (mean, across all concurrent requests)
# 1リクエストに要した処理時間(ミリ秒)
Transfer rate: 1918.44 [Kbytes/sec] received
# 1秒間に受信したデータサイズ
送信元⇒送信先 | リクエスト処理数/秒 | 処理時間/1リクエスト (ミリ秒) |
受信データサイズ (MB/秒) |
|
インターネット経由 | Azure VM@東日本 ⇒ AWS EC2@米国西部 | 220.81 | 5.01 | 2.48 |
AWS EC2@米国西部 ⇒ Azure VM@東日本 | 224.73 | 5.03 | 2.53 | |
VNet-to-VNet経由 | Azure VM@東日本 ⇒ Azure VM@米国西部 | 284.09 | 4.04 | 3.19 |
Azure VM@米国西部 ⇒ Azure VM@東日本 | 329.45 | 3.72 | 3.70 | |
Azureバックボーン経由 | Azure VM@東日本 ⇒ Azure VM@米国西部 | 239.41 | 4.18 | 2.69 |
Azure VM@米国西部 ⇒ Azure VM@東日本 | 270.95 | 3.69 | 3.04 |
Azure Throughput Analyzer によるファイル転送時間
- テストファイルを Azure Blob Storage にアップロードした後にダウンロードするスループット測定ツール
- 送信元: Windows Server 仮想マシン、送信先: Azure Blob Storage で測定
- テストファイルのサイズは一律 『1GB』 (1,073,741,824バイト)
- 50スレッド (マルチスレッドの上限設定) で送受信
送信元⇒送信先 | アップロード(秒) | ダウンロード(秒) | |
インターネット経由 | AWS EC2@東日本 ⇒ Azure Blob@米国西部 | 25.94 | 88.27 |
AWS EC2@米国西部 ⇒ Azure Blob@東日本 | 32.23 | 39.24 | |
Azureバックボーン経由 | Azure VM@東日本 ⇒ Azure Blob@米国西部 | 23.31 | 26.18 |
Azure VM@米国西部 ⇒ Azure Blob@東日本 | 20.83 | 14.32 |
結論から言うと、日本~米国間だと驚くような差は出なかったというのが正直なところです。
あと、プロトコルによっても、バラつきは出てますね。
とはいえ、通信事情の芳しくないブラジルやインド等との間だと、もっとはっきりした差が出てくることが容易に想像できます。
最後に...時期や時間帯などによって、インターネットの輻輳状態も大きく異なるため、あくまで参考値として見ていただければ幸いです。