JP2003280975A

JP2003280975A - キャッシュ制御方法およびキャッシュシステム

Info

Publication number: JP2003280975A
Application number: JP2002084620A
Authority: JP
Inventors: Michimitsu Hattori; 進実服部; Minoru Nakazawa; 実中沢
Original assignee: Kanazawa Institute of Technology (KIT)
Current assignee: Kanazawa Institute of Technology (KIT)
Priority date: 2002-03-25
Filing date: 2002-03-25
Publication date: 2003-10-03
Anticipated expiration: 2022-03-25
Also published as: JP4017065B2

Abstract

(57)【要約】【課題】コンテンツ配信ネットワークにおけるコスト
を削減する。【解決手段】キャッシュサーバ１４は、コンテンツ配
信ネットワーク上に設けられている。キャッシュサーバ
１４は、リクエスト回数カウンタ２８を用いてコンテン
ツのリクエスト回数の増大を監視する。リクエスト回数
が増大することにより所定のキャッシュ条件が満たされ
るのを待ってからキャッシュサーバ１４がコンテンツを
キャッシングする。典型的には所定の数までリクエスト
数が増大したときにキャッシングが行われる。好ましく
は、リクエスト回数からその後のリクエスト回数増大量
の期待値が求められ、期待値が最大になるときのリクエ
スト回数が、キャッシュ条件の閾値として用いられる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンテンツ配信ネ
ットワーク上のキャッシュサーバによるコンテンツのキ
ャッシングの制御方法に関し、特に、コスト削減が可能
なキャッシュ制御方法に関する。

【０００２】

【従来の技術】インターネットはそれ以前のメディアに
はなかった双方向性を持ち、世界中に蓄積された情報を
容易かつ即時的に取得可能なハイパーメディアである。
そのため、インターネットを利用したビジネス（ｅ−ｃ
ｏｍｍｅｒｃｅ、デジタルコンテンツ配信など）やアプ
リケーションシステム（ＣＲＭ、ＥＲＰなど）、コミュ
ニケーション（ＶｏＩＰ、Ｅメールなど）は年々増加し
ており、インターネットの情報伝達媒体としての地位は
高まる一方である。しかし、近年の急激なアクセスネッ
トワークの高速大容量化や、コンテンツの大容量化によ
って、バックボーンネットワークの処理能力を超えるト
ラヒック需要が発生し、コンテンツの応答速度が著しく
低下する場面も多く見られるようになった。これは、イ
ンターネットの双方向性や即時性が損なわれることを意
味し、インターネットを利用したビジネスやシステムに
とって非常に重要な問題である。

【０００３】この問題に対処すべく、現在さまざまなコ
ンテンツ配信システムの研究開発が盛んに行われてお
り、その中の１つにコンテンツ配信ネットワーク（Cont
ent Distribution/Delivery Network、以下ＣＤＮ）が
ある。ＣＤＮは、ネットワークエッジに配備したサーバ
を用いて、インターネットにおける渋滞や遅延を解消す
るソリューションであり、１９９９年に設立された米Ａ
ｋａｍａｉ社のコンテンツデリバリネットワークがはじ
まりである。Ａｋａｍａｉは世界中に配備したサーバを
結ぶサーバネットワークと、独自のルーティング技術に
よって顧客（コンテンツ事業者）のコンテンツをエンド
ユーザに届けるシステムを構築し、応答速度の低下の問
題を解決した。また、ＣＤＮはそのコンテンツ配信能力
から、Ｐ２Ｐネットワークやグローバルコンピューティ
ング（以下Ｇｒｉｄ）におけるミドルウェアとしての役
割を期待されている。

【０００４】しかし、ミドルウェアとしてＣＤＮを用い
るにはコストが高く、より低コストのＣＤＮサービスが
実現されることが求められる。さらに、地理的に離れた
場所で同質のＣＤＮサービスを受けられなければ、アプ
リケーションに地域格差が生じる問題も発生する。これ
に関する最近の活動では、ＣＤＮピアリングに関する活
動が多い。ＣＤＮピアリングとは、異なる事業者間でＣ
ＤＮリソースを共有し合うことである。これによって複
数の事業者が提携することでコストを抑えつつ大規模な
ＣＤＮを構成できるが、本格的な実用段階には至ってい
ない。また、仮に実用段階に至ったとしてもＣＤＮを利
用する分のコストはかかり、アプリケーション（結局は
ユーザ）の負担が増えるという問題は依然として残る。

【０００５】

【発明が解決しようとする課題】上述したようにＣＤＮ
が注目を集めており、ＣＤＮをインフラとする様々なコ
ンテンツ配信サービスが行われている。そして、アクセ
スネットワークのブロードバンド化に伴って、ＣＤＮ市
場が成長し続けることが予想される。しかし、広域なネ
ットワーク上でＣＤＮを用いるためにはコストが高いと
いう課題があり、ＣＤＮプラットフォームのコスト最適
化が求められる。

【０００６】コストの問題ついてさらに説明する。ＣＤ
Ｎには、キャッシュサーバを用いたものと、バックボー
ンネットワークを活用しエンドユーザまでコンテンツを
配信するものがある。ここでは、主として、前者のキャ
ッシュサーバを用いるＣＤＮ技術に着目する。既存のＣ
ＤＮの目的は、単純に「利益の最大化」であった。ここ
でいう利益とは、エンドユーザからキャッシュサーバへ
行われるリクエスト回数である。利益の最大化を達成す
るため、従来、キャッシュサーバは、リクエストされた
任意のコンテンツを無差別にキャッシングする。その結
果、キャッシングされるコンテンツ数が非常に多く、こ
のことが、キャッシュサーバに多大な容量を要求し、そ
して、コストを押し上げる要因になっている。

【０００７】本発明は上記課題に鑑みてなされたもので
あり、その目的は、コンテンツ配信におけるコストを削
減可能な技術を提供することにある。さらに、本発明の
目的は、リクエスト回数の増大が見込める適当なコンテ
ンツをキャッシング可能にすることによってコストを適
切に削減可能な技術を提供することにある。

【０００８】

【課題を解決するための手段】本発明は、コンテンツ配
信ネットワーク上のキャッシュサーバによるコンテンツ
のキャッシングを制御するキャッシュ制御方法に関す
る。本発明のキャッシュ制御方法は、コンテンツのリク
エスト回数の増大を監視し、リクエスト回数が増大する
ことにより所定のキャッシュ条件が満たされるのを待っ
てから前記コンテンツをキャッシュサーバにキャッシン
グさせる。好ましくは、前記キャッシュ条件は、リクエ
スト回数が多いほどその後のリクエストの可能性が大き
いリクエスト特性に基づき設定される。

【０００９】典型的には、キャッシュ条件は、リクエス
ト回数が適当な値まで増大したときに満たされる。この
判断を実現する処理には、典型的にはリクエスト回数そ
のものが用いられるが、他のパラメータが用いられても
よい。

【００１０】本発明によれば、例えば、１回だけリクエ
ストされた後にリクエストされないコンテンツを無駄に
キャッシングするのを回避できる。実際、このようなコ
ンテンツは相当に多い。このようにして、本発明によれ
ば、適当なコンテンツを限定的にキャッシングすること
により、コストの削減を図れる。

【００１１】好ましくは、前記キャッシュ条件は、リク
エスト回数とその後の目標リクエスト回数達成確率との
関係に基づき設定される。目標リクエスト回数達成確率
は、例えば、リクエストのログを解析することによって
得られる。

【００１２】好ましくは、前記キャッシュ条件は、前記
目標リクエスト回数達成確率から得られるリクエスト増
大量の期待値に基づき設定される。好ましくは、期待値
が適当な大きさになるリクエスト回数が、キャッシュ条
件としてのコンテンツ抽出閾値に設定される。より好ま
しくは、期待値が最大になるときのリクエスト回数が、
キャッシュ条件としてのコンテンツ抽出閾値に設定され
る。そして、本発明は、コンテンツのリクエスト回数が
前記コンテンツ抽出閾値まで増大したときに前記コンテ
ンツを前記キャッシュサーバにキャッシングさせる。本
発明によれば、期待値に基づくキャッシングの制御によ
り、リクエスト回数の増大が見込めるコンテンツを適切
にキャッシングできる。

【００１３】なお、本発明の範囲内で、目標リクエスト
回数達成確率に基づく他の制御が行われてもよい。例え
ば、目標リクエスト回数達成確率が適当な値になるとき
のリクエスト回数がコンテンツ抽出閾値として用いられ
てもよい。しかし、上述の期待値に基づく制御は、後述
にてより詳細に説明されるように、リクエスト回数の増
大が見込めるコンテンツを適当なタイミングでキャッシ
ングでき、本発明の利点が一層好適に得られると考えら
れる。

【００１４】さらに好ましくは、ユーザグループによっ
て前記リクエスト特性が異なることに基づき、キャッシ
ュ条件がユーザグループに応じて設定される。そして、
ユーザグループによるリクエスト回数に基づきキャッシ
ングが制御される。ユーザグループに応じた制御によ
り、さらなるコスト削減効果が期待できる。また、本発
明は、後述にてさらに説明するように、ユーザグループ
によって異なる被リクエストコンテンツの幅を反映した
適切な制御を可能にする。

【００１５】本発明の別の態様は、コンテンツ配信ネッ
トワーク上のキャッシュサーバによるコンテンツのキャ
ッシュの制御方法であって、ユーザグループによるコン
テンツリクエスト履歴情報を取得するステップと、前記
コンテンツリクエスト履歴情報に基づき、リクエスト回
数とその後の目標リクエスト回数達成確率との関係を求
めるステップと、前記目標リクエスト回数未満のリクエ
スト回数を対象として、前記目標リクエスト回数達成確
率と前記目標リクエスト回数までの残リクエスト回数の
積で表されるリクエスト増大量の期待値を求めるステッ
プと、前記期待値が最大になるときのリクエスト回数を
コンテンツ抽出閾値に設定するステップと、前記ユーザ
グループによるコンテンツのリクエスト回数を監視し、
あるコンテンツのリクエスト回数が前記コンテンツ抽出
閾値まで増大したときに前記コンテンツをキャッシュサ
ーバにキャッシングさせるキャッシュ制御を行うステッ
プと、を含む。

【００１６】本発明の別の態様は、コンテンツリクエス
ト増大量の予測方法であり、ユーザグループによるコン
テンツリクエスト履歴情報を取得するステップと、前記
コンテンツリクエスト履歴情報に基づき、リクエスト回
数とその後の目標リクエスト回数の達成確率との関係を
求めるステップと、前記目標リクエスト回数未満のリク
エスト回数を対象として、前記目標リクエスト回数達成
確率と前記目標リクエスト回数までの残リクエスト回数
の積で表されるリクエスト増大量の期待値を求めるステ
ップと、を含む。

【００１７】本発明の別の態様はキャッシュシステムで
あり、コンテンツ配信ネットワーク上で提供されるコン
テンツをキャッシュデータとして記憶するキャッシュメ
モリと、ユーザグループによるコンテンツのリクエスト
回数をカウントするリクエスト回数カウンタと、前記リ
クエスト回数カウンタによりカウントされたリクエスト
回数が所定のコンテンツ抽出閾値に達したときに前記コ
ンテンツを前記キャッシュメモリにキャッシングさせる
キャッシュ制御部と、を含む。上述の構成がキャッシュ
サーバに設けられるとき、そのキャッシュサーバが単独
で本態様のキャッシュシステムであってよい。また、上
述の構成がコンテンツ配信サービス上で分散されると
き、それらが本態様のキャッシュシステムであってよ
い。

