JP7401764B2 - 制御プログラム、制御方法および制御装置 - Google Patents

Description

本発明は制御プログラム、制御方法および制御装置に関する。

物理マシン上に、アプリケーションから物理マシンのように見える仮想処理単位を形成するコンピュータ仮想化技術がある。仮想処理単位には、プロセッサやメモリなど物理マシンが有するハードウェアリソースの一部が割り当てられる。仮想処理単位は、割り当てられたリソースを用いてアプリケーションを実行し得る。コンピュータ仮想化技術を利用することで、仮想処理単位の追加、移動および削除が容易となり、アプリケーションの需要の変動や物理マシンの運用状況に柔軟に対応することができる。

仮想処理単位には、ゲストオペレーティングシステム（ＯＳ：Operating System）を実行する狭義の仮想マシンと、ゲストＯＳを実行しない軽量のコンテナとがある。物理マシンがハイパーバイザなどを実行することで、物理マシン上に仮想マシンを形成することができる。また、物理マシンがコンテナエンジンを実行することで、物理マシン上にコンテナを形成することができる。また、仮想マシンがコンテナエンジンを実行することで、仮想マシン上にコンテナを形成することもできる。よって、物理マシン、仮想マシン、コンテナなどの処理単位を階層的に積み上げることが可能である。

なお、２以上のクラウドシステムを利用して実装された分散アプリケーションの障害を検出する障害診断方法が提案されている。提案の障害診断方法は、異なるクラウドシステム間の接続の情報を収集して監視し、接続に関する障害を検出する。

国際公開第２０１２／１６２１７１号

ところで、システム設計思想の１つとして、多数の仮想処理単位を配置し、細分化されたアプリケーションをそれら仮想処理単位に分散して実行させ、それらアプリケーションが連携して一連のサービスを実現するようにする方法が考えられる。しかし、多数の仮想処理単位を含む仮想環境の上で様々なアプリケーションが実行されていると、障害発生時の原因分析を効率的に行うことが容易でないという問題がある。

あるアプリケーションに障害が発生した場合に、その根本原因がアプリケーション自身にあるのではなく、アプリケーションを支えるインフラストラクチャとしての仮想環境の障害に起因していることがある。例えば、物理マシンのハードウェア障害や仮想マシンのゲストＯＳの障害が、コンテナ上で実行されているアプリケーションの障害の根本原因になっていることがある。しかしながら、多数の処理単位と多数のアプリケーションを含むシステムから、あるアプリケーション障害の根本原因になっている他の障害を特定するのは容易ではなく、システム管理者による長時間の作業を要することがある。

そこで、１つの側面では、本発明は、仮想化されたシステムにおける障害原因の分析を効率化する制御プログラム、制御方法および制御装置を提供することを目的とする。

１つの態様では、コンピュータに以下の処理を実行させる制御プログラムが提供される。それぞれが割り当てられたリソースを用いてアプリケーションを実行可能な処理ノードであって、仮想化ソフトウェアを用いて階層的に配置することが可能な複数の処理ノードを含み、複数のアプリケーションそれぞれが複数の処理ノードの何れかで実行される情報処理システムについて、第１のアプリケーションの障害を示す第１の障害情報と、第２の処理ノードの障害を示す第２の障害情報と、第１の障害情報と第２の障害情報との間の関連の有無を示す教師ラベルとを取得する。第１の障害情報および第２の障害情報に基づいて、第１のアプリケーションを実行する第１の処理ノードと第２の処理ノードとの間の配置の階層関係を示す第１の評価値と、第２の処理ノードの上に配置された処理ノードで実行される第２のアプリケーションと第１のアプリケーションとの間の依存関係を示す第２の評価値と、第１の障害情報に含まれる第１のエラーメッセージと第２の障害情報に含まれる第２のエラーメッセージとの間の類似度を示す第３の評価値とを算出する。第１の評価値、第２の評価値および第３の評価値を含む特徴情報と教師ラベルとを対応付けた訓練データを用いて、２つの障害情報についての特徴情報に対応する入力データから２つの障害情報の関連性の有無を推定するモデルを生成する。

また、１つの態様では、コンピュータが実行する制御方法が提供される。また、１つの態様では、記憶部と処理部とを有する制御装置が提供される。

１つの側面では、仮想化されたシステムにおける障害原因の分析を効率化できる。

第１の実施の形態の制御装置の例を説明する図である。 第２の実施の形態の情報処理システムの例を示す図である。 管理サーバのハードウェア例を示すブロック図である。 仮想化インフラストラクチャの階層例を示す図である。 システム構成グラフの例を示す図である。 サービスメッシュグラフの例を示す図である。 原因判定モデルの生成例を示す図である。 システム管理画面の例を示す図である。 管理サーバの機能例を示すブロック図である。 障害テーブルの例を示す図である。 構成テーブルの例を示す図である。 サービス距離テーブルとサービス配置テーブルの例を示す図である。 訓練データテーブルの例を示す図である。 モデル生成の手順例を示すフローチャートである。 障害原因判定の手順例を示すフローチャートである。 モデル更新の手順例を示すフローチャートである。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。

図１は、第１の実施の形態の制御装置の例を説明する図である。
第１の実施の形態の制御装置１０は、情報処理システム２０で発生した障害の分析に用いられる。制御装置１０は、クライアント装置でもよいしサーバ装置でもよい。制御装置１０を、コンピュータ、情報処理装置、分析装置、機械学習装置などと言うこともできる。制御装置１０と情報処理システム２０とがネットワークで接続されていてもよい。

情報処理システム２０は、コンピュータ仮想化技術を利用してアプリケーションを実行する監視対象システムである。情報処理システム２０は、処理ノード２１，２２，２３（第１、第２および第３の処理ノード）を含む複数の処理ノードを有する。

各処理ノードは、割り当てられたリソースを用いてアプリケーションを実行することができる。リソースには、プロセッサの演算能力、メモリの記憶領域、通信帯域などのハードウェアリソースが含まれ得る。各処理ノードは、物理マシンであることもあるし、仮想マシンやコンテナなどの仮想処理ノードであることもある。２以上の処理ノードを、仮想化ソフトウェアを用いて階層的に配置することが可能である。例えば、ある処理ノードがハイパーバイザを実行することで、その処理ノードの上に仮想マシンを配置することができる。また、ある処理ノードがコンテナエンジンを実行することで、その処理ノードの上にコンテナを配置することができる。物理マシンの上に１以上の仮想マシンを配置し、各仮想マシンの上に１以上のコンテナを配置することもある。

情報処理システム２０では、アプリケーション２４，２５（第１および第２のアプリケーション）を含む複数のアプリケーションそれぞれが、何れかの処理ノードで実行される。アプリケーションを、アプリケーションソフトウェアと言うこともできる。各アプリケーションは、単一のプログラムまたは２以上のプログラムの集合によって実装され得る。各アプリケーションは、単一のプロセスまたは２以上のプロセスの集合として動作する。上記のプログラムを、アプリケーションプログラムやユーザプログラムと言うこともできる。上記のプロセスを、ユーザプロセスと言うこともできる。アプリケーションの例として、Ｗｅｂサーバ、業務ロジックサーバ、データベースサーバなどが挙げられる。

複数のアプリケーションは、いわゆるマイクロサービスアーキテクチャに基づいて実装されたものであってもよい。マイクロサービスアーキテクチャでは、機能が細分化された複数のアプリケーションが実装され、それら複数のアプリケーションが複数の処理ノードに分散して配置される。それら複数のアプリケーションが相互に通信して連携することで、Ｗｅｂサービスなどの一連のサービスがユーザに対して提供される。

一例として、処理ノード２１がアプリケーション２４を実行している。また、処理ノード２３がアプリケーション２５を実行している。処理ノード２３は処理ノード２２の上に存在する。ここで、処理ノード２２の上に処理ノード２３があるとは、両者の間に階層的な親子関係があればよい。処理ノード２２が処理ノード２３を直接制御しているという直接的な親子関係であってもよいし、処理ノード２２と処理ノード２３の間に更に他の処理ノードの層が存在するという間接的な親子関係であってもよい。物理マシンに近い方が下位の階層であり、アプリケーションに近い方が上位の階層である。

処理ノード２１は、処理ノード２２の上にあってもよいし、処理ノード２２の上になくてもよい。よって、処理ノード２１と処理ノード２３は、同一の物理マシンに配置されていることもあるし、異なる物理マシンに配置されていることもある。例えば、処理ノード２１，２３は、物理マシンまたは仮想マシンの１つ上の階層に位置するコンテナである。また、例えば、処理ノード２２は、物理マシンまたは仮想マシンである。

制御装置１０は、記憶部１１および処理部１２を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性半導体メモリでもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性ストレージでもよい。処理部１２は、例えば、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などのプロセッサである。ただし、処理部１２は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。プロセッサは、ＲＡＭなどのメモリ（記憶部１１でもよい）に記憶されたプログラムを実行する。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うこともある。

記憶部１１は、障害情報１３，１４（第１および第２の障害情報）と教師ラベル１５とを記憶する。障害情報１３は、過去にアプリケーション２４で発生した障害を示す。障害情報１４は、過去に処理ノード２２で発生した障害を示す。教師ラベル１５は、障害情報１３と障害情報１４との間の関連の有無を示す。例えば、教師ラベル１５は、アプリケーション２４の障害の原因が、処理ノード２２の障害であるか否かを示すフラグである。

