ディザスタリカバリ (Disaster Recovery, DR) とは、自然災害などによって企業や組織の主要なデータセンターやサーバーがダウンした場合に備え、他の地域に存在するバックアップ機能を活用して業務を継続する手法です。これは事業継続計画 (BCP) の一部であり、特に東日本大震災以降、企業が急速に導入を検討しています。ディザスタリカバリを実現するには、維持するための適切なルールの設定や、そのルールを守る堅牢なシステムの構築が重要です。これはエンジニアの力だけでは実現できず、予算などの決定権を持つ役員などが理解することが不可欠です。一方、システムに疎い企業では、一見無駄に見える DR 環境への投資を躊躇する場合が多いため、個人的な意見としては、経営層に最低限の提言をしておくことは良いと思っています。
以前、私が所属していた会社の ASP サービスでも DR 環境を構築していましたが、以下の理由の通り、実際には期待に応えるものではありませんでした。
- 初期導入時に DR が考慮されていなかった。
- 単一の基盤上にシステムの相乗りが多かった。
- DR を統括可能なアーキテクト的な考えができるエンジニアがいなかった。
- システム全体として、ファシリティ（電源管理）、インフラ（ネットワークやサーバー）、アプリ開発の指揮系統が統一されていなかった。
- 十分な予算を得ることができなかった。
これらの要因の中で特に重要なのは、「1」であり、DR を導入しやすい環境であるかどうかが影響します。DR の設計における私見として、データベースやコンテンツなどのステートフルな情報をどのようにサイト間で同期させるか？が非常に重要だと考えています。これまで、いくつかの DR 設計に関与してきましたが、このステートフルな情報の同期をうまく設計できない場合、自動的な DR は難しく、データベースの準備ができた段階で、ネットワークを切り替えるなどの手動オペレーションが増加します。
「2」のようにシステムの相乗りが多い場合は、後からの DR 導入が難しくなる場合があります。つまり、単一のインフラ基盤であれば、そのインフラ基盤の単位で DR を考え、設計することで、各システムの DR 設計に一貫性を持たせることができます。
「3〜5」は組織的な問題であり、一般論として縦割り組織の影響が大きいと考えられる一方、ある程度の規模の組織はどうしても階層構造になるため、私見として縦割り組織の問題ではなく、重要なのは、それを前提とした上で、組織横断のユニットを作ることも組織として良いアプローチでしょう。
現代社会における企業業務は、システムが中心的な役割を果たしています。そのため、DR の実現には経営者の判断が重要であり、それには十分な利益が必要です。分かりやすい例を挙げると、DR とはシステムのエラー処理であるとも言えます。つまり、単純に必要な機能だけを実現するプログラムはシンプルですが、エラー処理などを考慮することで複雑性が増し、その分コストが増えますよね。DR のコストも規模は違いますが、そういうものだと思います。
