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

Description

本発明は、クライアントとサーバとの間に配置され、クライアントから受信したリクエストをサーバに転送し、当該リクエストに対してサーバから返却されるレスポンスをクライアントに転送する装置に利用する。特に、リクエストのスケジューリングに関する。なお、本明細書では、Ｗｅｂサーバに着目して説明するが、必ずしも他のサーバへの本発明の適用を制限するものではない。

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

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

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

また、Ｗｅｂサービスによって提供されるコンテンツとして映像や音声のストリーミングが盛んに利用されるようになっている。ストリーミングの基本的な仕組みは以下のとおりである。

まず、クライアントのＷｅｂブラウザは、ストリームコンテンツのメタファイルをＷｅｂサーバから取得する。メタファイルには、ストリームコンテンツのＵＲＬが記述される。同時に、Ｗｅｂブラウザは、メタファイルの拡張子に関連付けられたプレイヤ（ストリーム再生用アプリケーション）を起動する。そして、Ｗｅｂサーバから取得したメタファイルに示されるＵＲＬに基づき、プレイヤがストリーミングサーバに対し、ストリームコンテンツの送信を要求する。最後に、ストリーミングサーバが、プレイヤに対してストリーミングデータを送信する。

ストリーミングでサーバは一般的に、ストリームコンテンツの再生制御にＲＴＳＰ（Real Time Streaming Protocol）プロトコルを使用する。ＲＴＳＰプロトコルはＨＴＴＰプロトコルをベースとするプロトコルであり、クライアントとサーバとの間で、リクエストとリクエストに対するレスポンスを送受信することによって、ストリームコンテンツを再生制御する。

ＲＴＳＰのリクエストが使用できる主な制御メソッドとして、初期設定（ＳＥＴＵＰ）、再生（ＰＬＡＹ）、停止（ＴＥＡＲＤＯＷＮ）、などがある。ＲＴＳＰでは、同時に複数のストリームを制御するため、セッションの概念を有する。すなわち、ＲＴＳＰでは、プレイヤがＳＥＴＵＰリクエストを送信してから、ＴＥＡＲＤＯＷＮリクエストを送信してストリーミングが終了するまでを一つのセッションとみなす。

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

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

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

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

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

過剰トラヒックによるサーバ性能低下を防ぐため、サーバに送信されるリクエスト量を予め制限する手法が提案されている。リクエスト量を制限する指標として、（ａ）ＴＣＰコネクション数、（ｂ）サーバ負荷状態、（ｃ）帯域、（ｄ）並列度などが用いられる。

（ａ）ＴＣＰコネクション数を用いる場合は、同時接続可能なＴＣＰコネクション数の上限を定めることによって、サーバの過負荷回避を試みる。Ａｐａｃｈｅなどの汎用的なＨＴＴＰサーバ、負荷分散システムなどで用いられる。しかしながら、リクエストの種類、クライアントの回線速度などによって、ＴＣＰコネクション毎にその負荷が大きく異なる。このため、ＴＣＰコネクション数の上限に達する前に、サーバが過負荷となったり、逆に、サーバリソースが余っていても、ＴＣＰコネクション数が上限に達していることによって、新たなＴＣＰコネクションを確立できない、といった問題が生じる。

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

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

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

並列度を制御する具体例として、ページ単位に並列度を制限するように、ＨＴＴＰサーバを拡張した文献１（松沼正浩、日比野秀章、佐藤芳樹、光来健一、千葉滋著、“過負荷時のＷｅｂアプリケーションの性能劣化を改善するＳｅｓｓｉｏｎ−Ｌｅｖｅｌ Ｑｕｅｕｅ Ｓｃｈｅｄｕｌｉｎｇ”、第２回ディペンダブルソフトウェアワークショップ（ＤＳＷ’０５）、ｐｐ．１０５−１１４，２００５年１月）がある。しかし、サーバ上で並列度を制御しても、リクエスト処理性能低下の第一要因である、サーバが処理しきれないリクエストの受信に伴う、割込み、ＴＣＰ／ＩＰ処理などのオーバヘッドを避けることができない。その結果、他の手法と同様に、過剰トラヒック時におけるサーバの処理性能の低下が生じる。また、ＨＴＴＰサーバまたはＷｅｂアプリケーションの変更が必要になるため、既に運用中のサービスへの導入障壁が高いといった問題がある。

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

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

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

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

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

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

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

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

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

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

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

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

また、従来技術ａ）で示したように、一般的にＷｅｂサーバでは、ＴＣＰコネクションの同時接続数に上限を設けている。しかし、ＴＣＰコネクションの同時接続数に制限が設けられると、応答待ちリクエスト数に基づく負荷制御が機能しなくなる場合がある。この問題を解決するため、本発明では、応答待ちリクエスト数による負荷制御を、従来技術の一つのコネクション集約と組み合わせて利用する。コネクション集約とはＨＴＴＰ１．１のＫｅｅｐ−Ａｌｉｖｅ機能を利用し、負荷制御装置とサーバとの間で張られたＴＣＰコネクションを複数のクライアントで共有する技術である。

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

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

ここで、本発明の特徴とするところは、前記サーバに送信済みであるが前記サーバからレスポンスが返されていない応答待ちリクエストの数を制限する手段と、前記制限する手段は、応答待ちリクエスト数が閾値に達しているならば、受信したリクエストを一時蓄積するバッファと、応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの送信を待ち合わせる手段と、応答待ちリクエスト数が閾値未満の場合は、前記バッファからリクエストを１つ選択して取り出し、応答待ちリクエスト数を１インクリメントさせた後、サーバに当該リクエストを送信する手段と、受信したレスポンスを、当該レスポンスのリクエストを送信したクライアントに対して返送し、応答待ちリクエスト数を１デクリメントする手段と備え、前記サーバの実行状況を監視する手段と、前記監視する手段の監視結果に基づいて単位時間あたりに前記サーバが処理したリクエスト数である、現在の応答待ちリクエスト数の閾値に対するスループットを測定する手段と、前記バッファに一時蓄積されているリクエストの数が所定数に達しているか否かを判定する手段と、前記判定する手段の判定結果に基づいて、リクエストの数が所定数に達している場合、現在の応答待ちリクエスト数の閾値に対するスループットを記録し、現在の応答待ちリクエスト数の閾値に対して記録したスループットが当該現在の応答待ちリクエスト数の閾値より小さい閾値に対して記録したスループットを上回る場合には、当該現在の応答待ちリクエスト数の閾値を増加させ、現在の応答待ちリクエスト数の閾値に対して記録したスループットが当該現在の応答待ちリクエスト数の閾値より小さい閾値に対して記録したスループットを下回る場合には、当該現在の応答待ちリクエスト数の閾値を減少させる手段と、を備えたところにある。例えば、前記閾値は“１”よりも大きい値とする。

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

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

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

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

