JP2013161305A - リソース監視装置、リソース監視システム、リソース監視方法及びリソース監視プログラム - Google Patents

Abstract

【課題】複数リソースを利用するサービスにおいて、異常リソースを適切に特定する。
【解決手段】連携してサービスを提供する複数のリソース各々に関する複数の情報を異なる管理装置から取得し、取得した複数の情報間の相関関係と所定の相関関係との差が、許容値よりも大きくなったリソースを異常リソース候補として抽出し、前記サービスにおける複数のリソースの構成を示す構成情報に基づいて、前記異常リソース候補の中から、前記異常リソース候補に異常を発生させる原因となったリソースである異常原因リソースを特定する。
【選択図】図１

Description

本発明は、リソース監視サーバ、リソース監視システム、リソース監視方法およびリソース監視プログラムに関する。

近年、インタークラウドシステムが注目されている。インタークラウドシステムは、複数のクラウドシステムのリソースをシステム縦断的に利用可能とする技術である。インタークラウドシステムにおいては、複数の別個のクラウドを相互に連携させて、各クラウドが管理するリソースを、一つのシステムのリソースであるかのように、ユーザに提供する。

インタークラウドシステムにおいては、ユーザは、提供元が異なるリソースを組み合わせて利用する。例えば、事業者Ａが提供するクラウドのネットワークリソースと事業者Ｂが提供するクラウドのサーバリソースとを組み合わせて利用する。また、事業者は仮想化技術を適用して、物理的リソースを複数の論理的リソースに分割して、ユーザに提供することがある。この場合、複数のユーザが、実際には同一の物理的リソースを共用することになる。このように提供元が異なる複数リソースを組み合わせて利用するユーザは、それらのリソースを利用して、エンドユーザにアプリケーションサービス等のサービスを提供することもある。かかるインタークラウドシステムにおけるリソースの適切な管理のために、様々な手法が提案されている。

例えば、インタークラウドにおいて、各テナントユーザに複数のクラウドのリソースを適正に割り当てるためのアルゴリズムが提案されている。また、システムを適正に運用するために、時間的相関性のない変更イベントと故障とを相関付けて、システムにおいて発生した故障の根本原因を特定する技術が提案されている。さらに、ログを分析することで分散型システム内の構成要素間の依存関係を抽出する技術が開示されている。

胡博、波戸邦夫、村田祐一、村山純一著、「インタークラウド環境におけるリソース割当アルゴリズムの提案」、信学技報、電子情報通信学会技術研究報告、110（449）、157−162、2011−02−24、社団法人電子情報通信学会 Manoj K. Agarwal, Venkateswara R. Madduri, "Correlating Failures with Asynchronous Changes for Root Cause Analysis in Enterprise Environments", pp. 517-526, 2010 IEEE/IFIP International Conference on Dependable Systems & Networks (DSN), 2010 Jian-Guang Lou, Qiang Fu, Yi Wang, Jiang Li, "Mining Dependency in Distributed Systems Through Unstructured Logs Analysis", the 2nd Workshop on Analysis of System Logs, pp. 91-96, Oct. 2010

しかしながら、インタークラウドにおいては、各クラウドは異なる事業者によって管理され、リソースの管理も異なるポリシに基づいて行われる。そのため、いずれかのクラウドのリソースに異常が発生しても、インタークラウド全体を管理する装置には、通知が送られず、異常発生箇所を特定できない場合がある。

例えば、ユーザが利用しているサービスが、事業者Ａが管理するクラウドシステムが提供するリソースを利用したアプリケーションと、事業者Ｂが管理するクラウドシステムが提供するリソースを利用したデータベースとによって提供されているとする。この場合、事業者Ａと事業者Ｂとは、それぞれ異なるポリシに基づいて、不具合発生時の警告等の通知を、インタークラウドを管理する装置に送信する。しかし、各事業者が他の事業者に対しては非開示としている不具合が発生した場合には、通知は送られない。そのため、インタークラウドを管理する装置は、システムに性能劣化等の不具合が発生しても、不具合の原因となった箇所を特定することができないことがある。そのため、不具合の原因の特定や問題箇所の把握が遅れることになる。

開示の実施の形態は、上記に鑑みてなされたものであって、故障箇所を適正に特定することを可能にすることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、連携してサービスを提供する複数のリソース各々に関する複数の情報を異なる管理装置から取得し、取得した複数の情報間の相関関係と所定の相関関係との差が、許容値よりも大きくなったリソースを異常リソース候補として抽出し、前記サービスにおける複数のリソースの構成を示す構成情報に基づいて、前記異常リソース候補の中から、前記異常リソース候補に異常を発生させる原因となったリソースである異常原因リソースを特定することを特徴とする。

開示するリソース監視装置、リソース監視システム、リソース監視方法及びリソース監視プログラムは、故障箇所を適正に特定することを可能にするという効果を奏する。

図１は、実施例１に係るリソース監視システムの構成の一例を示す図である。 図２−１は、実施例１に係る構成情報の構造の一例を示す図である。 図２−２は、実施例１に係る構成情報を説明するための図である。 図３は、実施例１における異常リソース候補の抽出処理の流れの一例を示すフローチャートである。 図４は、実施例１における異常原因リソースの特定処理の流れの一例を示すフローチャートである。 図５は、実施例２に係るインタークラウドサーバの構成の一例を示す図である。 図６は、実施例２に係るインタークラウドシステムにおける、リソースとサービスとの関係の一例を示す図である。 図７は、実施例２に係る管理装置と、サーバ管理装置と、リソースと、サービスとの関係の一例を示す図である。 図８は、実施例２に係る相関関係記憶部に格納される情報の一例を示す図である。 図９は、実施例２に係る構成情報の一例を示す図である。 図１０は、実施例２に係る異常リソース候補リストの一例を示す図である。 図１１−１は、実施例２に係る管理装置から送信される情報の構成の一例を示す図である。 図１１−２は、実施例２に係る管理装置から送信される情報の構成の一例を示す図である。 図１２−１は、実施例２に係るサービス管理装置から送信される情報について説明するための図である。 図１２−２は、実施例２に係るサービス管理装置から送信される情報の構成の一例を示す図である。 図１３は、実施例２に係るインタークラウドサーバにおける異常リソース検出処理の流れの一例を示す図である。 図１４は、実施例２に係る相関関係算出処理の流れの一例を示す図である。 図１５は、実施例２に係る異常リソース候補抽出処理の流れの一例を示すフローチャートである。 図１６は、実施例２に係る自己相関関数を示す一次近似曲線と許容誤差の一例を示す図である。 図１７は、実施例２に係る異常原因リソース特定処理の流れの一例を示す図である。 図１８は、実施例２に係る異常原因リソース特定処理を説明するための図である。 図１９は、実施例２の変形例１を示す図である。 図２０は、実施例３に係るインタークラウドサーバの概略図である。 図２１は、実施例３に係る異常リソース検出処理の流れの一例を説明するための図である。 図２２は、インタークラウドサーバによる一連の処理を実行するプログラムであるリソース監視プログラムによる情報処理が、コンピュータを用いて具体的に実現されることを示す図である。

以下に、本発明に係るリソース監視装置、リソース監視システム、リソース監視方法及びリソース監視プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［実施例１に係るリソース監視システムの構成］
図１は、実施例１に係るリソース監視システムの構成の一例を示す図である。実施例１に係るリソース監視システムは、リソース監視装置と、複数の管理装置と、複数のリソースにより実現される。図１中、リソース監視装置１は、複数の管理装置２−１〜２−７と接続される。複数の管理装置２−１〜２−７のうち、管理装置２−１〜２−５は、それぞれリソース３−１〜３−５と接続される。また、管理装置２−６〜２−７は、リソース３−１〜３−５のうち、複数のリソースと接続される。図１中、管理装置２−６は、リソース３−４および３−５と接続され、管理装置２−７は、リソース３−１〜３−３と接続される。管理装置２−１〜２−５は、それぞれが接続されたリソースを管理する。例えば、管理装置２−１〜２−５は、それぞれが接続されたリソース３−１〜３−５が実行する処理に関する情報を検出する。管理装置２−６および２−７は、それぞれが接続されたリソース３−４〜３−５、３−１〜３−３によって提供されているサービスを管理する。例えば、管理装置２−６および２−７は、それぞれが接続されたリソース３−４〜３−５、３−１〜３−３によって提供されているサービスの処理に関する情報を検出する。

実施例１のリソース監視装置１は、例えば、インタークラウドサーバである。また、実施例１の管理装置２−１〜２−５は、例えば、リソースを提供する事業者、例えばＣＳＰ（Cloud Service Provider）事業者がリソースを管理するために使用する管理装置、例えば、データセンタオペレーションシステム（DC-OPS）等である。また、実施例１の管理装置２−６、２‐７は、例えば、サービスを提供するＡＳＰ（Application Service Provider）事業者がサービス管理のために使用するサービスプロバイダオペレーションシステム（SP-OPS）等である。また、実施例１のリソースは、例えば、網リソース、計算リソース、記憶リソース等である。なお、図１には、７つの管理装置と５つのリソースを示すが、リソース監視装置に接続される管理装置の数および当該管理装置が管理するリソースの数は、図示される数に限定されるものではない。

リソース監視装置１は、制御部１１と記憶部１２とを備える。制御部１１は、リソース監視装置１において実行される、以下に説明する処理を制御する。記憶部１２は、リソース監視装置１における処理に使用される情報および処理の結果生成される情報を記憶する。例えば、記憶部１２は、所定の相関関係および構成情報を各リソースに対応づけて記憶する。

リソース監視装置１は、各リソースに関する複数の情報を、リソースを管理する複数の管理装置２−１〜２−７から取得する。例えば、リソース監視装置１は、管理装置２−１からリソース３−１の情報を取得する。また、リソース監視装置１は、管理装置２−７からリソース３−１〜３−３の情報を取得する。そして、リソース監視装置１は、リソース３−１に対応付けて記憶部１２に格納した相関関係と、リソース３−１について取得した２つの情報とを照合する。取得した２つの情報間の相関関係と記憶部に格納した相関関係との差が、許容値を上回る場合、リソース監視装置１は、リソース３−１を異常が発生した可能性のある異常リソース候補として抽出する。ここで、異常リソース候補とは、異常、例えば物理的インタフェースの破損等の故障が生じている可能性のあるリソースとして抽出されるリソースである。また、実施例１では、相関関係は特に限定されず、リソースに関する複数の情報間の相関関係であればよいものとする。

