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

2025-04-21

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

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

MTU、断片化、Large Send Offload

MTUの

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

断片化

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

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

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

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

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

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

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

Azure と断片化

Azure では、高速ネットワークを使用してフラグメント化されたパケットを処理しません。 VMがフラグメント化されたパケットを受信すると、非加速化パスによって処理されます。その結果、フラグメント化されたパケットは、待機時間の短縮、ジッターの減少、1 秒あたりのパケット数の増加など、高速ネットワークの利点を逃します。このため、可能であれば断片化を回避することをお勧めします。

Azure では、既定では、VM に到着したフラグメント化されたパケットが順不同でドロップされます。つまり、パケットがソースエンドポイントからの伝送シーケンスと一致しません。この問題は、パケットがインターネットまたはその他の大規模な WAN を経由する場合に発生する可能性があります。

MTU のチューニング

VM のトラフィックの MTU を増やすことで、内部仮想ネットワークのスループットを向上させることができます。ただし、VM が異なる MTU を持つ仮想ネットワークの外部の宛先と通信すると、断片化が発生し、パフォーマンスが低下する可能性があります。

Azure VM での MTU の設定の詳細については、「Azure での仮想マシンの最大伝送ユニット (MTU) の構成」を参照してください。

Large Send Offload

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

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

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

TCP 最大セグメントサイズ

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

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

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

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

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

パス MTU 検出

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

PMTUD プロセスでは、非効率性のためにネットワークパフォーマンスが低下します。ネットワークパスの MTU を超えた場合は、より低い MSS でパケットを再送信する必要があります。ネットワークファイアウォールが ICMP 断片化が必要なメッセージをブロックする場合、送信者は MSS を下げる必要性を認識せずに、パケットを繰り返し再送信します。このため、Azure VM MTU を増やさないことをお勧めします。

VPN および MTU

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

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

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

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

光の速度によって、光ファイバーネットワークでのネットワーク待機時間が決まります。 2 つのネットワークデバイス間のラウンドトリップ時間 (RTT) によって、TCP ネットワークスループットが制御されます。

ルート	距離	一方向の時間	アールティーティー
ニューヨークからサンフランシスコへ	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	六十	1.09	8.74
65,535	90	0.73	5.83
65,535	120	0.55	4.37

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

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

TCP ウィンドウのスケーリングは、受信確認が必要になる前により多くのデータを送信できるように、TCP ウィンドウサイズを動的に増やす手法です。前の例では、受信確認が必要になる前に 45 個のパケットが送信されます。受信確認が必要になる前に送信できるパケットの数を増やすと、送信者が受信確認を待機する回数を減らすことができます。

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

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 設定です。

オートチューニングレベル	スケールファクター	スケール乗数	数式 (最大ウィンドウサイズを計算)
無効	なし	なし	ウィンドウサイズ
制限付き	4	2^4	ウィンドウサイズ * (2^4)
厳重に制限されている	2	2^2	ウィンドウサイズ * (2^2)
標準	8	2^8	ウィンドウサイズ * (2^8)
試験	14	2^14	ウィンドウサイズ * (2^14)

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

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

高速ネットワーキング

これまで、仮想マシンネットワークの機能は、ゲスト 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 は、クライアントまたはサーバーとして、多くのソケットを頻繁に開いたり閉じたりします。通常の TCP 操作中、ソケットは多くの場合、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 設定と送信元ポート範囲の構成についての情報は、「ネットワークパフォーマンスを向上させるために変更可能な設定」をご覧ください。

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

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

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

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

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

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

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

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

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

ネットワークインターフェイスの数: 帯域幅の制限は、仮想マシンからのすべての送信トラフィックの合計に適用されます。
高速ネットワーク: この機能は公開された制限を達成するのに役立ちますが、制限は変更されません。
トラフィックの宛先: すべての宛先が送信制限にカウントされます。
プロトコル: すべてのプロトコル上のすべての送信トラフィックが制限にカウントされます。

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

Linux Virtual Machines (VM) の最適化

最新の Linux カーネルには、一貫性とパフォーマンスを実現するのに役立つ機能があり、特定のワークロードで必要な場合があります。

詳細については、Azure VM でのネットワーク帯域幅の最適化に関するページを参照してください。

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

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

待機時間: 2 つのエンドポイント間のラウンドトリップ時間は、中間ネットワーク上の問題、"最短" の距離パスを取らないトラフィック、および最適でないピアリングパスの影響を受けます。
パケット損失: パケット損失は、ネットワークの輻輳、物理パスの問題、パフォーマンスの低いネットワークデバイスによって発生します。
MTU サイズ/断片化: パスに沿った断片化により、データの到着またはパケットの順序が間に合わない遅延が発生し、パケットの配信に影響する可能性があります。

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

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

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

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

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

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

たとえば、2 つの VM が同じ仮想ネットワークとサブネット内にあっても、異なるラック、列、さらにはデータセンターにある可能性があります。これらは、光ファイバーケーブルのフィートまたは光ファイバーケーブルのキロメートルで区切ることができます。このバリエーションは、異なる 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」を参照してください。

ICMP および TCP ping では、高速ネットワークデータパスは測定されません。データパスを測定するには、この記事の Latte と SockPerf についてお読みください。

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

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

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

非効率的な TCP 動作の検出

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

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

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

次のステップ

Azure VM の TCP/IP パフォーマンスチューニングについて学習したので、仮想ネットワークを計画するための他の要因を検討することを検討してください。また、仮想ネットワークの接続と構成の詳細についても説明します。