JP2016144153A - サービス監視装置、および、サービス監視方法 - Google Patents

Abstract

【課題】複数のサービスが提供されているネットワークに対して、提供中のサービスの監視を行うことができるようにする。
【解決手段】複数のネットワーク装置２から収集したフローデータを用いて、サービスを監視するサービス監視装置１であって、収集したフローデータから、サービスに対する、要求トラフィックおよび応答トラフィックを抽出するトラフィック抽出部１１と、抽出された、要求トラフィックおよび応答トラフィックに基づいて、要求トラフィックおよび応答トラフィックとの間の定常性を算出する定常性算出部１２と、特定期間内での要求トラフィックおよび応答トラフィックとの間の関係性が、算出された定常性からどれだけ逸脱しているかによって、サービスの品質を判定するサービス品質判定部１３と、を備える、ことを特徴とする。
【選択図】図２

Description

本発明は、ネットワーク上で提供されているサービスを監視する技術に関する。

ネットワークの運用管理において、現在提供中のサービスを監視することが非常に重要であり、ネットワーク上の異常を検出するさまざまな異常検出方法が従来から知られている（例えば、特許文献１，２参照）。従来技術によれば、異常な挙動を示すネットワーク装置を特定することができる（装置監視）。

従来のサービスは、例えば、音声通話サービスのように、１つのネットワーク上に１つのサービスが提供される形態をとっていたので、ネットワーク装置の死活状態や異常状態がサービスと１対１に対応していた。このため、従来技術であっても、サービスの監視を適切に行うことができた。

しかし、近年のＩＰ（Internet Protocol）ネットワークに関しては、１つのネットワーク上に複数のサービスが提供される形態が一般化しているので、従来技術の装置監視では、提供される複数のサービスを監視することは困難である。現状では、図８に示すように、ＤＮＳサーバ３ａ（３）、Ｗｅｂサーバ３ｂ（３）、ＤＢサーバ３ｃ（３）などのサービスを提供するサーバ３に対する１ｃａｌｌ試験やポートの死活監視などにより、オペレータが操作するＨＭＩ（Human Machine Interface）装置５にてサービス監視を行っている。

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

しかし、図８に示すように、複数のサービスが提供されているネットワークに対して、１ｃａｌｌ試験などの従来のサービス監視は、ネットワーク装置群Ｇの一部しか対象にしない限定的なものとなってしまう（符号Ｚで示される矢印参照）。特定のネットワーク装置２がＤｏＳ攻撃（Denial of Service attack）などに晒されているために提供中のサービス（符号Ｘで示される矢印参照）を一部のユーザ（端末４）が利用できないこと、特定のネットワーク装置２が輻輳しているため提供中のサービス（符号Ｙで示される矢印）の品質が一部のユーザ（端末４）に対して低下していること、などに対しては、１コール試験などの従来のサービス監視が及ばない。

このような背景を鑑みて本発明がなされたのであり、本発明は、複数のサービスが提供されているネットワークに対して、提供中のサービスの監視を行うことができるようにすることを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、複数のネットワーク装置から収集したフローデータを用いて、サービスを監視するサービス監視装置であって、前記収集したフローデータから、前記サービスに対する、要求トラフィックおよび応答トラフィックを抽出する抽出部と、前記抽出された、要求トラフィックおよび応答トラフィックに基づいて、前記要求トラフィックおよび前記応答トラフィックとの間の定常性を算出する定常性算出部と、特定期間内での前記要求トラフィックおよび前記応答トラフィックとの間の関係性が、前記算出された定常性からどれだけ逸脱しているかによって、前記サービスの品質を判定する判定部と、を備える、ことを特徴とする。

また、請求項２に記載の発明は、複数のネットワーク装置から収集したフローデータを用いて、サービスを監視するサービス監視装置におけるサービス監視方法であって、前記収集したフローデータから、前記サービスに対する、要求トラフィックおよび応答トラフィックを抽出する抽出ステップと、前記抽出された、要求トラフィックおよび応答トラフィックに基づいて、前記要求トラフィックおよび前記応答トラフィックとの間の定常性を算出する定常性算出ステップと、特定期間内での前記要求トラフィックおよび前記応答トラフィックとの間の関係性が、前記算出された定常性からどれだけ逸脱しているかによって、前記サービスの品質を判定する判定ステップと、を備える、ことを特徴とする。

