AWS上で稼働する基幹システムのDisaster Recoveryについて考える

AWS上の基幹システムで考えられる主なDRパターンは4通りです。マルチリージョンでのDRが必要かどうかも含めて考えてみます。

#AWS Disaster Recovery

吉井亮

2022.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井亮です。

先日、前職の同僚と会話をする機会がありました。（前職では ERP 導入をしていました）
彼の顧客が大阪リージョンを利用した DR を計画しているという聞きまして、AWS 上の基幹システムの DR を改めて考えてみました。

何に備えるのか

DR の定義を「様々な災害被害を受けたシステムを復旧させること」とするとあまりに広すぎます。何に備えるかをまず初めに考え、災害とは何を指すかを定義しておきましょう。
例えば以下のような事象を想像します。他にも自組織では何をもってして災害とするかを考えてみてください。

自然災害によるシステムダウン（地震、洪水、火災など）
社会インフラの停止（停電、インターネット回線断など）
ユーザーでは対策できない AWS 障害（リージョン、アベイラビリティゾーンレベル）
人的災害（マルウェア・ランサムウェア感染、テロ、ストライキなど）
作業ミスによるデータロスト、全損・一部損

DR 求められているので対策考えてください、というご依頼を頂戴することが稀にあります。何をもって災害とするかによって対策と費用が変わります。私はしつこくここを確認するようにしています。
DR 検討前に災害を定義しますが最終決定ではありません。後段フェーズで具体的な方式・アーキテクチャが決まってくるとコスト計算が可能になります。災害の発生確率や頻度とコストを天秤にかけて災害の定義を見直します。
見直しは運用が始まってからも継続的に実施することが理想だと考えます。

3つの指標

DR を検討するうえで大切な指標が3つあります。
何に備えるのか、次に定義します。

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

https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html より引用

目標値の決定

目標値は机上で全てを決めるのではなく、構築しテストをしながら少しずつ調整します。根拠の無い目標値は避けましょう。
テック的なタスク、例えばスナップショットから RDS の復旧、だけではなく DR の検知～DR 発動の意思決定～社内報知～担当者アサイン～テック的なタスク～業務的な復旧確認～社内報知までテストします。フローの正確性や所要時間を計測します。

3つの指標とコスト

3つの指標はそれぞれが関係し合っています。3つをバランスよく定義することが大切です。
例えば、サブシステムが複数あるシステムで RTO が数時間、かつ、RLO が 100% であることは (人的リソースが大量な組織以外は) 現実的ではありません。
RPO が数分～1時間未満であればスナップショットでは事足りず、データレプリケーションが必要になるかもしれません。

3つの指標の目標値を理想に近付ければ近付けるほど DR コストが増えていきます。コストと相談しながら目標値を決定します。

リージョン内冗長をまず考える

オンプレミスに仮想サーバー環境を立てることと、AWS 東京リージョンに EC2 を立てることは DR 観点でイコールではありません。
東京リージョンは3つ（一部のユーザーは4つ）のアベイラビリティゾーンが提供されています。
アベイラビリティゾーンは1つ以上のデータセンターで構成されています。各ゾーンは電源、ネットワークが高度に冗長化されており、停電等の災害に耐える構成となっています。
リージョン内で AWS リソースを適切に冗長化する、または、冗長されたマネージドサービスを使うことで複数のデータセンターを跨いだ構成をとることが可能です。

オンプレミスで東京近郊に1つのデータセンター、DR 対策で関西や北海道などの遠隔地にデータセンターを用意する戦略は正しいと思います。
AWS ではリージョンが複数データセンターで構成されているという大きな違いがあります。単一データセンター時代と同じ発想で DR を考えることはせず AWS インフラストラクチャーを考慮した DR 戦略を策定することが大切です。

東京リージョン内で適切な冗長構成を採用することをまず第一に考え、それでも DR 要件を満たせない場合に他リージョンでの DR 構成を検討することをお勧めしています。

DR選択肢

AWS での DR を検討するとしたらどのようなアプローチがあるでしょうか？
Disaster Recovery of Workloads on AWS: Recovery in the Cloud では4つのアプローチが紹介されています。