障害情報１３は、例えば、障害が発生したアプリケーション２４を識別する情報と、障害内容を示すエラーメッセージ（第１のエラーメッセージ）とを含む。障害情報１３は、アプリケーション２４を実行する処理ノード２１の管理ソフトウェア（例えば、コンテナライブラリ）によって生成されてもよい。また、障害情報１３は、処理ノード２１の管理ソフトウェアが出力するログから制御装置１０が生成したものでもよい。同様に、障害情報１４は、例えば、障害が発生した処理ノード２２を識別する情報と、障害内容を示すエラーメッセージ（第２のエラーメッセージ）とを含む。障害情報１４は、処理ノード２２の管理ソフトウェア（例えば、物理マシンのホストＯＳまたは仮想マシンのゲストＯＳ）によって生成されてもよい。また、障害情報１４は、処理ノード２２の管理ソフトウェアが出力するログから制御装置１０が生成したものでもよい。

アプリケーション２４の障害としては、例えば、他のアプリケーションとのデータ通信の失敗、データ処理のタイムアウトなどが挙げられる。処理ノード２２の障害としては、例えば、メモリやＨＤＤや通信インタフェースなどのハードウェアへのアクセス失敗、通信プロセスなどの管理用プロセスの異常停止などが挙げられる。

教師ラベル１５は、アプリケーション２４の障害に対するシステム管理者の原因分析結果を反映している。教師ラベル１５は、システム管理者によって作成されてもよい。また、教師ラベル１５は、システム管理者によって作成された障害対応記録から制御装置１０が生成したものでもよい。例えば、アプリケーション２４の障害の原因が処理ノード２２の障害であると障害対応の際に結論付けられた場合、教師ラベル１５は「関連あり」を示す。一方、アプリケーション２４の障害の原因が処理ノード２２の障害以外にあると障害対応の際に結論付けられた場合、教師ラベル１５は「関連なし」を示す。

処理部１２は、障害情報１３，１４および教師ラベル１５を用いて訓練データを生成し、生成した訓練データを用いて機械学習によりモデル１７を生成する。訓練データの生成では、処理部１２は、障害情報１３，１４に基づいて、評価値１６ａ，１６ｂ，１６ｃ（第１、第２および第３の評価値）を含む特徴情報１６を生成する。そして、処理部１２は、特徴情報１６と教師ラベル１５とを対応付けた訓練データを生成する。特徴情報１６は説明変数に相当し、教師ラベル１５は目的変数に相当する。

評価値１６ａは、処理ノード間の親子関係を示す指標である。評価値１６ａは、障害が発生したアプリケーション２４を実行する処理ノード２１と、障害が発生した処理ノード２２との間の配置の階層関係を示す。例えば、評価値１６ａは、コンテナと物理マシンまたは仮想マシンとの間の階層関係を示す。評価値１６ａは、処理ノード２２の上に処理ノード２１が存在するか否か示すものでもよい。また、評価値１６ａは、処理ノード２１の階層と処理ノード２２の階層との間の距離（階層差）を示すものでもよい。

評価値１６ｂは、アプリケーション間の依存関係を示す指標である。評価値１６ｂは、障害が発生した処理ノード２２の上に配置された処理ノード２３で実行されるアプリケーション２５と、障害が発生したアプリケーション２４との間の依存関係を示す。依存関係として、例えば、アプリケーション２４とアプリケーション２５との間の通信関係を用いることができる。評価値１６ｂは、アプリケーション２４とアプリケーション２５とが直接または間接的にデータ通信を行うか否かを示すものでもよい。また、評価値１６ｂは、複数のアプリケーションの間の通信関係を示すサービスメッシュグラフにおいて、アプリケーション２４とアプリケーション２５との間の距離を示すものでもよい。

評価値１６ｃは、障害情報１３に含まれるエラーメッセージと障害情報１４に含まれるエラーメッセージとの間の類似度を示す。類似度の指標として、例えば、Bag of Wordsのコサイン類似度が用いられる。ただし、編集距離（レーベンシュタイン距離）などの他の指標を用いることもできる。また、類似度を算出するにあたり、各エラーメッセージから、数値などノイズとなり得る所定の種類の文字列をフィルタにより除去する、特徴的なキーワードのみを抽出する、といった前処理を行うようにしてもよい。

訓練データの１つのレコードは、障害情報のペア毎に生成される。処理部１２は、障害情報１３，１４のペアと同様の方法で、異なる障害情報のペアから訓練データのレコードを生成する。訓練データが生成されると、処理部１２は、その訓練データを用いて機械学習によりモデル１７を生成する。モデル１７は、２つの障害情報についての特徴情報に対応する入力データから、当該２つの障害情報の関連性の有無を推定するものである。モデル１７は、２つの障害の間に関連があるか否か判定するものでもよく、一方の障害の原因が他方の障害にあるか否か判定するものでもよい。また、モデル１７は、その確信度を出力するものでもよい。

モデル１７は、機械学習によってその値が決定されるパラメータを含む。モデル１７は、例えば、ロジスティック回帰分析によって生成される回帰モデルである。ただし、モデル１７が、サポートベクタマシン（ＳＶＭ：Support Vector Machine）、ランダムフォレスト、ニューラルネットワークなどの他の種類のモデルであってもよい。

第１の実施の形態の制御装置１０によれば、過去の障害を示す障害情報１３，１４から、アプリケーションの障害と仮想環境としてのインフラストラクチャに含まれる処理ノードの障害との間の関連の有無を判定するモデル１７が生成される。生成されたモデル１７を利用することで、アプリケーションの障害の原因が特定の処理ノードの障害である可能性を評価することができる。よって、システム管理者による障害対応を支援することができ、システム管理者の作業時間を短縮することが可能となる。

また、モデル１７の入力となる特徴情報１６には、障害が発生したアプリケーションを実行する処理ノードと、同時期に障害が発生した処理ノードとの間の階層関係を示す評価値１６ａが含まれる。このため、障害が下位の階層から上位の階層に伝播する態様を表現することができる。また、特徴情報１６には、障害が発生したアプリケーションと、障害が発生した処理ノードの上の階層で実行されているアプリケーションとの間の依存関係を示す評価値１６ｂが含まれる。このため、通信エラーなどによりアプリケーション間で障害が伝播する態様を表現することができる。また、特徴情報１６には、エラーメッセージの類似性を示す評価値１６ｃが含まれる。このため、障害の伝播によりアプリケーションと処理ノードとで同じ種類の障害が発生する態様を表現することができる。以上により、２つの障害の間の関連性を精度よく判定することが可能となる。

［第２の実施の形態］
次に、第２の実施の形態を説明する。
図２は、第２の実施の形態の情報処理システムの例を示す図である。

第２の実施の形態の情報処理システムは、クライアント端末３１、管理サーバ１００および監視対象システム２００を含む。クライアント端末３１、管理サーバ１００および監視対象システム２００は、ネットワーク３０に接続されている。ネットワーク３０は、ＬＡＮ（Local Area Network）を含んでもよく、インターネットなどの広域ネットワークを含んでもよい。管理サーバ１００は、第１の実施の形態の制御装置１０に対応する。監視対象システム２００は、第１の実施の形態の情報処理システム２０に対応する。

クライアント端末３１は、監視対象システム２００を管理するシステム管理者が使用するクライアントコンピュータである。監視対象システム２００に障害が発生すると、クライアント端末３１は、管理サーバ１００から障害情報を受信して表示する。同時期に２以上の障害が発生している場合、管理サーバ１００から受信する障害情報には、ある障害の根本原因が他の障害である可能性を示す情報が含まれることがある。システム管理者は、クライアント端末３１に表示された障害情報を参考にして、障害原因の特定を含む障害対応作業を行う。クライアント端末３１は、システム管理者から障害対応情報の入力を受け付け、管理サーバ１００に障害対応情報を送信する。

管理サーバ１００は、監視対象システム２００を監視するサーバコンピュータである。管理サーバ１００は、監視対象システム２００に含まれる構成要素の配置を示す構成情報を収集する。また、管理サーバ１００は、監視対象システム２００で実行されるアプリケーション間の論理関係を示すサービス情報を収集する。また、管理サーバ１００は、監視対象システム２００で発生した障害を示す障害情報を収集する。管理サーバ１００は、障害を検出すると、クライアント端末３１に障害情報を送信する。また、管理サーバ１００は、クライアント端末３１から障害対応情報を受信して保存する。

同時期に２以上の障害が発生している場合、管理サーバ１００は、ある障害の根本原因が他の障害である可能性を評価し、評価結果を障害情報に含めてクライアント端末３１に送信する。２つの障害の関連性の評価には、機械学習によって生成された原因判定モデルが使用される。原因判定モデルは、２つの障害の情報から、その２つの障害が関連している確率を示す確信度を算出する回帰モデルである。管理サーバ１００は、過去に収集した構成情報、サービス情報および障害情報から訓練データを生成し、この訓練データを用いて原因判定モデルを生成する。また、管理サーバ１００は、クライアント端末３１からのフィードバックに基づいて、判定精度が上がるように原因判定モデルを更新する。

監視対象システム２００は、コンピュータ仮想化技術を利用してアプリケーションを実行する情報処理システムである。監視対象システム２００は、サービス事業者が所有するオンプレミスシステム（自社システム）であってもよいし、クラウド事業者が所有してサービス事業者に有料で使用させるクラウドシステムであってもよい。

