JP4916809B2 - 負荷分散制御装置および方法 - Google Patents

Description

本発明は、１つ以上のクライアントと２つ以上のサーバとの間に配置され、クライアントから受信したリクエストをサーバのいずれかに転送し、当該リクエストに対してサーバから返却されるレスポンスをクライアントに転送する装置に利用する。特に、サーバへのリクエストの分配とスケジューリングに関する。

なお、本明細書では、Ｗｅｂサーバに着目して説明するが、他のサーバへの本発明の適用も可能であり、同様の効果を発揮する。

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

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

本明細書では、Ｗｅｂサービスを行うサーバシステム全体をＷｅｂサーバ、また、Ｗｅｂサーバ上でリクエストに応じたコンテンツを生成する機能をＷｅｂアプリケーションと呼ぶ。

Ｗｅｂサービスが普及するにつれて、サービスを快適に利用していくための課題も明らかになりつつある。その課題の一つとして、サービス利用が集中した際の過剰トラヒックへの対応が挙げられる。サービス利用の集中の例として、人気の高い銘柄の株やチケットの売買によるリクエスト集中や、災害発生時の見舞呼などがある。また、悪意のあるクライアントによって、再送を過剰に要求するＦ５アタックなどの無意味なリクエストが大量に送信される場合もある。これらの要因によって、Ｗｅｂサーバにリクエストが過剰に送信されると、Ｗｅｂサーバにおいて、リクエストの取りこぼしや、リクエスト処理性能の低下が生じる。

図１は、リクエスト過剰によるＷｅｂサーバのリクエストの取りこぼし、リクエストの処理性能の低下を示す実験結果である。実験では、あるＷｅｂサーバに対して、入力リクエストレート、すなわち、単位時間当りのリクエスト数（ｒｐｓ）を変化させてリクエストを送信する。そして、スループット、すなわち、Ｗｅｂサーバが単位時間当りに完了できたリクエスト数（ｒｐｓ）を計測している。

図１の横軸は入力リクエストレートであり、縦軸はスループットである。入力リクエストレートとスループットとの差が、Ｗｅｂサーバが取りこぼしたリクエストレートとなる。図１に示されるように、入力リクエストレートが一定範囲内であるならば、入力レートに対してスループットは比例する（図１破線（ａ））。しかしながら、Ｗｅｂサーバの最大スループットに達すると、Ｗｅｂサーバがリクエストを取りこぼすようになる。さらに、リクエストレートが上昇するとスループットが低下に転じる（図１破線（ｂ））。本明細書では、図１破線（ｂ）に従う状態を、サーバの過負荷状態と呼ぶ。

リクエスト過剰の対策として、大きく負荷分散と負荷制御とに分けられる。負荷分散はサーバ台数を追加してリクエストをサーバ間で振り分けることで、システム全体の最大性能を向上させる手法である。負荷分散によって、図１の破線（ｂ）が破線（ｄ）のように上方向にシフトされ、破線（ａ）に沿う領域が拡大される。リクエストの振り分けアルゴリズムとして、一定順序でサーバに対してリクエストを振り分けるラウンドロビン方式、接続中のコネクション数が最も少ないサーバにリクエストを振り分ける最小コネクション数方式、などが知られている（例えば、非特許文献１参照）。

負荷制御は、システムの最大性能を超える過剰リクエストを受信した場合に、一部のリクエスト量を制限することで、サーバの過負荷を防ぐ手法である。すなわち、負荷制御では、リクエスト量がサーバの最大性能を超えても、図１の破線（ｃ）の維持を試みる。リクエスト量を制限する指標として、（ａ）ＴＣＰコネクション数、（ｂ）サーバ負荷状態などが用いられる。（ａ）ＴＣＰコネクション数は、同時接続可能なＴＣＰコネクション数の上限を定めることによって、サーバの過負荷回避を試みる。この手法は、Ａｐａｃｈｅなどの汎用的なＨＴＴＰサーバなどで用いられている。

Ｗ．Ｚｈａｎ，"Ｌｉｎｕｘ Ｖｉｒｔｕａｌ Ｓｅｒｖｅｒ ｆｏｒ Ｓｃａｌａｂｌｅ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅｓ"，Ｏｔｔａｗａ Ｌｉｎｕｘ Ｓｙｍｐｏｓｉｕｍ，２０００

上述した負荷分散では、ラウンドロビン方式や最小コネクション数方式では、リクエストやコネクション毎の負荷の偏りから、サーバの負荷を均衡化させることは難しい。その結果、サーバ台数増加分に見合う性能向上効果（台数効果）が得られていない。また、システム全体の最大性能を超える過剰トラヒックに対しては、依然としてスループットの低下が生じる。

また、上述した負荷制御では、リクエストの種類、クライアントの回線速度などによって、ＴＣＰコネクション毎にその負荷が大きく異なる。このため、ＴＣＰコネクション数の上限に達する前にサーバが過負荷となる。逆に、サーバリソースが余っていても、ＴＣＰコネクション数が上限に達していることによって、新たなＴＣＰコネクションを確立できない、といった問題が生じる。（ｂ）サーバの負荷状態は、ＣＰＵ占有率、メモリ使用量、応答時間などからサーバの負荷状態を推測し、過負荷か否かを判定するものである。

過負荷と判定した場合は、新規リクエストの転送または拒絶など、サーバの負荷を軽減させるためのトラヒック制御を行う。しかし、過負荷と判定されてから初めてトラヒック制御を行うため、一時的なサーバの性能低下が免れない。また、サーバの過負荷からの回復を検出するまでの遅延時間が生じるため、その間、計算リソースの利用効率が低下する、といった問題が生じる。