あるいは、前記バッファは、リクエストが暗号化されているか否かに基づきリクエストを優先制御する手段を備えることができる。

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

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

あるいは、前記リクエストはＴＣＰコネクションによってクライアントから負荷制御装置に送信され、前記バッファは、クライアントと負荷制御装置との間に接続された他のＴＣＰコネクションの有無またはＴＣＰコネクションの数および当該リクエストがＴＣＰコネクションの最初のリクエストであるか否かに基づきリクエストを優先制御する手段を備えることができる。

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

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

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

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

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

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

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

また、本発明を、本発明の負荷制御装置が実行する負荷制御方法の発明としてみることができる。すなわち、本発明は、前記サーバに送信済みであるが前記サーバからレスポンスが返されていない応答待ちリクエストの数を制限するステップと、前記制限するステップは、応答待ちリクエスト数が閾値に達しているならば、受信したリクエストをバッファに一時蓄積するステップと、応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの送信を待ち合わせるステップと、応答待ちリクエスト数が閾値未満の場合は、前記バッファからリクエストを１つ選択して取り出し、応答待ちリクエスト数を１インクリメントさせた後、サーバに当該リクエストを送信するステップと、受信したレスポンスを、当該レスポンスのリクエストを送信したクライアントに対して返送し、応答待ちリクエスト数を１デクリメントするステップとを有し、前記サーバの実行状況を監視するステップと、前記監視するステップの監視結果に基づいて単位時間あたりに前記サーバが処理したリクエスト数である、現在の応答待ちリクエスト数の閾値に対するスループットを測定するステップと、前記バッファに一時蓄積されているリクエストの数が所定数に達しているか否かを判定するステップと、前記判定するステップの判定結果に基づいて、リクエストの数が所定数に達している場合、現在の応答待ちリクエスト数の閾値に対するスループットを記録し、現在の応答待ちリクエスト数の閾値に対して記録したスループットが当該現在の応答待ちリクエスト数の閾値より小さい閾値に対して記録したスループットを上回る場合には、当該現在の応答待ちリクエスト数の閾値を増加させ、現在の応答待ちリクエスト数の閾値に対して記録したスループットが当該現在の応答待ちリクエスト数の閾値より小さい閾値に対して記録したスループットを下回る場合には、当該現在の応答待ちリクエスト数の閾値を減少させるステップと、を有することを特徴とする負荷制御方法である。例えば、前記閾値は“１”よりも大きな値とする。

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

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

過剰リクエストによるサーバの処理性能低下を説明するための図。 理想的なスループットの挙動を示す図。 過剰リクエスト時のサーバの振る舞いおよび理想的なサーバへのリクエストの到着の状態を示す図。 本発明によるサーバへのリクエストの到着の状態を示す図。 第一の実施形態の全体構成図。 第一の実施形態の負荷制御装置の処理手順を示すフローチャート。 第一の実施形態のリクエスト受信処理の実行手順を示すフローチャート。 第一の実施形態のレスポンス受信処理の実行手順を示すフローチャート。 ＲＴＳＰリクエストのメソッド名に基づくクラス分類の一例を示す図。 第二の実施形態の負荷制御装置のブロック構成図。 第二の実施形態のリクエスト受信部の処理手順を示すフローチャート。 リクエスト表を示す図。 第二の実施形態のリクエスト送信部の処理手順を示すフローチャート。 サーバ側ソケット表を示す図。 第二の実施形態のレスポンス受信部の処理手順を示すフローチャート。 第二の実施形態のレスポンス送信部の処理手順を示すフローチャート。 第二の実施形態のスケジューリング部の処理手順を示すフローチャート。 本発明の効果を実証する実験の構成を示す図。 実験のためのサーバおよび負荷制御装置の構成表を示す図。 本発明の効果を示す図。 本発明の応答待ちリクエスト数の閾値を自動調整することの効果を実証する実験のためのサーバおよび負荷制御装置の構成表を示す図。 応答待ちリクエスト数の閾値の設定値に対するスループットの変化を示す図。 本発明の応答待ちリクエスト数の閾値を自動調整することの効果を示す図。 本発明のリクエストの優先制御をすることの効果を示す図。

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

図５は、本発明の第一の実施形態を示すブロック図である。本発明は、リクエストを発行するクライアント１−１〜１−ｎと、リクエストに対応するレスポンスを返すサーバ４、および、リクエストおよびレスポンスを仲介する負荷制御装置３とからなる。なお、サーバ４は、Apacheなどのソフトウエアモジュールであってもよく、負荷制御装置3とはＣＰＵやメモリなどの物理リソースが独立であるハードウエアモジュールであってもよい。また、本負荷制御装置３を２つ以上のサーバ４に接続し、1つの負荷制御装置３で、複数のサーバ４に対して負荷制御をしてもよい。さらに、負荷制御装置３は、リバースＰｒｏｘｙ、Ｗｅｂアクセラレータ、Ｆｉｒｅｗａｌｌ、負荷分散システムなどの既存技術を拡張して実装してもよい。負荷制御装置３にて、サーバ４に送信済みであるが、まだ、レスポンスが返されていないリクエスト数、すなわち応答待ちリクエスト数を監視する。応答待ちリクエスト数が定められた閾値を超える場合は、受信したリクエストをバッファリングする。そして、応答待ちリクエスト数が閾値を下回るまで、リクエストの送信を見合わせる。

図６に、負荷制御装置３の処理手順を示す。実行が開始されると負荷制御装置３は、まず、メッセージを受信するまで待ち合せる（Ｓ１）。ここで、負荷制御装置が受信するメッセージは、リクエストまたはレスポンスの２種類のみとする。メッセージを受信すると（Ｓ２）、そのメッセージがリクエストである場合はリクエスト受信処理を起動し（Ｓ３）、レスポンスである場合はレスポンス受信処理を起動する（Ｓ４）。

