サーバ連携互助システムならびにそのサーバおよびサーバ連携互助プログラム
【課題】ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバへのサービス要求を他のサーバが制限するシステムを提供する。
【解決手段】エンドサーバES#iが過負荷状態に陥ると近隣の他のエンドサーバESへ援助を依頼する。エンドサーバES#jが援助要請を受け容れると、エンドサーバES#i，ES#j間には互助関係が確立され、エンドサーバES#iは援助要請サーバとして動作し、エンドサーバES#jは援助提供サーバとして動作する。援助要請サーバES#iは、ユーザ端末から受信したサービス要求をエンドサーバES#jへ転送する。援助提供サーバES#jは、援助要請サーバES#iの動作をエミュレータで模擬し、援助要請サーバES#iから転送されたサービス要求の送信元に対して、エミュレータに基づいて算出された待機時間Tiの記述されたアクセスパス（整理券）を発行する。
【解決手段】エンドサーバES#iが過負荷状態に陥ると近隣の他のエンドサーバESへ援助を依頼する。エンドサーバES#jが援助要請を受け容れると、エンドサーバES#i，ES#j間には互助関係が確立され、エンドサーバES#iは援助要請サーバとして動作し、エンドサーバES#jは援助提供サーバとして動作する。援助要請サーバES#iは、ユーザ端末から受信したサービス要求をエンドサーバES#jへ転送する。援助提供サーバES#jは、援助要請サーバES#iの動作をエミュレータで模擬し、援助要請サーバES#iから転送されたサービス要求の送信元に対して、エミュレータに基づいて算出された待機時間Tiの記述されたアクセスパス（整理券）を発行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムならびにそのサーバおよびサーバ連携互助プログラムに関する。
【背景技術】
【０００２】
テレビやラジオ番組など特定のイベントを契機として、特定のサーバに対してユーザからのアクセスが短時間かつ集中的に発生する場合がある。このような特定のイベントを契機としたアクセス集中は、例えば音楽番組におけるCDの売り上げランキング発表直後あるいは番組中の視聴者プレゼントへの応募直後などに、視聴者が電話回線やインターネット等の通信回線を利用して一斉に特定のサーバにアクセスすることで生じることが多い。そして、短時間で集中的にアクセス量が増加すると、過負荷によりサーバの動作が不安定となり、さらにはシステムダウン等も起こり得る。
【０００３】
このような技術課題に対して、本発明の発明者等は、サーバの運用効率を同時接続セッション数の観点から最適化し、ユーザ端末の待機時間を短縮できるリクエスト受付システムを発明し、特許出願した（特許文献１）。
【０００４】
特許文献１では、図９にその概要を示したように、サービスを提供するサーバ（エンドサーバ）ESの前段に、制御情報を配信するためのアクセスパスサーバ(APS)が設置される。ユーザ端末は、サービス要求に先だってAPSへアクセスパス要求を送信する。APSは、各エンドサーバの混み具合を模擬する機能(エンドサーバエミュレータ)を備え、ユーザ端末からのアクセスパス要求に対して、前記エンドサーバエミュレータを利用して、各エンドサーバへのアクセスまでにユーザ端末が待機すべき時間をアプセスパスに記述してユーザ端末に通知する。ユーザ端末は、APSから通知された時間分だけ待機した後、エンドサーバESにサービス要求を送信する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−３０１０９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
APSは、ユーザ端末からのリクエストに対して待ち時間を算定し、この待ち時間の記載された整理券を発行して各ユーザ端末へ返信するだけなので、その処理はエンドサーバでのサービス提供に較べて低負荷であり、相当数のリクエストを処理できる。しかしながら、想定を超えるようなリクエストが集中してしまうと、APS自体が過負荷状態となってボトルネックとなる可能性がある。
【０００７】
本発明の目的は、上記した従来技術の課題を解決し、ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムならびにそのサーバおよびサーバ連携互助プログラムを提供することにある。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、本発明は、ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムならびにそのサーバおよびサーバ連携互助プログラムにおいて、以下のような要件を具備した点に特徴がある。
【０００９】
(1)各サーバが、他のサーバへ援助を要請する援助要請機能部および他のサーバへ援助を提供する援助提供機能部を具備すること。
【００１０】
(2)援助要請機能部が、サービス要求の処理負荷を判定する負荷判定手段と、処理負荷が高くなると他のサーバへ援助を要請する援助要請手段と、援助要請を受け容れたサーバへサービス要求を転送する転送手段とを具備すること。
【００１１】
(3)援助提供機能部が、他のサーバから送信された援助要請を受け付ける援助要請受付手段と、援助要請したサーバの動作をエミュレータで模擬する動作模擬手段と、援助要請したサーバから転送されたサービス要求について、エミュレータに基づいて再アクセスまでの待機時間を算出する手段と、待機時間の記述されたアクセスパスを、サービス要求を送信したユーザ端末へ送信するアクセスパス送信手段とを具備すること。
【発明の効果】
【００１２】
本発明によれば、以下のような効果が達成される。
【００１３】
(1)各サーバの輻輳状況を一元的に管理するためのサーバを別途に設けることなく、サーバ同士で自律的な輻輳制御が可能になる。
【００１４】
(2)能力に余裕のあるサーバが余裕の無いサーバを援助するので、限られたサーバ資源の有効利用が可能になる。
【図面の簡単な説明】
【００１５】
【図１】本発明のサーバ連携互助システムが適用されるサービス提供システムのブロック図である。
【図２】サーバ連携互助ネットワークに参加するエンドサーバESの機能ブロック図である。
【図３】援助要請するエンドサーバおよび援助提供するエンドサーバが互助関係を確立する動作を示したシーケンスフローである。
【図４】援助要請するエンドサーバおよび援助提供するエンドサーバが互助関係を確立する動作を示したフローチャートである。
【図５】援助要請するエンドサーバから各エンドサーバへ提供されるサーバパラメータの一例を示した図である。
【図６】各エンドサーバが所持する、援助要請が可能なサーバのリストの一例を示した図である。
【図７】援助要請するエンドサーバから援助提供するエンドサーバへ提供されるサーバパラメータの一例を示した図である。
【図８】援助要請するエンドサーバの動作を模擬するエミュレータの一例を示した図である。
【図９】従来技術の機能ブロック図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明のサーバ連携互助システムが適用されるサービス提供システムのネットワーク構成を示したブロック図であり、ここでは、ユーザ端末MNからエンドサーバES（サービス提供サーバ）へコンテンツ配信のサービスを要求する場合を例にして説明する。
【００１７】
携帯電話、PDAあるいはコンピュータなどのユーザ端末MNは、インターネット（図示せず）を経由してサーバ連携互助ネットワークに接続される。サーバ連携互助ネットワークは、ユーザ端末MNからのサービス要求に応答して、音楽や映像などのコンテンツを配信する複数のエンドサーバESにより構成され、各エンドサーバESは、それぞれ異なるサービスを提供する。各エンドサーバESは、ソフト配信サーバから専用ソフトウェア（サーバ連携互助プログラム）を取得して自身にインストールし、これを設定、起動することによりサーバ連携互助ネットワークに参加できる。各エンドサーバESは、同一の企業・団体により運営されていても良いし、それぞれ異なる企業・団体により運営されていても良い。
【００１８】
本実施形態では、例えばエンドサーバES#iへのサービス要求が集中して過負荷状態に陥ると、当該エンドサーバES#iが他のエンドサーバESへ援助を依頼する。エンドサーバES#jが援助要請を受け容れると、エンドサーバES#i，ES#j間には互助関係が確立され、これ以降、エンドサーバES#iは援助要請サーバとして動作し、エンドサーバES#jは援助提供サーバとして動作する。
【００１９】
以上のようにして互助関係が確立されると、援助要請サーバES#iは、ユーザ端末から受信したサービス要求をエンドサーバES#jへ転送する。援助提供サーバES#jは、援助要請サーバES#iの処理状況を模擬するエミュレータを構築し、ユーザ端末から受信したサービス要求を処理してサービスを提供する通常処理を継続しながら、前記援助要請サーバES#iから転送されたサービス要求の送信元MNに対して、前記エミュレータに基づいて算出された待機時間Tiの記述されたアクセスパス（整理券）を発行する。このアクセスパスを受信したユーザ端末MNは、前記待機時間Tiの経過後に前記援助要請サーバES#iへの再アクセスが許可される。
【００２０】
図２は、前記サーバ連携互助ネットワークに参加するエンドサーバESの主要部の構成を示した機能ブロック図である。本実施形態では、各エンドサーバESが固有のコンテンツファイルを具備し、サービス要求に応答してコンテンツファイルを送信するほか、前記専用ソフトウェア（サーバ連携互助プログラム）をインストールすることで、自身が過負荷状態となったときに他のサーバへ援助を要請して支援を受ける「援助要請サーバ」、他のサーバからの援助要請を受け容れて当該サーバへ援助を提供する「援助提供サーバ」のいずれかとしても同時に動作できる。
【００２１】
サービス要求処理部１０は、ユーザ端末から送信されたサービス要求を受信して受け付け、要求されたコンテンツファイルを提供するなどの通常のサービスを実行する。援助要請機能部２０は、前記援助要請サーバとしての機能を実行する。援助提供機能部３０は、前記援助提供サーバとしての機能を実行する
【００２２】
前記援助要請機能部２０において、負荷判定部２０１は、サービス要求の処理負荷を所定の閾値と比較し、処理負荷が閾値を超えると過負荷状態と判定する。援助要請部２０２は、前記処理負荷が閾値を超えて過負荷状態になると、他のエンドサーバESに対して援助を要請する。サービス要求転送部２０３は、前記援助要請を受け容れて援助提供サーバとして動作するエンドサーバESに対してサービス要求を転送する。
【００２３】
前記援助提供機能部３０において、援助要請受付部３０１は、過負荷状態に陥ったエンドサーバESから送信された援助要請を受け付けて、この援助要請を受け容れるか否かを判定し、その判定結果を応答する。動作模擬部３０２は、援助要請サーバの動作を模擬するエミュレータを構築し、このエミュレータ上で援助要請サーバの動作を模擬する。待機時間算出部３０３は、前記援助要請サーバから転送されたサービス要求について、前記エミュレータに基づいて再アクセスまでの待機時間Tを算出する。アクセスパス送信部３０４は、前記待機時間Tの記述されたアクセスパスを、前記サービス要求を送信したユーザ端末へ送信する。
【００２４】
図３は、アクセス集中により過負荷状態に陥って援助を要請するエンドサーバ（援助要請サーバ）、および援助要請サーバへ援助を提供するエンドサーバ（援助提供サーバ）が、協調して互助関係を確立する動作を示したシーケンスフローであり、図４は、各エンドサーバの動作をそれぞれ示したフローチャートである。
【００２５】
エンドサーバES#iにおいて、前記負荷判定部２０１により、サービス要求のアクセスが集中して過負荷状態となったことがステップＳ１で検知されると、ステップＳ２では、援助要請メッセージが、連携互助ネットワーク上の他の全てのエンドサーバES、あるいはエンドサーバES#iとのネットワーク距離やサーバスペックなどが所定の条件を満足する一部のエンドサーバESへ、前記援助要請部２０２により送信される。前記援助要請メッセージには、図５に一例を示したように、エンドサーバES#iの最大同時接続セッション数Smax,iおよびサービス時間の確率密度分布Pi、ならびに確率密度分布Piの具体的なパラメータである平均サービス時間diおよびサービス時間の標準偏差sdiなどが含まれる。また、前記援助要請の可能なエンドサーバESは、図６に一例を示したように、そのIPアドレスおよびポート番号のペアがリスト形式で予め取得されているものとする。
【００２６】
前記他のエンドサーバESでは、ステップＳ５１において前記援助要請メッセージが受信されるとステップＳ５２へ進む。ステップＳ５２では、前記援助要請受付部３０１により、自身の現時点での同時接続セッション数やCPU使用率などに基づいて、自身のサービス提供に支障をきたすことなく無く援助提供が可能であるか否かが判定される。この判定結果は、ステップＳ５３において援助応答メッセージに記述されてエンドサーバES#iへ返信される。
【００２７】
エンドサーバES#iでは、前記援助応答がステップＳ３で受信されるとステップＳ４へ進み、援助要請を受け容れ可能なエンドサーバESが、前記援助要請部２０２により援助提供サーバとして選択される。なお、援助要請を受け容れ可能なエンドサーバESが複数ある場合には、相手サーバへ要求するスペックや過去の実績などを考慮していずれか一つのエンドサーバESが選択される。すなわち、スペックのより高いサーバ、より多く援助を受け入れた実績のあるサーバほど優先的に選択される。ここでは、エンドサーバES#jが援助提供サーバとして選択されたものとして説明を続ける。
【００２８】
ステップＳ５では、前記選択されたエンドサーバES#jへ援助依頼メッセージが送信される。この援助依頼メッセージには、図７に一例を示したように、エンドサーバES#iの現時点での同時接続セッション数Siおよびサービス提供URLが記述される。なお、前記ステップＳ２で通知されるとしたサービス時間の確率密度分布Piならびにその具体的なパラメータである平均サービス時間diおよびサービス時間の標準偏差sdiについては、このタイミングで通知されるようにしても良い。
【００２９】
前記エンドサーバES#jは、ステップＳ５４において前記援助依頼メッセージを受信するとステップＳ５５へ進み、前記援助要請受付部３０１により援助承諾メッセージが返信される。この援助承諾メッセージが、ステップＳ６において前記エンドサーバES#iにより受信されると、エンドサーバES#i，ES#j間には互助関係が確立され、これ以降、エンドサーバES#iは援助要請サーバとして動作し、エンドサーバES#jは援助提供サーバとして動作することになる。援助提供サーバES#jでは、ステップＳ５６において、援助要請サーバES#iの動作を模擬するエミュレータが、前記動作模擬部３０２により構築される。エミュレータの具体的な構築方法については後述する。
【００３０】
援助要請サーバES#iは、ステップＳ７において、ユーザ端末からサービス要求メッセージ受信するとステップＳ８へ進む。ステップＳ８では、前記サービス要求メッセージが前記サービス要求転送部２０３により援助提供サーバES#jへ転送される。援助提供サーバES#jは、ステップＳ５７において前記メッセージを受信するとステップＳ５８へ進む。ステップＳ５８では、ユーザ端末に要求する待機時間Tiが、前記待機時間算出部３０３により算出される。この待機時間Tiの具体的な算出方法についても後述する。
【００３１】
ステップＳ５９では、前記エミュレータが更新される。ステップＳ６０では、前記待機時間Tiの算出結果および前記サービス提供URLの記述されたアクセスパスが、前記アクセスパス送信部３０４により前記ユーザ端末MNへ送信される。このような互助関係に基づく援助処理は、ステップＳ６１において互助関係の解除条件が成立したと判定されるまで繰り返される。
【００３２】
その後、援助提供サーバES#jへのサービス要求のアクセスが増えて、その負荷レベルが閾値を超えるか、あるいは援助要請サーバES#iの負荷レベルが十分に低下したことが、前記エミュレータによる推定結果から判明するなどし、ステップＳ６１において、互助関係の解除条件が成立したと判定されるとステップＳ６２へ進む。ステップＳ６２では、援助終了メッセージが援助要請サーバES#iへ送信される。
【００３３】
援助要請サーバES#iは、ステップＳ９において、前記援助終了メッセージが受信されるとステップＳ１０へ進み、援助提供サーバES#jとの互助関係を解除してステップＳ１へ戻る。したがって、この時点でエンドサーバES#iの負荷が依然として解消されていなければ上記の各処理が繰り返され、エンドサーバES#iは他のエンドサーバとの間に互助関係を確立して再び援助要請サーバES#iとして動作することになる。
【００３４】
次いで、前記エミュレータの構築方法および当該エミュレータを利用した待機時間Tiの算出方法について説明する。
【００３５】
図８は、援助提供サーバES#jに構築されるエミュレータの構成を模式的に表現した図であり、援助要請サーバES#iから通知された最大同時接続数がSmax,iであれば、Smax,i個の仮想FIFOキューFQi,k(k＝1,2…Smax,i)が用意され、そのうち、援助要請された時点での同時接続数Si分の仮想FIFOキューFQi,1〜FQi,Siにのみキューが蓄積される。各仮想FIFOキューFQi,1〜FQi,Siに蓄積されるキュー値（キュー長）は、援助要請サーバES#1から通知されたサービス時間に基づいて決定される。
【００３６】
ここでは、時刻tにおいてエンドサーバES#iから転送されたサービス要求を受け付ける直前および直後の各仮想FIFOキューFQi,kのキュー値を、それぞれFQi,k(t)−，FQi,k(t)＋と表現する。また、援助要請サーバES#iが一つのサービス要求を処理するのに要する時間（サービス時間）は、前記平均サービス時間diであるものとする。
【００３７】
時刻tnで援助要請サーバES#iからサービス要求が転送されると、援助提供サーバES#jでは、援助要請サーバES#iに関する全ての仮想FIFOキューFQi,kのキュー値FQi,k(tn)が次式(1)に基づいて更新される。
FQi,k(tn)−＝FQi,k(tn-1)＋−(tn−tn-1)／di …(1)
【００３８】
次に、全ての仮想FIFOキューFQi,kから、そのキュー値FQi,k(tn)−が最小のものが、次式(2)に基づいて選択される。
K＝argmin_k(FQi,k(tn)−) …(2)
【００３９】
上式(2)により選択されたKで識別される仮想FIFOキューFQi,Kのキュー値FQi,K(tn)−に基づいて、次式(3)により待機時間Ti,nが算出され、サービス要求の送信元へ通知される。
Ti,n＝FQi,k(tn)−×di …(3)
【００４０】
上記の待機時間Ti,nを算出した後、各仮想FIFOキューのキュー値が次式(4)、(5)により更新される。
FQi,k(tn)＋＝FQi,k(tn)−＋bn、 if k=K …(4)
FQi,k(tn)＋＝FQi,k(tn)− otherwise …(5)
【００４１】
前記bnは、要求されたサービスまたはコンテンツをユーザへ提供するために必要なサービス時間に応じて設定され重み値である。例えば、要求されたサービスの提供に要するサービス時間が平均サービス時間diと同等と推定されればbn＝１とされ、平均サービス時間diよりも長くなると予測されればbn＞１とされ、平均サービス時間diよりも短くなると予測されればbn＜１とされる。
【００４２】
ただし、一般には各エンドサーバESでのサービス時間を事前に正確に知ることはできないので、援助要請サーバES#iのサービス時間に関する前記確率密度分布Piに基づく乱数を発生させ、その乱数値Drandを今回のサービス時間diと見なし、次式によりbnを定めるようにしても良い。
bn＝Drand／di
【００４３】
援助提供サーバES#jは、援助要請サーバES#iからサービス要求を転送されるごとに上記の各処理を繰り返すことで、援助要請サーバES#iにおけるサービス要求の処理状況を仮想的に模擬でき、かつ援助要請サーバES#iにおける同時接続セッション数が所望の数以下となるように、前記待機時間Tiを各ユーザ端末に通知することが可能になる。
【符号の説明】
【００４４】
１０…サービス要求処理部，２０…援助要請機能部，３０…援助提供機能部，２０１…負荷判定部，２０２…援助要請部，２０３…サービス要求転送部，３０１…援助要請受付部，３０２…動作模擬部，３０３…待機時間算出部，３０４…アクセスパス送信部
【技術分野】
【０００１】
本発明は、ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムならびにそのサーバおよびサーバ連携互助プログラムに関する。
【背景技術】
【０００２】
テレビやラジオ番組など特定のイベントを契機として、特定のサーバに対してユーザからのアクセスが短時間かつ集中的に発生する場合がある。このような特定のイベントを契機としたアクセス集中は、例えば音楽番組におけるCDの売り上げランキング発表直後あるいは番組中の視聴者プレゼントへの応募直後などに、視聴者が電話回線やインターネット等の通信回線を利用して一斉に特定のサーバにアクセスすることで生じることが多い。そして、短時間で集中的にアクセス量が増加すると、過負荷によりサーバの動作が不安定となり、さらにはシステムダウン等も起こり得る。
【０００３】
このような技術課題に対して、本発明の発明者等は、サーバの運用効率を同時接続セッション数の観点から最適化し、ユーザ端末の待機時間を短縮できるリクエスト受付システムを発明し、特許出願した（特許文献１）。
【０００４】
特許文献１では、図９にその概要を示したように、サービスを提供するサーバ（エンドサーバ）ESの前段に、制御情報を配信するためのアクセスパスサーバ(APS)が設置される。ユーザ端末は、サービス要求に先だってAPSへアクセスパス要求を送信する。APSは、各エンドサーバの混み具合を模擬する機能(エンドサーバエミュレータ)を備え、ユーザ端末からのアクセスパス要求に対して、前記エンドサーバエミュレータを利用して、各エンドサーバへのアクセスまでにユーザ端末が待機すべき時間をアプセスパスに記述してユーザ端末に通知する。ユーザ端末は、APSから通知された時間分だけ待機した後、エンドサーバESにサービス要求を送信する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−３０１０９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
APSは、ユーザ端末からのリクエストに対して待ち時間を算定し、この待ち時間の記載された整理券を発行して各ユーザ端末へ返信するだけなので、その処理はエンドサーバでのサービス提供に較べて低負荷であり、相当数のリクエストを処理できる。しかしながら、想定を超えるようなリクエストが集中してしまうと、APS自体が過負荷状態となってボトルネックとなる可能性がある。
【０００７】
本発明の目的は、上記した従来技術の課題を解決し、ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムならびにそのサーバおよびサーバ連携互助プログラムを提供することにある。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、本発明は、ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムならびにそのサーバおよびサーバ連携互助プログラムにおいて、以下のような要件を具備した点に特徴がある。
【０００９】
(1)各サーバが、他のサーバへ援助を要請する援助要請機能部および他のサーバへ援助を提供する援助提供機能部を具備すること。
【００１０】
(2)援助要請機能部が、サービス要求の処理負荷を判定する負荷判定手段と、処理負荷が高くなると他のサーバへ援助を要請する援助要請手段と、援助要請を受け容れたサーバへサービス要求を転送する転送手段とを具備すること。
【００１１】
(3)援助提供機能部が、他のサーバから送信された援助要請を受け付ける援助要請受付手段と、援助要請したサーバの動作をエミュレータで模擬する動作模擬手段と、援助要請したサーバから転送されたサービス要求について、エミュレータに基づいて再アクセスまでの待機時間を算出する手段と、待機時間の記述されたアクセスパスを、サービス要求を送信したユーザ端末へ送信するアクセスパス送信手段とを具備すること。
【発明の効果】
【００１２】
本発明によれば、以下のような効果が達成される。
【００１３】
(1)各サーバの輻輳状況を一元的に管理するためのサーバを別途に設けることなく、サーバ同士で自律的な輻輳制御が可能になる。
【００１４】
(2)能力に余裕のあるサーバが余裕の無いサーバを援助するので、限られたサーバ資源の有効利用が可能になる。
【図面の簡単な説明】
【００１５】
【図１】本発明のサーバ連携互助システムが適用されるサービス提供システムのブロック図である。
【図２】サーバ連携互助ネットワークに参加するエンドサーバESの機能ブロック図である。
【図３】援助要請するエンドサーバおよび援助提供するエンドサーバが互助関係を確立する動作を示したシーケンスフローである。
【図４】援助要請するエンドサーバおよび援助提供するエンドサーバが互助関係を確立する動作を示したフローチャートである。
【図５】援助要請するエンドサーバから各エンドサーバへ提供されるサーバパラメータの一例を示した図である。
【図６】各エンドサーバが所持する、援助要請が可能なサーバのリストの一例を示した図である。
【図７】援助要請するエンドサーバから援助提供するエンドサーバへ提供されるサーバパラメータの一例を示した図である。
【図８】援助要請するエンドサーバの動作を模擬するエミュレータの一例を示した図である。
【図９】従来技術の機能ブロック図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は、本発明のサーバ連携互助システムが適用されるサービス提供システムのネットワーク構成を示したブロック図であり、ここでは、ユーザ端末MNからエンドサーバES（サービス提供サーバ）へコンテンツ配信のサービスを要求する場合を例にして説明する。
【００１７】
携帯電話、PDAあるいはコンピュータなどのユーザ端末MNは、インターネット（図示せず）を経由してサーバ連携互助ネットワークに接続される。サーバ連携互助ネットワークは、ユーザ端末MNからのサービス要求に応答して、音楽や映像などのコンテンツを配信する複数のエンドサーバESにより構成され、各エンドサーバESは、それぞれ異なるサービスを提供する。各エンドサーバESは、ソフト配信サーバから専用ソフトウェア（サーバ連携互助プログラム）を取得して自身にインストールし、これを設定、起動することによりサーバ連携互助ネットワークに参加できる。各エンドサーバESは、同一の企業・団体により運営されていても良いし、それぞれ異なる企業・団体により運営されていても良い。
【００１８】
本実施形態では、例えばエンドサーバES#iへのサービス要求が集中して過負荷状態に陥ると、当該エンドサーバES#iが他のエンドサーバESへ援助を依頼する。エンドサーバES#jが援助要請を受け容れると、エンドサーバES#i，ES#j間には互助関係が確立され、これ以降、エンドサーバES#iは援助要請サーバとして動作し、エンドサーバES#jは援助提供サーバとして動作する。
【００１９】
以上のようにして互助関係が確立されると、援助要請サーバES#iは、ユーザ端末から受信したサービス要求をエンドサーバES#jへ転送する。援助提供サーバES#jは、援助要請サーバES#iの処理状況を模擬するエミュレータを構築し、ユーザ端末から受信したサービス要求を処理してサービスを提供する通常処理を継続しながら、前記援助要請サーバES#iから転送されたサービス要求の送信元MNに対して、前記エミュレータに基づいて算出された待機時間Tiの記述されたアクセスパス（整理券）を発行する。このアクセスパスを受信したユーザ端末MNは、前記待機時間Tiの経過後に前記援助要請サーバES#iへの再アクセスが許可される。
【００２０】
図２は、前記サーバ連携互助ネットワークに参加するエンドサーバESの主要部の構成を示した機能ブロック図である。本実施形態では、各エンドサーバESが固有のコンテンツファイルを具備し、サービス要求に応答してコンテンツファイルを送信するほか、前記専用ソフトウェア（サーバ連携互助プログラム）をインストールすることで、自身が過負荷状態となったときに他のサーバへ援助を要請して支援を受ける「援助要請サーバ」、他のサーバからの援助要請を受け容れて当該サーバへ援助を提供する「援助提供サーバ」のいずれかとしても同時に動作できる。
【００２１】
サービス要求処理部１０は、ユーザ端末から送信されたサービス要求を受信して受け付け、要求されたコンテンツファイルを提供するなどの通常のサービスを実行する。援助要請機能部２０は、前記援助要請サーバとしての機能を実行する。援助提供機能部３０は、前記援助提供サーバとしての機能を実行する
【００２２】
前記援助要請機能部２０において、負荷判定部２０１は、サービス要求の処理負荷を所定の閾値と比較し、処理負荷が閾値を超えると過負荷状態と判定する。援助要請部２０２は、前記処理負荷が閾値を超えて過負荷状態になると、他のエンドサーバESに対して援助を要請する。サービス要求転送部２０３は、前記援助要請を受け容れて援助提供サーバとして動作するエンドサーバESに対してサービス要求を転送する。
【００２３】
前記援助提供機能部３０において、援助要請受付部３０１は、過負荷状態に陥ったエンドサーバESから送信された援助要請を受け付けて、この援助要請を受け容れるか否かを判定し、その判定結果を応答する。動作模擬部３０２は、援助要請サーバの動作を模擬するエミュレータを構築し、このエミュレータ上で援助要請サーバの動作を模擬する。待機時間算出部３０３は、前記援助要請サーバから転送されたサービス要求について、前記エミュレータに基づいて再アクセスまでの待機時間Tを算出する。アクセスパス送信部３０４は、前記待機時間Tの記述されたアクセスパスを、前記サービス要求を送信したユーザ端末へ送信する。
【００２４】
図３は、アクセス集中により過負荷状態に陥って援助を要請するエンドサーバ（援助要請サーバ）、および援助要請サーバへ援助を提供するエンドサーバ（援助提供サーバ）が、協調して互助関係を確立する動作を示したシーケンスフローであり、図４は、各エンドサーバの動作をそれぞれ示したフローチャートである。
【００２５】
エンドサーバES#iにおいて、前記負荷判定部２０１により、サービス要求のアクセスが集中して過負荷状態となったことがステップＳ１で検知されると、ステップＳ２では、援助要請メッセージが、連携互助ネットワーク上の他の全てのエンドサーバES、あるいはエンドサーバES#iとのネットワーク距離やサーバスペックなどが所定の条件を満足する一部のエンドサーバESへ、前記援助要請部２０２により送信される。前記援助要請メッセージには、図５に一例を示したように、エンドサーバES#iの最大同時接続セッション数Smax,iおよびサービス時間の確率密度分布Pi、ならびに確率密度分布Piの具体的なパラメータである平均サービス時間diおよびサービス時間の標準偏差sdiなどが含まれる。また、前記援助要請の可能なエンドサーバESは、図６に一例を示したように、そのIPアドレスおよびポート番号のペアがリスト形式で予め取得されているものとする。
【００２６】
前記他のエンドサーバESでは、ステップＳ５１において前記援助要請メッセージが受信されるとステップＳ５２へ進む。ステップＳ５２では、前記援助要請受付部３０１により、自身の現時点での同時接続セッション数やCPU使用率などに基づいて、自身のサービス提供に支障をきたすことなく無く援助提供が可能であるか否かが判定される。この判定結果は、ステップＳ５３において援助応答メッセージに記述されてエンドサーバES#iへ返信される。
【００２７】
エンドサーバES#iでは、前記援助応答がステップＳ３で受信されるとステップＳ４へ進み、援助要請を受け容れ可能なエンドサーバESが、前記援助要請部２０２により援助提供サーバとして選択される。なお、援助要請を受け容れ可能なエンドサーバESが複数ある場合には、相手サーバへ要求するスペックや過去の実績などを考慮していずれか一つのエンドサーバESが選択される。すなわち、スペックのより高いサーバ、より多く援助を受け入れた実績のあるサーバほど優先的に選択される。ここでは、エンドサーバES#jが援助提供サーバとして選択されたものとして説明を続ける。
【００２８】
ステップＳ５では、前記選択されたエンドサーバES#jへ援助依頼メッセージが送信される。この援助依頼メッセージには、図７に一例を示したように、エンドサーバES#iの現時点での同時接続セッション数Siおよびサービス提供URLが記述される。なお、前記ステップＳ２で通知されるとしたサービス時間の確率密度分布Piならびにその具体的なパラメータである平均サービス時間diおよびサービス時間の標準偏差sdiについては、このタイミングで通知されるようにしても良い。
【００２９】
前記エンドサーバES#jは、ステップＳ５４において前記援助依頼メッセージを受信するとステップＳ５５へ進み、前記援助要請受付部３０１により援助承諾メッセージが返信される。この援助承諾メッセージが、ステップＳ６において前記エンドサーバES#iにより受信されると、エンドサーバES#i，ES#j間には互助関係が確立され、これ以降、エンドサーバES#iは援助要請サーバとして動作し、エンドサーバES#jは援助提供サーバとして動作することになる。援助提供サーバES#jでは、ステップＳ５６において、援助要請サーバES#iの動作を模擬するエミュレータが、前記動作模擬部３０２により構築される。エミュレータの具体的な構築方法については後述する。
【００３０】
援助要請サーバES#iは、ステップＳ７において、ユーザ端末からサービス要求メッセージ受信するとステップＳ８へ進む。ステップＳ８では、前記サービス要求メッセージが前記サービス要求転送部２０３により援助提供サーバES#jへ転送される。援助提供サーバES#jは、ステップＳ５７において前記メッセージを受信するとステップＳ５８へ進む。ステップＳ５８では、ユーザ端末に要求する待機時間Tiが、前記待機時間算出部３０３により算出される。この待機時間Tiの具体的な算出方法についても後述する。
【００３１】
ステップＳ５９では、前記エミュレータが更新される。ステップＳ６０では、前記待機時間Tiの算出結果および前記サービス提供URLの記述されたアクセスパスが、前記アクセスパス送信部３０４により前記ユーザ端末MNへ送信される。このような互助関係に基づく援助処理は、ステップＳ６１において互助関係の解除条件が成立したと判定されるまで繰り返される。
【００３２】
その後、援助提供サーバES#jへのサービス要求のアクセスが増えて、その負荷レベルが閾値を超えるか、あるいは援助要請サーバES#iの負荷レベルが十分に低下したことが、前記エミュレータによる推定結果から判明するなどし、ステップＳ６１において、互助関係の解除条件が成立したと判定されるとステップＳ６２へ進む。ステップＳ６２では、援助終了メッセージが援助要請サーバES#iへ送信される。
【００３３】
援助要請サーバES#iは、ステップＳ９において、前記援助終了メッセージが受信されるとステップＳ１０へ進み、援助提供サーバES#jとの互助関係を解除してステップＳ１へ戻る。したがって、この時点でエンドサーバES#iの負荷が依然として解消されていなければ上記の各処理が繰り返され、エンドサーバES#iは他のエンドサーバとの間に互助関係を確立して再び援助要請サーバES#iとして動作することになる。
【００３４】
次いで、前記エミュレータの構築方法および当該エミュレータを利用した待機時間Tiの算出方法について説明する。
【００３５】
図８は、援助提供サーバES#jに構築されるエミュレータの構成を模式的に表現した図であり、援助要請サーバES#iから通知された最大同時接続数がSmax,iであれば、Smax,i個の仮想FIFOキューFQi,k(k＝1,2…Smax,i)が用意され、そのうち、援助要請された時点での同時接続数Si分の仮想FIFOキューFQi,1〜FQi,Siにのみキューが蓄積される。各仮想FIFOキューFQi,1〜FQi,Siに蓄積されるキュー値（キュー長）は、援助要請サーバES#1から通知されたサービス時間に基づいて決定される。
【００３６】
ここでは、時刻tにおいてエンドサーバES#iから転送されたサービス要求を受け付ける直前および直後の各仮想FIFOキューFQi,kのキュー値を、それぞれFQi,k(t)−，FQi,k(t)＋と表現する。また、援助要請サーバES#iが一つのサービス要求を処理するのに要する時間（サービス時間）は、前記平均サービス時間diであるものとする。
【００３７】
時刻tnで援助要請サーバES#iからサービス要求が転送されると、援助提供サーバES#jでは、援助要請サーバES#iに関する全ての仮想FIFOキューFQi,kのキュー値FQi,k(tn)が次式(1)に基づいて更新される。
FQi,k(tn)−＝FQi,k(tn-1)＋−(tn−tn-1)／di …(1)
【００３８】
次に、全ての仮想FIFOキューFQi,kから、そのキュー値FQi,k(tn)−が最小のものが、次式(2)に基づいて選択される。
K＝argmin_k(FQi,k(tn)−) …(2)
【００３９】
上式(2)により選択されたKで識別される仮想FIFOキューFQi,Kのキュー値FQi,K(tn)−に基づいて、次式(3)により待機時間Ti,nが算出され、サービス要求の送信元へ通知される。
Ti,n＝FQi,k(tn)−×di …(3)
【００４０】
上記の待機時間Ti,nを算出した後、各仮想FIFOキューのキュー値が次式(4)、(5)により更新される。
FQi,k(tn)＋＝FQi,k(tn)−＋bn、 if k=K …(4)
FQi,k(tn)＋＝FQi,k(tn)− otherwise …(5)
【００４１】
前記bnは、要求されたサービスまたはコンテンツをユーザへ提供するために必要なサービス時間に応じて設定され重み値である。例えば、要求されたサービスの提供に要するサービス時間が平均サービス時間diと同等と推定されればbn＝１とされ、平均サービス時間diよりも長くなると予測されればbn＞１とされ、平均サービス時間diよりも短くなると予測されればbn＜１とされる。
【００４２】
ただし、一般には各エンドサーバESでのサービス時間を事前に正確に知ることはできないので、援助要請サーバES#iのサービス時間に関する前記確率密度分布Piに基づく乱数を発生させ、その乱数値Drandを今回のサービス時間diと見なし、次式によりbnを定めるようにしても良い。
bn＝Drand／di
【００４３】
援助提供サーバES#jは、援助要請サーバES#iからサービス要求を転送されるごとに上記の各処理を繰り返すことで、援助要請サーバES#iにおけるサービス要求の処理状況を仮想的に模擬でき、かつ援助要請サーバES#iにおける同時接続セッション数が所望の数以下となるように、前記待機時間Tiを各ユーザ端末に通知することが可能になる。
【符号の説明】
【００４４】
１０…サービス要求処理部，２０…援助要請機能部，３０…援助提供機能部，２０１…負荷判定部，２０２…援助要請部，２０３…サービス要求転送部，３０１…援助要請受付部，３０２…動作模擬部，３０３…待機時間算出部，３０４…アクセスパス送信部
【特許請求の範囲】
【請求項１】
ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムにおいて、
各サーバが、他のサーバへ援助を要請する援助要請機能部および他のサーバへ援助を提供する援助提供機能部を具備し、
前記援助要請機能部が、
サービス要求の処理負荷を判定する負荷判定手段と
処理負荷が所定の閾値を超えると他のサーバへ援助を要請する援助要請手段と、
前記援助要請を受け容れたサーバへサービス要求を転送する転送手段とを具備し、
前記援助提供機能部が、
他のサーバから送信された援助要請を受け付ける援助要請受付手段と、
援助要請したサーバの動作をエミュレータで模擬する動作模擬手段と、
援助要請したサーバから転送されたサービス要求について、前記エミュレータに基づいて再アクセスまでの待機時間を算出する手段と、
前記待機時間の記述されたアクセスパスを、前記サービス要求を送信したユーザ端末へ送信するアクセスパス送信手段とを具備したことを特徴とするサーバ連携互助システム。
【請求項２】
前記援助要請に、当該援助を要請するサーバのパラメータが登録され、前記動作模擬手段は、前記パラメータに基づいて、前記援助要請したサーバの動作を模擬することを特徴とする請求項１に記載のサーバ連携互助システム。
【請求項３】
前記援助要請機能部が、援助を要請できるサーバのリストを有することを特徴とする請求項１に記載のサーバ連携互助システム。
【請求項４】
前記援助要請受付手段は、前記援助要請に対して、自サーバの負荷状態に基づいて援助提供が可能であるか否かを判定し、判定結果を返信することを特徴とする請求項１に記載のサーバ連携互助システム。
【請求項５】
前記援助要請手段は、前記援助要請に対して複数のサーバから援助提供が可能である旨の応答を受信すると、各サーバのスペックおよび過去の援助実績の少なくとも一方に基づいて、一つのサーバを援助提供サーバとして選択することを特徴とする請求項４に記載のサーバ連携互助システム。
【請求項６】
前記援助要請に登録されるパラメータが、援助要請するサーバの最大同時接続セッション数を含むことを特徴とする請求項２に記載のサーバ連携互助システム。
【請求項７】
前記援助要請に登録されるパラメータが、援助要請するサーバにおける平均サービス時間を含むことを特徴とする請求項２に記載のサーバ連携互助システム。
【請求項８】
前記援助要請に登録されるパラメータが、援助要請するサーバにおけるサービス時間の確率密度分布を含むことを特徴とする請求項２に記載のサーバ連携互助システム。
【請求項９】
ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムのサーバにおいて、
他のサーバへ援助を要請する援助要請機能部および他のサーバへ援助を提供する援助提供機能部を具備し、
前記援助要請機能部が、
サービス要求の処理負荷を判定する負荷判定手段と
処理負荷が所定の閾値を超えると他のサーバへ援助を要請する援助要請手段と、
前記援助要請を受け容れたサーバへサービス要求を転送する転送手段とを具備し、
前記援助提供機能部が、
他のサーバから送信された援助要請を受け付ける援助要請受付手段と、
援助要請したサーバの動作をエミュレータで模擬する動作模擬手段と、
援助要請したサーバから転送されたサービス要求について、前記エミュレータに基づいて再アクセスまでの待機時間を算出する手段と、
前記待機時間の記述されたアクセスパスを、前記サービス要求を送信したユーザ端末へ送信するアクセスパス送信手段とを具備したことを特徴とするサーバ連携互助システムのサーバ。
【請求項１０】
ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムの各サーバで実行されるサーバ連携互助プログラムにおいて、
各サーバに、他のサーバへ援助を要請する援助要請機能部および他のサーバへ援助を提供する援助提供機能部を提供し、
前記援助要請機能部には、
サービス要求の処理負荷を判定する処理と、
処理負荷が所定の閾値を超えると他のサーバへ援助を要請する処理と、
前記援助要請を受け容れたサーバへサービス要求を転送する処理とを実行させ、
前記援助提供機能部には、
他のサーバから送信された援助要請を受け付ける処理と、
援助要請したサーバの動作をエミュレータで模擬する処理と、
援助要請したサーバから転送されたサービス要求について、前記エミュレータに基づいて再アクセスまでの待機時間を算出する処理と、
前記待機時間の記述されたアクセスパスを、前記サービス要求を送信したユーザ端末へ送信する処理とを実行させることを特徴とするサーバ連携互助プログラム。
【請求項１】
ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムにおいて、
各サーバが、他のサーバへ援助を要請する援助要請機能部および他のサーバへ援助を提供する援助提供機能部を具備し、
前記援助要請機能部が、
サービス要求の処理負荷を判定する負荷判定手段と
処理負荷が所定の閾値を超えると他のサーバへ援助を要請する援助要請手段と、
前記援助要請を受け容れたサーバへサービス要求を転送する転送手段とを具備し、
前記援助提供機能部が、
他のサーバから送信された援助要請を受け付ける援助要請受付手段と、
援助要請したサーバの動作をエミュレータで模擬する動作模擬手段と、
援助要請したサーバから転送されたサービス要求について、前記エミュレータに基づいて再アクセスまでの待機時間を算出する手段と、
前記待機時間の記述されたアクセスパスを、前記サービス要求を送信したユーザ端末へ送信するアクセスパス送信手段とを具備したことを特徴とするサーバ連携互助システム。
【請求項２】
前記援助要請に、当該援助を要請するサーバのパラメータが登録され、前記動作模擬手段は、前記パラメータに基づいて、前記援助要請したサーバの動作を模擬することを特徴とする請求項１に記載のサーバ連携互助システム。
【請求項３】
前記援助要請機能部が、援助を要請できるサーバのリストを有することを特徴とする請求項１に記載のサーバ連携互助システム。
【請求項４】
前記援助要請受付手段は、前記援助要請に対して、自サーバの負荷状態に基づいて援助提供が可能であるか否かを判定し、判定結果を返信することを特徴とする請求項１に記載のサーバ連携互助システム。
【請求項５】
前記援助要請手段は、前記援助要請に対して複数のサーバから援助提供が可能である旨の応答を受信すると、各サーバのスペックおよび過去の援助実績の少なくとも一方に基づいて、一つのサーバを援助提供サーバとして選択することを特徴とする請求項４に記載のサーバ連携互助システム。
【請求項６】
前記援助要請に登録されるパラメータが、援助要請するサーバの最大同時接続セッション数を含むことを特徴とする請求項２に記載のサーバ連携互助システム。
【請求項７】
前記援助要請に登録されるパラメータが、援助要請するサーバにおける平均サービス時間を含むことを特徴とする請求項２に記載のサーバ連携互助システム。
【請求項８】
前記援助要請に登録されるパラメータが、援助要請するサーバにおけるサービス時間の確率密度分布を含むことを特徴とする請求項２に記載のサーバ連携互助システム。
【請求項９】
ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムのサーバにおいて、
他のサーバへ援助を要請する援助要請機能部および他のサーバへ援助を提供する援助提供機能部を具備し、
前記援助要請機能部が、
サービス要求の処理負荷を判定する負荷判定手段と
処理負荷が所定の閾値を超えると他のサーバへ援助を要請する援助要請手段と、
前記援助要請を受け容れたサーバへサービス要求を転送する転送手段とを具備し、
前記援助提供機能部が、
他のサーバから送信された援助要請を受け付ける援助要請受付手段と、
援助要請したサーバの動作をエミュレータで模擬する動作模擬手段と、
援助要請したサーバから転送されたサービス要求について、前記エミュレータに基づいて再アクセスまでの待機時間を算出する手段と、
前記待機時間の記述されたアクセスパスを、前記サービス要求を送信したユーザ端末へ送信するアクセスパス送信手段とを具備したことを特徴とするサーバ連携互助システムのサーバ。
【請求項１０】
ユーザ端末からの要求に応答してサービスを提供する複数のサーバが相互に連携し、負荷の高いサーバを他のサーバが援助するサーバ連携互助システムの各サーバで実行されるサーバ連携互助プログラムにおいて、
各サーバに、他のサーバへ援助を要請する援助要請機能部および他のサーバへ援助を提供する援助提供機能部を提供し、
前記援助要請機能部には、
サービス要求の処理負荷を判定する処理と、
処理負荷が所定の閾値を超えると他のサーバへ援助を要請する処理と、
前記援助要請を受け容れたサーバへサービス要求を転送する処理とを実行させ、
前記援助提供機能部には、
他のサーバから送信された援助要請を受け付ける処理と、
援助要請したサーバの動作をエミュレータで模擬する処理と、
援助要請したサーバから転送されたサービス要求について、前記エミュレータに基づいて再アクセスまでの待機時間を算出する処理と、
前記待機時間の記述されたアクセスパスを、前記サービス要求を送信したユーザ端末へ送信する処理とを実行させることを特徴とするサーバ連携互助プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１３−３７１０（Ｐ２０１３−３７１０Ａ）
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願番号】特願２０１１−１３２１６９（Ｐ２０１１−１３２１６９）
【出願日】平成２３年６月１４日（２０１１．６．１４）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願日】平成２３年６月１４日（２０１１．６．１４）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]