タグアーカイブ フェイルオーバー

  1. ホーム   /  タグ付きの投稿: "フェイルオーバー"
Cloud Runのマルチリージョン高可用性が強化、障害検知と自動復旧が数秒単位に
2026年7月21日 0

Cloud Runのマルチリージョン高可用性が強化、障害検知と自動復旧が数秒単位に

発表の概要

発表の概要

Google Cloudは2026年7月20日、Cloud Runにおけるマルチリージョン高可用性の機能強化を発表した。ミッションクリティカルなアプリケーションのダウンタイムは、企業の収益や評判に直結する問題だ。これに対処するため、Cloud Runは単一コマンドで複数リージョンに同一サービスを展開できる設計をとってきたが、今回のアップデートで障害検知と自動復旧の精度が大幅に向上している。

新たに導入された機能は「Readiness Probe」と「Service Health」の2つだ。インスタンスレベルの死活監視とリージョンレベルの健全性評価を組み合わせることで、リージョン障害が発生した際のトラフィック迂回が数秒単位で自動化される。

マルチリージョン高可用性を支える2つの新機能

マルチリージョン高可用性を支える2つの新機能
Readiness Probe（準備状況プローブ）
コンテナがトラフィックを処理できる状態かを検証するヘルスチェック。Cloud Runサービス内の各インスタンスの稼働状況を可視化し、異常があれば速やかに検知する。
↓
Service Health（サービス健全性）
Readiness Probeの結果を集約し、リージョン単位でサービスの健全性を評価する。この情報はサーバーレスNEG（ネットワークエンドポイントグループ）を通じてグローバルロードバランサに公開され、異常が確認されたリージョンへのトラフィックが自動的に停止される。
■ Readiness Probe　■ Service Health

Readiness Probeの役割は「個々のコンテナが外部リクエストを受け付けられる状態か」を確認することだ。この結果はCloud Runコンソールからもリージョン別に確認でき、どのリージョンでインスタンスが縮退しているかが一目で分かる。

Service Healthはこのプローブ結果をリージョン単位で集約するレイヤーにあたる。複数のヘルスチェック結果を「そのリージョンが正常に稼働しているかどうか」というひとつの評価に落とし込み、グローバルロードバランサがこの評価に基づいてルーティングを切り替える。この仕組みにより、障害発生時の手動オペレーションが原則不要になる。

パブリックとプライベートで異なる自動フェイルオーバーの経路

パブリックとプライベートで異なる自動フェイルオーバーの経路

自動フェイルオーバーを実現するには、トラフィックが流入してくるネットワーク層によってロードバランサの種類を選択する必要がある。Cloud Runは外部向けと内部向けで最適なバランサ構成を用意している。

パブリックインターネットアプリケーション
ユーザー → グローバル外部ALB → リージョンA NEG（正常）
ユーザー → グローバル外部ALB → リージョンB NEG（異常） ※自動迂回
ウェブサイトや一般公開API向け。グローバルな外部ロードバランサがトラフィックを受け、障害リージョンを除外してルーティングする。
プライベートネットワークアプリケーション
内部VPC → クロスリージョン内部ALB → リージョンA NEG（正常）
内部VPC → クロスリージョン内部ALB → リージョンB NEG（異常） ※自動迂回
社内システムやマイクロサービス間通信向け。VPC内に閉じた内部ロードバランサが同じ自動フェイルオーバー機能を提供する。
■ リクエスト元　■ 外部ALB　■ 内部ALB　■ 正常リージョン　■ 障害リージョン

この構成の利点は、どちらのパターンでもロードバランサ側が自動でService Healthを参照し、異常リージョンをルーティング対象から外してくれる点にある。手動でのDNS切り替えや手作業によるトラフィック操作が不要になるため、復旧までの時間が大幅に短縮される。

設計段階で押さえるべき3つのポイント

設計段階で押さえるべき3つのポイント

Service Healthの活用を前提にマルチリージョン構成を設計する際、見落としやすい検討項目が3つある。いずれも高可用性に直結するため、初期段階で整理しておくことが望ましい。

1 単一障害点の排除 全レイヤー（Web・アプリ・DB）を対象とする。3層アーキテクチャであればWeb層は外部ALB、アプリ層は内部ALBでそれぞれマルチリージョン化し、DB層にも冗長構成が求められる。
2 データレプリケーション リカバリポイント目標（RPO）の要件を明確にしたうえで、リージョン間でのデータ複製方針を決める。書き込みの多いワークロードはアクティブ-アクティブ同期が効果的だが、ゼロデータロスが必須かを先に判断する必要がある。
3 データレジデンシー 特定の国や地域にデータを置く必要がある場合、Firestore、Spanner、Cloud Storage、Cloud SQLなどGoogle Cloudのマルチリージョン対応データベースを選定する。これらはCloud Runとの相性がよく、厳格なデータ主権要件にも対応しやすい。

単一障害点をなくすには、インフラ層だけでなくアプリケーション自体のステートレス設計が前提になる。データ層を別途冗長化し、ロードバランサの背後で自由にインスタンスを入れ替えられる状態を作っておくことが、Cloud Runのマルチリージョン構成を最大限活かす秘訣だ。

利用開始とコスト

Cloud Runのマルチリージョン高可用性に関する一連の機能は、すでに全リージョンで利用可能だ。Service Healthの機能そのものに追加料金は発生しない。Readiness Probeの実行に伴う標準的なCPU・メモリ消費のみが課金対象となる。

導入にあたっては、既存のCloud RunサービスにReadiness Probeを設定し、Service Healthを有効にしたうえで適切なロードバランサに接続するだけでよい。公式ドキュメントにチュートリアルが用意されており、少ないステップでマルチリージョン高可用性の基盤を整えられる。

この記事のポイント

  • Readiness Probeがコンテナ単位の死活監視を行い、Service Healthがリージョン単位の健全性を可視化する
  • Serverless NEGを通じてグローバルロードバランサに健全性が通知され、障害リージョンを数秒で自動迂回する
  • パブリック向けは外部ALB、VPC内向けは内部ALBを選択すれば、どちらも自動フェイルオーバーに対応可能
  • DB層を含めた全レイヤーでの冗長化と、データレプリケーションの方針決定が設計の鍵を握る
  • 機能追加に伴う追加コストはなく、通常のリソース消費のみで全リージョンですぐに利用を開始できる
海田 洋祐
, , , , ,
クラウド・インフラ

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.