JP5655687B2 - 解析処理装置，解析処理プログラムおよび解析処理方法 - Google Patents

Description

本発明は，情報システムの状態を分析する解析処理装置，解析処理プログラムおよび解析処理方法に関するものである。

情報システムにおけるメッセージを解析することで，情報システムの状態を監視するシステム可視化の技術がある。この技術では，例えば，ミラーリングなどにより監視対象の情報システムから通信パケットをキャプチャし，キャプチャした通信パケットからメッセージを生成し，メッセージのリクエストとレスポンスとを監視することで，情報システムの状態を判断する。

また，システム可視化において，情報システムの分析を行う装置は，処理量が膨大となるため，複数のＣＰＵで処理を分散して行うこともある。

なお，サーバ間のパケットをキャプチャし，トランザクション解析を行うシステム分析装置において，トランザクション単位でパケットのサンプリングを行う技術が知られている。また，ストリームデータを並列処理する装置において，許容遅延時間の範囲内で蓄積時間を設定し，蓄積時間の間データを蓄積した後に，制御ノード装置から処理ノード装置にデータを送信する技術が知られている。

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

上述のように，情報システムの分析を行う装置は，情報システムの通信パケットを監視し，リクエストとレスポンスのメッセージを解析することで，情報システムの状態を検出する。このとき，メッセージ解析処理では，通信パケットからメッセージを生成し，メッセージ内容を分析する処理が行われる。このメッセージ生成と内容分析の処理は，ＣＰＵの負荷が大きく，ＣＰＵリソースが少ないと，リアルタイムに大量の通信パケットを処理できないといった問題が存在する。

この問題への対策として，マルチＣＰＵ環境では，コネクション単位に複数のＣＰＵに負荷分散させ，並列処理することで，メッセージ解析の処理能力を上げる方法が考えられる。このとき，コネクションを分散するアルゴリズムでは，コネクション接続時にラウンドロビンで順番にＣＰＵを割り振る，最もコネクション数が少ないＣＰＵを選択する，といった負荷分散方法が用いられる。しかし，これらの負荷分散方法は，必ずしも，メッセージ解析の処理量を各ＣＰＵに対して均等に分散することを考慮した方法とはなっていない。

一側面では，本発明は，情報システムにおけるメッセージの解析を行う際に，各プロセッサの負荷が均等化されるようにすることを目的とする。

１態様では，解析処理装置は，ネットワークで接続されたコンピュータ間で送受信される通信パケットから組み立てられるメッセージを解析する複数の制御部と，リクエストメッセージから抽出されるリクエスト種別単位に，リクエストに対するレスポンスメッセージのデータ量と解析に要した処理時間とを蓄積する蓄積部と，蓄積部に蓄積された情報からレスポンスメッセージのデータ量と処理時間との関係式を算出する算出部と，関係式を用いて，リクエスト種別に対応するレスポンスメッセージのデータ量の統計データをもとにレスポンスメッセージのデータを解析する処理時間を予測する予測部と，予測した処理時間をもとに，レスポンスメッセージのデータを解析する制御部を選択し，該制御部にレスポンスメッセージのデータの解析処理を振り分ける振り分け部とを備える。

１態様では，情報システムにおけるメッセージの解析を行う際に，各プロセッサの負荷が均等化される。

本実施の形態による解析処理装置の機能構成例を示す図である。 本実施の形態による解析処理装置が用いられる情報システムの例を示す図である。 リクエスト種別ごとのレスポンスデータ量と処理時間との関係の例を示す図である。 時間推移によるレスポンスデータ量の変化の例を示す図である。 本実施の形態による解析処理装置のハードウェア構成例を示す図である。 本実施の形態によるコネクション情報テーブルの一例を示す図である。 本実施の形態による履歴情報テーブルの一例を示す図である。 本実施の形態によるＣＰＵ予定処理時間テーブルの一例を示す図である。 本実施の形態による振り分け用テーブルの一例を示す図である。 パケットの構成を示す図である。 ＴＣＰコネクションの接続シーケンスの一例を示す図である。 本実施の形態のマルチプロセッサによるメッセージ単位でのパケットの分散処理シーケンスを示す図である。 本実施の形態のＣＰＵ（＃０）によるコネクション解析処理フローチャートである。 本実施の形態のＣＰＵ（＃０）によるコネクション解析処理フローチャートである。 本実施の形態のＣＰＵ（＃１）またはＣＰＵ（＃２）によるレスポンスメッセージ解析処理フローチャートである。

以下，本実施の形態について，図を用いて説明する。

図１は，本実施の形態による解析処理装置の機能構成例を示す図である。

図１に示す解析処理装置１は，情報システムの通信パケットを取り込み，通信パケットから情報システムの状態を分析する。解析処理装置１は，パケット受信部１０，算出部１１，データ量推測部１２，予測部１３，振り分け部１４，メッセージ解析部１５，蓄積部１６を備える。

パケット受信部１０は，ネットワークで接続されたコンピュータ間で送受信されるメッセージを所定の単位で分割したパケットを受信する。

