初めての Private Service Connect #1 PSCってなに？ 編
そもそもに立ち返ると、ネットワークを利用する目的はサービスの利用者とサービスの提供者を結びつけることです。サービスの利用者が不特定多数の場合には、現在では一般的に Internet などを経由してサービスの提供者と利用者とが接続されます。しかし、限定的な利用者のみに対してプライベートにサービスを提供したい・利用したい場合、しかも、異なる管理者による管理下にある異なるネットワークにサービスの利用者とサービスの提供者が分かれて存在する場合には、これまではネットワークの管理者間で様々な調整や、場合によっては事前に必要な対応を行った上で両者のネットワークを接続することが必要でした。
今回から全3回に分けてご紹介する Private Service Connect (PSC) は、このような『限定的な利用者のみに対してプライベートにサービスを提供したい・利用したい』場合において大きなメリットを提供するサービスです。組織間でのプライベートなサービスの提供や利用といった使い方が社内向けの業務システムなどにおいても広がるにつれて、こうしたニーズはより高まっていくと思われます。
第1回となる今回は、従来のネットワークをまたいだプライベートなサービスの提供と利用における課題と、その課題を解決するために PSC が採用した仕組みについて解説します。
PSC は何を解決するのか
Google Cloud において、プライベートネットワークを構成する仕組みである Virtual Private Cloud (VPC) はグローバルリソースなので、ゾーンはもちろん、リージョンを超えて利用できます。そのため、単純に1つの組織として1つのネットワークを利用する分には、マルチリージョン構成であったとしても VPC を1つ作成するだけで完了し、リージョン毎に VPC を作って VPC ピアリングで接続したりする必要はありません。たとえば、東京リージョン (asia-northeast1) と大阪リージョン (asia-northeast2) の両方で Compute Engine のインスタンスを構成し相互にプライベートIPアドレスで通信をさせたい場合、1つの VPC の中に、東京リージョン側の Subnet と、大阪リージョン側の Subnet を構成すれば、それだけでインスタンス間の通信は可能となります（正確には、必要に応じてファイアウォールルールの構成が必要となる場合もあります）。
ところが、現実には様々な理由で「異なる VPC に構築されたサービスを利用したい」ケースが発生します。たとえば、利用したいサービスが別組織が管理する VPC に接続されている場合や、何らかの歴史的経緯や要件などによって 異なる VPC に接続されている場合などです。
もちろん、いずれの場合であっても VPC 外を経由して接続する、つまりは パブリックな IP アドレスを用いてサービスの利用者と提供者を結びつけることが可能です。しかし、コンプライアンスやセキュリティなどの管理面の理由や、接続帯域などの性能面の理由によって外部ネットワークを経由させたくないという場合もあるでしょう。
このようなケースに対応するために、Google Cloud では従来から VPC 間を相互接続する VPC ピアリングの仕組みが用意されています。これを用いれば、異なる VPC 間でネットワークを接続することで、サービスの利用者はサービスの提供者にプライベート IP アドレスのままでアクセスできるようになります。しかし VPC ピアリングを構成する場合には、当然ながらそれぞれの VPC で使用されている IP アドレス範囲に重複があってはいけません。さらにはネットワークとして接続しますので、2つの VPC 間で適切なセキュリティとアクセス制御を構成する必要があります。
しかも、サービスの提供側 VPC とサービスの利用側 VPC の両方が同一の組織によって管理されている場合であれば VPC ピアリングによるVPC 間の接続やそれに伴う構成の変更等は問題ないかもしれませんが、異なる組織が管理する VPC 間での VPC ピアリング接続の利用は、技術要件のみならず様々な非技術要件（コンプライアンスや、責任の境界区分など）も相まって非常に敷居が高くなってしまいます。特に1つのサービス提供者に対して複数のサービス利用者が存在する場合などでは、VPC ピアリングの利用は非現実的でしょう。
このような課題を解決するために提供される仕組みが、この Private Service Connect (PSC) です。PSC は、サービスの利用者とサービスの提供者の間を VPC ピアリングのような直接的なネットワーク接続を構成することなくプライベートに接続するネットワークサービスです。2022 年 1 月現在、PSC は以下の 2 つの用途でご利用いただくことができます。
- Google API に対してプライベート接続する（以下、PSC for Google APIs）
- Producer が内部ロードバランサを通じて提供するサービスへプライベート接続する（以下、PSC for ILB）
PSC において、サービスの提供者を Producer、サービスの利用者を Consumer と呼称しますが、上記 1. の PSC for Google APIs パターンは、Producer が Google 自身の API である場合、2. の PSC for ILB パターンは Producer がサービス提供者側の VPC 内に構成されたサービスである場合に利用します。これらは、同時に利用いただくことが可能です。
PSC を実現する仕組み
PSC では、Consumer 側にはサービスへの接続点として PSC Endpoint を構成します。PSC Endpoint は、Consumer 側からみるとサービスが提供される自身の VPC 範囲内にあるプライベート IP アドレスそのものになります。つまり、Consumer VPC 内の Compute Engine インスタンス等から PSC Endpoint として構成した IP アドレス宛に通信をすることで Producer が提供するサービスへ接続できるようになります。
PSC Endpoint を通じて利用するサービスが Google API である場合（= PSC for Google APIs）には、Producer 側の構成は特にありません。
PSC for Google APIs の別パターンとして、内部HTTP(S)ロードバランサを用いた Google API への接続構成が 提供されています。ただし、この場合に接続対象として構成可能な Google API は Region Service Endpoint として利用可能なリージョンに紐づく Google API (Cloud KMS, Cloud Logging, Pub/Sub, Cloud Run, Cloud Spanner) に限られます。今回はこちらについては解説の対象外となります。
Producer が提供する公開サービスである場合（= PSC for ILB）には、Producer 側でも PSC を通じてサービスを公開するための構成が必要です。公開サービスを提供する Producer 側では、PSC Endpoint からの接続先となる Service Attachment を構成します。Consumer 側で PSC Endpoint 宛に発生した通信は、この Service Attachment を通じて Producer 側 VPC 内で内部ロードバランサ宛にパケットが送受信されます。
上記のように、Consumer 側では Consumer VPC 内でサービスを利用したいインスタンス等と PSC Endpoint との間で通信をすることで、Producer 側では Producer VPC 内の Service Attachment から内部ロードバランサに通信が行われることでそれぞれサービスの利用と提供が可能となります。Consumer VPC と Producer VPC との間での ピアリングの構成や、ネットワークとしてのルーティングの構成などは必要ありません。
Consumer 側の PSC Endpoint は、単一のホストIPアドレスです（2022年1月現在、PSC Endpoint の IPアドレスとして IPv6 を利用する構成はサポートされていません）。対して、Producer 側の Service Attachment には、Subnet を紐付けます（この Subnet を NAT Subnet と呼びます）。NAT Subnet 範囲の IP アドレスは、インスタンスへの割り当てなどの他用途に用いることはできません。PSC では、Consumer 側の PSC Endpoint を通じたサービスへの通信を、この Service Attachment に紐付けた NAT Subnet 範囲の IP アドレスに対して自動的に SNAT （送信元 NAT）することで通信を実現しています。また、内部ロードバランサからの戻り通信に対しては DNAT （宛先 NAT）を適用することで Consumer 側では PSC Endpoint の先にある Producer 側の VPC の存在自体を隠匿し、Consumer 側から見れば単に PSC Endpoint のIPアドレス自身がサービスを提供している様にみせています。
上図の例では、Client は Endpoint 宛に通信を行いサービスをリクエストしています。
PSC は Endpoint 宛に届いたリクエスト通信を NAT 変換し、送信元 IP アドレスは Client の内部 IP アドレスを NAT Subnet 範囲内から自動選択した IP アドレスに SNAT し、宛先 IP アドレスは Endpoint の IP アドレスを Service Attachment に紐付けられている内部ロードバランサの IP アドレスに DNAT します。これにより、内部ロードバランサは単純に VPC 内の IP アドレスから届いたリクエストとして通信を処理するため、利用者側 VPC の存在を意識しません。
そして PSC は内部ロードバランサからのレスポンスを改めて NAT 変換し、送信元（返信元）IP アドレスを ILB の IP アドレスから改めて Endpoint のアドレスに SNAT するとともに、送信先（返信先）IP アドレスを NAT Subnet の IP アドレスから Client の IP アドレスに DNAT します。これにより、Client 側からも Endpoint の背後にある提供側 VPC の存在を意識しません。
このように、利用者側と提供者側の双方において実際の通信相手が異なる VPC に存在しているということを意識させないように構成してしまうことで、PSC は VPC ピアリングやルーティングなどのネットワークとしての構成を一切意識することなく VPC 範囲を超えたプライベートなサービス接続をサービス視点で実現しています。
第2回では PSC for Google APIs の構成例を、第3回では PSC for ILB の構成例についての解説とまとめを予定しています。お楽しみに!!
