JP4594258B2 - システム分析装置およびシステム分析方法 - Google Patents

Description

本発明は，例えば１Ｇｂｐｓを超えるような高速なネットワークに接続された多層構成のサーバシステムにおいて，流れるパケットをキャプチャしてトランザクション解析を行うシステム分析装置およびシステム分析方法に関する。多層サーバシステムは，例えば，Ｗｅｂサーバ，アプリケーションサーバ（ＡＰサーバ），データベースサーバ（ＤＢサーバ）の３層に構成されたサーバが所定の処理を各層で分散して行うシステムなどである。

多層サーバシステムにおけるシステム分析では，流れるパケットをキャプチャし，パケット解析やトランザクション解析を行い，解析結果を分析または可視化して，システム性能を分析する。

パケット解析では，キャプチャしたパケットを用いて，ＴＣＰ，アプリケーションプロトコル（ＨＴＴＰ等）などのメッセージレベルでの解析が行われる。トランザクション解析では，キャプチャしたパケットを用いて，業務Ａ，業務Ｂなどのトランザクション単位で，各サーバでの処理時間や，各サーバ内の処理オブジェクト（ＯＢＪ）間の呼び出し関係などの解析が行われる。ここで，トランザクションとは，クライアントからのリクエストに対する一連の処理の結びつきをいう。

そして，パケット解析またはトランザクション解析の結果を，分析または可視化する。例えば，システム性能として，各サーバでの処理時間，各サーバ内の処理オブジェクト間の呼び出し関係などを可視化する。なお，ボトルネック分析，傾向予測なども，分析または可視化の処理の範疇にはいる。

このようなシステム分析によって，システムにおける問題箇所の把握，必要リソースの追加やネットワーク切り換えなどの対応策の提案に利用することが可能となる。

システム分析の手法として，２つ手法がある。１つめの手法は，キャプチャしたパケットをいったんディスクなどに保存し，それを後から読み出してパケット解析，トランザクション解析，分析／可視化を行う方法であって，「蓄積型分析」と呼ばれる。２つめの手法は，キャプチャしたパケットをリアルタイムでパケット解析，トランザクション解析，分析または可視化まで処理を行い，解析結果を表示する方法であって，「リアルタイム型分析」と呼ばれる。

パケットをキャプチャしてトランザクション解析を行う従来技術として，プロトコルとアプリケーションを意識することなく，通信回線上から採取した通信情報から希望するトランザクションのアプリケーションログを簡単に抽出して解析できるトランザクションのトレース装置に関する技術が記載されている（例えば，特許文献１を参照）。
特開平９−１２８３４２号公報

多層サーバシステムにおけるシステム分析の例を，より詳細に説明する。

図１５は，システム分析装置が適用されるシステムの例を示す図である。このシステムは，Ｗｅｂサーバ１３１，ＡＰサーバ１３２，ＤＢサーバ１３３からなる多層サーバシステムであって，ネットワーク１５０を介して，クライアント１４０と通信を行うことができるとする。

システム分析装置１１０は，クライアント１４０−Ｗｅｂサーバ１３１間，Ｗｅｂサーバ１３１−ＡＰサーバ１３２間，ＡＰサーバ１３２−ＤＢサーバ１３３間の各区間を流れるパケットをキャプチャする。キャプチャしたパケットに対してトランザクション解析を行い，業務Ａ，業務Ｂなどのトランザクション単位で，各サーバでの処理時間や，各サーバ内の処理オブジェクト（ＯＢＪ）間の呼び出し関係などを解析する。トランザクションは，クライアント１４０からのリクエストに対する一連の処理の結びつきとする。

図１６は，システム分析の処理の流れを示す図である。

システム分析装置１１０は，クライアント１４０−Ｗｅｂサーバ１３１間，Ｗｅｂサーバ１３１−ＡＰサーバ１３２間，ＡＰサーバ１３２−ＤＢサーバ１３３間の各区間でパケットをキャプチャする（Ｐ１００）。キャプチャしたパケットに対して，パケット解析を行う（Ｐ１０１）。パケット解析は，ＴＣＰ，アプリケーションプロトコル（ＨＴＴＰ等）などのメッセージレベルでの解析処理である。パケット解析の結果は，プロトコルログ２００として記録される。

次に，キャプチャしたパケットに対して，トランザクション解析を行う（Ｐ１０２）。トランザクション解析は，メッセージの入れ子関係の特定，マッチングなどを使ったトランザクション抽出，オブジェクトの関連付けなどの解析処理である。トランザクション解析の結果は，プロトコル相関ログ／トランザクションデータ２１０として記録される。

最後に，パケット解析またはトランザクション解析の結果を，分析または可視化する（Ｐ１０３）。ここでは，システム性能として，各サーバでの処理時間，各サーバ内の処理オブジェクト間の呼び出し関係などを可視化する。

図１７は，解析結果の可視化出力の例を示す図である。図１７（Ａ）は，トランザクション単位の情報として，業務トランザクションの全処理時間，各サーバごとのサーバ時間，各区間のネットワーク時間を可視化したものである。図１７（Ｂ）は，オブジェクト単位の情報として，オブジェクトの呼び出し関係，各オブジェクトの処理時間を可視化したものである。

図１５のシステム分析装置１１０において，流れるすべてのパケットをソフトウェアでキャプチャする場合に，パケット通信速度が１Ｇｂｐｓ程度に近づくとシステム的に限界となる。通信速度が１Ｇｂｐｓ以上となるシステムについて，単一のシステム分析装置で直接パケットをキャプチャすることは困難である。また，市販されているパケットのキャプチャ処理の製品で，キャプチャ性能が１Ｇｂｐｓを超える能力を持つものはない。

そのため，１Ｇｂｐｓ超の高速なネットワーク・システムに対して，パケットをキャプチャしてトランザクション解析する方法として，図１８に示すように，用途に応じた次の２つの手法が考えられる。

第１の手法は，図１８（Ａ）に示すように，複数装置へ処理を負荷分散し，または処理のハード化などによって，すべてのパケットをキャプチャして解析する方法である。この方法は，処理負荷は大きくなるが，全現象を確実に捉えて解析したい場合に有効である。

第２の手法は，図１８（Ｂ）に示すように，トランザクション単位でパケットをサンプリングし，キャプチャおよび解析の処理量を減らして統計的に解析する方法である。この方法は，処理負荷を軽くして，例えば，コネクション時間などの統計情報によって，傾向をつかみたい場合に有効である。

図１８（Ａ）に示す第１の手法では，前段の振分装置３００により，後段の複数のキャプチャ／解析装置３１０にパケットを振り分ける。これによって，全体の処理性能を向上させている。振分装置３００の処理は，事前に定義した振分ロジックに従ってパケットを振り分ける判定機能であり，メモリコピーやディスクへの書き込み処理などを伴うキャプチャ／解析装置３１０より処理は軽い。キャプチャ／解析装置３１０の処理上限が１Ｇｂｐｓ程度であるのに対し，振分装置３００は市販のアプライアンス製品などでは４Ｇｂｐｓ程度の処理能力が得られている。また，振分装置３００を，ＡＳＩＣなどを使ってハード化し，後段のキャプチャ／解析装置３１０の台数を増やすことで，さらに高速な処理が可能である。

図１８（Ｂ）に示す第２の手法では，所定の規則にもとづいて入力パケットを間引いて全体の処理量を減らし，収集した入力パケットの部分集合から全体の傾向を推定する。統計的に解析を行うことによって，処理能力を向上させている。これらは，すべて単一のキャプチャ／解析装置３２０内で行うことが可能である。サンプリング部３２１は，処理量的には図１８（Ａ）の前段の振分装置３００とほぼ同等と考えられるので，処理性能としては４Ｇｂｐｓ程度が目安となる。サンプリング後のキャプチャ／解析部３２２での処理は，サンプリングするレートにも依存するが，レートを落とすほど軽くすることができる。例えば，４Ｇｂｐｓの入力パケットをサンプリングで１０％に落とすと，４００Ｍｂｐｓとなる。処理能力は，サンプリングした後のパケットに対し，１Ｇｂｐｓが目安となる。図１８（Ａ）の場合と同じく，サンプリング処理の部分をハード化することで，さらに高速な処理が可能である。

ここでは，上記の第２の手法について考える。システム分析で上記第２の手法を実現するには，サンプリング処理をトランザクションの単位で実施する必要がある。すなわち，パケットキャプチャ時に，リアルタイムに近い処理で，トランザクション単位でパケットをサンプリングすることが理想的である。しかし，以下の（ａ）〜（ｄ）のような問題があるため実現できていない。

