BCP対策としてのクラウドコンピューティング(後編)

  1. NTT西日本 公共・法人HOME
  2. 最適経営のヒント
  3. 著名人が語る
  4. BCP対策としてのクラウドコンピューティング(後編)
写真:甲元 宏明
ユーザー企業が押さえておくべき選定のポイント 2012年1月
甲元 宏明/アイ・ティ・アール シニア・アナリスト
BCP(事業継続計画)対策としてのクラウドの有効性を提唱する甲元氏。後編では、インシデント発生時のRTO(目標復旧時間、許容停止時間)を軸に、従来型の対策手法とクラウドベースの対策手法を比較し、短時間での災害復旧を低コストで実現する手法を、実例を交えて紹介。さらに、クラウドを導入する際の選定ポイントも提示する。

プロフィール

1958年生まれ。83年大阪大学大学院工学研究科修了、三菱金属(現・三菱マテリアル)入社。88年米国イリノイ大学に留学。SCM構築、CRM・ECなどのシステム開発や、グループ全体のIT戦略立案を主導し、欧州企業との合弁事業ではグローバルIT責任者を務めた。2007年からIT調査会社のITRに転じ、現在はクラウドコンピューティングやCRMなどを担当するとともに、ユーザー企業のITアーキテクチャー設計や、ITベンダーの事業戦略立案などのコンサルティングにも取り組んでいる。

クラウドなら短時間でのDRが可能

地震や洪水、火事などの災害が発生した場合、その災害がITシステムに影響を及ぼして業務が停止する場合がある。このようなケースにおいて、業務復旧までに必要な手順を図1に示した。

図1:復旧時間の考え方

業務復旧に要する時間は、ITシステムの復旧時間だけではなく、災害検知、状況確認、関係者への通知などの初動対応や、バックアップ実行時と災害発生時の間に入力されたデータ(損失データ)の再入力などの業務上の対応時間にも左右される。しかし、業務上の対応については企業や組織により異なるため、本稿ではITシステムについてのみ言及することとする。

ITシステムのRTO(Recovery Time Objective:目標復旧時間、許容停止時間)は、電力復旧、ネットワーク復旧、要員移動、バックアップ・テープ輸送などに要する時間に依存する。複数のデータセンターで稼働しているパブリック・クラウドは、この部分の復旧時間を大幅に短縮することが可能である。

実際、前編で紹介した、複数のデータセンターを利用した分散システムによって実現しているSaaS(Software as a Service)の場合、RTOはゼロ(つまり無停止)となることが多い。また、サーバー環境のパブリック・クラウドであるIaaS(Infrastructure as a Service)の場合、一つのサーバー環境(主に仮想サーバー)は一つのデータセンターで稼働しているため、SaaSのように無停止稼働というわけにはいかないが、仮想サーバー・イメージやデータを別のデータセンターに常時バックアップしておくことにより、短時間での災害からの復旧(DR:Disaster Recovery)が可能となる。

PAGETOP

従来型DR手法の3タイプ

パブリック・クラウドの利用そのものがBCPの強化につながるのだが、オンプレミス(自社所有)型システムのDR対策としても、パブリック・クラウドの活用は有用である。DR手法によるITシステムのRTO比較を図2に示した。従来のDR手法には、大きく分けて三つのタイプがある。

図2:従来手法とクラウド・ベースDRのRTO比較

(1)同期レプリケーション

最も理想的な手法は同期レプリケーション(複製)である。複数(通常は2カ所)のデータセンターに設置したシステムを同時稼働させ、リアルタイムでデータの同期を取り、片方のシステムが災害の影響で停止した場合でも、別のデータセンターのシステムで稼働を継続する。これによりRTOゼロを達成することが可能であるが、システム費用、データセンター間の通信費用など多大なコストが必要となる。そのため、同期レプリケーションを採用している企業は少なく、またそれだけの投資に見合うシステムも少ない。

(2)非同期レプリケーション

短時間のRTOを実現するDR手法としてよく採用されるのが、非同期レプリケーションである。本番システムは一つとし、バックアップ用のシステムを別のデータセンターに設置しておく。定期的にデータをバックアップし、災害などでシステムが停止した際には、バックアップ用システムにデータを復旧し、それを本番システムとして再稼働させる方式である。数分ごとといった短い間隔でバックアップを行うことにより、システム停止時間を短時間にすることが可能である。しかし、この手法も、システム費用など多くのコストが必要になる。

(3)バックアップ・テープからの復旧

低コストでのDR手法として最もよく用いられるのは、バックアップ・テープからの復旧である。1日1回、または半日に1回という間隔で磁気テープにデータをバックアップしておき、災害でシステムが停止した際には、そのテープからバックアップ・システムにデータを復旧する。データセンター間のテープ輸送やデータの書き戻しに時間を要するため、RTOは半日以上になることが多い。

PAGETOP

自社所有型のバックアップ先としてクラウドを活用

