BCP・DRで有効な対策とは？ポイントは「クラウド」の活用

サムネイル

こんにちは、富士通クラウドダイレクトのMです。

先日の「中小企業のエンジニアこそ知っておくべき『BCP（事業継続計画）』の基礎知識」の記事では、災害などの有事の際に被害を最小限にし、事業の継続や早期の復旧を図るための計画である「BCP（事業継続計画）」について、基礎から解説しました。

一方で、「BCPが何かはわかったけど、何を対策として盛り込めばいいの？」と感じた方もいるかと思います。BCPに盛り込むべき対策は業種などによっても異なりますが、例えば製造業の場合、原材料や部品の調達先の複数化、代替拠点の確保と整備などが必要になります。また、これらの業務プロセスを遂行するにあたって考慮しなければならないのが「ITシステム」であり、対策の重要性は極めて高いといえます。

BCPのうち、ITシステムに関する対策のことを「DR（Disaster Recovery）」といいます。今回は、DRの概要から、DRにクラウドを活用するメリットまで、中小企業のエンジニアの方や情報システム部門の方向けに詳しく解説します。

DRとは

DRとは、「Disaster Recovery（災害復旧）」の略で、災害などでITシステムが被害に遭った場合に迅速に復旧するための機能や体制を整えることをいいます。

DXなどを目的に業務のデジタル化が急速に進む中、ITシステムはビジネスと切り離せない存在になっています。一方で、何らかの要因でシステムに不具合が生じ、業務が停止するリスクも同時に高まっています。業務の停止が長引けば、顧客の流出やシェア率の低下など、経営への大きなダメージにつながる可能性もあります。

そのため、有事の際もシステムを止めないよう日頃から備えておくこと、すなわちDRに取り組むことは企業にとって必須ともいえます。

DRの指標となる「RPO」と「RTO」

ITシステムにおいては、災害時もデータの損失などを起こさず、ダウンタイムなしで運用し続けられることが理想的です。とはいえ、そのような高い可用性を維持するための対策には、それ相応のコストがかかります。すべてのシステムに同様の対策を講じるのは費用面でも現実的ではないため、どこかで妥協する必要があるでしょう。

そのため、まずは対象のシステムについて、不具合が生じることによるビジネスへの影響を分析し、データ損失やシステム停止の許容期間などを検討、そのうえで対策のレベル感を決めることが重要です。そして、その際に指標となるのが「RPO（Recovery Point Objective）」と「RTO（Recovery Time Objective）」です。

RPO・RTO

RPOは「目標復旧時点」という意味で、システムやデータを過去のどの時点まで遡って復元するか決めるための指標のことをいいます。「日・時・分・秒」の単位で表され、RPOを1秒として設定した場合は、不具合が起きた1秒前までの状態に復旧させることになります。この場合、データの損失などは限りなく少なくできますが、秒単位でのバックアップが必要なためコストは増えることになります。

一方、RTOは「目標復旧時間」を意味し、システムの復旧までにかかる時間の目標値のことをいいます。こちらも「日・時・分・秒」の単位で表され、RTOを2日として設定した場合は、不具合が起きてから2日以内に復旧させることになります。

このように、RPO・RTOともに短ければ短いほどコストがかさむのが特徴です。システムのDR対策を考える際は、システムやデータの不具合による損失とコストとのバランスをよく検討したうえで、その妥協点としてRPO・RTOを決定するのがよいでしょう。

DRを実現するための方式

対象のシステムのRPO・RTOが決まれば、次はDRを実現するための具体的な方式を検討するステップになります。代表的なものとしては次の4つが挙げられますが、それぞれ達成可能なRPO・RTOやかかるコストが異なるため、注意が必要です。対象のシステムのRPO・RTOとコストの許容範囲に合わせて、最適な方式を選択しましょう。

DRの方式と概要

ホットスタンバイ

ホットスタンバイは、事前にメイン環境（メインシステム）と同等の構成でDR環境（予備システム）を用意しておき、稼働させた状態で待機させる方式です。

これにより、メイン環境に不具合が起こった際も瞬時にDR環境に切り替えて運用できるため、RPO・RTOを限りなく短くし、システムや事業への影響を最小限にすることが可能です。そのため、官公庁や金融機関のシステムなど、わずかな停止も許容できないシステムの場合はホットスタンバイになります。

ただし、メイン環境と同等の機能を持つDR環境を常時稼働させておくことになるため、最もコストがかかる方式ともいえます。

