JP5655049B2 - 判定装置、判定方法および判定プログラム - Google Patents

Description

本発明は、判定装置等に関する。

ネットワークの品質を監視する各種の技術が存在する。例えば、ネットワークを利用するアプリケーションのレスポンス遅延が発生した場合に、専用装置を配置して、アプリケーションレベルのトラフィック量やＴＣＰヘッダ情報を監視することで、品質劣化の原因を特定する技術がある。

また、ネットワークの品質劣化時に、サーバとクライアントとの間でパケットデータの受け渡しに要する時間を、ネットワーク処理時間と、サーバの処理時間とに切り分けることで、品質劣化の原因がサーバ側にあるのかクライアント側にあるのかを判定する技術が存在する。

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

しかしながら、上述した従来技術では、多種多様な大量のデータを基にして、ネットワークの品質劣化の原因を判定することができないという問題がある。

ネットワークの品質劣化の要因は、上述したもの以外に様々なものが想定され、単純に、トラフィック量やパケットデータの受け渡し時間等から特定できるものではない。このため、現状では、ネットワークから得られる多種多様な情報を、保守作業員が確認し、保守作業員の経験などから、品質劣化の原因を判断している。

開示の技術は、上記に鑑みてなされたものであって、ネットワークの品質劣化の原因を判定することができる判定装置、判定方法および判定プログラムを提供することを目的とする。

開示の判定装置は、生成部と判定部を有する。生成部は、ネットワークを介して複数のホストと複数のサーバとの間で送受信されるパケットを分析してネットワーク品質に関連する特徴を特定し、特定した特徴を基にして、可視化して表示装置に表示可能なネットワーク集計データと、アプリの特徴を示すアプリ集計データとを生成する。判定部は、ネットワーク集計データとアプリ集計データとを基にして、ネットワークの品質劣化の原因を判定する。

開示の装置によれば、ネットワークの品質劣化の原因を判定することができるという効果を奏する。

図１は、本実施例に係るシステムの構成を示す図である。 図２は、本実施例に係る判定装置の構成を示す機能ブロック図である。 図３は、スループットデータのデータ構造の一例を示す図である。 図４は、ネットワーク集計データの一例を示す図である。 図５は、アプリ集計データのデータ構造の一例を示す図である。 図６は、環境定義テーブルのデータ構造の一例を示す図である。 図７は、ネットワーク品質診断テーブルのデータ構造の一例を示す図である。 図８は、アプリ品質診断テーブルのデータ構造の一例を示す図である。 図９は、アプリ特性データのデータ構造の一例を示す図である。 図１０は、判定部の処理手順の一例を示すフローチャート（１）である。 図１１は、判定部の処理手順の一例を示すフローチャート（２）である。 図１２は、判定結果の一例を示す図である。 図１３は、可視化データ表示部が出力する可視化データの一例を示す図である。

以下に、本願の開示する判定装置、判定方法および判定プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

本実施例に係るシステムの構成について説明する。図１は、本実施例に係るシステムの構成を示す図である。同図に示すように、このシステムは、サイト１０ａ，１０ｂ，１０ｃおよびデータセンター６０を有する。サイト１０ａ，１０ｂ，１０ｃおよびデータセンター６０は、ネットワーク５０を介して相互に接続される。例えば、ネットワーク５０は、ＩＰ（Internet Protocol）−ＶＰＮ（Virtual Private Network）に対応する。サイト１０ａ，１０ｂ，１０ｃをまとめて、適宜、サイト１０と表記する。

例えば、サイト１０ａは、ホスト１２ａ，１３ａ、１４ａ，１５ａ、ルータ１１ａを有する。サイト１０ｂは、ホスト１２ｂ，１３ｂ、ルータ１１ｂを有する。サイト１０ｃは、ホスト１２ｃ，１３ｃ、ルータ１１ｃを有する。

以下の説明では、サイト１０ａ，１０ｂ，１０ｃをまとめて、適宜、サイト１０と表記する。各ホスト１２ａ，１２ｂ，１２ｃ，１３ａ，１３ｂ，１３ｃ，１４ａ，１５ａをまとめて、適宜、ホストと表記する。ルータ１１ａ，１１ｂ，１１ｃをまとめて、適宜、ルータ１１と表記する。

各サイト１０のホストは、ルータ１１、ネットワーク５０を介して、データセンター６０との間でパケットを送受信する。ルータ１１は、パケットを中継する装置である。

また、サイト１０は、複数のサブネットを含む。例えば、サイト１０ａは、ホスト１２ａ，１３ａを含むサブネットａと、ホスト１４ａ，１５ａを含むサブネットｂを有する。サイト１０ｂは、ホスト１２ｂ，１３ｂを含むサブネットｃを有する。サイト１０ｃは、ホスト１２ｃ，１３ｃを含むサブネットｓを有する。各サイト１０はその他のサブネットを有していても良い。

データセンター６０は、例えば、ルータ１１ｄ、ＵＴＭ（Unified Threat Management）６５、Ｗｅｂサーバ７０ａ，７０ｂ，７０ｃ、ＡＰサーバ８０、ＤＢサーバ９０、判定装置１００を有する。Ｗｅｂサーバ７０ａ，７０ｂ，７０ｃをまとめて、適宜、Ｗｅｂサーバ７０と表記する。

ルータ１１ｄは、パケットを中継する装置である。ＵＴＭ６５は、ファイヤーウォールとＶＰＮ機能をベースに、アンチウイルス、不正侵入防御、Ｗｅｂコンテンツフィルタリング等のセキュリティ機能が統合された装置である。

Ｗｅｂサーバ７０は、サイト１０のホストとパケットを送受信し、ホストからの要求に応じて、サービスを提供する装置である。Ｗｅｂサーバ７０は、ルータ１１ｄ、ＵＴＭ６５を介して、サイト１０のホストとパケットを送受信する。また、Ｗｅｂサーバ７０は、ＡＰサーバ８０を利用して、ＤＢサーバ９０に各種データを要求する。

ＡＰサーバ８０は、Ｗｅｂサーバ７０と、ＤＢサーバ９０との間に位置し、データの橋渡しを行う装置である。例えば、ＡＰサーバ８０は、Ｗｅｂサーバ７０が要求するデータを、ＤＢサーバ９０から取得する。

ＤＢサーバ９０は、各種のデータを記憶し、ＡＰサーバ８０を介して、Ｗｅｂサーバ７０に要求されたデータを送信する装置である。

判定装置１００は、サイト１０とデータセンター６０との間で送受信されるパケットを分析して、ネットワーク品質に関連する特徴を特定し、特定した特徴を基にして、可視化して表示装置に表示可能なネットワーク集計データを生成する。判定装置１００は、ネットワーク集計データを基にして、ネットワークの品質劣化の原因を判定する。例えば、判定装置１００は、サイト１０側のポイントＸ１，Ｘ２，Ｘ３と、データセンター６０内のポイントＹ１，Ｙ２，Ｙ３から、パケットをキャプチャして分析を行うものとする。

