リクエスト受付方法およびシステム
【課題】エンドサーバのサービス処理レートに基づいて各ユーザ端末からエンドサーバへのアクセスタイミングを制御するリクエスト受付方法およびシステムを提供する。
【解決手段】ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバAPSが、エンドサーバへのサービス要求を試行するサービス要求試行部１６と、試行したサービス要求の処理時間に基づいてエンドサーバの能力を計測するサーバ能力計測部１７と、アクセスパス要求を受信するアクセスパス要求受信部１１と、受信したアクセスパス要求ごとに、エンドサーバの能力に基づいてエンドサーバへのアクセスタイミングを決定するアクセスタイミング決定部１３と、アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成部１４と、アクセスパス応答をユーザ端末へ返信するアクセスパス応答返信部１５とを含む。
【解決手段】ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバAPSが、エンドサーバへのサービス要求を試行するサービス要求試行部１６と、試行したサービス要求の処理時間に基づいてエンドサーバの能力を計測するサーバ能力計測部１７と、アクセスパス要求を受信するアクセスパス要求受信部１１と、受信したアクセスパス要求ごとに、エンドサーバの能力に基づいてエンドサーバへのアクセスタイミングを決定するアクセスタイミング決定部１３と、アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成部１４と、アクセスパス応答をユーザ端末へ返信するアクセスパス応答返信部１５とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ端末から送信されたアクセスパス要求を予め受け付けて、各ユーザ端末からエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へアクセスパスとして返信するリクエスト受付方法およびシステムに関する。
【背景技術】
【０００２】
災害発生時の安否確認のためのリクエスト、あるいはTV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。これらの宛先でリクエストを受け付けるエンドサーバでは、リクエスト数が処理能力を超過すると、超過分についてはサービスの提供が不可能となる。これは同サービスを利用するユーザの満足度を低下させると共に、リクエストが有料コンテンツの配信であれば、コンテンツ提供者にとっては販売機会の損失となる。
【０００３】
イベントを契機とするアクセスの集中は通常のアクセス量を遙かに凌駕し、瞬間的には１０倍から１００倍に達する場合もある。したがって、アクセス集中時のピーク時に合わせてサーバ容量を設計してしまうと、時間的に大半を占める通常時には大幅な過剰設備状態を招いてしまう。しかも、このようなアクセス集中は予測が難しいので、たとえ十分と予測される設備を用意できたとしても、その容量を上回るアクセスが集中する可能性を否定できない。
【０００４】
一方、２００３年１２月に東京・大阪・名古屋で地上デジタル放送が開始され、それ以後、他の地域でも放送が順次開始されると共に、移動体受信端末向けサービスなどが拡充されることになっている。地上デジタル放送で提供される通信放送連携サービスでは、番組内容を契機とした同時大量アクセスの発生が予見されており、上記で指摘した事象が今後ますます顕在化してくることが想定される。
【０００５】
特許文献１には、アクセス集中により受付拒否されたリクエストメッセージの再アクセスを、新たなアクセス集中を生じさせることなく公平に受け付けて処理できるシステムが開示されている。
【０００６】
ここでは、サービスを提供するエンドサーバに多数のアクセスが集中すると、受け付けられないユーザに対して、現在混んでいる旨と、次回優先接続される時間帯が提示される。同ユーザが改めて優先接続時間帯にアクセスしてきた場合、このリクエストメッセージは他のリクエストメッセージよりも優先的に受け付けられる。
【０００７】
しかしながら、特許文献１では一のユーザがリクエストメッセージを送信した際に受付側の負荷が大きいと受付を後回しにされる一方、その直後に他の一のユーザがリクエストメッセージを送信した際に受付側の負荷が解消していると、当該他の一のユーザのリクエストメッセージが先に受け付けられてしまうので、受付が公平に行われないという技術課題があった。
【０００８】
このような技術課題に対して、本発明の発明者等は特許文献２および非特許文献１において、ユーザにサービスを提供するエンドサーバとは別に、ユーザ端末から事前に送信されるアクセスパス要求を受け付けて各ユーザ端末からエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へアクセスパスとして返信するアクセスサーバを設けることにより、ユーザ端末からのアクセスを漏れなく、かつ順序逆転なく公平に受け付けられるようにしたリクエスト受付方法およびシステムを提案している。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００７−２１９６５０号公報
【特許文献２】特開２００９−４３０６９号公報
【非特許文献】
【００１０】
【非特許文献１】「整理券発行機能を用いたアクセス制御システムの提案」，信学技法 vol.1 108 No.218, p81-p86.
【発明の概要】
【発明が解決しようとする課題】
【００１１】
エンドサーバにおいてユーザ端末からのサービス要求のアクセスを滞りなく処理するためには、エンドサーバに入力されるサービス要求の周期とエンドサーバが一つのサービス要求を処理するのに要する時間、すなわちサービス時間TAT(Turn Around Time)とが一致していることが望ましい。そこで、上記した特許文献２および非特許文献１に開示された技術では、各エンドサーバのサービス時間を予め統計的に推定し、この推定値に従ってサービス要求が各エンドサーバで処理されるという前提で各ユーザ端末のアクセスタイミングを決定していた。
【００１２】
しかしながら、例えばコンテンツ配信のサービス要求に応答してエンドサーバがユーザ端末へ動画などのコンテンツを配信するサービスでは、エンドサーバのサービス時間がユーザ端末におけるコンテンツのダウンロード速度に依存する。そして、ユーザ端末のダウンロード速度は、アクセス回線の容量や接続方式（有線LANまたは有線LANなど）に依存するので、提供するサービスが同一であってもエンドサーバのサービス時間が一定になるとは限らない。
【００１３】
したがって、上記の従来技術では、エンドサーバのサービス時間に関する推定値と実績値とに乖離が生じる場合があり、これが大きくなると、推定値＜実績値であればエンドサーバに輻輳が生じ、その逆に推定値＞実績値であればエンドサーバの運用効率が低下してしまう。
【００１４】
本発明の目的は、上記した従来技術の課題を解決し、エンドサーバの実際のサービス時間（実績処理レート）に基づいて各ユーザ端末からエンドサーバへのアクセスタイミングを適正に制御できるリクエスト受付方法およびシステムを提供することにある。
【課題を解決するための手段】
【００１５】
上記した目的を達成するために、本発明は、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付システムにおいて、ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、このアクセスパスサーバが以下のような手段を具備した点に特徴がある。
【００１６】
(1)ユーザ端末からアクセスパス要求を受信するアクセスパス要求受信手段と、受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定するアクセスタイミング決定手段と、アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成手段と、アクセスパス応答を要求元にユーザ端末へ返信するアクセスパス応答返信手段と、エンドサーバへのサービス要求を試行するサービス要求試行手段と、試行したサービス要求の実績処理レートを計測するサーバ能力計測手段と、計測結果に基づいてエンドサーバの能力を見直す見直手段とを具備したことを特徴とする。
【００１７】
(2)サービス要求試行手段は、第１の周期でサービス要求を試行した際の実績処理レートに基づいてサーバ能力を見直すか否かを決定し、エンドサーバの能力を見直す際は前記第１の周期よりも短い第２の周期でサービス要求を繰り返し試行し、見直手段は、第２の周期でサービス要求を繰り返し試行して得られた複数回の処理レートに基づいてエンドサーバの能力を見直すことを特徴とする。
【発明の効果】
【００１８】
本発明によれば、以下のような効果が達成される。
【００１９】
(1)エンドサーバの実績処理レート（サービス時間と同義）を監視し、この監視結果に基づいて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定するので、エンドサーバにサービス要求が集中して輻輳を生じさせたり、あるいはサービス要求が規制され過ぎてエンドサーバの運用効率を低下させたりすることなく、各ユーザ端末に対して最適なアクセスタイミングを決定できるようになる。
【００２０】
(2)アクセスパスサーバからエンドサーバへのサービス要求の試行が、最初は第１の周期で行われ、サーバ能力を見直す必要があると判定されると、今度は第１の周期よりも短い第２の周期で繰り返される。したがって、常時は試行の周期を長くすることができ、エンドサーバの負荷を軽減できるようになる。
【図面の簡単な説明】
【００２１】
【図１】本発明のリクエスト受付システムが適用されるネットワークのブロック図である。
【図２】ゲートウエイの主要部の構成を示した機能ブロック図である。
【図３】ユーザ端末におけるリクエスト処理の手順を示したフローチャートである。
【図４】アクセスパスサーバにおけるアクセスパス応答処理の手順を示したフローチャートである。
【図５】アクセスタイミング決定処理の手順を示したフローチャートである。
【図６】ユーザ端末がサービス要求を送信する推定確率をサービス要求のアクセスレートに基づいて算出する手順を示したフローチャートである。
【図７】ユーザ端末がサービス要求を送信する推定確率をアクセスパス要求のアクセスボリュームに基づいて算出する手順を示したフローチャートである。
【図８】サービス処理レートの見直し手順を示したシーケンスフローである。
【図９】受付完了メッセージの表示例を示した図である。
【図１０】ダウンロード完了メッセージの表示例を示した図である。
【図１１】サービス開始時刻およびサービス終了時刻をSYN/FINパケットに基づいて推定する方法を模式的に表現した図である。
【図１２】実績処理レートCrealをHTTP METHODに基づいて推定する方法を模式的に表現した図である。
【図１３】実績処理レートCrealをHTTPメッセージボディに基づいて推定する方法を模式的に表現した図である。
【図１４】エンドサーバの能力監視周期が変更される様子を示した図である。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の実施の形態について詳細に説明する。 図１は、本発明のリクエスト受付システムが適用されるネットワークの構成を示したブロック図であり、ここでは、ユーザ端末MNからエンドサーバES（サービス提供サーバ）へコンテンツの配信サービスを要求する場合を例にして説明する。
【００２３】
携帯電話、PDAあるいはコンピュータなどのユーザ端末MNは基地局APを経由して携帯電話網あるいはインターネット等のIPネットワークNWに接続されている。また、ユーザ端末MNからのサービス要求に応答して、音楽や映像などのコンテンツを配信する複数のエンドサーバESjが、アクセスパスサーバAPSと共に前記IPネットワークNWに接続されている。
【００２４】
前記アクセスパスサーバAPSは、各ユーザ端末MNにエンドサーバESjへのアクセス（サービス要求）を許可するタイミングを決定して各ユーザ端末MNへ通知する機能を備え、ユーザ端末MNから、アクセス先のエンドサーバESjの識別情報およびコンテンツの識別情報などを含むアクセスパス要求のメッセージを受信すると、エンドサーバESjの能力や状況に基づいてアクセスタイミングを決定し、これを要求元のユーザ端末MNへ通知する。ユーザ端末MNは、通知されたアクセスタイミングを待ってエンドサーバESjへサービス要求を送信し、当該エンドサーバESjからコンテンツ配信などのサービスを受ける。
【００２５】
図２は、前記アクセスパスサーバAPSの主要部の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。なお、アクセスパスサーバAPSが各ユーザ端末MNからアクセスパス要求を受信するごとに実行する応答処理は低負荷なので、アクセスパス要求が短時間に集中的に受信される場合でも、アクセスパスサーバAPSは全てのアクセスパス要求を受信順に滞りなく受付処理できる。
【００２６】
アクセスパス要求受信部１１は、各ユーザ端末MNから送信されたアクセスパス要求を受信する。サーバ処理管理部１２は、各エンドサーバESjにおけるサービス要求の処理状況をキュー値で仮想的に管理する。
【００２７】
アクセスタイミング決定部１３は、各エンドサーバESjがユーザ端末MNから受信した一つのサービス要求を処理するのに要するサービス時間TATを、各エンドサーバESjにおけるサービスの処理状況をアクセスパスサーバAPS上で模すための仮想的な処理レートCjとして管理する処理レート管理部１３１を具備し、後に詳述するように、前記サーバ処理管理部１２で管理されている各エンドサーバESjのキュー値や処理レートCjをパラメータとして、各ユーザ端末MNに対して許可する各エンドサーバESjへのアクセスタイミングをアクセスパス要求ごとに決定する。
【００２８】
アクセスパス応答生成部１４は、エンドサーバESjへのアクセスタイミングを含むアクセスパス応答を生成する。アクセスパス応答返信部１５は、前記アクセスパス応答を前記アクセスパス要求の送信元に返信する。
【００２９】
サービス要求試行部１６は、ダミーのサービス要求を各エンドサーバESjへ周期的に送信するサービス要求送信部１６１と、前記サービス要求に応答して各エンドサーバESjで開始されたサービスの終了を検知するサービス終了検知部１６２とを含む。
【００３０】
サーバ能力計測部１７は、前記サービスの開始タイミングおよび終了タイミングに基づいて各エンドサーバESjの実績処理レートCrealを算出する実績処理レート算出部１７１と、前記実績処理レートCrealに基づいて、前記処理レート管理部１３１で管理されている各エンドサーバの処理レートCjを見直す処理レート見直部１７２とを含む。
【００３１】
次いで、フローチャートを参照して本実施形態の動作を詳細に説明する。図３は、コンテンツ配信を要求するユーザ端末MNにおけるリクエスト処理の手順を示したフローチャートであり、図４，５，６，７，８は、アクセスパスサーバAPSの動作を示したフローチャートである。
【００３２】
ユーザがユーザ端末MNのキースイッチ等を操作してコンテンツのリクエスト操作を実施し、これが図３のステップＳ１１で検知されるとステップＳ１２へ進む。ステップＳ１２では、リクエストするコンテンツの識別子および当該コンテンツを提供するエンドサーバESjの識別子を含み、アクセスパスサーバAPSを宛先とするアクセスパス要求が生成され、ステップＳ１３において送信される。
【００３３】
図４へ進み、アクセスパスサーバAPSは、図４のステップＳ３１において前記アクセスパス要求を受信すると、ステップＳ３２では、前記アクセスタイミング決定部１３において、ユーザ端末MNに前記エンドサーバESjへのアクセスを許可するタイミングが以下の手順で決定される。
【００３４】
図５は、アクセスタイミング決定処理の手順を示したフローチャートであり、主に前記アクセスタイミング決定部１３の動作を示している。なお、各符号の定義は以下の通りである。
【００３５】
i：アクセスパス要求の識別子
j：エンドサーバESの識別子
ti,j：エンドサーバESjに対するi番目のアクセス要求時刻
di,j：エンドサーバESjに対するi番目のアクセス要求に対して割り当てられるアクセスタイミングまでの待機時間
Cj：各エンドサーバESjの処理能力（処理レート）
Qmax_j：各エンドサーバESjのキュー値の上限値
bi,j：重み値
δ：アクセスパスサーバAPSからユーザ端末MNへのアクセスパス要求の想定伝達遅延時間
Qj(ti,j)−：時刻tiでアクセスパス要求を受信する直前のエンドサーバESjのキュー値
Qj(ti,j)＋：時刻tiでアクセスパス要求を受信した直後のエンドサーバESjのキュー値
pj：エンドサーバESjへアクセスパス要求を送信したユーザ端末MNが、許可されたアクセスタイミングでエンドサーバESjへサービス要求を送信する推定確率
【００３６】
図５のステップＳ３２１では、受信したアクセスパス要求に登録されている識別子に対応したエンドサーバESjに関して、前回のアクセスパス要求を時刻[ti-1]で受信した直後のキュー値[Qj(ti-1,j)＋]が前記サーバ処理管理部１２から取り込まれる。本実施形態では、一つのキューが一つのサービス要求を代表している。
【００３７】
ステップＳ３２２では、エンドサーバESjの処理レートCjが処理レート管理部１３１から取り込まれる。なお、この処理レートCjは、後に図８のフローチャートを参照して詳述するように、各エンドサーバESjの負荷に応じて動的に見直される。ステップＳ３２３では、時刻[ti,j]でエンドサーバESj宛のアクセスパス要求を受信する直前の当該エンドサーバESjの未処理リクエスト量、すなわちキュー値[Qj(ti,j)−]が次式(1)で求められる。
【００３８】
【数１】
【００３９】
ステップＳ３２４では、時刻[ti,j]でアクセスパス要求を受信した直後のキュー値[Qj(ti,j)＋]が次式(2)で求められる。
【００４０】
【数２】
【００４１】
ここで、重み値[bi,j]はサービス要求を処理するエンドサーバESjの処理負荷に依存し、例えば、アクセスパス要求が音楽コンテンツの配信要求であれば、リクエストする音楽ファイルのサイズが大きいほど大きな重み値bi,jが割り当てられる。なお、重み付けが不要であれば、前記重み値[bi,j]には所定の定数（例えば、「１」）が割り当てられる。
【００４２】
ステップＳ３２５では、アクセスパス要求を送信したユーザ端末MNに通知するアクセスタイミングが、当該アクセスパス要求の受信時刻[ti,j]を基準にした待機時間[di,j]として次式(3)で求められる。ステップＳ３２６では、前記キュー値[Qj(ti,j)＋]の計算結果が前記サーバ処理管理部１２へ更新登録される。
【００４３】
【数３】
【００４４】
なお、ユーザ端末MNがアクセスパス応答を受信しても、回線状況の変化等が原因で、許可されたアクセスタイミングにおいてサービス要求を送信できなくなる場合がある。次式(4)では、このような状況を考慮して、サービス要求を送信したユーザ端末MNが、さらにサービス要求を送信する推定確率pj(ti,j)をエンドサーバESjごとに統計的に求めて前記待機時間[di,j]に反映させている。
【００４５】
【数４】
【００４６】
図６は、前記推定確率Pj(ti,j)をエンドサーバESjへのアクセスレートに基づいて算出する手順を示したフローチャートである。
【００４７】
ステップＳ７１において、エンドサーバESjに関するアクセスパス要求が受信されると、ステップＳ７２では、前回のアクセスパス要求の受信時刻ti-1,jから今回のアクセスパス要求の受信時刻ti,jまでの経過期間Δti,j、および当該経過時間Δti,jにおけるエンドサーバESjへのアクセス数ni,j、すなわちサービス要求の総数が算出される。
【００４８】
ステップＳ７３では、今回のアクセスパス要求を受信する直前のエンドサーバESjのキュー値[Qj(ti,j)−]がゼロよりも大きいか否かが判定される。キュー値[Qj(ti,j)−]がゼロよりも大きければステップＳ７４へ進み、キュー値[Qj(ti,j)−]が最後にゼロとなった以降の累積アクセス数Mおよび経過時刻Tが算出される。ステップＳ７５では、エンドサーバESjへの平均アクセスレートARj(ti,j)が、前記累積アクセス数Mおよび経過時刻Tに基づいて算出される。ステップＳ７６では、次式(5)に基づいて推定確率Pj(ti,j)が設定される。なお、符号Pminは０＜Pmin＜１の定数である。
【００４９】
【数５】
【００５０】
これに対して、前記ステップＳ７３においてキュー値[Qj(ti,j)−]がゼロと判定されると、ステップＳ７７において推定確率Pj(ti,j)に「１」が登録される。ステップＳ７８では、前記累積アクセス数Mおよび経過時刻Tがリセットされる。
【００５１】
図７は、前記推定確率Pj(ti,j)をサービス要求やコンテンツのボリューム（以下、アクセスボリュームで総称する）に基づいて算出する手順を示したフローチャートである。
【００５２】
ステップＳ８１において、エンドサーバESjに関するアクセスパス要求が受信されると、ステップＳ８２では、前回のアクセスパス要求の受信時刻ti-1,jから今回のアクセスパス要求の受信時刻ti,jまでの経過期間Δti,j、および当該経過時間Δti,jにおけるエンドサーバESjのアクセスボリュームvi,jが算出される。
【００５３】
ステップＳ８３では、今回のアクセスパス要求を受信する直前のエンドサーバESjのキュー値[Qj(ti,j)−]がゼロよりも大きいか否かが判定される。キュー値[Qj(ti,j)−]がゼロよりも大きければステップＳ８４へ進み、キュー値[Qj(ti,j)−]が最後にゼロとなった以降の累積アクセスボリュームWおよび経過時刻Tが算出される。ステップＳ８５では、エンドサーバESjへの平均アクセスボリュームVRj(ti,j)が、前記累積アクセスボリュームWおよび経過時刻Tに基づいて算出される。ステップＳ８６では、次式(6)に基づいて推定確率Pj(ti,j)が設定される。なお、符号Pminは０＜Pmin＜１の定数である。
【００５４】
【数６】
【００５５】
これに対して、前記ステップＳ８３においてキュー値[Qj(ti,j)−]がゼロと判定されると、ステップＳ８７において推定確率Pj(ti,j)に「１」が登録される。ステップＳ８８では、前記累積アクセスボリュームWおよび経過時刻Tがリセットされる。
【００５６】
図４へ戻り、ステップＳ３３では、前記アクセスタイミングとしての待機時間[di,j]を含むアクセスパス応答が前記アクセスパス応答生成部１４で生成され、ステップＳ３４において、前記アクセスパス応答返信部１５から、前記アクセスパス要求を送信したユーザ端末MN宛に返信される。
【００５７】
図３へ戻り、ユーザ端末MNでは、前記アクセスパス応答がステップＳ１４で受信されると、ステップＳ１５では、このアクセスパス応答に登録されているアクセスタイミングとしての待機時間[di,j]が抽出される。ステップＳ１６では、抽出された待機時間[di,j]が所定の上限値dmaxと比較され、待機時間[di,j]＞dmaxであればステップＳ１７へ進み、サービスを提供できない旨のエラーメッセージを端末ディスプレーに表示して当該処理を中止する。これに対して、待機時間[di,j]≦dmaxであればステップＳ１８へ進み、図９(a)，(b)に一例を示したように、リクエストが先着順に処理されている旨を示す受付完了メッセージが端末ディスプレーに表示される。
【００５８】
ステップＳ１９では、配信を要求するコンテンツの識別子およびエンドサーバの識別子を含むコンテンツ要求がサービス要求として生成される。ステップＳ２０では、前記ステップＳ１３においてアクセス要求パスを送信してからの経過時間が前記待機時間[di,j]に達したか否かに基づいてアクセスタイミングであるか否かが判定され、アクセスタイミングを待ってステップＳ２１へ進む。ステップＳ２１では、前記ステップＳ１９で生成されたサービス要求（ここでは、コンテンツ配信要求）が、前記エンドサーバESjを宛先として送信される。このようなユーザ端末MNにおけるアクセスタイミングまでの待機処理は、Java(登録商標)scriptなどの各種スクリプト言語やFlash機能を利用することで実装できる。
【００５９】
このサービス要求を受信したエンドサーバESjは、要求されているコンテンツを用意して前記ユーザ端末MNへ配信する。
【００６０】
ユーザ端末MNは、前記コンテンツをステップＳ２２で受信すると、ステップＳ２３へ進んで当該コンテンツを保存する。ステップＳ２４では、図１０に一例を示したダウンロード完了メッセージが端末ディスプレーに表示される。
【００６１】
図８は、各エンドサーバESjの処理レートCjを動的に見直すサービス要求試行部１６およびサーバ能力計測部１７の動作を示したフローチャートである。
【００６２】
ステップＳ４９では、未だ処理負荷の低い監視対象のエンドサーバESjに対して、前記サービス要求試行部１６によりダミーのサービス要求が試行され、その応答が受信される。ステップＳ５０では、前記サーバ能力計測部１７により、前記試行されたサービス要求およびその応答に基づいて、試行された一つのサービス要求をエンドサーバESjが処理するのに要するサービス時間が計測され、これがエンドサーバESjの現在の実績処理レートCrealとされる。
【００６３】
図１１，１２，１３は、実績処理レートCrealの計測方法の一例を示したシーケンスフローであり、サービス要求およびサービス応答がTCPセッションを利用して行われる場合、SYN/FINパケット、HTTP METHOD、あるいはHTTPメッセージボディを監視することで実績処理レートCrealが求められる。
【００６４】
図１１は、サービス開始時刻およびサービス終了時刻をSYN/FINパケットに基づいて推定する方法を模式的に表現した図である。
【００６５】
TCPセッションは複数(N個)のTCPコネクションにより構成され、各TCPコネクションはアクセスパスサーバAPSから送信されるSYNパケットに対してエンドサーバESjがSYN-ACKを返信し、さらにアクセスパスサーバAPSからエンドサーバESjへACKパケットが送信されることにより確立される。そして、このようにして確立されたTCPコネクションは、アクセスパスサーバAPSおよびエンドサーバESjの双方がFIN-ACKを交換することで切断される。
【００６６】
そこで、本実施形態ではエンドサーバESjから送信された最初のSYN-ACKがアクセスパスサーバAPSで受信された時刻をサービス開始時刻とし、さらに、N回目のFIN-ACK交換においてアクセスパスサーバAPSからFIN-ACKが送信された時刻をサービス終了時刻とし、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
【００６７】
なお、前記TCPコネクション数（N個）はサービス内容に依存するので、アクセスパスサーバAPSは事前に各エンドサーバESjから各サービスのTCPコネクション数(N個)を取得しておくことが望ましい。
【００６８】
また、各TCPコネクションが同一のTCPセッションに係るものであるか否かは、例えば送信元IPアドレスおよびport番号が同一、かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断できる。あるいは、送信元端末固有のIDが同一かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断しても良い。
【００６９】
図１２は、実績処理レートCrealをHTTP METHODに基づいて推定する方法を模式的に表現した図である。この方法では、アクセスパスサーバAPSからHTTP METHOD（例えば、GET，POSTなど）が送信された時点でアクセスパスサーバAPSとエンドサーバESjとの間にTCPコネクションが確立されたものと判断し、当該時刻がサービス開始時刻とされる。
【００７０】
そして、N回目のFIN-ACK交換においてアクセスパスサーバAPSからFIN-ACKが送信された時刻がサービス終了時刻とされ、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
【００７１】
図１３は、実績処理レートCrealをHTTPメッセージボディに基づいて推定する方法を模式的に表現した図である。この方法では、セッション開始を意味する識別コード（たとえば、「start」などの文字列）の登録されているHTTPメッセージボディがアクセスパスサーバAPSから送信された時刻がサービス開始時刻とされる。
【００７２】
そして、セッション終了を意味する識別コード（たとえば、「finish」などの文字列）の登録されているHTTPメッセージボディがアクセスパスサーバAPSから送信された時刻がサービス終了時刻とされ、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
【００７３】
図８へ戻り、ステップＳ５１では、前記ステップＳ５０で計測された現在の実績処理レートCrealが標準処理レートC1とされる。ステップＳ５２では、アクセスパスサーバAPSがエンドサーバESjの実績処理レートCrealを監視する周期Uに標準周期U1が設定される。ステップＳ５３では、監視周期Uの監視タイミングであるか否かが判定され、監視タイミングであればステップＳ５４へ進む。
【００７４】
ステップＳ５４では監視対象のエンドサーバESjに対して、前記サービス要求試行部１６によりダミーのサービス要求が試行され、その応答が受信される。ステップＳ５５では、前記試行されたサービス要求およびその応答に基づいて、前記と同様にエンドサーバESjの現在の実績処理レートCrealが計測される。本実施形態では、前記サービス要求の試行がエンドサーバESjにとって負荷とならないように前記標準周期U1が設定されている。
【００７５】
ステップＳ５６では、現在の実績処理レートCrealと標準処理レートC1との乖離が閾値Crefと比較される。エンドサーバESjの処理負荷が未だ低くければ乖離が閾値Cref以下となるので、現在の処理レートCjが適正と判定されてステップＳ５３へ戻り、現在の監視周期U(＝Uref)での監視が繰り返される。
【００７６】
これに対して、エンドサーバESjの処理負荷が上昇し、乖離が閾値Crefを上回るようになるとステップＳ５７へ進み、エンドサーバESjの監視周期Uが見直されて現在の標準監視周期U1よりも短い周期U2に変更される。図１４は、監視周期Uが変更される様子を模式的に示した図であり、時刻t1において乖離が大きいと判定されると、それ以降、監視周期UがU1からU2に短縮されている。
【００７７】
ステップＳ５８では、見直し後の短い監視周期U(＝U2)の監視タイミングであるか否かが判定され、監視タイミングであればステップＳ５９へ進む。ステップＳ５９では、監視対象のエンドサーバESjに対してダミーのサービス要求が試行され、その応答が受信される。ステップＳ６０では、前記試行されたサービス要求およびその応答に基づいて、前記と同様に現在の実績処理レートCrealが計測される。ステップＳ６１ではサービス要求の試行回数が判定され、n回の試行が繰り返されるまでステップＳ５８へ戻る。本実施形態では、前記監視周期U2もサービス要求の試行がエンドサーバESjにとって負荷とならない時間に設定されている。
【００７８】
その後、周期Uでのn回の試行が完了するとステップＳ６２へ進み、n回のサービス要求の試行で得られた実績処理レートCrealの平均値Cave（平均処理レート）が算出される。ステップＳ６３では、標準処理レートC1と前記平均処理レートCaveとが比較され、C1≒Cave であれば、現在の処理レートCjが適正と判定されてステップＳ５２へ戻り、監視周期Uを初期値1に戻して上記の処理が繰り返される。
【００７９】
これに対して、C1≒CaveでなければステップＳ６４へ進み、C1とCaveとの差分(C1−Cave)が相対的な乖離度として算出され、これを現在の処理レートCjから減じた値が新たな処理レートCjとされる。ステップＳ６５では、標準処理レートC1が平均処理レートCaveに更新され、その後、ステップＳ５２へ戻って上記の各処理が繰り返される。
【００８０】
なお、上記した実施形態では、ユーザ端末MNがコンテンツ配信用のアクセスパスを予め取得し、このアクセスパスによって許可されたアクセスタイミングでエンドサーバESjへコンテンツ要求を送信してコンテンツをダウンロードする場合を例にして説明したが、本発明はこれのみに限定されるものではなく、ユーザ端末がデータやコンテンツをエンドサーバESjへアップロードするためのアクセスパスを予め取得し、許可されたアクセスタイミングでアップロードを実行する場合にも同様に適用できる。
【符号の説明】
【００８１】
１…リクエスト応答部，２…リクエスト受付部，１１…リクエスト受信部，１２…サーバ処理管理部，１３…アクセスタイミング決定部，１４…アクセスパス応答生成部，１５…アクセスパス応答返信部，１６…サービス要求試行部，１７…サーバ能力計測部
【技術分野】
【０００１】
本発明は、ユーザ端末から送信されたアクセスパス要求を予め受け付けて、各ユーザ端末からエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へアクセスパスとして返信するリクエスト受付方法およびシステムに関する。
【背景技術】
【０００２】
災害発生時の安否確認のためのリクエスト、あるいはTV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。これらの宛先でリクエストを受け付けるエンドサーバでは、リクエスト数が処理能力を超過すると、超過分についてはサービスの提供が不可能となる。これは同サービスを利用するユーザの満足度を低下させると共に、リクエストが有料コンテンツの配信であれば、コンテンツ提供者にとっては販売機会の損失となる。
【０００３】
イベントを契機とするアクセスの集中は通常のアクセス量を遙かに凌駕し、瞬間的には１０倍から１００倍に達する場合もある。したがって、アクセス集中時のピーク時に合わせてサーバ容量を設計してしまうと、時間的に大半を占める通常時には大幅な過剰設備状態を招いてしまう。しかも、このようなアクセス集中は予測が難しいので、たとえ十分と予測される設備を用意できたとしても、その容量を上回るアクセスが集中する可能性を否定できない。
【０００４】
一方、２００３年１２月に東京・大阪・名古屋で地上デジタル放送が開始され、それ以後、他の地域でも放送が順次開始されると共に、移動体受信端末向けサービスなどが拡充されることになっている。地上デジタル放送で提供される通信放送連携サービスでは、番組内容を契機とした同時大量アクセスの発生が予見されており、上記で指摘した事象が今後ますます顕在化してくることが想定される。
【０００５】
特許文献１には、アクセス集中により受付拒否されたリクエストメッセージの再アクセスを、新たなアクセス集中を生じさせることなく公平に受け付けて処理できるシステムが開示されている。
【０００６】
ここでは、サービスを提供するエンドサーバに多数のアクセスが集中すると、受け付けられないユーザに対して、現在混んでいる旨と、次回優先接続される時間帯が提示される。同ユーザが改めて優先接続時間帯にアクセスしてきた場合、このリクエストメッセージは他のリクエストメッセージよりも優先的に受け付けられる。
【０００７】
しかしながら、特許文献１では一のユーザがリクエストメッセージを送信した際に受付側の負荷が大きいと受付を後回しにされる一方、その直後に他の一のユーザがリクエストメッセージを送信した際に受付側の負荷が解消していると、当該他の一のユーザのリクエストメッセージが先に受け付けられてしまうので、受付が公平に行われないという技術課題があった。
【０００８】
このような技術課題に対して、本発明の発明者等は特許文献２および非特許文献１において、ユーザにサービスを提供するエンドサーバとは別に、ユーザ端末から事前に送信されるアクセスパス要求を受け付けて各ユーザ端末からエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へアクセスパスとして返信するアクセスサーバを設けることにより、ユーザ端末からのアクセスを漏れなく、かつ順序逆転なく公平に受け付けられるようにしたリクエスト受付方法およびシステムを提案している。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００７−２１９６５０号公報
【特許文献２】特開２００９−４３０６９号公報
【非特許文献】
【００１０】
【非特許文献１】「整理券発行機能を用いたアクセス制御システムの提案」，信学技法 vol.1 108 No.218, p81-p86.
【発明の概要】
【発明が解決しようとする課題】
【００１１】
エンドサーバにおいてユーザ端末からのサービス要求のアクセスを滞りなく処理するためには、エンドサーバに入力されるサービス要求の周期とエンドサーバが一つのサービス要求を処理するのに要する時間、すなわちサービス時間TAT(Turn Around Time)とが一致していることが望ましい。そこで、上記した特許文献２および非特許文献１に開示された技術では、各エンドサーバのサービス時間を予め統計的に推定し、この推定値に従ってサービス要求が各エンドサーバで処理されるという前提で各ユーザ端末のアクセスタイミングを決定していた。
【００１２】
しかしながら、例えばコンテンツ配信のサービス要求に応答してエンドサーバがユーザ端末へ動画などのコンテンツを配信するサービスでは、エンドサーバのサービス時間がユーザ端末におけるコンテンツのダウンロード速度に依存する。そして、ユーザ端末のダウンロード速度は、アクセス回線の容量や接続方式（有線LANまたは有線LANなど）に依存するので、提供するサービスが同一であってもエンドサーバのサービス時間が一定になるとは限らない。
【００１３】
したがって、上記の従来技術では、エンドサーバのサービス時間に関する推定値と実績値とに乖離が生じる場合があり、これが大きくなると、推定値＜実績値であればエンドサーバに輻輳が生じ、その逆に推定値＞実績値であればエンドサーバの運用効率が低下してしまう。
【００１４】
本発明の目的は、上記した従来技術の課題を解決し、エンドサーバの実際のサービス時間（実績処理レート）に基づいて各ユーザ端末からエンドサーバへのアクセスタイミングを適正に制御できるリクエスト受付方法およびシステムを提供することにある。
【課題を解決するための手段】
【００１５】
上記した目的を達成するために、本発明は、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付システムにおいて、ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、このアクセスパスサーバが以下のような手段を具備した点に特徴がある。
【００１６】
(1)ユーザ端末からアクセスパス要求を受信するアクセスパス要求受信手段と、受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定するアクセスタイミング決定手段と、アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成手段と、アクセスパス応答を要求元にユーザ端末へ返信するアクセスパス応答返信手段と、エンドサーバへのサービス要求を試行するサービス要求試行手段と、試行したサービス要求の実績処理レートを計測するサーバ能力計測手段と、計測結果に基づいてエンドサーバの能力を見直す見直手段とを具備したことを特徴とする。
【００１７】
(2)サービス要求試行手段は、第１の周期でサービス要求を試行した際の実績処理レートに基づいてサーバ能力を見直すか否かを決定し、エンドサーバの能力を見直す際は前記第１の周期よりも短い第２の周期でサービス要求を繰り返し試行し、見直手段は、第２の周期でサービス要求を繰り返し試行して得られた複数回の処理レートに基づいてエンドサーバの能力を見直すことを特徴とする。
【発明の効果】
【００１８】
本発明によれば、以下のような効果が達成される。
【００１９】
(1)エンドサーバの実績処理レート（サービス時間と同義）を監視し、この監視結果に基づいて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定するので、エンドサーバにサービス要求が集中して輻輳を生じさせたり、あるいはサービス要求が規制され過ぎてエンドサーバの運用効率を低下させたりすることなく、各ユーザ端末に対して最適なアクセスタイミングを決定できるようになる。
【００２０】
(2)アクセスパスサーバからエンドサーバへのサービス要求の試行が、最初は第１の周期で行われ、サーバ能力を見直す必要があると判定されると、今度は第１の周期よりも短い第２の周期で繰り返される。したがって、常時は試行の周期を長くすることができ、エンドサーバの負荷を軽減できるようになる。
【図面の簡単な説明】
【００２１】
【図１】本発明のリクエスト受付システムが適用されるネットワークのブロック図である。
【図２】ゲートウエイの主要部の構成を示した機能ブロック図である。
【図３】ユーザ端末におけるリクエスト処理の手順を示したフローチャートである。
【図４】アクセスパスサーバにおけるアクセスパス応答処理の手順を示したフローチャートである。
【図５】アクセスタイミング決定処理の手順を示したフローチャートである。
【図６】ユーザ端末がサービス要求を送信する推定確率をサービス要求のアクセスレートに基づいて算出する手順を示したフローチャートである。
【図７】ユーザ端末がサービス要求を送信する推定確率をアクセスパス要求のアクセスボリュームに基づいて算出する手順を示したフローチャートである。
【図８】サービス処理レートの見直し手順を示したシーケンスフローである。
【図９】受付完了メッセージの表示例を示した図である。
【図１０】ダウンロード完了メッセージの表示例を示した図である。
【図１１】サービス開始時刻およびサービス終了時刻をSYN/FINパケットに基づいて推定する方法を模式的に表現した図である。
【図１２】実績処理レートCrealをHTTP METHODに基づいて推定する方法を模式的に表現した図である。
【図１３】実績処理レートCrealをHTTPメッセージボディに基づいて推定する方法を模式的に表現した図である。
【図１４】エンドサーバの能力監視周期が変更される様子を示した図である。
【発明を実施するための形態】
【００２２】
以下、図面を参照して本発明の実施の形態について詳細に説明する。 図１は、本発明のリクエスト受付システムが適用されるネットワークの構成を示したブロック図であり、ここでは、ユーザ端末MNからエンドサーバES（サービス提供サーバ）へコンテンツの配信サービスを要求する場合を例にして説明する。
【００２３】
携帯電話、PDAあるいはコンピュータなどのユーザ端末MNは基地局APを経由して携帯電話網あるいはインターネット等のIPネットワークNWに接続されている。また、ユーザ端末MNからのサービス要求に応答して、音楽や映像などのコンテンツを配信する複数のエンドサーバESjが、アクセスパスサーバAPSと共に前記IPネットワークNWに接続されている。
【００２４】
前記アクセスパスサーバAPSは、各ユーザ端末MNにエンドサーバESjへのアクセス（サービス要求）を許可するタイミングを決定して各ユーザ端末MNへ通知する機能を備え、ユーザ端末MNから、アクセス先のエンドサーバESjの識別情報およびコンテンツの識別情報などを含むアクセスパス要求のメッセージを受信すると、エンドサーバESjの能力や状況に基づいてアクセスタイミングを決定し、これを要求元のユーザ端末MNへ通知する。ユーザ端末MNは、通知されたアクセスタイミングを待ってエンドサーバESjへサービス要求を送信し、当該エンドサーバESjからコンテンツ配信などのサービスを受ける。
【００２５】
図２は、前記アクセスパスサーバAPSの主要部の構成を示した機能ブロック図であり、ここでは、本発明の説明に不要な構成は図示が省略されている。なお、アクセスパスサーバAPSが各ユーザ端末MNからアクセスパス要求を受信するごとに実行する応答処理は低負荷なので、アクセスパス要求が短時間に集中的に受信される場合でも、アクセスパスサーバAPSは全てのアクセスパス要求を受信順に滞りなく受付処理できる。
【００２６】
アクセスパス要求受信部１１は、各ユーザ端末MNから送信されたアクセスパス要求を受信する。サーバ処理管理部１２は、各エンドサーバESjにおけるサービス要求の処理状況をキュー値で仮想的に管理する。
【００２７】
アクセスタイミング決定部１３は、各エンドサーバESjがユーザ端末MNから受信した一つのサービス要求を処理するのに要するサービス時間TATを、各エンドサーバESjにおけるサービスの処理状況をアクセスパスサーバAPS上で模すための仮想的な処理レートCjとして管理する処理レート管理部１３１を具備し、後に詳述するように、前記サーバ処理管理部１２で管理されている各エンドサーバESjのキュー値や処理レートCjをパラメータとして、各ユーザ端末MNに対して許可する各エンドサーバESjへのアクセスタイミングをアクセスパス要求ごとに決定する。
【００２８】
アクセスパス応答生成部１４は、エンドサーバESjへのアクセスタイミングを含むアクセスパス応答を生成する。アクセスパス応答返信部１５は、前記アクセスパス応答を前記アクセスパス要求の送信元に返信する。
【００２９】
サービス要求試行部１６は、ダミーのサービス要求を各エンドサーバESjへ周期的に送信するサービス要求送信部１６１と、前記サービス要求に応答して各エンドサーバESjで開始されたサービスの終了を検知するサービス終了検知部１６２とを含む。
【００３０】
サーバ能力計測部１７は、前記サービスの開始タイミングおよび終了タイミングに基づいて各エンドサーバESjの実績処理レートCrealを算出する実績処理レート算出部１７１と、前記実績処理レートCrealに基づいて、前記処理レート管理部１３１で管理されている各エンドサーバの処理レートCjを見直す処理レート見直部１７２とを含む。
【００３１】
次いで、フローチャートを参照して本実施形態の動作を詳細に説明する。図３は、コンテンツ配信を要求するユーザ端末MNにおけるリクエスト処理の手順を示したフローチャートであり、図４，５，６，７，８は、アクセスパスサーバAPSの動作を示したフローチャートである。
【００３２】
ユーザがユーザ端末MNのキースイッチ等を操作してコンテンツのリクエスト操作を実施し、これが図３のステップＳ１１で検知されるとステップＳ１２へ進む。ステップＳ１２では、リクエストするコンテンツの識別子および当該コンテンツを提供するエンドサーバESjの識別子を含み、アクセスパスサーバAPSを宛先とするアクセスパス要求が生成され、ステップＳ１３において送信される。
【００３３】
図４へ進み、アクセスパスサーバAPSは、図４のステップＳ３１において前記アクセスパス要求を受信すると、ステップＳ３２では、前記アクセスタイミング決定部１３において、ユーザ端末MNに前記エンドサーバESjへのアクセスを許可するタイミングが以下の手順で決定される。
【００３４】
図５は、アクセスタイミング決定処理の手順を示したフローチャートであり、主に前記アクセスタイミング決定部１３の動作を示している。なお、各符号の定義は以下の通りである。
【００３５】
i：アクセスパス要求の識別子
j：エンドサーバESの識別子
ti,j：エンドサーバESjに対するi番目のアクセス要求時刻
di,j：エンドサーバESjに対するi番目のアクセス要求に対して割り当てられるアクセスタイミングまでの待機時間
Cj：各エンドサーバESjの処理能力（処理レート）
Qmax_j：各エンドサーバESjのキュー値の上限値
bi,j：重み値
δ：アクセスパスサーバAPSからユーザ端末MNへのアクセスパス要求の想定伝達遅延時間
Qj(ti,j)−：時刻tiでアクセスパス要求を受信する直前のエンドサーバESjのキュー値
Qj(ti,j)＋：時刻tiでアクセスパス要求を受信した直後のエンドサーバESjのキュー値
pj：エンドサーバESjへアクセスパス要求を送信したユーザ端末MNが、許可されたアクセスタイミングでエンドサーバESjへサービス要求を送信する推定確率
【００３６】
図５のステップＳ３２１では、受信したアクセスパス要求に登録されている識別子に対応したエンドサーバESjに関して、前回のアクセスパス要求を時刻[ti-1]で受信した直後のキュー値[Qj(ti-1,j)＋]が前記サーバ処理管理部１２から取り込まれる。本実施形態では、一つのキューが一つのサービス要求を代表している。
【００３７】
ステップＳ３２２では、エンドサーバESjの処理レートCjが処理レート管理部１３１から取り込まれる。なお、この処理レートCjは、後に図８のフローチャートを参照して詳述するように、各エンドサーバESjの負荷に応じて動的に見直される。ステップＳ３２３では、時刻[ti,j]でエンドサーバESj宛のアクセスパス要求を受信する直前の当該エンドサーバESjの未処理リクエスト量、すなわちキュー値[Qj(ti,j)−]が次式(1)で求められる。
【００３８】
【数１】
【００３９】
ステップＳ３２４では、時刻[ti,j]でアクセスパス要求を受信した直後のキュー値[Qj(ti,j)＋]が次式(2)で求められる。
【００４０】
【数２】
【００４１】
ここで、重み値[bi,j]はサービス要求を処理するエンドサーバESjの処理負荷に依存し、例えば、アクセスパス要求が音楽コンテンツの配信要求であれば、リクエストする音楽ファイルのサイズが大きいほど大きな重み値bi,jが割り当てられる。なお、重み付けが不要であれば、前記重み値[bi,j]には所定の定数（例えば、「１」）が割り当てられる。
【００４２】
ステップＳ３２５では、アクセスパス要求を送信したユーザ端末MNに通知するアクセスタイミングが、当該アクセスパス要求の受信時刻[ti,j]を基準にした待機時間[di,j]として次式(3)で求められる。ステップＳ３２６では、前記キュー値[Qj(ti,j)＋]の計算結果が前記サーバ処理管理部１２へ更新登録される。
【００４３】
【数３】
【００４４】
なお、ユーザ端末MNがアクセスパス応答を受信しても、回線状況の変化等が原因で、許可されたアクセスタイミングにおいてサービス要求を送信できなくなる場合がある。次式(4)では、このような状況を考慮して、サービス要求を送信したユーザ端末MNが、さらにサービス要求を送信する推定確率pj(ti,j)をエンドサーバESjごとに統計的に求めて前記待機時間[di,j]に反映させている。
【００４５】
【数４】
【００４６】
図６は、前記推定確率Pj(ti,j)をエンドサーバESjへのアクセスレートに基づいて算出する手順を示したフローチャートである。
【００４７】
ステップＳ７１において、エンドサーバESjに関するアクセスパス要求が受信されると、ステップＳ７２では、前回のアクセスパス要求の受信時刻ti-1,jから今回のアクセスパス要求の受信時刻ti,jまでの経過期間Δti,j、および当該経過時間Δti,jにおけるエンドサーバESjへのアクセス数ni,j、すなわちサービス要求の総数が算出される。
【００４８】
ステップＳ７３では、今回のアクセスパス要求を受信する直前のエンドサーバESjのキュー値[Qj(ti,j)−]がゼロよりも大きいか否かが判定される。キュー値[Qj(ti,j)−]がゼロよりも大きければステップＳ７４へ進み、キュー値[Qj(ti,j)−]が最後にゼロとなった以降の累積アクセス数Mおよび経過時刻Tが算出される。ステップＳ７５では、エンドサーバESjへの平均アクセスレートARj(ti,j)が、前記累積アクセス数Mおよび経過時刻Tに基づいて算出される。ステップＳ７６では、次式(5)に基づいて推定確率Pj(ti,j)が設定される。なお、符号Pminは０＜Pmin＜１の定数である。
【００４９】
【数５】
【００５０】
これに対して、前記ステップＳ７３においてキュー値[Qj(ti,j)−]がゼロと判定されると、ステップＳ７７において推定確率Pj(ti,j)に「１」が登録される。ステップＳ７８では、前記累積アクセス数Mおよび経過時刻Tがリセットされる。
【００５１】
図７は、前記推定確率Pj(ti,j)をサービス要求やコンテンツのボリューム（以下、アクセスボリュームで総称する）に基づいて算出する手順を示したフローチャートである。
【００５２】
ステップＳ８１において、エンドサーバESjに関するアクセスパス要求が受信されると、ステップＳ８２では、前回のアクセスパス要求の受信時刻ti-1,jから今回のアクセスパス要求の受信時刻ti,jまでの経過期間Δti,j、および当該経過時間Δti,jにおけるエンドサーバESjのアクセスボリュームvi,jが算出される。
【００５３】
ステップＳ８３では、今回のアクセスパス要求を受信する直前のエンドサーバESjのキュー値[Qj(ti,j)−]がゼロよりも大きいか否かが判定される。キュー値[Qj(ti,j)−]がゼロよりも大きければステップＳ８４へ進み、キュー値[Qj(ti,j)−]が最後にゼロとなった以降の累積アクセスボリュームWおよび経過時刻Tが算出される。ステップＳ８５では、エンドサーバESjへの平均アクセスボリュームVRj(ti,j)が、前記累積アクセスボリュームWおよび経過時刻Tに基づいて算出される。ステップＳ８６では、次式(6)に基づいて推定確率Pj(ti,j)が設定される。なお、符号Pminは０＜Pmin＜１の定数である。
【００５４】
【数６】
【００５５】
これに対して、前記ステップＳ８３においてキュー値[Qj(ti,j)−]がゼロと判定されると、ステップＳ８７において推定確率Pj(ti,j)に「１」が登録される。ステップＳ８８では、前記累積アクセスボリュームWおよび経過時刻Tがリセットされる。
【００５６】
図４へ戻り、ステップＳ３３では、前記アクセスタイミングとしての待機時間[di,j]を含むアクセスパス応答が前記アクセスパス応答生成部１４で生成され、ステップＳ３４において、前記アクセスパス応答返信部１５から、前記アクセスパス要求を送信したユーザ端末MN宛に返信される。
【００５７】
図３へ戻り、ユーザ端末MNでは、前記アクセスパス応答がステップＳ１４で受信されると、ステップＳ１５では、このアクセスパス応答に登録されているアクセスタイミングとしての待機時間[di,j]が抽出される。ステップＳ１６では、抽出された待機時間[di,j]が所定の上限値dmaxと比較され、待機時間[di,j]＞dmaxであればステップＳ１７へ進み、サービスを提供できない旨のエラーメッセージを端末ディスプレーに表示して当該処理を中止する。これに対して、待機時間[di,j]≦dmaxであればステップＳ１８へ進み、図９(a)，(b)に一例を示したように、リクエストが先着順に処理されている旨を示す受付完了メッセージが端末ディスプレーに表示される。
【００５８】
ステップＳ１９では、配信を要求するコンテンツの識別子およびエンドサーバの識別子を含むコンテンツ要求がサービス要求として生成される。ステップＳ２０では、前記ステップＳ１３においてアクセス要求パスを送信してからの経過時間が前記待機時間[di,j]に達したか否かに基づいてアクセスタイミングであるか否かが判定され、アクセスタイミングを待ってステップＳ２１へ進む。ステップＳ２１では、前記ステップＳ１９で生成されたサービス要求（ここでは、コンテンツ配信要求）が、前記エンドサーバESjを宛先として送信される。このようなユーザ端末MNにおけるアクセスタイミングまでの待機処理は、Java(登録商標)scriptなどの各種スクリプト言語やFlash機能を利用することで実装できる。
【００５９】
このサービス要求を受信したエンドサーバESjは、要求されているコンテンツを用意して前記ユーザ端末MNへ配信する。
【００６０】
ユーザ端末MNは、前記コンテンツをステップＳ２２で受信すると、ステップＳ２３へ進んで当該コンテンツを保存する。ステップＳ２４では、図１０に一例を示したダウンロード完了メッセージが端末ディスプレーに表示される。
【００６１】
図８は、各エンドサーバESjの処理レートCjを動的に見直すサービス要求試行部１６およびサーバ能力計測部１７の動作を示したフローチャートである。
【００６２】
ステップＳ４９では、未だ処理負荷の低い監視対象のエンドサーバESjに対して、前記サービス要求試行部１６によりダミーのサービス要求が試行され、その応答が受信される。ステップＳ５０では、前記サーバ能力計測部１７により、前記試行されたサービス要求およびその応答に基づいて、試行された一つのサービス要求をエンドサーバESjが処理するのに要するサービス時間が計測され、これがエンドサーバESjの現在の実績処理レートCrealとされる。
【００６３】
図１１，１２，１３は、実績処理レートCrealの計測方法の一例を示したシーケンスフローであり、サービス要求およびサービス応答がTCPセッションを利用して行われる場合、SYN/FINパケット、HTTP METHOD、あるいはHTTPメッセージボディを監視することで実績処理レートCrealが求められる。
【００６４】
図１１は、サービス開始時刻およびサービス終了時刻をSYN/FINパケットに基づいて推定する方法を模式的に表現した図である。
【００６５】
TCPセッションは複数(N個)のTCPコネクションにより構成され、各TCPコネクションはアクセスパスサーバAPSから送信されるSYNパケットに対してエンドサーバESjがSYN-ACKを返信し、さらにアクセスパスサーバAPSからエンドサーバESjへACKパケットが送信されることにより確立される。そして、このようにして確立されたTCPコネクションは、アクセスパスサーバAPSおよびエンドサーバESjの双方がFIN-ACKを交換することで切断される。
【００６６】
そこで、本実施形態ではエンドサーバESjから送信された最初のSYN-ACKがアクセスパスサーバAPSで受信された時刻をサービス開始時刻とし、さらに、N回目のFIN-ACK交換においてアクセスパスサーバAPSからFIN-ACKが送信された時刻をサービス終了時刻とし、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
【００６７】
なお、前記TCPコネクション数（N個）はサービス内容に依存するので、アクセスパスサーバAPSは事前に各エンドサーバESjから各サービスのTCPコネクション数(N個)を取得しておくことが望ましい。
【００６８】
また、各TCPコネクションが同一のTCPセッションに係るものであるか否かは、例えば送信元IPアドレスおよびport番号が同一、かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断できる。あるいは、送信元端末固有のIDが同一かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断しても良い。
【００６９】
図１２は、実績処理レートCrealをHTTP METHODに基づいて推定する方法を模式的に表現した図である。この方法では、アクセスパスサーバAPSからHTTP METHOD（例えば、GET，POSTなど）が送信された時点でアクセスパスサーバAPSとエンドサーバESjとの間にTCPコネクションが確立されたものと判断し、当該時刻がサービス開始時刻とされる。
【００７０】
そして、N回目のFIN-ACK交換においてアクセスパスサーバAPSからFIN-ACKが送信された時刻がサービス終了時刻とされ、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
【００７１】
図１３は、実績処理レートCrealをHTTPメッセージボディに基づいて推定する方法を模式的に表現した図である。この方法では、セッション開始を意味する識別コード（たとえば、「start」などの文字列）の登録されているHTTPメッセージボディがアクセスパスサーバAPSから送信された時刻がサービス開始時刻とされる。
【００７２】
そして、セッション終了を意味する識別コード（たとえば、「finish」などの文字列）の登録されているHTTPメッセージボディがアクセスパスサーバAPSから送信された時刻がサービス終了時刻とされ、サービス開始時刻からサービス終了時刻までのセッション継続時間が実績処理レートCrealとされる。
【００７３】
図８へ戻り、ステップＳ５１では、前記ステップＳ５０で計測された現在の実績処理レートCrealが標準処理レートC1とされる。ステップＳ５２では、アクセスパスサーバAPSがエンドサーバESjの実績処理レートCrealを監視する周期Uに標準周期U1が設定される。ステップＳ５３では、監視周期Uの監視タイミングであるか否かが判定され、監視タイミングであればステップＳ５４へ進む。
【００７４】
ステップＳ５４では監視対象のエンドサーバESjに対して、前記サービス要求試行部１６によりダミーのサービス要求が試行され、その応答が受信される。ステップＳ５５では、前記試行されたサービス要求およびその応答に基づいて、前記と同様にエンドサーバESjの現在の実績処理レートCrealが計測される。本実施形態では、前記サービス要求の試行がエンドサーバESjにとって負荷とならないように前記標準周期U1が設定されている。
【００７５】
ステップＳ５６では、現在の実績処理レートCrealと標準処理レートC1との乖離が閾値Crefと比較される。エンドサーバESjの処理負荷が未だ低くければ乖離が閾値Cref以下となるので、現在の処理レートCjが適正と判定されてステップＳ５３へ戻り、現在の監視周期U(＝Uref)での監視が繰り返される。
【００７６】
これに対して、エンドサーバESjの処理負荷が上昇し、乖離が閾値Crefを上回るようになるとステップＳ５７へ進み、エンドサーバESjの監視周期Uが見直されて現在の標準監視周期U1よりも短い周期U2に変更される。図１４は、監視周期Uが変更される様子を模式的に示した図であり、時刻t1において乖離が大きいと判定されると、それ以降、監視周期UがU1からU2に短縮されている。
【００７７】
ステップＳ５８では、見直し後の短い監視周期U(＝U2)の監視タイミングであるか否かが判定され、監視タイミングであればステップＳ５９へ進む。ステップＳ５９では、監視対象のエンドサーバESjに対してダミーのサービス要求が試行され、その応答が受信される。ステップＳ６０では、前記試行されたサービス要求およびその応答に基づいて、前記と同様に現在の実績処理レートCrealが計測される。ステップＳ６１ではサービス要求の試行回数が判定され、n回の試行が繰り返されるまでステップＳ５８へ戻る。本実施形態では、前記監視周期U2もサービス要求の試行がエンドサーバESjにとって負荷とならない時間に設定されている。
【００７８】
その後、周期Uでのn回の試行が完了するとステップＳ６２へ進み、n回のサービス要求の試行で得られた実績処理レートCrealの平均値Cave（平均処理レート）が算出される。ステップＳ６３では、標準処理レートC1と前記平均処理レートCaveとが比較され、C1≒Cave であれば、現在の処理レートCjが適正と判定されてステップＳ５２へ戻り、監視周期Uを初期値1に戻して上記の処理が繰り返される。
【００７９】
これに対して、C1≒CaveでなければステップＳ６４へ進み、C1とCaveとの差分(C1−Cave)が相対的な乖離度として算出され、これを現在の処理レートCjから減じた値が新たな処理レートCjとされる。ステップＳ６５では、標準処理レートC1が平均処理レートCaveに更新され、その後、ステップＳ５２へ戻って上記の各処理が繰り返される。
【００８０】
なお、上記した実施形態では、ユーザ端末MNがコンテンツ配信用のアクセスパスを予め取得し、このアクセスパスによって許可されたアクセスタイミングでエンドサーバESjへコンテンツ要求を送信してコンテンツをダウンロードする場合を例にして説明したが、本発明はこれのみに限定されるものではなく、ユーザ端末がデータやコンテンツをエンドサーバESjへアップロードするためのアクセスパスを予め取得し、許可されたアクセスタイミングでアップロードを実行する場合にも同様に適用できる。
【符号の説明】
【００８１】
１…リクエスト応答部，２…リクエスト受付部，１１…リクエスト受信部，１２…サーバ処理管理部，１３…アクセスタイミング決定部，１４…アクセスパス応答生成部，１５…アクセスパス応答返信部，１６…サービス要求試行部，１７…サーバ能力計測部
【特許請求の範囲】
【請求項１】
ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付システムにおいて、
ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、
前記アクセスパスサーバが、
ユーザ端末からアクセスパス要求を受信するアクセスパス要求受信手段と、
受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定するアクセスタイミング決定手段と、
前記アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成手段と、
前記アクセスパス応答を要求元にユーザ端末へ返信するアクセスパス応答返信手段と、
エンドサーバへのサービス要求を試行するサービス要求試行手段と、
前記試行したサービス要求の実績処理レートを計測するサーバ能力計測手段と、
前記計測結果に基づいてエンドサーバの能力を見直す見直手段とを具備したことを特徴とするリクエスト受付システム。
【請求項２】
前記サービス要求試行手段は、第１の周期でサービス要求を試行した際の実績処理レートに基づいてサーバ能力を見直すか否かを決定し、エンドサーバの能力を見直す際は前記第１の周期よりも短い第２の周期でサービス要求を繰り返し試行し、
前記見直手段は、前記第２の周期でサービス要求を繰り返し試行して得られた複数回の処理レートに基づいてエンドサーバの能力を見直すことを特徴とする請求項１に記載のリクエスト受付システム。
【請求項３】
前記サーバ能力計測手段は、サービスの開始時刻から終了時刻までのサービス時間に基づいてエンドサーバの処理レートを計測することを特徴とする請求項１または２に記載のリクエスト受付システム。
【請求項４】
前記ユーザ端末が
アクセスパス要求をアクセスパスサーバへ送信する手段と、
アクセスパス応答を受信する手段と、
前記アクセスパス応答からアクセスタイミングを抽出する手段と、
前記アクセスタイミングを待ってサービス要求をエンドサーバへ送信する手段とを含むことを特徴とする請求項１ないし３のいずれかに記載のリクエスト受付システム。
【請求項５】
ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付方法において、
ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、
前記アクセスパスサーバが、
ユーザ端末からアクセスパス要求を受信する手順と、
受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定する手順と、
前記アクセスタイミングを含むアクセスパス応答を生成する手順と、
前記アクセスパス応答を要求元にユーザ端末へ返信する手順と、
エンドサーバへのサービス要求を試行する手順と、
前記試行したサービス要求の実績処理レートを計測する手順と、
前記計測結果に基づいてエンドサーバの能力を見直す手順とを具備したことを特徴とするリクエスト受付方法。
【請求項１】
ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付システムにおいて、
ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、
前記アクセスパスサーバが、
ユーザ端末からアクセスパス要求を受信するアクセスパス要求受信手段と、
受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定するアクセスタイミング決定手段と、
前記アクセスタイミングを含むアクセスパス応答を生成するアクセスパス応答生成手段と、
前記アクセスパス応答を要求元にユーザ端末へ返信するアクセスパス応答返信手段と、
エンドサーバへのサービス要求を試行するサービス要求試行手段と、
前記試行したサービス要求の実績処理レートを計測するサーバ能力計測手段と、
前記計測結果に基づいてエンドサーバの能力を見直す見直手段とを具備したことを特徴とするリクエスト受付システム。
【請求項２】
前記サービス要求試行手段は、第１の周期でサービス要求を試行した際の実績処理レートに基づいてサーバ能力を見直すか否かを決定し、エンドサーバの能力を見直す際は前記第１の周期よりも短い第２の周期でサービス要求を繰り返し試行し、
前記見直手段は、前記第２の周期でサービス要求を繰り返し試行して得られた複数回の処理レートに基づいてエンドサーバの能力を見直すことを特徴とする請求項１に記載のリクエスト受付システム。
【請求項３】
前記サーバ能力計測手段は、サービスの開始時刻から終了時刻までのサービス時間に基づいてエンドサーバの処理レートを計測することを特徴とする請求項１または２に記載のリクエスト受付システム。
【請求項４】
前記ユーザ端末が
アクセスパス要求をアクセスパスサーバへ送信する手段と、
アクセスパス応答を受信する手段と、
前記アクセスパス応答からアクセスタイミングを抽出する手段と、
前記アクセスタイミングを待ってサービス要求をエンドサーバへ送信する手段とを含むことを特徴とする請求項１ないし３のいずれかに記載のリクエスト受付システム。
【請求項５】
ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末に許可するエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信するリクエスト受付方法において、
ユーザ端末から受信したアクセスパス要求を受け付けてアクセスパス応答を返信するアクセスパスサーバを備え、
前記アクセスパスサーバが、
ユーザ端末からアクセスパス要求を受信する手順と、
受信したアクセスパス要求ごとに、エンドサーバの能力に基づいて、エンドサーバへのアクセスタイミングを決定する手順と、
前記アクセスタイミングを含むアクセスパス応答を生成する手順と、
前記アクセスパス応答を要求元にユーザ端末へ返信する手順と、
エンドサーバへのサービス要求を試行する手順と、
前記試行したサービス要求の実績処理レートを計測する手順と、
前記計測結果に基づいてエンドサーバの能力を見直す手順とを具備したことを特徴とするリクエスト受付方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１０−２２４８２１（Ｐ２０１０−２２４８２１Ａ）
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願番号】特願２００９−７０７９５（Ｐ２００９−７０７９５）
【出願日】平成２１年３月２３日（２００９．３．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２２年１０月７日（２０１０．１０．７）
【国際特許分類】
【出願日】平成２１年３月２３日（２００９．３．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]