JPWO2013047207A1 - キャッシュシステム、キャッシュ方法、及びキャッシュサーバ - Google Patents

Abstract

オリジンサーバと、端末から要求されたコンテンツを、オリジンサーバの代わりに配信する複数のキャッシュサーバとを備え、キャッシュサーバは、端末から要求されたコンテンツを保持していない場合に、そのコンテンツを保持する他のキャッシュサーバから取得して端末に配信するにあたり、他のキャッシュサーバとコンテンツを送受信することによる負荷を示す指標に基づいて、コンテンツの複製の制御行う。

Description

本発明は、キャッシュシステム、キャッシュ方法、及びキャッシュサーバに関する。特に本発明は、端末から要求されたコンテンツを、オリジンサーバの代わりにキャッシュサーバから端末に配信するキャッシュシステム、キャッシュ方法、並びにキャッシュサーバに関する。

図１４は、キャッシュシステムの一例を示す。この例のキャッシュシステムは、ネットワーク１、ネットワーク２、端末１００、オリジンサーバ２００、及びキャッシュサーバ３００を備える。

キャッシュサーバ３００は、ネットワーク１を介して、オリジンサーバ２００と通信接続される。また、キャッシュサーバ３００は、ネットワーク２を介して、端末１００と通信接続される。

オリジンサーバ２００は、端末１００から要求されたコンテンツを、端末１００に配信する。キャッシュサーバ３００は、オリジンサーバ２００から端末１００へのコンテンツの配信を仲介する。より具体的に説明すると、キャッシュサーバ３００は、コンテンツをキャッシュすることによって、端末１００から同じコンテンツを要求された場合には、オリジンサーバ２００の代わりに要求されたコンテンツを配信する。これによりオリジンサーバ２００や、ネットワーク１の負荷を下げることができる。これによって、一般にキャッシュサーバ３００は、オリジンサーバ２００よりも端末１００に近い場所に配置されるので、コンテンツ配信の遅延も短縮することができる。

また、キャッシュサーバ３００は、オリジンサーバ２００の所有者、又はオリジンサーバ２００に保持されたコンテンツの所有者とのビジネス的な同意に従い、事前に配信対象とするコンテンツを保持することもある。

図１５にコンテンツ配信システムのシーケンス図を示す。まずステップＳ１００で、端末１００は、オリジンサーバ２００に対してコンテンツの要求を行う。ここで、コンテンツ要求を行うためのプロトコルは様々なプロトコルが考えられるが、例えばＨＴＴＰの場合は、コンテンツ要求は、ＨＴＴＰ ＧＥＴに相当する。

端末１００が、オリジンサーバ２００に対して行うコンテンツ要求を、キャッシュサーバ３００に仲介させるための方法がいくつか存在する。ひとつは、端末１００に、ＷＥＢ Ｐｒｏｘｙサーバとしてキャッシュサーバ３００の情報を設定し、端末１００の動作によりキャッシュサーバ３００にアクセスする方法である。

次に、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバを使う方法である。ＤＮＳサーバを使う方法は、端末１００が、ＤＮＳサーバを使ってオリジンサーバ２００のアドレスを取得する際に、ＤＮＳサーバは、オリジンサーバ２００の代わりにキャッシュサーバ３００のアドレスを応答する方法である。他にも、ＨＴＴＰリダイレクトによる方法や、端末１００がオリジンサーバ２００と通信する際に通過する経路上にキャッシュサーバ３００を配置する方法等があるが、本発明には直接関係ないので詳細は省略する。

キャッシュサーバ３００は、コンテンツ要求を受信すると、コンテンツ要求に含まれるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）等の情報に基づいて、要求対象のコンテンツを特定する。そして、キャッシュサーバ３００は、要求されたコンテンツを保持しているか否かを確認し、保持していない場合はオリジンサーバ２００に要求対象のコンテンツ要求を転送する（このステップでは対象のコンテンツを保持していないものとする）。ここで、端末１００からのコンテンツ要求を変更すること無くコンテンツ要求を転送する場合もあれば、アドレス等に変更を加えた後で転送する場合もある。

オリジンサーバ２００は、キャッシュサーバ３００から転送されたコンテンツ要求を受信すると、要求されたコンテンツをキャッシュサーバ３００へと配信する処理を開始する（Ｓ１０１）。

キャッシュサーバ３００は、オリジンサーバ２００から配信が開始されたコンテンツを受信すると、ステップＳ１０２で、これを端末１００に配信すると共に、そのコンテンツのキャッシュを保存する（以後、キャッシュするともいう）。

その後、端末１００は、キャッシュサーバ３００介して配信されたコンテンツを受信する。

次に端末１００が同じコンテンツを要求した場合を考える。ここでの端末１００は、一度目にコンテンツを要求した端末１００と同じ端末である必要はない。この場合、キャッシュサーバ３００は、端末１００からコンテンツ要求を受信すると、そのコンテンツのキャッシュを保持している。そのため、コンテンツ要求をオリジンサーバ２００に転送することなく、キャッシュサーバ３００から要求されたコンテンツを端末１００へ配信する（Ｓ１０３）。

次に、図１４に示すキャッシュサーバを、複数台分散配備した例を図１６に示す。すなわち、図１６は、キャッシュがキャッシュサーバ間でキャッシュの交換をしない非連携キャッシュシステムの例である。

図１６のキャッシュサーバ３００ａ、３００ｂ、３００ｃ、端末１００ａ、１００ｂ、１００ｃ、ネットワーク２ａ、２ｂ、２ｃはそれぞれ、図１４で説明したキャッシュサーバ３００、端末１００、ネットワーク２が複数ある状況を示している。ネットワーク２ａ、２ｂ、２ｃは、異なるＩＳＰ、又はネットワークオペレータのネットワークの場合もあれば、同じＩＳＰ、ネットワークオペレータのネットワークの場合もある。

図１６では、端末１００ａがコンテンツ要求した場合、キャッシュサーバ３００ａにキャッシュが保持される。そして、端末１００ｂ、端末１００ｃについては、それぞれキャッシュサーバ３００ｂ、キャッシュサーバ３００ｃにキャッシュが保持される。このとき、キャッシュされる際の動作は、図１５と同じである。

この例のキャッシュシステムは、端末１００ａから要求されたコンテンツをキャッシュサーバ３００ａがキャッシュしていなかった場合、他のキャッシュサーバにキャッシュがあったとしても、オリジンサーバ２００から取得する。

これを改善するため、各キャッシュサーバ間で連携可能なキャッシュシステムとすることが考えられる。具体的には、あるキャッシュサーバで端末から要求されたコンテンツをキャッシュしていなかった場合、すぐオリジンサーバからコンテンツを取得するのではなく、他のキャッシュサーバが要求されたコンテンツを保持していないかを否かを確認する。その結果、コンテンツを保持しているキャッシュサーバがあった場合、当該キャッシュサーバからキャッシュを取得し、端末に配信するというものである。以降ではこの連携のことを、キャッシュサーバ間連携と呼称する。

キャッシュサーバ間連携可能なキャッシュシステムを図１７に示す。図１７の、キャッシュサーバ３００’ａ、３００’ｂ、３００’ｃはそれぞれ連携機能を持ったキャッシュサーバである。管理サーバ４００は、各キャッシュサーバ３００’に対して他のキャッシュサーバが保持するコンテンツの情報を提供したり、各キャッシュサーバが保持すべきコンテンツを制御する。

図１８にキャッシュサーバ間連携の効果を示すグラフを示す。図１８は、端末１００のコンテンツ要求の傾向がＺｉｐｆ分布に従うと想定したときに、単独のキャッシュサーバのヒット率と、キャッシュサーバ間連携を適用した場合のヒット率の違いを示したものである。Ｚｉｐｆ分布とは、人気度の高いコンテンツにアクセスが集中する分布を示し、ｋ番目に人気のコンテンツへのアクセス確率は以下の式（１）で表すことができる。

ここで、Σ｛Ｎ，ｎ＝１｝ （１／ｎ＾ｓ）は、ｎを１からＮまで変化させた時の、（１／ｎ＾ｓ）の和を示す。また、ｓは、人気の高いコンテンツへのアクセス集中度を決めるパラメタであり、動画配信サービスにおいてはｓ＝０．５５程度となるとの研究報告があるため、ここでは、ｓ＝０．５５とした。

図１８のグラフでは、連携可能なキャッシュサーバの数を横軸、システム全体でのヒット率、すなわち連携の結果得られるヒット率を縦軸としている。連携可能なキャッシュサーバの数が０の場合は連携なしのキャッシュサーバを適用した場合のヒット率を示す。

