株式会社ブレインパッド プロダクトユニットの岡です。
本記事は、【Google Cloud 】Cloud Runサービス間の通信をプライベートネットワークで実現するの関連記事です。前回は同一VPC内でのCloud Run間通信を内部ロードバランサで実現しました。今回は、異なるVPC間での内部通信をPrivate Service Connect（PSC）で実現する方法について解説します。
はじめに
前回の記事では、同一VPC内のCloud Run間通信を内部ロードバランサで実現しました。しかし、実際のシステムでは以下のようなケースがあります。
- マルチテナント環境で、テナントごとにVPCを分離したい
- 他チームが管理するVPCのサービスを利用したい
このようなVPCをまたいだ内部通信を実現するのがPrivate Service Connect（PSC）です。
対象読者
- 異なるVPC間で内部通信を実現したい
- Private Service Connectの使い方を知りたい
- VPCピアリング以外の選択肢を探している
Private Service Connectとは
Private Service Connect（PSC）は、異なるVPC間でプライベート接続を確立するためのサービスです。VPCピアリングと異なり、以下の特徴があります。
| 項目 | VPCピアリング | Private Service Connect |
|---|---|---|
| IPアドレス範囲 | 重複不可 | 重複可能 |
| 接続の方向 | 双方向 | 一方向（コンシューマー→プロデューサー） |
| 公開範囲 | VPC全体 | 特定のサービスのみ |
| 管理 | 両VPCの管理者が必要 | プロデューサー側で制御可能 |
アーキテクチャ
今回構築するアーキテクチャのイメージは以下の通りです。前回と異なり、client-service と server-service は別のVPCに配置されてます。client-service から server-serviceへのアクセスはPSCを経由して行われます。
必要なリソース
PSCを構成するには、以下のリソースが必要です。
プロデューサー側（サービス提供側）
- 内部ロードバランサ（前回の記事で作成済み）
- PSC用NATサブネット（
purpose = "PRIVATE_SERVICE_CONNECT"） - Service Attachment
コンシューマー側（サービス利用側）
- VPCとサブネット
- PSCエンドポイント用の内部IPアドレス
- PSCエンドポイント（Forwarding Rule）
プロデューサー側の実装
PSC用NATサブネットの作成
PSCでは、プロデューサー側にNAT用の専用サブネットが必要です。このサブネットはpurpose = "PRIVATE_SERVICE_CONNECT"を指定します。
# PSC NAT Subnet (for Private Service Connect)
resource "google_compute_subnetwork" "psc_nat_subnet" {
name = "psc-nat-subnet"
ip_cidr_range = "10.0.2.0/24"
region = var.region
network = google_compute_network.vpc_network.id
purpose = "PRIVATE_SERVICE_CONNECT"
}
このサブネットは、コンシューマーからのトラフィックをNAT変換するために使用されます。
Service Attachmentの作成
Service Attachmentは、内部ロードバランサをPSC経由で公開するためのリソースです。
resource "google_compute_service_attachment" "psc_attachment" {
name = "${var.internal_lb_name_prefix}-psc-attachment"
region = var.region
description = "Private Service Connect attachment for internal load balancer"
# target_serviceはForwarding Ruleを指定する
target_service = google_compute_forwarding_rule.internal_lb_frontend.id
nat_subnets = [google_compute_subnetwork.psc_nat_subnet.id]
connection_preference = "ACCEPT_AUTOMATIC"
enable_proxy_protocol = false
reconcile_connections = false
}
重要なポイント
| パラメータ | 説明 |
|---|---|
target_service |
公開する内部ロードバランサのForwarding Rule |
nat_subnets |
PSC用NATサブネット（purpose = "PRIVATE_SERVICE_CONNECT"のサブネット） |
connection_preference |
ACCEPT_AUTOMATICで自動承認、ACCEPT_MANUALで手動承認 |
コンシューマー側の実装
VPCとサブネットの作成
コンシューマー側のVPCとサブネットを作成します。IPアドレス範囲はプロデューサー側と重複しても問題ありません。
resource "google_compute_network" "vpc_network2" {
name = var.vpc_name2
auto_create_subnetworks = false
}
resource "google_compute_subnetwork" "consumer_subnet" {
name = "consumer-subnet"
ip_cidr_range = "10.1.0.0/24"
region = var.region
network = google_compute_network.vpc_network2.id
}
PSCエンドポイントの作成
コンシューマー側では、PSCエンドポイントを作成してプロデューサーのService Attachmentに接続します。
# PSCエンドポイント用の内部IPアドレス
resource "google_compute_address" "psc_endpoint_ip" {
name = "psc-endpoint-ip"
region = var.region
address = "10.1.0.10"
address_type = "INTERNAL"
subnetwork = google_compute_subnetwork.consumer_subnet.id
}
# PSCエンドポイント（Forwarding Rule）
resource "google_compute_forwarding_rule" "psc_endpoint" {
name = "psc-endpoint-to-internal-lb"
region = var.region
network = google_compute_network.vpc_network2.id
subnetwork = google_compute_subnetwork.consumer_subnet.id
target = google_compute_service_attachment.psc_attachment.id
# エンドポイントのIPアドレス（リソースIDを指定）
ip_address = google_compute_address.psc_endpoint_ip.id
load_balancing_scheme = ""
}
動作確認
PSCエンドポイントのIPアドレス（10.1.0.10）に対してリクエストを送信すると、プロデューサー側の内部ロードバランサを経由してサービスにアクセスできます。
コンシューマーVPCに接続されたサービスから以下のようにアクセスします：
http://10.1.0.10/your_api_endpoint
これにより、異なるVPC間でもプライベートネットワーク内で通信が完結します。
まとめ
Private Service Connectを使用することで、異なるVPC間でのプライベート接続を実現できます。
ポイント
- PSCはVPCピアリングと異なり、IPアドレス範囲の重複が許容される
- プロデューサー側では、内部LBのForwarding RuleをService Attachmentで公開する
- PSC用NATサブネット（
purpose = "PRIVATE_SERVICE_CONNECT"）が必要 - コンシューマー側では、PSCエンドポイントのIPアドレスに向けてリクエストを送信する
-
connection_preferenceで接続の承認方法を制御できる
前回の記事との関係
- 前回：同一VPC内での内部ロードバランサによる通信
- 今回：PSCを用いた異なるVPC間での内部通信
これらを組み合わせることで、セキュアでスケーラブルなマイクロサービスアーキテクチャを構築できます。