フェイルオーバーテスト ふぇいるおーばーてすと
フェイルオーバー災害復旧DR訓練RTO高可用性BCP
フェイルオーバーテストって何？
簡単に言うとこんな感じ！
「本番システムが壊れたとき、予備システムに自動で切り替わる」仕組みが実際にちゃんと動くか、わざと障害を起こして確かめる訓練だよ！消防訓練みたいなもので、「いざというとき動くか」を本番前にテストしておくんだ！
フェイルオーバーテストとは
フェイルオーバーテスト（Failover Test）とは、システムに障害が発生したときに予備システムへ自動または手動で切り替わる「フェイルオーバー」機能が、実際に正しく動作するかを意図的に障害を起こして検証するテストのことです。
企業のシステムは「壊れないように作る」だけでなく、「壊れたときにすぐ復旧できるように作る」ことが重要です。しかし、いくら設計上は「切り替わるはず」でも、実際に試してみないと本当に動くかはわかりません。フェイルオーバーテストは、この「机上の計算」を「実証済みの事実」に変えるための訓練です。
BCP（事業継続計画） や DR（ディザスターリカバリー） の実効性を担保するうえで不可欠なテストであり、金融機関・医療・EC事業者など、システム停止が許されない業種では定期的な実施が求められています。
フェイルオーバーテストの仕組みと種類
フェイルオーバーテストは「どこで」「どうやって」障害を起こすかによって、いくつかの種類に分かれます。
| テスト種別 | 内容 | リスク |
|---|---|---|
| 計画的フェイルオーバー | 事前に告知・準備したうえで切り替えを実施 | 低い（本番影響を最小化できる） |
| ブラインドテスト | 担当者に予告なしで実施（抜き打ち訓練） | 中程度（対応力を測れる） |
| カオスエンジニアリング | 本番環境に意図的な障害を注入して耐障害性を検証 | 高い（Netflix等の大企業が採用） |
| DR訓練（全系切り替え） | 本番をすべて停止し、DRサイトで業務継続を確認 | 高い（業務影響あり） |
テストで確認すべき3つのポイント
- RTO（目標復旧時間）を満たせるか — 「30分以内に復旧」という目標を実際に達成できるか
- RPO（目標復旧時点）を満たせるか — 「直近1時間分のデータは失わない」という目標が守られるか
- 業務継続性 — 切り替え後のシステムで実際の業務オペレーションが問題なく動くか
よくあるテスト手順（概要）
1. テスト計画の策定（対象システム・手順・判定基準を文書化）
2. 関係者への事前通知と承認取得
3. 現用環境のバックアップ確認
4. 意図的な障害の注入（サーバー停止・ネットワーク切断など）
5. フェイルオーバー動作の確認（自動切り替えの発動を観察）
6. RTOの計測（障害発生〜復旧完了までの時間を記録）
7. 業務テスト（切り替え後に実際の操作が通るか確認）
8. フェイルバック（元の構成への戻し）
9. 結果の記録・課題の改善歴史と背景
- 1960〜70年代 — メインフレーム時代。冗長構成の考え方が登場。ただしテストは費用・時間的に困難
- 1980年代 — 金融・航空業界でDR要件が義務化。定期テストの概念が生まれる
- 2001年 9.11同時多発テロ — 物理的災害がITインフラを破壊することが広く認識され、DR訓練の重要性が世界的に高まる
- 2000年代後半 — 仮想化技術（VMwareなど）の普及により、フェイルオーバーの自動化・テストが格段に容易になる
- 2010年代 — クラウドの普及でマルチリージョン構成が一般化。AWS・Azureなどが自動フェイルオーバー機能を標準提供
- 2011年（Netflix） — Chaos Monkey をOSS公開。本番環境での意図的障害注入（カオスエンジニアリング）という概念が広まる
- 現在 — ISO 22301（事業継続マネジメント）やクラウドのWell-Architectedフレームワークでもフェイルオーバーテストの定期実施が推奨されている
現用環境とDRサイトの関係
フェイルオーバーテストは「現用（プライマリ）」と「予備（セカンダリ／DRサイト）」の2拠点構成で実施されることが多いです。
フェイルオーバーテスト vs 関連テストの比較
| テスト名 | 目的 | 本番停止 | 頻度の目安 |
|---|---|---|---|
| フェイルオーバーテスト | 切り替え機能の動作確認 | 一時的にあり | 年1〜2回 |
| バックアップリストアテスト | データが復元できるか確認 | 基本なし | 月1回 |
| DR訓練（フルDRテスト） | 全系切り替えでの業務継続確認 | あり | 年1回 |
| ペネトレーションテスト | セキュリティ上の侵入可能性を確認 | 基本なし | 年1〜2回 |
関連する規格・RFC
| 規格・番号 | 内容 |
|---|---|
| ISO 22301 | 事業継続マネジメントシステム（BCMS）の国際規格。DRテストの定期実施を要求 |
| NIST SP 800-34 | 米国政府向けの情報システム緊急時対応計画ガイド。テスト手順を詳細に規定 |
| AWS Well-Architected（信頼性の柱） | AWSが推奨するアーキテクチャのベストプラクティス。フェイルオーバーテストを明示的に推奨 |
| FISC安全対策基準 | 金融機関向け。バックアップセンターへの切り替え訓練の定期実施を要求 |
関連用語
- フェイルオーバー — 障害時に予備システムへ自動切り替えする仕組み本体
- RTO（目標復旧時間） — 障害発生から業務復旧までの目標時間
- RPO（目標復旧時点） — 障害発生時に許容できるデータ損失の最大時間
- DR（ディザスターリカバリー） — 大規模障害・災害時のシステム復旧戦略全般
- BCP（事業継続計画） — 災害・障害時にも事業を継続するための計画
- カオスエンジニアリング — 本番環境に意図的な障害を注入してシステムの耐障害性を高める手法