負荷分散と負荷制御とを組み合わせた装置もある。すなわち、過負荷と判定されたサーバをリクエストの振り分け候補から外し、過負荷となっていないサーバに対してのみリクエストを振り分ける手法である。しかしながら、前述したように、従来の負荷制御手法では（１）サーバの負荷を正確に測ることができない、（２）過負荷および過負荷から回復の検出に遅延時間が生じる。故に、過負荷となっているにも関わらずそのサーバにリクエストを送信されるという問題や、余裕があるにも関わらずサーバにリクエストが振り分けられない、という問題が生じている。

本発明は、このような背景の下に行われたものであって、特定のサーバに対して過剰な負荷がかからず、サーバの負荷を均等化でき、サーバ台数増加分に見合う性能向上が得られる負荷分散制御装置および方法を提供することを目的とする。

本発明の負荷分散制御装置は、負荷制御と負荷分散とを融合し、過剰リクエストに際しても、サーバ台数に比例したスループットを得ることができる。負荷制御手法として、サーバに送信済みであるが、サーバからレスポンスが返却されていないリクエスト、すなわち、応答待ちリクエストの数を制限する。

本手法は、クライアントとサーバとの間に配置され、両者のリクエストおよびレスポンスの送受信を仲介する。すなわち、クライアントから受信したリクエストをサーバに転送し、さらにサーバから返却されるレスポンスをクライアントに転送する。このとき、本手法は、応答待ちリクエスト数が閾値を超える場合は、最大性能を発揮するのに必要十分なリクエストがサーバに供給されているとみなす。そして、リクエストをバッファリングし、応答待ちリクエスト数が閾値を下回るまで、リクエストの送信を待ち合わせる。

本手法に基づき負荷制御を実施することで、過剰リクエストを受信した場合でも、サーバの性能を発揮するための必要十分なリクエストのみがサーバに送信される。このため、サーバの性能を制限することなく、サーバ過負荷を回避できる。そこで、本発明では、応答待ちリクエスト数の制限による負荷制御手法を負荷分散に拡張する。

本発明では、この負荷制御方法を拡張し、受信したリクエストの転送先サーバが複数候補ある場合は、そのうち応答待ちリクエストの数が閾値に達していないサーバに対してリクエストを送信するようにする。転送先サーバの全候補が応答待ちリクエスト数の閾値に達している場合は、そのリクエストをバッファに格納し、いずれかのサーバで応答待ちリクエスト数の閾値が下回るまで転送を待ち合わせる。

応答待ちリクエスト数が閾値に達しているサーバへのリクエストの振り分けを見合わせることで、各サーバが過負荷となることが確実に回避される。さらに、リクエストまたはレスポンス単位で細粒度に個々のサーバへのリクエスト転送の可否を判定する。故に、従来手法のように、サーバの過負荷検出または過負荷からの回復検出に要する遅延時間がない。この結果、各サーバの計算リソースの利用効率低下といった問題も生じない。このため、応答待ちリクエスト数が閾値に達しているか否かに応じてリクエストの振り分け先を判定することで、サーバ台数に比例したスループット向上が可能となる。

さらに本発明では、応答待ちリクエスト数が閾値に達していないサーバが複数ある場合は、各サーバの応答待ちリクエスト数に基づいてサーバを選択することができる。応答待ちリクエスト数の増加は、そのサーバで多重に実行されているリクエスト数の増加を意味する。したがって、応答待ちリクエスト数が大きいサーバほど、リクエストを転送してからレスポンスが返ってくるまでの応答時間が大きくなる。故に、応答待ちリクエスト数に基づいてサーバを選択することで、サーバから返送されるレスポンスの応答時間を最小化することができる。

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

ここで、本発明の特徴とするところは、サーバへ送信済みのリクエストのうち、サーバからレスポンスが返却されていないリクエストである応答待ちリクエストの数をサーバ毎に計測する手段と、この計測する手段の計測結果に基づきいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合に、閾値を下回っているサーバのいずれかにリクエストを転送する手段と、全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合に、リクエストをバッファに一時蓄積する手段と、いずれかのサーバの応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの転送を待ち合わせる手段とを備えたところにある。

あるいは、本発明の特徴とするところは、リクエストを処理できるサーバの範囲である転送可能範囲を特定する手段と、サーバへ送信済みのリクエストのうち、サーバからレスポンスが返却されていないリクエストである応答待ちリクエストの数をサーバ毎に計測する手段と、この計測する手段の計測結果に基づき転送可能範囲内のいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合に、閾値を下回っているサーバのいずれかにリクエストを転送する手段と、転送可能範囲内の全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合に、リクエストを転送可能範囲毎に設けられたバッファに一時蓄積する手段と、転送可能範囲内のいずれかのサーバの応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの転送を待ち合わせる手段とを備えたところにある。

このときに、転送可能範囲としてリクエストを処理できるサーバのいずれかから一つのサーバを特定することもできる。前記転送可能範囲として一つのサーバを特定する手段は、例えば、リクエストを処理できるサーバのいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合には、閾値を下回っているサーバから一つのサーバを選択し、リクエストを処理できるサーバの全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合には、バッファ中で転送を待ち合わせているリクエスト数に基づき一つのサーバを選択する。

また、応答待ちリクエスト数がその閾値を下回っているサーバの中から、各サーバの応答待ちリクエスト数に基づきリクエストの転送先サーバを選択する手段を備えることができる。

