JP2001195285A

JP2001195285A - アプリケーション性能劣化要因分析方法，アプリケーション性能劣化要因分析システムおよびそのプログラム記録媒体

Info

Publication number: JP2001195285A
Application number: JP2000002210A
Authority: JP
Inventors: Takashi Horinouchi; 剛史堀之内
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2000-01-11
Filing date: 2000-01-11
Publication date: 2001-07-19

Abstract

(57)【要約】【課題】マルチメディアネットワークにおいて，標準
的に取得可能なトラヒック情報を用い，運用サーバへの
負荷等の影響を最小限に抑えて，特定サーバ（群）が提
供する特定アプリケーションの性能劣化要因を分析可能
にする。【解決手段】アプリケーションに特化したアクセス状
況情報αとアプリケーションに対する個々のアクセスの
アプリケーション性能情報βと，ネットワークインタフ
ェースの基本情報γおよびトラヒック情報δとを入力
し，αとδとから，アプリケーションのトラヒック情報
εと，その他のマルチメディアトラヒック情報ζとに分
類し，「β，δ，ε，ζの平均離散時系列データ群とそ
れらの加工データ群」の多変量分析により，アプリケー
ション性能の劣化がネットワークの伝送容量不足に起因
しているか否かを判断し，またアプリケーション性能へ
の影響の主要因を判断する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，インターネットプ
ロトコルに代表される多種多様なマルチメディアトラヒ
ックが混在したネットワークにおけるネットワーク管
理，および個々のアプリケーション等のサービス管理の
ためのアプリケーション性能劣化要因分析方法，アプリ
ケーション性能劣化要因分析システムおよびそのプログ
ラム記録媒体に関する。

【０００２】

【従来の技術】近年，多種多様なアプリケーションをイ
ンターネットプロトコル（ＩＰ）ベースのネットワーク
に統合する動きが顕著である。各種サーバ，端末，ネッ
トワーク伝送機器のインタフェース等に付与されたＩＰ
アドレスに従い，ルータによるパケット伝送を基本とす
る。ＩＰネットワークにより，各種のアプリケーション
通信が可能である。しかしながら，様々なアプリケーシ
ョンがネットワークを共有するＩＰネットワークには，
運用管理が難しいという本質的な問題がある。

【０００３】ＩＰネットワークを管理するためのプロト
コルとして，ＳＮＭＰ（Simple Network Management Pr
otocol）がある。ＩＰネットワークの構成機器であるル
ータは，トラヒック管理情報（ＭＩＢ（Management Inf
ormation Base)−IIなど）を標準サポートしており，ル
ータの稼動状況や，ルータに備わるネットワークインタ
フェースの基本情報（最大伝送帯域など）や，トラヒッ
ク情報（伝送情報量，伝送パケット数，エラーパケット
数，パケット廃棄数など）を取得できる＜方法１＞。こ
れらの情報を一元的に管理するツールは多数製品化され
ており，ネットワーク管理者は，管理ツールを用いてル
ータやインタフェースの稼動／障害状況，トラヒック情
報を視覚的に把握することができる。

【０００４】一方，ＩＰアドレスや，各種アプリケーシ
ョンを区別して，トラヒック管理ができるように各種の
ＭＩＢ情報（ＲＭＯＮ（Remote network MONitoring ）
１／２など）が標準化されている＜方法２＞。これらの
ＭＩＢ情報に基づくネットワーク管理ツールも多数製品
化されている。これにより，ネットワーク管理者はＩＰ
アドレスや上位のプロトコル（ＴＣＰ，ＵＤＰ，ＨＴＴ
Ｐ，ＦＴＰ，ＳＭＴＰなど）別のトラヒック情報を管理
することができる。これらのツールを用いて，特定サー
バ（群）上の特定アプリケーションに特化したトラヒッ
ク管理も可能である。

【０００５】ＬＡＮ内や個別アプリケーショントラヒッ
クを詳細に分析するツールとして，各種ＬＡＮアナライ
ザ製品やフリーのツール（”tcpdump ”など）があり，
パケットレベルの詳細な解析が可能である＜方法３＞。

【０００６】サーバ（群）単体，ネットワーク単体，エ
ンドエンド通信の性能を測定する方法として，"ping ”
等の測定コマンドや，擬似トラヒックを各種の条件にお
いて発生させ，その条件と観測された性能の関係から，
ネットワークの問題点を分析することが可能である＜方
法４＞。

【０００７】＜方法４＞とは異なり，物理ネットワーク
構成や，アプリケーションの利用形態を模擬し，ネット
ワーク性能を分析することが可能である＜方法５＞。

【０００８】ネットワークサービスの障害発生時にトラ
ブル原因を自動的に判断して，対策方法をユーザに提示
する方法およびシステムとして，特開平１０−２２９３
９６号公報に示されている「サービス管理方法及びシス
テム」の発明がある＜方法６＞。

【０００９】サブネットワーク単位の統計情報の収集を
行い，ＷＡＮに適したトラヒックの集計モニタができる
監視システムとして，特開平１１−１３６２３７号公報
に示されている「ネットワークトラフィック監視システ
ム」の発明がある＜方法７＞。

【００１０】

【発明が解決しようとする課題】しかし，特定サービス
の性能劣化原因を分析したり，将来ボトルネックになり
そうな要因を抽出したりする要求に対し，前記の各種方
法は，以下に述べる理由により必ずしも十分とは言えな
い。

【００１１】方法１は，ＯＳＩ参照モデルレイヤ２以下
のトラヒック情報を管理する方法であり，主にネットワ
ーク障害の管理に適した方法である。よって，特定アプ
リケーションの性能との関連性は把握できない。

