ハイブリッドクラウドの深淵：GCP InterconnectとCloud NATが織りなすパケットの旅路
オンプレミスとGCPを Dedicated Interconnect で接続した瞬間、多くのエンジニアは「これでプライベートな閉域網が手に入った」と安堵する。だが、現実はそれほど単純ではない。レガシーなオンプレ環境からクラウド上の外部SaaS APIを叩く際、あるいは出口戦略を設計する際、Cloud NAT の存在をどう扱うかで、そのアーキテクチャの生死が決まる。
本稿では、Interconnectを経由してやってきたパケットが、GCPの Cloud NAT を通り抜け、パブリックなインターネットへと解き放たれるまでの「変換の儀式」を、パケットレベルの解像度で紐解いていく。
—
1. パケットの行方：Cloud NATが引き起こす「魔法」の正体
通常、オンプレミスから Cloud NAT を利用してインターネットへ出る構成は、Cloud Router が Interconnect 越しに通知する「デフォルトルート」をどう制御するかに集約される。
パケット転送のメカニズム
オンプレから送信されたパケットは、Interconnect を経由してGCPの VPC に到達する。ここで重要なのは、Cloud NAT は「特定のサブネット」に紐付くのではなく、「Cloud Router が管理するルーティングテーブル」によって制御されるという点だ。
1. Ingress: オンプレからのパケットが VPC に到達。
2. Routing: Cloud Router がパケットを Cloud NAT ゲートウェイへ誘導。
3. SNAT (Source NAT): ここでパケットの送信元IP（オンプレのプライベートIP）が、Cloud NAT に割り当てられた「外部IPアドレス」に書き換えられる。
4. Egress: パケットは Cloud NAT の外部IPをソースとしてインターネットへ送出される。
この際、Cloud NAT は「送信元IP」だけでなく、「送信元ポート（Source Port）」も同時に変換（PAT: Port Address Translation）する。このポートの枯渇こそが、大規模ハイブリッド環境で遭遇する最大の敵である。
—
2. パフォーマンスの極致：TCPバッファとRTTの最適化
ハイブリッドクラウドでは、物理的な距離による物理レイテンシ（RTT）が避けられない。この環境で外部APIとのセッションを維持する場合、TCPの初期挙動がボトルネックになる。
TCPバッファチューニングの重要性
デフォルトのLinuxカーネルパラメータでは、高帯域・高遅延な Interconnect 回線を活かしきれないことが多い。sysctl で以下の値を調整し、BDP（Bandwidth Delay Product）を考慮したバッファサイズを確保すべきだ。
# TCP送受信バッファの最小・デフォルト・最大値を拡大
# 高速なInterconnect環境では、パイプライン化されたパケットを滞留させないことが重要
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 輻輳制御アルゴリズムをBBRに変更（パケットロスに強く、スループットが劇的に向上する）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrTLSハンドシェイクのオーバーヘッド
オンプレから Cloud NAT を経由して外部APIを叩く際、TLSハンドシェイクがRTTを倍加させる。これを軽減するには TCP Fast Open や、コネクションプーリングを前提とした HTTP/2 または HTTP/3 の採用が必須だ。特に HTTP/3 (QUIC) はUDPベースであり、Cloud NAT のタイムアウト挙動（特にUDPエントリの保持期間）には注意を払う必要がある。
—
3. セキュリティとネットワークの脆弱性回避
Cloud NAT を利用する際、しばしば見落とされるのが「ポートの予測可能性」と「接続追跡（Conntrack）の枯渇」だ。
脆弱性の回避：NATポートのランダム化
デフォルトでは Cloud NAT はポートを動的に割り当てるが、高負荷時にはポートの衝突や予測がセキュリティリスクとなる。min_ports_per_vm を適切に設定し、かつ enable_endpoint_independent_mapping を検討することで、特定の宛先への接続安定性を向上させつつ、セキュリティポリシーを厳格化できる。
# gcloudコマンドによるNAT設定の最適化
gcloud compute routers nats update [NAT_NAME] \
--router=[ROUTER_NAME] \
--region=[REGION] \
--min-ports-per-vm=2048 \
--enable-endpoint-independent-mapping # 特定の宛先への接続でIP/ポートの一貫性を保持ネットワークの「死角」を可視化する
Cloud NAT が適切に機能しているか、またはポートが枯渇していないかを監視するには、Cloud Loggingの NATログ を必ず有効にする必要がある。
- NAT ログの収集項目:
connection_drop: セッションの強制終了。多くの場合、ポート枯渇を示唆。tcp_reset: 通信相手または途中のファイアウォールによるリセット。
—
4. 最後に：インフラアーキテクトが持つべき視点
クラウドのネットワークを単なる「配線」と見なしてはならない。Interconnect という物理的な道と、Cloud NAT という論理的なゲートウェイが交差する地点には、パケットが書き換えられ、ルーティングされ、時に破棄されるドラマがある。
極限のパフォーマンスを求めるなら、Cloud NAT のスループット制限だけでなく、パケットが通過する VPC のスループット制限（インスタンスあたりの帯域制限）や、物理的な Interconnect の物理ポートの輻輳も視野に入れるべきだ。
ネットワークは生き物だ。メトリクスを眺めるだけでなく、tcpdump を用いて、Interconnect の境界と Cloud NAT の出口で何が起きているのか、その「パケットの変容」を肌感覚で理解したとき、初めて真のハイブリッドクラウドアーキテクトと呼べるだろう。
次回の更新では、このネットワーク構成における Service Mesh (Istio) のオーバーヘッドと、その最適化手法について踏み込んでいく。
コメント