ウォームスタンバイ

ウォームスタンバイは、ホットスタンバイと同様、事前にメイン環境とは別でDR環境を用意しておき、稼働させた状態で待機させる方式です。ただし、DR環境の構成をメイン環境と同等ではなく、最小限のスペックで用意する点がホットスタンバイと異なります。

DR環境を最小限の構成で待機させることで、ホットスタンバイと比較してコストを抑えることが可能です。一方で、最小限の構成のためそのままの状態でメイン環境から切り替えても使用することはできません。

有事の際は切り替え前にサーバーの設定作業（スケールアップ・スケールアウト）を実施し、メイン環境と同等の構成にパワーアップさせる必要があります。そのため、瞬時に切り替えができるホットスタンバイと比較すると、RTOはやや長くなる点に注意が必要です。

コールドスタンバイ

コールドスタンバイも、ウォームスタンバイと同様、メイン環境とは別で最小限のスペックで構成したDR環境を用意しておく方式です。主な違いはDR環境の「待機方法」です。ウォームスタンバイはDR環境を稼動させた状態で待機させるのに対し、コールドスタンバイは停止させた状態で待機させます。

最小限の構成かつ停止状態で待機させることで、ウォームスタンバイよりもさらにコストを抑えられます。一方で、普段はサーバーが停止しているため、有事の際は切り替え前にサーバーの起動から実施する必要があります。また、サーバーが停止していることで、メイン環境とのデータの自動同期なども実施できません。そのため、サーバーの起動に加えデータのリストア（復元）作業も必要です。

このように、スケール作業（メイン環境と同等の構成にパワーアップさせる作業）以外にも作業が必要なため、ウォームスタンバイよりもRTOは長くなります。

バックアップ・リストア

上記の方式は、いずれも事前にメイン環境から切り替えるためのDR環境を用意しておくものです。一方、バックアップ・リストアは、メイン環境のデータのバックアップを定期的に取得・保持しておき、有事の際はメイン環境と同等のシステムを再構築してバックアップからデータをリストアすることで、運用を継続・再開する方式です。

この方式は、普段はバックアップのデータを保持しておく以外にコストが発生しないため、シンプルかつ最も低コストな方式といえます。ただし、事前にDR環境を用意していないため、有事の際はイチからシステムを再構築する必要があり、RTOは他の方式と比べて長くなります。また、最新のバックアップ取得から不具合発生時点までのデータは失われるため、バックアップの頻度によってRPOも長くなります。

バックアップを取得・リストアするための方法はさまざまで、データを外付けHDDなどのメディアに記録して社内で保管する方法や、メディアが破損してデータに損失が出ないよう、メディアそのものを堅牢な金庫で保管したり、コピーを遠隔地に保管しておいたりする方法などがあります。メイン環境と同じ状態のデータがリストアできるのであればどんな方法を選択しても問題ありませんが、方法によってはRTO・RPOが非常に長くなる場合もあるため、注意が必要です。

DR対策には「クラウド」の活用がおすすめ

これまで紹介した「ウォームスタンバイ」「コールドスタンバイ」「バックアップ・リストア」の方式では、いずれも有事の際にDR環境のスケール作業や、システムの再構築が必要です。システムをオンプレミスで運用している場合、メイン環境と同等の構成にする、あるいは再構築するためには、新たな機器調達や設定が必要なため時間がかかります。もし機器の調達が遅れれば、システムの停止はさらに長引くでしょう。このようなリスクを回避し、迅速な復旧を実現するためにおすすめなのが、「クラウド」の活用です。

クラウドなら、オンプレミスのような機器調達は必要なく、オンデマンドでリソースを追加することが可能です。そのため、オンプレミスよりも圧倒的に短い時間でDR環境を構築できます。さらに、DR環境をあえて地理的に離れた場所（別リージョン）に構築することで、地震などの地域特性が要因となる災害などへの耐性も高めることも可能です。

また、コスト面から見てもクラウドがおすすめです。BCPの観点から、ITシステムのDR対策は非常に重要といえます。しかし、いつかわからない「もしも」に備えて普段は利用しない環境を用意するのはコストになるため、できれば抑えたいというのが本音です。

その点、クラウドはオンプレミスのように機器を購入する必要はなく、定期的なリプレイス作業も発生しません。そのため、初期費用を抑えるだけでなく、DR環境の運用保守にかかるコストも限りなく抑えることが可能です。

オンプレミスとクラウドの比較