1. はじめに
VPC ピアリングは、プロデューサーがユーザーにサービス消費を提供するための一般的な方法です。ただし、VPC ピアリングを使用すると、非推移的 VPC ピアリング、大量の IP アドレス消費、ピアリングされた VPC 内のリソースの過剰な公開など、多くのルーティングの複雑さが生じます。
Private Service Connect（PSC）は、プロデューサーがワークロード VPC でコンシューマーがプロビジョニングする単一のエンドポイントを介してサービスを公開できるようにする接続方法です。これにより、VPC ピアリングでユーザーが直面する多くの問題が解消されます。多くの新しいサービスが PSC で作成されていますが、VPC ピアリング サービスとして存在するサービスもまだ多くあります。
Google Cloud は、VPC ピアリングで作成したサービスを PSC ベースのアーキテクチャに移行するための移行パスを導入しました。この移行方法を使用すると、VPC ピアリングを介して公開されるプロデューサー サービスの IP アドレスが PSC ベースのアーキテクチャに保持されるため、コンシューマーに必要な変更は最小限で済みます。この Codelab に沿って、この移行を行うための技術的な手順を学びます。
注: この移行パスは、プロデューサーとコンシューマーが同じ Google Cloud 組織内に存在するサービスにのみ適用されます。VPC ピアリングを使用する Google Cloud サービスまたはサードパーティ サービスでは、同様の移行方法が使用されますが、サービス自体に合わせてカスタマイズされます。これらのタイプのサービスの移行パスについては、適切な関係者にお問い合わせください。
学習内容
- VPC ピアリング ベースのサービスを設定する方法
- PSC ベースのサービスを設定する方法
- Internal-Ranges API を使用して、VPC ピアリングを介してサブネット移行を実行し、VPC ピアリングから PSC サービスへの移行を実現します。
- サービス移行でダウンタイムが必要になるタイミングについて
- 移行のクリーンアップ手順
必要なもの
- オーナー権限を持つ Google Cloud プロジェクト
2. Codelab のトポロジ
わかりやすくするため、この Codelab ではすべてのリソースを 1 つのプロジェクトに集約します。プロデューサーとコンシューマーが異なるプロジェクトに属している場合に、プロデューサー側で実行する必要があるアクションとコンシューマー側で実行する必要があるアクションは、Codelab に記載されます。
この Codelab には 4 つの状態があります。
状態 1 は VPC ピアリングの状態です。2 つの VPC（consumer-vpc と producer-vpc）がピアリングされます。producer-vpc には、内部ネットワーク パススルー ロードバランサを介して公開されるシンプルな Apache サービスがあります。consumer-vpc には、テスト目的で単一の consumer-vm があります。
状態 2 は PSC テスト状態です。新しい転送ルールを作成し、このルールを使用してサービス アタッチメントに関連付けます。次に、PSC サービスが想定どおりに動作することを確認するために、consumer-vpc にテスト PSC エンドポイントを作成します。
状態 3 は移行状態です。VPC ピアリング ベースのサービスがデプロイされたプロデューサー VPC のサブネット範囲を予約し、コンシューマー VPC で使用します。次に、producer-vpc の既存の転送ルールと同じ IP アドレスを使用して、新しい PSC エンドポイントを作成します。
状態 4 は最終的な PSC 状態です。テスト PSC エンドポイントをクリーンアップし、consumer-vpc と producer-vpc の間の VPC ピアリングを削除します。
3. 設定と要件
セルフペース型の環境設定
- Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。
- プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。いつでも更新できます。
- プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は
PROJECT_IDと識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。 - なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。
- 次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクトを削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
Cloud Shell を起動する
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。
Google Cloud Console で、右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。この Codelab での作業はすべて、ブラウザ内から実行できます。インストールは不要です。
4. 始める前に
API を有効にする
Cloud Shell で、プロジェクトが設定されていることを確認し、変数を構成します。
gcloud auth login gcloud config list project gcloud config set project [YOUR-PROJECT-ID] export projectid=[YOUR-PROJECT-ID] export region=us-central1 export zone=$region-a echo $projectid echo $region echo $zone
必要なサービスをすべて有効にする
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com gcloud services enable dns.googleapis.com
5. プロデューサー VPC ネットワークを作成する（プロデューサー アクティビティ）
VPC ネットワーク
Cloud Shell から
gcloud compute networks create producer-vpc \
--subnet-mode=custom
サブネットを作成する
Cloud Shell から
gcloud compute networks subnets create producer-service-subnet \
--network=producer-vpc \
--range=10.0.0.0/28 \
--region=$region
gcloud compute networks subnets create producer-fr-subnet \
--network=producer-vpc \
--range=192.168.0.0/28 \
--region=$region
プロデューサーの Cloud Router と Cloud NAT を作成する
Cloud Shell から
gcloud compute routers create $region-cr \
--network=producer-vpc \
--region=$region
gcloud compute routers nats create $region-nat \
--router=$region-cr \
--region=$region \
--nat-all-subnet-ip-ranges \
--auto-allocate-nat-external-ips
プロデューサー ネットワーク ファイアウォール ポリシーとファイアウォール ルールを作成する
Cloud Shell から
gcloud compute network-firewall-policies create producer-vpc-policy --global
gcloud compute network-firewall-policies associations create \
--firewall-policy producer-vpc-policy \
--network producer-vpc \
--name network-producer-vpc \
--global-firewall-policy
IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
- IAP を使用してアクセス可能にするすべての VM インスタンスに適用されます。
- IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可します。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
Cloud Shell から
gcloud compute network-firewall-policies rules create 1000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "SSH with IAP" \
--direction INGRESS \
--src-ip-ranges 35.235.240.0/20 \
--layer4-configs tcp:22 \
--global-firewall-policy
また、ロードバランサのヘルスチェックをサービスに許可するルールと、consumer-vpc から接続する VM からのネットワーク トラフィックを許可するルールを 2 つ作成します。
Cloud Shell から
gcloud compute network-firewall-policies rules create 2000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "LB healthchecks" \
--direction INGRESS \
--src-ip-ranges 130.211.0.0/22,35.191.0.0/16 \
--layer4-configs tcp:80 \
--global-firewall-policy
gcloud compute network-firewall-policies rules create 3000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "allow access from consumer-vpc" \
--direction INGRESS \
--src-ip-ranges 10.0.1.0/28 \
--layer4-configs tcp:80 \
--global-firewall-policy
6. プロデューサー サービスの設定（プロデューサー アクティビティ）
リージョン内部ネットワーク パススルー ロードバランサでフロントエンド処理される非マネージド インスタンス グループに追加される Apache ウェブサーバーを実行する単一の VM を使用して、プロデューサー サービスを作成します。
VM と非マネージド インスタンス グループを作成する
Cloud Shell から
gcloud compute instances create producer-service-vm \
--network producer-vpc \
--subnet producer-service-subnet \
--zone $zone \
--no-address \
--metadata startup-script='#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
a2enmod ssl
sudo a2ensite default-ssl
echo "I am a Producer Service." | \
tee /var/www/html/index.html
systemctl restart apache2'
Cloud Shell から
gcloud compute instance-groups unmanaged create prod-uig \ --zone=$zone gcloud compute instance-groups unmanaged add-instances prod-uig \ --zone=$zone \ --instances=producer-service-vm
リージョン内部ネットワーク パススルー ロードバランサを作成する
Cloud Shell から
gcloud compute health-checks create http producer-hc \
--region=$region
gcloud compute backend-services create producer-bes \
--load-balancing-scheme=internal \
--protocol=tcp \
--region=$region \
--health-checks=producer-hc \
--health-checks-region=$region
gcloud compute backend-services add-backend producer-bes \
--region=$region \
--instance-group=prod-uig \
--instance-group-zone=$zone
gcloud compute addresses create producer-fr-ip\
--region $region \
--subnet producer-fr-subnet \
--addresses 192.168.0.2
gcloud compute forwarding-rules create producer-fr \
--region=$region \
--load-balancing-scheme=internal \
--network=producer-vpc \
--subnet=producer-fr-subnet \
--address=producer-fr-ip \
--ip-protocol=TCP \
--ports=80 \
--backend-service=producer-bes \
--backend-service-region=$region
7. コンシューマー VPC ネットワークを作成する（コンシューマー アクティビティ）
VPC ネットワーク
Cloud Shell から
gcloud compute networks create consumer-vpc \
--subnet-mode=custom
サブネットの作成
Cloud Shell から
gcloud compute networks subnets create consumer-vm-subnet \
--network=consumer-vpc \
--range=10.0.1.0/28 \
--region=$region
コンシューマー ネットワーク ファイアウォール ポリシーとファイアウォール ルールを作成する
consumer-vpc 用に別のネットワーク ファイアウォール ポリシーを作成します。
Cloud Shell から
gcloud compute network-firewall-policies create consumer-vpc-policy --global
gcloud compute network-firewall-policies associations create \
--firewall-policy consumer-vpc-policy \
--network consumer-vpc \
--name network-consumer-vpc \
--global-firewall-policy
gcloud compute network-firewall-policies rules create 1000 \
--action ALLOW \
--firewall-policy consumer-vpc-policy \
--description "SSH with IAP" \
--direction INGRESS \
--src-ip-ranges 35.235.240.0/20 \
--layer4-configs tcp:22 \
--global-firewall-policy
8. VPC ピアを作成する
プロデューサー アクティビティ
Cloud Shell から
gcloud compute networks peerings create producer-vpc-peering \
--network=producer-vpc \
--peer-project=$projectid \
--peer-network=consumer-vpc
Consumer Activity
Cloud Shell から
gcloud compute networks peerings create consumer-vpc-peering \
--network=consumer-vpc \
--peer-project=$projectid \
--peer-network=producer-vpc
consumer-vpc のルートのリストを確認して、ピアリングが確立されていることを確認します。consumer-vpc と producer-vpc の両方のルートが表示されます。
Consumer Activity
Cloud Shell から
gcloud compute routes list --filter="network=consumer-vpc"
想定される出力
NAME: default-route-49dda7094977e231 NETWORK: consumer-vpc DEST_RANGE: 0.0.0.0/0 NEXT_HOP: default-internet-gateway PRIORITY: 1000 NAME: default-route-r-10d65e16cc6278b2 NETWORK: consumer-vpc DEST_RANGE: 10.0.1.0/28 NEXT_HOP: consumer-vpc PRIORITY: 0 NAME: peering-route-496d0732b4f11cea NETWORK: consumer-vpc DEST_RANGE: 192.168.0.0/28 NEXT_HOP: consumer-vpc-peering PRIORITY: 0 NAME: peering-route-b4f9d3acc4c08d55 NETWORK: consumer-vpc DEST_RANGE: 10.0.0.0/28 NEXT_HOP: consumer-vpc-peering PRIORITY: 0
9. DNS ゾーンを作成する（コンシューマー アクティビティ）
より現実的な例を示すために、限定公開 IP アドレスではなく DNS 経由でプロデューサー サービスを呼び出す Cloud DNS 限定公開ゾーンを作成します。
以前に作成したネットワーク パススルー ロードバランサの転送ルール IP アドレスに service.example.com を指す A レコードを example.com ドメインに追加します。転送ルールの IP アドレスは 192.168.0.2 です。
Cloud Shell から
gcloud dns managed-zones create "producer-service" \ --dns-name=example.com \ --description="producer service dns" \ --visibility=private \ --networks=consumer-vpc gcloud dns record-sets transaction start \ --zone="producer-service" gcloud dns record-sets transaction add 192.168.0.2 \ --name=service.example.com \ --ttl=300 \ --type=A \ --zone="producer-service" gcloud dns record-sets transaction execute \ --zone="producer-service"
10. VPC ピアリング経由のプロデューサー サービスのテスト（コンシューマー アクティビティ）
これで、状態 1 のアーキテクチャが作成されました。
コンシューマー クライアント VM を作成する
Cloud Shell から
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
接続をテストする
Cloud Shell から
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
コンシューマー クライアント VM から
curl service.example.com
想定される出力
I am a Producer Service.
コンシューマー クライアント VM から
exit
11. Private Service Connect 用にサービスを準備する（プロデューサー アクティビティ）
初期設定の手順がすべて完了したので、Private Service Connect への移行に向けて VPC ピアリング サービスの準備を開始します。このセクションでは、サービス アタッチメントを介してサービスが公開されるように構成して、producer-vpc を変更します。既存のサブネットを consumer-vpc に移行して、サービスの既存の IP アドレスを維持できるように、新しいサブネットとそのサブネット内に新しい転送ルールを作成する必要があります。
新しいロードバランサ転送ルール IP がホストされるサブネットを作成します。
Cloud Shell から
gcloud compute networks subnets create producer-psc-fr-subnet \
--network=producer-vpc \
--range=10.0.2.64/28 \
--region=$region
ロードバランサの転送ルールの内部 IP アドレスを作成します。
Cloud Shell から
gcloud compute addresses create producer-psc-ip \ --region $region \ --subnet producer-psc-fr-subnet \ --addresses 10.0.2.66
新しいロードバランサの転送ルールを作成します。このルールは、以前に構成したバックエンド サービスとヘルスチェックを使用するように構成されています。
Cloud Shell から
gcloud compute forwarding-rules create psc-service-fr \ --region=$region \ --load-balancing-scheme=internal \ --network=producer-vpc \ --subnet=producer-psc-fr-subnet \ --address=producer-psc-ip \ --ip-protocol=TCP \ --ports=80 \ --backend-service=producer-bes \ --backend-service-region=$region
psc-nat-subnet は、ネットワーク アドレス変換の目的で PSC サービス アタッチメントに関連付けられます。本番環境のユースケースでは、このサブネットは、接続されているエンドポイントの数をサポートするように適切にサイズ設定する必要があります。詳細については、PSC NAT サブネットのサイジングに関するドキュメントをご覧ください。
Cloud Shell から
gcloud compute networks subnets create psc-nat-subnet \
--network=producer-vpc \
--range=10.100.100.0/28 \
--region=$region \
--purpose=PRIVATE_SERVICE_CONNECT
psc-nat-subnet からのトラフィックを許可するために、ネットワーク ファイアウォール ポリシーに追加のファイアウォール ルールを追加する必要があります。PSC を介してサービスにアクセスする場合、トラフィックの送信元は psc-nat-subnet になります。
Cloud Shell から
gcloud compute network-firewall-policies rules create 2001 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "allow PSC NAT subnet" \
--direction INGRESS \
--src-ip-ranges 10.100.100.0/28 \
--layer4-configs tcp:80 \
--global-firewall-policy
サービス アタッチメントを作成し、サービス アタッチメント URI をメモして、次のセクションで PSC エンドポイントを構成します。
Cloud Shell から
gcloud compute service-attachments create producer-sa \
--region=$region \
--producer-forwarding-rule=psc-service-fr \
--connection-preference=ACCEPT_MANUAL \
--consumer-accept-list=$projectid=5 \
--nat-subnets=psc-nat-subnet
Cloud Shell から
gcloud compute service-attachments describe producer-sa --region=$region
出力例:
connectionPreference: ACCEPT_MANUAL consumerAcceptLists: - connectionLimit: 5 projectIdOrNum: $projectid creationTimestamp: '2025-04-24T11:23:09.886-07:00' description: '' enableProxyProtocol: false fingerprint: xxx id: 'xxx' kind: compute#serviceAttachment name: producer-sa natSubnets: - https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/psc-nat-subnet pscServiceAttachmentId: high: 'xxx' low: 'xxx' reconcileConnections: false region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/serviceAttachments/producer-sa targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/forwardingRules/psc-service-fr
12. 「test」コンシューマー PSC エンドポイントをプロデューサー サービスに接続してテストする（コンシューマー アクティビティ）
アーキテクチャは State 2 になりました。
この時点で、VPC ピアリングを介して公開された既存のプロデューサー サービスは、本番環境シナリオで引き続き稼働し、正常に動作しています。現在の VPC ピアリング サブネットをコンシューマー VPC に移行する停止期間を開始する前に、公開されたサービス アタッチメントが正しく機能していることを確認するために、「テスト」PSC エンドポイントを作成します。最終的な接続は、VPC ピアリング ベースのサービスの現在の転送ルールと同じ IP アドレスを持つ PSC エンドポイントになります。
PSC エンドポイントを作成する
Cloud Shell から
gcloud compute addresses create test-psc-endpoint-ip \
--region=$region \
--subnet=consumer-vm-subnet \
--addresses 10.0.1.3
以下のターゲット サービスは、前の手順でメモしたサービス アタッチメント URI になります。
Cloud Shell から
gcloud compute forwarding-rules create test-psc-endpoint \ --region=$region \ --network=consumer-vpc \ --address=test-psc-endpoint-ip \ --target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa
「test」PSC エンドポイントをテストする
Cloud Shell から
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
consumer-client から
curl 10.0.1.3
想定される出力
I am a Producer Service.
consumer-client から
exit
13. 既存のプロデューサー転送ルール サブネットを移行する
これらの手順を実行すると、ライブ VPC ピアリング ベースのプロデューサー サービスで停止が発生します。次に、内部範囲 API を使用して、転送ルールのサブネットを producer-vpc から consumer-vpc に移行します。これにより、プロデューサー VPC でサブネットを削除し、コンシューマー VPC での作成を移行目的でのみ指定するまでの間、サブネットが使用されないようにロックされます。
内部範囲 API では、既存の VPC ピアリング転送ルール サブネット（producer-fr-subnet、192.168.0.0/28）を予約し、コンシューマー VPC（consumer-psc-subnet）でターゲット サブネット名を指定する必要があります。この名前の新しいサブネットを consumer-vpc に作成する手順は次のとおりです。
移行用に producer-fr-subnet を予約する
プロデューサー アクティビティ
Cloud Shell から
gcloud network-connectivity internal-ranges create producer-peering-internal-range \
--ip-cidr-range=192.168.0.0/28 \
--network=producer-vpc \
--usage=FOR_MIGRATION \
--migration-source=projects/$projectid/regions/$region/subnetworks/producer-fr-subnet \
--migration-target=projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
作成した内部範囲に対して describe を実行して、サブネットの状態を表示します。
プロデューサー アクティビティ
Cloud Shell から
gcloud network-connectivity internal-ranges describe producer-peering-internal-range
出力例:
createTime: '2025-04-24T19:26:10.589343291Z' ipCidrRange: 192.168.0.0/28 migration: source: projects/$projectid/regions/$region/subnetworks/producer-fr-subnet target: projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet name: projects/$projectid/locations/global/internalRanges/producer-peering-internal-range network: https://www.googleapis.com/compute/v1/projects/$project/global/networks/producer-vpc peering: FOR_SELF updateTime: '2025-04-24T19:26:11.521960016Z' usage: FOR_MIGRATION
VPC ピアリング ベースの転送ルールとサブネットを削除する
プロデューサー アクティビティ
Cloud Shell から
gcloud compute forwarding-rules delete producer-fr --region=$region gcloud compute addresses delete producer-fr-ip --region=$region gcloud compute networks subnets delete producer-fr-subnet --region=$region
サブネットを移行する
以前に作成した内部範囲を使用して新しいサブネットを作成し、サブネットを consumer-vpc に移行します。このサブネットの名前は、先ほどターゲットにした名前（consumer-psc-subnet）と同じにする必要があります。PEER_MIGRATION の特定の目的は、ピアリングされた VPC 間のサブネット移行用にサブネットが予約されていることを示しています。この目的フラグを使用すると、このサブネットには予約済みの静的 IP アドレスと PSC エンドポイントのみを含めることができます。
Consumer Activity
Cloud Shell から
gcloud compute networks subnets create consumer-psc-subnet \ --purpose=PEER_MIGRATION \ --network=consumer-vpc \ --range=192.168.0.0/28 \ --region=$region
14. 最終状態の PSC エンドポイント（コンシューマー アクティビティ）を作成します。
この時点では、Producer サービスはまだダウンしています。作成したサブネットはロックされたままで、移行という特定の目的にのみ使用できます。このサブネットに VM を作成してみることで、これをテストできます。VM の作成は失敗します。
Cloud Shell から
gcloud compute instances create test-consumer-vm \
--zone=$zone \
--subnet=consumer-psc-subnet \
--no-address
想定される出力
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Subnetwork must have purpose=PRIVATE.
このサブネットは PSC エンドポイントの作成にのみ使用できます。作成する IP アドレスは、プロデューサー サービスが VPC ピアリングで使用した転送ルールと同じ IP を使用します。
Cloud Shell から
gcloud compute addresses create psc-endpoint-ip \
--region=$region \
--subnet=consumer-psc-subnet \
--addresses 192.168.0.2
ここでも、前にメモした「test」PSC エンドポイントの作成に使用したのと同じサービス アタッチメント URI を使用する必要があります。
Cloud Shell から
gcloud compute forwarding-rules create psc-endpoint \
--region=$region \
--network=consumer-vpc \
--address=psc-endpoint-ip \
--target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa
15. 最終状態の PSC エンドポイント（コンシューマー アクティビティ）をテストします。
この時点で、State 3 アーキテクチャになります。
Cloud Shell から
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
コンシューマー クライアント VM から
curl service.example.com
想定される出力
I am a Producer Service.
コンシューマー クライアント VM から
exit
この時点で、サービス停止は終了し、サービスが再び稼働しています。既存の DNS に変更を加える必要はありませんでした。コンシューマー側のクライアントに変更を加える必要はありません。アプリケーションは、移行されたサービスへのオペレーションを再開するだけです。
16. 移行のクリーンアップ
移行を完了するには、クリーンアップの手順をいくつか実行する必要があります。リソースを削除してロックを解除する必要があります。
内部範囲サブネットのロックを解除する
これにより、移行されたサブネットがロック解除され、その目的を「PEER_MIGRATION」から「PRIVATE」に変更できるようになります。
プロデューサー アクティビティ
Cloud Shell から
gcloud network-connectivity internal-ranges delete producer-peering-internal-range
Consumer Activity
Cloud Shell から
gcloud compute networks subnets update consumer-psc-subnet \
--region=$region \
--purpose=PRIVATE
gcloud compute networks subnets describe consumer-psc-subnet --region=$region
出力例:
creationTimestamp: '2025-04-24T12:29:33.883-07:00' fingerprint: xxx gatewayAddress: 192.168.0.1 id: 'xxx' ipCidrRange: 192.168.0.0/28 kind: compute#subnetwork name: consumer-psc-subnet network: https://www.googleapis.com/compute/v1/projects/$projectid/global/networks/consumer-vpc privateIpGoogleAccess: false privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS purpose: PRIVATE region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
VPC ピアを削除する
プロデューサー アクティビティ
Cloud Shell から
gcloud compute networks peerings delete producer-vpc-peering \
--network=producer-vpc
Consumer Activity
Cloud Shell から
gcloud compute networks peerings delete consumer-vpc-peering \
--network=consumer-vpc
「test」PSC エンドポイントを削除します。
Consumer-Activity
Cloud Shell から
gcloud compute forwarding-rules delete test-psc-endpoint --region=$region gcloud compute addresses delete test-psc-endpoint-ip --region=$region
17. 移行後の最終テスト（ユーザー アクティビティ）
この時点で、状態 4 のアーキテクチャ（最終状態）が実現されています。
PSC エンドポイントの接続性を再度テストして、移行のクリーンアップによる悪影響がないことを確認します。
Cloud Shell から
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
コンシューマー クライアント VM から
curl service.example.com
想定される出力
I am a Producer Service.
コンシューマー クライアント VM から
exit
SUCCESS!
18. クリーンアップ手順
Cloud Shell から
gcloud compute forwarding-rules delete psc-endpoint --region=$region -q gcloud compute addresses delete psc-endpoint-ip --region=$region -q gcloud compute instances delete consumer-client --zone=$zone --project=$projectid -q gcloud dns record-sets delete service.example.com --zone="producer-service" --type=A -q gcloud dns managed-zones delete "producer-service" -q gcloud compute network-firewall-policies rules delete 1000 --firewall-policy consumer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies associations delete --firewall-policy=consumer-vpc-policy --name=network-consumer-vpc --global-firewall-policy -q gcloud compute network-firewall-policies delete consumer-vpc-policy --global -q gcloud compute networks subnets delete consumer-psc-subnet --region=$region -q gcloud compute networks subnets delete consumer-vm-subnet --region=$region -q gcloud compute networks delete consumer-vpc -q gcloud compute service-attachments delete producer-sa --region=$region -q gcloud compute forwarding-rules delete psc-service-fr --region=$region -q gcloud compute addresses delete producer-psc-ip --region=$region -q gcloud compute backend-services delete producer-bes --region=$region -q gcloud compute health-checks delete producer-hc --region=$region -q gcloud compute instance-groups unmanaged delete prod-uig --zone=$zone -q gcloud compute instances delete producer-service-vm --zone=$zone --project=$projectid -q gcloud compute network-firewall-policies rules delete 3000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy --name=network-producer-vpc --global-firewall-policy -q gcloud compute network-firewall-policies delete producer-vpc-policy --global -q gcloud compute routers nats delete $region-nat --router=$region-cr --region=$region -q gcloud compute routers delete $region-cr --region=$region -q gcloud compute networks subnets delete psc-nat-subnet --region=$region -q gcloud compute networks subnets delete producer-psc-fr-subnet --region=$region -q gcloud compute networks subnets delete producer-service-subnet --region=$region -q gcloud compute networks delete producer-vpc -q
19. 完了
以上で、この Codelab は完了です。
学習した内容
- VPC ピアリング ベースのサービスを設定する方法
- PSC ベースのサービスを設定する方法
- Internal-Ranges API を使用して、VPC ピアリングを介してサブネット移行を実行し、VPC ピアリングから PSC サービスへの移行を実現します。
- サービス移行でダウンタイムが必要になるタイミングについて
- 移行のクリーンアップ手順