JP2010097285A - システム分析支援プログラム、システム分析支援装置、およびシステム分析支援方法 - Google Patents

Abstract

【課題】レスポンスメッセージが存在しないリクエストメッセージについて、リクエスト時刻とレスポンス時刻との対応関係を構築することで、タイムアウトを含むトランザクションを把握すること。
【解決手段】対象システム内で受け渡されたメッセージ群のうち、レスポンスメッセージが存在しないリクエストメッセージを特定する。つぎに、そのリクエストメッセージの送信時刻と当該リクエストメッセージに対するその送信先のサーバでの実績処理時間とに基づいて、レスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定する。そして、その推定送信時刻とリクエストメッセージとを関連付けることで、レスポンスメッセージが存在しないリクエストメッセージについて、リクエスト時刻とレスポンス時刻との対応関係を構築する。
【選択図】図１

Description

この発明は、ネットワークシステムの稼働状況の分析を支援する技術に関する。

現在のＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）システムは、社会的なインフラを担う存在となっており、２４時間３６５日の安定稼働が欠かせない。また、ＩＴビジネスの成長にともない、継続的な安定稼働だけでなく、ＩＴシステムが提供できるサービスの質が問われるようになってきている。このため、エンドユーザが体験するサービスの質を、エンドユーザの視点から監視することが重要となる。

一方で、複数のアプリケーションが連携して動作するＩＴシステムでは、性能劣化や障害の原因を突き止めるために、各サーバの挙動だけでなくシステム全体の性能を観測、分析する必要がある。それ故に、大規模化、複雑化するＩＴシステムの稼働状況や性能問題（たとえば、負荷に対する性能不足）を的確に把握することが難しくなってきている。

従来において、ＩＴシステムの稼働状況を分析する各種技術が開示されている。たとえば、サービスごとに対象システム内で受け渡されるメッセージを解析してトランザクションモデルを生成し、対象システム全体の性能を観測、分析するシステム可視化技術がある。このシステム可視化技術では、リクエストメッセージとレスポンスメッセージとをペアとする表現形式のトランザクションモデルを用いる。このため、リクエストに対するレスポンスが存在することを前提として、トランザクションモデルの生成や対象システムの稼働状況の分析をおこなうこととなる。

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

しかしながら、対象システムで動作するアプリケーションは、一定時間経過してもレスポンスがない処理をタイムアウトとして検出してしまう。この場合、リクエストメッセージに対応するレスポンスメッセージが発行されず存在しない。したがって、従来手法のシステム可視化技術では、タイムアウトを含むトランザクションの処理状況を把握することが難しく、ひいては対象システムの稼働状況の分析精度の低下を招くという問題がある。

一方で、トランザクションの処理状況を把握するために、一定時間経過してもレスポンスがない処理をタイムアウトとして検出しない場合には、リクエストに対するレスポンスをユーザが待ち続けることになる。これでは、エンドユーザが体験する質を低下させてしまい、ひいては対象システムが提供できるサービスの質の低下を招くという問題がある。

この開示技術は、上述した従来技術による問題点を解消するため、タイムアウトを含むトランザクションの処理状況を的確に把握し、対象システムの稼働状況の分析精度の向上を図ることを目的とする。

上述した課題を解決し、目的を達成するため、この開示技術は、複数のサーバが連携して動作するネットワークシステム内で受け渡されたメッセージデータ群から、リクエストメッセージに対応するレスポンスメッセージを検索し、前記レスポンスメッセージが検索されなかった場合、前記リクエストメッセージに対する送信先のサーバでの実績処理時間を記憶するテーブルから実績処理時間を読み出して、前記リクエストメッセージに対する実績処理時間が経過しているか否かを、前記リクエストメッセージの送信時刻から判断し、前記実績処理時間が経過していると判断された場合、前記リクエストメッセージの送信時刻と前記実績処理時間とに基づいて、前記レスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定し、決定された推定送信時刻と前記リクエストメッセージとを関連付けて、関連付けられた関連付け結果を出力する。

この開示技術によれば、リクエスト先のサーバで実行される処理の実績処理時間を用いて、リクエストメッセージとペアとなる実際には存在しないレスポンスメッセージの推定送信時刻を補完することができる。

この開示技術によれば、タイムアウトを含むトランザクションの処理状況を的確に把握し、対象システムの稼働状況の分析精度の向上を図ることができるという効果を奏する。

以下に添付図面を参照して、このシステム分析支援プログラム、システム分析支援装置、およびシステム分析支援方法の好適な実施の形態を詳細に説明する。このシステム分析支援プログラム、システム分析支援装置、およびシステム分析支援方法では、レスポンスがない場合、リクエスト先のサーバでの実績処理時間からレスポンス時刻を補完し、リクエスト時刻とレスポンス時刻の対応関係を構築することで、タイムアウトを含むトランザクションの処理状況を分析する。

（本システム分析支援手法の概要）
まず、本システム分析支援手法の概要について説明する。以下において、最初に、従来手法の問題点を説明し、続いて、本技術によるその解決手法の概要を説明する。公知のシステム可視化技術では、（ａ）対象システム内で受け渡されたメッセージを分析して、業務サービスごとのトランザクションモデルを生成する。ここで、トランザクションモデルとは、業務サービスにかかるトランザクションの実行中に対象システム内で受け渡されるメッセージを定義するものである。

業務サービスとしては、たとえば、オンラインバンキングでの「入金」、「残高照会」、「送金」、「振り込み」などのサービスがある。たとえば、「入金」の業務サービスを提供する際に、対象システム内で受け渡されるメッセージを定義したものが「入金」トランザクションのトランザクションモデルとなる。

また、システム可視化技術では、（ｂ）対象システム内で受け渡されたメッセージとトランザクションモデルとのマッチングをおこなうことで、業務サービスごとの処理状況を分析する。たとえば、「入金」トランザクションのトランザクションモデルを用いて、「入金」サービスの提供時における対象システム内の各サーバでの処理時間などを分析する。

従来手法のトランザクションモデルは、リクエストメッセージとレスポンスメッセージとをペアとする表現形式となっている。したがって、従来手法では、リクエストメッセージとレスポンスメッセージとのメッセージペアを前提として、上述した（ａ）や（ｂ）をおこなうこととなる。

ところが、対象システム内で動作するアプリケーションの中には、一定時間経過してもレスポンスがない処理をタイムアウトとして検出するものがある。この場合、リクエストメッセージに対応するレスポンスメッセージが存在しないこととなり、従来手法では扱うことができない。

タイムアウトは、たとえば、負荷に対するサーバの性能不足や通信トラフィックの増大などが原因となって発生する。また、タイムアウトは、エンドユーザが体験する業務サービスの質に影響を及ぼし、頻繁に発生すると著しい質の低下につながる。それ故に、タイムアウトを含むトランザクションを的確に把握し、対象システムのキャパシティプランニングをおこなうことが重要となる。以下、一般的な３階層システムにおけるタイムアウトの発生状況について説明する。

図１は、一般的な３階層システムの模式図である。図１において、３階層システムは、クライアントサーバシステムを、Ｗｅｂ層、ＡＰ（アプリケーション）層、ＤＢ（データベース）層の３層に分割して構築されたシステムである。この３階層システムは、たとえば、オンラインバンキングの各種業務サービスを提供するシステムに用いられる。

従来手法により、上述した（ａ）や（ｂ）をおこなう場合、処理の呼出関係に基づく階層間のメッセージペアの入れ子関係を判断する。ここで、処理の呼出関係とは、上位階層（たとえば、Ｗｅｂ層）の処理が下位階層（たとえば、ＡＰ層）の処理を呼び出すが、その逆はないという関係である。

すなわち、上位階層のメッセージペアが下位階層のメッセージペアを包含していることが前提となる。ここでは、Ｗｅｂ層のリクエストメッセージ１０１とレスポンスメッセージ１０２との間に、ＡＰ層のリクエストメッセージ１０３とレスポンスメッセージ１０４とが挟まれることが前提となる。具体的には、各メッセージ１０１〜１０４の送信時刻Ｔ１，Ｔ２，Ｔ３，Ｔ４について、『Ｔ１＜Ｔ３』かつ『Ｔ４＜Ｔ２』という送信時刻の制約を満たす必要がある。この制約は、ＡＰ／ＤＢ層間でも同様に満たす必要がある。

ところが、図１の例では、リクエストメッセージ１０５に対応するレスポンスメッセージが一定時間経過してもないため、ＤＢ層のタイムアウトをＡＰ層が検出して処理を続行している。この場合、リクエストメッセージ１０５に対応するレスポンスメッセージが存在しないため、メッセージペアを前提とする送信時刻の制約を満たさない。それ故に、従来手法では上述した（ａ）や（ｂ）をおこなうことができない。これでは、タイムアウトを含むトランザクションの処理状況、すなわち、タイムアウトが発生した際の業務サービスの処理状況を把握することができない。

そこで、本手法では、まず、（１）対象システム内で受け渡されたメッセージ群のうち、レスポンスメッセージが存在しないリクエストメッセージを特定する。そして、（２）リクエスト先のサーバで実行される処理の実績処理時間を用いて、そのリクエストメッセージとペアとなる実際には存在しないレスポンスメッセージの推定送信時刻を補完する。