各ラインでは、異なるキャッシュサーバのサイズを想定している。キャッシュサーバのサイズは、オリジンサーバに対する割合として表現している。

図１８より、キャッシュサーバのサイズに関わらず、キャッシュサーバ間連携によりキャッシュヒット率を向上できることがわかる。しかし、図１８の場合では、各キャッシュサーバへのコンテンツ配置については連携を意識した制御は行わず、要求されたコンテンツを各キャッシュサーバの判断でキャッシュするのみである。

各キャッシュサーバへのコンテンツ配置についても、キャッシュサーバ間連携を意図した配置とすることで、連携によるキャッシュヒット率の改善効果は図１８に示されている値以上となる。例えば、ある程度人気にあるコンテンツを、一部のキャッシュサーバがキャッシュしていた場合は、他のキャッシュサーバは、同じコンテンツをキャッシュしないようにする制御が考えられる。一方で、人気が非常に高いコンテンツについては、負荷分散の意味で、複数のキャッシュサーバに配置した方がよい場合がある。

また、非特許文献１には、複数のキャッシュサーバが連携するＣＲＩＳＰ（Ｃａｃｈｉｎｇ ａｎｄ Ｒｅｐｌｉｃａｔｉｏｎ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｅｒｆｏｒｍａｎｃｅ）に関する技術が記載されている。

Ｓｙａｍ Ｇａｄｄｅ、Ｍｉｃｈａｅｌ Ｒａｂｉｎｏｖｉｃｈ、Ｊｅｆｆ Ｃｈａｓｅ、「Ｒｅｄｕｃｅ， Ｒｅｕｓｅ， Ｒｅｃｙｃｌｅ： Ａｎ Ａｐｐｒｏａｃｈ ｔｏ Ｂｕｉｌｄｉｎｇ Ｌａｒｇｅ Ｉｎｔｅｒｎｅｔ Ｃａｃｈｅｓ」、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ， １９９７．， Ｔｈｅ Ｓｉｘｔｈ Ｗｏｒｋｓｈｏｐ ｏｎ Ｈｏｔ Ｔｏｐｉｃｓ ｉｎ、１９９７年５月、ｐ．９３−９８

図１７に示すキャッシュサーバ３００’同士を効率よく連携させることができるようなコンテンツ配置を実現しようとする場合、管理サーバ４００は、各キャッシュサーバ３００’が保持するコンテンツの情報や、各コンテンツへのアクセス情報を、各キャッシュサーバ３００’から収集して、最適な配置となるように、各キャッシュサーバ３００’を制御しなければならない。

しかしながら、管理サーバ４００がコンテンツの配置を一元的に制御する方法の場合には、コンテンツの種類や、キャッシュサーバの数が多くなると、キャッシュサーバと交換すべき情報量や、最適な配置を計算するための計算量が大きくなる。そのため、管理サーバ４００では処理しきれなくなる問題がある。このような状態となったとき、各キャッシュサーバが、管理サーバ４００に依存した処理が多いほど、正常動作を継続できずシステムとして破綻する懸念がある。

本発明の目的は、上述した課題を解決するキャッシュシステム、キャッシュ方法、及びキャッシュサーバを提供することにある。

上記課題を解決するために、本発明の第１の態様に係わるキャッシュシステムによると、オリジンサーバと、端末から要求されたコンテンツを、オリジンサーバの代わりに配信する複数のキャッシュサーバとを備え、キャッシュサーバは、端末から要求されたコンテンツを保持していない場合に、前記コンテンツを保持する他のキャッシュサーバから取得して端末に配信するにあたり、他のキャッシュサーバとコンテンツを送受信することによる負荷を示す指標に基づいて、コンテンツの複製の制御行う。

本発明の第２の態様に係わるキャッシュ方法によると、オリジンサーバと、端末から要求されたコンテンツを、オリジンサーバの代わりに配信する複数のキャッシュサーバとを備えるキャッシュシステムにおけるキャッシュ方法であって、キャッシュサーバは、端末から要求されたコンテンツを保持していない場合に、前記コンテンツを保持する他のキャッシュサーバから取得して端末に配信するにあたり、他のキャッシュサーバとコンテンツを送受信することによる負荷を示す指標に基づいて、コンテンツの複製の制御行う。

本発明の第３の態様に係わるキャッシュサーバよると、端末から要求されたコンテンツを、オリジンサーバの代わりに配信するキャッシュサーバであって、端末から要求されたコンテンツを保持していない場合に、当該コンテンツを保持する他のキャッシュサーバから取得して端末に配信するにあたり、他のキャッシュサーバとコンテンツを送受信することによる負荷を示す指標に基づいて、コンテンツの複製の制御行う。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となり得る。

以上の説明から明らかなように、この発明に係わるキャッシュシステムによれば、良好なキャッシュヒット率が得られる分散キャッシュシステムを提供することができる。

本発明の第１実施形態に係る分散キャッシュシステムの一例を示す図である。 本発明の第１実施形態に係るキャッシュサーバのブロック構成の一例を示す図である。 本発明の第１実施形態に係るキャッシュサーバが複製決定及び複製指示する処理の流れを示すフローチャートである。 本発明の第１実施形態に係るキャッシュサーバが端末からのコンテンツ要求を受信した際の処理の流れを示すフローチャートである。 本発明の第１実施形態に係る端末、及びキャッシュサーバの動作シーケンスの一例を示す図である。 本発明の第２実施形態に係るキャッシュサーバのブロック構成の一例を示す図である。 本発明の第２実施形態に係る端末、及びキャッシュサーバの動作シーケンスの一例を示す図である。 キャッシュサーバのブロック構成の一例を示す図である。 本発明の第３実施形態に係わるキャッシュサーバが端末からのコンテンツ要求を受信した際の処理の流れを示すフローチャートである。 本発明の第３実施形態に係わる端末、及びキャッシュサーバの動作シーケンスの一例を示す図である。 本発明の第４実施形態に係る分散キャッシュシステムの一例を示す図である。 本発明の第４実施形態に係るキャッシュサーバのブロック構成の一例を示す図である。 本発明の第５実施形態に係るキャッシュサーバのブロック構成の一例を示す図である。 キャッシュシステムの一例を示す図である。 端末、キャッシュサーバ、及びオリジンサーバの動作シーケンスの一例を示す図である。 キャッシュサーバ間連携しない分散キャッシュシステムの一例を示す図である。 キャッシュサーバ間連携可能な分散キャッシュシステムの一例を示す図である。 キャッシュサーバ間連携による効果を示すグラフである。

以下、発明の実施形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

＜第1実施形態＞
図１は、第１実施形態に係る分散キャッシュシステムの一例を示す。第１実施形態の分散キャッシュシステムは、ネットワーク１、複数のネットワーク２ａ、ｂ、ｃ、・・・（以下、ネットワーク２と総称する。）、複数の端末１００ａ、ｂ、ｃ、・・・（以下、端末１００と総称する。）、オリジンサーバ２００、及び複数のキャッシュサーバ３０１ａ、ｂ、ｃ、・・・（以下、キャッシュサーバ３０１と総称する。）を備える。

キャッシュサーバ３０１は、ネットワーク１を介して、オリジンサーバ２００、及び他のキャッシュサーバ３０１と通信接続される。また、キャッシュサーバ３０１は、ネットワーク２を介して、端末１００と通信接続される。

図２は、キャッシュサーバ３０１のブロック構成の一例を示す。キャッシュサーバ３０１は、配信部３１０、連携部３１１、複製決定部３１２、及び記憶装置３２０を備える。
以下、各構成要素の機能及び動作を説明する。

配信部３１０は、端末１００からコンテンツ要求を受信すると、要求されたコンテンツが記憶装置３２０にキャッシュとして記録されているか否かを確認する。そして、要求されたコンテンツが記憶装置３２０に記録されている場合、配信部３１０は、そのコンテンツを、端末１００に配信する。一方、要求されたコンテンツが記憶装置３２０に記録されていなかった場合、連携部３１１に、キャッシュサーバ間連携により、他のキャッシュサーバ３０１からコンテンツを取得することを要求する。その結果、他のキャッシュサーバ３０１からの対象のコンテンツが得られた場合は、これを端末１００に配信する。他のキャッシュサーバ３０１から対象のコンテンツが得られなかった場合は、オリジンサーバ２００に対し対象のコンテンツを要求し、応答されたコンテンツを端末１００に配信する。
配信部３１０はさらに、オリジンサーバ２００に対して同一のコンテンツを所定の回数要求したこと等を条件にオリジンサーバから得られたコンテンツを記憶装置３２０にキャッシュとして保持する。

