(57)【要約】【課題】体感品質に影響を与える可能性が小さくなるサーバことを選択可能とすること。【解決手段】サーバ選択装置は、クライアントに対するコンテンツの配信候補である複数のサーバのそれぞれに関して行われた通信ごとに、通信環境を示す通信環境情報と、通信品質を示す品質情報とを取得する取得部と、前記取得部が取得した前記通信環境情報及び品質情報の履歴に基づいて、サーバ及び通信環境情報の組み合わせごとに、通信品質の確率的な劣化を反映したスコアを計算する計算部と、前記計算部が計算したスコアに基づいて、前記クライアントに対してコンテンツを配信するサーバを選択する選択部と、を有する。【選択図】図１
2019139317.tif 000002
【特許請求の範囲】
【請求項１】
クライアントに対するコンテンツの配信候補である複数のサーバのそれぞれに関して行われた通信ごとに、通信環境を示す通信環境情報と、通信品質を示す品質情報とを取得する取得部と、
前記取得部が取得した前記通信環境情報及び品質情報の履歴に基づいて、サーバ及び通信環境情報の組み合わせごとに、通信品質の確率的な劣化を反映したスコアを計算する計算部と、
前記計算部が計算したスコアに基づいて、前記クライアントに対してコンテンツを配信するサーバを選択する選択部と、
を有することを特徴とするサーバ選択装置。
【請求項２】
前記計算部は、サーバ及び通信環境情報の組み合わせごとに、当該組み合わせに係る前記品質情報が、閾値よりも悪くなる確率に基づいて前記スコアを計算する、
ことを特徴とする請求項１記載のサーバ選択装置。
【請求項３】
前記計算部は、サーバ及び通信環境情報の組み合わせごとに、当該組み合わせに係る前記通信のうち、前記品質情報が閾値よりも悪くなる通信の時間間隔に基づいて前記スコアを計算する、
ことを特徴とする請求項１記載のサーバ選択装置。
【請求項４】
前記取得部は、前記クライアントから、又は前記クライアントとは別の装置から前記品質情報を取得する、
ことを特徴とする請求項１乃至３いずれか一項記載のサーバ選択装置。
【請求項５】
クライアントに対するコンテンツの配信候補である複数のサーバのそれぞれに関して行われた通信ごとに、通信環境を示す通信環境情報と、通信品質を示す品質情報とを取得する取得手順と、
前記取得手順において取得された前記通信環境情報及び品質情報の履歴に基づいて、サーバ及び通信環境情報の組み合わせごとに、通信品質の確率的な劣化を反映したスコアを計算する計算手順と、
前記計算手順において計算されたスコアに基づいて、前記クライアントに対してコンテンツを配信するサーバを選択する選択手順と、
をコンピュータが実行することを特徴とするサーバ選択方法。
【請求項６】
請求項１乃至４いずれか一項記載の各部としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ選択装置、サーバ選択方法及びプログラムに関する。
【背景技術】
【０００２】
インターネットを介してＷｅｂ閲覧や動画閲覧などを行う際は、コンテンツ事業者が設置したサーバ、又はＣＤＮ（Content Delivery Network）からコンテンツをダウンロードする。その際、サーバへの集中アクセスやセキュリティアタックにより輻輳が発生すると、サーバの応答速度が落ちる、又は完全に応答しなくなってしまうことがある。このようなサービス品質の劣化はユーザの体感品質に大きな影響を与えてしまう可能性がある。
【０００３】
そのため、コンテンツを複数のサーバに設置することで、あるサーバの通信品質が劣化している際には、別のサーバからダウンロードすることのできる、マルチサーバ環境の導入が進んでいる。マルチサーバ環境における"サーバ"とは、ＣＤＮにおけるサーバのようにインターネットにおけるサーバのみならず、オンプレミスのサーバをも含む。
【０００４】
マルチサーバ選択ソリューションは、Ｃｏｎｖｉｖａ社及びＣｅｄｅｘｉｓ社が既に製品化している。Ｃｏｎｖｉｖａ社の提供するソリューションは、リアルタイムに提供される各ＣＤＮの品質情報に基づき、最もスループットの高いＣＤＮからコンテンツをダウンロードすることで、より通信品質の高いコンテンツ配信を実現する（非特許文献１）。Ｃｅｄｅｘｉｓ社の提供するＯｐｅｎｍｉｘは、スループット、コストといった指標を組み合わせ、選択ロジックをプログラムとして記述することで、ＣＤＮ選択アルゴリズムをユーザが自由に組み立てることができる（非特許文献２）。さらに、直近のスループットの比で確率的にＣＤＮを選択する方式も提案されている（非特許文献３）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】［online］、インターネット＜ＵＲＬ：https://www.cedexis.com/openmix/＞
【非特許文献２】Liu, Xi and Dobrian, Florin and Milner, Henry and Jiang, Junchen and Sekar, Vyas and Stoica, Ion and Zhang, Hui, A Case for a Coordinated Internet Video Control Plane, Proceedings of the ACM SIGCOMM 2012 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, SIGCOMM 2012
【非特許文献３】Wamser, Florian and Hofner, Steffen and Seufert, Michael and Tran-Gia, Phuoc, Server and Content Selection for MPEG DASH Video Streaming with Client Information, Proceedings of the Workshop on QoE-based Analysis and Management of Data Communication Networks, Internet QoE 2017
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記に示すように、マルチサーバ環境における選択アルゴリズムや、選択することのできる環境は整いつつある。しかし、これらの手法は、ＣＤＮの品質が確率的に低下するという可能性を考慮していないという課題がある。
【０００７】
例えば、サーバＡ及びサーバＢが存在し、サーバＡは１０回中９回は５０Ｍｂｐｓの速度が出るが、１０回中１回は１００ｋｂｐｓの速度しか出ないサーバであり、サーバＢは、１０回中１０回において３０Ｍｂｐｓの速度が出るサーバであるとする。この場合、サーバＡの平均スループットは４５．０１Ｍｂｐｓ、サーバＢの平均スループットは３０Ｍｂｐｓとなるため、既存の手法を適用すると、平均スループットの高いサーバＡが選択される。しかし、動画閲覧のようなストリーミング型の通信においては、ある程度のスループットが安定的に出ていれば、それ以上のスループットが出ていたとしても体感品質には影響を与えない。そのため、体感品質の観点からは、サーバＢを選ぶべきである。
【０００８】
本発明は、上記の点に鑑みてなされたものであって、体感品質に影響を与える可能性が小さくなるサーバことを選択可能とすることを目的とする。
【課題を解決するための手段】
【０００９】
そこで上記課題を解決するため、サーバ選択装置は、クライアントに対するコンテンツの配信候補である複数のサーバのそれぞれに関して行われた通信ごとに、通信環境を示す通信環境情報と、通信品質を示す品質情報とを取得する取得部と、前記取得部が取得した前記通信環境情報及び品質情報の履歴に基づいて、サーバ及び通信環境情報の組み合わせごとに、通信品質の確率的な劣化を反映したスコアを計算する計算部と、前記計算部が計算したスコアに基づいて、前記クライアントに対してコンテンツを配信するサーバを選択する選択部と、を有する。
【発明の効果】
【００１０】
体感品質に影響を与える可能性が小さくなるサーバことを選択可能とすることができる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施の形態におけるマルチサーバ環境システムの構成例を示す図である。
【図２】第１の実施の形態における計算装置のハードウェア構成例を示す図である。
【図３】第１の実施の形態におけるサーバ情報テーブルの構成例を示す図である。
【図４】第１の実施の形態におけるスコア情報テーブルの構成例を示す図である。
【図５】品質情報テーブルの構成例を示す図である。
【図６】品質ＤＢにおけるデータの持ち方を説明するための図である。
【図７】第２の実施の形態におけるサーバ情報テーブルの構成例を示す図である。
【図８】第２の実施の形態におけるスコア情報テーブルの構成例を示す図である。
【図９】第３の実施の形態におけるマルチサーバ環境システムの構成例を示す図である。
【図１０】プレイリストの書き換えの一例を示す図である。
【図１１】第４の実施の形態におけるマルチサーバ環境システムの構成例を示す図である。
【発明を実施するための形態】
【００１２】
以下、図面に基づいて本発明の実施の形態を説明する。以下においては、プローブの有無、振り分け方式、スコア計算アルゴリズムの任意の組み合わせに基づいて実施形態を分けて説明する。
【００１３】
プローブとは、定期的に各サーバに対してアクセスして、各サーバの通信品質を示す情報である品質情報を取得する装置をいう。プローブ有無とは、斯かるプローブを利用するか否かを意味する。
【００１４】
振り分け方式とは、クライアント装置から指定されたＵＲＬに対応するサーバを振り分ける方式をいい、本実施の形態では、「ＤＮＳ方式」、「ＨＴＴＰリダイレクト方式」、「プレイリスト方式」等の選択肢が有る。各選択肢の詳細については後述される。
【００１５】
スコア計算アルゴリズムとは、クライアント装置にアクセスさせるサーバを選択する際の指標として利用される「スコア」の計算アルゴリズムをいい、本実施の形態では、閾値法及び統計法の２つの選択肢が有る。
【００１６】
プローブの有無、振り分け方式、スコア計算アルゴリズムの組み合わせを、以下（プローブの有無、振り分け方式、スコア計算アルゴリズム）の形式で表記する。但し、当該組み合わせの各要素については、上記の方式名に加え、＊（ドントケア）を指定することもできる。第１〜第３の実施の形態では、（プローブ無し、＊、＊）の一例について説明する。第４の実施の形態では、（プローブ有り、＊、＊）について説明する。
【００１７】
なお、以下で説明する各実施の形態においては、クライアント装置が取得すべきコンテンツのＵＲＬは特定できている状況を想定する。取得すべきコンテンツのＵＲＬは、Ｗｅｂサイトの閲覧であれば、ユーザからの指定、又は読み込んだＷｅｂページのＪａｖａｓｃｒｉｐｔ（登録商標）から指定されることで特定することができる。また、動画閲覧であれば、プレイリストのＵＲＬ、又はプレイリストに記載されたチャンクのＵＲＬをパースすることで取得することができる。
【００１８】
図１は、第１の実施の形態におけるマルチサーバ環境システムの構成例を示す図である。第１の実施の形態では、（プローブ無し、ＤＮＳ方式、＊）の形態について説明する。図１において、マルチサーバ環境システムは、１以上のクライアント装置２０、サーバ群３０及びサーバ選択装置１０等を含む。クライアント装置２０は、サーバ群３０及びサーバ選択装置１０とインターネット等のネットワークを介して接続されている。
【００１９】
クライアント装置２０は、ユーザがＷｅｂコンテンツや動画コンテンツ等の閲覧に利用する端末である。例えば、ＰＣ（Personal Computer）、スマートフォン、タブレット端末等がクライアント装置２０として利用されてもよい。
【００２０】
サーバ群３０は、マルチサーバ環境における複数のサーバ３１（サーバ３１ａ〜３１ｃ）の集合である。各サーバ３１は、クライアント装置２０から要求されたコンテンツを配信する。なお、サーバ３１は、ＣＤＮにおけるサーバ３１のようにインターネットにおけるサーバ３１であってもよいし、オンプレミスのサーバ３１であってもよい。
【００２１】
サーバ選択装置１０は、サーバ群３０の中から、コンテンツの閲覧又は視聴に関する体感品質が確率的に低下する可能性が相対的に低いサーバ３１（すなわち、体感品質に影響を与える可能性が小さくなるサーバ３１）を選択する処理を実行する１以上のコンピュータである。サーバ選択装置１０は、クライアント装置２０と通信可能であれば、どこに配置されてもよい。例えば、サーバ選択装置１０は、クライアント装置２０が配置される企業内に配置されてもよいし、インターネット上に配置されてもよい。
【００２２】
図１において、サーバ選択装置１０は、スコア計算部１１、サーバ選択部１２及び品質ＤＢ１１１を有する。スコア計算部１１は、各サーバ３１のスコアの計算等を実行する。サーバ選択部１２は、スコアに基づいて、コンテンツの閲覧に関する体感品質が確率的に低下する可能性が相対的に低いサーバ３１を選択する。品質ＤＢ１１１は、クライアント装置２０が各サーバ３１からコンテンツをダウンロードするための通信の品質に関する情報を記憶するデータベースである。なお、サーバ選択装置１０の各構成要素に対応するコンピュータは、それぞれ異なっていてもよい。
【００２３】
図２は、第１の実施の形態におけるサーバ選択装置１０のハードウェア構成例を示す図である。図２のサーバ選択装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００２４】
サーバ選択装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００２５】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってサーバ選択装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００２６】
なお、図１におけるスコア計算部１１及びサーバ選択部１２は、サーバ選択装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。品質ＤＢ１１１は、例えば、補助記憶装置１０２、又はサーバ選択装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００２７】
以下、第１の実施の形態において実行される処理手順について図１を参照して説明する。
【００２８】
ステップＳ１）クライアント装置２０は、アクセスしたいＵＲＬ及びクライアントの通信環境を示す通信環境情報をサーバ選択部１２に対して送信する。
【００２９】
ステップＳ２）サーバ選択部１２は、品質ＤＢ１１１に予め記憶されているサーバ情報テーブルを参照して、クライアント装置２０から送信されたＵＲＬ（以下、「対象ＵＲＬ」という。）に対応するサーバ候補（クライアント装置２０へのコンテンツの配信候補）を抽出する。
【００３０】
図３は、第１の実施の形態におけるサーバ情報テーブルの構成例を示す図である。図３に示されるように、第１の実施の形態におけるサーバ情報テーブルには、ＵＲＬに対応付けてアクセス先ＩＰアドレスが記憶されている。ここで、ＵＲＬとアクセス先ＩＰアドレスとの関係は、一対多である。したがって、ステップＳ２では、複数のアクセス先ＩＰアドレスが、対象ＵＲＬに対応するサーバ候補のとして抽出される。このように、対象ＵＲＬに対応するサーバ候補をＩＰアドレスによって特定する「振り分け方式」を「ＤＮＳ方式」という。
【００３１】
例えば、対象ＵＲＬが「ｈｔｔｐ：／／ａａａ．ｃｏｍ」である場合、「１１．１１．１１．１１」、「２２．２２．２２．２２」、「３３．３３．３３．３３」がサーバ候補として抽出される。
【００３２】
ステップＳ３）サーバ選択部１２は、品質ＤＢ１１１に記憶されているスコア情報テーブルより、ステップＳ２において抽出された各サーバ候補のスコアのうち、クライアント装置２０の通信環境情報（以下、「クライアント通信環境情報」という。）と同様の通信環境情報に係るレコードを取得する。
【００３３】
図４は、第１の実施の形態におけるスコア情報テーブルの構成例を示す図である。図４に示されるように、スコア情報テーブルには、サーバ３１と通信環境情報との組み合わせごとに、当該組み合わせに関して算出されたスコアが記憶されている。
【００３４】
ここで、通信環境情報とは、通信環境を区別する（通信環境を示す）情報をいい、固定系回線については利用ＩＳＰ及びエリアによって構成される情報であり、移動系回線については、キャリア、セルＩＤ、基地局ＩＤ及び位置情報のうちの一部又は全部によって構成される情報である。図４のスコア情報テーブルでは、「要素１」から「要素３」の列が、通信環境報の構成要素に相当する。すなわち、固定系回線については、例えば、「要素１」、「要素２」に、利用ＩＳＰ、エリアが記憶されており、移動系回線については、「要素１」、「要素２」、「要素３」に、例えば、キャリア、セルＩＤ、基地局ＩＤが記憶されている。
【００３５】
また、サーバ選択部１２は、通信環境情報が同様であるか否かを次のようにして判断する。クライアント通信環境情報が、固定系回線の通信環境情報である場合、サーバ選択部１２は、スコア情報テーブルにおいて、ＩＳＰ及びエリアが、クライアント通信環境情報に一致するレコードを検索した後に、ＩＳＰがクライアント通信環境情報に一致するレコードを順に検索していき、最初にヒットした通信環境情報を、クライアント通信環境情報と同様の通信環境情報であるとする。クライアント通信環境情報が移動系回線の通信環境情報である場合、検索部は、キャリア、基地局ＩＤ、セルＩＤがクライアント通信環境情報に一致するレコードを検索した後に、キャリア、基地局ＩＤがクライアント通信環境情報に一致するレコード、キャリアがクライアント通信環境情報に一致するレコードを順に検索し、最初にヒットした通信環境情報を、クライアント通信環境情報と同様の通信環境情報であるとする。
【００３６】
したがって、例えば、サーバ候補が「１１．１１．１１．１１」、「２２．２２．２２．２２」、「３３．３３．３３．３３」であり、クライアント通信環境情報が、「ＣａｒｒｉｅｒＡ」、「ｅＮＢＡ」、「ＣｅｌｌＡ」であれば、図４において、項番１、５、９のレコードが取得される。
【００３７】
ステップＳ４）サーバ選択部１２は、取得したレコードの中で「スコア」の値が最大であるレコード（以下「対象レコード」という。）の「サーバ」の値（ＩＰアドレス）を取得する。すなわち、スコアが最大であるサーバ３１が選択される。なお、本実施の形態において、スコアが大きいほど、確率的に品質が劣化する可能性が低いことを意味する。
【００３８】
ステップＳ５）サーバ選択部１２は、取得したＩＰアドレスをクライアント装置２０に返信する。
【００３９】
ステップＳ６）クライアント装置２０は、サーバ選択装置１０から返信されたＩＰアドレスにアクセスする。その結果、ユーザは、コンテンツを閲覧することができる。
【００４０】
ステップＳ７）例えば、ユーザによるコンテンツの閲覧の完了後、クライアント装置２０は、品質ＤＢ１１１に対し、アクセス時刻、アクセス先ＩＰアドレス、アクセス先ＵＲＬ、クライアント通信環境情報、計測された遅延、スループット等の品質情報を送信する。品質ＤＢ１１１は、送信された品質情報を品質情報テーブルに記憶する。
【００４１】
図５は、品質情報テーブルの構成例を示す図である。図５に示されるように、品質情報テーブルには、クライアント装置２０によるいずれかのサーバ３１に対するアクセス（いずれかのサーバ３１からのコンテンツのダウンロード）ごとに、アクセス時刻、アクセス先ＩＰアドレス、アクセス先ＵＲＬ、通信環境情報（クライアント通信環境情報）、遅延及びスループット等の品質情報が記憶される。すなわち、品質情報テーブルには、クライアント装置２０によるいずれかのサーバ３１との通信について、通信環境情報及び品質情報等の履歴が記憶される。なお、図５においては省略されているが、品質情報には、遅延及びスループット以外の情報（例えば、ジッタ等）が含まれてもよい。
【００４２】
なお、クライアント装置２０が送信する通信環境情報は、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）、固定系回線で内容が異なる。これに合わせ、Ａｎｄｒｏｉｄ（登録商標）、ｉＯＳ（登録商標）、固定系回線に応じて、品質ＤＢ１１１の品質情報テーブルにおける通信環境情報を構成する要素１から要素３の持ち方を、図６のように変更してもよい。図６では、Ａｎｄｒｏｉｄ（登録商標）（図６における「Ａ」）は、サーバ３１、キャリア、基地局ＩＤ、セルＩＤの順に、ｉＯＳ（登録商標）（図６における「Ｉ」）は、サーバ３１、キャリア、位置情報の順に、固定系回線は、ＩＳＰ、エリアの順（要素３は値なし）にキーを設定してデータを持つ例が示されている。固定系回線のエリアは、ｇｅｏＩＰを用いて、ＩＰアドレスから変換して取得することができる。
【００４３】
また、上記では、全てのクライアント装置２０が、常に品質情報を品質ＤＢ１１１に対して送信する例を示しているが、全てのクライアント装置２０が常に品質情報を送信しなくてもよい。例えば、一部のクライアント装置２０のみが品質情報を送信するようにしてもよいし、全てのクライアント装置２０が品質情報を送信せず、何らかの方法で品質情報テーブル（図５）に蓄積された品質情報を用いてサーバ３１の選択を行う形態をとることも可能である。
【００４４】
続いて、品質情報テーブルを用いて、各サーバ３１の通信環境情報に応じたスコアの算出法について説明する。
【００４５】
本実施の形態において、スコア算出法には、閾値法、統計法の２種類があり、いずれかの方法が選択されてもよい。また、最大ウインドウサイズｗを定めておき、過去ｗ時間分のレコードのみが利用される。スコア算出の契機は任意であり、定期的（例えば１日おき）などとしてもよい。
【００４６】
閾値法とは、通信環境情報が合致する過去のスループット、遅延、ジッタ等の品質情報が、事前に設定された閾値Ｔｈを下回る頻度確率（すなわち、品質情報が閾値Ｔｈよりも悪くなる確率）の−１倍、又は閾値Ｔｈを下回った時間間隔の平均値を用いてスコアを定める方法である。例えば、品質情報テーブルの内容が図５に示す通りであり、スコア計算を開始した時刻が「２０１８．１．１  １４：００：００」、ｗ＝１、スループットに対する閾値Ｔｈ＝１０００であると仮定する。まず、スコア情報テーブル（図４）の項番１に相当する、サーバ３１が「１１．１１．１１．１１」、通信環境情報が「ＣａｒｒｉｅｒＡ、ｅＮＢＡ、ＣｅｌｌＡ」である条件（以下「対象条件」という。）に対するスコアを計算する例を示す。
【００４７】
この場合、スコア計算部１１は、品質情報テーブル（図５）において、スコア計算の開始時刻である「２０１８．１．１２０１８．１．１」より過去ｗ（ｗ＝１）時間分である１３：００：００以降のレコードのうち、通信環境情報が対象条件の通信環境情報の全てに一致する、項番２、３、４の３つのレコードを計算対象として抽出する。
【００４８】
続いて、スコア計算部１１は、当該３つのレコードのそれぞれのスループットをＴｈ＝１０００と比較することで、スループットがＴｈを下回ったレコードの数が２であり、スループットがＴｈ以上であるレコードの数が１であることを特定する。
【００４９】
続いて、スコア計算部１１は、スループットがＴｈを下回る頻度確率＝２÷３≒０．６６を計算し、当該頻度確率の−１倍である−０．６６を、サーバ３１「１１．１１．１１．１１」及び通信環境情報「ＣａｒｒｉｅｒＡ、ｅＮＢＡ、ＣｅｌｌＡ」のスコアとする。したがって、この場合、スコア計算部１１は、スコア情報テーブルにおいて対象条件に対応するレコードの「スコア」に、−０．６６を記憶する。なお、図４では、当該３つのレコードのアクセス時刻の時間間隔の平均値がスコアとされた例に相当する。
【００５０】
次に、スコア情報テーブル（図４）の項番３に相当する、サーバ３１が「１１．１１．１１．１１」、通信環境情報が「ＣａｒｒｉｅｒＡ、＊、＊」の条件（以下、「対象条件」という。）に対するスコアを計算する例を示す。
【００５１】
この場合、スコア計算部１１は、品質情報テーブル（図５）において、スコア計算の開始時刻である「２０１８．１．１  １４：００：００」より過去ｗ（ｗ＝１）時間分である１３：００：００以降のレコードのうち、通信環境情報の要素のうち、少なくとも「要素１（キャリア）」が「ＣａｒｒｉｅｒＡ」に一致する、項番２−９レコード群を計算対象として抽出する。
【００５２】
続いて、スコア計算部１１は、当該レコード群に含まれる各レコードについて、スループットをＴｈ＝１０００と比較することで、スループットがＴｈを下回ったレコードの数が４であり、スループットがＴｈ以上であるレコードの数が４であることを特定する。
【００５３】
続いて、スコア計算部１１は、スループットがＴｈを下回る頻度確率＝４÷８≒０．５を計算し、当該頻度確率の−１倍である−０．５を、サーバ３１「１１．１１．１１．１１」及び通信環境情報「ＣａｒｒｉｅｒＡ、＊、＊」のスコアとする。したがって、この場合、スコア計算部１１は、スコア情報テーブルにおいて対象条件に対応するレコードの「スコア」に、−０．６６を記憶する。
【００５４】
なお、スコア計算部１１は、スコア計算の各タイミングにおいて、スコア情報テーブル（図４）のその他の条件についても、同様にしてレコードの抽出及びスコア算出等を実行する。
【００５５】
一方、統計法とは、閾値法と同様にして抽出された、計算対象となるレコード群に対し、スコア計算部１１が、平均μ、分散σ、ａパーセンタイル（ａは０以上１００以下の実数）を計算し、μ−ｂσ（ｂは正の実数）の値、又はａパーセンタイル値をスコアとするものである。
【００５６】
このように、閾値法及び統計法のいずれについても、通信品質の確率的な劣化を反映したスコアの計算方法の一例である。
【００５７】
次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
【００５８】
第２の実施の形態では、（プローブ無し、ＨＴＴＰリダイレクト方式、＊）の形態について、図１を参照して説明する。
【００５９】
ステップＳ１）クライアント装置２０は、アクセスしたいＵＲＬ及びクライアント通信環境情報をサーバ選択部１２に対して送信する。
【００６０】
ステップＳ２）サーバ選択部１２は、品質ＤＢ１１１に予め記憶されているサーバ情報テーブルを参照して、クライアント装置２０から送信されたＵＲＬ（以下、「対象ＵＲＬ」という。）に対応するサーバ候補を抽出する。
【００６１】
図７は、第２の実施の形態におけるサーバ情報テーブルの構成例を示す図である。図４に示されるように、第２の実施の形態におけるサーバ情報テーブルには、ＵＲＬに対応付けてアクセス先ＵＲＬが記憶されている。ここで、ＵＲＬとアクセス先ＵＲＬとの関係は、一対多である。したがって、ステップＳ２では、複数のアクセス先ＵＲＬが、対象ＵＲＬに対応するサーバ候補として抽出される。このように、対象ＵＲＬに対応するサーバ候補をＵＲＬによって特定する「振り分け方式」を「ＨＴＴＰリダイレクト方式」という。
【００６２】
例えば、対象ＵＲＬが「ｈｔｔｐ：／／ａａａ．ｃｏｍ」である場合、「ｈｔｔｐ：／／ａａａ−１．ｃｏｍ」、「ｈｔｔｐ：／／ａａａ−２．ｃｏｍ」、「ｈｔｔｐ：／／ａａａ−３．ｃｏｍ」がサーバ候補として抽出される。
【００６３】
ステップＳ３）サーバ選択部１２は、品質ＤＢ１１１に記憶されているスコア情報テーブル（図４）より、ステップＳ２において抽出された各サーバ候補のスコアのうち、クライアント通信環境情報と同様の通信環境情報に係るレコードを取得する。
【００６４】
図８は、第２の実施の形態におけるスコア情報テーブルの構成例を示す図である。図８のスコア情報テーブルは、図４のスコア情報テーブルに対して、「サーバ」の値が、ＵＲＬによって表記されている点が異なる。
【００６５】
なお、通信環境情報が同様であるか否かの判定方法は、第１の実施の形態と同様である。したがって、サーバ候補がｈｔｔｐ：／／ａａａ−１．ｃｏｍ」、「ｈｔｔｐ：／／ａａａ−２．ｃｏｍ」、「ｈｔｔｐ：／／ａａａ−３．ｃｏｍ」であり、クライアント通信環境情報が、「ＣａｒｒｉｅｒＡ」、「ｅＮＢＡ」、「ＣｅｌｌＡ」であれば、図８において、項番１、５、９のレコードが取得される。
【００６６】
ステップＳ４）サーバ選択部１２は、取得したレコードの中で「スコア」の値が最大であるレコード（以下「対象レコード」という。）の「サーバ」の値（ＵＲＬ）を取得する。すなわち、スコアが最大であるサーバ３１が選択される。
【００６７】
ステップＳ５）サーバ選択部１２は、取得したＵＲＬをクライアント装置２０に返信する。
【００６８】
ステップＳ６）クライアント装置２０は、サーバ選択装置１０から返信されたＵＲＬにアクセスする。その結果、ユーザは、コンテンツを閲覧することができる。この際、クライアント装置２０は、アクセスしたＵＲＬのＩＰアドレスをアクセス先ＩＰアドレスとして取得しておく。なお、クライアント装置２０は、一般的なＤＮＳ（Domain Name System）を用いて、アクセスしたＵＲＬのＩＰアドレスを取得可能である。
【００６９】
ステップＳ７）例えば、ユーザによるコンテンツの閲覧の完了後、クライアント装置２０は、品質ＤＢ１１１に対し、アクセス時刻、アクセス先ＩＰアドレス、アクセス先ＵＲＬ、クライアント通信環境情報、計測された遅延、スループット等の品質情報を送信する。品質ＤＢ１１１は、送信された品質情報を品質情報テーブル（図５）に記憶する。
【００７０】
次に、第３の実施の形態について説明する。第３の実施の形態では第１又は第２の実施の形態と異なる点について説明する。第３の実施の形態において特に言及されない点については、第１又は第２の実施の形態と同様でもよい。第３の実施の形態では、（プローブ無し、プレイリスト方式、＊）の形態について説明する。振り分け方式としてプレイリスト方式が用いられるのは、クライアント装置２０において、ＨＬＳ方式、ＤＡＳＨ方式等の、ＡＢＲ（Adaptive Bitrate Streaming）型動画配信を採用しているアプリケーションが利用される場合に限られる。
【００７１】
図９は、第３の実施の形態におけるマルチサーバ環境システムの構成例を示す図である。図９中、図１と同一部分には同一符号を付し、その説明は省略する。
【００７２】
図９において、サーバ選択装置１０は、更に、プレイリスト生成部１３を有する。プレイリスト生成部１３は、サーバ選択装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。
【００７３】
以下、第３の実施の形態において実行される処理手順について図９を参照して説明する。
【００７４】
ステップＳ１）クライアント装置２０は、ユーザによって指定された動画プレイリストのＵＲＬとクライアント通信環境情報とをプレイリスト生成部１３に対して送信する。
【００７５】
ステップＳ２）プレイリスト生成部１３は、クライアント装置２０から受信したＵＲＬに係るプレイリストに含まれる各ＵＲＬについて、サーバ３１の選択をサーバ選択部１２に実行させる。すなわち、サーバ選択部１２は、当該各ＵＲＬについて、第１の実施の形態（プローブ無し、ＤＮＳ方式、＊）又は第２の実施の形態（プローブ無し、ＨＴＴＰリダイレクト、＊）のステップＳ２〜ステップＳ４を適用して、スコアが最大であるサーバ３１を選択する。プレイリスト生成部１３は、選択されたサーバ３１のＩＰアドレス又はＵＲＬへの書き換えをプレイリストについて実行する。
【００７６】
図１０は、プレイリストの書き換えの一例を示す図である。図１０には、ＨＬＳ（Http Live Streaming）方式を例として、書き換え前のプレイリストと書き換え後のプレイリストとの例が示されている。図１０では、書き換え前のプレイリストの各ＵＲＬが「ｈｏｇｅ．ｃｏｍからｆｕｇａ．ｃｏｍ」に書き換えられている。
【００７７】
ステップＳ３）プレイリスト生成部１３は、各ＵＲＬが書き換えられたプレイリストをクライアント装置２０へ返信する。
【００７８】
ステップＳ４）クライアント装置２０は、返信されたプレイリストに基づいて動画の再生を行う。
【００７９】
ステップＳ５）例えば、ユーザによる動画の閲覧の完了後、クライアント装置２０は、品質ＤＢ１１１に対し、アクセス時刻、アクセス先ＩＰアドレス、アクセス先ＵＲＬ、クライアント通信環境情報、計測された遅延、スループット等の品質情報を送信する。品質ＤＢ１１１は、送信された品質情報を品質情報テーブル（図５）に記憶する。
【００８０】
次に、第４の実施の形態について説明する。第４の実施の形態では第１、第２又は第３の実施の形態と異なる点について説明する。第４の実施の形態において特に言及されない点については、第１、第２又は第３の実施の形態と同様でもよい。第４の実施の形態では、（プローブ有り、＊、＊）の形態について説明する。
【００８１】
図１１は、第４の実施の形態におけるマルチサーバ環境システムの構成例を示す図である。図１１において、マルチサーバ環境システムは、プローブ４１の集合であるプローブ群４０を含む。プローブ群４０に含まれるプローブ４１ａ〜プローブ４１ｃ（それぞれを区別しない場合、「プローブ４１」という。）、サーバ群３０及びサーバ選択装置１０とネットワークを介して接続される。なお、図１１のサーバ選択装置１０について、スコア計算部１１、サーバ選択部１２及びプレイリスト生成部１３は、便宜上、省略されている。
【００８２】
第４の実施の形態では、プローブ無しの場合（第１〜第３の実施の形態）と比較して、品質ＤＢ１１１における品質情報テーブルの更新方法のみが異なる。各プローブ４１は、クライアント装置２０からの要求とは同期せず、定期的に各サーバ３１に対してアクセスし、各サーバ３１の品質情報を取得する。各プローブは、取得した品質情報をサーバ選択装置１０に送信する。サーバ選択装置１０は、受信した品質情報を品質情報テーブルに記憶する。第４の実施の形態では、品質情報がプローブ４１から取得されるため、必ずしもクライアント装置２０から品質情報を送付する必要がない。
【００８３】
上述したように、上記各実施の形態によれば、各サーバ３１に対する過去のアクセス時（通信時）の品質情報を用いて、急激に品質が劣化する確率がスコアとして算出される。クライアント装置２０からＵＲＬが指定された際には、当該ＵＲＬに対応するサーバ候補の中から、クライアント装置２０の通信環境と同様の通信環境におけるスコアが最大であるサーバ３１が、アクセス先として選択される。したがって、本実施の形態によれば、体感品質に影響を与える可能性が小さくなるサーバ３１（体感品質が大きく劣化する可能性を最小限に抑えることができるサーバ３１）を選択可能とすることができる。その結果、従来のサーバ選択方式を適用した場合と比較して、より体感品質の高い映像配信・Ｗｅｂ閲覧を実現することが可能となる。
【００８４】
なお、上記各実施の形態において、サーバ選択部１２及びプレイリスト生成部１３等は、取得部の一例である。スコア計算部１１は、計算部の一例である。サーバ選択部１２は、選択部の一例である。
【００８５】
以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００８６】
１０          サーバ選択装置
１１          スコア計算部
１２          サーバ選択部
１３          プレイリスト生成部
２０          クライアント装置
３０          サーバ群
３１          サーバ
４０          プローブ群
４１          プローブ
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１１１        品質ＤＢ
Ｂ            バス
【図１】
2019139317.tif 000003
【図２】
2019139317.tif 000004
【図３】
2019139317.tif 000005
【図４】
2019139317.tif 000006
【図５】
2019139317.tif 000007
【図６】
2019139317.tif 000008
【図７】
2019139317.tif 000009
【図８】
2019139317.tif 000010
【図９】
2019139317.tif 000011
【図１０】
2019139317.tif 000012
【図１１】
2019139317.tif 000013