Azure VM の TCP/IP パフォーマンス チューニング

この記事では、一般的な TCP/IP のパフォーマンス チューニング技法と、それらを Azure で実行している仮想マシンに使用する場合の考慮事項について説明します。 基本的な手法の概要を示し、チューニングする方法を詳しく説明します。

一般的な TCP/IP チューニング手法

MTU、断片化、Large Send Offload (LSO)

MTU

最大転送単位 (MTU) は、ネットワーク インターフェイスを介して送信できる、バイト単位で指定された最大サイズのフレーム (パケット) です。 MTU は、構成可能な設定です。 Azure VM 上で使用される既定の MTU と、ほとんどのネットワーク デバイス上のグローバルな既定の設定は、1,500 バイトです。

断片化

断片化は、ネットワーク インターフェイスの MTU を超えるパケットが送信されるときに発生します。 TCP/IP スタックにより、パケットは、インターフェイスの MTU に準拠したより小さい部分 (フラグメント) に分割されます。 断片化は IP レイヤーで行われ、基になるプロトコル (TCP など) には依存しません。 2,000 バイトのパケットが、MTU が 1,500 であるネットワーク インターフェイスで送信されると、そのパケットは 1,500 バイトのパケット 1 つと 500 バイトのパケット 1 つに分割されます。

ソースと宛先の間のパス上にあるネットワーク デバイスには、MTU を超えるパケットを削除するか、パケットをより小さい部分に断片化することができます。

IP パケット内の断片化禁止ビット

断片化禁止ビット (DF) は、IP プロトコル ヘッダー内のフラグです。 DF ビットは、送信者と受信者の間のパス上にあるネットワーク デバイスでパケットを断片化してはならないことを示します。 このビットは、多くの理由で設定できます。 (1 つの例として、この記事の「パス MTU 検出」セクションを参照してください)。断片化禁止ビットが設定されたパケットがネットワーク デバイスによって受信され、そのパケットがデバイスのインターフェイスの MTU を超えている場合、デバイスの標準的な動作は、パケットを削除することです。 デバイスは、"ICMP Fragmentation Needed" (ICMP 断片化が必要) メッセージをパケットの送信元に戻します。

断片化がパフォーマンスに与える影響

断片化は、パフォーマンスに悪影響を与えることがあります。 パフォーマンスに与える影響の主な理由の 1 つは、パケットの断片化と再構築が CPU/メモリに与える影響です。 ネットワーク デバイスがパケットの断片化を必要とする場合、断片化を実行するための CPU/メモリ リソースを割り当てる必要があります。

パケットの再構築時にも同じことが起きます。 ネットワーク デバイスでは、元のパケットに再構築できるように、すべてのフラグメントが受信されるまでそれらを格納しておく必要があります。 断片化と再構築のこのプロセスは、待ち時間も生じさせます。

断片化について考えられるパフォーマンスへの他の悪影響は、断片化されたパケットが順不同で到着する可能性があることです。 パケットが順不同で受信されると、ネットワーク デバイスの種類によってはそれらを削除することがあります。 これが起きた場合、パケット全体を再送信する必要があります。

フラグメントは一般的に、ネットワーク ファイアウォールなどのセキュリティ デバイスや、ネットワーク デバイスの受信バッファーが使い果たされた場合に削除されます。 ネットワーク デバイスの受信バッファーが使い果たされた場合、ネットワーク デバイスは断片化されたパケットの再構築を試みますが、パケットを格納して再び取り出すためのリソースがありません。

断片化は否定的な操作と見られることがありますが、断片化のサポートは、インターネット経由で多様なネットワークに接続する場合に必要です。

MTU の変更の利点と結果

一般に、MTU を大きくすることで、より効率的なネットワークを作成できます。 送信されるすべてのパケットには、元のパケットに追加されるヘッダー情報があります。 断片化により多くのパケットが作成されるときは、さらに多くのヘッダー オーバーヘッドが生じ、それによりネットワークの効率が低下します。

次に例を示します。 イーサネット ヘッダーのサイズは、14 バイトに、フレームの一貫性を確保するための 4 バイトのフレーム チェック シーケンスが加算されます。 2,000 バイトのパケットが 1 つ送信された場合、18 バイトのイーサネット オーバーヘッドがネットワークに追加されます。 パケットが 1,500 バイトのパケットと 500 バイトのパケットに断片化されている場合は、各パケットが 18 バイトのイーサネット ヘッダーを持ち、合計で 36 バイトになります。