さらに、転送可能範囲内毎に設けられるバッファ間でリクエスト転送順序を優先制御することもできる。

また、本発明を負荷分散制御方法の観点から観ることもできる。すなわち、本発明は、１つ以上のクライアントと２つ以上のサーバとの間に配置され、前記クライアントから受信したリクエストを前記サーバのいずれかに転送し、当該リクエストに対して前記サーバから返却されるレスポンスを前記クライアントに転送する負荷分散制御装置において実行される負荷分散制御方法である。

ここで、本発明の特徴とするところは、サーバへ送信済みのリクエストのうち、サーバからレスポンスが返却されていないリクエストである応答待ちリクエストの数をサーバ毎に計測し、この計測結果に基づきいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合に、閾値を下回っているサーバのいずれかにリクエストを転送し、全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合に、リクエストをバッファに一時蓄積し、いずれかのサーバの応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの転送を待ち合わせるところにある。

あるいは、本発明の特徴とするところは、リクエストを処理できるサーバの範囲である転送可能範囲を特定し、サーバへ送信済みのリクエストのうち、サーバからレスポンスが返却されていないリクエストである応答待ちリクエストの数をサーバ毎に計測し、この計測結果に基づき転送可能範囲内のいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合に、閾値を下回っているサーバのいずれかにリクエストを転送し、転送可能範囲内の全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合に、リクエストを転送可能範囲毎に設けられたバッファに一時蓄積し、転送可能範囲内のいずれかのサーバの応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの転送を待ち合わせるところにある。

このときに、転送可能範囲としてリクエストを処理できるサーバのいずれかから一つのサーバを特定することもできる。前記転送可能範囲として一つのサーバを特定する際に、例えば、リクエストを処理できるサーバのいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合には、閾値を下回っているサーバから一つのサーバを選択し、リクエストを処理できるサーバの全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合には、バッファ中で転送を待ち合わせているリクエスト数に基づき一つのサーバを選択する。

また、応答待ちリクエスト数がその閾値を下回っているサーバの中から、各サーバの応答待ちリクエスト数に基づきリクエストの転送先サーバを選択することができる。

さらに、転送可能範囲内毎に設けられるバッファ間でリクエスト転送順序を優先制御することもできる。

また、本発明をプログラムの観点から観ることもできる。すなわち、本発明は、汎用の情報処理装置にインストールすることにより、その汎用の情報処理装置に、本発明の負荷分散制御装置の機能に相応する機能を実現させるプログラムである。本発明のプログラムは記録媒体に記録されることにより、前記汎用の情報処理装置は、この記録媒体を用いて本発明のプログラムをインストールすることができる。あるいは、本発明のプログラムを保持するサーバからネットワークを介して直接前記汎用の情報処理装置に本発明のプログラムをインストールすることもできる。

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

本発明によれば、過剰リクエスト受信時におけるサーバの性能低下を回避しつつ、サーバ台数に見合う性能向上を得ることができる。

本発明の全実施形態に共通したブロック図を図２に示す。本発明は、リクエストを発行する１つ以上のクライアント１−１〜１−ｎと、リクエストに対応するレスポンスを返す２つ以上のサーバＳ１〜ＳＮ、および、リクエストおよびレスポンスを転送する負荷分散制御装置３とからなる。クライアント１−１〜１−ｎと負荷分散制御装置３とはインターネットなどのネットワーク２を介して接続される。負荷分散制御装置３がクライアント１−ｉ（ｉ＝１，…，ｎ）からリクエストを受信すると、いずれかのサーバＳｉに対してリクエストを転送する。サーバＳｉからリクエストに対するレスポンスが返却されると、負荷分散制御装置３はリクエストの送信元にレスポンスを転送する。

負荷分散制御装置３は、リバースＰｒｏｘｙ、Ｗｅｂアクセラレータ、Ｆｉｒｅｗａｌｌ、負荷分散システムなどの既存装置を拡張して実装してもよい。なお、本明細書では、負荷分散制御装置３がＮ台のサーバに接続されている場合に、各サーバを記号Ｓｉ（ｉ＝１，…，Ｎ）と表す。なお、以下の説明では、負荷分散制御装置の符号“３”は省略する。

（第一の実施形態）
本発明の第一の実施形態のリクエスト振り分け機能の概念図を図３に示す。負荷分散制御装置が受信したリクエストを負荷分散制御装置に接続されたいずれのサーバ上でも処理できると仮定する。このとき、負荷分散制御装置は、受信したリクエストを全てのサーバで共有するバッファ１０に格納する。そして、転送先サーバ選択部１１により、サーバの実行状況に応じて、バッファ１０からリクエストを取り出し、各サーバにリクエストを振り分ける。

負荷分散制御装置によるリクエスト振り分け方法について具体的に述べる。負荷分散制御装置は、サーバに送信済みであるが、まだ、レスポンスが返されていないリクエスト数、すなわち応答待ちリクエスト数を監視する。全てのサーバで応答待ちリクエスト数が定められた閾値を超える場合は、受信したリクエストをバッファリングする。そして、いずれかのサーバで応答待ちリクエスト数が閾値を下回るまで、リクエストの送信を見合わせる。以下では、サーバＳｉの応答待ちリクエスト数をＸｉ、サーバＳｉの応答待ちリクエスト数の閾値をＲｉと表記する。

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