これにより、レスポンスメッセージが存在しないリクエストメッセージについても、リクエスト時刻とレスポンス時刻との対応関係を構築することができる。この結果、メッセージペアの送信時刻の制約を判断することが可能となり、リクエストメッセージ１０１からレスポンスメッセージ１０２までのタイムアウトを含むトランザクションの処理状況を把握することができる。

（ＩＴシステムのシステム構成）
つぎに、本実施の形態にかかるＩＴシステムのシステム構成について説明する。図２は、ＩＴシステムのシステム構成図である。図２において、ＩＴシステム２００は、システム分析支援装置２０１と、クライアント端末２０２と、Ｗｅｂサーバ２０３と、ＡＰサーバ２０４と、ＤＢサーバ２０５と、がインターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワーク２１０を介して接続されている。なお、図面の簡単化のため、クライアント端末２０２、Ｗｅｂサーバ２０３、ＡＰサーバ２０４およびＤＢサーバ２０５を、それぞれ１台のみ表記している。

ＩＴシステム２００は、プロトコルの階層構造が定義された３階層システム（図１参照）である。具体的には、Ｗｅｂ層には、クライアント端末２０２とＷｅｂサーバ２０３との通信に用いられるプロトコルであるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）が定義されている。

また、ＡＰ層には、Ｗｅｂサーバ２０３とＡＰサーバ２０４との通信に用いられるプロトコルであるＩＩＯＰ（Ｉｎｔｅｒｎｅｔ Ｉｎｔｅｒ−ＯＲＢ Ｐｒｏｔｏｃｏｌ）が定義されている。また、ＤＢ層には、ＡＰサーバ２０４とＤＢサーバ２０５との通信に用いられるプロトコル（データベース言語）であるＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）が定義されている。

ここで、システム分析支援装置２０１は、ＩＴシステム２００内で受け渡されるメッセージをキャプチャする機能を有する。また、システム分析支援装置２０１は、ＩＴシステム２００の稼働状況の分析を支援する機能を有する。Ｗｅｂサーバ２０３、ＡＰサーバ２０４およびＤＢサーバ２０５は、クライアント端末２０２からのリクエストに応じて、オンラインバンキングサービスなどの業務サービスを提供する。

（キャプチャ機能の概要）
つぎに、本実施の形態にかかるシステム分析支援装置２０１が有するキャプチャ機能について説明する。図３は、キャプチャ機能の概要を示す説明図である。図３には、ＩＴシステム２００内で受け渡される各種プロトコル（ＨＴＴＰ、ＩＩＯＰ、ＳＱＬ）のパケットＰ１〜Ｐ３をキャプチャする機能の概要が示されている。

ここで、システム分析支援装置２０１、クライアント端末２０２、Ｗｅｂサーバ２０３、ＡＰサーバ２０４およびＤＢサーバ２０５は、ネットワーク２１０内に設けられたスイッチＳ１〜Ｓ３の個別のポートに接続されている。これらスイッチＳ１〜Ｓ３は、自身を通過するデータをミラーリングする機能を有している。ミラーリングとは、あるポートに出力されるデータと同じデータを、他のポートからも出力する機能である。

ここでは、Ｗｅｂサーバ２０３、ＡＰサーバ２０４およびＤＢサーバ２０５が接続されたポートのミラーリング先として、システム分析支援装置２０１が接続されたポートが指定されている。このため、各サーバ宛のパケットは、宛先となるサーバに入力されるとともにシステム分析支援装置２０１にも入力される。

たとえば、クライアント端末２０２からのリクエストに応じて、Ｗｅｂサーバ２０３、ＡＰサーバ２０４およびＤＢサーバ２０５が連動してサービスを提供する場合を想定する。この場合、まず、クライアント端末２０２からＷｅｂサーバ２０３に対してパケットＰ１が送信される。

このとき、パケットＰ１と同じ内容のパケットＰ１が、システム分析支援装置２０１に入力される。つぎに、Ｗｅｂサーバ２０３からＡＰサーバ２０４へパケットＰ２が送信されると、パケットＰ２と同じ内容のパケットＰ２が、システム分析支援装置２０１に入力される。さらに、ＡＰサーバ２０４からＤＢサーバ２０５へパケットＰ３が送信されると、パケットＰ３と同じ内容のパケットＰ３が、システム分析支援装置２０１に入力される。

システム分析支援装置２０１に入力されたパケットＰ１〜Ｐ３は、スイッチＳ１〜Ｓ３に直接接続されたキャプチャ部３１０によって取得される。また、キャプチャ部３１０によって取得されたパケットは、メッセージ解析部３２０によってメッセージ解析される。なお、メッセージ解析については従来技術のため説明を省略する。

解析された解析結果は、たとえば、図５に示すメッセージバッファ５００に記憶される。また、システム分析支援装置２０１は、図６を用いて後述する補完データ６００−１〜６００−ｍを記憶する補完データテーブル６００、および図８を用いて後述するペア情報８００−１〜８００−ｎを記憶するペアリングテーブル８００にアクセス可能である。

このキャプチャ機能によれば、運用中のサービスに影響を及ぼすことなく、ＩＴシステム２００内で受け渡されたメッセージを収集することができる。なお、キャプチャ部３１０は、任意のパケット（たとえば、同期型メッセージを構成するパケット）のみをキャプチャしてもよい。さらに、スイッチＳ１〜Ｓ３において必要なデータのみを選択してミラーリングしてもよい。

（システム分析支援装置のハードウェア構成）
つぎに、本実施の形態にかかるシステム分析支援装置２０１のハードウェア構成について説明する。図４は、システム分析支援装置のハードウェア構成を示すブロック図である。図４において、システム分析支援装置２０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）４０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４０３と、磁気ディスクドライブ４０４と、磁気ディスク４０５と、光ディスクドライブ４０６と、光ディスク４０７と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）４０８と、を備えている。また、各構成部はバス４００によってそれぞれ接続されている。

ここで、ＣＰＵ４０１は、システム分析支援装置２０１の全体の制御を司る。ＲＯＭ４０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ４０３は、ＣＰＵ４０１のワークエリアとして使用される。磁気ディスクドライブ４０４は、ＣＰＵ４０１の制御にしたがって磁気ディスク４０５に対するデータのリード／ライトを制御する。磁気ディスク４０５は、磁気ディスクドライブ４０４の制御で書き込まれたデータを記憶する。

光ディスクドライブ４０６は、ＣＰＵ４０１の制御にしたがって光ディスク４０７に対するデータのリード／ライトを制御する。光ディスク４０７は、光ディスクドライブ４０６の制御で書き込まれたデータを記憶したり、光ディスク４０７に記憶されたデータをコンピュータに読み取らせたりする。

インターフェース（以下、「Ｉ／Ｆ」と略する。）４０８は、通信回線を通じてＬＡＮ、ＷＡＮ、インターネットなどのネットワーク２１０に接続され、このネットワーク２１０を介して他の装置（たとえば、スイッチＳ１〜Ｓ３）に接続される。そして、Ｉ／Ｆ４０８は、ネットワーク２１０と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ４０８には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

ここでは、システム分析支援装置２０１のハードウェア構成について説明したが、クライアント端末２０２、Ｗｅｂサーバ２０３、ＡＰサーバ２０４およびＤＢサーバ２０５についても同様のハードウェア構成で実現することができる。なお、以降において、特に指定する場合を除いて、Ｗｅｂサーバ２０３、ＡＰサーバ２０４およびＤＢサーバ２０５を単に「サーバ２０３〜２０５」と表記する。

（メッセージバッファの記憶内容）
つぎに、図４に示した磁気ディスク４０５、光ディスク４０７などの記憶領域に構築されるメッセージバッファの記憶内容について説明する。図５は、メッセージバッファの記憶内容の一例を示す説明図である。なお、図面では、メッセージバッファに記憶されているメッセージデータの一部を抜粋して表示している。

図５において、メッセージバッファ５００は、メッセージの送信時刻、メッセージＩＤ、プロトコル、メッセージ種別およびオブジェクトといったフィールドを有する。各フィールドに情報を設定することで、ＩＴシステム２００内で受け渡されたメッセージデータ５００−１〜５００−５がレコードとして記憶されることとなる。

ここで、送信時刻とは、クライアント端末２０２またはサーバ２０３〜２０５から送信されたメッセージの送信時刻である。このメッセージには、リクエストメッセージとレスポンスメッセージとが含まれている。リクエストメッセージとは、所定の処理やデータの提供などを要求するためのメッセージである。レスポンスメッセージとは、リクエストメッセージの要求に対する応答のためのメッセージである。

また、メッセージＩＤとは、メッセージを識別する識別子である。ここでは、対応関係を有するメッセージペアに、同一のメッセージＩＤが付与されている。したがって、図７を用いて後述する機能部（たとえば、選択部７０２、検索部７０３）が、このメッセージＩＤを参照することで、対応関係を有するリクエストメッセージとレスポンスメッセージとを認識することができる。

また、プロトコルとは、メッセージの受け渡しに用いられたプロトコルである。したがって、機能部が、このプロトコルを参照することで、メッセージの送信元および送信先のクライアント端末２０２またはサーバ２０３〜２０５を認識することができる。また、メッセージ種別とは、リクエストメッセージまたはレスポンスメッセージを特定する情報である。また、オブジェクトとは、サーバ２０３〜２０５がリクエストメッセージを受信してからレスポンスメッセージを送信するまでに実行する単一または複数の処理である。

