DR対策に課題をお持ちの方向け！クラウド活用によるDR対策方法を徹底解説します

1.災害復旧(DR)とは？

1-1.DRの意味について

最初に、DRとは何かを簡単におさらいしておきましょう。
「知ってるよ！」という方は読み飛ばしてください。
まず、「DR」とは「Disaster Recovery」の略で、日本語に訳すと「災害復旧」となります。

システムが何らかの原因で使用できなくなってしまった時に、そこから復旧するための備えのことです。言葉としては、よく「DR対策」という使い方をされます。
災害と言うと地震や台風などの自然災害を思い浮かべるかも知れませんが、それ以外にも、電力不足といった技術的な障害や操作ミスによるシステムの停止も含まれます。

これら「システムが使えなくなる事態」全般が「災害」であり、それに対する備えがDR対策です。

1-2.DR対策の実現方法

では、どうやってDR対策を実現するかとなると、「パイロットライト」「ウォームスタンバイ」「マルチサイト」などなど、方式はいくつもあります。

ここで各方式の詳細はご説明しませんが、今例に挙げた各方式の共通点は、
「メインサイトが使えなくなったら、DRサイトに切り替える」という点です。
つまり、何らかの形でDRサイトを用意することになります。

2.クラウド以前のDR対策（オンプレミス）

クラウド登場以前なら、DR対策を実現する方法は、オンプレミスということになります。
しかし、これはかなり大変です。
DRサイトを用意するとなれば、当然そこに設置する機器を購入して、データセンターを確保して、さらに日々のメンテナンスも必要となります。

お金も労力もかかってしまうわけですから、「DR対策するぞ！」と覚悟を決めなければ、なかなか手を出しづらいものでした。
しかも、災害が発生しなければ、システム自体の老朽化に伴ってリプレースの日を迎え、DRサイトはまったく使われないまま終わる、ということにもなります。

もちろん、DRサイトの出番がないのはよいことなのですが、使うかどうかわからないならコストは抑えたいのが人情です。

3.クラウドがDR対策に向いている要因（メリット）

クラウドが登場したことで、DR対策実現のハードルは格段に低くなりました。
要因を考えてみましょう。
サン・エム・システム（株）ではAWSとAzureに力を入れていますので、この2つのクラウドを引き合いに出しながらご説明します。

また、実際にクラウドを導入した事例を知りたい方はこちらから資料請求が可能です。

3-1.クラウドのロケーション

まず、クラウド自体が複数の離れた場所でサービスを展開していることが挙げられます。
クラウドの実態は複数のデータセンターの集まりです。

１つ以上のデータセンターをまとめたグループを、
AWSやAzureでは「アベイラビリティーゾーン」と呼びます。
さらに、アベイラビリティーゾーンの集まりを「リージョン」と呼びます。



例えば、AWSなら日本国内だけでも「東京リージョン」と「大阪リージョン」があるため、
東京リージョンにメインサイトを用意し、大阪リージョンにDRサイトを用意する、という使い方ができます。

AWSやAzureといった超有名どころのクラウドは世界中に展開していますから、国外のリージョンを使うことも可能です。

3-2.データの保管方法

ここでDR対策に必要な要素は何か、という根本に立ち返ってみたいのですが、もっとも基本的なことは「データの損失を防ぐ」ということではないでしょうか。
その点、クラウドでははじめからデータの損失を防ぐようなサービスが数多く提供されています。

例えば、Azureのストレージサービスである「Azure Storage」は、デフォルトでデータをコピーし、
同じデータを合計3つ持ちます。
そのデータの配置場所にもいくつかのオプションがあるのですが、その中でも単純かつ効果的なのが「ゾーン冗長ストレージ（ZRS）」です。

これは1つのリージョンの中で3つのデータセンターにコピーを分散させるというもので、
データセンター単位の障害に対応できます。
もちろん、リージョンをまたいで分散させるオプションも用意されています。



データをコピーして万が一に備えることが、クラウドではデフォルトで実現できたり、オプションを選択したりするだけで簡単に実現できてしまうのです。

3-3.コストを抑えやすい

最後は、何と言っても安さです。
オンプレミスなら機器の初期導入費用、データセンターの賃料、メンテナンスの人件費や部品代などがかかります。
DRサイトでメインサイトとまったく同じスペックを実現したいとなれば、同じ機器を用意するわけですから、単純計算で2倍の費用がかかります。

