(57)【要約】【課題】配信効率の低下を抑えつつサーバの負荷を制御することができる。【解決手段】処理装置としてのサーバ３であって、複数のセグメントから構成されるコンテンツを第１装置に送信するため、当該コンテンツの処理を実行する第１処理部（通信部１１、セグメント記憶部１６、応答処理部１５も含む）と、前記第１処理部の処理量の測定を実行する、第２処理部（負荷測定部１８も含む）と、前記第２処理部にて測定された処理量が、所定量を超過する第１処理量から、所定量未満である第２処理量になると、前記第１処理部において、前記コンテンツを前記第１装置に送信することが可能であることを示す第１情報を、他の処理装置を介して、前記第１装置に送信するための処理を実行する、第３処理部（状態監視部２０も含む）と、を有する。【選択図】図２
2020136933.tif 000002
【特許請求の範囲】
【請求項１】
処理装置であって、
複数のセグメントから構成されるコンテンツを第１装置に送信するため、当該コンテンツの処理を実行する、第１処理部と、
前記第１処理部の処理量の測定を実行する、第２処理部と、
前記第２処理部にて測定された処理量が、所定量を超過する第１処理量から、所定量未満である第２処理量になると、
前記第１処理部において、前記コンテンツを前記第１装置に送信することが可能であることを示す第１情報を、他の処理装置を介して、前記第１装置に送信するための処理を実行する、第３処理部と、
を有することを特徴とする、処理装置。
【請求項２】
前記第１情報を受信した場合、前記第１装置からのセグメント要求に対する応答メッセージに、当該第１情報の送信元が前記コンテンツの送信を可能であることを示す第２情報を含める処理を実行する、第４処理部、
を有することを特徴とする、請求項１に記載の処理装置。
【請求項３】
前記第４処理部は、
前記第１情報の送信元が前記コンテンツの送信を不可能であることを示す第３情報を含めた前記セグメント要求を送信した前記第１装置に対してのみ、前記応答メッセージに前記第２情報を含める、
ことを特徴とする、請求項２に記載の処理装置。
【請求項４】
前記第２処理部にて測定された処理量が、所定量未満である前記第２処理量から、所定量を超過する前記第１処理量になると、
前記第１処理部において、前記コンテンツを前記第１装置に送信することが不可能であることを示す第４情報を、前記第１装置からのセグメント要求に対する応答メッセージに含める処理を実行する、第５処理部、
を有することを特徴とする、請求項２または請求項３に記載の処理装置。
【請求項５】
請求項４に記載の処理装置と、
前記コンテンツを再生する前記第１装置と、を備える処理システムであって、
前記第１装置は、
前記第４情報を含む前記応答メッセージを受信した場合、当該応答メッセージの送信元が前記コンテンツの送信を不可能であることを示す第５情報を含めた前記セグメント要求を、当該応答メッセージの送信元以外の処理装置に送信する処理を実行する、第６処理部、
を有することを特徴とする、処理システム。
【請求項６】
前記第６処理部は、
前記第４情報を含む応答メッセージを送信した送信元に関する前記第２情報を含んだ応答メッセージを受信した場合、前記第５情報を含まない前記セグメント要求を当該第４情報を含む応答メッセージの送信元の処理装置に送信する、
ことを特徴とする、請求項５に記載の処理システム。
【請求項７】
処理装置のコンピュータを、
複数のセグメントから構成されるコンテンツを第１装置に送信するため、当該コンテンツの処理を実行する第１処理部、
前記第１処理部の処理量の測定を実行する、第２処理部、
前記第２処理部にて測定された処理量が、所定量を超過する第１処理量から、所定量未満である第２処理量になると、
前記第１処理部において、前記コンテンツを前記第１装置に送信することが可能であることを示す第１情報を、他の処理装置を介して、前記第１装置に送信するための処理を実行する、第３処理部、
として機能させるための、処理プログラム。
【請求項８】
処理装置の処理方法であって、
複数のセグメントから構成されるコンテンツを第１装置に送信するため、当該コンテンツの処理を実行する第１処理ステップと、
前記第１処理ステップの処理量の測定を実行する、第２処理ステップと、
前記第２処理ステップにて測定された処理量が、所定量を超過する第１処理量から、所定量未満である第２処理量になると、
前記第１処理ステップにおいて、前記コンテンツを前記第１装置に送信することが可能であることを示す第１情報を、他の処理装置を介して、前記第１装置に送信するための処理を実行する、第３処理ステップと、
を有することを特徴とする、処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処理装置、処理システム、処理プログラムおよび処理方法に関し、例えば、複数の配信サーバで構成される分散配信システムにおける負荷分散に関するものである。
【背景技術】
【０００２】
分散ＤＡＳＨ映像配信の場合、視聴端末は、最初にＭＰＤ（Media Presentation Description）を取得する。ＭＰＤは、コンテンツのセグメントのＵＲＬ（Uniform Resource Locator）を複数記載したファイルである。そして、ＭＰＤに記載されたコンテンツのセグメントのＵＲＬの中から一つを選択し、そのＵＲＬにセグメントファイルを要求することで映像を再生する（非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】“ハイブリッドキャスト関連技術  MPEG-DASHの応用技術”、ＮＨＫ技術カタログ一覧「2018年1月」、[online]、一般財団法人 ＮＨＫエンジニアリングシステム、[平成３１年２月７日検索]、インターネット＜http://www.nes.or.jp/transfer/catalog/NHK-tech_catalog2018.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００４】
サーバに負荷が生じた場合、ＭＰＤの記載を修正して負荷の生じたサーバにセグメントを要求させないという方法がある。分散配信では各サーバの負荷を定期的に収集し、それに基づき割り当て可能なサーバのＵＲＬをＭＰＤファイルに記載する事になるが、情報収集によるハードウェアやネットワークの負荷を下げるためには取得間隔を大きくする必要がある。このため、負荷情報にタイムラグが生じ、そのタイムラグ分だけ上限の設定を低くする必要があるので、サーバの負荷制御が配信効率を下げる事につながるという問題があった。
【０００５】
本発明は、前記課題に鑑みてなされたものであり、配信効率の低下を抑えつつサーバの負荷を制御することができる、処理装置、処理システム、処理プログラムおよび処理方法を提供するものである。
【課題を解決するための手段】
【０００６】
前記課題を解決するため、本発明に係る処理装置は、複数のセグメントから構成されるコンテンツを第１装置に送信するため、当該コンテンツの処理を実行する、第１処理部と、前記第１処理部の処理量の測定を実行する、第２処理部と、前記第２処理部にて測定された処理量が、所定量を超過する第１処理量から、所定量未満である第２処理量になると、前記第１処理部において、前記コンテンツを前記第１装置に送信することが可能であることを示す第１情報を、他の処理装置を介して、前記第１装置に送信するための処理を実行する、第３処理部と、を有することを特徴とする。
【０００７】
また、本発明に係る処理システムは、上記した処理装置と、前記コンテンツを再生する前記第１装置と、を備える処理システムであって、前記第１装置は、コンテンツを第１装置に送信することが不可能であることを示す第４情報を含む応答メッセージを受信した場合、当該応答メッセージの送信元が前記コンテンツの送信を不可能であることを示す第５情報を含めた前記セグメント要求を、当該応答メッセージの送信元以外の処理装置に送信する処理を実行する、第６処理部、を有することを特徴とする。
【０００８】
また、本発明に係る処理プログラムは、処理装置のコンピュータを、複数のセグメントから構成されるコンテンツを第１装置に送信するため、当該コンテンツの処理を実行する第１処理部、前記第１処理部の処理量の測定を実行する、第２処理部、前記第２処理部にて測定された処理量が、所定量を超過する第１処理量から、所定量未満である第２処理量になると、前記第１処理部において、前記コンテンツを前記第１装置に送信することが可能であることを示す第１情報を、他の処理装置を介して、前記第１装置に送信するための処理を実行する、第３処理部、として機能させる。
【０００９】
また、本発明に係る処理方法は、処理装置の処理方法であって、複数のセグメントから構成されるコンテンツを第１装置に送信するため、当該コンテンツの処理を実行する第１処理ステップと、前記第１処理ステップの処理量の測定を実行する、第２処理ステップと、前記第２処理ステップにて測定された処理量が、所定量を超過する第１処理量から、所定量未満である第２処理量になると、前記第１処理ステップにおいて、前記コンテンツを前記第１装置に送信することが可能であることを示す第１情報を、他の処理装置を介して、前記第１装置に送信するための処理を実行する、第３処理ステップと、を有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、配信効率の低下を抑えつつサーバの負荷を制御することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１実施形態に係るコンテンツ配信システムの全体構成図である。
【図２】ＭＦファイルのイメージ図である。
【図３】本発明の第１実施形態に係るクライアントのブロック図である。
【図４】本発明の第１実施形態に係るクライアントでの要求禁止フラグの処理を示すフローチャートの例示である。
【図５】本発明の第１実施形態に係るサーバのブロック図である。
【図６】本発明の第１実施形態に係るサーバがセグメント要求を受け取った場合の処理を示すフローチャートである。
【図７】本発明の第１実施形態に係るサーバの負荷が上限を下回った場合の処理を示すフローチャートである。
【図８】本発明の第１実施形態に係るコンテンツ配信システムにおけるコンテンツの配信制限動作を示すシーケンス図である。
【図９】本発明の第１実施形態に係るコンテンツ配信システムにおけるコンテンツの配信制限解除動作を示すシーケンス図である。
【図１０】本発明の第２実施形態に係るサーバのブロック図である。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための形態を、適宜図面を参照しながら詳細に説明する。
各図は、本発明を十分に理解できる程度に、概略的に示してあるに過ぎない。よって、本発明は、図示例のみに限定されるものではない。また、本実施形態では、本発明と直接的に関連しない構成や周知な構成については、説明を省略する場合がある。なお、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。
【００１３】
［第１実施形態］
≪第１実施形態に係るコンテンツ配信システムの構成≫
図１は、第１実施形態に係るコンテンツ配信システム１について説明する。図１は、第１実施形態に係るコンテンツ配信システム１の全体構成図である。コンテンツ配信システム１は、特定の時間間隔で区切ったセグメント単位でコンテンツ（例えば、映像や音声）を配信する。コンテンツ配信システム１におけるコンテンツの配信方式は特に限定されず、例えば、「HTTP Live Streaming(HLS)」や「Moving Picture Experts Group- Dynamic Adaptive Streaming over HTTP(MPEG-DASH)」である。
【００１４】
コンテンツ配信システム１は、クライアント２と、三台のサーバ３Ａ，３Ｂ，３Ｃ（以下、区別しない場合には「サーバ３」と表記する）とを備える。ここで、図１に示すクライアント２の数は一台であるが、複数台でもよい。また、図１に示すサーバ３の数は三台であるが、複数台（二台以上）であればよい。
【００１５】
なお、コンテンツ配信システム１は、「処理システム」の一例であり、「処理システム」の一例は、コンテンツ配信システム１に限るものではない。
また、クライアント２は、「第１装置」の一例であり、「第１装置」の一例は、クライアント２に限るものではない。
また、サーバ３は、「処理装置」の一例であり、「処理装置」の一例は、サーバ３に限るものではない。
【００１６】
サーバ３Ａ，３Ｂ，３Ｃは、バックヤードのネットワーク４を介して通信可能に繋がっている。また、サーバ３Ａ，３Ｂ，３Ｃとクライアント２とは、公衆のネットワーク５を介して通信可能に繋がっている。ネットワーク４，５の種類は特に限定されず、有線／無線のいずれであってもよい。なお、サーバ３Ａ，３Ｂ，３Ｃは、公衆のネットワーク５を介して通信可能に繋がっていてもよい。つまり、コンテンツ配信システム１は、バックヤードのネットワーク４を備えない構成であってもよい。
【００１７】
クライアント２は、セグメントの取得先が記載されたセグメントリストを取得し、セグメントリストに従ってセグメントを要求する。セグメントリストは、例えば、セグメントのメタデータであるマニフェストファイル（ＭＦファイル）に記載される。マニフェストファイルは、ＨＬＳにおけるプレイリストであり、ＭＰＥＧ−ＤＡＳＨにおけるＭＰＤ（Media Presentation Description）である。ＭＦファイルのイメージを図２に示す。
【００１８】
図３を参照して（適宜、図１参照）、クライアント２の構成を説明する。図３は、クライアント２のブロック図である。クライアント２は、サーバ３（図１参照）から配信されるコンテンツを再生する装置である。クライアント２は、例えば、テレビ受像機、パーソナルコンピュータ（ＰＣ：Personal Computer）、携帯電話端末、タブレット端末、スマートフォンなどである。クライアント２は、例えば、ディスプレイに映像を表示するとともに、スピーカを通じて音声を出力する。
【００１９】
クライアント２は、通信部２１と、要求処理部２２と、要求ヘッダ処理部２３と、記憶部２４と、応答処理部２５と、応答ヘッダ処理部２６と、再生処理部２７と、ディスプレイ２ａとを備える。
なお、要求処理部２２は、「第６処理部」の一例であり、「第６処理部」の一例は、要求処理部２２に限るものではない。
【００２０】
通信部２１、要求処理部２２、要求ヘッダ処理部２３、記憶部２４、応答処理部２５、応答ヘッダ処理部２６および再生処理部２７は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や専用回路等により実現される。実行処理用のプログラムは、コンピュータによる読み取り可能な記録媒体（例：ＣＤ−ＲＯＭ）に記憶して提供することができる。また、そのプログラムを、インターネットなどのネットワークを通して提供することもできる。
【００２１】
通信部２１は、例えばＮＩＣ（Network Interface Card）やそれに関連するソフトウェアであり、クライアント２をネットワーク５（図１参照）に接続する。
要求処理部２２は、セグメント要求の生成に関する全体の処理を行い、通信部２１を介してセグメント要求をサーバ３に送信する。
【００２２】
記憶部２４には、負荷が高いサーバ３へのセグメント要求が禁止されていることを示す情報（「busy:server xxxx」、ここで「xxxx」はサーバを識別する情報）が記憶される。記憶部２４に記憶される当該情報を「要求禁止フラグ」と呼ぶ場合がある。
要求ヘッダ処理部２３は、記憶部２４の要求禁止フラグ（「busy:server xxxx」、ここで「xxxx」はサーバを識別する情報）が立っている（オンされている）場合、その情報をセグメント要求のヘッダに記載する。
【００２３】
なお、「busy:server xxxx」は、「第３情報」および「第５情報」の一例であり、「第３情報」および「第５情報」の一例は、「busy:server xxxx」に限るものではない。
【００２４】
応答処理部２５は、セグメント要求に対する応答メッセージ（セグメントを含む）をサーバ３から受け取り、受け取った応答メッセージに関する全体の処理を行う。
応答ヘッダ処理部２６は、応答を行ったサーバ３へのセグメント要求が禁止されていることを示す情報（「serverstatus:busy」）が応答メッセージに記載されている場合、当該サーバ３への要求が禁止されていることを示す情報（「busy:server xxxx」、ここで「xxxx」はサーバを識別する情報）を記憶部２４に記録する（つまり、要求禁止フラグをオンする）。また、応答ヘッダ処理部２６は、セグメント要求を禁止されていたサーバ３への要求が可能になったことを示す情報（「ok:server xxxx」、ここで「xxxx」はサーバを識別する情報）が応答メッセージに記載されている場合、記憶部２４から当該サーバ３への要求が禁止されていることを示す情報（「busy:server xxxx」、ここで「xxxx」はサーバを識別する情報）を削除する（つまり、要求禁止フラグをオフする）。
【００２５】
再生処理部２７は、受け取った応答に含まれるセグメントの再生を処理し、ディスプレイ２ａに映像を表示するとともに、図示しないスピーカを通じて音声を出力する。
【００２６】
図４を参照して、セグメント要求に対する応答メッセージを受信した場合のクライアント２における要求禁止フラグの処理を説明する。図４は、クライアント２での要求禁止フラグの処理を示すフローチャートの例示である。
【００２７】
応答処理部２５は、通信部２１を介してセグメント要求に対する応答メッセージをサーバ３から受信する（ステップＳ１１）。続いて、応答ヘッダ処理部２６は、応答メッセージのヘッダに「serverstatus:busy」があるか否かを確認し（ステップＳ１２）、当該情報がヘッダにある場合（ステップＳ１２で“ｙｅｓ”）、応答を行ったサーバ３への要求禁止フラグ（「busy:server xxxx」）を立てる（ステップＳ１３）。
【００２８】
また、応答ヘッダ処理部２６は、ヘッダに「serverstatus:busy」がある応答メッセージを特定のサーバ３から受信済みであり（つまり、特定のサーバ３への要求禁止フラグ（「busy:server yyyy」）が立っている）、かつ、受信した応答メッセージのヘッダに当該サーバ３に関する「ok:server yyyy」があるか否かを判定する（ステップＳ１４）。要求禁止フラグがオンのサーバ３に関する「ok:server yyyy」が記載される応答メッセージを受信した場合（ステップＳ１４で“ｙｅｓ”）、応答ヘッダ処理部２６は、当該サーバ３への要求禁止フラグ（「busy:server xxxx」）を削除する（ステップＳ１５）。
【００２９】
図５を参照して（適宜、図１ないし図４参照）、サーバ３の構成を説明する。図５は、サーバ３のブロック図である。サーバ３は、クライアント２（図１参照）の要求に応じてコンテンツを配信する装置である。また、サーバ３は、バックヤードのネットワーク４（図１参照）を介して、コンテンツ配信の制限に関する情報を他のサーバ３との間で通信する。コンテンツ配信の制限は、サーバ３の負荷に応じて実行される。
【００３０】
サーバ３は、通信部１１と、要求処理部１２と、記憶部１３と、要求ヘッダ処理部１４と、応答処理部１５と、セグメント記憶部１６と、応答ヘッダ処理部１７と、負荷測定部１８と、アクセス解析部１９と、状態監視部２０と、ＨＤＤ（Hard Disk Drive）３ａとを備える。ＨＤＤ３ａには、コンテンツがセグメント単位で格納されている。
【００３１】
通信部１１、要求処理部１２、記憶部１３、要求ヘッダ処理部１４、応答処理部１５、セグメント記憶部１６、応答ヘッダ処理部１７、負荷測定部１８、アクセス解析部１９および状態監視部２０は、例えば、ＣＰＵ（Central Processing Unit）によるプログラム実行処理や専用回路等により実現される。実行処理用のプログラムは、コンピュータによる読み取り可能な記録媒体（例：ＣＤ−ＲＯＭ）に記憶して提供することができる。また、そのプログラムを、インターネットなどのネットワークを通して提供することもできる。
【００３２】
なお、通信部１１、応答処理部１５、セグメント記憶部１６などは、「第１処理部」の一例であり、「第１処理部」の一例は、通信部１１、応答処理部１５、セグメント記憶部１６などに限るものではない。
また、負荷測定部１８は、「第２処理部」の一例であり、「第２処理部」の一例は、負荷測定部１８に限るものではない。
また、状態監視部２０は、「第３処理部」の一例であり、「第３処理部」の一例は、状態監視部２０に限るものではない。
また、応答ヘッダ処理部１７は、「第４処理部」の一例であり、「第４処理部」の一例は、応答ヘッダ処理部１７に限るものではない。
また、応答処理部１５は、「第５処理部」の一例であり、「第５処理部」の一例は、応答処理部１５に限るものではない。
【００３３】
通信部１１は、例えばＮＩＣ（Network Interface Card）やそれに関連するソフトウェアであり、サーバ３をネットワーク４，５（図１参照）に接続する。
【００３４】
記憶部１３には、クライアント２のアドレス、アクセス時間およびアクセスしたコンテンツを含むアクセスログが記憶される。
また、記憶部１３には、自身の負荷（ＣＰＵ使用量、ＮＩＣの送信量、ＤＩＳＫのＩＯ等）が上限を超えたことを示す情報（「server_busy」）が記憶される。記憶部１３に記憶される当該情報を「高負荷フラグ」と呼ぶ場合がある。
また、記憶部１３には、自身の負荷（ＣＰＵ使用量、ＮＩＣの送信量、ＤＩＳＫのＩＯ等）が上限より下回っていることを示す情報（「server_ok」）が記憶される。記憶部１３に記憶される当該情報を「低負荷フラグ」と呼ぶ場合がある。
また、記憶部１３には、他のサーバ３が配信制限を解除したことを示す情報（「server xxxx:server_ok」、ここで「xxxx」はサーバを識別する情報）が記憶される。記憶部１３に記憶される当該情報を「配信制限解除フラグ」と呼ぶ場合がある。
【００３５】
負荷測定部１８は、ＮＩＣの送信量、ＣＰＵ負荷、ＤＩＳＫのＩＯ量などを定期的に測定し、上限に達している場合には記憶部１３の高負荷フラグ「server_busy」を立てる（オンする）。また、負荷測定部１８は、定期的に負荷を調べて負荷が上限より下回った事を確認したら、記憶部１３から高負荷フラグ「server_busy」を消して低負荷フラグ「server_ok」を立てる。
【００３６】
（クライアントとの間で行うセグメント要求／応答に関する機能）
要求処理部１２は、通信部１１を介してクライアント２からセグメント要求を受け取り、受け取ったセグメント要求に関する全体の処理を行う。
要求ヘッダ処理部１４は、セグメント要求のヘッダに関する処理を行う。
【００３７】
アクセス解析部１９は、定期的に記憶部１３に記録されているアクセスログを取得し、過去数分間のアクセス頻度を集計して頻度の高い順にクライアント２のランキングを作成する。
【００３８】
応答処理部１５は、応答メッセージの生成に関する全体の処理を行い、通信部１１を介して応答メッセージをクライアント２に送信する。
セグメント記憶部１６は、応答処理部１５の要求に応じて該当するセグメントを応答処理部１５に返す。セグメント記憶部１６には、返答するセグメントが一時的に記憶される。
【００３９】
応答ヘッダ処理部１７は、記憶部１３の「高負荷フラグ」（「server_busy」）がオンされ、かつ、セグメント要求の要求がアクセス頻度のランキング上位に入っているクライアント２からの場合、応答メッセージのヘッダにセグメント要求が禁止されていることを示す「serverstatus:busy」を記載する。
また、応答ヘッダ処理部１７は、セグメント要求のヘッダに特定のサーバ３への要求が禁止されていることを示す「busy:server xxxx」があり、かつ、当該特定のサーバ３から配信制限を解除することを示す配信制限解メッセージを受け取った（つまり、配信制限解除フラグ「server xxxx: server_ok」が立っている）場合、応答メッセージのヘッダにセグメント要求を禁止されていたサーバ３への要求が可能になったことを示す「ok:server xxxx」を記載する。
【００４０】
なお、「serverstatus:busy」は、「第４情報」の一例であり、「第４情報」の一例は、「serverstatus:busy」に限るものではない。
【００４１】
図６を参照して、サーバ３がセグメント要求を受信した場合の処理を説明する。図６は、サーバ３がセグメント要求を受信した場合の処理を示すフローチャートの例示である。
【００４２】
要求処理部１２は、通信部１１を介してクライアント２からセグメント要求を受信する（ステップＳ２１）。応答ヘッダ処理部１７は、受信したセグメント要求のヘッダに「busy:server xxxx」があり、かつ、当該サーバ３から配信制限解除メッセージを受信済みである場合（ステップＳ２２で“ｙｅｓ”）、応答メッセージのヘッダに「ok:server xxxx」を記載する（ステップＳ２３）。
【００４３】
なお、配信制限解除メッセージは、「第１情報」の一例であり、「第１情報」の一例は、配信制限解除メッセージに限るものではない。
また、「ok:server xxxx」は、「第２情報」の一例であり、「第２情報」の一例は、「ok:server xxxx」に限るものではない。
【００４４】
また、応答ヘッダ処理部１７は、負荷が上限を超えており（ステップＳ２４で“ｙｅｓ”）、かつ、アクセス頻度の高いクライアント２からの要求である場合（ステップＳ２５で“ｙｅｓ”）、応答メッセージのヘッダに「serverstatus:busy」を記載する（ステップＳ２６）。そして、応答処理部１５は、ステップＳ２３またはステップＳ２６で情報を付したヘッダを有した応答メッセージ（セグメントを含む）をクライアント２に送信する（ステップＳ２７）。
【００４５】
（他のサーバとの間で行う配信制限解除メッセージ／応答に関する機能）
図５に示す状態監視部２０は、定期的に記憶部１３を調べて低負荷フラグ「server_ok」が立ったら、配信制限を解除することを示す配信制限解除メッセージを他の全てのサーバ３に通信部１１を介して送信する。状態監視部２０は、配信制限解除メッセージの送信に成功したら、記憶部１３の低負荷フラグ「server_ok」を削除する。
【００４６】
要求処理部１２は、通信部１１を介して他のサーバ３から配信制限解除メッセージを受け取る。要求処理部１２は、配信制限解除メッセージを受け取った場合、他のサーバ３が配信制限を解除したことを示す情報（「server xxxx:server_ok」、ここで「xxxx」はサーバを識別する情報）を記憶部１３に記録する。そして、応答処理部１５は、配信制限解除メッセージの発信元のサーバ３に「200 OK」を応答する。
【００４７】
図７を参照して、サーバ３の負荷が上限を下回った場合の処理例を説明する。サーバ３の負荷が上限を下回った場合の処理を示すフローチャートの例示である。
【００４８】
負荷測定部１８は、自身の負荷が上限を下回ったか否かを判定し（ステップＳ３１）、負荷が上限を下回った場合（ステップＳ３１で“ｙｅｓ”）、状態監視部２０は、配信制限解除メッセージを他の全てのサーバ３に送信する（ステップＳ３２）。
【００４９】
≪第１実施形態に係るコンテンツ配信システムの動作≫
次に、第１実施形態に係るコンテンツ配信システム１の動作について説明する。ここでは、サーバ３の負荷（ＣＰＵ使用量、ＮＩＣの送信量、ＤＩＳＫのＩＯ等）に応じて当該サーバ３からの配信を制限する場合の動作（配信制限動作）と、配信を制限した状態から配信の制限を解除する場合の動作（配信制限解除動作）との二通りに分けて説明する。
【００５０】
配信制限動作は、サーバ３の負荷（ＣＰＵ使用量、ＮＩＣの送信量、ＤＩＳＫのＩＯ等）が上限を超えた場合の動作である。また、配信制限解除動作は、配信制限状態からサーバ３の負荷が上限を下回った場合の動作である。なお、配信制限動作を実行する閾値である上限と配信制限解除動作を実行する閾値である上限とは、異なる値であってもよい。つまり、配信制限動作を実行する閾値である上限として「第一の閾値」を用い、また、配信制限解除動作を実行する閾値である上限として第一の閾値とは異なる「第二の閾値」を用いてもよい。
【００５１】
＜コンテンツの配信制限動作＞
図８を参照して（適宜、図１ないし図７参照）、第１実施形態に係るコンテンツ配信システム１におけるコンテンツの配信制限動作を説明する。ここで、クライアント２は、セグメントの取得先が記載されたセグメントリストを予め取得している。また、クライアント２は、サーバ３Ａへのアクセス頻度が高く、主としてサーバ３に対してセグメントの要求を行う場合を想定して説明する。
【００５２】
（ステップＳ４１）
最初に、クライアント２は、サーバ３Ａにセグメントを要求する（ステップＳ４１）。セグメント要求を受け取ったサーバ３Ａの処理は、以下の通りである。
通信部１１は、受信したセグメント要求を要求処理部１２に送る。要求処理部１２は、セグメント要求をヘッダとメッセージとに分けて、ヘッダを要求ヘッダ処理部１４へ送り、メッセージを応答処理部１５に送る。また、要求処理部１２は、クライアント２のアドレス、アクセス時間およびアクセスしたコンテンツを含むアクセスログを記憶部１３に記録する。また、要求ヘッダ処理部１４は、ヘッダにサーバ３の状態に関する情報が記載されていないかを確認する。ここでは、ヘッダにサーバ３の状態に関する情報が記載されていないので、何も処理を行わない。
【００５３】
（ステップＳ４２）
続いて、サーバ３Ａは、クライアント２に「serverstatus:busy」記載のセグメントを応答する（ステップＳ４２）。セグメントを応答するサーバ３Ａの処理は、以下の通りである。
アクセス解析部１９は、定期的に記憶部１３に記録されているアクセスログを取得し、過去数分間のアクセス頻度を集計して頻度の高い順にクライアント２のランキングを作成する。また、負荷測定部１８は、ＮＩＣの送信量、ＣＰＵ負荷、ＤＩＳＫのＩＯ量などを定期的に測定し、負荷が上限に達している場合には記憶部１３に高負荷フラグ「server_busy」を立てる。ここでは、サーバ３Ａの負荷が上限に達しているものとする。
【００５４】
また、応答処理部１５は、応答ヘッダ処理部１７に応答ヘッダを要求する。応答ヘッダ処理部１７は、記憶部１３に高負荷フラグ「server_busy」が立っていて、かつ、要求元がアクセス頻度のランキング上位に入っているクライアントからの場合、応答ヘッダに「serverstatus:busy」を付けて応答処理部１５に返す。ここでは、両方の条件を満たすので、応答ヘッダ処理部１７は、応答ヘッダに「serverstatus:busy」を付けて応答処理部１５に返す。
そして、応答処理部１５は、クライアント２から要求されたセグメントをセグメント記憶部１６に要求し、セグメント記憶部１６は、要求されたセグメントを応答処理部１５に返す。応答処理部１５は、ヘッダと併せてセグメントを、通信部１１を通しクライアント２に応答する。
【００５５】
（ステップＳ４３）
続いて、クライアント２は、サーバ３Ａからの応答を受け取り、負荷が上限に達していないサーバ３Ｂまたはサーバ３Ｃ（ここでは、サーバ３Ｂ）に次のセグメントを要求する（ステップＳ４３）。セグメントを要求するクライアント２の処理は、以下の通りである。
通信部２１は、サーバ３Ａからの応答を受け取って応答処理部２５に送る。応答処理部２５は、応答をヘッダとセグメントとに分け、ヘッダを応答ヘッダ処理部２６に送り、セグメントを再生処理部２７に送る。
【００５６】
応答ヘッダ処理部２６は、サーバ３Ａからの応答メッセージのヘッダに「serverstatus:busy」が記載されているので、記憶部２４に「busy:server3A」を記録する。再生処理部２７は、セグメントの再生を行い、要求処理部２２に次のセグメントを要求する。要求処理部２２は、要求ヘッダ処理部２３にセグメント要求のヘッダを要求する。要求ヘッダ処理部２３は、記憶部２４に「busy:server3A」が記録されている事を確認し、ヘッダに「busy:server3A」を記載して要求処理部２２にヘッダを返す。要求処理部２２は、次に要求するセグメントのurlを記載し、通信部２１を通してサーバ３Ｂまたはサーバ３Ｃに次のセグメントを要求する。ここでは、サーバ３Ｂに次のセグメントを要求したとする。
【００５７】
（ステップＳ４４）
続いて、サーバ３Ｂは、次のセグメントを応答する。セグメントを応答するサーバ３Ｂの処理は、ステップＳ４２で説明した処理と同様である。ただし、負荷の上限は超えていない場合、サーバ３Ｂは「serverstatus:busy」を応答メッセージのヘッダに付けない。
【００５８】
（ステップＳ４５）
続いて、クライアント２は、サーバ３Ｂからの応答を受け取り、負荷が上限に達していないサーバ３Ｂまたはサーバ３Ｃに次のセグメントを引き続き要求する（ステップＳ４５）。ここでは、サーバ３Ｃに次のセグメントを要求したとする。セグメントを要求するクライアント２の処理は、ステップＳ４３で説明した処理と同様である。ただし、応答ヘッダに「serverstatus:busy」がついていない場合、記憶部２４に「busy:server3B」や「busy:server3C」は記録されない。
【００５９】
（ステップＳ４６）
続いて、サーバ３Ｃは、次のセグメントを応答する。セグメントを応答するサーバ３Ｃの処理は、ステップＳ４４で説明した処理と同様である。
【００６０】
このように、負荷が上限を超えたサーバ３（図８では、サーバ３Ａ）は、自身にアクセスするクライアント２の数を減らす事ができる。
【００６１】
＜コンテンツの配信制限解除動作＞
図９を参照して（適宜、図１ないし図８参照）、第１実施形態に係るコンテンツ配信システム１におけるコンテンツの配信制限解除動作を説明する。ここでは、図８の動作の続きを想定して説明する。そのため、クライアント２は、セグメントの取得先が記載されたセグメントリストを予め取得している。また、クライアント２は、サーバ３Ａへのアクセス頻度が高く、主としてサーバ３に対してセグメントの要求を行う場合を想定して説明する。
【００６２】
（ステップＳ５１，５３）
サーバ３Ａは、自身の配信制限を解除する場合、他の全てのサーバ３（ここでは、サーバ３Ｂ，３Ｃ）に配信制限解除メッセージを送る。配信制限を解除するサーバ３Ａの処理は、以下の通りである。
負荷測定部１８は、定期的に負荷を調べて負荷が上限より下回った事を確認したら、記憶部１３から高負荷フラグ「server_busy」を消して低負荷フラグ「server_ok」を立てる。状態監視部２０は、定期的に記憶部１３を調べて低負荷フラグ「server_ok」が立ったら、通信部１１を通して配信制限解除メッセージを他の全てのサーバ３（ここでは、サーバ３Ｂ，３Ｃ）に送る。状態監視部２０は、配信制限解除メッセージの送信に成功したら、記憶部１３の高負荷フラグ「server_ok」を削除する（オフする）。
【００６３】
（ステップＳ５２，５４）
続いて、配信制限解除メッセージを受け取ったサーバ３（ここでは、サーバ３Ｂ，３Ｃ）は、配信制限解除メッセージに対して応答する。配信制限解除メッセージを受け取ったサーバ３（ここでは、サーバ３Ｂ，３Ｃ）の処理は、以下の通りである。
サーバ３Ｂ，３Ｃの要求処理部１２は、通信部１１を通してサーバ３Ａから配信制限解除メッセージを受け取る。要求処理部１２は、配信制限解除メッセージを受け取った場合、配信制限を受けているクライアント２（ここでは、記憶部２４に「busy:server31」が記載）の配信制限を解除するため、記憶部１３に「server3A:server_ok」を記録する。そして、応答処理部１５は、サーバ３Ａに「200 OK」を応答する。
【００６４】
（ステップＳ５５）
クライアント２は、サーバ３Ａの配信制限が解除されたことを知らないので、サーバ３Ｂまたはサーバ３Ｃに次のセグメントを要求する（ステップＳ５５）。ここでは、サーバ３Ｂに次のセグメントを要求したとする。セグメントを要求するクライアント２の処理は、ステップＳ４３で説明した処理と同様である。記憶部２４に「busy:server3A」が有ればヘッダに「busy:server3A」を記載する。ここでは、記憶部２４に「busy:server3A」が有るので、ヘッダに「busy:server3A」を引き続き記載する。
【００６５】
（ステップＳ５６）
続いて、サーバ３Ｂは、次のセグメントを応答する。セグメントを応答するサーバ３Ｂの処理は、以下の通りである。
要求処理部１２は、通信部１１を介してセグメントの要求を受ける。要求処理部１２は、セグメント要求をヘッダとメッセージとに分けて、ヘッダを要求ヘッダ処理部１４へ送り、メッセージを応答処理部１５に送る。要求処理部１２は、クライアント２のアドレス、アクセス時間およびアクセスしたコンテンツを含むアクセスログを記憶部１３に記録する。
また、要求ヘッダ処理部１４は、ヘッダにある「busy:server3A」を確認し、記憶部１３に「notify:address」を記録する。ここでの「address」は、クライアント２のアドレスである。
【００６６】
また、応答処理部１５は、応答ヘッダ処理部１７に応答ヘッダを要求する。応答ヘッダ処理部１７は、記憶部１３に「notify:address」と「server3A: server_ok」がある事を確認し、応答ヘッダに「ok:server3A」を記載する。つまり、応答ヘッダ処理部１７は、セグメント要求のヘッダにサーバ３Ａへの要求が禁止されていることを示す「busy:server3A」があり、かつ、サーバ３Ａから配信制限を解除することを示す配信制限解メッセージを受け取った（つまり、配信制限解除フラグ「server3A:server_ok」が立っている）場合、応答ヘッダに「ok:server3A」を記載する。そして、応答ヘッダ処理部１７は、ヘッダを応答処理部１５に返す。応答処理部１５は、セグメント記憶部１６から要求されたセグメントを取得し、通信部１１を通してクライアント２にセグメントを応答する。
【００６７】
（ステップＳ５７）
続いて、クライアント２は、サーバ３Ｂからの応答を受け取り、サーバ３Ａに次のセグメントを要求する（ステップＳ５７）。セグメントを要求するクライアント２の処理は、以下の通りである。
応答処理部２５は、通信部２１を通して取得した応答をヘッダとセグメントとに分け、ヘッダを応答ヘッダ処理部２６に送り、セグメントを再生処理部２７に送る。
【００６８】
応答ヘッダ処理部２６は、応答ヘッダの「ok:server3A」を確認し、記憶部２４から「busy:server3A」を削除する。再生処理部２７は、セグメントの再生を行い、要求処理部２２に次のセグメントを要求する。要求処理部２２は、要求ヘッダ処理部２３にセグメント要求のヘッダを要求する。要求ヘッダ処理部２３は、記憶部２４に配信制限中のサーバがない事を確認し(「busy:server3A」等がない)、ヘッダに「busy:server3A」等は記載しない。要求処理部２２は、次に要求するセグメントのurlを記載し、通信部２１を通してサーバ３Ａに次のセグメントを要求する。
【００６９】
（ステップＳ５８）
続いて、サーバ３Ａは、次のセグメントを応答する（ステップＳ５８）。セグメントを応答するサーバ３Ａの処理は、ステップＳ５６で説明した処理と同様である。ただし、セグメント要求には「busy:server3A」がついていない。
【００７０】
このように、負荷が上限を下回ったサーバ３（図９では、サーバ３Ａ）は、自身にアクセスするクライアント２の数を増やす事ができる。
【００７１】
以上のように、第１実施形態に係るコンテンツ配信システム１は、サーバ３の負荷が上限に達した場合、セグメント要求に対する応答ヘッダを通じてその事をクライアント２に通知する。つまり、セグメント要求が禁止されていることを示す情報「serverstatus:busy」を応答メッセージのヘッダに記載する。そのため、負荷が上限を超えたサーバ３に対するクライアント２によるセグメントの要求を制限できる。
また、第１実施形態に係るコンテンツ配信システム１は、サーバ３の負荷が上限を下回った場合、他のサーバを通じてその事をクライアント２に通知する。つまり、サーバ３は、他のサーバに配信制限解除メッセージを送信し、それを受けとった他のサーバは、セグメント要求を禁止されていたサーバ３への要求が可能になったことを示す情報「ok:server xxxx」を応答ヘッダに記載する。そのため、負荷が上限を下回ったサーバ３に対するクライアント２によるセグメントの要求を再開できる。
その結果、各サーバ３で負荷の管理を行え、また、割り当て可能なサーバのＵＲＬをＭＦファイルにその都度記載する必要もないので、負荷の制御によるタイムラグを小さくできる。これにより、タイムラグを考慮して負荷の上限を低く設定する必要がないので、配信効率の低下を抑えることができる。
【００７２】
［第２実施形態］
≪第２実施形態に係るコンテンツ配信システムの構成≫
図１０は、第２実施形態に係るサーバ３Ａのブロック図である。第２実施形態に係るサーバ３Ａは、管理部６１をさらに備える点が第１実施形態に係るサーバ３と異なる。以下では、第１実施形態との相違点について説明する。
【００７３】
管理部６１は、記憶部１３と繋がっており、コンテンツの配信を制限する要求をクライアント単位で外部から受け付け、その情報を記憶部１３に記録する。コンテンツの配信を制限するクライアント２は、例えば、契約によってコンテンツの配信量が決まっている者や不正をしている者などである。
【００７４】
応答ヘッダ処理部１７は、記憶部１３に記録されているコンテンツの配信を制限するクライアント２からのセグメント要求に対しては、応答メッセージのヘッダに「serverstatus:busy」を返すようにする。
【００７５】
以上のように、第２実施形態に係るコンテンツ配信システム１は、特定のクライアント２に対するコンテンツの配信の制限を容易に行える。例えば、特定のクライアント２に対する配信を制限する旨を記載したメッセージを全てのサーバ３に対して送ることで、当該特定のクライアント２への配信は制限される。
【００７６】
［変形例］
以上、本発明の実施形態について説明したが、本発明はこれに限定されるものではなく、特許請求の範囲の趣旨を変えない範囲で実施することができる。実施形態の変形例を以下に例示する。
【００７７】
第１実施形態では、アクセス頻度を集計し、負荷が上限を超えた場合にアクセス頻度のランキング上位に入っているクライアント２からのセグメントの要求を制限していた。しかしながら、アクセス頻度に関係なく、負荷が上限を超えた場合に全てのクライアント２に対して制限をかけるようにしてもよい。
【符号の説明】
【００７８】
１      コンテンツ配信システム
２      クライアント
３      サーバ
４，５  ネットワーク
１１    通信部
１２    要求処理部
１３    記憶部
１４    要求ヘッダ処理部
１５    応答処理部
１６    セグメント記憶部
１７    応答ヘッダ処理部
１８    負荷測定部
１９    アクセス解析部
２０    状態監視部
２１    通信部
２２    要求処理部
２３    要求ヘッダ処理部
２４    記憶部
２５    応答処理部
２６    応答ヘッダ処理部
２７    再生処理部
【図１】
2020136933.tif 000003
【図２】
2020136933.tif 000004
【図３】
2020136933.tif 000005
【図４】
2020136933.tif 000006
【図５】
2020136933.tif 000007
【図６】
2020136933.tif 000008
【図７】
2020136933.tif 000009
【図８】
2020136933.tif 000010
【図９】
2020136933.tif 000011
【図１０】
2020136933.tif 000012