ここで、メッセージデータ５００−２を例に挙げると、機能部が、各フィールドに設定された情報を参照することで、クライアント端末２０１からＷｅｂサーバ２０３に送信されたリクエストメッセージＭ１を認識することができる。なお、メッセージバッファ５００は、たとえば、メッセージ解析部３２０（図３参照）から送られてくるメッセージデータを、古い順に取り出すＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ，Ｆｉｒｓｔ Ｏｕｔ）構造となっている。

（補完データテーブルの記憶内容）
つぎに、システム分析支援装置２０１がアクセス可能な補完データテーブルの記憶内容について説明する。図６は、補完データテーブルの記憶内容の一例を示す説明図である。図６において、補完データテーブル６００は、オブジェクト名、実行回数、平均処理時間、最大処理時間および標準偏差といったフィールドを有する。各フィールドに情報を設定することで、補完データ６００−１〜６００−ｍがレコードとして記憶されることとなる。

ここで、オブジェクト名とは、リクエストメッセージに対するその送信先のサーバ２０３〜２０５で実行されるオブジェクトを識別する名称である。ここでは、各種業務サービスの提供時に実行されるオブジェクトの処理内容がオブジェクト名となっている。また、実行回数とは、サーバ２０３〜２０５で実行されたオブジェクトの実行回数である。また、平均処理時間および最大処理時間とは、リクエストメッセージの送信先のサーバで実行されたオブジェクトの実績処理時間である。

具体的には、平均処理時間とは、オブジェクトの実行にかかるサーバ２０３〜２０５での平均処理時間である。また、最大処理時間とは、オブジェクトの実行にかかるサーバ２０３〜２０５での最大処理時間である。また、標準偏差とは、オブジェクトの実行にかかるサーバ２０３〜２０５での処理時間のばらつき度合を示す指標である。

ここで、補完データ６００−２を例に挙げると、図７を用いて後述する機能部（たとえば、更新部７０８）が、各フィールドに設定された情報を参照することで、オブジェクト「ＡＢＣ」の実行回数Ｃ２、平均処理時間Ｔ２_ave、最大処理時間Ｔ２_maxおよび標準偏差σ２を認識することができる。なお、補完データテーブル６００のレコード内容は、ＩＴシステム２００の運用中に逐次更新される。また、この補完データテーブル６００は、たとえば、システム分析支援装置２０１の磁気ディスク４０５、光ディスク４０７などの記憶領域に構築されてもよく、また、外部のコンピュータ装置に構築されてもよい。

（システム分析支援装置の機能的構成）
つぎに、本実施の形態にかかるシステム分析支援装置２０１の機能的構成について説明する。図７は、システム分析支援装置の機能的構成を示すブロック図である。図７において、システム分析支援装置２０１は、取得部７０１と、選択部７０２と、検索部７０３と、判断部７０４と、決定部７０５と、算出部７０６と、関連付け部７０７と、更新部７０８と、出力部７０９と、を含む構成である。

この制御部となる機能（取得部７０１〜出力部７０９）は、具体的には、たとえば、図４に示したＲＯＭ４０２、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶領域に記憶されたプログラムをＣＰＵ４０１に実行させることにより、または、Ｉ／Ｆ４０８により、その機能を実現する。

まず、取得部７０１は、対象システム内で受け渡されたメッセージデータを取得する機能を有する。ここで、対象システムとは、稼働状況の分析対象であり、複数のサーバが連携して動作するネットワークシステム（たとえば、ＩＴシステム２００）である。また、対象システム内で受け渡されたメッセージデータとは、対象システム内のコンピュータ装置間で送受信されたメッセージのログデータである。このメッセージデータには、たとえば、メッセージの送信時刻、メッセージＩＤ、プロトコル、メッセージ種別およびオブジェクトなどが含まれている。

具体的には、たとえば、取得部７０１が、メッセージ解析部３２０によって解析されたメッセージデータを取得してもよい。また、取得部７０１が、外部のコンピュータ装置からメッセージデータをＩ／Ｆ４０８を介して受信してもよい。取得されたメッセージデータは、たとえば、図５に示したメッセージバッファ５００に記憶される。

選択部７０２は、取得されたメッセージデータ群から任意のリクエストメッセージを選択する機能を有する。具体的には、たとえば、選択部７０２が、メッセージバッファ５００に記憶されたメッセージデータ５００−１〜５００−５の中から、メッセージ種別「リクエスト」を手掛かりに、任意のリクエストメッセージを選択する。選択された選択結果は、図４に示したＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶領域に記憶される。

検索部７０３は、選択されたリクエストメッセージに対応するレスポンスメッセージをメッセージデータ群から検索する機能を有する。具体的には、たとえば、検索部７０３が、メッセージデータ５００−１〜５００−５の中から、メッセージＩＤとメッセージ種別を手掛かりに、リクエストメッセージと同一メッセージＩＤのレスポンスメッセージを検索する。

ここで、選択部７０２によってメッセージＩＤ「Ｍ２」のリクエストメッセージ（以下、単に「リクエストメッセージＭ２」と表記する）が選択されたとする。この場合、検索部７０３が、メッセージデータ５００−１〜５００−５の中から、メッセージＩＤ「Ｍ２」かつメッセージ種別「レスポンス」のメッセージを検索する。ここでは、レスポンスメッセージＭ２が検索される。

また、選択部７０２によってリクエストメッセージＭ３が選択されたとする。この場合、検索部７０３が、メッセージデータ５００−１〜５００−５の中から、メッセージＩＤ「Ｍ３」かつメッセージ種別「レスポンス」のメッセージを検索する。ここでは、該当するメッセージは検索されない。なお、検索された検索結果は、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶領域に記憶される。

判断部７０４は、レスポンスメッセージが検索されなかった場合、リクエストメッセージの送信時刻から、テーブルに記憶されているリクエストメッセージに対する実績処理時間が経過しているか否かを判断する機能を有する。ここで、テーブルとは、たとえば、図６に示した補完データテーブル６００である。

また、実績処理時間とは、図６で説明したように、たとえば、リクエストメッセージの送信先のサーバで実行されたオブジェクトの処理時間である、平均処理時間や最大処理時間などである。ここでは特に、補完データテーブル６００に記憶されているリクエストメッセージに対するその送信先のサーバ２０３〜２０５での最大処理時間を用いる。

また、リクエストメッセージの送信時刻から実績処理時間が経過しているか否かを判断する基準時刻は、メッセージバッファ５００に記憶されている最新のメッセージデータの送信時刻としてもよい。すなわち、判断部７０４が、最新のメッセージデータ５００−５の送信時刻ｔ５が、リクエストメッセージの送信時刻から最大処理時間後の時刻を経過しているか否かを判断してもよい。また、システム分析支援装置２０１内部で計時されている現在時刻を基準時刻としてもよい。

なお、補完データテーブル６００が初期化された状態では、各オブジェクトの実行にかかる実績処理時間が記憶されていない。この場合、予め設定されている初期値を実績処理時間として用いてもよい。初期値には、たとえば、リクエストメッセージの送信元のサーバ固有に設定されているタイムアウト時間を用いることができる。

ここで、判断処理の具体例として、リクエストメッセージＭ３に対応するレスポンスメッセージＭ３が検索されなかった場合を説明する。ただし、判断対象となる実績処理時間として、リクエストメッセージＭ３に対するその送信先のサーバでの最大処理時間を用いる。

この場合、まず、判断部７０４が、補完データテーブル６００にアクセスして、補完データ６００−１〜６００−ｍのオブジェクト名を参照し、リクエストメッセージＭ３の最大処理時間Ｔ３_maxを読み出す。具体的には、判断部７０４が、リクエストメッセージＭ３のオブジェクト「ＳＥＬＥＣＴ ｕｉｄ ｆｒｏｍ ｔｂｌ」を手掛かりに、最大処理時間Ｔ３_maxを読み出す。

つぎに、判断部７０４が、メッセージデータ５００−１〜５００−５の送信時刻を参照して、最新のメッセージデータ５００−５の送信時刻ｔ５を特定する。そして、判断部７０４が、この送信時刻ｔ５が、リクエストメッセージＭ３の送信時刻ｔ４に最大処理時間Ｔ３_maxを加算した時刻「ｔ４＋Ｔ３_max」を経過しているか否かを判断する。

ここで、送信時刻ｔ５が時刻「ｔ４＋Ｔ３_max」を経過している場合とは、リクエストメッセージＭ３に対応するレスポンスメッセージがない、すなわち、リクエストメッセージＭ３の送信元のＡＰサーバ２０４がタイムアウト処理を実行したことを意味している。なお、判断された判断結果は、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶領域に記憶される。

決定部７０５は、実績処理時間が経過していると判断された場合、リクエストメッセージに対応するレスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定する機能を有する。具体的には、たとえば、決定部７０５が、リクエストメッセージの送信時刻とリクエストメッセージに対するその送信先のサーバでの実績処理時間とに基づいて推定送信時刻を決定する。

より具体的には、たとえば、決定部７０５が、リクエストメッセージの送信時刻に、リクエストメッセージに対するその送信先のサーバでの平均処理時間または最大処理時間を加算した時刻を推定送信時刻に決定する。決定された決定結果は、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶領域に記憶される。

