JP5153685B2 - コンテンツ配信システムおよび配信制御サーバ - Google Patents

Description

本発明は、ネットワークを介して接続されたテレビやＰＣ、携帯電話等のクライアントからのリクエストに応答して、映像（動画像）や音声などの、配信中のリアルタイム性が要求されるコンテンツを配信する配信システムに関し、特にコンテンツの配信を制御する配信制御サーバに関する。

ネットワークを介したコンテンツ配信システムの普及に伴い、動画像や音声など配信するコンテンツの容量の増大や、配信サービスを受けるクライアントからの要求の一時的な増大などにより、コンテンツを配信するサーバの負荷が高くなり、配信サービスの継続が困難な状況に陥ることがある。このような状況に対応するために、高負荷の第1のサーバにコンテンツ配信を要求したクライアントに対して、第1のサーバは第２のサーバのURLを応答情報として送信し、そのクライアントは受信したURLを用いて第２のサーバから配信サービスを受ける技術がある（特許文献１）。この技術では、第２のサーバは、クライアントからの要求に対応して、第１のサーバに対して第２のサーバへのコンテンツ配信を要求する。

特開2005−27009

特許文献1に開示される技術では、クライアントからの要求に応答する段階で第1のサーバから第２のサーバへコンテンツを配信するので、クライアントに対する応答時間（コンテンツの配信を開始するまでの時間）が長くなる。また第1のサーバは第２のサーバの負荷状態を不知であるので、第２のサーバも高負荷な状態にある状況が発生する。

クライアントに対する応答時間を短くするために、コンテンツ配信システムの多くは、会員クライアントを地域などでグループ化し、グループ化したクライアント対応に、サービスする配信サーバを配置している。コンテンツ配信のネットワーク上のルータなどの通信機器による遅延や障害の影響を少なくするために、配信サーバからクライアントへのネットワーク経路上の通信機器の数が少なくなるように、グループ化されている。このように応答時間の短いサービスを実現するために、配信するコンテンツデータは各配信サーバに予め格納されている。一方、クライアントが対応する配信サーバを個々に知る必要がないように、クライアントからの配信要求を一つの配信制御サーバで受けるようにしている。

このようなコンテンツ配信システムにおいては、新たなサーバがクライアントから要求を受けて、最初に要求を受けたサーバに配信要求する必要はないが、配信サーバの高負荷な状態は発生する。したがって、高負荷な状態が発生した配信サーバを制御することが必要となる。

本発明は、以下のような態様のコンテンツ配信システム及び配信制御サーバである。コンテンツ配信システムは、クライアント、配信サーバ及び配信制御サーバとを含む。クライアントは、クライアント自身を特定する情報及びコンテンツを特定する情報を含むリクエストを送信する。配信制御サーバは、クライアントからのリクエストを受信し、配信サーバが配信中のコンテンツ配信処理に係る負荷が、負荷配分により予め決定された負荷の上限値以上であり、上限値を超えるリスクを考慮して設定された許容値未満であり、かつコンテンツ配信処理以外の特別処理を実行中でないとの条件の下で、前記配信サーバに前記リクエストを転送する。配信サーバは、転送されたリクエストの受信に応答して、クライアントにコンテンツを配信する。クライアントは、配信サーバからコンテンツを受信する。

本発明の他の態様は、負荷の上限値及び許容値の各々は、配信サーバが同時に配信するスケジュール(コンテンツ)の数及び同時に配信するコンテンツの使用伝送帯域幅の合計である。

本発明のさらに他の態様は、配信制御サーバは、配信サーバによるコンテンツの配信を含めた配信サーバの負荷が予め定めた許容時間内に解消することを、前述の条件に加える。

本発明によれば、配信サーバのコンテンツ配信に配分された能力を超えた高負荷な状態が発生しても、配信サーバはそのときの負荷状況に応じてコンテンツ配信することができる。

コンテンツ配信システムの概略構成図である。 コンテンツ配信システムの動作概略の説明図である。 対応クライアントテーブルの構成例である。 サーバ順序テーブルの構成例である。 配信スケジュールテーブルの構成例である。 サーバ状態テーブルの構成例である。 配信スケジュール管理部の処理フローチャートである。