（ａ） サンプリング技術としてＩＥＴＦのｓＦｌｏｗなどがある。しかし，これは，パケット単位のサンプリングであり，トランザクション単位，すなわち，一連の処理の流れを含むパケットの集合単位でサンプリングすることはできない。

（ｂ） トランザクション解析の仕様上，全パケットあるいは一定量のパケットをキャプチャした後，トランザクション解析，すなわちキャプチャしたパケットを一括して解析するところまでを行わないと，トランザクションを判定することができない。

（ｃ） 異なるＴＣＰコネクションでも，１つのトランザクションに属する場合があるため，ＴＣＰコネクションの単位でトランザクションを定義することはできない。

（ｄ） 送信元ＩＰアドレス（以下，ＳｒｃＩＰとする），宛先ＩＰアドレス（以下，ＤｓｔＩＰとする）は，それぞれ各サーバのＩＰアドレスであり，全トランザクションですべて共通であるため，Ｗｅｂサーバ−ＡＰサーバ間，ＡＰサーバ−ＤＢサーバ間では，ＩＰアドレスでトランザクションを分離することができない。

本発明は，上記の問題点の解決を図り，多層サーバシステムのシステム分析において，膨大な量の装置を用意することなく，トランザクション単位でのパケットのサンプリングを可能とすることにより，軽い処理負荷でのトランザクション単位のシステム分析が可能となる技術を提供することを目的とする。

本発明は，上記の課題を解決するため，クライアントからのリクエストに応じた所定の処理を複数の層に構成されたサーバで分散して行う多層サーバシステムにおいて，クライアント−多階層サーバシステム区間では，クライアントからのリクエストパケットの送信元ＩＰアドレス（ＳｒｃＩＰ）単位，すなわちクライアントのＩＰアドレスの単位でのサンプリングを行い，多層サーバシステム内のサーバ−サーバ区間では，前の区間がリクエスト待ちの状態である場合にのみサンプリングを行うことを特徴とする。

具体的には，本発明のシステム分析装置は，１）クライアントと前記クライアントのリクエスト送信先となる前記多層サーバシステムのサーバとのデータ通信区間であるクライアント−サーバ区間または前記多層サーバシステム内で隣接する層のサーバ同士のデータ通信区間であるサーバ−サーバ区間を流れるパケットからミラーリングされたパケットを区間ごとに分別して取得するネットワークインタフェース部と，２）前記クライアント−サーバ区間を流れるパケットを，前記パケットの送信元であるクライアントのアドレス情報をもとにフィルタリングする第１のフィルタリング部と，３）外部からの制御信号によって，前記サーバ−サーバ区間を流れるパケットを取得するオン期間または前記パケットを廃棄するオフ期間とが切り替え可能に設定され，前記オン期間またはオフ期間の設定に応じて前記パケットをフィルタリングする第２のフィルタリング部と，４）前記クライアント−サーバ区間または前記サーバ−サーバ区間のうち予め対応付けられた一つの区間から取得されたパケットを判定し，当該パケットのメッセージ状態から当該区間のリクエスト送信側がレスポンス待ちである期間を特定し，前記期間に連動させて当該区間の次のサーバ−サーバ区間のパケットをフィルタリングする前記第２のフィルタリング部の前記オン期間または前記オフ期間の設定を制御するリクエスト／レスポンス分析部と，５）前記第１のフィルタリング部または前記第２のフィルタリング部において通過したパケットを取得するパケットキャプチャ部とを備える。

本発明のシステム分析装置は，ネットワークインタフェース部によって，クライアント−サーバ区間（クライアントと多層サーバシステムのサーバとの区間）またはサーバ−サーバ区間（多層サーバシステム内で隣接する層のサーバ同士の区間）を流れるパケットからミラーリングされたパケットを区間ごとに分別して取得する。そして，第１フィルタリング部によって，クライアント−サーバ区間を流れるパケットを，パケットの送信元であるクライアントのアドレス情報をもとにフィルタリングする。

リクエスト／レスポンス分析部によって，クライアント−サーバ区間またはサーバ−サーバ区間のうち予め対応付けられた一つの区間から取得されたパケットを判定し，このパケットのメッセージ状態から自己が対応付けられた区間のリクエスト送信側がレスポンス待ちである期間を特定し，この期間に連動させて当該区間の次のサーバ−サーバ区間のパケットをフィルタリングする第２のフィルタリング部のオン期間またはオフ期間の設定を制御する。

第２のフィルタリング部は，外部からの制御信号によって，前記サーバ−サーバ区間を流れるパケットを取得するオン期間または前記パケットを廃棄するオフ期間とが切り替え可能に設定され，前記オン期間またはオフ期間の設定に応じて前記パケットをフィルタリングする。

そして，パケットキャプチャ部によって，第１のフィルタリング部または第２のフィルタリング部において通過したパケットを取得する。

これにより，トランザクション単位でのパケットのサンプリングが可能となり，その後のシステム分析において，トランザクション単位の解析処理が実現できる。特に，必要なトランザクションのパケットを確実にキャプチャしながらも，不必要なパケットのサンプリングの量を減らすことが可能となる。

また，本発明の前記ネットワークインタフェース部は，クライアント−サーバ区間とサーバ−サーバ区間の各区間に対応した複数の構成部として備えられ，各ネットワークインタフェース部は，対応する区間でミラーリングされたパケットを取得することができる。

さらに，本発明は，前記ネットワークインタフェース部によって取得されたパケットを当該パケットが流れていた各区間に分離する区間分離部を備え，前記ネットワークインタフェース部は，単一の構成部として備えられ，前記クライアント−サーバ区間と前記サーバ−サーバ区間とを流れるパケットからミラーリングされたパケットを集約して取得して，前記区間分離部へ送出することができる。これにより，システム分析装置にネットワークインタフェースが１つしかないような場合でも，トランザクション単位でのパケットのサンプリングが可能となる。

また，本発明の前記第１のフィルタリング部は，前記クライアント−サーバ区間を流れるパケットを，当該パケットの送信元ＩＰアドレスごとに所定の割合で取得することができる。これにより，パケットのサンプリングの割合を，任意または動的に指定することが可能となる。

さらに，本発明は，前記第１のフィルタリング部によって通過されたパケットのメッセージ状態をもとに，前記クライアント側のレスポンス待ちの期間と当該レスポンス待ち以外の期間とを特定し，前記２つの期間が所定の比率となるように，前記第１のフィルタリング部におけるフィルタリングの前記所定の割合を変更する範囲制御部を備えることができる。これにより，クライアントのＩＰアドレスの範囲，クライアントのＩＰアドレスに対して行ったハッシュ演算の結果の範囲などを変えることで，パケットのサンプリングの割合を自動的に調整することが可能となる。

また，本発明の前記第１のフィルタリング部は，パケットを取得するクライアントの範囲を前記クライアントのＩＰアドレスの全部または一部を用いて特定するフィルタリングポリシを備えて，前記クライアント−サーバ区間を流れるパケットのなかから，前記フィルタリングポリシに合致する送信元ＩＰアドレスを持つパケットを取得することができる。これにより，サンプリングを行うクライアントのＩＰアドレスの範囲を任意に指定することが可能となる。

さらに，前記第１のフィルタリング部は，前記クライアント−サーバ区間を流れるパケットの送信元ＩＰアドレスにハッシュ演算を行い，ハッシュ演算結果が所定の範囲となるパケットを取得することができる。これにより，サンプリングを行うクライアントのＩＰアドレスの偏りをなくすことが可能となる。

以上のシステム分析装置が行う処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも，ネットワークを通して提供することも可能である。

本発明によって，１Ｇｂｐｓを超える高速なネットワークに対してトランザクション単位のサンプリングを実現することにより，軽い処理負荷でのトランザクション解析が可能となる。また，少ない装置量でのトランザクション解析が可能となるため，コストの削減が期待できる。また，ゲートウェイ，ルータなどの中継装置に本発明のシステム分析装置の機能を組み込んだ場合でも，ルーティングやＱｏＳなどの中継処理に与える影響を最小限にしたトランザクション解析を行うことが可能となる。

