JP6722345B2 - 予兆検知装置及び予兆検知方法 - Google Patents

Description

本発明は予兆検知装置及び予兆検知方法に関し、アプリケーションのサービスレベル低下の予兆を検知する予兆検知装置に適用して好適なものである。

アプリケーションやＩＴ（Information Technology）インフラストラクチャの性能劣化や障害などを予兆段階で検知し、これら性能劣化や障害を未然に防ぐ対策を取ることで、サービスレベルの低下を防ぎたいというニーズがある。これに関連する技術として、特許文献１及び２にそれぞれ開示された技術がある。

特許文献１には、性能種目又は被管理装置を要素とし、少なくとも第１の要素に関する性能情報の時系列変化を示す第１の性能系列情報と、第２の要素に関する性能情報の時系列変化を示す第２の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを各要素間の組み合わせについて求める相関モデル生成部と、各要素間の各相関モデルを順次探索して最適な相関モデルを決定し、この決定された相関モデルに基づいて第１の要素の性能情報から第２の要素の性能情報を予測する技術が開示されている。

また特許文献２には、管理計算機がストレージ装置へのアクセスに関する性能情報をホスト計算機より取得し、取得したアクセスに関する性能が、予め定められた第１の要求性能を満たすか否かを判断し、第１の要求性能が満たされていなければ、仮想論理ボリューム管理情報に基づいて状態の原因である仮想論理ボリュームを特定し、プール管理情報に基づき、各プールに含まれる実領域の容量消費傾向を算出し、特定した仮想論理ボリュームの情報と、算出した容量消費傾向とに基づいて、所定の時間後に実施し得る第１の要求性能が満たされるための対策案を生成する技術が開示されている。

また、アプリケーションの性能や可用性が低下した場合に、アプリケーションをスケールアウトすることで対策を取る技術が非特許文献１及び２において公開されている。

特開２００９−１９９５３４号公報 特願２０１４−５４５４７８

"Production-Grade Container Orchestraion"、［online］、kubernetes、［平成29年１月24日検索］、インターネット〈URL: http://kubernetes.io/〉 "Program against your datacenter like it's a single pool of resources"、［online］、Apache MESOS、［平成29年１月24日検索］、インターネット〈http://mesos.apache.org/〉

特許文献１で開示されているような予兆検知の技術では、予兆検知に必要となる相関モデルを生成するために、ある程度の期間アプリケーションを運用し、性能などの稼働情報を収集する必要がある。従来のアプリケーションの開発・運用手法では、開発やテストに十分に時間を掛けて、比較的長いリリースサイクルでアプリケーションをリリースするため、例えばテスト期間中に上述のような稼働情報を収集し、精度の良い相関モデルを事前に生成しておくことができる。

一方、近年、アプリケーションの開発・運用手法としてＤｅｖＯｐｓと呼ばれるソフトウェアの開発手法が注目されている。ＤｅｖＯｐｓでは、従来の開発・運用手法と異なり、短期間でアプリケーションの設計、開発、テスト、運用のサイクルを回すことにより、高頻度なアプリケーションのリリースを実現している。このようにアプリケーションのリリースが早い場合、十分に稼働情報を収集することができず、事前に精度の良い相関モデルを生成することができない。従って、このようなアプリケーションにおいて、特許文献１で開示されているような方法で予兆検知を行う場合には、運用が始まった時点では予兆検知の精度が低く、運用の中で精度を向上していく必要がある。

しかしながら、特許文献１及び２や、非特許文献１及び２の技術を組み合わせて、アプリケーションの性能劣化や障害などを予兆段階で検知し、これら性能劣化や障害を未然に防ぐ対策を取る運用を行った場合、以下の（ａ）〜（ｃ）の問題が生じる。

（ａ）予兆検知の精度が低いため、予兆が誤っている可能性がある。予兆が正しいことを検証するためには、その後、実際に性能劣化が起こったか否かの結果と、予兆とを比較することで検証できる。しかし予兆に基づいて特許文献２で開示されているような方法で対策を行った場合、この対策によって将来的に発生する可能性のあった性能劣化や障害は発生しなくなる。このため予兆が正しかったか否かの検証ができず、予兆検知の精度を向上できない。

（ｂ）アプリケーションの性能劣化や障害の予兆が、アプリケーションの実装上の問題により発生している可能性がある。しかし、予兆に基づいて事前対策を取った場合、性能劣化や障害が発生しなくなるため、アプリケーションの実装上の問題に気付きにくい。

（ｃ）アプリケーションのバージョンアップによりアプリケーションの振る舞いが変化する。旧バージョンのアプリケーションの運用の中で精度向上した相関モデルが、必ずしも新バージョンのアプリケーションに対する予兆検知に好適であるとは限らない。

本発明は以上の点を考慮してなされたもので、精度の高い予兆検知を行い得る予兆検知装置及び予兆検知方法を提案しようとするものである。

かかる課題を解決するため本発明においては、アプリケーションのサービスレベルの低下の予兆を検知する予兆検知装置において、前記アプリケーションの稼働データを収集する稼働データ収集部と、前記稼働データのデータ値と、前記サービスレベルとの相関を表す相関モデルを生成する相関モデル生成部と、前記アプリケーションの最新の前記稼働データのデータ値と、前記相関モデルとに基づいて、前記アプリケーションの前記サービスレベルの低下の予兆を検知する予兆検知部と、前記予兆検知部により前記アプリケーションの前記サービスレベルの低下の予兆が検知された場合に、前記アプリケーションのインスタンスの中から、当該サービスレベルの低下を防止するための所定の事前対策を実施しない第１のインスタンスと、当該事前対策を実施する第２のインスタンスとをそれぞれ選択し、前記第２のインスタンスに前記事前対策を実施する事前対策部と、前記アプリケーションの前記事前対策を実施しなかった前記第１のインスタンスの稼働データを監視し、当該稼働データに基づいて前記サービスレベルの低下を検知しなかった場合に、前記予兆検知部により検知された前記予兆を、前記サービスレベルの低下の予兆に含めないように前記相関モデルを修正する予兆検証部とを設けるようにした。

また本発明においては、アプリケーションのサービスレベルの低下の予兆を検知する予兆検知装置において実行される予兆検知方法であって、前記予兆検知装置は、前記アプリケーションの稼働データを収集し、前記予兆検知装置が、前記稼働データのデータ値と、前記サービスレベルとの相関を表す相関モデルを生成する第１のステップと、前記予兆検知装置が、前記アプリケーションの最新の前記稼働データのデータ値と、前記相関モデルとに基づいて、前記アプリケーションの前記サービスレベルの低下の予兆を検知する第２のステップと、前記予兆検知装置が、前記アプリケーションの前記サービスレベルの低下の予兆を検知した場合に、前記アプリケーションのインスタンスの中から、当該サービスレベルの低下を防止するための所定の事前対策を実施しない第１のインスタンスと、当該事前対策を実施する第２のインスタンスとをそれぞれ選択し、前記第２のインスタンスに前記事前対策を実施する第３のステップと、前記予兆検知装置が、前記アプリケーションの前記事前対策を実施しなかった前記第１のインスタンスの稼働データを監視し、当該稼働データに基づいて前記サービスレベルの低下を検知しなかった場合に、第２のステップで検知した前記予兆を、前記サービスレベルの低下の予兆に含めないように前記相関モデルを修正する第４のステップとを設けるようにした。

本発明の予兆検知装置及び予兆検知方法によれば、予兆検知の正否を検証しながら相関モデルの精度を向上させることができる。

本発明によれば、精度の高い予兆検知を行い得る予兆検知装置及び予兆検知方法を実現できる。

計算機システムの全体構成を示すブロック図である。 ＩＴインフラストラクチャの論理構成の一例を示すブロック図である。 第１の実施形態による管理サーバの構成例を示すブロック図である。 ＩＴインフラストラクチャ構成テーブルの構成例を示す図表である。 アプリケーション構成テーブルの構成例を示す図表である。 アプリケーション稼働データテーブルの構成例を示す図表である。 第１の実施形態によるアプリケーション稼働データクラスタテーブルの構成例を示す図表である。 負荷分散設定テーブルの構成例を示す図表である。 アプリケーション問題管理テーブルの構成例を示す図表である。 対策効果テーブルの構成例を示す図表である。 メトリクス空間設定画面の構成例を示す図である。 第１の実施形態によるアプリケーション監視処理の処理手順の一例を示すフローチャートである。 第１の実施形態による予兆検知処理の処理手順の一例を示すフローチャートである。 事前対策処理の処理手順の一例を示すフローチャートである。 第１の実施形態による予兆検証処理の処理手順の一例を示すフローチャートである。 第２の実施形態による管理サーバの構成例を示すブロック図である。 第２の実施形態によるアプリケーション稼働データクラスタテーブルの構成例を示す図表である。 第２の実施形態によるアプリケーション監視処理の処理手順の一例を示すフローチャートである。 第２の実施形態による予兆検知処理の処理手順の一例を示すフローチャートである。 第２の実施形態による予兆検証処理の処理手順の一例を示すフローチャートである。 初期アプリケーション稼働データクラスタ決定処理の処理手順の一例を示すフローチャートである。 判定結果の一例を示す図表である。

以下、幾つかの実施形態を、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。なお、以後の説明では「ａａａテーブル」等の表現にて本発明の情報を説明するが、これら情報はテーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名称」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。

以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信デバイス、管理Ｉ／Ｆ、データＩ／Ｆ）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。

以後、計算機システムを管理し、本発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は管理サーバが管理システムである、また、管理サーバと表示用計算機との組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。

（１）第１の実施形態
（１−１）本実施形態による計算機システムの構成
図１は、本実施形態におけるシステム構成を示す。本実施形態の計算機システム１０００は、複数のクラウドから構成される。図１ではクラウド２０００及びクラウド３０００により計算機システム１０００が構成されている例を示している。クラウド２０００はリージョン１（例えば米国西海岸）に、クラウド３０００はリージョン２（例えば米国東海岸）に設置されている。

クラウド２０００は、管理サーバ４０００、ＩＴインフラストラクチャ５０００、管理ネットワーク６０００及びデータネットワーク７０００を備えて構成される。ＩＴインフラストラクチャ５０００は、コンピュートサーバ５１００、ストレージサーバ５２００及びストレージ装置５３００を備えて構成され、これらコンピュートサーバ５１００、ストレージサーバ５２００及びストレージ装置５３００が管理サーバ４０００と管理ネットワーク６０００を介して接続されている。また、ＩＴインフラストラクチャ５０００の構成要素（コンピュートサーバ５１００、ストレージサーバ５２００及びストレージ装置５３００）同士は、データネットワーク７０００を介して接続されている。

同様に、クラウド３０００も、ＩＴインフラストラクチャ５０００、管理ネットワーク６０００及びデータネットワーク７０００を備えて構成される。ＩＴインフラストラクチャ５０００は、コンピュートサーバ５１００、ストレージサーバ５２００及びストレージ装置５３００を備えて構成され、これらコンピュートサーバ５１００、ストレージサーバ５２００及びストレージ装置５３００が管理サーバ４０００と管理ネットワーク６０００を介して接続されている。またＩＴインフラストラクチャ５０００の構成要素（コンピュートサーバ５１００、ストレージサーバ５２００及びストレージ装置５３００）同士は、データネットワーク７０００を介して接続されている。