すなわち、リクエストメッセージに対応するレスポンスメッセージがない場合は、送信先のサーバでの実績処理時間を用いて、実際には存在しないレスポンスメッセージの送信時刻を補完する。ここで、決定処理の具体例として、リクエストメッセージＭ３に対応するレスポンスメッセージの推定送信時刻を、平均処理時間を用いて決定する場合を説明する。

この場合、まず、決定部７０５が、補完データテーブル６００にアクセスして、リクエストメッセージＭ３の平均処理時間Ｔ３_aveを読み出す。そして、決定部７０５が、リクエストメッセージＭ３の送信時刻ｔ４に平均処理時間Ｔ３_aveを加算することで、レスポンスメッセージの推定送信時刻「ｔ４＋Ｔ３_ave」を決定する。

この推定送信時刻「ｔ４＋Ｔ３_ave」は、ＡＰサーバ２０４からのリクエストメッセージＭ３に対して、ＤＢサーバ２０５からＡＰサーバ２０４に送信されるべきレスポンスメッセージＭ３の推定送信時刻である。これにより、リクエストメッセージＭ３に対応する実際には存在しないレスポンスメッセージＭ３の推定送信時刻を補完することができる。

また、推定送信時刻の補完に用いる時間を、リクエストメッセージに対するサーバでの実績処理時間に関する統計情報から求めることとしてもよい。ここで、統計情報とは、オブジェクトの実行にかかるサーバでの処理時間の平均処理時間、標準偏差、分散、中央値などである。

具体的には、算出部７０６は、判断部７０４によって実績処理時間が経過していると判断された場合、リクエストメッセージに対するその送信先のサーバでの推定処理時間を算出する機能を有する。この場合、決定部７０５は、リクエストメッセージの送信時刻に推定処理時間を加算した時刻を、レスポンスメッセージの推定送信時刻に決定してもよい。

より具体的には、たとえば、算出部７０６が、送信先のサーバでの平均処理時間に、処理時間のばらつきを示す標準偏差の定数倍（たとえば、３倍）を加算した時間を、サーバでの推定処理時間として算出することとしてもよい。算出された算出結果は、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶領域に記憶される。

ここで、算出処理の具体例として、リクエストメッセージＭ３に対応するレスポンスメッセージＭ３の推定処理時間を算出する場合を説明する。この場合、まず、算出部７０６が、補完データテーブル６００にアクセスして、オブジェクト名を手掛かりに、リクエストメッセージＭ３の平均処理時間Ｔ３_aveと標準偏差σ３を読み出す。

そして、算出部７０６が、平均処理時間Ｔ３_aveに標準偏差σ３の３倍を加算することで、ＤＢサーバ２０５での推定処理時間「Ｔ３_ave＋３σ３」を算出する。この場合、決定部７０５が、たとえば、リクエストメッセージＭ３の送信時刻ｔ４に推定処理時間「Ｔ３_ave＋３σ３」を加算することで、レスポンスメッセージＭ３の推定送信時刻「ｔ４＋（Ｔ３_ave＋３σ３）」を決定する。これにより、レスポンスメッセージＭ３の推定送信時刻を、オブジェクト「ＳＥＬＥＣＴ ｕｉｄ ｆｒｏｍ ｔｂｌ」の実行にかかるＤＢサーバ２０５での処理時間の統計的なばらつきを考慮して補完することができる。

関連付け部７０７は、決定された推定送信時刻とリクエストメッセージとを関連付ける機能を有する。具体的には、たとえば、関連付け部７０７が、リクエストメッセージのメッセージＩＤ、プロトコル、オブジェクト名および送信時刻と、実際には存在しないレスポンスメッセージの推定送信時刻とを関連付ける。これにより、レスポンスメッセージが存在しないリクエストメッセージについて、リクエスト時刻とレスポンス時刻との対応関係を構築することができる。

さらに、関連付け部７０７は、対応関係を有するリクエストメッセージとレスポンスメッセージとを関連付けることとしてもよい。ここで、対応関係を有するメッセージペアは、たとえば、検索部７０３が、メッセージデータ群から選択されたリクエストメッセージに対応するレスポンスメッセージを、メッセージデータ群から検索することで特定してもよい。

また、検索部７０３が、メッセージデータ群から選択されたレスポンスメッセージに対応するリクエストメッセージを、メッセージデータ群から検索することで特定してもよい。なお、関連付けられた関連付け結果は、新たなレコードとして後述の図８に示すペアリングテーブル８００に登録される。

更新部７０８は、テーブルに記憶されているリクエストメッセージに対するその送信先のサーバでの実績処理時間を更新する機能を有する。具体的には、たとえば、更新部７０８が、関連付けられたリクエストメッセージの送信時刻とレスポンスメッセージの送信時刻とに基づいて、そのリクエストメッセージに対する実績処理時間を更新する。

より具体的には、たとえば、まず、更新部７０８が、レスポンスメッセージの送信時刻からリクエストメッセージの送信時刻を差し引くことで、サーバでの処理時間を算出する。そして、更新部７０８が、その処理時間を用いて、補完データテーブル６００に記憶されている平均処理時間や最大処理時間を更新する。

更新部７０８による更新処理は、たとえば、対応関係を有するリクエストメッセージとレスポンスメッセージとが関連付けられると、その都度実行される。これにより、各オブジェクトの実行にかかる実績処理時間を、ＩＴシステム２００の稼働状況に合わせて逐次更新することができる。なお、更新処理の具体的な処理内容は図９を用いて後述する。

ここで、ペアリングテーブルの記憶内容について説明する。図８は、ペアリングテーブルの記憶内容の一例を示す説明図である。図８において、ペアリングテーブル８００は、ペアＩＤ、補完フラグ、メッセージＩＤ、プロトコル、オブジェクト名、リクエスト時刻およびレスポンス時刻といったフィールドを有する。各フィールドに情報を設定することで、ペア情報８００−１〜８００−ｎがレコードとして記憶されることとなる。

ここで、ペアＩＤとは、リクエストとレスポンスとのペアを識別する識別子である。また、補完フラグとは、レスポンスメッセージが存在しないペアを識別するためのフラグである。ここでは、レスポンスメッセージが存在しないペア、すなわち、レスポンスメッセージの送信時刻が補完されたペアの補完フラグが「ＯＮ」となっている。

また、オブジェクト名とは、オブジェクトを識別するための名称である。また、リクエスト時刻とは、リクエストメッセージの送信時刻である。また、レスポンス時刻とは、レスポンスメッセージが送信された送信時刻または推定送信時刻である。

たとえば、ペア情報８００−１の各フィールドに設定された情報を参照することで、オブジェクト「ＡＢＣ」のリクエスト時刻ｔ３とレスポンス時刻ｔ５との対応関係を認識することができる。さらに、プロトコル「ＩＩＯＰ」からＷｅｂサーバ２０３とＡＰサーバ２０４との間でメッセージが受け渡されたことを認識することができる。

また、ペア情報８００−２の各フィールドに設定された情報を参照することで、オブジェクト「ＳＥＬＥＣＴ ｕｉｄ ｆｒｏｍ ｔｂｌ」のリクエスト時刻ｔ４とレスポンス時刻「ｔ４＋Ｔ３_ave」との対応関係を認識することができる。さらに、プロトコル「ＳＱＬ」からＡＰサーバ２０４とＤＢサーバ２０５との間でメッセージが受け渡されたことを認識することができる。ただし、このレスポンス時刻「ｔ４＋Ｔ３_ave」は、実際には存在しないレスポンスメッセージＭ３の推定送信時刻である。

出力部７０９は、関連付けられた関連付け結果を出力する機能を有する。具体的には、たとえば、出力部７０９が、ペアリングテーブル８００のレコード内容をＩ／Ｆ４０８に出力する。出力形式としては、たとえば、ディスプレイへの表示、プリンタへの印刷出力、Ｉ／Ｆ４０８による外部装置への送信がある。また、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶領域に記憶することとしてもよい。

また、出力部７０９は、更新された更新後のリクエストメッセージに対するその送信先のサーバでの実績処理時間を出力することとしてもよい。具体的には、たとえば、出力部７０９が、更新後の補完データテーブル６００のレコード内容をＩ／Ｆ４０８に出力する。

（更新処理の処理内容）
ここで、更新部７０８による更新処理の具体的な処理内容について説明する。ここでは、対応関係を有するリクエストメッセージＭ１とレスポンスメッセージＭ１が関連付けられた結果、補完データテーブル６００に記憶されている補完データ６００−１を更新する場合を例に挙げる。図９は、更新処理の概要を示す説明図である。

まず、更新前において、オブジェクト「ＧＥＴ／ｍａｉｎ．ｊｓｐ」の実行にかかるＷｅｂサーバ２０３での平均処理時間Ｔ１_aveは１．１［ｓｅｃ］、最大処理時間Ｔ１_maxは１．１［ｓｅｃ］、標準偏差σ１は０である。ここで、対応関係を有するリクエストメッセージＭ１とレスポンスメッセージＭ１とが関連付けられたとする。ただし、レスポンスメッセージＭ１の送信時刻をｔ６とする。

この場合、更新部７０８が、レスポンスメッセージＭ１の送信時刻ｔ６からリクエストメッセージＭ２の送信時刻ｔ１を差し引くことで、オブジェクト「ＧＥＴ／ｍａｉｎ．ｊｓｐ」の実行にかかるＷｅｂサーバ２０３での処理時間を算出する。ここでは、処理時間が１．３［ｓｅｃ］であったとする。