以下、図面を参照してこの発明の実施形態を説明する。本実施形態は、映像(動画像)や音声などの、配信中（配信開始から終了まで）のリアルタイム性が要求されるコンテンツの配信を対象にしたコンテンツ配信システムの一例である。図１は、コンテンツ配信システム５の概略構成図である。コンテンツ配信システム５は、コンテンツ配信を制御する配信制御サーバ１、コンテンツを配信する配信サーバ２（２a、２b、２c、・・・）及び配信制御サーバ１へコンテンツ配信をリクエスト（配信要求）し、配信サーバ２からコンテンツ配信を受けるクライアント３（３a、３b、３c、・・・）が通信ネットワーク４を介して接続する構成である。クライアント３は、テレビ、ＰＣ、携帯電話などのネットワークを介して配信制御サーバ１や配信サーバ２との通信機能を持った映像機器や音声機器である。映像機器や音声機器は、録画・録音機能を備えていることが望ましい。

図２は、コンテンツ配信システム５の動作概略の説明図である。クライアント３のリクエスト送信部３０は、ユーザにより指定されたコンテンツの配信要求(リクエスト)を配信制御サーバ１へ送信する。ユーザによるコンテンツの指定は、コンテンツの一覧表示から選択するなどによる。

配信制御サーバ１は、クライアント３からのリクエストをリクエスト受付部１１で受信する。リクエストには、リクエストを送信したクライアント３を特定する情報（アドレスやユーザ識別子など）及びリクエストされたコンテンツを特定する情報（コンテンツの名称や識別子など）が含まれる。配信スケジュール管理部１０は、受信したリクエストから、リクエストを送信したクライアント３及びリクエストされたコンテンツを特定する。特定したクライアント３に対して、特定したコンテンツを配信する配信サーバ２を決定する。配信要求部１２は、決定した配信サーバ２に対して、特定したコンテンツの特定したクライアント３への配信要求を送信する。配信要求の送信は、受信したリクエストをリダイレクトする。

配信サーバ２は、コンテンツ配信部２１が受信した配信要求に応じたコンテンツを特定された(リクエストを送信した)クライアント３へ配信する。配信されたコンテンツをクライアント３は、コンテンツ受信部３１が受信し、表示装置やスピーカへ出力する。

以上の動作概略において、配信制御サーバ１の配信スケジュール管理部１０は、配信サーバ２の決定に際して、対応クライアントテーブル１６、サーバ順序テーブル１７、配信スケジュールテーブル１８、及びサーバ状態テーブル１９の各テーブルを用いる。

図３は、対応クライアントテーブル１６の構成例である。対応クライアントテーブル１６は、配信サーバ１６０の欄の配信サーバ２とクライアント１６２の欄のクライアント３との対応関係を示し、配信サーバ２aは、クライアントa1、a2、a3、・・・、aｘ(クライアント数がｘ)のグループへの配信サービスを担当する。配信サーバ２ｂは、クライアント数がｙのグループへの配信サービスを担当する。グループは、コンテンツ配信のネットワーク上のトラフィックの増減による遅延や障害の影響を少なくするために、例えば配信サーバからクライアントへのネットワーク経路上の通信機器の数が少なくなるようにグループ化したり、配信サービスの違いや配信サーバが扱うコンテンツの種類などによりグループ化したりする。

クライアント数ｘ、ｙは、予め次のように決める。配信サーバ２aの通信性能も含めた性能の、たとえば60％がコンテンツ配信に割り当て、この50％の性能で、100クライアントに同時にコンテンツ配信が可能とする。この100クライアントの100を上限値と呼ぶ。担当するクライアントの中で、同時にコンテンツ配信を受ける確率を20％とすれば、この配信サーバ２aが担当するクライアント数ｘは、100/0.2＝500となる。数値60％、20％、100クライアントなどは、配信サーバ２の性能や各コンテンツの配信のために必要な帯域、配信要求の多いコンテンツの多少などにより決定される。したがって、決定したクライアント数を超えるクライアントがグループに加わるような場合は、新たな配信サーバ２を設け、グループ内のクライアントの担当を２分する。

なお、コンテンツ配信以外に割り当てておく配信サーバ２の性能は、配信制御サーバ1からの新しいコンテンツの配信登録や配信サーバ２自身の異常処理などの実行に用いられる。したがって、配信サーバ２は定常的には、コンテンツ配信の負荷がかかっている。上記の数値例を用いると、配信サーバ２aが30クライアントに同時にコンテンツ配信しているならば、配信サーバ２の負荷は、60×30/100＝18（％）である。

