JP5434562B2 - 運用管理プログラム、運用管理装置および運用管理方法 - Google Patents

Description

本発明は情報処理システムの運用を管理する運用管理プログラム、運用管理装置および運用管理方法に関する。

従来、複数のコンピュータが階層的に処理を分担する情報処理システム（多階層システムという）が利用されている。多階層システムとして、例えばシステム利用のためのインタフェースを提供するＷｅｂサーバ、システム上の処理を実行するＡｐｐ（Application）サーバおよびデータを管理するＤＢ（Database）サーバを有する３階層システムが知られている。各サーバは、ユーザからの処理要求に対して連携して処理を実行し、その処理要求に応答する。このように、各コンピュータに処理を分担させることで、システムの信頼性や応答性を向上できる。

ところで、情報処理システムでは安定稼働を目的とした運用管理が行われる。特に、多階層システムは重要な業務システムに用いられることが多く、処理の応答性に高いパフォーマンスを求められることも多い。このため、システムの応答性が低下する場合には、何れの階層で処理遅延などの要因が生じているかを的確に把握できることが望ましい。

コンピュータ上で遅延箇所を特定するためには、所定のエージェントをコンピュータ上で実行させて、ハードウェア資源やソフトウェア資源の利用状況を取得することが考えられる。例えば、このような利用状況に基づき、コンピュータ上の何れの資源に遅延の主要因が存在するかを解析する技術がある。

多階層システムでは、管理対象の各コンピュータについて取得した情報に基づき、各コンピュータのリソースの利用状況や処理時間の伸長率等を取得することが考えられる。例えば、リソースの不足や処理時間の伸長により、何れの階層のコンピュータで処理遅延が生じているかを特定する技術がある。

また、ネットワーク上を流れる通信パケットに基づき処理要求に対する各コンピュータの処理時間や応答時間を見積もることで、多階層システムにおける遅延箇所を特定する方法も考えられる。

特開２００５−３３９４３７号公報 特許第３９４４１６７号公報 特開２００５−１３５４２６号公報 特開２００６−０１１６８３号公報 特開２００８−１５８８８９号公報

ここで、多階層システムにおいて処理遅延のボトルネックとなっている階層（あるいはコンピュータ、以下同じ）を特定することは重要である。なぜなら、複数の階層で処理遅延が発生している場合、ボトルネックとなっている階層の遅延が、他の階層の処理に影響を及ぼしている可能性があるからである。このような場合には、ボトルネックとなっている階層を特定して、その原因を解消することがシステム全体の性能向上を図る上では効率的である。

ところが、各コンピュータのリソースの利用状況や処理時間等を収集する場合、従来の技術で解析しても、適切にボトルネックを検出できない場合が生じ得る。例えば、アプリケーションソフトウェアの設定によって並列実行可能な処理数が制限されている場合が考えられる。この場合、そのコンピュータではリソース不足や処理遅延が発生しないことが考えられる。すなわち、従来の何れの方法でも、該当のコンピュータにおいて、これを異常として検出することが困難である。よって、ボトルネックの要因が看過される恐れがある。

本発明はこのような点に鑑みてなされたものであり、ボトルネック候補となる情報処理装置を適切に検出することができる運用管理プログラム、運用管理装置および運用管理方法を提供することを目的とする。

本発明では上記の課題を解決するために、運用管理プログラムが提供される。この運用管理プログラムを実行するコンピュータは、計数手段および処理手段として機能する。計数手段は、情報処理装置から取得した、所定の時間間隔で得られたＮ（Ｎは１≦Ｎの整数）個のサンプリングタイミングから、各サンプリングタイミング時に情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）を得る。処理手段は、Ｘｉの総和に対する、Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理を、複数の情報処理装置について行い、求めた割合が所定値以上の情報処理処置を検出する。

また、上記運用管理プログラムを実行するコンピュータと同様の機能を有する運用管理装置が提供される。また、上記運用管理プログラムと同様の処理を行う運用管理方法が提供される。

上記運用管理プログラム、運用管理装置および運用管理方法によれば、ボトルネック候補となる情報処理装置を適切に検出することができる。

第１の実施の形態に係る運用管理装置を示す図である。 第２の実施の形態の業務システムの全体構成を示す図である。 第２の実施の形態の運用管理サーバのハードウェア構成を示す図である。 第２の実施の形態の運用管理サーバの機能構成を示す図である。 業務システムにおける通信の流れの具体例を示すシーケンス図である。 復元メッセージを例示する図である。 復元メッセージを例示する図である。 第２の実施の形態のメッセージ管理テーブルのデータ構造例を示す図である。 第２の実施の形態のカウンタテーブルのデータ構造例を示す図である。 第２の実施の形態の処理要求滞在数テーブルのデータ構造例を示す図である。 集中度の定義を示す図である。 正規分布か否かの判定方法の具体例を示す図である。 第２の実施の形態のパケットキャプチャ処理を示すフローチャートである。 第２の実施の形態の監視処理を示すフローチャートである。 第２の実施の形態のボトルネック検出処理を示すフローチャートである。 処理要求滞在数の時系列推移の第１のパターンを例示する図である。 処理要求滞在数の頻度分布の第１のパターンを例示する図である。 処理要求滞在数の時系列推移の第２のパターンを例示する図である。 処理要求滞在数の頻度分布の第２のパターンを例示する図である。 処理要求滞在数の時系列推移の第３のパターンを例示する図である。 処理要求滞在数の頻度分布の第３のパターンを例示する図である。 第３の実施の形態の運用管理サーバの機能構成を示す図である。 第３の実施の形態の業務モデル定義ファイル群を例示する図である。 第３の実施の形態の業務メッセージ解析データを例示する図である。 第３の実施の形態のメッセージ管理テーブルのデータ構造例を示す図である。 第３の実施の形態のカウンタテーブルのデータ構造例を示す図である。 第３の実施の形態のカウンタテーブルの変形例を示す図である。 第３の実施の形態の処理要求滞在数テーブルのデータ構造例を示す図である。 第３の実施の形態のボトルネック検出処理を示すフローチャートである。 第４の実施の形態の運用管理サーバの機能構成を示す図である。 業務モデルごとの処理要求滞在数の時系列推移を例示する図である。 第４の実施の形態のフーリエ解析結果テーブルのデータ構造例を示す図である。 第４の実施の形態の合成振幅テーブルを例示する第１の図である。 第４の実施の形態の合成振幅テーブルを例示する第２の図である。 第４の実施の形態の監視処理を示すフローチャートである。 第４の実施の形態のボトルネック検出対象選択処理を示すフローチャートである。 第４の実施の形態のボトルネック検出処理を示すフローチャートである。 第５の実施の形態の運用管理サーバの機能構成を示す図である。 第５の実施の形態の監視処理を示すフローチャートである。 第５の実施の形態のサンプリング周期変更処理を示すフローチャートである。 サンプリング周期変更による頻度分布の変化を例示する図である。 第６の実施の形態の運用管理サーバの機能構成を示す図である。 第６の実施の形態のボトルネック検出処理を示すフローチャートである。

以下、本実施の形態を図面を参照して詳細に説明する。
［第１の実施の形態］
図１は、第１の実施の形態に係る運用管理装置を示す図である。運用管理装置１は、情報処理装置２，３，４と通信可能である。運用管理装置１および情報処理装置２，３，４は、情報処理システムを構成する。

情報処理装置２，３，４は、互いに連携してシステム上の処理を実行する。情報処理装置２，３，４は、例えば、多階層システムである。多階層システムの一例として、Ｗｅｂ３階層システムが考えられる。

運用管理装置１は、情報処理装置２，３，４の稼働状況を管理する。運用管理装置１は、履歴情報記憶部１ａ、計数部１ｂおよび処理部１ｃを有する。
履歴情報記憶部１ａは、情報処理装置２，３，４で発生した処理要求の履歴を示す履歴情報を記憶する。履歴情報は、例えば、情報処理装置２，３，４の間で送受信される通信情報を運用管理装置１で収集したものである。このような通信情報には、情報処理装置２，３，４の間での処理要求や処理要求に対する応答を示すメッセージが含まれる。また、履歴情報は、例えば、情報処理装置２，３，４で取得された処理のログであってもよい。このログには、上述の通信情報と同様に処理要求を受け付けたことや処理要求に対する応答を示すメッセージ、あるいは、これと同等の内容を示す情報が含まれる。

計数部１ｂは、情報処理装置から取得した、所定の時間間隔で得られたＮ（Ｎは１≦Ｎの整数）個のサンプリングタイミングから、各サンプリングタイミング時に情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）を得る。具体的には、計数部１ｂは、履歴情報記憶部１ａに記憶された履歴情報に基づいて、所定期間ごとのサンプリングタイミングにおいて情報処理装置２，３，４で処理中の処理要求の数を計数し処理要求滞在数とする。

ここで、「処理要求の滞在」について説明する。「処理要求が滞在している」状態とは、その情報処理装置において、その処理要求に対する処理を実行中である状態をいう。なお、その処理要求が上位の階層の情報処理装置から依頼されたものであれば、上位の情報処理装置でその依頼に対する応答を受け付けるまでは、依頼元の処理要求が上位の情報処理装置に「滞在した」状態となる。計数部１ｂは、例えば履歴情報に含まれるメッセージとメッセージに対応付けられたタイムスタンプとに基づいて、所定期間ごとの処理要求滞在数を計数することができる。

処理部１ｃは、Ｘｉの総和に対する、Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理を、複数の情報処理装置について行い、求めた該割合が所定値以上の情報処理処置を検出する。具体的には、処理部１ｃは情報処理装置２，３，４ごとに計数対象となったサンプリングタイミングの総数に対する処理要求滞在数の最大値から所定範囲内の値の処理要求滞在数となるサンプリングタイミングの数の占める割合を情報処理装置２，３，４ごとの集中度とする。そして、処理部１ｃは、集中度が所定値以上である情報処理装置を検出する。

ここで、集中度とは、該当の情報処理装置の分布について、処理要求滞在数が最大値から所定範囲内であったイベントが該当の分布に含まれる全イベントに対してどれ程存在したかを示す指標である。

所定範囲を決める情報として、例えば「特定した最大値から“最大値のＺ％”（ただし、Ｚは０より大きく１００よりも小さい実数）の値の範囲内とする」という条件が予め設定される。

例えば、処理部１ｃは情報処理装置２について処理要求滞在数の頻度分布５を取得する。また、例えば処理部１ｃは情報処理装置３について処理要求滞在数の頻度分布６を取得する。また、例えば処理部１ｃは情報処理装置４について処理要求滞在数の頻度分布７を取得する。なお、頻度とは各処理要求滞在数となるサンプリング時刻の数を示す。

例として“Ｚ＝１０”および情報処理装置の検出のための集中度の所定値が“０．８”と設定されている場合を考える。まず、処理部１ｃは頻度分布５，６，７に含まれる処理要求滞在数の最大値を特定する。頻度分布５であれば、処理部１ｃは、例えば最大値“４３”を特定する。そして、最大値“４３”から“４３×０．１＝４．３”の値の範囲内、すなわち、“３８．７以上４３以下”の範囲における集中度を算出する。処理部１ｃは、頻度分布５についてこの範囲における集中度を、例えば“０．２”と算出する。この場合、集中度の所定値“０．８”よりも小さい。よって、処理部１ｃは情報処理装置２を検出しない。

また、頻度分布６についても同様にして、処理部１ｃは集中度を例えば“０．５”と算出する。この場合も集中度の所定値“０．８”よりも小さい。よって、処理部１ｃは情報処理装置３を検出しない。

また、頻度分布７についても同様にして、処理部１ｃは集中度を例えば“０．９”と算出する。この場合、集中度の所定値“０．８”よりも大きい。よって、処理部１ｃは情報処理装置４を検出する。

なお、集中度を求めるための所定範囲を決める情報として、上述した割合（“Ｚ％”）を指定するパラメータのほか、例えば「特定した最大値から定数値“Ｙ”の範囲内」などという条件を処理部１ｃに予め設定してもよい。

運用管理装置１によれば、計数部１ｂにより、情報処理装置から取得した、所定の時間間隔で得られたＮ個のサンプリングタイミングから、各サンプリングタイミング時に情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）が取得される。処理部１ｃにより、Ｘｉの総和に対する、Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理が、複数の情報処理装置について行われ、求めた割合が所定値以上の情報処理処置が検出される。

このようにして検出された情報処理装置では、処理要求滞在数の最大値において、所定期間当たりに許容される処理要求滞在数が飽和していると考えることができる。この場合、情報処理装置４において処理要求滞在数が飽和して処理要求が受け付けられないために、例えば情報処理装置３において、次に情報処理装置４に依頼すべき処理が滞留する。すなわち、情報処理装置４の処理要求滞在数の飽和状態の影響が情報処理装置３に及び、情報処理装置３で処理遅延を引き起こす要因となる。このため、情報処理装置４は情報処理システムにおける処理のボトルネック候補と捉えることができる。処理部１ｃは、検出した情報処理装置をボトルネック候補としてシステムの管理者に報知してもよい。このようにすれば、管理者はボトルネックの解消作業を早期に開始できる。

また、このような飽和状態は、アプリケーションソフトウェア（以下、アプリケーションという）の動作上、処理要求滞在数（並列実行可能な処理数）に制限が加わっていることに起因するものであると考えられる。このようにアプリケーションの動作上の制限により処理要求滞在数が頭打ちとなる場合には、情報処理装置４において処理時間の増大やリソースの枯渇などの異常がみられないことが多い。したがって、従来のように処理時間やリソースの状況を取得する方法のみでは、このようなボトルネック候補を検出することは困難であった。

これに対し、運用管理装置１は、情報処理装置２，３，４における処理要求滞在数の集中度に基づいてボトルネック候補を検出する。このため、アプリケーションの動作上の制限によって生じるボトルネック候補を適切に検出することができる。

以下の実施の形態では、Ｗｅｂ３階層システムに運用管理装置１を適用する場合を例に採り、更に具体的に説明する。
［第２の実施の形態］
以下、第２の実施の形態を図面を参照して詳細に説明する。

図２は、第２の実施の形態の業務システムの全体構成を示す図である。この業務システムは、運用管理サーバ１００、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００を有する。運用管理サーバ１００、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００は、スイッチ装置１０を介して相互に接続されている。また、スイッチ装置１０は、ネットワーク２０を介して端末装置２１，２２，２３に接続されている。

端末装置２１，２２，２３は、スイッチ装置１０およびネットワーク２０を介してＷｅｂサーバ２００にアクセス可能である。端末装置２１，２２，２３のユーザは、Ｗｅｂサーバ２００が提供するＧＵＩ（Graphical User Interface）を端末装置２１，２２，２３から操作して業務システムを利用できる。ネットワーク２０は、例えばイントラネットである。

なお、ネットワーク２０がインターネットである場合も考えられる。その場合、スイッチ装置１０はファイアウォールとして機能させることもできる。また、Ｗｅｂサーバ２００の属するネットワークセグメントは、例えばＤＭＺ（Demilitarized Zone）として扱われる。

運用管理サーバ１００は、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００の稼働状況を管理する。運用管理サーバ１００は、そのための情報をスイッチ装置１０から取得することができる。すなわち、スイッチ装置１０は、ポートミラーリング機能を有しており、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００の間で送受信される通信パケットを運用管理サーバ１００にも送信する。運用管理サーバ１００は、スイッチ装置１０から送信される通信パケットを受信して、記憶する（パケットキャプチャ）。なお、運用管理サーバ１００で単にパケットキャプチャを行う用途であれば、スイッチ装置１０をリピータハブで代用することもできる。

Ｗｅｂサーバ２００は、端末装置２１，２２，２３で実行されるＷｅｂブラウザから業務システムに対する処理要求（メッセージ）を受け付ける。ここで、Ｗｅｂサーバ２００と端末装置２１，２２，２３とのメッセージ交換は、ＨＴＴＰ（HyperText Transfer Protocol）によって行われるものとする。ただし、他のプロトコルが用いられてもよい。

以下では、端末装置２１，２２，２３からＷｅｂサーバ２００へ送信する処理要求をＨＴＴＰリクエストと呼ぶこととする。また、それに対する応答をＨＴＴＰレスポンスと呼ぶこととする。なお、リクエスト／レスポンスともに処理要求の一例である。

Ｗｅｂサーバ２００は、端末装置２１，２２，２３から受信したＨＴＴＰリクエストに基づいて、静的コンテンツに関しては自装置でＨＴＴＰレスポンスを生成し、端末装置２１，２２，２３に送信する。なお、動的コンテンツに関しては、Ａｐｐサーバ３００に依頼すべき処理の処理要求（メッセージ）を生成して、Ａｐｐサーバ３００に送信する。

ここで、Ｗｅｂサーバ２００とＡｐｐサーバ３００とのメッセージ交換は、ＩＩＯＰ（Internet Inter-ORB（Object Request Broker） Protocol）によって行われるものとする。ただし、他のプロトコルが用いられてもよい。

以下では、Ｗｅｂサーバ２００からＡｐｐサーバ３００へ送信する処理要求をＩＩＯＰリクエストと呼ぶこととする。また、それに対する応答をＩＩＯＰレスポンスと呼ぶこととする。

Ｗｅｂサーバ２００は、ＩＩＯＰリクエストに対するＩＩＯＰレスポンスを受信すると、その内容に基づいてＨＴＴＰレスポンスを生成して、端末装置２１，２２，２３に送信する。

Ａｐｐサーバ３００は、Ｗｅｂサーバ２００から受信したＩＩＯＰリクエストに基づいてＤＢサーバ４００に依頼すべき処理のクエリを生成し、ＤＢサーバ４００に送信する。
ここで、Ａｐｐサーバ３００が生成するクエリは、例えばＳＱＬ文によって表記される。以下では、Ａｐｐサーバ３００がＤＢサーバ４００に送信するクエリをＤＢリクエストと呼ぶこととする。また、それに対する応答をＤＢレスポンスと呼ぶこととする。

Ａｐｐサーバ３００は、ＤＢリクエストに対するＤＢレスポンスを受信すると、その内容に基づいてＩＩＯＰレスポンスを生成してＷｅｂサーバ２００に送信する。
ＤＢサーバ４００は、Ａｐｐサーバ３００から受信したＤＢリクエストに含まれるＳＱＬ文を実行してＤＢの参照や更新等の処理を実行する。ＤＢサーバ４００は、その処理結果に基づいてＤＢレスポンスを生成し、Ａｐｐサーバ３００に送信する。

なお、業務システムにおいてＷｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００と各層（Ｗｅｂ層、Ａｐｐ層およびＤＢ層）一台ずつの構成を例示したが、各層にそれぞれ複数台のサーバを設けてもよい。

また、以下では各サーバという場合、Ｗｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００を示すものとする。更に、Ｗｅｂサーバ２００は、Ａｐｐサーバ３００およびＤＢサーバ４００よりも上位の階層のサーバであるとする。また、Ａｐｐサーバ３００は、ＤＢサーバ４００よりも上位の階層のサーバであるとする。このような階層関係を定義する情報は、運用管理サーバ１００に予め格納される。

図３は、第２の実施の形態の運用管理サーバのハードウェア構成を示す図である。運用管理サーバ１００は、ＣＰＵ（Central Processing Unit）１０１、ＲＯＭ（Read Only Memory）１０２、ＲＡＭ（Random Access Memory）１０３、ＨＤＤ（Hard Disk Drive）１０４、グラフィック処理装置１０５、入力インタフェース１０６、記録媒体読取装置１０７および通信インタフェース１０８を有する。

ＣＰＵ１０１は、運用管理サーバ１００全体を制御する。
ＲＯＭ１０２は、運用管理サーバ１００上のＢＩＯＳ（Basic Input / Output System）のプログラムなどを記憶する。

ＲＡＭ１０３は、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションのプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０３は、ＣＰＵ１０１による処理に必要な各種データを記憶する。

