(57)【要約】  ネットワーク上の他のコンテンツ配信サーバから負荷情報（他サーバ情報）を受信して記憶し、自コンテンツ配信サーバの負荷情報（自サーバ情報）を記憶する負荷情報交換及び記憶手段と、前記自サーバ情報に基づいて、自コンテンツ配信サーバの空きリソースの有無を判定する判定手段と、前記判定手段が空きリソースが無いと判断した時に、他のコンテンツ配信サーバの中から、自コンテンツ配信サーバより負荷が低い一以上のコンテンツ配信サーバを、前記自サーバ情報と前記他サーバ情報に基づいて選択する選択手段と、選択された前記他のコンテンツ配信サーバに、コンテンツ配信要求の対象であるコンテンツの、前記コンテンツ配信要求を発信したユーザ端末に対する配信を依頼するリダイレクト手段と、を有することを特徴とするコンテンツ配信サーバ。
2011024930.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上の他のコンテンツ配信サーバから負荷情報（他サーバ情報）を受信して記憶し、自コンテンツ配信サーバの負荷情報（自サーバ情報）を記憶する負荷情報交換及び記憶手段と、
前記自サーバ情報に基づいて、自コンテンツ配信サーバの空きリソースの有無を判定する判定手段と、
前記判定手段が空きリソースが無いと判断した場合に、他のコンテンツ配信サーバの中から、自コンテンツ配信サーバより負荷が低い一以上の他のコンテンツ配信サーバを、前記自サーバ情報と前記他サーバ情報に基づいて選択する選択手段と、
選択された前記他のコンテンツ配信サーバに、コンテンツ配信要求の対象であるコンテンツの、前記コンテンツ配信要求を発信したユーザ端末に対する配信を依頼するリダイレクト手段と、
を有することを特徴とするコンテンツ配信サーバ。
【請求項２】
前記リダイレクト手段による、一定期間内での配信の依頼回数の最大値を、前記一定期間の直前の一定期間Ｔ内に受信した前記他サーバ情報と前記自サーバ情報から得た全コンテンツ配信サーバの平均リソース使用率と、前記自コンテンツ配信サーバの平均リソース使用率に基づいて算出するリダイレクト数算出手段と、
依頼回数が前記最大値に達しているか否かを判定し、前記依頼回数が前記最大値に達している場合は、前記リダイレクト手段に依頼を行わせない比較手段と、を有することを特徴とする請求項１のコンテンツ配信サーバ。
【請求項３】
前記選択手段は、
前記コンテンツを構成するセグメント毎に、
一つの他の配信サーバを選択することを特徴とする請求項１又は２いずれかに記載のコンテンツ配信サーバ。
【請求項４】
前記リダイレクト数算出手段は、
前記最大値、Ｒｍａｘを、
前記一定期間の直前の一定期間Ｔ内で得た
前記全コンテンツ配信サーバの平均リソース使用率Ｕ、
前記自コンテンツ配信サーバの平均リソース使用率Ｕｉ、
前記自コンテンツ配信サーバの平均同時接続数Ｃｉ、
一定期間Ｔ内の平均セグメントサイズＳを用いて、
（１）Ｕ≧Ｕｉのとき、Ｒｍａｘ＝０
（２）Ｕ＜Ｕｉのとき、Ｒｍａｘ＝（Ｕｉ−Ｕ）×Ｃｉ×Ｔ／Ｓ
により算出することを特徴とする請求項２記載のコンテンツ配信サーバ。
【請求項５】
自サーバ情報を前記ネットワーク上の複数の他のコンテンツ配信サーバに送信する前記負荷情報交換及び記憶手段を備える、複数の、請求項１乃至４の何れかのコンテンツ配信サーバと、
複数の、前記ユーザ端末を包含するコンテンツ配信システム。
【請求項６】
ネットワーク上の他のコンテンツ配信サーバから負荷情報（他サーバ情報）を受信して記憶し、自コンテンツ配信サーバの負荷情報（自サーバ情報）を記憶し、
前記自サーバ情報に基づいて、自コンテンツ配信サーバの空きリソースの有無を判定し、
空きリソースが無いと判断した場合に、
他のコンテンツ配信サーバの中から、
自コンテンツ配信サーバより負荷が低い一以上の他のコンテンツ配信サーバを前記自サーバ情報と前記他サーバ情報に基づいて選択し、
選択された前記他のコンテンツ配信サーバに、コンテンツ配信要求の対象であるコンテンツの、前記コンテンツ配信要求を発信したユーザ端末に対する配信を依頼することを特徴とするコンテンツ配信方法。
【請求項７】
一定期間内の配信の依頼回数の最大値を、前記一定期間の直前の一定期間Ｔ内に受信した前記他サーバ情報と前記自サーバ情報から得た全コンテンツ配信サーバの平均リソース使用率と、前記自コンテンツ配信サーバの平均リソース使用率に基づいて算出し、依頼回数が前記最大値に達しているか否かを判定し、前記依頼回数が前記最大値に達している場合は、前記配信の依頼を行わないことを特徴とする請求項６のコンテンツ配信方法。
【請求項８】
前記選択においては、前記コンテンツを構成するセグメント毎に、一つ以上の他の配信サーバを選択することを特徴とする請求項５又は６いずれかに記載のコンテンツ配信方法。
【請求項９】
前記最大値、Ｒｍａｘを、
前記一定期間の直前の一定期間Ｔ内で得た
前記全コンテンツ配信サーバの平均リソース使用率Ｕ、
前記自コンテンツ配信サーバの平均リソース使用率Ｕｉ、
前記自コンテンツ配信サーバの平均同時接続数Ｃｉ、
一定期間Ｔ内の平均セグメントサイズＳを用いて、
（１）Ｕ≧Ｕｉのとき、Ｒｍａｘ＝０
（２）Ｕ＜Ｕｉのとき、Ｒｍａｘ＝（Ｕｉ−Ｕ）×Ｃｉ×Ｔ／Ｓ
により算出することを特徴とする請求項７記載のコンテンツ配信方法。
【請求項１０】
ネットワーク上の他のコンテンツ配信サーバから負荷情報（他サーバ情報）を受信して記憶し、自コンテンツ配信サーバの負荷情報（自サーバ情報）を記憶する負荷情報交換及び記憶処理と、
前記自サーバ情報に基づいて、自コンテンツ配信サーバの空きリソースの有無を判定する判定処理と、
前記判定手段が空きリソースが無いと判断した時に、他のコンテンツ配信サーバの中から、自コンテンツ配信サーバより負荷が低い一以上の他のコンテンツ配信サーバを、前記自サーバ情報と前記他サーバ情報に基づいて選択する選択処理と、
選択された前記他のコンテンツ配信サーバに、コンテンツ配信要求の対象であるコンテンツの、前記コンテンツ配信要求を発信したユーザ端末に対する配信を依頼するリダイレクト処理と、
をコンピュータに実行させることを特徴とするコンテンツ配信プログラム。
【請求項１１】
前記リダイレクト処理による一定期間内での、配信の依頼回数の最大値を、
前記一定期間内の直前の一定期間Ｔ内に受信した前記他サーバ情報と前記自さーバ情報から得た全コンテンツ配信サーバの平均リソース使用率と、前記自コンテンツ配信サーバの平均リソース使用率に基づいて算出するリダイレクト数算出処理と、
依頼回数が前記最大値に達しているか否かを判定し、前記依頼回数が前記最大値に達している場合は、前記配信の依頼を行わせない比較処理と
を前記コンピュータに実行させる請求項１０のコンテンツ配信プログラム。
【請求項１２】
前記選択処理は、
前記コンテンツを構成するセグメント毎に、
一つの他の配信サーバを選択することを特徴とする請求項１０又は１１のいずれかに記載のコンテンツ配信プログラム。
【請求項１３】
前記リダイレクト数算出処理は、
前記最大値、Ｒｍａｘを、
前記一定期間の直前の一定期間Ｔ内で得た
前記全コンテンツ配信サーバの平均リソース使用率Ｕ、
前記自コンテンツ配信サーバの平均リソース使用率Ｕｉ、
前記自コンテンツ配信サーバの平均同時接続数Ｃｉ、
一定期間Ｔ内の平均セグメントサイズＳを用いて、
（１）Ｕ≧Ｕｉのとき、Ｒｍａｘ＝０
（２）Ｕ＜Ｕｉのとき、Ｒｍａｘ＝（Ｕｉ−Ｕ）×Ｃｉ×Ｔ／Ｓ
により算出することを特徴とする請求項１１に記載のコンテンツ配信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンテンツ配信システム、コンテンツ配信方法及びコンテンツ配信用プログラムに係り、特にネットワークを介して映像などのコンテンツを配信するコンテンツ配信システム、コンテンツ配信方法及びコンテンツ配信用プログラムに関する。
【背景技術】
【０００２】
近年、ブロードバンドネットワークの普及に伴い、ネットワークを介して映像などのコンテンツを端末に配信することによって実現される、見たいときに見たい映像を視聴できるサービスの必要性が高まっている。そのようなサービスを実現する技術としては、例えばネットワーク上に、予め映像コンテンツが蓄積された映像配信サーバを設置し、ユーザ端末からの配信要求に応じて、その映像配信サーバから映像コンテンツを配信する映像コンテンツ配信システムがある。
また、上記の映像コンテンツ配信システムに類似のコンテンツ配信システムとしては、ウェブ配信サーバが配信要求元のユーザ端末に対してウェブコンテンツ（ホームページ、テキストデータなど）を配信するウェブシステムがある。
このウェブシステムでは、ウェブ配信サーバに対して情報配信の要求が集中すると、ウェブ配信サーバの処理能力の限界を超えてしまうため、ユーザ端末は情報配信のために長い時間待たされることがある。或いは、このような場合、ユーザ端末が、全く配信を受けられないといった障害が発生することがある。
そのため、多数の受信端末が接続される配信サーバは、その配信サーバの負荷を分散又は軽減させ、安定して情報配信を継続できるシステムの構築を、必要としている。
ここで、配信サーバの負荷集中を解決する手段としては、クライアント（受信端末）と配信サーバとでデータの送受信を行うネットワーク上に負荷分散装置を利用する手法が一般的に用いられている。
例えば、特開２００３−２４２０５７号公報（以下、特許文献１という）は負荷分散装置を用いたコンテンツ配信システムを開示している。この特許文献１記載のコンテンツ配信システムには、同じウェブコンテンツを配信可能な複数台のウェブ配信サーバと、負荷分散装置とが設置される。負荷分散装置は、それぞれのウェブ配信サーバのＩＰアドレスの登録を受けると共に、負荷分散装置自身にも１つのＩＰアドレスの設定を受ける。クライアントとしての受信端末に、負荷分散装置のＩＰアドレスは、ウェブコンテンツを配信しているウェブ配信サーバのアドレスとして公開される。
また、負荷分散装置は、ウェブ配信サーバの負荷状況を常に収集し、処理能力に余裕のある空きウェブ配信サーバを把握しておく。
一方、受信端末は、負荷分散装置をウェブ配信サーバとみなして、配信要求を送信する。
負荷分散装置は、受け取った配信要求を空きウェブサーバに転送する。すると、空きウェブ配信サーバは、配信要求に対する処理結果を負荷分散装置に出力する。負荷分散装置は、受信した処理結果を要求の配信元である受信端末に出力する。
このような構成のコンテンツ配信システムは、複数台のウェブ配信サーバを有し、負荷分散装置によりそれらのウェブ配信サーバを管理させ、更にデータの送信又は受信を行うことで、アクセスが集中してもウェブ配信サーバの負荷を分散させることができる。
しかしながら、映像配信サーバの場合は、上記の負荷分散装置を利用することは困難である。テキストデータ等の少ないデータの配信の場合は、負荷分散装置が配信データを受信端末に送信する処理は短時間で済み、送信処理に要する計算資源の量は少ない。しかし、映像配信の場合は、映像配信サーバが送信する映像データが大量であり、更に継続的な映像データを負荷分散装置が受信端末に転送し続けなければならない。このため、転送処理が負荷分散装置の計算資源等を大量に消費し、結果として負荷分散装置自体の負荷が高くなってしまうことが、映像配信サーバの場合に上記の負荷分散装置を利用することが困難なことの理由である。
また、受信端末の接続数が多い場合にも負荷分散装置を使用すると、負荷分散装置がボトルネックとなって、映像配信サーバは、映像を安定して配信できなくなってしまう。ところで、上述のようなコンテンツ配信システムが、例えば番組コンテンツ等の映像データを配信する場合、映像を構成するデータ量はウェブ配信サーバ等が配信するテキストデータ等と比較して極端にデータ量が多い。また、コンテンツ配信システムは、そのデータを継続的に配信し続ける必要がある。
そのため、映像の配信処理は配信サーバのＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ；中央処理装置）の使用時間や、ネットワーク帯域等の計算資源を大量に消費する。従って、映像データを配信する映像配信サーバの負荷は高くなりやすい。
そこで、映像配信サーバを構成する際には、映像配信サーバの負荷分散の技術がより重要となる。
そこで、映像配信サーバの負荷分散の技術としては、負荷分散装置ではなく、特開２００５−３３２３７３号公報（以下、特許文献２という）記載のコンテンツ配信システムのような、メディア・ディレクタを利用することが考えられる。特許文献２記載のコンテンツ配信システムは、一つのメディア・ディレクタ及び複数のメディア・エンジンで構成される。このような構成を有するコンテンツ配信システムは次のように動作する。
それぞれのメディア・エンジンは、メディア・コンテンツ用記憶装置、ネットワークを通じてメディア・コンテンツを取り出すための通信チャネル、及びネットワークを通じてメディア・コンテンツをストリーミングするための通信チャネルを組み込んでいる。メディア・ディレクタは、選択されたメディア・エンジンによるネットワークを通じてのメディア・コンテンツの取り出しを指令し、メディア・エンジンに格納されたコンテンツを追跡するために適合されたコントローラを備える。このコントローラは、メディア・ステーションに接続されたメディア・コンソールから要求されたコンテンツを、ストリーミング要求に対応するコンテンツを格納するメディア・エンジンのうちの選択された１つのメディア・エンジンへリダイレクトすることに適合している。
しかし、規模が大きくなると、映像配信サービスは、負荷分散装置の場合と同様の理由から、特許文献２記載のコンテンツ配信システムのようにメディア・ディレクタを利用することも困難となる。
このような理由から、映像配信サービスは、負荷分散装置やメディア・ディレクタを利用することなく映像配信サービスの負荷を分散し、配信サーバの負荷を軽減するよう制御する手段が必要である。
そこで、負荷分散装置やメディア・ディレクタを利用することなく映像配信サービスの負荷を分散するコンテンツ配信システムとして、特開２００６−１１３７３５号公報（以下、特許文献３という）記載のコンテンツ配信システムが提案されている。このコンテンツ配信システムは、コンテンツ配信サーバが配信する配信データとしてコンテンツデータにコンテンツデータの識別子とサーバの負荷の状況とを付加したものを受信端末に送信する。受信端末はコンテンツ配信サーバの負荷状況を判断して負荷の軽い別のコンテンツ配信サーバに接続し、コンテンツデータの受信を継続して行う。
また、特開２００８−７１１５６号公報（以下、特許文献４）記載の負荷分散システムは、複数のサーバ間で負荷情報を交換する手段を有している。この発明は、この負荷情報の交換によって、自サーバの負荷が負荷目標値を超えるときには、他のサーバで処理を実行させるという処理の融通を行っている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
特許文献１に記載されているコンテンツ配信システムは、リクエスト負荷と配信負荷が集中する負荷分散装置には高い処理能力が求められる。負荷分散装置に高い処理能力を持たせることは、配信システムのコストを増大させることになる。また負荷分散装置の処理能力がボトルネックとなり、コンテンツ配信システムが、映像を安定して配信できないという事態も発生する。
その詳細は、以下に説明される。
特許文献１に記載されているコンテンツ配信システムでは、ユーザ端末からＶＩＰ（Ｖｉｒｔｕａｌ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスが設定された配信リクエストパケットを受信した負荷分散装置が、それぞれのサーバが保持しているＲＩＰ（Ｒｏｕｔｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を選択的に決定し、ＶＩＰに付け替えて送信することにより各サーバの負荷を分散させる。
したがって、負荷分散装置は、常にサーバの負荷状況を把握する必要があるため、モニタリング負荷が高くなる。このモニタリング負荷の増大が、コンテンツ配信システムに、映像の安定配信を阻む原因となっている。
更に、負荷分散装置は、配信リクエストパケットの宛先ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスを、当該ＶＩＰに関連付けられている、複数のサーバに設定されたＲＩＰの中から、１台のサーバのＲＩＰを選択し、このＲＩＰをＶＩＰに付け替えて送信する。この際に負荷分散装置は、高い処理能力が必要となる。
また、特許文献２に記載されているコンテンツ配信システムでは、メディア・ディレクタにリクエスト負荷と配信管理負荷が集中するため、メディア・ディレクタにも高い処理能力が求められる。このことは、配信システムのコストをさらに増大させることにつながる。また、メディア・ディレクタの処理能力がボトルネックとなり、コンテンツ配信システムが、映像を安定して配信できないという事態も発生する。
その理由は、以下に説明される。
特許文献２に記載されているコンテンツ配信システムでは、メディア・ディレクタが、メディア・ステーションに接続されたメディア・コンソールからコンテンツを要求される。メディアディレクタはこの要求に応え、ストリーミング要求に対応するコンテンツを格納するメディア・エンジンのうちの一つを選択して、そのメディア・エンジンへリダイレクトする。
そのため、コンテンツ所在情報とメディア・エンジンの負荷状況を常に把握する必要があるので、モニタリング負荷が高くなる。
更に、メディアディレクタは、コンテンツを複数のセグメントに分割して、セグメント単位で配信を行う。そのため、あるセグメントの配信が完了したタイミングで次のセグメントを配信するメディア・エンジンを選択して、そのメディア・エンジンへリダイレクトする必要がある。そのため、サーバ選択処理とメディア・コンソールの視聴状況を把握するための処理負荷が大きくなる。
更に、特許文献３に記載されているコンテンツ配信システムでは、ユーザ端末からコンテンツ配信サーバに対して負荷状況の問い合わせが頻繁に生じる。そのため、コンテンツ配信サーバに多大な負荷がかかり、特にユーザ端末の接続数が多い場合に配信システム全体としての配信能力が著しく低下するという問題がある。
その理由は、以下に説明される。
特許文献３に記載されているコンテンツ配信システムでは、個々のユーザ端末は、コンテンツデータを配信する複数の配信サーバにコンテンツデータの配信要求を行なう。ユーザ端末は、配信要求した配信サーバから得られる配信データから、配信サーバの負荷情報を取得して、負荷比較結果に基づいて配信サーバを決定する。そのため、コンテンツ配信サーバには多大な負荷がかかる。
特許文献４に記載されている負荷分散システムは、コンテンツの配信に関係しない。
本発明は以上の点に鑑みなされたものである。本発明は、負荷分散装置やメディア・ディレクタ、ユーザ端末から配信サーバに対して負荷状況の問い合わせ、を必要とせずに、負荷の分散、平滑化及び視聴品質の劣化防止を図ることを目的とする。
本発明は、上記の目的を果たすコンテンツ配信システム、コンテンツ配信方法及びコンテンツ配信用プログラムを提供する。
【課題を解決するための手段】
【０００４】
上記の目的を達成するため、
本発明のコンテンツ配信システムは、
ネットワーク上の複数の配信サーバ同士で負荷情報を随時交換し、
前記負荷情報と自サーバの負荷情報とを記憶する負荷情報交換及び記憶手段と、
コンテンツ配信要求を受けた配信サーバが、
前記負荷情報に基づいて、自らの空きリソースの有無を判定する判定手段と、
前記判定手段が空きリソースが無いと判断した時に、他の配信サーバの中から、
自配信サーバより負荷が低い一以上の他の配信サーバを選択する選択手段と、
前記コンテンツ配信要求を発信したユーザ端末に対し、選択された前記他の配信サーバに、前記コンテンツ配信要求の対象であるコンテンツの配信を引き継ぐリダイレクト手段と、を有することを特徴とする。
また、上記の目的を達成するため、
本発明のコンテンツ配信方法は、
ネットワーク上の複数の配信サーバ同士で負荷情報を随時交換し、
前記負荷情報と自サーバの負荷情報とを記憶し、
コンテンツ配信要求を受けた配信サーバが、
前記負荷情報に基づいて、
自らの空きリソースが無いと判断した場合に、
他の配信サーバの中から、
自配信サーバより負荷が低い一以上の他の配信サーバを選択し、
前記コンテンツ配信要求を発信したユーザ端末に対し、
選択された前記他の配信サーバに、前記コンテンツ配信要求の対象であるコンテンツの配信を引き継ぐことを特徴とする。
また、上記の目的を達成するため、本発明のコンテンツ配信プログラムは、
ネットワーク上の複数の配信サーバ同士で負荷情報を随時交換し、
前記負荷情報と自サーバの負荷情報とを記憶する負荷情報交換及び記憶処理と、
コンテンツ配信要求を受けた配信サーバが、
前記負荷情報に基づいて、自らの空きリソースの有無を判定する判定処理と、
前記判定手段が空きリソースが無いと判断した時に、他の配信サーバの中から、
自配信サーバより負荷が低い一以上の他の配信サーバを選択する選択処理と、
前記コンテンツ配信要求を発信したユーザ端末に対し、
選択された前記他の配信サーバに、前記コンテンツ配信要求の対象であるコンテンツの配信を引き継ぐリダイレクト処理と、
をコンピュータに実行させることを特徴とする。
【発明の効果】
【０００５】
本発明によれば、コンテンツ配信システム、コンテンツ配信方法及びコンテンツ配信用プログラムは、負荷分散装置やメディア・ディレクタを用いることなく、またユーザ端末から配信サーバに対して負荷状況の問い合わせを行うことなく、配信サーバ負荷の分散及び平滑化を図るとともに、視聴品質の劣化を防止することができる。
【図面の簡単な説明】
【０００６】
【図１】図１は本発明のコンテンツ配信システムの一実施形態の構成図である。
【図２】図２は、図１のコンテンツ配信システムにおいてコンテンツ配信要求先の配信サーバに空きリソースがある場合の動作を説明するブロック図である。
【図３】図３は、図１のコンテンツ配信システムにおいてコンテンツ配信要求先の配信サーバに空きリソースが無い場合の動作を説明するブロック図である。
【図４】図４は、図１のコンテンツ配信システムにおいて、配信サーバがリダイレクト実績がリダイレクト数の上限値に達していることを確認した場合の動作を説明するブロック図である。
【図５】図５は、図１のコンテンツ配信システムにおいて、配信サーバがリダイレクト実績がリダイレクト数の上限値に達していないことを確認した場合の動作を説明するブロック図である。
【図６】図６は、図１のコンテンツ配信システムにおける配信サーバ間の負荷情報交換時の動作説明図である。
【図７】図７は、図１中の負荷情報管理部に格納される配信サーバ毎の現在の負荷情報データの一例を示す図である。
【図８】図８は本発明のコンテンツ配信システムの他の一実施形態の構成図である。
【発明を実施するための形態】
【０００７】
次に、発明を実施するための第１の実施形態について図面を参照して詳細に説明する。
図１は、本発明になるコンテンツ配信システムの第１の実施形態の構成図を示す。
本実施形態のコンテンツ配信システム１は、コンテンツ配信サーバ群１０（以降コンテンツ配信サーバを単に配信サーバとも記す）とユーザ端末群２０とがネットワーク３０を介して双方向に接続されている。
ユーザ端末群２０は、例えばｎ台（ｎは２以上の自然数）からなる。
配信サーバ群１０は、例えばｍ台（ｍは２以上の自然数）の配信サーバ１０−１〜１０−ｍからなる。
配信サーバ１０−１〜１０−ｍは、それぞれ固有のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスを有している。
また、配信サーバ１０−１〜１０−ｍは、それぞれ同一構成であり、コンテンツ格納部１００、負荷情報交換部１０１、負荷情報管理部１０２、リダイレクト数算出部１０３、リダイレクト部１０４、配信サーバ選択部１０５、コンテンツ格納部１０６からなる。
コンテンツ格納部１００には、映像コンテンツのコンテンツデータが格納される。ある配信サーバに格納されるコンテンツデータは、他の配信サーバに格納されるコンテンツデータと同じであってもよく、また異なってもよい。
また、コンテンツデータは少なくとも一片のコンテンツデータ（セグメント）として格納されていればよい。ここで、「一片」とは、一連の動画を示すコンテンツデータを示す単位を意味する。
また、コンテンツデータは、図１に示すように配信サーバ１０−１〜１０−ｍのそれぞれのコンテンツ格納部１００に個別に格納されていてもよいが、配信サーバ１０−１〜１０−ｍが共有するストレージに格納されていてもよい。
負荷情報交換部１０１は、配信サーバ１０−１〜１０−ｍ間で互いが保持する配信サーバ毎の配信負荷情報を定期的に又は非定期的に随時交換し合うことで、リアルタイムで他の配信サーバの負荷情報を収集して、負荷情報管理部１０２に格納する。
負荷情報管理部１０２は、収集した他の配信サーバの負荷情報を自配信サーバの負荷情報と共に格納し、随時更新する。
リダイレクト数算出部１０３は、或る一定の期間毎に設定されるリダイレクト数の上限値を算出する。ここで、「リダイレクト」とは、自配信サーバのコンテンツ配信先のユーザ端末が次のセグメントを要求するタイミングで、自配信サーバが他の配信サーバに配信を引き継がせる動作を意味する。引き継ぐ先の他の配信サーバは、配信サーバ選択部１０５によって決定される。
リダイレクト部１０４は、或る一定の期間毎に設定されるリダイレクト数の上限値を超えない範囲において、リダイレクトを行う機能を有する。ここでのリダイレクトは、自配信サーバのコンテンツ配信先のユーザ端末が次のセグメントを要求するタイミングで、自配信サーバが他の配信サーバに配信を引き継がせることを意味する。具体的には、リダイレクト部１０４は、配信サーバ選択部１０５によって選択された、自配信サーバより負荷の低いどれか一つの他の配信サーバにリダイレクトする。
なお、リダイレクト部１０４はリダイレクトする毎に、リダイレクト回数をカウントする。そして、リダイレクト部１０４は、リダイレクト確認（リダイレクト実績確認）の際に、そのカウント値がリダイレクト数算出部１０３が算出したリダイレクト数の上限値Ｒｍａｘ以上であるか否かを比較判定する。そして、リダイレクト部１０４は、カウント値が上限値Ｒｍａｘに達していない時にはリダイレクトを行う。
配信サーバ選択部１０５は、負荷の低い他の配信サーバを選択する。配信サーバ選択部１０５は、自配信サーバより負荷の低い他の配信サーバが複数存在する場合は、例えば、予め定めた順番により、あるいはランダムに、あるいは最も負荷の低い他の配信サーバを選択する。その選択方法は、どのような方法であってもよい。
コンテンツ配信部１０６は、ユーザ端末２０−１〜２０−ｎに対してコンテンツデータ（セグメントの集合）を配信する。
ユーザ端末２０−１〜２０−ｎは、それぞれコンテンツ配信要求送信部、
配信されたコンテンツデータの受信部、コンテンツデータである映像データを表示する表示部、配信要求切り替え部を少なくとも備えている。配信要求切り替え部は、コンテンツ配信要求先の配信サーバからリダイレクトの情報を受信したときは、コンテンツ配信要求先をリダイレクトされた配信サーバに切り替えてコンテンツ配信要求を行う。なお、本発明におけるコンテンツデータは映像データに限定されるものではないが、この実施の形態では配信サーバ１０−１〜１０−ｍは、映像データを受信する映像配信サーバであるものとして説明する。
次に、図２、図３、図４、図５、図６のブロック図を参照して本実施形態の全体の動作について詳細に説明する。ここでは、説明の便宜上、図１のユーザ端末群２０中の任意の一台のユーザ端末２０−１と、配信サーバ群１０中の任意の３台の配信サーバ１０−１、１０−２及び１０−３との間での動作について説明する。
まず、コンテンツ配信要求先の配信サーバに空きリソースがある場合の動作について、図２と共に説明する。
図２は、ユーザ端末２０−１が配信サーバ１０−１に対してコンテンツＡのセグメント００１の配信を要求したものとする（ステップＳ１）。
すると、コンテンツ配信要求先の配信サーバ１０−１は、その負荷情報交換部１０１が、負荷情報管理部１０２に格納されている負荷情報を参照して自配信サーバに空きリソースがあるかを確認する（ステップＳ２）。
配信サーバ１０−１が、自配信サーバに空きリソースがある（リソース使用率が１００％ではない）と判断した場合は、ユーザ端末２０−１に対して、コンテンツＡのセグメント００１をコンテンツ配信部１０６により配信する（ステップＳ３）。なお、コンテンツＡはコンテンツ格納部１００に格納されている。
次に、コンテンツ配信要求先の配信サーバに空きリソースが無い場合の動作について、図３を用いて説明する。
図３において、ユーザ端末２０−１が、配信サーバ１０−１に対してコンテンツＡのセグメント００１を要求したものとする（ステップＳ１１）。すると、コンテンツ配信要求先の配信サーバ１０−１は、その負荷情報交換部１０１が負荷情報管理部１０２に格納されている負荷情報を参照して自配信サーバに空きリソースがあるかを確認する（ステップＳ１２）。
そして、配信サーバ１０−１は、自配信サーバに空きリソースがない（リソース使用率が１００％である）と判断した場合は、自配信サーバより負荷の低いどれか一つの他の配信サーバ（ここでは配信サーバ１０−２）を選択する（ステップ１２）。この選択は配信サーバ選択部１０５によって負荷情報管理部１０２に格納されている他の配信サーバの負荷情報に基づいて、行われる。
その選択された配信サーバ１０−２に、ユーザ端末２０−１の次のセグメント要求のタイミングでリダイレクト部１０４によりリダイレクトする（ステップＳ１３）。これにより、ユーザ端末２０−１が配信サーバ１０−２に対してコンテンツＡのセグメント００１の配信を要求する（ステップＳ１４）。
すると、配信サーバ１０−２は、自配信サーバに空きリソースがあることを確認する（ステップＳ１５）。空きリソースがあると判断した場合は、配信要求元のユーザ端末２０−１に対してコンテンツＡのセグメント００１をコンテンツ配信部１０６により配信する（ステップＳ１６）。なお、コンテンツＡのセグメント１００は、自配信サーバ内のコンテンツ格納部１００に格納されている。
次に、配信サーバが、リダイレクト実績がリダイレクト数の上限値に達していることを確認した場合の動作について図４を用いて説明する。図４において、配信サーバ１０−１は、配信要求元のユーザ端末２０−１に対するコンテンツＡのセグメント００１の配信が完了に近付くと（ステップＳ２１）、リダイレクト部１０４によりリダイレクト実績を確認する（ステップＳ２２）。
これにより、配信サーバ１０−１のリダイレクト部１０４は、リダイレクト実績がリダイレクト数算出部１０３により算出されたリダイレクト数の上限値に達していることを確認する。そして、その後のユーザ端末２０−１の次のセグメント要求に応じて、コンテンツ格納部１００に格納されているコンテンツＡの次のセグメント００２をコンテンツ配信部１０６により配信する（ステップＳ２３）。
次に、配信サーバが、リダイレクト実績がリダイレクト数の上限値に達していないことを確認した場合の動作について図５と共に説明する。
図５において、配信サーバ１０−１は、ユーザ端末２０−１に対するコンテンツＡのセグメント００１の配信が完了に近付くと（ステップＳ３１）、リダイレクト部１０４によりリダイレクト実績を確認する（ステップＳ３２）。
これにより、配信サーバ１０−１のリダイレクト部１０４は、リダイレクト実績がリダイレクト数算出部１０３により算出されたリダイレクト数の上限値に達していないことを確認する。その場合は、配信サーバ選択部１０５によって負荷情報管理部１０２に格納されている他の配信サーバの負荷情報に基づいて、自配信サーバより負荷の低いどれか一つの他の配信サーバ（配信サーバ１０−３）を選択する（ステップＳ３３）。
続いて、配信サーバ１０−１は、ユーザ端末２０−１の次のセグメント要求のタイミングでリダイレクト部１０４により配信サーバ１０−３にリダイレクトする（ステップＳ３４）。
すると、ユーザ端末２０−１が配信サーバ１０−３に対してコンテンツＡの次のセグメント００２の配信を要求する（ステップＳ３５）。
この配信要求に従い、配信サーバ１０−３は自配信サーバに空きリソースがあるかを確認する（ステップＳ３６）。配信サーバ１０−３は、自配信サーバに空きリソースがあることを確認した場合は、配信要求元のユーザ端末２０−１に対して、配信サーバ１０−３内のコンテンツ格納部１００に格納されているコンテンツＡのセグメント００２をコンテンツ配信部１０６により配信する（ステップＳ３７）。
次に、配信サーバ１０−１〜１０−３間の負荷情報交換時の動作について図６を用いて説明する。
図６において、配信サーバ１０−１、１０−２、１０−３は、それぞれ負荷情報交換部１０１により、事前に設定された配信サーバと定期的に負荷情報を交換し、交換した負荷情報データを負荷情報管理部１０２に格納する。
図７は、負荷情報管理部１０２に格納される配信サーバ毎の現在の負荷情報データの一例を示す。
図７に示すように、負荷情報データは、ＩＰアドレスと負荷とからなる。図７に示す負荷はリソース使用率を示している。ここで、リソース使用率は
リソース使用率＝配信中のデータのビットレート［ｂｐｓ］÷配信容量［ｂｐｓ］
で表される。従って、リソース使用率が「１．０」の場合は、負荷が１００％となって、それ以上配信できないことを表す。
本実施形態において、負荷情報交換時には、保有する自配信サーバ及び他配信サーバ全ての情報を近隣の配信サーバだけと送受信し合うことで、近隣の配信サーバ全体の負荷状況を効率的にリアルタイムで把握することができる。これにより、全配信サーバ１０−１〜１０−ｍ間で負荷情報を交換しなくて済む。この結果、配信サーバ１０−１〜１０−３は、負荷分散装置やメディア・ディレクタを用いることなく、自配信サーバよりも負荷の低い配信サーバにリダイレクトする自律分散処理が可能となる。このことは、配信サーバ負荷の分散及び平滑化を図ると共に、視聴品質の劣化を防止することを可能とする。なお、ここでリダイレクトする場合とは、図３で説明した自配信サーバに空きリソースがない場合及び図５で説明したリダイレクト数の上限値にリダイレクトの回数が達していない場合である。
これにより、本実施形態は、負荷分散装置やメディア・ディレクタにリクエスト負荷と配信負荷が集中するという事態を起こさないようにすることができる。すなわち、本実施形態は、負荷分散装置やメディア・ディレクタに高い処理能力が求めることを必要としない。このように本実施形態は、配信システムのコストが大きくなることを防ぐことを可能とする。また、本実施形態は、負荷分散装置やメディア・ディレクタの処理能力がボトルネックとなり、映像を安定して配信できなくなることを防ぐことを可能とする。
また、個々のユーザ端末がコンテンツデータを配信する複数の配信サーバのうち所望の配信サーバにコンテンツデータの配信要求を行い、得た配信データから、その配信サーバの負荷情報を取得し、負荷比較結果に基づいて配信サーバを決定する方法では、次のような問題がある。この方法では、ユーザ端末から配信サーバに対して負荷状況の問い合わせが頻繁に生じて、配信サーバに多大な負荷がかかる。特にユーザ端末の接続数ｎが多い場合にコンテンツ配信システム全体としての配信能力が著しく低下する。
これに対し、本実施形態は、以下のような理由により、ユーザ端末から配信サーバへの負荷状況の問い合わせを省き、ユーザ端末の接続数ｎが多い場合にも、コンテンツ配信システム全体としての配信能力の低下現象を防止することができる。その理由とは、配信サーバ１０−１〜１０−ｍのうち近隣の配信サーバ間で負荷情報交換することで、効率的にリアルタイムで負荷状況を把握できることにある。こうして把握した配信サーバ１０−１〜１０−ｍ全体の負荷状況に基づいて、配信要求先の配信サーバが自配信サーバよりも負荷の低い配信サーバにリダイレクトする自律分散処理を行うことができる。
次に、発明を実施するための第３の実施形態について図８を参照して詳細に説明する。
本実施形態は、ネットワーク上の他のコンテンツ配信サーバから負荷情報（他サーバ情報）を受信して記憶し、自コンテンツ配信サーバの負荷情報（自サーバ情報）を記憶する負荷情報交換及び記憶部３１０と、前記自サーバ情報に基づいて、自コンテンツ配信サーバの空きリソースの有無を判定する判定部３２０と、前記判定手段が空きリソースが無いと判断した場合に、他のコンテンツ配信サーバの中から、自コンテンツ配信サーバより負荷が低い一以上の他のコンテンツ配信サーバを、前記自サーバ情報と前記他サーバ情報に基づいて選択する選択部３３０と、選択された前記他のコンテンツ配信サーバに、コンテンツ配信要求の対象であるコンテンツの、前記コンテンツ配信要求を発信したユーザ端末に対する配信を依頼するリダイレクト部３４０と、を有することを特徴とするコンテンツ配信サーバである。
本実施形態では、負荷分散装置やメディア・ディレクタを用いることなく、またユーザ端末から配信サーバに対して負荷状況の問い合わせを行うことなく、配信サーバ負荷の分散及び平滑化を図るとともに、視聴品質の劣化を防止することができる。
【実施例１】
【０００８】
次に、具体的な実施例を用いて発明を実施する形態の動作を説明する。
この実施例は、情報更新周期Ｔ［ｓｅｃ］の間の、全配信サーバ１０−１〜１０−ｍの平均リソース使用率をＵ、としている。また、この実施例は、ｉ番目（ｉ＝１〜ｍ）の配信サーバ１０−ｉの平均リソース使用率をＵｉ、配信サーバ１０−ｉの平均同時接続数をＣｉ、としている。また、この実施例は、平均セグメントサイズをＳ［ｓｅｃ］と、している。
このとき、この実施例は、配信サーバ１０−ｉにおいて、次の周期のリダイレクト数の上限値Ｒｍａｘを導出する方法を下記に示した方法としている。
ここで、「リダイレクト」とは、配信サーバ１０−ｉが、コンテンツ配信先のｊ番目（ｊ＝１〜ｎ）のユーザ端末２０−ｊの所定のタイミングで、他の配信サーバに配信を引き継ぐ動作を意味する。
「所定のタイミング」は、ユーザ端末２０−ｊが現在配信されているセグメントの次のセグメントを要求するタイミングである。
配信サーバ１０−ｉは、前の周期の間に収集した負荷情報データを基に、全配信サーバ１０−１〜１０−ｍの平均リソース使用率Ｕ、配信サーバ１０−ｉの平均リソース使用率Ｕｉ、配信サーバ１０−ｉの平均同時接続数Ｃｉをそれぞれ導出する。また、平均セグメントサイズＳは事前に知っているものとする。
このとき、配信サーバ１０−ｉは、次の情報更新周期の開始時点で、以下のようにリダイレクト数の上限値Ｒｍａｘを算出する。
（１）Ｕ≧Ｕｉのとき、Ｒｍａｘ＝０
（２）Ｕ＜Ｕｉのとき、Ｒｍａｘ＝（Ｕｉ−Ｕ）×Ｃｉ×Ｔ／Ｓ
（１）の場合は、全配信サーバの平均リソース使用率Ｕが、個々のコンテンツ配信要求先の配信サーバ１０−ｉの平均リソース使用率Ｕｉ以上である場合である。このときは、その配信サーバ１０−ｉは負荷が低いので、リダイレクト数の上限値Ｒｍａｘは「０」に設定され、その配信サーバはリダイレクトを行わない。
（２）の場合は、個々のコンテンツ配信要求先の配信サーバ１０−ｉの平均リソース使用率Ｕｉが全配信サーバの平均リソース使用率Ｕよりも大きい場合である。このときには、リダイレクト数の上限値Ｒｍａｘは、期間Ｔにおいて視聴される予定のセグメント数「Ｃｉ×Ｔ／Ｓ」のうち、負荷平均値からの超過分「Ｕｉ−Ｕ」を他の配信サーバにリダイレクトする値に設定される。
上記のように、この実施例では、セグメント単位でリダイレクト数の上限値Ｒｍａｘを基準としてリダイレクトするか否かを配信サーバが判定する。そのために、この実施例は、セグメント単位のきめ細やかな負荷分散を実現すると同時に、負荷が低い配信サーバが過剰なリダイレクトを行うことを抑制する。この結果、本実施例によれば、特にユーザ端末の接続数が多い場合においても、配信サーバは映像を安定してユーザ端末に配信することができる。
なお、本発明は以上の実施形態及び実施例に限定されるものではない。
例えば、図１に示した配信サーバ１０−１〜１０−ｍの各ブロックの動作や、
図２〜図５で説明した各ステップの動作を、配信サーバ内のコンピュータにより実現させるコンテンツ配信用プログラムも包含するものである。
以上、実施形態及び実施例を参照して本願発明を説明したが、本願発明は上記実施形態及び実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、２００９年８月２４日に出願された日本出願特願２００９−１９２７３９を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０００９】
本発明は、配信サーバ間の自律分散処理によって、配信サーバ負荷の平滑化を図るとともに、視聴品質の劣化を防止することを可能とする。
また、本発明をストリーミング配信サーバに適用することにより、ユーザ端末の視聴品質の向上が、期待できる。
特にインターネット等のＩＰ網において、大規模で音声や映像のストリーミング配信や、ポータルサービス等を行う際には、本発明を適用することにより、多数のユーザ端末からのリクエストに対応するときに、上記の大きな効果が期待できる。
【符号の説明】
【００１０】
１０  配信サーバ群（コンテンツ配信サーバ群）
１０−１〜１０−ｍ  配信サーバ（コンテンツ配信サーバ）
２０  ユーザ端末群
２０−１〜２０−ｎ  ユーザ端末
３０  ネットワーク
１００  コンテンツ格納部
１０１  負荷情報交換部
１０２  負荷情報格納部
１０３  リダイレクト数算出部
１０４  リダイレクト部
１０５  配信サーバ選択部
１０６  コンテンツ配信部
【図１】
2011024930.tif 000003
【図２】
2011024930.tif 000004
【図３】
2011024930.tif 000005
【図４】
2011024930.tif 000006
【図５】
2011024930.tif 000007
【図６】
2011024930.tif 000008
【図７】
2011024930.tif 000009
【図８】
2011024930.tif 000010
【国際調査報告】
2011024930.tif 000011
2011024930.tif 000012
2011024930.tif 000013