図４は、サーバ順序テーブル１７の構成例である。サーバ順序テーブル１７は配信サーバ１７０の欄の配信サーバ２が同時に配信可能なコンテンツ数以上の負荷に陥ったときの、新たなリクエストに対応する配信サーバ２の順序１７２を表すテーブルである。図4に示すように、たとえば、サーバ２aに対して、サーバ２ｂ、サーバ２e、、サーバ２cの順序でバックアップする。バックアップする配信サーバ２も過負荷状態にある場合も想定されるので、複数の配信サーバ２がバックアップできるようにしてある。順序１７２は、配信サーバ１７０が担当するグループのクライアントへのネットワーク経路上の通信機器の数が少ない順が望ましい。

図５は、配信スケジュールテーブル１８の構成例である。配信スケジュールテーブル１８は、配信サーバ１８０の欄の配信サーバ２に関して、スケジュール数１８２、コンテンツ１８４、終了時刻１８６、及び配信先１８８の各欄のデータを格納している。スケジュール数１８２は、配信中のスケジュールの数を示すための連続番号である。サーバ２aの同時にコンテンツ配信が可能なクライアントの数である上限値をｍ、サーバ２ｂの上限値をｎとしている。図５は、サーバ２aに関してはｍ＋1、サーバ２ｂに関してはｎ＋２のスケジュール数に関するデータを格納できるように示している。各々の上限値を超える、サーバ２aに関するｍ＋1、サーバ２ｂに関するｎ＋２を許容値と呼ぶ。

コンテンツ１８４の欄は配信中のコンテンツを示し、終了時刻１８６の欄はそのコンテンツの配信終了時刻を示し、配信先１８８の欄はそのコンテンツの配信先クライアントを示している。図５は、現在時刻を10：00として示し、たとえば、サーバ２aはコンテンツ11を、10：02を終了時刻としてクライアントa1に配信している。

コンテンツの配信が終了すると、たとえば図５のコンテンツ11の配信が10：02に終了すると、コンテンツ１８４、終了時刻１８６、及び配信先１８８の各欄のデータを削除し、他のデータを前詰めする。たとえば、スケジュール数1の行には、コンテンツ12、終了時刻10：08、クライアントa2が格納される。

一方、新たなコンテンツの配信を介する場合は、コンテンツ１８４、終了時刻１８６、及び配信先１８８の各欄に、新たなスケジュールに関するデータを格納し、終了時刻１８６のデータでコンテンツ１８４、終了時刻１８６、及び配信先１８８の各欄をソートする。結果として、コンテンツ１８４、終了時刻１８６、及び配信先１８８の各欄のデータは、終了時刻順に並ぶ。

図５において、現在時刻10：00の時点で、サーバ２ｂは上限値ｎを下回るコンテンツ数kのコンテンツを配信中であることを示している。

図６は、サーバ状態テーブル１９の構成例である。サーバ状態テーブル１９は、配信サーバ１９０の配信サーバ２の状態を状態１９２の欄で示す。状態は、ここでは特別処理中と定常とする。定常とは、図３の説明中の例示で説明したように、配信サーバ２がコンテンツ配信に係る処理以外の処理を実行していない状態である。図３の例示で言えば、配信サーバ２aの負荷が高々60％の状態である。一方、特別処理中とは、配信サーバ２がコンテンツ配信に係る処理以外の処理を実行している状態である。コンテンツ配信に係る処理以外の処理の典型的な例は、前述した配信制御サーバ1からの新しいコンテンツの配信登録や配信サーバ２自身の異常処理などである。新しいコンテンツの配信登録に関しては、配信制御サーバ1が処理の一端を担っているので、配信制御サーバ1は配信サーバ２の状態を認識できるので、状態１９２の欄に特別処理中を格納することができる。配信サーバ２の異常処理の実行に関しては、異常の検知及び異常処理の終了を通信ネットワーク４を介して配信サーバ２から通知されることで、配信制御サーバ1は認識でき、認識結果に応じて状態１９２の欄を書き換える。図６は、配信サーバ２ｂが特別処理中であることを示し、配信サーバ２a及び配信サーバ２ｃは定常状態であることを示している。

図７は、クライアント３から新たなリクエストを受けた配信制御サーバ１の配信スケジュール管理部１０の処理フローチャートである。受信したリクエストから特定したリクエストを送信したクライアント３を担当する配信サーバ２を仮決定する(ステップ１００)。この仮決定の処理は、特定したクライアント３が対応クライアントテーブル１６のクライアント１６２の欄にあるかを調べ、あるならば対応する配信サーバ１６０の欄の配信サーバを仮決定するサーバとする。仮決定するサーバがなければ、配信不可を応答として、リクエストを送信してきたクライアント３に送信し（ステップ１０５）、処理を終了する。なお、ステップ１００における最初の判定で、仮決定するサーバがない場合は、たとえば会員登録されていないクライアントからのリクエストであったことになる。図７に示すように処理がループするので、ステップ１００における２回目以降の判定があり得る。２回目以降の判定に関しては後述する。