請求項１，２に記載の発明によれば、ネットワークデータから収集したフローデータを用いることで、提供中である複数のサービスを特定するとともに、特定したサービスに対して、要求トラフィックと応答トラフィックとの間の定常性を見つけ出すことができる。このため、サービス品質を定常性からの逸脱度合いとして定量的に評価することができる。その結果、複数のサービスが提供されているネットワークに対して、提供中のサービスの監視を行うことができるようにすることができる。

本発明によれば、複数のサービスが提供されているネットワークに対して、提供中のサービスの監視を行うことができるようにすることができる。

ネットワークの全体構成図である。 本実施形態のサービス監視装置の機能構成図である。 本実施形態のサービス監視装置の処理を示すフローチャートである。 実施例１の説明図である。 実施例２の説明図である。 実施例３の説明図である。 サービス監視用のプログラムを実行するコンピュータを示す図である。 従来のサービス監視を説明する図である。

＜構成＞
図１に示すように、本実施形態のサービス監視装置１は、ネットワーク装置群Ｇのネットワーク装置２の各々からフローデータを収集し、収集したフローデータを用いて、サーバ３から端末４へ提供中のサービス（図１中の符号Ｘ，Ｙを付した矢印で表現）を監視する。フローデータの収集方法は、NetFlow,sFlowなどといった周知の方法である（例えば、参考文献１：B. Claise, "Cisco Systems NetFlow Services Export Version9," IETF RFC3954, October 2004. http://www.ietf.org/rfc/rfc3954や、参考文献２：P. Phaal, S. Panchen, and N. McKee, "InMon Corporation's sFlow:A Method for Monitoring Traffic in Switched and Routed Networks," IETF RFC3176, September 2001. http://www.ietf.org/rfc/rfc3176、などを参照）。

フローデータは、送信元ＩＰアドレス、宛先ＩＰアドレス（または、送信先ＩＰアドレス）、送信元ポート番号、宛先ポート番号（または、送信先ポート番号）、プロトコルの種類、パケット数、バイト数などの情報を一部または全部含む。フローデータの収集は、所定の時間単位で行われ、収集時刻をフローデータに含めることもできる。なお、フローデータの送信元ポート番号または宛先ポート番号を特定することで、サービス品質を判定したい提供中のサービスを特定することができる。

本実施形態のサービス監視装置１は、例えば、ＩＰＦＩＸ（Internet Protocol Flow Information Export）のフローコレクタとして機能し、ネットワーク装置２の各々からフローデータを収集することができる。
ネットワーク装置２は、例えば、ルータ、ブリッジ、リピータ、ゲートウェイである。ネットワーク装置２は、例えば、ＩＰＦＩＸのフローエクスポータとして機能する。なお、ネットワーク装置群Ｇにおいて、フローエクスポータとして機能しないネットワーク装置２が含まれていてもよい。このようなネットワーク装置２でのトラフィック状態は、フローエクスポータとして機能するネットワーク装置２が提供するフローデータを周知の方法で解析することで間接的に特定することができる。

サーバ３は、例えば、ＤＮＳサーバ３ａ、Ｗｅｂサーバ３ｂ、ＤＢサーバ３ｃであり、端末４に所定のサービスを提供する。なお、サーバ３にフローエクスポータの機能を持たせてもよい。
端末４は、ユーザがサービスを利用するために操作する装置である。なお、端末４にフローエクスポータの機能を持たせてもよい。
ＨＭＩ装置５は、オペレータがサービス監視装置１を制御するための管理コンソールである。サービス監視装置１は、ネットワーク装置２から収集したフローデータに基づいて必要に応じてサービス警報などをＨＭＩ装置５に出力する。

図２に示すように、本実施形態のサービス監視装置１は、処理部１０、入出力部２０、および記憶部３０を備える。
処理部１０は、サービス監視装置１の処理を司る。処理部１０は、トラフィック抽出部１１（抽出部）、定常性算出部１２、サービス品質判定部１３（判定部）、および、結果出力部１４、といった機能部を備える。これらの機能部については後記する。
入出力部２０は、サービス監視装置１の入出力インターフェースを構成する。入出力部２０は、入力部２１および出力部２２を備える。入力部２１は、ＨＭＩ装置５からの入力やネットワーク装置２からのフローデータなどの取得を行う。出力部２２は、処理部１０による処理結果をファイルｆ等で出力する。
記憶部３０は、所定のデータを所定の形式で記憶する。記憶部３０は、フローデータ保存部３１、定常性データ保存部３２、および、詳細データ保存部３３、といった機能部を備える。これらの機能部については後記する。

