(57)【要約】【課題】DNSトラヒックに基づくサービス毎のアクセス数推定の負荷を軽減する。【解決手段】通信ネットワークにおけるサービスに対するユーザのアクセス数を推定するアクセス数推定装置は、DNS（Domain Name System）クエリを一定の時間間隔でドメイン毎に集計し、通信ログに記録するDNSクエリ集計部と、前記通信ログから算出されるドメイン毎の累計クエリ数、最大TTL（Time-To-Live）及び潜在ユーザ数を用いて表したモデル式に基づき、ドメイン毎のアクセス数を推定するアクセス数推定部と、前記ドメイン毎のアクセス数を出力する出力部とを有する。【選択図】図３
2018032965.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークにおけるサービスに対するユーザのアクセス数を推定するアクセス数推定装置であって、
DNS（Domain Name System）クエリを一定の時間間隔でドメイン毎に集計し、通信ログに記録するDNSクエリ集計部と、
前記通信ログから算出されるドメイン毎の累計クエリ数、最大TTL（Time-To-Live）及び潜在ユーザ数を用いて表したモデル式に基づき、ドメイン毎のアクセス数を推定するアクセス数推定部と、
前記ドメイン毎のアクセス数を出力する出力部と、
を有するアクセス数推定装置。
【請求項２】
前記DNSクエリ集計部は、所定の第１の期間に観測されたTTL値の最大値を、前記最大TTLとして前記通信ログに記録し、所定の第２の期間において観測された送信元アドレスのユニーク個数を、前記潜在ユーザ数として前記通信ログに記録する、請求項１に記載のアクセス数推定装置。
【請求項３】
前記アクセス数推定部は、前記DNSクエリを集計する時間間隔をtとし、前記累計クエリ数をQ'd(t)とし、前記最大TTLをτdとし、前記潜在ユーザ数をNdとした場合、ドメイン毎のアクセス数Fdを
【数９】
2018032965.tif 000014
で表したモデル式に基づいて算出する、請求項１又は２に記載のアクセス数推定装置。
【請求項４】
前記累計クエリ数、前記潜在ユーザ数、前記最大TTL及び前記DNSクエリを集計する時間間隔に基づいて、アクセス数の推定精度を判断する推定精度判断部を更に有する、請求項１乃至３のうちいずれか１項に記載のアクセス数推定装置。
【請求項５】
前記推定精度判断部は、前記DNSクエリを集計する時間間隔を変更することにより、前記アクセス数の推定精度を調整する、請求項４に記載のアクセス数推定装置。
【請求項６】
通信ネットワークにおけるサービスに対するユーザのアクセス数を推定するアクセス数推定装置におけるアクセス数推定方法であって、
DNS（Domain Name System）クエリを一定の時間間隔でドメイン毎に集計し、通信ログに記録するステップと、
前記通信ログから算出されるドメイン毎の累計クエリ数、最大TTL（Time-To-Live）及び潜在ユーザ数を用いて表したモデル式に基づき、ドメイン毎のアクセス数を推定するステップと、
前記ドメイン毎のアクセス数を出力するステップと、
を有するアクセス数推定方法。
【請求項７】
通信ネットワークにおけるサービスに対するユーザのアクセス数を推定するアクセス数推定装置として、コンピュータを機能させるためのプログラムであって、当該コンピュータを、
DNS（Domain Name System）クエリを一定の時間間隔でドメイン毎に集計し、通信ログに記録するDNSクエリ集計手段、
前記通信ログから算出されるドメイン毎の累計クエリ数、最大TTL（Time-To-Live）及び潜在ユーザ数を用いて表したモデル式に基づき、ドメイン毎のアクセス数を推定するアクセス数推定手段、及び
前記ドメイン毎のアクセス数を出力する出力手段、
として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセス数推定装置、アクセス数推定方法、及びプログラムに関する。
【背景技術】
【０００２】
近年、インターネット・トラヒックを扱う通信事業者等において、ネットワークの輻輳による通信品質の劣化を回避するため、ネットワークの状況を逐次監視し、適切な通信制御や設備計画を行う必要性が生じている。
【０００３】
ネットワークの状況を監視する代表的な手法として、NetFlow（非特許文献１）等によるフロー計測技術やDPI（Deep Packet Inspection）によるトラヒック収集・分析方式が存在する。
【０００４】
フロー計測技術はIP（Internet Protocol）アドレスに基づき通信元を識別する。しかし、単一のIPアドレスから複数種類のサービスを同時配信するCDN（Contents Delivery Network）事業者経由の配信トラヒックではサービス毎の利用状況を可視化することができない。
【０００５】
一方のDPIは通信のアプリケーションにおけるヘッダ情報を参照することで通信のサービスを識別する。しかし、DPI装置のコストは高いため通信トラヒック量が多い通信事業者では網羅的な監視が困難である。さらにDPIは通信におけるデータ格納領域（ペイロード）を参照する方式であるため、ネットワーク事業者によってはサービス約款等により実施困難なケースがあり得る。
【０００６】
上記を解決するために、DNS（Domain Name System）（非特許文献２）の通信ログを用いてサービス毎のアクセス数を推定する方式が提案されている（非特許文献３）。この方式はDPIを用いて通信トラヒックを収集するものの、収集対象の通信種別はDNSトラヒックに限定される。非特許文献３はユーザ端末のOS（Operating System）あるいはブラウザに搭載されたDNS問い合わせをキャッシュする機構（以下、スタブリゾルバ）を数理的にモデル化することで、ユーザからDNSキャッシュサーバ宛ての秒毎のクエリ数の時系列を観測し、さらにユーザ毎に利用するDNSキャッシュサーバが異なるケースへの対応として、ユーザ毎にDNSドメイン毎のTTL（Time-To-Live）時間を記録し補正することで、DNSトラヒックでは従来推定困難であったユーザのアクセス数を推定可能にする。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】Cisco Systems NetFlow Services Export Version9, インターネット（URL：http://www.ietf.org/rfc/rfc3954.txt）, ［平成２８年７月２８日検索］
【非特許文献２】Domain Names: Implementation and Specification, インターネット（URL：https://www.ietf.org/rfc/rfc1035.txt）, ［平成２８年７月２８日検索］
【非特許文献３】A. Shimoda, K. Ishibashi, K. Sato, M. Tsujino, T. Inoue, M. Shimura, T. Takebe, K. Takahashi, T. Mori, and S. Goto, "Inferring Popularity of Domain Names with DNS Traffic: Exploiting Cache Timeout Heuristics," Proceedings of the IEEE Global Communications Conference (GLOBECOM 2015), December 2015, San Diego CA, US.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、非特許文献３の方式は次の２つの課題が存在する。
【０００９】
まず第１の課題について説明する。非特許文献３の手法は、各ドメインにおけるTTL時間内に観測されたクエリ数時系列の減衰カーブをモデルにフィッティングさせる必要があるため、TTLに対して十分に小さい間隔でクエリ数のログを測定する必要がある。
【００１０】
通信事業者では長期間の通信ログを保全するにあたり、データ記憶容量や分析リソースの都合により、一定の長さの時間間隔（例：5分毎）でログを記録する場合がある。推定対象のドメインのTTLが十分に大きい（例：6時間）の場合は、5分毎に取得したログを用いてモデルへのフィッティングが可能であるが、近年増加しているTTLが短いドメイン（例：20秒）では、TTL未満の短い間隔でログを取得していなければフィッティングが難しい。加えて、ログの収集間隔を短くする場合は、ログの収集、分析、蓄積のコストが増大する。
【００１１】
次に第２の課題について説明する。近年の大規模なDNSキャッシュサーバ（例: Google Public DNS、ISP（Internet Service Provider）のキャッシュサーバ）では、サーバの負荷分散を目的として、一つの仮想的なサーバIPアドレスをユーザに公開した上で、その仮想のIPアドレスの配下に複数のDNSキャッシュサーバを配置した上で、ロードバランサ（負荷分散装置）を用いてDNSクエリをパケット単位でランダムに複数のDNSキャッシュサーバに振り分けるサーバ形態が増加している。
【００１２】
上記のロードバランス構成を持つDNSキャッシュサーバにおいては、ユーザ毎にそれぞれ異なるDNSキャッシュサーバにクエリが配送される可能性がある。その場合、各ユーザ同士においてキャッシュ切れのタイミングが同期しなくなり、クエリ数時系列の指数減衰カーブが観測されないケースがある。非特許文献３はその対処として、ユーザ毎にDNSドメイン毎の最終応答TTLを記録する方式を採用する。しかし、該方式は、ユーザ数が数十万、数百万以上の規模である場合に、分析に必要なメモリサイズが巨大となり、汎用分析装置のメモリでは扱うことが困難となる課題がある。
【００１３】
上述のように、従来技術では、クエリ数時系列の減衰カーブをモデルにフィッティングするため、短い間隔でクエリ数ログの収集を行う必要があった。さらに、ロードバランス構成を持つDNSキャッシュサーバにおいては、ユーザ間でキャッシュ切れ時刻が同期しないことから、フィッティング対象となる指数減衰曲線の補正を行う必要があった。これらのことから、従来技術ではアクセス数推定の負荷が大きく、大規模なユーザ数への適用が困難であった。
【００１４】
本発明は上記の課題を鑑みてなされたものであり、DNSトラヒックに基づくサービス毎のアクセス数推定の負荷を軽減することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の一形態に係るアクセス数推定装置は、
通信ネットワークにおけるサービスに対するユーザのアクセス数を推定するアクセス数推定装置であって、
DNS（Domain Name System）クエリを一定の時間間隔でドメイン毎に集計し、通信ログに記録するDNSクエリ集計部と、
前記通信ログから算出されるドメイン毎の累計クエリ数、最大TTL（Time-To-Live）及び潜在ユーザ数を用いて表したモデル式に基づき、ドメイン毎のアクセス数を推定するアクセス数推定部と、
前記ドメイン毎のアクセス数を出力する出力部と、
を有することを特徴とする。
【００１６】
また、本発明の一形態に係るアクセス数推定方法は、
通信ネットワークにおけるサービスに対するユーザのアクセス数を推定するアクセス数推定装置におけるアクセス数推定方法であって、
DNS（Domain Name System）クエリを一定の時間間隔でドメイン毎に集計し、通信ログに記録するステップと、
前記通信ログから算出されるドメイン毎の累計クエリ数、最大TTL（Time-To-Live）及び潜在ユーザ数を用いて表したモデル式に基づき、ドメイン毎のアクセス数を推定するステップと、
前記ドメイン毎のアクセス数を出力するステップと、
を有することを特徴とする。
【００１７】
また、本発明の一形態に係るプログラムは、
通信ネットワークにおけるサービスに対するユーザのアクセス数を推定するアクセス数推定装置として、コンピュータを機能させるためのプログラムであって、当該コンピュータを、
DNS（Domain Name System）クエリを一定の時間間隔でドメイン毎に集計し、通信ログに記録するDNSクエリ集計手段、
前記通信ログから算出されるドメイン毎の累計クエリ数、最大TTL（Time-To-Live）及び潜在ユーザ数を用いて表したモデル式に基づき、ドメイン毎のアクセス数を推定するアクセス数推定手段、及び
前記ドメイン毎のアクセス数を出力する出力手段、
として機能させることを特徴とする。
【発明の効果】
【００１８】
本発明によれば、DNSトラヒックに基づくサービス毎のアクセス数推定の負荷を軽減することが可能になる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態におけるシステム構成例を示す図である。
【図２】トラヒック分析装置の機能を説明するための図である。
【図３】本発明の実施の形態におけるトラヒック収集装置及びアクセス数推定装置の機能構成例を示す図である。
【図４】DNSクエリ集計部における処理手順を示すフローチャートである。
【図５】アクセス数推定部及びログ出力部における処理手順を示すフローチャートである。
【図６】従来技術におけるアクセス数の推定の概要を示す図である。
【図７】本発明の実施の形態におけるアクセス数の推定の概要を示す図である。
【図８】本発明の実施の形態におけるアクセス数推定装置のハードウェア構成例を示す図である。
【発明を実施するための形態】
【００２０】
以下、図面に基づいて本発明の実施の形態を説明する。本発明の実施の形態では、通信ネットワークにおけるサービスに対するユーザのアクセス数を推定するアクセス数推定装置について説明する。本発明の実施の形態にかかるアクセス数推定装置は、ある一定期間に観測されたDNSクエリ数の統計値を用いてアクセス数を推定可能にすることで非特許文献３における第１の課題を解決し、かつユーザ毎のDNS応答情報の保持を不要とすることで非特許文献３における第２の課題を解決する。
【００２１】
まず、本発明の実施の形態で用いる各用語を以下のように定義する。
【００２２】
「通信」または「トラヒック」の各用語は、いずれも「通信トラヒック」と同義であり、ネットワーク上を流れる通信データを指す。
【００２３】
「ユーザ」とは、ネットワークにおけるサーバ、クライアント間通信のクライアントを指す。「ユーザ」は通信の利用者そのものを指す場合（例：ユーザ端末）と、通信事業者等のインターネット側から見たクライアントのIPアドレスを指す場合（例：ユーザIPアドレス）がある。
【００２４】
「DNS（Domain Name System）」は、ドメイン名から、対応するIPアドレスを検索（名前解決）するための一連のプロトコルおよびサービスである。DNSクエリとは、ユーザがDNSキャッシュサーバに対して、あるドメインの名前解決要求を送信する際の要求パケットを指す。DNS応答とは、DNSクエリに対して、DNSキャッシュサーバがユーザに応答を返す際のパケットを指す。
【００２５】
「スタブリゾルバ」とはユーザのOSやブラウザ上に実装されたDNSキャッシュ機能を表す。スタブリゾルバ上にはキャッシュテーブルが存在し、過去の名前解決要求の応答パケットに含まれるTTL（Time-To-Live）の秒数だけ、ドメインとIPアドレスの対応関係を保持し、TTLの時間が経過すると、キャッシュ切れ（後述）により該対応関係が破棄される。
【００２６】
「キャッシュ切れ」とは、各ユーザがスタブリゾルバ上で保持するドメイン毎のDNSキャッシュが無効化されることを指す。具体的には、スタブリゾルバがDNSキャッシュサーバからの応答に基づき、あるドメインのDNSキャッシュを生成後、該ドメインのTTLがキャッシュテーブルでカウントダウンされ、TTL値が0になったタイミングでキャッシュ切れが発生する。通常、あるドメインでキャッシュ切れを起こすと、次の該ドメインに対するアクセスが発生した際に、DNSクエリがキャッシュサーバに送信される。
【００２７】
「アクセス」並びに「アクセス数」とは、ユーザ端末にて名前解決（DNSを用いてドメイン名から対応するIPアドレスを取得する処理）を必要とする通信の発生、ないしはその回数を表す。
【００２８】
図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、内部ネットワークには、１以上の内部ホスト３０、トラヒック収集装置２０、及びアクセス数推定装置１０等が配置されている。なお、トラヒック収集装置２０及びアクセス数推定装置１０は、１つのアクセス数推定装置として同一の汎用計算装置（例：汎用サーバ）上に実装することも、あるいはそれぞれ別の装置に切り離すこともできる。また、外部ネットワークには、１以上のDNSキャッシュサーバ４０及び１以上のコンテンツサーバ５０が配置されている。内部ネットワークとは、例えば、或るISP内のネットワーク（或るISPと当該ISPを介してインターネットに接続する各内部ホスト３０との間のネットワーク）をいう。外部ネットワークは、例えば、ISPの外側のネットワークをいう。
【００２９】
DNSキャッシュサーバ４０は、例えば、ISPが管理するDNSキャッシュサーバである。DNSキャッシュサーバ４０は、DNSクエリにおいて問い合わされたドメイン名（FQDN（Fully Qualified Domain Name））に関する名前解決の結果（IPアドレス等）を応答する。
【００３０】
コンテンツサーバ５０は、例えば、インターネット上において任意のサービス（例えば、コンテンツの配信サービス）を提供する１以上のコンピュータである。
【００３１】
各内部ホスト３０は、コンテンツサーバからサービス提供を受けるホスト端末であり、PC（Personal Computer）、タブレット端末、又はスマートフォン等のユーザ端末でもよい。各内部ホスト３０は、１以上のアプリケーション３１及びスタブリゾルバ３２等を含む。アプリケーション３１は、コンテンツサーバ５０によって提供されるサービスにアクセスするプログラムである。アプリケーション３１の一例として、Webブラウザが挙げられる。例えば、サービスへのアクセスとは、コンテンツサーバ５０のホームページへのアクセスである。アプリケーション３１は、例えば、ユーザによって入力されるドメイン名（FQDN（Fully Qualified Domain Name））に係るサービスにアクセスするたびに、当該FQDNに関する名前解決をスタブリゾルバ３２に要求し、名前解決結果に基づいて特定されるIPアドレス宛にアクセス（リクエストを送信）する。
【００３２】
スタブリゾルバ３２は、DNSクエリ送受信機能とDNSキャッシュ機能とを実現するプログラムであり、例えば、OS（Operating System）又はWebブラウザ等に含まれている。DNSクエリ送受信機能とは、アプリケーション３１からの名前解決要求に応じたDNSクエリをDNSキャッシュサーバ４０に送信し、当該DNSクエリに対する応答を受信する機能をいう。DNSキャッシュ機能とは、過去のDNSクエリに関する名前解決の結果を、所定期間キャッシュする機能をいう。
【００３３】
＜トラヒックの収集＞
トラヒック収集装置２０は、各内部ホスト３０によるトラヒックを収集し、当該トラヒックに関するログを記録するコンピュータ等の装置である。トラヒック収集装置２０は、ユーザとDNSキャッシュサーバ４０との間のDNSトラヒックを含む通信ログを収集し蓄積する。トラヒック収集装置２０はネットワーク回線上に挿入される形態、ないしはタップやミラーなどの方法によって外付けされる形態によって設置される。通信ログの収集箇所は、ユーザとDNSキャッシュサーバ４０との間の通信を含む条件を満たせば特に限定されないが、DNSキャッシュサーバ４０内もしくはネットワークのゲートウェイ装置における通信ログの収集を想定する。図１はネットワークのゲートウェイ装置における通信ログ収集の形態の例である。
【００３４】
図２は、トラヒック収集装置２０の機能を説明するための図である。図２に示されるように、トラヒック収集装置２０は内部ネットワークと外部ネットワークとの間の通信に影響しないようにしながら、内部ネットワークと外部ネットワークとの間の通信トラヒックから、ユーザからDNSキャッシュサーバに対するDNSクエリ（以下、クエリ）を抽出し、その統計情報である通信ログを、トラヒック収集装置２０上の通信ログDBに記録する。収集対象とするDNSクエリの種類は主にAレコードまたはAAAAレコードであるが、他のレコードタイプにも適用可能である。通信ログは、任意の時間間隔ΔT（例えば、ΔT=5分）毎に集計される。トラヒック収集装置２０により収集された通信ログは、アクセス数推定装置１０によって分析される。
【００３５】
図３は、本発明の実施の形態におけるトラヒック収集装置及びアクセス数推定装置の機能構成例を示す図である。トラヒック収集装置２０はDNSクエリ集計部２１および推定精度判断部２３で構成される。なお、DNSクエリ集計部２１はアクセス数推定装置１０に含まれてもよく、トラヒック収集装置２０は単にDNSクエリを収集し、収集したDNSクエリをアクセス数推定装置１０によって集計することも可能である。また、推定精度判断部２３もアクセス数推定装置１０に含まれてもよい。推定精度判断部２３については「推定条件と精度の確認方法」の節で述べる。
【００３６】
DNSクエリ集計部２１により、一定の観測期間（T）毎に、DNSドメイン（以下、ドメイン）毎に以下のDNSクエリの統計値が収集されるものとする。
【００３７】
【表１】
2018032965.tif 000003
ここで、ドメイン名は、ユーザがDNSに問い合わるドメイン名である。
【００３８】
クエリ数は、該ドメインにおけるユーザからDNSキャッシュサーバへの累計クエリ数である。
【００３９】
潜在ユーザ数は、該ドメインにおけるユーザからDNSキャッシュサーバへのクエリの送信元IPアドレスのユニーク個数である。ただし、潜在ユーザ数の測定期間はΔTとは異なり、TTLに対して十分に長い期間において観測されたユーザ数であるとする。詳細は「潜在ユーザ数の観測」の節で述べる。
【００４０】
最大TTLは、DNS権威サーバのゾーンファイルに登録された該ドメインのTTL値であるが、トラヒック収集装置２０では直接観測することができない。そこで本発明の実施の形態では該ドメインにおいて十分に長い期間において観測したDNS応答パケットにおいて、観測されたTTL値における最大値を最大TTLと推定する。なお、以下の説明においては、最大TTLの測定期間は潜在ユーザ数の測定期間に準ずるものとするが、最大TTLの測定期間は潜在ユーザ数の測定期間と異なってもよい。
【００４１】
DNSクエリを集計する時間間隔ΔTは適用環境に合わせて設定する時間間隔であり、パラメータである。例えば1日の観測時間に対して5分毎にDNSクエリを集計する場合、T=1日、ΔT=5分となる。
【００４２】
以上により、蓄積される通信ログのレコード数は、観測時間Tにおいて、N個のドメインを観測した場合は、最大で
【００４３】
【数１】
2018032965.tif 000004
個となる。
【００４４】
なお、潜在ユーザ数の測定期間及び最大TTLの測定期間は、DNSクエリを集計する時間間隔ΔTを跨がる。上記のように、表１の通信ログのレコードはΔTの間隔で出力されるが、潜在ユーザ数および最大TTLはΔTとは異なる観測期間Tduserで計測した値が複数のレコードに渡って横断的に埋め込まれる。
【００４５】
＜DNSクエリ集計部における処理手順の説明＞
図４に、以上を踏まえたDNSクエリ集計部２１における処理手順を示す。
【００４６】
DNSクエリ集計部２１は、パケットがトラヒック収集装置２０を通過する毎に当該パケットがDNSクエリであるか確認する（ステップＳ２０１）。DNSクエリである場合、DNSクエリを収集してメモリ又は記憶装置などに記録する（ステップＳ２０３）。DNSクエリでない場合には、記録は行わない。
【００４７】
DNSクエリ集計部２１は、前回の集計処理からΔTが経過したか確認する（ステップＳ２０５）。ΔTが経過した場合、ΔTの時間間隔におけるDNSクエリを集計し（ステップＳ２０７）、DNSクエリ数を通信ログDBに記録する（ステップＳ２０９）。
【００４８】
また、DNSクエリ集計部２１は、前回の集計処理からTduserが経過したか確認する（ステップＳ２１１）。Tduserが経過した場合、Tduserの期間におけるユーザ数を集計すると共に、最大TTLを集計する（ステップＳ２１３）。上記のように、ユーザ数を集計する期間とユーザ数を集計する期間は異なってもよい。DNSクエリ集計部２１は、集計されたユーザ数（潜在ユーザ数）及び最大TTLを通信ログDBに記録する（ステップＳ２１５）。
【００４９】
＜アクセス数の推定＞
本発明の実施の形態における分析方式はアクセス数推定装置１０にソフトウェアとして実装し、トラヒック収集装置２０に記録された通信ログを参照して分析し、結果を出力する。
【００５０】
図３に示されるように、アクセス数推定装置１０は、アクセス数推定部１１およびログ出力部１３で構成される。アクセス数推定部１１はトラヒック収集装置２０が通信ログDBに出力した結果を参照し、以下に述べるモデルに基づきドメイン毎のアクセス数を推定する。ログ出力部１３はアクセス数推定部１１の出力を整形し、最終的な分析結果となるログ（ドメイン毎のアクセス数）を出力する。
【００５１】
次に本発明の実施の形態において根幹となる、クエリ数の統計値および最大TTL値、潜在ユーザ数を用いて、アクセス数を推定する手法について述べる。
【００５２】
＜数理モデルの導出＞
前提として、「アクセス」とはDNS名前解決を必要とする通信要求であり、例えばWebブラウザや通信アプリケーションでドメイン名を指定して通信する度に発生する。一方で、このアクセスによって発生するDNSクエリは、該ユーザの端末上のスタブリゾルバに該ドメインのキャッシュが存在しない場合に送信され、存在する場合は送信されない。
【００５３】
以下では式の導出の過程で、観測期間tの変数を使用しているが、これはモデルが推定対象とする期間であり、上述の観測期間Tとは意味が異なる。数理モデルを通信ログに適用する際は、観測期間tは通信ログを集計する時間間隔であるΔTに対応する。
【００５４】
最初にユーザのアクセスがポアソンに従うと仮定する。あるユーザのあるドメインdに関して時刻0からtまでにアクセスがk回発生する確率は、ポアソンの仮定に基づき、以下の式で表される。
【００５５】
【数２】
2018032965.tif 000005
ここでrdはユーザの単位時間毎のアクセスレートである。ドメインdに関してキャッシュ切れが発生しない、すなわちTTLが無限であると仮定すると、あるユーザuにおける、時刻0からtにおける累計クエリ数の期待値は以下の式で表される。
【００５６】
【数３】
2018032965.tif 000006
ここではDNSクエリの発生確率は、0からtまでの間にアクセスが1回以上発生する確率と等しいという関係を用いている。次に、ユーザ数Ndとした場合、ユーザ全員が平均してレートrdでアクセスしていると仮定すると、累計クエリ数は、次のように表される。
【００５７】
【数４】
2018032965.tif 000007
上式はTTLが無限であると仮定しているが、観測期間をt、最大TTLをτdとした場合、TTLが有限である場合の時刻0からtまでの累計クエリ数は次のように表される。
【００５８】
【数５】
2018032965.tif 000008
上式をrdについて解く。
【００５９】
【数６】
2018032965.tif 000009
最終的なアクセス数は、アクセスレートrdにユーザ数Ndと観測時間tを掛け合わせて求まるため、アクセス数は以下の式で計算できる。
【００６０】
【数７】
2018032965.tif 000010
上式が本発明の実施の形態におけるモデル式である。各変数のうち、観測時間tは自明である。最大TTLτd、累計クエリ数Qd'(t)は表１の通信ログの統計値から観測可能である。
【００６１】
一方で、ユーザ数NdはTTLが無限であると仮定した場合のユーザ数である。したがって、観測時間tとは別の時間幅で観測する必要がある。Ndの観測については以下に述べる。
【００６２】
＜潜在ユーザ数の観測＞
モデル式におけるNdは、TTLが無限であると仮定した場合のユーザ数であるため、現実的には正確に観測することは困難である。そのため、本手法においては、NdはTTLに対して十分に長い期間に観測されたユニークなユーザ数、すなわち、その期間に観測された送信元アドレスのユニーク個数と定義し、これを以下、潜在ユーザ数と呼ぶ。一般にアクセス頻度の高いドメイン名ではTTLを短くする傾向があることを踏まえ、潜在ユーザ数の観測期間は、例として、6時間、12時間、1日など、大部分のドメインのTTLよりも大きく、なおかつ、測定環境によって許容できる観測期間を任意に選択するものとする。ここで、潜在ユーザ数の観測期間をTduserとする。Tduserはトラヒック収集装置２０にて、通信ログとは平行して測定を行い、表１の通信ログに潜在ユーザ数を記録するものとする。
【００６３】
＜ログの出力＞
ログ出力部１３が出力する分析結果は、前述におけるドメイン毎のアクセス数Fdである。ログ出力部１３ではアクセス数推定部の結果を以下の形式に整形し、出力する。これが「分析装置」の出力となる。各レコードは時間間隔ΔTの間隔で出力される。
【００６４】
【表２】
2018032965.tif 000011
＜推定条件と精度の確認方法＞
本発明の実施の形態によるアクセス数の推定精度は、観測データの大小やユーザ数、ドメイン名の最大TTL、観測期間によって左右される。推定精度判断部２３は、以下の式を利用して精度の定性的な確認を行うことができる。
【００６５】
【数８】
2018032965.tif 000012
各変数の表記は、前述の数理モデルの説明に準ずる。上式は、モデル式のlogの項が0から1の範囲を取り得ることに着目して式変形することで得られる。
【００６６】
観測値が上記の関係式を満たさない場合、本方式ではアクセス数の推定が困難となる。これは観測誤差が大きい場合や、ユーザのアクセスがポアソンに従わない場合等に発生し得る。
【００６７】
一方で精度の観点としては、上式から以下のような観点で推定精度判断部２３において観測データの採り方を調整することにより、推定困難なドメインの削減や推定精度の向上を図ることができる。
【００６８】
TTLτdが長いドメインである場合は、(1)観測期間tが十分に長い、(2)観測ユーザ数Ndが十分多い、のいずれか、もしくは両方を満たす必要がある。
【００６９】
観測期間tが短い場合、(1)TTLτdが短い、(2)ユーザ数Ndが十分に多い、のいずれか、もしくは両方を満たす必要がある。
【００７０】
これらの変数のうち、推定精度判断部２３は、観測期間t=ΔTを変更することができ、観測期間の変更によってアクセス数の推定精度を調整することができる。
【００７１】
＜アクセス数推定部およびログ出力部における処理手順の説明＞
図５に、以上を踏まえたアクセス数推定部１１およびログ出力部１３における処理手順を示す。
【００７２】
アクセス数推定部１１は、DNSクエリ集計部２１において記録された通信ログDBを参照し、１つのドメインの集計情報を取得する（ステップＳ１０１）。
【００７３】
アクセス数推定部１１は、上記の数理モデルに従い、ドメイン毎の累計クエリ数、最大TTL及び潜在ユーザ数を用いて表したモデル式に基づき、ドメイン毎のアクセス数を推定する（ステップＳ１０３）。
【００７４】
ログ出力部１３は、ドメイン毎のアクセス数の推定結果を出力する（ステップＳ１０５）。
【００７５】
以上のDNSクエリ集計部２１、推定精度判断部２３、アクセス数推定部１１およびログ出力部１３における機能は、任意のプログラム言語ないしはスクリプト言語もしくはそれらの組み合わせで実装できる。
【００７６】
＜具体例＞
次に、本発明の実施の形態におけるアクセス数の推定の具体例について述べる。
【００７７】
トラヒック収集装置２０で収集した通信ログとして、以下のドメインの情報が得られたと仮定する。
【００７８】
【表３】
2018032965.tif 000013
計測間隔ΔTは5分（300秒）とする。潜在ユーザ観測期間Tduserは24時間としている。最大TTLの測定期間は測定の便宜上、Tduserに準ずる。この時、モデル式における各パラメータはそれぞれ、t=300、τd=15、Qd'(t)=62150、Nd=4210となる。数理モデルにおける式に各変数を代入することにより、rd=0.089およびFd=1.1×105と求まる（有効数字2桁）。すなわち、ドメインxxx.comに対する5分間の推定アクセス数は約110000となる。
【００７９】
同様に、観測期間Tが1時間（3600秒）である場合、xxx.comに関して表３と同様の各5分間の通信ログが計12サンプル観測されるため、各サンプルにおいて先と同様の手順でアクセス数を推定し、それらを合算することで合計の推定アクセス数が求まる。
【００８０】
＜本発明の実施の形態の効果＞
図６は、従来技術におけるアクセス数の推定の概要を示す図である。従来技術では、DNSクエリ数時系列の中から１つのTTL周期分の観測データを抽出し、DNSクエリ数時系列の減衰カーブをモデルにフィッティングさせる必要がある。回帰分析によりモデルのパラメータを推定するには十分な個数の観測データが必要となる。測定間隔Δtは、最大TTLから観測データ個数を割った値を設定するが、十分な個数の観測データを得るには、測定間隔Δtを短くする必要がある。一方、ネットワークの設備や環境、コスト上の理由で、十分に短い測定間隔Δtを設定することができない場合がある。そのような場合、最大TTLが短いドメインのアクセス数を推定することができなくなる。例えば、モデル推定に必要な観測データ個数を8個とし、Δtが5分と仮定すると、推定可能なドメインは最大TTLが40分（2400秒）以上に限定される。従って、推定可能なドメインは最大TTLの大小により制限される。
【００８１】
図７は、本発明の実施の形態におけるアクセス数の推定の概要を示す図である。図７のグラフは、DNSクエリ数時系列を示しているが、本発明の実施の形態では、従来技術のような短い測定間隔ΔtでDNSクエリ数時系列を観測する必要はなく、DNSクエリを集計する時間間隔ΔTにおいて累積クエリ数を観測すればよい。累積クエリ数に加えて、ΔTよりも大きい期間で別途ユーザ数、最大TTLをそれぞれ観測し、それらをモデル式に入力して推定アクセス数を推定することができる。測定間隔ΔTは最大TTLに依存しないため、本発明の実施の形態では、推定可能などメインに制限が生じない。また、測定間隔ΔTは任意の時間を設定することができ、さらに、推定精度を高めるためにΔTを変更することも可能である。
【００８２】
また、従来技術では、十分短い測定間隔Δtで時間あたりのDNSクエリ数時系列を観測した場合、DNSのキャッシュ切れの時刻を起点とする指数減衰曲線に従うことに着目し、モデルにフィッティングさせている。ロードバランス構成を持つDNSキャッシュサーバの場合、キャッシュ切れの時刻がユーザ間で同期しないため、フィッティング対象となる指数減衰曲線を再現するために補正する必要がある。そのためにはユーザ毎にDNSクエリの問い合わせ履歴を保持する必要があり、メモリ消費量が増大する。
【００８３】
一方、本発明の実施の形態ではDNSクエリ数時系列ではなく、累積クエリ数に基づくモデル化を行い、アクセス数を推定する。従って、モデルへのフィッティングは不要であり、指数減衰曲線の再現のための補正も不要である。これにより補正に伴うメモリ消費量を軽減することができる。
【００８４】
以上にて詳細に説明したように、本発明の実施の形態によれば、ネットワーク・トラヒックもしくはDNSキャッシュサーバの一定間隔で集約されたログを用いて、従来技術における２つの課題を解決し、ドメイン名毎のアクセス数の推定が実現されるようになる。
【００８５】
＜ハードウェア構成例＞
図８は、本発明の実施の形態におけるアクセス数推定装置１０のハードウェア構成例を示す図である。図８のアクセス数推定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、CPU１０４、及びインタフェース装置１０５等を有する。
【００８６】
アクセス数推定装置１０での処理を実現するプログラムは、CD-ROM等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００８７】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。CPU１０４は、メモリ装置１０３に格納されたプログラムに従ってアクセス数推定装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００８８】
なお、アクセス数推定装置１０とトラヒック収集装置２０が別の装置に切り離される場合、トラヒック収集装置２０も図８に示すように構成されることができる。
【００８９】
＜補足＞
説明の便宜上、本発明の実施の形態に係るアクセス数推定装置およびトラヒック収集装置は機能的なブロック図を用いて説明しているが、本発明の実施の形態に係るアクセス数推定装置およびトラヒック収集装置は、ハードウェア、ソフトウェアまたはそれらの組み合わせで実現されてもよい。また、各機能部が必要に応じて組み合わせて使用されてもよい。また、本発明の実施の形態に係る方法は、実施の形態に示す順序と異なる順序で実施されてもよい。
【００９０】
以上、DNSトラヒックに基づくサービス毎のアクセス数推定の負荷を軽減するため手法について説明したが、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々の変更・応用が可能である。
【符号の説明】
【００９１】
１０    アクセス数推定装置
１１    アクセス数推定部
１３    ログ出力部
２０    トラヒック収集装置
２１    DNSクエリ集計部
２３    推定精度判断部
３０    内部ホスト
３１    アプリケーション
３２    スタブリゾルバ
４０    DNSキャッシュサーバ
５０    コンテンツサーバ
１００  ドライブ装置
１０１  記録媒体
１０２  補助記憶装置
１０３  メモリ装置
１０４  CPU
１０５  インタフェース装置
【図１】
2018032965.tif 000015
【図２】
2018032965.tif 000016
【図３】
2018032965.tif 000017
【図４】
2018032965.tif 000018
【図５】
2018032965.tif 000019
【図６】
2018032965.tif 000020
【図７】
2018032965.tif 000021
【図８】
2018032965.tif 000022