GCPプライベートGoogleアクセス：パケットを「魔界」へ飛ばさないための深層アーキテクチャ
クラウドアーキテクトとして数多くの大規模システムを見てきましたが、いまだに現場で混乱を招くのが「パブリックなGoogle APIに、なぜプライベートIPで届くのか」という問いです。
「外部IPを持たないVMから、GCSバケットへセキュアにアクセスしたい」。この要求に対し、多くのエンジニアは安易にCloud NATを検討します。しかし、Google Cloudが用意した真の武器は、その手前にある「Private Google Access (PGA)」という仕組みです。今回は、この黒魔術のような通信経路の内部挙動を、パケットレベルの視点から解剖します。
—
1. パケットはどこを流れるのか？：ルートテーブルの深淵
PGAを有効にすると、VPCのルートテーブルには 199.36.153.8/30（restricted.googleapis.com）や 199.36.153.4/30（private.googleapis.com）へのネクストホップが default-internet-gateway として自動挿入されます。
ここで多くの人が勘違いするのは、「インターネットゲートウェイに行くなら外へ出るのではないか？」という点です。しかし、GCPの内部ネットワークにおいて、このパケットは物理的なインターネットには決して流出しません。
パケットがVMのNICを離れた瞬間、GCPのSoftware Defined Network (SDN) レイヤーである Andromeda が介入します。このパケットの宛先IPがGoogleの所有する特定のIP範囲であると認識された瞬間、ルーティングはGoogleのプライベートバックボーンへと強制的にスイッチングされるのです。つまり、パケットは最初から最後までGoogleの管理下にある光ファイバーのみを移動します。
—
2. DNS名前解決の「罠」を回避する
PGAを機能させるには、DNSの設定が全てです。VMから storage.googleapis.com を解決した際、パブリックIP（142.250.x.x など）が返ってきては意味がありません。
ここで Cloud DNS の DNS Private Zones を使い、CNAME レコードを駆使します。
# 解決フローの設計指針
# 1. ユーザーは storage.googleapis.com を引く
# 2. Cloud DNS は storage.googleapis.com -> storage.private.googleapis.com へ転送
# 3. 最終的に 199.36.153.4 (private.googleapis.com) が返されるように設定するこのとき、PTR レコードや A レコードのTTL設定を過度に大きくしすぎないことが、障害発生時の切り替え速度（フェイルオーバー）において重要です。
—
3. TLSハンドシェイクとRTTの最適化
PGA経由の通信は物理的な距離が短縮されますが、それでも「通信の往復」というコストは無視できません。特にTLS 1.3が主流の現在、ハンドシェイクのオーバーヘッドをどう削るかがパフォーマンスの分水嶺です。
TCPバッファチューニング
VMインスタンス側で以下のカーネルパラメータを調整することで、スループットのボトルネックを解消できます。特に広帯域なGCSへのアップロード/ダウンロード時には、初期ウィンドウサイズを大きくすることが鉄則です。
# /etc/sysctl.conf に追記し、高帯域通信に最適化する
# 初期輻輳ウィンドウサイズを 10 に設定 (RFC 6928)
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCPウィンドウのスケーリングを有効化
net.ipv4.tcp_window_scaling = 1—
4. セキュリティの要：VPC Service Controlsとの共鳴
PGAだけでは、「誰でもGoogle APIにアクセスできる」という状態になりかねません。ここで登場するのが VPC Service Controls (VPC-SC) です。
PGAが「経路」を定義するなら、VPC-SCは「境界」を定義します。パケットがGCSに到達した際、GCPのAPIゲートウェイは「このリクエストは許可されたVPCから来ているか？」をヘッダー情報ではなく、パケットのコンテキストから検証します。これにより、データ持ち出し（Exfiltration）の脅威を物理的にシャットアウトできるのです。
推奨される構成例
- PGA: バックボーンを通るための「チケット」。
- VPC-SC: サービス境界を作るための「検問所」。
これらを組み合わせることで、外部IPを持たない隔離されたVMであっても、GCS上の機密データに対して安全かつ高速にアクセスが可能になります。
—
5. 最後に：エンジニアが向き合うべきこと
PGAのトラブルシューティングにおいて最も重要なのは、traceroute や mtr を鵜呑みにしないことです。前述の通り、Andromeda がパケットを制御しているため、トレース結果は不正確になりがちです。
トラブル発生時は、必ず VPC Flow Logs を確認し、パケットが REJECT されているのか、あるいはそもそも宛先に到達できていないのかを、SDNレイヤーの視点で追跡してください。
ネットワークは魔法ではありません。すべてはパケットが移動する経路と、その宛先を決定するDNSの論理構造に集約されます。この深層を理解したとき、皆さんのインフラアーキテクチャはより堅牢で、かつエレガントなものへと進化するはずです。
次回の記事では、gRPC を用いたマイクロサービス間通信におけるPGAの最適化について深く掘り下げてみたいと思います。では、現場のエンジニア諸氏、健闘を祈ります。
コメント