リクエスト受信処理の実行手順を図７に示す。リクエストを受信した場合に、負荷制御装置３はそのリクエストをバッファに格納する（Ｓ１０）。次に、応答待ちリクエスト数が閾値未満であるか否かを判定する（Ｓ１１）。なお、本実施形態では、応答待ちリクエスト数の閾値は、任意の値が静的に与えられているものとする。閾値以上である場合は（Ｓ１１）、サーバ４へのリクエストの送信を見合せ、本処理を終了する。閾値未満の場合は（Ｓ１１）、バッファからリクエストを一つ選択して取り出す（Ｓ１２）。次に、応答待ちリクエスト数を１インクリメントさせた後（Ｓ１３）、サーバ４にリクエストを送信する（Ｓ１４）。

次に、レスポンス受信処理の実行手順を図８に示す。まず、受信したレスポンスを、当該レスポンスのリクエストを送信したクライアントに対して返送する（Ｓ２０）。次に、応答待ちリクエスト数を１デクリメントする（Ｓ２１）。そして、バッファ中に送信待ちリクエストが存在するか否かを判定する（Ｓ２２）。リクエストが存在しない場合は（Ｓ２２）、当該処理を終了する。リクエストが存在する場合は（Ｓ２２）、リクエスト受信処理と同様に、リクエストの送信を試みる。すなわち、応答待ちリクエスト数が閾値未満であるか否かを判定する（Ｓ２３）。閾値以上の場合は（Ｓ２３）、サーバ４へのリクエストの送信を見合せ、本処理を終了する。閾値未満の場合は（Ｓ２３）、バッファからリクエストを一つ選択して取り出す（Ｓ２４）。次に、応答待ちリクエスト数を１インクリメントさせた後（Ｓ２５）、サーバ４にリクエストを送信する（Ｓ２６）。

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

バッファ中のリクエストの実行順序をスケジューリングするアルゴリズムとして単一のキューを用いてＦＩＦＯ(First-In First-Out)に基づきリクエストを処理することができる。また、複数のキューを用いてリクエストの重要度や要求品質に応じて優先制御を実施することもできる。この場合は、リクエストは一定のルールに基づき分類され、その結果に応じて優先制御のパラメータ（例えば、優先度、重み、タイムアウト時間）などが設定される。ここで、一定のルールに基づき分類された結果生じるリクエストの集合をクラスと定義する。そしてクラス別にリクエストをキューに格納し、各キュー間のリクエスト取り出し順序を優先制御パラメータに基づきスケジューリングする。このスケジューリングアルゴリズムとして、例えば、最も優先度が高いクラスに属するリクエストから処理するＰｒｉｏｒｉｔｙ Ｑｕｅｕｉｎｇ、クラス毎の重みに基づきレート制御するＷａｉｔｅｄ Ｆａｉｒ Ｑｕｅｕｉｎｇ、Ｗａｉｔｅｄ Ｒｏｕｎｄ Ｒｏｂｉｎなど、既存の優先スケジューリングアルゴリズムを利用できる。また、キューの代わりとして、タイムアウトするまでの時間長が昇順となるようにリクエストを並べる、ＥＤＦ(Earliest Deadline First)を用いることができる。リクエストの優先制御を行うことで、重要なリクエストや時間制約が厳しいリクエストを優先的にサーバ４で処理させることが可能になる。

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

・廃棄：リクエストを廃棄する。

・拒絶：サーバ４へのリクエスト送信を取りやめる。そして、負荷制御装置３からビジーメッセージなどをクライアント１−１〜１−ｎに送信する。リクエストの廃棄と異なり、リクエストが失敗した原因がリクエスト集中であることをクライアント１−１〜１−ｎに明示できる。

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

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

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

・クライアント識別情報に基づくクラス分類
・リクエストの内容に基づくクラス分類
・暗号化の有無に基づくクラス分類
・ページ処理の進行状況に基づくクラス分類
・セッション処理の進行状況に基づくクラス分類
・不正の疑わしさに基づくクラス分類
（クライアント識別情報に基づくクラス分類）
リクエストの送信元クライアントに応じてクラス分類する。以下に実施例を示す。

・送信元ＩＰアドレスに基づくクラス分類：リクエストを送信するプロトコルとしてＴＣＰ／ＩＰを用いる場合には、クライアントを送信元ＩＰアドレスから識別できる。故に、送信元ＩＰアドレスに基づいてキューを選択することで、特定のクライアントからのリクエストを優先化または非優先化することができる。

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

・Ｕｓｅｒ−Ａｇｅｎｔフィールドに基づくクラス分類：サーバがＷｅｂサーバである場合は、クライアントはＨＴＴＰプロトコルに基づきリクエストのヘッダにＵｓｅｒ−Ａｇｅｎｔフィールドを含めることができる。

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

・ユーザＩＤに基づくクラス分類：Ｗｅｂサーバは、クライアントを識別するため、クライアントに応じてユーザＩＤを発行し、クライアントに発行したユーザＩＤをＨＴＴＰリクエスト中に含ませるように指示できる。このユーザＩＤは、Ｃｏｏｋｉｅフィールド、ＵＲＬのクエリ、リクエストのボディにユーザＩＤを含ませることができる。したがって、負荷制御装置において、予め優先化（または非優先化）したいクライアントのユーザＩＤを登録しておく。次に、ＨＴＴＰリクエストに含まれるユーザＩＤと登録されているユーザＩＤとが一致するか否かに応じてクラスを選択する。これにより、例えば、追加料金を払っているクライアントからのリクエストを優先化したり、逆に、ブラックリストに載っているクライアントからのリクエストを非優先化させたりできる。

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

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

・ファイルの種別に基づくクラス分類：動的コンテンツのような負荷が高い処理へのリクエストを非優先化したい場合がある。動的コンテンツであるか静的コンテンツであるかは、リクエストされるファイル名から識別できる。例えば、動的コンテンツとしてＣＧＩを用いる場合は、そのリクエストするファイル名の接尾語は．ｃｇｉとなる。故に、ＣＧＩを非優先化する場合は、リクエストのＵＲＬがパターン“．ｃｇｉ”と一致するファイルへのリクエストを低優先なクラスに分類すればよい。

・ファイルサイズに基づくクラス分類：非常に大きいサイズのファイルのアップロードを試みるようなリクエストを非優先化したい場合は、ＨＴＴＰヘッダのリクエストサイズを表すＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈフィールドの値に閾値を設定し、閾値を超えるリクエストの低優先なクラスに分類すればよい。