判定装置１００は、ポイントＸ１から、サイト１０ａとデータセンター６０間で送受信されるパケットを取得する。判定装置１００は、ポイントＸ２から、サイト１０ｂとデータセンター６０間で送受信されるパケットを取得する。判定装置１００は、ポイントＸ３から、サイト１０ｃとデータセンター６０間で送受信されるパケットを取得する。

判定装置１００は、ポイントＹ１から、各サイト１０とＷｅｂサーバ７０との間で送受信されるパケットを取得する。判定装置１００は、ポイントＹ２から、Ｗｅｂサーバ７０とＡＰサーバ８０との間で送受信されるパケットを取得する。判定装置１００は、ポイントＹ３から、ＡＰサーバ８０とＤＢサーバ９０との間で送受信されるパケットを取得する。

次に、図１に示した判定装置１００の構成の一例について説明する。図２は、本実施例に係る判定装置の構成を示す機能ブロック図である。図２に示すように、この判定装置１００は、通信部１１０、入力部１２０、表示部１３０、記憶部１４０、制御部１５０を有する。

通信部１１０は、図１のポイントＸ１，Ｘ２，Ｘ３，Ｙ１，Ｙ２，Ｙ３に接続され、パケットを取得する処理部である。通信部１１０は、ＮＩＣ（Network Interface Card）に対応する。

入力部１２０は、判定装置１００に各種の情報を入力するための入力装置である。例えば、入力部１２０は、入力キーやタッチパネルに対応する。

表示部１３０は、後述する制御部１５０から出力される情報を表示する表示装置である。例えば、表示部１３０はディスプレイやタッチパネルに対応する。

記憶部１４０は、スループットデータ１４０ａ、ネットワーク集計データ１４０ｂ、アプリ集計データ１４０ｃ、環境定義テーブル１４０ｄを記憶する。記憶部１４０は、ネットワーク品質診断テーブル１４０ｅ、アプリ品質診断テーブル１４０ｆ、アプリ特性データ１４０ｇを記憶する。記憶部１４０は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ（Flash Memory）などの半導体メモリ素子などの記憶装置に対応する。

以下では、記憶部１４０に記憶されたデータ１４０ａ〜１４０ｇについて順に説明する。下記の説明で用いる、「Ａ１〜Ａ３，Ｂ１，Ｃ１」等は、ホストアドレスの一例であり、「Ｓ１」等はＷｅｂサーバのアドレスの一例であり、「ＡＰ１」等はＡＰサーバのアドレスの一例であり、「ＤＢ１」等はＤＢサーバのアドレスの一例である。

スループットデータ１４０ａは、単位時間当たりに送受信されるパケットのデータ量を時刻毎に示すデータである。図３は、スループットデータのデータ構造の一例を示す図である。図３に示すように、このスループットデータ１４０ａは、時刻と、サブネット情報と、送信スループットと、受信スループットとを有する。

サブネット情報は、図１で説明した各サブネットを識別する情報である。送信スループットは、サイト１０側からデータセンター６０側に送信されるパケットの単位時間当たりのデータ量を示す。受信スループットは、データセンター６０側からサイト１０側に送信されるパケットの単位時間当たりのデータ量を示す。

ネットワーク集計データ１４０ｂは、ネットワーク品質に関連する特徴を示すデータである。図４は、ネットワーク集計データの一例を示す図である。例えば、ネットワーク集計データ１４０ｂは、テーブル２０ａ，２０ｂ，２０ｃを有する。テーブル２０ａは、ネットワーク品質に関する特徴をホスト単位で示したテーブルである。テーブル２０ｂは、ネットワーク品質に関する特徴をサブネット単位で示したテーブルである。テーブル２０ｃは、ネットワーク品質に関する特徴をサイト単位で示したテーブルである。

テーブル２０ａは、時刻、送信元ＩＰアドレス、宛先ＩＰアドレス、アプリ情報、送信トラフィック量、受信トラフィック量、ネットワーク遅延、送信ロス率、受信ロス率、サーバ処理時間を有する。送信元ＩＰアドレスは、送信元のホストのアドレスである。宛先ＩＰアドレスは、宛先のＷｅｂサーバのアドレスである。アプリ情報は、アプリの種別を識別する情報である。本実施例では、一例として、アプリ情報を宛先ポート番号で示す。

送信トラフィック量は、送信元ＩＰアドレスから宛先ＩＰアドレスに送信されるパケットの単位時間当たりのデータ量である。受信トラフィック量は、宛先ＩＰアドレスから送信元ＩＰアドレスに送信されるパケットの単位時間当たりのデータ量である。

ネットワーク遅延は、送信元がパケットを送信した時刻から、このパケットに対応する応答を送信元が受信する時刻までの時間を示すＲＴＴ（Round Trip Time）である。

送信ロス率は、送信元ＩＰアドレスから宛先ＩＰアドレスに送信されるパケットのロス率である。受信ロス率は、宛先ＩＰアドレスから送信元ＩＰアドレスに送信されるパケットのロス率である。サーバ処理時間は、Ｗｅｂサーバ７０がパケットを受信してから応答を返すまでの時間である。

テーブル２０ｂは、時刻、送信元サブネット、宛先ＩＰアドレス、アプリ情報、送信トラフィック量、受信トラフィック量、ネットワーク遅延、送信ロス率、受信ロス率、サーバ処理時間を有する。送信元サブネットは、送信元のサブネットを識別する情報である。テーブル２０ｂに関するその他の属性に関する説明は、テーブル２０ａと同様である。

テーブル２０ｃは、時刻、送信元サイト、宛先ＩＰアドレス、アプリ情報、送信トラフィック量、受信トラフィック量、ネットワーク遅延、送信ロス率、受信ロス率、サーバ処理時間を有する。送信元サイトは、送信元のサイトを識別する情報である。テーブル２０ｃに関するその他の属性に関する説明は、テーブル２０ａと同様である。

アプリ集計データ１４０ｃは、あるアプリによって行われたサービスに関する情報を有する。図５は、アプリ集計データのデータ構造の一例を示す図である。図５に示すように、アプリ集計データ１４０ｃは、時刻、送信元ＩＰアドレス、宛先ＩＰアドレス、サービス名、リクエスト数、処理時間、オブジェクトを有する。

送信元ＩＰアドレスは、パケットの送信元を示すアドレスである。パケットの送信元には、ホスト、Ｗｅｂサーバ７０、ＡＰサーバ８０等が含まれる。宛先ＩＰアドレスは、パケットの宛先を示すアドレスである。パケットの宛先には、ホスト、Ｗｅｂサーバ７０、ＡＰサーバ８０等が含まれる。

