冗長性の先にある「真の可用性」：マルチAZ NATゲートウェイ設計の深淵
クラウドネイティブなインフラにおいて、NATゲートウェイ（NATGW）は単なるインターネットへの出口ではない。それは、プライベートサブネットに潜むコンテナやインスタンスの「生命線」であり、同時にパフォーマンスのボトルネックにもなり得る二面性を持ったコンポーネントだ。
多くのアーキテクトが「NATGWをAZごとに配置せよ」と教えられ、それを遵守する。しかし、なぜそうするのか、その背後でパケットがどのような運命を辿るのか、そしてTCPのハンドシェイクにどのような影を落とすのかまで語れる者は少ない。今回は、単なる設計論を超えた、ネットワークの深層心理に迫る。
なぜ「シングルAZ NATGW」が悪夢の入り口なのか
単一のAZにNATGWを配置するということは、そのAZの物理的な障害が、インターネット通信を行うすべてのリソースの「即死」を意味する。これは可用性の問題以前に、設計としての不完全さだ。
だが、真に恐ろしいのは可用性だけではない。「AZ跨ぎのデータ転送料金」と「レイテンシ」だ。アプリケーションがAZ-Aにあり、NATGWがAZ-Bにある場合、パケットはAZ間を往復する。このわずか数ミリ秒のRTT（Round Trip Time）の増加が、TLSハンドシェイクの反復において、致命的なパフォーマンス低下を引き起こす。特にAPIのマイクロサービス化が進む環境では、この積み重ねがユーザー体験を確実に劣化させる。
アーキテクチャの最適解：AZ独立型NATGW
ベストプラクティスは、各AZにNATGWを配置し、ルーティングテーブルをAZごとに分割することだ。
# AWS CLIを用いたルーティングテーブルの分離イメージ
# 各AZ専用のルートテーブルを作成し、デフォルトルートをそのAZのNATGWへ向ける
aws ec2 create-route --route-table-id rtb-az1-private --destination-cidr-block 0.0.0.0/0 --gateway-id nat-az1
aws ec2 create-route --route-table-id rtb-az2-private --destination-cidr-block 0.0.0.0/0 --gateway-id nat-az2この構成により、パケットは常に「最短距離」で外部へ出る。AZ障害時には、該当するAZのサブネットへのトラフィックが遮断されるが、別のAZで稼働しているインスタンスは、自身のローカルAZのNATGWを通じて通信を継続できる。
パケットレベルの深淵：TCPチューニングとボトルネックの回避
NATGWはIPマスカレード（NAPT）を行うため、変換テーブルを保持する。ここで重要になるのが、tcp_tw_reuse や tcp_fin_timeout といったLinuxカーネルのネットワークスタックとの相性だ。
大量の短命な接続（Short-lived Connections）が発生するKubernetesクラスターでは、NATGWのポート枯渇が頻発する。これを防ぐには、クライアント側で接続プールを適切に管理するだけでなく、カーネルパラメータを最適化する必要がある。
# /etc/sysctl.conf での推奨設定例
# TIME_WAIT状態のソケットを再利用し、ポート枯渇を緩和する
net.ipv4.tcp_tw_reuse = 1
# TCP FIN-WAIT-2のタイムアウトを短縮し、リソース解放を早める
net.ipv4.tcp_fin_timeout = 15
# TCPバッファを拡大し、高スループット環境での遅延を抑える
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216TLSハンドシェイクとRTTの最適化
NATGWを介した通信において、TLSのハンドシェイクは3回のRTTを消費する。ここでNATGWの配置が最適でないと、ハンドシェイク完了までに余分なAZ間転送が走り、アプリケーションのレスポンスタイムが目に見えて悪化する。
最近では TLS 1.3 の導入が標準だが、これには 0-RTT データ送信という強力な武器がある。NATGWが適切に配置され、クライアントとNATGW間の物理的な距離が最小化されていれば、TLS 1.3 の恩恵を最大限に引き出せる。
セキュリティの観点：NATGWとEgressフィルター
NATGWはあくまで「出口」である。最近の脅威モデルでは、NATGWの背後でどのようなドメインにアクセスしているかを可視化する Egress Gateway（Istio等のサービスメッシュ機能）との併用が不可欠だ。NATGW自体にはL7の制御能力はないため、パケットの送信先IPだけでなく、通信内容の正当性を検証する層を別途設けることが、現代のセキュリティスペシャリストの矜持と言える。
最後に：ネットワークは「生き物」である
クラウドネットワークは、仮想化された抽象レイヤーの上に成り立っているが、その下には常に物理的なインフラが存在する。AZごとにNATGWを配置するのは、単なる「おまじない」ではない。それは、物理的な距離と故障ドメインを意識した、エンジニアによる「空間設計」そのものだ。
君たちが構築するインフラが、パケットにとって最も自然で、最も効率的な経路を通るように設計してほしい。その先に、真に堅牢で高速なシステムが待っている。
トラブルシューティングの際、tcpdump を実行した瞬間にパケットの呼吸が聞こえてくるようになれば、君も一人前のクラウド・ネットワーク・アーキテクトだ。
コメント