企業の大切なデータやシステムを守るために、忘れてはならないのがディザスタリカバリです。ディザスタリカバリは、万一の災害時に業務への影響を最小限にとどめ、サービスを途切れることなく提供していくために不可欠な仕組みですが、いったいどのようなものなのでしょうか。
ここでは、ディザスタリカバリの意味や重要性のほか、実施方法やおすすめのソフトウェアなどについてご紹介します。
目次
1 ディザスタリカバリとは災害復旧のこと
ディザスタリカバリ（英語：Disaster Recovery）は「DR」とも略され、「予期せぬ災害によって、システムダウンしてしまう等の障害から復旧すること」を意味します。
地震や津波などの天災だけではなく、テロ、不正侵入、オペレーションミスなどによるシステムダウンやデータの損傷が起こった際、早期の復旧・修復を図り、顧客へのサービスの継続性を保つこと、もしくは、これらの作業を実行するシステムや体制を指します。
1.1 ディザスタリカバリが重要な理由
多くのサービスがデジタルネットワークによって提供されている現在では、システムダウンはサービスの提供停止を意味します。災害復旧の対策をとっていない場合、システムダウン前の状況に戻すには、多くの時間とコストがかかることになります。売上機会の損失や顧客への補償といった直接的な損害だけでなく、危機管理の不備を露呈することで、企業価値が大きく下がることも考えられるのです。こうした事態を避ける上で、ディザスタリカバリは重要な役割を担います。
万一に備えるディザスタリカバリは、平常時には投資効果を得られません。ですが、昨今の頻発する災害の経験から、「ディザスタリカバリこそ企業の生命線」という認識が広まり、今や多くの企業が導入を推進しています。
1.2 ディザスタリカバリと事業継続計画（BCP）の違い
ディザスタリカバリと混同されることが多い用語が、「事業継続計画（BCP）」です。
事業継続計画とは、災害などの緊急事態の際に、企業の損害を最小限に抑え、事業の継続や復旧を図るための計画のことを指します。事業継続計画は、事業の存続を目的として、事業の継続に必要なあらゆる要素を対象とし、指示系統や管理体制などにも関わります。一方、ディザスタリカバリは、データやサーバーなどのシステム関連の復旧を行います。
つまり、ディザスタリカバリは事業継続計画の一部として含まれていると考えるとわかりやすいでしょう。事業の継続には、システムの復旧が欠かせないため、事業継続計画とディザスタリカバリはセットにして対策を講じる必要があります。
2 ディザスタリカバリのメリット
企業が万が一の場合に備え、ディザスタリカバリを導入する主なメリットは、下記が挙げられます。
2.1 損失を最小限にできる
災害等によってシステムが損傷すると、さまざまな部門・業務に悪影響が及び、業務効率が低下します。この間は通常の利益を上げることができず、むしろ予定外のコストがかかる状況となります。
しかし、ディザスタリカバリを導入していれば、こうした事態であっても迅速に復旧することが可能なため、悪影響を最小限にとどめることができるでしょう。
2.2 企業の信頼向上
システムダウンやサービスの停止は、顧客にも自社にも不利益を与え、顧客からの信頼を損ねてしまいます。しかし、ディザスタリカバリによってサービスの品質低下や停止を回避できたり、早期の復旧が実現できたりすれば、顧客からの評価につながり、企業の信頼を得る機会にもできます。
3 ディザスタリカバリを策定する際の3つの指標
ディザスタリカバリを構築するにあたり、重要視すべき3つの指標をご紹介します。それが、「RTO」「RPO」「RLO」です。
＜ディザスタリカバリ策定における3つの指標＞
・RTO：「いつまでに」システムを復旧させるか
・RPO：「いつまでの」データを復旧させるか
・RLO：「どの程度まで」システムを復旧させるか
いずれもプランニングの際に目標値として設定するのですが、目標値を高めれば当然ながらコストアップにつながります。システムの損傷によって被る損失と、それを回復させるためにかかるコストを見比べながら、目標値を設定することが大切です。
3.1 RTO（Recovery Time Objective）：目標復旧時間
RTOは、損傷したシステムやデータを、いつまでに復旧するか、その所要時間を表します。設定値は、秒単位から日単位での設定が可能です。
システムの機能が損なわれている間は業務に支障が出てしまうため、復旧させるまでに使う時間をどこまで許容するかの検討が必要です。業務上、システムに頼る度合いがどれ程かによって、RTOの設定は変化します。RTOの値が小さければ、より損失を抑えることができ、サービスを中断させる時間が短くて済むため、信頼の獲得にもつながるといえるでしょう。しかし、その分コストはかかります。
3.2 RPO（Recovery Point Objective）：目標復旧時点
RPOは、損傷したデータを過去のどの時点までさかのぼって復旧するか、その時点を表します。例えば、「30分前まで」「3時間前まで」という具合です。
RPOを30分に設定した場合、災害が起きた時点から最長で30分前までのデータは、すべて失われてしまいます。RPOを短時間に設定する程コストが増大するので、データのやりとりの状況も考慮した上で、設定しましょう。
3.3 RLO（Recovery Level Objective）：目標復旧レベル
災害時のデータの損失については、前述のRTOとRPOが主な指標として使われますが、RLOはシステムの機能的な障害をどの程度まで復旧させるかという、機能的レベルについての指標です。通常時の稼働状態を100％として、何％まで復旧させるかを表します。
RLOの数値が100％に近ければ通常の稼働状態に近く、それだけ損失は少ないといえます。しかし、RLOは障害の程度に加え、「いつまでに何％まで回復させ、その後どれ程の時間をかけて完全復旧するか」というように、時間軸も関係しています。そのため、RTOと関連付けて検討されるのが一般的です。もちろん、各段階でどの機能から回復させるか、その優先順位の見極めも重要です。
4 ディザスタリカバリを実現する方法
目標とするRTO、RPO、RLOや許容できるコストが決定できたら、実際にディザスタリカバリを実現する具体的な方式を検討します。
ここで特に重点を置きたいのは、データベースのディザスタリカバリです。なぜかというと、多くの企業では肝心な基幹情報やお客様情報はをデータベースに保存し管理しており、これは企業の重要な資産とも言えるものになっています。したがって、ディザスタリカバリを策定するにあたり、データベースのディザスタリカバリ策定が肝となるといっても過言ではないでしょう。
過去には、データをメディアに記録し、遠隔地に移送して保管するという方法が主流で、現在でも一部でそうした手法がとられています。しかし現在では、「遠隔地バックアップ」、あるいはスタンバイサイトを構築する「レプリケーション」のいずれかで対応している企業が多いといえるでしょう。
4.1 遠隔地バックアップ
遠隔地バックアップとは、必要なデータを定期的にバックアップし、それを遠隔地のサーバー、あるいはAWSやAzureといったクラウドサービスに保管しておきます。バックアップデータの保管先は、地震や風水害など、広範囲にわたって被害が及ぶ事態も考慮すると、システムが稼働している場所から離れた地域を選ぶのが常道です。
以前に比べれば比較的低コストで実施できますが、データ量が大きくなると、それだけ強力なネットワークが必要になること、大規模災害時には通信障害が起こりやすいため復旧までに時間がかかる可能性があるという不安要素もあります。
4.2 レプリケーション
平常時に稼働させているものとまったく同じ待機系システムを、スタンバイサイトとして用意しておき、障害発生時にこちらに稼働を切り替えることで、業務の継続とデータの保護を可能にするのがレプリケーションです。AWSやAzureといったクラウドサービスでも、レプリケーションによるディザスタリカバリサービスが提供されています。主な導入先としては、短時間でも停止すると大きなダメージを受けるシステムや、社会インフラを支えるシステムなどです。
スタンバイサイトはリアルタイムでの更新を続けるレプリカなので、RTOをほぼゼロにできるのが強み。一方、同じシステムを複数用意することになるため、単純計算で2倍のコストがかかってしまうことや、ウイルスなどの不適切なデータまで複製してしまう可能性があることを覚えておきましょう。
また、レプリケーション導入前は下記を確認しておく必要があります。
・ホットスタンバイか、コールドスタンバイか
スタンバイサイトをホットスタンバイにするか、あるいはコールドスタンバイにするか。これは復旧効果とコストのバランスを検討した上で、判断する必要があります。
ホットスタンバイでは待機系システムにも常に電源が投入され、稼働している運用系と相互に監視し、異常を検知すると即座に待機系システムに稼働が切り替わります。対してコールドスタンバイは、障害の発生を検知してから、手動あるいは自動で待機系システムを起動します。
ホットスタンバイはハードとソフト、さらに運用面でもコストが膨らむ傾向がありますが、一瞬たりとも止められないシステムであれば、こちらを選ぶことをおすすめします。
・物理（フィジカル）レプリケーションが導入できるかどうか
レプリケーションは、物理（フィジカル）レプリケーションと論理（ロジカル）レプリケーションの2つの方式があります。ディザスタリカバリでのレプリケーションは、完全に近いレプリカを作成するという意味から、物理レプリケーションが強く推奨されます。ですが、環境や状況によっては、非常に高額なコストがかかるため、導入に踏み切れないという悩みも少なくありません。
例えば、「Oracle Data Guard」にはフィジカル・スタンバイが用意されていますが、これはOracle SE2（Standard Edition 2）では利用できず、非常に高額なライセンスコストがかかるOracle EE（Enterprise Edition）のみで利用可能です。そのため、「物理レプリケーションを使いたいが、コストが膨らみすぎる」という、悩ましい問題が生まれてしまいます。
「レプリケーション」については、下記のページをご覧ください。
レプリケーションとは？バックアップとの違いやおすすめツールを解説
5 ディザスタリカバリソフトなら「Dbvisit Standby」がおすすめ
「Dbvisit Standby」は、物理レプリケーションを使用したOracle Databaseおよび、Microsoft SQL Server向けのディザスタリカバリソフトウェアです。今後、PostgreSQLやMySQLへ対応する予定です。
初期の設計を済ませてあれば、わずか数分でインストール完了。ユーザーフレンドリーなGUI搭載で、スタンバイサイトの構築から日々の運営までを簡単な操作で行えます。さらに、ディザスタリカバリの実行にあたり懸念されるいくつもの課題を、「Dbvisit Standby」なら解決できます。
5.1 「Oracle Data Guard」に代わる機能と低コストを実現
「Dbvisit Standby」は、基本的なアーキテクチャは「Oracle Data Guard」と同一。ただし、「Dbvisit Standby」なら、「Oracle Data Guard」が使えないOracle SE2上でも物理レプリケーションを実行できます。そのため、ディザスタリカバリのためだけにOracle EEを用意する必要がありません。
また、AWSやAzureのようなクラウドサービスではなく、アプリケーションですので、簡単な操作によって自社内で管理運営でき、コストの点でも有利です。
さらに、全く同一の構成のデータベースを複数作れる点を活かして、待機系システムのほかにさらなるレプリカを作成し、それを開発環境として活用したり、非常時に備えた訓練フィールドとしたりという使い方も可能です。
5.2 AWSでの可用性を拡大できる
オンプレミスからクラウドへ移行する際は、現状と同じ機能を確保できるかが問題になります。例えば、自社で運用しているOracle RACからAmazon EC2に移行する場合、Amazon RDSのような、サーバー停止時に自動的に待機システムに切り替えるフェイルオーバーサービスが利用できません。
ですが、こうした場合にも「Dbvisit Standby」の導入によって、フェイルオーバーや手動で待機システムに切り替えるスイッチオーバーが実現でき、さらに「Dbvisit Standby」ならではの各機能を利用できます。「Oracle Data Guard」と同等以上の機能性を得ることで、AWSでの可用性を大きく広げることができます。
こちらにdbvisitを利用してスイッチオーバーが高い信頼性で短時間で実現することができた事例をご紹介します。
Pythianのディザスタリカバリソフトの導入事例ダウンロード
6 効率的なディザスタリカバリのために
自然災害の多い日本では、ディザスタリカバリは避けて通ることのできない重要課題です。ですが、「もしものときへの備え」であるからこそ、必要十分な機能性は不可欠ですし、同時にコストとのバランスも検討しなくてはなりません。
「Dbvisit Standby」なら、110以上の国々のお客様の稼働実績があり、さまざまな障害から重要な情報を保護しています。例えば、大規模かつ複雑な在庫管理の運用を行っているセブンイレブン・フィリピンでは、ハリケーンによるシステムや運用へのリスクを軽減させるため、DRソリューションとして「Dbvisit Standby」を採用し、80%以上ものコスト削減を実現しております。
「セブンイレブン・フィリピンの導入事例」については、下記のページをご覧ください。
事例紹介｜セブンイレブン･フィリピン｜Dbvisit Standbyで、ディザスタリカバリに80%以上ものコスト削減を実現
また、私たちインサイトテクノロジーは、日本国内でも多くの企業様に「ディザスタリカバリソフト- Dbvisit Standby」を導入した実績があります。ご興味がある方は、下記バナーより、ディザスタリカバリソフトの事例資料をダウンロードできますのでご覧ください。
また、「Dbvisit Standby」導入やディザスタリカバリプランの構築を検討中で、一度話を聞いてみたいという方は、ぜひデータベースの専門家集団であるインサイトテクノロジーにご相談ください。