以下，本発明を実施するための最良の形態について，図を用いて説明する。本形態において，セッションは，送受信のＩＰアドレスとポート番号によって定まる通信路上で送受信されるデータの集合をいう。また，メッセージは，ＴＣＰセッション上で複数の機器がやりとりするデータの最小単位のことをいう。例えば，ＨＴＴＰでのリクエストやそれに対するレスポンスのことをいう。さらに，トランザクションは，システムに対する要求によって発生する各サーバでの処理，すなわちサーバがメッセージを受信してからレスポンスを送信するまでに行う単一または複数の処理の集合をいう。

まず，本発明の原理について説明する。

図１は，本発明の第１の原理を説明する原理説明図である。本発明の第１の原理によるシステム分析装置１０は，ネットワークインタフェース部（Ｎｅｔ−ＩＦ部）１１，ソースＩＰ単位フィルタ部（ＳｒｃＩＰ単位フィルタ部）１２，オン／オフ・フィルタ部（ＯＮ／ＯＦＦフィルタ部）１３（１３ａ，１３ｂ），リクエスト／レスポンス分析部１４（１４ａ，１４ｂ），範囲制御部１５，パケットキャプチャ部１６，パケット解析／トランザクション解析部１７を備える。

システム分析装置１０のシステム分析の対象は，Ｗｅｂサーバ３１，ＡＰサーバ３２，ＤＢサーバ３３からなる３層で分散して処理を行うサーバシステムである。クライアント４０は，ネットワーク５０を介してＷｅｂサーバ３１にリクエストを送信し，Ｗｅｂサーバ３１からレスポンスを受信する。Ｗｅｂサーバ３１は，ＡＰサーバ３２にリクエストを送信し，ＡＰサーバ３２からレスポンスを受信する。ＡＰサーバ３２は，ＤＢサーバ３３にリクエストを送信し，ＤＢサーバ３３からレスポンスを受信する。

システム分析装置１０のＳｒｃＩＰ単位フィルタ部１２，ＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ），リクエスト／レスポンス分析部１４（１４ａ，１４ｂ），範囲制御部１５によって，パケットのサンプリングを行い，キャプチャすべき総パケット量を軽減させることができる。

Ｎｅｔ−ＩＦ部１１は，予め対応付けられた区間（例えば，クライアント４０−Ｗｅｂサーバ３１間，Ｗｅｂサーバ３１−ＡＰサーバ３２間，ＡＰサーバ３２−ＤＢサーバ３３間）を流れるパケットからミラーリングされたパケットを取得する処理手段である。

ＳｒｃＩＰ単位フィルタ部１２は，Ｎｅｔ−ＩＦ１１から入力されたパケットについて，所定のソースＩＰ単位（ＳｒｃＩＰ単位）でフィルタリングを行う手段である。ＳｒｃＩＰ単位のフィルタリングとは，クライアント４０からのリクエストのＳｒｃＩＰ単位，すなわち，クライアント４０のＩＰアドレス単位でフィルタリングを行うことである。

図１では，クライアント４０−Ｗｅｂサーバ３１間でミラーリングされたパケットは，Ｎｅｔ−ＩＦ１１を介してＳｒｃＩＰ単位フィルタ部１２に送られる。ＳｒｃＩＰ単位フィルタ部１２は，受け取ったパケットに対してＳｒｃＩＰ単位のフィルタリングを行う。

クライアント４０−Ｗｅｂサーバ３１間では，１つのトランザクションは同一のクライアント４０から出た複数のＴＣＰコネクションとなる。そのため，ＳｒｃＩＰ単位のフィルタリングを行うことにより，同じトランザクションに属するパケットをすべてキャプチャすることができる。

また，ＳｒｃＩＰ単位フィルタ部１２は，設定された一定の割合，例えば，１／１０の割合などで，ＳｒｃＩＰ単位のサンプリングを行うことができる。

また，フィルタリングでは，例えば，ＳｒｃＩＰが一定の範囲内であるパケットのみをキャプチャしてもよい。または，ＳｒｃＩＰに対してハッシュ演算を行い，そのハッシュ演算の結果が一定の範囲内にあるパケットのみをキャプチャしてもよい。ハッシュ演算の結果を用いてサンプリングする場合には，キャプチャするパケットのＳｒｃＩＰの偏りをなくすことができる。

ＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ）は，外部からの制御信号によって，前記サーバ−サーバ区間を流れるパケットを取得するオン期間（ＯＮ期間）または前記パケットを廃棄するオフ期間（ＯＦＦ期間）とが切り替え可能に設定され，前記オン期間またはオフ期間（ＯＮ／ＯＦＦ）の設定に応じて前記パケットをフィルタリングする処理手段である。

フィルタリングのＯＮ／ＯＦＦによって，Ｎｅｔ−ＩＦ１１から入力されたパケットを通過させるか否かが決定される。

ＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ）は，外部からの制御信号によって設定されるＯＮ／ＯＦＦフラグを備え，このＯＮ／ＯＦＦフラグが“ＯＮ”であるときをＯＮ期間とし，“ＯＦＦ”であるときをＯＦＦ期間とする。そして，ＯＮ期間中では，入力されたパケットを通過させ，ＯＦＦ期間中では，入力されたパケットを廃棄する。

図１では，Ｗｅｂサーバ３１−ＡＰサーバ３２間，ＡＰサーバ３２−ＤＢサーバ３３間でミラーリングされたパケットは，それぞれに対応付けられたＮｅｔ−ＩＦ１１を介してＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ）に送られる。ＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ）では，ＯＮ／ＯＦＦフラグが“ＯＮ”であれば，入力されたパケットを通過させる。

リクエスト／レスポンス分析部１４（１４ａ，１４ｂ）は，予め対応付けられた区間から取得されたパケットのメッセージ状態から，その区間のリクエスト送信側がレスポンス待ちである期間を特定し，前記期間に連動させて当該区間の次のサーバ−サーバ区間のパケットをフィルタリングするＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ）のＯＮ／ＯＦＦフラグの切り替えを制御する処理手段である。ＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ）のフィルタリングのＯＮ／ＯＦＦフラグの切り替えは，リクエスト／レスポンスの包含関係を利用して行う。

図２は，各区間のリクエスト／レスポンスの期間の包含関係を説明するための図である。図２に示すように，ある層のサーバがリクエスト発行してレスポンスを待つ期間（リクエスト発行／レスポンス待ち期間）は，その前段のサーバにおけるリクエスト発行／レスポンス待ち期間内に包含される。したがって，自己層（現段階）がリクエスト発行／レスポンス待ちの期間でのみ，次層（次段階）でも，現段階でキャプチャされたパケットと同一のトランザクションに属するパケットがキャプチャされる可能性がある。

リクエスト／レスポンス分析部１４（１４ａ，１４ｂ）は，このようなリクエスト／レスポンスの包含関係とリクエスト／レスポンス分析の結果とを利用して，自層（現段階）がリクエスト発行／レスポンス待ちのときのみ次の区間（自己とその次層のサーバ間）でパケットをキャプチャするように，次の区間に対応するＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ）のＯＮ／ＯＦＦフラグを切り替える制御信号を送る。

例えば，リクエスト／レスポンス分析部１４ａは，クライアント４０−Ｗｅｂサーバ３１間でキャプチャされたパケットを用いてリクエストまたはレスポンスを分析し，リクエスト（Ｗｅｂリクエスト）発行を検出すると，次の区間に対応するＯＮ／ＯＦＦフィルタ部１３ａに対してＯＮフラグ設定の制御信号を送る。また，レスポンス（ＡＰレスポンス）を検出すると，ＯＮ／ＯＦＦフィルタ部１３ａに対してＯＦＦフラグ設定の制御信号を送る。

図２に示すように，リクエスト／レスポンス分析部１４ａから制御信号を受け取るＯＮ／ＯＦＦフィルタ部１３ａは，ＯＮ／ＯＦＦフラグが“ＯＮ”に書き換えられ，次にＯＮ／ＯＦＦフラグが“ＯＦＦ”に書き換えられるまでのＯＮ期間中に，キャプチャされたパケットを通過させる。

また，同様に，リクエスト／レスポンス分析部１４ｂは，ＯＮ／ＯＦＦフィルタ部１３ａが通過させたパケット（Ｗｅｂサーバ３１−ＡＰサーバ３２間でキャプチャされたパケット）を用いてリクエストまたはレスポンスを分析し，リクエスト（ＡＰリクエスト）発行を検出すると，次の区間のＯＮ／ＯＦＦフィルタ部１３ｂに対してＯＮフラグ設定の制御信号を送る。また，レスポンス（ＡＰレスポンス）を検出すると，ＯＦＦフラグ設定の制御信号を送る。ＯＮ／ＯＦＦフィルタ部１３ｂは，ＯＮ期間中のみ，キャプチャされたパケットを通過させる。