（暗号化の有無に基づくクラス分類）
リクエストが暗号化されているか否かに応じて、リクエストのクラスを選択する。一般的に、暗号化して送信されたリクエストは、暗号化しないで送信されたリクエストより重要な情報が含まれる。そこで、暗号化されているリクエストを、高優先なクラスに分類することで、重要リクエストを保護できる。例えば、Ｗｅｂサービスでは、リクエストの送信方法として、暗号化しないＨＴＴＰ通信、暗号化するＨＴＴＰＳ通信のいずれかを選択できる。

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

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

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

・ＵＲＬに基づくクラス分類：ページの表示には不可欠なリソースに対するリクエストを優先処理することで、サーバ混雑時において、必要最小限のページ構成でより多くのクライアントにサービスを提供することができる。例えば、Ｗｅｂサーバにおいて、ページ表示に不可欠なリソースとそうでないリソースとをＷｅｂサーバの異なるディレクトリに保管しておく。そして、負荷制御装置において、前述した「リクエストの内容に基づくクラス分類」を用いて、ページ表示に不可欠なリソースが保管されるディレクトリの配下のリソースに対するリクエストを優先度が高いクラスに分類すればよい。

・ページルートリソースへのリクエストであるか否かに基づくクラス分類：ページルートリソースへのリクエストを低優先なクラスに分類することで、既に継続中のページ処理を優先的に処理する。これにより、サーバ混雑時にページ処理中のリクエストが途中失敗し、クライアントのブラウザ上に不完全なページが表示される、という問題を解消できる。特に、バッファ中のリクエストをスケジューリングするアルゴリズムとして前述したＰｒｉｏｒｉｔｙ Ｑｕｅｕｉｎｇを用いる場合には、ページ処理中のリクエストがバッファにある限り、ページルートリソースへのリクエストが処理されない。故に、サーバ混雑時に新規ページ処理の開始を効果的にブロッキングすることができる。

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

・ＴＣＰコネクションの最初のリクエストであるか否か：ＨＴＴＰ１．１では、１つのＴＣＰコネクションで複数のリクエスト・レスポンスを送受信することができる。このため、ページ表示のためブラウザが自動的にリクエストを送信する場合には、通常、ページルートリソースへの取得に用いられたＴＣＰコネクションが再利用される。

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

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

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

２）リクエストを受信すると、クライアント識別情報表を参照する。

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

４）同一クライアントから接続されるＴＣＰコネクションが全て切断されると、そのクライアントの識別情報をクライアント識別情報表から削除する。

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

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

１）レスポンスのファイルタイプがＨＴＭＬファイルである場合は、コンテンツ中にパターン“Ｓｒｃ＝”と一致する文字列を検索する。

２）パターン“Ｓｒｃ＝”と一致する文字列が存在する場合は、次に、パターン“Ｓｒｃ＝”に続くＵＲＬを抽出する。

３）抽出したＵＲＬとレスポンス送信先のクライアント識別情報との組を一定期間キャッシュする。

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

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

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

セッション処理を行う場合には、Ｗｅｂサーバは、受信したリクエストがどのセッションに属するかを識別する必要がある。このため、セッション処理では、セッションＩＤなどのセッション識別情報が用いられる。例えば、Ｗｅｂサーバは、セッションの先頭ページに対するリクエストを受け取ると、セッション毎に一意なセッションＩＤを発行し、レスポンスと共にクライアントに返送する。典型的なＷｅｂサーバでは、セッションＩＤをＨＴＴＰレスポンスのＳｅｔ−Ｃｏｏｋｉｅフィールドに格納する。次に、クライアントはサーバから通知されたセッションＩＤをリクエストに含めてサーバに送信する。このときセッションＩＤは、セッションＩＤがレスポンスのＳｅｔ−Ｃｏｏｋｉｅフィールドによって通知された場合に、リクエストのＣｏｏｋｉｅフィールドに格納される。Ｗｅｂサーバは、リクエスト中のセッションＩＤによって、そのリクエストが属するセッションを識別できる。

また、前述したように、ストリーミングサーバで用いられるＲＴＳＰは、セッションの概念を標準で備えている。すなわち、ＳＥＴＵＰリクエストによってセッションが開始されると、セッションＩＤが発行され、以降のリクエスト・レスポンスに付与される。ＲＴＳＰでは、セッションＩＤをＲＴＳＰヘッダのＳｅｓｓｉｏｎフィールドに格納する。

本実施例の負荷制御装置では、まず、リクエスト中のセッションＩＤをキーとして、当該リクエストが属するセッションの進行状況を評価する。例えば、既に開始済みのセッションに属するリクエストを一律に優先化する場合は、ＨＴＴＰプロトコルならばリクエスト中のＣｏｏｋｉｅフィールドなどを、ＲＴＳＰプロトコルならばリクエスト中のＳｅｓｓｉｏｎフィールドの有無を検査し、セッションＩＤがリクエストに含まれるか否かを判定する。そして、セッションＩＤを含むリクエストを高優先なクラスに分類する。これにより、開始済みセッションを優先的にサーバで処理することができる。特に、バッファ中のリクエストをスケジューリングするアルゴリズムとして前述したＰｒｉｏｒｉｔｙ Ｑｕｅｕｉｎｇを用いる場合には、継続中の開始済みセッションに属するリクエストがバッファにある限り、新規セッションの開始を要求するリクエストが処理されない。故に、サーバ混雑時に新規セッション処理の開始を効果的にブロッキングすることができる。

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

１）サーバからのレスポンスを検査し、ＨＴＴＰプロトコルならばＳｅｔ−Ｃｏｏｋｉｅフィールドなどを、ＲＴＳＰプロトコルならばＳｅｓｓｉｏｎフィールドを調べ、セッションＩＤが新しく発行されているか否かを判定する。

２）新しくセッションＩＤが発行されている場合は、当該セッションＩＤを一定期間、キャッシュする。

３）負荷制御装置が受け取ったリクエストにセッションＩＤが含まれているか否かを検証する。

４）リクエストにセッションＩＤが含まれている場合は、キャッシュしたセッションＩＤのいずれかと一致するか否か検証する。

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

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

キャッシュするセッション識別情報として、リクエストの送信元ＩＰアドレス、ユーザＩＤなどのクライアント識別情報を用いてもよい。例えば、セッションＩＤの代わりとして、サーバでリクエストが処理されたクライアントのＩＰアドレスをキャッシュしておくことで、送信元ＩＰアドレス単位で開始済みセッションを優先化する。本手法の実施例を以下に示す。