クラウド２０００及びクラウド３０００間は、広域ネットワーク８０００を介して接続されている。すなわち、クラウド２０００の管理ネットワーク６０００と、クラウド３０００の管理ネットワーク６０００とは、広域ネットワーク８０００を介して通信可能な状態にある。また、クラウド２０００のデータネットワーク７０００と、クラウド３０００のデータネットワーク７０００とは、広域ネットワーク８０００を介して通信可能な状態にある。

なお、クラウド２０００及びクラウド３０００が持つ管理ネットワーク６０００とデータネットワーク７０００とは、同一のネットワークであっても良い。また、管理サーバ４０００がクラウド３０００内に存在していても良い。

図２は、本実施形態におけるＩＴインフラストラクチャ５０００の構成の一例を示す。上述のようにＩＴインフラストラクチャ５０００は、コンピュートサーバ５１００（５１００Ａ，５１００Ｂ，５１００Ｃ）と、ストレージサーバ５２００と、ストレージ装置５３００とを備えて構成される。

コンピュートサーバ５１００（５１００Ａ，５１００Ｂ，５１００Ｃ）は、アプリケーションを実行するためのサーバである。第１のコンピュートサーバ５１００Ａでは、ホストＯＳ（Operating System）５１１０が稼働しており、ホストＯＳ５１１０が提供するユーザ空間内でアプリケーションソフトウェア（以下、これを単にアプリケーションと呼ぶ）５１１１が稼働している。また第２のコンピュートサーバ５１００Ｂでは、ホストＯＳ５１２０が提供するユーザ空間内でコンテナ５１２１が稼働している。さらにコンテナ５１２１が提供する仮想的なユーザ空間内でアプリケーション５１２２が稼働している。第３のコンピュートサーバ５１００Ｃでは、ホストＯＳ５１３０上でハイパーバイザ５１３１が稼働している。さらに、ハイパーバイザ５１３１が提供する仮想マシン（以下、これをＶＭ（Virtual Machine）と呼ぶ）上でゲストＯＳ５１３３が稼働しており、ゲストＯＳ５１３３が提供するユーザ空間内でアプリケーション５１３４が稼働している。

ストレージサーバ５２００は、自身が持つ記憶装置の容量を他のサーバに提供するサーバである。ストレージサーバ５２００は、記憶装置５２１０を備えている。ストレージサーバ５２００ではホストＯＳ５２１１が稼働しており、ホストＯＳ５２１１が提供するユーザ空間内でストレージコントローラプログラム５２１２が稼働している。ストレージコントローラプログラム５２１２は、記憶装置５２１０に対するデータの読み書きや、アクセス制御、データ保護機能などのストレージ機能を提供する。なお、コンピュートサーバ５１００及びストレージサーバ５２００を１つのサーバに統合しても良い。例えばストレージサーバ５２００が持つホストＯＳ５２１１上でアプリケーション５１１１等を稼働させても良い。

ストレージ装置５３００は、自身が持つ記憶装置の容量を他のサーバに提供する専用の記憶装置である。ストレージ装置５３００は、通常、コンピュートサーバ５１００やストレージサーバ５２００で用いられるハードウェアとは異なる専用ハードウェアを有していることが多いが、ストレージサーバ５２００の一種と見なしても良い。ストレージ装置５３００は、記憶装置５３１０と、ストレージコントローラ５３１１とを備えている。ストレージコントローラ５３１１は、ストレージサーバ５２００上のストレージコントローラプログラム５２１２と同様のストレージ機能を提供する専用ハードウェアである。

図３は、本実施形態における管理サーバ４０００の構成の一例を示す。管理サーバ４０００は、管理ネットワークインタフェース４１００、プロセッサ４２００、Ｉ／Ｏ（Input/Output）デバイス４３００、記憶装置４４００及びメモリ４５００を備えている。これらの構成要素は互いにバス４６００を介して接続されている。

管理ネットワークインタフェース４１００は、管理ネットワーク６０００との接続に用いるネットワークインタフェースである。

記憶装置４４００は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などから構成される。本実施形態の場合、記憶装置４４００には、セルフサービスポータルプログラム４４１０、管理プログラム４４２０、予兆検知プログラム４４３０、予兆検証プログラム４４４０及びアプリケーション問題管理プログラム４４５０が格納されている。これらプログラムは、プロセッサ４２００によってメモリ４５００上に読み出されて実行される。

セルフサービスポータルプログラム４４１０は、計算機システム１０００のユーザに対して、計算機システム１０００を使用するためのユーザインタフェースを提供する。例えばセルフサービスポータルプログラム４４１０が、計算機システム１０００のユーザに対して、クラウド２０００やクラウド３０００上にアプリケーション５１１１，５１２２，５１３４（図２）をデプロイして稼働させるためのユーザインタフェースを提供するようにしても良い。また、例えばセルフサービスポータルプログラム４４１０が、クラウド２０００やクラウド３０００上にデプロイされたアプリケーション５１１１，５１２２，５１３４の稼働情報を監視するためのユーザインタフェースを提供するようにしても良い。

管理プログラム４４２０は、ＩＴインフラストラクチャ５０００を管理するプログラムである。管理プログラム４４２０は、ＩＴインフラストラクチャ５０００の構成情報や稼働情報などを収集して保持する。また管理プログラム４４２０は、ＩＴインフラストラクチャ５０００の各構成要素に対して構成変更を行う。例えば管理プログラム４４２０は、ストレージサーバ５２００やストレージ装置５３００が持つ記憶装置５２１０，５３１０（図２）から、論理的な記憶領域を切り出し、コンピュートサーバ５１００に割り当てる機能を提供しても良い。また、例えば管理プログラム４４２０は、コンピュートサーバ５１００Ｂ（図２）が持つホストＯＳ５１２０（図２）上に新たなコンテナを作成して稼働させる機能を提供しても良い。また、例えば管理プログラム４４２０は、コンピュートサーバ５１００Ｃ（図２）が持つハイパーバイザ５１３１（図２）上に新たなＶＭ５１３２（図２）を作成して稼働させる機能を提供しても良い。さらに管理プログラム４４２０は、計算機システム１０００のユーザのリクエストに応じて、ＩＴインフラストラクチャ５０００が持つコンピュートサーバ５１００上にアプリケーション５１１１，５１２２，５１３４をデプロイする機能を有する。

予兆検知プログラム４４３０は、ＩＴインフラストラクチャ５０００上で稼働するアプリケーション５１１１，５１２２，５１３４（図２）における性能劣化や障害などのサービスレベルの低下の予兆を検知するプログラムである。後述するように、本実施形態においては、かかる予兆をアプリケーション５１１１，５１２２，５１３４のレスポンスタイムに基づいて検知する。

予兆検証プログラム４４４０は、予兆検知プログラム４４３０によって検知された予兆の正しさを検証するプログラムである。またアプリケーション問題管理プログラム４４５０は、アプリケーション５１１１，５１２２，５１３４（図２）の実装上の問題を管理するプログラムである。

メモリ４５００は、例えば半導体メモリから構成される。本実施形態の場合、メモリ４５００には、ＩＴインフラストラクチャ構成テーブル４５１０、アプリケーション構成テーブル４５２０、アプリケーション稼働データテーブル４５３０、アプリケーション稼働データクラスタテーブル４５４０、負荷分散設定テーブル４５５０、アプリケーション問題管理テーブル４５６０、及び、対策効果テーブル４５７０が格納される。各テーブルの詳細は後述する。なお、各テーブルは記憶装置４４００内に保持されても良い。

記憶装置４４００やメモリ４５００には、他に、ＩＴインフラストラクチャ５０００を管理するための一般的なプログラムやテーブルが格納されていても良い。例えばメモリ４５００に、計算機システム１０００のユーザの情報（ユーザ名、パスワード、ＩＴインフラストラクチャに対するアクセス権限など）を保持するテーブルが格納されていても良い。

図４は、本実施形態におけるＩＴインフラストラクチャ構成テーブル４５１０の一例を示す。ＩＴインフラストラクチャ構成テーブル４５１０は、ＩＴインフラストラクチャ５０００の構成情報を保持するテーブルである。このＩＴインフラストラクチャ構成テーブル４５１０は、装置ＩＤ欄４５１１、リージョンＩＤ欄４５１２、リソースＩＤ欄４５１３及びリソース容量欄４５１４を備えて構成される。

そして装置ＩＤ４５１１には、ＩＴインフラストラクチャ５０００を構成するコンピュートサーバ５１００やストレージサーバ５２００及びストレージ装置５３００にそれぞれ付与された識別子（装置ＩＤ）が格納される。またリージョンＩＤ欄４５１２には、対応するコンピュートサーバ５１００、ストレージサーバ５２００又はストレージ装置５３００が設置されているリージョンに付与された識別子（リージョンＩＤ）が格納される。さらにリソースＩＤ欄４５１３には、対応するコンピュートサーバ５１００、ストレージサーバ５２００又はストレージ装置５３００が備える各リソースにそれぞれ付与された識別子（リソースＩＤ）が全て格納される。かかるリソースとしては、例えばＣＰＵ（Central Processing Unit）コアやＲＡＭ（Random Access Memory）、ＮＩＣ（Network Interface Card）、ＳＳＤ及び又はＨＤＤなどを挙げることができる。リソース容量欄４５１４には、各リソースの性能や容量を示す情報が格納される。

図５は、本実施形態におけるアプリケーション構成テーブル４５２０の一例を示す。アプリケーション構成テーブル４５２０は、アプリケーション５１１１，５１２２，５１３４（図２）からＩＴインフラストラクチャ５０００を構成するコンピュートサーバ５１００、ストレージサーバ５２００及びストレージ装置５３００までの構成情報を保持するテーブルである。アプリケーション構成テーブル４５２０は、アプリＩＤ欄４５２１、バージョン欄４５２２、アプリインスタンスＩＤ欄４５２３、アプリ実行環境ＩＤ欄４５２４、サーバＩＤ欄４５２５、サーバポートＩＤ欄４５２６、ストレージポートＩＤ欄４５２７、ストレージＩＤ欄４５２８、及び、ボリュームＩＤ欄４５２９を備えて構成される。

そしてアプリＩＤ欄４５２１には、各アプリケーション５１１１，５１２２，５１３４（図２）にそれぞれ付与された識別子（アプリＩＤ）が格納される。またバージョン欄４５２２には、対応するアプリケーション５１１１，５１２２，５１３４（図２）のバージョンを示す情報が格納される。アプリインスタンスＩＤ欄４５２３には、対応するアプリケーション５１１１，５１２２，５１３４の各インスタンス（以下、これをアプリインスタンス又はアプリケーションインスタンスとも呼ぶ）にそれぞれ付与された識別子（アプリインスタンスＩＤ）がすべて格納される。さらにアプリ実行環境ＩＤ欄４５２４には、対応するインスタンスの実行環境（ベアメタルサーバ、コンテナ、ＶＭなど）を表す識別子（アプリ実行環境ＩＤ）が格納される。

サーバＩＤ欄４５２５には、対応するインスタンスの実行環境を提供するコンピュートサーバ５１００（図１）に付与された識別子（サーバＩＤ）が格納される。またサーバポートＩＤ欄４５２６には、そのコンピュートサーバ５１００が持つネットワークインタフェースに付与された識別子（サーバポートＩＤ）が格納される。さらにストレージポートＩＤ欄４５２７には、ストレージサーバ５２００（図２）やストレージ装置５３００（図２）が持つネットワークインタフェースのネットワークポートのうち、対応するインスタンスが利用するネットワークポートに付与された識別子（ストレージポートＩＤ）が格納される。