トラフィック抽出部１１は、ネットワーク装置２から収集したフローデータから、提供中の所定のサービスに対する要求トラフィックおよび応答トラフィックを抽出する。

「要求トラフィック」とは、サービスを利用する端末４からサービスを提供するサーバ３へ向けられた、サービス実現に必要な情報である。要求トラフィックを送信する端末４は、フローデータの送信元ＩＰアドレスから識別できる。要求トラフィックを受信するするサーバ３は、フローデータの宛先ＩＰアドレスから識別できる。

「応答トラフィック」とは、サービスを提供するサーバ３からサービスを利用する端末４へ向けられた、サービス実現に必要な情報である。応答トラフィックを送信するサーバ３は、フローデータの送信元ＩＰアドレスから識別できる。応答トラフィックを受信するする端末４は、フローデータの宛先ＩＰアドレスから識別できる。

定常性算出部１２は、トラフィック抽出部１１が抽出した、要求トラフィックおよび応答トラフィックに基づいて、要求トラフィックおよび応答トラフィックとの間の定常性を算出する。サーバ３から端末４へのサービスの提供が正常に行われている場合、要求トラフィックおよび応答トラフィックの間には一定の傾向が発生し、所定の定常状態が形成されると考えられる。定常性算出部１２が算出する定常性は、この定常状態を定量的に表現したものである。もし、ＤｏＳ攻撃などによりサーバ３がサービスを提供できない場合には、要求トラフィックに対して、応答トラフィックが極端に少なくなり定常性が破綻しているといえる。
なお、定常性算出部１２による定常性の算出は、所定の単位時間ごとに行われる。また、定常性の算出方法はさまざまであり、詳細は後記する。

サービス品質判定部１３は、特定期間内での要求トラフィックおよび応答トラフィックとの間の関係性が、定常性算出部１２が算出した定常性からどれだけ逸脱しているかによって、サービスの品質を判定する。「特定期間」とは、例えば、定常性算出部１２が定常性を算出する際に対象とした期間よりも後の期間とすることができる。「要求トラフィックおよび応答トラフィックとの間の関係性」は、定常性算出部１２が算出した定常性と同じ物理量で表現される。サービス品質判定部１３が用いる関係性と、定常性算出部１２が算出した定常性との逸脱度合いが大きいほどサービスの品質が低下しているとする。例えば、ＤｏＳ攻撃などが発生している場合、サービス品質判定部１３が用いる関係性が、定常性算出部１２が算出した定常性よりも大きく逸脱するため、対象とするサービスの品質は低下していると判定することができる。

結果出力部１４は、サービス品質判定部１３によって、サービス品質が低下していると判定されたサービスに関する詳細データを出力する。詳細データには、例えば、対象とするサービスを提供しているサーバ３のホスト名、そのサービスを利用する端末４の数などさまざまなデータが含まれる。ＨＭＩ装置５は、サービス監視装置１を制御して、オペレータが所望する詳細データを取得することができる。また、出力部２２は、取得した詳細データを処理部１０による処理結果としてファイルｆ等で出力する。

フローデータ保存部３１は、サービス監視装置１が収集したフローデータを所定の形式で保存する。トラフィック抽出部１１は、フローデータ保存部３１にアクセスして要求トラフィックおよび応答トラフィックの抽出を行う。

定常性データ保存部３２は、定常性算出部１２が算出した定常性を所定の形式で保存する。
詳細データ保存部３３は、例えば、サービス品質判定部１３によってサービス品質が低下していると判定されたサービスに関する詳細データを所定の形式で保存する。

＜処理＞
図３に示すように、本実施形態のサービス監視装置１は、本実施形態のサービス監視装置１の処理は以下の通りである。この処理は、ステップＳ１から開始する。