１）負荷制御装置がサーバから受け取ったレスポンスの送信先クライアントのＩＰアドレスを、一定期間、キャッシュする。

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

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

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

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

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

サーバが、ＲＴＳＰに基づくストリーミングサーバである場合は、セッションの進行状況を、リクエストのメソッドに基づいて評価してもよい。前述したように、ＲＴＳＰでは、ストリームの制御内容に応じ、ＳＥＴＵＰ、ＰＬＡＹ、ＴＥＡＲＤＯＷＮなどのメソッドが用意されている。これらのメソッドは、セッション確立以前に用いられるもの、セッション確立後に用いられるものに分類できる。

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

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

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

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

４）一致する場合は、低優先クラスに分類する。

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

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

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

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

（自動調整の実施例１）
バッファで待機している（平均）リクエスト数Ｎ、および、負荷制御装置３がリクエストをサーバ４に送信してからレスポンスを受け取るまでの（平均）応答時間Ｔを定期的に測定する。また、Ｎ、Ｔに対する閾値として、ＬN、ＬTを定めておく。このとき、Ｎ＜ＬNならば、リクエスト量が少ないため、応答待ちリクエスト数がその閾値に達していないとみなす。また、Ｔ＜ＬTならば、良好な応答が返ってきているとみなす。故に、
・Ｔ≧ＬTならば、応答待ちリクエスト数の閾値を減少させる。

・Ｔ＜ＬT
−Ｎ≧ＬNならば、応答待ちリクエスト数の閾値を増加させる。

−Ｎ＜ＬNならば、応答待ちリクエスト数の閾値を変化させない。

（自動調整の実施例２）
バッファで待機している（平均）リクエスト数Ｎ、および、負荷制御装置３がリクエストをサーバ４に返信してからレスポンスを受け取るまでの応答時間Ｔを定期的に測定する。また、Ｎ、Ｔに対する閾値として、ＬN、ＬTを定めておく。さらに、Ｔ＞ＬTとなったリクエストの割合をｒとする。このとき、定数ｋ（０≦ｋ≦１）を用いて、
・ｒ≧ｋならば、応答待ちリクエスト数の閾値を減少させる。

・ｒ＜ｋ
−Ｎ≧ＬNならば、応答待ちリクエスト数の閾値を増加させる。

−Ｎ＜ＬNならば、応答待ちリクエスト数の閾値を変化させない。

（自動調整の実施例３）
バッファで待機している（平均）リクエスト数Ｎ、および、サーバ４のＣＰＵ使用率Ｕを定期的に測定する。また、Ｎ、Ｌに対する閾値として、ＬN、ＬUを定めておく。

・Ｕ≧ＬUならば、応答待ちリクエスト数の閾値を減少させる。

・Ｕ＜ＬU
−Ｎ≧ＬNならば、応答待ちリクエスト数の閾値を増加させる。

−Ｎ＜ＬNならば、応答待ちリクエスト数の閾値を変化させない。

ＣＰＵ使用率のみでなく、メモリ使用率、帯域、並列度を監視し、その最大値をＵとしてもよい。

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

ここで、応答待ちリクエスト数の閾値Ｒに対するスループットをＴ［Ｒ］と表記する。また、バッファ中のリクエスト数Ｎに対する閾値として、ＬNを定めておく。このとき、測定されたＮおよびＴに応じて、以下を実施する。

１）Ｎ＜ＬNならば、応答待ちリクエスト数が閾値に達していないことを意味する。故に、応答待ちリクエスト数の閾値を更新しないで終了する。Ｎ≧ＬNならば、２）を実施する。

２）現在の応答待ちリクエスト数の閾値に対するスループットＴ［Ｒ］を、Ｔを用いて更新する。次に３）を実施する。

３）現在の応答待ちリクエスト数の閾値Ｒに対するスループットＴ［Ｒ］と、閾値がより小さい場合のスループットＴ［Ｒ’］（Ｒ’＜Ｒ）とを比較する。

Ａ）Ｔ［Ｒ］≧ｋ１×Ｔ［Ｒ’］の場合：応答待ちリクエスト数の閾値の増加によって、スループットの向上が得られていることを意味する。故に、さらに応答待ちリクエスト数の閾値を増加させる。ここで、ｋ１は定数であり、ｋ１≧１．０。

Ｂ）Ｔ［Ｒ］≦ｋ２×Ｔ［Ｒ’］の場合：応答待ちリクエスト数の閾値の増加によってスループットが減少していることを意味する。故に、応答待ちリクエスト数の閾値を減少させる。ここで、ｋ２は定数であり、ｋ２≦１．０。

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

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

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

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

（第二の実施形態）
次に、第二の実施形態として、リクエストおよびレスポンスを送受信するプロトコルとして、インターネットで広く利用されるＴＣＰ／ＩＰ(Transfer Control Protocol/Internet Protocol)を用いる場合について示す。図１０は、本発明の第二の実施形態を示すブロック図である。本実施形態は、リクエストを発行するクライアント１−１〜１−ｎと、リクエストに対応するレスポンスを返すサーバ４、および、リクエスト・レスポンスを仲介する負荷制御装置３とからなる。負荷制御装置３は、リバースＰｒｏｘｙ、Ｗｅｂアクセラレータ、Ｆｉｒｅｗａｌｌ、負荷分散システムなどの既存技術を拡張して実装してもよい。

本実施形態の負荷制御システムは、次の７つの機能ブロックから構成される。

・リクエスト受信部３０
・リクエスト送信部３２
・レスポンス受信部３４
・レスポンス送信部３３
・スケジューリング部３１
リクエスト受信部３０は、クライアント１−１〜１−ｎから受信したリクエストをスケジューリング部３１に送信する。リクエスト受信部３０の処理手順を図１１に示す。まず、クライアント１−１〜１−ｎからのＴＣＰコネクションが新規に確立されると（Ｓ３０）、クライアント１−１〜１−ｎと負荷制御装置３との間でリクエストおよびレスポンスを送受信するためのソケットを生成する（Ｓ３１）。このとき、生成されたソケットには、ソケットを一意に識別するＩＤ（ソケットＩＤ）が振られる。

