Azure Load Balancer の送信接続に関する問題のトラブルシューティング
Azure Load Balancer の送信接続に関するトラブルシューティング ガイダンスについて説明します。 これには、送信元ネットワーク アドレス変換 (SNAT) の理解、接続への影響、VM での個々のパブリック IP の使用、SNAT ポートの枯渇を回避するための接続効率の高いアプリケーションの設計が含まれます。 顧客が体験する送信接続に関する問題のほとんどは、SNAT ポートの枯渇と、接続タイムアウトを原因とするパケットのドロップです。
SNAT ポートの詳細については、送信接続での送信元ネットワーク アドレス変換に関するページを参照してください。
SNAT ポートの使用状況を理解する
「メトリック、アラート、リソース正常性を使用した Standard Load Balancer の診断」に従って、既存のロード バランサーの SNAT ポートの使用状況と割り当てを監視します。 監視して、SNAT 枯渇のリスクを確認または判断します。 送信接続の動作を理解できない場合は、IP スタック統計 (netstat) を使用するか、パケット キャプチャを収集します。 これらのパケット キャプチャはインスタンスのゲスト OS で実行できます。また、パケット キャプチャには Network Watcher も使用できます。 Azure では、SNAT 枯渇のリスクを軽減するために、ほとんどのシナリオに対して、送信接続に NAT Gateway を使用することをお勧めしています。 サービスによって同じ宛先への TCP または UDP 送信接続が繰り返し開始されている場合は、NAT Gateway を強くお勧めします。
送信接続用に Azure デプロイを最適化する
送信接続用に Azure デプロイを最適化することが重要です。 最適化により、送信接続に関する問題を防止または軽減できます。
送信インターネット接続用の NAT ゲートウェイをデプロイする
Azure NAT Gateway は、仮想ネットワークからインターネットへの送信接続を提供する、回復性が高くスケーラブルな Azure サービスです。 NAT Gateway 独自の SNAT ポートの使用方法は、一般的な SNAT 枯渇と接続の問題を解決するのに役立ちます。 Azure NAT Gateway の詳細については、「Azure NAT Gateway とは」を参照してください。
NAT Gateway では、SNAT ポート枯渇のリスクはどのように軽減されますか?
Azure Load Balancer では、バックエンド プール内の各仮想マシン インスタンスに固定量の SNAT ポートが割り当てられます。 この割り当て方法では、特にトラフィック パターンが不均等なために特定の仮想マシンで大量の送信接続が送信された場合に、SNAT 枯渇が発生する可能性があります。 ロード バランサーとは異なり、NAT Gateway ではサブネット内のすべての VM インスタンスに SNAT ポートが動的に割り当てられます。
NAT Gateway では、サブネット内のすべてのインスタンスから、使用可能な SNAT ポートにアクセスできます。 この動的割り当てを使用すると、VM インスタンスでは、使用可能なポート プールから、それぞれ必要な SNAT ポート数を新しい接続に使用できます。 動的割り当てにより、SNAT 枯渇のリスクが軽減されます。
ポートの選択と再利用の動作。
NAT Gateway は、使用可能なポート プールからランダムにポートを選択します。 使用可能なポートがない場合は、同じ宛先パブリック IP とポートへの既存の接続がない限り、SNAT ポートが再利用されます。 NAT Gateway のこのポート選択と再利用動作により、接続タイムアウトが発生する可能性が低くなります。
SNAT とポート使用状況が NAT Gateway に対してどのように機能するかについては、SNAT の基礎に関する記事を参照してください。 送信接続に NAT Gateway を使用できない条件がいくつかあります。 NAT Gateway の制限事項の詳細については、NAT Gateway の制限事項に関する記事を参照してください。
送信接続に NAT Gateway を使用できない場合は、この記事で説明されている他の移行オプションを参照してください。
VM あたりの SNAT ポート数を最大化するようにロード バランサーのアウトバウンド規則を構成する
パブリック Standard Load Balancer を使用しているときに SNAT 枯渇または接続エラーが発生する場合は、手動のポート割り当てでアウトバウンド規則を使用していることを確認してください。 そうでない場合は、ロード バランサーの既定の送信アクセスに依存している可能性が高くなります。 既定の送信アクセスでは、バックエンド プール内のインスタンスの数に基づいて、保守的な数のポートが自動的に割り当てられます。 既定の送信アクセスは、送信接続を有効にするための推奨される方法ではありません。 バックエンド プールのスケーリング時、ポートを再割り当てする必要がある場合、接続に影響がある可能性があります。
既定の送信アクセスと既定のポート割り当ての詳細については、送信接続での送信元ネットワーク アドレス変換に関するページを参照してください。
VM ごとに使用可能な SNAT ポートの数を増やすには、ロード バランサーに手動のポート割り当てを使用してアウトバウンド規則を構成します。 たとえば、バックエンド プール内に最大で 10 台の VM があることがわかっている場合は、VM ごとに、既定の 1,024 ではなく、最大 6,400 の SNAT ポートを割り当てることができます。 さらに SNAT ポートが必要な場合は、送信接続用に複数のフロントエンド IP アドレスを追加して、使用可能な SNAT ポートの数を増やすことができます。 フロントエンド IP アドレスを追加する前に、SNAT ポート枯渇の理由を理解していることを確認してください。
詳細なガイダンスについては、この記事の後半にある「接続を効率的に使用するようにアプリケーションを設計する」を参照してください。 送信接続用の IP アドレスをさらに追加するには、新しい IP ごとにフロントエンド IP 構成を作成します。 アウトバウンド規則が構成されている場合は、バックエンド プールに対して複数のフロントエンド IP 構成を選択できます。 受信と送信接続には、異なる IP アドレスを使用することをお勧めします。 監視とトラブルシューティングを向上させるために、異なる IP アドレスでトラフィックを分離します。
VM に個々のパブリック IP を構成する
小規模なデプロイの場合は、パブリック IP を VM に割り当てることを検討できます。 パブリック IP が VM に割り当てられている場合は、そのパブリック IP によって提供されるすべてのポートを VM で使用できます。 ロード バランサーや NAT Gateway の場合とは異なり、これらのポートにアクセスできるのは、IP アドレスに関連付けられている 1 台の VM のみです。
個々のパブリック IP アドレスを割り当てることはスケーラブルなソリューションではないので、代わりに NAT Gateway の利用を検討することを強くお勧めします。
注意
Azure 仮想ネットワークを、Azure Storage、Azure SQL、Azure Cosmos DB、またはその他の利用可能な Azure サービスなどの Azure PaaS サービスに接続する必要がある場合は、Azure Private Link を活用して SNAT を完全に回避できます。 Azure Private Link は、インターネット経由ではなく Azure バックボーン ネットワーク経由で仮想ネットワークから Azure サービスにトラフィックを送信します。
Private Link は、Azure でホストされるサービスへのプライベート アクセスにおいて、サービス エンドポイントよりも推奨されるオプションです。 Private Link とサービス エンドポイントの違いの詳細については、「プライベート エンドポイントとサービス エンドポイントの比較」を参照してください。
接続効率の高いアプリケーションを設計する
アプリケーションを設計するときは、接続が効率的に使用されるようにします。 接続の効率性により、デプロイされたアプリケーションで SNAT ポートの枯渇を減らしたり排除したりできます。
接続を再利用するようにアプリケーションを変更する
要求ごとに個々のアトミック TCP 接続を生成するのではなく、接続を再利用するようにアプリケーションを構成することをお勧めします。 接続の再利用により、TCP トランザクションのパフォーマンスが向上します。また、これは、接続の再利用が既定である HTTP/1.1 などのプロトコルに特に適しています。 この再利用は、REST などのトランスポートとして HTTP を使用する他のプロトコルに適用されます。
接続プールを使用するようにアプリケーションを変更する
アプリケーションでは接続プーリング スキームを利用します。この場合、要求は、固定された接続セットに内部的に分散され、可能な場合に再利用されます。 このスキームにより、使用中の SNAT ポートの数が制限され、環境の予測可能性が高まります。
このスキームを使用すると、ある操作の応答で 1 つの接続がブロックされている際に同時に複数の操作を行えるようにして、要求のスループットを向上させることができます。
接続プーリングは既に、アプリケーションの開発に使用しているフレームワーク、またはアプリケーションの構成設定の中に存在している可能性があります。 接続プーリングは接続の再利用と組み合わせることができます。 同じ宛先 IP アドレスとポートに対する複数の要求で、固定された予測可能な数のポートを消費します。
要求には、TCP トランザクションを効率的に使用することで、待ち時間とリソース使用率を削減できるメリットがあります。 UDP トランザクションにもメリットがあります。 UDP フローの数を管理することで、枯渇状態を回避して SNAT ポートの使用率を管理できます。
再試行の頻度を抑えるようにアプリケーションのロジックを変更する
SNAT ポートが不足している場合、またはアプリケーションのエラーが発生している場合は、減退やバックオフ ロジックを使わず単純に再試行を繰り返すと、ポート不足が発生したり持続したりします。 SNAT ポートの需要は、再試行の頻度を抑えたロジックを使用することで減らすことができます。
構成されているアイドル タイムアウトによっては、再試行の頻度が高すぎると、接続で SNAT ポートを閉じて解放して再利用するのに十分な時間が取れない場合があります。
キープアライブを使用して送信アイドル タイムアウトをリセットする
ロード バランサーのアウトバウンド規則には、既定で 4 分間のアイドル タイムアウトがありますが、これは最大 100 分まで調整可能です。 TCP キープアライブを使用するとアイドル フローを更新し、必要に応じて、このアイドル タイムアウトをリセットできます。 TCP キープアライブを使用するときは、接続の一方の側で有効にすれば十分です。
たとえば、フローのアイドル タイマーをリセットするときは、サーバー側でのみ有効にすれば十分であり、両側で TCP キープアライブを開始する必要はありません。 データベースのクライアント/サーバー構成など、アプリケーション レイヤーにも同様の概念があります。 サーバー側で、アプリケーション固有のキープアライブのどのようなオプションが存在するかを確認します。
次のステップ
SNAT ポートの枯渇、送信接続オプション、および既定の送信アクセスの詳細については、次を参照してください。