WO2007125942A1 - 負荷制御装置およびその方法 - Google Patents

Abstract

　サーバ（４）に送信済みであるがサーバ（４）からレスポンスが返されていない応答待ちリクエストの数を制限する。この制限を行うためには、応答待ちリクエスト数が閾値に達しているならば、受信したリクエストをバッファに一時蓄積し、応答待ちリクエスト数が閾値を下回るまでバッファからのリクエストの送信を待ち合わせる。また、サーバ（４）の実行状況を監視し、サーバ（４）のリクエストに対する応答時間が許容範囲内であるときには前記閾値を増加させ、当該応答時間が許容範囲を超える場合には前記閾値を減少させる。さらに、サーバ（４）と負荷制御装置（３）との間のＴＣＰコネクション同時接続数が応答待ちリクエスト数の閾値以下となるように負荷制御装置（３）とクライアント（１－１、・・・、１－ｎ）との間のＴＣＰコネクションを集約する。

Description

明 細 書

負荷制御装置およびその方法

技術分野

[0001] 本発明は、クライアントとサーバとの間に配置され、クライアントから受信したリクエス トをサーバに転送し、当該リクエストに対してサーノくから返却されるレスポンスをクライ アントに転送する装置に利用する。特に、リクエストのスケジューリングに関する。なお

、本明細書では、 Webサーバに着目して説明する力 必ずしも他のサーバへの本発 明の適用を制限するものではな 、。

背景技術

[0002] インターネットの普及に伴 、、ネットワークを介して様々なサービスを利用できるよう になっている。メール、ホームページの閲覧、検索、オンライン取引、 IP電話、ビデオ オンデマンドなどは、その一例である。これらのネットワークサービスは様々な形態で 提供し得るが、近年、クライアントとのインタフェースとして、 Webサーバの利用が主 流となっている。

[0003] Webサーバを用いたサービス (Webサービス）の基本的な仕組みは以下のとおりで ある。まず、クライアントが Webサーバに対して、取得したいコンテンツを識別する UR L(Uniform Resource Locator)を付与したリクエストを送信する。 Webサーバがリクエス トを受け取ると、リクエスト中の URLに対応するコンテンツをレスポンスとしてクライァ ントに送り返す。 Webサービスは、このリクエスト一レスポンスの繰り返しによって提供 される。

[0004] リクエスト レスポンスを転送する通信プロトコルとして、 HTTP(Hyper Text Transfe r Protocol)が用いられる。本明細書では、 Webサービスを行うサーバシステム全体を Webサーバ、また、 Webサーバ上で HTTPプロトコルを処理する機能を HTTPサー ノ 、リクエストに応じたコンテンツを生成する機能を Webアプリケーションと呼ぶ。

[0005] また、 Webサービスによって提供されるコンテンツとして映像や音声のストリーミング が盛んに利用されるようになっている。ストリーミングの基本的な仕組みは以下のとお りである。 [0006] まず、クライアントの Webブラウザは、ストリームコンテンツのメタファイルを Webサー ノくから取得する。メタファイルには、ストリームコンテンツの URLが記述される。同時 に、 Webブラウザは、メタファイルの拡張子に関連付けられたプレイヤ (ストリーム再生 用アプリケーション）を起動する。そして、 Webサーバから取得したメタファイルに示さ れる URLに基づき、プレイヤがストリーミングサーバに対し、ストリームコンテンツの送 信を要求する。最後に、ストリーミングサーバ力 プレイヤに対してストリーミングデー タを送信する。

[0007] ストリーミングでサーバは一般的に、ストリームコンテンツの再生制御に RTSP (Real Time Streaming Protocol)プロトコルを使用する。 RTSPプロトコルは HTTPプロトコ ルをベースとするプロトコルであり、クライアントとサーバとの間で、リクエストとリクエス トに対するレスポンスを送受信することによって、ストリームコンテンツを再生帘 U御する

[0008] RTSPのリクエストが使用できる主な制御メソッドとして、初期設定（SETUP)、再生

(PLAY)、停止（TEARDOWN)、などがある。 RTSPでは、同時に複数のストリーム を制御するため、セッションの概念を有する。すなわち、 RTSPでは、プレイヤが SET UPリクエストを送信してから、 TEARDOWNリクエストを送信してストリーミングが終 了するまでを一つのセッションとみなす。

[0009] そして、ストリームサーバは、 SETUPリクエストをプレイヤから受け取ると、一意のセ ッシヨン IDを発行する。セッション IDは、レスポンスに付与されてクライアントに通知さ れる。プレイヤが通知されたセッション IDを後続のリクエストに付与することで、ストリ ームサーバにおいて制御対象となるセッションを識別することができる。

[0010] Webサービスが普及するにつれて、サービスを快適に利用していくための課題も明 らかになりつつある。その課題の一つとして、サービス利用が集中した際の過剰トラヒ ックへの対応が挙げられる。

[0011] サービス利用の集中の例として、人気の高い銘柄の株やチケットの売買によるリク ェスト集中や、災害発生時の見舞呼などがある。また、悪意のあるクライアントによつ て、 F5アタックなどの無意味なリクエストが大量に送信される場合もある。これらの要 因によって、サーバにリクエストが過剰に送信されると、サーバのリクエスト処理性能 の低下が生じる。

[0012] リクエスト過剰時におけるサーバのリクエスト処理性能の低下要因は以下のとおりで ある。すなわち、第一に、サーバが処理しきれないリクエストの受信に伴う、割込み、 T

CPZIP処理といった入出力オーバヘッドが増加する。第二に、リクエストを処理する スレッドまたはプロセス数が増大し、スレッドまたはプロセスの切替え処理に要するォ ーバヘッドである文脈切替えオーバヘッドが顕在化する。第三に、クライアントにレス ポンスが返されるまでの応答時間が増加するため、応答を待ちきれないクライアント 力 Sリクエストを途中でキャンセルするようになる。これらの結果、サーバが混雑すれば するほど、サーバの処理性能が低下するという問題が生じる。

[0013] 図 1は、リクエスト過剰による Webサーバの処理性能の低下を示す実験結果である 。横軸に入力リクエストレートをとり、縦軸にスループットをとる。図 1では、ある Webサ ーバに対して、入力リクエストレート、すなわち、単位時間当りのリクエスト数 (rps)を 変化させてリクエストを送信する。そして、スループット、すなわち、 Webサーバが単 位時間当りに完了できたリクエスト数 (rps)を計測している。図 1に示されるように、入 力リクエストレートが一定範囲内であるならば、入力レートに対してスループットは比 例する（図 1直線 (a) )。し力しながら、 Webサーバの最大スループットに達すると、ス ループットが低下に転じる（図 1直線 (c) )。故に、 Webサーバの最大性能を超えるリ タエストを受信した場合でも、図 1破線 (b)にそって、 Webサーバの最大性能を維持 できる技術が必要といえる。参考のため、理想的なスループットの挙動を図 2に示す

[0014] 過剰トラヒックによるサーバ性能低下を防ぐため、サーバに送信されるリクエスト量を 予め制限する手法が提案されている。リクエスト量を制限する指標として、（a)TCPコ ネクシヨン数、（b)サーバ負荷状態、（c)帯域、（d)並列度などが用いられる。

[0015] (a) TCPコネクション数を用いる場合は、同時接続可能な TCPコネクション数の上限 を定めることによって、サーバの過負荷回避を試みる。 Apacheなどの汎用的な HTT Pサーバ、負荷分散システムなどで用いられる。し力しながら、リクエストの種類、クラ イアントの回線速度などによって、 TCPコネクション毎にその負荷が大きく異なる。こ のため、 TCPコネクション数の上限に達する前に、サーバが過負荷となったり、逆に、 サーバリソースが余っていても、 TCPコネクション数が上限に達していることによって 、新たな TCPコネクションを確立できない、といった問題が生じる。

[0016] (b)サーバの負荷状態を用いる場合は、 CPU占有率、メモリ使用量、応答時間など 力 サーバの負荷状態を推測し、過負荷力否かを判定し、過負荷と判定した場合は 、新規リクエストの転送、拒絶など、サーバの負荷を軽減させるためのトラヒック制御を 行う。しかし、過負荷と判定されて力 初めてトラヒック制御を行うため、一時的なサー バの性能低下が免れない。

[0017] (c)帯域を用いる場合は、シェーバーなどの帯域制御機能を用いて、サーバに到達 されるトラヒック量を制限する。し力しながら、帯域はサーバの負荷を正確に測る指標 とはならない。例えば、画像ファイルのダウンロードは、大きな帯域を占めるがサーバ に与える負荷は比較的小さい。故に、帯域制限によって、サーバのリソースを十分に 活用しつつ、過負荷を確実に回避することは難しい。

[0018] (d)並列度を用いる場合は、サーバが同時に実行するスレッドまたはプロセス数を制 限する。これにより、リクエストを処理するスレッドまたはプロセス数の増大に伴う文脈 切替えオーバヘッドを削減できる。

[0019] 並列度を制御する具体例として、ページ単位に並列度を制限するように、 HTTPサ ーバを拡張した文献 1 (松沼正浩、日比野秀章、佐藤芳榭、光来健一、千葉滋著、 " 過負荷時の Webアプリケーションの性能劣化を改善する Session— Level Queue Scheduling",第 2回ディペンダブルソフトウェアワークショップ（DSW， 05)、 pp. 1 05 - 114, 2005年 1月）がある。し力し、サーバ上で並列度を制御しても、リクエスト 処理性能低下の第一要因である、サーバが処理しきれないリクエストの受信に伴う、 割込み、 TCP/IP処理などのオーバヘッドを避けることができない。その結果、他の 手法と同様に、過剰トラヒック時におけるサーバの処理性能の低下が生じる。また、 H TTPサーバまたは Webアプリケーションの変更が必要になるため、既に運用中のサ 一ビスへの導入障壁が高 、と 、つた問題がある。

[0020] 並列度を制御するもう一つの例として、ストリーミングサーバのセッション数制限があ る。すなわち、ストリーミングサーバでは、同時に保持できるセッション数に上限を設 けることが一般的である。これにより、セッション数の増大に伴うサーバ過負荷を回避 する。

[0021] しかし、セッション数の制限は、 RTSPによる制御リクエストの受信までを制限するも のではない。このため、 RTSPリクエストがストリームサーバに集中すると、リクエストに 対する処理オーバヘッドが顕在化し、ストリームサーバの処理性能の低下が生じる、 という問題が生じる。

[0022] サーバの性能低下は、図 3 (a)に示すような、新規リクエストの受信によって、割り込 み、入出力、文脈切替オーバヘッドなどが増加することによって生じる。このようなォ ーバヘッドを取り除き、サーバの性能を最大限に発揮させるためには、図 3 (b)のよう に、サーバでの処理が完了した瞬間に次のリクエストが到着することが理想である。こ の場合は、サーバで処理しきれないリクエストの受信によるオーバヘッドがない。また 、処理完了力 次のリクエスト到着までの空き時間がサーバに生じない。

