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

予兆検知装置及び予兆検知方法 Download PDF

Info

Publication number
WO2018163280A1
WO2018163280A1 PCT/JP2017/008986 JP2017008986W WO2018163280A1 WO 2018163280 A1 WO2018163280 A1 WO 2018163280A1 JP 2017008986 W JP2017008986 W JP 2017008986W WO 2018163280 A1 WO2018163280 A1 WO 2018163280A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
instance
sign
operation data
service level
Prior art date
Application number
PCT/JP2017/008986
Other languages
English (en)
French (fr)
Inventor
泰隆 河野
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2017/008986 priority Critical patent/WO2018163280A1/ja
Priority to JP2019504165A priority patent/JP6722345B2/ja
Publication of WO2018163280A1 publication Critical patent/WO2018163280A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the storage device 5300 is a dedicated storage device that provides its own storage device capacity to other servers.
  • the storage apparatus 5300 usually has dedicated hardware different from the hardware used in the compute server 5100 and the storage server 5200, but may be regarded as a kind of the storage server 5200.
  • the storage device 5300 includes a storage device 5310 and a storage controller 5311.
  • the storage controller 5311 is dedicated hardware that provides the same storage function as the storage controller program 5212 on the storage server 5200.
  • the server ID column 4525 stores an identifier (server ID) assigned to the compute server 5100 (FIG. 1) that provides the execution environment of the corresponding instance.
  • the server port ID column 4526 stores an identifier (server port ID) assigned to the network interface of the compute server 5100.
  • the storage port ID column 4527 contains an identifier (storage port) assigned to the network port used by the corresponding instance among the network ports of the network interface of the storage server 5200 (FIG. 2) or the storage apparatus 5300 (FIG. 2). ID) is stored.
  • the sign verification process is started when the sign verification program 4440 is called by the management program 4420 in step S23 of the precaution process (FIG. 14). You may start with a method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】 精度の高い予兆検知を行い得る予兆検知装置及び予兆検知方法を提案する。 【解決手段】 アプリケーションの稼働データを収集し、稼働データのデータ値と、サービスレベルとの相関を表す相関モデルを生成し、アプリケーションの最新の稼働データのデータ値と、相関モデルとに基づいて、アプリケーションのサービスレベルの低下の予兆を検知し、当該予兆を検知した場合に、アプリケーションのインスタンスの中から、所定の事前対策を実施しない第1のインスタンスと、当該事前対策を実施する第2のインスタンスとをそれぞれ選択して第2のインスタンスに事前対策を実施し、第1のインスタンスの稼働データを監視し、当該稼働データに基づいてサービスレベルの低下を検知しなかった場合に、予兆検知部により検知された予兆を、サービスレベルの低下の予兆に含めないように相関モデルを修正するようにした。

Description

予兆検知装置及び予兆検知方法
 本発明は予兆検知装置及び予兆検知方法に関し、アプリケーションのサービスレベル低下の予兆を検知する予兆検知装置に適用して好適なものである。
 アプリケーションやIT(Information Technology)インフラストラクチャの性能劣化や障害などを予兆段階で検知し、これら性能劣化や障害を未然に防ぐ対策を取ることで、サービスレベルの低下を防ぎたいというニーズがある。これに関連する技術として、特許文献1及び2にそれぞれ開示された技術がある。
 特許文献1には、性能種目又は被管理装置を要素とし、少なくとも第1の要素に関する性能情報の時系列変化を示す第1の性能系列情報と、第2の要素に関する性能情報の時系列変化を示す第2の性能系列情報との相関関数を導出し、この相関関数に基づいて相関モデルを生成し、この相関モデルを各要素間の組み合わせについて求める相関モデル生成部と、各要素間の各相関モデルを順次探索して最適な相関モデルを決定し、この決定された相関モデルに基づいて第1の要素の性能情報から第2の要素の性能情報を予測する技術が開示されている。
 また特許文献2には、管理計算機がストレージ装置へのアクセスに関する性能情報をホスト計算機より取得し、取得したアクセスに関する性能が、予め定められた第1の要求性能を満たすか否かを判断し、第1の要求性能が満たされていなければ、仮想論理ボリューム管理情報に基づいて状態の原因である仮想論理ボリュームを特定し、プール管理情報に基づき、各プールに含まれる実領域の容量消費傾向を算出し、特定した仮想論理ボリュームの情報と、算出した容量消費傾向とに基づいて、所定の時間後に実施し得る第1の要求性能が満たされるための対策案を生成する技術が開示されている。
 また、アプリケーションの性能や可用性が低下した場合に、アプリケーションをスケールアウトすることで対策を取る技術が非特許文献1及び2において公開されている。
特開2009-199534号公報 特願2014-545478
"Production-Grade Container Orchestraion"、[online]、kubernetes、[平成29年1月24日検索]、インターネット〈URL: http://kubernetes.io/〉 "Program against your datacenter like it's a single pool of resources"、[online]、Apache MESOS、[平成29年1月24日検索]、インターネット〈http://mesos.apache.org/〉
 特許文献1で開示されているような予兆検知の技術では、予兆検知に必要となる相関モデルを生成するために、ある程度の期間アプリケーションを運用し、性能などの稼働情報を収集する必要がある。従来のアプリケーションの開発・運用手法では、開発やテストに十分に時間を掛けて、比較的長いリリースサイクルでアプリケーションをリリースするため、例えばテスト期間中に上述のような稼働情報を収集し、精度の良い相関モデルを事前に生成しておくことができる。
 一方、近年、アプリケーションの開発・運用手法としてDevOpsと呼ばれるソフトウェアの開発手法が注目されている。DevOpsでは、従来の開発・運用手法と異なり、短期間でアプリケーションの設計、開発、テスト、運用のサイクルを回すことにより、高頻度なアプリケーションのリリースを実現している。このようにアプリケーションのリリースが早い場合、十分に稼働情報を収集することができず、事前に精度の良い相関モデルを生成することができない。従って、このようなアプリケーションにおいて、特許文献1で開示されているような方法で予兆検知を行う場合には、運用が始まった時点では予兆検知の精度が低く、運用の中で精度を向上していく必要がある。
 しかしながら、特許文献1及び2や、非特許文献1及び2の技術を組み合わせて、アプリケーションの性能劣化や障害などを予兆段階で検知し、これら性能劣化や障害を未然に防ぐ対策を取る運用を行った場合、以下の(a)~(c)の問題が生じる。
(a)予兆検知の精度が低いため、予兆が誤っている可能性がある。予兆が正しいことを検証するためには、その後、実際に性能劣化が起こったか否かの結果と、予兆とを比較することで検証できる。しかし予兆に基づいて特許文献2で開示されているような方法で対策を行った場合、この対策によって将来的に発生する可能性のあった性能劣化や障害は発生しなくなる。このため予兆が正しかったか否かの検証ができず、予兆検知の精度を向上できない。
(b)アプリケーションの性能劣化や障害の予兆が、アプリケーションの実装上の問題により発生している可能性がある。しかし、予兆に基づいて事前対策を取った場合、性能劣化や障害が発生しなくなるため、アプリケーションの実装上の問題に気付きにくい。
(c)アプリケーションのバージョンアップによりアプリケーションの振る舞いが変化する。旧バージョンのアプリケーションの運用の中で精度向上した相関モデルが、必ずしも新バージョンのアプリケーションに対する予兆検知に好適であるとは限らない。
 本発明は以上の点を考慮してなされたもので、精度の高い予兆検知を行い得る予兆検知装置及び予兆検知方法を提案しようとするものである。
 かかる課題を解決するため本発明においては、アプリケーションのサービスレベルの低下の予兆を検知する予兆検知装置において、前記アプリケーションの稼働データを収集する稼働データ収集部と、前記稼働データのデータ値と、前記サービスレベルとの相関を表す相関モデルを生成する相関モデル生成部と、前記アプリケーションの最新の前記稼働データのデータ値と、前記相関モデルとに基づいて、前記アプリケーションの前記サービスレベルの低下の予兆を検知する予兆検知部と、前記予兆検知部により前記アプリケーションの前記サービスレベルの低下の予兆が検知された場合に、前記アプリケーションのインスタンスの中から、当該サービスレベルの低下を防止するための所定の事前対策を実施しない第1のインスタンスと、当該事前対策を実施する第2のインスタンスとをそれぞれ選択し、前記第2のインスタンスに前記事前対策を実施する事前対策部と、前記アプリケーションの前記事前対策を実施しなかった前記第1のインスタンスの稼働データを監視し、当該稼働データに基づいて前記サービスレベルの低下を検知しなかった場合に、前記予兆検知部により検知された前記予兆を、前記サービスレベルの低下の予兆に含めないように前記相関モデルを修正する予兆検証部とを設けるようにした。
 また本発明においては、アプリケーションのサービスレベルの低下の予兆を検知する予兆検知装置において実行される予兆検知方法であって、前記予兆検知装置は、前記アプリケーションの稼働データを収集し、前記予兆検知装置が、前記稼働データのデータ値と、前記サービスレベルとの相関を表す相関モデルを生成する第1のステップと、前記予兆検知装置が、前記アプリケーションの最新の前記稼働データのデータ値と、前記相関モデルとに基づいて、前記アプリケーションの前記サービスレベルの低下の予兆を検知する第2のステップと、前記予兆検知装置が、前記アプリケーションの前記サービスレベルの低下の予兆を検知した場合に、前記アプリケーションのインスタンスの中から、当該サービスレベルの低下を防止するための所定の事前対策を実施しない第1のインスタンスと、当該事前対策を実施する第2のインスタンスとをそれぞれ選択し、前記第2のインスタンスに前記事前対策を実施する第3のステップと、前記予兆検知装置が、前記アプリケーションの前記事前対策を実施しなかった前記第1のインスタンスの稼働データを監視し、当該稼働データに基づいて前記サービスレベルの低下を検知しなかった場合に、第2のステップで検知した前記予兆を、前記サービスレベルの低下の予兆に含めないように前記相関モデルを修正する第4のステップとを設けるようにした。
 本発明の予兆検知装置及び予兆検知方法によれば、予兆検知の正否を検証しながら相関モデルの精度を向上させることができる。
 本発明によれば、精度の高い予兆検知を行い得る予兆検知装置及び予兆検知方法を実現できる。
