東日本大震災以降、企業のITインフラ構築には「DR対策」が求められる傾向が強まっています。一般的なサーバー運用においても障害は常に想定されるものですが、災害を原因とする障害は、これとは性質が異なります。なぜなら、システムの停止期間・規模から影響範囲が大きくなりやすいからです。では、DR（Disaster Recovery：ディザスタリカバリ＝災害復旧）の考え方に基づき、事業停止による損失のリスクを最小限に留めるためのサーバー環境はどう構築すべきなのでしょうか。ここでは、DR対策の具体例を解説していきます。
目次
DRの実例から見える「DR対策」とは？
2011年3月11日の東日本大震災以降、企業ではDR対策が注目されるようになりました。
東日本大震災では、サーバーやネットワーク機器の損壊によって業務システムがダウンし、業務を一時停止せざるを得ない事態が多数発生したからです。以降、BCP（事業継続）対策のなかでも、DR対策が特に重視されるようになり、現在ではDR対策を織り込んだシステム構成が主流になっています。
ここで、東日本大震災時のシステム障害事例を紹介します。仙台市の某政府機関では、地震後の津波によってハードウェアが水没・損壊・流出し、復旧のための資材も揃わない状態に陥りました。何とかシステムを復旧させるために、近隣の業者から取り寄せたハードウェアとバックアップデータによって臨時代替システムを構成し、稼働にこぎつけたとのことです。しかし臨時代替システムの稼働までには1週間を要し、その間にも水没したハードウェアを泥水から引き上げるなどの作業を余儀なくされました。水没したハードウェアからバックアップデータを回収できたことは、不幸中の幸いと言えるでしょう。
また、別の例では、計画停電に備えてUPSを設置していたものの、設定ミスや経年劣化によって正しく動作せず、強制的な電源断が引き起こされたとのこと。せっかくのUPSも、常日頃のチェックとメンテナンスを怠れば、無用の長物と化してしまうわけです。
こういった事例からは「バックアップ」や「緊急用電源の確保（UPS）」といった一般的なDR対策が機能していないことが散見されます。その理由としては、「オンプレミス環境において本番システムとバックアップ環境が同時にダメージを受けたこと」や「電源を含めたサーバー設置環境の脆弱さ」が挙げられるでしょう。つまり、リスク分散とメンテナンスが十分ではなかったと言えます。
DR対策を踏まえたサーバー環境構築とは？
これまでの内容を踏まえ、大規模災害に耐えうるDR対策の具体例を3つ紹介します。
○バックアップデータの遠隔地保管
災害によって本番環境が停止したとき、最初に手配すべきはバックアップデータです。前述した事例にもあるように、バックアップデータが確保できるか否かで、システムが復旧する可能性は大きく変わります。遠隔地保管を行っておけば、バックアップデータを何らかの方法で本番環境へ移行し、サーバーを構築した上でリストアする、という復旧プロセスが可能になります。データを守ることが最優先であり、復旧までに多少の時間を要して良い場合に有効です。
○リモートサイトにレプリケーション
遠隔地保管のデメリットである復旧までの時間を短縮するためには、リモートサイトへのレプリケーションがおすすめです。本番環境が何らかの要因でダウンしてしまっても、サイト間切り替えにより短時間でシステムを復旧させられます。ただし、リモートサイト用のサーバーと切り替え作業（リストアと切替え）が必要になるため、相応の労力・コストがかかります。
○グローバルクラスタの活用（半自動的なリストア）
リストアと切替えの労力を削減したい場合には、グローバルクラスタの活用が有効になるでしょう。グローバルクラスタは、遠く離れたサーバー同士をつなぐことで、HAクラスタシステムを構築します。
HAクラスタとはシステムの可用性を高めるための手法で、複数のサーバーを連携して構築することで、稼働しているサーバーが何らかの要因でダウンしてしまっても、スタンバイ状態にある別のサーバーが処理を引き継ぎます。いわゆる「フェールオーバー」が可能になるため、システムの停止時間を最小限に抑えることが可能になります。
これら3つの方法のうち、いずれを採用する場合でも、オンプレミス環境のみでの構築は現実的とは言えません。また、ハイブリットクラウド（パブリッククラウドとプライベートクラウドの併用）であれば実現は可能ですが、リモートサイトを運用しているクラウド環境が障害を起こす可能性もあります。
例えば、2019年8月に起こったAWS東京リージョンの障害では、国内多数のサービスに影響が生じました。この障害は自然災害によるものではなく、サーバーの冷却装置にトラブルが生じ、過熱状態に陥ったことから引き起こされています。しかし、世界的に知名度の高いAWSでの障害は、自然災害によるトラブルに通じるものがあるでしょう。あのAWSでさえ、些細な冷却システムのトラブルから不測の事態が発生するわけです。したがって、単一のクラウドサービスに頼ったDR対策はリスクが高いと考えられます。
マルチクラウドを活用したDRのメリット
そこで注目すべきが、「マルチクラウド」です。複数のクラウドサービスを活用するマルチクラウドを活用すれば、いざというときの「逃げ場」を比較的容易に確保できます。異なるベンダーが提供するクラウドサービスを活用することで、本番環境とバックアップ・リストア環境を安価に併存させることができます。
また、複数のサービスを平行利用できるため、自社独自のカスタマイズが可能であったり、ベンダーロックイン※1を防止できたりといった点も見逃せません。マルチクラウドを上手く活用することで、冗長化やリスク分散を容易に行えるため、DR対策として優れているのです。
ただし、マルチクラウドの導入では、ベンダーの選定に注力する必要があります。サービスを提供しているクラウドベンダーが持つ安定性や拡張性、可用性などを総合的に判断し、マルチクラウド環境を構築していきましょう。
※1：ベンダーロックイン……特定のベンダーから提供される機能・技術に依存してしまい、他サービス・製品への乗換えが困難になること。システムの柔軟性や拡張性を確保しにくくなるというデメリットがある。
まとめ
本稿では、DRの実例と有効な対策について紹介してきました。DR対策の基本はバックアップとリストアにあります。この2つをいかにスムーズかつ確実に行うかが、DR対策の要諦といえるでしょう。大規模災害が起こると、自社以外も甚大なダメージを受けることは確実です。そのため、できるだけバックアップ、リストアの候補を分散させておくべきでしょう。分散・冗長化が容易なマルチクラウドの活用で、DR対策を踏まえたサーバー環境を構築してみてはいかがでしょうか。