【００１２】方法２は，アプリケーションやサーバ単位
のトラヒック情報を管理できるものの，現状のツールは
測定データの視覚化レベルにとどまり，分析自体は管理
者が行うことになる。そのため，管理者の分析スキルが
必要とされる。また，ＲＭＯＮ２によるアプリケーショ
ン単位，プロトコル単位のトラヒック情報収集には，相
当量のＣＰＵ資源，ネットワーク資源を必要とする。負
荷軽滅のため，ほとんどの既存ルータ装置には，方法２
のＲＭＯＮ仕様のすべては実装されておらず，ＲＭＯＮ
２ＭＩＢ情報を取得する箇所ごとに高価な測定装置を
設置する必要がある。

【００１３】方法３により，ネットワークにおける最も
詳細なパケットレベルの情報を取得できる。しかし，そ
の分析には高度なスキルを要する。また，障害時の原因
追求や実験環境における性能分析などの場面で用いる方
法であり，定常的に測定結果に基づいて分析する用途に
は不向きである。

【００１４】方法４により，実ネットワーク環境におい
て特定サービスの性能劣化原因の分析が可能である。し
かしながら，測定目的の付加的なトラヒックの発生やサ
ーバ処理の増加により，提供サービスの性能劣化を招く
危険がある。サービス停止や品質低下により致命的な損
害を発生するようなクリティカルなサービスへの適用は
望ましくない。

【００１５】方法５により，方法４の問題は回避でき
る。しかし，複雑な実ネットワーク環境を適切に表現し
たシミュレーションモデルの構築にはノウハウを要し，
非常に困難である。また，そのように構築したシミユレ
ーションモデルにおける結果の妥当性に信憑性がないこ
と，オンラインで継続的にトラヒック分析することは，
現実的に不可能であることなどが問題である。

【００１６】方法６では，サービス提供上の構成要素で
あるネットワーク機器等に関し，ネットワークサービス
を正常に提供可能な性能を事前に保持しておき，実サー
ビス運用時の観測された値との比較によって，各機器の
状態を判断する。この方法６は，ネットワークサービス
の障害対策として有用であるが，ネットワーク機器等の
状態が正常な範囲にある場合に，管理者にとって有用な
情報は得られない。つまり，潜在的な障害・性能劣化要
因を分析する機能をもたない。

【００１７】方法７を用いれば，サービス提供サーバ群
のトラヒックを効率的に分析可能と思われる。しかし，
この方法は，ネットワークサービスの性能とトラヒック
情報の関連性を分析する機能をもたない。

【００１８】このような各種の手法の課題を踏まえ，本
発明は，次のような特徴を持つ手段を提供し，サービス
／ネットワーク管理者にサービス／ネットワークのマク
ロな分析情報を示すことにより，詳細な分析を行う箇所
の優先順序付けや，設備増強箇所の特定などの支援を目
的とする。・ＩＰプロトコルに基づく任意のネットワーク構成にお
いて，標準的に取得可能なトラヒック情報を利用する。・付加的なトラヒック測定機器を必ずしも必要としな
い。・測定のためのトラヒック発生を抑制する。・性能劣化要因分析時に，運用サーバに対する負荷等の
影響を最小限にする。・特定のネットワークサービスについて，サーバ，管理
対象ネットワーク構成装置，非管理対象ネットワーク構
成装置（他管理下のネットワーク，クライアント端末
等）の３要素に性能劣化要因を切り分け提示する。・特定のネットワークサービスのトラヒックと他トラヒ
ックとの相互影響や，それぞれの性能劣化に与える影響
度を把握する。

【００１９】

【課題を解決するための手段】上記課題を解決するた
め，本発明は，マルチメディアネットワークにおいて，
１または複数の特定サーバが提供する特定アプリケーシ
ョンの性能劣化要因を分析する際に，前記アプリケーシ
ョンに特化したアクセス（ダウンロード／アップロー
ド）状況情報αを取得する第１の手段と，前記アプリケ
ーションに対する個々のアクセスのアプリケーション性
能情報β（スループット，応答時間等）を取得する第２
の手段と，サーバ・クライアント間の通信経路におい
て，一つもしくはそれ以上のネットワークインタフェー
スの基本情報γ（最大伝送可能帯域など）と，トラヒッ
ク情報δを収集する第３の手段とを有し，前記第１の手
段によるアクセス状況情報と，前記第３の手段によるト
ラヒック情報から，前記アプリケーションのトラヒック
情報εと，その他のマルチメディアトラヒック情報ζに
分類し，「β，δ，ε，ζの平均離散時系列データ群と
それらの加工データ群」などの多変量分析により，前記
アプリケーション性能の劣化が，前記ネットワークの伝
送容量不足に起因しているか否かを判断するのに加え，
起因すると判断した場合には，前記アプリケーショント
ラヒック，その他のマルチメディアトラヒックのどちら
がアプリケーション性能への影響の主要因であるかを判
断する機能を有する。

【００２０】また，前記第１，第２および第３の手段に
加え，前記サーバ（群）の装置性能に関する情報（群）
（ＣＰＵロード，メモリ使用率など）ηｉ（ｉ＝１，
２，…）を取得する第４の手段と，時間帯区分，平日／
休日分類等のトレンド情報（群）θｊ（ｊ＝１，２，
…）を取得する第５の手段とを有し，「β，δ，ε，
ζ，ηｉ，θｊの平均離散時系列データ群とそれらの加
工データ群」などの多変量分析を行い，前記アプリケー
ション性能の劣化が，前記サーバの性能，ネットワーク
の伝送容量，その他の性能（クライアント，インターネ
ット等の制御不能ネットワーク，観測点以外の制御可能
ネットワーク）のいずれがアプリケーション性能劣化の
主要因であるかを判断し，ネットワークの伝送容量不足
と判断した際には，前記の分析を実施する機能を有す
る。

