MSP仕掛け人コラム

第17回
IaaSの障害発生で思うこと

2014/10/01 (Wed)

こんにちは。MSP仕掛け人コラムニスト6号です。

前回は、クラウド運用サービスの分類について書きましたが、今回は、クラウド障害(IaaS)について勝手に思っていることを書いてみたいと思います。

 

障害は、どんなインフラでも頻度や深刻度は別にして変わりなく発生するものですが、いざIaaSに発生するとちょっと厄介です。

 

クラウド事業者としては、コロケーションやハウジングのように個社への影響に限定されず、その上でサービス提供している多くの利用者に、大きな損失と信用低下を招き、利用者のサービスへの影響を把握することは極めて難しいです。

 

 

一方、利用者にとっては、クラウド事業者から先に障害連絡があればまだ良いですが、エンドユーザーから利用者、そこからクラウド事業者へディエスカレーションとなると、障害箇所や影響範囲、原因と対策、報告など、その後の対応に多くの時間が必要です。このケースでは、エンドユーザーからの問い合わせに対して、利用者はどこが問題なのか切り分けし、SIer経由か直接クラウド事業者に問い合せます。

 

クラウド事業者も利用者の契約情報は管理していますが、その利用者がIaaSでどんなサービスを提供しているか、サービス停止でのインパクトは?

などの情報は持っているでしょうか?

 

 

答えは、「No」です。

 

 

当然、事業者としてサービス基盤(インフラ)の監視は24×365で行い、障害を検出すると直ちに確認や復旧および連絡に取り掛かる体制を構築しているのでIssSに何らかの障害が発生していることは伝えてくれます。

 

しかし、エンドユーザーからの問い合わせや事象が、IaaS側に障害が影響しているのか。は、利用者が判断しなくてはなりません。

このような横割りのレイヤー別対応になっているため、ユーザー視点でレイヤを縦串に監視することがないのでまどろっこしい感じです。

 

 

 

  「利用者は、IaaSでどんなサービスを誰に提供しているか?」

 

  「そのサービスのアクセス数はどの程度なのか?」

 

  「停止した場合の損失はどれくらいか?」

 

  「サービスの稼働を監視することはできないか?」

 

など、情報を管理活用しているクラウド事業者は皆無です。

(ここでいう監視とは利用者に障害連絡をするものでは無く、クラウド事業者としてのものです。)

理由は簡単で、一般的にサービス仕様ではOS以上は利用者の責任範囲であるからでもあります。(図1.責任範囲 参照)

 

(図1.責任範囲)

column17_1

 

たとえば、これら前述の情報(最新化は必須)があるのと、無いのでは、IaaS障害時の事業者として影響範囲を把握して影響する多くの利用者に対する情報提供など、アカウント営業としての対応の質は雲泥の差があるのではないでしょうか?

 

ぜひ、アカウントプランの項目に含めて顧客接点強化のため、情報収集とその適用をしてほしいものです。日本では、障害報告もアカウント営業の重要なミッションであり、災いを転じてより良い関係となるチャンスでもあります。

 

そこまで、求めるならオプションの運用監視サービスを個別契約すべきではありますが、コロケーションやハウジングとは異なりクラウド設備や仮想サーバーなどの共通の基盤で提供されるので、クラウド事業者でないと問題箇所の特定や影響範囲の切り分けが困難です。セルフ型のパブリッククラウドでは、このような管理・監視は困難なので一方的なIaaSの状況を通知するしか出来ません。

 

ですが、利用者の顔の見えるプライベートクラウドであれば、クラウド事業者としての管理・監視は可能と思います。外資のクラウドベンダーにこのようなきめ細やかなことはしないし、なにより利用者にとって安心出来るのではないでしょうか?

 

理想では、予算があれば専門のMSPなどに依頼してインフラの監視(低レイヤ)とユーザー視点の監視(高レイヤ)をハイブリッドで行い統合的に判断することですが、IaaSゆえに事業者と利用者でレイヤーに管理責任の境界があり、実際にはMSPでも簡単ではないですが・・・

 

 

(図2.理想の監視)

 

column17_2

 

 

いずれにしても、クラウド事業者としてIaaS上で利用者が提供しているサービスについての状況を知ることが重要で

 

「Japan Cloud Quality」に繋がるのではないでしょうか?

 

 

 

記:MSP仕掛け人コラムニスト6号(43番)

pageトップへ