またストレージＩＤ欄４５２８には、対応するインスタンスに対して記憶容量を提供しているストレージサーバ５２００又はストレージ装置５３００に付与された識別子（ストレージＩＤ）が格納される。さらにボリュームＩＤ欄４５２９には、対応するインスタンスに対してストレージサーバ５２００又はストレージ装置５３００が提供する記憶領域（ボリューム）に対して付与された識別子（ボリュームＩＤ）が格納される。

図６は、本実施形態におけるアプリケーション稼働データテーブル４５３０の一例を示す。アプリケーション稼働データテーブル４５３０は、コンピュートサーバ５１００に実装された各アプリケーション５１１１，５１２２，５１３４の稼働情報（性能情報や障害情報など）を保持するテーブルである。

実際上、本実施形態においては、アプリケーション５１１１，５１２２，５１３４ごとに、そのアプリケーション５１１１，５１２２，５１３４について予め定められた後述するメトリクス空間を構成するメトリックなどの必要なメトリックのデータ値を定期的（例えば１秒ごと）にそれぞれ取得する。そして、このように取得された各メトリックのデータ値がそのアプリケーション５１１１，５１２２，５１３４の稼働情報（以下、稼働データとも呼ぶ）としてこのアプリケーション稼働データテーブル４５３０に蓄積される。

このアプリケーション稼働データテーブル４５３０は、アプリＩＤ欄４５３１、バージョン欄４５３２、アプリインスタンスＩＤ欄４５３３、メトリック名欄４５３４、外的要因フラグ欄４５３５、時刻欄４５３６、及び、データ値欄４５３７を備えて構成される。

そしてアプリＩＤ欄４５３１には、コンピュートサーバ５１００に実装された各アプリケーション５１１１，５１２２，５１３４にそれぞれ付与されたアプリＩＤが格納される。またバージョン欄４５３２には、対応するアプリケーション５１１１，５１２２，５１３４のバージョンを示す情報が格納される。さらにアプリインスタンスＩＤ欄４５３３は、対応するアプリケーション５１１１，５１２２，５１３４のすべてのインスタンスのアプリインスタンスＩＤが格納される。さらにメトリック名欄４５３４には、対応するアプリケーション５１１１，５１２２，５１３４の対応するインスタンスについて設定されたメトリックの名前（メトリック名）を示す情報が格納される。

外的要因フラグ欄４５３５には、対応するメトリックが対応するアプリケーション５１１１，５１２２，５１３４の稼働情報を変化させる外的要因であるか否かを示すフラグ（以下、これを外的要因フラグと呼ぶ）が格納される。図６の例では、対応するメトリックが対応するアプリケーション５１１１，５１２２，５１３４の稼働情報を変化させる外的要因ではない場合には外的要因フラグが「０」に設定され、当該メトリックが当該アプリケーション５１１１，５１２２，５１３４の稼働情報を変化させる外的要因である場合には外的要因フラグが「１」に設定される。

時刻欄４５３６には、対応するアプリケーションの対応するバージョンの対応するインスタンスに関して対応するメトリックのデータ値を取得した時刻が格納される。またデータ値欄４５３７には、対応する時刻に取得した対応するメトリックのデータ値が格納される。

図７は、本実施形態におけるアプリケーション稼働データクラスタテーブル４５４０の一例を示す。アプリケーション稼働データクラスタテーブル４５４０は、アプリケーション５１１１，５１２２，５１３４の稼働データをクラスタリングした結果得られた、稼働データのデータ値と性能との相関を表す相関モデル（以下、適宜、これを予兆検知モデルと呼ぶ）を保持するテーブルである。

後述のように、本実施形態においては、アプリケーション５１１１，５１２２，５１３４ごとに、そのアプリケーション５１１１，５１２２，５１３４の稼働データ（そのアプリケーション５１１１，５１２２，５１３４について予め設定された各メトリックのデータ値）をアプリケーション稼働データテーブル４５３０に登録する度に、予め設定された条件を満たす稼働データのクラスタリングが行われる。アプリケーション稼働データクラスタテーブル４５４０は、このようにして行われたクラスタリングの結果を保持するためのテーブルである。

このアプリケーション稼働データクラスタテーブル４５４０は、アプリＩＤ欄４５４１、バージョン欄４５４２、メトリクス空間欄４５４３、条件欄４５４４、クラスタＩＤ欄４５４５、クラスタ中心欄４５４６、及び、標準偏差欄４５４７を備えて構成される。

そしてアプリＩＤ欄４５４１には、コンピュートサーバ５１００に実装された各アプリケーション５１１１，５１２２，５１３４のアプリＩＤが格納される。またバージョン欄４５４２には、対応するアプリケーション５１１１，５１２２，５１３４のバージョンが格納される。さらにメトリクス空間欄４５４３には、対応するアプリケーション５１１１，５１２２，５１３４の対応するバージョンについて予め設定されたメトリクス空間を構成する１つ以上のメトリックの組み合わせが格納される。

条件欄４５４４には、対応するアプリケーション５１１１，５１２２，５１３４の対応するバージョンについて対応するメトリクス空間において稼働データをクラスタリングする際の対象とすべき稼働データの条件が格納される。例えば図７の例では、「アプリＡ」というアプリケーション５１１１，５１２２，５１３４のある時刻における稼働データにおいて、「Response Time」の値が「20」より小さい場合に、その稼働データに含まれる「Queue Depth」、「Request Per Second」、「Input Data Average Size」の値の組合せを該当メトリクス空間においてクラスタリングすべきことが規定されている。

クラスタＩＤ欄４５４５には、対応するメトリクス空間内に生成された各クラスタにそれぞれ付与された識別子（クラスタＩＤ）が格納される。またクラスタ中心欄４５４６には、対応するメトリクス空間における対応するクラスタの中心位置の座標が格納される。さらに標準偏差欄４５４７には、対応するクラスタに含まれる稼働データの標準偏差を示す情報が格納される。

図８は、本実施形態における負荷分散設定テーブル４５５０の一例を示す。負荷分散設定テーブル４５５０は、各アプリケーション５１１１，５１２２，５１３４の各インスタンスに対するロードバランサによる負荷分散の設定情報を格納するテーブルである。なお、図２ではロードバランサの記載は省略したが、ロードバランサはアプリケーション５１１１，５１２２，５１３４と同様に、任意のコンピュートサーバ５１００（図１）上で稼働するものとする。この負荷分散設定テーブル４５５０は、アプリＩＤ欄４５５１、バージョン欄４５５２、ロードバランサＩＤ欄４５５３、アプリインスタンスＩＤ欄４５５４、及び、負荷バランス欄４５５５を備えて構成される。

そしてアプリＩＤ欄４５５１には、コンピュートサーバ５１００に実装された各アプリケーション５１１１，５１２２，５１３４のアプリＩＤが格納され、バージョン欄４５５２には、対応するアプリケーション５１１１，５１２２，５１３４のバージョンが格納される。またロードバランサＩＤ欄４５５３には、対応するアプリケーション５１１１，５１２２，５１３４の負荷分散を行うロードバランサに付与された識別子（ロードバランサＩＤ）が格納される。

さらにアプリインスタンスＩＤ欄４５５４には、対応するアプリケーション５１１１，５１２２，５１３４のすべてのインスタンスのアプリインスタンスＩＤがそれぞれ格納され、負荷バランス欄４５５５には、対応するアプリケーション５１１１，５１２２，５１３４の対応するインスタンスに対してロードバランサが割り当てるべき、予め定められた負荷のバランスを表す情報が格納される。

図９は、本実施形態におけるアプリケーション問題管理テーブル４５６０の一例を示す。アプリケーション問題管理テーブル４５６０は、コンピュートサーバ５１００に実装されたアプリケーション５１１１，５１２２，５１３４の実装上の問題点を保持するテーブルである。このアプリケーション問題管理テーブル４５６０は、アプリＩＤ欄４５６１、バージョン欄４５６２、登録時刻欄４５６３、現象欄４５６４、及び、条件欄４５６５を備えて構成される。

そしてアプリＩＤ欄４５６１には、コンピュートサーバ５１００に実装された各アプリケーション５１１１，５１２２，５１３４にそれぞれ付与されたアプリＩＤが格納され、バージョン欄４５６２には、対応するアプリケーション５１１１，５１２２，５１３４のバージョンを示す情報が格納される。また登録時刻欄４５６３には、対応するアプリケーション５１１１，５１２２，５１３４における対応するバージョンの実装上の問題が登録された時刻が格納される。さらに現象欄４５６４には、対応するアプリケーション５１１１，５１２２，５１３４における対応するバージョンの実装上の問題によって引き起こされた現象を示す情報が格納される。

条件欄４５６５には、対応する現象が発生した条件を示す情報が格納される。例えば図９の例では、「アプリＡ」のバージョン「1.0」において、インスタンス数が「３」、かつ「Queue Depth=20.0」、「Request Per Second=50」及び「Input Data Average Size=150」という条件を満たした際に、該当アプリケーション５１１１，５１２２，５１３４の「Response Time」が「50」より長くなったという現象（性能劣化）がそのアプリケーション５１１１，５１２２，５１３４におけるそのバージョンの実装上の問題として登録されている状態を示している。

図１０は、本実施形態における対策効果テーブル４５７０の一例を示す。対策効果テーブル４５７０は、あるアプリケーション５１１１，５１２２，５１３４のインスタンスにおいて性能劣化などの予兆が検知された際に管理プログラム４４２０によって実行された事前対策の効果を保持するテーブルである。この対策効果テーブル４５７０は、アプリＩＤ欄４５７１、バージョン欄４５７２、メトリクス空間欄４５７３、外れ値欄４５７４、最近傍クラスタＩＤ欄４５７５、正規化距離欄４５７６、対策プラン欄４５７７、及び、効果欄４５７８を備えて構成される。

そしてアプリＩＤ欄４５７１には、コンピュートサーバ５１００に実装された各アプリケーション５１１１，５１２２，５１３４のアプリＩＤが格納され、バージョン欄４５７２には、対応するアプリケーション５１１１，５１２２，５１３４のバージョンが格納される。またメトリクス空間欄４５７３には、対応するアプリケーション５１１１，５１２２，５１３４について予め設定されたメトリクス空間を構成する１つ以上のメトリックの組み合わせを示す情報が格納される。

外れ値欄４５７４には、対応するメトリクス空間においてどのクラスタにも属さないと判定された稼働データの値（外れ値）が格納される。本実施形態の場合、図６及び図７について上述したように、アプリケーション５１１１，５１２２，５１３４ごとに、そのアプリケーション５１１１，５１２２，５１３４について予め設定されたメトリクス空間を構成する各メトリックのデータ値等をそのアプリケーション５１１１，５１２２，５１３４の稼働データとして定期的に取得し、これをそのメトリクス空間上でクラスタリングしている。外れ値は、このようなクラスタリングによりどのクラスタにも属さないと判定された稼働データの値（外れ値）が格納される。

また最近傍クラスタ欄ＩＤ４５７５には、外れ値欄４５７４に格納された値（外れ値）に最も近い位置に存在するクラスタ（以下、これを最近傍クラスタと呼ぶ）のＩＤ（最近傍クラスタＩＤ）が格納される。

