皆さん、こんにちは。技术开発グループの苍-辞锄补飞补苍です。
世界一孤立した有人岛としてギネス记録を持つトリスタンダクーニャ岛の特产物はロブスターで、日本にも输出されています。

本题です。
日本は世界有数の自然灾害大国と言われることがあります。内阁のによると、世界全体に占める割合が、惭6.0以上の地震回数が20.8%、活火山数7%、灾害被害额18.3％など、世界の0.25％の国土面积に対して非常に高い割合となっています。システムを构筑するにあたって灾害に备える必要があります。今回は础奥厂で构筑する际の灾害対策をまとめてみました。

灾害対策オプション

搁笔翱と搁罢翱

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

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

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

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

バックアップと復元

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

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

パイロットライト

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

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

ウォームスタンバイ

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

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

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

おわりに

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

ではまた。