NATゲートウェイの「64kの壁」：ポート枯渇が招くネットワークの静寂と、SREが打つべき一手
クラウドネイティブな環境において、NATゲートウェイ（NAT GW）は魔法の杖のように見える。プライベートサブネットのインスタンスたちが、インターネットという大海原へ安全に、かつ透過的にアクセスするためのゲートウェイだ。しかし、この「魔法の門」には、TCP/IPの物理的な制約という冷徹な現実が刻まれている。
多くのエンジニアが運用開始から数ヶ月後に直面する「ポート枯渇（Port Exhaustion）」。今日は、この見えざるパケット破棄のメカニズムを、プロトコル層から分解し、どのように監視し、どうアーキテクチャで回避すべきかを語ろう。
1. なぜ「64,000」なのか：ポート枯渇の解剖学
NATゲートウェイが行っているのは、プライベートIPと送信元ポートの組み合わせを、パブリックIPと「エフェメラルポート（一時ポート）」の組み合わせに書き換えることだ（SNAT）。
TCPパケットのヘッダーには Source Port という16ビットのフィールドがある。つまり、理論上の最大値は $2^{16} = 65,536$ だ。しかし、実際にはシステム予約ポートやNAT GWの内部的なオーバーヘッドを差し引く必要がある。
ここで重要なのは、「1つのNAT GW、1つのプライベートIP、1つの接続先（IP:Port）」のペアで、このポートが消費されるということだ。
- 何が起きているか:
SYNパケットを送信した瞬間、NAT GWは送信元ポートを確保する。コネクションがFINまたはRSTで終了した後も、TIME_WAIT状態の期間中、そのポートは再利用できない。 - ポート枯渇の瞬間: 突発的なトラフィックバーストにより、秒間6万以上のコネクションがアクティブな状態を維持すると、新規の
SYNパケットは、NAT GWのポートアロケーターによって無慈悲にドロップされる。これがErrorPortAllocationの正体だ。
2. メトリクスによる「静かな死」の可視化
CloudWatchやAzure Monitorで見逃してはならないのは、単純なパケットロス率ではない。NAT GWが発する特定のメトリクスだ。
- AWSの場合:
ErrorPortAllocation - Azureの場合:
SNAT Connection Count
これらが閾値を超えた瞬間、サービスは「インターネットに繋がらない」という抽象的な障害を報告し始める。これを防ぐためのアラート設計は、CPU使用率のような「事後」の監視ではなく、「ポート使用率の傾向」を監視する必要がある。
# AWS CLIでNAT GWのポート使用状況を確認する例
aws cloudwatch get-metric-statistics \
--namespace "AWS/NATGateway" \
--metric-name "ErrorPortAllocation" \
--dimensions Name=NatGatewayId,Value=nat-0123456789abcdef \
--start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 60 \
--statistics Sum3. トランスポート層の最適化：泥臭いチューニング
ポート枯渇を回避する最も直接的かつ強力なアプローチは、「コネクションを使い回す」ことだ。
HTTP Keep-Aliveと接続プーリング
クライアント（アプリケーション）側で Connection: keep-alive を有効にすることは必須だ。多くの開発者がこれを忘れている。コネクションを再利用すれば、TCPの3ウェイハンドシェイク（SYN, SYN-ACK, ACK）のオーバーヘッドと、ポートの再確保を削減できる。
TCPバッファと TIME_WAIT の制御
Linuxカーネルレベルで tcp_tw_reuse を有効にすることも検討すべきだが、現代のNAT環境下では慎重さが必要だ。
# /etc/sysctl.conf に追記し、TIME_WAITの再利用を促進する
# ※ただし、NAT背後でのタイムスタンプ検証と競合しないか検証すること
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15 # FIN待ち時間を短縮4. アーキテクチャによる脆弱性の回避：スケールアウト戦略
もし、アプリケーションの特性上、どうしても短命な接続が大量に発生する（マイクロサービス間の激しい通信など）のであれば、単一のNAT GWに固執してはいけない。
1. NAT GWの分散: サブネットごとにNAT GWを配置する。これにより、ポートの予算を論理的に分割できる。
2. VPCエンドポイントの活用: S3やDynamoDBへの通信は、NAT GWを経由させず、必ず Gateway型 または Interface型 のVPCエンドポイントを利用すること。これでNAT GWのポート消費を劇的に抑えられる。
3. IPv6デュアルスタック化: 可能であれば、通信先をIPv6に倒す。IPv6にはNATという概念そのものが存在しないため、ポート枯渇という概念から完全に解放される。
最後に：エンジニアとしての矜持
ポート枯渇エラーは、インフラが「これ以上は無理だ」と悲鳴を上げているサインだ。ただ単にNAT GWを増やすのではなく、パケットがどのエンドポイントに向かい、なぜそれほど多くのセッションを占有しているのかを tcpdump や netstat で徹底的に追跡してほしい。
プロトコルスタックの奥底を理解し、トラフィックを制御する。それこそが、堅牢なクラウドインフラを構築するSREの醍醐味だ。次にコンソールで ErrorPortAllocation を見たときは、焦るのではなく、アーキテクチャを洗練させる絶好の機会だと捉えてほしい。
ネットワークは嘘をつかない。すべてはパケットの中に答えがある。
コメント