監視対象システム２００は、物理マシン２０１，２０２を含む複数の物理マシンと、スイッチ２０３を含む１以上の通信装置とを含む。物理マシン２０１，２０２は、スイッチ２０３に接続されている。物理マシン２０１，２０２は、仮想化ソフトウェアを用いて複数の仮想処理ノードを形成するサーバコンピュータである。仮想処理ノードには、ハイパーバイザを用いて形成される狭義の仮想マシンと、コンテナエンジンを用いて形成されるコンテナとが含まれる。仮想マシンは、ゲストＯＳを実行する独立性の高い仮想処理ノードであるのに対し、コンテナは、ゲストＯＳを実行しない軽量の仮想処理ノードである。

監視対象システム２００では、マイクロサービスアーキテクチャに基づいて実装されたアプリケーションが実行される。Ｗｅｂサービスなどのサービスを実現するための機能が細分化されて複数のアプリケーションとして実装され、異なるアプリケーションが異なる仮想処理ノードで実行される。アプリケーションには、例えば、Ｗｅｂサーバ、業務ロジックサーバ、データベースサーバなどが含まれる。複数のアプリケーションが相互に通信して連携し、一連のサービスを実現する。第２の実施の形態では、後述するように、アプリケーションがコンテナで実行されるようにする。これにより、負荷の変動に応じたスケールアウト（サーバ台数の増加）やスケールイン（サーバ台数の減少）が容易となる。また、新しい機能をもつアプリケーションの追加も容易となる。

図３は、管理サーバのハードウェア例を示すブロック図である。
管理サーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像インタフェース１０４、入力インタフェース１０５、媒体リーダ１０６および通信インタフェース１０７を有する。管理サーバ１００が有するこれらのユニットは、バスに接続されている。ＣＰＵ１０１は、第１の実施の形態の処理部１２に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。クライアント端末３１や物理マシン２０１，２０２も、管理サーバ１００と同様のハードウェアを用いて実現できる。

ＣＰＵ１０１は、プログラムの命令を実行するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。ＣＰＵ１０１は複数のプロセッサコアを備えてもよく、管理サーバ１００は複数のプロセッサを備えてもよい。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に使用するデータを一時的に記憶する揮発性半導体メモリである。管理サーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数のメモリを備えてもよい。

ＨＤＤ１０３は、ＯＳやミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性ストレージである。管理サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）など他の種類のストレージを備えてもよく、複数のストレージを備えてもよい。

画像インタフェース１０４は、ＣＰＵ１０１からの命令に従って、管理サーバ１００に接続された表示装置１１１に画像を出力する。表示装置１１１として、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイ、プロジェクタなど、任意の種類の表示装置を使用することができる。管理サーバ１００に、プリンタなど表示装置１１１以外の出力デバイスが接続されてもよい。

入力インタフェース１０５は、管理サーバ１００に接続された入力デバイス１１２から入力信号を受け付ける。入力デバイス１１２として、マウス、タッチパネル、タッチパッド、キーボードなど、任意の種類の入力デバイスを使用することができる。管理サーバ１００に複数種類の入力デバイスが接続されてもよい。

媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、半導体メモリなど、任意の種類の記録媒体を使用することができる。媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体１１３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。

通信インタフェース１０７は、ネットワーク３０に接続され、ネットワーク３０を介してクライアント端末３１や物理マシン２０１，２０２と通信する。通信インタフェース１０７は、スイッチやルータなどの有線通信装置に接続される有線通信インタフェースである。ただし、通信インタフェース１０７が、基地局やアクセスポイントなどの無線通信装置に接続される無線通信インタフェースであってもよい。

次に、監視対象システム２００の仮想環境について説明する。
図４は、仮想化インフラストラクチャの階層例を示す図である。
監視対象システム２００は、コンピュータ仮想化技術として、ハイパーバイザ型仮想化とコンテナ型仮想化を併用する。ハイパーバイザ型仮想化では、仮想化ソフトウェアであるハイパーバイザを用いて、ゲストＯＳを含む仮想マシンを形成する。コンテナ型仮想化では、仮想化ソフトウェアであるコンテナエンジンを用いて、ゲストＯＳを含まないコンテナを形成する。物理マシン、仮想マシンおよびコンテナは何れも、アプリケーションからコンピュータとして認識され得る処理ノードである。ただし、仮想マシンおよびコンテナは、物理マシンそのものではない仮想処理ノードである。

第２の実施の形態では、コンテナがアプリケーションを実行する。監視対象システム２００は、物理マシンの上にコンテナを配置する２階層の仮想環境と、物理マシンの上に仮想マシンを配置し仮想マシンの上にコンテナを配置する３階層の仮想環境とを併用する。２階層の仮想環境では、物理マシンの上で１以上のコンテナが動作し、各コンテナの上で１以上のアプリケーションが動作する。３階層の仮想環境では、物理マシンの上で１以上の仮想マシンが動作し、各仮想マシンの上で１以上のコンテナが動作し、各コンテナの上で１以上のアプリケーションが動作する。１台の物理マシンの中に、２階層の仮想環境と３階層の仮想環境とを混在させることも可能である。

２階層の仮想環境では、物理マシンがホストＯＳ２４１およびコンテナエンジン２４４ａを実行する。ホストＯＳ２４１は、物理マシンのハードウェアリソースを管理し、物理マシン上でのプロセスの実行を制御する。ハードウェアリソースには、ＣＰＵの演算能力、ＲＡＭの記憶領域、ＨＤＤの記憶領域、通信インタフェースの通信帯域などが含まれる。メモリ空間がカーネル空間とユーザ空間とに分けて管理される。ホストＯＳ２４１は、コンテナから見てベースＯＳと言われることもある。

ホストＯＳ２４１は、物理マシンの稼働状況を示すログを生成する。ホストＯＳ２４１が生成するログは、物理マシンの障害を示すことがある。物理マシンの障害には、ハードウェアリソースのアクセス異常や、重要な管理用プロセスの異常停止が含まれる。物理マシンは、ホスト名、ＩＰ（Internet Protocol）アドレス、ＭＡＣ（Medium Access Control）アドレスなどの識別子をもつ。ホストＯＳ２４１は、物理マシンの識別子を知っている。

コンテナエンジン２４４ａは、物理マシンの直上に１以上のコンテナを形成する仮想化ソフトウェアである。コンテナエンジン２４４ａは、物理マシンが有するハードウェアリソースの一部をコンテナに割り当てる。コンテナエンジン２４４ａは、ホストＯＳ２４１が管理するユーザ空間の一部を仮想ユーザ空間としてコンテナに提供する。コンテナエンジン２４４ａは、物理マシン上で動作するコンテナを把握している。

また、２階層の仮想環境では、コンテナがコンテナライブラリ２４５ａおよびサイドカープロキシ２４６ａを実行する。コンテナライブラリ２４５ａは、コンテナに割り当てられたハードウェアリソースを用いて、コンテナ上でのプロセスの実行を制御する。コンテナライブラリ２４５ａは、コンテナエンジン２４４ａから割り当てられた仮想ユーザ空間を使用する。コンテナライブラリ２４５ａは、ＯＳそのものではないものの、アプリケーションに対して限定的なＯＳ機能をＡＰＩ（Application Programming Interface）として提供する。アプリケーションからＯＳのように見えることがあるため、コンテナライブラリ２４５ａをコンテナＯＳと言うことがある。

コンテナライブラリ２４５ａは、コンテナの稼働状況を示すログを生成する。コンテナライブラリ２４５ａが生成するログには、コンテナが実行するアプリケーションの障害を示すことがある。アプリケーションの障害には、他のアプリケーションとの通信失敗や、アプリケーションのプロセスの異常停止が含まれる。コンテナは、ホスト名やアドレスなどの識別子をもつ。コンテナライブラリ２４５ａは、コンテナの識別子を知っている。

サイドカープロキシ２４６ａは、プロキシサーバのソフトウェアである。サイドカープロキシ２４６ａは、コンテナで実行されるアプリケーションが他のアプリケーション（特に、他のコンテナ上のアプリケーション）と通信するとき、アプリケーション層において通信を中継する。これにより、サイドカープロキシ２４６ａは、アプリケーション間で行われるメッセージ通信を把握することができる。コンテナライブラリ２４５ａまたはサイドカープロキシ２４６ａは、コンテナ上で動作するアプリケーションを把握している。

また、２階層の仮想環境では、上記のコンテナの上にサービスノード２４７ａが配置される。サービスノード２４７ａは、あるサービスを実現するために細分化されて実装された１つのアプリケーションである。サービスノード２４７ａは、コンテナライブラリ２４５ａの制御のもとで実行される。サービスノード２４７ａは、例えば、Ｗｅｂサーバ、業務ロジックサーバ、データベースサーバなどのサーバアプリケーションである。サービスノード２４７ａは、単一のユーザプログラムまたは２以上のユーザプログラムの集合によって実装される。また、サービスノード２４７ａは、単一のプロセスまたは２以上のプロセスの集合として実行される。サービスノード２４７ａは、サーバ名やＵＲＬ（Uniform Resource Locator）などの識別子をもつ。

３階層の仮想環境では、物理マシンがハイパーバイザ２４２を実行する。ハイパーバイザ２４２は、物理マシンの直上に１以上の仮想マシンを形成する仮想化ソフトウェアである。ハイパーバイザ２４２は、物理マシンが有するハードウェアリソースの一部を仮想マシンに割り当てる。ハイパーバイザ２４２は、物理マシン上で動作する仮想マシンを把握している。なお、３階層の仮想環境でも、物理マシンは管理用ＯＳを実行している。

