みなさん、こんにちは。
Google Cloud でインフラ周りを担当する Customer Enginner をしている Takao です。
このBlogは、Google Cloud Japan Advent Calendar の12/12分です。基本的に今年はZenn.devでみんな書いているので、合わせてGoogle Cloud Japanのグループページもチェックしてみてください。
TL;DR:
今回のトピックは、Private Service Connect (PSC)です。Google Cloudにおいては、VPCの1機能として位置づけられています。
そもそもPSCって何？という方向けに簡単に説明すると、PSCはサービスの提供者とサービスの利用者を「ネットワークとしてつなげる」のではなく「サービスとしてつなげる」ための仕組みです。下図はサービスの提供者（下図においては Producer VPC と表記）とサービスの利用者（下図においては Consumer VPC と表記）の間を、VPC Peeringを用いて「ネットワークとしてつなげる」場合（左側）と、PSCを用いて「サービスとしてつなげる」場合（右側）の違いを簡単に図示したものです。
VPC PeeringとPrivate Service Connectの比較
VPC Peeringを用いて「ネットワークとしてつなげる」場合には、当然ですがお互いをネットワークとして意識した接続が必要です。IPアドレスの重複はできませんし、お互いルーティングを考慮した構成が必要です。セキュリティに関しても、適切なファイアウォールを双方が構成する必要があります。
対して、PSCを用いて「サービスとしてつなげる」場合には、サービスの提供者と利用者はお互いをネットワークとして意識する必要性はなくなります。サービスの提供者は誰に対してどのサービスを提供するのかを管理し、サービスの利用者は自分が管理するVPC内にサービスへの接続点となる PSC Endpoint を用意することで、サービスへの接続が可能となります。
より詳細には、このBlogはMediumの方に私が書いたBlogシリーズの続き扱いとなっていますので、まずはそちらからお読みください。下記が「Mediumの方に私が書いたBlogシリーズ」です。2022/1〜3に書いていたようです。ちょうど、今年の頭頃ですね。Blogに関しては、PSCに始まり、PSCに終わる1年ということになりそうです。
2022年のPSC関連リリース
PSCは精力的に機能追加と新規対応が進められているため、上記MedumでのBlogの内容の一部はすでに情報として古くなってしまっている部分もあったりします。そんなわけで、まずは本題に入る前に年末っぽく今年のPSC絡みのUpdateを振り返ってみたいと思います。
PSCはRelease NotesとしてはVPCの一部として扱われています。…が、最近のVPCのRelease NotesはPSC関連のアップデートが多く、PSCのRelease Notesのようになっています。このあたりから見ても、Google CloudとしてのPSCへの力の入れようがわかりますね。
なお、日付部分がRelease Notesへのリンク、説明分でリンクが有る場合は当該のガイド箇所へのリンクとなっています。また、公式のリリースノートは翻訳されていませんので、和訳は筆者による意訳です。
-
- [GA] コンシューマHTTP(S)コントロールを使用するPSCによるリージョンサービスエンドポイントへのアクセスに対応
- [Preview] コンシューマHTTP(S)コントロールを使用するPSCを使用したマネージドサービスへのアクセスに対応 → 10/4にGA
-
- [GA] PSC Endpoint 構成時の自動的なDNSの構成に対応（サービスプロデューサー側：DNSドメイン名の構成、サービスコンシューマー側：Service Directory DNSゾーンを用いたDNSエントリの構成）
-
- [Preview] サービスプロデューサー側のVPC内の内部リージョンTCP Proxyロードバランサを通じてホストされた公開サービスをサポート（バックエンドとして、Google Cloud、他のクラウド、オンプレミスおよびそれらの組み合わせに対応）→ 11/1にGA
-
- [GA] グローバルアクセスが有効化された内部TCP/UDPロードバランサもしくは内部プロトコル転送を利用したロードバランサによってホストされた公開サービスをサポート
-
- [GA] Cloud MonitoringによるPSC Producerのメトリックのモニタリング対象として、接続されたConsumer転送ルールと使用されたNAT IPアドレスのモニタリングに対応
-
- [GA] PSCによるサービスアタッチメントターゲットとして内部リージョンTCP Proxyロードバランサをサポート（VPC内のクライアントからPSCとHybrid NEGを用いたオンプレミスのサービスを利用したHybrid TCP/UDPサービスの作成が可能に）
-
- [Preview] コンシューマHTTP(S)コントロールを使用するPSC Endpointによるリージョン外部HTTP(S)ロードバランサおよびリージョン内部HTTP(S)ロードバランサを使用した、リージョンのGoogle APIおよびマネージドサービスへのアクセスをサポート
L4 PSCとL7 PSC
さて、ここからが今回のBlogの本題です。
前述した「初めてのPrivate Service Connect」シリーズの #1 〜 #3 はいずれも、L4 PSCとも呼ばれる、Consumer側では利用者がPSC Endpointに対して直接アクセスをしてPSCを利用するパターンのみにフォーカスした紹介でした。
L4 PSC
今回は、L7 PSC とも呼ばれる、Consumer側にPSC Endpointを配置するのではなくロードバランサのバックエンドサービスに Private Service Connect Network Endpoint Group (PSC NEG) として配置して利用するパターンについて紹介します。ガイドにおいてはConsumer側でHTTP(S)ロードバランサを利用するため、「コンシューマHTTP(S)コントロールを使用する」と表現されています。
L7 PSC
先にリストしたリリースノートにも合ったとおり、実は L7 PSC 自体は Release Notes において今年の1/24にグローバル外部HTTP(S)ロードバランサを通じた利用パターンがPreview対応していました（その後、10/4にGA）ので、前回PSCのBlogシリーズ#1〜#3を書いた時点でも登場していたのですが、あえて触れずにいた部分です。さらに、11/16にはPreviewとして、リージョン外部HTTP(S)ロードバランサおよびリージョン内部HTTP(S)ロードバランサへの対応もされ、さらに利用可能なパターンが広がりつつあります。
PSCを活用するパターンとしては、L7 PSC構成であることによって可能となるユースケースもあるため、今回はL7 PSCについて解説していきたいと思います。
L7 PSC のメリット・ユースケース
L4 PSC構成と比較して、L7 PSC構成のメリット、というかPSCをロードバランサの背後に置いて利用することで得られる価値は「Consumer側でロードバランサを介してPSCを利用することとなるため、セキュリティやルーティングをConsumer側で制御できる」という点です。
もう少し具体的なユースケースを4つ挙げてみましょう。
マネージドサービスへの段階的な移行
こちらのパターンは、ロードバランサの背後にPSCを経由してパートナーのマネージドサービスへの接続を構成することで、利用者からは同じ接続先を通じて段階的に自己管理のサービスからマネージドサービスへの移行を進める例です。サービスを利用する側に対しては、ロードバランサに設定した同じIPアドレスを通じて移行元・移行先のサービスを同時に提供することができるため、移行プロセスを簡素化できます。
マネージドサービスへの段階的な移行
Consumer側で管理するドメイン名を通じたアクセス
こちらのパターンは、利用者側でサービスのURLを自由に設定して利用する例です。サービスを利用する側にIPアドレスを意識させないDNSベースでの提供を行いたい場合、PSC Endpointを直接参照する構成でもドメイン名の紐付けは可能ですが、ロードバランサを介して利用することでドメイン名とPSC Endpointの紐付けを間接的として将来の変更や拡張により柔軟に対応が可能となります。
Consumer側で管理するドメイン名を通じたアクセス
リージョンAPIへのアクセス
こちらのパターンは、リージョン毎に提供されているリージョンAPIへのアクセスをロードバランサによって取りまとめる例です。ロードバランサによって（基本的には）最寄りのリージョンに通信が振り分けられるため、利用者のアクセス元によってアクセス先となるリージョンAPIを振り分けつつも、利用者にとってもサービスの接続先が1つにまとめられるため接続の管理が楽になります。
リージョンAPIへのアクセス
L7 PSC構成で利用可能なGoogle Cloud Region APIについては、以下のガイドページを参照してください。
LBと組み合わせて利用可能なIAPやCloud Armorの活用
最後にこちらのパターンは、Cloud Load Balancingを利用することで利用可能となる各種サービスを、PSC Endpointを通じたサービスへのアクセスに対して利用する例です。セキュリティや可視化などを目的としてCloud ArmorやIdentity-aware Proxy (IAP)などを利用することができるようになるため、特にユーザ側でPSC Endpointを通じて接続したサービスを外部に公開して利用したい場合には、この構成によってより適切な制御が可能となります。
LBと組み合わせて利用可能なIAPやCloud Armorの活用
なお、L7 PSCでも、Producer Serviceとしては、Google API (以前のBlogにおいて、PSC for Google APIs としていたパターン) と 自身もしくはパートナーが提供する Managed Service (以前のBlogにおいて、PSC for ILB としていたパターン) の両方のパターンに対応しています。ただし、L4 PSC との組み合わせで利用できる Google API が Global Google API であったのに対して、L7 PSC との組み合わせで利用できる Google API は、リージョンサービスエンドポイント（Regonal Google API）となります。
L7 PSC の構成手順と考慮点
L7 PSCの基本的な構成手順は以下の通りです。
- 接続するAPIまたはサービスの特定（リージョンサービスエンドポイントもしくはサービスアタッチメントURI）
- ロードバランサのデプロイ
- PSC NEGの構成と、ロードバランサのバックエンドサービスとしての登録
L7 PSC構成でConsumer側で使用可能なロードバランサとサポートするAPI / サービスの組み合わせは以下の通りです。なお、リージョン内部HTTP(S)ロードバランサおよびリージョン外部HTTP(S)ロードバランサを利用したL7 PSC構成は、2022/12時点ではPreview段階となっております。
- グローバル外部 HTTP(S) ロードバランサ + Service Producer 側 内部TCP/UDPロードバランサ
- リージョン内部 HTTP(S) ロードバランサ + Reginal Google API もしくは Service Producer 側 内部TCP/UDPロードバランサ
- リージョン外部 HTTP(S) ロードバランサ+ Reginal Google API もしくは Service Producer 側 内部TCP/UDPロードバランサ
PSG NEG 利用の場合の要件は以下の通りです。
- PSC NEG を他のNEGタイプと混在させることはできない
- PSC NEG を使用するバックエンドサービスはHTTPSの利用が必須（HTTPでは不可）
- PSC NEG を使用するバックエンドサービスではヘルスチェックは未サポート
- PSC NEG はサポートされるロードバランサとの組み合わせでのみ利用可能
Service Producer側のHTTPSサービスには、Cloud Run でも使って…と思いましたが、L7 PSCでService Producer側で利用可能なロードバランサはTCP/UDPロードバランサのみなので、残念ながらServerless NEGは利用できません。まぁそもそもCloud Runを使うならL7 PSCみたいな構成は不要なわけで、素直に普通にL4 PSCで構成すればいいわけです。PSC Endpointを用いてCloud Runで構成したサービスに対してオンプレミス等からの接続を構成する手順については、以下のBlogを参考ください。
そんなわけで、今回はService Producer側のVPCでGCEインスタンスを使ってHTTPSなWebサーバを立ち上げて、それをTCP/UDPロードバランサの背後に置いた構成を用意して利用する構成としたいと思います。
L7 PSC 構成パターン
本例では、同一組織内にService Producer側となるプロジェクトとして advent-producer を、Consumer側となるプロジェクトとして advent-consumer を構成しています。もちろん、実際の利用においてはService Producer VPCとConsumer VPCは別組織での構成も可能ですし、同一プロジェクト内での構成も可能です。
また、Service Producer側のVPCは producer-vpc 、Consumer側のVPCは consumer-vpc です。
Service Producer 側の構成
本題ではないので、必要なAPIの有効化やVPC、Firewall、GCEインスタンス、インスタンスグループ、TCP/UDPロードバランサの構成などの解説は端折らせて頂きます。また、今回は本題となるL7 PSC部分以外は徹底的に手抜きをしているため、HTTPSなWebサーバは1台だけ構成し、自己証明書をつかったnginxでWebサーバを立ち上げており、同様にロードバランサにも自己証明書を設定しているため、ブラウザからのアクセス時に警告がでる状態となっています。良い子は真似してはいけません。
Service Producer 側のVPC内で、GCEで構成したWebサーバにHTTPSでアクセスするとこんな感じです。本例のWebサーバのIPアドレスは 192.168.1.3 です。
Service Producer VPC内でのWebサーバへの直接アクセス例
用意したWebサーバを非マネージドインスタンスグループとして構成し、TCP/UDPロードバランサのバックエンドサービスとして設定してHTTPSでアクセスするとこんな感じです。本例のTCP/UDPロードバランサのVIPアドレスは 192.168.1.11 です。
Service Producer VPC内でのTCP/UDPロードバランサ経由でのWebサーバへのアクセス例
ここまで準備ができれば、あとはこのTCP/UDPロードバランサを対象としてService Producer側でサービスアタッチメントを作成します。サービスアタッチメント作成の詳細手順については以下のガイドを合わせて参照してください。
まず、PSC用のSubnetを作成します。Subnetサイズについては、ガイドを参照して容量設計を行ってください。ただし、構成後のサブネット範囲の追加や拡大も可能です。また、グローバル外部HTTP(S)ロードバランサを用いるPSC EndpointによってConsumeされる場合にはSubnetは利用されませんが、作成が必要です（その場合は、/29の最小サイズでの構成を推奨します）。本例では、PSC用Subnetとして 192.168.0.0/24 を作成しました。
PSC用Subnetの構成
必要に応じて、Firewall Ruleを構成してください。L7 PSCを利用する場合には、ロードバランサのヘルスチェックに利用されるのと同じ 35.191.0.0/16 と 130.211.0.0/22 範囲からの通信を許可する必要性があります。本例では、ファイアウォールポリシーを使ってターゲットもポートもを絞らずに設定してしまっていますが、これは悪い例です。キチンとセキュリティタグ（Resource Manager タグ）を用いてターゲット範囲は絞り込み、必要なポートだけを許可する様に設定しましょう。
Service Producer側VPCへのファイアーウォールポリシー構成例（ちょっと悪い例）
続いて、サービスアタッチメントを作成します。これはService Producerがサービスを公開するためのURIとして利用され、Consumer側での指定が必要となります。URIの形式は projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME となります。
Private Service Connect - 公開サービス 構成画面
サービスアタッチメントは、プロジェクトを自動承認してサービスを公開する方法と、明示的なプロジェクト承認を使用してサービスを公開する方法の2種類で構成が可能です。以下ではGUIを用いて「明示的なプロジェクト承認を使用してサービスを公開する方法」で構成した例となります。
PSC公開サービス構成例
「プロジェクトを自動承認してサービスを公開する方法」や、gcloud / API を用いて構成を行う手順などについては以下のガイドURLを参照してください。
今回の構成例の場合、サービスアタッチメントのURIは projects/advent-producer/regions/asia-northeast1/serviceAttachments/tokyo-web-l4-lb-psc-producer-service となりました。
PSC公開サービス構成結果例
以上で、下図のようなService Producer側の構成が出来上がりました。
L7 PSC構成のためのService Producer側構成例
Consumer 側の構成
続いて、Consumer側の構成です。
L4 PSCの場合には、ここでまずはPSC Endpointを作成することとなりますが、PSC NEGとして使用する場合にはPSC Endpoint に対するIPアドレスの設定や名前空間との紐付けは不要であるため、ロードバランサの構成手順の中でPSC NEGとして構成を行います。
今回はせっかくですので、L7 VPC構成で可能な全てのロードバランサを利用した構成を試してみたいと思います。
リージョン内部HTTP(S)ロードバランサを用いた構成
まずは、リージョン内部HTTP(S)ロードバランサを利用した構成からやってみたいと思います。なお、こちらの構成は2022/12時点ではまだPreviewです。
リージョン内部HTTP(S)ロードバランサの作成は、作成画面で [HTTP(S)ロードバランシング]→ インターネット接続または内部専用で[VMまたはサーバーレスサービス間のみ]を選択することで作成できます。
なお、Envoyを利用するリージョンHTTP(S)ロードバランサを利用する際には、プロキシ専用Subnetの構成がリージョン毎に必要となります。本例では、172.16.0.0/24を割り当てています。
リージョンHTTP(S)ロードバランサで利用するプロキシ専用Subnetの構成例
リージョン内部HTTP(S)ロードバランサの構成例
L7 PSC構成の場合には、バックエンドサービスのバックエンドタイプとして[Private Service Connect ネットワークエンドポイントグループ] を指定し、PSC NEG指定欄で[Private Service Connect ネットワークエンドポイントグループを作成]を選択します。
バックエンドサービスとしてPSC NEGを構成する
PSC NEGのパラメータは、[名前]と[ターゲット]、PSC NEGのために利用する[サブネットワーク]の3項目です。ターゲットとして公開サービス（Published service）を選択した場合には、Service Producer側から伝えられたURIをターゲットサービス欄に入力します。
PSC NEGとして公開サービスを利用する場合には公開サービスのURIを指定する
蛇足：自己署名証明書（オレオレ証明書）を使うと…
蛇足ですが、証明書と秘密鍵に自己署名証明書（いわゆるオレオレ証明書）を設定しようとすると、警告メッセージが表示されます。テスト目的以外でオレオレしてはいけません。
自己署名証明書を利用した場合の例（悪い例）
本例ではロードバランサのIPアドレスとして 172.16.1.11 を指定しています。
リージョン内部HTTP(S)ロードバランサによるPSC NEG構成例
以上で、下図のような構成が出来上がりました。
リージョン内部HTTP(S)ロードバランサによるPSC NEG構成例の概要図
ロードバランサに設定したIPアドレスにブラウザでアクセスし、PSCを通じてService Producer側のWebサーバが表示されることを確認します（オレオレ証明書利用のせいで警告が出ているところはそっとしておいてください…）。
Consumer VPC側からPSC NEGをバックエンドに持つリージョン内部HTTP(S)ロードバランサ経由でのService Producer側公開サービスのWebサーバへのアクセス例
リージョン外部HTTP(S)ロードバランサを用いた構成
続いて、リージョン外部HTTP(S)ロードバランサを利用した構成です。なお、こちらの構成も2022/12時点ではまだPreviewです。
リージョン内部HTTP(S)ロードバランサの作成は、作成画面で [HTTP(S)ロードバランシング]→ インターネット接続または内部専用で[インターネットからVMまたはサーバーレスサービスへ]を選択し、グローバル / リージョンで[リージョンHTTP(S)ロードバランサ]を選択することで作成できます。
なお、Envoyを利用するリージョンHTTP(S)ロードバランサを利用する際には、プロキシ専用Subnetの構成がリージョン毎に必要となります。
リージョン外部HTTP(S)ロードバランサを用いたPSC NEGバックエンドの構成は、外部IPアドレスを使用する以外は基本的には全てリージョン内部HTTP(S)ロードバランサの構成手順と同様ですので、スクリーンショットを含めた手順の紹介は割愛します。
以下が本例の場合の構成です。構成の結果、本例ではロードバランサ用のIPアドレスとして 35.213.47.142 が設定されました。
リージョン外部HTTP(S)ロードバランサによるPSC NEG構成例
以上で、下図のような構成が出来上がりました。
リージョン外部HTTP(S)ロードバランサによるPSC NEG構成例の概要図
ロードバランサに設定したIPアドレスにブラウザでアクセスし、PSCを通じてService Producer側のWebサーバが表示されることを確認します（オレオレ証明書利用のせいで警告が出ているところはそっとしておいてください…アゲイン）。
外部からConsumer VPC側に構成したPSC NEGをバックエンドに持つリージョン外部HTTP(S)ロードバランサ経由でのService Producer側公開サービスのWebサーバへのアクセス例
グローバル外部HTTP(S)ロードバランサを用いた構成
最後に、グローバル外部HTTP(S)ロードバランサを利用した構成です。なお、こちらの構成は既にGAしており、本番用途にご利用いただけます。
グローバル内部HTTP(S)ロードバランサの作成は、作成画面で [HTTP(S)ロードバランシング]→ インターネット接続または内部専用で[インターネットからVMまたはサーバーレスサービスへ]を選択し、グローバル / リージョンで[グローバルHTTP(S)ロードバランサ]を選択することで作成できます。
グローバル外部HTTP(S)ロードバランサを用いたPSC NEGバックエンドの構成は、多少リージョン内部HTTP(S)ロードバランサおよびリージョン外部HTTP(S)ロードバランサの構成手順とは画面が異なりますが、おおよそ同じ項目を設定することになりますので、スクリーンショットを含めた手順の紹介は割愛します。なお、グローバル外部HTTP(S)ロードバランサを使用する場合のみ、PSC NEGをバックエンドサービスとして構成する際にHTTPSが必須となっています（設定欄がグレーアウトして変更できなくなっています）。
以下が本例の場合の構成です。構成の結果、本例ではロードバランサ用のIPアドレスとして 34.149.14.216 が設定されました。
グローバル外部HTTP(S)ロードバランサによるPSC NEG構成例
以上で、下図のような構成が出来上がりました。
グローバル外部HTTP(S)ロードバランサによるPSC NEG構成例の概要図
ロードバランサに設定したIPアドレスにブラウザでアクセスし、PSCを通じてService Producer側のWebサーバが表示されることを確認します（オレオレ証明書利用のせいで警告が出ているところはそっとしておいてください…アゲインアゲイン）。
外部からConsumer VPC側に構成したPSC NEGをバックエンドに持つグローバル外部HTTP(S)ロードバランサ経由でのService Producer側公開サービスのWebサーバへのアクセス例
まとめ
今回はConsumer側でCloud Load Balancingを通じてPSCをNEGとして利用するL7 PSC構成について紹介しました。冒頭で2022年のリリースノートの振り返りから見ても、PSCは非常に注力されて開発が進められており、PSCを通じた利用をサポートするパートナーも増えつつあります。今回試してみたように、PSCは自らService Producerとなることも可能ですが、最もよくあるユースケースはGoogle CloudのAPIや、サードパーティが提供するマネージドサービスをプライベートかつセキュアに利用するために利用するパターンです。Consumer側だけの構成であれば、非常にわずかなステップだけでサービスが利用できるようになることがおわかり頂けたかと思います。
是非皆様の環境においてもPSCを活用頂き、2023年は「初めての」ではなく「さらに使いこなす」シリーズとしてPSCの最新情報の紹介を続けられたらいいなと思います。
引き続き、Google Cloud Japan Advent Calendar をお楽しみください！
Discussion