発明の開示

[0023] 本発明は、このような背景の下に行われたものであって、過剰リクエスト受信時にお けるサーバの性能低下を回避することができる負荷制御装置およびその方法を提供 することを目的とする。

[0024] 本発明の負荷制御装置は、クライアントとサーバとの間に配置され、両者のリクエス ト 'レスポンスの送受信を仲介する。すなわち、クライアントから受信したリクエストをサ ーバに送信し、さらにサーノくから返されるレスポンスをクライアントに送信する。このと き、本発明は、サーバに送信済みである力 サーノくからレスポンスが返されていない リクエスト、すなわち、応答待ちリクエストの数を制限する。この制限を行うためには、 応答待ちリクエスト数が閾値に達しているならば、受信したリクエストをバッファリングし 、応答待ちリクエスト数が閾値を下回るまで、リクエストの送信を待ち合わせる。

[0025] 本発明は、図 3 (b)の理想的なリクエストの到着を模擬するように、サーバのリクエス ト送信を制限する。説明を単純化するため、まず、応答待ちリクエスト数の閾値を" 1" とした場合を図 4 (a)に示す。図 3 (b)を模擬するには、まず、サーバでのスレッドの実 行完了を知る必要がある。本発明では、サーバでのスレッドの実行完了をサーノくから レスポンスの受信によって認識する。そして、先に送信したリクエストに対するレスボン スが返されて初めて、次のリクエストをサーバに送信する。本発明に基づけば、サー バが処理しきれないリクエストがサーバに送信されない。このため、リクエストの受信 処理に伴うサーバのオーバヘッドが削減される。

[0026] 図 4 (a)では、サーバがレスボスンスを返してから、負荷制御装置が次のリクエストを 送信するまでの間、サーバに空きが生じる。この問題を回避するため、本発明では、 応答待ちリクエスト数の閾値として、 "1"より大きい値を設定できる。図 4 (b)は応答待 ちリクエスト数の閾値を" 2"とした場合の実行例を示している。応答待ちリクエスト数を 複数とすることによって、サーバ上で実行可能状態にあるスレッド数が増加する。ある スレッドの実行が完了すると、次のスレッドの実行を即時に開始できるため、サーバの リソースに空きが生じ難くなる。さらに、本発明に基づけば、サーバの負荷を、サーバ の内部情報を参照することなぐサーバの外部力も制御できる。故に、既に稼働中の サーバに対して付加的な機能の追加または変更を行わないで、本発明を導入するこ とがでさる。

[0027] また、本発明に基づけば、応答待ちリクエスト数の閾値を自動調整できる。最適な 応答待ちリクエスト数の閾値は、サーバのシステム構成 (サーバ台数、 CPU数など）、 アプリケーションの実行時間などによって異なる。故に、応答待ちリクエスト数の閾値 を静的に設定する場合は、事前の性能評価が必要になるなど、負荷制御装置の管 理者に力かる負担が大きい。

[0028] 例えば、 CPU数が 2つであるサーバが同時に処理できるリクエスト数は、 CPU数が 1つであるサーバよりも多い。故に、サーバのスループットを最大化するためには、 C PU数が 2である場合の応答待ちリクエスト数の閾値は、 CPU数が 1である場合よりも 大きく設定することが必要である。

[0029] また、アプリケーションに着目すると、その実行時間が短いほど、負荷制御装置とサ ーバとの間の送信遅延が相対的に大きくなる。故に、実行時間が短いアプリケーショ ンほど、応答待ちリクエスト数の閾値を大きく設定し、送信遅延時間によるサーバ空き 時間を隠蔽できるようにする必要がある。

[0030] また、応答待ちリクエスト数の閾値が大きくなると、サーバ上で多重に処理されるリク エスト数も増加する。故に、閾値が大きくなり過ぎると、サーバでの文脈切替えオーバ ヘッドが増加し、スループット低下が生じる。さらに、負荷制御装置がサーバにリクェ ストを送信して力 レスポンスが返ってくるまでの応答時間が悪ィ匕する、といった問題 が生じる。

[0031] 故に、本発明では、サーバの応答時間またはスループットを計測し、その計測結果 に応じて応答待ちリクエスト数の閾値を自動調整する。これによりサーバのシステム 構成またはアプリケーションによらず、望ま 、応答時間およびスループットを得るこ とができる。その結果、応答待ちリクエストの閾値の設定に要する管理者の負担を軽 減することができる。

[0032] また、従来技術 a)で示したように、一般的に Webサーバでは、 TCPコネクションの 同時接続数に上限を設けている。しかし、 TCPコネクションの同時接続数に制限が 設けられると、応答待ちリクエスト数に基づく負荷制御が機能しなくなる場合がある。 この問題を解決するため、本発明では、応答待ちリクエスト数による負荷制御を、従 来技術の一つのコネクション集約と組み合わせて利用する。コネクション集約とは HT TP1. 1の Keep— Alive機能を利用し、負荷制御装置とサーバとの間で張られた TC Pコネクションを複数のクライアントで共有する技術である。

[0033] コネクション集約を用いない場合には、現在接続中のクライアント数を超えた数の T CPコネクション力 負荷制御装置とサーバとの間で接続される。したがって、リクエス トの送信頻度が低 、クライアントが多数接続を試みて 、る場合などにぉ 、て、応答待 ちリクエスト数の閾値を超える前にサーバの TCPコネクション接続数が上限に達する 可能性がある。その結果、サーバの計算リソースを活用するために十分な量のリクェ ストをサーバに供給できなくなる。これに対し、コネクション集約を用いる場合には、負 荷制御装置側で、 TCPコネクション数が応答待ちリクエスト数の閾値を超えな 、よう に調整できる。すなわち、サーバの TCPコネクションの同時接続数の上限が応答待 ちリクエスト数の閾値より大きい限り、 TCPコネクション同時接続数の制限が無効化さ れる。

[0034] すなわち、本発明は、クライアントとサーバとの間に配置され、前記クライアントから 受信したリクエストを前記サーバに送信し、当該リクエストに対して前記サーノから返 されるレスポンスを前記クライアントに送信する負荷制御装置である。

[0035] ここで、本発明の特徴とするところは、前記サーバに送信済みであるが前記サーバ 力もレスポンスが返されていない応答待ちリクエストの数を制限する手段を備え、この 制限する手段は、応答待ちリクエスト数が閾値に達しているならば、受信したリクエス トを一時蓄積するバッファと、応答待ちリクエスト数が閾値を下回るまで前記バッファ 力ものリクエストの送信を待ち合わせる手段とを備えたところにある。例えば、前記閾 値は" 1"よりも大きい値とする。

[0036] また、前記サーバの実行状況を監視する手段と、この監視する手段の監視結果に 基づいて前記サーバのリクエストに対する応答時間が許容範囲内であるときには前 記応答待ちリクエスト数の閾値を増加させ、当該応答時間が許容範囲を超える場合 には前記応答待ちリクエスト数の閾値を減少させる手段とを備えることが望ましい。

[0037] あるいは、前記サーバの実行状況を監視する手段と、この監視する手段の監視結 果に基づ 、て単位時間あたりにサーバが処理したリクエスト数であるスループットを 応答待ちリクエスト数の閾値毎に測定する手段と、現在の閾値に対するスループット が現在の閾値より小さい閾値に対するスループットを上回る場合には閾値を増加さ せ、現在の閾値に対するスループットが現在の閾値より小さい閾値のスループットを 下回る場合には閾値を減少させる手段とを備えることが望ましい。

[0038] また、このときには、応答待ちリクエスト数がその閾値に達している力否かを判定す る手段と、閾値に達している場合に、閾値を増加または減少させる力否かを判定する 手段とを備えることにより、サーバに負荷が十分に力かっていない状態において、応 答待ちリクエスト数の閾値が無制限に増カロしてしまう問題を解消することができる。

[0039] また、前記サーバと自己との間の TCPコネクション同時接続数が前記応答待ちリク ェスト数の閾値以下となるように自己と前記クライアントとの間の TCPコネクションを集 約する手段を備えることが望まし 、。

[0040] また、前記バッファは、送信元クライアントの識別情報に基づきリクエストを優先制御 する手段を備えることができる。

[0041] あるいは、前記バッファは、リクエスト中の特定の位置または範囲に特定のパターン が含まれる力否かに基づきリクエストを優先制御する手段を備えることができる。

[0042] あるいは、前記バッファは、リクエスト中の特定の変数が予め設定した閾値より大き いか否かに基づきリクエストを優先制御する手段を備えることができる。 [0043] あるいは、前記バッファは、リクエストが暗号ィ匕されている力否かに基づきリクエスト を優先制御する手段を備えることができる。

[0044] あるいは、前記バッファは、所定時間以上蓄積されたリクエストに対して、ビジーメッ セージを通知する手段を備えることができる。

[0045] あるいは、前記サーバは Webサーバであり、前記バッファは、リクエストのページ表 示の表示優先度に基づきリクエストを優先制御する手段を備えることができる。

[0046] あるいは、前記リクエストは TCPコネクションによってクライアントから負荷制御装置 に送信され、前記バッファは、クライアントと負荷制御装置との間に接続された他の T

CPコネクションの有無または TCPコネクションの数および当該リクエストが TCPコネク シヨンの最初のリクエストである力否かに基づきリクエストを優先制御する手段を備え ることがでさる。

[0047] あるいは、レスポンスにブラウザが自動取得すべきページ構成要素の URLが指し 示されて!/ヽる場合に、レスポンス送信先の識別情報と当該 URLとの組を一時的に記 憶する手段を備え、前記バッファは、リクエストの送信元の識別情報と URLとの組が 、一時記憶されたレスポンス送信先の識別情報と URLとの組と一致するカゝ否かに基 づきリクエストを優先制御する手段を備えることができる。

[0048] あるいは、前記リクエストが属するセッションの進行状況に基づきリクエストを優先制 御する手段を備えることができる。

[0049] あるいは、前記サーバで処理されたリクエストが属するセッションのセッション識別情 報を一定期間キャッシュする手段と、キャッシュされているセッション識別情報を持つ か否かに基づきリクエストを優先制御する手段を備えることができる。

[0050] あるいは、前記バッファは、クライアントから送信されたトラヒックの不正アクセスの疑 わしさに基づきリクエストを優先制御する手段を備えることができる。

[0051] 本発明を、プログラムとしてみることもできる。すなわち、本発明は、汎用の情報処 理装置にインストールすることにより、その汎用の情報処理装置に、本発明の負荷制 御装置の機能に相応する機能を実現させるプログラムである。