計算機システムの全体構成を示すブロック図である。 ITインフラストラクチャの論理構成の一例を示すブロック図である。 第1の実施形態による管理サーバの構成例を示すブロック図である。 ITインフラストラクチャ構成テーブルの構成例を示す図表である。 アプリケーション構成テーブルの構成例を示す図表である。 アプリケーション稼働データテーブルの構成例を示す図表である。 第1の実施形態によるアプリケーション稼働データクラスタテーブルの構成例を示す図表である。 負荷分散設定テーブルの構成例を示す図表である。 アプリケーション問題管理テーブルの構成例を示す図表である。 対策効果テーブルの構成例を示す図表である。 メトリクス空間設定画面の構成例を示す図である。 第1の実施形態によるアプリケーション監視処理の処理手順の一例を示すフローチャートである。 第1の実施形態による予兆検知処理の処理手順の一例を示すフローチャートである。 事前対策処理の処理手順の一例を示すフローチャートである。 第1の実施形態による予兆検証処理の処理手順の一例を示すフローチャートである。 第2の実施形態による管理サーバの構成例を示すブロック図である。 第2の実施形態によるアプリケーション稼働データクラスタテーブルの構成例を示す図表である。 第2の実施形態によるアプリケーション監視処理の処理手順の一例を示すフローチャートである。 第2の実施形態による予兆検知処理の処理手順の一例を示すフローチャートである。 第2の実施形態による予兆検証処理の処理手順の一例を示すフローチャートである。 初期アプリケーション稼働データクラスタ決定処理の処理手順の一例を示すフローチャートである。 判定結果の一例を示す図表である。
 以下、幾つかの実施形態を、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。なお、以後の説明では「aaaテーブル」等の表現にて本発明の情報を説明するが、これら情報はテーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「aaaテーブル」等について「aaa情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名称」、「ID」という表現を用いるが、これらについてはお互いに置換が可能である。
 以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート(通信デバイス、管理I/F、データI/F)を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。
 以後、計算機システムを管理し、本発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は管理サーバが管理システムである、また、管理サーバと表示用計算機との組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機(表示を表示用計算機が行う場合は表示用計算機も含め)が管理システムである。