ＨＤＤ１０４は、ＯＳのプログラム、アプリケーションのプログラムを記憶する。また、ＨＤＤ１０４はＣＰＵ１０１による処理に必要な各種データを記憶する。なお、ＨＤＤ１０４に代えて（または、ＨＤＤ１０４と併せて）、ＳＳＤ（Solid State Drive）など他の種類の記憶装置を用いてもよい。

グラフィック処理装置１０５は、モニタ１１と接続される。グラフィック処理装置１０５は、ＣＰＵ１０１からの命令に従って画像をモニタ１１の画面に表示させる。
入力インタフェース１０６は、キーボード１２とマウス１３と接続される。入力インタフェース１０６は、キーボード１２やマウス１３から送られてくる信号をＣＰＵ１０１に送信する。

記録媒体読取装置１０７は、記録媒体１４に記憶されたデータを読み取る読取装置である。例えば、運用管理サーバ１００が有すべき機能は、その機能の処理内容を記述したプログラムをコンピュータに実行させることで実現できる。そのようなプログラムは、コンピュータ読み取り可能な記録媒体１４に記録して配布することができる。また、スイッチ装置１０あるいはネットワーク２０に接続されたプログラム配信サーバ（図示せず）にそのプログラムを格納してもよい。この場合、運用管理サーバ１００は、スイッチ装置１０あるいはネットワーク２０を介してプログラム配信サーバからプログラムをダウンロードすることができる。

記録媒体１４としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリを使用できる。磁気記録装置には、ＨＤＤ、フレキシブルディスク（ＦＤ：Flexible Disk）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−Ｒ／ＲＷ／ＲＡＭなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。半導体メモリには、ＵＳＢ（Universal Serial Bus）メモリなどのフラッシュメモリがある。

通信インタフェース１０８は、ＴＰ（Twisted Pair）ケーブルや光ケーブル等によってスイッチ装置１０と接続される。通信インタフェース１０８は、スイッチ装置１０を介して他の情報処理装置とデータ通信する。また、通信インタフェース１０８は、各サーバの間で送受信される通信パケットをスイッチ装置１０から受信する。

なお、Ｗｅｂサーバ２００、Ａｐｐサーバ３００、ＤＢサーバ４００および端末装置２１，２２，２３も運用管理サーバ１００と同様のハードウェア構成により実現できる。
図４は、第２の実施の形態の運用管理サーバの機能構成を示す図である。運用管理サーバ１００は、パケット記憶部１１０、計数情報記憶部１２０、パケット受信部１３０、計数部１４０、ボトルネック検出処理部１５０および報知部１６０を有する。これらの機能は、所定のプログラムをＣＰＵ１０１が実行することで実現される。なお、これらの機能の少なくとも一部または全部を専用のハードウェアにより実現してもよい。

パケット記憶部１１０は、キャプチャしたパケット情報を記憶する。
計数情報記憶部１２０は、各サーバにおける処理要求滞在数を示す情報（以下、計数情報という）を記憶する。

パケット受信部１３０は、スイッチ装置１０を介して送受信される通信パケットをスイッチ装置１０から受信する。パケット受信部１３０は、受信した通信パケットをパケット情報としてパケット記憶部１１０に格納する。

計数部１４０は、パケット記憶部１１０に記憶されたパケット情報に基づいて、各サーバの間で送受信されるメッセージを復元する。計数部１４０は、復元したメッセージに基づいて各サーバにおける処理要求滞在数を計数し、計数情報を生成する。計数部１４０は、生成した計数情報を計数情報記憶部１２０に格納する。

ボトルネック検出処理部１５０は、計数情報記憶部１２０に記憶された計数情報に基づいて、各サーバにおける処理要求滞在数の頻度分布を解析し、頻度分布が以下の条件を満たすサーバをボトルネック候補として検出する。

（条件１）頻度分布において、処理要求滞在数の最大値から所定範囲内におけるイベントの集中度が閾値以上であること。
（条件２）頻度分布でピークをとる処理要求滞在数のうち、最大の処理要求滞在数に対応するピークが正規分布でないこと。

ここで、集中度とは、該当のサーバの分布について、処理要求滞在数が最大値から所定範囲内であったイベントが該当の分布に含まれる全イベントに対してどれ程存在したかを示す指標である。集中度の評価方法の詳細は後述する。

ボトルネック検出処理部１５０は、検出したボトルネック候補からボトルネックとなりうるサーバを特定して、特定結果を報知部１６０に出力する。
報知部１６０は、ボトルネック検出処理部１５０から取得したサーバを示す情報を業務システムの管理者に報知する。

次に、各データ構造例を説明する。まず、業務システムで送受信されるメッセージの流れの具体例を説明する。その後、そのようなメッセージについて管理されるデータ構造例を説明する。

図５は、業務システムにおける通信の流れの具体例を示すシーケンス図である。以下、図５に示す処理をステップ番号に沿って説明する。なお、図５では各ステップにつき、そのメッセージに対応する通信パケットをキャプチャしたタイムスタンプ（時：分：秒．マイクロ秒）が表記されている。

［ステップＳ１］Ｗｅｂサーバ２００は、端末装置２１からＨＴＴＰリクエストを受信する（時刻“０１：５８：１９．９８７３６０”）。
［ステップＳ２］Ａｐｐサーバ３００は、Ｗｅｂサーバ２００からＩＩＯＰリクエストを受信する（時刻“０１：５８：２０．０５７２７５”）。

［ステップＳ３］ＤＢサーバ４００は、Ａｐｐサーバ３００からＤＢリクエストを受信する（時刻“０１：５８：２０．１２０１００”）。
［ステップＳ４］Ａｐｐサーバ３００は、ＤＢサーバ４００からＤＢレスポンスを受信する（時刻“０１：５８：２０．２２５２２１”）。

［ステップＳ５〜Ｓ１０］ＤＢサーバ４００は、Ａｐｐサーバ３００からＤＢリクエストを受信する。そして、Ａｐｐサーバ３００は、それに応じてＤＢサーバ４００からＤＢレスポンスを受信する。

［ステップＳ１１］Ｗｅｂサーバ２００は、Ａｐｐサーバ３００からＩＩＯＰレスポンスを受信する（時刻“０１：５８：２１．２２９２５８”）。
［ステップＳ１２］Ｗｅｂサーバ２００は、端末装置２１にＨＴＴＰレスポンスを送信する（時刻“０１：５８：２１．３３０４３１”）。

このようにして、各サーバの間で、メッセージが交換される。
なお、端末装置２２，２３から受け付けるＨＴＴＰリクエストに対しても同様の流れとなる。

運用管理サーバ１００は、各装置間で送受信される通信パケットをキャプチャして、対応するメッセージを復元することができる。メッセージを復元する方法として、例えば特開２００６−０１１６８３号公報に記載の方法を利用することができる。

図６，７は、復元メッセージを例示する図である。復元メッセージ１１１は、図５に示した各ステップにおけるメッセージの内容を含む。計数部１４０は、パケット記憶部１１０に記憶されたパケット情報に基づいて、復元メッセージ１１１を得ることができる。なお、復元メッセージ１１１には、各階層間の処理要求および応答に関連するメッセージ以外のメッセージに関しては図示を省略している。

復元メッセージ１１１の各行には、日付フィールド１１１ａ、時刻フィールド１１１ｂ、セッション番号フィールド１１１ｃ、送信元アドレスフィールド１１１ｄ、送信先アドレスフィールド１１１ｅ、コマンド種別フィールド１１１ｆおよびメッセージフィールド１１１ｇが含まれる。

日付フィールド１１１ａは、メッセージをキャプチャした日付を示すフィールドである。
時刻フィールド１１１ｂは、メッセージをキャプチャした時刻を示すフィールドである。

セッション番号フィールド１１１ｃは、業務システムにおけるメッセージの送受信に用いるリソースを管理するためのセッション番号を示すフィールドである。
送信元アドレスフィールド１１１ｄは、メッセージの送信元のコンピュータのＩＰ（Internet Protocol）アドレスおよびポート番号を示すフィールドである。

送信先アドレスフィールド１１１ｅは、メッセージの送信先のコンピュータのＩＰアドレスおよびポート番号を示すフィールドである。
コマンド種別フィールド１１１ｆは、コマンドのリクエスト／レスポンス属性やプロトコル（ＨＴＴＰ、ＩＩＯＰおよびＤＢクエリ用等）の種別を示すフィールドである。

メッセージフィールド１１１ｇは、コマンド種別フィールド１１１ｆに示されたリクエスト等のメッセージ内容を示すフィールドである。
以下、復元メッセージ１１１に付した行番号を示して説明する。

例えば、ステップＳ１のＨＴＴＰリクエストは１行目に対応する。
日付フィールド１１１ａには、その行に対応する通信パケットをキャプチャした日付として、例えば“２００９／０９／０７”が取得される。

また、時刻フィールド１１１ｂには、パケットキャプチャした時刻として、例えば“０１：５８：１９．９８７３６０”が取得される。
また、セッション番号フィールド１１１ｃには、セッション番号として、例えば“１３２２９０−１”が表示される。セッション番号フィールド１１１ｃには、リクエスト／レスポンスの組で一意の情報が取得されている。これは、同一のセッションを用いてリクエストと、そのリクエストに対応するレスポンスが交換されるためである。例えば、１行目のＨＴＴＰリクエストに対応するＨＴＴＰレスポンスとして１８行目のメッセージを特定できる。

送信元アドレスフィールド１１１ｄには、ＨＴＴＰリクエストを送信した端末装置２１のＩＰアドレスとポート番号として、例えば“１９４．１８５．３９．２４：５１２７２”が取得される。

送信先アドレスフィールド１１１ｅには、ＨＴＴＰリクエストの送信先であるＷｅｂサーバ２００のＩＰアドレスとポート番号として、例えば、“１９４．２３．６．２２６：１０４４３”が取得される。

コマンド種別フィールド１１１ｆには、１行目がＨＴＴＰリクエストに関するメッセージであることを示す情報として、例えば“Ｒｅｑｕｅｓｔ ＨＴＴＰ”という情報が取得される。また、メッセージフィールド１１１ｇには、ＨＴＴＰリクエストの内容として、例えば“ＰＯＳＴ ／ｃｇｉ−ｂｉｎ／・・・”という情報が取得される。

このように、復元メッセージ１１１を参照することで、何れのサーバに対して、どのようなメッセージが送信されたかを検出することができる。
ここで、復元メッセージ１１１中のその他のＩＰアドレスと各装置との対応関係は次の通りである。

“１９４．２３．７．１６８”は、Ａｐｐサーバ３００のＩＰアドレスを示す。“１９４．２３．８．１９８”は、ＤＢサーバのＩＰアドレスを示す。“１９４．１８５．３９．２５”は、端末装置２２のＩＰアドレスを示す。

すなわち、Ｗｅｂサーバ２００と端末装置２２との間でのＨＴＴＰリクエスト／ＨＴＴＰレスポンスの送受信を各行に含まれる送信元アドレスフィールド１１１ｄ、送信先アドレスフィールド１１１ｅおよびコマンド種別等によって特定できる。具体的には、復元メッセージ１１１の６，２０行目が対応する。

また、Ｗｅｂサーバ２００とＡｐｐサーバ３００との間でのＩＩＯＰリクエスト／ＩＩＯＰレスポンスの送受信は、復元メッセージ１１１の２，７，１７，１９行目に対応する。

また、Ａｐｐサーバ３００とＤＢサーバ４００との間でのＤＢリクエスト／ＤＢレスポンスの送受信は、復元メッセージ１１１の３〜５、８〜１６行目に対応する。
なお、日付フィールド１１１ａおよび時刻フィールド１１１ｂの情報として、パケット受信部１３０が通信パケットをキャプチャしたタイミングにおけるタイムスタンプが取得されるものとしたが、これに限らない。例えば、通信パケット中に各サーバにおけるパケットの生成時刻や送信時刻の情報が含まれている場合には、その時刻としてもよい。その場合、各サーバで精度良く時刻同期が行われていることが望ましい。

図８は、第２の実施の形態のメッセージ管理テーブルのデータ構造例を示す図である。メッセージ管理テーブル１２１は、計数部１４０によって生成され、計数情報記憶部１２０に格納される。メッセージ管理テーブル１２１は、計数部１４０が計数処理を効率的に実行するためのデータである。

メッセージ管理テーブル１２１には、項番を示す項目、時刻を示す項目、セッション番号を示す項目、プロトコルを示す項目およびＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅを示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのメッセージに関する情報を示す。

項番を示す項目には、レコードを識別する番号が設定される。時刻を示す項目には、メッセージに対応する通信パケットをキャプチャした時刻が設定される。セッション番号を示す項目には、メッセージを送信するために用いられたセッションを識別するセッション番号が設定される。プロトコルを示す項目には、メッセージが何れのプロトコルによるものかを示す情報が設定される。Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅを示す項目には、そのメッセージがリクエスト／レスポンスの何れのものであるかを示す情報が設定される。

メッセージ管理テーブル１２１には、例えば、項番が“１”、時刻が“０１：５８：１９．９８７”、セッション番号が“１３２２９０”、プロトコルが“ＨＴＴＰ”、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅが“Ｒｅｑｕｅｓｔ”という情報が設定される。

このレコードは、復元メッセージ１１１の１行目の内容に対応する。ただし、時刻にはミリ秒までを設定している。この点、更に短い時間単位（例えば、マイクロ秒単位）で時刻を取得してもよい。また、セッション番号にはセッション番号フィールド１１１ｃに含まれる情報のうち、リクエスト／レスポンスの組を特定するために必要な最低限の情報を設定している。以下、セッション番号という場合、メッセージ管理テーブル１２１のセッション番号を示す項目に設定された情報を示すものとする。

図９は、第２の実施の形態のカウンタテーブルのデータ構造例を示す図である。カウンタテーブル１２２は、計数部１４０によってメッセージ管理テーブル１２１に基づいて生成され、計数情報記憶部１２０に格納される。カウンタテーブル１２２は、各メッセージに対応する通信パケットをキャプチャしたタイミングにおける各サーバの処理要求滞在数をカウントしたものである。

カウンタテーブル１２２には、項番を示す項目、時刻を示す項目、Ｗｅｂサーバを示す項目、Ａｐｐサーバを示す項目およびＤＢサーバを示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのタイミングにおける各サーバの処理要求滞在数を示す。

項番を示す項目には、レコードを識別する番号が設定される。時刻を示す項目は、メッセージ管理テーブル１２１の時刻を示す項目に対応する。この時刻は第１の実施の形態におけるサンプリング時刻に対応する。Ｗｅｂサーバを示す項目には、該当の時刻におけるＷｅｂサーバの処理要求滞在数が設定される。Ａｐｐサーバを示す項目には、該当の時刻におけるＡｐｐサーバの処理要求滞在数が設定される。ＤＢサーバを示す項目には、該当の時刻におけるＤＢサーバの処理要求滞在数が設定される。

計数部１４０は、メッセージ管理テーブル１２１を参照して、次の手順によりカウンタテーブル１２２を生成することができる。
（手順１）計数部１４０は、メッセージ管理テーブル１２１からリクエストとそれに対するレスポンスの組を抽出する。対応するリクエスト／レスポンスの組は、セッション番号に基づいて特定できる。ここで、リクエスト／レスポンスの組として抽出できない処理要求（例えば、リクエストは存在するが対応するレスポンスのないもの、あるいは、レスポンスは存在するが対応するリクエストのないもの）は破棄する。

（手順２）計数部１４０は、全メッセージを時刻順に並べる。
（手順３）計数部１４０は、メッセージ管理テーブル１２１の各レコードを時刻順に参照し、各サーバに対するリクエストをキャプチャしたらそのサーバの処理要求滞在数に１加算する。また、そのリクエストに対するレスポンスをキャプチャした時刻で処理要求滞在数を１減算する。

ここで、手順１のような処理を行うのは、リクエスト／レスポンスのどちらか一方が存在しないために処理要求滞在数の値が増加し続けてしまうことを防止するためである。その要因として、例えばサーバで異常処理が発生してレスポンスを返せない場合が考えられる。また、例えば実際にはレスポンスが返っているにもかかわらず、通信パケットのキャプチャ段階でパケット落ちが生じてしまい、運用管理サーバ１００でレスポンスを検出できない場合が考えられる。

カウンタテーブル１２２には、例えば、項番が“１”、時刻が“０１：５８：１９．９８７”、Ｗｅｂサーバが“１”、Ａｐｐサーバが“０”、ＤＢサーバが“０”という情報が設定される。計数部１４０は、メッセージ管理テーブル１２１を参照してこのレコードを生成できる。具体的には、メッセージ管理テーブル１２１によれば時刻“０１：５８：１９．９８７”にＨＴＴＰリクエストの通信パケットがキャプチャされていることが分かる。すなわち、Ｗｅｂサーバ２００に対してＨＴＴＰリクエストが送信されたことを示す。このため、計数部１４０はカウンタテーブル１２２において、Ｗｅｂサーバ２００につき時刻“０１：５８：１９．９８７”で本ＨＴＴＰリクエストによって生じた処理要求滞在数として１を加算する。ただし、カウンタテーブル１２２では時刻“０１：５８：１９．９８７”よりも前には、各サーバの処理要求滞在数が０であった場合を示している。よって、時刻“０１：５８：１９．９８７”におけるＷｅｂサーバ２００の処理要求滞在数は、“０＋１＝１”となる。

また、計数部１４０はその要求に対する応答がなされた場合に、処理要求滞在数を１減算する。例えば、メッセージ管理テーブル１２１によれば、時刻“０１：５８：１９．９８７”のＨＴＴＰリクエスト（セッション番号“１３２２９０”）に対して、時刻“０１：５８：２１．３３０”にＨＴＴＰレスポンス（セッション番号“１３２２９０”）が送信されている。このため、計数部１４０はカウンタテーブル１２２において、Ｗｅｂサーバ２００につき時刻“０１：５８：２１．３３０”で本ＨＴＴＰレスポンスによって減少した処理要求滞在数として１を減算する。ここで、時刻“０１：５８：２１．３３０”の直前の時刻“０１：５８：２１．２９９”でＷｅｂサーバ２００の処理要求滞在数は“２”である。よって、時刻“０１：５８：２１．３３０”におけるＷｅｂサーバ２００の処理要求滞在数は、“２−１＝１”となる。

計数部１４０は、同様にしてＡｐｐサーバ３００およびＤＢサーバ４００における通信パケットをキャプチャした各時刻（サンプリング時刻）における処理要求滞在数を取得することができる。

更に、計数部１４０は取得した複数のサンプリング時刻における処理要求滞在数を所定のサンプリング周期で抽出する。サンプリング周期は、例えば１秒とする。その場合、計数部１４０は、例えば時刻“０１：５８：２０．０００”、“０１：５８：２１．０００”、・・・における各サーバの処理要求滞在数を抽出する。計数部１４０は、時刻“０１：５８：２０．０００”の直前に記録された時刻“０１：５８：１９．９８７”に取得された各サーバの処理要求滞在数を時刻“０１：５８：２０．０００”の各サーバの処理要求滞在数として取得する。また、計数部１４０は時刻“０１：５８：２１．０００”の直前に記録された時刻“０１：５８：２０．９９１”に取得された各サーバの処理要求滞在数を時刻“０１：５８：２１．０００”の各サーバの処理要求滞在数として取得する。

このようにして、計数部１４０はサンプリング周期（例えば、１秒）ごとの各サーバの処理要求滞在数を取得する。
図１０は、第２の実施の形態の処理要求滞在数テーブルのデータ構造例を示す図である。処理要求滞在数テーブル１２３は、計数部１４０によって生成され、計数情報記憶部１２０に格納される。処理要求滞在数テーブル１２３には、サーバ名を示す項目および処理要求滞在数を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのサーバの各時刻における処理要求滞在数を示す。

