JP4616791B2 - リクエスト種別プログラム、リクエスト種別装置およびリクエスト種別方法 - Google Patents

Description

この発明は、リクエスト種別プログラム、リクエスト種別装置およびリクエスト種別方法に関する。

従来より、Ｗｅｂ３階層システム等のように、複数のサーバ間でリクエストを呼び出し合って利用者からの要求を処理するシステムアーキテクチャが登場している。ここで、リクエストとは、個別の処理に係るプロトコル、リクエスト名、ＩＰアドレス、時刻などのデータの集合を意味する。例えば、クライアント（Ｗｅｂブラウザ）、Ｗｅｂサーバ、アプリケーションサーバ、およびデータベースサーバによって構成されるシステムにおいては、クライアントの要求をＷｅｂサーバが受け取り、Ｗｅｂサーバが受け取ったクライアントの要求をアプリケーションサーバがＷｅｂサーバからリクエストを呼び出し合って受け取り、アプリケーションサーバがこの要求に従ってデータベースサーバにアクセスし、データベースサーバにおける処理をリクエストを呼び出し合って実行するなど、複数のサーバ間でリクエストを呼び出し合ってクライアントの要求を処理している。

ところで、このようなシステムの性能や障害原因を分析することを目的として、利用者からの要求に対する複数のサーバにおける処理をモデル化して分析する手法が知られている。具体的には、特定の要求に対する実際のサーバにおける処理とモデルにおける処理との違いや、特定の時間帯の要求に対する実際のサーバにおける処理とモデルにおける処理との違い、あるいは、モデルの時間的な変化や、負荷との依存関係などを分析することで、性能分析や障害原因分析などを行う。

また、このモデル化を行うにあたっては、複数のサーバ間で送受信されるリクエストを一連の処理単位でまとめたトランザクションを識別する必要があり、その前提として、リクエストを種別する必要がある。例えば、特許文献１で開示されている方法では、トランザクションを識別するために、クライアントからＷｅｂサーバに送信されたリクエストのリクエスト名を直接利用してリクエストを種別している。

特開２００６−１１６８３号公報

ところで、上記した従来の技術では、リクエストのリクエスト名を直接利用してリクエストを種別するので、トランザクションの識別にあたりリクエストの種別が細かくなりすぎてしまい、本来同一のトランザクションに識別されるべきリクエストが異なる種別のリクエストに分類されてしまう結果、トランザクションの識別が不十分になるという課題がある。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、リクエストのリクエスト名を直接利用してリクエストを種別する手法に比較して、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことが可能なリクエスト種別プログラム、リクエスト種別装置およびリクエスト種別方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明は、複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別方法をコンピュータに実行させるリクエスト種別プログラムであって、前記リクエストに含まれる所定の文字列に係る情報ごとに当該リクエストの種別を規定するリクエスト種別規定を保持するリクエスト種別規定保持手順と、複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から当該リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、当該呼出関係集合を前記リクエスト種別規定保持手順によって保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、当該置き換えから前記リクエスト種別ごとに当該リクエスト種別を呼び出す呼出元リクエスト種別および当該リクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを前記リクエスト履歴における出現頻度とともに導出するリクエスト種別間呼出関係パターン導出手順と、前記リクエスト種別間呼出関係パターン導出手順によって導出されたリクエスト種別間呼出関係パターンを用いて前記リクエスト種別を評価する評価値を算出する評価値算出手順と、をコンピュータに実行させることを特徴とする。

また、本発明は、上記の発明において、前記リクエスト種別規定保持手順によって保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して新たにリクエスト種別を規定するリクエスト種別規定変更手順と、前記リクエスト種別規定変更手順によって変更されたリクエスト種別ごとに前記リクエスト種別間呼出関係パターン導出手順によってリクエスト種別間呼出関係パターンを導出し、当該リクエスト種別間呼出関係パターンを用いて前記評価値算出手順によって評価値を算出し、当該評価値と所定の終了条件とを比較して終了条件を判断する終了条件判断手順と、をさらに備えたことを特徴とする。

また、本発明は、上記の発明において、前記評価値算出手順は、前記リクエスト種別間呼出関係パターン導出手順によって導出されたリクエスト種別間呼出関係パターンと前記リクエスト種別との相関の強さを評価する相関値を、前記出現頻度を用いて算出することを特徴とする。

また、本発明は、上記の発明において、前記リクエスト種別間呼出関係パターン導出手順は、あらかじめ定めた所定の規定に基づいて網羅的に推定された呼出関係で関連づけられる呼出関係集合を生成してリクエスト種別間呼出関係パターンを導出することを特徴とする。

また、本発明は、前記リクエスト種別間呼出関係パターン導出手順は、前記リクエスト種別規定保持手順によって保持されたリクエスト種別規定を用いて、当該リクエスト履歴における出現頻度が高い呼出関係集合のみを生成してリクエスト種別間呼出関係パターンを導出することを特徴とする。

本発明によれば、複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別方法をコンピュータに実行させるリクエスト種別プログラムであって、リクエストに含まれる所定の文字列に係る情報ごとにリクエストの種別を規定するリクエスト種別規定を保持し、複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴からリクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、保持されたリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、置き換えからリクエスト種別ごとにリクエスト種別を呼び出す呼出元リクエスト種別およびリクエスト種別が呼び出す呼出先リクエスト種別からなるパターンをリクエスト履歴における出現頻度とともに導出し、導出されたリクエスト種別間呼出関係パターンを用いてリクエスト種別を評価するので、リクエストのリクエスト名を直接利用してリクエストを種別する手法に比較して、リクエストに含まれる所定の文字列に係る情報ごとにリクエストの種別を規定し、かつ、規定したリクエスト種別を評価することから、高い評価値が算出されるようにリクエスト種別規定を改善していくことで、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことが可能になる。

また、本発明によれば、保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して新たにリクエスト種別を規定し、変更されたリクエスト種別ごとにリクエスト種別間呼出関係パターンを導出し、リクエスト種別間呼出関係パターンを用いて評価値を算出し、評価値と所定の終了条件とを比較して終了条件を判断するので、リクエスト種別規定を自動的に変更することから、トランザクションを十分に識別し得る適切なリクエスト種別を簡易に導き出すことが可能になる。

また、本発明によれば、導出されたリクエスト種別間呼出関係パターンとリクエスト種別との相関の強さを評価する相関値を、出現頻度を用いて算出するので、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことが可能になる。

また、本発明によれば、あらかじめ定めた所定の規定に基づいて網羅的に推定された呼出関係で関連づけられる呼出関係集合を生成してリクエスト種別間呼出関係パターンを導出するので、複数のサーバ間で送受信されるリクエスト間の呼出関係を各サーバにおいて監視していない場合であっても、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことが可能になる。

また、本発明によれば、保持されたリクエスト種別規定を用いて、リクエスト履歴における出現頻度が高い呼出関係集合のみを生成してリクエスト種別間呼出関係パターンを導出するので、複数のリクエストが複数のリクエストから呼び出されている可能性があるなどリクエスト間の呼出関係の多重度が高い場合であっても、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことが可能になる。

以下に添付図面を参照して、この発明に係るリクエスト種別プログラム、リクエスト種別装置およびリクエスト種別方法の実施例を詳細に説明する。なお、以下では、実施例で用いる主要な用語、実施例１に係るリクエスト種別装置の概要および特徴、リクエスト種別装置の構成および処理の流れ、リクエスト種別装置による処理の詳細、実施例１の効果を順に説明し、最後に他の実施例を説明する。

［用語の説明］
まず最初に、以下の実施例で用いる主要な用語を説明する。以下の実施例で用いる「リクエスト（特許請求の範囲に記載の「リクエスト」に対応する）」とは、Ｗｅｂ３階層システム等のように、複数のサーバが連携して利用者からの要求を処理するシステムアーキテクチャにおいて、複数のサーバ間で送受信される情報のことである。具体的には、個別の処理に係るプロトコル、リクエスト名、ＩＰアドレス、時刻などのデータの集合である。また、リクエストは、例えば、「あるＨＴＴＰリクエストを処理するために、別のＩＩＯＰリクエストが呼び出されている」といった呼出関係（特許請求の範囲に記載の「呼出関係」に対応する）によって、複数のサーバを連携させている。

このようなリクエストは、通常、各サーバのログにリクエスト履歴として蓄積されており、蓄積されたリクエスト履歴を用いて、システムの性能や障害原因の分析が行われる。分析にあたっては、リクエストを一連の処理単位でまとめたトランザクション（特許請求の範囲に記載の「呼出関係集合」に対応する）を識別する必要がある。すなわち、トランザクションとは、システム外部から与えられたリクエスト、それを処理するために呼び出されている子リクエスト、さらに、子リクエストを処理するためにシステム内部で直接または間接に呼び出されているリクエストの集合を、リクエスト間の呼出関係を含めてまとめたものであり、このようなトランザクションを識別することで、システム内部における挙動を把握することが可能になり、システムの性能や障害原因の分析に役立つ結果となる。

ところで、リクエスト履歴からトランザクションを識別する前提として、リクエストを何らかの手法によってグループに分類するリクエスト種別（特許請求の範囲に記載の「リクエスト種別」）が行われる。これは、多種多様なリクエストから直接トランザクションを識別するよりも、分類されたリクエストからトランザクションを識別する方が、適切かつ効率的な結果を得ることができるからである。

［リクエスト種別装置の概要および特徴］
続いて、図１を用いて、実施例１に係るリクエスト種別装置の概要および特徴を説明する。図１は、実施例１に係るリクエスト種別装置の概要および特徴を説明するための図である。

実施例１に係るリクエスト種別装置は、上記したように、複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいてリクエストを種別することを概要とし、リクエストのリクエスト名を直接利用してリクエストを種別する手法に比較して、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことを特徴とする。

この主たる特徴について簡単に説明すると、図１に示すように、実施例１に係るリクエスト種別装置は、複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴をあらかじめ記憶する。また、リクエストに含まれる所定の文字列に係る情報ごとにリクエストの種別を規定するリクエスト種別規定を保持する（図１の（１）を参照）。ここで、リクエスト種別規定について具体的に説明すると、例えば、リクエスト履歴におけるリクエスト１およびリクエスト２のリクエスト名がそれぞれ「ｘｘｘａａａ１１１」および「ｘｘｘａａａ２２２」である場合に、リクエスト種別Ｇ０１として規定される文字列に係る情報が「ｘｘｘａａａ＊」であると、「＊」は任意の文字列を許すことを表すので、リクエスト１およびリクエスト２はリクエスト種別Ｇ０１に分類されることになる。