算出部１１は，過去に解析されたレスポンスメッセージのデータ量と解析に要した処理時間との履歴情報をもとに，レスポンスメッセージのデータ量と処理時間との関係式を算出する。この履歴情報は，リクエスト種別単位に蓄積されており，関係式は，リクエスト種別単位に算出される。

データ量推測部１２は，リクエストメッセージを受信したときに，そのリクエスト種別に対応するレスポンスメッセージのデータ量を推測する。このデータ量の推測値としては，例えば最近の同じリクエスト種別に対する所定時間内または所定個数のレスポンスメッセージのデータ量の平均値などの統計データが用いられる。

予測部１３は，データ量推測部１２が推測したレスポンスメッセージのデータ量から，算出部１１が算出した関係式を用いて，そのレスポンスメッセージのデータの解析処理時間を予測する。

振り分け部１４は，予測した解析処理時間から，レスポンスメッセージのデータを解析するメッセージ解析部１５の一つを選択し，該メッセージ解析部１５にレスポンスメッセージのデータの解析処理を振り分ける。このとき，振り分け部１４は，各メッセージ解析部１５ａ，１５ｂ，... の解析処理時間が全体として平均化するように，解析処理を振り分ける。

メッセージ解析部１５ａ，１５ｂ，... は，それぞれ制御部１７ａ，１７ｂ，... ，すなわちマルチプロセッサにおける個々のプロセッサで動作し，振り分けられたメッセージの解析処理を実行する。メッセージ解析部１５は，ネットワークで接続されたコンピュータ間で送受信される通信パケットから組み立てられるメッセージの解析を行う。

蓄積部１６ａ，１６ｂ，... は，それぞれメッセージ解析部１５ａ，１５ｂ，... が解析したレスポンスメッセージのデータ量と解析に要した処理時間とを，リクエスト種別単位に蓄積する。この履歴情報は，算出部１１によって参照される。

算出部１１が関係式の算出に用いるメッセージのデータ量は，レスポンスメッセージのデータ量である。以下，レスポンスメッセージのデータ量を，レスポンスデータ量とも呼ぶ。データ量推測部１２が推測するメッセージのデータ量も，レスポンスデータ量である。これは，一般にリクエストメッセージのデータ量に比べてレスポンスメッセージのデータ量の方が多いので，解析処理時間の負荷はレスポンスデータの方が大きくなるからである。

図２は，本実施の形態による解析処理装置が用いられる情報システムの例を示す図である。

図２に示す情報システムでは，複数のコンピュータ３（３ａ，３ｂ，３ｃ，... ）がネットワーク２で接続され，複数のコンピュータ３間でメッセージが送受信される。メッセージは，所定の単位でパケットに分割され，各パケットのヘッダに含まれる宛先情報によって，スイッチ４を介して通信先のコンピュータ３に送られる。パケットとは，通信モデルの一つであるＴＣＰ／ＩＰ（Transmission Control Protcol/Internet Protocol）モデルの中のインターネットレイヤでの送信単位である。

メッセージには，あるコンピュータ３に対して何らかの処理を要求するリクエストメッセージと，処理要求を受けたコンピュータ３が処理結果として応答するレスポンスメッセージとがある。

解析処理装置１は，スイッチ４のミラーリング機能を用いて，各コンピュータ３間で送受信されるパケットを受信し，受信したパケットからメッセージを再構成し，そのメッセージを解析することにより，情報システムの状態を分析する。すなわち，解析処理装置１は，コンピュータ３間で送受信されるリクエストメッセージ，レスポンスメッセージ等を監視し，分析することにより，通信しているコンピュータ３同士の稼働状態，通信状態等を把握することができる。

解析対象となるメッセージのデータ量は膨大であるため，解析処理装置１は，マルチプロセッサ環境でメッセージ解析処理の負荷分散を行っている。このとき，解析処理の負荷が均等になるように，各プロセッサに各メッセージの受信パケットを振り分ける必要がある。本実施の形態の技術では，メッセージ解析処理のためのパケットの振り分けが，各プロセッサにおける処理時間ができるだけ均等になるように行われる。

本実施の形態の技術をさらに詳しく説明する。

メッセージ解析処理は，リクエスト種別ごとに異なり，データ量と処理時間とが比例するものもあれば，処理時間が一定のものもあり，処理時間のバラツキが存在する。このバラツキを解消するために，算出部１１は，リクエストのメッセージ解析処理を行いながら，リクエスト種別単位にレスポンスデータ量と処理時間との近似関係式を算出する。近似関係式は，例えば最小二乗法などの周知の分析手法を用いて算出することができる。

図３は，リクエスト種別ごとのレスポンスデータ量と処理時間との関係の例を示す図である。

図３（Ａ）は，リクエスト種別が，例えば，電子掲示板に投稿するなどの「ＰＯＳＴ ＵＲＬ１」である場合の例を示す。また，図３（Ｂ）は，リクエスト種別が，例えば，未読メールを読み込むような「ＧＥＴ ＵＲＬ２」である場合の例を示す。また，図３（Ｃ）は，リクエスト種別が，例えば，画像データを取得する「ＧＥＴ ＵＲＬ３」である場合の例を示す。