ステップＳ１にて、トラフィック抽出部１１は、収集したフローデータから、要求トラフィックおよび応答トラフィックを抽出する。ステップＳ１の後、ステップＳ２に進む。

ステップＳ２にて、定常性算出部１２は、抽出された、要求トラフィックおよび応答トラフィックの間の定常性を算出する。ステップＳ２の後、ステップＳ３に進む。

ステップＳ３にて、サービス品質判定部１３は、特定期間内での要求トラフィックおよび応答トラフィックとの間の関係性が、定常性算出部１２が算出した定常性からどれだけ逸脱しているかによって、サービスの品質を判定する。なお、サービス品質判定部１３は、サービス品質判定部１３が用いる関係性と、定常性算出部１２が算出した定常性との逸脱度合いに関する閾値となる許容誤差（詳細は後記）を用いてサービスの品質を判定することができる。ステップＳ３の後、ステップＳ４に進む。
に進む。

ステップＳ４にて、結果出力部１４は、許容誤差より大きくサービス品質が変動しているネットワーク装置２について詳細データを収集し、結果を出力する。

図３に示す処理によれば、許容誤差を用いて、要求トラフィックおよび応答トラフィックの間の定常性の破綻を判定することができるので、提供中のサービスの監視を確実に行うことができる。

本実施形態によれば、ネットワークデータから収集したフローデータを用いることで、提供中である複数のサービスを特定するとともに、特定したサービスに対して、要求トラフィックと応答トラフィックとの間の定常性を見つけ出すことができる。このため、サービス品質を定常性からの逸脱度合いとして定量的に評価することができる。その結果、複数のサービスが提供されているネットワークに対して、提供中のサービスの監視を行うことができるようにすることができる。

次に、実施例１〜３に亘って、サービス品質の判定方法の具体例を説明する。

［実施例１］
定常性算出部１２が算出する定常性として、要求トラフィックおよび応答トラフィックとの間の相関係数を採用することができる。サーバ３をＤＮＳ（Domain Name System）サーバ３ａとし、１または複数のＤＮＳサーバ３ａが提供するサービスを例に採り上げて説明する。

ＤＮＳに関する通信は、５３番ポートで行われる。よって、トラフィック抽出部１１は、複数のネットワーク装置２の各々から収集したフローデータから、宛先ポート番号が５３番となるフローデータを要求トラフィックとして抽出し、送信元ポート番号が５３番となるフローデータを応答トラフィックとして抽出する。

定常性算出部１２は、抽出された要求トラフィックの量となる要求フロー数（フローデータの数）を、ネットワーク装置２ごとに、かつ、所定期間ごとに求めるとともに、抽出された応答トラフィックの量となる応答フロー数を、ネットワーク装置２ごとに、かつ、所定期間ごとに求める。よって、各ネットワーク装置２から、時刻ｔ（ｋ−１）〜時刻ｔ（ｋ）（ｋ＝１，２，・・・）の期間に得られた、要求フロー数および応答フロー数が求まる。定常性算出部１２は、ネットワーク装置２の数からなる成分を有する要求フロー数の変量と、ネットワーク装置２の数からなる成分を有する応答フロー数の変量とを用いて相関係数を求める。相関係数は、２変量の共分散を、各変量の標準偏差の積で除算したものである。

時刻ｔ（ｋ−１）〜ｔ（ｋ）（ｋ＝１，２，・・・，７）の期間に得られた相関係数は以下の通りであったとする。
ｔ（０）〜ｔ（１）の相関係数＝0.95
ｔ（１）〜ｔ（２）の相関係数＝0.93
ｔ（２）〜ｔ（３）の相関係数＝0.97
ｔ（３）〜ｔ（４）の相関係数＝0.99
ｔ（４）〜ｔ（５）の相関係数＝0.91
ｔ（５）〜ｔ（６）の相関係数＝0.75
ｔ（６）〜ｔ（７）の相関係数＝0.85

上記によれば、ｔ（ｋ−１）〜ｔ（ｋ）（ｋ＝１，２，３，４，５）の相関係数の平均値は0.95である。定常性算出部１２は、例えば、この平均値0.95を定常性として採用することができる。