その結果，パケットキャプチャ部１６は，クライアント４０−Ｗｅｂサーバ３１間でＷｅｂレスポンス待ちの間だけ，Ｗｅｂサーバ３１−ＡＰサーバ３２間でのパケットのキャプチャを行い，Ｗｅｂサーバ３１−ＡＰサーバ３２間でＡＰレスポンス待ちの間だけ，ＡＰサーバ３２−ＤＢサーバ３３間でのパケットのキャプチャを行うことになる。これにより，キャプチャすべき総パケット量を大きく減らすことができる。

ただし，パケットキャプチャ部１６でキャプチャされるパケットには，他のトランザクションに属するパケットも含まれる可能性がある。このような他のトランザクションに属するパケットは，パケット解析／トランザクション解析部１７でフィルタリングする。

範囲制御部１５は，ＳｒｃＩＰ単位フィルタ部１２においてパケットをキャプチャするＳｒｃＩＰの範囲を制御する手段である。クライアント４０−Ｗｅｂサーバ３１間におけるＯＮ期間／ＯＦＦ期間，すなわちレスポンス待ちの期間／レスポンス待ちでない期間の比率が所望のもの（例えば，１：９など）になるように，パケットのフィルタリングの割合を，例えばキャプチャするパケットのＳｒｃＩＰの範囲，ＳｒｃＩＰにハッシュ演算した結果の範囲などをもとに調整する。

パケットキャプチャ部１６は，フィルタリングを通過したパケットのキャプチャ処理を行う手段である。このとき，パケットキャプチャ部１６は，キャプチャしたパケットを蓄積してもよく，キャプチャと同時にパケット解析／トランザクション解析部１７に渡してもよい。パケット解析，トランザクション解析の手法には，いったんキャプチャしたパケットをディスクなどに蓄積して後から解析を行う蓄積型処理と，キャプチャしながら解析を行うリアルタイム型処理とがある。なお，パケットキャプチャ部１６，パケット解析／トランザクション解析部１７については，従来通りのものであるので，詳細な説明を省略する。

このようなシステム分析装置１０によって，総キャプチャ量を削減した上で，同一のトランザクションに属するパケットをすべてキャプチャすることができる。したがって，キャプチャしたパケットを統計的に解析することにより，軽い処理負荷でのトランザクション解析（例えば，オブジェクトの呼び出し関係や処理時間などの分析）が可能となる。これにより，１Ｇｂｐｓを超える高速なネットワークのシステム分析が可能となる。

図３は，本発明の第２の原理を説明する原理説明図である。本発明の第２の原理によるシステム分析装置２０は，Ｎｅｔ−ＩＦ１１，ＳｒｃＩＰ単位フィルタ部１２，ＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ），リクエスト／レスポンス分析部１４（１４ａ，１４ｂ），範囲制御部１５，パケットキャプチャ部１６，パケット解析／トランザクション解析部１７，区間分離部１８を備える。

本発明の第２の原理では，各区間のミラーリングパケットがすべてスイッチ（ＳＷ）６０に集められ，１つのＮｅｔ−ＩＦ１１を介してシステム分析装置２０に入力される。区間分離部１８は，Ｎｅｔ−ＩＦ１１から入力されたパケットを区間ごとに分け，該当する区間のＳｒｃＩＰ単位フィルタ部１２，ＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ）に送信する。それ以外の部分については，図１に示す第１の原理と同じであるので，説明を省略する。

本発明の第２の原理によるシステム分析装置２０では，Ｎｅｔ−ＩＦ１１が１つあればよい。第１の原理によるシステム分析装置１０のように，パケットのキャプチャを行う区間ごとにＮｅｔ−ＩＦ１１を用意する必要がないので，キャプチャを行う区間が多い場合などには，コストを下げることができる。

以上説明したような原理によって，本発明では，トランザクション単位でのパケットのサンプリングをリアルタイムに行うことが可能となる。

以下，本発明のより具体的な実施の形態について説明する。

〔第１の実施形態〕
図４は，本発明の第１の実施形態によるシステム分析装置の例を示す図である。本実施形態は，各区間の通信路に配備されたスイッチ（ＳＷ）６２，６３，６４のミラーリング出力を，システム分析装置１０の別々のネットワークインタフェース（Ｎｅｔ−ＩＦ）１１ａ，１１ｂ，１１ｃに入力する形態である。上述の第１の原理に相当する。

システム分析装置１０は，Ｎｅｔ−ＩＦ部１１（１１ａ，１１ｂ，１１ｃ），ＳｒｃＩＰ単位フィルタ部１２，ＯＮ／ＯＦＦフィルタ部１３（１３ａ，１３ｂ），リクエスト／レスポンス分析部１４（１４ａ，１４ｂ），範囲制御部１５，パケットキャプチャ部１６，パケット解析／トランザクション解析部１７を備える。

本実施形態では，Ｗｅｂサーバ３１，ＡＰサーバ３２，ＤＢサーバ３３からなる３層のサーバシステムのシステム分析を行う。本第１の実施形態では，３台のクライアント４０（４０ａ，４０ｂ，４０ｃ）がＳＷ６１に接続されている。各クライアント４０（４０ａ，４０ｂ，４０ｃ）は，ネットワーク５０を介してＷｅｂサーバ３１にリクエストを送り，Ｗｅｂサーバ３１からレスポンスを受ける。Ｗｅｂサーバ３１は，ＡＰサーバ３２にリクエストを送り，ＡＰサーバ３２からレスポンスを受ける。ＡＰサーバ３２は，ＤＢサーバ３３にリクエストを送り，ＤＢサーバ３３からレスポンスを受ける。

各クライアント４０（ａ，ｂ，ｃ）には，それぞれＩＰアドレス“192.168.10.1”，“192.168.10.2”，“192.168.10.3”が設定されている。Ｗｅｂサーバ３１には，クライアント４０側にＩＰアドレス“192.168.1.1 ”が，ＡＰサーバ３２側にＩＰアドレス“192.168.2.1 ”が設定されている。ＡＰサーバ３２には，Ｗｅｂサーバ３１側にＩＰアドレス“192.168.2.2 ”が，ＤＢサーバ３３側にＩＰアドレス“192.168.3.1 ”が設定されている。ＤＢサーバ３３には，ＩＰアドレス“192.168.3.2 ”が設定されている。システム分析装置１０の各Ｎｅｔ−ＩＦ１１（ａ，ｂ，ｃ）には，それぞれＩＰアドレス“192.168.1.3 ”，“192.168.2.3 ”，“192.168.3.3 ”が設定されている。

クライアント４０−Ｗｅｂサーバ３１間，Ｗｅｂサーバ３１−ＡＰサーバ３２間，ＡＰサーバ３２−ＤＢサーバ３３間では，それぞれＨＴＴＰ，ＩＩＯＰ，ＲＤＢ２で通信が行われている。

図５は，パケットのフォーマットの例を示す図である。図５（Ａ）は，各区間でミラーリングされて，システム分析装置１０に入力されるパケットのフォーマットを示す。図５（Ｂ）は，パケットのＩＰヘッダのフォーマットを示す。図５（Ｃ）は，パケットのＴＣＰヘッダのフォーマットを示す。図５（Ｄ）は，ＴＣＰヘッダのフラグ部分のフォーマットを示す。なお，図５の各フォーマットは，一般的なＴＣＰ／ＩＰパケットのフォーマットである。

図６は，ＳｒｃＩＰ単位フィルタ部による処理のフローチャートである。クライアント４０−Ｗｅｂサーバ３１間のミラーリングパケットが，Ｎｅｔ−ＩＦ１１ａからシステム分析装置１０に入力されると，ＳｒｃＩＰ単位フィルタ部１２によって，この処理が開始される。

ＳｒｃＩＰ単位フィルタ部１２は，フィルタリングポリシ７０に従って，フィルタリング判定を行う（ステップＳ１０）。フィルタリング判定では，入力されたパケットのＩＰアドレスを確認することにより，入力されたパケットを通過させるか否かの判定を行う。フィルタリングポリシ７０には，クライアント４０からのリクエストのＳｒｃＩＰをキーにした，パケットのキャプチャまたは廃棄の判定の論理が定義されている。フィルタリングポリシ７０は，ユーザによって事前に定義され，運用中に変更されることもある。

