Cloud Run にある、サービスヘルスを使ったクロスリージョン自動フェイルオーバーという機能が先日 GA されました。
これにより、サーバーレスアーキテクチャを維持したまま、リージョン障害時に自動でトラフィックを切り替え、高可用性なマルチリージョン構成を実現できるようになります。
本記事では、この機能の概要・仕組みの解説・フェイルオーバーの実演を行なっていきます。
この機能でできること
従来、Cloud Run のマルチリージョン構成で Act-Standby を行うにはカスタムの追加実装が必要でしたが、今回の機能でそれが実現できるようになりました。
DNS層でのフェイルオーバーのようにDNSキャッシュの壁がないため、より迅速な切り替えが期待できます。
- 自動フェイルオーバー: リージョンが異常を検知すると、ロードバランサが自動で正常なリージョンへトラフィックを切り替え
- 自動フェイルバック: 障害リージョンが復旧すると、段階的にトラフィックを元のリージョンへ戻す
- サーバーレス NEG（Network Endpoint Group）を活用した健全性監視: 各コンテナインスタンスの準備状況をプローブで監視し、リージョン単位の健全性を集計
対応するロードバランサは以下の2種類です。
- グローバル外部ロードバランサ
- クロスリージョン内部ロードバランサ
仕組み
アーキテクチャの全体像は以下のとおりです。
コンポーネント間のフェイルオーバーの流れは以下のように行われます。
設定方法
設定手順は公式ドキュメントに詳細がありますので、そちらをご参照ください。
前提として、リージョンごとに最小インスタンス数を 1以上 設定すること、フェイルオーバーには 2リージョン以上 が必要です。
また、新しいリビジョンをデプロイする際の CD ベストプラクティスとして、カナリアリリースによる段階的ロールアウトが推奨されています。
実際にフェイルオーバーを起こしてみる
Cloud Run サービスごとの Healthy/Unhealthy をトグルで切り替えられるサンプルアプリを用意しました。
これを使ってフェイルオーバーを再現してみます。
Cloud Run がリージョン A を「Unhealthy」と判定し、ロードバランサがリージョン B へ自動でトラフィックが切り替わりました。
大体30~40秒くらいでしょうか。Cloud Monitoring へのメトリクス反映時間を考慮するとこのくらいは掛かりますね。
リージョン A のプローブを正常に戻すと、段階的にトラフィックが元のリージョン A へフェイルバックします。
フェイルバックは20秒ほどですね。この間エラー画面に切り替わることはありませんでした。
メトリクスからフェイルオーバー先の Cloud Run がすぐに起動していることも確認できました。
おわりに
今回の Cloud Run サービスヘルスによるクロスリージョン自動フェイルオーバーを触ってみて、サーバーレスでここまでできるんだなと思いました。
さらに、以前の記事で紹介したComposite Health for Private Service Connect と組み合わせることで、インフラ層・アプリ層の両方をカバーした多段フェイルオーバー構成が組めるようになりました。
こういったアップデートから Google Cloud のマルチリージョン運用は、ここ最近でかなり実用的なレベルに進化してきたと感じています。
プラットフォーム側の進化によって、ダウンタイムを最小限に抑えるアーキテクチャが、運用コストや複雑さの面でも現実的な選択肢になってきましたね。
簡単30秒