(1)第1の実施形態
(1-1)本実施形態による計算機システムの構成
 図1は、本実施形態におけるシステム構成を示す。本実施形態の計算機システム1000は、複数のクラウドから構成される。図1ではクラウド2000及びクラウド3000により計算機システム1000が構成されている例を示している。クラウド2000はリージョン1(例えば米国西海岸)に、クラウド3000はリージョン2(例えば米国東海岸)に設置されている。
 クラウド2000は、管理サーバ4000、ITインフラストラクチャ5000、管理ネットワーク6000及びデータネットワーク7000を備えて構成される。ITインフラストラクチャ5000は、コンピュートサーバ5100、ストレージサーバ5200及びストレージ装置5300を備えて構成され、これらコンピュートサーバ5100、ストレージサーバ5200及びストレージ装置5300が管理サーバ4000と管理ネットワーク6000を介して接続されている。また、ITインフラストラクチャ5000の構成要素(コンピュートサーバ5100、ストレージサーバ5200及びストレージ装置5300)同士は、データネットワーク7000を介して接続されている。
 同様に、クラウド3000も、ITインフラストラクチャ5000、管理ネットワーク6000及びデータネットワーク7000を備えて構成される。ITインフラストラクチャ5000は、コンピュートサーバ5100、ストレージサーバ5200及びストレージ装置5300を備えて構成され、これらコンピュートサーバ5100、ストレージサーバ5200及びストレージ装置5300が管理サーバ4000と管理ネットワーク6000を介して接続されている。またITインフラストラクチャ5000の構成要素(コンピュートサーバ5100、ストレージサーバ5200及びストレージ装置5300)同士は、データネットワーク7000を介して接続されている。
 クラウド2000及びクラウド3000間は、広域ネットワーク8000を介して接続されている。すなわち、クラウド2000の管理ネットワーク6000と、クラウド3000の管理ネットワーク6000とは、広域ネットワーク8000を介して通信可能な状態にある。また、クラウド2000のデータネットワーク7000と、クラウド3000のデータネットワーク7000とは、広域ネットワーク8000を介して通信可能な状態にある。
 なお、クラウド2000及びクラウド3000が持つ管理ネットワーク6000とデータネットワーク7000とは、同一のネットワークであっても良い。また、管理サーバ4000がクラウド3000内に存在していても良い。
 図2は、本実施形態におけるITインフラストラクチャ5000の構成の一例を示す。上述のようにITインフラストラクチャ5000は、コンピュートサーバ5100(5100A,5100B,5100C)と、ストレージサーバ5200と、ストレージ装置5300とを備えて構成される。
 コンピュートサーバ5100(5100A,5100B,5100C)は、アプリケーションを実行するためのサーバである。第1のコンピュートサーバ5100Aでは、ホストOS(Operating System)5110が稼働しており、ホストOS5110が提供するユーザ空間内でアプリケーションソフトウェア(以下、これを単にアプリケーションと呼ぶ)5111が稼働している。また第2のコンピュートサーバ5100Bでは、ホストOS5120が提供するユーザ空間内でコンテナ5121が稼働している。さらにコンテナ5121が提供する仮想的なユーザ空間内でアプリケーション5122が稼働している。第3のコンピュートサーバ5100Cでは、ホストOS5130上でハイパーバイザ5131が稼働している。さらに、ハイパーバイザ5131が提供する仮想マシン(以下、これをVM(Virtual Machine)と呼ぶ)上でゲストOS5133が稼働しており、ゲストOS5133が提供するユーザ空間内でアプリケーション5134が稼働している。
 ストレージサーバ5200は、自身が持つ記憶装置の容量を他のサーバに提供するサーバである。ストレージサーバ5200は、記憶装置5210を備えている。ストレージサーバ5200ではホストOS5211が稼働しており、ホストOS5211が提供するユーザ空間内でストレージコントローラプログラム5212が稼働している。ストレージコントローラプログラム5212は、記憶装置5210に対するデータの読み書きや、アクセス制御、データ保護機能などのストレージ機能を提供する。なお、コンピュートサーバ5100及びストレージサーバ5200を1つのサーバに統合しても良い。例えばストレージサーバ5200が持つホストOS5211上でアプリケーション5111等を稼働させても良い。
 ストレージ装置5300は、自身が持つ記憶装置の容量を他のサーバに提供する専用の記憶装置である。ストレージ装置5300は、通常、コンピュートサーバ5100やストレージサーバ5200で用いられるハードウェアとは異なる専用ハードウェアを有していることが多いが、ストレージサーバ5200の一種と見なしても良い。ストレージ装置5300は、記憶装置5310と、ストレージコントローラ5311とを備えている。ストレージコントローラ5311は、ストレージサーバ5200上のストレージコントローラプログラム5212と同様のストレージ機能を提供する専用ハードウェアである。
 図3は、本実施形態における管理サーバ4000の構成の一例を示す。管理サーバ4000は、管理ネットワークインタフェース4100、プロセッサ4200、I/O(Input/Output)デバイス4300、記憶装置4400及びメモリ4500を備えている。これらの構成要素は互いにバス4600を介して接続されている。
 管理ネットワークインタフェース4100は、管理ネットワーク6000との接続に用いるネットワークインタフェースである。
 記憶装置4400は、HDD(Hard Disk Drive)やSSD(Solid State Drive)などから構成される。本実施形態の場合、記憶装置4400には、セルフサービスポータルプログラム4410、管理プログラム4420、予兆検知プログラム4430、予兆検証プログラム4440及びアプリケーション問題管理プログラム4450が格納されている。これらプログラムは、プロセッサ4200によってメモリ4500上に読み出されて実行される。
 セルフサービスポータルプログラム4410は、計算機システム1000のユーザに対して、計算機システム1000を使用するためのユーザインタフェースを提供する。例えばセルフサービスポータルプログラム4410が、計算機システム1000のユーザに対して、クラウド2000やクラウド3000上にアプリケーション5111,5122,5134(図2)をデプロイして稼働させるためのユーザインタフェースを提供するようにしても良い。また、例えばセルフサービスポータルプログラム4410が、クラウド2000やクラウド3000上にデプロイされたアプリケーション5111,5122,5134の稼働情報を監視するためのユーザインタフェースを提供するようにしても良い。
 管理プログラム4420は、ITインフラストラクチャ5000を管理するプログラムである。管理プログラム4420は、ITインフラストラクチャ5000の構成情報や稼働情報などを収集して保持する。また管理プログラム4420は、ITインフラストラクチャ5000の各構成要素に対して構成変更を行う。例えば管理プログラム4420は、ストレージサーバ5200やストレージ装置5300が持つ記憶装置5210,5310(図2)から、論理的な記憶領域を切り出し、コンピュートサーバ5100に割り当てる機能を提供しても良い。また、例えば管理プログラム4420は、コンピュートサーバ5100B(図2)が持つホストOS5120(図2)上に新たなコンテナを作成して稼働させる機能を提供しても良い。また、例えば管理プログラム4420は、コンピュートサーバ5100C(図2)が持つハイパーバイザ5131(図2)上に新たなVM5132(図2)を作成して稼働させる機能を提供しても良い。さらに管理プログラム4420は、計算機システム1000のユーザのリクエストに応じて、ITインフラストラクチャ5000が持つコンピュートサーバ5100上にアプリケーション5111,5122,5134をデプロイする機能を有する。
 予兆検知プログラム4430は、ITインフラストラクチャ5000上で稼働するアプリケーション5111,5122,5134(図2)における性能劣化や障害などのサービスレベルの低下の予兆を検知するプログラムである。後述するように、本実施形態においては、かかる予兆をアプリケーション5111,5122,5134のレスポンスタイムに基づいて検知する。
 予兆検証プログラム4440は、予兆検知プログラム4430によって検知された予兆の正しさを検証するプログラムである。またアプリケーション問題管理プログラム4450は、アプリケーション5111,5122,5134(図2)の実装上の問題を管理するプログラムである。
 メモリ4500は、例えば半導体メモリから構成される。本実施形態の場合、メモリ4500には、ITインフラストラクチャ構成テーブル4510、アプリケーション構成テーブル4520、アプリケーション稼働データテーブル4530、アプリケーション稼働データクラスタテーブル4540、負荷分散設定テーブル4550、アプリケーション問題管理テーブル4560、及び、対策効果テーブル4570が格納される。各テーブルの詳細は後述する。なお、各テーブルは記憶装置4400内に保持されても良い。
 記憶装置4400やメモリ4500には、他に、ITインフラストラクチャ5000を管理するための一般的なプログラムやテーブルが格納されていても良い。例えばメモリ4500に、計算機システム1000のユーザの情報(ユーザ名、パスワード、ITインフラストラクチャに対するアクセス権限など)を保持するテーブルが格納されていても良い。
 図4は、本実施形態におけるITインフラストラクチャ構成テーブル4510の一例を示す。ITインフラストラクチャ構成テーブル4510は、ITインフラストラクチャ5000の構成情報を保持するテーブルである。このITインフラストラクチャ構成テーブル4510は、装置ID欄4511、リージョンID欄4512、リソースID欄4513及びリソース容量欄4514を備えて構成される。
 そして装置ID4511には、ITインフラストラクチャ5000を構成するコンピュートサーバ5100やストレージサーバ5200及びストレージ装置5300にそれぞれ付与された識別子(装置ID)が格納される。またリージョンID欄4512には、対応するコンピュートサーバ5100、ストレージサーバ5200又はストレージ装置5300が設置されているリージョンに付与された識別子(リージョンID)が格納される。さらにリソースID欄4513には、対応するコンピュートサーバ5100、ストレージサーバ5200又はストレージ装置5300が備える各リソースにそれぞれ付与された識別子(リソースID)が全て格納される。かかるリソースとしては、例えばCPU(Central Processing Unit)コアやRAM(Random Access Memory)、NIC(Network Interface Card)、SSD及び又はHDDなどを挙げることができる。リソース容量欄4514には、各リソースの性能や容量を示す情報が格納される。
 図5は、本実施形態におけるアプリケーション構成テーブル4520の一例を示す。アプリケーション構成テーブル4520は、アプリケーション5111,5122,5134(図2)からITインフラストラクチャ5000を構成するコンピュートサーバ5100、ストレージサーバ5200及びストレージ装置5300までの構成情報を保持するテーブルである。アプリケーション構成テーブル4520は、アプリID欄4521、バージョン欄4522、アプリインスタンスID欄4523、アプリ実行環境ID欄4524、サーバID欄4525、サーバポートID欄4526、ストレージポートID欄4527、ストレージID欄4528、及び、ボリュームID欄4529を備えて構成される。
 そしてアプリID欄4521には、各アプリケーション5111,5122,5134(図2)にそれぞれ付与された識別子(アプリID)が格納される。またバージョン欄4522には、対応するアプリケーション5111,5122,5134(図2)のバージョンを示す情報が格納される。アプリインスタンスID欄4523には、対応するアプリケーション5111,5122,5134の各インスタンス(以下、これをアプリインスタンス又はアプリケーションインスタンスとも呼ぶ)にそれぞれ付与された識別子(アプリインスタンスID)がすべて格納される。さらにアプリ実行環境ID欄4524には、対応するインスタンスの実行環境(ベアメタルサーバ、コンテナ、VMなど)を表す識別子(アプリ実行環境ID)が格納される。
 サーバID欄4525には、対応するインスタンスの実行環境を提供するコンピュートサーバ5100(図1)に付与された識別子(サーバID)が格納される。またサーバポートID欄4526には、そのコンピュートサーバ5100が持つネットワークインタフェースに付与された識別子(サーバポートID)が格納される。さらにストレージポートID欄4527には、ストレージサーバ5200(図2)やストレージ装置5300(図2)が持つネットワークインタフェースのネットワークポートのうち、対応するインスタンスが利用するネットワークポートに付与された識別子(ストレージポートID)が格納される。
 またストレージID欄4528には、対応するインスタンスに対して記憶容量を提供しているストレージサーバ5200又はストレージ装置5300に付与された識別子(ストレージID)が格納される。さらにボリュームID欄4529には、対応するインスタンスに対してストレージサーバ5200又はストレージ装置5300が提供する記憶領域(ボリューム)に対して付与された識別子(ボリュームID)が格納される。
 図6は、本実施形態におけるアプリケーション稼働データテーブル4530の一例を示す。アプリケーション稼働データテーブル4530は、コンピュートサーバ5100に実装された各アプリケーション5111,5122,5134の稼働情報(性能情報や障害情報など)を保持するテーブルである。
 実際上、本実施形態においては、アプリケーション5111,5122,5134ごとに、そのアプリケーション5111,5122,5134について予め定められた後述するメトリクス空間を構成するメトリックなどの必要なメトリックのデータ値を定期的(例えば1秒ごと)にそれぞれ取得する。そして、このように取得された各メトリックのデータ値がそのアプリケーション5111,5122,5134の稼働情報(以下、稼働データとも呼ぶ)としてこのアプリケーション稼働データテーブル4530に蓄積される。
 このアプリケーション稼働データテーブル4530は、アプリID欄4531、バージョン欄4532、アプリインスタンスID欄4533、メトリック名欄4534、外的要因フラグ欄4535、時刻欄4536、及び、データ値欄4537を備えて構成される。
 そしてアプリID欄4531には、コンピュートサーバ5100に実装された各アプリケーション5111,5122,5134にそれぞれ付与されたアプリIDが格納される。またバージョン欄4532には、対応するアプリケーション5111,5122,5134のバージョンを示す情報が格納される。さらにアプリインスタンスID欄4533は、対応するアプリケーション5111,5122,5134のすべてのインスタンスのアプリインスタンスIDが格納される。さらにメトリック名欄4534には、対応するアプリケーション5111,5122,5134の対応するインスタンスについて設定されたメトリックの名前(メトリック名)を示す情報が格納される。
 外的要因フラグ欄4535には、対応するメトリックが対応するアプリケーション5111,5122,5134の稼働情報を変化させる外的要因であるか否かを示すフラグ(以下、これを外的要因フラグと呼ぶ)が格納される。図6の例では、対応するメトリックが対応するアプリケーション5111,5122,5134の稼働情報を変化させる外的要因ではない場合には外的要因フラグが「0」に設定され、当該メトリックが当該アプリケーション5111,5122,5134の稼働情報を変化させる外的要因である場合には外的要因フラグが「1」に設定される。
 時刻欄4536には、対応するアプリケーションの対応するバージョンの対応するインスタンスに関して対応するメトリックのデータ値を取得した時刻が格納される。またデータ値欄4537には、対応する時刻に取得した対応するメトリックのデータ値が格納される。
 図7は、本実施形態におけるアプリケーション稼働データクラスタテーブル4540の一例を示す。アプリケーション稼働データクラスタテーブル4540は、アプリケーション5111,5122,5134の稼働データをクラスタリングした結果得られた、稼働データのデータ値と性能との相関を表す相関モデル(以下、適宜、これを予兆検知モデルと呼ぶ)を保持するテーブルである。
 後述のように、本実施形態においては、アプリケーション5111,5122,5134ごとに、そのアプリケーション5111,5122,5134の稼働データ(そのアプリケーション5111,5122,5134について予め設定された各メトリックのデータ値)をアプリケーション稼働データテーブル4530に登録する度に、予め設定された条件を満たす稼働データのクラスタリングが行われる。アプリケーション稼働データクラスタテーブル4540は、このようにして行われたクラスタリングの結果を保持するためのテーブルである。
 このアプリケーション稼働データクラスタテーブル4540は、アプリID欄4541、バージョン欄4542、メトリクス空間欄4543、条件欄4544、クラスタID欄4545、クラスタ中心欄4546、及び、標準偏差欄4547を備えて構成される。
 そしてアプリID欄4541には、コンピュートサーバ5100に実装された各アプリケーション5111,5122,5134のアプリIDが格納される。またバージョン欄4542には、対応するアプリケーション5111,5122,5134のバージョンが格納される。さらにメトリクス空間欄4543には、対応するアプリケーション5111,5122,5134の対応するバージョンについて予め設定されたメトリクス空間を構成する1つ以上のメトリックの組み合わせが格納される。
 条件欄4544には、対応するアプリケーション5111,5122,5134の対応するバージョンについて対応するメトリクス空間において稼働データをクラスタリングする際の対象とすべき稼働データの条件が格納される。例えば図7の例では、「アプリA」というアプリケーション5111,5122,5134のある時刻における稼働データにおいて、「Response Time」の値が「20」より小さい場合に、その稼働データに含まれる「Queue Depth」、「Request Per Second」、「Input Data Average Size」の値の組合せを該当メトリクス空間においてクラスタリングすべきことが規定されている。
 クラスタID欄4545には、対応するメトリクス空間内に生成された各クラスタにそれぞれ付与された識別子(クラスタID)が格納される。またクラスタ中心欄4546には、対応するメトリクス空間における対応するクラスタの中心位置の座標が格納される。さらに標準偏差欄4547には、対応するクラスタに含まれる稼働データの標準偏差を示す情報が格納される。
 図8は、本実施形態における負荷分散設定テーブル4550の一例を示す。負荷分散設定テーブル4550は、各アプリケーション5111,5122,5134の各インスタンスに対するロードバランサによる負荷分散の設定情報を格納するテーブルである。なお、図2ではロードバランサの記載は省略したが、ロードバランサはアプリケーション5111,5122,5134と同様に、任意のコンピュートサーバ5100(図1)上で稼働するものとする。この負荷分散設定テーブル4550は、アプリID欄4551、バージョン欄4552、ロードバランサID欄4553、アプリインスタンスID欄4554、及び、負荷バランス欄4555を備えて構成される。
 そしてアプリID欄4551には、コンピュートサーバ5100に実装された各アプリケーション5111,5122,5134のアプリIDが格納され、バージョン欄4552には、対応するアプリケーション5111,5122,5134のバージョンが格納される。またロードバランサID欄4553には、対応するアプリケーション5111,5122,5134の負荷分散を行うロードバランサに付与された識別子(ロードバランサID)が格納される。
 さらにアプリインスタンスID欄4554には、対応するアプリケーション5111,5122,5134のすべてのインスタンスのアプリインスタンスIDがそれぞれ格納され、負荷バランス欄4555には、対応するアプリケーション5111,5122,5134の対応するインスタンスに対してロードバランサが割り当てるべき、予め定められた負荷のバランスを表す情報が格納される。
 図9は、本実施形態におけるアプリケーション問題管理テーブル4560の一例を示す。アプリケーション問題管理テーブル4560は、コンピュートサーバ5100に実装されたアプリケーション5111,5122,5134の実装上の問題点を保持するテーブルである。このアプリケーション問題管理テーブル4560は、アプリID欄4561、バージョン欄4562、登録時刻欄4563、現象欄4564、及び、条件欄4565を備えて構成される。
 そしてアプリID欄4561には、コンピュートサーバ5100に実装された各アプリケーション5111,5122,5134にそれぞれ付与されたアプリIDが格納され、バージョン欄4562には、対応するアプリケーション5111,5122,5134のバージョンを示す情報が格納される。また登録時刻欄4563には、対応するアプリケーション5111,5122,5134における対応するバージョンの実装上の問題が登録された時刻が格納される。さらに現象欄4564には、対応するアプリケーション5111,5122,5134における対応するバージョンの実装上の問題によって引き起こされた現象を示す情報が格納される。
 条件欄4565には、対応する現象が発生した条件を示す情報が格納される。例えば図9の例では、「アプリA」のバージョン「1.0」において、インスタンス数が「3」、かつ「Queue Depth=20.0」、「Request Per Second=50」及び「Input Data Average Size=150」という条件を満たした際に、該当アプリケーション5111,5122,5134の「Response Time」が「50」より長くなったという現象(性能劣化)がそのアプリケーション5111,5122,5134におけるそのバージョンの実装上の問題として登録されている状態を示している。
 図10は、本実施形態における対策効果テーブル4570の一例を示す。対策効果テーブル4570は、あるアプリケーション5111,5122,5134のインスタンスにおいて性能劣化などの予兆が検知された際に管理プログラム4420によって実行された事前対策の効果を保持するテーブルである。この対策効果テーブル4570は、アプリID欄4571、バージョン欄4572、メトリクス空間欄4573、外れ値欄4574、最近傍クラスタID欄4575、正規化距離欄4576、対策プラン欄4577、及び、効果欄4578を備えて構成される。
 そしてアプリID欄4571には、コンピュートサーバ5100に実装された各アプリケーション5111,5122,5134のアプリIDが格納され、バージョン欄4572には、対応するアプリケーション5111,5122,5134のバージョンが格納される。またメトリクス空間欄4573には、対応するアプリケーション5111,5122,5134について予め設定されたメトリクス空間を構成する1つ以上のメトリックの組み合わせを示す情報が格納される。
 外れ値欄4574には、対応するメトリクス空間においてどのクラスタにも属さないと判定された稼働データの値(外れ値)が格納される。本実施形態の場合、図6及び図7について上述したように、アプリケーション5111,5122,5134ごとに、そのアプリケーション5111,5122,5134について予め設定されたメトリクス空間を構成する各メトリックのデータ値等をそのアプリケーション5111,5122,5134の稼働データとして定期的に取得し、これをそのメトリクス空間上でクラスタリングしている。外れ値は、このようなクラスタリングによりどのクラスタにも属さないと判定された稼働データの値(外れ値)が格納される。
 また最近傍クラスタ欄ID4575には、外れ値欄4574に格納された値(外れ値)に最も近い位置に存在するクラスタ(以下、これを最近傍クラスタと呼ぶ)のID(最近傍クラスタID)が格納される。
 正規化距離欄4576には、対応する外れ値欄4574に格納された値と、対応する最近傍クラスタの中心との距離を正規化した値が格納される。正規化距離の算出方法には、例えば、外れ値と最近傍クラスタのユークリッド距離を、該当クラスタの標準偏差で除算するなどの方法があるが、限定はしない。また対策プラン欄4577には、対応するアプリケーション5111,5122,5134の対応するバージョンのインスタンスにおいて性能劣化などの予兆が検知された際に管理プログラム4420によって実行された事前対策が格納される。
 効果欄4578には、性能劣化などの予兆に対する該当の事前対策による効果を示す情報が格納される。例えば図10の例では、「アプリA」というアプリケーション5111,5122,5134のバージョン「1.0」において、「Queue Depth」、「Request Per Second」、「Input Data Average Size」から構成されるメトリクス空間で「Queue Depth =20.0」、「Request Per Second=50」、「Input Data Average Size=150」で示される外れ値が検出された際に、事前対策として該当アプリケーション5111,5122,5134のインスタンス数を2倍にするスケールアウトを実行した結果、性能劣化が起こらなくなったことを示している。また図10の例では、同じメトリクス空間で「Queue Depth =30.0」、「Request Per Second=50」、「Input Data Average Size=150」で示される外れ値が検出された際に、該当アプリケーション5111,5122,5134のインスタンス数を2倍にするスケールアウトを実行した際には、該当アプリケーション5111,5122,5134において「10%」の「Response Time」の劣化が発生したことを示している。
