クラウドを利用したDRのポイントとは
さまざまな自然災害によってデータセンターが被災してしまい、システムに障害が発生する可能性は常に存在しています。特に日本においては、地震や台風といった災害の被害に合う確率は決して無視できません。そうした災害に常日頃から備え、いざ被災した際には迅速に復旧できる体制を整えることを、DR（Disaster Recovery）と呼びます。本記事では、DRの具体的な方法とクラウドを利用したDRのポイントについて解説します。
なお、DRとよく似た言葉にBCP（Business Continuity Plan）があります。BCPとは、災害やテロなどの緊急事態が発生した際に損害を最小限にし、事業の継続や復旧を図るための計画のことです。どちらも災害に備えるという点では同じような意味を持つ言葉ですが、サーバーなどのシステムに対する備えを指す場合にはDR、事業全体の復旧計画を指す場合にはBCPが使われることが一般的です。
本記事をご覧いただいた方向けに、おすすめの記事をまとめました。こちらもあわせてご確認ください。
DRの考え方
いざ災害が発生した際には、データの喪失を起こさず、ダウンタイムなしで運用を継続できるのが理想ですが、それには大きなコストがかかるため、どこかで折り合いをつける必要が出てきます。そこで、重要となるのがシステムを過去のどの時点まで復元するかの目標値である「RPO（Recovery Point Objective）」とシステムの復旧までにかかる時間の目標値である「RTO（Recovery Time Objective）」です。どちらも「○○秒」や「○○時間」といった単位で表されます。
これらの目標値を決定するには、まずDRの対象となるシステムの経過時間ごとのビジネスインパクトを分析する必要があります。
極端な例ですが、RPOを1秒とすると障害が発生する1秒前までのデータを復旧させる必要があります。この場合、データの喪失は非常に少なくなりますが、秒単位でデータのバックアップを取得しなければならないため、バックアップにかかるコストが非常に大きくなってしまいます。対してRPOを1時間とすると、直近1時間のデータは失われてしまう可能性がありますが、バックアップの頻度が下がるため、バックアップにかかるコストを小さくすることが可能です。
システムが長時間停止したりデータを喪失した際に発生する損失とRPO/RTOを短くする際にかかるコストを天秤にかけ、システムが許容できるデータの喪失期間や停止時間の限界を決定することが大切です。こうして、目標とするRPO/RTPや許容できるコストが決定できたら、実際にDRを実現する具体的な方式を検討していきましょう。
DRの具体的な方式とは
代表的なDRの方式には、「ホットスタンバイ」「ウォームスタンバイ」「コールドスタンバイ」「バックアップ&リストア」があります。
いずれの方式もシステムを復旧させるという目的は同じですが、それぞれ達成できるRPO/RTOとかかるコストが異なってきます。前述の通り、RPO/RTOを小さくしようとすればするほどかかるコストは大きくなってしまいますので、システムが目標とするRPO/RTOと許容できるコストによって、最適なDR方式は異なってきます。
ホットスタンバイ
「ホットスタンバイ」は、主環境と同等のDR環境を事前に作成しておき、稼動状態で待機させておく方式です。
災害発生時はDR環境に切り替えるだけで運用を継続できるため、本節に挙げた方式の中ではRPO/RTOを最も小さくできる方式です。しかし、主環境と同等のDR環境を常に待機させておく必要があるため、環境の維持にかかるコストも大きくなります。「コストがかかってもよいのでRPO/RTOを可能な限り小さくしたい」という場合に有効な方式です。
バックアップ&リストア
「バックアップ&リストア」は、最も低コストで実現可能なDR方式です。
定期的に主環境のデータのバックアップを安全な場所へ保存しておき、災害発生時にはシステムを再構築した後にデータをリストアして運用を再開します。平常時にはバックアップデータの保持以外にコストがかからないため、非常に低コストではじめられる反面、災害時には環境の再構築からはじめなければならないため、RTOが大きくなりがちです。また、最新のバックアップから災害発生時までのデータも喪失してしまうため、RPOも大きくなります。
「長い停止時間やデータの喪失を許容する代わりにコストを小さく抑えたい」という場合には、バックアップ&リストアを選択するのもよいでしょう。
ウォームスタンバイ/コールドスタンバイ
上記2つの方式の中間に位置するのが、「ウォームスタンバイ」と「コールドスタンバイ」です。
どちらもDR用の環境を最小の構成で事前に作成し、ウォームスタンバイは稼動状態で、コールドスタンバイは停止状態で待機させておきます。災害発生時にはサーバーの起動・スケールアップ・スケールアウトといった作業を行い、主環境と同等の状態へ拡張して切り替えを行います。
事前にDR環境を準備しておくという点ではホットスタンバイと同じですが、最小構成で待機させることで、待機時のコストを小さく抑えているのがポイントです。ただし、その代償として切り替え前にサーバーの起動やスケールアップなどの作業が発生するため、RTOはホットスタンバイに比べてやや大きくなってしまいます。「ホットスタンバイほどDR環境の維持にコストをかけたくないが、バックアップ&リストアのRPO/RTOは許容できない」といった場合の折衷案として有効な方式です。
DRにクラウドを利用するメリット
前述の「ウォームスタンバイ」「コールドスタンバイ」や「バックアップ&リストア」では、災害発生後にDR環境のスケールアップや再構築が必要となります。しかし、ハードウェアの調達や設定に時間のかかるオンプレミスにおいて、災害発生後にこうした作業を短時間で行うのは困難でしょう。しかし、「低コストで利用可能」「オンデマンドにリソースの追加が可能」といった特長を持つクラウドを利用すれば、オンプレミスと比較して短時間、かつ低コストでDR環境を構築・維持することができます。
また、複数のリージョンで構成されているクラウドサービスであれば、DR環境をあえて地理的に離れた別リージョンに待機させることで、地震のようなロケーションに起因する災害への耐性も高めることができます。
クラウドを利用したDRの構成例
クラウドを利用したDRのよくある構成例が、東日本と西日本といった複数のリージョンを組み合わせ、主環境とDR環境を構築するパターンです。前述の通り、主環境とDR環境を同一のリージョン内に構築してしまうと、地震のような特定のロケーションに大きな被害の出る災害発生時に両方の環境が影響を受けてしまう可能性があるためです。
FJcloud-V(旧ニフクラ)では、ネットワーク機能の「プライベートブリッジ」を提供し、東日本/西日本の一部リージョン間でプライベート通信が可能です。プライベートブリッジを利用すれば、東西リージョンでのDR構成を比較的容易に構築することができます。詳細につきましては、プライベートブリッジの機能・サービスページをご確認ください。
また、FJcloud-V(旧ニフクラ)でのDR/バックアップの代表的な構成をFJcloud-V(旧ニフクラ) クラウドデザインパターンでご紹介しています。詳細なDR/バックアップの構成を知りたい方は、ぜひご確認ください。
