JP5593944B2 - 判定装置、判定方法及びコンピュータプログラム - Google Patents

Description

本発明は、ネットワーク上のトラヒックを解析、判定する判定装置、判定方法及びコンピュータプログラムに関する。

近年、ＩＣＴ（Information and Communication Technology）インフラの整備に伴い、ネットワークサービスの普及が進んでいる。サービス提供者は、常時安定してユーザにサービスを提供するために、システムを管理しておくことが重要であり、「つながらない」、「遅い」といった障害が発生した時には関連するサーバ・ネットワークを迅速に復旧する必要がある。

一般的に、１つのネットワークサービスは、複数のサーバがネットワークで接続した構成で成り立っており、障害発生時には原因となるサーバ・ネットワークを特定しなければならない。例えば、ウェブサービスでは、クライアントからのリクエストを受けるウェブサーバとそのバックヤードでリクエスト毎の処理を行うアプリケーションサーバ、データを管理するデータベースサーバ等から構成されており、クライアントが「つながらない」、「遅い」といった場合には、いずれのサーバ・ネットワークが悪いかを特定する必要がある。

ネットワークにおいて障害箇所を特定する方式の１つとして、例えば、特許文献１に記載の技術が存在する。これは、ＬＡＮ又はＷＡＮのどちら側の障害であるかを、ＷＡＮ側のトラヒックを解析することで切り分ける方式であり、ＬＡＮから来たトラヒックとＬＡＮ及びＷＡＮの境界のルータから来たトラヒックとを判別し、各トラヒックの品質を比較することにより障害箇所を特定する構成としている。

特開２００７−２０８３２８号公報

特許文献１に開示されている技術では、アドレス・プロトコルなどパケットに記載された内容を基に、ＬＡＮから来たトラヒックか、ＬＡＮ及びＷＡＮの境界のルータから来たトラヒックかの判別を行う。しかしながら、上記のように複数のサーバが連携してネットワークサービスを構成している環境では、フロントサーバで折り返されたトラヒックもバックヤードサーバで折り返されたトラヒックも同じアドレス・プロトコルであるため、特許文献１のようにパケットに記載された内容を基に両者を判別することはできない。

本願は、上記の課題を解決するため、クライアントとフロントサーバとの間のトラヒックを解析することにより、フロントサーバで折り返されたトラヒックであるか、バックヤードで折り返されたトラヒックであるかを判定する判定装置、判定方法及びコンピュータプログラムを提供することを目的とする。

本願に開示する判定装置は、通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信され、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得するパケット取得部、該パケット取得部が所定時間内に取得したパケットに基づき、前記サーバ装置群から前記クライアント装置への応答に係る応答時間の最小値及び応答時間の揺らぎを算出する算出部、及び該算出部が算出した応答時間の最小値及び応答時間の揺らぎを夫々に対する閾値と比較することにより、前記パケット取得部にて取得した前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定する判定部を備えることを特徴とする。

本願によれば、通信経路上でクライアント装置とサーバ装置群との間のトラヒックを取得し、解析することにより、トラヒックの到達先がフロントサーバであるか、バックヤードサーバであるかを判別することができる。

本実施の形態に係る判定システムの全体構成を示す模式図である。 判定装置の内部構成を説明するブロック図である。 設定情報記憶部に記憶される設定情報の一例を示す模式図である。 計測データＤＢに記憶される内容の一例を示す模式図である。 パケット受信時の手順を示すフローチャートである。 到達パターン判定部による判定手順を示すフローチャートである。 到達パターン判定部による判定手順を示すフローチャートである。 実施の形態３に係る判定装置が用いる設定情報の一例を示す模式図である。 実施の形態３に係る判定装置による判定手順を説明するフローチャートである。 実施の形態４に係る判定装置の内部構成を説明するブロック図である。 計測データＤＢの記憶内容の一例を示す模式図である。 集計結果の一例を示す模式図である。 実施の形態４に係る判定装置が実行する処理の手順を説明するフローチャートである。 障害箇所特定部が実行する障害解析処理の手順を説明するフローチャートである。

以下、本発明をその実施の形態を示す図面に基づいて具体的に説明する。
実施の形態１．
図１は本実施の形態に係る判定システムの全体構成を示す模式図である。本実施の形態に係る判定システムでは、クライアント装置１０とサーバ装置群２０とが通信ネットワークＮにより接続されており、この通信ネットワークＮ上のトラヒックを判定装置３０が監視する構成としている。

サーバ装置群２０は、クライアント装置１０からのアクセスを受けるフロントサーバ２１及びバックヤードで機能するバックヤードサーバ２２を含む。フロントサーバ２１は、例えば、ウェブサーバである。バックヤードサーバ２２は、例えば、アプリケーションサーバである。フロントサーバ２１及びバックヤードサーバ２２は、互いに連携して機能することにより、クライアント装置１０にウェブサービスを提供するサーバ装置群２０を構成する。

本実施の形態では、通信ネットワークＮ上でウェブサービスを提供するシステムへの適用例について説明するが、他のシステムにも適用可能である。例えば、フロントサーバ２１がプロキシサーバであり、バックヤードサーバ２２がウェブサーバであるシステムへの適用も可能である。また、フロントサーバ２１がＳＩＰサーバ（SIP : Session Initiation Protocol）であり、バックヤードサーバ２２がデータベースサーバであるシステムへの適用も可能である。
なお、図１に示した例では、クライアント装置１０及びサーバ装置群２０をそれぞれ１つずつ記載したが、判定装置３０は、複数のクライアント装置と複数（又は複数種）のサーバ群との間で送受信されるパケットを監視することが可能である。

