こんにちは藤城（@tafujish）です。RDB関連のエントリーは別の人が書いてくれたので、久しぶりにRDB以外の話をします。
最近、DR（Disaster Recovery）に関連したお問い合わせが多いため、IDCFクラウド上でのDR、つまり災害復旧を可能とする事前対策を紹介しようと思います。
ちなみに、DRやBCPといったワードについては用語集をご参照ください。
そもそも、IDCFではクラウドサービスを提供するずっと前から、DRを意識したデータセンターの建設を行ってきました。
www.idcf.jp
地震や台風など天災が多い日本では、DRに対して需要が多くあり、IDCFではクラウドサービスにおいても次のようなDRを意識したサービスを提供してきました。
一方で、ドキュメントも提供しており、IDCFクラウド本の6.4章では、RPO（Recovery Point Objective）とRTO（Recovery Time Objective）の考えから構成例までを紹介しています。
また活用マニュアルでは、MySQLレプリケーションによるデータ同期を用いたDRサイトの構築手順をwordpressを例に紹介しています。
www.idcf.jp
他にもsambaによるファイルサーバーを同期する方法を紹介しています。
www.idcf.jp
と、前置きが長くなりましたが、上述のとおり事前にDRを考慮した構成にしていれば問題はないのです。しかし、既存のサイトを急にDR対応する必要がでてくることもあると思います。そのようなときに、後追いでDRサイトを準備する具体的な方法を紹介していきたいと思います。（もしこれからサイトを構築する話であれば上記ドキュメントを参考にしてください）
前提
ここでは、WEBサーバーとDBサーバーがあるような構成のサイトのDR化を検討していきます。DR化を考えたとき、3つのレベルに分けることができます。
1. データを退避する
災害時に一番困ることは、サービスが停止することではなく、データが消失することです。そのため、まずはデータを災害から保護するために退避させます。データの退避は、更新があったときや、頻繁にあるようであれば定期的に実施します。災害時にはそのデータからDRサイトを再構築し復旧します。データの退避先は、DRサイトの近くにあるとデータのリストアが速く理想です。
2. サーバー環境含めて事前に構築する
災害後の復旧のためにサーバー環境を再構築するには時間がかかりサービスの復旧が遅くなってしまいますので、事前にサーバー環境まで構築します。災害時には、DRサイトへの切り替えを行う程度なので構築しなおすより復旧までの時間を短くできます。
3. 災害時には自動で切り替わる仕組みまで構築する
災害時にDRサイトへ手動で切り替えるとなると、その分の時間がかかりますしそもそもその作業が実施できるかもわかりません。そこで、即時復旧する仕組みを用意します。そのためには、ネットワークの自動切り替えやデータを同期する仕組みが必要です。
1から3になるにつれて、復旧までの時間は短くなっていきますが、構築の手間や費用などインフラコストは大きくなっていきます。ここでは、手軽に導入することを目的として1の方法を扱います。
次の構成のとおり、メインサイトのみで稼働しているサイトにDRサイトを追加していきます。データを退避させるネットワークの経路としては、点線のインターネット側と実線のインターナル側がありますが、これについては後述します。
どんなデータを退避させるか
まずは最低限、DB上のデータを移す必要があります。バックアップ用にダンプを取得していると思いますので、このファイルを退避させます。
次にコンテンツデータですが、これらのファイルも退避させた方が良いでしょう。Git系のサービスや社内のデプロイ環境を使っているなら、そこから戻すことも考えられますが、災害時に利用できるかどうかわからないですからね。予備用と思って退避しておくのが良いと思います。
その他に、サーバー構築に必要なパッケージファイルや設定ファイルもあれば退避させるのが良いですが、可能であればOSやミドルウェア周りはテンプレートとして保存しておくと、再構築しやすいので良いと思います。（IDCFクラウドではテンプレートのリージョン間コピーができます）
どこにデータを退避させるか
基本的には、再構築する環境に物理的にまたネットワーク的に近いところ、可能であれば同じところに保存しましょう。
ある程度ファイルサイズが大きくなると思いますので、DRサイトと同じネットワーク上など距離が近いところに置き、帯域とレイテンシを確保して素早く戻せるようにしておきます。
また、災害時せっかく退避したデータにアクセスできないと元も子もないので、災害時にもアクセスできる必要があります。つまり、メインサイトとDRサイトの物理的な配置はある程度把握しておき、物理的な距離を確保しておく必要があります。IDCFクラウドであれば、東西リージョンに分けて使うだけで物理的な距離、電力会社、ネットワーク経路などDRに必要な要素を網羅しています。
どうやってデータを退避させるか
ファイルの転送であれば特別な実装はいらないため導入しやすいと思います。Linux環境であればデータの差分等考えるとrsyncコマンドを利用するのが簡単で良いと思います。転送先のサーバーへSSHできることが条件です。例えば次のように実行できます。
# rsync [オプション] <コピー元> <コピー先>
/opt/backupfile 以下をDR先（192.168.1.97）へ転送する例だと次のように実行します。
# rsync -ahv /opt/backupfile root@192.168.1.97:/opt/
どのタイミングでデータを退避させるか
データの更新がどこまで頻繁にあるかに依存します。ほとんど更新がなければ更新したタイミングや週次での実行で良いですし、もう少し更新頻度があれば日次での実行でも良いです。日次や週次の定期実行であれば、cronで定期実行できます。日次で実行したい場合、上記のrsyncのコマンドをスクリプトファイル（rsync.sh）として
/etc/cron.daily/rsync.sh
へ設置すると簡単だと思います。
もし、日次よりも頻度を上げたい場合は、lsyncdを使ってファイルの更新を検知し同期するということも可能です。
このときに指定するIPアドレスがグローバルIPアドレスであれば、インターネット側の経路での通信となります（先述の構成図の点線の部分）。
IDCFクラウドならではの構成
上述のとおり、ファイルを自動で同期すると、その頻度やデータサイズによっては時間がかかってしまうこともあると思います。また、データの内容によってはセキュリティの考慮が必要になるケースがあると思います。
このような場合は、閉域でセキュアに接続でき高帯域を使えるプライベートコネクトがおすすめです。東日本リージョンと西日本リージョンを簡単に接続すること（先述の構成図の実線の部分での転送）が可能です。追加ネットワーク費用（月額1万円×2ゾーン）分はかかりますが、プライベートコネクト自体には費用はかかりません。
既にIDCFクラウド上に環境があれば、次の流れで導入できます。
1. 追加ネットワーク作成
プライベートコネクトの接続には、追加ネットワーク経由で利用します。
追加ネットワーク作成し、仮想マシンを接続するまでの流れは次のブログを参照ください。
blog.idcf.jp
記事中でのルーティング設定はCentOS6系での例ですが、CentOS7系の場合は次のFAQを参照ください。
追加NICの設定例（CentOS7系の場合） | IDCFクラウド
補足ですが、このFAQの内容だと設定反映のためにインターフェースのリスタートすなわち通信断が生じます。
簡単に止められない場合は、上記設定に加え、一時的にルーティングを追加することも可能です。
# ip route add 192.168.0.0/21 via 192.168.7.254 dev eno33557248
2. プライベートコネクトで東日本リージョンと西日本リージョンを接続
次のご利用ガイドで紹介している手順のように接続できます。
www.idcf.jp
災害時の復旧の流れ
以上の対応で、データは退避できました。では、次に実際に災害等で、DRサイトを立ち上げが必要になったときの流れを紹介します。
1. サーバー環境を構築
一から構築するか、もし用意していたらテンプレートからサーバーを立ち上げます。
ファイアウォールやロードバランサーなどネットワーク設定もします。
2. 構築した環境に退避していたデータを戻す
退避していたデータを、WEBサーバーやDBサーバーへ戻します。
3. サイトの動作確認ができたら、DNSレコードを変更
通常のサイトであれば、DNSレコードを新しいIPアドレスへ変更して完了になると思います。
もし、IPアドレスが変わることで、影響する箇所がないかは事前に確認しておくと良いです。
このように難しくない流れだと思います。大事なのは、いざというときにデータから環境を戻せることです。そのためには、事前にテストをしておくと良いでしょう。
まとめ
このように、データさえ何とかなれば、意外と簡単にDRサイトは用意できます。
これからDR含めたサイトを作成する場合は、冒頭のドキュメントを参照いただき、手っ取り早くDRサイトを作りたい方は今回のエントリーを参照ください。
クラウドの機能を活用いただいて、簡単にそしてより速い復旧を実現いただければ幸いです。
