【アップデート】Cloud Run でマルチリージョン対応の自動フェイルオーバーとフェイルバック機能がGAされました
はじめに
こんにちは。
クラウド事業本部コンサルティング部の渡邉です。
2026年6月29日、Cloud Run でマルチリージョン対応の自動フェイルオーバーとフェイルバック機能が General Availability (GA) になりました。
今年の2月にPreviewでリリースされた機能の待望のGAになるかと思います。
これまで、Cloud Run はサーバーレスの手軽さとスケーラビリティが魅力の一方、リージョン障害時のフェイルオーバーには、手動でグローバル外部アプリケーションロードバランサの URL マップを変更する操作が必要でした。今回の GA により、readiness probeを活用した自動フェイルオーバー機能が正式サポートとなり、Cloud Run でマルチリージョン構成を組みたいエンタープライズ向けの高可用性アーキテクチャを構築できるようになりました。
本記事では、Cloud Run のマルチリージョン自動フェイルオーバーとフェイルバック機能の概要と、実際に試してみた手順をご紹介します。
Cloud Run service health とは
Cloud Run service health は、各リージョンの Cloud Run サービスの集約的な健全性（health）を Serverless Network Endpoint Groups (NEGs) 経由でロードバランサーに公開する仕組みです。
自動フェイルオーバーの仕組み
自動フェイルオーバーの仕組みについては以下になります。
フェイルオーバーのアーキテクチャ図
- 各コンテナインスタンスがreadiness probeを実行
- Cloud Run がリージョン単位でサービスの健全性を集約
- リージョンが不健全になると、ロードバランサーが自動的にトラフィックを健全なリージョンへ切り替え
- 障害リージョンが回復すると、段階的にトラフィックが戻る
外部トラフィックにはグローバル外部 Application ロードバランサー、内部トラフィックにはクロスリージョン内部 Application ロードバランサーを使用することができます。
制限事項
Cloud Run のサービスの健全性には、以下の制限事項が存在するため、確認してから設計してください。
| 制限事項 | 詳細 |
|---|---|
| 最小インスタンス数 | ヘルスチェック実行のため、各リージョンで最小1インスタンス以上の設定が必須になります |
| 最低リージョン数 | フェイルオーバーには異なるリージョンのサービスが最低2つ必要です。 |
| NEG バックエンド上限 | 1ロードバランサーあたり最大5つの Serverless NEG バックエンドまでの制限があります |
| URL マスク/タグ | Serverless NEG での URL マスクやタグ設定はできません |
| IAP | バックエンドサービスやロードバランサーからの IAP 有効化はできません。Cloud Run から直接有効化する必要があります |
| サービス削除 | Cloud Run サービスを削除しても、ロードバランサーへの不健全ステータスは通知されません |
実際に試してみる
公式ドキュメントのチュートリアルに沿って、2リージョン（us-west1、europe-west1）での高可用性 Cloud Run サービスを構築します。
前提条件
- Google Cloud プロジェクト
- 以下の API が有効化済み：Artifact Registry、Cloud Build、Cloud Run Admin API、Network Services API、Compute Engine
- gcloud CLI インストール済み
- Cloud Build サービスアカウントに
roles/run.builderロールが付与済み
1. 変数の設定
検証で使用する構成変数を設定していきます。
export PROJECT_ID=YOUR_PROJECT_ID
gcloud config set core/project $PROJECT_ID
export SERVICE=health-example
export REGION_A=us-west1
export REGION_B=europe-west1
2. サンプルアプリケーションの準備
公式でサンプルのGo アプリケーションが公開されているので、こちらをCloud Runへデプロイして検証していきます。
# サンプルリポジトリのクローン
git clone https://github.com/GoogleCloudPlatform/golang-samples
# Cloud Run service-health サンプルディレクトリへ移動
cd golang-samples/run/service-health
3. 2リージョンへのデプロイ（readiness probe付き）
サンプルアプリケーションをus-west1 と europe-west1 にreadiness probe付きでデプロイしていきます。
gcloud beta run deploy $SERVICE \
--source=. \
--regions=$REGION_A,$REGION_B \
--min=10 \
--readiness-probe httpGet.path="/are_you_ready"
Allow unauthenticated invocations to [health-example] (y/N)? Y
Building using Buildpacks and deploying container to Cloud Run service [health-example] in project [YOUR_PROJECT_ID] regions [us-west1,europe-west1]
✓ Building and deploying new Multi-Region service... Done.
✓ Validating configuration...
✓ Uploading sources...
✓ Building Container... Logs are available at [ https://console.cloud.google.com/cloud-build/builds;region=us-west1/YOUR_BUILD_ID?project=YOUR_PROJECT_NUMBER ].
✓ Creating Revision in region: us-west1 https://health-example-YOUR_PROJECT_NUMBER.us-west1.run.app
✓ Creating Revision in region: europe-west1 https://health-example-YOUR_PROJECT_NUMBER.europe-west1.run.app
✓ Setting IAM Policy... Setting IAM policy for region europe-west1
Done.
Multi-Region Service [health-example] has been deployed to regions ['us-west1', 'europe-west1'].
Regional URLs:
https://health-example-YOUR_PROJECT_NUMBER.us-west1.run.app (us-west1)
https://health-example-YOUR_PROJECT_NUMBER.europe-west1.run.app (europe-west1)
デプロイが完了しました。コンソール画面からもus-west1とeurope-west1リージョンのマルチリージョン構成でデプロイされていることが確認できます。
4. グローバル外部 Application ロードバランサーのセットアップ
マルチリージョン構成でデプロイしたCloud Runのそれぞれのリージョンにトラフィックをルーティングしたいので、グローバル外部 Application ロードバランサーを作成していきます。
バックエンドサービスの作成
gcloud compute backend-services create $SERVICE-bs \
--load-balancing-scheme=EXTERNAL_MANAGED \
--global
Created [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/global/backendServices/health-example-bs].
NAME BACKENDS PROTOCOL
health-example-bs HTTP
グローバル静的 IP アドレスの確保
gcloud compute addresses create $SERVICE-ip \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global
Created [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/global/addresses/health-example-ip].
URL マップの作成
gcloud compute url-maps create $SERVICE-lb \
--default-service $SERVICE-bs
Created [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/global/urlMaps/health-example-lb].
NAME DEFAULT_SERVICE
health-example-lb backendServices/health-example-bs
ターゲット HTTP プロキシの作成
gcloud compute target-http-proxies create $SERVICE-hp \
--url-map=$SERVICE-lb
Created [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/global/targetHttpProxies/health-example-hp].
NAME URL_MAP
health-example-hp health-example-lb
フォワーディングルールの作成
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
Created [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/global/forwardingRules/health-example-fr].
5. Serverless NEG の追加
Cloud Runをグローバル外部 Application ロードバランサーの背後に配置するためには、Serverless NEGが必要になるので、us-west1 と europe-west1 リージョンにそれぞれ作成して、バックエンド サービスに追加していきます。
# us-west1 の NEG 作成
gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_A \
--region $REGION_A \
--network-endpoint-type=serverless \
--cloud-run-service=$SERVICE
# europe-west1 の NEG 作成
gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_B \
--region $REGION_B \
--network-endpoint-type=serverless \
--cloud-run-service=$SERVICE
# バックエンドサービスへの追加（us-west1）
gcloud compute backend-services add-backend $SERVICE-bs \
--global \
--network-endpoint-group=$SERVICE-neg-$REGION_A \
--network-endpoint-group-region=$REGION_A
# バックエンドサービスへの追加（europe-west1）
gcloud compute backend-services add-backend $SERVICE-bs \
--global \
--network-endpoint-group=$SERVICE-neg-$REGION_B \
--network-endpoint-group-region=$REGION_B
Created [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/regions/us-west1/networkEndpointGroups/health-example-neg-us-west1].
Created network endpoint group [health-example-neg-us-west1].
Created [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/regions/europe-west1/networkEndpointGroups/health-example-neg-europe-west1].
Created network endpoint group [health-example-neg-europe-west1].
Updated [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/global/backendServices/health-example-bs].
Updated [https://www.googleapis.com/compute/v1/projects/YOUR_PROJECT_ID/global/backendServices/health-example-bs].
ロードバランサーの詳細画面では、バックエンドサービス health-example-bs に us-west1 と europe-west1 の2つの Serverless NEG がバックエンドとして登録されていることが確認できます。
ロードバランサーの詳細画面
直近Previewでリリースされたバックエンドサービスの Resource View では、転送ルール → ターゲット HTTP プロキシ → URL マップ → バックエンドサービス → 2つの Serverless NEG という一連のリソース構成が視覚的に確認できます。
バックエンドサービスの Resource View
6. フェイルオーバーのテスト
準備ができたのでフェイルオーバーのテストをしていきます。
まずは、作成したロードバランサーの IP アドレスを取得します。
LBIP=$(gcloud compute addresses describe $SERVICE-ip --global --format='value(address)')
echo $LBIP
取得した IP アドレスに http://<LOAD_BALANCER_IP> でサンプルアプリケーションにアクセスします。Serving from us-west1 と表示され、readiness probe が HEALTHY であることが確認できます。Serving regions for this service セクションでは、europe-west1 が 3/3、us-west1 が 9/9 のインスタンスがすべて HEALTHY な状態です。
初期状態のサンプルアプリ
次に、europe-west1 の Toggle Unhealthy ボタンをクリックしてリージョン障害をシミュレートします。europe-west1 の Healthy Instances が 0/3 となり、すべてのインスタンスが UNHEALTHY に変わりました。ロードバランサーはこの状態を検知し、自動的に us-west1 のみにトラフィックをルーティングします。ページには引き続き Serving from us-west1 と表示されており、ユーザーへのサービスが継続されていることが確認できました。europe-west1 のHealthy Instances が回復後は、europe-west1にもルーティングされるようになりました。
フェイルオーバー後のサンプルアプリ
まとめ
今回のアップデートにより、Cloud Run のマルチリージョン高可用性と自動フェイルオーバー機能が GA となりました。これまでサーバーレスアーキテクチャでは難しかった「リージョン障害への自動対応」が、readiness probeと Serverless NEG の組み合わせによってシンプルに実現できるようになりました。
このアーキテクチャは、ダウンタイムを許容できないミッションクリティカルなサービスや、グローバルユーザー向けに低レイテンシを維持したいアプリケーションに特に有効です。最小インスタンス数の設定は必須ですが、フェイルオーバーを実現できる恩恵を考えれば十分に価値ある投資になると思います。
Cloud Run で高可用性アーキテクチャを検討している方は、ぜひ公式のチュートリアルを試してみてください。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部コンサルティング部の渡邉でした!