例えば，図３（Ａ）に示すように，同じリクエスト種別，同じレスポンスデータ量であっても，メッセージ解析の処理時間には，ある程度のバラツキが生じる。このことは，図３（Ｂ）や図３（Ｃ）の例についても同様である。図３において，楕円は，同じリクエスト種別のメッセージに対する処理において，メッセージごとのレスポンスデータ量と処理時間との関係のバラツキを表す。

また，例えば，図３（Ａ）に示すリクエスト種別が「ＰＯＳＴ ＵＲＬ１」である場合と，図３（Ｂ）に示すリクエスト種別が「ＧＥＴ ＵＲＬ２」である場合には，傾き等に違いはあるが，レスポンスデータ量と処理時間とが比例する傾向にある。一方，図３（Ｃ）に示すリクエスト種別が「ＧＥＴ ＵＲＬ３」である場合には，処理時間がほぼ一定となっている。一般に画像データに対するレスポンスデータ量は一定であり，解析の処理時間も一定となる。

このように，レスポンスデータ量と処理時間との関係には，バラツキはあっても，リクエスト種別ごとの傾向がある。

そこで，図３に示すようなリクエスト種別ごとのレスポンスデータ量と処理時間との関係をつかむために，算出部１１は，各蓄積部１６ａ，１６ｂ，... が蓄積した履歴情報を利用して，近似関係式を算出する。各蓄積部１６ａ，１６ｂ，... は，メッセージ解析部１５ａ，１５ｂ，... が実際にメッセージ解析処理を実行した結果のレスポンスデータ量と処理時間とを，リクエスト種別ごとに記憶装置に蓄積しておく。

図４は，時間推移によるレスポンスデータ量の変化の例を示す図である。

図４（Ａ）は，リクエスト種別が，例えば，電子掲示板に投稿するなどの「ＰＯＳＴ ＵＲＬ１」である場合の例を示す。また，図４（Ｂ）は，リクエスト種別が，例えば，未読メールを読み込むような「ＧＥＴ ＵＲＬ２」である場合の例を示す。また，図４（Ｃ）は，リクエスト種別が，例えば，画像データを取得する「ＧＥＴ ＵＲＬ３」である場合の例を示す。

動的レスポンスデータは，時間推移とともに変化する。例えば，掲示板などのリスト構造の場合には，図４（Ａ）に示すように，時間が経過するに従って，徐々にレスポンスデータ量が増加するケースがある。また，例えば，メールの未読表示などの場合には，図４（Ｂ）に示すように，時間の流れとともに，レスポンスデータ量が増えたり減ったりするケースがある。画像データ表示などの場合には，図４（Ｃ）に示すように，レスポンスデータ量がほぼ一定であるケースが多い。

新しいレスポンスメッセージを解析処理するにあたって，そのレスポンスデータ量を推測する場合，どのケースでもレスポンスデータ量は直後のデータ量に近い。このため，データ量推測部１２は，例えば，最近のある一定時間内のレスポンスデータ量の平均から，これから受信するレスポンスデータ量を推測する。一定時間内にレスポンスデータがない場合には，一定個数のレスポンスデータ量の平均から，これから受信するレスポンスデータ量を推測するようにしてもよい。

なお，レスポンスデータ量と処理時間とのバラツキを比較した場合，処理時間には，システム処理などの，メッセージ解析処理以外の処理にも同時にＣＰＵが使われるケースも，含まれていることが考えられる。そこで，予測部１３が新しいレスポンスデータの解析処理時間を予測する場合，履歴情報の処理時間を直接指標とするよりも，レスポンスデータ量を指標としたほうがバラツキが少ないと考えられる。

つまり，予測部１３は，最近のある一定時間のレスポンスデータ量の平均を求めた後に，近似関係式から処理時間を求める方が，正確な処理時間を予測することが可能になる。その結果，振り分け部１４は，リクエストメッセージを解析した時点で，レスポンスデータ解析の処理量にバラツキがあっても均等にＣＰＵリソースが用いられるように，レスポンスデータの振り分け先ＣＰＵを決めることができる。すなわち，予測部１３は，データ量推測部１２が推測したレスポンスデータ量をもとに処理時間を予測し，求めた処理時間で振り分け先ＣＰＵを決定する。

以上の処理によって，バラツキのあるレスポンスメッセージ解析処理の効率的な負荷分散を実現することができる。

図５は，本実施の形態による解析処理装置のハードウェア構成例を示す図である。

解析処理装置１は，複数のＣＰＵ２０，すなわちＣＰＵ（＃０）２０ａ，ＣＰＵ（＃１）２０ｂ，ＣＰＵ（＃２）２０ｃを有するマルチプロセッサシステムとなっている。なお，図５に示す例ではＣＰＵ２０の数は３つであるが，ＣＰＵ２０の数は２つ以上であればいくつでもよい。