また、３階層の仮想環境では、仮想マシンがゲストＯＳ２４３およびコンテナエンジン２４４ｂを実行する。ゲストＯＳ２４３は、仮想マシンに割り当てられたハードウェアリソースを管理し、仮想マシン上でのプロセスの実行を制御する。ゲストＯＳ２４３は、コンテナから見てベースＯＳと言われることもある。ゲストＯＳ２４３は、仮想マシンの稼働状況を示すログを生成する。ゲストＯＳ２４３が生成するログは、仮想マシンの障害を示すことがある。仮想マシンの障害には、割り当てられたハードウェアリソースのアクセス異常や、重要な管理用プロセスの異常停止が含まれる。仮想マシンは、ホスト名やアドレスなどの識別子をもつ。ゲストＯＳ２４３は、仮想マシンの識別子を知っている。

コンテナエンジン２４４ｂは、仮想マシンの直上に１以上のコンテナを形成する仮想化ソフトウェアである。コンテナエンジン２４４ｂは、仮想マシンに割り当てられたハードウェアリソースの一部を更にコンテナに割り当てる。コンテナエンジン２４４ｂは、ゲストＯＳ２４３が管理するユーザ空間の一部を仮想ユーザ空間としてコンテナに提供する。コンテナエンジン２４４ｂは、仮想マシン上で動作するコンテナを把握している。

また、３階層の仮想環境では、コンテナがコンテナライブラリ２４５ｂおよびサイドカープロキシ２４６ｂを実行する。コンテナライブラリ２４５ｂの機能はコンテナライブラリ２４５ａと同様である。サイドカープロキシ２４６ｂの機能は、サイドカープロキシ２４６ａと同様である。また、３階層の仮想環境では、上記のコンテナの上にサービスノード２４７ｂが配置される。サービスノード２４７ｂは、１つのアプリケーションである。サービスノード２４７ｂは、サービスノード２４７ａと通信して連携することがある。

ここで、サービスノード２４７ａ，２４７ｂなどのアプリケーションの機能に生じた障害を、アプリケーション障害または略して「アプリ障害」と言うことがある。また、物理マシン、仮想マシン、コンテナなどの処理ノードの機能に生じた障害を、インフラストラクチャ障害または略して「インフラ障害」と言うことがある。第２の実施の形態では、インフラ障害として主に、物理マシンの障害と仮想マシンの障害を想定する。

図５は、システム構成グラフの例を示す図である。
第２の実施の形態の説明では、一例として、図５に示すような処理ノードおよびサービスノードの配置を使用する。監視対象システム２００は、処理ノードとして、物理マシン２０１，２０２、仮想マシン２１１，２１２およびコンテナ２２１，２２２，２２３，２２４，２２５，２２６を含む。また、監視対象システム２００は、サービスノード２３１，２３２，２３３，２３４，２３５，２３６を含む。これらの処理ノードおよびサービスノードのトポロジは、スイッチ２０３をルートとする木構造になっている。

物理マシン２０１（Ｍ１）の直上には、仮想マシン２１１（ＶＭ１）およびコンテナ２２１，２２２（Ｃ１，Ｃ２）が配置されている。仮想マシン２１１の直上には、コンテナ２２３，２２４（Ｃ３，Ｃ４）が配置されている。物理マシン２０２（Ｍ２）の直上には、仮想マシン２１２（ＶＭ２）およびコンテナ２２６（Ｃ６）が配置されている。仮想マシン２１２の直上には、コンテナ２２５（Ｃ５）が配置されている。

コンテナ２２１は、サービスノード２３１（ＡＰ１）を実行する。コンテナ２２２は、サービスノード２３２（ＡＰ２）を実行する。コンテナ２２３は、サービスノード２３３（ＡＰ３）を実行する。コンテナ２２４は、サービスノード２３４（ＡＰ４）を実行する。コンテナ２２５は、サービスノード２３５（ＡＰ５）を実行する。コンテナ２２６は、サービスノード２３６（ＡＰ６）を実行する。

図６は、サービスメッシュグラフの例を示す図である。
サービスノード２３１，２３２，２３３，２３４，２３５，２３６は、相互に通信することで、連携して１つのサービスを実現する。サービスノード間の通信には、例えば、ＲＥＳＴ（Representational State Transfer）などの軽量な通信ＡＰＩが使用される。前述のサイドカープロキシ２４６ａ，２４６ｂに相当するサイドカープロキシを用いることで、サービスノード間のメッセージ通信の状況を把握することが可能である。

サービスノードのペアの中には、直接通信することがあるペアもあるし、直接通信することがないペアもある。直接通信することがある２つのサービスノードの間にエッジを記述すると、図６に示すようなサービスメッシュグラフを生成することができる。サービスメッシュグラフは、サービスノードを示す節点とサービスノード間の通信を示す節点間のエッジとを含む無向グラフである。第２の実施の形態の説明では、一例として、図６に示すサービスメッシュグラフを使用する。

サービスノード２３１（ＡＰ１）は、サービスノード２３３と通信する。サービスノード２３２（ＡＰ２）は、サービスノード２３３，２３４，２３６と通信する。サービスノード２３３（ＡＰ３）は、サービスノード２３１，２３２，２３４と通信する。サービスノード２３４（ＡＰ４）は、サービスノード２３２，２３３と通信する。サービスノード２３５（ＡＰ５）は、サービスノード２３６と通信する。サービスノード２３６（ＡＰ６）は、サービスノード２３２，２３５と通信する。上記以外のサービスノードのペアは、直接には通信しない。ただし、このサービスメッシュグラフは連結グラフであるため、任意の２つのサービスノードを結ぶパスが存在する。よって、全てのサービスノードが連携している。

次に、原因判定モデルの生成について説明する。
図７は、原因判定モデルの生成例を示す図である。
管理サーバ１００は、原因判定モデル１５１を生成する。原因判定モデル１５１は、ロジスティック回帰分析によって生成される回帰モデルである。原因判定モデル１５１は、１つのアプリ障害と１つのインフラ障害との間の関係を示す特徴ベクトルを、説明変数として使用する。また、原因判定モデル１５１は、当該１つのアプリ障害の原因が当該１つのインフラ障害である確率を示す確信度を、目的変数として使用する。

よって、原因判定モデル１５１は、監視対象システム２００で同時期に発生したアプリ障害とインフラ障害について、アプリ障害の根本原因がインフラ障害であるか否か判定するものである。ある処理ノードにおける通信プロセスの異常終了が、あるサービスノードのメッセージ通信の失敗を引き起こすなど、インフラ障害がサービスノードに伝播することがある。その場合、システム管理者は、アプリ障害への対応として、その原因となっているインフラ障害を解消すればよい。このため、原因判定モデル１５１を使用することで、システム管理者に対して有用な情報を提供することができる。

原因判定モデル１５１を生成するにあたり、管理サーバ１００は、過去に発生したアプリ障害とインフラ障害のペア毎に、特徴ベクトル１４１と教師ラベル１４２とを対応付けたレコードを生成して訓練データに追加する。特徴ベクトル１４１は、評価値ｖ_１，ｖ_２，ｖ_３，ｖ_４を含む４次元ベクトルである。評価値ｖ_１は、親子距離１４３を表す。評価値ｖ_２は、サービス距離１４４を表す。評価値ｖ_３は、テキスト類似度１４５を表す。評価値ｖ_４は、時刻差１４６を表す。教師ラベル１４２は、着目するアプリ障害の原因が、着目するインフラ障害であるか否かを示すフラグである。障害原因であるか否かは、過去にシステム管理者が行った障害対応作業の結果として把握される。インフラ障害がアプリ障害の原因でない場合、教師ラベル１４２が「０」となる。インフラ障害がアプリ障害の原因である場合、教師ラベル１４２が「１」となる。

親子距離１４３は、アプリ障害とインフラ障害との間の処理ノードの階層関係を示す。具体的には、親子距離１４３は、アプリ障害が発生したサービスノードを実行するコンテナ、すなわち、アプリ障害を検出したコンテナと、インフラ障害を検出した物理マシンまたは仮想マシンとの間の階層関係を示す。上記のコンテナが上記の物理マシンまたは仮想マシンの上方に配置されている場合、すなわち、親子関係が存在する場合、当該コンテナと当該物理マシンまたは仮想マシンとの間の階層差が、親子距離１４３となる。一方、上記のコンテナが上記の物理マシンまたは仮想マシンの上方に配置されていない場合、すなわち、親子関係が存在しない場合、親子距離１４３は「０」とみなされる。

例えば、図５において、サービスノード２３３でアプリ障害が発生し、仮想マシン２１１でインフラ障害が発生した場合、親子距離１４３は「１」となる。サービスノード２３３でアプリ障害が発生し、物理マシン２０１でインフラ障害が発生した場合、親子距離１４３は「２」となる。サービスノード２３３でアプリ障害が発生し、物理マシン２０２でインフラ障害が発生した場合、親子距離１４３は「０」となる。親子距離１４３が小さいほど（ただし「０」を除く）、インフラ障害がアプリ障害の原因である可能性が高い。なお、親子距離１４３は、例えば、スイッチ２０３をルートとする木構造において各処理ノードの深さを算出し、２つの処理ノードの深さの差を求めることで算出できる。