なお、図４には、ある期間において、ネットワーク装置２ごとにプロットした、ＤＮＳサーバ３ａのサービスに関する要求フロー数および応答フロー数の散布図が示されている。散布図の横軸には応答フロー数（src53番のフロー数（ＤＮＳ応答フロー数）。「src」は送信元を表す）をとり、散布図の縦軸には要求フロー数（dst53番のフロー数（ＤＮＳ要求フロー数）。「dst」は宛先を表す）をとる。なお、散布図中のプロットは、１つの期間（例：期間ｔ（０）〜ｔ（１））を対象としたプロットであるとするが、２以上の期間をまとめて対象としたプロットとしてもよい。

定常性算出部１２は、散布図中のプロットを対象にして相関係数を求める。相関係数が大きな値を示す場合、図４中の直線Ｌ（二点鎖線）の近傍にプロットが集まるといった、要求フロー数と応答フロー数との間に一定の傾向がある。一方、フローデータはサンプリングデータであるため、相当量の誤差が含まれており、サービス品質が安定していてもプロットは直線Ｌからある程度は離れてしまう。よって、直線Ｌに対してある程度の幅を有するエリアＡ１を定め、エリアＡ１の範囲内にあるプロットから定常性を定義することが好ましい。

サービス品質判定部１３は、ｔ（５）〜ｔ（６）の相関係数0.75（関係性）が、定常性を示す相関係数の平均値0.95からどれだけ逸脱しているかを評価する。ＨＭＩ装置５から指定された許容誤差σ（図３のステップＳ４参照）が0.15であるとした場合、

ｔ（５）〜ｔ（６）の逸脱度合い ＝ |0.95-0.75| = 0.20 ＞ σ

となり、ｔ（５）〜ｔ（６）における要求フロー数および応答フロー数の間の関係性が定常性から大きく逸脱しているといえる。よって、サービス品質判定部１３は、ｔ（５）〜ｔ（６）におけるＤＮＳサーバ３ａのサービスの品質が低下していると判定する。

図４の散布図には、ｔ（５）〜ｔ（６）における要求フロー数および応答フロー数の間の関係性を示すプロットとして、エリアＡ２に含まれるプロットが示されている。このプロットは、ＤｏＳ攻撃等によってＤＮＳ応答フロー数に対して、ＤＮＳ要求フロー数が極端に増大しているため、エリアＡ１から大きく逸脱している。その結果、エリアＡ２に含まれるプロットに該当するネットワーク装置２について何らかの対処を施す必要があると判断することができる。

また、サービス品質判定部１３は、ｔ（６）〜ｔ（７）の相関係数0.85が、定常性を示す相関係数の平均値0.95からどれだけ逸脱しているかを評価する。この場合、

ｔ（６）〜ｔ（７）の逸脱度合い ＝ |0.95-0.85| = 0.10 ＜ σ

となり、ｔ（６）〜ｔ（７）における要求フロー数および応答フロー数の間の関係性が定常性から逸脱しているといえない。よって、サービス品質判定部１３は、ｔ（６）〜ｔ（７）におけるＤＮＳサーバ３ａのサービスの品質が低下しておらず安定していると判定する。

図４の散布図によれば、には、ｔ（６）〜ｔ（７）における要求フロー数および応答フロー数の間の関係性を示すプロットは、エリアＡ１に含まれる。その結果、ｔ（６）〜ｔ（７）において、ＤＮＳサーバ３ａによるサービスの品質は安定しているといえる。

結果出力部１４は、期間ｔ（５）〜ｔ（６）についてサービス品質が低下していると判定された、ＤＮＳサーバ３ａが提供するサービスについて詳細データを作成する。例えば、サービス品質の低下を示したフローデータから、
（１）ＤＮＳサーバのＩＰアドレス（宛先ポート番号が５３番であるフローデータの宛先ＩＰアドレス、送信元ポート番号が５３番であるフローデータの送信元ＩＰアドレス）
（２）サービスを利用しているユーザの端末のＩＰアドレス（宛先ポート番号が５３番であるフローデータの送信元ＩＰアドレス、送信元ポート番号が５３番であるフローデータの宛先ＩＰアドレス）
（３）ポート番号（本例では、５３番）
（４）定常性からの逸脱度合い
（５）ＤＮＳサーバのホスト名
（６）サービスを利用しているユーザの端末の数
（７）要求フロー数（または応答フロー数）が想定外に大きくなったネットワーク装置の識別子
などを詳細データとして出力する。出力された詳細データは、ＨＭＩ装置５に送信され、オペレータによる分析に寄与する。