図４中のリクエスト受信処理の実行手順を図５に示す。リクエストを受信した場合に、負荷分散制御装置はそのリクエストをバッファ１０に格納する。次に、各サーバＳｉの応答待ちリクエスト数Ｘｉを検査し、応答待ちリクエスト数がその閾値Ｒｉを下回っているサーバ、すなわちＸｉ＜Ｒｉが成り立つサーバＳｉが存在するか否かを検査する。

Ｘｉ＜Ｒｉが成り立つサーバＳｉが存在しない場合は、全てのサーバに性能を発揮するための必要十分なリクエストが供給されていることを意味するため、リクエストのサーバへの転送を見合わせる。一方、Ｘｉ＜Ｒｉが成り立つサーバＳｉは、サーバの最大性能を発揮するために必要十分なリクエストが供給されていないことを意味する。故に、転送先サーバ選択処理において、Ｘｉ＜Ｒｉが成り立つサーバＳｉから当該リクエストを送信すべきサーバを選択する。ここで選択されたサーバをＳｊと表記する。次に、バッファからリクエストを一つ取り出す。なお、後述するレスポンス受信処理によって、Ｘｉ＜Ｒｉが成り立つサーバＳｉが存在する場合には、バッファ１０中にあるリクエストは当該受信処理でバッファ１０に格納したリクエスト１つのみであることに注意されたい。次に、選択されたサーバＳｊの応答待ちリクエスト数Ｘｊを１インクリメントする。最後に、取り出したリクエストを選択されたサーバＳｊに転送する。

図５中の転送先サーバ選択処理の実施例を列挙する。
・Ｘｉ＜Ｒｉとなるサーバに対し、ラウンドロビン方式に基づき一定順序で、リクエストを振り分ける。
・Ｘｉ＜Ｒｉとなるサーバのうち、応答待ちリクエスト数Ｘｉが最も小さいサーバを選択する。すなわち、応答待ちリクエスト数を均一化させる。
・Ｘｉ＜Ｒｉとなるサーバのうち、応答待ちリクエスト数と閾値との比Ｘｉ／Ｒｉが最も小さいサーバを選択する。すなわち、各サーバの閾値に対する応答待ちリクエスト数の割合が均一化されるようにリクエストを転送する。
・サーバＳｉの応答待ちリクエスト数に対するスループット（単位時間当りのリクエスト完了数など）を予め計測しておく。ここで、応答待ちリクエスト数がＸｉであるときのサーバＳｉの平均スループットをＴｉ［Ｘｉ］と表記する。このとき、Ｘｉ＜Ｒｉとなるサーバのうち、Ｔｉ［Ｘｉ＋１］−Ｔｉ［Ｘｉ］が最大となるサーバを選択する。すなわち、当該リクエストの転送によるシステム全体のスループット向上効果が最大となるように、リクエストの転送先を選択する。

図４中のレスポンス受信処理の実施例を図６に示す。まず負荷分散制御装置は、そのレスポンスに対応するリクエストを送信したクライアントにリクエストを転送する。次に、レスポンスの返送に伴うサーバの応答待ちリクエスト数の減少を補填するため、レスポンスを返送したサーバに対し、バッファ中のリクエストの転送を試みる。ここで、レスポンスを返送したサーバをＳｋと表記する。また、バッファ中にリクエストが存在する場合は必ず、Ｓｋ以外の全てのサーバにおいて応答待ちリクエスト数がその閾値に達していることに注意されたい。

まず、バッファ１０中にリクエストが存在するか否かを検査する。バッファ１０中にリクエストが存在しない場合は、レスポンスを返送したサーバＳｋの応答待ちリクエスト数Ｘｋを１デクリメントし、当該処理を終了する。一方で、バッファ１０中にリクエストが格納されている場合は、リクエスト選択処理によってバッファからリクエストを一つ選択する。次に、選択したリクエストを、レスポンスを返送したサーバＳｋに転送する。

図６のリクエスト選択処理では、バッファ１０としてＦＩＦＯ(First-In First-Out)方式や、タイムアウトするまでの時間長が昇順となるようにリクエストを並べるＥＤＦ(Earliest
Deadline First)方式などを用いて、リクエストを選択できる。また、リクエストの重要度や要求品質に応じた優先制御を実施することもできる。

（第二の実施形態）
第一の実施形態では、負荷分散制御装置が受信したリクエストを負荷分散制御装置に接続されたいずれのサーバ上でも処理できる、と仮定していた。しかしながら、サーバのアプリケーションによっては、受信したリクエストによって、そのリクエストを処理できるサーバの範囲が異なる場合がある。

例えば、Ｗｅｂサーバによるオンラインショッピングサイトでは、一連の購入手続き（セッション）が終了するまで、同じクライアントからのリクエストを同じサーバ上に送信しなければならない場合がある。したがって、全てのサーバに転送可能なリクエストに加え、特定のサーバに転送しなければならないリクエストを考慮する必要がある。第一の実施形態では、全てのサーバ間でバッファ１０を共有している。このため、特定のサーバに転送しなければならないリクエストが混在すると、バッファ１０の方式によっては、サーバのリソースが十分にあるにも関わらず、サーバにリクエストが転送できなくなる（ブロッキングされる）場合が生じる。その結果、サーバリソースの利用効率が低下する。

バッファ１０の方式としてＦＩＦＯを仮定した場合のブロッキング例を図７に示す。図７では、負荷分散制御装置はサーバＳ１、Ｓ２、Ｓ３に接続されている。図７のバッファ（ＦＩＦＯ）１０内の○印はリクエストを示し、○印内部の数字は転送可能なサーバ番号を示す。なお、サーバ番号が※である場合は、全てのサーバに転送可能なリクエストであることを示す。また、図７には、現在の応答待ちリクエスト数Ｘｉとその閾値Ｒｉとをサーバ毎に示している。