[0052] また、本発明を、記録媒体としてみることもできる。すなわち、本発明は、本発明の プログラムが記録された記録媒体である。本発明のプログラムは本発明の記録媒体 に記録されることにより、汎用の前記情報処理装置は、この記録媒体を用いて本発 明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持 するサーノからネットワークを介して直接汎用の前記情報処理装置に本発明のプロ グラムをインストールすることもできる。

[0053] これにより、汎用の情報処理装置を用いて、本発明の負荷制御装置を実現すること ができる。

[0054] また、本発明を、本発明の負荷制御装置が実行する負荷制御方法の発明としてみ ることができる。すなわち、本発明は、前記サーバに送信済みであるが前記サーバか らレスポンスが返されて 、な 、応答待ちリクエストの数を制限するステップを有し、こ の制限するステップは、応答待ちリクエスト数が閾値に達しているならば、受信したリ タエストをバッファに一時蓄積するステップと、応答待ちリクエスト数が閾値を下回るま で前記バッファ力ものリクエストの送信を待ち合わせるステップとを有することを特徴と する負荷制御方法である。例えば、前記閾値は" 1"よりも大きな値とする。

[0055] また、前記サーバの実行状況を監視するステップと、この監視するステップの監視 結果に基づいて前記サーバのリクエストに対する応答時間が許容範囲内であるとき には前記応答待ちリクエスト数の閾値を増加させ、当該応答時間が許容範囲を超え る場合には前記応答待ちリクエスト数の閾値を減少させるステップとを有することが望 ましい。

[0056] あるいは、前記サーバの実行状況を監視するステップと、この監視するステップの 監視結果に基づ 、て単位時間あたりにサーバが処理したリクエスト数であるスループ ットを応答待ちリクエスト数の閾値毎に測定するステップと、現在の閾値に対するスル 一プットが現在の閾値より小さい閾値に対するスループットを上回る場合には閾値を 増加させ、現在の閾値に対するスループットが現在の閾値より小さい閾値のスループ ットを下回る場合には閾値を減少させるステップとを有することが望ましい。

[0057] また、このときには、応答待ちリクエスト数がその閾値に達している力否かを判定す るステップと、閾値に達している場合に、閾値を増加または減少させるカゝ否かを判定 するステップとを有することが望ま 、。

[0058] また、前記サーバと自己との間の TCPコネクション同時接続数が前記応答待ちリク ェスト数の閾値以下となるように自己と前記クライアントとの間の TCPコネクションを集 約するステップを有することが望まし 、。

[0059] 本発明によれば、過剰リクエスト受信時におけるサーバの性能低下を回避すること ができる。この際に、適切な制御のための閾値の設定も自動化することができるため 、装置管理者の負担を軽減させることができる。

図面の簡単な説明

[0060] [図 1]過剰リクエストによるサーバの処理性能低下を説明するための図。

[図 2]理想的なスループットの挙動を示す図。

[図 3]過剰リクエスト時のサーバの振る舞いおよび理想的なサーバへのリクエストの到 着の状態を示す図。

[図 4]本発明によるサーバへのリクエストの到着の状態を示す図。

[図 5]第一の実施形態の全体構成図。

[図 6]第一の実施形態の負荷制御装置の処理手順を示すフローチャート。

[図 7]第一の実施形態のリクエスト受信処理の実行手順を示すフローチャート。

[図 8]第一の実施形態のレスポンス受信処理の実行手順を示すフローチャート。

[図 9]RTSPリクエストのメソッド名に基づくクラス分類の一例を示す図。

[図 10]第二の実施形態の負荷制御装置のブロック構成図。

[図 11]第二の実施形態のリクエスト受信部の処理手順を示すフローチャート。

[図 12]リクエスト表を示す図。

[図 13]第二の実施形態のリクエスト送信部の処理手順を示すフローチャート。

[図 14]サーバ側ソケット表を示す図。

[図 15]第二の実施形態のレスポンス受信部の処理手順を示すフローチャート。

[図 16]第二の実施形態のレスポンス送信部の処理手順を示すフローチャート。

[図 17]第二の実施形態のスケジューリング部の処理手順を示すフローチャート。

[図 18]本発明の効果を実証する実験の構成を示す図。

[図 19]実験のためのサーバおよび負荷制御装置の構成表を示す図。

[図 20]本発明の効果を示す図。

[図 21]本発明の応答待ちリクエスト数の閾値を自動調整することの効果を実証する実 験のためのサーバおよび負荷制御装置の構成表を示す図。

[図 22]応答待ちリクエスト数の閾値の設定値に対するスループットの変化を示す図。

[図 23]本発明の応答待ちリクエスト数の閾値を自動調整することの効果を示す図。

[図 24]本発明のリクエストの優先制御をすることの効果を示す図。

発明を実施するための最良の形態

[0061] (第一の実施形態）

本発明の第一の実施形態について図面を参照して説明する。

[0062] 図 5は、本発明の第一の実施形態を示すブロック図である。本発明は、リクエストを 発行するクライアント 1—1〜l—nと、リクエストに対応するレスポンスを返すサーバ 4 、および、リクエストおよびレスポンスを仲介する負荷制御装置 3とからなる。なお、サ ーバ 4は、 Apacheなどのソフトウェアモジュールであってもよぐ負荷制御装置 3とは C PUやメモリなどの物理リソースが独立であるハードウェアモジュールであってもよい。 また、本負荷制御装置 3を 2つ以上のサーバ 4に接続し、 1つの負荷制御装置 3で、 複数のサーバ 4に対して負荷制御をしてもよい。さらに、負荷制御装置 3は、リバース Proxy, Webァクセラレータ、 Firewall,負荷分散システムなどの既存技術を拡張し て実装してもよい。負荷制御装置 3にて、サーバ 4に送信済みであるが、まだ、レスポ ンスが返されていないリクエスト数、すなわち応答待ちリクエスト数を監視する。応答 待ちリクエスト数が定められた閾値を超える場合は、受信したリクエストをバッファリン グする。そして、応答待ちリクエスト数が閾値を下回るまで、リクエストの送信を見合わ せる。

[0063] 図 6に、負荷制御装置 3の処理手順を示す。実行が開始されると負荷制御装置 3は 、まず、メッセージを受信するまで待ち合せる（Sl)。ここで、負荷制御装置が受信す るメッセージは、リクエストまたはレスポンスの 2種類のみとする。メッセージを受信する と（S2)、そのメッセージがリクエストである場合はリクエスト受信処理を起動し (S3)、 レスポンスである場合はレスポンス受信処理を起動する（S4)。

[0064] リクエスト受信処理の実行手順を図 7に示す。リクエストを受信した場合に、負荷制 御装置 3はそのリクエストをバッファに格納する（S10)。次に、応答待ちリクエスト数が 閾値未満であるか否かを判定する（S 11)。なお、本実施形態では、応答待ちリクエス ト数の閾値は、任意の値が静的に与えられているものとする。閾値以上である場合は

(S 11)、サーノ へのリクエストの送信を見合せ、本処理を終了する。閾値未満の場 合は（S11)、 ノ ッファ力もリクエストを一つ選択して取り出す (S12)。次に、応答待ち リクエスト数を 1インクリメントさせた後（S13)、サーバ 4にリクエストを送信する（S14)

[0065] 次に、レスポンス受信処理の実行手順を図 8に示す。まず、受信したレスポンスを、 当該レスポンスのリクエストを送信したクライアントに対して返送する（S20)。次に、応 答待ちリクエスト数を 1デクリメントする（S21)。そして、ノッファ中に送信待ちリクエス トが存在する力否かを判定する（S22)。リクエストが存在しない場合は（S22)、当該 処理を終了する。リクエストが存在する場合は（S22)、リクエスト受信処理と同様に、リ タエストの送信を試みる。すなわち、応答待ちリクエスト数が閾値未満であるか否かを 判定する（S23)。閾値以上の場合は（S23)、サーバ 4へのリクエストの送信を見合せ 、本処理を終了する。閾値未満の場合は（S23)、ノ ッファからリクエストを一つ選択し て取り出す (S24)。次に、応答待ちリクエスト数を 1インクリメントさせた後（S25)、サ ーバ 4にリクエストを送信する（S26)。

[0066] このように、応答待ちリクエスト数が閾値を超える場合には、リクエストの送信を見合 わせることで、サーバ 4に過剰なリクエストが送信されなくなる。また、閾値を超える場 合はリクエストをバッファ中に蓄えることで、瞬時的なリクエスト量の増減を吸収するこ とができる。この結果、サーバ 4に対して安定してリクエストを供給することができる。

[0067] バッファ中のリクエストの実行順序をスケジューリングするアルゴリズムとして単一の キューを用いて FIFO(First- In First- Out)に基づきリクエストを処理することができる。 また、複数のキューを用いてリクエストの重要度や要求品質に応じて優先制御を実施 することもできる。この場合は、リクエストは一定のルールに基づき分類され、その結 果に応じて優先制御のパラメータ（例えば、優先度、重み、タイムアウト時間）などが 設定される。ここで、一定のルールに基づき分類された結果生じるリクエストの集合を クラスと定義する。そしてクラス別にリクエストをキューに格納し、各キュー間のリクエス ト取り出し順序を優先制御パラメータに基づきスケジューリングする。このスケジユーリ ングアルゴリズムとして、例えば、最も優先度が高いクラスに属するリクエストから処理 する Priority Queuing、クラス毎の重みに基づきレート制御する Waited Fair Q ueuing、 Waited Round Robinなど、既存の優先スケジューリングアルゴリズムを 利用できる。また、キューの代わりとして、タイムアウトするまでの時間長が昇順となる ようにリクエストを並べる、 EDF(Earliest Deadline First)を用いることができる。リクエス トの優先制御を行うことで、重要なリクエストや時間制約が厳し 、リクエストを優先的に サーノ で処理させることが可能になる。

[0068] また、ノ ッファにリクエストを格納する際に、ノ ッファ中のリクエスト数が格納可能な 最大数に達している場合がある。この場合は、ノ ッファ中のいずれかのリクエストを選 択し、以下のいずれかを実行する。

[0069] ·廃棄:リクエストを廃棄する。

[0070] ·拒絶：サーノ へのリクエスト送信を取りやめる。そして、負荷制御装置 3からビジー メッセージなどをクライアント 1— 1〜1— nに送信する。リクエストの廃棄と異なり、リク ェストが失敗した原因がリクエスト集中であることをクライアント 1— 1〜1—nに明示で きる。

[0071] ·転送:過負荷時用の待機サーバにリクエストを転送する。これにより、負荷が集中し ているサーバ 4に代わって、待機サーバが当該リクエストを処理できる。

[0072] また、ノ ッファ中の各リクエストにタイムアウトを設定することもできる。タイムアウトに 達したリクエストを検出した場合にも、バッファ中のリクエスト数が格納可能な最大数 に達した場合と同様の処理を実施できる。