【００２１】また，「β，δ，ε，ζ（，ηｉ，θｊ）
およびそれらの加工データ群」における関係の組合せと
それに対してサーバ管理者またはネットワーク管理者が
とるべき有力な対処方法に関する情報とを一レコードと
して，複数レコードを記録したルールベースιを有し，
前記の分析方法の実施結果をもとにルールベースιを参
照し，サーバ管理者またはネットワーク管理者に対処方
法を提示する手段を有する。

【００２２】また，「β，δ，ε，ζ（，ηｉ，θｊ）
およびそれらの加工データ群」における関係の組合せと
それに対してサーバ管理者またはネットワーク管理者が
とるべき有力な対処方法に関する情報を一レコードとし
て，複数レコードを記録したルールベースιの構築方法
として，「β，δ，ε，ζ（，ηｉ，θｊ）およびそれ
らの加工データ群」の相関行列を生成し，相関行列の特
定の要素（群）が，それらに対応する特定の閾値を超え
るか否かにより対処方法を定める機能を有する。

【００２３】また，「β，δ，ε，ζ（，ηｉ，θｊ）
およびそれらの加工データ群」における関係の組合せと
それに対してサーバ管理者またはネットワーク管理者が
とるべき有力な対処方法に関する情報を一レコードとし
て，複数レコードを記録したルールベースιの構築方法
として，「β，δ，ε，ζ（，ηｉ，θｊ）およびそれ
らの加工データ群」の相関行列を生成し，相関行列の特
定の要素群が，特定の順序関係を満たすか否かにより対
処方法を定める機能を有するようにしてもよい。

【００２４】以上のアプリケーション性能劣化要因を分
析する処理方法をコンピュータによって実現するための
プログラムは，コンピュータが読み取り可能な可搬媒体
メモリ，半導体メモリ，ハードディスクなどの適当な記
録媒体に格納することができる。

【００２５】

【発明の実施の形態】本発明の実施の形態について図面
を参照して説明する。

【００２６】図１は，本発明を適用するネットワーク構
成の例を示す。情報要求元のクライアント（群）１０１
は，サーバ１０２の「サービス／ネットワーク管理者」
が管理できないネットワーク１０３（例えば，インター
ネット），性能上のボトルネック候補であるネットワー
ク１０４（例えば，インターネット接続用の専用回
線），「サービス／ネットワーク管理者」が管理可能な
ネットワーク１０５（例えば，イントラネット）を通じ
て，サーバ１０２にサービス要求を発する。

【００２７】サーバ１０２は，ネットワーク１０５，ネ
ットワーク１０４，ネットワーク１０３という経路をも
って，要求されたサービスをクライアント（群）１０１
に提供する。サーバ１０２のサービス提供状況は，サー
バ１０２のログ情報１０６として記録される。また，ト
ラヒックの発生状況は，ＳＮＭＰプロトコルを使用し，
ルータ１０７のＭＩＢ−II情報として取得できる。ただ
し，ネットワーク１０５には，サーバ１０２以外にも，
多数のサーバ（群）１０９，クライアント（群）１１０
が接続されており，ネットワーク１０４を通じてネット
ワーク１０３向けにトラヒックを発生している。ルータ
１０７のＭＩＢ情報では，前記の装置（サーバ１０２，
その他のサーバ群１０９，クライアント群１１０）のト
ラヒックを区別することはできない。なお，破線で示す
矩形領域１１１は，サービス／ネットワーク管理が可能
な領域を示している。

【００２８】本発明の第１の実施の形態（請求項１の発
明に対応する）について順に説明する。サーバ１０２の
アクセス（ダウンロード／アップロード）状況情報αの
取得手段とその前処理方法の実施例を説明する。以下の
二つの形態が考えられる。

【００２９】形態１−１：サーバのアクセスログ情報を
利用する形態形態１−２：アプリケーションセッション状況の監視ツ
ールを利用する形態形態１−１では，サーバ上のアクセスログもしくはその
一部の加工情報をアプリケーション性能劣化要因分析シ
ステムに渡す機能が必要である。具体例として，ＦＴＰ
（File Transfer Protocol）によるファイル伝送や，物
理的な記憶媒体による情報伝達が挙げられる。形態１−
２では，サーバ上に観測モジュールを常駐させておく
か，サーバのネットワークインタフェースもしくは接続
ケーブルに流れるトラヒック情報を取得するツールを要
する。この形態１−２では，サーバに常駐するモジュー
ルが継続的にサーバ資源を消費したり，付加的な測定ツ
ールを要するという欠点がある。

【００３０】アクセス状況情報に基づく時系列データ出
力形式の例を図２に示す。これは，５分間のデータ送出
量を時系列に記録したものである。形態１−２では，ネ
ットワークインタフェースを流れるデータ量を５分周期
で測定することにより取得できる。

【００３１】形態１−１にて取得する方法を以下に示
す。必要なアクセスログの項目は以下の通りである。

【００３２】Ａ：データ送出終了日時／時刻Ｂ：送出データ量Ｃ：データ送出期間Ａ，ＢはＷＷＷサーバのＣｏｍｍｏｎＬｏｇ形式に含
まれており，ログ記録機能を有するＷＷＷサーバシステ
ムにおいては必ず取得できる。Ｃは拡張項目であるが，
ほとんどのサーバシステムで取得可能である。

【００３３】個々のデータ伝送（ログの一行に相当）に
おいて，常に一定の帯域を消費するものとみなす。Ａ，
Ｃのデータより送出開始時刻と終了時刻がわかり，その
期間の間，Ｂ÷Ｃの伝送速度でデータを送出するものと
する。単位時間ごとの配列を用意し，送出開始時間から
終了時間の間で単位時間区切りのデータ伝送量を求め，
配列の値に加える。この操作を全てのデータに対して繰
り返し，最終的に，単位時間ごとの推定データ伝送量の
時系列データが得られる。

