はじめに
この記事は Japan AWS Jr. Champions Advent Calendar 2023 の17日目の記事です。
DR(Disaster Recovery)対策、してますか？
先日のJr.Championsの勉強会でDR対策に関して話しましたので、その内容をこちらの記事にも留めておきたいと思います。
DR対策を語るときには、まずそこで想定される「災害」とは何かということを考えなくてはいけません。
この記事での「災害」とは、リージョン内のすべてのAZが機能停止に陥るような、大規模広域被災を想定しています。
そのため、ここで語るDR対策も「リージョン内でAZ冗長を組む」というものではなく、「リージョン全体が機能停止したときに、他リージョンでサービスを復旧できるようにする」というものになります。
AWS上のDR対策の選択肢
AWSでのDR対策の考え方として、AWSからは4つの選択肢が提示されています。
- Backup & Restore
- Pilot Light
- Warm standby
- Multi-site active/active
詳細はこちらのドキュメントをご確認ください。
↑の記事がいい感じにサマリされているクラメソ様の記事も載せておきます。
なんやかんやで Backup & Restore 採用されがち
当然ですが、DR対策にはコストがかかります。
そしてコストは最小限に抑えたい。
という背景で、DR対策として「Backup & Restore」が採用され、
東京リージョンでサービスを展開している場合、平常時は大阪リージョンにバックアップを送り、有事の際は大阪リージョンでリストアを行う、という方針を取るケースが多い
、、というのが筆者の肌感覚です。
「Backup & Restore」の場合、バックアップを別リージョンに送っておくということが大前提となるので、環境構築の際はそこだけに焦点が置かれがちです。
AWS Backup を使えばその設定も簡単！
しかし、バックアップを送る、という設定だけで「Backup & Restore」は成り立つのでしょうか。
キャパシティ保証についても考えてほしい！
「Backup & Restore」という名前の通り、有事の際は確実にDR先リージョンでリストアを行う必要があります。
そして重要なことは、「Backup & Restore」を採用しているユーザは自分たちだけではないということです。
いざ有事の際にリストアを行うと思ったとき、そのリージョンで多くのユーザのDR環境が乱立し、キャパシティが食いつぶされ、結果としてリストアに失敗してしまう
という可能性が否定できないのです。
サービス継続のためのDR対策。
その検討で見落とされがちなのが、このキャパシティの観点かなと思います。
キャパシティ予約を使いましょう！
キャパシティ予約を利用することで、DR先リージョンで確実にリストアできる可能性が高まります。
キャパシティ予約については、以下の記事が分かりやすかったです。
キャパシティー予約とは、該当するインスタンスタイプの EC2 Instance を任意の時間に「起動可能」であるというキャパシティーを予約する権利のことです。
キャパシティ予約の利用料金については以下の通り。
キャパシティ予約を買ったとしても、実際にそのキャパシティ分のリソースを起動していれば、結果的にキャパシティ予約のために追加料金が発生するということにはなりません。
インスタンスをリザーブドキャパシティで実行しているかどうかにかかわらず、オンデマンドの場合と同等の料金がキャパシティ予約に課金されます。
予約を使用しない場合、この予約は Amazon EC2 請求書に未使用予約として記載されます。
予約の属性に一致するインスタンスを実行するときは、そのインスタンスの料金のみを支払い、予約に料金はかかりません。
例えば、20 個の m4.large Linux インスタンスに対してキャパシティーの予約を作成し、同じアベイラビリティーゾーンで 15 個の m4.large Linux インスタンスを実行すると、15 個のアクティブインスタンスと予約されている 5 個の未使用のインスタンス分が課金されます。
コスト削減のための提案
キャパシティ予約のためのコストを最小化したい、、
そこで提案したいのが、開発環境をDR先リージョンに設けるという発想です。
平常時は開発環境としてEC2を起動させておき、キャパシティ予約で確保した分のリソースを利用します。
そして、そのキャパシティ予約をDR環境のあるアカウントに共有しておきます。
復旧時は開発環境のEC2を停止させて、解放されたキャパシティ予約の枠を利用して、確実にリソースを起動させます。
開発環境と本番環境をセットで用意されている方で、「Backup & Restore」によるDR対策を検討されている方は、ぜひ上記ご検討いただければと思います。
終わりに
発表後、参加者の皆様からコメントをいただき、AWS側ではリージョン全体が機能停止することは想定されていないということを伺いました。
現実的には、リージョン全体よりAZの、しかもそのAZの一部の機能の障害が頻度も高く、そのような事象への対策のほうが重要度は高めです。
以下、ご連携いただいた参考リンク。
・単一アベイラビリティーゾーンでのアプリケーション障害からの迅速な復旧
・Zonal autoshift – Automatically shift your traffic away from Availability Zones when we detect potential issues
・AWSで障害に強いシステムを構築する方法
とはいえ、システムのBCP要件によっては、AZ内の障害への備えはもちろん、リージョン全体に影響が及ぶ被災についても考えておく必要があります。
そのようなケースで、ご検討材料の一つにキャパシティ予約の利用を含めていただけると幸いです。
そもそも、そのような障害、激甚災害が発生しないことを祈りつつ。
お付き合いいただきありがとうございました。