Google Cloud 共有VPC：大規模組織におけるネットワーク・ガバナンスとパケットの「最短距離」
クラウドの設計において、ネットワークは単なる「土管」ではない。特にGoogle Cloudの共有VPC（Shared VPC）は、組織のスケールに伴う権限の分断と、パケットの遅延を最小化するアーキテクチャの要だ。
多くの技術者が「ただ繋がればいい」と考えがちだが、SREの視点から言えば、ホストプロジェクトとサービスプロジェクトの境界線は、単なる管理上の区分ではない。それはパケットのルーティング効率、TCPセッションの生存率、そしてセキュリティ境界そのものを規定する重要なレイヤーである。
1. 共有VPCの真価：ルーティングとセキュリティの分離
共有VPCの本質は、ネットワーク管理者（ホストプロジェクト）とアプリケーション開発者（サービスプロジェクト）の責務分離にある。しかし、技術的観点で最も重要なのは、「VPCネットワークがプロジェクトの壁を越えて透過的に機能する」という点だ。
サービスプロジェクト上のリソースは、ホストプロジェクトのサブネットに直接NICを接続する。これにより、オーバーレイネットワークや複雑なVPNトンネルを介することなく、Googleの広大なグローバルネットワークである Andromeda 上で、ネイティブなパケット転送が行われる。
アーキテクチャ設計の要諦
ホストプロジェクトでファイアウォールを一元管理することで、10.0.0.0/8 のような広大なアドレス空間の可視性を維持しつつ、サービスプロジェクト側の権限を compute.networkUser に限定できる。これにより、開発者が誤ってVPCのピアリング設定を書き換えたり、不要なルートを広報したりする「ネットワーク事故」を未然に防ぐことが可能だ。
2. パケットレベルの最適化とレイテンシの縮小
共有VPC環境下でも、パケットの挙動は通常のVPCと変わらない。しかし、レイテンシを極限まで削るためには、以下のチューニングが不可欠となる。
TCPバッファの動的チューニング
高トラフィックなマイクロサービス間通信では、デフォルトのTCPウィンドウサイズではスループットが頭打ちになる。Linuxカーネルパラメータを調整し、BDP（Bandwidth Delay Product）を最適化しよう。
# TCP受信バッファの最適化：共有VPC内のサービス間通信でスループットを向上させる
# 最大受信バッファを16MBに拡大
sysctl -w net.core.rmem_max=16777216
# TCP受信ウィンドウの自動チューニング範囲を設定
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"また、同一リージョン内のサービスプロジェクト間通信であれば、MTU を 1460 から 8896（Jumbo Frames）へ拡張することを検討すべきだ。ヘッダーのオーバーヘッドを削減し、CPUのパケット処理負荷を劇的に低減できる。
3. TLSハンドシェイクとヘッダー圧縮
共有VPC環境下で、サービスプロジェクトにまたがる通信を行う場合、サイドカープロキシ（Istio等）を介することが多い。ここで考慮すべきは、TLS 1.3 の 0-RTT 機能と HPACK によるヘッダー圧縮だ。
HTTP/2 の HPACK は、動的テーブルを用いてヘッダーを圧縮する。サービスプロジェクト間での通信頻度が高い場合、この圧縮効率を最大化するために、接続の「粘り気」を維持することが重要だ。
Istio側でのタイムアウトと接続設定例
# EnvoyFilterによるコネクションプールの最適化
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: tcp-keepalive-filter
spec:
configPatches:
- applyTo: CLUSTER
patch:
operation: MERGE
value:
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
# Keepalive設定でアイドル時のコネクション断を防止
tcp_keepalive:
keepalive_time: 30s
keepalive_probes: 3
keepalive_interval: 5s4. 重大な脆弱性の回避：境界を守る「零細管理」
共有VPCで最も恐ろしいのは、サービスプロジェクトからホストプロジェクトの特権的なサブネットへ、意図しないアクセスが許可されることだ。
対策：階層型ファイアウォールポリシーの活用
単一のVPCファイアウォールルールに頼らず、組織レベル（Organization Level）の階層型ファイアウォールポリシーを適用せよ。これにより、サービスプロジェクト側でどれだけファイアウォール設定をいじろうとも、「絶対に許可してはならない通信（例: 管理用SSHポートの開放）」を強制的にドロップできる。
# 組織レベルのファイアウォールポリシーを作成し、強制力を担保する
gcloud compute network-firewall-policies create "global-security-policy" \
--global \
--description="組織全体のインバウンド制限ポリシー"
# 優先度1000で、SSH(22)への全開放を防ぐ
gcloud compute network-firewall-policies rules create 1000 \
--action=deny \
--direction=ingress \
--firewall-policy="global-security-policy" \
--global \
--priority=1000 \
--layer4-configs=tcp:22 \
--src-ip-ranges=0.0.0.0/0結論：ネットワークを「コード」として捉えよ
共有VPCは、単なるネットワーク構成ではない。それは「組織の統治（Governance）」を技術的に実装するためのフレームワークだ。パケットの経路、カーネルのバッファ、そして階層化されたセキュリティポリシー。これらを一貫した哲学で設計した時、クラウドインフラは初めて「堅牢な城」へと進化する。
次に構築する環境では、ただサブネットを切るのではなく、パケットがホストとサービスの間を駆け抜けるその一瞬に、どれだけの最適化の余地があるかを想像してみてほしい。それが、SREとしての一歩先を行くアーキテクトの思考である。
コメント