Cloud Run を使用して高可用性のマルチリージョン サービスを構築する方法

※この投稿は米国時間 2025 年 9 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

最も必要なときにアプリケーションがダウンすることを心配したことはありませんか？Cloud Next 2025 の講演 Run high-availability multi-region services with Cloud Run（Cloud Run を使用して高可用性のマルチリージョン サービスを実行する）では、Google Cloud のサーバーレス コンテナ プラットフォームである Cloud Run を使用して、フォールト トレラントで信頼性の高いアプリケーションを構築する方法について詳しく説明しています。

Google のスペシャリスト Shane Ouchi と Taylor Money、そして Commerzbank の Seenuvasan Devasenan 氏が、Cloud Run の組み込みの復元力について解説し、Service Health という Cloud Run の新機能を使った現実のシナリオを紹介します。

Cloud Run に組み込まれたフォールト トレランスについて

Cloud Next 2025 のプレゼンテーションでは、Shane はまず、自動スケーリング、データプレーンとコントロール プレーンの分離、N+1 ゾーン冗長性による Cloud Runの基本的なレジリエンスについて説明しました。では、自動スケーリングから順に詳しく見ていきましょう。

自動スケーリングで容量が需要を満たすようにする

Cloud Run は、受信リクエストの負荷に基づいてインスタンスを自動的に追加および削除し、Cloud Run サービスの容量が需要を満たすようにします。Shane はこれをハイパー エラスティシティと呼び、Cloud Run のコンテナ インスタンスを迅速に追加できる機能を指しています。迅速な自動スケーリングにより、アプリケーションがすべてのリクエストを処理するのに必要なサーバー インスタンスを確保できず障害につながる事態を防止できます。

注: Cloud Run では、インスタンスの最大数を制限することで、スケーリングの暴走を防ぐことができます。

データプレーンとコントロール プレーンの分離によりレジリエンスが向上

Cloud Run のコントロール プレーンは、新しいリビジョンのデプロイ、サービスの構成、インフラストラクチャ リソースの管理などの管理オペレーションを担当するシステムの一部です。データプレーンから切り離されています。データプレーンは、ユーザーからのリクエストを受信してコンテナ インスタンスにルーティングし、アプリケーション コードを実行する役割を担います。データプレーンはコントロール プレーンから独立して動作するため、コントロール プレーンの問題が実行中のサービスに影響することは通常ありません。

コントロール プレーンとデータプレーンの両方で N+1 の冗長性

Cloud Run はリージョン サービスであり、Cloud Run はデフォルトで N+1 ゾーン冗長性を提供します。つまり、リージョン内のいずれかのゾーンで障害が発生した場合、Cloud Run インフラストラクチャは、同じリージョン内にすべてのワークロードの処理を継続できる十分なフェイルオーバー容量（「+1」）を備えています。これにより、アプリケーションがゾーン障害から分離されます。

コンテナのプローブで可用性を向上

アプリケーションの可用性が気になる場合は、障害が発生したインスタンスをシャットダウンするよう、liveness プローブを構成します。Cloud Run では、2 種類のコンテナ インスタンスのヘルスチェックを構成できます。

• startup プローブ: 新しいインスタンスが正常に起動し、リクエストを受け付ける準備ができていることを確認します。

• liveness プローブ: 実行中のインスタンスが正常な状態を維持し、リクエストの処理を続行できるかどうかをモニタリングします。このプローブは省略可能ですが、有効にすると、Cloud Run が障害のあるインスタンスを自動的に削除できるようになります。

100% の可用性は非現実的

アプリケーションの中には、常に利用できるようにしておきたいほど重要なものもあります。100% の可用性は非現実的ですが、できる限りフォールト トレラントにすることは可能です。これを適切に行うには、アプリケーション アーキテクチャと、使用する基盤のプラットフォームとサービスが重要です。Cloud Run には、ベースラインのレジリエンスを高めるための機能がいくつかありますが、アプリケーションのレジリエンスをさらに高めるためにできることは他にもあります。

ゾーンの冗長性を超えて

Cloud Run はゾーン冗長性を提供するリージョン サービスであるため、開発者はリージョンの停止に対するレジリエンスを備えたアプリケーションを積極的に設計する必要があります。幸いなことに、Cloud Run はすでにマルチリージョン デプロイをサポートしています。仕組みは次のとおりです。

• 同じコンテナ イメージと構成を使用して、複数のリージョンに Cloud Run サービスをデプロイする。

• 1 つのバックエンド サービスと Cloud Run サービスごとのサーバーレス ネットワーク エンドポイント グループ（NEG）を使用して、グローバル外部アプリケーション ロードバランサを作成する。