配信部３１０はまた、端末１００からコンテンツへのアクセス数等の情報を含んだコンテンツ情報を、記憶装置３２０に記録する。コンテンツ情報には、他にもコンテンツの識別子（ＵＲＬ、又はシステムが割り当てた識別子）が含まれ、コンテンツ識別子をキー情報としてコンテンツの情報が参照できる。コンテンツ情報には、他にも、サイズや、メディアのタイプ等、他の情報を含むこととしてもよい。

連携部３１１は、配信部３１０の要求に応じて、他のキャッシュサーバが、端末１００から要求されたコンテンツを保持するキャッシュサーバ３０１を探す。

ここで、端末１００から要求されたコンテンツを保持するキャッシュサーバ３０１を探すにあたり、連携候補とするキャッシュサーバ３０１群のＩＰアドレス等、アクセスする際に必要な情報が事前に設定されていることを想定する。

キャッシュサーバ３０１は、連携候補とするキャッシュサーバ群の中から、近い順に、又はランダムに、対象のコンテンツを要求する。その結果、対象のコンテンツを保持するキャッシュサーバ３０１があった場合は、前記キャッシュサーバ３０１から対象のコンテンツを取得し、これを配信部３１０を介して端末１００に配信する。

上記の説明では、連携候補のキャッシュサーバに順次問い合わせるものとしたが、他の方法を採用することもできる。例えば、同一局舎内に連携候補のキャッシュサーバが配備されているケースが考えられる。その場合、ブロードキャストやマルチキャスト等の複数のキャッシュサーバに同報可能な手段により、対象のコンテンツを問い合わせ、対象のコンテンツを保持している旨を示す応答を返したキャッシュサーバから対象のコンテンツを取得するようにしてもよい。なお、連携候補のキャッシュサーバの数が多い場合、順次問合せ方法では、対象のコンテンツを発見するまでに長い時間を要してしまう。よって、連携候補とするキャッシュサーバを、システム中の一部のキャッシュサーバに限定することとしてもよい。

連携部３１１は、他のキャッシュサーバ３０１から任意のコンテンツを要求された場合で、要求対象のコンテンツを記憶装置３２０に保持していた場合は、対象のコンテンツを要求元のキャッシュサーバ３０１に応答する。この際、連携部３１１は、他のキャッシュサーバからアクセス数をコンテンツ情報の一つとして記憶装置３２０に記録する。

また、連携部３１１は、コンテンツの複製をコンテンツの識別子と共に複製決定部３１２から通知され、その後、他のキャッシュサーバからコンテンツに対するコンテンツ要求があった場合、コンテンツの応答にコンテンツの複製を指示する情報を格納する。このようにして、コンテンツ要求元のキャッシュサーバに対してコンテンツの複製を指示する。ここでは、コンテンツ応答に、コンテンツの複製を指示する情報を格納するとしたが、他の信号でコンテンツの複製を指示するようにしても構わない。

連携部３１１はまた、コンテンツ応答に、コンテンツの複製を指示する情報が格納されていた場合は、受信したコンテンツをキャッシュとして記憶装置３２０に保存する。コンテンツ応答とは他の信号でコンテンツの複製を指示された場合も、複製対象のコンテンツを受信した際に、そのコンテンツをキャッシュとして記憶装置３２０に保存する。

連携部３１１は、他のキャッシュサーバにコンテンツを要求する際に、キャッシュサーバ３０１の記憶装置３２０の空き容量や、負荷を示す情報とを、要求に格納してもよい。ここで、負荷を示す情報とは、例えば、ＣＰＵ使用率、通信インタフェースの使用率、他のキャッシュサーバとのコンテンツ送受信に関わるトラヒック量、同時接続数等の情報である。また、コンテンツの複製を指示する側のキャッシュサーバ３０１の連携部３１１は、コンテンツ要求側のキャッシュサーバの記憶装置３２０の空き容量や負荷を示す情報に基づいて、コンテンツの複製の指示対象とするキャッシュサーバを選択するようにしてもよい。

複製決定部３１２は、キャッシュサーバの通信インタフェースに関する情報を監視している。そして、キャッシュサーバ間連携により同時に送受信しているコンテンツの数、キャッシュサーバ間連携による合計帯域のいずれかが、閾値を超えた場合、キャッシュサーバ間連携を使用しすぎているとみなす。そして、記憶装置３２０に記録されたコンテンツ情報を参照し、キャッシュサーバ間連携の負荷に寄与している１又は複数のコンテンツを決定する。

閾値は、キャッシュサーバのＣＰＵの性能や、通信インタフェースの性能に依存する値で、事前に設定しておくことができる。さらに、キャッシュサーバ全体の同時コンテンツ送受信数や、配信帯域の合計、ＣＰＵ負荷率等のように動的に変わる情報に基づき、閾値を補正することとしてもよい。

また、キャッシュサーバ間連携の負荷に寄与していることを判定する際の指標としては、他のキャッシュサーバからのアクセス数が使用できる。また、コンテンツのサイズを、アクセス数に掛けた値を指標とする等、コンテンツのサイズを考慮した指標としてもよい。さらに、他の要素を考慮して、キャッシュサーバ間連携の負荷に寄与していることを判定する指標としてもよい。

複製決定部３１２は、キャッシュサーバ間連携の負荷に寄与しているコンテンツを決定すると、該当する１又は複数のコンテンツ識別子と共に、他のキャッシュサーバに対して複製を実施させることを決定したことを意味する情報を、連携部３１１に通知する。

記憶装置３２０には、キャッシュされたコンテンツ、及びコンテンツ情報が記録される。

コンテンツ情報には、コンテンツの識別子、端末からのアクセス数、他のキャッシュサーバからのアクセス数が含まれる。その他にも、コンテンツのサイズや、メディアタイプといったコンテンツに係る情報を含むものとしても構わない。

以上説明した、配信部３１０、連携部３１１、複製決定部３１２は、その全てをソフトウェアで実装し、ＣＰＵ上で動作させることで実施できる。または、その一部又は全てをハードウェアで構成することも可能である。一方、記憶装置３２０は、半導体メモリ、ハードディスクドライブ等、情報を記録・読み出し可能な装置により構成できる。

次に、図３のフローチャートを用いて第1実施形態のキャッシュサーバ３０１が、キャッシュされたコンテンツの複製を決定し、他のキャッシュサーバにコンテンツの複製を指示する手順を説明する。

まず、ステップＳ２００で、定期的な契機、又は連携部３１１が、他キャッシュサーバからのコンテンツ要求を受信した契機で、複製決定部３１２における複製判定処理を開始する。

次に、ステップＳ２０１で、複製決定部３１２の機能について前に述べたとおり、キャッシュサーバ間連携により同時に送受信しているコンテンツの数や、キャッシュサーバ間連携による帯域等を参照して、コンテンツの複製をすべきか否かを決定する。

次に、ステップＳ２０２で、複製判定結果が評価され、複製する場合はステップＳ２０３が処理される（Ｓ２０２のＹ）、複製しない場合は処理を終了する（Ｓ２０２のＮ）。

ステップＳ２０３で、複製決定部３１２は、他のキャッシュサーバからのアクセス数等を評価指標として、複製対象とする１又は複数のコンテンツを決定する。

最後に、複製決定部３１２は、連携部３１１に対して、複製対象のコンテンツの識別子と共に、複製の実施を通知する（Ｓ２０４）。連携部３１１は、ここで通知されたコンテンツを他のキャッシュサーバから要求された際に、当該コンテンツの応答にコンテンツの複製を指示する情報を格納する等して、コンテンツの応答先となるキャッシュサーバにコンテンツの複製を指示し、処理を終了する。

次に、図４のフローチャートを用いて第１実施形態のキャッシュサーバ３０１が、端末１００からのコンテンツ要求を受信した際の処理の流れを説明する。

まず、配信部３１０は、端末１００からのコンテンツ要求を受信すると、記憶装置３２０を検索し、要求されたコンテンツを既にキャッシュとして保持しているか否か判定される（Ｓ３０１）。

ここで、キャッシュがあった場合は（Ｓ３０１のＹ）、配信部３１０は、記憶装置３２０から対象のコンテンツを読み出し、これを端末１００に配信し（Ｓ３１０）、処理を終了する。

一方、キャッシュがなかった場合（Ｓ３０１のＮ）、連携部３１１の機能により、対象のコンテンツを保持している他のキャッシュサーバを発見する処理を実施する。この方法については既に説明した通りである。