解析処理装置１は，メモリ２１，ハードディスクや半導体記憶装置などの記憶装置２３，入力装置２６が接続される入出力Ｉ／Ｆ（Interface ）２４，出力装置２７が接続される入出力Ｉ／Ｆ２５を備える。また，解析処理装置１は，ネットワークに接続するためのＮＩＣ（Network Interface Card）２８を備える。ＮＩＣ２８は，スイッチ４のミラーポートに接続されている。スイッチ４は，監視対象のコンピュータ通信の通信路をスイッチングしており，受信したパケットをミラーリング接続でＮＩＣ２８に伝達する。

記憶装置２３には，パケット受信プログラム３１，メッセージ解析プログラム３２を含む解析処理アプリケーション３０およびオペレーティングシステム３３が格納されている。オペレーティングシステム３３，解析処理アプリケーション３０は，起動時にメモリ２１にロードされ，ＣＰＵ（＃０）２０ａ等のコンピュータにメッセージ解析のための処理を実行させる。

特に，パケット受信プログラム３１は，ＮＩＣ２８に到達したパケットを，ＮＩＣ２８のプロミスキャスモードを用いてオペレーティングシステム３３を経由して取り込む処理を，コンピュータに実行させる。また，メッセージ解析プログラム３２は，パケット受信プログラム３１によって受信したパケットで構成されるメッセージを解析する処理を，コンピュータに実行させる。プロミスキャスモードとは，宛先が自装置宛でないパケットも受信するモードである。

パケット受信プログラム３１は，パケットを受信して，そのパケットについてメッセージ解析を行うＣＰＵ２０の一つに割り当てる処理を，例えばＣＰＵ（＃０）２０ａに実行させるプログラムである。メッセージ解析プログラム３２は，パケットを割り当てられたＣＰＵ２０，例えばＣＰＵ（＃１）２０ｂやＣＰＵ（＃２）２０ｃで実行される。

また，記憶装置２３またはメモリ２１には，メッセージ解析処理に用いるコネクション情報テーブル３４，振り分け用テーブル３５，履歴情報テーブル３６，ＣＰＵ予定処理時間テーブル３７が設けられる。

メモリ２１のバッファ２２ａは，例えばＣＰＵ（＃１）２０ｂが使用するバッファであり，バッファ２２ｂは，ＣＰＵ（＃２）２０ｃが使用するバッファである。受信パケットは，これらのバッファ２２ａ，２２ｂに格納され，各ＣＰＵ（＃１）２０ｂ，ＣＰＵ（＃２）２０ｃに振り分けられる。

図６は，本実施の形態によるコネクション情報テーブルの一例を示す図である。

図６に示すコネクション情報テーブル３４は，接続先ＩＰアドレス，接続先ポート番号，接続元ＩＰアドレス，接続元ポート番号，コネクション番号のデータ項目を持つ。各ＴＣＰコネクションごとに，接続先ＩＰアドレスの項目には，接続先のＩＰアドレスが格納される。接続先ポート番号の項目には，接続先のポート番号が格納される。接続元ＩＰアドレスの項目には，接続元のＩＰアドレスが格納される。接続元ポート番号の項目には，接続元のポート番号が格納される。コネクション番号の項目には，コネクションを一意に識別するコネクション番号が格納される。

なお，「接続先」とは，コネクションを確立する際に，接続を要求された側をいう。「接続元」とは，コネクションを確立する際に，接続を要求した側をいう。以下，接続先ＩＰアドレス，接続先ポート番号，接続元ＩＰアドレス，接続元ポート番号，コネクション番号を含む１組の情報をコネクション情報と呼ぶ。

図７は，本実施の形態による履歴情報テーブルの一例を示す図である。

図７に示す履歴情報テーブル３６には，リクエスト種別単位に，実際に解析されたレスポンスデータ量と，解析処理に要した処理時間と，解析処理の開始時刻の履歴情報が格納される。図７に示す履歴情報テーブル３６において，レスポンスデータ量の単位はバイト［Ｂ］であり，処理時間の単位は秒［ｓｅｃ］である。

ここでは，リクエスト種別としてＨＴＴＰリクエストの例を示したが，リクエスト種別は，処理要求のメッセージの種類を示す情報であればよく，ＨＴＴＰリクエストに限られない。ちなみに，「ＳＥＬＥＣＴ ＴＡＢＬＥ１」は，ＳＱＬによる関係データベースのテーブル検索要求である。

図８は，本実施の形態によるＣＰＵ予定処理時間テーブルの一例を示す図である。

図８に示すＣＰＵ予定処理時間テーブル３７は，ＣＰＵ２０単位に予定処理時間が格納されるテーブルである。図８に示すＣＰＵ予定処理時間テーブル３７において，ＣＰＵ番号は，ＣＰＵ２０を特定する識別情報である。図８に示すＣＰＵ予定処理時間テーブル３７には，各ＣＰＵ２０に対して割り当てられたメッセージ解析対象となるコネクションのコネクション番号と，その予定処理時間とが格納され，また，各ＣＰＵ２０の予定処理時間の合計値が格納される。図８に示すＣＰＵ予定処理時間テーブル３７において，予定処理時間と予定処理時間合計の単位は秒［ｓｅｃ］である。

図９は，本実施の形態による振り分け用テーブルの一例を示す図である。

