GCP VPCピアリングの深淵：パケットが語る「推移的ルーティング」の限界と最適化の哲学
クラウドインフラを設計する際、VPCネットワークピアリング（VPC Network Peering）は最もエレガントかつ、同時に最も罠にはまりやすい機能の一つだ。ネットワークエンジニアにとって、この機能は単なる「プライベート接続」の手段ではない。それは、Googleの巨大なSDN（Software Defined Network）であるAndromedaの内部でパケットがどのようにルーティングされ、いかにして物理的境界を超えていくかを理解する試金石である。
今回は、単なる公式ドキュメントの焼き直しではなく、我々SREが現場で直面する「なぜ通信できないのか」という問いに対し、パケットの挙動とアーキテクチャの制約から深掘りしていこう。
1. VPCピアリングの核心：ルーティングは「双方向」の合意である
VPCピアリングを構成する際、多くのエンジニアが躓くのが「接続の非対称性」だ。ピアリングは、単に片側で設定を投入すれば繋がるような甘いものではない。
GoogleのVPCピアリングは、コントロールプレーンにおいて「サブネット範囲の交換」を行う。具体的には、ピアリングが確立された瞬間、お互いのVPCが持つIP CIDRブロックのルート情報が、相手方のGCP VPC Routing Tableへと自動的に注入される。
ここで重要なのは、「推移的ルーティング（Transitive Routing）はサポートされていない」という鉄の掟だ。
例えば、VPC AがVPC Bとピアリングし、VPC BがVPC Cとピアリングしているとする。このとき、VPC AからVPC Cへの直接通信はルーティングされない。パケットはBまで到達し、そこで「Cへのルートがネクストホップとして存在しない（あるいはBを通過するパケットとして転送されない）」ため、黙って破棄される。
なぜ推移的ルーティングは禁止なのか？
これは単なる仕様ではなく、ネットワークの安定性とパフォーマンスを維持するための防波堤だ。推移的ルーティングを許可すると、ルーティングループの検知が指数関数的に困難になり、経路制御プロトコル（BGP的な挙動）が収束しなくなるリスクがある。GCPのアーキテクチャは、各ノードでの決定論的なルーティングを担保することで、マイクロ秒単位の低遅延を実現しているのだ。
2. IP重複と衝突：現場で遭遇する「悪夢」の回避策
複数のVPCを運用していると、避けられないのがIP CIDRの重複だ。ピアリングが確立されると、重複するサブネットに対するルートが両方のVPCに存在することになる。
GCPの挙動としては、より具体的なプレフィックス（最長一致ルーティング）が優先されるが、完全に範囲が重複している場合、トラフィックのルーティングは極めて不安定になる。これを防ぐには、ネットワーク設計の段階でIPAM（IP Address Management）を厳格に運用し、ピアリングする可能性のある全VPCでCIDRをユニークにするのが鉄則だ。
どうしても衝突を避けられない場合は、Private Service Connect（PSC）の利用を検討すべきだ。PSCは、ピアリングとは異なり、エンドポイントベースでサービスを公開するため、ネットワーク全体を繋ぎ合わせることなく、特定のサービスのみを、重複を気にせず公開できる。
3. パフォーマンスの深淵：TCPバッファとTLSの最適化
ピアリングを経由した通信において、RTT（Round Trip Time）が物理的な距離以上に増大するように感じられる場合、それはネットワークの遅延ではなく、TCPの輻輳制御やバッファ設定に問題があることが多い。
特に、広帯域かつ高遅延な経路をまたぐ場合、LinuxカーネルのデフォルトのTCPバッファサイズでは帯域を使い切れない。以下のsysctl設定で、ウィンドウサイズを最適化し、スループットを向上させるのが定石だ。
# 送受信バッファの最小値、デフォルト値、最大値を調整する
# 16MB程度まで広げることで、帯域幅遅延積(BDP)をカバーする
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"また、TLSハンドシェイクのオーバーヘッドを削減するために、TLS 1.3の採用は必須だ。TLS 1.3ではハンドシェイクが1往復（0-RTTモードなら0往復）で完了するため、リージョンをまたぐようなピアリング環境下では、レイテンシ削減に劇的な効果を発揮する。
4. トラブルシューティングの極意：パケットは嘘をつかない
VPCピアリングの疎通確認には、gcloudコマンドだけでなく、Packet Mirroringを活用することを強く推奨する。
# 特定のVPC内のパケットをミラーリングし、解析基盤に流す設定例
gcloud compute packet-mirrorings create my-mirroring \
--region=asia-northeast1 \
--collector-ilb=my-collector-ilb \
--network=my-vpc \
--filter-cidr-ranges=10.0.0.0/16 # ピアリング先の範囲を特定通信がうまくいかない場合、以下の順序でスタックを調査せよ。
1. ファイアウォールルール: ingress/egressでピアリング先のCIDRが許可されているか？
2. ルートの伝播: gcloud compute networks peerings listでステータスがACTIVEになっているか？
3. OSレベルのルーティング: インスタンス内のip routeコマンドで、意図したインターフェースへパケットが送出されているか？
結び：アーキテクトとしての矜持
VPCピアリングは便利だが、魔法ではない。GCPのネットワーク境界をまたぐ通信は、常に「信頼の境界」を意識する必要がある。
推移的ルーティングを回避し、IP設計をクリーンに保ち、カーネルレベルでTCPをチューニングする。これら一見地味な積み重ねこそが、数百万リクエストを捌く堅牢なシステムを作る。ネットワークは、パケットが通過するただの通り道ではない。そこに流れるデータの意図を汲み取り、最適化する場所なのだ。
次回の記事では、このピアリング環境下でのCloud Load Balancingの挙動と、Global VPCにおけるトラフィック最適化について深掘りしていこう。エンジニアの諸君、引き続き泥臭く、しかし知的にクラウドと向き合おうではないか。
コメント