正規化距離欄４５７６には、対応する外れ値欄４５７４に格納された値と、対応する最近傍クラスタの中心との距離を正規化した値が格納される。正規化距離の算出方法には、例えば、外れ値と最近傍クラスタのユークリッド距離を、該当クラスタの標準偏差で除算するなどの方法があるが、限定はしない。また対策プラン欄４５７７には、対応するアプリケーション５１１１，５１２２，５１３４の対応するバージョンのインスタンスにおいて性能劣化などの予兆が検知された際に管理プログラム４４２０によって実行された事前対策が格納される。

効果欄４５７８には、性能劣化などの予兆に対する該当の事前対策による効果を示す情報が格納される。例えば図１０の例では、「アプリＡ」というアプリケーション５１１１，５１２２，５１３４のバージョン「1.0」において、「Queue Depth」、「Request Per Second」、「Input Data Average Size」から構成されるメトリクス空間で「Queue Depth =20.0」、「Request Per Second=50」、「Input Data Average Size=150」で示される外れ値が検出された際に、事前対策として該当アプリケーション５１１１，５１２２，５１３４のインスタンス数を２倍にするスケールアウトを実行した結果、性能劣化が起こらなくなったことを示している。また図１０の例では、同じメトリクス空間で「Queue Depth =30.0」、「Request Per Second=50」、「Input Data Average Size=150」で示される外れ値が検出された際に、該当アプリケーション５１１１，５１２２，５１３４のインスタンス数を２倍にするスケールアウトを実行した際には、該当アプリケーション５１１１，５１２２，５１３４において「10％」の「Response Time」の劣化が発生したことを示している。

（１−２）メトリクス空間設定画面
図１１は、本実施形態におけるセルフサービスポータルプログラム４４１０により管理サーバ４０００に表示されるメトリクス空間設定画面４４１０Ａの構成例を示す。メトリクス空間設定画面４４１０Ａは、計算機システム１０００のユーザが所望するアプリケーション５１１１，５１２２，５１３４の所望するバージョンに対してメトリクス空間を設定するためのユーザインタフェースである。

このメトリクス空間設定画面４４１０Ａは、メトリクス空間を設定しようとするアプリケーション５１１１，５１２２，５１３４（バージョンを含む）を指定するためのアプリケーション指定フィールド４４１１Ａと、そのアプリケーション５１１１，５１２２，５１３４に対するメトリクス空間を設定するためのメトリクス空間設定フィールド４４１２Ａと、クラスタリングするデータの条件を設定するための条件設定フィールド４４１３Ａと、ＯＫボタン４４１４Ａ及びキャンセルボタン４４１５Ａとを備えて構成される。

アプリケーション指定フィールド４４１１Ａは、アプリケーション名表示欄４４１１ＡＡ及びドロップダウンボタン４４１１ＡＢを備えて構成される。そしてアプリケーション指定フィールド４４１１Ａでは、ドロップダウンボタン４４１１ＡＢをクリックすることによりメトリクス空間を設定可能なすべてのアプリケーション５１１１，５１２２，５１３４のアプリケーション名（バージョンを含む）が掲載されたドロップダウンリスト（図示せず）を表示させることができ、このドロップダウンリストにアプリケーション名が掲載されたアプリケーション５１１１，５１２２，５１３４の中から所望するアプリケーション５１１１，５１２２，５１３４を選択することにより、そのアプリケーション５１１１，５１２２，５１３４をメトリクス空間の設定対象として指定することができる。なお、このとき指定されたアプリケーション５１１１，５１２２，５１３４のアプリケーション名がアプリケーション名表示欄４４１１ＡＡに表示される。

またメトリクス空間設定フィールド４４１２Ａは、メトリクス空間４４１２ＡＡ及びメトリクス空間追加ボタン４４１２ＡＢを備えて構成される。またメトリクス空間４４１２ＡＡには、１又は複数のテキストボックス４４１２ＡＡＸと、メトリック追加ボタン４４１２ＡＡＹとが設けられている。そしてメトリクス空間４４１２ＡＡでは、所望する各メトリックの名前をそれぞれテキストボックス４４１２ＡＡＸに入力することにより、これらのメトリックをそのとき設定しようとするメトリクス空間を構成するメトリックとして指定することができる。またメトリクス空間４４１２ＡＡでは、メトリック追加ボタン４４１２ＡＡＹをクリックすることにより、メトリックを入力するためのテキストボックス４４１２ＡＡＸを追加表示させることができる。さらにメトリクス空間設定フィールド４４１２Ａでは、メトリクス空間追加ボタン４４１２ＡＢをクリックすることにより、メトリクス空間４４１２ＡＡを追加表示させることができる。これにより１つのアプリケーション５１１１，５１２２，５１３４に対して複数のメトリクス空間を設定することができるようになされている。

条件設定フィールド４４１３Ａは、メトリック用テキストボックス４４１３ＡＡ、条件指定欄４４１３ＡＢ、ドロップダウンボタン４４１３ＡＣ、値用テキストボックス４４１３ＡＤ及び条件追加ボタン４４１３ＡＥを備えて構成される。そして条件設定フィールド４４１３Ａでは、ドロップダウンボタン４４１３ＡＣをクリックすることにより、不等号などの記号の一覧が掲載されたドロップダウンリスト（図示せず）を表示させることができ、このドロップダウンリストに掲載された記号の中から所望する記号を選択することにより、その記号を条件指定欄４４１３ＡＢに表示させることができる。これにより条件設定フィールド４４１３Ａでは、メトリック用テキストボックス４４１３ＡＡに所望するメトリックの名前を入力すると共に、値用テキストボックス４４１３ＡＤに値を入力し、さらに条件指定欄４４１３ＡＢに所望する記号を表示させることにより、クラスタリングすべき稼働データの条件を設定することができる。また条件設定フィールド４４１３Ａでは、条件追加ボタン４４１３ＡＥをクリックすることにより、メトリック用テキストボックス４４１３ＡＡ、条件指定欄４４１３ＡＢ、ドロップダウンボタン４４１３ＡＣ及び値用テキストボックス４４１３ＡＤのセットを追加表示させることができる。これにより１つのアプリケーション５１１１，５１２２，５１３４に対して複数の条件を設定することができるようになされている。

そしてメトリクス空間設定画面４４１０Ａでは、上述のようにしてアプリケーション指定フィールド４４１１Ａにおいて対象とするアプリケーション５１１１，５１２２，５１３４を指定し、メトリクス空間設定フィールド４４１２Ａにおいてそのとき設定しようとするメトリクス空間を定義し、条件設定フィールド４４１３Ａにおいてクラスタリングする稼働データの条件を設定した後、ＯＫボタン４４１４Ａをクリックすることにより、その内容を設定することができる。この設定内容は、セルフサービスポータルプログラム４４１０によってアプリケーション稼働データクラスタテーブル４５４０（図７）に格納される。またメトリクス空間設定画面４４１０Ａでは、キャンセルボタン４４１５Ａをクリックすることにより、アプリケーション指定フィールド４４１１Ａ、メトリクス空間設定フィールド４４１２Ａ及び条件設定フィールド４４１３Ａにおいて指定した条件を設定することなく、閉じることができる。

（１−３）管理サーバにおいて実行される各種処理
（１−３−１）アプリケーション監視処理
図１２は、管理プログラム４４２０により実行されるアプリケーション監視処理の処理手順を示す。管理プログラム４４２０は、この図１２に示す手順に従って、アプリケーション５１１１，５１２２，５１３４を監視し、これらアプリケーション５１１１，５１２２，５１３４の稼働情報（稼働データ）を収集する。なお本アプリケーション監視処理は、管理プログラム４４２０の起動時に自動的に開始されるものとするが、これに限らず他の方法で開始されても良い。

まずステップＳ１にて、管理プログラム４４２０は、１つのアプリケーション５１１１，５１２２，５１３４のインスタンスごとに、そのアプリケーション５１１１，５１２２，５１３４について定められたメトリックのデータ値を稼働データとしてそれぞれ取得し、取得した稼働データをアプリケーション稼働データテーブル４５３０（図６）に格納する。アプリケーション５１１１，５１２２，５１３４の稼働データを取得する方法は、一般的なApplication Performance Monitoringソフトから取得するなど、任意の方法で良い。

続くステップＳ２にて、管理プログラム４４２０は、アプリケーション稼働データクラスタテーブル４５４０（図７）を参照して、該当アプリケーション５１１１，５１２２，５１３４について予め設定されたメトリクス空間ごとに、対応する条件欄４５４４からそのメトリクス空間について予め定められたクラスタリングを実行する条件を取得する。

次いで、管理プログラム４４２０は、ステップＳ３にて、かかるメトリクス空間ごとに、ステップＳ１で取得した稼働データの中からステップＳ２で取得した条件を満たす稼働データを抽出する。

さらに管理プログラム４４２０は、ステップＳ４にて、かかるメトリクス空間ごとに、かかる条件を満たす稼働データを抽出できたか否かを判定する。判定結果が肯定的であった場合、処理はステップＳ５に進む。判定結果が否定的であった場合、処理はステップＳ６に進む。

ステップＳ５にて、管理プログラム４４２０は、かかるメトリクス空間ごとに、アプリケーション５１１１，５１２２，５１３４の稼働データをクラスタリング（予兆検知モデルを更新）し、クラスタの情報をアプリケーション稼働データクラスタテーブル４５４０（図７）に格納する。稼働データをクラスタリングする方法としては、例えばk-means法などの一般的に知られた方法があるが、特に限定はしない。

ステップＳ６にて、管理プログラム４４２０は、予め定められた時間（例えば１秒）が経過するのを待つ。予め定められた時間が経過した後、処理はステップＳ１に戻る。従って、本処理は管理プログラム４４２０のプロセス内の１つのスレッドとして、後述する他の処理とは並列に実行することが好ましい。

なお以上のステップＳ１〜ステップＳ６の処理は、コンピュートサーバ５１００に実装された各アプリケーション５１１１，５１２２，５１３４のバージョンごとにそれぞれ実行される。

（１−３−２）予兆検知処理
図１３は、本実施形態において、予兆検知プログラム４４３０がアプリケーション５１１１，５１２２，５１３４の性能劣化の予兆を検知する予兆検知処理の処理手順を示す。

以下においては、予兆検知の対象の例としてアプリケーション５１１１，５１２２，５１３４の性能劣化を取り上げているが、これに限らず他の対象であっても良い。例えばアプリケーション５１１１，５１２２，５１３４の可用性低下の予兆を検知しても良いし、ＩＴインフラストラクチャ５０００の性能劣化や可用性の低下の予兆を検知しても良い。また、これらの予兆を検知する方法には、例えば特開２００９−１９９５３４号公報で開示されている方法などがあるが、特に限定しない。本実施の形態においてはアプリケーションの稼働データをクラスタリングし、どのクラスタにも属さない外れ値を検出するという、一般的に「教師なし学習」に分類される手法を用いているが、これに限らず他の方法で予兆を検知しても良い。また本実施形態においては、本処理は予兆検知プログラム４４３０の起動時に自動的に開始されるものとするが、これに限らず他の方法で開始されても良い。