そして、対象のコンテンツを保持するキャッシュサーバがあった場合（Ｓ３０３のＹ）、連携部３１１は、そのコンテンツを保持するキャッシュサーバ３０１にコンテンツを要求し、応答されたコンテンツを配信部３１０を介して端末１００に配信する（Ｓ３０４）。このとき、コンテンツ応答に、コンテンツの複製を指示する情報が格納されていた場合は、ステップＳ３０５のＹに進み、ステップＳ３０６で、コンテンツは記憶装置３２０にキャッシュとして保持される。その後ステップＳ３０７で、記憶装置３２０のコンテンツ情報中のアクセス数等の情報が更新され、処理を終了する。

一方、コンテンツの複製指示がなかった場合（Ｓ３０５のＮ）、コンテンツは保持せず、ステップＳ３０７でコンテンツ情報の更新が行われ、処理が終了する。

ここで、ステップＳ３０３に戻り、対象のコンテンツを保持するキャッシュサーバがなかった場合（Ｓ３０３のＮ）を説明する。この場合、ステップＳ３０８で、配信部３１０はオリジンサーバに対し対象のコンテンツを要求し、オリジンサーバから応答されたコンテンツを端末１００に配信する。この際、当該コンテンツに対するアクセス数等の情報に基づき、記憶装置３２０に当該コンテンツをキャッシュとして保持するか否か判定される。キャッシュとして保持する場合（Ｓ３０９のＹ）、既に説明したステップＳ３０６以降の処理が処理される。一方、キャッシュとして保持しない場合（Ｓ３０９のＮ）、ステップＳ３０７のコンテンツ情報更新が実施され、処理が終了する。

図５は、端末１００ａ、及びキャッシュサーバ３０１ａ〜ｃの動作シーケンスの一例を示す。次に、キャッシュサーバ３０１ｃが、キャッシュサーバ３０１ａに対してコンテンツの複製を指示し、キャッシュサーバ３０１ａが、指示に従い、コンテンツをキャッシュとして保持するまでの処理の流れを、より具体的な例を用いて説明する。

ここでの説明にあたり、端末１００ａは、キャッシュサーバ３０１ａ配下に収容された端末であり、当該端末がコンテンツを要求するものとする。そして、要求されたコンテンツは、キャッシュサーバ３０１ｃで保持されているものと想定する。

はじめにステップＳ４００で、端末１００ａのコンテンツ要求をキャッシュサーバ３０１ａが受信する。キャッシュサーバ３０１ａは、要求されたコンテンツをキャッシュとして保持していなので、連携候補のキャッシュサーバのうち、キャッシュサーバ３０１ｂに対してコンテンツを要求する。しかし、キャッシュサーバ３０１ｂは、要求されたコンテンツを保持していないので、”コンテンツ無し”をキャッシュサーバ３０１ａに応答する（Ｓ４０１）。

キャッシュサーバ３０１ａは、次の候補であるキャッシュサーバ３０１ｃに対して、コンテンツを再度要求する（Ｓ４０２）。

このとき、キャッシュサーバ３０１ｃでは、複製決定部３１２の機能により、コンテンツを複製する決定がなされていたものとする。この状態で、ステップＳ４０２で、キャッシュサーバ３０１ｃがコンテンツを要求されると、キャッシュサーバ３０１ｃの連携部３１１は、要求されたコンテンツを応答する際に、その応答にコンテンツの複製を指示する情報を格納する（Ｓ４０４）。

キャッシュサーバ３０１ａは、コンテンツ複製を指示する情報が格納されたコンテンツを受信すると、これを端末１００ａに配信すると共に（Ｓ４０５）、記憶装置３２０にキャッシュとして保持する（Ｓ４０６）。

以上説明したとおり、第１実施形態では、各キャッシュサーバが内部的に得られる情報を使って、キャッシュサーバ間連携による負荷が過剰になったことを判定する。また、キャッシュサーバ間連携による負荷が過剰となっている主たる要因のコンテンツを特定し、当該コンテンツの複製を増やすよう動作する。このように、第１実施形態の分散キャッシュシステムは、管理サーバがない場合でも、キャッシュサーバ間連携を過不足なく使用することができる。また、適切なコンテンツ配置を算出するための通信負荷、及び処理負荷なく、キャッシュサーバ間連携による良好なキャッシュヒット率が得られる。

＜第２実施形態＞
次に、第２実施形態について図面を参照して詳細に説明する。第２実施形態では、キャッシュサーバ３０２以外の構成は第1実施形態と同じとなるため、ここでは、キャッシュシステム全体の図は省略する。

第２実施形態のキャッシュサーバ３０２は、図６に示すように、第1実施形態のキャッシュサーバ３０１とほぼ同じだが、連携部３１３、複製決定部３１４の機能が、第1実施形態の連携部３１１、複製決定部３１２と異なる。よってここでは、連携部３１３、複製決定部３１４の機能に着目した説明を行う。

複製決定部３１４は、第1実施形態の複製決定部３１２とほぼ同じ機能を備えるが、コンテンツの複製を決定した際に、複製対象となるコンテンツを決定すると共に、複製数も決定する。より具体的に説明すると、連携部３１３対しコンテンツの複製を指示するよう通知する際に、コンテンツ識別子に加え、複製数の情報も含める。

複製決定部３１４は、複製数を決定する上で、キャッシュサーバ間連携によるアクセス数や同時接続数を参照する。これらの値が閾値を大きく超えた場合等、早急にシステム中のコンテンツの複製を増やす必要が生じた場合、緊急の度合いに応じて複製数を大きな値とすることができる。

連携部３１３は、第1実施形態の連携部３１１とほぼ同じ機能を備える。また、連携部３１３は、複製決定部３１４から通知された複製数、又は他のキャッシュサーバからのコンテンツ応答としてコンテンツ複製の指示を示す情報と共に格納された複製数のいずれかを受け取る。そして、受け取った複製数に基づき、他のキャッシュサーバが、複製対象となるコンテンツを要求してきた場合には、そのコンテンツの複製を指示する。また、必要に応じて複製数情報も格納することで、さらに他のキャッシュサーバ３０２にもコンテンツの複製の指示を依頼する。

以上説明した、連携部３１３、複製決定部３１４は、その全てをソフトウェアで実装し、ＣＰＵ上で動作させることで実施できる。または、その一部又は全てをハードウェアで構成することも可能である。

第２実施形態のキャッシュサーバ３０２の処理の流れは、図３、図４で示した第1実施形態のキャッシュサーバ３０１の処理の流れとほぼ同じである。ただし、キャッシュサーバ３０２は、複製指示を決定する際に、複製数も同時に決定する点が図３に示す処理と異なる。また、キャッシュサーバ３０２は、通知された複製数に応じて、他のキャッシュサーバから要求されたコンテンツが複製対象だった場合、コンテンツを応答すると共にコンテンツの複製を指示する情報と共に、複製数情報を必要に応じて格納する点も異なる。

また、キャッシュサーバ３０２の処理は、キャッシュサーバ間連携により他のキャッシュサーバから応答されたコンテンツに複製を指示する情報が含まれているか否か判定する際に、複製数情報の存在も確認する点が図４に示す処理と異なる。そして、複製数情報が格納されていた場合は、これを取得し、これをコンテンツ識別子と共に記録しておく。ここで記録された複製数情報は、上記したように、複製数情報に基づいて他のキャッシュサーバにコンテンツの複製を指示する際に参照される。

第２実施形態の処理の流れをより明確にするため、図７のシーケンス図を用いて第２実施形態の分散キャッシュシステムの処理の流れを説明する。

まず、ステップＳ５００でキャッシュサーバ間連携による通信量が過剰気味となっている状況を想定する。過剰か否かの判定は、先に説明したとおり、例えば、キャッシュサーバ間連携によるコンテンツの同時配信数や通信帯域が、予め決めたおいた閾値を大きく超える場合が考えられる。ただし、同時配信数や、帯域の増加の早さ等、他の指標により過剰であること、又は過剰になりそうなことを判定してもよい。

この状態で、端末１００は、キャッシュサーバ３０２ａにコンテンツ要求を実施する（Ｓ５０１）。