図９に示す振り分け用テーブル３５は，コネクション番号ごとに，振り分け先ＣＰＵ２０を示す振り分け先ＣＰＵ番号と，リクエスト種別との情報が格納されるテーブルである。

図１０は，パケットの構成を示す図である。

パケットは，図１０（Ａ）に示すように，ＩＰヘッダ，ＴＣＰヘッダ，ＴＣＰデータを含む。

ＩＰヘッダは，図１０（Ｂ）に示すようなデータ構造を持つ。ＩＰヘッダには，バージョン，ヘッダ長，サービスタイプ，データグラム長，識別子，各種のフラグ，フラグメントオフセット，生存時間，プロトコル，ヘッダチェックサム，送信元ＩＰアドレス，送信先ＩＰアドレス，オプション，パディングの項目が格納される。

ＴＣＰヘッダは，図１０（Ｃ）に示すようなデータ構造を持つ。ＴＣＰヘッダには，送信元ポート番号，送信先ポート番号，シーケンス番号，確認応答番号，ヘッダ長，予約ビット，フラグ，ウィンドウサイズ，チェックサム，緊急ポインタ，オプション，パディングの項目が格納される。

図１１は，ＴＣＰコネクションの接続シーケンスの一例を示す図である。

ここでは，接続シーケンスの例として，スリーウェイハンドシェイクによるＴＣＰコネクションの確立について説明する。

図１１において，最初に，接続を要求する側のコンピュータすなわちクライアントは，接続を要求される側のコンピュータすなわちサーバに，ＴＣＰヘッダ内のＳＹＮを示すフラグが立ったＳＹＮパケットを送信する。サーバは，ＴＣＰヘッダ内でＳＹＮフラグとＡＣＫフラグが立ったＳＹＮ ＡＣＫパケットをクライアントへ送信する。クライアントは，ＡＣＫフラグが立ったＡＣＫパケットをサーバへ送る。これにより，クライアントとサーバの間のコネクションが確立し，コネクション接続状態となる。なお，接続を要求する側から接続を要求される側への接続方向を「上り」といい，その反対方向を「下り」という。

ＴＣＰコネクションの切断は，次のように行われる。ＴＣＰコネクションを切断しようとする側から相手側に，ＴＣＰヘッダ内のＦＩＮを示すフラグが立ったＦＩＮパケットを送信する。これに対して，相手側は，ＴＣＰコネクションを切断しようとする側にＡＣＫパケットを送信し，片方向のコネクションが開放される。さらに，相手側は，ＴＣＰコネクションを切断しようとする側にＦＩＮパケットを送信し，ＴＣＰコネクションを切断しようとする側は，相手側にＡＣＫパケットを返信する。これにより，もう片方向のコネクションも開放される。

図１２は，本実施の形態のマルチプロセッサによるメッセージ単位でのパケットの分散処理シーケンスを示す図である。

図１１で説明したコネクション接続状態において送受信されるメッセージ単位でのパケットを，マルチプロセッサのＣＰＵ（＃０）２０ａ，ＣＰＵ（＃１）２０ｂ，ＣＰＵ（＃２）２０ｃが，次のように処理する。

ＣＰＵ（＃０）２０ａは，ＮＩＣ２８から送られたパケットを受信すると（処理５０），パケットのヘッダ情報を参照することによりコネクションを解析し（処理５１），パケットの送信方向を識別する。ＣＰＵ（＃０）２０ａは，パケットの送信方向が「上り」であるか「下り」であるかを判定する（処理５２）。パケットの送信方向が「上り」であれば（処理５２の上り），ＣＰＵ（＃０）２０ａは，処理５３〜処理５７を実行する。パケットの送信方向が「下り」であれば（処理５２の下り），ＣＰＵ（＃０）２０ａは，処理５８を実行する。

パケットの送信方向が「上り」である場合（処理５２の上り），ＣＰＵ（＃０）２０ａは，まず，そのパケットを含んで構成されるリクエストメッセージの組み立てを行い，リクエスト内容を解析する（処理５３）。ＣＰＵ（＃０）２０ａは，リクエスト内容の解析によって，要求の種類を示すリクエスト種別を得る。ＣＰＵ（＃０）２０ａは，履歴情報テーブル３６からそのリクエスト種別に対応する履歴情報を読み込み，過去に蓄積されたレスポンスデータ量と処理時間とから，これらの近似関係式を算出する（処理５４）。

次に，ＣＰＵ（＃０）２０ａは，同じく履歴情報テーブル３６から得た最近のレスポンスデータ量の平均値を算出する（処理５５）。ＣＰＵ（＃０）２０ａは，算出した平均値から，現在のリクエストメッセージに対するレスポンスメッセージのレスポンスデータ量を推測する。ＣＰＵ（＃０）２０ａは，推測したレスポンスデータ量に対して解析に要する処理時間を，処理５４で算出した近似関係式を用いて算出する（処理５６）。