次に、クライアント側ソケットを一つ選択し（Ｓ３２）、そのクライアント側ソケットを検査する（Ｓ３３）。検査した結果、ソケットに新規リクエストが含まれている場合には（Ｓ３４）、各ソケットからリクエストを読み出すリクエスト受信処理を行う（Ｓ３５）。リクエストを読み出すたび、各リクエストにリクエストを一意に識別するリクエストＩＤが振られる。

次に、リクエストとクライアント側のソケットとの対応関係を維持するため、図１２に示すリクエスト表に、リクエストＩＤおよびソケットＩＤの組を登録しておく（Ｓ３６）。最後に、受信したリクエストはスケジューリング部３１に送信される（Ｓ３７）。

また、クライアント側ソケットを検査した結果（Ｓ３３）、そのソケットに新規リクエストが含まれていない場合には（Ｓ３４）、次のクライアント側ソケットを一つ選択（Ｓ３２）して処理（Ｓ３３〜Ｓ３７）を繰り返す（Ｓ３８）。

さらに、リクエストの読み出しと並行し、タイムアウトなどの要因によってＴＣＰコネクションが切断されたか否かを検査する（Ｓ３９）。コネクションが切断されている場合には、そのソケットを廃棄する（Ｓ４０）。

リクエスト送信部３２は、リクエストを負荷制御装置３からサーバ４に送信するためのソケットの管理、および、リクエストの送信処理を行う。リクエスト送信部３２の処理手順を図１３に示す。リクエスト送信部３２は、スケジューリング部３１から新規送信リクエストを受け取ると（Ｓ５０）、図１４に示されるサーバ側ソケット表を参照し、送信先のサーバ４との間にフリー状態のソケットが存在するか否かを検索する（Ｓ５１）。ここで、フリー状態のソケットとは、負荷制御装置３と送信先のサーバ４との間でＴＣＰコネクションが確立されており、かつ、これまでにサーバ４に対して送信されたリクエストに対応するレスポンスを全て受信しているソケットを指す。

フリー状態のソケットを検出した場合は（Ｓ５２）、そのソケットをリクエスト送信用ソケットとして選択する。フリー状態のソケットが存在しない場合は（Ｓ５２）、送信先のサーバ４と新規にＴＣＰコネクションを確立し、リクエスト送信用ソケットを生成する（Ｓ５３）。このとき、ソケットは一意のＩＤが割当てられる。そして、サーバ側ソケット表に、生成したソケットのＩＤを登録し（Ｓ５４）、その状態をフリーとする。フリー状態のソケットを選択すると、次に、サーバ側ソケット表に当該リクエストＩＤを登録する（Ｓ５６）。このとき、ソケットの状態はフリーからビジーに変更される（Ｓ５５）。最後に、サーバ４に対してリクエストを送信する（Ｓ５７）。

また、リクエスト送信部３２は、タイムアウトなどによって切断されたＴＣＰコネクションが有るか否かを常時監視して検出する（Ｓ５８）。切断されたＴＣＰコネクションを検出した場合は（Ｓ５９）、対応するソケットを廃棄し（Ｓ６０）、サーバ側ソケット表から削除する（Ｓ６１）。

本実施形態のように、本発明は、リクエスト送信時に、その送信元クライアントに関わらず、フリー状態のソケットを再利用する（コネクション集約）。コネクション集約により、負荷制御装置３側において、サーバ４と負荷制御装置３との間のＴＣＰコネクション数がクライアント数を超えないように調整することができる。よって、サーバ側ソケット数が応答待ちリクエスト数の閾値を超えることがない。故に、応答待ちリクエスト数の閾値がＴＣＰコネクション数の制限より小さいならば、リクエスト送信がＴＣＰコネクション数の制限によってブロックされることがなくなる。

図１３の実施例では、１つのソケットが同時にサーバ４に送信できるリクエスト数を１としている。しかし、レスポンスの返却を待たずに、１つのソケットで複数のリクエストを連続送信してもよい。１つのソケットから複数のリクエストを連続的にサーバ４に送信することで、ソケットの生成または廃棄オーバヘッドを軽減できる。

レスポンス受信部３４の処理手順を図１５に示す。レスポンス受信部３４は、サーバ４から返送されたレスポンスを受信する（Ｓ７０）。次に、サーバ側ソケット表を参照し、レスポンスを受信したサーバ側ソケットを選択する（Ｓ７１）。次に、レスポンスを読み込み（Ｓ７２）、サーバ側ソケット表のＩＤから対応するリクエストＩＤを取得する（Ｓ７３）。そして、受信したレスポンスＩＤとして、対応するリクエストと同じＩＤを割当てる。次に、レスポンスをスケジューリング部３１、レスポンス送信部３３に送信する（Ｓ７４）。最後に、当該ソケットから次のリクエストを送信できるように、ソケットの状態をビジーからフリーに変更する（Ｓ７５）。

レスポンス送信部３３の処理手順を図１６に示す。レスポンス送信部３３では、レスポンスを受け取ると（Ｓ８０）、そのレスポンスＩＤ（リクエストＩＤと一致する）を基にリクエスト表を参照し、レスポンスを送信すべきクライアントと接続されているクライアント側ソケットＩＤを取得（Ｓ８１）してクライアント側ソケットを選択する。次に、ソケットにレスポンスを書き込むことでそのレスポンスをクライアントに返送する（Ｓ８２）。

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

スケジューリング部３１の処理手順を図１７に示す。リクエスト受信した場合は、まず、リクエストをバッファに格納する（Ｓ９０）。次に、バッファ中に送信待ちリクエストが存在するか否かを判定する（Ｓ９１）。送信待ちリクエストが存在する場合は、現在の応答待ちリクエスト数がその閾値を超えているか否かを判定する（Ｓ９２）。閾値以上である場合は当該処理を終了する。送信中リクエスト数が閾値未満である場合は、応答待ちリクエスト数を１増加させる（Ｓ９３）。次に、バッファからリクエストを一つ取り出し、リクエスト送信部３２に対して送信する（Ｓ９４）。

一方で、レスポンスを受信した場合は、次のリクエストを送信できるように応答待ちリクエスト数を１減じる（Ｓ９５）。その後の処理は、リクエスト受信時と同様に、図１７のステップＳ９１「リクエストがバッファに存在？」以降を実行する。

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

本発明の効果を示すため、本発明の負荷制御装置３をＰＣ（パーソナル・コンピュータ）上に実装し、実験的に評価する。評価は、クライアント１−１〜１−ｎからのサーバ４への入力リクエストレート(request per second:rps)を変化させた場合のＷｅｂサーバのスループット（ｒｐｓ）を、本発明の負荷制御装置３が有る場合と無い場合とで比較する。

