JP2006171822A

JP2006171822A - コンテンツ配信方法

Info

Publication number: JP2006171822A
Application number: JP2004359341A
Authority: JP
Inventors: Atsushi Terauchi; 敦寺内; Osamu Akashi; 修明石; Mitsuru Maruyama; 充丸山; Kensuke Fukuda; 健介福田; Toshiharu Sugawara; 俊治菅原
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2004-12-13
Filing date: 2004-12-13
Publication date: 2006-06-29

Abstract

【課題】インターネットにおけるコンテンツの配信方法において、コンテンツの高品質化や大容量化、複数コンテンツの同時配信、ユーザの視聴スタイルの多様化、ネットワークやリクエストの動的な変動に容易に対応できるようにする。
【解決手段】インターネットに接続されたコンテンツサーバに格納されたコンテンツを複数のキャッシュサーバに一時的に保存させながら不特定多数のクライアント端末に配信するときに、個々のキャッシュサーバに、自律的に自己の状態およびネットワークの状態を観測させ、クライアントからリクエストされたコンテンツのキャッシュデータを持つキャッシュサーバ群を探索し、自己の状態、他のキャッシュサーバの状態、リクエストの種類や量に応じてリクエストの処理を前記コンテンツサーバまたはキャッシュサーバに振り分ける。
【選択図】図７

Description

本発明は、コンテンツ配信方法に関し、特に、コンテンツサーバに格納された映像や音楽等の大容量のコンテンツを、複数のキャッシュサーバを介して不特定多数のクライアント端末に配信する配信方法に適用して有効な技術に関するものである。

従来、ADSL(Asymmetric Digital Subscriber Line)やFTTH(Fiber To The Home)といったブロードバンド環境の普及にともない、インターネット上で流通するコンテンツも、静止画中心のコンテンツから動画中心のコンテンツに移り変わっている。また、今後のインターネットにおける動画コンテンツの配信は、コンテンツのHDTV（High Definition TeleVision）化のようなさらなる高品質化、多チャンネルによる複数コンテンツの同時配信、短時間の動画から映画などの数時間に渡る動画までのコンテンツの多様化が進むと予想される。そのため、インターネットにおける動画コンテンツの配信においては、コンテンツを配信するサーバの負荷の増大やネットワーク帯域の不足といったリソースの問題が今後さらに顕著になる可能性がある。

また、インターネットによる多チャンネルの動画配信は、従来以上にユーザがオンデマンド（on-demand）、すなわちコンテンツを自由なスタイルで視聴することを可能にする。前記コンテンツの視聴スタイルとしては、たとえば、チャンネル（コンテンツ）を頻繁に変える、早送りや巻き戻しを行いながらコンテンツ中の好きなところだけを少しずつ見る、現在配信中のコンテンツを少し遅れてから視聴する、コンテンツの主要なところだけを跳ばし見しながらダイジェスト的に視聴する、といった多様な視聴スタイルが考えられる。そのため、これからの動画コンテンツの配信においては、このようなユーザの視聴スタイルの多様性をサポートする必要がある。また、今後の動画コンテンツの配信においては、ユーザの視聴スタイルの多様化に加えて、利用者の好みの傾向、短期的な人気、地域やイベントによる特定コンテンツヘの過度の集中などのダイナミズムが配信系に発生する。

これまでに提案されている動画配信方法としては、たとえば、動画の配信を受けたクライアントが他のクライアントに対するキャッシュサーバとして働くことによりサーバの負荷を軽減する方法（たとえば、非特許文献１を参照）や、キャッシュサーバが協調してデータの配信経路を構築するとともにサーバやネットワーク帯域の負荷軽減を図る方法（たとえば、非特許文献２を参照）、複数の動画を複数のクライアントに配信するために最適なキャッシュサーバの配置構成を計算により求めてそれらを用いて動画配信を行う方法（たとえば、非特許文献３を参照）などの方法がある。

しかしながら、これらの動画配信方法のうち、前記非特許文献１や非特許文献２に記載された配信方法では、複数のビデオ（コンテンツ）の同時配信を想定していないため、前述のような多チャンネルによる複数コンテンツの同時配信にはそのまま適用できないという問題がある。また、前記非特許文献３に記載された配信方法の場合、コンテンツの途中から視聴するなどの多様なリクエストに対応する配信を想定していない。そのため、前述のようなユーザの視聴スタイルの多様化に対応できないという問題がある。

一方、WWWコンテンツの配信においては、proxy cacheやCDN(Contents Delivery Network)が利用され、前記コンテンツを配信するサーバやネットワークの負荷軽減に効果を上げているが、前記proxy cacheはサイズ（容量）の小さいコンテンツには有効であるが、たとえば、動画のようなサイズの大きなコンテンツにはそのままでは適用できない。また、前記proxy cacheを応用した技術として、たとえば、コンテンツの一部のみをキャッシュするpartial caching方式（たとえば、非特許文献４を参照）が提案されているが、前記partial caching方式も含め、従来のキャッシュベースの負荷軽減方法では、サーバやネットワーク帯域といったリソース配置が固定的である。そのため、前述のようにリクエストが多様化し、かつ、その傾向が頻繁に変化するような動的な環境ではキャッシュのヒット率が下がり効果が十分に得られないという問題がある。