リソース監視装置１は、さらに、リソース３−２の情報を管理装置２−２から取得する。また、リソース監視装置１は、管理装置２−７からリソース３−１〜３−３の情報を取得する。そして、リソース監視装置１は、リソース３−２に対応付けて記憶部１２に格納した相関関係と、リソース３−２について取得した２つの情報とを照合する。取得した２つの情報間の相関関係と記憶部に格納した相関関係との差が、許容値を上回る場合、リソース監視装置１は、リソース３−２を異常が発生した可能性のある異常リソース候補として抽出する。

上記処理を各リソースについて行い、一つのサービスに利用されている複数のリソースが異常リソース候補として抽出された場合、リソース監視装置１は、さらに、複数の異常リソース候補から異常原因リソースを特定する。異常原因リソースとは、複数のリソースが異常リソース候補として抽出された場合に、それらすべてのリソースに異常を発生させている原因と考えられるリソースである。

ここでは、リソース３−１とリソース３−２とが異常リソース候補として抽出されたとする。すると、リソース監視装置１は、まず、リソース３−１、３−２、３−３によって構成されているサービスの構成情報を記憶部１２から読み出す。

ここで、構成情報とは、リソース間の依存関係を示す情報である。例えば、構成情報は、一つのサービスを提供するためにリソースがどのように構成されているかを示す情報である。例えば、リソース３−１がユーザからのリクエストを受信するサーバであり、リソース３−２がリソース３−１であるサーバからのリクエストを転送するネットワークであり、リソース３−３が、転送されたリクエストを受信してデータを処理するサーバである場合を考える。この場合、リソース３−１とリソース３−２との間に接続関係が存在し、さらにリソース３−２とリソース３−３との間に接続関係が存在する。構成情報は、かかる接続関係を示す。また、上記の場合、リソース３−１〜３−３の間には一つのリクエストに対応して順次処理を行っていくという、順番関係がある。構成情報は、かかる処理順序を示すものであってもよい。

［構成情報の構造の一例］
図２−１を参照して、構成情報の構造の一例を示す。図２−１は、実施例１に係る構成情報の構造の一例を示す図である。図２−１中、構成情報は、各サービスを一意に識別するためのサービスＩＤ（Identifier）と、当該サービスにおいて利用されるリソース間の処理順序、接続関係等と、を対応づけることで構成されている。例えば、図２−１中、サービスＩＤ「０００１」に、処理順序「Ｗｅｂ１−ＡＰ１−ＤＢ１」「Ｗｅｂ１−ＡＰ１−ＤＢ２」「Ｗｅｂ２−ＡＰ２−ＤＢ２」が対応付けられている。この構成情報は、サービス「０００１」においては、リソースＩＤ「Ｗｅｂ１」のウェブと、リソースＩＤ「ＡＰ１」のアプリケーションと、リソースＩＤ「ＤＢ１」のデータベースとが、この順番に接続されて処理を行っていることを示す。例えば、図２−１のサービスＩＤ「０００１」のサービスにおけるリソース構成は、図２−２のようになる。

リソース監視装置１は、読み出した構成情報を参照して、リソース３−１と３−２とが接続関係を有しているか否かを判定する。すなわち、当該サービスのユーザがリクエストを入力し、リクエストに応じてリソース３−１および３−２の一方が処理を行った後に、さらにリソース３−１および３−２の他方が処理を行う、という関係が存在するか否かを判定する。リソース３−１および３−２の間に接続関係がなければ、リソース監視装置１は、リソース３−１と３−２の双方を異常原因リソースとして特定する。他方、両者間に接続関係があれば、当該サービスのユーザからのリクエストの処理順序が後のリソースを異常原因リソースとして特定する。

例えば、図２−１に示すサービス「０００１」の場合に、リソース「ＡＰ１」とリソース「ＤＢ１」とが異常リソース候補として抽出されたとする。この場合、リソース監視装置１は、構成情報を参照して、リソース「ＡＰ１」とリソース「ＤＢ１」との間に接続関係があるか否かを判定した上で、処理順序が後であるリソース「ＤＢ１」を異常原因リソースとして特定する。

［実施例１における異常リソース候補抽出処理の概要］
図３を参照し、実施例１のリソース監視装置１における異常リソース候補を抽出する処理の流れを説明する。図３は、実施例１における異常リソース候補の抽出処理の流れの一例を示すフローチャートである。

まず、リソース監視装置１は、一つのリソースＲ［ｎ］（ｎ＝ｋ、ｋは１以上の自然数）を選択する（ステップＳ３１）。そして、リソース監視装置１は、リソースＲ［ｎ］について複数の情報ｘ［ｎ］，ｙ［ｎ］を複数の管理装置から受信する（ステップＳ３２）。リソース監視装置１は、受信した情報ｘ［ｎ］と情報ｙ［ｎ］との相関関係と、記憶部１２にリソースＲ［ｎ］に対応付けて格納された所定の相関関係とを比較する（ステップＳ３３）。そして、リソース監視装置１は、比較の結果、情報ｘ［ｎ］と情報ｙ［ｎ］との相関関係と所定の相関関係との差が、許容値以下であるか否かを判定する（ステップＳ３４）。情報ｘ［ｎ］と情報ｙ［ｎ］との相関関係と所定の相関関係との差が、許容値以下である場合（ステップＳ３４、否定）、リソース監視装置１は、全てのリソースについて処理を行ったか否かを判定する（ステップＳ３５）。全てのリソースについて処理を終えていれば（ステップＳ３５、肯定）、処理を終了する。全てのリソースについて処理を終えていなければ（ステップＳ３５、否定）、次のリソースを選択し（ｎ＝ｋ＋１）（ステップＳ３６）、ステップＳ３２に戻る。情報ｘ［ｎ］と情報ｙ［ｎ］との相関関係と所定の相関関係との差が、許容値より大きい場合（ステップＳ３４、肯定）、リソース監視装置１は、リソースＲ［ｎ］を異常リソース候補として抽出する（ステップＳ３７）。抽出された異常リソース候補のリソースＩＤは、記憶部１２に格納する。そして、リソース監視装置１は、全てのリソースを処理したか否かを判定する（ステップＳ３８）。全てのリソースを処理したと判定した場合（ステップＳ３８、肯定）、リソース監視装置１は、処理を終了する。全てのリソースの処理を終えていないと判定した場合（ステップＳ３８、否定）、リソース監視装置１は、ステップＳ３６に戻って、次のリソースを選択する（ステップＳ３６）。

次に、図４を参照して、実施例１における異常原因リソースを特定する処理の流れの一例を説明する。図４は、実施例１における異常原因リソースの特定処理の流れの一例を示すフローチャートである。リソース監視装置１は、まず、記憶部１２を参照して、一つのサービスについて、複数の異常リソース候補が抽出されたか否かを判定する（ステップＳ４１）。複数の異常リソース候補が抽出されていないと判定した場合（ステップＳ４１、否定）、リソース監視装置１は、一つの異常リソース候補が抽出されたか否かを判定する（ステップＳ４４）。一つの異常リソース候補が抽出されていると判定すれば（ステップＳ４４、肯定）、当該異常リソース候補を異常原因リソースであると特定する（ステップＳ４５）。そして処理を終了する。他方、一つの異常リソース候補も抽出されていないと判定すれば（ステップＳ４４、否定）、そのまま処理を終了する。

他方、複数の異常リソース候補が抽出されていると判定すると（ステップＳ４１、肯定）、リソース監視装置１は、当該サービスに対応づけて記憶部１２に格納された構成情報を参照する（ステップＳ４２）。そして、リソース監視装置１は、構成情報において、処理順序が最も後の異常リソース候補を異常原因リソースとして特定し（ステップＳ４３）、処理を終了する。

［実施例１のリソース監視装置の効果］
上記のように、実施例１のリソース監視装置は、複数の管理装置から各リソースについての情報を受信し、情報間の相関関係を予め準備した所定の相関関係と比較し、両者の差が許容値より大きければ、当該リソースを異常リソース候補として抽出する。このため、一つの管理装置からの情報に基づいて、リソースにおける異常発生の有無を判定することができない場合であっても、異常が発生した可能性のあるリソースを適正に抽出することができる。このため、リソース管理において、故障箇所を適正に特定し、故障に迅速に対応することが可能になるという効果を奏する。また、実施例１のリソース監視装置によれば、複数の事業者からリソースの情報を取得している場合に、一つの事業者において非開示としている不具合が発生しても、複数の管理装置からの情報に基づいて、故障箇所を適正に特定することができるという効果を奏する。

また、実施例１のリソース監視装置は、さらに、一つのサービスについて複数の異常リソース候補が抽出された場合は、サービスの構成情報を参照して、異常原因リソースを特定する。このため、多数の異常リソース候補が抽出された場合であっても、複数のリソースにおいて異常を発生させる原因となっている異常原因リソースを適正に特定することができる。このため、リソース管理において、故障箇所を適正に特定し、故障に迅速に対応することが可能になるという効果を奏する。

なお、実施例１においては、管理装置２−１〜２−５がそれぞれ一つのリソースを管理し、管理装置２−６、２−７が複数リソースにより構成されるサービスを管理するものとして説明した。しかし、実施例１は、この例に限定されず、管理装置によって、一つのリソースについて複数の情報が検出されるシステムであれば、適用することができる。例えば、複数の管理装置がそれぞれ、サービスやリソース等からなる異なるレイヤーにおいてリソースを管理し情報を検出してもよい。また、一つの管理装置が、異なるレイヤーにおけるリソースの情報を複数検出してもよい。

図５は、実施例２に係るインタークラウドサーバの構成の一例を示す図である。図５に示すインタークラウドサーバ１００は、複数のクラウドシステムを連携させることによって実現されるインタークラウドシステムを管理する。例えば、インタークラウドサーバ１００は、インタークラウドシステムにより提供されるリソースを利用したサービスに不具合が生じた場合に、異常の発生したリソースを検出し、異常原因リソースを特定する。