MTU を増やしても、必ずしもより効率的なネットワークが作成されるわけでないことに注意してください。 アプリケーションで 500 バイトのパケットのみを送信する場合、MTU が 1,500 バイトか 9,000 バイトかにかかわらず、同じヘッダー オーバーヘッドが存在するようになります。 ネットワークは、MTU の影響を受ける大きなパケット サイズを使用している場合にのみ、より効率的になります。

Azure と VM の MTU

Azure VM の既定の MTU は 1,500 バイトです。 Azure Virtual Network スタックでは、1,400 バイトでのパケットの断片化が試行されます。

VM の MTU が 1,500 であっても、1,400 バイトでパケットを断片化するため、仮想ネットワーク スタックは本質的に非効率ではないことに注意してください。 ネットワーク パケットの大部分は 1,400 または 1,500 バイトよりかなり小さくなります。

Azure と断片化

Virtual Network スタックは、"順序が正しくないフラグメント"、つまり元の断片化された順序で到着しない断片化されたパケットを削除するように設定されています。 これらのパケットは主に、2018 年 11 月に発表された FragmentSmack と呼ばれるネットワーク セキュリティの脆弱性が原因で削除されます。

FragmentSmack は、断片化された IPv4 および IPv6 パケットの再構築が Linux カーネルによって処理される方法の欠陥です。 リモートの攻撃者は、この欠陥を利用して、コストの高いフラグメント再構築操作をトリガーします。これは、ターゲット システム上での CPU 使用の増加やサービス拒否攻撃につながる可能性があります。

MTU のチューニング

Azure VM の MTU は、その他の任意のオペレーティング システムの場合と同じように構成できます。 ただし、MTU を構成する場合は、上記の、Azure で発生する断片化を考慮する必要があります。

VM の MTU を増やすことは、お客様にお勧めしていません。 この説明は、Azure がどのように MTU を実装し、断片化を実行するかを詳しく説明することが目的です。

重要

MTU を大きくしてもパフォーマンスの向上は見られず、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。

Large Send Offload (LSO)

Large Send Offload (LSO) では、パケットのセグメント化をイーサネット アダプターにオフロードすることで、ネットワーク パフォーマンスを向上させることができます。 LSO が有効になっている場合、TCP/IP スタックでは大きな TCP パケットが作成され、転送前にセグメント化するためにイーサネット アダプターに送信されます。 LSO の利点は、MTU に準拠したサイズへのパケットのセグメント化から CPU を解放でき、ハードウェアで実行されているイーサネット インターフェイスにその処理をオフロードできることです。 LSO の特典についての詳細については、Large Send Offload のサポートを参照してください。

LSO が有効になっている場合、Azure のお客様では、パケット キャプチャの実行時に大きなフレーム サイズが見られることがあります。 これらの大きなフレーム サイズにより、一部のお客様は、断片化が起きているとか、大きな MTU が使用されていないのに使用されていると考える可能性があります。 LSO により、イーサネット アダプターは、より大きな最大セグメント サイズ (MSS) を TCP/IP スタックにアドバタイズして、さらに大きな TCP パケットを作成します。 この非セグメント化フレーム全体がイーサネット アダプターに転送され、VM 上で実行されるパケット キャプチャに表示されます。 しかし、パケットは、イーサネット アダプターによってイーサネット アダプターの MTU に従って多くの小さなフレームに分割されます。

TCP/MSS ウィンドウ スケーリングと PMTUD

TCP 最大セグメント サイズ

TCP 最大セグメント サイズ (MSS) は、TCP セグメントのサイズを制限する設定であり、これにより TCP パケットの断片化を避けます。 オペレーティング システムは、通常はこの数式を使用して、MSS を設定します。

MSS = MTU - (IP header size + TCP header size)

IP ヘッダーと TCP ヘッダーは、それぞれ 20 バイト、つまり合計 40 バイトです。 したがって、1,500 の MTU とのインターフェイスでは MSS が 1,460 になります。 ただし、MSS は構成可能です。