ＣＰＵ（＃０）２０ａは，算出した処理時間から振り分け先のＣＰＵ２０を決定し，振り分け用テーブル３５に設定する（処理５７）。すなわち，ＣＰＵ（＃０）２０ａは，図９に示す振り分け用テーブル３５に，コネクション番号と，振り分け先ＣＰＵ番号と，リクエスト種別を設定する。ＣＰＵ（＃０）２０ａが振り分け先のＣＰＵ２０を決定する際には，後に詳しく説明するように，図８に示すＣＰＵ予定処理時間テーブル３７を参照し，各ＣＰＵ２０の予定処理時間の合計値が均等になるように，振り分け先のＣＰＵを選択する。

パケットの送信方向が「下り」である場合（処理５２の下り），そのパケットはレスポンスメッセージのパケットである。このとき，ＣＰＵ（＃０）２０ａは，振り分け用テーブル３５を参照して，そのパケットを振り分け先のＣＰＵ２０，ここではＣＰＵ（＃１）２０ｂまたはＣＰＵ（＃２）２０ｃに振り分ける（処理５８）。

各ＣＰＵ（＃１）２０ｂ，ＣＰＵ（＃２）２０ｃは，振り分けられたパケットからレスポンスメッセージを組み立てて，レスポンスメッセージを解析する（処理６０，６０’）。各ＣＰＵ（＃１）２０ｂ，ＣＰＵ（＃２）２０ｃが，どのような解析処理を行うかについては任意であり，本実施の形態の要旨ではないので，ここでの解析処理の内容についての説明は割愛する。

各ＣＰＵ（＃１）２０ｂ，ＣＰＵ（＃２）２０ｃは，レスポンスメッセージの解析処理にともない，レスポンスデータ量を取得するともに（処理６１，６１’），処理時間を計測する（処理６２，６２’）。各ＣＰＵ（＃１）２０ｂ，ＣＰＵ（＃２）２０ｃは，それらの結果をもとに，履歴情報テーブル３６のデータを更新する（処理６３，６３’）。

図１３，図１４は，本実施の形態のＣＰＵ（＃０）によるコネクション解析処理フローチャートである。

ＣＰＵ（＃０）２０ａは，ＮＩＣ２８から送られたパケットを受信したかを判定する（ステップＳ１０）。

パケットを受信した場合には（ステップＳ１０の真），ＣＰＵ（＃０）２０ａは，パケットのヘッダ情報を参照することにより，コネクション情報を取得する（ステップＳ１１）。コネクション情報は，接続先ＩＰアドレス，接続先ポート番号，接続元ＩＰアドレス，接続元ポート番号等の情報である。

ＣＰＵ（＃０）２０ａは，ステップＳ１１で取得したコネクション情報をもとに，コネクション情報テーブル３４を検索する（ステップＳ１２）。ＣＰＵ（＃０）２０ａは，コネクション情報テーブル３４から，ステップＳ１１で取得したコネクション情報に一致するコネクション情報が検出されたかを判定する（ステップＳ１３）。一致するコネクション情報が検出された場合には（ステップＳ１３の真），ＣＰＵ（＃０）２０ａは，ステップＳ１４に進む。一致するコネクション情報が検出されなかった場合には（ステップＳ１３の偽），ＣＰＵ（＃０）２０ａは，ステップＳ２５に進む。

一致するコネクション情報が検出された場合（ステップＳ１３の真），ＣＰＵ（＃０）２０ａは，コネクションの接続方向が上りであると特定する（ステップＳ１４）。ＣＰＵ（＃０）２０ａは，受信した上りパケットからリクエストメッセージの組み立てを行う（ステップＳ１５）。ＣＰＵ（＃０）２０ａは，リクエストメッセージを組み立てた後，リクエスト内容を解析する（ステップＳ１６）。

リクエスト内容の解析とは，リクエストメッセージについて，プロトコルの種類ごとに解析を行うことにより，クライアントからサーバへの要求の種類を示すリクエスト種別と，要求に付随する設定値を示すリクエストパラメータを取り出す処理のことである。なお，リクエストパラメータが存在しない場合もある。

例えば，リクエスト種別とリクエストのパラメータは，ＨＴＴＰプロトコルの場合（ＰＯＳＴ ／ｃｇｉ−ｂｉｎ／ｘｘｘ．ｃｇｉ？ 名前１＝値１＆名前２＝値２），リクエスト種別がメソッド（ＰＯＳＴ）＋ＵＲＬ（／ｃｇｉ−ｂｉｎ／ｘｘｘ．ｃｇｉ），リクエストのパラメータがＣＧＩパラメータ（名前１＝値１＆名前２＝値２）となる。また，リクエスト種別とリクエストのパラメータは，ＤＢプロトコルの場合，例えば「ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔａｂｌｅ１ ＷＨＥＲＥ ＮＡＭＥ＝＊＊＊＊」というようなＳＱＬ文を取り出したとすると，次のようになる。コマンド部分（ＳＥＬＥＣＴ ＊ ＦＲＯＭ ｔａｂｌｅ１）がリクエスト種別，リクエストのパラメータが引数（ＮＡＭＥ＝＊＊＊＊）になる。

