DRについての前提知識解説

　まずはDRの概念、用語などを含めて簡単におさらいをするとよいだろう。ITmediaエンタープライズの記事にも参考になるものがある。特に、インターネットイニシアティブ（IIJ）の小川晋平氏による特集「ディザスタリカバリで強い企業を作る」は必読である。DRの考え方から設計・運用まで、明快な解説がなされている他、IT以外の側面における記述も徹底しており、DRが単に「ITで解決すべき問題」でなく、幅広い経営問題であることがよく分かる。DRをゼロから考えねばならないユーザー企業にとって、心強い羅針盤となることは間違いない。

　本稿ではパブリッククラウドの有用性を検討することから、DRの「ITの側面」のみを考える。その中でもデータセンターやサーバホスティングの観点にフォーカスし検討を進めることとしたい。また、本連載（参考：「企業向けシステムを構築するパブリッククラウド」）で過去に扱ったパブリッククラウドのうち、Amazon Web Services（以下、AWS）、IIJ GIO（以下、GIO）を取り上げる。さらに、Salesforce.comの可能性にも言及する。いずれも日本国内にデータセンターを有する（Salesforce.comは近日予定）観点から選定した。

　次に幾つか基本的な単語について解説をしておく。

・BCP（Business Continuity Plan：事業継続計画）

　予期せぬ事態が発生した際の行動計画をBCPという。災害発生時に備え、事前に策定しておく。

・RPO（Recovery Point Objective：目標復旧時点）

　障害発生時には、直前に発生したデータを再現できない可能性があることから、ある程度の時間をさかのぼった時点までシステムの状態を戻す必要がある。現在から過去にかけてどこまで戻すかという指標をRPOと呼ぶ。一般にRPOは短ければ短いほど良い。

・RTO（Recovery Time Objective：目標復旧時間）

　障害が発生してシステムが利用できなくなった時点から、再度利用可能になるまでの時間をいう。本番系が落ちてから待機系に切り替わるまでのタイムラグと考えると分かりやすい。RTOも短ければ短いほど良い。

・本番系／待機系

　プライマリサイト／セカンダリサイトなどとも呼ばれる。通常時（平時）にサービス提供しているシステムが前者、災害発生などで前者が利用できなくなった際に代替手段として利用するシステムが後者である。

・ホット／ウォーム／コールド

　平時における待機系の保持方法についての概念。「温度」が高いほど即座に本番系の業務を肩代わりすることができ、RPOやRTOが短くなるが、その分コストがかさむ。

　ホットの例として、金融系のシステムでは、RPO／RTOを「ほぼゼロ」に近づける努力が成されている。これは事実上、本番系と待機系で同格のシステムを2個保有し、常に両方ともフル稼働させているに等しい。システムコストは単純に考えれば2倍になり、動作検証や障害発生を想定した演習などを考えると、費用的には2.5～3倍になるというのが経験者の実感である。

　コールドの例としては、遠隔地のデータセンターにアプリケーションを入れたサーバを保有しておき、普段は電源を入れないが、定期的に本番系のバックアップをテープなどで送付しておく方法がある。災害発生時にはサーバの起動とデータの読み込み、ネットワーク設定・切り替え作業などを（多くは手作業で）行う。RPO／RTOは、1日から数日といったところだ。

　ウォームは、ホットとコールドの中間と考えればよいだろう。費用対効果を考えると多くの企業がここに解を求めることになる。とはいえ解は単純ではない。各ユーザー企業のシステムは一品一様で、複数のシステムが密接にからまっている。システムごとに重要度もさまざまだ。ビジネスによって許容できるRPO／RTOから、待機系システムに必要な「温度」が決まる。

　次に、DRにおいてクラウドがどのような優位性を持つか考えてみよう。

パブリッククラウドの優位性

　待機系は、通常は稼働していないシステムである。ここに巨額のハードウェアを投資することにためらうのは誰しもやむを得ない。安価に済ませるなら、パブリッククラウドが非常に良い選択肢となる。例えば、次のような利用方法が考えられる。

GIO