例えば、サーバＳ２の応答待ちリクエスト数Ｘ２は“８”であり閾値Ｒ２は“１０”である。図７から、サーバＳ１を除く他のサーバは、応答待ちリクエスト数がその閾値を下回っており、リクエストを受付可能な状態である。このとき、バッファ１０の先頭で待機しているリクエストは、サーバＳ１以外では処理できないと仮定すると、サーバＳ１の応答待ちリクエスト数はその閾値に達しているため、先頭のリクエストを転送できない。その結果、サーバＳ２、Ｓ３がリクエストを受付可能であっても、先頭リクエストがサーバＳ１に転送されるまで、後続のリクエストを転送できなくなる。

図７の問題は、先頭のリクエストがブロッキングされても、後続のリクエストを先に転送できるように、バッファ１０を拡張することによっても解決できる。しかしながら、サーバに転送可能なリクエストをバッファ１０から検索する処理が必要となるため、計算コストが飛躍的に増加する。

バッファ１０中のリクエストを検索することなくブロッキングの問題を解決するため、リクエストをサーバに送信できる範囲毎に別のバッファに格納することができるようにする。説明を簡単化するために、いずれか一つの特定サーバにのみ送信できるリクエストおよび全てのサーバに送信できるリクエストの２種類を仮定する。そして、第二の実施形態では、図８に示すように、転送可能範囲特定部１２により、特定のサーバに転送しなければならないリクエストはサーバ毎に設けられたバッファＱ０〜ＱＮに、全てのサーバに転送可能なリクエストを全サーバで共有するバッファに格納する。以下では、サーバＳｉ（ｉ＝１，…，Ｎ）に転送しなければならないリクエストを格納するためのバッファをＱｉと表記する。また、いずれのサーバにも転送可能なリクエストを格納するためのバッファをＱ０と表記する。本明細書では、Ｗｅｂサーバにおけるセッション処理を例にとり、セッション実行中のリクエストは、常に同じサーバに送信しなければならないとする。

第二の実施形態の実行手順は第一の実施形態の図４と同様である。ただし、図４中のリクエスト受信処理、レスポンス受信処理はそれぞれ第一の実施形態と異なる。

第二の実施形態のリクエスト受信処理の実行手順を図９に示す。まずリクエストを受信すると、まず当該リクエストをいずれのサーバに対しても転送可能か、または特定のサーバにのみ転送可能かを判定する。

転送可能範囲となるサーバの判定処理では、まずセッション処理を実行中のリクエストか否かを判定する。Ｗｅｂサーバでは一般的に、セッション処理の開始時にセッション識別番号を発行する。そして、セッション識別番号を、ＨＴＴＰのＣｏｏｋｉｅなどを用いてレスポンスに付与し、クライアントに通知する。クライアントは、その後のリクエストにＷｅｂサーバから通知されたセッション識別番号を付与することで、Ｗｅｂサーバはリクエストが属するセッションを識別する。

したがって、負荷分散制御装置において、セッション識別番号が付与されているレスポンスを転送する際に、レスポンスの返送元のサーバとそのセッション識別番号とを記憶させる。そして、リクエストを受信する度に、リクエストにセッション識別番号が含まれているか否かを検査する。リクエストにセッション識別番号が含まれている場合は、当該リクエストは非セッション処理とみなし、いずれのサーバにも転送してよいとする。一方で、登録されているセッション番号が付与されているならば、そのセッション識別番号を発行したサーバを転送先サーバとする。

転送可能範囲の判定処理にてリクエストをいずれのサーバに対しても転送できると判定された場合には、まず、当該リクエストを、いずれのサーバにも送信可能なリクエストを格納するためのバッファＱ０に格納する。次に、応答待ちリクエスト数Ｘｉがその閾値Ｒｉを下回っているサーバがあるか否かを判定する。全てのサーバで、Ｘｉ＜Ｒｉが成り立たない場合は、リクエストの転送を待ち合わせ、本処理を終了する。一方で、Ｘｉ＜Ｒｉが成り立つサーバがある場合は、転送先サーバ選択処理にてＸｉ＜Ｒｉが成り立つサーバの中から、リクエストの転送先となるサーバＳｊを選択する。

第二の実施形態における転送先サーバ選択処理は、第一の実施形態における転送先サーバの選択処理と同様の手法を用いて実現できる。次に、バッファＱ０からリクエストを一つ取り出す。次に、選択されたサーバＳｊの応答待ちリクエスト数Ｘｊを１インクリメントする。最後に、取り出したリクエストを選択されたサーバＳｊに転送する。

転送可能範囲の判定処理にてリクエストの転送先サーバＳｊが特定された場合には、まず、リクエストを特定されたサーバＳｊ用のバッファＱｊに格納する。次に、特定されたサーバＳｊにおいて、Ｘｊ＜Ｒｊが成り立つか判定する。Ｘｊ＜Ｒｊが成り立たない場合は、リクエストの転送を待ち合わせ、本処理を終了する。一方で、Ｘｊ＜Ｒｊが成り立つ場合は、バッファＱｊからリクエストを一つ取り出す。次に、選択されたサーバＳｊの応答待ちリクエスト数Ｘｊを１インクリメントする。最後に、取り出したリクエストを選択されたサーバＳｊに転送する。