実施例２では、インタークラウドサーバ１００が、ＳａａＳ（Software as a Service）、ＰａａＳ（Platform as a Service）、Ｈａａｓ（Hardware as a Service）、ＩａａＳ（Infrastructure as a Service）等の利用形態によって複数事業者からユーザに提供されるリソースの異常を検出し、異常原因リソースを特定することを想定している。ただし、本実施例は、これらの利用形態に限られず、異なる事業者が提供するリソースを組み合わせてユーザが利用するシステムにおいて、各事業者から何らかの理由で性能劣化情報を取得できない場合に適用することができる。また、リソースを提供する各事業者がリソースの提供のために利用する技術は特に限定されない。各事業者は、例えば、仮想化技術を利用してリソースを提供してもよいし、グリッドコンピューティング等を利用してもよい。

図５中、インタークラウドサーバ１００は、複数の管理装置２００と、サービス管理装置３００と接続される。インタークラウドサーバ１００は、管理装置２００に対して、当該管理装置２００が管理するリソースの情報を要求する通知を送信する。例えば、インタークラウドサーバ１００は、管理装置２００に対して、所定時点でのリソースの処理性能に関する性能情報を要求する通知を送信する。そして、管理装置２００は通知に応じて情報をインタークラウドサーバ１００に送信する。

インタークラウドサーバ１００は、同様に、サービス管理装置３００に対して、当該サービス管理装置３００が管理するサービスに関する情報を要求する通知を送信する。例えば、インタークラウドサーバ１００は、サービスにおいてリソースにかかる負荷の情報や、リソースによる処理の状況に関する情報を要求する。そして、インタークラウドサーバ１００は、当該サービス管理装置３００が要求に応じて送信する情報を受信する。

インタークラウドサーバ１００は、継続的に、管理装置２００およびサービス管理装置３００から送信される情報を受信し、複数の情報間の相関関係の変動を検出する。そして、情報間の相関関係と予め定められた所定の相関関係との差が、許容値よりも大きくなるとその情報に対応するリソース４００を異常リソース候補として抽出する。さらに、単一のサービスに利用されるリソース４００のうち、複数のリソース４００が異常リソース候補として抽出された場合、異常リソース候補の中から異常原因リソースを特定する。異常リソース候補の抽出処理および異常原因リソースの特定処理の詳細については、後述する。

管理装置２００は、インタークラウドサーバ１００及びリソース４００と接続される。管理装置２００は、リソース４００を管理する。管理装置２００は、インタークラウドサーバ１００からの通知に応じて、リソース４００の情報を検出し、インタークラウドサーバ１００に送信する。例えば、管理装置２００は、リソース４００の処理状況に関する情報を検出する。例えば、管理装置２００は、リソース４００のＣＰＵ（Central Processing Unit）使用率やメモリ使用率、レスポンスタイム等を検出する。

なお、一つのリソース４００を一つの管理装置２００が管理してもよく、複数のリソース４００をまとめて一つの管理装置２００が管理してもよい。通常、クラウドを提供する事業者ごとに異なる管理装置２００が設けられる。ただし、１事業者が提供するクラウド内のリソースについて、異なる種類のリソースごとに異なる管理装置２００を設けてもよい。例えば、ネットワークのリソースを管理する管理装置２００と、サーバのリソースを管理する管理装置２００とを設けてもよい。また、ひとつのデータセンタを一つの管理装置２００が管理するものとしてもよい。また、複数事業者が提供するクラウドを単一の管理装置２００が管理するものとしてもよい。また、異なるクラウドシステムのリソースを異なる管理装置２００が管理するものとしてもよく、異なるクラウドシステムのリソースを一つの管理装置２００がまとめて管理するものとしてもよい。図５では、異なる事業者が提供するリソースごとに一つの管理装置２００を設けるものとする。

サービス管理装置３００は、インタークラウドサーバ１００およびリソース４００と接続される。サービス管理装置３００は、所定のサービスを提供するユーザに割り当てられたリソース４００から構成されるサービスを管理する。例えば、リソース４００の中から所定のユーザに対して割り当てられたリソースによってデータベース（ＤＢ）やアプリケーション（ＡＰ）を含むサービスが構成される。サービス管理装置３００は、このようにして構成されたサービスの情報を検出する。そして、サービス管理装置３００は、検出した情報をインタークラウドサーバ１００に送信する。例えば、サービス管理装置３００は、インタークラウドサーバ１００からの通知に応じて、サービスにおいて各リソースにかかる負荷の情報を検出する。例えば、サービス管理装置３００は、各リソースが受信した１秒当たりのリクエストの数や１秒あたりのクエリの数等や、各リソースが転送した１秒当たりのリクエストの数や１秒あたりのクエリの数等を検出する。

リソース４００は、インタークラウドシステムにおいて利用される資源である。例えば、計算リソース、記憶リソース、網リソース等がリソースに該当する。例えば、計算リソースとしては、仮想マシン（Virtual Machine）、サーバ、ＣＰＵ（Central Processing Unit）、メモリ、ディスク等が挙げられる。また、記憶リソースとしては、ストレージ装置等が挙げられる。さらに網リソースとしては、ネットワーク、ローカルエリアネットワーク（ＬＡＮ：Local Area Network）、広域ネットワーク（ＷＡＮ：Wide Area Network）、光ファイバー、光パス、ＩＰネットワーク、イーサネット（登録商標）、トンネルネットワーク等が挙げられる。

リソース４００は、ユーザからの割当要求に応じて、割当要求を送信したユーザに割当られ、所定のサービスを提供するよう構成される。サービスは、リソース４００の中からユーザに割り当てられたリソースを、データベース（ＤＢ）、アプリケーション（ＡＰ）、ウェブ（ＷＥＢ）等として構成することで実現される（図６参照）。サービスは、エンドユーザ側からは独立したシステムと認識されるが、実際には複数のクラウドが提供するリソース４００によって構築されている。

図６を参照して、リソースとサービスとの関係についてさらに説明する。図６は、実施例２に係るインタークラウドシステムにおける、リソースとサービスとの関係の一例を示す図である。図６中、リソース４００によって構成されるシステムをクラウドリソース層として示す。また、リソース４００の中からサービスのために割り当てられたリソースを利用して構築されるシステムをサービス層として示す。図６中、クラウドリソース層は、異なる事業者が運営するデータセンタＤＣ１、ＤＣ２、ＤＣ３をネットワークＮＷによって接続することで構成されている。これらのリソースは、ユーザからの要求に応じてユーザが提供するサービスに適合するよう組み合わされ、サービスを構成する。例えば、図６のサービス層は、データベースＤＢ１，ＤＢ２とアプリケーションＡＰ１，ＡＰ２とウェブＷＥＢ１，ＷＥＢ２とから構成されている。データベースＤＢ１，ＤＢ２はそれぞれ、データセンタＤＣ１の物理マシン上に仮想的に構築される仮想マシンＶＭ１，ＶＭ２によって実現されている。また、アプリケーションＡＰ１，ＡＰ２は、データセンタＤＣ２内のリソースによって実現され、ＷＥＢ１，ＷＥＢ２は、データセンタＤＣ３内のリソースによって実現されている。また、ＡＰ１とＷＥＢ１とを接続するネットワークは、ネットワークＮＷによって実現されている。サービスを利用するエンドユーザは、サービス層を独立したシステムとして認識するが、実際にはクラウドリソース層内の複数の事業者が提供するリソースを組み合わせることで実現されている。

図７を参照し、実施例２における管理装置２００と、サーバ管理装置３００と、リソース４００と、サービスとの関係をさらに詳しく説明する。図７は、実施例２に係る管理装置２００と、サーバ管理装置３００と、リソース４００と、サービスとの関係の一例を示す図である。図７においては、インタークラウドサーバ１００は、複数のクラウドシステムのリソースを管理する６つの管理装置２００−１〜２００−６と接続される。管理装置２００−１〜２００−３はそれぞれ、リソースとしてサーバ４０１−１〜４０１−３、サーバ４０１−４〜４０１−６、サーバ４０１−７〜４０１−９を管理する。また、管理装置２００−４〜２００−６はそれぞれ、リソースとしてネットワーク４０２−１、４０２−２、４０２−３を管理する。

ユーザ端末５００−１〜５００−３は、それぞれが利用するサービスを構成するリソースと接続される。例えば、ユーザ端末５００−１は、管理装置２００−４が管理するネットワーク４０２−１を介して管理装置２００−３が管理するサーバ４０１−７と接続される。ユーザ端末５００−２は、管理装置２００−５が管理するネットワーク４０２−２を介して、管理装置２００−２が管理するサーバ４０１−５および管理装置２００−３が管理するサーバ４０１−９と接続される。ユーザ端末５００−３は、管理装置２００−６が管理するネットワーク４０２−３を介して、管理装置２００−１が管理するサーバ４０１−１および管理装置２００−２が管理するサーバ４０１−６と接続される。

図７において、ユーザ端末５００−１〜５００−３それぞれが利用するサービスは、異なる事業者、例えば、ＡＳＰ（Application Service Provider）事業者によって提供されているものとする。

図７中、インタークラウドサーバ１００はまた、サービス管理装置３００−１〜３００−３と接続される。サービス管理装置３００−１〜３００−３はそれぞれ、異なるＡＳＰ事業者により管理されているものとする。サービス管理装置３００−１は、ユーザ端末５００−１が利用するサービスを管理する。つまり、サービス管理装置３００−１は、ネットワーク４０２−１と、サーバ４０１−７によって実現されるサービスの性能、例えば、処理速度を検出する。同様に、サービス管理装置３００−２は、ネットワーク４０２−２、サーバ４０１−５、サーバ４０１−９によって実現されるサービスの性能を検出する。また、同様に、サービス管理装置３００−３は、ネットワーク４０２−３、サーバ４０１−１、サーバ４０１−６によって実現されるサービスの性能を検出する。

このように、管理装置２００は、リソース層における各リソースの状態を検出し、検出した情報をインタークラウドサーバ１００に送信する。また、サービス管理装置３００は、サービス層における各リソースの状態を検出し、検出した情報をインタークラウドサーバ１００に送信する。これによって、インタークラウドサーバ１００は、一つのリソースを異なる側面からみた複数の情報を取得することができる。