サーバ名を示す項目には、サーバの名称が設定される。処理要求滞在数を示す項目には、各時刻における処理要求滞在数が設定される。
処理要求滞在数テーブル１２３には、例えばサーバ名が“Ｗｅｂサーバ”、処理要求滞在数が時刻“１：５８：２０”に“２３”、時刻“１：５８：２１”に“２５”、・・・という情報が設定される。これらの値は、カウンタテーブル１２２から対応する時刻の処理要求滞在数として取得した値である。

なお、カウンタテーブル１２２では、処理要求滞在数の変化が分かり易いように小さな値を用いて説明した。しかし、現実のシステム運用の際には、カウンタテーブル１２２では、それよりも大きな値が計数されることが考えられる。そこで、以降の説明をより具体的にするために、処理要求滞在数テーブル１２３ではカウンタテーブル１２２で示した値よりも大きな値でデータを例示している。

ここで、カウンタテーブル１２２および処理要求滞在数テーブル１２３は、頻度分布を取得するための元データであり、計数情報に対応するものである。
なお、計数部１４０がカウンタテーブル１２２から所定のサンプリング周期で処理要求滞在数を抽出する理由は、処理するデータ量を削減して演算コストを低減するためである。ただし、カウンタテーブル１２２をそのまま処理要求滞在数テーブル１２３として扱うこともできる。

図１１は、集中度の定義を示す図である。ボトルネック検出処理部１５０は、計数情報記憶部１２０に記憶された処理要求滞在数テーブル１２３に基づいて、処理要求滞在数の頻度分布６００を得たとする。頻度分布６００には、各処理要求滞在数の値に対する頻度の系列を示す分布関数６０１が示されている。

ボトルネック検出処理部１５０は、次のような方法ＭＡ１または方法ＭＡ２の何れかによって、最大値近傍の分布の集中度を算出する。なお、集中度とは前述したとおり、処理要求滞在数の発生頻度がどれだけ処理要求滞在数の最大値直前に集中しているかを示す指標である。

（方法ＭＡ１）ボトルネック検出処理部１５０は、頻度分布における処理要求滞在数の最大値Ｘを取得する。次に、集中度を求めるための最大値からの範囲を決める比率ｐ（ｐ＜１）をＸに乗じたｐＸを求める。ここで、比率ｐは業務システムを構成するアプリケーションに応じて決定する。比率ｐとして、例えば０．９が予め設定される。そして、ボトルネック検出処理部１５０は、分布全体に含まれるイベント数Ｅ１とｐＸ以上Ｘ以下に含まれる各処理要求滞在数のイベント数Ｅ２との比Ｅ２／Ｅ１を集中度とする。

（方法ＭＡ２）ｐＸを求めるまでは方法ＭＡ１と同様である。次に、ボトルネック検出処理部１５０は、分布関数６０１と横軸とで囲まれる領域の面積Ｓ１を算出する。また、分布関数６０１と横軸と処理要求滞在数＝ｐＸの直線とで囲まれる領域６０２の面積Ｓ２を算出する。そして、各面積の比Ｓ２／Ｓ１を集中度とする。

ここで、方法ＭＡ１をとる場合、最大値Ｘと比率ｐの値によってはＸが小さい値のときに、集中度が最大値Ｘに対応するイベント数のみによって決定されてしまい、集中度を適切に評価できないことが考えられる。例えば、最大値Ｘ＝６、ｐ＝０．９の場合、集中度の評価の対象範囲は、処理要求滞在数が５．４以上６以下の範囲である。このため、Ｅ２の値は、最大値Ｘ（＝６）に対応するイベント数と等しくなり、Ｘよりも小さい処理要求滞在数を考慮した集中度を精度良く評価することができない。

よって、処理要求滞在数の値が小さな値で最大値をとる場合にも集中度を精度良く評価するためには、方法ＭＡ２のように面積比Ｓ２／Ｓ１を集中度とすることが好ましい。なぜなら、このように評価すれば集中度の評価対象範囲の最小値（例えば５．４）と最大値（例えば６）とを集中度の算出結果に反映させることができるためである。以下では、集中度の算出方法として方法ＭＡ２を用いる場合を想定する。

なお、最大値Ｘが大きな値（例えば１０以上の値）のときには方法ＭＡ１を用い、最大値Ｘが小さな値（例えば１０よりも小さい値）のときには方法ＭＡ２を用いてもよい。このようにすると、集中度の評価精度を保ちつつ演算負荷を軽減できる。

図１２は、正規分布か否かの判定方法の具体例を示す図である。ボトルネック検出処理部１５０は、計数情報記憶部１２０に記憶された処理要求滞在数テーブル１２３に基づいて、処理要求滞在数の頻度分布６００ａを得たとする。頻度分布６００ａには、各処理要求滞在数の値に対する頻度の系列を示す分布関数６０１ａが示されている。ここで、頻度分布６００ａには複数のピークが表れることもある。その場合、分布関数６０１ａは複数のピークのうち、処理要求滞在数が最も大きな値に対応するピークを示す分布関数とする。

ボトルネック検出処理部１５０は、分布関数６０１ａで示される分布を正規分布とみなせるか否かを、次のような方法ＭＢ１または方法ＭＢ２の何れかによって判定できる。
（方法ＭＢ１）分布関数６０１ａを正規分布関数でフィッティングする。フィッティングの方法としては、例えば非線形最小二乗法を用いることができる。フィッティングの結果得られた分布関数と分布関数６０１ａとに基づいてχ２乗検定を行う。すなわち、両関数に対応するスペクトルの残差に基づくχ２乗値、χ２乗分布の自由度および各自由度におけるχ２乗分布によりを正規分布とみなすか否かを判定することができる。なお、検定に必要な情報（例えば、各自由度におけるχ２乗分布や検定の有意水準等）は予め与えられる。

（方法ＭＢ２）処理要求滞在数の出現頻度の最も大きな値Ｙから処理要求滞在数の最大値Ｘまでの範囲６０３で分布関数６０１ａが単調減少となっているかを判定する。単調減少となっている場合、正規分布とみなす。単調減少となっていない場合、正規分布とはみなさない。なお、Ｙ＝Ｘの場合には、単調減少にはなっていないものとし、正規分布とはみなさない。

ここで、方法ＭＢ１と方法ＭＢ２とでは、方法ＭＢ２の方がその演算負荷が小さい。よって、正規分布の判定を厳密に行う必要がなく、当判定処理による負荷を軽減するためには、方法ＭＢ２をとることが好ましい。

次に、以上のような構成を備える運用管理サーバ１００の処理手順を詳細に説明する。
図１３は、第２の実施の形態のパケットキャプチャ処理を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。

［ステップＳ１１］パケット受信部１３０は、スイッチ装置１０からの通信パケットの受信の待ち受けを開始する。なお、パケット受信部１３０は、この開始処理を、例えば管理者によるキーボード１２やマウス１３を用いた所定の開始入力（開始コマンド）を受け付けたタイミングで実行する。そして、パケット受信部１３０は、例えば管理者によるキーボード１２やマウス１３を用いた所定の停止入力（停止コマンド）を受け付けるまで以降の処理を繰り返し実行する。

［ステップＳ１２］パケット受信部１３０は、受信した通信パケットをキャプチャして、パケット記憶部１１０に格納する。ここで、パケット受信部１３０は、キャプチャした通信パケット群を所定時間ごとに区切った複数のファイルとして出力する。

［ステップＳ１３］パケット受信部１３０は、停止コマンドを受け付けるとパケットキャプチャ処理を停止する。
このように、パケット受信部１３０は、通信パケット群を一定時間溜めた複数のファイルとして出力する。以下、通信パケット群を溜めて１ファイルを生成する時間の周期をボトルネック解析周期と呼ぶこととする。計数部１４０は、ボトルネック解析周期で出力されたファイル単位で計数処理を実行できる。

ここで、ボトルネック解析周期は、長すぎるとパケットデータ量が増大して後段の計数処理の計算量が多くなり運用管理サーバ１００に過大な負荷がかかる。また、短期間で生じるボトルネックを見逃す可能性がある。一方、ボトルネック解析周期は、短すぎるとパケットデータ量が少なすぎて特定の少数の処理に結果が大きく影響を受けてしまう可能性がある。よって、ボトルネック解析周期は、システムを構成するハードウェアやアプリケーションの処理に応じて適切な周期とすることが望ましい。例えば、本実施の形態の業務システムのようなＷｅｂ３階層システムでは１０〜６０秒程度とすることが考えられる。

なお、パケット情報を複数のファイルとして出力することで、パケットキャプチャ処理とボトルネック検出処理とを同時に並列して行うことができる。すなわち、ボトルネック検出のためにパケットキャプチャ処理を停止する必要がないので、パケットキャプチャ処理を停止している間の通信パケットの欠落を防止できる。そして、計数部１４０は、例えばパケット受信部１３０によってパケット記憶部１１０に新たなファイルが出力されるたびに、出力されたファイルの計数処理を実行できる。

次に、ボトルネックの発生の有無を監視する処理を説明する。ボトルネック検出処理は、この監視処理に含まれる。
図１４は、第２の実施の形態の監視処理を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。

［ステップＳ２１］計数部１４０は、パケット受信部１３０がパケット記憶部１１０にファイルを出力したかの監視を開始する。なお、計数部１４０は、この開始処理を、例えば、管理者によるキーボード１２やマウス１３を用いた所定の開始入力（開始コマンド）を受け付けたタイミングで実行する。そして、計数部１４０は、例えば管理者によるキーボード１２やマウス１３を用いた所定の停止入力（停止コマンド）を受け付けるまで以降の処理を繰り返し実行する。ここで、開始コマンドや停止コマンドは、ステップＳ１１に示したパケット受信部１３０に対する各コマンドとそれぞれ同一のコマンドとして受け付けてもよいし、別個のコマンドとして受け付けてもよい。

［ステップＳ２２］計数部１４０は、パケット記憶部１１０に新たなファイルが出力されると、そのファイルを読み取る。
［ステップＳ２３］計数部１４０は、読み取ったファイルに基づいて各サーバで送受信されたメッセージを復元する。

［ステップＳ２４］計数部１４０は、復元したメッセージに基づいてメッセージ管理テーブルを生成し、計数情報記憶部１２０に格納する。計数部１４０は、メッセージ管理テーブルに基づいてカウンタテーブルを生成し、計数情報記憶部１２０に格納する。計数部１４０は、カウンタテーブルに基づいて処理要求滞在数テーブル１２３を生成して、計数情報記憶部１２０に格納する。

［ステップＳ２５］ボトルネック検出処理部１５０は、処理要求滞在数テーブル１２３に基づいて、各サーバにおける処理要求滞在数の頻度分布を求める。そして、ボトルネック検出処理部１５０は、各サーバで求めた分布が所定の条件を満たしているかを判定して、条件を満たすサーバをボトルネック候補として検出する。ボトルネック検出処理部１５０は、ボトルネック候補からボトルネックとなり得るサーバを特定して、特定結果を報知部１６０に出力する。報知部１６０は、ボトルネック検出処理部１５０から取得したサーバを示す情報を業務システムの管理者に報知する。

［ステップＳ２６］計数部１４０は、停止コマンドを受け付けるとファイル出力の監視を停止する。これにより、ボトルネック発生の有無の監視処理が完了する。
このように、計数部１４０は、パケット受信部１３０のパケットキャプチャによって、パケット記憶部１１０に新たなファイルが出力されると、計数処理を実行する。そして、ボトルネック検出処理部１５０は、計数部１４０によって計数情報記憶部１２０に出力された処理要求滞在数テーブル１２３に基づいて、ボトルネック検出処理を実行する。

次に、ステップＳ２５のボトルネック検出処理を詳細に説明する。
図１５は、第２の実施の形態のボトルネック検出処理を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。

［ステップＳ３１］ボトルネック検出処理部１５０は、業務システムの階層単位に以降のステップＳ３８までの処理を繰り返し実行する。なお、本実施の形態では、各階層にサーバは１台ずつであるので、サーバごとに順次実行すればよい。

［ステップＳ３２］ボトルネック検出処理部１５０は、計数情報記憶部１２０に記憶された処理要求滞在数テーブル１２３に基づいて、処理対象のサーバの処理要求滞在数の頻度分布を取得する。

［ステップＳ３３］ボトルネック検出処理部１５０は、取得した頻度分布における処理要求滞在数の最大値を特定する。
［ステップＳ３４］ボトルネック検出処理部１５０は、頻度分布における処理要求滞在数の最大値近傍の集中度を算出する。

［ステップＳ３５］ボトルネック検出処理部１５０は、集中度が閾値以上であるか否かを判定する。閾値以上である場合、処理をステップＳ３６に進める。閾値よりも小さい場合、処理をステップＳ３８に進める。

［ステップＳ３６］ボトルネック検出処理部１５０は、頻度分布が正規分布であるか否かを判定する。正規分布でない場合、処理をステップＳ３７に進める。正規分布である場合、処理をステップＳ３８に進める。

［ステップＳ３７］ボトルネック検出処理部１５０は、処理対象のサーバをボトルネック候補として追加する。
［ステップＳ３８］ボトルネック検出処理部１５０は、全階層（サーバ）について処理済みであれば、処理をステップＳ３９に進める。未処理の階層（サーバ）が存在する場合、処理をステップＳ３１に進める。

［ステップＳ３９］ボトルネック検出処理部１５０は、ステップＳ３１〜Ｓ３８の処理でボトルネック候補を検出しているか否かを判定する。検出している場合、処理をステップＳ４０に進める。検出していない場合、処理を完了する。

［ステップＳ４０］ボトルネック検出処理部１５０は、ボトルネック候補が複数検出されたか否かを判定する。複数ある場合、処理をステップＳ４１に進める。複数でない、すなわち、１つだけ検出されている場合、処理をステップＳ４２に進める。

［ステップＳ４１］ボトルネック検出処理部１５０は、複数のボトルネック候補のうち、最下位の階層のサーバをボトルネックと特定する。例えば、ボトルネック候補としてＡｐｐサーバ３００およびＤＢサーバ４００が検出されている場合、ＤＢサーバ４００をボトルネックと特定する。ボトルネック検出処理部１５０は、特定したボトルネックのサーバを示す情報を報知部１６０に出力する。

［ステップＳ４２］報知部１６０は、ボトルネック検出処理部１５０から取得したボトルネックのサーバを示す情報を管理者に報知する。
このようにして、ボトルネック検出処理部１５０はボトルネックのサーバを検出する。

ボトルネック検出処理部１５０は処理要求滞在数の頻度分布に基づいてボトルネック候補を検出する。このため、従来の方法と比べて複数の階層のサーバで処理遅延等が生じた場合にも適切にボトルネック候補を検出できる。例えば、次のような問題を解決できる。

処理時間等を測定する従来の方法では、上位の階層に対する下位の階層がボトルネックとなっている場合を適切に検知することが困難であった。例えば、上位階層から下位階層に送信される処理要求の数が、下位階層で処理可能な数を超えて際限なく増加すると、下位階層における応答時間が増加し続けることが想定される。しかし、下位階層での処理要求滞在数がアプリケーションの動作設定などで制限されているために、下位階層への処理要求の数が上位階層で適切にコントロールされている場合は、下位階層に対する所定数以上の処理要求の送信が制限される。この場合、下位階層における処理時間の増加はある程度抑制される。その一方で、上位階層では下位階層へ処理要求を送信するまでの待ち時間が増加する。したがって、上位階層で処理遅延が発生する。

この場合、従来の方法では各階層で生じた遅延が、該当の階層の装置の処理時間の増加によるものか、他階層における処理待ちの時間の増加によるものか、を区別することが困難であった。このため、処理待ちの時間が増加した方の階層（上記の例では上位階層）にボトルネックが存在すると誤認してしまう可能性もあった。

これに対し、ボトルネック検出処理部１５０のように処理要求滞在数の頻度分布の集中度を評価する。これにより、アプリケーションによる処理要求滞在数の制限を考慮して適切にボトルネック候補を検出することができる。

なお、各階層に複数のサーバが設けられている場合には、何れの階層がボトルネックとなっているかを検出することができる。例えば、Ｗｅｂ層にＷｅｂサーバが複数台設けられている場合には、計数部１４０は各Ｗｅｂサーバの処理要求滞在数の総和（階層単位処理要求滞在数）をＷｅｂ層における処理要求滞在数として求めることができる。これにより、処理要求滞在数テーブル１２３の処理要求滞在数を示す項目の値をＷｅｂサーバ、ＡｐｐサーバおよびＤＢサーバ単位での値に代えて、Ｗｅｂ層、Ａｐｐ層およびＤＢ層の階層単位処理要求滞在数として取得できる。そして、ボトルネック検出処理部１５０は、このように階層単位で取得された処理要求滞在数テーブルに基づき上記ボトルネック検出処理を実行することで、ボトルネックとなっている階層を特定できる。

更に、このように階層単位でボトルネックを求めるのか、サーバ単位でボトルネックを求めるのかを管理者によって選択可能としてもよい。例えば、運用管理サーバ１００は、そのためのＧＵＩをモニタ１１に表示させる。そして、管理者のキーボード１２やマウス１３を用いた選択操作の入力を受け付けることができる。

以下、ボトルネック検出処理の具体例として３つのパターンを示す。
第１のパターンは、単一のサーバでボトルネックが発生しているケースである。
第２のパターンは、下位の階層のサーバでボトルネックが発生しており、上位の階層のサーバにその影響が波及するパターンである。

第３のパターンは、最下位の階層のサーバでボトルネックが発生しており、上位の全ての階層のサーバにその影響が波及するパターンである。
まず、第１のパターンを説明する。

図１６は、処理要求滞在数の時系列推移の第１のパターンを例示する図である。時系列推移５１０には、系列５１１，５１２，５１３が示されている。系列５１１は、Ｗｅｂサーバ２００の処理要求滞在数の時間推移を示している。系列５１２は、Ａｐｐサーバ３００の処理要求滞在数の時間推移を示している。系列５１３は、ＤＢサーバ４００の処理要求滞在数の時間推移を示している。

時系列推移５１０では、Ａｐｐサーバ３００における処理の並列度が“１５”に制限されていることによって、Ａｐｐサーバ３００にボトルネックが存在している場合を例示している。業務システムの利用予測を誤って、Ａｐｐサーバ３００における最大スレッド数を低く設定してしまったことが本ボトルネック発生の典型的な原因として考えられる。ここで、Ｗｅｂサーバ２００およびＤＢサーバ４００には処理の並列度に制限は存在しない、あるいは、処理の並列度の許容量に十分余裕があるものとする。

この場合、系列５１２に示すようにＡｐｐサーバ３００における処理要求滞在数がほぼ“１５”あるいは、それよりも小さい値をとって推移する。そして、そのうちの一定割合がＤＢサーバ４００へアクセスするので、ＤＢサーバ４００における処理要求滞在数も特定の値をとることが多くなる。ただし、この場合はＤＢサーバ４００の処理要求滞在数に制限は存在していない（あるいは、処理要求滞在数の許容量に十分余裕がある）。よって、系列５１３は最も高頻度の処理要求滞在数を挟む前後の値もとりながら推移する。

図１７は、処理要求滞在数の頻度分布の第１のパターンを例示する図である。頻度分布６１０には、分布６１１，６１２，６１３が示されている。分布６１１は、Ｗｅｂサーバ２００の処理要求滞在数の頻度分布を示している。分布６１１は、系列５１１に対応する。分布６１２は、Ａｐｐサーバ３００の処理要求滞在数の頻度分布を示している。分布６１２は、系列５１２に対応する。分布６１３は、ＤＢサーバ４００の処理要求滞在数の頻度分布を示している。分布６１３は、系列５１３に対応する。

