これまでの常識では、クラウドテクノロジーは回復力に関して多くのメリットをもたらすとされていた。その理由はクラウドのスケールメリットとスケーラブルなアーキテクチャにある。クラウドサービスは複数の重複する場所に分散した形で作られ、スケーラブルで迅速なプロビジョニングが重視されている。そのため、どんな逆境でもアプリケーションは自動的に継続して実行されると多くの利用者は信じている。

　もちろん、クラウドを実際に使用している企業は、この点に関して「物事には細部にわながある」ということを理解している（ほぼ全ての企業がクラウドを使用しているのが実情だ）。例えば、2011年4月に米Amazon Web Services（Amazon）が提供する「Amazon Web Services」（AWS）が停止した事件を覚えているだろうか。この事件は今もなお「クラウドの黙示録」と呼ばれている。この事件についてご存じない方のために簡単に説明しよう。これはAWS環境でサービスが短時間停止した事件だが、比較的大きな規模で影響があった。多くのダウンストリームサブスクライバーのサービスは停止を余儀なくされた。この影響を受けた企業には、米Reddit、米Quora、米Foursquareなどがある。だが、クラウドサービスの停止という問題が発生したのはAmazonだけではない。2011年には、米Microsoft、米Google、米Intuit、米Pivotal Softwareの「Cloud Foundry」のクラウドサービスでもダウンタイムが発生している。

　企業はクラウドと接点のあるサービスのダウンタイムは避けられないと肝に銘じておくべきだろう。これは、仮にクラウドサービスプロバイダーが自社のインフラから考えられる全てのダウンタイムを排除できたとしても変わらない（ただし、このようなことは現実的に不可能だ）。クラウドサービスがサポートするオンプレミスの配信型コンポーネントやサービスがダウンしたときに、クラウドサービスにどのようなことが起こるか考えてみてほしい。

　例えば、オンプレミスでホストされている認証コンポーネントを利用するSaaSアプリケーションについて考えてみよう。こオンプレミスでコンポーネントをホストするのには、セキュリティまたは使用上のもっともな理由があるかもしれない。例えば、SaaSを利用するためだけに別のパスワードを覚えたくないなど、使い勝手を改善してほしいという要請がユーザーからあったかもしれない。また、会社が提供する資格情報のみに権限があり、これをログインに使用するを会社のセキュリティポリシーで規定されていることもあるだろう。だが、このような統合によって運用上の依存関係が生じ、プロセスの単一障害点となる。危機的な状況下でクラウドサービスが利用可能な状態を維持できても、依存関係のあるコンポーネントが利用できなければ、クラウドサービスが使用できなくなり、ユーザーはオフラインになる。この状態は依存関係のあるコンポーネントが利用できるようになるまで続く。

　クラウドサービスを使用しているという理由だけでダウンタイムを回避できるわけではない。つまり、管理者にとっては、ユーザーがクラウドサービスのダウンタイムの影響を受ける状況をどのように把握できるのかが問題になる。クラウドの回復力を監視して、利用可能性のリスクが許容範囲内にあるときも含め、緩和措置を取るべきタイミングを把握できるようにするにはどうしたら良いだろうか。

使用状況を評価する

　クラウドの回復力を監視する上で重要な最初の手順は、クラウドサービス本来の回復力を特定することだ。簡単そうに聞こえるかもしれないが、それほど簡単な作業ではない。というのも、クラウドサービスプロバイダーが公開している稼働時間、契約で取り決めている稼働時間に関するサービスレベル契約、プロバイダーが稼働時間について公式／非公式に発表していることを確認しなければならないからだ。もちろん、プロバイダーが発表している情報は重要だ（特に、契約でプロバイダーの同意を得ているものは重要だ）。だが、それだけで全体像をつかめるわけではない。それ以外に、クラウドサービスの使用状況と相互依存関係という各企業に固有の情報も必要になる。

　1つ目の使用状況に関する情報は、基本的に会社が使用しているクラウドサービスを調査すれば入手できる。具体的には、どこで使用しているのかと、どのように使用しているかだ。クラウドの使用状況は拡大する可能性がある。また、IT部門が直接管理していないものも少なくない（これは特にSaaSに当てはまる）。IT部門が管理していないクラウドサービスの使用状況は、ダウンタイムを引き起こす原因となり得るものとして把握しておく必要があるだろう。従業員は、ビジネスにとって重要なアプリケーションにこのサービスを利用している可能性があるからだ。また、一般消費者向けサービスの中には99.999％の稼働率を念頭において開発されていないものもある。ダウンタイムシナリオ全般を評価し、このようなシナリオがビジネス全体に与える影響を十分に評価するには、使用状況を理解しなければならない。

　使用状況の情報を収集する方法は幾つかある。1つは既存のプロセスを活用する方法だ。例えば、ビジネスインパクト分析（BIA）を使用すると、どのようなクラウドサービスを使用していて、そのサービスを使用することがどの程度重要かについてデータを収集することができる。企業によっては、災害復旧や事業継続計画の一環としてBIAを定期的に実行しているかもしれない。そのような場合は、そのデータを使用して、クラウドの使用状況を特定すれば、面倒な作業の大半を省略できるだろう。もう1つの方法は市場で新しく誕生している「クラウド検出ツール」を活用することだ。例えば、米Skyhigh Networksの「Skyhigh Discover」や米CipherCloudの「CipherCloud for Cloud Discovery」などがある。このようなツールを使用すると、IT部門の預かり知らぬところで従業員がクラウドを使用しているシナリオを特定できる。どちらの方法を使用しても、あなたの会社が現在使用しているクラウドサービスと、使用中のサービスがどのように関連しているのかについての情報を特定できるだろう。また、特定のサービスがオフラインになった場合に発生する可能性がある問題を評価することもできる。

クラウドの配置アーキテクチャを理解する

　クラウドの回復力を監視するための2つ目の手順は、クラウドの配置アーキテクチャを理解することだ。アーキテクチャを理解すると、単一障害点を特定できるようになる。注目すべきは認証システムやデータストレージシステムなど、従来の非クラウドのITインフラに配置されている情報のマスターリポジトリや処理を一元管理しているシステムである。

　これを把握する良い方法は、相互作用点を図示した既存の成果物を使うことだ。例えば、PCI準拠の環境を使用している場合は、データフローを示す図が必要だったことを思い出してほしい（これは1.1.3で規定されている）。少なくともクレジットカード保持者のデータを扱っている場合はデータフロー図があるはずだ。同様に、データフロー図の作成を伴う様式化された脅威モデルの策定を行っている場合は、コンポーネント間の相互作用点が、既にドキュメントに明記されている可能性がある（コンポーネントには、クラウドにあるものと従来のIT環境にあるものが含まれる）。どちらのリソースもない場合は、相互作用点を特定するために詳しい調査が必要になるかもしれない。この情報を特定する戦略の1つは、中央データリポジトリや主要コンポーネントへのトラフィックを調査することだ。このようなものは単一障害点の最有力候補となる。

　これらの手順を実施したからといってダウンタイムの心配が完全になくなるわけではない。また、会社で必要なレベルの回復力が確実に得られるわけでもない。だが、ダウンタイムを回避するためのたたき台にはなるだろう。少なくとも組織分析を行うために必要な材料は手に入れることができる。