特許 6198195 推定装置、推定方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6198195

(24)【登録日】2017年9月1日

(45)【発行日】2017年9月20日

(54)【発明の名称】推定装置、推定方法、及びプログラム

(51)【国際特許分類】

   H04L 12/70 20130101AFI20170911BHJP

【ＦＩ】

   H04L12/70 100A

【請求項の数】7

【全頁数】21

(21)【出願番号】特願2015-28744(P2015-28744)

(22)【出願日】2015年2月17日

(65)【公開番号】特開2016-152501(P2016-152501A)

(43)【公開日】2016年8月22日

【審査請求日】2016年11月1日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(73)【特許権者】

【識別番号】899000068

【氏名又は名称】学校法人早稲田大学

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】下田 晃弘

(72)【発明者】

【氏名】石橋 圭介

(72)【発明者】

【氏名】佐藤 一道

(72)【発明者】

【氏名】井上 武

(72)【発明者】

【氏名】森 達哉

(72)【発明者】

【氏名】後藤 滋樹

【審査官】 宮島 郁美

(56)【参考文献】

【文献】 特開2013-157931（ＪＰ，Ａ）

【文献】 特開2006-129533（ＪＰ，Ａ）

【文献】 特開2006-13876（ＪＰ，Ａ）

【文献】 特開2005-348416（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ１２／００−１２／２６，１２／５０−１２／９５５

(57)【特許請求の範囲】

【請求項1】

ネットワークにおいて観測されるＤＮＳ応答に基づいて、ドメイン名ごとのＤＮＳ要求の数を計測する第一の計測部と、
ネットワークにおいて観測されるフローについて、ＩＰアドレスが共通する単位ごとに、フロー数及びデータ量の合計を計測する第二の計測部と、
前記ＤＮＳ応答に含まれるドメイン名又はＩＰアドレスをノードとし、前記ドメイン名及び前記ＩＰアドレスの間の対応関係を枝とするグラフを生成する生成部と、
前記グラフのノードを構成する各ＩＰアドレスに関して前記第二の計測部によって計測されたデータ量と、前記グラフの中間ノードを除くノードを構成するドメイン名に関して前記第一の計測部によって計測されたＤＮＳ要求の数との関係を示す変換行列を推定する行列推定部と、
前記ドメイン名ごとの要求数に前記各ドメイン名のフローごとのデータ量を乗じた値が、前記変換行列に前記ＩＰアドレスごとのデータ量を乗じた値に等しいとする関係に基づいて、前記各ドメイン名のフローごとのデータ量を求め、当該データ量に、ドメイン名ごとのＤＮＳ要求の数を乗じて、ドメイン名ごとのデータ量の推定値を算出する算出部と、
を有することを特徴とする推定装置。

【請求項2】

前記行列推定部は、前記グラフを隣接行列に変換し、前記隣接行列を前記グラフの最大ホップ長の数だけ掛け合わせて得られる行列のうち、前記グラフの中間ノードを除くドメイン名のノードとＩＰアドレスのノードとの組み合わせに対応する成分を前記変換行列の初期値として抽出し、抽出された初期値と、前記グラフのノードを構成する各ＩＰアドレスに関して前記第二の計測部によって計測されたデータ量と、前記グラフの中間ノードを除くノードを構成するドメイン名に関して前記第一の計測部によって計測されたＤＮＳ要求の数とに基づいて、前記変換行列を推定し、
前記隣接行列は、入次数が０であるノードの対角成分の値を１とし、入次数が１以上であるノードに入る枝に対応する成分の値を、当該枝の数で１を除すことにより得られる値とする、
ことを特徴とする請求項１記載の推定装置。

【請求項3】

前記生成部は、前記ＤＮＳ応答に含まれるドメイン名又はＩＰアドレスをノードとし、前記ドメイン名及び前記ＩＰアドレスの間の対応関係を枝とする１以上の連結グラフを生成し、
前記行列推定部は、前記連結グラフごとに、前記変換行列を推定し、
前記算出部は、前記連結グラフごとに、当該連結グラフの中間ノードを除くノードを構成するドメイン名ごとの推定値を算出する、
ことを特徴とする請求項１又は２記載の推定装置。

【請求項4】

ネットワークにおいて観測されるＤＮＳ応答に基づいて、ドメイン名ごとのＤＮＳ要求の数を計測する第一の計測部と、
ネットワークにおいて観測されるフローについて、ＩＰアドレスが共通する単位ごとに、フロー数及びデータ量の合計を計測する第二の計測部と、
前記ドメイン名ごとの要求数に前記各ドメイン名のフローごとのデータ量を乗じた値が、前記ＩＰアドレスごとのデータ量に等しいとする関係に基づいて、前記各ドメイン名のフローごとのデータ量を求め、当該データ量に、ドメイン名ごとのＤＮＳ要求の数を乗じて、ドメイン名ごとのデータ量の推定値を算出する算出部と、
を有することを特徴とする推定装置。

【請求項5】

コンピュータが、
ネットワークにおいて観測されるＤＮＳ応答に基づいて、ドメイン名ごとのＤＮＳ要求の数を計測する第一の計測手順と、
ネットワークにおいて観測されるフローについて、ＩＰアドレスが共通する単位ごとに、フロー数及びデータ量の合計を計測する第二の計測手順と、
前記ＤＮＳ応答に含まれるドメイン名又はＩＰアドレスをノードとし、前記ドメイン名及び前記ＩＰアドレスの間の対応関係を枝とするグラフを生成する生成手順と、
前記グラフのノードを構成する各ＩＰアドレスに関して前記第二の計測手順によって計測されたデータ量と、前記グラフの中間ノードを除くノードを構成するドメイン名に関して前記第一の計測手順によって計測されたＤＮＳ要求の数との関係を示す変換行列を推定する行列推定手順と、
前記ドメイン名ごとの要求数に前記各ドメイン名のフローごとのデータ量を乗じた値が、前記変換行列に前記ＩＰアドレスごとのデータ量を乗じた値に等しいとする関係に基づいて、前記各ドメイン名のフローごとのデータ量を求め、当該データ量に、ドメイン名ごとのＤＮＳ要求の数を乗じて、ドメイン名ごとのデータ量の推定値を算出する算出手順と、
を実行することを特徴とする推定方法。

【請求項6】

コンピュータが、
ネットワークにおいて観測されるＤＮＳ応答に基づいて、ドメイン名ごとのＤＮＳ要求の数を計測する第一の計測手順と、
ネットワークにおいて観測されるフローについて、ＩＰアドレスが共通する単位ごとに、フロー数及びデータ量の合計を計測する第二の計測手順と、
前記ドメイン名ごとの要求数に前記各ドメイン名のフローごとのデータ量を乗じた値が、前記ＩＰアドレスごとのデータ量に等しいとする関係に基づいて、前記各ドメイン名のフローごとのデータ量を求め、当該データ量に、ドメイン名ごとのＤＮＳ要求の数を乗じて、ドメイン名ごとのデータ量の推定値を算出する算出手順と、
を実行することを特徴とする推定方法。