［実施例２に係るインタークラウドサーバの構成］
図５に戻って、インタークラウドサーバ１００の構成につきさらに詳細に説明する。インタークラウドサーバ１００は、通信部１０１、記憶部１１０及び制御部１２０を備える。通信部１０１は、インタークラウドサーバ１００と、その外部の装置との通信を行う。図５中、通信部１０１は、管理装置２００とサービス管理装置３００とからの情報を受信し、インタークラウドサーバ１００内の機能部から出力される情報を、管理装置２００およびサービス管理装置３００に送信する。記憶部１１０は、インタークラウドサーバ１００内での処理に利用される情報や処理の結果生成された情報を記憶する。例えば、記憶部１１０は、異常リソース候補として抽出されたリソースのリソースＩＤや、異常原因リソースの特定のために使用される構成情報を記憶する。制御部１２０は、インタークラウドサーバ１００内で実行される各種処理を制御する。例えば、制御部１２０は、インタークラウドサーバ１００内の異常リソース候補の検出および異常原因リソースの特定のための処理を制御する。記憶部１１０および制御部１２０における処理の詳細については、以下にさらに詳細に説明する。

［実施例２に係る記憶部の構成］
記憶部１１０は、インタークラウドサーバ１００内での異常リソース候補の検出や異常原因リソースの特定のための処理に使用する情報を記憶する。記憶部１１０は、相関関係記憶部１１１と構成情報記憶部１１２と異常リソース候補記憶部１１３とを備える。相関関係記憶部１１１は、リソースが正常であるか否かを判定するための基準値として、正常時のリソース４００に関する複数の情報間の相関関係を格納する。構成情報記憶部１１２は、各サービスにおいて利用する複数リソース間の関係を示す構成情報を格納する。異常リソース候補記憶部１１３は、後述する抽出部１２３が抽出した異常リソース候補を示す異常リソース候補リストを格納する。

［相関関係の概要］
相関関係は、正常時の各リソース４００について、管理装置２００やサービス管理装置３００から送信される複数情報間の関係を示す情報である。例えば、管理装置２００が検出した、リソースにおけるＣＰＵ使用率と、サービス管理装置３００が検出した、当該リソースに対する１秒当たりのリクエスト数との相関関係である。実施例２では、正常時のリソース４００に関する各情報間の相関関係を予め算出して、相関関係記憶部１１１に記憶しておく。

図８を参照して、相関関係記憶部１１１に格納される相関関係について説明する。図８は、実施例２に係る相関関係記憶部１１１に格納される情報の一例を示す図である。図８に示すように、相関関係記憶部１１１は、各リソースを一意に識別するリソースＩＤと当該リソースを利用するサービスのサービスＩＤとに対応付けて、相関関係として、リソースに関する情報間の自己相関関数と許容誤差の値とを格納する。また、リソースＩＤとサービスＩＤとに対応づけて正常時のリソースに関する情報を格納する。ここで、正常時とは、例えば、リソースの性能がサービスにおいて要求される所定の性能基準に達している時をいう。例えば、図８の例では、リソースＩＤ「ＮＷ＃１」のリソースに対応づけて、サービスＩＤ「０００１」が格納されている。さらに、相関関係として、リソースのＣＰＵ使用率と１秒あたりのリクエスト数との自己相関関数「ｙ＝２ｘ＋０．５」、許容誤差「０．１％」が格納されている。さらに、リソースに関する情報として、ＣＰＵ使用率が「ｙｎｗ［１］［１］＝５０％」として格納されている。また、１秒あたりのリクエスト数が「ｘｖｍ［１］［１］＝６」として記憶されている。ここで、「ｙｎｗ［ｉ］［ｋ］」中、［ｉ］はリソースＩＤであり、［ｋ］はデータの番号である。また、「ｙｎｗ」は、ネットワークのリソースの使用率を示す。つまり、「ｙｎｗ［１］［１］＝５０％」は、リソースＩＤ「１」のネットワークリソースの使用率を示す情報のうち、１番目のデータが「５０％」であることを示す。また、「ｘｖｍ［ｉ］［ｋ］」中、［ｉ］はリソースＩＤであり、［ｋ］はデータの番号であり、「ｘｖｍ」は、仮想マシンリソースのリクエスト数／秒を示す。つまり、「ｘｖｍ［１］［１］＝６」は、リソースＩＤ「１」の仮想マシンリソースのリクエスト数／秒を示す情報のうち、１番目のデータが「６」であることを示す。なお、リソースに関する情報についてはさらに後述する（図１１−１、１１−２、１２−１、１２−２を参照）。

［構成情報の概要］
次に、図９を参照し、構成情報について説明する。図９は、構成情報の一例を示す図である。構成情報は、それぞれのサービスの提供において利用されるリソース間の関係を表す情報である。例えば、リソースがどのように接続されているか、という接続関係を示す。また、リソース間で処理がどのような順序で行われるか、という処理順序を示す。また、各リソースで行われる処理がどのように相互に依存しているか、という依存関係を示す。例えば、リソースＸがリクエストを発行し、リソースＹがリクエストを転送し、リソースＺがリクエストを受信して処理する等の関係を示す。構成情報は、例えばリソーストポロジとして構成情報記憶部１１２に格納される。

図９に示すように、リソーストポロジは、「Connection」と「point」によって示される。「Connection」はネットワークを表わし、「point」はサーバを表わしている。「Connection」は、ネットワークのリソースＩＤによって示され、「point」はサーバのリソースＩＤによって示される。「point」に付された番号は、処理の順序を表わしており、「point1」のリソースから転送・送信された情報が「point2」のリソースによって受信され処理されることを示す。例えば、図９に示す「Connection List」中、一行目の「Connection =”NW#1” point1=”client#1” point2=”LB1” /」は、ネットワークが、リソースＩＤ「ＮＷ＃１」で表わされるネットワークであり、そこに、リソースＩＤ「Ｃｌｉｅｎｔ＃１」で表わされるサーバが接続されており、当該サーバから転送されるリクエストが、リソースＩＤ「ＬＢ１」で表わされるサーバによって受信され処理されることを表わしている。

なお、ここでは、構成情報は、各サービスに対してリソースが割り当てられた時点で、構成情報記憶部１１２に格納されるものとする。例えば、インタークラウドサーバ１００が、リソースの割当処理も行う場合は、割当処理の完了時に格納する。他の装置がリソースの割当処理を行う場合は、割当処理の完了後、インタークラウドサーバ１００に送信する。なお、構成情報の取得タイミングはこれに限られるものではない。例えば、リソースの割当後、サービスの提供が開始した後に、適宜、インタークラウドサーバ１００からサービス管理装置３００やサービスを提供する事業者の端末等に要求を送信することで、インタークラウドサーバ１００が構成情報を受信して構成情報記憶部１１２に格納するものとしてもよい。また、構成情報の構造は、図９に示すものに限られず、リソース間の接続関係や処理順序、依存関係を示すものであれば、その構造は特に限定されない。構成情報は、リソーストポロジ、サービス構成マップ等とも呼ぶ。

［異常リソース候補リストの概要］
図１０を参照し、異常リソース候補リストについて説明する。図１０は、実施例２に係る異常リソース候補リストの一例を示す図である。異常リソース候補リストは、各リソースを利用して構成されるサービスのサービスＩＤと、異常リソース候補であるリソースのリソースＩＤとを対応付ける。図１０のリストにおいては、サービスＩＤ「０００１」のサービスについて利用されているリソースＩＤ「＃ＶＭ０００１」のリソースとリソースＩＤ「＃ＶＭ０００２」のリソースとが異常リソース候補であることが示されている。

［実施例２に係る制御部の構成］
図５に戻って、インタークラウドサーバ１００の制御部１２０の構成について説明する。制御部１２０は、受信部１２１と、算出部１２２と、抽出部１２３と、特定部１２４と、出力部１２５とを備える。受信部１２１は、管理装置２００およびサービス管理装置３００から送信される情報を、通信部１０１を介して受信する。例えば、受信部１２１は、管理装置２００およびサービス管理装置３００から送信される各リソースの情報を受信する。受信部１２１は、受信した情報を算出部１２２に送信する。

算出部１２２は、受信部１２１が受信した各リソースについての複数の情報を受け取り、複数の情報間の相関関係を算出する。例えば、算出部１２２は、管理装置２００から送信されるリソース４００のＣＰＵ使用率と、リソース管理装置３００から送信される所定のサービスにおいてリソース４００が受け取った１秒あたりのリクエスト数との相関関係を算出する。算出部１２２による算出処理の詳細については後述する。

なお、算出部１２２は、リソースを利用するユーザによるサービス提供開始後、所定の期間にわたって、当該サービスにおいて利用されるリソースの情報を受信して相関関係を算出し、算出した相関関係を相関関係記憶部１１１に格納するものとしてもよい。また、相関関係記憶部１１１に格納する相関関係は別途、リソースの性能やサービスにおいて要求される性能基準に基づいて算出してサービス提供開始前に予め相関関係記憶部１１１に格納するものとしてもよい。

抽出部１２３は、相関関係記憶部１１１にリソースに対応付けて格納された相関関係と、受信部１２１が受信した情報の相関関係との差を算出する。そして、抽出部１２３は、算出した差と許容値とを比較する。抽出部１２３は、比較結果に基づき、異常リソース候補を抽出する。例えば、抽出部１２３は、相関関係記憶部１１１に格納された相関関係と、算出した相関関係との差が、相関関係記憶部１１１に格納された許容値よりも大きい場合、当該情報に対応するリソースを異常リソース候補として抽出する。抽出した異常リソース候補は、当該リソースを利用するサービスのサービスＩＤに対応づけて、異常リソース候補記憶部１１３内に格納する。抽出部１２３による異常リソース候補抽出処理の詳細については後述する。

特定部１２４は、構成情報記憶部１１２に格納された構成情報と、抽出部１２３が抽出し、異常リソース候補記憶部１１３に格納された異常リソース候補リストとを照合し、異常原因リソースを特定する。例えば、特定部１２４は、サービスＩＤ「０００１」で識別されるサービスに対応づけて構成情報記憶部１１２内に格納された構成情報を読み出す。そして、特定部１２４は、サービスＩＤ「０００１」に対応づけて異常リソース候補記憶部１１３内に格納された異常リソース候補リストを読み出す。異常リソース候補リストに、複数の異常リソース候補が含まれている場合、特定部１２４は、構成情報を参照して、複数の異常リソース候補から異常原因リソースを特定する。例えば、構成情報として処理順序が示されている場合、異常リソース候補のうち、最も後に処理を行うリソースを、異常原因リソースとして特定する。特定部１２４の処理の詳細についても後述する。