【００３４】図３を用いて詳しく説明する。ログに３つ
のデータ送出記録がある。では，データ送出開始時刻
０時０分０秒からデータ送出終了時刻０時１分３０秒ま
でに９００バイトのデータを送出したので，６００バイ
ト／分の速度でデータを送出するものとみなす。よっ
て，はじめの単位時間（０時０分０秒〜０時１分０秒）
には６００バイト，次の単位時間（０時１分０秒〜０時
２分０秒）には３００バイトのデータを送出したことに
なる。この操作をからまで繰り返すと，はじめの単
位時間（０時０分０秒〜０時１分０秒）には１１００バ
イト，次の単位時間（０時１分０秒〜０時２分０秒）に
は１９００バイトのデータを送出したことになる。

【００３５】サーバ１０２に対する個々のアクセスのア
プリケーション性能情報β（スループット，応答時間
等）を取得する手段と，その前処理の実施例を説明す
る。この場合にも，以下の二つの形態が考えられる。

【００３６】形態２−１：サーバのアクセスログ情報を
利用する形態形態２−２：アプリケーションセッション状況の監視ツ
ールを利用する形態形態２−２では，セッション単位に最初のパケットと最
後のパケットの送出時間間隔を計測し，全パケットのデ
ータ量を時間で割ることによりスループットを得る。

【００３７】形態２−１では，前記のＡ，Ｂ，Ｃの情報
をもとに，スループットに相当する．を以下のように求
める。サーバが記録するＣ（データ伝送時間）は，クラ
イアント要求に対するアプリケーションプロセスが開始
されてから，アプリケーションプロセスが終了する（デ
ータをサーバ側の送出バッファに渡す）までの期間に相
当し，ＴＣＰ等のトランスポート層の処理時間等を含ま
ない（図４参照）。そのため，クライアントの体感時間
とは乖離がある。このような乖離の影響を少なくするた
めに，サーバ送出バッファの大きさ以上のデータのみを
アプリケーション性能情報βの測定材料とする。これ
は，データ量の小さなオブジェクトは，一度に送出バッ
ファに書き込むことが可能となり，アクセスログの伝送
時間Ｃには，ネットワークの伝送時間を全く含まないこ
ととなるためである。

【００３８】アプリケーション性能情報βの算出方法の
一例は，以下のとおりである。データ量をＸ，データ伝
送時間をＣ，バッファサイズをＢとして，このセッショ
ンのスループットは（Ｘ−Ｂ）／Ｃとなる。この操作を
各セッションに対して繰り返すことにより，図５のよう
なセッションの平均スループットに関する５分ごとの時
系列データを得る。

【００３９】サーバ・クライアント間の通信経路上のル
ータにおけるネットワークインタフェースの基本情報γ
（最大伝送可能帯域など）と，トラヒック情報δを収集
する実施例を説明する。図１のルータ１０７のＷＡＮ側
インタフェースを例として説明する。γ，δともにルー
タが保持する標準のＭＩＢ−II情報よりＳＮＭＰプロト
コルを介して取得できる。具体的には，それぞれinterf
ace グループのifSpeed ，ifOutOctets オブジェクトを
得る。このうちifOutOctets についてはカウンタ情報で
あるため，５分ごとに取得要求を発し，前回のカウンタ
値と今回のカウンタ値の差分を得る。この時系列データ
を図２と同様の形式で記録する。

【００４０】アクセス状況情報αとトラヒック情報δか
ら，アプリケーションのトラヒック情報εと，その他の
マルチメディアトラヒック情報ζとに分類する方法は，
例えば以下のとおりである。アプリケーションのトラヒ
ック情報εは，アクセス状況情報αの時系列データその
ものであり，その他のマルチメディアトラヒック情報ζ
は，トラヒック情報δの時系列データからアクセス状況
情報αの時系列データ分を差し引いた時系列データであ
る。従って，アクセス状況情報αの時系列データをアプ
リケーションのトラヒック情報εとし，トラヒック情報
δの時系列データからアクセス状況情報αの時系列デー
タ分を差し引いた時系列データを，その他のマルチメデ
ィアトラヒック情報ζとして分類する。

【００４１】「β，δ，ε，ζの平均離散時系列データ
群とそれらの加工データ群」を多変量分析する実施例を
説明する。分析する多変量の例として，アプリケーショ
ン性能情報β，アプリケーショントラヒック情報ε，マ
ルチメディアトラヒック情報ζ，ＷＡＮ回線空帯域情報
（δ−ε−ζ），アプリケーショントラヒックの占める
割合ε／（ε＋ζ）を用意する。各変数の時系列データ
を入力として，多変量変数の相関行列を作成する。

【００４２】アプリケーション性能の劣化が，前記ネッ
トワークの伝送容量不足に起因しているか否かを判断す
る実施例を説明する（図６：ステップＳ１〜Ｓ３）。前
記の相関行列よりアプリケーション性能情報β，ＷＡＮ
回線空帯域情報（δ−ε−ζ）の相関係数を調べる（ス
テップＳ１）。この相関係数が特定の閾値Ｘよりも高
く，強い正の相関が認められれば，アプリケーション性
能の劣化がネットワークの伝送容量不足に起因するとみ
なす（ステップＳ２）。そうでなければ，ネットワーク
の伝送容量が問題ではないとする（ステップＳ３）。

【００４３】アプリケーショントラヒック，その他のマ
ルチメディアトラヒックのどちらがアプリケーション性
能への影響の主要因であるかを判断する実施例を説明す
る（図６：ステップＳ４〜Ｓ７）。前記の相関行列より
アプリケーション性能情報β，アプリケーショントラヒ
ックの占める割合ε／（ε＋ζ）との間の相関係数を調
べる。この相関係数が特定の閾値Ｙよりも低く，強い負
の相関が認められれば（ステップＳ４），アプリケーシ
ョンのトラヒック自体がＷＡＮ帯域を圧迫しており，ア
プリケーション性能の劣化を引き起こしたとみなす（ス
テップＳ５）。逆に相関係数が特定の閾値Ｚよりも高
く，強い正の相関が認められれば（ステップＳ６），そ
の他のマルチメディアトラヒックがＷＡＮ帯域の圧迫を
引き起こし，アプリケーション性能の劣化を引き起こし
たとみなす（ステップＳ７）。