実施例１によれば、要求フロー数と応答フロー数との間の相関係数を、要求トラフィックと応答トラフィックとの間の定常性として採用することで、サービス品質の低下を招く要因を容易に特定することができる。このため、複数のサービスが提供されているネットワークに対して、提供中のサービスの監視を行うことができるようにすることができる。

［実施例２］
あるサービスに対する、要求トラフィックおよび応答トラフィックについてk-means法等によるクラスタリングを採用し、定常性算出部１２が算出する定常性として、クラスタの数、クラスタの重心の座標を採用することができる。サーバ３をＤＮＳサーバ３ａとし、１または複数のＤＮＳサーバ３ａが提供するサービスを例に採り上げて説明する。

サービス品質安定時において、ネットワーク装置２ごとにプロットした、ＤＮＳサーバ３ａのサービスに関する要求フロー数および応答フロー数の散布図は、図５（ａ）に示すようになったとする。この場合、クラスタリングを行うと、定常性を示す２個のクラスタＢ１，Ｂ２が形成され、クラスタＢ１，Ｂ２の各々の重心を求めることができる。

ここで、サービス品質低下時において、ネットワーク装置２ごとにプロットしたときの散布図が図５（ｂ）に示すようになったとする。この場合、クラスタリングを行うと、クラスタＢ１，Ｂ２の他に、応答フロー数に対して要求フロー数が極端に多いエリアにプロットされるクラスタＢ３が形成される。よって、サービス品質判定部１３は、サービス品質安定時と比較して、クラスタの数が１増えたこと（関係性）、クラスタＢ３の重心の座標が、クラスタＢ１，Ｂ２の座標から相当量乖離していること（関係性）を理由にして、サービス品質が低下していると判定する。

実施例２によれば、要求フロー数および応答フロー数に対してクラスタリングを行い、クラスタの数および重心を、要求トラフィックと応答トラフィックとの間の定常性として採用することで、サービス品質の低下を招く要因を容易に特定することができる。このため、複数のサービスが提供されているネットワークに対して、提供中のサービスの監視を行うことができるようにすることができる。

［実施例３］
あるサービスに対する、要求トラフィックおよび応答トラフィックの各々について、ネットワーク装置２から収集したフローデータに関するヒストグラムを採用し、定常性算出部１２が算出する定常性として、要求トラフィックのヒストグラムと、応答トラフィックのヒストグラムとの間の類似度を採用することができる。サーバ３をＤＮＳサーバ３ａとし、１または複数のＤＮＳサーバ３ａが提供するサービスを例に採り上げて説明する。

ある期間における、ＤＮＳサーバ３ａのサービスに関する要求フロー数のヒストグラムは、図６（ａ）に示すようになったとする。ここで、図６（ａ）のヒストグラムの横軸には、フローデータをサービス監視装置１にエクスポートしたネットワーク装置２の識別子を「データ区間」としてとり、縦軸には、各ネットワーク装置２からエクスポートされたフローデータのうち要求ポート番号が５３番となるフローデータの数（ＤＮＳ要求フロー数）を「頻度」としてとる。図６（ａ）では、縦軸の頻度は、例えば、１０個のネットワーク装置２からエクスポートされたときのＤＮＳ要求フロー数の合計値を示しているが、これに限定されない。
なお、必要に応じて、ＤＮＳ要求フロー数は、ＤＮＳサーバ３ａごとにとってもよい。

また、同じ期間における、ＤＮＳサーバ３ａのサービスに関する応答フロー数のヒストグラムは、図６（ｂ）に示すようになったとする。図６（ｂ）のヒストグラムの横軸および縦軸のとり方は図６（ａ）と同じである。

例えば、ＤＮＳ要求フロー数ヒストグラムと、ＤＮＳ応答フロー数ヒストグラムとの間の類似度は、データ区間の各値に対する頻度を成分としたベクトル同士のコサイン類似度として算出することができる。コサイン類似度は、（「ＤＮＳ要求フロー数ヒストグラムから得られるベクトル」と「ＤＮＳ応答フロー数ヒストグラムから得られるベクトル」との内積）を（「ＤＮＳ要求フロー数ヒストグラムから得られるベクトルの大きさ」と「ＤＮＳ応答フロー数ヒストグラムから得られるベクトルの大きさ」との積）で除算した値として計算される。コサイン類似度が大きい（１に近い）ほど、両ベクトルはより類似していることになる。