第二の実施形態のレスポスン受信処理の実行手順を図１０に示す。まず負荷分散制御装置は、受信したレスポンスに対応するリクエストを送信したクライアントに、当該レスポンスを転送する。次に、レスポンスの返送に伴うサーバの応答待ちリクエスト数の減少を補填するために、返送したサーバに対し、バッファ中のリクエストの転送を試みる。ここで、レスポンスを返送したサーバをＳｋと表記する。まず、サーバＳｋに送信できるリクエストを有している可能性がある、バッファＳ０、またはバッファＳｋ中にリクエストが存在するか否かを検査する。バッファ中にリクエストが存在しない場合は、レスポンスを返送したサーバＳｋの応答待ちリクエスト数Ｘｋを１デクリメントし、当該処理を終了する。一方で、バッファ中にリクエストが格納されている場合は、リクエスト選択処理によってバッファＱ０またはＱｋからリクエストを一つ選択する。次に、選択したリクエストを、レスポンスを返送したサーバＳｋに転送する。

図１０のリクエスト選択処理では、リクエストにタイムスタンプを振っておき、より早く負荷分散制御装置に到達したリクエストを先に選択することもできる。また、バッファＱ０とバッファＱｋとをラウンドロビン方式に基づき、交互に出力することもできる。また、バッファＱ０とバッファＱｋとの間のリクエスト選択にて、ＰＱ(Priority Queuing)、ＷＲＲ(Waited Round Robin)、ＷＦＱ(Waited Fair Queuing)といった既存の優先制御手法を用いることができる。

例えば、前述したセッション識別番号に基づきリクエストの格納先バッファを決定している場合には、バッファＱｋには既に開始済みのセッションに属するリクエストが格納される。一方で、バッファＱ０には、非セッション処理のリクエストやセッション開始要求のリクエストが格納される。故に、バッファＱ０よりバッファＱｋに属するリクエストを高優先にサーバに転送することで、サーバ混雑時においても、開始済みのセッションを効率良く保護することが可能となる。

（第三の実施形態）
第一および第二の実施形態では、バッファの格納後にリクエストの転送先を決定している。しかしながら、図１１のように、転送可能サーバ特定部１３により、予めリクエストのバッファへの格納前に、その転送先サーバを決定することもできる。転送先サーバ毎に独立したバッファを持つことができるため、サーバ毎のリクエストの優先制御を、他のサーバに影響されることなく実現できる、という利点が得られる。以下では、サーバＳｉ（ｉ＝１，…，Ｎ）に送信されるリクエストを格納するためのバッファをＱｉと表記する。

第三の実施形態の実行手順は第一の実施形態の図１と同様である。ただし、図１中のリクエスト受信処理およびレスポンス受信処理はそれぞれ第一の実施形態と異なる。

第三の実施形態のリクエスト受信処理の実行手順を図１２に示す。まずリクエストを受信すると、当該リクエストをいずれのサーバに対しても転送できるか、または、特定のサーバにのみ転送できるかを判定する。判定方法は、第二の実施形態と同様の方法を利用できる。

いずれのサーバに対しても転送できると判定された場合は、次に、転送先サーバの選択処理にて、リクエストの転送先サーバＳｊを決定する。ここで、転送サーバの選択処理の実施例として以下がある。
・いずれかのサーバの応答待ちリクエスト数がその閾値を下回っている場合には、第一の実施形態の転送サーバの選択処理と同様の手法が利用できる。
・全てのサーバの応答待ちリクエスト数がその閾値に達している場合には、ラウンドロビン方式に基づき、順番にリクエストの転送先サーバを選択する。または、バッファ中のリクエスト数が最も少ないサーバを選択する。すなわち、バッファ中のリクエスト数が均一化されるように、リクエストの転送先サーバを決定する。または、各サーバＳｉのスループット（単位時間当りの完了リクエスト数）を計測しておく。スループットに対するバッファ中のリクエスト数の割合が最も小さいサーバを選択する。すなわち、バッファ中の待機する時間が最も短くなるように、リクエストの転送先サーバを決定する。

特定のサーバにのみ転送できる場合は、そのサーバをリクエストの転送先サーバＳｊとする。次に、転送先サーバＳｊのバッファＱｊに、当該リクエストを格納する。次に、サーバＳｊにおいて、Ｘｊ＜Ｒｊが成り立つか判定する。Ｘｊ＜Ｒｊが成り立たない場合は、リクエストの転送を待ち合わせ、本処理を終了する。一方で、Ｘｊ＜Ｒｊが成り立つ場合は、バッファＱｊからリクエストを一つ取り出す。次に、選択されたサーバＳｊの応答待ちリクエスト数Ｘｊを１インクリメントする。最後に、取り出したリクエストを選択されたサーバＳｊに転送する。

第三の実施形態のレスポンス受信処理の実行手順を図１３に示す。まず負荷分散制御装置は、受信したレスポンスに対応するリクエストを送信したクライアントに、当該レスポンスを転送する。次にレスポンスの返送に伴うサーバの応答待ちリクエスト数の減少を補填するために、返送したサーバに対しバッファ中のリクエストの転送を試みる。ここで、レスポンスを返送したサーバをＳｋと表記する。

まず、サーバＳｋに対して転送すべきリクエストが格納されるキューＳｋ中にリクエストが存在するか否かを検査する。バッファ中にリクエストが存在しない場合は、レスポンスを返送したサーバＳｋの応答待ちリクエスト数Ｘｋを１デクリメントし、当該処理を終了する。一方で、バッファ中にリクエストが格納されている場合は、リクエスト選択処理によってＱｋからリクエストを一つ選択する。次に、選択したリクエストを、レスポンスを返送したサーバＳｋに転送する。

