GCP Cloud NATの深淵：ポート枯渇と戦うアーキテクトのためのチューニング指針
クラウドインフラを設計していると、ある日突然「特定の通信先だけが断続的にタイムアウトする」という悪夢のような事象に遭遇することがあります。ログを漁り、パケットをキャプチャし、辿り着いた先は決まって Cloud NAT のポート枯渇問題です。
今日は、教科書的なドキュメントを飛び越え、TCPスタックの挙動とGCPのネットワークファブリックがどう交差しているのか、その「現場のリアル」を解説します。
—
1. ポート枯渇の正体：なぜ「Min ports per VM」が重要なのか
Cloud NAT は、外部IPを持たないVMがインターネットへ通信する際の「ゲートウェイ」です。VMから外部へのパケットが送信される際、NATは送信元IPを自身のIPに置換し、送信元ポートを自身の管理する範囲から割り当てます。
ここで重要なのが min_ports_per_vm です。デフォルトの64では、高負荷なマイクロサービスや、多くの外部APIを叩くバックエンドでは、あっという間にポートの「使い回し」が追いつかなくなります。
なぜ枯渇するのか？
TCP通信において、送信元IP・送信元ポート・送信先IP・送信先ポートの4つが同じ組み合わせ（タプル）である場合、それが「一意なセッション」として識別されます。NATゲートウェイが特定の宛先に大量の接続を生成すると、同一の送信元ポートを再利用しようとしても、TCPの TIME_WAIT 状態にあるソケットがそれを阻みます。
2. カーネルとNATの暗黙の契約：タイマーチューニングの極意
ポート枯渇を防ぐための定石は、単に「ポート数を増やす」ことだけではありません。いかにしてポートを「速やかに解放するか」が、真のアーキテクトの腕の見せ所です。
TCPタイムアウト設定の最適化
Linuxカーネルのデフォルト設定は、インターネットの黎明期からほとんど変わっていません。現代の高速なクラウドネットワークにおいて、以下のチューニングは必須といえます。
# TCPの再利用を許可（TIME_WAIT状態のソケットを新規接続に転用）
sysctl -w net.ipv4.tcp_tw_reuse=1
# TCP FINタイムアウトを短縮（デフォルトの60秒は長すぎるケースが多い）
# 接続切断時のパケットドロップを防ぐため、アプリの挙動を見ながら20-30秒程度へ
sysctl -w net.ipv4.tcp_fin_timeout=20※ 注意: tcp_tw_reuse を有効にする際は、タイムスタンプオプション (net.ipv4.tcp_timestamps) も有効である必要があります。これらはNAT配下でのパケットの順序制御に深く関わります。
3. アプリケーション層でのパケット削減戦略
インフラ層でのチューニングには限界があります。真のパフォーマンスを追求するなら、アプリケーション層での「コネクション管理」を最適化すべきです。
Keep-Aliveと接続プール
毎回のHTTPリクエストでハンドシェイク（SYN/SYN-ACK/ACK）を行うのは、レイテンシとポート消費の観点から最悪の選択です。Keep-Alive を活用し、TCPコネクションを可能な限り維持してください。
Python (Requests) での接続プール例:
import requests
from requests.adapters import HTTPAdapter
# セッションオブジェクトでコネクションを維持
session = requests.Session()
# 最大接続数とリトライ設定を明示的に定義
adapter = HTTPAdapter(pool_connections=100, pool_maxsize=100)
session.mount('https://', adapter)
# これにより、TCPハンドシェイクのオーバーヘッドを大幅に削減できる
response = session.get('https://api.example.com')TLSハンドシェイクの最適化
TLS 1.3への移行は、RTT（Round Trip Time）削減の特効薬です。TLS 1.3ではハンドシェイクが1ラウンドトリップで完了するため、NATを経由する際の影響を最小限に抑えられます。可能であれば、TLS False Start や OCSP Stapling を有効にし、ヘッダー圧縮（HPACK/QPACK）が効くHTTP/2以降のプロトコルを強制してください。
4. Cloud NATのデバッグ：パケットドロップを見逃さない
「ポートが足りているはずなのに繋がらない」。そんな時は、GCPの Cloud Logging で NAT のメトリクスを監視しましょう。
nat/allocated_ports_count: 現在のポート使用率nat/dropped_packets_count: NATによるドロップ数
特に dropped_packets_count が急上昇している場合は、min_ports_per_vm を増やすか、endpoint-independent-mapping の設定を検討してください。ただし、後者はセキュリティ要件と相談が必要です。
Terraformでの最適化構成例
resource "google_compute_router_nat" "nat" {
name = "my-nat"
router = google_compute_router.router.name
nat_ip_allocate_option = "AUTO_ONLY"
source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
# ポート枯渇を防ぐためのチューニング
min_ports_per_vm = 1024 # デフォルト64から大幅増強
# TCPセッションのタイマーを短縮し、ポートの回転率を上げる
tcp_established_idle_timeout_sec = 600
tcp_transitory_idle_timeout_sec = 30 # FIN/RST後の待機時間を短く設定
}最後に：ネットワークを「制御」するという意識
ネットワークはブラックボックスではありません。LinuxカーネルのTCPスタックから、GCPのSDN（Software Defined Network）の挙動、そしてアプリケーションの接続管理まで、すべては「パケットの旅」です。
ポート枯渇という事象は、単なる設定ミスではなく、あなたのシステムが「どれだけ効率的に外部と対話できているか」を測るバロメーターです。今回紹介したパラメータは、決して魔法の杖ではありません。皆さんのアーキテクチャに合わせて、常に tcpdump やメトリクスと対話し、最適なバランスを見つけ出してください。
次は、Cloud CDN を組み合わせたエッジでのTLSオフロードと、キャッシュヒット率向上のためのヘッダー戦略について深掘りしましょう。それでは、良きSREライフを。
コメント