「VPCピアリングはもう古い？」GCP Private Service Connect (PSC) で実現する、境界を越えたプライベート接続の真髄
インフラエンジニアの皆さん、VPCピアリングの管理で頭を悩ませた経験はありますか？
「AプロジェクトとBプロジェクトを繋ぎたいだけなのに、IPアドレスの重複に怯え、ルーティングテーブルのメンテナンスに追われ、ファイアウォールの穴開けでセキュリティ監査に冷や汗をかく……」。かつて、クラウド間のネットワーク構築は、こうした「泥臭い調整」の連続でした。
しかし、Google Cloudの Private Service Connect (PSC) が登場して以来、世界は変わりました。今回は、NATもピアリングも不要で、極めてセキュアかつスケーラブルにサービスを公開・利用できるPSCの「中身」を、現場目線で深掘りしていきます。
—
1. PSCの正体：なぜ「IPの重複」を恐れなくていいのか？
PSCの核心は、「サービス提供側のVPCと、利用者側のVPCが直接繋がっていない」という点にあります。
従来のVPCピアリングは、ネットワークの境界そのものを拡張する手法でした。これに対し、PSCは「サービスへの入り口（エンドポイント）」を、利用者側のVPC内に「仮想的なインターフェース」として投影します。
- 利用者側: 自分のVPC内にある特定のプライベートIP（エンドポイント）に対してリクエストを投げる。
- Googleのバックボーン: そのIPへの通信を、裏側で魔法のようにサービス提供側のエンドポイントへ転送する。
この仕組みにより、提供側と利用側でIPアドレス体系が重複していても、全く問題なく通信が成立します。ルーティングの競合を考慮してIP設計を練り直す……なんていう、あの悪夢から解放されるわけです。
—
2. 通信フロー：パケットはどこを走るのか？
PSCの通信シーケンスを整理すると、意外なほどシンプルです。
1. 名前解決: アプリケーションはエンドポイントのIPを叩きます。DNS（Cloud DNS）を使って、特定のドメインをこのエンドポイントIPに解決するように設定するのが定石です。
2. 転送ルール (Forwarding Rule): 利用者側のVPCに作成された転送ルールが、通信をキャッチします。これが「PSCエンドポイント」の正体です。
3. Googleの魔法: 送信元IPはNAT変換されることなく、Googleのプライベートバックボーンを経由し、サービス提供側の「サービス添付（Service Attachment）」へと運ばれます。
4. サービス着信: 提供側のロードバランサーが通信を受け取り、バックエンドへ配送します。
ここで重要なのは、「サービス提供側からは、利用側のプライベートIPがそのまま見える」ということです。これにより、提供側は利用者のIPに基づいたアクセス制御が可能になります。
—
3. 実践：PSCエンドポイントを構築する
実際に gcloud コマンドでエンドポイントを構成する手順を見てみましょう。ここでは、他プロジェクトで公開されているサービスを利用する想定です。
ステップ1：エンドポイントの作成
# 利用者側のVPC内に、PSCエンドポイント用のIPアドレスを確保
gcloud compute addresses create psc-endpoint-ip \
--global \
--purpose=PRIVATE_SERVICE_CONNECT \
--subnet=my-subnet \
--addresses=10.0.0.5 # エンドポイントとして割り当てるIP
# 転送ルールの作成（これが通信の入り口）
gcloud compute forwarding-rules create my-psc-endpoint \
--address=psc-endpoint-ip \
--network=my-vpc \
--target-service-attachment=projects/producer-project/regions/asia-northeast1/serviceAttachments/my-service-attachment \
--globalステップ2：アプリケーションから呼び出す（Python例）
アプリケーション側は、まるでローカルにあるサーバーを叩くかのように、この 10.0.0.5 を参照します。
import requests
# 実際のエンドポイントIPに向けたリクエスト
# DNS設定を済ませていれば、ドメイン名で指定するのがベスト
url = "http://10.0.0.5/api/v1/resource"
try:
# タイムアウト設定は必須。ネットワーク障害時にもアプリを道連れにしないために
response = requests.get(url, timeout=5)
response.raise_for_status()
print(response.json())
except requests.exceptions.RequestException as e:
# 繋がらない時は、まず forwarding-rule の状態を gcloud で確認すること
print(f"PSC経由の通信エラー: {e}")—
4. 現場のトラブルシューティングTips
PSCを運用していると、「なぜか繋がらない」という状況に直面することがあります。その際、シニアエンジニアが最初に確認するのは以下の3点です。
- サービス添付（Service Attachment）の承認状態: 提供側で「自動承認」になっていない場合、利用者側からの接続リクエストが「保留中」になっていることがあります。
gcloud compute service-attachments describeで状態を確認してください。 - ファイアウォールルール: PSCエンドポイントそのものにファイアウォールを設定する必要はありませんが、サービス提供側のバックエンド（ロードバランサー）が、PSC経由のトラフィックを許可しているかを確認してください。
- DNSの解決先:
digやnslookupで、意図したエンドポイントIPが返ってきているかを必ず確認します。特にハイブリッド環境（オンプレミスからの接続）では、Cloud DNSのフォワーディング設定が漏れがちです。
—
最後に：ネットワークを「意識しない」アーキテクチャへ
PSCの真の価値は、ネットワークの複雑さを「エンドポイント」という単一のオブジェクトに封じ込めたことにあります。
開発者はインフラのトポロジーを気にせず、提供されたエンドポイントURLを config に書くだけでサービスを利用できる。インフラ担当者は、ピアリングのルート管理から解放され、よりセキュアな設計に集中できる。
これこそが、モダンなクラウドインフラの理想形ではないでしょうか。ぜひ皆さんのプロダクション環境でも、PSCを活用して「ネットワークのしがらみ」から自由になってください。
それでは、また次回の記事でお会いしましょう！
コメント