トップ > Private Service Connect > Private Service Connect でマネージドサービスを公開する

Private Service Connect でマネージドサービスを公開する

Private Service Connect Virtual Private Cloud (VPC) Google Cloud
記事タイトルとURLをコピーする

G-gen の杉村です。Private Service Connect は Google Cloud API やユーザー独自で公開するサービスにプライベート接続を提供するサービスです。当記事では、Private Service Connect を使って独自サービスを公開する方法をご紹介します。

概要

Private Service Connect とは

Private Service Connect とは Google Cloud (旧称 GCP) の Virtual Private Cloud (VPC) に備わった一機能です。

以下の用途で用いられます。

  1. Google Cloud の API にプライベート IP でアクセスする
  2. ユーザー独自のサービスを他の Google Cloud プロジェクト向けに公開する

前者は、本来パブリック IP を用いてインターネット経由でのアクセスが必要な Google Cloud の各種 API に対し、プライベート IP による接続を実現する用途です。以下の記事で詳細を紹介しています。

blog.g-gen.co.jp

後者は、当記事でご紹介する内容です。Google Cloud 上でホストするサービス (Web API やその他のサービス) を 他の Google Cloud ユーザー向け 、あるいは 社内の別 Google Cloud プロジェクト向け に公開する用途です。

AWS には類似の機能として AWS PrivateLink があり、これの Google Cloud 版と思えば良いでしょう。

Private Service Connect によるサービス公開

Compute Engine VM 等でホストするサービスを他の Google Cloud プロジェクトや他の VPC に向けに公開するには、以下のような方法が考えられます。

  1. サービスエンドポイントをインターネットに公開する (外部 HTTP(S) ロードバランサ等を利用)
  2. VPC Peering で接続する
  3. Cloud VPN で VPC 同士を接続する
  4. Private Service Connect で公開する

選択肢 1. は、通常の Web サービスのようにインターネット公開する方法です。ただし、サービスが特定少数のクライアントにだけ向けたものであれば、セキュリティ上の理由でこの方法は避けたくなります。

選択肢 2. や 3. は、VPC 同士を直接接続し、プライベート IP で通信する方法です。これなら不特定多数のクライアントからアクセスされることはありませんが、全ての VPC 同士の IP アドレス帯が重複していない ことが必須条件です。複数の会社・官公庁をまたぐネットワークだと、IP アドレス帯が重複してしまっているケースも多いでしょう。

そこで選択肢 4. の Private Service Connect が検討に入ります。

Private Service Connect によるサービス公開では、IP アドレスの重複有無に関係なく、他の VPC 向けにサービスを公開し、プライベートネットワークでの接続を実現することができます。この方法を Private Service Connect によるマネージドサービス公開 と言います。

Private Service Connect のアーキテクチャ

構成図

Private Service Connect でのマネージドサービス公開は、以下のようなアーキテクチャで実現されます。

アーキテクチャ

左側の Google Cloud 環境がサービスを利用する側 (サービスコンシューマーとも呼称) で、右側がサービスを提供する側 (サービスプロデューサーとも呼称) です。

通信の流れ

通信は、以下の流れで実現されます。

前提 : 図右端のサーバは HTTP (tcp/80) でサービスを提供。図左端のクライアントからアクセスされる

  1. クライアントは 10.100.0.101:80 (Private Service Connect エンドポイント) へアクセス
  2. 通信は Google Cloud 内部ネットワークを通りサービス提供側環境の Service Attachment へ到達。SNAT されて内部ロードバランサへ到達
  3. 内部ロードバランサが負荷分散してバックエンドのサーバへ通信が届く (レスポンスは逆の経路を通ってクライアントに返る)

詳細な構成

サービス提供側

サービス提供側は 「サービスアタッチメント」「内部ロードバランサ」「バックエンドサーバ」 の組み合わせでサービスを提供します。

サービスアタッチメント はサービス公開のために作成されるリソースであり、1サービスにつき1個のサービスアタッチメントを作成します。サービスアタッチメントはパケット転送先として 転送ルール にひも付きます。この「転送ルール」とは、ロードバランサの「フロントエンド」と思えば良いです。

なおサービスアタッチメントを作成するための 専用サブネット が必要です。サブネット作成時に「Private Service Connect 用」と明示的に選択して作成する必要があります。サイズは任意であり最小サイズ ( /29 ) とすることもできますが同時接続するクライアント数が多すぎると IP 不足になるおそれがあります (参考)。

内部ロードバランサ は、以下の種類に対応しています。

  • 内部パススルーネットワークロードバランサ
  • 内部アプリケーションロードバランサ
  • 内部プロトコル転送
  • リージョン内部プロキシネットワークロードバランサ

バックエンドサーバ としては、内部ロードバランサが対応している各種バックエンドが利用できます。すなわち、Compute Engine VM (インスタンスグループ) や VPN / 専用線で接続されたオンプレミスのサーバなどが利用できます。

サービス利用側

サービス提供側でサービスアタッチメントを作成すると、サービス名が払い出されます ( projects/${PROJECT_ID}/regions/${REGION}/serviceAttachments/${SERVICE_NAME})。