Ｗｅｂサーバ２００およびＤＢサーバ４００では、処理要求滞在数が制限に達しておらず、分布６１１，６１３は正規分布（あるいは、それの複合）に近くなる。一方、Ａｐｐサーバ３００では、系列５１２で示したように処理要求滞在数がほぼ“１５”で推移する。このため、分布６１２は処理要求滞在数“１５”を最大値として頻度のピークをとり、“１５”よりも小さい値に向かって減少する。なお、分布６１２において処理要求滞在数“１６”以上の頻度は“０”である。

ボトルネック検出処理部１５０は、図１５に示したボトルネック検出処理の手順によって分布６１１，６１２，６１３を解析し、ボトルネック候補を検出する。
具体的には、まず、解析対象とするサーバを選択し、そのサーバに対応する分布を取得する。取得した分布に含まれる処理要求滞在数の最大値近傍の集中度を算出する。そして、集中度が所定の閾値以上であるか、その分布が正規分布に従うかを判定する。集中度が所定の閾値以上で、かつ、その分布が正規分布に従う場合には、その分布に対応するサーバをボトルネック候補とする。そして、次のサーバを選択して上記の処理をサーバごとに繰り返す。

例えば、Ｗｅｂサーバ２００は、分布６１１について集中度が所定の閾値以上とならないとして、ボトルネック候補にはならない。また、Ａｐｐサーバ３００は、分布６１２について集中度が所定の閾値以上となり、かつ、正規分布ではないとしてボトルネック候補となる。また、ＤＢサーバ４００は、分布６１３について集中度が所定の閾値以上となるが、正規分布に従うとして、ボトルネック候補にはならない。

このように、ボトルネック検出処理部１５０は、処理要求滞在数に制限が加えられていることによってボトルネックとなっているサーバを適切に検出できる。
上記第１のパターンでは、Ａｐｐサーバ３００にボトルネックが発生しているが、それが継続的なものではない場合を示した。すなわち、長期平均でみると業務システム全体としては、許容される応答時間で処理できる範囲での負荷の場合である。これに対し、端末装置２１，２２，２３から送られてくるリクエストが長期に渡り継続して多量に送信され続けると、そのリクエストは上位のＷｅｂサーバ２００に滞留する。この場合が第２のパターンである。

以下、第２のパターンを説明する。
図１８は、処理要求滞在数の時系列推移の第２のパターンを例示する図である。時系列推移５２０には、系列５２１，５２２，５２３が示されている。系列５２１は、Ｗｅｂサーバ２００の処理要求滞在数の時間推移を示している。系列５２２は、Ａｐｐサーバ３００の処理要求滞在数の時間推移を示している。系列５１３は、ＤＢサーバ４００の処理要求滞在数の時間推移を示している。

時系列推移５２０では、Ａｐｐサーバ３００における処理の並列度が“１５”に制限されていることによって、Ａｐｐサーバ３００にボトルネックが存在している場合を例示している。ここで、Ｗｅｂサーバ２００およびＤＢサーバ４００には処理の並列度に制限は存在しない、あるいは、処理の並列度の許容量に十分余裕があるものとする。

この場合、系列５２２に示すようにＡｐｐサーバ３００における処理要求滞在数がほぼ“１５”あるいは、それよりも小さい値をとって推移する。そして、そのうちの一定割合がＤＢサーバ４００へアクセスするので、ＤＢサーバ４００における処理要求滞在数も特定の値をとることが多くなる。ただし、この場合はＤＢサーバ４００の処理要求滞在数に制限は存在していない（あるいは、処理要求滞在数の許容量に十分余裕がある）。よって、系列５２３は最も高頻度の処理要求滞在数を挟む前後の値もとりながら推移する。

また、Ｗｅｂサーバ２００は端末装置２１，２２，２３からＨＴＴＰリクエストを受信し続けている。このために、Ｗｅｂサーバ２００がＡｐｐサーバ３００に対して依頼する処理のＩＩＯＰリクエスト数がＡｐｐサーバ３００の処理できる許容量（“１５”）を平均して上回っている。この場合、Ｗｅｂサーバ２００ではＡｐｐサーバ３００にＩＩＯＰリクエストを送信したとしても、そのリクエストに対してＡｐｐサーバ３００からＩＩＯＰレスポンスを受信できないといった状態が発生する。Ｗｅｂサーバ２００は、例えば、そのようなＩＩＯＰリクエストにつきＡｐｐサーバ３００からＩＩＯＰレスポンスを得られるまで所定の間隔で再送し続ける。したがって、Ｗｅｂサーバ２００において、端末装置２１，２２，２３に対して、ＨＴＴＰレスポンスを送信できないものが蓄積される。その結果、Ｗｅｂサーバ２００における処理要求滞在数が時間の経過とともに増加し続ける。

図１９は、処理要求滞在数の頻度分布の第２のパターンを例示する図である。頻度分布６２０には、分布６２１，６２２，６２３が示されている。分布６２１は、Ｗｅｂサーバ２００の処理要求滞在数の頻度分布を示している。分布６２１は、系列５２１に対応する。分布６２２は、Ａｐｐサーバ３００の処理要求滞在数の頻度分布を示している。分布６２２は、系列５２２に対応する。分布６２３は、ＤＢサーバ４００の処理要求滞在数の頻度分布を示している。分布６２３は、系列５２３に対応する。

Ｗｅｂサーバ２００およびＤＢサーバ４００では、処理要求滞在数が制限に達しておらず、分布６２１，６２３は正規分布（あるいは、それの複合）に近くなる。一方、Ａｐｐサーバ３００では、系列５２２で示したように処理要求滞在数がほぼ“１５”で推移する。このため、分布６２２は処理要求滞在数“１５”を最大値として頻度のピークをとり、“１５”よりも小さい値に向かって減少する。なお、分布６２２において処理要求滞在数“１６”以上の頻度は“０”である。

また、Ｗｅｂサーバ２００では、系列５２１で示したように処理要求滞在数が時間の経過とともに増加し続ける。このため、分布６２１では、分布６１１で示したよりも大きな値の処理要求滞在数が測定される。

ボトルネック検出処理部１５０は、図１５に示したボトルネック検出処理の手順によって分布６２１，６２２，６２３を解析し、ボトルネック候補を検出する。
例えば、Ｗｅｂサーバ２００は、分布６２１について集中度が所定の閾値以上とならないとして、ボトルネック候補にはならない。また、Ａｐｐサーバ３００は、分布６２２について集中度が所定の閾値以上となり、かつ、正規分布ではないとしてボトルネック候補となる。また、ＤＢサーバ４００は、分布６２３について集中度が所定の閾値以上となるが、正規分布に従うとして、ボトルネック候補にはならない。

このように、ボトルネック検出処理部１５０は、ボトルネックとなっているサーバの影響が波及して、処理要求滞在数が大きく増加した上位のサーバが存在する場合でも、適切にボトルネックとなっているサーバを検出できる。

次に、第３のパターンを説明する。第３のパターンでは、Ａｐｐサーバ３００およびＤＢサーバ４００に処理要求滞在数の制限がある場合である。
図２０は、処理要求滞在数の時系列推移の第３のパターンを例示する図である。時系列推移５３０には、系列５３１，５３２，５３３が示されている。系列５３１は、Ｗｅｂサーバ２００の処理要求滞在数の時間推移を示している。系列５３２は、Ａｐｐサーバ３００の処理要求滞在数の時間推移を示している。系列５３３は、ＤＢサーバ４００の処理要求滞在数の時間推移を示している。

時系列推移５３０では、Ａｐｐサーバ３００における処理の並列度が“２５”に制限され、かつ、ＤＢサーバ４００における処理の並列度が“６”に制限されている場合を例示している。ここで、Ｗｅｂサーバ２００には処理の並列度に制限は存在しない、あるいは、処理要求滞在数の許容量に十分余裕があるものとする。

この場合、系列５３３に示すようにＤＢサーバ４００における処理要求滞在数がほぼ“６”あるいは、それよりも小さい値をとって推移している。一方で、系列５３１で示すように、Ｗｅｂサーバ２００は端末装置２１，２２，２３からのリクエストを受信し続けている。そして、系列５３２に示すようにＡｐｐサーバ３００はＷｅｂサーバ２００から受信するリクエストに応答しきれずに、処理要求滞在数が増加する（時刻“１：５８：２０〜２７”の範囲）。更に、それ以降では系列５３２に示すようにＡｐｐサーバ３００における処理要求滞在数がほぼ“２５”あるいは、それよりも小さい値をとって推移する。

図２１は、処理要求滞在数の頻度分布の第３のパターンを例示する図である。頻度分布６３０には、分布６３１，６３２，６３３が示されている。分布６３１は、Ｗｅｂサーバ２００の処理要求滞在数の頻度分布を示している。分布６３１は、系列５３１に対応する。分布６３２は、Ａｐｐサーバ３００の処理要求滞在数の頻度分布を示している。分布６３２は、系列５３２に対応する。分布６３３は、ＤＢサーバ４００の処理要求滞在数の頻度分布を示している。分布６３３は、系列５３３に対応する。

Ｗｅｂサーバ２００では、処理要求滞在数が制限に達しておらず、分布６３１は正規分布（あるいは、それの複合）に近くなる。また、Ｗｅｂサーバ２００では、系列５３１に示したように処理要求滞在数が時間の経過とともに増加し続ける。

一方、ＤＢサーバ４００では、系列５３３で示したように処理要求滞在数がほぼ“６”で推移する。このため、分布６３３は処理要求滞在数“６”を最大値として頻度のピークをとり、“６”よりも小さい値に向かって減少する。なお、分布６３３において処理要求滞在数“７”以上の頻度は“０”である。

また、Ａｐｐサーバ３００では、系列５３２で示したように処理要求滞在数がほぼ“２５”で推移する。このため、分布６３２は処理要求滞在数“２５”を最大値として頻度のピークをとり、“２５”よりも小さい値に向かって減少するような分布となる。なお、分布６３２において処理滞在数“２６”以上の頻度は“０”である。

ボトルネック検出処理部１５０は、図１５に示したボトルネック検出処理の手順によって分布６３１，６３２，６３３を解析し、ボトルネック候補を検出する。
例えば、Ｗｅｂサーバ２００は、分布６３１について集中度が所定の閾値以上とならないとして、ボトルネック候補にはならない。また、Ａｐｐサーバ３００は、分布６３２について集中度が所定の閾値以上となり、かつ、正規分布ではないとしてボトルネック候補となる。また、ＤＢサーバ４００は、分布６３３について集中度が所定の閾値以上となり、かつ、正規分布ではないとしてボトルネック候補となる。

ここで、ボトルネック検出処理部１５０は、ボトルネック候補としてＡｐｐサーバ３００およびＤＢサーバ４００を検出する。このような場合には、ボトルネック検出処理部１５０は、より下位の階層のサーバをボトルネックと特定する。

すなわち、複数のボトルネック候補が存在する場合には、上位の階層における処理要求滞在数の増加は、下位の階層の処理要求滞在数の増加の影響によって、二次的に引き起こされたと考える。これにより、複数の階層のサーバでボトルネック候補を検出した場合にも、適切にボトルネックを特定することができる。

［第３の実施の形態］
以下、第３の実施の形態について説明する。前述の第２の実施の形態との相違点を中心に説明し、同様の事項については説明を省略する。

第３の実施の形態では、業務システムにおける個々の処理単位にボトルネック候補を検出可能とする。以下、そのための構成について詳細に説明する。
なお、第３の実施の形態の業務システムの全体構成は、図２で示した第２の実施の形態の業務システムの全体構成と同様であるため説明を省略する。ただし、運用管理サーバ１００に代えて運用管理サーバ１００ａを設ける。

また、第３の実施の形態の業務システムに含まれる各装置のハードウェア構成は、図３で示した第２の実施の形態の運用管理サーバ１００のハードウェア構成と同様であるため説明を省略する。

図２２は、第３の実施の形態の運用管理サーバの機能構成を示す図である。運用管理サーバ１００ａは、パケット記憶部１１０、計数情報記憶部１２０ａ、パケット受信部１３０、計数部１４０ａ、ボトルネック検出処理部１５０ａ、報知部１６０および業務モデル記憶部１７０を有する。これらの機能は、所定のプログラムをＣＰＵ１０１が実行することで実現される。なお、これらの機能の少なくとも一部または全部を専用のハードウェアにより実現してもよい。

ここで、パケット記憶部１１０、パケット受信部１３０および報知部１６０は、図４で示した第２の実施の形態の運用管理サーバ１００で同一の符号を付して説明した構成と同一であるため説明を省略する。

計数情報記憶部１２０ａは、計数情報を記憶する。ここで、第２の実施の形態では計数情報をサーバごとに取得した。これに対し、第３の実施の形態では、計数情報を処理単位で取得する。処理単位とは、業務システムにおいて実行される処理の単位を示すものである。例えば、端末装置２１，２２，２３から受け付けたＨＴＴＰリクエストに対してＨＴＴＰレスポンスを応答するまでに各サーバで実行される一連の処理を１単位に定義することができる。なお、以下では、この処理単位を業務モデルと呼ぶこととする。

計数部１４０ａは、パケット記憶部１１０に記憶されたパケット情報に基づいて、各サーバの間で送受信されるメッセージを復元する。計数部１４０ａは、業務モデル記憶部１７０に記憶された業務モデル定義情報を参照して、復元したメッセージを業務モデルに対応付ける。計数部１４０ａは、各業務モデルのメッセージに基づいて、業務モデルごとの各サーバの処理要求滞在数を計数し、計数情報を生成する。計数部１４０ａは、生成した計数情報を計数情報記憶部１２０ａに格納する。

ボトルネック検出処理部１５０ａは、計数情報記憶部１２０ａに記憶された計数情報に基づいて、業務モデルごとの各サーバの処理要求滞在数の頻度分布を解析し、頻度分布が所定の条件を満たすサーバをボトルネック候補として検出する。この条件は、ボトルネック検出処理部１５０が用いる条件１，２と同一である。

ボトルネック検出処理部１５０ａは、検出したボトルネック候補からボトルネックとなり得るサーバを特定して、特定結果を報知部１６０に出力する。
業務モデル記憶部１７０は、業務システムで実行され得る複数の業務モデルを定義した業務モデル定義情報を記憶する。

図２３は、第３の実施の形態の業務モデル定義ファイル群を例示する図である。業務モデル定義ファイル群１７１は、業務モデル記憶部１７０に格納される。業務モデル定義ファイル群１７１は、業務モデルを定義するための情報の集合である。業務モデル定義ファイル群１７１には、メッセージパターン定義ファイル１７１ａおよびエイリアス定義ファイル１７１ｂが含まれる。

メッセージパターン定義ファイル１７１ａは、メッセージの内容と業務モデルとを対応付けるための情報を含む。メッセージパターン定義ファイル１７１ａの内容は、例えばＸＭＬ（Extensible Markup Language）を用いて記述できる。以下、メッセージパターン定義ファイル１７１ａに便宜的に付した行番号を示して説明する。

メッセージパターン定義ファイル１７１ａには、例えばモデルＩＤが“Ｍｏｄｅｌ−３”の業務モデルに関する定義情報が含まれる。メッセージパターン定義ファイル１７１ａによれば、モデルＩＤ“Ｍｏｄｅｌ−３”の業務モデルでは、以下のメッセージを順に取得することが分かる。

（１）Ｗｅｂサーバ２００は、ＨＴＴＰのＰＯＳＴメソッドで“ＰＯＳＴ ／ＣＧＩ−ＢＩＮ／ＡＸＸＰＦ３９４３？＿ＺＩＤ＝ＡＸＸＧ１３１３０”というＵＲＬ（Uniform Resource Locator）を含むＨＴＴＰリクエストを受信する。Ｗｅｂサーバ２００は、このＨＴＴＰリクエストに対するＨＴＴＰレスポンスにステータスコード“２００”を含めてリクエスト元に送信する。この内容は、３〜６行目に対応する。

（２）Ａｐｐサーバ３００は、“ＡＸＸＧ１３１３０／ＩＮＦ／Ｈ０１”というオブジェクトの取得要求を含むＩＩＯＰリクエストをＷｅｂサーバ２００から受信する。Ａｐｐサーバ３００は、このＩＩＯＰリクエストに対するＩＩＯＰレスポンスにステータスを示すコード“０”を含めてＷｅｂサーバ２００に送信する。この内容は、７〜１０行目に対応する。

（３）ＤＢサーバ４００は、クエリとしてエイリアスの識別番号“５，７，１０，１３”で示されるＳＱＬ文を含むＤＢリクエストを順番にＡｐｐサーバ３００から受信する。この内容は、１１〜１４行目に対応する。

ここで、計数部１４０ａは、エイリアスの識別番号で指定されるＳＱＬ文の記述内容を、エイリアス定義ファイル１７１ｂを参照することで取得できる。
エイリアス定義ファイル１７１ｂは、メッセージパターン定義ファイル１７１ａで使用される文字列に対するエイリアスを定義したファイルである。例えば、メッセージパターン定義ファイル１７１ａにおいて、１２行目の“［５，７，１０，１３］”は、それぞれエイリアス定義ファイル１７１ｂの１〜４行目に示されたＳＱＬ文で置換した内容に読み替えることができる。

なお、メッセージパターン定義ファイル１７１ａやエイリアス定義ファイル１７１ｂには、業務モデルとメッセージとの対応付けを行う上で必要となる最低限の判定用文字列（例えば、ＵＲＬやＳＱＬ文の一部）が定義されていればよい。

図２４は、第３の実施の形態の業務メッセージ解析データを例示する図である。業務メッセージ解析データ１７２は、計数部１４０ａにより、復元メッセージ１１１と業務モデル定義ファイル群１７１とに基づいて生成され、業務モデル記憶部１７０に格納される。業務メッセージ解析データ１７２は、計数部１４０ａがパケット記憶部１１０に記憶されたパケット情報から復元した復元メッセージ１１１を業務モデルと対応付けたデータである。

業務メッセージ解析データ１７２には、マッチング結果フィールド１７２ａ，１７２ｂ，１７２ｃが含まれる。マッチング結果フィールド１７２ａ，１７２ｂ，１７２ｃは、業務モデル定義ファイル群１７１に含まれる判定用文字列で復元メッセージ１１１に含まれるメッセージをマッチングし、マッチングに適合したメッセージを抽出して設定するフィールドである。

マッチング結果フィールド１７２ａには、例えばＨＴＴＰリクエストとＨＴＴＰレスポンスとの組の抽出結果が設定される。マッチング結果フィールド１７２ｂには、例えばＩＩＯＰリクエストとＩＩＯＰレスポンスとの組の抽出結果が設定される。マッチング結果フィールド１７２ｃには、例えばＤＢリクエストとＤＢレスポンスとの組の抽出結果が設定される。

計数部１４０ａは、このように業務モデル定義ファイル群１７１に含まれる判定用文字列が復元メッセージ１１１に所定の順番で含まれるか否かによって、該当の業務モデルで定義づけられた処理が行われたか否かを検出することができる。

計数部１４０ａは、業務メッセージ解析データ１７２に基づいて、業務モデルごとのメッセージ管理テーブルを生成し、計数情報記憶部１２０ａに格納する。
図２５は、第３の実施の形態のメッセージ管理テーブルのデータ構造例を示す図である。メッセージ管理テーブル１２１ａ，１２１ｂ，１２１ｃ，・・・は、計数部１４０ａによって業務メッセージ解析データ１７２に基づいて生成され、計数情報記憶部１２０ａに格納される。メッセージ管理テーブル１２１ａ，１２１ｂ，１２１ｃ，・・・は、計数部１４０ａが計数処理を効率的に実行するためのデータである。メッセージ管理テーブル１２１ａ，１２１ｂ，１２１ｃ，・・・は、各業務モデルに対応付けて生成され得る。例えば、メッセージ管理テーブル１２１ａは、モデルＩＤ“Ｍｏｄｅｌ−３”に対応するものである。