クライアント装置１０は、ウェブサービスの提供を受けるユーザが使用するパーソナルコンピュータ、携帯電話機等の端末装置である。クライアント装置１０には、フロントサーバ２１へアクセスするためのソフトウェアとしてウェブブラウザがインストールされている。クライアント装置１０は、ウェブブラウザを通じて受付けるユーザの要求をサーバ装置群２０へ送信する。このとき、クライアント装置１０は、通信ネットワークＮを介してリクエストパケットをサーバ装置群２０へ送信する。また、クライアント装置１０は、送信したリクエストパケットに対するサーバ装置群２０の応答として、フロントサーバ２１又はバックヤードサーバ２２からのリプライパケットを通信ネットワークＮを介して受信する。

判定装置３０は、通信ネットワークＮ上のトラヒック（クライアント装置１０とサーバ装置群２０との間で送受信されるパケット）をモニタするために、通信ネットワークＮの途中の経路に設置された分岐装置１５を介して通信ネットワークＮに接続されている。この分岐装置１５は、ネットワークスイッチ、ネットワークタップ等である。分岐装置１５は、クライアント装置１０から送信されるリクエストパケット、フロントサーバ２１又はバックヤードサーバ２２から送信されるリプライパケットを本来の送信先へ送信すると共に、同一内容のパケットを判定装置３０へ送信する。

判定装置３０は、以下で説明するように、分岐装置１５を通じて取得するパケットを基に、フロントサーバ２１に到達したパケット（フロントサーバ２１で折り返されたパケット）であるか、バックヤードサーバ２２に到達したパケット（バックヤードサーバ２２で折り返されたパケット）であるかの判定を行う。

図２は判定装置３０の内部構成を説明するブロック図である。判定装置３０は、制御部３１、キャプチャ部３２、トラヒック解析部３３、計測データＤＢ（DataBase）３４、到達パターン設定部３５、設定情報記憶部３６、到達パターン判定部３７を備える。

制御部３１は、例えば、ＭＰＵ（Micro Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）を備える。ＲＯＭには、本願の判定方法を実現するためのコンピュータプログラムが予め格納されている。ＭＰＵは、ＲＯＭに格納されているコンピュータプログラムを実行することにより、上述したハードウェア各部の動作を制御し、全体として本願の判定装置として機能させる。

キャプチャ部３２は、分岐装置１５を通じて、クライアント装置１０とサーバ装置群２０との間で送受信されるウェブトラヒックのパケット（リクエストパケット及びリプライパケット）を取得する。
トラヒック解析部３３は、キャプチャ部３２にて取得したパケットを解析し、リクエスト・レスポンス単位でデータをまとめ、計測データＤＢ３４に記憶させる。

到達パターン設定部３５は、パケットの到達先を判定するために、識別子データとパケットの到達先との関係を手入力で受付ける。到達パターン設定部３５にて受付ける識別子データには、ＵＲＩ、拡張子、コンテンツ種別、経路情報などが含まれる。到達先としては、本実施の形態では、フロントサーバ２１としてのウェブサーバ又はバックヤードサーバ２２としてのアプリケーションサーバの何れか一方が設定される。到達パターン設定部３５にて設定された識別子データとパケットの到達先との関係は、設定情報記憶部３６に記憶される。

図３は設定情報記憶部３６に記憶される設定情報の一例を示す模式図である。設定情報記憶部３６では、識別子データの種別及びその内容と到達先のサーバ装置との関係が記憶される。図３に示した例では、「http://xxx/servlet/*」というＵＲＩ（ここで、＊は任意の文字列を表す）が含まれているリクエストパケットの到達先は、アプリケーションサーバであることが記憶されている。一方、「http://xxx/image/*」というＵＲＩが含まれているリクエストパケットの到達先は、ウェブサーバであることが記憶されている。また、リクエストパケットにファイル名が含まれており、その拡張子が「gif」である場合には、到達先がウェブサーバであり、「jsp」である場合には到達先がアプリケーションサーバであることが記憶されている。更に、コンテンツ種別に「image/*」が含まれている場合には、パケットの到達先がウェブサーバであることが記憶されている。

なお、図３に示した識別子データは一例に過ぎない。また、図３に示したＵＲＩ、拡張子、コンテンツ種別の他、応答コードに含まれるエラー番号を登録するものであってもよい。例えば、エラー番号が「４０４」の応答コードは、指定されたＵＲＩに一致するものが存在しない旨をウェブサーバから通知するコードであるため、パケットの到達先はウェブサーバであると設定することができる。また、エラー番号が「５０３」の応答コードは、サーバが一時的な過負荷等により利用できない状態にあることを通知するコードであるため、パケットの到達先はアプリケーションサーバであると設定することができる。

到達パターン判定部３７は、設定情報記憶部３６に記憶されている設定に基づき、クライアント装置１０から送信されるパケットの到達先が、フロントサーバ２１であるか、バックヤードサーバ２２であるかを判定する。到達パターン判定部３７は、判定結果（到達パターン）を計測データＤＢ３４に記憶させる。