まず、実施例１に係るリクエスト種別装置は、リクエスト履歴からリクエスト間の呼出関係で関連づけられる呼出関係集合を生成する（図１の（２）を参照）。例えば、図１に示すリクエスト履歴には、リクエスト１がリクエスト４を呼び出し、リクエスト４がリクエスト５を呼び出し、リクエスト５がリクエスト９を呼び出すという呼出関係が存在するので、リクエスト１、リクエスト４、リクエスト５、およびリクエスト９について呼出関係を含めてまとめ、呼出関係集合とする。同様に、リクエスト２がリクエスト４を呼び出し、リクエスト４がリクエスト５を呼び出し、リクエスト５がリクエスト７を呼び出すという呼出関係、リクエスト３がリクエスト４を呼び出し、リクエスト４がリクエスト５を呼び出し、リクエスト５がリクエスト９を呼び出すという呼出関係についても、呼出関係集合を生成する。なお、実施例１に係るリクエスト種別装置は、あらかじめ定めた所定の規定に基づいてリクエスト履歴から呼出関係を網羅的に推定し、推定された呼出関係で関連づけられる呼出関係集合を生成しているが、図１は、その一部のみを図示したものである。

次に、リクエスト種別装置は、生成された呼出関係集合を、保持しているリクエスト種別規定で規定されるリクエスト種別間の呼出関係集合に置き換える（図１の（３）を参照）。例えば、リクエスト１は、図１の（１）に示すリクエスト種別規定によるとリクエスト種別Ｇ０１に分類されるので、リクエスト種別Ｇ０１に置き換えられる。同様に、リクエスト４はリクエスト種別Ｇ１０に置き換えられ、リクエスト５はリクエスト種別Ｇ１１に置き換えられ、リクエスト９はリクエスト種別Ｇ１２に置き換えられる。また、他の呼出関係集合についても同様に置き換えられる。

そして、リクエスト種別装置は、置き換えられたリクエスト種別間の呼出関係集合から、リクエスト種別ごとに、リクエスト種別を呼出す呼出元リクエスト種別およびリクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを、リクエスト履歴における出現頻度とともに導出する（図１の（４）を参照）。例えば、リクエスト種別Ｇ０１、リクエスト種別Ｇ１０、リクエスト種別Ｇ１１、およびリクエスト種別Ｇ１２からなるリクエスト種別間の呼出関係集合は、リクエスト種別Ｇ０１に着目して呼出関係パターンを導出すると、リクエスト種別Ｇ０１を呼び出す親リクエスト種別が存在しないことから親リクエスト種別は「なし」に、リクエスト種別Ｇ０１が呼び出す子リクエスト種別は「Ｇ１０、Ｇ１１、Ｇ１２」になる。

このとき、リクエスト種別装置は、図１の（３）におけるリクエスト種別間の呼出関係集合で、リクエスト種別Ｇ０２、リクエスト種別Ｇ１０、リクエスト種別Ｇ１１、およびリクエスト種別Ｇ１２からなる呼出関係集合について、リクエスト種別Ｇ０２に着目して呼出関係パターンを導出すると、リクエスト種別Ｇ０２を呼び出す親リクエスト種別が存在しないことから親リクエスト種別は「なし」に、リクエスト種別Ｇ０２が呼び出す子リクエスト種別は「Ｇ１０、Ｇ１１、Ｇ１２」になり、先ほどのリクエスト種別Ｇ０１に着目して導出された呼出関係パターンと同一の呼出関係パターンを導出する。なお、図１においては、出現頻度を図示していないが、リクエスト種別装置は、各リクエスト種別間呼出関係パターンと出現頻度とを対応づけて導出している。

続いて、実施例１に係るリクエスト種別装置は、導出されたリクエスト種別間呼出関係パターンとリクエスト種別との相関の強さを評価する相関値を、出現頻度を用いて算出する（図１の（５）を参照）。

また、これとは別に、実施例１に係るリクエスト種別装置は、保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して新たにリクエスト種別を規定する（図１の（６）を参照）。例えば、上記したように、リクエスト種別Ｇ０１に着目して導出された呼出関係パターンと、リクエスト種別Ｇ０２に着目して導出された呼出関係パターンとは、同一の呼出関係パターンである。すなわち、「ある呼出関係パターンで処理されているにも関わらず、異なるリクエスト種別に属している」ことになる。

このため、実施例１に係るリクエスト種別装置は、「ある呼出関係パターンで処理されているにも関わらず、異なるリクエスト種別に属しているリクエストが存在するのであれば、それらのリクエストが同一のリクエスト種別に属するようにリクエスト種別を変更する」方法を用いて、リクエストに含まれる所定の文字列に係る情報を変更する。例えば、リクエスト種別Ｇ０１およびリクエスト種別Ｇ０２において同一の呼出関係パターンが導出されることになったリクエストは、リクエスト種別Ｇ０１におけるリクエスト１およびリクエスト２と、リクエスト種別Ｇ０２におけるリクエスト３とであるので、リクエスト１またはリクエスト２の一方と、リクエスト３とが同一のリクエスト種別に属するようにリクエスト種別を変更する。具体的に例を挙げると、リクエスト１とリクエスト３とが同一の種別に属するように変更する場合には、リクエストに含まれる所定の文字列に係る情報を「ｘｘｘ＊」に変更して新たにリクエスト種別を規定することで、リクエスト１およびリクエスト３が新たに生成された同一のリクエスト種別Ｇ０３に属することになる。

続いて、実施例１に係るリクエスト種別装置は、変更されたリクエスト種別ごとに再びリクエスト種別間の呼出関係集合の置き換えを行い（図１の（３）を参照）、置き換えから変更されたリクエスト種別ごとにリクエスト種別間呼出関係パターンを導出する（図１の（４）を参照）。そして、変更されたリクエスト種別間呼出関係パターンと変更されたリクエスト種別との相関の強さを評価する相関値を、出現頻度を用いて算出する（図１の（５）を参照）。

そして、リクエスト種別装置は、このようなリクエスト種別の変更を繰り返し行い、算出された相関値と所定の終了条件とを比較して終了条件を判断し、終了条件を充たす場合に、リクエスト種別を終了する。なお、リクエスト種別を終了した時点において、実施例１に係るリクエスト種別装置が保持するリクエスト種別規定は、リクエスト種別間呼出関係パターンとの相関について高い評価値が算出されたものであるので、このようなリクエスト種別規定によって種別されたリクエストを利用することで、トランザクションを十分に識別することができるようになる。

こうして、実施例１に係るリクエスト種別装置は、複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいてリクエストを種別する場合に、リクエストのリクエスト名を直接利用してリクエストを種別する手法に比較して、リクエストに含まれる所定の文字列に係る情報ごとにリクエストの種別を規定し、かつ、規定したリクエスト種別を評価することから、高い評価値が算出されるようにリクエスト種別規定を改善していくことで、トランザクションの識別にあたり適切なリクエストの種別をすることが可能になる。

［リクエスト種別装置の構成］
次に、図２を用いて、実施例１に係るリクエスト種別装置の構成を説明する。図２は、実施例１に係るリクエスト種別装置の構成を示すブロック図である。

図２に示すように、リクエスト種別装置１０は、入力部１１と、出力部１２と、入出力制御ＩＦ部１３と、記憶部２０と、制御部３０とから主に構成される。

入力部１１は、制御部３０による各種処理に用いるデータや、各種処理をするための操作指示などを、キーボード、記憶媒体、または通信などによって入力する入力手段である。例えば、複数のサーバ間で実際に送受信されたリクエストや、リクエストに含まれる所定の文字列に係る情報や、リクエスト種別を評価する評価値を算出するための操作指示や、リクエスト種別規定を変更するための操作指示などを入力する。なお、入力部１１によって入力されたリクエストは、後述するリクエスト履歴記憶部２１に記憶され、入力部１１によって入力されたリクエストに含まれる所定の文字列に係る情報は、後述するリクエスト種別規定保持部２２に記憶される。

出力部１２は、制御部３０による各種処理の結果や、各種処理をするための操作指示などを、モニタ、プリンタなどに出力する出力手段である。例えば、入力部１１によって入力されたリクエスト履歴や、後述するリクエスト種別規定保持部２２によって保持されたリクエスト種別規定や、後述する評価値算出部３２によって算出された評価値などを出力する。

入出力制御ＩＦ部１３は、入力部１１および出力部１２と、記憶部２０および制御部３０との間におけるデータ転送を制御する手段である。

記憶部２０は、制御部３０による各種処理に用いるデータを記憶する記憶手段であり、特にこの発明に密接に関連するものとしては、図２に示すように、リクエスト履歴記憶部２１と、リクエスト種別規定保持部２２と、呼出関係集合記憶部２３と、リクエスト種別間呼出関係集合記憶部２４と、リクエスト種別間呼出関係パターン記憶部２５と、評価値記憶部２６とを備える。なお、リクエスト種別規定保持部２２は、特許請求の範囲に記載の「リクエスト種別規定保持手順」に対応する。

かかる記憶部２０のなかで、リクエスト履歴記憶部２１は、リクエスト種別装置１０においてリクエストを種別するために必要となる複数のサーバ間で実際に送受信されたリクエストを記憶する記憶手段である。具体的には、図４に示すように、入力部１１によって入力されたリクエストをリクエスト履歴として記憶する。

リクエスト種別規定保持部２２は、リクエスト種別装置１０においてリクエストの種別を規定するリクエスト種別規定を記憶する記憶手段である。具体的には、図７に示すように、入力部１１によって入力されたリクエスト種別規定、または、後述するリクエスト種別規定変更部３３によって変更されたリクエスト種別規定を記憶する。

呼出関係集合記憶部２３は、リクエスト種別装置１０においてリクエスト種別間呼出関係パターンが導出される過程で生成される呼出関係集合を記憶する記憶手段である。具体的には、図６に示すように、後述するリクエスト種別間呼出関係パターン導出部３１によってリクエスト種別間呼出関係パターンが導出される過程で生成される呼出関係集合を記憶する。

リクエスト種別間呼出関係集合記憶部２４は、リクエスト種別装置１０においてリクエスト種別間呼出関係パターンが導出される過程で生成されるリクエスト種別間呼出関係集合を記憶する記憶手段である。具体的には、図８に示すように、後述するリクエスト種別間呼出関係パターン導出部３１によってリクエスト種別間呼出関係パターンが導出される過程で生成された呼出関係集合を、リクエスト種別規定保持部２２によって保持されたリクエスト種別規定を用いて置き換えたリクエスト種別間呼出関係集合を記憶する。

リクエスト種別間呼出関係パターン記憶部２５は、リクエスト種別装置１０において導出されたリクエスト種別間呼出関係パターンを記憶する記憶手段である。具体的には、図９に示すように、後述するリクエスト種別間呼出関係パターン導出部３１によって置き換えられたリクエスト種別間の呼出関係集合から、リクエスト種別ごとにリクエスト種別を呼び出す呼出元リクエスト種別およびリクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを、リクエスト履歴における出現頻度とともに導出して記憶する。

評価値記憶部２６は、リクエスト種別装置１０においてリクエスト種別が評価された評価値を記憶する記憶手段である。具体的には、後述する評価値算出部３２によってリクエスト種別間呼出関係パターンとリクエスト種別との相関の強さを評価する相関値を記憶する。

制御部３０は、リクエスト種別装置１０を制御して各種処理を実行する制御手段であり、特にこの発明に密接に関連するものとしては、図２に示すように、リクエスト種別間呼出関係パターン導出部３１と、評価値算出部３２と、リクエスト種別規定変更部３３と、終了条件判断部３４とを備える。なお、リクエスト種別間呼出関係パターン導出部３１は、特許請求の範囲に記載の「リクエスト間呼出関係パターン導出手順」に対応し、評価値算出部３２は、特許請求の範囲に記載の「評価値算出手順」に対応し、リクエスト種別規定変更部３３は、特許請求の範囲に記載の「リクエスト種別規定変更手順」に対応し、終了条件判断部は、特許請求の範囲に記載の「終了条件判断手順」に対応する。