つぎに、更新部７０８が、たとえば、下記式（１）を用いて、更新後の平均処理時間Ｔ１_aveを求める。ただし、Ｔｉ_aveは更新後の平均処理時間、Ｔ’ｉ_aveは更新前の平均処理時間、Ｃｉは更新前のオブジェクトの実行回数、Ｘはオブジェクトの実行にかかった今回の処理時間である（ｉ＝１，２，…，ｍ）。

Ｔｉ_ave＝（Ｔ’ｉ_ave×Ｃｉ＋Ｘ）／（Ｃｉ＋１） ・・・（１）

ここでは、更新後の平均処理時間Ｔ１_aveは『Ｔ１_ave＝（１．１×１＋１．３）／（１＋１）＝１．２』となる。この場合、更新部７０８が、補完データ６００−１の平均処理時間Ｔ１_aveを「１．１」から「１．２」に書き換える。

また、更新部７０８が、更新前の最大処理時間Ｔ１_maxとオブジェクトの実行にかかった今回の処理時間Ｘ（Ｘ＝１．３）を比較して、更新後の最大処理時間Ｔ１_maxを決定する。ここでは、処理時間Ｘが更新前の最大処理時間Ｔ１_maxよりも大きい。この場合、更新部７０８が、補完データ６００−１の最大処理時間Ｔ１_maxを「１．１」から「１．３」に書き換える。

また、更新部７０８が、更新後の平均処理時間Ｔ１_aveと処理時間Ｘとを用いて、更新後の標準偏差σ１を算出する。具体的には、更新後の平均処理時間Ｔ１_aveと処理時間Ｘとの差分を２乗し、その平方根をとることで、更新後の標準偏差σ１を算出する。ここでは、更新後の標準偏差σ１は「０．１」となる。この場合、更新部７０８が、補完データ６００−１の標準偏差σ１を「０」から「０．１」に書き換える。

この更新処理を、対応関係を有するメッセージペアが関連付けられると、その都度実行することで、補完データ６００−１〜６００−ｍの各フィールドに設定された情報を、ＩＴシステム２００の稼働状況に合わせて更新することができる。なお、図示は省略するが、標準偏差σｉを求めるために必要となる過去の処理時間は、たとえば、補完データテーブル６００に蓄積されている。

（システム分析支援装置のシステム分析支援処理手順）
つぎに、システム分析支援装置２０１のシステム分析支援処理手順について説明する。ここでは、メッセージデータの取得を契機に自動実行されるシステム分析支援処理手順について説明する。なお、システム分析支援処理の実行前において、補完データテーブル６００は初期化されている。具体的には、たとえば、実行回数、平均処理時間、最大処理時間のフィールドに初期値「０」が設定されている。

図１０および図１１は、システム分析支援処理手順の一例を示すフローチャートである。図１０のフローチャートにおいて、まず、取得部７０１は、メッセージデータを取得したか否かを判断する（ステップＳ１００１）。ここで、メッセージデータを取得するのを待って（ステップＳ１００１：Ｎｏ）、取得した場合（ステップＳ１００１：Ｙｅｓ）、メッセージデータをメッセージバッファ５００に記憶する（ステップＳ１００２）。

つぎに、検索部７０３は、取得されたメッセージデータのメッセージ種別を参照して、レスポンスメッセージか否かを判断する（ステップＳ１００３）。ここで、リクエストメッセージの場合（ステップＳ１００３：Ｎｏ）、図１１に示すステップＳ１１０１に移行する。

一方、レスポンスメッセージの場合（ステップＳ１００３：Ｙｅｓ）、検索部７０３は、そのレスポンスメッセージと同一メッセージＩＤのリクエストメッセージをメッセージバッファ５００の中から検索する（ステップＳ１００４）。そして、検索部７０３は、リクエストメッセージが検索されたか否かを判断する（ステップＳ１００５）。

ここで、リクエストメッセージが検索された場合（ステップＳ１００５：Ｙｅｓ）、関連付け部７０７は、リクエストメッセージとレスポンスメッセージを関連付ける（ステップＳ１００６）。そして、関連付け部７０７は、その関連付け結果をペア情報としてペアリングテーブル８００に登録する（ステップＳ１００７）。

このあと、更新部７０８は、補完データテーブル６００の記憶内容を更新する更新処理を実行し（ステップＳ１００８）、図１１に示すステップＳ１１０１に移行する。また、ステップＳ１００５において、リクエストメッセージが検索されなかった場合（ステップＳ１００５：Ｎｏ）、図１１に示すステップＳ１１０１に移行する。

図１１のフローチャートにおいて、まず、選択部７０２は、メッセージバッファ５００の中から選択されていない未選択のリクエストメッセージがあるか否かを判断する（ステップＳ１１０１）。ここで、未選択のリクエストメッセージがある場合（ステップＳ１１０１：Ｙｅｓ）、選択部７０２は、メッセージバッファ５００の中から、メッセージ種別「リクエスト」を手掛かりに、任意のリクエストメッセージを選択する（ステップＳ１１０２）。

そして、検索部７０３は、選択されたリクエストメッセージと同一メッセージＩＤのレスポンスメッセージをメッセージバッファ５００の中から検索する（ステップＳ１１０３）。このあと、検索部７０３は、レスポンスメッセージが検索されたか否かを判断する（ステップＳ１１０４）。

ここで、レスポンスメッセージが検索された場合（ステップＳ１１０４：Ｙｅｓ）、ステップＳ１１０１に戻る。一方、レスポンスメッセージが検索されなかった場合（ステップＳ１１０４：Ｎｏ）、判断部７０４は、補完データテーブル６００にアクセスして、ステップＳ１１０２において選択されたリクエストメッセージに対するその送信先のサーバでの最大処理時間を読み出す（ステップＳ１１０５）。

そして、判断部７０４は、メッセージバッファ５００に記憶されている最新のメッセージデータの送信時刻が、リクエストメッセージの送信時刻に最大処理時間を加算した時刻を経過しているか否かを判断する（ステップＳ１１０６）。ここで、経過していない場合（ステップＳ１１０６：Ｎｏ）、ステップＳ１１０１に戻る。

一方、経過している場合は（ステップＳ１１０６：Ｙｅｓ）、決定部７０５は、補完データテーブル６００にアクセスして、ステップＳ１１０２において選択されたリクエストメッセージに対するその送信先のサーバでの平均処理時間を読み出す（ステップＳ１１０７）。そして、決定部７０５は、リクエストメッセージの送信時刻に平均処理時間を加算した時刻を、レスポンスメッセージの推定送信時刻に決定する（ステップＳ１１０８）。

このあと、関連付け部７０７は、リクエストメッセージとレスポンスメッセージの推定送信時刻とを関連付ける（ステップＳ１１０９）。そして、関連付け部７０７は、その関連付け結果をペア情報としてペアリングテーブル８００に登録して（ステップＳ１１１０）、ステップＳ１１０１に戻る。そして、ステップＳ１１０１において、未選択のリクエストメッセージがない場合は（ステップＳ１１０１：Ｎｏ）、図１０に示したステップＳ１００１に戻る。

これにより、レスポンスメッセージが存在しないものを含むリクエストメッセージについて、リクエスト時刻とレスポンス時刻との対応関係を示すペア情報を収集することができる。また、メッセージデータの取得を契機に上述した一連の処理を実行することで、ＩＴシステム２００の運用中のリアルタイムでペア情報を収集することができる。

なお、上述した一連の処理を実行中の任意のタイミングでペア情報の出力指示を入力することで、ペアリングテーブル８００のレコード内容を任意の出力形式で出力することができる。

つぎに、図１０に示したステップＳ１００８における更新処理の具体的処理手順について説明する。なお、ここでは補完データテーブル６００が有するフィールドのうち、実行回数、平均処理時間、最大処理時間を更新する場合について説明する。図１２は、更新処理の具体的処理手順の一例を示すフローチャートである。

図１２のフローチャートにおいて、まず、更新部７０８は、図１０に示したステップＳ１００４において検索されたリクエストメッセージに対するその送信先のサーバでの処理時間を算出する（ステップＳ１２０１）。具体的には、図１０に示したステップＳ１００６において関連付けられたレスポンスメッセージの送信時刻からリクエストメッセージの送信時刻を差し引くことで上記処理時間を算出する。

このあと、補完データテーブル６００にアクセスして、該当レコードの平均処理時間、実行回数および上記処理時間を上記式（１）に代入することで、更新後の平均処理時間を算出する（ステップＳ１２０２）。なお、該当レコードとは、ステップＳ１００４において検索されたリクエストメッセージのオブジェクトから特定されるレコードである。そして、補完データテーブル６００の該当レコードの平均処理時間を、算出された平均処理時間に書き換える（ステップＳ１２０３）。

つぎに、補完データテーブル６００の該当レコードの最大処理時間が上記処理時間以上か否かを判断する（ステップＳ１２０４）。ここで、最大処理時間が上記処理時間未満の場合（ステップＳ１２０４：Ｎｏ）、該当レコードの最大処理時間を上記処理時間に書き換える（ステップＳ１２０５）。

最後に、補完データテーブル６００の該当レコードの実行回数をインクリメントして（ステップＳ１２０６）、図１１に示したステップＳ１１０１に移行する。また、ステップＳ１２０４において、最大処理時間が上記処理時間以上の場合（ステップＳ１２０４：Ｙｅｓ）、該当レコードの実行回数をインクリメントして（ステップＳ１２０６）、図１１に示したステップＳ１１０１に移行する。