まずステップＳ１０にて、予兆検知プログラム４４３０は、アプリケーション稼働データテーブル４５３０を参照し、１つのアプリケーション５１１１，５１２２，５１３４の最新の稼働データを取得する。最新の稼働データは、最も取得時刻の新しい稼働データ１つであっても良いし、例えば直近の10分間の稼働データなどのように、時間的に幅を持たせても良い。

続くステップＳ１１にて、予兆検知プログラム４４３０は、アプリケーション稼働データクラスタテーブル４５４０（図７）を参照し、該当アプリケーション５１１１，５１２２，５１３４の稼働データクラスタの情報を取得する。

次いで、予兆検知プログラム４４３０は、ステップＳ１２にて、ステップＳ１０で取得した最新の稼働データと、ステップＳ１１で取得した稼働データクラスタの情報とを比較し、最近傍クラスタの中心から最新の稼働データまでの距離Ｌを算出する。本実施形態においては、距離Ｌは、最新の稼働データと最近傍クラスタの中心との間のユークリッド距離を最近傍クラスタの標準偏差で除算した値とするが、これに限らず、他の方法で距離Ｌを算出しても良い。

ステップＳ１３にて、予兆検知プログラム４４３０は、算出した距離Ｌが最近傍クラスタの標準偏差のＮ倍より大きいか否かを判定する。定数Ｎの値は予め定められているものとする。判定結果が肯定的であった場合、ステップＳ１０で取得した稼働データは外れ値であるものと判断され、処理はステップＳ１４に進む。判定結果が否定的であった場合、処理はステップＳ１６に進む。

ステップＳ１４にて、予兆検知プログラム４４３０は、セルフサービスポータルプログラム４４１０が表示するセルフサービスポータルに性能劣化の予兆を表示する。表示する情報には、例えばステップＳ１３で結果が肯定的と判定された時刻や、アプリケーションのＩＤやバージョン、アプリケーション稼働データクラスタテーブル４５４０における対応するメトリクス空間欄４５４３に格納されたメトリクス空間の定義や、ステップＳ１２で算出した距離Ｌ、及び又は、最近傍クラスタの中心位置などが含まれて良い。

ステップＳ１５にて、予兆検知プログラム４４３０は、管理プログラム４４２０を呼び出し、図１４について後述する事前対策処理を実行させる。

ステップＳ１６にて、予兆検知プログラム４４３０は、予め定められた時間が経過するのを待つ。予め定められた時間が経過した後、処理はステップＳ１０に戻る。本予兆検知処理は予兆検知プログラム４４３０のプロセス内の１つのスレッドとして実行しても良い。

なお以上のステップＳ１〜ステップＳ６の処理は、コンピュートサーバ５１００に実装されたアプリケーション５１１１，５１２２，５１３４ごとに実行される。

（１−３−３）事前対策処理
図１４は、管理プログラム４４２０が、アプリケーション５１１１，５１２２，５１３４の性能劣化の予兆が検知されたことを受けて、アプリケーション５１１１，５１２２，５１３４の性能劣化が実際に起こらないようにするための事前対策を実行する事前対策処理の処理手順を示す。

本実施形態において、本事前対策処理は、予兆検知処理（図１３）のステップＳ１５にて、管理プログラム４４２０が予兆検知プログラム４４３０により呼び出されることによって開始されるものとするが、これに限らず他の方法で開始されても良い。なお、予兆検知プログラム４４３０が管理プログラム４４２０を呼び出す際に、検知した予兆に関する情報を当該管理プログラム４４２０に受け渡すものとする。従って、管理プログラム４４２０は、本事前対策処理を実施する際に、予兆が検知されたアプリケーション５１１１，５１２２，５１３４のＩＤやバージョン及び予兆の内容を特定できているものとする。

まず管理プログラム４４２０は、ステップＳ２０にて、対象とするアプリケーション５１１１，５１２２，５１３４について、事前対策を実施する１つのインスタンスと、事前対策を実施しないインスタンスとを選定する。選定の方法には例えば下記の第１〜第３の方法がある。

（Ａ）第１の方法
アプリケーション構成テーブル４５２０（図５）を参照し、対象とするアプリケーション５１１１，５１２２，５１３４の該当するバージョンの中から、インスタンスの一覧を取得する。インスタンスの一覧のうち先頭の１つを、事前対策を実施しないインスタンスとして選定する。また、対象とするアプリケーション５１１１，５１２２，５１３４のインスタンスのうち残りの全てを、事前対策を実施するインスタンスとして選定する。

（Ｂ）第２の方法
アプリケーション構成テーブル４５２０を参照し、対象とするアプリケーション５１１１，５１２２，５１３４の対象とするバージョンの中から、インスタンスの一覧を取得する。さらにＩＴインフラストラクチャ構成テーブル４５１０（図４）を参照し、各インスタンスが稼働している実行環境のリージョンを特定する。同一のリージョンで稼働するインスタンスが複数ある場合、それらのインスタンスのうちの１つを、事前対策を実施しないインスタンスとして選定する。同一のリージョンで稼働する残りのインスタンス及び他のリージョンで稼働するインスタンスはすべて、事前対策を実施するインスタンスとして選定する。

この選定方法では、例えば「リージョン１」で稼働するインスタンスが１つ、「リージョン２」で稼働するインスタンスが２つ存在する場合に、「リージョン１」で稼働するインスタンスが事前対策を実施しないインスタンスとして選定されるのを防ぐことができる。仮に「リージョン１」で稼働するインスタンスが事前対策を実施しないインスタンスとして選定した場合、このインスタンスは将来的に性能劣化が発生する可能性がある。この例では「リージョン１」で稼働する他のインスタンスは存在しないため、「リージョン１」に地理的に近いところから対象とするアプリケーションを利用しているユーザにとって、サービスレベルが著しく低下する可能性がある。本第２の方法によれば、これを防ぐ、あるいは緩和することができる。

（Ｃ）第３の方法
アプリケーション構成テーブル４５２０を参照し、対象とするアプリケーション５１１１，５１２２，５１３４の対象とするバージョンの中から、インスタンスの一覧を取得する。これらすべてを、事前対策を実施するインスタンスとして選定する。また該当アプリケーションの該当バージョンのインスタンスを新たにＩＴインフラストラクチャ５０００上にデプロイし、これを事前対策を実施しないインスタントして選定する。

続くステップＳ２１にて、管理プログラム４４２０は、事前対策を実施する対象として選定したインスタンスに対して、性能劣化が実際に起こらないようにするための事前対策を実施する。本実施形態においては、事前対策の方法としてインスタンスのスケールアウトを行うものとするが、これに限らず他の方法で対策を行っても良い。スケールアウトするインスタンスの数（ｎ）を決める方法には、例えば予兆が検知された時刻のアプリケーション稼働データテーブル４５３０（図６）におけるメトリック名が「Response Time」の対応するデータ値欄４５３７に格納されていたデータ値（ｒ１）と、予兆の出ていなかった時刻の当該データ値欄４５３７に格納されていたデータ値の平均値（ｒ２）とを比較し、次式
によりインスタンス数ｎを決定する方法がある。ただし、これに限らず他の方法でインスタンス数ｎを決定しても良い。

ステップＳ２２にて、管理プログラム４４２０は、対象とするアプリケーション５１１１，５１２２，５１３４に対応するロードバランサの負荷分散設定を変更する。本実施形態では、例えば以下の第１又は第２の方法で負荷分散設定を変更する。

（Ａ）第１の方法
ステップＳ２０で事前対策を実施しない対象として選定したインスタンスをグループ１とする。ステップＳ２０で事前対策を実施する対象として選定したインスタンスについて、各インスタンスと、ステップＳ２１でスケールアウトによって追加されたインスタンスとを１つのグループとする。例えば図８の「アプリＡ」、バージョン「1.0」において、「インスタンス２」及び「インスタンス３」が事前対策を実施する対象、「インスタンス１」が事前対策を実施しない対象と選定された場合を例として説明する。ステップＳ２１で「インスタンス２」及び「インスタンス３」をスケールアウトし、それぞれインスタンス数を２ずつ増やすという対策が行われたとする。ここではスケールアウトにより追加されたインスタンスを「インスタンス２’」、「インスタンス２’’」及び「インスタンス３’」、「インスタンス３’’」と表記する。このとき、これら合計７つのインスタンスは以下のようにグルーピングされる。
グループ１=［インスタンス１］
グループ２=［インスタンス２、インスタンス２’、インスタンス２’’］
グループ３=［インスタンス３、インスタンス３’、インスタンス３’’］

「アプリＡ」のバージョン「1.0」に対する負荷を、各グループで均等に振り分けた上で、グループごとに、当該グループに振り分けられた負荷を当該グループ内の各インスタンスに均等に振り分けるように負荷バランスを設定する。前述の例においては、各グループの負荷は１／３ずつとなる。グループ１にはインスタンス１のみが含まれるため、インスタンス１の負荷は１／３となる。グループ２、３にはインスタンスが３つずつ含まれるため、「インスタンス２」、「インスタンス２’」、「インスタンス２’’」、「インスタンス３」、「インスタンス３’」、「インスタンス３’’」の負荷はそれぞれ１／９となる。

（Ｂ）第２の方法
ステップＳ２０で事前対策を実施しない対象として選定したインスタンスをグループ１とする。ステップＳ２０で事前対策を実施する対象として選定したインスタンスと、ステップＳ２１でスケールアウトによって追加されたインスタンスを合わせたリストを作成する。このリストに含まれるインスタンスを、ｉ（ｉは２以上の正数）番目のグループに含まれるインスタンス数がｉ個になるようにグループ分けする。なお、ｉ番目のグループに含まれるインスタンス数が（ｉ−１）番目のグループに含まれるインスタンス数より少ない場合には、ｉ番目のグループを削除し、ｉ番目のグループに含まれるインスタンスを（ｉ−１）番目のグループに含める。例えば図８の「アプリＡ」、バージョン「1.0」において、「インスタンス２」、「インスタンス３」が事前対策を実施する対象、「インスタンス１」が事前対策を実施しない対象と選定された場合を例として説明する。ステップＳ２１で「インスタンス２」、「インスタンス３」をスケールアウトし、それぞれインスタンス数を２ずつ増やすという対策が行われたとする。ここではスケールアウトにより追加されたインスタンスを「インスタンス２’」、「インスタンス２’’」及び「インスタンス３’」、「インスタンス３’’」と表記する。このとき、これら合計７つのインスタンスは下記のようにグルーピングされる。
グループ１=［インスタンス１］
グループ２＝［インスタンス２、インスタンス２’］
グループ３＝［インスタンス２’’、インスタンス３、インスタンス３’、インスタンス３’’］

「アプリＡ」のバージョン「1.0」に対する負荷を、各グループで均等に分けた上で、各グループの負荷をグループ内の各インスタンスで均等になるように負荷バランスを設定する。前述の例においては、各グループの負荷は１／３ずつとなる。グループ１には「インスタンス１」のみが含まれるため、「インスタンス１」の負荷は１／３となる。グループ２には「インスタンス」が２つ含まれるため、「インスタンス２」及び「インスタンス２’」の負荷は１／６ずつとなる。グループ３にはインスタンスが４つ含まれるため、「インスタンス２’’」、「インスタンス３」、「インスタンス３’」、「インスタンス３’’」の負荷は１／１２ずつとなる。