しかし、クラウドでは多くのサービスで従量課金制となるので、まず最低限必要なリソースで使い始めて足りなくなったら増やす、という使い方ができます。

それを踏まえて、例えば、AWSはDRサイトの方式の一つ「ウォームスタンバイ」を実現するやり方として、「普段DRサイトは低スペックで安価なサーバを稼働させておき、いざDRサイトに切り替える場合には、スペックを上げて（スケールアップして）処理を行う」という方法を提示しています。

これは、簡単にスペックのスケールアップ・スケールダウンが可能なクラウドだからこそなせる業と言えるでしょう。



それどころか、さらに費用を抑えたいのであれば、
DRサイトではサーバを停止しておく、という方法も可能です。
同じくAWSが提示している「パイロットライト」の実現方法は、「DRサイトにデータ（データベースのデータのことです）は同期しておくが、処理を行うサーバは停止しておく」というものです。

この方式では、DRサイトに切り替える時に初めてDRサイトにサーバを起動させます。
AWSではサーバの使用料は起動していた時間に応じて課金されるため、そもそも起動しなければ料金がかからない、というわけです。



なお、当然のことながら、クラウドであっても高スペックの仮想マシンを使ったり、大量のデータをストレージに保存したりすれば、使用料も高くなります。

とは言え、ハードウェアのメンテナンスはクラウドベンダーにお任せできるということを考えれば、やはりクラウドの費用対効果は高いと考えられるでしょう（ハードウェアだけでなくミドルウェアまでクラウドベンダーが管理する形態（PaaS）やソフトウェアまでクラウドベンダーが管理する形態（SaaS）もあります）。

そして、安いということは、DRサイトを構築する費用も抑えやすいということに他なりません。
先に例を示した「ウォームスタンバイ」や「パイロットライト」のような構成にすれば、
DRサイトを用意するのにメインサイトの2倍の費用は必要ないわけです。

何らかの事情でメインサイトをオンプレミスにする必要があったとしても、DRサイトはクラウドにする、という戦略も考えられます。

近年、クラウドとオンプレミスを連携する仕組みも大いに発達しています。
必要なデータをオンプレミスからクラウドに同期しておき、災害が発生してオンプレミス環境が使えなくなってしまったら、クラウド上のデータで業務を継続する、ということも可能です。

4.クラウドのデメリット

このように見ていくと、クラウドでDRサイトを構築するのはよいことばかりにも見えますが、
クラウドにはクラウドならではの特徴や弱点があります。

これはDR対策に限らず、メインサイトをクラウドに構築したり、オンプレミスからリプレースしたりする際にも考慮が必要なものですが、何点か挙げてみましょう。

4-1.ネットワークが接続できることが大前提となる

クラウドはインターネットの向こう側に、各種サーバを配置し、データを保管して、それを利用するものです。
ということは、そこにアクセスするためのネットワークが確保されていなければ使い物になりません。

オンプレミスなら、例えば本社の一角にサーバルームがあるような場合なら、社内LANで繋げば社内サーバは利用できます。

4-2.カスタマイズの自由度は下がる

オンプレミスでハードウェアを一から選定するような場合なら、ベンダーや機種を自由に選べますし、
スペックも思い通りの組み合わせにしやすいでしょう。
対して、クラウドの場合は、クラウドベンダーが用意したものから選ぶことになります。

例えば、Azureのサーバ「Windows Virtual Machine」の価格表を見てみると、
CPUコア数・メモリサイズ・一時ストレージの容量の組み合わせが決まっています。

汎用的な「Bsシリーズ」を例にとると、CPUコア数が1の場合、メモリは1GiBか2GiBで、
一時ストレージサイズは4GiB固定です。
CPUコア数1、メモリ4GiB、一時ストレージ8GiBという組み合わせは選べません。

ここではサーバのスペック、つまりハードウェア寄りの部分を例に挙げましたが、ミドルウェアやソフトウェアでも同様です。

ミドルウェアやソフトウェアまでクラウドベンダーが管理してくれるサービスは、すぐに使い始められ、こちらの管理の手間を減らすこともできるというメリットがある一方で、自分好みにカスタマイズする余地は小さい、ということになります。