サービス名は、パケットによりリクエストされるサービスを識別する情報である。例えば、サービス名「ＷＥＢ」は、Ｗｅｂサーバ７０が所定の処理を行うことを示す。サービス名「ＡＰ」は、ＡＰサーバ８０が所定の処理を行うことを示す。サービス名「ＤＢ」は、ＤＢサーバ９０が所定の処理を行うことを示す。

リクエスト数は、特定のサービスに対するリクエスト数を示す。処理時間は、リクエストの処理に要した時間である。オブジェクトは、例えば、アプリによって実行されるコマンドの一例を示すものである。例えば、オブジェクトは、個々のリクエストに対する処理である。

例えば、図５の１行目を参照すると、時刻「１０時００分」において、送信元ＩＰアドレス「Ａ１」のホストから宛先ＩＰアドレス「Ｓ１」のＷｅｂサーバ７０へパケットが送信されており、サービス名「ＷＥＢ」が実行されている。そして、かかるサービス名「ＷＥＢ」に対するリクエスト数が「８００」であり、処理時間が「２５０ｍｓ」であり、オブジェクトが「ｇｅｔ ｈｔｔｐ：・・・」となっている。

環境定義テーブル１４０ｄは、サイト１０とサブネットとの関係を定義する情報である。図６は、環境定義テーブルのデータ構造の一例を示す図である。図６に示すように、この環境定義テーブル１４０ｄは、サイト情報とサブネット情報とを対応付ける。また、環境定義テーブル１４０ｄは、サブネット情報と、サブネットに含まれるホスト情報とを対応付けた情報を更に保持しても良い。サイト情報は、サイトを識別する情報である。サブネット情報は、サブネットを識別する情報である。例えば、図６の１行目を参照すると、サイト１０ａには、サブネットａ、ｂが含まれる旨が示される。

ネットワーク品質診断テーブル１４０ｅは、ネットワーク品質に関する特徴を時間帯毎に示したデータである。図７は、ネットワーク品質診断テーブルのデータ構造の一例を示す図である。図７に示す例では、平日１０時台のネットワーク品質に関する特徴を示すがこれに限定されるものではない。

図７に示すように、ネットワーク品質診断テーブル１４０ｅは、送信元サブネット、宛先サブネット、送信スループット、受信スループット、ネットワーク遅延、ロス率、サーバ処理時間を有する。

送信元サブネットは、送信元のサブネットを識別する情報である。宛先サブネットは、宛先のサブネットを識別する情報である。例えば、宛先サブネットの「ｓ」は、Ｗｅｂサーバ７０ａ，７０ｂ，７０ｃから構成されるサブネットとする。

送信スループットは、平常時における、送信元サブネットから宛先サブネットに送信されるパケットの単位時間当たりのデータ量を示す。受信スループットは、平常時における、宛先サブネットから送信元サブネットに送信されるパケットの単位時間当たりのデータ量を示す。

ネットワーク遅延は、平常時のネットワーク遅延と、ネットワーク遅延の閾値とを含む。ロス率は、平常時のロス率と、ロス率の閾値とを含む。サーバ処理時間は、平常時のサーバ処理時間と、サーバ処理時間の閾値とを含む。

アプリ品質診断テーブル１４０ｆは、アプリに対する各サーバの処理時間やリクエスト数を時間帯毎に示したデータである。図８は、アプリ品質診断テーブルのデータ構造の一例を示す図である。図８に示す例では、平日１０時台の情報を示すが、これに限定されるものではない。

図８に示すように、アプリ品質診断テーブル１４０ｆは、送信元ＩＰアドレス、宛先ＩＰアドレス、処理時間、リクエスト数を有する。

送信元ＩＰアドレスは、パケットの送信元のホストまたはＷｅｂサーバ７０、ＡＰサーバ８０、ＤＢサーバ９０を示すアドレスである。なお、アプリ品質診断テーブル１４０ｆは、各ホストのアドレスをまとめて「−」で表す。宛先ＩＰアドレスは、パケットの宛先を示すアドレスである。

処理時間は、アプリを実行するＷｅｂサーバ７０、ＡＰサーバ８０、ＤＢサーバ９０の平常時の処理時間と、処理時間の閾値とを含む。リクエスト数は、平常時のリクエスト数と、リクエスト数の閾値とを含む。

アプリ特性データ１４０ｇは、アプリがネットワーク品質に与える特徴を示すデータである。図９は、アプリ特性データのデータ構造の一例を示す図である。図９に示すように、アプリ特性データ１４０ｇは、時刻、送信元サブネット、アプリ情報、ネットワーク遅延、送信ロス率、受信ロス率を有する。時刻、送信元サブネット、アプリ情報、ネットワーク遅延、送信ロス率、受信ロス率に関する説明は、図４に示したネットワーク集計データ１４０ｂの説明と同様である。

制御部１５０は、スループット計測部１５０ａ、パケットキャプチャー部１５０ｂ、生成部１５０ｃ、判定部１５０ｄ、可視化データ表示部１５０ｅを有する。制御部１５０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）や、ＦＰＧＡ（Field Programmable Gate Array）などの集積装置に対応する。また、制御部１５０は、例えば、ＣＰＵやＭＰＵ（Micro Processing Unit）等の電子回路に対応する。

スループット計測部１５０ａは、図１に示したサイト側のポイントＸ１，Ｘ２，Ｘ３から単位時間当たりに通過するパケットのデータ量を計測する処理部である。スループット計測部１５０ａは、計測結果をスループットデータ１４０ａに格納する。

例えば、スループット計測部１５０ａは、サブネット毎に、送信スループットおよび受信スループットを計測する。スループット計測部１５０ａは、パケットのヘッダ情報と、環境定義テーブル１４０ｄとを基にして、パケットがどのサブネットに属するのか判定する。

パケットキャプチャー部１５０ｂは、図１に示したデータセンター６０内のポイントＹ１，Ｙ２，Ｙ３からパケットをキャプチャーし、キャプチャーしたパケットを生成部１５０ｃに出力する処理部である。

生成部１５０ｃは、パケットキャプチャー部１５０ｂから取得するパケットを分析してネットワーク品質に関連する特徴を特定し、特定した特徴を基にして、ネットワーク集計データ１４０ｂ、アプリ集計データ１４０ｃ、ネットワーク品質診断テーブル１４０ｅ、アプリ品質診断テーブル１４０ｆ、アプリ特性データ１４０ｇを生成する処理部である。以下では、生成部１５０ｃが各データを生成する処理の一例について順に説明する。

生成部１５０ｃが、「図４に示したネットワーク集計データ１４０ｂ」を生成する処理の一例について説明する。生成部１５０ｃは、例えば、テーブル２０ａを生成し、テーブル２０ａを基にして、テーブル２０ｂを生成し、テーブル２０ｂを基にして、テーブル２０ｃを生成する。