• 1 つのグローバル外部 IP アドレスを使用して、エントリ ポイントを単一にする。

これを図で表すと次のようになります。

念のために説明すると、サーバーレス ネットワーク エンドポイント グループ（NEG）は、Cloud Run サービスまたは App Engine アプリをポイントするロードバランサのバックエンド構成リソースです。

リージョン冗長性を実現するアプリケーションの設計は困難

Cloud Run を使用すると複数のリージョンに簡単にデプロイできますが、課題は、個々のリージョン サービスが障害を起こしてもデータが失われず、他のリージョンのサービスに影響を与えないようにアプリケーションを設計することです。

データの冗長性とレプリケーションを適切に実現することは困難です。ただし、Cloud Spanner などのマルチリージョン データベースや Cloud SQL のクロスリージョン レプリカ機能が登場したことで、以前ほど難しくなくなりました。

この投稿では、これ以上詳しく説明しませんが、Anna Berenberg 氏と Brad Calder 氏による優れた論文「Deployment Archetypes for Cloud Applications」を読むことをおすすめします。

自動リージョン フェイルオーバーを実現する Service Health のプレビュー

現在、マルチリージョン Cloud Run アーキテクチャをセットアップすると、リクエストはすべて最も近いリージョンにルーティングされますが、そのリージョンの Cloud Run サービスが利用できなくなった場合、リクエストが自動的に別のリージョンにルーティングされることはありません。次の図をご覧ください。

今後リリースされる Service Health 機能では、あるリージョンのサービスが利用できなくなると、そのリージョンにルーティングされるはずだったトラフィックは、別のリージョンに自動的にフェイルオーバーします。

Service Health の有効化

2025 年 8 月現在 Service Health はまだ一般公開されていません（限定公開プレビュー版のみ）が、まもなく一般公開の予定です。留意すべき点として、この機能は一般提供までに変更される可能性があることが挙げられます。アクセスをリクエストするには、こちらのフォームに記入してください。

アクセスを取得したら、次の 2 つのステップで、マルチリージョン サービスの Service Health を有効にすることができます。

• 各 Cloud Run サービスにコンテナ インスタンスの readiness プローブを追加する。

• 各 Cloud Run サービスの最小インスタンス数を 1 に設定する。

これですべての設定が完了しました。追加でロードバランサを構成する必要はありません。

Cloud Run に readiness プローブが導入されます

Service Health の一部として、Cloud Run に readiness プローブが導入されます。readness プローブ は、HTTP 経由で各コンテナ インスタンスを定期的にチェックします。readiness プローブが失敗すると、Cloud Run は、プローブが再び成功するまで、そのインスタンスへのトラフィックのルーティングを停止します。一方、liveness プローブが失敗すると、Cloud Run は異常なインスタンスをシャットダウンします。

Service Health は、サービス内のすべてのコンテナ インスタンスの集計された準備状態を使用して、サービス自体が正常かどうかを判断します。コンテナの大部分が失敗している場合は、サービスが異常であると判断され、トラフィックが別のリージョンにルーティングされます。

Cloud Next 2025 でのライブデモ

ライブデモでは、Taylor が同じサービスを 2 つのリージョン（1 つは近く、1 つは遠く）にデプロイしました。その後、グローバル外部アプリケーション ロードバランサ（ALB）を介してリクエストを送信しました。ALB は、リクエストを最も近いリージョンのサービスに正しくルーティングします。

最も近いサービスが 30 秒ごとに失敗と正常を切り替えるように構成した後でも、トラフィックがフェイルオーバーしないことを実証しました。これは現状の動作で、新しいことではありません。

デモの次のステップは、各サービスで最小インスタンスと readiness プローブを有効にして、Service Health を有効にすることでした。2 つのサービスに構成の変更をデプロイするために、Taylor は Cloud Run gcloud インターフェースの新しいフラグを使用しました。gcloud run deploy の --regions フラグです。同じコンテナ イメージと構成を複数のリージョンに同時にデプロイするのに最適な方法です。

readiness プローブが配置され、最小インスタンス数が設定されたことで、Service Health はサービス障害を検出し、トラフィックを別のリージョンの正常なサービスに移行し始めました。素晴らしいデモでしたね。

次のステップ

この投稿では、Cloud Run の組み込みのフォールト トレランス メカニズム（自動スケーリングやゾーン冗長性など）、高可用性を実現するマルチリージョン サービスの設計方法について説明し、さらに今後リリースされる、自動リージョン フェイルオーバーを実現する Service Health 機能をご紹介しました。

Service Health 機能はまだ限定公開プレビュー版ですが、こちらのリクエスト フォームに記入してアクセスを申し込むことができます。

-デベロッパー リレーションズ エンジニア、Wietse Venema