　低スペックのインスタンスで待機系を構築し、平時にはアプリケーションのアップデートと、データのレプリケーションのみを定期的に行っておく方法がある。いわゆる「ウォーム」の待機系といえる。非常時にはアプリケーションやデータを保持したまま、インスタンスのスペックを拡大させることが可能だ（最大16倍）。パフォーマンスを必要とする基幹系システムであっても、非常用の縮退運転と割り切れば十分だろう。現時点ではスペック拡大に依頼から1日程度かかるようだが、いずれより短時間での実現が可能になり、さらにはユーザーのオペレーションによる半自動化も可能になると期待されている。

AWS

　低スペックのインスタンスでウォームな待機系を構築できる点はGIOと同様だが、アプリケーションを保持したままインスタンスのスペックを上げることは難しい。EBS（Elastic Block Storage）などの機能を駆使しながら、インスタンスを切り替えることになる。また、このような作業をAWSに「依頼」することはできず、全て自己責任による作業となる。複雑な作業になるが、信頼できるITパートナーに業務委託をするか、公開されているAPIを使って自動制御プログラムをきちんと作り込むことができれば理想的といえる。

　インスタンスをデータベースサーバやアプリケーションサーバなどに分け、アプリケーションのアップデートはほとんど行わないと割り切った場合、平時にはアプリケーションサーバを利用しないのでその分のインスタンス利用料を節約できる可能性もある。停止中のマシンのイメージ（AMIという）を保持するためのファイル保管料は課金されるが、インスタンスの利用料に比べれば微々たるものである。

　データ量にもよるが、コールドに近い待機系の構築もAWSなら可能である。アプリケーションを保持したインスタンス類は全て停止状態としておき、データのみS3（Simple Storage Service）に送信して保管しておく方法である。非常時にはインスタンスの再起動とS3からのデータ読み込みという手順を踏むことになる。S3の利用料も著しく低いので、かなり低コストな待機系になると期待できる。

　ここまでは単純にアプリケーションとデータのみに着目しているが、当然、システムはそれほど単純ではない。次にDRにおけるクラウド利用を阻害する要因と、その対策について考えてみよう。

パブリッククラウドの利用を阻害する要因

特殊な機器

　特定の取引先との通信に、ISDNやアナログ電話回線を使っているケースでは、TA（ターミナルアダプター）やモデムなどの機器を基幹系システムの一部として保持していることがある。発信番号による認証を行っている場合には、これらの機器や回線を収納するデータセンター自体が利用不能になる事態を想定したDRができなくなる。このような接続方式については、物理的なロケーションを問わないWebサービスなどへの移行を早期に検討したい。

　それが不可能な場合は、多少コストはかさむが無駄を承知で複数の発信番号からの認証を可能にするなどして、DRサイト側にもこれらの機器を持ち込むことになるだろう。AWSでは対応できないが、GIOなら可能である。

閉域網

　特定の取引先との通信や、自社拠点間の通信に閉域網を使っているケースも多いだろう。非常時には自社と待機系データセンター（クラウド）との間は、インターネット回線とする方がメリットもあるが（例えば出勤不能に陥った社員が自宅からシステムを利用可能になる）、取引先との通信も同じように切り替えられるかどうかは十分確認する必要がある。切り替えが困難であるなら、DRサイト側にも（平時には利用しない）閉域網接続を用意しておく必要がある。これもAWSでは対応できないが、GIOなら可能である。

ソフトウェアの制約

　ソフトウェア（アプリケーションやツール類）が、特定のOSやハードウェアに依存した作りになっていると、そもそもクラウド上のインスタンスで動作させることが難しい場合がある。サーバ統合を行い、ソフトウェアの仮想化環境への移行を進めておくと、待機系の選定と構築が平易になるなどのメリットがあるので、事前に推進しておきたい。また、待機系にスタンバイさせるソフトウェアのライセンスの問題は提供ベンダーとの間で個別に確認する必要がある。ものによっては仮想化環境での動作を保証していなかったり、クラウド（ユーザーの資産でないインスタンス）上へのインストールを禁じていたりするので注意したい。動作保証をしていないというレベルであれば、緊急時の一時的利用ということでベンダーサポートに依存しないと割り切るのも一案であろう。

DRにおけるパブリッククラウドの将来性