出力部１２５は、特定部１２４が異常原因リソースとして特定したリソースを出力する。なお、図５には図示しないが、出力部１２５から出力された異常原因リソースは、通信部１０１を介して、インタークラウドサーバ１００の管理者の端末等に送信される。

［リソースについての情報の構成］
ここで、図１１−１、図１１−２、図１２−１、図１２−２を参照し、管理装置２００から送信される各リソースについての情報について説明する。図１１−１は、実施例２に係る管理装置２００から送信される情報の構成の一例を示す図である。例えば、管理装置２００が管理するリソース４００が仮想マシンであって、当該仮想マシンによってウェブ（ＷＥＢ）やアプリケーション（ＡＰ）が構成される場合を考える。この場合、図１１−１に示すように、リソースについての情報は、当該ウェブやアプリケーションのレスポンスタイム、当該ウェブやアプリケーションによるＣＰＵの使用率、メモリ使用率等である。

また、例えば、管理装置２００が管理するリソース４００が仮想マシンであって、当該仮想マシンによってデータベース（ＤＢ）が構成される場合を考える。この場合、図１１−１に示すように、リソースについての情報は、当該データベースのレスポンスタイム、ＣＰＵ使用率、メモリ使用率等である。

また、例えば、管理装置２００が管理するリソース４００がネットワークである場合を考える。この場合、図１１−１に示すように、リソースについての情報は、当該ネットワークの使用率等である。

なお、リソースについての情報は、所定期間にわたって継続的に管理装置２００からインタークラウドサーバ１００に送信されるため、一つのリソースについて複数の情報が蓄積される（図８参照）。したがって、適宜、図１１−１に示す「ｙｓ［ｉ］［ｋ］」、「ｙｃ［ｉ］［ｋ］」、「ｙｍ［ｉ］［ｋ］」、「ｙｎｗ［ｉ］［ｋ］」のように表される。例えば、「ｙｓ［ｉ］［ｋ］」は、リソースＩＤ「ｉ」のリソースについて、ｋ番目に受信されたレスポンスタイムのデータである。また、「ｙｃ［ｉ］［ｋ］」は、リソースＩＤ「ｉ」のリソースについて、ｋ番目に受信されたＣＰＵ使用率のデータである。また、「ｙｍ［ｉ］［ｋ］」は、リソースＩＤ「ｉ」のリソースについて、ｋ番目に受信されたメモリ使用率のデータである。また、「ｙｎｗ［ｉ］［ｋ］」は、リソースＩＤ「ｉ」のリソースについて、ｋ番目に受信されたネットワーク使用率のデータである。

次に、図１１−２を参照し、管理装置２００から送信される情報の構成について説明する。図１１−２は、実施例２に係る管理装置２００から送信される情報の構成の一例を示す図である。図１１−２に示すように、管理装置２００は、当該リソースを利用するサービスのＩＤと、当該リソースのＩＤと、検出した情報、例えばＣＰＵ使用率と、当該ＣＰＵ使用率を検出した日時とを送信する。図１１−２の例では、送信される情報は、サービスＩＤ「０００１」と、リソースＩＤ「＃ＶＭ０００３」と、ＣＰＵ使用率「４０％」と、タイムスタンプ「２０１２／０１０１／２０：３０」とを含む。

次に、図１２−１を参照し、サービス管理装置３００から送信される情報の一例につき説明する。図１２−１は、実施例２に係るサービス管理装置３００から送信される情報について説明するための図である。例えば、リソースが仮想マシンである場合を考える。この場合、当該リソースにより実現されるサービスにおける当該リソースの情報であって、サービス管理装置３００が検出し送信する情報は、図１２−１に示すように、ウェブ（ＷＥＢ）やアプリケーション（ＡＰ）に対するリクエスト数／秒、データベース（ＤＢ）に対するクエリ数／秒等である。また、リソースがネットワークリソースである場合、当該リソースにより実現されるサービスにおける当該リソースの情報とは、図１２−１に示すように、当該ネットワークを通じて送信される、当該ネットワークに接続されたウェブやアプリケーションのリクエスト数／秒、データベースのクエリ数／秒等である。

上述した管理装置２００が送信する情報と同様、サービス管理装置３００が送信する情報は、所定期間にわたって継続的にサービス管理装置３００からインタークラウドサーバ１００に送信される。このため、一つのリソースについて複数のデータが蓄積される（図８参照）。したがって、適宜、図１２−１に示す「ｘｖｍ［ｉ］［ｋ］」のように表される。例えば、「ｘｖｍ［ｉ］［ｋ］」は、リソースＩＤ「ｉ」のリソースについて、ｋ番目に受信された１秒当たりのリクエスト数、または、１秒当たりのクエリ数である。

次に、図１２−２を参照し、サービス管理装置３００が送信する情報の構成について説明する。図１２−２は、実施例２に係るサービス管理装置３００から送信される情報の構成の一例を示す図である。図１２−２に示すように、サービス管理装置３００は、提供するサービスにおける各リソースの情報として、当該サービスのＩＤと、各リソースのＩＤと、リクエスト数／秒と、当該情報を検出した日時とを送信する。図１２−２に示す例では、送信される情報は、サービスＩＤ「０００２」と、リソースＩＤ「＃ＶＭ０００１」と、リクエスト数／秒「６」と、タイムスタンプ「２０１１／１２２５／００：３０」と、を含む。

［実施例２における異常リソース検出処理の概要］
図１３を参照し、実施例２に係るインタークラウドサーバ１００における異常リソース検出処理の概要を説明する。図１３は、実施例２に係るインタークラウドサーバ１００における異常リソース検出処理の流れの一例を示す図である。まず、受信部１２１が、管理装置２００およびサービス管理装置３００から複数の情報を受信する（ステップＳ１０１）。次に、算出部１２２が、複数の情報間の相関関係を算出する（ステップＳ１０２）。そして、抽出部１２３が、相関関係記憶部１１１に格納された相関関係と、算出部１２２が算出した相関関係との比較に基づき、異常リソース候補を抽出する（ステップＳ１０３）。特定部１２４は、抽出部１２３が抽出した異常リソース候補と、構成情報記憶部１１２に格納された構成情報とを照合し、異常原因リソースを特定する（ステップＳ１０４）。

［相関関係記憶部に格納する相関関係の算出処理］
次に、図１４を参照し、相関関係記憶部１１１に格納される相関関係の算出処理について説明する。図１４は、実施例２に係る相関関係算出処理の流れの一例を示す図である。ここでは、受信部１２１が、正常時に管理装置２００およびサービス管理装置３００が送信した情報を受信し、受信した情報に基づき、算出部１２２が相関関係格納部１１１に格納する相関関係を算出するものとして説明する。

実施例２に係る相関関係算出処理においては、算出部１２２は、正常時に受信した複数の情報間の自己相関関数を算出する。さらに、算出部１２２は、算出した自己相関関数から逸脱しても正常値と判定する範囲を、許容値として設定する。

まず、算出部１２２は、受信部１２１から正常時のリソースに関する複数の情報を取得する（ステップＳ２０１）。例えば、受信部１２１は、管理装置２００からリソース４００のＣＰＵ使用率を受信する。また、受信部１２１は、サービス管理装置３００からリソース４００に対する１秒当たりのリクエスト数を受信する。そして、算出部１２２は、取得した情報を、検出日時に基づいて組み合わせて、ｎ個のデータペア｛ｙ［ｉ］［ｋ］，ｘ［ｉ］［ｋ］｝（式中「ｉ」は、リソース番号を示す）を生成する（ステップＳ２０２）。

次に、算出部１２２は、生成したｎ個のデータペアを用いて、最小二乗法により、自己相関関数ｙ［ｉ］＝ｆ［ｉ］（ｘ［ｉ］）を求める（ステップＳ２０３）。最小二乗法とは、想定する関数が測定値に対してよい近似となるように、残差の二乗和を最小とするような係数を決定する方法である。具体的には、自己相関関数を一次関数とするため、取得したｎ個のデータペアを用いて、一次近似直線ｙ＝ａ^＊ｘ＋ｂを算出する。式中のａ及びｂは、以下の式によって求める。

次に、算出部１２２は、データペアを構成する｛ｙ［ｉ］［ｋ］｝と｛ｘ［ｉ］［ｋ］｝とを用いて、算出した自己相関関数の値｛ｆ［ｉ］（ｘ［ｉ］［ｋ］）｝と、｛ｙ［ｉ］［ｋ］｝とから、二乗平均平方根ｒｍｓ［ｉ］を算出する（ステップＳ２０４）。さらに、許容係数αを用いて、自己相関関数からの許容誤差の値βを、「β＝ｒｍｓ［ｉ］・α」として算出する（ステップＳ２０５）。

ステップＳ２０１乃至Ｓ２０５の処理を全てのリソースについて実行することで、各リソースについての自己相関関数と許容誤差の値とが算出される。算出した自己相関関数と許容誤差の値とは、リソースＩＤに対応づけて、記憶部１１０内の相関関係記憶部１１１に格納される（ステップＳ２０６）（図８参照）。

［抽出部による異常リソース候補抽出処理］
次に、図１５を参照して、抽出部１２３による異常リソース候補抽出処理（図１３、ステップＳ１０３）について説明する。図１５は、異常リソース候補抽出処理の流れの一例を示すフローチャートである。抽出部１２３は複数の情報を取得すると（ステップＳ３０１）、情報に含まれるサービスＩＤ、リソースＩＤおよびタイムスタンプに基づき、データペア｛ｙ，ｘ｝を生成する（ステップＳ３０２）。そして、相関関係記憶部１１１に格納された当該リソースＩＤおよびサービスＩＤに対応づけられた自己相関関数と許容誤差の値とを読み出す（ステップＳ３０３）。次に、抽出部１２３は、読みだした自己相関関数ｆに、生成したデータペアの「ｘ」を代入し、正常値として、ｆ（ｘ）を算出する（ステップＳ３０４）。そして、抽出部１２３は、データペアの「ｙ」と算出したｆ（ｘ）とを比較し、ｆ（ｘ）に許容値を加算した値よりも「ｙ」が小さく、かつ、ｆ（ｘ）から許容値を減算した値よりも「ｙ」が大きいか否かを判定する（ステップＳ３０５）。データペアの「ｙ」がｆ（ｘ）に許容値を加算した値よりも小さく、かつ、ｆ（ｘ）から許容値を減算した値よりも大きいと判定した場合（ステップＳ３０５、肯定）、抽出部１２３は、当該リソースを正常リソースであると判定する（ステップＳ３０６）。これに対し、データペアの「ｙ」がｆ（ｘ）に許容値を加算した値よりも大きいか、またはｆ（ｘ）から許容値を減算した値よりも小さいと判定した場合（ステップＳ３０５、否定）、抽出部１２３は、当該リソースを異常リソース候補と判定する（ステップＳ３０７）。