管理プログラム４４２０は、負荷分散設定テーブル４５５０（図８）に格納されている負荷バランスの情報を、これら第１又は第２の方法で決定した各インスタンスの負荷バランスの情報で上書きする。ロードバランサは上書きされた負荷バランス情報を参照し、これに基づいて負荷分散を行う。なお、ロードバランサが負荷バランスの設定を変更する機能を有していない場合には、管理プログラム４４２０が新たにロードバランサをＩＴインフラストラクチャ５０００上にデプロイすることで、各インスタンスの負荷が上述のように算出した負荷バランスになるように調整しても良い。例えば、上述の第１の方法で説明した例では、元のロードバランサに加えて、「グループ２」を担当するサブロードバランサ１と、「グループ３」を担当するサブロードバランサ２を新たにデプロイする。元のロードバランサは「インスタンス１」と、サブロードバランサ１と、サブロードバランサ２に対して均等に負荷分散を行う。サブロードバランサ１は「インスタンス２」、「インスタンス２’」、「インスタンス２’’」に対して均等に負荷分散を行う。サブロードバランサ２は「インスタンス３」、「インスタンス３’」、「インスタンス３’’」に対して均等に負荷分散を行う。この結果、「インスタンス１」には全体負荷の１／３が、「インスタンス２」、「インスタンス２’」、「インスタンス２’’」、「インスタンス３」、「インスタンス３’」及び「インスタンス３’’」にはそれぞれ全体負荷の１／９ずつが割り当てられることになり、上述の方法で元のロードバランサの負荷バランスの設定を変更する場合と同じ効果が得られる。

ステップＳ２３にて、管理プログラム４４２０は、予兆検証プログラム４４４０を呼び出す。そして予兆検証プログラム４４４０による図１５について後述する予兆検証処理が終了すると、本事前対策処理が終了する。

なお以上のステップＳ１〜ステップＳ６の処理は、コンピュートサーバ５１００に実装されたアプリケーション５１１１，５１２２，５１３４のうちの必要なアプリケーション５１１１，５１２２，５１３４ごとに実行される。

（１−３−４）予兆検証処理
図１５は、予兆検知プログラム４４３０が検知した予兆の正しさを、予兆検証プログラム４４４０が検証する予兆検証処理の処理手順を示す。

本実施形態において、本予兆検証処理は、事前対策処理（図１４）のステップＳ２３にて管理プログラム４４２０により予兆検証プログラム４４４０が呼び出されることによって開始されるものとするが、これに限らず他の方法で開始されても良い。

まず予兆検証プログラム４４４０は、ステップＳ３０にて、性能劣化の予兆が検知されたアプリケーション５１１１，５１２２，５１３４の全インスタンスの稼働データを予め定められた期間、監視する。

続くステップＳ３１にて、予兆検証プログラム４４４０は、管理プログラム４４２０によって事前対策処理（図１４）のステップＳ２０で事前対策を実施しないインスタンスとして選定されたインスタンスについて、性能劣化が発生したか否かを判定する。この場合の判定手法としては、予兆検知処理（図１３）のステップＳ１１〜ステップＳ１３について上述した方法と同様にして、事前対策を実施しないインスタンスとして選定されたインスタンスの稼働データ（最新の稼働データ又は稼働データの平均値）が外れ値となるか否かに基づいて判定する手法や、事前対策を実施したインスタンスの稼働データと、事前対策を実施していないインスタンスの稼働データとの比較結果に基づいて判定する手法を適用することができる。例えば、後者の手法を適用する場合、事前対策を実施した各インスタンスの稼働データの平均値と、事前対策を実施していないインスタンスの稼働データとが一致しなかった場合に性能劣化が発生したと判定する。

ステップＳ３１の判定結果が肯定的である場合、処理はステップＳ３４に進む。またステップＳ３１の判定結果が否定的である場合、処理はステップＳ３２に進む。この判定結果が肯定的であるということは、予兆を検知したにも関わらず事前対策を実施しなかったインスタンスにおいて実際に性能劣化が起こったことを意味する。従って、この場合、検知された予兆は正しかったと検証できる。一方、この判定結果が否定的であるということは、予兆を検知したにも関わらず事前対策を実施しなかったインスタンスにおいて実際には性能劣化が起こらなかったことを意味する。従って、この場合、検知された予兆は誤りであったと検証できる。

ステップＳ３２にて、予兆検証プログラム４４４０は、予兆検知処理（図１３）のステップＳ１３で外れ値として検出された稼働データを、性能劣化の予兆に含めないように（正確には、最近傍の稼働データクラスタに含めるように）アプリケーション稼働データクラスタテーブル４５４０に登録されている予兆検知モデルのデータ（クラスタ中心、標準偏差等）を修正する。このように誤った予兆検知の原因となった外れ値を最近傍クラスタに含めることで、この外れ値と同様の値が将来的に発生した場合に、これを外れ値として検出しなくなり、この結果、誤った予兆検知を行わないようにできる。

ステップＳ３３にて、予兆検証プログラム４４４０は、管理プログラム４４２０が事前対策処理（図１４）のステップＳ２１で行った事前対策と、ステップＳ２２で行った負荷分散方法の変更を元に戻す。本実施形態においては、ステップＳ２１で行う事前対策は、インスタンスのスケールアウトであるため、ここではスケールアウトによって増やされたインスタンスの数を元の数に縮小する。これにより、誤った予兆検知によって行われた事前対策を取り消すことができ、不要なコストが発生し続けることを回避することができる。

ステップＳ３４にて、予兆検証プログラム４４４０は、アプリケーション稼働データテーブル４５３０（図６）を参照し、予兆検知処理（図１３）のステップＳ１２で外れ値として検出された稼働データにおいて、最近傍クラスタからの距離が最も離れていたメトリックが外的要因か否かを判定する。判定結果が肯定的である場合、処理はステップＳ３６に進む。判定結果が否定的である場合、処理はステップＳ３５に進む。この判定結果が肯定的であるということは、性能劣化の予兆は外的要因によって発生しており、アプリケーション自体の実装上の問題とは言えないことを意味する。一方、この判定結果が否定的であるということは、性能劣化の予兆は内的要因によって発生しており、アプリケーション自体の実装上の問題である可能性があることを意味する。

ステップＳ３５にて、予兆検証プログラム４４４０は、対応するアプリケーション５１１１，５１２２，５１３４の性能劣化の問題をアプリケーション問題管理プログラム４４５０に通知する。例えば図９では、インスタンス数が「３」であり、かつ「Queue Depth=120」、「Request Per Second=1300」、「Input Data Average Size=150」という条件の下、「アプリＡ」のバージョン「1.0」において「Response Time」が「50」以上になったという問題が登録されている。図７に示されたクラスタ情報の例では、この外れ値の最近傍クラスタは「クラスタ１」であるが、そのクラスタ中心からの距離では「Queue Depth」の距離が標準偏差（=「20」）の３倍程度、離れていることがわかる。図６のアプリケーション稼働データテーブル４５３０において、「Queue Depth」は外的要因フラグ欄４５３５に格納された外的要因フラグの値が「０」となっており、これは外的要因でないことを意味している。従って、予兆検証プログラム４４４０は、この性能劣化の予兆がアプリケーションの実装上の問題により発生した可能性があるとして、この問題をアプリケーション問題管理プログラム４４５０に通知する。かくしてアプリケーション問題管理プログラム４４５０は、予兆検証プログラム４４４０から通知されたかかる問題をアプリケーション問題管理テーブル４５６０に登録して管理する。

ステップＳ３６にて、予兆検証プログラム４４４０は、管理プログラム４４２０によって事前対策処理（図１４）のステップＳ２０で事前対策を実施するインスタンスとして選定されたインスタンスについて、性能劣化が発生したか否かを判定する。判定結果が肯定的である場合、処理はステップＳ３７に進む。判定結果が否定的である場合、本予兆検証処理が終了する。この判定結果が肯定的であるということは、管理プログラム４４２０が事前対策処理（図１４）のステップＳ２１で行った事前対策が十分に効果的でなかったことを意味する。

ステップＳ３７にて、予兆検証プログラム４４４０は、検出された予兆と、当該予兆に対して管理プログラム４４２０が実行した事前対策の内容と、当該事前対策を実行した結果（効果）とを対策効果テーブル４５７０（図１０）に記録する。管理プログラム４４２０が事前対策処理（図１４）のステップＳ２１において、事前対策を実行する際に対策効果テーブル４５７０を参照し、前回実施した事前対策で良い効果を得られなかった場合（効果が「ＯＫ」でなかった場合）には、事前対策の方法を変更するようにしても良い。

この後、予兆検証プログラム４４４０は、本予兆検証処理を終了する。

（１−４）本実施の形態の効果
以上のように本実施形態の計算機システム１０００では、管理サーバ４０００が、アプリケーション５１１１，５１２２，５１３４の稼働データを定期的に収集し、収集した稼働データのうちの予め設定された条件を満たす稼働データをクラスタリングすることによりアプリケーション５１１１，５１２２，５１３４の性能劣化を検知するための予兆検知モデルを生成する。

また管理サーバ４０００は、生成した予兆検知モデルと、アプリケーション５１１１，５１２２，５１３４の最新の稼働データとに基づいて当該アプリケーション５１１１，５１２２，５１３４の性能劣化の予兆の有無を判定し、かかる予兆を検知した場合には、そのアプリケーション５１１１，５１２２，５１３４のインスタンスの中から性能劣化を防止するための所定の事前対策（インスタンスのスケールアウト）を実施するインスタンスと、当該事前対策を実施しないインスタンスとを選択して、前者のインスタンスに事前対策を実施する。

また管理サーバ４０００は、その後、事前対策を実施しなかったインスタンスの稼働データを所定期間監視し、当該稼働データに基づいてそのインスタンスの性能劣化を検出しなかった場合、つまり予兆が正しくないと判断した場合には、かかる予兆を検出したときの稼働データを予兆検知モデルに含めないように予兆検知モデルを修正する。

従って、本実施形態の管理サーバ４０００によれば、予兆検知の正否を検証しながら予兆検知モデルの精度を向上させることができるため、精度の高い予兆検知を行うことができる。

また管理サーバ４０００は、かかる事前対策を実施しなかったインスタンスの稼働データに基づいてそのインスタンスの性能劣化を検出した場合、つまり予兆が正しいと判断した場合には、アプリケーション性能を変化させる外的要因によって予兆が検知されたか否かを判定し、外的要因によって予兆が出ていない場合には、アプリケーション問題管理テーブル４５６０にその現象及び条件等をアプリケーション５１１１，５１２２，５１３４の実装上の問題として登録する。

従って、本実施形態の管理サーバ４０００によれば、例えば、アプリケーション問題管理テーブル４５６０に登録された問題（アプリケーションの実装上の問題）の内容をユーザからの要求に応じて管理サーバ４０００，４０００Ｂ等に表示させ得るようにすることによって、通常は気付きにくいアプリケーションの実装上の問題をユーザに認識させることができ、結果としてアプリケーション５１１１，５１２２，５１３４の品質の向上を期待することができる。

（２）第２の実施形態
次に、本発明の第２の実施形態について説明する。