フィルタリング判定の結果，パケットを通過（Ｐａｓｓ）させる，すなわちパケットをキャプチャする場合には（ステップＳ１１），パケットをリクエスト／レスポンス分析部１４ａに渡す（ステップＳ１２）。パケットをＰａｓｓしない，すなわちパケットをキャプチャしない場合には（ステップＳ１１），パケットをそのまま廃棄（ｄｉｓｃａｒｄ）する（ステップＳ１３）。

当該パケットの処理後，後続のパケットがあるかを判定する（ステップＳ１４）。後続のパケットがあれば，ステップＳ１０のフィルタリング判定に戻って次の新しいパケットに対する処理を行う。後続のパケットがなければ，処理を終了する。

ここで，フィルタリングポリシ７０が“ＳｒｃＩＰの下１桁が“１”のパケットのみキャプチャする”である場合の例について説明する。フィルタリング判定では，まず，Ｗｅｂサーバ３１のＩＰアドレスから，パケットの方向がクライアント４０からＷｅｂサーバ３１へ送信されたものか，Ｗｅｂサーバ３１からクライアント４０へ送信されたものかを識別する。システム分析装置１０側では，Ｗｅｂサーバ３１のＩＰアドレスを認識しているため，パケットのＳｒｃＩＰ，ＤｓｔＩＰのうち，Ｗｅｂサーバ３１のＩＰアドレスでない方がクライアント４０のＩＰアドレスとなる。クライアント４０からＷｅｂサーバ３１へ送信されたものである場合には，パケットフォーマットからＳｒｃＩＰを抽出する。Ｗｅｂサーバ３１からクライアント４０へ送信されたものである場合には，パケットフォーマットからＤｓｔＩＰを抽出する。

抽出したＩＰアドレスの下１桁を判定し，それが“１”であるならばパケットをキャプチャし，それ以外であるならばパケットを廃棄する。例えば，図４に示す構成では，３台のクライアント４０（ａ，ｂ，ｃ）のうち，クライアント４０ａのみＩＰアドレスの下一桁が“１”である。そのため，クライアント４０−Ｗｅｂサーバ３１間では，クライアント４０ａを発着とするパケットのみが，キャプチャされることになる。

また，フィルタリングポリシ７０で，例えば“192.168.10.1〜192.168.10.3”といったように，“ＳｒｃＩＰが一定の範囲内であるパケットのキャプチャ”を指定することもできる。また，フィルタリングポリシ７０で，“入力されたパケットのＳｒｃＩＰに対してハッシュ演算を行い，その演算結果が一定の範囲内にあるパケットのキャプチャ”を指定することもできる。ＳｒｃＩＰに対するハッシュ演算の結果によるフィルタリングでは，キャプチャするパケットのＳｒｃＩＰの偏りをなくすことができる。

図７は，ＯＮ／ＯＦＦフィルタ部による処理のフローチャートである。Ｗｅｂサーバ３１−ＡＰサーバ３２間，またはＡＰサーバ３２−ＤＢサーバ３３間からのミラーリングパケットが，それぞれＮｅｔ−ＩＦ１１ｂ，Ｎｅｔ−ＩＦ１１ｃからシステム分析装置１０に入力されると，各区間に対応するＯＮ／ＯＦＦフィルタ部１３（ａ，ｂ）によって，この処理が開始される。

ＯＮ／ＯＦＦフィルタ部１３は，ＯＮ／ＯＦＦフラグ７１に従って，フィルタリング判定を行う（ステップＳ２０）。ＯＮ／ＯＦＦフラグ７１は，前の区間のリクエスト／レスポンス分析部１４によってＳｅｔ／Ｒｅｓｅｔされる。すなわち，Ｗｅｂサーバ３１−ＡＰサーバ３２間に対応するＯＮ／ＯＦＦフィルタ部１３ａは，クライアント４０−Ｗｅｂサーバ３１間に対応するリクエスト／レスポンス分析部１４ａから，ＡＰサーバ３２−ＤＢサーバ３３間に対応するＯＮ／ＯＦＦフィルタ部１３ｂは，Ｗｅｂサーバ３１−ＡＰサーバ３２間に対応するリクエスト／レスポンス分析部１４ｂから，ＯＮシグナルまたはＯＦＦシグナルを受信する。ＯＮシグナルを受信した場合にはフラグＳｅｔ（フラグＯＮ），ＯＦＦシグナルを受信した場合にはフラグＲｅｓｅｔ（フラグＯＦＦ）となる。フィルタリング判定では，フラグのＯＮ／ＯＦＦによって，入力されたパケットを通過させるか否かの判定を行う。

ＯＮ／ＯＦＦフラグ７１がＯＮである場合には（ステップＳ２１），パケットのキャプチャとなり，ＯＮ／ＯＦＦフィルタ部１３ａならリクエスト／レスポンス分析部１４ａに，ＯＮ／ＯＦＦフィルタ部１３ｂならパケットキャプチャ部１６に，パケットを渡す（ステップＳ２２）。ＯＮ／ＯＦＦフラグ７１がＯＦＦである場合には（ステップＳ２１），パケットを廃棄する（ステップＳ２３）。

当該パケットの処理後，後続のパケットがあるかを判定する（ステップＳ２４）。後続のパケットがあれば，ステップＳ２０のフィルタリング判定に戻って次の新しいパケットに対する処理を行う。後続のパケットがなければ，処理を終了する。

後述のリクエスト／レスポンス分析部１４のところで詳細に説明するが，前の区間がレスポンス待ちのときにはＯＮ／ＯＦＦフラグ７１がＯＮとなり，前の区間がレスポンス待ちでないときにはフラグがＯＦＦとなる。つまり，前の区間がレスポンス待ちのときにのみ，当該区間でパケットをキャプチャすることになる（図２参照）。

ＯＮ／ＯＦＦフィルタ部１３では，リクエスト／レスポンスの包含関係を利用して，パケットをキャプチャするか廃棄するかの判定を行っている。そのため，同一のトランザクションに属するパケットをすべてキャプチャすることはできるが，他のトランザクションに属するパケットも一緒にキャプチャしてしまう可能性がある。他のトランザクションに属するパケットについては，パケット解析／トランザクション解析部１７によるトランザクション解析時に判定し，フィルタリングすればよい。

図８は，リクエスト／レスポンス分析部による処理のフローチャートである。クライアント４０−Ｗｅｂサーバ３１間ではＳｒｃＩＰ単位フィルタ部１２から，Ｗｅｂサーバ３１−ＡＰサーバ３２間ではＯＮ／ＯＦＦフィルタ部１３ａからパケットを渡されると，各区間に対応するリクエスト／レスポンス分析部１４（ａ，ｂ）によって，この処理が開始される。

リクエスト／レスポンス分析部１４は，まず，ＴＣＰ／ＵＤＰコネクション分離により，パケットをそのパケットが属するセッションに振り分ける（ステップＳ３０）。ＴＣＰセッションの振り分けには，送受信側のＩＰアドレスとポート番号とを用いて行う。また，宛先ポート番号（サーバ側の受信ポート番号）から，どのサービスに属するセッションであるかを調べる。例えば，サーバ側のポート番号が８０番であった場合には，Ｗｅｂサーバ３１との通信（ＨＴＴＰ）であると判定する。

次に，振り分けられたセッション単位で，パケットがＴＣＰ／ＵＤＰの制御パケットか，データパケットかを判定する（ステップＳ３１）。これは，ＴＣＰヘッダ中のフラグ状態，ＴＣＰデータの有無により判定することができる。具体的には，図５（Ｄ）に示すフラグ中のＲＳＴ，ＳＹＮ，ＦＩＮビットのどれかがＯＮであれば，そのパケットは制御パケットである。図５（Ｄ）に示すフラグ中のＲＳＴ，ＳＹＮ，ＦＩＮビットのすべてがＯＦＦであり，かつＴＣＰデータが存在すれば，そのパケットはデータパケットである。

ステップＳ３１において，パケットが制御パケットである場合には，ＴＣＰ（ＲＦＣ７９３）の処理シーケンスに従い，ＴＣＰ／ＵＤＰ状態管理を行う（ステップＳ３２）。ＴＣＰ／ＵＤＰ状態管理では，新規コネクションが開設されると，そのコネクションが状態管理テーブルに登録され，既存コネクションがクローズされると，そのコネクションが状態管理テーブルから削除される。また，ＴＣＰ／ＵＤＰ状態管理では，状態管理テーブルのＴＣＰ／ＵＤＰ状態の書き換えを行う。