【００１８】好ましくは、キャッシュシステムは、前記
ユーザグループによるコンテンツリクエスト履歴情報を
解析することにより前記コンテンツ抽出閾値を求める解
析部を含む。好ましくは、前記解析部は、前記コンテン
ツリクエスト履歴情報から得られるリクエスト増大の期
待値が最大になるときのリクエスト回数を前記コンテン
ツ抽出閾値として求める。

【００１９】本発明の別の態様は、コンテンツ配信ネッ
トワークを介して提供されるコンテンツをキャッシュデ
ータとして記憶するキャッシュメモリを有するキャッシ
ュサーバであって、ユーザグループによるコンテンツの
リクエスト回数が所定のコンテンツ抽出閾値に達したと
きに前記コンテンツを前記キャッシュメモリにキャッシ
ングするように制御される。

【００２０】本発明の別の態様は、コンテンツ配信ネッ
トワーク上のキャッシュサーバによるコンテンツのキャ
ッシングを制御するキャッシュ制御装置であって、ユー
ザグループによるコンテンツのリクエスト回数をカウン
トするリクエスト回数カウンタと、前記リクエスト回数
カウンタによりカウントされたリクエスト回数が所定の
コンテンツ抽出閾値に達したときに前記コンテンツを前
記キャッシュサーバにキャッシングさせるキャッシュ制
御部と、を含む。本態様のキャッシュ制御装置は、コン
テンツ配信ネットワーク上の局所的な装置で構成されて
もよく、分散された複数の装置で構成されてもよい。

【００２１】本発明の別の態様は、コンテンツ配信ネッ
トワークを介して提供されるコンテンツをキャッシュデ
ータとして記憶するキャッシュメモリに関連して用いら
れる、コンピュータにて実行可能なプログラムであっ
て、ユーザグループによるコンテンツのリクエスト回数
をカウントし、リクエスト回数が所定のコンテンツ抽出
閾値に達したときに前記コンテンツを前記キャッシュメ
モリにキャッシングさせるキャッシュ制御を前記コンピ
ュータに実現させる。本発明の別の態様は、上述のプロ
グラムを記録した、コンピュータにて読取可能な記録媒
体である。

【００２２】さらに、以上の構成要素の任意の組合せ、
本発明の表現を方法、装置、サーバ、システム、コンピ
ュータプログラム、記録媒体などの間で変換したものも
また、本発明の態様として有効である。

【００２３】

【発明の実施の形態】以下、本発明についてさらに説明
する。以下では、まず、「ユーザクラスタリング機構を
用いたコンテンツ自動配信システムの構築」の提案につ
いて詳細に説明する。その後に、同技術を適用したキャ
ッシュサーバで構成されるシステムの実施形態について
説明する。「ユーザクラスタリング機構を用いたコンテ
ンツ自動配信システムの構築」１．コンテンツ自動配信システムの構築に関する説明の
全体概要を説明する。以下では、まず、ＣＤＮ（コンテンツ配信ネットワー
ク）の概要を説明し（２章）、それから、本提案システ
ムについて説明する（３章）。ここでは、本提案システ
ムの位置づけ（３．１節）、具体的手法（３．２〜３．
５節）、試作機の構成（３．６〜３．７節）を説明す
る。さらに、試作機による実験および評価を説明する
（４章）。

【００２４】２．ＣＤＮ（Content Distribution/Deliv
ery Network）ＣＤＮとは、ネットワークエッジに配備されたサーバを
むすんだサーバネットワークを用いてインターネットの
渋滞や遅延を解消するソリューションである。既に述べ
たように、１９９９年に米Akamai社がはじめたコンテン
ツ・デリバリー・ネットワークがはじまりであり、その
後今日に至るまで多くのＣＤＮプロバイダが生まれてい
る。本章では、ＣＤＮのアーキテクチャおよびプロトコ
ルについて説明する。

【００２５】２．１ＣＤＮアーキテクチャおよびプロ
トコルＣＤＮはコンテンツ提供者とエンドユーザとの間に位置
し、コンテンツ配信を効率化するために様々な機能を果
たす。ＣＤＮを構成する主な機能には次がある。すなわ
ち、リクエスト・ルーティング、ディストリビューショ
ン、アカウンティングおよびコンテンツ・アダプテーシ
ョンである。

【００２６】２．１．１リクエスト・ルーティング
（Request Routing System）リクエスト・ルーティングとは、分散された多数のサロ
ゲートの中から最も適切な１つを選び出し、そこへエン
ドユーザからの要求を誘導することである。単純な例と
して、BIND（参考文献：Paul Albitz and Cricket Liu,
DNS & BIND Third Edition, O'REILLY, 2000）のラウ
ンドロビン機能による負荷分散がある。しかしこの方式
はアクセスを順に振り分けるだけであり、サーバやネッ
トワークの混雑度に応じた負荷分散機能はない。サロゲ
ートの中から最適なものを選択するためには様々な条件
を考慮しなければならず、以下のようなものが考えられ
ている。・サロゲートのＣＰＵ負荷、応答時間、・サロ
ゲートにおけるコンテンツのキャッシュ状況、・サロゲ
ートのカバーするコンテンツ種類、・ユーザとサロゲー
ト間のネットワーク混雑度、パケット損失率、回線速
度、・サロゲート運用者、ＩＳＰ、コンテンツ提供者等
関係者間での契約関係。

【００２７】リクエスト・ルーティングシステムには、
上で挙げた情報を関係する機器の間で常時交換し、最新
のパラメータを保持することが求められる。

【００２８】現在リクエスト・ルーティングについては
多くの手法が考案されているが、ＩＥＴＦ（Internet E
ngineering Task Force）のＣＤＩ（Content Distribut
ionInternetworking）ＷＧにおいてもこの技術が検討さ
れている（参考文献：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）。

【００２９】２．１．２ディストリビューション（Di
stribution System）プロキシ・キャッシュ・サーバへのコンテンツ配信は、
エンドユーザからの要求により受動的に行われるが、そ
れだけでは効率が悪い。複数のキャッシュサーバ間で通
信を行い、それらが近隣のキャッシュサーバからコンテ
ンツを複製する方式など、効率的にコンテンツを配信す
るための研究がＩＲＣａｃｈｅプロジェクトを中心に行
われ、いくつかのプロトコルが提案された（参考文献：
P. Vixieand D. Wessels. Hyper Text Caching Protoco
l (HTCP). RFC2187. September,1997）、（参考文献：
V.Valloppillil and K.W.Ross. Cache Array Routing P
rotocol v1.0. draft-vinod-carp-v1-03.txt February,
1998）。

【００３０】ＣＤＮにおけるサロゲートでは、さらにコ
ンテンツ提供者側による積極的あるいは戦略的にコンテ
ンツ配信制御が行われる。さきがけ的存在として、Ａｋ
ａｍａｉ社が開発したＦｒｅｅＦｌｏｗがある。さら
に、サロゲート間での通信に専用回線や衛星回線などを
活用し、コンテンツ配信の効率化を行う企業も現れてき
ている。

【００３１】２．１．３アカウンティング（Accounti
ng System）一般的に、インターネットを介して情報を提供しようと
いう場合にはＡＡＡ（Authentication, Authorization,
Accounting）の３つの処理が必要である。それぞれ
「認証」「許可」「課金」という意味である。認証は相
手が誰であるかを確認することであり、許可は確認され
た相手に対してどのような権限を与えるか制御すること
であり、課金は料金計算のための情報収集、料金請求な
どの処理である。これら３つを総合的に議論する場とし
て、ＩＥＴＦにはＡＡＡワーキンググループがある。こ
のＷＧの目標は、多様なアプリケーションに共通に使用
可能な汎用性のあるＡＡＡのためのプロトコルを定義す
ることにある。

【００３２】２．１．４コンテンツ・アダプテーショ
ン（Content Adaptation）エンドユーザの嗜好や特性、使用する機器のスペックな
どに合わせてコンテンツを修正／加工することを、コン
テンツ・アダプテーションといい、コンテンツ配信の付
加価値を高めることを期待されている。コンテンツ・ア
ダプテーションの例を示すと、１）言語の翻訳、２）メ
ディアタイプの適応、３）ユーザ特性に合わせた広告挿
入、４）地域データの挿入、５）ウィルス・スキャンで
ある。

【００３３】しかし、サロゲートにおいてコンテンツの
適応をどこまで行うことができるかという問題もある。
デジタル著作権の管理技術は現在十分に発展しておら
ず、法整備もなされていないため、この問題は解決され
るに至っていない。ＣＤＮがビジネスとして発展するた
めには、この問題に早急に取り組まなければならないと
いわれている。

【００３４】３．提案システムこの章では、本提案システムの構成と、それを実現する
ための方法、本システムを実装した試作機の構成などに
ついて説明する。

【００３５】３．１提案システム概要本提案システムの目的は、アプリケーションからＣＤＮ
を低コストで使用できるようにすることである。低コス
ト化を図るためには、第１に設備投資を減らす必要があ
る。本システムは完成後にフリーソフトウェアとして配
布することが好ましいと考えられる。ＣＤＮプラットフ
ォームを広く浸透させることによって、アプリケーショ
ン開発の活性化が期待できる。本システムの構成を図１
および図２に示す。

【００３６】ディストリビューションシステムは、本シ
ステムを組込んだサーバ（Distribution Server,以下Ｄ
Ｓ)群から成り、各サーバは自律的に協調し、コンテン
ツを複製し合う。キャッシュサーバ（ＣＳ）はＤＳに含
まれる。また、オリジンもディストリビューションシス
テムに含まれる。協調関係については全てのサーバが同
等であり、図２にそれを示す。

【００３７】リクエストルーティングシステムは、ユー
ザ（アプリケーション）からの名前解決に対して応答す
るシステムである。コンテンツの名前と所在を保持し、
これらはディストリビューションシステムからの登録に
よって更新される。ＤＮＳ（Domain Name Service）サ
ーバとほぼ同等の役割を負う。

【００３８】図１について説明すると、（１）オリジン
（Ｗｅｂサーバに限らず情報の発生源という意味）は、
リクエストルーティングシステムへコンテンツ（名前、
場所）を登録する。（２）コンテンツの場所を問い合わ
せる。（３）登録リストの中から最も適切と思われる場
所を応答として返す。（４）（３）の結果がオリジンサ
ーバだった場合、オリジンサーバへリクエストする。
（５）コンテンツの取得が行われる。（６）オリジンは
コンテンツの複製を行なうために、複製先サーバリスト
を取得する。（７）複製ポリシーに基づいてコンテンツ
の複製を行う。（８）コンテンツを受け取ったサーバは
リクエストルーティングシステムへ、コンテンツ（名
前、場所）を登録する。（９）リクエストルーティング
システムから複製先サーバリストを取得する。（１０）
複製先サーバの方がオリジンサーバよりもエンドユーザ
に近い場合は、複製先サーバへリクエストする。（１
１）コンテンツの取得が行われる。

【００３９】３．２提案システムの具体化ここでは、主としてディストリビューションシステムに
ついて説明する。ディストリビューションシステムの役
割は、最適なコンテンツ配信を行うことである。３．
２．１では本システムにおける「最適なコンテンツ配
信」の意味について述べ、３．２．２でその実現手法、
３．２．３では本システムで用いる具体化について述べ
る。

