(57)【要約】【課題】クライアントやサーバ間のメッセージ（コマンドまたはメソッド、ステータスコードを含むパケット）の応答時間から、アプリケーションのメッセージ種別や内容に対応するサービスを提供しているサーバの負荷上昇の前兆（サービスへの影響）を把握できる技術を提供する。【解決手段】ＳＩＰメッセージのメソッドやステータスコードを検索する検索手段１１３と、ＳＩＰメッセージのメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求める手段１１４と、応答時間と応答時間の平均値の差分と予め登録した閾値と比較する手段１１５と、閾値テーブル２１５を有する。【選択図】図２
2009245374.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーショントラヒックのメソッドやステータスコードを検索する検索手段と、
アプリケーショントラヒックのメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求める手段と、
応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較手段と、
前記比較手段により、サーバが過負荷を示すステータスコードを発行する前にサーバの負荷上昇の予兆を判断する判断手段と
を有することを特徴とする負荷監視分析装置。
【請求項２】
アプリケーショントラヒックのメソッドやステータスコードを検索する検索手段と、
サーバとクライアント間のメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求める手段と、
応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較手段と、
前記比較手段により、サーバが過負荷を示すステータスコードを発行する前にサーバの負荷上昇の予兆を判断する判断手段とを有し、
クライアントとサーバ間またはサーバとサーバ間のトラヒックを負荷監視分析することを特徴とする負荷監視分析装置。
【請求項３】
前記応答時間や応答時間の平均値はＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）またはアドレスまたはＵＲＩまたはアドレスのドメインごとに計算し、前記閾値は、ＵＲＩまたはアドレスまたはＵＲＩまたはアドレスのドメインごとに規定することを特徴とする請求項１または２に記載の負荷監視分析装置。
【請求項４】
前記応答時間や応答時間の平均値を求める手段は、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）のＩＮＶＩＴＥメッセージに対してプロキシー認証が必要であることを示すステータスコードの応答時間や応答時間の平均値、ＳＩＰのＩＮＶＩＴＥメッセージに対して呼の試行中であることを示すステータスコードの応答時間や応答時間の平均値を求めることを特徴とする請求項１または２に記載の負荷監視分析装置。
【請求項５】
前記応答時間や応答時間の平均値を求める手段は、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）のメッセージに対してＰｏｓｉｔｉｖｅ  Ｐｒｅｌｉｍｉｎａｒｙ  ｒｅｐｌｙ  を示すステータスコードの応答時間や応答時間の平均値を求めることを特徴とする請求項１または２に記載の負荷監視分析装置。
【請求項６】
アプリケーショントラヒックのメソッドやステータスコードを検索する検索ステップと、
アプリケーショントラヒックのメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求めるステップと、
応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較ステップと、
前記比較ステップにより、サーバが過負荷を示すステータスコードを発行する前にサーバの負荷上昇の予兆を判断する判断ステップとを備えることを特徴とする負荷監視分析方法。
【請求項７】
アプリケーショントラヒックのメソッドやステータスコードを検索する検索ステップと、
サーバとクライアント間のメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求めるステップと、
応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較ステップと、
前記比較ステップにより、サーバが過負荷を示すステータスコードを発行する前にサーバの負荷上昇の予兆を判断する判断ステップとを備え、
クライアントとサーバ間またはサーバとサーバ間のトラヒックをパッシブ計測により負荷監視分析することを特徴とする負荷監視分析方法。
【請求項８】
前記応答時間や応答時間の平均値はＵＲＩまたはアドレスまたはＵＲＩまたはアドレスのドメインごとに計算し、前記閾値は、ＵＲＩまたはアドレスまたはＵＲＩまたはアドレスのドメインごとに規定することを特徴とする請求項６または７記載の負荷監視分析方式。
【請求項９】
前記応答時間や応答時間の平均値を求めるステップは、ＳＩＰのＩＮＶＩＴＥメッセージに対してプロキシー認証が必要であることを示すステータスコードの応答時間や応答時間の平均値、ＳＩＰのＩＮＶＩＴＥに対して呼の試行中であることを示すステータスコードの応答時間や応答時間の平均値を求めることを特徴とする請求項７または８記載の負荷監視分析方法。
【請求項１０】
情報装置のプログラムであって、前記プログラムは情報処理装置を、アプリケーショントラヒックのメソッドやステータスコードを検索する検索処理と、
アプリケーショントラヒックのメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求める処理と、
応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較処理と、
前記比較処理により、サーバが過負荷を示すステータスコードを発行する前にサーバの負荷上昇の予兆を判断する判断処理として機能させることを特徴とするプログラム。
【請求項１１】
情報装置のプログラムであって、前記プログラムは情報処理装置を、
アプリケーショントラヒックのメソッドやステータスコードを検索する検索処理と、
サーバとクライアント間のメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求める処理と、
応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較処理と、
前記比較処理により、サーバが過負荷を示すステータスコードを発行する前にサーバの負荷上昇の予兆を判断する判断処理とを有し、
クライアントとサーバ間またはサーバとサーバ間のトラヒックをパッシブ計測により負荷監視分析するために機能させることを特徴とする請求項１１記載のプログラム。
【請求項１２】
情報装置のプログラムであって、前記プログラムは情報処理装置を、
前記応答時間や応答時間の平均値はＵＲＩまたはアドレスまたはＵＲＩまたはアドレスのドメインごとに計算し、前記閾値は、ＵＲＩまたはアドレスまたはＵＲＩまたはアドレスのドメインごとに規定して機能させることを特徴とする請求項１１記載のプログラム。
【請求項１３】
情報装置のプログラムであって、前記プログラムは情報処理装置を、
前記応答時間や応答時間の平均値を求める処理は、ＳＩＰのＩＮＶＩＴＥに対してプロキシー認証が必要であることを示すステータスコードの応答時間や応答時間の平均値、
ＳＩＰのＩＮＶＩＴＥメッセージに対して呼の試行中であることを示すステータスコードの応答時間や応答時間の平均値を求め機能させることを特徴とする請求項９記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、負荷監視分析方式、装置ならびにプログラムに関する。
【背景技術】
【０００２】
サーバ負荷監視の方法には以下のようなものがあるが、アプリケーションのメッセージ種別や内容に対応するサービスを提供しているサーバの負荷上昇の前兆（サービスへの影響）を知るには十分でない。
【０００３】
サーバのＣＰＵ使用率を用いればサーバ全体の負荷監視は可能であるが、ＣＰＵ使用率監視からサービスの影響まで知ることは困難である。
【０００４】
また、計測用パケット（ＨＴＴＰならＧＥＴメソッドを発行）を生成して送信し、サーバの応答時間を計測するアクティブ計測を利用した負荷監視がある。しかし、計測用パケットを生成するため、通信路の利用効率を下げる問題がある。一方、ノード間のトラヒックを監視するパッシブ計測がある。以下に例を挙げて説明する。
【０００５】
アプリケーショントラヒックの例として、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）の呼処理プロトコルの１つであるＳＩＰを挙げる。通常、呼処理にはＳＩＰサーバを利用するが、クライアントからのメッセージ（メソッド、ステータスコードを含むパケット）に対し、ＳＩＰサーバが過負荷のときは例えば５０３というステータスコードをクライアントへ応答する。この特徴に着目してトラヒックを監視すれば、ＳＩＰサーバの負荷は把握できる。しかし、過負荷を示すステータスコードを発行したときには、既にＳＩＰサーバは過負荷になった状態であり、負荷の兆候の把握は難しいものとなる。
【０００６】
ＩＴＵ−Ｔ  Ｙ．１５３０では特定のプロトコルに限定しない呼処理品質が示されており、ＶｏＩＰ推進協議会では、ＩＴＵ−Ｔ  Ｙ．１５３０をＳＩＰ等へ適用する議論が行われている。非特許文献によれば、ＳＩＰに対応した呼処理品質として、端末でのメソッドやステータスコードの受信時間や送信時間から算出する接続や切断の指標が提案されている。この指標は端末間に存在するＳＩＰサーバの処理時間やネットワーク遅延を含んだ指標である。
【０００７】
以上、ＳＩＰについて説明したが、サーバが過負荷のときには、ＨＴＴＰでは５０３、ＳＭＴＰでは４５１等の過負荷を示すステータスコードをサーバは応答する。
【０００８】
ネットワーク上のサービスを向上させるものとして、例えば特許文献１が提案されている。特許文献１は、「定期的に複数のサービスのサービスレベルを測定し、測定された各々のサービスの測定レベルと予め設定されたしきい値とを比較する。また、比較結果に基づいて測定レベルがしきい値を越えた時に当該測定レベルがしきい値を越えたサービスに対してバックアップ用サーバを割り当て、サーバを補強することにより、サービスの低下を防止する」ものであるが、例えば、「各サーバ毎にＨＴＴＰあるいはＦＴＰ等の応答時間のインターネットサービスレベルを測定」し、また、「サービスＡのサービスレベルが満たされていないとすると、サービスＡに関してサーバを補強する処理を行う」ことが示されている。
【０００９】
一方、ＳＩＰアプリケーションについての開示は特許文献２においてなされており、「ＳＩＰ  Ｓｅｒｖｌｅｔコンテナの呼び出し先を定義するコンテナ定義ファイル６１の定義ステップと、コンテナ定義ステップに基づくＳＩＰ  Ｓｅｒｖｌｅｔコンテナからの呼び出しに基づいて、ＳＩＰ要求又はＳＩＰ応答を認証する認証アクション３４と、ロケーションサーバ４へ接続して操作するロケーションサーバ操作アクション３６と、レジストラアプリケーション固有の処理を行うレジストラアクション３８とを呼び出すことにより、ログイン又はログアウトの処理を行うフレームワークであるレジストラフレームワーク４１とをコンピュータに実行させる」ことが開示されているが、ＳＩＰパケットを解釈し、ＳＩＰメソッドを抽出する方法が公開されている。
【００１０】
さらに、応答時間を計測する例は特許文献３に紹介されており、「ウェブ・サーバに接続可能なウェブ・クライアントを有するコンピュータ・ネットワークにおいて情報をログする方法を提供する。ＨＴＴＰ要求に応答して（およびその要求に対する応答の受信結果として）、その第１のＨＴＴＰ要求に関連する応答時間を計算する。その後、計算した応答時間をウェブ・クライアントからそのウェブ・サーバに後続のＨＴＴＰ要求で渡し、後で情報を使用するためにウェブ・サーバでログする。好ましい実施形態では、第１のＨＴＴＰ要求に関連する応答時間は第２のＨＴＴＰ要求のクッキーで渡される」と記載されている。
【００１１】
加えて、トラフィック分析部が加入者とサービスサーバとの通信の統計を求め、その統計から応答時間を求めることは特許文献４に紹介されており、「パケットデータトラフィックを分析し、サービスを監視し、データサービス別料金請求情報を生成し、且つプロトコル分析に基づいてネットワークを監視する移動通信網におけるパケットデータ分析装置。このパケットデータ分析装置は、加入者に対する無線データサービスを提供する移動通信交換機及びパケット制御装置のうちの１つとサービスサーバの間に配設され、前記移動通信交換機及びパケット制御装置のうちの１つとサービスサーバの間で伝送されるユーザパケットデータを分離して受信するパケットデータ分離部、前記パケットデータ分離部を通じて受信される前記ユーザパケットデータを伝送方向に応じて区分して分析するトラフィック分析部、前記トラフィック分析部が分析した結果データを記憶且つ管理する統計記憶部、及び、前記統計記憶部に記憶された各種データを検索して、使用者の所望の統計情報を提供する統計紹介部を備える」と記載されている。
【００１２】
しかしながら、サーバは過負荷時に、過負荷を示すステータスコードを発行するので、過負荷になる前に負荷上昇の前兆を把握できない、という課題がある。
【００１３】
更に、非特許文献１によると、時間測定のポイントを端末として、メソッドやステータスコードの受信時間や送信時間から呼処理遅延を算出している。この呼処理遅延のうち端末間にあるサーバそれぞれがどの程度の時間を占めているかということはわからない。つまり、各サーバが処理時間にどれくらい要したかは不明のため、各サーバの負荷上昇の前兆を把握する目的においては、呼処理遅延の利用は難しい。
【００１４】
過負荷を示すステータスコードの監視や非特許文献１が示す方法による時間監視では、アプリケーションのメッセージ種別や内容に対応するサービスを提供しているサーバの負荷上昇の前兆（サービスへの影響）を知ることは困難である。
【００１５】
特にＳＩＰにおいて、過負荷になる前に負荷上昇の前兆を把握する手法については、特許文献１乃至４には開示がなされていない。
【００１６】
【非特許文献１】ｈｔｔｐ：／／ｗｗｗ．ｔｅｌｅｓａ．ｏｒ．ｊｐ／ｃｏｍｍｉｔｔｅｅ／ｖｏｉｐ／ｐｄｆ／０５０７＿ＩＰＣａｌｌ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒ１．ｐｄｆ
【特許文献１】特開２００２−３４２２９６号公報
【特許文献２】特開２００７−１５６９７１号公報
【特許文献３】特開平１１−１１０３１２号公報
【特許文献４】特表２００６−５０６８４２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１７】
従って、本発明が解決しようとする目的は、クライアントやサーバ間のメッセージ（コマンドまたはメソッド、ステータスコードを含むパケット）の応答時間から、アプリケーションのメッセージ種別や内容に対応するサービスを提供しているサーバの負荷上昇の前兆（サービスへの影響）を把握できる技術を提供することである。
【００１８】
本技術を利用することで得られるメリットについてＳＩＰを例に説明する。メッセージのＳＩＰ−ＵＲＩ参照で判明する災害時の優先電話（優先呼）や緊急通報（緊急呼）が、負荷上昇の兆候があるサーバに接続していることが分かるので、例えば呼を迂回させ不通を事前回避させる対処を実施することができる。また、メッセージのＳＩＰ−ＵＲＩを参照すると負荷上昇の兆候があるサーバを選別できるため、サーバがダウンする前にサーバの増強や呼規制の対処を期待できる。以下、実施例ではＳＩＰを例に説明する。
【課題を解決するための手段】
【００１９】
上記課題を解決するための第１の発明は、ＳＩＰメッセージのメソッドやステータスコードを検索する検索手段１１３と、ＳＩＰメッセージのメソッド受信時刻、ステータスコード受信時刻から応答時間を求める手段と、応答時間の平均値を求める手段と、応答時間や応答時間の平均値の差分と予め登録した閾値と比較する比較手段と、比較手段により、ＳＩＰサーバが過負荷を示すステータスコードを発行する前にＳＩＰサーバの負荷上昇の予兆を判断する判断手段とを有することを特徴とする。
【００２０】
上記課題を解決するための第２の発明は、ＳＩＰメッセージのメソッドやステータスコードを検索する検索ステップと、ＳＩＰメッセージのメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求めるステップと、応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較ステップと、比較ステップにより、ＳＩＰサーバが過負荷を示すステータスコードを発行する前にＳＩＰサーバの負荷上昇の予兆を判断する判断ステップとを有することを特徴とする。
【００２１】
上記課題を解決するための第３の発明は、情報装置のプログラムであって、プログラムは情報処理装置を、ＳＩＰメッセージのメソッドやステータスコードを検索する検索処理と、ＳＩＰメッセージのメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求める処理と、応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較処理と、比較処理により、ＳＩＰサーバが過負荷を示すステータスコードを発行する前にＳＩＰサーバの負荷上昇の予兆を判断する判断処理として機能させることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、クライアントやサーバ間のメッセージ（コマンドまたはメソッド、ステータスコードを含むパケット）の応答時間から、アプリケーションのメッセージ種別や内容に対応するサービスを提供しているサーバの負荷上昇の前兆（サービスへの影響）を把握できる。
【００２３】
その理由は、例えばＳＩＰの場合では、本発明の負荷監視分析装置がＳＩＰメッセージのメソッド（ＩＮＶＩＴＥ）に対してプロキシー認証が必要であることを示すステータスコードや、ＩＮＶＩＴＥに対して呼の試行中であることを示すステータスコードを検索する検索手段と、ＳＩＰメッセージのメソッド受信時刻、ステータスコード受信時刻から応答時間や応答時間の平均値を求める手段と、応答時間と応答時間の平均値の差分と予め登録した閾値と比較する比較手段と、この比較手段による閾値を越えたか否かの確認により、ＳＩＰサーバが過負荷を示すステータスコードを発行する前にＳＩＰサーバの負荷上昇の予兆を判断する判断手段を備えているからである。
【００２４】
クライアントとサーバ間やサーバとサーバ間のトラヒック監視により応答時間を計測し、応答時間からアプリケーションのメッセージ種別や内容に対応するサービスを提供しているサーバの負荷上昇の前兆（サービスへの影響）を知ることができる。
【００２５】
更に、クライアントとサーバのトラヒックをサーバに近い箇所でモニタすることで、ネットワーク遅延の影響を軽減し、サーバの負荷上昇の前兆をより正確に把握できる。
【発明を実施するための最良の形態】
【００２６】
以下本発明の実施の形態について複数の実施例を用いて以下に説明する。
【００２７】
なお、本発明は、上記の実施の形態に限定されず、本発明の技術思想の範囲内において、実施の形態が適宜変更され得るものである。
【実施例１】
【００２８】
まず本発明の構成について説明する。本発明の第１の実施例について、図１、図１０の第１の実施例を示す図を用いて説明する。図１は、本実施例における負荷監視分析方式を用いた通信システムの一例を示す図である。クライアント６１、６２、サーバ６３、６４は負荷監視分析装置７１、７２とネットワークで接続されている。負荷監視分析装置７１、７２はクライアント６１、６２、サーバ６３、６４のＳＩＰパケットを負荷監視分析する。以下、負荷監視分析装置７１を例に説明する。負荷監視分析装置７１と７２は同じ構成である。
【００２９】
図１０は、ＲＦＣ３６６５（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３６６５．ｔｘｔ）で示されているコールフローを例に、負荷監視分析装置の配置を示したものである。負荷監視分析装置は、図９の負荷監視分析箇所５０１、５０２、５０３のトラヒックをミラーリング監視サーバ等で負荷監視分析する。ここでは、図１０のクライアント６１が発話者、クライアント６２が着呼者であることを想定し、負荷監視分析箇所５０１、５０２のトラヒックを負荷監視分析装置が監視する場合を示す。なお、図９のクライアント６１が着呼者、クライアント６２が発話者の場合は、負荷監視分析箇所５０３、５０２のトラヒックを負荷監視分析装置は監視する。図１０中のＭ１からＭ８は説明のためにメッセージに付けた番号である。
【００３０】
図２は、本発明における第１の実施例を示すブロック図である。本発明における第１の実施例による負荷監視分析方式は、Ｌ２（ＯＳＩ参照モデルのレイヤー２：データリンク層）、Ｌ３（ＯＳＩ参照モデルのレイヤー３：ネットワーク層）、Ｌ４（ＯＳＩ参照モデルのレイヤー４：トランスポート層）終端処理部１１０、プロトコル識別部１１１、ＳＩＰセッション管理部１１２、コマンド、ステータスコード抽出部１１３、応答時間算出部１１４、判定部１１５、ＳＩＰセッション管理テーブル２１０、サーバリスト２１１、コマンド、ステータスコードテーブル２１２、応答時間テーブル２１３、基準時間テーブル２１４、閾値テーブル２１５、から構成される。
【００３１】
Ｌ２、Ｌ３、Ｌ４終端処理部１１０は、Ｌ２、Ｌ３、Ｌ４の終端処理を行う。ＳＩＰは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）、ＳＣＴＰ（Ｓｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ、ＲＦＣ２９６０）を利用できるため、ＴＣＰやＳＣＴＰパケットが入力された場合はストリーム再構築を行う。
【００３２】
プロトコル識別部１１１は、ＳＩＰパケットであるかをポート番号（５０６０）により識別して、ＳＩＰパケットのみを後段処理にわたす。ＳＩＰ以外のパケットの場合は廃棄する。ここで、図３に本発明に係る負荷監視分析装置７１、７２について、その構成を示す。負荷監視分析装置７１、７２の内部にはＣＰＵ２１８が設けられ、検索部１１３、終端処理部１１０、応答時間算出部１１４、プロトコル識別部１１１、判定部１１５と、ＳＩＰセッション管理部１１２はプログラム領域に格納される。
【００３３】
ＳＩＰセッション管理部１１２は、負荷監視分析装置７１に入力されたＳＩＰセッションを管理する。サーバリスト２１１と比較して、クライアントがサーバに宛てたメッセージ、またはサーバがクライアントに宛てたメッセージのみを後段処理に渡す。サーバリストとは、負荷監視分析装置７１が負荷監視分析対象とするサーバのＩＰアドレスのリストであり、図４に例を示す。
【００３４】
検索部１１３は、メソッド、ステータスコードリスト２１２に示されているメソッドとステータスコードが、ＳＩＰパケットのヘッダフィールドに含まれているかを確認するため検索し、一致したら応答時間算出部１１４へ渡す。不一致の場合は何もしない。メソッド、ステータスコードリスト２１２の例を図４に示す。ＩＮＶＩＴＥに対してプロキシー認証が必要であることを示すステータスコードや、ＩＮＶＩＴＥに対して呼の試行中であることを示すステータスコードを確認する。
【００３５】
図１０はクライアント６１とサーバ６３との間でのみ認証を実施するコールフローである。図１０で、負荷監視分析箇所が５０１の場合、負荷監視分析装置７１は、ＩＮＶＩＴＥ（Ｍ１）とそれに対応するステータスコードの４０７（Ｍ７）、またはＩＮＶＩＴＥ（Ｍ４）と対応するステータスコードの１００（Ｍ６）を処理対象とする。負荷監視分析箇所が図１０の５０２の場合、負荷監視分析装置７２は、ＩＮＶＩＴＥ（Ｍ５）と対応するステータスコードの１００（Ｍ８）を処理対象とする。
【００３６】
図１２に、クライアント６１がサーバ６３だけでなくサーバ６４とも認証を実施するコールフロー（ＲＦＣ３６６５）を示す．負荷監視分析装置７１は、ＩＮＶＩＴＥ（Ｍ１）と対応するステータスコードの４０７（Ｍ２）、ＩＮＶＩＴＥ（Ｍ４）と対応するステータスコードの１００（Ｍ５）、ＩＮＶＩＴＥ（Ｍ４）と対応するステータスコードの４０７（Ｍ９）、ＩＮＶＩＴＥ（Ｍ１１）と対応するステータスコード１００（Ｍ１２）を処理対象とする。
【００３７】
同様に負荷監視分析装置７２は、ＩＮＶＩＴＥ（Ｍ６）と対応するステータスコードの４０７（Ｍ７）、ＩＮＶＩＴＥ（Ｍ１３）と対応するステータスコードの１００（Ｍ１４）を処理対象とする。
【００３８】
応答時間算出部１１４は、ＳＩＰパケットのヘッダフィールドに含まれるＣａｌｌ−ＩＤ、ＣＳｅｑを参照し、対応するメソッドとステータスコードのそれぞれの受信時刻から、応答時間（時間差）を算出する。メソッドの受信時刻、ステータスコードの受信時刻は、負荷監視分析装置７１がパケットを受信した時刻である。メソッドの受信時刻やステータスコードの受信時刻、応答時間は、図６、図７に示すように応答時間テーブル２１３、基準時間テーブル２１４に登録する。
【００３９】
基準時間テーブルは、負荷上昇の前兆と判断するための基準値である。基準時間テーブル２１４に登録される時間は、例えばＳＩＰ−ＵＲＩのドメイン毎の応答時間の平均値やＳＩＰ−ＵＲＩ毎の応答時間の平均値が登録されている。図７は、ＳＩＰ−ＵＲＩのドメイン毎の平均応答時間を示した例である。
【００４０】
ＳＩＰ−ＵＲＩ単位またはＳＩＰ−ＵＲＩのドメイン単位で処理する理由を説明する。本発明の目的は、サーバの負荷上昇の前兆を検知することである。ＳＩＰ−ＵＲＩが同一あるいは、ＳＩＰ−ＵＲＩのドメインが同一のメッセージは、同じサーバで処理されると考えることができる。例えば、１）ｕｓｅｒ＠ｓｅｒｖｅｒ．ｃｏｍ、２）ｃｌｉｅｎｔ＠ｓｅｒｖｅｒ．ｃｏｍ、３）ｕｓｅｒ＠ｅｘａｍｐｌｅ．ｃｏｍというＳＩＰ−ＵＲＩを考える。１）と２）は同じサーバで処理され、３）を処理するサーバは、１）と２）を処理するサーバとは異なると考えられる。以上より、ＳＩＰ−ＵＲＩ単位またはＳＩＰ−ＵＲＩのドメイン単位で応答時間の評価を行う。
【００４１】
判定部１１５は、サーバ負荷上昇の前兆を応答時間から判定する。応答時間と基準時間テーブル２１４の値の差分が、閾値テーブル２１５の閾値より大きいときに、サーバ負荷上昇の前兆があると判断する。
【００４２】
続いて動作について説明する。次に、図９の負荷監視分析方式の処理を示すフローチャートと、図１０のＲＦＣ３６６５で示されているコールフローを例に、本発明である負荷監視分析装置７１、７２の処理の動作について説明する。
【００４３】
以下、負荷監視分析装置７１の処理の動作を示す。負荷監視分析装置７２は、負荷監視分析装置７１と処理対象とするパケットが異なるため、一部だけ動作が異なる．負荷監視分析装置７１はクライアントとサーバ間のメッセージを、負荷監視分析装置７２はサーバとサーバ間のメッセージを処理対象とする。
【００４４】
ネットワーク上を流れるパケットを負荷監視分析装置７１が受信すると、Ｌ２、Ｌ３、Ｌ４終端処理部１１０は、終端処理を行う（ステップＳ１）。ＴＣＰやＳＣＴＰパケットの場合はストリーム再構築を行う。
【００４５】
次にＳＩＰパケットのみを処理対象とするため、プロトコル識別部１１１はポート番号が５０６０であるパケットのみを後段の処理に渡す。５０６０以外のパケットはここで廃棄する（ステップＳ２）。
【００４６】
ＳＩＰパケットを受け取ったＳＩＰセッション管理部１１２は、ＳＩＰパケットのＩＰヘッダの送信元ＩＰ、送信先ＩＰ、ＳＩＰ−ＵＲＩ等を参照し、ＳＩＰセッション管理テーブル２１０を用いて、セッション管理を行う（ステップＳ３）。また、このとき、図４のようなサーバリスト２１１を参照して、送信元ＩＰまたは送信先ＩＰがサーバリストのＩＰと一致したパケットのみを後段処理に渡す。
【００４７】
負荷監視分析装置７１は、サーバ間のトラヒックを監視するため、送信元ＩＰと送信先ＩＰの両方ともサーバリストのＩＰと一致したパケットのみを後段処理に渡す。
【００４８】
パケットを受け取った検索部１１３は、メソッド、ステータスコードリスト２１２に登録されているメソッド、ステータスコードが、ＳＩＰパケットのヘッダフィールドに含まれていないかを確認するため検索を行う（ステップＳ４）。ＩＮＶＩＴＥに対してプロキシー認証が必要であることを示すステータスコードや、ＩＮＶＩＴＥに対して呼の試行中であることを示すステータスコードを確認する。
【００４９】
負荷監視分析箇所が図１０の５０１の場合、負荷監視分析装置７１は、ＩＮＶＩＴＥ（Ｍ１）と対応するステータスコードの４０７（Ｍ２）、ＩＮＶＩＴＥ（Ｍ４）と対応するステータスコード１００（Ｍ６）を処理対象とする。負荷監視分析箇所が図１０の５０２の場合、負荷監視分析装置７２は、ＩＮＶＩＴＥ（Ｍ５）と対応するステータスコードの１００（Ｍ８）を処理対象とする。
【００５０】
図１２に、クライアント６１がサーバ６３だけでなくサーバ６４とも認証を実施するコールフロー（ＲＦＣ３６６５）を示す。負荷監視分析箇所が図１２の５０１の場合、負荷監視分析装置７１は、ＩＮＶＩＴＥ（Ｍ１）や対応するステータスコードの４０７（Ｍ７）、ＩＮＶＩＴＥ（Ｍ４）と対応するステータスコードの１００（Ｍ５）、ＩＮＶＩＴＥ（Ｍ４）と対応するステータスコード４０７（Ｍ９）、ＩＮＶＩＴＥ（Ｍ１１）と対応するステータスコード１００（Ｍ１２）を処理対象とする。
【００５１】
監視箇所が図１２の５０２の場合、ＩＮＶＩＴＥ（Ｍ６）と対応するステータスコード４０７（Ｍ７）、ＩＮＶＩＴＥ（Ｍ１３）と対応するステータスコード１００（Ｍ１４）を処理対象とする。
【００５２】
続いて応答時間算出部１１４は、応答時間テーブル２１３にメソッドとステータスコードを登録しメソッドとステータスコードがそろったら応答時間を算出する（ステップＳ５、Ｓ６）。受信パケットにメソッドを含む場合はＣａｌｌ−ＩＤ、ＣＳｅｑ、受信時刻を、ステータスコードを含む場合は受信時刻を対応する行（メソッド）に登録する。ＳＩＰパケットのヘッダフィールドに含まれるＣａｌｌ−ＩＤ、ＣＳｅｑを参照してメソッドとステータスコードの対応をとる。ＨＴＴＰやＳＭＴＰはテキストデータ（コンテンツ）の転送を目的にしているのに対し、ＳＩＰはセッション管理を主眼においている。そのため、ＳＩＰメッセージのメソッドとそれに対するステータスコードの受信時間に基づいた応答時間計測を実現するために、ＳＩＰメッセージに含まれるＣａｌｌ−ＩＤ、ＣＳｅｑを用いてセッション中のメソッドとステータスコードの対応づけを行う。
【００５３】
図６を例に説明する。図６は、ＩＮＶＩＴＥとそれに対応する１００の応答時間を計測する場合の応答時間テーブル２１３である。例えば、ｕｓｅｒ１＠ｓｅｒｖｅｒ１．ｃｏｍという発話者のＩＮＶＩＴＥ（Ｃａｌｌ−ＩＤ：１２３４５６７８＠ｓｅｖｅｒ１．ｃｏｍ）を観測し、発話者と着呼者のＳＩＰ−ＵＲＩ、Ｃａｌｌ−ＩＤ、ＣＳｅｑ、ＩＮＶＩＴＥ受信時刻をテーブルに記録したとする。次に、ステータスコード１００を観測した場合は、ステータスコードのＣａｌｌ−ＩＤとＣＳｅｑを確認する。Ｃａｌｌ−ＩＤが１２３４５６７８＠ｓｅｖｅｒ１．ｃｏｍ、ＣＳｅｑが１  ＩＮＶＩＴＥであることから、ｕｓｅｒ１＠ｓｅｒｖｅｒ１．ｃｏｍのＩＮＶＩＴＥに対応するステータスコードであるのでステータスコード１００の受信時刻をテーブルのｕｓｅｒ１＠ｓｅｒｖｅｒ１．ｃｏｍの行に記録する。ＩＮＶＩＴＥの受信時刻とＩＮＶＩＴＥに対応する１００受信時刻の差分が２２［ｍｓ］であるから、応答時間は２２［ｍｓ］となる。また、図６の応答時間テーブル２１３のＳＩＰ−ＵＲＩを参照すれば、該当呼が優先呼や緊急呼であるかどうかがわかる。
【００５４】
最後の判定部１１５は、（応答時間算出部１１４で得た応答時間）−（基準時間テーブル２１４が示す値）＞（閾値テーブル２１５が示す値）であるかを確認する。
【００５５】
閾値テーブル２１５は、ＳＩＰ−ＵＲＩ毎または、ＳＩＰ−ＵＲＩのドメイン毎に閾値を保持している．図７はドメイン毎のＩＮＶＩＴＥと４０７の平均応答時間を、図８はＳＩＰ−ＵＲＩのドメイン毎の閾値を示している．平均応答時間を得るための処理内容は後述する。
【００５６】
例えば、ｕｓｅｒ１＠ｓｅｒｖｅｒ１．ｃｏｍのＩＮＶＩＴＥに対する４０７の応答時間が２２［ｍｓ］の場合、図７よりｓｅｒｖｅｒ１．ｃｏｍの平均応答時間は２０［ｍｓ］、図８のドメインｓｅｒｖｅｒ１．ｃｏｍの閾値は５０［ｍｓ］であるから、２２［ｍｓ］−２０［ｍｓ］＝２［ｍｓ］＜５０［ｍｓ］となり、閾値よりも小さいため、サーバ負荷上昇の前兆はないと判定する。閾値よりも大きい場合は、サーバ負荷上昇の前兆があると判定する（ステップＳ７、Ｓ８）。
【００５７】
ＳＩＰ−ＵＲＩ単位またはＳＩＰ−ＵＲＩのドメイン単位で処理する理由を説明する。本発明の目的は、サーバの負荷上昇の前兆を検知することである。ＳＩＰ−ＵＲＩが同一あるいは、ＳＩＰ−ＵＲＩのドメインが同一のメッセージは、同じサーバで処理されると考えることができる。例えば、１）ｕｓｅｒ＠ｓｅｒｖｅｒ．ｃｏｍ、２）ｃｌｉｅｎｔ＠ｓｅｒｖｅｒ．ｃｏｍ、３）ｕｓｅｒ＠ｅｘａｍｐｌｅ．ｃｏｍというＳＩＰ−ＵＲＩを考える。１）と２）は同じサーバで処理され、３）を処理するサーバは、１）と２）を処理するサーバとは異なると考えられる。以上より、ＳＩＰ−ＵＲＩ単位またはＳＩＰ−ＵＲＩのドメイン単位で応答時間の評価を行う。
【００５８】
図１０のように、クライアントとサーバ間やサーバとサーバ間のトラヒックをモニタし、ＩＰアドレスと計測した応答時間を参照することで、各サーバが処理時間にどれくらい要したかがわかる。図１０ではクライアント６１が発話者、クライアント６２が着呼者である様子を示しているので、負荷監視分析装置７１はサーバ６３の処理時間を、負荷監視分析装置７２はサーバ６４の処理時間を知ることが出来る。
【００５９】
また、負荷監視分析装置７１はＦｒｏｍのＳＩＰ−ＵＲＩを参照することで、どのクライアントのメッセージが、サーバ６３の処理時間の影響をうけているかを把握することができ、同様に負荷監視分析装置７２もＦｒｏｍを参照することで、どのクライアントのメッセージが、サーバ６４の処理時間の影響を受けているか把握できる。
【００６０】
なお、図１０では、負荷監視分析箇所５０１、５０２に負荷監視分析装置を設置して、トラヒックをモニタしている。図１２のようにプローブ装置を負荷監視分析箇所５０１、５０２に設置し、プローブ装置と負荷監視分析装置を接続した形態でも良い。プローブ装置はモニタしたトラヒックを負荷監視分析装置に渡すことで、図１０と等価な処理が可能である。
【００６１】
次に図１１を用いて、平均応答時間を得るための処理内容を説明する．図１１のステップＳ１からステップＳ６までは、図８のステップＳ１からステップＳ６と同じである。図６のように応答時間を登録していくが、平均応答時間の得たいドメインをもつ着呼者の数が、ネットワーク管理者が予め設定した数に達したら（ステップＳ５１）、ドメインの応答時間の平均値を計算し、平均応答時間とする（ステップＳ５２）。
【００６２】
平均応答時間の取得は、図９の通常処理と併行して行っても良い。また、図９の通常処理は実行せず、図１１のみを実行しても良い。
【実施例２】
【００６３】
続いて、図１４〜図１８に、本発明に係る実施例２における負荷監視分析方式をＳＭＴＰプロトコルサーバに適用した例を示す。実施例２では、図１４にクライアント７０２、７０４、サーバ７０６、７０８は負荷監視分析装置７１０、７１２とネットワークで接続されている。負荷監視分析装置７１０、７１２はクライアント７０２、７０４、サーバ７０６、７０８のＳＭＴＰパケットを負荷監視分析する。以下、負荷監視分析装置７１０を例に説明する。負荷監視分析装置７１０と７１２は同じ構成である。
【００６４】
図１５は、本発明における第３の実施例を示すフローチャートである。本発明に係る第３の実施例による負荷監視分析システムは、Ｌ２、Ｌ３、Ｌ４終端処理部１１０、プロトコル識別部１１１、ＳＭＴＰセッション管理部７２４、コマンド、ステータスコード抽出部１１３、応答時間算出部１１４、判定部１１５、ＳＭＴＰセッション管理テーブル７２８、サーバリスト２１１、コマンド、ステータスコードテーブル２１２、応答時間テーブル２１３、基準時間テーブル２１４、閾値テーブル２１５、から構成される。本発明に係る第１の実施例の図３と同名のブロックは同一の機能を有するブロックである。
【００６５】
特に実施例１と異なる機能について説明する。プロトコル識別部１１１は、ＳＭＴＰパケットであるかどうかをポート番号（２５）により識別して、ＳＭＴＰパケットのみを後段処理に渡す。
【００６６】
ＳＭＴＰセッション管理部７２４は、負荷監視分析装置７１０に入力されたＳＭＴＰセッションを管理する。サーバリスト２１１と比較して、クライアントがサーバに宛てたメッセージ、またはサーバがクライアントに宛てたメッセージのみを後段処理に渡す。
【００６７】
検索部１１３は、コマンド、リプライコードリスト２１２に示されているコマンドとリプライコードが、ＳＭＴＰパケットのヘッダフィールドに含まれているかを確認するため検索し、一致したら応答時間算出部１１４へ渡す。不一致の場合は何もしない。コマンド、リプライコードリスト２１２の一例を図１８に示す。コマンドに対するＰｏｓｉｔｉｖｅ  Ｐｒｅｌｉｍｉｎａｒｙ  ｒｅｐｌｙを確認する。
【００６８】
続いて動作について説明する。図１６の負荷監視分析方式の処理を示すフローチャートにより、本発明である負荷監視分析装置７２０の処理の動作について説明する。各工程は、ステップＳＣ３を除き、実施例１と同一である。特に、実施例１と異なるステップＳＣ３について説明する。
【００６９】
次にＳＭＴＰパケットのみを処理対象とするため、プロトコル識別部１１１はポート番号が２５であるパケットのみを後段の処理に渡す。２５以外のパケットはここで廃棄する（ステップＳＢ２）。
【００７０】
ＳＭＴＰパケットを受け取ったＳＭＴＰセッション管理部７２４は、ＳＭＴＰパケットのＩＰヘッダの送信元ＩＰ、送信先ＩＰ、Ｆｒｏｍ、Ｔｏ等を参照し、ＳＭＴＰセッション管理テーブル７２８を用いて、セッション管理を行う（ステップＳＢ３）。
【００７１】
最後の判定部１１５は、（応答時間算出部１１４で得た応答時間）−（基準時間テーブル２１４が示す値）＞（閾値テーブル２１５が示す値）であるかを確認する。閾値テーブル２１５は、メールアドレスごとまたは、メールアドレスのドメイン毎に閾値を保持している．
【図面の簡単な説明】
【００７２】
【図１】本実施例におけるＳＩＰ負荷監視分析装置を用いた通信システムの一例を示す図である。
【図２】本発明における第１の実施例の構成を示すブロック図である。
【図３】本発明における第１の実施例の構成を示すブロック図である。
【図４】本発明における第１の実施例のサーバリストの例を示す図である。
【図５】本発明における第１の実施例のメソッド、ステータスコードリストの例を示す図である。
【図６】本発明における第１の実施例の応答時間テーブルの例を示す図である。
【図７】本発明における第１の実施例の基準時間テーブルの例を示す図である。
【図８】本発明における第１の実施例の閾値テーブルの例を示す図である。
【図９】本発明における第１の実施例の処理フローを示す図である。
【図１０】本発明における第１の実施例を示すフロー図である。
【図１１】本発明における第１の実施例の基準データ生成の処理フローを示す図である。
【図１２】本発明における第１の実施例を示すフロー図である。
【図１３】本実施例における第２の実施例のＳＭＴＰ負荷監視分析装置を用いた通信システムの一例を示す図である。
【図１４】本発明における第２の実施例の構成を示すブロック図である。
【図１５】本発明における第２の実施例を示すフロー図である。
【図１６】本発明における第２の実施例の閾値テーブルの例を示す図である。
【符号の説明】
【００７３】
６１、６２  クライアント
６３、６４  サーバ
７１、７２、７３  負荷監視分析装置
１１０  Ｌ２、Ｌ３、Ｌ４終端処理部
１１１  プロトコル識別部
１１２  ＳＩＰセッション管理部
１１３  検索部
１１４  応答時間算出部
１１５  判定部
２１０  ＳＩＰセッション管理テーブル
２１１  サーバリスト
２１２  メソッド、ステータスコードテーブル
２１３  応答時間テーブル
２１４  基準時間テーブル
２１５  閾値テーブル
５０１、５０２、５０３  負荷監視分析箇所
７０２、７０４  クライアント
７０６、７０８  サーバ
７１０、７１２  負荷監視分析装置
７２４  ＳＭＴＰセッション管理部
７２８  ＳＭＴＰセッション管理テーブル
【図１】
2009245374.tif 000003
【図２】
2009245374.tif 000004
【図３】
2009245374.tif 000005
【図４】
2009245374.tif 000006
【図５】
2009245374.tif 000007
【図６】
2009245374.tif 000008
【図７】
2009245374.tif 000009
【図８】
2009245374.tif 000010
【図９】
2009245374.tif 000011
【図１０】
2009245374.tif 000012
【図１１】
2009245374.tif 000013
【図１２】
2009245374.tif 000014
【図１３】
2009245374.tif 000015
【図１４】
2009245374.tif 000016
【図１５】
2009245374.tif 000017
【図１６】
2009245374.tif 000018