共有VPCの真髄：クラウドネイティブなネットワーク分離と最適化の深淵
クラウドアーキテクトとして数多くの大規模インフラを設計してきましたが、「ネットワークをどこで分けるべきか」という問いに対する最適解は、常に「Shared VPC（共有VPC）」という答えに帰結します。
単にプロジェクトを論理的に分割するだけなら簡単です。しかし、組織が成長し、GKEクラスタやCloud Runが乱立する中で、一貫したセキュリティポリシーとトラフィック制御を維持するのは至難の業です。本稿では、Shared VPCのアーキテクチャを単なる「共有機能」としてではなく、パケットレベルの効率化とセキュリティの観点から掘り下げます。
—
1. 共有VPCのアーキテクチャと「暗黙の」信頼境界
Shared VPCの本質は、ホストプロジェクト（Host Project）がネットワークの「特権」を保持し、サービスプロジェクト（Service Project）がその「恩恵」を借りるという、明確な権限分離にあります。
ここで重要なのは、サービスプロジェクト上のリソースがホストプロジェクトのサブネットを参照する際、IAMの境界が物理的なルーティングテーブルを分離するのではなく、管理権限のみを分離しているという点です。パケットは単一のVPC内で転送されるため、レイヤー3のルーティングにおいてオーバーヘッドは発生しません。
IAM権限モデルの勘所
実務で最もハマりやすいのが compute.networkUser ロールの付与範囲です。広範囲に付与しすぎると、サービスプロジェクト間での意図しないサブネット利用が発生します。
# 特定のサービスプロジェクトに対して、特定のサブネットのみを利用可能にする最小権限設定
gcloud compute networks subnets add-iam-policy-binding [サブネット名] \
--region=[リージョン] \
--project=[ホストプロジェクトID] \
--role="roles/compute.networkUser" \
--member="serviceAccount:[サービスプロジェクトのSA]"—
2. パケットレベルのパフォーマンス最適化：RTTとバッファのチューニング
Shared VPC環境下では、プロジェクトを跨ぐ通信が発生しないため、レイテンシは物理的なGCPのバックボーンに完全に依存します。しかし、高負荷なマイクロサービス通信では、LinuxカーネルのTCPスタックがボトルネックになることが少なくありません。
特に、Keep-Alive を多用するHTTP/2環境では、tcp_rmem および tcp_wmem の設定がスループットを左右します。
TCPバッファの最適化（sysctl設定例）
以下の設定は、広帯域・低遅延なGCPネットワークにおいて、輻輳制御を維持しつつスループットを最大化するための推奨値です。
# /etc/sysctl.conf への追記例
# TCP受信バッファの最大値を最適化（高帯域通信用）
net.ipv4.tcp_rmem = 4096 87380 16777216
# TCP送信バッファの最大値を最適化
net.ipv4.tcp_wmem = 4096 65536 16777216
# タイムスタンプを有効にし、RTT測定の精度を上げる
net.ipv4.tcp_timestamps = 1—
3. TLSハンドシェイクの「極限」削減
Shared VPCを利用する際、Cloud CDNや外部ロードバランサを介した通信において、TLSハンドシェイクのオーバーヘッドは看過できません。ここで鍵となるのが TLS 1.3 への強制移行と、0-RTT（Zero Round Trip Time）の活用です。
セキュリティとパフォーマンスの両立
TLS 1.3では、ハンドシェイクが1往復（1-RTT）に短縮されています。さらに、再接続時には 0-RTT により、クライアントが暗号化されたデータを初回のHelloパケットで送出可能です。
設計上の脆弱性回避策:
0-RTT はリプレイ攻撃に対して脆弱です。これを回避するためには、サーバー側で Replay Protection を実装するか、冪等性のないリクエスト（POST/PUT）には 0-RTT を許可しないようアプリケーションレイヤーで制御する必要があります。
—
4. ヘッダー圧縮とパケットの効率化
gRPCやHTTP/2を採用している場合、HPACK によるヘッダー圧縮は非常に強力です。しかし、Shared VPCを流れるトラフィックにおいて、コンテキストの共有が不完全だと圧縮効率は低下します。
特に、Internal HTTP(S) Load Balancer を経由する際、X-Forwarded-For などのヘッダーが長大になりがちです。これらはパケットサイズを増大させ、MTUの制限（GCPではデフォルト 1460 バイト）に抵触すると、パケットフラグメンテーションが発生し、劇的なパフォーマンス低下を招きます。
現場の知見：
MTUの限界ギリギリを攻めるのではなく、アプリケーション側で可能な限り不要なカスタムヘッダーを削ぎ落とし、gRPC のメタデータ管理を最適化することが、ネットワークレイヤーの複雑さを回避する最も泥臭く、かつ最も効果的な手法です。
—
結びに：ネットワークは「生き物」である
Shared VPCは、単なるネットワークの共有基盤ではありません。それは、巨大な組織のセキュリティ境界を定義し、パケットが効率よく、かつ安全に目的のマイクロサービスへ到達するための「動脈」です。
技術的な仕様書を読み込むことは重要ですが、実際にパケットがどのルートを通り、どのTCPバッファで待機し、どのTLSセッションで暗号化されるのかを想像できるようになると、トラブルシューティングの景色は一変します。
次回の構築時には、ぜひ tcpdump を片手に、VPC内部のパケットがどう振る舞っているのかを観測してみてください。そのとき、初めて「クラウドネットワークの真の姿」が見えてくるはずです。
コメント