【請求項7】

請求項１乃至４いずれか一項記載の各部としてコンピュータを機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、推定装置、推定方法、及びプログラムに関する。

【背景技術】

【0002】

近年、動画配信サービスをはじめとする、多数のユーザを抱えるインターネット上のサービスにおいて、コンテンツの配信元サーバを地理的、又はネットワーク的に分散させることで、トラヒックの分散、サーバ負荷の分散、あるいは遅延時間の低減を図る仕組みが導入されている。特に、ＣＤＮ（Contents Delivery Network）は、配信元サーバを分散させることに特化したサービスであり、現在、多くのインターネット・サービスが、ＣＤＮを利用してコンテンツの配信を行っている。

【0003】

一方で、ＣＤＮでは配信元サーバの各ＩＰアドレスが複数のサービスで共用される場合がある。この運用形態により、ＣＤＮ経由のトラヒックの統計情報を知りたい場合において、フロー情報に含まれるＩＰアドレスの情報では、そのＩＰアドレスに紐付く配信元サービスを一意に特定することが困難である。

【0004】

上記の課題を解決する方法の一つとして、ＤＰＩ（Deep Packet Inspection）が存在する。ＤＰＩはパケットのペイロード領域（ＯＳＩ（Open Systems Interconnection）参照モデルではレイヤ５から７に該当する領域）をも含めたパケット分析方式全般を指す。ＤＰＩを用いて、パケットのペイロード領域に含まれるサービス名や識別子を抽出することにより、そのパケットのサービス名の特定が可能である。例えば、ＨＴＴＰ（HyperText Transfer Protocol）パケットの場合は、ＨＴＴＰリクエスト・パケットのＨＴＴＰヘッダに含まれる「ＨＯＳＴフィールド」を参照することで、そのパケットのサービス名を特定できる。

【0005】

しかしながら、パケットのペイロード領域にサービスを特定する情報が含まれていない場合には、ＤＰＩを適用してサービス名を特定するのは困難である。また、パケットが暗号化されておりペイロード領域を参照できない場合においても、ＤＰＩの適用は困難である。更に、ＤＰＩでは、全てのパケットについて、ペイロード領域も含めてキャプチャを行い、なおかつ平行して分析を行うため、測定装置のコストと負荷が高く、大容量トラヒックへの適用は現実的には困難である。

【0006】

一方、ＤＰＩを用いずに、かつ、暗号化通信にも適用できる方式として、ＤＮＳ（Domain Name System）ログとフロー情報とを突合してフローのサービスを識別する方式が提案されている（例えば、非引用文献４参照）。非引用文献４では、ＤＮＳログとフロー情報とが同一地点で収集される。その上で、あるユーザが送受信したフローと、該フローの直近に該ユーザが送受信したＤＮＳパケットの問い合わせドメイン名とを紐付けることで、該フローのドメイン名（すなわち、サービスの識別名）が推定される。この方式はフロー情報とＤＮＳログとを同一地点で収集するという条件において、ＨＴＴＰ通信では７５％から９７％の推定精度、暗号化通信（ＴＬＳ（Transport Layer Security））では７４％から９６％の推定精度を示している。

【先行技術文献】

【非特許文献】

【0007】

【非特許文献1】Domain Names:Implementation and Specification,https://www.ietf.org/rfc/rfc1035.txt

【非特許文献2】Cisco Systems NetFlow Services Export Version9,http://www.ietf.org/rfc/rfc3954.txt

【非特許文献3】InMon Corporation's sFlow:A Method for Monitoring Traffic in Switched and Routed Networks,https://www.ietf.org/rfc/rfc3176.txt

【非特許文献4】Bermudez,Ignacio N.,et al,"DNS to the rescue: discerning content and services in a tangled web",In:Proceedings of the 2012 ACM conference on Internet measurement conference,ACM,2012,p.413-426,2012.

【非特許文献5】P.-A.Absil,et all,(2007),Optimization Algorithms on Matrix Manifolds,pp.10-14,ISBN 978-0-691-13298-3.

【非特許文献6】Russell,Stuart J.,Norvig Peter,(2003),Artificial Intelligence:A Modern Approach (3rd ed.),Upper Saddle River,New Jersey:Prentice Hall,pp.122-125,ISBN 978-0-13-604259-4.

【発明の概要】

【発明が解決しようとする課題】

【0008】

しかしながら、フロー情報とＤＮＳログとが異なる場所で収集される環境においては、フローと直近のＤＮＳパケットの突合は困難である。したがって、引用文献４に記載された方式では、斯かる環境において収集されたフロー情報とＤＮＳログとに基づいて、サービス名単位（例えば、ドメイン名単位）のトラヒック量を推定するのは困難である。

【0009】

本発明は、上記の点に鑑みてなされたものであって、ドメイン名ごとのトラヒック量の推定のための情報収集に関する制約を緩和することを目的とする。

【課題を解決するための手段】

【0010】

そこで上記課題を解決するため、推定装置は、ネットワークにおいて観測されるＤＮＳ応答に基づいて、ドメイン名ごとのＤＮＳ要求の数を計測する第一の計測部と、ネットワークにおいて観測されるフローについて、ＩＰアドレスが共通する単位ごとに、フロー数及びデータ量の合計を計測する第二の計測部と、前記ＤＮＳ応答に含まれるドメイン名又はＩＰアドレスをノードとし、前記ドメイン名及び前記ＩＰアドレスの間の対応関係を枝とするグラフを生成する生成部と、前記グラフのノードを構成する各ＩＰアドレスに関して前記第二の計測部によって計測されたデータ量と、前記グラフの中間ノードを除くノードを構成するドメイン名に関して前記第一の計測部によって計測されたＤＮＳ要求の数との関係を示す変換行列を推定する行列推定部と、前記ドメイン名ごとの要求数に前記各ドメイン名のフローごとのデータ量を乗じた値が、前記変換行列に前記ＩＰアドレスごとのデータ量を乗じた値に等しいとする関係に基づいて、前記各ドメイン名のフローごとのデータ量を求め、当該データ量に、ドメイン名ごとのＤＮＳ要求の数を乗じて、ドメイン名ごとのデータ量の推定値を算出する算出部と、を有する。

【発明の効果】

【0011】

ドメイン名ごとのトラヒック量の推定のための情報収集に関する制約を緩和することができる。

【図面の簡単な説明】

【0012】

【図1】第一の実施の形態における推定装置のハードウェア構成例を示す図である。

【図2】第一の実施の形態における推定装置の機能構成例を示す図である。

【図3】グラフ生成部が実行する処理手順の一例を説明するためのフローチャートである。

【図4】ＤＮＳログ記憶部の構成例を示す図である。

