Endpoints は、サービス、ランタイム、ツールからなる分散 API 管理システムです。Endpoints は管理、モニタリング、認証を提供します。
Endpoints を構成するコンポーネントは次のとおりです。
Extensible Service Proxy（ESP）または Extensible Service Proxy V2（ESPv2） - Endpoints 機能を追加します。
Service Control - API 管理ルールを適用します。
Service Management - API 管理ルールを構成します。
Google Cloud CLI - デプロイと管理に使用します。
Google Cloud コンソール - ロギング、モニタリング、共有に使用します。
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 キーを確認して、呼び出しを許可すべきかどうかを示します。
レポート - ロギングとモニタリングのレコードをシステムに通知します。
サービス管理
gRPC サービスの動作を、Endpoints 構成と呼ばれる YAML ファイルに記述します。API 管理ルールを構成する gcloud CLI を使用して、Service Management に対するエンドポイントの構成とコンパイルされた.proto ファイルをデプロイします。構成に関連するその他のタスクもここで行います。たとえば他のデベロッパーとの API の共有、さまざまなプロジェクトでの API の有効化と無効化、API キーの生成に関するタスクが考えられます。
gcloud CLI
gcloud CLI は、さまざまな Google Cloud サービスを呼び出す際に使用できる Google Cloud CLI を提供します。Google Cloud CLI を使用して Endpoints の構成を Service Management にデプロイします。
Google Cloud コンソール
Google Cloud コンソールは、Google Cloud のグラフィック ユーザー インターフェースです。Endpoints は Google Cloud コンソールを使用することで、ESP または ESPv2 から送信され Service Control で記録されるモニタリング データとロギングデータを公開すること、API を他のデベロッパーと共有すること、さらに他のデベロッパーが API を呼び出すための API キーを生成することができるようにします。
デプロイメント シナリオ
デプロイのオプションは、Endpoints プロキシとして ESP と ESPv2 のどちらを使用するかによって異なります。次のセクションで説明するように、ESPv2 はリモート プロキシとしてデプロイでき、ESPv2 と ESP はどちらもサイドカー モードでデプロイできます。
リモート プロキシモード
ESPv2 を使用する場合、Endpoints はリモート プロキシとしてデプロイできます。このモードは、サーバーレス プラットフォーム（スタンダード環境向けの Cloud Run、Cloud Run 関数、App Engine など）で実行されるアプリケーションをサポートするために使用されます。
このモードでは、ESPv2 が Cloud Run アプリケーションとしてデプロイされます。アプリケーションは、OpenAPI サービス構成の x-google-backend フィールドを使用して、ESPv2 をリモート バックエンドとして使用するように構成されています。このデプロイモードでリモート プロキシとして機能すると、1 つの ESPv2 が複数のリモート バックエンドをサポートできます。
サイドカー モード
ESP と ESPv2 はどちらも、バックエンドの各インスタンスとともに 1 つのコンテナ内でデプロイメントをサポートします。このサーバー ローカルなトポロジは、ウェブ公開 API にもマイクロ サービスにも最適です。集中管理プロキシに通常伴うネットワーク ホップが回避され、API 管理によって高いパフォーマンスとスケーラビリティが実現します。
通常、負荷分散は、トラフィックが ESP または ESPv2 に達する前に適用されます。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 でのサイドカー デプロイメントでも同じです。
