AWS 災害対策オプションまとめ

皆さん、こんにちは。技術開発グループのn-ozawanです。
世界一孤立した有人島としてギネス記録を持つトリスタンダクーニャ島の特産品はロブスターで、日本にも輸出されています。

本題です。
日本は世界有数の自然災害大国と言われることがあります。内閣の防災情報ページによると、世界全体に占める割合が、M6.0以上の地震回数が20.8%、活火山数7%、災害被害額18.3％など、世界の0.25％の国土面積に対して非常に高い割合となっています。システムを構築するにあたって災害に備える必要があります。今回はAWSで構築する際の災害対策をまとめてみました。

災害対策オプション

RPOとRTO

災害が発生し、システムに致命的な障害が発生した場合に備えるのが災害対策です。災害対策を検討する際に重要となるのがRPOとRTOです。

RPO (Recovery Point Objective) は目標復旧時点で、災害により失われたデータを、いつの時点まで復旧すればよいのかの指標です。そのシステムは災害により、どれぐらいデータを損失しても良いのかの指標とも言えます。例えば、RPOを3時間と定めた場合、災害発生の3時間前のデータは保障しなくてはなりません。

RTO (Recovery Time Objective) は目標復旧時間で、障害発生からシステムが完全復旧するまでの時間です。例えばRTOを5分と定めた場合、災害が発生後、5分以内に完全復旧する必要があります。

一般的にRPOとRTOが短ければ短いほどコストは高くなります。以下の図では、一番左にある「バックアップと復元」のRPOとRTOが1時間以上となり、最もコストが低い災害対策です。一方で、一番右にある「マルチサイト アクティブ/アクティブ」は、RPOとRTOがリアルタイムとなっており、最もコストが高い災害対策です。

バックアップと復元

RPOとRTOが数時間の場合に選択する構成です。損失しても業務に支障が出ない場合や、システムが停止しても問題ない場合に選択します。AWSではデータをバックアップするためのサービスが用意されており、別のリージョンにバックアップデータを保存することで災害後の復元を可能とします。

バックアップと復元では、災害後にシステムを迅速に再構築する必要があります。AWS CloudFormationやTerraformなどのIaCでインフラをデプロイしないと、想定以上に復旧時間が長引く恐れがあります。予めIaCで開発することと、IaCのコードを別のリージョンに保存する必要があります。

パイロットライト

RPOとRTOが数十分の場合に選択する構成です。S3やDBなどのデータを別のリージョンにレプリケート（複製）し、サーバーなどのインフラも別リージョンにコピーしておきます。サーバーは普段は停止状態となっており、災害発生時にサーバーを起動、かつ、DBをスケールアップして復旧します。

AWS CloudFormationやTerraformなどのIaCでインフラをデプロイしている場合、データのレプリケートだけを行い、災害発生時に別リージョンに対してIaCでインフラをデプロイする方法もあります。

ウォームスタンバイ

RPOとRTOが数分の場合に選択する構成です。パイロットライトと同様に別リージョンにインフラ環境をコピーします。パイロットライトと違うのは、普段は最小の構成で動作しており、災害発生時は、パイロットライトよりも素早く復旧することが出来ます。

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

リアルタイムでの復旧が求められている場合の構成です。本番環境と同一の環境を別リージョンに構築しておき、どちらもアクティブに稼働します。コストが2倍となりますが、仮に片方のリージョンで災害が発生しても、もう片方のリージョンでは問題なく稼働します。

おわりに

災害に備えるためには、RPOとRTOを考慮して上記の構成を選択するのはもちろんですが、災害発生時の運用マニュアルや、迅速な復旧に向けての日頃の訓練なども必要になります。AWSではフォールトインジェクションサービスという、災害時に発生しうるトラブルをシミュレーションし、適切に復旧できるかのテストが出来るサービスがあります。これらを活用して災害に強いシステムを構築すると良いかと思います。

ではまた。