抽出部１２３による自己相関関数と許容誤差を用いた判定を、図１６を用いてさらに説明する。図１６は、実施例２に係る自己相関関数を示す一次近似曲線と許容誤差の一例を示す図である。例えば、自己相関関数が図１６の直線によって表わされているとする。また、自己相関関数からの許容誤差の範囲が図１６の破線によって表わされているとする。この場合に、抽出部１２３がステップＳ３０２で生成したデータペア｛ｘ，ｙ｝が、白丸で示す位置に示される値であるとする。すると、白丸は、許容誤差を示す破線に挟まれた領域内にある。すなわち、「ｙ」がｆ（ｘ）に許容誤差を加算した値よりも小さく、かつ、ｆ（ｘ）から許容誤差を減算した値よりも大きい。したがって、白丸で表わされるデータペアに対応するリソースは正常リソースと判定される。これに対して、図１６中、×印で示す位置に示される値は、「ｙ」がｆ（ｘ）に許容誤差を加算した値よりも大きい。したがって、この値のデータペアに対応するリソースは異常リソース候補と判定される。なお、図１６中、自己相関関数を算出するために用いた情報の値を、「学習データ」として、白抜きの三角で示している。

［特定部による異常原因リソース特定処理］
次に、図１７を参照して、特定部１２４による異常原因リソース特定処理について説明する。図１７は、実施例２に係る異常原因リソース特定処理の流れの一例を示す図である。まず、特定部１２４は、異常リソース候補記憶部１１３から異常リソース候補のリスト（図１０参照）を読み出す（ステップＳ４０１）。特定部１２４は、次に、構成情報記憶部１１２から構成情報（図９参照）を読み出す（ステップＳ４０２）。

次に、特定部１２４は、異常リソース候補リストから異常リソース候補を一つ選択する（ステップＳ４０３）。そして、特定部１２４は、選択した異常リソース候補の、構成情報中の位置を特定する。次に、特定部１２４は、構成情報中、選択した異常リソース候補よりもエンドユーザから遠い位置にあり、選択した異常リソース候補と接続されたリソースがあるか否かを判定する（ステップＳ４０４）。ないと判定すると（ステップＳ４０４、否定）、特定部１２４は、選択した異常リソース候補が異常原因リソースであると特定する（ステップＳ４０６）。次のリソースがあると判定する（ステップＳ４０４、肯定）と、特定部１２４は、次のリソースが、異常リソース候補であるか否かを判定する（ステップＳ４０５）。次のリソースが異常リソース候補であると判定した場合（ステップＳ４０５、肯定）は、特定部１２４は、さらにステップＳ４０４に戻って、さらにその次のリソースがあるか否かを判定する。ステップＳ４０５で、次のリソースが異常リソース候補ではないと判定された場合（ステップＳ４０５、否定）は、特定部１２４は、当該リソースを異常原因リソースと特定する（ステップＳ４０６）。

例えば、図１８を参照して異常原因リソース特定処理をさらに説明する。図１８は、実施例２に係る異常原因リソース特定処理を説明するための図である。図１８において、リソースＡ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆがリソースとしてエンドユーザに対するサービスに利用されている。これらのリソースのうち、リソースＡ，Ｂ，Ｄ，Ｅ，Ｆが異常リソース候補として抽出されている。このとき、特定部１２４は、まず、異常リソース候補のリストからリソースＡを選択し、構成情報中の位置を特定する。そして、特定部１２４は、リソースＡよりもエンドユーザから遠く、リソースＡと接続されているリソースＢが異常リソース候補か否かを判定する。判定結果が肯定であるため、特定部１２４はさらに、リソースＢよりもエンドユーザから遠く、リソースＢと接続されているリソースＣ、Ｆが異常リソース候補か否かを判定する。その結果、リソースＦが異常リソース候補と判定される。そして、リソースＦよりもエンドユーザから遠いリソースはないため、リソースＦが異常原因リソースとして特定される。

［実施例２の効果］
上記のとおり、実施例２においては、インタークラウドサーバ１００は、管理装置２００およびサービス管理装置３００から各リソースに関する複数の情報を受信する。そして、インタークラウドサーバ１００は、複数の情報間の相関関係を算出する。インタークラウドサーバ１００は、算出した相関関係と、予め準備した所定の相関関係とを比較し、差が許容値を上回る場合、当該情報に対応するリソースを異常リソース候補として抽出する。さらに、インタークラウドサーバ１００は、リソースを利用するサービスの構成情報を取得して、当該構成情報に基づき、異常リソース候補のうち、最も処理順序が後のリソースを異常原因リソースとして特定する。このため、リソースに異常が発生した時に、管理装置２００から故障に関する通知がなくとも、故障個所を推定することができ、故障個所を適正に特定して故障に迅速に対応することができる。

また、上記の通り、実施例２においては、インタークラウドサーバ１００は、リソースについて取得することができる情報が限られている場合であっても、取得した情報相互間の自己相関関数を予め正常時に取得しておき、異常発生時には、予め取得した自己相関関数に基づいて、異常発生リソースを抽出する。このため、直接異常に関する情報を取得できない場合であっても、故障箇所を適正に特定して故障に迅速に対応することができる。

また、上記の通り、実施例２においては、インタークラウドサーバ１００は、自己相関関数と許容誤差値とに基づいて異常リソース候補を抽出した後、構成情報に基づいて、異常原因リソースを特定する。このため、多数の異常リソース候補が検出された場合であっても、適切に故障原因を絞り込むことができ、故障箇所を適正に特定して故障に迅速に対応することができる。

［実施例２の変形例１］
なお、上記実施例２では、インタークラウドサーバ１００の機能として、異常リソース候補を抽出し異常原因リソースを特定するものとして説明したが、インタークラウドサーバ１００は、このほかに、リソース４００のユーザに対する新規割当や割当廃止等の処理も行うものとしてよい。また、インタークラウドサーバ１００を、図１９に示すように、管理サーバ１０００と監視サーバ２０００とに分けて機能を分散してもよい。図１９は、実施例２の変形例１を示す図である。例えば、図１９に示すように、管理サーバ１０００を管理装置１２００およびユーザ端末１４００と接続し、監視サーバ２０００を管理装置１２００およびサービス管理装置１３００と接続する。管理装置１２００及びサービス管理装置１３００をそれぞれ、リソース１５００と接続する。そして、リソース割当に関連する処理については、管理サーバ１０００が実行し、異常リソース候補抽出、異常原因リソース特定に関連する処理については、監視サーバ２０００が実行する。

［実施例２の変形例１の効果］
上記のように構成することで、インタークラウドサーバ１００にかかる負荷を分散することができ、柔軟にインタークラウドシステムを構築することができる。

［実施例２の変形例２］
また、上記実施例２では、インタークラウドサーバ１００が継続的に、複数の管理装置２００およびサービス管理装置３００から送信される情報を受信し、複数情報間の相関関係の変動に基づいて、異常リソース候補を抽出するものとした。しかし、インタークラウドサーバ１００は特定の要求を受け付けた場合にのみ、異常リソース候補の抽出や異常原因リソースの特定のための処理を行うものとしてもよい。例えば、管理装置２００およびリソース管理装置３００が、それぞれ管理するリソースおよびサービスの処理状況に異常を検出した場合には、インタークラウドサーバ１００に異常を通知する警告を送信するものとしてもよい。そして、インタークラウドサーバ１００は、管理装置２００からは警告を受信していないが、サービス管理装置３００から警告を受信した場合のみ、異常リソース候補抽出処理および異常原因リソース特定処理を実行するものとしてもよい。また、インタークラウドサーバ１００は、管理装置２００から警告を受信しているが、サービス管理装置３００からは警告を受信していない場合のみ、異常リソース候補抽出処理および異常原因リソース特定処理を実行するものとしてもよい。また、それぞれの場合に応じて、使用する情報の種類や適用する許容係数αを変更してもよい。

［実施例２の変形例２の効果］
上記のように構成することで、インタークラウドサーバ１００にかかる負荷を軽減し、必要なときにのみ異常リソース候補抽出処理および異常原因リソース特定処理を実行して、迅速かつ効率的に異常に対処することができる。また、異常の種類に応じて、判定手法を柔軟に調整することができ、的確に異常を検出し対処することができる。

実施例３では、インタークラウドサーバの詳細について更に説明する。実施例３では、インタークラウドサーバ７００にインストールされたプログラムが一連の処理を実行することで、各クラウドシステムが提供するリソースの異常を検出し異常の原因となっているリソースを特定する場合を用いて説明する。

なお、以下では、ＣＳＰ（Cloud Service Provider）事業者により提供されるリソースが、ＡＳＰ（Application Service Provider）運用者に割り当てられ、ＡＳＰ運用者により提供されるサービスをユーザが利用する場合を用いて説明する。

図２０は、実施例３に係るインタークラウドサーバの概略図である。実施例３に係るインタークラウドサーバ７００は、データセンタのリソースやネットワークのリソースを提供するクラウドシステム各々について、リソースの状況を示す情報を収集し、異なるクラウドシステムに属するリソースをＡＳＰ運用者に割り当てる。例えば、実施例３に係るインタークラウドサーバ７００は、異なるクラウドシステムにより提供されるリソースを組み合わせて提供することで、スケールアウト等のマイグレーションを支援する。

