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

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

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-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=GATEWAY_ID
```
次に例を示します。
```
gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg-eu \
  --region=europe-west1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-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 create BACKEND_SERVICE_NAME \
  --global \ 
```
```
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 つのバックエンドサービスのみを対象としているため、ホストルールやパスマッチャーは必要ありません。複数のバックエンドサービスを対象とする場合、ホストルールを使用して、ホスト名に基づいてリクエストを特定のサービスに転送できます。パスマッチャーを使用して、リクエストパスに基づいてリクエストを特定のサービスに転送します。

次に例を示します。
```
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 の料金をご覧ください。

ベストプラクティス

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