大規模災害が起こった時の災害対策パターン、基本的なことだけど名前も含めて忘れがちになるので備忘のためにまとめておきます。
前提でわかっておきたいRTO / RPO
災害が起こった時の対策を考える前に、まず理解しておかなければいけないのがRTO（Recovery Time Objective / 目標復旧時間）とRPO（Recovery Point Objective / 目標復旧時点）です。
このRTOとRPOがどのくらい許容できるかが、災害復旧のためのアーキテクチャを選ぶための大前提の要件になります。
災害復旧のための構成を充実しようとすればするほどコストがかかってくるので、このRTO / RPOとコストのバランスを考えて構成のパターンを選択していきます。
RTO（Recovery Time Objective / 目標復旧時間）
RTOは障害が発生してからシステムがまた利用できるまでにかかる目標時間のことです。
この時間が長くなればシステムが使えない時間が長くなり、逆に短くなると災害が起こってもすぐにサービスが利用できるようになります。
災害が発生してしまったときに、特にライフラインに関わるシステムはこのRTOの時間を短くするような設計が必要です。
逆にゲームなど「災害が起こった時は止まっても仕方がないよね」といえるサービスについては長くてもそこまで問題にはなりません。
RPO（Recovery Point Objective / 目標復旧時点）
RPOは復旧作業が発生したときにどの時点の状況に戻すかの目標時点を示したものです。
この時点が大きくなると障害によって失うデータが大きくなり、逆に小さくなると失うデータは少なくなります。
例えば、RPOを1日とすると最大24時間のデータが消え、5分とすると最大5分のデータが消える可能性があります。
これはデータの重要度や、データを失ったときに取れるオペレーションなどを考慮して検討するといいと思います。
例えば、紙の帳簿をインプットする社内システムは紙があれば数日前のデータでも復旧できますが、ECサイトの決済系のデータは損失が許されません。
RTOとRPOのイメージはこちら。
【本題】災害復旧のためのパターン
ここからが本題です。災害復旧のためのパターンを４つ書いていきます。
- バックアップ＆リストア
- コールドスタンバイ / パイロットライト
- ウォームスタンバイ
- ホットスタンバイ / マルチサイト
バックアップ＆リストア以外はRPOを高くすることができます。
また、下に行くほどコストはかかりますが、RTOを短くできます。
コストバランスと求められるRTO / RPOを考えてパターンを選んでいきましょう。システムの重要度が高くなるほど下のパターンを選ぶ必要が出てきます。
また、災害復旧という観点で考えると災害対策用のデータセンターの場所も重要です。
例えば東京のデータセンターが潰れてしまうほどの災害が発生したときにもシステムを止めたくない場合は、関西のデータセンターに災害対策用の環境を用意する必要があります。
さらには、関東・関西のデータセンターが潰れてしまうほどの災害が発生したときもシステムを止めたくない場合は、海外のデータセンターに災害対策用の環境を用意することを検討します。
では、それぞれのパターンについてもまとめていきます。
バックアップ＆リストア
最初の構成パターンはバックアップ＆リストアです。
RTOとRPOが他のパターンよりも大きくなってしまいますが、一番コストを抑えられるパターンです。
災害が発生したときにデータの損失がある程度許容され、サービス停止も長時間許される場合はこのパターンが適切です。
システムを運用していく上でデータはとても大切です。ある程度のデータ損失は許容されても、データを全て失ってしまうとサービスの継続ができなくなってしまうので、最低限バックアップをしておきましょう。
そして、災害復旧のときにはバックアップをリストアしてデータを復元し、システムを構築し直します。
RTOとRPOについて
このパターンのRTOはバックアップしたデータをリストアして構成を作り直すので長くなります。
システムを１から構築する時間とバックアップをリストアする時間を想定してRTOを計算します。
また、人の手が必要な作業もあると思いますが、災害発生したときにオペレーターがすぐに対応できない可能性も考える必要があります。
このパターンのRPOはバックアップの頻度とそれをコピーまたはレプリケーションする頻度に依存します。
日次でのバックアップをしている場合は、最大24時間のデータ損失が発生します。
コールドスタンバイ / パイロットライト
次の構成パターンはコールドスタンバイ / パイロットライトです。
バックアップ＆リストアよりもRTOをRPOを小さくすることができ、ウォームスタンバイやホットスタンバイよりもコストも抑えられるのがこのパターンです。
災害が発生したときにデータは無くなってはいけないけれど、サービスの停止はある程度許される場合はこのパターンが適切です。
災害対策用のデータセンターにデータを同期させるスタンバイ用のデータベースを用意します。
データベースのスペックはコスト削減のために低いものにする場合があります。
コスト削減のために、データベース以外のアーキテクチャ（アプリケーション層など）は構築しません。
災害が発生したら、スタンバイ用のデータベースをマスターにして、残りのサービスの構築します。
RTOとRPOについて
このパターンのRTOはデータベースの構築とデータのリストアが不要な分、バックアップ＆リストアよりも短くなります。
データベース以外の領域を構築し、サービスを再開できる時間を想定してRTOを計算します。
また、人の手が必要な作業もあると思いますが、災害発生したときにオペレーターがすぐに対応できない可能性も考える必要があります。
このパターンのRPOはデータを同期しているため短くなります。
最終のデータ同期タイミングまでのデータが災害対策用のデータセンターに残っているのでデータ損失が発生しにくくなります。
データを同期レプリケーションしているか非同期レプリケーションしているかでRTOが変わります。
ウォームスタンバイ
次のパターンはウォームスタンバイです。
RPOはコールドスタンバイと変わらず、RTOをより短くでき、コストをホットスタンバイよりも抑えられます。しかし、災害が発生したときにサービスのスペックが低くなるのがこのパターンです。
災害が発生したときにデータは無くなってはならず、サービス停止も数分から数時間までなら許容できる、またはサービスのスペックの縮退が許容できる場合はこのパターンが適切です。
コールドスタンバイの構成に加えて、データベース以外のレイヤーもサービスを構築します。
しかし、コスト削減のためにサービスが動く最低限の構成・スペックで構築しておきます。停止しておく場合もあります。
災害発生時は、サービス停止しておいた場合は起動し、リクエストの向き先を切り替えることでサービスが縮退された状態での素早い復旧ができます。
復旧後にスケールアップ・スケールアウトを追って実施することで、段階的にサービスのスペックを通常稼働と同じ状態に合わせられます。
RTOとRPOについて
このパターンのRTOはシステムが構築できているためコールドスタンバイよりも短くなります。
サービスを構築後に停止している場合は起動とリクエストの切り替えにかかる時間を、停止していない場合はリクエストの切り替えにかかる時間を想定してRTOを計算します。
人の手が必要な作業もあると思いますが、構築が事前に済んでいる分、比較的自動化がしやすくなります。なるべくRTOを短くするために自動化を検討します。
このパターンのRPOはコールドスタンバイと同じです。
ホットスタンバイ / マルチサイト
最後のパターンはホットスタンバイ / マルチサイトです。
RPOはコールドスタンバイと変わらず、RPOを最小にできますが、コストが最もかかります。災害が発生したときにも即時に本番環境と同等のスペックを得られるのがこのパターンです。
災害が発生したときにもデータ損失をせずに、短時間で業務復旧する必要がある場合はこのパターンが適切です。
通常の構成と同じ構成を災害対策のためのデータセンターにも構築し、リクエストの切り替えをするだけでサービス継続できる状態にします。
サービスのスペックの縮退もありません。
RTOとRPOについて
このパターンのRTOは最も短くなります。
災害用のデータセンターにリクエストを切り替えるためにかかる時間を想定してRTOを計算します。
リクエストの切り替えもなるべくRTOを短くするために自動化をしましょう。DNSの設定による切り替えができるので自動化もしやすくなります。
このパターンのRPOはコールドスタンバイと同じです。
パターンまとめ
備忘のため、災害復旧のための４つのパターンをまとめてみました。
