GCP VPCピアリングの「不都合な真実」と、推移的ルーティングの壁を乗り越える戦略
現場のSREとして、これまで数多のマルチリージョン構成やマイクロサービス群のネットワーク設計を見てきましたが、GCPの「VPC Network Peering」ほど、その利便性と制約のバランスでエンジニアを悩ませる機能も珍しいと感じています。
「とりあえずVPCを繋げば通信できる」――そう考えて設計した若手エンジニアが、プロダクトリリース直前に「あれ、繋がらない拠点があるぞ？」と青ざめる姿を、私は何度見てきたことでしょう。今日は、VPCピアリングという「魔法」の裏側にある物理的な限界と、それをどうハックしてビジネスを止めないインフラに仕立てるか、現場の知見を共有します。
—
VPCピアリング：高速道路の開通、ただし「寄り道は禁止」
GCPのVPCピアリングは、異なるVPC間でプライベートIPを用いた低遅延かつ高スループットな通信を可能にします。ここで重要なのは、これが単なるトンネルではなく、「データプレーンレベルで直接接続される」という点です。パケットは一度も外のインターネットに出ることなく、Googleの広大なバックボーンを高速で駆け巡ります。
しかし、ここで多くの人が躓くのが「推移的ルーティング（Transitive Routing）の非サポート」という壁です。
なぜ「推移的」がダメなのか
ネットワークの図を書いてみてください。VPC AとVPC Bがピアリングし、VPC BとVPC Cがピアリングしているとします。このとき、VPC AからVPC Cへパケットを送ろうとしても、GCPはこれを「ルーティング不可」として弾きます。
これは仕様です。BをハブにしてAとCを繋ぐような「中継」は、VPCピアリングの設計思想には存在しません。もしこれを無視して設計を進めると、可用性を考慮して増やしたはずのVPCが、逆にネットワークの断絶を招く「孤島」を大量生産することになります。
—
実践：ルーティングの正解とデバッグの手順
ピアリング設定が正しく行われているか確認する際、まずはgcloudコマンドでルートの伝搬状況をチェックするのが定石です。
# VPCピアリングのルートを詳細確認
# peering-name はピアリング設定名、vpc-name は対象のVPC名
gcloud compute networks peerings list-routes <peering-name> \
--network=<vpc-name> \
--direction=INCOMINGもし通信が通らない場合、真っ先に疑うべきは「IPアドレスの重複」です。VPCピアリングでは、接続するVPC間でIPセグメントが被っていると、ルートが生成されません。特にTerraformで環境をIaC化している場合、CIDR設計の重複は致命的なデプロイエラーを招きます。
疎通確認のセオリー：curlでのテスト
アプリケーション層のエンジニアであれば、まずは以下のようなシェルスクリプトをサイドカーやデバッグ用Podで回して、疎通を検証しましょう。
#!/bin/bash
# 接続先のプライベートIPとポートを定義
TARGET_IP="10.128.0.5"
TARGET_PORT="8080"
# タイムアウト付きで疎通確認
# -v: 詳細表示, -m: 最大接続時間(秒)
curl -v -m 5 http://${TARGET_IP}:${TARGET_PORT}/healthz—
限界を突破する：Hub-and-Spokeの現実解
では、推移的ルーティングができない環境で、複数のVPCを中央集権的に管理するにはどうすべきか？
現場で最も推奨されるのは「Network Connectivity Center (NCC)」を活用したハブ＆スポーク構成です。あるいは、よりシンプルに「Cloud VPN」や「Cloud Interconnect」を介在させることで、推移的ルーティングを無理やり実現させる手法もありますが、管理コストとレイテンシを天秤にかける必要があります。
設計上のTips：Route Advertiserの活用
どうしても動的にルートを広報したい場合は、Cloud Routerを介したBGPセッションを検討してください。静的なピアリング設定に固執するのではなく、BGPのAD（アドバタイズ）機能を使うことで、どのルートをどのVPCに流すかを動的に制御できます。
# PythonでCloud Routerのルート設定を動的に生成するイメージ
# 実際には Google Cloud Client Library を使用します
from google.cloud import compute_v1
def update_router_route(project_id, region, router_name):
# 既存のルーター設定にカスタムルートを追加する処理
# 注意: ここでの変更は全接続先に影響するため、DR環境等で検証必須
print(f"Updating {router_name} in {region} for dynamic routing...")—
SREからの最後のアドバイス：構成を複雑にしない勇気
「とりあえずピアリングで繋げばいいや」という場当たり的な設計は、後々、ネットワークトラブルシューティングという名の地獄を招きます。
1. CIDR設計は神聖な儀式と思え: 最初にVPCのIP設計をケチると、将来の拡張で必ず泣きを見ます。VPCピアリングを前提とするなら、全VPCでCIDRが重複しないよう、最初から大きめのIPアドレス空間を確保してください。
2. 可視化を怠るな: VPC Flow Logsを有効にし、BigQueryで分析できる状態にしておきましょう。「パケットがどこで捨てられたか」を即座に特定できる環境こそが、真のSREの武器です。
3. 推移的ルーティングの回避: 可能であればVPCを統合する。どうしても分けるなら、それらを繋ぐための専用の「Transit VPC」を設計し、そこで透過的なルーティング制御を行うのが、最も枯れた（安定した）アーキテクチャです。
クラウドネットワークは生き物です。公式ドキュメントを読み込むのはスタートラインに過ぎません。実際にパケットを飛ばし、トラフィックの変動をログで追い、泥臭い検証を積み重ねた先にある「安定した接続」こそが、我々エンジニアの誇りです。
さあ、あなたの環境のルートテーブルを、もう一度見直してみませんか？
コメント