雲の上でパケットが迷わないために：GCP VPCピアリングの深淵とルーティングの「不都合な真実」
クラウドアーキテクトの視点から見ると、VPC Network Peeringは一見すると魔法のようにシンプルだ。しかし、この「魔法」の裏側には、Googleの巨大なSDN（Software Defined Network）である Andromeda が支配する、極めて厳格かつ洗練されたルールが存在する。
今回は、単なる設定手順の解説ではなく、パケットがVPCの境界を越える瞬間に何が起きているのか、そしてなぜ「推移的ルーティング」という壁に多くのエンジニアが頭を抱えるのか、その核心に迫っていこう。
—
VPCピアリング：Andromedaが描く「論理的直結」の正体
VPCピアリングは、異なるVPC間でプライベートIPアドレスを介した通信を可能にする。ここで重要なのは、これがVPNやルーターを介した「カプセル化」ではないという点だ。
Googleのインフラにおいて、パケットはピアリングされたVPC間を、あたかも同一のサブネット内に存在するかのように、直接的なルーティングテーブルのルックアップによって転送される。これにより、オーバーヘッドは最小限に抑えられ、レイテンシは物理的な近接性を最大限に活かしたレベルまで削ぎ落とされる。
推移的ルーティング（Transitive Routing）の壁
現場で最も議論を呼ぶのが「推移的ルーティングの非サポート」だ。
VPC A と VPC B がピアリングされ、VPC B と VPC C がピアリングされていても、VPC A から VPC C にはパケットは届かない。これはGoogleの設計思想であり、ネットワークのループや意図しないトラフィックの流出を防ぐための「意図的な制約」である。
もしあなたが「VPC A → VPC B（中継）→ VPC C」という構成を組もうとしているなら、それはアーキテクチャの再考を促す警告だ。
対抗策：ネットワークのハブ＆スポーク化
この制約を回避するための現場の定石は、Cloud VPN または Cloud Interconnect を用いたハブ＆スポーク型の構成、あるいは Network Connectivity Center (NCC) を活用することだ。これにより、単なるピアリングの限界を超えたルーティング制御が可能になる。
—
パフォーマンスの極致：TCPスタックとRTTの最適化
VPC間の通信において、パケットロスを最小化し、スループットを最大化するためのチューニングはSREの腕の見せ所だ。特に、リージョンを跨ぐピアリングや、高トラフィックなマイクロサービス間通信では、カーネルレベルのチューニングが必須となる。
TCPバッファの動的調整
デフォルトのカーネル設定では、広帯域・高RTT（Round Trip Time）な環境下でウィンドウサイズがボトルネックとなり、帯域を使い切れないことが往々にしてある。以下のような sysctl 設定を適用し、輻輳制御アルゴリズムを bbr に変更することを推奨する。
# TCPウィンドウサイズの最大値を拡大（メモリ許容範囲で）
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# 輻輳制御アルゴリズムをBBRに変更（Googleの知見の結晶）
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbrBBR (Bottleneck Bandwidth and RTT) は、パケットロスを輻輳のシグナルとする従来型（Cubic等）と異なり、実際の帯域幅とRTTを推定して送出レートを制御する。GCPの広大なネットワークインフラ上でその真価を遺憾なく発揮するはずだ。
—
セキュリティ：TLSハンドシェイクの最適化と脆弱性回避
プライベートネットワーク内であっても、零トラストの観点からは TLS による暗号化を省略する理由は存在しない。しかし、内部通信における過度なハンドシェイクはレイテンシを増大させる。
TLS 1.3 と 0-RTT の活用
内部サービス間では TLS 1.3 を強制し、再接続時の 0-RTT (Early Data) を活用することで、ハンドシェイクの往復回数を削減できる。
また、ヘッダー圧縮については、gRPC を採用しているならば HTTP/2 の HPACK アルゴリズムが自動的にヘッダーを圧縮してくれる。インフラレベルで Cloud CDN や Load Balancer を利用する場合も、QUIC (HTTP/3) への移行を検討してほしい。
ネットワーク脆弱性の回避策
VPCピアリングにおいて最も危険なのは、「接続したネットワークのセキュリティ意識が自社よりも低い」という状況だ。これを防ぐため、以下の防御を徹底すること。
1. ファイアウォールルールの最小権限化: gcloud compute firewall-rules を使用し、送信元・宛先・ポートを極限まで絞り込む。
2. VPC Service Controls の適用: ピアリング先からの意図しないAPIコールを遮断するため、サービス境界を定義する。
# 特定のサービスアカウント間のみ、かつ特定のポートのみ許可する例
gcloud compute firewall-rules create allow-internal-service \
--network=my-vpc \
--action=ALLOW \
--direction=INGRESS \
--source-ranges=10.128.0.0/20 \
--rules=tcp:8080 \
--description="ピアリング先からのgRPCトラフィックのみを許可"—
結びに代えて：パケットの行く末を見守るということ
VPCピアリングは、単純な接続機能ではない。それは、複雑に絡み合うマイクロサービス群の「神経系」を構築する行為だ。
我々エンジニアが意識すべきは、コマンド一つで疎通させることではなく、その先のパケットがどのような経路で、どのようなバッファの状態を経て、最終的にアプリケーションに到達するのかを想像し続けることにある。
ネットワークは生き物だ。そして、Google Cloud という巨大な生命体の上で動く我々のインフラは、常に最適化の余地を求めている。この深い森のようなネットワークの世界を、これからも深く掘り下げていこう。
コメント