例示として、配信サーバ２aがリクエストを送信してきたクライアント３へのコンテンツ配信を担当するものとし、仮決定した配信サーバが配信サーバ２aであるとする。仮決定した配信サーバ２の現在の配信スケジュール(コンテンツ)数は上限以上であるかを判定する（ステップ１１０）。上限未満であるならば、仮決定した配信サーバ２を決定した配信サーバ２として、ステップ１３０へ移る。図５の配信スケジュールテーブル１８を参照すると、配信サーバ２aの現在の配信スケジュール数は上限のｍである。

上限以上ならば、配信サーバ２の現在の配信スケジュール(コンテンツ)数は許容値以上であるかを判定する（ステップ１１５）。許容値以上ならば、ステップ１００に戻る。配信サーバ２aの現在の配信スケジュール数はｍであり、許容値ｍ＋1未満である。

許容値未満ならば、仮決定の配信サーバ２は特別処理中かを判定する(ステップ１２０)。特別処理中ならば、ステップ１００に戻る。配信サーバ２aの状態は、サーバ状態テーブル１９を参照すると、定常である。

特別処理中でなければ、許容時間内に配信を終了するスケジュールがあるかを判定する(ステップ１２５)。許容時間内に配信を終了するスケジュールがなければ、ステップ１００に戻る。許容時間は、コンテンツ配信システム１として予め決定しておいても良いが、配信サーバ２によって扱うコンテンツに要する配信時間やハードウェアの性能などが異なるので、配信サーバ２毎に許容時間を定めておくことが望ましい。許容時間を大きく設定すると、配信サーバ２の負荷が上限値近くになった場合でもクライアントからのリクエストを取り逃しにくく、配信サーバ２の利用効率が高くなる。しかしその半面、配信サーバ２の負荷が上限値を超えてしまうリスクが高くなる。逆に、許容時間を小さく設定すると配信サーバ２の負荷が上限値を超える危険性は低くなるが、配信サーバ２の上限値近くになるとクライアントからのリクエストを拒否してしまう可能性が高く、サーバの利用効率が低くなる。配信サーバ２aの許容時間を５分とすると、許容時間の５分以内の10：02に、コンテンツ11のクライアントa1への配信が終了する。許容時間内に配信を終了するスケジュールがあれば、仮決定した配信サーバ２を決定した配信サーバ２とする。

決定した配信サーバ２に対応させて配信スケジュールテーブル１８にリクエストされたコンテンツ、その終了時刻、配信先のクライアントを格納する(ステップ１３０)。終了時刻は、配信制御サーバが保持しているコンテンツに関するデータベース(図示略)のコンテンツ配信時間を現在時刻に加えた時刻とする。配信スケジュールテーブル１８の内容を終了時刻でソートし(ステップ１３５)、リクエストを決定した配信サーバ２にリダイレクト(転送)し(ステップ１４０)、処理を終了する。リクエストがリダイレクトされた配信サーバ２からクライアント３にリクエストしたコンテンツが配信される。

ステップ１１５、ステップ１２０、及びステップ１２５のいずれかからステップ１００に戻った場合のステップ１００の処理の説明を補足する。いずれの場合も、仮決定した配信サーバ２が要求に応えられない場合である。このとき、サーバ順序テーブル１７を参照する。最初に仮決定した配信サーバ２の行の順序１７２に従って、新たな配信サーバ２を仮決定する。たとえば、最初に配信サーバ２aを仮決定した場合、図７の処理のループに応じて配信サーバ２ｂ、配信サーバ２e、配信サーバ２ｃの順に仮決定し、配信サーバ２ｃにおいても、ステップ１１５、ステップ１２０、及びステップ１２５のいずれかからステップ１００に戻った場合、配信不可とする。

