Google Cloud Run、自動フェイルオーバー機能が一般提供開始――オランダのデータセンター大規模停電から6日後の発表
2026年7月22日 18:15
Googleは、サーバーレスサービス「Cloud Run」において、手動介入なしで自動的にクロスリージョンフェイルオーバーを実行できる「サービスヘルス（Service Health）」機能の一般提供（GA）を開始した。この機能は、オランダのデータセンターで発生した大規模な停電事故からわずか6日後にリリースされ、マルチリージョンでサーバーレスワークロードを運用する企業にとって可用性向上の強力な手段となる。追加のプラットフォーム利用料は発生せず、すべてのCloud Runリージョンで即座に利用可能だ。
■オランダの停電事故と絶妙なタイミングでのGAリリース
Googleは今週、Cloud Runのサービスヘルス（Service Health）機能を一般提供（GA）に移行した。これにより、マルチリージョンのサーバーレスワークロードを実行している組織は、手動の介入なしに、自動的なクロスリージョンフェイルオーバーを利用できるようになる。追加料金は、レディネスプローブ（readiness probes）の実行中に消費されるCPUとメモリの標準コストのみである。
このリリースのタイミングは、非常に示唆に富んでいる。2026年7月15日午後7時57分（東部時間、日本時間7月16日午前8時57分）、オランダにあるGoogleのデータセンターで停電が発生し、europe-west4-aアベイラビリティゾーンが約15時間にわたってオフラインになった。この影響で、Google Cloud VMware Engine、Bare Metal Solution、Google Cloud NetApp Volumesのサービスが翌朝に復旧するまで影響を受けた。上流の電力網における電気的障害が、配電設備と冷却インフラの両方に混乱をもたらし、Googleは熱による損傷を防ぐためにホストサーバー、ストレージクラスター、ネットワークスイッチのシャットダウンを余余儀なくされた。Cloud Runのサービスヘルス機能がGAとなったのは、そのわずか6日後のことだった。この時間差は、単なる偶然というよりも、障害イベントによってリリーススケジュールが加速された結果のように見える。
Cloud Run自体は、このオランダでの障害による直接的な影響を受けなかった。しかし、このアウトブレイクは、クロスリージョンフェイルオーバーがまさに防ぐために設計された障害モードを実証する形となった。つまり、保護されていないシングルリージョン構成や、不適切に構成されたマルチリージョン構成では、手動の介入や設計されたフェイルオーバーメカニズムなしには乗り切れない、地域的なサービス停止という事態である。
■レディネスプローブとサービスヘルス集約による自動検知の仕組み
この機能は、順次動作する2つのコンポーネントに基づいている。それは、インスタンスレベルでの「レディネスプローブ（readiness probes）」と、リージョンレベルでの「サービスヘルス集約（service health aggregation）」である。
レディネスプローブは、個々のコンテナインスタンスに対して定期的に実行されるHTTPチェックである。プローブが失敗すると、Cloud Runはそのインスタンスへのトラフィックのルーティングを停止する。これは、インスタンス自体を完全に再起動させる「ライブネスプローブ（liveness probes）」とは異なる。リージョン内のより多くのインスタンスでレディネスチェックが失敗すると、プローブの失敗率が上昇する。
サービスヘルスは、これらを集約するレイヤーである。Cloud Runは、インスタンスごとのレディネス信号を、各デプロイメントの単一のリージョンヘルスステータスへと継続的に集約する。この集約されたヘルスステータスは、サーバーレスネットワークエンドポイントグループ（NEG）を介して公開される。NEGは、特定のIPアドレスではなく、Cloud Runサービスを指し示すロードバランサーのバックエンド構成リソースである。
グローバル外部アプリケーションロードバサーが、リージョンのNEGが異常（Unhealthy）ステータスを報告していることを検出すると、自動的にトラフィックを正常なリージョンに迂回させる。そして、異常のあったリージョンが回復すると、徐々にトラフィックを元に戻す。これらの一連の動作にオペレーターの介入は不要である。Googleは、この初期設定を、最小インスタンス数を有効にしてレディネスプローブを追加するだけの「2クリック」の構成であると説明している。
■Kubernetesとの比較：サーバーレスにおける課題の克服
今回のGA以前、Cloud Runには、マネージドKubernetesではなくサーバーレスを選択したエンジニアが暗黙的に受け入れていた、特定のアーキテクチャ上のギャップが存在していた。それは、リージョン全体のサービスヘルスをグローバルロードバランサーに公開するネイティブな仕組みが存在しなかったことである。
サービスヘルス機能がないマルチリージョンのCloud Runデプロイメントでは、リクエストは常にユーザーに地理的に最も近いリージョンにルーティングされていた。そのリージョンのCloud Runサービスが失敗し始めても、トラフィックはそこに送信され続けた。ロードバランサーには、それを検知して動作を切り替えるための信号がなかったからである。ダッシュボードを監視しているオペレーターがエラー率の上昇に気づき、手動でグローバルロードバランサーのURLマップを変更してトラフィックをリダイレクトする必要があった。このプロセスには数分を要し、その間、ユーザー向けのリクエストは失敗し続けていた。
Google Kubernetes Engine（GKE）のオペレーターであれば、KubernetesのヘルスチェックとIngress構成を使用して自動的なクロスリージョンフェイルオーバーを構築できたが、それには大幅に多くのインフラ構築と専門知識が必要だった。Cloud Runのサービスヘルス機能は、この格差を解消するものである。サーバーレスデプロイメントにおいて、Kubernetesよりも劇的にシンプルな設定モデルで、同等のネイティブ機能が利用可能になったとGoogleは主張している。
■パブリック・プライベート双方に対応、ただし制限事項も
この機能は、インターネット向けおよび内部向けのトラフィックの両方に対応しているが、使用するロードバランサーのレイヤーが異なる。
パブリックAPIやウェブサイトの場合、GoogleはCloud Runとグローバル外部アプリケーションロードバランサーの組み合わせを推奨している。プライベートネットワーク内の内部トラフィックのみを処理するワークロードの場合、同じメカニズムがクロスリージョン内部アプリケーションロードバランサーを介して動作する。どちらの場合も、目的は同じである。リージョンサービスの問題が検出された瞬間に、オペレーターが介入する前にトラフィックを自動的に移行することである。
Googleは、この機能を「アクティブ・アクティブ」構成（2つ以上のリージョンが同時にアクティブなトラフィックを処理している状態）向けに設計した。この構成では、正常なリージョンが隣接リージョンのトラフィック負荷を吸収できるため、アクティブ・パッシブ構成で問題となる「コールドスタート」による遅延を回避できる。アクティブ・パッシブ構成では、待機リージョンがゼロにスケールダウンしている可能性があり、トラフィックを受信する前にコンテナインスタンスを起動する必要があるためである。
ただし、ドキュメント化された制限事項も存在する。この機能は、ロードバランサーあたり最大5つのサーバーレスNEGバックエンドをサポートする。Identity-Aware Proxy（IAP）は、ロードバランサーレイヤーからではなく、Cloud Runから直接有効にする必要がある。また、Cloud Runサービスが削除された場合、プラットフォームはロードバランサーに異常ステータスを報告しないため、サービスの削除によってフェイルオーバーがトリガーされることはない。さらに、レディネスプローブが構成されていないリビジョンは「ヘルス不明（health unknown）」として扱われ、ロードバランサーは不明なインスタンスを正常とみなすため、プローブが設定されていないリビジョンは、実際に失敗していてもトラフィックを受信し続けることになる。
■アプリ層のフェイルオーバーが解決しない「データベースの課題」
Googleは、この機能が達成できる境界線を明確に示している。Cloud Run層におけるアプリケーションレイヤーのフェイルオーバーは、3層アーキテクチャの一部を解決するにすぎない。データベースレイヤーに独自のリージョン冗長性がなければ、アプリケーション層がどれほど迅速にフェイルオーバーしたとしても、真のリージョン障害が発生した場合にはデータの損失やサービスの停止が発生する。
3層アプリケーションにおいて、Googleはウェブ層とアプリケーション層で別々のマルチリージョンアーキテクチャを採用することを推奨している。これは、パブリックトラフィックと内部トラフィックで異なるルーティング要件を反映するためである。データ層においては、組織は目標復旧時点（RPO、最悪のシナリオでどの程度のデータ損失が許容されるか）を個別に評価し、それに応じてデータベース製品を選択する必要がある。
Googleのマネージドサービス自体はこれをサポートしている。Firestore、Spanner、Cloud Storage、Cloud SQLはすべて、Cloud Runのサービスヘルスと組み合わせることができるクロスリージョン構成を備えている。書き込みアクティビティが多いアプリケーションにおいて、リージョン間でのデータ損失ゼロの同期は技術的に要求が高く、コストもかかる。これは、今回のCloud RunのGAリリース単体では解決できない、アーキテクチャ上の意思決定として残り続ける。
■専任インフラチームがなくても実現できる高可用性
Cloud Runのサービスヘルス機能の設計目標の一つは、専任のプラットフォームエンジニアリングチームを持たないチームでも利用できるようにすることである。マネージドKubernetesを使用したクロスリージョンフェイルオーバーの構築には、高度なインフラの専門知識、継続的な運用投資、そしてKubernetesのIngress構成への精通が必要だった。これに対し、Googleが説明するCloud Runのアプローチでは、最小インスタンス数を設定し、レディネスプローブのエンドポイントを構成するだけで済む。
これは大きな変化である。歴史的に、マルチリージョンの高可用性は、それを構築・維持できるエンジニアリング能力を持つ組織にのみ許されたアーキテクチャ上の特権であった。GAステータスになったことで、組織はSLAに裏打ちされた本番環境のコミットメントにおいて、この機能に正式に依存できるようになる。これは、今回の発表前のプレビュー期間中には明示的にサポートされていなかったことである。
この機能は現在、すべてのCloud Runリージョンにおいて、追加のプラットフォーム料金なしで利用可能である。
■注目ポイントQ&A
●Cloud Runのサービスヘルス機能は、どのようにしてリージョンの障害を検知しますか？
各Cloud Runサービス内のコンテナインスタンスが定期的にHTTPレディネスプローブを実行します。Cloud Runはこれらのレディネス状態をリージョン全体のヘルスステータスとして集約し、サーバーレスネットワークエンドポイントグループ（NEG）を介して公開します。グローバルロードバランサーがこのNEGを監視し、異常を検知すると自動的に正常なリージョンへトラフィックを迂回させます。
●この機能を有効にすれば、データベースの障害対策も自動的に行われますか？
いいえ、この機能はアプリケーション層（Cloud Runサービス自体）のみを対象としています。データベース層が単一リージョンで稼働している場合、アプリ層がフェイルオーバーしてもデータベースの読み書きは行えません。完全なリージョン耐性を実現するには、Cloud SpannerやCloud SQLのクロスリージョンレプリカなど、データベース層での個別対策が必要です。
●社内ネットワーク向けのプライベートなサービスでも利用できますか？
はい、利用可能です。インターネット向けのパブリックなトラフィックには「グローバル外部アプリケーションロードバランサー」を組み合わせ、社内ネットワーク内のプライベートなトラフィックには「クロスリージョン内部アプリケーションロードバランサー」を組み合わせることで、同様の自動フェイルオーバーを実現できます。
●導入にあたって注意すべき制限事項はありますか？
ロードバランサーあたり最大5つのサーバーレスNEGバックエンドという制限があります。また、レディネスプローブが設定されていないリビジョンは「ヘルス不明」とみなされ、異常が発生していてもトラフィックが送信され続けます。さらに、Cloud Runサービス自体が削除された場合は異常ステータスがロードバランサーに通知されないため、フェイルオーバーはトリガーされません。
元記事: Cloud Run Automated Failover Goes GA Six Days After Google’s Netherlands Power Cut