このたび当社では、ネットワークシステム監視に関する連載コラム「kanshi de mirai」を開始することになりました。当社の社員がネットワークシステム監視のプロとして、
これからのネットワークシステム監視について、さまざまなテーマで語ります。どうぞよろしくお願いいたします。
さて、第1回目の今回は「SaaSやクラウドにおけるSLA責任範囲」についてお話しします。
新システム導入前においては、その業務を安定して稼働させる為に必要なリソース性能を企業の情報システム部門が必ず吟味、検討していました。しかしながら、部門やグループ単位で簡単に使用を開始できるSaaSやクラウドサービスは、情報システム部門を経由しない検討や導入が進んでいます。
このため、性能遅延が発生した場合には、従来では情報システム部門に問い合わせや改善を求めていたユーザーが、一斉にSaaS事業者に直接クレームを出し始めています。これに困惑しているSaaS事業者も少なくありません。
この問題の主なポイントは、3点あります。
①ユーザーは必ずしもITに詳しくない
②サービス提供事業者がユーザー環境を把握できない
③アプリケーション中心に問題が議論されている
多くのケースでは、ユーザー側とサービス提供側の責任範囲が明確でなかったり、両者が客観的に判定できる性能情報を持ち合わせていないのが原因と言えます。特に、応答遅延の場合には感覚的な要素も含まれる為、状況把握だけでも困難となります。それゆえ、一旦問題が発生した場合には、原因把握や調査に多くの労力や時間が必要となってしまいます。残念ながら想定のサービスレベルが達成できずに、せっかく活用しようと思ったサービスをあきらめてしまうユーザーもいるでしょう。このような場合、ユーザーはコスト削減の機会を逸し、サービス事業者はビジネス機会の損失となってしまいます。
SaaSやクラウドサービスの性能は、大きく3つの要素で構成されています。ネットワーク環境、データセンター環境、ユーザーのLAN環境です。それぞれのSLA責任としては、データセンター内性能はサービス提供者、ネットワーク性能はキャリアやプロバイダーの範囲、そして、ユーザーは自らのLAN環境性能に関しては責任があると言えるでしょう。SaaSやクラウドサービスはそれぞれの立場で努力しあってこそ、安定したサービス
提供がなされます。言い換えると自らの責任範疇内のみの努力だけでは大きな性能改善が出来ない背景があります。
これらの背景や問題に対して、SaaSやクラウドを運用する事業者にとっては、今まで以上に複雑化したITインフラの個々の構成要素すべてについて、コンポーネント単位で詳細に動作状況を把握する必要性も出てきています。
その上で安定したサービスを得る為の情報をユーザーに対して発信することや、ユーザーのLAN環境に対する改善提案ができればベストではないでしょうか。
将来、それぞれの立場で性能情報を提供し合い、性能改善や安定について協力すること
が、当たり前になる時代が来るかもしれません。そして、その第一歩が、SaaSやデータ
センター事業者による性能情報の公開から始まると思います。
次回のテーマは、「守りの監視から攻めの監視へ」です。
by マーケティング 岩井靖