サービス距離１４４は、アプリ障害とインフラ障害に関係するサービスノード間の通信関係を示す。具体的には、サービス距離１４４は、アプリ障害が発生したサービスノードと、インフラ障害を検出した物理マシンまたは仮想マシンを基盤として実行されている他のサービスノードとの間の通信関係を示す。アプリ障害が発生したサービスノードと上記の他のサービスノードとの間に、サービスメッシュグラフ上のパスが存在する場合、当該パスの長さ（距離）がサービス距離１４４となる。上記の他のサービスノードが２以上ある場合、２以上の他のサービスノードそれぞれに対して算出される距離のうちの最小値がサービス距離１４４となる。一方、何れの他のサービスノードとの間にもパスが存在しない場合、サービス距離１４４は「０」とみなされる。

例えば、図５において、サービスノード２３３でアプリ障害が発生し、仮想マシン２１１でインフラ障害が発生したとする。この場合、インフラ障害がある仮想マシン２１１の上方で実行されているサービスノードは、サービスノード２３３，２３４である。すると、図６のサービスメッシュグラフにおいて、｛ＡＰ３｝と｛ＡＰ３，ＡＰ４｝の間の最小距離は「０」である。このため、サービス距離１４４は「０」となる。

また、例えば、図５において、サービスノード２３３でアプリ障害が発生し、物理マシン２０２でインフラ障害が発生したとする。この場合、インフラ障害がある物理マシン２０２の上方で実行されているサービスノードは、サービスノード２３５，２３６である。すると、図６のサービスメッシュグラフにおいて、｛ＡＰ３｝と｛ＡＰ５，ＡＰ６｝の間の最小距離は「２」である。このため、サービス距離１４４は「２」となる。サービス距離１４４が小さいほど（ただし「０」を除く）、インフラ障害がアプリ障害の原因である可能性が高い。なお、サービス距離１４４は、例えば、サービスメッシュグラフに対して、ダイクストラ法などの最短経路探索アルゴリズムを実行することで算出できる。

テキスト類似度１４５は、アプリ障害とインフラ障害との間のエラーメッセージの類似度を示す。アプリ障害のエラーメッセージとインフラ障害のエラーメッセージとの間に共通単語が多いほど、テキスト類似度１４５が大きくなる。テキスト類似度１４５が大きいほど、インフラ障害がアプリ障害の原因である可能性が高い。

テキスト類似度１４５として、第２の実施の形態では、Bug of Wordsのコサイン類似度を使用する。Bug of Wordsの生成では、管理サーバ１００は、エラーメッセージ毎に文字列を単語に分割し、同一単語の出現数をカウントする。管理サーバ１００は、エラーメッセージ毎に、各単語の出現数を列挙したベクトルをBug of Wordsとして生成する。管理サーバ１００は、２つのエラーメッセージに対応する２つのベクトルの間でコサイン類似度を算出する。コサイン類似度は、０以上１以下の実数である。コサイン類似度が１に近いほど２つのエラーメッセージの類似度が高いことを意味し、コサイン類似度が０に近いほど２つのエラーメッセージの類似度が低いことを意味する。

ただし、コサイン類似度は、テキスト類似度１４５の一例である。テキスト類似度１４５の指標として、分散表現を使用するものや、編集距離（レーベンシュタイン距離）を使用するものなど、他の指標も考えられる。また、エラーメッセージからホスト名やアドレスなどの識別子を除去するなど、前処理を行うようにしてもよい。

時刻差１４６は、アプリ障害の発生とインフラ障害の発生の間の遅延を示す。アプリ障害の発生時刻がインフラ障害の発生時刻以後である場合、時刻差１４６は、アプリ障害の発生時刻からインフラ障害の発生時刻を引いた差となる。第２の実施の形態では、時刻差１４６の単位として時間（hour）を使用する。一方、アプリ障害の発生時刻がインフラ障害の発生時刻より前である場合、時刻差１４６は「０」とみなされる。例えば、アプリ障害の発生時刻が２０２０年４月１日１６時０分であり、インフラ障害の発生時刻が２０２０年４月１日１５時０分である場合、時刻差１４６は「１」となる。時刻差１４６が小さいほど（ただし「０」を除く）、インフラ障害がアプリ障害の原因である可能性が高い。

特徴ベクトル１４１が、親子距離１４３を示す評価値ｖ_１を含むことで、下位の階層の処理ノードの障害が上位の階層の処理ノードに影響を与えるという垂直方向の障害伝播を評価することができる。また、特徴ベクトル１４１が、サービス距離１４４を示す評価値ｖ_２を含むことで、あるサービスノードの障害が別のサービスノードに影響を与えるという水平方向の障害伝播を評価することができる。また、特徴ベクトル１４１が、テキスト類似度１４５を示す評価値ｖ_３を含むことで、障害内容の類似性を評価することができる。また、特徴ベクトル１４１が、時刻差１４６を示す評価値ｖ_４を含むことで、アプリ障害とインフラ障害の発生の同時性を評価することができる。

一方で、特徴ベクトル１４１は、ホスト名やアドレスなどの識別子に関する評価値を含まない。これは、処理ノードやサービスノードの識別子を使用すると、処理ノードの構成が変化した場合に原因判定モデル１５１の判定精度が低下し、原因判定モデル１５１を再生成せざるを得なくなる可能性があるためである。

監視対象システム２００では、仮想マシンの追加、移動、削除により、物理マシンと仮想マシンとの対応関係が変化し得る。また、監視対象システム２００では、コンテナの追加、移動、削除により、物理マシンまたは仮想マシンとコンテナとの対応関係が変化し得る。この点、原因判定モデル１５１の入力に識別子を使用すると、構成変更によって原因判定モデル１５１の有用性が低下するおそれがある。これに対して、原因判定モデル１５１の入力に識別子を使用しないことで、仮想マシンやコンテナの配置変更があっても、原因判定モデル１５１を引き続き使用することができる。

管理サーバ１００は、上記のような特徴ベクトル１４１および教師ラベル１４２を含む訓練データを用いて、原因判定モデル１５１を生成する。原因判定モデル１５１は、例えば、数式（１）に示すようなロジスティック関数として表現される。数式（１）のロジスティック関数は、評価値ｖ_１’，ｖ_２’，ｖ_３，ｖ_４’から確信度Ｐを算出する。ここで算出される確信度Ｐは、０より大きく１より小さい実数である。確信度Ｐが１に近いほど、インフラ障害がアプリ障害の原因である可能性が高く、確信度Ｐが０に近いほど、インフラ障害がアプリ障害の原因である可能性が低い。

評価値ｖ_１’，ｖ_２’，ｖ_４’は、後述するように、評価値ｖ_１，ｖ_２，ｖ_４から変換されるものである。また、このロジスティック関数は、パラメータα，β_１，β_２，β_３，β_４を含む。パラメータα，β_１，β_２，β_３，β_４の値は、訓練データを用いて機械学習を通じて決定される。パラメータαは定数である。パラメータβ_１は評価値ｖ_１’の重み係数である。パラメータβ_２は評価値ｖ_２’の重み係数である。パラメータβ_３は評価値ｖ_３の重み係数である。パラメータβ_４は評価値ｖ_４’の重み係数である。

評価値ｖ_１’は、評価値ｖ_１から数式（２）のように変換される。ｖ_１＝０の場合はｖ_１’＝０となり、それ以外の場合はｖ_１が大きいほどｖ_１’が小さくなる。評価値ｖ_１’は、０以上１以下の実数である。評価値ｖ_２’は、評価値ｖ_２から数式（３）のように変換される。ｖ_２＝０の場合はｖ_２’＝０となり、それ以外の場合はｖ_２が大きいほどｖ_２’が小さくなる。評価値ｖ_２’は、０以上１以下の実数である。評価値ｖ_４’は、評価値ｖ_４から数式（４）のように変換される。ｖ_４＝０の場合はｖ_４’＝０となり、それ以外の場合はｖ_４が大きいほどｖ_４’が小さくなる。評価値ｖ_４’は、０以上の実数である。

管理サーバ１００は、このようにして生成した原因判定モデル１５１を使用して、同時期に発生したアプリ障害とインフラ障害との間の関連性を評価する。あるアプリ障害が発生したときに、その直近に２以上のインフラ障害が発生していることがある。その場合、管理サーバ１００は、当該アプリ障害と当該２以上のインフラ障害それぞれとの間で、原因判定モデル１５１を用いて確信度を算出する。管理サーバ１００は、２以上のインフラ障害を確信度の高い順にソートしてシステム管理者に提示する。

図８は、システム管理画面の例を示す図である。
システム管理画面１５２は、管理サーバ１００からクライアント端末３１に送信され、クライアント端末３１のディスプレイに表示される。システム管理画面１５２は、あるアプリケーションに障害が発生したことを示すメッセージを含む。また、システム管理画面１５２は、アプリ障害と同時期に、物理マシンや仮想マシンなどの処理ノードに障害が発生していることを示すメッセージを含む。また、システム管理画面１５２は、インフラ障害毎に、アプリ障害の原因である可能性を示す確信度の数値を含む。インフラ障害のメッセージは、確信度の降順にソートされている。

例えば、システム管理画面１５２は、サービスノード２３３（ＡＰ３）のアプリ障害を報告する。また、システム管理画面１５２は、仮想マシン２１１（ＶＭ１）のインフラ障害と、そのインフラ障害がアプリ障害の原因である可能性が９０％である旨を報告する。また、システム管理画面１５２は、物理マシン２０２（Ｍ２）のインフラ障害と、そのインフラ障害がアプリ障害の原因である可能性が４０％である旨を報告する。これにより、システム管理者は、アプリ障害の原因分析と障害解消作業を効率的に行うことができる。