キャッシュサーバ３０２ａは、要求されたコンテンツを保持していない場合、そのコンテンツを保持するキャッシュサーバ（ここでは、キャッシュサーバ３０２ｂとする。コンテンツを保持するキャッシュサーバを順次的に探す手順はここでは関係ないので省略する。）に対してコンテンツの要求を実施し、要求先のキャッシュサーバ３０２ｂは、要求されたコンテンツをキャッシュサーバ３０２ａに応答する。このとき、キャッシュサーバ３０２ｂは、キャッシュサーバ間連携が過剰に使用されていることから、コンテンツの複製の指示と共に、複製指示を他のキャッシュサーバに依頼するために、複製数をコンテンツ応答に格納する。そして、これをキャッシュサーバ３０２ａに通知する（Ｓ５０２）。なお、ここでは算出された複製数が８の場合で、かつ、キャッシュサーバ３０２ａに、８つの内の４つ分の複製指示を依頼することを想定している。４つ分のコンテンツ複製を依頼した後、キャッシュサーバ３０２ｂが当該コンテンツの複製指示をすべき数は、キャッシュサーバ３０２ａに１つ複製が作られることも考慮し、３（＝８−４−１）つとなる。

キャッシュサーバ３０２ａが、コンテンツ応答を受信すると、これを端末１００に配信する（Ｓ５０３）。それと共に、複製指示に従い、キャッシュサーバ３０２ａは、受信したコンテンツをキャッシュとして保持する（Ｓ５０４）。

キャッシュサーバ３０２ａはまた、キャッシュの複製数（＝４）として複製の指示を依頼されたことで、他のキャッシュサーバにさらに４つ分のコンテンツの複製を指示するための契機を待つ。すなわち、他のキャッシュサーバから、複製対象のコンテンツを要求される契機を待つ。

ここで、ステップＳ５０５のように、キャッシュサーバ３０２ｃから複製対象のコンテンツが要求された場合には、複製指示を示す情報と、複製数を格納したコンテンツ応答をキャッシュサーバ３０２ｃに送信する。ステップＳ５０５の例では、キャッシュサーバ３０２ａは、複製数に２を設定したものと想定する。この場合、キャッシュサーバ３０２ａが複製対象のコンテンツに関して、複製指示すべき残り数は１となる（＝４−複製を依頼した数２ −キャッシュサーバ３０２ｃへの複製１）。

以上説明したとおり、第２実施形態では、複製の実施の決定に加え、複製数を決定し、決定された複製数に応じて、他のキャッシュサーバにも複製指示を依頼するよう構成した。
このようにして、キャッシュサーバ間連携を過剰に使用している場合や、過剰な使用が予測される場合にも、高速にコンテンツの複製数を増やすことができ、システムが破綻する懸念を軽減できる。

＜第３実施形態＞
次に、第３実施形態について図面を参照して詳細に説明する。第３実施形態では、キャッシュサーバ３０３以外の構成は第1実施形態と同じとなるため、ここでは、キャッシュシステム全体の図は省略する。

第３実施形態のキャッシュサーバ３０３は、図８に示すように、第1実施形態のキャッシュサーバ３０１とほぼ同じだが、連携部３１５の機能が、第1実施形態の連携部３１１と異なる。よってここでは、連携部３１５の機能に着目した説明を行う。

連携部３１５は、キャッシュサーバ間連携により、他のキャッシュサーバにコンテンツを要求する。そして、これが応答された際に、複製決定部３１２の機能により、コンテンツの複製が必要で、かつ、応答されたコンテンツが複製対象であった場合には、そのコンテンツをキャッシュとして記憶装置３２０に保持する点が第1実施形態の連携部３１１と異なる。それ以外は第1実施形態の連携部３１１と同様の機能を備える。

即ち、第1実施形態の連携部３１１は、複製が必要なコンテンツを要求された場合、コンテンツを要求された側のキャッシュサーバが、要求した側のキャッシュサーバに対してコンテンツの複製を指示する。これに対し、第３実施形態の連携部３１５は、コンテンツ要求元側で、コンテンツの複製の実施の必要性と、複製対象とするコンテンツを決定する点が異なっている。

以上説明した、連携部３１５は、その全てをソフトウェアで実装し、ＣＰＵ上で動作させることで実施できる。または、その一部又は全てをハードウェアで構成することも可能である。

次に、図９のフローチャートを用いて第３実施形態のキャッシュサーバ３０３が、キャッシュサーバ間連携により、他のキャッシュサーバから配信されるコンテンツを受信した場合に、必要に応じてそのコンテンツをキャッシュする手順を説明する。

まず、ステップＳ６００で、連携部３１５が他のキャッシュサーバからコンテンツを受信した契機に、複製決定部３１２における複製判定処理を開始する。

次に、ステップＳ６０１で、複製決定部３１２の機能の説明の箇所に記述したとおり、キャッシュサーバ間連携により同時に送受信しているコンテンツの数や、キャッシュサーバ間連携による帯域等を参照して、コンテンツの複製をすべきか否かを決定する。

次に、ステップＳ６０２で、複製判定結果が評価され、複製する場合はステップＳ６０３が処理される（Ｓ６０２のＹ）、複製しない場合は処理を終了する（Ｓ６０２のＮ）。

ステップＳ６０３で、複製決定部３１２は、他のキャッシュサーバからのアクセス数等を評価指標として、複製対象とする１又は複数のコンテンツを決定する。

次に、連携部３１５は、他のキャッシュサーバから受信したコンテンツが、ステップＳ６０３で決定した複製対象のコンテンツに含まれているか否か判定する（Ｓ６０４）。そして、含まれている場合はＹに進みステップＳ６０５で当該コンテンツは、記憶装置３２０にキャッシュとして保持される。一方、ステップＳ６０４の判定で、受信したコンテンツが複製対象のコンテンツに含まれていないと判定された場合は、Ｎに進みキャッシュとして保持せず処理を終了する。

キャッシュサーバ３０３が端末１００からコンテンツ要求を受信した際の処理の流れは、図４に示すステップＳ３０５からステップＳ３０６までの処理を、図９に示すステップＳ６００からステップＳ６０５までの処理で置き換えたものとなる。

次に、図１０のシーケンス図を用いて、キャッシュサーバ３０３ａが、端末１００から要求されたコンテンツをキャッシュサーバ３０３ｃから取得し、そのコンテンツを複製判定結果に基づきキャッシュとして保持するまでの処理の流れを説明する。

ここでの説明にあたり、端末１００ａは、キャッシュサーバ３０３ａ配下に収容された端末であり、当該端末がコンテンツを要求するものとする。そして、要求されたコンテンツは、キャッシュサーバ３０３ａで保持されておらず、キャッシュサーバ３０１ｃで保持されている状況を想定する。

はじめにステップＳ７００で、端末１００ａのコンテンツ要求をキャッシュサーバ３０３ａが受信する。キャッシュサーバ３０３ａは、要求されたコンテンツをキャッシュとして保持していなので、連携候補のキャッシュサーバから選ばれたキャッシュサーバ３０３ｂに対してコンテンツを要求する。しかし、キャッシュサーバ３０３ｂは、要求されたコンテンツを保持していないので、”コンテンツ無し”をキャッシュサーバ３０３ａに応答する（Ｓ７０１）。

そこでキャッシュサーバ３０３ａは、次の候補であるキャッシュサーバ３０３ｃに対して、コンテンツを要求する（Ｓ７０２）。

キャッシュサーバ３０３ｃは、ステップＳ７０２でコンテンツ要求を受信すると、要求されたコンテンツを保持しているため、当該コンテンツをキャッシュサーバ３０３ａに応答する（Ｓ７０３）。

キャッシュサーバ３０３ａは、コンテンツ応答を受信すると、これを端末１００ａへと応答すると共に（Ｓ７０４）、図９に示すフローチャートに従い、受信したコンテンツをキャッシュすべきか否かの判定を行う。そして、キャッシュすべきと判断された場合は、当該コンテンツをキャッシュとして保持する（Ｓ７０４）。

以上説明したとおり、第３実施形態では、キャッシュサーバがキャッシュサーバ間連携によりコンテンツを他のキャッシュサーバから受信した際に、コンテンツを受信したキャッシュサーバ側がキャッシュすべきか否かの判定を行う構成とした。このようにして、コンテンツ応答する側のキャッシュサーバは、コンテンツ応答に複製を指示する情報を格納する必要がなくなる。このため、キャッシュサーバ間でコンテンツをやり取りするプロトコルとして、ＨＴＴＰ等、既存のプロトコルを再利用する場合において、既存のプロトコルへの変更が不要となるため、本発明に係わるキャッシュシステムの適用が容易となる。

＜第４実施形態＞
次に、第４実施形態について図面を参照して詳細に説明する。第４実施形態の分散キャッシュシステムの全体図を図１１に示す。ここで名称や、番号が同じ装置やネットワークは、第1実施形態の分散キャッシュシステムの全体図（図１）と同じなので、ここでは説明を省略する。

本発明の第1実施形態に係わる分散キャッシュシステムと異なるのは、キャッシュサーバ３０４と、管理サーバ４０１である。

