API Gateway のデプロイモデル

API コンポーネントについて

API Gateway で定義された API は、次の 2 つの主要コンポーネントで構成されています。

API 構成: API 定義をアップロードしたときに作成される API 構成。API 定義は OpenAPI 仕様として作成します。API が Cloud Run 上の gRPC サービスを管理する場合は、gRPC サービス定義と構成で API を定義できます。

API 定義をアップロードするたびに、API Gateway によって新しい API 構成が作成されます。つまり、API 構成は作成できますが、後で変更することはできません。後で OpenAPI 仕様または gRPC サービス定義で API 定義を編集し、編集した API 定義をアップロードすると、新しい API 構成が作成されます。
Gateway: デプロイされた API 構成をホストする、Envoy ベースの高パフォーマンスでスケーラブルなプロキシ。API 構成をゲートウェイにデプロイすると、API クライアントが API へのアクセスに使用する外部公開 URL が作成されます。

次の図に、これらのコンポーネントを示します。

[API Gateway] ペインの API 定義には、3 つの API 構成コンポーネントと 3 つのゲートウェイコンポーネントが表示されています。

ゲートウェイへの API 構成のデプロイについて

API クライアントが API にアクセスできるように、API 構成をゲートウェイにデプロイします。

3 つのサンプル API では、API 構成がゲートウェイにデプロイされ、API クライアントが API にアクセスできるようにしています。

ゲートウェイ:

特定の GCP リージョンにデプロイされます。リージョンとは、リソースをデプロイできる GCP 上の特定の地理的なリージョンです。
API 構成をホストする必要があります。空のゲートウェイ、つまり API 構成のないゲートウェイは作成できません。ただし、ゲートウェイの作成後にゲートウェイを更新して、ある API 構成を別の API 構成に置き換えることはできます。
単一の API 構成のみをホストできます。同じゲートウェイに複数の API 構成をデプロイすることはできません。

デプロイされた各ゲートウェイは個別に管理します。ゲートウェイごとに次のことができます。

ゲートウェイの起動/停止/削除
ログと指標の表示
トレース情報の表示

GCP リージョンの選択

各ゲートウェイは GCP 上の特定の地理的なリージョンにデプロイされます。API Gateway は、以下の GCP リージョンのデプロイをサポートしています。

asia-northeast1
australia-southeast1
europe-west1
europe-west2
us-east1
us-east4
us-central1
us-west2
us-west3
us-west4

以前に asia-east1 に作成された API Gateway ゲートウェイのサポートは、2022 年 11 月 1 日に終了します。 asia-east1 で現在実行中のゲートウェイを確認し、必要に応じて削除するか、新しい場所で再作成してください。

デプロイされた API 構成のエンドポイントの定義

API 構成をゲートウェイにデプロイすると、API Gateway によってゲートウェイの一意の URL が gateway.dev ドメインに作成されます。API クライアントは、次の形式の URL を使用して、デプロイされた API 構成にアクセスします。

https://GATEWAY_ID-HASH.REGION_CODE.gateway.dev

ここで、GATEWAY_ID はゲートウェイの名前、HASH は API のデプロイ時に生成された一意のハッシュコード、REGION_CODE は GCP リージョン（ゲートウェイをデプロイした場所）のコードです。

次に例を示します。

my-gateway-a12bcd345e67f89g0h.uc.gateway.dev

API 構成をデプロイするためのサービスアカウントの構成

ゲートウェイにデプロイされた API 構成は、API 構成の作成に使用されるサービスアカウントに付与されているロールに関連付けられた権限で実行されます。そのため、通常は、API 構成用に別のサービスアカウントを定義します。そのサービスアカウントは、バックエンドサービスにアクセスするために必要なロールにのみ割り当てられます。このようにして、API 構成に関連付けられた権限を制限できます。

サービスアカウントには、バックエンドサービスへのアクセスに必要なロールに加えて、次の権限が付与されている必要があります。

iam.serviceAccounts.actAs 権限。この権限は、サービスアカウントユーザーのロールに含まれています。
バックエンドサービスにアクセスするために必要な権限。たとえば、バックエンドを Cloud Functions として実装する場合、少なくとも Cloud Functions 起動元のロールにサービスアカウントを割り当てる必要があります。Cloud Run バックエンドの場合、ロールは Cloud Run 起動元です。API 構成に関連付けられた権限を制限することで、バックエンドシステムをより適切に保護できます。

詳細については、開発環境の構成をご覧ください。

ゼロへのスケーリングについて

API Gateway はゼロへのスケーリングのサービスです。つまり、トラフィックがない場合はすべてのゲートウェイインスタンスが削除され、トラフィックが増加すると、負荷を処理するためにオンデマンドで新しいインスタンスが作成されます。ゼロへのスケーリングは GCP によって自動的に制御されます。構成や管理は必要ありません。

ロードバランサの使用

リージョンにデプロイされた各ゲートウェイには、ゲートウェイにデプロイされた API へのクライアントリクエストを管理する統合ロードバランサが含まれています。ゲートウェイごとに個別のロードバランサを作成する必要はありません。