実験の構成を図１８に示す。図１８に示すように、クライアント１−１〜１−ｎとサーバ４（Ｗｅｂサーバ）とは、Ｌ２スイッチ５および負荷制御装置３を介して通信をする。サーバ４と負荷制御装置３との間および負荷制御装置３とＬ２スイッチ５との間のネットワーク（図示省略）の帯域は１Ｇｂｐｓである。一方、クライアント１−１〜１−ｎとＬ２スイッチ５との間のネットワーク（図示省略）の帯域は１００Ｍｂｐｓである。ここで、サーバ４および負荷制御装置３の構成を図１９に示す。本実験では、負荷制御装置３の応答待ちリクエスト数の閾値を“１０”で固定している。

従来の負荷制御手法と比較するため、サーバ４が同時に接続可能なＴＣＰコネクション数の上限を１５０に設定しておく。また、クライアント１−１〜１−ｎがリクエストを送信してから受信するまでのタイムアウト時間を１０秒に設定する。タイムアウトに達すると、クライアント１−１〜１−ｎはＴＣＰコネクションを切断し、当該リクエストをキャンセルする。

図２０に実験結果を示す。図２０は横軸に入力リクエストレートをとり、縦軸にスループットをとる。図２０はクライアント１−１〜１−ｎからの入力リクエストレート（ｒｐｓ）に対するサーバ４のスループット（ｒｐｓ）の変化を示している。図２０中の「本発明」は、負荷制御装置３が有る場合の結果を示し、「従来手法」は、負荷制御装置３を介さずにサーバ４とクライアント１−１〜１−ｎを接続した場合の結果を示している。

図２０から、入力リクエストレートが１００ｒｐｓ以下ならば、負荷制御装置３の有無に関わらず、サーバ４のスループットは入力リクエストレートに比例して増加する。しかし、入力リクエストレートが１００ｒｐｓを超えると、負荷制御装置３がない場合では、スループットの低下が顕著に生じる。例えば、入力レートが２００ｒｐｓにおけるスループットはピーク時の約６０％となる。

一方で、本発明の負荷制御装置３を用いると、入力リクエストレートが１００ｒｐｓより増加しても、そのスループットをピーク時の９０％以上に維持できている。以上の結果は、本発明による負荷制御装置３の有効性を実証するものといえる。

次に、応答待ちリクエスト数の閾値を自動調整することによる効果を示す。本評価では図１８と同様の構成を用いる。また、本評価におけるサーバ４および負荷制御装置３の詳細を図２１に示す。本評価では、Ｗｅｂアプリケーションとして、オンラインショッピングを想定し、ベンチマークソフトウェアＳＰＥＣ ＷＥＢ２００５ Ｅｃｏｍｍｅｒｃｅを用いている（例えば、ｈｔｔｐ：／／ｗｗｗ．ｓｐｅｃ．ｏｒｇ参照）。このＷｅｂアプリケーションでは、ショッピングを完了するまでにおよそ１３ページを必要とする。またクライアントＰＣ上に現実のクライアントの動作をエミュレートするプログラムを実行する。

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

まず、応答待ちリクエスト数の閾値を静的に設定する場合を評価する。その評価結果を図２２に示す。図２２のグラフは、応答待ちリクエスト数の閾値の設定値に対するスループットの変化を示している。すなわち、図２２の横軸は、応答待ちリクエスト数の閾値の設定値であり、縦軸はサーバ４のスループット（ｒｐｓ）である。図２２のグラフから、サーバ４のスループットは応答待ちリクエスト数の閾値が“２”の場合に６７１ｒｐｓで最大となり、応答待ちリクエスト数の増加に伴って徐々に低下することがわかる。この結果から、仮に、スループットを最大値の９７％以上に維持したいと仮定すると、応答待ちリクエスト数の閾値を“２”〜“６”の範囲に設定することが必要となる。

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

・Ｃi＞Ｃi-1かつＴi＜Ｔi-1ならば並列度を減少させる。

・Ｃi＜Ｃi-1かつＴi≧Ｔi-1ならば並列度を減少させる。

・Ｃi＜Ｃi-1かつＴi＜Ｔi-1ならば並列度を増加させる。

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

図２３のグラフは、応答待ちリクエスト数の閾値の時間的変化を示している。図２３の横軸は時間（秒）であり、縦軸は応答待ちリクエスト数の閾値である。図２３において、本発明に基づく自動調整法では、応答待ちリクエスト数の閾値が“２”〜“６”の間に収まっている時間が、観測時間の９６．９％に達している。加えて、本発明に基づいて自動調整した場合の平均スループットは６６０ｒｐｓであり、これは静的に設定した場合の最大スループットの９８％に達している。一方で、図２３から、非特許文献１に基づく手法では、応答待ちリクエスト数の閾値が異常増加していることがわかる。非特許文献１による手法でこのような異常増加が生じる要因として以下がある。

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

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

次に、本発明に基づくリクエストの優先制御の効果の一例として、セッションの進行状況に基づくクラス分類の評価結果を示す。すなわち、有効なセッションＩＤを含むか否かに基づき、リクエストをクラス分類する。そして、Ｐｒｉｏｒｉｔｙ Ｑｕｅｕｉｎｇを用いて、有効なセッションＩＤを含むリクエストを優先的にサーバで処理させる。本評価では図１８と同様の構成を用いる。また、本評価におけるサーバ４および負荷制御装置３の詳細は図２１と同様である。ただし、負荷制御装置の応答待ちリクエスト数の閾値は静的に１０に設定している。以上の条件のもと、Ｗｅｂサーバ上に対してセッション処理を試みるクライアントの数を変化させたときの、Ｗｅｂサーバが単位時間当りに完了できたセッション数（以下、セッションスループット）を、負荷制御装置がある場合とない場合とで比較する。

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

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

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

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

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

Claims (19)