図９は，状態管理テーブルの例を示す図である。図９の例は，クライアント４０−Ｗｅｂサーバ３１間の状態管理テーブル８０である。なお，Ｗｅｂサーバ３１−ＡＰサーバ３２間でも用いるものも，同様の形式である。

図９の状態管理テーブル８０は，送信元ＩＰアドレス（クライアント側），宛先ＩＰアドレス（Ｗｅｂサーバ側），送信元ポート番号，宛先ポート番号，ＴＣＰ／ＵＤＰ状態，メッセージ状態などの情報から構成される。状態管理テーブル８０では，ＴＣＰ／ＵＤＰコネクションごとに，エントリが設けられる。

図９の状態管理テーブル８０において，クライアント側のＩＰアドレスが送信元ＩＰアドレスとなっているのは，クライアント４０からＷｅｂサーバ３１へのリクエストパケットによってコネクションが開設されるからである。すなわち，送信元ＩＰアドレス，宛先ＩＰアドレス，送信元ポート番号，宛先ポート番号は，クライアント４０からＷｅｂサーバ３１へのリクエストパケットから取得されたものである。

状態管理テーブル８０のＴＣＰ／ＵＤＰ状態の項目は，ＴＣＰ／ＵＤＰの状態遷移を示す項目である。図９の状態管理テーブルにおいて，“Ｃｏｎｎｅｃｔｉｎｇ”はコネクションの接続／切断処理中であることを示し，“Ｃｏｎｎｅｃｔｅｄ”はすでにコネクションが確立されていることを示す。ステップＳ３２のＴＣＰ／ＵＤＰ状態管理では，コネクションの状態遷移に応じて，状態管理テーブル８０のＴＣＰ／ＵＤＰ状態の値を書き替える。

ステップＳ３１において，パケットがデータパケットである場合には，メッセージ状態管理を行う（ステップＳ３３）。メッセージ状態管理では，まず，メッセージがリクエストであるかレスポンスであるかを，ＩＰアドレスをキーにパケットの方向で判定する。例えば，クライアント４０−Ｗｅｂサーバ３１間において，クライアント４０からＷｅｂサーバ３１へのパケットの場合，すなわちパケットの送信元ＩＰアドレスがクライアント４０のＩＰアドレスで宛先ＩＰアドレスがＷｅｂサーバ３１のＩＰアドレスである場合には，メッセージはリクエストである。また，Ｗｅｂサーバ３１からクライアント４０へのパケットの場合，すなわちパケットの送信元ＩＰアドレスがＷｅｂサーバ３１のＩＰアドレスで宛先ＩＰアドレスがクライアント４０のＩＰアドレスである場合には，メッセージはレスポンスである。

このような状態変化の結果，メッセージ状態に変化があれば状態管理テーブル８０のメッセージ状態を書き替える。ここでは，メッセージ状態として，次の２つの状態を定義する。

Ｒｅｓｐ−ｗａｉｔ：リクエストを受信した後，レスポンス待ちの状態
Ｎｏ−ｒｅｓｐ−ｗａｉｔ：Ｒｅｓｐ−ｗａｉｔ以外の状態
なお，上記のメッセージ状態は，ＴＣＰ／ＵＤＰ状態がＣｏｎｎｅｃｔｅｄのときにのみ意味を持ち，ＴＣＰ／ＵＤＰ状態がＣｏｎｎｅｃｔｉｎｇのときには，Ｎ／Ａ（Not Applicable：適用外）である。

新規コネクションにおいて，ＴＣＰコネクションが確立された時には，メッセージ状態はＮｏ−ｒｅｓｐ−ｗａｉｔである。その後リクエストを受信したときに，メッセージ状態をＲｅｓｐ−ｗａｉｔに書き替える。その後さらにレスポンスを受信したときに，メッセージ状態をＮｏ−ｒｅｓｐ−ｗａｉｔに書き替える。

メッセージ状態管理の後，状態管理テーブル８０全体のメッセージ状態の遷移チェックを行う（ステップＳ３４）。このとき必要があれば，ＯＮ／ＯＦＦシグナルを次段のＯＮ／ＯＦＦフィルタ部１３に発行する。シグナルを発行するのは，具体的には次のような場合である。

状態管理テーブル８０にＲｅｓｐ−ｗａｉｔがまったくない状態から，新規にＲｅｓｐ−ｗａｉｔが発生した場合：
ＯＮシグナルを，次段のＯＮ／ＯＦＦフィルタ部１３に発行する。このとき，シグナルの発行時刻と種別（この場合にはＯＮシグナル）とを，シグナルテーブルに記録する。

状態管理テーブル８０にＲｅｓｐ−ｗａｉｔがある状態から，まったくない状態になった場合：
ＯＦＦシグナルを，次段のＯＮ／ＯＦＦフィルタ部１３に発行する。このとき，シグナルの発行時刻と種別（この場合にはＯＦＦシグナル）とを，シグナルテーブルに記録する。

図１０は，シグナルテーブルの例を示す図である。シグナルテーブル８１は，シグナルの発行時刻と種別とを，システムの立ち上げ時からシーケンシャルに記録したログ形式のテーブルである。システム立ち上げ時には，システムを起動した時刻が記録される。図１０に示すように，ＯＮシグナルとＯＦＦシグナルとは，必ず交互に出現する。なお，シグナルテーブル８１は，後述の範囲制御部１５の処理において，過去一定時間の間のＯＮ期間，ＯＦＦ期間の総時間を求める際に利用する。

パケットが制御パケットであった場合，パケットがデータパケットであった場合ともに，パケットキャプチャ部１６にパケットを渡す（ステップＳ３５）。その後，後続のパケットがあるかを判定する（ステップＳ３６）。後続のパケットがあれば，ステップＳ３０のＴＣＰ／ＵＤＰコネクション分離に戻って次の新しいパケットに対する処理を行う。後続のパケットがなければ，処理を終了する。

図１１は，範囲制御部による処理のフローチャートである。システムが起動されると，範囲制御部１５によって，この処理が開始される。

範囲制御部１５は，まず，一定時間（例えば，１０分など）スリープし（ステップＳ４０），その間のＯＮ／ＯＦＦレートを算出する（ステップＳ４１）。ＯＮ／ＯＦＦレートの算出では，指定された期間中のＯＦＦ時間の総和に対するＯＮ時間の総和が，シグナルテーブル８１の記録から求められる。

算出されたＯＮ／ＯＦＦレートを，ターゲットＯＮ／ＯＦＦレート７２と比較する（ステップＳ４２）。ターゲットＯＮ／ＯＦＦレート７２は，ＯＮ／ＯＦＦレートのターゲット値（例えば，１／９など）である。ターゲットＯＮ／ＯＦＦレート７２は，管理者によって事前に定義され，運用中に変更されることもある。

ターゲットＯＮ／ＯＦＦレート７２の方が大きければ（ステップＳ４３），キャプチャするＳｒｃＩＰの比率を増加する（ステップＳ４４）。例えば，それまでＳｒｃＩＰの下１桁が“１”のパケットのみをキャプチャしていたのを，ＳｒｃＩＰの下１桁が“１，２”のパケットをキャプチャするように，ＳｒｃＩＰ単位フィルタ部１２のフィルタリングポリシ７０を書き換える。

ターゲットＯＮ／ＯＦＦレート７２の方が小さければ（ステップＳ４３），キャプチャするＳｒｃＩＰの比率を減少する（ステップＳ４５）。例えば，それまでＳｒｃＩＰの下１桁が“１〜３”のパケットをキャプチャしていたのを，ＳｒｃＩＰの下１桁が“１，２”のパケットをキャプチャするように，ＳｒｃＩＰ単位フィルタ部１２のフィルタリングポリシ７０を書き換える。

その後，管理者からの終了指示があるかを判定する（ステップＳ４６），管理者からの終了指示がなければ，ステップＳ４０の一定時間のスリープ状態に戻る。管理者からの終了指示があれば，処理を終了する。

図１２は，ＯＮ／ＯＦＦレートの算出の例を説明する図である。ここでは，現在時刻を12.46.00（単位は［時．分．秒］，以下同様）とし，ＯＮ／ＯＦＦレートとして過去１０分間の〔ＯＮ時間の総和／ＯＦＦ時間の総和〕を求めるものとする。