　最後に、ロケーションの問題に言及しつつ、新しい提案を試みてみたい。

　DR用のデータセンターは、通常、本番系のデータセンターから一定以上の距離を置いたロケーションを選定する。GIOは、ある程度の場所情報は公開しているので、目安とすることができる。

　AWSは国内については「東京の複数箇所」という以外、情報を公開していないので、本番系データセンターが東京にある場合は悩ましいことになる。思い切って、シンガポールリージョンにDRサイトを構築するか、あるいは逆転の発想で、本番系を東京以外のところに移設することになる（笑）。さすがにこれは冗談としても、現実は、ある意味で徐々に「主客転倒」しつつあるので解説したい。

　現実問題として、パブリッククラウドのデータセンターは、堅牢性と可用性において「もうこれ以上は考えられない」というほど圧倒的に優れている。自社でデータセンター（サーバルーム）を保有しているユーザー企業も多いと思うが、「パブリッククラウドの方が安全ですよ」と断言しておきたい。外部のデータセンター業者を利用しても、そのセンターの性能は「良くてパブリッククラウドと同等。普通はそれ以下のはず」と指摘したい。パブリッククラウド自身が複数のデータセンターを冗長構成していることを考えれば自明であろう。

　その上で、次のような問題を考えていただきたい。「トップクラスのデータセンター」と「それほどでもないデータセンター」があり、「本番系システム」と「待機系システム」をそれぞれ入れ込まねばならないとしたら、どちらのシステムをどちらのセンターにアロケートした方が良いのだろうか、と。ここで「本番系＝トップクラスのデータセンター」「待機系＝それほどでもないデータセンター」と考えるのは、むしろ自然な流れだと言えるのではないか。現時点では、企業活動の生命線である基幹系システムをパブリッククラウドに預けるという発想には相当の心理的バリアがあることは承知している。しかし技術面から見ると、「これまでの常識」と「これからの常識」は180度異なるものになっていくだろう。

　さらに論を進めると、近い将来の「正解」は、「本番系も待機系もパブリッククラウド」に至ると筆者は確信している。既に述べたようにパブリッククラウドは、複数のデータセンターから成り立っており、それ自身が極めて強力なDR機能を有している。ユーザーは、ただ単に、これらを上手に組み合わせるだけで、つまり追加コストをほとんど発生させることなく、パブリッククラウド自身のDR機能に相乗りできるのである。1つの業者で不安であれば、複数のパブリッククラウドを組み合わせることすら可能だ。

　そしてその先の未来には、業務用アプリケーションを最初からDR構成で設計・構築するという方法論もある。AWSでは、1つの地域をアベイラビリティゾーンという概念で細分化し、ロードバランシングやデータベースのレプリケーションを複数のアベイラビリティゾーンにまたがって実行させることが可能だ。個々のアベイラビリティゾーンは、「物理的に距離を置いて設置されているデータセンター」とみなされているので、この構成であればシステム全体がDR機能を内包している格好になる。業務用のアプリケーションをこの形式にインプリメントするにはまだまだ時間がかかると思うが、既にSNSやゲームなどのアプリケーションの一部がこの構成で稼働していると推察されており、技術的要素は出そろっていると言ってよいだろう。

　最後に、SaaS（software as a Service）系パブリッククラウドの雄、Salesforce.comに言及しておきたい。同社のWebサイトの情報を解釈すれば、アプリケーションもデータも、複数のデータセンターにリアルタイムで複製されていると推察できる。換言すれば、Salesforce.com自体も「業務用アプリケーションを、最初からDR構成で構築」されているサービスであると考えて差し支えないだろう。同社の基盤（Force.com）上で完全な基幹系システムを構築するには、また解決すべき課題が多々あると思われるが、DRの観点からは興味深い存在だといえる。

最後に

　以上、パブリッククラウドを使った基幹系DRという観点で、いろいろな可能性を論じてみた。申し上げるまでもないが、当該分野は技術的進歩の激しい分野であり、記載されている事項は原稿執筆時点での筆者の認識に基づいているものであることをご了解いただきたい。本稿がユーザー企業各位において、クラウド時代のDRを検討する上で一助となれば幸いである。