• 会員限定
  • 2022/10/07 掲載

Teamsの障害で改めて見えたクラウドシフトの注意点、「99%はほぼ0点」という現実

  • icon-mail
  • icon-print
  • icon-hatena
  • icon-line
  • icon-close-snsbtns
記事をお気に入りリストに登録することができます。
7月21日に、世界で広く利用されているマイクロソフトのコラボレーションツールであるTeamsと、連携するOffice Onlineなど複数のサービスが利用できなくなった。また8月25日にもTeamsに障害が発生、日本を含むアジア太平洋地域においてサービスが利用できなくなった。いずれも平日のワークタイムを直撃した障害だったため、ビジネスに大きな影響を及ぼした。ユーザーからは「仕事にならないから休憩することにした」といった声もあったが、より切迫感を伴ったユーザーも存在した。相次ぐ障害は、Teamsに限らずクラウドサービスを利用すること自体への不安を改めて認識させることになった。

執筆:友永 慎哉

執筆:友永 慎哉

製造業向け基幹系システムの開発を経験後、企業ITの編集、ライター業に従事。ファイナンス、サプライチェーンなど、企業経営の知識を軸にした執筆に強みを持つ。インダストリー4.0など新たな技術による製造業の世界的な変革や、Systems of Records(SoR)からSystems of Engagement(SoE)への移行、情報システムのクラウドシフトなどに注目する。GAFAなど巨大IT企業が金融、流通小売り、サービスといった既存の枠組みを塗り替えるなど、テクノロジーが主導する産業の変化について情報を収集・発信している。

photo
クラウドサービスを利用するメリットとデメリットを正しく理解する必要がある
(Photo/Getty Images)

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

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

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

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

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

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

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

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

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

画像
あなたの企業はクラウドベンダーにすべてを委ねてよいのか?
(Photo/Getty Images)

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

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

 それを考える上で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%」が示す驚くべき数字

関連タグ

関連コンテンツ

    PR

    PR

    PR

処理に失敗しました

人気のタグ

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報
本メディアサイトに公開されます

必要な会員情報が不足しています。

必要な会員情報をすべてご登録いただくまでは、以下のサービスがご利用いただけません。

  • 記事閲覧数の制限なし

  • [お気に入り]ボタンでの記事取り置き

  • タグフォロー

  • おすすめコンテンツの表示

詳細情報を入力して
会員限定機能を使いこなしましょう!

詳細はこちら 詳細情報の入力へ進む
報告が完了しました

」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報
お相手に公開されます