【００４４】本発明の第２の実施の形態（請求項２の発
明に対応する）について，前述した第１の実施の形態と
の差分のみを，以下に説明する。

【００４５】サーバ（群）の装置性能に関する情報
（群）（ＣＰＵロード，メモリ使用率など）ηｉ（ｉ＝
１，２，…）を取得するには，オペレーティング・シス
テム組込みの測定コマンド（ＵＮＩＸであればｗコマン
ドなど）を呼び出して取得するか，測定用のアプリケー
ションから値を受け渡してもらうことにより取得する。
具体的には，５分より短い周期単位で測定し，５分間の
平均値を用いる。

【００４６】時間帯区分，平日／休日分類等のトレンド
情報（群）θｊ（ｊ＝１，２，…）を取得する実施例を
説明する。時間帯区分については，例えば０時からの２
４時までの１時間単位の変数θｉ（ｉ＝１，２，…，２
４）を用意する。ζｉはｉ−１時からｉ時の間であれば
１，それ以外であれば０をとる変数である。また，勤務
時間帯，テレホーダイ時間帯等のトラヒック変動に影響
のありそうな変数を用意してもよい。平日／体日分類に
ついても，平日である場合に１となり，休日となる場合
に０となる変数θｘを用意する。

【００４７】「β，δ，ε，ηｉ，θｊの平均離散時系
列データ群とそれらの加工データ群」の多変量分析法に
ついては，データ項目数が増えただけで，第１の実施の
形態で説明した方法と同じである。

【００４８】アプリケーション性能の劣化が，前記サー
バの性能，（前記観測点の）ネットワークの伝送容量，
その他の性能（クライアント，インターネット等の制御
不能ネットワーク，観測点以外の制御可能ネットワー
ク）のいずれがアプリケーション性能劣化の主要因であ
るかを判断する場合の例について，図７を用いて説明す
る。

【００４９】アプリケーション性能情報βに対し，サー
バ（群）の装置性能に関する情報（群）ηｉ，前記回線
空帯域情報（δ−ε−ζ），トレンド情報（群）θｊの
相関係数を得る（ステップＳ１１）。これらの相関係数
の絶対値および相対関係により分類する。まず，トレン
ド情報θｉのみの相関係数の絶対値が大きい場合（ステ
ップＳ１２），アプリケーションの性能劣化は，サービ
ス事業者の管轄外であるインターネット上のみの問題で
あるとみなす（ステップＳ１３）。

【００５０】次に，サーバ（群）の装置性能に関する情
報（群）ηｉとの相関係数の絶対値が大きく，回線空帯
域情報（δ−ε−ζ）との相関係数の絶対値が小さい場
合（ステップＳ１４），サーバ性能の問題であるとみな
す（ステップＳ１５）。回線空帯域情報（δ−ε−ζ）
との相関係数の絶対値が大きい場合には（ステップＳ１
６），第１の実施の形態と同様，ネットワーク伝送容量
の問題であるとみなす（ステップＳ１７）。

【００５１】本発明の第３の実施の形態（請求項３，４
の発明に対応する）について，第１および第２の実施の
形態との差分のみ以下に説明する。

【００５２】「β，δ，ε，ζ（，ηｉ，θｊ）および
それらの加工データ群」における関係の組合せとそれに
対してサーバ管理者またはネットワーク管理者がとるべ
き有力な対処方法を一レコードとして，複数レコードを
記録したルールベースιの形式例を図８に示す。

【００５３】レコードは条件変数項Ｖ_k（ｋは項数）の
集合と，結果出力項Ｒより構成される。各条件変数項に
は，条件式（Ａ_k，Ｂ_k，Ｘ_k）が対応する。Ａ_k，Ｂ
_kは，ｘ，ｙの相関係数Ｃ（ｘ，ｙ），その絶対値｜Ｃ
（ｘ，ｙ）｜，定数のいずれかである。Ｘ_kは，Ａ_k，
Ｂ_kの比較演算子であり，＞／≧／＜／≦のいずれかで
ある。条件変数項は，ｔｒｕｅ／ｆａｌｓｅ／−のいず
れかの値をとり，それぞれ（Ａ_k，Ｂ_k，Ｘ_k）を「満
たす」／「満たさない」／「考慮しない」を意味する。
条件変数項が“ｔｒｕｅ”である条件式をすべて満た
し，“ｆａｌｓｅ”である条件式をすべて満たさない場
合に限り，結果出力項Ｒを出力する。

【００５４】以上のアプリケーション性能のボトルネッ
ク箇所分析などの性能劣化要因の分析に用いるルールベ
ースιの構築方法として，アプリケーション性能情報
β，トラヒック情報δ，アプリケーションのトラヒック
情報ε，その他のマルチメディアトラヒック情報ζ，ま
たはこれらの情報と装置性能に関する情報ηｉ，トレン
ド情報θｊの平均離散時系列データ群，およびそれらの
加工データ群の相関行列を生成し，相関行列の特定の要
素または要素群が，それらに対応する特定の閾値を超え
るか否かにより対処方法を定める方法を用いることがで
きる。これは，図８において，Ａ_kが，ｘ，ｙの相関係
数Ｃ（ｘ，ｙ）またはその絶対値｜Ｃ（ｘ，ｙ）｜の関
数であり，Ｂ_kが定数である場合に対応する。

