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) ロードバランサを作成する

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

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

各ゲートウェイインスタンスにサーバーレス 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 を作成します。
バックエンドサービスを作成して、Cloud Load Balancing によるトラフィックの分散方法を定義します。

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

バックエンドサービスを作成し、そのバックエンドサービスにバックエンドとしてサーバーレス 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 をバックエンドサービスに追加します。
次の図に示すように、バックエンドサービスに受信リクエストをルーティングする 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 マップのドキュメントをご覧ください。
次の図に示すように、ターゲットプロキシの 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
```
次の図に示すように、URL マップにリクエストをルーティングするターゲット HTTP(S) プロキシを作成します。

ターゲットプロキシを作成するには、次のコマンドを使用します。
- 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
```
次の図に示すように、受信リクエストをプロキシにルーティングする転送ルールを作成します。

次のコマンドを使用して、転送ルールを作成します。
- 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 プロバイダによって異なります。

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

グローバル転送ルールの IP アドレスを確認するには、次のコマンドを使用します。
```
gcloud compute forwarding-rules list
```
ロードバランサの IP アドレスを参照するようにドメインの DNS A または AAAA レコードを更新します。これにより、既存のカスタムドメイン URL に送信されたトラフィックがロードバランサ経由でルーティングされるようになります。DNS がこの変更を DNS サーバーに反映するまでに、わずか数秒から数時間かかる場合があります。
curl を使用して、またはブラウザで URL にアクセスし、ゲートウェイがトラフィックを受信していることを確認します。例: https://my-app-domain

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

考慮事項

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

API Gateway は現在、ヘルスチェックをサポートしていません。クロスリージョンのルーティング構成では、ゲートウェイまたはそのバックエンドサービスが 1 つのリージョンでエラーを返しても、そのリージョンの API Gateway インフラストラクチャ全体が利用可能で、十分な容量がある場合、HTTP(S) ロードバランサはトラフィックをその他のリージョンに転送しません。
1 つの転送ルールで異なるリージョンを組み合わせるには、プレミアムティアの料金が必要です。料金と使用量の計算の詳細については、Network Service Tiers の料金をご覧ください。