かかる制御部３０のなかで、リクエスト種別間呼出関係パターン導出部３１は、複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から、リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、この呼出関係集合をリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、この置き換えからリクエスト種別ごとに、リクエスト種別を呼び出す呼出元リクエスト種別およびリクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを、リクエスト履歴における出現頻度とともに導出する手段である。

具体的には、リクエスト履歴記憶部２１に記憶されたリクエスト履歴から、リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、呼出関係集合記憶部２３に記憶させる。そして、呼出関係集合記憶部２３に記憶させた呼出関係集合を、リクエスト種別規定保持部２２によって保持されたリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、リクエスト種別間呼出関係集合記憶部２４に記憶させる。続いて、リクエスト種別間呼出関係集合記憶部２４に記憶させたリクエスト種別間呼出関係集合から、リクエスト種別ごとにリクエスト種別間呼出関係パターンを、リクエスト履歴における出現頻度とともに導出し、リクエスト種別間呼出関係パターン記憶部２５に記憶させる。なお、リクエスト種別間呼出関係パターン導出部３１の具体的な処理については、後述する［リクエスト種別装置による処理（詳細）］において詳述する。

評価値算出部３２は、リクエスト種別呼出関係パターンとリクエスト種別との相関の強さを評価する相関値を、出現頻度を用いて算出する手段である。具体的には、リクエスト種別間呼出関係パターン記憶部２５に記憶されたリクエスト種別間呼出関係パターンと、リクエスト種別規定保持部２２によって保持されたリクエスト種別との相関を、リクエスト種別間呼出関係パターンとともに導出された出現頻度を用いて算出し、評価値記憶部２６に記憶させる。なお、評価値算出部３２の具体的な処理については、後述する［リクエスト種別装置による処理（詳細）］において詳述する。

リクエスト種別規定変更部３３は、リクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して、新たにリクエスト種別を規定する手段である。具体的には、リクエスト種別規定保持部２２によって保持されたリクエスト種別規定に含まれる所定の文字列に係る情報を変更して、新たにリクエスト種別を規定し、リクエスト種別規定保持部２２に記憶させる。なお、リクエスト種別規定変更部３３の具体的な処理については、後述する［リクエスト種別装置による処理（詳細）］において詳述する。

終了条件判断部３４は、変更されたリクエスト種別ごとにリクエスト種別間呼出関係パターンを導出し、リクエスト種別間呼出関係パターンを用いて相関値を算出し、相関値と所定の終了条件とを比較して終了条件を判断する手段である。具体的には、リクエスト種別規定保持部２２によって保持された変更後のリクエスト種別ごとに、リクエスト種別間呼出関係パターン導出部３１によってリクエスト種別間呼出関係パターンが導出され、評価値算出部３２によって算出された評価値と、所定の終了条件とを比較して終了条件を判断する。なお、終了条件判断部３４の具体的な処理については、後述する［リクエスト種別装置による処理（詳細）］において詳述する。

［リクエスト種別装置による処理］
次に、図３を用いて、実施例１におけるリクエスト種別装置による処理を説明する。図３は、実施例１におけるリクエスト種別処理の手順を示すフローチャートである。

まず、図３に示すように、実施例１におけるリクエスト種別装置１０は、リクエストに含まれる所定の文字列に係る情報ごとにリクエストの種別を規定するリクエスト種別規定（図７を参照）を、リクエスト種別規定保持部２２に保持する（ステップＳ３０１）。

次に、リクエスト種別装置１０は、リクエスト履歴記憶部２１に記憶されたリクエスト履歴の入力を受け付けたか否かを判断し（ステップＳ３０２）、受け付けた場合には（ステップＳ３０２肯定）、リクエスト履歴からリクエスト間の呼出関係で関連づけられる呼出関係集合（図６を参照）を生成し、呼出関係集合記憶部２３に記憶させる（ステップＳ３０３）。なお、リクエスト履歴の入力を受け付けない場合には（ステップＳ３０２否定）、リクエスト種別装置１０は、リクエスト履歴の入力を待機する。

そして、リクエスト種別装置１０は、呼出関係集合記憶部２３に記憶された呼出関係集合を、リクエスト種別規定保持部２２によって保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合（図８を参照）に置き換え、リクエスト種別間呼出関係集合記憶部２４に記憶させる（ステップＳ３０４）。

続いて、リクエスト種別装置１０は、リクエスト種別間呼出関係集合記憶部２４に記憶されたリクエスト種別間呼出関係集合から、リクエスト種別ごとに、リクエスト種別を呼び出す呼出元リクエスト種別およびリクエスト種別が呼び出す呼出先リクエスト種別からなるパターン（図９を参照）を、リクエスト履歴における出現頻度とともに導出し、リクエスト種別間呼出関係パターン記憶部２５に記憶させる（ステップＳ３０５）。

次に、リクエスト種別装置１０は、リクエスト種別間呼出関係パターン記憶部２５に記憶されたリクエスト種別間呼出関係パターンと、リクエスト種別規定保持部２２に保持されたリクエスト種別規定との相関の強さを評価する相関値を、出現頻度を用いて算出し、評価値記憶部２６に記憶させる（ステップＳ３０６）。

また、これとは別に、リクエスト種別装置１０は、リクエスト種別規定保持部２２によって保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して、新たにリクエスト種別を規定し、リクエスト種別規定保持部２２に記憶させる（ステップＳ３０７）。

次に、リクエスト種別装置１０は、呼出関係集合記憶部２３に記憶された呼出関係集合を、リクエスト種別規定保持部２２に新たに記憶された変更後のリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、リクエスト種別間呼出関係集合記憶部２４に記憶させる（ステップＳ３０８）。

そして、リクエスト種別装置１０は、リクエスト種別間呼出関係集合記憶部２４に記憶された変更後のリクエスト種別間呼出関係集合から、変更後のリクエスト種別ごとに、変更後のリクエスト種別を呼び出す呼出元リクエスト種別および変更後のリクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを、リクエスト履歴における出現頻度とともに導出し、変更後のリクエスト種別間呼出関係パターン記憶部２５に記憶させる（ステップＳ３０９）。

続いて、リクエスト種別装置１０は、リクエスト種別間呼出関係パターン記憶部２５に記憶された変更後のリクエスト種別間呼出関係パターンと、リクエスト種別規定保持部２２に保持された変更後のリクエスト種別規定との相関の強さを評価する相関値を、出現頻度を用いて算出し、評価値記憶部２６に記憶させる（ステップＳ３１０）。

次に、リクエスト種別装置１０は、他のリクエスト規定を変更するか否かを判断し（ステップＳ３１１）、変更する場合には（ステップＳ３１１肯定）、再び、ステップＳ３０７へと戻る。一方、変更しない場合には（ステップＳ３１１否定）、リクエスト種別装置１０は、ステップＳ３０６で算出した相関値と、ステップＳ３１０で算出した相関値とを比較し、リクエスト種別規定を変更することで相関値が改善したか否かを判断する（ステップＳ３１２）。

そして、相関値が改善したと判断した場合には（ステップＳ３１２肯定）、続いて、その他の終了条件とを比較して終了条件を判断し（ステップＳ３１３）、終了条件を充たしていないと判断した場合には（ステップＳ３１３否定）、リクエスト種別装置１０は、再び、ステップＳ３０７へと戻り、リクエスト種別規定を変更する。なお、ステップＳ３１２において相関値が改善していないと判断した場合（ステップＳ３１２否定）、もしくは、ステップＳ３１３において終了条件を充たすと判断した場合（ステップＳ３１３肯定）には、リクエスト種別装置１０は、リクエスト種別の処理を終了する。

［リクエスト種別装置による処理（詳細）］
次に、図４〜図１６を用いて、実施例１におけるリクエスト種別装置１０による処理を詳述する。図４は、リクエスト履歴を説明するための図であり、図５は、リクエスト間の呼出関係を説明するための図であり、図６は、呼出関係集合を説明するための図であり、図７は、リクエスト種別規定を説明するための図であり、図８は、リクエスト種別間呼出関係集合を説明するための図であり、図９は、リクエスト種別間呼出関係パターンを説明するための図であり、図１０および図１１は、相関値算出を説明するための図であり、図１２および図１３は、リクエスト種別変更後のリクエスト種別間呼出関係パターンを説明するための図であり、図１４および図１５は、リクエスト種別変更後の相関値算出を説明するための図であり、図１６は、変更後のリクエスト種別規定を説明するための図である。

［実施例１におけるリクエスト種別処理の前提］
ここで、通常のＷｅｂシステムは、Ｗｅｂサーバ、アプリケーションサーバ、およびデータベースサーバの３階層システムの場合が多いが、以下で説明する実施例１におけるリクエスト種別装置１０による処理は、説明の便宜上から、Ｗｅｂサーバ（ＩＰアドレス＝１００．１００．１００．８）およびアプリケーションサーバ（ＩＰアドレス＝１００．１００．１００．９）の２階層システムを前提とする。また、通信プロトコルとしては、クライアントとＷｅｂサーバとの間の通信にはＨＴＴＰが利用され、Ｗｅｂサーバとアプリケーションサーバとの間の通信にはＩＩＯＰが利用されることを前提とする。

まず、実施例１に係るリクエスト種別装置１０は、複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から、あらかじめ定めた所定の規定に基づいてリクエスト間の呼出関係を網羅的に推定する。ここで、リクエスト履歴とは、図４に示すように、各リクエストについて、例えば、ＩＤ、プロトコル、リクエスト名、呼出元ＩＰアドレス、呼出先ＩＰアドレス、リクエスト時刻（開始時刻）、レスポンス時刻（終了時刻）、処理時間などの情報が与えられたものである。

これらの情報のうち、呼出元ＩＰアドレスとは、そのリクエストを発した計算機（またはそれに準じるもの）のＩＰアドレスのことであり、呼出先ＩＰアドレスとは、そのリクエストを受け取った計算機、すなわち、実際にそのリクエストを処理する計算機のＩＰアドレスのことである。例えば、Ｗｅｂシステムのように、複数のサーバ間でリクエストを呼び出し合って利用者からの要求を処理するシステムアーキテクチャにおいては、ＨＴＴＰによる通信の場合、呼出元ＩＰアドレスは、Ｗｅｂブラウザが動作している利用者の計算機（クライアント）を示し、呼出先ＩＰアドレスは、Ｗｅｂシステム側のＷｅｂサーバを示すことが通常である。

また、リクエスト名とは、そのリクエストの内容を表す文字列であるが、呼出元の計算機から呼び出された（リクエストされた）内容だけでなく、それに対するレスポンスの内容を表す文字列を追加する等、編集を行うことも可能である。また、処理時間は、終了時刻から開始時刻を差し引くことで計算される。