この設定は、TCP セッションがソースと宛先の間に設定されている場合に、TCP 3 ウェイ ハンドシェイクで合意されます。 両方の側が MSS 値を送信し、2 つのうち小さい方が TCP 接続に使用されます。

ソースと宛先の MTU が、MSS の値を決定する唯一の要素ではないことに留意してください。 Azure VPN Gateway をはじめとする VPN ゲートウェイのような中間ネットワーク デバイスには、最適なネットワーク パフォーマンスを実現するためにソースと宛先に依存せずに MTU を調整する機能があります。

パス MTU 検出

MSS がネゴシエートされますが、使用できる実際の MSS を示さない場合があります。 これは、ソースと宛先の間のパスにある他のネットワーク デバイスが、ソースと宛先よりも低い MTU 値を持つ可能性があるからです。 この場合、パケットよりも MTU が小さいデバイスがパケットを破棄します。 デバイスは、その MTU を含む ICMP Fragmentation Needed (ICMP 断片化が必要) (タイプ 3、コード 4) メッセージを戻します。 この ICMP メッセージにより、ソース ホストはそのパス MTU を適宜縮小できます。 そのプロセスは、パス MTU 検出 (PMTUD) と呼ばれます。

PMTUD プロセスは、効率的でなく、ネットワーク パフォーマンスに影響を与えます。 ネットワーク パスの MTU を超えるパケットが送信された場合、それらのパケットはより小さい MSS で再送信される必要があります。 パス上のネットワーク ファイアウォール (一般に PMTUD ブラックホールと呼ばれます) が原因で送信者が ICMP Fragmentation Needed (ICMP 断片化が必要) メッセージを受信しない場合、送信者は MSS を縮小する必要があることを認識せず、パケットを再送信し続けます。 このため、Azure VM の MTU を増やすことはお勧めしません。

VPN および MTU

(IPsec VPN などの) カプセル化を実行する VM を使用する場合は、パケット サイズと MTU に関するいくつか追加の考慮事項があります。 VPN は、さらにヘッダーをパケットに追加しますが、これによりパケット サイズが大きくなり、より小さい MSS が必要になります。

Azure の場合、TCP MSS クランプを 1,350 バイトに設定し、トンネル インターフェイス MTU を 1,400 に設定することをお勧めします。 詳細については、VPN デバイスと IPSec/IKE パラメーターに関するページを参照してください。

待ち時間、ラウンドトリップ時間、TCP ウィンドウ スケーリング

待ち時間とラウンドトリップ時間

ネットワーク待ち時間は、光ファイバー ネットワーク上では光の速度に左右されます。 2 台のネットワーク デバイス間のラウンドトリップ時間 (RTT) により、TCP のネットワーク スループットも事実上制御されます。

ルート Distance 一方向の時間 RTT
ニューヨークからサンフランシスコへ 4,148 km 21 ミリ秒 42 ミリ秒
ニューヨークからロンドンへ 5,585 km 28 ミリ秒 56 ミリ秒
ニューヨークからシドニーへ 15,993 km 80 ミリ秒 160 ミリ秒

次の表では、2 つの場所間の直線距離を示します。 ネットワークでは、距離は一般的に直線距離より長くなります。 光速により制御される最小 RTT を計算するための単純な数式を次に示します。

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

伝播の速度には、200 を使用できます。 これは、光が 1 ミリ秒に移動する、キロメートル単位の距離です。

例として、ニューヨークからサンフランシスコを取り上げてみましょう。 直線距離は、4,148 km です。 式に値を代入すると、次の解が得られます。

Minimum RTT = 2 * (4,148 / 200)

式の出力は、ミリ秒単位です。

ネットワーク パフォーマンスを最適化する場合、論理的なオプションは、それらの間が最短距離である宛先を選択することです。 トラフィックのパスを最適化して待ち時間を短縮するように仮想ネットワークを設計する必要もあります。 詳細については、この記事の「ネットワーク設計に関する考慮事項」セクションを参照してください。

TCP に対する待ち時間とラウンドトリップ時間の影響

ラウンド トリップ時間は、TCP の最大スループットに直接影響します。 TCP プロトコルでは、ウィンドウ サイズ は、送信者が受信者から受信確認を受信する前に TCP 接続経由で送信できるトラフィックの最大量です。 TCP MSS が 1,460 に設定され、TCP ウィンドウ サイズが 65,535 に設定されている場合、送信者は受信者から受信確認を受信する前に 45 パケットを送信できます。 送信者が受信確認を取得しない場合は、データは再送信されます。 数式は次のとおりです。