図４は計測データＤＢ３４に記憶される内容の一例を示す模式図である。上述したように、計測データＤＢ３４には、キャプチャ部３２で取得したパケットの情報、及び到達パターン判定部３７による判定結果が記憶される。パケットの情報としては、パケットを送受信したクライアント装置及びサーバ装置の通信アドレス／ポート番号、リクエストパケットの受信時刻及び内容（リクエストデータ）、リプライパケットの受信時刻、内容（リプライデータ）及びデータサイズが記憶される。また、到達パターン判定部３７による判定結果として、フロントサーバ２１又はバックヤードサーバ２２が記憶される。
なお、図４に示した例では、フロントサーバ２１を「ＦＳ」、バックヤードサーバ２２を「ＢＳ」と表記している。

以下、判定装置３０の動作について説明する。図５はパケット受信時の手順を示すフローチャートである。判定装置３０のキャプチャ部３２は、分岐装置１５を通じてパケットを取得した場合（ステップＳ１１）、解析対象のパケットであるか否かを判定する。本実施の形態では、ＨＴＴＰプロトコル、ＴＣＰポート８０番のパケットを解析対象としている。キャプチャ部３２は、解析対象のパケットを取得した場合、そのパケットをトラヒック解析部３３へ送出する。解析対象以外のパケットを取得した場合、そのパケットを破棄する。

なお、取得したパケットが解析対象であるか否かは、サーバ装置群２０の構成に依存する。本実施の形態では、サーバ装置群２０を構成するサーバ装置として、ウェブサーバ（フロントサーバ２１）とアプリケーションサーバ（バックヤードサーバ２２）とを想定しているため、ＨＴＴＰプロトコル、ＴＣＰポート８０番のパケットを解析対象のパケットとしたが、サーバ装置群の構成が異なる場合には、他のプロトコル、他のポート番号のパケットを解析対象としてもよい。

トラヒック解析部３３は、キャプチャ部３２から送出されるパケットについてプロトコル解析を行う（ステップＳ１２）。トラヒック解析部３３は、パケット構造を解析し、リクエストパケット及びリプライパケットの判別、各種パラメータの抽出を行う。抽出するパラメータは、例えば、送信元及び送信先の通信アドレス、ポート番号、リクエスト種別、応答コード等である。

トラヒック解析部３３は、プロトコル解析での判別結果がリクエストパケットであるか否かを判断し（ステップＳ１３）、リクエストパケットである場合には（Ｓ１３：ＹＥＳ）、そのリクエストパケットの情報を計測データＤＢ３４に新規登録する（ステップＳ１４）。このとき、トラヒック解析部３３は、リクエストパケットの送信元（クライアント装置１０）の通信アドレス及びポート番号、送信先（例えば、ウェブサーバ）の通信アドレス及びポート番号、リクエストパケットの受信時刻、リクエストデータを計測データＤＢ３４に記憶させる。

ステップＳ１３において、プロトコル解析での判別結果がリクエストパケットではなく（Ｓ１３：ＮＯ）、リプライパケットであると判断した場合、そのリプライパケットの情報を計測データＤＢ３４に追加登録する（ステップＳ１５）。このとき、トラヒック解析部３３は、リプライパケットの送信元及び送信先の通信アドレス、ポート番号を基に、対応するリクエストパケットの項目を計測データＤＢ３４より検索し、リプライパケットから抽出した受信時刻、リプライデータ、サイズの情報を追記する。また、トラヒック解析部３３は、リクエストパケットの受信時刻から所定時間の間にリプライパケットを取得しない場合には、サーバ装置群２０からの応答がなかった旨を計測データＤＢ３４に登録する。

次いで、判定装置３０の到達パターン判定部３７は、計測データＤＢ３４の登録内容を基にパケットの到達先を判定する（ステップＳ１６）。判定手順の詳細については後述することとするが、到達パターン判定部３７は、リクエストデータに記載されているＵＲＩ、拡張子、リプライデータに記載されているコンテンツ種別が、設定情報記憶部３６に記憶されている識別子データと一致するか否かを判断することによって、到達先の判定を行う。
一致する識別子データが設定情報記憶部３６に記憶されている場合には、パケットの到達先を判定できるため、判定結果を計測データＤＢ３４の該当する項目に登録する。

判定装置３０は、以上の処理を繰り返して実行し、計測データＤＢ３４への登録、パケットの到達先の判定を随時行う。

図６及び図７は到達パターン判定部３７による判定手順を示すフローチャートである。到達パターン判定部３７は、判定対象のリクエストパケット及びリプライパケットの組のうち、リクエストデータに含まれるＵＲＩが設定情報記憶部３６に設定情報として記憶されているＵＲＩであるか否かを判断する（ステップＳ２１）。
設定情報記憶部３６では、ＵＲＩと到達先のサーバとの関係が規定されているため、ステップＳ２１において、リクエストデータに含まるＵＲＩが設定情報記憶部３６に記憶されていると判断した場合（Ｓ２１：ＹＥＳ）、設定情報を参照することにより、到達先のサーバを判定することができる（ステップＳ２２）。