【００４０】３．２．１最適なコンテンツ配信コンテンツ配信における「最適」という言葉には様々な
意味があり、配信側か受信側かによっても意味が異な
る。ここでは、配信側と受信側における「最適なコンテ
ンツ配信」の意味について述べる。ただし、ここでは、
狭義のコンテンツ配信（コンテンツの配送方法）につい
て説明する。

【００４１】まず、受信側（つまりはユーザ側）から見
た最適なコンテンツ配信であるが、エンドユーザに対し
ての応答速度が最速であるような配信を最適ということ
もあれば、エンドユーザへジッタのない安定したデータ
転送ができる配信を最適ということもある。いくらジッ
タのない安定したデータ転送でも、応答速度が非常に遅
い場合は最適とはいえず、逆に応答速度がいくら高速で
もデータ転送が途切れてしまっても最適とはいえない。
また、応答速度が高速でジッタもなかったとしても、一
度に転送できるデータ転送量が小さければ最適とはいえ
ない。このように、最適となるための必要条件を挙げれ
ばキリがなく、全ての条件を満足することなど不可能に
近い。そこで、インターネットにおいては、ある１つの
サービスを提供するために最低限必要な品質をＱｏＳ
（Quality of Service）とよび、このＱｏＳを満たせば
「最適」となる。つまり、最適なコンテンツ配信とはＱ
ｏＳを満足する配信である。

【００４２】しかし、ベストエフォート型のインターネ
ット上、特にネットワーク的に離れた地域間による「Ｅ
ｎｄｔｏＥｎｄ」での通信ではＱｏＳ実現すら難し
く、ＲＳＶＰやＤｉｆｆｓｅｒｖ、ＭＰＬＳなどの技術
を用いたソリューションが期待されていた。だが、この
流れはＣＤＮの登場によって大きく流れが変わることに
なる。「ＥｎｄｔｏＥｎｄ」という概念を戦略的に
インターネットに持ち込むことによって、ＱｏＳ実現を
可能にした。ネットワークエッジに配置されたサーバ、
つまりエンドユーザに近いサーバからコンテンツを配信
することによって、混雑する回線や遅い回線を回避し、
応答速度が高速でスループットの高いデータ転送をジッ
タもエラーもなく行えることを意味する。まとめると、
ＣＤＮを用いれば、ＱｏＳ保証されたサービスが可能で
あり、受信側にとって最適なコンテンツ配信が行えると
いえる。

【００４３】次に、配信側にとって最適なコンテンツ配
信についてであるが、受信側にはない条件が必要とな
る。それは、コンテンツ配信資源の効率的活用である。
配信側の立場では、コンテンツ配信にかかるコストより
も得られる利益が少ないと、コンテンツ配信を行う意味
がなくなってしまうからである。ここでいうコストと
は、コンテンツ配信に必要となるあらゆるもので、ディ
スク／メモリ使用量やコンテンツ複製トラフィック、計
算負荷などであり、配信側は利益を高めるためにはコス
トの最適化を行う必要がある。つまり、コストの最適化
を行いつつ、ユーザへ近いサーバへコンテンツを配置す
ることが、配信側にとっての「最適なコンテンツ配信」
といえる。

【００４４】３．２．２最適なコンテンツ配信の実現
手法３．２．１で最適なコンテンツ配信とは「コストの最適
化が行われたＣＤＮである」と説明したが、それに対し
て本システムがとるアプローチを述べる。本システムは
コストの最適化を行うために「多く必要とされるコンテ
ンツを、多く必要とするユーザから、最も近いサーバ
へ」というコンセプトに基づいて設計する。

【００４５】コンテンツ複製対象を、多く必要とされる
コンテンツに限定することで大きなコスト削減効果が見
込まれる。図３〜図８は、それぞれ異なったプロキシサ
ーバのアクセスログを解析した結果である。図３と図
４、図７は研究室で使用しているプロキシサーバ（Ｓｑ
ｕｉｄ）、図５と図６、図８は情報工学科のプロキシサ
ーバ（Ｓｑｕｉｄ）のものである。ユーザのリクエスト
傾向としてわかるのは、リクエスト回数の少ないコンテ
ンツ数の割合は非常に高いがそれらに対するリクエスト
数の割合はそれほど高くなく、リクエスト回数の多いコ
ンテンツはコンテンツ数の割合は少ないがリクエスト数
の割合が高いということである。図６を基にして考えれ
ば、２回以上リクエストされたコンテンツをキャッシュ
することにするだけで、６６．２３％のディスク／メモ
リ使用量が削減できる。また、３．４節で詳しく述べる
が、リクエストの多いコンテンツは、その後もリクエス
トされる可能性が高いので、リクエストの多いコンテン
ツのみでコンテンツの複製を行う。

【００４６】次に、コンテンツを必要としているユーザ
に近いサーバに限定してコンテンツを複製する理由を説
明する。これは、リクエストのネットワーク的な偏りを
利用しようというものである。インターネットには数多
くのネットワークが相互接続されており、ネットワーク
によってユーザ数もリクエスト傾向も違う。全てのネッ
トワークを同じように捉えるのではなく、ネットワーク
単位で捉えることによってそのネットワークに特化した
コンテンツ配信が行える。よって、ネットワーク単位で
リクエストを解析することは重要であり、コンテンツの
複製はネットワーク毎（つまりネットワークに一番近い
サーバ）に行うべきである。ネットワークの分割の仕
方、つまりはユーザのグルーピング方法については３．
３節で説明する。

【００４７】３．２．３実現手法の具体化本システムにおいて用いる手順について説明する。本シ
ステムは大きく分けて３つの手順をふんでコンテンツの
複製が行われる。このような手順をふむ理由は３．２．
２で説明した通りである。３つの手順は、（１）ユーザ
クラスタリング（ユーザのグループ化）、（２）リクエ
ストの多いコンテンツの抽出、（３）最適サーバ選択で
ある。（１）については３．３節、（２）については
３．４節、（３）については３．５節で説明する。

【００４８】（ポリシーについて）後に詳細に述べるよ
うに、本提案システムでは、ＣＤＮにポリシーが組み込
まれる。ポリシーは複製モジュールとのインタフェー
スに従いさえすればどのようなものでもよく、様々なア
ルゴリズムが適用可能である。

【００４９】今回提案するポリシーは「コンテンツ配信
におけるコストを削減」というものである。既存のＣＤ
Ｎの目的が単純に「利益の最大化」というものであるの
に対して、本提案ポリシーはコストの無駄を省くという
ことが目的となる。ここでいう利益とは、エンドユーザ
からＣＳ（ＤＳ）へ行われるリクエスト数のことであ
る。コンテンツ配信においては、より多くのリクエスト
に対応できるということが利益といえる。提案ポリシー
を実現するために求められる条件を３つ示す。（１）利
益を多く生む場所（地域）の把握、（２）利益の高いコ
ンテンツの抽出、（３）最適なサーバにコンテンツを複
製である。これら条件（１）〜（３）を満足するため
に、上述の３つのアルゴリズムがそれぞれ有利に用いら
れる。すなわち条件（１）にはユーザクラスタリングが
対応し、条件（２）には選択的コンテンツ抽出が対応
し、条件（３）には最適サーバ探索が対応する。

【００５０】３．３ユーザクラスタリング本システムにおけるユーザクラスタリングとは、ユーザ
を共通のポリシーによって管理されているネットワーク
単位によってグループ化することである。ここで用いら
れる好適なクラスタリングアルゴリズムは、「Balachan
der Krishnamurthy and Jia Wang. On Network-Aware C
lustering of Web Clients. In Proceedings of ACM SI
GCOMM, August 2000.」である。このアルゴリズムは、
ＢＧＰ（Broader Gateway Protocol）ルーティングテー
ブルのスナップショットを用いてユーザのクラスタリン
グを行う（K.Lougheed and Y.Rekhter. A Border GateW
ayProtocol. RFC1163, IETF, June 1990.）。ルーティ
ングテーブルのエントリーをクラスタリングの単位とす
ると、ＢＧＰルーティングテーブルがネットワークの障
害や変更に対応するので、クラスタリングの精度は高く
なる。上述のBalachander Krishnamurthyらの実験結果
によると、９９．９％のユーザがどれかのクラスターに
属し、９０％以上の精度があると報告されている。クラ
スタリングの手順を図９に示すとともに、以下に図９に
ついて説明する。

【００５１】「ＩＰＡｄｄｒｅｓｓｅｘｔｒａｃｔ
ｉｏｎ」：アクセスログからIPアドレスを抽出する。

【００５２】「Ｎｅｔｗｏｒｋｐｒｅｆｉｘｅｘｔ
ｒａｃｔｉｏｎ（Prefix extraction, unification, me
rging）」：ＢＧＰルーティングテーブルから、プレフ
ィックスエントリーを抽出する。プレフィックスエント
リーのフォーマットがＢＧＰルーティングテーブルによ
って異なるのでマージする。フォーマットには下の３種
類ある。すなわち、「X1.X2.X3.X4/k1.k2.k3.k4」、「X
1.X2.X3.X4/m」および「X1.X2.X3.0」である。

【００５３】「Ｃｌｉｅｎｔｃｌｕｓｔｅｒｉｄｅ
ｎｔｉｆｉｃａｔｉｏｎ」：ログから抽出したユーザＩ
ＰアドレスについてＢＧＰルーティングテーブルから抽
出したプレフィックスと比較し、最長一致するプレフィ
ックスを求める。ユーザは最長一致したプレフィックス
のクラスターに属すると識別される。

【００５４】「Ｖａｌｉｄａｔｉｏｎ」：Ｎｅｔｗｏｒ
ｋ−Ａｗａｒｅｃｌｕｓｔｅｒｉｎｇには、２つの理
由によりクラスターが誤って求められる可能性がある。
クラスターがもう１つ以上のネットワークを含んでいる
場合と、１つのネットワークがいくつかのクラスターに
分割されている場合である。この問題を解決するため
に、ｎｓｌｏｏｋｕｐとｔｒａｃｅｒｏｕｔｅを用い
る。ｎｓｌｏｏｋｕｐはホストのドメイン名を問い合わ
せるツールである。同じプレフィックスのユーザには同
じドメイン名がついている性質を利用してクラスタリン
グの精度を高めようというものであるが、前出のBalach
ander Krishnamurthyらの文献によれば、ｎｓｌｏｏｋ
ｕｐによってドメイン名が求められる確率は５０％程度
であり、nslookupだけでは問題を解決できない可能性が
ある。そこでｔｒａｃｅｒｏｕｔｅを適切なかたちで適
用してクラスタリングの精度を高めることが好適であ
る。ｔｒａｃｅｒｏｕｔｅはユーザまでの経路情報を得
ることができるので、同じネットワークに属しているか
どうかを判断することができる。

【００５５】「Ｅｘａｍｉｎｉｎｇｉｍｐａｃｔｏ
ｆｎｅｔｗｏｒｋｄｙｎａｍｉｃｓ」：ＢＧＰルー
ティングテーブルがネットワークの障害や変更に即座に
更新されるので、クラスタリングをネットワークの変動
に対応させることができる。「Ｓｅｌｆ−ｃｏｒｒｅｃ
ｔｉｏｎａｎｄａｄａｐｔａｔｉｏｎ」：Ｖａｌｉ
ｄａｔｉｏｎによって求めたクラスタリングの誤検出を
修正する。1人のユーザが2つのクラスターにまたがって
いる場合、1つのクラスターとする。1つのネットワーク
がいくつかのネットワークを含んでいた場合、ｔｒａｃ
ｅｒｏｕｔｅによって得られた結果に基づいてクラスタ
ーを分割する。

