このたびの震災は、BC/DR（ビジネス・コンティニュイティとディザスタ・リカバリ ［災害対策・災害復旧］）の大切さを改めて教えてくれたように思います。今回は、このBC/DR対策におけるクラウド利用の可能性について考えてみることにしました。
本来、BC/DRの目的は、災害時における業務の停止時間を極小化することにあります。そのために、データセンター設備そのものの災害対策に加え、設置されているハードーウェアや電源設備の冗長化により、システム停止を回避する対策がとられています。
加えて、データセンターそのものの機能不全を前提に、別の地域に代替のセンターを構え、同等の機能を提供できる設備を用意する措置がとられます。そして、運用管理システムが、両者の切り替えを支援することになます。ただ、オープン・システムの場合は、それを完全に自動化することは、かなり困難なようです。
これに対して、メインフレームでは、装置そのものだけではなく、部品レベルでの冗長化に加えて、ハード、ＯＳ、ミドルウェアの連携により、ハードウェアの計画外停止にとどまらず、アプリケーション・レベルの計画停止まで含めた「業務レベルの可用性」を実現する機能を実装しています。
また、拠点内だけではなく、地域をまたがリ、ひとつのシステム・イメージを構築するクラスタリングの機能も、ＯＳの基本的な機能として提供されており、ノンストップ運用環境が実現しています。
ＩＢＭのメインフレームでは、並列シススプレックといわれる機能がこれに相当します。その機能の中で、地域をまたがった運用の切り替えを行なうのが、「広域分散並列シスプレックス（Geographically Dispersed Parallel Sysplex, GDPS）」といわれるもので、システムの拠点間切り替えを自動的に行ないます。
1.代替リソースとしてのクラウド
さて、このようなBC/DR対策は、普段の業務で必要となるシステム・リソースの代替リソースを提供することです。まずは、その観点から、クラウドの可能性を考えてみましょう。
既存の業務システムとの互換性を考えれば、自社のシステム構成に合わせることが容易なIaaSは使いやすいサービス形態です。Amazonのサービスのように従量課金であれば、システムの構成イメージをIaaS上に持っているだけであれば、費用は発生しません。ですから、BC/DR対策としてのコストは大幅に削減できる可能性があります。
また、Amazonは、VMwareイメージ（KMDK）をAmazon EC2クラウドへ持ち込めるVM Importを昨年の12月に発表しています。社内システムをVmwareで仮想化しておけば、障害時にシステムの移行をスムーズにできる可能性があります。現段階では、コマンドラインで操作する必要があるようで、ライブマイグレーションによるリアルタイムな切り替えには対応していないようです。今後のサービス内容の充実に期待したいところですが、BC/DRの手段としては、有効な選択肢になるかと思われます。
もうひとつ注目したいのが、Window Azure Platformです。Window Azure Platformは、企業内システムとして、ひろく普及しているWindows Serverとの高い互換性を売りにしたPaaSに位置づけられるサービスです。.Net FramworkとVisual Studioをそのまま使えることから、オンプレミスとクラウドをひとつのシームレスなプラットフォームとして、開発・運用・実行環境を提供するというものです。つまり、オンプレミスとクラウドをひとつの連続したシステム・リソースと考え、その運用を当初より設計するという考え方が生まれてきます。
このような考え方は、オープン系のシステムでは、以前では、考えられなかったことです。ひとつの可能性として、検討に値するかもしれません。
2.非基幹業務のクラウド
クラウドによるもうひとつのBC/DR対策の可能性として、コミュニケーション／コラボレーションの手段を当初よりクラウドのサービス（SaaS）として利用するという考え方です。
電子メールやグループウェアは、企業個別の独自性は、それほどありません。従って、これをSaaSとして、日常の業務で使うことに、大きな支障はないもものと考えられます。実際に、クラウドに二の足を踏む金融系大手企業でも、このあたりであれば、問題ないとして、導入に踏み切る企業も増えてきました。
個人的な体験ですが、今回の地震発生当日、電話がほとんど通じなくなりましたが、電子メールに加え、TwitterやFacebook、Skypeは、なんの支障もなく使えました。仕事相手や米国にいる家族と問題なくskypeで会話できたことに、驚き、感謝しています。また、TwitterやFacebookも、掲示板として、伝言メモとして、効果をあげています。スマート・フォンの普及と共に、使い勝手も進化しています。
ビジネス・コミュニケーションにおけるBC/DR対策として、オンプレミスに依存する場合の対策負担を考えれば、簡単かつ低コストでの対応が可能と考えられます。
もともとインターネットは、軍事用のネットワークとして開発されたもので、特定の通信ノードが破壊されても、自律的に迂回経路を見つけて、通信経路を確保する仕掛けです。また、クラウドのデータセンターについては、高度の災害対策が施されています。このような仕組をコミュニケーションのライフラインとして、普段より業務の仕組として組み込んでおくという考え方は、有効な対策です。
確かに、セキュリティ上の懸念を指摘する声もあります。しかし、これについては、昨今、いろいろな手立てが考えられているようで、以前のような不安は解消されつつあるのではないでしょうか。
3.災害時の追加リソースとしてのクラウド
もうひとつは、今回の震災で、IIJやIBMが発表した震災地域の自治体や企業へのクラウド・サービスの無償提供です。これは、単なる社会貢献という意味を越えて、災害対策のひとつの方法論として、注目すべきかもしれません。つまり、既存リソースの代替手段ではなく、災害対策の時にのみ必要となるリソースの調達手段としてのクラウドの可能性です。
米国商務省の配下にある米国国立標準技術研究所（NIST: National Institute of Standards and Technology）の「クラウドの定義」は有名ですが、彼らが定めるクラウドの条件として、「オンデマンド・セルフサービス」、「広範なネットワーク/デバイスの利用」、「システム資源のプール」、「迅速な順応性」、「従量課金」があげられています。
この条件を充足しているクラウド・サービスは、我国には、必ずしも多くありません。しかし、もし、この条件にかなうサービスであれば、BC/DR対策の手段として、十分現実的な選択肢になるはずです。
■ BC/DR対策としてクラウドを検討する際の課題
ただ、課題も少なくないことを理解しておく必要があります。特に気になる課題のひとつと考えられるのが、コンプライアンスと法律・規制の問題です。データセンターが海外にある場合は、この点を考慮する必要があります。
もうひとつ、海外の場合、遅延時間（レイテンシー）が大きな課題となるでしょう。
データセンターが海外に設置されている場合、日本との間は海を隔てた遠距離になることから、パケットのやりとりに数百ミリ秒の遅延が発生します。TCP/IPのプロトコルの制約上、必ずシェークハンドという送受信の前に自分と相手の間で、送っていいかどうかの確認作業が行なわれます。データは、複数のデータフレームに分割して転送されるのですが、そのデータフレームを送ろうとするたびに、確認作業が必要となり、その間データフレームを送ることができない「すきま時間」が、挟まれてしまいます。
拠点間の距離が長い場合、この送れない「すきま時間」が長くなってしまい、大量のデータを送る場合は、転送効率が著しく低下（スープットの低下）します。これは、データを大量にやりとりしなければならない業務システムにとっては、致命的です。
この問題を解決する効果的な対策は、日本国内にあるセンターを利用するか、Windows Azureの場合は、マイクロソフトが日本国内に設置する「コンテンツ配信ネットワーク (CDN)」 にキャッシュを置くという方法が考えられます。
——
これ以外にも課題はあります。ただ、クラウドは、もはやBC/DR対策の手段のひとつとして、「十分検討に値する」、そんな時代になってきたのではないでしょうか。
■Facebookで議論しませんか？
このブログのFacebookページを開設しています。ぜひ、Facebookページ「ソリューション営業プロフェッショナル」にアクセスいただき、「いいな！」をクリックし、ご参加ください。