第４実施形態のキャッシュサーバ３０４は、図１２に示すように、第1実施形態のキャッシュサーバ３０１に加え、さらに情報交換部３１６を備える。また、連携部３１７の機能が第1実施形態の連携部３１１と少し異なる。その他の機能ブロックは第1実施形態のキャッシュサーバ３０１の構成と同じなので説明を省略する。

情報交換部３１６は、記憶装置３２０に保持されたコンテンツのリストを管理サーバ４０１に通知する機能を有すると共に、管理サーバ４０１から他のキャッシュサーバ３０４が保持するコンテンツのリストを取得し、これを記憶装置３２０に記録する。この際、記憶装置３２０には、キャッシュサーバ３０４の識別子と、当該キャッシュサーバが保持するコンテンツのリストが対応付けられて記録される。

情報交換部３１６が、コンテンツリストを管理サーバに通知するタイミングや、他のキャッシュサーバのコンテンツリストを取得する契機については、例えば、定期的にコンテンツリストの一部又は全てを通知、及び取得するようにしても構わない。また、記憶装置３２０にコンテンツがキャッシュとして保持されたタイミング、又は記憶装置３２０の容量が残り少なくなったこと等を理由として、キャッシュが削除されたタイミングで保持するようにしてもよい。または、削除されたコンテンツの情報を管理サーバ４０１に通知することとしてもよい。さらに、端末１００からコンテンツを要求された契機に、要求されたコンテンツの他のキャッシュサーバの保持状況を、管理サーバ４０１から取得することとしてもよい。

連携部３１７は、本発明の第1実施形態に係わる連携部３１１とほぼ同じ機能を有する。また、連携部３１７は、コンテンツの要求先のキャッシュサーバを決定する際、記憶装置３２０に記録された他のキャッシュサーバのコンテンツリストを参照する。そして、要求対象のコンテンツを保持するキャッシュサーバを特定した上で、特定されたキャッシュサーバのうちのいずれかをコンテンツ要求先として決定する。これにより、順次的な方法で要求対象のコンテンツを保持するキャッシュサーバを発見する必要はなくなるため、より効率的なキャッシュサーバ間連携が可能となる。

管理サーバ４０１は、キャッシュサーバ３０４から通知されたコンテンツリストを保持する。また、キャッシュサーバ３０４からの要求に応じて、キャッシュシステム中のキャッシュサーバ３０４のコンテンツリストを応答する。情報交換量を削減するため、応答するコンテンツリストを、コンテンツリストを要求してきたキャッシュサーバ３０４の周辺のキャッシュサーバについてのコンテンツリストに限定する等、応答する情報を一部に限定することとしてもよい。

本発明の第４実施形態に係わるキャッシュシステムは、管理サーバ４０１を介して、コンテンツリストを共有することで、より円滑なキャッシュサーバ間連携が可能となるが、一方で、管理サーバ４０１が必要となり、管理サーバ４０１とキャッシュサーバ３０４との間での通信が発生する。しかしこの場合でも、背景技術の問題として挙げた管理サーバの計算負荷、及び通信負荷は、ここでは大きな問題とならない。その理由は、第４実施形態の管理サーバ４０１の備える機能が、限定的な情報を仲介する機能に絞られているためである。より具体的には、情報交換すべき情報は、コンテンツリストに限定されており、また、管理サーバ４０１では、各キャッシュサーバへのコンテンツ配置の計算と、計算されたコンテンツ配置にするためにキャッシュサーバを制御する必要がないためである。

以上説明した、情報交換部３１６、連携部３１７は、その全てをソフトウェアで実装し、ＣＰＵ上で動作させることで実施できる。または、その一部又は全てをハードウェアで構成することも可能である。

管理サーバ４０１は、上述した機能をソフトウェアで実装し、ＣＰＵや、記憶装置を搭載したサーバ上で実施できる

本発明の第４実施形態に係わるキャッシュサーバ３０４の動作の流れは、図４で既に示した、第1実施形態のキャッシュサーバ３０１が、端末１００からコンテンツ要求を受信した際の処理とほぼ同じとなる。異なるのは、ステップＳ３０２でコンテンツの要求先とするキャッシュサーバを発見に際して、管理サーバ４０１から取得したコンテンツリストを参照する点だけである。

第４実施形態に係わる分散キャッシュシステムでは、第1実施形態の分散キャッシュシステムに対して、管理サーバ４０１をさらに備える。キャッシュサーバ３０４は、管理サーバ４０１とコンテンツリストを交換するための情報交換部３１６を備える。連携部３１７は、情報交換部３１６により管理サーバ４０１から得た他のキャッシュサーバのコンテンツリストを利用して、コンテンツ要求先とするキャッシュサーバを決定する。この第1実施形態と第４実施形態の差分となる要素は、同じように、第２実施形態、第３実施形態の構成に対しても、第1実施形態と同様に適用できる。

以上説明したとおり、第４実施形態では、キャッシュサーバは、他のキャッシュサーバからコンテンツを取得する際に、管理サーバにより得られたコンテンツリストを使って、コンテンツの要求先を決定することで、より効率的なキャッシュサーバ間連携を実現できる。

＜第５実施形態＞
次に、第５実施形態について図面を参照して詳細に説明する。第５実施形態では、第４実施形態の管理サーバ４０１の機能を、各キャッシュサーバ３０５が分担する構成となる。よって、第５実施形態の分散キャッシュシステムでは管理サーバ４０１が不要となる。このため、第５実施形態の分散キャッシュシステムの構成は、第1実施形態と同様となるので、図は省略する。

第５実施形態のキャッシュサーバ３０５は、図１３に示すように、第４実施形態のキャッシュサーバ３０４に加え、さらに管理サーバ機能３１８を備える。

管理サーバ機能３１８は、第４実施形態における管理サーバ４０１が備える機能と同様に、他のキャッシュサーバ３０５の情報交換部３１６とコンテンツリストの情報を交換する。ただし、全てのコンテンツについてのリストを管理するのではなく一部のコンテンツを管理する点が、第４実施形態における管理サーバ４０１と異なっている。各キャッシュサーバ３０５の管理サーバ機能３１８が管理対象とするコンテンツを決定する方法は後述する。

情報交換部３１６’は、基本的に第４実施形態の情報交換部３１６と同じ機能を備える。そして、情報交換部３１６’は、コンテンツリストの通知先、及び取得先とするのが管理サーバ４０１ではなく、他のキャッシュサーバ３０５の管理サーバ機能３１８である点が異なる。また、コンテンツ毎にコンテンツ通知先・取得先とするキャッシュサーバを決定する点が異なる。

情報交換部３１６’が、コンテンツ毎にコンテンツリストの通知先・取得先とするキャッシュサーバを決定する方法の一例を以下に示す。

ここで、各キャッシュサーバには０から連続した値となるキャッシュサーバインデックス（ＣａｃｈｅＳｅｒｖｅｒＩｎｄｅｘ）が割当てられている。そして、キャッシュサーバインデックスと分散キャッシュシステム中のキャッシュサーバの数（ＮｕｍＯｆＣａｃｈｅＳｅｒｖｅｒ）が、各キャッシュサーバで共有されているものとする。

このとき、情報交換部３１６’は、コンテンツの識別子がＣｏｎｔｅｎｔＩＤであるコンテンツをキャッシュとして保持した契機、削除した契機、又は定期的な契機で、そのコンテンツの保持状態を通知するキャッシュサーバを決定する。その際、式（２）に示す計算によりキャッシュサーバインデックスを求める。そして、得られたキャッシュサーバインデックスが割り当てられたキャッシュサーバをコンテンツのコンテンツリスト通知先として決定する。

ここで、Ｈａｓｈ（ｘ）は、ＭＤ５や、ＳＨＡ１等のハッシュ関数によりｘのハッシュ値を算出する処理を示す。また、ｘ％ｙは、ｘをｙで割った際の剰余を意味する。

あるコンテンツを保持しているキャッシュサーバの情報を取得するため、コンテンツのコンテンツリストを管理するキャッシュサーバを決定する場合にも、式２を使用する。即ち、式２により得られたキャッシュサーバインデックスが割り当てられたキャッシュサーバをコンテンツリスト取得先とする。

上に示した、キャッシュリストの分担方法は、あくまで一例であり、他の方法でコンテンツリストを分担管理こととしても構わない。

以上説明した、情報交換部３１６’、管理サーバ機能３１８は、その全てをソフトウェアで実装し、ＣＰＵ上で動作させることで実施できる。または、その一部又は全てをハードウェアで構成することも可能である。