ＣＰＵ（＃０）２０ａは，履歴情報テーブル３６に蓄積された“リクエスト種別単位のレスポンスデータ量と処理時間と時刻”の履歴情報から，過去の該当リクエスト種別のレスポンスデータ量と処理時間とを取得する（ステップＳ１７）。ＣＰＵ（＃０）２０ａは，取得したレスポンスデータ量と処理時間とをもとに，最小二乗法などを用いて，レスポンスデータ量と処理時間との近似関係式を算出する（ステップＳ１８）。

ＣＰＵ（＃０）２０ａは，例えば，現在時間から１分以内のレスポンスメッセージのデータ量を，履歴情報テーブル３６から取得する（ステップＳ１９）。なお，現在時間から１分以内のデータがない場合に，ＣＰＵ（＃０）２０ａが，新しい方から１０個以内のレスポンスメッセージのデータ量を取得する，などの実施も可能である。ＣＰＵ（＃０）２０ａは，取得したレスポンスメッセージのデータ量の平均値を算出する（ステップＳ２０）。ＣＰＵ（＃０）２０ａは，データ量の平均値から，ステップＳ１８で算出した近似関係式を用いて，予定処理時間を求める（ステップＳ２１）。

ＣＰＵ（＃０）２０ａは，予定処理時間を算出すると，ＣＰＵ予定処理時間テーブル３７からＣＰＵ２０ごとの予定処理時間の合計値を検索し，最小の合計値のＣＰＵ番号を選択する（ステップＳ２２）。ＣＰＵ（＃０）２０ａは，ステップＳ２２で算出した予定処理時間を，ＣＰＵ予定処理時間テーブル３７における選択したＣＰＵ番号に対応させて，コネクション番号とともに保存する（ステップＳ２３）。また，ＣＰＵ（＃０）２０ａは，ＣＰＵ予定処理時間テーブル３７における該当ＣＰＵの予定処理時間合計値に，予定処理時間を加算する（ステップＳ２３）。

ＣＰＵ（＃０）２０ａは，振り分け用テーブル３５の新しいエントリに，コネクション番号，振り分け先ＣＰＵ番号およびリクエスト種別を格納し，振り分け用テーブル３５を更新し（ステップＳ２４），処理を終了する。

一致するコネクション情報が検出されなかった場合（ステップＳ１３の偽），ＣＰＵ（＃０）２０ａは，取得したコネクション情報における接続先ＩＰアドレスと接続元ＩＰアドレスとを入れ替える（ステップＳ２５）。また，ＣＰＵ（＃０）２０ａは，接続先ポート番号と接続元ポート番号とを入れ替える（ステップＳ２５）。ＣＰＵ（＃０）２０ａは，ステップＳ２５で接続先と接続元を入れ替えたコネクション情報を用いて，コネクション情報テーブル３４を検索する（ステップＳ２６）。

ＣＰＵ（＃０）２０ａは，ステップＳ２６でコネクション情報テーブル３４を検索した結果，該当するコネクション情報が検出されたかを判定する（ステップＳ２７）。該当するコネクション情報が検出された場合には（ステップＳ２７の真），ＣＰＵ（＃０）２０ａは，ステップＳ２８に進む。該当するコネクション情報が検出されなかった場合には（ステップＳ２７の偽），ＣＰＵ（＃０）２０ａは，ステップＳ３２に進む。

該当するコネクション情報が検出された場合（ステップＳ２７の真），ＣＰＵ（＃０）２０ａは，そのパケットを下りパケットと特定する（ステップＳ２８）。ＣＰＵ（＃０）２０ａは，振り分け用テーブル３５を参照する（ステップＳ２９）。ＣＰＵ（＃０）２０ａは，振り分け用テーブル３５中のコネクション番号から，振り分け先ＣＰＵ番号とリクエスト種別を取得する（ステップＳ３０）。ＣＰＵ（＃０）２０ａは，振り分け先ＣＰＵ番号のＣＰＵ２０に，下りパケットを，リクエスト種別とともに通知し（ステップＳ３１），処理を終了する。

該当するコネクション情報が検出されなかった場合（ステップＳ２７の偽），ＣＰＵ（＃０）２０ａは，受信パケットが上りパケットでも下りパケットでもないので，コネクション確立メッセージのパケットかどうかを判定する（ステップＳ３２）。受信したパケットがコネクション確立メッセージのパケットである場合には（ステップＳ３２の真），ＣＰＵ（＃０）２０ａは，ステップＳ３３に進む。受信したパケットがコネクション確立メッセージのパケットでもない場合には（ステップＳ３２の偽），ＣＰＵ（＃０）２０ａは，処理を終了する。

受信したパケットがコネクション確立メッセージのパケットである場合には（ステップＳ３２の真），ＣＰＵ（＃０）２０ａは，コネクション接続の確認をする（ステップＳ３３）。その後，ＣＰＵ（＃０）２０ａは，コネクション接続が確認されたコネクション情報を，コネクション情報テーブル３４に設定し（ステップＳ３４），処理を終了する。コネクション情報は，接続先ＩＰアドレス，接続先ポート番号，接続元ＩＰアドレス，接続元ポート番号，コネクション番号等である。