次に、管理サーバ１００の機能について説明する。
図９は、管理サーバの機能例を示すブロック図である。
管理サーバ１００は、障害情報記憶部１２１、構成情報記憶部１２２、サービス情報記憶部１２３およびモデル記憶部１２４を有する。これらの記憶部は、例えば、ＲＡＭ１０２またはＨＤＤ１０３の記憶領域を用いて実現される。また、管理サーバ１００は、障害監視部１２５、構成監視部１２６、サービス監視部１２７、学習部１２８および原因判定部１２９を有する。これらの処理部は、例えば、プログラムを用いて実現される。

障害情報記憶部１２１は、監視対象システム２００で発生した障害を示す障害情報を記憶する。また、障害情報記憶部１２１は、障害に対するシステム管理者の障害対応を示す障害対応情報を記憶する。構成情報記憶部１２２は、物理マシン、仮想マシンおよびコンテナの配置を示す構成情報を記憶する。サービス情報記憶部１２３は、複数のサービスノードの間の通信関係を示すサービスメッシュグラフの情報を記憶する。また、サービス情報記憶部１２３は、コンテナへのサービスノードの配置を示す情報を記憶する。モデル記憶部１２４は、管理サーバ１００が生成した原因判定モデル１５１を記憶する。

障害監視部１２５は、監視対象システム２００の障害を監視する。障害監視部１２５は、監視対象システム２００から障害に関する情報を収集し、障害情報を障害情報記憶部１２１に保存する。障害に関する情報は、物理マシンのホストＯＳ、仮想マシンのゲストＯＳ、コンテナのコンテナライブラリなどから収集することができる。監視方法として、物理マシン、仮想マシンおよびコンテナなどの各処理ノードが、障害を検出したときに、管理サーバ１００に対して障害を通知するようにしてもよい。また、障害監視部１２５が定期的に各処理ノードからエラーログを収集するようにしてもよい。また、障害監視部１２５が定期的に各処理ノードから各種ログを収集し、ログを分析して障害の有無を判定し、障害を検出したときにログから障害情報を抽出するようにしてもよい。

構成監視部１２６は、監視対象システム２００の仮想環境の構成を監視する。障害監視部１２５は、物理マシン、仮想マシンおよびコンテナの配置が変更されたことを検出すると、変更後の配置を示す構成情報を構成情報記憶部１２２に保存する。物理マシンと仮想マシンとの間の関係は、物理マシンで実行されているハイパーバイザから収集することができる。物理マシンまたは仮想マシンとコンテナとの間の関係は、物理マシンまたは仮想マシンで実行されているコンテナエンジンから収集することができる。

サービス監視部１２７は、監視対象システム２００に配置された複数のサービスノード（アプリケーション）を監視する。サービス監視部１２７は、複数のサービスノードの間の通信関係が変化したことを検出すると、変更後の通信関係を示す情報をサービス情報記憶部１２３に保存する。サービスノード間の通信関係は、コンテナで実行されているサイドカープロキシから収集することができる。また、サービス監視部１２７は、コンテナへのサービスノードの配置が変更されたことを検出すると、変更後の配置を示す情報をサービス情報記憶部１２３に保存する。サービスノードの配置は、コンテナで実行されているコンテナライブラリまたはサイドカープロキシから収集することができる。

学習部１２８は、障害情報記憶部１２１、構成情報記憶部１２２およびサービス情報記憶部１２３に記憶された情報から訓練データを生成し、ロジスティック回帰分析により原因判定モデル１５１を生成する。学習部１２８は、原因判定モデル１５１をモデル記憶部１２４に保存する。また、学習部１２８は、原因判定部１２９による障害原因の予測に対応する障害対応情報がシステム管理者から提供されると、予測と正解との間の誤差に基づいて、判定精度が上がるように原因判定モデル１５１を更新する。

原因判定部１２９は、新たなアプリ障害が検出されると、障害情報記憶部１２１に記憶された障害情報に基づいて、システム管理画面１５２を生成してクライアント端末３１に送信する。このとき、原因判定部１２９は、障害情報記憶部１２１、構成情報記憶部１２２およびサービス情報記憶部１２３に記憶された情報から特徴ベクトルを生成し、モデル記憶部１２４に記憶された原因判定モデル１５１に入力する。これにより、原因判定部１２９は、アプリ障害と同時期に発生しているインフラ障害それぞれの確信度を算出し、算出した確信度をシステム管理画面１５２に含めて送信する。

その後、原因判定部１２９は、クライアント端末３１から障害対応情報を受信して障害情報記憶部１２１に保存する。障害対応情報には、確信度を算出したアプリ障害とインフラ障害のペアに対して、障害原因であったか否かを示す正解の教師ラベルが含まれる。原因判定部１２９は、学習部１２８に原因判定モデル１５１を更新させる。

図１０は、障害テーブルの例を示す図である。
障害テーブル１３１は、障害情報記憶部１２１に記憶される。障害テーブル１３１は、障害ＩＤ、時刻、検出ノード、障害種別、メッセージ、対応フラグおよび原因ＩＤの項目をそれぞれ含む複数のレコードを記憶する。障害ＩＤとして、障害を識別する識別子が登録される。時刻として、障害が発生した時刻または障害が認識された時刻が登録される。検出ノードとして、障害を検出した処理ノードの識別子が登録される。障害を検出する処理ノードは、物理マシン、仮想マシンまたはコンテナである。

障害種別として、アプリ障害であるかインフラ障害であるかの区分が登録される。コンテナで検出されたサービスノード（アプリケーション）の障害は、アプリ障害である。物理マシンまたは仮想マシンで検出された障害は、インフラ障害である。メッセージとして、ログに含まれるエラーメッセージのテキストが登録される。対応フラグとして、システム管理者の障害対応作業によって障害が既に解消しているか未解消であるかを示すフラグが登録される。障害対応作業によって、障害原因が別の障害であるとシステム管理者が結論付けた場合、原因ＩＤとして原因の障害の障害ＩＤが登録される。対応フラグおよび原因ＩＤは、障害対応情報に基づいて追記される情報である。

図１１は、構成テーブルの例を示す図である。
構成テーブル１３２は、構成情報記憶部１２２に記憶される。構成テーブル１３２は、時刻、親ノード、子ノードおよび距離の項目をそれぞれ含む複数のレコードを記憶する。時刻として、構成変更が検出された時刻が登録される。親ノードとして、下位（物理マシンに近い方）にある処理ノードの識別子が登録される。子ノードとして、親ノードの上位（アプリケーションに近い方）にある処理ノードの識別子が登録される。

親ノードおよび子ノードはそれぞれ、物理マシン、仮想マシンまたはコンテナである。子ノードは、親ノードで実行されていることもある。また、親ノードで別の処理ノードが実行され、その処理ノードで子ノードが実行されていることもある。距離として、親ノードと子ノードとの間の親子距離が登録される。距離は、垂直方向の階層の差である。物理マシンで仮想マシンが実行され、仮想マシンでコンテナが実行されている場合、物理マシンと仮想マシンの間の距離は「１」であり、仮想マシンとコンテナの間の距離は「１」である。また、物理マシンとコンテナの間の距離は「２」である。一方の処理ノードの上に他方の処理ノードがあるという親子関係が存在しないペア、すなわち、距離が「０」のペアは、構成テーブル１３２に登録しなくてもよい。

図１２は、サービス距離テーブルとサービス配置テーブルの例を示す図である。
サービス距離テーブル１３３は、サービス情報記憶部１２３に記憶される。サービス距離テーブル１３３は、時刻、始点ノード、終点ノードおよび距離の項目をそれぞれ含む複数のレコードを記憶する。時刻として、サービスメッシュグラフの変更が検出された時刻が登録される。サービスメッシュグラフは、コンテナの追加や削除、アプリケーションプログラムの更新などによって変化することがある。

始点ノードとして、直接通信する２つのサービスノードのうちの一方の識別子が登録される。終点ノードとして、直接通信する２つのサービスノードのうちの他方の識別子が登録される。サービスメッシュグラフは無向グラフであるため、始点ノードと終点ノードを入れ替えたものを別レコードとして登録しなくてもよい。距離として、サービスメッシュグラフにおける始点ノードと終点ノードとの間のパスのホップ数が登録される。

サービス配置テーブル１３４は、サービス情報記憶部１２３に記憶される。サービス配置テーブル１３４は、時刻、サービスノードおよびコンテナの項目をそれぞれ含む複数のレコードを記憶する。時刻として、サービスノードの配置変更が検出された時刻が登録される。サービスノードとして、配置されるサービスノードの識別子が登録される。コンテナとして、サービスノードを配置したコンテナの識別子が登録される。サービスノードの配置は、コンテナの追加や削除などによって変化することがある。

図１３は、訓練データテーブルの例を示す図である。
訓練データテーブル１３５は、学習部１２８によって生成される。訓練データテーブル１３５が、モデル記憶部１２４に保存されてもよい。訓練データテーブル１３５は、アプリ障害、インフラ障害、評価値ｖ_１，ｖ_２，ｖ_３，ｖ_４、評価値ｖ_１’，ｖ_２’，ｖ_４’および教師ラベルの項目をそれぞれ含む複数のレコードを記憶する。

