今回ご紹介するのは「ディザスタリカバリ」です！
２０１１年の東日本大震災など、自然災害とその復旧に注目が集まる昨今、
コンピュータシステムもまた、
どのように復旧作業を行うかは重要ポイントです。
たとえ企業の地元に災害の影響が無くても、
データを管理しているサーバが被災地にあったため
事業を再開できなかった例も多くありました。
そんな事態に備えるため、近年企業がこぞって対策しているのが
「ディスタリカバリ」です。
お前のスマホも使えなくなるし、このページも公開できなくなるぞ。
今回は、災害からコンピュータを救うための仕組み
ディザスタリカバリについてお送りします！
「ディザスタリカバリ」って何なの？
ディザスタリカバリとは英語では「Disaster Recovery」と書き、
自然災害などの不測の事態に対応する災害対策システムです。
通販システムや銀行のシステムなど、
主に企業が運営しているコンピュータシステムを復旧することを指します。
復旧手段を考えるときに大事なポイントは、
- どのくらいの鮮度のデータまでさかのぼるかを示す「目標復旧地点」
- いつまでに復旧するかを示す「目標復旧時間」
の２つです。
- ”昨日までの５種類の登録データまで復旧する”と決めるのが「目標復旧地点」
- ”明日までにデータを復旧する”と決めるのが「目標復旧時間」
- 目標復旧地点のことを「ＲＰＯ（Recovery Point Objective）」
- 目標復旧時間のことを「ＲＴＯ（Recovery Time Objective）」
と呼びます。
「ＲＴＯ」と「ＲＰＯ」の違いは？どうやって使うの？？
ここから、「ＲＴＯ」と「ＲＰＯ」にスポットを当てて解説しましょう。
前述した通り、
- ＲＴＯは「地点」
- ＲＰＯは「時間」
を基準にした値です。
身近でわかりやすい例として、Windowsパソコンをお使いの方は
「復元ポイント」という言葉を聞いたことがありませんか？
この復元ポイントが「ＲＴＯ」に当たります。
あのアプリのインストール前の状態まで戻す、という指定ができますね。
対して「ＲＰＯ」は、
ＰＣをいつまでに復旧させると使う人の影響を最小限に抑えられる？という視点です。
例えば銀行システムなら、
- ＲＴＯ：災害発生日時の１時間前までの取引データまでを復旧しよう。
- ＲＰＯ：平日にＡＴＭの利用が多くなるから、休日含めて３連休の間に全て復旧できるようにしよう。
とかになりますね。
復旧が翌週の月曜日以降になったら、企業の業務に影響してしまうからな。
そう、ＲＴＯとＲＰＯを決定する上で大切なのは
- スピード
- コスト
です。
業務の再開に影響する範囲は最小限にしなければなりません。
上記で例に挙げた銀行システムは、スピードを重要視する代表例ですね。
完璧に復旧できるとしても復旧までに３年かかってしまうようでは、
日本中の経済が止まってしまいます。
そして３年も復旧作業をしていたら、
その間の人件費など費用が膨大になってしまいますね。
ここでも「働き方改革（！？）」効率良くコストカットが望ましいわけです。
またコストの面から言うと、そもそも「ディザスタリカバリ」自体が
システム運営にかかわる「保険」に当たります。
保険の契約って、どの程度の保証を付けるか悩みますよね？
色々オプション契約は付けたいけれど、月々の支払は抑えたい・・・など。
企業としても、自前のデータサーバを地方に置くことが
逆にコスト増大のリスクを抱えることになるので、
別のクラウドサービスに任せようか、ということも考えられます。
このように、どのデータ、どのシステムに対してどこまで非常事態に備えるのか、
十分検討する必要があるのです。
ディザスタリカバリとは？RTOとRPOの差は？わかりやすくご紹介します おわりに
いかがでしたでしょうか。
ディザスタリカバリは、災害に備えた復旧作業です。
システムを運営する企業としては「保険」として押さえておくべき仕組みですね。
ＲＴＯはどこまで巻き戻すか、ＲＰＯはいつまでに治すか。
復旧への重要度と用途と予算によって、適切に設定したいところですね。
最後までお読みいただきありがとうございました。