図１６は、第１の実施形態の管理サーバ４０００に代えて図１の計算機システム１に適用される第２の実施形態の管理サーバ４０００Ｂの構成例を示す。本実施形態の管理サーバ４０００Ｂと、第１の実施形態の管理サーバ４０００との差異は以下の（Ａ）〜（Ｅ）である。
（Ａ）本実施形態のアプリケーション稼働データクラスタテーブル４５４０Ｂの構成が、第１の実施形態のアプリケーション稼働データクラスタテーブル４５４０（図７）の構成と異なる点
（Ｂ）管理プログラム４４２０Ｂにより実行されるアプリケーション監視処理が、図１２について上述した第１の実施形態の管理プログラム４４２０により実行されるアプリケーション監視処理と異なる点
（Ｃ）本実施形態の予兆検知プログラム４４３０Ｂにより実行される予兆検知処理が、図１３について上述した第１の実施形態の予兆検知プログラム４４３０により実行される予兆検知処理フローと異なる点
（Ｄ）本実施形態の予兆検証プログラム４４４０Ｂにより実行される予兆検証処理が、図１５について上述した第１の実施形態の予兆検証プログラム４４４０により実行される予兆検証処理と異なる点
（Ｅ）管理プログラム４４２０Ｂが、図１８について後述する初期アプリケーション稼働データクラスタ決定処理を実行する機能を有している点
これらの差異点以外は第１の実施形態と同様の構成及び処理であるため説明は省略する。

図１７は、本実施形態によるアプリケーション稼働データクラスタテーブル４５４０Ｂの構成例を示す。アプリケーション稼働データクラスタテーブル４５４０Ｂと、第１の実施形態におけるアプリケーション稼働データクラスタテーブル４５４０との差異は、アプリケーション稼働データクラスタテーブル４５４０Ｂがリビジョン欄４５４８を備える点である。そしてリビジョン欄４５４８には、アプリケーション稼働データクラスタのリビジョンを示す情報が格納される。なお、アプリケーション稼働データクラスタのリビジョンは、図２０について後述する本実施形態の予兆検証処理のステップＳ３２Ｂにおいて増加される。詳細については後述する。また、本実施形態においては「リビジョン」という言葉は「バージョン」と同義であり、アプリケーション稼働データクラスタのリビジョンをバージョンと言い換えても良い。本実施例では、アプリケーションのバージョンとの混同を避けるため、アプリケーション稼働データクラスタに対しては「リビジョン」という言葉を用いる。

この差異点以外は、アプリケーション稼働データクラスタテーブル４５４０Ｂとアプリケーション稼働データクラスタテーブル４５４０とは同様であるため、アプリケーション稼働データクラスタテーブル４５４０Ｂの他の欄の説明は省略する。

図１２との対応部分に同一符号を付して示す図１８は、図１２のアプリケーション監視処理に代えて管理プログラム４４２０Ｂにより実行される本実施形態のアプリケーション監視処理の処理手順を示す。第１の実施形態の管理プログラム４４２０により実行されるアプリケーション監視処理（図１２）との差異は、ステップＳ５Ｂの処理内容がステップＳ５の処理内容と異なる点である。本実施形態のアプリケーション監視処理は、この点以外は第１の実施形態のアプリケーション監視処理と同様のため、ステップＳ５Ｂ以外の説明は省略する。

管理プログラム４４２０Ｂは、ステップＳ５Ｂにて、アプリケーションの稼働データをクラスタリングし、各クラスタの情報（すなわち予兆検知モデルの情報であり、以下、これをクラスタ情報とも呼ぶ）をアプリケーション稼働データクラスタテーブル４５４０Ｂの最新のリビジョンに対応するクラスタＩＤ欄４５４５、クラスタ中心欄４５４６及び標準偏差欄４５４７に格納する。例えば図１７の例では、「アプリＡ」のバージョン「1.0」には「リビジョン１」と「リビジョン２」の２つのクラスタ情報が格納されている。この場合、管理プログラム４４２０Ｂは最新のリビジョンである「リビジョン２」に、ステップＳ５Ｂで生成したクラスタの情報を格納する。このとき、古いリビジョンである「リビジョン１」のクラスタ情報は、変更や上書き等されずにそのまま残される。

図１３との対応部分に同一符号を付して示す図１９は、図１３の予兆検知処理に代えて予兆検知プログラム４４３０Ｂにより実行される本実施形態の予兆検知処理の処理手順を示す。第１の実施形態の予兆検知プログラム４４３０により実行される予兆検知処理（図１３）との差異は、ステップＳ１１Ｂの処理内容がステップＳ１１の処理内容と異なる点である。本実施形態の予兆検知処理は、この点以外は第１の実施形態の予兆検知処理と同様のため、ステップＳ１１Ｂ以外の説明は省略する。

ステップＳ１１Ｂにて、予兆検知プログラム４４３０Ｂは、アプリケーション稼働データクラスタテーブル４５４０Ｂを参照し、該当アプリの稼働データクラスタの最新のリビジョンの情報を取得する。

図１５との対応部分に同一符号を付して示す図２０は、図１５の予兆検証処理に代えて予兆検証プログラム４４４０Ｂにより実行される本実施形態の予兆検証処理の処理手順を示す。第１の実施形態の予兆検証プログラム４４４０により実行される予兆検証処理（図１５）との差異は、ステップＳ３２Ｂの処理内容がステップＳ３２の処理内容と異なる点である。本実施形態の予兆検証処理は、この点以外は第１の実施形態の予兆検証処理と同様のため、ステップＳ３２Ｂ以外の説明は省略する。

予兆検証プログラム４４４０Ｂは、ステップＳ３２Ｂにて、アプリケーション稼働データクラスタテーブル４５４０Ｂを参照し、該当アプリケーションの稼働データクラスタの最新のリビジョンの情報をコピーし、リビジョンを１つ上げる。これを新たな最新リビジョンとし、そのクラスタ情報にて、図１９の予兆検知処理のステップＳ１２で外れ値として検出された稼働データを、最近傍の稼働データクラスタに含めるように修正する。

例えば図１７の例では、「アプリＡ」のバージョン「1.0」には「リビジョン１」と「リビジョン２」の２つのクラスタ情報が格納されている。この場合、予兆検証プログラム４４４０Ｂは、最新のリビジョンであるリビジョン２のクラスタ情報をコピーし、「リビジョン３」としてアプリケーション稼働データクラスタテーブル４５４０Ｂに格納する。そして新たな最新リビジョンである「リビジョン３」のクラスタ情報において、ステップＳ１２で外れ値として検出された稼働データを、最近傍の稼働データクラスタに含めるように修正する。このとき、「リビジョン１」や「リビジョン２」のクラスタ情報は、変更や上書き等されずにそのまま残される。

図２１は、本実施形態の管理プログラム４４２０Ｂがアプリケーションの新しいバージョンがデプロイされた際に、その初期アプリケーション稼働データクラスタ（初期予兆検知モデル）を決定する処理（以下、これを初期アプリケーション稼働データクラスタ決定処理と呼ぶ）の処理手順を示す。

本実施形態において、本初期アプリケーション稼働データクラスタ決定処理は、管理プログラム４４２０Ｂが計算機システムのユーザからアプリケーションの新しいバージョンをデプロイする要求を受けた際に開始されるものとするが、これに限らず他の方法で開始されても良い。

管理プログラム４４２０Ｂは、まずステップＳ４０にて、アプリケーションの新バージョンをＩＴインフラストラクチャ５０００上にデプロイする。このとき、すでにデプロイされて稼働している旧バージョンのアプリケーションもそのまま残す。そして、旧バージョンのアプリケーションに対するユーザリクエストの一部又は全部が新旧両方のアプリケーションに到達するように、ルータやロードバランサを用いて制御する。新旧アプリケーションを併用した運用が一定期間過ぎた後、ユーザの要求に応じて旧バージョンのアプリケーションを削除し、新バージョンのアプリケーションのみでユーザリクエストを処理するように変更しても良い。また、例えば新バージョンのアプリケーションにおいて不具合があることが判明した場合には、ユーザの要求に応じて新バージョンのアプリケーションを削除し、旧バージョンのアプリケーションのみでユーザリクエストを処理するように変更しても良い。

続くステップＳ４１にて、管理プログラム４４２０Ｂは、新バージョンのアプリケーションに対する図１８について上述したアプリケーション監視処理を開始する。このとき、新バージョンのアプリケーションにおいては、アプリケーション稼働データクラスタテーブル４５４０Ｂ（図１７）にレコードがまだ存在しないため、ステップＳ２（図１８）で各メトリクス空間の条件が取得できない。この結果、図１８のアプリケーション監視処理のステップＳ４の判定は常に否定的となる。

ステップＳ４２にて、管理プログラム４４２０Ｂは、アプリケーション稼働データテーブル４５３０を参照し、新旧アプリの最新の稼働データを取得する。

ステップＳ４３にて、管理プログラム４４２０Ｂは、アプリケーション稼働データクラスタテーブル４５４０Ｂから、旧バージョンのアプリケーションの全てのリビジョンのクラスタ情報（予兆検知モデル）を取得する。

そして管理プログラム４４２０Ｂは、取得したこれら旧バージョンのアプリケーションの全てのリビジョンのクラスタ情報を用いて、ステップＳ４４及びステップＳ４５において、旧バージョンの前記アプリケーションの前記サービスレベルの低下の予兆の判定と、新バージョンの前記アプリケーションの前記サービスレベルの低下の予兆の判定とをそれぞれ行う。

実際上、管理プログラム４４２０Ｂは、ステップＳ４４にて、新旧両バージョンのアプリケーションに対して、旧バージョンのアプリケーションの全てのリビジョンのクラスタ情報を用いて、最新の稼働データと稼働データクラスタを比較し、最近傍クラスタの中心からの距離Ｌを算出する。

また管理プログラム４４２０Ｂは、ステップＳ４５にて、新旧両バージョンのアプリケーションに対して、各リビジョンのクラスタについて、距離Ｌが標準偏差σのＮ倍より大きいか否か（つまり「外れ値」であるか否か）を判定する。

続くステップＳ４６にて、管理プログラム４４２０Ｂは、新旧両バージョンのアプリケーションにおける判定結果を比較し、判定結果が一致したリビジョンのうちの最新のリビジョンを特定する。例えば図２２に示すような判定結果が得られたとする。この図２２では、リビジョンが「１」〜「３」の３つのクラスタ情報（予兆検知モデルの情報）がアプリケーション稼働データクラスタテーブル４５４０Ｂに登録されており、アプリケーション５１１１，５１２２，５１３４の「バージョン１」が旧バージョン、「バージョン２」が新バージョンを表している。また図２２において、「True」は距離Ｌが標準偏差σのＮ倍より大きい（つまり「外れ値」である）ことを意味し、「False」は距離Ｌが標準偏差σのＮ倍以下であることを意味する。この結果、新旧両バージョンのアプリケーション５１１１，５１２２，５１３４における判定結果において、判定結果が一致した最新のリビジョンは「リビジョン２」と特定される。

ステップＳ４７にて、管理プログラム４４２０Ｂは、該当リビジョンのクラスタ情報（予兆検知モデル）を、新バージョンのアプリケーション５１１１，５１２２，５１３４の初期クラスタ情報（初期の予兆検知モデル）としてアプリケーション稼働データクラスタテーブル４５４０Ｂ（図１７）に登録する。上述の例では、新バージョンのアプリケーション５１１１，５１２２，５１３４の初期クラスタ情報は、旧バージョンのアプリケーション５１１１，５１２２，５１３４のクラスタ情報の「リビジョン２」がコピーされたものとなる。