定常性算出部１２は、ＤＮＳ要求フロー数ヒストグラム（図６（ａ））から得られるベクトルと、ＤＮＳ応答フロー数ヒストグラム（図６（ｂ））から得られるベクトルと、を用いてコサイン類似度を、所定の期間ごと（例：ｔ（ｋ−１）〜ｔ（ｋ）（ｋ＝１，２，３，４，５））に計算する。そして、定常性算出部１２は、例えば、所定の期間ごとに計算したコサイン類似度の平均値を定常性として採用する。

サービス品質判定部１３は、特定期間（例：ｔ（５）〜ｔ（６））について、コサイン類似度（関係性）を算出する。算出したコサイン類似度と、定常性となるコサイン類似度の平均値との差分が、ＨＭＩ装置５から入力された許容誤差を超えた場合、サービス品質判定部１３は、特定期間におけるＤＮＳサーバ３ａのサービスの品質が低下していると判定する。

また、例えば、ＤＮＳ要求フロー数ヒストグラムと、ＤＮＳ応答フロー数ヒストグラムとの間の類似度は、データ区間の各値に対する頻度から得られる要素からなる集合同士のJaccard係数として算出することができる。「データ区間の各値に対する頻度から得られる要素」は、データ区間の各値に対する頻度が微小値以上であれば「１」となり、微小値未満であれば「０」となる。これにより、ＤＮＳ要求フロー数ヒストグラムおよびＤＮＳ応答フロー数ヒストグラムが示す分布は、０１集合で表現することができる。

Jaccard係数は、ＤＮＳ要求フロー数ヒストグラムから得られる０１集合、および、ＤＮＳおよびフロー数ヒストグラムから得られる０１集合について、各データ区間における要素の値がいずれも「１」となる要素の数を、各データ区間における要素の値がいずれか一方が「１」となる要素の数で除算した値として計算される。Jaccard係数が大きい（１に近い）ほど、両集合はより類似していることになる。

定常性算出部１２は、ＤＮＳ要求フロー数ヒストグラム（図６（ａ））から得られる０１集合と、ＤＮＳ応答フロー数ヒストグラム（図６（ｂ））から得られる０１集合と、を用いてJaccard係数を、所定の期間ごと（例：ｔ（ｋ−１）〜ｔ（ｋ）（ｋ＝１，２，３，４，５））に計算する。そして、定常性算出部１２は、例えば、所定の期間ごとに計算したJaccard係数の平均値を定常性として採用する。

サービス品質判定部１３は、特定期間（例：ｔ（５）〜ｔ（６））について、Jaccard係数（関係性）を算出する。算出したJaccard係数と、定常性となるJaccard係数の平均値との差分が、ＨＭＩ装置５から入力された許容誤差を超えた場合、サービス品質判定部１３は、特定期間におけるＤＮＳサーバ３ａのサービスの品質が低下していると判定する。

実施例３によれば、要求フロー数および応答フロー数をヒストグラムで表現し、要求フロー数ヒストグラムおよび応答フロー数ヒストグラムの類似度を、要求トラフィックと応答トラフィックとの間の定常性として採用することで、サービス品質の低下を招く要因を容易に特定することができる。このため、複数のサービスが提供されているネットワークに対して、提供中のサービスの監視を行うことができるようにすることができる。

（プログラム）
また、上記実施形態に係るサービス監視装置１が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。この場合、コンピュータがプログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかるプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませて実行することにより上記実施形態と同様の処理を実現してもよい。以下に、サービス監視装置１と同様の機能を実現する監視プログラムを実行するコンピュータの一例を説明する。

図７は、監視プログラムを実行するコンピュータを示す図である。図７に示すように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有する。これらの各部は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。ディスクドライブ１１００には、例えば、磁気ディスクや光ディスク等の着脱可能な記憶媒体が挿入される。シリアルポートインタフェース１０５０には、例えば、マウス１１１０およびキーボード１１２０が接続される。ビデオアダプタ１０６０には、例えば、ディスプレイ１１３０が接続される。