なお、リクエスト履歴は、各サーバのログ（例えば、Ｗｅｂサーバのアクセスログなど）に蓄積されたものを利用したり、計算機間の通信をキャプチャしてその内容を解析して生成したもの（特許文献１を参照）を利用することも可能である。

［リクエスト間呼出関係推定］
実施例１に係るリクエスト種別装置１０は、図４に示されたリクエスト履歴から、あらかじめ定めた所定の規定に基づいてリクエスト間の呼出関係を網羅的に推定する。ここで、リクエスト間の呼出関係とは、例えば、「あるＨＴＴＰリクエストを処理するために、別のＩＩＯＰリクエストを呼び出す」という関係のことである。

実施例１における呼出関係の推定は、呼出元ＩＰアドレス、呼出先ＩＰアドレス、開始時刻、および終了時刻を組み合わせた所定の規定を用いて、リクエスト履歴から呼出関係を推定することから行われる。例えば、「あるリクエストＲを処理するために、別のリクエストＱが呼び出されている」という呼出関係について考えると、リクエストＱの呼出元ＩＰアドレスは、リクエストＲを処理する計算機を示すＩＰアドレスでなければならず、すなわち、リクエストＲの呼出先ＩＰアドレスでなければならないという規定が成立する。また、リクエストＱの開始時刻は、リクエストＲの開始時刻以後でなければならず、リクエストＱの終了時刻は、リクエストＲの終了時刻以前でなければならないという規定が成立する。

次に、これらの規定を用いた呼出関係の推定について、図４に示されたリクエスト履歴のＩＤ＝１５のリクエスト（以下、リクエスト１５と表記する）について具体的に説明する。まず、リクエスト１５の呼出先ＩＰアドレスは１００．１００．１００．８であるから、このリクエスト１５を処理するために、リクエスト１５から呼び出されている可能性のあるリクエストの呼出元ＩＰアドレスは、１００．１００．１００．８でなければならない。この規定を満足するリクエストは、ＩＤ＝２、４、６、８、１１、１３、１６、１８の８リクエストである。実施例１に係るリクエスト種別装置は、これらのリクエストの中から、その開始時刻がリクエスト１５の開始時刻である４３以後で、かつ、終了時刻がリクエスト１５の終了時刻である５７以前であるものを選択するので、リクエスト１６およびリクエスト１８の２つが該当する。すなわち、リクエスト１５から呼び出されている可能性があるリクエストは、リクエスト１６およびリクエスト１８の２つのリクエストである。

実施例１においては、呼出関係にある２つのリクエストについて、呼出元リクエストを「親リクエスト」と呼び、呼出先リクエストを「子リクエスト」と呼ぶことにすると、例えば、リクエスト１５は、リクエスト１６およびリクエスト１８の親リクエストの候補であり、逆に、リクエスト１６およびリクエスト１８は、リクエスト１５の子リクエストの候補である。もっとも、上記で推定した呼出関係は、あくまで「リクエスト１５を処理するために、リクエスト１６が呼び出されている可能性がある」、または、「リクエスト１５を処理するために、リクエスト１８が呼び出されている可能性がある」という確率付きのものであり、実際は、リクエスト１６は、リクエスト１５以外のリクエスト（例えば、リクエスト１４など）を処理するために呼び出されている可能性もある。

同様に、実施例１に係るリクエスト種別装置は、図４のリクエスト履歴におけるすべてのリクエストについて呼出関係を推定し、図５に示すように、親リクエスト候補および子リクエスト候補をリクエストごとにまとめる。

［呼出関係集合生成］
次に、実施例１に係るリクエスト種別装置１０は、図６に示すように、推定された呼出関係に関連づけられる呼出関係集合を生成する。なお、実施例１においては、呼出関係集合を、トランザクション（または、トランザクション候補）と呼ぶ。すなわち、トランザクションとは、システム外部から与えられたリクエストと、それを処理するために呼び出されている子リクエスト、さらに子リクエストを処理するためにシステム内部で直接または間接に呼び出されているリクエストの集合を、リクエスト間の呼出関係を含めてまとめたものである。

ここで、リクエスト間の呼出関係を正確に推定することができるのであれば、リクエスト種別装置１０は、呼出関係に関連づけられるトランザクションも正確に生成することができる。しかし、上記したように、実施例１においてリクエスト履歴から推定されるリクエスト間の呼出関係は、あくまで確率付きのものである。このため、実施例１に係るリクエスト種別装置１０は、トランザクションについて確率を計算する。

まず、実施例１に係るリクエスト種別装置１０がトランザクション候補を生成するためには、まず、システム外部から呼び出されているリクエストと、システム内部で呼ばれているリクエストとを分別することが必要である。実施例１では、Ｗｅｂサーバおよびアプリケーションサーバの２階層システムを前提としているので、クライアントからＷｅｂサーバに対してＨＴＴＰによって送信されたリクエストが、システム外部から呼び出されているリクエストであり、Ｗｅｂサーバからアプリケーションサーバに対してＩＩＯＰによって送信されたリクエストが、システム内部で呼ばれているリクエストであり、ＩＩＯＰによって送信されたリクエストがシステム外部から直接呼ばれることはないということを前提とする。

そして、リクエスト種別装置１０は、システム外部から呼び出されたリクエストをひとつ選択し、選択したリクエストから呼ばれている可能性のあるリクエストを追加し、さらに、追加されたリクエストから呼ばれている可能性のあるリクエストを追加し、以上のプロセスを、追加されたリクエストから呼ばれている可能性のあるリクエストがなくなるまで継続して行うことで、トランザクション候補の生成を行う。すなわち、システム外部から呼び出されたリクエストをひとつ選択し、選択したリクエストの子リクエスト候補を選択しないか、あるいは、ひとつまたは複数選択して追加し、さらに、追加された子リクエスト候補の子リクエスト候補を選択しないか、あるいは、ひとつまたは複数選択して追加し、以上のプロセスを、子リクエスト候補がなくなるまで継続して行う。

例えば、システム外部から呼び出されたリクエストとして、リクエスト種別装置１０が、ＩＤ＝１のリクエストを選択したとする。リクエスト１の子リクエスト候補は、図５に示すように、リクエスト２のみであるので、子リクエスト候補であるリクエスト２を選択しない場合と、子リクエスト候補であるリクエスト２を選択する場合の２つの場合を考える。このとき、リクエスト２は、ＩＩＯＰによって送信されたリクエストであるので、実施例１における前提によれば、ＨＴＴＰによって送信されたリクエストのいずれかのリクエストからシステム内部で呼ばれているはずである。ここで、リクエスト２が呼ばれている可能性のある親リクエスト候補は、図５に示すように、リクエスト１のみであるので、リクエスト２は必ずリクエスト１から呼ばれていることになり、すなわち、リクエスト１とリクエスト２の間の呼出関係が真である確率は「１」であると計算される。よって、上記した２つの場合のうち、子リクエスト候補であるリクエスト２を選択する場合のみを考えればよいことになる。

次に、選択して追加されたリクエスト２の子リクエスト候補について考えると、図５に示すように、子リクエスト候補は空集合であるので、子リクエスト候補がないことになり、リクエスト種別装置１０は、トランザクション候補の生成をここで終了する。したがって、生成されたトランザクション候補は、リクエスト１およびリクエスト２からなるトランザクションであり、その呼出関係は、リクエスト１によってリクエスト２が呼び出されている呼出関係のみであり、確率は１である。

一方、システム外部から呼び出されたリクエストとして、リクエスト種別装置１０が、ＩＤ＝１５のリクエストを選択したとする。リクエスト１５の子リクエスト候補は、図５に示すように、リクエスト１６およびリクエスト１８であるので、子リクエスト候補であるリクエスト１６およびリクエスト１８の両方を選択しない場合と、子リクエスト候補であるリクエスト１６のみを選択する場合と、子リクエスト候補であるリクエスト１８のみを選択する場合と、子リクエスト候補であるリクエスト１６およびリクエスト１８の両方を選択する場合の４つの場合を考える。このとき、リクエスト１６およびリクエスト１８は、ＩＩＯＰによって送信されたリクエストであるので、実施例１における前提によれば、ＨＴＴＰによって送信されたリクエストのいずれかのリクエストからシステム内部で呼ばれているはずである。ここで、リクエスト１６が呼ばれている可能性のある親リクエスト候補は、図５に示すように、リクエスト１４およびリクエスト１５であり、リクエスト１８が呼ばれている可能性のある親リクエスト候補は、リクエスト１５およびリクエスト１７であるので、リクエスト１６もリクエスト１８も、リクエスト１５から呼ばれている確率は０．５である。よって、上記の４つの場合の確率は、すべて０．２５となる。

次に、選択して追加されたリクエスト１６およびリクエスト１８の子リクエスト候補について考えると、図５に示すように、子リクエスト候補は空集合であるので、子リクエスト候補がないことになり、リクエスト種別装置１０は、トランザクション候補の生成をここで終了する。

同様に、実施例１に係るリクエスト種別装置１０が、図４に示すリクエスト履歴に存在するシステム外部から呼び出されたリクエスト全てについてトランザクション候補（呼出関係集合）を生成した結果が、図６である。なお、実施例１では、上記したように、Ｗｅｂサーバおよびアプリケーションサーバの２階層システムを前提としているので、トランザクション候補は、システム外部から呼び出されたＨＴＴＰリクエストひとつと、このＨＴＴＰリクエストから呼び出されているＩＩＯＰリクエストとの集合で表すことができる。そこで、図６では、ＨＴＴＰリクエストを親リクエストと記述し、このＨＴＴＰリクエストから呼び出されているＩＩＯＰリクエストの集合を子リクエストの集合として記述している。

［リクエスト種別規定保持］
ここで、実施例１に係るリクエスト種別装置１０が保持しているリクエスト種別規定について説明する。リクエスト種別規定は、リクエストに含まれる所定の文字列に係る情報ごとにリクエストの種別を規定する。この発明では、単にシステム内での処理が類似するものを集めてリクエスト種別として規定するのではなく、リクエスト種別ごとに意味を持たせ、かつ、リクエスト種別を用いた分析の結果を見る利用者がその意味を理解しやすいものとするために、特定の文字列パターン、文字列の論理積、または文字列の論理和などでリクエスト種別を規定する。

また、実施例１においては、リクエスト種別を規定するための条件として、「ＨＴＴＰリクエストはパラメータ部分（「？」以降）を無視する」と、「ＩＩＯＰはリクエスト名をそのまま使う」という条件を用いる。例えば、ＨＴＴＰリクエスト１のリクエスト名は、「top/aaa.jsp?id=1&type=update」であるので、パラメータ部分（「？」以降）を無視した「top/aaa.jsp?*」というリクエスト種別を規定する。同様に、図４に示すリクエスト履歴からリクエスト種別を規定したものが、図７である。図７では、ＨＴＴＰリクエスト種別３種類およびＩＩＯＰリクエスト種別３種類が規定されていることがわかる。

