気づかぬ間に進んでいるクラウドプロバイダーへの依存

　7月の障害時、あるユーザーは「Teamsがなければ仕事ができない」と判断したという。社内連絡はもちろん、顧客など社外との打ち合わせもTeamsで実施することになっていたからだ。

　急ぎの用件だけを済ませるのであれば、電話やメールでこなせる場面もあるかもしれない。また、ZOOMやGoogle Meetなど別のツールを緊急避難的に利用することも考えられる。だが、プロジェクト全体の進捗管理や文書の保存もこうしたコラボレーションツールをベースにしていることも多く、「通常運転」というわけにはいかない。

　マイクロソフトの公式Twitterによると、7月の障害の原因は内部ストレージへの接続が切断されたためだったという。また8月の障害は、直近のアップデートが原因であることを特定し、ロールバックによって問題の解消を進めていると説明した。

　クラウドサービスプロバイダーが原因究明と復旧に努めるのは当然であるが、ここでユーザーが認識しておくべきことは、いつどの程度復旧するかはクラウドサービスプロバイダーに依存することである。自社にはどうにもならないのである。

システム障害の影響の大きさ

　ICT障害の影響として最近の記憶に新しいのは、7月2日に発生したKDDIの携帯電話サービスの通信障害である。KDDIが総務省に提出した報告書によると、3091万人に影響が出た。医療機器の稼働に影響を与えるなど、通信は人命にかかわる重大なインフラであることを再認識することになった。

　Teamsのような業務アプリケーションも、今や人命にかかわらないとは言い切れない。また、ビジネスの停止時に「休憩できてよかった」と思えるユーザーばかりではないだろう。オンラインミーティングでの大事な商談が延期になったことで、結果として受注を逃すことも考えられる。

　このように、クラウド大手だとしても、システム障害を起こしてしまうのが現実である。しかも、クラウドを使う側であるユーザーは、復旧にまったく関われない。となれば、ユーザーからすると、ビジネスの再開時期は半ば「神のみぞ知る」という感覚すら出てきてしまう。


　クラウドサービスを利用するのか、コストがかかっても自社で稼働や障害復旧をコントロールできるオンプレミスシステムを選択するのかについては、今一度整理し、考えておくべきだろう。

「ミッションクリティカル」を数字で示す

　それを考える上で1つのアプローチになるのが、稼働率に関するSLA（Service Level Agreement）の確認である。稼働率とは、1年間にどれくらいの割合でシステムが稼働するか、そこから1年間にどれくらいの時間停止してしまうのかを、割合表示で理解するものである。

　最も信頼性が高いと言われるメインフレームやUNIXサーバーで構築した基幹系システムの場合、稼働率は「99.999％」、ファイブナインに上ると言われる。ファイブナインの場合、1年間の停止時間は5分15秒（365日×（1-0.99999））となる。

　ちなみに、9がもう一つ多いシックスナイン「99.9999％」の場合は、年間の停止時間は32秒という。参考までに、もう1つ9を加えたセブンナイン「99.99999％」であれば、年間ほぼ3秒となる。絶対に止められないシステムである金融の勘定系システムなどには、一般にファイブナイン以上の数字が求められる。現状のクラウドサービスでは実現が難しく、「メインフレームがなくなることはない」と言われる理由がここにあると言える。

　では、それ以下についても見てみよう。9が4つ「99.99％」であると、年間の停止時間は52分強となる。1年運用していると1時間ほどサービスが停止するイメージだ。この99.99％が、現在のクラウドサービスプロバイダーが掲げる目標となっている。

　Amazon Web Servicesは、99.99％という可用性目標について、「Eコマースサイト、B to B ウェブサービス、高トラフィックのコンテンツ／メディアサイトなど、企業にとって重要な収益源となるミッションクリティカルなアプリケーションの稼働を支えるもの」と説明する。

　マイクロソフトはAzureの稼働率について、複数リージョンにまたがって「Premium」レベルで実行することを前提に、99.99％以上のSLAを掲げている。単一リージョンの場合は99.95％以上を保証している。

　つまり、現在のクラウドサービスでは、最も信頼性が高いとするケースでも、年間1時間ほどのダウンタイムを見込んでいるのである。そして、障害の発生が続くことからも分かる通り、99.99％などの目標はあくまでも目標であり、実態は異なる可能性もあるのだ。

【次ページ】「稼働率99％」が示す驚くべき数字