Cloud Endpoints のアーキテクチャの概要

Endpoints は、サービス、ランタイム、ツールからなる分散 API 管理システムです。Endpoints は管理、モニタリング、認証を提供します。

Endpoints を構成するコンポーネントは次のとおりです。

  • Extensible Service Proxy(ESP)または Extensible Service Proxy V2(ESPv2) - Endpoints 機能を追加します。

  • Service Control - API 管理ルールを適用します。

  • Service Management - API 管理ルールを構成します。

  • Cloud SDK - デプロイと管理に使用します。

  • Google Cloud Console - ロギング、モニタリング、共有に使用します。

Endpoints アーキテクチャ

Endpoints アーキテクチャ

Endpoints コンポーネント

ESP

ESP は、バックエンドの手前で実行され、認証、モニタリング、ロギングなどの Endpoints 機能を提供する NGINX ベースのプロキシです。ESP は Service Management からサービス構成を取得し、それを使用して受信リクエストを検証します。

ESP は、コンテナ環境にデプロイされて JWT と Google ID トークンを検証するように設計されています。軽量さとパフォーマンスの高さを維持するために、大量キャッシング、非同期呼び出しなど、さまざまな手法を採用しています。

ESP のサポートは、次のプラットフォームで使用できます。

ESPv2

ESPv2 は高性能でスケーラブルな Envoy ベースのプロキシで、OpenAPI バックエンドまたは gRPC API バックエンドの前面で動作します。ESPv2 上の Endpoints では、OpenAPI 仕様と gRPC 仕様のバージョン 2 がサポートされています。

認証、テレメトリー レポート、指標、セキュリティなどの API 管理機能を大規模に有効にするために、ESPv2 は Google Service Infrastructure と統合します。

ESPv2 のサポートは、次のプラットフォームでご利用いただけます。

Service Control

Service Control は、キー認証、モニタリング、ロギングなどの API 管理ルールを実行時に適用します。Service Control には、以下のメソッドが用意されています。

  • チェック - 認証情報と API キーを確認して、呼び出しを許可すべきかどうかを示します。

  • レポート - ロギングとモニタリングのレコードをシステムに通知します。

サービス管理

OpenAPI 仕様を使用して、Endpoints 構成と呼ばれるテキスト ファイルに API のサーフェスと動作を記述します。Cloud SDK を使用して Endpoints 構成を Service Management にデプロイすると、API 管理ルールが構成されます。構成に関連するその他のタスクもここで行います。たとえば他のデベロッパーとの API の共有、さまざまなプロジェクトでの API の有効化と無効化、API キーの生成に関するタスクが考えられます。

Cloud SDK

Cloud SDK では、さまざまな Google Cloud サービスを呼び出す際に使える gcloud コマンドライン ツールが提供されています。gcloud コマンドライン ツールを使用して、Endpoints 構成を Service Management にデプロイします。

Google Cloud Console

Cloud Console は、Google Cloud のグラフィック ユーザー インターフェースです。Endpoints は Cloud Console を使用して、ESP または ESPv2 から送信され、Service Control で記録されるモニタリング データとロギングデータを公開します。また、API を他のデベロッパーと共有して、デベロッパーは API を呼び出すための API キーを生成します。

デプロイメント シナリオ

デプロイのオプションは、Endpoints プロキシとして ESP と ESPv2 のどちらを使用するかによって異なります。次のセクションで説明するように、ESPv2 はリモート プロキシとしてデプロイでき、ESPv2 と ESP はどちらもサイドカー モードでデプロイできます。

リモート プロキシ モード

ESPv2 を使用する場合、Endpoints はリモート プロキシとしてデプロイできます。このモードは、サーバーレス プラットフォーム(スタンダード環境向けの Cloud Run、Cloud Functions、App Engine など)で実行されるアプリケーションをサポートするために使用されます。

このモードでは、ESPv2 は Cloud Run アプリケーションとしてデプロイされます。このアプリケーションは、OpenAPI サービス構成の x-google-backend フィールドを使用して、ESPv2 をリモート バックエンドとして使用するように設定されています。このデプロイモードでリモート プロキシとして機能する場合、1 つの ESPv2 で複数のリモート バックエンドをサポートできます。

詳細については、Endpoints の構成をご覧ください。

サイドカー モード

ESP と ESPv2 はどちらも、バックエンドの各インスタンスとともに 1 つのコンテナ内でデプロイメントをサポートします。このサーバー ローカルなトポロジは、ウェブ公開 API にもマイクロ サービスにも最適です。集中管理プロキシに通常伴うネットワーク ホップが回避され、API 管理によって高いパフォーマンスとスケーラビリティが実現します。

通常、負荷分散は、トラフィックが ESP または ESPv2 に達する前に適用されます。App Engine では、自動で負荷分散が行われます。Compute Engine では、Cloud Load Balancing により負荷分散が行われます。Kubernetes のデプロイでは、上り(内向きの)プロキシを使用して負荷分散できます。Google Kubernetes Engine では、負荷分散に Cloud Load Balancing または上り(内向きの)プロキシを使用できます。

ESP や ESPv2 は起動時に、Service Management からサービス構成を取得します。サービス構成は OpenAPI 仕様または gRPC、つまりサービス構成 YAML ファイルから生成されます。これにより、管理する API のサーフェスとポリシー(認証が必要なメソッド、API キーが必要なメソッドなど)が ESP または ESPv2 に伝えられます。

リクエストのルーティング

ESP または ESPv2 はリクエストを受信すると、Cloud Trace のトレース トークンを作成します。

次に、ESP または ESPv2 は受信リクエストのパスを API のサーフェスと照合します。一致するルートが見つかると、ESP または ESPv2 は指定されたメソッドの認証手順をすべて実施します。

JWT の検証が必要な場合、ESP または ESPv2 は、署名者の適切な公開鍵を使用して認証情報を検証し、JWT の audience フィールドを検証します。API キーが必要な場合、ESP または ESPv2 は、Service Control API を呼び出してキーを検証します。

Service Control はキーを調べて検証し、そのキーに関連付けられたプロジェクトで API が有効になっていることを確認します。キーが無効な場合、またはプロジェクトで API が有効になっていない場合は、呼び出しが拒否され、Service Control API によってそれがログに記録されます。

Service Control がキーの検証に成功した場合は、リクエストとともに、元のすべてのヘッダーおよび JWT 検証ヘッダー(該当する場合)がバックエンドに転送されます。

バックエンドからレスポンスを受信すると、ESP または ESPv2 は、呼び出し元にレスポンスを返し、最終的なタイミング情報を Trace に送信します。呼び出しポイントが Service Control API によってログに記録され、この API は指標とログを適切な場所に書き込みます。

Kubernetes 上の ESP または ESPv2

次の図は、ESP が API サービス アプリケーション コンテナの前面でサイドカー コンテナとして実行され、my-api API が my-api.com でホストされ、Kubernetes Service によってバックアップされる全体的なアーキテクチャを示しています。このアーキテクチャは、ESPv2 でのサイドカー デプロイメントでも同じです。

Kubernetes での Endpoints の概要

次のステップ