［リクエスト種別間呼出関係パターン導出］
続いて、実施例１に係るリクエスト種別装置１０は、生成された呼出関係集合を、保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、この置き換えからリクエスト種別ごとに、リクエスト種別を呼び出す呼出元リクエスト種別およびこのリクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを、リクエスト履歴における出現頻度とともに導出する。以下では、このリクエスト種別間呼出関係パターンを親子パターンと表記する。親子パターンとは、図９に示すように、リクエスト種別を呼び出している親リクエスト種別と、同じ親リクエスト種別から呼ばれている兄弟リクエスト種別と、リクエスト種別が直接呼出している子リクエスト種別の組み合わせである。

親子パターンの導出について具体的に説明すると、例えば、ＩＩＯＰリクエスト種別Ｇ１３を、図８に示すリクエスト種別で置き換えられたトランザクション候補の中で探すと、トランザクション候補４、１２、１３、１５の子リクエストの種別として登場することがわかる。このなかで、トランザクション候補４および１２では、ＨＴＴＰリクエスト種別Ｇ０２から呼び出されて、兄弟リクエスト種別は存在しない。よって、親子パターンとしては、親リクエスト種別がＧ０２、子リクエスト種別が空集合、兄弟リクエスト種別が空集合という親子パターンが生成され、その頻度は、トランザクション候補４の確率１と、トランザクション候補１２の確率０．２５の和である１．２５となる。

一方、トランザクション候補１３では、親リクエスト種別がＧ０２、子リクエスト種別が空集合、兄弟リクエスト種別が｛Ｇ１２｝という親子パターンが生成され、その頻度は、トランザクション候補１３の頻度０．２５である。また、トランザクション候補１５では、親リクエスト種別がＧ０３、子リクエスト種別が空集合、兄弟リクエスト種別が空集合という親子パターンが生成され、その頻度は、トランザクション候補１５の頻度０．５である。

同様にして、全てのリクエスト種別について親子パターンとその出現頻度（期待値）を求めた結果が、図９である。実施例１においては、Ｗｅｂサーバおよびアプリケーションサーバの２階層システムを前提としているので、ＨＴＴＰリクエストのリクエスト種別の親子パターンでは親リクエスト種別は「なし」で、兄弟リクエスト種別も空集合となり、また、ＩＩＯＰリクエストの親子パターンでは、子リクエスト集合は空集合となる。

［相関値算出］
実施例１に係るリクエスト種別装置は、全てのリクエスト種別について親子パターンを導出すると、導出した親子パターンを用いて、リクエスト種別を評価する評価値を算出する。ここで、システムの挙動や性能を分析するにあたっては、リクエスト種別は、同一のリクエスト種別に関しては、システムにおける挙動や性能が類似しており、逆に、異なるリクエスト種別に関しては、システムにおける挙動や性能が異なっていることが望ましい。そこで、実施例１においては、システムにおける挙動の最も基本的な要素として、親子パターンで表されるリクエスト種別間の呼出関係に着目する。すなわち、あるリクエスト種別に関しては親子パターンがひとつしか存在せず（もしくは、複数の親子パターンが存在してもその中のひとつの親子パターンに頻度が集中している）、かつ、ある親子パターンは異なるリクエスト種別には存在しない（もしくは、存在しても頻度が低い）ことが望ましい。

このため、実施例１に係るリクエスト種別装置は、リクエスト種別と親子パターンとの間の相関の強さを評価する相関値を算出し、相関が高ければ高いほど良いリクエスト種別であると評価する。ここで、相関の強さを評価する方法としては情報量基準に基づく方法等種々の方法が考えられるが、実施例１においては、カイ自乗法を用いる。実施例１に係るリクエスト種別装置は、あるリクエスト種別がある親子パターンで処理される実際の頻度と、リクエスト種別と親子パターンが独立であると仮定した場合に、あるリクエスト種別がある親子パターンで処理される期待値との差の自乗を、全てのリクエスト種別と親子パターンの組み合わせに対して計算し、和をとることで相関の強さを評価する。この評価方法では、リクエスト種別と親子パターンとが独立で全く相関がない場合に評価値が「０」となり、評価値が大きくなるほど相関が強いことを示す。なお、プロトコルが異なるリクエスト種別については、親子パターンが異なることは当然であるので、カイ自乗法は、プロトコルごとに行い、その結果をリクエストひとつあたりの値に正規化して（プロトコルごとのリクエスト数で割り）、その和をとったものを評価値とする。

実施例１における評価について具体的に説明すると、相関値の計算にあたり注意すべき点としては、図９の表は、リクエスト種別ごとに親子パターンをまとめているため、同一の親子パターンが異なるリクエスト種別に現れている点である。例えば、図９のＰ０１１とＰ０２２は、いずれも親リクエスト種別が「なし」、子リクエスト種別の集合が｛Ｇ１１｝、兄弟リクエスト種別の集合が｛｝である。このような２つのパターンは、相関の強さを考える上では同じパターンと考えるべきである。この点に注意して、リクエスト種別ごとの親子パターン数を計算した結果が、図１０および図１１である。

実施例１に係るリクエスト種別装置１０は、まず最初に、ＨＴＴＰリクエストについて評価値を算出する。ＨＴＴＰリクエスト全体の頻度が１０回、その中で、リクエスト種別Ｇ０１の頻度は２回、および親子パターンＰ０１１（＝Ｐ０２２）の頻度が３回であることから、リクエスト種別と親子パターンとが独立の関係であると仮定した場合に、リクエスト種別Ｇ０１が親子パターンＰ０１１（＝Ｐ０２２）で処理される頻度の期待値は、０．６回（２×３／１０＝０．６）となる。一方、実際の頻度は１回であるから、期待値との差の自乗は、０．１６（（１−０．６）^２＝０．１６）となる。同様の計算を全てのリクエスト種別と親子パターンに対して行い、その和をとると、２．９４となる。これをＨＴＴＰリクエスト数１０で割ると、ＨＴＴＰリクエストから算出される評価値は、０．２９４となる。

リクエスト種別装置１０は、同様の計算をＩＩＯＰリクエストについて行う。そして、ＩＩＯＰリクエストから算出した評価値は０．０８８となり、よって、この段階でのリクエスト種別の評価値は、これらの和である０．３８２（０．２９４＋０．０８８＝０．３８２）となる。

［リクエスト種別規定変更］
次に、実施例１に係るリクエスト種別装置１０は、保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して、新たにリクエスト種別を規定する。ここで、上記したように、あるリクエスト種別に関しては親子パターンがひとつしか存在せず（もしくは、複数の親子パターンが存在してもその中のひとつの親子パターンに頻度が集中している）、かつ、ある親子パターンは異なるリクエスト種別には存在しない（もしくは、存在しても頻度が低い）ことが望ましいので、変更方法としては、次の２つの方法が考えられる。

すなわち、「ある親子パターンで処理されているにも関わらず、異なるリクエスト種別に属しているリクエストが存在するのであれば、それらのリクエストが同一のリクエスト種別に属するようにリクエスト種別を変更する」方法と、「ある同一のリクエスト種別に属する２つのリクエストが、別々の親子パターンで処理されているのであれば、その２つのリクエストが異なるリクエスト種別に属するようにリクエスト種別を変更する」方法とである。実施例１においては、「ある親子パターンで処理されているにも関わらず、異なるリクエスト種別に属しているリクエストが存在するのであれば、それらのリクエストが同一のリクエスト種別に属するようにリクエスト種別を変更する」方法を採用する。

リクエスト種別の変更方法について具体的に説明すると、例えば、図１０に示すように、親子パターンＰ０１１（＝Ｐ０２２）に属するリクエストが、リクエスト種別Ｇ０１とＧ０２との双方に存在することがわかる。図９のリクエスト種別ごとの親子パターンから、Ｇ０１でこの親子パターンとなるのは、トランザクション候補１に含まれるＨＴＴＰリクエスト、すなわちリクエスト１で、Ｇ０２では、トランザクション候補２および７、すなわち、リクエスト３およびリクエスト１２である。したがって、リクエスト１およびリクエスト３、あるいは、リクエスト１およびリクエスト１２は同じ親子パターンで処理されるが、属するリクエスト種別が異なる。そこで、これらのリクエストの組み合わせごとにリクエスト種別の変更を行う。

具体的な変更方法は、選択された２つのリクエストのリクエスト名に共通する文字列パターンＳを求め、それを含むリクエストの集合であるリクエスト種別を新たに作る。このとき、複数のリクエスト種別に属する、すなわち、もともと属していたリクエスト種別と新たに生成されたリクエスト種別との双方に属するリクエストが出現する可能性があるが、その場合はどのリクエスト種別に属するかをリクエスト種別に適当に優先順位をつけることで選択する。なお、優先順位のつけ方は、被覆するリクエスト数の少ないものを優先する方法や、対応する文字列パターンの長い、すなわち条件の厳しい種別を優先する方法など様々な方法が考えられるが、実施例１では、新しく作られた種別を優先するものとする。この優先順位の考え方は、「新しいリクエスト種別は、それよりも古いリクエスト種別によるリクエストの分割の欠点を解決するために導入されるので、古いリクエスト種別よりも優先する」という考え方に基づいている。

実施例１におけるＨＴＴＰリクエストの現在のリクエスト種別Ｇ０１、Ｇ０２、Ｇ０３では、複数の種別に属しうるリクエストは存在しないので、文字列パターンＳに対応するリクエスト種別を導入することによって、「Ｓに対応しない、かつ、Ｇ０１」（¬Ｓ∧Ｇ０１）、「Ｓに対応しない、かつ、Ｇ０２」（¬Ｓ∧Ｇ０２）、「Ｓに対応しない、かつ、Ｇ０３」（¬Ｓ∧Ｇ０３）、「Ｓに対応する」（Ｓ）にリクエスト種別が分割されることになる。

ただし、Ｓを導入した結果、所属するリクエストが存在しなくなるリクエスト種別が出現する可能性もある。そのようなリクエスト種別は削除するので、新しいリクエスト種別を導入することで、リクエスト種別の数が減る場合も考えられる。

