この記事では、Azure NAT ゲートウェイのベスト プラクティスについて説明します。 このガイダンスは、優れたアーキテクチャの 5 つの柱に基づきます。これらはコストの最適化、オペレーショナル エクセレンス、パフォーマンス効率、信頼性、セキュリティです。
Azure NAT Gateway の実用的な知識があり、それぞれの機能を十分に理解していることが前提です。 復習のため、Azure NAT Gateway のドキュメント一式を見直してください。
NAT は "ネットワーク アドレス変換" を表します。 「ネットワーク アドレス変換の概要」を参照してください。
コストの最適化
NAT ゲートウェイの使用を避けるために、Azure Private Link またはサービス エンドポイント (ストレージを含む) 経由で PaaS サービスにアクセスする必要があります。 Private Link とサービス エンドポイントでは、PaaS サービスにアクセスするために NAT ゲートウェイを走査する必要はありません。 このアプローチでは、NAT ゲートウェイのコストと Private Link またはサービス エンドポイントを比較した場合、処理済みデータの GB あたりの料金を低く抑えられます。 Private Link またはサービス エンドポイントを使用した場合、セキュリティ上のさらなる利点があります。
パフォーマンス効率
各 NAT ゲートウェイ リソースでは、最大 50 Gbps のスループットを提供できます。 デプロイを複数のサブネットに分割し、各サブネットまたはサブネットのグループを NAT ゲートウェイに割り当てて、スケールアウトすることができます。
各 NAT ゲートウェイのパブリック IP アドレスは、64,512 個の SNAT ポートを提供します。 1 つの NAT ゲートウェイに最大 16 個の IP アドレスを割り当てることができます。 IP アドレスには、個々の標準パブリック IP アドレス、パブリック IP プレフィックス、またはその両方を指定できます。 同じ宛先エンドポイントへの接続の場合、NAT ゲートウェイは、割り当てられた送信 IP アドレスごとに、TCP と UDP に対してそれぞれ最大 50,000 の同時フローをサポートできます。 詳細については、送信元ネットワーク アドレス変換 (SNAT) に関する次のセクションを参照してください。 TCP は "伝送制御プロトコル"、UDP は "ユーザー データグラム プロトコル" を表します。
SNAT の枯渇
- NAT ゲートウェイ リソースの既定の TCP アイドル タイムアウトは 4 分で、最大 120 分まで構成できます。 この値を既定よりも大きい値に変更した場合、NAT ゲートウェイがフローを保持する時間が長くなり、SNAT ポート インベントリに不要な負荷が発生する可能性があります。
- アトミック要求 (接続ごとに 1 要求) では、規模が制限され、パフォーマンスと信頼性が低下するため、設計の選択肢として貧弱です。 代わりに、HTTP/S 接続を再利用し、接続と関連付けられている SNAT ポートの数を減らします。 接続を再利用すると、アプリケーションのスケーリングが向上します。 TLS を利用すると、ハンドシェイク、オーバーヘッド、暗号化操作による代償が減り、アプリケーションのパフォーマンスが向上します。
- ドメイン ネーム システム (DNS) リゾルバーの結果がクライアントでキャッシュされないとき、DNS ルックアップでは個別フローを大量に導入できます。 DNS キャッシュを使用してフローの量を減らし、SNAT ポートの数を減らします。 DNS とは、インターネットまたはプライベート ネットワークに接続されているリソースの IP アドレスにドメイン名をマッピングするネーミング システムです。
- DNS 参照などの UDP フローでは、アイドル時間中に SNAT ポートを使用します。 UDP アイドル タイムアウト タイマーは 4 分に固定され、変更できません。
- 接続プールを使用し、接続ボリュームを形成します。
- 警告なしで TCP フローを破棄し、TCP タイマーに依存してフローを消去することは決してしないでください。 TCP で明示的に接続を閉じなかった場合、TCP 接続は開いたままになります。 中間システムとエンドポイントでこの接続が使用されたままになり、他の接続に SNAT ポートを利用できなくなります。 このアンチパターンによって、アプリケーション エラーと SNAT 枯渇がトリガーされる可能性があります。
- OS レベルの TCP 終了関連のタイマー値は、影響が専門的にわからない場合、変更しないでください。 TCP スタックの復旧中、接続のエンドポイントで期待値が一致しない場合、アプリケーションのパフォーマンスが低下する可能性があります。 タイマー値の変更は、通常、基になる設計に問題があることを示しています。 基になるアプリケーションにその他のアンチパターンがあると、タイマー値が変更された場合に SNAT 枯渇が増幅することもあります。
サービスの規模や信頼性を改善するため、次のガイダンスをご確認ください。
- TCP アイドル タイムアウトをより小さい値に変更した場合の効果を詳しく調べます。 既定のアイドル タイムアウトの 4 分にすると、SNAT ポート インベントリをもっと早く解放できます。
- 実行時間の長い操作に対しては、非同期ポーリング パターンを使用して他の操作のために接続リソースを解放することを検討します。
- 有効期間の長いフロー (たとえば、再利用された TCP 接続) では、中間システムのタイムアウトを回避するために、TCP キープアライブまたはアプリケーション レイヤー キープアライブを使用する必要があります。アイドル タイムアウトを増やすことは最後の手段であり、根本原因が解決されるとは限りません。 タイムアウトが長いと、タイムアウトの終了時、低い率でエラーが発生し、遅延や不要な障害を引き起こす可能性があります。 TCP キープアライブは、片側の接続から有効にして、両側からの接続を維持できます。
- UDP トラフィックを使用する有効期間の長いフローでは、UDP キープアライブを有効にして接続を維持できます。 UDP キープアライブが片側の接続で有効になっている場合、片側からの接続のみが維持されます。 接続を維持するには、接続の両側で UDP キープアライブを有効にする必要があります。
- 一時的な障害または障害復旧中の積極的な再試行またはバーストを回避するには、グレースフルな再試行パターンを使用する必要があります。 "アトミック接続" と呼ばれるアンチパターンは、すべての HTTP 操作に対して新しい TCP 接続を作成するときに使用されます。 アトミック接続は、アプリケーションのスケーリングを妨げ、リソースを浪費します。 常に複数の操作をパイプラインで同じ接続に渡してください。 アプリケーションにとっては、トランザクション速度とリソース コストの面でメリットがあります。 アプリケーションでトランスポート レイヤー暗号化 (TLS など) を使用する場合、新しい接続の処理に関連する多大なコストがかかります。 その他のベスト プラクティス パターンについては、Azure のクラウド設計パターンに関するページを確認してください。
オペレーショナル エクセレンス
NAT ゲートウェイは Azure Kubernetes Service (AKS) でも使用できますが、AKS の一部としては管理されません。 NAT ゲートウェイを コンテナー ネットワーキング インターフェイス (CNI) サブネットに割り当てる場合は、NAT ゲートウェイ経由で AKS ポッドのエグレスを有効にします。
ゾーン間またはリージョン間で複数の NAT ゲートウェイを使用する場合は、Azure パブリック IP プレフィックスまたは BYOIP プレフィックスを使用して、送信 IP 資産を管理可能な状態にします。 16 IP アドレス (/28 プレフィックス サイズ) を超える IP プレフィックス サイズを NAT ゲートウェイに割り当てることはできません。
Azure Monitor アラートを使用して、SNAT ポートの使用状況、処理またはドロップされたパケット、および送信されたデータの量について監視し、警告します。 NSG フロー ログを使用して、NAT ゲートウェイが構成されたサブネット内の仮想マシン インスタンスからの送信トラフィック フローを監視します。
サブネットが NAT ゲートウェイで構成されている場合、そのサブネット上のすべての VM について、他のすべての送信接続が NAT ゲートウェイによってパブリック インターネットに置き換えられます。 NAT ゲートウェイは、アウトバウンド規則の有無に関係なく、ロード バランサーよりも優先され、VM に直接割り当てられているパブリック IP アドレスよりも優先されます。 Azure では、フローの方向を追跡し、非対称ルーティングは発生しません。 元の受信トラフィックは正しく変換され (ロード バランサーのフロントエンド IP など)、NAT ゲートウェイ経由の元の送信トラフィックとは別に変換されます。 このように分離されていることで、受信および送信サービスをシームレスに共存させることができます。
仮想ネットワークの送信接続を有効にするための既定値として、NAT ゲートウェイを使用することをお勧めします。 NAT ゲートウェイは、Azure の他の送信接続方法よりも効率的なため、運用の複雑さが軽減されます。 NAT ゲートウェイでは、SNAT ポートをオンデマンドで割り当て、より効率的なアルゴリズムを使用して SNAT ポートの再利用の競合を防ぎます。 資産の "既定の送信接続" (アンチパターン) に依存しないでください。 代わりに、NAT ゲート ウェイ リソースを使用して明示的に定義します。
[信頼性]
NAT ゲートウェイのリソースは 1 つの可用性ゾーン内で高可用性であり、複数の障害ドメインにまたがります。 NAT ゲートウェイは、AZURE が NAT ゲートウェイを配置するゾーンを自動的に選択する "ゾーンなし" にデプロイできます。 NAT ゲートウェイは、ユーザーが特定のゾーンに分離することもできます。
各サブネットに特定のゾーン内のリソースのみが含まれている場合を除き、可用性ゾーンの分離を指定することはできません。 代わりに、VM がデプロイされている各可用性ゾーンのサブネットをデプロイし、一致するゾーン NAT ゲートウェイに合わせてゾーン VM を配置して、個別のゾーン スタックを構築します。 たとえば、可用性ゾーン 1 の仮想マシンが、可用性ゾーン 1 にしかない他のリソースが含まれるサブネット上にあるとします。 NAT ゲートウェイは、そのサブネットを提供するために、可用性ゾーン 1 で構成されます。 次の図を参照してください。
仮想ネットワークとサブネットは、リージョン内のすべての可用性ゾーンにまたがっています。 ゾーン リソースに対応するために、可用性ゾーンでそれらを分割する必要はありません。
セキュリティ
NAT ゲートウェイを使うと、個々の 仮想マシン (または他のコンピューティング リソース) でパブリック IP アドレスが必要なくなり、完全にプライベートな状態を維持できます。 パブリック IP アドレスを持たないリソースでも、仮想ネットワークの外部にある外部ソースに引き続き到達できます。 また、パブリック IP プレフィックスを関連付けて、IP の連続するセットがアウトバウンド接続に使用されるようにできます。 この予測可能な IP リストに基づいて、宛先ファイアウォール規則を構成できます。
一般的なアプローチは、サードパーティのファイアウォールまたはプロキシ サーバーを使用して、送信専用ネットワーク仮想アプライアンス (NVA) のシナリオを設計することです。 NVA の仮想マシン スケールセットで NAT ゲートウェイをサブネットにデプロイすると、これらの NVA では、ロード バランサーの IP や個々の IP ではなく、NAT ゲートウェイ アドレスが送信接続に使用されます。 このシナリオを Azure Firewall で使用するには、「Azure Firewall と Azure Standard Load Balancer を統合する」を参照してください。
Microsoft Defender for Cloud では、NAT ゲートウェイ経由の疑わしい送信接続を監視できます。 これは Microsoft Defender for Cloud のアラート機能です。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Ethan Haslett | シニア クラウド ソリューション アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。