【００５５】また，ルールベースιの構築方法として，
アプリケーション性能情報β，トラヒック情報δ，アプ
リケーションのトラヒック情報ε，その他のマルチメデ
ィアトラヒック情報ζ，またはこれらの情報と装置性能
に関する情報ηｉ，トレンド情報θｊの平均離散時系列
データ群，およびそれらの加工データ群の相関行列を生
成し，相関行列の特定の要素または要素群が，特定の順
序関係を満たすか否かにより対処方法を定める方法を用
いることもできる。これは，図８において，Ａ _k，Ｂ_k
ともに，ｘ，ｙの相関係数Ｃ（ｘ，ｙ）またはその絶対
値｜Ｃ（ｘ，ｙ）｜の関数である場合に対応する。

【００５６】さらに，ルールベースιの構築方法とし
て，アプリケーション性能情報β以外の変数間の相関係
数から知識ルールを構築してもよい。例えば，アプリケ
ーション性能情報β，ＷＡＮ回線空帯域情報（δ−ε−
ζ）の相関係数が高く，かつその他のマルチメディアト
ラヒック情報ζ，ＷＡＮ回線空帯域情報（δ−ε−ζ）
の相関係数が著しく高ければ，「帯域制御によりアプリ
ケーションの帯域を確保するのがよい」等のルールを生
成する。

【００５７】図９は，本発明を実現するシステムの構成
例を示す。アクセス状況情報取得手段２１０は，サーバ
のアクセスログ１０６（形態１−１の場合）またはトラ
ヒック状況観測モジュール１０２１（形態１−２の場
合）からアプリケーションに特化したアクセス状況情報
を取得し，アクセス状況情報変換部２１１によって所定
の形式のアクセス状況情報αを生成する。

【００５８】ネットワーク情報収集手段２２０は，ルー
タ１０７からＭＩＢ情報１０７１を得て，ネットワーク
情報変換部２２１によって所定の形式のトラヒック情報
δおよびネットワークインタフェース基本情報γを生成
する。

【００５９】アプリケーション性能情報取得手段２３０
は，サーバのアクセスログ１０６（形態１−１の場合）
またはアプリケーションセッション観測モジュール１０
２２（形態１−２の場合）からアプリケーションに対す
る個々のアクセスのアプリケーション性能情報を得て，
アプリケーション性能情報変換部２３１によって所定の
形式のアプリケーション性能情報βを生成する。

【００６０】トラヒック分類手段２４０のトラヒック分
類部２４１は，アクセス状況情報αとトラヒック情報δ
とから，アプリケーションのトラヒック情報εと，その
他のマルチメディアトラヒック情報ζとに分類した情報
を求め，その情報を分析手段２５０に引き渡す。分析手
段２５０は，多変量分析部２５１によって，アプリケー
ション性能情報β，トラヒック情報δ，アプリケーショ
ンのトラヒック情報ε，その他のマルチメディアトラヒ
ック情報ζの平均離散時系列データ群とそれらの加工デ
ータ群の多変量分析を行い，あらかじめルールベース登
録手段２７０のルールベース登録部２７１によって登録
したルールベースιを，ルールベース参照手段２６０の
ルールベース参照部２６１によって参照し，アプリケー
ション性能の劣化が，ネットワークの伝送容量不足に起
因しているか否かを判断する。また，ネットワークの伝
送容量不足に起因すると判断した場合には，アプリケー
ショントラヒック，その他のマルチメディアトラヒック
のどちらがアプリケーション性能への影響の主要因であ
るかを判断する。

【００６１】この判断結果を分析結果提示手段２８０へ
送り，結果出力部２８１によって結果表示装置２９０に
出力する。

【００６２】さらに装置性能取得手段（図示省略）によ
ってサーバの装置性能に関する情報ηｉ（ｉ＝１，２，
…）を取得し，また，トレンド情報取得手段（図示省
略）によって時間帯区分，平日／休日分類またはその他
の日時に関連するトレンド情報θｊ（ｊ＝１，２，…）
を取得し，多変量分析部２５１では，アプリケーション
性能情報β，トラヒック情報δ，アプリケーションのト
ラヒック情報ε，その他のマルチメディアトラヒック情
報ζ，装置性能に関する情報ηｉ，トレンド情報θｊの
平均離散時系列データ群とそれらの加工データ群の多変
量分析により，アプリケーション性能の劣化が，サーバ
の性能，ネットワークの伝送容量，その他の性能のいず
れがアプリケーション性能劣化の主要因であるかを判断
するようにしてもよい。このときネットワークの伝送容
量不足と判断した際には，アプリケーショントラヒッ
ク，その他のマルチメディアトラヒックのどちらがアプ
リケーション性能への影響の主要因であるかを判断す
る。

【００６３】ルールベースιには，ルールベース登録部
２７１によって，アプリケーション性能情報β，トラヒ
ック情報δ，アプリケーションのトラヒック情報ε，そ
の他のマルチメディアトラヒック情報ζ，またはこれら
の情報と装置性能に関する情報ηｉ，トレンド情報θｊ
の平均離散時系列データ群，およびそれらの加工データ
群における関係の組合せと，それに対してサーバ管理者
またはネットワーク管理者がとるべき有力な対処方法に
関する情報とを一レコードとして，複数レコードが記録
されている。分析手段２５０では，多変量分析の実施結
果をもとにルールベースιを参照し，分析結果提示手段
２８０を介して，サーバ管理者またはネットワーク管理
者に対処方法を提示する。

【００６４】上記アクセス状況情報取得手段２１０，ネ
ットワーク情報収集手段２２０，アプリケーション性能
情報取得手段２３０，トラヒック分類手段２４０，分析
手段２５０，ルールベース参照手段２６０，ルールベー
ス登録手段２７０，分析結果提示手段２８０，結果表示
装置２９０は，サーバ１０２内に設けてもよいが，サー
バ１０２の負荷を軽減するために，サーバ１０２以外の
装置に実装したほうが望ましい。必要に応じて複数の装
置に分散させることもできる。各手段のすべてを必ずし
もネットワーク１０５に接続される装置に設ける必要は
ないが，ネットワーク情報収集手段２２０は，ルータ１
０７からＭＩＢ情報１０７１を取得できる位置に配置す
る必要がある。

