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 ピアリング状態です。consumer-vpc と producer-vpc の 2 つの VPC がピアリングされます。Producer-VPC には、内部ネットワーク パススルー ロードバランサを介して公開されるシンプルな Apache サービスがあります。consumer-vpc にはテスト目的の consumer-vm が 1 つあります。
状態 2 は PSC テストの状態です。新しい転送ルールを作成し、このルールを使用してサービス アタッチメントに関連付けます。次に、consumer-vpc にテスト用の PSC エンドポイントを作成して、PSC サービスが期待どおりに動作していることをテストします。
状態 3 は移行状態です。VPC ピアリング ベースのサービスがデプロイされている producer-vpc のサブネット範囲を予約して、consumer-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 は、リージョン内部ネットワーク パススルー ロードバランサを前面に配置した非マネージド インスタンス グループに追加されます。
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
消費者の行動
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 の両方のルートが表示されます。
消費者の行動
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 限定公開ゾーンを作成します。
example.com ドメインに、先ほど作成したネットワーク パススルー ロードバランサ転送ルールの IP アドレスを指す service.example.com を指す A レコードを追加します。転送ルールの 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 のアーキテクチャが作成されました。
consumer-client 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
consumer-client VM から
curl service.example.com
想定される出力
I am a Producer Service.
consumer-client 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. 「テスト」コンシューマ PSC エンドポイントをプロデューサー サービスに接続し、テスト（コンシューマ アクティビティ）を行う
アーキテクチャは状態 2 になっています。
この時点では、VPC ピアリングを介して公開されている既存のプロデューサー サービスはまだ稼働しており、本番環境シナリオで正常に動作しています。「テスト用」の PSC エンドポイントを作成して、現在の VPC ピアリング サブネットをコンシューマ VPC に移行するサービス停止期間を開始する前に、公開されたサービス アタッチメントが正しく機能していることを確認します。最終的な接続は、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
「テスト」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 ピアリング ベースのプロデューサー サービスが停止します。次に、Internal Ranges API を使用して、転送ルールのサブネットを producer-vpc から consumer-vpc に移行します。これにより、そのサブネットは producer-vpc で削除されるまでの間は使用できなくなり、consumer-vpc での作成用に移行目的でのみ指定されます。
内部範囲 API を使用するには、既存の VPC ピアリング転送ルール サブネット（producer-fr-subnet, 192.168.0.0/28）を予約し、consumer-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 エンドポイントのみを含めることができます。
消費者の行動
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 エンドポイントを作成する（コンシューマー アクティビティ）
この時点では、プロデューサー サービスはまだ停止しています。作成したサブネットはロックされたままで、移行という特定の目的にのみ使用できます。このサブネットで 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 エンドポイントをテストする（コンシューマーのアクティビティ）
この時点では、状態 3 のアーキテクチャになっています。
Cloud Shell から
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
consumer-client VM から
curl service.example.com
想定される出力
I am a Producer Service.
consumer-client VM から
exit
この時点でサービス停止は終了し、サービスは再び稼働しています。既存の DNS に変更を加える必要はありません。コンシューマー側のクライアントに変更を加える必要はありません。アプリケーションは、移行したサービスへのオペレーションを再開するだけで済みます。
16. 移行のクリーンアップ
移行を完了するために、いくつかのクリーンアップ手順を実行する必要があります。リソースを削除してロックを解除する必要があります。
内部範囲サブネットをロック解除する
これにより、移行されたサブネットがロック解除され、その目的を「PEER_MIGRATION」から「PRIVATE」に変更できます。
プロデューサー アクティビティ
Cloud Shell から
gcloud network-connectivity internal-ranges delete producer-peering-internal-range
消費者の行動
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
消費者の行動
Cloud Shell から
gcloud compute networks peerings delete consumer-vpc-peering \
--network=consumer-vpc
「test」PSC エンドポイントを削除する
消費者 - アクティビティ
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
consumer-client VM から
curl service.example.com
想定される出力
I am a Producer Service.
consumer-client 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 サービスへの移行を実現する。
- サービス移行のためにダウンタイムが発生するタイミングの理解
- 移行のクリーンアップ手順