生成部１５０ｃがテーブル２０ａを生成する処理について説明する。生成部１５０ｃは、パケットのヘッダ情報を基にして、送信元ＩＰアドレス、宛先ＩＰアドレス、アプリ情報を特定して、テーブル２０ａに格納する。そして、生成部１５０ｃは、送信元ＩＰアドレス、宛先ＩＰアドレス、アプリ情報の組みが同一のヘッダ情報に有するパケットに着目し、送信トラフィック量、受信トラフィック量、ネットワーク遅延を計測し、テーブル２０ａに格納する。

生成部１５０ｃは、同一の送信元ＩＰアドレス、宛先ＩＰアドレス、アプリ情報の組みをヘッダ情報に有するパケットに着目し、所定の時間間隔におけるパケット抜けを検出することで、送信ロス率、受信ロス率を算出し、テーブル２０ａに格納する。例えば、パケットはパケットＩＤを有しており、このパケットＩＤがほぼ昇順となるように送受信されている。このため、順次取得するパケットのパケットＩＤが、「１，２，３，４，６，７，８」となっている場合に、パケットＩＤ「５」のパケットがロスしたと判定出来る。生成部１５０ｃは、このようなパケットＩＤを用いて送信ロス率、受信ロス率を算出しても良いし、他の従来技術を用いて、送信ロス率、受信ロス率を算出してもよい。

生成部１５０ｃは、図１のポイントＹ１でキャプチャーされたパケットの応答が、再びポイントＹ１でキャプチャーされるまでの時間をサーバ処理時間として算出し、テーブル２０ａのサーバ処理時間に格納する。生成部１５０ｃは、パケットのヘッダ情報の、送信元ＩＰアドレス、送信先ＩＰアドレス、アプリ情報の組みの関係から、パケットの応答となるパケットを判定しても良い。例えば、送信元ＩＰアドレス「Ａ１」、送信先ＩＰアドレス「Ｓ１」、アプリ情報「８０」の応答は、ヘッダ情報に、送信元ＩＰアドレス「Ｓ１」、送信先ＩＰアドレス「Ａ１」、アプリ情報「８０」を含むことを利用する。なお、生成部１５０ｃは、他の従来技術を用いて、サーバ処理時間を算出しても良い。

生成部１５０ｃがテーブル２０ｂを生成する処理について説明する。生成部１５０ｃは、環境定義テーブル１４０ｄと、テーブル２０ａとを比較して、同一のサブネットに属するホストのレコードを特定し、特定したレコードの各数値を平均化することで、テーブル２０ｂを生成する。

例えば、図４のテーブル２０ａの送信元ＩＰアドレス「Ａ１〜Ａ３」が同一のサブネット「ａ」に属している場合には、生成部１５０ｃは、送信元ＩＰアドレス「Ａ１〜Ａ３」のレコードを平均化して、テーブル２０ｂの送信元サブネット「ａ」のレコードを生成する。

生成部１５０ｃがテーブル２０ｃを生成する処理について説明する。生成部１５０ｃは、環境定義テーブル１４０ｄと、テーブル２０ｂとを比較して、同一のサイトに属するサブネットのレコードを特定し、特定したレコードの各数値を平均化することで、テーブル２０ｃを生成する。

例えば、図４のテーブル２０ｂの送信元サブネット「ａ，ｂ」が同一のサイト「サイト１０ａ」に属している場合には、生成部１５０ｃは、送信元サブネット「ａ，ｂ」のレコードを平均化して、テーブル２０ｃの送信元サイト「サイト１０ａ」のレコードを生成する。

次に、生成部１５０ｃが、「図５に示したアプリ集計データ１４０ｃ」を生成する処理の一例について説明する。生成部１５０ｃは、パケットのヘッダ情報を基にして、送信元ＩＰアドレス、宛先ＩＰアドレスを特定し、アプリ集計データ１４０ｃに格納する。また、生成部１５０ｃは、ヘッダ情報に含まれる宛先ポート番号を基にして、サービス名を特定し、アプリ集計データ１４０ｃに格納する。例えば、生成部１５０ｃは、宛先ポート番号と、サービス名との対応関係を示す情報を保持しているものとする。

生成部１５０ｃは、送信元ＩＰアドレス、宛先ＩＰアドレス、サービス名の組みが同一となるパケットに着目し、係るパケットの通過数をカウントすることで、リクエスト数を特定し、アプリ集計データ１４０ｃに格納する。

生成部１５０ｃは、サービス名「ＷＥＢ」となるパケットに関しては、図１のポイントＹ１でキャプチャーされたパケットの応答が、再びポイントＹ１でキャプチャーされるまでの時間を処理時間として算出し、アプリ集計データの処理時間に格納する。

生成部１５０ｃは、サービス名「ＡＰ」となるパケットに関しては、図１のポイントＹ２でキャプチャーされたパケットの応答が、再びポイントＹ２でキャプチャーされるまでの時間を処理時間として算出し、アプリ集計データの処理時間に格納する。

生成部１５０ｃは、サービス名「ＤＢ」となるパケットに関しては、図１のポイントＹ３でキャプチャーされたパケットの応答が、再びポイントＹ３でキャプチャーされるまでの時間を処理時間として算出し、アプリ集計データの処理時間に格納する。

生成部１５０ｃは、パケットに含まれるオブジェクトの情報を、アプリ集計データ１４０ｃのオブジェクトに格納する。

次に、生成部１５０ｃが、「図７に示したネットワーク品質診断テーブル１４０ｅ」を生成する処理の一例について説明する。生成部１５０ｃは、周知の正常性診断の技術を活用し、スループットデータ１４０ａおよびネットワーク集計データ１４０ｂを統計的に処理してデータの傾向を捉え、混入した異常の影響を除去することで、ネットワーク品質診断テーブル１４０ｅを生成する。

例えば、生成部１５０ｃは、過去数ヶ月分の、所定の時間帯（例えば、１０時台）において、送信元サブネットと宛先サブネットとの組みが同一となるレコードを抽出し、平均化することで、平常時の送信スループット、平常時の受信スループット、平常時のネットワーク遅延、平常時のロス率、平常時のサーバ処理時間を算出する。なお、生成部１５０ｃは、平均値と大きく異なる値を有するレコードを除外して、各平常時の値を算出しても良い。

また、生成部１５０ｃは、平常時の値と、予め設定される変動率とを掛け合わせることで、各閾値を算出する。生成部１５０ｃは、平常時のネットワーク遅延に、変動率をかけることで、ネットワーク遅延の閾値を算出する。生成部１５０ｃは、平常時のロス率に、変動率をかけることで、ロス率の閾値を算出する。生成部１５０ｃは、平常時のサーバ処理時間に、変動率をかけることで、サーバ処理時間の閾値を算出する。なお、変動率の数値を、ネットワーク遅延、ロス率、サーバ処理時間毎に設定しても良い。

