(57)【要約】【課題】コンテンツ配信に必要な応答性能を確保するとともに待機系コンテンツ配信装置の台数を削減することのできるコンテンツ配信装置を提供する。【解決手段】本発明に係るコンテンツ配信装置は、フェイルオーバが発生した時に待機系コンテンツ配信装置がコンテンツデータに対して実行すべき準備処理を待機系コンテンツ配信装置にあらかじめ通知しておく。【選択図】図６
2011186772.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツデータを格納する記憶部と、
前記コンテンツデータを配信する配信部と、
待機系コンテンツ配信装置に処理を引き継ぐフェイルオーバを行う時に前記待機系コンテンツ配信装置が引き継ぐ前記処理に対して実行すべき準備処理を示す準備処理情報と、
前記準備処理を前記待機系コンテンツ配信装置に通知して当該準備処理をあらかじめ実行しておくよう指示する連携部と、
を備えたことを特徴とするコンテンツ配信装置。
【請求項２】
前記連携部は、
前記コンテンツデータを配信する処理を行う際に用いるパラメータを、前記待機系コンテンツ配信装置に送信してあらかじめ保持させておく
ことを特徴とする請求項１記載のコンテンツ配信装置。
【請求項３】
前記準備処理情報は前記準備処理の優先度を保持しており、
前記連携部は、
その優先度が高い順に前記準備処理を実行するよう前記待機系コンテンツ配信装置に指示する
ことを特徴とする請求項１記載のコンテンツ配信装置。
【請求項４】
前記準備処理情報は、
前記コンテンツデータの配信状態に応じて前記優先度を補足する優先度補助情報を保持しており、
前記優先度補助情報は、
前記コンテンツデータの配信回数、前記コンテンツデータを配信する際の画質、または前記コンテンツデータの再送回数のうち少なくともいずれかを保持しており、
前記連携部は、
前記優先度と前記優先度補助情報を用いて算出した総合優先度に準じて前記準備処理を実行するよう前記待機系コンテンツ配信装置に指示する
ことを特徴とする請求項３記載のコンテンツ配信装置。
【請求項５】
前記連携部は、
当該コンテンツ配信装置と前記コンテンツデータの配信先との間の接続状態を示すコネクション情報を、前記パラメータとして前記待機系コンテンツ配信装置に送信する
ことを特徴とする請求項２記載のコンテンツ配信装置。
【請求項６】
前記連携部は、前記コネクション情報として、
前記コンテンツデータの配信先に対して既に送出したデータの末尾位置を示すポインタ情報と、
前記コンテンツデータの配信先から受信確認応答を既に受け取ったデータの末尾位置を示すポインタ情報と、
を前記待機系コンテンツ配信装置に送信する
ことを特徴とする請求項５記載のコンテンツ配信装置。
【請求項７】
前記連携部は、
前記記憶部が前記コンテンツデータを格納するファイルシステムの構成を示すファイルシステム情報を、前記パラメータとして前記待機系コンテンツ配信装置に送信する
ことを特徴とする請求項２記載のコンテンツ配信装置。
【請求項８】
前記連携部は、
前記待機系コンテンツ配信装置が前記準備処理を実行するのに十分なリソースを有するか否かを確認し、十分なリソースがない場合にはその旨を報知する
ことを特徴とする請求項１記載のコンテンツ配信装置。
【請求項９】
前記準備処理を実行する準備処理部を備え、
前記連携部は、
当該コンテンツ配信装置が待機系コンテンツ配信装置である場合は、稼動系コンテンツ配信装置より前記準備処理を実行するよう指示を受けると、前記準備処理部にその旨を通知し、
前記準備処理部はその通知にしたがって前記準備処理を実行する
ことを特徴とする請求項１記載のコンテンツ配信装置。
【請求項１０】
当該コンテンツ配信装置のＯＳを仮想化するハイパバイザを備え、
前記配信部の稼動状況を監視する監視部を前記ハイパバイザの配下に配置し、
前記監視部は、
前記ハイパバイザが稼動している間は、当該コンテンツ配信装置のＯＳが正常に稼動しているか否かに関わらず動作する
ことを特徴とする請求項１記載のコンテンツ配信装置。
【請求項１１】
前記ハイパバイザの配下に前記連携部を配置し、
前記連携部は、
前記ハイパバイザが稼動している間は、当該コンテンツ配信装置のＯＳが正常に稼動しているか否かに関わらず動作する
ことを特徴とする請求項１０記載のコンテンツ配信装置。
【請求項１２】
前記連携部は、
前記ハイパバイザが稼動している間は、当該コンテンツ配信装置のＯＳが正常に稼動しているか否かに関わらず、前記コンテンツデータを配信する処理を行う際に用いるパラメータを、前記待機系コンテンツ配信装置に送信してあらかじめ保持させておく
ことを特徴とする請求項１１記載のコンテンツ配信装置。
【請求項１３】
前記監視部は、
当該コンテンツ配信装置のＯＳの種類によらず同一の所定時間間隔で、前記配信部の稼動状況を監視する
ことを特徴とする請求項１０記載のコンテンツ配信装置。
【請求項１４】
複数の請求項１記載のコンテンツ配信装置と、
前記複数のコンテンツ配信装置の間でコンテンツ配信処理の負荷を分散させる負荷分散装置と、
を有し、前記複数のコンテンツ配信装置のうちいずれか１以上は前記待機系コンテンツ配信装置である
ことを特徴とするコンテンツ配信システム。
【請求項１５】
前記連携部は、
前記監視部の監視結果を前記負荷分散装置に通知し、
前記負荷分散装置は、
前記複数のコンテンツ配信装置の稼働状況を示すデータを保持する稼働状況情報を備え、
前記監視部より前記配信部の稼動状況についての通知を受け取るとその内容を前記稼働状況情報に反映し、
前記稼働状況情報の内容にしたがって前記複数のコンテンツ配信装置の間でコンテンツ配信処理の負荷を分散させる
ことを特徴とする請求項１４記載のコンテンツ配信システム。
【請求項１６】
前記連携部は、
いずれの前記待機系コンテンツ配信装置に対して前記準備処理を実行するよう指示すべきかを前記負荷分散装置に問い合わせ、
前記負荷分散装置は、
前記連携部より前記問い合わせを受けると、前記稼働状況情報を参照して前記複数のコンテンツ配信装置の稼働状況を取得し、前記準備処理を実行するのに十分なリソースを有する前記待機系コンテンツ配信装置を特定し、その前記待機系コンテンツ配信装置に対して前記準備処理を実行するよう指示すべき旨を返信する
ことを特徴とする請求項１５記載のコンテンツ配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを配信する技術に関するものである。
【背景技術】
【０００２】
近年、広帯域ネットワークを介して映像データなどを配信するコンテンツ配信が盛んに行われている。なかでも、有料配信用途のコンテンツ配信サーバや放送局内向け設備が備えるコンテンツ配信サーバは、サーバに障害が発生した場合にも映像を乱れることなく継続して配信するためのフェイルオーバ機能を備えることが要求される。
【０００３】
フェイルオーバ機能とは、稼動中のサーバに障害が発生した場合に、稼動中のサーバが実行していた処理を待機系サーバが引き継ぐ機能である。
【０００４】
フェイルオーバには、いくつかの方式がある。最も単純な方式は、２台のサーバを一組として相互にデータの同期を取る１対１フェイルオーバ方式である。しかし、この方式では稼動サーバ台数の２倍の台数の待機サーバが必要となるため、全サーバ台数に占める稼動サーバ台数の割合であるサーバの稼動効率が低下する。コンテンツ配信システムは、全世界へコンテンツを配信する非常に大規模なシステムも想定する必要があるため、稼動しているサーバの２倍のサーバ台数を要する本方式は非現実的である。
【０００５】
一方、ｎ＞ｍとなるようなｎ台の稼動サーバとｍ台の待機サーバを用いるｎ＋ｍフェイルオーバ方式では、少数の待機サーバを多数の稼動サーバが共有することになる。そのため、１対１フェイルオーバ方式よりも稼動効率が改善する。待機サーバの台数ｍが、稼動サーバの台数ｎより小さくなるほど改善効果が高く、待機サーバ台数が１台となるｎ＋１フェイルオーバで稼動効率が最大となる。
【０００６】
ところで、コンテンツ配信システムはフェイルオーバ発生時にも映像を途切れることなく配信を継続する必要がある。そのため、単純に稼動効率を改善するだけでなく、フェイルオーバ実行時におけるコンテンツ配信リクエストに対する応答時間が許容範囲を超えないように配慮する必要がある。
【０００７】
下記特許文献１では、稼動サーバの稼動直前の状態を保存しておくことにより、フェイルオーバを実行する時間の短縮を図っている。稼動直前のサーバ状態をあらかじめ保存しておくことにより、サーバが稼動状態になるまでに実行しなければならない一連の処理を省略することができる。したがって、待機サーバが稼動サーバの処理を引き継ぐまでの時間を短縮することができる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００８−２９３２４５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上記特許文献１に記載の技術では、フェイルオーバ実行時に待機サーバへアクセスが集中することにより過負荷状態が発生する可能性がある。例えば、フェイルオーバ実行時にはコンテンツデータを再度読み込み直す処理が発生し、処理負荷が上昇しやすい。特許文献１ではこの点を考慮していないため、応答時間が許容範囲内になるように多数の待機サーバを用意しなければならない。したがって、待機サーバの台数を十分に削減できない。
【００１０】
本発明は、上記のような課題を解決するためになされたものであり、コンテンツ配信に必要な応答性能を確保するとともに待機系コンテンツ配信装置の台数を削減することのできるコンテンツ配信装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明に係るコンテンツ配信装置は、フェイルオーバが発生した時に待機系コンテンツ配信装置がコンテンツデータに対して実行すべき準備処理を待機系コンテンツ配信装置にあらかじめ通知しておく。
【発明の効果】
【００１２】
本発明に係るコンテンツ配信装置によれば、フェイルオーバが発生したときに待機系コンテンツ配信装置が実行すべき処理をあらかじめ実行してフェイルオーバの準備をしておくことができる。これにより、フェイルオーバ発生時に待機系コンテンツ装置にアクセスが集中しても、過負荷状態に陥りにくくすることができるので、待機系コンテンツ配信装置の台数を抑えつつ、待機系コンテンツ配信装置の応答性能を確保することができる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係るコンテンツ配信システム１０の構成を示す図である。
【図２】コンテンツ配信装置１００の内部的な構成を示す機能ブロック図である。
【図３】コンテンツ配信装置１００がフェイルオーバを実行するときにおけるＣＰＵ１１０の利用率の経時変化を示すグラフである。
【図４】通常時におけるコンテンツ配信システム１０のコンテンツ配信シーケンスを示す図である。
【図５】フェイルオーバが発生したときにおける従来のコンテンツ配信システムのコンテンツ配信シーケンスを示す図である。
【図６】フェイルオーバが発生したときにおける本実施形態１に係るコンテンツ配信システム１０のコンテンツ配信シーケンスを示す図である。
【図７】図４で説明したシーケンスにおいて各プラグラムが果たす役割を説明する図である。
【図８】稼動系コンテンツ配信装置１００ａから待機系コンテンツ配信装置１００ｂに対して、フェイルオーバ発生時に生じる準備処理を実行しておくよう指示する際の各プログラムの役割を説明する図である。
【図９】コンテンツ配信装置１００から負荷分散装置２００に対して稼働状況を通知する際の各プログラムの役割を説明する図である。
【図１０】コンテンツ配信装置１００の記憶部１２０が格納する資源情報テーブル１２１の構成とデータ例を示す図である。
【図１１】負荷分散装置２００の記憶部２２０が格納する稼働状況テーブル２２１の構成例を示す図である。
【図１２】記憶部３２０がコンテンツデータ３２１をどのように格納しているかを説明する図である。
【図１３】視聴端末４００とコンテンツ配信装置１００の間で通信を確立するシーケンスを説明する図である。
【図１４】コンテンツデータ３２１の配信を継続するために必要な情報について説明する図である。
【図１５】図１２〜図１４で説明した情報がメモリ１４０上にどのように格納されているかを示す図である。
【図１６】図４のステップＳ４０３で視聴端末４００がコンテンツ配信装置１００に対して送信するコンテンツ配信リクエスト４１０のデータ形式を示す図である。
【図１７】図４のステップＳ４０２で負荷分散装置２００が送信するアクセス先応答２５０のデータ形式を示す図である。
【図１８】図４のステップＳ４０５でコンテンツ配信元装置３００が送信する認証応答３５０のデータ形式を示す図である。
【図１９】図４のステップＳ４０７で視聴端末４００がコンテンツ配信装置１００に対して送信するコンテンツ配信リクエスト４２０のデータ形式を示す図である。
【図２０】図４のステップＳ４１０でコンテンツ配信装置１００が視聴端末４００に対して送信する配信応答１５０のデータ形式を示す図である。
【図２１】図６のステップＳ６０５で待機系コンテンツ配信装置１００に対して送信される準備処理要求１６０のデータ形式を示す図である。
【図２２】稼動系コンテンツ配信装置１００が備える予測連携プログラム１４５の動作フロー図である。
【図２３】待機系コンテンツ配信装置１００が備える予測連携プログラム１４５の動作フロー図である。
【図２４】実施の形態６に係るコンテンツ配信システム１０の構成図である。
【図２５】実施の形態８に係るコンテンツ配信システム１０の構成図である。
【図２６】実施の形態９に係るコンテンツ配信システム１０の構成図である。
【発明を実施するための形態】
【００１４】
＜実施の形態１＞
図１は、本発明の実施の形態１に係るコンテンツ配信システム１０の構成を示す図である。コンテンツ配信システム１０は、１以上のコンテンツ配信装置１００、負荷分散装置２００、コンテンツ配信元装置３００、視聴端末４００を有する。コンテンツ配信装置１００、負荷分散装置２００、視聴端末４００は、ネットワーク５０１を介して接続されている。コンテンツ配信装置１００とコンテンツ配信元装置３００は、ネットワーク５０２を介して接続されている。
【００１５】
コンテンツ配信元装置３００は、コンテンツデータ３２１の一次配信元装置であり、記憶部３２０、配信プログラム３４１を備える。コンテンツデータ３２１は、例えば映像データ、音声データ、文書データなど、ユーザが視聴する任意種類のデータである。
【００１６】
記憶部３２０は、視聴端末４００に配信するコンテンツデータ３２１を格納する、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）等の記憶装置である。ＨＤＤは、ＳＡＳ（Ｓｅｒｉａｌ  Ａｔｔａｃｈｅｄ  ＳＣＳＩ）やＳＡＴＡディスク等である。また、ＨＤＤではなく、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｖｉｃｅ）であってもよいし、他の記憶装置であってもよい。また、記憶部３２０は複数あってもよい。配信プログラム３４１は、コンテンツデータ３２１を配信する動作を記述したソフトウェアである。コンテンツ配信元装置３００が備えるＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）等の演算装置は、配信プログラム３４１を実行することにより、コンテンツデータ３２１を配信する。
【００１７】
記憶部３２０は、ｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ  Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）のような既存技術を用いてネットワーク５０２に接続してもよいし、ＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）のような既存技術を用いてコンテンツ配信装置１００およびコンテンツ配信元装置３００に直接接続してもよい。さらには、コンテンツ配信元装置３００の内部に組み込んでもよい。
【００１８】
負荷分散装置２００は、視聴端末４００が送信するコンテンツ配信リクエストをいずれかのコンテンツ配信装置１００に振り分ける装置であり、アクセス分散プログラム２４１、予測連携プログラム２４２を備える。負荷分散装置２００が備えるＣＰＵ等の演算装置は、これら各プログラムを実行する。各プログラムの動作は後述する。
【００１９】
コンテンツ配信装置１００は、コンテンツ配信元装置３００の性能を補うため、コンテンツ配信元装置３００が送信するコンテンツデータ３２１を、コンテンツ配信元装置３００に代わって視聴端末４００に配信する装置である。コンテンツ配信装置１００は、コンテンツ配信機能に特化した装置であることを想定するが、コンテンツ配信元装置３００が備える機能の全部または一部をそのままコンテンツ配信装置１００の機能として用いることもできる。コンテンツ配信装置１００のうちいずれか１以上は稼動系装置、その他は待機系装置として動作する。
【００２０】
コンテンツ配信装置１００は、代理配信プログラム１４１、資源スヌーププログラム１４２、準備処理プログラム１４３、障害監視プログラム１４４、予測連携プログラム１４５を備える。コンテンツ配信装置１００が備えるＣＰＵ等の演算装置は、これら各プログラムを実行する。各プログラムの動作は後述する。
【００２１】
以後の説明において、同様の構成を備える装置等について言及するときは、符号にアルファベット添字を付けて各装置等を区別する。
【００２２】
図２は、コンテンツ配信装置１００の内部的な構成を示す機能ブロック図である。コンテンツ配信装置１００は、ＣＰＵ１１０、記憶部１２０、ネットワークＩ／Ｆ１３０、メモリ１４０を備える。
【００２３】
ＣＰＵ１１０は、メモリ１４０内に格納されている各プログラムを実行する。記憶部１２０は、コンテンツ配信装置１００の動作に必要となるデータ等を格納する、ＨＤＤ等の記憶装置である。ネットワークＩ／Ｆ１３０は、ネットワーク５０１と接続するためのインターフェースである。メモリ１４０は、各プログラムを格納する。
【００２４】
負荷分散装置２００とコンテンツ配信元装置３００は、図２と同様の構成を備えているが、メモリ１４０内のプログラムの構成が、図１に示すようにそれぞれ異なる。各装置が実行する動作の差異は、主に各プログラムの動作の差異によって生じる。
【００２５】
以下では、記載の便宜上、各プログラムを動作主体として説明することがあるが、実際に各プログラムを実行する動作主体は各装置が備えるＣＰＵ等の演算装置であることを付言しておく。
【００２６】
図３は、コンテンツ配信装置１００がフェイルオーバを実行するときにおけるＣＰＵ１１０の利用率の経時変化を示すグラフである。以下、図３の各区間におけるＣＰＵ利用率について説明する。
【００２７】
視聴端末４００がコンテンツ配信装置１００に接続を開始した直後の区間１１１０では、コンテンツ配信装置１００のＣＰＵ１１０はコンテンツデータ３２１をオープンする処理や認証処理等の初期処理を実行するため、ＣＰＵ利用率が高くなる（１１０１）。その後の定常状態である区間１１１１ではＣＰＵ利用率は低い（１１０２）。
【００２８】
一般に、定常状態である区間１１１１の時間長に比べて接続開始直後の区間１１１０の時間長は十分に短いので、区間１１１０において偶然に視聴端末４００からのアクセスが集中する可能性は無視できるほど小さい。したがって、コンテンツ配信処理を実行するために必要なＣＰＵ利用率は、配信するコンテンツの数に、区間１１１１（定常状態）におけるＣＰＵ利用率（１１０２）を乗じて算出することができる。
【００２９】
しかし、何らかの要因で区間１１１０においてアクセスが集中した場合には、複数のコンテンツの配信開始タイミングが同時刻に重なる。そのためＣＰＵ利用率は、配信するコンテンツの数に接続開始直後のＣＰＵ利用率（１１０１）を乗じて算出する必要がある。すなわち、アクセスが集中する場合には、アクセス集中がない場合に比べて１台のコンテンツ配信装置１００が配信できるコンテンツの本数は少なくなる。
【００３０】
特にフェイルオーバを実行する時には、稼動系コンテンツ配信装置が実行していたコンテンツ配信処理が一斉に待機系コンテンツ配信装置に移行することになるため、必ずアクセス集中が発生する。そのため、稼動系コンテンツ配信装置１台で処理していたコンテンツ配信処理は、必ずしも１台の待機系コンテンツ配信装置で引き継ぐことができない。それどころか、最悪の場合にはアクセス集中により限界を超えた過負荷状態となり、待機系コンテンツ配信装置１００が過負荷状態から復帰できなくなるスパイラルダウンに陥る可能性もある。また、バックエンドのコンテンツ配信元装置３００や記憶部３２０にもアクセス集中が発生するので、これらバックエンド装置がスパイラルダウンすることにより、コンテンツ配信システム１０全体がスパイラルダウンに陥る可能性もある。
【００３１】
図４は、通常時におけるコンテンツ配信システム１０のコンテンツ配信シーケンスを示す図である。以下、図４の各ステップについて説明する。
（図４：ステップＳ４０１）
視聴端末４００は、最初に負荷分散装置２００に対してコンテンツ配信リクエストを発行する。
（図４：ステップＳ４０２）
負荷分散装置２００は、複数のコンテンツ配信装置１００のなかから１台を選択し、そのアクセス先アドレスを視聴端末４００に返信する。
【００３２】
（図４：ステップＳ４０３）
視聴装置４００は、負荷分散装置２００から受け取ったアクセス先アドレス（コンテンツ配信装置１００）に宛てて、コンテンツ配信リクエストを発行する。このとき必要に応じて、認証処理や課金処理などのように、コンテンツを視聴するために必要な前処理を実行するようリクエストする。
（図４：ステップＳ４０４）
コンテンツ配信装置１００は、視聴装置４００からコンテンツ配信リクエストを受け取る。このリクエストにおいて、認証処理や課金処理のように、コンテンツ配信に特化したコンテンツ配信装置１００が実行することができない処理が発生する場合、コンテンツ配信装置１００はコンテンツ配信リクエストをコンテンツ配信元装置３００に転送する。コンテンツ配信装置１００のみで処理を実行できる場合は、ステップＳ４０４は省略することができる。
【００３３】
（図４：ステップＳ４０５）
コンテンツ配信元装置３００は、認証処理や課金処理を実行し、その結果をコンテンツ配信装置１００に返信する。
（図４：ステップＳ４０６）
コンテンツ配信装置１００は、コンテンツ配信元装置３００から受け取った返信をそのまま視聴端末４００に送信する。認証処理等が必要ない場合は、コンテンツ配信装置１００が自ら視聴端末４００に対する応答を生成する。
【００３４】
（図４：ステップＳ４０７）
視聴端末４００は、コンテンツ配信装置１００に宛てて、改めてコンテンツ配信リクエストを発行する。
（図４：ステップＳ４０８〜Ｓ４１０）
コンテンツ配信装置１００は、記憶部３２０上のコンテンツデータ３２１をオープンして読み込み可能な状態とする。以後コンテンツ配信装置１００は、コンテンツデータ３２１を順次読み取り、読み取ったデータ部分を視聴端末４００に対して配信する。
【００３５】
図５は、フェイルオーバが発生したときにおける従来のコンテンツ配信システムのコンテンツ配信シーケンスを示す図である。図５において、フェイルオーバを実行する過程でアクセス集中が発生する。以下、図５の各ステップについて説明する。記載の都合上、負荷分散装置２００およびコンテンツ配信元装置３００に係るステップは省略する。また、各装置の符号は本発明に係るコンテンツ配信システム１０と同じものを用いる。
（図５：ステップＳ５０１〜Ｓ５０２）
端末装置４００ａは、コンテンツ配信装置１００ａに対してコンテンツ配信リクエストを発行する。コンテンツ配信装置１００ａは、記憶部３２０からコンテンツデータ３２１を読み込んで視聴端末４００ａに送信する。
（図５：ステップＳ５０３〜Ｓ５０４）
端末装置４００ｂは、コンテンツ配信装置１００ｂに対してコンテンツ配信リクエストを発行する。コンテンツ配信装置１００ｂは、コンテンツデータ３２１を読み込んで視聴端末４００ａに送信する。
【００３６】
（図５：ステップＳ５０１〜Ｓ５０４：補足）
各視聴端末４００のユーザは、アドホックにコンテンツ配信を要求する。したがってこれらのステップ間の時間間隔５０５は、図３に示した区間１１１０の時間間隔よりも十分に長くなり、ＣＰＵ利用率が高くなるアクセスが短時間に集中する可能性は低い。したがって１台のコンテンツ配信装置１００ａのみで、余裕をもってコンテンツ配信処理を実行することができる。
（図５：ステップＳ５０６）
コンテンツ配信処理を継続中に、コンテンツ配信装置１００ａに障害が発生したものと仮定する。フェイルオーバ処理により、コンテンツ配信装置１００ａが実行していたコンテンツ配信処理は、コンテンツ配信装置１００ｂに引き継がれる。
【００３７】
（図５：ステップＳ５０７〜Ｓ５１０）
視聴端末４００ａおよび４００ｂは、ステップＳ５０１〜Ｓ５０４と同様の処理を、コンテンツ配信１００ｂに対して実行する。このとき、各視聴端末４００は略同時にコンテンツ配信リクエストを発行する。したがって、各ステップ間の時間間隔５１１は図３に示した区間１１１０の時間間隔と比較して短くなり、ＣＰＵ利用率が高くなるアクセスが短時間に集中することとなる。
【００３８】
以上説明したとおり、フェイルオーバが発生すると、フェイルオーバ先の待機系コンテンツ配信装置１００においてアクセス集中が発生しやすくなる。コンテンツ配信装置１００のスパイラルダウンを防ぐため、コンテンツ配信リクエストを待ち行列に格納して順次処理することも考えられるが、例えば映像配信を行うケースでは視聴中の映像が途切れないようにコンテンツ配信を継続する必要があるため、現実的でない。
【００３９】
図６は、フェイルオーバが発生したときにおける本実施形態１に係るコンテンツ配信システム１０のコンテンツ配信シーケンスを示す図である。以下、図６の各ステップについて説明する。図５と同様に、負荷分散装置２００およびコンテンツ配信元装置３００に係るステップは省略する。
（図６：ステップＳ６０１〜Ｓ６０４）
視聴端末４００は、コンテンツ配信装置１００ａに対してコンテンツ配信リクエストを発行する。コンテンツ配信装置１００ａは、記憶部３２０からコンテンツデータ３２１を読み込んで視聴端末４００ａに送信する。以後、端末装置４００とコンテンツ配信装置１００ａは、図３に示す定常状態（区間１１１１）となる。
（図６：ステップＳ６０５）
コンテンツ配信装置１００ａは、フェイルオーバが発生したときに待機系コンテンツ配信装置１００ｂが実行する必要がある準備処理をコンテンツ配信装置１００ｂに通知し、あらかじめ実行させておく。ここでいう準備処理とは、例えばコンテンツデータ３２１をオープンして読み込んでおく処理などのことである。
【００４０】
（図６：ステップＳ６０５：補足）
フェイルオーバが発生したときにコンテンツ配信装置１００ｂが実行する必要がある準備処理の内容は、例えばコンテンツ配信装置１００が備える記憶部１２０内に記憶しておけばよい。コンテンツ配信装置１００ａは、その準備処理を、コンテンツ配信装置１００ｂに通知する。
（図６：ステップＳ６０６〜Ｓ６０７）
コンテンツ配信装置１００ｂは、ステップＳ６０５でコンテンツ配信装置１００ａから通知された準備処理を実行する。ここでは記憶部３２０上のコンテンツデータ３２１をあらかじめ読み込んでおくシーケンスを例示した。
【００４１】
（図６：ステップＳ６０８）
コンテンツ配信処理を継続中に、コンテンツ配信装置１００ａに障害が発生したものと仮定する。フェイルオーバ処理により、コンテンツ配信装置１００ａが実行していたコンテンツ配信処理は、コンテンツ配信装置１００ｂに引き継がれる。
（図６：ステップＳ６０９〜Ｓ６１０）
視聴端末４００は、ステップＳ６０１と同様の処理を、コンテンツ配信１００ｂに対して実行する。コンテンツ配信装置１００ｂは、ステップＳ６０６〜Ｓ６０７において既にコンテンツデータ３２１を読み込んでいるので、改めてコンテンツデータ３２１を読み込むことなくコンテンツ配信を開始することができる。したがってコンテンツ配信装置１００ｂは、フェイルオーバが発生した時点において、ＣＰＵ利用率の上昇につながる処理を多数実行する必要がないので、複数の視聴端末４００からアクセスが集中しても、スパイラルダウンに陥る可能性は低いといえる。
【００４２】
以上、本実施の形態１に係るコンテンツ配信装置１００がコンテンツを配信するシーケンスについて説明した。
【００４３】
以上のように、本実施の形態１によれば、稼動系コンテンツ配信装置１００ａは、フェイルオーバが発生したときに待機系コンテンツ配信装置１００ｂが実行する準備処理をあらかじめ通知して実行させておく。これにより、フェイルオーバが発生した時点では、コンテンツ配信装置１００ｂはＣＰＵ利用率上昇の原因となり易い準備処理を既に実行済みの状態となる。したがって、複数の視聴端末４００からアクセスが集中しても、ＣＰＵ利用率を極端に上昇させずにコンテンツ配信を開始することができる。
【００４４】
＜実施の形態２＞
本発明の実施の形態２では、コンテンツ配信装置１００および負荷分散装置２００が備える各プログラムの役割について詳述する。また、準備処理について記述したデータテーブルの例を示す。各装置の構成は、実施の形態１と同様である。
【００４５】
図７は、図４で説明したシーケンスにおいて各プラグラムが果たす役割を説明する図である。以下、各プログラムの役割について説明する。
【００４６】
負荷分散装置２００が備えるＣＰＵは、アクセス分散プログラム２４１を実行する。アクセス分散プログラム２４１は、図４のステップＳ４０１〜Ｓ４０２における負荷分散装置２００側の処理、すなわち視聴端末４００がいずれのコンテンツ配信装置１００にアクセスすべきかを判断してそのアクセス先アドレスを返信する処理を実行するプログラムである。
【００４７】
コンテンツ配信装置１００が備えるＣＰＵ１１０は、代理配信プログラム１４１を実行する。代理配信プログラム１４１は、図４のステップＳ４０３〜Ｓ４１０におけるコンテンツ配信装置１００側の処理、すなわち視聴端末４００からコンテンツ配信リクエストを受けてコンテンツデーら３２１を読み込み、視聴端末４００に読み込んだデータを送信する処理を実行するプログラムである。
【００４８】
図８は、稼動系コンテンツ配信装置１００ａから待機系コンテンツ配信装置１００ｂに対して、フェイルオーバ発生時に生じる準備処理を実行しておくよう指示する際の各プログラムの役割を説明する図である。以下、各プログラムの役割について説明する。
【００４９】
コンテンツ配信装置１００ａが備えるＣＰＵ１１０は、上記プログラムの他、資源スヌーププログラム１４２ａおよび予測連携プログラム１４５ａを実行する。資源スヌーププログラム１４２ａは、代理配信プログラム１４１ａが内部的に保持する配信制御パラメータ等を取得し、後述の図１０で説明する資源情報テーブル１２１に格納する。予測連携プログラム１４５ａは、資源情報テーブル１２１が保持している情報を読み取り、その内容に基づきコンテンツ配信装置１００ｂがあらかじめ実行しておくべき準備処理の内容を確定し、その準備処理を実行しておくようコンテンツ配信装置１００ｂに指示する。
【００５０】
コンテンツ配信装置１００ｂが備えるＣＰＵ１１０は、上記プログラムの他、準備処理プログラム１４３ｂおよび予測連携プログラム１４５ｂを実行する。予測連携プログラム１４５ｂは、予測連携プログラム１４５ａから上述の準備処理指示を受け取り、準備処理プログラム１４３ｂに通知する。準備処理プログラム１４３ｂは、上述の準備処理指示にしたがって準備処理を実行する。
【００５１】
予測連携プログラム１４５ａと予測連携プログラム１４５ｂの間の通信は、例えば共有メモリ、Ｐ２Ｐ（Ｐｅｅｒ  Ｔｏ  Ｐｅｅｒ）、ブロードキャスト通信、マルチキャスト通信などの手法によって実施することができる。
【００５２】
図９は、コンテンツ配信装置１００から負荷分散装置２００に対して稼働状況を通知する際の各プログラムの役割を説明する図である。以下、各プログラムの役割について説明する。
【００５３】
コンテンツ配信装置１００が備えるＣＰＵ１１０は、上記プログラムの他、障害監視プログラム１４４を実行する。障害監視プログラム１４４は、代理配信プログラム１４１の稼働状況、例えば稼働中／停止中、配信パフォーマンスなどを監視する。予測連携プログラム１４５は、負荷分散装置２００の予測連携プログラム２４２に、代理配信プログラム１４１の稼働状況を通知する。
【００５４】
負荷分散装置２００が備えるＣＰＵは、上記プログラムの他、予測連携プログラム２４２を実行する。予測連携プログラム２４２は、コンテンツ配信装置１００の予測連携プログラム１４５より代理配信プログラム１４１の稼働状況通知を受け取り、アクセス分散プログラム２４１へ通知する。アクセス分散プログラム２４１は、代理配信プログラム１４１の稼働状況を、後述の図１１で説明する稼働状況テーブル２２１に反映する。アクセス分散プログラム２４１は、稼働状況テーブル２２１の内容にしたがって、いずれのコンテンツ配信装置１００にコンテンツ配信リクエストを振り分けるかを定める。
【００５５】
本発明における「配信部」は、代理配信プログラム１４１が相当する。「連携部」は、予測連携プログラム１４５が相当する。「監視部」は、障害監視プログラム１４４が相当する。「準備処理部」は、準備処理プログラム１４３が相当する。これらの機能を、同等の機能を実現する回路デバイスなどのハードウェアによって構成することもできる。
【００５６】
図１０は、コンテンツ配信装置１００の記憶部１２０が格納する資源情報テーブル１２１の構成とデータ例を示す図である。図は例示であり、資源情報が記憶されていれば、その形式はテーブルに限定されない。他のテーブルについても同様である。資源情報テーブル１２１は、資源スヌーププログラム１４２が代理配信プログラム１４１の稼働状況を収集することによって作成される。各行のデータは、代理配信プログラム１４１が実行している処理の具体的な内容を示すデータを保持する。
【００５７】
資源情報テーブル１２１は、準備処理タイプ列１２１１、データ位置列１２１２、データ形式列１２１３、優先度列１２１４、優先度補助情報列１２１５、識別子列１２１６を有する。
【００５８】
準備処理タイプ列１２１１は、代理配信プログラム１４１が実行している処理の種類を示すデータを保持する。主に、代理配信プログラム１４１が処理するデータの種類が保持される。本列の値は、フェイルオーバが発生したときに待機系コンテンツ配信装置１００が実行すべき処理と対応しているので、待機系コンテンツ配信装置１００があらかじめ実行しておくべき準備処理の内容を表しているともいえる。
【００５９】
データ形式列１２１３とデータ位置列１２１２は、準備処理タイプ列１２１１の値で示されるデータのメモリ１４０上におけるデータ形式、およびメモリ１４０上の格納位置を示す値を保持する。
【００６０】
優先度列１２１４は、準備処理タイプ列１２１１の値で定まるデータタイプの優先度を示す値を保持する。ここでいうデータの優先度とは、コンテンツ配信装置１００がコンテンツ配信を行なうに際してそのデータが必要となる度合いを示す値である。優先度の程度はフェイルオーバ発生時に待機系コンテンツ配信装置１００がコンテンツ配信を行う際にも同様であるため、本列の値は準備処理の優先度を表しているということもできる。図１０の例では、値が大きいほどフェイルオーバ時に当該データ等が必要となる可能性が高いものとした。
【００６１】
優先度補助情報列１２１５は、優先度列１２１４の値を補足する値を保持する。優先度列の値は、準備処理タイプ列１２１１の値、すなわちデータタイプに応じて固定的に定めるのに対し、本列は代理配信プログラム１４１の稼働状況に応じて変化する動的な優先度を算出するためのデータを提供する。本列の具体例は、各行のデータ例について説明するときに併せて説明する。
【００６２】
識別子列１２１６は、各行の具体内容を示す識別子を保持する。識別子の内容は、準備処理タイプ列１２１１の値によって異なる。準備処理タイプ列１２１１がファイルについてのものである場合、本列はそのファイル名（ファイルパスを含む）を示す。準備処理タイプ列１２１１が視聴端末４００に対して送信しているコンテンツデータ３２１の配信状況を示す場合、本列は視聴端末４００とコンテンツ配信装置１００の間の接続パラメータ、例えばポート番号を示す。
【００６３】
１行目の行データ１２２１は、代理配信プログラム１４１が配信しているファイルデータ（コンテンツデータ３２１）についての情報を保持する。コンテンツデータ３２１はファイル名で識別することができるので、識別子列１２１６には当該コンテンツデータ３２１のファイル名がセットされている。同じコンテンツデータ３２１に対する配信リクエストが増えるほどそのコンテンツデータ３２１の重要度は増すと考えられるので、優先度補助情報列１２１５の値は当該コンテンツデータ３２１の配信回数を保持するものとした。
【００６４】
２行目の行データ１２２２は、代理配信プログラム１４１が配信しているコンテンツデータ３２１のファイルシステムデータについての情報を保持する。ファイルシステムデータとは、当該コンテンツデータ３２１がオペレーティングシステム（ＯＳ）のファイルシステム上でどのように格納されているかを示す情報である。例えばファイル属性やファイルパスなどの情報がこれに相当する。行データ１２２１と同様の理由により、優先度補助情報列１２１５の値は当該コンテンツデータ３２１の配信回数を保持するものとした。
【００６５】
３行目の行データ１２２３は、代理配信プログラム１４１が配信しているコンテンツデータ３２１のファイル制御情報についての情報を保持する。ファイル制御情報とは、ファイルがオープン状態であるのか否か、といったファイルの状態そのものを示す情報のことである。行データ１２２１と同様の理由により、優先度補助情報列１２１５の値は当該コンテンツデータ３２１の配信回数を保持するものとした。
【００６６】
４行目の行データ１２２４は、未送信データについての情報を保持する。未送信データとは、代理配信プログラム１４１がオープンしたコンテンツデータ３２１のうち視聴端末４００に対して送信していないデータ部分のことである。コンテンツデータ３２１の画質が高い場合は転送すべきデータ量が多くなり、要求される配信性能が相対的に高くなるので、当該コンテンツデータ３２１の重要度は増すと考えられる。そこで優先度補助情報列１２１５の値は当該コンテンツデータ３２１の画質を保持するものとした。
【００６７】
５行目の行データ１２２５は、送信済データについての情報を保持する。送信済データとは、代理配信プログラム１４１がオープンしたコンテンツデータ３２１のうち視聴端末４００に対して送信し終えたデータ部分のことである。送信済データに関しては、再送頻度が高くなるほどそのコンテンツデータ３２１の重要度は増すと考えられる。したがって、優先度補助情報列１２１５の値は当該コンテンツデータ３２１の再送回数を保持するものとした。
【００６８】
６行目の行データ１２２６は、代理配信プログラム１４１が配信しているコンテンツデータ３２１の送受信制御情報についての情報を保持する。送受信制御情報とは、代理配信プログラム１４１がコンテンツデータ３２１をどこまで読込済みであり、そのうち送信済み部分はどこからどこまでか、などを示すファイルポインタについての情報である。これらの情報のサイズは小さく、データ転送継続の効果も大きいため、優先度列１２１４の値は高く設定されている。また、行データ１２２４と同様の理由により、優先度補助情報列１２１５の値は当該コンテンツデータ３２１の画質を保持するものとした。
【００６９】
７行目の行データ１２２７は、認証結果情報についての情報を保持する。認証結果情報とは、図４で示したステップ４０５でコンテンツ配信元装置３００から取得する認証結果に相当する。行データ１２２１と同様の理由により、優先度補助情報列１２１５の値は当該コンテンツデータ３２１の配信回数を保持するものとした。
【００７０】
図１０に示した資源情報テーブル１２１の列構成、行データ例、優先度列１２１４の値、優先度補助情報列１２１５の設定基準などは説明のための１例であり、他の構成を採用することもできる。
【００７１】
図１１は、負荷分散装置２００の記憶部が格納する稼働状況テーブル２２１の構成例を示す図である。稼働状況テーブル２２１は、アクセス分散プログラム２４１が代理配信プログラム１４１の稼働状況を収集することによって作成するデータテーブルであり、コンテンツ配信装置アドレス列２２１１、稼動状態列２２１２、配信中コンテンツ一覧列２２１３、配信準備済みコンテンツ一覧列２２１４、配信性能余力列２２１５を有する。
【００７２】
コンテンツ配信装置アドレス列２２１１は、個々のコンテンツ配信装置１００を識別することができるアドレスを保持する。稼動状態列２２１２は、当該コンテンツ配信装置１００の稼動状態を示す値を保持する。配信中コンテンツ一覧列２２１３は、当該コンテンツ配信装置１００が配信中であるコンテンツデータ３２１の識別子一覧を保持する。配信準備済みコンテンツ一覧列２２１４は、当該コンテンツ配信装置１００が配信中ではないが配信準備が完了しているコンテンツデータ３２１の識別子一覧を保持する。配信性能余力列２２１５は、当該コンテンツ配信装置１００のＣＰＵ利用率など、配信性能の余力を示すパラメータを保持する。
【００７３】
負荷分散装置２００が備えるアクセス分散プログラム２４１は、視聴端末４００からコンテンツ配信リクエストを受け取ると、そのコンテンツ名を取得し、配信準備済みコンテンツ一覧列２２１４内にそのコンテンツ名を保持している行データを検索する。アクセス分散プログラム２４１は、見つかった行データのうち、稼動状態列２２１２が「稼働中」を示しているコンテンツ配信装置１００を特定し、さらにその中で配信性能余力列２２１５の値が十分に大きいものを抽出する。アクセス分散プログラム２４１は、最終的に決定した行データのコンテンツ配信装置アドレス列２２１１の値を、コンテンツ配信リクエストに対する応答として視聴端末４００に返信する。
【００７４】
図１１に示した稼動状態テーブル２２１の列構成は説明のための１例であり、他の構成を採用することもできる。
【００７５】
以上のように、本実施の形態２によれば、コンテンツ配信装置１００が備える予測連携プログラム１４５は、代理配信プログラム１４１の稼働状況を記述した資源情報テーブル１２１から制御パラメータを読み取って待機系コンテンツ配信装置１００に通知する。待機系コンテンツ配信装置１００の準備処理プログラム１４３は、その制御パラメータにしたがって準備処理をあらかじめ実行しておく。これにより待機系コンテンツ配信装置１００は、稼動系コンテンツ配信装置１００の稼働状況を正確に反映して準備処理を実行することができるので、フェイルオーバ発生時にスムーズに処理を引き継ぐことができる。
【００７６】
＜実施の形態３＞
本発明の実施の形態３では、実施の形態２で説明した資源情報テーブル１２１が記述している制御パラメータのうち、行データ１２２２〜の１２２６の具体内容について説明する。各装置の構成は実施の形態２と同様である。
【００７７】
図１２は、記憶部３２０がコンテンツデータ３２１をどのように格納しているかを説明する図である。各コンテンツデータ３２１は、それぞれ独立したデータとして記憶部３２０に格納されている。記憶部３２０上には、各コンテンツデータ３２１を格納するディレクトリが構成されている。
【００７８】
例えば、ルートディレクトリ３２２１「／」の配下にサブディレクトリ３２２２「ｆｏｏ」が構成され、サブディレクトリ３２２２の配下にコンテンツデータ３２２３「ｂａｒ」が構成されている例を考える。以下、記憶部３２０からコンテンツデータ３２２３を読み出すときにどのような処理が発生するかを説明する。
【００７９】
記憶部３２０は、ディレクトリ構成、各ディレクトリおよびコンテンツデータ３２１が記憶部３２０上のどの位置に格納されているか、などを記述したファイルシステムデータ（メタデータともいう）３２３を、所定位置に格納している。
【００８０】
ファイルシステムデータ３２３はディレクトリ毎に設けられている。先頭のファイルシステムデータ３２３１は、ルートディレクトリ３２２１配下のディレクトリ、ファイル等についての情報を記述している。ファイルシステムデータ３２３２はサブディレクトリ３２２２配下のディレクトリ、ファイル等についての情報を記述している。ファイルシステムデータ３２３３はコンテンツデータ３２２３の位置等についての情報を記述している。
【００８１】
代理配信プログラム１４１は、ファイルシステムデータ３２３を読み取ってディレクトリ構成、ファイル構成を順次辿ることにより、コンテンツデータ３２１を読み取ることができる。
【００８２】
代理配信プログラム１４１は、ファイルシステムデータ３２３を一度読み込んでおけばキャッシュメモリ上にファイルシステムデータ３２３を展開して再利用することができるので、逐一ファイルシステムデータ３２３を読み込み直す必要はない。しかし、フェイルオーバ発生直後など、記憶部３２０に改めて最初からアクセスし直すときは、ファイルシステムデータ３２３を改めて読み込む必要がある。これが原因となり、待機系コンテンツ配信装置１００に処理を引き継ぐ際の応答性能が低下する懸念がある。
【００８３】
そこで資源スヌーププログラム１４２は、代理配信プログラム１４１が既に読み取ったファイルシステムデータ３２３を資源情報テーブル１２１に格納しておく。図１０の行データ１２２２にその１例を示した。予測連携プログラム１４５は、ファイルシステムデータ３２３についての情報を待機系コンテンツ配信装置１００に通知する。待機系コンテンツ配信装置１００の準備処理プログラム１４３は、その通知に基づきファイルシステムデータ３２３をあらかじめ読み取りキャッシュメモリに格納しておく。これにより、フェイルオーバ発生時に改めてファイルシステムデータ３２３を読み込み直す必要がなくなり、応答性能を向上させることができる。
【００８４】
図１３は、視聴端末４００とコンテンツ配信装置１００の間で通信を確立するシーケンスを説明する図である。視聴端末４００とコンテンツ配信装置１００は、３ｗａｙハンドシェイクと呼ばれる手順で通信を確立する。
【００８５】
ステップＳ１３０１において、視聴端末４００は、コンテンツ配信装置１００に対し接続要求を発行する。ステップＳ１３０２において、コンテンツ配信装置１００は、接続要求を受信した旨の確認応答を返信する。ステップＳ１３０３において、視聴端末４００は、その確認応答を受信した旨の応答を返信する。以上のステップにより、視聴端末４００とコンテンツ配信装置１００の間で相互に接続が確立する。
【００８６】
このように、３ｗａｙハンドシェイクを実行するためには、少なくとも通信路を１往復半するだけの時間が必要となる。以上の手順は、視聴端末４００とコンテンツ配信元装置３００の間で接続を確立場合も同様である。
【００８７】
なお、ステップＳ１３０１〜Ｓ１３０２では、コンテンツデータ３２１をどの程度のサイズに分割してどの程度の量連続して送出するか、などの配信条件に関する情報交換を、各装置の間で実行する。フェイルオーバの発生などによって上述の配信条件が喪失すると、改めて３ｗａｙハンドシェイクを実行する必要があり、そのための時間を要する。
【００８８】
図１４は、コンテンツデータ３２１の配信を継続するために必要な情報について説明する図である。以下、図１４について説明する。
【００８９】
コンテンツデータ３２１のうち代理配信プログラム１４１がメモリ１４０上に読み込んでいるデータは、以下の３つの部分に分けられる。
（データ部分３２１１）視聴端末４００に対して送信済みでかつ視聴端末４００から受信確認を受け取ったデータ部分
（データ部分３２１２）視聴端末４００に対して送信済みだが視聴端末４００から受信確認を受け取っていないデータ部分
（データ部分３２１３）視聴端末４００に対してまだ送信していないデータ部分
データ部分３２１２は、視聴端末４００に対してデータが届かなかった場合に再送する必要がある。データ部分３２１３は、以後のコンテンツ配信プロセスにおいて視聴端末４００に送信する必要がある。
【００９０】
待機系コンテンツ配信装置１００において、データ部分３２１３をあらかじめキャッシュメモリに読み込んでおけば、フェイルオーバ発生時にコンテンツデータ３２１の配信を継続できるか否かによらず、データ部分３２１３を改めて読み込む必要がなくなり、その分だけ応答性能の改善が期待できる。また、余裕があればデータ部分３２１２もあらかじめキャッシュメモリに読み込んでおけば、データ部分３２１２を再送する場合に改めて読み込み直す必要がなくなり、その分だけ応答性能の改善が期待できる。
【００９１】
以上の通り、視聴端末４００とコンテンツ配信装置１００の間でコンテンツデータ３２１を配信している状態について、待機系コンテンツ配信装置１００でもあらかじめ同様の状態を準備しておくことにより、フェイルオーバ発生時の応答性能を改善することができる。特に、フェイルオーバ発生時に３ｗａｙハンドシェイクを改めて実行しないようにするためには、以下のような情報を待機系コンテンツ配信装置１００に通知しておく必要がある。
【００９２】
（１）コネクションを識別するための情報
視聴端末４００とコンテンツ配信装置１００の間のコネクションは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）ポート番号によって識別することができる。したがって、ポート番号を待機系コンテンツ配信装置１００に通知しておく必要がある。図１０の行データ１２２４〜１２２６において、識別子列１２１６に各データのポート番号をセットした例を示した。
【００９３】
（２）ポインタ情報
図１４で説明したデータ部分３２１２の範囲を特定するため、データ部分３２１２の開始位置ポインタ３２１４（Ｐ１）と終了位置ポインタ３２１５（Ｐ２）を、待機系コンテンツ配信装置１００に通知しておく必要がある。開始位置ポインタ３２１４は、視聴端末４００から受信確認応答を受信済みのデータ部分３２１１の末尾位置を示す。終了位置ポインタ３２１５は、データ部分３２１２の末尾位置を示す。なお、送出方向とは別に受信方向についても同様のポインタを保持しなければならない。
【００９４】
（３）データサイズ
３ｗａｙハンドシェイクにおいて、配信条件に関する情報交換を各装置の間で実行することを、図１３で説明した。３ｗａｙハンドシェイクを再度実行しないようにするためには、この配信条件を待機系コンテンツ配信装置１００にあらかじめ通知しておく必要がある。具体的には、図１４に示すサイズ３２１６（Ｓ１）とサイズ３２１７（Ｓ２）を通知する必要がある。サイズ３２１６は、コンテンツ配信装置１００がコンテンツデータ３２１を送出する単位となるサイズである。サイズ３２１７は、視聴端末４００からの受信確認応答の到着を待たずに送出することができる最大データサイズである。なお、送出方向とは別に受信方向についても同様のサイズを保持しなければならない。
【００９５】
（３）データサイズ：補足
実際のデータ転送では、常にサイズ３２１７のサイズまでデータを送出できるわけではなく、ネットワークの混雑状況等によっては、送出可能なサイズが一時的に小さな値（サイズ３２１８）になる場合もある。余裕があれば、上記サイズ３２１８のような一時的な値も待機系コンテンツ配信装置１００に通知しておくと、データ転送を安定的に継続できるため望ましい。また、３ｗａｙハンドシェイク実行時には上述したサイズ以外にも拡張的なデータ転送方式を有効にするための補助情報が交換される場合があるため、それら情報も保持する必要がある。なお、送出方向とは別に受信方向についても同様の一時的な制御情報や補助情報を保持する必要がある。
【００９６】
図１５は、図１２〜図１４で説明した情報がメモリ１４０上にどのように格納されているかを示す図である。以下、図１５について説明する。
【００９７】
メモリ１４０は、ページと呼ばれる単位に分割されて管理されている。あるデータがどこのページにあるのかを示すインデックス情報１４０１は、所定のページ上に存在する。また、記憶部３２０から読み込まれたファイルシステムデータ１４０２およびコンテンツデータ１４０３（図１２で説明した各データ）、データ転送に必要な制御パラメータ１４０４（図１３〜図１４で説明した各情報）など、全てのデータはページ上に保持されている。
【００９８】
コンテンツ配信装置１００は、インデックス情報１４０１を参照して目的とするページにアクセスすることにより、必要なデータを読み出すことができる。なお、インデックス情報１４０１は１つのページにまとまっているとは限らないので、必要に応じて複数のページを参照する必要がある。
【００９９】
予測連携プログラム１４５は、メモリ１４０上に展開されている上記各情報を読み出して、待機系コンテンツ配信装置１００に通知する。特にコンテンツデータ１４０３などについては、待機系コンテンツ配信装置１００にそのまま送信してキャッシュすることができる。したがって、待機系コンテンツ配信装置１００においてコンテンツデータ３２１を読み込む代わりに、メモリ１４０上の上記ページを待機系コンテンツ配信装置１００に転送するようにしてもよい。ただし、待機系コンテンツ配信装置１００上におけるインデックス情報１４０１は稼動系コンテンツ配信装置１００上におけるインデックス情報１４０１と異なる可能性があるので、適宜差分などを調整する必要がある。
【０１００】
以上のように、本実施の形態３では、コンテンツデータ３２１を配信する処理を行う際に用いる制御パラメータとして、コンテンツ配信装置１００と視聴端末４００との間の接続状態を示すコネクション情報を、待機系コンテンツ配信装置１００に通知する。これにより、フェイルオーバが発生したときでも、コネクションを確立するための３ｗａｙハンドシェイクを待機系コンテンツ配信装置１００と視聴端末４００の間で改めて実行する必要がなくなり、フェイルオーバに係る応答性能を改善することができる。
【０１０１】
また、本実施の形態３では、上記コネクション情報として、データ部分３２１２の開始位置ポインタ３２１４と終了位置ポインタ３２１５を、待機系コンテンツ配信装置１００にあらかじめ通知しておく。これにより、待機系コンテンツ配信装置１００は、再送する可能性があるデータ部分、以後のステップで配信する必要があるデータ部分、などを区別してあらかじめ読み込んでおくことができる。したがって、待機系コンテンツ装置１００の性能余力に応じて適切な準備処理を実行することができ、負荷配分の最適化の観点から好ましい。
【０１０２】
また、本実施の形態３では、記憶部３２０上のディレクトリ構成およびファイル構成を記述したファイルシステムデータ３２３を、待機系コンテンツ配信装置１００にあらかじめ通知しておく。ファイルシステムデータ３２３は、記憶部３２０からコンテンツデータ３２１を読み取る際に必ず読み込む必要があるので、これをあらかじめ読み込んでおくことにより、フェイルオーバ発生時のＣＰＵ利用率上昇を抑えることができる。
【０１０３】
＜実施の形態４＞
本発明の実施の形態４では、各装置の間で送受信されるリクエストなどの詳細フォーマットを説明する。各装置の構成は、実施の形態１〜３と同様である。
【０１０４】
図１６は、図４のステップＳ４０３で視聴端末４００がコンテンツ配信装置１００に対して送信するコンテンツ配信リクエスト４１０のデータ形式を示す図である。コンテンツ配信リクエスト４１０は、コンテンツ名４１１、アカウント名４１２、パスワード４１３、要求画質４１４を有する。
【０１０５】
コンテンツ名４１１は、視聴端末４００に配信するコンテンツを識別する名称である。アカウント名４１２とパスワード４１３は、ステップＳ４０４において認証処理が必要となる場合にコンテンツ配信元装置３００へ送信する認証情報である。要求画質４１４は、視聴端末４００に対してコンテンツデータ３２１を配信する際の画質を指定する。
【０１０６】
コンテンツ配信リクエスト４１０は、上記以外のパラメータを有していてもよい。また例えば認証処理を行う必要がない場合にアカウント名４１２とパスワード４１３を省略するなど、不要なパラメータを省略することもできる。
【０１０７】
図１７は、図４のステップＳ４０２で負荷分散装置２００が送信するアクセス先応答２５０のデータ形式を示す図である。アクセス先応答２５０は、応答２５１とアクセス先アドレス２５２を有する。
【０１０８】
応答２５１は、例えばコンテンツ配信システム１０が混雑してコンテンツ配信リクエストを受け付けられない場合などにおいて、視聴端末４００へエラーを通知するためのパラメータである。アクセス先アドレス２５２は、ステップＳ４０３で視聴端末４００がコンテンツ配信リクエストを送信すべきコンテンツ配信装置１００のアドレスを示す。アクセス分散プログラム２４１は、アクセス先アドレス２５２を個々のコンテンツ配信装置１００のアドレスに振り分けることにより、負荷分散を行うことができる。
【０１０９】
図１８は、図４のステップＳ４０５でコンテンツ配信元装置３００が送信する認証応答３５０のデータ形式を示す図である。認証応答３５０は、応答３５１と認証結果３５２を有する。
【０１１０】
応答３５１は、応答２５１と同様である。認証結果３５２は、認証に成功したことを電子的に証明するデータである。アカウント名４１２とパスワード４１３を省略する場合は認証結果３５２も必要ない。
【０１１１】
図１９は、図４のステップＳ４０７で視聴端末４００がコンテンツ配信装置１００に対して送信するコンテンツ配信リクエスト４２０のデータ形式を示す図である。コンテンツ配信リクエスト４２０は、コンテンツ配信リクエスト４１０とほぼ同様であるが、認証に成功したことを示す認証結果４２５を新たに有する点が異なる。認証処理を行わない場合は、認証結果４２５は必要ない。
【０１１２】
図２０は、図４のステップＳ４１０でコンテンツ配信装置１００が視聴端末４００に対して送信する配信応答１５０のデータ形式を示す図である。配信応答１５０は、応答１５１と配信画質１５２を有する。
【０１１３】
応答１５１は、応答２５１と同様である。配信画質１５２は、コンテンツデータ３２１を配信する際の画質を示す。
【０１１４】
図２１は、図６のステップＳ６０５で待機系コンテンツ配信装置１００に対して送信される準備処理要求１６０のデータ形式を示す図である。準備処理要求１６０は、要求先／要求元アドレス１６１、優先度１６２、準備処理タイプ１６３、データ１６４、識別子１６５を有する。
【０１１５】
要求先／要求元アドレス１６１は、準備処理要求１６０の送信元アドレスと送信先アドレスを示す。これにより、ブロードキャストや共有メモリのように、全ての装置宛に情報を送出するような方法で準備処理要求１６０を送出しても、正しい宛先に準備処理要求１６０を届けることができる。
【０１１６】
優先度１６２は、図１０で説明した資源情報テーブル１２１の優先度列１２１４と優先度補助情報列１２１５の値に相当する。これらの列の値をそのまま格納してもよいし、これらの列の値を元に算出した総合優先度の値を格納してもよい。
【０１１７】
優先度１６２は、準備処理要求１６０の実行優先度を示す。準備処理要求１６０が複数の送信元から複数種類同時に送出された場合など、準備処理に必要な処理能力が待機系コンテンツ配信装置１００の処理能力を上回ったとき、優先度１６２が高い準備処理要求１６０から順に実行することができる。優先度１６２が高いとは、言い換えれば、フェイルオーバが発生すると待機系コンテンツ配信装置１００で実行しなければならなくなる可能性が高いと予想される、ということである。
【０１１８】
準備処理タイプ１６３、識別子１６５は、それぞれ図１０で説明した資源情報テーブル１２１の準備処理タイプ列１２１１、識別子列１２１６の値に相当する。
【０１１９】
データ１６４は、準備処理タイプ１６３の値によって内容が異なる。例えば準備処理タイプ１６３がファイルシステムデータ３２３を示す値である場合、データ１６４はファイルシステムデータ３２３そのものを保持する。
【０１２０】
待機系コンテンツ配信装置１００は、例えばデータ１６４をメモリ１４０上の空きページに配置し、インデックス情報１４０１を更新してキャッシュとして登録する。あるいは、データ１６４に記憶部１２０上のブロックアドレスのみが含まれている場合には、データ１６４を記憶部１２０から読み込み、同様にメモリ１４０上の空きページに配置してキャッシュとして登録する。
【０１２１】
以上、本実施の形態４では、各装置の間で送受信されるリクエストなどの詳細フォーマットを説明した。
【０１２２】
＜実施の形態５＞
本発明の実施の形態５では、コンテンツ配信装置１００が備える予測連携プログラム１４５の詳細動作を説明する。各装置の構成は、実施の形態１〜４と同様である。
【０１２３】
図２２は、稼動系コンテンツ配信装置１００が備える予測連携プログラム１４５の動作フロー図である。以下、図２２の各ステップについて説明する。
（図２２：ステップＳ２２００）
コンテンツ配信装置１００の電源がＯＮになると、ＣＰＵ１１０は予測連携プログラム１４５の実行を開始する。
（図２２：ステップＳ２２０１）
予測連携プログラム１４５は、資源情報テーブル１２１より、代理配信プログラム１４１の稼働状況を取得する。
【０１２４】
（図２２：ステップＳ２２０２）
予測連携プログラム１４５は、優先度１６２を算出する。例えば、資源情報テーブル１２１の優先度列１２１４に優先度補助情報１２１５の値を重み付けして加算し、最終的な優先度１６２の値とする。
（図２２：ステップＳ２２０３〜Ｓ２２０５）
予測連携プログラム１４５は、準備処理要求１６０を作成し（Ｓ２２０３）、待機系コンテンツ配信装置１００に送信する（Ｓ２２０４）。予測連携プログラム１４５は、資源情報テーブル１２１内の全ての行データについてステップＳ２２０３〜Ｓ２２０４を繰り返す（Ｓ２２０５）。
【０１２５】
（図２２：ステップＳ２２０６）
予測連携プログラム１４５は、障害監視プログラム１４４の監視結果に基づき、コンテンツ配信装置１００に障害が発生しているか否かを判定する。障害が発生していればステップＳ２２０８へ進み、発生していなければステップＳ２２０７へ進む。
（図２２：ステップＳ２２０７）
予測連携プログラム１４５は、所定時間間隔毎に次のステップＳ２２０８を実行するため、本ステップにおいてその所定時間間隔が経過したか否かをチェックする。経過していればステップＳ２２０８へ進み、経過していなければステップＳ２２０８へ進む。
【０１２６】
（図２２：ステップＳ２２０８）
予測連携プログラム１４５は、待機系コンテンツ配信装置１００および負荷分散装置２００へ、コンテンツ配信装置１００（特に代理配信プログラム１４１）の稼動状態を通知する。この通知は、ハートビートとも呼ばれる。
（図２２：ステップＳ２２０９）
予測連携プログラム１４５は、動作を継続する場合はステップＳ２２０１へ戻って同様の処理を繰り返し、終了する場合は本動作フローを終了する。
【０１２７】
図２３は、待機系コンテンツ配信装置１００が備える予測連携プログラム１４５の動作フロー図である。以下、図２３の各ステップについて説明する。なお、コンテンツ配信装置１００が稼動系であるか待機系であるかについては、例えば稼動状態を示すフラグ情報を記憶部１２０内に格納しておくなどにより判定することができる。
（図２３：ステップＳ２２００）
コンテンツ配信装置１００の電源がＯＮになると、ＣＰＵ１１０は予測連携プログラム１４５の実行を開始する。
（図２３：ステップＳ２３０１）
予測連携プログラム１４５は、準備処理要求１６０を受信したか否かを確認する。受信していればステップＳ２３０５へ進み、受信していなければステップＳ２３０２へ進む。なお、準備処理要求１６０をまとめて処理するため、準備処理要求１６０を所定個数受信するまではステップＳ２３０２へ進み、準備処理要求１６０を所定個数受信した時点で初めてステップＳ２３０５へ進むようにしてもよい。
【０１２８】
（図２３：ステップＳ２３０２）
予測連携プログラム１４５は、稼動系コンテンツ配信装置１００より障害が発生した旨の稼働状況通知を受信した場合は、ステップＳ２３０４へ進む。それ以外の場合はステップＳ２３０３へ進む。
（図２３：ステップＳ２３０３）
予測連携プログラム１４５は、稼動系コンテンツ配信装置１００より、稼働状況の通知が所定時間以上途切れているか否かを判定する。所定時間以上途切れていればステップＳ２３０４へ進み、それ以外であればステップＳ２３０１へ戻って同様の処理を繰り返す。
【０１２９】
（図２３：ステップＳ２３０４）
予測連携プログラム１４５は、稼動系コンテンツ配信装置１００に障害が発生しているものとみなし、自ら稼動系コンテンツ配信装置１００となるべく、稼動状態に移行する。
（図２３：ステップＳ２３０４：補足）
ステップＳ２３０２において、稼動系コンテンツ配信装置１００より障害が発生した旨の稼働状況通知を受信した場合は、稼動系コンテンツ配信装置１００に障害が発生したことは明らかである。一方ステップＳ２３０３において、稼動系コンテンツ配信装置１００より稼働状況の通知が所定時間以上途切れている場合は、稼動系コンテンツ配信装置１００がダウンしていると考えられる。この場合もやはり、稼動系コンテンツ配信装置１００に障害が発生していると考えることができる。
（図２３：ステップＳ２３０５）
予測連携プログラム１４５は、これまで受信した準備処理要求１６０を優先度が高い順にソートする。
【０１３０】
（図２３：ステップＳ２３０６）
予測連携プログラム１４５は、準備処理要求１６０が指示する準備処理を実行することができるか否かを、ＣＰＵ利用率などのリソース空き状況に鑑みて判断する。実行可能であればステップＳ２３０７へ進み、実行できなければステップＳ２３０９へ進む。
（図２３：ステップＳ２３０７〜Ｓ２３０８）
予測連携プログラム１４５は、準備処理要求１６０が指示する準備処理を、ステップＳ２３０５でソートした順に実行する。全ての準備処理を実行し終えた後は、ステップＳ２３０１へ戻って同様の処理を繰り返す。
【０１３１】
（図２３：ステップＳ２３０９）
予測連携プログラム１４５は、準備処理要求１６０が指示する準備処理の優先度が所定優先度以上の高い優先度であるか否かを判定する。所定優先度以上であればステップＳ２３１０へ進み、それ以外であればステップＳ２３０１へ戻って同様の処理を繰り返す。
（図２３：ステップＳ２３１０）
予測連携プログラム１４５は、待機系コンテンツ配信装置１００の処理能力が不足している旨を報知する。報知手段としては、管理者へメールを送信する、ブザー、警告ランプなどを点灯させる、などの手法が考えられる。その他、警告を契機として新たな待機系コンテンツ配信装置１００を自動追加するなどの措置をとってもよい。
【０１３２】
以上、予測連携プログラム１４５の動作について説明した。次に、準備処理プログラム１４３の動作を説明する。
【０１３３】
準備処理実行プログラム１４３は、資源スヌーププログラム１４２がページのインデックス情報１４０１を手がかりにメモリ１４０上からデータを集める手順と逆の手順で、インデックス情報１４０１を手がかりにメモリ１４０上のデータを更新し、あるいは、空ページにデータを書き込み、当該ページが利用できるようにインデックス情報１４０１を更新する。データ１６４については、準備処理要求１６０に含まれるデータ１６４の内容をそのまま用いることもできるし、データ１６４によって指定された記憶部３２０上のデータを読み込む、稼動系コンテンツ配信装置１００のメモリ１４０上にあるデータを予測連携プログラム１４５が提供する情報共有機能を介して取得する、などの手法で処理することもできる。
【０１３４】
なお、全く同じ準備処理が重なった場合には、準備処理プログラム１４３は先に受け取った処理のみを実行し、重複した準備処理を実行しない。また、未使用メモリ領域がなくなった場合には、準備処理を実行してから最も時間が経過しているメモリ領域から順に当該メモリ領域を使用している準備処理をキャンセルして、新たな準備処理を実行する。
以上、本実施の形態５では、予測連携プログラム１４５の動作について説明した。
【０１３５】
以上のように、本実施の形態５によれば、予測連携プログラム１４５は、待機系コンテンツ配信装置１００が準備処理を実行できないときはその旨を報知する。これにより、フェイルオーバが発生する前の時点で、システム管理者が待機系コンテンツ配信装置１００のリソースを増強するなどの適切な措置を講じることができる。
【０１３６】
＜実施の形態６＞
図２４は、本発明の実施の形態６に係るコンテンツ配信システム１０の構成図である。本実施の形態６に係るコンテンツ配信システム１０において、各装置は、ＯＳ領域とハイパバイザ領域を有する。例えば負荷分散装置２００は、ＯＳ領域２０００とハイパバイザ領域２００１を有する。ハイパバイザ領域の配下には、障害監視プログラムと予測連携プログラムが配置される。ＯＳ領域の配下には、その他のプログラムが配置される。この領域構成は、他装置においても同様である。その他の構成は、実施の形態１〜５と同様である。
【０１３７】
ＯＳは、上述のプログラムとハードウェアの間に介在し、単一のＣＰＵ上で複数のプログラムを並行に実行するなどの役割を担う。ハイパバイザは、ＯＳとハードウェアの間に介在する基本ソフトウェアである。ハイパバイザは、ＯＳに対して仮想的なハードウェアを提示することにより、１つのハードウェア上で複数のＯＳを並行的に実行する機能を有する。
【０１３８】
各ＯＳはハイパバイザの配下で動作するので、各ＯＳがダウンしたとしても、ハイパバイザは動作を継続することができる。ハイパバイザの配下に障害監視プログラムと予測連携プログラムを配置することにより、以下のような効果を発揮することができる。
（効果１：ハートビートに依存しない）
実施の形態１〜５では、稼動系コンテンツ配信装置１００がダウンすると、ダウンした側からその旨を通知することはできないので、待機系コンテンツ配信装置１００が定期的に稼動系コンテンツ配信装置１００の稼働状況を確認しなければならない。そのための手段として、図２２のステップＳ２２０８で説明したハートビートを用いることとした。一方、ハイパバイザ配下に障害監視プログラム１４４と予測連携プログラム１４５を配置しておけば、稼動系コンテンツ配信装置１００のＯＳがダウンしてもハイパバイザは稼動し続けるので、ダウンした側からその旨を通知することができる。したがって、実施の形態１〜５では稼動系コンテンツ配信装置１００がダウンしてから待機系コンテンツ配信装置１００がその旨を検出するまで、最大でハートビート間隔のタイムラグが生じるが、本実施形態６ではそのようなタイムラグは生じない。
【０１３９】
（効果２：ハートビート間隔の共通化）
実施の形態１〜５では、各コンテンツ配信装置が異なるＯＳを用いている場合、ハートビート間隔がコンテンツ配信装置毎に異なる可能性がある。例えば、リアルタイムＯＳを用いているコンテンツ配信装置１００については、ほぼ規定通りの間隔でハートビートを実行すると想定されるが、動作時間について保証のない一般的なＯＳを用いているコンテンツ配信装置１００については、負荷状況などによってハートビート間隔にバラつきが生じる可能性がある。この場合、各コンテンツ配信装置１００の動作は、最も長いハートビート間隔に合わせる必要がある。一方、本実施形態６では、ハイパバイザはＯＳの種類によらず共通化することができるので、各コンテンツ配信装置１００は共通のハートビート間隔を用いることができる。これにより、最も長いハートビート間隔に合わせる必要がなくなるので、結果としてハートビート間隔を短くし、障害発生時に速やかにフェイルオーバを開始することができる。
【０１４０】
（効果３：準備処理の実行タイミング）
実施の形態１〜５では、稼動系コンテンツ配信装置１００がダウンすると、ファイルシステムデータ３２３などのデータを稼動系コンテンツ配信装置１００に転送することができなくなる。そのため実施の形態１〜５では、あらかじめ準備処理としてこれらデータを待機系コンテンツ配信装置１００に通知しておくこととした。これに対し本実施の形態６では、ＯＳがダウンしてもハイパバイザは稼動し続けているので、稼動系コンテンツ配信装置１００のＯＳがダウンした後に上記データを待機系コンテンツ配信装置１００に転送し始めても支障はない。これにより、準備処理を実行開始すべきタイミングがより柔軟になり、実施の形態１〜５では間に合わない準備処理であっても本実施の形態６では間に合うようになるなど、応答性能を確保する観点から好適である。さらには、ステップＳ２２０４を実行するタイミングを、ステップＳ２２０６で実際に障害検出するまで遅らせて、準備処理自体の量を削減することもできる。
【０１４１】
（効果４：ＯＳ依存部分の削減）
実施の形態１〜５では、ページのインデックス情報１４０１の場所や形式はＯＳ毎に異なるため、ＯＳ毎に専用の資源スヌーププログラム１４２や準備処理プログラム１４３を開発する必要がある。これに対し本実施形態６では、ハイパバイザがハードウェアを仮想化しているため、仮想化されたハードウェア上でページのインデックス情報１４０１を保持し、ページ内容を予測連携プログラム１４５により待機系コンテンツ配信装置１００に送出することができる。ハイパバイザ配下で一部のページ管理することにより、上記プログラムの開発工数を削減することができる。すなわち、資源スヌーププログラム１４２および準備処理プログラム１４３の一部機能をハイパバイザ配下にもち、各コンテンツ配信装置間で共通化することができる。
【０１４２】
（効果５：ハードウェア台数削減）
本実施形態６では、ハイパバイザ上で複数のＯＳを実行することができる。これにより比較的負荷の小さいアクセス分散プログラム２４１や配信プログラム３４１を同じハードウェア上で動作させるなど、ハードウェア台数の削減効果が期待できる。
（効果６：プログラムの共通化）
ハイパバイザ配下の予測連携プログラム１４５などのプログラムは、負荷分散装置２００やコンテンツ配信元装置３００など、どのハードウェア上でも利用できるようになる。そのため、たとえば複数の負荷分散装置２００あるいはコンテンツ配信元装置３００に関して、コンテンツ配信装置１００で行っているのと同様のフェイルオーバ手順を適用してシステム全体の信頼性を高めることができる。
【０１４３】
＜実施の形態７＞
以上の実施の形態１〜６において、待機系コンテンツ配信装置１００が複数存在する場合、稼動系コンテンツ配信装置１００がいずれの待機系コンテンツ配信装置１００に準備処理を指示すべきかについては、以下のように定めることができる。
（例１：固定的に定める）
稼動系コンテンツ配信装置１００は、いずれの待機系コンテンツ配信装置１００に準備処理を指示するかを記述したリストをあらかじめ保持しておき、これにしたがって規定の待機系コンテンツ配信装置１００に準備処理を指示する。
（例２：負荷分散装置２００に問い合わせる）
待機系コンテンツ配信装置１００から負荷分散装置２００に対し、稼働状況を定期的に通知し、負荷分散装置２００は稼働状況テーブル２２１にその内容を反映しておく。稼動系コンテンツ配信装置１００は、いずれの待機系コンテンツ配信装置１００に準備処理を指示すべきかを、負荷分散装置２００に問い合わせる。負荷分散装置２００は、ＣＰＵ利用率などのリソースに十分空きがある待機系コンテンツ配信装置１００のアドレスを返信する。
【０１４４】
＜実施の形態８＞
図２５は、本発明の実施の形態８に係るコンテンツ配信システム１０の構成図である。
実施の形態１〜７は、図２５のように、ストレージ装置６００内に配信プログラム３４１と記憶部３２０を備える構成であってもよい。
【０１４５】
ストレージ装置６００は、ＣＰＵ６１０、Ｉ／Ｆ６２０、メモリ６３０、記憶部３２０を備える。配信プログラム３４１は、メモリ６３０に格納され、ＣＰＵ６１０によって実行される。ＣＰＵ６１０、Ｉ／Ｆ６２０、メモリ６３０、記憶部３２０は、それぞれ複数あってもよい。また、記憶部３２０は、複数の記憶装置からなるＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙ  ｏｆ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｄｉｓｋｓ）構成であってもよい。さらに、外部にストレージ装置が接続される構成であってもよい。コンテンツ３２１は、Ｉ／Ｆ６２０を通じて、コンテンツ配信装置１００に送信される。
【０１４６】
本実施の形態では、資源情報テーブル１２１は、メモリ６３０に格納される。
ストレージ装置６００が実行する処理は、コンテンツ配信元装置３００による処理と同様であるため、説明を省略する。
【０１４７】
＜実施の形態９＞
図２６は、本発明の実施の形態９に係るコンテンツ配信システム１０の構成図である。
実施の形態１〜７は、図２６のように、ストレージ装置６００が、コンテンツ配信装置１００の機能を備えることで実現されてもよい。つまり、ストレージ装置６００のメモリ６３０は、代理配信プログラム１４１、資源スヌーププログラム１４２、準備処理プログラム１４３、障害監視プログラム１４４、予測連携プログラム１４５、配信プログラム３４１、記憶部３２０を備える。
【０１４８】
ストレージ装置６００は、ＣＰＵ６１０、Ｉ／Ｆ６２０、メモリ６３０を有するコントローラを備えていてもよい。また、ストレージ装置６００は、コントローラを複数備えていてもよい。この場合、各コントローラが代理配信プログラム１４１、資源スヌーププログラム１４２、準備処理プログラム１４３、障害監視プログラム１４４、予測連携プログラム１４５、配信プログラム３４１を備える。
【０１４９】
本実施の形態では、資源情報テーブル１２１は、メモリ６３０に格納される。
ストレージ装置６００が実行する処理は、コンテンツ配信装置１００及び、コンテンツ配信元装置３００による処理と同様であるため、説明を省略する。
【符号の説明】
【０１５０】
１０：コンテンツ配信システム、１００：コンテンツ配信装置、１１０：ＣＰＵ、１２０：記憶部、１２１：資源情報テーブル、１２１１：準備処理タイプ列、１２１２：データ位置列、１２１３：データ形式列、１２１４：優先度列、１２１５：優先度補助情報列、１２１６：識別子列、１３０：ネットワークＩ／Ｆ、１４０：メモリ、１４１：代理配信プログラム、１４２：資源スヌーププログラム、１４３：準備処理プログラム、１４４：障害監視プログラム、１４５：予測連携プログラム、１５０：配信応答、１５１：応答、１５２：配信画質、１６０：準備処理要求、１６１：要求先／要求元アドレス、１６２：優先度、１６３：準備処理タイプ、１６４：データ、１６５：識別子、２００：負荷分散装置、２２１：稼働状況テーブル、２２１１：コンテンツ配信装置アドレス列、２２１２：稼動状態列、２２１３：配信中コンテンツ一覧列、２２１４：配信準備済みコンテンツ一覧列、２２１５：配信性能余力列、２４１：アクセス分散プログラム、２４２：予測連携プログラム、２５０：アクセス先応答、２５１：応答、２５２：アクセス先アドレス、３００：コンテンツ配信元装置、３２０：記憶部、３２１：コンテンツデータ、３２３：ファイルシステムデータ、３４１：配信プログラム、３５０：認証応答、３５１：応答、３５２：認証結果、４００：視聴端末、４１０：コンテンツ配信リクエスト、４１１：コンテンツ名、４１２：アカウント名、４１３：パスワード、４１３：要求画質、４２０：コンテンツ配信リクエスト、４２５：認証結果、５０１〜５０２：ネットワーク、１４０１：インデックス情報、２０００：ＯＳ領域、２００１：ハイパバイザ領域。
【図１】
2011186772.tif 000003
【図２】
2011186772.tif 000004
【図３】
2011186772.tif 000005
【図４】
2011186772.tif 000006
【図５】
2011186772.tif 000007
【図６】
2011186772.tif 000008
【図７】
2011186772.tif 000009
【図８】
2011186772.tif 000010
【図９】
2011186772.tif 000011
【図１０】
2011186772.tif 000012
【図１１】
2011186772.tif 000013
【図１２】
2011186772.tif 000014
【図１３】
2011186772.tif 000015
【図１４】
2011186772.tif 000016
【図１５】
2011186772.tif 000017
【図１６】
2011186772.tif 000018
【図１７】
2011186772.tif 000019
【図１８】
2011186772.tif 000020
【図１９】
2011186772.tif 000021
【図２０】
2011186772.tif 000022
【図２１】
2011186772.tif 000023
【図２２】
2011186772.tif 000024
【図２３】
2011186772.tif 000025
【図２４】
2011186772.tif 000026
【図２５】
2011186772.tif 000027
【図２６】
2011186772.tif 000028