図１２では，時間軸の左側に，図１０のシグナルテーブル８１のイベントをプロットしている。ただし，秒の小数点以下については四捨五入されている。このようなイベントの発生状況から，ＯＮ期間，ＯＦＦ期間および各期間の時間を求めると，時間軸の右側に示す通りとなる。

例えば，12.37.21にＯＮシグナルが発行され，12.38.05にＯＦＦシグナルが発行されていることから，12.37.21〜12.38.05の区間はＯＮ期間であり，その差から，ＯＮ期間の時間は00.00.44であることが分かる。このように，各区間ごとに，その区間の種別がＯＮ期間かＯＦＦ期間かを判別し，その期間の時間を求める。現在時刻12.46.00から過去１０分間を算出対象区間として計算すると，図１２から，ＯＮ時間の総和，ＯＦＦ時間の総和は，それぞれ３１７秒，２８３秒となる。よって，ＯＮ／ＯＦＦレートは，
ＯＮ時間の総和／ＯＦＦ時間の総和＝３１７／２８３＝１．１２
と求められる。

本実施の形態におけるパケットキャプチャ部１６，パケット解析／トランザクション解析部１７は，通常のパケットキャプチャ処理，パケット解析処理，トランザクション処理を行う。従来の技術であるので，それらの処理の詳細については省略する。なお，原理説明の部分で説明したように，パケットキャプチャ部１６は，キャプチャしたパケットを蓄積するようにしてもよいし，キャプチャと同時にパケット解析／トランザクション解析部１７に渡すようにしてもよい。

〔第２の実施形態〕
図１３は，本発明の第２の実施形態によるシステム分析装置の例を示す図である。本実施形態は，各区間に配備されたスイッチ（ＳＷ６２，６３，６４）のミラーリング出力を，システム分析装置２０の１つのネットワークインタフェースＮｅｔ−ＩＦ１１に入力する形態である。上述の第２の原理に相当する。

システム分析装置２０は，Ｎｅｔ−ＩＦ部１１，ＳｒｃＩＰ単位フィルタ部１２，ＯＮ／ＯＦＦフィルタ部１３（ａ，ｂ），リクエスト／レスポンス分析部１４（ａ，ｂ），範囲制御部１５，パケットキャプチャ部１６，パケット解析／トランザクション解析部１７，区間分離部１８を備える。第１の実施形態のシステム分析装置１０と比較すると，３つあったＮＥＴ−ＩＦ部１１が１つとなり，また新たに区間分離部１８が加わった構成となっている。

サーバシステム自体の構成は，図４の第１の実施形態のサーバシステムの構成と同じである。ただし，ミラーリングパケットをシステム分析装置２０に取り込む部分の構成が，図４の第１の実施形態の構成と異なる。本実施形態では，各区間に配備されたスイッチ（ＳＷ６２，６３，６４）のミラーリング出力は，すべてスイッチ（ＳＷ６０）を経由して，システム分析装置２０に送られる。

また，本実施形態の各装置に設定されたＩＰアドレスも，システム分析装置２０のＮｅｔ−ＩＦ１１に設定されたＩＰアドレス“192.168.4.1 ”以外は，すべて図４の第１の実施形態と同じである。

本実施形態のシステム分析装置２０におけるＳｒｃＩＰ単位フィルタ部１２，ＯＮ／ＯＦＦフィルタ部１３，リクエスト／レスポンス分析部１４，範囲制御部１５，パケットキャプチャ部１６，パケット解析／トランザクション解析部１７での処理は，第１の実施形態のシステム分析装置１０における処理と同様であるので，ここでは説明を省略する。以下では，第１の実施形態のシステム分析装置１０にない区間分離部１８による処理についてのみ説明する。

図１４は，区間分離部による処理のフローチャートである。ミラーリングパケットがＮｅｔ−ＩＦ１１からシステム分析装置２０に入力されると，区間分離部１８によって，この処理が開始される。

区間分離部１８は，区間分離ポリシ７３に従って，区間判定処理を行う（ステップＳ５０）。区間判定処理では，入力されたパケットのＩＰアドレス，ポート番号等のマッチング判定により，入力されたパケットがどの区間を流れるパケットであるかを判定する。区間分離ポリシ７３には，ＩＰアドレスやポート番号などのマッチング判定により，パケットがどの区間でキャプチャされたものかを判定する論理が定義されている。区間分離ポリシ７３は，管理者によって事前に定義され，運用中に変更されることもある。

図１３のサーバシステムの例では，例えば，区間分離ポリシ７３を以下の１）〜３）のように定義すればよい。

１）パケットの送信元ＩＰアドレスまたは宛先ＩＰアドレスが“192.168.1.1 ”である場合には，そのパケットがクライアント４０−Ｗｅｂサーバ３１間を流れるパケットであると判定する。

２）パケットの送信元ＩＰアドレスが“192.168.2.1 ”であり，パケットの宛先ＩＰアドレスが“192.168.2.2 ”である場合，またはパケットの送信元ＩＰアドレスが“192.168.2.2 ”であり，パケットの宛先ＩＰアドレスが“192.168.2.1 ”である場合には，そのパケットがＷｅｂサーバ３１−ＡＰサーバ３２間を流れるパケットであると判定する。

３）パケットの送信元ＩＰアドレスが“192.168.3.1 ”であり，パケットの宛先ＩＰアドレスが“192.168.3.2 ”である場合，またはパケットの送信元ＩＰアドレスが“192.168.3.2 ”であり，パケットの宛先ＩＰアドレスが“192.168.3.1 ”である場合には，そのパケットがＡＰサーバ３２−ＤＢサーバ３３間を流れるパケットであると判定する。

入力されたパケットがクライアント４０−Ｗｅｂサーバ３１間を流れるパケットである場合には，クライアント−Ｗｅｂ間に対応するＳｒｃＩＰ単位フィルタ部１２にパケットを渡す（ステップＳ５１）。

入力されたパケットがＷｅｂサーバ３１−ＡＰサーバ３２間を流れるパケットである場合には，Ｗｅｂサーバ３１−ＡＰサーバ３２間に対応するＯＮ／ＯＦＦフィルタ部１３ａにパケットを渡す（ステップＳ５２）。

入力されたパケットがＡＰサーバ３２−ＤＢサーバ３３間を流れるパケットである場合には，ＡＰサーバ３２−ＤＢサーバ３３間に対応するＯＮ／ＯＦＦフィルタ部１３ｂにパケットを渡す（ステップＳ５３）。

当該パケットの処理後，後続のパケットがあるかを判定する（ステップＳ５４）。後続のパケットがあれば，ステップＳ５０の区間判定処理に戻って次の新しいパケットに対する処理を行う。後続のパケットがなければ，処理を終了する。

以上，２つの実施例で説明した本発明から期待できる効果を簡単に説明する。なお，以下の例では，均質なトラフィックを仮定している。

本発明によれば，システム分析装置１０のＳｒｃＩＰ単位フィルタ部１２によって，クライアント４０−Ｗｅｂサーバ３１間のパケットのフィルタリング範囲をＳｒｃＩＰの範囲を用いて絞ることができる。さらに，範囲制御部１５によって，ＳｒｃＩＰの範囲を調整することができ，ＳｒｃＩＰ単位フィルタ部１２でのサンプリング範囲の絞り込みを動的に変化させることができる。

例えば，ＳｒｃＩＰ単位フィルタ部１２でのクライアント４０−Ｗｅｂサーバ３１間のパケットのサンプリング率を１／１０に絞り込めば，トランザクション解析の処理負荷やトランザクション解析に必要な装置量を１／１０にすることができる。

また，クライアント４０−Ｗｅｂサーバ３１間の後の区間であるＷｅｂサーバ３１−ＡＰサーバ３２間でのパケットのフィルタリングは，リクエスト／レスポンス分析部１４ｂによって，クライアント４０−Ｗｅｂサーバ３１間でのフィルタリング率に連動する。そのため，クライアント４０−Ｗｅｂサーバ３１間のサンプリング率を１／１０に絞り込めば，クライアント４０−Ｗｅｂサーバ３１間の後の区間のサンプリング率も１／１０に絞り込まれると考えられる。

サンプリング率の絞り込みの程度は，トランザクション解析の精度と関係する。統計的処理で±５％の精度を確保するためには，１５００個以上のサンプル数が必要となる。したがって，トランザクション解析の精度を向上させるためには，サンプル数を増やすか，または，サンプリング期間（トランザクション解析の単位時間）を延ばせばよい。なお，トランザクション解析の精度は，サンプリング率のみで直接決定されるわけではない。