さらに、インタークラウドサーバ７００は、ＡＳＰ運用者に割り当てられたリソースの状況を示す監視情報を、ＡＳＰ運用者が提供するサービスの状況を監視するＳＰ−ＯＰＳ（Service Provider-Operation System）６１１から収集する。同時に、インタークラウドサーバ７００は、各ＣＳＰ事業者からリソースの状況を示す監視情報を収集する。そして収集した情報に基づき、異常リソースを検出して、異常原因となっているリソースを特定する。

実施例３に係るインタークラウドサーバ７００は、リソースの割当に関する条件を記憶する制約条件データベース（ＤＢ）７１１と、リソースに関する管理情報を記憶する管理情報ＤＢ７１２とを備える。制約条件ＤＢ７１１および管理情報ＤＢ７１２は、実施例２のインタークラウドサーバ１００が備える記憶部１１０に相当する。

制約条件ＤＢ７１１は、インタークラウドシステムにより提供されるリソースが割り当てられるＡＳＰ運用者を識別するユーザＩＤと、当該ＡＳＰ運用者が要求するリソースに関する情報（以下、制約条件とも呼ぶ）とを対応づけて記憶する。例えば、制約条件ＤＢ７１１は、ＡＳＰ運用者とインタークラウドシステムの管理者との間で合意されたリソースの性能についての条件（ＳＬＡ：Service Level Agreement）等に基づく性能条件等を記憶する。また、実施例２の相関関係や構成情報に相当する情報をそれぞれ、各リソースおよび各サービスに対応づけて記憶する。

管理情報ＤＢ７１２は、リソースを管理する管理装置についての管理情報を記憶する。例えば、ＤＣ−ＯＰＳ６０３−１についての管理情報を記憶し、ＮＷ−ＯＰＳ６０４−１についての管理情報を記憶する。管理情報とは、例えば、管理装置の識別名や管理装置にアクセスする際に用いられるＵＲＬ、管理装置にアクセスする際に用いられるパスワードなどが該当する。

図２０に示す例では、インタークラウドサーバ７００に加えて、オペレータ端末６０１と、ＡＳＰ端末６０２と、ＤＣ−ＯＰＳ（Data Center-Operation System）６０３−１〜６０３−４と、ＮＷ−ＯＰＳ（Network-Operation System）６０４−１〜６０４−４と、ＤＣ（Data Center、データセンタ）６０５−１〜６０５−４と、Ｒ（Router、ルータ）６０６−１〜６０６−４と、ユーザ端末６０７−１〜６０７−３と、ＣＳＰ端末６０９と、ＳＰ−ＯＰＳ（Service Provider-Operation System）６１１とを示す。

オペレータ端末６０１は、インタークラウドサーバ７００と接続される。オペレータ端末６０１は、インタークラウドサーバ７００を管理するオペレータにより用いられる。オペレータ端末６０１は、Ｗｅｂブラウザを有する。例えば、オペレータ端末６０１は、インタークラウドサーバ７００の設定や運用、管理等を行うためのインタフェースをＷｅｂブラウザ上に表示する。

ＡＳＰ端末６０２は、インタークラウドサーバ７００と接続される。ＡＳＰ端末６０２は、クラウドシステムにより提供されるリソースを用いてサービスを提供するＡＳＰ運用者により用いられる。ＡＳＰ端末６０２は、Ｗｅｂブラウザを有する。例えば、ＡＳＰ端末６０２は、インタークラウドサーバ７００の設定や運用、管理等を行うためのインタフェースをＷｅｂブラウザ上に表示する。

ＣＳＰ端末６０９は、インタークラウドサーバ７００と接続される。ＣＳＰ端末６０９は、各クラウドシステムを提供する事業者により用いられる。ＣＰＳ端末６０９は、Ｗｅｂブラウザを有する。例えば、ＣＳＰ端末６０９は、管理するリソースに関する設定や運用、管理等を行うためのインタフェースをＷｅｂブラウザ上に表示する。

Ｒ６０６−１〜６０６−４は、ＮＷ−ＯＰＳ６０４−１〜６０４−４及びＤＣ６０５−１〜６０５−４、ユーザ端末６０７−１〜６０７−３と接続される。Ｒ６０６−１〜６０６−４は、ネットワーク装置であり、例えば、ルータである。Ｒ６０６−１〜６０６−４は、ネットワークを形成する。なお、Ｒ６０６−１〜６０６−４により形成されるネットワーク６０８により、ＤＣ６０５−１〜６０５−４とユーザ端末６０７−１〜６０７−３とが接続され、複数あるＤＣ６０５−１〜６０５−４各々が接続される。Ｒ６０６−１〜６０６−４は、ＮＷ−ＯＰＳ６０４−１〜６０４−４により管理される。

ＤＣ６０５−１〜６０５−４は、ＤＣ−ＯＰＳ６０３−１〜６０３−４及びＲ６０６−１〜６０６−４と接続される。ＤＣ６０５−１〜６０５−４は、仮想マシンサービスを提供する。ＤＣ６０５−１〜６０５−４は、ＤＣ−ＯＰＳ６０３−１〜６０３−４により管理される。なお、仮想マシン（ＶＭ：Virtual Machine）とは、ソフトウェアによって提供される仮想的なＰＣを示す。

ＤＣ−ＯＰＳ６０３−１〜６０３−４は、インタークラウドサーバ７００及びＤＣ６０５−１〜６０５−４と接続される。ＤＣ−ＯＰＳ６０３−１〜６０３−４は、ＤＣ６０５−１〜６０５−４のリソースを管理する管理装置である。具体的には、ＤＣ−ＯＰＳ６０３−１〜６０３−４は、ＤＣ６０５−１〜６０５−４の監視情報をＡＳＰ運用者毎に把握する。例えば、ＤＣ−ＯＰＳ６０３−１は、ＤＣ６０５−１〜６０５−４の内１つ又は複数のＤＣを管理する。

ＮＷ−ＯＰＳ６０４−１〜６０４−４は、インタークラウドサーバ７００及びＲ６０６−１〜６０６−４と接続される。ＮＷ−ＯＰＳ６０４−１〜６０４−４は、Ｒ６０６−１〜６０６−４を管理する管理装置である。具体的には、ＮＷ−ＯＰＳ６０４−１〜６０４−４は、Ｒ６０６−１〜６０６−４により形成されるネットワーク６０８について、ネットワーク６０８の監視情報をＡＳＰ運用者毎に把握する。例えば、ＮＷ−ＯＰＳ６０４−１は、Ｒ６０６−１〜６０６−４の内１つ又は複数のＲを管理する。

ＳＰ−ＯＰＳ６１１は、インタークラウドサーバ７００および管理対象であるサービスを構成するリソースと接続される（図示せず）。ＳＰ−ＯＰＳ６１１は、サービスを構成するリソースをサービス層において管理する管理装置である。例えば、ＤＣ６０５−１、６０５−３と、Ｒ６０６−１、６０６−４とを用いてサービスが提供されている場合、ＳＰ−ＯＰＳ６１１は、サービス層においてＤＣ６０５−１、６０５−３および、Ｒ６０６−１、６０６−４の処理状況を監視する。

なお、図２０に示す例では、説明の便宜上、オペレータ端末が１つあり、ＡＳＰ端末が１つあり、ＣＳＰ端末が１つあり、ＤＣ−ＯＰＳが４つあり、ＮＷ−ＯＰＳが４つあり、ＤＣが４つあり、Ｒが４つあり、ＳＰ−ＯＰＳが１つあり、ユーザ端末が３つある場合を示した。ただし、これに限定されるものではなく、各装置の数は任意であって良い。例えば、ＡＳＰ端末が２つ以上あっても良く、ＤＣ−ＯＰＳやＮＷ−ＯＰＳ、ＤＣ、Ｒなどが３つ以下でも良く、５つ以上でも良い。また、ＣＳＰ端末およびＳＰ−ＯＰＳは、インタークラウドシステムにおいては通常複数存在する。

また、図２０に示す例では、オペレータ端末６０１と、ＡＳＰ端末６０２と、ユーザ端末６０７、ＣＳＰ端末６０９とが別装置である場合を例に示したが、これに限定されるものではない。例えば、オペレータ端末６０１と、ＡＳＰ端末６０２と、ユーザ端末６０７と、ＣＳＰ端末６０９とのうち、任意の装置を組み合わせて１つの装置としても良い。

インタークラウドサーバ７００は、各種のハードウェアを有し、ＯＳやミドルウェアなどの各種プログラムが予めインストールされる。具体的には、インタークラウドサーバ７００は、詳細については後述するように、インタークラウドサーバ７００が有する各種のハードウェアにより実行されるプログラムとして、ＩＣＳソフトウェア７０１を実行する。なお、ＩＣＳソフトウェア７０１は、実施例２における制御部１２０の各部により実行される処理を実行する。

また、実施例３におけるＩＣＳソフトウェア７０１は、後述するように、ＤＣ−ＯＰＳ６０３−１〜６０３−４およびＮＷ−ＯＰＳ６０４−１〜６０４−４から各リソースの監視情報を取得する。また、ＩＣＳソフトウェア７０１は、ＳＰ−ＯＰＳ６１１からサービスにおけるリソースの監視情報を取得する。そして、ＩＣＳソフトウェア７０１は、正常時の監視情報に基づき、相関関係を算出する。また、ＩＣＳソフトウェア７０１は、ＳＰ−ＯＰＳ６１１から警告通知を受信すると、ＤＣ−ＯＰＳ６０３−１〜６０３−４、ＮＷ−ＯＰＳ６０４−１〜６０４−４、ＳＰ−ＯＰＳ６１１に対して監視情報の送信を要求する。そして、ＩＣＳソフトウェア７０１は、相関関係と監視情報とを照合することで異常リソース候補を抽出し、その中から、異常原因リソースを特定する。ＩＣＳソフトウェア７０１は、オペレータ端末６０１に、特定された異常原因リソースを通知する。また、ＩＣＳソフトウェア７０１は、異常リソース候補とされたリソースのリストをオペレータ端末６０１に送信する。さらに、ＩＣＳソフトウェア７０１は、異常原因リソースを提供しているＣＳＰ事業者のＣＳＰ端末６０９に、異常原因リソースのメンテナンスを要求する通知を送る。オペレータおよびＣＳＰ事業者はそれぞれ、Ｗｅｂブラウザ上で、異常リソース候補のリストや異常原因リソースの情報を視認することができる。