【００５６】（グループ化の利点）既に述べたように、
ユーザクラスタリングとは、ユーザのグループ化のこと
である。ここで、グループ化による利点を以下に２つ挙
げる。すなわち、（１）リクエスト傾向の把握がしやす
い、（２）複製を効率的に行える、である。

【００５７】（１）リクエスト傾向の把握がしやすい利
点：ユーザ1人毎にリクエスト傾向を把握するよりもグ
ループ単位で行う方が処理負荷を軽減することができ、
把握しやすいものとなる。グループが類似した嗜好や特
徴を持つユーザの集合だとすれば、グループ内のユーザ
は類似したコンテンツをリクエストする事が期待できる
ため、グループ単位のリクエスト傾向はユーザ単位のも
のと近似と考えることができる。つまり、グループ化に
よってユーザ単位でリクエスト傾向を把握する必要はな
くなり、ユーザ単位では難しい傾向の把握をしやすくな
ることを意味する。

【００５８】（２）複製を効率的に行える利点：ユーザ
単位でコンテンツの複製を行うのではなくグループ単位
で行うため、複製１回に対する効果を高めることができ
る。例えば、リクエスト傾向の異なる２つのグループが
あった場合、リクエストの少ないグループに対してコン
テンツの複製を行うよりも、リクエストの多いグループ
に対して行う方が提案したポリシーに基づいていて効率
的である。既存ＣＤＮがリクエストの有無によってコン
テンツの複製を行うかどうかの判断をしてきたのに対
し、リクエスト数の多いか少ないかによって複製の判断
を行うという本提案ポリシーにおいては、グループ化が
非常に有効である。

【００５９】このようにグループ化によってもたらされ
る効果は高いのだが、ここで重要なのはグループ化が何
に基づいて行われて、その精度がどの程度であるかとい
うことである。今回はコンテンツ配信における最適化と
いうことを重視し、上述したように、ネットワークトポ
ロジーに基づいてユーザのグループ化を行うNetwork-Aw
are Clusteringを用いる。このアルゴリズムは、ＢＧＰ
ルーティングテーブルのスナップショットとユーザのＩ
Ｐアドレスを使用してグループ化（クラスタリング）を
行うものであり、このアルゴリズムを簡略化したものが
本提案システムに好適に適用される。

【００６０】３．４コンテンツ抽出アルゴリズムコンテンツを選択的に抽出するのは、最小限のコストで
最大限の利益（リクエスト数）を上げるコスト最適化の
ためである。リクエストの多いコンテンツのみを複製対
象とすることで、リクエストの少ない（利益の少ない）
コンテンツに関するコストを削減することができる。し
かし、この方法によるコスト最適化のためには、リクエ
ストの多いコンテンツをリクエストされる以前に把握す
る必要がある。これはユーザのリクエストを予測するこ
とであり、非常に難しい問題である。なぜなら、どのコ
ンテンツがどの程度リクエストされるのかを予測するた
めには、ユーザ特性を知る必要があるからである。本シ
ステムにおけるアプローチはログから確率的なリクエス
ト傾向を求め、それを用いてコンテンツを抽出する。３．４．１ユーザのリクエスト傾向リクエスト傾向（リクエスト特性）を知る手段として、
プロキシサーバのログを解析することが有効である。プ
ロキシサーバは学校や企業などの組織の出入り口に位置
し、ユーザのリクエストを代行する役割を持つ。リクエ
ストの履歴はログとして蓄積されるので、プロキシサー
バのログを解析すれば組織単位でのユーザのリクエスト
傾向がわかる。図１０に示されるように、今回解析した
ログは研究室Ｘ、情報工学科Ｙ、大学Ｚの学生約３００
０人が加入しているＩＳＰの３つである。ただし、図１
０においては、不正アクセスや正規のリクエストでない
ものは除かれている。また、ログの解析においてユーザ
のプライバシーが守られなければならないことはもちろ
んである。

【００６１】３つのプロキシサーバのログ解析結果よ
り、リクエスト数が多いコンテンツは少量しかないこと
がわかった（リクエストが少ないコンテンツの数が多
い）（図１１）。したがって、リクエストの多いコンテ
ンツだけを抽出することによって、ディスクスペース量
や管理コスト、複製に関する処理などを削減することが
できる。

【００６２】図１２〜図１７は、それぞれのログから、
リクエスト回数別にその後リクエストされる確率を表し
たものである。それぞれの図は１０回以上、２０回以
上、３０回以上、４０回以上、５０回以上、１００回以
上リクエストされる確率を図にしたものである。図１２
を見ると、３回リクエストされたコンテンツが１０回以
上リクエストされる可能性は研究室のものが約７０％、
ISPが約６５％、情報工学科が約８２％だということが
わかる。ばらつきがあるが、３つとも同じような対数曲
線を描くことがわかる。このことから、リクエスト回数
が多いほどその後リクエストされる可能性が高いことが
わかり（リクエスト回数が少ないほどその後のリクエス
トされる可能性が低い）（図１１）、ある程度リクエス
トされたコンテンツはその後リクエストされる可能性が
非常に高くなることがわかった。

【００６３】３．４．２期待値３．４．１で、リクエスト回数が多くなるとその後リク
エストされる可能性が高い傾向があると説明した。では
実際にリクエスト回数がどの程度になればコンテンツ抽
出を行うべきなのかを説明する。いくら確率が高くても
得られる利益（キャッシュヒットによってユーザ得られ
る利益）が低ければ意味がない。例えば、図１７の情報
工学科のグラフを見ると、９９回リクエストされたコン
テンツが１００回以上リクエストされる可能性は９９．
７６４４６％であることがわかる。そこで、９９回目の
リクエストで初めてコンテンツをキャッシュしたとす
る。もしリクエストされる回数が１００回ならば１回分
しか利益を得ることしかできない。よって、「その後リ
クエストされる確率が高い」ではなく、「高い利益を得
る確率が高い」という判断によってコンテンツを抽出す
る必要がある。

【００６４】本システムにおいては、「利益を得られる
確率（Ｘ回以上リクエストされる確率）」と「得られる
利益（その後のリクエスト回数）」との積を求め、それ
とＸとの商を期待値とし、それに基づいてコンテンツ抽
出を行うことにする（期待値を求めるときにＸで割らな
くてもよい）。

【００６５】期待値を表したものが図１８〜図２３であ
る。これらの図より、あるリクエスト回数で期待値が極
大値を取ること、どのプロキシサーバかによって極大値
をとるリクエスト回数が異なることがわかる。それぞれ
のプロキシサーバによる違いは、グループ毎のリクエス
ト傾向の違いを表している。本システムは、極大値をグ
ループ毎に求め、これをコンテンツ抽出閾値とする。

【００６６】次に、図２４は、期待値が最大となるリク
エスト回数をグラフにしたものを示す。横軸（Ｘ）は、
図１８〜図２３における目標のリクエスト回数（１０回
から１００回）である。縦軸は、期待値が極大値となる
リクエスト数（コンテンツ抽出閾値）である。横軸のリ
クエスト回数（Ｘ）は、何回リクエストされたものを利
益が高いとするかによって決まる。例えば、１００回以
上リクエストされるコンテンツを利益が高いとすると、
情報工学科ならばリクエスト数１３回でコンテンツを抽
出すればよいことがわかる（コンテンツ抽出閾値＝１３
で、期待値が最大になる）。このように、図２４より、
コンテンツ抽出閾値は変数Ｘによって定まることがわか
る。Ｘは、システム使用者により適宜決定されてよい。

【００６７】図２４における近似曲線の傾きはユーザの
リクエストの幅を表す。これは多数回リクエストされる
コンテンツが多い場合に期待値が最大となるのが早く、
少ない場合は最大となることが遅いことを根拠としてい
る（多数回リクエストされるコンテンツが多いというこ
とは、リクエストが偏っているといえる）。よって、傾
きが大きいほどリクエストの幅が広く、小さいほどリク
エストの幅は狭い。この場合、情報工学科が最もリクエ
ストの幅が狭く、ＩＳＰが最もリクエストの幅が広いこ
とがわかる。したがって、このようなコンテンツ抽出閾
値導出手法を適用することにより、グループのリクエス
ト傾向を反映させた閾値の設定が可能になる。閾値はＣ
Ｓのログを解析することによって求められる。なお、図
２４における「ｘ」は「Ｘ／１０」である。

【００６８】また、上述において、本システムによるコ
ストの最適化とは、「利益の少ないコンテンツに関する
コストを削減しつつ最大限の利益を上げよう」というも
のであり、単なる利益の最大化ではないことに注意が必
要である。

【００６９】３．４．３クラスタリングとコンテンツ
抽出３．４．２ではコンテンツ抽出閾値の導出法を説明した
が、実際の使用方法について述べる。コンテンツ抽出閾
値を、３．３節で説明したユーザクラスタリングによっ
て求めたクラスタリング毎に適用する（図２５）。クラ
スターが組織単位となるので、組織単位でコンテンツ閾
値を求めることができ、コンテンツ抽出の精度を高める
ことができる（組織単位でのリクエスト傾向を反映でき
るので）。また、コンテンツの複製を個人単位やインタ
ーネット全体ではなくクラスター単位で行うことによっ
て、複製回数を抑え、頻繁な複製を防ぐことができる。

【００７０】３．５最適サーバ選択アルゴリズムユーザクラスタリングによって求めたクラスター毎にコ
ンテンツ抽出アルゴリズムを適用し、複製するコンテン
ツと複製先の目標となる場所（クラスター）を導入する
ことができた。しかし、複製を行うためには複製目標の
クラスターに対して最適である複製先ＤＳを発見するこ
とが求められる。そこで最適サーバ探索が求められる。
本システムにおいては、以下に説明するように、最適サ
ーバを目標クラスターから最も近いサーバとし、単純に
ラウンドトリップタイム（以下、ＲＴＴ）の小さいもの
を近いとする。

【００７１】複製を行なうためにはクラスターの最近隣
にある複製先ＤＳ（Distributed Server、以下同じ)を
発見することが望まれる。ＤＮＳサーバを用いて複製先
となるクラスター側から最近隣ＤＳを発見する方法（図
２６）には様々な研究および製品があるが（下川俊彦,
吉田紀彦,牛島和夫. 多様な選択ポリシーを利用可能な
サーバ選択機構, 電子情報通信学会論文誌 Vol.J84-D-I
No.9 2001.9）、これがクラスターから遠隔にあるＤＳ
単独で最近隣ＤＳを探索することになると問題は難解に
なる。なぜなら、クラスターから各ＤＳへの経路を把握
することが、複製元ＤＳでは難しいからである（図２
７）。この解決策としてＩＰルーティングのように各Ｄ
Ｓが協調し合い、クラスターから最近隣ＤＳを探索する
方法（図２８)を挙げることができるが、ＤＳの数が多
くなると協調によるオーバーヘッドが大きくなるのであ
まり好ましくない。違った協調を使用したものとして、
複製元ＤＳと近いＤＳから順に協調し複製する方法があ
る。フローチャートは図３３のようになる。この場合、
協調そのものに対するオーバーヘッドは小さくて済むが
複製が局所的であり、目標となるクラスターから最近隣
のＤＳへコンテンツを複製するために複数回複製を要す
る可能性が高い（図２９〜図３２）。また、こういった
アルゴリズムは複製の終了条件を設定するのが難しい。