次に、生成部１５０ｃが、「図８に示したアプリ品質診断テーブル１４０ｆ」を生成する処理の一例について説明する。生成部１５０ｃは、周知の正常診断の技術を活用し、アプリ集計データ１４０ｃを統計的に処理してデータの傾向を捉え、混入した異常の影響を除去することで、アプリ品質診断テーブル１４０ｆを生成する。

例えば、生成部１５０ｃは、過去数ヶ月分の、所定の時間帯（例えば、１０時台）において、宛先がＷｅｂサーバ７０となるレコードを抽出し、平均化することで、アプリ品質診断テーブル１４０ｆの１行目のレコードを生成する。生成部１５０ｃは、過去数ヶ月分の、所定の時間帯において、送信元がＷｅｂサーバ７０、宛先がＡＰサーバ８０となるレコードを抽出し、平均化することで、アプリ品質診断テーブル１４０ｆの２行目のレコードを生成する。生成部１５０ｃは、過去数ヶ月分の、所定の時間帯において、送信元がＡＰサーバ８０、宛先がＤＰサーバ９０となるレコードを抽出し、平均化することで、アプリ品質診断テーブル１４０ｆの３行目のレコードを生成する。

次に、生成部１５０ｃが、「図９に示したアプリ特性データ１４０ｇ」を生成する処理の一例について説明する。生成部１５０ｃは、ネットワーク集計データ１４０ｂのテーブル２０ａを基にして、アプリ特性データ１４０ｇを生成する。例えば、生成部１５０ｃは、送信元サブネットとアプリ情報との組み毎に、レコードを平均化することで、ネットワーク遅延、送信ロス率、受信ロス率を算出し、アプリ特性データ１４０ｇに格納する。

判定部１５０ｄは、記憶部１４０に記憶される各データ１４０ａ〜１４０ｇを基にして、ネットワークの品質劣化の原因を判定する処理部である。図１０、図１１は、判定部の処理手順の一例を示すフローチャートである。

図１０に示すように、判定部１５０ｄは、ネットワーク集計データ１４０ｂのネットワーク遅延が、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値よりも大きいか否かを判定する（ステップＳ１０１）。

判定部１５０ｄは、ネットワーク集計データ１４０ｂのネットワーク遅延が、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値よりも大きい場合には（ステップＳ１０１，Ｙｅｓ）、ホスト側の品質劣化の方向を分析する（ステップＳ１０２）。

ステップＳ１０２に示した、ホスト側の品質劣化の方向を分析する処理の一例について説明する。判定部１５０ｄは、品質劣化の方向を分析することで、品質劣化が、特定のサブネットによるものか、全サイトによるものか、特定のサイトによるものか、特定のホストによるものかを判定する。以下では、説明の便宜上、ネットワーク遅延を利用して、品質劣化の方向を分析する方法について述べるが、トラフィック量、ロス率、サーバ処理時間を複合的に用いて品質劣化の方向を分析しても良い。

判定部１５０ｄは、テーブル２０ｃを参照し、ネットワーク遅延が、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値よりも大きいレコードを特定する。そして、判定部１５０ｄは、特定したレコードの送信元サイトを、品質劣化の方向として判定する。

図４のテーブル２０ｃの場合では、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値よりも大きいレコードは、１行目のレコードとなり、判定部１５０ｄは、送信元サイト「サイト１０ａ」を、品質劣化の方向として特定する。

続いて、判定部１５０ｄは、テーブル２０ｃで特定した、送信元サイトに含まれるサブネットを、環境定義テーブル１４０ｄを基にして特定する。判定部１５０ｄは、特定したサブネットを送信元サブネットに含むレコードを、テーブル２０ｂにて特定し、ネットワーク遅延が、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値よりも大きいレコードを特定する。判定部１５０ｄは、特定したレコードの送信元サブネットを、品質劣化の方向として特定する。

例えば、送信元サイト「１０ａ」に含まれるサブネットは、サブネット「ａ，ｂ」となる。判定部１５０ｄは、テーブル２０ｂで、送信元サブネットが「ａ，ｂ」となるレコードを特定する。図４のテーブル２０ｂでは、１，２行目のレコードが特定される。判定部１５０ｄは、特定したレコードにつき、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値よりも大きいレコードを特定すると、テーブル２０ｂの１行目のレコードが、特定される。判定部１５０ｄは、送信元サブネット「ａ」を、品質劣化の方向として特定する。

続いて、判定部１５０ｄは、テーブル２０ｂで特定した、送信元サブネットに含まれるホストを、環境定義テーブル１４０ｄを基にして特定する。判定部１５０ｄは、特定したホストを送信元ＩＰアドレスに含むレコードを、テーブル２０ａにて特定し、ネットワーク遅延が、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値よりも大きいレコードを特定する。判定部１５０ｄは、特定したレコードの送信元ＩＰアドレス（ホスト）を、品質劣化の方向として特定する。

例えば、送信元サブネット「ａ」に含まれるホストの送信元ＩＰアドレスを「Ａ１，Ａ２，Ａ３」とする。判定部１５０ｄは、テーブル２０ａで、送信元ＩＰアドレスが「Ａ１，Ａ２，Ａ３」となるレコードを特定する。図４のテーブル２０ａでは、１，４，５行目のレコードが特定される。判定部１５０ｄは、特定したレコードにつき、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値よりも大きいレコードを特定すると、テーブル２０ｂの１，５行目のレコードが、特定される。判定部１５０ｄは、送信元ＩＰアドレス「Ａ１，Ａ２」を、品質劣化の方向として特定する。

判定部１５０ｄが、上記の処理を実行することで、品質劣化の方向が、送信元サイト「１０ａ」に含まれる送信元サブネット「ａ」の送信元ＩＰアドレス「Ａ１，Ａ２」のホストと判定する。なお、品質劣化の方向を特定する処理は、上述した処理に限定されず、トモグラフィ技術を用いて、品質劣化の方向を特定しても良い。

判定部１５０ｄは、品質劣化の方向を特定した後に、特定したホスト、特定したサブネット、特定したサイト、全サイトについて、図１１のステップＳ１０３〜Ｓ１１１の処理をそれぞれ実行する。ここでは説明の便宜上、特定したサブネットについて、ステップＳ１０３〜Ｓ１１１を実行する場合について説明する。

図１１において、判定部１５０ｄは、テーブル２０ｂの特定したサブネットのレコードについて、送信トラフィック量または受信トラフィック量が平常時よりも大きいか否かを判定する（ステップＳ１０３）。

