NATゲートウェイの「IP固定」という名の深い沼 —— パフォーマンスと可用性を最大化する設計論
クラウドネイティブなアーキテクチャにおいて、NATゲートウェイ（NATGW）は単なる「外に出るためのゲート」ではない。それは、プライベートな世界と荒野（パブリックインターネット）を隔てる、極めて重要な境界線だ。
多くのジュニアエンジニアは「NATGWはとりあえず作っておけばいい」と考える。しかし、我々のようなSREの視点から言わせれば、NATGWは「TCPコネクションの終端であり、セキュリティの要塞であり、そしてパケットの寿命を支配する管理者」である。
今回は、Elastic IP（EIP）のバインド仕様から、パケットレベルの最適化まで、現場の泥臭い知見を交えて解説する。
—
1. なぜNATGWにはEIPが必須なのか：アーキテクチャの真実
NATGWを作成する際、EIPを明示的に割り当てるのは「単なる識別子」のためではない。それは、「予測可能性（Predictability）」を担保するためだ。
AWSにおいて、NATGWにEIPを割り当てないという選択肢はない（そもそもAWSマネージドNATGWは作成時にEIPの指定が必須だ）。なぜなら、EIPが動的に変わる世界では、セキュリティグループやファイアウォールによるIPホワイトリスト運用が破綻するからだ。
EIPアソシエーションの挙動とダウンタイム
NATGWのEIPを変更（再アソシエーション）する場合、バックエンドのコンポーネントが切り替わる際に、一瞬の「パケットの消失」が発生する。これはTCPのコネクション追跡（Conntrack）テーブルがNATGWの切り替えと共にフラッシュされるためだ。
ダウンタイムを最小化する戦術:
1. Blue/Green NATGW戦略: 新しいNATGWを別サブネットで構築し、ルートテーブルのターゲットを切り替える。
2. コネクションの緩やかなドレイン: 切り替え前に既存のコネクションを終了させるようアプリケーション層で制御する。
—
2. パケットレベルの深層：TCPバッファとNATの相性
NATGWは、膨大な数のTCPコネクションを、限られたIPアドレスとポート範囲（65535ポート）にマッピングする。ここで最も恐ろしいのは「ポート枯渇（Port Exhaustion）」だ。
NATのボトルネックを打破する
もし50,000リクエスト/秒を一つのNATGWで捌こうとすれば、タイムスタンプやシーケンス番号の管理以前に、NATテーブルが溢れる。
- TCPバッファチューニング: 送信側のインスタンスで
tcp_tw_reuseを有効にしても、NATGWの背後ではNATによるポート変換がボトルネックとなる。 - Keep-Aliveの最適化: 接続のたびにSYN/ACKを繰り返すと、RTT（Round Trip Time）だけでなく、NATテーブルの消費も加速する。HTTP/2やgRPCを活用し、コネクションを再利用することで、NAT変換のオーバーヘッドを劇的に下げることが可能だ。
# LinuxカーネルのTCPスタックを調整し、NATゲートウェイへの負荷を軽減する
# 接続終了後のTIME_WAIT状態のソケットを再利用可能にする
sysctl -w net.ipv4.tcp_tw_reuse=1
# TCPの送受信バッファを拡大し、スループットを向上させる
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"—
3. セキュリティとネットワークヘッダーの深淵
NATゲートウェイを通過する際、パケットヘッダーは書き換えられる。ここで意識すべきは、「MSS（Maximum Segment Size）の調整」だ。
MTU（Maximum Transmission Unit）が標準の 1500 バイトであっても、カプセル化やトンネリングが絡む場合、NATGWを通過するパケットが断片化（Fragmentation）を起こす可能性がある。断片化はCPU負荷を増大させ、IDS/IPS（侵入検知/防御システム）のバイパスを許す脆弱性にも繋がる。
推奨設定：MSSクランプ
以下のコマンドで、TCPハンドシェイク時にMSSを適切に制御し、パケット分割を未然に防ぐ。
# iptablesを用いて、TCP SYNパケットのMSS値を調整（TCP MSS Clamping）
# これにより、パスMTUディスカバリが失敗してもパケット断片化を防げる
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360—
4. 結論：NATGWは「管理されるべきインフラ」である
NATゲートウェイを「作って終わり」のブラックボックスにしてはいけない。
1. メトリクスの監視: ErrorPortAllocation や ActiveConnectionCount をCloudWatchで監視し、閾値を超えたらアラートを上げる。これができていない組織は、いずれサービス断という名の「ツケ」を払うことになる。
2. EIPのIPレピュテーション: NATGWのEIPがブラックリスト入りしていないか、時折チェックが必要だ。共有インフラにおいて、前任者が汚したIPを引き継ぐリスクは常に存在する。
ネットワークは生き物だ。パケットの旅路を可視化し、カーネルレベルのチューニングを怠らないこと。それが、真のクラウドアーキテクトに求められる「職人芸」なのだ。
NATゲートウェイの向こう側で何が起きているか——その解像度こそが、あなたのサービスの信頼性を決定づける。
コメント