なお、コンテンツによって配信に要する伝送帯域幅(伝送速度:bps)が異なることがある。コンテンツが動画像である場合、その解像度（画面当たりのピクセル数）やフレームレートなどによって伝送帯域幅が異なる。同じ解像度であっても、動画像や音声の符号化方式の違いにより、伝送帯域幅が異なる。このような場合、配信スケジュールテーブル１８に伝送帯域幅（bps）の欄を設け、各配信コンテンツの使用伝送帯域幅の値を格納しておき、配信サーバ２の能力としての伝送帯域幅を負荷配分した伝送帯域幅を上限値とし、さらに伝送帯域幅の許容値を設け、使用伝送帯域幅の合計を同時配信コンテンツ数の代わりに判定する。

配信スケジュール管理部１０の処理は、配信サーバ２の負荷配分設計に基づく上限値を超えても、同時に配信する負荷（配信コンテンツ数または使用伝送帯域幅）が許容値以内であれば、新たなコンテンツの配信を許容するものである。ただし、上限値を超えるというリスクを考慮して許容する。さらに、リスクを厳しく見る場合は、許容時間を設け、リスクのあるコンテンツ配信時間を制限するものである。許容時間内の負荷の上限値を超えるリスクを許容することで、負荷の上限値に近い状態であっても、クライアントからのリクエストの拒否の発生を極力抑え、配信サーバの性能を上限値まで最大限に有効利用することが可能になる。異常処理のような特別処理を実行すると、その処理内容により配信サーバ２にかかる負荷は大きく変動するので、負荷配分設計が事前になされるのが通常である。たとえば、配信サーバ２の能力のほとんど(たとえば９８％)をコンテンツ配信のために割り当てると、特別処理の実行に伴って、一部またはすべてのコンテンツ配信の中断を招きかねないので、定常状態では余裕のある負荷配分がなされる。この余裕の一部を利用するのは本実施形態である。

以上説明したように、本実施形態によれば、配信サーバのコンテンツ配信に配分された能力を超えた高負荷な状態が発生しても、配信サーバはそのときの負荷状況に応じてコンテンツ配信することができる。

１：配信制御サーバ、２：配信サーバ、３：クライアント、４：通信ネットワーク、５：コンテンツ配信システム、１０：配信スケジュール管理部、１６：対応クライアントテーブル、１７：サーバ順序テーブル、１８：配信スケジュールテーブル、１９：サーバ状態テーブル。

Claims (6)

1. クライアントを特定する情報及びコンテンツを特定する情報を含むリクエストを送信し、前記コンテンツが配信される前記クライアント、
   前記リクエストを受信し、配信サーバが配信中のコンテンツ配信処理に係る負荷が、負荷配分により予め決定された負荷の上限値以上であり、前記上限値を超えるリスクを考慮して設定された許容値未満であり、かつ前記コンテンツ配信処理以外の特別処理を実行中でないとの条件の下で、前記配信サーバに前記リクエストを転送する配信制御サーバ、および、
   前記転送されたリクエストの受信に応答して、前記クライアントに前記コンテンツを配信する前記配信サーバとを設けることを特徴とするコンテンツ配信システム。
2. 前記負荷の前記上限値及び前記許容値の各々は、前記配信サーバが同時に配信するコンテンツの数及び前記同時に配信するコンテンツの使用伝送帯域幅の合計であることを特徴とする請求項１記載のコンテンツ配信システム。
3. 前記配信制御サーバは、前記配信サーバによる前記コンテンツの配信を含めた前記配信サーバ負荷状態が予め定めた許容時間内に解消することを、前記条件に加えることを特徴とする請求項２記載のコンテンツ配信システム。
4. クライアントから、前記クライアントを特定する情報及びコンテンツを特定する情報を含むリクエストを受け付けるリクエスト受付部、
   配信サーバが配信中のコンテンツ配信処理に係る負荷が、負荷配分により予め決定された負荷の上限値以上であり、前記上限値を超えるリスクを考慮して設定された許容値未満であり、かつ前記コンテンツ配信処理以外の特別処理を実行中でないとの条件を判定する配信スケジュール管理部、および、
   前記配信スケジュール管理部により前記条件が成立すると判定されたとき、前記配信サーバに前記リクエストを転送する配信要求部を設けることを特徴とする配信制御サーバ。
5. 前記負荷の前記上限値及び前記許容値の各々は、前記配信サーバが同時に配信するコンテンツの数及び前記同時に配信するコンテンツの使用伝送帯域幅の合計であることを特徴とする請求項４記載の配信制御サーバ。
6. 前記配信サーバによる前記コンテンツの配信を含めた前記配信サーバ負荷状態が予め定めた許容時間内に解消することを、前記条件に加えることを特徴とする請求項５記載の配信制御サーバ。

Images