ディザスタリカバリとは?BCPとの違いやRPOとRTO、DR対策導入のポイントを解説

    地震や台風など、災害が多い日本において注目されているのが「DR(ディザスタリカバリ/災害復旧)」という考え方です。この記事ではディザスタリカバリの言葉の意味や、BCPとの違い、指標、DR対策導入のポイントなどを解説します。

    ディザスタリカバリとは?

    ディザスタリカバリ(Disaster Recovery)とは、災害・障害時にシステムを復旧する事や、災害に備えた措置や体制を指します。 2011年の東日本大震災以来、「災害復旧」として広く知られるようになりました。

    地震や津波といった天災だけでなく、悪意のある不正侵入などによりシステムを意図的に破壊するといった犯罪も絶えません。このような予期せぬ状況を想定し、復旧、修復を実現するのがディザスタリカバリシステムです。

    また、ディザスタリカバリシステムを構築するうえでは、ダウンタイムを最小限にすることも重要。一度システムが破壊されてしまうと関連する事業そのものが停滞してしまうことも少なくありません。事業を継続させるために、ディザスタリカバリシステムにおいては、建物を含むハード面がどれほどの壊滅的被害を受けた場合であっても、データを損失しないよう、普段のバックアップの運用体制や、複数の遠隔拠点での運用などを検討する必要があります。

    しかし、ディザスタリカバリシステムがデータを扱う事業者にとって必要不可欠であるとはいえ、強固にすればするほど費用がかかってしまうという問題も。ディザスタリカバリシステムの構築を進める場合、コスト面を考慮して、どのレベルまで対策を講じるべきか、費用対効果を検討する必要があります。

    DRとBCPの違いとは?

    ディザスタリカバリシステムとともによく聞かれる用語として「BCP」があります。BCPとは「事業継続計画」を意味し、地震や台風などの天災や火災、テロ攻撃などの緊急事態において、企業が事業資産の損害を最小限にとどめ、事業を継続するための戦略をまとめた計画のことです。

    BCPには、緊急時の対応方法だけでなく、平常時に行うべき活動や手段なども含まれます。大規模な地震やテロなどの危機が発生したときに企業が事業継続のために守るべき、オフィス環境やデータセンター、従業員など、すべての経営資源がこの中には含まれているのです。そんなBCPにおいて、システムの早期復旧や修復を担うのがディザスタリカバリシステムです。

    RPOとRTO

    ディザスタリカバリシステムの構築にあたり、重要視すべき指標が2つあります。1つ目は、目標復旧地点であるRPO(Recovery Point Objective)、そしてもう1つが、目標復旧時間であるRTO(Recovery Time Objective)です。それぞれについて説明します。

    RPO(目標復旧地点)

    RPO(Recovery Point Objective)は、障害が発生した際、時間の流れをどの地点までさかのぼったシステムのデータを復旧させるかを表す指標です。

    例えばRPOが「10日間」であれば、システムが停止する10日前までのデータを復旧でき、「0秒」であれば、システムが停止した直前までのデータを復旧できるということです。

    RPO(目標復旧地点)が過去日になればなるほど、多くのデータを失うことになります。RPOが短い時間になればなるほど、復元できるデータ量は増えますが、その反面、データレプリケーションといった技術が必要となるため、コストも増加します。

    そのため、業種に応じたRPOの設定が必要。銀行などのデータの正確性や完全性が重視される業種のシステムにおいてはRPOをできるだけ短くすることが求められます。

    RTO(目標復旧時間)

    RTO(Recovery Time Objective)は、破損したデータをいつまでに復旧するのかを示めす指標です。

    例えばRTOが「3時間」であれば、システムの復旧を3時間以内に行うということ。RTOは、事業を継続させるという観点から、BCP策定の際にも重要視されます。

    RTOもRPOと同様、短いに越したことはありませんが、やはりコストにもつながるため、提供する製品やサービスなどの性質や、顧客との契約条件などを考慮して検討する必要があります。

    DRソリューションを選ぶ際のポイント

    ディザスタリカバリシステムの導入において、選定するソリューションはどのように選べばよいのでしょうか。事業継続を行ううえで、できるだけシステムにデータ欠損がなく、短期間に復旧したいと考えますが、コストもかかってしまうもの。どんな機能でどれだけの効果を期待するかをバランスよく考えていくことが大切ですが、この点から考えていくと、マルチサイトクラスタ構成は外せない機能と言われています。ここでは、DRソリューションを選ぶ際のポイントを解説します。

    レプリケーションの性能

    最初に考えるべきなのは、レプリケーションの性能です。レプリケーションは、ハードウェアを含め同じシステム環境を2組あらかじめ用意しておくことを指します。2組のシステムは、一方で実稼働を行い、もう一方は待機用として用います。常にデータの同期を行っているため、障害が発生するとすぐに、待機用に制御が切り替わり、システムを続行することができます。レプリケーションを行わずバックアップのみで対処する考えもありますが、バックアップはリアルタイムなデータの更新が難しいため、障害時や誤操作などによるデータの消去や破損への対応が十分にできません。かといってレプリケーションだけで高可用性を実現できるわけではなく、バックアップの併用は必須の条件となります。

    理想的なDRサイトの構築が可能か否か

    被災時においては、事業継続という観点からDRサイトの構築が有効です。セキュリティやメンテナンス性を考えて社内にサーバーを設置するオンプレミス運用では、災害においてシステムを守ることに不安が残るためです。多くのシステムが、クラウド運用へ移行したり、オンプレミスとクラウドといった2つの環境を併用したりしています。中にはAzureとAWSなど、異なるクラウド間でのマルチクラウドを行うシステムもあり、それが可能なソリューションも提供されています。DRサイトの構築では、遠隔地にバックアップシステムを配置して、災害時にサービスを継続させる構成が理想的です。そのためには、マルチサイトクラスタ構成が効果的。マルチサイトクラスタは、メインサイトとバックアップサイトをそれぞれHAクラスタ化して、アクティブスタンバイ構成をする方法です。

    コスト

    全く同じ機能やデータをもち、どちらを稼働させても問題なく運用ができるシステムを2組用意するDRサイト運用においてはコストがかかります。特にDRシステムを自社内に用意しようとすれば、DR用のデータセンターを構築し運用しなければなりません。いくら事業継続のためとはいえ、災害が起こらなければ使う機会のないシステムに対してそれほど大きなコストをかけることは難しい場合もあるでしょう。コストの問題を少しでも解消させるべく、自社リソースからクラウドサービスへシステムを変更させている企業も少なくありません。

    トライアル期間の有無

    DR対策としてソリューションを採用する場合に気になるのが、非常時において問題なく稼働できるのかということでしょう。緊急時のデータ復旧やシステム切り替えは、スムーズに行えればよいですが、多くのステップがあったり、機能選択が多いがためにうまく切り替えができなかったりする可能性があります。DRソリューションを選定する際には、これらの使い勝手は実感することができません。この不安を解消するためには、トライアル期間が設けられているシステムを使ってみることがよいでしょう。トライアル期間で、既存の環境をDRリューションでどのように移行し、どのように運用するかを検討することで、自社のシステムにとってふさわしいソリューションなのかを見極め、導入の判断ができます。

    隔地レプリケーションとマルチクラウドにも対応。「LINBITクラスタスタック・サポートDR」

    LINBITクラスタスタック・サポートDRは、遠隔地レプリケーションとマルチクラウド対応という、DRシステム構築、運用に有効な手法を低価格で実現することができるソリューションです。オプションで用意されているDRBD Proxy転送アクセラレータソフトウェアを使用することで、回線速度や品質が保証されていないWANやVPNであっても、快適で安定したデータバックアップが可能。一般的に企業で使用されているWAN回線やVPN回線では回線遅延が発生しやすいのに対し、DRBD Proxyを使うことで定的に遠隔地レプリケーションを行うことができます。

     

    SNSでもご購読できます。