[0073] リクエストの優先制御を実施する場合には、リクエストを一定ルールに基づきクラス に分類し、クラス毎に設定された優先度、重み、タイムアウト時間などのパラメータに 基づきスケジューリングする。 Webサービスを効果的に提供するためには、以下に示 すルールに基づき、リクエストが属するクラスを分類すればよい。なお、これらの実施 例の 、ずれかのみを用いることも、複数の実施例を組み合わせてクラスを分類するこ とも可能である。

[0074] 'クライアント識別情報に基づくクラス分類

•リクエストの内容に基づくクラス分類

•暗号ィ匕の有無に基づくクラス分類 'ページ処理の進行状況に基づくクラス分類

•セッション処理の進行状況に基づくクラス分類

•不正の疑わしさに基づくクラス分類

(クライアント識別情報に基づくクラス分類）

リクエストの送信元クライアントに応じてクラス分類する。以下に実施例を示す。

[0075] '送信元 IPアドレスに基づくクラス分類：リクエストを送信するプロトコルとして TCPZI Pを用いる場合には、クライアントを送信元 IPアドレスカゝら識別できる。故に、送信元 I Pアドレスに基づ 、てキューを選択することで、特定のクライアントからのリクエストを優 先化または非優先化することができる。

[0076] 例えば、負荷制御装置に管理者のホストの IPアドレスを予め登録しておく。次に、 負荷制御装置がリクエストを受信すると、登録されて 、るホストからのリクエストである ならば高優先なクラスに格納する。これにより、管理者によるサーバへのアクセスを保 護することができる。

[0077] 'User— Agentフィールドに基づくクラス分類：サーバが Webサーバである場合は、 クライアントは HTTPプロトコルに基づきリクエストのヘッダに User— Agentフィール ドを含めることができる。

[0078] User— Agentフィールドには、リクエストを発行したクライアントアプリケーションの 情報が格納される。故に、負荷制御装置において、受信したリクエストの User— Age ntの種類に応じてクラスに分類することで、当該 Webサービス専用のブラウザを利用 するクライアントからのリクエストを優先化したり、また、検索ロボットなどによって機械 的に発行されたリクエストを非優先化したりすることができる。

[0079] 'ユーザ IDに基づくクラス分類: Webサーバは、クライアントを識別するため、クライア ントに応じてユーザ IDを発行し、クライアントに発行したユーザ IDを HTTPリクエスト 中に含ませるように指示できる。このユーザ IDは、 Cookieフィールド、 URLのクエリ、 リクエストのボディにユーザ IDを含ませることができる。したがって、負荷制御装置に お!、て、予め優先化 (または非優先化）した 、クライアントのユーザ IDを登録しておく 。次に、 HTTPリクエストに含まれるユーザ IDと登録されているユーザ IDとが一致す る力否かに応じてクラスを選択する。これにより、例えば、追加料金を払っているクライ アントからのリクエストを優先化したり、逆に、ブラックリストに載っているクライアントか らのリクエストを非優先化させたりできる。

[0080] (リクエストの内容に基づくクラス分類）

リクエスト中のヘッダまたはコンテンツの任意の位置（HTTPリクエストである場合は 、例えばリクエスト行、各フィールドなど）に任意のパターンと一致するか否力、リクェ スト中の任意の変数が閾値を超えているか否かに応じて、リクエストを格納するクラス を選択する。 HTTPプロトコルを用いた場合の実施例を以下に列挙する。なお、以下 の実施例ではパターンを""中に正規表現で記述して!/、る。

[0081] 'メソッドに基づくクラス分類: HTTPでは、リソースに対する操作内容に応じて、複数 のメソッドが用意される。例えば、リソースの取得には GETメソッドが利用され、サーバ へのデータ送信には、 POSTメソッドが用いられる。オンラインショッピングや個人情 報の更新などの重要な処理では、ユーザが入力した情報をサーバに送信することが 必要となるため、 GETメソッドではなく POSTメソッドが用いられる。ここで、 HTTPで は、メソッド名はリクエスト中のリクエスト行で指定する。故に、リクエスト行のメソッド名 がパターン" POST"と一致するリクエストを高優先なクラスに分類することで、重要度 が高 、リクエストを優先処理することができる。

[0082] 'ファイルの種別に基づくクラス分類：動的コンテンツのような負荷が高 、処理へのリク エストを非優先化した 、場合がある。動的コンテンツであるか静的コンテンツであるか は、リクエストされるファイル名力も識別できる。例えば、動的コンテンツとして CGIを 用いる場合は、そのリクエストするファイル名の接尾語は. cgiとなる。故に、 CGIを非 優先化する場合は、リクエストの URLがパターン". cgi"と一致するファイルへのリク エストを低優先なクラスに分類すればよい。

[0083] 'ファイルサイズに基づくクラス分類：非常に大き 、サイズのファイルのアップロードを 試みるようなリクエストを非優先化した ヽ場合は、 HTTPヘッダのリクエストサイズを表 す Content— Lengthフィールドの値に閾値を設定し、閾値を超えるリクエストの低優 先なクラスに分類すればよい。

[0084] (暗号化の有無に基づくクラス分類）

リクエストが暗号ィ匕されているカゝ否かに応じて、リクエストのクラスを選択する。一般 的に、暗号ィ匕して送信されたリクエストは、暗号ィ匕しないで送信されたリクエストより重 要な情報が含まれる。そこで、暗号化されているリクエストを、高優先なクラスに分類 することで、重要リクエストを保護できる。例えば、 Webサービスでは、リクエストの送 信方法として、暗号ィ匕しない HTTP通信、暗号ィ匕する HTTPS通信のいずれかを選 択できる。

[0085] このとき、 HTTP通信、 HTTPS通信であるかは、 TCPコネクションの接続先ポート 番号によって識別できる。故に、暗号化されたリクエストを優先化する場合は、 HTTP S通信用のポートに接続する TCPコネクション力 送信されたリクエストを高優先なク ラスに分類すればよい。

[0086] (ページ処理の進行状況に基づくクラス分類）

Webサービスでは、クライアントのブラウザが 1ページを表示するまでに複数のリク ェストが必要となる場合がある。 1つのページを表示するためのリクエストの繰り返しを 、本明細書ではページ処理と呼ぶ。ページ処理の基本的な進行手順は以下のとおり である。まず、クライアントはブラウザに対して取得したいページのルートとなるリソー ス（以下、ページルートリソース）の URLを入力する。次に、ブラウザは、入力された U RLに基づき、 Webサーバに対してリクエストを送信し、ページルートリソースを取得 する。

[0087] このとき、ページルートリソースにはページ表示に必要となる他のリソースの URLが 指し示される。次に、ブラウザは、指し示される URLに対して自動的にリクエストを発 行する。以上を、ページ表示に必要な全リソースを取得するまで再帰的に繰り返す。 ページ処理の進行に基づくクラス分類の実施例を以下に示す。

[0088] 'URLに基づくクラス分類：ページの表示には不可欠なリソースに対するリクエストを 優先処理することで、サーバ混雑時において、必要最小限のページ構成でより多く のクライアントにサービスを提供することができる。例えば、 Webサーバにおいて、ぺ ージ表示に不可欠なリソースとそうでないリソースとを Webサーバの異なるディレクトリ に保管しておく。そして、負荷制御装置において、前述した「リクエストの内容に基づ くクラス分類」を用いて、ページ表示に不可欠なリソースが保管されるディレクトリの配 下のリソースに対するリクエストを優先度が高いクラスに分類すればよい。 [0089] ·ページルートリソースへのリクエストであるか否かに基づくクラス分類：ページルートリ ソースへのリクエストを低優先なクラスに分類することで、既に継続中のページ処理を 優先的に処理する。これにより、サーバ混雑時にページ処理中のリクエストが途中失 敗し、クライアントのブラウザ上に不完全なページが表示される、という問題を解消で きる。特に、ノッファ中のリクエストをスケジューリングするアルゴリズムとして前述した Priority Queuingを用いる場合には、ページ処理中のリクエストがバッファにある 限り、ページルートリソースへのリクエストが処理されない。故に、サーバ混雑時に新 規ページ処理の開始を効果的にブロッキングすることができる。

[0090] ページルートリソースへのリクエストを低優先化するための手法は以下のとおりであ る。

[0091] 'TCPコネクションの最初のリクエストであるか否力 ： HTTP1. 1では、 1つの TCPコ ネクシヨンで複数のリクエスト 'レスポンスを送受信することができる。このため、ページ 表示のためブラウザが自動的にリクエストを送信する場合には、通常、ページルートリ ソースへの取得に用いられた TCPコネクションが再利用される。

[0092] したがって、 TCPコネクションが接続されてから 2つ目以降のリクエストを高優先なク ラスに分類することで、継続中のページ処理を保護することができる。また、ブラウザ が同じサーバに対して複数のコネクションを接続し、ページ表示に必要なリソースを 複数コネクションで並列に受信することもできる。故に、 TCPコネクションが接続され て力も最初のリクエストであっても、同一のクライアントから既にサーバ（または負荷制 御装置）に接続された TCPコネクションが存在するならば、そのリクエストを例外的に 高優先なクラスに分類してもよい。

[0093] 負荷制御装置における具体的な実行手順は以下のとおりである。

[0094] 1)サーノ からレスポンスを受信すると、返送先となるクライアントの識別情報を表 (クラ イアント識別情報表）に追加する。既に、表中に当該クライアントの識別情報が存在 する場合は、当該ステップを省略してよい。

[0095] 2)リクエストを受信すると、クライアント識別情報表を参照する。

[0096] 3)表中に当該リクエストの送信元であるクライアントの識別情報がある場合は、当該リ タエストを高優先なクラスに分類する。一方で、表中にない場合は、当該リクエストを 低優先なクラスに分類する。

[0097] 4)同一クライアントから接続される TCPコネクションが全て切断されると、そのクライァ ントの識別情報をクライアント識別情報表力 削除する。

[0098] ·ページルートリソースの URLの登録：予めページルートリソースの URLの一覧表を 負荷制御装置に登録しておく。そして、前述した「リクエストの内容に基づくクラス分 類」を用いてクラスを分類する。すなわち、負荷制御装置は、リクエストを受け取ると、 まず、リクエストの URLと表中の URLとを比較する。そして、当該リクエストの URLが ページルートリソースの URLと一致するならば、当該リクエストを低優先なクラスに分 類する。

[0099] 'URLのキャッシュ：サーバから返送されたレスポンス中にブラウザが自動的に取得 すべきリソースの URLが指し示されて!/、た場合は、その URLを一定時間キャッシュし 、当該 URLに対するリクエストを優先化する。 HTTPプロトコルでは、 HTMLファイル の Srcタグになどによって、ブラウザが自動的に取得すべき URLが指し示される。し たがって、負荷制御装置における実行手順は以下のようになる。

[0100] 1)レスポンスのファイルタイプが HTMLファイルである場合は、コンテンツ中にパター ン "Src = "と一致する文字列を検索する。