TCP window size / TCP MSS = packets sent

この例では、65,535 / 1,460 は 45 に切り上げられます。

信頼性の高いデータ配信を確実にするメカニズムとしてのこの "受信確認待機中" 状態は、RTT が TCP のスループットに影響を与える原因です。 送信者が受信確認を待機する期間が長くなるほど、他のデータを送信する前に待機する必要のある時間も長くなります。

1 つの TCP 接続の最大スループットを計算する数式は次のとおりです。

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

この表は、1 つの TCP 接続の最大メガバイト/秒のスループットを示しています。 (読みやすくするため、メガバイトを測定単位に使用しています。)

TCP ウィンドウ サイズ (バイト単位) RTT 待ち時間 (ミリ秒) 最大メガバイト/秒のスループット 最大メガビット/秒のスループット
65,535 1 65.54 524.29
65,535 30 2.18 17.48
65,535 60 1.09 8.74
65,535 90 .73 5.83
65,535 120 .55 4.37

パケットが失われた場合、送信者が既に送信されたデータを再送信するときに、TCP 接続の最大スループットが低下します。

TCP ウィンドウ スケーリング

TCP ウィンドウ スケーリングは、TCP ウィンドウ サイズを動的に増やして、受信確認が必要になる前に送信できるデータ量を増やすという技法です。 前の例では、受信確認が必要になる前に 45 パケットが送信されます。 受信確認の前に送信するパケット数を増やすと、送信者が受信確認を待機する回数が減るので TCP の最大スループットも向上します。

この表は、これらの関係を示しています。

TCP ウィンドウ サイズ (バイト単位) RTT 待ち時間 (ミリ秒) 最大メガバイト/秒のスループット 最大メガビット/秒のスループット
65,535 30 2.18 17.48
131,070 30 4.37 34.95
262,140 30 8.74 69.91
524,280 30 17.48 139.81

ただし、TCP ウィンドウ サイズの TCP ヘッダー値は 2 バイトの長さなので、受信ウィンドウの最大値は 65,535 になります。 最大ウィンドウ サイズを大きくするために、TCP ウィンドウ スケール ファクターが導入されました。

スケール ファクターも、オペレーティング システムで構成できる設定です。 スケール ファクターを使用して TCP ウィンドウ サイズを計算する数式は次のとおりです。

TCP window size = TCP window size in bytes \* (2^scale factor)

ウィンドウ スケール ファクターの 3 とウィンドウ サイズの 65,535 の計算を次に示します。

65,535 \* (2^3) = 262,140 bytes

14 のスケール ファクターでは TCP ウィンドウ サイズが 14 (最大オフセットを許可) になります。 TCP ウィンドウ サイズは 1,073,725,440 バイト (8.5 ギガビット) となります。

TCP ウィンドウ スケーリングのサポート

Windows では、異なる接続の種類の異なるスケーリング ファクターを設定できます。 (接続のクラスには、データセンターやインターネットなどが含まれます)。Get-NetTCPConnection PowerShell コマンドを使用して、ウィンドウ スケーリング接続の種類を表示します。

Get-NetTCPConnection

Get-NetTCPSetting PowerShell コマンドを使用して、各クラスの値を表示できます。

Get-NetTCPSetting

初期の TCP ウィンドウ サイズと TCP スケーリング ファクターは、Windows で Set-NetTCPSetting PowerShell コマンドを使用して設定できます。 詳細については、Set-NetTCPSetting を参照してください。

Set-NetTCPSetting

AutoTuningLevel の有効な TCP 設定は、次のとおりです。

AutoTuningLevel スケール ファクター スケール乗数 数式
(最大ウィンドウ サイズを計算)
無効 なし なし ウィンドウ サイズ
制限付き 4 2^4 ウィンドウ サイズ * (2^4)
厳しく制限 2 2^2 ウィンドウ サイズ * (2^2)
Normal 8 2^8 ウィンドウ サイズ * (2^8)
Experimental 14 2^14 ウィンドウ サイズ * (2^14)