なお、メッセージ管理テーブル１２１ａ，１２１ｂ，１２１ｃ，・・・の構成は、図８で示した第２の実施の形態のメッセージ管理テーブル１２１の構成と同様である。
図２６は、第３の実施の形態のカウンタテーブルのデータ構造例を示す図である。カウンタテーブル１２２ａ，１２２ｂ，１２２ｃ，・・・は、計数部１４０ａによってメッセージ管理テーブル１２１ａ，１２１ｂ，１２１ｃ，・・・に基づいて生成され、計数情報記憶部１２０ａに格納される。カウンタテーブル１２２ａ，１２２ｂ，１２２ｃ，・・・は、各業務モデルに対応付けて生成される。例えば、カウンタテーブル１２２ａは、モデルＩＤ“Ｍｏｄｅｌ−３”に対応するものである。

なお、カウンタテーブル１２２ａ，１２２ｂ，１２２ｃ，・・・の構成は、図９で示した第２の実施の形態のカウンタテーブル１２２の構成と同様である。また、カウンタテーブル１２２ａ，１２２ｂ，１２２ｃ，・・・の生成手順は、図９の説明において示した手順１〜３と同様である。

図２７は、第３の実施の形態のカウンタテーブルの変形例を示す図である。カウンタテーブル１２４ａ，１２４ｂ，１２４ｃ，・・・は、計数部１４０ａによってメッセージ管理テーブル１２１ａ，１２１ｂ，１２１ｃ，・・・に基づいて生成され、計数情報記憶部１２０ａに格納される。カウンタテーブル１２４ａ，１２４ｂ，１２４ｃ，・・・は、各業務モデルに対応付けて生成される。例えば、カウンタテーブル１２４ａは、モデルＩＤ“Ｍｏｄｅｌ−３”に対応するものである。

なお、カウンタテーブル１２４ａ，１２４ｂ，１２４ｃ，・・・の構成は、図９で示した第２の実施の形態のカウンタテーブル１２２の構成と同様である。ただし、カウンタテーブル１２４ａ，１２４ｂ，１２４ｃ，・・・の生成手順は、図９の説明において示した手順３につき以下の点で異なる。

すなわち、計数部１４０ａは、上位の階層のサーバと下位の階層のサーバとの間のリクエスト／レスポンスの送受信の後に、同じサーバ間で同じセッション番号を用いて複数回リクエスト／レスポンスの送受信がなされている一連のメッセージフローを抽出する。図２４に示す業務メッセージ解析データ１７２では、例えばマッチング結果フィールド１７２ｃの一連のメッセージフロー（セッション番号“１３１２６８”を使用）が対応する。そして、その一連のメッセージフローの送受信については、メッセージフローの最初のリクエストの送信タイミングで処理要求滞在数を１加算し、メッセージフローの最後のレスポンスの送信タイミングで処理要求滞在数を１減算する。すなわち、１つのメッセージフローの間は、そのメッセージフローに基づく処理要求が下位側のサーバに常に滞在しているとする。

その結果、カウンタテーブル１２４ａに示すように、計数部１４０ａは例えば時刻“０１：５８：２１．０００”の時点のＷｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００における処理要求滞在数として“１”、“１”、“１”を取得する。

この結果をカウンタテーブル１２２ａの場合と比較する。カウンタテーブル１２２ａの場合では、計数部１４０ａは時刻“０１：５８：２１．０００”の時点のＷｅｂサーバ２００、Ａｐｐサーバ３００およびＤＢサーバ４００における処理要求滞在数として“１”、“１”、“０”を取得する。

カウンタテーブル１２２ａのように計数を行う場合、例えば、一連の連続したメッセージ送受信の間中に継続して占有され続けるリソース（例えば、ＤＢサーバ４００に対するコネクションやＤＢサーバ４００において利用されるＤＢカーソルなど）が関わる処理要求滞在数を適切にカウントできない可能性がある。すなわち、サンプリングのタイミングによっては、そのようなリソースの占有を伴う処理を反映した処理要求滞在数が欠落してしまう。これに対し、リソースが占有され続けている間は、該当のサーバにおいてその処理要求が滞在し続けているとした方が、実際の処理要求滞在数により適合する場合もある。

そのような場合には、上述した方法によって、同一セッションで送受信される一連のメッセージフローを検出することで、サンプリングのタイミングによる処理要求滞在数の欠落を防止できる。

図２８は、第３の実施の形態の処理要求滞在数テーブルのデータ構造例を示す図である。処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃは、計数部１４０ａによってカウンタテーブル１２２ａ，１２２ｂ，１２２ｃ，・・・に基づいて生成され、計数情報記憶部１２０ａに格納される。処理要求滞在数テーブル１２３ａは、Ｗｅｂサーバ２００に対応する。処理要求滞在数テーブル１２３ｂは、Ａｐｐサーバ３００に対応する。処理要求滞在数テーブル１２３ｃは、ＤＢサーバ４００に対応する。以下では、処理要求滞在数テーブル１２３ａの構成に関して説明するが、処理要求滞在数テーブル１２３ｂ，１２３ｃに関しても同様の構成である。

処理要求滞在数テーブル１２３ａには、モデルＩＤを示す項目、処理要求滞在数を示す項目および平均を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つの業務モデルの各時刻における処理要求滞在数を示す。

モデルＩＤを示す項目には、モデルＩＤが設定される。処理要求滞在数を示す項目には、各時刻における処理要求滞在数が設定される。平均を示す項目には、ボトルネック解析周期の間の処理要求滞在数の平均値が設定される。

処理要求滞在数テーブル１２３ａには、例えばモデルＩＤが“Ｍｏｄｅｌ−１”、処理要求滞在数が時刻“１：５８：２０”に“５”、時刻“１：５８：２１”に“６”、・・・、平均が“５．８１”という情報が設定される。このレコードに含まれる処理要求滞在数の値は、カウンタテーブル１２２ａ，１２２ｂ，１２２ｃ，・・・の“Ｍｏｄｅｌ−１”のテーブルから対応する時刻に設定されたＷｅｂサーバ２００用のカウンタ値（処理要求滞在数）を取得して得たものである。

次に、以上のような構成を備える運用管理サーバ１００ａの処理手順を詳細に説明する。ここで、パケットキャプチャ処理に関しては、図１３で示した第２の実施の形態のパケットキャプチャ処理と同一であるため説明を省略する。また、監視処理に関しては、図１４で示した第２の実施の形態の監視処理と同一であるため説明を省略する。

図２９は、第３の実施の形態のボトルネック検出処理を示すフローチャートである。以下、図２９に示す処理をステップ番号に沿って説明する。
［ステップＳ５１］ボトルネック検出処理部１５０ａは、業務システムの階層単位に以降のステップＳ６０までの処理を繰り返し実行する。なお、本実施の形態では、各階層にサーバは１台ずつであるので、サーバごとに順次実行すればよい。

［ステップＳ５２］ボトルネック検出処理部１５０ａは、業務モデルごとに以降のステップＳ５９までの処理を繰り返し実行する。
［ステップＳ５３］ボトルネック検出処理部１５０ａは、計数情報記憶部１２０ａに記憶された処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃに基づいて、処理対象の業務モデルにつき対象サーバの処理要求滞在数の頻度分布を取得する。

［ステップＳ５４］ボトルネック検出処理部１５０ａは、取得した頻度分布における処理要求滞在数の最大値を特定する。
［ステップＳ５５］ボトルネック検出処理部１５０ａは、頻度分布における処理要求滞在数の最大値近傍の集中度を算出する。

［ステップＳ５６］ボトルネック検出処理部１５０ａは、集中度が閾値以上であるか否かを判定する。閾値以上である場合、処理をステップＳ５７に進める。閾値よりも小さい場合、処理をステップＳ５９に進める。

［ステップＳ５７］ボトルネック検出処理部１５０ａは、頻度分布が正規分布であるか否かを判定する。正規分布でない場合、処理をステップＳ５８に進める。正規分布である場合、処理をステップＳ５９に進める。

［ステップＳ５８］ボトルネック検出処理部１５０ａは、処理対象の業務モデルにつき対象サーバをボトルネック候補として追加する。
［ステップＳ５９］ボトルネック検出処理部１５０ａは、全業務モデルについて処理済みであれば、処理をステップＳ６０に進める。未処理の業務モデルが存在する場合、処理をステップＳ５２に進める。

［ステップＳ６０］ボトルネック検出処理部１５０ａは、全階層（サーバ）について処理済みであれば、処理をステップＳ６１に進める。未処理の階層（サーバ）が存在する場合、処理をステップＳ５１に進める。

［ステップＳ６１］ボトルネック検出処理部１５０ａは、ステップＳ５１〜Ｓ６０の処理でボトルネック候補を検出しているか否かを判定する。検出している場合、処理をステップＳ６２に進める。検出していない場合、処理を完了する。

［ステップＳ６２］ボトルネック検出処理部１５０ａは、業務モデルごとにボトルネック候補が複数検出されたか否かを判定する。複数ボトルネックが存在する業務モデルがある場合、処理をステップＳ６３に進める。複数ボトルネックが存在する業務モデルがない場合、処理をステップＳ６４に進める。

［ステップＳ６３］ボトルネック検出処理部１５０ａは、業務モデルごとに複数のボトルネック候補のうち、最下位の階層のサーバをボトルネックと特定する。例えば、業務モデル“Ｍｏｄｅｌ−３”についてボトルネック候補としてＡｐｐサーバ３００およびＤＢサーバ４００が検出されている場合、ＤＢサーバ４００を業務モデル“Ｍｏｄｅｌ−３”のボトルネックと特定する。ボトルネック検出処理部１５０ａは、特定したボトルネックのサーバを示す情報を業務モデルに対応付けて報知部１６０に出力する。

［ステップＳ６４］報知部１６０は、ボトルネック検出処理部１５０ａから取得したボトルネックのサーバを示す情報を業務モデルごとに管理者に報知する。
このようにして、ボトルネック検出処理部１５０ａはボトルネックのサーバを業務モデルごとに検出する。なお、各階層に複数のサーバが設けられている場合には、第２の実施の形態と同様に、何れの階層がボトルネックとなっているかを検出することができる。例えば、Ｗｅｂ層にＷｅｂサーバが複数台設けられている場合には、計数部１４０ａは各Ｗｅｂサーバの処理要求滞在数の総和をＷｅｂ層における処理要求滞在数として求めることができる。これにより、処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃの処理要求滞在数を示す項目の値をＷｅｂサーバ、ＡｐｐサーバおよびＤＢサーバ単位での値に代えて、Ｗｅｂ層、Ａｐｐ層およびＤＢ層の階層単位の値として取得できる。そして、ボトルネック検出処理部１５０ａは、このように階層単位に取得された処理要求滞在数テーブルに基づき上記ボトルネック検出処理を実行することで、ボトルネックとなっている階層を特定できる。

更に、報知部１６０は、業務モデル単位にボトルネック検出処理部１５０ａが検出したボトルネックを報知することができる。
例えば、処理要求滞在数の制限は業務モデルごとに設定される場合が考えられる。その場合、報知部１６０はボトルネックとして検出されたサーバの識別情報を業務モデルごとに対応付けて報知する。例えば、ボトルネック検出処理部１５０ａにより、“Ｍｏｄｅｌ−１”、“Ｍｏｄｅｌ−５”についてＡｐｐサーバ３００がボトルネックとして検出され、“Ｍｏｄｅｌ−３”についてＤＢサーバ４００がボトルネックとして検出された場合を考える。この場合、報知部１６０は、“Ｍｏｄｅｌ−１”のボトルネック検出結果として、Ａｐｐサーバ３００を報知する。また、“Ｍｏｄｅｌ−５”のボトルネック検出結果として、Ａｐｐサーバ３００を報知する。更に、“Ｍｏｄｅｌ−３”のボトルネック検出結果として、ＤＢサーバ４００を報知する。

また、例えば、処理要求滞在数の制限は複数の業務モデルの合計として設定される場合が考えられる。その場合、報知部１６０は平均に設定された値が大きな業務モデルを優先して報知することができる。例えば、“Ｍｏｄｅｌ−１”〜“Ｍｏｄｅｌ−７”の合計の処理要求滞在数が制限されている場合、その中でも平均の処理要求滞在数が大きいものを優先して報知する。具体的には、処理要求滞在数テーブル１２３ａの例では、“Ｍｏｄｅｌ−６”の処理要求滞在数の平均が最大である。したがって、報知部１６０は、これらの業務モデルでＷｅｂサーバ２００にボトルネックを検出した場合、“Ｍｏｄｅｌ−６”に対する注意を特に促すように管理者に報知することができる。

これにより、第２の実施の形態の運用管理サーバ１００よりも対象を絞ったボトルネック検出が可能となる。すなわち、問題の特定を一層容易にすることができる。その結果、管理者は問題に対する対策をより効率的に行うことができる。

［第４の実施の形態］
以下、第４の実施の形態について説明する。前述の第２，３の実施の形態との相違点を中心に説明し、同様の事項については説明を省略する。

第４の実施の形態では、複数の業務モデルに対するリクエストの組合せに関連して発生するボトルネックの検出を可能とする。例えば、Ａｐｐサーバ３００において、複数の業務モデルが共通して使用するプログラムが存在する場合、当プログラムが複数のリクエストに適切に対応できない設計であればボトルネックとなり得る。また、例えば、複数の業務モデルが発行するＤＢサーバ４００に対するクエリに問題があってボトルネックが発生することも考えられる。このように、複数の業務モデルとボトルネックとを関連付けて検出可能とすることで、共通するあるいは関連の深い問題点を抱えると想定される複数の業務モデルを一度に特定できる。以下、そのための構成について詳細に説明する。

なお、第４の実施の形態の業務システムの全体構成は、図２で示した第２の実施の形態の業務システムの全体構成と同様であるため説明を省略する。ただし、運用管理サーバ１００に代えて運用管理サーバ１００ｂを設ける。

また、第４の実施の形態の業務システムに含まれる各装置のハードウェア構成は、図３で示した第２の実施の形態の運用管理サーバ１００のハードウェア構成と同様であるため説明を省略する。

図３０は、第４の実施の形態の運用管理サーバの機能構成を示す図である。運用管理サーバ１００ｂは、パケット記憶部１１０、計数情報記憶部１２０ｂ、パケット受信部１３０、計数部１４０ａ、ボトルネック検出処理部１５０ｂ、報知部１６０、業務モデル記憶部１７０および検査モデル選択処理部１８０を有する。これらの機能は、所定のプログラムをＣＰＵ１０１が実行することで実現される。なお、これらの機能の少なくとも一部または全部を専用のハードウェアにより実現してもよい。

ここで、パケット記憶部１１０、パケット受信部１３０および報知部１６０は、図４で示した第２の実施の形態の運用管理サーバ１００で同一の符号を付して説明した構成と同一であるため説明を省略する。また、計数部１４０ａおよび業務モデル記憶部１７０は、図２２で示した第３の実施の形態の運用管理サーバ１００ａで同一の符号を付して説明した構成と同一であるため説明を省略する。

計数情報記憶部１２０ｂは、業務モデルごとの計数情報を記憶する。業務モデルごとの計数情報とは、前述の第３の実施の形態の計数情報記憶部１２０ａが記憶する情報と同一である。また、計数情報記憶部１２０ｂは、複数の業務モデルの関連を示す情報を記憶する。

ボトルネック検出処理部１５０ｂは、検査モデル選択処理部１８０が選択した業務モデルの組合せを取得する。ボトルネック検出処理部１５０ｂは、計数情報記憶部１２０ｂに記憶された計数情報を参照し、取得した業務モデルの組合せに基づいて、ボトルネックの検出処理を行う。具体的には、ボトルネック検出処理部１５０ｂは、業務モデルの組合せごとの各サーバの処理要求滞在数の頻度分布を解析し、頻度分布が所定の条件を満たすサーバをボトルネック候補として検出する。この条件は、第２の実施の形態のボトルネック検出処理部１５０が用いる条件１，２と同一である。なお、業務モデルの組合せごとの処理要求滞在数は、例えば、組合せに含まれる業務モデルごとの処理要求滞在数の合計によって求めることができる。

ボトルネック検出処理部１５０ｂは、検出したボトルネック候補からボトルネックとなり得るサーバを特定して、特定結果を報知部１６０に出力する。
検査モデル選択処理部１８０は、計数情報記憶部１２０ｂに記憶された計数情報に基づいて、ボトルネック検出処理部１５０ｂが検出処理を行うべき業務モデルの組合せを選択する。

ここで、業務モデルが複数存在する場合に、業務モデルの組合せを多数作ることができる。しかし、全ての組合せについてボトルネック検出処理を行うことは、処理量の観点からは妥当ではない。よって、検査モデル選択処理部１８０により、ボトルネック検出処理部１５０ｂが処理対象とする組合せを予め絞り込むことで、処理負荷を軽減しておくことが好ましい。

ただし、検査モデル選択処理部１８０の機能を用いずに、全ての業務モデルの組合せをボトルネック検出処理部１５０ｂの処理対象としてもよい。
ここで、検査モデル選択処理部１８０は、例えば、業務モデルの組合せの中で、同じプログラムを利用している等の共通項を知識情報として予め取得する。そして、これらをボトルネック検出処理の対象としてボトルネック検出処理部１５０ｂに出力することが考えられる。

また、検査モデル選択処理部１８０にそのような知識情報を設定することなく、得られた処理要求滞在数の時系列推移から業務モデル間の関連を抽出することもできる。具体的には、検査モデル選択処理部１８０は、ボトルネック検出処理部１５０ｂの前処理として、計数情報記憶部１２０ｂに記憶された処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃに基づく業務モデルごとの時系列推移をフーリエ解析する。検査モデル選択処理部１８０は、フーリエ解析の結果として得られた業務モデルごとの各周期（周波数）成分に基づいて業務モデル間の関連性を抽出できる。検査モデル選択処理部１８０は、その結果に基づいてボトルネック検出処理部１５０ｂが処理対象とすべき業務モデルの組合せを絞り込むことができる。

以下では、このようにフーリエ解析によって業務モデルの組合せを選択する際に、検査モデル選択処理部１８０が生成するデータについて説明する。
図３１は、業務モデルごとの処理要求滞在数の時系列推移を例示する図である。時系列推移５４０は、Ｗｅｂサーバ２００の業務モデルごとの時系列推移を示している。時系列推移５４０には、系列５４１，５４２，５４３，５４４，５４５，５４６，５４７が示されている。系列５４１は、業務モデル“Ｍｏｄｅｌ−１”に対応する。系列５４２は、業務モデル“Ｍｏｄｅｌ−２”に対応する。系列５４３は、業務モデル“Ｍｏｄｅｌ−３”に対応する。系列５４４は、業務モデル“Ｍｏｄｅｌ−４”に対応する。系列５４５は、業務モデル“Ｍｏｄｅｌ−５”に対応する。系列５４６は、業務モデル“Ｍｏｄｅｌ−６”に対応する。系列５４７は、業務モデル“Ｍｏｄｅｌ−７”に対応する。

検査モデル選択処理部１８０は、時系列推移５４０の系列５４１，５４２，５４３，５４４，５４５，５４６，５４７それぞれをフーリエ解析して、各系列に含まれる複数の周期成分を抽出する。

図３２は、第４の実施の形態のフーリエ解析結果テーブルのデータ構造例を示す図である。フーリエ解析結果テーブル１２５ａ，１２５ｂ，１２５ｃは、検査モデル選択処理部１８０によって生成され、計数情報記憶部１２０ｂに格納される。フーリエ解析結果テーブル１２５ａは、Ｗｅｂサーバ２００に対応する。フーリエ解析結果テーブル１２５ｂは、Ａｐｐサーバ３００に対応する。フーリエ解析結果テーブル１２５ｃは、ＤＢサーバ４００に対応する。以下では、フーリエ解析結果テーブル１２５ａの構成に関して説明するが、フーリエ解析結果テーブル１２５ｂ，１２５ｃに関しても同様の構成である。