【００６５】なお，上記の例は，本発明の説明のために
示したものであり，本発明がこれらの実施方法に限定さ
れるものではないことは言うまでもない。

【００６６】

【発明の効果】以上説明したように，本発明によれば，
ＩＰプロトコルに基づく任意のネットワーク構成におい
て，標準的に取得可能なトラヒック情報を利用したり，
付加的なトラヒック測定機器を必ずしも必要としないと
いう汎用性と，測定のためのトラヒック発生や運用サー
バに対する負荷等を最小限に抑制するという安全性を有
し，特定ネットワークサービスについて，サーバ，管理
対象ネットワーク構成装置，非管理対象ネットワーク構
成装置（他管理下のネットワーク，クライアント端末
等）の３要素に性能劣化要因を切り分け提示したり，特
定ネットワークサービスのトラヒックと他トラヒックと
の相互影響や，それぞれの性能劣化に与える影響度を把
握することにより，サービス／ネットワーク管理者にサ
ービス／ネットワークのマクロな分析情報を示し，詳細
な分析を行う箇所を優先順序付けしたり，設備増強箇所
の特定を手助けするという効果がある。

【図面の簡単な説明】

【図１】本発明を適用するネットワーク構成の例を示す
図である。

【図２】アプリケーションサーバのアクセス状況情報に
基づく時系列データ出力形式の例を示す図である。

【図３】サーバのアクセスログから推定データ伝送量の
時系列データを生成する例を示す図である。

【図４】サーバに記録されるデータ伝送時間とクライア
ントの体感伝送時間の違いを説明するための図である。

【図５】単位時間ごとの平均スループットを記録する形
式の例を示す図である。

【図６】第１の実施の形態におけるアプリケーション性
能劣化要因を判断する処理フロー図である。

【図７】第２の実施の形態におけるアプリケーション性
能劣化要因を判断する処理フロー図である。

【図８】第３の実施の形態におけるルールベースιの形
式の例を示す図である。

【図９】本発明を実現するシステムの構成例を示す図で
ある。

【符号の説明】

１０１クライアント群１０２サーバ１０３インターネット等の「サービス／ネットワーク
管理者」が制御不能なネットワーク１０４性能上のボトルネック候補であるネットワーク１０５イントラネット等の「サービス／ネットワーク
管理者」が制御可能なネットワーク１０６サーバ１０２のアクセスログ１０７ルータ１０８ルータ１０９サーバ１０２以外のサーバ群１１０クライアント群１１１サービス／ネットワーク管理が可能な領域２１０アクセス状況情報取得手段２２０ネットワーク情報収集手段２３０アプリケーション性能情報取得手段２４０トラヒック分類手段２５０分析手段２６０ルールベース参照手段２７０ルールベース登録手段２８０分析結果提示手段２９０結果表示装置