これらの設定は TCP のパフォーマンスに影響する可能性が最も高いものですが、Azure で制御されないインターネット上の他の多くの要素も TCP のパフォーマンスに影響する可能性があることに留意しておいてください。

MTU サイズを増やす

MTU が大きいほど MSS が大きくなるので、MTU を増やすと TCP のパフォーマンスが向上することを疑問に思う場合があります。 答えはおそらく「いいえ」でしょう。 パケット サイズには、TCP トラフィック以外にも長所と短所があります。 前述のように、TCP のスループット パフォーマンスに影響を与える最も重要な要素は、TCP ウィンドウ サイズ、パケット損失、RTT です。

重要

Azure のお客様に、仮想マシン上の既定の MTU 値を変更することはお勧めしていません。

高速ネットワークと受信側のスケーリング

Accelerated Networking

仮想マシンのネットワーク機能は、これまでゲスト VM とハイパーバイザー/ホストの両方で CPU を集中的に使用してきました。 ホストを通過するすべてのパケットは、ホストの CPU によってソフトウェア内で処理されます。これには、すべての仮想ネットワークのカプセル化/カプセル化解除が含まれます。 そのため、ホストを通過するトラフィックが増えると、CPU の負荷が高くなります。 また、ホストの CPU が他の操作を実行していてビジー状態の場合は、ネットワークのスループットと待ち時間にも影響します。 Azure は、高速ネットワークでこの問題に対処します。

高速ネットワークは、Azure のプログラミング可能な社内ハードウェアと SR-IOV などのテクノロジを使用して、一貫性のある非常に短いネットワーク待ち時間を実現します。 高速ネットワークでは、多くの Azure ソフトウェア定義ネットワーク スタックが CPU を離れて FPGA ベース SmartNIC に移動します。 この変更により、エンド ユーザー アプリケーションはコンピューティング サイクルを再利用できます。これにより VM の負荷が減り、待ち時間でのジッターや不整合が減ります。 つまり、パフォーマンスがより決定論的になります。

高速ネットワークは、ゲスト VM がホストをバイパスしてホストの SmartNIC との直接データパスを確立できるようにすることで、パフォーマンスを向上させます。 高速ネットワークのいくつかの利点は次のとおりです。

  • 待ち時間の短縮/1 秒あたりのパケット数 (pps) の向上:データパスから仮想スイッチを削除することで、ホストにおけるパケットのポリシー処理に必要な時間がなくなるため、VM 内で処理できるパケット数が増加します。

  • ジッターの削減:仮想スイッチの処理は、適用するポリシーの量と、処理を行う CPU のワークロードによって異なります。 ハードウェアへのポリシーの適用をオフロードすると、パケットが直接 VM に配信され、ホストと VM 間の通信とソフトウェアによる干渉やコンテキスト スイッチがなくなるため、そのばらつきはなくなります。

  • CPU 使用率の削減:ホストの仮想スイッチをバイパスすることによって、ネットワーク トラフィックを処理するための CPU 使用率を削減できます。

高速ネットワークを使用するには、該当する各 VM に明示的に有効にする必要があります。 手順については、「高速ネットワークを使った Linux 仮想マシンの作成」を参照してください。

Receive Side Scaling

Receive Side Scaling (RSS) は、受信処理をマルチプロセッサ システム上の複数の CPU に分散することで、ネットワーク トラフィックの受信をより効率的に分散するネットワーク ドライバー テクノロジです。 簡単に言うと、RSS では、1 つだけではなくすべての使用可能な CPU が使用されるので、システムで処理できる受信トラフィックが増えます。 RSS の技術的な詳細については、サイド スケーリングの受け取りの概要を参照してください。

VM 上で高速ネットワークが有効になっているときに最大のパフォーマンスを実現するには、RSS を有効にする必要があります。 RSS は、高速ネットワークを使用しない VM 上でも利点があります。 RSS が有効になっているかどうかを判断する方法と、これを有効にすることについては、「Azure 仮想マシンのネットワーク スループットの最適化」を参照してください。

TCP TIME_WAIT と TIME_WAIT アセシネーション

