フェイルオーバーは本当に動く？　Google Cloudが障害注入機能のプレビュー提供開始

冗長化やフェイルオーバーの仕組みを用意しても、障害時に本当に想定通り動くかは別問題だ。可用性対策では、障害を避けるだけでなく、あえて起こして確かめる発想も重要になる。Google Cloudが、そのための新たな選択肢を打ち出した。

公開 2026年09月11日 09時00分

[キーマンズネット]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　システムの可用性を高めるため、データベースやネットワークを冗長化し、障害時の切り替え手順を設計することは重要だ。ただし、「フェイルオーバーできる構成になっていること」と、「実際の障害時に問題なく切り替わること」は同じではない。

　障害が発生すれば、データベースやネットワークだけでなく、それらに依存するアプリケーションも影響を受ける。構成上は冗長化されていても、実際に切り替えが発生したときに想定通り動くかどうかは、平常時の運用だけでは見えにくいからだ。

　こうした背景から、障害を避ける対策に加え、あえて障害を起こして挙動を確かめることも重要になっている。Google Cloudが今回発表した新機能も、そのための選択肢の一つと言える。

「壊して確かめる」をクラウド運用にどう組み込むか

　Google Cloudがプレビュー版の提供を開始した「Fault Injection Testing」（FIT）は、Google Cloud環境に意図的に障害を発生させ、アプリケーションやインフラが想定通り動作するかを検証するサービスだ。

　公開プレビューでは主に2つの障害シナリオを試せる。一つは、高可用性構成の「Cloud SQL」インスタンスをプライマリーゾーンからスタンバイゾーンへフェイルオーバーさせるものだ。もう一つは、「Application Load Balancer」（レイヤー7ロードバランサー）を介する通信に遅延を加えたり、HTTPエラーを発生させたりして、アプリケーショントラフィックが劣化した状態を再現する。

　試験では、注入する障害と対象リソースを定義したテンプレートを作成する。障害を発生させる前には読み取り専用の自動ドライランが実行され、必要な権限や影響を受けるリソースを確認できる。対象範囲を確認した後に手動で障害注入を開始し、設定した時間が経過すると障害は解除される。テスト中に想定外の状態になった場合は、途中で停止してリソースの復元を始められる。

　FITは「Google Cloudコンソール」「gcloud CLI」「REST API」で利用できる。プレビュー版の利用にはGoogle Cloudのアカウントチームを通じたアクセス申請が必要で、プロジェクトで「Fault Testing API」を有効にする。テストの設定と実行には「roles/faulttesting.operator」ロールに加え、対象となるGoogle Cloudリソースへの編集権限が必要だ。

　こうした可用性対策では、冗長構成を用意するだけでなく、実際に障害が起きたときに想定通り動くかを繰り返し確かめることが重要だ。FITのような仕組みは、その検証をクラウド環境で実施するための選択肢となる。

　ただし、障害を意図的に発生させる以上、検証そのものが想定外のトラブルにつながらないよう注意が必要だ。Googleもプレビュー期間中は本番環境以外でのFITの利用を推奨している。障害対応を本番で初めて試すのではなく、影響範囲を管理しながら、いわば「避難訓練」を重ねておくことが可用性対策では重要になりそうだ。

印刷する