【００７２】上記を考慮した上で、本システムは、精度
の低いＤＳ単独で探索する方法を提案し用いる。サーバ
選択における「最適」または「最近隣」の定義に関し
て、ＲＴＴやＴＣＰスループット、サーバ処理能力、回
線使用率など様々な要素を用いた研究が多いが、本シス
テムにおいては単純にＲＴＴを用いる。ユーザクラスタ
ーから最もＲＴＴが小さい（応答速度が速い）ＤＳを最
低サーバとする。

【００７３】３．５．１提案最適サーバ選択方法提案手法はｔｒａｃｅｒｏｕｔｅを基にしている。この
方法は、ネットワークトポロジーが木構造または線形構
造である場合には高精度で最近隣サーバを発見すること
ができるが、リングを含むネットワークである場合には
精度は保証されない。処理の流れを図３４に、イメージ
化したものを図３５〜図３９に示す。ｔｒａｃｅｒｏｕ
ｔｅを、ｗｗｗ．ＸＸＸＸＸ．ｃｏ．ｊｐといったＵＲ
Ｌに対して実行することによって経路情報とＲＴＴが得
られる。

【００７４】３．６システムの実装方法３．３〜３．５節で、コンテンツ複製におけるポリシー
を説明した。本説では、この複製ポリシーをどのように
実装するかを述べる。多様な複製ポリシーを利用可能と
し、システムの柔軟性を上げる意味で、実装は柔軟であ
ることが望ましい。そこで、本システムにおいては複製
ポリシーと複製を実行するモジュールとを分離し、実装
を容易化する。複製ポリシーに基づいて複製戦略をたて
るモジュールを解析モジュール、複製を行なうモジュー
ルを複製モジュールと呼ぶことにする。図４０はこれら
をまとめた階層図である。このような階層をとることに
よって、アプリケーションは複製ポリシーを選択するこ
とが可能となる。

【００７５】３．６．１解析モジュール解析モジュールは複製ポリシーに基づいて複製戦略をた
て、複製モジュールに指令を下す役割を持つ。複製ポリ
シーは選択可能とすることがより好適と考えられる。複
製ポリシーの構成は図４１で示す。複製ポリシーはユー
ザクラスタリングアルゴリズム、コンテンツ抽出アルゴ
リズム、最適ザーバ選択アルゴリズムの３つのアルゴリ
ズムによって構成される。組み合わせは自由とし、アプ
リケーションレベルで組み合わせを決められる機構を作
成することがより好適と考えられる。

【００７６】３．６．２複製モジュール複製モジュールは解析モジュールの指示（どのコンテン
ツをどのＤＳに複製するか）を受け、それに基づいて複
製を行なうモジュールである。複製モジュールには、Ｄ
Ｓ間通信における認証や暗号化などのセキュリティ機能
や、軽量化された通信機能が備えられることが望まれ
る。図４２に複製モジュールの構成図を示す。

【００７７】（Ｐ−ＣＤＮ）ここで、上述にて説明され
るように、本発明者は、コンテンツ配信にかかるコスト
削減を目的としたポリシーを既存ＣＤＮに組み込んだＰ
−ＣＤＮ（Policy based CDN）を提案する。

【００７８】Ｐ−ＣＤＮとは、アプリケーションから多
様なポリシーが選択可能なＣＤＮであり、既存ＣＤＮに
戦略性を持たせることができる。ポリシーとは具体的に
キャッシュサーバ（ＣＤ、上述のＤＳに相当）間におけ
るコンテンツ配置アルゴリズムのことであり、本システ
ムはポリシーに基づいてＣＳ間でコンテンツの複製を行
う。Ｐ−ＣＤＮの特徴は以下の４つ、すなわち、（１）
ポリシーに基づくコンテンツ配置、（２）ポリシーの内
容は条件内で自由、（３）複数のポリシーを組込み可
能、（４）ポリシーの選択は自由である。

【００７９】Ｐ−ＣＤＮでは、既に述べたように、ポリ
シーと複製を実行するモジュールとが分離されることが
有利でる。ポリシーに基づき複製の指令を出す解析モジ
ュールが設けられ、さらに、複製を実行する複製モジュ
ールが設けられる。

【００８０】より詳細には、解析モジュールの役割は２
つある。１つはアプリケーションに対してポリシーの選
択性を提供することである。もう１つは、ポリシーに対
してシステムが組み込まれているＣＳ（ＤＳ）やネット
ワークの状態を提供する役割である。ポリシーに提供さ
れる項目は、（１）ＣＰＵ使用率、（２）メモリ使用
率、（３）コネクション数、（４）データ転送量、
（５）ユーザからのリクエストのログ、（６）外部との
通信用のメッセージ通信機能、である。

【００８１】一方、複製モジュールはポリシーからの指
令を受け、それに基づいて実際にコンテンツを複製する
モジュールである。ポリシーから複製モジュールになさ
れる指令は、以下に示す２つの要素から構成される。す
なわち、（１）コンテンツの名前（ＵＲＬ）および
（２）複製先サーバ名（ＩＰアドレス）である。

【００８２】解析モジュールと複製モジュールとの分離
によって様々なポリシーの開発および実装を簡単化で
き、ポリシーの開発だけに専念できる環境が生まれると
考える。以上、Ｐ−ＣＤＮについて説明した。

【００８３】３．７試作機の構成本章で述べてきた提案システムを実用化するために作成
された、システムを実装した試作機について説明する。
試作機は、ＰＣ／ＡＴ互換機で作成し、システムはＦｒ
ｅｅＢＳＤ上に実装する。システムはキャッシュサーバ
ソフトウェアであるＳｑｕｉｄ（Squid Web Proxy Cach
e）を基にして作成した。Ｓｑｕｉｄにはコンテンツの
キャッシュ機能やキャッシュサーバ間通信機能があるの
で、コーディング作業を大幅に減らすことができる。図
４３は、試作機のシステム構成図を示している。

【００８４】３．７．１解析モジュールの実装解析モジュールには、Ｓｑｕｉｄのアクセスログを解析
する機能と、最適サーバ探索機能を持たせる。図４４お
よび図４５は、解析モジュールの動作を示している。

【００８５】図４４および図４５について説明すると、
（１）Ｓｑｕｉｄのアクセスログを用いてユーザクラス
タリングを行なう。ログはクラスター毎に分割される。
クラスタリングに用いるＢＧＰルーティングテーブルは
前もってダウンロードしておく。（２）ログ毎にリクエ
スト傾向を求める。リクエスト傾向によって抽出閾値を
導出する。（３）閾値以上のリクエスト回数のコンテン
ツを抽出し、ＵＲＬを抜き出す。（４）クラスターから
最も近いＤＳを探索し、ＤＳのＩＰアドレスを求める。
（５）ＵＲＬとＤＳのＩＰアドレスを複製モジュールへ
渡す。

【００８６】３．７．２複製モジュールの実装本来なら解析モジュールのように複製モジュールも単体
で動作するように実装することが望ましいと考えられ
る。しかし、今回は、複製モジュールをプロキシサーバ
ソフトウエアのＳｑｕｉｄに組込んで実装を行なった。

【００８７】複製モジュールは解析モジュールが作成し
た複製先ＤＳリストを利用して、コンテンツの複製を行
なうモジュールである。複製モジュールは複製先ＤＳリ
ストを定期的にチェックしており、リストに変更があれ
ばリストから複製先ＤＳアドレスと複製するコンテンツ
を取得して複製動作を行なう。ＤＳ間のネゴシエーショ
ンは図４６のような内容になっている。Connection mes
sageはＤＳ間で複製を行なうための情報の通信を行い、
Request Messageはコンテンツ複製を実際に開始するた
めの通信に利用する。Connection messageには各種メソ
ッドが含まれており、メッセージを受信したＤＳがメソ
ッドに合わせた処理を行なうようになっている。Connec
tion 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_MOV
E」メッセージを送信する。このメッセージには複製す
るコンテンツのアドレスが含まれている。また、「ICP_
NEGO_N」メッセージを受け取った場合は協調動作を中止
する。「ICP_MOVE」を受け取った複製先ＤＳはRequest
messageを複製元ＤＳに送信し、それを受けた複製元Ｄ
Ｓはコンテンツデータの送信は開始するようになってい
る。

【００８８】４実験と評価本提案システムを検証するために、解析モジュールと複
製モジュールをインストールした試作機によって検証実
験を行った。本章では、その実験環境と実験結果につい
て述べる。

【００８９】４．１実験環境４．１．１ネットワーク構成図４７に今回の実験環境のネットワーク構成を示す。ル
ータマシン、試作機マシン(ＤＳ)、クライアントマシン
はいずれも一般的なマシン(ＩＢＭＰＣ／ＡＴ互換機)
を使用した。ルータマシンＩにはＯＳとしてＦｒｅｅＢ
ＳＤ５．０を、ルータマシンＩＩ、ＩＩＩ、ＩＶはＦｒ
ｅｅＢＳＤ４．２をインストールした。それぞれのルー
タマシンにはＮＩＣ(Network Interface Card)が複数枚
装着してあり、複数のネットワークとのゲートウェイと
して動作している。試作機マシンのＯＳにはＦｒｅｅＢ
ＳＤ４．２、クライアントマシンにはＷｉｎｄｏｗｓＭ
Ｅ（登録商標）とＷｉｎｄｏｗｓ２０００（登録商標）
をインストールした。試作機マシン、クライアントマシ
ンにはＮＩＣが１枚装着してある。各端末間の接続速度
はすべて１００ｂａｓｅＴＸで接続されている。試作機
マシンにはアクセスログの解析を行うための解析モジュ
ールとコンテンツ複製を行うための複製モジュールが実
装されている。各マシンスペックは図４８に示すとおり
である。マシンスペックには個体差があるが、これはＣ
ＰＵ処理速度を故意に下げることにより、ＣＰＵの処理
能力が解析処理やパケット転送処理のボトルネックとな
るような環境を作っている。試作機Ａと試作機Ｂとを差
別化するため、試作機ＡのＮＩＣは意図的に性能の低い
ものにしてある。

【００９０】４．１．２実験環境詳細実験開始段階では試作機Ａにだけコンテンツをキャッシ
ュしてある状態にしてある。その他の試作機はコンテン
ツを何も持っておらず、クライアントからのアクセスが
こない状態になっている。試作機Ａは一定時間間隔でア
クセスログを解析し、最適なコンテンツ配置先を選択す
るプログラムが動作している。また、それぞれの試作機
マシン上では複製モジュールが動作しており、協調を行
うためのメッセージのやり取りができるようになってい
る。

【００９１】実験では図４９のように、各クライアント
から試作機Ａへリクエスト要求を複数回送っている。実
験ではクライアントマシンからのアクセス要求をクライ
アントグループからのアクセスと見立てて、解析モジュ
ールでクラスタリングを行うようになっている。アクセ
ス回数はクライアントαよりクライアントβが多く要求
を出すパターンと少なく出すパターンで行った。取得す
るデータはコンテンツ複製前とコンテンツ複製後で試作
機からクライアントマシンへのＨＴＴＰレスポンスタイ
ム等のデータを取り、提案システムや解析モジュールの
有効性をデータとして示す。