フーリエ解析結果テーブル１２５ａには、モデルＩＤを示す項目および周期成分を示す項目が設けられている。各項目の横方向に並べられた情報同士が関連付けられて、１つのモデルの各周期成分を示す。

モデルＩＤを示す項目には、業務モデルのモデルＩＤが設定される。周期成分を示す項目には、各周期の成分が設定される。
フーリエ解析結果テーブル１２５ａには、例えば、フーリエ解析によって周期１６，８，５．３３３，４の成分が求められる。なお、処理に用いる周期成分の数によっては、更に複数の周期成分を求めてもよい。

具体的には、フーリエ解析結果テーブル１２５ａには、モデルＩＤが“Ｍｏｄｅｌ−１”、周期１６の成分が“−７．１５９＋２．２０５ｉ”、周期８の成分が“４．２４３＋６．６５７ｉ”、・・・という情報が設定される。

検査モデル選択処理部１８０は、フーリエ解析結果テーブル１２５ａで求めた業務モデルごとの各周期成分を用いて、業務モデルの組合せごとに各周期成分の合計振幅を求める。例えば、２つの業務モデルの組合せをボトルネックの検出対象とする場合には、２つの業務モデルについて、同じ周期成分同士の合成振幅を求める。具体的には、“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との周期１６の成分同士の合成振幅を求める。また、“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との周期８の成分同士の合成振幅を求める。このようにして、業務モデルの全ての組合せについて同一周期成分同士の合成振幅を求める。

図３３は、第４の実施の形態の合成振幅テーブルを例示する第１の図である。合成振幅テーブル１２６ａ，１２６ｂ，１２６ｃは、２つの業務モデルの組合せごとに周期１６の成分の合成振幅の算出結果を示している。合成振幅テーブル１２６ａは、Ｗｅｂサーバ２００に対応する。合成振幅テーブル１２６ｂは、Ａｐｐサーバ３００に対応する。合成振幅テーブル１２６ｃは、ＤＢサーバ４００に対応する。以下では、合成振幅テーブル１２６ａの構成に関して説明するが、合成振幅テーブル１２６ｂ，１２６ｃに関しても同様の構成である。

合成振幅テーブル１２６ａには、モデルＩＤを示す項目および合成振幅を示す項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つの業務モデルの組合せにおける合成振幅を示す。

モデルＩＤを示す項目には、業務モデルのモデルＩＤが設定される。合成振幅を示す項目には、対応する業務モデル同士の周期１６の成分の合成振幅が設定される。
合成振幅テーブル１２６ａには、例えば、モデルＩＤ“Ｍｏｄｅｌ−１”および“Ｍｏｄｅｌ−２”の業務モデルの組合せに対して、周期１６の成分の合成振幅が“１．５５６”という情報が設定される。この合成振幅は、具体的には、フーリエ解析結果テーブル１２５ａに基づいて各周期成分の合成“（−７．１５９＋８．２１７）＋（２．２０５−１．０６４）ｉ＝１．０５８＋１．１４１ｉ”の振幅として求めることができる。

他の合成振幅に関しても同様である。
図３４は、第４の実施の形態の合成振幅テーブルを例示する第２の図である。合成振幅テーブル１２７ａ，１２７ｂ，１２７ｃは、２つの業務モデルの組合せごとに周期８の成分の合成振幅の算出結果を示している。合成振幅テーブル１２７ａは、Ｗｅｂサーバ２００に対応する。合成振幅テーブル１２７ｂは、Ａｐｐサーバ３００に対応する。合成振幅テーブル１２７ｃは、ＤＢサーバ４００に対応する。

なお、合成振幅テーブル１２７ａ，１２７ｂ，１２７ｃの構成は、合成振幅テーブル１２６ａの構成と同一であるため説明を省略する。
検査モデル選択処理部１８０は、各合成振幅テーブルから合成振幅の値が所定の閾値以上となっていない組合せを特定する。閾値は、検査モデル選択処理部１８０に予め設定されていてもよいし、処理要求滞在数の測定結果から適宜求めてもよい。例えば、複数の業務モデルのうち、処理要求滞在数の平均値が大きいものから組合せの数（例えば、業務モデルを２つ組み合わせる場合には２つ）だけ合計した数に所定の閾値率を乗算して、このような閾値を求めることができる。

そして、所定の閾値以上となっていない組合せとして特定した組合せをボトルネックの検出処理の対象として選択する。例えば、合成振幅テーブル１２６ａ〜１２７ｃでは、閾値が“３”であれば、周期１６の合成振幅および周期８の合成振幅の何れもが３より小さい“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との組合せを選択する。

このように、検査モデル選択処理部１８０は、業務モデルごとの時系列推移をフーリエ解析し、業務モデルの組合せごとの合成振幅を比較する。このような比較を行う理由は、ボトルネック検出処理部１５０ｂがボトルネックとして検出する場合、処理要求滞在数の時系列推移がほぼ一定となっているものが検出されるためである。時系列推移がほぼ一定となる場合には、フーリエ解析した周期成分の振幅は小さくなると考えられる。よって、業務モデルごとに求めた周期成分を合成して、周期成分の振幅が小さいものが得られれば、その業務モデルの組合せでボトルネックが発生し得ると考えることができる。

これにより、処理要求滞在数が一定値前後に集中することが予想される業務モデルの組合せを低コストで選択することができる。
なお、２つ組み合わせる場合を例示したが、３つ以上の業務モデルの組合せで選択する場合も、それらの業務モデルの同一周期成分の和に基づいて選択することができる。

また、周期１６および周期８の成分の合成振幅によって判定を行う場合を例示したが、更に複数の周期成分の合成振幅を求めて判定に用いることもできる。
次に、以上のような構成を備える運用管理サーバ１００ｂの処理手順を詳細に説明する。ここで、パケットキャプチャ処理に関しては、図１３で示した第２の実施の形態のパケットキャプチャ処理と同一であるため説明を省略する。

図３５は、第４の実施の形態の監視処理を示すフローチャートである。以下、図３５に示す処理をステップ番号に沿って説明する。
［ステップＳ７１］計数部１４０ａは、パケット受信部１３０がパケット記憶部１１０にファイルを出力したかの監視を開始する。なお、計数部１４０ａが開始コマンドおよび停止コマンドを受け付けるタイミングは、図１４のステップＳ２１の場合と同様である。

［ステップＳ７２］計数部１４０ａは、パケット記憶部１１０に新たなファイルが出力されると、そのファイルを読み取る。
［ステップＳ７３］計数部１４０ａは、読み取ったファイルに基づいて各サーバで送受信されたメッセージを復元する。

［ステップＳ７４］計数部１４０ａは、復元したメッセージに基づいて業務モデルごとのメッセージ管理テーブル１２１ａ，１２１ｂ，１２１ｃ，・・・を生成し、計数情報記憶部１２０ｂに格納する。計数部１４０ａは、メッセージ管理テーブル１２１ａ，１２１ｂ，１２１ｃ，・・・に基づいてカウンタテーブル１２２ａ，１２２ｂ，１２２ｃ，・・・を生成し、計数情報記憶部１２０ｂに格納する。計数部１４０ａは、カウンタテーブル１２２ａ，１２２ｂ，１２２ｃ，・・・に基づいて、処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃを生成して、計数情報記憶部１２０ｂに格納する。

［ステップＳ７５］検査モデル選択処理部１８０は、計数情報記憶部１２０ｂに記憶された処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃに基づいて、ボトルネック検出処理部１５０ｂが処理すべき業務モデルの組合せを選択する。検査モデル選択処理部１８０は、業務モデルの組合せの選択結果をボトルネック検出処理部１５０ｂに出力する。

［ステップＳ７６］ボトルネック検出処理部１５０ｂは、処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃと検査モデル選択処理部１８０による業務モデルの組合せの選択結果とに基づいて、各サーバにおける業務モデルの組合せごとの処理要求滞在数の頻度分布を求める。そして、ボトルネック検出処理部１５０ｂは、各サーバの業務モデルごとに求めた分布が所定の条件を満たしているかを判定して、条件を満たすサーバをその業務モデルにおけるボトルネック候補として検出する。ボトルネック検出処理部１５０ｂは、ボトルネック候補からボトルネックとなり得るサーバを特定して、特定結果を報知部１６０に出力する。報知部１６０は、ボトルネック検出処理部１５０ｂから取得したサーバを示す情報を業務システムの管理者に報知する。

［ステップＳ７７］計数部１４０ａは、停止コマンドを受け付けるとファイル出力の監視を停止する。これにより、ボトルネック発生の有無の監視処理が完了する。
このように、計数部１４０ａは、パケット受信部１３０のパケットキャプチャによって、パケット記憶部１１０に新たなファイルが出力されると、計数処理を実行する。そして、ボトルネック検出処理部１５０ｂは、計数部１４０ａによって計数情報記憶部１２０ｂに出力された処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃと検査モデル選択処理部１８０による業務モデルの組合せの選択結果とに基づいて、ボトルネック検出処理を実行する。

次に、ステップＳ７５のボトルネック検出対象選択処理を詳細に説明する。
図３６は、第４の実施の形態のボトルネック検出対象選択処理を示すフローチャートである。以下、図３６に示す処理をステップ番号に沿って説明する。

［ステップＳ８１］検査モデル選択処理部１８０は、業務システムの階層単位に以降のステップＳ９８までの処理を繰り返し実行する。なお、本実施の形態では、各階層にサーバは１台ずつであるので、サーバごとに順次実行すればよい。

［ステップＳ８２］検査モデル選択処理部１８０は、業務モデルごとに以降のステップＳ８５までの処理を繰り返し実行する。
［ステップＳ８３］検査モデル選択処理部１８０は、対象の業務モデルにつき処理対象のサーバのボトルネック解析周期の間の処理要求滞在数の平均値を取得する。例えば、検査モデル選択処理部１８０は、処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃを参照して、この平均値を取得できる。

［ステップＳ８４］検査モデル選択処理部１８０は、対象の業務モデルにつき処理対象のサーバの処理要求滞在数の時系列推移をフーリエ解析する。その結果、検査モデル選択処理部１８０は、時系列推移の系列に含まれる複数の周期成分を示すフーリエ解析結果テーブル１２５ａ，１２５ｂ，１２５ｃを生成し、計数情報記憶部１２０ｂに格納する。

［ステップＳ８５］検査モデル選択処理部１８０は、全業務モデルについて処理済みであれば、処理をステップＳ８６に進める。未処理の業務モデルが存在する場合、処理をステップＳ８２に進める。

［ステップＳ８６］検査モデル選択処理部１８０は、業務モデルを組み合わせる組合せ数ごとに以降のステップＳ９７までの処理を繰り返し実行する。なお、業務モデルの組合せ数は、検査モデル選択処理部１８０に予め設定される。例えば、２つの業務モデルの組合せによって発生するボトルネックを検出したい場合、組合せ数“２”が設定される。また、例えば、３つの業務モデルの組合せによって発生するボトルネックを検出したい場合、組合せ数“３”が設定される。

［ステップＳ８７］検査モデル選択処理部１８０は、業務モデルの組合せ数ｍを取得する。検証する組合せ数が複数存在する場合、複数の値のうち小さい方から処理を行ってもよいし、大きい方から処理を行ってもよい。

［ステップＳ８８］検査モデル選択処理部１８０は、業務モデルのうち、処理要求滞在数の平均値の大きい方からｍ個の和Ｍを算出する。例えば、ｍ＝２とする。この場合、検査モデル選択処理部１８０は、例えば処理要求滞在数テーブル１２３ａについて業務モデル“Ｍｏｄｅｌ−５”と“Ｍｏｄｅｌ−６”との平均の和としてＭ＝１３．８８＋２０．００＝３３．８８を算出する。

［ステップＳ８９］検査モデル選択処理部１８０は、Ｍに所定の閾値率ｑ（ｑ＜１）を乗じて、閾値Ｅ＝ｑＭを算出する。ここで、閾値率ｑは業務システムの処理に応じて決定する。閾値率ｑとして、例えば０．１が予め設定される。Ｍ＝３３．８８が算出されている場合、検査モデル選択処理部１８０はＥ＝０．１×３３．８８＝３．８９を算出する。

［ステップＳ９０］検査モデル選択処理部１８０は、複数の業務モデルにつき組合せ数ｍである組合せごとに以降のステップＳ９６までの処理を繰り返し実行する。
［ステップＳ９１］検査モデル選択処理部１８０は、処理対象とする組合せのうち、最長周期の成分を合成し、合成振幅Ａ１を算出する。例えば、Ｗｅｂサーバ２００について、ｍ＝２で“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との組合せが処理対象となっている場合を考える。この場合、検査モデル選択処理部１８０は、計数情報記憶部１２０ｂに記憶されたフーリエ解析結果テーブル１２５ａを参照し、“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との周期１６の成分の合成振幅Ａ１＝１．５５６を求める。

［ステップＳ９２］検査モデル選択処理部１８０は、合成振幅Ａ１が閾値Ｅよりも小さいか否かを判定する。Ａ１がＥよりも小さい場合、処理をステップＳ９３に進める。Ａ１がＥ以上である場合、処理をステップＳ９６に進める。

［ステップＳ９３］検査モデル選択処理部１８０は、処理対象とする組合せのうち、２番目に長い周期の成分を合成し、合成振幅Ａ２を算出する。例えば、Ｗｅｂサーバ２００について、ｍ＝２で“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との組合せが処理対象となっている場合を考える。この場合、検査モデル選択処理部１８０は、計数情報記憶部１２０ｂに記憶されたフーリエ解析結果テーブル１２５ａを参照し、“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との周期８の成分の合成振幅Ａ２＝２．０８４を求める。

［ステップＳ９４］検査モデル選択処理部１８０は、合成振幅Ａ２が閾値Ｅよりも小さいか否かを判定する。Ａ２がＥよりも小さい場合、処理をステップＳ９５に進める。Ａ２がＥ以上である場合、処理をステップＳ９６に進める。

［ステップＳ９５］検査モデル選択処理部１８０は、処理対象としている業務モデルの組合せを処理の対象としてボトルネック検出処理部１５０ｂに出力する。
［ステップＳ９６］検査モデル選択処理部１８０は、業務モデルの全組合せについて処理済みであれば、処理をステップＳ９７に進める。未処理の組合せが存在する場合、処理をステップＳ９０に進める。

［ステップＳ９７］検査モデル選択処理部１８０は、全組合せ数について処理済みであれば、処理をステップＳ９８に進める。未処理の組合せ数が存在する場合、処理をステップＳ８６に進める。

［ステップＳ９８］検査モデル選択処理部１８０は、全階層（サーバ）について処理済みであれば、処理を完了する。未処理の階層（サーバ）が存在する場合、処理をステップＳ８１に進める。

このように、検査モデル選択処理部１８０は、ボトルネック検出処理部１５０ｂが処理対象とすべき複数の業務モデルの組合せを予め選択する。ボトルネック検出処理部１５０ｂは予め選択された組合せについてボトルネック検出処理を行えばよい。よって、全ての組合せについてボトルネック検出処理を行う場合に比べて、処理コストを低減できる。

また、検査モデル選択処理部１８０は、業務モデルごとの処理要求滞在数の時系列推移をフーリエ解析し、各周期成分の合成振幅によりボトルネックとなり得る業務モデルの組合せを選択する。これにより、処理要求滞在数が一定値前後に集中することが予想される業務モデルの組合せを低コストで取得することができる。

なお、ステップＳ８８，Ｓ８９において、閾値Ｅを処理要求滞在数の平均値の上位ｍ個の合計から求めている理由は、任意のｍ個の業務モデルについて、それらの処理要求滞在数の合計は、最大でも平均値の上位ｍ個の合計数程度である場合が多いためである。

また、検査モデル選択処理部１８０はこの合計数の一定割合（閾値率ｑ＝０．１程度）を合計振幅の閾値としている。このとき、合成振幅が閾値以上となる組合せでは、合計の処理要求滞在数の時系列推移が閾値率（例えば、１０％）の変動幅に収まっていないと考えられる。このため、ボトルネック検出処理部１５０ｂが処理対象としても、処理要求滞在数の最大値直前への集中度が大きくなる可能性が低い。よって、ボトルネック候補として検出される可能性が低いと判断できるので、ボトルネック検出処理の対象から除外できる。

一方、合成振幅が閾値よりも小さい組合せでは、合計の処理要求滞在数の時系列推移が閾値率の変動幅に収まることになる。このため、ボトルネック検出処理部１５０ｂの処理において、処理要求滞在数の最大値直前への集中度が大きくなる可能性が高く、ボトルネック候補として検出される可能性が高いと判断できる。よって、このような組合せをボトルネック検出処理の対象として選択できる。

図３７は、第４の実施の形態のボトルネック検出処理を示すフローチャートである。以下、図３７に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］ボトルネック検出処理部１５０ｂは、業務システムの階層単位に以降のステップＳ１１０までの処理を繰り返し実行する。なお、本実施の形態では、各階層にサーバは１台ずつであるので、サーバごとに順次実行すればよい。

［ステップＳ１０２］ボトルネック検出処理部１５０ｂは、検査モデル選択処理部１８０から取得した処理対象の業務モデルの組合せごとに以降のステップＳ１０９までの処理を繰り返し実行する。

［ステップＳ１０３］ボトルネック検出処理部１５０ｂは、計数情報記憶部１２０ｂに記憶された処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃに基づいて、処理対象の業務モデルの組合せにつき対象サーバにおける処理要求滞在数の同一サンプリング時刻ごとの和をとった合成処理要求滞在数（以下、単に処理要求滞在数という）の頻度分布を取得する。

［ステップＳ１０４］ボトルネック検出処理部１５０ｂは、取得した頻度分布における処理要求滞在数の最大値を特定する。
［ステップＳ１０５］ボトルネック検出処理部１５０ｂは、頻度分布における処理要求滞在数の最大値近傍の集中度を算出する。

［ステップＳ１０６］ボトルネック検出処理部１５０ｂは、集中度が閾値以上であるか否かを判定する。閾値以上である場合、処理をステップＳ１０７に進める。閾値よりも小さい場合、処理をステップＳ１０９に進める。

［ステップＳ１０７］ボトルネック検出処理部１５０ｂは、頻度分布が正規分布であるか否かを判定する。正規分布でない場合、処理をステップＳ１０８に進める。正規分布である場合、処理をステップＳ１０９に進める。

［ステップＳ１０８］ボトルネック検出処理部１５０ｂは、処理対象の業務モデルの組合せにつき対象サーバをボトルネック候補として追加する。
［ステップＳ１０９］ボトルネック検出処理部１５０ｂは、検査モデル選択処理部１８０から取得した業務モデルの全組合せについて処理済みであれば、処理をステップＳ１１０に進める。未処理の業務モデルの組合せが存在する場合、処理をステップＳ１０２に進める。

［ステップＳ１１０］ボトルネック検出処理部１５０ｂは、全階層（サーバ）について処理済みであれば、処理をステップＳ１１１に進める。未処理の階層（サーバ）が存在する場合、処理をステップＳ１０１に進める。

［ステップＳ１１１］ボトルネック検出処理部１５０ｂは、ステップＳ１０１〜Ｓ１１０の処理でボトルネック候補を検出しているか否かを判定する。検出している場合、処理をステップＳ１１２に進める。検出していない場合、処理を完了する。

［ステップＳ１１２］ボトルネック検出処理部１５０ｂは、業務モデルの組合せごとにボトルネック候補が複数検出されたか否かを判定する。複数ボトルネックが存在する業務モデルの組合せがある場合、処理をステップＳ１１３に進める。複数ボトルネックが存在する業務モデルの組合せがない場合、処理をステップＳ１１４に進める。