異なるリージョンのゲートウェイに同じ API をデプロイする場合は、ロードバランサを作成する必要があります。その後、ロードバランサは API リクエストを異なるリージョンに転送します。詳細については、下記の複数のリージョンへの API のデプロイをご覧ください。

API への SSL アクセスの構成

API Gateway は、ゲートウェイにデプロイされた API への HTTPS アクセスをサポートします。API は gateway.dev ドメインにデプロイされるため、Google はゲートウェイと統合されたロードバランサで SSL 証明書を作成および管理します。独自の証明書を作成またはアップロードする必要はありません。

ドメインネームサーバーの構成

デフォルトでは、API クライアントは、上記に示すように、デプロイされた API にアクセスするための gateway.dev ドメインへのリクエストを行います。

カスタムドメイン名は、API Gateway^{プレビュー} の HTTP(S) ロードバランシングと組み合わせて使用する場合の API Gateway に使用されます。ドメイン名をカスタマイズするには、カスタムドメイン名を使用するロードバランサを作成し、デプロイした API の gateway.dev ドメインにリクエストを送信します。詳細については、API Gateway でカスタムドメインを使用するをご覧ください。

同じ API での複数の API 構成のデプロイ

ゲートウェイにデプロイできる API 構成は 1 つのみです。ただし、同じ API 内の複数のゲートウェイに複数の API 構成をデプロイすることはできます。

このセクションでは、1 つの API 内の複数のゲートウェイに複数の API 構成をデプロイする 2 つのシナリオについて説明します。

同じリージョン内の複数のゲートウェイへの API 構成のデプロイ

API を構築するときに、API 開発者は通常、次のような開発環境、ステージング環境、本番環境を作成します。

開発環境は、デベロッパーが API を作成するために使用します。
ステージング環境は、本番環境へのリリースに備えて API をテストするために使用されます。
本番環境では、外部 API クライアントが API にアクセスできます。

このタイプの開発環境をサポートするには、複数の API 構成を定義します。たとえば、現在開発中の API 構成が複数あり、現在、1 つのAPI 構成がステージング環境でテストされており、1 つのAPI 構成が本番環境にデプロイされているとします。

API Gateway を使用すると、1 つの API 内で複数の API 構成を作成して、各 API 構成を異なるゲートウェイにデプロイできます。

API 1 では、API Config Dev、API Config Stage、API Config Prod という 3 つの API 構成が、それぞれ 3 つのゲートウェイにデプロイされます。

この例では、dev、stage、prod の 3 つの異なる API 構成があります。次に、各 API 構成を別のゲートウェイにデプロイすると、各ゲートウェイで固有のエンドポイント URL が定義されます。

API 構成の複数のリージョンへのデプロイ

多くの場合、API を複数の GCP リージョンにデプロイします。複数のリージョンにデプロイすると、リクエストがクライアントの地理的に近いリージョンで実行される API に送信されるためにリクエストのレイテンシが低減したり、あるリージョンで障害が発生しても他のリージョンで実行されている API には影響しないために信頼性が向上するなど、いくつかの利点があります。

API を複数のリージョンにデプロイするには、API 構成を各リージョンのゲートウェイにデプロイします。各 API 構成は、そのリージョンのバックエンドサービスを参照する必要があるため、デプロイされたリージョンに固有のものです。

次の図では、API 1 と API 2 は 1 つのリージョンにデプロイされ、API 3 は複数のリージョンにデプロイされています。

API 1 と API 2 はリージョン 1 にデプロイされ、API 3 はロードバランサを使用してリージョン 1、リージョン 2、リージョン 3 にまたがってデプロイされます。

この例では、API 3 用のゲートウェイにデプロイされた各 API 構成には、次の形式の一意の URL エンドポイントがあります。

https://my-gateway1-a12bcd345e67f89g0h.uc.gateway.dev
https://my-gateway2-b12cde345f67g89h0i.en.gateway.dev
https://my-gateway3-c12bde345g67h89i0j.uw.gateway.dev

次に、API Gateway^{プレビュー}用の HTTP(S) ロードバランシングを使用してロードバランサを構成し、API へのリクエストを処理して適切なリージョンに転送します。詳細については、API Gateway のマルチリージョンデプロイの作成をご覧ください。

API の更新

デプロイされた API を更新するには、OpenAPI 仕様で API 定義を編集してから、仕様をアップロードします。新しい仕様をアップロードすると、新しい API 構成が作成されます。

API Gateway は、ダウンタイムのない更新モデルをサポートしています。つまり、更新された API 構成のデプロイ中に API がリクエストの処理を継続します。ただし、一部のリクエストが前のバージョンの API 構成で処理される可能性がある場合は、新しい API 構成がデプロイされる期間があります。

API 構成を複数のリージョンとゲートウェイにデプロイしている場合は、更新された API 構成を各リージョンに個別に再デプロイする必要があります。

次のステップ

OpenAPI の概要