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 構成を作成します。
ゲートウェイ: デプロイされた API 構成をホストする Envoy ベースの高パフォーマンスでスケーラブルなプロキシ。API 構成をゲートウェイにデプロイすると、API クライアントが API へのアクセスに使用する外部向け URL が作成されます。
次の図に、これらのコンポーネントを示します。
ゲートウェイへの 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_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 は、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 構成を異なるゲートウェイにデプロイできます。
この例では、dev、stage、prod の 3 つの異なる API 構成があります。次に、各 API 構成を別のゲートウェイにデプロイすると、各ゲートウェイで固有のエンドポイント URL が定義されます。
API 構成の複数のリージョンへのデプロイ
多くの場合、API を複数の GCP リージョンにデプロイします。複数のリージョンにデプロイすると、リクエストがクライアントの地理的に近いリージョンで実行される API に送信されるためにリクエストのレイテンシが低減したり、あるリージョンで障害が発生しても他のリージョンで実行されている API には影響しないために信頼性が向上するなど、いくつかの利点があります。
API を複数のリージョンにデプロイするには、API 構成を各リージョンのゲートウェイにデプロイします。各 API 構成は、そのリージョン内のバックエンド サービスを参照する必要があるため、デプロイされたリージョンに固有のものです。
次の図では、API 1 と API 2 は 1 つのリージョンにデプロイされ、API 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 構成を各リージョンに個別に再デプロイする必要があります。