(1-2)メトリクス空間設定画面
 図11は、本実施形態におけるセルフサービスポータルプログラム4410により管理サーバ4000に表示されるメトリクス空間設定画面4410Aの構成例を示す。メトリクス空間設定画面4410Aは、計算機システム1000のユーザが所望するアプリケーション5111,5122,5134の所望するバージョンに対してメトリクス空間を設定するためのユーザインタフェースである。
 このメトリクス空間設定画面4410Aは、メトリクス空間を設定しようとするアプリケーション5111,5122,5134(バージョンを含む)を指定するためのアプリケーション指定フィールド4411Aと、そのアプリケーション5111,5122,5134に対するメトリクス空間を設定するためのメトリクス空間設定フィールド4412Aと、クラスタリングするデータの条件を設定するための条件設定フィールド4413Aと、OKボタン4414A及びキャンセルボタン4415Aとを備えて構成される。
 アプリケーション指定フィールド4411Aは、アプリケーション名表示欄4411AA及びドロップダウンボタン4411ABを備えて構成される。そしてアプリケーション指定フィールド4411Aでは、ドロップダウンボタン4411ABをクリックすることによりメトリクス空間を設定可能なすべてのアプリケーション5111,5122,5134のアプリケーション名(バージョンを含む)が掲載されたドロップダウンリスト(図示せず)を表示させることができ、このドロップダウンリストにアプリケーション名が掲載されたアプリケーション5111,5122,5134の中から所望するアプリケーション5111,5122,5134を選択することにより、そのアプリケーション5111,5122,5134をメトリクス空間の設定対象として指定することができる。なお、このとき指定されたアプリケーション5111,5122,5134のアプリケーション名がアプリケーション名表示欄4411AAに表示される。
 またメトリクス空間設定フィールド4412Aは、メトリクス空間4412AA及びメトリクス空間追加ボタン4412ABを備えて構成される。またメトリクス空間4412AAには、1又は複数のテキストボックス4412AAXと、メトリック追加ボタン4412AAYとが設けられている。そしてメトリクス空間4412AAでは、所望する各メトリックの名前をそれぞれテキストボックス4412AAXに入力することにより、これらのメトリックをそのとき設定しようとするメトリクス空間を構成するメトリックとして指定することができる。またメトリクス空間4412AAでは、メトリック追加ボタン4412AAYをクリックすることにより、メトリックを入力するためのテキストボックス4412AAXを追加表示させることができる。さらにメトリクス空間設定フィールド4412Aでは、メトリクス空間追加ボタン4412ABをクリックすることにより、メトリクス空間4412AAを追加表示させることができる。これにより1つのアプリケーション5111,5122,5134に対して複数のメトリクス空間を設定することができるようになされている。
 条件設定フィールド4413Aは、メトリック用テキストボックス4413AA、条件指定欄4413AB、ドロップダウンボタン4413AC、値用テキストボックス4413AD及び条件追加ボタン4413AEを備えて構成される。そして条件設定フィールド4413Aでは、ドロップダウンボタン4413ACをクリックすることにより、不等号などの記号の一覧が掲載されたドロップダウンリスト(図示せず)を表示させることができ、このドロップダウンリストに掲載された記号の中から所望する記号を選択することにより、その記号を条件指定欄4413ABに表示させることができる。これにより条件設定フィールド4413Aでは、メトリック用テキストボックス4413AAに所望するメトリックの名前を入力すると共に、値用テキストボックス4413ADに値を入力し、さらに条件指定欄4413ABに所望する記号を表示させることにより、クラスタリングすべき稼働データの条件を設定することができる。また条件設定フィールド4413Aでは、条件追加ボタン4413AEをクリックすることにより、メトリック用テキストボックス4413AA、条件指定欄4413AB、ドロップダウンボタン4413AC及び値用テキストボックス4413ADのセットを追加表示させることができる。これにより1つのアプリケーション5111,5122,5134に対して複数の条件を設定することができるようになされている。
 そしてメトリクス空間設定画面4410Aでは、上述のようにしてアプリケーション指定フィールド4411Aにおいて対象とするアプリケーション5111,5122,5134を指定し、メトリクス空間設定フィールド4412Aにおいてそのとき設定しようとするメトリクス空間を定義し、条件設定フィールド4413Aにおいてクラスタリングする稼働データの条件を設定した後、OKボタン4414Aをクリックすることにより、その内容を設定することができる。この設定内容は、セルフサービスポータルプログラム4410によってアプリケーション稼働データクラスタテーブル4540(図7)に格納される。またメトリクス空間設定画面4410Aでは、キャンセルボタン4415Aをクリックすることにより、アプリケーション指定フィールド4411A、メトリクス空間設定フィールド4412A及び条件設定フィールド4413Aにおいて指定した条件を設定することなく、閉じることができる。
(1-3)管理サーバにおいて実行される各種処理
(1-3-1)アプリケーション監視処理
 図12は、管理プログラム4420により実行されるアプリケーション監視処理の処理手順を示す。管理プログラム4420は、この図12に示す手順に従って、アプリケーション5111,5122,5134を監視し、これらアプリケーション5111,5122,5134の稼働情報(稼働データ)を収集する。なお本アプリケーション監視処理は、管理プログラム4420の起動時に自動的に開始されるものとするが、これに限らず他の方法で開始されても良い。
 まずステップS1にて、管理プログラム4420は、1つのアプリケーション5111,5122,5134のインスタンスごとに、そのアプリケーション5111,5122,5134について定められたメトリックのデータ値を稼働データとしてそれぞれ取得し、取得した稼働データをアプリケーション稼働データテーブル4530(図6)に格納する。アプリケーション5111,5122,5134の稼働データを取得する方法は、一般的なApplication Performance Monitoringソフトから取得するなど、任意の方法で良い。
 続くステップS2にて、管理プログラム4420は、アプリケーション稼働データクラスタテーブル4540(図7)を参照して、該当アプリケーション5111,5122,5134について予め設定されたメトリクス空間ごとに、対応する条件欄4544からそのメトリクス空間について予め定められたクラスタリングを実行する条件を取得する。
 次いで、管理プログラム4420は、ステップS3にて、かかるメトリクス空間ごとに、ステップS1で取得した稼働データの中からステップS2で取得した条件を満たす稼働データを抽出する。
 さらに管理プログラム4420は、ステップS4にて、かかるメトリクス空間ごとに、かかる条件を満たす稼働データを抽出できたか否かを判定する。判定結果が肯定的であった場合、処理はステップS5に進む。判定結果が否定的であった場合、処理はステップS6に進む。
 ステップS5にて、管理プログラム4420は、かかるメトリクス空間ごとに、アプリケーション5111,5122,5134の稼働データをクラスタリング(予兆検知モデルを更新)し、クラスタの情報をアプリケーション稼働データクラスタテーブル4540(図7)に格納する。稼働データをクラスタリングする方法としては、例えばk-means法などの一般的に知られた方法があるが、特に限定はしない。
 ステップS6にて、管理プログラム4420は、予め定められた時間(例えば1秒)が経過するのを待つ。予め定められた時間が経過した後、処理はステップS1に戻る。従って、本処理は管理プログラム4420のプロセス内の1つのスレッドとして、後述する他の処理とは並列に実行することが好ましい。
 なお以上のステップS1~ステップS6の処理は、コンピュートサーバ5100に実装された各アプリケーション5111,5122,5134のバージョンごとにそれぞれ実行される。