リクエストデータに含まれるＵＲＩが設定情報記憶部３６に記憶されているＵＲＩでないと判断した場合（Ｓ２１：ＮＯ）、リプライデータに含まれる応答コードを参照し（ステップＳ２３）、リプライデータに含まれる応答コードが、ウェブサーバでの折り返しに特有の応答コードであるか否かを判断する（ステップＳ２４）。このステップでは、エラー番号「４０４」のようにウェブサーバのみが応答したことを示す応答コードを含むか否かを判断する。ウェブサーバでの折り返しに特有の応答コードを含むと判断した場合（Ｓ２４：ＹＥＳ）、リクエストパケットの到達先がウェブサーバであると判定する（ステップＳ２５）。

一方、ウェブサーバでの折り返しに特有の応答コードがリプライデータの中に含まれていないと判断した場合（Ｓ２４：ＮＯ）、到達パターン判定部３７は、リクエストデータからファイルの拡張子を抽出することができるか否かを判断する（ステップＳ２６）。
拡張子を抽出することができる場合（Ｓ２６：ＹＥＳ）、その拡張子が、ウェブコンテンツ（静的なコンテンツ）に特有の拡張子であるか否かを判断する（ステップＳ２７）。ウェブコンテンツに特有の拡張子である場合（Ｓ２７：ＹＥＳ）、リクエストパケットの到達先がウェブサーバであると判定する（ステップＳ２８）。
抽出した拡張子がウェブコンテンツに特有の拡張子でないと判断した場合（Ｓ２７：ＮＯ）、ＡＰコンテンツ（動的なコンテンツ）に特有の拡張子であるか否かを判断する（ステップＳ２９）。ＡＰコンテンツに特有の拡張子である場合（Ｓ２９：ＹＥＳ）、リクエストパケットの到達先がアプリケーションサーバであると判定する（ステップＳ３０）。

ステップＳ２６で拡張子を抽出できない場合（Ｓ２６：ＮＯ）、又はステップＳ２９でＡＰコンテンツに特有の拡張子でないと判断した場合（Ｓ２９：ＮＯ）、到達パターン判定部３７は、リプライデータからコンテンツタイプを抽出することができるか否かを判断する（ステップＳ３１）。
コンテンツタイプを抽出することができる場合（Ｓ３１：ＹＥＳ）、そのコンテンツが、ウェブコンテンツ（静的なコンテンツ）に特有のコンテンツタイプであるか否かを判断する（ステップＳ３２）。ウェブコンテンツに特有のコンテンツタイプである場合（Ｓ３２：ＹＥＳ）、リクエストパケットの到達先がウェブサーバであると判定する（ステップＳ３３）。
抽出したコンテンツタイプがウェブコンテンツに特有のコンテンツタイプでないと判断した場合（Ｓ３２：ＮＯ）、ＡＰコンテンツ（動的なコンテンツ）に特有のコンテンツタイプであるか否かを判断する（ステップＳ３４）。ＡＰコンテンツに特有のコンテンツタイプである場合（Ｓ３４：ＹＥＳ）、リクエストパケットの到達先がアプリケーションサーバであると判定する（ステップＳ３５）。

ステップＳ３１でコンテンツタイプを抽出できない場合（Ｓ３１：ＮＯ）、又はステップＳ３４でＡＰコンテンツに特有の拡張子でないと判断した場合（Ｓ３４：ＮＯ）、到達パターン判定部３７は、リクエストパケットの到達先が不明であると判定する（ステップＳ３６）。

なお、上記の判定手順は一例に過ぎない。本実施の形態では、ＵＲＩ、応答コード、拡張子、コンテンツタイプの順で判定を行ったが、判定の順序は任意であり、どのような順序で判定を行ってもよい。
また、判定装置３０において、リクエストパケット及びリプライパケットの各組について、パケットの到達先を判定する必要は必ずしもなく、例えば、一定期間の計測データを、ＵＲＩ毎、応答コード毎に集計し、同じＵＲＩを有する組、又は同じ応答コードを有する組についてはまとめて判定する構成としてもよい。

以上のように、実施の形態１では、クライアント装置１０とサーバ装置群２０との間のトラヒックを取得し、解析することにより、トラヒックの到達先がフロントサーバ２１であるか、バックヤードサーバ２２であるかを判別することができる。

実施の形態２．
実施の形態１では、到達パターン設定部３５にて手入力より設定された情報を基にパケットの到達先を判定する構成としたが、フロントサーバ２１の設定データを取得し、取得した設定データを基に設定情報記憶部３６に記憶させる設定情報を生成するようにしてもよい。

フロントサーバ２１は、一般的に、バックヤードサーバ２２と連携するための設定ファイルを有しており、この設定ファイルに従ってバックヤードサーバ２２と連携することにより一連の処理を実行する。例えば、フロントサーバ２１のウェブサーバとしてＡｐａｃｈｅ（登録商標）、バックヤードサーバ２２のアプリケーションサーバとしてＴｏｍｃａｔ（登録商標）を使用している場合、フロントサーバ２１は、ＡｐａｃｈｅにてＴｏｍｃａｔと連携するためのモジュール（mod_jk.so）を有し、このモジュールにて設定ファイル（mod_jk.conf）が利用される。

