災害対策計画とは？
概要
いつもは安定的に動いているシステムも地震などの自然災害やネットワークの大規模障害などが起こるとビジネスの継続が難しくなる場合があります。特にグローバル企業であれば一地域の災害がグローバルのビジネス全体に波及するリスクもあり、普段からか災害への備えを意識したシステムを構築する必要があります。ビジネス継続性を維持することを目的に、災害への備えとして災害対策計画を考える際に重要な概念としてBCPとDRがあります。
事業継続計画（Business Continuity Plan）は技術面だけでなく組織全体の業務継続を対象とし、業務プロセスや人員配置、コミュニケーションなど広範な要素を含む計画を言います。DRとBCPは補完的な関係にあり、両方を適切に計画・実行することで、企業や組織のレジリエンス（回復力）を高めることができます。
システムにおけるDR（Disaster Recovery）は、ITインフラストラクチャやデータを保護しシステムの可用性を維持するための計画です。これには自然災害、ハードウェアの故障、サイバー攻撃、人為的なミスなど、さまざまなリスクに対する準備と対応が含まれれており何かしらの災害やシステム障害が発生した際にITシステムやデータの復旧と業務の再開を目的とします。DRは主に技術的な側面に焦点を当てており、システムやデータのバックアップ、リカバリ手順、冗長性確保などの具体的な措置を含みます。
BCPやDRはAWSの提言するベストプラクティスであるAWS Well-Architected Frameworkの信頼性の柱でも説明がありますので、興味のある方はこちらも確認してみるとよいでしょう。
レジリエンシー
レジリエンシーとは回復性を指し、障害が発生した際にいかにシステムを元通りに回復できるかを指す指標となります。AWSではこのレジリエンシーを考える際に、災害対策（DR）と可用性（Availability）を考慮する必要があると提言しています。可用性は回復性戦略の別の重要な要素です。災害対策は 1 回限りのイベントに対する目標を測定するのに対し、可用性の目標は一定期間の平均値を測定することにあります。この記事ではDRに特化して解説することとします。なお下図がAWSがホワイトペーパーで示している概念になります。
AWS, AWS でのワークロードの災害対策: クラウド内での復旧
RTOとRPO
DRは災害時に以下にある地点まで短い時間で復旧できるかをが重要であり、それを考える上での指標がRTOとRPOになります。RTO（目標復旧時間）は サービスの中断からサービスの復旧までの最大許容遅延時間を指し、これによりサービスのダウンタイムの許容可能な期間が決まります。またRPO（目標復旧時点）は 最後のデータ復旧ポイントからの最大許容時間を指し、これにより許容できるデータの損失と見なされるものが決まります。イメージ図は下図となります（引用元はこちら）。
AWS, AWS でのディザスタリカバリ (DR) アーキテクチャ、パートI：クラウドでのリカバリの戦略
AWSの考えるDR方針
DR目標
目標値とコストのバランス
DR目標を考える場合に重要となるのがRTOとRPOをどう設定するかになります。RTO、RPOともに小さい数値であればあるほど損害は少なくなりますが、通常時のリソースへの支出と運用の複雑さという点でコストが高くなります。そのため、DR目標はビジネスインパクトを考慮したRTO/RPOの目標値と掛けられるコストをバランスさせることが重要です。
DR戦略
影響範囲
災害の影響がアベイラビリティゾーン（AZ）にとどまるのか、リージョン全体に影響するのかは重要な観点です。AZにおいては普段から単一AZではなくマルチAZにすることが推奨されています。複数リージョンでの運用についてはDR目標の観点を参考にリスクやコストを考慮した上で決定することになるでしょう。詳細はこちらをご参照ください。
アクティブ/アクティブ or アクティブ/パッシブ
DR戦略を考えるためのアーキテクチャ構成の基本としてアクティブ/アクティブ型とアクティブ/パッシブ型があります。詳細はこちらをご確認ください。
アクティブ/アクティブ型は通常時も運用が行われており、災害時はもう一つのアクティブなアーキテクチャで稼働を保証する方法です。RTOやRPOを小さくすることができる一方で、普段から稼働をしているためコストが高くなりやすい構成です。
AWS, AWS でのディザスタリカバリ (DR) アーキテクチャ、パートI：クラウドでのリカバリの戦略
アクティブ/パッシブ型は、普段稼働していないパッシブなアーキテクチャ（待機系）が存在し災害時にアクティブとなりビジネス継続性を維持する方法です。アクティブ/パッシブ型の方がコストが低く抑えられますが、災害時のリソースやDB切り替えによる対応時間やパッシブからアクティブに切り替えた際に正常に動くことを普段から確認しておく必要があります。
AWS, AWS でのディザスタリカバリ (DR) アーキテクチャ、パートI：クラウドでのリカバリの戦略
4つの戦略
ここでは具体的なDR戦略を紹介します。上記のアクティブ/アクティブ型、アクティブ/パッシブ型を考慮したアーキテクチャとして、4つの構成（バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイト）が挙げられます。下図ではこれらの特徴とRTO/RPOの目安について述べられています。（引用元はこちら）
AWS, クラウド内での災害対策オプション
それぞれの構成についてアーキテクチャ構成図を確認ながら特徴を理解したい場合はこちらのAWS公式ページをご参考ください。
テスト
それでは最後のセクションとしてテストを紹介します。せっかくDRを作成してもいざというときに稼働しないので元も子もありません。DRを策定した後は定期的にフェイルオーバーテストを実施し、①手順書にそって確実に災害対策ができるか、①RTO/RPOが満たされているかを確認するようにしましょう。不備があった場合は手順書やアーキテクチャ構成を見直し、確実に災害対策が実施できる環境を整備することが重要です。
まとめ
本記事では災害対策計画としてAWSの考えるDRについてまとめました。アプリ開発では運用を見据えた仕組みを整えることも重要なタスクになってきます。本記事を参考に想定される損害と対応にかけるべきコストをバランスさせながら現場に合ったDR戦略を考えて頂けたらと思います！