実際のところ、許容停止時間(つまりRTO)が数秒から数分でなければならないITシステムはさほど多くない。多くの場合、数時間以内で復旧できれば、業務への影響は最小限に留めることができる。しかし、従来の手法では、コストパフォーマンスに優れ、数時間以内のRTOを実現するDR手法は多くない。オンプレミス型システムのバックアップ先システムとしてパブリック・クラウドを活用すれば、数時間以内のRTOを低コストで実現する可能性が高い。

例として、米国の介護サービス会社であるHelp At Home社のケースを見てみよう。全米で85拠点のオフィスを展開し、1万3千人の外勤スタッフを雇用しているこの企業は、ほぼ全てのシステムがVMwareの仮想サーバー上で稼働している。

従来は、専用機器を導入し、自社システムが利用するデータベースとデータ・ファイルの変更部分のみをバックアップしていた。しかし、この手法では自社が定めたBCPから導かれるRTOを実現できないことが判明し、DRシステムの再構築を検討した。

オンプレミス型システムでDRを実現する場合、ハード、ソフト、通信費、運用保守にかかる費用が3年間で19万ドル(約1,500万円)となることが分かった。パブリック・クラウド(米国Iland社のIaaS)を利用すれば、3年間の費用が5万ドル(約400万円)で済み、14万ドル(約1,100万円)という大幅なコスト削減が達成できることが分かった。

Help At Home社が採用したDR手法は以下のとおりである。

Help At Home社が採用したDR手法

これにより、短時間での災害復旧を低コストで実現することができたとしている。

PAGETOP

「分散化されているか」の確認が重要

本稿で述べてきたように、パブリック・クラウドは、さまざまな観点でBCP対策として利用でき、短いRTOや低コストといった従来手法にはなかった価値を創出することが可能である。

図3に、DR対策として利用可能なパブリック・クラウドを列挙した。前編で述べたようにSaaSを利用するだけで高い継続性を実現可能である。PaaS(Platform as a Service)も同様である。しかし、全てのSaaS/PaaSが複数のデータセンターを活用した分散システムで実現されているとは限らない。単独のデータセンターだけで稼働しているものも少なくないため、ソリューション選定の際には、「そのシステムが分散化されているかどうか」を確認することが重要である。

図3:DR対策として利用可能なパブリック・クラウド

欧米では、バックアップ・システムをクラウドサービス化したBaaS(Backup as a Service)や、DRのクラウド・サービスであるDaaS(DR as a Service)も多く登場している。国内でこのようなサービスを提供している事業者はまだ少ないが、クラウド事業者の多くはユーザー企業の要求に応じてサービス内容のカスタマイズを行っている。

既にパブリック・クラウドによるDRシステムを構築した国内ユーザー企業も多く、そのほとんどは、クラウド事業者と相談し自社向けサービスとしてカスタマイズしたものである。パブリック・クラウドによるDRに興味のあるユーザー企業は、クラウド事業者に相談することをお勧めする。

PAGETOP

クラウド選定では、企業自ら“理論武装”すべし

図4には、DRという視点から見たパブリック・クラウド選定のポイントを示した。最も重要なポイントは、「パブリック・クラウドにコミットしている事業者を選ぶ」ということである。コミットの大小を評価するには、市場シェアやデータセンター投資などを指標として用いるとよい。

図4:DR視点によるパブリック・クラウド選定ポイント

昨今のクラウドブーム、そして東日本大震災後のBCPに対する投資機運の高まりを受け、多くのクラウド事業者が登場しているが、中には単一データセンターで運用し、実態は単なるサーバー貸しに過ぎないサービスも存在する。ユーザー企業がクラウド・サービスを選定する場合、事業者に対して、データセンター仕様、セキュリティーレベルとその実現方法などについて、RFI(Request for Information:情報提供依頼書)やRFP(Request for Proposal:提案依頼書)を用いて、情報を得る必要がある。

また、サービスレベルに関する確認も重要だ。そのためには、SLA(Service Level Agreement:サービス品質保証契約)を締結することが最良であるが、国内クラウド事業者の多くはSLAを提供していない。しかし、SLO(Service Level Objective:サービス品質目標)などの実質的なサービスレベル保証を行う事業者も少なくないため、事業者のサービスレベルが自社の要求条件を満たしているか確認することが重要である。

クラウドコンピューティングは、IT業界において最もホットなテーマの一つであり、変化が非常に激しい分野である。ともすればベンダーやSI企業の言いなりになりかねない。ユーザー企業自ら、業界動向や技術動向などを調査し、理論武装しておくことが望ましい。

PAGETOP
PAGETOP

本ホームページに掲載されている会社名、商品名は一般にメーカー各社の登録商標または商標です。
本ホームページの無断転載、引用はお断りいたします。
Copyright(c)NTT西日本 ビジネス営業本部 企画部

PAGETOP

審査 16-2826-1

Copyright(C) 1999-2017 西日本電信電話株式会社
バックナンバー RSS