クラウドネットワークの「見えないコスト」をハックする：マルチAZ NATゲートウェイの最適化戦略
クラウドインフラの設計において、我々SREが直面する最大のジレンマの一つが「可用性とコストのトレードオフ」だ。特にAWSやGCPのようなメガクラウドにおいて、マルチAZ構成は「正義」とされるが、その裏でパケットがAZの境界を越えるたびに課金カウンターが回っている事実は、意外と見落とされている。
今日は、特にNATゲートウェイ（NAT GW）という「金食い虫」を、パケットレベルの挙動とOSカーネルのチューニングからどう御していくか、その泥臭い最適化戦略について深く掘り下げたい。
—
1. なぜ「NAT GW」がコストのボトルネックになるのか
NAT GWを経由するトラフィックには、二重のコストが課せられる。
1. NAT GW自体の時間課金
2. データ処理量に対する課金（GB単位）
3. AZ間データ転送料金（クロスAZトラフィック）
特に見落とされがちなのが、Private Subnet 内のアプリケーションが、別AZにあるNAT GWへパケットを投げた瞬間に発生する「AZ間転送コスト」だ。これを回避する鉄則は、「NAT GWはAZごとに配置し、ルーティングテーブルで当該AZ内のNAT GWを優先させる」ことに尽きる。
しかし、単に配置するだけでは足りない。パケットの往来を最小化するためのチューニングこそが、真のエンジニアの腕の見せ所だ。
—
2. カーネルレベルでの最適化：RTTとTCPスタックの制御
NAT GWはステートフルなデバイスだ。大量のコネクションが集中すると、ポート枯渇やコネクショントラッキング（conntrack）のオーバーヘッドが問題になる。これを防ぐには、アプリケーション層だけでなく、Linuxカーネルの設定がモノを言う。
TCPバッファとコネクションのチューニング
sysctl.conf で調整すべきは、単なるバッファサイズではない。tcp_tw_reuse や tcp_fin_timeout を適切に設定し、NAT GW側のポートを効率的に再利用させる必要がある。
# /etc/sysctl.conf への推奨設定
# TIME_WAIT状態のソケットを再利用可能にする（NAT GWのポート枯渇対策）
net.ipv4.tcp_tw_reuse = 1
# TCP接続の維持時間を最適化し、NAT GWのコネクション追跡テーブルを解放しやすくする
net.ipv4.tcp_fin_timeout = 15
# 送受信のバッファサイズを大きくして、高レイテンシ環境でのスループットを維持
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216—
3. TLSハンドシェイクの最適化とパケット効率
NAT GWを経由する通信において、特にTLSハンドシェイクはコストを増幅させる。ハンドシェイクの往復回数（RTT）が増えれば増えるほど、AZ間通信量が増え、コストも積み上がる。
TLS 1.3への強制移行
TLS 1.2以前のハンドシェイクは2-RTTを要するが、TLS 1.3は1-RTTで済む。これを徹底するだけで、AZを跨ぐパケットの総量を劇的に削減できる。
さらに、HTTP/2 や gRPC の利用は必須だ。これらはコネクションを多重化し、ヘッダー圧縮（HPACK/QPACK）を行うため、NAT GWを通過するペイロードサイズを抑えつつ、通信効率を最大化する。
—
4. セキュリティとネットワーク設計の急所
NAT GWを跨ぐ通信において、重大な脆弱性の温床となるのが「パスMTU問題」だ。パケットサイズがMTUを超え、フラグメンテーションが発生すると、NAT GW側でパケットドロップが起きたり、再送処理が頻発してコストが跳ね上がる。
MSSクランプによる対策
iptablesを利用して、通過するパケットのMSS（Maximum Segment Size）を強制的に調整する手法がある。
# パケットのMSSを1460バイト以下に制限し、フラグメンテーションを防ぐ
# NAT GW前段のルーターやゲートウェイインスタンスでの適用例
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360※ 1360 という値は、オーバーヘッド（VXLANやGeneve等）を考慮した安全な値だ。
—
5. アーキテクトへの提言：コストと運用のバランス
結局のところ、NAT GWのコスト最適化は「ネットワークの局所性（Locality）」をいかに守るかに帰結する。
1. VPC Endpoints (PrivateLink) の徹底活用: S3やDynamoDBへの通信は、絶対にNAT GWを通すな。これだけでコストの3割は削減できる。
2. AZ間データ転送監視: CloudWatch Metricsで CrossAZTraffic を監視し、特定のAZに偏った通信がないか定期的にレビューせよ。
3. プロキシの検討: HTTP/HTTPS通信が主なら、NAT GWの代わりに Squid や Envoy を用いたプロキシ層を挟み、コネクションプーリングを行う手法も、高負荷環境では検討に値する。
ネットワークは「魔物」だ。しかし、パケットがどこへ向かい、どのデバイスで何をしているかを理解していれば、魔物は単なる「制御可能なリソース」へと変わる。今日紹介したチューニングは、教科書にはない、現場で何度もパケットキャプチャを回した末に得た知見だ。ぜひ、君のインフラで試してほしい。
技術の本質は、常に「見えない挙動」を「見える化」し、それを「制御」することにある。それができるSREこそが、次世代のインフラを創るのだ。
コメント