［ステップＳ１１３］ボトルネック検出処理部１５０ｂは、業務モデルの組合せごとに複数のボトルネック候補のうち、最下位の階層のサーバをボトルネックと特定する。例えば、業務モデル“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との組合せについてボトルネック候補としてＡｐｐサーバ３００およびＤＢサーバ４００が検出されている場合が考えられる。この場合には、下位の階層のサーバであるＤＢサーバ４００を業務モデル“Ｍｏｄｅｌ−１”と“Ｍｏｄｅｌ−２”との組合せのボトルネックと特定する。ボトルネック検出処理部１５０ｂは、特定したボトルネックのサーバを示す情報を業務モデルの組合せに対応付けて報知部１６０に出力する。

［ステップＳ１１４］報知部１６０は、ボトルネック検出処理部１５０ｂから取得したボトルネックのサーバを示す情報を業務モデルの組合せごとに管理者に報知する。
このようにして、ボトルネック検出処理部１５０ｂはボトルネックのサーバを業務モデルの組合せごとに検出する。

これにより、複数の業務モデルに対するリクエストの組合せに関連して発生するボトルネックを管理者に対して適切に通知できる。例えば、Ａｐｐサーバ３００において、複数の業務モデルが共通して使用するプログラムが存在する場合、当プログラムが複数のリクエストに適切に対応できない設計であればボトルネックとなり得る。また、例えば、複数の業務モデルが発行するＤＢサーバ４００に対するクエリに問題があってボトルネックが発生することも考えられる。このように、複数の業務モデルとボトルネックとを関連付けて検出可能とすることで、共通するあるいは関連の深い問題点を抱えると考えられる複数の業務モデルを一度に特定できる。よって、管理者は、このような問題点を効率的に把握することが可能となる。その結果、このような問題点に対して効率的に対処することが可能となる。

なお、各階層に複数のサーバが設けられている場合には、第２，３の実施の形態と同様に階層単位で何れの階層がボトルネックとなっているかを検出することもできる。
［第５の実施の形態］
以下、第５の実施の形態について説明する。前述の第２〜４の実施の形態との相違点を主に説明し、同様の事項に関しては説明を省略する。

第２〜４の実施の形態において、計数部１４０が処理要求滞在数テーブル１２３あるいは処理要求滞在数テーブル１２３ａ，１２３ｂ，１２３ｃを生成する際のサンプリング周期は、これらのテーブルに設定される処理要求滞在数の精度に影響する。すなわち、サンプリング周期を大きくとると、サンプリング周期の期間内にリクエスト／レスポンスが送受信された処理に関する情報を取得できない。このような情報の欠落は、短期間にリクエスト／レスポンスが送受信される処理が多いほど顕著となる。一方、サンプリング周期を小さくとると、解析するデータ量の増加に伴い処理負荷が増大する。このため、サンプリング周期を適切に調整して、処理要求滞在数の取得精度と解析処理の負荷とのバランスを図れることが望ましい。

そこで、第５の実施の形態では、動的にサンプリング周期を変更する機能を提供する。以下では、そのための構成について詳細に説明する。
なお、第５の実施の形態の業務システムの全体構成は、図２で示した第２の実施の形態の業務システムの全体構成と同様であるため説明を省略する。ただし、運用管理サーバ１００に代えて運用管理サーバ１００ｃを設ける。

また、第５の実施の形態の業務システムに含まれる各装置のハードウェア構成は、図３で示した第２の実施の形態の運用管理サーバ１００のハードウェア構成と同様であるため説明を省略する。

図３８は、第５の実施の形態の運用管理サーバの機能構成を示す図である。運用管理サーバ１００ｃは、パケット記憶部１１０、計数情報記憶部１２０、パケット受信部１３０、計数部１４０ｃ、ボトルネック検出処理部１５０、報知部１６０およびサンプリング周期変更部１９０を有する。これらの機能は、所定のプログラムをＣＰＵ１０１が実行することで実現される。なお、これらの機能の少なくとも一部または全部を専用のハードウェアにより実現してもよい。

ここで、パケット記憶部１１０、計数情報記憶部１２０、パケット受信部１３０、ボトルネック検出処理部１５０および報知部１６０は、図４で示した第２の実施の形態の運用管理サーバ１００で同一の符号を付して説明した構成と同一であるため説明を省略する。

計数部１４０ｃは、パケット記憶部１１０に記憶されたパケット情報に基づいて、各サーバの間で送受信されるメッセージを復元する。計数部１４０ｃは、復元したメッセージに基づいて各サーバにおける処理要求滞在数を計数し、計数情報を生成する。計数部１４０ｃは、生成した計数情報を計数情報記憶部１２０に格納する。ここで、計数部１４０ｃは、サンプリング周期変更部１９０から指示されたサンプリング周期によって、処理要求滞在数を求める。

サンプリング周期変更部１９０は、計数情報記憶部１２０に記憶された処理要求滞在数テーブル１２３を参照して、処理要求滞在数の最大値が周期変更閾値よりも小さいサーバについては、計数部１４０ｃのサンプリング周期を短い周期に変更する。

サンプリング周期変更部１９０は、サンプリング周期を変更した場合、変更後のサンプリング周期を計数部１４０ｃに指示する。
次に、以上のような構成を備える運用管理サーバ１００ｃの処理手順を詳細に説明する。ここで、パケットキャプチャ処理に関しては、図１３で示した第２の実施の形態のパケットキャプチャ処理と同一であるため説明を省略する。

図３９は、第５の実施の形態の監視処理を示すフローチャートである。以下、図３９に示す処理をステップ番号に沿って説明する。
［ステップＳ１２１］計数部１４０ｃは、パケット受信部１３０がパケット記憶部１１０にファイルを出力したかの監視を開始する。なお、計数部１４０ｃが開始コマンドおよび停止コマンドを受け付けるタイミングは、図１４のステップＳ２１の場合と同様である。

［ステップＳ１２２］計数部１４０ｃは、パケット記憶部１１０に新たなファイルが出力されると、そのファイルを読み取る。
［ステップＳ１２３］計数部１４０ｃは、読み取ったファイルに基づいて各サーバで送受信されたメッセージを復元する。

［ステップＳ１２４］計数部１４０ｃは、復元したメッセージに基づいてメッセージ管理テーブルを生成し、計数情報記憶部１２０に格納する。計数部１４０ｃは、メッセージ管理テーブルに基づいてカウンタテーブルを生成し、計数情報記憶部１２０に格納する。計数部１４０ｃは、カウンタテーブルに基づいて処理要求滞在数テーブル１２３を生成して、計数情報記憶部１２０に格納する。

［ステップＳ１２５］ボトルネック検出処理部１５０は、処理要求滞在数テーブル１２３に基づいて、各サーバにおける処理要求滞在数の頻度分布を求める。そして、ボトルネック検出処理部１５０は、各サーバで求めた分布が所定の条件を満たしているかを判定して、条件を満たすサーバをボトルネック候補として検出する。ボトルネック検出処理部１５０は、ボトルネック候補からボトルネックとなり得るサーバを特定して、特定結果を報知部１６０に出力する。報知部１６０は、ボトルネック検出処理部１５０から取得したサーバを示す情報を業務システムの管理者に報知する。

［ステップＳ１２６］サンプリング周期変更部１９０は、処理要求滞在数テーブル１２３に基づいて、計数部１４０ｃが処理要求滞在数の頻度分布を解析するためのサンプリング周期を変更する。これにより、次回計数部１４０ｃが処理要求滞在数テーブル１２３を生成する際のサンプリング周期が変更される。

［ステップＳ１２７］計数部１４０ｃは、停止コマンドを受け付けるとファイル出力の監視を停止する。これにより、ボトルネック発生の有無の監視処理が完了する。
このように、計数部１４０ｃは、パケット受信部１３０のパケットキャプチャによって、パケット記憶部１１０に新たなファイルが出力されると、計数処理を実行する。そして、ボトルネック検出処理部１５０は、計数部１４０ｃによって計数情報記憶部１２０に出力された処理要求滞在数テーブル１２３に基づいて、ボトルネック検出処理を実行する。

また、計数部１４０ｃは、サンプリング周期変更部１９０からサンプリング周期変更の指示を受け付けると、変更後のサンプリング周期で次回の処理要求滞在数テーブル１２３の生成を行う。

ただし、ステップＳ１２６をステップＳ１２４の直後に行ってもよい。また、ステップＳ１２６を実行した後に同一ボトルネック解析周期で再度ステップＳ１２５を実行して、解析結果の精度を向上させることもできる。

次に、ステップＳ１２６のサンプリング周期変更処理を詳細に説明する。
図４０は、第５の実施の形態のサンプリング周期変更処理を示すフローチャートである。以下、図４０に示す処理をステップ番号に沿って説明する。

［ステップＳ１３１］サンプリング周期変更部１９０は、処理要求滞在数の周期変更閾値Ｄを取得する。例えば、周期変更閾値Ｄは、サンプリング周期変更部１９０に予め与えられる。

［ステップＳ１３２］サンプリング周期変更部１９０は、計数情報記憶部１２０に記憶された処理要求滞在数テーブル１２３を参照して、処理要求滞在数の最大値が周期変更閾値Ｄよりも小さいサーバ（階層単位で処理要求最大数を取得している場合は階層。以下同じ）が存在するか否かを判定する。処理要求滞在数の最大値がＤよりも小さいサーバが存在する場合、処理をステップＳ１３３に進める。処理要求滞在数の最大値がＤよりも小さいサーバが存在しない場合、処理をステップＳ１３５に進める。

［ステップＳ１３３］サンプリング周期変更部１９０は、処理要求滞在数の最大値がＤよりも小さいサーバの処理要求滞在数の最大値Ｎを取得する。なお、処理要求滞在数の最大値がＤよりも小さいサーバが複数存在する場合には、そのうち、より小さい方の値を最大値とするサーバについてその最大値Ｎを取得する。

［ステップＳ１３４］サンプリング周期変更部１９０は、サンプリング周期をＮ／Ｄ倍に変更する。サンプリング周期変更部１９０は、変更後のサンプリング周期をボトルネック検出処理部１５０に通知する。そして、処理を完了する。

［ステップＳ１３５］サンプリング周期変更部１９０は、サンプリング周期がデフォルト値から変更されているか否かを判定する。デフォルト値は、例えばサンプリング周期変更部１９０に予め与えられる。変更されている場合、処理をステップＳ１３６に進める。変更されていない場合、処理を完了する。

［ステップＳ１３６］サンプリング周期変更部１９０は、サンプリング周期をデフォルト値に変更し、その旨を計数部１４０ｃに通知する。そして、処理を完了する。
このようにして、サンプリング周期変更部１９０は計数部１４０ｃが処理要求滞在数テーブルを求めるためのサンプリング周期を変更する。

なお、全てのサーバについてサンプリング周期を変更する場合を例示したが、処理要求滞在数の最大値がＤよりも小さいサーバについて、該当サーバそれぞれの処理要求滞在数の最大値に応じて、該当サーバそれぞれでサンプリング周期を変更してもよい。

サンプリング周期変更処理後に実行されるボトルネック検出処理（図３９のステップＳ１２５）は、図１５に示した第２の実施の形態のボトルネック検出処理と同様であるため説明を省略する。

このようにサンプリング周期を変更することで、処理要求滞在数の最大値が小さいサーバについてもより精度良く頻度分布を取得できる。具体的には以下の通りである。
図４１は、サンプリング周期変更による頻度分布の変化を例示する図である。頻度分布６４０には、分布６４１，６４２，６４３が示されている。分布６４１，６４２，６４３は、サンプリング周期Ｔ１で取得された処理要求滞在数の頻度分布である。分布６４１，６４２，６４３は処理要求滞在数の最大値が“１”の場合の頻度分布の３つのパターンを例示したものである。ここで、周期変更閾値ＤはＤ＞１とする。

分布６４１では、処理要求滞在数“０”の頻度がほぼ“０”であり、処理要求滞在数“１”の頻度がほぼ“１．０”を示している。分布６４２では、処理要求滞在数“０”、“１”の頻度が共に“０．５”を示している。分布６４３では、処理要求滞在数“０”の頻度がほぼ“１．０”であり、処理要求滞在数“１”の頻度がほぼ“０”を示している。

このようにサンプリング周期Ｔ１では、その周期内にリクエスト／レスポンスが複数回送受信される処理要求について処理要求滞在数“０”、“１”の頻度が、“０”あるいは“１．０”に大きく偏ってしまい、解析精度が低減することが考えられる。

そこで、サンプリング周期変更部１９０は、このような場合にサンプリング周期をより短い周期Ｔ２（＜Ｔ１）に変更する。具体的には、Ｔ２＝（Ｎ／Ｄ）×Ｔ１＝Ｔ１／Ｄである。ここで、Ｎは処理要求滞在数の最大値であるのでＮ＝１を代入している。その結果、計数部１４０ｃは処理要求滞在数テーブルを短いサンプリング周期で取得する。そして、ボトルネック検出処理部１５０は、頻度分布６５０を得る。

頻度分布６５０には、分布６５１，６５２，６５３が示されている。分布６５１，６５２，６５３は、例えば分布６４１，６４２，６４３を取得したボトルネック解析周期と同じ期間の計数情報からサンプリング周期Ｔ２で取得された処理要求滞在数の頻度分布である。なお、分布６５１，６５２，６５３についても処理要求滞在数の最大値が“１”となる３つのパターンを例示している。

ここで、分布６５１は分布６４１に対応する。分布６５２は分布６４２に対応する。分布６５３は分布６４３に対応する。
分布６５１では、処理要求滞在数“０”の頻度が“０．３”であり、処理要求滞在数“１”の頻度が“０．７”を示している。分布６５２では、処理要求滞在数“０”の頻度が“０．４”であり、処理要求滞在数“１”の頻度が“０．６”を示している。分布６５３では、処理要求滞在数“０”の頻度が“０．７”であり、処理要求滞在数“１”の頻度が“０．３”を示している。

このように、サンプリング周期Ｔ２（＜Ｔ１）とすることで、サンプリング周期Ｔ１では取得できなかった処理の滞在を検出することができ、頻度分布を精度良く取得することができる。その結果、ボトルネック検出処理部１５０による解析の精度を向上することができる。

なお、上述の例では、処理要求滞在数の最大値によってサンプリング周期の変更を行うか否かを判定するものとしたがその他の方法を用いてもよい。例えば、ステップＳ１２２において、サンプリング周期変更部１９０は、ボトルネック解析周期における処理要求滞在数の平均値を算出し、その平均値が周期変更閾値よりも大きいか否かを判定することができる。そして、平均値が周期変更閾値よりも小さい場合に、ステップＳ１２３に進める。また、平均値が周期変更閾値以上である場合には、ステップＳ１２５に進める。

これにより、処理要求滞在数の最大値によりサンプリング周期の変更を行う場合と同様の効果を得ることができる。
［第６の実施の形態］
以下、第６の実施の形態について説明する。前述の第２〜５の実施の形態との相違点を中心に説明し、同様の事項に関しては説明を省略する。

第５の実施の形態では、各サーバで処理要求滞在数が周期変更閾値Ｄよりも小さい場合に頻度分布を解析するためのサンプリング周期を変更することとした。これに対し、第６の実施の形態では、第５の実施の形態の変形例として、ボトルネック候補の有無に応じてサンプリング周期の変更を行う機能を提供する。

なお、第６の実施の形態の業務システムの全体構成は、図２で示した第２の実施の形態の業務システムの全体構成と同様であるため説明を省略する。ただし、運用管理サーバ１００に代えて、運用管理サーバ１００ｄを設ける。

また、第６の実施の形態の業務システムに含まれる各装置のハードウェア構成は、図３で示した第２の実施の形態の運用管理サーバ１００のハードウェア構成と同様であるため説明を省略する。

図４２は、第６の実施の形態の運用管理サーバの機能構成を示す図である。運用管理サーバ１００ｄは、パケット記憶部１１０、計数情報記憶部１２０、パケット受信部１３０、計数部１４０ｃ、ボトルネック検出処理部１５０ｄ、報知部１６０およびサンプリング周期変更部１９０ｄを有する。これらの機能は、所定のプログラムをＣＰＵ１０１が実行することで実現される。なお、これらの機能の少なくとも一部または全部を専用のハードウェアにより実現してもよい。

ここで、パケット記憶部１１０、計数情報記憶部１２０、パケット受信部１３０、報知部１６０は、図４で示した第２の実施の形態の運用管理サーバ１００で同一の符号を付して説明した構成と同一であるため説明を省略する。また、計数部１４０ｃは、図３８で示した第５の実施の形態の運用管理サーバ１００ｃで同一の符号を付して説明した構成と同様であるため説明を省略する。

ボトルネック検出処理部１５０ｄは、計数情報記憶部１２０に記憶された計数情報に基づいて、各サーバの処理要求滞在数の頻度分布を解析し、頻度分布が所定の条件を満たすサーバをボトルネック候補として検出する。この条件は、ボトルネック検出処理部１５０が用いる条件１，２と同一である。

ボトルネック検出処理部１５０ｄは、ボトルネック候補の検出結果をサンプリング周期変更部１９０ｄに出力する。また、検出したボトルネック候補からボトルネックとなり得るサーバを特定して、特定結果を報知部１６０に出力する。

サンプリング周期変更部１９０ｄは、ボトルネック検出処理部１５０ｄによるボトルネック候補の検出結果に基づいて、計数部１４０ｃが処理要求滞在数を取得する際のサンプリング周期を変更する。

次に、以上のような構成を備える運用管理サーバ１００ｄの処理手順を詳細に説明する。ここで、パケットキャプチャ処理に関しては、図１３で示した第２の実施の形態のパケットキャプチャ処理と同一であるため説明を省略する。また、監視処理に関しては、図１４で示した第２の実施の形態の監視処理と同一であるため説明を省略する。ただし、ステップＳ２５のボトルネック検出処理が異なる。

図４３は、第６の実施の形態のボトルネック検出処理を示すフローチャートである。以下、図４３に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］サンプリング周期変更部１９０ｄは、ボトルネック検出処理部１５０ｄによる一回目のボトルネック検出処理であるか否かを検出する。一回目のボトルネック検出処理である場合、処理をステップＳ１４２に進める。一回目でない、すなわち、二回目のボトルネック検出処理である場合、処理をステップＳ１４３に進める。なお、サンプリング周期変更部１９０ｄは、ボトルネック検出処理が一回目であるか、二回目であるかを例えば所定の記憶部に設けられた所定のフラグによって判定できる。具体的には、ボトルネック検出処理部１５０ｄは、後述のステップＳ１４３において、そのフラグに次回の処理が二回目である旨を示す情報を設定することができる。運用管理サーバ１００ｄには、そのためのフラグを記憶する記憶部が予め設けられる。

［ステップＳ１４２］サンプリング周期変更部１９０ｄは、サンプリング周期をＴ１に変更し、その旨を計数部１４０ｃに通知する。そして、処理をステップＳ１４５に進める。

［ステップＳ１４３］サンプリング周期変更部１９０ｄは、サンプリング周期をＴ２（Ｔ２＜Ｔ１）に変更し、その旨を計数部１４０ｃに通知する。
［ステップＳ１４４］計数部１４０ｃは、サンプリング周期変更部１９０ｄから通知されたサンプリング周期と計数情報記憶部１２０に記憶されたカウンタテーブルとに基づいて処理要求滞在数テーブル１２３を再生成して、計数情報記憶部１２０に格納する。そして、処理をステップＳ１４５に進める。

［ステップＳ１４５］ボトルネック検出処理部１５０ｄは、業務システムの階層単位に以降のステップＳ１５２までの処理を繰り返し実行する。なお、本実施の形態では、各階層にサーバは１台ずつであるので、サーバごとに順次実行すればよい。