[0101] 2)パターン" Src = "と一致する文字列が存在する場合は、次に、ノターン" Src = " に続く URLを抽出する。

[0102] 3)抽出した URLとレスポンス送信先のクライアント識別情報との組を一定期間キヤッ シュする。

[0103] 4)前述した「送信元クライアント識別情報に基づくクラス分類」「リクエストの内容に基 づくクラス分類」を併用して、キャッシュされているクライアントからキャッシュされてい る URLに対するリクエストを受け取った場合に、そのリクエストを高優先なクラスに分 類する。

[0104] (セッション処理の進行状況に基づくクラス分類）

Webサービスでは、複数ページに跨がって閲覧または情報入力することで、初めて 1つのサービスが完了する場合がある。例えば、オンラインショッピングでは、購入す べき商品の選択あるいはクライアント情報の入力などをし、最後に購入内容の確認を することで、初めて購入手続きが完了する。本明細書では、完了までに複数ページを 要するサービスにおいて、クライアントが先頭ページを取得して力 最後のページを 取得完了するまでをセッションと呼ぶ。

[0105] セッションは、金品や取引や、個人情報の更新など、重要な処理を行う場合に用い られる。しかし、サーバが混雑すると、セッションがほとんど完了しなくなる、という問題 がある。これは、サーバ上で並列処理されるセッションの数が増加すると、セッション 間でサーノ リソースが競合し、途中失敗するセッションが増加するためである。したが つて、負荷制御装置において、サーバ混雑時においても高いセッションスループット を維持できるよう、リクエストが属するセッションの進行状況に基づきクラスを分類する

[0106] セッション処理を行う場合には、 Webサーバは、受信したリクエストがどのセッション に属するかを識別する必要がある。このため、セッション処理では、セッション IDなど のセッション識別情報が用いられる。例えば、 Webサーバは、セッションの先頭ぺー ジに対するリクエストを受け取ると、セッション毎に一意なセッション IDを発行し、レス ポンスと共にクライアントに返送する。典型的な Webサーバでは、セッション IDを HT TPレスポンスの Set— Cookieフィールドに格納する。次に、クライアントはサーバか ら通知されたセッション IDをリクエストに含めてサーバに送信する。このときセッション I Dは、セッション IDがレスポンスの Set— Cookieフィールドによって通知された場合 に、リクエストの Cookieフィールドに格納される。 Webサーバは、リクエスト中のセッシ ヨン IDによって、そのリクエストが属するセッションを識別できる。

[0107] また、前述したように、ストリーミングサーバで用いられる RTSPは、セッションの概念 を標準で備えている。すなわち、 SETUPリクエストによってセッションが開始されると 、セッション IDが発行され、以降のリクエスト 'レスポンスに付与される。 RTSPでは、 セッション IDを RTSPヘッダの Sessionフィールドに格納する。

[0108] 本実施例の負荷制御装置では、まず、リクエスト中のセッション IDをキーとして、当 該リクエストが属するセッションの進行状況を評価する。例えば、既に開始済みのセッ シヨンに属するリクエストを一律に優先化する場合は、 HTTPプロトコルならばリクエス ト中の Cookieフィールドなどを、 RTSPプロトコルならばリクエスト中の Sessionフィー ルドの有無を検査し、セッション IDがリクエストに含まれるか否かを判定する。そして、 セッション IDを含むリクエストを高優先なクラスに分類する。これにより、開始済みセッ シヨンを優先的にサーバで処理することができる。特に、ノッファ中のリクエストをスケ ジユーリングするアルゴリズムとして前述した Priority Queuingを用いる場合には、 継続中の開始済みセッションに属するリクエストがバッファにある限り、新規セッション の開始を要求するリクエストが処理されない。故に、サーバ混雑時に新規セッション 処理の開始を効果的にブロッキングすることができる。

[0109] さらに、悪意のあるクライアントによる不正なセッション ID使用を回避するため、セッ シヨン IDの有効性を検証することもできる。負荷制御装置における実行手順を示す。

[0110] 1)サーバからのレスポンスを検査し、 HTTPプロトコルならば Set— Cookieフィール ドなどを、 RTSPプロトコルならば Sessionフィールドを調べ、セッション IDが新しく発 行されて!ヽるカゝ否かを判定する。

[0111] 2)新しくセッション IDが発行されている場合は、当該セッション IDを一定期間、キヤッ シュする。

[0112] 3)負荷制御装置が受け取ったリクエストにセッション IDが含まれている力否かを検証 する。

[0113] 4)リクエストにセッション IDが含まれている場合は、キャッシュしたセッション IDのいず れかと一致するか否か検証する。

[0114] 5)いずれのセッション IDとも一致しない場合は、当該リクエストのセッション IDは無効 であり、当該リクエストを高優先なクラスに分類する必要はない。

[0115] なお、キャッシュからセッション IDが漏れることへの対策として、リクエストが持つセッ シヨン IDがキャッシュに存在しなかった場合、サーバにてそのリクエストが処理された 時点で、そのリクエストが持っていたセッション IDをキャッシュに再登録してもよい。

[0116] キャッシュするセッション識別情報として、リクエストの送信元 IPアドレス、ユーザ ID などのクライアント識別情報を用いてもよい。例えば、セッション IDの代わりとして、サ ーバでリクエストが処理されたクライアントの IPアドレスをキャッシュしておくことで、送 信元 IPアドレス単位で開始済みセッションを優先化する。本手法の実施例を以下に 示す。 [0117] 1)負荷制御装置がサーノから受け取ったレスポンスの送信先クライアントの IPァドレ スを、一定期間、キャッシュする。

[0118] 2)負荷制御装置が受け取ったリクエストの送信元 IPアドレス力 キャッシュしているセ ッシヨン IDのいずれかと一致するか否か検証する。一致する場合は、サーバでの処 理開始が承認されているクライアントからのリクエストとみなし、当該リクエストを高優先 なクラスに分類する。

[0119] セッション IDを用いる場合と比較すると、本手法では優先化する必要がないセッシ ヨンまで優先化する可能性がある、という欠点がある。例えば、複数のクライアントが同 じ Proxyを介して負荷制御装置にアクセスする場合に、負荷制御装置が受け取るリク ェストの送信元 IPアドレスは、全て Proxyの IPアドレスとなる。

[0120] このため、同じ Proxyにアクセスしているクライアントのいずれかで処理が開始され て ヽる場合には、他のクライアントからのリクエストも全て高優先なクラスに分類される ことになる。一方で、送信元 IPアドレスを用いることの利点として、計算コストが小さい こと、設定が容易であること、が挙げられる。

[0121] セッション識別情報のキャッシュを、前述したページ処理の進行状況に基づくクラス 分類における「ページルートリソースへのリクエストであるか否かに基づくクラス分類」 にも応用できる。すなわち、ページ処理は、 1ページで完結する特殊なセッション処 理とみなせる。ゆえに、セッション識別情報をキャッシュしておく期間を、 1つのページ 処理の完了に要する時間（典型的には数秒）に制限する。これにより、クライアントが 新しいページにアクセスする前に、キャッシュ中のセッション識別情報が消去される。 その結果、新しいページのページルートリソースへのリクエストは、キャッシュにセッシ ヨン識別情報が存在しないため、低優先なクラスに分類される。そして、そのページル 一トリソースへのリクエストがサーバで処理された時点で、セッション識別情報をキヤッ シュに再登録することで、ページ表示に必要な残りのリソースへのリクエストを高優先 なクラスに分類することができる。

[0122] セッションの進行状況を、セッション IDではなぐリクエストの URLに基づいて評価 してもよい。例えば、 Webサーバにおいて、セッションを構成する各ページのリソース を、予めページ毎に異なるディレクトリに保管しておく。これにより、リクエストの URL に示されるディレクトリによって、リクエストが要求するリソースが属するページを識別 できる。したがって、負荷制御装置において、前述した「リクエストの内容に基づくクラ ス分類」を用いることで、リクエストを、要求されたリソースが属するページ毎にクラス分 類できる。このとき、セッション開始に近いページほど、その優先度を低く設定してお

<o

[0123] サーバが、 RTSPに基づくストリーミングサーバである場合は、セッションの進行状 況を、リクエストのメソッドに基づいて評価してもよい。前述したように、 RTSPでは、ス トリームの制御内容に応じ、 SETUP, PLAY, TEARDOWNなどのメソッドが用意 されている。これらのメソッドは、セッション確立以前に用いられるもの、セッション確立 後に用いられるものに分類できる。

[0124] したがって、セッション確立後に使用されるメソッドのリクエストを、優先度が高いクラ スに分類することで、確立済みのセッションを優先化することが可能となる。図 9に、 R TSPで使用されるメソッドとその分類先クラスの設定例を示す。

[0125] (不正アクセスの疑わしさに基づくクラス分類）

悪意のあるクライアントによる不正アクセスによってサーバの計算リソースが占有さ れることがある。この問題を回避するため、本実施例の負荷制御装置に、不正ァクセ スが疑われるトラヒックを検知する侵入検知機能を併用し、不正アクセスの可能性が 高いと判定されたリクエストを優先度が低いクラスに分類してもよい。さらに、「クライア ント識別情報に基づくクラス分類」と連携し、不正アクセスの可能性が高いと判定され たトラヒックを送信したクライアントを一定期間非優先化することもできる。すなわち、 1)負荷制御装置において、受信中のトラヒックが不正アクセスである可能性を評価す る。

[0126] 2)不正アクセスの可能性が高 ヽと判定されたトラヒックの送信元識別情報を一定期 間記録する。

[0127] 3)リクエストを受け取ると、そのクライアントの識別情報が記録された識別情報と一致 するか判定する。

[0128] 4)一致する場合は、低優先クラスに分類する。

[0129] また、侵入検知機能は、負荷制御装置と既存の侵入検知装置 (IDS:Intru_Si_0nDicti on System)などと接続することで、負荷制御装置の外部装置として実現してもよい。こ の場合は、侵入検知装置から負荷制御装置に、不正アクセスに関する情報、すなわ ち、不正アクセスの種類や送信元となるクライアント識別情報をァラートとし送信する 。負荷制御装置にてァラートに基づき、リクエストの優先制御を実施する。

[0130] このように、不正アクセスが疑われるリクエストを低優先クラスに分類することで、サ ーバ混雑時に、正常である可能性が高いリクエストから優先的に処理することが可能 である。同様の不正アクセスを規制する装置として侵入防御システムがある。侵入防 御システムでは、不正アクセスと判定されたトラヒックを即時的に廃棄する。このため、 正常なリクエストを誤って不正と判定することによって、正常リクエストを誤って規制す る、誤規制の問題がある。しかし、本発明では、サーバが混雑しない限り、不正が疑 われるリクエストもサーバ上で処理されるため、侵入防御システムにおける誤規制の 問題を緩和できる。

