説明

通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システム

【課題】 クライアントからの要求を複数のデータ配信サーバのいずれかに振り分ける通信制御装置を備えるデータ配信システムにおいて、データ配信サーバと通信制御装置との間の通信量を低減する。
【解決手段】 本発明は、複数のデータ配信サーバと、1又は複数の通信制御装置とを有するデータ配信システムに関する。データ配信サーバは、現在の負荷状況に係る情報を有するサーバ負荷情報を生成して通信制御装置に送信する。そして、通信制御装置は、データ配信サーバからサーバ負荷情報を取得する手段と、過去に取得したサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、クライアントからの割り当て要求に対して割り当てるデータ配信サーバを選択する手段と、選択したデータ配信サーバからクライアント装置へ配信データを配信するように通信制御する手段とを有する。

【発明の詳細な説明】
【技術分野】
【0001】
この発明は、通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムに関し、例えば、動画像データのストリーム配信を行うデータ配信サーバを複数備えるVOD(Video On Demand)システムに適用することができる。
【背景技術】
【0002】
従来、VODシステム(データ配信システム)において、クライアントに動画像データをストリーム配信するデータ配信サーバ(VODサーバ)が複数存在する場合においては、ディスパッチャという通信制御装置が存在し、配信要求をしてきたクライアントに対し配信要求先のデータ配信サーバを振り分けて指定する事で負荷を分散させていた。
【0003】
従来のディスパッチャを備えるシステムとしては、特許文献1に記載のマルチタスクシステムがある。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2000−284980号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、特許文献1の記載技術では、1つのディスパッチャで集中して通信制御を行っているため、クライアント数が大きくなるとディスパッチャがボトルネックとなる。このため大規模なシステムにおいては複数のディスパッチャを並列的に用いることが必要となるが、複数のディスパッチャが、各サーバの負荷を調べるために密に通信を行うとサーバのみならずネットワークの負荷も増大させる事になる。
【0006】
そのため、ディスパッチャ(通信制御装置)を備えるデータ配信システムにおいて、データ配信サーバとディスパッチャ(通信制御装置)との間の通信量を低減することができる通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムが望まれている。
【課題を解決するための手段】
【0007】
第1の本発明は、クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバとの間の通信を制御する通信制御装置において、(1)データ配信サーバのそれぞれについて、現在の負荷状況に係るサーバ負荷情報を取得するサーバ負荷情報取得手段と、(2)上記クライアント装置から、データ配信サーバを割り当てる割当要求を受付けるサーバ割当要求受付手段と、(3)上記サーバ負荷情報取得手段が過去に取得した、データ配信サーバごとのサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、上記割当要求に対して割当てるデータ配信サーバを選択するサーバ選択手段と、(4)上記サーバ選択手段が選択したデータ配信サーバから、上記クライアント装置に、配信データを配信するように、上記サーバ選択手段が選択したデータ配信サーバ、及び上記クライアント装置を制御する通信制御手段とを有することを特徴とする。
【0008】
第2の本発明は、通信制御装置の制御に応じたクライアント装置に対して、配信データのストリーム配信を行うデータ配信サーバにおいて、(1)当該データ配信サーバの、現在の負荷状況に係る情報を有するサーバ負荷情報を生成するサーバ負荷情報生成手段と、(2)上記サーバ負荷情報生成手段が生成したサーバ負荷情報を、上記通信制御装置に与えるサーバ負荷情報送信手段とを有することを特徴とする。
【0009】
第3の本発明の通信制御プログラムは、(1)クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバとの間の通信を制御する通信制御装置に搭載されたコンピュータを、(2)データ配信サーバのそれぞれについて、現在の負荷状況に係るサーバ負荷情報を取得するサーバ負荷情報取得手段と、(3)上記クライアント装置から、データ配信サーバを割り当てる割当要求を受付けるサーバ割当要求受付手段と、(4)上記サーバ負荷情報取得手段が過去に取得した、データ配信サーバごとのサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、上記割当要求に対して割当てるデータ配信サーバを選択するサーバ選択手段と、(5)上記サーバ選択手段が選択したデータ配信サーバから、上記クライアント装置に、配信データを配信するように、上記サーバ選択手段が選択したデータ配信サーバ、及び上記クライアント装置を制御する通信制御手段として機能させることを特徴とする。
【0010】
第4の本発明のデータ配信プログラムは、(1)通信制御装置の制御に応じたクライアント装置に対して、配信データのストリーム配信を行うデータ配信サーバに搭載されたコンピュータを、(2)当該データ配信サーバの、現在の負荷状況に係る情報を有するサーバ負荷情報を生成するサーバ負荷情報生成手段と、(3)上記サーバ負荷情報生成手段が生成したサーバ負荷情報を、上記通信制御装置に与えるサーバ負荷情報送信手段として機能させることを特徴とする。
【0011】
第5の本発明は、クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバと、上記クライアント装置と上記データ配信サーバとの間の通信を制御する1又は複数の通信制御装置とを有するデータ配信システムにおいて、(1)それぞれの上記データ配信サーバとして第2の本発明のデータ配信サーバを適用し、(2)それぞれの上記通信制御装置として第1の本発明の通信制御装置を適用したことを特徴とする。
【発明の効果】
【0012】
本発明によれば、クライアントからの要求を複数のデータ配信サーバのいずれかに振り分ける通信制御装置を備えるデータ配信システムにおいて、データ配信サーバと通信制御装置との間の通信量を低減することができる。
【図面の簡単な説明】
【0013】
【図1】第1の実施形態に係るデータ配信システムの全体構成について示したブロック図である。
【図2】第1の実施形態に係るデータ配信サーバからディスパッチャに送信されるサーバ負荷情報の内容について示した説明図である。
【図3】第1の実施形態に係るデータ配信システムにおける、各装置間の動作例について示したシーケンス図である。
【図4】第1の実施形態に係るディスパッチャにおけるサーバ選択動作の処理について示したフローチャートである。
【図5】第2の実施形態に係るディスパッチャにおけるサーバ選択動作の処理について示したフローチャートである。
【図6】第3の実施形態に係るストリーム配信終了予定情報の内容例について示した説明図である。
【図7】第3の実施形態に係るディスパッチャの処理において用いられるdeallocated関数の処理内容の例について示した説明図である。
【図8】第3の実施形態に係るストリーム配信終了予定情報の具体例について示した説明図である。
【発明を実施するための形態】
【0014】
(A)第1の実施形態
以下、本発明による通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムの第1の実施形態を、図面を参照しながら詳述する。なお、第1の実施形態においては、本発明の通信制御装置はディスパッチャであるもとして説明している。
【0015】
(A−1)第1の実施形態の構成
図1は、この実施形態のデータ配信システム10の全体構成を示すブロック図である。なお、図1において、括弧内に記載された符号は、後述する第2及び第3の実施形態において用いる符号である。
【0016】
データ配信システム10は、4台のデータ配信サーバ20(20−1〜20−4)、通信制御システム30、N台のクライアント40−1〜40−Nを有している。また、通信制御システム30には、Proxy31、及び、3台のディスパッチャ32(32−1〜32−3)が配置されている。
【0017】
なお、データ配信サーバ20、ディスパッチャ32、クライアント40の台数は限定されないものである。
【0018】
データ配信サーバ20は、いずれかのディスパッチャ32の制御に応じたクライアント40へ、動画像データをストリーム配信する装置である。この実施形態においては、データ配信サーバ20は、動画像データを配信するものとして説明するが、動画像データに音声データを付加して配信するようにしても良いし、音声データだけを配信するようにしても良い。
【0019】
ここで、データ配信サーバ20は、例えば、CPU、ROM、RAM、EEPROM、ハードディスクなどのプログラムの実行構成、及び、他の通信装置と通信をするためのインターフェースを有する装置に、実施形態のデータ配信プログラム等をインストールすることにより構築するようにしても良い。
【0020】
データ配信サーバ20は、所定の間隔ごとに、当該データ配信サーバ20の負荷状況に係る情報(以下、「サーバ負荷情報」という)を、各ディスパッチャ32に与える。サーバ負荷情報の詳細については、後述する動作説明において詳述する。
【0021】
また、データ配信サーバ20において、上述のサーバ負荷情報を生成して、各ディスパッチャ32に与える構成以外は、既存のデータ配信システム(VODシステム)のデータ配信サーバと同様の構成を適用することができる。
【0022】
図1において、データ配信サーバ20−1〜20−4は、それぞれ動画像データを蓄積(同一のデータでも良いし、それぞれ異なるデータであっても良い)するようにしても良いし、データ配信サーバ20−1〜20−4で共通的なストレージ装置(図示せず)を設けて、そのストレージ装置から動画像データを読み込んで保持するようにしても良い。すなわち、データ配信サーバ20−1〜20−4が動画像データを保持する方法は限定されないものである。なお、図1においては、説明を簡易にするため、データ配信サーバ20−1〜20−4は、それぞれ同じ動画像データを保持することが可能であるものとして説明する。
【0023】
Proxy31は、クライアント40とディスパッチャ32との間の通信を中継する機能を担っている。Proxy31は、クライアント40から、いずれかのデータ配信サーバ20をデータ配信に割り当てる要求(以下、「サーバ割当要求」という)を受付けて、そのサーバ割当要求を、いずれかのディスパッチャ32に振り分けて転送し、以後、そのクライアント40とディスパッチャ32との間の通信を中継する。
【0024】
図1では、例として、クライアント40とディスパッチャ32の間にProxy31が存在しているが、Proxy31は必須ではなく省略することができる。例えば、予めディスパッチャ32ごとに特定クライアント40を割り当て(例えば、静的にクライアント40側に設定したり、DNSサーバ(図示せず)により割り振る等)、クライアント40が直接ディスパッチャ32にアクセスするようにしても良い。
【0025】
また、Proxy31がサーバ割当要求を、いずれかのクライアント40に割り当てる方法については限定されないものであり、例えば、ランダムに選択したり、ラウンドロビン方式により選択したり等、既存の負荷分散方式を適用するようにしても良い。
【0026】
クライアント40−1〜40−Nは、既存のデータ配信システム(VODシステム)におけるクライアント装置と同様のものを適用することができる。
【0027】
ディスパッチャ32は、データ配信サーバ20とクライアント40との間の通信に係る制御を行うものである。
【0028】
ディスパッチャ32は、例えば、CPU、ROM、RAM、EEPROM、ハードディスクなどのプログラムの実行構成、及び、他の通信装置と通信をするためのインターフェースを有する装置に、実施形態の通信制御プログラム等をインストールすることにより構築するようにしても良い。
【0029】
ディスパッチャ32は、所定の間隔ごとに、各データ配信サーバ20−1〜20−4のサーバ負荷情報を取得する。
【0030】
そして、ディスパッチャ32は、クライアント40からサーバ割当要求を受取ると、各データ配信サーバ20−1〜20−4から過去に取得したサーバ負荷情報を利用して、そのクライアント40に割り当てるデータ配信サーバ20を選択する。そして、ディスパッチャ32は、少なくとも選択したデータ配信サーバ20の識別情報を有するサーバ割当要求の応答(以下、「サーバ割当応答」という)を、そのクライアント40に、Proxy31を介して送信する。クライアント40は、サーバ割当応答を受取ると、そのサーバ割当応答に含まれるデータ配信サーバ20の識別情報を抽出し、その識別情報のデータ配信サーバ20へアクセスし、実際の配信要求を行う。以降、そのデータ配信サーバ20は、サーバ割当応答に基づきアクセスしてきたクライアント40に、ストリーム配信を行う。
【0031】
それぞれのディスパッチャ32−1〜32−3が、データ配信サーバ20−1〜20−4のサーバ負荷情報を保持する方法としては、例えば、それぞれのディスパッチャ32−1〜32−3が、データ配信サーバ20−1〜20−4へサーバ負荷情報を要求して読込むようにしても良いし、逆に、データ配信サーバ20−1〜20−4からディスパッチャ32−1〜32−3へサーバ負荷情報を配信するようにしても良い。すなわち、ディスパッチャ32−1〜32−3において、定期的にデータ配信サーバ20−1〜20−4からサーバ負荷情報を保持することができれば、その通信手順は限定されないものである。なお、サーバ負荷情報の詳細については、後述する動作説明において詳述する。
【0032】
(A−2)第1の実施形態の動作
次に、以上のような構成を有する第1の実施形態のデータ配信システム10の動作を説明する。
【0033】
(A−2−1)サーバ負荷情報について
まず、ディスパッチャ32における、サーバ負荷情報に係る処理について説明する。
【0034】
図2は、データ配信サーバ20からディスパッチャ32に与えられるサーバ負荷情報に含まれる内容の例について示した説明図である。
【0035】
図2に示すように、ここでは、サーバ負荷情報には、「ServerID」、「Priority」、「stream」、「updatetime」の情報が含まれているものとして説明する。
【0036】
「ServerID」は、当該データ配信サーバ20の識別情報であり、例えば、アドレス情報やドメイン名等が適用される。
【0037】
「Priority」は、当該データ配信サーバ20の優先度の高低を示すパラメータである。Priorityは、データ配信サーバ20ごとに予め異なる値が設定されているものとする。詳細については後述するが、ディスパッチャ32では、この優先度も考慮してデータ配信サーバ20に対するストリーム配信の割当を行う。Priorityとしては、例えば、優先度が高いほど、小さな数値を設定するようにしても良い。
【0038】
「stream」は、当該データ配信サーバ20の、余剰の処理能力を示すパラメータである。第1の実施形態においては、「stream」は、当該データ配信サーバ20において、配信可能な残りのストリーム数を示すものとする。例えば、当該データ配信サーバ20が同時にクライアント40へ配信可能なストリームの本数が10であり、現在5本配信中である場合には、配信可能な残りのストリーム数を示すstreamは、「5」となる。
【0039】
「updatetime」は、当該サーバ負荷情報が更新された時間(生成された時間)を示すものとする。
【0040】
(A−2−2)各装置間の処理について
図3は、データ配信システム10構成する各装置間の処理について示したシーケンス図である。
【0041】
図3では、説明を簡易にするため、クライアント40−1、ディスパッチャ32−1、データ配信サーバ20−1の間の処理に係るシーケンス図として示しているが、実際には、データ配信システム10には、図1に示すように、クライアント40、ディスパッチャ32、データ配信サーバ20は、それぞれ複数配置されている。
【0042】
図3では、まず、クライアント40−1からProxy31に、サーバ割当要求が与えられ、Proxy31により、そのサーバ割当要求が、ディスパッチャ32−1に与えられたものとする(S101)。以下では、ディスパッチャ32−1に係る動作について説明するが、その他のディスパッチャ32−2、32−3も、サーバ割当要求が与えられた場合の動作は同様であるので、説明を省略する。
【0043】
次に、ディスパッチャ32−1では、クライアント40−1からのサーバ割当要求が与えられると、クライアント40−1に対して割り当てるデータ配信サーバ20の選択が行われる(S102)。
【0044】
ここでは、ディスパッチャ32−1において、基本的にはデータ配信サーバ20は優先度順(サーバ負荷情報におけるpriorityで表される優先度順)に割り当てるものとするが、配信限界に達して割り当て不可能なデータ配信サーバ20への割当を避けるため、サーバ負荷情報のstreamが所定よりも小さいサーバを割り当てないようにする。サーバ負荷情報は、取得時からの経過時間に従属して信頼度が下がるので、これらの情報を基にどのサーバを割り当てるかを判断する。
【0045】
ここでは、ステップS102の処理において、ディスパッチャ32−1により、データ配信サーバ20−1が選択されたものとするが、ディスパッチャ32−1のデータ配信サーバ20を選択する処理の詳細については後述する。
【0046】
次に、ディスパッチャ32−1により、ステップS102で選択されたデータ配信サーバ20−1に対して、サーバ割当要求が送信される(S103)。
【0047】
次に、データ配信サーバ20−1では、クライアント40−1に対して仮割り当てが行われ、データ配信サーバ20−1へのアクセス情報がディスパッチャ32−1に送信される(S104)。
【0048】
次に、ディスパッチャ32−1により、アクセス情報が、サーバ割当要求の送信元であるクライアント40−1に送信される(S105)。
【0049】
次に、クライアント40−1により、アクセス情報に基づいたデータ配信サーバ20−1に配信要求が送信される(S106)。
【0050】
次に、データ配信サーバ20−1からクライアント40−1に配信要求に基づいたデータ配信がおこなわれる(S107)。
【0051】
(A−2−3)データ配信サーバの選択処理について
図4は、上述のステップS102における、ディスパッチャ32−1のデータ配信サーバ20の選択処理について示したフローチャートである。
【0052】
また、図4のフローチャートでは、ループ処理に用いる変数として「I」を用いるものとして説明する。また、図4のフローチャートでは、ループ処理に用いる定数としてM(データ配信サーバ20の台数を表す)を用いるものとする。
【0053】
まず、ディスパッチャ32−1では、経過時間に基づきstreamに対する閾値が、以下の(1)式を用いて求められる(S201)。
【0054】
閾値=α(now−updatetime)+初期値 …(1)
(1)式で、αは予め設定された所定の正の値である。なお、αはディスパッチャ32の総数に比例する値を適用することが望ましい。これはProxy31が各ディスパッチャ32に均等に割り当て要求を分配していると仮定して設定している(もしくは各ディスパッチャ32にクライアント40が均等に割り当てられている)。
【0055】
また、(1)式で、nowは現在の時刻であり、updatetimeは最後に取得したサーバ負荷情報におけるupdatetimeが適用される。すなわち、「now−updatetime」は、データ配信サーバ20について最後に取得したサーバ負荷情報が生成された時刻から現在までの経過時間を示している。
【0056】
なお、ここでは説明を簡易にするため、上述のステップS201において算出される閾値は、データ配信サーバ20−1〜20−4で全て同じ(すなわち、データ配信サーバ20−1〜20−4でサーバ負荷情報が生成されるタイミングが同じ)であるものとして説明するが、適用するupdatetimeがデータ配信サーバ20ごとに異なる場合には、上述のステップS201の処理もデータ配信サーバ20ごとに行う必要がある。
【0057】
また、(1)式において初期値は、限定されないものであり、任意の値が設定されるものとする。
【0058】
次に、後述するループ処理に用いられる変数Iが初期化(I=0)される(S202)。なお、I=0の場合には、後述するステップS203〜S205のループ処理では、優先順位(サーバ負荷情報におけるPriorityにより定まる順位)が最も高いデータ配信サーバ20が処理対象のサーバとして処理が行われ、I=1では2番目に優先順位が高いデータ配信サーバ20の処理が行われるものとして説明する。例えば、データ配信サーバ20−1、20−2、20−3、20−4の順で優先順位が設定されていた場合には、1番目(I=0)はデータ配信サーバ20−1、2番目(I=1)はデータ配信サーバ20−2、3番目(I=2)はデータ配信サーバ20−3、4番目(I=3)はデータ配信サーバ20−4が、それぞれ処理対象のサーバとなる。
【0059】
ディスパッチャ32−1におけるループ処理では、まず、処理対象のサーバのサーバ負荷情報における最新のstreamが、上述のステップS201で算出した閾値よりも大きいか否かが判定される(S203)。
【0060】
ステップS203において、streamが閾値よりも大きい場合には、その処理対象のサーバが、サーバ割当要求に対して割り当てるデータ配信サーバ20として選択され、処理が終了する。
【0061】
一方、ステップS203において、streamが閾値以下の場合には、その処理対象のサーバは、サーバ割当要求に対して割り当てるデータ配信サーバ20からはずされる。そして、変数Iがインクリメント(I=I+1)され(S204)、さらに、変数I=Mであるか否かが判定される(S205)。ステップS205において、変数I=Mでない場合(まだ処理対象のサーバとなっていないデータ配信サーバ20がある場合)には、上述のステップS203の処理から動作し、変数I=Mの場合(全てのデータ配信サーバ20が処理対象のサーバとなった)場合には、サーバ割当要求に対して割り当てるデータ配信サーバ20がないものとして処理が終了する。
【0062】
以上のように、ディスパッチャ32では、各データ配信サーバ20について最後に取得したサーバ負荷情報におけるstreamの値と、最後に取得したサーバ負荷情報が生成された時刻から現在までの経過時間とを利用して、現在の各データ配信サーバ20の負荷状況を推定し、その推定結果を考慮して、サーバ割当要求に対して割り当てるデータ配信サーバ20を選択する。
【0063】
例えば、上記の(1)式においてα=2で初期値=0が適用され、データ配信サーバ20−1のstreamが5、データ配信サーバ20−2のstreamが10であり、データ配信サーバ20−1の優先度が最も高く、その次にデータ配信サーバ20−2が高い場合を想定する。この場合、経過時間(now−updatetime)が2.5秒後に、閾値がデータ配信サーバ20−1のstreamの値(5)に達するので、その時点でデータ配信サーバ20−1は、割り当ての対象から外され、それ以降はデータ配信サーバ20−2が割り当てられることになる。閾値の予測が正しいとすればデータ配信サーバ20−1との無駄な通信を避ける事ができる。
【0064】
(A−3)第1の実施形態の効果
第1の実施形態によれば、以下のような効果を奏することができる。
【0065】
ディスパッチャ32では、サーバ負荷情報の内容と、最後にサーバ負荷情報が生成された時刻からの経過時間(now−updatetime)とを利用して、配信受付可能なデータ配信サーバ20を推定し、配信受付不可能なデータ配信サーバ20との無駄な通信を避ける事ができる。例えば、第1の実施形態において、仮に、配信受付不可能なデータ配信サーバ20の推定を行わなかったとすると、他のディスパッチャ32により割り当てられサーバ情報と実際の情報に開きが生じた場合でもそのまま割り当てを試み続けるという事が起き、通信に失敗してしまうという問題が発生する。
【0066】
また、サーバ負荷情報の内容だけでなく、最後にサーバ負荷情報が生成された時刻からの経過時間(now−updatetime)とを利用して、配信受付可能なデータ配信サーバ20を推定するので、例えば、サーバ負荷情報だけに基づいて推定する場合よりも少ない頻度でサーバ負荷情報を取得しておけば良いため、データ配信サーバ20とディスパッチャ32との間の通信量を低減させることができる。
【0067】
また、データ配信システム10では、ディスパッチャ32−1〜32−3は、それぞれ並列的に単独で動作させているため、通常時におけるディスパッチャ32同士で同期処理や、一部のディスパッチャ32の障害発生時の切替処理を不要としており、構築コストの低減や保守性が向上するといった効果を奏する。
【0068】
(B)第2の実施形態
以下、本発明による通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムの第2の実施形態を、図面を参照しながら詳述する。なお、第2の実施形態においては、本発明の通信制御装置はディスパッチャであるもとして説明している。
【0069】
(B−1)第2の実施形態の構成
第2の実施形態のデータ配信システム10Aも、図1を用いて説明することができる。
【0070】
第2の実施形態のデータ配信システム10Aでは、第1の実施形態のデータ配信システム10がデータ配信システム10Aに置き換わっているが、それ以外の構成については第1の実施形態と同様であるので詳しい説明を省略する。
【0071】
データ配信システム10Aは、ディスパッチャ32(32−1〜32−3)が、ディスパッチャ32A(32A−1〜32A−3)に置き換わっているが、それ以外の構成については第1の実施形態と同様であるので詳しい説明は省略する。
【0072】
ディスパッチャ32Aは、サーバ割当要求に対して割り当てるデータ配信サーバ20を選択する処理(上述の図3のステップS102の処理)が、第1の実施形態のディスパッチャ32と異なるだけである。なお、ディスパッチャ32Aにおける、サーバ割当要求に対して割り当てるデータ配信サーバ20を選択する処理の詳細については、後述する動作説明において詳述する。
【0073】
(B−2)第2の実施形態の動作
次に、以上のような構成を有する第2の実施形態のデータ配信システム10Aの動作を説明する。
【0074】
データ配信システム10Aを構成する各装置間の処理についても上述の図3により示すことができる。ただし、第2の実施形態のデータ配信システム10Aでは、図3におけるステップS102の処理(サーバ割当要求に対して割り当てるデータ配信サーバ20を選択する処理)だけが、第1の実施形態と異なるので、以下ではステップS102に係る処理についてのみ説明する。
【0075】
図5は、ディスパッチャ32A−1で、上述のステップS102に相当する処理(データ配信サーバ20の選択処理)について示したフローチャートである。
【0076】
また、図5のフローチャートでは、第1の実施形態(上述の図4参照)と同様に、ループ処理に用いる変数として「I」、ループ処理に用いる定数としてM(データ配信サーバ20の台数)を用いるものとする。
【0077】
また、各ディスパッチャ32Aでは、各データ配信サーバ20から受信したサーバ負荷情報を蓄積し、図5のフローチャートに係る動作において、その蓄積したサーバ負荷情報の履歴を用いるものとする。
【0078】
まず、ディスパッチャ32Aでは、後述するループ処理に用いられる変数Iが初期化(I=0)される(S301)。なお、I=0の場合には、後述するステップS302〜S305のループ処理では、第1の実施形態と同様に、優先順位(サーバ負荷情報におけるPriorityにより定まる順位)が最も高いデータ配信サーバ20が処理対象のサーバとして処理が行われ、I=1では2番目に優先順位が高いデータ配信サーバ20の処理が行われるものとして説明する。
【0079】
ディスパッチャ32A−1におけるループ処理では、ディスパッチャ32A−1において、各ディスパッチャ32Aでは、蓄積したサーバ負荷情報の履歴にもとづいて、各データ配信サーバ20のサーバ負荷情報におけるstreamの値の変化傾向を分析する。そして、ディスパッチャ32A−1では、その変化傾向に基づいて現在の各データ配信サーバ20における余剰の処理能力を示す値(以下、「new_stream」という)を算出する(S302)。なお、new_streamを算出する具体的な処理については後述する。
【0080】
次に、ディスパッチャ32A−1では、上述のステップS302で算出したnew_streamが、所定の閾値よりも大きいか否かが判定される(S303)。ステップS303において用いられる閾値は、任意の値を設定することができるが、例えば「0」を適用するようにしても良い。
【0081】
ステップS303において、streamが閾値よりも大きい場合には、その処理対象のサーバが、サーバ割当要求に対して割り当てるデータ配信サーバ20として選択され、処理が終了する。
【0082】
一方、ステップS303において、streamが閾値以下の場合には、その処理対象のサーバは、サーバ割当要求に対して割り当てるデータ配信サーバ20からはずされる。そして、変数Iがインクリメント(I=I+1)され(S304)、さらに、変数I=Mであるか否かが判定される(S305)。ステップS305において、変数I=Mでない場合(まだ処理対象のサーバとなっていないデータ配信サーバ20がある場合)には、上述のステップS302の処理から動作し、変数I=Mの場合(全てのデータ配信サーバ20が処理対象のサーバとなった場合)には、サーバ割当要求に対して割り当てるデータ配信サーバ20がないものとして処理が終了する。
【0083】
[new_streamの算出方法について]
次に、上述のステップS302におけるnew_streamの算出方法の詳細について説明する。
【0084】
まず、ディスパッチャ32A−1では、各データ配信サーバ20から受信して蓄積したサーバ負荷情報の履歴にもとづいて、各データ配信サーバ20のサーバ負荷情報におけるstreamの値の変化傾向を分析する。ここでは、例として、各ディスパッチャ32Aでは、各データ配信サーバ20に係るstreamの値が上昇傾向にあるか、下降傾向にあるかを以下の(2)式を用いて判定するものとして説明する。
【0085】
なお、(2)式において、α+α+α+…+α=1、及び、α>α>α>…>αの関係が成り立つ値が予め設定されているものとする。また、(2)式において、stream、stream、stream、stream、…、streamは、変化傾向の判定対象となるデータ配信サーバ20から、ディスパッチャ32Aに与えられたサーバ負荷情報におけるstreamの値の履歴を示している。すなわち、streamが最新の値を示しており、streamが最も古い値を示している。iの値は、任意の値を設定するようにしても良い。
【0086】
δ=α(stream−stream)+α(stream−stream
+ … +α(streami−1−stream) …(2)
そして、ディスパッチャ32Aでは、上記の(2)式により求められたδをさらに、以下の(3)式に適用することにより、当該データ配信サーバ20に、現在割り当て可能なストリームの本数を推定する。
【0087】
なお、(3)式において、MAX(…)は、new_streamの値を算出するための関数である。例えば、MAX(a,b)と表した場合、a≧bならばMAX(a,b)の結果としてaが返され、a<bならばMAX(a,b)の結果としてbが返されるものとする。すなわち、(3)式においては、aがb(0)より以上の値である場合にはnew_stream=aとなり、aが0より小さい値である場合には、new_stream=0となる。
【0088】
また、サーバ情報更新間隔は、データ配信サーバ20において、サーバ負荷情報が生成される間隔を示す。各データ配信サーバ20のサーバ情報更新間隔としては、任意の値を設定することができるが、第2の実施形態においては、各データ配信サーバ20のサーバ情報更新間隔は全て同じ値が設定されており、各ディスパッチャ32にもその値が記憶されているものとして説明する。
【数1】

【0089】
次に、(3)を適用した場合の具体的な計算例について説明する。以下では、例として、α=0.8、α=0.2、サーバ情報更新間隔=10秒であるものとする。また、データ配信サーバ20−1ではstream=5、stream=15、stream=25であるものとする。さらに、データ配信サーバ20−1ではstream=4、stream=5、stream=6であるものとする。
【0090】
そして、以下の(4)式は、上述の条件において、ディスパッチャ32A−1で、データ配信サーバ20−1について、updatetimeから5秒後に算出されるδであり、以下の(5)式は、(4)式で算出されたδを用いて算出されたnew_streamである。
【0091】
また、以下の(6)式は、上述の条件において、ディスパッチャ32A−1で、データ配信サーバ20−2について、updatetimeから5秒後に算出されるδであり、以下の(7)式は、(6)式で算出されたδを用いて算出されたnew_streamである。
【0092】
上述の例の場合、データ配信サーバ20−1は、以下の(4)式、(5)式に示すように、5秒後にはnew_stream=0となり、その時点で、このデータ配信サーバ20−1には、サーバ割当要求に対して割り当てるサーバとして選択されないことになる。
【0093】
一方、データ配信サーバ20−2は、以下の(6)式、(7)式に示すように、5秒後にもnew_stream=3.5なので、優先順位がデータ配信サーバ20−1>データ配信サーバ20−2でもデータ配信サーバ20−2が割り当てられる。
【数2】

【0094】
(B−3)第2の実施形態の効果
第2の実施形態によれば、以下のような効果を奏することができる。
【0095】
ディスパッチャ32Aでは、サーバ負荷情報の履歴にもとづいて、各データ配信サーバ20のサーバ負荷情報におけるstreamの値の変化傾向を分析し、その分析結果に基づいて、各データ配信サーバ20の現在の負荷状況を推定し、データ配信サーバ20の選択に利用している。例えば、第1の実施形態において、第2の実施形態のような推定を行わなかったとすると、あるデータ配信サーバ20のアクセス数が急激に増大していて既に配信限界に達していても、そのデータ配信サーバ20を選択してしまうという問題がある。
【0096】
(C)第3の実施形態
以下、本発明による通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムの第3の実施形態を、図面を参照しながら詳述する。なお、第3の実施形態においては、本発明の通信制御装置はディスパッチャであるもとして説明している。
【0097】
(C−1)第3の実施形態の構成
第3の実施形態のデータ配信システム10Bも、図1を用いて説明することができる。
【0098】
第3の実施形態のデータ配信システム10Bでは、第2の実施形態のデータ配信システム10がデータ配信システム10Bに置き換わっている。また、第2の実施形態のデータ配信サーバ20(20−1〜20−4)が、データ配信サーバ20B(20B−1〜20B−4)に置き換わっているが、それ以外の構成については第2の実施形態と同様であるので詳しい説明を省略する。
【0099】
データ配信システム10Bでは、ディスパッチャ32A(32A−1〜32A−3)が、ディスパッチャ32B(32B−1〜32B−3)に置き換わっているが、それ以外の構成については第2の実施形態と同様であるので詳しい説明は省略する。
【0100】
データ配信サーバ20Bは、ディスパッチャ32Bに与えるサーバ負荷情報の内容が、上述の図2に示す内容に加えて、現在当該データ配信サーバ20Bがデータ配信を行っているストリームについて、ストリーム配信が終了する予定に係る情報(以下、「ストリーム配信終了予定情報」という)が含まれている点で、第2の実施形態のデータ配信サーバ20と異なっている。
【0101】
図6は、データ配信サーバ20Bが送信するサーバ負荷情報に含まれる、ストリーム配信終了予定情報の内容例について示した説明図である。
【0102】
図6に示すように、ストリーム配信終了予定情報には、A〜A、K〜Kの情報が含まれている。A〜Aは、それぞれ、当該サーバ負荷情報が生成された時刻から何秒後であるかを示し、K〜Kは、それぞれA〜Aに係る時刻に、当該データ配信サーバ20Bにおいて、データ配信が終了するストリームの本数を示している。例えば、0秒〜A秒後までにデータ配信が終了するストリームの本数が1であればKには1が設定され、A秒後からA秒後までの間にデータ配信が終了するストリームの本数が2であればKには2が設定されることになる。
【0103】
なお、A〜Aに設定する具体的な時間は限定されないものであるが、この実施形態においては、例えば、A〜Aを全て1秒間隔で設定(1秒、2秒、3秒、…、j秒)するものとして説明する。また、jの値についても限定されないものであるが、この実施形態では、サーバ情報更新間隔と同じ値が設定されるものとして説明する。データ配信サーバ20Bでは、それぞれのストリームについて、動画像データの長さ(再生時間)と、現在の送信位置(再生位置)とが把握されており、それらの情報に基づいて、ストリーム配信終了予定情報は生成される。
【0104】
ディスパッチャ32Bは、サーバ割当要求に対して割り当てるデータ配信サーバ20を選択する処理(上述の図3のステップS102の処理)が、第2の実施形態のディスパッチャ32と異なるだけである。なお、ディスパッチャ32Bにおいて、サーバ割当要求に対して割り当てるデータ配信サーバ20を選択する処理の詳細については、後述する動作説明において詳述する。
【0105】
また、各ディスパッチャ32Bでは、第2の実施形態と同様に、各データ配信サーバ20から受信したサーバ負荷情報を蓄積している。
【0106】
(C−2)第3の実施形態の動作
次に、以上のような構成を有する第3の実施形態のデータ配信システム10Bの動作を説明する。
【0107】
データ配信システム10Bを構成する各装置間の処理についても上述の図3により示すことができる。ただし、第3の実施形態のデータ配信システム10Bでは、図3におけるステップS102の処理だけが、第2の実施形態と異なるので、以下ではステップS102に係る処理についてのみ説明する。
【0108】
第3の実施形態において上述のステップS102に相当する処理(データ配信サーバ20Bの選択処理)についても、上述の図5を用いて示すことができる。ただし、第3の実施形態のディスパッチャ32Bでは、図5におけるステップS302の処理(new_streamの算出処理)だけが、第2の実施形態と異なるので、以下ではステップS302に係る処理についてのみ説明する。
【0109】
まず、ディスパッチャ32B−1では、各データ配信サーバ20Bから受信して蓄積したサーバ負荷情報(ストリーム配信終了予定情報を含む)の履歴にもとづいて、各データ配信サーバ20のサーバ負荷情報におけるstreamの値の過去の変化傾向を、第2の実施形態と同様に上記の(2)式によりδを求めることにより分析する。
【0110】
そして、ディスパッチャ32Bでは、上記の(2)式により求められたδをさらに、以下の(8)式に適用することにより、当該データ配信サーバ20Bに、現在割り当て可能なストリームの本数を推定する。
【0111】
なお、(8)式において、MAXは、上記の(3)式と同様に、new_streamの値を算出するための関数である。例えば、MAX(a,b)と表した場合、a≧bならばMAX(a,b)の結果としてaが返され、a<bならばMAX(a,b)の結果としてbが返されるものとする。
【数3】

【0112】
また、(8)式において、deallocatedもnew_streamの値を算出するための関数である。
【0113】
図7は、deallocated関数の処理についてプログラム言語(例えば、C言語)で表記した場合の内容について示した説明図である。
【0114】
図7に示すように、deallocated関数は、時間を示すtime変数を入力すると、if文により、timeがストリーム配信終了予定情報におけるAよりも大きい場合には、Kを戻り値として返し、timeがAよりも大きい場合はK+Kを返し、…、timeがAよりも大きい場合にはK+K+…+Kを返す処理を行う。
【0115】
すなわち、deallocated関数は、now−updatetimeを入力すると、最後に当該データ配信サーバ20Bにおいてサーバ負荷情報が生成された時刻から現在時刻までの間(updatetime−now)に、当該データ配信サーバ20においてストリーム配信が終了するストリームの本数を把握することができる。この実施形態においては、deallocated関数の処理は、図7のプログラム処理により示したが、同様の処理が可能であれば、その処理手順は限定されないものである。
【0116】
このように、ディスパッチャ32Bでは、上記の(8)式のように、当該データ配信サーバ20のサーバ負荷情報におけるstreamの値の過去の変化傾向を示すδと、当該データ配信サーバ20においてストリーム配信が終了するストリームの本数(deallocated(now−updatetime))とを利用してnew_streamを算出している。
【0117】
次に、上記の(8)式を適用した場合の具体的な計算例について説明する。以下では、例として、α=0.8、α=0.2、サーバ情報更新間隔=10秒であるものとする。また、データ配信サーバ20−1ではstream=5、stream=15、stream=25であるものとする。さらに、データ配信サーバ20−1ではstream=4、stream=5、stream=6であるものとする。
【0118】
図8は、ストリーム配信終了予定情報の具体例について示した説明図である。
【0119】
データ配信サーバ20B−1のサーバ負荷情報におけるストリーム配信終了予定情報は図8(a)のような内容であったものとし、データ配信サーバ20B−1のサーバ負荷情報におけるストリーム配信終了予定情報は図8(b)のような内容であったものとする。
【0120】
この場合、updatetimeから5秒後にはデータ配信サーバ20B−1のnew_stream=0となり、割り当て出来なくなるが、データ配信サーバ20B−2は終了するストリームが幾つかあるのでnew_stream=0とはならず割り当てが可能である。
【0121】
(C−3)第3の実施形態の効果
第3実施形態によれば、以下のような効果を奏することができる。
【0122】
ディスパッチャ32Bでは、ストリーム配信終了予定情報を利用して、各データ配信サーバ20Bの現在の負荷状況を推定している。これにより、第2の実施形態と比較して、より精度の高い負荷状況の推定を行うことができる。例えば、第2の実施形態においては、あるデータ配信サーバ20の負荷の変化傾向が過去において上昇傾向であっても、ストリーム配信終了予定情報において、配信終了予定のストリームが多い場合には、実際割り当て可能なのにも関わらず割り当て不可と判断される可能性がある。
【0123】
(D)他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【0124】
(D−1) 上記の各実施形態において、データ配信サーバからクライアントへのストリーム配信において、各ストリームのビットレートは異なるビットレートとしても良い。この場合、サーバ割当要求等の制御信号に、各クライアントが配信要求するデータのビットレートの情報が含まれるようにしても良いし、データ配信サーバ側で、予めクライアントごとのビットレートを登録しておくようにしても良い。
【0125】
そして、各ストリームのビットレートが可変である場合には、サーバ負荷情報のstreamのパラメータの単位は図2に示すようなストリームの本数ではなく、その他の余剰の処理能力を示す単位を適用するようにしても良い。
【0126】
例えば、1000kbpsのストリーム1本で処理能力を10単位必要とし、500kbpsのストリーム1本で処理能力5単位を必要とする単位等を適用するようにしても良い。この場合、例えば、任意のデータ配信サーバ20が全体で50単位の処理能力を有していると想定すると、このデータ配信サーバ20は、500kbpsのストリームなら10本、1000kbpsのストリームなら5本同時に配信できることになる。そして、このデータ配信サーバ20が、1000kbpsのストリームを3本配信中には、サーバ負荷情報におけるstreamのパラメータは、50−(10×3)=20単位となる。
【0127】
(D−2)上記の各実施形態において、ディスパッチャは、優先度を考慮して、サーバ割当要求に対して割り当てるデータ配信サーバを選択する処理を行っているが、優先度を考慮しないようにしても良い。例えば、第1の実施形態において、ステップS203〜ステップS205の処理は、データ配信サーバに付与された優先度順に行っているが、ランダムな順番や、優先度を考慮しない固定の順番や、識別情報をキーに昇順で並べた順番等、その他の基準により定められる順番で実施するようにしても良い。
【0128】
(D−3)上記の各実施形態において、データ配信システムには、複数のディスパッチャが配置されているが、ディスパッチャは1つとしても良い。
【0129】
(D−4)上記の各実施形態においては、サーバ負荷情報には、updatetime(当該サーバ負荷情報が生成された時刻)の情報が含まれているが、これを省略して、ディスパッチャ側で、サーバ負荷情報を受信した時刻をupdatetimeに置き換えて適用するようにしても良い。
【符号の説明】
【0130】
10…データ配信システム、20、20−1〜20−4…データ配信サーバ、30…通信制御システム、31…Proxy、32、32−1〜32−3…ディスパッチャ、40、30−1〜30−N…クライアント。

【特許請求の範囲】
【請求項1】
クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバとの間の通信を制御する通信制御装置において、
データ配信サーバのそれぞれについて、現在の負荷状況に係るサーバ負荷情報を取得するサーバ負荷情報取得手段と、
上記クライアント装置から、データ配信サーバを割り当てる割当要求を受付けるサーバ割当要求受付手段と、
上記サーバ負荷情報取得手段が過去に取得した、データ配信サーバごとのサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、上記割当要求に対して割当てるデータ配信サーバを選択するサーバ選択手段と、
上記サーバ選択手段が選択したデータ配信サーバから、上記クライアント装置に、配信データを配信するように、上記サーバ選択手段が選択したデータ配信サーバ、及び上記クライアント装置を制御する通信制御手段と
を有することを特徴とする通信制御装置。
【請求項2】
サーバ負荷情報には、そのサーバ負荷情報が生成された時刻に係る情報が含まれていることを特徴とする請求項1に記載の通信制御装置。
【請求項3】
上記サーバ選択手段は、過去にデータ配信サーバから取得したサーバ負荷情報の履歴に基づいて、そのデータ配信サーバの負荷に係る変動傾向を分析し、その分析結果を利用して、そのデータ配信サーバの現在の負荷状況を推定することを特徴とする請求項1又は2に記載の通信制御装置。
【請求項4】
サーバ負荷情報には、そのサーバ負荷情報がデータ配信サーバにおいて生成された時点で、そのデータ配信サーバで現在配信中のストリームの終了予定時刻に係るストリーム配信終了予定情報が含まれており、
上記サーバ選択手段は、上記サーバ負荷情報取得手段が過去にデータ配信サーバから取得したサーバ負荷情報に含まれるストリーム配信終了予定情報も利用して、そのデータ配信サーバの現在の負荷状況を推定することを特徴とする請求項1又は2に記載の通信制御装置。
【請求項5】
通信制御装置の制御に応じたクライアント装置に対して、配信データのストリーム配信を行うデータ配信サーバにおいて、
当該データ配信サーバの、現在の負荷状況に係る情報を有するサーバ負荷情報を生成するサーバ負荷情報生成手段と、
上記サーバ負荷情報生成手段が生成したサーバ負荷情報を、上記通信制御装置に与えるサーバ負荷情報送信手段と
を有することを特徴とするデータ配信サーバ。
【請求項6】
クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバとの間の通信を制御する通信制御装置に搭載されたコンピュータを、
データ配信サーバのそれぞれについて、現在の負荷状況に係るサーバ負荷情報を取得するサーバ負荷情報取得手段と、
上記クライアント装置から、データ配信サーバを割り当てる割当要求を受付けるサーバ割当要求受付手段と、
上記サーバ負荷情報取得手段が過去に取得した、データ配信サーバごとのサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、上記割当要求に対して割当てるデータ配信サーバを選択するサーバ選択手段と、
上記サーバ選択手段が選択したデータ配信サーバから、上記クライアント装置に、配信データを配信するように、上記サーバ選択手段が選択したデータ配信サーバ、及び上記クライアント装置を制御する通信制御手段と
して機能させることを特徴とする通信制御プログラム。
【請求項7】
通信制御装置の制御に応じたクライアント装置に対して、配信データのストリーム配信を行うデータ配信サーバに搭載されたコンピュータを、
当該データ配信サーバの、現在の負荷状況に係る情報を有するサーバ負荷情報を生成するサーバ負荷情報生成手段と、
上記サーバ負荷情報生成手段が生成したサーバ負荷情報を、上記通信制御装置に与えるサーバ負荷情報送信手段と
して機能させることを特徴とするデータ配信プログラム。
【請求項8】
クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバと、上記クライアント装置と上記データ配信サーバとの間の通信を制御する1又は複数の通信制御装置とを有するデータ配信システムにおいて、
それぞれの上記データ配信サーバとして請求項5に記載のデータ配信サーバを適用し、
それぞれの上記通信制御装置として請求項1に記載の通信制御装置を適用したこと
を特徴とするデータ配信システム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate


【公開番号】特開2011−109180(P2011−109180A)
【公開日】平成23年6月2日(2011.6.2)
【国際特許分類】
【出願番号】特願2009−259047(P2009−259047)
【出願日】平成21年11月12日(2009.11.12)
【出願人】(308033722)株式会社OKIネットワークス (165)
【Fターム(参考)】