マルチリージョンにおけるディザスタリカバリ(DR)戦略について調べてみた

はじめに

関わっているプロジェクトの非機能要件に障害・災害対策は「メインリージョンが停止してもサブリージョンで運用を継続できること」があり、対応方法がわからなかったためディザスタリカバリ(DR)戦略について調べてみることにしました。

3つの指標

• RPO（Recovery Point Objective、目標復旧時点）
  • 災害からの復旧時にどの時点のデータに戻っていればよいか
  • 最後のバックアップから災害によるサービスダウンまでの間に許容されるデータ損失期間
• RTO（Recovery Time Objective、目標復旧時間）
  • 災害によるサービスダウンから復旧までの最大許容時間
• RLO（Recovery Level Objective、目標復旧レベル）
  • どの程度まで復旧させるか
  • サブシステムが複数存在する場合、業務上重要なシステムを復旧の対策にする
  • 重要度の低いシステムは後回しにする

AWSにおけるディザスタリカバリ(DR)戦略

事業継続における4つの戦略

バックアップとリストア

• 平常時はバックアップを取得
• RTOに応じて常時サブサイトへバックアップを転送
• 障害時はバックアップデータからサブサイトを構築
  
  

パイロットライト

• 平常時はコアサービスのみに限定したサブサイトを運用(例:DBのみ常時運用 etc.)
• 障害時に必要に応じてその他サービスを起動
  
  

ウォームスタンバイ

• 平常時からメインサイト同等機能を持ち規模を縮小したサブサイトを運用
• 障害時は自動フェイルオーバーして絞って継続
  
  

マルチサイトアクティブ/アクティブ

• 平常時からメインサイト同様構成のサブサイトを運用
• 障害時は自動フェイルオーバー
  

まとめ

一番コストが低い「バックアップとリストア」は構築が簡単にできるが異常時の対応が大変。
あとが日頃からシュミレーションしておかないと、いざという時に対応できなさそう。
一番コストが高い「マルチサイトアクティブ/アクティブ」は構築が大変であるが、異常時対応がスムーズにできる。