AWSのDR戦略 ― パイロットライトとウォームスタンバイの違い

リージョン全体が使えなくなったとき、別のリージョンでどれだけ早くサービスを復旧できるか。AWSのDR戦略（DRは災害復旧のこと）は、そのために待機側をどこまで用意しておくかで分けた4つの方式です。用意が少ない順に、バックアップと復元・パイロットライト・ウォームスタンバイ・マルチサイトアクティブ/アクティブです。

この順に費用と複雑さは大きくなり、目標の復旧時間は短くなります。パイロットライトとウォームスタンバイは、どちらもデータを常に複製します。違いはサーバです。ウォームスタンバイだけが待機側でサーバを動かしておき、切り替えた直後から要求を処理できます。

戦略を選ぶ基準は、RPOとRTOです。RPOは、どの時点までのデータを取り戻すかの目標です。RTOは、停止から復旧までに許容する時間の目標です。2つの意味と決め方はBCPとDRの記事で説明しています。

AWSは、1つのリージョンの中で複数のAZを使うだけでも、火災・洪水・大規模な停電などに備えられると説明しています。別のリージョンを使う4つの戦略を検討するのは、リージョン全体が使えなくなる事態に備える場合や、規制で求められる場合です。リージョンとAZの関係は、リージョンとAZの記事にまとめています。

4つの戦略は、待機側のリージョンで何を動かしておくかで区別できます。次の図は、データ・サーバ・平常時の通信の3つについて、それぞれの戦略で動いているかどうかを並べたものです。

図の目安は、AWS Well-Architectedフレームワークの信頼性の柱が示している値です。実際にかかる時間は、構成や切り替えの手順で変わります。図の左から右へ進むごとに、用意するものが増えていきます。

バックアップと復元は、データのバックアップを別のリージョンにコピーしておき、障害が起きてから環境を作り直す戦略です。待機側では、平常時には何も動かしません。4つの中で費用と複雑さがいちばん小さい戦略です。目安はRPOが時間単位、RTOが24時間以内です。

バックアップには、AWS Backupが使えます。AWS Backupは、EC2・EBS・RDS・DynamoDBなどのバックアップをまとめて管理できます。別のリージョンへのコピーもできます。S3のデータは、別のリージョンのバケットへ非同期で複製し続けることもできます。

障害のあとは、データに加えて、ネットワークやサーバなどの基盤とアプリケーションのコードも配置し直します。そのためAWSは、基盤をCloudFormationなどのテンプレートで作れるようにしておくことを勧めています。テンプレートで作る仕組みは、CloudFormationの記事で説明しています。

パイロットライトとは、データを別のリージョンへ常に複製しておく戦略です。アプリケーションのサーバは、切り替えるときに動かします。待機側で常に動いているのは、データベースやオブジェクトストレージなど、複製とバックアップに必要なものだけです。目安はRPOが分単位、RTOが数十分です。

サーバは、設定とコードを用意したうえで止めておくか、作らずにおきます。AWSは、必要になるまでサーバを作らず、すぐ作れる仕組みを整えておくやり方を勧めています。動かしているものが少ない分、平常時の費用を抑えられます。

データを別のリージョンへ非同期で複製し続けるサービスには、次のものがあります。

• S3のレプリケーション：バケットのオブジェクトを、別のリージョンのバケットへ複製します。
• RDSのリードレプリカ：別のリージョンに置き、切り替えるときにプライマリへ昇格させます。
• Aurora Global Database：セカンダリのリージョンのクラスターへ、通常1秒未満で書き込みを反映します。
• DynamoDBのグローバルテーブル：複数のリージョンに、同じテーブルを置きます。

切り替えでは、読み取り専用のデータベースを、書き込みを受けるプライマリに昇格させます。ホワイトペーパーは、Aurora以外のRDSのリードレプリカの昇格に数分かかるとしています。Aurora Global Databaseなら、リージョン全体が止まっても1分未満でセカンダリを昇格できるとしています。Global Databaseの仕組みは、Amazon Auroraの記事で説明しています。

AWS Elastic Disaster Recoveryは、サーバのデータをブロック単位で複製し続けるサービスです。復旧にはパイロットライトの戦略を使います。AWSは、このサービスならパイロットライトの費用のまま、ウォームスタンバイに近い目安を狙えると説明しています。

ウォームスタンバイとは、本番と同じ構成一式を、台数を減らしたまま別のリージョンで動かしておく戦略です。データの複製に加えて、アプリケーションのサーバも常に動いています。目安はRPOが秒単位、RTOが分単位です。

切り替えるときは、台数を本番の規模まで増やします。EC2なら、Auto Scalingのグループの希望の台数を上げます。サービスクォータとは、アカウントで使えるリソースの数の上限です。待機側のリージョンのサービスクォータは、本番の規模まで増やせる値にしておく必要があります。