以上説明したとおり、第５実施形態では、管理サーバの機能を、各キャッシュサーバで分担管理することで、管理サーバがない場合でも、効率的なキャッシュサーバ間連携を実現できる。

第1実施形態に係わるキャッシュシステムは、各キャッシュサーバが内部的に得られる情報を使って、キャッシュサーバ間連携による負荷が過剰になったことを判定し、キャッシュサーバ間連携による負荷が過剰となっている主たる要因のコンテンツを特定し、そのコンテンツの複製を増やす。これにより、管理サーバがない場合でも、キャッシュサーバ間連携を過不足なく使用することができる。そして、適切なコンテンツ配置を算出するための通信負荷、及び処理負荷なく、キャッシュサーバ間連携による良好なキャッシュヒット率が得られる分散キャッシュシステムを提供することができる。

第２実施形態に係わるキャッシュシステムによれば、複製の実施の決定に加え、複製数を決定し、決定された複製数に応じて、他のキャッシュサーバにも複製指示を依頼するよう構成した。このようにして、キャッシュサーバ間連携を過剰に使用している場合や、過剰な使用が予測される場合にも、高速にコンテンツの複製数を増やすことができ、システムが破綻する懸念を軽減できる。

第３実施形態係わるキャッシュシステムによれば、キャッシュサーバがキャッシュサーバ間連携によりコンテンツを他のキャッシュサーバから受信した際に、コンテンツを受信したキャッシュサーバ側がキャッシュすべきか否かの判定を行う構成とした。このようにして、コンテンツ応答する側のキャッシュサーバは、コンテンツ応答に複製を指示する情報を格納する必要がなくなる。
このため、キャッシュサーバ間でコンテンツをやり取りするプロトコルとして、ＨＴＴＰ等、既存のプロトコルを再利用する場合において、既存のプロトコルへの変更が不要となるため、本発明の適用が容易となる。

第４実施形態に係わるキャッシュシステムによれば、キャッシュサーバは、他のキャッシュサーバからコンテンツを取得する際に、管理サーバにより得られたコンテンツリストを使って、コンテンツの要求先を決定することで、より効率的なキャッシュサーバ間連携を実現できる。

第５実施形態に係わるキャッシュシステムによれば、管理サーバの機能を、各キャッシュサーバで分担管理することで、管理サーバがない場合でも、効率的なキャッシュサーバ間連携を実現できる。

本発明に係わる分散キャッシュシステムを、固定ＩＳＰのネットワーク、又はモバイルネットワークに適用することで、分散キャッシュシステムにおけるキャッシュサーバ間連携を活用した高いキャッシュヒット率を得ることができる。これにより、相互接続点（ＰＯＩ：Ｐｏｉｎｔ Ｏｆ Ｉｎｔｅｒｆａｃｅ）上のトラヒックを効果的に削減でき、ネットワークのオペレータはＯＰＥＸ（ＯＰｅｒａｔｉｏｎ ＥＸｐｅｎｓｅ）を削減できる。さらに、コンテンツの複製等の制御を分散処理できるようにしたことで、高いスケーラビリティと、高可用性が実現できる。

以上、本発明に係わるキャッシュシステムについて実施形態を用いて説明したが、本発明の技術的範囲は、上記実施形態に記載の範囲には限定されない。上記実施形態に、多様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本願は、２０１１年９月３０日に、日本に出願された特願２０１１−２１５８５０号に基づき優先権を主張し、その内容をここに援用する。

本発明に係わるキャッシュシステムによれば、管理サーバを必須とせず、個々のキャッシュサーバが持ちうる情報に基づき効果的なキャッシュサーバ間連携を実現し得るキャッシュシステム、キャッシュ方法、及びキャッシュサーバを提供することができる。

１ ネットワーク
２ ネットワーク
１００ 端末
２００ オリジンサーバ
３０１ キャッシュサーバ
３０２ キャッシュサーバ
３０３ キャッシュサーバ
３０４ キャッシュサーバ
３０５ キャッシュサーバ
３１０ 配信部
３１１ 連携部
３１２ 複製決定部
３１３ 連携部
３１４ 複製決定部
３１５ 連携部
３１６ 情報交換部
３１６’ 情報交換部
３１７ 連携部
３１８ 管理サーバ機能
３２０ 記憶装置
４０１ 管理サーバ

Claims (30)

1. オリジンサーバと、
   端末から要求されたコンテンツを、前記オリジンサーバの代わりに配信する複数のキャッシュサーバと
   を備え、
   前記キャッシュサーバは、
   前記端末から要求されたコンテンツを保持していない場合に、前記コンテンツを保持する他のキャッシュサーバから取得して前記端末に配信するにあたり、他のキャッシュサーバとコンテンツを送受信することによる負荷を示す指標に基づいて、コンテンツの複製の制御を行うキャッシュシステム。
2. 前記指標は、キャッシュサーバ間でのコンテンツ送受信に関わるトラヒック量、キャッシュサーバ間の同時セッション数、キャッシュサーバの通信インタフェース使用量、ＣＰＵ使用率の少なくともいずれかにより得られた指標である請求項１に記載のキャッシュシステム。
3. 前記キャッシュサーバは、コンテンツの複製を決定する際に、少なくとも、前記キャッシュサーバが保持するコンテンツへのアクセス数、コンテンツのサイズのいずれかに基づいて、複製対象とする１又は複数のコンテンツを決定する請求項１又は２に記載のキャッシュシステム。
4. 前記キャッシュサーバはコンテンツの複製の実施を決定し、複製対象とする１又は複数のコンテンツを決定した後で、前記キャッシュシステムを構成する他のキャッシュサーバから前記キャッシュサーバに対して、前記決定されたコンテンツのうちのいずれかのコンテンツが要求された場合、コンテンツの要求元となるキャッシュサーバに対し、前記コンテンツを応答すると共に、前記コンテンツをキャッシュとして保持するよう指示する請求項３に記載のキャッシュシステム。
5. 前記キャッシュサーバは、コンテンツの複製の実施を決定した際に、複製対象とする１又は複数のコンテンツを決定すると共に、コンテンツの複製数を決定し、
   前記キャッシュシステムを構成する他のキャッシュサーバから、前記キャッシュサーバに対して、前記決定されたコンテンツのうちのいずれかのコンテンツが要求された場合、コンテンツの要求元となるキャッシュサーバに対し、前記コンテンツを応答すると共に、前記コンテンツをキャッシュとして保持するよう指示する情報に加え、前記決定したコンテンツ複製数のうち、前記要求元のキャッシュサーバに複製の指示を依頼する数に設定した複製数を通知し、
   前記コンテンツの要求元のキャッシュサーバは、前記複製数を受信すると、複製数分の複製の指示を依頼されたものとして、複製数の分だけ、他のキャッシュサーバにコンテンツの複製を指示するか、又は他のキャッシュサーバに複製数を通知することで、コンテンツの複製の指示を依頼する請求項４に記載のキャッシュシステム。
6. 前記キャッシュサーバは、他のキャッシュサーバにコンテンツを要求する際に、前記要求に、前記キャッシュサーバの記憶容量の空き情報、ＣＰＵ使用状況、通信インタフェース使用量、他のキャッシュサーバとのコンテンツ送受信に関わるトラヒック量、同時接続数、の少なくともいずれかをキャッシュサーバ負荷情報として格納し、
   前記キャッシュサーバのコンテンツ要求を受信したキャッシュサーバは、前記コンテンツ要求から取得した前記キャッシュサーバ負荷情報に基づき、コンテンツ複製指示の対象とするキャッシュサーバを決定する請求項４に記載のキャッシュシステム。
7. 前記キャッシュサーバは、他のキャッシュサーバからコンテンツを取得した際に、取得したコンテンツが複製対象として決定したコンテンツに含まれていた場合は、前記コンテンツをキャッシュとして保持する請求項３に記載のキャッシュシステム。
8. 前記キャッシュサーバは、端末からコンテンツを要求された場合で、自キャッシュサーバが前記コンテンツを保持していなかった場合は、順次的な方法、又は同報的な方法により、前記要求されたコンテンツを保持しているキャッシュサーバを発見する請求項１又は２に記載のキャッシュシステム。
9. 前記キャッシュサーバは、自キャッシュサーバが保持するコンテンツ情報を管理サーバに通知し、
   前記キャッシュサーバが端末からコンテンツを要求された場合で、自キャッシュサーバが前記コンテンツを保持していなかった場合は、前記管理サーバから得られた情報に基づき、前記要求されたコンテンツを保持しているキャッシュサーバを発見する請求項１又は２に記載のキャッシュシステム。
