マンガ: 栗生ゑゐこ /ad-manga.com
情報システム基盤の仮想化が進み、プライベートクラウドへの移行を検討する企業も多くなりました。仮想マシンの拡張や構成変更、レプリケーションなどがより手軽になったことで、ユーザーはWebシステムのさらなるレスポンス向上や、より厳しいサービスレベル(ダウンタイムの極小化)を求め始めています。
しかし、仮想環境下で物理サーバや仮想マシン、アプリケーション、ネットワークなどは構成が動的に変化し、複雑に絡み合うようになってきたため、システム全体の変調をいち早く把握できず、突然のレスポンス遅延によりサービスレベルの低下を招く事例が後を絶ちません。
1つの重大事故の裏には29の軽微な事故と、事故に至らないもののヒヤリやハッとした300の異常が存在するというハインリッヒの法則では、事故の予兆といえるヒヤリ・ハットを事前に把握することで事故の回避を提唱しています。
「JP1 」の最新版となるV9.5の新機能で最も注目されているのが、サービスレベル管理基盤の「JP1/IT Service Level Management」(以下、JP1/ITSLM)です。JP1/ITSLMでは、これまで困難とされてきたWebシステムにおける「サービス全体の状況の把握」と「サービスレベル低下の予兆検知」の2つの機能を同時に提供しています。
図 JP1/ITSLMでは、金融機関向けに日立製作所が培ってきた「ストリームデータ処理技術」を応用し、大量のデータをリアルタイムに分析して正常時と違う予兆をいち早く検知。問題が顕在化する前に対処することが可能です。
第1のサービス全体の状況の把握では、監視対象となるサービスグループごとのサマリ状況や要注意サービスのランキング、発生したイベントを確認できるほか、エラー・警告・正常ごとに色分けして表示することで、問題の発生をすぐに認識できるようになりました。
サービス利用者が体感している性能をSLO(Service Level Objective;サービスの評価指標)をしきい値として監視しリアルタイムに監視画面に表示します。
第2のサービスレベル低下の予兆検知では、まず過去の応答時間を記録して平均値を基にした推移線(ベースライン)を生成し、それを中心に平常時での上下の振れ幅(偏差)を正常範囲とします。もし、何らかの原因でその正常範囲のワクを超えて応答時間が長く(遅く)なると、JP1/ITSLMはそれを“サイレント障害”と認識し、近い将来SLOしきい値を超えて障害に発展してしまう前に、その予兆をリアルタイムに検知します。
図 過去蓄積したデータの傾向から正常時と違う予兆をリアルタイムに検知し、問題が発生する前に対処ができます。
JP1/ITSLMでWebシステム全体の応答時間の実態や障害予測を把握することができれば、管理者は次の新たなアクションに結び付けることが可能です。例えば、OSやアプリケーションで性能低下が起きていれば、統合管理(統合コンソール)の「JP1/Integrated Management」(以下、JP1/IM)と、アベイラビリティ管理(サーバ稼働管理)の「JP1/Performance Management」(以下、JP1/PFM)で詳細な分析を行い、原因を特定して対策を施すことができます。
また、分析に「uCosminexus Navigation Platform」の応用も有効です。予兆が発生した時点であらかじめ登録した分析シナリオに従ってJP1/IMやJP1/PFMを使用して原因究明を行い、誰でも管理者レベルの対応が可能になります。
さらに、仮想マシンのリソースの割り当てや性能不足の対策を行う場合は、ITリソース管理「JP1/IT Resource Management」で仮想環境の構成変更を容易に行えるよう支援します。
こうした機能を統合的に連携させることで、快適なサービスを継続して提供できることにつながります。SLA(サービスレベル契約)は外部の顧客のためだけに存在するものではありません。社内のユーザーに対しても質の高いサービスを維持してほしいものです。
そのためなら、どんなに仮想化・クラウド化が進んでも、スーザン(S)、リンダ(L)、アニー(A)はあなたの会社のサービスレベルをゴージャスにするヒントを与えてくれることでしょう。