フロントページの続きＦターム(参考） 5B042 GA12 GA39 HH20 MA14 MC09 MC25 MC29 5B085 AA01 AC11 BG07 5K030 GA14 JA10 MA04 MA12 MB09 MC07 5K033 DB14 DB20 EA03 EA07 5K035 BB03 CC01 DD01 EE22 EE25 HH02

Claims

【特許請求の範囲】

【請求項１】マルチメディアネットワークにおいて，
１または複数の特定サーバが提供する特定アプリケーシ
ョンの性能劣化要因を分析する方法であって，アクセス
状況情報取得手段によって取得した前記アプリケーショ
ンに特化したアクセス状況情報αと，アプリケーション
性能情報取得手段によって取得した前記アプリケーショ
ンに対する個々のアクセスのアプリケーション性能情報
βと，サーバ・クライアント間の通信経路において，ネ
ットワーク情報収集手段によって収集した１または複数
のネットワークインタフェースの基本情報γおよびトラ
ヒック情報δとを入力し，前記アクセス状況情報αと前
記トラヒック情報δとから，前記アプリケーションのト
ラヒック情報εと，その他のマルチメディアトラヒック
情報ζとに分類した情報を求め，前記アプリケーション
性能情報β，前記トラヒック情報δ，前記アプリケーシ
ョンのトラヒック情報ε，前記その他のマルチメディア
トラヒック情報ζに関するデータ群の多変量分析によ
り，前記アプリケーション性能の劣化が，前記ネットワ
ークの伝送容量不足に起因しているか否かを判断すると
ともに，前記ネットワークの伝送容量不足に起因すると
判断した場合には，前記アプリケーショントラヒック，
その他のマルチメディアトラヒックのどちらがアプリケ
ーション性能への影響の主要因であるかを判断すること
を特徴とするアプリケーション性能劣化要因分析方法。
【請求項２】マルチメディアネットワークにおいて，
１または複数の特定サーバが提供する特定アプリケーシ
ョンの性能劣化要因を分析する方法であって，アクセス
状況情報取得手段によって取得した前記アプリケーショ
ンに特化したアクセス状況情報αと，アプリケーション
性能情報取得手段によって取得した前記アプリケーショ
ンに対する個々のアクセスのアプリケーション性能情報
βと，サーバ・クライアント間の通信経路において，ネ
ットワーク情報収集手段によって収集した１または複数
のネットワークインタフェースの基本情報γおよびトラ
ヒック情報δと，装置性能取得手段によって取得した前
記１または複数の特定サーバの装置性能に関する情報η
ｉ（ｉ＝１，２，…）と，トレンド情報取得手段によっ
て取得した時間帯区分，平日／休日分類またはその他の
日時に関連するトレンド情報θｊ（ｊ＝１，２，…）と
を入力し，前記アプリケーション性能情報β，前記トラ
ヒック情報δ，前記アプリケーションのトラヒック情報
ε，前記その他のマルチメディアトラヒック情報ζ，前
記装置性能に関する情報ηｉ，前記トレンド情報θｊに
関するデータ群の多変量分析により，前記アプリケーシ
ョン性能の劣化が，前記サーバの性能，ネットワークの
伝送容量，その他の性能のいずれがアプリケーション性
能劣化の主要因であるかを判断し，ネットワークの伝送
容量不足と判断した場合には，前記アプリケーショント
ラヒック，その他のマルチメディアトラヒックのどちら
がアプリケーション性能への影響の主要因であるかを判
断することを特徴とするアプリケーション性能劣化要因
分析方法。
【請求項３】請求項１または請求項２のいずれかに記
載のアプリケーション性能劣化要因分析方法において，
前記アプリケーション性能情報β，前記トラヒック情報
δ，前記アプリケーションのトラヒック情報ε，前記そ
の他のマルチメディアトラヒック情報ζ，またはこれら
の情報と前記装置性能に関する情報ηｉ，前記トレンド
情報θｊの平均離散時系列データ群およびそれらの加工
データ群における関係の組合せと，それに対してサーバ
管理者またはネットワーク管理者がとるべき有力な対処
方法に関する情報とを一レコードとして，複数レコード
を記録したルールベースιを有し，請求項１または請求
項２に記載の分析方法の実施結果をもとに前記ルールベ
ースιを参照し，サーバ管理者またはネットワーク管理
者に対処方法を提示することを特徴とするアプリケーシ
ョン性能劣化要因分析方法。
【請求項４】請求項３に記載のアプリケーション性能
劣化要因分析方法において，アプリケーションの性能劣
化要因の分析に用いる前記ルールベースιの構築方法と
して，前記アプリケーション性能情報β，前記トラヒッ
ク情報δ，前記アプリケーションのトラヒック情報ε，
前記その他のマルチメディアトラヒック情報ζ，または
これらの情報と前記装置性能に関する情報ηｉ，前記ト
レンド情報θｊの平均離散時系列データ群，およびそれ
らの加工データ群の相関行列を生成し，相関行列の特定
の要素または要素群が，それらに対応する特定の閾値を
超えるか否か，または特定の順序関係を満たすか否かに
より対処方法を定めることを特徴とするアプリケーショ
ン性能劣化要因分析方法。
【請求項５】マルチメディアネットワークにおいて，
１または複数の特定サーバが提供する特定アプリケーシ
ョンの性能劣化要因を分析するシステムであって，前記
アプリケーションに特化したアクセス状況情報αを取得
する手段と，前記アプリケーションに対する個々のアク
セスのアプリケーション性能情報βを取得する手段と，
サーバ・クライアント間の通信経路において，一つもし
くはそれ以上のネットワークインタフェースの基本情報
γと，トラヒック情報δを収集する手段と，前記アクセ
ス状況情報と，前記トラヒック情報とから，前記アプリ
ケーションのトラヒック情報εと，その他のマルチメデ
ィアトラヒック情報ζとに分類した情報を算出する手段
と，前記アプリケーション性能情報β，前記トラヒック
情報δ，前記アプリケーションのトラヒック情報ε，前
記その他のマルチメディアトラヒック情報ζに関するデ
ータ群の多変量分析を行う手段と，前記アプリケーショ
ン性能の劣化が，前記ネットワークの伝送容量不足に起
因しているか否かを判断するとともに，前記ネットワー
クの伝送容量不足に起因すると判断した場合には，前記
アプリケーショントラヒック，その他のマルチメディア
トラヒックのどちらがアプリケーション性能への影響の
主要因であるかを判断する手段とを備えることを特徴と
するアプリケーション性能劣化要因分析システム。
【請求項６】マルチメディアネットワークにおいて，
１または複数の特定サーバが提供する特定アプリケーシ
ョンの性能劣化要因を分析するシステムであって，前記
アプリケーションに特化したアクセス状況情報αを取得
する手段と，前記アプリケーションに対する個々のアク
セスのアプリケーション性能情報βを取得する手段と，
サーバ・クライアント間の通信経路において，一つもし
くはそれ以上のネットワークインタフェースの基本情報
γと，トラヒック情報δを収集する手段と，前記アクセ
ス状況情報と，前記トラヒック情報とから，前記アプリ
ケーションのトラヒック情報εと，その他のマルチメデ
ィアトラヒック情報ζとに分類した情報を算出する手段
と，前記１または複数の特定サーバの装置性能に関する
情報ηｉ（ｉ＝１，２，…）を取得する手段と，時間帯
区分，平日／休日分類またはその他の日時に関連するト
レンド情報θｊ（ｊ＝１，２，…）とを取得する手段
と，前記アプリケーション性能情報β，前記トラヒック
情報δ，前記アプリケーションのトラヒック情報ε，前
記その他のマルチメディアトラヒック情報ζ，前記装置
性能に関する情報ηｉ，前記トレンド情報θｊに関する
データ群の多変量分析を行う手段と，前記アプリケーシ
ョン性能の劣化が，前記サーバの性能，ネットワークの
伝送容量，その他の性能のいずれがアプリケーション性
能劣化の主要因であるかを判断し，ネットワークの伝送
容量不足と判断した際には，前記アプリケーショントラ
ヒック，その他のマルチメディアトラヒックのどちらが
アプリケーション性能への影響の主要因であるかを判断
する手段とを備えることを特徴とするアプリケーション
性能劣化要因分析システム。
【請求項７】請求項１ないし請求項４のいずれかに記
載のアプリケーション性能劣化要因分析方法を，コンピ
ュータに実行させるためのプログラムを記録したことを
特徴とするコンピュータ読み取り可能なプログラム記録
媒体。