[0131] 第一実施例では、応答待ちリクエスト数の閾値を静的に与えている。しかし、前述し たように、人手による応答待ちリクエスト数の閾値設定は、負荷制御装置 3の管理者 に大きな負担をかける。そこで、第一実施例を拡張し、 a)サーバ 4の処理性能を最大 限に引き出すことができ、かつ b)応答時間が許容範囲に収まるように、応答待ちリク ェスト数の閾値を動的に設定できるようにする。

[0132] 応答待ちリクエスト数の閾値を自動調整するための実施例を列挙する。

[0133] (自動調整の実施例 1)

ノ ッファで待機している（平均）リクエスト数 N、および、負荷制御装置 3がリクエスト をサーバ 4に送信してからレスポンスを受け取るまでの（平均)応答時間 Tを定期的に 測定する。また、 N、 Tに対する閾値として、 LN、 LTを定めておく。このとき、 N<LN ならば、リクエスト量が少ないため、応答待ちリクエスト数がその閾値に達していないと みなす。また、 T<LTならば、良好な応答が返ってきているとみなす。故に、 •T≥LTならば、応答待ちリクエスト数の閾値を減少させる。

[0134] -T<LT

N≥LNならば、応答待ちリクエスト数の閾値を増加させる。

[0135] N<LNならば、応答待ちリクエスト数の閾値を変化させない。 [0136] (自動調整の実施例 2)

ノ ッファで待機している（平均）リクエスト数 N、および、負荷制御装置 3がリクエスト をサーバ 4に返信してからレスポンスを受け取るまでの応答時間 Tを定期的に測定す る。また、 N、 Tに対する閾値として、 LN、 LTを定めておく。さらに、 T>LTとなったリ タエストの割合を する。このとき、定数 k (0≤k≤l)を用いて、

• r≥ kならば、応答待ちリタエスト数の閾値を減少させる。

[0137] -r< k

N≥LNならば、応答待ちリクエスト数の閾値を増加させる。

[0138] N<LNならば、応答待ちリクエスト数の閾値を変化させない。

[0139] (自動調整の実施例 3)

ノ ッファで待機している（平均）リクエスト数 N、および、サーノ の CPU使用率 Uを 定期的に測定する。また、 N、 Lに対する閾値として、 LN、 LUを定めておく。

[0140] ·υ≥ΙΑΙならば、応答待ちリクエスト数の閾値を減少させる。

[0141] -U<LU

N≥LNならば、応答待ちリクエスト数の閾値を増加させる。

[0142] N<LNならば、応答待ちリクエスト数の閾値を変化させない。

[0143] CPU使用率のみでなぐメモリ使用率、帯域、並列度を監視し、その最大値を Uと してちよい。

[0144] (自動調整の実施例 4)

定期的にバッファで待機している（平均）リクエスト数 N、および、サーバ 4が単位時 間あたりに処理できたリクエスト数であるスループット Tを測定する。また、現在の応答 待ちリクエスト数の閾値を Rとする。また、応答待ちリクエスト数の閾値 R毎にスループ ットを記録できるようにする。

[0145] ここで、応答待ちリクエスト数の閾値 Rに対するスループットを T[R]と表記する。ま た、ノ ッファ中のリクエスト数 Nに対する閾値として、 LNを定めておく。このとき、測定 された Nおよび Tに応じて、以下を実施する。

[0146] 1) Nく LNならば、応答待ちリクエスト数が閾値に達していないことを意味する。故に

、応答待ちリクエスト数の閾値を更新しないで終了する。 N≥LNならば、 2)を実施す る。

[0147] 2)現在の応答待ちリクエスト数の閾値に対するスループット T[R]を、 Tを用いて更新 する。次に 3)を実施する。

[0148] 3)現在の応答待ちリクエスト数の閾値 Rに対するスループット T[R]と、閾値がより小 さい場合のスループット T[R' ] (R， <R)とを比較する。

[0149] A)T[R]≥kl XT[R，]の場合:応答待ちリクエスト数の閾値の増加によって、スルー プットの向上が得られていることを意味する。故に、さらに応答待ちリクエスト数の閾 値を増カロさせる。ここで、 klは定数であり、 kl≥l . 0。

[0150] B)T[R]≤k2 XT[R' ]の場合：応答待ちリクエスト数の閾値の増加によってスルー プットが減少していることを意味する。故に、応答待ちリクエスト数の閾値を減少させ る。ここで、 k2は定数であり、 k2≤l. 0。

[0151] C)上記以外の場合は、応答待ちリクエスト数の閾値を変化させない。

[0152] 本発明では、ノ ッファ中の待機リクエスト数に基づき、応答待ちリクエスト数がその 閾値に達しているかを判定している。そして、応答待ちリクエスト数がその閾値に達し ていると判定された場合に、応答待ちリクエスト数の閾値を増カロさせるべき力否かを 判定している。

[0153] これにより、サーバ 4に負荷が十分に力かっていない状態において、応答待ちリクェ スト数の閾値が無制限に増加してしまう問題を解消している。なお、上記実施例では 、 N<LN、すなわち応答待ちリクエスト数がその閾値に達していない場合に、応答待 ちリクエスト数の閾値を変化させていない。しかし、 Nく LNの場合に、応答待ちリクェ スト数の閾値を減少させてもょ 、。

[0154] 上記の実施例において、応答待ちリクエスト数の閾値の最大値と最小値とを定めて おき、修正後の応答待ちリクエストの閾値がその範囲外となる場合は、その修正を実 施しないようにしてもよい。

[0155] (第二の実施形態）

次に、第二の実施形態として、リクエストおよびレスポンスを送受信するプロトコルと して、インターネットで広く利用される TCPZlP(Transfer Control Protocol/Internet

Protocol)を用いる場合について示す。図 10は、本発明の第二の実施形態を示すブ ロック図である。本実施形態は、リクエストを発行するクライアント 1— 1〜1— nと、リク ェストに対応するレスポンスを返すサーバ 4、および、リクエスト 'レスポンスを仲介す る負荷制御装置 3と力もなる。負荷制御装置 3は、リバース Proxy、 Webァクセラレー タ、 Firewall,負荷分散システムなどの既存技術を拡張して実装してもよい。

[0156] 本実施形態の負荷制御システムは、次の 7つの機能ブロック力も構成される。

[0157] 'リクエスト受信部 30

'リクエスト送信部 32

'レスポンス受信部 34

'レスポンス送信部 33

•スケジューリング部 31

リクエスト受信部 30は、クライアント 1— 1〜1—nから受信したリクエストをスケジユー リング部 31に送信する。リクエスト受信部 30の処理手順を図 11に示す。まず、クライ アント 1— 1〜1—nからの TCPコネクションが新規に確立されると（S30)、クライアント 1 1〜1 nと負荷制御装置 3との間でリクエストおよびレスポンスを送受信するため のソケットを生成する（S31)。このとき、生成されたソケットには、ソケットを一意に識別 する ID (ソケット ID)が振られる。

[0158] 次に、クライアント側ソケットを一つ選択し (S32)、そのクライアント側ソケットを検査 する（S33)。検査した結果、ソケットに新規リクエストが含まれている場合には（S34) 、各ソケットからリクエストを読み出すリクエスト受信処理を行う（S35)。リクエストを読 み出すたび、各リクエストにリクエストを一意に識別するリクエスト IDが振られる。

[0159] 次に、リクエストとクライアント側のソケットとの対応関係を維持するため、図 12に示 すリクエスト表に、リクエスト IDおよびソケット IDの組を登録しておく（S36)。最後に、 受信したリクエストはスケジューリング部 31に送信される（S37)。

[0160] また、クライアント側ソケットを検査した結果 (S33)、そのソケットに新規リクエストが 含まれて 、な 、場合には（S34)、次のクライアント側ソケットを一つ選択 (S32)して 処理（S33〜S37)を繰り返す（S38)。

[0161] さらに、リクエストの読み出しと並行し、タイムアウトなどの要因によって TCPコネクシ ヨンが切断された力否かを検査する（S39)。コネクションが切断されている場合には、 そのソケットを廃棄する（S40)。

[0162] リクエスト送信部 32は、リクエストを負荷制御装置 3からサーバ 4に送信するための ソケットの管理、および、リクエストの送信処理を行う。リクエスト送信部 32の処理手順 を図 13に示す。リクエスト送信部 32は、スケジューリング部 31から新規送信リクエスト を受け取ると（S50)、図 14に示されるサーバ側ソケット表を参照し、送信先のサーバ 4との間にフリー状態のソケットが存在する力否かを検索する（S51)。ここで、フリー 状態のソケットとは、負荷制御装置 3と送信先のサーノ との間で TCPコネクションが 確立されており、かつ、これまでにサーバ 4に対して送信されたリクエストに対応する レスポンスを全て受信して 、るソケットを指す。

[0163] フリー状態のソケットを検出した場合は（S52)、そのソケットをリクエスト送信用ソケッ トとして選択する。フリー状態のソケットが存在しない場合は（S52)、送信先のサーバ 4と新規に TCPコネクションを確立し、リクエスト送信用ソケットを生成する（S53)。こ のとき、ソケットは一意の IDが割当てられる。そして、サーバ側ソケット表に、生成した ソケットの IDを登録し (S54)、その状態をフリーとする。フリー状態のソケットを選択す ると、次に、サーバ側ソケット表に当該リクエスト IDを登録する（S56)。このとき、ソケッ トの状態はフリーからビジーに変更される（S55)。最後に、サーバ 4に対してリクエス トを送信する（S57)。

[0164] また、リクエスト送信部 32は、タイムアウトなどによって切断された TCPコネクション が有る力否かを常時監視して検出する（S58)。切断された TCPコネクションを検出し た場合は (S59)、対応するソケットを廃棄し (S60)、サーバ側ソケット表から削除する (S61)。

[0165] 本実施形態のように、本発明は、リクエスト送信時に、その送信元クライアントに関 わらず、フリー状態のソケットを再利用する（コネクション集約)。コネクション集約によ り、負荷制御装置 3側において、サーバ 4と負荷制御装置 3との間の TCPコネクション 数がクライアント数を超えないように調整することができる。よって、サーバ側ソケット 数が応答待ちリクエスト数の閾値を超えることがない。故に、応答待ちリクエスト数の 閾値が TCPコネクション数の制限より小さ 、ならば、リクエスト送信が TCPコネクショ ン数の制限によってブロックされることがなくなる。 [0166] 図 13の実施例では、 1つのソケットが同時にサーバ 4に送信できるリクエスト数を 1と している。し力し、レスポンスの返却を待たずに、 1つのソケットで複数のリクエストを連 続送信してもよい。 1つのソケットから複数のリクエストを連続的にサーバ 4に送信する ことで、ソケットの生成または廃棄オーバヘッドを軽減できる。

