Cloud Run サービスの健全性を使用してクロスリージョン フェイルオーバーを自動化する

このドキュメントでは、自動フェイルオーバーとフェイルバック機能を備えた高可用性のマルチリージョン Cloud Run サービスを構成してデプロイする方法について説明します。

Cloud Run Service Health は、サーバーレス ネットワーク エンドポイント グループ（NEG）を使用して、各リージョンのサービスの集約されたヘルスを公開します。

• パブリック（外部）トラフィックをルーティングするには、グローバル外部アプリケーション ロードバランサを使用して Service Health を構成します。

• プライベート（内部）トラフィックをルーティングするには、クロスリージョン内部アプリケーション ロードバランサを使用して Service Health を構成します。

仕組み

自動フェイルオーバーは、グローバル外部アプリケーション ロードバランサまたはクロスリージョン内部アプリケーション ロードバランサからの受信リクエストを、リージョン サーバーレス NEG を介して Cloud Run サービスにルーティングします。個々のコンテナ インスタンスは readiness プローブを実行します。Cloud Run はこれを集計して、各リージョン サービスの全体的な健全性ステータスを判断します。

リージョン内の Cloud Run サービスは、インスタンスの 60% 以上が readiness プローブに合格すると、正常な状態になり、トラフィックを受信します。リージョンが異常な状態になると、ロードバランサはトラフィックを正常なリージョンに自動的に再ルーティングします。異常なリージョンが回復すると、ロードバランサはトラフィックを徐々に復元します。

制限事項

Cloud Run の Service Health には、次の制限が適用されます。

• 健全性を計算するには、リージョンごとにサービスレベルまたはリビジョン レベルの最小インスタンス数を 1 つ以上構成する必要があります。Cloud Monitoring のコンテナ インスタンス数指標を使用して、リージョンに必要な最小インスタンス数を推定することもできます。
• フェイルオーバーには、異なるリージョンのサービスが少なくとも 2 つ必要です。そうでない場合、1 つのサービスが失敗すると、エラー メッセージ no healthy upstream が表示されます。
• サーバーレス NEG で URL マスクやタグを構成することはできません。
• Cloud Run サービスが削除されると、Cloud Run はロードバランサに異常なステータスを報告しません。
• 新しいインスタンスの起動では最初の準備状況プローブはカウントされないため、リクエストは、正常な状態になる前に、新しく起動されたサービスに短時間ルーティングされる可能性があります。
• Cloud Run の Service Health は、すべてのインスタンスで計算されます。プローブのないリビジョンと、最初の準備状況プローブを完了していない新しく起動されたインスタンスは、不明として扱われます。リビジョン間のすべてのトラフィックの移行中に、新しいインスタンスが起動して最初の readiness プローブを完了するまで、Service Health が UNKNOWN を一時的に報告することがあります。ロードバランサは、不明なインスタンスを正常と見なします。
• インスタンスが急速にクラッシュしている場合、Service Health の計算で不正確な結果が生成される可能性があります。

ベスト プラクティス

準備状況プローブ、トラフィック分割、最小インスタンスを組み合わせて使用すると、安全かつ段階的なロールアウトを実行できます。これにより、新しいリビジョンを昇格させる前に単一の「カナリア」リージョンで健全性を確認し、ロードバランサが正常なリージョン バックエンドにのみトラフィックを送信するようにします。

独自のアプリケーションでプローブを構成する場合は、プローブに応答するために、サービスコードに HTTP/1 エンドポイント（HTTP/2 ではなく Cloud Run のデフォルト）を追加します。エンドポイント名（/startup、/health、/are_you_ready など）は、プローブ構成の path と一致する必要があります。HTTP ヘルスチェック エンドポイントは外部からアクセスでき、外部に公開される他の HTTP サービス エンドポイントと同じ原則に従います。

推奨されるロールアウト プロセス

準備状況プローブまたは Cloud Run サービスの健全性を使用していない既存の Cloud Run サービスにサービス リビジョンをロールアウトできます。このプロセスをリージョンごとに 1 つずつ実行して、新しいリビジョンを安全にデプロイします。

1. 準備状況プローブが構成された単一の「カナリア」リージョンに新しいリビジョンをデプロイします。