［ステップＳ１４６］ボトルネック検出処理部１５０ｄは、計数情報記憶部１２０に記憶された処理要求滞在数テーブル１２３に基づいて、処理対象のサーバの処理要求滞在数の頻度分布を取得する。

［ステップＳ１４７］ボトルネック検出処理部１５０ｄは、取得した頻度分布における処理要求滞在数の最大値を特定する。
［ステップＳ１４８］ボトルネック検出処理部１５０ｄは、頻度分布における処理要求滞在数の最大値近傍の集中度を算出する。

［ステップＳ１４９］ボトルネック検出処理部１５０ｄは、集中度が閾値以上であるか否かを判定する。閾値以上である場合、処理をステップＳ１５０に進める。閾値よりも小さい場合、処理をステップＳ１５２に進める。

［ステップＳ１５０］ボトルネック検出処理部１５０ｄは、頻度分布が正規分布であるか否かを判定する。正規分布でない場合、処理をステップＳ１５１に進める。正規分布である場合、処理をステップＳ１５２に進める。

［ステップＳ１５１］ボトルネック検出処理部１５０ｄは、処理対象のサーバをボトルネック候補として追加する。
［ステップＳ１５２］ボトルネック検出処理部１５０ｄは、全階層（サーバ）について処理済みであれば、処理をステップＳ１５３に進める。未処理の階層（サーバ）が存在する場合、処理をステップＳ１４５に進める。

［ステップＳ１５３］ボトルネック検出処理部１５０ｄは、ステップＳ１４５〜Ｓ１５２の処理でボトルネック候補を検出しているか否かを判定する。検出している場合、処理をステップＳ１５４に進める。検出していない場合、処理を完了する。

［ステップＳ１５４］ボトルネック検出処理部１５０ｄは、今回のボトルネック候補の検出が二回目の検出であるか否かを判定する。二回目の検出である場合、処理をステップＳ１５５に進める。二回目の検出でない、すなわち、一回目の検出である場合、処理をステップＳ１４１に進める。なお、ボトルネック検出処理部１５０ｄは、ステップＳ１４１でのサンプリング周期変更部１９０ｄによる判定処理のために、例えば、運用管理サーバ１００ｄが有する所定の記憶部に設けられた所定のフラグに次回の処理が二回目である旨を示す情報を設定する。

［ステップＳ１５５］ボトルネック検出処理部１５０ｄは、ボトルネック候補が複数検出されたか否かを判定する。複数ある場合、処理をステップＳ１５６に進める。複数でない、すなわち、１つだけ検出されている場合、処理をステップＳ１５７に進める。

［ステップＳ１５６］ボトルネック検出処理部１５０ｄは、複数のボトルネック候補のうち、最下位の階層のサーバをボトルネックと特定する。例えば、ボトルネック候補としてＡｐｐサーバ３００およびＤＢサーバ４００が検出されている場合、ＤＢサーバ４００をボトルネックと特定する。ボトルネック検出処理部１５０ｄは、特定したボトルネックのサーバを示す情報を報知部１６０に出力する。

［ステップＳ１５７］報知部１６０は、ボトルネック検出処理部１５０ｄから取得したボトルネックのサーバを示す情報を管理者に報知する。
このようにして、サンプリング周期変更部１９０ｄは計数部１４０ｃが処理要求滞在数テーブルを求めるためのサンプリング周期を変更する。

これにより、第５の実施の形態と同様の効果を得ることができる。また、第５の実施の形態よりも効率的にサンプリング周期を変更できる。具体的には次の通りである。
サンプリング周期を短縮すると、解析データが増大する。このため、計算処理コストが増大する可能性がある。一方、サンプリング周期の短縮を行わないとボトルネック検出の精度が低減する可能性がある。よって、これらの両立を図れることが望ましい。

ここで、現実の運用環境では、ボトルネックが発生していない場合、処理要求滞在数の値はピーク値前後に分布しており、集中度が閾値以上とならない場合がほとんどである。このような場合には、サンプリング周期の短縮の対象としなくても解析精度への影響は小さいと考えられる。

そこで、第６の実施の形態では、一回目は所定のサンプリング周期でボトルネック検出処理を行い、ボトルネック候補が検出されたら二回目は一回目よりも短いサンプリング周期で再度ボトルネック検出処理を行う。これにより、ボトルネック候補が検出される可能性の高い場合にサンプリング周期が短縮される。

その結果、解析処理に要する処理コストを低減しつつ、解析精度の向上を図ることが可能となる。
なお、上述の例では、ボトルネック検出処理につき一回目と二回目とで集中度の閾値を同じ値とした。しかし、一回目と二回目とで集中度の閾値を変更してもよい。具体的には、ボトルネック検出処理部１５０ｄは一回目では二回目に用いる集中度の閾値よりも小さい閾値とする。そして、一回目でボトルネック候補として仮検出したサーバに対して、再度一回目よりも大きな集中度の閾値でボトルネック検出処理を行う。

このようにすると、一回目において、サンプリング周期が長いために集中度の計算の精度が低減したとしても、ボトルネック候補をより確実に仮検出できる。このため、ボトルネック候補の検出漏れを抑制できる。

また、各階層に複数のサーバが設けられている場合には、第２〜５の実施の形態と同様に階層単位で何れの階層がボトルネックとなっているかを検出することもできる。
なお、第２〜６の実施の形態ではＷｅｂ３階層システムを例示して説明したが、このようなシステム構成に限らない。例えば、ＷｅｂサーバとＡｐｐサーバとを同一のサーバ上に設け、Ｗｅｂ／Ａｐｐ層とＤＢ層とで構成される２階層システムであってもよい。あるいは、ＡｐｐサーバとＤＢサーバとを同一のサーバ上に設け、Ｗｅｂ層とＡｐｐ／ＤＢ層とで構成される２階層システムであってもよい。また、４以上の階層を有した情報処理システムに適用することもできる。

また、各サーバ間で送受信されるメッセージに基づいて処理要求滞在数の頻度分布を求めることとしたが、このような方法に限られない。例えば、各サーバでアプリケーションの実行履歴を記録したＯＳやアプリケーションのログを取得し、取得したログを解析して処理要求滞在数を求めてもよい。ただし、そのような場合には、各サーバにおいて正確に時刻を同期させることが望ましい。時刻の同期は、例えばＮＴＰ（Network Time Protocol）を用いてスイッチ装置１０やネットワーク２０に接続されたＮＴＰサーバの時刻と同期することで行うことができる。なお、ＮＴＰによって各サーバの時刻を精度よく（例えば、マイクロ秒単位で）同期させるのは難しい。このため、短い時間（例えば、マイクロ秒単位）での処理要求滞在数を取得したい場合には、第２〜６の実施の形態で示したように、通信パケットから取得したメッセージを用いる方法がより適している。なぜなら、通信パケットをキャプチャした運用管理サーバ１００，１００ａ，１００ｂ，１００ｃ，１００ｄの時刻で各メッセージの送信タイミングを検出できるからである。また、各サーバにログの取得、通知等の役割を与えると、各サーバでそのためのプロセスを別個に実行する必要がある。このため、余計な処理負荷を与えず、各サーバ本来の処理への影響を低減するという観点からも通信パケットを利用した方法を採ることが好ましい。

第２〜６の実施の形態で説明したように、運用管理サーバ１００，１００ａ，１００ｂ，１００ｃ，１００ｄは、多階層システムにおいてアプリケーションの動作上の制限等による処理要求滞在数の飽和が原因で生じたボトルネックを適切に検出することができる。なお、ボトルネックの検出対象としてはコンピュータ単位とすることもできるし、多階層システムにおける階層単位とすることもできる。

以上、本発明の運用管理プログラム、運用管理装置および運用管理方法を図示の実施の形態に基づいて説明したが、これらに限定されるものではなく、各部の構成は同様の機能を有する任意の構成のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。更に、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

以上の第１〜第６の実施の形態を含む実施の形態に関し、更に以下の付記を開示する。
（付記１） コンピュータを、
情報処理装置から取得した、所定の時間間隔で得られたＮ（Ｎは１≦Ｎの整数）個のサンプリングタイミングから、各サンプリングタイミング時に該情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）を得る計数手段、
該Ｘｉの総和に対する、該Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理を、複数の該情報処理装置について行い、求めた該割合が所定値以上の情報処理処置を検出する処理手段、
として機能させることを特徴とする運用管理プログラム。

（付記２） 前記処理手段は、更に、処理要求滞在数ごとの前記サンプリングタイミングの数を示す頻度分布を前記情報処理装置ごとに生成し、前記頻度分布に含まれるピークのうち、最も大きな処理要求滞在数に対応するピークが正規分布に従うか否かを判定し、前記正規分布に従わないと判定した前記情報処理装置を検出することを特徴とする付記１記載の運用管理プログラム。

（付記３） 前記処理手段は、前記正規分布に従うか否かの判定の際に、前記頻度分布に含まれる前記処理要求滞在数の出現頻度の最も大きな値から前記処理要求滞在数の最大値までの範囲で前記頻度分布が単調減少となっているか否かを判定し、単調減少となっている場合には前記正規分布に従っているとみなし、単調減少となっていない場合には前記正規分布に従っていないとみなす、ことを特徴とする付記２記載の運用管理プログラム。

（付記４） 前記処理手段は、前記頻度分布を示す分布関数と頻度０の直線とで囲まれる領域の第１の面積と、前記分布関数と前記頻度０を示す直線と前記処理要求滞在数の前記所定範囲の境界値のうち前記最大値よりも小さい方の境界値を示す直線とで囲まれる領域の第２の面積と、を算出し、前記第２の面積と前記第１の面積との商を前記割合として算出することを特徴とする付記２または３の何れか一項に記載の運用管理プログラム。

（付記５） 前記コンピュータを、更に、
複数の情報処理装置間で前記処理要求を送受信した際に、各情報処理装置間で利用されたセッションを示す情報を前記処理要求に対応付けて記録した履歴情報を記憶する履歴情報記憶手段、
として機能させ、
前記計数手段は、前記履歴情報記憶手段に記憶された前記履歴情報を参照して、同一セッションで送受信されている複数の前記処理要求のうち、リクエストである最初の処理要求と前記リクエストに対するレスポンスである最後の処理要求とに基づいて、前記処理要求滞在数を計数する、
ことを特徴とする付記１乃至４の何れか一項に記載の運用管理プログラム。

（付記６） 前記コンピュータを、更に、
複数の情報処理装置間で送受信される複数の処理要求の内容を業務処理に対応付けた業務モデルを記憶する業務モデル記憶手段、
として機能させ、
前記計数手段は、前記業務モデル記憶手段に記憶された前記業務モデルごとに前記各情報処理装置の前記処理要求滞在数を求め、
前記処理手段は、前記頻度分布を前記計数手段が求めた前記業務モデルごとの前記各情報処理装置の前記処理要求滞在数に基づいて、前記業務モデルごとに前記情報処理装置の検出を行う、
ことを特徴とする付記１乃至５の何れか一項に記載の運用管理プログラム。

（付記７） 前記コンピュータを、更に、
前記計数手段が計数した前記業務モデルごとの前記各情報処理装置の前記処理要求滞在数に基づいて、関連のある複数の業務モデルを、前記処理手段による処理の対象とすべき組合せとして選択し、当該組合せを前記処理手段に通知する検査モデル選択処理手段、
として機能させ、
前記処理手段は、前記検査モデル選択処理手段から通知された前記組合せに含まれる業務モデルごとの前記各情報処理装置の前記処理要求滞在数の和、である合成処理要求滞在数に基づいて、前記情報処理装置の検出を行う、
ことを特徴とする付記６記載の運用管理プログラム。

（付記８） 前記検査モデル選択処理手段は、前記計数手段が計数した前記業務モデルごとの前記各情報処理装置の前記処理要求滞在数の時系列推移をフーリエ解析し、当該フーリエ解析の結果に基づいて、前記組合せを選択することを特徴とする付記７記載の運用管理プログラム。

（付記９） 前記計数手段は、第１のサンプリング周期で処理要求滞在数を取得し、前記第１のサンプリング周期で取得した処理要求滞在数のうち、所定の周期変更閾値以上のものが存在しない場合、前記第１のサンプリング周期よりも短い第２のサンプリング周期で処理要求滞在数を取得することを特徴とする付記１乃至８の何れか一項に記載の運用管理プログラム。

（付記１０） 前記計数手段は、前記処理手段が前記第１のサンプリング周期で取得された処理要求滞在数に基づいて前記情報処理装置を検出すると、前記第１のサンプリング周期よりも短い第２のサンプリング周期で処理要求滞在数を取得し、
前記処理手段は、前記計数手段が前記第２のサンプリング周期で取得した処理要求滞在数に基づいて再検出を行う、
ことを特徴とする付記１乃至８の何れか一項に記載の運用管理プログラム。

（付記１１） 前記処理手段は、前記情報処理装置の検出の結果、複数の情報処理装置を検出した場合、前記複数の情報処理装置の間に定義された階層関係に基づいて、最も下位の階層に設けられた情報処理装置を検出することを特徴とする付記１乃至１０の何れか一項に記載の運用管理プログラム。

（付記１２） 前記コンピュータを、更に、
前記処理手段が検出した前記情報処理装置を示す情報を報知する報知手段、
として機能させることを特徴とする付記１乃至１１の何れか一項に記載の運用管理プログラム。

（付記１３） 前記計数手段は、前記各情報処理装置が多階層システムの何れかの階層に対応付けられている場合、同一の前記階層に対応付けられた情報処理装置について求めた同一の前記サンプリングタイミングごとの前記処理要求滞在数を合計して前記各階層の前記所定期間ごとの階層単位処理要求滞在数を算出し、
前記処理手段は、前記階層ごとに計数対象となった前記サンプリングタイミングの総数に対する前記階層単位処理要求滞在数の最大値から所定範囲内の値の階層単位処理要求滞在数となる前記サンプリングタイミングの数を占める割合を前記階層ごとの集中度とし、前記集中度が所定値以上である階層を検出する、
ことを特徴とする付記１乃至付記１２の何れか一項に記載の運用管理プログラム。

（付記１４） 情報処理装置から取得した、所定の時間間隔で得られたＮ（Ｎは１≦Ｎの整数）個のサンプリングタイミングから、各サンプリングタイミング時に該情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）を得る計数部と、
該Ｘｉの総和に対する、該Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理を、複数の該情報処理装置について行い、求めた該割合が所定値以上の情報処理処置を検出する処理部と、
を有することを特徴とする運用管理装置。

（付記１５） 運用管理装置の運用管理方法であって、
計数部が、情報処理装置から取得した、所定の時間間隔で得られたＮ（Ｎは１≦Ｎの整数）個のサンプリングタイミングから、各サンプリングタイミング時に該情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）を取得し、
処理部が、該Ｘｉの総和に対する、該Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理を、複数の該情報処理装置について行い、求めた該割合が所定値以上の情報処理処置を検出する、
ことを特徴とする運用管理方法。

１ 運用管理装置
１ａ 履歴情報記憶部
１ｂ 計数部
１ｃ 処理部
２，３，４ 情報処理装置
５，６，７ 頻度分布

Claims (9)

1. コンピュータを、
   情報処理装置から取得した、所定の時間間隔で得られたＮ（Ｎは１≦Ｎの整数）個のサンプリングタイミングから、各サンプリングタイミング時に該情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）を得る計数手段、
   該Ｘｉの総和に対する、該Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理を、複数の該情報処理装置について行い、求めた該割合が所定値以上の情報処理処置を検出する処理手段、
   として機能させることを特徴とする運用管理プログラム。
2. 前記処理手段は、更に、処理要求滞在数ごとの前記サンプリングタイミングの数を示す頻度分布を前記情報処理装置ごとに生成し、前記頻度分布に含まれるピークのうち、最も大きな処理要求滞在数に対応するピークが正規分布に従うか否かを判定し、前記正規分布に従わないと判定した前記情報処理装置を検出することを特徴とする請求項１記載の運用管理プログラム。
3. 前記コンピュータを、更に、
   複数の情報処理装置間で前記処理要求を送受信した際に、各情報処理装置間で利用されたセッションを示す情報を前記処理要求に対応付けて記録した履歴情報を記憶する履歴情報記憶手段、
   として機能させ、
   前記計数手段は、前記履歴情報記憶手段に記憶された前記履歴情報を参照して、同一セッションで送受信されている複数の前記処理要求のうち、リクエストである最初の処理要求と前記リクエストに対するレスポンスである最後の処理要求とに基づいて、前記処理要求滞在数を計数する、
   ことを特徴とする請求項１または２の何れか一項に記載の運用管理プログラム。
4. 前記コンピュータを、更に、
   複数の情報処理装置間で送受信される複数の処理要求の内容を業務処理に対応付けた業務モデルを記憶する業務モデル記憶手段、
   として機能させ、
   前記計数手段は、前記業務モデル記憶手段に記憶された前記業務モデルごとに前記各情報処理装置の前記処理要求滞在数を求め、
   前記処理手段は、前記頻度分布を前記計数手段が求めた前記業務モデルごとの前記各情報処理装置の前記処理要求滞在数に基づいて、前記業務モデルごとに前記情報処理装置の検出を行う、
   ことを特徴とする請求項１乃至３の何れか一項に記載の運用管理プログラム。
5. 前記コンピュータを、更に、
   前記計数手段が計数した前記業務モデルごとの前記各情報処理装置の前記処理要求滞在数に基づいて、関連のある複数の業務モデルを、前記処理手段による処理の対象とすべき組合せとして選択し、当該組合せを前記処理手段に通知する検査モデル選択処理手段、
   として機能させ、
   前記処理手段は、前記検査モデル選択処理手段から通知された前記組合せに含まれる業務モデルごとの前記各情報処理装置の前記処理要求滞在数の和、である合成処理要求滞在数に基づいて、前記情報処理装置の検出を行う、
   ことを特徴とする請求項４記載の運用管理プログラム。
6. 前記計数手段は、第１のサンプリング周期で処理要求滞在数を取得し、前記第１のサンプリング周期で取得した処理要求滞在数のうち、所定の周期変更閾値以上のものが存在しない場合、前記第１のサンプリング周期よりも短い第２のサンプリング周期で処理要求滞在数を取得することを特徴とする請求項１乃至５の何れか一項に記載の運用管理プログラム。
7. 前記計数手段は、前記処理手段が前記第１のサンプリング周期で取得された処理要求滞在数に基づいて前記情報処理装置を検出すると、前記第１のサンプリング周期よりも短い第２のサンプリング周期で処理要求滞在数を取得し、
   前記処理手段は、前記計数手段が前記第２のサンプリング周期で取得した処理要求滞在数に基づいて再検出を行う、
   ことを特徴とする請求項１乃至５の何れか一項に記載の運用管理プログラム。
8. 情報処理装置から取得した、所定の時間間隔で得られたＮ（Ｎは１≦Ｎの整数）個のサンプリングタイミングから、各サンプリングタイミング時に該情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）を得る計数部と、
   該Ｘｉの総和に対する、該Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理を、複数の該情報処理装置について行い、求めた該割合が所定値以上の情報処理処置を検出する処理部と、
   を有することを特徴とする運用管理装置。
9. 運用管理装置の運用管理方法であって、
   計数部が、情報処理装置から取得した、所定の時間間隔で得られたＮ（Ｎは１≦Ｎの整数）個のサンプリングタイミングから、各サンプリングタイミング時に該情報処理装置が処理中の処理要求の数を示す値Ｘｉ（ｉは１≦ｉ≦Ｎの整数）を取得し、
   処理部が、該Ｘｉの総和に対する、該Ｘｉの最大値との差分が所定範囲内にあるＸｉの総和の割合を求める処理を、複数の該情報処理装置について行い、求めた該割合が所定値以上の情報処理処置を検出する、
   ことを特徴とする運用管理方法。

Images