送信接続 (クラシック)
Azure では、いくつかの異なるメカニズムを通じて顧客デプロイの送信接続を提供します。 この記事では、どのようなシナリオがあり、それらがいつ適用されるかについて説明するほか、それらのシナリオのしくみと管理方法について説明します。
注意
この記事では、クラシック デプロイについてのみ説明します。 Azure でのすべての Resource Manager デプロイ シナリオについては、「送信接続」をご覧ください。
Azure のデプロイは、パブリック IP アドレス空間で Azure 外部のエンドポイントと通信できます。 インスタンスがパブリック IP アドレス空間の宛先への送信フローを開始すると、Azure によってプライベート IP アドレスがパブリック IP アドレスに動的にマッピングされます。 このマッピングが作成されると、この送信フローの戻りトラフィックも、フローの送信元であるプライベート IP アドレスに到達できます。
Azure は送信元ネットワーク アドレス変換 (SNAT) を使用してこの機能を実行します。 複数のプライベート IP アドレスが単一のパブリック IP アドレスでマスカレードされている場合、Azure ではポート アドレス変換 (PAT) を使用してプライベート IP アドレスがマスカレードされます。 エフェメラル ポートが PAT に使用され、プール サイズに基づいて事前に割り当てられます。
送信シナリオは複数あります。 必要に応じて、これらのシナリオを組み合わせることができます。 これらを注意深く確認して、実際のデプロイメント モデルとアプリケーション シナリオに適用される際の機能、制約、パターンを把握してください。 また、これらのシナリオを管理するためのガイダンスを確認してください。
シナリオの概要
Azure では、送信接続のクラシック デプロイを実現するために、3 つの異なる方法が提供されます。 すべてのクラシック デプロイで、3 つのシナリオすべてを使用できるわけではありません。
| シナリオ | Method | IP プロトコル | 説明 | Web worker ロール | IaaS |
|---|---|---|---|---|---|
| 1. インスタンス レベルのパブリック IP アドレスを持つ VM | SNAT (ポート マスカレードは不使用) | TCP、UDP、ICMP、ESP | Azure は仮想マシンに割り当てられたパブリック IP アドレスを使います。 インスタンスには、使用可能なすべてのエフェメラル ポートがあります。 | いいえ | はい |
| 2. パブリックに負荷分散されたエンドポイント | パブリック エンドポイントに対するポート マスカレード (PAT) による SNAT | TCP、UDP | Azure は、複数のプライベート エンドポイントとパブリック IP アドレスのパブリック エンドポイントを共有します。 Azure は、PAT のパブリック エンドポイントのエフェメラル ポートを使います。 | はい | はい |
| 3. スタンドアロン VM | ポート マスカレード (PAT) による SNAT | TCP、UDP | Azure は自動的に、SNAT のパブリック IP アドレスを指定し、このパブリック IP アドレスをデプロイ全体で共有して、PAT のパブリック エンドポイント IP アドレスのエフェメラル ポートを使います。 これは、上記のシナリオのフォールバック シナリオです。 可視性と制御が必要は場合は推奨されません。 | はい | はい |
これは、Azure の Resource Manager デプロイで使用できる送信接続機能のサブセットです。
クラシックの異なるデプロイには、異なる機能があります。
| 従来のデプロイ | 使用可能な機能 |
|---|---|
| 仮想マシン | シナリオ 1、2、または 3 |
| Web worker ロール | シナリオ 2、3 のみ |
軽減策にも同様の違いがあります。
クラシック デプロイで PAT のエフェメラル ポートの事前割り当てに使用されるアルゴリズムは、Azure Resource Manager リソース デプロイの場合と同じです。
シナリオ 1: インスタンス レベルのパブリック IP アドレスがある VM
このシナリオでは、VM にはインスタンス レベルのパブリック IP (ILPIP) が割り当てられています。 送信接続に関する限り、VM に負荷分散されたエンドポイントがあるかどうかは関係ありません。 このシナリオは他のシナリオよりも優先されます。 ILPIP が使用される場合、すべての送信フローで VM によって ILPIP が使用されます。
VM に割り当てられたパブリック IP は、(1 対多ではなく) 1 対 1 の関係であり、1 対 1 のステートレス NAT として実装されます。 ポート マスカレード (PAT) は使用されず、VM は使用可能なすべてのエフェメラル ポートを備えます。
アプリケーションが多数の送信フローを開始したために SNAT ポート不足が発生した場合は、SNAT の制約を軽減するために ILPIP を割り当てることを検討してください。 その全体像については、SNAT 不足の管理に関するセクションを確認してください。
シナリオ 2: パブリックに負荷分散されたエンドポイント
このシナリオでは、VM または Web worker ロールは、負荷分散されたエンドポイントを通してパブリック IP アドレスに関連付けられます。 VM にパブリック IP アドレスは割り当てられていません。
負荷分散 VM が送信フローを作成すると、Azure が、送信フローのプライベート ソース IP アドレスを、パブリックに負荷分散されたエンドポイントのパブリック IP アドレスに変換します。 Azure は、SNAT を使用してこの機能を実行します。 また、Azure は、PAT を使用して、複数のプライベート IP アドレスをパブリック IP アドレスでマスカレードします。
ロード バランサーのパブリック IP アドレス フロントエンドのエフェメラル ポートを使用して、VM から送信される個々のフローが区別されます。 送信フローが作成されると、事前に割り当てられたエフェメラル ポートが SNAT によって動的に使用されます。 ここでは、SNAT で使用されるエフェメラル ポートを SNAT ポートと呼びます。
SNAT ポートは、「SNAT と PAT の理解」の説明のとおり事前に割り当てられます。 これは有限のリソースであり、不足する可能性があります。 これらがどのように消費されるのかを理解することが重要です。 この消費のための設計と移行を必要に応じて行う方法については、SNAT 不足の管理に関するセクションを確認してください。
複数のパブリック負荷分散エンドポイントが存在する場合、これらのパブリック IP アドレスのいずれかが送信フローの候補となり、ランダムに選択されます。
シナリオ 3: パブリック IP アドレスが関連付けられていない
このシナリオでは、VM または Web worker ロールはパブリックに負荷分散されたエンドポイントの一部ではありません。 そして、VM の場合は、ILPIP アドレスは割り当てられていません。 VM が送信フローを作成すると、Azure が、送信フローのプライベート ソース IP アドレスをパブリック ソース IP アドレスに変換します。 この送信フローで使用されるパブリック IP アドレスは構成不可能であり、サブスクリプションのパブリック IP リソースの制限に対してカウントされません。 Azure は、このアドレスを自動的に割り当てます。
Azure は、SNAT とポート マスカレード (PAT) を使用してこの機能を実行します。 このシナリオは、使用される IP アドレスに対するコントロールがない点を除いて、シナリオ 2 に類似しています。 これは、シナリオ 1 および 2 がない場合のフォールバック シナリオです。 このシナリオは、送信アドレスに対するコントロールが必要な場合は推奨されません。 発信接続がアプリケーションの重要な部分である場合は、別のシナリオを選ぶ必要があります。
SNAT ポートは、「SNAT と PAT の理解」の説明のとおり事前に割り当てられます。 パブリック IP アドレスを共有する VM または Web worker ロールの数により、事前に割り当てられるエフェメラル ポートの数が決まります。 これらがどのように消費されるのかを理解することが重要です。 この消費のための設計と移行を必要に応じて行う方法については、SNAT 不足の管理に関するセクションを確認してください。
SNAT と PAT の理解
ポート マスカレード SNAT (PAT)
デプロイが送信接続を行うときは、各送信接続ソースが書き換えられます。 ソースは、(上記のシナリオに基づいて) プライベート IP アドレス空間から、デプロイに関連付けられたパブリック IP アドレスに書き換えられます。 パブリック IP アドレス空間では、フローの 5 タプル (ソース IP アドレス、ソース ポート、IP 転送プロトコル、宛先 IP アドレス、宛先ポート) は一意である必要があります。
これを実現するために、プライベート ソース IP アドレスの書き換え後にエフェメラル ポート (SNAT ポート) が使用されます。これは複数のフローが単一のパブリック IP アドレスから送信されるためです。
1 つの SNAT ポートは、1 つの宛先 IP アドレス、ポート、プロトコルへの 1 つのフローで消費されます。 同じ宛先 IP アドレス、ポート、プロトコルへの複数のフローでは、各フローが 1 つの SNAT ポートを消費します。 これにより、同じパブリック IP アドレスから送信されて同じ宛先 IP アドレス、ポート、プロトコルに移動する複数のフローが、一意であることが保証されます。
別の宛先 IP アドレス、ポート、プロトコルへの複数のフローは、宛先ごとに 1 つの SNAT ポートを共有します。 宛先 IP アドレス、ポート、プロトコルによってフローは一意になります。パブリック IP アドレス空間でフローを区別するための追加のソース ポートは必要ありません。
SNAT ポート リソースがなくなると、既存のフローによって SNAT ポートが解放されない限り、送信フローは失敗します。 Load Balancer はフローが終了すると SNAT ポートを回収します。また、4 分間のアイドル タイムアウトを使用して、アイドル フローからの SNAT ポートを回収します。
SNAT ポート不足を引き起こしやすい状態を軽減するパターンについては、SNAT の管理に関するセクションを確認してください。
ポート マスカレード SNAT (PAT) 用のエフェメラル ポートの事前割り当て
Azure では、アルゴリズムを使用して、割り当てられる利用可能な SNAT ポートの数が決定されます。これは、ポート マスカレード SNAT (PAT) を使用する際のバックエンド プールのサイズに基づきます。 SNAT ポートは、特定のパブリック IP ソース アドレスについて使用可能なエフェメラル ポートです。
特定のパブリック IP アドレスを共有する VM または Web worker ロールのインスタンスの数に基づいてインスタンスがデプロイされる場合、Azure は SNAT ポートを事前に割り当てます。 送信フローが作成されると、これらのポートは (事前に割り当てられた上限に達するまで) PAT によって動的に消費されます。そして、フローが終了するかアイドル タイムアウトが発生すると解放されます。
次の表は、バックエンド プール サイズのレベルに対する SNAT ポートの事前割り当てを示しています。
| インスタンス | インスタンスあたりの事前に割り当てられる SNAT ポート |
|---|---|
| 1-50 | 1,024 |
| 51-100 | 512 |
| 101-200 | 256 |
| 201-400 | 128 |
利用できる SNAT ポートの数が、そのままフローの数に変換されるわけではないことに注意してください。 複数の一意の送信先に単一の SNAT ポートを再利用できます。 ポートは、フローを一意にするために必要な場合にのみ消費されます。 設計と軽減策のガイダンスについて、この有限のリソースを管理する方法に関するセクション、および PAT について説明しているセクションを参照してください。
デプロイのサイズを変更すると、確立されたフローの一部に影響が及ぶ可能性があります。 バックエンド プール サイズが増加し、次のレベルに移行すると、1 つ大きいバックエンド プール レベルに移行する間に、事前に割り当てられた SNAT ポートの半分が回収されます。 回収された SNAT ポートに関連付けられているフローはタイムアウトになるので、再確立する必要があります。 新しいフローを試みると、事前に割り当てられたポートが使用可能な限り、フローはすぐに成功します。
デプロイのサイズが減少し、1 つ小さいレベルに移行すると、使用できる SNAT ポートが増えます。 この場合、割り当てられている既存の SNAT ポートと各フローに影響はありません。
クラウド サービスを再デプロイまたは変更した場合、インフラストラクチャでバックエンド プールが実際の最大 2 倍であると一時的に報告されることがあります。その結果、Azure によって事前に割り当てられるインスタンスあたりの SNAT ポート数が想定よりも少なくなります。 これにより、一時的に SNAT ポート不足が発生する可能性が高くなります。 最終的に、プールのサイズは実際のサイズに移行し、Azure によって事前に割り当てられる SNAT ポート数は、前述の表に従って想定される数まで自動的に増えます。 この動作は仕様であり、構成できません。
SNAT ポートの割り当ては、IP トランスポート プロトコル固有であり (TCP と UDP は別々に管理されます)、次の条件下で解放されます。
TCP SNAT ポートの解放
- サーバーとクライアントの両方が FIN/ACK を送信すると、SNAT ポートは 240 秒後に解放されます。
- RST が送信されると、SNAT ポートは 15 秒後に解放されます。
- アイドル タイムアウトに達した場合。
UDP SNAT ポートの解放
- アイドル タイムアウトに達した場合。
問題の解決
このセクションの内容は、SNAT の枯渇や、Azure の送信接続で発生する可能性のある他のシナリオを軽減するのに役立ちます。
SNAT (PAT) ポート不足の管理
パブリック IP アドレスが関連付けられていない場合やパブリックに負荷分散されたエンドポイントの場合に説明したように、PAT に使われるエフェメラル ポートは枯渇する可能性のあるリソースです。
同じ宛先 IP アドレスとポートに対して多数の TCP 送信接続または UDP 送信接続が開始されることがわかっている場合、送信接続エラーが出る場合、または SNAT ポート (PAT によって使用される事前割り当て済みのエフェメラル ポート) が不足しているとサポートから指摘された場合、いくつかの一般的な軽減策の選択肢があります。 これらのオプションを確認し、使用可能であり、実際のシナリオに最適な選択肢を判断してください。 それらを 1 つまたは複数組み合わせることが状況改善に役立つ場合もあります。
送信接続の動作の理解が難しい場合は、IP スタック統計 (netstat) を使用できます。 また、パケット キャプチャを使用した接続動作を観察することも効果的です。
接続を再利用するようにアプリケーションを変更する
SNAT に使用される一時ポートの需要は、アプリケーションで接続を再利用することで減らすことができます。 これには、既定で接続が再利用される HTTP/1.1 などのプロトコルが特に有効です。 また、HTTP が転送に使用されるその他のプロトコル (REST など) も活用できます。
要求ごとに個別にアトミック TCP 接続するよりも、再利用するほうが常に効果的です。 再利用は、TCP トランザクションのパフォーマンス向上と大幅な効率化につながります。
接続プールを使用するようにアプリケーションを変更する
アプリケーションでは接続プーリング スキームを利用できます。この場合、接続の固定セットに対して要求が内部的に分散されます (各要求で利用可能な接続が再利用されます)。 このスキームにより、使用される一時ポートの数が制限され、環境の予測可能性が高まります。 さらに、このスキームを使用すると、ある操作の応答で 1 つの接続がブロックされている際に同時に複数の操作を行えるようにして、要求のスループットを向上させることもできます。
接続プーリングは既に、アプリケーションの開発に使用しているフレームワーク、またはアプリケーションの構成設定の中に存在している可能性があります。 接続プーリングは接続の再利用と組み合わせることができます。 同じ宛先 IP アドレスとポートに対する複数の要求で、固定された予測可能な数のポートを消費します。 これらの要求で、TCP トランザクションを非常に効率的に使用して、待ち時間とリソース使用率を減らすこともできます。 また、UDP フローの数を管理すると不足状態を回避して SNAT ポートの使用率を管理できるので、UDP トランザクションにもメリットがあります。
再試行の頻度を抑えるようにアプリケーションのロジックを変更する
PAT に使用される事前割り当て済みのエフェメラル ポートが不足している場合、またはアプリケーションのエラーが発生している場合、減退やバックオフ ロジックを使わず単純に再試行を繰り返すと、ポート不足が発生したり持続したりします。 エフェメラル ポートの需要は、再試行の頻度を抑えたロジックを使用することで減らすことができます。
エフェメラル ポートには 4 分間のアイドル タイムアウトが設定されています (調整不可)。 再試行の頻度が高すぎた場合、不足が自動的に解消されることはありません。 そのため、アプリケーションがトランザクションを再試行する方法と頻度を考慮することは、設計において非常に重要です。
インスタンスレベル パブリック IP を個々の VM に割り当てる
ILPIP を割り当てることで、インスタンスレベル パブリック IP を VM に割り当てるシナリオに移行します。 この VM で、VM ごとに使用されるパブリック IP のすべてのエフェメラル ポートを使用できます。 (パブリック IP のエフェメラル ポートが、それぞれのデプロイに関連付けられているすべての VM と共有されるシナリオとは対照的です)。多数の個々の IP アドレスを許可リストに登録する場合の潜在的な影響など、考慮すべきトレードオフがあります。
Note
このオプションは、worker ロールでは使用できません。
キープアライブを使用して送信アイドル タイムアウトをリセットする
送信接続には、4 分間のアイドル タイムアウトが設けられています。 このタイムアウトは調整できません。 ただし、必要に応じて、転送 (TCP キープアライブなど) またはアプリケーション レイヤー キープアライブを使用して、アイドル フローを更新したりこのアイドル タイムアウトをリセットしたりできます。 これがサポートされているかどうか、またはそれを有効にする方法については、パッケージ化されたソフトウェアの供給元に問い合わせてください。 一般に、アイドル タイムアウトをリセットするには、一方の側だけがキープアライブを生成する必要があります。
VM で使用されるパブリック IP の検出
送信接続のパブリック ソース IP アドレスを判別する方法は多数あります。 OpenDNS によって提供されるサービスで、VM のパブリック IP アドレスを表示できます。
nslookup コマンドを使用することで、名前 myip.opendns.com に関する DNS クエリを OpenDNS Resolver に送信できます。 このサービスは、クエリの送信に使用されたソース IP アドレスを返します。 VM から次のクエリを実行すると、その VM で使用されるパブリック IP が応答として返されます。
nslookup myip.opendns.com resolver1.opendns.com
次のステップ
- Resource Manager デプロイで使われている Load Balancer の詳細を確認する
- Resource Manager デプロイで利用できる送信接続シナリオの詳細を確認する