2. 新しいリビジョンに少量のトラフィック（1% など）を送信します。

3. 最小インスタンス数には、リビジョン レベルではなくサービスレベルでゼロ以外の値を使用します。

4. 準備状況プローブ指標（run.googleapis.com/container/instance_count_with_readiness）を調べて、新しいインスタンスが正常であることを確認します。

5. 段階的に、新しいリビジョンへのトラフィックの割合を増やします。ランプアップするときは、ロードバランサで使用されるリージョン Cloud Run サービスの健全性指標（run.googleapis.com/service_health_count）をモニタリングします。十分なトラフィックが新しいリビジョンに転送されるまで、Cloud Run サービスの健全性は UNKNOWN を返します。

6. リビジョンが 100% のトラフィックを受信し、リージョン Cloud Run サービスの Service Health が安定して正常になったら、他のすべてのリージョンでこのプロセスを繰り返します。

すでに Cloud Run Service Health を使用しているサービスの場合は、リージョン間で 2 段階のロールアウトを並行して実行することで、UNKNOWN の報告を回避できます。

1. トラフィックの一部を新しいリビジョンにルーティングします。新しいインスタンスが起動し、readiness プローブに合格するまで待ちます。

2. トラフィックの 100% を新しいリビジョンにルーティングします。

チュートリアル: 自動フェイルオーバーを構成する

このチュートリアルでは、サンプル Go アプリケーションを 2 つのリージョンにデプロイし、サーバーレス NEG を使用してグローバル外部アプリケーション ロードバランサを設定して、自動フェイルオーバーをテストします。

このチュートリアルの内容は次のとおりです。

1. サンプル アプリケーションを準備する
2. 2 つのリージョンに readiness プローブを使用して Cloud Run サービスをデプロイする
3. グローバル外部アプリケーション ロードバランサを設定する
4. サーバーレス NEG を介してサービスを追加する
5. フェイルオーバーをテストする

このドキュメントでは、課金対象である次の Google Cloudコンポーネントを使用します。

• Artifact Registry
• Cloud Build
• Compute Engine
• Cloud Load Balancing
• Cloud Run
• Cloud Storage

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

新規の Google Cloud ユーザーの方は、無料トライアルをご利用いただける場合があります。

Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオで Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. Artifact Registry、Cloud Build、Cloud Run Admin API、Network Services API、Compute Engine API を有効にします（まだ有効になっていない場合）。

   API を有効にするために必要なロール

   API を有効にするには、serviceusage.services.enable 権限が必要です。プロジェクトを作成した場合は、オーナーロール（roles/owner）を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール（roles/serviceusage.serviceUsageAdmin）を介してこの権限を取得できます。ロールを付与する方法を学習する。

   API を有効にする

2. gcloud CLI をインストールして初期化します。
3. コンポーネントを更新します。

   gcloud components update

4. このチュートリアルで使用する構成変数を設定します。

   PROJECT_ID= gcloud config set core/project PROJECT_ID
   PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
   SERVICE=health-example
   REGION_A=us-west1
   REGION_B=europe-west1

   PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

必要なロールを設定する

ビルドを使用してソースからデプロイするには、ユーザーまたは管理者が Cloud Build サービス アカウントに次の IAM ロールを付与する必要があります。

クリックして Cloud Build サービス アカウントに必要なロールを表示

この動作をオーバーライドしない限り、Cloud Build は、ソースコードと Cloud Run リソースのビルドにデフォルトの Cloud Build サービス アカウントとして Compute Engine のデフォルトのサービス アカウントを自動的に使用します。Cloud Build がソースをビルドできるようにするには、プロジェクトの Compute Engine のデフォルトのサービス アカウントに Cloud Run ビルダー（roles/run.builder）を付与するよう管理者に依頼します。

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:[e-mail] \
      --role=roles/run.builder
  

PROJECT_NUMBER は Google Cloudプロジェクト番号に、PROJECT_ID は Google Cloudプロジェクト ID に置き換えます。プロジェクト ID とプロジェクト番号を確認する方法については、プロジェクトの作成と管理をご覧ください。

Compute Engine のデフォルト サービス アカウントに Cloud Run ビルダーのロールを付与すると、反映されるまでに数分かかることがあります。

