BCP — 事業継続計画とは？
BCP（Business Continuity Plan）は、大規模障害・自然災害・サイバー攻撃などが発生しても業務を継続できるようにするための計画です。「完全復旧まで何もできない」ではなく「最小限の機能で業務を続ける」ことを目的とします。
RTO と RPO — 2つの復旧目標
RTO と RPO の関係
RPO時点 ← 最後のバックアップ（この時点のデータまで復元可能）
障害発生 ← ここからの変更データは失われる可能性
サービス復旧 ← RTO経過後にここまで復旧
RTO（Recovery Time Objective）
目標復旧時間
目標復旧時間
障害発生から何時間以内にサービスを復旧させるかの目標
例：「RTO=4時間」= 4時間以内に復旧しなければならない
短いほど高コスト（ホットスタンバイが必要）
例：「RTO=4時間」= 4時間以内に復旧しなければならない
短いほど高コスト（ホットスタンバイが必要）
RPO（Recovery Point Objective）
目標復旧時点
目標復旧時点
障害発生時にどの時点のデータまで許容できるかの目標
例：「RPO=24時間前」= 最大24時間前のデータで復旧OK
短いほどバックアップ頻度が高い（コスト増）
例：「RPO=24時間前」= 最大24時間前のデータで復旧OK
短いほどバックアップ頻度が高い（コスト増）
復旧サイトの種類
DR（災害復旧）サイトの3種類
| 種類 | 特徴 | RTO目安 | コスト |
|---|---|---|---|
| ホットサイト | 常時稼働・データリアルタイム同期 | 数分〜数時間 | 高い |
| ウォームサイト | 機器は稼働中・定期バックアップで同期 | 数時間〜1日 | 中程度 |
| コールドサイト | 場所・電源のみ確保。機器は持ち込み | 数日〜1週間 | 低い |
冗長化の考え方
アクティブ/スタンバイ（フェールオーバー）
平常時：1台が稼働、1台が待機
障害時：自動的に待機系に切り替え
用途：DBサーバ、重要システム
障害時：自動的に待機系に切り替え
用途：DBサーバ、重要システム
アクティブ/アクティブ（負荷分散）
平常時：複数台が同時に稼働して負荷分散
障害時：残りのサーバで処理を継続
用途：Webサーバ、APIサーバ
障害時：残りのサーバで処理を継続
用途：Webサーバ、APIサーバ
フェールオーバー（自動切替）のフロー
平常時：プライマリサーバが稼働中。スタンバイは同期受信
プライマリが障害発生 → ヘルスチェックが失敗を検知
スタンバイに自動切替（フェールオーバー）→ 数秒〜数分でサービス再開
プライマリ復旧後：手動または自動でフェールバック（元に戻す）
BCPテストの重要性
BCPなしの問題
実際に障害が起きると手順が不明確 → 対応が遅れる → 被害拡大
定期的なBCPテスト
年1回以上の訓練（フェールオーバー切替・データ復元）で本番での迅速対応を確認
試験ポイントまとめ
RTO = 復旧にかかる時間の目標（短いほどコスト高）
RPO = どこまでのデータ損失を許容するかの目標（短いほどバックアップ頻度高）
ホットサイト = 即時切替可（高コスト）、コールドサイト = 数日後（低コスト）
BCPは計画を立てるだけでなく、定期的にテスト・訓練することが重要