アプリ障害として、障害種別がアプリ障害である障害の障害ＩＤが登録される。インフラ障害として、障害種別がインフラ障害である障害の障害ＩＤが登録される。評価値ｖ_１として、アプリ障害とインフラ障害のペアに対して算出された親子距離が登録される。評価値ｖ_２として、上記のペアに対して算出されたサービス距離が登録される。評価値ｖ_３として、上記のペアに対して算出されたテキスト類似度が登録される。評価値ｖ_４として、上記のペアに対して算出された時刻差が登録される。評価値ｖ_１’，ｖ_２’，ｖ_４’として、評価値ｖ_１，ｖ_２，ｖ_４から変換された補正値が登録される。教師ラベルとして、インフラ障害がアプリ障害の原因か否かを示すフラグが登録される。

次に、管理サーバ１００の処理手順について説明する。
図１４は、モデル生成の手順例を示すフローチャートである。
（Ｓ１０）学習部１２８は、障害テーブル１３１から、複数のアプリ障害の障害情報と複数のインフラ障害の障害情報とを分けて抽出する。

（Ｓ１１）学習部１２８は、アプリ障害とインフラ障害の組を１つ選択する。なお、ステップＳ１０において、ｍ個のアプリ障害の障害情報とｎ個のインフラ障害の障害情報とが抽出された場合、アプリ障害とインフラ障害の組の候補はｍ×ｎ個存在する。

（Ｓ１２）学習部１２８は、アプリ障害を検出した検出ノードとインフラ障害を検出した検出ノードとを特定する。学習部１２８は、構成テーブル１３２から、２つの検出ノードの間の親子距離を検索して評価値ｖ_１とする。なお、２つの検出ノードの間の親子距離が構成テーブル１３２に登録されていない場合はｖ_１＝０とする。また、構成テーブル１３２を参照するにあたり、障害時刻の直前の情報を使用する。

（Ｓ１３）学習部１２８は、構成テーブル１３２を参照して、インフラ障害を検出した検出ノードと親子関係にあるコンテナを検索する。学習部１２８は、サービス配置テーブル１３４を参照して、検索したコンテナで実行されるサービスノードを検索する。なお、サービス配置テーブル１３４を参照するにあたり、障害時刻の直前の情報を使用する。

（Ｓ１４）学習部１２８は、サービス距離テーブル１３３から、アプリ障害が発生しているサービスノードとステップＳ１３で検索されたサービスノードそれぞれとの間のサービス距離を検索する。学習部１２８は、検索されたサービス距離のうちの最小のサービス距離を評価値ｖ_２とする。なお、異なるサービスノードの間のサービス距離がサービス距離テーブル１３３に登録されていない場合、当該異なるサービスノードは非連結である。ステップＳ１３で検索されたサービスノードの全てが、アプリ障害が発生しているサービスノードと非連結である場合、ｖ_２＝０とする。また、サービス距離テーブル１３３を参照するにあたり、障害時刻の直前の情報を使用する。

（Ｓ１５）学習部１２８は、アプリ障害の障害情報およびインフラ障害の障害情報それぞれからエラーメッセージを抽出する。学習部１２８は、抽出した２つのエラーメッセージの間でテキスト類似度を算出して評価値ｖ_３とする。例えば、学習部１２８は、エラーメッセージ毎にテキストを単語に分割してBug of Wordsのベクトルを算出し、２つのベクトルの間でコサイン類似度を算出して評価値ｖ_３とする。

（Ｓ１６）学習部１２８は、アプリ障害の障害情報およびインフラ障害の障害情報それぞれから障害時刻を抽出する。学習部１２８は、抽出した２つの障害時刻の間の時刻差を算出して評価値ｖ_４とする。時刻差の単位は、例えば、時間（hour）とする。なお、インフラ障害の方がアプリ障害より遅い場合、ｖ_４＝０とする。

（Ｓ１７）学習部１２８は、ステップＳ１２で算出した評価値ｖ_１を、数式（２）に従って評価値ｖ_１’に変換する。また、学習部１２８は、ステップＳ１４で算出した評価値ｖ_２を、数式（３）に従って評価値ｖ_２’に変換する。また、学習部１２８は、ステップＳ１６で算出した評価値ｖ_４を、数式（４）に従って評価値ｖ_４’に変換する。学習部１２８は、評価値ｖ_１’，ｖ_２’，ｖ_３，ｖ_４’を含む特徴ベクトルを生成する。

（Ｓ１８）学習部１２８は、アプリ障害の障害情報に含まれる原因ＩＤに基づいて、着目するインフラ障害がアプリ障害の原因であるか判断する。インフラ障害がアプリ障害の原因でない場合、教師ラベルを「０」に決定する。インフラ障害がアプリ障害の原因である場合、教師ラベルを「１」に決定する。

（Ｓ１９）学習部１２８は、ステップＳ１７で生成した特徴ベクトルとステップＳ１８で決定した教師ラベルとを対応付けて、訓練データに追加する。
（Ｓ２０）学習部１２８は、ステップＳ１１において、全てのアプリ障害とインフラ障害の組を選択したか判断する。全ての組を選択した場合はステップＳ２１に進み、未選択の組がある場合はステップＳ１１に戻る。

（Ｓ２１）学習部１２８は、ステップＳ１０～Ｓ２０を通じて生成された訓練データを用いて、ロジスティック回帰分析により原因判定モデル１５１を生成する。ここでは、数式（１）に含まれるパラメータα，β_１，β_２，β_３，β_４が決定される。学習部１２８は、生成した原因判定モデル１５１をモデル記憶部１２４に保存する。

図１５は、障害原因判定の手順例を示すフローチャートである。
（Ｓ３０）原因判定部１２９は、新たなアプリ障害が発生したことを検出する。すると、原因判定部１２９は、障害テーブル１３１から、当該新たなアプリ障害の障害情報と未解消のインフラ障害の障害情報とを抽出する。

（Ｓ３１）原因判定部１２９は、インフラ障害を１つ選択する。
（Ｓ３２）原因判定部１２９は、前述のステップＳ１２と同様にして、アプリ障害の検出ノードとインフラ障害の検出ノードの間の親子距離を示す評価値ｖ_１を算出する。

（Ｓ３３）原因判定部１２９は、前述のステップＳ１３と同様にして、インフラ障害を検出した処理ノードの上位階層で実行されているサービスノードを検索する。
（Ｓ３４）原因判定部１２９は、前述のステップＳ１４と同様にして、サービスノード間のサービス距離を示す評価値ｖ_２を算出する。

（Ｓ３５）原因判定部１２９は、前述のステップＳ１５と同様にして、アプリ障害とインフラ障害の間のエラーメッセージの類似度を示す評価値ｖ_３を算出する。
（Ｓ３６）原因判定部１２９は、前述のステップＳ１６と同様にして、アプリ障害とインフラ障害の間の時刻差を示す評価値ｖ_４を算出する。

（Ｓ３７）原因判定部１２９は、前述のステップＳ１７と同様にして、評価値ｖ_１，ｖ_２，ｖ_４を評価値ｖ_１’，ｖ_２’，ｖ_４’に変換し、評価値ｖ_１’，ｖ_２’，ｖ_３，ｖ_４’を含む特徴ベクトルを生成する。

（Ｓ３８）原因判定部１２９は、ステップＳ３７で生成した特徴ベクトルを原因判定モデル１５１に入力し、確信度を算出する。
（Ｓ３９）原因判定部１２９は、ステップＳ３１において、全てのインフラ障害を選択したか判断する。全てのインフラ障害を選択した場合はステップＳ４０に進み、未選択のインフラ障害がある場合はステップＳ３１に戻る。

（Ｓ４０）原因判定部１２９は、未解消のインフラ障害を確信度の降順にソートする。
（Ｓ４１）原因判定部１２９は、アプリ障害の情報と、確信度の降順に並べた未解消のインフラ障害の情報と、各インフラ障害の確信度とを含むシステム管理画面１５２を生成し、システム管理画面１５２をクライアント端末３１に送信する。

図１６は、モデル更新の手順例を示すフローチャートである。
このモデル更新は、図１５の障害原因判定の後に実行される。
（Ｓ５０）原因判定部１２９は、クライアント端末３１から障害対応情報を受信する。障害対応情報は、アプリ障害の障害ＩＤと、インフラ障害の障害ＩＤと、そのインフラ障害がアプリ障害の原因であったか否かを示す教師ラベルとを含む。教師ラベルは、障害対応作業を通じてシステム管理者により判断された結果である。そのインフラ障害がアプリ障害の原因でない場合は教師ラベルが「０」となる。そのインフラ障害がアプリ障害の原因である場合は教師ラベルが「１」となる。原因判定部１２９は、受信した障害対応情報に基づいて、障害テーブル１３１を更新する。

（Ｓ５１）学習部１２８は、前述のステップＳ３７で生成された特徴ベクトルが保存されている場合、その特徴ベクトルを取得する。一方、学習部１２８は、特徴ベクトルが保存されていない場合、ステップＳ３２～Ｓ３７と同様にして特徴ベクトルを再生成する。

（Ｓ５２）学習部１２８は、前述のステップＳ３８で算出された確信度が保存されている場合、その確信度を取得する。一方、学習部１２８は、確信度が保存されていない場合、ステップＳ３８と同様にして確信度を再算出する。

（Ｓ５３）学習部１２８は、原因判定モデル１５１、特徴ベクトル、確信度および教師ラベルを用いて、オンライン学習により原因判定モデル１５１を更新する。オンライン学習には、確率的勾配降下法などの勾配法を用いることができる。例えば、学習部１２８は、確信度と教師ラベルの間の誤差を算出し、パラメータα，β_１，β_２，β_３，β_４の値をそれぞれ微少量だけ変化させたときの誤差の変化量から、パラメータα，β_１，β_２，β_３，β_４に対する誤差の勾配を算出する。学習部１２８は、誤差の勾配に所定の学習率を乗じた分だけパラメータα，β_１，β_２，β_３，β_４の値を変化させる。ただし、オンライン学習を行う代わりに、今回の特徴ベクトルと教師ラベルの組を訓練データに追加して、前述のステップＳ２１の機械学習を再実行してもよい。

第２の実施の形態の情報処理システムによれば、アプリ障害とインフラ障害とが同時期に発生している場合に、インフラ障害がアプリ障害の根本原因である可能性が評価され、その確信度がシステム管理者に対して提示される。複数のインフラ障害が発生している場合、確信度の高い順にそれら複数のインフラ障害が提示される。これにより、システム管理者の障害対応作業の負担が軽減され、障害解消までの所要時間を短縮できる。特に、物理マシン、仮想マシンおよびコンテナが階層的に配置された複雑な仮想環境において、細分化された多数のアプリケーションが多数のコンテナによって分散して実行されていても、インフラ障害が原因で引き起こされるアプリ障害の原因分析を効率化できる。

また、アプリ障害とインフラ障害の関連性の評価には、機械学習によって過去の障害情報から生成された原因判定モデルが使用される。原因判定モデルの説明変数には、処理ノードの階層関係を示す評価値が含まれる。よって、下位の階層の処理ノードで発生した障害が上位の階層の処理ノードに影響を与えるという垂直方向の障害伝播の可能性を考慮することができる。また、特徴ベクトルには、アプリケーション間の通信関係を示す評価値が含まれる。よって、あるアプリケーションの障害が別のアプリケーションに影響を与えるという水平方向の障害伝播の可能性を考慮することができる。

また、特徴ベクトルには、エラーメッセージの類似度を示す評価値が含まれる。よって、障害内容の類似性を考慮することができる。また、特徴ベクトルには、アプリ障害とインフラ障害の時刻差を示す評価値が含まれる。よって、遅延時間の側面から障害伝播の可能性を評価することができる。このように、上記の４つの観点を総合的に利用することで、原因判定モデルの判定精度を向上させることができる。また、原因判定モデルの入力には、物理マシン、仮想マシン、コンテナおよびアプリケーションの識別子は使用されない。このため、仮想環境の構成変更が行われても、生成した原因判定モデルの判定精度が低下しづらく、原因判定モデルの有用性を維持することができる。

１０ 制御装置
１１ 記憶部
１２ 処理部
１３，１４ 障害情報
１５ 教師ラベル
１６ 特徴情報
１６ａ，１６ｂ，１６ｃ 評価値
１７ モデル
２０ 情報処理システム
２１，２２，２３ 処理ノード
２４，２５ アプリケーション

Claims (8)

1. コンピュータに、
   それぞれが割り当てられたリソースを用いてアプリケーションを実行可能な処理ノードであって、仮想化ソフトウェアを用いて階層的に配置することが可能な複数の処理ノードを含み、複数のアプリケーションそれぞれが前記複数の処理ノードの何れかで実行される情報処理システムについて、第１のアプリケーションの障害を示す第１の障害情報と、第２の処理ノードの障害を示す第２の障害情報と、前記第１の障害情報と前記第２の障害情報との間の関連の有無を示す教師ラベルとを取得し、
   前記第１の障害情報および前記第２の障害情報に基づいて、前記第１のアプリケーションを実行する第１の処理ノードと前記第２の処理ノードとの間の配置の階層関係を示す第１の評価値と、前記第２の処理ノードの上に配置された処理ノードで実行される第２のアプリケーションと前記第１のアプリケーションとの間の依存関係を示す第２の評価値と、前記第１の障害情報に含まれる第１のエラーメッセージと前記第２の障害情報に含まれる第２のエラーメッセージとの間の類似度を示す第３の評価値とを算出し、
   前記第１の評価値、前記第２の評価値および前記第３の評価値を含む特徴情報と前記教師ラベルとを対応付けた訓練データを用いて、２つの障害情報についての特徴情報に対応する入力データから前記２つの障害情報の関連性の有無を推定するモデルを生成する、
   処理を実行させる制御プログラム。
2. 前記モデルの出力は、前記２つの障害情報の間の関連性の強さを示す確信度を含み、
   前記コンピュータに更に、
   前記モデルが生成された後、１つのアプリケーションの障害を示す第３の障害情報と、異なる処理ノードの障害を示す複数の第４の障害情報とを取得し、
   前記第３の障害情報と前記複数の第４の障害情報のうちの１つの第４の障害情報との組毎に、前記第３の障害情報および前記１つの第４の障害情報に基づいて前記入力データを生成し、前記入力データを前記モデルに入力して前記確信度を算出し、
   前記確信度に基づいて、前記複数の第４の障害情報を優先付けして出力する、
   処理を実行させる請求項１記載の制御プログラム。
3. 前記コンピュータに更に、
   前記第１のアプリケーションの障害の分析結果を示す障害対応情報を取得し、前記障害対応情報が示す障害原因に前記第２の処理ノードの障害が含まれる場合、関連ありを示す前記教師ラベルを生成し、前記障害対応情報が示す障害原因に前記第２の処理ノードの障害が含まれない場合、関連なしを示す前記教師ラベルを生成する、
   処理を実行させる請求項１記載の制御プログラム。
4. 前記第１の評価値は、前記第１の処理ノードの階層と前記第２の処理ノードの階層との間の距離を示し、前記第２の評価値は、前記複数のアプリケーションの間の通信関係を示すメッシュグラフにおける前記第１のアプリケーションと前記第２のアプリケーションとの間の距離を示し、前記第３の評価値は、前記第１のエラーメッセージに含まれる単語と前記第２のエラーメッセージに含まれる単語の間の類似度を示す、
   請求項１記載の制御プログラム。
5. 前記特徴情報は更に、前記第１のアプリケーションの障害の発生時刻と前記第２の処理ノードの障害の発生時刻との間の時刻差を示す第４の評価値を更に含む、
   請求項１記載の制御プログラム。
6. 前記複数の処理ノードは、２以上の物理マシンと、それぞれ前記２以上の物理マシンの何れかの上に配置される２以上の仮想マシンと、それぞれ前記２以上の仮想マシンの何れかの上に配置される２以上のコンテナとを含み、
   前記第１の処理ノードは、前記２以上のコンテナの何れか１つであり、前記第２の処理ノードは、前記２以上の物理マシンおよび前記２以上の仮想マシンの何れか１つである、
   請求項１記載の制御プログラム。
7. コンピュータが、
   それぞれが割り当てられたリソースを用いてアプリケーションを実行可能な処理ノードであって、仮想化ソフトウェアを用いて階層的に配置することが可能な複数の処理ノードを含み、複数のアプリケーションそれぞれが前記複数の処理ノードの何れかで実行される情報処理システムについて、第１のアプリケーションの障害を示す第１の障害情報と、第２の処理ノードの障害を示す第２の障害情報と、前記第１の障害情報と前記第２の障害情報との間の関連の有無を示す教師ラベルとを取得し、
   前記第１の障害情報および前記第２の障害情報に基づいて、前記第１のアプリケーションを実行する第１の処理ノードと前記第２の処理ノードとの間の配置の階層関係を示す第１の評価値と、前記第２の処理ノードの上に配置された処理ノードで実行される第２のアプリケーションと前記第１のアプリケーションとの間の依存関係を示す第２の評価値と、前記第１の障害情報に含まれる第１のエラーメッセージと前記第２の障害情報に含まれる第２のエラーメッセージとの間の類似度を示す第３の評価値とを算出し、
   前記第１の評価値、前記第２の評価値および前記第３の評価値を含む特徴情報と前記教師ラベルとを対応付けた訓練データを用いて、２つの障害情報についての特徴情報に対応する入力データから前記２つの障害情報の関連性の有無を推定するモデルを生成する、
   制御方法。
8. それぞれが割り当てられたリソースを用いてアプリケーションを実行可能な処理ノードであって、仮想化ソフトウェアを用いて階層的に配置することが可能な複数の処理ノードを含み、複数のアプリケーションそれぞれが前記複数の処理ノードの何れかで実行される情報処理システムについて、第１のアプリケーションの障害を示す第１の障害情報と、第２の処理ノードの障害を示す第２の障害情報と、前記第１の障害情報と前記第２の障害情報との間の関連の有無を示す教師ラベルとを記憶する記憶部と、
   前記第１の障害情報および前記第２の障害情報に基づいて、前記第１のアプリケーションを実行する第１の処理ノードと前記第２の処理ノードとの間の配置の階層関係を示す第１の評価値と、前記第２の処理ノードの上に配置された処理ノードで実行される第２のアプリケーションと前記第１のアプリケーションとの間の依存関係を示す第２の評価値と、前記第１の障害情報に含まれる第１のエラーメッセージと前記第２の障害情報に含まれる第２のエラーメッセージとの間の類似度を示す第３の評価値とを算出し、前記第１の評価値、前記第２の評価値および前記第３の評価値を含む特徴情報と前記教師ラベルとを対応付けた訓練データを用いて、２つの障害情報についての特徴情報に対応する入力データから前記２つの障害情報の関連性の有無を推定するモデルを生成する処理部と、
   を有する制御装置。

Images