【００９２】今回の実験は、複製ポリシーとして設定し
てある一連のアルゴリズムに基づいてコンテンツ複製が
行われるかを検証するためのものなので、ユーザクラス
タリングアルゴリズムとコンテンツ抽出アルゴリズムは
単純化してある。

【００９３】実験環境で使用されるマシンに割り振られ
るＩＰアドレスがプライベートＩＰアドレスなので、外
部のＢＧＰルーティングテーブルを用いたクラスタリン
グが行えない。よって、クラスタリングはプレフィック
スを２４ｂｉｔ固定として行う。

【００９４】３．４節で説明したコンテンツ抽出アルゴ
リズムは、ログが充分に蓄積された状態でなければアル
ゴリズムの精度が保証されない。そのため、ログの蓄積
数が少ない場合は予め固定の閾値を設定しておき、その
閾値を用いてコンテンツ抽出を行う。今回は、１０回を
閾値として設定した。コンテンツ抽出アルゴリズムは、
ログ数が例えば１０００行以上になった時に初めて動作
するように構成される。

【００９５】４．２実験結果４．１．２節の実験環境での検証では図５０に示すデー
タを得ることができた。今回の検証では複製閾値を１０
回としているので、アクセス回数が１０回を超えたとこ
ろからグラフに変化が現れている。図５０に示すアクセ
ス時間はクライアントβからコンテンツにアクセス要求
を出してから、コンテンツデータの先頭がクライアント
に届くまでの時間である。実験開始直後はクライアント
のアクセス要求はすべて試作機Ａへ送られる。アクセス
解析によりコンテンツの複製が起こった後は、クライア
ントβからのアクセスはレスポンスのよい試作機へ送ら
れるようになる。図５０のグラフのからもわかるよう
に、クライアントβから試作機Ａまでのレスポンスタイ
ムと、コンテンツ複製が起こり複製先の試作機へアクセ
ス要求を送ったレスポンスタイムでは複製先試作機にア
クセスしたほうがレスポンスタイムが短いことがわか
る。今回の検証でのコンテンツの複製された動作は、ク
ライアントα、βからのアクセスを試作機Aが解析しア
クセスの多いクライアントβに近いところにコンテンツ
を複製しようとしコンテンツの複製を行った。図５１の
ように解析モジュールが最適サーバを選択し、試作機Ｃ
が最適だと判断しコンテンツを複製し、コンテンツ複製
後からは図５２のようにクライアントβは試作機Ｃにア
クセスするようになるために、レスポンスタイムが短く
なっているのである。図に示してはないが、クライアン
トαのリクエスト数がクライアントβより多い場合でも
同じように、レスポンスタイムが短くなっている。これ
は試作機Ａより試作機ＢのほうがＣＰＵ能力がよいの
で、コンテンツが試作機Ｂへ複製され、クライアントα
のアクセス要求も試作機Ｂに送られるようになったため
である。

【００９６】４．３評価図５０に示されるように実験結果から提案システムの有
効性を示すことができた。図５０よりコンテンツ複製前
よりコンテンツ複製後のほうがクライアントへのレスポ
ンスが向上していることがわかる。これは、複製前のサ
ーバより解析モジュールによって選ばれた複製後のサー
バのほうがクライアントに近いからということが言え
る。このことから、解析モジュールの最適サーバを選択
するアルゴリズムが有効だといえる。提案システムでは
自律的にクラスター毎のアクセス傾向を解析し、クラス
タリングされたクライアントグループの近くにアクセス
の多いコンテンツを自動的に配置することができる。ク
ライアントグループごとにアクセスの多いコンテンツを
近くのサーバに複製することによって、オリジンサーバ
までコンテンツをアクセスしに行かなくても済むので、
レスポンスタイムが短くなる。また、コンテンツが複数
配置されることになるので、オリジンサーバの負荷分散
やトラヒックの軽減を行うことができる。また、この提
案システムはフリーソフトとして配布されてもよい。Ｃ
ＤＮプラットフォームを誰もが利用することができ、Ｃ
ＤＮを用いたアプリケーションの開発を促進することが
できると考えられる。

【００９７】（評価項目と確認）ここで、評価項目とそ
の達成の確認を行う。評価項目として、（１）閾値によ
って複製が行えるか、（２）（１）がクラスター毎に行
えるか、（３）最適サーバが探索されているか、を挙げ
る。

【００９８】図５３は、図５０と同様の図である。図５
３より、閾値による複製によってクライアントβに対す
る応答速度が向上しているのがわかる。これは、閾値を
境にクライアントβに最も近い試作機Ｃにコンテンツが
複製され、クライアントβのリクエストが試作機Cに対
して行われるようになるからである。これで評価項目
（１）と（２）が満足された。

【００９９】また、図５４は、ルータＩＶと試作機Ｃを
一定時間高負荷状態にした時のクライアントβに対する
応答速度の変化を表したものである。試作機Ｃが高負荷
状態であるために、まず試作機Ｂにコンテンツが複製さ
れ、その後試作機Ｃに複製されているのがわかる。この
実験によって評価項目（３）も満足された。

【０１００】５．以上に説明したように、ユーザクラス
タリング機構を用いたコンテンツ自動配信システム、Ｐ
−ＣＤＮの提案を行った。ユーザクラスタリング機構を
用いることによって、ユーザをクラスターに分割するこ
とができ、それぞれのクラスターに特化したコンテンツ
配置戦略をたてることができることを説明した。本シス
テムを実装した試作機による検証実験では、複製ポリシ
ーに基づいて動作することが確認された。複製ポリシー
のコンテンツ抽出アルゴリズムによりコンテンツ抽出、
複製が適切に行われた。

【０１０１】「キャッシュサーバ」次に、上述の技術が
適用されたキャッシュサーバを含むシステムの実施形態
を説明する。キャッシュサーバは上述のディストリビュ
ーションサーバ（ＤＳ）に対応する。この実施形態に
は、主として、上述した技術のうちの、期待値に基づく
コンテンツ抽出アルゴリズムが適用されている。

【０１０２】図５５は、キャッシュサーバを含むＣＤＮ
の構成図である。コンテンツプロバイダはコンテンツを
ユーザに提供するサーバである。コンテンツレシーバは
インターネットを介してコンテンツプロバイダが提供す
るコンテンツを受信して利用するユーザの端末である。
インターネットには複数のネットワークノードが含ま
れ、コンテンツプロバイダからコンテンツレシーバへ提
供されるコンテンツのデータを中継するルータとして機
能する。

【０１０３】図５５において、ユーザグループ１０は、
例えば、ある大学に属する複数のコンテンツレシーバを
含む。ネットワークノード１２は、ユーザグループ１０
の近傍に位置している。そして、ネットワークノード１
２には、本実施形態のキャッシュサーバ１４が一体的に
設けられている。キャッシュサーバ１４は、ユーザグル
ープ１０のために、コンテンツプロバイダから提供され
るコンテンツをキャッシュメモリに格納し、これにより
キャッシングが行われる。なお、図示されないが、キャ
ッシュサーバは他のネットワークノードにも設けられて
いてよいことはもちろんである。

【０１０４】図５６は、キャッシュサーバ１４の構成を
示している。キャッシュサーバ１４は、第１通信部２０
および第２通信部２２を有する。第１通信部２０はネッ
トワークと通信し、第２通信部２２はローカル側（ユー
ザグループ）と通信する。第１通信部２０および第２通
信部２２は、ハードウエア構成としては同一でよい。

【０１０５】キャッシュメモリ２４は、キャッシュメモ
リ制御部２６の制御の下で、キャッシングのためにコン
テンツを格納する。すなわち、コンテンツがキャッシュ
メモリ２４に複写され、これによりキャッシングが行わ
れる。キャッシュメモリ制御部２６は本発明のキャッシ
ュ制御部として機能する。

【０１０６】リクエスト回数カウンタ２８は、ユーザグ
ループ１０によるリクエストの情報を入手して、コンテ
ンツのリクエスト回数を計測する。各々のコンテンツの
リクエスト回数がカウントされる。カウント値は図示の
ようなテーブルに書き込まれる。このようにして、ユー
ザグループ１０によるコンテンツのリクエスト回数とそ
の増大が監視される。

【０１０７】許可カウントテーブル３０は、目標カウン
トと許可カウントを対応づけるテーブルである。目標カ
ウントは、本発明の目標リクエスト回数に相当し、３．
４．２節で説明した図２４の横軸に相当する。許可カウ
ントは、図２４の縦軸に相当し、期待値が最大になると
きのリクエスト回数である。

【０１０８】既に説明したように、期待値は、目標リク
エスト達成確率と残リクエスト回数の積で表される。目
標リクエスト回数達成確率は、リクエスト回数ｎから目
標リクエスト回数（目標カウント）Ｘに到達する確率で
あり、残リクエスト回数は、リクエスト回数ｎから目標
リクエスト回数（目標カウント）Ｘまでの残リのクエス
ト数、すなわち、Ｘ−ｎである。

【０１０９】本実施形態では、予め、ユーザグループ１
０のリクエストのログが、適当な期間に渡って解析され
る。例えば、２ヶ月間のログが解析される。この解析結
果に基づき、期待値の情報が求められる。そして、図２
４のテーブルのデータがキャッシュサーバに予め入力さ
れ、保持されている。

【０１１０】また、図２４を参照して既に述べたよう
に、リクエスト特性、特にリクエストの幅（バリエーシ
ョン）がユーザグループによって異なる。そして、期待
値を最大にするリクエスト回数もユーザグループによっ
て異なる。この点に関して、本実施形態の許可カウント
テーブル３０は、対象のグループの解析結果から得られ
たデータ、すなわち対象のグループの特性を反映するデ
ータを保持している。

【０１１１】図５６に戻り、指定ＵＩ（ユーザインター
フェース）３２は、キーボード等のデバイスを用いて入
力された目標カウントを受け付ける。目標カウントはキ
ャッシュメモリ制御部２６により取得される。キャッシ
ュメモリ制御部２６は、許可カウントテーブル３０を参
照し、目標カウントに対応する許可カウントを求める。
この許可カウントは、キャッシュメモリ制御部２６によ
り保持され、コンテンツ抽出閾値として、すなわちキャ
ッシュ条件として、キャッシングの制御に用いられる。
すなわち、以下に説明するように、あるコンテンツのリ
クエスト回数が許可カウントに達したとき、キャッシュ
条件が成立し、コンテンツのキャッシュが許可され、キ
ャッシングが行われる。

【０１１２】次に、図５６のキャッシュサーバ１４によ
るキャッシングの動作を説明する。上述のように、リク
エスト回数カウンタ２８は、ユーザグループ１０による
コンテンツのリクエスト回数を計測する。例えば、ユー
ザグループ１０を構成する一の端末からＵＲＬ１という
コンテンツが初めてリクエストされたとき、ＵＲＬ１の
カウント値として１がテーブルに記録される。その後、
ユーザグループ１０の端末からＵＲＬ１がリクエストさ
れるたびに、テーブル中のカウントが１ずつ増やされ
る。

【０１１３】キャッシュメモリ制御部２６は、ユーザグ
ループ１０の端末からコンテンツがリクエストされたと
き、リクエスト回数カウンタ２８のテーブルを参照す
る。そして、キャッシュメモリ制御部２６は、今回のリ
クエストによって、コンテンツのリクエスト回数が許可
カウントに達したか否かを判定する。上述したように、
許可カウントは許可カウントテーブル３０を参照するこ
とによって得られる。そして、キャッシュメモリ制御部
２６は、リクエスト回数が許可カウントに達した場合、
コンテンツデータをキャッシュメモリ２４に格納するこ
とで、コンテンツをキャッシングする。