【図5】フロー情報記憶部の構成例を示す図である。

【図6】ＤＮＳ応答テーブルに基づく有向グラフの一例を示す図である。

【図7】連結グラフの抽出を説明するための図である。

【図8】連結グラフの各ノードへの属性情報の付与を説明するための図である。

【図9】トラヒック量推定部が実行する処理手順の一例を説明するためのフローチャートである。

【図10】連結グラフの各ノードへの番号の割り振りを説明するための図である。

【図11】連結グラフに基づく隣接行列の一例を示す図である。

【図12】フロー変換行列の初期値の抽出例を示す図である。

【図13】ドメイン名ごとのトラヒック量の推定結果の出力例を示す図である。

【図14】第三の実施の形態における推定装置の機能構成例を示す図である。

【発明を実施するための形態】

【0013】

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第一の実施の形態における推定装置のハードウェア構成例を示す図である。図１の推定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

【0014】

推定装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0015】

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って推定装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

【0016】

図２は、第一の実施の形態における推定装置の機能構成例を示す図である。図２において、推定装置１０は、ＤＮＳ応答収集部１１、ＤＮＳ応答統計処理部１２、フロー情報収集部１３、フロー情報統計処理部１４、グラフ生成部１５、トラヒック量推定部１６、及び推定値変換部１７等を有する。これら各部は、推定装置１０にインストールされる１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。推定装置１０は、また、ＤＮＳログ記憶部１２１、フロー情報記憶部１２２、及びグラフ情報記憶部１２３を利用する。ＤＮＳログ記憶部１２１、フロー情報記憶部１２２、及びグラフ情報記憶部１２３は、例えば、図１の補助記憶装置１０２、又は推定装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

【0017】

ＤＮＳ応答収集部１１は、ネットワーク上において観測されるＤＮＳ（Domain Name System）応答パケットを収集する。ＤＮＳ応答パケットの収集方法は、特定のものに限定されない。例えば、ＤＮＳキャッシュサーバ又はネットワーク中継装置（例えば、ルータ、スイッチ）より、パケットキャプチャによってＤＮＳ応答パケットが収集されてもよい。

【0018】

ＤＮＳ応答統計処理部１２は、一定期間において収集されたＤＮＳ応答パケットについて統計処理を実行する。統計処理の結果は、ＤＮＳログ記憶部１２１に記憶される。

【0019】

フロー情報収集部１３は、ネットワーク上において観測される任意のフロー（例えば、クライアントとサーバとの間のフロー）に関する情報（以下、「フロー情報」という。）をネットワークを介してフロー情報を収集する。サーバとは、例えば、Ｗｅｂサーバやコンテンツを配信するサーバ等である。フローとは、一つの意味の有るメッセージ（例えば、要求又は応答等）を構成するパケットの集合をいう。したがって、一つのフローを構成するパケットの宛先、送信元のＩＰアドレス、及びポート番号は共通する。フロー情報は、例えば、ルータに搭載されたフロー情報収集機能を用いて収集されてもよい。又は、フロー情報収集部１３がパケットをキャプチャして、フロー情報を生成してもよい。フロー情報の通信プロトコルとしてＮｅｔＦｌｏｗ（非特許文献２参照）やｓＦｌｏｗ（非特許文献３参照）が挙げられるが、「送信元ＩＰアドレス」、「宛先ＩＰアドレス」、「フロー数」、「バイト数」の情報が取得可能であれば、フロー情報の収集方法やプロトコルは特定のものに限定されない。なお、本実施の形態では、フローが通信の最小単位として扱われるが、パケットが通信の最小単位として扱われてもよい。すなわち、以下の説明におけるフローは、パケットに置き換えられてもよい。

【0020】

フロー統計処理部は、一定期間において収集されたフロー情報について統計処理を実行する。統計処理の結果は、ＤＮＳログ記憶部１２１に記憶される。

【0021】

以上から明らかなように、本実施の形態における推定装置１０は、ＤＮＳ応答パケットとフロー情報との両方を収集可能なネットワークであれば、どのようなネットワークに接続されていてもよい。斯かるネットワークの一例として、ＩＳＰ（Internet Service Provider）のバックボーン・ネットワーク、企業内ネットワーク、大学ネットワーク、データセンタ・ネットワーク等が挙げられる。

【0022】

グラフ生成部１５は、グラフ変換部１５１、連結グラフ抽出部１５２、及び属性情報付与部１５３等を含む。グラフ変換部１５１は、ＤＮＳログ記憶部１２１に記憶されている情報を、有向グラフに変換する。より詳しくは、グラフ変換部１５１は、ＤＮＳ応答パケットに含まれているドメイン名（別名をも含む。）又はＩＰアドレスをノードとし、当該ドメイン名とＩＰアドレス、又は当該ドメイン名同士の対応関係を枝とする有向グラフを生成する。

【0023】

連結グラフ抽出部１５２は、グラフ変換部１５１によって生成された有向グラフから、連結グラフを抽出する。すなわち、連結グラフ抽出部１５２は、グラフ変換部１５１によって生成された有向グラフを、１以上の連結グラフの単位に分解する。連結グラフとは、有向グラフの枝を辿ることで到達可能な各ノードと、当該各ノード間を接続する枝との集合である。有向グラフの分割アルゴリズムはグラフ理論の一般的な方式が適用可能である。

【0024】

属性情報付与部１５３は、各連結グラフの各ノードに属性情報を付与する。各ノードは、ドメイン名又はＩＰアドレスである。したがって、各ノードには、当該ノードのドメイン名又はＩＰアドレスに関して、ＤＮＳログ記憶部１２１又はフロー情報記憶部１２２に記憶されている情報が属性情報として付与される。

【0025】

なお、グラフ生成部１５によって生成された有向グラフ（各連結グラフ）を示す情報は、グラフ情報記憶部１２３に記憶される。

【0026】

トラヒック量推定部１６は、グラフ情報記憶部１２３に記憶されている情報が示す有向グラフに基づいて、サービスごとのトラヒック量を推定する。一般的に、ドメイン名によって各サービスを識別することができる。すなわち、サービスごとにドメイン名は異なる。但し、別名によってサービスを識別するのは困難である。一つのサービスに対して複数の別名が設定される可能性が有るからである。したがって、本実施の形態では、別名を除くドメイン名ごとに、トラヒック量が推定される。図２において、トラヒック量推定部１６は、フロー数分配推定部１６１及びトラヒック量算出部１６２を含む。これら各部の機能の詳細については後述される。

【0027】

推定値変換部１７は、トラヒック量推定部１６で推定されたドメイン名ごとのトラヒック量の内部表現を、人間が確認可能なテキスト等の表現形式に変換する。例えば、推定値変換部１７は、変換後の表現形式によって、ドメイン名ごとのトラヒック量を可視化する。

【0028】