ここで、図７に示すように、ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。上記実施形態で説明した各テーブルは、例えばハードディスクドライブ１０９０やメモリ１０１０に記憶される。

また、監視プログラムは、例えば、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、ハードディスクドライブ１０９０に記憶される。具体的には、上記実施形態で説明した監視プログラムが実行する各処理が記述されたプログラムモジュールが、ハードディスクドライブ１０９０に記憶される。

また、監視プログラムによる情報処理に用いられるデータは、プログラムデータとして、例えば、ハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、ハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した各手順を実行する。

なお、監視プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限られず、例えば、着脱可能な記憶媒体に記憶されて、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、監視プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等のネットワークを介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。

≪その他≫
（１）：実施例１において、要求フロー数と応答フロー数との間の相関係数を定常性として採用した。しかし、要求フロー数および応答フロー数として用いたフロー数の代替手段として、１フローあたりのパケット数や、１パケットあたりのバイト数（つまり、平均パケット長）を用いることもできる。

（２）：１つのサービスを提供するサーバ３が複数存在する場合、定常性算出部１２が算出した定常性があまり良好でない場合（例えば、定常性に用いようとする相関係数が小さすぎて図４の散布図のプロットが散在してしまう場合）、対象にするサーバ３の数を減らす（場合によっては１つのサーバ３に絞る）ことで相関係数を大きくすることができる。

（３）：実施例２において、要求フロー数および応答フロー数に対してクラスタリングをし、定常性算出部１２が算出する定常性として、クラスタの数、クラスタの重心の座標を採用した。しかし、要求フロー数および応答フロー数として用いたフロー数の代替手段として、送受信ＩＰアドレスの数、送受信ＩＰアドレスの種類を用いることもできる。

（４）：実施例３において、要求フロー数および応答フロー数をヒストグラムで表現し、定常性算出部１２が算出する定常性として、コサイン類似度やJaccard係数を採用した。しかし、要求フロー数および応答フロー数として用いたフロー数の代替手段として、送受信ＩＰアドレスの数、送受信ＩＰアドレスの種類を用いることもできる。

また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
また、本実施形態で説明したソフトウェアをハードウェアとして実現することもでき、ハードウェアをソフトウェアとして実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１ サービス監視装置
２ ネットワーク装置
３ サーバ
４ 端末
５ ＨＭＩ装置
１０ 処理部
１１ トラフィック抽出部（抽出部）
１２ 定常性算出部
１３ サービス品質判定部（判定部）
１４ 結果出力部
２０ 入出力部
２１ 入力部
２２ 出力部
３０ 記憶部
３１ フローデータ保存部
３２ 定常性データ保存部
３３ 詳細データ保存部

Claims (2)

1. 複数のネットワーク装置から収集したフローデータを用いて、サービスを監視するサービス監視装置であって、
   前記収集したフローデータから、前記サービスに対する、要求トラフィックおよび応答トラフィックを抽出する抽出部と、
   前記抽出された、要求トラフィックおよび応答トラフィックに基づいて、前記要求トラフィックおよび前記応答トラフィックとの間の定常性を算出する定常性算出部と、
   特定期間内での前記要求トラフィックおよび前記応答トラフィックとの間の関係性が、前記算出された定常性からどれだけ逸脱しているかによって、前記サービスの品質を判定する判定部と、を備える、
   ことを特徴とするサービス監視装置。
2. 複数のネットワーク装置から収集したフローデータを用いて、サービスを監視するサービス監視装置におけるサービス監視方法であって、
   前記収集したフローデータから、前記サービスに対する、要求トラフィックおよび応答トラフィックを抽出する抽出ステップと、
   前記抽出された、要求トラフィックおよび応答トラフィックに基づいて、前記要求トラフィックおよび前記応答トラフィックとの間の定常性を算出する定常性算出ステップと、
   特定期間内での前記要求トラフィックおよび前記応答トラフィックとの間の関係性が、前記算出された定常性からどれだけ逸脱しているかによって、前記サービスの品質を判定する判定ステップと、を備える、
   ことを特徴とするサービス監視方法。

Images