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

[アーティクル]
11/30/2023

この記事では、一般的な 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/メモリリソースを割り当てる必要があります。

パケットの再構築時にも同じことが起きます。ネットワークデバイスでは、元のパケットに再構築できるように、すべてのフラグメントが受信されるまでそれらを保存しておく必要があります。

Azure と断片化

Azure の断片化されたパケットは、高速ネットワークでは処理されません。断片化されたパケットが VM で受信されると、高速化されていないパスを介して処理されます。これは、断片化されたパケットは、高速ネットワークの利点 (待機時間の短縮、ジッターの削減、1 秒あたりのパケット数の増加) を享受できないことを意味します。このため、可能であれば断片化を回避することをお勧めします。

既定では、ソースエンドポイントから送信された順序と異なる順序で VM に到着した断片化されたパケットは、Azure によってドロップされます。これは、パケットがインターネットまたはその他の大規模な WAN を介して送信されるときに発生する可能性があります。場合によっては、順序がずれたフラグメントの並べ替えを有効にできることがあります。アプリケーションでこれが必要な場合は、サポートケースを開いてください。

MTU のチューニング

VM NIC の MTU を増やすことはお勧めしません。 VM が、同様の MTU セットを持つ Virtual Network 内にない宛先と通信する必要がある場合、断片化が発生してパフォーマンスが低下する可能性があります。

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) = 524,280 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 のパフォーマンスに影響する可能性があることに留意しておいてください。

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

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」を参照してください。

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

Azure VM の帯域幅を正確に測定するには、このガイダンスに従ってください。

他のシナリオのテストの詳細については、次の記事を参照してください。

非効率的な TCP 動作の検出

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

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

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

次のステップ

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

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