また、IP網を使った多チャンネルの動画配信においては、IPレベルあるいはアプリケーションレベルでのmulticastを利用した配信方法が多く提案されている（たとえば、非特許文献５、非特許文献６、非特許文献７を参照）。前記multicastは、たとえば、ライブ映像の配信のように同じコンテンツに対するリクエストが同時に来るような場合、あるいは、プロバイダが自社の顧客に限定してサービスを提供するような配信先のグループが事前に予想可能である場合には効果的である。しかし、前述のように、今後のインターネットにおける動画コンテンツの配信において想定される多様なリクエストが断続的に送られてくる状況を考えた場合、サーバはリクエスト毎にmulticastツリーをいくつも生成しなければならず、結果として、サーバの負荷が軽減されないという問題がある。
D. A. Tran, K. A. Hua, and S. Sheu, "A New Caching Architecture for Efficient Video-on-Demand Services on the Internet", IEEE Symposium on Applications and the Internet (SAINT 2003), pp.172-181, 2003. M. M. Hefeeda, B. K. Bhargava, and D. K. Y. Yau, "A hybrid architecture for cost-effective on-demand media streaming", COMPUTER NETWORKS, Vol.44, No.3, pp.353-382, Feb, 2004. B. Wang, S. Sen, M. Adler, and D. Towsley, "Optimal Proxy Cache Allocation for Efficient Streaming Media Distribution", IEEE INFOCOM 2002, June 2002. S. Jin, A. Bestavros, and A. Iyengar, "Accelerating Internet Streaming Media Delivery using Network-Aware Partial Caching", International Conference on Distributed Computing Systems (ICDCS '02), 2002. Kien A. Hua, Duc A. Tran, and Roy Villafane, "Overlay Multicast for Video on Demand on the Internet", ACM SIGAPP Symposium on Applied Computing (SAC 2003), March 2003. Duc A. Tran, Kien A. Hua, and Tai T. Do, "ZIGZAG: An Efficient Peer-to-Peer Scheme for Media Streaming", IEEE INFOCOM 2003, March 2003. K. Hua, Y. Cai, and S. Sheu, "Patching: A multicast technique for true video on-demand services", ACM Multimedia '98, 1998.

本発明が解決しようとする問題点は、前記背景技術で説明したように、従来のインターネットにおける動画等のコンテンツの配信方法では、今後予想されるコンテンツの高品質化や大容量化、複数コンテンツの同時配信、ユーザの視聴スタイルの多様化、ネットワークやリクエストの動的な変動に対応できないという点である。

このような問題点の具体例として、不特定多数のユーザに対して多種類の動画を配信する際の問題点について説明する。不特定多数のユーザに対する多種類の動画配信には次のような問題が存在し、リソースを効率的に利用しながら高品質な動画を提供することを特に難しくしている。

１つめの問題点は、リソースの消費量の増加である。この点について、たとえば、前述のような前記HDTVクラスの高品質の動画コンテンツを100チャンネルで多重配信するような場合を考えると、予想されるリソースの消費量は非常に大きく、稼働率を最大に見積もってサーバやネットワークを設置することは初期投資が膨大になるため現実的ではない。

２つめの問題点は、リクエストの多様化による配信系の状態の変動である。この点について、たとえば、ユーザの動画の視聴に対する要求（リクエスト）が多様になることを考えると、TV放送のような単一ストリームによる単純な配信では不十分である。また、たとえば、１つのコンテンツに対するリクエストは複数のユーザから非同期的に発生するので、基本的にリクエスト数に応じた配信ストリームが発生する。また、ある程度同期した配信として１まとめにできるリクエストの集合があったとしても、たとえば、特定のニュースだけ見たい場合などのユーザによる早送りや跳ばし見（スキップ）といった操作により途中からストリームとして分割する必要が生じることがあり、配信系の環境が頻繁に変動する。このように、１つのコンテンツであっても多数のユーザに配信するとあたかも異なるコンテンツが存在するかのように、ネットワークや特にサーバに対して負荷がかかる。さらに、これらのリクエストがどのくらい来るか、どのコンテンツに人気が出るか、といったリクエスト全体の動向は事前の予測が難しく、しかもこの動向は配信されるコンテンツの変化などによって頻繁に変動することが予想される。そのため、従来の配信環境ではサーバの能力やネットワーク帯域といったリソースの稼働率を事前に見積もることはできず、さらにシステム稼働後もリクエストの変動に合わせてリソースの最適な配置を常に行わなければリソースを効率的に利用できないという問題がある。

本発明の目的は、インターネットにおけるコンテンツの配信方法において、コンテンツの高品質化や大容量化、複数コンテンツの同時配信、ユーザの視聴スタイルの多様化、ネットワークやリクエストの動的な変動に対応することが可能な配信方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面によって明らかになるであろう。

本願において開示される発明の概略を説明すれば、以下の通りである。

（１）ネットワーク上に設置されたコンテンツサーバおよび複数のキャッシュサーバからなるコンテンツ配信システムで、前記コンテンツサーバに格納されたコンテンツデータを、前記キャッシュサーバ上に一時的に保存させながら、前記コンテンツデータを複数のクライアント端末に配信するコンテンツ配信方法であって、前記各キャッシュサーバが、自律的に自己の状態およびネットワークの状態を観測するステップ１と、前記キャッシュサーバが、他のキャッシュサーバとの間で通信を行い、複数のキャッシュサーバの中から、前記クライアント端末からリクエストされたコンテンツのキャッシュデータを保存しているキャッシュサーバを探索するステップ２と、前記キャッシュサーバが、自己の状態、前記他のキャッシュサーバの状態、および前記リクエストの種類または量に応じて、前記リクエストの処理を前記コンテンツサーバまたはキャッシュサーバに振り分けるステップ３とを有するコンテンツ配信方法である。

（２）前記（１）のコンテンツ配信方法において、前記ステップ３は、あるキャッシュサーバで行っている処理を、他のキャッシュサーバに分配させるステップを有するコンテンツ配信方法である。

（３）前記（１）または（２）のコンテンツ配信方法において、前記ステップ３は、複数のキャッシュサーバで行われている同一の処理を、前記複数のキャッシュサーバのうちのいくつかのキャッシュサーバに集約させるステップを有するコンテンツ配信方法である。

（４）前記（１）から（３）のコンテンツ配信方法のいずれかにおいて、前記ステップ３は、あるキャッシュサーバで行われている処理と同一の処理を他のキャッシュサーバが行うときに、前記処理を行っているキャッシュサーバでの処理が終了した後、前記キャッシュサーバが保存しているコンテンツデータ（キャッシュデータ）を前記他のキャッシュサーバが利用できるように予約するステップを有するコンテンツ配信方法である。

本発明のコンテンツ配信方法は、前記（１）の配信方法のように、前記キャッシュサーバを自律的に制御することにより、不特定多数のクライアント端末に、複数種類のコンテンツを同時に配信するときの前記コンテンツ配信システムのリソースを効率的に利用するとともに、動画等のサイズ（容量）の大きいコンテンツを効率的に配信することができる。そのため、今後予想されるコンテンツの高品質化や大容量化、複数コンテンツの同時配信、ユーザの視聴スタイルの多様化、ネットワークやリクエストの動的な変動に容易に対応できる。

また、前記（１）のコンテンツ配信方法において、前記コンテンツ配信システムのリソースを効率的に利用する方法としては、たとえば、前記（２）のコンテンツ配信方法のように、前記ステップ３において、あるキャッシュサーバで行っている処理を、他のキャッシュサーバに分配させる方法がある。このような方法では、たとえば、処理の負荷が大きくなったキャッシュサーバで行っているコンテンツデータの配信（転送）処理の一部を負荷が小さい他のキャッシュサーバに分配することができ、キャッシュサーバ間の負荷の偏りによるリソースの非効率的な利用を防ぐことができる。

また、前記コンテンツ配信システムのリソースを効率的に利用する方法としては、たとえば、前記（３）のコンテンツ配信方法のように、前記ステップ３において、複数のキャッシュサーバで行われている同一の処理をいくつかのキャッシュサーバに集約させる方法もある。このような方法では、多数のキャッシュサーバが同一のコンテンツを配信（転送）しているときに、その処理を、たとえば、１つのキャッシュサーバに集約することで、前記コンテンツを配信できるキャッシュサーバを探索するときに消費されるリソースの量を低減したり、多数のキャッシュサーバで同一のコンテンツを保持することによるキャッシュサーバ（キャッシュスペース）の浪費を低減したりすることができる。

また、前記（１）から（３）のコンテンツ配信方法において、前記キャッシュサーバが保存しているキャッシュデータをより有効に活用するには、たとえば、前記（４）のコンテンツ配信方法のように、コンテンツを配信中のキャッシュサーバが保存しているコンテンツデータ（キャッシュデータ）を、配信終了後に他のキャッシュサーバが利用できるように予約することができるようにすることが好ましい。このようにすることで、同じコンテンツに対して時間差のあるリクエストが多く来るときのキャッシュデータの利用効率を向上させることができる。

以下、本発明について、図面を参照して実施の形態（実施例）とともに詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは、同一符号を付け、その繰り返しの説明は省略する。

本発明のコンテンツ配信方法では、まず、proxy cache方式の持つサーバの負荷軽減という利点を生かすために既存のCDN(Contents Delivery Network)と同様に多数のキャッシュサーバを配信系とするアーキテクチャを基本とする。そして、個々のキャッシュサーバを自律的なエージェントとしてモデル化することにより、それぞれのキャッシュサーバ自身がネットワークの状態およびリクエストの量や種類などのシステムの状態を観測して自分のキャッシュの内容や量を動的に決定する。また、キャッシュサーバ同士が通信を行ってキャッシュデータの内容や負荷の状況に応じてクライアントからのリクエストの振り分けの制御を行う。これらの制御を行うことで、ネットワークおよびリクエストの動的な変動の状態に適応しながらリソースの負荷率を軽減する動画配信を可能にする。

図１は、本発明による一実施例のコンテンツ配信方法が適用されるコンテンツ配信システムの概略構成を示す模式図である。
図１において、１はビデオサーバ（コンテンツサーバ）、２はクライアント端末、３はキャッシュサーバである。

本実施例のコンテンツ配信方法は、図１に示すように、動画のオリジナルデータを保存・配信するビデオサーバ（コンテンツサーバ）１と、動画の配信を受けるクライアント（ＣＬ）端末２と、前記ビデオサーバ１から前記クライアント端末２ヘの配信を中継すると同時に配信されたコンテンツ（動画データ）の一部を保存する多数のキャッシュサーバ（ＣＳ）３からなるキャッシュサーバ群により構成される。このとき、前記ビデオサーバ１、前記キャッシュサーバ群、前記クライアント端末２は、インターネットにより相互に接続されているとする。またこのとき、図１では省略しているが、前記キャッシュサーバ群の各キャッシュサーバ３も、インターネット等のネットワークにより相互に接続されているとする。

また、図１に示したようなコンテンツ配信システムの構成は、従来のWWWコンテンツの配信を効率化されるために用いられる一般的なCDNと同様の構成であるため、前記ビデオサーバ１の構成、前記クライアント端末２の構成、前記各キャッシュサーバ３の構成についての詳細な説明は省略する。またこのとき、前記ビデオサーバ１は、前記動画等のコンテンツを配信する業者または一般ユーザが設置し、前記キャッシュサーバ３は、専門の業者やインターネットサービスプロバイダ（ISP）あるいは通信網を提供する事業者により設置されているとする。

なお、図１に示したようなコンテンツ配信システムにおいて、前記ビデオサーバ１は、複数の動画コンテンツを格納（保持）しており、前記各クライアント端末２のリクエストに応じて、１つ以上のコンテンツを同時に、かつ、１つのコンテンツを複数のクライアント端末２またはキャッシュサーバ３に対して配信（送信）することができるとする。

このようなコンテンツ配信システムにおいて前記ビデオサーバ１から配信される動画データは、一般的なWWWのコンテンツなどとは違いファイルサイズ（容量）が非常に大きいため、１つのキャッシュサーバ３がそのすべてを保存することはできない。そのため、前記動画データのようなサイズの大きいコンテンツを配信する際には、前記各キャッシュサーバ３が、前記配信中の動画を一定の量だけ自分のキャッシュスペースに保存しながら配信を行う。これはちょうど、一定サイズのWindowをずらすイメージで保存され、配信が進むにつれてキャッシュされるデータも順次更新される。そして、前記キャッシュサーバ３のキャッシュスペース（storage）に空きがなくなった場合は、キャッシュのデータは最も古いデータから置き換わっていき、それ以外にも一定期間アクセスのなかったキャッシュデータはキャッシュサーバ３から削除される。

また、本実施例のコンテンツ配信方法では、以下で説明するように、前記キャッシュサーバ群のキャッシュサーバ３同士の協調により、あるキャッシュサーバから他キャッシュサーバにタスク（リクエスト）の実行を依頼することがある。しかしながら、タスクを依頼されたキャッシュサーバにも自己のリソースや能力を勘案する必要があるため、依頼が必ず受理されるとは限らない。そのため、依頼する側とされる側は役割の割り当てに関して必ずコミットメント（たとえば、文献；Michael Wooldridge, “An Introduction to Multiagent Systems”, John Wiley & Sons, Ltd., 2002.を参照）を確立する必要がある。コミットメントはロックとは異なり、依頼された側のサーバで依頼されたタスクを実行できると思ったときだけ行う。また依頼をコミットしたサーバは、受理した依頼を実行できないと判断した場合には依頼元にその旨を通知したり、代替を推薦したりするといった動作を行う義務を負う。一方、依頼した側もリクエストがキャンセルされるなどしてタスクを実行する必要がなくなればその旨を通知する義務がある。

以下、図１に示したようなコンテンツ配信システムにおける本実施例のコンテンツ配信方法について説明するが、その前に、まず、本実施例のコンテンツ配信方法における基本的な動画配信手順について説明する。

図２乃至図５は、本実施例のコンテンツ配信方法における基本的な動画配信手順を説明するための模式図であり、図２はクライアント端末からキャッシュサーバ（Mediator）にリクエストを送信するステップの図、図３はリクエストを受信したキャッシュサーバ（Mediator）が他のキャッシュサーバ（Mediator）にデータの探索を依頼するステップの図、図４はリクエストを受信したキャッシュサーバ（Mediator）が他のキャッシュサーバ（Mediator）からの探索結果を受信するステップの図、図５はキャッシュサーバ（Mediator）からリクエストを送信したクライアント端末に探索結果を返信するステップの図である。

本実施例のコンテンツ配信方法が適用されたコンテンツ配信システムでは、前述のように、動画コンテンツ等のサイズの大きいコンテンツを配信する場合、個々のキャッシュサーバ３には動画の一部分しか保持できない。そのため、前記動画コンテンツの配信を行うときには、複数のキャッシュサーバ３に前記動画のさまざまな部分が保存されるという状況が通常である。この状況下で動画配信を効率的に行うためには、複数のキャッシュサーバに分散して保存された動画のキャッシュデータをできる限り多く見つけ、前記動画コンテンツのデータ（パケット）をなるべくキャッシュサーバ３から受信し、キャッシュデータの利用率を高めることが好ましい。このようにすることで、オリジナルのサーバ（ビデオサーバ１）ヘのアクセスの集中による負荷を軽減でき、その結果として、リソースの負荷軽減が可能となる。

このとき、前記クライアント端末２は、図２に示すように、ネットワーク中（キャッシュサーバ群）のうちの１つのキャッシュサーバ３Ｍ₁に対してリクエストを送信する。このとき、前記リクエストを送信するキャッシュサーバの選択には、たとえば、DNS redirectionなど既存のCDNで用いられている方法を利用することができるので、詳細な説明は省略する。またこのとき、前記クライアント端末２からのリクエストを受けたキャッシュサーバ３Ｍ₁を、他のキャッシュサーバと区別するために、Mediatorと呼ぶこととし、図中ではＣＳ（Ｍ）と示すことにする。そして、前記クライアント端末２からのリクエストを受けた前記Mediator３Ｍ₁は、以下の手順により、リクエストされた動画（の一部分）を所有するキャッシュサーバの集合を形成する。

前記Mediator ３Ｍ₁は、前記クライアント端末２からのリクエストを受信すると、まず、図２に示すように、自分の近傍を探索してリクエストされた動画の一部を保持するキャッシュサーバの集合を形成する。ここで、前記Mediator ３Ｍ₁が自分の近傍のキャッシュサーバ３を見つけるために、ネットワーク（キャッシュサーバ群）のトポロジ情報を利用する。前記トポロジ情報は、IPアドレスやBGP(Border Gateway Protocol)におけるAS-path情報を用いることで取得することができるので、詳細な説明は省略する。

このとき、前記Mediator ３Ｍ₁は、自分の近傍を探索した結果、リクエスト動画をキャッシュしているキャッシュサーバ３を発見すると、そのキャッシュサーバ３に対して対応する動画を近いうちに利用するという要請を出す。そして、その要請を受けたキャッシュサーバ３は、自己のリソースを勘案し、この要求をコミットする。コミットを行ったキャッシュサーバ３は、実際にそのデータが使われるまで可能な限りそのデータを保持する。またこのとき、もし、リソースの関係でコミットメントを放棄しなくてはならない場合や、近隣で同じキャッシュ内容を持つ適切なエージェントが存在する場合には、新たなコミットメントを結ぶように前記Mediator ３Ｍ₁に要請する。

また、前記Mediator ３Ｍ₁が自分の近傍を探索した結果、リクエストされた動画の一部あるいは全部が見つからないときは、図３に示すように、最初の探索要求を受けた前記Mediator ３Ｍ₁から、別のキャッシュサーバ（Mediator）３Ｍ₂，３Ｍ₃，３Ｍ₄に前記リクエストを送信し、前記別のMediator ３Ｍ₂，３Ｍ₃，３Ｍ₄に同様に自分の近傍内で探索を依頼し、リクエストされた動画のキャッシュデータを取得できるか試みる。このとき、前記リクエストの転送は一定回数だけ行う。この場合も、前記別のMediator ３Ｍ₂，３Ｍ₃，３Ｍ₄における探索でデータが見つかった場合は、前記別のMediator ３Ｍ₂，３Ｍ₃，３Ｍ₄とキャッシュデータを持つキャッシュサーバ３の間でコミットメントを確立する。そして、前記別のMediator ３Ｍ₂，３Ｍ₃，３Ｍ₄は、リクエストされた動画のキャッシュデータを持つキャッシュサーバを見つけた場合は、図４に示したように、そのキャッシュサーバの情報を前記最初の探索要求を受けたMediator ３Ｍ₁に通知する。

このようにして、前記Mediator ３Ｍ₁において、リクエストされた動画の全体を構成できるキャッシュサーバの集合ＣＳＧが形成できた場合、図５に示すように、この集合ＣＳＧを元に、前記Mediator ３Ｍ₁は個々のキャッシュサーバ３からデータを受信して前記クライアント端末２に転送する。また、動画全体を提供できるサーバの集合ＣＳＧが形成できない場合、図示は省略するが、前記Mediator ３Ｍ₁は、足りない部分を前記ビデオサーバから取得して前記クライアント端末に転送する。また、前記Mediator ３Ｍ₁は自分自身もキャッシュサーバであるので、前記コンテンツ（キャッシュデータ）の転送の過程において、自己のキャッシュデータを随時更新する。

前記クライアント端末２は、このような手順で前記Mediator ３Ｍ₁から動画を受信するが、もし配信の途中で前記クライアント端末２からのリクエストの変更、あるいはキャンセルがあった場合、前記Mediator ３Ｍ₁は、コミットメントを確立した各キャッシュサーバに通知をしてコミットメントを解消する。

以上のような手順で動画コンテンツを配信するコンテンツ配信システムにおいて、今後予想されるコンテンツの高品質化や大容量化、複数コンテンツの同時配信、ユーザの視聴スタイルの多様化、ネットワークやリクエストの動的な変動に対応するための方法として、本実施例のコンテンツ配信方法では、以下のようなリクエストの振り分け制御を行う。

図６乃至図１１は、本実施例のコンテンツ配信方法におけるリクエストの振り分け処理を説明するための模式図であり、図６および図７はリクエストの分配処理を説明するための図、図８および図９はリクエストの委託処理を説明するための図、図１０および図１１はリクエストの交換処理を説明するための図である。

本実施例のコンテンツ配信方法では、前述のように、前記キャッシュサーバ群の各キャッシュサーバ３が前記ビデオサーバ１から配信される動画コンテンツの一部をキャッシュデータとして一時的に保持しており、前記クライアント端末２が前記動画コンテンツの配信を受けるときには、できるだけ前記キャッシュサーバ３のキャッシュデータを受信するようにし、オリジナルのサーバ（ビデオサーバ１）ヘのアクセスの集中による負荷を軽減して、リソースの負荷を軽減している。

このとき、前記各キャッシュサーバ３は、その動作中は定期的に自己の状態やネットワークの状態を測定している。そして、個々のキャッシュサーバ３はクライアント端末２からリクエストが来たら状態の最新の観測結果を調査し、それがたとえば、処理中のリクエストの数が一定値を上回る等の一定の条件を満たした場合に、周りのキャッシュサーバと通信を行って、以下に示す３つのリクエストの振り分け処理のいずれかを行う。

１つめの処理は、他のキャッシュサーバに対して自分と同じデータを保持することを依頼するリクエストの分配処理である。この分配処理は、キャッシュサーバに対するリクエストが大量になったときに利用して、自分と同じキャッシュデータを他者に持たせることで同一コンテンツに対するリクエストを２者で分担して処理することで負荷分散を実現することを可能にする。

前記分配処理の例として、たとえば、図６に示すように、あるキャッシュサーバ３Ａから５つのクライアント端末２Ａ，２Ｂ，２Ｃ，２Ｄ，２Ｅにコンテンツ#1のキャッシュを配信（転送）している場合を考える。このとき、前記キャッシュサーバ３Ａの配信能力、または前記キャッシュサーバ３Ａと各クライアント端末２Ａ，２Ｂ，２Ｃ，２Ｄ，２Ｅの間の通信経路の帯域に余裕があれば、前記キャッシュサーバ３Ａから安定した配信を行える。しかしながら、たとえば、前記キャッシュサーバ３Ａの負荷が増大して、図６に示したように、あるクライアント端末２Ｅに対してコンテンツ#1のキャッシュを配信できなくなったとする。この場合、前記キャッシュサーバ３Ａは、たとえば、図７に示すように、配信中のコンテンツ#1のキャッシュデータを他のキャッシュサーバ３Ｂに対して送信し、前記他のキャッシュサーバ３Ｂから前記クライアント端末２Ｄ，２Ｅにコンテンツ#1のキャッシュデータを配信（転送）してもらうように依頼する。このようにすることで、前記キャッシュサーバ３Ａの負荷を低減できる。

そして２つめの処理は、自分のキャッシュデータを他者に割り当てて、自分はそのデータのキャッシュの保持を中止するリクエストの委託処理である。この委託処理は、たとえば、あるコンテンツに対する人気が下がり、リクエストの量が減少してきた場合に、複数のキャッシュサーバで処理しているリクエストを処理能力のある１つのキャッシュサーバに集約して処理させるといった場合に行う。これにより他のキャッシュサーバのリソースを別の処理に使えるためリソースを効率的に利用できる。

前記委託処理の例として、たとえば、図８に示すように、あるキャッシュサーバ３Ａが３つのクライアント端末２Ａ，２Ｂ，２Ｃにコンテンツ#1のキャッシュデータを配信（転送）しており、他のキャッシュサーバ３Ｂが別の２つのクライアント端末２Ｄ，２Ｅに前記コンテンツ#1のキャッシュデータを配信（転送）している場合を考える。このとき、たとえば、前記コンテンツ#1の人気が高くてリクエスト、すなわち配信を要望するクライアント端末が多ければ、それらのクライアント端末からの多数のリクエストに対応するために、２つのキャッシュサーバ３Ａ，３Ｂで配信処理を分担することが好ましい。しかしながら、たとえば、前記コンテンツ#1の人気が下がった等の理由によりリクエストするクライアント端末が少なくなった場合、２つのキャッシュサーバ３Ａ，３Ｂで配信処理を分担することは、キャッシュサーバ（リソース）の浪費につながり、非効率な配信をしていることになる。そこで、たとえば、図８に示すように、前記他のキャッシュサーバ３Ｂが、前記キャッシュサーバ３Ａに対して、自分が受け持っているリクエストの処理の委託を依頼する。そしてこのとき、前記委託の依頼を受けた前記キャッシュサーバ３Ａにおいて、前記他のキャッシュサーバ３Ｂが行っていた処理を引き継ぐことが可能であれば、前記委託の依頼を受ける。その結果、前記依頼を受けた前記キャッシュサーバ３Ａは、図９に示すように、前記他のキャッシュサーバ３Ｂが配信（転送）していたクライアント端末２Ｄ，２Ｅを含めたクライアント端末２Ａ，２Ｂ，２Ｃ，２Ｄ，２Ｅに対して前記コンテンツ#1のキャッシュデータを配信する。このようにすることで、前記他のキャッシュサーバ３Ｂは、前記コンテンツ#1のキャッシュデータを破棄し、別のコンテンツのキャッシュデータの保持が可能となる。そのため、たとえば、前記他のキャッシュサーバ３Ｂに、リクエストが多いコンテンツのキャッシュデータを保持させれば、前記他のキャッシュサーバ３Ｂのリソース（キャッシュスペース）を有効利用することができる。

そして３つめの処理は、前記委託処理の応用であり、自分の役割を他者に委譲してその代わりに他者の持つ役割の割り当てを受けるリクエストの交換処理である。

前記交換処理の例として、たとえば、図１０に示すように、２つのキャッシュサーバ３Ａ，３Ｂがそれぞれコンテンツ#1，コンテンツ#2の２つのコンテンツのキャッシュデータをクライアント端末２Ａ，２Ｂ，２Ｃ，２Ｄ，２Ｅ，２Ｆ，２Ｇ，２Ｈに対して配信（転送）している場合を考える。またこのとき、図１０に示したように、一方のキャッシュサーバ３Ａは、前記コンテンツ#1を配信しているクライアント端末２Ａ，２Ｂ，２Ｃの数が多く、他方のキャッシュサーバ３Ｂは、前記コンテンツ#2を配信しているクライアント端末２Ｆ，２Ｇ，２Ｈの数が多いとする。このような状態は、各キャッシュサーバ３Ａ，３Ｂが、コンテンツ#1，コンテンツ#2の２つのコンテンツのキャッシュデータを保持していなければならないので、各キャッシュサーバ３Ａ，３Ｂのリソース（キャッシュスペース）の有効利用という観点からは効率的ではないと言える。そこで、前記コンテンツ#2を配信しているクライアント端末の数が多いキャッシュサーバ３Ｂは、たとえば、図１０に示したように、前記コンテンツ#1を配信しているクライアント端末の数が多いキャッシュサーバ３Ａに対して、前記コンテンツ#1のキャッシュの配信を委譲（委託）する。そして、その代わりに、前記コンテンツ#1を配信しているクライアント端末の数が多いキャッシュサーバ３Ａで配信しているコンテンツ#2の委譲（委託）を受ける。このようにすると、図１１に示すように、一方のキャッシュサーバ３Ａはコンテンツ#1のキャッシュデータの配信のみを行えばよくなり、他方のキャッシュサーバ３Ｂはコンテンツ#2のキャッシュデータの配信のみを行えばよくなる。

本実施例のように、図１に示したようなコンテンツ配信システムにおいて多種類の動画を配信する場合、１つのエージェント（キャッシュサーバ３）が複数のコンテンツのキャッシュを持つことが起こりうる。また、動画コンテンツは前述の通り複数のキャッシュサーバ３に分散して保存されるが分散されたキャッシュから部分を探索して集める作業はネットワーク帯域を消費する。そのため、このような交換処理を行うことにより、１つのコンテンツのキャッシュを少ないサーバに集めることができるので、探索のためのネットワークの通信量が削減される。そしてその結果として、リソースの効率的利用が可能になる。

本実施例のコンテンツ配信方法では、前記分配処理、委託処理、交換処理の３つの処理（制御）を行うことにより、前記キャッシュサーバ３、キャッシュデータ等のコンテンツ配信システムのリソースを有効利用することが可能であり、今後予想されるコンテンツの高品質化や大容量化、複数コンテンツの同時配信、ユーザの視聴スタイルの多様化、ネットワークやリクエストの動的な変動に対応することが可能である。しかしながら、前記分配処理、委託処理、交換処理の３つの処理（制御）に加えて、以下に示すような制御を行うことで、前記キャッシュデータをより有効に活用することができる。

前記キャッシュデータをより有効に活用する方法（制御）の１つめは、Mediator機能の分散である。本実施例のコンテンツ配信方法では、基本的には、前記Mediatorが動画の部品の探索などクライアント端末に対する配信の管理を行う。しかし、配信中の動画の連続した一部分が、ある別のキャッシュサーバ（サーバＡとする）の周りに存在する場合は、前記サーバＡに周りのキャッシュの取得を依頼することにより、該当する部分に関しては前記サーバＡを代理のMediatorとして機能させることができ、１つのリクエストの処理をサーバＡとの間で分散させることができる。これは、同一コンテンツに対する時間差のあるリクエストが多い場合には特に有効な手段と考えられる。

そして前記キャッシュデータをより有効に活用する方法（制御）２つめは、キャッシュの予約である。

図１２は、本実施例のコンテンツ配信方法においてキャッシュデータを有効に活用する方法を説明するための模式図である。

本実施例のコンテンツ配信方法において、たとえば、図１２に示すように、あるクライアント端末（ＣＬ１）２Ａに動画コンテンツを配信しているキャッシュサーバ（Mediator）３Ｍ₁がいたとする。また、前記キャッシュサーバ（Mediator）３Ｍ₁の近隣にはその動画コンテンツのキャッシュはなく、ビデオサーバ１（図示しない）からのデータを中継することでクライアント端末２Ｂに動画データの配信を行っていたとする。この場合、別のクライアント端末（ＣＬ２）２Ｂからの同一の動画に対する新たなリクエストを処理しようとしている別のキャッシュサーバ（Mediator）３Ｍ₂が、前記クライアント端末（ＣＬ１）２Ａに動画を配信中のキャッシュサーバ３Ｍ₁に対して配信が予定されている部分をキャッシュとして利用することを予約できる。この制御も、前記Mediatorの分散と同様に同じコンテンツに対して時間差のあるリクエストが多く来るときに特に有効でキャッシュデータの利用効率を向上させることが可能になる。

そして前記キャッシュデータをより有効に活用する方法（制御）３つめは、地域性を考慮したキャッシュの構成である。

気象情報などのように特定の地域からは多くのリクエストがあるが、それ以外ではさほど必要とされないような地域性のあるコンテンツは、その地域に近い位置にあるキャッシュサーバに優先的に保存されるようにする。これは、そのようなコンテンツに対するアクセスは特定の地域から集中して送られてくると考えられるため、キャッシュサーバの位置をその地域に近いところに持ってくることでネットワークの帯域利用をできる限り狭い範囲に留めることが可能になる。またそのような地域のキャッシュサーバでは当該コンテンツの保存量を増やす、消去されるまでの時間を延ばすといった制御を行うことにより、キャッシュデータのより効率的な利用が可能になる。

以上説明したように、本実施例のコンテンツ配信方法によれば、前記キャッシュサーバ群の各キャッシュサーバが保持しているコンテンツのキャッシュデータ、あるいはリクエスト処理の分配、委託、交換といった制御を行うことで、前記コンテンツ配信システムのリソースを効率的に利用することができる。そのため、インターネットによる動画配信において今後予想されるコンテンツの高品質化や大容量化、複数コンテンツの同時配信、ユーザの視聴スタイルの多様化、ネットワークやリクエストの動的な変動に対応することが可能である。

また、前記分配処理、委託処理、交換処理に加えて、前記Mediator機能の分散、キャッシュの予約、地域性を考慮したキャッシュ構成等の制御を行うことで、前記キャッシュデータの利用効率を向上させることができる。

なお、本実施例では、前記コンテンツの例として、動画を例に挙げたが、これに限らず、配信するコンテンツは音声等でもよく、データサイズ（容量）が大きいコンテンツを配信するコンテンツ配信システムであれば、本実施例のコンテンツ配信方法を適用することで、本実施例の場合と同様の効果が得られる。

以上、本発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において、種々変更可能であることはもちろんである。

本発明による一実施例のコンテンツ配信方法が適用されるコンテンツ配信システムの概略構成を示す模式図である。本実施例のコンテンツ配信方法における基本的な動画配信手順を説明するための模式図であり、クライアント端末からキャッシュサーバ（Mediator）にリクエストを送信するステップの図である。本実施例のコンテンツ配信方法における基本的な動画配信手順を説明するための模式図であり、リクエストを受信したキャッシュサーバ（Mediator）が他のキャッシュサーバ（Mediator）にデータの探索を依頼するステップの図である。本実施例のコンテンツ配信方法における基本的な動画配信手順を説明するための模式図であり、リクエストを受信したキャッシュサーバ（Mediator）が他のキャッシュサーバ（Mediator）からの探索結果を受信するステップの図である。本実施例のコンテンツ配信方法における基本的な動画配信手順を説明するための模式図であり、キャッシュサーバ（Mediator）からリクエストを送信したクライアント端末に探索結果を返信するステップの図である。本実施例のコンテンツ配信方法におけるリクエストの振り分け処理を説明するための模式図であり、リクエストの分配処理を説明するための図である。本実施例のコンテンツ配信方法におけるリクエストの振り分け処理を説明するための模式図であり、リクエストの分配処理を説明するための図である。本実施例のコンテンツ配信方法におけるリクエストの振り分け処理を説明するための模式図であり、リクエストの委託処理を説明するための図である。本実施例のコンテンツ配信方法におけるリクエストの振り分け処理を説明するための模式図であり、リクエストの委託処理を説明するための図である。本実施例のコンテンツ配信方法におけるリクエストの振り分け処理を説明するための模式図であり、リクエストの交換処理を説明するための図である。本実施例のコンテンツ配信方法におけるリクエストの振り分け処理を説明するための模式図であり、リクエストの交換処理を説明するための図である。本実施例のコンテンツ配信方法においてキャッシュデータを有効に活用する方法を説明するための模式図である。

符号の説明

１…ビデオサーバ（コンテンツサーバ）
２，２Ａ，２Ｂ，２Ｃ，２Ｄ，２Ｅ，２Ｆ、２Ｇ、２Ｈ…クライアント端末
３，３Ａ，３Ｂ…キャッシュサーバ
３Ｍ₁，３Ｍ₂，３Ｍ₃，３Ｍ₄…Mediator

Claims

ネットワーク上に設置されたコンテンツサーバおよび複数のキャッシュサーバからなるコンテンツ配信システムで、前記コンテンツサーバに格納されたコンテンツデータを、前記キャッシュサーバ上に一時的に保存させながら、前記コンテンツデータを複数のクライアント端末に配信するコンテンツ配信方法であって、
前記各キャッシュサーバが、自律的に自己の状態およびネットワークの状態を観測するステップ１と、
前記キャッシュサーバが、他のキャッシュサーバとの間で通信を行い、複数のキャッシュサーバの中から、前記クライアント端末からリクエストされたコンテンツのキャッシュデータを保存しているキャッシュサーバを探索するステップ２と、
前記キャッシュサーバが、自己の状態、前記他のキャッシュサーバの状態、および前記リクエストの種類または量に応じて、前記リクエストの処理を前記コンテンツサーバまたはキャッシュサーバに振り分けるステップ３とを有することを特徴とするコンテンツ配信方法。
前記ステップ３は、あるキャッシュサーバで行っている処理を、他のキャッシュサーバに分配させるステップを有することを特徴とする請求項１に記載のコンテンツ配信方法。
前記ステップ３は、複数のキャッシュサーバで行われている同一の処理を、前記複数のキャッシュサーバのうちのいくつかのキャッシュサーバに集約させるステップを有することを特徴とする請求項１または請求項２に記載のコンテンツ配信方法。
前記ステップ３は、あるキャッシュサーバで行われている処理と同一の処理を他のキャッシュサーバが行うときに、前記処理を行っているキャッシュサーバでの処理が終了した後、前記キャッシュサーバが保存しているコンテンツデータを前記他のキャッシュサーバが利用できるように予約するステップを有することを特徴とする請求項１乃至請求項３のいずれか１項に記載のコンテンツ配信方法。