AWSの説明によると、台数の変更は設定を変える操作なので、障害時にこれに頼るほど復旧の確実性が下がります。そこで、待機側に初めから本番の全量を用意しておく構成もあります。この構成をホットスタンバイと呼びます。ホットスタンバイでも、平常時の通信を受けるのは1つのリージョンだけです。

名前は同じでも、BCPとDRの記事のウォームスタンバイとは、待機側の用意の度合いが違います。BCPとDRの記事のウォームスタンバイは、予備機のハードウェアやソフトウェアの一部だけを準備しておく方式です。AWSのウォームスタンバイは、台数を減らしただけで構成一式が動いています。そのため、切り替えた直後から要求を処理できます。資料でウォームスタンバイという言葉を見たら、AWSの戦略の話か、一般の待機方式の話かを確認します。

サーバが常に動いているので、ウォームスタンバイでは復旧のテストも行いやすくなります。AWSは、テストを継続して行うことで、復旧の確実性を高められると説明しています。

パイロットライトとウォームスタンバイは、どちらも待機側のリージョンに本番のデータの複製を持ちます。違いは、切り替えた直後に要求を処理できるかどうかです。パイロットライトは、先にサーバを動かす作業が必要です。ウォームスタンバイは、減らした容量のまますぐ処理できます。

AWSは、どちらにするかをRTOとRPOの要件で決めるよう勧めています。数十分の停止を許容できるなら、パイロットライトで費用を抑えます。数分に収めたいなら、ウォームスタンバイを選びます。

マルチサイトアクティブ/アクティブは、複数のリージョンで本番を同時に動かし、どのリージョンでも通信を受ける戦略です。目安はRPOがほぼ0で、RTOは0にできることもあります。4つの中で、費用と複雑さがいちばん大きい戦略です。

1つのリージョンが使えなくなったら、そのリージョンへ通信を送るのをやめ、残りのリージョンで受けます。どのリージョンも初めから通信を受けているので、ほかの3つの戦略のように待機側を起動する切り替えはありません。

難しいのは、書き込みの扱いです。書き込みを1つのリージョンに集めるなら、Aurora Global Databaseが向きます。どのリージョンでも書き込みを受けるなら、DynamoDBのグローバルテーブルが使えます。同じデータを2つのリージョンで同時に書き換えたときの衝突は、回避するか、ルールを決めて解決します。

次の図で、許容できる停止時間とデータの損失を選ぶと、両方を満たす戦略のうち費用が最も小さいものが強調されます。AWSは、要件より厳しい戦略を選ぶと不要な費用がかかると説明しています。

停止時間とデータの損失のうち、厳しいほうの要件で戦略が決まります。たとえば停止は24時間まで許容できても、数秒分のデータしか失えないなら、ウォームスタンバイが必要です。

パイロットライトとウォームスタンバイでは、平常時はすべての通信が本番のリージョンへ届きます。本番が使えなくなったら、通信の行き先を待機側のリージョンへ変えます。この切り替えの代表的な方法が、Route 53のヘルスチェックを使ったDNSのフェイルオーバーです。

Route 53は、ヘルスチェックで本番の状態を確認し、健全な行き先だけを返します。仕組みは、Route 53の記事のフェイルオーバールーティングの節で説明しています。ほかに、固定のIPアドレスで受けて健全な行き先へ送るAWS Global Acceleratorも使えます。

ヘルスチェックで自動的に切り替えると、誤検知でも切り替わります。そのたびにデータや時間を失います。そのため、切り替えの開始は人が判断することがよくあります。その場合も、AWSは切り替えの手順を自動化し、ボタン1つで始められるようにしておくよう勧めています。

データを常に複製していても、それだけでは不十分です。誤った削除やデータの破損も、そのまま待機側へ複製されることがあるからです。AWSは、どの戦略でも、時点を選んで戻せるバックアップを合わせて取るよう勧めています。

S3なら、オブジェクトのバージョニングを有効にしておくと、削除や上書きの前の版が残ります。マルチサイトアクティブ/アクティブでも、データの破損から復旧するときはバックアップに頼ります。戻せるのは破損に気づく前の時点なので、失うデータは0になりません。バックアップの取り方の違いは、フル・差分・増分バックアップの記事で説明しています。

• AWS Well-Architected「REL13-BP02 Use defined recovery strategies to meet the recovery objectives」（4つの戦略の目安と、パイロットライトとウォームスタンバイの違い）
• AWS「Disaster Recovery of Workloads on AWS: Recovery in the Cloud」の「Disaster recovery options in the cloud」（戦略ごとに使うサービス、切り替えの方法）