TCP TIME_WAIT は、ネットワークとアプリケーションのパフォーマンスに影響を与えるもう 1 つの一般的な設定です。 多くのソケットを開閉しているビジーな VM 上では、クライアントまたはサーバー (ソース IP:送信元ポート + 宛先 IP:送信先ポート) として、TCP の通常の動作中に、特定のソケットが最終的に長時間 TIME_WAIT 状態になることがあります。 この TIME_WAIT 状態は、ソケットを閉じる前に、そのソケットで他のデータを配信できることを意味します。 そのため、TCP/IP スタックは一般に、クライアントの TCP SYN パケットを自動的に削除することにより、ソケットの再利用を防止します。

ソケットが TIME_WAIT である時間は構成できます。 その範囲は 30 ~ 240 秒です。 ソケットは有限のリソースであり、同時に使用できるソケット数は構成可能です。 (一般に、使用可能なソケットの数は約 30,000 です。)使用可能なソケットが使い果たされた場合、またはクライアントとサーバーの TIME_WAIT 設定が一致せず、VM が TIME_WAIT 状態のソケットを再利用しようとした場合、新しい接続は TCP SYN パケットが自動的に削除されるために失敗します。

送信ソケットのポート範囲の値は、オペレーティング システムの TCP/IP スタック内で通常は構成可能です。 同じことが TCP TIME_WAIT 設定とソケットの再利用に当てはまります。 これらの数を変更すると、スケーラビリティが向上する可能性があります。 ただし、状況によっては、これらの変更により相互運用性の問題が発生する可能性があります。 これらの値を変更する場合は注意する必要があります。

TIME_WAIT アセシネーションを使用して、このスケールの制限に対処できます。 TIME_WAIT アセシネーションにより、新しい接続の IP パケット内のシーケンス番号が以前の接続の最後のパケットのシーケンス番号を超えたときのような一部の状況で、ソケットを再利用できます。 この場合、オペレーティング システムにより、新しい接続の確立 (新しい SYN ACK の受け入れ) が許可され、TIME_WAIT 状態だった以前の接続が強制的に終了されます。 この機能は、Azure の Windows VM でサポートされます。 他の VM でのサポートについては、OS ベンダーにお問い合わせください。

TCP TIME_WAIT の構成に関するドキュメントについては、「Settings that can be modified to improve network performance (ネットワーク パフォーマンスを向上させるために変更可能な設定)」をご覧ください。

パフォーマンスに影響する可能性のある仮想ネットワーク要素

VM の最大送信スループット

Azure の VM には多様なサイズと種類があり、パフォーマンス機能の組み合わせもそれぞれ異なっています。 これらのパフォーマンス機能の 1 つがネットワーク スループット (帯域幅) で、メガビット/秒 (Mbps) で測定されます。 仮想マシンは共有ハードウェアでホストされているため、同じハードウェアを使用する仮想マシン間でネットワーク容量が公平に分配される必要があります。 大きな仮想マシンには、小さい仮想マシンよりも多くの帯域幅が割り当てられます。

各仮想マシンに割り当てられたネットワーク帯域幅は、仮想マシンからのエグレス (送信) トラフィックで測定されます。 仮想マシンから送信されるすべてのネットワーク トラフィックは、送信先に関係なく、割り当てられた制限に達するまでカウントされます。 たとえば、ある仮想マシンの制限が 1,000 Mbps である場合、送信トラフィックの送信先が同じ仮想ネットワーク内の仮想マシンであっても Azure 外部であっても、この制限が適用されます。

受信は、直接的には測定も制限もされません。 ただし、CPU やストレージの制限などの他の要素がある場合、仮想マシンの受信データ処理機能に影響する可能性があります。

高速ネットワークは、ネットワーク パフォーマンス (待ち時間、スループット、CPU 使用率など) の向上を目的として設計されています。 高速ネットワークは仮想マシンのスループットを向上させますが、向上できるのは仮想マシンに割り当てられた帯域幅までです。

Azure 仮想マシンには常に少なくとも 1 つのネットワーク インターフェイスが接続されている必要があります。 複数を接続することができます。 仮想マシンに割り当てられる帯域幅は、マシンに接続されているすべてのネットワーク インターフェイス全体の送信トラフィックの合計です。 つまり、帯域幅は仮想マシンごとに割り当てられており、マシンに接続されているネットワーク インターフェイスの数は関係ありません。