ステップＳ１０３において、判定部１５０ｄは、テーブル２０ｂの該当するレコードの送信トラフィック量が、ネットワーク品質診断テーブル１４０ｅの送信スループットよりも大きい場合に、送信トラフィック量が平常時よりも大きいと判定する。また、判定部１５０ｄは、テーブル２０ｂの該当するレコードの受信トラフィック量が、ネットワーク品質診断テーブル１４０ｅの受信スループットよりも大きい場合に、受信トラフィック量が平常時よりも大きいと判定する。

判定部１５０ｄは、送信トラフィック量および受信トラフィック量が平常時のトラフィック量以下の場合には（ステップＳ１０３，Ｎｏ）、品質劣化の原因がトラフィック依存ではないと判定し（ステップＳ１０４）、ステップＳ１０９に移行する。ステップＳ１０４において、判定部１５０ｄは、サブネットに含まれる各ホストのうち、ネットワーク遅延、ロス率が閾値以上となるホストを特定する。また、判定部１５０ｄは、ホストに設定されるウインドウサイズを探索してもよい。この場合、ステップＳ１０９では、ステップＳ１０４で特定した情報が、表示部１３０に出力される。

一方、判定部１５０ｄは、送信トラフィック量または受信トラフィック量が平常時よりも大きい場合には（ステップＳ１０３，Ｙｅｓ）、アプリ特性データ１４０ｇを参照し（ステップＳ１０５）、ネットワークの品質劣化が、アプリ特性に依存するか否かを判定する（ステップＳ１０６）。

ステップＳ１０６において、判定部１５０ｄは、アプリ特性データ１４０ｇのネットワーク遅延、送信ロス率、受信ロス率のいずれかが、ネットワーク品質診断テーブル１４０ｅの該当閾値よりも大きい場合に、ネットワークの品質劣化が、アプリ特性に依存すると判定する。判定部１５０ｄは、アプリ特性データ１４０ｇのネットワーク遅延、送信ロス率、受信ロス率のいずれも、ネットワーク品質診断テーブル１４０ｅの該当閾値以下の場合に、ネットワークの品質劣化が、アプリ特性に依存しないと判定する。

判定部１５０ｄは、ネットワークの品質劣化が、アプリ特性に依存しない場合には（ステップＳ１０６，Ｎｏ）、ネットワークの品質劣化の原因が、トラフィック依存であると判定し（ステップＳ１０７）、ステップＳ１０９に移行する。判定部１５０ｄは、ステップＳ１０７において、トラフィック量が所定値よりも大きいサブネット等を、ネットワーク集計データ１４０ｂを基に特定し、回線速度や負荷分散の最適化を行っても良い。また、この場合、ステップＳ１０９では、ステップＳ１０７で特定した情報が、表示部１３０に出力される。

これに対して、判定部１５０ｄは、アプリ特性に依存すると判定した場合には（ステップＳ１０６，Ｙｅｓ）、品質劣化の原因がアプリ依存であると判定し（ステップＳ１０８）、判定結果を出力する（ステップＳ１０９）。判定部１５０ｄは、ステップＳ１０８において、ネットワーク集計データ１４０ｂを基にして、トラフィック量が所定値より大きいアプリを特定しても良い。また、この場合、ステップ１０９では、ステップＳ１０８で特定した情報が、表示部１３０に出力される。

図１０のステップＳ１０１の説明に戻る。判定部１５０ｄは、ネットワーク集計データ１４０ｂのネットワーク遅延が、ネットワーク品質診断テーブル１４０ｅのネットワーク遅延の閾値以下の場合には（ステップＳ１０１，Ｎｏ）、送信ロス率または受信ロス率が閾値よりも大きいか否かを判定する（ステップＳ１１０）。

ステップＳ１１０において、判定部１５０ｄは、ネットワーク集計データ１４０ｂの送信ロス率が、ネットワーク品質診断テーブル１４０ｅのロス率の閾値よりも大きい場合に、送信ロス率が閾値よりも大きいと判定する。ネットワーク集計データ１４０ｂの受信ロス率が、ネットワーク品質診断テーブル１４０ｅのロス率の閾値よりも大きい場合に、受信ロス率が閾値よりも大きいと判定する。

判定部１５０ｄは、送信ロス率または受信ロス率が閾値よりも大きい場合には（ステップＳ１１０，Ｙｅｓ）、ステップＳ１０２に移行する。

一方、判定部１５０ｄは、送信ロス率および受信ロス率が閾値以下の場合には（ステップＳ１１０，Ｎｏ）、送信スループットまたは受信スループットが、平常時以下であるか否かを判定する（ステップＳ１１１）。

ステップＳ１１１において、判定部１５０ｄは、スループットデータ１４０ａの送信スループットが、ネットワーク品質診断テーブル１４０ｅの送信スループット以下の場合に、送信スループットが平常時以下であると判定する。判定部１５０ｄは、スループットデータ１４０ａの受信スループットが、ネットワーク品質診断テーブル１４０ｅの受信スループット以下の場合に、受信スループットが平常時以下であると判定する。

判定部１５０ｄは、送信スループットまたは受信スループットが、平常時以下の場合には（ステップＳ１１１，Ｙｅｓ）、ステップＳ１０２に移行する。

一方、判定部１５０ｄは、送信スループットおよび受信スループットが、平常時よりも大きい場合には（ステップＳ１１１，Ｎｏ）、サーバ処理時間が閾値よりも大きいか否かを判定する（ステップＳ１１２）。

ステップＳ１１２において、判定部１５０ｄは、ネットワーク集計データ１４０ｂのサーバ処理時間が、ネットワーク品質診断テーブル１４０ｅのサーバ処理時間の閾値よりも大きい場合に、サーバ処理時間が閾値よりも大きいと判定する。判定部１５０ｄは、ネットワーク集計データ１４０ｂのサーバ処理時間が、ネットワーク品質診断テーブル１４０ｅのサーバ処理時間の閾値以下の場合には、サーバ処理時間が閾値以下であると判定する。

判定部１５０ｄは、サーバ処理時間が閾値以下である場合には（ステップＳ１１２，Ｎｏ）、処理を終了する。このように、サーバ処理時間が閾値以下の場合には、ネットワークの品質劣化の原因が見当たらないことを示す。

一方、判定部１５０ｄは、サーバ処理時間が閾値よりも大きい場合には（ステップＳ１１２，ｙｅｓ）、データセンター６０側の劣化箇所を判定する（ステップＳ１１３）。

ステップＳ１１３に示した、データセンター６０側の劣化箇所を特定する処理の一例について説明する。判定部１５０ｄは、データセンター６０側の劣化箇所を特定することで、劣化箇所がＷｅｂサーバ７０なのか、ＡＰサーバ８０なのか、ＤＢサーバ９０なのかを判定する。判定部１５０ｄは、アプリ集計データ１４０ｃの処理時間と、アプリ品質診断テーブル１４０ｆの処理時間の閾値とを比較して、劣化箇所を判定する。

