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