（第四の実施形態）
第四の実施形態は、汎用の情報処理装置にインストールすることにより、その汎用の情報処理装置に、本実施形態の負荷分散制御装置の機能に相応する機能を実現させるプログラムである。このプログラムは、記録媒体に記録されて汎用の情報処理装置にインストールされ、あるいは通信回線を介して汎用の情報処理装置にインストールされることにより当該汎用の情報処理装置に、本実施形態の負荷分散制御装置に相応する機能を実現させることができる。汎用の情報処理装置は、例えば、汎用のパーソナル・コンピュータである。

本発明によれば、特定のサーバに対して過剰な負荷がかからず、サーバの負荷を均等化でき、サーバ台数増加分に見合う性能向上が得られるので、ネットワーク事業者にとってはネットワークを効率良く運用することに寄与することができる。また、ネットワークユーザにとってはサービス品質の向上に寄与することができる。

過剰リクエストによる性能低下の様子を示す図。 全実施形態に共通のブロック図。 第一の実施形態のリクエスト振り分け機能を示す図。 負荷分散制御装置の処理手順を示すフローチャート。 第一の実施形態のリクエスト受信処理の実行手順を示すフローチャート。 第一の実施形態のレスポンス受信処理の実行手順を示すフローチャート。 リクエストのブロッキングの例を示す図。 第二の実施形態のリクエスト振り分け機能を示す図。 第二の実施形態のリクエスト受信処理手順を示すフローチャート。 第二の実施形態のレスポンス受信処理の実行手順を示すフローチャート。 第三の実施形態のリクエスト振り分け機能を示す図。 第三の実施形態のリクエスト受信処理の実行手順を示すフローチャート。 第三の実施形態のレスポンス受信処理の実行手順を示すフローチャート。

符号の説明

１−１〜１−ｎ クライアント
２ ネットワーク
３ 負荷分散制御装置
１０、Ｑ０〜ＱＮ バッファ
１１ 転送先サーバ選択部
１２ 転送可能範囲特定部
１３ 転送可能サーバ特定部
Ｓ１〜ＳＮ サーバ

Claims (6)

1. １つ以上のクライアントと２つ以上のサーバとの間に配置され、前記クライアントから受信したリクエストを前記サーバのいずれかに転送し、リクエストに対して前記サーバから返却されるレスポンスを前記クライアントに転送する負荷分散制御装置において、
   リクエストを処理できるサーバの範囲である転送可能範囲を特定する手段と、
   サーバへ送信済みのリクエストのうちサーバからレスポンスが返却されていないリクエストである応答待ちリクエストを複数、サーバに保持させる手段と、
   応答待ちリクエストの数をサーバ毎にリアルタイムで計測する手段と、
   この計測する手段の計測結果に基づき、
   転送可能範囲内のいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合に、閾値を下回っているサーバのいずれかにリクエストを転送し、そのサーバに対応する応答待ちリクエスト数をインクリメントするためのリクエストを転送する手段と、
   レスポンスがサーバから返却される度にそのサーバの属する転送可能範囲に設けられたバッファ中に転送を待ち合わせているリクエストが存在するか否かを検査し、バッファ中に転送を待ち合わせているリクエストが存在しない場合にはそのサーバに対応する応答待ちリクエスト数をデクリメントし、バッファ中に転送を待ち合わせているリクエストが存在する場合にはバッファから選択した一つのリクエストを前記レスポンスを返却したサーバに転送するためのレスポンスを返却する手段と、
   転送可能範囲内の全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合に、リクエストを転送可能範囲毎に設けられたバッファに一時蓄積する手段と、
   転送可能範囲内のいずれかのサーバの応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの転送を待ち合わせる手段と
   を備え、
   前記転送可能範囲を特定する手段は、セッション処理を実行中のリクエストについては、当該セッションを開始処理したサーバを転送先とすることで転送可能範囲を特定する
   ことを特徴とする負荷分散制御装置。
2. １つ以上のクライアントと２つ以上のサーバとの間に配置され、前記クライアントから受信したリクエストを前記サーバのいずれかに転送し、リクエストに対して前記サーバから返却されるレスポンスを前記クライアントに転送する負荷分散制御装置において、
   リクエストを処理できるサーバの範囲である転送可能範囲を特定する手段と、
   サーバへ送信済みのリクエストのうちサーバからレスポンスが返却されていないリクエストである応答待ちリクエストを複数、サーバに保持させる手段と、
   応答待ちリクエストの数をサーバ毎にリアルタイムで計測する手段と、
   この計測する手段の計測結果に基づき、
   転送可能範囲内のサーバにおいて応答待ちリクエスト数が閾値を下回っている場合に、当該サーバにリクエストを転送し、そのサーバに対応する応答待ちリクエスト数をインクリメントするためのリクエストを転送する手段と、
   レスポンスがサーバから返却される度にそのサーバに設けられたバッファ中に転送を待ち合わせているリクエストが存在するか否かを検査し、バッファ中に転送を待ち合わせているリクエストが存在しない場合にはそのサーバに対応する応答待ちリクエスト数をデクリメントし、バッファ中に転送を待ち合わせているリクエストが存在する場合には選択した一つのリクエストを前記レスポンスを返却したサーバに転送するためのレスポンスを返却する手段と、
   転送可能範囲内のサーバにおいて応答待ちリクエスト数が閾値に達している場合に、リクエストを当該サーバ毎に設けられたバッファに一時蓄積する手段と、
   転送可能範囲内のサーバの応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの転送を待ち合わせる手段と
   を備え、
   前記転送可能範囲を特定する手段は、
   セッション処理を実行中のリクエストについては、当該セッションを開始処理したサーバを転送先とすることで転送可能範囲を特定し、
   セッション処理を実行中のリクエスト以外のリクエストについては、リクエストを処理できるサーバのいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合には、閾値を下回っているサーバから選択した一つのサーバを転送先とすることで転送可能範囲を特定し、
   リクエストを処理できるサーバの全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合には、バッファ中で転送を待ち合わせているリクエスト数に基づき選択した一つのサーバを転送先とすることで転送可能範囲を特定する
   ことを特徴とする負荷分散制御装置。