サービス利用側ではこの名称を指定して、サービスに接続するためのエンドポイント (Private Service Connect Endpoint) を作成します。

エンドポイントを作成するとプライベート IP が割り当てられます。クライアントからはこのプライベート IP を宛先としてサービスを利用します。

なお、サービス提供側ではサービスアタッチメント作成時に、明示的に承認したプロジェクトのエンドポイントだけを受け付けるように設定できます。未承認のエンドポイントではパケットが転送されません。

※ より詳細な仕様として、Private Service Connect エンドポイントの実体は「サービスアタッチメントをターゲットとする転送ルール」であり gcloud compute forwarding-rules list で一覧表示することができます。転送ルールはロードバランサのフロントエンドとしても利用されるリソースです。

接続元 IP アドレス

トラフィックの接続元 IP アドレスはバックエンドサーバからどう見えるのかが問題になることがあります。Private Service Connect でルートされたトラフィックの接続元 IP は、利用しているロードバランサによって異なります。

  • 内部ロードバランサが プロキシ型 の場合、バックエンドサーバから見た接続元 IP は プロキシ専用サブネットの CIDR 範囲 となる
  • 内部ロードバランサが パススルー型 の場合、バックエンドサーバから見た接続元 IP は サービス専用サブネットの CIDR 範囲 となる

いずれの場合でも、クライアントの元々の IP アドレスは得ることができません。元々の IP アドレスを知りたい場合にはサービスアタッチメントにて プロキシプロトコル を有効化します。有効化する場合は以下に注意が必要です。

  • 対応しているのは「内部 TCP / UDP ロードバランサ (TCP 通信のみ)」と「内部プロトコル転送」のみ
  • サーバ側でプロキシプロトコルヘッダを処理するように適切に設定しなければ、リクエストが正常に処理されない

またプロキシプロトコルを使った場合でも VPC Firewall などではその情報を参照できないため、Firewall rule で接続元 IP に基づいたアクセス制御を行うことはできません。詳細は以下のドキュメントも参考にしてください。

DNS 名

エンドポイントに DNS 名を設定することもできます。

Service Directory の機能を利用することでサービス提供側で DNS 名を定義 することも可能ですし、サービス利用側で Cloud DNS を使って 定義する ことも可能です。

構築手順

サービス提供側の手順

大まかに、以下の作業を行います。

  1. バックエンドサーバを構築
  2. 内部ロードバランサを構築 (適切な VPC Firewall rule を作成)
  3. Private Service Connect サービス専用サブネットを作成
  4. (パススルー型ロードバランサの場合) サービス専用サブネットからの通信を許可する VPC Firewall rule を作成
  5. サービスアタッチメントを作成
  6. 承認するプロジェクトを追加

詳細は以下のドキュメントを参照してください。

サービス利用側の手順

サービス利用側では原則的に「エンドポイントを作成する」だけです。

その他にも DNS の設定などを使用する場合は、追加の手順があります。詳細は以下のドキュメントを参照してください。

Private Service Connect backends

応用として Private Service Connect backends という手法を用いることもできます (かつては「コンシューマ HTTP(S) コントロールを使用する Private Service Connect エンドポイント」と呼称されていました)。

こちらですと、サービス利用側は外部 HTTP(S) ロードバランサをエンドポイントとして利用します。ロードバランサのバックエンドサービスとして「Private Service Connect NEG」を利用することで実現します。

メリットとしては「サービスを柔軟に任意の URL にマップできる」「Cloud Logging に全リクエストをロギングできる」「任意の SSL/TLS 証明書を利用できる」「段階的に Private Service Connect にホストされたサービスへ移行できる」などがあります。

詳細は以下のドキュメントを参照してください。

Private Service Connect interfaces

Private Service Connect interfaces は、Private Service Connect Endpoint とは逆で、サービス提供側から開始してサービス利用側へ通信する経路を確立するっ機能です。

サービス利用側のサブネットに ネットワークアタッチメント (network attachment) というコンポーネントを作成します。このコンポーネントには Internal IP アドレスが割り振られ、サービス提供側からの通信を中継します。

サービス提供側の Compute Engine VM は最低2つの NIC を持つ必要があり、うち一つが Private Service Connect interface であり、サービス利用側 (顧客側) との通信に使われます。一つの VM には7つまで Private Service Connect interface を作成できます。

当機能の詳細は、以下の公式ガイドを参照してください。

なお当機能は2023年6月現在、Preview であることにご留意ください。

料金

サービス提供側

サービスアタッチメントで処理したデータ 1 GB につき $0.01 が発生します (上り・下りの両面)。

Private Service Connect 自体にかかる料金は上記のみですが、これに加えてバックエンドのサーバ (Compute Engine 等) の利用料金や、内部ロードバランサの利用料金も発生しますのでご留意ください。

サービス利用側

エンドポイントに 1 時間あたり $0.01 の料金が発生します。

また処理したデータ 1 GB あたり $0.01 が発生します (上り・下りの両面)。

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。