以上のように本実施形態の管理サーバ４０００Ｂでは、アプリケーション５１１１，５１２２，５１３４のリビジョンごとの予兆検知モデルを管理しておき、新しいバージョンのアプリケーション５１１１，５１２２，５１３４がデプロイされた際に、新旧両バージョンのアプリケーション５１１１，５１２２，５１３４に対して、旧バージョンのアプリケーション５１１１，５１２２，５１３４の全てのリビジョンの予兆検知モデルを用いてそれぞれ予兆検知を行い、結果が一致したリビジョンの予兆検知モデルのうちの最新の予兆検知モデルを新バージョンのアプリケーション５１１１，５１２２，５１３４の初期予兆検知モデルとして採用する。

従って、本実施形態の管理サーバ４０００Ｂによれば、アプリケーション５１１１，５１２２，５１３４がバージョンアップした際に、新しいバージョンのアプリケーション５１１１，５１２２，５１３４にとって好適なアプリケーション稼働データクラスタ（予兆検知モデル）を、旧バージョンのアプリケーション５１１１，５１２２，５１３４から引き継ぐことができる。かくするにつき、本実施形態によれば、アプリケーション５１１１，５１２２，５１３４がバージョンアップした場合においても、精度の高い予兆検知を行うことができる。

（３）他の実施形態
なお上述の第１及び第２の実施形態においては、予兆検証処理（図１５、図２０）のステップＳ３１において、事前対策を実施しないインスタンスとして選択されたインスタンスについて性能劣化が発生したか否かを判定する判定手法として、予兆検知処理（図１３）のステップＳ１１〜ステップＳ１３について上述した方法と同様に判定する手法や、事前対策を実施したインスタンスの稼働データと、事前対策を実施していないインスタンスの稼働データとの比較結果に基づいて判定する手法を適用する場合について述べたが、本発明はこれに限らず、この他種々の手法を広く適用することができる。

また上述の第１の実施形態においては、アプリケーションの稼働データを収集する稼働データ収集部と、サービスレベルに関して予め設定された条件を満たす稼働データをクラスタリングすることにより、稼働データのデータ値と、サービスレベルとの相関を表す相関モデルを生成する相関モデル生成部と、アプリケーションのサービスレベルの低下の予兆が検知された場合に、アプリケーションのインスタンスの中から、当該サービスレベルの低下を防止するための所定の事前対策を実施しない第１のインスタンスと、当該事前対策を実施する第２のインスタンスとをそれぞれ選択し、第２のインスタンスに事前対策を実施する事前対策部とを同じ１つの管理プログラム４４２０により構成し、上述の第２の実施形態においては、かかる稼働データ収集部、相関モデル生成部及び事前対策部に加えて、前記予兆検証部により修正された前記相関モデルのリビジョンごとの情報をそれぞれ管理する相関モデル管理部とを同じ１つの管理プログラム４４２０Ｂにより構成するようにした場合について述べたが、本発明はこれに限らず、管理プログラム４４２０，４４２０Ｂを、かかる稼働データ収集部、相関モデル生成部、事前対策部及び相関モデル管理部の機能をそれぞれ有する複数のプログラムに分割して形成するようにしても良い。

本発明は、アプリケーションのサービスレベルの低下の予兆を検知する予兆検知装置に適用して好適なものである。

１０００……計算機システム、２０００，３０００……クラウド、４０００，４０００Ｂ……管理サーバ、５０００……ＩＴインフラストラクチャ、５１００，５１００Ａ〜５１００Ｃ……コンピュートサーバ、５１１，５１２２，５１３４……アプリケーション、４４１０……セルフサービスポータルプログラム、４４２０，４４２０Ｂ……管理プログラム、４４３０，４４３０Ｂ……予兆検知プログラム、４４４０，４４４０Ｂ……予兆検証プログラム、４４５０……アプリケーション問題管理プログラム、４５１０……ＩＴインフラストラクチャ構成テーブル、４５２０……アプリケーション構成テーブル、４５３０……アプリケーション稼働データテーブル、４５４０，４５４０Ｂ……アプリケーション稼働データクラスタテーブル、４５５０……負荷分散設定テーブル、４５６０……アプリケーション問題管理テーブル、４５７０……対策効果テーブル、４４１０Ａ……メトリクス空間設定画面。

Claims (10)

1. アプリケーションのサービスレベルの低下の予兆を検知する予兆検知装置において、
   前記アプリケーションの稼働データを収集する稼働データ収集部と、
   前記稼働データのデータ値と、前記サービスレベルとの相関を表す相関モデルを生成する相関モデル生成部と、
   前記アプリケーションの最新の前記稼働データのデータ値と、前記相関モデルとに基づいて、前記アプリケーションの前記サービスレベルの低下の予兆を検知する予兆検知部と、
   前記予兆検知部により前記アプリケーションの前記サービスレベルの低下の予兆が検知された場合に、前記アプリケーションのインスタンスの中から、当該サービスレベルの低下を防止するための所定の事前対策を実施しない第１のインスタンスと、当該事前対策を実施する第２のインスタンスとをそれぞれ選択し、前記第２のインスタンスに前記事前対策を実施する事前対策部と、
   前記アプリケーションの前記事前対策を実施しなかった前記第１のインスタンスの稼働データを監視し、当該稼働データに基づいて前記サービスレベルの低下を検知しなかった場合に、前記予兆検知部により検知された前記予兆を、前記サービスレベルの低下の予兆に含めないように前記相関モデルを修正する予兆検証部と
   を備えることを特徴とする予兆検知装置。
2. 前記予兆検証部は、
   前記アプリケーションの前記事前対策を実施しなかった前記第１のインスタンスの稼働データに基づいて前記サービスレベルの低下を検知した場合であって、当該サービスレベルの低下が外的要因によって発生したものでない場合には、当該アプリケーションの問題として記録する
   ことを特徴とする請求項１に記載の予兆検知装置。
3. 前記事前対策部は、
   同一のリージョンで稼働する前記インスタンスが複数ある場合には、当該インスタンスのうちの１つを前記第１のインスタンスとして選択し、当該リージョンで稼働する他の前記インスタンス及び他のリージョンで稼働する各前記インスタンスをすべて前記第２のインスタンスとして選択する
   ことを特徴とする請求項１に記載の予兆検知装置。
4. 前記事前対策部は、
   前記アプリケーションの新たな前記インスタンスをサーバにデプロイし、当該インスタンスを前記第１のインスタンスとして選択し、当該デプロイ前に前記サーバ上で稼働していた前記アプリケーションのすべての前記インスタンスを前記第２のインスタンスとして選択する
   ことを特徴とする請求項１に記載の予兆検知装置。
5. 前記事前対策は、前記アプリケーションのインスタンスのスケールアウトであり、
   前記事前対策部は、前記事前対策を実施する際、
   前記第１のインスタンスを１つのグループとすると共に、前記第２のインスタンスごとに、それぞれ前記第２のインスタンスと、前記事前対策により追加されたインスタンスとを１つのグループとし、
   前記アプリケーションに対する負荷を各前記グループに均等に振り分け、
   前記グループごとに、当該グループに振り分けられた負荷を当該グループ内の各インスタンスに均等に振り分けるように負荷バランスを設定する
   ことを特徴とする請求項１に記載の予兆検知装置。
6. 前記事前対策は、前記アプリケーションのインスタンスのスケールアウトであり、
   前記事前対策部は、前記事前対策を実施する際、
   前記第１のインスタンスを１つのグループとすると共に、各前記第２のインスタンス及び前記事前対策により追加されたすべてのインスタンスを、ｉ（ｉは２以上の正数）番目のグループに含まれるインスタンス数がｉ個となるように、かつｉ番目のグループに含まれるインスタンス数が（ｉ−１）番目のグループに含まれるインスタンス数より少ない場合には、ｉ番目のグループを削除し、ｉ番目のグループに含まれるインスタンスを（ｉ−１）番目のグループに含めるようにグループ分けし、
   前記アプリケーションに対する負荷を各前記グループに均等に振り分け、
   前記グループごとに、当該グループに振り分けられた負荷を当該グループ内の各インスタンスに均等に振り分けるように負荷バランスを設定する
   ことを特徴とする請求項１に記載の予兆検知装置。
7. 前記予兆検証部は、
   前記第１のインスタンスの稼働データに基づいて前記サービスレベルの低下を検知しなかった場合には、前記予兆検知部により検知された前記予兆に基づいて実施した前記事前対策を取り消す処理を実行する
   ことを特徴とする請求項１に記載の予兆検知装置。
8. 前記予兆検証部は、
   前記アプリケーションの前記事前対策を実施しなかった前記第１のインスタンスの稼働データに加えて、前記アプリケーションの前記事前対策を実施した前記第２のインスタンスの稼働データをも監視し、
   前記第２のインスタンスの前記サービスレベルの低下が発生した場合には、前記予兆検知部が検知した前記予兆と、当該予兆に対して前記事前対策部が実行した前記事前対策と、当該事前対策を実施した結果とを記録し、
   前記事前対策部は、
   前記記録を参照して、必要に応じて前記事前対策の方法を変更する
   ことを特徴とする請求項１に記載の予兆検知装置。
9. 前記予兆検証部により修正された前記相関モデルのリビジョンごとの情報をそれぞれ管理する相関モデル管理部を備え、
   前記相関モデル管理部は、
   新バージョンの前記アプリケーションがデプロイされた場合に、新旧両バージョンの前記アプリケーションに対して、旧バージョンの前記アプリケーションの全てのリビジョンの前記相関モデルを用いて、旧バージョンの前記アプリケーションの前記サービスレベルの低下の予兆の判定と、新バージョンの前記アプリケーションの前記サービスレベルの低下の予兆の判定とをそれぞれ行い、
   新旧両バージョンの前記アプリケーションの前記サービスレベルの低下の予兆の判定が一致した前記リビジョンのうちの最新の前記リビジョンの前記相関モデルを、新バージョンの前記アプリケーションの初期の前記相関モデルとして設定する
   ことを特徴とする請求項１に記載の予兆検知装置。
10. アプリケーションのサービスレベルの低下の予兆を検知する予兆検知装置において実行される予兆検知方法であって、
    前記予兆検知装置は、前記アプリケーションの稼働データを収集し、
    前記予兆検知装置が、前記稼働データのデータ値と、前記サービスレベルとの相関を表す相関モデルを生成する第１のステップと、
    前記予兆検知装置が、前記アプリケーションの最新の前記稼働データのデータ値と、前記相関モデルとに基づいて、前記アプリケーションの前記サービスレベルの低下の予兆を検知する第２のステップと、
    前記予兆検知装置が、前記アプリケーションの前記サービスレベルの低下の予兆を検知した場合に、前記アプリケーションのインスタンスの中から、当該サービスレベルの低下を防止するための所定の事前対策を実施しない第１のインスタンスと、当該事前対策を実施する第２のインスタンスとをそれぞれ選択し、前記第２のインスタンスに前記事前対策を実施する第３のステップと、
    前記予兆検知装置が、前記アプリケーションの前記事前対策を実施しなかった前記第１のインスタンスの稼働データを監視し、当該稼働データに基づいて前記サービスレベルの低下を検知しなかった場合に、第２のステップで検知した前記予兆を、前記サービスレベルの低下の予兆に含めないように前記相関モデルを修正する第４のステップと
    を備えることを特徴とする予兆検知方法。