JP6589223B2 - サービス推定装置、サービス推定方法、及びプログラム - Google Patents

Description

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

近年、ＯＳやアプリケーションのアップデート等によるトラヒック変動の増加により、サービス毎のトラヒック分析に基づくネットワーク設計や通信制御の必要性が高まってきている。一方で、ＳＳＬ（Secure Socket Layer）やＴＬＳ（Transport Layer Security）の普及によって多くのＷｅｂサービスが暗号化され、ネットワークの経路上におけるサービスの識別が困難となってきている。

一方、ＤＰＩ（Deep Packet Inspection）が利用可能な場合、ＴＬＳの拡張仕様であるＳＮＩ（Server Name Indication）情報を解析することで、暗号化されたトラヒックのサービスを識別する方法が存在する。ＳＳＬ−ＳＮＩは、ＳＳＬの拡張仕様であり、クライアントからサーバに対して接続先ドメイン名（ＦＱＤＮ（Fully Qualified Domain Name））を伝える仕組みである。同一ＩＰアドレスで複数ドメインを運用しているサーバが、ドメインに応じた証明書を使い分けるためにＳＮＩが利用される。

ＳＮＩに対応したクライアントの場合、サーバがＳＮＩに対応しているか否かに関わらずＳＮＩにドメイン名が付加される。既存技術では、このＳＮＩのドメイン名に基づいてサービスを識別している。

Wazen M. Shbair, Thibault Cholez, Antoine Goichot and Isabelle Chrisment, ''Efficiently bypassing SNI-based HTTPS filtering,'' IFIP/IEEE International Symposium on Integrated Network Management 2015.

しかしながら、ＳＮＩに非対応のクライアントの場合、ＳＮＩのドメイン名を利用することができず、サービスを識別することができない。

暗号化されたトラヒックにおいて、同一ＩＰアドレスで複数ドメインを運用しているサーバが存在する一方、ＳＮＩ対応／非対応のクライアントが、混在しているのが一般的である。従来技術では、ＳＮＩ非対応クライアントからのアクセスはサービスの識別ができず、分析データとして使用できないため、精度のよいサービス毎のトラヒック分析が行えなかった。

本発明は、上記の点に鑑みてなされたものであって、ＳＮＩに非対応のクライアントがアクセスしたサービスを推定することを目的とする。

そこで上記課題を解決するため、サービス推定装置は、それぞれが複数のサービスを提供する複数のサーバのいずれかに対する、前記サービスの識別情報を含むアクセスについて、前記各サーバの前記識別情報ごとのアクセス数を記録する学習部と、いずれかの前記サーバに対する、前記識別情報を含まないアクセスが観測されると、当該サーバに関して記録されている前記識別情報ごとのアクセス数に基づいて、当該アクセスの対象のサービスを推定する推定部と、を有する。

ＳＮＩに非対応のクライアントがアクセスしたサービスを推定することができる。

リアルタイム法のイメージとバッチ法のイメージとを示す図である。 第１の実施の形態におけるサービス推定装置のハードウェア構成例を示す図である。 第１の実施の形態におけるサービス推定装置の機能構成例を示す図である。 第１の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。 第２の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。 第３の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。 第４の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。 第５の実施の形態におけるサービス推定装置の機能構成例を示す図である。 第５の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。 第６の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。 第７の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。本実施の形態では、ＳＮＩ（Server Name Indication）対応クライアントからのサーバへのアクセスに基づきサービスへのアクセス状況を学習し、学習結果に基づきＳＮＩ非対応クライアントからのアクセスの対象のサービスを推定する。

具体的には、サーバに対する通信を逐次観測し、観測時点までに蓄積された統計情報に基づいてサービスを逐次推定するリアルタイム法と、一定期間において観測された通信を対象に、全通信の統計情報に基づいてサービスを一括推定するバッチ法の２つの手法について開示する。図１に、リアルタイム法のイメージとバッチ法のイメージとを示す。

リアルタイム法は通信の開始時にサービスを推定するため、即応性が必要なシステムに適している。バッチ法は通信の開始前のみならず終了後の統計量を利用可能であるため、より精度のよい推定が可能である。

第１〜第４の実施の形態はリアルタイム法に関し、第５〜第７の実施の形態はバッチ法に関する。

なお、本実施の形態において、サーバとは、ＩＰアドレスを識別情報とする単位（すなわち、ＩＰアドレスによって区別される単位）である。サービスとは、ＦＱＤＮ（Fully Qualified Domain Name）又はＦＱＤＮからホスト名を除いたドメイン名を識別情報とする単位（すなわち、ＦＱＤＮ又はＦＱＤＮからホスト名を除いたドメイン名によって区別される単位）である。

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

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

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

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

ＳＮＩ判定部１１は、観測されたＨＴＴＰＳセッション（クライアントからサーバへのアクセス）について、ＳＮＩが含まれているか否かを判定する。サービス学習部１２は、ＳＮＩ情報が含まれていないアクセスについて、サーバ別及びサービス別のアクセス回数を統計情報記憶部１４に記録する。サービス推定部１３は、ＳＮＩ情報が含まれていないアクセスについて、サービスを推定する。

なお、第１の実施の形態において、サービス推定装置１０は、サーバとクライアントとのネットワークのパケットを観測可能な位置であれば、どのような位置に配置されてもよい。

以下、サービス推定装置１０が実行する処理手順について説明する。図４は、第１の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。

ＳＮＩ判定部１１は、ネットワークにおいて、クライアントｃ_ｉからサーバｓ_ｊへのアクセスを観測（検出）すると（Ｓ１１０でＹｅｓ）、アクセス内容にＳＮＩ情報が含まれているか否かを判定する（Ｓ１２０）。当該アクセスは、例えば、ＳＳＬ（Secure Socket Layer）のシーケンスにおける「ＣｌｉｅｎｔＨｅｌｌｏ」であってもよい。

アクセス内容にＳＮＩ情報が含まれている場合（Ｓ１２０でＹｅｓ）、統計情報記憶部１４に記憶されている統計情報を更新することで、サービスを学習する。統計情報には、サーバごとのサービスの集合と、各サーバのサービスごとのセッション数（ＳＳＬアクセス数）とが含まれる。ここで、アクセス内容に含まれていたＳＮＩ情報が示すサービスが、ｄ_ｋであり、サーバｓ_ｊのサービスの集合がＤ_ｓｊであり、サーバｓ_ｊのサービスｄ_ｋに対するセッション数がＮ_ｓｊ（ｄ_ｋ）であるとする。すなわち、Ｄ_ｓｊは、サービスの集合が記録されるデータであり、Ｎ_ｓｊ（ｄ_ｋ）は、サーバｓ_ｊのサービスｄ_ｋに対するセッション数が記録されるデータである。なお、本実施の形態において、「セッション」とは、ＳＳＬセッションをいう。

まず、サービス学習部１２は、Ｄ_ｓｊにｄ_ｋを記録済みであるか否かを判定する（Ｓ１３０）。Ｄ_ｓｊにｄ_ｋが記録されていない場合（Ｓ１３０でＹｅｓ）、サービス学習部１２は、Ｄ_ｓｊにｄ_ｋを記録する（Ｓ１４０）。続いて、サービス学習部１２は、Ｎ_ｓｊ（ｄ_ｋ）に１を記録する（Ｓ１５０）。一方、Ｄ_ｓｊにｄ_ｋが記録されている場合（Ｓ１３０でＮｏ）、サービス学習部１２は、Ｎ_ｓｊ（ｄ_ｋ）に１を加算した結果を、Ｎ_ｓｊ（ｄ_ｋ）に記録する（Ｓ１６０）。

一方、アクセス内容にＳＮＩ情報が含まれていない場合（Ｓ１２０でＮｏ）、サービス推定部１３は、以下の確率Ｐ（ｄ'）に従って、サービスｄ'を選択し、選択結果をサービスの推定結果とする（Ｓ１７０）。

ここで、確率Ｐ（ｄ'）に従ってサービスｄ'を選択するとは、サービスｄ'が確率Ｐ（ｄ'）の確率で選択されるようにサービスｄ'を選択するということである。例えば、０〜１の範囲の乱数について、当該範囲を各ｄ'の確率Ｐ（ｄ'）に応じた割合で分割してもよい。サービス推定部１３は、当該乱数を発生させて、発生した値が属する範囲に対応するサービスｄ'を選択してもよい。

上述したように、第１の実施の形態によれば、ＳＮＩ対応クライアントからのアクセスに基づきサービスを学習し、学習結果に基づきＳＮＩ非対応クライアントからのアクセスの対象のサービスを推定することができる。その結果、例えば、ＳＮＩ非対応クライアントのアクセスのデータを用いて、精度の高いサービス毎のトラヒック分析を行うことを可能とすることができる。

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

第１の実施の形態では、学習期間の特段の制限は設けられていない。しかし、例えば、ＣＤＮ（Content Delivery Network）の場合、サーバ側の制御によって配信サービスが時間変化するため、古い学習結果は誤推定の要因となる可能性が有る。第２の実施の形態では、斯かる問題を解決する。

図５は、第２の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。図５中、図４と同一ステップには同一ステップ番号を付し、その説明は省略する。

図５では、ステップＳ１５０、Ｓ１６０、Ｓ１７０の代わりに、ステップＳ１５０ａ、Ｓ１６０ａ、Ｓ１７０ａが実行される。また、ステップＳ１６０ａに続いてステップＳ１６１が実行される。なお、図５において、Ｎ_ｓｊ（ｄ_ｋ）は、サーバｓ_ｊのサービスｄ_ｋへのアクセスが観測（検出）された時刻の集合である。また、ステップＳ１１０におけるアクセスの観測時刻（最後のアクセスの観測時刻）は、時刻ｔであるとする。

ステップＳ１５０ａにおいて、サービス学習部１２は、Ｎ_ｓｊ（ｄ_ｋ）に対して｛ｔ｝を記録する（Ｓ１５０ａ）。すなわち、ステップＳ１１０におけるアクセスの観測時刻がＮ_ｓｊ（ｄ_ｋ）に追加される。

ステップＳ１６０ａにおいて、サービス学習部１２は、以下の演算を行う。

但し、δは、学習履歴の保持期間である。すなわち、ステップＳ１６０ａでは、時刻ｔから遡って保持期間δ内の時刻がＮ_ｓｊ（ｄ_ｋ）から抽出されて、Ｎ_ｓｊ（ｄ_ｋ）に代入される。

続いて、サービス学習部１２は、Ｎ_ｓｊ（ｄ_ｋ）と｛ｔ｝との論理和をＮ_ｓｊ（ｄ_ｋ）に記録する（Ｓ１６１）。

ステップＳ１７０ａにおいて、サービス推定部１３は、以下の確率Ｐ（ｄ'）に従って、サービスｄ'を選択し、選択結果をサービスの推定結果とする。

但し、｜Ｘ｜は、Ｘの要素数を表し、以下においても同様である。すなわち、｜Ｎ_ｓｊ（ｄ）｜は、サーバｓ_ｊのサービスｄに対するアクセス数を示す。

式（３）では、時刻ｔのアクセス先であるサーバｓ_ｊのサービスｄ_ｋごとに、時刻ｔから遡って保持期間δ内の時刻がＮｓ_ｊ（ｄ_ｋ）に代入される。式（４）では、サーバｓ_ｊのサービスｄ'ごとに、当該サービスｄ'の保持期間δ内のアクセス数について、サーバｓ_ｊの全てのサービスの保持期間δ内のアクセス数の総和に対する割合が確率Ｐ（ｄ'）として算出される。

すなわち、時刻ｔから保持期間δ内の学習結果に基づいて、確率Ｐ（ｄ'）が計算される。なお、確率Ｐ（ｄ'）に従って、サービスｄ'を選択することの意味は、第１の実施の形態と同様である。

上述したように、第２の実施の形態によれば、古い学習結果に基づく誤推定の可能性を低下させることができる。

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

第１の実施の形態では特定クライアントから膨大な量のアクセスがあった場合に確率分布が偏ってしまう。そこで、第３の実施の形態では、確率分布の偏りを回避する例について説明する。

図６は、第３の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。図６中、図４と同一ステップには同一ステップ番号を付し、その説明は省略する。

図６では、ステップＳ１５０に続いて、ステップＳ１５１が実行される。また、ステップＳ１６０の前に、ステップＳ１５５及びＳ１５６が実行される。

ステップＳ１５１において、サービス学習部１２は、Ｃ_{ｓｊ，ｄｋ}にｃ_ｉを記録する。ここで、Ｃ_{ｓｊ，ｄｋ}は、サーバｓ_ｊのサービスｄ_ｋにアクセスしたクライアントの集合である。ｃ_ｉは、ステップＳ１０１において観測されたアクセスのアクセス元のクライアントの識別情報である。

ステップＳ１５５において、サービス学習部１２は、Ｃ_{ｓｊ，ｄｋ}にｃ_ｉが含まれているか否かを判定する。すなわち、クライアントｃ_ｉが、サーバｓ_ｊのサービスｄ_ｋに既にアクセスしていたか否かが判定される。クライアントｃ_ｉが、サーバｓ_ｊのサービスｄ_ｋにアクセスしていなかった場合（Ｓ１５５でＹｅｓ）、サービス学習部１２は、Ｃ_{ｓｊ，ｄｋ}にｃ_ｉを追加する（Ｓ１５６）。続いて、サービス学習部１２は、Ｎ_ｓｊ（ｄ_ｋ）に１を加算した結果を、Ｎ_ｓｊ（ｄ_ｋ）に記録する（Ｓ１６０）。

一方、クライアントｃ_ｉが、サーバｓ_ｊのサービスｄ_ｋにアクセスしていた場合（Ｓ１５５でＮｏ）、ステップＳ１５６及びＳ１６０は実行されない。すなわち、第３の実施の形態において、同一のクライアントによる同一のサーバ及び同一のサービスに対するアクセスは、重複してカウントされない。したがって、Ｎ_ｓｊ（ｄ_ｋ）は、セッション数ではなく、クライアント数を意味する。その結果、アクセスの確率分布の偏りを回避することができる。

なお、ステップＳ１７０の内容は、第１の実施の形態と同様でよい。

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

第４の実施の形態では、第３の実施の形態に対して第２の実施の形態が組み合わされる。

図７は、第４の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。図７中、図６と同一ステップには同一ステップ番号を付し、その説明は省略する。

図７では、ステップＳ１２０でＹｅｓの場合に、サービス学習部１２は、Ｔ（ｃ_ｉ）に対して時刻ｔを記録する（Ｓ１２１）。Ｔ（ｃ_ｉ）は、クライアントｃ_ｉによる最後のアクセスが観測された時刻である。すなわち、第４の実施の形態では、アクセスが観測されたクライアントごとに、当該クライアントが最後にいずれかのサーバにアクセスした時刻が統計情報記憶部１４のＴ（ｃ_ｉ）に記録される。

なお、図７では、ステップＳ１５０及びＳ１６０は実行されなくてよい。

また、図７では、ステップＳ１７０がステップＳ１７０ｂに置き換わる。ステップＳ１７０ｂにおいて、サービス推定部１３は、以下の確率Ｐ（ｄ'）に従って、サービスｄ'を選択し、選択結果をサービスの推定結果とする。

すなわち、式（５）では、サーバｓ_ｊのサービスｄ_ｋにアクセスしたクライアントの集合であるＣ_{ｓｊ，ｄｋ}のうち、Ｔ（ｃ_ｉ）が時刻ｔから遡って保持期間δ内のｃ_ｉが、Ｎ_ｓｊ（ｄ_ｋ）に代入される。すなわち、最後のアクセス時刻が保持期間δ内のｃ_ｉがＮ_ｓｊ（ｄ_ｋ）に代入される。Ｎ_ｓｊ（ｄ_ｋ）は、サーバｓ_ｊの全てのサービスｄｋについて生成される。

また、式（６）では、サーバｓ_ｊのサービスｄ'ごとに、当該サービスｄ'の保持期間δ内のクライアント数について、サーバｓ_ｊの全てのサービスの保持期間δ内のクライアント数の総和に対する割合が確率Ｐ（ｄ'）として算出される。なお、確率Ｐ（ｄ'）に従って、サービスｄ'を選択することの意味は、第１の実施の形態と同様である。

なお、第１〜第４の実施の形態では、確率的にサービスｄ'が選択される。但し、以下の式に基づいて、決定的にサービスｄ'が選択されてもよい。

すなわち、式（７）は、第１及び第３の実施の形態のように、Ｎ_ｓｊ（ｄ'）がアクセス数又はクライアント数である場合に、最大のＮ_ｓｊ（ｄ'）のサービスｄ'が選択されることを示す。また、式（８）は、第２及び第４の実施の形態のように、Ｎ_ｓｊ（ｄ'）がアクセス時刻の集合である場合に、要素数が最大のＮ_ｓｊ（ｄ'）のサービスｄ'が選択されることを示す。

次に、第５の実施の形態について説明する。第５の実施の形態では第１の実施の形態と異なる点について説明する。第５の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。なお、第５の実施の形態以降は、バッチ法に関する実施形態である。

図８は、第５の実施の形態におけるサービス推定装置の機能構成例を示す図である。図８中、図３と同一又は対応する部分には同一符号を付している。

図８において、サービス推定装置１０は、サービス学習部１２の代わりに統計化処理部１５を有する。統計化処理部１５は、ＨＴＴＰＳトラヒック情報に基づいて、所定期間（以下、「観測期間Ｔ」という。）におけるサービスへのアクセスのうち、ＳＮＩ対応クライアントからのアクセスに関する統計情報を計測又は算出する。計測又は算出された統計情報は、統計情報記憶部１４に記憶される。具体的には、統計化処理部１５は、観測期間Ｔにおいて、ＳＮＩ対応クライアントからのアクセスの通信量をサービス別に計測する。本実施の形態において、セッション数及びトラヒック量が通信量の一例である。

サービス推定部１３は、ＨＴＴＰＳトラヒック情報と、統計情報記憶部１４に記憶された情報とに基づいて、観測期間ＴにおけるＳＮＩ非対応クライアントからのアクセスをも含む通信量を、サービス別に推定する。

なお、ＨＴＴＰＳトラヒック情報には、観測期間Ｔにおける、いずれかのクライアントによる、いずれかのサーバのいずれかのサービスへのアクセス（セッション）ごとに、クライアントの識別情報、ＳＮＩ情報、サーバの識別情報、及びトラヒック量を示す情報（以下、「アクセスログ」という。）が含まれている。但し、ＳＮＩ情報は、ＳＮＩ情報が含まれているアクセスについてのみアクセスログに含まれている。

図９は、第５の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。図９の処理手順は、観測期間Ｔの後に、観測期間Ｔにおいて観測されたＨＴＴＰＳトラヒック情報について実行される。

ステップＳ２０１において、統計化処理部１５は、ＨＴＴＰＳトラヒック情報においてＳＮＩが含まれているアクセスログに基づいて、観測期間Ｔにおいていずれかのサーバｓ_ｊにアクセスした全てのＳＮＩ対応クライアントｃ_ｓｊ＝｛ｃ_１，・・・，ｃ_Ｉ｝を特定する。

続いて、統計化処理部１５は、ＨＴＴＰＳトラヒック情報に基づいて、観測期間Ｔにおいてアクセスされたサーバｓ_ｊごとに、当該サーバ_ｓｊが提供する全サービスＤ_ｓｊ＝｛ｄ_１，・・・，ｄ_Ｋ｝を特定する（Ｓ２０２）。

続いて、統計化処理部１５は、ＳＮＩ対応クライアントｃ_ｉごとに、サービスｄ_ｋごとのセッション数ｎ（ｃ_ｉ，ｄ_ｋ）を、ＨＴＴＰＳトラヒック情報に基づいて集計する（Ｓ２０３）。続いて、統計化処理部１５は、ＳＮＩ対応クライアントｃ_ｉごとに、サービスｄ_ｋごとのトラヒック量ｖ（ｃ_ｉ，ｄ_ｋ）を、ＨＴＴＰＳトラヒック情報に基づいて集計する（Ｓ２０４）。

続いて、統計化処理部１５は、各サーバｓ_ｊのサービスｄ_ｋごとの総セッション数Ｎ_ｓｊ（ｄ_ｋ）を、以下の演算により算出する（Ｓ２０５）。

すなわち、ステップＳ２０３において集計されたｎ（ｃ_ｉ，ｄ_ｋ）について、サーバｓ_ｊのサービスｄ_ｋごとの総和が算出される。

続いて、統計化処理部１５は、各サーバｓ_ｊのサービスｄ_ｋごとの総トラヒック量Ｖ_ｓｊ（ｄ_ｋ）を、以下の演算により算出する（Ｓ２０６）。

すなわち、ステップＳ２０４において集計されたｖ（ｃ_ｉ，ｄ_ｋ）について、サーバｓ_ｊのサービスｄ_ｋごとの総和が算出される。

なお、ステップＳ２０５及びＳ２０６における算出結果は、統計情報記憶部１４に記憶される。

続いて、サービス推定部１３は、ＨＴＴＰＳトラヒック情報のうち、ＳＮＩ情報が含まれていないアクセスログに基づいて、全ＳＮＩ非対応クライアントによるサーバｓ_ｊごとのセッション数Ｎ'_ｓｊを集計する（Ｓ２０７）。

続いて、サービス推定部１３は、ＨＴＴＰＳトラヒック情報のうち、ＳＮＩ情報が含まれていないアクセスログに基づいて、全ＳＮＩ非対応クライアントによるサーバｓ_ｊごとのトラヒック量Ｖ'_ｓｊを集計する（Ｓ２０８）。

続いて、サービス推定部１３は、以下の演算を行って、ＳＮＩ対応クライアント及びＳＮＩ非対応クライアントを問わない全てのクライアントと、各サーバｓ_ｊの各サービスｄ_ｋとの総セッション数Ｎ_ｓｊ（ｄ_ｋ）を算出する（Ｓ２０９）。

すなわち、ステップＳ２０６の算出結果に対して、Ｎ_ｓｊ（ｄ_ｋ）の確率にＮ'_ｓｊを乗じた値を加算した結果が、Ｎ_ｓｊ（ｄ_ｋ）の推定値として算出される。換言すれば、ステップＳ２０５において算出された各Ｎ_ｓｊ（ｄ_ｋ）の比に基づいて、各Ｎ_ｓｊ（ｄ_ｋ）に対してＮ'_ｓｊが配分される。

続いて、サービス推定部１３は、以下の演算を行って、ＳＮＩ対応クライアント及びＳＮＩ非対応クライアントを問わない全てのクライアントと、各サーバｓ_ｊの各サービスｄ_ｋとのトラヒック量Ｖ_ｓｊ（ｄ_ｋ）を算出する（Ｓ２１０）。

すなわち、ステップＳ２０７の算出結果に対して、Ｖ_ｓｊ（ｄ_ｋ）の確率にＮ'_ｓｊを乗じた値を加算した結果が、Ｖ_ｓｊ（ｄ_ｋ）の推定値として算出される。換言すれば、ステップＳ２０６において算出された各Ｖ_ｓｊ（ｄ_ｋ）の比に基づいて、各Ｖ_ｓｊ（ｄ_ｋ）に対してＶ'_ｓｊが配分される。

上述したように、第５の実施の形態によれば、過去の一定期間における観測結果に基づいて、ＳＮＩ非対応のクライアントによるアクセスも含む、各サービスへのアクセスの統計情報を得ることができる。

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

一般的に、サービスの内容が異なる場合、セッションあたりのトラヒック量（以下、「セッション長」という。）の分布も異なる。例えば、動画サービスの場合はセッション長が相対的に長くなり、Ｗｅｂページなどのテキストではセッション長は相対的に短くなる。第６の実施の形態では、このような事情を考慮することで推定精度を向上させる。

図１０は、第６の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ３０１において、統計化処理部１５は、ＨＴＴＰＳトラヒック情報に基づいて、観測期間Ｔにおいてアクセスされたサーバｓ_ｊごとに、当該サーバｓ_ｊが提供する全サービスＤ_ｓｊ＝｛ｄ_１，・・・，ｄ_Ｋ｝を特定する。

続いて、統計化処理部１５は、サーバｓ_ｊごとに以下の演算を行うことにより、各サーバｓ_ｊの各サービスｄ_ｋのセッション長の確率分布であるセッション長分布Ｌ_ｓｊ（ｄ_ｋ）を算出する。

但し、ｎ_ｄｋ（ｌ）は、サービスｄ_ｋについてセッション長ｌのセッションが観測された回数である。ｎ_ｄｋ（ｌ）は、ＨＴＴＰＳトラヒック情報から集計可能である。また、ｌ_ｃは、０〜∞の任意のセッション長である。ここで、便宜上セッション長の最大値を∞と表現しているが、実際には過去に観測された最大のセッション長を記録しておき、その値とすれば良い。すなわち、ステップＳ３０２では、サービスｄ_ｋについて、ｎ_ｄｋ（ｌ）の総和が求められ、０〜∞の各セッション長ｌ_ｃの観測回数ｎ_ｄｋ（ｌ_ｃ）について、当該総和に対する割合の分布が算出される。

続いて、サービス推定部１３は、ＨＴＴＰＳトラヒック情報に含まれているアクセスログのうち、ＳＮＩ情報が含まれていないアクセスログに基づいて、観測期間Ｔにおける、ＳＮＩ非対応クライアントからのサーバｓ_ｊへの各アクセス（セッション）を特定し、それぞれのアクセスのセッション長ｌ_ｃに基づいて、以下の確率Ｐ（ｄ'）に従って、各アクセスのサービスｄ'を選択する（Ｓ３０３）。選択結果が、サービスの推定結果とされる。

なお、確率Ｐ（ｄ'）に従って、サービスｄ'を選択することの意味は、第１の実施の形態と同様である。

なお、第６の実施の形態において、セッション長は、予め定められた区間ごとの代表値によって表現されてもよい。

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

例えば、負荷分散等のために、複数のサーバによって同一のサービスが提供される場合がある。そして、サービスの内容が同一である場合、サーバが異なってもセッションあたりのトラヒック量（セッション長）の分布は同一となる又は類似したものとなる可能性が高い。第７の実施の形態では、このような事情を考慮して推定精度の向上を図る。

図１１は、第７の実施の形態におけるサービス推定装置が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ４０１において、統計化処理部１５は、ＨＴＴＰＳトラヒック情報に基づいて、観測期間Ｔにおいてアクセスされた全サービスＤ＝｛ｄ_１，・・・，ｄ_Ｋ｝を特定する。ここでは、サーバの別は考慮されない。

続いて、統計化処理部１５は、以下の演算を行うことにより、各サービスｄ_ｋのセッション長分布Ｌ（ｄ_ｋ）を算出する（Ｓ４０２）。

但し、ｎ_ｄｋ（ｌ）は、サービスｄ_ｋについてセッション長ｌのセッションが観測された回数である。また、ｌ_ｃは、０〜∞の任意のセッション長である。すなわち、ステップＳ４０２では、サービスｄ_ｋについて、ｎ_ｄｋ（ｌ）の総和が求められ、０〜∞の各セッション長ｌ_ｃの観測回数ｎ_ｄｋ（ｌ_ｃ）について、当該総和に対する割合の分布が算出される。

続いて、サービス推定部１３は、ＨＴＴＰＳトラヒック情報に含まれているアクセスログのうち、ＳＮＩ情報が含まれていないアクセスログに基づいて、観測期間Ｔにおける、ＳＮＩ非対応クライアントからのサーバｓ_ｊへの各アクセス（セッション）を特定し、それぞれのアクセスのセッション長ｌ_ｃに基づいて、以下の確率Ｐ（ｄ'）に従って、各アクセスのサービスｄ'を選択する（Ｓ４０３）。選択結果が、サービスの推定結果とされる。

なお、確率Ｐ（ｄ'）に従って、サービスｄ'を選択することの意味は、第１の実施の形態と同様である。

なお、第７の実施の形態において、セッション長は、予め定められた区間ごとの代表値によって表現されてもよい。

なお、第６及び第７の実施の形態では、確率的にサービスｄ'が選択される。但し、ステップＳ３０３又はＳ４０３では、以下の式に基づいて、決定的にサービスｄ'が選択（推定）されてもよい。

すなわち、サービス推定部１３は、ＨＴＴＰＳトラヒック情報に含まれているアクセスログのうち、ＳＮＩ情報が含まれていないアクセスログに基づいて、観測期間Ｔにおける、ＳＮＩ非対応クライアントからのサーバｓ_ｊへの各アクセス（セッション）を特定し、それぞれのアクセスのセッション長ｌ_ｃについて、観測回数が最大であるサービスｄ'をアクセス先として推定する。

なお、上記各実施の形態において、サービス学習部１２は、学習部の一例である。サービス推定部１３は、推定部の一例である。統計化処理部１５は、計測部及び算出部の一例である。

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

１０ サービス推定装置
１１ ＳＮＩ判定部
１２ サービス学習部
１３ サービス推定部
１４ 統計情報記憶部
１５ 統計化処理部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス

Claims (5)

1. それぞれが複数のサービスを提供する複数のサーバのいずれかに対する、前記サービスの識別情報を含むアクセスについて、前記各サーバの前記識別情報ごとのアクセス数を記録する学習部と、
   いずれかの前記サーバに対する、前記識別情報を含まないアクセスが観測されると、当該サーバに関して記録されている前記識別情報ごとのアクセス数に基づいて、当該アクセスの対象のサービスを推定する推定部と、
   を有することを特徴とするサービス推定装置。
2. 前記推定部は、いずれかの前記サーバに対する、前記識別情報を含むアクセスが観測されると、当該サーバに関して所定期間に記録された前記識別情報ごとのアクセス数に基づいて、当該アクセスの対象のドメイン名を推定する、
   ことを特徴とする請求項１記載のサービス推定装置。
3. 前記学習部は、前記サービスの識別情報を含むアクセスについて、前記各サーバの前記識別情報ごとのクライアント数を記録し、
   前記推定部は、前記識別情報を含まないアクセスが観測されると、当該サーバに関して記録されている前記識別情報ごとのクライアント数に基づいて、当該アクセスの対象のサービスを推定する、
   ことを特徴とする請求項１又は２記載のサービス推定装置。
4. それぞれが複数のサービスを提供する複数のサーバのいずれかに対する、前記サービスの識別情報を含むアクセスについて、前記各サーバの前記識別情報ごとのアクセス数を記録する学習手順と、
   いずれかの前記サーバに対する、前記識別情報を含まないアクセスが観測されると、当該サーバに関して記録されている前記識別情報ごとのアクセス数に基づいて、当該アクセスの対象のサービスを推定する推定手順と、
   をコンピュータが実行することを特徴とするサービス推定方法。
5. 請求項１乃至３いずれか一項記載の各部としてコンピュータを機能させることを特徴とするプログラム。

Images