以下、推定装置１０が実行する処理手順について説明する。図３は、グラフ生成部が実行する処理手順の一例を説明するためのフローチャートである。図３の開始時において、ログ情報記憶部には、期間ｔ１１において収集されたＤＮＳ応答パケットに関してＤＮＳ応答統計処理部１２によって計測された統計情報が記憶されており、フロー情報記憶部１２２には、期間ｔ１２において収集されたフロー情報に関してフロー情報統計処理部１４によって計測された統計情報が記憶されている。ここで、期間ｔ１１と期間ｔ１２とは、同じであってもよいし、異なっていてもよい。期間ｔ１２と期間ｔ１２とが同じであるとは、それぞれの期間の開始時期及び終了時期が一致することをいう。期間ｔ１１と期間ｔ１２とが異なるとは、それぞれの期間の開始時期及び終了時期の少なくともいずれか一方が異なることをいう。

【0029】

ステップＳ１０１において、グラフ変換部１５１は、ＤＮＳログ記憶部１２１に記憶されている情報（以下、「ＤＮＳログ」という。）を読み出す。

【0030】

図４は、ＤＮＳログ記憶部の構成例を示す図である。図４に示されるように、ＤＮＳログ記憶部１２１には、ＤＮＳ要求テーブルＴ１と、ＤＮＳ応答テーブルＴ２とが記憶されている。

【0031】

ＤＮＳ要求テーブルＴ１には、ＤＮＳ応答のＱｕｅｓｔｉｏｎセクションに記述された情報（すなわち、ＤＮＳ要求に関する情報）が記憶されている。具体的には、ＤＮＳ要求テーブルＴ１には、観測されたドメイン名及びクエリタイプの組み合わせの単位ごとに、要求数及びユーザ数が記憶されている。

【0032】

ドメイン名（厳密にはＦＱＤＮ（Fully Qualified Domain Name）であり、以下のドメイン名についても同じ。）は、ＤＮＳ要求において問い合わせの対象とされたドメイン名（すなわち、名前解決の対象のドメイン名）である。クエリタイプは、当該ＤＮＳ要求において問い合わせの対象とされたレコードである。「Ａ」は、Ａレコードを示す。図４には示されていないが、ＡＡＡＡレコードが問い合わせの対象とされた場合のクエリタイプは、「ＡＡＡＡ」となる。要求数は、「ドメイン名」及び「クエリタイプ」に対応するＱｕｅｓｔｉｏｎセクションを含むＤＮＳ応答の数である。なお、１つのＤＮＳ応答は、複数のＤＮＳ応答パケットによって構成される場合も有るため、ここでは、ＤＮＳ応答の数としている。ユーザ数は、「ドメイン名」及び「クエリタイプ」に対応するＱｕｅｓｔｉｏｎセクションを含むＤＮＳ応答に係るＤＮＳ応答パケットの宛先ＩＰアドレスの種類数である。すなわち、ユーザ数は、ＤＮＳ要求元の種類数である。「ドメイン名」及び「クエリタイプ」ごとの要求数及びユーザ数は、ＤＮＳ応答統計処理部１２によって計測される。なお、図４において、要求数及びユーザ数の値は、便宜上、記号によって示されているが、実際には数値である。

【0033】

一方、ＤＮＳ応答テーブルＴ２には、ＤＮＳ応答のＡｎｓｗｅｒセクションに記述されたＡレコード、ＡＡＡＡレコード、又はＣＮＡＭＥレコード等に関する情報が記憶されている。具体的には、ＤＮＳ応答テーブルＴ２には、観測されたドメイン名、レコードタイプ、及びレコードデータの組み合わせの単位ごとに、ＴＴＬ（Time To Live）が記憶されている。

【0034】

ドメイン名は、名前解決の対象とされたドメイン名である。レコードタイプは、ＤＮＳ応答に含まれているレコードのタイプである。レコードデータは、ＤＮＳ応答に含まれているレコードの値（すなわち、ドメイン名に対して対応付けられている値）である。当該レコードがＡレコード又はＡＡＡＡレコードである場合（すなわち、レコードタイプが「Ａ」又は「ＡＡＡＡ」である場合）、レコードデータの値はＩＰアドレス（ＩＰｖ４のＩＰアドレス又はＩＰｖ６のＩＰアドレス）である。当該レコードがＣＮＡＭＥレコードである場合（すなわち、レコードタイプが「ＣＮＡＭＥ」である場合）、レコードデータの値は、別名である。ＴＴＬは、ドメイン名のキャッシュの有効期限の最大値の推定値である。有効期限の最大値とは、「ＤＮＳ権威サーバ」のゾーンファイルの設定ファイルにおいて定義されている値であり、ネットワーク管理者等によって設定される。観測されるＤＮＳ応答パケット内の各レコードのＴＴＬは、当該ＤＮＳ応答パケットの観測時点での残り秒数であるため、必ずしも最大値ではない。そこで、ＤＮＳ応答統計処理部１２は、期間ｔ１１において観測されたＤＮＳ応答パケットに含まれているＡレコード又はＣＮＡＭＥレコードのうち、ドメイン名、レコードタイプ、及びレコードデータが重複するレコードごとに、観測されたＴＴＬの中で最大の値を計測し、計測結果を、当該レコードのＴＴＬの最大値として推定する。

【0035】

続いて、グラフ変換部１５１は、フロー情報記憶部１２２に記憶されているフロー情報の統計情報（以下、「フロー情報ログ」という。）を読み出す（ステップＳ１０２）。

【0036】

図５は、フロー情報記憶部の構成例を示す図である。図５に示されるように、フロー情報記憶部１２２には、観測されたフローのＩＰアドレスごとに（すなわち、観測されたフローについてＩＰアドレスが共通する単位ごとに）、フロー数、ユーザ数、バイト数が記憶されている。

【0037】

ＩＰアドレスは、サーバ側のＩＰアドレスである。サーバ側のＩＰアドレスは、観測されたフローの送信元ＩＰアドレス又は宛先ＩＰアドレスである。推定装置１０がＩＳＰ等によって運用される場合、各クライアントのＩＰアドレスは、ＩＳＰによって割り当てられる。換言すれば、推定装置１０は、クライアントのＩＰアドレスの一覧を保持することができる。フロー情報統計処理部１４は、斯かる一覧に基づいて、送信元ＩＰアドレス又及び宛先ＩＰアドレスのいずれがサーバのＩＰアドレスであるのかを特定してもよい。

【0038】

フロー数は、「ＩＰアドレス」に係るフローの数である。ユーザ数は、「ＩＰアドレス」に係るフローのクライアント側のＩＰアドレスの数である。バイト数は、「ＩＰアドレス」に係るフローのバイト数の総和（データ量）である。

【0039】

フロー数、ユーザ数、及びバイト数は、フロー情報統計処理部１４によって計測される。なお、図５において、フロー数、ユーザ数、及びバイト数の値は、便宜上、記号によって示されているが、実際には数値である。