服に例えると「自分の体形に合わせてオーダーメイドで服を作る（オンプレミス）」のと「既成の服から自分の体形で着られるものを選ぶ（クラウド）」との違いです。

4-3.クラウドに障害が発生したら手が出せない

2019年8月23日にAWSの東京リージョンで障害が発生し、日本国内でAWSを利用している多くの事業者が影響を受けました。障害が起きたこと自体は問題ではありません。
AWSの思想はそもそも「機械はいつか壊れるし、障害は起きるもの。それを前提として、耐えられるシステムを作るべき」というものだからです。

クラウドならではの特徴は、クラウドで障害が発生したら、クラウドベンダーが復旧してくれるのを待つしかない、という点です。

オンプレミスなら、現地にエンジニアを送って状況を把握でき、こまめに進捗を確認することもできるでしょう。しかし、クラウドの場合はそうはいかない、ということです。

この障害が起こった時、「こういうことがあるからクラウドは安心できない」という意見も聞かれたのですが、 そうではなく「こういう場合でも事業を継続するためにどうしたらよいか」と考えるべきでしょう。それがまさにこの記事のテーマなのですから。

例えば、この事例は東京リージョンで発生しましたが、大阪リージョンにDRサイトがあればそちらに切り替えて事業を継続できたかも知れません。

また、手が出せないとは言っても、この2019年8月23日の障害については、12:36に障害が発生し、同日18:30にはほぼ復旧しました。

またAWSは、障害発生から、わずか2日後の8月25日に、事象の経緯や影響範囲について詳しい説明を公開しています。このスピード感は、決して遅くないでしょう。

（ついでに個人的な意見を書くと、オンプレミスで現地にエンジニアを派遣できたとしても、復旧を待つしかないのはクラウドと同じなので、大した違いはないと思います。エンジニアにこまめに報告させて急かしたところで、復旧が早くなるわけでもありませんからね。）

5.DR対策、検討してみませんか？

5-1.DR対策が必要な状況

ここまで、DR対策と、DR対策にクラウドが適している理由について書いてきましたが、何でもかんでもDR対策すればよいかと言われれば、それは違います。

DR対策の大前提として、「災害が発生しても稼働させ続ける必要があるか？」を検討すべきです。検討した結果、災害発生時には停止を許容するのであれば、DR対策は不要となります。

ですから、システムのすべてをDR対策する必要もないわけで、例えば、「顧客情報が入ったデータは何が何でも守る、社内決裁のシステムは最悪止まってもよい」などといった切り分けが必要です。

5-2.DR対策の検討方法

DR対策が必要だという結論に達したら、その実現方法を検討します。今回は、クラウドであればDR対策実現のハードルが低いという観点でお話ししてきましたが、検討すべきことはまだまだあります。

例えば、「どのクラウドを使うのか」「どの方式を採用するのか」。

これらは、「予算はどのくらいか」「障害発生からDRサイトへの切り替え完了までの時間はどこまで許容できるか」などの要素を元に決めていく必要があります。

最初に述べた種々の「災害」への備えとしてのDR対策は、クラウドの登場と普及により、今や「贅沢品」ではなく「手が届くもの」になっています。

「DR対策なんて御大層なもの、うちには関係ないよ」と考えていた方も、ぜひ一度、検討してみてください。

サン・エム・システムは、AWSのSelect Consulting PartnerかつAzureのCloud Solution Providerです。確かな知見と技術で、お客様の事業をお手伝いいたします。
「どこから手を付けたらよいかもわからない......」、そんな場合でも遠慮なくご相談ください。

サン・エム・システムがプロフェッショナルとしてご支援いたします。

ご相談はこちらから　https://www.sun-m.co.jp/service/onestopcloud/

こちらの記事もおすすめ！

• 【徹底解説】Amazon API Gatewayの落とし穴！使用時の注意点とは？
• AWS CDKv2の開発者プレビュー版をさわってみた
• AZ-900: Microsoft Azure Fundamentalsの取得
• AWS認定資格に合格するためにやったこと

参考

• AWS でのディザスタリカバリ (DR) アーキテクチャ、パートI：クラウドでのリカバリの戦略
• Azure Storage の冗長性
• Windows Virtual Machines の料金
• 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要