[0167] レスポンス受信部 34の処理手順を図 15に示す。レスポンス受信部 34は、サーバ 4 力も返送されたレスポンスを受信する（S70)。次に、サーバ側ソケット表を参照し、レ スポンスを受信したサーバ側ソケットを選択する（S71)。次に、レスポンスを読み込み (S72)、サーバ側ソケット表の ID力も対応するリクエスト IDを取得する（S73)。そして 、受信したレスポンス IDとして、対応するリクエストと同じ IDを割当てる。次に、レスポ ンスをスケジューリング部 31、レスポンス送信部 33に送信する（S74)。最後に、当該 ソケットから次のリクエストを送信できるように、ソケットの状態をビジー力もフリーに変 更する（S75)。

[0168] レスポンス送信部 33の処理手順を図 16に示す。レスポンス送信部 33では、レスポ ンスを受け取ると（S80)、そのレスポンス ID (リクエスト IDと一致する）を基にリクエスト 表を参照し、レスポンスを送信すべきクライアントと接続されて ヽるクライアント側ソケッ ト IDを取得 (S81)してクライアント側ソケットを選択する。次に、ソケットにレスポンスを 書き込むことでそのレスポンスをクライアントに返送する（S82)。

[0169] スケジューリング部 31では、第一の実施形態と同様に、受信したリクエストをバッフ ァにバッファリングする。そして、応答待ちリクエスト数が閾値を下回っている場合には 、ノ ッファに格納されているリクエストを選択し、サーバ 4に対して送信する。

[0170] スケジューリング部 31の処理手順を図 17に示す。リクエスト受信した場合は、まず、 リクエストをバッファに格納する（S90)。次に、ノ ッファ中に送信待ちリクエストが存在 するか否かを判定する（S91)。送信待ちリクエストが存在する場合は、現在の応答待 ちリクエスト数がその閾値を超えている力否かを判定する（S92)。閾値以上である場 合は当該処理を終了する。送信中リクエスト数が閾値未満である場合は、応答待ちリ タエスト数を 1増加させる（S93)。次に、ノ ッファからリクエストを一つ取り出し、リクェ スト送信部 32に対して送信する（S94)。

[0171] 一方で、レスポンスを受信した場合は、次のリクエストを送信できるように応答待ちリ タエスト数を 1減じる（S95)。その後の処理は、リクエスト受信時と同様に、図 17のス テツプ S91「リクエストがバッファに存在？」以降を実行する。

[0172] 上述した実施例では、サーバ台数は 1台としているが、複数のサーバを用いてもよ い。複数サーバを用いる場合は、スケジューリング部 31、レスポンス送信部 33、レス ポンス受信部 34を、サーバ台数分複製する。そして、リクエスト受信部 30において、 宛先にしたがって各サーバ用の各処理部にリクエストを振り分ければよい。

[0173] 本発明の効果を示すため、本発明の負荷制御装置 3を PC (パーソナル'コンビユー タ）上に実装し、実験的に評価する。評価は、クライアント l— l〜l—nからのサーバ 4への入力リクエストレート (request per second:rps)を変化させた場合の Webサーノ のスループット (rps)を、本発明の負荷制御装置 3が有る場合と無い場合とで比較す る。

[0174] 実験の構成を図 18に示す。図 18に示すように、クライアント 1— 1〜1— nとサーノ

(Webサーノ とは、 L2スィッチ 5および負荷制御装置 3を介して通信をする。サーバ 4と負荷制御装置 3との間および負荷制御装置 3と L2スィッチ 5との間のネットワーク（ 図示省略）の帯域は lGbpsである。一方、クライアント 1— 1〜1— nと L2スィッチ 5と の間のネットワーク（図示省略）の帯域は 100Mbpsである。ここで、サーバ 4および負 荷制御装置 3の構成を図 19に示す。本実験では、負荷制御装置 3の応答待ちリクェ スト数の閾値を" 10"で固定している。

[0175] 従来の負荷制御手法と比較するため、サーバ 4が同時に接続可能な TCPコネクシ ヨン数の上限を 150に設定しておく。また、クライアント 1— 1〜1— nがリクエストを送 信して力も受信するまでのタイムアウト時間を 10秒に設定する。タイムアウトに達する と、クライアント l— l〜l—nは TCPコネクションを切断し、当該リクエストをキャンセル する。

[0176] 図 20に実験結果を示す。図 20は横軸に入力リクエストレートをとり、縦軸にスルー プットをとる。図 20はクライアント 1— 1〜1—nからの入力リクエストレート（rps)に対す るサーバ 4のスループット（rps)の変化を示している。図 20中の「本発明」は、負荷制 御装置 3が有る場合の結果を示し、「従来手法」は、負荷制御装置 3を介さずにサー ノ とクライアント 1— 1〜1—nを接続した場合の結果を示して 、る。 [0177] 図 20から、入力リクエストレートが lOOrps以下ならば、負荷制御装置 3の有無に関 わらず、サーノ のスループットは入力リクエストレートに比例して増加する。しかし、 入力リクエストレートが lOOrpsを超えると、負荷制御装置 3がない場合では、スルー プットの低下が顕著に生じる。例えば、入力レートが 200rpsにおけるスループットは ピーク時の約 60%となる。

[0178] 一方で、本発明の負荷制御装置 3を用いると、入力リクエストレートが lOOrpsより増 加しても、そのスループットをピーク時の 90%以上に維持できている。以上の結果は 、本発明による負荷制御装置 3の有効性を実証するものと 、える。

[0179] 次に、応答待ちリクエスト数の閾値を自動調整することによる効果を示す。本評価で は図 18と同様の構成を用いる。また、本評価におけるサーバ 4および負荷制御装置 3の詳細を図 21に示す。本評価では、 Webアプリケーションとして、オンラインショッ ピングを想定し、ベンチマークソフトウェア SPEC WEB2005 Ecommerceを用い ている（例えば、 http : //www. spec, org参照）。この Webアプリケーションでは、 ショッピングを完了するまでにおよそ 13ページを必要とする。またクライアント PC上に 現実のクライアントの動作をエミュレートするプログラムを実行する。

[0180] クライアントプログラムでは、自動的に Webサーバにアクセスし、セッションの実行を 試みる。このとき、クライアントプログラムの振る舞いは、現実のクライアントと同様に、 一つのページを取得してから次のページに移動するまでの思考時間、ページ読み 込みのタイムアウトを考慮する。タイムアウトした場合は、再度、当該ページの取得を 試みる。また一定の確率で、前のページに後戻りしたり、セッション途中中断したりす る。本評価では、まず、サーノ の最大処理性能を上回る量のリクエストを負荷制御 装置 3に送信する。次に、サーノ で単位時間に処理されたリクエスト数であるスルー プットを、応答待ちリクエスト数の閾値を静的に設定する場合と、本発明に基づき自 動調整する場合とで測定して比較する。

[0181] まず、応答待ちリクエスト数の閾値を静的に設定する場合を評価する。その評価結 果を図 22に示す。図 22のグラフは、応答待ちリクエスト数の閾値の設定値に対する スループットの変化を示している。すなわち、図 22の横軸は、応答待ちリクエスト数の 閾値の設定値であり、縦軸はサーノ のスループット (rps)である。図 22のグラフから 、サーノ のスループットは応答待ちリクエスト数の閾値力 ' 2"の場合に 671rpsで最 大となり、応答待ちリクエスト数の増加に伴って徐々に低下することがわかる。この結 果から、仮に、スループットを最大値の 97%以上に維持したいと仮定すると、応答待 ちリクエスト数の閾値を" 2"〜"6"の範囲に設定することが必要となる。

[0182] 次に、上述した（自動調整の実施例 4)を用いて、本発明に基づいて応答待ちリクェ スト数の閾値を自動調整した結果を示す。なお、本発明に基づく閾値の自動調整法 の有効性を示すため、非特許文献 1に示されるページ単位の並列度自動調整法を、 応答待ちリクエスト数の閾値の制御に応用した場合の結果を併せて示す。なお、非 特許文献 1に示される並列度自動調整法は以下のとおりである。まず、定期的にスル 一プットを測定し、並列度を増カロさせる力減少させるかを決定する。ここで、 i回目の 測定におけるスループットを Tiとする。また、 i回目の測定時の並列度を とする。こ のとき、

•Ci>Ci-lかつ Ti≥Ti-lならば並列度を増加させる。

[0183] *Ci>Ci-lかつ Ti<Ti-lならば並列度を減少させる。

[0184] *Ci< Ci-lかつ Ti≥Ti-lならば並列度を減少させる。

[0185] *Ci< Ci-lかつ Ti<Ti-lならば並列度を増加させる。

[0186] すなわち、前回の測定結果と比較し、スループットの向上が得られているならば前 回と同じオペレーション（並列度の増加または減少）を行う。逆に、スループットが減 少していたら、前回と逆のオペレーションを施す。

[0187] 図 23のグラフは、応答待ちリクエスト数の閾値の時間的変化を示している。図 23の 横軸は時間（秒)であり、縦軸は応答待ちリクエスト数の閾値である。図 23において、 本発明に基づく自動調整法では、応答待ちリクエスト数の閾値が" 2"〜"6"の間に収 まっている時間が、観測時間の 96. 9%に達している。力！]えて、本発明に基づいて自 動調整した場合の平均スループットは 660rpsであり、これは静的に設定した場合の 最大スループットの 98%に達している。一方で、図 23から、非特許文献 1に基づく手 法では、応答待ちリクエスト数の閾値が異常増加していることがわかる。非特許文献 1 による手法でこのような異常増加が生じる要因として以下がある。

[0188] (1)非特許文献 1に基づく手法では、現在の応答待ちリクエスト数がその閾値に達し ている力否かを判定する手段がない。故に、サーバへの入力リクエストレートを徐々 に増加させると、応答待ちリクエスト数の閾値に達する前にその閾値が際限なく増加 するという問題がある。これに対し、本発明では、キュー中のリクエストが十分な数に 達しない限り、応答待ちリクエスト数の閾値を増加させないことで、この問題を回避し ている。

[0189] (2)非特許文献 1に基づく手法では、応答待ちリクエスト数の閾値の増減は、前回と 今回のスループット計測結果の比較と 、う、局所的なスループットの変化力 決定さ れる。このため、スループットが一時的に大きく下がって徐々に回復した場合などで、 長期的にはスループットの向上が得られて 、な 、にも関わらず応答待ちリクエスト数 の閾値が際限なく増加 (または減少)するという問題が生じる。これに対して本発明の 自動調整の実施例 4では、応答待ちリクエスト数の閾値毎にスループットを記録し比 較することで、スループットの増加が得られない限り閾値が増加しな 、ように設計され ている。また、自動調整の実施例 1〜3では、応答時間に閾値を設定することで、応 答待ちリクエスト数の閾値が際限なく増加する問題を回避している。

