(57)【要約】  【課題】  本発明は、暗号化されたリクエストを受け付けてクライアントからの要求を処理するシステムにおいて、複数のサーバ間で送受信されるリクエストを分析してリクエスト間の呼出関係の対応付けを行うリクエスト対応付けプログラム、リクエスト対応付け方法およびリクエスト対応付け装置に関するものである。  【解決手段】  本発明のリクエスト対応付けプログラムは、各サーバと送受信されるリクエストと開始／終了時間とを取得し、平文化されたリクエストに対してはリクエストの文字列を基にリクエスト間の呼出関係の集合を求めてサブモデルとし、サブモデルと暗号化されたリクエストのそれぞれの開始／終了時間を基に呼出関係にあると確定する、ことをコンピュータに実行させるよう構成する。【選択図】    図１０
2010123022.tif 000002
【特許請求の範囲】
【請求項１】
暗号化されたリクエストを受け付けた最上階層のサーバが該暗号化されたリクエストを平文化して次階層以下のサーバと該平文化されたリクエストを送受信して処理を行うシステムにおいて、送受信されるリクエストの呼出関係を対応付けるリクエスト対応付けプログラムであって、
前記システムを構成する各階層のサーバで送受信されるリクエストと該リクエストの開始／終了時間とを含む情報をキャプチャし、該情報をリクエストログとして記憶するリクエスト取得手順と、
前記リクエストログから次階層以下のサーバ間で送受信される前記平文化されたリクエストを抽出し、該リクエストの文字列を基に階層に跨がるリクエスト間の呼出関係の集合を求めてサブモデルを作成し、該サブモデルと該サブモデルの開始／終了時間とをサブモデルリストとして記憶するサブモデルリスト作成手順と、
前記リクエストログから前記暗号化されたリクエストと該リクエストの開始／終了時間とを抽出し、暗号化リクエストリストとして記憶する暗号化リクエストリスト作成手順と、
前記サブモデルリストに記憶しているサブモデルの開始／終了時間と前記暗号化リクエストリストに記憶している暗号化されたリクエストの開始／終了時間とを基に、該サブモデルと該暗号化されたリクエストとの呼出関係を確定する呼出関係確定手順と
をコンピュータに実行させることを特徴とするリクエスト対応付けプログラム。
【請求項２】
前記呼出関係確定手順は、それぞれの前記サブモデルの開始／終了時間が前記暗号化リクエストリストの開始／終了時間内に存在する該暗号化されたリクエストの数を調べ、該数の最も少ないサブモデルと該サブモデルの開始／終了時間を内在する暗号化されたリクエストとが呼出関係にあると確定する
ことを特徴とする請求項１に記載のリクエスト対応付けプログラム。
【請求項３】
前記暗号化されたリクエストは、ＨＴＴＰＳ通信によるリクエストである
ことを特徴とする請求項１または請求項２に記載のリクエスト対応付けプログラム。
【請求項４】
暗号化されたリクエストを受け付けた最上階層のサーバが該暗号化されたリクエストを平文化して次階層以下のサーバと該平文化されたリクエストを送受信して処理を行うシステムにおいて、送受信されるリクエストの呼出関係を対応付けるリクエスト対応付け方法であって、
前記システムを構成する各階層のサーバで送受信されるリクエストと該リクエストの開始／終了時間とを含む情報をキャプチャし、該情報をリクエストログとして記憶するリクエスト取得手順と、
前記リクエストログから次階層以下のサーバ間で送受信される前記平文化されたリクエストを抽出し、該リクエストの文字列を基に階層に跨がるリクエスト間の呼出関係の集合を求めてサブモデルを作成し、該サブモデルと該サブモデルの開始／終了時間とをサブモデルリストとして記憶するサブモデルリスト作成手順と、
前記リクエストログから前記暗号化されたリクエストと該リクエストの開始／終了時間とを抽出し、暗号化リクエストリストとして記憶する暗号化リクエストリスト作成手順と、
前記サブモデルリストに記憶しているサブモデルの開始／終了時間と前記暗号化リクエストリストに記憶している暗号化されたリクエストの開始／終了時間とを基に、該サブモデルと該暗号化されたリクエストとの呼出関係を確定する呼出関係確定手順と
を有することを特徴とするリクエスト対応付け方法。
【請求項５】
暗号化されたリクエストを受け付けた最上階層のサーバが該暗号化されたリクエストを平文化して次階層以下のサーバと該平文化されたリクエストを送受信して処理を行うシステムにおいて、送受信されるリクエストの呼出関係を対応付けるリクエスト対応付け装置であって、
前記システムを構成する各階層のサーバで送受信されるリクエストと該リクエストの開始／終了時間とを含む情報をキャプチャし、該情報をリクエストログとして記憶するリクエスト取得手段と、
前記リクエストログから次階層以下のサーバ間で送受信される前記平文化されたリクエストを抽出し、該リクエストの文字列を基に階層に跨がるリクエスト間の呼出関係の集合を求めてサブモデルを作成し、該サブモデルと該サブモデルの開始／終了時間とをサブモデルリストとして記憶するサブモデルリスト作成手段と、
前記リクエストログから前記暗号化されたリクエストと該リクエストの開始／終了時間とを抽出し、暗号化リクエストリストとして記憶する暗号化リクエストリスト作成手段と、
前記サブモデルリストに記憶しているサブモデルの開始／終了時間と前記暗号化リクエストリストに記憶している暗号化されたリクエストの開始／終了時間とを基に、該サブモデルと該暗号化されたリクエストとの呼出関係を確定する呼出関係確定手段と
を有することを特徴とするリクエスト対応付け装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号化されたリクエストを受け付けてクライアントからの要求を処理するシステムにおいて、ネットワークシステムの運用状態の把握や性能劣化の原因究明等を行うために複数のサーバ間で送受信されるリクエストからトランザクション処理を分析してリクエスト間の呼出関係の対応付けを行うリクエスト対応付けプログラム、リクエスト対応付け方法およびリクエスト対応付け装置に関するものである。
【背景技術】
【０００２】
オンラインバンキングシステムに見られるような入出金処理や残高照会は、機能の異なる複数のサーバ間でリクエストを送り合ってクライアントからの要求を処理するシステムアーキテクチャが用いられている。そのようなシステムとして、例えば図１９に示すようなＷｅｂサーバ／Ａｐｐ（アプリケーション）サーバ／ＤＢ（データベース）サーバにより構成されるＷＥＢ３階層システムが一般的に知られている。Ｗｅｂサーバはクライアントからのリクエストに基づいてＡｐｐサーバを呼び出し、呼び出しを受けたＡｐｐサーバは更にＤＢサーバにアクセスして例えば上記に示した処理を行う。即ち、システムの外部から受け付けたリクエストはその処理を行うため子のリクエストが呼び出され、さらにその子のリクエストを処理するために孫のリクエストが呼び出され、処理が行われる(このようなリクエストの集合がトランザクションである)。
【０００３】
このようなシステムにおいて、レスポンスの低下やシステム障害はサービスの低下に繋がることから性能劣化や障害の原因を究明することが必要である。そのためシステム全体で送受信されるリクエストからリクエストの呼出関係を調べ、それらのリクエストがどのような処理を行うものであるかを種別して分析することが行われる。分析のツールとしてシステム可視化分析ソフトウェアが存在し、そのソフトウェアでは階層化されたサーバ間で送受信されるリクエストをもとにトランザクションを組み立て、組み立てたトランザクションをもとに分析を行うことが知られている（特許文献1）。
【０００４】
従来は、このトランザクションの組み立てにリクエストとして送受信されている電文中の部分文字列（ＵＲＬ（Uniform Resource Locator）等のリクエストの一部）を用いて種別分けし、トランザクションを組み立てることが行われていた（特許文献２）。このとき、ＨＴＴＰ（Hyper Text Transfer Protocol）の通信を例に挙げれば、使える文字列としては処理されるＣＧＩ（Common Gateway Interface）のＵＲＬや、ＣＧＩに渡されるオプションのパラメタがある。従来技術ではこれらＵＲＬやＣＧＩパラメタの文字列に基づいてリクエスト間の呼出関係を求め、予め定めた種別規定を参照してリクエストの種別分けしている。
【０００５】
上記の種別分けを図を用いて説明する。図２０はＨＴＴＰ通信におけるＵＲＬとパラメタの例を示し、図２１にＷＥＢ３階層システムにおけるサーバ間で受け渡される上記のパラメタの例を示している。図２１において、Ｗｅｂサーバはクライアントから受け取ったリクエストを解析してパラメタを含む新たなリクエストを生成してＡｐｐサーバを呼び出しパラメタを含む情報を渡している。Ｗｅｂサーバからのリクエストに基づいて、Ａｐｐサーバは受け取ったリクエストを解析してパラメタを含むリクエストを生成し、ＤＢサーバを呼び出しリクエストを渡す。ＤＢサーバはリクエストに基づいて例えばデータベースにアクセスし、必要な処理をして処理結果をＡｐｐサーバにレスポンスする。レスポンスの情報は更にＷＥＢサーバを介してクライアント（図２１のＣｌｉｅｎｔ、正確にはクライアントのＷｅｂブラウザ）に渡される。Ｗｅｂサーバ、ＡｐｐサーバおよびＤＢサーバで受け渡しされるリクエストの呼出関係は、例えば図２１に示すパラメタの文字列を基に関係付けられ、関係付けられたリクエストの集合と予め定めた種別規定（処理形態で定まるリクエストの呼出関係パターン）と比較することにより関係付けられたリクエストの集合はどのような処理を行ったものであるかを種別分けすることができる。
【特許文献１】特開２００６−１１６８３号公報
【特許文献２】特開２００７−３０４６４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、従来手法ではサーバ間での通信が暗号化されている場合には種別分けに必要となる電文中の文字列が解読できなくなるため、暗号化された通信を含むトランザクションを扱えないという問題がある。特に対外アクセスにも使用されているＨＴＴＰＳ通信では安全性を高めるために暗号化されており（ＣＧＩのＵＲＬとオプションパラメタの総てが暗号化される）、従来技術のように電文の部分文字列を使用してリクエストの呼出関係を調べて種別分けする手法が使用できない。
【０００７】
図２２は、暗号化されたリクエストを受け付けた場合の例を図２１に対比させて描いたものである。図２２に示されるようにＷｅｂサーバはクライアントから暗号化されたリクエストを受け付けると、下位階層のＡｐｐサーバに対して暗号化されたリクエストを平文化してリクエストを送信する。従って、Ａｐｐサーバ以下においては従来手法によっては可能である。しかしながら、Ａｐｐサーバ以下で呼出関係の対応付けしたリクエストとＷｅｂサーバが受け付けた暗号化されたリクエストとの呼出関係の対応付けは従来手法では困難である。
【０００８】
そこで、本発明では、ＨＴＴＰＳ通信等によりリクエストの電文解読ができない（ＵＲＬもパラメタも取得できない）場合において、各階層のサーバにおけるリクエストの呼出関係を求め、階層を跨ぐリクエスト間の対応付けを行うことを課題とする。
【課題を解決するための手段】
【０００９】
本発明のリクエスト対応付けプログラムは、暗号化されたリクエストを受け付けた最上階層のサーバが暗号化されたリクエストを平文化して次階層以下のサーバと平文化されたリクエストを送受信して処理を行うシステムにおいて、送受信されるリクエストの呼出関係を対応付けるリクエスト対応付けプログラムであり、次に示すリクエスト取得手順、サブモデルリスト作成手順、暗号化リクエストリスト作成手順および呼出関係確定手順をコンピュータに実行させることを特徴とするものである。
【００１０】
リクエスト取得手順は、システムを構成する各階層のサーバで送受信されるリクエストとそのリクエストの開始／終了時間とを含む情報をキャプチャし、その情報をリクエストログとして記憶。
【００１１】
サブモデルリスト作成手順は、リクエストログから次階層以下のサーバ間で送受信される平文化されたリクエストを抽出し、リクエストの文字列を基に階層に跨がるリクエスト間の呼出関係の集合を求めてサブモデルを作成し、サブモデルとそのサブモデルの開始／終了時間とをサブモデルリストとして記憶する。
【００１２】
暗号化リクエストリスト作成手順は、リクエストログから暗号化されたリクエストとそのリクエストの開始／終了時間とを抽出し、暗号化リクエストリストとして記憶する。
【００１３】
呼出関係確定手順は、サブモデルリストに記憶しているサブモデルの開始／終了時間と暗号化リクエストリストに記憶している暗号化されたリクエストの開始／終了時間とを基に、サブモデルと暗号化されたリクエストとの呼出関係を確定する。
【発明の効果】
【００１４】
暗号化されたリクエストとそのリクエストに基づいて作成されたリクエストの集合（即ち、上記のサブモデル）とのそれぞれの開始／終了時間を比較することで呼出関係を容易に対応付けることができ、暗号化された通信であってもネットワークシステムの分析が可能となる。
【発明を実施するための最良の形態】
【００１５】
本発明のリクエスト対応付けプログラム、リクエスト対応付け方法およびリクエスト対応付け装置についてＷＥＢ３階層システムを例にとり図１〜図１８を用いて説明する。
【００１６】
まず本発明に係わる全体の構成例を図１を用いて説明する。図１において、ＷＥＢ３階層システム１０はＷｅｂサーバ１１、Ａｐｐサーバ１２、ＤＢサーバ１３から成り、Ｗｅｂサーバ１１はネットワーク２０に接続している。クライアントが所有するクライアント端末３０−３３もネットワーク２０と接続しており、クライアントはネットワーク２０を介してＷＥＢ３階層システム１０のＷｅｂサーバ１１にリクエストを行い、サービスの提供を受けることができる。
【００１７】
ポートミラーリング４０は、ＷＥＢ３階層システム１０の各サーバで送受信されるリクエストをキャプチャし、可視化システム５０の可視化サーバ１００はシステム可視化ソフトウェアを搭載してポートミラーリング４０がキャプチャしたリクエスト情報を取得する。可視化クライアント端末１０１は、可視化サーバ１００がリクエスト情報を基に可視化した情報を表示する。
【００１８】
次に、図２を用いて可視化システム５０の構成を説明する。可視化システム５０は図１に示すように可視化サーバ１００と可視化クライアント端末１０１とで構成し、可視化サーバ１００は全体を制御するＣＰＵ（Central Processing Unit）１１０、リクエスト対応付けプログラム１３０を実行する主メモリ１２０、可視化クライアント端末１０１に対する入出力を制御する入出力制御部１４０、ポートミラーリング４０から取得したリクエスト情報を記憶するリクエストログ記憶部１５０、リクエスト対応付けプログラム１３０を実行する上で作成されるリスト等の情報（詳細は後述する）を記憶するＬｉｓｔ／Ｍａｐ記憶部１６０、およびポートミラーリング４０との通信を制御する通信制御部１７０から成る。
【００１９】
ここでは、本発明に必要な構成要素のみを示している。また、システム可視化分析ソフトウェアはリクエスト対応付けプログラム１３０がシステム可視化分析ソフトウェアを構成する１プログラムとして示している。なお、リクエスト対応付け装置は図２に示される可視化サーバ１００に相当する。
【００２０】
次に、リクエスト対応付け方法について図３−図１０を用いて説明する。図３はポートミラーリング４０を介してリクエストログ記憶部１５０に記録したリクエストログのリクエストを各サーバの階層毎に示したものである。縦軸はクライアントをベースとして各サーバの階層（Ｗｅｂ、Ａｐｐ、ＤＢ）を示し、横軸は時間の推移を示す。図に示されるように、Ｗｅｂサーバの階層を示すＷｅｂではｈｔｔｐｓ１とｈｔｔｐｓ２のリクエストが記録され、Ａｐｐの階層ではｉｉｏｐ１とｉｉｏｐ２が、ＤＢの階層ではｄｂ１とｄｂ２がリクエストとして記録された例である。ｈｔｔｐｓ１とｈｔｔｐｓ２とは暗号化されており、ｉｉｏｐ１、ｉｉｏｐ２、ｄｂ１およびｄｂ２のリクエストは平文化されている。リクエストログに記録されたログは、ポートミラーリング４０が時系列に収集したリクエストを単に記録したもので、各階層を跨ぐリクエスト間の呼出関係は判っていない。
【００２１】
このリクエストログを基に、平文化されているリクエストについて従来手法により図４に示す呼出関係の対応付けを行う。即ち、リクエストｉｉｏｐ１、ｉｉｏｐ２とリクエストｄｂ１、ｄｂ２の電文を構成する部分文字列を基に親子関係、即ち呼出関係を構築する。図４の円で囲んだリクエスト（ｉｉｏｐ１とｄｂ１、およびｉｉｏｐ２とｄｂ２）が呼出関係にあるリクエストの集合ということになる。なお、ｈｔｔｐｓ１およびｈｔｔｐｓ２は暗号化されているため、従来手法によって呼出関係の対応付けはできない。
【００２２】
図４に示される対応付けがなされたリクエストの組み合わせ（リクエストの集合）に対してＩＤを付与し１つのサブモデルとして扱う。図５は対応付けがなされたリクエストの組み合わせをサブモデルとして置き換えた状態を示す。この状態から、このサブモデルに対する親となる暗号化されたＨＴＴＰＳを探し、対応付けを行うことになる。
【００２３】
サブモデルに対応するＨＴＴＰＳを探すために、サブモデルの開始／終了時間とＨＴＴＰＳの開始／終了時間を対比し、サブモデルの開始／終了時間がＨＴＴＰＳの開始／終了時間に内在するかどうかを調べる。図６に示す図の横軸は時間軸を示しており、サブモデルｓｕｂ１はｈｔｔｐｓ１とｈｔｔｐｓ２の両リクエストの開始／終了時間内にあり、サブモデルｓｕｂ２はｈｔｔｐｓ２のみ開始／終了時間内にあることが判る（図６のサブモデルの開始と終了の時間を点線で示しており、その時間がＨＴＴＰＳの処理時間内にあるかどうかを見ている）。このとき、サブモデルｓｕｂ１はｈｔｔｐｓ１とｈｔｔｐｓ２との２つのリクエストに関係しているので、それぞれのリクエスト（ｈｔｔｐｓ１とｈｔｔｐｓ２）に５０％の確率で呼出関係にあると言える。また、ｓｕｂ２はｈｔｔｐｓ２に１００％の確率で呼出関係にあると言える。従って、ｓｕｂ２とｈｔｔｐｓ２とは呼出関係にあると確定する（サブモデルとリクエストのＨＴＴＰＳとが呼出関係が確定した組み合わせをここでは確定モデルと言うことにする）。このため、サブモデルｓｕｂ１とｈｔｔｐｓ１、またはｓｕｂ１とｈｔｔｐｓ２の組み合わせの内のｓｕｂ１とｈｔｔｐｓ２はあり得ないことになる。図７はｓｕｂ２とｈｔｔｐｓ２が確定モデルとして決定され、それに伴ってｓｕｂ１とｈｔｔｐｓ２の組み合わせは消去されたことを示している。
【００２４】
組み合わせが決まったサブモデルおよびＨＴＴＰＳが除かれ、残ったサブモデルとＨＴＴＰＳでサブモデルの開始／終了時間がＨＴＴＰＳの開始／終了時間内にある確率を再計算する。図８は、図７でｓｕｂ２とｈｔｔｐｓ２とが呼出関係にある確定モデルとして除かれ、ｓｕｂ１とｈｔｔｐｓ１とが残って呼出関係の確率を求めている状態を示している。ｓｕｂ１の開始／終了時間はｈｔｔｐｓ１の開始／終了時間内にあり、他のＨＴＴＰＳは存在しないので確率１００％となって、ｓｕｂ１とｈｔｔｐｓ１とは呼出関係にあると確定する（図９）。
【００２５】
図１０は、最終的に認識された２つの確定モデルを示している（サブモデルをＡｐｐ、ＤＢの各階層に展開した状態で示している）。即ち、ｈｔｔｐｓ１−ｉｉｏｐ１−ｄｂ１とｈｔｔｐｓ２−ｉｉｏｐ２−ｄｂ２はそれぞれ呼出関係にある。
【００２６】
以上、本発明の各階層におけるリクエストの呼出関係の対応付け方法を説明した。次に、このことをコンピュータ（図２に示す可視化サーバ１００）が処理する場合について処理フローとデータ例とを用いて説明する。図１１−図１４は処理フローを、図１５−図１８はデータ例を示すものである。
【００２７】
まず、図１１は全体の処理フローを示し、ステップＳ１００（以降、単にＳ１００と記す）においてポートミラーリング４０がキャプチャした各サーバのリクエストを取得し、リクエストログとしてリクエストログ記憶部１５０に記憶する。リクエストログのデータ例を図１５に示す。図に示すように各サーバから時系列に取得したリクエストがそのリクエストの開始時間と終了時間を含んで記憶される。例えば、１行目のｈｔｔｐｓ１はＷｅｂサーバから取得した暗号化されたリクエストで、Ｗｅｂサーバがｈｔｔｐｓ１を受け付け処理を開始時間した時間（時刻）はｈ１−ｓで、処理を終了して例えばクライアントに処理結果を送信した時間はｈ１−ｅである。
【００２８】
このリクエストログからＡｐｐとＤＢの階層のリクエストであるｉｉｏｐとｄｂとを抽出する（Ｓ１０１）。抽出したリクエストｉｉｏｐとリクエストｄｂの呼出関係（即ち、親子関係にある）を従来技術を用いて求め、この組み合わせをサブモデルとする。このサブモデルにはＩＤを付与して開始時間と終了時間と共にｓｕｂｍｏｄｅｌＬｉｓｔ１６１に登録する。サブモデルとしての開始と終了時間は、リクエストｉｉｏｐの開始と終了時間ということになる（Ｓ１０２）。
【００２９】
続いて、リクエストログからＷｅｂの階層のＨＴＴＰＳのリクエストを抽出し、開始と終了時間と共にｈｔｔｐｓＬｉｓｔ１６２に登録する（Ｓ１０３）。
【００３０】
ｓｕｂｍｏｄｅｌＬｉｓｔ１６１とｈｔｔｐｓＬｉｓｔ１６２のデータ例を図１６に示す。図１６（ａ）はｓｕｂｍｏｄｅｌＬｉｓｔ１６１のデータ例で、例えば、１行目のｓｕｂ１は開始と終了時間はそれぞれｓ１−ｓとｓ１−ｅで、リクエストｉｉｏｐ１とｄｂ１とから構成することを示している。また、図１６（ｂ）はｈｔｔｐｓＬｉｓｔ１６２の例で、例えば、１行目のｈｔｔｐｓ１は開始と終了時間はそれぞれｈ１−ｓとｈ１−ｅであることを示している。
【００３１】
ｓｕｂｍｏｄｅｌＬｉｓｔ１６１とｈｔｔｐｓＬｉｓｔ１６２のそれぞれに登録されている数（エントリ数）が「１」以上であれば「サブモデル／ＨＴＴＰＳマップ作成ルーチン」に入り、続いて「呼出関係確率算出ルーチン」、「確定モデル決定ルーチン」を経てリクエストであるｈｔｔｐｓ、ｉｉｏｐ、ｄｂの呼出関係の対応付けが決定される（Ｓ１０５−Ｓ１０７）。
【００３２】
次に、「サブモデル／ＨＴＴＰＳマップ作成ルーチン」について図１２を用いて説明する。先のＳ１０２で作成したｓｕｂｍｏｄｅｌＬｉｓｔ１６１からサブモデルを１つ取得する。続いて、Ｓ１０３で作成したｈｔｔｐｓＬｉｓｔ１６２からＨＴＴＰＳを１つ取得する（Ｓ２００、Ｓ２０１）。
【００３３】
取得したサブモデルの開始／終了時間とＨＴＴＰＳの開始／終了時間を比較し、
「ＨＴＴＰＳの開始時間＜サブモデルの開始時間」
且つ、
「ＨＴＴＰＳの終了時間＞サブモデルの終了時間」
を満足する場合に、サブモデルとＨＴＴＰＳのリクエストの組み合わせをｓｕｂ２ｈｔｔｐｓＭａｐ１６３に登録する。即ち、サブモデルが処理した時間はＨＴＴＰＳの処理した時間内にあるかどうかを判定し、時間内であれば呼出関係にある候補と見なしてｓｕｂ２ｈｔｔｐｓＭａｐ１６３に登録している（Ｓ２０２、Ｓ２０３）。
【００３４】
ｓｕｂ２ｈｔｔｐｓＭａｐ１６３の登録が終わると、ｈｔｔｐｓＬｉｓｔ１６２から次のＨＴＴＰＳを１つ取り出し、先のサブモデル（ｓｕｂ２ｈｔｔｐｓＭａｐ１６３に登録したサブモデル）と今回取り出したＨＴＴＰＳとの開始／終了時間をＳ２０２に示す比較を行う。これを、ｈｔｔｐｓＬｉｓｔ１６２に登録された総てのＨＴＴＰＳに対して行う。従って、１つのサブモデルに対して複数のＨＴＴＰＳとの組み合わせが登録される場合がある。
【００３５】
Ｓ２００で取り出した１つのサブモデルと登録された総てのＨＴＴＰＳとの開始／終了時間の比較が終わったら、ｓｕｂｍｏｄｅｌＬｉｓｔ１６１から次のサブモデルを取り出し、同様の処理（Ｓ２０１−Ｓ２０４）を行う。ｓｕｂｍｏｄｅｌＬｉｓｔ１６１に登録された総てのサブモデルに対して上記の処理を行うと「サブモデル／ＨＴＴＰＳマップ作成ルーチン」は終了となる（Ｓ２０４、Ｓ２０５）。
【００３６】
「サブモデル／ＨＴＴＰＳマップ作成ルーチン」では、リクエスト間で呼出関係にあると考えられるサブモデルとＨＴＴＰＳの組み合わせをｓｕｂ２ｈｔｔｐｓＭａｐ１６３にリストアップした。「呼出関係確率算出ルーチン」ではこのｓｕｂ２ｈｔｔｐｓＭａｐ１６３を用いて、リストアップされたサブモデルのＨＴＴＰＳに対する呼出関係の確率を求めることを行う。
【００３７】
図１３は、「呼出関係確率算出ルーチン」の処理フローを示し、まずＳ３００でｓｕｂ２ｈｔｔｐｓＭａｐ１６３に含まれるサブモデルから、異なるサブモデル名のサブモデルを抽出し、ｓｕｂＬｉｓｔ１６４に登録する。例えば、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３にｎ個のサブモデルが登録されており、その内異なるサブモデル名のサブモデルがｍ個（当然ながらｍ＜＝ｎである）あるとしたら、このｍ個のサブモデルが抽出されｓｕｂＬｉｓｔ１６４に登録されることになる。
【００３８】
次に、ｓｕｂＬｉｓｔ１６４から１つのサブモデルを取り出し、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３にある同一名のサブモデルの個数を計測する。計測した個数を「ｃｏｕｎｔ」とすると、「１００÷ｃｏｕｎｔ」を確率として求め、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３の該当するサブモデル名の確率フィールドに記録する（データ例を後述するが、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３はサブモデル名をキーとして組み合わせ候補であるＨＴＴＰＳ名および確率のフィールドを備えているものとする）。ｓｕｂ２ｈｔｔｐｓＭａｐ１６３に例えばｓｕｂ１のサブモデルが１個登録されていたとすれば、確率は「１００％」となり、２個登録されていたとすれば確率は「５０％」となる。２個登録の場合には、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３の２カ所のｓｕｂ１の確率フィールドに「５０％」を記録することになる（Ｓ３０１−Ｓ３０３）。
【００３９】
ｓｕｂＬｉｓｔ１６４のサブモデルの総てに対して確率を求め、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３に記録したら終了となる（Ｓ３０４）。
【００４０】
図１７にｓｕｂ２ｈｔｔｐｓＭａｐ１６３とｓｕｂＬｉｓｔ１６４のデータ例を示す。図１７（ａ）は、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３のデータ例を示し、サブモデル名、ＨＴＴＰＳ名および確率の各フィールドで構成する。例えば、１行目のサブモデル名ｓｕｂ１はｈｔｔｐｓ１と呼出関係にあると考えられ、その確率は５０％であることを示している。図１７（ｂ）はｓｕｂＬｉｓｔ１６４を示し、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３にエントリされたサブモデルをリストアップしたものである。
【００４１】
次に「確定モデル決定ルーチン」について図１４を用いて説明する。Ｓ４００において、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３から確率が最大を示すサブモデルとＨＴＴＰＳの組み合わせを抽出し、ｍａｘｐｏｓＭａｐ１６５に記録する。確率が最大を示す組み合わせは１つ以上ありこれらをｍａｘｐｏｓＭａｐ１６５に記録することになる（Ｓ４００）。
【００４２】
続いて、ｍａｘｐｏｓＭａｐ１６５に記録されたそれぞれのサブモデルについて、開始時間の最も早い組み合わせのエントリ以外を削除（これはサブモデルがＨＴＴＰＳから呼び出されたと思われる順に処理を行うものである）し、そして残ったｍａｘｐｏｓＭａｐ１６５のエントリに対してＨＴＴＰＳのｓｕｂ２ｈｔｔｐｓＭａｐ１６３での出現回数が最小となるエントリ以外を削除する。これはサブモデルを呼び出すようなＨＴＴＰＳ通信は、呼び出し後はすぐに帰った結果を処理（画面に出力）する（＝処理時間がサブモデルの処理時間と大きくは違わない）という考えによるものである。多数のサブモデルを含んでいるＨＴＴＰＳ通信は着目しているサブモデルの親ではない可能性が高いので、この時点では着目しているサブモデルの親となりうるＨＴＴＰＳ通信は複数存在し得る。更に、残ったｍａｘｐｏｓＭａｐ１６５のエントリに対してサブモデルとＨＴＴＰＳの処理時間（開始から終了までの時間）の差が最小となるエントリ以外を削除する（Ｓ４０１−Ｓ４０３）。
【００４３】
上記のＳ４０１からＳ４０２の処理により、ｍａｘｐｏｓＭａｐ１６５には１組のエントリが残ることなり、この組み合わせを確定モデルに決定する。確定モデルをｍｏｄｅｌＬｉｓｔ１６６に記憶する（Ｓ４０４）。
【００４４】
ｓｕｂ２ｈｔｔｐｓＭａｐ１６３から、確定モデルとなったサブモデルとＨＴＴＰＳを含む組み合わせのエントリを削除する。そして、ｓｕｂ２ｈｔｔｐｓＭａｐ１６３のエントリが「０」でなければ、Ｓ４００に戻り次の確定モデルを決定する。ｓｕｂ２ｈｔｔｐｓＭａｐ１６３のエントリが「０」となった時点で終了となる。
【００４５】
ｍｏｄｅｌＬｉｓｔ１６６に記憶されたサブモデルとＨＴＴＰＳのリクエストの組み合わせが呼出関係にある。なお、サブモデルはｓｕｂｍｏｄｅｌｌｉｓｔ１６１からサブモデルを構成するリクエストに展開でき、各階層に跨がるリクエスト間の対応付けができたことになる。
【図面の簡単な説明】
【００４６】
【図１】本発明に係わる全体の構成例である。
【図２】リクエスト対応付け装置の構成例である。
【図３】リクエストログに記憶されたリクエスト例である。
【図４】暗号化されていないＡｐｐ層とＤＢ層との呼出関係の対応付け例である。
【図５】サブモデルへの置き換え例である。
【図６】各サブモデルの親となり得るHTTPSの確率の算出例である。
【図７】確定モデルの決定例である。
【図８】残された候補で確率の再計算例である。
【図９】次の確定モデルの決定例である。
【図１０】最終的に認識された確定モデル例である。
【図１１】全体の処理フロー例である。
【図１２】サブモデル/HTTPSマップ作成ルーチンの処理フローである。
【図１３】呼出関係確率算出ルーチンの処理フローである。
【図１４】確定モデル決定ルーチンの処理フローである。
【図１５】リクエストログのデータ例である。
【図１６】ｓｕｂｍｏｄｅｌＬｉｓｔとｈｔｔｐｓＬｉｓｔのデータ例である。
【図１７】ｓｕｂ２ｈｔｔｐｓＭａｐとｓｕｂＬｉｓｔのデータ例である。
【図１８】ｍａｘｐｏｓＭａｐとｍｏｄｅｌＬｉｓｔのデータ例である。
【図１９】ＷＥＢ３階層システムの例である。
【図２０】HTTPS通信におけるURLとパラメータである。
【図２１】従来手法の例である。
【図２２】従来手法が適用できない例である。
【符号の説明】
【００４７】
１０    ＷＥＢ３階層
１１    Ｗｅｂサーバ
１２    Ａｐｐサーバ
１３    ＤＢサーバ
２０    ネットワーク
３０    クライアント端末
３１    クライアント端末
３２    クライアント端末
３３    クライアント端末
４０    ポートミラーリング
５０    可視化システム
１００  可視化サーバ
１０１  可視化クライアント端末
１１０  ＣＰＵ
１２０  主メモリ
１３０  リクエスト対応付けプログラム
１３１  リクエスト取得部
１３２  サブモデルリスト作成部
１３３  ＨＴＴＰＳリクエスト作成部
１３４  呼出関係確定部
１４０  入出力制御部
１５０  リクエストログ記憶部
１６０  Ｌｉｓｔ／Ｍａｐ記憶部
１６１  ｓｕｂｍｏｄｅｌ
１６２  ｈｔｔｐｓＬｉｓｔ
１６３  ｓｕｂ２ｈｔｔｐｓＭａｐ
１６４  ｓｕｂＬｉｓｔ
１６５  ｍａｘｐｏｓＭａｐ
１６６  ｍｏｄｅｌＬｉｓｔ
１７０  通信制御部
【図１】
2010123022.tif 000003
【図２】
2010123022.tif 000004
【図３】
2010123022.tif 000005
【図４】
2010123022.tif 000006
【図５】
2010123022.tif 000007
【図６】
2010123022.tif 000008
【図７】
2010123022.tif 000009
【図８】
2010123022.tif 000010
【図９】
2010123022.tif 000011
【図１０】
2010123022.tif 000012
【図１１】
2010123022.tif 000013
【図１２】
2010123022.tif 000014
【図１３】
2010123022.tif 000015
【図１４】
2010123022.tif 000016
【図１５】
2010123022.tif 000017
【図１６】
2010123022.tif 000018
【図１７】
2010123022.tif 000019
【図１８】
2010123022.tif 000020
【図１９】
2010123022.tif 000021
【図２０】
2010123022.tif 000022
【図２１】
2010123022.tif 000023
【図２２】
2010123022.tif 000024