(1-3-2)予兆検知処理
 図13は、本実施形態において、予兆検知プログラム4430がアプリケーション5111,5122,5134の性能劣化の予兆を検知する予兆検知処理の処理手順を示す。
 以下においては、予兆検知の対象の例としてアプリケーション5111,5122,5134の性能劣化を取り上げているが、これに限らず他の対象であっても良い。例えばアプリケーション5111,5122,5134の可用性低下の予兆を検知しても良いし、ITインフラストラクチャ5000の性能劣化や可用性の低下の予兆を検知しても良い。また、これらの予兆を検知する方法には、例えば特開2009-199534号公報で開示されている方法などがあるが、特に限定しない。本実施の形態においてはアプリケーションの稼働データをクラスタリングし、どのクラスタにも属さない外れ値を検出するという、一般的に「教師なし学習」に分類される手法を用いているが、これに限らず他の方法で予兆を検知しても良い。また本実施形態においては、本処理は予兆検知プログラム4430の起動時に自動的に開始されるものとするが、これに限らず他の方法で開始されても良い。
 まずステップS10にて、予兆検知プログラム4430は、アプリケーション稼働データテーブル4530を参照し、1つのアプリケーション5111,5122,5134の最新の稼働データを取得する。最新の稼働データは、最も取得時刻の新しい稼働データ1つであっても良いし、例えば直近の10分間の稼働データなどのように、時間的に幅を持たせても良い。
 続くステップS11にて、予兆検知プログラム4430は、アプリケーション稼働データクラスタテーブル4540(図7)を参照し、該当アプリケーション5111,5122,5134の稼働データクラスタの情報を取得する。
 次いで、予兆検知プログラム4430は、ステップS12にて、ステップS10で取得した最新の稼働データと、ステップS11で取得した稼働データクラスタの情報とを比較し、最近傍クラスタの中心から最新の稼働データまでの距離Lを算出する。本実施形態においては、距離Lは、最新の稼働データと最近傍クラスタの中心との間のユークリッド距離を最近傍クラスタの標準偏差で除算した値とするが、これに限らず、他の方法で距離Lを算出しても良い。
 ステップS13にて、予兆検知プログラム4430は、算出した距離Lが最近傍クラスタの標準偏差のN倍より大きいか否かを判定する。定数Nの値は予め定められているものとする。判定結果が肯定的であった場合、ステップS10で取得した稼働データは外れ値であるものと判断され、処理はステップS14に進む。判定結果が否定的であった場合、処理はステップS16に進む。
 ステップS14にて、予兆検知プログラム4430は、セルフサービスポータルプログラム4410が表示するセルフサービスポータルに性能劣化の予兆を表示する。表示する情報には、例えばステップS13で結果が肯定的と判定された時刻や、アプリケーションのIDやバージョン、アプリケーション稼働データクラスタテーブル4540における対応するメトリクス空間欄4543に格納されたメトリクス空間の定義や、ステップS12で算出した距離L、及び又は、最近傍クラスタの中心位置などが含まれて良い。
 ステップS15にて、予兆検知プログラム4430は、管理プログラム4420を呼び出し、図14について後述する事前対策処理を実行させる。
 ステップS16にて、予兆検知プログラム4430は、予め定められた時間が経過するのを待つ。予め定められた時間が経過した後、処理はステップS10に戻る。本予兆検知処理は予兆検知プログラム4430のプロセス内の1つのスレッドとして実行しても良い。
 なお以上のステップS1~ステップS6の処理は、コンピュートサーバ5100に実装されたアプリケーション5111,5122,5134ごとに実行される。
(1-3-3)事前対策処理
 図14は、管理プログラム4420が、アプリケーション5111,5122,5134の性能劣化の予兆が検知されたことを受けて、アプリケーション5111,5122,5134の性能劣化が実際に起こらないようにするための事前対策を実行する事前対策処理の処理手順を示す。
 本実施形態において、本事前対策処理は、予兆検知処理(図13)のステップS15にて、管理プログラム4420が予兆検知プログラム4430により呼び出されることによって開始されるものとするが、これに限らず他の方法で開始されても良い。なお、予兆検知プログラム4430が管理プログラム4420を呼び出す際に、検知した予兆に関する情報を当該管理プログラム4420に受け渡すものとする。従って、管理プログラム4420は、本事前対策処理を実施する際に、予兆が検知されたアプリケーション5111,5122,5134のIDやバージョン及び予兆の内容を特定できているものとする。
 まず管理プログラム4420は、ステップS20にて、対象とするアプリケーション5111,5122,5134について、事前対策を実施する1つのインスタンスと、事前対策を実施しないインスタンスとを選定する。選定の方法には例えば下記の第1~第3の方法がある。
(A)第1の方法
 アプリケーション構成テーブル4520(図5)を参照し、対象とするアプリケーション5111,5122,5134の該当するバージョンの中から、インスタンスの一覧を取得する。インスタンスの一覧のうち先頭の1つを、事前対策を実施しないインスタンスとして選定する。また、対象とするアプリケーション5111,5122,5134のインスタンスのうち残りの全てを、事前対策を実施するインスタンスとして選定する。
(B)第2の方法
 アプリケーション構成テーブル4520を参照し、対象とするアプリケーション5111,5122,5134の対象とするバージョンの中から、インスタンスの一覧を取得する。さらにITインフラストラクチャ構成テーブル4510(図4)を参照し、各インスタンスが稼働している実行環境のリージョンを特定する。同一のリージョンで稼働するインスタンスが複数ある場合、それらのインスタンスのうちの1つを、事前対策を実施しないインスタンスとして選定する。同一のリージョンで稼働する残りのインスタンス及び他のリージョンで稼働するインスタンスはすべて、事前対策を実施するインスタンスとして選定する。
 この選定方法では、例えば「リージョン1」で稼働するインスタンスが1つ、「リージョン2」で稼働するインスタンスが2つ存在する場合に、「リージョン1」で稼働するインスタンスが事前対策を実施しないインスタンスとして選定されるのを防ぐことができる。仮に「リージョン1」で稼働するインスタンスが事前対策を実施しないインスタンスとして選定した場合、このインスタンスは将来的に性能劣化が発生する可能性がある。この例では「リージョン1」で稼働する他のインスタンスは存在しないため、「リージョン1」に地理的に近いところから対象とするアプリケーションを利用しているユーザにとって、サービスレベルが著しく低下する可能性がある。本第2の方法によれば、これを防ぐ、あるいは緩和することができる。
(C)第3の方法
 アプリケーション構成テーブル4520を参照し、対象とするアプリケーション5111,5122,5134の対象とするバージョンの中から、インスタンスの一覧を取得する。これらすべてを、事前対策を実施するインスタンスとして選定する。また該当アプリケーションの該当バージョンのインスタンスを新たにITインフラストラクチャ5000上にデプロイし、これを事前対策を実施しないインスタントして選定する。
 続くステップS21にて、管理プログラム4420は、事前対策を実施する対象として選定したインスタンスに対して、性能劣化が実際に起こらないようにするための事前対策を実施する。本実施形態においては、事前対策の方法としてインスタンスのスケールアウトを行うものとするが、これに限らず他の方法で対策を行っても良い。スケールアウトするインスタンスの数(n)を決める方法には、例えば予兆が検知された時刻のアプリケーション稼働データテーブル4530(図6)におけるメトリック名が「Response Time」の対応するデータ値欄4537に格納されていたデータ値(r1)と、予兆の出ていなかった時刻の当該データ値欄4537に格納されていたデータ値の平均値(r2)とを比較し、次式
Figure JPOXMLDOC01-appb-M000001
によりインスタンス数nを決定する方法がある。ただし、これに限らず他の方法でインスタンス数nを決定しても良い。
 ステップS22にて、管理プログラム4420は、対象とするアプリケーション5111,5122,5134に対応するロードバランサの負荷分散設定を変更する。本実施形態では、例えば以下の第1又は第2の方法で負荷分散設定を変更する。
(A)第1の方法
 ステップS20で事前対策を実施しない対象として選定したインスタンスをグループ1とする。ステップS20で事前対策を実施する対象として選定したインスタンスについて、各インスタンスと、ステップS21でスケールアウトによって追加されたインスタンスとを1つのグループとする。例えば図8の「アプリA」、バージョン「1.0」において、「インスタンス2」及び「インスタンス3」が事前対策を実施する対象、「インスタンス1」が事前対策を実施しない対象と選定された場合を例として説明する。ステップS21で「インスタンス2」及び「インスタンス3」をスケールアウトし、それぞれインスタンス数を2ずつ増やすという対策が行われたとする。ここではスケールアウトにより追加されたインスタンスを「インスタンス2’」、「インスタンス2’’」及び「インスタンス3’」、「インスタンス3’’」と表記する。このとき、これら合計7つのインスタンスは以下のようにグルーピングされる。
 グループ1=[インスタンス1]
 グループ2=[インスタンス2、インスタンス2’、インスタンス2’’]
 グループ3=[インスタンス3、インスタンス3’、インスタンス3’’]
 「アプリA」のバージョン「1.0」に対する負荷を、各グループで均等に振り分けた上で、グループごとに、当該グループに振り分けられた負荷を当該グループ内の各インスタンスに均等に振り分けるように負荷バランスを設定する。前述の例においては、各グループの負荷は1/3ずつとなる。グループ1にはインスタンス1のみが含まれるため、インスタンス1の負荷は1/3となる。グループ2、3にはインスタンスが3つずつ含まれるため、「インスタンス2」、「インスタンス2’」、「インスタンス2’’」、「インスタンス3」、「インスタンス3’」、「インスタンス3’’」の負荷はそれぞれ1/9となる。