[0190] 次に、本発明に基づくリクエストの優先制御の効果の一例として、セッションの進行 状況に基づくクラス分類の評価結果を示す。すなわち、有効なセッション IDを含むか 否かに基づき、リクエストをクラス分類する。そして、 Priority Queuingを用いて、有 効なセッション IDを含むリクエストを優先的にサーバで処理させる。本評価では図 18 と同様の構成を用いる。また、本評価におけるサーバ 4および負荷制御装置 3の詳細 は図 21と同様である。ただし、負荷制御装置の応答待ちリクエスト数の閾値は静的に 10に設定している。以上の条件のもと、 Webサーバ上に対してセッション処理を試み るクライアントの数を変化させたときの、 Webサーバが単位時間当りに完了できたセッ シヨン数 (以下、セッションスループット）を、負荷制御装置がある場合とない場合とで 比較する。

[0191] 図 24に実験結果を示す。図 24の縦軸はクライアントの数であり、横軸はセッション スループットを示している。図 24に示されるとおり、 400クライアントまでは、負荷制御 装置の有無に関わらず、クライアント数に対してサーバのセッションスループットが比 例して増加する。しかし、 400クライアントを超えると、サーバが過負荷となり、クライア ント間でサーバリソースが競合するようになる。この結果、負荷制御装置が無い場合 では、各クライアントで等しくタイムアウトや途中中断が生じるようになり、セッションス ループットが低下に転じる。そして、 800クライアントでセッションが全く完了しなくなる 。これに対して、本実施例の負荷制御装置では、より進行しているセッションを優先的 に処理する。この結果、 Webサーバが過負荷となった状態においても、セッションス ループットを最大のまま維持している。以上の結果は、本実施例の負荷制御装置に 基づく優先制御の効果を実証するものである。

[0192] 以上の結果は本発明の有効性を示すものといえる。

[0193] 本実施例は、汎用の情報処理装置にインストールすることにより、その情報処理装 置に、本実施例で説明した負荷制御装置 3に相応する機能を実現させるプログラムと して実施することができる。このプログラムは、記録媒体に記録されて汎用の情報処 理装置にインストールされ、あるいは通信回線を介して汎用の情報処理装置にインス トールされることにより当該汎用の情報処理装置を本実施例で説明した負荷制御装 置 3に相応する装置とすることができる。

[0194] なお、本実施例のプログラムは、汎用の情報処理装置によって直接実行可能なも のだけでなぐハードディスクなどにインストールすることによって実行可能となるもの も含む。また、圧縮されたり、暗号化されたりしたものも含む。

産業上の利用可能性

[0195] 本発明によれば、過剰リクエスト受信時におけるサーバの性能低下を回避すること ができ、また、この際に、適切な制御のための閾値の設定も自動化することができる ため装置 (ネットワーク)管理者およびネットワーク 'ユーザの双方にとって利便性を向 上させることができる。

Claims

請求の範囲

[1] クライアント（1— 1、 · · ·、 l—n)とサーバ (4)との間に配置され、前記クライアント（1 1、 · · ·、 l—n)力も受信したリクエストを前記サーバ (4)に送信し、当該リクエストに対 して前記サーバ (4)から返されるレスポンスを前記クライアント（1— 1、 · · ·、 1— n)に 送信する負荷制御装置（3)にお 、て、

前記サーバ (4)に送信済みであるが前記サーバ (4)からレスポンスが返されて 、な い応答待ちリクエストの数を制限する手段を備え、

この制限する手段は、

応答待ちリクエスト数が閾値に達しているならば、受信したリクエストを一時蓄積す るノ ッファと、

応答待ちリクエスト数が閾値を下回るまで前記バッファ力 のリクエストの送信を待 ち合わせる手段と、

を備えたことを特徴とする負荷制御装置 (3)。

[2] 前記閾値は 1よりも大きな値である請求の範囲第 1項記載の負荷制御装置（3)。

[3] 前記サーバ (4)の実行状況を監視する手段と、

この監視する手段の監視結果に基づいて前記サーバ (4)のリクエストに対する応答 時間が許容範囲内であるときには前記応答待ちリクエスト数の閾値を増加させ、当該 応答時間が許容範囲を超える場合には前記応答待ちリクエスト数の閾値を減少させ る手段と、

を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[4] 前記サーバ (4)の実行状況を監視する手段と、

この監視する手段の監視結果に基づ!、て単位時間あたりにサーバ (4)が処理した リクエスト数であるスループットを応答待ちリクエスト数の閾値毎に測定する手段と、 現在の閾値に対するスループットが現在の閾値より小さい閾値に対するスループッ トを上回る場合には閾値を増加させ、現在の閾値に対するスループットが現在の閾 値より小さい閾値のスループットを下回る場合には閾値を減少させる手段と、 を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[5] 応答待ちリクエスト数がその閾値に達している力否かを判定する手段と、 閾値に達して 、る場合に、閾値を増加または減少させる力否かを判定する手段と、 を備えた請求の範囲第 3項または第 4項記載の負荷制御装置 (3)。

[6] 前記サーバ (4)と自己（3)との間の TCPコネクション同時接続数が前記応答待ちリク ェスト数の閾値以下となるように自己（3)と前記クライアント（1— 1、 · · ·、 l—n)との間 の TCPコネクションを集約する手段を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[7] 前記バッファは、送信元クライアント（1— 1、 · · ·、 l—n)の識別情報に基づきリクエス トを優先制御する手段を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[8] 前記バッファは、リクエスト中の特定の位置または範囲に特定のパターンが含まれる か否かに基づきリクエストを優先制御する手段を備えた請求の範囲第 1項記載の負 荷制御装置 (3)。

[9] 前記バッファは、リクエスト中の特定の変数が予め設定した閾値より大きいか否かに 基づきリクエストを優先制御する手段を備えた請求の範囲第 1項記載の負荷制御装 置 (3)。

[10] 前記バッファは、リクエストが暗号ィ匕されているか否かに基づきリクエストを優先制御 する手段を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[11] 前記バッファは、所定時間以上蓄積されたリクエストに対して、ビジーメッセージを通 知する手段を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[12] 前記サーバ（4)は Webサーバであり、

前記バッファは、リクエストのページ表示の表示優先度に基づきリクエストを優先制 御する手段を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[13] 前記リクエストは TCPコネクションによってクライアント（1— 1、 · · ·、 l—n)力も負荷制 御装置 (3)に送信され、

前記バッファは、クライアントと負荷制御装置との間に接続された他の TCPコネクシ ヨンの有無または TCPコネクションの数および当該リクエストが TCPコネクションの最 初のリクエストである力否かに基づきリクエストを優先制御する手段を備えた請求の範 囲第 1項記載の負荷制御装置 (3)。

[14] レスポンスにブラウザが自動取得すべきページ構成要素の URLが指し示されて 、る 場合に、レスポンス送信先の識別情報と当該 URLとの組を一時的に記憶する手段を 備え、

前記バッファは、リクエストの送信元の識別情報と URLとの組力 一時記憶されたレ スポンス送信先の識別情報と URLとの組と一致するカゝ否かに基づきリクエストを優先 制御する手段を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[15] 前記リクエストが属するセッションの進行状況に基づきリクエストを優先制御する手段 を備えた請求の範囲第 1項記載の負荷制御装置 (3)。

[16] 前記サーバ (4)で処理されたリクエストが属するセッションのセッション識別情報を一 定期間キャッシュする手段と、キャッシュされているセッション識別情報を持つか否か に基づきリクエストを優先制御する手段を備えた請求の範囲第 1項記載の負荷制御 装置 (3)。

[17] 前記バッファは、クライアント（1— 1、 · · ·、 1—n)力 送信されたトラヒックの不正ァク セスの疑わしさに基づきリクエストを優先制御する手段を備えた請求の範囲第 1項記 載の負荷制御装置 (3)。

[18] 汎用の情報処理装置にインストールすることにより、その汎用の情報処理装置に、請 求の範囲第 1項ないし第 17項のいずれかに記載の負荷制御装置の機能に相応する 機能を実現させるプログラム。

[19] 請求の範囲第 18項記載のプログラムが記録された前記汎用の情報処理装置が読取 可能な記録媒体。

[20] クライアント（1— 1、 · · ·、 1 n)とサーバ (4)との間に配置され、前記クライアント（1 1、 · · ·、 1—n)力も受信したリクエストを前記サーバ (4)に送信し、当該リクエストに対 して前記サーバ (4)から返されるレスポンスを前記クライアント（1— 1、 · · ·、 1— n)に 送信する負荷制御装置 (3)が実行する負荷制御方法にぉ 、て、

前記サーバに送信済みであるが前記サーノからレスポンスが返されていない応答 待ちリクエストの数を制限するステップ（S10— S14、 S20— S26)を有し、

この制限するステップは、

応答待ちリクエスト数が閾値に達しているならば、受信したリクエストをバッファに 一時蓄積するステップ (S 10、 S11)と、 応答待ちリクエスト数が閾値を下回るまで前記バッファ力 のリクエストの送信を待 ち合わせるステップ（Sl l— S14、 S23— S26)と、

を有することを特徴とする負荷制御方法。

[21] 前記閾値は 1よりも大きな値である請求の範囲第 20項記載の負荷制御方法。

[22] 前記サーバ (4)の実行状況を監視するステップと、

この監視するステップの監視結果に基づいて前記サーバのリクエストに対する応答 時間が許容範囲内であるときには前記応答待ちリクエスト数の閾値を増加させ、当該 応答時間が許容範囲を超える場合には前記応答待ちリクエスト数の閾値を減少させ るステップと、

を有する請求の範囲第 20項記載の負荷制御方法。

[23] 前記サーバ (4)の実行状況を監視するステップと、

この監視するステップの監視結果に基づ ヽて単位時間あたりにサーバ (4)が処理 したリクエスト数であるスループットを応答待ちリクエスト数の閾値毎に測定するステツ プと、

現在の閾値に対するスループットが現在の閾値より小さい閾値に対するスループッ トを上回る場合には閾値を増加させ、現在の閾値に対するスループットが現在の閾 値より小さい閾値のスループットを下回る場合には閾値を減少させるステップと、 を有する請求の範囲第 20項記載の負荷制御方法。

[24] 応答待ちリクエスト数がその閾値に達している力否かを判定するステップと、

閾値に達して 、る場合に、閾値を増加または減少させる力否かを判定するステップ と、

を有する請求の範囲第 22項または第 23項記載の負荷制御方法。

[25] 前記サーバ (4)と自己（3)との間の TCPコネクション同時接続数が前記応答待ちリク ェスト数の閾値以下となるように自己（3)と前記クライアント（1— 1、 · · ·、 l—n)との間 の TCPコネクションを集約するステップを有する請求の範囲第 20項記載の負荷制御 方法。