これにより、補完データテーブル６００に記憶されている各オブジェクトの実行にかかる平均処理時間、最大処理時間を、ＩＴシステム２００の稼働状況に合わせて逐次更新することができる。

図１０および図１１に示した例では、メッセージデータの取得を契機にシステム分析支援処理を実行することとしたが、これに限らない。たとえば、特定期間（たとえば、２４時間、１週間）にＩＴシステム２００内で受け渡されたメッセージデータ群を、一括してシステム分析支援装置２０１に与えることで、システム分析支援処理を実行することとしてもよい。

この場合、メッセージデータ群の中にリクエストメッセージに対応するレスポンスメッセージがないと、そのリクエストメッセージを、レスポンスメッセージが存在しないものとして扱うことができる。すなわち、図１１に示したステップＳ１１０５およびステップＳ１１０６に相当する処理を省略することができる。

ただし、メッセージデータ群のうち特定期間終了間際のリクエストメッセージについては、特定期間終了後にレスポンスメッセージが発行される可能性がある。しかし、このようなメッセージペアは、メッセージ群全体に対して無視できる程度に少ない。このため、このメッセージペアの把握漏れが、ＩＴシステム２００の稼働状況の分析精度に与える影響は小さい。

なお、図示は省略するが、特定期間にＩＴシステム２００内で受け渡されたメッセージデータ群は、図５に示したメッセージバッファ５００と同様のデータ構造を有するメッセージＤＢに記憶されている。また、メッセージＤＢは、たとえば、システム分析支援装置２０１の磁気ディスク４０５、光ディスク４０７などの記憶領域に構築される。

以下、特定期間にＩＴシステム２００内で受け渡されたメッセージデータ群を、一括してシステム分析支援装置２０１に与えることで実行されるシステム分析支援処理手順について説明する。図１３は、システム分析支援処理手順の一例を示すフローチャート（その３）である。

図１３のフローチャートにおいて、まず、取得部７０１は、メッセージデータ群を取得したか否かを判断する（ステップＳ１３０１）。ここで、メッセージデータ群を取得するのを待って（ステップＳ１３０１：Ｎｏ）、取得した場合（ステップＳ１３０１：Ｙｅｓ）、メッセージデータを時系列にソートする（ステップＳ１３０２）。

つぎに、選択部７０２は、時系列にソートされたメッセージデータ群の中から先頭のメッセージデータを選択する（ステップＳ１３０３）。そして、検索部７０３は、選択されたメッセージデータのメッセージ種別を参照して、リクエストメッセージか否かを判断する（ステップＳ１３０４）。ここで、レスポンスメッセージの場合（ステップＳ１３０４：Ｎｏ）、ステップＳ１３０３に戻る。

一方、リクエストメッセージの場合（ステップＳ１３０４：Ｙｅｓ）、検索部７０３は、そのリクエストメッセージと同一メッセージＩＤのレスポンスメッセージをメッセージデータ群の中から検索する（ステップＳ１３０５）。そして、検索部７０３は、レスポンスメッセージが検索されたか否かを判断する（ステップＳ１３０６）。

ここで、レスポンスメッセージが検索された場合（ステップＳ１３０６：Ｙｅｓ）、関連付け部７０７は、リクエストメッセージとレスポンスメッセージを関連付ける（ステップＳ１３０７）。そして、関連付け部７０７は、その関連付け結果をペア情報としてペアリングテーブル８００に登録する（ステップＳ１３０８）。このあと、更新部７０８は、補完データテーブル６００の記憶内容を更新する更新処理を実行し（ステップＳ１３０９）、ステップＳ１３１４に移行する。なお、更新処理の具体的処理手順については、図１０に示した手順と同様のため説明を省略する。

また、ステップＳ１３０６において、レスポンスメッセージが検索されなかった場合（ステップＳ１３０６：Ｎｏ）、決定部７０５は、補完データテーブル６００にアクセスして、選択されたリクエストメッセージに対するその送信先のサーバでの平均処理時間を読み出す（ステップＳ１３１０）。そして、決定部７０５は、リクエストメッセージの送信時刻に平均処理時間を加算した時刻を、レスポンスメッセージの推定送信時刻に決定する（ステップＳ１３１１）。

このあと、関連付け部７０７は、リクエストメッセージとレスポンスメッセージの推定送信時刻とを関連付ける（ステップＳ１３１２）。そして、関連付け部７０７は、その関連付け結果をペア情報としてペアリングテーブル８００に登録する（ステップＳ１３１３）。つぎに、選択部７０２は、メッセージデータ群の中から選択されていない未選択のメッセージデータがあるか否かを判断する（ステップＳ１３１４）。

ここで、未選択のメッセージデータがある場合（ステップＳ１３１４：Ｙｅｓ）、ステップＳ１３０３に戻り、選択部７０２は、未選択のメッセージデータ群の中から先頭のメッセージデータを選択する。一方、未選択のメッセージデータがない場合（ステップＳ１３１４：Ｎｏ）、出力部７０９は、ペアリングテーブル８００のレコード内容を出力して（ステップＳ１３１５）、本フローチャートによる一連の処理を終了する。

これにより、特定期間中にＩＴシステム２００内で受け渡されたリクエストメッセージ（レスポンスメッセージが存在しないものを含む）について、リクエスト時刻とレスポンス時刻との対応関係を示すペア情報を提供することができる。

以上説明したように、本実施の形態によれば、リクエスト先のサーバで実行される処理の実績処理時間を用いて、リクエストメッセージとペアとなる実際には存在しないレスポンスメッセージの推定送信時刻を補完することができる。これにより、レスポンスメッセージが存在しないリクエストメッセージについて、リクエスト時刻とレスポンス時刻との対応関係を構築することができる。

また、リクエスト時刻とレスポンス時刻との対応関係を構築することで、階層間のメッセージペアの入れ子関係を判断することが可能となり、タイムアウトを含むトランザクションを把握することができる。この結果、タイムアウトが発生した際の業務サービスの処理状況が分析可能となり、対象システムの稼働状況の分析精度を向上させることができる。

（システム可視化技術への活用）
以下、本システム分析支援手法により得られるペア情報（たとえば、図８に示したペア情報８００−１〜８００−ｎ）の活用例について説明する。本システム分析支援手法により得られるペア情報は、公知のシステム可視化技術に活用することができる。特に、実際には存在しないレスポンスメッセージの推定送信時刻を用いて、タイムアウトを含むトランザクションの処理状況を分析することができる。

ここで、ペア情報８００−１〜８００−３を例に挙げて、タイムアウトを含むトランザクションについて説明する。ただし、各メッセージの送信時刻ｔ２〜ｔ６（時：分：秒）を、「００：００：００．１００」、「００：００：００．１５０」、「００：００：００．１９０」、「００：００：００．２５０」、「００：００：００．３００」とする。また、平均処理時間Ｔ３_aveを２０［ｍｓｅｃ］とする。

図１４は、タイムアウトを含むトランザクションの具体例を示す説明図である。図１４において、グラフ１４００は、タイムアウトを含むトランザクションの実行時にＩＴシステム２００内で受け渡されたメッセージの流れを時系列に示すシーケンスである。このトランザクションを把握するためには、コンピュータ装置（システム可視化技術を実現するためのコンピュータ装置）が、階層間でのメッセージペアの入れ子関係を認識する必要がある。

ここでは、コンピュータ装置が、ペア情報８００−１，８００−３を参照して、Ｗｅｂ／ＡＰ層間のメッセージペアの入れ子関係を認識する。具体的には、Ｗｅｂ層のリクエストメッセージＭ１とレスポンスメッセージＭ１との間に、ＡＰ層のリクエストメッセージＭ２とレスポンスメッセージＭ２とが挟まれていることを認識する。

また、ペア情報８００−１，８００−２を参照して、ＡＰ／ＤＢ層間のメッセージペアの入れ子関係を認識する。具体的には、ＡＰ層のリクエストメッセージＭ２とレスポンスメッセージＭ２との間に、ＤＢ層のリクエストメッセージＭ３とレスポンスメッセージＭ３とが挟まれていることを認識する。さらに、ペア情報８００−２の補完フラグを参照することで、レスポンスメッセージＭ３は実際には存在しないことを認識することができる。

また、ペア情報８００−１〜８００−３の各リクエスト時刻、レスポンス時刻を参照することで、このトランザクション実行時における各サーバ２０３〜２０５での処理時間を算出することができる。ここでは、Ｗｅｂサーバ２０３での処理時間は２００［ｍｓｅｃ］、ＡＰサーバ２０４での処理時間は１００［ｍｓｅｃ］、ＤＢサーバ２０５での処理時間は２０［ｍｓｅｃ］となる。

このように、ペア情報８００−１〜８００−３によれば、階層間でのメッセージペアの入れ子関係を判断することが可能となり、タイムアウトを含むトランザクションを把握することができる。特に、実際には存在しないレスポンスメッセージＭ３の推定送信時刻を用いて、ＡＰ／ＤＢ層間のメッセージペアの入れ子関係を判断することができる。

