災害復旧対策（ディザスタリカバリ）

G社は、全国に営業店をもつ、中堅の専門商社である。現在、東京の本社ビルの一室をサーバルームとして、社内業務システムを運用している。今年度の事業計画に事業継続計画の策定が挙げられていて、その一環として、本社ビルのサーバルームが災害などで使用不能となった際の対策を検討することになった。

【G社の社内業務システム】

現在、G社の社内業務システムには、会計、販売管理、人事の三つのシステムがあり、それぞれWebシステムとして実現している。社内業務システムのネットワーク構成を図1に示す。各Webサーバはアプリケーションサーバの機能も有しており、仮想サーバで実現している。データベースサーバ（以下、DBサーバという）は2台のクラスタ構成で、全システムで共用している。営業店から社内業務システムへはIP-VPN経由でアクセスしている。

各システムにアクセスする際のURLを表1に示す。ロードバランサでは、URLのパスから対応するシステムのWebサーバにPCからのリクエストを振り分けている。また、複数台あるWebサーバの負荷分散も行っている。

営業店のPCが社内業務システムにアクセスする際は、DNSを利用してwebap.example.co.jpのIPアドレスを取得してアクセスする。DNSサーバのIPアドレスは、PCの起動時に各営業店のDHCPサーバから配布される。現在、プライマリDNSサーバとして、192.168.10.3が登録されており、セカンダリDNSサーバは未登録である。DNSに登録されているリソースレコードの情報を表2に示す。

DBサーバ上のデータベースのバックアップは、フルバックアップと更新ログから成る。毎日深夜1時にフルバックアップを取得し、過去1週間分をNASに保管している。また、1時間ごとに、その1時間の間に発生したトランザクションの更新ログを採取し、1ファイルとしてNASに保管している。フルバックアップの取得は30分以内、更新ログの採取は5分以内に完了する。データベースが壊れた場合は、フルバックアップと、フルバックアップ取得後からデータベースが壊れるまでに採取した更新ログから、データベースを復旧する。

【災害復旧対策】

災害復旧対策において目標とする復旧のレベルの指標として、目標復旧時間（RTO：Recovery Time Objective）及び目標復旧時点（RPO：Recovery Point Objective）を用いる。RTOは、システムが使用不能になった時（以下、災害時刻という）から、業務が再開されるまでに掛かる時間の目標を表す。RPOは、災害時刻にどれだけ近い時刻の状態にデータを復旧できるかの目標を、災害時刻との時間差で表す。RTOとRPOを検討した結果、RTOは24時間、RPOは1時間とした。

別の拠点に、本社ビルと同等のサーバルームを用意するのはコストが掛かり過ぎ、実現が難しい。そこで、低コストで災害復旧対策を実現する方法を調査したところ、クラウドサービスを利用する方法があることが分かった。調査したクラウドサービスでは、コストは、サーバが稼働している時間、使用しているストレージの容量、及び下りデータの通信量に応じて掛かるので、サーバを停止していれば安価になると考えた。

各システムのWebサーバのイメージファイルから、クラウド上にWebサーバを作成し、DBサーバには本社と同じデータベースを作成しておく。DNSサーバは本社と同じ設定でセカンダリDNSサーバとして使えるように機能しておく。通常時は、ロードバランサ、Webサーバ、DBサーバは停止しておく。本社でデータベースのバックアップを作成次第、クラウドのNASにアップロードする。被災運用が発動された際は、ロードバランサ、DBサーバを起動して、データベースを復旧し、Webサーバを起動して動作確認をした後、DNSの登録内容を変更して被災運用を開始する。被災運用時システムのクラウド上のネットワーク構成を図2に示す。

【被災運用の発動手順】

実際に被災運用が発動された際の手順を表3のとおり定めた。また、各作業に必要な時間を表4に示す。全システムの動作確認が完了する前に、営業店から被災運用時用システムにアクセスすることがないよう、DNSの変更は手順の最後にした。

動作確認の際は、DNSを利用せず被災運用時用のロードバランサのIPアドレスを用いる。