API Gateway のデプロイモデル

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

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

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

    API 定義をアップロードするたびに、API ゲートウェイは新しい 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

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

ゲートウェイに API 構成をデプロイすると、API Gateway によって gateway.dev ドメインにゲートウェイの一意の URL が作成されます。次に、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 構成が複数あり、ステージングでテスト中の API 構成が 1 つ、本番環境にデプロイ中の API 構成が 1 つあるとします。

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

次のステップ