概要
GCPにおけるVPC間接続は、システム設計の重要な要素です。適切な接続方式を選択することで、セキュリティ、パフォーマンス、コストを最適化できます。本記事では、VPC Peering、PSC（Private Service Connect）、TCP Proxyの特徴と使い分けについて詳しく解説します。
VPC間接続の3つの選択肢
1. VPC Peering - Customer VPC同士の接続
適用場面:
1
2
| [Project A VPC] ⟷ VPC Peering ⟷ [Project B VPC]
ユーザー管理 ユーザー管理
|
設定例:
1
2
3
4
5
| # VPC Peering作成
gcloud compute networks peerings create dev-to-prod \
--network=dev-vpc \
--peer-project=prod-project \
--peer-network=prod-vpc
|
メリット:
- 設定が簡単
- 低遅延・高スループット
- 追加コストなし
- 直接的な通信
制約:
- 両方のVPCの管理権限が必要
- IPアドレス重複不可
- トランジティブ接続不可
2. PSC（Private Service Connect） - Google Managed Service接続
適用場面:
- 一方がGoogle管理サービスの場合
- Datastream、Cloud SQL等との接続
1
2
| [Datastream VPC] ⟷ PSC ⟷ [Customer VPC]
Google管理 ユーザー管理
|
設定例:
1
2
3
4
5
6
7
8
| # PSC接続作成
gcloud compute addresses create psc-endpoint \
--subnet=app-subnet \
--addresses=10.0.2.100
gcloud compute forwarding-rules create datastream-psc \
--address=psc-endpoint \
--target-service-attachment=datastream-sa
|
メリット:
- Google管理サービスとの最適接続
- 高いセキュリティ
- 管理負荷が低い
- 新しい標準的手法
制約:
3. TCP Proxy - レガシー手法
適用場面:
- 上記が利用できない制約環境
- 既存システムとの互換性が必要
1
| [Source VPC] → [Proxy Instance] → [Target VPC]
|
設定例:
1
2
3
4
5
| # Proxy用インスタンス作成
gcloud compute instances create tcp-proxy \
--zone=asia-northeast1-a \
--machine-type=e2-medium \
--subnet=proxy-subnet
|
制約:
- 管理負荷が高い
- 単一障害点（SPOF）
- 性能制限あり
- セキュリティリスク
設計判断フローチャート
1
2
3
4
5
6
7
8
9
10
| VPC間接続の必要性
↓
同一VPC内配置可能？
↓ No
両方Customer VPC？
↓ Yes ↓ No
VPC Peering Google管理サービス？
↓ Yes ↓ No
PSC Interface TCP Proxy
(非推奨)
|
実際の設計例
パターン1: 開発・本番環境分離
1
2
3
4
5
6
7
8
9
10
11
| # 開発環境
Project: company-dev
VPC: dev-vpc (10.1.0.0/16)
# 本番環境
Project: company-prod
VPC: prod-vpc (10.2.0.0/16)
# 接続方式
Connection: VPC Peering
理由: 両方Customer VPC、管理権限あり
|
パターン2: データ基盤統合
1
2
3
4
5
6
7
8
9
10
| # アプリケーション基盤
VPC: app-vpc (10.10.0.0/16)
# データ分析基盤
Service: Datastream (Google Managed)
Database: AlloyDB (Google Managed)
# 接続方式
Connection: PSC Interface
理由: Google管理サービスとの接続
|
パターン3: マルチクラウド統合
1
2
3
4
5
6
7
8
9
| # GCP環境
VPC: gcp-vpc (10.0.0.0/16)
# AWS環境（VPN経由）
VPC: aws-vpc (10.100.0.0/16)
# 接続方式
Connection: Cloud VPN + BGP
理由: 異なるクラウド間接続
|
セキュリティ考慮事項
VPC Peering時のファイアウォール
1
2
3
4
5
| # 最小権限接続
gcloud compute firewall-rules create allow-db-access \
--source-ranges=10.1.2.0/24 \
--target-tags=database \
--allow=tcp:5432
|
PSC使用時の暗号化
1
2
3
| # SSL/TLS強制化
gcloud sql instances patch my-instance \
--require-ssl
|
パフォーマンス比較
| 接続方式 | 遅延 | スループット | 可用性 | 管理負荷 |
|---|
| VPC Peering | 最小 | 最高 | 高 | 低 |
| PSC | 小 | 高 | 高 | 低 |
| TCP Proxy | 中 | 中 | 中 | 高 |
トラブルシューティング
よくある接続問題
- IPアドレス重複
1
2
3
| # 重複チェック
gcloud compute networks describe vpc-a --format="value(IPv4Range)"
gcloud compute networks describe vpc-b --format="value(IPv4Range)"
|
- ファイアウォールルール不足
1
2
| # 接続テスト
gcloud compute ssh test-instance --command="nc -zv target-ip 5432"
|
- DNS解決問題
1
2
3
| # DNS設定確認
gcloud compute instances describe instance-name \
--format="value(networkInterfaces[0].accessConfigs[0].natIP)"
|
ベストプラクティス
1. 設計原則
- 同一VPC内配置を最優先検討
- 管理権限の有無で接続方式を決定
- 将来の拡張性を考慮
2. セキュリティ強化
- 最小権限の原則を適用
- ネットワークレベル + アプリケーションレベルの暗号化
- 定期的なアクセスログ監査
3. 運用効率化
- インフラストラクチャコードでの管理
- モニタリング・アラート設定
- 文書化の徹底
まとめ
VPC間接続の選択は、管理権限とサービスタイプに基づいて決定します：
- Customer VPC同士 → VPC Peering
- Google Managed Service → PSC Interface
- 制約環境 → TCP Proxy（非推奨）
適切な接続方式の選択により、セキュアで効率的なクラウドインフラストラクチャを構築できます。
📅 作成日: 2025年09月09日
参考リンク: