JP4017065B2 - キャッシュ制御方法およびキャッシュシステム - Google Patents
キャッシュ制御方法およびキャッシュシステム Download PDFInfo
- Publication number
- JP4017065B2 JP4017065B2 JP2002084620A JP2002084620A JP4017065B2 JP 4017065 B2 JP4017065 B2 JP 4017065B2 JP 2002084620 A JP2002084620 A JP 2002084620A JP 2002084620 A JP2002084620 A JP 2002084620A JP 4017065 B2 JP4017065 B2 JP 4017065B2
- Authority
- JP
- Japan
- Prior art keywords
- content
- request
- requests
- cache
- certain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシングの制御方法に関し、特に、コスト削減が可能なキャッシュ制御方法に関する。
【０００２】
【従来の技術】
インターネットはそれ以前のメディアにはなかった双方向性を持ち、世界中に蓄積された情報を容易かつ即時的に取得可能なハイパーメディアである。そのため、インターネットを利用したビジネス（ｅ−ｃｏｍｍｅｒｃｅ、デジタルコンテンツ配信など）やアプリケーションシステム（ＣＲＭ、ＥＲＰなど）、コミュニケーション（ＶｏＩＰ、Ｅメールなど）は年々増加しており、インターネットの情報伝達媒体としての地位は高まる一方である。しかし、近年の急激なアクセスネットワークの高速大容量化や、コンテンツの大容量化によって、バックボーンネットワークの処理能力を超えるトラヒック需要が発生し、コンテンツの応答速度が著しく低下する場面も多く見られるようになった。これは、インターネットの双方向性や即時性が損なわれることを意味し、インターネットを利用したビジネスやシステムにとって非常に重要な問題である。
【０００３】
この問題に対処すべく、現在さまざまなコンテンツ配信システムの研究開発が盛んに行われており、その中の１つにコンテンツ配信ネットワーク（Content Distribution/Delivery Network、以下ＣＤＮ）がある。ＣＤＮは、ネットワークエッジに配備したサーバを用いて、インターネットにおける渋滞や遅延を解消するソリューションであり、１９９９年に設立された米Ａｋａｍａｉ社のコンテンツデリバリネットワークがはじまりである。Ａｋａｍａｉは世界中に配備したサーバを結ぶサーバネットワークと、独自のルーティング技術によって顧客（コンテンツ事業者）のコンテンツをエンドユーザに届けるシステムを構築し、応答速度の低下の問題を解決した。また、ＣＤＮはそのコンテンツ配信能力から、Ｐ２Ｐネットワークやグローバルコンピューティング（以下Ｇｒｉｄ）におけるミドルウェアとしての役割を期待されている。
【０００４】
しかし、ミドルウェアとしてＣＤＮを用いるにはコストが高く、より低コストのＣＤＮサービスが実現されることが求められる。さらに、地理的に離れた場所で同質のＣＤＮサービスを受けられなければ、アプリケーションに地域格差が生じる問題も発生する。これに関する最近の活動では、ＣＤＮピアリングに関する活動が多い。ＣＤＮピアリングとは、異なる事業者間でＣＤＮリソースを共有し合うことである。これによって複数の事業者が提携することでコストを抑えつつ大規模なＣＤＮを構成できるが、本格的な実用段階には至っていない。また、仮に実用段階に至ったとしてもＣＤＮを利用する分のコストはかかり、アプリケーション（結局はユーザ）の負担が増えるという問題は依然として残る。
【０００５】
【発明が解決しようとする課題】
上述したようにＣＤＮが注目を集めており、ＣＤＮをインフラとする様々なコンテンツ配信サービスが行われている。そして、アクセスネットワークのブロードバンド化に伴って、ＣＤＮ市場が成長し続けることが予想される。しかし、広域なネットワーク上でＣＤＮを用いるためにはコストが高いという課題があり、ＣＤＮプラットフォームのコスト最適化が求められる。
【０００６】
コストの問題ついてさらに説明する。ＣＤＮには、キャッシュサーバを用いたものと、バックボーンネットワークを活用しエンドユーザまでコンテンツを配信するものがある。ここでは、主として、前者のキャッシュサーバを用いるＣＤＮ技術に着目する。既存のＣＤＮの目的は、単純に「利益の最大化」であった。ここでいう利益とは、エンドユーザからキャッシュサーバへ行われるリクエスト回数である。利益の最大化を達成するため、従来、キャッシュサーバは、リクエストされた任意のコンテンツを無差別にキャッシングする。その結果、キャッシングされるコンテンツ数が非常に多く、このことが、キャッシュサーバに多大な容量を要求し、そして、コストを押し上げる要因になっている。
【０００７】
本発明は上記課題に鑑みてなされたものであり、その目的は、コンテンツ配信におけるコストを削減可能な技術を提供することにある。さらに、本発明の目的は、リクエスト回数の増大が見込める適当なコンテンツをキャッシング可能にすることによってコストを適切に削減可能な技術を提供することにある。
【０００８】
【課題を解決するための手段】
本発明は、コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシングを制御するキャッシュ制御方法に関する。本発明のキャッシュ制御方法は、コンテンツのリクエスト回数の増大を監視し、リクエスト回数が増大することにより所定のキャッシュ条件が満たされるのを待ってから前記コンテンツをキャッシュサーバにキャッシングさせる。好ましくは、前記キャッシュ条件は、リクエスト回数が多いほどその後のリクエストの可能性が大きいリクエスト特性に基づき設定される。
【０００９】
典型的には、キャッシュ条件は、リクエスト回数が適当な値まで増大したときに満たされる。この判断を実現する処理には、典型的にはリクエスト回数そのものが用いられるが、他のパラメータが用いられてもよい。
【００１０】
本発明によれば、例えば、１回だけリクエストされた後にリクエストされないコンテンツを無駄にキャッシングするのを回避できる。実際、このようなコンテンツは相当に多い。このようにして、本発明によれば、適当なコンテンツを限定的にキャッシングすることにより、コストの削減を図れる。
【００１１】
好ましくは、前記キャッシュ条件は、リクエスト回数とその後の目標リクエスト回数達成確率との関係に基づき設定される。目標リクエスト回数達成確率は、例えば、リクエストのログを解析することによって得られる。
【００１２】
好ましくは、前記キャッシュ条件は、前記目標リクエスト回数達成確率から得られるリクエスト増大量の期待値に基づき設定される。好ましくは、期待値が適当な大きさになるリクエスト回数が、キャッシュ条件としてのコンテンツ抽出閾値に設定される。より好ましくは、期待値が最大になるときのリクエスト回数が、キャッシュ条件としてのコンテンツ抽出閾値に設定される。そして、本発明は、コンテンツのリクエスト回数が前記コンテンツ抽出閾値まで増大したときに前記コンテンツを前記キャッシュサーバにキャッシングさせる。本発明によれば、期待値に基づくキャッシングの制御により、リクエスト回数の増大が見込めるコンテンツを適切にキャッシングできる。
【００１３】
なお、本発明の範囲内で、目標リクエスト回数達成確率に基づく他の制御が行われてもよい。例えば、目標リクエスト回数達成確率が適当な値になるときのリクエスト回数がコンテンツ抽出閾値として用いられてもよい。しかし、上述の期待値に基づく制御は、後述にてより詳細に説明されるように、リクエスト回数の増大が見込めるコンテンツを適当なタイミングでキャッシングでき、本発明の利点が一層好適に得られると考えられる。
【００１４】
さらに好ましくは、ユーザグループによって前記リクエスト特性が異なることに基づき、キャッシュ条件がユーザグループに応じて設定される。そして、ユーザグループによるリクエスト回数に基づきキャッシングが制御される。ユーザグループに応じた制御により、さらなるコスト削減効果が期待できる。また、本発明は、後述にてさらに説明するように、ユーザグループによって異なる被リクエストコンテンツの幅を反映した適切な制御を可能にする。
【００１５】
本発明の別の態様は、コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシュの制御方法であって、ユーザグループによるコンテンツリクエスト履歴情報を取得するステップと、前記コンテンツリクエスト履歴情報に基づき、リクエスト回数とその後の目標リクエスト回数達成確率との関係を求めるステップと、前記目標リクエスト回数未満のリクエスト回数を対象として、前記目標リクエスト回数達成確率と前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求めるステップと、前記期待値が最大になるときのリクエスト回数をコンテンツ抽出閾値に設定するステップと、前記ユーザグループによるコンテンツのリクエスト回数を監視し、あるコンテンツのリクエスト回数が前記コンテンツ抽出閾値まで増大したときに前記コンテンツをキャッシュサーバにキャッシングさせるキャッシュ制御を行うステップと、を含む。
【００１６】
本発明の別の態様は、コンテンツリクエスト増大量の予測方法であり、ユーザグループによるコンテンツリクエスト履歴情報を取得するステップと、前記コンテンツリクエスト履歴情報に基づき、リクエスト回数とその後の目標リクエスト回数の達成確率との関係を求めるステップと、前記目標リクエスト回数未満のリクエスト回数を対象として、前記目標リクエスト回数達成確率と前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求めるステップと、を含む。
【００１７】
本発明の別の態様はキャッシュシステムであり、コンテンツ配信ネットワーク上で提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリと、ユーザグループによるコンテンツのリクエスト回数をカウントするリクエスト回数カウンタと、前記リクエスト回数カウンタによりカウントされたリクエスト回数が所定のコンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングさせるキャッシュ制御部と、を含む。上述の構成がキャッシュサーバに設けられるとき、そのキャッシュサーバが単独で本態様のキャッシュシステムであってよい。また、上述の構成がコンテンツ配信サービス上で分散されるとき、それらが本態様のキャッシュシステムであってよい。
【００１８】
好ましくは、キャッシュシステムは、前記ユーザグループによるコンテンツリクエスト履歴情報を解析することにより前記コンテンツ抽出閾値を求める解析部を含む。好ましくは、前記解析部は、前記コンテンツリクエスト履歴情報から得られるリクエスト増大の期待値が最大になるときのリクエスト回数を前記コンテンツ抽出閾値として求める。
【００１９】
本発明の別の態様は、コンテンツ配信ネットワークを介して提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリを有するキャッシュサーバであって、ユーザグループによるコンテンツのリクエスト回数が所定のコンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングするように制御される。
【００２０】
本発明の別の態様は、コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシングを制御するキャッシュ制御装置であって、ユーザグループによるコンテンツのリクエスト回数をカウントするリクエスト回数カウンタと、前記リクエスト回数カウンタによりカウントされたリクエスト回数が所定のコンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュサーバにキャッシングさせるキャッシュ制御部と、を含む。本態様のキャッシュ制御装置は、コンテンツ配信ネットワーク上の局所的な装置で構成されてもよく、分散された複数の装置で構成されてもよい。
【００２１】
本発明の別の態様は、コンテンツ配信ネットワークを介して提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリに関連して用いられる、コンピュータにて実行可能なプログラムであって、ユーザグループによるコンテンツのリクエスト回数をカウントし、リクエスト回数が所定のコンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングさせるキャッシュ制御を前記コンピュータに実現させる。本発明の別の態様は、上述のプログラムを記録した、コンピュータにて読取可能な記録媒体である。
【００２２】
さらに、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、サーバ、システム、コンピュータプログラム、記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【００２３】
【発明の実施の形態】
以下、本発明についてさらに説明する。以下では、まず、「ユーザクラスタリング機構を用いたコンテンツ自動配信システムの構築」の提案について詳細に説明する。その後に、同技術を適用したキャッシュサーバで構成されるシステムの実施形態について説明する。
「ユーザクラスタリング機構を用いたコンテンツ自動配信システムの構築」
１．コンテンツ自動配信システムの構築に関する説明の全体概要を説明する。
以下では、まず、ＣＤＮ（コンテンツ配信ネットワーク）の概要を説明し（２章）、それから、本提案システムについて説明する（３章）。ここでは、本提案システムの位置づけ（３．１節）、具体的手法（３．２〜３．５節）、試作機の構成（３．６〜３．７節）を説明する。さらに、試作機による実験および評価を説明する（４章）。
【００２４】
２．ＣＤＮ（Content Distribution/Delivery Network）
ＣＤＮとは、ネットワークエッジに配備されたサーバをむすんだサーバネットワークを用いてインターネットの渋滞や遅延を解消するソリューションである。既に述べたように、１９９９年に米Akamai社がはじめたコンテンツ・デリバリー・ネットワークがはじまりであり、その後今日に至るまで多くのＣＤＮプロバイダが生まれている。本章では、ＣＤＮのアーキテクチャおよびプロトコルについて説明する。
【００２５】
２．１ ＣＤＮアーキテクチャおよびプロトコル
ＣＤＮはコンテンツ提供者とエンドユーザとの間に位置し、コンテンツ配信を効率化するために様々な機能を果たす。ＣＤＮを構成する主な機能には次がある。すなわち、リクエスト・ルーティング、ディストリビューション、アカウンティングおよびコンテンツ・アダプテーションである。
【００２６】
２．１．１ リクエスト・ルーティング（Request Routing System）
リクエスト・ルーティングとは、分散された多数のサロゲートの中から最も適切な１つを選び出し、そこへエンドユーザからの要求を誘導することである。単純な例として、BIND（参考文献：Paul Albitz and Cricket Liu, DNS & BIND Third Edition, O'REILLY, 2000）のラウンドロビン機能による負荷分散がある。しかしこの方式はアクセスを順に振り分けるだけであり、サーバやネットワークの混雑度に応じた負荷分散機能はない。サロゲートの中から最適なものを選択するためには様々な条件を考慮しなければならず、以下のようなものが考えられている。・サロゲートのＣＰＵ負荷、応答時間、・サロゲートにおけるコンテンツのキャッシュ状況、・サロゲートのカバーするコンテンツ種類、・ユーザとサロゲート間のネットワーク混雑度、パケット損失率、回線速度、・サロゲート運用者、ＩＳＰ、コンテンツ提供者等関係者間での契約関係。
【００２７】
リクエスト・ルーティングシステムには、上で挙げた情報を関係する機器の間で常時交換し、最新のパラメータを保持することが求められる。
【００２８】
現在リクエスト・ルーティングについては多くの手法が考案されているが、ＩＥＴＦ（Internet Engineering Task Force）のＣＤＩ（Content Distribution Internetworking）ＷＧにおいてもこの技術が検討されている（参考文献：B. Cain, F. Douglis, M. Green, M. Hofmann, R. Nair and D. Potter, O.Spantscheck. Known CDN Request-Routing Mechanisms. Draft-cain-cdnp-known-request-routing-02.txt. June 2001）。
【００２９】
２．１．２ ディストリビューション（Distribution System）
プロキシ・キャッシュ・サーバへのコンテンツ配信は、エンドユーザからの要求により受動的に行われるが、それだけでは効率が悪い。複数のキャッシュサーバ間で通信を行い、それらが近隣のキャッシュサーバからコンテンツを複製する方式など、効率的にコンテンツを配信するための研究がＩＲＣａｃｈｅプロジェクトを中心に行われ、いくつかのプロトコルが提案された（参考文献：P. Vixie and D. Wessels. Hyper Text Caching Protocol (HTCP). RFC2187. September, 1997）、（参考文献：V.Valloppillil and K.W.Ross. Cache Array Routing Protocol v1.0. draft-vinod-carp-v1-03.txt February, 1998）。
【００３０】
ＣＤＮにおけるサロゲートでは、さらにコンテンツ提供者側による積極的あるいは戦略的にコンテンツ配信制御が行われる。さきがけ的存在として、Ａｋａｍａｉ社が開発したＦｒｅｅＦｌｏｗがある。さらに、サロゲート間での通信に専用回線や衛星回線などを活用し、コンテンツ配信の効率化を行う企業も現れてきている。
【００３１】
２．１．３ アカウンティング（Accounting System）
一般的に、インターネットを介して情報を提供しようという場合にはＡＡＡ（Authentication, Authorization, Accounting）の３つの処理が必要である。それぞれ「認証」「許可」「課金」という意味である。認証は相手が誰であるかを確認することであり、許可は確認された相手に対してどのような権限を与えるか制御することであり、課金は料金計算のための情報収集、料金請求などの処理である。これら３つを総合的に議論する場として、ＩＥＴＦにはＡＡＡワーキンググループがある。このＷＧの目標は、多様なアプリケーションに共通に使用可能な汎用性のあるＡＡＡのためのプロトコルを定義することにある。
【００３２】
２．１．４ コンテンツ・アダプテーション（Content Adaptation）
エンドユーザの嗜好や特性、使用する機器のスペックなどに合わせてコンテンツを修正／加工することを、コンテンツ・アダプテーションといい、コンテンツ配信の付加価値を高めることを期待されている。コンテンツ・アダプテーションの例を示すと、１）言語の翻訳、２）メディアタイプの適応、３）ユーザ特性に合わせた広告挿入、４）地域データの挿入、５）ウィルス・スキャンである。
【００３３】
しかし、サロゲートにおいてコンテンツの適応をどこまで行うことができるかという問題もある。デジタル著作権の管理技術は現在十分に発展しておらず、法整備もなされていないため、この問題は解決されるに至っていない。ＣＤＮがビジネスとして発展するためには、この問題に早急に取り組まなければならないといわれている。
【００３４】
３．提案システム
この章では、本提案システムの構成と、それを実現するための方法、本システムを実装した試作機の構成などについて説明する。
【００３５】
３．１ 提案システム概要
本提案システムの目的は、アプリケーションからＣＤＮを低コストで使用できるようにすることである。低コスト化を図るためには、第１に設備投資を減らす必要がある。本システムは完成後にフリーソフトウェアとして配布することが好ましいと考えられる。ＣＤＮプラットフォームを広く浸透させることによって、アプリケーション開発の活性化が期待できる。本システムの構成を図１および図２に示す。
【００３６】
ディストリビューションシステムは、本システムを組込んだサーバ（Distribution Server,以下ＤＳ)群から成り、各サーバは自律的に協調し、コンテンツを複製し合う。キャッシュサーバ（ＣＳ）はＤＳに含まれる。また、オリジンもディストリビューションシステムに含まれる。協調関係については全てのサーバが同等であり、図２にそれを示す。
【００３７】
リクエストルーティングシステムは、ユーザ（アプリケーション）からの名前解決に対して応答するシステムである。コンテンツの名前と所在を保持し、これらはディストリビューションシステムからの登録によって更新される。ＤＮＳ（Domain Name Service）サーバとほぼ同等の役割を負う。
【００３８】
図１について説明すると、（１）オリジン（Ｗｅｂサーバに限らず情報の発生源という意味）は、リクエストルーティングシステムへコンテンツ（名前、場所）を登録する。（２）コンテンツの場所を問い合わせる。（３）登録リストの中から最も適切と思われる場所を応答として返す。（４）（３）の結果がオリジンサーバだった場合、オリジンサーバへリクエストする。（５）コンテンツの取得が行われる。（６）オリジンはコンテンツの複製を行なうために、複製先サーバリストを取得する。（７）複製ポリシーに基づいてコンテンツの複製を行う。（８）コンテンツを受け取ったサーバはリクエストルーティングシステムへ、コンテンツ（名前、場所）を登録する。（９）リクエストルーティングシステムから複製先サーバリストを取得する。（１０）複製先サーバの方がオリジンサーバよりもエンドユーザに近い場合は、複製先サーバへリクエストする。（１１）コンテンツの取得が行われる。
【００３９】
３．２ 提案システムの具体化
ここでは、主としてディストリビューションシステムについて説明する。ディストリビューションシステムの役割は、最適なコンテンツ配信を行うことである。３．２．１では本システムにおける「最適なコンテンツ配信」の意味について述べ、３．２．２でその実現手法、３．２．３では本システムで用いる具体化について述べる。
【００４０】
３．２．１ 最適なコンテンツ配信
コンテンツ配信における「最適」という言葉には様々な意味があり、配信側か受信側かによっても意味が異なる。ここでは、配信側と受信側における「最適なコンテンツ配信」の意味について述べる。ただし、ここでは、狭義のコンテンツ配信（コンテンツの配送方法）について説明する。
【００４１】
まず、受信側（つまりはユーザ側）から見た最適なコンテンツ配信であるが、エンドユーザに対しての応答速度が最速であるような配信を最適ということもあれば、エンドユーザへジッタのない安定したデータ転送ができる配信を最適ということもある。いくらジッタのない安定したデータ転送でも、応答速度が非常に遅い場合は最適とはいえず、逆に応答速度がいくら高速でもデータ転送が途切れてしまっても最適とはいえない。また、応答速度が高速でジッタもなかったとしても、一度に転送できるデータ転送量が小さければ最適とはいえない。このように、最適となるための必要条件を挙げればキリがなく、全ての条件を満足することなど不可能に近い。そこで、インターネットにおいては、ある１つのサービスを提供するために最低限必要な品質をＱｏＳ（Quality of Service）とよび、このＱｏＳを満たせば「最適」となる。つまり、最適なコンテンツ配信とはＱｏＳを満足する配信である。
【００４２】
しかし、ベストエフォート型のインターネット上、特にネットワーク的に離れた地域間による「Ｅｎｄ ｔｏ Ｅｎｄ」での通信ではＱｏＳ実現すら難しく、ＲＳＶＰやＤｉｆｆｓｅｒｖ、ＭＰＬＳなどの技術を用いたソリューションが期待されていた。だが、この流れはＣＤＮの登場によって大きく流れが変わることになる。「Ｅｎｄ ｔｏ Ｅｎｄ」という概念を戦略的にインターネットに持ち込むことによって、ＱｏＳ実現を可能にした。ネットワークエッジに配置されたサーバ、つまりエンドユーザに近いサーバからコンテンツを配信することによって、混雑する回線や遅い回線を回避し、応答速度が高速でスループットの高いデータ転送をジッタもエラーもなく行えることを意味する。まとめると、ＣＤＮを用いれば、ＱｏＳ保証されたサービスが可能であり、受信側にとって最適なコンテンツ配信が行えるといえる。
【００４３】
次に、配信側にとって最適なコンテンツ配信についてであるが、受信側にはない条件が必要となる。それは、コンテンツ配信資源の効率的活用である。配信側の立場では、コンテンツ配信にかかるコストよりも得られる利益が少ないと、コンテンツ配信を行う意味がなくなってしまうからである。ここでいうコストとは、コンテンツ配信に必要となるあらゆるもので、ディスク／メモリ使用量やコンテンツ複製トラフィック、計算負荷などであり、配信側は利益を高めるためにはコストの最適化を行う必要がある。つまり、コストの最適化を行いつつ、ユーザへ近いサーバへコンテンツを配置することが、配信側にとっての「最適なコンテンツ配信」といえる。
【００４４】
３．２．２ 最適なコンテンツ配信の実現手法
３．２．１で最適なコンテンツ配信とは「コストの最適化が行われたＣＤＮである」と説明したが、それに対して本システムがとるアプローチを述べる。本システムはコストの最適化を行うために「多く必要とされるコンテンツを、多く必要とするユーザから、最も近いサーバへ」というコンセプトに基づいて設計する。
【００４５】
コンテンツ複製対象を、多く必要とされるコンテンツに限定することで大きなコスト削減効果が見込まれる。図３〜図８は、それぞれ異なったプロキシサーバのアクセスログを解析した結果である。図３と図４、図７は研究室で使用しているプロキシサーバ（Ｓｑｕｉｄ）、図５と図６、図８は情報工学科のプロキシサーバ（Ｓｑｕｉｄ）のものである。ユーザのリクエスト傾向としてわかるのは、リクエスト回数の少ないコンテンツ数の割合は非常に高いがそれらに対するリクエスト数の割合はそれほど高くなく、リクエスト回数の多いコンテンツはコンテンツ数の割合は少ないがリクエスト数の割合が高いということである。図６を基にして考えれば、２回以上リクエストされたコンテンツをキャッシュすることにするだけで、６６．２３％のディスク／メモリ使用量が削減できる。また、３．４節で詳しく述べるが、リクエストの多いコンテンツは、その後もリクエストされる可能性が高いので、リクエストの多いコンテンツのみでコンテンツの複製を行う。
【００４６】
次に、コンテンツを必要としているユーザに近いサーバに限定してコンテンツを複製する理由を説明する。これは、リクエストのネットワーク的な偏りを利用しようというものである。インターネットには数多くのネットワークが相互接続されており、ネットワークによってユーザ数もリクエスト傾向も違う。全てのネットワークを同じように捉えるのではなく、ネットワーク単位で捉えることによってそのネットワークに特化したコンテンツ配信が行える。よって、ネットワーク単位でリクエストを解析することは重要であり、コンテンツの複製はネットワーク毎（つまりネットワークに一番近いサーバ）に行うべきである。ネットワークの分割の仕方、つまりはユーザのグルーピング方法については３．３節で説明する。
【００４７】
３．２．３ 実現手法の具体化
本システムにおいて用いる手順について説明する。本システムは大きく分けて３つの手順をふんでコンテンツの複製が行われる。このような手順をふむ理由は３．２．２で説明した通りである。３つの手順は、（１）ユーザクラスタリング（ユーザのグループ化）、（２）リクエストの多いコンテンツの抽出、（３）最適サーバ選択である。（１）については３．３節、（２）については３．４節、（３）については３．５節で説明する。
【００４８】
（ポリシーについて）
後に詳細に述べるように、本提案システムでは、ＣＤＮにポリシーが組み込まれる。 ポリシーは複製モジュールとのインタフェースに従いさえすればどのようなものでもよく、様々なアルゴリズムが適用可能である。
【００４９】
今回提案するポリシーは「コンテンツ配信におけるコストを削減」というものである。既存のＣＤＮの目的が単純に「利益の最大化」というものであるのに対して、本提案ポリシーはコストの無駄を省くということが目的となる。ここでいう利益とは、エンドユーザからＣＳ（ＤＳ）へ行われるリクエスト数のことである。コンテンツ配信においては、より多くのリクエストに対応できるということが利益といえる。提案ポリシーを実現するために求められる条件を３つ示す。（１）利益を多く生む場所（地域）の把握、（２）利益の高いコンテンツの抽出、（３）最適なサーバにコンテンツを複製である。これら条件（１）〜（３）を満足するために、上述の３つのアルゴリズムがそれぞれ有利に用いられる。すなわち条件（１）にはユーザクラスタリングが対応し、条件（２）には選択的コンテンツ抽出が対応し、条件（３）には最適サーバ探索が対応する。
【００５０】
３．３ ユーザクラスタリング
本システムにおけるユーザクラスタリングとは、ユーザを共通のポリシーによって管理されているネットワーク単位によってグループ化することである。ここで用いられる好適なクラスタリングアルゴリズムは、「Balachander Krishnamurthy and Jia Wang. On Network-Aware Clustering of Web Clients. In Proceedings of ACM SIGCOMM, August 2000.」である。このアルゴリズムは、ＢＧＰ（Broader Gateway Protocol）ルーティングテーブルのスナップショットを用いてユーザのクラスタリングを行う（K.Lougheed and Y.Rekhter. A Border GateWay Protocol. RFC1163, IETF, June 1990.）。ルーティングテーブルのエントリーをクラスタリングの単位とすると、ＢＧＰルーティングテーブルがネットワークの障害や変更に対応するので、クラスタリングの精度は高くなる。上述のBalachander Krishnamurthyらの実験結果によると、９９．９％のユーザがどれかのクラスターに属し、９０％以上の精度があると報告されている。クラスタリングの手順を図９に示すとともに、以下に図９について説明する。
【００５１】
「ＩＰ Ａｄｄｒｅｓｓ ｅｘｔｒａｃｔｉｏｎ」： アクセスログからIPアドレスを抽出する。
【００５２】
「Ｎｅｔｗｏｒｋ ｐｒｅｆｉｘ ｅｘｔｒａｃｔｉｏｎ（Prefix extraction, unification, merging）」：ＢＧＰルーティングテーブルから、プレフィックスエントリーを抽出する。プレフィックスエントリーのフォーマットがＢＧＰルーティングテーブルによって異なるのでマージする。フォーマットには下の３種類ある。すなわち、「X1.X2.X3.X4/k1.k2.k3.k4」、「X1.X2.X3.X4/m」および「X1.X2.X3.0」である。
【００５３】
「Ｃｌｉｅｎｔ ｃｌｕｓｔｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」：ログから抽出したユーザＩＰアドレスについてＢＧＰルーティングテーブルから抽出したプレフィックスと比較し、最長一致するプレフィックスを求める。ユーザは最長一致したプレフィックスのクラスターに属すると識別される。
【００５４】
「Ｖａｌｉｄａｔｉｏｎ」：Ｎｅｔｗｏｒｋ−Ａｗａｒｅ ｃｌｕｓｔｅｒｉｎｇには、２つの理由によりクラスターが誤って求められる可能性がある。クラスターがもう１つ以上のネットワークを含んでいる場合と、１つのネットワークがいくつかのクラスターに分割されている場合である。この問題を解決するために、ｎｓｌｏｏｋｕｐとｔｒａｃｅｒｏｕｔｅを用いる。ｎｓｌｏｏｋｕｐはホストのドメイン名を問い合わせるツールである。同じプレフィックスのユーザには同じドメイン名がついている性質を利用してクラスタリングの精度を高めようというものであるが、前出のBalachander Krishnamurthyらの文献によれば、ｎｓｌｏｏｋｕｐによってドメイン名が求められる確率は５０％程度であり、nslookupだけでは問題を解決できない可能性がある。そこでｔｒａｃｅｒｏｕｔｅを適切なかたちで適用してクラスタリングの精度を高めることが好適である。ｔｒａｃｅｒｏｕｔｅはユーザまでの経路情報を得ることができるので、同じネットワークに属しているかどうかを判断することができる。
【００５５】
「Ｅｘａｍｉｎｉｎｇ ｉｍｐａｃｔ ｏｆ ｎｅｔｗｏｒｋ ｄｙｎａｍｉｃｓ」：ＢＧＰルーティングテーブルがネットワークの障害や変更に即座に更新されるので、クラスタリングをネットワークの変動に対応させることができる。「Ｓｅｌｆ−ｃｏｒｒｅｃｔｉｏｎ ａｎｄ ａｄａｐｔａｔｉｏｎ」：Ｖａｌｉｄａｔｉｏｎによって求めたクラスタリングの誤検出を修正する。1人のユーザが2つのクラスターにまたがっている場合、1つのクラスターとする。1つのネットワークがいくつかのネットワークを含んでいた場合、ｔｒａｃｅｒｏｕｔｅによって得られた結果に基づいてクラスターを分割する。
【００５６】
（グループ化の利点）
既に述べたように、ユーザクラスタリングとは、ユーザのグループ化のことである。ここで、グループ化による利点を以下に２つ挙げる。すなわち、（１）リクエスト傾向の把握がしやすい、（２）複製を効率的に行える、である。
【００５７】
（１）リクエスト傾向の把握がしやすい利点：ユーザ1人毎にリクエスト傾向を把握するよりもグループ単位で行う方が処理負荷を軽減することができ、把握しやすいものとなる。グループが類似した嗜好や特徴を持つユーザの集合だとすれば、グループ内のユーザは類似したコンテンツをリクエストする事が期待できるため、グループ単位のリクエスト傾向はユーザ単位のものと近似と考えることができる。つまり、グループ化によってユーザ単位でリクエスト傾向を把握する必要はなくなり、ユーザ単位では難しい傾向の把握をしやすくなることを意味する。
【００５８】
（２）複製を効率的に行える利点：ユーザ単位でコンテンツの複製を行うのではなくグループ単位で行うため、複製１回に対する効果を高めることができる。例えば、リクエスト傾向の異なる２つのグループがあった場合、リクエストの少ないグループに対してコンテンツの複製を行うよりも、リクエストの多いグループに対して行う方が提案したポリシーに基づいていて効率的である。既存ＣＤＮがリクエストの有無によってコンテンツの複製を行うかどうかの判断をしてきたのに対し、リクエスト数の多いか少ないかによって複製の判断を行うという本提案ポリシーにおいては、グループ化が非常に有効である。
【００５９】
このようにグループ化によってもたらされる効果は高いのだが、ここで重要なのはグループ化が何に基づいて行われて、その精度がどの程度であるかということである。今回はコンテンツ配信における最適化ということを重視し、上述したように、ネットワークトポロジーに基づいてユーザのグループ化を行うNetwork-Aware Clusteringを用いる。このアルゴリズムは、ＢＧＰルーティングテーブルのスナップショットとユーザのＩＰアドレスを使用してグループ化（クラスタリング）を行うものであり、このアルゴリズムを簡略化したものが本提案システムに好適に適用される。
【００６０】
３．４ コンテンツ抽出アルゴリズム
コンテンツを選択的に抽出するのは、最小限のコストで最大限の利益（リクエスト数）を上げるコスト最適化のためである。リクエストの多いコンテンツのみを複製対象とすることで、リクエストの少ない（利益の少ない）コンテンツに関するコストを削減することができる。しかし、この方法によるコスト最適化のためには、リクエストの多いコンテンツをリクエストされる以前に把握する必要がある。これはユーザのリクエストを予測することであり、非常に難しい問題である。なぜなら、どのコンテンツがどの程度リクエストされるのかを予測するためには、ユーザ特性を知る必要があるからである。本システムにおけるアプローチはログから確率的なリクエスト傾向を求め、それを用いてコンテンツを抽出する。
３．４．１ ユーザのリクエスト傾向
リクエスト傾向（リクエスト特性）を知る手段として、プロキシサーバのログを解析することが有効である。プロキシサーバは学校や企業などの組織の出入り口に位置し、ユーザのリクエストを代行する役割を持つ。リクエストの履歴はログとして蓄積されるので、プロキシサーバのログを解析すれば組織単位でのユーザのリクエスト傾向がわかる。図１０に示されるように、今回解析したログは研究室Ｘ、情報工学科Ｙ、大学Ｚの学生約３０００人が加入しているＩＳＰの３つである。ただし、図１０においては、不正アクセスや正規のリクエストでないものは除かれている。また、ログの解析においてユーザのプライバシーが守られなければならないことはもちろんである。
【００６１】
３つのプロキシサーバのログ解析結果より、リクエスト数が多いコンテンツは少量しかないことがわかった（リクエストが少ないコンテンツの数が多い）（図１１）。したがって、リクエストの多いコンテンツだけを抽出することによって、ディスクスペース量や管理コスト、複製に関する処理などを削減することができる。
【００６２】
図１２〜図１７は、それぞれのログから、リクエスト回数別にその後リクエストされる確率を表したものである。それぞれの図は１０回以上、２０回以上、３０回以上、４０回以上、５０回以上、１００回以上リクエストされる確率を図にしたものである。図１２を見ると、３回リクエストされたコンテンツが１０回以上リクエストされる可能性は研究室のものが約７０％、ISPが約６５％、情報工学科が約８２％だということがわかる。ばらつきがあるが、３つとも同じような対数曲線を描くことがわかる。このことから、リクエスト回数が多いほどその後リクエストされる可能性が高いことがわかり（リクエスト回数が少ないほどその後のリクエストされる可能性が低い）（図１１）、ある程度リクエストされたコンテンツはその後リクエストされる可能性が非常に高くなることがわかった。
【００６３】
３．４．２ 期待値
３．４．１で、リクエスト回数が多くなるとその後リクエストされる可能性が高い傾向があると説明した。では実際にリクエスト回数がどの程度になればコンテンツ抽出を行うべきなのかを説明する。いくら確率が高くても得られる利益（キャッシュヒットによってユーザ得られる利益）が低ければ意味がない。例えば、図１７の情報工学科のグラフを見ると、９９回リクエストされたコンテンツが１００回以上リクエストされる可能性は９９．７６４４６％であることがわかる。そこで、９９回目のリクエストで初めてコンテンツをキャッシュしたとする。もしリクエストされる回数が１００回ならば１回分しか利益を得ることしかできない。よって、「その後リクエストされる確率が高い」ではなく、「高い利益を得る確率が高い」という判断によってコンテンツを抽出する必要がある。
【００６４】
本システムにおいては、「利益を得られる確率（Ｘ回以上リクエストされる確率）」と「得られる利益（その後のリクエスト回数）」との積を求め、それとＸとの商を期待値とし、それに基づいてコンテンツ抽出を行うことにする（期待値を求めるときにＸで割らなくてもよい）。
【００６５】
期待値を表したものが図１８〜図２３である。これらの図より、あるリクエスト回数で期待値が極大値を取ること、どのプロキシサーバかによって極大値をとるリクエスト回数が異なることがわかる。それぞれのプロキシサーバによる違いは、グループ毎のリクエスト傾向の違いを表している。本システムは、極大値をグループ毎に求め、これをコンテンツ抽出閾値とする。
【００６６】
次に、図２４は、期待値が最大となるリクエスト回数をグラフにしたものを示す。横軸（Ｘ）は、図１８〜図２３における目標のリクエスト回数（１０回から１００回）である。縦軸は、期待値が極大値となるリクエスト数（コンテンツ抽出閾値）である。横軸のリクエスト回数（Ｘ）は、何回リクエストされたものを利益が高いとするかによって決まる。例えば、１００回以上リクエストされるコンテンツを利益が高いとすると、情報工学科ならばリクエスト数１３回でコンテンツを抽出すればよいことがわかる（コンテンツ抽出閾値＝１３で、期待値が最大になる）。このように、図２４より、コンテンツ抽出閾値は変数Ｘによって定まることがわかる。Ｘは、システム使用者により適宜決定されてよい。
【００６７】
図２４における近似曲線の傾きはユーザのリクエストの幅を表す。これは多数回リクエストされるコンテンツが多い場合に期待値が最大となるのが早く、少ない場合は最大となることが遅いことを根拠としている（多数回リクエストされるコンテンツが多いということは、リクエストが偏っているといえる）。よって、傾きが大きいほどリクエストの幅が広く、小さいほどリクエストの幅は狭い。この場合、情報工学科が最もリクエストの幅が狭く、ＩＳＰが最もリクエストの幅が広いことがわかる。したがって、このようなコンテンツ抽出閾値導出手法を適用することにより、グループのリクエスト傾向を反映させた閾値の設定が可能になる。閾値はＣＳのログを解析することによって求められる。なお、図２４における「ｘ」は「Ｘ／１０」である。
【００６８】
また、上述において、本システムによるコストの最適化とは、「利益の少ないコンテンツに関するコストを削減しつつ最大限の利益を上げよう」というものであり、単なる利益の最大化ではないことに注意が必要である。
【００６９】
３．４．３ クラスタリングとコンテンツ抽出
３．４．２ではコンテンツ抽出閾値の導出法を説明したが、実際の使用方法について述べる。コンテンツ抽出閾値を、３．３節で説明したユーザクラスタリングによって求めたクラスタリング毎に適用する（図２５）。クラスターが組織単位となるので、組織単位でコンテンツ閾値を求めることができ、コンテンツ抽出の精度を高めることができる（組織単位でのリクエスト傾向を反映できるので）。また、コンテンツの複製を個人単位やインターネット全体ではなくクラスター単位で行うことによって、複製回数を抑え、頻繁な複製を防ぐことができる。
【００７０】
３．５ 最適サーバ選択アルゴリズム
ユーザクラスタリングによって求めたクラスター毎にコンテンツ抽出アルゴリズムを適用し、複製するコンテンツと複製先の目標となる場所（クラスター）を導入することができた。しかし、複製を行うためには複製目標のクラスターに対して最適である複製先ＤＳを発見することが求められる。そこで最適サーバ探索が求められる。本システムにおいては、以下に説明するように、最適サーバを目標クラスターから最も近いサーバとし、単純にラウンドトリップタイム（以下、ＲＴＴ）の小さいものを近いとする。
【００７１】
複製を行なうためにはクラスターの最近隣にある複製先ＤＳ（Distributed Server、以下同じ)を発見することが望まれる。ＤＮＳサーバを用いて複製先となるクラスター側から最近隣ＤＳを発見する方法（図２６）には様々な研究および製品があるが（下川俊彦,吉田紀彦,牛島和夫. 多様な選択ポリシーを利用可能なサーバ選択機構, 電子情報通信学会論文誌 Vol.J84-D-I No.9 2001.9）、これがクラスターから遠隔にあるＤＳ単独で最近隣ＤＳを探索することになると問題は難解になる。なぜなら、クラスターから各ＤＳへの経路を把握することが、複製元ＤＳでは難しいからである（図２７）。この解決策としてＩＰルーティングのように各ＤＳが協調し合い、クラスターから最近隣ＤＳを探索する方法（図２８)を挙げることができるが、ＤＳの数が多くなると協調によるオーバーヘッドが大きくなるのであまり好ましくない。違った協調を使用したものとして、複製元ＤＳと近いＤＳから順に協調し複製する方法がある。フローチャートは図３３のようになる。この場合、協調そのものに対するオーバーヘッドは小さくて済むが複製が局所的であり、目標となるクラスターから最近隣のＤＳへコンテンツを複製するために複数回複製を要する可能性が高い（図２９〜図３２）。また、こういったアルゴリズムは複製の終了条件を設定するのが難しい。
【００７２】
上記を考慮した上で、本システムは、精度の低いＤＳ単独で探索する方法を提案し用いる。サーバ選択における「最適」または「最近隣」の定義に関して、ＲＴＴやＴＣＰスループット、サーバ処理能力、回線使用率など様々な要素を用いた研究が多いが、本システムにおいては単純にＲＴＴを用いる。ユーザクラスターから最もＲＴＴが小さい（応答速度が速い）ＤＳを最低サーバとする。
【００７３】
３．５．１ 提案最適サーバ選択方法
提案手法はｔｒａｃｅｒｏｕｔｅを基にしている。この方法は、ネットワークトポロジーが木構造または線形構造である場合には高精度で最近隣サーバを発見することができるが、リングを含むネットワークである場合には精度は保証されない。処理の流れを図３４に、イメージ化したものを図３５〜図３９に示す。ｔｒａｃｅｒｏｕｔｅを、ｗｗｗ．ＸＸＸＸＸ．ｃｏ．ｊｐといったＵＲＬに対して実行することによって経路情報とＲＴＴが得られる。
【００７４】
３．６ システムの実装方法
３．３〜３．５節で、コンテンツ複製におけるポリシーを説明した。本説では、この複製ポリシーをどのように実装するかを述べる。多様な複製ポリシーを利用可能とし、システムの柔軟性を上げる意味で、実装は柔軟であることが望ましい。そこで、本システムにおいては複製ポリシーと複製を実行するモジュールとを分離し、実装を容易化する。複製ポリシーに基づいて複製戦略をたてるモジュールを解析モジュール、複製を行なうモジュールを複製モジュールと呼ぶことにする。図４０はこれらをまとめた階層図である。このような階層をとることによって、アプリケーションは複製ポリシーを選択することが可能となる。
【００７５】
３．６．１ 解析モジュール
解析モジュールは複製ポリシーに基づいて複製戦略をたて、複製モジュールに指令を下す役割を持つ。複製ポリシーは選択可能とすることがより好適と考えられる。複製ポリシーの構成は図４１で示す。複製ポリシーはユーザクラスタリングアルゴリズム、コンテンツ抽出アルゴリズム、最適ザーバ選択アルゴリズムの３つのアルゴリズムによって構成される。組み合わせは自由とし、アプリケーションレベルで組み合わせを決められる機構を作成することがより好適と考えられる。
【００７６】
３．６．２ 複製モジュール
複製モジュールは解析モジュールの指示（どのコンテンツをどのＤＳに複製するか）を受け、それに基づいて複製を行なうモジュールである。複製モジュールには、ＤＳ間通信における認証や暗号化などのセキュリティ機能や、軽量化された通信機能が備えられることが望まれる。図４２に複製モジュールの構成図を示す。
【００７７】
（Ｐ−ＣＤＮ）
ここで、上述にて説明されるように、本発明者は、コンテンツ配信にかかるコスト削減を目的としたポリシーを既存ＣＤＮに組み込んだＰ−ＣＤＮ（Policy based CDN）を提案する。
【００７８】
Ｐ−ＣＤＮとは、アプリケーションから多様なポリシーが選択可能なＣＤＮであり、既存ＣＤＮに戦略性を持たせることができる。ポリシーとは具体的にキャッシュサーバ（ＣＤ、上述のＤＳに相当）間におけるコンテンツ配置アルゴリズムのことであり、本システムはポリシーに基づいてＣＳ間でコンテンツの複製を行う。Ｐ−ＣＤＮの特徴は以下の４つ、すなわち、（１）ポリシーに基づくコンテンツ配置、（２）ポリシーの内容は条件内で自由、（３）複数のポリシーを組込み可能、（４）ポリシーの選択は自由である。
【００７９】
Ｐ−ＣＤＮでは、既に述べたように、ポリシーと複製を実行するモジュールとが分離されることが有利でる。ポリシーに基づき複製の指令を出す解析モジュールが設けられ、さらに、複製を実行する複製モジュールが設けられる。
【００８０】
より詳細には、解析モジュールの役割は２つある。１つはアプリケーションに対してポリシーの選択性を提供することである。もう１つは、ポリシーに対してシステムが組み込まれているＣＳ（ＤＳ）やネットワークの状態を提供する役割である。ポリシーに提供される項目は、（１）ＣＰＵ使用率、（２）メモリ使用率、（３）コネクション数、（４）データ転送量、（５）ユーザからのリクエストのログ、（６）外部との通信用のメッセージ通信機能、である。
【００８１】
一方、複製モジュールはポリシーからの指令を受け、それに基づいて実際にコンテンツを複製するモジュールである。ポリシーから複製モジュールになされる指令は、以下に示す２つの要素から構成される。すなわち、（１）コンテンツの名前（ＵＲＬ）および（２）複製先サーバ名（ＩＰアドレス）である。
【００８２】
解析モジュールと複製モジュールとの分離によって様々なポリシーの開発および実装を簡単化でき、ポリシーの開発だけに専念できる環境が生まれると考える。以上、Ｐ−ＣＤＮについて説明した。
【００８３】
３．７ 試作機の構成
本章で述べてきた提案システムを実用化するために作成された、システムを実装した試作機について説明する。試作機は、ＰＣ／ＡＴ互換機で作成し、システムはＦｒｅｅＢＳＤ上に実装する。システムはキャッシュサーバソフトウェアであるＳｑｕｉｄ（Squid Web Proxy Cache）を基にして作成した。Ｓｑｕｉｄにはコンテンツのキャッシュ機能やキャッシュサーバ間通信機能があるので、コーディング作業を大幅に減らすことができる。図４３は、試作機のシステム構成図を示している。
【００８４】
３．７．１ 解析モジュールの実装
解析モジュールには、Ｓｑｕｉｄのアクセスログを解析する機能と、最適サーバ探索機能を持たせる。図４４および図４５は、解析モジュールの動作を示している。
【００８５】
図４４および図４５について説明すると、（１）Ｓｑｕｉｄのアクセスログを用いてユーザクラスタリングを行なう。ログはクラスター毎に分割される。クラスタリングに用いるＢＧＰルーティングテーブルは前もってダウンロードしておく。（２）ログ毎にリクエスト傾向を求める。リクエスト傾向によって抽出閾値を導出する。（３）閾値以上のリクエスト回数のコンテンツを抽出し、ＵＲＬを抜き出す。（４）クラスターから最も近いＤＳを探索し、ＤＳのＩＰアドレスを求める。（５）ＵＲＬとＤＳのＩＰアドレスを複製モジュールへ渡す。
【００８６】
３．７．２ 複製モジュールの実装
本来なら解析モジュールのように複製モジュールも単体で動作するように実装することが望ましいと考えられる。しかし、今回は、複製モジュールをプロキシサーバソフトウエアのＳｑｕｉｄに組込んで実装を行なった。
【００８７】
複製モジュールは解析モジュールが作成した複製先ＤＳリストを利用して、コンテンツの複製を行なうモジュールである。複製モジュールは複製先ＤＳリストを定期的にチェックしており、リストに変更があればリストから複製先ＤＳアドレスと複製するコンテンツを取得して複製動作を行なう。ＤＳ間のネゴシエーションは図４６のような内容になっている。Connection messageはＤＳ間で複製を行なうための情報の通信を行い、Request Messageはコンテンツ複製を実際に開始するための通信に利用する。Connection messageには各種メソッドが含まれており、メッセージを受信したＤＳがメソッドに合わせた処理を行なうようになっている。Connection messageのメソッドの種類にはＤＳ間でネゴシエーションを開始するときに複製元ＤＳから送られる「ICP_NEGO」、複製先ＤＳが複製可能だと複製元ＤＳに知らせる「ICP_NEGO_Y」、複製先ＤＳが複製不可能だと複製元に知らせる「ICP_NEGO_N」、複製するコンテンツのアドレスを複製先ＤＳに送るための「ICP_MOVE」がある。通信プロトコルはConnection messageの送信にはＵＤＰをRequest messageとコンテンツデータの送信にはＴＣＰを用いている。まず、リストに変更が複製元DSは複製先ＤＳリストから複製先ＤＳと複製するコンテンツを取得する。複製元ＤＳは複製先ＤＳにConnection message「ICP_NEGO」を送信しネゴシエーション要求を出し協調動作を開始する。「ICP_NEGO」を受け取った複製先ＤＳは現在の自分の状態を調べて複製可能かどうかを判断する。判断する内容はディスク残り容量、ＣＰＵ負荷、ネットワーク負荷などをもとに判断する。複製可能な場合は複製元ＤＳへ「ICP_NEGO_Y」を返し、不可能な場合は「ICP_NEGO_N」を返す。「ICP_NEGO_Y」を受けた複製元ＤＳは協調動作可能と判断し、複製先ＤＳへ「ICP_MOVE」メッセージを送信する。このメッセージには複製するコンテンツのアドレスが含まれている。また、「ICP_NEGO_N」メッセージを受け取った場合は協調動作を中止する。「ICP_MOVE」を受け取った複製先ＤＳはRequest messageを複製元ＤＳに送信し、それを受けた複製元ＤＳはコンテンツデータの送信は開始するようになっている。
【００８８】
４ 実験と評価
本提案システムを検証するために、解析モジュールと複製モジュールをインストールした試作機によって検証実験を行った。本章では、その実験環境と実験結果について述べる。
【００８９】
４．１ 実験環境
４．１．１ ネットワーク構成
図４７に今回の実験環境のネットワーク構成を示す。ルータマシン、試作機マシン(ＤＳ)、クライアントマシンはいずれも一般的なマシン(ＩＢＭ ＰＣ／ＡＴ互換機)を使用した。ルータマシンＩにはＯＳとしてＦｒｅｅＢＳＤ５．０を、ルータマシンＩＩ、ＩＩＩ、ＩＶはＦｒｅｅＢＳＤ４．２をインストールした。それぞれのルータマシンにはＮＩＣ(Network Interface Card)が複数枚装着してあり、複数のネットワークとのゲートウェイとして動作している。試作機マシンのＯＳにはＦｒｅｅＢＳＤ４．２、クライアントマシンにはＷｉｎｄｏｗｓ ＭＥ（登録商標）とＷｉｎｄｏｗｓ２０００（登録商標）をインストールした。試作機マシン、クライアントマシンにはＮＩＣが１枚装着してある。各端末間の接続速度はすべて１００ｂａｓｅＴＸで接続されている。試作機マシンにはアクセスログの解析を行うための解析モジュールとコンテンツ複製を行うための複製モジュールが実装されている。各マシンスペックは図４８に示すとおりである。マシンスペックには個体差があるが、これはＣＰＵ処理速度を故意に下げることにより、ＣＰＵの処理能力が解析処理やパケット転送処理のボトルネックとなるような環境を作っている。試作機Ａと試作機Ｂとを差別化するため、試作機ＡのＮＩＣは意図的に性能の低いものにしてある。
【００９０】
４．１．２ 実験環境詳細
実験開始段階では試作機Ａにだけコンテンツをキャッシュしてある状態にしてある。その他の試作機はコンテンツを何も持っておらず、クライアントからのアクセスがこない状態になっている。試作機Ａは一定時間間隔でアクセスログを解析し、最適なコンテンツ配置先を選択するプログラムが動作している。また、それぞれの試作機マシン上では複製モジュールが動作しており、協調を行うためのメッセージのやり取りができるようになっている。
【００９１】
実験では図４９のように、各クライアントから試作機Ａへリクエスト要求を複数回送っている。実験ではクライアントマシンからのアクセス要求をクライアントグループからのアクセスと見立てて、解析モジュールでクラスタリングを行うようになっている。アクセス回数はクライアントαよりクライアントβが多く要求を出すパターンと少なく出すパターンで行った。取得するデータはコンテンツ複製前とコンテンツ複製後で試作機からクライアントマシンへのＨＴＴＰレスポンスタイム等のデータを取り、提案システムや解析モジュールの有効性をデータとして示す。
【００９２】
今回の実験は、複製ポリシーとして設定してある一連のアルゴリズムに基づいてコンテンツ複製が行われるかを検証するためのものなので、ユーザクラスタリングアルゴリズムとコンテンツ抽出アルゴリズムは単純化してある。
【００９３】
実験環境で使用されるマシンに割り振られるＩＰアドレスがプライベートＩＰアドレスなので、外部のＢＧＰルーティングテーブルを用いたクラスタリングが行えない。よって、クラスタリングはプレフィックスを２４ｂｉｔ固定として行う。
【００９４】
３．４節で説明したコンテンツ抽出アルゴリズムは、ログが充分に蓄積された状態でなければアルゴリズムの精度が保証されない。そのため、ログの蓄積数が少ない場合は予め固定の閾値を設定しておき、その閾値を用いてコンテンツ抽出を行う。今回は、１０回を閾値として設定した。コンテンツ抽出アルゴリズムは、ログ数が例えば１０００行以上になった時に初めて動作するように構成される。
【００９５】
４．２ 実験結果
４．１．２節の実験環境での検証では図５０に示すデータを得ることができた。今回の検証では複製閾値を１０回としているので、アクセス回数が１０回を超えたところからグラフに変化が現れている。図５０に示すアクセス時間はクライアントβからコンテンツにアクセス要求を出してから、コンテンツデータの先頭がクライアントに届くまでの時間である。実験開始直後はクライアントのアクセス要求はすべて試作機Ａへ送られる。アクセス解析によりコンテンツの複製が起こった後は、クライアントβからのアクセスはレスポンスのよい試作機へ送られるようになる。図５０のグラフのからもわかるように、クライアントβから試作機Ａまでのレスポンスタイムと、コンテンツ複製が起こり複製先の試作機へアクセス要求を送ったレスポンスタイムでは複製先試作機にアクセスしたほうがレスポンスタイムが短いことがわかる。今回の検証でのコンテンツの複製された動作は、クライアントα、βからのアクセスを試作機Aが解析しアクセスの多いクライアントβに近いところにコンテンツを複製しようとしコンテンツの複製を行った。図５１のように解析モジュールが最適サーバを選択し、試作機Ｃが最適だと判断しコンテンツを複製し、コンテンツ複製後からは図５２のようにクライアントβは試作機Ｃにアクセスするようになるために、レスポンスタイムが短くなっているのである。図に示してはないが、クライアントαのリクエスト数がクライアントβより多い場合でも同じように、レスポンスタイムが短くなっている。これは試作機Ａより試作機ＢのほうがＣＰＵ能力がよいので、コンテンツが試作機Ｂへ複製され、クライアントαのアクセス要求も試作機Ｂに送られるようになったためである。
【００９６】
４．３ 評価
図５０に示されるように実験結果から提案システムの有効性を示すことができた。図５０よりコンテンツ複製前よりコンテンツ複製後のほうがクライアントへのレスポンスが向上していることがわかる。これは、複製前のサーバより解析モジュールによって選ばれた複製後のサーバのほうがクライアントに近いからということが言える。このことから、解析モジュールの最適サーバを選択するアルゴリズムが有効だといえる。提案システムでは自律的にクラスター毎のアクセス傾向を解析し、クラスタリングされたクライアントグループの近くにアクセスの多いコンテンツを自動的に配置することができる。クライアントグループごとにアクセスの多いコンテンツを近くのサーバに複製することによって、オリジンサーバまでコンテンツをアクセスしに行かなくても済むので、レスポンスタイムが短くなる。また、コンテンツが複数配置されることになるので、オリジンサーバの負荷分散やトラヒックの軽減を行うことができる。また、この提案システムはフリーソフトとして配布されてもよい。ＣＤＮプラットフォームを誰もが利用することができ、ＣＤＮを用いたアプリケーションの開発を促進することができると考えられる。
【００９７】
（評価項目と確認）
ここで、評価項目とその達成の確認を行う。評価項目として、（１）閾値によって複製が行えるか、（２）（１）がクラスター毎に行えるか、（３）最適サーバが探索されているか、を挙げる。
【００９８】
図５３は、図５０と同様の図である。図５３より、閾値による複製によってクライアントβに対する応答速度が向上しているのがわかる。これは、閾値を境にクライアントβに最も近い試作機Ｃにコンテンツが複製され、クライアントβのリクエストが試作機Cに対して行われるようになるからである。これで評価項目（１）と（２）が満足された。
【００９９】
また、図５４は、ルータＩＶと試作機Ｃを一定時間高負荷状態にした時のクライアントβに対する応答速度の変化を表したものである。試作機Ｃが高負荷状態であるために、まず試作機Ｂにコンテンツが複製され、その後試作機Ｃに複製されているのがわかる。この実験によって評価項目（３）も満足された。
【０１００】
５．以上に説明したように、ユーザクラスタリング機構を用いたコンテンツ自動配信システム、Ｐ−ＣＤＮの提案を行った。ユーザクラスタリング機構を用いることによって、ユーザをクラスターに分割することができ、それぞれのクラスターに特化したコンテンツ配置戦略をたてることができることを説明した。本システムを実装した試作機による検証実験では、複製ポリシーに基づいて動作することが確認された。複製ポリシーのコンテンツ抽出アルゴリズムによりコンテンツ抽出、複製が適切に行われた。
【０１０１】
「キャッシュサーバ」
次に、上述の技術が適用されたキャッシュサーバを含むシステムの実施形態を説明する。キャッシュサーバは上述のディストリビューションサーバ（ＤＳ）に対応する。この実施形態には、主として、上述した技術のうちの、期待値に基づくコンテンツ抽出アルゴリズムが適用されている。
【０１０２】
図５５は、キャッシュサーバを含むＣＤＮの構成図である。コンテンツプロバイダはコンテンツをユーザに提供するサーバである。コンテンツレシーバはインターネットを介してコンテンツプロバイダが提供するコンテンツを受信して利用するユーザの端末である。インターネットには複数のネットワークノードが含まれ、コンテンツプロバイダからコンテンツレシーバへ提供されるコンテンツのデータを中継するルータとして機能する。
【０１０３】
図５５において、ユーザグループ１０は、例えば、ある大学に属する複数のコンテンツレシーバを含む。ネットワークノード１２は、ユーザグループ１０の近傍に位置している。そして、ネットワークノード１２には、本実施形態のキャッシュサーバ１４が一体的に設けられている。キャッシュサーバ１４は、ユーザグループ１０のために、コンテンツプロバイダから提供されるコンテンツをキャッシュメモリに格納し、これによりキャッシングが行われる。なお、図示されないが、キャッシュサーバは他のネットワークノードにも設けられていてよいことはもちろんである。
【０１０４】
図５６は、キャッシュサーバ１４の構成を示している。キャッシュサーバ１４は、第１通信部２０および第２通信部２２を有する。第１通信部２０はネットワークと通信し、第２通信部２２はローカル側（ユーザグループ）と通信する。第１通信部２０および第２通信部２２は、ハードウエア構成としては同一でよい。
【０１０５】
キャッシュメモリ２４は、キャッシュメモリ制御部２６の制御の下で、キャッシングのためにコンテンツを格納する。すなわち、コンテンツがキャッシュメモリ２４に複写され、これによりキャッシングが行われる。キャッシュメモリ制御部２６は本発明のキャッシュ制御部として機能する。
【０１０６】
リクエスト回数カウンタ２８は、ユーザグループ１０によるリクエストの情報を入手して、コンテンツのリクエスト回数を計測する。各々のコンテンツのリクエスト回数がカウントされる。カウント値は図示のようなテーブルに書き込まれる。このようにして、ユーザグループ１０によるコンテンツのリクエスト回数とその増大が監視される。
【０１０７】
許可カウントテーブル３０は、目標カウントと許可カウントを対応づけるテーブルである。目標カウントは、本発明の目標リクエスト回数に相当し、３．４．２節で説明した図２４の横軸に相当する。許可カウントは、図２４の縦軸に相当し、期待値が最大になるときのリクエスト回数である。
【０１０８】
既に説明したように、期待値は、目標リクエスト達成確率と残リクエスト回数の積で表される。目標リクエスト回数達成確率は、リクエスト回数ｎから目標リクエスト回数（目標カウント）Ｘに到達する確率であり、残リクエスト回数は、リクエスト回数ｎから目標リクエスト回数（目標カウント）Ｘまでの残リのクエスト数、すなわち、Ｘ−ｎである。
【０１０９】
本実施形態では、予め、ユーザグループ１０のリクエストのログが、適当な期間に渡って解析される。例えば、２ヶ月間のログが解析される。この解析結果に基づき、期待値の情報が求められる。そして、図２４のテーブルのデータがキャッシュサーバに予め入力され、保持されている。
【０１１０】
また、図２４を参照して既に述べたように、リクエスト特性、特にリクエストの幅（バリエーション）がユーザグループによって異なる。そして、期待値を最大にするリクエスト回数もユーザグループによって異なる。この点に関して、本実施形態の許可カウントテーブル３０は、対象のグループの解析結果から得られたデータ、すなわち対象のグループの特性を反映するデータを保持している。
【０１１１】
図５６に戻り、指定ＵＩ（ユーザインターフェース）３２は、キーボード等のデバイスを用いて入力された目標カウントを受け付ける。目標カウントはキャッシュメモリ制御部２６により取得される。キャッシュメモリ制御部２６は、許可カウントテーブル３０を参照し、目標カウントに対応する許可カウントを求める。この許可カウントは、キャッシュメモリ制御部２６により保持され、コンテンツ抽出閾値として、すなわちキャッシュ条件として、キャッシングの制御に用いられる。すなわち、以下に説明するように、あるコンテンツのリクエスト回数が許可カウントに達したとき、キャッシュ条件が成立し、コンテンツのキャッシュが許可され、キャッシングが行われる。
【０１１２】
次に、図５６のキャッシュサーバ１４によるキャッシングの動作を説明する。上述のように、リクエスト回数カウンタ２８は、ユーザグループ１０によるコンテンツのリクエスト回数を計測する。例えば、ユーザグループ１０を構成する一の端末からＵＲＬ１というコンテンツが初めてリクエストされたとき、ＵＲＬ１のカウント値として１がテーブルに記録される。その後、ユーザグループ１０の端末からＵＲＬ１がリクエストされるたびに、テーブル中のカウントが１ずつ増やされる。
【０１１３】
キャッシュメモリ制御部２６は、ユーザグループ１０の端末からコンテンツがリクエストされたとき、リクエスト回数カウンタ２８のテーブルを参照する。そして、キャッシュメモリ制御部２６は、今回のリクエストによって、コンテンツのリクエスト回数が許可カウントに達したか否かを判定する。上述したように、許可カウントは許可カウントテーブル３０を参照することによって得られる。そして、キャッシュメモリ制御部２６は、リクエスト回数が許可カウントに達した場合、コンテンツデータをキャッシュメモリ２４に格納することで、コンテンツをキャッシングする。
【０１１４】
例えば、上述のＵＲＬ１がリクエストされたとき、この情報がキャッシュメモリ制御部２６に取得される。キャッシュメモリ制御部２６は、現在のＵＲＬ１のカウント値を、リクエスト回数カウンタ２８から求める。そして、キャッシュメモリ制御部２６は、今回のリクエストにより、リクエスト回数が許可カウントに達するか否かを判定する。すでに許可カウントから１を引いた値までリクエスト回数が到達している場合、今回のリクエストにより、リクエスト回数が許可カウントに到達する。そこで、キャッシュメモリ制御部２６は、リクエストされたコンテンツデータをキャッシュメモリに格納する。キャッシュサーバを通過するときにコンテンツデータがキャッシュメモリに格納される。
【０１１５】
以上のようにして、本実施形態は、コンテンツのリクエスト回数の増大を監視して、リクエスト回数が許可カウント（コンテンツ抽出閾値）まで増大することによりキャッシュ条件が満たされるのを待ってからコンテンツをキャッシュサーバにキャッシングさせる。したがって、コンテンツの増大が見込める適当なコンテンツをキャッシングできる。１度だけしかリクエストされないようなコンテンツの無駄なキャッシングが回避され、コストを削減できる。
【０１１６】
また、本実施形態は、リクエスト特性に基づいた適切なキャッシング制御を行っている。特に、本実施形態は、上述のように、リクエスト増大の期待値に基づいたコンテンツ抽出閾値（許可カウント）を用いており、これにより好適な制御が行われる。
【０１１７】
すなわち、コンテンツ抽出閾値を大きく設定すると、その後のリクエストの確率は高いものの、リクエスト回数自体が少なくなり、キャッシングの効果が少なくなる。一方、コンテンツ抽出閾値を小さくしすぎると、リクエスト回数が伸びないコンテンツを無駄にキャッシングする可能性が高くなる。このような点を考慮した上で、本実施形態は、期待値に基づきコンテンツ抽出閾値を設定している。その結果、リクエスト回数の増大が見込めるコンテンツを早めの適切なタイミングでキャッシングすることができ、コスト削減が図れる。
【０１１８】
なお、本実施形態では、キャッシュサーバ１４はネットワークノード１２と一体化されていた（図５５）。しかし、本発明はこれに限定されない。キャッシュサーバ１４はネットワークノード１２の外側に付属してもよい。
【０１１９】
また、図５５には示されないが、他のユーザグループについても同様に本発明のキャッシュ制御技術が適用されてよいことはもちろんである。このとき、一つのキャッシュサーバが複数のユーザに対応してもよい。
【０１２０】
また、本実施形態では、図５５に示されるように、ユーザグループに近いキャッシュサーバがコンテンツをキャッシングしている。これに対し、アクセス時間が多少長くなるものの、本発明の範囲内で、ユーザグループからより遠くのキャッシュサーバが用いられてもよい。
【０１２１】
また、本実施形態では、すべてのコンテンツに関して、目標カウントおよび許可カウントが一定であった。これに対し、コンテンツの種類が判別可能なとき、目標カウントおよび許可カウントをコンテンツに応じて異ならせる制御が行われてもよい。例えば、コンテンツのジャンルに応じた制御を行うことが好適と考えられる。
【０１２２】
また、キャッシュサーバ１４の指定ＵＩ３２は、目標カウントを入手した。そして、キャッシュサーバ１４内で、許可カウントテーブル３０を参照して、許可カウントが求められた。これに対し、指定ＵＩ３２は、許可カウントを入手してもよい。すなわち、オペレータによりキーボード等を用いて許可カウントが入力される。このとき、許可カウントテーブル３０は削除されてもよい。
【０１２３】
また、キャッシュサーバ１４は、本発明のキャッシュ制御のためのプログラムをコンピュータにインストールすることにより実現されている。さらに、このプログラムは、通信でキャッシュサーバ１４に入手されてもよく、ＣＤ−ＲＯＭ等の記録媒体からキャッシュサーバ１４に入手されてもよい。そして、キャッシュサーバ１４は、本発明のキャッシュシステムとして機能する。さらに、キャッシュサーバ１４は、本発明のキャッシュ制御装置の機能を実現し、すなわちキャッシュ制御装置を備えている。これらの点は、下記の実施形態においても同様である。
【０１２４】
また、本発明は、主として、コンテンツをキャッシュメモリに格納する部分に特徴をもつので、上述の説明では、格納されたコンテンツを活用する部分の説明は省略されている。しかし、この点に関しては、従来同様の処理が行われてよい。すなわち、格納済み（キャッシング済み）のコンテンツがユーザグループ１０の端末からリクエストされときは、キャッシュメモリ２６の制御の下で、キャッシュメモリ２４からコンテンツが読み出され、提供される。これによりアクセス時間が短縮される。その他、既に格納されたコンテンツは、ＬＦＵ（Least Frequently Used）方式またはＬＲＵ（Least Recent Used）方式等の適当な方法でキャッシュバッファから追い出される。
【０１２５】
次に、図５７は、本発明の別の実施形態におけるキャッシュサーバ１４０を示している。キャッシュサーバ１４０は、上述した構成に加えて、リクエスト履歴を解析する機能を備える。
【０１２６】
図５７において、リクエスト履歴情報取得部４０は、コンテンツのリクエスト履歴の情報を取得する。リクエスト履歴情報は、キャッシュサーバ１４０自身により、リクエストを監視することにより取得されてもよい。また、リクエスト履歴情報は外部から通信等で入手されてもよい。例えば、前述したように、ユーザグループのプロキシサーバでのアクセスログが、履歴情報として有用である。
【０１２７】
キャッシュサーバ１４０はさらに解析部４２を有する。解析部４２は、リクエスト履歴の情報を取得する。解析部４２は、既に説明したコンテンツ抽出アルゴリズムに従った処理を行う。すなわち、期待値算出部４４が、目標リクエスト回数の達成確率を求め（図１２〜図１７）、期待値を求める（図１８〜図２３）。そして、期待値に基づき、許可カウントテーブル３０が作成される。既に説明したように、許可カウントテーブルは、図２４のグラフに相当するデータをもち、目標カウント（目標リクエスト回数）と、最大の期待値を与えるリクエストの関係求める。
【０１２８】
さらに、解析部４２において、許可カウント決定部４６は、指定ＵＩ３２を介して、目標カウントの指定値を取得する。この指定値に対応する許可カウントが求められる。許可カウントはキャッシュメモリ制御部２６に伝えられ、キャッシング制御に使われる。
【０１２９】
図５７のキャッシュサーバ１４０のキャッシング動作を説明する。初期段階では、期待値および許可カウントを求められるだけの十分な量のリクエスト履歴が得られていない。そこで、キャッシュメモリ制御部２６は、デフォルト値の許可カウントを用いる。
【０１３０】
デフォルト値の許可カウントは、複数種類でもよい。そして、ユーザグループの種類に対応するデフォルト値が選択されてもよい。例えば、研究室、学部、大学といったグループの規模または他の性質に応じて異なるデフォルト値が設定される。好ましくは、グループ規模等に応じた適当な許可カウントが、予め統計的に求められ、使用される。この許可カウントは、図２４を用いて説明したグループ間のリクエスト幅の相違を反映しており、好適である。
【０１３１】
リクエスト履歴情報が十分な量に達したか否かは、例えば、履歴情報の集積期間に基づき判断される。例えば２ヶ月が経過したとき、十分な履歴情報が得られたと判断される。また例えば、リクエスト総数が適当な値に達したとき、リクエスト履歴情報が十分であると判断されてもよい。
【０１３２】
リクエスト履歴情報が集まると、解析部４２が、履歴情報を解析し、許可カウントテーブルを求める。さらに、解析部４２は、指定された目標カウントに対応する許可カウントを求める。この解析部４２は、許可カウントをキャッシュメモリ制御部２６に伝える。以降、キャッシュメモリ制御部２６は、解析部４２から伝えられた許可カウントをキャッシング制御に使う。なお、解析部４２の一部または全部の構成がキャッシュメモリ制御部２６に設けられてもよい。
【０１３３】
さらに好ましくは、図５７のキャッシュサーバ１４０は、リクエスト履歴のさらなる追跡調査を行う。すなわち、リクエスト履歴から許可カウントが求められた後も、引き続き、リクエスト履歴情報が収集される。解析部４２は、引き続き得られるリクエスト履歴情報を解析して、期待値を求め、許可カウントを求める。この処理は、上述の初めて許可カウントを求める処理と同様でよい。新たに求められた許可カウントがキャッシュメモリ制御部２６に伝えられる。このようにして、本実施形態によれば、許可カウントの値を調整することができる。
【０１３４】
なお、許可カウントの調整には、前回に許可カウントを求めた後の履歴情報のみが用いられてもよい。それ以前の履歴も含めた長期間の情報が用いられてもよい。
【０１３５】
上記の調整処理によれば、グループの変化に応じて、例えば、グループの規模や年齢層の変化に応じて、キャッシュ条件（許可カウント）を好適に調整することができる。また、季節等の環境の変化に合わせたキャッシュ条件の調整も可能となる。このようにして、より一層のコスト削減効果を得ることが期待できる。
【０１３６】
以上、本発明の好適な実施形態を説明した。なお、本実施形態では、本発明を実現するための主要な機能が、主に単独のキャッシュサーバに設けられた。しかし、本発明を実現可能な範囲で、それら機能がネットワークに分散して設けられてもよいことはもちろんである。例えば、一部または全部の機能が、コンテンツプロバイダに設けられてもよく、また、コンテンツレシーバ側に設けられてもよい。
【０１３７】
また、本実施形態では、本発明が、予め決まったユーザグループおよびキャッシュサーバに対して適用されていた。そして、これにより、システムが簡略化されている。しかし、本発明の範囲内で、より自動化の進んだシステムが採用されてもよい。
【０１３８】
典型的には、まず、前出のクラスタリング分析アルゴリズム（３．３節）が組み込まれる。そして、ユーザグループ（クラスタリング）が自動的に求められる。求められたクラスタリングのリクエスト特性が分析され、キャッシュ条件に基づくキャッシング制御が行われる。
【０１３９】
また、最適サーバ選択アルゴリズム（３．５節）が組み込まれてもよい。最適サーバ選択アルゴリズムにより、ユーザグループの近傍のキャッシュサーバが検出される。検出されたキャッシュサーバにて、上述した本実施形態のキャッシング制御が行われる。コンテンツデータは、検出されたキャッシュサーバに複製される。
【０１４０】
上述のクラスタ分析機能および最適サーバ選択機能についても、コンテンツ抽出機能と同様、局所的に設けられてもよく、分散して設けられてもよい。例えば、コンテンツプロバイダが、クラスタ分析機能と最適サーバ選択機能をもち、（１）ユーザグループおよびその近傍のサーバを見つけ、（２）ユーザグループのリクエスト特性を解析し、そして、（３）上述のキャッシング制御として、キャッシュサーバへの複製の指示を行ってもよい。
【０１４１】
以上、本発明を実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１４２】
【発明の効果】
以上に説明したように、本発明によれば、無駄なキャッシングを削減し、リクエスト回数増大が見込めるコンテンツを適切にキャッシングし、コンテンツ配信ネットワークにおけるコスト削減を図ることができる。
【図面の簡単な説明】
【図１】 コンテンツ自動配信システムの構築に関する提案システムを示す図である。
【図２】 コンテンツ自動配信システムの構築に関する提案システムを示す図である。
【図３】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図４】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図５】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図６】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図７】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図８】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図９】 適当なクラスタリングの手順を示す図である。
【図１０】 リクエスト傾向を求めるためにログを取得したプロキシサーバを示す図である。
【図１１】 ログ解析結果の概要を示す図である。
【図１２】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１３】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１４】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１５】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１６】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１７】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１８】 リクエスト回数と期待値の関係を示す図である。
【図１９】 リクエスト回数と期待値の関係を示す図である。
【図２０】 リクエスト回数と期待値の関係を示す図である。
【図２１】 リクエスト回数と期待値の関係を示す図である。
【図２２】 リクエスト回数と期待値の関係を示す図である。
【図２３】 リクエスト回数と期待値の関係を示す図である。
【図２４】 期待値が最大となるリクエスト回数を示す図である。
【図２５】 クラスタリング毎のコンテンツ抽出閾値の適用を示す図である。
【図２６】 最適サーバ選択アルゴリズムを説明するための図である。
【図２７】 最適サーバ選択アルゴリズムを説明するための図である。
【図２８】 最適サーバ選択アルゴリズムを説明するための図である。
【図２９】 最適サーバ選択アルゴリズムを説明するための図である。
【図３０】 最適サーバ選択アルゴリズムを説明するための図である。
【図３１】 最適サーバ選択アルゴリズムを説明するための図である。
【図３２】 最適サーバ選択アルゴリズムを説明するための図である。
【図３３】 最適サーバ選択アルゴリズムを説明するための図である。
【図３４】 最適サーバ選択のための処理の流れを示す図である。
【図３５】 図３４の処理のイメージを示す図である。
【図３６】 図３４の処理のイメージを示す図である。
【図３７】 図３４の処理のイメージを示す図である。
【図３８】 図３４の処理のイメージを示す図である。
【図３９】 図３４の処理のイメージを示す図である。
【図４０】 解析モジュールと複製モジュールで構成されるシステムの概念を示す図である。
【図４１】 複製ポリシーの構成を示す図である。
【図４２】 複製モジュールの構成を示す図である。
【図４３】 提案システムの試作機の構成を示す図である。
【図４４】 解析モジュールの動作を示す図である。
【図４５】 解析モジュールの動作を示す図である。
【図４６】 提案システムにおけるサーバ間のネゴシエーションを示す図である。
【図４７】 提案システムの実験環境のネットワーク構成を示す図である。
【図４８】 試作システムのマシンスペックを示す図である。
【図４９】 試作システムの実験におけるリクエスト要求を示す図である。
【図５０】 試作機の実験データを示す図である。
【図５１】 実験におけるコンテンツの複製を示す図である。
【図５２】 実験におけるコンテンツ複製後のアクセスを示す図である。
【図５３】 実験結果を示す図である。
【図５４】 実験結果を示す図である。
【図５５】 本発明の好適な実施形態における、キャッシュサーバを含むコンテンツ配信システムの全体構成を示す図である。
【図５６】 図５５のシステムに設けられたキャッシュサーバの構成を示す図である。
【図５７】 リクエスト履歴の解析機能を備えた別の実施形態におけるキャッシュサーバの構成を示す図である。
【符号の説明】
１０ ユーザグループ
１２ ネットワークノード
１４ キャッシュサーバ
２４ キャッシュメモリ
２６ キャッシュメモリ制御部
２８ リクエスト回数カウンタ
３０ 許可カウントテーブル
４０ リクエスト履歴情報取得部
４２ 解析部
４４ 期待値算出部
４６ 許可カウント決定部
【発明の属する技術分野】
本発明は、コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシングの制御方法に関し、特に、コスト削減が可能なキャッシュ制御方法に関する。
【０００２】
【従来の技術】
インターネットはそれ以前のメディアにはなかった双方向性を持ち、世界中に蓄積された情報を容易かつ即時的に取得可能なハイパーメディアである。そのため、インターネットを利用したビジネス（ｅ−ｃｏｍｍｅｒｃｅ、デジタルコンテンツ配信など）やアプリケーションシステム（ＣＲＭ、ＥＲＰなど）、コミュニケーション（ＶｏＩＰ、Ｅメールなど）は年々増加しており、インターネットの情報伝達媒体としての地位は高まる一方である。しかし、近年の急激なアクセスネットワークの高速大容量化や、コンテンツの大容量化によって、バックボーンネットワークの処理能力を超えるトラヒック需要が発生し、コンテンツの応答速度が著しく低下する場面も多く見られるようになった。これは、インターネットの双方向性や即時性が損なわれることを意味し、インターネットを利用したビジネスやシステムにとって非常に重要な問題である。
【０００３】
この問題に対処すべく、現在さまざまなコンテンツ配信システムの研究開発が盛んに行われており、その中の１つにコンテンツ配信ネットワーク（Content Distribution/Delivery Network、以下ＣＤＮ）がある。ＣＤＮは、ネットワークエッジに配備したサーバを用いて、インターネットにおける渋滞や遅延を解消するソリューションであり、１９９９年に設立された米Ａｋａｍａｉ社のコンテンツデリバリネットワークがはじまりである。Ａｋａｍａｉは世界中に配備したサーバを結ぶサーバネットワークと、独自のルーティング技術によって顧客（コンテンツ事業者）のコンテンツをエンドユーザに届けるシステムを構築し、応答速度の低下の問題を解決した。また、ＣＤＮはそのコンテンツ配信能力から、Ｐ２Ｐネットワークやグローバルコンピューティング（以下Ｇｒｉｄ）におけるミドルウェアとしての役割を期待されている。
【０００４】
しかし、ミドルウェアとしてＣＤＮを用いるにはコストが高く、より低コストのＣＤＮサービスが実現されることが求められる。さらに、地理的に離れた場所で同質のＣＤＮサービスを受けられなければ、アプリケーションに地域格差が生じる問題も発生する。これに関する最近の活動では、ＣＤＮピアリングに関する活動が多い。ＣＤＮピアリングとは、異なる事業者間でＣＤＮリソースを共有し合うことである。これによって複数の事業者が提携することでコストを抑えつつ大規模なＣＤＮを構成できるが、本格的な実用段階には至っていない。また、仮に実用段階に至ったとしてもＣＤＮを利用する分のコストはかかり、アプリケーション（結局はユーザ）の負担が増えるという問題は依然として残る。
【０００５】
【発明が解決しようとする課題】
上述したようにＣＤＮが注目を集めており、ＣＤＮをインフラとする様々なコンテンツ配信サービスが行われている。そして、アクセスネットワークのブロードバンド化に伴って、ＣＤＮ市場が成長し続けることが予想される。しかし、広域なネットワーク上でＣＤＮを用いるためにはコストが高いという課題があり、ＣＤＮプラットフォームのコスト最適化が求められる。
【０００６】
コストの問題ついてさらに説明する。ＣＤＮには、キャッシュサーバを用いたものと、バックボーンネットワークを活用しエンドユーザまでコンテンツを配信するものがある。ここでは、主として、前者のキャッシュサーバを用いるＣＤＮ技術に着目する。既存のＣＤＮの目的は、単純に「利益の最大化」であった。ここでいう利益とは、エンドユーザからキャッシュサーバへ行われるリクエスト回数である。利益の最大化を達成するため、従来、キャッシュサーバは、リクエストされた任意のコンテンツを無差別にキャッシングする。その結果、キャッシングされるコンテンツ数が非常に多く、このことが、キャッシュサーバに多大な容量を要求し、そして、コストを押し上げる要因になっている。
【０００７】
本発明は上記課題に鑑みてなされたものであり、その目的は、コンテンツ配信におけるコストを削減可能な技術を提供することにある。さらに、本発明の目的は、リクエスト回数の増大が見込める適当なコンテンツをキャッシング可能にすることによってコストを適切に削減可能な技術を提供することにある。
【０００８】
【課題を解決するための手段】
本発明は、コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシングを制御するキャッシュ制御方法に関する。本発明のキャッシュ制御方法は、コンテンツのリクエスト回数の増大を監視し、リクエスト回数が増大することにより所定のキャッシュ条件が満たされるのを待ってから前記コンテンツをキャッシュサーバにキャッシングさせる。好ましくは、前記キャッシュ条件は、リクエスト回数が多いほどその後のリクエストの可能性が大きいリクエスト特性に基づき設定される。
【０００９】
典型的には、キャッシュ条件は、リクエスト回数が適当な値まで増大したときに満たされる。この判断を実現する処理には、典型的にはリクエスト回数そのものが用いられるが、他のパラメータが用いられてもよい。
【００１０】
本発明によれば、例えば、１回だけリクエストされた後にリクエストされないコンテンツを無駄にキャッシングするのを回避できる。実際、このようなコンテンツは相当に多い。このようにして、本発明によれば、適当なコンテンツを限定的にキャッシングすることにより、コストの削減を図れる。
【００１１】
好ましくは、前記キャッシュ条件は、リクエスト回数とその後の目標リクエスト回数達成確率との関係に基づき設定される。目標リクエスト回数達成確率は、例えば、リクエストのログを解析することによって得られる。
【００１２】
好ましくは、前記キャッシュ条件は、前記目標リクエスト回数達成確率から得られるリクエスト増大量の期待値に基づき設定される。好ましくは、期待値が適当な大きさになるリクエスト回数が、キャッシュ条件としてのコンテンツ抽出閾値に設定される。より好ましくは、期待値が最大になるときのリクエスト回数が、キャッシュ条件としてのコンテンツ抽出閾値に設定される。そして、本発明は、コンテンツのリクエスト回数が前記コンテンツ抽出閾値まで増大したときに前記コンテンツを前記キャッシュサーバにキャッシングさせる。本発明によれば、期待値に基づくキャッシングの制御により、リクエスト回数の増大が見込めるコンテンツを適切にキャッシングできる。
【００１３】
なお、本発明の範囲内で、目標リクエスト回数達成確率に基づく他の制御が行われてもよい。例えば、目標リクエスト回数達成確率が適当な値になるときのリクエスト回数がコンテンツ抽出閾値として用いられてもよい。しかし、上述の期待値に基づく制御は、後述にてより詳細に説明されるように、リクエスト回数の増大が見込めるコンテンツを適当なタイミングでキャッシングでき、本発明の利点が一層好適に得られると考えられる。
【００１４】
さらに好ましくは、ユーザグループによって前記リクエスト特性が異なることに基づき、キャッシュ条件がユーザグループに応じて設定される。そして、ユーザグループによるリクエスト回数に基づきキャッシングが制御される。ユーザグループに応じた制御により、さらなるコスト削減効果が期待できる。また、本発明は、後述にてさらに説明するように、ユーザグループによって異なる被リクエストコンテンツの幅を反映した適切な制御を可能にする。
【００１５】
本発明の別の態様は、コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシュの制御方法であって、ユーザグループによるコンテンツリクエスト履歴情報を取得するステップと、前記コンテンツリクエスト履歴情報に基づき、リクエスト回数とその後の目標リクエスト回数達成確率との関係を求めるステップと、前記目標リクエスト回数未満のリクエスト回数を対象として、前記目標リクエスト回数達成確率と前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求めるステップと、前記期待値が最大になるときのリクエスト回数をコンテンツ抽出閾値に設定するステップと、前記ユーザグループによるコンテンツのリクエスト回数を監視し、あるコンテンツのリクエスト回数が前記コンテンツ抽出閾値まで増大したときに前記コンテンツをキャッシュサーバにキャッシングさせるキャッシュ制御を行うステップと、を含む。
【００１６】
本発明の別の態様は、コンテンツリクエスト増大量の予測方法であり、ユーザグループによるコンテンツリクエスト履歴情報を取得するステップと、前記コンテンツリクエスト履歴情報に基づき、リクエスト回数とその後の目標リクエスト回数の達成確率との関係を求めるステップと、前記目標リクエスト回数未満のリクエスト回数を対象として、前記目標リクエスト回数達成確率と前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求めるステップと、を含む。
【００１７】
本発明の別の態様はキャッシュシステムであり、コンテンツ配信ネットワーク上で提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリと、ユーザグループによるコンテンツのリクエスト回数をカウントするリクエスト回数カウンタと、前記リクエスト回数カウンタによりカウントされたリクエスト回数が所定のコンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングさせるキャッシュ制御部と、を含む。上述の構成がキャッシュサーバに設けられるとき、そのキャッシュサーバが単独で本態様のキャッシュシステムであってよい。また、上述の構成がコンテンツ配信サービス上で分散されるとき、それらが本態様のキャッシュシステムであってよい。
【００１８】
好ましくは、キャッシュシステムは、前記ユーザグループによるコンテンツリクエスト履歴情報を解析することにより前記コンテンツ抽出閾値を求める解析部を含む。好ましくは、前記解析部は、前記コンテンツリクエスト履歴情報から得られるリクエスト増大の期待値が最大になるときのリクエスト回数を前記コンテンツ抽出閾値として求める。
【００１９】
本発明の別の態様は、コンテンツ配信ネットワークを介して提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリを有するキャッシュサーバであって、ユーザグループによるコンテンツのリクエスト回数が所定のコンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングするように制御される。
【００２０】
本発明の別の態様は、コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシングを制御するキャッシュ制御装置であって、ユーザグループによるコンテンツのリクエスト回数をカウントするリクエスト回数カウンタと、前記リクエスト回数カウンタによりカウントされたリクエスト回数が所定のコンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュサーバにキャッシングさせるキャッシュ制御部と、を含む。本態様のキャッシュ制御装置は、コンテンツ配信ネットワーク上の局所的な装置で構成されてもよく、分散された複数の装置で構成されてもよい。
【００２１】
本発明の別の態様は、コンテンツ配信ネットワークを介して提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリに関連して用いられる、コンピュータにて実行可能なプログラムであって、ユーザグループによるコンテンツのリクエスト回数をカウントし、リクエスト回数が所定のコンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングさせるキャッシュ制御を前記コンピュータに実現させる。本発明の別の態様は、上述のプログラムを記録した、コンピュータにて読取可能な記録媒体である。
【００２２】
さらに、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、サーバ、システム、コンピュータプログラム、記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【００２３】
【発明の実施の形態】
以下、本発明についてさらに説明する。以下では、まず、「ユーザクラスタリング機構を用いたコンテンツ自動配信システムの構築」の提案について詳細に説明する。その後に、同技術を適用したキャッシュサーバで構成されるシステムの実施形態について説明する。
「ユーザクラスタリング機構を用いたコンテンツ自動配信システムの構築」
１．コンテンツ自動配信システムの構築に関する説明の全体概要を説明する。
以下では、まず、ＣＤＮ（コンテンツ配信ネットワーク）の概要を説明し（２章）、それから、本提案システムについて説明する（３章）。ここでは、本提案システムの位置づけ（３．１節）、具体的手法（３．２〜３．５節）、試作機の構成（３．６〜３．７節）を説明する。さらに、試作機による実験および評価を説明する（４章）。
【００２４】
２．ＣＤＮ（Content Distribution/Delivery Network）
ＣＤＮとは、ネットワークエッジに配備されたサーバをむすんだサーバネットワークを用いてインターネットの渋滞や遅延を解消するソリューションである。既に述べたように、１９９９年に米Akamai社がはじめたコンテンツ・デリバリー・ネットワークがはじまりであり、その後今日に至るまで多くのＣＤＮプロバイダが生まれている。本章では、ＣＤＮのアーキテクチャおよびプロトコルについて説明する。
【００２５】
２．１ ＣＤＮアーキテクチャおよびプロトコル
ＣＤＮはコンテンツ提供者とエンドユーザとの間に位置し、コンテンツ配信を効率化するために様々な機能を果たす。ＣＤＮを構成する主な機能には次がある。すなわち、リクエスト・ルーティング、ディストリビューション、アカウンティングおよびコンテンツ・アダプテーションである。
【００２６】
２．１．１ リクエスト・ルーティング（Request Routing System）
リクエスト・ルーティングとは、分散された多数のサロゲートの中から最も適切な１つを選び出し、そこへエンドユーザからの要求を誘導することである。単純な例として、BIND（参考文献：Paul Albitz and Cricket Liu, DNS & BIND Third Edition, O'REILLY, 2000）のラウンドロビン機能による負荷分散がある。しかしこの方式はアクセスを順に振り分けるだけであり、サーバやネットワークの混雑度に応じた負荷分散機能はない。サロゲートの中から最適なものを選択するためには様々な条件を考慮しなければならず、以下のようなものが考えられている。・サロゲートのＣＰＵ負荷、応答時間、・サロゲートにおけるコンテンツのキャッシュ状況、・サロゲートのカバーするコンテンツ種類、・ユーザとサロゲート間のネットワーク混雑度、パケット損失率、回線速度、・サロゲート運用者、ＩＳＰ、コンテンツ提供者等関係者間での契約関係。
【００２７】
リクエスト・ルーティングシステムには、上で挙げた情報を関係する機器の間で常時交換し、最新のパラメータを保持することが求められる。
【００２８】
現在リクエスト・ルーティングについては多くの手法が考案されているが、ＩＥＴＦ（Internet Engineering Task Force）のＣＤＩ（Content Distribution Internetworking）ＷＧにおいてもこの技術が検討されている（参考文献：B. Cain, F. Douglis, M. Green, M. Hofmann, R. Nair and D. Potter, O.Spantscheck. Known CDN Request-Routing Mechanisms. Draft-cain-cdnp-known-request-routing-02.txt. June 2001）。
【００２９】
２．１．２ ディストリビューション（Distribution System）
プロキシ・キャッシュ・サーバへのコンテンツ配信は、エンドユーザからの要求により受動的に行われるが、それだけでは効率が悪い。複数のキャッシュサーバ間で通信を行い、それらが近隣のキャッシュサーバからコンテンツを複製する方式など、効率的にコンテンツを配信するための研究がＩＲＣａｃｈｅプロジェクトを中心に行われ、いくつかのプロトコルが提案された（参考文献：P. Vixie and D. Wessels. Hyper Text Caching Protocol (HTCP). RFC2187. September, 1997）、（参考文献：V.Valloppillil and K.W.Ross. Cache Array Routing Protocol v1.0. draft-vinod-carp-v1-03.txt February, 1998）。
【００３０】
ＣＤＮにおけるサロゲートでは、さらにコンテンツ提供者側による積極的あるいは戦略的にコンテンツ配信制御が行われる。さきがけ的存在として、Ａｋａｍａｉ社が開発したＦｒｅｅＦｌｏｗがある。さらに、サロゲート間での通信に専用回線や衛星回線などを活用し、コンテンツ配信の効率化を行う企業も現れてきている。
【００３１】
２．１．３ アカウンティング（Accounting System）
一般的に、インターネットを介して情報を提供しようという場合にはＡＡＡ（Authentication, Authorization, Accounting）の３つの処理が必要である。それぞれ「認証」「許可」「課金」という意味である。認証は相手が誰であるかを確認することであり、許可は確認された相手に対してどのような権限を与えるか制御することであり、課金は料金計算のための情報収集、料金請求などの処理である。これら３つを総合的に議論する場として、ＩＥＴＦにはＡＡＡワーキンググループがある。このＷＧの目標は、多様なアプリケーションに共通に使用可能な汎用性のあるＡＡＡのためのプロトコルを定義することにある。
【００３２】
２．１．４ コンテンツ・アダプテーション（Content Adaptation）
エンドユーザの嗜好や特性、使用する機器のスペックなどに合わせてコンテンツを修正／加工することを、コンテンツ・アダプテーションといい、コンテンツ配信の付加価値を高めることを期待されている。コンテンツ・アダプテーションの例を示すと、１）言語の翻訳、２）メディアタイプの適応、３）ユーザ特性に合わせた広告挿入、４）地域データの挿入、５）ウィルス・スキャンである。
【００３３】
しかし、サロゲートにおいてコンテンツの適応をどこまで行うことができるかという問題もある。デジタル著作権の管理技術は現在十分に発展しておらず、法整備もなされていないため、この問題は解決されるに至っていない。ＣＤＮがビジネスとして発展するためには、この問題に早急に取り組まなければならないといわれている。
【００３４】
３．提案システム
この章では、本提案システムの構成と、それを実現するための方法、本システムを実装した試作機の構成などについて説明する。
【００３５】
３．１ 提案システム概要
本提案システムの目的は、アプリケーションからＣＤＮを低コストで使用できるようにすることである。低コスト化を図るためには、第１に設備投資を減らす必要がある。本システムは完成後にフリーソフトウェアとして配布することが好ましいと考えられる。ＣＤＮプラットフォームを広く浸透させることによって、アプリケーション開発の活性化が期待できる。本システムの構成を図１および図２に示す。
【００３６】
ディストリビューションシステムは、本システムを組込んだサーバ（Distribution Server,以下ＤＳ)群から成り、各サーバは自律的に協調し、コンテンツを複製し合う。キャッシュサーバ（ＣＳ）はＤＳに含まれる。また、オリジンもディストリビューションシステムに含まれる。協調関係については全てのサーバが同等であり、図２にそれを示す。
【００３７】
リクエストルーティングシステムは、ユーザ（アプリケーション）からの名前解決に対して応答するシステムである。コンテンツの名前と所在を保持し、これらはディストリビューションシステムからの登録によって更新される。ＤＮＳ（Domain Name Service）サーバとほぼ同等の役割を負う。
【００３８】
図１について説明すると、（１）オリジン（Ｗｅｂサーバに限らず情報の発生源という意味）は、リクエストルーティングシステムへコンテンツ（名前、場所）を登録する。（２）コンテンツの場所を問い合わせる。（３）登録リストの中から最も適切と思われる場所を応答として返す。（４）（３）の結果がオリジンサーバだった場合、オリジンサーバへリクエストする。（５）コンテンツの取得が行われる。（６）オリジンはコンテンツの複製を行なうために、複製先サーバリストを取得する。（７）複製ポリシーに基づいてコンテンツの複製を行う。（８）コンテンツを受け取ったサーバはリクエストルーティングシステムへ、コンテンツ（名前、場所）を登録する。（９）リクエストルーティングシステムから複製先サーバリストを取得する。（１０）複製先サーバの方がオリジンサーバよりもエンドユーザに近い場合は、複製先サーバへリクエストする。（１１）コンテンツの取得が行われる。
【００３９】
３．２ 提案システムの具体化
ここでは、主としてディストリビューションシステムについて説明する。ディストリビューションシステムの役割は、最適なコンテンツ配信を行うことである。３．２．１では本システムにおける「最適なコンテンツ配信」の意味について述べ、３．２．２でその実現手法、３．２．３では本システムで用いる具体化について述べる。
【００４０】
３．２．１ 最適なコンテンツ配信
コンテンツ配信における「最適」という言葉には様々な意味があり、配信側か受信側かによっても意味が異なる。ここでは、配信側と受信側における「最適なコンテンツ配信」の意味について述べる。ただし、ここでは、狭義のコンテンツ配信（コンテンツの配送方法）について説明する。
【００４１】
まず、受信側（つまりはユーザ側）から見た最適なコンテンツ配信であるが、エンドユーザに対しての応答速度が最速であるような配信を最適ということもあれば、エンドユーザへジッタのない安定したデータ転送ができる配信を最適ということもある。いくらジッタのない安定したデータ転送でも、応答速度が非常に遅い場合は最適とはいえず、逆に応答速度がいくら高速でもデータ転送が途切れてしまっても最適とはいえない。また、応答速度が高速でジッタもなかったとしても、一度に転送できるデータ転送量が小さければ最適とはいえない。このように、最適となるための必要条件を挙げればキリがなく、全ての条件を満足することなど不可能に近い。そこで、インターネットにおいては、ある１つのサービスを提供するために最低限必要な品質をＱｏＳ（Quality of Service）とよび、このＱｏＳを満たせば「最適」となる。つまり、最適なコンテンツ配信とはＱｏＳを満足する配信である。
【００４２】
しかし、ベストエフォート型のインターネット上、特にネットワーク的に離れた地域間による「Ｅｎｄ ｔｏ Ｅｎｄ」での通信ではＱｏＳ実現すら難しく、ＲＳＶＰやＤｉｆｆｓｅｒｖ、ＭＰＬＳなどの技術を用いたソリューションが期待されていた。だが、この流れはＣＤＮの登場によって大きく流れが変わることになる。「Ｅｎｄ ｔｏ Ｅｎｄ」という概念を戦略的にインターネットに持ち込むことによって、ＱｏＳ実現を可能にした。ネットワークエッジに配置されたサーバ、つまりエンドユーザに近いサーバからコンテンツを配信することによって、混雑する回線や遅い回線を回避し、応答速度が高速でスループットの高いデータ転送をジッタもエラーもなく行えることを意味する。まとめると、ＣＤＮを用いれば、ＱｏＳ保証されたサービスが可能であり、受信側にとって最適なコンテンツ配信が行えるといえる。
【００４３】
次に、配信側にとって最適なコンテンツ配信についてであるが、受信側にはない条件が必要となる。それは、コンテンツ配信資源の効率的活用である。配信側の立場では、コンテンツ配信にかかるコストよりも得られる利益が少ないと、コンテンツ配信を行う意味がなくなってしまうからである。ここでいうコストとは、コンテンツ配信に必要となるあらゆるもので、ディスク／メモリ使用量やコンテンツ複製トラフィック、計算負荷などであり、配信側は利益を高めるためにはコストの最適化を行う必要がある。つまり、コストの最適化を行いつつ、ユーザへ近いサーバへコンテンツを配置することが、配信側にとっての「最適なコンテンツ配信」といえる。
【００４４】
３．２．２ 最適なコンテンツ配信の実現手法
３．２．１で最適なコンテンツ配信とは「コストの最適化が行われたＣＤＮである」と説明したが、それに対して本システムがとるアプローチを述べる。本システムはコストの最適化を行うために「多く必要とされるコンテンツを、多く必要とするユーザから、最も近いサーバへ」というコンセプトに基づいて設計する。
【００４５】
コンテンツ複製対象を、多く必要とされるコンテンツに限定することで大きなコスト削減効果が見込まれる。図３〜図８は、それぞれ異なったプロキシサーバのアクセスログを解析した結果である。図３と図４、図７は研究室で使用しているプロキシサーバ（Ｓｑｕｉｄ）、図５と図６、図８は情報工学科のプロキシサーバ（Ｓｑｕｉｄ）のものである。ユーザのリクエスト傾向としてわかるのは、リクエスト回数の少ないコンテンツ数の割合は非常に高いがそれらに対するリクエスト数の割合はそれほど高くなく、リクエスト回数の多いコンテンツはコンテンツ数の割合は少ないがリクエスト数の割合が高いということである。図６を基にして考えれば、２回以上リクエストされたコンテンツをキャッシュすることにするだけで、６６．２３％のディスク／メモリ使用量が削減できる。また、３．４節で詳しく述べるが、リクエストの多いコンテンツは、その後もリクエストされる可能性が高いので、リクエストの多いコンテンツのみでコンテンツの複製を行う。
【００４６】
次に、コンテンツを必要としているユーザに近いサーバに限定してコンテンツを複製する理由を説明する。これは、リクエストのネットワーク的な偏りを利用しようというものである。インターネットには数多くのネットワークが相互接続されており、ネットワークによってユーザ数もリクエスト傾向も違う。全てのネットワークを同じように捉えるのではなく、ネットワーク単位で捉えることによってそのネットワークに特化したコンテンツ配信が行える。よって、ネットワーク単位でリクエストを解析することは重要であり、コンテンツの複製はネットワーク毎（つまりネットワークに一番近いサーバ）に行うべきである。ネットワークの分割の仕方、つまりはユーザのグルーピング方法については３．３節で説明する。
【００４７】
３．２．３ 実現手法の具体化
本システムにおいて用いる手順について説明する。本システムは大きく分けて３つの手順をふんでコンテンツの複製が行われる。このような手順をふむ理由は３．２．２で説明した通りである。３つの手順は、（１）ユーザクラスタリング（ユーザのグループ化）、（２）リクエストの多いコンテンツの抽出、（３）最適サーバ選択である。（１）については３．３節、（２）については３．４節、（３）については３．５節で説明する。
【００４８】
（ポリシーについて）
後に詳細に述べるように、本提案システムでは、ＣＤＮにポリシーが組み込まれる。 ポリシーは複製モジュールとのインタフェースに従いさえすればどのようなものでもよく、様々なアルゴリズムが適用可能である。
【００４９】
今回提案するポリシーは「コンテンツ配信におけるコストを削減」というものである。既存のＣＤＮの目的が単純に「利益の最大化」というものであるのに対して、本提案ポリシーはコストの無駄を省くということが目的となる。ここでいう利益とは、エンドユーザからＣＳ（ＤＳ）へ行われるリクエスト数のことである。コンテンツ配信においては、より多くのリクエストに対応できるということが利益といえる。提案ポリシーを実現するために求められる条件を３つ示す。（１）利益を多く生む場所（地域）の把握、（２）利益の高いコンテンツの抽出、（３）最適なサーバにコンテンツを複製である。これら条件（１）〜（３）を満足するために、上述の３つのアルゴリズムがそれぞれ有利に用いられる。すなわち条件（１）にはユーザクラスタリングが対応し、条件（２）には選択的コンテンツ抽出が対応し、条件（３）には最適サーバ探索が対応する。
【００５０】
３．３ ユーザクラスタリング
本システムにおけるユーザクラスタリングとは、ユーザを共通のポリシーによって管理されているネットワーク単位によってグループ化することである。ここで用いられる好適なクラスタリングアルゴリズムは、「Balachander Krishnamurthy and Jia Wang. On Network-Aware Clustering of Web Clients. In Proceedings of ACM SIGCOMM, August 2000.」である。このアルゴリズムは、ＢＧＰ（Broader Gateway Protocol）ルーティングテーブルのスナップショットを用いてユーザのクラスタリングを行う（K.Lougheed and Y.Rekhter. A Border GateWay Protocol. RFC1163, IETF, June 1990.）。ルーティングテーブルのエントリーをクラスタリングの単位とすると、ＢＧＰルーティングテーブルがネットワークの障害や変更に対応するので、クラスタリングの精度は高くなる。上述のBalachander Krishnamurthyらの実験結果によると、９９．９％のユーザがどれかのクラスターに属し、９０％以上の精度があると報告されている。クラスタリングの手順を図９に示すとともに、以下に図９について説明する。
【００５１】
「ＩＰ Ａｄｄｒｅｓｓ ｅｘｔｒａｃｔｉｏｎ」： アクセスログからIPアドレスを抽出する。
【００５２】
「Ｎｅｔｗｏｒｋ ｐｒｅｆｉｘ ｅｘｔｒａｃｔｉｏｎ（Prefix extraction, unification, merging）」：ＢＧＰルーティングテーブルから、プレフィックスエントリーを抽出する。プレフィックスエントリーのフォーマットがＢＧＰルーティングテーブルによって異なるのでマージする。フォーマットには下の３種類ある。すなわち、「X1.X2.X3.X4/k1.k2.k3.k4」、「X1.X2.X3.X4/m」および「X1.X2.X3.0」である。
【００５３】
「Ｃｌｉｅｎｔ ｃｌｕｓｔｅｒ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ」：ログから抽出したユーザＩＰアドレスについてＢＧＰルーティングテーブルから抽出したプレフィックスと比較し、最長一致するプレフィックスを求める。ユーザは最長一致したプレフィックスのクラスターに属すると識別される。
【００５４】
「Ｖａｌｉｄａｔｉｏｎ」：Ｎｅｔｗｏｒｋ−Ａｗａｒｅ ｃｌｕｓｔｅｒｉｎｇには、２つの理由によりクラスターが誤って求められる可能性がある。クラスターがもう１つ以上のネットワークを含んでいる場合と、１つのネットワークがいくつかのクラスターに分割されている場合である。この問題を解決するために、ｎｓｌｏｏｋｕｐとｔｒａｃｅｒｏｕｔｅを用いる。ｎｓｌｏｏｋｕｐはホストのドメイン名を問い合わせるツールである。同じプレフィックスのユーザには同じドメイン名がついている性質を利用してクラスタリングの精度を高めようというものであるが、前出のBalachander Krishnamurthyらの文献によれば、ｎｓｌｏｏｋｕｐによってドメイン名が求められる確率は５０％程度であり、nslookupだけでは問題を解決できない可能性がある。そこでｔｒａｃｅｒｏｕｔｅを適切なかたちで適用してクラスタリングの精度を高めることが好適である。ｔｒａｃｅｒｏｕｔｅはユーザまでの経路情報を得ることができるので、同じネットワークに属しているかどうかを判断することができる。
【００５５】
「Ｅｘａｍｉｎｉｎｇ ｉｍｐａｃｔ ｏｆ ｎｅｔｗｏｒｋ ｄｙｎａｍｉｃｓ」：ＢＧＰルーティングテーブルがネットワークの障害や変更に即座に更新されるので、クラスタリングをネットワークの変動に対応させることができる。「Ｓｅｌｆ−ｃｏｒｒｅｃｔｉｏｎ ａｎｄ ａｄａｐｔａｔｉｏｎ」：Ｖａｌｉｄａｔｉｏｎによって求めたクラスタリングの誤検出を修正する。1人のユーザが2つのクラスターにまたがっている場合、1つのクラスターとする。1つのネットワークがいくつかのネットワークを含んでいた場合、ｔｒａｃｅｒｏｕｔｅによって得られた結果に基づいてクラスターを分割する。
【００５６】
（グループ化の利点）
既に述べたように、ユーザクラスタリングとは、ユーザのグループ化のことである。ここで、グループ化による利点を以下に２つ挙げる。すなわち、（１）リクエスト傾向の把握がしやすい、（２）複製を効率的に行える、である。
【００５７】
（１）リクエスト傾向の把握がしやすい利点：ユーザ1人毎にリクエスト傾向を把握するよりもグループ単位で行う方が処理負荷を軽減することができ、把握しやすいものとなる。グループが類似した嗜好や特徴を持つユーザの集合だとすれば、グループ内のユーザは類似したコンテンツをリクエストする事が期待できるため、グループ単位のリクエスト傾向はユーザ単位のものと近似と考えることができる。つまり、グループ化によってユーザ単位でリクエスト傾向を把握する必要はなくなり、ユーザ単位では難しい傾向の把握をしやすくなることを意味する。
【００５８】
（２）複製を効率的に行える利点：ユーザ単位でコンテンツの複製を行うのではなくグループ単位で行うため、複製１回に対する効果を高めることができる。例えば、リクエスト傾向の異なる２つのグループがあった場合、リクエストの少ないグループに対してコンテンツの複製を行うよりも、リクエストの多いグループに対して行う方が提案したポリシーに基づいていて効率的である。既存ＣＤＮがリクエストの有無によってコンテンツの複製を行うかどうかの判断をしてきたのに対し、リクエスト数の多いか少ないかによって複製の判断を行うという本提案ポリシーにおいては、グループ化が非常に有効である。
【００５９】
このようにグループ化によってもたらされる効果は高いのだが、ここで重要なのはグループ化が何に基づいて行われて、その精度がどの程度であるかということである。今回はコンテンツ配信における最適化ということを重視し、上述したように、ネットワークトポロジーに基づいてユーザのグループ化を行うNetwork-Aware Clusteringを用いる。このアルゴリズムは、ＢＧＰルーティングテーブルのスナップショットとユーザのＩＰアドレスを使用してグループ化（クラスタリング）を行うものであり、このアルゴリズムを簡略化したものが本提案システムに好適に適用される。
【００６０】
３．４ コンテンツ抽出アルゴリズム
コンテンツを選択的に抽出するのは、最小限のコストで最大限の利益（リクエスト数）を上げるコスト最適化のためである。リクエストの多いコンテンツのみを複製対象とすることで、リクエストの少ない（利益の少ない）コンテンツに関するコストを削減することができる。しかし、この方法によるコスト最適化のためには、リクエストの多いコンテンツをリクエストされる以前に把握する必要がある。これはユーザのリクエストを予測することであり、非常に難しい問題である。なぜなら、どのコンテンツがどの程度リクエストされるのかを予測するためには、ユーザ特性を知る必要があるからである。本システムにおけるアプローチはログから確率的なリクエスト傾向を求め、それを用いてコンテンツを抽出する。
３．４．１ ユーザのリクエスト傾向
リクエスト傾向（リクエスト特性）を知る手段として、プロキシサーバのログを解析することが有効である。プロキシサーバは学校や企業などの組織の出入り口に位置し、ユーザのリクエストを代行する役割を持つ。リクエストの履歴はログとして蓄積されるので、プロキシサーバのログを解析すれば組織単位でのユーザのリクエスト傾向がわかる。図１０に示されるように、今回解析したログは研究室Ｘ、情報工学科Ｙ、大学Ｚの学生約３０００人が加入しているＩＳＰの３つである。ただし、図１０においては、不正アクセスや正規のリクエストでないものは除かれている。また、ログの解析においてユーザのプライバシーが守られなければならないことはもちろんである。
【００６１】
３つのプロキシサーバのログ解析結果より、リクエスト数が多いコンテンツは少量しかないことがわかった（リクエストが少ないコンテンツの数が多い）（図１１）。したがって、リクエストの多いコンテンツだけを抽出することによって、ディスクスペース量や管理コスト、複製に関する処理などを削減することができる。
【００６２】
図１２〜図１７は、それぞれのログから、リクエスト回数別にその後リクエストされる確率を表したものである。それぞれの図は１０回以上、２０回以上、３０回以上、４０回以上、５０回以上、１００回以上リクエストされる確率を図にしたものである。図１２を見ると、３回リクエストされたコンテンツが１０回以上リクエストされる可能性は研究室のものが約７０％、ISPが約６５％、情報工学科が約８２％だということがわかる。ばらつきがあるが、３つとも同じような対数曲線を描くことがわかる。このことから、リクエスト回数が多いほどその後リクエストされる可能性が高いことがわかり（リクエスト回数が少ないほどその後のリクエストされる可能性が低い）（図１１）、ある程度リクエストされたコンテンツはその後リクエストされる可能性が非常に高くなることがわかった。
【００６３】
３．４．２ 期待値
３．４．１で、リクエスト回数が多くなるとその後リクエストされる可能性が高い傾向があると説明した。では実際にリクエスト回数がどの程度になればコンテンツ抽出を行うべきなのかを説明する。いくら確率が高くても得られる利益（キャッシュヒットによってユーザ得られる利益）が低ければ意味がない。例えば、図１７の情報工学科のグラフを見ると、９９回リクエストされたコンテンツが１００回以上リクエストされる可能性は９９．７６４４６％であることがわかる。そこで、９９回目のリクエストで初めてコンテンツをキャッシュしたとする。もしリクエストされる回数が１００回ならば１回分しか利益を得ることしかできない。よって、「その後リクエストされる確率が高い」ではなく、「高い利益を得る確率が高い」という判断によってコンテンツを抽出する必要がある。
【００６４】
本システムにおいては、「利益を得られる確率（Ｘ回以上リクエストされる確率）」と「得られる利益（その後のリクエスト回数）」との積を求め、それとＸとの商を期待値とし、それに基づいてコンテンツ抽出を行うことにする（期待値を求めるときにＸで割らなくてもよい）。
【００６５】
期待値を表したものが図１８〜図２３である。これらの図より、あるリクエスト回数で期待値が極大値を取ること、どのプロキシサーバかによって極大値をとるリクエスト回数が異なることがわかる。それぞれのプロキシサーバによる違いは、グループ毎のリクエスト傾向の違いを表している。本システムは、極大値をグループ毎に求め、これをコンテンツ抽出閾値とする。
【００６６】
次に、図２４は、期待値が最大となるリクエスト回数をグラフにしたものを示す。横軸（Ｘ）は、図１８〜図２３における目標のリクエスト回数（１０回から１００回）である。縦軸は、期待値が極大値となるリクエスト数（コンテンツ抽出閾値）である。横軸のリクエスト回数（Ｘ）は、何回リクエストされたものを利益が高いとするかによって決まる。例えば、１００回以上リクエストされるコンテンツを利益が高いとすると、情報工学科ならばリクエスト数１３回でコンテンツを抽出すればよいことがわかる（コンテンツ抽出閾値＝１３で、期待値が最大になる）。このように、図２４より、コンテンツ抽出閾値は変数Ｘによって定まることがわかる。Ｘは、システム使用者により適宜決定されてよい。
【００６７】
図２４における近似曲線の傾きはユーザのリクエストの幅を表す。これは多数回リクエストされるコンテンツが多い場合に期待値が最大となるのが早く、少ない場合は最大となることが遅いことを根拠としている（多数回リクエストされるコンテンツが多いということは、リクエストが偏っているといえる）。よって、傾きが大きいほどリクエストの幅が広く、小さいほどリクエストの幅は狭い。この場合、情報工学科が最もリクエストの幅が狭く、ＩＳＰが最もリクエストの幅が広いことがわかる。したがって、このようなコンテンツ抽出閾値導出手法を適用することにより、グループのリクエスト傾向を反映させた閾値の設定が可能になる。閾値はＣＳのログを解析することによって求められる。なお、図２４における「ｘ」は「Ｘ／１０」である。
【００６８】
また、上述において、本システムによるコストの最適化とは、「利益の少ないコンテンツに関するコストを削減しつつ最大限の利益を上げよう」というものであり、単なる利益の最大化ではないことに注意が必要である。
【００６９】
３．４．３ クラスタリングとコンテンツ抽出
３．４．２ではコンテンツ抽出閾値の導出法を説明したが、実際の使用方法について述べる。コンテンツ抽出閾値を、３．３節で説明したユーザクラスタリングによって求めたクラスタリング毎に適用する（図２５）。クラスターが組織単位となるので、組織単位でコンテンツ閾値を求めることができ、コンテンツ抽出の精度を高めることができる（組織単位でのリクエスト傾向を反映できるので）。また、コンテンツの複製を個人単位やインターネット全体ではなくクラスター単位で行うことによって、複製回数を抑え、頻繁な複製を防ぐことができる。
【００７０】
３．５ 最適サーバ選択アルゴリズム
ユーザクラスタリングによって求めたクラスター毎にコンテンツ抽出アルゴリズムを適用し、複製するコンテンツと複製先の目標となる場所（クラスター）を導入することができた。しかし、複製を行うためには複製目標のクラスターに対して最適である複製先ＤＳを発見することが求められる。そこで最適サーバ探索が求められる。本システムにおいては、以下に説明するように、最適サーバを目標クラスターから最も近いサーバとし、単純にラウンドトリップタイム（以下、ＲＴＴ）の小さいものを近いとする。
【００７１】
複製を行なうためにはクラスターの最近隣にある複製先ＤＳ（Distributed Server、以下同じ)を発見することが望まれる。ＤＮＳサーバを用いて複製先となるクラスター側から最近隣ＤＳを発見する方法（図２６）には様々な研究および製品があるが（下川俊彦,吉田紀彦,牛島和夫. 多様な選択ポリシーを利用可能なサーバ選択機構, 電子情報通信学会論文誌 Vol.J84-D-I No.9 2001.9）、これがクラスターから遠隔にあるＤＳ単独で最近隣ＤＳを探索することになると問題は難解になる。なぜなら、クラスターから各ＤＳへの経路を把握することが、複製元ＤＳでは難しいからである（図２７）。この解決策としてＩＰルーティングのように各ＤＳが協調し合い、クラスターから最近隣ＤＳを探索する方法（図２８)を挙げることができるが、ＤＳの数が多くなると協調によるオーバーヘッドが大きくなるのであまり好ましくない。違った協調を使用したものとして、複製元ＤＳと近いＤＳから順に協調し複製する方法がある。フローチャートは図３３のようになる。この場合、協調そのものに対するオーバーヘッドは小さくて済むが複製が局所的であり、目標となるクラスターから最近隣のＤＳへコンテンツを複製するために複数回複製を要する可能性が高い（図２９〜図３２）。また、こういったアルゴリズムは複製の終了条件を設定するのが難しい。
【００７２】
上記を考慮した上で、本システムは、精度の低いＤＳ単独で探索する方法を提案し用いる。サーバ選択における「最適」または「最近隣」の定義に関して、ＲＴＴやＴＣＰスループット、サーバ処理能力、回線使用率など様々な要素を用いた研究が多いが、本システムにおいては単純にＲＴＴを用いる。ユーザクラスターから最もＲＴＴが小さい（応答速度が速い）ＤＳを最低サーバとする。
【００７３】
３．５．１ 提案最適サーバ選択方法
提案手法はｔｒａｃｅｒｏｕｔｅを基にしている。この方法は、ネットワークトポロジーが木構造または線形構造である場合には高精度で最近隣サーバを発見することができるが、リングを含むネットワークである場合には精度は保証されない。処理の流れを図３４に、イメージ化したものを図３５〜図３９に示す。ｔｒａｃｅｒｏｕｔｅを、ｗｗｗ．ＸＸＸＸＸ．ｃｏ．ｊｐといったＵＲＬに対して実行することによって経路情報とＲＴＴが得られる。
【００７４】
３．６ システムの実装方法
３．３〜３．５節で、コンテンツ複製におけるポリシーを説明した。本説では、この複製ポリシーをどのように実装するかを述べる。多様な複製ポリシーを利用可能とし、システムの柔軟性を上げる意味で、実装は柔軟であることが望ましい。そこで、本システムにおいては複製ポリシーと複製を実行するモジュールとを分離し、実装を容易化する。複製ポリシーに基づいて複製戦略をたてるモジュールを解析モジュール、複製を行なうモジュールを複製モジュールと呼ぶことにする。図４０はこれらをまとめた階層図である。このような階層をとることによって、アプリケーションは複製ポリシーを選択することが可能となる。
【００７５】
３．６．１ 解析モジュール
解析モジュールは複製ポリシーに基づいて複製戦略をたて、複製モジュールに指令を下す役割を持つ。複製ポリシーは選択可能とすることがより好適と考えられる。複製ポリシーの構成は図４１で示す。複製ポリシーはユーザクラスタリングアルゴリズム、コンテンツ抽出アルゴリズム、最適ザーバ選択アルゴリズムの３つのアルゴリズムによって構成される。組み合わせは自由とし、アプリケーションレベルで組み合わせを決められる機構を作成することがより好適と考えられる。
【００７６】
３．６．２ 複製モジュール
複製モジュールは解析モジュールの指示（どのコンテンツをどのＤＳに複製するか）を受け、それに基づいて複製を行なうモジュールである。複製モジュールには、ＤＳ間通信における認証や暗号化などのセキュリティ機能や、軽量化された通信機能が備えられることが望まれる。図４２に複製モジュールの構成図を示す。
【００７７】
（Ｐ−ＣＤＮ）
ここで、上述にて説明されるように、本発明者は、コンテンツ配信にかかるコスト削減を目的としたポリシーを既存ＣＤＮに組み込んだＰ−ＣＤＮ（Policy based CDN）を提案する。
【００７８】
Ｐ−ＣＤＮとは、アプリケーションから多様なポリシーが選択可能なＣＤＮであり、既存ＣＤＮに戦略性を持たせることができる。ポリシーとは具体的にキャッシュサーバ（ＣＤ、上述のＤＳに相当）間におけるコンテンツ配置アルゴリズムのことであり、本システムはポリシーに基づいてＣＳ間でコンテンツの複製を行う。Ｐ−ＣＤＮの特徴は以下の４つ、すなわち、（１）ポリシーに基づくコンテンツ配置、（２）ポリシーの内容は条件内で自由、（３）複数のポリシーを組込み可能、（４）ポリシーの選択は自由である。
【００７９】
Ｐ−ＣＤＮでは、既に述べたように、ポリシーと複製を実行するモジュールとが分離されることが有利でる。ポリシーに基づき複製の指令を出す解析モジュールが設けられ、さらに、複製を実行する複製モジュールが設けられる。
【００８０】
より詳細には、解析モジュールの役割は２つある。１つはアプリケーションに対してポリシーの選択性を提供することである。もう１つは、ポリシーに対してシステムが組み込まれているＣＳ（ＤＳ）やネットワークの状態を提供する役割である。ポリシーに提供される項目は、（１）ＣＰＵ使用率、（２）メモリ使用率、（３）コネクション数、（４）データ転送量、（５）ユーザからのリクエストのログ、（６）外部との通信用のメッセージ通信機能、である。
【００８１】
一方、複製モジュールはポリシーからの指令を受け、それに基づいて実際にコンテンツを複製するモジュールである。ポリシーから複製モジュールになされる指令は、以下に示す２つの要素から構成される。すなわち、（１）コンテンツの名前（ＵＲＬ）および（２）複製先サーバ名（ＩＰアドレス）である。
【００８２】
解析モジュールと複製モジュールとの分離によって様々なポリシーの開発および実装を簡単化でき、ポリシーの開発だけに専念できる環境が生まれると考える。以上、Ｐ−ＣＤＮについて説明した。
【００８３】
３．７ 試作機の構成
本章で述べてきた提案システムを実用化するために作成された、システムを実装した試作機について説明する。試作機は、ＰＣ／ＡＴ互換機で作成し、システムはＦｒｅｅＢＳＤ上に実装する。システムはキャッシュサーバソフトウェアであるＳｑｕｉｄ（Squid Web Proxy Cache）を基にして作成した。Ｓｑｕｉｄにはコンテンツのキャッシュ機能やキャッシュサーバ間通信機能があるので、コーディング作業を大幅に減らすことができる。図４３は、試作機のシステム構成図を示している。
【００８４】
３．７．１ 解析モジュールの実装
解析モジュールには、Ｓｑｕｉｄのアクセスログを解析する機能と、最適サーバ探索機能を持たせる。図４４および図４５は、解析モジュールの動作を示している。
【００８５】
図４４および図４５について説明すると、（１）Ｓｑｕｉｄのアクセスログを用いてユーザクラスタリングを行なう。ログはクラスター毎に分割される。クラスタリングに用いるＢＧＰルーティングテーブルは前もってダウンロードしておく。（２）ログ毎にリクエスト傾向を求める。リクエスト傾向によって抽出閾値を導出する。（３）閾値以上のリクエスト回数のコンテンツを抽出し、ＵＲＬを抜き出す。（４）クラスターから最も近いＤＳを探索し、ＤＳのＩＰアドレスを求める。（５）ＵＲＬとＤＳのＩＰアドレスを複製モジュールへ渡す。
【００８６】
３．７．２ 複製モジュールの実装
本来なら解析モジュールのように複製モジュールも単体で動作するように実装することが望ましいと考えられる。しかし、今回は、複製モジュールをプロキシサーバソフトウエアのＳｑｕｉｄに組込んで実装を行なった。
【００８７】
複製モジュールは解析モジュールが作成した複製先ＤＳリストを利用して、コンテンツの複製を行なうモジュールである。複製モジュールは複製先ＤＳリストを定期的にチェックしており、リストに変更があればリストから複製先ＤＳアドレスと複製するコンテンツを取得して複製動作を行なう。ＤＳ間のネゴシエーションは図４６のような内容になっている。Connection messageはＤＳ間で複製を行なうための情報の通信を行い、Request Messageはコンテンツ複製を実際に開始するための通信に利用する。Connection messageには各種メソッドが含まれており、メッセージを受信したＤＳがメソッドに合わせた処理を行なうようになっている。Connection messageのメソッドの種類にはＤＳ間でネゴシエーションを開始するときに複製元ＤＳから送られる「ICP_NEGO」、複製先ＤＳが複製可能だと複製元ＤＳに知らせる「ICP_NEGO_Y」、複製先ＤＳが複製不可能だと複製元に知らせる「ICP_NEGO_N」、複製するコンテンツのアドレスを複製先ＤＳに送るための「ICP_MOVE」がある。通信プロトコルはConnection messageの送信にはＵＤＰをRequest messageとコンテンツデータの送信にはＴＣＰを用いている。まず、リストに変更が複製元DSは複製先ＤＳリストから複製先ＤＳと複製するコンテンツを取得する。複製元ＤＳは複製先ＤＳにConnection message「ICP_NEGO」を送信しネゴシエーション要求を出し協調動作を開始する。「ICP_NEGO」を受け取った複製先ＤＳは現在の自分の状態を調べて複製可能かどうかを判断する。判断する内容はディスク残り容量、ＣＰＵ負荷、ネットワーク負荷などをもとに判断する。複製可能な場合は複製元ＤＳへ「ICP_NEGO_Y」を返し、不可能な場合は「ICP_NEGO_N」を返す。「ICP_NEGO_Y」を受けた複製元ＤＳは協調動作可能と判断し、複製先ＤＳへ「ICP_MOVE」メッセージを送信する。このメッセージには複製するコンテンツのアドレスが含まれている。また、「ICP_NEGO_N」メッセージを受け取った場合は協調動作を中止する。「ICP_MOVE」を受け取った複製先ＤＳはRequest messageを複製元ＤＳに送信し、それを受けた複製元ＤＳはコンテンツデータの送信は開始するようになっている。
【００８８】
４ 実験と評価
本提案システムを検証するために、解析モジュールと複製モジュールをインストールした試作機によって検証実験を行った。本章では、その実験環境と実験結果について述べる。
【００８９】
４．１ 実験環境
４．１．１ ネットワーク構成
図４７に今回の実験環境のネットワーク構成を示す。ルータマシン、試作機マシン(ＤＳ)、クライアントマシンはいずれも一般的なマシン(ＩＢＭ ＰＣ／ＡＴ互換機)を使用した。ルータマシンＩにはＯＳとしてＦｒｅｅＢＳＤ５．０を、ルータマシンＩＩ、ＩＩＩ、ＩＶはＦｒｅｅＢＳＤ４．２をインストールした。それぞれのルータマシンにはＮＩＣ(Network Interface Card)が複数枚装着してあり、複数のネットワークとのゲートウェイとして動作している。試作機マシンのＯＳにはＦｒｅｅＢＳＤ４．２、クライアントマシンにはＷｉｎｄｏｗｓ ＭＥ（登録商標）とＷｉｎｄｏｗｓ２０００（登録商標）をインストールした。試作機マシン、クライアントマシンにはＮＩＣが１枚装着してある。各端末間の接続速度はすべて１００ｂａｓｅＴＸで接続されている。試作機マシンにはアクセスログの解析を行うための解析モジュールとコンテンツ複製を行うための複製モジュールが実装されている。各マシンスペックは図４８に示すとおりである。マシンスペックには個体差があるが、これはＣＰＵ処理速度を故意に下げることにより、ＣＰＵの処理能力が解析処理やパケット転送処理のボトルネックとなるような環境を作っている。試作機Ａと試作機Ｂとを差別化するため、試作機ＡのＮＩＣは意図的に性能の低いものにしてある。
【００９０】
４．１．２ 実験環境詳細
実験開始段階では試作機Ａにだけコンテンツをキャッシュしてある状態にしてある。その他の試作機はコンテンツを何も持っておらず、クライアントからのアクセスがこない状態になっている。試作機Ａは一定時間間隔でアクセスログを解析し、最適なコンテンツ配置先を選択するプログラムが動作している。また、それぞれの試作機マシン上では複製モジュールが動作しており、協調を行うためのメッセージのやり取りができるようになっている。
【００９１】
実験では図４９のように、各クライアントから試作機Ａへリクエスト要求を複数回送っている。実験ではクライアントマシンからのアクセス要求をクライアントグループからのアクセスと見立てて、解析モジュールでクラスタリングを行うようになっている。アクセス回数はクライアントαよりクライアントβが多く要求を出すパターンと少なく出すパターンで行った。取得するデータはコンテンツ複製前とコンテンツ複製後で試作機からクライアントマシンへのＨＴＴＰレスポンスタイム等のデータを取り、提案システムや解析モジュールの有効性をデータとして示す。
【００９２】
今回の実験は、複製ポリシーとして設定してある一連のアルゴリズムに基づいてコンテンツ複製が行われるかを検証するためのものなので、ユーザクラスタリングアルゴリズムとコンテンツ抽出アルゴリズムは単純化してある。
【００９３】
実験環境で使用されるマシンに割り振られるＩＰアドレスがプライベートＩＰアドレスなので、外部のＢＧＰルーティングテーブルを用いたクラスタリングが行えない。よって、クラスタリングはプレフィックスを２４ｂｉｔ固定として行う。
【００９４】
３．４節で説明したコンテンツ抽出アルゴリズムは、ログが充分に蓄積された状態でなければアルゴリズムの精度が保証されない。そのため、ログの蓄積数が少ない場合は予め固定の閾値を設定しておき、その閾値を用いてコンテンツ抽出を行う。今回は、１０回を閾値として設定した。コンテンツ抽出アルゴリズムは、ログ数が例えば１０００行以上になった時に初めて動作するように構成される。
【００９５】
４．２ 実験結果
４．１．２節の実験環境での検証では図５０に示すデータを得ることができた。今回の検証では複製閾値を１０回としているので、アクセス回数が１０回を超えたところからグラフに変化が現れている。図５０に示すアクセス時間はクライアントβからコンテンツにアクセス要求を出してから、コンテンツデータの先頭がクライアントに届くまでの時間である。実験開始直後はクライアントのアクセス要求はすべて試作機Ａへ送られる。アクセス解析によりコンテンツの複製が起こった後は、クライアントβからのアクセスはレスポンスのよい試作機へ送られるようになる。図５０のグラフのからもわかるように、クライアントβから試作機Ａまでのレスポンスタイムと、コンテンツ複製が起こり複製先の試作機へアクセス要求を送ったレスポンスタイムでは複製先試作機にアクセスしたほうがレスポンスタイムが短いことがわかる。今回の検証でのコンテンツの複製された動作は、クライアントα、βからのアクセスを試作機Aが解析しアクセスの多いクライアントβに近いところにコンテンツを複製しようとしコンテンツの複製を行った。図５１のように解析モジュールが最適サーバを選択し、試作機Ｃが最適だと判断しコンテンツを複製し、コンテンツ複製後からは図５２のようにクライアントβは試作機Ｃにアクセスするようになるために、レスポンスタイムが短くなっているのである。図に示してはないが、クライアントαのリクエスト数がクライアントβより多い場合でも同じように、レスポンスタイムが短くなっている。これは試作機Ａより試作機ＢのほうがＣＰＵ能力がよいので、コンテンツが試作機Ｂへ複製され、クライアントαのアクセス要求も試作機Ｂに送られるようになったためである。
【００９６】
４．３ 評価
図５０に示されるように実験結果から提案システムの有効性を示すことができた。図５０よりコンテンツ複製前よりコンテンツ複製後のほうがクライアントへのレスポンスが向上していることがわかる。これは、複製前のサーバより解析モジュールによって選ばれた複製後のサーバのほうがクライアントに近いからということが言える。このことから、解析モジュールの最適サーバを選択するアルゴリズムが有効だといえる。提案システムでは自律的にクラスター毎のアクセス傾向を解析し、クラスタリングされたクライアントグループの近くにアクセスの多いコンテンツを自動的に配置することができる。クライアントグループごとにアクセスの多いコンテンツを近くのサーバに複製することによって、オリジンサーバまでコンテンツをアクセスしに行かなくても済むので、レスポンスタイムが短くなる。また、コンテンツが複数配置されることになるので、オリジンサーバの負荷分散やトラヒックの軽減を行うことができる。また、この提案システムはフリーソフトとして配布されてもよい。ＣＤＮプラットフォームを誰もが利用することができ、ＣＤＮを用いたアプリケーションの開発を促進することができると考えられる。
【００９７】
（評価項目と確認）
ここで、評価項目とその達成の確認を行う。評価項目として、（１）閾値によって複製が行えるか、（２）（１）がクラスター毎に行えるか、（３）最適サーバが探索されているか、を挙げる。
【００９８】
図５３は、図５０と同様の図である。図５３より、閾値による複製によってクライアントβに対する応答速度が向上しているのがわかる。これは、閾値を境にクライアントβに最も近い試作機Ｃにコンテンツが複製され、クライアントβのリクエストが試作機Cに対して行われるようになるからである。これで評価項目（１）と（２）が満足された。
【００９９】
また、図５４は、ルータＩＶと試作機Ｃを一定時間高負荷状態にした時のクライアントβに対する応答速度の変化を表したものである。試作機Ｃが高負荷状態であるために、まず試作機Ｂにコンテンツが複製され、その後試作機Ｃに複製されているのがわかる。この実験によって評価項目（３）も満足された。
【０１００】
５．以上に説明したように、ユーザクラスタリング機構を用いたコンテンツ自動配信システム、Ｐ−ＣＤＮの提案を行った。ユーザクラスタリング機構を用いることによって、ユーザをクラスターに分割することができ、それぞれのクラスターに特化したコンテンツ配置戦略をたてることができることを説明した。本システムを実装した試作機による検証実験では、複製ポリシーに基づいて動作することが確認された。複製ポリシーのコンテンツ抽出アルゴリズムによりコンテンツ抽出、複製が適切に行われた。
【０１０１】
「キャッシュサーバ」
次に、上述の技術が適用されたキャッシュサーバを含むシステムの実施形態を説明する。キャッシュサーバは上述のディストリビューションサーバ（ＤＳ）に対応する。この実施形態には、主として、上述した技術のうちの、期待値に基づくコンテンツ抽出アルゴリズムが適用されている。
【０１０２】
図５５は、キャッシュサーバを含むＣＤＮの構成図である。コンテンツプロバイダはコンテンツをユーザに提供するサーバである。コンテンツレシーバはインターネットを介してコンテンツプロバイダが提供するコンテンツを受信して利用するユーザの端末である。インターネットには複数のネットワークノードが含まれ、コンテンツプロバイダからコンテンツレシーバへ提供されるコンテンツのデータを中継するルータとして機能する。
【０１０３】
図５５において、ユーザグループ１０は、例えば、ある大学に属する複数のコンテンツレシーバを含む。ネットワークノード１２は、ユーザグループ１０の近傍に位置している。そして、ネットワークノード１２には、本実施形態のキャッシュサーバ１４が一体的に設けられている。キャッシュサーバ１４は、ユーザグループ１０のために、コンテンツプロバイダから提供されるコンテンツをキャッシュメモリに格納し、これによりキャッシングが行われる。なお、図示されないが、キャッシュサーバは他のネットワークノードにも設けられていてよいことはもちろんである。
【０１０４】
図５６は、キャッシュサーバ１４の構成を示している。キャッシュサーバ１４は、第１通信部２０および第２通信部２２を有する。第１通信部２０はネットワークと通信し、第２通信部２２はローカル側（ユーザグループ）と通信する。第１通信部２０および第２通信部２２は、ハードウエア構成としては同一でよい。
【０１０５】
キャッシュメモリ２４は、キャッシュメモリ制御部２６の制御の下で、キャッシングのためにコンテンツを格納する。すなわち、コンテンツがキャッシュメモリ２４に複写され、これによりキャッシングが行われる。キャッシュメモリ制御部２６は本発明のキャッシュ制御部として機能する。
【０１０６】
リクエスト回数カウンタ２８は、ユーザグループ１０によるリクエストの情報を入手して、コンテンツのリクエスト回数を計測する。各々のコンテンツのリクエスト回数がカウントされる。カウント値は図示のようなテーブルに書き込まれる。このようにして、ユーザグループ１０によるコンテンツのリクエスト回数とその増大が監視される。
【０１０７】
許可カウントテーブル３０は、目標カウントと許可カウントを対応づけるテーブルである。目標カウントは、本発明の目標リクエスト回数に相当し、３．４．２節で説明した図２４の横軸に相当する。許可カウントは、図２４の縦軸に相当し、期待値が最大になるときのリクエスト回数である。
【０１０８】
既に説明したように、期待値は、目標リクエスト達成確率と残リクエスト回数の積で表される。目標リクエスト回数達成確率は、リクエスト回数ｎから目標リクエスト回数（目標カウント）Ｘに到達する確率であり、残リクエスト回数は、リクエスト回数ｎから目標リクエスト回数（目標カウント）Ｘまでの残リのクエスト数、すなわち、Ｘ−ｎである。
【０１０９】
本実施形態では、予め、ユーザグループ１０のリクエストのログが、適当な期間に渡って解析される。例えば、２ヶ月間のログが解析される。この解析結果に基づき、期待値の情報が求められる。そして、図２４のテーブルのデータがキャッシュサーバに予め入力され、保持されている。
【０１１０】
また、図２４を参照して既に述べたように、リクエスト特性、特にリクエストの幅（バリエーション）がユーザグループによって異なる。そして、期待値を最大にするリクエスト回数もユーザグループによって異なる。この点に関して、本実施形態の許可カウントテーブル３０は、対象のグループの解析結果から得られたデータ、すなわち対象のグループの特性を反映するデータを保持している。
【０１１１】
図５６に戻り、指定ＵＩ（ユーザインターフェース）３２は、キーボード等のデバイスを用いて入力された目標カウントを受け付ける。目標カウントはキャッシュメモリ制御部２６により取得される。キャッシュメモリ制御部２６は、許可カウントテーブル３０を参照し、目標カウントに対応する許可カウントを求める。この許可カウントは、キャッシュメモリ制御部２６により保持され、コンテンツ抽出閾値として、すなわちキャッシュ条件として、キャッシングの制御に用いられる。すなわち、以下に説明するように、あるコンテンツのリクエスト回数が許可カウントに達したとき、キャッシュ条件が成立し、コンテンツのキャッシュが許可され、キャッシングが行われる。
【０１１２】
次に、図５６のキャッシュサーバ１４によるキャッシングの動作を説明する。上述のように、リクエスト回数カウンタ２８は、ユーザグループ１０によるコンテンツのリクエスト回数を計測する。例えば、ユーザグループ１０を構成する一の端末からＵＲＬ１というコンテンツが初めてリクエストされたとき、ＵＲＬ１のカウント値として１がテーブルに記録される。その後、ユーザグループ１０の端末からＵＲＬ１がリクエストされるたびに、テーブル中のカウントが１ずつ増やされる。
【０１１３】
キャッシュメモリ制御部２６は、ユーザグループ１０の端末からコンテンツがリクエストされたとき、リクエスト回数カウンタ２８のテーブルを参照する。そして、キャッシュメモリ制御部２６は、今回のリクエストによって、コンテンツのリクエスト回数が許可カウントに達したか否かを判定する。上述したように、許可カウントは許可カウントテーブル３０を参照することによって得られる。そして、キャッシュメモリ制御部２６は、リクエスト回数が許可カウントに達した場合、コンテンツデータをキャッシュメモリ２４に格納することで、コンテンツをキャッシングする。
【０１１４】
例えば、上述のＵＲＬ１がリクエストされたとき、この情報がキャッシュメモリ制御部２６に取得される。キャッシュメモリ制御部２６は、現在のＵＲＬ１のカウント値を、リクエスト回数カウンタ２８から求める。そして、キャッシュメモリ制御部２６は、今回のリクエストにより、リクエスト回数が許可カウントに達するか否かを判定する。すでに許可カウントから１を引いた値までリクエスト回数が到達している場合、今回のリクエストにより、リクエスト回数が許可カウントに到達する。そこで、キャッシュメモリ制御部２６は、リクエストされたコンテンツデータをキャッシュメモリに格納する。キャッシュサーバを通過するときにコンテンツデータがキャッシュメモリに格納される。
【０１１５】
以上のようにして、本実施形態は、コンテンツのリクエスト回数の増大を監視して、リクエスト回数が許可カウント（コンテンツ抽出閾値）まで増大することによりキャッシュ条件が満たされるのを待ってからコンテンツをキャッシュサーバにキャッシングさせる。したがって、コンテンツの増大が見込める適当なコンテンツをキャッシングできる。１度だけしかリクエストされないようなコンテンツの無駄なキャッシングが回避され、コストを削減できる。
【０１１６】
また、本実施形態は、リクエスト特性に基づいた適切なキャッシング制御を行っている。特に、本実施形態は、上述のように、リクエスト増大の期待値に基づいたコンテンツ抽出閾値（許可カウント）を用いており、これにより好適な制御が行われる。
【０１１７】
すなわち、コンテンツ抽出閾値を大きく設定すると、その後のリクエストの確率は高いものの、リクエスト回数自体が少なくなり、キャッシングの効果が少なくなる。一方、コンテンツ抽出閾値を小さくしすぎると、リクエスト回数が伸びないコンテンツを無駄にキャッシングする可能性が高くなる。このような点を考慮した上で、本実施形態は、期待値に基づきコンテンツ抽出閾値を設定している。その結果、リクエスト回数の増大が見込めるコンテンツを早めの適切なタイミングでキャッシングすることができ、コスト削減が図れる。
【０１１８】
なお、本実施形態では、キャッシュサーバ１４はネットワークノード１２と一体化されていた（図５５）。しかし、本発明はこれに限定されない。キャッシュサーバ１４はネットワークノード１２の外側に付属してもよい。
【０１１９】
また、図５５には示されないが、他のユーザグループについても同様に本発明のキャッシュ制御技術が適用されてよいことはもちろんである。このとき、一つのキャッシュサーバが複数のユーザに対応してもよい。
【０１２０】
また、本実施形態では、図５５に示されるように、ユーザグループに近いキャッシュサーバがコンテンツをキャッシングしている。これに対し、アクセス時間が多少長くなるものの、本発明の範囲内で、ユーザグループからより遠くのキャッシュサーバが用いられてもよい。
【０１２１】
また、本実施形態では、すべてのコンテンツに関して、目標カウントおよび許可カウントが一定であった。これに対し、コンテンツの種類が判別可能なとき、目標カウントおよび許可カウントをコンテンツに応じて異ならせる制御が行われてもよい。例えば、コンテンツのジャンルに応じた制御を行うことが好適と考えられる。
【０１２２】
また、キャッシュサーバ１４の指定ＵＩ３２は、目標カウントを入手した。そして、キャッシュサーバ１４内で、許可カウントテーブル３０を参照して、許可カウントが求められた。これに対し、指定ＵＩ３２は、許可カウントを入手してもよい。すなわち、オペレータによりキーボード等を用いて許可カウントが入力される。このとき、許可カウントテーブル３０は削除されてもよい。
【０１２３】
また、キャッシュサーバ１４は、本発明のキャッシュ制御のためのプログラムをコンピュータにインストールすることにより実現されている。さらに、このプログラムは、通信でキャッシュサーバ１４に入手されてもよく、ＣＤ−ＲＯＭ等の記録媒体からキャッシュサーバ１４に入手されてもよい。そして、キャッシュサーバ１４は、本発明のキャッシュシステムとして機能する。さらに、キャッシュサーバ１４は、本発明のキャッシュ制御装置の機能を実現し、すなわちキャッシュ制御装置を備えている。これらの点は、下記の実施形態においても同様である。
【０１２４】
また、本発明は、主として、コンテンツをキャッシュメモリに格納する部分に特徴をもつので、上述の説明では、格納されたコンテンツを活用する部分の説明は省略されている。しかし、この点に関しては、従来同様の処理が行われてよい。すなわち、格納済み（キャッシング済み）のコンテンツがユーザグループ１０の端末からリクエストされときは、キャッシュメモリ２６の制御の下で、キャッシュメモリ２４からコンテンツが読み出され、提供される。これによりアクセス時間が短縮される。その他、既に格納されたコンテンツは、ＬＦＵ（Least Frequently Used）方式またはＬＲＵ（Least Recent Used）方式等の適当な方法でキャッシュバッファから追い出される。
【０１２５】
次に、図５７は、本発明の別の実施形態におけるキャッシュサーバ１４０を示している。キャッシュサーバ１４０は、上述した構成に加えて、リクエスト履歴を解析する機能を備える。
【０１２６】
図５７において、リクエスト履歴情報取得部４０は、コンテンツのリクエスト履歴の情報を取得する。リクエスト履歴情報は、キャッシュサーバ１４０自身により、リクエストを監視することにより取得されてもよい。また、リクエスト履歴情報は外部から通信等で入手されてもよい。例えば、前述したように、ユーザグループのプロキシサーバでのアクセスログが、履歴情報として有用である。
【０１２７】
キャッシュサーバ１４０はさらに解析部４２を有する。解析部４２は、リクエスト履歴の情報を取得する。解析部４２は、既に説明したコンテンツ抽出アルゴリズムに従った処理を行う。すなわち、期待値算出部４４が、目標リクエスト回数の達成確率を求め（図１２〜図１７）、期待値を求める（図１８〜図２３）。そして、期待値に基づき、許可カウントテーブル３０が作成される。既に説明したように、許可カウントテーブルは、図２４のグラフに相当するデータをもち、目標カウント（目標リクエスト回数）と、最大の期待値を与えるリクエストの関係求める。
【０１２８】
さらに、解析部４２において、許可カウント決定部４６は、指定ＵＩ３２を介して、目標カウントの指定値を取得する。この指定値に対応する許可カウントが求められる。許可カウントはキャッシュメモリ制御部２６に伝えられ、キャッシング制御に使われる。
【０１２９】
図５７のキャッシュサーバ１４０のキャッシング動作を説明する。初期段階では、期待値および許可カウントを求められるだけの十分な量のリクエスト履歴が得られていない。そこで、キャッシュメモリ制御部２６は、デフォルト値の許可カウントを用いる。
【０１３０】
デフォルト値の許可カウントは、複数種類でもよい。そして、ユーザグループの種類に対応するデフォルト値が選択されてもよい。例えば、研究室、学部、大学といったグループの規模または他の性質に応じて異なるデフォルト値が設定される。好ましくは、グループ規模等に応じた適当な許可カウントが、予め統計的に求められ、使用される。この許可カウントは、図２４を用いて説明したグループ間のリクエスト幅の相違を反映しており、好適である。
【０１３１】
リクエスト履歴情報が十分な量に達したか否かは、例えば、履歴情報の集積期間に基づき判断される。例えば２ヶ月が経過したとき、十分な履歴情報が得られたと判断される。また例えば、リクエスト総数が適当な値に達したとき、リクエスト履歴情報が十分であると判断されてもよい。
【０１３２】
リクエスト履歴情報が集まると、解析部４２が、履歴情報を解析し、許可カウントテーブルを求める。さらに、解析部４２は、指定された目標カウントに対応する許可カウントを求める。この解析部４２は、許可カウントをキャッシュメモリ制御部２６に伝える。以降、キャッシュメモリ制御部２６は、解析部４２から伝えられた許可カウントをキャッシング制御に使う。なお、解析部４２の一部または全部の構成がキャッシュメモリ制御部２６に設けられてもよい。
【０１３３】
さらに好ましくは、図５７のキャッシュサーバ１４０は、リクエスト履歴のさらなる追跡調査を行う。すなわち、リクエスト履歴から許可カウントが求められた後も、引き続き、リクエスト履歴情報が収集される。解析部４２は、引き続き得られるリクエスト履歴情報を解析して、期待値を求め、許可カウントを求める。この処理は、上述の初めて許可カウントを求める処理と同様でよい。新たに求められた許可カウントがキャッシュメモリ制御部２６に伝えられる。このようにして、本実施形態によれば、許可カウントの値を調整することができる。
【０１３４】
なお、許可カウントの調整には、前回に許可カウントを求めた後の履歴情報のみが用いられてもよい。それ以前の履歴も含めた長期間の情報が用いられてもよい。
【０１３５】
上記の調整処理によれば、グループの変化に応じて、例えば、グループの規模や年齢層の変化に応じて、キャッシュ条件（許可カウント）を好適に調整することができる。また、季節等の環境の変化に合わせたキャッシュ条件の調整も可能となる。このようにして、より一層のコスト削減効果を得ることが期待できる。
【０１３６】
以上、本発明の好適な実施形態を説明した。なお、本実施形態では、本発明を実現するための主要な機能が、主に単独のキャッシュサーバに設けられた。しかし、本発明を実現可能な範囲で、それら機能がネットワークに分散して設けられてもよいことはもちろんである。例えば、一部または全部の機能が、コンテンツプロバイダに設けられてもよく、また、コンテンツレシーバ側に設けられてもよい。
【０１３７】
また、本実施形態では、本発明が、予め決まったユーザグループおよびキャッシュサーバに対して適用されていた。そして、これにより、システムが簡略化されている。しかし、本発明の範囲内で、より自動化の進んだシステムが採用されてもよい。
【０１３８】
典型的には、まず、前出のクラスタリング分析アルゴリズム（３．３節）が組み込まれる。そして、ユーザグループ（クラスタリング）が自動的に求められる。求められたクラスタリングのリクエスト特性が分析され、キャッシュ条件に基づくキャッシング制御が行われる。
【０１３９】
また、最適サーバ選択アルゴリズム（３．５節）が組み込まれてもよい。最適サーバ選択アルゴリズムにより、ユーザグループの近傍のキャッシュサーバが検出される。検出されたキャッシュサーバにて、上述した本実施形態のキャッシング制御が行われる。コンテンツデータは、検出されたキャッシュサーバに複製される。
【０１４０】
上述のクラスタ分析機能および最適サーバ選択機能についても、コンテンツ抽出機能と同様、局所的に設けられてもよく、分散して設けられてもよい。例えば、コンテンツプロバイダが、クラスタ分析機能と最適サーバ選択機能をもち、（１）ユーザグループおよびその近傍のサーバを見つけ、（２）ユーザグループのリクエスト特性を解析し、そして、（３）上述のキャッシング制御として、キャッシュサーバへの複製の指示を行ってもよい。
【０１４１】
以上、本発明を実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１４２】
【発明の効果】
以上に説明したように、本発明によれば、無駄なキャッシングを削減し、リクエスト回数増大が見込めるコンテンツを適切にキャッシングし、コンテンツ配信ネットワークにおけるコスト削減を図ることができる。
【図面の簡単な説明】
【図１】 コンテンツ自動配信システムの構築に関する提案システムを示す図である。
【図２】 コンテンツ自動配信システムの構築に関する提案システムを示す図である。
【図３】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図４】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図５】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図６】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図７】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図８】 プロキシサーバのアクセスログを解析した結果を示す図である。
【図９】 適当なクラスタリングの手順を示す図である。
【図１０】 リクエスト傾向を求めるためにログを取得したプロキシサーバを示す図である。
【図１１】 ログ解析結果の概要を示す図である。
【図１２】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１３】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１４】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１５】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１６】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１７】 リクエスト回数別にその後リクエストされる確率を表した図である。
【図１８】 リクエスト回数と期待値の関係を示す図である。
【図１９】 リクエスト回数と期待値の関係を示す図である。
【図２０】 リクエスト回数と期待値の関係を示す図である。
【図２１】 リクエスト回数と期待値の関係を示す図である。
【図２２】 リクエスト回数と期待値の関係を示す図である。
【図２３】 リクエスト回数と期待値の関係を示す図である。
【図２４】 期待値が最大となるリクエスト回数を示す図である。
【図２５】 クラスタリング毎のコンテンツ抽出閾値の適用を示す図である。
【図２６】 最適サーバ選択アルゴリズムを説明するための図である。
【図２７】 最適サーバ選択アルゴリズムを説明するための図である。
【図２８】 最適サーバ選択アルゴリズムを説明するための図である。
【図２９】 最適サーバ選択アルゴリズムを説明するための図である。
【図３０】 最適サーバ選択アルゴリズムを説明するための図である。
【図３１】 最適サーバ選択アルゴリズムを説明するための図である。
【図３２】 最適サーバ選択アルゴリズムを説明するための図である。
【図３３】 最適サーバ選択アルゴリズムを説明するための図である。
【図３４】 最適サーバ選択のための処理の流れを示す図である。
【図３５】 図３４の処理のイメージを示す図である。
【図３６】 図３４の処理のイメージを示す図である。
【図３７】 図３４の処理のイメージを示す図である。
【図３８】 図３４の処理のイメージを示す図である。
【図３９】 図３４の処理のイメージを示す図である。
【図４０】 解析モジュールと複製モジュールで構成されるシステムの概念を示す図である。
【図４１】 複製ポリシーの構成を示す図である。
【図４２】 複製モジュールの構成を示す図である。
【図４３】 提案システムの試作機の構成を示す図である。
【図４４】 解析モジュールの動作を示す図である。
【図４５】 解析モジュールの動作を示す図である。
【図４６】 提案システムにおけるサーバ間のネゴシエーションを示す図である。
【図４７】 提案システムの実験環境のネットワーク構成を示す図である。
【図４８】 試作システムのマシンスペックを示す図である。
【図４９】 試作システムの実験におけるリクエスト要求を示す図である。
【図５０】 試作機の実験データを示す図である。
【図５１】 実験におけるコンテンツの複製を示す図である。
【図５２】 実験におけるコンテンツ複製後のアクセスを示す図である。
【図５３】 実験結果を示す図である。
【図５４】 実験結果を示す図である。
【図５５】 本発明の好適な実施形態における、キャッシュサーバを含むコンテンツ配信システムの全体構成を示す図である。
【図５６】 図５５のシステムに設けられたキャッシュサーバの構成を示す図である。
【図５７】 リクエスト履歴の解析機能を備えた別の実施形態におけるキャッシュサーバの構成を示す図である。
【符号の説明】
１０ ユーザグループ
１２ ネットワークノード
１４ キャッシュサーバ
２４ キャッシュメモリ
２６ キャッシュメモリ制御部
２８ リクエスト回数カウンタ
３０ 許可カウントテーブル
４０ リクエスト履歴情報取得部
４２ 解析部
４４ 期待値算出部
４６ 許可カウント決定部
Claims (9)
- コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシュ制御方法であって、
コンテンツリクエスト履歴情報を取得するステップと、
前記コンテンツリクエスト履歴情報に基づき、あるリクエスト回数に達した後に目標リクエスト回数を達成した確率を目標リクエスト回数達成確率として算出するステップと、
前記目標リクエスト回数達成確率と前記あるリクエスト回数から前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求めるステップと、
前記あるリクエスト回数が前記期待値を最大にするとき、前記あるリクエスト回数をコンテンツ抽出閾値として設定するステップと、
コンテンツのリクエスト回数の増大を監視し、あるコンテンツのリクエスト回数が前記コンテンツ抽出閾値に達したときに前記あるコンテンツをキャッシュサーバにキャッシングさせるキャッシュ制御を行うステップと、
を含むことを特徴とするキャッシュ制御方法。 - 前記コンテンツ抽出閾値を、共通のポリシーによって管理されているネットワークを単位とするグループに応じて設定することを特徴とする請求項１に記載のキャッシュ制御方法。
- コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシュ制御方法であって、
共通のポリシーによって管理されているネットワークを単位とするグループによるコンテンツリクエスト履歴情報を取得するステップと、
前記コンテンツリクエスト履歴情報に基づき、あるリクエスト回数に達した後に目標リクエスト回数を達成した確率を目標リクエスト回数達成確率として算出するステップと、
前記目標リクエスト回数達成確率と前記あるリクエスト回数から前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求めるステップと、
前記あるリクエスト回数が前記期待値を最大にするとき、前記あるリクエスト回数をコンテンツ抽出閾値に設定するステップと、
前記グループによるコンテンツのリクエスト回数を監視し、あるコンテンツのリクエスト回数が前記コンテンツ抽出閾値に達したときに前記コンテンツをキャッシュサーバにキャッシングさせるキャッシュ制御を行うステップと、
を含むことを特徴とするキャッシュ制御方法。 - コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツリクエスト増大量の予測方法であって、
共通のポリシーによって管理されているネットワークを単位とするグループによるコンテンツリクエスト履歴情報を取得するステップと、
前記コンテンツリクエスト履歴情報に基づき、あるリクエスト回数に達した後に目標リクエスト回数を達成した確率を目標リクエスト回数達成確率として算出するステップと、
前記目標リクエスト回数達成確率と前記あるリクエスト回数から前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求めるステップと、
を含むことを特徴とするコンテンツリクエスト増大量の予測方法。 - コンテンツ配信ネットワーク上で提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリと、
共通のポリシーによって管理されているネットワークを単位とするグループによるコンテンツのリクエスト回数をカウントするリクエスト回数カウンタと、
コンテンツリクエスト履歴情報に基づき、あるリクエスト回数に達した後に目標リクエスト回数を達成した確率を目標リクエスト回数達成確率として算出し、前記目標リクエスト回数達成確率と前記あるリクエスト回数から前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求め、前記あるリクエスト回数が前記期待値を最大にするとき、前記あるリクエスト回数をコンテンツ抽出閾値として設定する解析部と、
前記リクエスト回数カウンタによりカウントされたあるコンテンツへのリクエスト回数が前記コンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングさせるキャッシュ制御部と、
を含むことを特徴とするキャッシュシステム。 - コンテンツ配信ネットワークを介して提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリを有するキャッシュサーバであって、
共通のポリシーによって管理されているネットワークを単位とするグループによるコンテンツのリクエスト回数をカウントするリクエスト回数カウンタと、
コンテンツリクエスト履歴情報に基づき、あるリクエスト回数に達した後に目標リクエスト回数を達成した確率を目標リクエスト回数達成確率として算出し、前記目標リクエスト回数達成確率と前記あるリクエスト回数から前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求め、前記あるリクエスト回数が前記期待値を最大にするとき、前記あるリクエスト回数をコンテンツ抽出閾値として設定する解析部と、
前記グループによるコンテンツのリクエスト回数が前記コンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングさせるキャッシュ制御部と、 を含むことを特徴とするキャッシュサーバ。 - コンテンツ配信ネットワーク上のキャッシュサーバによるコンテンツのキャッシングを制御するキャッシュ制御装置であって、
共通のポリシーによって管理されているネットワークを単位とするグループによるコンテンツのリクエスト回数をカウントするリクエスト回数カウンタと、
コンテンツリクエスト履歴情報に基づき、あるリクエスト回数に達した後に目標リクエスト回数を達成した確率を目標リクエスト回数達成確率として算出し、前記目標リクエスト回数達成確率と前記あるリクエスト回数から前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求め、前記あるリクエスト回数が前記期待値を最大にするとき、前記あるリクエスト回数をコンテンツ抽出閾値として設定する解析部と、
前記リクエスト回数カウンタによりカウントされたリクエスト回数が前記コンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュサーバにキャッシングさせるキャッシュ制御部と、
を含むことを特徴とするキャッシュ制御装置。 - コンテンツ配信ネットワークを介して提供されるコンテンツをキャッシュデータとして記憶するキャッシュメモリに関連して用いられる、コンピュータにて実行可能なプログラムであって、
コンテンツリクエスト履歴情報に基づき、あるリクエスト回数に達した後に目標リクエスト回数を達成した確率を目標リクエスト回数達成確率として算出し、前記目標リクエスト回数達成確率と前記あるリクエスト回数から前記目標リクエスト回数までの残リクエスト回数の積で表されるリクエスト増大量の期待値を求め、前記あるリクエスト回数が前記期待値を最大にするとき、前記あるリクエスト回数をコンテンツ抽出閾値として設定する機能と、
ユーザ端末が共通のポリシーによって管理されているネットワークを単位とするグループによるコンテンツのリクエスト回数をカウントし、リクエスト回数が前記コンテンツ抽出閾値に達したときに前記コンテンツを前記キャッシュメモリにキャッシングさせるキャッシュ制御機能と、
を前記コンピュータに実現させることを特徴とするプログラム。 - 請求項８に記載のプログラムを記録した、コンピュータにて読取可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002084620A JP4017065B2 (ja) | 2002-03-25 | 2002-03-25 | キャッシュ制御方法およびキャッシュシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002084620A JP4017065B2 (ja) | 2002-03-25 | 2002-03-25 | キャッシュ制御方法およびキャッシュシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003280975A JP2003280975A (ja) | 2003-10-03 |
| JP4017065B2 true JP4017065B2 (ja) | 2007-12-05 |
Family
ID=29231871
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002084620A Expired - Lifetime JP4017065B2 (ja) | 2002-03-25 | 2002-03-25 | キャッシュ制御方法およびキャッシュシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4017065B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4635682B2 (ja) * | 2005-03-29 | 2011-02-23 | ブラザー工業株式会社 | 情報処理装置、情報処理方法及び情報処理用プログラム |
| JP4929142B2 (ja) * | 2007-12-07 | 2012-05-09 | キヤノン株式会社 | データ処理装置及びその制御方法、コンピュータプログラム |
| US8321568B2 (en) * | 2008-03-31 | 2012-11-27 | Amazon Technologies, Inc. | Content management |
| US8417816B2 (en) * | 2009-02-20 | 2013-04-09 | Alcatel Lucent | Topology aware cache cooperation |
| EP2438742B1 (en) * | 2009-06-03 | 2013-12-18 | Telefonaktiebolaget LM Ericsson (publ) | Method and node for distributing electronic content in a content distribution network |
| JP2011003154A (ja) * | 2009-06-22 | 2011-01-06 | Nippon Telegr & Teleph Corp <Ntt> | 情報データ収集管理装置とその送信周期推定方法及びプログラム |
| EP2518950B1 (en) * | 2009-12-25 | 2018-11-21 | Panasonic Intellectual Property Management Co., Ltd. | Network location recognition system and terminal location recognition device |
| WO2013121745A1 (ja) * | 2012-02-13 | 2013-08-22 | 日本電気株式会社 | キャッシュ装置、配信方法、およびプログラム |
| JP6020278B2 (ja) | 2013-03-21 | 2016-11-02 | 富士通株式会社 | 自律分散型キャッシュ配置制御システム |
| US20170214674A1 (en) * | 2016-01-25 | 2017-07-27 | Google Inc. | Reducing latency |
| JP6662191B2 (ja) | 2016-05-18 | 2020-03-11 | 富士通株式会社 | 通信装置および通信方法 |
| JP2022032169A (ja) | 2020-08-11 | 2022-02-25 | 富士通株式会社 | データ管理装置、データ管理方法、およびデータ管理プログラム |
-
2002
- 2002-03-25 JP JP2002084620A patent/JP4017065B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003280975A (ja) | 2003-10-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11194719B2 (en) | Cache optimization | |
| US7062570B2 (en) | High performance server farm with tagging and pipelining | |
| US20180004748A1 (en) | Method and system of using a local hosted cache and cryptographic hash functions to reduce network traffic | |
| Bartolini et al. | A walk through content delivery networks | |
| US8572208B2 (en) | Shared content delivery infrastructure | |
| US20040236869A1 (en) | Parallel information delivery method based on peer-to-peer enabled distributed computing technology and the system thereof | |
| US20020099850A1 (en) | Internet content delivery network | |
| Zhang et al. | On wide area network optimization | |
| JP2001526814A (ja) | 分散型キャッシュ、プリフェッチ、複写の方法およびそのシステム | |
| JP4017065B2 (ja) | キャッシュ制御方法およびキャッシュシステム | |
| Hefeeda et al. | Design and evaluation of a proxy cache for peer-to-peer traffic | |
| CN107135266B (zh) | Http代理框架安全数据传输方法 | |
| US20020136204A1 (en) | Method and system for routing network traffic based upon application information | |
| US11606415B2 (en) | Method, apparatus and system for processing an access request in a content delivery system | |
| KR100873788B1 (ko) | 멀티미디어 컨텐츠 분배망 구성 방법 및 그를 이용한멀티미디어 컨텐츠 서비스 방법 | |
| Chandhok | Web distribution systems: Caching and replication | |
| KR20040076660A (ko) | 분산 처리 및 피어 대 피어 통신을 이용한 네트워크 상의정보 전송 병렬화 방법 및 그 시스템 | |
| Sivasubramanian et al. | Web replica hosting systems | |
| el-Khameesy et al. | A Proposed Model for Web Proxy Caching Techniques to Improve Computer Networks Performance | |
| Sivasubramanian et al. | Web replica hosting systems design | |
| Neumann | Contributions to Content Placement, Load-balancing and Caching: System Design and Security | |
| Joseph | A Review On A Load Balancing Technique For Cost Reduction In Cloud Data Transmission | |
| Data | CROSS-REFERENCE TO RELATED APPLICATIONS | |
| Chao | Content delivery networks | |
| Chauhan et al. | Named Data Networking: Content-Based Routing—Architecture, Challenges, and Applications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070501 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070614 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070717 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070814 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070904 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070912 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100928 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100928 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110928 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120928 Year of fee payment: 5 |