注:

iam.automaticIamGrantsForDefaultServiceAccounts 組織のポリシーの制約により、編集者のロールはデフォルトのサービス アカウントに自動的に付与されません。2024 年 5 月 3 日より後に組織を作成した場合、この制約はデフォルトで適用されます。

この制約を適用して、ロールの自動付与を無効にすることを強くおすすめします。ロールの自動付与を無効にする場合は、デフォルトのサービス アカウントに付与するロールを決定し、ご自身でこれらのロールを付与する必要があります。

デフォルトのサービス アカウントにすでに編集者ロールが設定されている場合は、編集者ロールを権限の低いロールに置き換えることをおすすめします。サービス アカウントのロールを安全に変更するには、Policy Simulator を使用して変更の影響を確認してから、適切なロールを付与または取り消す操作を行います。

ファイルと Cloud Storage バケットにアクセスするためにサービス ID に必要な権限を取得するには、サービス ID にストレージ管理者（roles/storage.admin）ロールを付与するよう管理者に依頼してください。Cloud Storage のロールと権限の詳細については、Cloud Storage の IAM をご覧ください。

Cloud Run に関連付けられている IAM ロールと権限のリストについては、Cloud Run IAM ロールと Cloud Run IAM 権限をご覧ください。Cloud Run サービスがGoogle Cloud APIs（Cloud クライアント ライブラリなど）と連携している場合は、サービス ID の構成ガイドをご覧ください。ロールの付与の詳細については、デプロイ権限とアクセスの管理をご覧ください。

サンプル アプリケーションを準備する

使用するコードサンプルを取得するには:

1. ローカルマシンにサンプル リポジトリのクローンを作成します。

   git clone https://github.com/GoogleCloudPlatform/golang-samples
   

2. Cloud Run のサンプルコードが含まれているディレクトリに移動します。

   cd golang-samples/run/service-health
   

注: 独自のアプリケーションを使用する場合は、プローブに応答するために、サービスコードに HTTP/1 エンドポイント（HTTP/2 ではなく Cloud Run のデフォルト）を追加します。エンドポイント名（/startup、/health、/are_you_ready など）は、プローブ構成の path と一致する必要があります。HTTP ヘルスチェック エンドポイントは外部からアクセスでき、外部に公開される他の HTTP サービス エンドポイントと同じ原則に従います。

readinessProbe を使用して 2 つのリージョンに Cloud Run サービスをデプロイする

フェイルオーバーには、異なるリージョンのサービスが少なくとも 2 つ必要です。readiness プローブを使用して 2 つの異なるリージョンにソースからサービスをデプロイするには、次のコマンドを実行します。Terraform を使用する場合は、マルチリージョン サービスをデプロイするを参照し、readiness probe の構成を追加してください。

1. ソース ディレクトリから us-west1 と europe-west1 にサービス health-example をデプロイします。readiness プローブを使用して Service Health を構成するには、少なくとも 1 つの最小インスタンスが必要です。

   gcloud run deploy $SERVICE \
   --source=. \
   --regions=$REGION_A,$REGION_B \
   --min=10 \
   --readiness-probe httpGet.path="/are_you_ready"
   

2. プロンプトが表示されたら、「y」と応答して、必要な API をインストールします。これが必要なのはプロジェクトに対して 1 回だけです。始める前にセクションに記載されているように、デフォルト値を設定しない場合は、別のプロンプトにプラットフォームとリージョンを指定して応答します。

グローバル外部アプリケーション ロードバランサを設定する

us-west1 と europe-west1 の間でトラフィックをルーティングするようにグローバル外部アプリケーション ロードバランサを設定するには、次の手順を行います。Terraform を使用してロードバランサをプロビジョニングする場合は、グローバル外部アプリケーション ロードバランサを作成するをご覧ください。

1. バックエンド サービスを作成します。

   gcloud compute backend-services create $SERVICE-bs \
     --load-balancing-scheme=EXTERNAL_MANAGED \
     --global
   

2. ロードバランサにアクセスするためのグローバル静的外部 IP アドレスを設定します。

   gcloud compute addresses create $SERVICE-ip \
     --network-tier=PREMIUM \
     --ip-version=IPV4 \
     --global
   