図１５は，本実施の形態のＣＰＵ（＃１）またはＣＰＵ（＃２）によるレスポンスメッセージ解析処理フローチャートである。

図１５に示すフローチャートは，受信パケットを振り分けられたＣＰＵ（＃１）２０ｂまたはＣＰＵ（＃２）２０ｃが，レスポンスメッセージ解析処理を実行する場合の例を示す。ＣＰＵ（＃１）２０ｂ，ＣＰＵ（＃２）２０ｃは，受信パケットを振り分けられると，図１５に示す処理を実行する。なお，以下では，ＣＰＵ（＃１）２０ｂによる処理を例に説明を行うが，ＣＰＵ（＃２）２０ｃについても同様である。

ＣＰＵ（＃１）２０ｂは，受信パケットからレスポンスメッセージを組み立てる（ステップＳ４０）。ＣＰＵ（＃１）２０ｂは，組み立てたレスポンスメッセージの内容を解析する（ステップＳ４１）。レスポンスメッセージの解析では，例えば，応答コードなどの情報が取得される。

ＣＰＵ（＃１）２０ｂは，内容解析の対象となったレスポンスデータのデータ量を求める（ステップＳ４２）。ＣＰＵ（＃１）２０ｂは，このときの解析に要した処理時間の測定を行う（ステップＳ４３）。

ＣＰＵ（＃１）２０ｂは，通知されたリクエスト種別と求めた解析の処理時間とをもとに，リクエスト単位のレスポンスデータ量と処理時間と時刻の情報を，履歴情報テーブル３６に新履歴データとして挿入し，履歴情報テーブル３６を更新する（ステップＳ４４）。

ＣＰＵ（＃１）２０ｂは，ＣＰＵ予定処理時間テーブル３７から，ＣＰＵ２０単位の予定処理時間を読み出し，合計値から減算し，ＣＰＵ予定処理時間テーブル３７を更新する（ステップＳ４５）。

以上説明した本実施の形態の解析処理装置１によれば，レスポンスデータ解析の処理量にバラツキがあっても，リクエスト種別を解析した時点で，均等にＣＰＵリソースを用いるように，その後のレスポンスデータ解析の振り分け先ＣＰＵ２０を決めることができる。したがって，本実施の形態の解析処理装置１は，各ＣＰＵ２０への解析処理の振り分けを均等化することができる。これにより，解析処理装置１におけるＣＰＵリソースの有効な利用が可能となる。

以上，本実施の形態について説明したが，本発明はその主旨の範囲において種々の変形が可能であることは当然である。

１ 解析処理装置
１０ パケット受信部
１１ 算出部
１２ データ量推測部
１３ 予測部
１４ 振り分け部
１５ メッセージ解析部
１６ 蓄積部
１７ 制御部

Claims (3)

1. ネットワークで接続されたコンピュータ間で送受信される通信パケットから組み立てられるメッセージを解析する複数の制御部と，
   リクエストメッセージから抽出されるリクエスト種別単位に，リクエストに対するレスポンスメッセージのデータ量と解析に要した処理時間とを蓄積する蓄積部と，
   前記蓄積部に蓄積された情報からレスポンスメッセージのデータ量と処理時間との関係式を算出する算出部と，
   前記関係式を用いて，前記リクエスト種別に対応するレスポンスメッセージのデータ量の統計データをもとにレスポンスメッセージのデータを解析する処理時間を予測する予測部と，
   前記予測した処理時間をもとに，レスポンスメッセージのデータを解析する前記制御部を選択し，該制御部にレスポンスメッセージのデータの解析処理を振り分ける振り分け部とを備える
   ことを特徴とする解析処理装置。
2. コンピュータに，
   リクエストメッセージから抽出されるリクエスト種別単位に，リクエストに対するレスポンスメッセージのデータ量と解析に要した処理時間とを記憶装置に記憶して蓄積し，
   前記記憶装置に蓄積された情報からレスポンスメッセージのデータ量と処理時間との関係式を算出し，
   前記関係式を用いて，前記リクエスト種別に対応するレスポンスメッセージのデータ量の統計データをもとにレスポンスメッセージのデータを解析する処理時間を予測し，
   前記予測した処理時間をもとに，レスポンスメッセージのデータを解析する複数の制御部のいずれかを選択して，該制御部にレスポンスメッセージのデータの解析処理を振り分ける
   処理を実行させるための解析処理プログラム。
3. コンピュータが，
   リクエストメッセージから抽出されるリクエスト種別単位に，リクエストに対するレスポンスメッセージのデータ量と解析に要した処理時間とを記憶装置に記憶して蓄積し，
   前記記憶装置に蓄積された情報からレスポンスメッセージのデータ量と処理時間との関係式を算出し，
   前記関係式を用いて，前記リクエスト種別に対応するレスポンスメッセージのデータ量の統計データをもとにレスポンスメッセージのデータを解析する処理時間を予測し，
   前記予測した処理時間をもとに，レスポンスメッセージのデータを解析する複数の制御部のいずれかを選択して，該制御部にレスポンスメッセージのデータの解析処理を振り分ける過程を実行する
   ことを特徴とする解析処理方法。

Images