【0040】

続いて、グラフ変換部１５１は、ＤＮＳ応答テーブルＴ２の内容を、有向グラフに変換する（ステップＳ１０３）。

【0041】

図６は、ＤＮＳ応答テーブルに基づく有向グラフの一例を示す図である。図６のグラフｇ１は、図４に示したＤＮＳ応答テーブルＴ２に対応する。すなわち、グラフｇ１の各ノードは、ＤＮＳ応答テーブルＴ２のドメイン名又はレコードデータ（ＩＰアドレス若しくは別名）である。具体的には、ノードｎ１、ノードｎ２、及びノードｎ３は、ドメイン名のノードである。ノードｎ４及びノードｎ５は、ＩＰアドレスのノードである。

【0042】

また、グラフｇ１は、ＤＮＳ応答テーブルＴ２におけるドメイン名とレコードデータとの対応関係を示すと共に、ドメイン名からレコードデータへの向きを有する有向枝を含む。

【0043】

続いて、連結グラフ抽出部１５２は、グラフ変換部１５１によって生成された有向グラフを、連結グラフの単位に分解し、各連結グラフを抽出する（ステップＳ１０４）。

【0044】

図７は、連結グラフの抽出を説明するための図である。ステップＳ１０３において生成される有向グラフが、仮に、図７の左側の破線の矩形で囲まれたものである場合、図７の右側に示されるように、４つの連結グラフが抽出される。なお、本実施の形態では、グラフｇ１が、そのまま１つの連結グラフとして抽出される。

【0045】

続いて、属性情報付与部１５３は、各連結グラフの各ノードに対して属性情報を付与する（ステップＳ１０５）。

【0046】

図８は、連結グラフの各ノードへの属性情報の付与を説明するための図である。図８に示されるように、ドメイン名の各ノードに対しては、ＤＮＳ要求テーブルＴ１において当該ノードに対応するレコードの要求数及びユーザ数と、ＤＮＳ応答テーブルＴ２において当該ノードに対応するＴＴＬとが付与される。図８では、「＜要求数＞／＜ユーザ数＞／＜ＴＴＬ＞」の形式で、付与された属性情報が示されている。

【0047】

一方、ＩＰアドレスの各ノードに対しては、フロー情報記憶部１２２において当該ノードに対応するレコードのフロー数、ユーザ数、及びバイト数が付与される。図８では、「＜フロー数＞／＜ユーザ数＞／＜バイト数＞」の形式で、付与された属性情報が示されている。

【0048】

なお、期間ｔ１１と期間ｔ１２との時間が相互に異なる場合、又は各期間の時間幅が相互に異なる場合、各ＩＰアドレスのノード（ノードｎ４及びノードｎ５）に付与されたフロー数の合計と、中間ノードを除くドメイン名のノード（ノードｎ１及びノードｎ２）に付与された要求数の合計とが一致しなくなる可能性が有る。この場合、後述されるフロー数分配推定部１６１によって推定されるフロー変換行列Ｈの推定精度が劣化する可能性が有る。そこで、属性情報付与部１５３は、連結グラフごとに、中間ノードを除く各ドメイン名のノードの要求数の合計が１となるように、当該各ノードの要求数を正規化すると共に、ＩＰアドレスの各ノードのフロー数の合計が１となるように、ＩＰアドレスの各ノードのフロー数を正規化するようにしてもよい。

【0049】

なお、グラフ生成部１５によって生成された各連結グラフを示す情報（以下、「グラフ情報」という。）は、グラフ情報記憶部１２３に記憶される。グラフ情報の生成周期は、ＤＮＳ応答統計処理部１２によるＤＮＳ応答パケットの統計処理の周期以上であり、かつ、フロー情報統計処理部１４によるフロー情報の統計処理の周期以上であれば、どのような周期であってもよい。グラフ情報の生成時期（以下、「グラフ生成時期」という。）が訪れた時点において、ＤＮＳログ記憶部１２１に最後に記憶されたＤＮＳログ（ＤＮＳ要求テーブルＴ１及びＤＮＳ応答テーブルＴ２）と、フロー情報記憶部１２２に最後に記憶されたフロー情報ログとが用いられて、グラフ情報が生成されてもよい。

【0050】

各グラフ生成時期に生成されたグラフ情報は、当該グラフ生成時期に対応付けられてグラフ情報記憶部１２３に記憶される。例えば、期間ｔ１１と期間ｔ１２とに対応するグラフ生成時期をグラフ生成時期ｔ１とすると、期間ｔ１１におけるＤＮＳログと期間ｔ１２におけるフロー情報ログとに基づいて生成されたグラフ情報は、グラフ生成時期ｔ１に対応付けられてグラフ情報記憶部１２３に記憶される。また、期間ｔ１１よりの後の一定期間である期間ｔ１２においてＤＮＳログ記憶部１２１に記憶されたＤＮＳログと、期間ｔ２１よりの後の一定期間である期間ｔ２２においてフロー情報記憶部１２２に記憶されたフロー情報ログとに基づいて生成される各連結グラフを示すグラフ情報は、期間ｔ２１及び期間ｔ２２とに対応するグラフ生成時期ｔ２に対応付けられてグラフ情報記憶部１２３に記憶される。

【0051】

続いて、トラヒック量推定部１６が実行する処理手順について説明する。図９は、トラヒック量推定部が実行する処理手順の一例を説明するためのフローチャートである。なお、図９は、各連結グラフについて実行されるが、本実施の形態では、図６のグラフｇ１が処理対象とされる。また、図９の処理の実行のタイミングは、図３の処理の実行タイミングと非同期であってもよい。

【0052】

ステップＳ２０１において、フロー数分配推定部１６１は、変数ｔに１を代入する。変数ｔは、処理対象とするグラフ生成時期と、ステップＳ２０２以降の実行回数とを識別するための変数である。

【0053】

続いて、フロー数分配推定部１６１は、グラフ情報記憶部１２３から、ｔ番目のグラフ生成時期に対応するグラフ情報を取得する（ステップＳ２０２）。ここでは、グラフ生成時期ｔ１における、図８のグラフｇ１を示すグラフ情報が取得される。続くステップＳ２０３〜ステップＳ２０７において、フロー数分配推定部１６１は、グラフｇ１の形状的特徴と、グラフｇ１の各ノードに付与された属性情報（すなわち、ＤＮＳログ及びフロー情報ログ）とに基づき、ドメイン名ごとの要求数とＩＰアドレスごとのフロー数との関係を示すフロー変換行列Ｈを推定する。本実施の形態では、グラフｇ１において、中間ノードを除くドメイン名のノード（すなわち、別名ではないノード）であるノードｎ１とノードｎ２とのそれぞれのトラヒック量を求めるためにそれぞれのフロー数を知りたいところ、フロー変換行列Ｈは、ノードｎ４とノードｎ５とにおいて既知であるフロー数が、ノードｎ１とノードｎ２とに対してどのように分配されるべきであるのかを推定するための行列である。なお、中間ノードを除くドメイン名のノードが１つである連結グラフ（例えば、図７の右側の上から２番目の連結グラフ及び上から４番目の連結グラフ）の場合、中間ノードを除くドメイン名のノードのフロー数は、ＩＰアドレスのノードのフロー数を単純に合算することで求めることが可能であるため、以降の処理は実行されなくてもよい。

【0054】

ステップＳ２０３において、フロー数分配推定部１６１は、グラフｇ１の各ノードに番号を割り振る。各ノードの番号が１つの連結グラフ内で重複しなければ、番号の割り振り方には制限が無い。

【0055】

図１０は、連結グラフの各ノードへの番号の割り振りを説明するための図である。図１０においては、ノードｎ１、ｎ２、ｎ３、ｎ４、ｎ５の順に、（１）、（２）、（３）、（４）、（５）の番号が割り振られた例が示されている。

【0056】

続いて、フロー数分配推定部１６１は、グラフｇ１を隣接行列Ａに変換する（Ｓ２０４）。隣接行列Ａの行数と列数は等しく、かつ、その行数及び列数は、ステップＳ２０３において割り振られた番号の個数（すなわち、グラフｇ１のノードの数）に等しい。

【0057】

図１１は、連結グラフに基づく隣接行列の一例を示す図である。図１１に示される隣接行列Ａにおいて、行方向がソース側（有向枝が出る側）であり、列方向がシンク側（有向枝が入る側）である。隣接行列Ａへの変換方法は、基本的には、一般に知られている汎用的な方法が利用されてよい。但し、本実施の形態において、隣接行列Ａは、一般的な隣接行列に対して以下の（ａ）及び（ｂ）に示される拡張がなされる。
（ａ）ノードｉからノードｊに有向枝が存在し，ノードｊの入次数がｎの場合，Ａ_ｉｊ＝１／ｎとする。
（ｂ）ノードｉの入次数が０の場合，ノードｉの対角成分であるＡ_ｉｉ＝１とする。

【0058】

なお、図１１において、０である成分の値は、便宜上、空欄とされている。

【0059】

例えば、Ａ_１３、Ａ_２３、Ａ_３４、及びＡ_３５の値は、上記（ａ）に基づいて割り当てられた値である。すなわち、Ａ_１３、Ａ_２３は、それぞれ、ノードｎ１からノードｎ３への有向枝、ノードｎ２からノードｎ３への有向枝に対応するが、ノードｎ３の入次数（ノードｎ３に入ってくる有向枝の数）は、２である。したがって、Ａ_１３及びＡ_２３の値は、１／２＝０．５となる。また、Ａ_３４、Ａ_３５は、それぞれ、ノードｎ３からノードｎ４への有向枝、ノードｎ３からノードｎ４への有向枝に対応するが、ノードｎ４及びノードｎ５のいずれについても入次数は１である。したがって、Ａ_１３及びＡ_２３の値は、１／１＝１となる。

【0060】

一方、Ａ_１１及びＡ_２２の値は、上記（ｂ）に基づいて割り当てられた値である。すなわち、ノードｎ１及びノードｎ２のいずれについても、入次数は０である。したがって、Ａ_１１及びＡ_２２の値は１とされている。

【0061】

続いて、フロー数分配推定部１６１は、グラフｇ１の最大ホップ長の数だけ隣接行列Ａを掛け合わせて、行列Ａ'を求める（ステップＳ２０５）。すなわち、フロー数分配推定部１６１は、Ａ'＝Ａ^ｎを演算する（ｎはグラフｇ１の最大ホップ長）。なお、隣接行列Ａをｎ乗ずる意義は、一般的なグラフ理論に詳しい。

【0062】

続いて、フロー数分配推定部１６１は、行列Ａ'から、グラフｇ１における中間ノードを除くドメイン名のノードに対応する行と、ＩＰアドレスのノードに対応する列との組み合わせに対応する成分を抽出する（ＳステップＳ２０６）。抽出された成分が構成する行列は、フロー変換行列Ｈの初期値Ｈ_ｉｎｉｔとされる。

【0063】

図１２は、フロー変換行列の初期値の抽出例を示す図である。図１２では、行列Ａ'における、（１）行及び（２）行と、（４）列及び（５）列との重複部分の成分が、初期値Ｈ_ｉｎｉｔとして抽出される例が示されている。

【0064】

続いて、フロー数分配推定部１６１は、初期値Ｈ_ｉｎｉｔと、グラフｇ１（図８）において初期値Ｈ_ｉｎｉｔの各行に対応するドメイン名のノードに付与されている要求数と、グラフｇ１において初期値Ｈ_ｉｎｉｔの各列に対応するＩＰアドレスに対応するノードに付与されているフロー数とに基づいて、フロー変換行列Ｈを推定する（ステップＳ２０７）。フロー変換行列Ｈは、当該要求数及び当該フロー数に含まれるノイズ等により一意に定まるものではないため、本実施の形態では、最適化問題を解くことにより、フロー変換行列Ｈの局所解が推定される。例えば、以下の式（１）は、最適化問題を解く場合の定式化の一例である。

【0065】

【数1】

ここで、||…||_Fは、フロベニウス・ノルムを表す。
また、αは、初期状態（初期値Ｈ_ｉｎｉｔ）の重視度を決めるパラメータである。すなわち、フロー変換行列Ｈについて、初期値Ｈ_ｉｎｉｔにできるだけ近い解を得たい場合に、αの値は大きくされる。

【0066】

更に、ベクトルＸは、グラフｇ１において初期値Ｈ_ｉｎｉｔの各列に対応するＩＰアドノード（ノードｎ４、ノードｎ５）に付与されているフロー数（Ｆ４、Ｆ５）である。ベクトルＹは、グラフｇ１において初期値Ｈ_ｉｎｉｔの各行に対応するドメイン名のノード（ノードｎ１、ノードｎ２）に付与されている要求数（Ｑ１、Ｑ２）である。

【0067】

すなわち、フロー変換行列Ｈは、ＩＰアドレスごとのフロー数を、ドメイン名ごとのフロー数に変換するための行列である。

【0068】

なお、最適化問題を解く場合、フロー変換行列Ｈの初期値は、任意の値であってもよい。例えば、全ての成分の値が０である行列が初期値とされてもよい。この場合、ステップＳ２０３〜Ｓ２０６は実行されなくてもよい。但し、本実施の形態のように、初期値Ｈ_ｉｎｉｔを求めることで、フロー変換行列Ｈについて、グラフｇ１の状態（すなわち、ＤＮＳ応答パケットやフロー情報の観測状態）に即した解が得られる可能性を高めることができる。その結果、ドメイン名ごとのトラヒック量の推定精度の向上を期待することができる。

【0069】