VM の各サイズでサポートされる予想される送信スループットとサポートされるネットワーク インターフェイスの数については、「Azure での Windows の VM サイズ」で詳しく説明しています。 最大スループットを表示するには、汎用 などの種類を選択し、表示されたページにサイズ シリーズに関するセクション (たとえば、「Dv2-series」) を見つけます。 各シリーズに、"最大 NIC 数/想定ネットワーク帯域幅 (Mbps)" というタイトルの最終列でネットワーク仕様を提供する表があります。

このスループット制限が仮想マシンに適用されます。 スループットは、次の要因の影響を受けません。

  • ネットワーク インターフェイスの数:帯域幅の制限は、仮想マシンからのすべての送信トラフィックに適用されます。

  • 高速ネットワーク:この機能は公開されている制限までの達成には役立ちますが、制限を変更することはありません。

  • トラフィックの送信先:すべての送信先が、送信制限に達するまでカウントされます。

  • プロトコル:すべてのプロトコルに対するすべての送信トラフィックが、制限に達するまでカウントされます。

詳しくは、「仮想マシンのネットワーク帯域幅」を参照してください。

インターネットのパフォーマンスに関する考慮事項

この記事全体を通して説明するように、インターネット上の要素と Azure の制御外の要素がネットワーク パフォーマンスに影響する可能性があります。 次のような要素があります。

  • 待ち時間:2 つの宛先の間のラウンドトリップ時間は、中間ネットワーク上の問題、"最短" 距離のパスをとることができないトラフィック、および最適ではないピアリング パスの影響を受ける可能性があります。

  • パケット損失:パケット損失は、ネットワークの輻輳、物理パスの問題、およびパフォーマンスが平均を下回るネットワーク デバイスが原因となっている可能性があります。

  • MTU サイズ/断片化:パス上での断片化は、データの到着遅延や正しくない順序でのパケットの到着につながる場合があり、これがパケットの配信に影響する可能性があります。

Traceroute は、ソース デバイスと宛先デバイス間のすべてのネットワーク パス上でネットワーク パフォーマンスの特性 (パケット損失や待ち時間など) を測定するための優れたツールです。

ネットワーク設計に関する考慮事項

この記事の前のほうで説明した考慮事項とともに、仮想ネットワークのトポロジは、ネットワークのパフォーマンスに影響します。 たとえば、トラフィックを単一ハブの仮想ネットワークにグローバルにバックホールするハブ アンド スポーク設計では、ネットワーク遅延が生じるので、ネットワークの全体的なパフォーマンスに影響があります。

ネットワーク トラフィックが通過するネットワーク デバイスの数も全体的な待ち時間に影響することがあります。 たとえば、ハブ アンド スポーク設計では、トラフィックがインターネットに送信される前にスポークのネットワーク仮想アプライアンスとハブの仮想アプライアンスを通過する場合、ネットワーク仮想アプライアンスによって待ち時間が生じる可能性があります。

Azure リージョン、仮想ネットワーク、待ち時間

Azure リージョンは、一般的な地理的領域内に存在する複数のデータ センターで構成されます。 これらのデータセンターは、物理的に並んでいない場合があります。 場合によっては 10 キロメートルほど離れています。 仮想ネットワークとは、Azure の物理データセンター ネットワーク上の論理オーバーレイです。 仮想ネットワークは、データセンター内のいずれかの特定のネットワーク トポロジのことを意味しません。

たとえば、2 つの VM が同じ仮想ネットワークとサブネット内にあっても、異なるラック、列、さらにはデータセンターにある可能性があります。 これらを分離している光ファイバー ケーブルの長さは、1 フィートの場合も数 km の場合もあります。 このバリエーションは、異なる VM 間に可変の待ち時間 (数ミリ秒の差異) をもたらす可能性があります。

VM の地理的な配置および 2 つの VM 間の潜在的な結果の待ち時間は、可用性セットと可用性ゾーンの構成により影響を受ける可能性があります。 しかしリージョン内のデータセンター間の距離はリージョン固有であり、主としてリージョン内のデータセンター トポロジによって影響を受けます。

送信元 NAT ポートの不足