また、従来のマッチング方式により、本システム分析支援手法により得られるペア情報を用いて、メッセージとトランザクションモデルとのマッチングをおこなうことができる。ただし、本システム分析支援手法で用いるトランザクションモデルは、従来のトランザクションモデルとは異なる表現形式となる。ここで、本システム分析支援手法で用いるトランザクションモデルについて説明する。

図１５は、トランザクションモデルの生成例を示す説明図である。図１５において、トランザクションモデルＴＭ１は、従来手法の表現形式で記述されたトランザクションモデルである。このトランザクションモデルＴＭ１は、リクエストメッセージとレスポンスメッセージとのメッセージペアを前提として記述されている。

具体的には、トランザクションモデルＴＭ１において、ＨＴＴＰメッセージ「ＧＥＴ／ｍａｉｎ．ｊｓｐ」は、Ｔａがリクエスト時刻であり、Ｔｂがレスポンス時刻である。なお、「Ｃｏｄｅ２００」はＨＴＴＰが正常に取得されたという戻り値を示している。また、このＨＴＴＰメッセージ「ＧＥＴ／ｍａｉｎ．ｊｓｐ」から呼ばれるＩＩＯＰメッセージ「ＡＢＣ」は、Ｔｃがリクエスト時刻であり、Ｔｄがレスポンス時刻である。

さらに、このＩＩＯＰメッセージ「ＡＢＣ」から呼ばれるＳＱＬメッセージ「ＳＥＬＥＣＴ ｕｉｄ ｆｒｏｍ ｔｂｌ」は、Ｔｅがリクエスト時刻であり、Ｔｆがレスポンス時刻である。この場合、各時刻Ｔａ〜Ｔｆについて、Ｔａ＜Ｔｃ，Ｔｄ＜Ｔｂ，Ｔｃ＜Ｔｅ，Ｔｆ＜Ｔｄの制約が成立する。すなわち、この表現形式では、レスポンスメッセージが存在しない場合はトランザクションモデルＴＭ１と合致せず、扱うことができない。

そこで、本システム分析支援手法で用いるトランザクションモデルＴＭ２では、各プロトコルについて、リクエストメッセージのみ定義する。たとえば、ＨＴＴＰメッセージ「ＧＥＴ／ｍａｉｎ．ｊｓｐ」については、リクエスト時刻Ｔａのみを定義する。このトランザクションモデルＴＭ２は、トランザクションモデルＴＭ１からレスポンスメッセージに関する記述を削除することで生成することができる。

そして、ＩＴシステム２００内で受け渡されるメッセージとトランザクションモデルＴＭ２とのマッチングをおこなう。このとき、トランザクションモデルＴＭ２とマッチングされるメッセージはリクエストメッセージのみである。そこで、本システム分析支援手法により得られるペア情報を用いて、階層間でのメッセージペアの入れ子関係を認識する。これにより、タイムアウトを含むトランザクションの処理状況を分析することができる。

ここで、トランザクションモデルＴＭ２を用いたマッチング結果について説明する。図１６は、マッチング結果の具体例を示す説明図である。図１６において、マッチング結果１６００は、モデルＩＤ、レコードＩＤ、サブレコードＩＤ、送信時刻、プロトコル、メッセージ種別およびオブジェクト名といったフィールドを有する。各フィールドに情報を設定することで、トランザクション情報（たとえば、トランザクション情報１６００−１，１６００−２）がレコードとして記憶されることとなる。

ここで、モデルＩＤとは、トランザクションモデルを識別する識別子である。レコードＩＤとは、マッチング結果を識別する識別子である。サブレコードＩＤとは、トランザクションモデルに含まれるメッセージを識別する識別子である。なお、マッチング結果１６００では、推定送信時刻が補完されたメッセージ、すなわち、存在しないレスポンスメッセージは非表示となっている。

ユーザ（たとえば、ＩＴシステム２００の管理者）は、このマッチング結果１６００を参照することで、タイムアウトを含むトランザクションの発生状況を把握することができる。たとえば、トランザクション情報１６００−１によれば、タイムアウトを含むトランザクションの発生時刻ｔ２、タイムアウトとなった処理のリクエストメッセージＭ３の送信時刻ｔ４、タイムアウト処理が実行されたＡＰサーバ２０４などを認識することができる。

なお、トランザクションモデルとのマッチング結果としては、図１６に示した例のほか、特定期間（たとえば、２４時間）のマッチング結果を集計して、トランザクションモデルごとのマッチング回数を出力することとしてもよい。これにより、特定の期間内にタイムアウトを含むトランザクションが何回発生したのかを把握することができる。

さらに、トランザクションモデルＴＭ１（図１５参照）のマッチング回数と、トランザクションモデルＴＭ２とのマッチング回数との比率を出力することとしてもよい。これにより、たとえば、オンラインバンキングでおこなわれた「入金」トランザクションのうち、どれくらいの割合でタイムアウトが発生したのかを把握することができる。

また、特定期間のマッチング結果を集計して、業務サービス単位の各サーバ２０３〜２０５での平均処理時間を算出し、図１４に示したようなシーケンスとしてグラフ化することとしてもよい。このとき、タイムアウトを含むトランザクションについても、推定送信時刻を用いて各サーバ２０３〜２０５での処理時間を算出することができる。

これにより、業務サービス提供時における各サーバ２０３〜２０５での処理時間を正確に把握することができる。また、サーバ２０３〜２０５が連携して実行するトランザクションの挙動を、人間に分かりやすい形で提示することにより、ＩＴシステム２００に潜む問題の迅速な把握と的確な対処を可能とする。

なお、本実施の形態で説明したシステム分析支援方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、このプログラムは、インターネットなどのネットワークを介して配布することが可能であってもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）複数のサーバが連携して動作するネットワークシステムの稼働状況の分析を支援するコンピュータを、
前記ネットワークシステム内で受け渡されたメッセージデータ群から、リクエストメッセージに対応するレスポンスメッセージを検索する検索手段、
前記検索手段によって前記レスポンスメッセージが検索されなかった場合、前記リクエストメッセージに対する送信先のサーバでの実績処理時間を記憶する記憶手段から実績処理時間を読み出して、前記リクエストメッセージに対する実績処理時間が経過しているか否かを、前記リクエストメッセージの送信時刻から判断する判断手段、
前記判断手段によって前記実績処理時間が経過していると判断された場合、前記リクエストメッセージの送信時刻と前記実績処理時間とに基づいて、前記レスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定する決定手段、
前記決定手段によって決定された推定送信時刻と前記リクエストメッセージとを関連付ける関連付け手段、
前記関連付け手段によって関連付けられた関連付け結果を出力する出力手段、
として機能させることを特徴とするシステム分析支援プログラム。

（付記２）前記実績処理時間は、前記リクエストメッセージに対するその送信先のサーバでの最大処理時間であることを特徴とする付記１に記載のシステム分析支援プログラム。

（付記３）前記実績処理時間は、前記リクエストメッセージに対するその送信先のサーバでの平均処理時間であることを特徴とする付記１または２に記載のシステム分析支援プログラム。

（付記４）前記決定手段は、
前記リクエストメッセージの送信時刻に前記実績処理時間を加算した時刻を、前記推定送信時刻に決定することを特徴とする付記１〜３のいずれか一つに記載のシステム分析支援プログラム。

（付記５）前記コンピュータを、
前記実績処理時間が経過していると判断された場合、前記リクエストメッセージに対するその送信先のサーバでの推定処理時間を算出する算出手段として機能させ、
前記記憶手段は、
前記リクエストメッセージに対するその送信先のサーバでの実績処理時間に関する統計情報を記憶しており、
前記算出手段は、
前記記憶手段に記憶されている前記リクエストメッセージに対するその送信先のサーバでの実績処理時間と当該実績処理時間に関する統計情報とに基づいて、前記サーバでの推定処理時間を算出し、
前記決定手段は、
前記リクエストメッセージの送信時刻に前記算出手段によって算出された推定処理時間を加算した時刻を、前記推定送信時刻に決定することを特徴とする付記１〜３のいずれか一つに記載のシステム分析支援プログラム。

（付記６）前記算出手段は、
前記リクエストメッセージに対するその送信先のサーバでの処理時間に、当該処理時間のばらつきを示す標準偏差を加算することにより、前記サーバでの推定処理時間を算出することを特徴とする付記５に記載のシステム分析支援プログラム。

（付記７）前記判断手段は、
前記検索手段によって検索されなかった場合、前記メッセージデータ群のうち最新のメッセージデータの送信時刻が、前記リクエストメッセージの送信時刻から前記実績処理時間後の時刻を経過しているか否かを判断することを特徴とする付記１〜６のいずれか一つに記載のシステム分析支援プログラム。

（付記８）前記コンピュータを、
前記記憶手段に記憶されている前記リクエストメッセージに対する実績処理時間を更新する更新手段として機能させ、
前記関連付け手段は、
対応関係を有するリクエストメッセージとレスポンスメッセージとを関連付け、
前記更新手段は、
前記関連付け手段によって関連付けられたリクエストメッセージの送信時刻とレスポンスメッセージの送信時刻とに基づいて、前記リクエストメッセージに対する実績処理時間を更新することを特徴とする付記１〜７のいずれか一つに記載のシステム分析支援プログラム。

