初めての Private Service Connect #3 PSC for ILB 編 + まとめ
これは3回シリーズで Private Service Connect について解説する Blog の第3回（最終回）となります。第1回と第2回をまだお読みでない方は是非そちらから御覧ください。
第1回では、Private Service Connect (PSC) の概要やメリットについて、第2回では、PSC for Google APIs を用いて Google API を通じて提供される各種サービス（Cloud Storage や Cloud Run など）をプライベート接続で利用する方法についてまとめました。最終の第3回となる今回は、Private Service Connect のもう一つの利用パターンである “Private Service Connect for Internal Load Balancer”（以下、PSC for ILB）について解説していきます。
PSC for Google APIs の場合、Producer 側は Google API となるため PSC の利用者側となる Consumer 側のみが構成範囲でしたが、PSC for ILB の場合は Consumer 側に加えて、サービスを提供する Producer 側も構成の範囲となります。Consumer 側と Producer 側は同じ組織の中で構成することもできますし、それぞれ別の組織で構成することもできます。
内部ロードバランサを通じて提供されるサービスへの PSC を用いた接続
PSC for ILB の Consumer 側における必要要件の詳細についてはこちらを参照してください。
PSC for Google APIs の場合と同様に PSC for ILB 構成においても 2022 年 2 月時点では IPv4 のみがサポートされています。また、PSC Endpoint に対する通信は、VPC の範囲を超えて利用することができない点も同様です。つまり、VPC ピアリング構成を併用している場合、異なる VPC 範囲からは PSC Endpoint に対して直接アクセスすることはできません（Proxyを経由させるなどのワークアラウンドは可能）。
PSC Endpoint に割り当てる IP アドレスについては、PSC for Google APIs の場合には VPC 内に構成されている Subnet の範囲外とする必要がありましたが、PSC for ILB の場合は逆に VPC 内に構成されれている Subnet の範囲内から割り当てる必要がある点に注意してください（今回の構成例では、Subnet 192.168.0.0/24 の範囲内から 192.168.0.123 を選択）。
また、PSC for ILB が PSC for Google APIs と最も異なる点は、Consumer 側における PSC Endpoint に対する接続が同一リージョンからの接続に限定される点です（つまり、Producer 側の内部ロードバランサと同じリージョンに、Consumer 側の Endpoint が構成される必要があります）。そして、オンプレミス環境からの接続については 2022 年 2 月現在、Cloud VPN 経由の場合のみがサポートされています。Cloud Interconnect を通じて接続されたオンプレミス環境からの接続が必要な場合には、NAT / Proxy VM を利用するなどの何らかのワークアラウンド対応が必要です。なお、これらの仕様は将来において変更される可能性があります。PSC 利用に際しては最新の状況を必ず確認してください。
以下の図が今回の構成例となる PSC for ILB 構成の概略図となります。
今回の例では、Consumer 側の VPC に内部 IP アドレス 192.168.0.2 を持つインスタンスが存在し、同一 VPC 範囲に構成された PSC Endpoint 192.168.0.123 宛にリクエストを行います。実際には PSC Endpoint は届いた通信をその背後で「宛先 IP アドレスを Producer VPC 側にある内部ロードバランサ宛に DNAT する」とともに「送信元 IP アドレスを Service Attachment に紐付けた NAT Subnet 範囲から取得した IP アドレスに SNAT する」ことにより、Producer VPC 側の内部ロードバランサのバックエンドサービスとして構成されたサーバでリクエストは処理されレスポンスが Service Attachment に返されます（この際に、Producer VPC に存在する内部ロードバランサからは Consumer VPC 側に存在する元々のリクエスト発行元のインスタンスはもちろん、PSC Endpoint の存在についても一切意識していない点が重要です）。Service Attachment に届いたレスポンスは再度「PSC Endpoint の IPアドレスに SNAT される」とともに「宛先 IP アドレスはリクエストを発行した元のインスタンスのIPアドレスに DNAT される」ことで、リクエストを発行したインスタンス側からも全く Producer VPC の存在を意識することのない、PSC Endpoint 自身が応答したように認識される状態となってレスポンスが返されます。
このように、Consumer 側においては Endpoint がサービスの接続先に、Producer 側では Service Attachment がサービスの接続元になることで、実際にサービスをリクエストしているインスタンスと、サービスを提供している内部ロードバランサのそれぞれが異なる VPC に属していてネットワークとしての接続性を構成しなくてもよい「サービスとしてのつながり」を構成し、SNAT / DNAT を用いた変換と関係性の紐付け管理をシンプルなパラメータ要素だけで構成維持してくれるという点が、PSC for ILB の本質といえます。
今回の例では内部 TCP/UDP ロードバランサを用いていますが、PSC for ILB に対してサービスを公開する場合の内部ロードバランサとしては、内部 TCP/UDP ロードバランサと内部 HTTP(S) ロードバランサのどちらも使用することができます。
つづいて、Producer 側の設定、Consumer 側の設定の順に説明します。
Producer 側の設定
PSC for ILB の Producer 側の構成手順は以下のとおりです。
- 内部ロードバランサを利用するサービスを構成します
- 内部ロードバランサと同じリージョンに Service Attachment のために使用する NAT Subnet を作成します
- 内部ロードバランサと同じリージョンに Service Attachment を作成します
なお、1つの内部ロードバランサは、1つの Service Attachment のみと紐付けることが可能です。
PSC 用としての内部ロードバランサの利用に際してはいくつかの制限事項が存在します。特に、Packet Mirroirng が利用できない点やグローバルアクセスは利用できない点、同じ IP アドレスを使用する複数の転送ルールは作成できない点などに注意してください。また、内部ロードバランサとして内部 HTTP(S) ロードバランサを用いる場合には、Consumer 側の送信元 IP アドレスの紐付けを確認するための PROXY プロトコルを用いることはできません。
今回は、内部ロードバランサを使用するサービス自体については構成済みとして手順を解説します。
PSC 用 NAT Subnet の作成
Service Attachment に紐付ける PSC 用の NAT Subnet を VPC に紐付けて作成します。この NAT Subnet 範囲の IP アドレスは、Consumer 側の送信元 IP アドレスを SNAT して変換するために利用されます。この NAT Subnet 範囲の IP アドレスは、Service Attachment 以外の用途に利用できません。63 の Consumer VM に対して少なくとも 1 つの NAT Subnet 範囲の IP アドレスが利用されます。NAT Subnet は、想定される Consumer VM 数に基づいて十分なサイズを確保してください。ただし、後から Service Attachment に対して追加の NAT Subnet を紐付けることが可能です。
PSC用 NAT Subnet は、Cloud Console、gcloud、API により作成できます。
Service Attachment の作成
PSC for ILB では、Producer 側に Service Attachment を作成することでサービスを提供します。PSC for ILB に紐付ける内部ロードバランサ、サービス名と PSC for ILB で使用する NAT Subnet、そして [接続の設定] を選択します。
なお、Consumer 側では PSC Endpoint を構成する際に Service Attachment を指定することでサービスに接続しますが、Service Attachment の指定に利用される URI は規則性があるため、Producer 側の Project ID や構成したリージョン名、Service Attachment のサービス名などがわかってしまえば誰もが接続できてしまうことになります。そこで、Producer 側は公開するサービスに紐付ける Service Attachment を作成する際に、PSC Endpoint からの接続を、自動承認する構成（[接続の設定]において、”すべてのプロジェクトの接続を自動的に受け入れる”を選択する）と、手動承認する構成（[接続の設定]において、”選択したプロジェクトの接続を受け入れる”を選択する）のいずれかで構成できます。手動承認とした場合には、Service Attachment と PSC Endpoint との間の接続は、PSC Endpoint 側での Service Attachment の URI を用いた指定と、Service Attachment 側での承認の両方が揃って初めて接続が可能となります。この承認構成は後から変更することも可能です。なお、VPC-SC を利用している場合には追加の構成が必要です（今回は VPC-SC 未使用の場合の構成例となります）。
Service Attachment を作成すると、Private Service Connect の管理画面の[公開サービス]タブに、作成済みの Service Attachment が表示されます。
Producer は Consumer に対して、Service Attachment の URI （下図、[サービスの接続]にあるURI）を伝える必要があります。このURIは、以下の形式になります。
projects/SERVICE_PROJECT/regions/REGION/serviceattachments/SERVICE_NAME
今回の構成例では以下の構成で Service Attachment を作成したため、以下のURIとなります。
- Service Attachment を構成した Project ID : psc-demo-334606
- Service Attachment を配置した Region : asia-northeast1 (東京)
- Service Attachment 名 : pscweb
- Service Attachment URI : projects/psc-demo-334606/regions/asia-northeast1/serviceAttachments/pscweb
Consumer 側の設定
続いて、Consumer 側で Service Attachment を通じて提供されるサービスに紐付ける PSC Endpoint を構成します。
PSC Endpoint の構成は、Cloud Console や gcloud コマンドなどでおこなうことができます（構成を行うアカウントに必要なロールについてはこちらを参照してください）。以下では、公開サービスに紐付ける PSC Endpoint 用の IP アドレスとして、192.168.0.123 を指定した場合の例となります（psc-lb-web-endpoint-ip として 192.168.0.123 を予約しています）。
公開サービスに紐付けて PSC Endpoint を作成する場合には、対象として [公開済のサービス] を選択し、ターゲットサービス欄に接続する Service Attachment のURIを指定します（指定する URI については、Producer側から事前に情報を取得してください）。PSC Endpoint 作成時に Service Directory の名前空間を指定しなかった場合には、既定の名前空間 goog-psc-default が自動的に作成されます。
基本的には以上で Consumer 側の構成は完了ですが、Service Attachment 側の接続認証の構成次第で作成後のステータスが異なります。
接続時の承認構成に基づく動作の違い
PSC Endpoint が接続した Service Attachment が自動承認構成の場合には、PSC Endpoint のステータスは構成後すぐに [承認済み] となります。この場合、Consumer 側では作成した PSC Endpoint を通じてサービスへの接続が既に可能となっています。
PSC Endpoint が接続した Service Attachment が手動承認構成の場合には、PSC Endpoint のステータスは構成時には [保留] となります。この場合は、Producer 側で承認されるまでサービスへの接続はできません。
Producer 側の Service Attachment でも、PSC Endpoint の接続が構成されたが保留ステータスとなっていることを確認できます。
Producer 側の Service Attachment では、PSC Endpoint からの接続要求に対して相手の Project ID に基づいて判断を行い、 [承諾] もしくは [拒否] を行います。
承認する場合には、合わせて Consumer に対する Project レベルでの接続上限数を指定します。承認は取り消しが可能です。また、接続上限数は後から変更が可能です。
接続確認
必要に応じて DNS の構成を行います。
Consumer 側で PSC Endpoint を通じて Producer 側の公開サービスへのアクセスを確認します。
~ $ curl http://192.168.0.123
psc-producer-mig-9klg
~ $ curl http://192.168.0.123
psc-producer-mig-2n8d
~ $今回の構成例の環境では、問題なく内部ロードバランサに紐付けたインスタンスグループのメンバーに対してProducer 側のロードバランサを経由して Consumer 側のVMからアクセスできていることが確認できました。
全体まとめ : PSC 利用のメリットと考慮点
PSC を利用することの最大のメリットは、本シリーズの第1回でも書いたとおりサービスの利用側とサービスの提供側がそれぞれ異なる VPC に接続されている状況下において、ネットワークとして相互接続する場合の制約（IPアドレスの重複ができないことや、ルーティングの調整などが必要となること、何よりも両者の間で様々な調整や確認が必要となること）に制限されずに「サービスレベルでの接続性」を実現できる点です。しかも、通信経路は End-to-End でプライベートな接続（Googleのバックボーンネットワークのみを経由する暗号化された通信）となり、外部ネットワークは一切経由しません。これによって、高いセキュリティはもちろん、広帯域で低遅延な接続が可能です。特に、1つの Producer が提供するサービスに対して複数の Consumer が接続するようなケースにおいては、Producer と各 Consumer 間でのネットワークとしての調整などが不要である点はとても重要です。
PSC の利用に際しての考慮点としては、 PSC の利用に対して時間あたりの課金が発生する点と、PSC for ILB の場合にはそれに加えて GB あたりの転送料金が Consumer と Producer 側の双方に発生する点です。また、よくも悪くも PSC はサービス単位での接続を提供する仕組みであり、多数のサービスを VPC 間で提供・利用するような場合によっては逆に構成が複雑化してしまう可能性があります。また、2022 年 1月時点では PSC は VPC ピアリングと組み合わせての利用ができない点と、IPv6 にはまだ未対応である点にも注意が必要です。
PSC for Google APIs パターンで PSC を利用するメリットとなる点は、プライベートな接続のみに制限している VPC 内からも Google API を通じて提供される各種サービスを利用できるようになる点や、Google API に対する接続を許可する対象をファイアウォールルールによって制限しやすくなる点などです。
PSC for Google APIs パターンでの考慮点としては、PSC を利用しない場合には考慮が不要であった API に対する接続DNS名について、場合によってはクライアント側での対応を求める点です。しかし、標準の DNS 名（たとえば、Cloud Storage の API エントリーポイントとなる storage.googleapis.com ）に対して解決される IP アドレスを PSC Endpoint に割り当てたものに変更することも可能ですので、適切に対処すれば問題となることはないでしょう。
PSC for ILB パターンで PSC を利用するメリットとなる点は、Consumer と Producer の間で VPC ピアリングの構成は不要であり、VPC ピアリングにまつわるスケーラビリティや構成に制限が発生しないことに加え、Consumer と Producer で使用する IP アドレス範囲について調整する必要がないということです。つまり、Consumer 側は自分自身でサービスへの接続に使用する IP アドレスを自身の VPC 内に自由に設定することができますし、Producer 側も Consumer 側 VPC で使用されている IP アドレス範囲を意識することなく VPC を管理することができます。1つの Producer に対して複数の Consumer が接続する構成も可能ですし、その場合においてもProducer と Consumer 間および複数の Consumer 間での IP アドレスの調整は不要です。いずれに場合においても、Consumer 側と Producer 側で IPアドレスが重複していたとしても問題ありません。
PSC for ILB パターンでの考慮点としては、Service Attachment と PSC Endpoint が同一リージョンである必要性がある点と、Cloud Interconnect を経由したオンプレミスからの接続構成に制限がある点です。
最後に、PSC は 2020 年末に Preview 提供が開始され、2021 年をかけて順次 GA されてきた新しいサービスです。今後も様々な機能追加や改善が予定されています。今回 考慮点として記載した事項についても、将来においては改善されていくことをご期待頂ければと思います。PSC はいくつかの制約はあれど、従来のネットワーク間接続では簡単には構成できなかった組織間やVPC間を超えたプライベート接続を簡易に実現できるようにしてくれるサービスです。ぜひリリースノートで最新の状況を確認してみてください！！
本シリーズを書き上げるに際しては、同僚の Seiji Ariga さんに多くのとても有益なコメントと指摘を頂きました。ここに感謝の意を表します。ありがとうございました。