(B)第2の方法
 ステップS20で事前対策を実施しない対象として選定したインスタンスをグループ1とする。ステップS20で事前対策を実施する対象として選定したインスタンスと、ステップS21でスケールアウトによって追加されたインスタンスを合わせたリストを作成する。このリストに含まれるインスタンスを、i(iは2以上の正数)番目のグループに含まれるインスタンス数がi個になるようにグループ分けする。なお、i番目のグループに含まれるインスタンス数が(i-1)番目のグループに含まれるインスタンス数より少ない場合には、i番目のグループを削除し、i番目のグループに含まれるインスタンスを(i-1)番目のグループに含める。例えば図8の「アプリA」、バージョン「1.0」において、「インスタンス2」、「インスタンス3」が事前対策を実施する対象、「インスタンス1」が事前対策を実施しない対象と選定された場合を例として説明する。ステップS21で「インスタンス2」、「インスタンス3」をスケールアウトし、それぞれインスタンス数を2ずつ増やすという対策が行われたとする。ここではスケールアウトにより追加されたインスタンスを「インスタンス2’」、「インスタンス2’’」及び「インスタンス3’」、「インスタンス3’’」と表記する。このとき、これら合計7つのインスタンスは下記のようにグルーピングされる。
 グループ1=[インスタンス1]
 グループ2=[インスタンス2、インスタンス2’]
 グループ3=[インスタンス2’’、インスタンス3、インスタンス3’、インスタンス3’’]
 「アプリA」のバージョン「1.0」に対する負荷を、各グループで均等に分けた上で、各グループの負荷をグループ内の各インスタンスで均等になるように負荷バランスを設定する。前述の例においては、各グループの負荷は1/3ずつとなる。グループ1には「インスタンス1」のみが含まれるため、「インスタンス1」の負荷は1/3となる。グループ2には「インスタンス」が2つ含まれるため、「インスタンス2」及び「インスタンス2’」の負荷は1/6ずつとなる。グループ3にはインスタンスが4つ含まれるため、「インスタンス2’’」、「インスタンス3」、「インスタンス3’」、「インスタンス3’’」の負荷は1/12ずつとなる。
 管理プログラム4420は、負荷分散設定テーブル4550(図8)に格納されている負荷バランスの情報を、これら第1又は第2の方法で決定した各インスタンスの負荷バランスの情報で上書きする。ロードバランサは上書きされた負荷バランス情報を参照し、これに基づいて負荷分散を行う。なお、ロードバランサが負荷バランスの設定を変更する機能を有していない場合には、管理プログラム4420が新たにロードバランサをITインフラストラクチャ5000上にデプロイすることで、各インスタンスの負荷が上述のように算出した負荷バランスになるように調整しても良い。例えば、上述の第1の方法で説明した例では、元のロードバランサに加えて、「グループ2」を担当するサブロードバランサ1と、「グループ3」を担当するサブロードバランサ2を新たにデプロイする。元のロードバランサは「インスタンス1」と、サブロードバランサ1と、サブロードバランサ2に対して均等に負荷分散を行う。サブロードバランサ1は「インスタンス2」、「インスタンス2’」、「インスタンス2’’」に対して均等に負荷分散を行う。サブロードバランサ2は「インスタンス3」、「インスタンス3’」、「インスタンス3’’」に対して均等に負荷分散を行う。この結果、「インスタンス1」には全体負荷の1/3が、「インスタンス2」、「インスタンス2’」、「インスタンス2’’」、「インスタンス3」、「インスタンス3’」及び「インスタンス3’’」にはそれぞれ全体負荷の1/9ずつが割り当てられることになり、上述の方法で元のロードバランサの負荷バランスの設定を変更する場合と同じ効果が得られる。
 ステップS23にて、管理プログラム4420は、予兆検証プログラム4440を呼び出す。そして予兆検証プログラム4440による図15について後述する予兆検証処理が終了すると、本事前対策処理が終了する。
 なお以上のステップS1~ステップS6の処理は、コンピュートサーバ5100に実装されたアプリケーション5111,5122,5134のうちの必要なアプリケーション5111,5122,5134ごとに実行される。
(1-3-4)予兆検証処理
 図15は、予兆検知プログラム4430が検知した予兆の正しさを、予兆検証プログラム4440が検証する予兆検証処理の処理手順を示す。
 本実施形態において、本予兆検証処理は、事前対策処理(図14)のステップS23にて管理プログラム4420により予兆検証プログラム4440が呼び出されることによって開始されるものとするが、これに限らず他の方法で開始されても良い。
 まず予兆検証プログラム4440は、ステップS30にて、性能劣化の予兆が検知されたアプリケーション5111,5122,5134の全インスタンスの稼働データを予め定められた期間、監視する。
 続くステップS31にて、予兆検証プログラム4440は、管理プログラム4420によって事前対策処理(図14)のステップS20で事前対策を実施しないインスタンスとして選定されたインスタンスについて、性能劣化が発生したか否かを判定する。この場合の判定手法としては、予兆検知処理(図13)のステップS11~ステップS13について上述した方法と同様にして、事前対策を実施しないインスタンスとして選定されたインスタンスの稼働データ(最新の稼働データ又は稼働データの平均値)が外れ値となるか否かに基づいて判定する手法や、事前対策を実施したインスタンスの稼働データと、事前対策を実施していないインスタンスの稼働データとの比較結果に基づいて判定する手法を適用することができる。例えば、後者の手法を適用する場合、事前対策を実施した各インスタンスの稼働データの平均値と、事前対策を実施していないインスタンスの稼働データとが一致しなかった場合に性能劣化が発生したと判定する。
 ステップS31の判定結果が肯定的である場合、処理はステップS34に進む。またステップS31の判定結果が否定的である場合、処理はステップS32に進む。この判定結果が肯定的であるということは、予兆を検知したにも関わらず事前対策を実施しなかったインスタンスにおいて実際に性能劣化が起こったことを意味する。従って、この場合、検知された予兆は正しかったと検証できる。一方、この判定結果が否定的であるということは、予兆を検知したにも関わらず事前対策を実施しなかったインスタンスにおいて実際には性能劣化が起こらなかったことを意味する。従って、この場合、検知された予兆は誤りであったと検証できる。
 ステップS32にて、予兆検証プログラム4440は、予兆検知処理(図13)のステップS13で外れ値として検出された稼働データを、性能劣化の予兆に含めないように(正確には、最近傍の稼働データクラスタに含めるように)アプリケーション稼働データクラスタテーブル4540に登録されている予兆検知モデルのデータ(クラスタ中心、標準偏差等)を修正する。このように誤った予兆検知の原因となった外れ値を最近傍クラスタに含めることで、この外れ値と同様の値が将来的に発生した場合に、これを外れ値として検出しなくなり、この結果、誤った予兆検知を行わないようにできる。
 ステップS33にて、予兆検証プログラム4440は、管理プログラム4420が事前対策処理(図14)のステップS21で行った事前対策と、ステップS22で行った負荷分散方法の変更を元に戻す。本実施形態においては、ステップS21で行う事前対策は、インスタンスのスケールアウトであるため、ここではスケールアウトによって増やされたインスタンスの数を元の数に縮小する。これにより、誤った予兆検知によって行われた事前対策を取り消すことができ、不要なコストが発生し続けることを回避することができる。
 ステップS34にて、予兆検証プログラム4440は、アプリケーション稼働データテーブル4530(図6)を参照し、予兆検知処理(図13)のステップS12で外れ値として検出された稼働データにおいて、最近傍クラスタからの距離が最も離れていたメトリックが外的要因か否かを判定する。判定結果が肯定的である場合、処理はステップS36に進む。判定結果が否定的である場合、処理はステップS35に進む。この判定結果が肯定的であるということは、性能劣化の予兆は外的要因によって発生しており、アプリケーション自体の実装上の問題とは言えないことを意味する。一方、この判定結果が否定的であるということは、性能劣化の予兆は内的要因によって発生しており、アプリケーション自体の実装上の問題である可能性があることを意味する。
 ステップS35にて、予兆検証プログラム4440は、対応するアプリケーション5111,5122,5134の性能劣化の問題をアプリケーション問題管理プログラム4450に通知する。例えば図9では、インスタンス数が「3」であり、かつ「Queue Depth=120」、「Request Per Second=1300」、「Input Data Average Size=150」という条件の下、「アプリA」のバージョン「1.0」において「Response Time」が「50」以上になったという問題が登録されている。図7に示されたクラスタ情報の例では、この外れ値の最近傍クラスタは「クラスタ1」であるが、そのクラスタ中心からの距離では「Queue Depth」の距離が標準偏差(=「20」)の3倍程度、離れていることがわかる。図6のアプリケーション稼働データテーブル4530において、「Queue Depth」は外的要因フラグ欄4535に格納された外的要因フラグの値が「0」となっており、これは外的要因でないことを意味している。従って、予兆検証プログラム4440は、この性能劣化の予兆がアプリケーションの実装上の問題により発生した可能性があるとして、この問題をアプリケーション問題管理プログラム4450に通知する。かくしてアプリケーション問題管理プログラム4450は、予兆検証プログラム4440から通知されたかかる問題をアプリケーション問題管理テーブル4560に登録して管理する。
 ステップS36にて、予兆検証プログラム4440は、管理プログラム4420によって事前対策処理(図14)のステップS20で事前対策を実施するインスタンスとして選定されたインスタンスについて、性能劣化が発生したか否かを判定する。判定結果が肯定的である場合、処理はステップS37に進む。判定結果が否定的である場合、本予兆検証処理が終了する。この判定結果が肯定的であるということは、管理プログラム4420が事前対策処理(図14)のステップS21で行った事前対策が十分に効果的でなかったことを意味する。
 ステップS37にて、予兆検証プログラム4440は、検出された予兆と、当該予兆に対して管理プログラム4420が実行した事前対策の内容と、当該事前対策を実行した結果(効果)とを対策効果テーブル4570(図10)に記録する。管理プログラム4420が事前対策処理(図14)のステップS21において、事前対策を実行する際に対策効果テーブル4570を参照し、前回実施した事前対策で良い効果を得られなかった場合(効果が「OK」でなかった場合)には、事前対策の方法を変更するようにしても良い。
 この後、予兆検証プログラム4440は、本予兆検証処理を終了する。