（付記９）複数のサーバが連携して動作するネットワークシステムの稼働状況の分析を支援するシステム分析支援装置であって、
前記ネットワークシステム内で受け渡されたリクエストメッセージに対する、その送信先のサーバでの実績処理時間を記憶する記憶手段と、
前記ネットワークシステム内で受け渡されたメッセージデータ群から、リクエストメッセージに対応するレスポンスメッセージを検索する検索手段、
前記検索手段によって前記レスポンスメッセージが検索されなかった場合、前記記憶手段から実績処理時間を読み出して、前記リクエストメッセージに対する実績処理時間が経過しているか否かを、前記リクエストメッセージの送信時刻から判断する判断手段と、
前記判断手段によって前記実績処理時間が経過していると判断された場合、前記リクエストメッセージの送信時刻と前記実績処理時間とに基づいて、前記レスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定する決定手段と、
前記決定手段によって決定された推定送信時刻と前記リクエストメッセージとを関連付ける関連付け手段と、
前記関連付け手段によって関連付けられた関連付け結果を出力する出力手段と、
を備えることを特徴とするシステム分析支援装置。

（付記１０）制御手段および記憶手段を備えるコンピュータが、
前記制御手段により、複数のサーバが連携して動作するネットワークシステム内で受け渡されたメッセージデータ群から、リクエストメッセージに対応するレスポンスメッセージを検索して、その検索結果を前記記憶手段に記憶する検索工程と、
前記制御手段により、前記検索工程によって前記レスポンスメッセージが検索されなかった場合、前記リクエストメッセージに対する送信先のサーバでの実績処理時間を記憶するテーブルから実績処理時間を読み出して、前記リクエストメッセージに対する実績処理時間が経過しているか否かを、前記リクエストメッセージの送信時刻から判断して、その判断結果を前記記憶手段に記憶する判断工程と、
前記制御手段により、前記判断工程によって前記実績処理時間が経過していると判断された場合、前記リクエストメッセージの送信時刻と前記実績処理時間とに基づいて、前記レスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定して、その決定結果を前記記憶手段に記憶する決定工程と、
前記制御手段により、前記決定工程によって決定された推定送信時刻と前記リクエストメッセージとを関連付けて、その関連付け結果を前記記憶手段に記憶する関連付け工程と、
前記制御手段により、前記関連付け工程によって関連付けられた関連付け結果を出力する出力工程と、
を実行することを特徴とするシステム分析支援方法。

以上のように、システム分析支援プログラム、システム分析支援装置、およびシステム分析支援方法は、複数のサーバが連携して動作するネットワークシステムの稼働状況を分析する技術に有用であり、特に、タイムアウトを含むトランザクションの処理状況を分析する技術に適している。

一般的な３階層システムの模式図である。 ＩＴシステムのシステム構成図である。 キャプチャ機能の概要を示す説明図である。 システム分析支援装置のハードウェア構成を示すブロック図である。 メッセージバッファの記憶内容の一例を示す説明図である。 補完データテーブルの記憶内容の一例を示す説明図である。 システム分析支援装置の機能的構成を示すブロック図である。 ペアリングテーブルの記憶内容の一例を示す説明図である。 更新処理の概要を示す説明図である。 システム分析支援処理手順の一例を示すフローチャート（その１）である。 システム分析支援処理手順の一例を示すフローチャート（その２）である。 更新処理の具体的処理手順の一例を示すフローチャートである。 システム分析支援処理手順の一例を示すフローチャート（その３）である。 タイムアウトを含むトランザクションの具体例を示す説明図である。 トランザクションモデルの生成例を示す説明図である。 マッチング結果の具体例を示す説明図である。

符号の説明

２００ ＩＴシステム
２０１ システム分析支援装置
２０２ クライアント端末
２０３ Ｗｅｂサーバ
２０４ ＡＰサーバ
２０５ ＤＢサーバ
７０１ 取得部
７０２ 選択部
７０３ 検索部
７０４ 判断部
７０５ 決定部
７０６ 算出部
７０７ 関連付け部
７０８ 更新部
７０９ 出力部

Claims (8)

1. 複数のサーバが連携して動作するネットワークシステムの稼働状況の分析を支援するコンピュータを、
   前記ネットワークシステム内で受け渡されたメッセージデータ群から、リクエストメッセージに対応するレスポンスメッセージを検索する検索手段、
   前記検索手段によって前記レスポンスメッセージが検索されなかった場合、前記リクエストメッセージに対する送信先のサーバでの実績処理時間を記憶する記憶手段から実績処理時間を読み出して、前記リクエストメッセージに対する実績処理時間が経過しているか否かを、前記リクエストメッセージの送信時刻から判断する判断手段、
   前記判断手段によって前記実績処理時間が経過していると判断された場合、前記リクエストメッセージの送信時刻と前記実績処理時間とに基づいて、前記レスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定する決定手段、
   前記決定手段によって決定された推定送信時刻と前記リクエストメッセージとを関連付ける関連付け手段、
   前記関連付け手段によって関連付けられた関連付け結果を出力する出力手段、
   として機能させることを特徴とするシステム分析支援プログラム。
2. 前記実績処理時間は、前記リクエストメッセージに対するその送信先のサーバでの最大処理時間であることを特徴とする請求項１に記載のシステム分析支援プログラム。
3. 前記実績処理時間は、前記リクエストメッセージに対するその送信先のサーバでの平均処理時間であることを特徴とする請求項１または２に記載のシステム分析支援プログラム。
4. 前記決定手段は、
   前記リクエストメッセージの送信時刻に前記実績処理時間を加算した時刻を、前記推定送信時刻に決定することを特徴とする請求項１〜３のいずれか一つに記載のシステム分析支援プログラム。
5. 前記コンピュータを、
   前記実績処理時間が経過していると判断された場合、前記リクエストメッセージに対するその送信先のサーバでの推定処理時間を算出する算出手段として機能させ、
   前記記憶手段は、
   前記リクエストメッセージに対するその送信先のサーバでの実績処理時間に関する統計情報を記憶しており、
   前記算出手段は、
   前記記憶手段に記憶されている前記リクエストメッセージに対するその送信先のサーバでの実績処理時間と当該実績処理時間に関する統計情報とに基づいて、前記サーバでの推定処理時間を算出し、
   前記決定手段は、
   前記リクエストメッセージの送信時刻に前記算出手段によって算出された推定処理時間を加算した時刻を、前記推定送信時刻に決定することを特徴とする請求項１〜３のいずれか一つに記載のシステム分析支援プログラム。
6. 前記コンピュータを、
   前記記憶手段に記憶されている前記リクエストメッセージに対する実績処理時間を更新する更新手段として機能させ、
   前記関連付け手段は、
   対応関係を有するリクエストメッセージとレスポンスメッセージとを関連付け、
   前記更新手段は、
   前記関連付け手段によって関連付けられたリクエストメッセージの送信時刻とレスポンスメッセージの送信時刻とに基づいて、前記リクエストメッセージに対する実績処理時間を更新することを特徴とする請求項１〜５のいずれか一つに記載のシステム分析支援プログラム。
7. 複数のサーバが連携して動作するネットワークシステムの稼働状況の分析を支援するシステム分析支援装置であって、
   前記ネットワークシステム内で受け渡されたリクエストメッセージに対する、その送信先のサーバでの実績処理時間を記憶する記憶手段と、
   前記ネットワークシステム内で受け渡されたメッセージデータ群から、リクエストメッセージに対応するレスポンスメッセージを検索する検索手段と、
   前記検索手段によって前記レスポンスメッセージが検索されなかった場合、前記記憶手段から実績処理時間を読み出して、前記リクエストメッセージに対する実績処理時間が経過しているか否かを、前記リクエストメッセージの送信時刻から判断する判断手段と、
   前記判断手段によって前記実績処理時間が経過していると判断された場合、前記リクエストメッセージの送信時刻と前記実績処理時間とに基づいて、前記レスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定する決定手段と、
   前記決定手段によって決定された推定送信時刻と前記リクエストメッセージとを関連付ける関連付け手段と、
   前記関連付け手段によって関連付けられた関連付け結果を出力する出力手段と、
   を備えることを特徴とするシステム分析支援装置。
8. 制御手段および記憶手段を備えるコンピュータが、
   前記制御手段により、複数のサーバが連携して動作するネットワークシステム内で受け渡されたメッセージデータ群から、リクエストメッセージに対応するレスポンスメッセージを検索して、その検索結果を前記記憶手段に記憶する検索工程と、
   前記制御手段により、前記検索工程によって前記レスポンスメッセージが検索されなかった場合、前記リクエストメッセージに対する送信先のサーバでの実績処理時間を記憶するテーブルから実績処理時間を読み出して、前記リクエストメッセージに対する実績処理時間が経過しているか否かを、前記リクエストメッセージの送信時刻から判断して、その判断結果を前記記憶手段に記憶する判断工程と、
   前記制御手段により、前記判断工程によって前記実績処理時間が経過していると判断された場合、前記リクエストメッセージの送信時刻と前記実績処理時間とに基づいて、前記レスポンスメッセージが送信されたと仮定した場合の推定送信時刻を決定して、その決定結果を前記記憶手段に記憶する決定工程と、
   前記制御手段により、前記決定工程によって決定された推定送信時刻と前記リクエストメッセージとを関連付けて、その関連付け結果を前記記憶手段に記憶する関連付け工程と、
   前記制御手段により、前記関連付け工程によって関連付けられた関連付け結果を出力する出力工程と、
   を実行することを特徴とするシステム分析支援方法。

Images