【０１１４】例えば、上述のＵＲＬ１がリクエストされ
たとき、この情報がキャッシュメモリ制御部２６に取得
される。キャッシュメモリ制御部２６は、現在のＵＲＬ
１のカウント値を、リクエスト回数カウンタ２８から求
める。そして、キャッシュメモリ制御部２６は、今回の
リクエストにより、リクエスト回数が許可カウントに達
するか否かを判定する。すでに許可カウントから１を引
いた値までリクエスト回数が到達している場合、今回の
リクエストにより、リクエスト回数が許可カウントに到
達する。そこで、キャッシュメモリ制御部２６は、リク
エストされたコンテンツデータをキャッシュメモリに格
納する。キャッシュサーバを通過するときにコンテンツ
データがキャッシュメモリに格納される。

【０１１５】以上のようにして、本実施形態は、コンテ
ンツのリクエスト回数の増大を監視して、リクエスト回
数が許可カウント（コンテンツ抽出閾値）まで増大する
ことによりキャッシュ条件が満たされるのを待ってから
コンテンツをキャッシュサーバにキャッシングさせる。
したがって、コンテンツの増大が見込める適当なコンテ
ンツをキャッシングできる。１度だけしかリクエストさ
れないようなコンテンツの無駄なキャッシングが回避さ
れ、コストを削減できる。

【０１１６】また、本実施形態は、リクエスト特性に基
づいた適切なキャッシング制御を行っている。特に、本
実施形態は、上述のように、リクエスト増大の期待値に
基づいたコンテンツ抽出閾値（許可カウント）を用いて
おり、これにより好適な制御が行われる。

【０１１７】すなわち、コンテンツ抽出閾値を大きく設
定すると、その後のリクエストの確率は高いものの、リ
クエスト回数自体が少なくなり、キャッシングの効果が
少なくなる。一方、コンテンツ抽出閾値を小さくしすぎ
ると、リクエスト回数が伸びないコンテンツを無駄にキ
ャッシングする可能性が高くなる。このような点を考慮
した上で、本実施形態は、期待値に基づきコンテンツ抽
出閾値を設定している。その結果、リクエスト回数の増
大が見込めるコンテンツを早めの適切なタイミングでキ
ャッシングすることができ、コスト削減が図れる。

【０１１８】なお、本実施形態では、キャッシュサーバ
１４はネットワークノード１２と一体化されていた（図
５５）。しかし、本発明はこれに限定されない。キャッ
シュサーバ１４はネットワークノード１２の外側に付属
してもよい。

【０１１９】また、図５５には示されないが、他のユー
ザグループについても同様に本発明のキャッシュ制御技
術が適用されてよいことはもちろんである。このとき、
一つのキャッシュサーバが複数のユーザに対応してもよ
い。

【０１２０】また、本実施形態では、図５５に示される
ように、ユーザグループに近いキャッシュサーバがコン
テンツをキャッシングしている。これに対し、アクセス
時間が多少長くなるものの、本発明の範囲内で、ユーザ
グループからより遠くのキャッシュサーバが用いられて
もよい。

【０１２１】また、本実施形態では、すべてのコンテン
ツに関して、目標カウントおよび許可カウントが一定で
あった。これに対し、コンテンツの種類が判別可能なと
き、目標カウントおよび許可カウントをコンテンツに応
じて異ならせる制御が行われてもよい。例えば、コンテ
ンツのジャンルに応じた制御を行うことが好適と考えら
れる。

【０１２２】また、キャッシュサーバ１４の指定ＵＩ３
２は、目標カウントを入手した。そして、キャッシュサ
ーバ１４内で、許可カウントテーブル３０を参照して、
許可カウントが求められた。これに対し、指定ＵＩ３２
は、許可カウントを入手してもよい。すなわち、オペレ
ータによりキーボード等を用いて許可カウントが入力さ
れる。このとき、許可カウントテーブル３０は削除され
てもよい。

【０１２３】また、キャッシュサーバ１４は、本発明の
キャッシュ制御のためのプログラムをコンピュータにイ
ンストールすることにより実現されている。さらに、こ
のプログラムは、通信でキャッシュサーバ１４に入手さ
れてもよく、ＣＤ−ＲＯＭ等の記録媒体からキャッシュ
サーバ１４に入手されてもよい。そして、キャッシュサ
ーバ１４は、本発明のキャッシュシステムとして機能す
る。さらに、キャッシュサーバ１４は、本発明のキャッ
シュ制御装置の機能を実現し、すなわちキャッシュ制御
装置を備えている。これらの点は、下記の実施形態にお
いても同様である。

【０１２４】また、本発明は、主として、コンテンツを
キャッシュメモリに格納する部分に特徴をもつので、上
述の説明では、格納されたコンテンツを活用する部分の
説明は省略されている。しかし、この点に関しては、従
来同様の処理が行われてよい。すなわち、格納済み（キ
ャッシング済み）のコンテンツがユーザグループ１０の
端末からリクエストされときは、キャッシュメモリ２６
の制御の下で、キャッシュメモリ２４からコンテンツが
読み出され、提供される。これによりアクセス時間が短
縮される。その他、既に格納されたコンテンツは、ＬＦ
Ｕ（Least Frequently Used）方式またはＬＲＵ（Least
Recent Used）方式等の適当な方法でキャッシュバッフ
ァから追い出される。

【０１２５】次に、図５７は、本発明の別の実施形態に
おけるキャッシュサーバ１４０を示している。キャッシ
ュサーバ１４０は、上述した構成に加えて、リクエスト
履歴を解析する機能を備える。

【０１２６】図５７において、リクエスト履歴情報取得
部４０は、コンテンツのリクエスト履歴の情報を取得す
る。リクエスト履歴情報は、キャッシュサーバ１４０自
身により、リクエストを監視することにより取得されて
もよい。また、リクエスト履歴情報は外部から通信等で
入手されてもよい。例えば、前述したように、ユーザグ
ループのプロキシサーバでのアクセスログが、履歴情報
として有用である。

【０１２７】キャッシュサーバ１４０はさらに解析部４
２を有する。解析部４２は、リクエスト履歴の情報を取
得する。解析部４２は、既に説明したコンテンツ抽出ア
ルゴリズムに従った処理を行う。すなわち、期待値算出
部４４が、目標リクエスト回数の達成確率を求め（図１
２〜図１７）、期待値を求める（図１８〜図２３）。そ
して、期待値に基づき、許可カウントテーブル３０が作
成される。既に説明したように、許可カウントテーブル
は、図２４のグラフに相当するデータをもち、目標カウ
ント（目標リクエスト回数）と、最大の期待値を与える
リクエストの関係求める。

【０１２８】さらに、解析部４２において、許可カウン
ト決定部４６は、指定ＵＩ３２を介して、目標カウント
の指定値を取得する。この指定値に対応する許可カウン
トが求められる。許可カウントはキャッシュメモリ制御
部２６に伝えられ、キャッシング制御に使われる。

【０１２９】図５７のキャッシュサーバ１４０のキャッ
シング動作を説明する。初期段階では、期待値および許
可カウントを求められるだけの十分な量のリクエスト履
歴が得られていない。そこで、キャッシュメモリ制御部
２６は、デフォルト値の許可カウントを用いる。

【０１３０】デフォルト値の許可カウントは、複数種類
でもよい。そして、ユーザグループの種類に対応するデ
フォルト値が選択されてもよい。例えば、研究室、学
部、大学といったグループの規模または他の性質に応じ
て異なるデフォルト値が設定される。好ましくは、グル
ープ規模等に応じた適当な許可カウントが、予め統計的
に求められ、使用される。この許可カウントは、図２４
を用いて説明したグループ間のリクエスト幅の相違を反
映しており、好適である。

【０１３１】リクエスト履歴情報が十分な量に達したか
否かは、例えば、履歴情報の集積期間に基づき判断され
る。例えば２ヶ月が経過したとき、十分な履歴情報が得
られたと判断される。また例えば、リクエスト総数が適
当な値に達したとき、リクエスト履歴情報が十分である
と判断されてもよい。

【０１３２】リクエスト履歴情報が集まると、解析部４
２が、履歴情報を解析し、許可カウントテーブルを求め
る。さらに、解析部４２は、指定された目標カウントに
対応する許可カウントを求める。この解析部４２は、許
可カウントをキャッシュメモリ制御部２６に伝える。以
降、キャッシュメモリ制御部２６は、解析部４２から伝
えられた許可カウントをキャッシング制御に使う。な
お、解析部４２の一部または全部の構成がキャッシュメ
モリ制御部２６に設けられてもよい。

【０１３３】さらに好ましくは、図５７のキャッシュサ
ーバ１４０は、リクエスト履歴のさらなる追跡調査を行
う。すなわち、リクエスト履歴から許可カウントが求め
られた後も、引き続き、リクエスト履歴情報が収集され
る。解析部４２は、引き続き得られるリクエスト履歴情
報を解析して、期待値を求め、許可カウントを求める。
この処理は、上述の初めて許可カウントを求める処理と
同様でよい。新たに求められた許可カウントがキャッシ
ュメモリ制御部２６に伝えられる。このようにして、本
実施形態によれば、許可カウントの値を調整することが
できる。

【０１３４】なお、許可カウントの調整には、前回に許
可カウントを求めた後の履歴情報のみが用いられてもよ
い。それ以前の履歴も含めた長期間の情報が用いられて
もよい。

【０１３５】上記の調整処理によれば、グループの変化
に応じて、例えば、グループの規模や年齢層の変化に応
じて、キャッシュ条件（許可カウント）を好適に調整す
ることができる。また、季節等の環境の変化に合わせた
キャッシュ条件の調整も可能となる。このようにして、
より一層のコスト削減効果を得ることが期待できる。

【０１３６】以上、本発明の好適な実施形態を説明し
た。なお、本実施形態では、本発明を実現するための主
要な機能が、主に単独のキャッシュサーバに設けられ
た。しかし、本発明を実現可能な範囲で、それら機能が
ネットワークに分散して設けられてもよいことはもちろ
んである。例えば、一部または全部の機能が、コンテン
ツプロバイダに設けられてもよく、また、コンテンツレ
シーバ側に設けられてもよい。

【０１３７】また、本実施形態では、本発明が、予め決
まったユーザグループおよびキャッシュサーバに対して
適用されていた。そして、これにより、システムが簡略
化されている。しかし、本発明の範囲内で、より自動化
の進んだシステムが採用されてもよい。

【０１３８】典型的には、まず、前出のクラスタリング
分析アルゴリズム（３．３節）が組み込まれる。そし
て、ユーザグループ（クラスタリング）が自動的に求め
られる。求められたクラスタリングのリクエスト特性が
分析され、キャッシュ条件に基づくキャッシング制御が
行われる。

【０１３９】また、最適サーバ選択アルゴリズム（３．
５節）が組み込まれてもよい。最適サーバ選択アルゴリ
ズムにより、ユーザグループの近傍のキャッシュサーバ
が検出される。検出されたキャッシュサーバにて、上述
した本実施形態のキャッシング制御が行われる。コンテ
ンツデータは、検出されたキャッシュサーバに複製され
る。