(1-4)本実施の形態の効果
 以上のように本実施形態の計算機システム1000では、管理サーバ4000が、アプリケーション5111,5122,5134の稼働データを定期的に収集し、収集した稼働データのうちの予め設定された条件を満たす稼働データをクラスタリングすることによりアプリケーション5111,5122,5134の性能劣化を検知するための予兆検知モデルを生成する。
 また管理サーバ4000は、生成した予兆検知モデルと、アプリケーション5111,5122,5134の最新の稼働データとに基づいて当該アプリケーション5111,5122,5134の性能劣化の予兆の有無を判定し、かかる予兆を検知した場合には、そのアプリケーション5111,5122,5134のインスタンスの中から性能劣化を防止するための所定の事前対策(インスタンスのスケールアウト)を実施するインスタンスと、当該事前対策を実施しないインスタンスとを選択して、前者のインスタンスに事前対策を実施する。
 また管理サーバ4000は、その後、事前対策を実施しなかったインスタンスの稼働データを所定期間監視し、当該稼働データに基づいてそのインスタンスの性能劣化を検出しなかった場合、つまり予兆が正しくないと判断した場合には、かかる予兆を検出したときの稼働データを予兆検知モデルに含めないように予兆検知モデルを修正する。
 従って、本実施形態の管理サーバ4000によれば、予兆検知の正否を検証しながら予兆検知モデルの精度を向上させることができるため、精度の高い予兆検知を行うことができる。
 また管理サーバ4000は、かかる事前対策を実施しなかったインスタンスの稼働データに基づいてそのインスタンスの性能劣化を検出した場合、つまり予兆が正しいと判断した場合には、アプリケーション性能を変化させる外的要因によって予兆が検知されたか否かを判定し、外的要因によって予兆が出ていない場合には、アプリケーション問題管理テーブル4560にその現象及び条件等をアプリケーション5111,5122,5134の実装上の問題として登録する。
 従って、本実施形態の管理サーバ4000によれば、例えば、アプリケーション問題管理テーブル4560に登録された問題(アプリケーションの実装上の問題)の内容をユーザからの要求に応じて管理サーバ4000,4000B等に表示させ得るようにすることによって、通常は気付きにくいアプリケーションの実装上の問題をユーザに認識させることができ、結果としてアプリケーション5111,5122,5134の品質の向上を期待することができる。
(2)第2の実施形態
 次に、本発明の第2の実施形態について説明する。
 図16は、第1の実施形態の管理サーバ4000に代えて図1の計算機システム1に適用される第2の実施形態の管理サーバ4000Bの構成例を示す。本実施形態の管理サーバ4000Bと、第1の実施形態の管理サーバ4000との差異は以下の(A)~(E)である。
(A)本実施形態のアプリケーション稼働データクラスタテーブル4540Bの構成が、第1の実施形態のアプリケーション稼働データクラスタテーブル4540(図7)の構成と異なる点
(B)管理プログラム4420Bにより実行されるアプリケーション監視処理が、図12について上述した第1の実施形態の管理プログラム4420により実行されるアプリケーション監視処理と異なる点
(C)本実施形態の予兆検知プログラム4430Bにより実行される予兆検知処理が、図13について上述した第1の実施形態の予兆検知プログラム4430により実行される予兆検知処理フローと異なる点
(D)本実施形態の予兆検証プログラム4440Bにより実行される予兆検証処理が、図15について上述した第1の実施形態の予兆検証プログラム4440により実行される予兆検証処理と異なる点
(E)管理プログラム4420Bが、図18について後述する初期アプリケーション稼働データクラスタ決定処理を実行する機能を有している点
 これらの差異点以外は第1の実施形態と同様の構成及び処理であるため説明は省略する。
 図17は、本実施形態によるアプリケーション稼働データクラスタテーブル4540Bの構成例を示す。アプリケーション稼働データクラスタテーブル4540Bと、第1の実施形態におけるアプリケーション稼働データクラスタテーブル4540との差異は、アプリケーション稼働データクラスタテーブル4540Bがリビジョン欄4548を備える点である。そしてリビジョン欄4548には、アプリケーション稼働データクラスタのリビジョンを示す情報が格納される。なお、アプリケーション稼働データクラスタのリビジョンは、図20について後述する本実施形態の予兆検証処理のステップS32Bにおいて増加される。詳細については後述する。また、本実施形態においては「リビジョン」という言葉は「バージョン」と同義であり、アプリケーション稼働データクラスタのリビジョンをバージョンと言い換えても良い。本実施例では、アプリケーションのバージョンとの混同を避けるため、アプリケーション稼働データクラスタに対しては「リビジョン」という言葉を用いる。
 この差異点以外は、アプリケーション稼働データクラスタテーブル4540Bとアプリケーション稼働データクラスタテーブル4540とは同様であるため、アプリケーション稼働データクラスタテーブル4540Bの他の欄の説明は省略する。
 図12との対応部分に同一符号を付して示す図18は、図12のアプリケーション監視処理に代えて管理プログラム4420Bにより実行される本実施形態のアプリケーション監視処理の処理手順を示す。第1の実施形態の管理プログラム4420により実行されるアプリケーション監視処理(図12)との差異は、ステップS5Bの処理内容がステップS5の処理内容と異なる点である。本実施形態のアプリケーション監視処理は、この点以外は第1の実施形態のアプリケーション監視処理と同様のため、ステップS5B以外の説明は省略する。
 管理プログラム4420Bは、ステップS5Bにて、アプリケーションの稼働データをクラスタリングし、各クラスタの情報(すなわち予兆検知モデルの情報であり、以下、これをクラスタ情報とも呼ぶ)をアプリケーション稼働データクラスタテーブル4540Bの最新のリビジョンに対応するクラスタID欄4545、クラスタ中心欄4546及び標準偏差欄4547に格納する。例えば図17の例では、「アプリA」のバージョン「1.0」には「リビジョン1」と「リビジョン2」の2つのクラスタ情報が格納されている。この場合、管理プログラム4420Bは最新のリビジョンである「リビジョン2」に、ステップS5Bで生成したクラスタの情報を格納する。このとき、古いリビジョンである「リビジョン1」のクラスタ情報は、変更や上書き等されずにそのまま残される。
 図13との対応部分に同一符号を付して示す図19は、図13の予兆検知処理に代えて予兆検知プログラム4430Bにより実行される本実施形態の予兆検知処理の処理手順を示す。第1の実施形態の予兆検知プログラム4430により実行される予兆検知処理(図13)との差異は、ステップS11Bの処理内容がステップS11の処理内容と異なる点である。本実施形態の予兆検知処理は、この点以外は第1の実施形態の予兆検知処理と同様のため、ステップS11B以外の説明は省略する。
 ステップS11Bにて、予兆検知プログラム4430Bは、アプリケーション稼働データクラスタテーブル4540Bを参照し、該当アプリの稼働データクラスタの最新のリビジョンの情報を取得する。
 図15との対応部分に同一符号を付して示す図20は、図15の予兆検証処理に代えて予兆検証プログラム4440Bにより実行される本実施形態の予兆検証処理の処理手順を示す。第1の実施形態の予兆検証プログラム4440により実行される予兆検証処理(図15)との差異は、ステップS32Bの処理内容がステップS32の処理内容と異なる点である。本実施形態の予兆検証処理は、この点以外は第1の実施形態の予兆検証処理と同様のため、ステップS32B以外の説明は省略する。
 予兆検証プログラム4440Bは、ステップS32Bにて、アプリケーション稼働データクラスタテーブル4540Bを参照し、該当アプリケーションの稼働データクラスタの最新のリビジョンの情報をコピーし、リビジョンを1つ上げる。これを新たな最新リビジョンとし、そのクラスタ情報にて、図19の予兆検知処理のステップS12で外れ値として検出された稼働データを、最近傍の稼働データクラスタに含めるように修正する。
 例えば図17の例では、「アプリA」のバージョン「1.0」には「リビジョン1」と「リビジョン2」の2つのクラスタ情報が格納されている。この場合、予兆検証プログラム4440Bは、最新のリビジョンであるリビジョン2のクラスタ情報をコピーし、「リビジョン3」としてアプリケーション稼働データクラスタテーブル4540Bに格納する。そして新たな最新リビジョンである「リビジョン3」のクラスタ情報において、ステップS12で外れ値として検出された稼働データを、最近傍の稼働データクラスタに含めるように修正する。このとき、「リビジョン1」や「リビジョン2」のクラスタ情報は、変更や上書き等されずにそのまま残される。
 図21は、本実施形態の管理プログラム4420Bがアプリケーションの新しいバージョンがデプロイされた際に、その初期アプリケーション稼働データクラスタ(初期予兆検知モデル)を決定する処理(以下、これを初期アプリケーション稼働データクラスタ決定処理と呼ぶ)の処理手順を示す。
 本実施形態において、本初期アプリケーション稼働データクラスタ決定処理は、管理プログラム4420Bが計算機システムのユーザからアプリケーションの新しいバージョンをデプロイする要求を受けた際に開始されるものとするが、これに限らず他の方法で開始されても良い。
 管理プログラム4420Bは、まずステップS40にて、アプリケーションの新バージョンをITインフラストラクチャ5000上にデプロイする。このとき、すでにデプロイされて稼働している旧バージョンのアプリケーションもそのまま残す。そして、旧バージョンのアプリケーションに対するユーザリクエストの一部又は全部が新旧両方のアプリケーションに到達するように、ルータやロードバランサを用いて制御する。新旧アプリケーションを併用した運用が一定期間過ぎた後、ユーザの要求に応じて旧バージョンのアプリケーションを削除し、新バージョンのアプリケーションのみでユーザリクエストを処理するように変更しても良い。また、例えば新バージョンのアプリケーションにおいて不具合があることが判明した場合には、ユーザの要求に応じて新バージョンのアプリケーションを削除し、旧バージョンのアプリケーションのみでユーザリクエストを処理するように変更しても良い。
 続くステップS41にて、管理プログラム4420Bは、新バージョンのアプリケーションに対する図18について上述したアプリケーション監視処理を開始する。このとき、新バージョンのアプリケーションにおいては、アプリケーション稼働データクラスタテーブル4540B(図17)にレコードがまだ存在しないため、ステップS2(図18)で各メトリクス空間の条件が取得できない。この結果、図18のアプリケーション監視処理のステップS4の判定は常に否定的となる。
 ステップS42にて、管理プログラム4420Bは、アプリケーション稼働データテーブル4530を参照し、新旧アプリの最新の稼働データを取得する。
 ステップS43にて、管理プログラム4420Bは、アプリケーション稼働データクラスタテーブル4540Bから、旧バージョンのアプリケーションの全てのリビジョンのクラスタ情報(予兆検知モデル)を取得する。
 そして管理プログラム4420Bは、取得したこれら旧バージョンのアプリケーションの全てのリビジョンのクラスタ情報を用いて、ステップS44及びステップS45において、旧バージョンの前記アプリケーションの前記サービスレベルの低下の予兆の判定と、新バージョンの前記アプリケーションの前記サービスレベルの低下の予兆の判定とをそれぞれ行う。
 実際上、管理プログラム4420Bは、ステップS44にて、新旧両バージョンのアプリケーションに対して、旧バージョンのアプリケーションの全てのリビジョンのクラスタ情報を用いて、最新の稼働データと稼働データクラスタを比較し、最近傍クラスタの中心からの距離Lを算出する。
 また管理プログラム4420Bは、ステップS45にて、新旧両バージョンのアプリケーションに対して、各リビジョンのクラスタについて、距離Lが標準偏差σのN倍より大きいか否か(つまり「外れ値」であるか否か)を判定する。
 続くステップS46にて、管理プログラム4420Bは、新旧両バージョンのアプリケーションにおける判定結果を比較し、判定結果が一致したリビジョンのうちの最新のリビジョンを特定する。例えば図22に示すような判定結果が得られたとする。この図22では、リビジョンが「1」~「3」の3つのクラスタ情報(予兆検知モデルの情報)がアプリケーション稼働データクラスタテーブル4540Bに登録されており、アプリケーション5111,5122,5134の「バージョン1」が旧バージョン、「バージョン2」が新バージョンを表している。また図22において、「True」は距離Lが標準偏差σのN倍より大きい(つまり「外れ値」である)ことを意味し、「False」は距離Lが標準偏差σのN倍以下であることを意味する。この結果、新旧両バージョンのアプリケーション5111,5122,5134における判定結果において、判定結果が一致した最新のリビジョンは「リビジョン2」と特定される。
 ステップS47にて、管理プログラム4420Bは、該当リビジョンのクラスタ情報(予兆検知モデル)を、新バージョンのアプリケーション5111,5122,5134の初期クラスタ情報(初期の予兆検知モデル)としてアプリケーション稼働データクラスタテーブル4540B(図17)に登録する。上述の例では、新バージョンのアプリケーション5111,5122,5134の初期クラスタ情報は、旧バージョンのアプリケーション5111,5122,5134のクラスタ情報の「リビジョン2」がコピーされたものとなる。
 以上のように本実施形態の管理サーバ4000Bでは、アプリケーション5111,5122,5134のリビジョンごとの予兆検知モデルを管理しておき、新しいバージョンのアプリケーション5111,5122,5134がデプロイされた際に、新旧両バージョンのアプリケーション5111,5122,5134に対して、旧バージョンのアプリケーション5111,5122,5134の全てのリビジョンの予兆検知モデルを用いてそれぞれ予兆検知を行い、結果が一致したリビジョンの予兆検知モデルのうちの最新の予兆検知モデルを新バージョンのアプリケーション5111,5122,5134の初期予兆検知モデルとして採用する。
 従って、本実施形態の管理サーバ4000Bによれば、アプリケーション5111,5122,5134がバージョンアップした際に、新しいバージョンのアプリケーション5111,5122,5134にとって好適なアプリケーション稼働データクラスタ(予兆検知モデル)を、旧バージョンのアプリケーション5111,5122,5134から引き継ぐことができる。かくするにつき、本実施形態によれば、アプリケーション5111,5122,5134がバージョンアップした場合においても、精度の高い予兆検知を行うことができる。
