1. はじめに
Cloud Load Balancing は、オンプレミス データセンターや他のパブリック クラウドなど、ハイブリッド接続で到達できる Google Cloud の外部に拡張されたエンドポイントへのトラフィックのロード バランシングをサポートします。
ハイブリッド戦略は、変化する市場の要求に応じて、アプリケーションを段階的にモダナイズするための実際的なソリューションです。これは、最新のクラウドベースのソリューションに移行するための一時的なハイブリッド デプロイか、組織の IT インフラストラクチャの恒久的な設備かも知れません。
ハイブリッド ロード バランシングを設定すると、Google Cloud の外部にある既存のインフラストラクチャで実行されているサービスでも Cloud Load Balancing のネットワーク機能のメリットを活用できます。
ハイブリッド サービスを他の VPC ネットワークで利用できるようにするには、Private Service Connect を使用してサービスを公開します。サービス アタッチメントを内部リージョン HTTP(S) ロードバランサの前に配置することで、他の VPC ネットワーク内のクライアントが、オンプレミスまたは他のクラウド環境で実行されている ハイブリッド サービスにアクセスできるようになります。
作成するアプリの概要
この Codelab では、ネットワーク エンドポイント グループを使用して、オンプレミス サービスへのハイブリッド接続を備えた内部 HTTP(S) ロードバランサを構築します。コンシューマ VPC はポート 80 を使用してオンプレミス サービスと通信できます。ポート 443 は Codelab の範囲外です。
学習内容
- ハイブリッド NEG バックエンドを使用して内部 HTTP(S) ロードバランサを作成する方法
- Private Service Connect プロデューサー（サービス アタッチメント）とコンシューマ（転送ルール）を確立する方法
必要なもの
- 確立済みのハイブリッド ネットワーキング（HA VPN、相互接続、SW-WAN など）
- Google Cloud プロジェクト
ハイブリッド接続を確立する
オンプレミスまたは他のクラウド環境と Google Cloud を接続するには、Cloud Router とともに Cloud Interconnect VLAN アタッチメントまたは Cloud VPN トンネルを使用して、ハイブリッド接続を確立する必要があります。高可用性接続の使用をおすすめします。
グローバル動的ルーティングが有効になっている Cloud Router は、BGP を介して特定のエンドポイントを学習し、Google Cloud VPC ネットワークにプログラムします。リージョン動的ルーティングはサポートされていません。静的ルートもサポートされていません。
Cloud Interconnect または Cloud VPN の構成に使用する Google Cloud VPC ネットワークは、ハイブリッド ロード バランシング デプロイの構成に使用するネットワークと同じです。VPC ネットワークのサブネットの CIDR 範囲がリモートの CIDR 範囲と競合しないようにしてください。IP アドレスが重複する場合、リモート接続よりもサブネット ルートが優先されます。
手順については、次をご覧ください。
カスタムルート アドバタイズ
以下のサブネットでは、Cloud Router からオンプレミス ネットワークへのカスタム アドバタイズが必要です。これにより、オンプレミスのファイアウォール ルールが更新されます。
サブネット | 説明 |
172.16.0.0/23 | オンプレミス サービスと直接通信するために使用されるプロキシ サブネット |
130.211.0.0/22、35.191.0.0/16 |
2. 始める前に
Codelab をサポートするようにプロジェクトを更新する
この Codelab では、Cloud Shell での gcloud 構成の実装に役立つ $variables を使用します。
Cloud Shell で次の操作を行います。
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab
3. プロデューサーの設定
プロデューサー VPC を作成する
Cloud Shell 内で、次のコマンドを実行します。
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
プロデューサー サブネットを作成する
Cloud Shell で次の操作を行います。
gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1
gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1
内部ロードバランサの IP アドレスを予約する
Cloud Shell 内で以下を実行します。Private Service Connect では SHARED_VIP の使用はサポートされていません。代わりに GCE_ENDPOINT を使用してください。
gcloud compute addresses create lb-ip \
--region=us-central1 \
--subnet=subnet-202 \
--purpose=GCE_ENDPOINT
compute addresses describe コマンドを使用して、割り振られた IP アドレスを表示します。
gcloud compute addresses describe lb-ip --region=us-central1 | grep address:
リージョン プロキシ サブネットを作成する
プロキシの割り当ては、ロードバランサ レベルではなく VPC レベルで行われます。Envoy ベースのロードバランサを使用する仮想ネットワーク（VPC）の各リージョンに、プロキシ専用サブネットを 1 つ作成する必要があります。同じリージョンおよび同じ VPC ネットワーク内に複数のロードバランサをデプロイすると、ロード バランシング用に同じプロキシ専用サブネットが共有されます。
- クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。
- 各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートをリッスンします。いずれかのプロキシがクライアントのネットワーク接続を受信して終了します。
- プロキシは、NEG 内の適切なバックエンド VM またはエンドポイントと接続を確立します。これは、ロードバランサの URL マップとバックエンド サービスによって決まります。
ネットワークが自動モードかカスタムモードかに関係なく、プロキシ専用サブネットを作成する必要があります。プロキシ専用サブネットでは 64 個以上の IP アドレスを指定する必要があります。これは、/26 以下のプレフィックス長に対応します。推奨されるサブネット サイズは /23（512 個のプロキシ専用アドレス）です。
Cloud Shell で次の操作を行います。
gcloud compute networks subnets create proxy-subnet-us-central \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=us-central1 \
--network=producer-vpc \
--range=172.16.0.0/23
Private Service Connect NAT サブネットを作成する
Private Service Connect で使用する 1 つ以上の専用サブネットを作成します。Google Cloud コンソールを使用してサービスを公開する場合、その作業中にサブネットを作成できます。サービスのロードバランサと同じリージョンにサブネットを作成します。通常のサブネットを Private Service Connect サブネットに変換することはできません。
Cloud Shell で次の操作を行います。
gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect
プロデューサーのファイアウォール ルールを作成する
Private Service Connect エンドポイントとサービス アタッチメント間のトラフィックを許可するファイアウォール ルールを構成します。この Codelab では、NAT サブネット 100.100.10.0/24 が Private Service Connect サービス アタッチメント（内部ロードバランサ）にアクセスできるように、上り（内向き）ファイアウォール ルールを作成しました。
Cloud Shell で次の操作を行います。
gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24
Cloud Shell 内で fw-allow-health-check ルールを作成し、Google Cloud ヘルスチェックが TCP ポート 80 でオンプレミス サービス（バックエンド サービス）に到達できるようにします。
gcloud compute firewall-rules create fw-allow-health-check \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--rules=tcp:80
ロードバランサが TCP ポート 80 でバックエンド インスタンスと通信できるように、プロキシ専用サブネットの上り（内向き）許可ファイアウォール ルールを作成します。
gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=172.16.0.0/23 \
--rules=tcp:80
ハイブリッド接続 NEG を設定する
NEG を作成するときは、Google Cloud とオンプレミスまたは他のクラウド環境との間の地理的距離を最小限に抑える ZONE を使用します。たとえば、ドイツのフランクフルトのオンプレミス環境にサービスをホストする場合、NEG の作成時に europe-west3-a Google Cloud ゾーンを指定できます。
また、Cloud Interconnect を使用している場合、NEG の作成に使用するゾーンは、Cloud Interconnect アタッチメントが構成されているリージョンと同じにする必要があります。
使用可能なリージョンとゾーンについては、Compute Engine のドキュメント: 使用可能なリージョンとゾーンをご覧ください。
Cloud Shell 内で gcloud compute network-endpoint-groups create コマンドを使用して、ハイブリッド接続 NEG を作成する
gcloud compute network-endpoint-groups create on-prem-service-neg \
--network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
--zone=us-central1-a \
--network=producer-vpc
Cloud Shell で、オンプレミス IP:Port エンドポイントをハイブリッド NEG に追加します。
gcloud compute network-endpoint-groups update on-prem-service-neg \
--zone=us-central1-a \
--add-endpoint="ip=192.168.1.5,port=80"
ロードバランサを構成する
次の手順では、ロードバランサ（転送ルール）を構成し、ネットワーク エンドポイント グループに関連付けます。
Cloud Shell 内で、オンプレミス サービスに渡すリージョン ヘルスチェックを作成する
gcloud compute health-checks create http http-health-check \
--region=us-central1 \
--use-serving-port
Cloud Shell 内で、ハイブリッド NEG を活用してオンプレミス バックエンド用のバックエンド サービスを作成する。
gcloud compute backend-services create on-premise-service-backend \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=HTTP \
--health-checks=http-health-check \
--health-checks-region=us-central1 \
--region=us-central1
Cloud Shell で、ハイブリッド NEG バックエンドをバックエンド サービスに追加します。RATE には、バックエンドで処理する最大 RATE を入力します。
gcloud compute backend-services add-backend on-premise-service-backend \
--region=us-central1 \
--balancing-mode=RATE \
--max-rate-per-endpoint=100 \
--network-endpoint-group=on-prem-service-neg \
--network-endpoint-group-zone=us-central1-a
Cloud Shell 内で、受信リクエストをバックエンド サービスに転送するための URL マップを作成する
gcloud compute url-maps create on-prem-svc-url-map \
--default-service on-premise-service-backend \
--region=us-central1
HTTP ターゲット プロキシを作成する
gcloud compute target-http-proxies create proxy-subnet-us-central\
--url-map=on-prem-svc-url-map \
--url-map-region=us-central1 \
--region=us-central1
受信リクエストをプロキシに転送する転送ルールを作成します。転送ルールの作成には、プロキシ専用サブネットを使用しないでください。
gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=subnet-202 \
--address=lb-ip \
--ports=80 \
--region=us-central1 \
--target-http-proxy=proxy-subnet-us-central \
--target-http-proxy-region=us-central1
4. ロードバランサを検証する
Cloud コンソールで、[ネットワーク サービス] > [ロード バランシング] > [ロードバランサ] に移動します。1 つの NEG は「Green」です。オンプレミス サービスへのヘルスチェックが成功したことを示す
‘on-premise-svc-url-map' を選択すると、フロントエンドの IP アドレスが生成され、バックエンド サービスを特定します。
5. オンプレミスから学習したルートを表示します。
[VPC ネットワーク] → [ルート] に移動します。学習されたオンプレミス サービス サブネット 192.168.1.0/27 に注意してください。
6. オンプレミス サービスへの接続を検証する
プロデューサー VPC から VM を作成し、オンプレミス サービスへの接続をテストします。その後、サービス アタッチメントを構成します。
Cloud Shell で、プロデューサー VPC にテスト インスタンスを作成します。
gcloud compute instances create test-box-us-central1 \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-201 \
--no-address
IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
- IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
- IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可します。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
Cloud Shell 内で、プロデューサー VPC にテスト インスタンスを作成する
gcloud compute firewall-rules create ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Cloud Shell で IAP を使用して test-box-us-central1 にログインし、ロード バランシングの IP アドレスに対して curl を実行してオンプレミス サービスへの接続を検証します。タイムアウトが発生した場合は再試行します。
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
オンプレミス サービスへの接続を検証する curl を実行します。検証が完了したら、VM を終了して Cloud Shell プロンプトに戻ります。ステップ 4 で特定した出力に基づいて、内部ロードバランサの IP を置き換えます。
user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
* Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
<
Welcome to my on-premise service!!
7. Private Service Connect サービス アタッチメントを作成する
次の手順では、サービス アタッチメントを作成します。コンシューマ エンドポイントとペア設定すると、VPC ピアリングを行うことなく、オンプレミス サービスへのアクセスが実現されます。
サービス アタッチメントを作成する
Cloud Shell で Service Attachment を作成します。
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet
省略可: 共有 VPC を使用する場合は、サービス プロジェクトにサービス アタッチメントを作成する
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>
TCP サービス アタッチメントを検証する
gcloud compute service-attachments describe service-1 --region us-central1
省略可: [ネットワーク サービス → Private Service Connect] に移動して、新しく作成されたサービス アタッチメントを表示します。
[Service-1] を選択すると、コンシューマが Private Service 接続を確立するために使用するサービス アタッチメント URI など、詳細が表示されます。後の手順で使用するため、URI をメモしておきます。
サービス アタッチメントの詳細: projects/<projectname>/regions/us-central1/serviceAttachments/service-1
8. コンシューマの設定
コンシューマ VPC を作成する
Cloud Shell 内で、次のコマンドを実行します。
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
コンシューマ サブネットを作成する
Cloud Shell で GCE サブネットを作成します。
gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1
Cloud Shell でコンシューマ エンドポイント サブネットを作成します。
gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1
コンシューマ エンドポイント（転送ルール）を作成する
Cloud Shell で、コンシューマ エンドポイントとして使用する静的 IP アドレスを作成します。
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
前に生成したサービス アタッチメント URI を使用して、コンシューマ エンドポイントを作成します。
Cloud Shell でコンシューマ エンドポイントを作成します。
gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1
9. コンシューマ Private Service Connect を検証する - コンシューマ VPC
コンシューマ VPC で、[ネットワーク サービス] → [Private Service Connect] → [接続済みエンドポイント] に移動して、Private Service 接続が正常に完了したことを確認します。確立された psc-consumer-1 接続と、前に作成した対応する IP アドレスをメモします。
psc-consumer-1 を選択すると、サービス アタッチメントの URI を含む詳細が提供されます。
10. コンシューマ Private Service Connect - プロデューサー VPC を検証する
プロデューサー VPC で、[ネットワーク サービス] → [Private Service Connect] → [公開サービス] に移動して、限定公開サービス接続が正常に完了したことを確認します。公開された service-1 接続に、1 つの転送ルール（接続エンドポイント）が表示されていることに注意してください。
11. 限定公開 DNS ゾーンを作成し、A レコード
PSC 接続エンドポイントにマッピングされた限定公開 DNS ゾーンを作成して、VPC 内の任意のホストからプロデューサーにシームレスにアクセスできるようにします。
Cloud Shell から
gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"
gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"
12. VM を使用してプロデューサー サービスへのコンシューマ アクセスを検証する
コンシューマ VPC から、コンシューマ エンドポイント service1.codelabs.net にアクセスしてオンプレミス サービスへの接続をテストする VM を作成します。
Cloud Shell で、コンシューマ VPC にテスト インスタンスを作成します。
gcloud compute instances create consumer-vm \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-101 \
--no-address
IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。
- IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
- IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可する。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。
Cloud Shell で、コンシューマ VPC にテスト インスタンスを作成します。
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Cloud Shell で IAP を使用して consumer-vm にログインし、dns FQDN service1.codelab.net に対して curl を実行してオンプレミス サービスへの接続を検証します。タイムアウトした場合は再試行する。
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
オンプレミス サービスへの接続を検証する curl を実行します。確認したら、VM を終了して Cloud Shell プロンプトに戻ります。
Cloud Shell で curl を実行します。
$ curl -v service1.codelab.net
* Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
<
Welcome to my on-premise service!!
オンプレミス サービスからのキャプチャの例を以下に示します。送信元 IP アドレス 172.16.0.13 は、プロキシ サブネット範囲 172.16.0.0/23 のものです。
13. プロデューサーのクリーンアップ
Producer コンポーネントの削除
Cloud Shell で、プロデューサー VPC のテスト インスタンスを削除します。
gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet
gcloud compute service-attachments delete service-1 --region=us-central1 --quiet
gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet
gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet
gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet
gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet
gcloud compute addresses delete lb-ip --region=us-central1 --quiet
gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet
gcloud compute health-checks delete http-health-check --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
14. コンシューマーのクリーンアップ
コンシューマ コンポーネントを削除する
Cloud Shell で、コンシューマ VPC のテスト インスタンスを削除します。
gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet
gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet
gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet
gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap-consumer --quiet
gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet
gcloud dns managed-zones delete codelab-zone --quiet
gcloud compute networks delete consumer-vpc --quiet
15. 完了
内部 HTTP(S) ロードバランサを使用して Private Service Connect を正常に構成して検証しました。
また、プロデューサー インフラストラクチャを作成し、オンプレミス サービスを指すプロデューサー VPC にサービス アタッチメントを追加しました。オンプレミス サービスへの接続を許可するコンシューマ VPC にコンシューマ エンドポイントを作成する方法について学習しました。
次のステップ
以下の Codelab をご覧ください。
- GKE で Private Service を使用してサービスを公開して使用する
- Private Service Connect でサービスを公開して使用する
- Private Service Connect と内部 TCP プロキシ ロードバランサを使用して、ハイブリッド ネットワーキング経由でオンプレミス サービスに接続する