例えば、判定部１５０ｄは、アプリ集計データ１４０ｃのサービス名「ＷＥＢ」となるレコードの処理時間が、アプリ品質診断テーブル１４０ｆの１行目のレコードに含まれる処理時間の閾値よりも大きい場合に、Ｗｅｂサーバ７０が劣化箇所であると判定する。

例えば、アプリ集計データ１４０ｃの１行目において、レコードの処理時間が「２５０」であり、アプリ品質診断テーブル１４０ｆの１段目のレコードの処理時間の閾値「２００」よりも大きい。この場合には、判定部１５０ｄは、宛先ＩＰアドレス「Ｓ１」のＷｅｂサーバ７０が、劣化箇所であると判定する。

判定部１５０ｄは、アプリ集計データ１４０ｃのサービス名「ＡＰ」となるレコードの処理時間が、アプリ品質診断テーブル１４０ｆの２行目のレコードの処理時間の閾値「２００」よりも大きい場合に、ＡＰサーバ８０が劣化箇所であると判定する。

例えば、アプリ集計データ１４０ｃの２行目において、レコードの処理時間が「１１０」であり、アプリ品質診断テーブル１４０ｆの４段目のレコードの処理時間の閾値「２００」以下である。この場合には、判定部１５０ｄは、宛先ＩＰアドレス「ＡＰ１」のＡＰサーバ８０が、劣化箇所ではないと判定する。

判定部１５０ｄは、アプリ集計データ１４０ｃのサービス名「ＤＢ」となるレコードの処理時間が、アプリ品質診断テーブル１４０ｆの３行目のレコードの処理時間の閾値「２００」よりも大きい場合に、ＤＢサーバ９０が劣化箇所であると判定する。

例えば、アプリ集計データ１４０ｃの５行目において、レコードの処理時間が「８０」であり、アプリ品質診断テーブル１４０ｆの４段目のレコードの処理時間の閾値「２００」以下である。この場合には、判定部１５０ｄは、宛先ＩＰアドレス「ＤＢ１」のＤＢサーバ９０が、劣化箇所ではないと判定する。

判定部１５０ｄが、上記の処理を実行することで、劣化箇所が特定される。例えば、上記の例では、Ｗｅｂサーバ７０が劣化箇所として特定される場合を示したが、Ｗｅｂサーバ７０、ＡＰサーバ８０、ＤＢサーバ９０のうち、複数のサーバが、劣化箇所として特定される場合もあり得る。

判定部１５０ｄは、データセンター６０側の劣化箇所を特定した後に、特定した劣化箇所について、図１１のステップＳ１１５〜Ｓ１１７の処理をそれぞれ実行する。ここでは説明の便宜上、劣化箇所をＷｅｂサーバ７０として、ステップＳ１１４〜Ｓ１１６の処理を実行する場合について説明する。

図１１において、判定部１５０ｄは、リクエスト数が閾値よりも大きいか否かを判定する（ステップＳ１１４）。ステップＳ１１５において、判定部１５０ｄは、アプリ集計データ１４０ｃのリクエスト数が、アプリ品質診断テーブル１４０ｆのリクエストの閾値よりも大きい場合に、リクエスト数が閾値よりも大きいと判定する。判定部１５０ｄは、アプリ集計データ１４０ｃのリクエスト数が、アプリ品質診断テーブル１４０ｆのリクエストの閾値以下の場合に、リクエスト数が閾値以下であると判定する。

判定部１５０ｄは、リクエスト数が閾値以下である場合には（ステップＳ１１４，Ｎｏ）、劣化箇所の原因はリクエスト数に依存しないと判定し（ステップＳ１１５）、ステップＳ１０９に移行する。ステップＳ１１５において、判定部１５０ｄは、アプリ集計データ１４０ｃを基にして、オブジェクトの特定を行っても良い。

一方、判定部１５０ｄは、リクエスト数が閾値よりも大きい場合には（ステップＳ１１４，Ｙｅｓ）、劣化箇所の原因はリクエスト数に依存すると判定し（ステップＳ１１６）、ステップＳ１０９に移行する。ステップＳ１１６において、アプリ集計データ１４０ｃを基にして、リクエストの発生箇所となるホスト、サブネット、サイトを判定しても良い。また、判定部１５０ｄは、特定のＷｅｂサーバ７０にリクエストが集中している場合には、負荷分散を行っても良い。

判定部１５０ｄが、図１０，１１に示した処理を実行することで、ネットワークの品質劣化の原因を特定することが可能となる。図１２は、判定結果の一例を示す図である。図１２の判定結果は、図１１のステップＳ１０８で生成され、Ｓ１０９で表示部１３０に表示される画面の一例である。

図２の説明に戻る。可視化データ表示部１５０ｅは、記憶部１４０に記憶された各データ１４０ａ〜１４０ｇを基にして、ネットワーク品質に関連する特徴を可視化し、表示部１３０に出力する処理部である。

図１３は、可視化データ表示部が出力する可視化データの一例を示す図である。図１３に示す可視化データ３０ａは、リクエスト頻度やレスポンス時間を時系列で表したものである。可視化データ３０ｂは、サーバ処理時間の内訳を時系列で表したものである。サーバ処理時間の内訳は、Ｗｅｂサーバの処理時間、ＡＰサーバの処理時間、ＤＢサーバの処理時間である。可視化データ３０ｃは、レスポンス時間を時系列で表した散布図である。可視化データ３０ｄは、オブオブジェクトの内訳を示すものである。可視化データ３０ｅは、サーバの並列処理数を時系列で表したデータである。可視化データ３０ｆは、ネットワーク遅延を時系列で表したデータである。

次に、本実施例にかかる判定装置１００の効果について説明する。判定装置１００は、ネットワーク５０を介して複数のホストと複数のサーバとの間で送受信されるパケットを分析してネットワーク品質に関連する各種の特徴を特定する。そして、判定装置１００は、ネットワーク品質に関連する各種の特徴を基にして、ネットワークの品質劣化の原因を判定する。このため、判定装置１００によれば、多種多様な大量のデータから、ネットワークの品質劣化の原因を判定することができる。また、従来では、保守作業員が、図１３に示したデータを目視して、保守作業員の経験等を頼りに品質劣化の原因を判断していたが、本実施例の判定装置１００によれば、係る手間が省け、保守作業員の負担を削減することができる。

また、判定装置１００によれば、ネットワーク遅延およびロス率と、複数のホストから構成されるサブネットおよび自判定装置１００間のスループットの計測結果とを基にして、ホスト側に品質劣化の原因があるのか、サーバ側に品質劣化の原因があるのかを判定するので、ネットワークの品質劣化の原因を切り分けることができる。