［実施例３における異常リソース検出処理］
図２１を参照して、実施例３における異常リソース検出処理の流れの一例について説明する。図２１は、実施例３に係る異常リソース検出処理の流れの一例を説明するための図である。まず、ＡＳＰ事業者からの要求に応じてリソースが割り当てられ、サービスが開始する。すると、サービスを管理するＳＰ−ＯＰＳ６１１は所定の期間にわたってインタークラウドサーバ７００に、サービスを構成するリソースの監視情報を送信する（図２１の（１））。また、当該サービスを構成するリソースを管理するＤＣ−ＯＰＳ６０３−２、ＮＷ−ＯＰＳ６０４−１は、リソースの監視情報を所定の期間にわたってインタークラウドサーバ７００に送信する（図２１の（１））。ＩＣＳソフトウェア７０１は、受信した情報間の相関関係を算出し、リソースＩＤと対応づけて制約条件ＤＢ７１１に格納する（図２１の（２））。その後、提供しているサービスの性能劣化を検出すると、ＳＰ−ＯＰＳ６１１は、インタークラウドサーバ７００に対して警告通知を送信する（図２１の（３））。警告通知を受信すると、ＩＣＳソフトウェア７０１は、該当するサービスを構成するリソースを提供している管理装置に対して、監視情報の送信を要求する通知を送信する（図２１の（４））。通知を受信した管理装置は、ＩＣＳソフトウェア７０１に対して監視情報を送信する（図２１の（５））。ＩＣＳソフトウェア７０１は、受信した監視情報と、制約条件ＤＢ７１１に格納した相関関係とを、リソースごとに照合する（図２１の（６））。そして、受信した監視情報が格納された相関関係から許容値を超えて逸脱していると判定すると、ＩＣＳソフトウェア７０１は、当該監視情報に対応するリソースを異常リソース候補として抽出する（図２１の（７））。さらに、ＩＣＳソフトウェア７０１は、制約条件ＤＢ７１１に格納された構成情報を参照し、異常原因リソースを特定する（図２１の（８））。ＩＣＳソフトウェア７０１は、抽出された異常リソース候補のリストと異常原因リソースとをオペレータ端末６０１に送信する（図２１の（９））。さらに、ＩＣＳソフトウェア７０１は、異常原因リソースと特定されたリソースを提供しているＣＳＰ事業者に、異常原因リソースを通知する（図２１の（１０））。

［実施例３におけるインタークラウドサーバの効果］
上述の通り、実施例３に係るインタークラウドサーバ７００は、リソースを管理するＤＣ−ＯＰＳやＮＷ−ＯＰＳからリソースの監視情報を受信し、サービスを管理するＳＰ−ＯＰＳからサービスにおけるリソースの監視情報を受信する。そして、インタークラウドサーバ７００は、受信した監視情報間の相関関係を予め算出しておく。その後、ＳＰ−ＯＰＳから性能劣化を通知する警告を受信すると、該当するＤＳ−ＯＰＳ、ＮＷ−ＯＰＳ、ＳＰ−ＯＰＳから新たに監視情報を受信して、予め算出した相関関係と照合する。照合の結果、新たに受信した監視情報が許容値を超えて相関関係から逸脱していれば、当該監視情報に対応するリソースを異常リソース候補として抽出する。このため、実施例３に係るインタークラウドサーバ７００は、ＤＳ−ＯＰＳやＮＷ−ＯＰＳからリソースの異常を通知されなくても、ＳＰ−ＯＰＳからの通知に基づいて、複数の装置から監視情報を取得して、異常が発生したリソースを適切に特定することができる。

これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、その他の実施例にて実施されてもよい。以下に、その他の実施例を説明する。

［システム構成］
本実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。例えば、相関関係や許容値の算出は算出部１２２が行うものとして説明したが、オペレータが手動で相関関係を算出し経験値を考慮して許容値を設定してもよい。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、図８に示す相関関係は、リソースＩＤおよびサービスＩＤに対応づけて格納されているが、リソースＩＤのみに対応づけて格納してもよい。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、図５に示す例では、記憶部１１０をインタークラウドサーバ１００の内部に配置したが、記憶部１１０をインタークラウドサーバ１００の外部装置としてネットワーク経由で接続するようにしてもよい。また、例えば、図５に示す例において、制御部１２０が、抽出部１２３の機能を分離して、データペアを生成するペア生成部と生成したペアについて異常値か否かを判定する判定部とに分けて備えてもよい。

［プログラム］
図２２は、インタークラウドサーバによる一連の処理を実行するプログラムであるリソース監視プログラムによる情報処理が、コンピュータを用いて具体的に実現されることを示す図である。図２２に例示するように、コンピュータ３０００は、例えば、メモリ３０１０と、ＣＰＵ（Central Processing Unit）３０２０と、ハードディスクドライブ３０８０と、ネットワークインタフェース３０７０とを有する。コンピュータ３０００の各部はバス３１００によって接続される。

メモリ３０１０は、図２２に例示するように、ＲＯＭ３０１１およびＲＡＭ３０１２を含む。ＲＯＭ３０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。

ここで、図２２に例示するように、ハードディスクドライブ３０８０は、例えば、ＯＳ３０８１、アプリケーションプログラム３０８２、プログラムモジュール３０８３、プログラムデータ３０８４を記憶する。すなわち、開示の実施の形態に係るリソース監視プログラムは、コンピュータによって実行される指令が記述されたプログラムモジュール３０８３として、例えばハードディスクドライブ３０８０に記憶される。例えば、制御部１２０の各部と同様の情報処理を実行する手順各々が記述されたプログラムモジュール３０８３が、ハードディスクドライブ３０８０に記憶される。

また、記憶部１１０に記憶されるデータのように、リソース監視プログラムによる情報処理に用いられるデータは、プログラムデータ３０８４として、例えばハードディスクドライブ３０８０に記憶される。そして、ＣＰＵ３０２０が、ハードディスクドライブ３０８０に記憶されたプログラムモジュール３０８３やプログラムデータ３０８４を必要に応じてＲＡＭ３０１２に読み出し、各種の手順を実行する。

なお、リソース監視プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ハードディスクドライブ３０８０に記憶される場合に限られない。例えば、プログラムモジュール３０８３やプログラムデータ３０８４は、着脱可能な記憶媒体に記憶されてもよい。この場合、ＣＰＵ３０２０は、ディスクドライブなどの着脱可能な記憶媒体を介してデータを読み出す。また、同様に、更新プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ネットワーク（ＬＡＮ、ＷＡＮ等）を介して接続された他のコンピュータに記憶されてもよい。この場合、ＣＰＵ３０２０は、ネットワークインタフェース３０７０を介して他のコンピュータにアクセスすることで各種データを読み出す。

［その他］
なお、本実施例で説明したリソース監視プログラムは、インターネット等のネットワークを介して配布することができる。また、リソース監視プログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読取可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

１ リソース監視装置
２−１〜２−７ 管理装置
３−１〜３−５ リソース
１１ 制御部
１２ 記憶部
１００ インタークラウドサーバ
１０１ 通信部
１１０ 記憶部
１１１ 相関関係記憶部
１１２ 構成情報記憶部
１１３ 異常リソース候補記憶部
１２０ 制御部
１２１ 受信部
１２２ 算出部
１２３ 抽出部
１２４ 特定部
１２５ 出力部
２００ 管理装置
３００ サービス管理装置
４００ リソース

Claims (8)

1. 連携してサービスを提供する複数のリソース各々に関する複数の情報を異なる管理装置から取得する取得部と、
   前記取得部が取得した複数の情報間の相関関係と所定の相関関係との差が、許容値よりも大きくなったリソースを異常リソース候補として抽出する抽出部と、
   前記サービスにおける複数のリソースの構成を示す構成情報に基づいて、前記異常リソース候補の中から、前記異常リソース候補に異常を発生させる原因となったリソースである異常原因リソースを特定する特定部と、
   を備えることを特徴とするリソース監視装置。
2. 前記取得部は、前記リソースを管理する管理装置から当該リソースの性能情報を取得し、前記サービスを管理する管理装置から当該サービスにおけるリソースの性能情報を取得することを特徴とする請求項１に記載のリソース監視装置。
3. 前記構成情報は、前記リソースを利用するサービスにおける複数のリソース間の処理順序および／または接続関係を含み、
   前記特定部は、前記処理順序および／または前記接続関係に基づいて、前記異常リソース候補の中から、前記異常原因リソースを特定することを特徴とする請求項１または２に記載のリソース監視装置。
4. 前記特定部は、前記処理順序を参照して、処理順序が最も後の異常リソース候補を異常原因リソースとして特定することを特徴とする請求項３に記載のリソース監視装置。
5. 前記取得部は、前記管理装置が、同一時刻および／または同一時間間隔で取得した情報を取得することを特徴とする請求項１〜４のいずれか１項に記載のリソース監視装置。
6. 複数の管理装置と、リソース監視装置とを備えたリソース監視システムであって、
   前記複数の管理装置は、リソースに関する複数の情報を前記リソース監視装置に送信する送信部を備え、
   前記リソース監視装置は、
   連携してサービスを提供する複数のリソース各々に関する複数の情報を異なる管理装置から取得する取得部と、
   前記取得部が取得した複数の情報間の相関関係と所定の相関関係との差が、許容値よりも大きくなったリソースを異常リソース候補として抽出する抽出部と、
   前記サービスにおける複数のリソースの構成を示す構成情報に基づいて、前記異常リソース候補の中から、前記異常リソース候補に異常を発生させる原因となったリソースである異常原因リソースを特定する特定部と、
   を備えることを特徴とするリソース監視システム。
7. リソース監視装置で実行されるリソース監視方法であって、
   連携してサービスを提供する複数のリソース各々に関する複数の情報を異なる管理装置から取得する取得工程と、
   前記取得部が取得した複数の情報間の相関関係と所定の相関関係との差が、許容値よりも大きくなったリソースを異常リソース候補として抽出する抽出工程と、
   前記サービスにおける複数のリソースの構成を示す構成情報に基づいて、前記異常リソース候補の中から、前記異常リソース候補に異常を発生させる原因となったリソースである異常原因リソースを特定する特定工程と、
   を含むリソース監視方法。
8. コンピュータを請求項１〜５のいずれか１項に記載のリソース監視装置として機能させるためのリソース監視プログラム。

Images