【０１４０】上述のクラスタ分析機能および最適サーバ
選択機能についても、コンテンツ抽出機能と同様、局所
的に設けられてもよく、分散して設けられてもよい。例
えば、コンテンツプロバイダが、クラスタ分析機能と最
適サーバ選択機能をもち、（１）ユーザグループおよび
その近傍のサーバを見つけ、（２）ユーザグループのリ
クエスト特性を解析し、そして、（３）上述のキャッシ
ング制御として、キャッシュサーバへの複製の指示を行
ってもよい。

【０１４１】以上、本発明を実施の形態をもとに説明し
た。これらの実施の形態は例示であり、それらの各構成
要素や各処理プロセスの組合せにいろいろな変形例が可
能なこと、またそうした変形例も本発明の範囲にあるこ
とは当業者に理解されるところである。

【０１４２】

【発明の効果】以上に説明したように、本発明によれ
ば、無駄なキャッシングを削減し、リクエスト回数増大
が見込めるコンテンツを適切にキャッシングし、コンテ
ンツ配信ネットワークにおけるコスト削減を図ることが
できる。

【図面の簡単な説明】

【図１】コンテンツ自動配信システムの構築に関する
提案システムを示す図である。

【図２】コンテンツ自動配信システムの構築に関する
提案システムを示す図である。

【図３】プロキシサーバのアクセスログを解析した結
果を示す図である。

【図４】プロキシサーバのアクセスログを解析した結
果を示す図である。

【図５】プロキシサーバのアクセスログを解析した結
果を示す図である。

【図６】プロキシサーバのアクセスログを解析した結
果を示す図である。

【図７】プロキシサーバのアクセスログを解析した結
果を示す図である。

【図８】プロキシサーバのアクセスログを解析した結
果を示す図である。

【図９】適当なクラスタリングの手順を示す図であ
る。

【図１０】リクエスト傾向を求めるためにログを取得
したプロキシサーバを示す図である。

【図１１】ログ解析結果の概要を示す図である。

【図１２】リクエスト回数別にその後リクエストされ
る確率を表した図である。

【図１３】リクエスト回数別にその後リクエストされ
る確率を表した図である。

【図１４】リクエスト回数別にその後リクエストされ
る確率を表した図である。

【図１５】リクエスト回数別にその後リクエストされ
る確率を表した図である。

【図１６】リクエスト回数別にその後リクエストされ
る確率を表した図である。

【図１７】リクエスト回数別にその後リクエストされ
る確率を表した図である。

【図１８】リクエスト回数と期待値の関係を示す図で
ある。

【図１９】リクエスト回数と期待値の関係を示す図で
ある。

【図２０】リクエスト回数と期待値の関係を示す図で
ある。

【図２１】リクエスト回数と期待値の関係を示す図で
ある。

【図２２】リクエスト回数と期待値の関係を示す図で
ある。

【図２３】リクエスト回数と期待値の関係を示す図で
ある。

【図２４】期待値が最大となるリクエスト回数を示す
図である。

【図２５】クラスタリング毎のコンテンツ抽出閾値の
適用を示す図である。

【図２６】最適サーバ選択アルゴリズムを説明するた
めの図である。

【図２７】最適サーバ選択アルゴリズムを説明するた
めの図である。

【図２８】最適サーバ選択アルゴリズムを説明するた
めの図である。

【図２９】最適サーバ選択アルゴリズムを説明するた
めの図である。

【図３０】最適サーバ選択アルゴリズムを説明するた
めの図である。

【図３１】最適サーバ選択アルゴリズムを説明するた
めの図である。

【図３２】最適サーバ選択アルゴリズムを説明するた
めの図である。

【図３３】最適サーバ選択アルゴリズムを説明するた
めの図である。

【図３４】最適サーバ選択のための処理の流れを示す
図である。

【図３５】図３４の処理のイメージを示す図である。

【図３６】図３４の処理のイメージを示す図である。

【図３７】図３４の処理のイメージを示す図である。

【図３８】図３４の処理のイメージを示す図である。

【図３９】図３４の処理のイメージを示す図である。

【図４０】解析モジュールと複製モジュールで構成さ
れるシステムの概念を示す図である。

【図４１】複製ポリシーの構成を示す図である。

【図４２】複製モジュールの構成を示す図である。

【図４３】提案システムの試作機の構成を示す図であ
る。

【図４４】解析モジュールの動作を示す図である。

【図４５】解析モジュールの動作を示す図である。

【図４６】提案システムにおけるサーバ間のネゴシエ
ーションを示す図である。

【図４７】提案システムの実験環境のネットワーク構
成を示す図である。

【図４８】試作システムのマシンスペックを示す図で
ある。

【図４９】試作システムの実験におけるリクエスト要
求を示す図である。

【図５０】試作機の実験データを示す図である。

【図５１】実験におけるコンテンツの複製を示す図で
ある。

【図５２】実験におけるコンテンツ複製後のアクセス
を示す図である。

【図５３】実験結果を示す図である。

【図５４】実験結果を示す図である。

【図５５】本発明の好適な実施形態における、キャッ
シュサーバを含むコンテンツ配信システムの全体構成を
示す図である。

【図５６】図５５のシステムに設けられたキャッシュ
サーバの構成を示す図である。

【図５７】リクエスト履歴の解析機能を備えた別の実
施形態におけるキャッシュサーバの構成を示す図であ
る。

【符号の説明】

１０ユーザグループ１２ネットワークノード１４キャッシュサーバ２４キャッシュメモリ２６キャッシュメモリ制御部２８リクエスト回数カウンタ３０許可カウントテーブル４０リクエスト履歴情報取得部４２解析部４４期待値算出部４６許可カウント決定部

Claims

【特許請求の範囲】

【請求項１】コンテンツ配信ネットワーク上のキャッ
シュサーバによるコンテンツのキャッシングの制御方法
であって、コンテンツのリクエスト回数の増大を監視し、リクエス
ト回数が増大することにより所定のキャッシュ条件が満
たされるのを待ってから前記コンテンツをキャッシュサ
ーバにキャッシングさせることを特徴とするキャッシュ
制御方法。
【請求項２】前記キャッシュ条件は、リクエスト回数
が多いほどその後のリクエストの可能性が大きいリクエ
スト特性に基づき設定されることを特徴とする請求項１
に記載のキャッシュ制御方法。
【請求項３】前記キャッシュ条件は、リクエスト回数
とその後の目標リクエスト回数達成確率との関係に基づ
き設定されることを特徴とする請求項２に記載のキャッ
シュ制御方法。
【請求項４】前記キャッシュ条件は、前記目標リクエ
スト回数達成確率から得られるリクエスト増大量の期待
値に基づき設定されることを特徴とする請求項３に記載
のキャッシュ制御方法。
【請求項５】前記期待値が最大になるときのリクエス
ト回数を、前記キャッシュ条件としてのコンテンツ抽出
閾値に設定し、コンテンツのリクエスト回数が前記コン
テンツ抽出閾値まで増大したときに前記コンテンツを前
記キャッシュサーバにキャッシングさせることを特徴と
する請求項４に記載のキャッシュ制御方法。
【請求項６】ユーザグループによって前記リクエスト
特性が異なることに基づき、キャッシュ条件をユーザグ
ループに応じて設定することを特徴とする請求項２〜５
のいずれかに記載のキャッシュ制御方法。
【請求項７】コンテンツ配信ネットワーク上のキャッ
シュサーバによるコンテンツのキャッシュの制御方法で
あって、ユーザグループによるコンテンツリクエスト履歴情報を
取得するステップと、前記コンテンツリクエスト履歴情報に基づき、リクエス
ト回数とその後の目標リクエスト回数達成確率との関係
を求めるステップと、前記目標リクエスト回数未満のリクエスト回数を対象と
して、前記目標リクエスト回数達成確率と前記目標リク
エスト回数までの残リクエスト回数の積で表されるリク
エスト増大量の期待値を求めるステップと、前記期待値が最大になるときのリクエスト回数をコンテ
ンツ抽出閾値に設定するステップと、前記ユーザグループによるコンテンツのリクエスト回数
を監視し、あるコンテンツのリクエスト回数が前記コン
テンツ抽出閾値まで増大したときに前記コンテンツをキ
ャッシュサーバにキャッシングさせるキャッシュ制御を
行うステップと、を含むことを特徴とするキャッシュ制御方法。
【請求項８】ユーザグループによるコンテンツリクエ
スト履歴情報を取得するステップと、前記コンテンツリクエスト履歴情報に基づき、リクエス
ト回数とその後の目標リクエスト回数の達成確率との関
係を求めるステップと、前記目標リクエスト回数未満のリクエスト回数を対象と
して、前記目標リクエスト回数達成確率と前記目標リク
エスト回数までの残リクエスト回数の積で表されるリク
エスト増大量の期待値を求めるステップと、を含むことを特徴とするコンテンツリクエスト増大量の
予測方法。
【請求項９】コンテンツ配信ネットワーク上で提供さ
れるコンテンツをキャッシュデータとして記憶するキャ
ッシュメモリと、ユーザグループによるコンテンツのリクエスト回数をカ
ウントするリクエスト回数カウンタと、前記リクエスト回数カウンタによりカウントされたリク
エスト回数が所定のコンテンツ抽出閾値に達したときに
前記コンテンツを前記キャッシュメモリにキャッシング
させるキャッシュ制御部と、を含むことを特徴とするキャッシュシステム。
【請求項１０】前記ユーザグループによるコンテンツ
リクエスト履歴情報を解析することにより前記コンテン
ツ抽出閾値を求める解析部を含むことを特徴とする請求
項９に記載のキャッシュシステム。
【請求項１１】前記解析部は、前記コンテンツリクエ
スト履歴情報から得られるリクエスト増大の期待値が最
大になるときのリクエスト回数を前記コンテンツ抽出閾
値として求めることを特徴とする請求項１０に記載のキ
ャッシュシステム。
【請求項１２】コンテンツ配信ネットワークを介して
提供されるコンテンツをキャッシュデータとして記憶す
るキャッシュメモリを有するキャッシュサーバであっ
て、ユーザグループによるコンテンツのリクエスト回数が所
定のコンテンツ抽出閾値に達したときに前記コンテンツ
を前記キャッシュメモリにキャッシングするように制御
されることを特徴とするキャッシュサーバ。
【請求項１３】コンテンツ配信ネットワーク上のキャ
ッシュサーバによるコンテンツのキャッシングを制御す
るキャッシュ制御装置であって、ユーザグループによるコンテンツのリクエスト回数をカ
ウントするリクエスト回数カウンタと、前記リクエスト回数カウンタによりカウントされたリク
エスト回数が所定のコンテンツ抽出閾値に達したときに
前記コンテンツを前記キャッシュサーバにキャッシング
させるキャッシュ制御部と、を含むことを特徴とするキャッシュ制御装置。
【請求項１４】コンテンツ配信ネットワークを介して
提供されるコンテンツをキャッシュデータとして記憶す
るキャッシュメモリに関連して用いられる、コンピュー
タにて実行可能なプログラムであって、ユーザグループによるコンテンツのリクエスト回数をカ
ウントし、リクエスト回数が所定のコンテンツ抽出閾値
に達したときに前記コンテンツを前記キャッシュメモリ
にキャッシングさせるキャッシュ制御を前記コンピュー
タに実現させることを特徴とするプログラム。
【請求項１５】請求項１４に記載のプログラムを記録
した、コンピュータにて読取可能な記録媒体。