(57)【特許請求の範囲】
【請求項１】
各端末において発生する、ドメイン名に関する名前解決要求に関して当該ドメイン名のＴＴＬが経過していれば当該端末から送信されるＤＮＳクエリについての所定の期間の観測数の履歴に基づいて、前記ＴＴＬを算出する第１の算出部と、
第１の時刻の直前のＴＴＬ切れの時刻から前記第１の時刻までに名前解決要求が１回以上発生する確率に基づいて導出される関係式であって、単位時間あたりにおいて前記ドメイン名に係るサービスにアクセスする第１の端末の数と、前記単位時間あたりの前記サービスへの前記第１の端末ごとの平均アクセス数と、前記単位時間あたりのＤＮＳクエリ数との関係式に対して、前記履歴において前記ＴＴＬの１周期の期間における複数の時点のＤＮＳクエリ数を当てはめて、前記端末の数及び前記平均アクセス数を算出する第２の算出部と、
前記端末の数及び前記平均アクセス数に基づいて、前記所定の期間における前記サービスへのアクセス数の推定値を算出する第３の算出部と、
を有することを特徴とするアクセス数推定装置。
【請求項２】
前記第１の端末の数は、前記ＴＴＬ切れに従ってＤＮＳクエリを送信する第２の端末の数と、前記ＴＴＬ切れを無視してＤＮＳクエリを送信する第３の端末の数とを含み、
前記平均アクセス数は、前記第２の端末ごとの平均アクセス数と、前記第３の端末ごとの平均アクセス数とを含む、
ことを特徴とする請求項１記載のアクセス数推定装置。
【請求項３】
前記関係式は、ＤＮＳクエリ数をｆ（ｔ）、前記第２の端末の数をＮ、前記第２の端末ごとの平均アクセス数をｒ、前記第３の端末の数をＮ'、前記第３の端末ごとの平均アクセス数をｒ'とした場合に、
ｆ（ｔ）＝Ｎｒｅ−ｒ・ｍｏｄ（ｔ，ＴＴＬ）＋Ｎ'ｒ'
である、
ことを特徴とする請求項２記載のアクセス数推定装置。
【請求項４】
コンピュータが、
各端末において発生する、ドメイン名に関する名前解決要求に関して当該ドメイン名のＴＴＬが経過していれば当該端末から送信されるＤＮＳクエリについての所定の期間の観測数の履歴に基づいて、前記ＴＴＬを算出する第１の算出手順と、
第１の時刻の直前のＴＴＬ切れの時刻から前記第１の時刻までに名前解決要求が１回以上発生する確率に基づいて導出される関係式であって、単位時間あたりにおいて前記ドメイン名に係るサービスにアクセスする第１の端末の数と、前記単位時間あたりの前記サービスへの前記第１の端末ごとの平均アクセス数と、前記単位時間あたりのＤＮＳクエリ数との関係式に対して、前記履歴において前記ＴＴＬの１周期の期間における複数の時点のＤＮＳクエリ数を当てはめて、前記端末の数及び前記平均アクセス数を算出する第２の算出手順と、
前記端末の数及び前記平均アクセス数に基づいて、前記所定の期間における前記サービスへのアクセス数の推定値を算出する第３の算出手順と、
を実行することを特徴とするアクセス数推定方法。
【請求項５】
前記第１の端末の数は、前記ＴＴＬ切れに従ってＤＮＳクエリを送信する第２の端末の数と、前記ＴＴＬ切れを無視してＤＮＳクエリを送信する第３の端末の数とを含み、
前記平均アクセス数は、前記第２の端末ごとの平均アクセス数と、前記第３の端末ごとの平均アクセス数とを含む、
ことを特徴とする請求項４記載のアクセス数推定方法。
【請求項６】
前記関係式は、ＤＮＳクエリ数をｆ（ｔ）、前記第２の端末の数をＮ、前記第２の端末ごとの平均アクセス数をｒ、前記第３の端末の数をＮ'、前記第３の端末ごとの平均アクセス数をｒ'とした場合に、
ｆ（ｔ）＝Ｎｒｅ−ｒ・ｍｏｄ（ｔ，ＴＴＬ）＋Ｎ'ｒ'
である、
ことを特徴とする請求項５記載のアクセス数推定方法。
【請求項７】
請求項４乃至６いずれか一項記載のアクセス数推定方法をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセス数推定装置、アクセス数推定方法、及びプログラムに関する。
【背景技術】
【０００２】
近年、ネットワーク過負荷やトラヒックスパイクの要因を特定するために、サービス単位のトラヒック監視の必要性が高まっている。従来、トラヒック監視にはＮｅｔＦｌｏｗ（非特許文献１）等によるフロー計測技術が利用されている。しかし、近年普及が進むＯＴＴ（Over-The-Top）／ＣＤＮ（Contents Delivery Network）事業者は、ＩＰアドレスを複数サービスで共有するため、フロー情報に含まれるＩＰアドレスだけでは配信元のサービス名を一意に特定することが難しい。配信元サービスを識別する方法の一つに、ＤＰＩ（Deep Packet Inspection）による監視がある。しかし、ＤＰＩは暗号化された通信には適用ができないため、近年、ＯＴＴトラヒックを中心に普及が進む暗号化通信に対して適用できないという課題がある。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】Cisco Systems NetFlow Services Export Version9、［online］、［平成２７年７月１３日検索］、インターネット〈URL：http://www.ietf.org/rfc/rfc3954.txt〉
【非特許文献２】Domain Names: Implementation and Specification、［online］、［平成２７年７月１３日検索］、インターネット〈URL：https://www.ietf.org/rfc/rfc1035.txt〉
【非特許文献３】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.
【非特許文献４】"Inferring Relative Popularity of Internet Applications by Actively Querying DNS Caches", SIGCOMM, 2003、［online］、［平成２７年７月１３日検索］、インターネット〈URL：http://conferences.sigcomm.org/imc/2003/papers/p311-wills1.pdf〉
【非特許文献５】"Peeking Through The Cloud: DNS-based estimation and itsapplications", Applied Cryptography and Network Security", 2008、［online］、［平成２７年７月１３日検索］、インターネット〈URL：https://www.cs.jhu.edu/~moheeb/webpage_files/DNS.pdf〉
【発明の概要】
【発明が解決しようとする課題】
【０００４】
一方で、各サービスのドメイン名は、相互に異なる。そこで、ＤＮＳ（Domain Name System）（非特許文献２）ログを用いてサービス毎のアクセス数を推定する方式が提案されている（非特許文献３、非特許文献４、非特許文献５）。非特許文献３は、ＤＮＳログとフロー情報とを突合することでサービス毎の通信バイト数やアクセス数を計測する。しかし、非特許文献３は、ＤＮＳログに加えてフロー情報を別途収集し、かつ、両者を同一箇所で収集する必要があるため、適用網羅性に課題がある。
【０００５】
また、非特許文献４及び５は、ＤＮＳキャッシュサーバを用いてアクセス頻度を推定する方式を提案している。非特許文献４及び５は、測定装置からＤＮＳキャッシュサーバに能動的にパケットを送信し、その応答を観測することでＦＱＤＮ（Fully Qualified Domain Name）毎のアクセス頻度を推定する。しかし、非特許文献４及び５の手法は、測定の対象となるドメイン名に対して随時ＤＮＳキャッシュサーバにパケットを送信する必要があるため、多くのドメイン名を網羅的に監視することが難しく、測定網羅性及びリアルタイム性に課題がある。
【０００６】
本発明は、上記の点に鑑みてなされたものであって、ＤＮＳクエリのみを観測対象としてドメイン名ごとのアクセス数を推定することを目的とする。
【課題を解決するための手段】
【０００７】
そこで上記課題を解決するため、アクセス数推定装置は、各端末において発生する、ドメイン名に関する名前解決要求に関して当該ドメイン名のＴＴＬが経過していれば当該端末から送信されるＤＮＳクエリについての所定の期間の観測数の履歴に基づいて、前記ＴＴＬを算出する第１の算出部と、第１の時刻の直前のＴＴＬ切れの時刻から前記第１の時刻までに名前解決要求が１回以上発生する確率に基づいて導出される関係式であって、単位時間あたりにおいて前記ドメイン名に係るサービスにアクセスする第１の端末の数と、前記単位時間あたりの前記サービスへの前記第１の端末ごとの平均アクセス数と、前記単位時間あたりのＤＮＳクエリ数との関係式に対して、前記履歴において前記ＴＴＬの１周期の期間における複数の時点のＤＮＳクエリ数を当てはめて、前記端末の数及び前記平均アクセス数を算出する第２の算出部と、前記端末の数及び前記平均アクセス数に基づいて、前記所定の期間における前記サービスへのアクセス数の推定値を算出する第３の算出部と、を有する。
【発明の効果】
【０００８】
ＤＮＳクエリのみを観測対象としてドメイン名ごとのアクセス数を推定することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態におけるシステム構成例を示す図である。
【図２】トラヒック分析装置の機能を説明するための図である。
【図３】名前解決要求、ＤＮＳクエリ、及びアクセスの定義を説明するための図である。
【図４】本発明の実施の形態におけるアクセス数推定装置のハードウェア構成例を示す図である。
【図５】本発明の実施の形態におけるアクセス数推定装置の機能構成例を示す図である。
【図６】トラヒック分析装置が実行する処理手順の一例を説明するためのフローチャートである。
【図７】ＤＮＳログの一例を示す図である。
【図８】アクセス数推定装置が実行する第１の処理手順の一例を説明するためのフローチャートである。
【図９】ＦＱＤＮごとのグラフの一例を示す図である。
【図１０】アクセス数推定装置が実行する第２の処理手順の一例を説明するためのフローチャートである。
【発明を実施するための形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、内部ネットワークには、１以上のユーザ端末３０、トラヒック分析装置２０、及びアクセス数推定装置１０等が配置されている。また、外部ネットワークには、ＤＮＳキャッシュサーバ４０及び１以上のコンテンツサーバ５０が配置されている。内部ネットワークとは、例えば、或るＩＳＰ（Internet Service Provider）内のネットワーク（或るＩＳＰと当該ＩＳＰを介してインターネットに接続する各ユーザ端末３０との間のネットワーク）をいう。外部ネットワークは、例えば、ＩＳＰの外側のネットワークをいう。
【００１１】
ＤＮＳキャッシュサーバ４０は、例えば、ＩＳＰが管理するＤＮＳ（Domain Name System）キャッシュサーバである。ＤＮＳキャッシュサーバ４０は、ＤＮＳクエリにおいて問い合わされたドメイン名（ＦＱＤＮ（Fully Qualified Domain Name））に関する名前解決の結果（ＩＰアドレス等）を応答する。
【００１２】
コンテンツサーバ５０は、例えば、インターネット上において任意のサービス（例えば、コンテンツの配信サービス）を提供する１以上のコンピュータである。
【００１３】
各ユーザ端末３０は、ＰＣ（Personal Computer）、タブレット端末、又はスマートホン等である。各ユーザ端末３０は、１以上のアプリケーション３１及びスタブリゾルバ３２等を含む。アプリケーション３１は、コンテンツサーバ５０によって提供されるサービスにアクセスするプログラムである。アプリケーション３１の一例として、Ｗｅｂブラウザが挙げられる。例えば、サービスへのアクセスとは、コンテンツサーバ５０のホームページへのアクセスである。アプリケーション３１は、例えば、ユーザによって入力されるドメイン名（ＦＱＤＮ（Fully Qualified Domain Name））に係るサービスにアクセスするたびに、当該ＦＱＤＮに関する名前解決をスタブリゾルバ３２に要求し、名前解決結果に基づいて特定されるＩＰアドレス宛にアクセス（リクエストを送信）する。
【００１４】
スタブリゾルバ３２は、ＤＮＳクエリ送受信機能とＤＮＳキャッシュ機能とを実現するプログラムであり、例えば、ＯＳ（Operating System）又はＷｅｂブラウザ等に含まれている。ＤＮＳクエリ送受信機能とは、アプリケーション３１からの名前解決要求に応じたＤＮＳクエリをＤＮＳキャッシュサーバ４０に送信し、当該ＤＮＳクエリに対する応答を受信する機能をいう。ＤＮＳキャッシュ機能とは、過去のＤＮＳクエリに関する名前解決の結果を、所定期間キャッシュする機能をいう。
【００１５】
トラヒック分析装置２０は、各ユーザ端末３０によるトラヒックを分析し、当該トラヒックに関するログを記録するコンピュータである。
【００１６】
図２は、トラヒック分析装置の機能を説明するための図である。図２に示されるように、トラヒック分析装置２０は、外部ネットワーク上のコンピュータからユーザ端末３０に対して通信要求が有った場合には、当該通信要求をそのまま内部のユーザ端末３０へ通過させる。一方、トラヒック分析装置２０は、ユーザ端末３０から外部ネットワーク上のコンピュータに対して通信要求が有った場合には、当該通信要求の内容を分析した後に、当該通信要求をそのまま当該コンピュータへ通過させる。本実施の形態において、トラヒック分析装置２０は、各ユーザ端末３０からＤＮＳキャッシュサーバ４０に対するＡレコード又はＡＡＡＡレコードのＤＮＳクエリ（以下、単に「ＤＮＳクエリ」という。）の数を、予め定められた観測期間τにおいて、ＦＱＤＮごとに、任意の単位時間（Ｘ秒間隔（Ｘは観測対象のＦＱＤＮのＴＴＬ（Time To Live）より十分に小さい秒数））の間隔で集計する。トラヒック分析装置２０は、集計結果をＤＮＳログとして、例えば、予め定められた周期が到来するごとにアクセス数推定装置１０に送信する。なお、トラヒック分析装置２０は、ネットワーク回線上に挿入される形態で設置されてもよいし、タップやミラー等の方法によって外付される形態によって設置されてもよい。
【００１７】
本実施の形態における「名前解決要求」、「ＤＮＳクエリ」、及び「アクセス」という用語について明確に定義する。図３は、名前解決要求、ＤＮＳクエリ、及びアクセスの定義を説明するための図である。
【００１８】
図３に示されるように、名前解決要求は、アプリケーション３１からのスタブリゾルバ３２に対する、ＦＱＤＮに関する名前解決の要求である。ＤＮＳクエリは、アプリケーション３１からの名前解決要求に応じて、スタブリゾルバ３２がＤＮＳキャッシュサーバ４０に対して送信する、ＦＱＤＮに関する名前解決の要求である。アクセスは、名前解決の結果に基づいて、アプリケーション３１がコンテンツサーバ５０に対して送信するリクエスト等である。なお、名前解決要求の数（頻度）を、名前解決数といい、ＤＮＳクエリの数の観測値を、ＤＮＳクエリ数といい、アクセスの数（頻度）を、アクセス数という。
【００１９】
なお、ＤＮＳクエリ数は、トラヒック分析装置２０において記録されるＤＮＳログに基づいて特定可能（すなわち、観測可能）な値である。一方、名前解決要求数及びアクセス数は、名前解決結果についてのＦＱＤＮごとのＴＴＬに基づくスタブリゾルバ３２によるキャッシュの影響により、ＤＮＳにログに基づいて観測するのは困難である。
【００２０】
そこで、アクセス数推定装置１０は、トラヒック分析装置２０から送信されるＤＮＳログに含まれる、ＦＱＤＮ毎のＤＮＳクエリ数、及びＤＮＳログから求まる各ＦＱＤＮのＴＴＬを継続的に分析して、観測期間τにおける名前解決要求数を推定する。名前解決要求は、アクセスのたびに発生するため、アクセス数に一致するとみなすことができる。したがって、アクセス数推定装置１０は、名前解決要求数を推定することで、実質的に、観測期間τにおけるアクセス数を推定する。
【００２１】
アクセス数（名前解決要求数）の推定の理論は以下の通りである。或るユーザ端末３０が、ＤＮＳキャッシュサーバ４０に対して或るＦＱＤＮに関するＤＮＳクエリを送信した場合、ＤＮＳキャッシュサーバ４０は、その時刻における当該ＦＱＤＮのＴＴＬをユーザ端末３０に通知する。詳しくは、ＤＮＳキャッシュサーバ４０は、当該ＤＮＳキャッシュサーバ４０に対してＦＱＤＮに関するＤＮＳクエリを送信した各ユーザ端末３０に対して、当該ＤＮＳキャッシュサーバ４０が当該ＦＱＤＮに関して保持するＴＴＬと同一のＴＴＬを応答する。このため、同一のＤＮＳキャッシュサーバ４０を利用する全てのユーザ端末３０において、或るＦＱＤＮに関してＴＴＬが期限切れとなる時刻（ＴＴＬが経過する時刻）は等しくなる。また、各ユーザ端末３０は、スタブリゾルバ３２が当該ＦＱＤＮに関して保持するＴＴＬが期限切れとなるまでは、当該ＦＱＤＮに係るサービスにアクセスする必要があってもＤＮＳキャッシュサーバ４０に対して当該ＦＱＤＮに関するＤＮＳクエリを送信しない。
【００２２】
以上の挙動から、ユーザ端末３０が、ＤＮＳキャッシュサーバ４０に対して或るＦＱＤＮに関するＤＮＳクエリを送信する確率は、当該ユーザ端末３０のスタブリゾルバ３２が当該ＦＱＤＮに関して保持するＴＴＬを周期とし、ユーザ端末３０の当該ＦＱＤＮに係るサービスに対するアクセス数と、ユーザ端末３０がＦＱＤＮのキャッシュを保持する期間とを引数とした関数で与えられると考えられる。
【００２３】
ここで、ユーザ端末３０（スタブリゾルバ３２）から送信されるＤＮＳクエリの数は、アプリケーション３１からの名前解決要求数に必ずしも一致しない。上記したように、スタブリゾルバ３２は、アプリケーション３１からのＦＱＤＮの名前解決要求に基づいて送信したＤＮＳクエリに対してＤＮＳキャッシュサーバ４０から応答された名前解決結果を、当該ＦＱＤＮのＴＴＬの期間の間キャッシュするからである。換言すれば、スタブリゾルバ３２が存在しなければ、名前解決要求数と、ＤＮＳクエリ数と、アクセス数とは一致する。
【００２４】
すなわち、ユーザ端末３０のスタブリゾルバ３２が、或るＦＱＤＮの名前解決結果をキャッシュしており、当該ＦＱＤＮのＴＴＬが期限切れになるまでの間、当該ＦＱＤＮに関する名前解決要求がアプリケーション３１から発生しても、ユーザ端末３０からＤＮＳキャッシュサーバ４０に対してＤＮＳクエリは送信されない。一方で、ユーザ端末３０のスタブリゾルバ３２が名前解決結果をキャッシュしない場合は、名前解決要求数がＤＮＳクエリ数と一致する。
【００２５】
ここで、ＦＱＤＮ（に係るサービス）に対する、１つのユーザ端末３０の単位時間あたりのアクセス数の平均（以下、「平均アクセス数」という。）をｒとする。また、単位時間において、ＦＱＤＮ（に係るサービス）にアクセスするユーザ端末３０の数をＮとする。また、アプリケーション３１からの名前解決要求数がポアソン分布に従うと仮定する。また、時刻ｔを示す値（例えば、コンピュータにおいて時刻ｔを示す数値）をＴＴＬで除算した結果の余りをｍｏｄ（ｔ，ＴＴＬ）とする。そうすると、時刻ｔの直前のＴＴＬ切れの時刻から時刻ｔまでの間において、アプリケーション３１からの名前解決要求がｘ回発生する確率をＰ（ｘ）は、以下の式（１）で与えられる。
Ｐ（ｘ）＝（ｒｘｅ−ｒ．ｍｏｄ（ｔ，ＴＴＬ））／ｘ！  ・・・（１）
ここで、時刻ｔの直前のＴＴＬ切れの時刻から時刻ｔまでの間に、或るユーザ端末３０からＤＮＳキャッシュサーバ４０に対するＤＮＳクエリが観測される確率を求める。当該確率は、時刻ｔの直前のＴＴＬが切れた時刻から時刻ｔまでに、当該ユーザ端末３０のアプリケーション３１からの名前解決要求が１回以上発生している確率と同等である。時刻ｔの直前のＴＴＬ切れの時刻から時刻ｔまでの間にＤＮＳクエリが観測される確率をＱ（ｔ）とすると、Ｑ（ｔ）は、以下の式（２）で表される。
Ｑ（ｔ）＝１−Ｐ（０）＝１−ｅ−ｒ・ｍｏｄ（ｔ，ＴＴＬ）  ・・・（２）
よって、内部ネットワーク全体のＤＮＳクエリ数は、以下の式（３）で表すことができる。
ＮＱ（ｔ）＝Ｎ（１−ｅ−ｒ・ｍｏｄ（ｔ，ＴＴＬ））  ・・・（３）
ＤＮＳキャッシュサーバ４０へ送信されるＤＮＳクエリの単位時間あたりの数は、式（３）をｔで微分した値となる。そのため、ＤＮＳキャッシュサーバ４０で、時刻ｔ−単位時間から時刻ｔの間に観測されるＤＮＳクエリ数をｆ（ｔ）とすると、ｆ（ｔ）は、以下の式（４）で与えられる。
ｆ（ｔ）＝Ｎｒｅ−ｒ・ｍｏｄ（ｔ，ＴＴＬ）  ・・・（４）
実際には、ＴＴＬを無視し、ＴＴＬで指定された時間より短い時間でＤＮＳキャッシュサーバ４０に対してＤＮＳクエリを送信するユーザ端末３０が一定数存在することが考えられる。ＴＴＬを無視するユーザ端末３０は、一定の割合（単位時間あたりのＤＮＳクエリ数が一定）でＤＮＳクエリを送信すると仮定する。ここで、ＴＴＬに従うユーザ端末３０の数をＮ、単位時間あたりの平均アクセス数をｒとする。また、ＴＴＬを無視するユーザ端末３０の数をＮ'、単位時間あたりの平均アクセス数を一定のｒ'とすると、ＤＮＳキャッシュサーバ４０で、時刻ｔ−単位時間から時刻ｔの間に観測されるＤＮＳクエリ数を表す式として、以下の式（５）が導出される。
ｆ（ｔ）＝Ｎｒｅ−ｒ・ｍｏｄ（ｔ，ＴＴＬ）＋Ｎ'ｒ'  ・・・（５）
以上より、ＤＮＳキャッシュサーバ４０へのＤＮＳクエリ数に基づいて、ＦＱＤＮに係るサービスにアクセスするユーザ端末３０の数をＮ＋Ｎ'、単位時間あたりの平均アクセス数をＮｒ＋Ｎ'ｒ'として求めることができる。
【００２６】
但し、式（５）に基づいて各パラメータ（Ｎ，Ｎ'，ｒ，ｒ'）の値を得るのは実際には困難である。そこで、本実施の形態では、ＴＴＬ切れを考慮しないで、各パラメータの値を得ることを考える。そうすると、式（５）は、以下の式（６）に簡略化される。
【００２７】
ｆ（ｔ）＝Ｎｒｅ−ｒｔ＋Ｎ'ｒ'  ・・・（６）
ＴＴＬ切れを考慮しない状態は、ＴＴＬ切れが発生しない期間に当てはめる。ＴＴＬ切れが発生しない期間とは、ＴＴＬの１周期分の期間である。したがって、本実施の形態では、ＴＴＬの１周期分のＤＮＳログを式（６）に当てはめることで、各パラメータの値を得る。各パラメータの値は、連立方程式の構築や回帰分析等によって得られる。
【００２８】
なお、アクセス数推定装置１０及びトラヒック分析装置２０は、物理的に同一のコンピュータによって実装されてもよい。
【００２９】
また、本実施の形態において、ネットワークは、ＴＣＰ／ＩＰによるＩＰパケットネットワークであり、アドレスは、ＴＣＰ／ＩＰネットワークにおけるＩＰｖ４アドレス又はＩＰｖ６アドレスであり、分析の対象が、外部ネットワーク向けトラヒックである例を示すが、本実施の形態の適用範囲はこの例に限られない。
【００３０】
続いて、観測期間τにおけるＦＱＤＮごとのアクセス数を推定するアクセス数推定装置１０について具体的に説明する。
【００３１】
図４は、本発明の実施の形態におけるアクセス数推定装置のハードウェア構成例を示す図である。図４のアクセス数推定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００３２】
アクセス数推定装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００３３】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってアクセス数推定装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００３４】
図５は、本発明の実施の形態におけるアクセス数推定装置の機能構成例を示す図である。図５において、アクセス数推定装置１０は、ＤＮＳログ受信部１１、ＴＴＬ算出部１２、パラメータ算出部１３、及びアクセス数推定部１４等を有する。これら各部は、アクセス数推定装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。
【００３５】
ＤＮＳログ受信部１１は、トラヒック分析装置２０から送信されるＤＮＳログ（観測期間τに属するＤＮＳに対ログ）を受信する。ＴＴＬ算出部１２は、ＤＮＳログを分析することで、ＦＱＤＮごとにＴＴＬの推定値を算出する。パラメータ算出部１３は、式（５）（実際的には、式（６））に関する各パラメータの値（Ｎ，Ｎ'，ｒ，ｒ'）を算出する。アクセス数推定部１４は、各パラメータの値に基づいて、観測期間τにおけるＦＱＤＮごとのアクセス数を推定する。
【００３６】
以下、トラヒック分析装置２０及びアクセス数推定装置１０が実行する処理手順について説明する。図６は、トラヒック分析装置が実行する処理手順の一例を説明するためのフローチャートである。
【００３７】
トラヒック分析装置２０は、内部ネットワークのいずれかのユーザ端末３０からのトラヒックを受信すると（ステップＳ１０１）、当該トラヒックがＤＮＳクエリであるか否かを判定する（ステップＳ１０２）。当該トラヒックが、ＤＮＳクエリである場合（ステップＳ１０２でＹｅｓ）、トラヒック分析装置２０は、当該ＤＮＳクエリにおいて対象とされているＦＱＤＮに対する、現在時刻が属する単位時間（Ｘ秒）におけるＤＮＳクエリ数に対して１を加算する（ステップＳ１０３）。
【００３８】
ステップＳ１０１〜Ｓ１０３は、例えば、予め設定された送信時期が到来されるまで実行される。その後、当該送信時期が到来すると（ステップＳ１０４でＹｅｓ）、トラヒック分析装置２０は、例えば、前回の送信時期から今回の送信時期までに記録されたＤＮＳログを、アクセス数推定装置１０に送信する（ステップＳ１０５）。なお、ＤＮＳログの送信は、アクセス数推定装置１０からの要求に応じて行われてもよい。この場合、当該要求において指定された期間に属するＤＮＳログが送信されてもよい。
【００３９】
図７は、ＤＮＳログの一例を示す図である。図７に示されるように、ＤＮＳログは、ＦＱＤＮごとに、単位時間（Ｘ）ごとのＤＮＳクエリ数を含む。図７では、単位時間（Ｘ）が１秒である例が示されている。
【００４０】
続いて、アクセス数推定装置１０が実行する処理手順について説明する。図８は、アクセス数推定装置が実行する第１の処理手順の一例を説明するためのフローチャートである。なお、図８の処理は、観測値（ＤＮＳクエリ数）が、式（５）のモデルに一致する場合に有効な処理手順の一例である。図８においては、簡単のために、ｒ'＝ｒ（すなわち、ＴＴＬを無視するユーザ端末３０の平均アクセス数［１／ｓ］が、ＴＴＬに従うユーザ端末３０の平均アクセス数［１／ｓ］と同じ）であるとする。
【００４１】
ステップＳ２１０において、ＤＮＳログ受信部１１は、トラヒック分析装置２０から送信されたＤＮＳログを受信する。受信されたＤＮＳログは、観測期間τに属するものであるとする。
【００４２】
続いて、ＴＴＬ算出部１２は、受信されたＤＮＳログについて、ＦＱＤＮごとに、縦軸をＤＮＳクエリ数とし、横軸を時間とするグラフを生成する（ステップＳ２２０）。
【００４３】
図９は、ＦＱＤＮごとのグラフの一例を示す図である。図９には、図７に示したＦＱＤＮごとにグラフが示されている。
【００４４】
続いて、ＴＴＬ算出部１２は、各グラフについて周期性の有無を判定する（ステップＳ２３０）。周期性の有無の判定は、公知の方法を用いて行われればよい。グラフに周期性が無いＦＱＤＮについては（Ｓ２３０でＮｏ）、ステップＳ２４０以降の処理は実行されない。グラフに周期性が有るＦＱＤＮごとに（Ｓ２３０でＹｅｓ）、ステップＳ２４０以降が実行される。以下の説明では、一つのＦＱＤＮを処理対象として説明する。当該ＦＱＤＮを、「対象ＦＱＤＮ」という。
【００４５】
ステップＳ２４０において、ＴＴＬ算出部１２は、対象ＦＱＤＮのＴＴＬの推定値を算出する。当該推定値は、対象ＦＱＤＮのグラフにおいて、スパイク（ＤＮＳクエリ数が最大値となる位置）の間隔を求めることで得ることができる。例えば、ＦＱＤＮ３については、ＴＴＬ＝１５［ｓ］となる。
【００４６】
続いて、パラメータ算出部１３は、目的変数をＤＮＳクエリ数とし、説明変数をＮ、Ｎ'、ｒ、ｒ'として式（６）を用いて回帰分析を適用して、Ｎ，ｒ，Ｎ'，ｒの値を算出する（ステップＳ２５０）。この際、ステップＳ２４０において算出されたＴＴＬの１周期分のＤＮＳログに含まれるＤＮＳクエリ数がｆ（ｔ）に適用される。すなわち、式（６）は、式（５）について、ＴＴＬ切れを考慮しない場合の式であるため、ＴＴＬについて１周期分のサンプルデータ（ＤＮＳクエリ数）が利用される。なお、ＤＮＳクエリ数について、移動平均等のスムージングが行われ、スムージングが行われた後のＤＮＳクエリ数が回帰分析に用いられてもよい。例えば、或る時刻ｔのＤＮＳクエリ数を、当該時刻ｔに隣接する前後のＤＮＳクエリ数との平均値によってスムージングする場合、例えば、時刻ｔ２のＤＮＳクエリ数は、時刻ｔ１、時刻ｔ２、及び時刻ｔ３のＤＮＳクエリ数の平均値とされてもよい。
【００４７】
続いて、アクセス数推定部１４は、ステップＳ２５０において算出された各パラメータの値を、以下の式に当てはめることで、観測期間τにおける対象ＦＱＤＮに対するアクセス数の推定値を算出する（ステップＳ２６０）
アクセス数＝（Ｎｒ＋Ｎ'ｒ'）τ÷Ｘ
ここで、τは、観測期間τの秒数である。また、Ｘは、単位時間（秒）である。
【００４８】
なお、上記では、式（５）（式（６））の各パラメータの値の算出において回帰分析が利用される例が示されたが、連立方程式を利用して、当該各パラメータの値の算出が試行されてもよい。
【００４９】
図１０は、アクセス数推定装置が実行する第２の処理手順の一例を説明するためのフローチャートである。図１０中、図８と同一ステップには同一ステップ番号を付し、その説明は省略する。図１０では、ステップＳ２４１〜Ｓ２４５が追加されている。
【００５０】
ステップＳ２４１について、パラメータ算出部１３は、ステップＳ２４０において算出されたＴＴＬの１周期分のＤＮＳログ数のうちのＮ個（すなわち、対象ＦＱＤＮに対応するグラフにおいてＴＴＬの１周期内の複数の時点のＤＮＳクエリ数の値）をサンプリングし、式（６）に当てはめることで、連立方程式を生成する。例えば、Ｎ＝３であれば、ｔ＝１、ｔ＝２、ｔ＝３の３点がサンプリングされ、各点のＤＮＳクエリ数ｆ（１）、ｆ（２）、ｆ（３）をそれぞれ、ｑ１、ｑ２、ｑ３とすると、以下のような連立方程式が生成される。
Ｎｒ＋Ｎ'ｒ＝ｑ１
Ｎｒｅ−ｒ＋Ｎ'ｒ＝ｑ２
Ｎｒｅ−２ｒ＋Ｎ'ｒ＝ｑ３
なお、ここでは、ｒ＝ｒ'であるため、連立方程式において、ｒ'は、ｒに置き換えられている。
【００５１】
続いて、パラメータ算出部１３は、ｒについて連立方程式を解く（ステップＳ２４２）。上記の連立方程式をｒについて解くと、以下の式が得られる。
ｒ＝−ｌｏｇ（（ｑ２−ｑ３）／（ｑ１−ｑ２））
ここで、ｑ１、ｑ２、ｑ３は、いずれもＤＮＳログから取得可能な観測値（ＤＮＳクエリ数）であるため、ｒの値が求まる。例えば、ｑ１＝８００、ｑ２＝７６２、ｑ３＝７２７であるとすると、ｒ＝０．１となる。なお、ここでのｑ１、ｑ２、ｑ３の値は、便宜上、図７とは無関係な値である。
【００５２】
続いて、パラメータ算出部１３は、ｒの値を３つの方程式に代入し、式変形をすることにより、Ｎ及びＮ'のそれぞれの値を算出する（ステップＳ２４３）。上記の例では、Ｎ＝４０００、Ｎ'＝１０００が求まる。
【００５３】
続いて、パラメータ算出部１３は、連立方程式が厳密に解けたか否かを判定する（ステップＳ２４５）。すなわち、ＤＮＳクエリ数の推移を示すグラフの形状やＤＮＳクエリ数の観測値に誤差が含まれるケースにおいては、連立方程式が厳密に解けない場合がある。したがって、連立方程式が厳密に解けなかった場合には（ステップＳ２４５でＮｏ）、パラメータ算出部１３は、図８おいて説明したように、ステップＳ２５０以降を実行する。
【００５４】
一方、連立方程式が解けた場合（ステップＳ２４５でＹｅｓ）、ステップＳ２６０に進む。
【００５５】
なお、上記では、ｒとｒ'が等しい場合について説明したが、ｒとｒ'とが異なる場合には、時系列から収集するサンプリングの数を増やし、回帰分析等を利用して各パラメータの値が推定されてもよい。
【００５６】
また、ＴＴＬに従うユーザ端末３０のみを考慮する場合には、式（５）及び式（６）の第２項であるＮ'ｒ'は、α等の１つの変数（ノイズ項）と考えることで、各パラメータの値が推定されてもよい。
【００５７】
上述したように、本実施の形態によれば、ＤＮＳクエリのみを観測対象としてＦＱＤＮごとのアクセス数を推定することができる。したがって、例えば、ＤＮＳキャッシュサーバ−権威サーバ間のＤＮＳトラヒックのみ観測可能な状況であっても、ＦＱＤＮごとのアクセス数（例えば、動画視聴頻度など）を推定することができる。
【００５８】
なお、本実施の形態において、ＴＴＬ算出部１２は、第１の算出部の一例である。パラメータ算出部１３は、第２の算出部の一例である。アクセス数推定部１４は、第３の算出部の一例である。式（５）又は式（６）は、関係式の一例である。ＤＮＳログは、ＤＮＳクエリについての所定期間の観測数の履歴の一例である。
【００５９】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００６０】
１０          アクセス数推定装置
１１          ＤＮＳログ受信部
１２          ＴＴＬ算出部
１３          パラメータ算出部
１４          アクセス数推定部
２０          トラヒック分析装置
３０          ユーザ端末
３１          アプリケーション
３２          スタブリゾルバ
４０          ＤＮＳキャッシュサーバ
５０          コンテンツサーバ
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
Ｂ            バス
【図１】
0006387332.tif 000002
【図２】
0006387332.tif 000003
【図３】
0006387332.tif 000004
【図４】
0006387332.tif 000005
【図５】
0006387332.tif 000006
【図６】
0006387332.tif 000007
【図７】
0006387332.tif 000008
【図８】
0006387332.tif 000009
【図９】
0006387332.tif 000010
【図１０】
0006387332.tif 000011