Private Service Connect を使って API プラットフォームから限定公開のサーバーレス サービスにアクセスするには
Google Cloud Japan Team
※この投稿は米国時間 2023 年 7 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。
Cloud Run は、Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォームです。最小限の必要リソースで、Apigee X から Cloud Run アプリケーションを利用できます。Apigee X は API の開発と管理を行うプラットフォームです。プロキシレイヤをサービスのフロントにすることで、Apigee はバックエンド サービス API の抽象化またはファサードを提供し、セキュリティ、レート制限、割り当て、分析などの機能を提供します。
ここでは、Private Service Connect（PSC）を使用して、別の Cloud プロジェクトや VPC から内部の Cloud Run アプリケーション（アプリ）を利用する方法についてご説明します。Apigee X から Cloud Run アプリに接続することでサービス アタッチメントの数を最小限に抑える方法があることについても紹介します。
ユースケース
Cloud Run を使用すると、Cloud Run サービスの運用、構成、スケーリングに必要な時間がほとんどなくなるため、デベロッパーはコードの作成に時間を費やすことができます。
つまり、クラスタの作成やインフラストラクチャの管理をすることなく Cloud Run で生産性を向上できます。
Cloud Run を使えば、アプリケーションを公共のインターネットに簡単に公開できます。また、上り（内向き）設定を使用して、サービスへの外部ネットワーク アクセスを制限することもできます。
では、別の GCP プロジェクトや Virtual Private Cloud（VPC）からこれらの内部アプリケーションに自動的にアクセスするにはどうすればよいのでしょうか。
その場合、リソースが同じ Cloud リージョンにあるとした場合に、2 つの VPC 間接続の可否、あるいは少なくとも 1 つの VPC から別の Cloud プロジェクト内の別のネットワーク リソースへの接続の可否が問題になります。
この記事でご説明するソリューションは、次の 2 つです。
VPC ピアリング
Private Service Connect（PSC）
この 2 つを取り上げて、Apigee X から内部の Cloud Run アプリを利用する方法について説明します。Apigee X は、API の公開とターゲット エンドポイントの接続で、VPC ピアリングと PSC の両方に対応しています。
このユースケースが特に重要となるのは、API 管理の場面です。内部サービスを作成し、そのサブセットだけを API として特定の外部クライアントに公開したい場合に活用できます。さらに、デベロッパー ポータルを作成して、これらの API をプロダクトとして公開し、収益化することも可能です。
また、Cloud Run サービスを作成し、Apigee X のターゲット エンドポイントから PSC を操作すれば、サービス アタッチメントの作成を最小限に抑えられます。
こちらのユースケースも、本記事の最後に解説と実装方法を紹介します。
VPC 間のネットワーク通信向けのソリューション
このセクションでは、1 つの VPC に存在するリソースに別の VPC からアクセスできるようにするソリューションを 2 つ紹介します。
VPC ピアリング
Google Cloud VPC ネットワーク ピアリングは、2 つの VPC ネットワークを接続し、各ネットワークのリソースが相互通信できるようにするソリューションです。VPC ピアリングのメリットとしては、ネットワーク セキュリティが挙げられます。サービス オーナーは、公共インターネットへのサービス公開や付随するリスクへの対処を行う必要はありません。
なお、VPC ピアリングのようなネットワーク通信を設定するには、サブネットを調整し、異なるネットワークや組織間の複雑なルーティング トポロジを管理する必要があります。
セキュリティ上の懸念に対処するためにサービスを完全に分離しておきたいと考える企業にとって、これは大きな課題となります。対策の一例として、多くの企業は、VPC ピアリング通信のトランスポート層とネットワーク層を制御できるよう、消費者側でネットワーク セキュリティ アプライアンスを使用するよう求めています。
Private Service Connect
PSC は、エンドポイントとサービス アタッチメント間の一方向の通信チャネルです。VPC ピアリングとは違い、基盤のインフラストラクチャは公開されません。そのため、サービスの接続と管理が大幅にシンプルになり、安全性と機密性も高まります。
なお、PSC の場合、アクセスする必要があるアプリケーションごとにエンドポイント アタッチメントとサービス アタッチメントを構成しなければなりません。ただし、アタッチメントの作成を最小限に抑えるソリューションがいくつか存在します。
この記事では、PSC 上に構築した Apigee X インスタンスから Cloud Run サービス（バックエンド）に接続するソリューションをご紹介します。ノースバウンドに関しては、ここでは特にご紹介しません。外部ロードバランサと「古典的」な MIG 経由の VPC ピアリングを使用するか、外部ロードバランサと PSC ネットワーク エンドポイント グループを使用するかは自由にお選びいただけます。
ソリューションの概要
このセクションでは、Apigee X ランタイムから内部の Cloud Run サービスにアクセスするために使用するソリューション案をご紹介します。
内部 HTTPS ロードバランサ（L7 ILB）は、サーバーレス NEG と URL マスクを使用して複数の Cloud Run アプリに対応する際に利用されます。サーバーレス NEG バックエンドは、複数の Cloud Run サービスを指すことができます。
URL マスクは、URL スキーマのテンプレートです。サーバーレス NEG はこのテンプレートを使用して、リクエストを適切なサービスにマッピングします。
L7 ILB には、Apigee X インスタンスから PSC エンドポイント アタッチメントを経由し、そこからさらに PSC サービス アタッチメントを経由してアクセスします。L7 ILB に関連する 2 つのアタッチメント（エンドポイント アタッチメントとサービス アタッチメント）は、同じ GCP リージョンに属している必要があります。
Apigee X は、PSC チャネルを経由して L7 ILB にアクセスする際、ターゲット エンドポイントを使用します。このエンドポイントは、HTTPS で構成され、専用のホスト名（l7 ILB のホスト名）を使用します。
よって、次の 2 種類の DNS 解決が必要となります。
1 つは、Apigee X（ターゲット エンドポイント）で行われるもので、PSC エンドポイント アタッチメントを参照します。管理するには、限定公開の Cloud DNS（A レコード）と DNS ピアリングが必要となります。この限定公開 DNS ゾーンは、Apigee X VPC とピアリングされているコンシューマ VPC（上の図では apigee-network という名前）上に構成されます。DNS ピアリングは特定のドメイン（上の例では example.com）の間の 2 つの VPC で構成されます。
もう 1 つは PSC サービス アタッチメントで行われるもので、L7 ILB を参照します。管理するには限定公開の Cloud DNS（A レコード）が必要となります。この限定公開ゾーンは、VPC（上の図では ilb-network という名前）上に構成されます。なお、L7 ILB は、SSL 証明書を提示してセキュアな通信を確立します。
さまざまな Cloud Run サービスを利用するには、ID トークンが必要です。Apigee X で生成され、署名なしトークンとして Cloud Run アプリに送信されます。
Apigee X 上のターゲット エンドポイントの構成は次のようになります。
ターゲット エンドポイント構成が含まれている API プロキシは、Cloud Run のような Google サービスに認証された呼び出しを送信できます。この API プロキシでは、「roles/run.invoker」というロールを持つ専用のサービス アカウントを作成および構成する必要があります。これについては、Google Apigee のドキュメントでも説明されています。
オーディエンス（ID トークンの aud 属性）は、Apigee の AssignMessage ポリシーを使用して動的に設定します。
内部の Cloud Run アプリにアクセスするには
このセクションでは、内部 HTTPS ロードバランサとサーバーレス ネットワーク エンドポイント グループ（NEG）を使用して内部の Cloud Run アプリケーションにアクセスする方法について説明します。
内部 HTTPS ロードバランサ
サーバーレス NEG と内部 HTTPS ロードバランサを使用して Cloud Run アプリにアクセスするうえで必要となるさまざまなコンポーネントは、次の図のとおりです。
サーバーレス アプリの HTTP(S) ロードバランサを有効にすると、同じドメインに対応する複数のサーバーレス サービスに 1 つの URL をマッピングできるようになります。
クライアント アプリケーションは内部 HTTPS ロードバランサに接続し、ターゲット HTTPS プロキシを経由して特定の SSL 証明書を公開します。
サーバーレス NEG
サーバーレス NEG を使用すると、ロードバランサを使って Cloud Run サービスを使用できるようになります。サーバーレス NEG バックエンドを使用してロードバランサを構成すると、そのロードバランサへのリクエストは Cloud Run バックエンドに転送されるようになります。
サービス アタッチメントの数を最小限に抑えるには
URL マスキング
サーバーレス NEG バックエンドは、単一の Cloud Run サービスを指すことも、複数の Cloud Run サービスを参照する URL マスクを指すこともできます。URL マスクは、URL スキーマのテンプレートです。サーバーレス NEG はこのテンプレートを使用して、リクエストを適切なサービスにマッピングします。
URL マスクは、サーバーレス アプリケーションが複数の Cloud Run サービスで構成されている場合に、サーバーレス NEG を構成しやすくするオプション機能です。内部 HTTP(S) ロードバランサで使用されるサーバーレス NEG は、Cloud Run サービスを参照する URL マスクのみを使用できます。
URL マスクが役立つのは、サーバーレス アプリが Google Cloud から割り当てられるデフォルトのアドレスではなく、カスタム ドメインにマッピングされている場合です。
example.com などのカスタム ドメインを使用すると、同じドメインの異なるサブドメインまたはパスに複数のサービスをデプロイできます。その場合、カスタム ドメイン用の汎用 URL マスク（example.com/<service> など）を使用した単一のサーバーレス NEG を作成できます。サービスごとに個別のサーバーレス NEG バックエンドを作成する必要はありません。NEG は、リクエストの URL からサービス名を抽出します。
異なる Google Cloud プロジェクトや VPC にデプロイされている Cloud Run アプリにアクセスするには
Apigee X からは、異なる VPC や GCP プロジェクトにデプロイされたさまざまな内部 Cloud Run サービスにアクセスできます。この場合、Apigee X 側には PSC エンドポイント アタッチメントを個別に作成する必要があります。
個々の Apigee X エンドポイント アタッチメントは、それぞれ専用の PSC サービス アタッチメントと関連付けられます。なお、PSC サービス アタッチメントは、属する GCP プロジェクトや VPC は異なっていても、属する GCP リージョンは必ず同じでなければなりません。
ソリューションのデプロイ
この記事の説明に沿ってアーキテクチャ全体をプロビジョニングするために使用できる Terraform モジュールを、こちらで提供しています。
次のステップ
Apigee は、内部 Cloud Run アプリケーションを活用して API の安全性確保、製品化、費用管理、分析提供を行うのに最適なプラットフォームです。API プロダクトをデベロッパー ポータルにデプロイすれば、簡単にアクセスできるようになります。
Apigee について詳しくは、以下をご覧ください。
ドキュメント
Git リポジトリ
Apigee Devrel: Apigee プロダクトのリファレンス ソリューションをお探しの場合
Google Cloud コミュニティ
- 戦略的クラウド エンジニア Anmol Sachdeva