10. 前記管理サーバに相当する機能を、各キャッシュサーバが分担し、各キャッシュサーバは、コンテンツの識別子に基づいて、コンテンツ毎にコンテンツの保有情報を管理を担当するキャッシュサーバを決定する請求項９に記載のキャッシュシステム。
11. オリジンサーバと、端末から要求されたコンテンツを、前記オリジンサーバの代わりに配信する複数のキャッシュサーバとを備えるキャッシュシステムにおけるキャッシュ方法であって、
    前記キャッシュサーバは、
    前記端末から要求されたコンテンツを保持していない場合に、前記コンテンツを保持する他のキャッシュサーバから取得して前記端末に配信するにあたり、他のキャッシュサーバとコンテンツを送受信することによる負荷を示す指標に基づいて、コンテンツの複製の制御を行う。
12. 前記指標は、キャッシュサーバ間でのコンテンツ送受信に関わるトラヒック量、キャッシュサーバ間の同時セッション数、キャッシュサーバの通信インタフェース使用量、ＣＰＵ使用率の少なくともいずれかにより得られた指標である請求項１１に記載のキャッシュ方法。
13. 前記キャッシュサーバは、コンテンツの複製を決定する際に、少なくとも、前記キャッシュサーバが保持するコンテンツへのアクセス数、コンテンツのサイズのいずれかに基づいて、複製対象とする１又は複数のコンテンツを決定する請求項１１又は１２に記載のキャッシュ方法。
14. 前記キャッシュサーバはコンテンツの複製の実施を決定し、複製対象とする１又は複数のコンテンツを決定した後で、前記キャッシュ方法を構成する他のキャッシュサーバから前記キャッシュサーバに対して、前記決定されたコンテンツのうちのいずれかのコンテンツが要求された場合、コンテンツの要求元となるキャッシュサーバに対し、前記コンテンツを応答すると共に、前記コンテンツをキャッシュとして保持するよう指示する請求項１３に記載のキャッシュ方法。
15. 前記キャッシュサーバは、コンテンツの複製の実施を決定した際に、複製対象とする１又は複数のコンテンツを決定すると共に、コンテンツの複製数を決定し、
    前記キャッシュ方法を構成する他のキャッシュサーバから、前記キャッシュサーバに対して、前記決定されたコンテンツのうちのいずれかのコンテンツが要求された場合、コンテンツの要求元となるキャッシュサーバに対し、前記コンテンツを応答すると共に、前記コンテンツをキャッシュとして保持するよう指示する情報に加え、前記決定したコンテンツ複製数のうち、前記要求元のキャッシュサーバに複製の指示を依頼する数に設定した複製数を通知し、
    前記コンテンツの要求元のキャッシュサーバは、前記複製数を受信すると、複製数分の複製の指示を依頼されたものとして、複製数の分だけ、他のキャッシュサーバにコンテンツの複製を指示するか、又は他のキャッシュサーバに複製数を通知することで、コンテンツの複製の指示を依頼する請求項１４に記載のキャッシュ方法。
16. 前記キャッシュサーバは、他のキャッシュサーバにコンテンツを要求する際に、前記要求に、前記キャッシュサーバの記憶容量の空き情報、ＣＰＵ使用状況、通信インタフェース使用量、他のキャッシュサーバとのコンテンツ送受信に関わるトラヒック量、同時接続数、の少なくともいずれかをキャッシュサーバ負荷情報として格納し、
    前記キャッシュサーバのコンテンツ要求を受信したキャッシュサーバは、前記コンテンツ要求から取得した前記キャッシュサーバ負荷情報に基づき、コンテンツ複製指示の対象とするキャッシュサーバを決定する請求項１４に記載のキャッシュ方法。
17. 前記キャッシュサーバは、他のキャッシュサーバからコンテンツを取得した際に、取得したコンテンツが複製対象として決定したコンテンツに含まれていた場合は、前記コンテンツをキャッシュとして保持する請求項１３に記載のキャッシュ方法。
18. 前記キャッシュサーバは、端末からコンテンツを要求された場合で、自キャッシュサーバが前記コンテンツを保持していなかった場合は、順次的な方法、又は同報的な方法により、前記要求されたコンテンツを保持しているキャッシュサーバを発見する請求項１１又は１２に記載のキャッシュ方法。
19. 前記キャッシュサーバは、自キャッシュサーバが保持するコンテンツ情報を管理サーバに通知し、
    前記キャッシュサーバが端末からコンテンツを要求された場合で、自キャッシュサーバが前記コンテンツを保持していなかった場合は、前記管理サーバから得られた情報に基づき、前記要求されたコンテンツを保持しているキャッシュサーバを発見する請求項１１又は１２に記載のキャッシュ方法。
20. 前記管理サーバに相当する機能を、各キャッシュサーバが分担し、各キャッシュサーバは、コンテンツの識別子に基づいて、コンテンツ毎にコンテンツの保有情報を管理を担当するキャッシュサーバを決定する請求項１９に記載のキャッシュ方法。
21. 端末から要求されたコンテンツを、オリジンサーバの代わりに配信するキャッシュサーバであって、
    前記端末から要求されたコンテンツを保持していない場合に、前記コンテンツを保持する他のキャッシュサーバから取得して前記端末に配信するにあたり、他のキャッシュサーバとコンテンツを送受信することによる負荷を示す指標に基づいて、コンテンツの複製の制御を行うキャッシュサーバ。
22. 前記指標は、キャッシュサーバ間でのコンテンツ送受信に関わるトラヒック量、キャッシュサーバ間の同時セッション数、キャッシュサーバの通信インタフェース使用量、ＣＰＵ使用率の少なくともいずれかにより得られた指標である請求項２１に記載のキャッシュサーバ。
23. コンテンツの複製を決定する際に、少なくとも、前記キャッシュサーバが保持するコンテンツへのアクセス数、コンテンツのサイズのいずれかに基づいて、複製対象とする１又は複数のコンテンツを決定する請求項２１又は２２に記載のキャッシュサーバ。
24. コンテンツの複製の実施を決定し、複製対象とする１又は複数のコンテンツを決定した後で、前記キャッシュサーバを構成する他のキャッシュサーバから前記キャッシュサーバに対して、前記決定されたコンテンツのうちのいずれかのコンテンツが要求された場合、コンテンツの要求元となるキャッシュサーバに対し、前記コンテンツを応答すると共に、前記コンテンツをキャッシュとして保持するよう指示する請求項２３に記載のキャッシュサーバ。
25. 前記コンテンツの応答を受信すると、複製指示に従って、コンテンツ応答により得られたコンテンツ端末に配信すると共に、キャッッシュとして保持する請求項２４に記載のキャッシュサーバ。
26. コンテンツの複製の実施を決定した際に、複製対象とする１又は複数のコンテンツを決定すると共に、コンテンツの複製数を決定し、
    前記キャッシュサーバを構成する他のキャッシュサーバから、前記キャッシュサーバに対して、前記決定されたコンテンツのうちのいずれかのコンテンツが要求された場合、コンテンツの要求元となるキャッシュサーバに対し、前記コンテンツを応答すると共に、前記コンテンツをキャッシュとして保持するよう指示する情報に加え、前記決定したコンテンツ複製数のうち、前記要求元のキャッシュサーバに複製の指示を依頼する数に設定した複製数を通知する請求項２４に記載のキャッシュサーバ。
27. 前記コンテンツの要求を受信すると、複製数分の複製の指示を依頼されたものとして、複製数の分だけ、他のキャッシュサーバにコンテンツの複製を指示するか、又は他のキャッシュサーバに複製数を通知することで、コンテンツの複製の指示を依頼する請求項２６に記載のキャッシュサーバ。
28. 他のキャッシュサーバにコンテンツを要求する際に、前記要求に、前記キャッシュサーバの記憶容量の空き情報、ＣＰＵ使用状況、通信インタフェース使用量、他のキャッシュサーバとのコンテンツ送受信に関わるトラヒック量、同時接続数、の少なくともいずれかをキャッシュサーバ負荷情報として格納する請求項２４に記載のキャッシュサーバ。
29. 前記コンテンツの要求を受信した場合、前記コンテンツの要求から取得した前記負荷を示す指標に基づき、コンテンツ複製指示の対象とするキャッシュサーバを決定する請求項２４に記載のキャッシュサーバ。
30. 他のキャッシュサーバからコンテンツを取得した際に、取得したコンテンツが複製対象として決定したコンテンツに含まれていた場合は、前記コンテンツをキャッシュとして保持する請求項２３に記載のキャッシュサーバ。
    

Images