例えば，１５，０００トランザクション／秒の入力がある場合に，１秒単位のトランザクション解析で上記の精度を得るためには，１，５００トランザクション／秒のサンプリングを行えばよい。このとき，削減率は，１／１０となる。また，１０秒単位のトランザクション解析で上記の精度を得るためには，１５０トランザクション／秒のサンプリングを行えばよい。このとき，削減率は，１／１００となる。

本発明の第１の原理を説明する原理説明図である。 各区間のリクエスト／レスポンスの期間の包含関係を説明するための図である。 本発明の第２の原理を説明する原理説明図である。 本発明の第１の実施形態によるシステム分析装置の例を示す図である。 パケットのフォーマットの例を示す図である。 ＳｒｃＩＰ単位フィルタ部による処理のフローチャートである。 ＯＮ／ＯＦＦフィルタ部による処理のフローチャートである。 リクエスト／レスポンス分析部による処理のフローチャートである。 状態管理テーブルの例を示す図である。 シグナルテーブルの例を示す図である。 範囲制御部による処理のフローチャートである。 ＯＮ／ＯＦＦレートの算出の例を説明する図である。 本発明の第２の実施形態によるシステム分析装置の例を示す図である。 区間分離部による処理のフローチャートである。 システム分析装置を適用するシステムの例を説明する図である。 システム分析の処理の流れを示す図である。 可視化出力の例を示す図である。 キャプチャおよびトランザクション解析の方法の例を示す図である。

符号の説明

１０，２０ システム分析装置
１１，１１ａ，１１ｂ，１１ｃ ネットワークインタフェース部（ＮＥＴ−ＩＦ）
１２ ソースＩＰ単位フィルタ部（ＳｒｃＩＰ単位フィルタ部）
１３，１３ａ，１３ｂ オン／オフ・フィルタ部（ＯＮ／ＯＦＦフィルタ部）
１４，１４ａ，１４ｂ リクエスト／レスポンス分析部
１５ 範囲制御部
１６ パケットキャプチャ部
１７ パケット解析／トランザクション解析部
１８ 区間分離部
３１ Ｗｅｂサーバ
３２ ＡＰサーバ
３３ ＤＢサーバ
４０，４０ａ，４０ｂ，４０ｃ クライアント
５０ ネットワーク
６０，６１，６２，６３，６４ スイッチ（ＳＷ）

Claims (9)

1. クライアントからのリクエストに応じた所定の処理を複数の層に構成されたサーバで分散して行う多層サーバシステムを，トランザクション単位で分析するシステム分析装置であって，
   クライアントと前記クライアントのリクエスト送信先となる前記多層サーバシステムのサーバとのデータ通信区間であるクライアント−サーバ区間または前記多層サーバシステム内で隣接する層のサーバ同士のデータ通信区間であるサーバ−サーバ区間を流れるパケットからミラーリングされたパケットを区間ごとに分別して取得するネットワークインタフェース部と，
   前記クライアント−サーバ区間を流れるパケットを，前記パケットの送信元であるクライアントのアドレス情報をもとにフィルタリングする第１のフィルタリング部と，
   外部からの制御信号によって，前記サーバ−サーバ区間を流れるパケットを取得するオン期間または前記パケットを廃棄するオフ期間とが切り替え可能に設定され，前記オン期間またはオフ期間の設定に応じて前記パケットをフィルタリングする第２のフィルタリング部と，
   前記クライアント−サーバ区間または前記サーバ−サーバ区間のうち予め対応付けられた一つの区間から取得されたパケットを判定し，当該パケットのメッセージ状態から当該区間のリクエスト送信側がレスポンス待ちである期間を特定し，前記期間に連動させて当該区間の次のサーバ−サーバ区間のパケットをフィルタリングする前記第２のフィルタリング部の前記オン期間または前記オフ期間の設定を制御するリクエスト／レスポンス分析部と，
   前記第１のフィルタリング部または前記第２のフィルタリング部において通過したパケットを取得するパケットキャプチャ部とを備える
   ことを特徴とするシステム分析装置。
2. 前記ネットワークインタフェース部は，前記クライアント−サーバ区間と前記サーバ−サーバ区間の各区間に対応した複数の構成部として備えられ，前記対応する区間でミラーリングされたパケットを取得する
   ことを特徴とする請求項１に記載されたシステム分析装置。
3. 前記ネットワークインタフェース部によって取得されたパケットを，当該パケットが流れていた各区間に分離する区間分離部を備え，
   前記ネットワークインタフェース部は，単一の構成部として備えられ，前記クライアント−サーバ区間と前記サーバ−サーバ区間とを流れるパケットからミラーリングされたパケットを集約して取得して，前記区間分離部へ送出する
   ことを特徴とする請求項１に記載されたシステム分析装置。
4. 前記第１のフィルタリング部は，前記クライアント−サーバ区間を流れるパケットを，当該パケットの送信元ＩＰアドレスごとに所定の割合で取得する
   ことを特徴とする請求項１ないし請求項３のいずれか一項に記載されたシステム分析装置。
5. 前記第１のフィルタリング部によって通過されたパケットのメッセージ状態をもとに，前記クライアント側のレスポンス待ちの期間と当該レスポンス待ち以外の期間とを特定し，前記２つの期間が所定の比率となるように，前記第１のフィルタリング部におけるフィルタリングの前記所定の割合を変更する範囲制御部を備える
   ことを特徴とする請求項４に記載されたシステム分析装置。
6. 前記第１のフィルタリング部は，パケットを取得するクライアントの範囲を前記クライアントのＩＰアドレスの全部または一部を用いて特定するフィルタリングポリシを備えて，前記クライアント−サーバ区間を流れるパケットのなかから，前記フィルタリングポリシに合致する送信元ＩＰアドレスを持つパケットを取得する
   ことを特徴とする請求項１ないし請求項３のいずれか一項に記載されたシステム分析装置。
7. 前記第１のフィルタリング部は，前記クライアント−サーバ区間を流れるパケットの送信元ＩＰアドレスにハッシュ演算を行い，前記ハッシュ演算結果が所定の範囲となるパケットを取得する
   ことを特徴とする請求項１ないし請求項３のいずれか一項に記載されたシステム分析装置。
8. 前記リクエスト／レスポンス分析部は，前記対応する区間からフィルタリングされたパケットのメッセージ状態を判定し，前記判定結果から前記区間のリクエスト送信側がリクエストを発行した時に，前記第２のフィルタリング部にオン期間を設定する制御信号を送信し，前記リクエスト送信側がレスポンスを受信した時に前記第２のフィルタリング部にオフ期間を設定する制御信号を送信する
   ことを特徴とする請求項１ないし請求項３のいずれか一項に記載されたシステム分析装置。
9. クライアントからのリクエストに応じた所定の処理を複数の層に構成されたサーバで分散して行う多層サーバシステムを，トランザクション単位で分析するシステム分析方法であって，
   クライアントと前記クライアントのリクエスト送信先となる前記多層サーバシステムのサーバとのデータ通信区間であるクライアント−サーバ区間または前記多層サーバシステム内で隣接する層のサーバ同士のデータ通信区間であるサーバ−サーバ区間を流れるパケットからミラーリングされたパケットを区間ごとに分別して取得する処理過程と，
   前記クライアント−サーバ区間を流れるパケットを，前記パケットの送信元であるクライアントのアドレス情報をもとにフィルタリングする処理過程と，
   外部からの制御信号によって，前記サーバ−サーバ区間を流れるパケットを取得するオン期間または前記パケットを廃棄するオフ期間とが切り替え可能に設定され，前記オン期間またはオフ期間の設定に応じて前記パケットをフィルタリングする処理過程と，
   前記クライアント−サーバ区間または前記サーバ−サーバ区間のうち予め対応付けられた一つの区間から取得されたパケットを判定し，当該パケットのメッセージ状態から当該区間のリクエスト送信側がレスポンス待ちである期間を特定し，前記期間に連動させて当該区間の次のサーバ−サーバ区間のパケットをフィルタリングする前記第２のフィルタリング部の前記オン期間または前記オフ期間の設定を制御する処理過程と，
   前記第１のフィルタリング部または前記第２のフィルタリング部において通過したパケットを取得する処理過程とを備える
   ことを特徴とするシステム分析方法。
   

Images