まず、リクエスト種別Ｇ０１からリクエスト１が選択され、リクエスト種別Ｇ０２からリクエスト３が選択されたとする。リクエスト１およびリクエスト３のリクエスト名は、それぞれ「top/aaa.jsp?id=1&type=update」および「top/bbb.jsp?id=2&type=update」であるので、これらの共通部分（文字列パターン）を求めると、「top/*.jsp?id=*&type=update」となる。ただし「*」の部分は任意の文字列を許すものとする。

すると、ＨＴＴＰリクエストのリクエスト種別は、リクエスト種別Ｇ０１が「¬top/*.jsp?id=*&type=update ∧ top/aaa.jsp?*」、リクエスト種別Ｇ０２が「¬top/*.jsp?id=*&type=update ∧ top/bbb.jsp?*」であり、リクエスト種別Ｇ０３が「¬top/*.jsp?id=*&type=update ∧ top/ddd.jsp?*」であり、リクエスト種別Ｇ０４が「top/*.jsp?id=*&type=update」となる。

なお、リクエスト履歴中で、aaa.jspおよびbbb.jspは、パラメータidおよびtypeを持ち、aaa.jspではtypeの値が必ずupdateになること、bbb.jspではtypeの値がupdateまたはcreateになること、ddd.jspではパラメータとしてidもtypeも持たないことから、上記の４つのリクエスト種別を表す文字列パターンは、リクエスト種別Ｇ０１が「なし」（該当するリクエストが存在しない）、リクエスト種別Ｇ０２が「top/bbb.jsp?id=*&type=create」、リクエスト種別Ｇ０３が「top/ddd.jsp?」、リクエスト種別Ｇ０４が「top/*.jsp?id=*&type=update」と、より簡単な形で書くことができる。リクエスト種別を用いた分析の利用者の理解しやすさという観点では、単純に否定の論理積を使って文字列パターンを組み合わせるだけでなく、それと整合する実際のリクエスト名を考慮して文字列パターンを単純化することが有効である。

そして、リクエスト種別装置１０は、これらのリクエスト種別に基づいてリクエストを種別し、ＨＴＴＰリクエストのリクエスト種別は、Ｇ０１：リクエストなし、Ｇ０２：リクエスト７、１５、Ｇ０３：リクエスト９、１７、Ｇ０４：リクエスト１、３、５、１０、１２、１４となる。

［変更後リクエスト種別の相関値算出］
実施例１に係るリクエスト種別装置１０は、変更されたリクエスト種別ごとにリクエスト種別呼出関係パターンを用いて評価値を算出する。そこで、上記と同様に、図９に相当する表を作成すると、図１２のようになる。これを基に、リクエスト種別装置１０が、カイ自乗法を用いて評価値を計算すると、変更後のリクエスト種別の評価値は１．２６となり、変更前の０．３８２よりも大きく改善する。

以下、同様に、リクエスト種別装置１０は、リクエスト１およびリクエスト１２や、他の異なるリクエスト種別に属するが同じ親子パターンで処理されるリクエストのペアについて、上記したように、リクエスト種別の変更と評価を行い、最も評価値の高いものを最終的なリクエスト種別の変更として選択する。

ここでは、リクエスト１およびリクエスト３を共通に含むリクエスト種別を生成して変更した場合の評価値が最も高く、かつ、変更前よりも評価値が改善されるので、この変更を選択し、その変更結果を現在のリクエスト種別にする。

［終了条件判断］
実施例１に係るリクエスト種別装置１０は、このような変更を、所定の終了条件を充たすまで繰り返す。なお、実施例１においては、終了条件として、「どのような変更によっても評価値が改善されなくなる」、もしくは、「変更が２回行われれば終了」、という条件が与えられている。実施例１におけるこの段階では、変更による評価値が改善されており、かつ、変更回数は１回なので、終了条件を満足していない。そこで、さらに、リクエスト種別の変更を行う。

［２回目のリクエスト種別変更］
実施例１に係るリクエスト種別装置１０は、２回目のリクエスト種別の変更として、同一の親子パターンを含む２つのリクエスト種別を選択し、そのそれぞれからひとつずつ、その親子パターンに属するリクエストを選択し、それらの共通文字列パターンに相当するリクエスト種別を生成し、それを追加した場合の評価値を計算する。リクエスト種別装置１０は、これを全ての組み合わせについて行い、最も評価値が高いものを選択する。

リクエスト種別装置１０が２回目に選択するのは、ＩＩＯＰリクエスト種別Ｇ１１に属するリクエスト２と、Ｇ１２に属するリクエスト６から新たなリクエストを生成した場合である。この２つのリクエスト名は、それぞれ、sss/reqaおよびsss/reqbであるので、共通の文字列パターンはsss/req*である。このとき、新たなＩＩＯＰリクエスト種別と、それに属するリクエストの集合は、Ｇ１１：「¬sss/req* ∧ sss/reqa」（リクエストなし）、Ｇ１２：「¬sss/req* ∧ sss/reqb」（リクエストなし）、Ｇ１３：「¬sss/req* ∧ ttt/reqc」（リクエスト８、１８）、Ｇ１８：「sss/req*」（リクエスト２、４、６、１１、１３、１６）である。

このようなリクエスト種別の変更を行った場合のリクエスト種別ごとの親子パターンを求めると、図１３のようになる。この表から、図１０および図１１に相当する表を作成すると、図１４および図１５となり、リクエスト種別装置１０が、これらの表からカイ自乗法を用いて評価値を計算すると、１．７３となり、１回目のリクエスト種別変更後の評価値１．２６よりも高い評価値であるので、リクエスト種別を変更する。

［終了条件判断］
次に、実施例１に係るリクエスト種別装置１０は、再度、終了条件を満足するか否かを判断し、今回は２回の変更を行い、終了条件を満足するので、図１６に示すように、最終的に得られたリクエスト種別と、各リクエスト種別に属するリクエストＩＤとを、結果として出力する。

ここで、最終結果であるリクエスト種別と親子パターンの相関表である図１４および図１５を、変更前のリクエスト種別と親子パターンの相関表である図１０および図１１と比較すると、変更前のリクエスト種別では、ひとつのリクエスト種別について頻度が高い親子パターンが複数存在したり、逆に、複数のリクエスト種別が同一の親子パターンで処理される頻度が高かったりする部分がある。すなわち、システム内部における挙動という観点からすると、リクエスト種別の分割が不十分だったり、逆に分割しすぎている部分があることがわかる。これに対して、変更後のリクエスト種別に対応する図１４および図１５では、リクエスト種別の観点からみても、親子パターンの観点からみても、確率の高い部分は高々ひとつしかない（図中の下線部分）。このことは、実施例１に係るリクエスト種別装置１０は、システム内部での挙動、すなわちリクエスト間の呼出関係をよりよく表すように、通常は多数存在するリクエスト名を、適当な数のリクエスト種別にまとめることができることを示している。

［実施例１の効果］
上述してきたように、実施例１によれば、複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別方法をコンピュータに実行させるリクエスト種別プログラムであって、リクエストに含まれる所定の文字列に係る情報ごとにリクエストの種別を規定するリクエスト種別規定を保持し、複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴からリクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、保持されたリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、置き換えからリクエスト種別ごとにリクエスト種別を呼び出す呼出元リクエスト種別およびリクエスト種別が呼び出す呼出先リクエスト種別からなるパターンをリクエスト履歴における出現頻度とともに導出し、導出されたリクエスト種別間呼出関係パターンを用いてリクエスト種別を評価するので、リクエストのリクエスト名を直接利用してリクエストを種別する手法に比較して、リクエストに含まれる所定の文字列に係る情報ごとにリクエストの種別を規定し、かつ、規定したリクエスト種別を評価することから、高い評価値が算出されるようにリクエスト種別規定を改善していくことで、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことが可能になる。

また、実施例１によれば、保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して新たにリクエスト種別を規定し、変更されたリクエスト種別ごとにリクエスト種別間呼出関係パターンを導出し、リクエスト種別間呼出関係パターンを用いて評価値を算出し、評価値と所定の終了条件とを比較して終了条件を判断するので、リクエスト種別規定を自動的に変更することから、トランザクションを十分に識別し得る適切なリクエスト種別を簡易に導き出すことが可能になる。

また、実施例１によれば、導出されたリクエスト種別間呼出関係パターンとリクエスト種別との相関の強さを評価する相関値を、出現頻度を用いて算出するので、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことが可能になる。

また、実施例１によれば、あらかじめ定めた所定の規定に基づいて網羅的に推定された呼出関係で関連づけられる呼出関係集合を生成してリクエスト種別間呼出関係パターンを導出するので、複数のサーバ間で送受信されるリクエスト間の呼出関係を各サーバにおいて監視していない場合であっても、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことが可能になる。

ところで、上記の実施例１では、異なるリクエスト種別に同一のリクエスト種別間呼出関係パターンが対応づけられている場合に、リクエスト種別装置が、このリクエスト種別間呼出関係パターンが同一のリクエスト種別規定に分類されるように新たなリクエスト種別を規定する方法を説明したが、この発明はこれに限定されるものではなく、同一のリクエスト種別に異なるリクエスト種別間呼出関係パターンが対応づけられている場合に、リクエスト種別装置が、これらのリクエスト種別間呼出関係パターンが異なるリクエスト種別規定に分類されるように新たなリクエスト種別を規定する方法にも、この発明を同様に適用することができる。

そこで、以下では、実施例２として、同一のリクエスト種別に異なるリクエスト種別間呼出関係パターンが対応づけられている場合に、リクエスト種別装置が、これらのリクエスト種別間呼出関係パターンが異なるリクエスト種別規定に分類されるように新たなリクエスト種別を規定する方法を説明する。なお、リクエスト種別規定変更以外の処理については実施例１と同様であるため、以下では、リクエスト種別規定変更処理についてのみ詳述する。

まず、実施例２に係るリクエスト種別装置は、同一のリクエスト種別に属するにも関わらず、異なる親子パターン（リクエスト種別間呼出関係パターン）で処理されている可能性のあるリクエストのペアを選択する。例えば、図９に示すように、ＨＴＴＰリクエストのうちリクエスト種別Ｇ０２に属する６個のリクエストが含まれるトランザクション候補（呼出関係集合）のうち、トランザクション２は、親子パターンＰ０２２で処理され、トランザクション４は、親子パターンＰ０２４で処理されている。ここで、トランザクション候補２に対応するリクエスト種別Ｇ０２のリクエストは、図６に示すようにリクエスト３、トランザクション候補４に対応するリクエスト種別Ｇ０２のリクエストは、図６に示すようにリクエスト７であるので、リクエスト３およびリクエスト７のリクエストペアは、上の「同一のリクエスト種別に属するにも関わらず、異なる親子パターン（リクエスト種別間呼出関係パターン）で処理されている可能性のあるリクエストのペア」という条件を充たす。このため、リクエスト種別装置は、リクエスト３およびリクエスト７のリクエストペアを選択する。

次に、リクエスト種別装置は、このリクエストペアのリクエスト名を比較し、これらの２つのリクエストの一方のみを含むような新たなリクエスト種別を規定する。すなわち、２つのリクエスト名を比較し、各々のリクエスト名を、２つのリクエスト名の共通部分とそれ以外の部分に分割する。例えば、リクエスト３およびリクエスト７のリクエスト名は、それぞれ「top/bbb.jsp?id=2&type=update」および「top/bbb.jsp?id=3&type=create」であるから、共通部分は「top/bbb.jsp?id=*&type=*」である。リクエスト種別装置は、この共通部分に一方にしか現れない文字列を加えた文字列パターンを用いることで、もう一方を含まない新しいリクエスト種別を規定する。この例では、リクエスト３にしか現れない文字として、idの値2、typeの値updateの２つがあり、リクエスト７にしかあらわれない文字列として、idの値3、typeの値createの２つがある。リクエスト種別装置は、これらの４つの文字列のひとつを上の共通部分に付け加えた以下の４種類の文字列パターンに相当する４種類のリクエスト種別を、新たに追加するリクエスト種別として規定する。すなわち、「top/bbb.jsp?id=2&type=*」、「top/bbb.jsp?id=*&type=update」、「top/bbb.jsp?id=3&type=*」、「top/bbb.jsp?id=*&type=create」である。

実施例２に係るリクエスト種別装置は、同様の処理を、同一のリクエスト種別に属するにも関わらず、異なる親子パターン（リクエスト種別間呼出関係パターン）で処理されている可能性のある他のリクエストペアについても行い、算出された評価値と所定の終了条件とを比較して終了条件を判断し、終了条件を充たす場合に、リクエスト種別を終了する。なお、実施例１で説明した方法から新たに規定されるリクエスト種別も含めて、最も評価値が高くなるリクエスト種別を選択してもよい。

また、上記の実施例１では、リクエスト種別装置が、リクエスト種別間呼出関係パターン導出において、あらかじめ定めた所定の規定に基づいて網羅的に推定された呼出関係で関連づけられる呼出関係集合を生成する場合を説明したが、この発明はこれに限定されるものではなく、リクエスト種別装置が、リクエスト種別間呼出関係パターン導出において保持されたリクエスト種別規定を用いて、リクエスト履歴における出現頻度が高い呼出関係集合のみを生成する場合も、この発明を同様に適用することができる。

そこで、以下では、実施例３として、保持されたリクエスト種別規定を用いて、リクエスト履歴における出現頻度が高い呼出関係集合のみを生成する場合を説明する。なお、呼出関係集合の生成以外の処理については実施例１と同様であるため、以下では、呼出関係集合の生成処理についてのみ詳述する。

まず、実施例３に係るリクエスト種別装置が、リクエスト履歴における出現頻度が高い呼出関係集合のみを生成する理由を説明すると、複数のリクエストが複数のリクエストから呼び出されている可能性があるなどリクエスト間の呼出関係の多重度が高い場合には、網羅的に推定された呼出関係で関連づけられるトランザクション候補（呼出関係集合）を全て生成することが、計算時間等の面から困難になる場合があるためである。

例えば、あるＨＴＴＰリクエストに対して、そこから呼ばれている可能性があり、かつ、他のＨＴＴＰリクエストからも呼ばれている可能性のあるＩＩＯＰリクエストがＮ個ある場合には、そのＨＴＴＰリクエストに関するトランザクション候補だけで、２のＮ乗個になる。例えば、Ｎが１０個の場合には、トランザクション候補の数は約１，０００個、Ｎが２０の場合には、トランザクション候補の数は約１００万個になる。リクエスト種別装置が、リクエストを種別するたびに毎回このような大量のトランザクション候補を用いることは現実的ではない。

この問題点を解決するためには、以下の２つの方法がある。ひとつは、システム外部から呼び出されているリクエストごとに、生成するトランザクション候補数の上限を定め、確率の高い方から所定の数の候補のみを採用する方法である。もうひとつは、トランザクション識別（特許文献１を参照）を行い、これによって得られるトランザクションのみをトランザクション候補として用いる方法である。

リクエスト種別装置は、トランザクション識別によって、システム外部から呼ばれているリクエストごとに、多数のトランザクション候補の中から最も可能性の高いトランザクションを選択する。すると、リクエスト種別装置は、生成するトランザクション候補の数をリクエスト履歴に現れるリクエスト数ににおさえることができ、かつ、リクエストの種別を正確に行うことができる。なお、トランザクション識別の結果は、リクエスト種別規定によるリクエスト種別に依存するので、評価のたびに毎回行う必要がある。

ここで、実施例１と同じリクエスト履歴を用いる場合について説明すると、実施例３に係るリクエスト種別装置は、図６に示されるような、あらかじめ定めた所定の規定に基づいて網羅的に推定された呼出関係で関連づけられるトランザクション候補を生成するのではなく、リクエスト種別規定のリクエスト名を対応するリクエスト種別のＩＤに書き換え、トランザクション識別（特許文献１を参照）を行い、図１７に示すような、トランザクション候補を生成する。

なお、この発明が対象としているリクエスト種別は、本来、トランザクション識別等の分析の前処理として行われるものであり、実施例３のように、前処理を行うためにトランザクション識別を用いる手法は矛盾しているように思える。しかし、実施例３に係るリクエスト種別装置は、適切なリクエスト種別に基づいてトランザクション識別を行い、その結果を用いてリクエスト種別を変更し、再びトランザクション識別を行うというサイクルを繰り返すことで、リクエスト種別とトランザクション識別との双方の精度を改善することができる。

ところで、これまで実施例１〜３に係るリクエスト種別装置について説明したが、この発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、実施例４に係るリクエスト種別装置として、異なる実施例を説明する。

［他の実施例］
上記の実施例１では、呼出関係集合を生成する際に、各サーバのログに蓄積されたリクエスト履歴から、あらかじめ定めた所定の規定に基づいて網羅的に呼出関係を推定して呼出関係集合を生成する場合を説明したが、この発明はこれに限定されるものではなく、各サーバが呼出関係を監視しているシステムであればその監視結果を呼び出し関係の推定結果として用いてもよい。この場合、呼出関係が確実に分かるため、全てのトランザクション候補の確率は１になる。

また、上記の実施例１では、各サーバのログに蓄積されたリクエスト履歴から、あらかじめ定めた所定の規定に基づいて網羅的に呼出関係を推定する際に、リクエストの開始時刻および終了時刻との単純な大小関係を用いて推定する場合を説明したが、この発明はこれに限定されるものではなく、子リクエストの開始時刻と親リクエストの開始時刻との差を、子リクエストの処理を開始するために必要となる最低の時間を下限値とする条件で判断するなど、その他の条件を用いて推定してもよい。

また、上記の実施例１では、リクエスト種別を評価する評価値として、リクエスト種別間呼出関係パターンとリクエスト種別との相関の強さを評価する相関値を用いる場合を説明したが、この発明はこれに限定されるものではなく、リクエスト種別ごとの処理時間分布により評価する評価値を用いたり、リクエスト種別間呼出関係パターンとリクエスト種別ごとの処理時間分布との両方により評価する評価値を用いるなど、いずれでもよい。

また、上記の実施例１では、リクエスト種別間呼出関係パターンとリクエスト種別との相関の強さを評価する相関値を算出する際に、カイ自乗法を用いる場合を説明したが、この発明はこれに限定されるものではなく、その他の情報量基準に基づく方法でもよい。

また、上記の実施例１では、新たなリクエスト種別を規定して複数のリクエスト種別に属するリクエストが出現した際に、新しく作られたリクエスト種別を優先する方法を説明したが、この発明はこれに限定されるものではなく、被覆するリクエスト数が少ないものを優先する方法や、対応する文字列パターンが長いもの（条件の厳しいリクエスト種別）を優先するなど、何らかの根拠に基づく優先方法であれば、いずれでもよい。

また、上記の実施例１では、リクエスト種別規定を変更する際に、ＨＴＴＰやＩＩＯＰといったプロトコルの違いを意識せずに処理を行う方法を説明したが、この発明はこれに限定されるものではなく、ＩＩＯＰリクエストに関してはリクエスト種別を変更せずに固定し、ＨＴＴＰリクエストのリクエスト種別のみを変更し、ＨＴＴＰリクエストのリクエスト種別変更が終了した場合に、今度はＨＴＴＰのリクエスト種別を固定して、ＩＩＯＰのリクエスト種別を変更するという方法や、ＨＴＴＰリクエストのリクエスト種別の変更が終了した場合に、ＩＩＯＰリクエストのリクエスト種別の変更を行い、その結果に基づいて、再びＨＴＴＰリクエストのリクエスト種別を変更するという方法など、いずれでもよい。なお、このような方法は、プロトコルごとにリクエスト名の性質が異なる場合、例えば、ＩＩＯＰリクエストのリクエスト名は、はじめから処理内容を表す少数の種類しかないのでリクエスト種別は比較的信用できるが、ＨＴＴＰリクエストのリクエスト名は、パラメータの値も含めると膨大な種類のリクエストが存在するというような場合に有効である。

［コンピュータ］
ところで、上記の実施例１で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１８を用いて、上記の実施例１と同様の機能を有するリクエスト種別プログラムを実行するコンピュータの一例を説明する。図１８は、実施例１に係るリクエスト種別プログラムを実行するコンピュータを示す図である。

図１８に示すように、リクエスト種別プログラム（コンピュータ）４０は、キャッシュ４１、ＲＡＭ４２、ＨＤＤ４３、ＲＯＭ４４およびＣＰＵ４５をバス４６で接続して構成される。ここで、ＲＯＭ４４には、上記の実施例１と同様の機能を発揮するリクエスト種別プログラム、つまり、図１８に示すように、リクエスト種別間呼出関係パターン導出プログラム４４ａ、評価値算出プログラム４４ｂ、リクエスト種別規定変更プログラム４４ｃ、および終了条件判断プログラム４４ｄがあらかじめ記憶されている。

そして、ＣＰＵ４５は、これらのプログラム４４ａ、４４ｂ、４４ｃ、および４４ｄを読み出して実行することで、図１８に示すように、各プログラム４４ａ、４４ｂ、４４ｃ、および４４ｄは、リクエスト種別間呼出関係パターン導出プロセス４５ａ、評価値算出プロセス４５ｂ、リクエスト種別規定変更プロセス４５ｃ、および終了条件判断プロセス４５ｄとなる。なお、各プロセス４５ａ、４５ｂ、４５ｃ、および４５ｄは、図２に示した、リクエスト種別間呼出関係パターン導出部３１、評価値算出部３２、リクエスト種別規定変更部３３、および終了条件判断部３４にそれぞれ対応する。

ところで、上記した各プログラム４４ａ、４４ｂ、４４ｃ、および４４ｄについては、必ずしもＲＯＭ４４に記憶させておく必要はなく、例えば、コンピュータ４０に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータ４０の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ４０に接続される「他のコンピュータ（またはサーバ）」に記憶させておき、コンピュータ４０がこれらからプログラムを読み出して実行するようにしてもよい。

［システム構成等］
また、上記の実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（付記１）複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別方法をコンピュータに実行させるリクエスト種別プログラムであって、
前記リクエストに含まれる所定の文字列に係る情報ごとに当該リクエストの種別を規定するリクエスト種別規定を保持するリクエスト種別規定保持手順と、
複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から当該リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、当該呼出関係集合を前記リクエスト種別規定保持手順によって保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、当該置き換えから前記リクエスト種別ごとに当該リクエスト種別を呼び出す呼出元リクエスト種別および当該リクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを前記リクエスト履歴における出現頻度とともに導出するリクエスト種別間呼出関係パターン導出手順と、
前記リクエスト種別間呼出関係パターン導出手順によって導出されたリクエスト種別間呼出関係パターンを用いて前記リクエスト種別を評価する評価値を算出する評価値算出手順と、
をコンピュータに実行させることを特徴とするリクエスト種別プログラム。

（付記２）前記リクエスト種別規定保持手順によって保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して新たにリクエスト種別を規定するリクエスト種別規定変更手順と、
前記リクエスト種別規定変更手順によって変更されたリクエスト種別ごとに前記リクエスト種別間呼出関係パターン導出手順によってリクエスト種別間呼出関係パターンを導出し、当該リクエスト種別間呼出関係パターンを用いて前記評価値算出手順によって評価値を算出し、当該評価値と所定の終了条件とを比較して終了条件を判断する終了条件判断手順と、
をさらに備えたことを特徴とする付記１に記載のリクエスト種別プログラム。

（付記３）前記評価値算出手順は、
前記リクエスト種別間呼出関係パターン導出手順によって導出されたリクエスト種別間呼出関係パターンと前記リクエスト種別との相関の強さを評価する相関値を、前記出現頻度を用いて算出することを特徴とする付記１または２に記載のリクエスト種別プログラム。

（付記４）前記リクエスト種別間呼出関係パターン導出手順は、
あらかじめ定めた所定の規定に基づいて網羅的に推定された呼出関係で関連づけられる呼出関係集合を生成してリクエスト種別間呼出関係パターンを導出することを特徴とする付記１〜３のいずれか一つに記載のリクエスト種別プログラム。

（付記５）前記リクエスト種別間呼出関係パターン導出手順は、
前記リクエスト種別規定保持手順によって保持されたリクエスト種別規定を用いて、当該リクエスト履歴における出現頻度が高い呼出関係集合のみを生成してリクエスト種別間呼出関係パターンを導出することを特徴とする付記１〜３のいずれか一つに記載のリクエスト種別プログラム。

（付記６）前記リクエスト種別規定変更手順は、
前記リクエスト種別規定保持手順によって保持された前記リクエスト種別規定の異なるリクエスト種別に、前記リクエスト種別間呼出関係パターン導出手順によって導出された同一のリクエスト種別間呼出関係パターンが対応づけられている場合には、当該リクエスト種別間呼出関係パターンが同一のリクエスト種別規定に分類されるように新たなリクエスト種別を規定することを特徴とする付記２に記載のリクエスト種別プログラム。

（付記７）前記リクエスト種別規定変更手順は、
前記リクエスト種別規定保持手順によって保持された前記リクエスト種別規定の同一のリクエスト種別に、前記リクエスト種別間呼出関係パターン導出手順によって導出された異なるリクエスト種別間呼出関係パターンが対応づけられている場合には、当該リクエスト種別間呼出関係パターンが異なるリクエスト種別規定に分類されるように新たなリクエスト種別を規定することを特徴とする付記２に記載のリクエスト種別プログラム。

（付記８）複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別装置であって、
前記リクエストに含まれる所定の文字列に係る情報ごとに当該リクエストの種別を規定するリクエスト種別規定を保持するリクエスト種別規定保持手段と、
複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から当該リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、当該呼出関係集合を前記リクエスト種別規定保持手段によって保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、当該置き換えから前記リクエスト種別ごとに当該リクエスト種別を呼び出す呼出元リクエスト種別および当該リクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを前記リクエスト履歴における出現頻度とともに導出するリクエスト種別間呼出関係パターン導出手段と、
前記リクエスト種別間呼出関係パターン導出手段によって導出されたリクエスト種別間呼出関係パターンを用いて前記リクエスト種別を評価する評価値を算出する評価値算出手段と、
を備えたことを特徴とするリクエスト種別装置。

（付記９）複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別方法であって、
前記リクエストに含まれる所定の文字列に係る情報ごとに当該リクエストの種別を規定するリクエスト種別規定を保持するリクエスト種別規定保持工程と、
複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から当該リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、当該呼出関係集合を前記リクエスト種別規定保持工程によって保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、当該置き換えから前記リクエスト種別ごとに当該リクエスト種別を呼び出す呼出元リクエスト種別および当該リクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを前記リクエスト履歴における出現頻度とともに導出するリクエスト種別間呼出関係パターン導出工程と、
前記リクエスト種別間呼出関係パターン導出工程によって導出されたリクエスト種別間呼出関係パターンを用いて前記リクエスト種別を評価する評価値を算出する評価値算出工程と、
を含んだことを特徴とするリクエスト種別方法。

以上のように、本発明に係るリクエスト種別プログラム、リクエスト種別装置およびリクエスト種別方法は、複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別することに有用であり、特に、リクエストのリクエスト名を直接利用してリクエストを種別する手法に比較して、トランザクションを十分に識別し得る適切なリクエスト種別を導き出すことに適する。

実施例１に係るリクエスト種別装置の概要および特徴を説明するための図である。 実施例１に係るリクエスト種別装置の構成を示すブロック図である。 実施例１におけるリクエスト種別処理の手順を示すフローチャートである。 リクエスト履歴を説明するための図である。 リクエスト間の呼出関係を説明するための図である。 呼出関係集合を説明するための図である。 リクエスト種別規定を説明するための図である。 リクエスト種別間呼出関係集合を説明するための図である。 リクエスト種別間呼出関係パターンを説明するための図である。 相関値算出を説明するための図である。 相関値算出を説明するための図である。 リクエスト種別変更後のリクエスト種別間呼出関係パターンを説明するための図である。 リクエスト種別変更後のリクエスト種別間呼出関係パターンを説明するための図である。 リクエスト種別変更後の相関値算出を説明するための図である。 リクエスト種別変更後の相関値算出を説明するための図である。 変更後のリクエスト種別規定を説明するための図である。 実施例３における呼出関係集合を説明するための図である。 実施例１に係るリクエスト種別プログラムを実行するコンピュータを示す図である。

符号の説明

１０ リクエスト種別装置
１１ 入力部
１２ 出力部
１３ 入出力制御ＩＦ部
２０ 記憶部
２１ リクエスト履歴記憶部
２２ リクエスト種別規定保持部
２３ 呼出関係集合記憶部
２４ リクエスト種別間呼出関係集合記憶部
２５ リクエスト種別間呼出関係パターン記憶部
２６ 評価値記憶部
３０ 制御部
３１ リクエスト種別間呼出関係パターン導出部
３２ 評価値算出部
３３ リクエスト種別規定変更部
３４ 終了条件判断部
４０ リクエスト種別プログラム（コンピュータ）
４１ キャッシュ
４２ ＲＡＭ
４３ ＨＤＤ
４４ ＲＯＭ
４５ ＣＰＵ
４６ バス

Claims (6)

1. 複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別方法をコンピュータに実行させるリクエスト種別プログラムであって、
   前記リクエストに含まれる所定の文字列に係る情報ごとに当該リクエストの種別を規定するリクエスト種別規定を保持するリクエスト種別規定保持手順と、
   複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から当該リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、当該呼出関係集合を前記リクエスト種別規定保持手順によって保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、当該置き換えから前記リクエスト種別ごとに当該リクエスト種別を呼び出す呼出元リクエスト種別および当該リクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを前記リクエスト履歴における出現頻度とともに導出するリクエスト種別間呼出関係パターン導出手順と、
   前記リクエスト種別間呼出関係パターン導出手順によって導出されたリクエスト種別間呼出関係パターンを用いて前記リクエスト種別を評価する評価値を算出する評価値算出手順と、
   前記リクエスト種別規定保持手順によって保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して新たにリクエスト種別を規定するリクエスト種別規定変更手順と、
   前記リクエスト種別規定変更手順によって変更されたリクエスト種別ごとに前記リクエスト種別間呼出関係パターン導出手順によってリクエスト種別間呼出関係パターンを導出し、当該リクエスト種別間呼出関係パターンを用いて前記評価値算出手順によって評価値を算出し、当該評価値と所定の終了条件とを比較して終了条件を判断する終了条件判断手順と、
   をコンピュータに実行させることを特徴とするリクエスト種別プログラム。
2. 前記評価値算出手順は、
   前記リクエスト種別間呼出関係パターン導出手順によって導出されたリクエスト種別間呼出関係パターンと前記リクエスト種別との相関の強さを評価する相関値を、前記出現頻度を用いて算出することを特徴とする請求項１に記載のリクエスト種別プログラム。
3. 前記リクエスト種別間呼出関係パターン導出手順は、
   あらかじめ定めた所定の規定に基づいて網羅的に推定された呼出関係で関連づけられる呼出関係集合を生成してリクエスト種別間呼出関係パターンを導出することを特徴とする請求項１又は２に記載のリクエスト種別プログラム。
4. 前記リクエスト種別間呼出関係パターン導出手順は、
   前記リクエスト種別規定保持手順によって保持されたリクエスト種別規定を用いて、当該リクエスト履歴における出現頻度が高い呼出関係集合のみを生成してリクエスト種別間呼出関係パターンを導出することを特徴とする請求項１又は２に記載のリクエスト種別プログラム。
5. 複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別装置であって、
   前記リクエストに含まれる所定の文字列に係る情報ごとに当該リクエストの種別を規定するリクエスト種別規定を保持するリクエスト種別規定保持手段と、
   複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から当該リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、当該呼出関係集合を前記リクエスト種別規定保持手段によって保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、当該置き換えから前記リクエスト種別ごとに当該リクエスト種別を呼び出す呼出元リクエスト種別および当該リクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを前記リクエスト履歴における出現頻度とともに導出するリクエスト種別間呼出関係パターン導出手段と、
   前記リクエスト種別間呼出関係パターン導出手段によって導出されたリクエスト種別間呼出関係パターンを用いて前記リクエスト種別を評価する評価値を算出する評価値算出手段と、
   前記リクエスト種別規定保持手段によって保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して新たにリクエスト種別を規定するリクエスト種別規定変更手段と、
   前記リクエスト種別規定変更手段によって変更されたリクエスト種別ごとに前記リクエスト種別間呼出関係パターン導出手段によってリクエスト種別間呼出関係パターンを導出し、当該リクエスト種別間呼出関係パターンを用いて前記評価値算出手段によって評価値を算出し、当該評価値と所定の終了条件とを比較して終了条件を判断する終了条件判断手段と、
   を備えたことを特徴とするリクエスト種別装置。
6. 複数のサーバ間でリクエストを呼び出し合ってクライアントからの要求を処理するシステムにおいて前記リクエストを種別するリクエスト種別方法であって、
   前記リクエストに含まれる所定の文字列に係る情報ごとに当該リクエストの種別を規定するリクエスト種別規定を保持するリクエスト種別規定保持工程と、
   複数のサーバ間で実際に送受信されたリクエストに係るリクエスト履歴から当該リクエスト間の呼出関係で関連づけられる呼出関係集合を生成し、当該呼出関係集合を前記リクエスト種別規定保持工程によって保持されるリクエスト種別規定を用いてリクエスト種別間の呼出関係集合に置き換え、当該置き換えから前記リクエスト種別ごとに当該リクエスト種別を呼び出す呼出元リクエスト種別および当該リクエスト種別が呼び出す呼出先リクエスト種別からなるパターンを前記リクエスト履歴における出現頻度とともに導出するリクエスト種別間呼出関係パターン導出工程と、
   前記リクエスト種別間呼出関係パターン導出工程によって導出されたリクエスト種別間呼出関係パターンを用いて前記リクエスト種別を評価する評価値を算出する評価値算出工程と、
   前記リクエスト種別規定保持工程によって保持されたリクエスト種別規定のリクエストに含まれる所定の文字列に係る情報を変更して新たにリクエスト種別を規定するリクエスト種別規定変更工程と、
   前記リクエスト種別規定変更工程によって変更されたリクエスト種別ごとに前記リクエスト種別間呼出関係パターン導出工程によってリクエスト種別間呼出関係パターンを導出し、当該リクエスト種別間呼出関係パターンを用いて前記評価値算出工程によって評価値を算出し、当該評価値と所定の終了条件とを比較して終了条件を判断する終了条件判断工程と、
   を含んだことを特徴とするリクエスト種別方法。

Images