Azure 内のデプロイでは、パブリック インターネットまたはパブリック IP 空間、あるいはその両方にある、Azure 外部のエンドポイントと通信できます。 インスタンスが送信接続を開始すると、Azure によってプライベート IP アドレスがパブリック IP アドレスに動的にマッピングされます。 Azure がこのマッピングを作成すると、この送信フローの戻りトラフィックも、フローの送信元であるプライベート IP アドレスに到達できます。

送信接続ごとに、このマッピングが Azure Load Balancer によって一定期間維持される必要があります。 Azure のマルチテナントの性質により、すべての VM のすべての送信フローについてこのマッピングを保持すると、大量のリソースが消費される可能性があります。 そのため、Azure Virtual Network の構成に基づいて制限が設定されます。 または、より正確に言うと、Azure VM では特定の時点に特定の数の送信接続のみ確立できます。 これらの制限に達すると、VM はそれ以上発信接続を作成できません。

ただしこの動作は構成できません。 SNAT と SNAT ポートの不足について詳しくは、こちらの記事をご覧ください。

Azure 上でのネットワーク パフォーマンスの測定

この記事のパフォーマンスの最大値は、2 つの VM 間のネットワーク待ち時間/ラウンドトリップ時間 (RTT) に関連しています。 ここでは、待ち時間/RTT をテストする方法と、TCP のパフォーマンスと VM ネットワークのパフォーマンスをテストする方法についての推奨事項を示します。 このセクションで説明する手法を使用して、前に説明したTCP/IP とネットワークの値のチューニングとパフォーマンステストを行うことができます。 待ち時間、MTU、MSS、およびウィンドウ サイズの値を前述の計算に代入し、テスト中に、理論上の最大値と観察された実際の値を比較します。

ラウンドトリップ時間とパケット損失の測定

TCP のパフォーマンスは、RTT とパケット損失に大きく依存します。 Windows と Linux で使用可能な ping ユーティリティは、RTT とパケット損失を測定する最も簡単な方法となります。 ping の出力は、ソースと宛先の間の最小/最大/平均待ち時間を示します。 パケット損失も表示されます。 ping では、既定で ICMP プロトコルが使用されます。 PsPing を使用して、TCP RTT をテストできます。 詳細については、「PsPing」を参照してください。

TCP 接続の実際のスループットの測定

NTttcp は、Linux または Windows VM の TCP パフォーマンスをテストするためのツールです。 TCP のさまざまな設定を変更し、NTttcp を使用してその利点をテストできます。 詳細については、次のリソースを参照してください。

仮想マシンの実際の帯域幅の測定

各種 VM タイプのパフォーマンスや高速ネットワークなどは、iPerf と呼ばれるツールを使用してテストできます。 iPerf は Linux と Windows でも利用できます。 iPerf では、TCP または UDP を使用してネットワークの全体的なスループットをテストできます。 iPerf TCP のスループット テストは、この記事で説明した要素 (待ち時間や RTT など) の影響を受けます。 最大スループットをテストする場合、UDP がより良い結果を生成する可能性があります。

詳細と例については、次の記事をご覧ください。

非効率的な TCP 動作の検出

パケット キャプチャで、Azure のお客様は、ネットワーク パフォーマンスの問題を示している可能性のある TCP フラグ (SACK、DUP ACK、RETRANSMIT、FAST RETRANSMIT) の付いた TCP パケットを見つける場合があります。 具体的には、これらのパケットは、パケット損失の結果であるネットワークの非効率性を示しています。 しかし、パケット損失は必ずしも Azure のパフォーマンスの問題によって発生するわけではありません。 パフォーマンスの問題は、アプリケーションの問題、オペレーティング システムの問題、またはその他の Azure プラットフォームに直接には関連しない問題の結果である可能性があります。

さらに、いくらかの再送信や重複 ACK は、ネットワーク上では普通に見られることに注意してください。 TCP プロトコルは信頼できるものとなるように構築されました。 パケット キャプチャにおけるこれらの TCP パケットの証拠は、過剰でない限り、必ずしもシステム的なネットワークの問題を示していません。

ただし、これらのパケットの種類は、TCP のスループットがこの記事の他のセクションで説明した理由により最大パフォーマンスを達成していないことを示します。

次のステップ

これで Azure VM の TCP/IP パフォーマンス チューニングについて学習したので、仮想ネットワークの計画の他の考慮事項について読んだり、仮想ネットワークの接続と構成の詳細について調べたりできます。