設定ファイルに、例えば、「JkMount/servlet/* worker１」との記述が存在する場合、この設定は「http://xxx/servlet/*」のリクエストをウェブサーバ（Ａｐａｃｈｅ）が受信した場合、そのリクエストをアプリケーションサーバ（Ｔｏｍｃａｔ）へ転送することを意味している。ここで、上記リクエストに含まれる「xxx」は、ウェブサーバの名前又はＩＰアドレス、「*」は、任意のパスを表す。
設定ファイルに上記のような記述が存在する場合、「http://xxx/servlet/*」のリクエストパケットの到達先はアプリケーションサーバとなる。

このように、フロントサーバ２１がバックヤードサーバ２２と連携する際に用いる設定ファイルには、パケットの到達先を規定する記述が含まれる。そこで、判定装置３０は、フロントサーバ２１から設定ファイルを取得し、取得した設定ファイルを解析することにより、設定情報記憶部３６に記憶させる設定情報を生成する。例えば、設定ファイルから「JkMount」の項目を抽出し、図３の１つ目に登録されているような情報を生成し、設定情報記憶部３６に記憶させる。

以上のように、実施の形態２では、設定情報の自動登録が可能となるため、設定の誤りを少なくすることができ、パケット到達先の判定精度を高めることができる。また、多数のサーバ装置によりサーバ装置群２０が構成されている場合、又は多数のサーバ装置群２０について判定装置３０が判定する場合であっても、実施の形態２では、手入力により設定する必要がないため、設定に要する手間を省くことができる。

実施の形態３．
実施の形態１及び２では、リクエストデータ又はリプライデータに含まれる情報を、設定情報記憶部３６に記憶されている識別子データから検索し、検索結果を基にパケットの到達先を判定する構成としたが、フロントサーバ２１で折り返す場合と、バックヤードサーバ２２で折り返す場合とにおける通信経路の違い、又は各サーバでの処理の違い等に起因した応答の変化を検出し、パケットの到達先を判定する構成としてもよい。
実施の形態３では、計測データＤＢ３４に記憶されたデータを集計及び解析し、パケットの到達先を判定する構成について説明する。

実施の形態３に係る判定装置３０の構成は、実施の形態１で説明した判定装置３０と全く同様であるが、到達先の判定には、次のような設定情報を用いる。図８は実施の形態３に係る判定装置３０が用いる設定情報の一例を示す模式図である。図８に示した例では、設定情報の１つとして、応答時間の最小値（Ｄｅｌａｙ＿ｍｉｎ）に対する閾値Ｘ（例えば、数十ミリ秒〜１秒）が記憶されており、計測データＤＢ３４より集計した応答時間の最小値がＸ以下であれば、パケットの到達先がウェブサーバであることを規定している。閾値Ｘは、ウェブサーバでパケットを折り返す場合には殆ど遅延時間が発生しないのに対し、アプリケーションサーバで折り返す場合には数十ミリ秒から数秒程度の応答時間を要することを想定して設定された値である。

また、設定情報の１つとして、応答時間の揺らぎ（Ｄｅｌａｙ＿ｓｔｄｅｖ）に対する閾値Ｙ（例えば、数十ミリ秒〜１秒）が記憶されており、計測データＤＢ３４より集計した応答時間の揺らぎ（標準偏差）がＹ以下であれば、パケットの到達先がウェブサーバであることを規定している。閾値Ｙは、アプリケーションサーバで処理を行う場合、処理時間に揺らぎが発生するに対し、ウェブサーバで処理を行う場合には処理時間に殆ど揺らぎが発生しないことを想定して設定された値である。

また、設定情報の１つとして、リプライパケットのデータサイズの揺らぎ（Ｓｉｚｅ）に対する閾値Ｚ（例えば、数バイト）が記憶されており、計測データＤＢ３４より集計したリプライパケットのサイズの揺らぎ（標準偏差）がＺ以上であれば、パケットの到達先がアプリケーションサーバであることを規定している。閾値Ｚは、アプリケーションサーバの応答が毎回サイズの異なるものであることを想定して設定された値である。

以上の設定情報は、到達パターン設定部３５より手入力され、設定情報記憶部３６に記憶されるものである。
また、計測データＤＢ３４に記憶されているデータのうち、ＵＲＩ、応答コード毎に集計し、応答時間、応答時間の揺らぎ、応答サイズについて平均値、分散等の統計値を算出し、上述したような閾値Ｘ〜Ｚを設定する構成としてもよい。計測データＤＢ３４に記憶されたデータを集計して閾値Ｘ〜Ｚを設定する場合、例えば、事前にデータを収集しておき、判定装置３０の制御部３１が演算を行うことによって自動的に設定することが可能である。

図９は実施の形態３に係る判定装置３０による判定手順を説明するフローチャートである。判定装置３０は、計測データＤＢ３４に記憶されているデータのうち、一定期間のデータを集計し、例えば、同一のＵＲＩを有するデータ毎、同一の応答コードを有するデータ毎にまとめる（ステップＳ４１）。次いで、判定装置３０は、集計したデータについて、応答時間の最小値、応答時間の揺らぎ（標準偏差）、リプライパケットのデータサイズの揺らぎを算出する（ステップＳ４２）。すなわち、判定の準備段階として、同一内容のリクエスト・リプライパケットを取りまとめ、判定に用いる応答時間の最小値、応答時間の揺らぎ、リプライパケットのデータサイズの揺らぎを算出する。

判定装置３０は、算出したリプライパケットのデータサイズの揺らぎが閾値Ｚ以上であるか否かを判断することにより（ステップＳ４３）、リプライパケットのデータサイズが常に変動するか否かを判断する。ステップＳ４２で算出した揺らぎの値が閾値Ｚ以上である場合（Ｓ４３：ＹＥＳ）、リプライパケットのデータが常に変動していると判断することができるため、リクエストパケットの到達先はアプリケーションサーバであると判定する（ステップＳ４４）。

揺らぎの値が閾値Ｚ未満である場合（Ｓ４３：ＮＯ）、ステップＳ４２で算出した応答時間の最小値が閾値Ｘ以下であるか否かを判断する（ステップＳ４５）。応答時間の最小値が閾値Ｘ以下である場合（Ｓ４５：ＹＥＳ）、処理時間を要することなく応答を返しているため、リクエストパケットの到達先はウェブサーバであると判定する（ステップＳ４６）。

応答時間の最小値が閾値Ｘより長い場合（Ｓ４５：ＮＯ）、ステップＳ４２で算出した応答時間の揺らぎが閾値Ｙ以下であるか否かを判断する（ステップＳ４７）。応答時間の揺らぎが閾値Ｙ以下である場合（Ｓ４７：ＹＥＳ）、処理時間に揺らぎが発生することなく応答を返しているため、リクエストパケットの到達先はウェブサーバであると判定する（ステップＳ４８）。
応答時間の揺らぎが閾値Ｙより長い場合（Ｓ４７：ＮＯ）、リクエストパケットの到達先は不明であると判定する（ステップＳ４９）。

なお、本実施の形態では、データサイズの変動、応答時間の最小値、応答時間の揺らぎの順に判定を行ったが、判定の順序は上記に限定されるものではない。

また、本実施の形態では、集計したデータから算出した値と閾値との比較結果の一方について、パケットの到達先を規定する構成とした。例えば、応答時間の最小値又は応答時間の揺らぎが閾値以下であれば、到達先がウェブサーバであると規定した。また、リプライパケットのデータサイズが閾値以上であれば、到達先がアプリケーションサーバであると規定した。しかしながら、比較結果の双方についてパケットの到達先を規定する構成としてもよい。例えば、応答時間の最小値又は応答時間の揺らぎが閾値以下であれば、到達先がウェブサーバであると規定し、閾値より大きい場合、到達先はアプリケーションサーバであると規定してもよい。また、リプライパケットのデータサイズが閾値以上であれば、到達先がアプリケーションサーバであると規定し、閾値未満であれば、到達先がウェブサーバであると規定してもよい。なお、これらの場合、比較結果によってパケットの到達先を一義的に判定することが可能であるため、何れか１つの集計データのみを用いて判定を行うことも可能である。また、応答時間の最小値、応答時間の揺らぎ、及びリプライパケットのデータサイズの夫々について判定結果を取得し、３つの判定結果が一致する場合にのみパケットの到達先として採用し、一致しない場合には到達先が不明と判定するようにしてもよい。

実施の形態４．
実施の形態１〜３では、パケットの到達先を判定する構成としたが、判定結果を集計し、集計結果に基づき、パケットの送受信に関して障害が発生しているか否かの判定、及び障害が発生している場合の障害箇所の特定を行うことも可能である。
実施の形態４では、パケット到達先の判定結果をサーバ毎に集計し、障害の発生の有無及び障害箇所を特定する構成について説明する。

本実施の形態では、図１に示すサーバ装置群２０の他にサーバ装置群が通信ネットワークＮ上に複数接続されており、判定装置３０がサーバ装置群の夫々とクライアント装置１０との間で送受信されるパケットを通信ネットワークＮを介して取得し、取得したパケットの情報を計測データＤＢ３４に記憶させるものとする。また、他のサーバ装置群の構成は、図１に示すサーバ装置群２０と同様であり、フロントサーバとバックヤードサーバとにより構成されているものとする。
なお、取得したパケットが何れのサーバ装置群と送受信されたものであるかについては、パケットに含まれるサーバの通信アドレスの情報から識別可能である。

図１０は実施の形態４に係る判定装置３０の内部構成を説明するブロック図である。判定装置３０は、実施の形態１と同様に、制御部３１、キャプチャ部３２、トラヒック解析部３３、計測データＤＢ３４、到達パターン設定部３５、設定情報記憶部３６、到達パターン判定部３７を備える他、障害箇所特定部３８を備える。

障害箇所特定部３８は、計測データＤＢ３４に記憶されたデータを集計する機能を備える。集計は、一定期間のデータを、各サーバ装置群の到達パターン毎に、ＮＧ応答の回数、無応答回数、応答時間が閾値以上の回数、上記以外（正常応答）の回数を計数することによって行う。ここで、ＮＧ応答とは、計測データＤＢ３４に記憶されているデータのうち、リプライデータにエラーコードが付されている応答をいう。また、無応答とは、計測データＤＢ３４に記憶されているデータのうち、リプライデータが存在しないデータをいう。応答時間が閾値以上の応答とは、リクエストパケットの受信時刻とリプライパケットの受信時刻との差が閾値以上（例えば、１秒以上）の応答をいう。正常応答は、それ以外であり、リプライデータとして正常に応答したことを示す応答コードが付された応答をいう。

集計結果の一例を以下に示す。例えば、計測データＤＢ３４の記憶内容が図１１に示した模式図の通りであったとする。この計測データＤＢ３４に記憶されているデータから、障害箇所特定部３８が、通信アドレス「３．１．１．１」、「４．１．１．１」、「５．１．１．１」を持つサーバ装置群について、到達パターン毎に一定期間（１０：００〜１０：１０）のデータを集計した場合、以下の集計結果が得られる。

図１２は集計結果の一例を示す模式図である。例えば、通信アドレスが「３．１．１．１」のサーバ装置群とクライアント装置１０との間で送受信されたパケットを集計した結果、フロントサーバが正常に応答した回数が１回であったことを示し、バックヤードサーバが２回応答しているが、その２回の応答が何れもＮＧ応答であったことを示している。通信アドレスが、「４．１．１．１」及び「５．１．１．１」のサーバ装置群とクライアント装置１０との間で送受信されたパケットの集計結果についても図１２に示すような結果が得られている。

障害箇所特定部３８は、図１２に示すような集計結果を基に、障害の有無の判定、及び障害箇所の特定を行う。例えば、障害箇所特定部３８は、サーバ装置群毎に集計した結果、異常応答がなければ、そのサーバ装置群とクライアント装置１０との間でパケットの送受信に関して障害が発生していないと判定する。また、異常応答がバックヤードサーバ側にのみ検知された場合、バックヤードサーバ側の原因で通信に障害が発生していると判定する（すなわち、障害箇所をバックヤードサーバに特定する）。異常応答がフロントサーバ、バックヤードサーバの双方で検知された場合、フロントサーバ側の原因で通信に障害が発生していると判定する（すなわち、障害箇所をフロントサーバに特定する）。
それ以外の場合（フロントサーバ側にのみ異常応答が検知された場合）、通信経路上での障害か、フロントサーバでの障害かを特定できないため、障害箇所が不明であると判定する。

図１３は実施の形態４に係る判定装置３０が実行する処理の手順を説明するフローチャートである。判定装置３０は、タイマ待ちを行い（ステップＳ５１）、一定期間（例えば、５分間）だけ待ち、定期的に無応答セッション確認を呼び出す（ステップＳ５２）。

無応答セッション確認では、計測データＤＢ３４においてリプライの項目が記録されていないデータを全て抽出し、リクエスト受信時刻から所定時間（例えば、２分）経過している項目に関しては、無応答である旨を記録し、リプライの受信時刻に記録しておく。

次いで、判定装置３０の到達パターン判定部３７にて到達パターンの判定を行う（ステップＳ５３）。到達パターンの判定手法としては、実施の形態１〜３で説明した手法を用いることができる。例えば、実施の形態３の手法を用いる場合、計測データＤＢ３４に蓄積されたデータに関してＵＲＩ毎に応答時間、データサイズ等を分析することにより、到達パターンを判定する。

次いで、判定装置３０の障害箇所特定部３８にて障害解析処理を行う（ステップＳ５４）。ここでは、前回タイマ待ちに入ってから今回呼び出されるまでに計測データＤＢに蓄積されたデータに関して分析を行い、障害の検知・障害箇所の特定を行う。障害解析処理の終了後、判定装置３０は処理をステップＳ５１へ戻す。

図１４は障害箇所特定部３８が実行する障害解析処理の手順を説明するフローチャートである。障害解析処理では、まず、前回タイマ待ちに入ってから今回呼び出されるまでに計測データＤＢに蓄積されたデータの集計を行う（ステップＳ６１）。具体的には、各サーバ装置群の到達パターン毎に、ＮＧ応答の回数、無応答回数、応答時間が閾値以上の回数、上記以外（正常応答）の回数を計数し、集計結果として図に示していないメモリに記憶させる。

次いで、障害箇所特定部３８は、解析対象のサーバ装置群を１つ指定し、そのサーバ群を構成するサーバ装置に異常応答を行ったものが存在するか否かを判断する（ステップＳ６２）。異常応答を行ったものが存在しなければ（Ｓ６２：ＮＯ）、障害の発生なしと判定する（ステップＳ６３）。

ステップＳ６２で異常応答を行ったサーバ装置が存在すると判断した場合（Ｓ６２：ＹＥＳ）、それはバックヤードサーバのみであるか否かを判断する（ステップＳ６４）。バックヤードサーバのみであると判断した場合（Ｓ６４：ＹＥＳ）、バックヤードサーバ側の原因で障害が発生していると判定し、障害箇所をバックヤードサーバと特定する（ステップＳ６５）。

異常応答を行ったサーバ装置がバックヤードサーバのみでないと判断した場合（Ｓ６４：ＮＯ）、フロントサーバ及びバックヤードの双方に異常応答が存在するか否かを判断する（ステップＳ６６）。フロントサーバ及びバックヤードサーバの双方に異常応答が存在すると判断した場合（Ｓ６６：ＹＥＳ）、フロントサーバ側の原因で障害が発生していると判定し、障害箇所をフロントサーバと特定する（ステップＳ６７）。一方、フロントサーバのみに異常応答が存在すると判断した場合（Ｓ６６：ＮＯ）、障害箇所が特定できないため、障害箇所不明と判定する（ステップＳ６８）。

以上のように、実施の形態４では、サービスの入り口のクライアント装置１０側からトラヒック状況（応答状態、応答遅延）を集計し、解析することによって、障害の発生を検知することができ、しかもその障害の発生が、フロントサーバ側に起因したものであるのか、又はバックヤードサーバ側に起因したものであるのかを特定することができる。

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

（付記１）
通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信される、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得するパケット取得部、
前記応答を示すパケットの送信元を推定するための情報を記憶する記憶部、及び
該記憶部に記憶された情報に基づき、前記パケット取得部にて取得した前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定する判定部
を備えることを特徴とする判定装置。

（付記２）
前記情報は、ＵＲＩ、ファイルの拡張子、コンテンツの種別、又は応答内容を表す応答コードのうち、少なくとも１つの情報を含み、
前記判定部は、前記クライアント装置からの要求を示すパケット、又は該サーバ装置群からの応答を示すパケットから前記情報を抽出し、抽出した情報と前記記憶部に記憶してある情報とを比較することにより、前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定するようにしてあることを特徴とする付記１に記載の判定装置。

（付記３）
前記第１及び第２サーバ装置は、予め設定された設定情報に従って連携するように構成されており、
前記設定情報を取得する設定情報取得部と、
該設定情報取得部が取得した設定情報から前記記憶部に記憶させる情報を生成する情報生成部と
を備え、
該情報生成部が生成した情報を前記記憶部に記憶させるようにしてあることを特徴とする付記１又は付記２に記載の判定装置。

（付記４）
通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信される、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得するパケット取得部、
前記要求に従って前記第１及び第２サーバ装置が実行する処理の相違に起因した情報を記憶する記憶部、及び
該記憶部に記憶された情報に基づき、前記パケット取得部にて取得した前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定する判定部
を備えることを特徴とする判定装置。

（付記５）
前記情報は、応答時間に係る情報、又はパケットのサイズに係る情報の少なくとも一方の情報を含み、
前記判定部は、前記クライアント装置からの要求を示すパケット及び該サーバ装置群からの応答を示すパケットから前記情報を算出し、算出した情報と前記記憶部に記憶してある情報とを比較することにより、前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定するようにしてあることを特徴とする付記１又は付記４に記載の判定装置。

（付記６）
前記パケット取得部にて取得したパケットを、前記要求及び応答の種別毎に集計するパケット集計部を備え、
前記判定部は、前記パケット集計部が集計したパケットについて応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定するようにしてあることを特徴とする付記５に記載の判定装置。

（付記７）
前記判定部による判定結果を集計する判定結果集計部と、
該判定結果集計部の集計結果に基づいてパケットの送受信に関する障害を検知した場合、前記集計結果から前記第１又は第２サーバ装置の何れで障害が発生したかを特定する障害箇所特定部と
を備えることを特徴とする付記１から付記６の何れか１つに記載の判定装置。

（付記８）
通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信される、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得し、
予め記憶された前記応答を示すパケットの送信元を推定するための情報に基づき、取得した前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定する
ことを特徴とする判定方法。

（付記９）
通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信される、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得し、
予め記憶された前記要求に従って前記第１及び第２サーバ装置が実行する処理の相違に起因した情報に基づき、取得した前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定する
ことを特徴とする判定方法。

（付記１０）
コンピュータに、通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信される、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得させるステップと、
コンピュータに、前記応答を示すパケットの送信元を推定するための情報に基づき、取得させた前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定させるステップと
を実行させることを特徴とするコンピュータプログラム。

（付記１１）
コンピュータに、通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信される、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得させるステップと、
コンピュータに、前記要求に従って前記第１及び第２サーバ装置が実行する処理の相違に起因した情報に基づき、取得させた前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定させるステップと
を実行させることを特徴とするコンピュータプログラム。

１０ クライアント装置
１５ 分岐装置
２０ サーバ装置群
２１ フロントサーバ
２２ バックヤードサーバ
３０ 判定装置
３１ 制御部
３２ キャプチャ部
３３ トラヒック解析部
３４ 計測データＤＢ
３５ 到達パターン設定部
３６ 設定情報記憶部
３７ 到達パターン判定部
３８ 障害箇所特定部
Ｎ 通信ネットワーク

Claims (3)

1. 通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信され、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得するパケット取得部、
   該パケット取得部が所定時間内に取得したパケットに基づき、前記サーバ装置群から前記クライアント装置への応答に係る応答時間の最小値及び応答時間の揺らぎを算出する算出部、及び
   該算出部が算出した応答時間の最小値及び応答時間の揺らぎを夫々に対する閾値と比較することにより、前記パケット取得部にて取得した前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定する判定部
   を備えることを特徴とする判定装置。
2. 通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信され、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得し、
   所定時間内に取得したパケットに基づき、前記サーバ装置群から前記クライアント装置への応答に係る応答時間の最小値及び応答時間の揺らぎを算出し、
   算出した応答時間の最小値及び応答時間の揺らぎを夫々に対する閾値と比較することにより、取得した前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定する
   ことを特徴とする判定方法。
3. コンピュータに、
   通信網を介してクライアント装置に接続された第１サーバ装置及び該第１サーバ装置に接続された１又は複数の第２サーバ装置を含むサーバ装置群と前記クライアント装置との間で送受信され、該クライアント装置から前記サーバ装置群への要求を示すパケット及び該サーバ装置群から前記クライアント装置への応答を示すパケットを、前記通信網を通じて取得し、
   所定時間内に取得したパケットに基づき、前記サーバ装置群から前記クライアント装置への応答に係る応答時間の最小値及び応答時間の揺らぎを算出し、
   算出した応答時間の最小値及び応答時間の揺らぎを夫々に対する閾値と比較することにより、取得した前記サーバ装置群からの応答を示すパケットの送信元が前記第１又は第２サーバ装置の何れであるかを判定する
   処理を実行させるためのコンピュータプログラム。

Images