3. 前記転送する手段は、サーバの応答待ちリクエスト数が閾値を下回った場合において、当該サーバへの転送を待ち合わせているリクエストのうち、すでにセッションを開始済みであるクライアントからのリクエストを優先して当該サーバに転送する請求項１記載の負荷分散制御装置。
4. １つ以上のクライアントと２つ以上のサーバとの間に配置され、前記クライアントから受信したリクエストを前記サーバのいずれかに転送し、リクエストに対して前記サーバから返却されるレスポンスを前記クライアントに転送する負荷分散制御装置において実行される負荷分散制御方法において、
   リクエストを処理できるサーバの範囲である転送可能範囲を特定し、
   サーバへ送信済みのリクエストのうち、サーバからレスポンスが返却されていないリクエストである応答待ちリクエストを複数、サーバに保持させ、
   応答待ちリクエストの数をサーバ毎にリアルタイムで計測し、
   この計測結果に基づき、
   転送可能範囲内のいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合に、閾値を下回っているサーバのいずれかにリクエストを転送し、そのサーバに対応する応答待ちリクエスト数をインクリメントし、
   レスポンスがサーバから返却される度にそのサーバに設けられたバッファ中に転送を待ち合わせているリクエストが存在するか否かを検査し、バッファ中に転送を待ち合わせているリクエストが存在しない場合にはそのサーバに対応する応答待ちリクエスト数をデクリメントし、バッファ中に転送を待ち合わせているリクエストが存在する場合には選択した一つのリクエストを前記レスポンスを返却したサーバに転送し、
   転送可能範囲内の全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合に、リクエストを転送可能範囲毎に設けられたバッファに一時蓄積し、
   転送可能範囲内のいずれかのサーバの応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの転送を待ち合わせ、
   前記転送可能範囲を特定する際に、セッション処理を実行中のリクエストについては、当該セッションを開始処理したサーバを転送先とすることで転送可能範囲を特定する
   ことを特徴とする負荷分散制御方法。
5. １つ以上のクライアントと２つ以上のサーバとの間に配置され、前記クライアントから受信したリクエストを前記サーバのいずれかに転送し、リクエストに対して前記サーバから返却されるレスポンスを前記クライアントに転送する負荷分散制御装置において実行される負荷分散制御方法において、
   リクエストを処理できるサーバの範囲である転送可能範囲を特定し、
   サーバへ送信済みのリクエストのうち、サーバからレスポンスが返却されていないリクエストである応答待ちリクエストを複数、サーバに保持させ、
   応答待ちリクエストの数をサーバ毎にリアルタイムで計測し、
   この計測結果に基づき、
   転送可能範囲内のサーバにおいて応答待ちリクエスト数が閾値を下回っている場合に、当該サーバにリクエストを転送し、そのサーバに対応する応答待ちリクエスト数をインクリメントし、
   レスポンスがサーバから返却される度にそのサーバに設けられたバッファ中に転送を待ち合わせているリクエストが存在するか否かを検査し、バッファ中に転送を待ち合わせているリクエストが存在しない場合にはそのサーバに対応する応答待ちリクエスト数をデクリメントし、バッファ中に転送を待ち合わせているリクエストが存在する場合には選択した一つのリクエストを前記レスポンスを返却したサーバに転送し、
   転送可能範囲内のサーバにおいて応答待ちリクエスト数が閾値に達している場合に、リクエストを当該サーバ毎に設けられたバッファに一時蓄積し、
   転送可能範囲内のサーバの応答待ちリクエスト数が閾値を下回るまで前記バッファからのリクエストの転送を待ち合わせ、
   前記転送可能範囲を特定する際に、
   セッション処理を実行中のリクエストについては、当該セッションを開始処理したサーバを転送先とすることで転送可能範囲を特定し、
   セッション処理を実行中のリクエスト以外のリクエストについては、リクエストを処理できるサーバのいずれかのサーバにおいて応答待ちリクエスト数が閾値を下回っている場合には、閾値を下回っているサーバから選択した一つのサーバを転送先とすることで転送可能範囲を特定し、
   リクエストを処理できるサーバの全てのサーバにおいて応答待ちリクエスト数が閾値に達している場合には、バッファ中で転送を待ち合わせているリクエスト数に基づき選択した一つのサーバを転送先とすることで転送可能範囲を特定する
   ことを特徴とする負荷分散制御方法。
6. 前記リクエストを転送する際に、サーバの応答待ちリクエスト数が閾値を下回った場合において、当該サーバへの転送を待ち合わせているリクエストのうち、すでにセッションを開始済みであるクライアントからのリクエストを優先して当該サーバに転送する請求項４記載の負荷分散制御方法。

Images