3. 受信リクエストをバックエンド サービスに転送するための URL マップを作成します。

   gcloud compute url-maps create $SERVICE-lb \
     --default-service $SERVICE-bs
   

4. 作成した URL マップにリクエストをルーティングするターゲット HTTP プロキシを作成します。

   gcloud compute target-http-proxies create $SERVICE-hp \
   --url-map=$SERVICE-lb
   

5. 受信リクエストをプロキシに転送する転送ルールを作成します。

   gcloud compute forwarding-rules create $SERVICE-fr \
     --load-balancing-scheme=EXTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --address=$SERVICE-ip \
     --target-http-proxy=$SERVICE-hp \
     --global \
     --ports=80
   

サーバーレス NEG を介してサービスを追加する

サーバーレス NEG を使用して us-west1 と europe-west1 にデプロイしたサービスを追加する手順は次のとおりです。Terraform を使用してサーバーレス NEG をプロビジョニングする場合は、リージョン ネットワーク エンドポイント グループを構成するをご覧ください。

1. us-west1 と europe-west1 に Cloud Run サービスのサーバーレス ネットワーク エンドポイント グループ（NEG）を作成します。

   gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_A \
       --region $REGION_A \
       --network-endpoint-type=serverless \
       --cloud-run-service=$SERVICE
   

   gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_B \
       --region $REGION_B \
       --network-endpoint-type=serverless \
       --cloud-run-service=$SERVICE
   

2. サーバーレス NEG をバックエンドとして us-west1 と europe-west1 のバックエンド サービスに追加します。

   gcloud compute backend-services add-backend $SERVICE-bs \
       --global \
       --network-endpoint-group=$SERVICE-neg-$REGION_A \
       --network-endpoint-group-region=$REGION_A
   

   gcloud compute backend-services add-backend $SERVICE-bs \
       --global \
       --network-endpoint-group=$SERVICE-neg-$REGION_B \
       --network-endpoint-group-region=$REGION_B
   

その他の構成オプションについては、Cloud Run を使用してグローバル外部アプリケーション ロードバランサを設定するをご覧ください。

リージョンの健全性を報告する

リージョン Cloud Run サービスの健全性を集計し、正常または異常なステータスをロードバランサに報告するには、次の操作を行います。

1. 1 つ以上の最小インスタンスを使用して、複数のリージョンに Cloud Run サービス リビジョンをデプロイします。次のコマンドを実行して、前の手順で構成した準備状況プローブを使用します。

   gcloud run deploy SERVICE_NAME \
   --regions=REGION_A,REGION_B \
   --min=MIN_INSTANCES

   次のように置き換えます。

   • SERVICE_NAME: サービスの名前。
   • REGION_A、REGION_B: サービス リビジョンの異なるリージョン。たとえば、REGION_A を us-central1 に、REGION_B を europe-west1 に設定します。
   • MIN_INSTANCES: ウォーム状態を維持し、リクエストを受信できるコンテナ インスタンスの数。最小値は 1 以上に設定する必要があります。

2. 各コンテナ インスタンスに設定された gRPC または HTTP 準備状況プローブを構成します。

3. グローバル外部アプリケーション ロードバランサまたはクロスリージョン内部アプリケーション ロードバランサを構成して、異常なリージョンからトラフィックを転送します。

4. 各リージョンの各 Cloud Run サービスにサーバーレス NEG を設定します。

5. サーバーレス NEG と接続するようにバックエンド サービスを構成します。

readiness プローブを使用してサンプル Cloud Run アプリケーションを 2 つのリージョンにデプロイする方法を学習する。

フェイルオーバーをテストして検証する

Cloud Run サービスの信頼性と復元性を確保するためにフェイルオーバーをテストする手順は次のとおりです。

1. 次のコマンドを実行して、ロードバランサの IP アドレスを取得します。

   LBIP=$(gcloud compute addresses describe $SERVICE-ip --global --format='value(address)')
   

2. 省略可: サービスで認証が必要な場合は、ロードバランサにリクエストを送信します。

   curl  -H "Authorization: Bearer $(gcloud auth print-identity-token)" $LBIP
   

