API Gateway のマルチリージョン デプロイの作成

このチュートリアルでは、API Gateway のマルチリージョン デプロイを有効にするように HTTP(S) ロードバランサを構成する方法について説明します。

API Gateway のマルチリージョン デプロイをサポートする HTTP(S) ロードバランサを作成すると、複数のリージョンからサービスを提供できるため、サービスの可用性が向上し、レイテンシを短縮できます。クロスリージョン ルーティングを使用すると、ユーザーに最も近いリージョンからのリクエストを処理するため、レイテンシを最小限に抑え、稼働時間を最大化できます。

このチュートリアルでは、単一の非リージョン URL スキームを構成します。このスキームは、世界中どこででも機能しますが、最も近い API Gateway のデプロイからのユーザー リクエストを処理します。この構成では、リクエストはユーザーへのレイテンシを最小限に抑えるリージョンにルーティングされることが理想的です。最も近いリージョンが利用できないか、そのリージョンの容量が不足している場合、リクエストは可用性を確保するために別のリージョンにルーティングされます。

始める前に

マルチリージョン デプロイを構成する前に、API Gateway のクイックスタートに沿って Cloud Run サービスをデプロイし、そのサービスを指すゲートウェイを作成します。

このチュートリアルでは、サービスを 2 つの異なるリージョンにデプロイします。たとえば、2 つの API Gateway インスタンスをデプロイします。

  • my-gateway-eu: ヨーロッパのリージョン用
  • my-gateway-us: 米国内のリージョン用

権限を構成

このチュートリアルでは、Cloud プロジェクトにサーバーレス ネットワーク エンドポイント グループ(NEG)と外部 HTTP(S) ロードバランサを作成します。これには、プロジェクトのオーナーまたは編集者のロール、または次の Compute Engine IAM のロールのいずれかが必要です。

タスク 必要なロール
ロードバランサとネットワーク コンポーネントの作成 ネットワーク管理者
NEG の作成と変更 Compute インスタンス管理者
SSL 証明書の作成と変更 セキュリティ管理者

SSL 証明書リソースを作成する

HTTPS ロードバランサを作成するには、ロードバランサのフロントエンドに SSL 証明書リソースを追加する必要があります。Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して SSL 証明書リソースを作成します。

  • Google マネージド証明書。このうち、Google Cloud が自動的に取得、管理、更新する Google マネージド証明書をおすすめします。Google マネージド証明書を作成するには、そのドメインをプロビジョニングするためのドメインと DNS レコードが必要です。ドメインがない場合は、Google Domains から取得できます。また、後の手順で作成するロードバランサの IP アドレスを指すように、ドメインの DNS A レコードを更新する必要があります。詳しい手順については、Google マネージド証明書の使用をご覧ください。

  • 自己署名証明書。この段階でドメインを設定したくない場合は、テスト用に自己署名 SSL 証明書を使用できます。

このチュートリアルでは、SSL 証明書リソースがすでに作成されていることを前提としています。

SSL 証明書リソース(または Google マネージド証明書で必要とされるドメイン)を作成せずにこのプロセスをテストする場合、このページの手順を使用して代わりに HTTP ロードバランサを設定できます。

