情報処理装置、プログラム、配信システム、及び情報提供方法
【課題】無駄にキャッシュ容量が確保されることを防止することが可能な情報処理装置、プログラム、配信システム、及び情報提供方法を提供する。
【解決手段】推定手段により推定されたネットワーク負荷が所定の負荷以上の場合に、推定されたネットワーク負荷に基づいて、ノード装置がコンテンツを保存可能なデータ容量が決定される。そして、ノード装置において既に設定されているデータ容量の更新する指令を示す指令情報がノード装置に送信される。そして、各ノード装置において、コンテンツを保存可能なデータ容量がネットワーク負荷に応じた適切なデータ容量に更新される。
【解決手段】推定手段により推定されたネットワーク負荷が所定の負荷以上の場合に、推定されたネットワーク負荷に基づいて、ノード装置がコンテンツを保存可能なデータ容量が決定される。そして、ノード装置において既に設定されているデータ容量の更新する指令を示す指令情報がノード装置に送信される。そして、各ノード装置において、コンテンツを保存可能なデータ容量がネットワーク負荷に応じた適切なデータ容量に更新される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オーバーレイネットワークを利用する配信システムの技術分野に関する。
【背景技術】
【０００２】
従来、オーバーレイネットワークを用いた配信システムが注目されている。具体的には、ピアツーピア（Ｐ２Ｐ）型の配信システムである。このピアツーピア型の配信システムにおいては、ネットワークを介して配信可能な複数のコンテンツが複数のノード装置に分散して保存される。このノード装置は、クライアント装置ともいう。特許文献１には、複数のクライアント装置から構成されたピアツーピア型の配信システムが開示されている。この配信システムにおいて、クライアント装置は、ピアツーピアネットワークを介して他のクライアント装置からコンテンツを取得、またはＣＤＮサーバ装置からコンテンツを取得することが可能になっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特表２０１１−５０３７４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、ピアツーピア型の配信システムでは、各ノード装置においてコンテンツを保存可能なデータ容量の上限値が予め設定されている。コンテンツを保存可能なデータ容量の上限値を、以下、「キャッシュ容量」という。各ノード装置は、キャッシュ容量以下に収まるようにコンテンツを保存する。
【０００５】
しかしながら、配信システムにおいて提供されるサービスの利用状況によっては、各ノード装置において、無駄にキャッシュ容量が確保されてしまうという問題があった。
【０００６】
本発明は、以上の点に鑑みてなされたものである。本発明は、無駄にキャッシュ容量が確保されることを防止することが可能な情報処理装置、プログラム、配信システム、及び情報提供方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおける情報処理装置であって、過去の所定期間における前記配信システムを構成する複数のノード装置の数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得手段と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段と、前記取得手段により取得された前記変化情報と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定手段と、前記推定手段により推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する第１決定手段と、前記複数のノード装置において既に設定されている前記データ容量を、前記第１決定手段により決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信手段と、を備えることを特徴とする。
【０００８】
請求項２に記載の発明は、請求項１に記載の情報処理装置において、前記記憶手段は、過去に前記配信システムに投入されたコンテンツのデータ量を記憶しており、前記情報処理装置は、前記配信システムにおいて提供されるサービスの利用が開始される際に前記配信システムに投入されるコンテンツのデータ量を決定する第２決定手段を更に備え、前記取得手段は、前記過去に前記配信システムに投入された前記コンテンツのデータ容量に対する、前記第２決定手段により決定された前記コンテンツのデータ量の増加の割合を前記変化情報として取得し、前記推定手段は、前記取得手段により取得された前記変化情報に示される前記コンテンツのデータ量の増加の割合と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定することを特徴とする。
【０００９】
請求項３に記載の発明は、請求項１または請求項２に記載の情報処理装置において、前記推定手段は、所定時間間隔で前記ネットワーク負荷を推定し、前記第１決定手段は、前記推定手段により前記所定時間間隔で前記ネットワーク負荷が推定される毎に、前記ネットワーク負荷が所定の負荷以上であるかを判定し、前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記ノード装置が前記コンテンツを保存可能なデータ容量を決定することを特徴とする。
【００１０】
請求項４に記載の発明は、請求項１から請求項３のいずれか一項に記載の情報処理装置において、前記情報処理装置は、前記配信システムを構成する複数のノード装置の数が所定数増加又は減少したかを判定する判定手段を更に備え、前記推定手段は、前記判定手段により前記複数のノード装置の数が所定数増加又は減少した場合に、前記ネットワーク負荷を推定し、前記第１決定手段は、前記推定手段により前記ネットワーク負荷が推定される毎に、前記ネットワーク負荷が所定の負荷以上であるかを判定し、前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記ノード装置が前記コンテンツを保存可能なデータ容量を決定することを特徴とする。
【００１１】
請求項５に記載の発明は、ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおける情報処理装置のコンピュータに、過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得ステップと、前記取得ステップにより取得された前記変化情報と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定ステップと、前記推定ステップにより推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する決定ステップと、前記複数のノード装置において既に設定されている前記データ容量を、前記決定ステップにより決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信ステップと、を実行させることを特徴とする。
【００１２】
請求項６に記載の発明は、ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムの情報処理装置における情報提供方法であって、前記情報処理装置が、過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得ステップと、前記情報処理装置が、前記取得ステップにより取得された前記変化情報と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定ステップと、前記情報処理装置が、前記推定ステップにより推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する決定ステップと、前記情報処理装置が、前記複数のノード装置において既に設定されている前記データ容量を、前記決定ステップにより決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信ステップと、を含むことを特徴とする。
【００１３】
請求項７に記載の発明は、ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおいて、前記配信システムにおける情報処理装置は、過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得手段と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段と、前記取得手段により取得された前記変化情報と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定手段と、前記推定手段により推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する第１決定手段と、前記複数のノード装置において既に設定されている前記データ容量を、前記第１決定手段により決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信手段と、を備え、前記ノード装置は、前記指令情報を受信する受信手段と、前記受信された指令情報に応じて、前記既に設定されている前記データ容量を、前記指令情報に示される前記データ容量に更新する更新手段と、を備えることを特徴とする。
【発明の効果】
【００１４】
請求項１、５乃至７に記載の発明によれば、推定手段により推定されたネットワーク負荷が所定の負荷以上の場合に、推定されたネットワーク負荷に基づいて、ノード装置がコンテンツを保存可能なデータ容量が決定される。そして、ノード装置において既に設定されているデータ容量の更新する指令を示す指令情報がノード装置に送信される。そのため、各ノード装置において、コンテンツを保存可能なデータ容量をネットワーク負荷に応じた適切なデータ容量に更新させることができる。その結果、無駄に、コンテンツを保存可能なデータ容量が確保されることを防止することができる。
【００１５】
請求項２に記載の発明によれば、配信システムにおいて提供されるサービスの利用が開始される際に、各ノード装置において、コンテンツを保存可能なデータ容量をネットワーク負荷に応じた適切なデータ容量に更新させることができる。
【００１６】
請求項３に記載の発明によれば、所定時間間隔毎に、各ノード装置において、コンテンツを保存可能なデータ容量をネットワーク負荷に応じた適切なデータ容量に更新させることができる。
【００１７】
請求項４に記載の発明によれば、複数のノード装置の接続数が所定数増加又は減少される毎に、各ノード装置において、コンテンツを保存可能なデータ容量をネットワーク負荷に応じた適切なデータ容量に更新させることができる。
【図面の簡単な説明】
【００１８】
【図１】本実施形態に係る配信システムの概要構成例を示す図である。
【図２】（Ａ）は、センターサーバＳＳの概要構成例を示すブロック図である。（Ｂ）は、ノードの概要構成例を示すブロック図である。
【図３】（Ａ）は、センターサーバＳＳの制御部１におけるキャッシュ容量算出処理を示すフローチャートである。（Ｂ）は、ノードの制御部１１におけるキャッシュ容量更新処理を示すフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、配信システムに本発明を適用した場合の実施形態である。
【００２０】
［１．配信システムの構成及び動作概要］
始めに、図１を参照して、本実施形態に係る配信システムの構成及び動作概要について説明する。図１は、本実施形態に係る配信システムの概要構成例を示す図である。図１に示すように、本実施形態に係る配信システムＳは、センターサーバＳＳ、及びノード装置Ｎｎ（ｎ＝１，２，３・・・ｋ）等により構成されている。また、センターサーバＳＳは、本発明における情報処理装置の一例である。ノード装置Ｎｎを、以下、「ノード」という。また、センターサーバＳＳ及びノードはネットワークＮＷに接続されている。ネットワークＮＷは、インターネット等からなる。
【００２１】
また、本実施形態では、図１に示す複数の拠点Ｐｎを想定している。この拠点の例としては、例えばカラオケ店舗、学校、会社、住宅、又はその他の施設等が挙げられる。このような拠点Ｐｎの中には、拠点ネットワークＮＬｎが構築されている拠点Ｐｎがある。拠点ネットワークＮＬｎは、例えば、ＬＡＮ（Local Area Network）等から構成される。また、各拠点ネットワークＮＬｎには、ノードと複数の拠点端末Ｔｎ−ｌとが接続されている。ノードは、同じ拠点ネットワークＮＬｎに接続されている拠点端末Ｔｎ−ｌへコンテンツを提供するエッジサーバとしての機能を有する。一方、拠点端末Ｔｎ−ｌは、コンテンツを再生する機能を有する。例えば、拠点Ｐｎがカラオケ店舗の場合、拠点端末Ｔｎ−ｌは、カラオケ用のコンテンツを再生するコマンダである。また、例えば拠点Ｐｎが学校である場合、教材用のコンテンツを再生する視聴端末である。
【００２２】
また、図１に示すように、配信システムＳには、ネットワークＮＷを介して互いに通信可能な複数のノードの参加によりオーバーレイネットワークＯＮが構成されている。オーバーレイネットワークＯＮは、仮想的なリンクを構成する論理的なネットワークである。オーバーレイネットワークＯＮは、特定のアルゴリズム、例えば、分散ハッシュテーブルを利用したアルゴリズムにより実現される。なお、分散ハッシュテーブルを、以下、「ＤＨＴ（Distributed Hash Table）」という。また、オーバーレイネットワークＯＮに参加している各ノードには、ノードＩＤが付与されている。このノードＩＤは、ノードを、オーバーレイネットワークＯＮに参加している他のノードの中から識別する固有の識別情報である。ここで、オーバーレイネットワークＯＮに参加するとは、ＤＨＴを用いたルーティングテーブルに基づいてオーバーレイネットワークＯＮを介して他のノードとの間で各種メッセージを送受信できる状態に稼動することをいう。なお、ＤＨＴを用いたルーティングテーブルについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。
【００２３】
そして、配信システムＳでは、オーバーレイネットワークＯＮを利用してコンテンツを配信する複数のサービスが提供される。ここで、サービスの例としては、カラオケ用のコンテンツを配信するサービス、及びユーザ等により投稿された動画のコンテンツを配信するサービス等がある。センターサーバＳＳは、例えばサービスの提供者の管理端末からアップロードされたコンテンツを配信システムＳに投入する。ここで、コンテンツの投入とは、オーバーレイネットワークＯＮに参加している１以上のノードに、コンテンツを保存させることをいう。ここで、投入されるコンテンツは、オリジナルのコンテンツを複製したレプリカである。また、オリジナルのコンテンツとは、例えばサービスの提供者の管理端末からアップロードされたコンテンツである。投入される各コンテンツにはコンテンツＩＤが付与されている。コンテンツＩＤは、コンテンツを、配信システムＳに投入されている他のコンテンツの中から識別する固有の識別情報である。なお、ノードＩＤ、及びコンテンツＩＤは、例えば、特開２００６−１９７４００号公報等に開示されるように、共通のハッシュ関数によりハッシュ化されて生成される。
【００２４】
また、所定のデータ量より大きいサイズのコンテンツは、所定のデータ量以下のファイルサイズに分割される。その結果、複数のチャンクが生成される。そして、チャンクは、１つのコンテンツとして配信システムＳに投入される。投入される各チャンクにはコンテンツＩＤが付与されている。チャンクのコンテンツＩＤは、チャンクＩＤともいう。また、コンテンツを構成する各チャンクのコンテンツＩＤは、このコンテンツのメタファイルに記述されている。コンテンツのメタファイルとは、このコンテンツを構成する各チャンクを検索するためのファイルである。そして、コンテンツのメタファイルは、１つのコンテンツとして配信システムＳに投入される。投入される各メタファイルにはコンテンツＩＤが付与されている。なお、「コンテンツ、チャンク、又はメタファイル」を、以下、「コンテンツ等」という。
【００２５】
また、各ノードは、コンテンツＩＤに基づき、他のノードに保存されているコンテンツ等を、オーバーレイネットワークＯＮを介して取得可能になっている。このように取得されたコンテンツ等は、ノードに保存される。なお、コンテンツ等を保存するノードを、以下、「コンテンツ保持ノード」という。また、コンテンツ等の所在を示す情報は、インデックス情報として、コンテンツ等の所在を管理しているノードに記憶される。コンテンツ等の所在を管理しているノードを、以下、「ルートノード」という。このインデックス情報には、コンテンツ保持ノードのノード情報とコンテンツＩＤとの組が含まれる。ノード情報には、コンテンツ保持ノードのＩＰアドレス、ポート番号、及びノードＩＤが含まれる。ルートノードは、例えば、コンテンツＩＤと最も近いノードＩＤが割り当てられたノードであるように定められる。コンテンツＩＤと最も近いノードＩＤとは、例えば、ＩＤの上位桁が最も多く一致するノードＩＤである。
【００２６】
そして、ノードが、配信システムＳにおいてコンテンツ等を検索する場合がある。この検索を行うノードを、以下、「ユーザノード」という。ユーザノードは、検索対象のコンテンツ等のコンテンツＩＤを用いて、このコンテンツ等を保存するコンテンツ保持ノードの所在をルートノードに問い合わせる。これにより、ユーザノードは、ルートノードからコンテンツ保持ノードのＩＰアドレス等を受信する。そして、ユーザノードは、コンテンツ保持ノードにアクセスし、コンテンツ等を要求する。これにより、ユーザノードは、コンテンツ保持ノードからコンテンツを取得する。或いは、ルートノードがユーザノードのＩＰアドレス等をコンテンツ保持ノードへ送信する。そして、コンテンツ保持ノードからユーザノードへアクセスするように構成してもよい。なお、ユーザノードによるルートノードへの問い合わせ処理は、例えば特開２００７−０５３６６２号公報等で公知であるので、詳しい説明を省略する。なお、検索対象のコンテンツ等を保存するコンテンツ保持ノードの数が少ない場合がある。この場合、ユーザノードは、センターサーバＳＳにアクセスし、コンテンツ等を要求することになる。
【００２７】
ところで、オーバーレイネットワークＯＮに参加している各ノードには、キャッシュ容量が設定されている。このキャッシュ容量は、上述したように、コンテンツを保存可能なデータ容量の上限値である。各ノードは、このキャッシュ容量以下に収まるようにコンテンツ等を保存する。そして、本実施形態では、各ノードにおけるキャッシュ容量が、センターサーバＳＳにより推定されたネットワーク負荷に応じた適切な容量に更新される。そのため、サービスの利用状況の変化に伴い、無駄のない最適なキャッシュ容量を各ノードに設定させることができる。なお、ネットワーク負荷は、過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報と、ネットワーク負荷に影響を与える要因となる起因要素ｘの変化を示す変化情報と、が用いられて推定される。ここで、過去の所定期間内の何れかの時点におけるネットワーク負荷には、例えば、過去の所定期間内に複数回計測されたネットワーク負荷の中で、最大のネットワーク負荷が該当する。この場合、過去の所定期間内の何れかの時点とは、最大のネットワーク負荷が計測された時点となる。或いは、過去の所定期間内に複数回計測されたネットワーク負荷の中で閾値以上のネットワーク負荷が、過去の所定期間内の何れかの時点におけるネットワーク負荷であってもよい。この場合、過去の所定期間内の何れかの時点とは、閾値以上のネットワーク負荷が計測された時点となる。ここで、閾値以上のネットワーク負荷が複数計測される場合がある。この場合、閾値以上の複数のネットワーク負荷の中で、例えばランダムに選択された何れか一つのネットワーク負荷が、過去の所定期間内の何れかの時点におけるネットワーク負荷に該当することになる。或いは、過去の所定期間内の何れかの時点におけるネットワーク負荷は、過去の所定期間内に複数回計測されたネットワーク負荷の平均値であってもよい。この場合、過去の所定期間内の何れかの時点とは、例えばネットワーク負荷の平均値の算出時点となる。また、ネットワーク負荷に影響を与える要因となる起因要素ｘの例としては、以下の起因要素ａ〜起因要素ｅが挙げられる。
【００２８】
（１）起因要素ａ：投入されたコンテンツのデータ量
コンテンツのデータ量とは、オリジナルのコンテンツのファイルサイズの総和である。投入されたコンテンツのデータ量が大きいときは、各ノードにおけるキャッシュ容量を大きくした方が望ましい。そこで、投入されたコンテンツのデータ量を起因要素ａとして考慮することで、投入されたコンテンツのデータ量の増加又は減少に応じて、各ノードにおけるキャッシュ容量を増加又は減少させることが可能となる。
【００２９】
（２）起因要素ｂ：コンテンツの要求数の偏り度合い
コンテンツの要求数の偏り度合いは、例えば、コンテンツの要求数の標準偏差で表すことができる。コンテンツの要求数の偏り度合いは、言い換えれば、コンテンツの人気の偏り度合いである。例えば、互いに異なる複数のコンテンツの中で、コンテンツの要求が人気のあるコンテンツに集中する場合がある。つまり、コンテンツの人気が偏っている場合がある。この場合、投入されたコンテンツのデータ量が大きくても、各ノードにおけるキャッシュ容量がそれほど大きくなくてもよい。そこで、コンテンツの要求数の偏り度合いを起因要素ｂとして考慮することで、コンテンツの要求数の偏り度合いの増加又は減少に応じて、各ノードにおけるキャッシュ容量を減少又は増加させることが可能となる。
【００３０】
（３）起因要素ｃ：チャンク１つ分のファイルサイズ
チャンク１つ分のファイルサイズが決められている場合がある。この場合において、チャンクにより構成されるコンテンツのファイルサイズに比べて、１つのノードにおけるキャッシュ容量が小さいと、１つのコンテンツを構成するチャンクが複数のノードに分散される。その結果、ノードによるコンテンツの再生待ちが発生してしまう。そのため、コンテンツを構成する各チャンクは、できるだけ１つのノードに保存されることが望ましい。つまり、チャンク１つ分のファイルサイズが大きいときは、各ノードにおけるキャッシュ容量を大きくした方が望ましい。そこで、チャンク１つ分のファイルサイズを起因要素ｃとして考慮することで、チャンク１つ分のファイルサイズの増加又は減少に応じて、各ノードにおけるキャッシュ容量を増加又は減少させることが可能となる。
【００３１】
（４）起因要素ｄ：オーバーレイネットワークＯＮに参加しているノードの数
オーバーレイネットワークＯＮに参加しているノードの数は、言い換えれば、配信システムＳを構成するノードの数である。これらのノードは、オーバーレイネットワークＯＮに所定時間以上参加していることが望ましい。この所定時間は、例えば２４時間程度とされる。オーバーレイネットワークＯＮに所定時間以上参加しているノードの数が少ないと、コンテンツ保持ノードの数が少なくなる。その結果、コンテンツ等の要求がユーザノードからセンターサーバＳＳに集中することになる。そのため、オーバーレイネットワークＯＮに参加しているノードの数が少ないときは、各ノードにおけるキャッシュ容量を大きくした方が望ましい。そこで、オーバーレイネットワークＯＮに参加しているノードの数を起因要素ｄとして考慮することで、ノードの数の増加又は減少に応じて、各ノードにおけるキャッシュ容量を増加又は減少させることが可能となる。なお、オーバーレイネットワークＯＮに参加しているノードの数は、コンテンツ保持ノードの数であってもよい。
【００３２】
（５）起因要素ｅ：投入前後のコンテンツの要求数の差
コンテンツの要求は、コンテンツの投入直後に増加する場合がある。言い換えれば、コンテンツの要求は、コンテンツの投入直後に集中する場合がある。コンテンツの要求の増加は、例えば、投入前後のコンテンツの要求数の差で表すことができる。この差は、例えば、投入前所定時間内のコンテンツの要求数と、投入後所定時間内のコンテンツの要求数との差である。この所定時間は、例えば２４時間程度とされる。投入直後にコンテンツの要求が増加すると、コンテンツ保持ノードやセンターサーバＳＳに負荷がかかる。そのため、投入前後のコンテンツの要求数の差が大きいときは、各ノードにおけるキャッシュ容量を大きくした方が望ましい。そこで、投入前後のコンテンツの要求数の差を起因要素ｅとして考慮することで、投入前後のコンテンツの要求数の差の増加又は減少に応じて、各ノードにおけるキャッシュ容量を増加又は減少させることが可能となる。
【００３３】
［２．センターサーバＳＳの構成及び機能］
次に、図２（Ａ）を参照して、センターサーバＳＳの構成及び機能について説明する。図２（Ａ）は、センターサーバＳＳの概要構成例を示すブロック図である。センターサーバＳＳは、図２（Ａ）に示すように、制御部１、記憶部２、及び通信部３等を備えて構成される。制御部１、記憶部２、及び通信部３はバス４を介して相互に接続されている。記憶部２は、本発明における記憶手段の一例である。
【００３４】
記憶部２は、例えばハードディスクドライブ等から構成される。記憶部２には、オペレーティングシステム、及びサーバプログラム等が記憶されている。なお、サーバプログラムは、例えば、ネットワークＮＷに接続された所定のサーバからダウンロードされるようにしてもよい。或いは、サーバプログラムは、例えば、記録媒体に記録されて記録媒体のドライブを介して読み込まれるようにしてもよい。
【００３５】
また、記憶部２には、オーバーレイネットワークＯＮに投入された各コンテンツ等のオリジナルが記憶されている。また、記憶部２には、オーバーレイネットワークＯＮに参加しているノードの中で、システム管理者等により管理されているノードのノード情報を登録するノードリストが記憶されている。システム運用者等により管理されるノードとしては、基本的にネットワークＮＷに定常的に接続されているノードが挙げられる。ここで、「定常的に」とは、例えば、ノードが故障時又はメンテナンス時以外の時には、オーバーレイネットワークＯＮから離脱せず参加していることを意味する。
【００３６】
また、記憶部２には、制御部１により計測されたネットワーク負荷を示す負荷情報が、計測された時の日付に対応付けられて記憶されている。ここで、ネットワーク負荷は、例えば、ネットワークＮＷに接続されるセンターサーバＳＳの通信回線の有効帯域（ｂｐｓ）で表される。制御部１は、通信部３を介して受信される単位時間当たりのデータ量に基づきネットワーク負荷を計測する。また、記憶部２には、制御部１により取得された上記起因要素ｘが、取得された時の日付に対応付けられて記憶されている。なお、日付には時刻を含んでもよい。更に、記憶部２には、各ノードにおいて設定されているキャッシュ容量を示す情報が記憶されている。
【００３７】
通信部３は、ネットワークＮＷを通じてノード等との間の通信制御を行う。
【００３８】
制御部１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，及びＲＯＭ等から構成される。制御部１は、本発明における取得手段、推定手段、第１決定手段、第２決定手段、判定手段、及び送信手段の一例である。また、制御部１は、時計機能及びタイマ機能を有する。制御部１は、ＣＰＵが記憶部２等に記憶されたプログラムを読み出して実行することにより、後述する処理を行う。
【００３９】
［３．ノードの構成及び機能等］
次に、図２（Ｂ）を参照して、ノードの構成及び機能について説明する。図２（Ｂ）は、ノードの概要構成例を示すブロック図である。ノードは、図２（Ｂ）に示すように、制御部１１、記憶部１２、通信部１３ａ、通信部１３ｂ、及びバッファメモリ１４等を備えて構成される。制御部１１、記憶部１２、通信部１３ａ、通信部１３ｂ、及びバッファメモリ１４はバス１５を介して相互に接続されている。
【００４０】
本実施形態において、ノードは、ネットワークＮＷと拠点ネットワークＮＬｎとの間でＩＰ（Internet Protocol）パケットを中継する中継機器である。この中継機器は、基本的にネットワークＮＷに定常的に接続されているルータ又はＬ３スイッチングハブ等である。また、ノードは、基本的にネットワークＮＷに定常的に接続されているゲートウェイ等の機器であっても良い。なお、ノードは、ネットワークＮＷに定常的に接続されるとは限らないユーザ端末であってもよい。ユーザ端末は、例えば、ユーザが使用する時等の時間だけネットワークＮＷに接続される。ユーザ端末の一例としては、パーソナルコンピュータや携帯端末等が挙げられる。
【００４１】
記憶部１２は、例えばハードディスクドライブ等から構成される。記憶部１２には、オペレーティングシステム、ＩＰパケット中継処理プログラム、及びＰ２Ｐプログラム等が記憶されている。また、記憶部１２には、センターサーバＳＳのＩＰアドレス及びポート番号が記憶されている。また、記憶部１２には、オーバーレイネットワークＯＮで使用されるＤＨＴを用いたルーティングテーブル等が記憶されている。ＤＨＴを用いたルーティングテーブルには、複数のノードのノード情報が登録されている。また、記憶部１２には、コンテンツを保存するためのコンテンツ保存領域が設けられている。このコンテンツ保存領域には、コンテンツを構成するチャンクも保存される。また、コンテンツ保存領域には、コンテンツのメタファイルが保存されてもよい。また、コンテンツ保存領域は、例えばＰ２Ｐプログラムがインストールされることにより設けられる。そして、コンテンツ保存領域には、上述したキャッシュ容量が設定されている。このキャッシュ容量は、センターサーバＳＳからの指令に応じて適切な容量に更新される。
【００４２】
通信部１３ａは、ネットワークＮＷを通じてセンターサーバＳＳ等との間の通信制御を行う。通信部１３ｂは、拠点ネットワークＮＬｎを通じて拠点端末Ｔｎ−ｌとの間の通信制御を行う。また、バッファメモリ１４は、通信部１３ａを介して受信されたコンテンツ等を一時的に蓄積する。
【００４３】
制御部１１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，及びＲＯＭ等から構成される。制御部１は、本発明における受信手段、及び更新手段の一例である。また、制御部１１は、時計機能及びタイマ機能を備える。そして、制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラムを読み出して実行することにより、後述する処理を行う。なお、制御部１１は、ＯＳＩ（Open Systems Interconnection）参照モデルの第３層であるネットワーク層において、他のルータ又はホストからのＩＰパケットを中継する機能を有する。ＩＰパケットを中継する機能は、公知のルータ又はＬ３スイッチングハブ等と同様であるので、詳しい説明を省略する。
【００４４】
［４．配信システムＳの動作］
次に、図３を参照して、本実施形態に係る配信システムＳの動作について説明する。図３（Ａ）は、センターサーバＳＳの制御部１におけるキャッシュ容量算出処理を示すフローチャートである。図３（Ｂ）は、ノードの制御部１１におけるキャッシュ容量更新処理を示すフローチャートである。図３（Ａ）に示すキャッシュ容量算出処理は、例えば所定時間間隔で定期的に実行される。例えば、１時間毎、１日毎、または１月毎に実行される。
【００４５】
図３（Ａ）に示すキャッシュ容量算出処理が開始されると、先ず、制御部１は、ネットワーク負荷の推定に用いる今回の起因要素ｘを取得する（ステップＳ１）。例えば、上述した起因要素ａ〜ｅの中から１以上の起因要素ｘが取得される。どの起因要素ｘが取得されるかは任意に設定可能である。ここで、起因要素ａ〜ｅの夫々の取得方法について説明する。
【００４６】
（１）起因要素ａの場合
この場合、制御部１は、前回のキャッシュ容量算出時から現時点までの期間内に配信ステムＳに投入されたオリジナルのコンテンツのファイルサイズの総和を、起因要素ａとして取得する。配信システムＳに投入されたオリジナルのコンテンツは記憶部２に記憶されている。そのため、制御部１は、オリジナルのコンテンツのファイルサイズの総和を算出することができる。
【００４７】
（２）起因要素ｂの場合
この場合、制御部１は、前回のキャッシュ容量算出時から現時点までの期間内におけるコンテンツの要求数をコンテンツ毎に取得する。コンテンツの要求数は、言い換えれば、ユーザノードからルートノードへの問い合わせの数である。本実施形態では、各コンテンツのルートノードは、ユーザノードからの問い合わせ数をカウントし記憶している。そのため、制御部１は、各コンテンツのルートノードから、上記問い合わせ数を各コンテンツの要求数として取得することができる。そして、制御部１は、各コンテンツの要求数の分散値又は標準偏差を算出し起因要素ｂとして取得する。
【００４８】
（３）起因要素ｃの場合
この場合、制御部１は、現時点におけるチャンク１つ分のファイルサイズを、起因要素ｃとして取得する。配信システムＳに投入されたオリジナルのチャンクは記憶部２に記憶されている。そのため、制御部１は、オリジナルのチャンク１つ分のファイルサイズを取得することができる。
【００４９】
（４）起因要素ｄの場合
この場合、制御部１は、現時点においてオーバーレイネットワークＯＮに所定時間以上参加しているノードの数を、起因要素ｄとして取得する。オーバーレイネットワークＯＮに所定時間以上参加しているノードは、例えば、記憶部２に記憶されているノードリストから決定される。
【００５０】
（５）起因要素ｅの場合
この場合、制御部１は、新たなコンテンツの投入前２４時間以内のコンテンツの要求数と、投入後２４時間以内のコンテンツの要求数とをコンテンツ毎に取得する。例えば、制御部１は、各コンテンツのルートノードから、投入前２４時間以内の問い合わせ数と、投入後２４時間以内の問い合わせ数を、コンテンツの要求数として夫々取得する。そして、制御部１は、投入前２４時間以内の各コンテンツの要求数の総和と、投入後２４時間以内の各コンテンツの要求数の総和との差を、起因要素ｅとして取得する。なお、新たなコンテンツの投入は、前回のキャッシュ容量算出時から現時点までの期間内における投入が対象となる。
【００５１】
こうして取得された起因要素ｘは、取得された時の日付に対応付けられて記憶部２に記憶される。このように記憶された起因要素ｘは、次回のキャッシュ容量算出処理でも用いられる。
【００５２】
次いで、制御部１は、前回の起因要素ｘを記憶部２から取得する（ステップＳ２）。前回の起因要素ｘは、前回のキャッシュ容量算出処理におけるステップＳ１で取得された起因要素ｘである。なお、どの起因要素ｘが取得されるかはステップＳ１と同様である。例えば、ステップＳ１で今回の起因要素ａ及び起因要素ｂが取得された場合、ステップＳ２では前回の起因要素ａ及び起因要素ｂが取得される。
【００５３】
次いで、制御部１は、ステップＳ１で取得された今回の起因要素ｘと、ステップＳ２で取得された前回の起因要素ｘとの間の変化を示す変化値Ｖｘを変化情報として取得する（ステップＳ３）。例えば、起因要素ａ〜ｃ，及びｅの場合、前回の起因要素ｘで今回の起因要素ｘを除した値が変化値Ｖｘとなる。一方、例えば、起因要素ｄの場合、今回の起因要素ｄで前回の起因要素ｄを除した値が変化値Ｖｄとなる。
【００５４】
次いで、制御部１は、前回のキャッシュ容量算出処理時から現時点までの期間内に計測及び記憶されたネットワーク負荷の中で、例えば最大のネットワーク負荷ＬＯｍを示す負荷情報を記憶部２から取得する（ステップＳ４）。なお、制御部１は、前回のキャッシュ容量算出処理時から現時点までの期間内に計測及び記憶されたネットワーク負荷の平均値を負荷情報として取得するように構成してもよい。
【００５５】
次いで、制御部１は、ステップＳ３で取得された変化情報と、ステップＳ４で取得された負荷情報とを用いて、今回のキャッシュ容量算出処理以降のネットワーク負荷ＬＯを推定する（ステップＳ５）。ここで推定されるネットワーク負荷ＬＯは、例えば、下記（i）式により算出される。
【００５６】
ネットワーク負荷ＬＯ＝最大のネットワーク負荷ＬＯｍ×起因要素ｘの変化値Ｖｘ・・・（i）
【００５７】
また、上記ステップＳ３において、複数の起因要素ｘの変化値Ｖｘが取得される場合がある。この場合、各起因要素ｘの変化値Ｖｘが乗算された値が、最大のネットワーク負荷ＬＯに乗算されることになる。例えば、上記ステップＳ３において、起因要素ａの変化値Ｖａと、起因要素ｄの変化値Ｖｄとが取得された場合、推定されるネットワーク負荷ＬＯは、例えば、下記（ii）式により算出される。
【００５８】
ネットワーク負荷ＬＯ＝最大のネットワーク負荷ＬＯｍ×起因要素ａの変化値Ｖａ×起因要素ｄの変化値Ｖｄ・・・（ii）
【００５９】
また、複数の起因要素ｘの変化値Ｖｘが取得される場合、各起因要素ｘの変化がネットワーク負荷の変化に影響を与える度合いは、起因要素ｘ毎に異なる場合がある。そのため、推定されるネットワーク負荷ＬＯは、ネットワーク負荷の変化に影響を与える度合いを考慮することが望ましい。この場合、ネットワーク負荷の変化に影響を与える度合いを表す係数Ｔｘは、起因要素ｘ毎に決定される。なお、各係数Ｔｘは、例えば、過去にデータとして蓄積された、ネットワーク負荷の変化と各起因要素ｘの変化との関係に基づいて決定される。そして、例えば、各起因要素ｘの係数Ｔｘは、各起因要素ｘの変化値Ｖｘに乗算されることになる。この場合、例えば、（ii）式は、下記（iii）式となる。
【００６０】
ネットワーク負荷ＬＯ＝最大のネットワーク負荷ＬＯｍ×起因要素ａの変化値Ｖａ×起因要素ａの係数Ｔａ×起因要素ｂの変化値Ｖｂ×起因要素ｂの係数Ｔｂ・・・（iii）
【００６１】
なお、コンテンツの投入直後だけ、一時的に最適なキャッシュ容量をノードに割り当てたい場合がある。この場合、上記（i）〜（iii）式において、上記起因要素ｅが優先されて最大のネットワーク負荷ＬＯｍに乗算される。
【００６２】
次いで、制御部１は、上記ステップＳ５で推定されたネットワーク負荷ＬＯと、ネットワーク負荷の基準値ＬＯｚとの差を算出する。ここで、ネットワーク負荷の基準値ＬＯｚは、例えば、上記ステップＳ４で取得された最大のネットワーク負荷ＬＯｍである。或いは、例えば、ネットワーク負荷の基準値ＬＯｚは、例えばサーバプログラムの起動時における初期化処理で設定される固定値であってもよい。そして、制御部１は、ネットワーク負荷ＬＯとネットワーク負荷の基準値ＬＯｚとの差が閾値以上であるか否かを判定する（ステップＳ６）。言い換えれば、推定されたネットワーク負荷ＬＯが所定の負荷以上または所定の負荷以下であるか否かが判定される。ここで、「所定の負荷」とは、例えば、上記ステップＳ４で取得された最大のネットワーク負荷ＬＯｍに上記閾値を加算した値、または最大のネットワーク負荷ＬＯｍから閾値を減算した値である。そして、制御部１は、ネットワーク負荷ＬＯと、ネットワーク負荷の基準値ＬＯｚとの差が閾値以上であると判定した場合には（ステップＳ６：ＹＥＳ）、ステップＳ７に進む。一方、制御部１は、ネットワーク負荷ＬＯとネットワーク負荷の基準値ＬＯｚとの差が閾値以上でないと判定した場合には（ステップＳ６：ＮＯ）、キャッシュ容量算出処理を終了する。つまり、推定されたネットワーク負荷ＬＯが所定の負荷未満である場合、ノードにおけるキャッシュ容量の更新が行われない。これは、ネットワーク負荷の変化が閾値未満と少ないにも関わらず、ノードに設定されるキャッシュ容量が過多に更新されることを防止するためである。
【００６３】
そして、ステップＳ７では、制御部１は、上記ステップＳ５で推定されたネットワーク負荷ＬＯに基づいて、ノードに設定させる最適なキャッシュ容量Ｃを決定する。
【００６４】
例えば、ネットワーク負荷ＬＯの推定に起因要素ａが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間において投入されたコンテンツのデータ量に増加に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。また、例えば、ネットワーク負荷ＬＯの推定に起因要素ｂが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間におけるコンテンツの要求数の偏り度合いの減少に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。また、例えば、ネットワーク負荷ＬＯの推定に起因要素ｃが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間におけるチャンク１つ分のファイルサイズの増加に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。また、例えば、ネットワーク負荷ＬＯの推定に起因要素ｄが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間におけるノードの数の増加に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。また、例えば、ネットワーク負荷ＬＯの推定に起因要素ｅが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間における投入前後のコンテンツの要求数の差の増加に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。そして、制御部１は、上記ステップＳ７おいて、ネットワーク負荷ＬＯの値が過去のネットワーク負荷ＬＯｍの値よりも大きければ、キャッシュ容量Ｃを現状のキャッシュ容量Ｃｚよりも大きく決定する。ここで、現状のキャッシュ容量Ｃｚとは、現在、各ノードにおいて設定されているキャッシュ容量である。
【００６５】
なお、このキャッシュ容量は、例えば、下記（iv）式により算出される。
【００６６】
キャッシュ容量Ｃ＝現状のキャッシュ容量Ｃｚ−キャッシュ容量の変化値Ｖｃ・・・（iv）
【００６７】
ここで、キャッシュ容量の変化値Ｖｃは、上記ステップＳ５で推定されたネットワーク負荷ＬＯをネットワーク負荷の基準値ＬＯｚに一致させる場合に増加又は減少するキャッシュ容量を示す。また、キャッシュ容量の変化値Ｖｃは、プラス（＋）の符号の場合と、マイナス（−）の符号の場合がある。キャッシュ容量の変化値Ｖｃは、例えば、下記（v）式により算出される。
【００６８】
キャッシュ容量の変化値Ｖｃ＝（現状のキャッシュ容量Ｃｚ×起因要素ｄの変化値Ｖｄ×起因要素ｄの係数Ｔｄ）／（ネットワーク負荷の基準値ＬＯｚ−ネットワーク負荷ＬＯ）・・・（v）
【００６９】
以上のように決定された最適なキャッシュ容量Ｃは、決定された時の日付に対応付けられて記憶部２に記憶される。このように記憶されたキャッシュ容量Ｃは、次回のキャッシュ容量算出処理でキャッシュ容量Ｃｚとして用いられる。
【００７０】
次いで、制御部１は、更新指令メッセージを生成する（ステップＳ８）。この更新指令メッセージは、複数のノードにおいて既に設定されているキャッシュ容量Ｃｚを、上記ステップＳ７で決定されたキャッシュ容量Ｃに更新する指令を示す。なお、更新指令メッセージは、本発明における指令情報の一例である。
【００７１】
次いで、制御部１は、上記ステップＳ８で生成された更新指令メッセージを、オーバーレイネットワークＯＮに参加している複数のノードへ送信する（ステップＳ９）。例えば、制御部１は、記憶部２に記憶されているノードリストに登録されているノードへ更新指令メッセージを送信する。或いは、制御部１は、例えばＤＨＴマルチキャストにより、オーバーレイネットワークＯＮに参加しているノードへ更新指令メッセージを送信する。なお、ＤＨＴマルチキャストは、特開２００７−０５３６６２号公報等で公知であるので、詳しい説明を省略する。
【００７２】
こうして送信された更新指令メッセージをノードが受信すると、図３（Ｂ）に示すキャッシュ容量更新処理が開始される。図３（Ｂ）に示すキャッシュ容量更新処理では、ノードの制御部１１は、受信された更新指令メッセージからキャッシュ容量Ｃを示すデータを取得する（ステップＳ１１）。次いで、ノードの制御部１１は、現在設定されているキャッシュ容量Ｃｚを、上記ステップＳ１１で取得されたデータに示される最適なキャッシュ容量Ｃに更新する（ステップＳ１２）。つまり、更新指令メッセージを受信した各ノードにおいて最適なキャッシュ容量が割り当てられる。例えば、制御部１１は、キャッシュ容量を設定している設定ファイルに記述されたキャッシュ容量Ｃｚをキャッシュ容量Ｃに書き換える。
【００７３】
以上説明したように、上記実施形態によれば、センターサーバＳＳにより推定されたネットワーク負荷ＬＯが所定の負荷以上の場合に、推定されたネットワーク負荷ＬＯに基づいて、ノードに設定させるキャッシュ容量Ｃが決定される。そして、決定されたキャッシュ容量Ｃに更新する指令を示す更新指令メッセージが各ノードへ送信される。そのため、サービスの利用状況の変化に伴い、無駄のない最適なキャッシュ容量Ｃを各ノードに設定させることができる。つまり、各ノードで設定されるキャッシュ容量を必要最低限に抑えることができる。その結果、各ノードの限られたリソースを最小利用することが可能となり、オーバーレイネットワークＯＮを利用するピアツーピア型の配信システムＳに対して、後からサービスを追加していくことが容易となる。また、システム管理者等が、サービス規模や利用状況をあらかじめ予測またはその都度見直してキャッシュ容量を決める必要がなくなる。また、利用状況の変化に伴うセンターサーバＳＳへの集中アクセスを軽減することができる。更に、最適なキャッシュ容量Ｃが自動的に最適化されることで、その容量に応じて課金するビジネスを提供することができる。
【００７４】
なお、上記実施形態において、図３（Ａ）に示すキャッシュ容量算出処理は、所定時間間隔で実行されるように構成した。この構成により、所定の時間間隔で各ノードで設定されるキャッシュ容量Ｃを最適化することができる。この構成の別の例として、センターサーバＳＳの制御部１は、ノードリストを参照して、オーバーレイネットワークＯＮに参加しているノードの数が所定数増加又は減少したか否かを判定する。そして、制御部１は、オーバーレイネットワークＯＮに参加しているノードの数が所定数増加又は減少した場合に、図３（Ａ）に示すキャッシュ容量算出処理を開始するように構成してもよい。オーバーレイネットワークＯＮに参加しているノードの数の増減は、コンテンツの要求数等に影響を与えるケースが多い。そのため、オーバーレイネットワークＯＮに参加しているノードの数が所定数増加又は減少される毎に各ノードにおけるキャッシュ容量を更新させる構成によれば、センターサーバＳＳへの負荷集中を防止することができる。
【００７５】
更に上記構成の別の例として、センターサーバＳＳの制御部１は、配信システムＳに新たなコンテンツを投入する場合に、図３（Ａ）に示すキャッシュ容量算出処理を開始するように構成してもよい。なお、コンテンツの投入は、例えば、配信システムＳにおいて提供されるサービスの利用が開始される際に行われる。この構成の場合、センターサーバＳＳの制御部１は、配信システムＳにこれから投入するコンテンツのデータ量を決定する。このコンテンツのデータ量は、例えば、オリジナルのコンテンツのファイルサイズの総和である。そして、センターサーバＳＳの制御部１は、過去に配信システムＳに投入されたオリジナルのコンテンツのファイルサイズの総和Ｄαに対する、上記決定したコンテンツのデータ量Ｄβの増加の割合を変化情報として取得する。ここで、コンテンツのデータ量の増加の割合は、（Ｄα＋Ｄβ）／Ｄαで表すことができる。また、過去に配信システムＳに投入されたオリジナルのコンテンツは記憶部２に記憶されている。そのため、制御部１は、オリジナルのコンテンツのファイルサイズの総和を算出することができる。そして、センターサーバＳＳの制御部１は、図３（Ａ）に示すキャッシュ容量算出処理のステップＳ５において、コンテンツのデータ量の増加の割合を示す変化情報と、上記ステップＳ４で取得された負荷情報とを用いて、今回のキャッシュ容量算出処理以降のネットワーク負荷ＬＯを推定する。ここで推定されるネットワーク負荷ＬＯは、例えば、下記（vi）式により算出される。
【００７６】
ネットワーク負荷ＬＯ＝最大のネットワーク負荷ＬＯｍ×コンテンツのデータ量の増加の割合・・・（vi）
【００７７】
例えば新たなサービスの利用が開始される際に、配信システムＳに新たにコンテンツが投入されると、一時的にそのコンテンツに対して取得要求が集中する場合がある。そのため、配信システムＳに新たなコンテンツが投入される毎に各ノードにおけるキャッシュ容量を更新させる構成によれば、センターサーバＳＳへの負荷集中を防止することができる。なお、上記（vi）式において起因要素ｘをコンテンツのデータ量の増加の割合に乗算してネットワーク負荷ＬＯを算出するように構成してもよい。
【００７８】
なお、上記実施形態においては、オーバーレイネットワークＯＮに、ＤＨＴを利用したピアツーピアネットワークを適用したが、これに限られるものではない。例えば、他のオーバーレイネットワークを用いたシステムが適用されてもよい。ＤＨＴを利用しないピアツーピアシステムとしては、例えば、ハイブリッド型のピアツーピアシステムがある。
【符号の説明】
【００７９】
１，１１ 制御部
２，１２ 記憶部
３，１３ａ，１３ｂ 通信部
ＳＳ センターサーバ
Ｎｎ ノード
ＮＷ ネットワーク
ＯＮ オーバーレイネットワーク
Ｓ 配信システム
【技術分野】
【０００１】
本発明は、オーバーレイネットワークを利用する配信システムの技術分野に関する。
【背景技術】
【０００２】
従来、オーバーレイネットワークを用いた配信システムが注目されている。具体的には、ピアツーピア（Ｐ２Ｐ）型の配信システムである。このピアツーピア型の配信システムにおいては、ネットワークを介して配信可能な複数のコンテンツが複数のノード装置に分散して保存される。このノード装置は、クライアント装置ともいう。特許文献１には、複数のクライアント装置から構成されたピアツーピア型の配信システムが開示されている。この配信システムにおいて、クライアント装置は、ピアツーピアネットワークを介して他のクライアント装置からコンテンツを取得、またはＣＤＮサーバ装置からコンテンツを取得することが可能になっている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特表２０１１−５０３７４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、ピアツーピア型の配信システムでは、各ノード装置においてコンテンツを保存可能なデータ容量の上限値が予め設定されている。コンテンツを保存可能なデータ容量の上限値を、以下、「キャッシュ容量」という。各ノード装置は、キャッシュ容量以下に収まるようにコンテンツを保存する。
【０００５】
しかしながら、配信システムにおいて提供されるサービスの利用状況によっては、各ノード装置において、無駄にキャッシュ容量が確保されてしまうという問題があった。
【０００６】
本発明は、以上の点に鑑みてなされたものである。本発明は、無駄にキャッシュ容量が確保されることを防止することが可能な情報処理装置、プログラム、配信システム、及び情報提供方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおける情報処理装置であって、過去の所定期間における前記配信システムを構成する複数のノード装置の数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得手段と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段と、前記取得手段により取得された前記変化情報と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定手段と、前記推定手段により推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する第１決定手段と、前記複数のノード装置において既に設定されている前記データ容量を、前記第１決定手段により決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信手段と、を備えることを特徴とする。
【０００８】
請求項２に記載の発明は、請求項１に記載の情報処理装置において、前記記憶手段は、過去に前記配信システムに投入されたコンテンツのデータ量を記憶しており、前記情報処理装置は、前記配信システムにおいて提供されるサービスの利用が開始される際に前記配信システムに投入されるコンテンツのデータ量を決定する第２決定手段を更に備え、前記取得手段は、前記過去に前記配信システムに投入された前記コンテンツのデータ容量に対する、前記第２決定手段により決定された前記コンテンツのデータ量の増加の割合を前記変化情報として取得し、前記推定手段は、前記取得手段により取得された前記変化情報に示される前記コンテンツのデータ量の増加の割合と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定することを特徴とする。
【０００９】
請求項３に記載の発明は、請求項１または請求項２に記載の情報処理装置において、前記推定手段は、所定時間間隔で前記ネットワーク負荷を推定し、前記第１決定手段は、前記推定手段により前記所定時間間隔で前記ネットワーク負荷が推定される毎に、前記ネットワーク負荷が所定の負荷以上であるかを判定し、前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記ノード装置が前記コンテンツを保存可能なデータ容量を決定することを特徴とする。
【００１０】
請求項４に記載の発明は、請求項１から請求項３のいずれか一項に記載の情報処理装置において、前記情報処理装置は、前記配信システムを構成する複数のノード装置の数が所定数増加又は減少したかを判定する判定手段を更に備え、前記推定手段は、前記判定手段により前記複数のノード装置の数が所定数増加又は減少した場合に、前記ネットワーク負荷を推定し、前記第１決定手段は、前記推定手段により前記ネットワーク負荷が推定される毎に、前記ネットワーク負荷が所定の負荷以上であるかを判定し、前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記ノード装置が前記コンテンツを保存可能なデータ容量を決定することを特徴とする。
【００１１】
請求項５に記載の発明は、ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおける情報処理装置のコンピュータに、過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得ステップと、前記取得ステップにより取得された前記変化情報と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定ステップと、前記推定ステップにより推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する決定ステップと、前記複数のノード装置において既に設定されている前記データ容量を、前記決定ステップにより決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信ステップと、を実行させることを特徴とする。
【００１２】
請求項６に記載の発明は、ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムの情報処理装置における情報提供方法であって、前記情報処理装置が、過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得ステップと、前記情報処理装置が、前記取得ステップにより取得された前記変化情報と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定ステップと、前記情報処理装置が、前記推定ステップにより推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する決定ステップと、前記情報処理装置が、前記複数のノード装置において既に設定されている前記データ容量を、前記決定ステップにより決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信ステップと、を含むことを特徴とする。
【００１３】
請求項７に記載の発明は、ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおいて、前記配信システムにおける情報処理装置は、過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得手段と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段と、前記取得手段により取得された前記変化情報と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定手段と、前記推定手段により推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する第１決定手段と、前記複数のノード装置において既に設定されている前記データ容量を、前記第１決定手段により決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信手段と、を備え、前記ノード装置は、前記指令情報を受信する受信手段と、前記受信された指令情報に応じて、前記既に設定されている前記データ容量を、前記指令情報に示される前記データ容量に更新する更新手段と、を備えることを特徴とする。
【発明の効果】
【００１４】
請求項１、５乃至７に記載の発明によれば、推定手段により推定されたネットワーク負荷が所定の負荷以上の場合に、推定されたネットワーク負荷に基づいて、ノード装置がコンテンツを保存可能なデータ容量が決定される。そして、ノード装置において既に設定されているデータ容量の更新する指令を示す指令情報がノード装置に送信される。そのため、各ノード装置において、コンテンツを保存可能なデータ容量をネットワーク負荷に応じた適切なデータ容量に更新させることができる。その結果、無駄に、コンテンツを保存可能なデータ容量が確保されることを防止することができる。
【００１５】
請求項２に記載の発明によれば、配信システムにおいて提供されるサービスの利用が開始される際に、各ノード装置において、コンテンツを保存可能なデータ容量をネットワーク負荷に応じた適切なデータ容量に更新させることができる。
【００１６】
請求項３に記載の発明によれば、所定時間間隔毎に、各ノード装置において、コンテンツを保存可能なデータ容量をネットワーク負荷に応じた適切なデータ容量に更新させることができる。
【００１７】
請求項４に記載の発明によれば、複数のノード装置の接続数が所定数増加又は減少される毎に、各ノード装置において、コンテンツを保存可能なデータ容量をネットワーク負荷に応じた適切なデータ容量に更新させることができる。
【図面の簡単な説明】
【００１８】
【図１】本実施形態に係る配信システムの概要構成例を示す図である。
【図２】（Ａ）は、センターサーバＳＳの概要構成例を示すブロック図である。（Ｂ）は、ノードの概要構成例を示すブロック図である。
【図３】（Ａ）は、センターサーバＳＳの制御部１におけるキャッシュ容量算出処理を示すフローチャートである。（Ｂ）は、ノードの制御部１１におけるキャッシュ容量更新処理を示すフローチャートである。
【発明を実施するための形態】
【００１９】
以下、本発明の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、配信システムに本発明を適用した場合の実施形態である。
【００２０】
［１．配信システムの構成及び動作概要］
始めに、図１を参照して、本実施形態に係る配信システムの構成及び動作概要について説明する。図１は、本実施形態に係る配信システムの概要構成例を示す図である。図１に示すように、本実施形態に係る配信システムＳは、センターサーバＳＳ、及びノード装置Ｎｎ（ｎ＝１，２，３・・・ｋ）等により構成されている。また、センターサーバＳＳは、本発明における情報処理装置の一例である。ノード装置Ｎｎを、以下、「ノード」という。また、センターサーバＳＳ及びノードはネットワークＮＷに接続されている。ネットワークＮＷは、インターネット等からなる。
【００２１】
また、本実施形態では、図１に示す複数の拠点Ｐｎを想定している。この拠点の例としては、例えばカラオケ店舗、学校、会社、住宅、又はその他の施設等が挙げられる。このような拠点Ｐｎの中には、拠点ネットワークＮＬｎが構築されている拠点Ｐｎがある。拠点ネットワークＮＬｎは、例えば、ＬＡＮ（Local Area Network）等から構成される。また、各拠点ネットワークＮＬｎには、ノードと複数の拠点端末Ｔｎ−ｌとが接続されている。ノードは、同じ拠点ネットワークＮＬｎに接続されている拠点端末Ｔｎ−ｌへコンテンツを提供するエッジサーバとしての機能を有する。一方、拠点端末Ｔｎ−ｌは、コンテンツを再生する機能を有する。例えば、拠点Ｐｎがカラオケ店舗の場合、拠点端末Ｔｎ−ｌは、カラオケ用のコンテンツを再生するコマンダである。また、例えば拠点Ｐｎが学校である場合、教材用のコンテンツを再生する視聴端末である。
【００２２】
また、図１に示すように、配信システムＳには、ネットワークＮＷを介して互いに通信可能な複数のノードの参加によりオーバーレイネットワークＯＮが構成されている。オーバーレイネットワークＯＮは、仮想的なリンクを構成する論理的なネットワークである。オーバーレイネットワークＯＮは、特定のアルゴリズム、例えば、分散ハッシュテーブルを利用したアルゴリズムにより実現される。なお、分散ハッシュテーブルを、以下、「ＤＨＴ（Distributed Hash Table）」という。また、オーバーレイネットワークＯＮに参加している各ノードには、ノードＩＤが付与されている。このノードＩＤは、ノードを、オーバーレイネットワークＯＮに参加している他のノードの中から識別する固有の識別情報である。ここで、オーバーレイネットワークＯＮに参加するとは、ＤＨＴを用いたルーティングテーブルに基づいてオーバーレイネットワークＯＮを介して他のノードとの間で各種メッセージを送受信できる状態に稼動することをいう。なお、ＤＨＴを用いたルーティングテーブルについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。
【００２３】
そして、配信システムＳでは、オーバーレイネットワークＯＮを利用してコンテンツを配信する複数のサービスが提供される。ここで、サービスの例としては、カラオケ用のコンテンツを配信するサービス、及びユーザ等により投稿された動画のコンテンツを配信するサービス等がある。センターサーバＳＳは、例えばサービスの提供者の管理端末からアップロードされたコンテンツを配信システムＳに投入する。ここで、コンテンツの投入とは、オーバーレイネットワークＯＮに参加している１以上のノードに、コンテンツを保存させることをいう。ここで、投入されるコンテンツは、オリジナルのコンテンツを複製したレプリカである。また、オリジナルのコンテンツとは、例えばサービスの提供者の管理端末からアップロードされたコンテンツである。投入される各コンテンツにはコンテンツＩＤが付与されている。コンテンツＩＤは、コンテンツを、配信システムＳに投入されている他のコンテンツの中から識別する固有の識別情報である。なお、ノードＩＤ、及びコンテンツＩＤは、例えば、特開２００６−１９７４００号公報等に開示されるように、共通のハッシュ関数によりハッシュ化されて生成される。
【００２４】
また、所定のデータ量より大きいサイズのコンテンツは、所定のデータ量以下のファイルサイズに分割される。その結果、複数のチャンクが生成される。そして、チャンクは、１つのコンテンツとして配信システムＳに投入される。投入される各チャンクにはコンテンツＩＤが付与されている。チャンクのコンテンツＩＤは、チャンクＩＤともいう。また、コンテンツを構成する各チャンクのコンテンツＩＤは、このコンテンツのメタファイルに記述されている。コンテンツのメタファイルとは、このコンテンツを構成する各チャンクを検索するためのファイルである。そして、コンテンツのメタファイルは、１つのコンテンツとして配信システムＳに投入される。投入される各メタファイルにはコンテンツＩＤが付与されている。なお、「コンテンツ、チャンク、又はメタファイル」を、以下、「コンテンツ等」という。
【００２５】
また、各ノードは、コンテンツＩＤに基づき、他のノードに保存されているコンテンツ等を、オーバーレイネットワークＯＮを介して取得可能になっている。このように取得されたコンテンツ等は、ノードに保存される。なお、コンテンツ等を保存するノードを、以下、「コンテンツ保持ノード」という。また、コンテンツ等の所在を示す情報は、インデックス情報として、コンテンツ等の所在を管理しているノードに記憶される。コンテンツ等の所在を管理しているノードを、以下、「ルートノード」という。このインデックス情報には、コンテンツ保持ノードのノード情報とコンテンツＩＤとの組が含まれる。ノード情報には、コンテンツ保持ノードのＩＰアドレス、ポート番号、及びノードＩＤが含まれる。ルートノードは、例えば、コンテンツＩＤと最も近いノードＩＤが割り当てられたノードであるように定められる。コンテンツＩＤと最も近いノードＩＤとは、例えば、ＩＤの上位桁が最も多く一致するノードＩＤである。
【００２６】
そして、ノードが、配信システムＳにおいてコンテンツ等を検索する場合がある。この検索を行うノードを、以下、「ユーザノード」という。ユーザノードは、検索対象のコンテンツ等のコンテンツＩＤを用いて、このコンテンツ等を保存するコンテンツ保持ノードの所在をルートノードに問い合わせる。これにより、ユーザノードは、ルートノードからコンテンツ保持ノードのＩＰアドレス等を受信する。そして、ユーザノードは、コンテンツ保持ノードにアクセスし、コンテンツ等を要求する。これにより、ユーザノードは、コンテンツ保持ノードからコンテンツを取得する。或いは、ルートノードがユーザノードのＩＰアドレス等をコンテンツ保持ノードへ送信する。そして、コンテンツ保持ノードからユーザノードへアクセスするように構成してもよい。なお、ユーザノードによるルートノードへの問い合わせ処理は、例えば特開２００７−０５３６６２号公報等で公知であるので、詳しい説明を省略する。なお、検索対象のコンテンツ等を保存するコンテンツ保持ノードの数が少ない場合がある。この場合、ユーザノードは、センターサーバＳＳにアクセスし、コンテンツ等を要求することになる。
【００２７】
ところで、オーバーレイネットワークＯＮに参加している各ノードには、キャッシュ容量が設定されている。このキャッシュ容量は、上述したように、コンテンツを保存可能なデータ容量の上限値である。各ノードは、このキャッシュ容量以下に収まるようにコンテンツ等を保存する。そして、本実施形態では、各ノードにおけるキャッシュ容量が、センターサーバＳＳにより推定されたネットワーク負荷に応じた適切な容量に更新される。そのため、サービスの利用状況の変化に伴い、無駄のない最適なキャッシュ容量を各ノードに設定させることができる。なお、ネットワーク負荷は、過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報と、ネットワーク負荷に影響を与える要因となる起因要素ｘの変化を示す変化情報と、が用いられて推定される。ここで、過去の所定期間内の何れかの時点におけるネットワーク負荷には、例えば、過去の所定期間内に複数回計測されたネットワーク負荷の中で、最大のネットワーク負荷が該当する。この場合、過去の所定期間内の何れかの時点とは、最大のネットワーク負荷が計測された時点となる。或いは、過去の所定期間内に複数回計測されたネットワーク負荷の中で閾値以上のネットワーク負荷が、過去の所定期間内の何れかの時点におけるネットワーク負荷であってもよい。この場合、過去の所定期間内の何れかの時点とは、閾値以上のネットワーク負荷が計測された時点となる。ここで、閾値以上のネットワーク負荷が複数計測される場合がある。この場合、閾値以上の複数のネットワーク負荷の中で、例えばランダムに選択された何れか一つのネットワーク負荷が、過去の所定期間内の何れかの時点におけるネットワーク負荷に該当することになる。或いは、過去の所定期間内の何れかの時点におけるネットワーク負荷は、過去の所定期間内に複数回計測されたネットワーク負荷の平均値であってもよい。この場合、過去の所定期間内の何れかの時点とは、例えばネットワーク負荷の平均値の算出時点となる。また、ネットワーク負荷に影響を与える要因となる起因要素ｘの例としては、以下の起因要素ａ〜起因要素ｅが挙げられる。
【００２８】
（１）起因要素ａ：投入されたコンテンツのデータ量
コンテンツのデータ量とは、オリジナルのコンテンツのファイルサイズの総和である。投入されたコンテンツのデータ量が大きいときは、各ノードにおけるキャッシュ容量を大きくした方が望ましい。そこで、投入されたコンテンツのデータ量を起因要素ａとして考慮することで、投入されたコンテンツのデータ量の増加又は減少に応じて、各ノードにおけるキャッシュ容量を増加又は減少させることが可能となる。
【００２９】
（２）起因要素ｂ：コンテンツの要求数の偏り度合い
コンテンツの要求数の偏り度合いは、例えば、コンテンツの要求数の標準偏差で表すことができる。コンテンツの要求数の偏り度合いは、言い換えれば、コンテンツの人気の偏り度合いである。例えば、互いに異なる複数のコンテンツの中で、コンテンツの要求が人気のあるコンテンツに集中する場合がある。つまり、コンテンツの人気が偏っている場合がある。この場合、投入されたコンテンツのデータ量が大きくても、各ノードにおけるキャッシュ容量がそれほど大きくなくてもよい。そこで、コンテンツの要求数の偏り度合いを起因要素ｂとして考慮することで、コンテンツの要求数の偏り度合いの増加又は減少に応じて、各ノードにおけるキャッシュ容量を減少又は増加させることが可能となる。
【００３０】
（３）起因要素ｃ：チャンク１つ分のファイルサイズ
チャンク１つ分のファイルサイズが決められている場合がある。この場合において、チャンクにより構成されるコンテンツのファイルサイズに比べて、１つのノードにおけるキャッシュ容量が小さいと、１つのコンテンツを構成するチャンクが複数のノードに分散される。その結果、ノードによるコンテンツの再生待ちが発生してしまう。そのため、コンテンツを構成する各チャンクは、できるだけ１つのノードに保存されることが望ましい。つまり、チャンク１つ分のファイルサイズが大きいときは、各ノードにおけるキャッシュ容量を大きくした方が望ましい。そこで、チャンク１つ分のファイルサイズを起因要素ｃとして考慮することで、チャンク１つ分のファイルサイズの増加又は減少に応じて、各ノードにおけるキャッシュ容量を増加又は減少させることが可能となる。
【００３１】
（４）起因要素ｄ：オーバーレイネットワークＯＮに参加しているノードの数
オーバーレイネットワークＯＮに参加しているノードの数は、言い換えれば、配信システムＳを構成するノードの数である。これらのノードは、オーバーレイネットワークＯＮに所定時間以上参加していることが望ましい。この所定時間は、例えば２４時間程度とされる。オーバーレイネットワークＯＮに所定時間以上参加しているノードの数が少ないと、コンテンツ保持ノードの数が少なくなる。その結果、コンテンツ等の要求がユーザノードからセンターサーバＳＳに集中することになる。そのため、オーバーレイネットワークＯＮに参加しているノードの数が少ないときは、各ノードにおけるキャッシュ容量を大きくした方が望ましい。そこで、オーバーレイネットワークＯＮに参加しているノードの数を起因要素ｄとして考慮することで、ノードの数の増加又は減少に応じて、各ノードにおけるキャッシュ容量を増加又は減少させることが可能となる。なお、オーバーレイネットワークＯＮに参加しているノードの数は、コンテンツ保持ノードの数であってもよい。
【００３２】
（５）起因要素ｅ：投入前後のコンテンツの要求数の差
コンテンツの要求は、コンテンツの投入直後に増加する場合がある。言い換えれば、コンテンツの要求は、コンテンツの投入直後に集中する場合がある。コンテンツの要求の増加は、例えば、投入前後のコンテンツの要求数の差で表すことができる。この差は、例えば、投入前所定時間内のコンテンツの要求数と、投入後所定時間内のコンテンツの要求数との差である。この所定時間は、例えば２４時間程度とされる。投入直後にコンテンツの要求が増加すると、コンテンツ保持ノードやセンターサーバＳＳに負荷がかかる。そのため、投入前後のコンテンツの要求数の差が大きいときは、各ノードにおけるキャッシュ容量を大きくした方が望ましい。そこで、投入前後のコンテンツの要求数の差を起因要素ｅとして考慮することで、投入前後のコンテンツの要求数の差の増加又は減少に応じて、各ノードにおけるキャッシュ容量を増加又は減少させることが可能となる。
【００３３】
［２．センターサーバＳＳの構成及び機能］
次に、図２（Ａ）を参照して、センターサーバＳＳの構成及び機能について説明する。図２（Ａ）は、センターサーバＳＳの概要構成例を示すブロック図である。センターサーバＳＳは、図２（Ａ）に示すように、制御部１、記憶部２、及び通信部３等を備えて構成される。制御部１、記憶部２、及び通信部３はバス４を介して相互に接続されている。記憶部２は、本発明における記憶手段の一例である。
【００３４】
記憶部２は、例えばハードディスクドライブ等から構成される。記憶部２には、オペレーティングシステム、及びサーバプログラム等が記憶されている。なお、サーバプログラムは、例えば、ネットワークＮＷに接続された所定のサーバからダウンロードされるようにしてもよい。或いは、サーバプログラムは、例えば、記録媒体に記録されて記録媒体のドライブを介して読み込まれるようにしてもよい。
【００３５】
また、記憶部２には、オーバーレイネットワークＯＮに投入された各コンテンツ等のオリジナルが記憶されている。また、記憶部２には、オーバーレイネットワークＯＮに参加しているノードの中で、システム管理者等により管理されているノードのノード情報を登録するノードリストが記憶されている。システム運用者等により管理されるノードとしては、基本的にネットワークＮＷに定常的に接続されているノードが挙げられる。ここで、「定常的に」とは、例えば、ノードが故障時又はメンテナンス時以外の時には、オーバーレイネットワークＯＮから離脱せず参加していることを意味する。
【００３６】
また、記憶部２には、制御部１により計測されたネットワーク負荷を示す負荷情報が、計測された時の日付に対応付けられて記憶されている。ここで、ネットワーク負荷は、例えば、ネットワークＮＷに接続されるセンターサーバＳＳの通信回線の有効帯域（ｂｐｓ）で表される。制御部１は、通信部３を介して受信される単位時間当たりのデータ量に基づきネットワーク負荷を計測する。また、記憶部２には、制御部１により取得された上記起因要素ｘが、取得された時の日付に対応付けられて記憶されている。なお、日付には時刻を含んでもよい。更に、記憶部２には、各ノードにおいて設定されているキャッシュ容量を示す情報が記憶されている。
【００３７】
通信部３は、ネットワークＮＷを通じてノード等との間の通信制御を行う。
【００３８】
制御部１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，及びＲＯＭ等から構成される。制御部１は、本発明における取得手段、推定手段、第１決定手段、第２決定手段、判定手段、及び送信手段の一例である。また、制御部１は、時計機能及びタイマ機能を有する。制御部１は、ＣＰＵが記憶部２等に記憶されたプログラムを読み出して実行することにより、後述する処理を行う。
【００３９】
［３．ノードの構成及び機能等］
次に、図２（Ｂ）を参照して、ノードの構成及び機能について説明する。図２（Ｂ）は、ノードの概要構成例を示すブロック図である。ノードは、図２（Ｂ）に示すように、制御部１１、記憶部１２、通信部１３ａ、通信部１３ｂ、及びバッファメモリ１４等を備えて構成される。制御部１１、記憶部１２、通信部１３ａ、通信部１３ｂ、及びバッファメモリ１４はバス１５を介して相互に接続されている。
【００４０】
本実施形態において、ノードは、ネットワークＮＷと拠点ネットワークＮＬｎとの間でＩＰ（Internet Protocol）パケットを中継する中継機器である。この中継機器は、基本的にネットワークＮＷに定常的に接続されているルータ又はＬ３スイッチングハブ等である。また、ノードは、基本的にネットワークＮＷに定常的に接続されているゲートウェイ等の機器であっても良い。なお、ノードは、ネットワークＮＷに定常的に接続されるとは限らないユーザ端末であってもよい。ユーザ端末は、例えば、ユーザが使用する時等の時間だけネットワークＮＷに接続される。ユーザ端末の一例としては、パーソナルコンピュータや携帯端末等が挙げられる。
【００４１】
記憶部１２は、例えばハードディスクドライブ等から構成される。記憶部１２には、オペレーティングシステム、ＩＰパケット中継処理プログラム、及びＰ２Ｐプログラム等が記憶されている。また、記憶部１２には、センターサーバＳＳのＩＰアドレス及びポート番号が記憶されている。また、記憶部１２には、オーバーレイネットワークＯＮで使用されるＤＨＴを用いたルーティングテーブル等が記憶されている。ＤＨＴを用いたルーティングテーブルには、複数のノードのノード情報が登録されている。また、記憶部１２には、コンテンツを保存するためのコンテンツ保存領域が設けられている。このコンテンツ保存領域には、コンテンツを構成するチャンクも保存される。また、コンテンツ保存領域には、コンテンツのメタファイルが保存されてもよい。また、コンテンツ保存領域は、例えばＰ２Ｐプログラムがインストールされることにより設けられる。そして、コンテンツ保存領域には、上述したキャッシュ容量が設定されている。このキャッシュ容量は、センターサーバＳＳからの指令に応じて適切な容量に更新される。
【００４２】
通信部１３ａは、ネットワークＮＷを通じてセンターサーバＳＳ等との間の通信制御を行う。通信部１３ｂは、拠点ネットワークＮＬｎを通じて拠点端末Ｔｎ−ｌとの間の通信制御を行う。また、バッファメモリ１４は、通信部１３ａを介して受信されたコンテンツ等を一時的に蓄積する。
【００４３】
制御部１１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，及びＲＯＭ等から構成される。制御部１は、本発明における受信手段、及び更新手段の一例である。また、制御部１１は、時計機能及びタイマ機能を備える。そして、制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラムを読み出して実行することにより、後述する処理を行う。なお、制御部１１は、ＯＳＩ（Open Systems Interconnection）参照モデルの第３層であるネットワーク層において、他のルータ又はホストからのＩＰパケットを中継する機能を有する。ＩＰパケットを中継する機能は、公知のルータ又はＬ３スイッチングハブ等と同様であるので、詳しい説明を省略する。
【００４４】
［４．配信システムＳの動作］
次に、図３を参照して、本実施形態に係る配信システムＳの動作について説明する。図３（Ａ）は、センターサーバＳＳの制御部１におけるキャッシュ容量算出処理を示すフローチャートである。図３（Ｂ）は、ノードの制御部１１におけるキャッシュ容量更新処理を示すフローチャートである。図３（Ａ）に示すキャッシュ容量算出処理は、例えば所定時間間隔で定期的に実行される。例えば、１時間毎、１日毎、または１月毎に実行される。
【００４５】
図３（Ａ）に示すキャッシュ容量算出処理が開始されると、先ず、制御部１は、ネットワーク負荷の推定に用いる今回の起因要素ｘを取得する（ステップＳ１）。例えば、上述した起因要素ａ〜ｅの中から１以上の起因要素ｘが取得される。どの起因要素ｘが取得されるかは任意に設定可能である。ここで、起因要素ａ〜ｅの夫々の取得方法について説明する。
【００４６】
（１）起因要素ａの場合
この場合、制御部１は、前回のキャッシュ容量算出時から現時点までの期間内に配信ステムＳに投入されたオリジナルのコンテンツのファイルサイズの総和を、起因要素ａとして取得する。配信システムＳに投入されたオリジナルのコンテンツは記憶部２に記憶されている。そのため、制御部１は、オリジナルのコンテンツのファイルサイズの総和を算出することができる。
【００４７】
（２）起因要素ｂの場合
この場合、制御部１は、前回のキャッシュ容量算出時から現時点までの期間内におけるコンテンツの要求数をコンテンツ毎に取得する。コンテンツの要求数は、言い換えれば、ユーザノードからルートノードへの問い合わせの数である。本実施形態では、各コンテンツのルートノードは、ユーザノードからの問い合わせ数をカウントし記憶している。そのため、制御部１は、各コンテンツのルートノードから、上記問い合わせ数を各コンテンツの要求数として取得することができる。そして、制御部１は、各コンテンツの要求数の分散値又は標準偏差を算出し起因要素ｂとして取得する。
【００４８】
（３）起因要素ｃの場合
この場合、制御部１は、現時点におけるチャンク１つ分のファイルサイズを、起因要素ｃとして取得する。配信システムＳに投入されたオリジナルのチャンクは記憶部２に記憶されている。そのため、制御部１は、オリジナルのチャンク１つ分のファイルサイズを取得することができる。
【００４９】
（４）起因要素ｄの場合
この場合、制御部１は、現時点においてオーバーレイネットワークＯＮに所定時間以上参加しているノードの数を、起因要素ｄとして取得する。オーバーレイネットワークＯＮに所定時間以上参加しているノードは、例えば、記憶部２に記憶されているノードリストから決定される。
【００５０】
（５）起因要素ｅの場合
この場合、制御部１は、新たなコンテンツの投入前２４時間以内のコンテンツの要求数と、投入後２４時間以内のコンテンツの要求数とをコンテンツ毎に取得する。例えば、制御部１は、各コンテンツのルートノードから、投入前２４時間以内の問い合わせ数と、投入後２４時間以内の問い合わせ数を、コンテンツの要求数として夫々取得する。そして、制御部１は、投入前２４時間以内の各コンテンツの要求数の総和と、投入後２４時間以内の各コンテンツの要求数の総和との差を、起因要素ｅとして取得する。なお、新たなコンテンツの投入は、前回のキャッシュ容量算出時から現時点までの期間内における投入が対象となる。
【００５１】
こうして取得された起因要素ｘは、取得された時の日付に対応付けられて記憶部２に記憶される。このように記憶された起因要素ｘは、次回のキャッシュ容量算出処理でも用いられる。
【００５２】
次いで、制御部１は、前回の起因要素ｘを記憶部２から取得する（ステップＳ２）。前回の起因要素ｘは、前回のキャッシュ容量算出処理におけるステップＳ１で取得された起因要素ｘである。なお、どの起因要素ｘが取得されるかはステップＳ１と同様である。例えば、ステップＳ１で今回の起因要素ａ及び起因要素ｂが取得された場合、ステップＳ２では前回の起因要素ａ及び起因要素ｂが取得される。
【００５３】
次いで、制御部１は、ステップＳ１で取得された今回の起因要素ｘと、ステップＳ２で取得された前回の起因要素ｘとの間の変化を示す変化値Ｖｘを変化情報として取得する（ステップＳ３）。例えば、起因要素ａ〜ｃ，及びｅの場合、前回の起因要素ｘで今回の起因要素ｘを除した値が変化値Ｖｘとなる。一方、例えば、起因要素ｄの場合、今回の起因要素ｄで前回の起因要素ｄを除した値が変化値Ｖｄとなる。
【００５４】
次いで、制御部１は、前回のキャッシュ容量算出処理時から現時点までの期間内に計測及び記憶されたネットワーク負荷の中で、例えば最大のネットワーク負荷ＬＯｍを示す負荷情報を記憶部２から取得する（ステップＳ４）。なお、制御部１は、前回のキャッシュ容量算出処理時から現時点までの期間内に計測及び記憶されたネットワーク負荷の平均値を負荷情報として取得するように構成してもよい。
【００５５】
次いで、制御部１は、ステップＳ３で取得された変化情報と、ステップＳ４で取得された負荷情報とを用いて、今回のキャッシュ容量算出処理以降のネットワーク負荷ＬＯを推定する（ステップＳ５）。ここで推定されるネットワーク負荷ＬＯは、例えば、下記（i）式により算出される。
【００５６】
ネットワーク負荷ＬＯ＝最大のネットワーク負荷ＬＯｍ×起因要素ｘの変化値Ｖｘ・・・（i）
【００５７】
また、上記ステップＳ３において、複数の起因要素ｘの変化値Ｖｘが取得される場合がある。この場合、各起因要素ｘの変化値Ｖｘが乗算された値が、最大のネットワーク負荷ＬＯに乗算されることになる。例えば、上記ステップＳ３において、起因要素ａの変化値Ｖａと、起因要素ｄの変化値Ｖｄとが取得された場合、推定されるネットワーク負荷ＬＯは、例えば、下記（ii）式により算出される。
【００５８】
ネットワーク負荷ＬＯ＝最大のネットワーク負荷ＬＯｍ×起因要素ａの変化値Ｖａ×起因要素ｄの変化値Ｖｄ・・・（ii）
【００５９】
また、複数の起因要素ｘの変化値Ｖｘが取得される場合、各起因要素ｘの変化がネットワーク負荷の変化に影響を与える度合いは、起因要素ｘ毎に異なる場合がある。そのため、推定されるネットワーク負荷ＬＯは、ネットワーク負荷の変化に影響を与える度合いを考慮することが望ましい。この場合、ネットワーク負荷の変化に影響を与える度合いを表す係数Ｔｘは、起因要素ｘ毎に決定される。なお、各係数Ｔｘは、例えば、過去にデータとして蓄積された、ネットワーク負荷の変化と各起因要素ｘの変化との関係に基づいて決定される。そして、例えば、各起因要素ｘの係数Ｔｘは、各起因要素ｘの変化値Ｖｘに乗算されることになる。この場合、例えば、（ii）式は、下記（iii）式となる。
【００６０】
ネットワーク負荷ＬＯ＝最大のネットワーク負荷ＬＯｍ×起因要素ａの変化値Ｖａ×起因要素ａの係数Ｔａ×起因要素ｂの変化値Ｖｂ×起因要素ｂの係数Ｔｂ・・・（iii）
【００６１】
なお、コンテンツの投入直後だけ、一時的に最適なキャッシュ容量をノードに割り当てたい場合がある。この場合、上記（i）〜（iii）式において、上記起因要素ｅが優先されて最大のネットワーク負荷ＬＯｍに乗算される。
【００６２】
次いで、制御部１は、上記ステップＳ５で推定されたネットワーク負荷ＬＯと、ネットワーク負荷の基準値ＬＯｚとの差を算出する。ここで、ネットワーク負荷の基準値ＬＯｚは、例えば、上記ステップＳ４で取得された最大のネットワーク負荷ＬＯｍである。或いは、例えば、ネットワーク負荷の基準値ＬＯｚは、例えばサーバプログラムの起動時における初期化処理で設定される固定値であってもよい。そして、制御部１は、ネットワーク負荷ＬＯとネットワーク負荷の基準値ＬＯｚとの差が閾値以上であるか否かを判定する（ステップＳ６）。言い換えれば、推定されたネットワーク負荷ＬＯが所定の負荷以上または所定の負荷以下であるか否かが判定される。ここで、「所定の負荷」とは、例えば、上記ステップＳ４で取得された最大のネットワーク負荷ＬＯｍに上記閾値を加算した値、または最大のネットワーク負荷ＬＯｍから閾値を減算した値である。そして、制御部１は、ネットワーク負荷ＬＯと、ネットワーク負荷の基準値ＬＯｚとの差が閾値以上であると判定した場合には（ステップＳ６：ＹＥＳ）、ステップＳ７に進む。一方、制御部１は、ネットワーク負荷ＬＯとネットワーク負荷の基準値ＬＯｚとの差が閾値以上でないと判定した場合には（ステップＳ６：ＮＯ）、キャッシュ容量算出処理を終了する。つまり、推定されたネットワーク負荷ＬＯが所定の負荷未満である場合、ノードにおけるキャッシュ容量の更新が行われない。これは、ネットワーク負荷の変化が閾値未満と少ないにも関わらず、ノードに設定されるキャッシュ容量が過多に更新されることを防止するためである。
【００６３】
そして、ステップＳ７では、制御部１は、上記ステップＳ５で推定されたネットワーク負荷ＬＯに基づいて、ノードに設定させる最適なキャッシュ容量Ｃを決定する。
【００６４】
例えば、ネットワーク負荷ＬＯの推定に起因要素ａが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間において投入されたコンテンツのデータ量に増加に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。また、例えば、ネットワーク負荷ＬＯの推定に起因要素ｂが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間におけるコンテンツの要求数の偏り度合いの減少に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。また、例えば、ネットワーク負荷ＬＯの推定に起因要素ｃが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間におけるチャンク１つ分のファイルサイズの増加に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。また、例えば、ネットワーク負荷ＬＯの推定に起因要素ｄが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間におけるノードの数の増加に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。また、例えば、ネットワーク負荷ＬＯの推定に起因要素ｅが用いられる場合がある。この場合、上記推定されるネットワーク負荷ＬＯの値は、過去の所定期間における投入前後のコンテンツの要求数の差の増加に応じて、過去のネットワーク負荷ＬＯｍの値よりも大きくなる。そして、制御部１は、上記ステップＳ７おいて、ネットワーク負荷ＬＯの値が過去のネットワーク負荷ＬＯｍの値よりも大きければ、キャッシュ容量Ｃを現状のキャッシュ容量Ｃｚよりも大きく決定する。ここで、現状のキャッシュ容量Ｃｚとは、現在、各ノードにおいて設定されているキャッシュ容量である。
【００６５】
なお、このキャッシュ容量は、例えば、下記（iv）式により算出される。
【００６６】
キャッシュ容量Ｃ＝現状のキャッシュ容量Ｃｚ−キャッシュ容量の変化値Ｖｃ・・・（iv）
【００６７】
ここで、キャッシュ容量の変化値Ｖｃは、上記ステップＳ５で推定されたネットワーク負荷ＬＯをネットワーク負荷の基準値ＬＯｚに一致させる場合に増加又は減少するキャッシュ容量を示す。また、キャッシュ容量の変化値Ｖｃは、プラス（＋）の符号の場合と、マイナス（−）の符号の場合がある。キャッシュ容量の変化値Ｖｃは、例えば、下記（v）式により算出される。
【００６８】
キャッシュ容量の変化値Ｖｃ＝（現状のキャッシュ容量Ｃｚ×起因要素ｄの変化値Ｖｄ×起因要素ｄの係数Ｔｄ）／（ネットワーク負荷の基準値ＬＯｚ−ネットワーク負荷ＬＯ）・・・（v）
【００６９】
以上のように決定された最適なキャッシュ容量Ｃは、決定された時の日付に対応付けられて記憶部２に記憶される。このように記憶されたキャッシュ容量Ｃは、次回のキャッシュ容量算出処理でキャッシュ容量Ｃｚとして用いられる。
【００７０】
次いで、制御部１は、更新指令メッセージを生成する（ステップＳ８）。この更新指令メッセージは、複数のノードにおいて既に設定されているキャッシュ容量Ｃｚを、上記ステップＳ７で決定されたキャッシュ容量Ｃに更新する指令を示す。なお、更新指令メッセージは、本発明における指令情報の一例である。
【００７１】
次いで、制御部１は、上記ステップＳ８で生成された更新指令メッセージを、オーバーレイネットワークＯＮに参加している複数のノードへ送信する（ステップＳ９）。例えば、制御部１は、記憶部２に記憶されているノードリストに登録されているノードへ更新指令メッセージを送信する。或いは、制御部１は、例えばＤＨＴマルチキャストにより、オーバーレイネットワークＯＮに参加しているノードへ更新指令メッセージを送信する。なお、ＤＨＴマルチキャストは、特開２００７−０５３６６２号公報等で公知であるので、詳しい説明を省略する。
【００７２】
こうして送信された更新指令メッセージをノードが受信すると、図３（Ｂ）に示すキャッシュ容量更新処理が開始される。図３（Ｂ）に示すキャッシュ容量更新処理では、ノードの制御部１１は、受信された更新指令メッセージからキャッシュ容量Ｃを示すデータを取得する（ステップＳ１１）。次いで、ノードの制御部１１は、現在設定されているキャッシュ容量Ｃｚを、上記ステップＳ１１で取得されたデータに示される最適なキャッシュ容量Ｃに更新する（ステップＳ１２）。つまり、更新指令メッセージを受信した各ノードにおいて最適なキャッシュ容量が割り当てられる。例えば、制御部１１は、キャッシュ容量を設定している設定ファイルに記述されたキャッシュ容量Ｃｚをキャッシュ容量Ｃに書き換える。
【００７３】
以上説明したように、上記実施形態によれば、センターサーバＳＳにより推定されたネットワーク負荷ＬＯが所定の負荷以上の場合に、推定されたネットワーク負荷ＬＯに基づいて、ノードに設定させるキャッシュ容量Ｃが決定される。そして、決定されたキャッシュ容量Ｃに更新する指令を示す更新指令メッセージが各ノードへ送信される。そのため、サービスの利用状況の変化に伴い、無駄のない最適なキャッシュ容量Ｃを各ノードに設定させることができる。つまり、各ノードで設定されるキャッシュ容量を必要最低限に抑えることができる。その結果、各ノードの限られたリソースを最小利用することが可能となり、オーバーレイネットワークＯＮを利用するピアツーピア型の配信システムＳに対して、後からサービスを追加していくことが容易となる。また、システム管理者等が、サービス規模や利用状況をあらかじめ予測またはその都度見直してキャッシュ容量を決める必要がなくなる。また、利用状況の変化に伴うセンターサーバＳＳへの集中アクセスを軽減することができる。更に、最適なキャッシュ容量Ｃが自動的に最適化されることで、その容量に応じて課金するビジネスを提供することができる。
【００７４】
なお、上記実施形態において、図３（Ａ）に示すキャッシュ容量算出処理は、所定時間間隔で実行されるように構成した。この構成により、所定の時間間隔で各ノードで設定されるキャッシュ容量Ｃを最適化することができる。この構成の別の例として、センターサーバＳＳの制御部１は、ノードリストを参照して、オーバーレイネットワークＯＮに参加しているノードの数が所定数増加又は減少したか否かを判定する。そして、制御部１は、オーバーレイネットワークＯＮに参加しているノードの数が所定数増加又は減少した場合に、図３（Ａ）に示すキャッシュ容量算出処理を開始するように構成してもよい。オーバーレイネットワークＯＮに参加しているノードの数の増減は、コンテンツの要求数等に影響を与えるケースが多い。そのため、オーバーレイネットワークＯＮに参加しているノードの数が所定数増加又は減少される毎に各ノードにおけるキャッシュ容量を更新させる構成によれば、センターサーバＳＳへの負荷集中を防止することができる。
【００７５】
更に上記構成の別の例として、センターサーバＳＳの制御部１は、配信システムＳに新たなコンテンツを投入する場合に、図３（Ａ）に示すキャッシュ容量算出処理を開始するように構成してもよい。なお、コンテンツの投入は、例えば、配信システムＳにおいて提供されるサービスの利用が開始される際に行われる。この構成の場合、センターサーバＳＳの制御部１は、配信システムＳにこれから投入するコンテンツのデータ量を決定する。このコンテンツのデータ量は、例えば、オリジナルのコンテンツのファイルサイズの総和である。そして、センターサーバＳＳの制御部１は、過去に配信システムＳに投入されたオリジナルのコンテンツのファイルサイズの総和Ｄαに対する、上記決定したコンテンツのデータ量Ｄβの増加の割合を変化情報として取得する。ここで、コンテンツのデータ量の増加の割合は、（Ｄα＋Ｄβ）／Ｄαで表すことができる。また、過去に配信システムＳに投入されたオリジナルのコンテンツは記憶部２に記憶されている。そのため、制御部１は、オリジナルのコンテンツのファイルサイズの総和を算出することができる。そして、センターサーバＳＳの制御部１は、図３（Ａ）に示すキャッシュ容量算出処理のステップＳ５において、コンテンツのデータ量の増加の割合を示す変化情報と、上記ステップＳ４で取得された負荷情報とを用いて、今回のキャッシュ容量算出処理以降のネットワーク負荷ＬＯを推定する。ここで推定されるネットワーク負荷ＬＯは、例えば、下記（vi）式により算出される。
【００７６】
ネットワーク負荷ＬＯ＝最大のネットワーク負荷ＬＯｍ×コンテンツのデータ量の増加の割合・・・（vi）
【００７７】
例えば新たなサービスの利用が開始される際に、配信システムＳに新たにコンテンツが投入されると、一時的にそのコンテンツに対して取得要求が集中する場合がある。そのため、配信システムＳに新たなコンテンツが投入される毎に各ノードにおけるキャッシュ容量を更新させる構成によれば、センターサーバＳＳへの負荷集中を防止することができる。なお、上記（vi）式において起因要素ｘをコンテンツのデータ量の増加の割合に乗算してネットワーク負荷ＬＯを算出するように構成してもよい。
【００７８】
なお、上記実施形態においては、オーバーレイネットワークＯＮに、ＤＨＴを利用したピアツーピアネットワークを適用したが、これに限られるものではない。例えば、他のオーバーレイネットワークを用いたシステムが適用されてもよい。ＤＨＴを利用しないピアツーピアシステムとしては、例えば、ハイブリッド型のピアツーピアシステムがある。
【符号の説明】
【００７９】
１，１１ 制御部
２，１２ 記憶部
３，１３ａ，１３ｂ 通信部
ＳＳ センターサーバ
Ｎｎ ノード
ＮＷ ネットワーク
ＯＮ オーバーレイネットワーク
Ｓ 配信システム
【特許請求の範囲】
【請求項１】
ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおける情報処理装置であって、
過去の所定期間における前記配信システムを構成する複数のノード装置の数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得手段と、
前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段と、
前記取得手段により取得された前記変化情報と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定手段と、
前記推定手段により推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する第１決定手段と、
前記複数のノード装置において既に設定されている前記データ容量を、前記第１決定手段により決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記記憶手段は、過去に前記配信システムに投入されたコンテンツのデータ量を記憶しており、
前記情報処理装置は、前記配信システムにおいて提供されるサービスの利用が開始される際に前記配信システムに投入されるコンテンツのデータ量を決定する第２決定手段を更に備え、
前記取得手段は、前記過去に前記配信システムに投入された前記コンテンツのデータ容量に対する、前記第２決定手段により決定された前記コンテンツのデータ量の増加の割合を前記変化情報として取得し、
前記推定手段は、前記取得手段により取得された前記変化情報に示される前記コンテンツのデータ量の増加の割合と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記推定手段は、所定時間間隔で前記ネットワーク負荷を推定し、
前記第１決定手段は、前記推定手段により前記所定時間間隔で前記ネットワーク負荷が推定される毎に、前記ネットワーク負荷が所定の負荷以上であるかを判定し、前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記ノード装置が前記コンテンツを保存可能なデータ容量を決定することを特徴とする請求項１または請求項２に記載の情報処理装置。
【請求項４】
前記情報処理装置は、前記配信システムを構成する複数のノード装置の数が所定数増加又は減少したかを判定する判定手段を更に備え、
前記推定手段は、前記判定手段により前記複数のノード装置の数が所定数増加又は減少した場合に、前記ネットワーク負荷を推定し、
前記第１決定手段は、前記推定手段により前記ネットワーク負荷が推定される毎に、前記ネットワーク負荷が所定の負荷以上であるかを判定し、前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記ノード装置が前記コンテンツを保存可能なデータ容量を決定することを特徴とする請求項１から請求項３のいずれか一項に記載の情報処理装置。
【請求項５】
ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおける情報処理装置のコンピュータに、
過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得ステップと、
前記取得ステップにより取得された前記変化情報と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定ステップと、
前記推定ステップにより推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する決定ステップと、
前記複数のノード装置において既に設定されている前記データ容量を、前記決定ステップにより決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信ステップと、
を実行させることを特徴とするプログラム。
【請求項６】
ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムの情報処理装置における情報提供方法であって、
前記情報処理装置が、過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得ステップと、
前記情報処理装置が、前記取得ステップにより取得された前記変化情報と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定ステップと、
前記情報処理装置が、前記推定ステップにより推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する決定ステップと、
前記情報処理装置が、前記複数のノード装置において既に設定されている前記データ容量を、前記決定ステップにより決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信ステップと、
を含むことを特徴とする情報提供方法。
【請求項７】
ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおいて、
前記配信システムにおける情報処理装置は、
過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得手段と、
前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段と、
前記取得手段により取得された前記変化情報と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定手段と、
前記推定手段により推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する第１決定手段と、
前記複数のノード装置において既に設定されている前記データ容量を、前記第１決定手段により決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信手段と、
を備え、
前記ノード装置は、
前記指令情報を受信する受信手段と、
前記受信された指令情報に応じて、前記既に設定されている前記データ容量を、前記指令情報に示される前記データ容量に更新する更新手段と、
を備えることを特徴とする配信システム。
【請求項１】
ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおける情報処理装置であって、
過去の所定期間における前記配信システムを構成する複数のノード装置の数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得手段と、
前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段と、
前記取得手段により取得された前記変化情報と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定手段と、
前記推定手段により推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する第１決定手段と、
前記複数のノード装置において既に設定されている前記データ容量を、前記第１決定手段により決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記記憶手段は、過去に前記配信システムに投入されたコンテンツのデータ量を記憶しており、
前記情報処理装置は、前記配信システムにおいて提供されるサービスの利用が開始される際に前記配信システムに投入されるコンテンツのデータ量を決定する第２決定手段を更に備え、
前記取得手段は、前記過去に前記配信システムに投入された前記コンテンツのデータ容量に対する、前記第２決定手段により決定された前記コンテンツのデータ量の増加の割合を前記変化情報として取得し、
前記推定手段は、前記取得手段により取得された前記変化情報に示される前記コンテンツのデータ量の増加の割合と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記推定手段は、所定時間間隔で前記ネットワーク負荷を推定し、
前記第１決定手段は、前記推定手段により前記所定時間間隔で前記ネットワーク負荷が推定される毎に、前記ネットワーク負荷が所定の負荷以上であるかを判定し、前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記ノード装置が前記コンテンツを保存可能なデータ容量を決定することを特徴とする請求項１または請求項２に記載の情報処理装置。
【請求項４】
前記情報処理装置は、前記配信システムを構成する複数のノード装置の数が所定数増加又は減少したかを判定する判定手段を更に備え、
前記推定手段は、前記判定手段により前記複数のノード装置の数が所定数増加又は減少した場合に、前記ネットワーク負荷を推定し、
前記第１決定手段は、前記推定手段により前記ネットワーク負荷が推定される毎に、前記ネットワーク負荷が所定の負荷以上であるかを判定し、前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記ノード装置が前記コンテンツを保存可能なデータ容量を決定することを特徴とする請求項１から請求項３のいずれか一項に記載の情報処理装置。
【請求項５】
ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおける情報処理装置のコンピュータに、
過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得ステップと、
前記取得ステップにより取得された前記変化情報と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定ステップと、
前記推定ステップにより推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する決定ステップと、
前記複数のノード装置において既に設定されている前記データ容量を、前記決定ステップにより決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信ステップと、
を実行させることを特徴とするプログラム。
【請求項６】
ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムの情報処理装置における情報提供方法であって、
前記情報処理装置が、過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得ステップと、
前記情報処理装置が、前記取得ステップにより取得された前記変化情報と、前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定ステップと、
前記情報処理装置が、前記推定ステップにより推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する決定ステップと、
前記情報処理装置が、前記複数のノード装置において既に設定されている前記データ容量を、前記決定ステップにより決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信ステップと、
を含むことを特徴とする情報提供方法。
【請求項７】
ネットワークに接続された複数のノード装置に複数のコンテンツが分散保存され、前記ネットワークを介して前記コンテンツが配信される配信システムにおいて、
前記配信システムにおける情報処理装置は、
過去の所定期間における前記複数のノード装置の接続数の変化又は前記配信システムに投入されたコンテンツのデータ量の変化を示す変化情報を取得する取得手段と、
前記過去の所定期間内の何れかの時点におけるネットワーク負荷を示す負荷情報を記憶する記憶手段と、
前記取得手段により取得された前記変化情報と、前記記憶手段に記憶された前記負荷情報とを用いて、ネットワーク負荷を推定する推定手段と、
前記推定手段により推定された前記ネットワーク負荷が所定の負荷以上の場合に、前記推定された前記ネットワーク負荷に基づいて、前記複数のノード装置が前記コンテンツを保存可能なデータ容量を決定する第１決定手段と、
前記複数のノード装置において既に設定されている前記データ容量を、前記第１決定手段により決定された前記データ容量に更新する指令を示す指令情報を前記複数のノード装置へ送信する送信手段と、
を備え、
前記ノード装置は、
前記指令情報を受信する受信手段と、
前記受信された指令情報に応じて、前記既に設定されている前記データ容量を、前記指令情報に示される前記データ容量に更新する更新手段と、
を備えることを特徴とする配信システム。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１２−２２１０１６（Ｐ２０１２−２２１０１６Ａ）
【公開日】平成２４年１１月１２日（２０１２．１１．１２）
【国際特許分類】
【出願番号】特願２０１１−８３３７２（Ｐ２０１１−８３３７２）
【出願日】平成２３年４月５日（２０１１．４．５）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
【公開日】平成２４年１１月１２日（２０１２．１１．１２）
【国際特許分類】
【出願日】平成２３年４月５日（２０１１．４．５）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
[ Back to top ]