なお、式（１）は、最適化問題として解く場合の定式化の一例であり、式（１）からフロー変換行列Ｈに関する更新式を導出することで局所解を求めることができる。他の例として、ヒルクライム法等の最適化問題を解く方式が適用されてもよい（例えば、非特許文献６参照）。

【0070】

続いて、フロー数分配推定部１６１は、変数ｔの値が、グラフｇ１の中間ノードを除くドメイン名のノードの数に達したか否かを判定する（ステップＳ２０８）。変数ｔ１の値が該当ノードの数に達していない場合（ステップＳ２０８でＮｏ）、フロー数分配推定部１６１は、変数ｔに１を加算して（ステップＳ２０９）、ステップＳ２０２以降を繰り返す。すなわち、次のグラフ生成時期に関して、ステップＳ２０２以降が実行される。本実施の形態において、該当ノードの数は、ノードｎ１とノードｎ２との２つである。したがって、例えば、生成時期ｔ２に関してステップＳ２０２以降が実行され、生成時期ｔ２に対するフロー変換行列Ｈが生成される。

【0071】

このように、フロー変換行列Ｈは、グラフｇ１の中間ノードを除くドメイン名のノードの数だけ、グラフ生成時期が相互に異なるグラフ情報に基づいて生成される。例えば、本実施の形態では、グラフ生成時期ｔ１に対するフロー変換行列Ｈ１と、グラフ生成時期ｔ２に対するフロー変換行列Ｈ２とが生成される。この理由については後述される。

【0072】

ステップＳ２１０以降では、フロー変換行列Ｈ等が用いられて、トラヒック量算出部１６２によって、ドメイン名ごとのトラヒック量の推定値が算出される。

【0073】

ステップＳ２１０において、トラヒック量算出部１６２は、値が未知であるデータ（すなわち、値が推定されるべきデータ）、及び値が既知のデータ（すなわち、グラフｇ１の各ノードに属性情報として付与されているデータ）のそれぞれについて変数を定義する。本実施の形態では、以下のように変数が定義される。
［既知のデータ］
Ｒａ：各ＩＰアドレスのフロー毎バイト数
Ｓａ：各ＩＰアドレスのフロー数
Ｂａ：各ＩＰアドレスのバイト数
Ｓｄ：各ドメイン名のフロー数
なお、各ドメイン名のフロー数Ｓｄは、ＤＮＳログからは得られないものの、要求数で近似可能であるため、その値が代入される。
［未知のデータ］
Ｒｄ：各ドメイン名のフロー毎バイト数
Ｂｄ：各ドメイン名のバイト数
本実施の形態において、既知の各データの値は、以下の通りとなる。
Ｒａ＝（Ｂ４／Ｆ４，Ｂ５／Ｆ５）
Ｓａ＝（Ｆ４，Ｆ５）
Ｂａ＝（Ｂ４，Ｑ５）
Ｓｄ＝（Ｑ１，Ｑ２）
なお、グラフｇ１に関して、中間ノードを除くドメイン名のノードの数は２であるため、Ｒｄ及びＢｄの次元数は２である。

【0074】

続いて、トラヒック量算出部１６２は、各ドメインのフロー毎バイト数Ｒｄを未知変数として、フロー変換行列Ｈを用いてトラヒック量の推定式（２）を生成する（ステップＳ２１１）。

【0075】

【数2】

Ｒｄに含まれる未知変数の数は、各隣接行列の中間ノードを除くドメイン名の数と一致する。推定式（２）を展開することにより連立一次方程式が得られる。

【0076】

なお、連立一次方程式は、Ｒｄの次元数分生成される。具体的には、中間ノードを除くドメイン名のノードの数だけ生成されているフロー変換行列Ｈのそれぞれが用いられて、連立一次方程式が生成される。したがって、本実施の形態では、グラフ生成時期ｔ１とグラフ生成時期ｔ２とに対する以下の２つの連立一次方程式（３）が生成される。

【0077】

【数3】

連立一次方程式（３）において、Ｓｄ１、Ｈ１、Ｂａ１は、グラフ生成時期ｔ１に対応するＳｄ、フロー変換行列Ｈ、Ｂａである。Ｓｄ２、Ｈ２、Ｂａ２は、グラフ生成時期ｔ２に対応するＳｄ、フロー変換行列Ｈ、Ｂａである。このように、フロー変換行列、Ｓｄ、及びＢａは、グラフｇ１の中間ノードを除くドメイン名のノードの数分だけ必要となるため、ステップＳ２０２〜Ｓ２０７は、その数分繰り返されるのである。

【0078】

なお、ここでは、Ｒｄが時刻に対して不変であること又は変化が小さいことが仮定されている。斯かる仮定は、一般的に妥当であるものと考えられる。フロー毎バイト数は、サービスに依存するものであり、時刻に対する依存度は小さいと考えられるからである。例えば、動画サイトと単なるテキスト情報のサイトとを比較すれば、動画サイトの方がフロー毎バイト数が大きいと考えられ、その関係は、時刻に対して不変である可能性が高いと考えられる。したがって、本実施の形態は、フロー毎バイト数について、時刻に対する依存度が低い環境に対して好適である。

【0079】

続いて、トラヒック量算出部１６２は、連立一次方程式（３）を解くことで、Ｒｄを求める（ステップＳ２１２）。但し、観測されるＤＮＳ応答パケットやフロー情報のノイズの影響等によりＲｄは一意に定まらない場合が有る。その場合には、非特許文献６の局所解を求める方法が利用されてもよい。

【0080】

続いて、トラヒック量算出部１６２は、ステップＳ２１２において得られたＲｄに対して、Ｓｄを乗算することにより、Ｂｄを求める（ステップＳ２１３）。すなわち、以下の演算が実行される。

【0081】

【数4】

ここで、Ｂｄは、目的とする、ドメイン名ごとのトラヒック量である。

【0082】

なお、ドメイン名ごとのトラヒック量の推定方法として、上記以外の方法が採用されてもよい。例えば、非特許文献５のような最適化アルゴリズム等の要素技術が用いられてもよい。

【0083】

推定値変換部１７は、上記のように推定された、ドメイン名ごとのトラヒック量を、例えば、図１３に示されるような形式で出力する。

【0084】

図１３は、ドメイン名ごとのトラヒック量の推定結果の出力例を示す図である。図１３では、グラフｇ１の他に、グラフｇ２が示されている。グラフｇ２は、グラフｇ１と共に抽出された連結グラフであるとする。この場合、非中間ノードの４つのドメイン名について、トラヒック量が得られる。推定値変換部１７は、これらのトラヒック量を、例えば、テーブルＴ３に示される形式で可視化する。テーブルＴ３には、ドメイン名ごとに推定トラヒック量が示されている。なお、テーブルＴ３における行の配列順序は、推定トラヒック量によってソートされてもよい。すなわち、ドメイン名ごとの推定トラヒック量のランキングが出力されてもよい。出力形態は、所定のものに限定されない。例えば、表示装置に表示されてもよいし、プリンタに印刷されてもよい。又は、ネットワークを介して他のコンピュータに送信されてもよい。

【0085】

上述したように、第一の実施の形態によれば、統計化された入力データ（ＤＮＳログ及びフロー情報ログ）が、グラフ生成部１５によって有向グラフに変換され、その有向グラフの特性を活かしつつ、トラヒック量推定部１６によって、統計情報に基づいてドメイン名ごとのトラヒック量が推定される。これら一連の処理の中では、個々のユーザやパケット単位の紐付けは必要とされない。すなわち、本実施の形態では、各ＤＮＳ応答パケットと各フロー情報とを一つずつ紐付けるのではなく、ＤＮＳ応答パケットの統計情報と、フロー情報の統計情報とを関連付けることにより、ドメイン名ごとのトラヒック量が推定される。したがって、ＤＮＳ応答パケット及びフロー情報のそれぞれの収集場所や収集時刻の違いによりＤＮＳログとフロー情報のそれぞれの送信ユーザ群が異なるケースにおいても対応可能である。よって、ドメイン名ごとのトラヒック量の推定のための情報収集に関する制約を緩和することができる。

【0086】

その結果、例えば、ＤＮＳ応答パケットとフロー情報とを異なる場所及び時間で収集せざるを得ない制約が有る大規模ネットワークにおいて、運用者は、サービス単位のトラヒック量を容易に把握することができ、ネットワーク監視・運用コストの削減、回線輻輳時の原因の切り分けの迅速化、あるいはネットワークの設備投資の最適化等の応用的な効果を期待することができる。

【0087】

次に、第二の実施の形態について説明する。第二の実施の形態では第一の実施の形態と異なる点について説明する。第二の実施の形態において特に言及されない点については、第一の実施の形態と同様でもよい。

【0088】

第二の実施の形態でのトラヒック量算出部１６２は、は、図９のステップＳ２１１において、以下の推定式（４）を生成する。

【0089】

【数5】

すなわち、第二の実施の形態では、フロー変換行列Ｈは利用されない。したがって、図９のステップＳ２０１〜Ｓ２０８は実行されなくてもよい。また、図３の処理も実行されなくてもよい。この場合、グラフ生成時期ごとの連立一次方程式は、以下の通りとなる。

【0090】

【数6】

その他については、第一の実施の形態と同様でよい。

【0091】

第二の実施の形態は、十分な観測データ（ＤＮＳ応答パケット及びフロー情報）が蓄積されている場合に適用されることが好ましい。観測データが多ければ多いほど、フロー変換行列Ｈが利用されなくても、ドメイン名ごとのトラヒック量の推定精度の劣化が大きくなるのを回避できると可能性が高くなるからである。

【0092】

次に、第三の実施の形態について説明する。第三の実施の形態では第一又は第二の実施の形態と異なる点について説明する。第三の実施の形態において特に言及されない点については、第一又は第二の実施の形態と同様でもよい。

【0093】

図１４は、第三の実施の形態における推定装置の機能構成例を示す図である。図１４中、図２と同一部分には同一符号を付し、その説明は省略する。図１４において、推定装置１０は、更に、要求数補正部１８及びフロー情報補正部１９を有する。

【0094】

要求数補正部１８は、ＤＮＳログに含まれる要求数とＴＴＬとを用いて、クライアントによるサーバへのアクセス数又はフロー数を推定し、推定結果によって、ＤＮＳログ内の要求数を置き換える。すなわち、ＤＮＳログに含まれる要求数は、クライアントによるサーバへのアクセス数又はフロー数とは異なる。通常、ユーザがＷｅｂページを閲覧するなどして、あるＵＲＬ（Uniform Resource Locator）にアクセスする際には、当該ＵＲＬに含まれるドメイン名に対して名前解決が試みられる。但し、一般にユーザの端末にはＤＮＳ応答をキャッシュする仕組み（スタブリゾルバ）が存在するため、クライアントによるＷｅｂページへのアクセス数に対して、観測されるＤＮＳ応答パケットは大幅に少なくなる。

【0095】

そこで、要求数補正部１８は、ＴＴＬと要求数とを用いて、実際のサーバへのアクセス数を推定する。例えば、ＴＴＬによって特定される期間において行われた名前解決の回数を推定し、推定結果を当初の要求数に加算することで、当該要求数が補正されてもよい。

【0096】

したがって、第三の実施の形態において、図４に示されるＤＮＳ要求テーブルＴ１の要求数は、補正後の値となる。

【0097】

一方、フロー情報補正部１９は、フロー情報ログのフロー数、ユーザ数、及びバイト数を補正する。すなわち、ルータ等の一般的なネットワーク機器では、性能上の理由により定常的にサンプリングを行いながらフロー情報が収集される。例えば、１０００パケットごとに１パケットに関するフロー情報が収集される。このようにサンプリングされたフロー情報に基づくフロー数、ユーザ数、及びバイト数は、実際の値よりも小さいものとなる。

【0098】

そこで、フロー情報補正部１９は、サンプリング前のフロー数、ユーザ数、及びバイト数を推定し、推定結果によって、フロー情報ログの内容を補正する。例えば、サンプリングの割合に基づいて補正が行われてもよい。サンプリングの割合が１／１０００であれば、フロー数、ユーザ数、及びバイト数の値を１０００倍することにより、補正が行われてもよい。又は他の方法によって補正が行われてもよい。

【0099】

したがって、第三の実施の形態において、図４に示されるＤＮＳ応答テーブルＴ２の要求数は、補正後の値となる。

【0100】

上述したように、第三の実施の形態によれば、ＤＮＳログの要求数やフロー情報ログの値を実際の値に近づけることができるため、ドメイン名ごとのトラヒック量の推定精度の向上を期待することができる。

【0101】

なお、上記各実施の形態において、ＤＮＳ応答統計処理部１２は、第一の計測部の一例である。フロー情報統計処理部１４は、第二の計測部の一例である。グラフ生成部１５は、生成部の一例である。フロー数分配推定部１６１は、行列推定部の一例である。トラヒック量算出部１６２は、算出部の一例である。

【0102】

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0103】

１０ 推定装置
１１ ＤＮＳ応答収集部
１２ ＤＮＳ応答統計処理部
１３ フロー情報収集部
１４ フロー情報統計処理部
１５ グラフ生成部
１６ トラヒック量推定部
１７ 推定値変換部
１８ 要求数補正部
１９ フロー情報補正部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１２１ ＤＮＳログ記憶部
１２２ フロー情報記憶部
１２３ グラフ情報記憶部
１５１ グラフ変換部
１５２ 連結グラフ抽出部
１５３ 属性情報付与部
１６１ フロー数分配推定部
１６２ トラヒック量算出部
Ｂ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】