AWS

【初心者向け】DR戦略の考え方まとめ

はじめに

こんにちは、ハヤシです。
今回は、災害復旧のために必要な「DR」の基本的な考え方について紹介していきます。

そもそもDRとは

DR(ディザスタリカバリ)とは、地震や津波などの災害によって障害が発生した際の復旧および修復、あるいは災害に備えたシステムや体制のことです。
DRシステムの構築にあたり、重視すべき以下2つの指標があります。

RTP(目標復旧時間)

サービス中断から復旧までの目安時間のことです。
例えば「30分で復旧しないといけない!」といった感じで、どれだけ急いで復旧させる必要があるのかを示します。

RTO(目標復旧時点)

どの時点までシステムを復元する必要があるのかの目安時点のことです。
例えば「5分前のデータを復旧しないといけない!」といった感じで、どの時点まで戻ることができれば問題ないのかを示します。
これはバックアップを取る頻度の目安につながります。

DR戦略の考え方

RTP・RTOを基にシステムの構成をする際に、以下の2パターンを考える必要があります。

アクティブ/パッシブ

同じ構成、あるいは本番環境より劣った環境を用意します。
通常時は2台の内1台だけが動き、もう1台は待機状態にあります。
災害が発生すると、待機していたシステムが引き継いで動き出します。

なお、待機状態のシステム構成として以下2パターンがあります。

  • ホットスタンバイ:本番環境相当のものを待機。瞬時に切り替え可能。
  • ウォームスタンバイ:本番環境より劣ったものを待機。数分~数時間程度で切り替え可能。

アクティブ/アクティブ

同じ構成のシステムを複数用意(冗長化)します。
通常時はそれぞれが稼働しリクエストを分け合っている状態です。
災害が発生すると、災害が発生したシステムに対しての遮断と切り替えが瞬時に行われます。
信頼性はかなり高いですがその分コストもかかります。

DR戦略のアーキテクチャ

DR戦略には4つのパターンがあります。

マルチサイト

別々のリージョンに同じ構成のシステムを用意します(アクティブ/アクティブ)
そのため、どちらかのリージョンで災害が発生してもサーバへの影響は最小限に抑えられます。
ほぼリアルタイムで復旧し、データの損失もありません。

ウォームスタンバイ

別のリージョンに本番環境より劣ったものを用意します(アクティブ/パッシブ)
サーバ台数は本番相当より少ない状態で待機させておくため、本番相当のリクエストを必ずしも処理できるものではないです。
数分で復旧し、データの損失もほぼありません。

パイロットライト

ウォームスタンバイと同じように別のリージョンにアクティブ/パッシブな構成を用意します。
この時、インスタンスは停止して待機させておくため、復旧の際にサーバを起動させる工程が必要になります。
数十分で復旧し、データの損失もほぼありません。

バックアップと復元

バックアップ用のファイルのみを保存し別のリージョンにコピーしておきます。
災害発生時にはそのファイルを使用し復元します。
復旧には1時間以上かかり、データ損失はバックアップを取った時間に依存します。

さいごに

以上、DR構築の際に考慮すべき基本的な考え方を簡潔にまとめてみました。
最後までお読みいいただき、ありがとうございました!

返信を残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA