JP2016146555A - サービス影響原因推定装置、サービス影響原因推定プログラム、及びサービス影響原因推定方法 - Google Patents

Abstract

【課題】ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできるようにする。【解決手段】モデル生成部６１は、記憶部５０を参照して、各フローについてデータが流れる物理設備及びソフトウェアのＩＤと当該データが流れる順番を特定するモデルであるフローモデルを生成する。処理部６０及び設定情報管理部７０は、フローモデル同士を比較して当該比較結果から通信ネットワーク上でのサービス影響の原因となる物理設備又はソフトウェアを推定する。【選択図】図３

Description

本発明は、サービス影響原因推定装置、サービス影響原因推定プログラム、及びサービス影響原因推定方法に関する。

通信ネットワークを介してサービスを提供するのに際して、通信ネットワーク中の故障又は品質劣化が発生している箇所を推定する技術が知られている。

特許文献１には、ユーザからの通信ネットワーク上でのトラブル発生の申告を契機に、利用端末と情報ソース（サーバに相当）の間に配置される複数のサービス構成要素（物理的な設備）からなる設備モデルを生成し、全サービス構成要素が正常な場合の通信シーケンスと、サービス構成要素それぞれが故障した場合の通信シーケンスとを生成し、これらの通信シーケンスと故障申告時における観測情報とを比較することで、故障したサービス構成要素を推定する技術について開示されている（詳細は「第１の比較例」として後述）。

また、通信ネットワーク上の装置間のパケットをキャプチャし、キャプチャしたパケットを解析することで、ユーザの体感品質に影響を与える種々の特性値（リオーダ幅、トラヒック流量、ＲＴＴ（Round-Trip Time）、パケットロス、ジッタ、セッション確立率、ウィンドウサイズ、サーバの応答時間）を算出し、その算出した値に基づいて当該特性値の正常性の判定を行い、前記装置間の通信品質劣化の原因箇所を推定する技術も知られている（詳細は「第２の比較例」として後述）。

さらに、非特許文献１には、仮想化された通信ネットワーク機能の選択的利用を可能とする柔軟な経路制御技術であるＳＦＣ（Service Function Chaining）技術を用いて、各フローに対し試験パケットを送信し、当該試験パケットが通過した転送機能部（物理／仮想ルータ又は物理／仮想スイッチに相当）及びアプリケーションのＩＤを、試験パケットが備えるリストにそれぞれ格納し、そのＩＤが格納されたリストと事前に設定した情報とを比較することで故障箇所を推定する技術について開示されている（詳細は「第３の比較例」として後述）。

特開平１０−２００５２７号公報

Y. Jiang他、"Fault Management in Service Function Chaining"、[online]、２０１４年１０月２７日、The Internet Engineering Task Force、[平成２７年１月２７日検索]、インターネット<URL：https://datatracker.ietf.org/doc/draft-jxc-sfc-fm/?include_text=1>

しかしながら、前記第１〜第３の比較例の技術では、仮想化設備やアプリケーションソフトといったソフトウェアに故障や劣化が生じていても異常を検出できないこと（特許文献１）、ＩＤを付与できない設備に対しては故障診断ができないこと（非特許文献１）、作業が煩雑になること、装置規模が大規模になること、サービス品質の劣化が生じている場合に原因箇所の推定をすることができないこと等の不具合点が存在する。
そこで、本発明は、ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできるサービス影響原因推定装置、サービス影響原因推定プログラム、及びサービス影響原因推定方法を提供することを目的とする。

本発明は、通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアのうち少なくとも１つ以上を用いて構成されるフローについて、当該フローを識別するフローＩＤと、前記物理設備を識別する物理設備ＩＤ、前記物理設備であるサーバを識別するサーバＩＤ、及び当該各サーバで用いられる前記ソフトウェアを識別するソフトウェアＩＤとを関連付けて記憶する記憶部と、前記記憶部を参照して、前記各フローについてデータが流れる前記物理設備及びソフトウェアの前記ＩＤと当該データが流れる順番を特定するモデルであるフローモデルを生成するモデル生成部と、前記フローモデル同士を比較して当該比較結果から前記通信ネットワーク上でのサービス影響の原因となる前記物理設備又は前記ソフトウェアを推定する推定部と、を備えたことを特徴とするサービス影響原因推定装置である。
本発明によれば、ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできる。

この場合に、前記推定部は、前記ソフトウェアＩＤを格納できるリストを生成するリスト生成部と、前記リストを備えた試験パケットを生成する試験パケット生成部と、前記試験パケットを前記フローごとに所定時間内に所定数送信するパケット送信部と、前記試験パケットが通過した前記ソフトウェアのＩＤを前記リストに格納した当該試験パケットのリプライパケットを受信するパケット受信部と、前記受信したリプライパケットを格納するリプライ格納部と、を備えたことを特徴としてもよい。
本発明によれば、試験パケットを送信してリプライパケットを受け取るだけなので、ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできる。

この場合に、前記リプライ格納部に格納されている前記リプライパケットの受信についての計測結果に基づいて前記各フローを正常グループと異常グループとに分類するグループ構成部を備えたことを特徴としてもよい。
本発明によれば、正常なフローと異常なフローとに分類することができる。

この場合に、前記グループ構成部は、前記計測結果としてのレスポンスタイム及び前記計測結果としてのリプライのカウント数がそれぞれ各所定値の範囲内にあり、かつ、前記記憶部から取得したソフトウェアＩＤと前記リプライパケットのリストに格納されたソフトウェアＩＤとを比較し、全てのソフトウェアＩＤが一致した前記フローを正常グループに分類し、それ以外の前記フローを異常グループに分類することを特徴としてもよい。
本発明によれば、レスポンスタイム、リプライのカウント数により簡易に正常なフローと異常なフローとに分類することができる。

この場合に、前記グループ構成部は、前記異常グループについて、前記レスポンスタイムの実測値及び前記カウント数がそれぞれ各所定値の範囲内にあるとき、又は、記憶部から取得したソフトウェアＩＤと前記リプライパケットのリストに格納されたソフトウェアＩＤとを比較し、少なくとも1つ以上のソフトウェアＩＤが一致しない前記フローを故障グループに分類し、それ以外の前記フローを性能劣化グループに分類することを特徴としてもよい。
本発明によれば、異常のあるフローを故障ありのものと劣化ありのものに分類できる。

この場合に、前記グループ構成部で前記レスポンスタイムに用いる前記所定値は、所定時間内に所定の値だけ送信された前記試験パケットに対する前記レスポンスタイムについて平均値をとる又は統計的手法を用いることで求めるものであり、前記カウント数に用いる前記所定値は、所定時間内に所定の値だけ送信された前記試験パケットに対する前記カウント数の平均値をとる又は統計的手法を用いることで求めるものであることを特徴としてもよい。
本発明によれば、レスポンスタイム、リプライのカウント数に用いる所定値を適切に決定することができる。

前記の場合に、前記推定部は、前記性能劣化グループ内又は前記故障グループ内で前記各フローのフローモデル同士を比較し、共通する前記物理設備又は前記ソフトウェアを抽出し、当該抽出した物理設備又はソフトウェアを前記サービス影響の原因として推定する第１の原因特定部と、前記性能劣化グループ又は前記故障グループと、前記正常グループとの間で前記各フローのフローモデル同士を比較して、共通する前記物理設備又は前記ソフトウェアは前記サービス影響の原因の候補から除外し、残った前記物理設備又は前記ソフトウェアを抽出して、当該抽出した前記物理設備又は前記ソフトウェアを前記サービス影響の原因として推定する第２の原因特定部と、を備えたこと特徴としてもよい。
本発明によれば、適切な手段によりサービス影響の原因の推定を行うことができる。

この場合に、前記推定部は、前記故障又は性能劣化グループに割り振られたフローの数が、同じグループについての所定の閾値以上の場合は前記第１の原因特定部を用い、前記所定の閾値未満の場合は前記第１の原因特定部を用いた後、前記第２の原因特定部を用いて前記サービス影響の原因の推定を行うことを特徴としてもよい。
本発明によれば、第１の原因特定部又は第２の原因特定部を的確に選択することができる。

前記の場合に、前記推定部は、前記性能劣化グループ内又は前記故障グループ内で前記各フローのフローモデル同士を比較し、共通する前記物理設備又は前記ソフトウェアの数をそれぞれカウントし、その後、当該比較をした前記性能劣化グループ又は前記故障グループと前記正常グループとの間で前記各フローのフローモデル同士を比較し、共通する前記物理設備又は前記ソフトウェアについては前記カウントの数を０とし、最終的に前記カウントの数が最大である前記物理設備又は前記ソフトウェアを抽出し、当該抽出した前記物理設備又は前記ソフトウェアを前記サービス影響の原因であるものとして推定すること特徴としてもよい。
本発明によれば、サービス影響の原因であるものの推定を的確に行うことができる。

この場合に、前記記憶部は、前記物理設備ＩＤ及び前記ソフトウェアＩＤとして、当該ＩＤが示す物理設備又はソフトウェアと、当該物理設備又はソフトウェアと親子関係又は接続関係にある他の物理設備、ソフトウェア、又はサーバとの相関関係を示すものであり、前記推定部は、前記サービス影響の原因である前記物理設備又は前記ソフトウェアが複数推定された場合に、当該複数の物理設備又はソフトウェア同士、又は、前回行われた前記推定で推定された前記物理設備又は前記ソフトウェアと今回行われた前記推定で推定された前記物理設備又は前記ソフトウェアとについて前記親子関係又は接続関係がある場合に、今回行われて複数推定された前記物理設備又は前記ソフトウェアの前記カウントの数に優先度をつけること特徴としてもよい。
本発明によれば、親子関係又は接続関係によってカウントの数に優先度をつけることができる。

別の本発明は、通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアのうち少なくとも１つ以上を用いて構成されるフローについて、当該フローを識別するフローＩＤと、前記物理設備を識別する物理設備ＩＤ、前記物理設備であるサーバを識別するサーバＩＤ、及び当該各サーバで用いられる前記ソフトウェアを識別するソフトウェアＩＤとを関連付けて記憶する記憶部を参照して、前記各フローについてデータが流れる前記物理設備及びソフトウェアの前記ＩＤと当該データが流れる順番を特定するモデルであるフローモデルを生成するモデル生成処理と、前記フローモデル同士を比較して当該比較結果から前記通信ネットワーク上でのサービス影響の原因となる前記物理設備又は前記ソフトウェアを推定する推定処理と、をコンピュータに実行させることを特徴とするコンピュータに読み取り可能なサービス影響原因推定プログラムである。
本発明によれば、ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできる。

別の本発明は、通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアのうち少なくとも１つ以上を用いて構成されるフローについて、当該フローを識別するフローＩＤと、前記物理設備を識別する物理設備ＩＤ、前記物理設備であるサーバを識別するサーバＩＤ、及び当該各サーバで用いられる前記ソフトウェアを識別するソフトウェアＩＤとを関連付けて記憶する記憶部を参照して、前記各フローについてデータが流れる前記物理設備及びソフトウェアの前記ＩＤと当該データが流れる順番を特定するモデルであるフローモデルを生成するモデル生成工程と、前記フローモデル同士を比較して当該比較結果から前記通信ネットワーク上でのサービス影響の原因となる前記物理設備又は前記ソフトウェアを推定する推定工程と、を備えたことを特徴とするサービス影響原因推定方法である。
本発明によれば、ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできる。

本発明によれば、ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできる。

本発明の一実施形態にかかるシステムの全体の構成図である。 本発明の一実施形態にかかるサービス影響原因推定装置のハードウェア構成の概要を示すブロック図である。 本発明の一実施形態にかかるサービス影響原因推定プログラムに基づいて中央処理装置が実行する機能を説明する機能ブロック図である。 本発明の一実施形態にかかるサービス影響原因推定装置の設備情報ＤＢに登録されているデータ構成の説明図である。 本発明の一実施形態にかかるサービス影響原因推定装置のソフトウェア情報ＤＢに登録されているデータ構成の説明図である。 本発明の一実施形態にかかるフローモデルの一例を示す説明図である。 本発明の一実施形態にかかる試験パケットの例を説明する。 本発明の一実施形態にかかる各フローをグループ分けする処理のフローチャートである。 図８のグループ分けにおける判断を示す状態遷移図である。 本発明の一実施形態におけるサービス影響の原因推定処理を説明する説明図である。 本発明の一実施形態において第１原因特定部を用いるか、第２原因特定部を用いるかを選択するためのフローチャートである。 本発明の一実施形態におけるサービス影響の原因推定処理の変形例を説明する説明図である。 本発明の一実施形態におけるサービス影響の原因推定処理の変形例を説明する説明図である。 本発明の一実施形態におけるサービス影響の原因推定処理の変形例を説明する説明図である。 第１の比較例の技術内容を説明する説明図である。 第２の比較例の技術内容を説明する説明図である。 第３の比較例の技術内容を説明する説明図である。

まず、本実施形態を説明する前に本実施形態に対する比較例を複数例説明する。
［比較例］
（第１の比較例）
本明細書において、サービス品質に「劣化」が生じているとは、ネットワーク管理者側で異常の発生を示すアラームを確認できないような異常が発生している場合であり、サービス品質に「故障」が生じているとは、ネットワーク管理者側で当該アラームを確認できる異常が発生している場合である。

図１５は、第１の比較例（特許文献１）の技術内容を説明する説明図である。このネットワークサービス故障診断方法及び装置では、ユーザがサービスを利用する際にその端末と情報ソースとの間に配置される複数のサービス構成要素のそれぞれに関する役割を記述している設備情報データベース（ＤＢ）２０１と、各サービス構成要素に関する正常時及び故障時の動作を記述している設計情報データベース（ＤＢ）２０２とを備えている。設備情報ＤＢ２０１の登録情報の例は符号２０３で示している。

まず、通信ネットワークのユーザ（ユーザＡ）の申告により、そのユーザＩＤと利用サービス名で検索を要求すると（Ｓ２１１）、設備情報ＤＢ２０１に基づいて、当該ユーザＡのEnd-to-Endの設備モデルを、サービス構成要素（物理的装置）を単位として出力する（Ｓ２１２）。そして、設計情報ＤＢ２０２を参照して、当該設備モデルに基づいて、全サービスの構成要素が正常なときの通信シーケンスを生成する（Ｓ２１３）。また、各サービスの構成要素が故障した際の通信シーケンスを、設計情報ＤＢ２０２を参照して生成する（Ｓ２１４）。

次に、正常時の通信シーケンス（Ｓ２１３）、異常時の通信シーケンス（Ｓ２１４）と、観測情報（通信システムの保守者の入力した情報）とを比較して、両者に共通の情報が含まれる通信シーケンスを抽出する。そして、各サービス構成要素のうち、本来の役割を果たさなかったサービス構成要素を抽出する（Ｓ２１５，Ｓ２１６）。この例では、Ｓ２１５で、Ｎｏ．４８のＮＩＣ（Network Interface Controller）の故障時の通信シーケンスが通信シーケンス番号１〜４として示されている。これらは、様々な故障パターンの通信シーケンス例である。また、Ｓ２１６で保守者の入力した情報は、「アラームＡ」という警告が表示されたこと、「メッセージＢ」というメッセージ（Ｓ２１４における「ホストからの応答がありません」というメッセージ）が表示されたこと、及び「○○が動かない」とのユーザＡからの申告である。
この例では、正常／異常時の通信シーケンスと観測情報との比較により、シーケンス番号１，３で一致し、これを抽出する。そして、シーケンス番号１，３の通信シーケンスにおいて、どのサービス構成要素が本来の役割を果たさないのかを判断して、異常個所の推定を行う。

しかしながら、このような第１の比較例は、予め故障時の通信シーケンスを網羅的に用意する必要があるため、作業が煩雑である。また、第１の比較例は、仮想化設備やアプリケーションソフトといったソフトウェアがサービス構成要素の対象外とされている（対象とされているのは物理的装置だけ）ため、例えば、同一サーバ内に複数の仮想化設備やアプリケーションソフトが設定されている場合、これを設備モデルに変換する際に、ある物理的装置に同居して存在する仮想化設備又はアプリケーションソフトなのか、ある物理的装置に単一で存在する仮想化設備又はアプリケーションソフトなのかを区別できないため、人手による1つ1つの確認作業が必要となってしまい、作業が煩雑である。さらに、第１の比較例は、通信シーケンスの異常を判断するものであるため、通信シーケンスは正常だがサービス品質に劣化が生じている場合に、原因となるサービス構成要素を推定できないという不具合もある。

（第２の比較例）
図１６は、第２の比較例の技術内容を説明する説明図である。この品質劣化原因推定方法は、図１６（ａ）に示すように、ユーザ端末３０１とサーバ３０２がネットワーク３０３を介して接続されている。そして、ネットワーク３０３に設けられた品質劣化原因推定装置３０４がユーザ端末３０１、サーバ３０２間のパケットＰ３１１をキャプチャし、キャプチャしたパケットＰ３１１を解析することで、ユーザの体感品質に影響を与える種々の特性値（リオーダ幅、トラヒック流量、ＲＴＴ（Round-Trip Time）、パケットロス、ジッタ、セッション確立率、ウィンドウサイズ、サーバの応答時間）を算出し、その算出した値に基づいて特性値の正常性判定を行い、ユーザ端末３０１、サーバ３０２間の通信品質劣化の原因箇所を推定するものである。

図１６（ｂ）は、特性値がセッション確立率の例である場合の判定処理のフローチャートである。特性値がセッション確立率であるときは、まず、品質劣化原因推定装置３０４は、セッション確立失敗率が所定の閾値より大きいか否か判断する（Ｓ３２１）。大きくないときは（Ｓ３２１のＮ）、品質劣化原因推定装置３０４は、ネットワーク３０３は正常であると判断する（Ｓ３２２）。大きいときは（Ｓ３２１のＹ）、品質劣化原因推定装置３０４は、セッション終端装置があるか否か判断する（Ｓ３２３）。セッション終端装置がある場合は（Ｓ３２３のＹ）、セッション終端装置に異常の原因がある可能性があるので、品質劣化原因推定装置３０４は、セッション終端装置のログを確認する必要があると判断する（Ｓ３２４）。セッション終端装置がない場合は（Ｓ３２３のＮ）、品質劣化原因推定装置３０４は、サーバ３０２に原因があると判断する（Ｓ３２５）。

図１６（ｃ）は、特性値がウィンドウサイズの例である場合の判定処理のフローチャートである。特性値がウィンドウサイズであるときは、まず、品質劣化原因推定装置３０４は、ウィンドウサイズが所定の閾値より小さいか否か判断する（Ｓ３３１）。閾値以上であるときは（Ｓ３３１のＮ）、品質劣化原因推定装置３０４は、ネットワーク３０３は正常であると判断する（Ｓ３３２）。閾値より小さいときは（Ｓ３３１のＹ）、品質劣化原因推定装置３０４は、帯域制御装置があるか否か判断する（Ｓ３３３）。帯域制御装置がある場合は（Ｓ３３３のＹ）、帯域制御装置に異常の原因がある可能性があるので、品質劣化原因推定装置３０４は、帯域制御装置のログを確認する必要があると判断する（Ｓ３３４）。帯域制御装置がない場合は（Ｓ３３３のＮ）、品質劣化原因推定装置３０４は、サーバ３０２に原因があると判断する（Ｓ３３５）。

しかしながら、このような第２の比較例は、フローごとに、End-to-Endで、ネットワーク３０３内の個々の装置も含めた原因箇所推定を行う場合に、ネットワーク３０３内の装置に設けるキャプチャポイントが多くなってしまい、キャプチャしたパケットＰ３１１のデータの保存量及び判定処理にかかる負荷が増大してしまうので、作業が煩雑となり、装置規模が大規模になってしまう。このため、通信キャリアといった大規模なネットワークにおいては適用が困難である。

（第３の比較例）
図１７は、第３の比較例の技術内容を説明する説明図である。この仮想化機構を含む故障診断方法は、図１７（ａ）に示すように、ネットワーク４０１中に、複数台のサーバ４０２、複数台のスイッチ（ネットワークスイッチ）４０３が配置されている。検出ノード４０４は、ネットワーク４０１中のノードのひとつである。サーバ４０２は、データ転送を行う転送機能部（仮想スイッチに相当）４１１と、アプリケーションソフト４１２とを備えている。ＳＦＦ１〜ＳＦＦ３は、各転送機能部４１１のＩＤであり、ＳＦ１〜ＳＦ５は、各アプリケーションソフト４１２のＩＤである。

本技術は、仮想化されたネットワーク機能の選択的利用を可能とする柔軟な経路制御技術であるＳＦＣ（Service Function Chaining）を用いている。検出ノード４０４は、各フローに対して試験パケットを１つ送信する。この試験パケットは、転送機能部４１１とアプリケーションソフト４１２のＩＤを格納するリストを備えている。試験パケットを受信したサーバ４０２では、当該試験パケットのリストに自身の転送機能部４１１のＩＤを格納し、当該格納後のリストをコピーし、コピーしたリストを送信元の検出ノード４０４にリプライする。その後、当該コピー元のリストを備えた試験パケットを同一サーバ４０２のアプリケーションソフト４１２に転送し、ここでも転送機能部４１１と同様にリストのコピー、コピーしたリストの送信元の検出ノード４０４へのリプライが行われる。さらに別のサーバ４０２に試験パケットが転送される場合も同様である。

図１７（ｂ）には、検出ノード４０４に予め格納されている設定情報４２１の例を示している。この設定情報４２１は、あるフローを転送される試験パケットの通過経路の各部のＩＤを通過する順に上から並べて示している。この例では、ＩＤがＳＦＦ１の転送機能部４１１を備えたサーバ４０２に試験パケットが転送され、その転送機能部４１１、アプリケーションソフト４１２を試験パケットが順次通過した後、ＩＤがＳＦＦ２の転送機能部４１１を備えたサーバ４０２に試験パケットが転送され、その転送機能部４１１、アプリケーションソフト４１２を試験パケットが順次通過する例である。そのため、当該試験パケットが通過する予定の各部のＩＤを順に示すと、“ＳＦＦ１→ＳＦ１→ＳＦＦ１→ＳＦＦ２→ＳＦ２→ＳＦＦ２→ＳＦ３→ＳＦＦ２”となる。

図１７（ｃ）は、試験パケットに基づいて、検出ノード４０４にリプライされたリストの例である。リスト１はＩＤがＳＦＦ１の転送機能部４１１からリプライされ、リスト２はＩＤがＳＦ１のアプリケーションソフト４１２からリプライされ、リスト３はＩＤがＳＦＦ１の転送機能部４１１からリプライされ、リスト４はＩＤがＳＦＦ２の転送機能部４１１からリプライされたものである。

これらのリストと設定情報４２１とを比較することにより、各転送機能部４１１、アプリケーションソフト４１２のうち、異常が存在する部位はどれであるかを判定することができる。リスト１〜リスト４は、設定情報４２１と比較すれば、いずれも検出ノード４０４に正しくリプライされたものであることがわかる。すなわち、リスト１〜リスト４の各最下段のＩＤは設定情報４２１中に存在し、当該ＩＤが当該リストのリプライ元であるから、そのリプライ元の転送機能部４１１又はアプリケーションソフト４１２は正常に動作していると判定できる。
ここで、仮に、ＩＤがＳＦＦ２である転送機能部４１１に異常が存在していると、最下段にＩＤのＳＦＦ２が記録されたリスト４はリプライされないので、リスト４のリプライの不存在をもって、ＩＤがＳＦＦ２である転送機能部４１１に異常があると判定することになる。

しかしながら、このような第３の比較例は、ＩＤを付与可能な転送機能部４１１及びアプリケーションソフト４１２のみを異常診断の対象としているため，それ以外のＩＤを付与できない物理的な装置やソフト的な設備に対しては異常診断ができないという不具合がある。また、転送機能部４１１及びアプリケーションソフト４１２のＩＤが格納されたリストと設定情報４２１との比較だけでは、サービス品質の劣化が生じている場合に原因箇所の推定をすることができないという不具合もある。

［実施形態］
次に、第１〜第３の比較例における不具合を解消した本実施形態の技術内容について説明する。
（システム構成の概要）
図１は、本実施形態の全体のシステム構成図である。インターネットなどの通信ネットワーク１０上には複数のサーバ１１が設置され、これらのサーバ１１は、スイッチ（ネットワークスイッチ）１２、リンク１３を介して接続されている。各サーバ１１には、いずれもソフトウェアである仮想スイッチ（ｖＳＷ）２１、アプリケーションソフト（ＡＰＬ）２２が用意されている。これらの通信ネットワーク１０中の各構成要素には、そのＩＤを、例えば「ＩＤ：ｓｖ０１」のように図示している。

サービス影響原因推定装置１は、この例ではサーバ１１に接続されて設けられている。しかし、本発明はこれに限定されるものではなく、サービス影響原因推定装置１をサーバ１１とは独立させて通信ネットワーク１０中に配置してもよい。

図２は、サービス影響原因推定装置１のハードウェア構成の概要を示すブロック図である。サービス影響原因推定装置１は、各種演算及び制御を行う中央処理装置（ＣＰＵ）３１と、中央処理装置３１の作業領域となる主記憶装置３２と、各種データを記憶する補助記憶装置（ＨＤＤ等）３３と、通信ネットワーク１０と通信を行う通信インターフェイス（Ｉ／Ｆ）３４とを備えている。補助記憶装置３３には、サービス影響原因推定装置１における下記に説明する特徴的な処理を実行するためのプログラムであるサービス影響原因推定プログラム４５が格納されている。

図３は、サービス影響原因推定プログラム４５に基づいて中央処理装置３１が実行する機能を説明する機能ブロック図である。
すなわち、サービス影響原因推定装置１は、記憶部５０と、処理部６０と、管理部７０とを備えている。
記憶部５０には、設備情報データベース（ＤＢ）５１と、ソフトウェア情報データベース（ＤＢ）５２とが設けられている。これら各部の詳細な機能は後述する。
処理部６０は、後述のフローモデルに関する処理を行う。処理部６０には、モデル生成部６１と、構成要素方法決定部６２と、構成要素抽出部６３と、抽出要素格納部６４とが設けられている。構成要素抽出部６３は、第１原因特定部６３１と、第２原因特定部６３２とを備えている。これら各部の詳細な機能は後述する。

管理部７０は、各種データの管理に関する処理を行う。管理部７０には、設定情報管理部７１と、グループ管理部７２と、閾値管理部７３と、試験パケット管理部７４と、記録部７５とが設けられている。グループ管理部７２には、グループ構成部７２１と、グループ格納部７２２とが設けられている。閾値管理部７３は、レスポンスタイム閾値格納部７３１と、リプライカウント数閾値格納部７３２と、故障フロー数閾値格納部７３３と、性能劣化フロー数閾値格納部７３４とが設けられている。試験パケット管理部７４は、試験パケット生成部７４１と、リスト生成部７４２と、パケット送信部７４３と、パケット受信部７４４と、リプライ格納部７４５とが設けられている。記録部７５は、レスポンスタイム格納部７５１と、リプライカウント数格納部７５２と、故障フロー数格納部７５３と、性能劣化フロー数格納部７５４とが設けられている。これら各部の詳細な機能は後述する。

以下では、サービス影響原因推定装置１が実行する処理であるサービス影響原因推定方法について順次説明する。
（サービス影響原因推定方法の概要）
図４は、設備情報ＤＢ５１（図３）に登録されているデータ構成の説明図である。設備情報ＤＢ５１には、フローＩＤと物理設備ＩＤとが関連付けられて登録される。フローＩＤは、通信ネットワーク１０において、転送装置や通信ケーブル等の物理設備と、仮想マシンや仮想スイッチ等の仮想化された設備及びアプリケーションソフト等のソフトウェアとのうち（図１の例では、サーバ１１、スイッチ１２、リンク１３、仮想スイッチ２１、アプリケーションソフト２２）の少なくとも１つ以上を用いて構成されるフローを識別する識別子である。物理設備ＩＤは、通信ネットワーク１０において、前記各フロー中の物理設備（図１の例では、サーバ１１、スイッチ１２、リンク１３）を識別する識別子である。物理設備ＩＤは、データが流れる物理設備のＩＤをデータが流れる順番に左から右に連結して示している。

図５は、ソフトウェア情報ＤＢ５２（図３）に登録されているデータ構成の説明図である。設備情報ＤＢ５１には、前記のフローＩＤと、サーバＩＤと、ソフトウェアＩＤとが関連付けられて登録される。サーバＩＤは、サーバ１１を識別する識別子である。ソフトウェアＩＤは、各サーバＩＤが示すサーバ１１に搭載されている仮想マシンや仮想スイッチ等の仮想化された設備及びアプリケーションソフト等のソフトウェア（図１の例では、仮想スイッチ２１、アプリケーションソフト２２）を識別する識別子である。ソフトウェアＩＤは、データが流れるソフトウェアのＩＤをデータが流れる順番に左から右に連結して示している。ソフトウェアＩＤは、各サーバ１１のサーバＩＤと関連付けられていて、当該サーバＩＤの示すサーバ１１内のソフトウェアのＩＤのみで示されている。

図６は、フローモデルの一例を示す説明図である。フローモデルもフローＩＤが識別子となり、図６においては、フローＩＤごとのフローモデル例を示している。フローモデルは、モデル生成部６１により生成される。すなわち、モデル生成部６１は、あるフローＩＤのフローモデルを作成するに際して、設備情報ＤＢ５１（図４）とソフトウェア情報ＤＢ５２（図５）とを参照して、それぞれ対象となるフローＩＤと関連付けられている、物理設備ＩＤが示す物理設備と、サーバＩＤ及びソフトウェアＩＤが示すソフトウェアとを、データが流れる順番に左から右に連結して示している。すなわち、モデル生成部６１は、各フローについてデータが流れる物理設備及びソフトウェアのＩＤと当該データが流れる順番を特定するモデルである。

本実施形態では、処理部６０及び管理部７０が推定部に相当し、この処理部６０及び管理部７０の実行する処理により、前記のフローモデル同士を比較して当該比較結果から、通信ネットワーク１０上での劣化、故障のようなサービス影響の原因となる物理設備又はソフトウェアを推定するものである。以下では、サービス影響原因推定装置１が実行する詳細な処理、特に、推定部となる処理部６０及び管理部７０が実行する具体的な処理について説明する。

（試験パケット）
通信ネットワーク１０上での劣化、故障のようなサービス影響の原因となる物理設備又はソフトウェアを推定するために用いる試験パケットの例を説明する。
まず、リスト生成部７４２がソフトウェアＩＤを格納できる、図７（ａ）に示すようなリストを生成する。このリストには、対象となるフローモデルのフローＩＤとソフトウェアＩＤとが、試験パケットが当該ソフトウェアを通過した際に記載される。そして、試験パケット生成部７４１が、当該リストを備えた試験パケットを生成する。この試験パケットのヘッダには、該当するフローの設備情報ＤＢ５１及びソフトウェア情報ＤＢ５２を参照して、当該試験パケットが通過する物理設備の物理設備ＩＤ、ソフトウェアのソフトウェアＩＤが格納されている。
パケット送信部７４３は、この生成した試験パケットをフローごとに所定時間内に所定数送信する。具体的には、１フローにつき複数個の同一の試験パケットが送信される。

これにより、各フローにおいて、フローモデルの最後の構成要素がリプライパケットを生成し、送信する。リプライパケットには、対応する試験パケットが通過したソフトウェアのＩＤをそれぞれ格納した、図７（ｂ）に示すようなリストが添付される。リプライパケットはパケット受信部７４４が受信する。そして、リプライ格納部７４５は、当該リプライパケットのリストを格納する。
この試験パケットのレスポンスタイムの実測値はレスポンスタイム格納部７５１に格納され、また、試験パケットのリプライパケットのカウント数はリプライカウント数格納部７５２に格納される。

（グループ分け）
次に、前記試験パケットの送信の結果に基づいて、各フローをグループ分けする。グループ分けは、まず、異常が存在しないフローと判断する「正常グループ」と、異常が存在するフローと判断する「異常グループ」である「性能劣化グループ」及び「故障グループ」とに分類する。グループ構成部７２１は、この正常グループ、異常グループ、性能劣化グループのグループ分けを行う。グループ格納部７２２は、このグループ分けの結果を格納する。また、設定情報管理部７１には、設備情報ＤＢ５１、ソフトウェア情報ＤＢ５２の登録情報を設定情報として取り込む。

図８は各フローをグループ分けする処理のフローチャートである。本処理では、レスポンスタイム格納部７５１に格納されている試験パケットのレスポンスタイムの実測値の閾値としてＮ１，Ｎ２（Ｎ１＜Ｎ２）、リプライカウント数格納部７５２に格納されている試験パケットのリプライパケットのカウント数の閾値としてＣ１，Ｃ２，Ｃ３（Ｃ１＞Ｃ２＞Ｃ３）を用いる。

ここで、レスポンスタイム閾値格納部７３１に格納されるレスポンスタイムに用いる所定値である閾値Ｎ１，Ｎ２は、所定時間内に前記のとおり所定の値だけ送信された試験パケットに対するレスポンスタイムについて平均値をとる又は所定の統計的手法を用いることで求めるものである。同様に、リプライカウント数閾値格納部７３２に格納されるリプライパケットのカウント数に用いる所定値である閾値Ｃ１，Ｃ２，Ｃ３は、所定時間内に前記所定の値だけ送信された試験パケットに対するカウント数の平均値をとる又は所定の統計的手法を用いることで求めるものである。

まず、フローごとに図８に示す処理を行う。すなわち、グループ構成部７２１は、レスポンスタイム格納部７５１に格納されているレスポンスタイムの実測値が閾値Ｎ１より小さいか否かを判断する（Ｓ１）。レスポンスタイムの実測値が閾値Ｎ１より小さいときは（Ｓ１のＹｅｓ）、グループ構成部７２１は、リプライカウント数格納部７５２に格納されているリプライパケットのカウント数が閾値Ｃ１以上か否かを判断する（Ｓ２）。リプライパケットのカウント数が閾値Ｃ１以上であるときは（Ｓ２のＹｅｓ）、グループ構成部７２１は、リプライ格納部７４５に格納されているリプライパケットのリストが設定情報管理部７１に格納されている設定情報と完全に一致するか否かを判断する（Ｓ３）。リプライパケットのリストと設定情報とが完全に一致するときは（Ｓ３のＹｅｓ）、レスポンスが良く、リプライパケットは十分な数が返ってきて、試験パケットは該当するフロー中の物理設備、ソフトウェアを全て正常に経由しているので、グループ構成部７２１は、そのフローを正常グループに分類する（Ｓ４）。

一方、リプライパケットのカウント数が閾値Ｃ１を下回ったときは（Ｓ２のＮｏ）、グループ構成部７２１は、Ｓ３と同様にリプライ格納部７４５に格納されているリプライパケットのリストが設定情報管理部７１に格納されている設定情報と完全に一致するか否かを判断する（Ｓ５）。リプライパケットのリストと設定情報とが完全に一致するときは（Ｓ５のＹｅｓ）、リプライパケットは十分な数が返ってきていないが、試験パケットは該当するフロー中の物理設備、ソフトウェアを全て正常に経由しているので、グループ構成部７２１は、そのフローを性能劣化グループに分類する（Ｓ６）。リプライパケットのリストと設定情報とで一致しないものがあるときは（Ｓ５のＹｅｓ）、リプライパケットは十分な数が返ってきておらず、試験パケットは該当するフロー中の物理設備、ソフトウェアで正常に経由していないものであるので、グループ構成部７２１は、そのフローを故障グループに分類する（Ｓ７）。Ｓ３で、リプライパケットのリストと設定情報とで一致しないものがあるときも（Ｓ３のＮｏ）、リプライパケットは十分な数が返ってきてはいるが、試験パケットは該当するフロー中の物理設備、ソフトウェアで正常に経由していないものであるので、グループ構成部７２１は、そのフローを故障グループに分類する（Ｓ７）。

レスポンスタイムの実測値が閾値Ｎ１以上であるときは（Ｓ１のＮｏ）、グループ構成部７２１は、レスポンスタイムの実測値が閾値Ｎ１以上で、かつ、閾値Ｎ２未満であるか否かを判断する（Ｓ８）。レスポンスタイムの実測値が閾値Ｎ１以上で、かつ、閾値Ｎ２未満であるときは（Ｓ８のＹｅｓ）、グループ構成部７２１は、リプライカウント数格納部７５２に格納されているリプライパケットのカウント数が閾値Ｃ２以上か否かを判断する（Ｓ９）。リプライパケットのカウント数が閾値Ｃ２以上であるときは（Ｓ９のＹｅｓ）、グループ構成部７２１は、リプライ格納部７４５に格納されているリプライパケットのリストが設定情報管理部７１に格納されている設定情報（記憶部５０の情報）と完全に一致するか否かを判断する（Ｓ１０）。リプライパケットのリストと設定情報とが完全に一致するときは（Ｓ１０のＹｅｓ）、レスポンスがそれほど良くはないリプライパケットが複数返ってきており、かつ、試験パケットは該当するフロー中の物理設備、ソフトウェアを全て正常に経由しているので、グループ構成部７２１は、そのフローを性能劣化グループに分類する（Ｓ６）。リプライパケットのリストと設定情報とで一致しないものがあるときは（Ｓ１０のＮｏ）、レスポンスがそれほど良くはないリプライパケットが複数返ってきており、かつ、試験パケットは該当するフロー中の物理設備、ソフトウェアで正常に経由していないものがあるので、グループ構成部７２１は、そのフローを故障グループに分類する（Ｓ７）。リプライパケットのカウント数が閾値Ｃ２未満であるときは（Ｓ９のＮｏ）、グループ構成部７２１は、前記のＳ３の判断により、正常グループと性能劣化グループとにグループ分けする。

レスポンスタイムの実測値が閾値Ｎ１以上で、かつ、閾値Ｎ２未満ではないときは（Ｓ８のＮｏ）、グループ構成部７２１は、レスポンスタイムの実測値が閾値Ｎ２以上であるか否かを判断する（Ｓ１１）。レスポンスタイムの実測値が閾値Ｎ２以上であるときは（Ｓ１１のＹｅｓ）、リプライパケットのカウント数が閾値Ｃ３以上か否かを判断する（Ｓ１２）。リプライパケットのカウント数が閾値Ｃ３以上のときは（Ｓ１２のＹｅｓ）、レスポンスが悪いリプライパケットが所定数以上返ってきているので、グループ構成部７２１は、当該フローを故障グループに分類する（Ｓ７）。リプライパケットのカウント数が閾値Ｃ３未満のときは（Ｓ１２のＹｅｓ）、グループ構成部７２１は、前記のＳ１０の判断により、性能劣化グループと故障グループとに分類する。
以上のグループ分けの結果は、グループ格納部７２２に格納される。

図９は、図８のグループ分けにおける判断を示す状態遷移図である。正常グループ、性能劣化グループ、故障グループにグループ分けする各判断の項目８１〜８９において、（１）は前記のレスポンスタイムの判断、（２）は前記のリプライパケットのカウント数の判断、（３）は前記した設定情報とリストの一致性をそれぞれ示している。

（サービス影響の原因推定）
構成要素抽出部６３は、第１原因特定部６３１と、第２原因特定部６３２とを備えている。構成要素抽出部６３は、フローモデル同士を比較して当該比較結果から通信ネットワーク１０上でのサービス影響の原因となる物理設備又は前記ソフトウェアを推定する。構成要素抽出部６３の第１原因特定部６３１と、第２原因特定部６３２とは、それぞれ異なる手法で当該推定を行う。
まず、第１原因特定部６３１は、前記のように分類された性能劣化グループ内又は故障グループ内で各フローについて、フローモデル同士を比較し、共通する要素となる物理設備又はソフトウェアを抽出し、当該抽出した物理設備又はソフトウェアをサービス影響の原因として推定する。
図１０（ａ）の例では、性能劣化グループ内又は故障グループ内で、フローＩＤがＰ１１とＰ１２のフローモデル同士を比較し、共通する要素となる物理設備ＩＤがｐｓ９５のスイッチ１２を抽出している。

第２原因特定部６３２は、前記のように分類された性能劣化グループ又は故障グループと、正常グループとの間で各フローのフローモデル同士を比較して、共通する物理設備又はソフトウェアはサービス影響の原因の候補から除外し、残った物理設備又はソフトウェアを抽出して、当該抽出した物理設備又はソフトウェアをサービス影響の原因として推定する。

図１０（ｂ）の例では、性能劣化グループ又は故障グループのフローＩＤがＰ２１のフローモデルと、正常グループのフローＩＤがＰ２２のフローモデルとを比較し、共通の要素である、ソフトウェアＩＤが“ｂｋ２”のアプリケーションソフト２２、物理設備ＩＤが“ｐｓ９５”のスイッチ１２を共通するものとして除外し、残った要素である物理設備又はソフトウェアを抽出している。
このようにして、第１原因特定部６３１又は第２原因特定部６３２により抽出された構成要素は抽出要素格納部６４に格納される。

図１１は、構成要素抽出部６３の第１原因特定部６３１を用いるか、第２原因特定部６３２を用いるかを選択するためのフローチャートである。
すなわち、構成要素抽出方法決定部６２が図１１の処理により、第１原因特定部６３１を用いるか、第１原因特定部６３１及び第２原因特定部６３２の両方を用いるかを選択する。この場合に後述の故障フロー数に関する閾値Ｄ１が故障フロー数閾値格納部７３３に格納されていて、同様に後述の性能劣化フロー数に関する閾値Ｄ２が性能劣化フロー数閾値格納部７３４に格納されていて、本処理では当該各閾値を用いる。

構成要素抽出方法決定部６２は、各フローについて図１１の処理を実行する。まず、当該フローが性能劣化グループに分類されているときは（Ｓ２１のＹｅｓ）、構成要素抽出方法決定部６２は、性能劣化グループに分類されたフローの数である性能劣化フロー数を、その閾値である閾値Ｄ１以上であるか否か判断する（Ｓ２２）。性能劣化フロー数が閾値Ｄ１以上であるときは（Ｓ２２のＹｅｓ）、構成要素抽出方法決定部６２は、第１原因特定部６３１を使用する（Ｓ２３）。性能劣化フロー数が閾値Ｄ１未満であるときは（Ｓ２２のＮｏ）、構成要素抽出方法決定部６２は、第１原因特定部６３１を使用した後（Ｓ２４）、第２原因特定部６３２を使用する（Ｓ２５）。

一方、該当するフローが故障グループに分類されているときは（Ｓ２６のＹｅｓ）、構成要素抽出方法決定部６２は、故障グループに分類されたフローの数である故障フロー数を、その閾値である閾値Ｄ２以上であるか否か判断する（Ｓ２７）。故障フロー数が閾値Ｄ２以上であるときは（Ｓ２７のＹｅｓ）、構成要素抽出方法決定部６２は、第１原因特定部６３１を使用する（Ｓ２３）。故障フロー数が閾値Ｄ２未満であるときは（Ｓ２７のＮｏ）、構成要素抽出方法決定部６２は、第１原因特定部６３１を使用した後（Ｓ２４）、第２原因特定部６３２を使用する（Ｓ２５）。
以上のように、第１原因特定部６３１又は第２原因特定部６３２が使用されて、前記のとおり構成要素となる物理設備又はソフトウェアが抽出されると、その抽出した構成要素をサービス影響の原因の特定個所と推定する（Ｓ２８）。

（サービス影響の原因推定の変形例）
図１２〜図１４を参照して前記したサービス影響の原因推定の処理の変形例について説明する。

図１２は、当該変形例を説明する説明図である。図１２（ａ）には、正常グループと故障グループ（性能劣化グループ）のフローモデルの例を示している。本例では、まず、構成要素抽出部６３が、前記の性能劣化グループ内又は前記の故障グループ内で、各フローのフローモデル同士を比較し、共通する物理設備又はソフトウェアの数をそれぞれカウントする。図１２（ｂ）には、そのカウント結果の例を示している。例えば、ソフトウェアＩＤが“ａ１”のアプリケーションソフト２２についてはカウント数が“２１”、物理設備ＩＤが“ｖｓ３”のスイッチ１２についてはカウント数が“１７”であるという例を示している。

その後、構成要素抽出部６３は、このような比較をした性能劣化グループ又は故障グループと、正常グループとの間で各フローのフローモデル同士を比較し、共通する物理設備又はソフトウェアについては、図１２（ｃ）に例示するようにカウントの数を０とする。図１２（ｃ）の例では、ソフトウェアＩＤが“ａ１”のアプリケーションソフト２２については、性能劣化グループ又は故障グループと、正常グループとの間で共通していたのでカウント数が“２１”から“０”に変更され、物理設備ＩＤが“ｖｓ３”のスイッチ１２については、性能劣化グループ又は故障グループと、正常グループとの間で共通していなかったので、カウント数が“１７”のままであるという例を示している（いずれも「合計」）。

そして、構成要素抽出部６３は、最終的に前記のカウントの数が最大である物理設備又はソフトウェアを抽出し、当該抽出した物理設備又はソフトウェアをサービス影響の原因であるものとして推定する。図１２（ｃ）の例では、カウントの数が最大である物理設備又はソフトウェアは、物理設備ＩＤが“ｓ３”のスイッチ１２のカウント数“４５”であり、これが「最終結果」となる。そのため、構成要素抽出部６３は、物理設備ＩＤが“ｓ３”のスイッチ１２が、サービス影響の原因であるものとして推定する。
このような処理において、最終的に前記のカウントの数が最大である物理設備又はソフトウェアを抽出し、その抽出した物理設備又はソフトウェアが複数個になる場合もある。

この場合に、抽出した複数個の物理設備又はソフトウェアについて説明する。まず、図１を参照して前記したように、通信ネットワーク１０上の各部にＩＤ（物理設備ＩＤ、サーバＩＤ、ソフトウェアＩＤ）が付されている。
これに対して、物理設備ＩＤ及びソフトウェアＩＤとして、当該ＩＤが示す物理設備又はソフトウェアと、当該物理設備又はソフトウェアと親子関係又は接続関係にある他の物理設備、ソフトウェア、又はサーバとの相関関係を示すものを用いるようにする。

図１３は、図１の例において、物理設備ＩＤ、ソフトウェアＩＤとして、このような相関関係のあるＩＤを用いた例を示す図である。例えば、物理設備ＩＤが“ｌ１：ｓｖ０１：ｓ１”であるリンク１３において、物理設備ＩＤの“ｌ１”の部分は当該リンク１３自体を示しており、これに続く“ｓｖ０１”の部分は当該スイッチ１２と接続関係にあるサーバ１１のＩＤを示し、同様に、“ｓ１”の部分は当該スイッチ１２と接続関係にあるスイッチ１２のＩＤを示している。
このような物理設備ＩＤ及びソフトウェアＩＤを用いることで、当該ＩＤから当該ＩＤと親子関係又は接続関係にある他の物理設備、ソフトウェア、又はサーバを認識することができる。

図１４は、図１３のＩＤを用いて実行する処理の説明図である。この例では、図１２の処理で求めた今回の結果が、物理設備ＩＤ又はソフトウェアＩＤ（の図１の例に相当する部分だけを図１４に示している）が、それぞれ“ｂ２”、“ｖｓ２”、“ｌ２”の場合の物理設備又はソフトウェアのカウントの数がいずれも“２５”である。すなわち、前記のサービス影響の原因である物理設備又はソフトウェアが複数推定された場合である。この場合に、構成要素抽出部６３は、今回の当該複数の物理設備又はソフトウェア同士、又は、前回行われた処理で推定された物理設備又はソフトウェアと今回行われた処理で推定された物理設備又はソフトウェアとについて前記の親子関係又は接続関係がある場合に、今回行われて複数推定された物理設備又はソフトウェアのカウントの数に優先度をつける。

図１４の例では、ソフトウェアＩＤが“ｂ２（図１３では、“ｂ２：ｖｓ２”）”のアプリケーションソフト２２と、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１との間には親子関係（前者が子、後者が親）があるため、親であるソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１の優先度を＋１だけ上げる。また、物理設備ＩＤが“ｌ２（図１３では、“ｌ２：ｓｖ０２：ｓ１”）”のリンク１３の前回の結果と、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１の今回の結果との間には直接的な接続関係があるため、物理設備ＩＤが“ｌ２（図１３では、“ｌ２：ｓｖ０２：ｓ１”）”のリンク１３の影響が波及したと推定し、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１の今回の結果の優先度を−０．５下げる。
物理設備ＩＤが“ｓ３（図１３では、“ｓ３：ｌ４：ｌ５”）”のスイッチ１２の前回の結果と、今回の結果との間には、親子関係又は接続関係がないため、当該スイッチ１２が単独で故障していると推定し、＋１だけ優先度を上げる。

これらの結果、ソフトウェアＩＤが“ｂ２（図１３では、“ｂ２：ｖｓ２”）”のアプリケーションソフト２２の最終結果は“２５”、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２”）”の仮想スイッチ２１の最終結果は“２５．５”、物理設備ＩＤが“ｓ３（図１３では、“ｓ３：ｌ４：ｌ５”）”のスイッチ１２の最終結果は“２６”となる。

以上の処理により、物理設備及びソフトウェアの探索順序は、最終結果の値が大きい物理設備ＩＤが“ｓ３（図１３では、“ｓ３：ｌ４：ｌ５）”のスイッチ１２、ソフトウェアＩＤが“ｖｓ２（図１３では、“ｖｓ２：ｂ１：ｂ２）”の仮想スイッチ２１、ソフトウェアＩＤが“ｂ２（図１３では、“ｂ２：ｖｓ２”）”のアプリケーションソフト２２の順番となる。

以上説明した本実施形態によれば、ソフトウェアの故障や劣化も検出でき、作業が簡易で、装置規模が比較的小規模であり、サービス品質の劣化が生じている原因箇所の推定もできるサービス影響原因推定装置１、サービス影響原因推定プログラム４５、及びサービス影響原因推定方法を提供することができる。

１ サービス影響原因推定装置
４５ サービス影響原因推定プログラム
５０ 記憶部
６０ 処理部（推定部）
６１ モデル生成部
７０ 管理部（推定部）
６３１ 第１原因特定部
６３２ 第２原因特定部
７２１ グループ構成部
７４１ 試験パケット生成部
７４２ リスト生成部
７４３ パケット送信部
７４４ パケット受信部
７４５ リプライ格納部

Claims (12)

1. 通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアのうち少なくとも１つ以上を用いて構成されるフローについて、当該フローを識別するフローＩＤと、前記物理設備を識別する物理設備ＩＤ、前記物理設備であるサーバを識別するサーバＩＤ、及び当該各サーバで用いられる前記ソフトウェアを識別するソフトウェアＩＤとを関連付けて記憶する記憶部と、
   前記記憶部を参照して、前記各フローについてデータが流れる前記物理設備及びソフトウェアの前記ＩＤと当該データが流れる順番を特定するモデルであるフローモデルを生成するモデル生成部と、
   前記フローモデル同士を比較して当該比較結果から前記通信ネットワーク上でのサービス影響の原因となる前記物理設備又は前記ソフトウェアを推定する推定部と、
   を備えたことを特徴とするサービス影響原因推定装置。
2. 前記推定部は、
   前記ソフトウェアＩＤを格納できるリストを生成するリスト生成部と、
   前記リストを備えた試験パケットを生成する試験パケット生成部と、
   前記試験パケットを前記フローごとに所定時間内に所定数送信するパケット送信部と、
   前記試験パケットが通過した前記ソフトウェアのＩＤを前記リストに格納した当該試験パケットのリプライパケットを受信するパケット受信部と、
   前記受信したリプライパケットを格納するリプライ格納部と、
   を備えたことを特徴とする請求項１に記載のサービス影響原因推定装置。
3. 前記リプライ格納部に格納されている前記リプライパケットの受信についての計測結果に基づいて前記各フローを正常グループと異常グループとに分類するグループ構成部を備えたことを特徴とする請求項２に記載のサービス影響原因推定装置。
4. 前記グループ構成部は、前記計測結果としてのレスポンスタイム及び前記計測結果としてのリプライのカウント数がそれぞれ各所定値の範囲内にあり、かつ、前記記憶部から取得したソフトウェアＩＤと前記リプライパケットのリストに格納されたソフトウェアＩＤとを比較し、全てのソフトウェアＩＤが一致した前記フローを正常グループに分類し、それ以外の前記フローを異常グループに分類することを特徴とする請求項３に記載のサービス影響原因推定装置。
5. 前記グループ構成部は、前記異常グループについて、前記レスポンスタイムの実測値及び前記カウント数がそれぞれ各所定値の範囲内にあるとき、又は、記憶部から取得したソフトウェアＩＤと前記リプライパケットのリストに格納されたソフトウェアＩＤとを比較し、少なくとも1つ以上のソフトウェアＩＤが一致しない前記フローを故障グループに分類し、それ以外の前記フローを性能劣化グループに分類することを特徴とする請求項４に記載のサービス影響原因推定装置。
6. 前記グループ構成部で前記レスポンスタイムに用いる前記所定値は、所定時間内に所定の値だけ送信された前記試験パケットに対する前記レスポンスタイムについて平均値をとる又は統計的手法を用いることで求めるものであり、前記カウント数に用いる前記所定値は、所定時間内に所定の値だけ送信された前記試験パケットに対する前記カウント数の平均値をとる又は統計的手法を用いることで求めるものであることを特徴とする請求項４又は５に記載のサービス影響原因推定装置。
7. 前記推定部は、
   前記性能劣化グループ内又は前記故障グループ内で前記各フローのフローモデル同士を比較し、共通する前記物理設備又は前記ソフトウェアを抽出し、当該抽出した物理設備又はソフトウェアを前記サービス影響の原因として推定する第１の原因特定部と、
   前記性能劣化グループ又は前記故障グループと、前記正常グループとの間で前記各フローのフローモデル同士を比較して、共通する前記物理設備又は前記ソフトウェアは前記サービス影響の原因の候補から除外し、残った前記物理設備又は前記ソフトウェアを抽出して、当該抽出した前記物理設備又は前記ソフトウェアを前記サービス影響の原因として推定する第２の原因特定部と、
   を備えたこと特徴とする請求項５に記載のサービス影響原因推定装置。
8. 前記推定部は、前記故障又は性能劣化グループに割り振られたフローの数が、同じグループについての所定の閾値以上の場合は前記第１の原因特定部を用い、前記所定の閾値未満の場合は前記第１の原因特定部を用いた後、前記第２の原因特定部を用いて前記サービス影響の原因の推定を行うことを特徴とする請求項７に記載のサービス影響原因推定装置。
9. 前記推定部は、前記性能劣化グループ内又は前記故障グループ内で前記各フローのフローモデル同士を比較し、共通する前記物理設備又は前記ソフトウェアの数をそれぞれカウントし、その後、当該比較をした前記性能劣化グループ又は前記故障グループと前記正常グループとの間で前記各フローのフローモデル同士を比較し、共通する前記物理設備又は前記ソフトウェアについては前記カウントの数を０とし、最終的に前記カウントの数が最大である前記物理設備又は前記ソフトウェアを抽出し、当該抽出した前記物理設備又は前記ソフトウェアを前記サービス影響の原因であるものとして推定すること特徴とする請求項５に記載のサービス影響原因推定装置。
10. 前記記憶部は、前記物理設備ＩＤ及び前記ソフトウェアＩＤとして、当該ＩＤが示す物理設備又はソフトウェアと、当該物理設備又はソフトウェアと親子関係又は接続関係にある他の物理設備、ソフトウェア、又はサーバとの相関関係を示すものであり、
    前記推定部は、前記サービス影響の原因である前記物理設備又は前記ソフトウェアが複数推定された場合に、当該複数の物理設備又はソフトウェア同士、又は、前回行われた前記推定で推定された前記物理設備又は前記ソフトウェアと今回行われた前記推定で推定された前記物理設備又は前記ソフトウェアとについて前記親子関係又は接続関係がある場合に、今回行われて複数推定された前記物理設備又は前記ソフトウェアの前記カウントの数に優先度をつけること特徴とする請求項９に記載のサービス影響原因推定装置。
11. 通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアのうち少なくとも１つ以上を用いて構成されるフローについて、当該フローを識別するフローＩＤと、前記物理設備を識別する物理設備ＩＤ、前記物理設備であるサーバを識別するサーバＩＤ、及び当該各サーバで用いられる前記ソフトウェアを識別するソフトウェアＩＤとを関連付けて記憶する記憶部を参照して、前記各フローについてデータが流れる前記物理設備及びソフトウェアの前記ＩＤと当該データが流れる順番を特定するモデルであるフローモデルを生成するモデル生成処理と、
    前記フローモデル同士を比較して当該比較結果から前記通信ネットワーク上でのサービス影響の原因となる前記物理設備又は前記ソフトウェアを推定する推定処理と、
    をコンピュータに実行させることを特徴とするコンピュータに読み取り可能なサービス影響原因推定プログラム。
12. 通信ネットワーク上でデータが受け渡しされる物理設備及びソフトウェアのうち少なくとも１つ以上を用いて構成されるフローについて、当該フローを識別するフローＩＤと、前記物理設備を識別する物理設備ＩＤ、前記物理設備であるサーバを識別するサーバＩＤ、及び当該各サーバで用いられる前記ソフトウェアを識別するソフトウェアＩＤとを関連付けて記憶する記憶部を参照して、前記各フローについてデータが流れる前記物理設備及びソフトウェアの前記ＩＤと当該データが流れる順番を特定するモデルであるフローモデルを生成するモデル生成工程と、
    前記フローモデル同士を比較して当該比較結果から前記通信ネットワーク上でのサービス影響の原因となる前記物理設備又は前記ソフトウェアを推定する推定工程と、
    を備えたことを特徴とするサービス影響原因推定方法。

Images