3. echo $LBIP コマンドを実行して、LBIP 変数の値を取得します。これにより、ロードバランサの IP アドレスが出力されます。例: 11.22.33.44

4. フェイルオーバーをテストするには、http://LOAD_BALANCER_IP URL に移動します。ここで、LOAD_BALANCER_IP は前の手順で取得した値です。[Serving Regions] セクションで、お住まいの地域の切り替えボタンをクリックします。これにより、正常なリージョンとトラフィックを処理するインスタンスが指定されます。

   

成功: 外部トラフィックの自動フェイルオーバーとフェイルバックを備えた高可用性のマルチリージョン Cloud Run サービスがデプロイされました。

ヘルスチェックをモニタリングする

Cloud Run サービスの健全性を設定すると、サーバーレス NEG は Cloud Monitoring サービスの健全性指標を収集します。既存のリージョン サービスの健全性ステータスを表示できます。

リージョンのサービスが異常な状態の場合、ロードバランサは異常なリージョンから正常なリージョンにトラフィックを転送します。リージョンが再び正常になると、トラフィックは回復します。

マルチリージョン デプロイで認証済みの Pub/Sub push サブスクリプションを使用する

デフォルトでは、Pub/Sub サービスは Pub/Sub サービスがメッセージを格納するのと同じ Google Cloud リージョン内の push エンドポイントにメッセージを配信します。この動作を回避するには、マルチリージョンの Cloud Run デプロイで認証済みの Pub/Sub push サブスクリプションを使用するをご覧ください。

代替手段: 手動フェイルオーバーを構成する

プローブに依存せずに正常なリージョンにフェイルオーバーするようにトラフィックを手動で構成する必要がある場合は、グローバル外部アプリケーション ロードバランサの URL マップを変更します。

1. グローバル外部アプリケーション ロードバランサの URL マップを更新するには、--global フラグを使用して、バックエンド サービスから NEG を削除します。

   gcloud compute backend-services remove-backend BACKEND_NAME \
   --network-endpoint-group=NEG_NAME \
   --network-endpoint-group-region=REGION \
   --global
   

   次のように置き換えます。

   • BACKEND_NAME: バックエンド サービスの名前。
   • NEG_NAME: ネットワーク エンドポイント グループ リソースの名前（例: myservice-neg-uscentral1）。
   • REGION: NEG が作成され、サービスを削除するリージョン。例: us-central1,asia-east1

2. 正常なリージョンがトラフィックを処理していることを確認するには、https://<domain-name> に移動します。

Google Cloud アカウントで追加料金が発生しないようにするには、このチュートリアルでデプロイしたすべてのリソースを削除します。

プロジェクトを削除する

このチュートリアル用に新規プロジェクトを作成した場合は、そのプロジェクトを削除します。既存のプロジェクトを使用し、このチュートリアルで行った変更を加えずに残す場合は、チュートリアル用に作成したリソースを削除します。

課金をなくす最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除するには:

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。既存のプロジェクトを使用してこのドキュメントのタスクを行った場合、そのプロジェクトを削除すると、プロジェクト内で行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（例: appspot.com）を保持するには、プロジェクト全体ではなく、プロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

1. Google Cloud コンソールで [リソースの管理] ページに移動します。

   [リソースの管理] に移動

2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

チュートリアル リソースの削除

1. このチュートリアルでデプロイした Cloud Run サービスを削除します。Cloud Run サービスの費用は、リクエストを受け取るまでは発生しません。

   Cloud Run サービスを削除するには、次のコマンドを実行します。

   gcloud run services delete SERVICE-NAME

   SERVICE-NAME は、サービスの名前に置き換えます。

   Cloud Run サービスは Google Cloud コンソールで削除することもできます。

2. チュートリアルの設定時に追加した gcloud のデフォルトのリージョン構成を削除します。

    gcloud config unset run/region
   

3. プロジェクト構成を削除します。

    gcloud config unset project
   

---

次のステップ

• Cloud Run サービスのヘルスチェックの構成の詳細を確認する。
• Cloud Run を使用したグローバル外部アプリケーション ロードバランサの設定の詳細を確認する。
• Spanner マルチリージョンや Cloud Storage のロケーションなど、他のプロダクトのマルチリージョン構成を確認する。