また、判定装置１００によれば、ホスト側に品質劣化の原因があると判定した場合に、トラフィック量がトラフィック量の閾値よりも大きいか否かを判定し、トラフィック量がトラフィック量の閾値以下の場合に、ネットワーク遅延またはロス率の大きいホストを、品質劣化の原因として判定する。このため、トラフィック依存しない場合の、ネットワーク品質劣化の原因を判定することができる。

また、判定装置１００によれば、ホスト側に品質劣化の原因があると判定した場合に、トラフィック量がトラフィック量の閾値よりも大きいか否かを判定し、トラフィック量がトラフィック量の閾値よりも大きい場合に、アプリの種別に対応付けられたネットワーク遅延またはロス率が、ネットワーク遅延の閾値または所定のロス率の閾値よりも大きいか否かを判定し、アプリの種別に対応付けられたネットワーク遅延またはロス率が、ネットワーク遅延の閾値または所定のロス率の閾値よりも大きい場合に、品質劣化がアプリに依存するものであると判定し、アプリの種別に対応付けられたネットワーク遅延またはロス率が、ネットワーク遅延の閾値またはロス率の閾値以下の場合に、品質劣化がトラフィックに依存するものであると判定する。このため、ネットワーク品質劣化の原因が、アプリ依存であるか、トラフィック依存であるかを正確に判定することができる。

また、判定装置１００によれば、サーバ側に品質劣化の原因があると判定し、かつ、サーバ処理時間が処理時間の閾値より大きい場合に、サーバに対するリクエスト数が所定のリクエスト数よりも大きいか否かを判定し、リクエスト数がリクエスト数の閾値よりも大きい場合に、品質劣化がトラフィックに依存すると判定する。このため、データセンター６０側の劣化箇所を特定しつつ、トラフィック依存であることを正確に判定することができる。

また、判定装置１００によれば、サーバ側に品質劣化の原因があると判定し、かつ、サーバ処理時間が処理時間の閾値より大きい場合に、サーバに対するリクエスト数がリクエスト数の閾値よりも大きいか否かを判定し、リクエスト数がリクエスト数の閾値以下の場合に、品質劣化がリクエスト数に依存しないと判定する。このため、データセンター６０側の劣化箇所を特定しつつ、トラフィック依存でないことを正確に判定することができる。

ところで、本実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部あるいは一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

さらに、各装置にて行われる各処理機能は、その全部または任意の一部がＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

１０ａ，１０ｂ，１０ｃ サイト
５０ ネットワーク
６０ データセンター
７０ａ，７０ｂ，７０ｃ Ｗｅｂサーバ
８０ ＡＰサーバ
９０ ＤＢサーバ
１００ 判定装置

Claims (7)

1. ネットワークを介して複数のホストと複数のサーバとの間で送受信されるパケットを分析してネットワーク品質に関連する特徴として、前記パケットの送信元および送信先の組み毎に、ネットワーク遅延およびロス率を特定する生成部と、
   前記ネットワーク遅延およびロス率と、前記複数のホストから構成されるサブネットおよび自判定装置間のスループットの計測結果とを基にして、ホスト側に品質劣化の原因があるのか、サーバ側に品質劣化の原因があるのかを判定する判定部と
   を有することを特徴とする判定装置。
2. 前記生成部は、前記ネットワーク品質に関連する特徴として、パケットの送信元および送信先の組み毎に、該送信元および送信先で利用されるアプリの種別およびトラフィック量を更に特定して、ネットワーク遅延およびロス率と対応付け、
   前記判定部は、ホスト側に品質劣化の原因があると判定した場合に、トラフィック量が平均時のスループットの閾値よりも大きいか否かを判定し、トラフィック量が平均時のスループットの閾値以下の場合に、ネットワーク遅延またはロス率の大きいネットワーク機器を、品質劣化の原因として判定することを特徴とする請求項１に記載の判定装置。
3. 前記判定部は、ホスト側に品質劣化の原因があると判定した場合に、トラフィック量が平均時のスループットの閾値よりも大きいか否かを判定し、トラフィック量が平均時のスループットの閾値よりも大きい場合に、アプリの種別に対応付けられたネットワーク遅延またはロス率が、ネットワーク遅延の閾値または所定のロス率の閾値よりも大きいか否かを判定し、アプリの種別に対応付けられたネットワーク遅延またはロス率が、ネットワーク遅延の閾値または所定のロス率の閾値よりも大きい場合に、品質劣化がアプリに依存するものであると判定し、
   アプリの種別に対応付けられたネットワーク遅延またはロス率が、ネットワーク遅延の閾値またはロス率の閾値以下の場合に、品質劣化がトラフィックに依存するものであると判定することを特徴とする請求項２に記載の判定装置。
4. 前記生成部は、前記ネットワーク品質に関する特徴として、パケットの送信元および送信先の組み毎に、サーバ処理時間を更に特定し、
   前記判定部は、サーバ側に品質劣化の原因があると判定し、かつ、サーバ処理時間が処理時間の閾値より大きい場合に、サーバに対するリクエスト数が所定のリクエスト数よりも大きいか否かを判定し、リクエスト数がリクエスト数の閾値よりも大きい場合に、品質劣化がトラフィックに依存すると判定することを特徴とする請求項１に記載の判定装置。
5. 前記判定部は、サーバ側に品質劣化の原因があると判定し、かつ、サーバ処理時間が処理時間の閾値より大きい場合に、サーバに対するリクエスト数がリクエスト数の閾値よりも大きいか否かを判定し、リクエスト数がリクエスト数の閾値以下の場合に、品質劣化が個々のリクエストに対する処理に依存すると判定することを特徴とする請求項４に記載の判定装置。
6. コンピュータが実行する判定方法であって、
   ネットワークを介して複数のホストと複数のサーバとの間で送受信されるパケットを分析してネットワーク品質に関連する特徴として、前記パケットの送信元および送信先の組み毎に、ネットワーク遅延およびロス率を特定し、
   前記ネットワーク遅延およびロス率と、前記複数のホストから構成されるサブネットおよび自コンピュータ間のスループットの計測結果とを基にして、ホスト側に品質劣化の原因があるのか、サーバ側に品質劣化の原因があるのかを判定する
   各処理を実行することを特徴とする判定方法。
7. コンピュータに、
   ネットワークを介して複数のホストと複数のサーバとの間で送受信されるパケットを分析してネットワーク品質に関連する特徴として、前記パケットの送信元および送信先の組み毎に、ネットワーク遅延およびロス率を特定し、
   前記ネットワーク遅延およびロス率と、前記複数のホストから構成されるサブネットおよび自コンピュータ間のスループットの計測結果とを基にして、ホスト側に品質劣化の原因があるのか、サーバ側に品質劣化の原因があるのかを判定する
   各処理を実行させることを特徴とする判定プログラム。

Images