API Gateway のデプロイモデル

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

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

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

    API 定義をアップロードするたびに、API Gateway によって新しい API 構成が作成されます。つまり、API 構成は作成できますが、後で変更することはできません。後で OpenAPI 仕様または gRPC サービス定義で API 定義を編集し、編集した API 定義をアップロードする場合は、新しい API 構成を作成します。

  2. ゲートウェイ: デプロイされた 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 構成に置き換えることができます。

  • 1 つの 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 は gateway.dev ドメインにゲートウェイの一意の URL を作成します。次に、API クライアントは、以下の形式の URL を使用して、デプロイされた API 構成にアクセスします。

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

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

次に例を示します。

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 は、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 構成のデプロイ

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

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

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

API の構築時に、API デベロッパーはしばしば次のような開発環境、ステージング環境、本番環境を作成します。

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

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

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

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

この例では、devstageprod の 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 構成を各リージョンに個別に再デプロイする必要があります。

次のステップ