HTTP(S) ロードバランサを作成する

  1. API Gateway インスタンスごとにサーバーレス NEG を作成します。

    ネットワーク エンドポイント グループ(NEG)は、ロードバランサのバックエンド エンドポイントのグループを指定します。サーバーレス NEG は、次の図に示すように、API Gateway などのサービスを指すバックエンドです。

    マルチリージョン ゲートウェイのバックエンドとしてのサーバーレス NEG の図

    各ゲートウェイ インスタンスにサーバーレス NEG を作成するには、次のコマンドを実行します。

    • SERVERLESS_NEG_NAME は、作成するサーバーレス NEG の名前です。
    • GATEWAY_ID はゲートウェイの名前を指定します。
    • REGION_ID は、サーバーレス NEG のデプロイ リージョンです(これはゲートウェイ リージョンと一致する必要があります)。
    gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
      --region=REGION_ID \
      --network-endpoint-type=serverless \
      --serverless-platform=apigateway.googleapis.com \
      --serverless-resource=GATEWAY_ID

    次に例を示します。

    gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg-eu \
      --region=europe-west1 \
      --network-endpoint-type=serverless \
      --serverless-platform=apigateway.googleapis.com \
      --serverless-resource=my-gateway-eu

    このコマンドを繰り返して、2 番目のゲートウェイ インスタンスに適切な値を使用して(たとえば、us-central1 リージョンの my-gateway-us には api-gateway-serverless-neg-us)、次のゲートウェイ インスタンスのサーバーレス NEG を作成します。

  2. バックエンド サービスを作成して、Cloud Load Balancing によるトラフィックの分散方法を定義します。

    バックエンド サービスの構成には、下の図に示すように、バックエンドへの接続に使用されるプロトコル、さまざまな配信とセッションの設定、ヘルスチェック、タイムアウトなどの値が含まれます。

    複数のデプロイがあるバックエンド サービスのバックエンドとしてのサーバーレス NEG の図

    バックエンド サービスを作成し、そのバックエンド サービスにバックエンドとしてサーバーレス NEG を追加するには、次のコマンドを実行します。

    • BACKEND_SERVICE_NAME はバックエンド サービスの名前です。
    • SERVERLESS_NEG_NAME は、前の手順で作成したサーバーレス NEG の名前です。
    • REGION_ID は、サーバーレス NEG のデプロイ リージョンです(これはゲートウェイ リージョンと一致する必要があります)。
    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --global \
      --network-endpoint-group=SERVERLESS_NEG_NAME \
      --network-endpoint-group-region=REGION_ID

    次に例を示します。

    gcloud compute backend-services add-backend api-gateway-backend-service \
      --global \
      --network-endpoint-group=api-gateway-serverless-neg-eu \
      --network-endpoint-group-region=europe-west1

    このコマンドを繰り返して、2 番目のサーバーレス NEG に適切な値を使用して(たとえば、us-central1 リージョンの my-gateway-us には api-gateway-serverless-neg-us)、2 番目のサーバーレス NEG をバックエンド サービスに追加します。

  3. 次の図に示すように、バックエンド サービスに受信リクエストをルーティングする URL マップを作成します。

    複数のデプロイがあるバックエンド サービスへの URL マップの図

    URL マップを作成するには、次のコマンドを実行します。

    • URL_MAP_NAME は、作成する URL マップの名前です。
    • BACKEND_SERVICE_NAME はバックエンド サービスの名前です。
    gcloud compute url-maps create URL_MAP_NAME \
      --default-service BACKEND_SERVICE_NAME

    次に例を示します。

    gcloud compute url-maps create api-gateway-url-map \
      --default-service api-gateway-backend-service

    この URL マップの例では、1 つのゲートウェイを表す 1 つのバックエンド サービスのみを対象としているため、ホストルールやパスマッチャーは必要ありません。複数のバックエンド サービスを対象とする場合、ホスト名に基づいてリクエストを特定のサービスに転送するにはホストルールを使用します。パスマッチャーを使用すると、リクエストパスに基づいてリクエストをさまざまなサービスに転送できます。

    次に例を示します。

    gcloud compute url-maps add-path-matcher api-gateway-url-map \
      --path-matcher-name=my-pm2  \
      --default-service=my-host-default-backend \
      --path-rules="/video=video-service,/video/*=video-service" \
      --new-hosts my-hosts.com
    gcloud compute url-maps add-host-rule api-gateway-url-map \
      --hosts=my-app-domain \
      --path-matcher-name=my-app-path-matcher

    ホストルールとパスマッチャーの詳細については、URL マップのドキュメントをご覧ください。

  4. 次の図に示すように、ターゲット プロキシの SSL 証明書を作成します。

    複数のデプロイがあるターゲット プロキシの SSL 証明書の図

    HTTPS ロードバランサを作成するには、HTTPS ターゲット プロキシに SSL 証明書リソースが必要です。SSL 証明書リソースは、Google マネージド SSL 証明書またはセルフマネージド SSL 証明書を使用して作成できます。Google マネージド証明書を使用することをおすすめします。

    Google マネージド証明書を作成するには、ドメインが必要です。ドメインがない場合は、自己署名 SSL 証明書を使用してテストできます。

    Google マネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。

    gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
      --domains DOMAIN

    セルフマネージド SSL 証明書リソースを作成するには、次のコマンドを実行します。

    gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
      --certificate CRT_FILE_PATH \
      --private-key KEY_FILE_PATH
  5. 次の図に示すように、URL マップにリクエストをルーティングするターゲット HTTP(S) プロキシを作成します。

    URL プロキシへの HTTP プロキシの図

    ターゲット プロキシを作成するには、次のコマンドを使用します。

    • TARGET_HTTP_PROXY_NAME は、作成するターゲット プロキシの名前です。
    • URL_MAP_NAME は、前の手順で作成した URL マップの名前です。
    • 省略可: SSL_CERT_NAME は、作成された SSL 証明書の名前です。
    gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --ssl-certificates=SSL_CERT_NAME
      --url-map=URL_MAP_NAME

    次に例を示します。

    gcloud compute target-http-proxies create api-gateway-https-proxy \
      --ssl-certificates=hello-cert
      --url-map=api-gateway-url-map
  6. 次の図に示すように、受信リクエストをプロキシにルーティングする転送ルールを作成します。

    HTTP プロキシへの転送ルールの図

    次のコマンドを使用して、転送ルールを作成します。

    • HTTPS_FORWARDING_RULE_NAME は、作成するルールの名前です。
    • TARGET_HTTP_PROXY_NAME は、作成するターゲット プロキシの名前です。
    gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
      --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
      --global \
      --ports=443

    次に例を示します。

    gcloud compute forwarding-rules create my-fw \
      --target-https-proxy=api-gateway-https-proxy \
      --global \
      --ports=443