(3)他の実施形態
 なお上述の第1及び第2の実施形態においては、予兆検証処理(図15、図20)のステップS31において、事前対策を実施しないインスタンスとして選択されたインスタンスについて性能劣化が発生したか否かを判定する判定手法として、予兆検知処理(図13)のステップS11~ステップS13について上述した方法と同様に判定する手法や、事前対策を実施したインスタンスの稼働データと、事前対策を実施していないインスタンスの稼働データとの比較結果に基づいて判定する手法を適用する場合について述べたが、本発明はこれに限らず、この他種々の手法を広く適用することができる。
 また上述の第1の実施形態においては、アプリケーションの稼働データを収集する稼働データ収集部と、サービスレベルに関して予め設定された条件を満たす稼働データをクラスタリングすることにより、稼働データのデータ値と、サービスレベルとの相関を表す相関モデルを生成する相関モデル生成部と、アプリケーションのサービスレベルの低下の予兆が検知された場合に、アプリケーションのインスタンスの中から、当該サービスレベルの低下を防止するための所定の事前対策を実施しない第1のインスタンスと、当該事前対策を実施する第2のインスタンスとをそれぞれ選択し、第2のインスタンスに事前対策を実施する事前対策部とを同じ1つの管理プログラム4420により構成し、上述の第2の実施形態においては、かかる稼働データ収集部、相関モデル生成部及び事前対策部に加えて、前記予兆検証部により修正された前記相関モデルのリビジョンごとの情報をそれぞれ管理する相関モデル管理部とを同じ1つの管理プログラム4420Bにより構成するようにした場合について述べたが、本発明はこれに限らず、管理プログラム4420,4420Bを、かかる稼働データ収集部、相関モデル生成部、事前対策部及び相関モデル管理部の機能をそれぞれ有する複数のプログラムに分割して形成するようにしても良い。
 本発明は、アプリケーションのサービスレベルの低下の予兆を検知する予兆検知装置に適用して好適なものである。
 1000……計算機システム、2000,3000……クラウド、4000,4000B……管理サーバ、5000……ITインフラストラクチャ、5100,5100A~5100C……コンピュートサーバ、511,5122,5134……アプリケーション、4410……セルフサービスポータルプログラム、4420,4420B……管理プログラム、4430,4430B……予兆検知プログラム、4440,4440B……予兆検証プログラム、4450……アプリケーション問題管理プログラム、4510……ITインフラストラクチャ構成テーブル、4520……アプリケーション構成テーブル、4530……アプリケーション稼働データテーブル、4540,4540B……アプリケーション稼働データクラスタテーブル、4550……負荷分散設定テーブル、4560……アプリケーション問題管理テーブル、4570……対策効果テーブル、4410A……メトリクス空間設定画面。

Claims (10)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2017/008986 WO2018163280A1 (ja) 2017-03-07 2017-03-07 予兆検知装置及び予兆検知方法
JP2019504165A JP6722345B2 (ja) 2017-03-07 2017-03-07 予兆検知装置及び予兆検知方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/008986 WO2018163280A1 (ja) 2017-03-07 2017-03-07 予兆検知装置及び予兆検知方法

Publications (1)

Publication Number Publication Date
WO2018163280A1 true WO2018163280A1 (ja) 2018-09-13

Family

ID=63449080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/008986 WO2018163280A1 (ja) 2017-03-07 2017-03-07 予兆検知装置及び予兆検知方法

Country Status (2)

Country Link
JP (1) JP6722345B2 (ja)
WO (1) WO2018163280A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2020261514A1 (ja) * 2019-06-27 2020-12-30
JP2022061781A (ja) * 2020-10-07 2022-04-19 株式会社日立製作所 債務管理支援方法および債務管理支援装置
TWI767326B (zh) * 2019-09-24 2022-06-11 日商國際電氣股份有限公司 基板處理裝置、半導體裝置的製造方法、及預兆偵測程式

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006302249A (ja) * 2005-03-23 2006-11-02 Hitachi Ltd 管理コンピュータの制御方法、及びサーバの制御方法
JP2008204134A (ja) * 2007-02-20 2008-09-04 Hitachi Electronics Service Co Ltd 異常兆候検出対処システム
JP2014102661A (ja) * 2012-11-19 2014-06-05 Fujitsu Ltd 適用判定プログラム、障害検出装置および適用判定方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006302249A (ja) * 2005-03-23 2006-11-02 Hitachi Ltd 管理コンピュータの制御方法、及びサーバの制御方法
JP2008204134A (ja) * 2007-02-20 2008-09-04 Hitachi Electronics Service Co Ltd 異常兆候検出対処システム
JP2014102661A (ja) * 2012-11-19 2014-06-05 Fujitsu Ltd 適用判定プログラム、障害検出装置および適用判定方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2020261514A1 (ja) * 2019-06-27 2020-12-30
WO2020261514A1 (ja) * 2019-06-27 2020-12-30 日本電信電話株式会社 割付制御装置、割付制御方法、および、割付制御プログラム
JP7315000B2 (ja) 2019-06-27 2023-07-26 日本電信電話株式会社 割付制御装置、割付制御方法、および、割付制御プログラム
TWI767326B (zh) * 2019-09-24 2022-06-11 日商國際電氣股份有限公司 基板處理裝置、半導體裝置的製造方法、及預兆偵測程式
JP2022061781A (ja) * 2020-10-07 2022-04-19 株式会社日立製作所 債務管理支援方法および債務管理支援装置
JP7365990B2 (ja) 2020-10-07 2023-10-20 株式会社日立製作所 債務管理支援方法および債務管理支援装置

Also Published As

Publication number Publication date
JP6722345B2 (ja) 2020-07-15
JPWO2018163280A1 (ja) 2019-06-27

Similar Documents

Publication Publication Date Title
US11182220B2 (en) Proactive high availability in a virtualized computer system
US11379341B2 (en) Machine learning system for workload failover in a converged infrastructure
US11016836B2 (en) Graphical user interface for visualizing a plurality of issues with an infrastructure
CN107005438B (zh) 生成动态地可缩放网络负载的方法、系统和介质
US9760420B1 (en) Fleet host rebuild service implementing vetting, diagnostics, and provisioning pools
US10915314B2 (en) Autonomous upgrade of deployed resources in a distributed computing environment
JP6114818B2 (ja) 管理システム及び管理プログラム
US20200026446A1 (en) Establishing and maintaining data apportioning for availability domain fault tolerance
US9852007B2 (en) System management method, management computer, and non-transitory computer-readable storage medium
US11106562B2 (en) System and method for detecting anomalies based on feature signature of task workflows
WO2016040699A1 (en) Computing instance launch time
US9696982B1 (en) Safe host deployment for a heterogeneous host fleet
US20150019722A1 (en) Determining, managing and deploying an application topology in a virtual environment
WO2018163280A1 (ja) 予兆検知装置及び予兆検知方法
US10360614B1 (en) Assessing and rating deployments of resources
US20140181598A1 (en) Information processing method, information processing device and recording medium
US20130247037A1 (en) Control computer and method for integrating available computing resources of physical machines
US10229005B2 (en) Pattern based configuration method for minimizing the impact of component failures
US20220374528A1 (en) Evaluation apparatus, evaluation system, evaluation method, and program
US9641384B1 (en) Automated management of computing instance launch times
US8798982B2 (en) Information processing device, information processing method, and program
US11755433B2 (en) Method and system for health rank based virtual machine restoration using a conformal framework
JP7532882B2 (ja) 障害判定装置、障害判定方法、及び、障害判定プログラム
US11507469B2 (en) Method and system for risk score based asset data protection using a conformal framework
US20240289441A1 (en) Service impairment isolation in information processing system environment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17899272

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019504165

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17899272

Country of ref document: EP

Kind code of ref document: A1