1. クライアントとサーバとの間に配置され、前記クライアントから受信したリクエストを前記サーバに送信し、当該リクエストに対して前記サーバから返されるレスポンスを前記クライアントに送信する負荷制御装置において、
   前記サーバに送信済みであるが前記サーバからレスポンスが返されていない応答待ちリクエストの数を制限する手段と、
   前記制限する手段は、
   応答待ちリクエスト数が閾値に達しているならば、受信したリクエストを一時蓄積するバッファと、
   応答待ちリクエスト数が閾値を下回るまで前記バッファからリクエストの送信を待ち合わせる手段と、
   応答待ちリクエスト数が閾値未満の場合は、前記バッファからリクエストを１つ選択して取り出し、応答待ちリクエスト数を１インクリメントさせた後、サーバに当該リクエストを送信する手段と、
   受信したレスポンスを、当該レスポンスのリクエストを送信したクライアントに対して返送し、応答待ちリクエスト数を１デクリメントする手段と、
   を備え、
   前記サーバの実行状況を監視する手段と、
   前記監視する手段の監視結果に基づいて単位時間あたりに前記サーバが処理したリクエスト数である、現在の応答待ちリクエスト数の閾値に対するスループットを測定する手段と、
   前記バッファに一時蓄積されているリクエストの数が所定数に達しているか否かを判定する手段と、
   前記判定する手段の判定結果に基づいて、リクエストの数が所定数に達している場合、現在の応答待ちリクエスト数の閾値に対するスループットを記録し、現在の応答待ちリクエスト数の閾値に対して記録したスループットが当該現在の応答待ちリクエスト数の閾値より小さい閾値に対して記録したスループットを上回る場合には、当該現在の応答待ちリクエスト数の閾値を増加させ、現在の応答待ちリクエスト数の閾値に対して記録したスループットが当該現在の応答待ちリクエスト数の閾値より小さい閾値に対して記録したスループットを下回る場合には、当該現在の応答待ちリクエスト数の閾値を減少させる手段と、
   を備えたことを特徴とする負荷制御装置。
2. 前記閾値は１よりも大きな値である請求の範囲第１項記載の負荷制御装置。
3. 前記サーバと自己との間のＴＣＰコネクション同時接続数が前記応答待ちリクエスト数の閾値以下となるように自己と前記クライアントとの間のＴＣＰコネクションを集約する手段を備えた請求の範囲第１項記載の負荷制御装置。
4. 前記バッファは、送信元クライアントの識別情報に基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
5. 前記バッファは、リクエスト中の特定の位置または範囲に特定のパターンが含まれるか否かに基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
6. 前記バッファは、リクエスト中の特定の変数が予め設定した閾値より大きいか否かに基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
7. 前記バッファは、リクエストが暗号化されているか否かに基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
8. 前記バッファは、所定時間以上蓄積されたリクエストに対して、ビジーメッセージを通知する手段を備えた請求の範囲第１項記載の負荷制御装置。
9. 前記サーバはＷｅｂサーバであり、
   前記バッファは、リクエストのページ表示の表示優先度に基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
10. 前記リクエストはＴＣＰコネクションによってクライアントから負荷制御装置に送信され、
    前記バッファは、クライアントと負荷制御装置との間に接続された他のＴＣＰコネクションの有無またはＴＣＰコネクションの数および当該リクエストがＴＣＰコネクションの最初のリクエストであるか否かに基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
11. レスポンスにブラウザが自動取得すべきページ構成要素のＵＲＬが指し示されている場合に、レスポンス送信先の識別情報と当該ＵＲＬとの組を一時的に記憶する手段を備え、
    前記バッファは、リクエストの送信元の識別情報とＵＲＬとの組が、一時記憶されたレスポンス送信先の識別情報とＵＲＬとの組と一致するか否かに基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
12. 前記リクエストが属するセッションの進行状況に基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
13. 前記サーバで処理されたリクエストが属するセッションのセッション識別情報を一定期間キャッシュする手段と、キャッシュされているセッション識別情報を持つか否かに基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
14. 前記バッファは、クライアントから送信されたトラヒックの不正アクセスの疑わしさに基づきリクエストを優先制御する手段を備えた請求の範囲第１項記載の負荷制御装置。
15. 汎用の情報処理装置にインストールすることにより、その汎用の情報処理装置に、請求の範囲第１項ないし第１４項のいずれかに記載の負荷制御装置の機能に相応する機能を実現させるプログラム。
16. 請求の範囲第１５項記載のプログラムが記録された前記汎用の情報処理装置が読取可能な記録媒体。
17. クライアントとサーバとの間に配置され、前記クライアントから受信したリクエストを前記サーバに送信し、当該リクエストに対して前記サーバから返されるレスポンスを前記クライアントに送信する負荷制御装置が実行する負荷制御方法において、
    前記サーバに送信済みであるが前記サーバからレスポンスが返されていない応答待ちリクエストの数を制限するステップと、
    前記制限するステップは、
    応答待ちリクエスト数が閾値に達しているならば、受信したリクエストをバッファに一時蓄積するステップと、
    応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの送信を待ち合わせるステップと、
    応答待ちリクエスト数が閾値未満の場合は、前記バッファからリクエストを１つ選択して取り出し、応答待ちリクエスト数を１インクリメントさせた後、サーバに当該リクエストを送信するステップと、
    受信したレスポンスを、当該レスポンスのリクエストを送信したクライアントに対して返送し、応答待ちリクエスト数を１デクリメントするステップと、
    を有し、
    前記サーバの実行状況を監視するステップと、
    前記監視するステップの監視結果に基づいて単位時間あたりに前記サーバが処理したリクエスト数である、現在の応答待ちリクエスト数の閾値に対するスループットを測定するステップと、
    前記バッファに一時蓄積されているリクエストの数が所定数に達しているか否かを判定するステップと、
    前記判定するステップの判定結果に基づいて、リクエストの数が所定数に達している場合、現在の応答待ちリクエスト数の閾値に対するスループットを記録し、現在の応答待ちリクエスト数の閾値に対して記録したスループットが当該現在の応答待ちリクエスト数の閾値より小さい閾値に対して記録したスループットを上回る場合には、当該現在の応答待ちリクエスト数の閾値を増加させ、現在の応答待ちリクエスト数の閾値に対して記録したスループットが当該現在の応答待ちリクエスト数の閾値より小さい閾値に対して記録したスループットを下回る場合には、当該現在の応答待ちリクエスト数の閾値を減少させるステップと、
    を有することを特徴とする負荷制御方法。
18. 前記閾値は１よりも大きな値である請求の範囲第１７項記載の負荷制御方法。
19. 前記サーバと自己との間のＴＣＰコネクション同時接続数が前記応答待ちリクエスト数の閾値以下となるように自己と前記クライアントとの間のＴＣＰコネクションを集約するステップを有する請求の範囲第１７項記載の負荷制御方法。

Images