ロードバランサの IP アドレスで DNS レコードを更新する

カスタム ドメインがある場合は、サービスの新しい IP アドレスを指すようにドメインの DNS 設定を行う必要があります。また、Google マネージド証明書を使用して HTTP(S) ロードバランサを作成している場合も必要です(ドメインが必要になります)。DNS で使用する場合は、静的 IP アドレスを割り当てて使用することをおすすめします。この手順の具体的な手順は、DNS プロバイダによって異なります。

  1. ロードバランサにトラフィックを送信するには、ドメインの DNS レコード(このチュートリアルでは my-app-domain)がロードバランサの IP アドレスを指している必要があります。

    グローバル転送ルールの IP アドレスを確認するには、次のコマンドを使用します。

    gcloud compute forwarding-rules list
  2. ロードバランサの IP アドレスを参照するようにドメインの DNS A または AAAA レコードを更新します。これにより、既存のカスタム ドメイン URL に送信されたトラフィックがロードバランサ経由でルーティングされるようになります。DNS がこの変更を DNS サーバーに反映するまでに、わずか数秒から数時間かかる場合があります。

  3. curl を使用して、またはブラウザで URL にアクセスし、ゲートウェイがトラフィックを受信していることを確認します。例: https://my-app-domain

    テスト時に、Cloud Run サービスによって生成されたレスポンスが表示されます。たとえば、これは「Hello World」という HTML ページや、バックエンド サービスから直接生成された別のレスポンスです。これは、リクエストがロードバランサを通過し、バックエンド サービスがロードバランサにユーザーのゲートウェイに送信するように指示していることを意味します。

考慮事項

API Gateway のマルチリージョン デプロイを実装する前に、次の点を考慮してください。

  1. API Gateway は現在、ヘルスチェックをサポートしていません。クロスリージョンのルーティング構成では、ゲートウェイまたはそのバックエンド サービスが 1 つのリージョンでエラーを返しても、そのリージョンの API Gateway インフラストラクチャ全体が利用可能で、十分な容量がある場合、HTTP(S) ロードバランサはトラフィックをその他のリージョンに転送しません。

  2. 1 つの転送ルールで異なるリージョンを組み合わせるには、プレミアム ティアの料金が必要です。料金と使用量の計算の詳細については、Network Service Tiers の料金をご覧ください。

おすすめの方法

マルチリージョンで配信する場合は、すべてのデータがグローバルに管理されるように、Cloud Spanner などのグローバルにレプリケートされたマネージド データ ストレージ ソリューションを使用することをおすすめします。