JP2004171572A - サーバ間の負荷分散方法、負荷分散システム、負荷分散サーバおよびプログラム - Google Patents

Abstract

【課題】 ユーザにより体感されるクライアントサーバシステムのパフォーマンスを、効果的に最適化することを可能とする。
【解決手段】 本発明は、好ましい態様として、１以上のクライアントを含むクライアント群から、複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを受信し一時保留するステップと、過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を特定するステップと、前記待ち時間に基づき、前記サーバ群の中から、一時保留している要求データに応じたデータ処理を行うサーバを選択するステップとを備えることを特徴とするサーバ間の負荷分散方法を提供する。
【選択図】 図１

Description

本発明は、複数サーバ間の負荷分散技術に関連し、より具体的には、クライアントのユーザインタフェースにおいて生成される要求に対するサーバ群の応答時間に基づき、サーバ群において要求に対する処理を分散する技術に関連する。

データ処理における情報およびリソースを共有する方法として、分散処理システムを通信ネットワーク内に配置する方法が広く用いられている。この場合、分散処理システムとは、一群のデータ処理装置が通信ネットワーク（以下、単に「ネットワーク」と呼ぶ）を介して相互に接続され、同じアプリケーションに従った処理を実行する形態のシステムをいう。分散処理システムを実現するにあたり広く採用されているアーキテクチャとして、クライアントサーバシステムがある。クライアントサーバシステムとは、データ処理能力が比較的小さいクライアント側のデータ処理装置（以下、単に「クライアント」と呼ぶ）が、豊富なデータ処理能力およびリソースを備えるサーバ側のデータ処理装置（以下、単に「サーバ」と呼ぶ）に対し、データ処理やデータ提供を要求する形態のシステムである。

近年、移動体クライアントの利用が広く普及してきた結果、人々の情報交換の方法が、私用であるか商用であるかを問わず、大きく変化してきている。例えば、よく知られるクライアントサーバシステムとして、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（以下、単に「Ｗｅｂ」と呼ぶ）がある。Ｗｅｂにおいては、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）と呼ばれる通信プロトコルに従い、世界規模のコンピュータのネットワークであるインターネットを介して、データの送受信が行われる。Ｗｅｂのクライアントは、Ｗｅｂのサーバから、Ｗｅｂにおいて通信可能な文書データやページ表示データ等を取得し、それらの内容を表示する。インターネットおよびＷｅｂの利用が広範に拡大するに伴い、ネットワーク内のサーバに課される処理量も増大してきている。従って、ネットワーク内において各種サービスを提供するサービスプロバイダは、サーバ群に対しデータ処理を要求する要求データ（以下、単に「要求」と呼ぶ）を制御するために、サーバ負荷分散と呼ばれる技術に注目している。サーバ負荷分散とは、サーバファームと呼ばれるサーバ群に含まれるサーバ間において、クライアントからの要求を分散する技術のことをいう。

サーバファームに含まれる複数のサーバに対し送信されたデータに関し、負荷分散を行う従来技術の例として、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｉｎｇ Ｓｙｓｔｅｍ）サーバによる負荷分散がある。ＤＮＳは、ラウンドロビン法に従いリスト内に示される複数のサーバを任意の順序で総当たり的に選択することにより、処理に用いるサーバを分散する。負荷分散を行う従来技術の他の例として、例えばＣｉｓｃｏ Ｓｙｓｔｅｍｓ（本社：米国カリフォルニア州サンノゼ）が生産するＣａｔａｌｙｓｔ ６０００シリーズ等のネットワークスイッチ（以下、単に「スイッチ」と呼ぶ）を用いるものがある。そのようなスイッチは、サーバファームとネットワークとの間に配置され、例えば、サーバファームに含まれる個々のサーバが、処理可能なクライアントとの接続許容数を超過することなく選択されるように、重み付けされたラウンドロビン法に従い処理に用いるサーバを選択する。また、そのようなスイッチのあるものは、サーバの負荷を示すマトリクス表に基づく最小接続選択法に従い、処理に適するサーバの決定を行うこともできる。例えば、単純な最小接続選択法によれば、現在のクライアントの接続数が最小であるサーバが選択される。また、重み付けされた最小接続選択法によれば、クライアントとの間の接続許容数に対する現在の接続数の比率が最小であるサーバが選択される。

調査によれば、ユーザインタフェースにおいて生成されるデータ処理の要求に対する応答時間によって、ユーザにより体感されるシステムのパフォーマンスが大きく左右されることが分かっている。すなわち、ユーザは、ユーザが行った要求に対してシステムが応答するまでの待ち時間が長いと、そのシステムのパフォーマンスを悪く評価する。これに対し、上述した従来技術によるサーバ間の負荷分散技術は、応答時間を直接考慮することなく、任意的な規則もしくはサーバの現在の負荷に応じて要求をサーバ間で分散させるため、ユーザにより体感されるシステムのパフォーマンスを効果的に最適化することができない。さらに、従来技術の多くは、それを実行するための専用のハードウェアを必要とする。

従って、ユーザにより体感されるシステムのパフォーマンスを効果的に最適化することを可能とする、より良いサーバ間の負荷分散システムおよび負荷分散方法が必要とされる。そこで、本発明は、サーバの応答時間を基準指標として用いることにより、サーバに対する要求の処理に伴う負荷の分散を行うシステムおよび方法を提案する。さらに、本発明は、汎用的なデータ処理装置により実現可能で、高い柔軟性と低コストを兼ね備える負荷分散システムを提案する。

上記課題を実現するために、本発明は、１以上のクライアントを含むクライアント群から、複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを受信し一時保留するステップと、過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を特定するステップと、前記待ち時間に基づき、前記サーバ群の中から、一時保留している要求データに応じたデータ処理を行うサーバを選択するステップとを備えることを特徴とするサーバ間の負荷分散方法を提供する。

また、本発明は、複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを生成可能なクライアントを、１以上含むクライアント群と、過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を記憶する記憶装置と、前記サーバ群に含まれるいずれかのサーバにおいて、前記クライアント群から要求データを受信して一時保留し、前記待ち時間に基づいて、前記サーバ群の中から、一時保留している要求データに応じたデータ処理を行うサーバを選択する負荷分散エージェントとを備えることを特徴とするサーバ間の負荷分散システムを提供する。

また、本発明は、クライアントを１以上含むクライアント群から、複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを受信する受信部と、過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を記憶する記憶部と、前記受信部が要求データを受信した場合、前記待ち時間に基づいて、前記サーバ群の中から、当該要求データに応じたデータ処理を行うサーバを選択する選択部とを備えることを特徴とする負荷分散サーバを提供する。

さらに、本発明は、プロセッサに、クライアントを１以上含むクライアント群から、複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを受信する受信処理と、過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を記憶する記憶処理と、前記受信処理において要求データが受信された場合、前記待ち時間に基づいて、前記サーバ群の中から、当該要求データに応じたデータ処理を行うサーバを選択する選択処理とを実行させるプログラムを提供する。

本発明に係る方法、システム、サーバおよびプログラムによれば、ユーザにより体感されるシステムのパフォーマンスが向上するように、サーバ間の負荷分散が効果的に最適化される。また、本発明に係る方法、システム、サーバおよびプログラムによれば、汎用的なデータ処理装置によりサーバ間の負荷分散が行われるため、高い柔軟性を備えたシステムが、低コストで実現される。

以下、本発明の好ましい実施形態を説明する。以下の説明においては、ＨＴＴＰを用いて通信を行うクライアントサーバシステムに本発明を適用した例を実施形態として示すが、ＨＴＴＰは本発明の実施に利用可能な通信プロトコルの一例であり、例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）等の他の通信プロトコルにより通信を行うクライアントサーバシステムに対しても本発明が適用可能であることは言うまでもない。

ユーザがクライアントを介して、対話形式で、ネットワークに接続されたサーバに対しデータ処理やデータ提供を要求する場合、ユーザの要求を満たす応答がユーザに提供されるまでの応答時間は、ユーザがそのネットワークシステムのパフォーマンスをどのように体感するかを大きく左右する。本実施形態によれば、ユーザインタフェースにおいて生成される要求に対する応答時間が計測され、計測された応答時間がサーバに対する要求の処理に伴う負荷の分散に用いられる。すなわち、その応答時間に応じて、クライアントのサーバに対する要求が、その要求に応答可能な複数のサーバ間に分散される。詳細は後述するが、本発明に係るサーバ間の負荷分散方法、負荷分散システム、サーバおよびプログラムによれば、クライアントの要求に対し応答可能なサーバ群の中から最適と思われるサーバが選択されることにより、ユーザにより体感されるネットワークシステムのパフォーマンスが向上される。

［１．アプリケーションモデル］
図１は、本実施形態に係るサーバ間の負荷分散技術により、サーバクライアントシステムのパフォーマンスがどのように最適化されるかを説明するために、サーバクライアントシステムに含まれるユーザインタフェースにおいて、要求の発生から消滅までを時系列的に示した図である。クライアントを操作するユーザは、サーバ側のアプリケーションにより提供されるサービスを利用する場合、思考時間ＴＴと待ち時間Ｗを交互に体験する。それぞれの思考時間ＴＴの終期において、ユーザはクライアントを介してサーバに対し要求を送出し、その後、その応答を待つ。サーバは、アプリケーションに従い、通常、ループ処理により常にユーザからの要求を監視している。そして、ユーザからの要求を受け取ると、サーバはデータの処理、データの取得等を行い、そのユーザからの要求を満たす応答の内容を生成する。その後、サーバは、ユーザに対し生成した応答を送り返す。

例えば、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式のデータを扱うアプリケーション間でデータの受け渡しが行われる場合、ユーザはクライアントにおいて実行されるＷｅｂブラウザに対し、Ｗｅｂページ形式のフォームに必要事項を入力して送信したり、サーバからＷｅｂページを取得するためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）へのリンクをクリックしたりすることにより、サーバに対し希望するデータの送信を要求することができる。すなわち、ユーザが、例えば何らかの応答を期待してフォームに必要事項を記入して送信したり、Ｗｅｂページを表示させるためにリンクをクリックしたりすると、クライアントからサーバに対し要求が送信される。

ある要求に対応する待ち時間Ｗは、クライアントが要求処理を行う時間を含んでいる。例えば、ユーザがクライアントを介して遠隔地に配置されたサーバ側のアプリケーションに対し要求を送る場合、その要求に対応する待ち時間Ｗは、（ａ）クライアントとサーバの間のデータ通信に費やされる時間と、（ｂ）サーバがユーザからの要求に応じた処理を行うために費やされる時間、すなわち要求先のサーバ側のアプリケーションによってデータの処理、データの入出力等を行うための時間とに分解される。

すなわち、以下の数式が成立する。

ただし、上記の式（１）において、Ｗは待ち時間、Ｃは総データ通信時間、すなわち図１においてＣ₁およびＣ₂で表される双方向のデータ通信に要する時間の合計、そしてＳはサーバにおけるサービス時間、すなわちサーバによるデータ処理時間およびデータ入出力時間の合計である。

今、ＣおよびＳが常時任意に変化すると仮定すると、式（１）の各変数の平均値の間に以下の数式が成立する。

ただし、上記の式（２）において、ａ（Ｗ）は待ち時間Ｗの平均値、ａ（Ｃ）は総データ通信時間Ｃの平均値、ａ（Ｓ）はサービス時間Ｓの平均値である。

さらに、ＣおよびＳが統計的に互いに独立して変化すると仮定すると、各変数の間に以下の数式で示される関係が成立する。

ただし、ｖ（Ｗ）は待ち時間Ｗの分散、ｖ（Ｃ）は総データ通信時間Ｃの分散、ｖ（Ｓ）はサービス時間Ｓの分散である。

通常、ユーザが体感するシステムのパフォーマンスは、待ち時間の平均値および分散、すなわちａ（Ｗ）およびｖ（Ｗ）によって左右される。従って、クライアントに対し同様のサービスを提供可能な一群のサーバ間においてうまく負荷分散を行うことにより、ａ（Ｗ）およびｖ（Ｗ）を最小化することができれば、ユーザにシステムのパフォーマンスの向上を体感させることができる。

［２．クライアントサーバシステムモデル］
図２は、本実施形態に係るサーバ間の負荷分散を行うクライアントサーバシステム１０をモデル的に示した図である。クライアントサーバシステム１０は２種類のデータ処理装置、すなわちクライアント１２とサーバ１４をそれぞれ複数、備えている。クライアント１２とサーバ１４は、ネットワーク１６により相互に接続されている。ネットワーク１６は、例えば１つのネットワークしか含まないＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）や、異種の複数ネットワークを相互接続したＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等のいずれであってもよい。クライアント１２は様々な種類の移動体データ処理装置のいずれであってもよく、例えばネットワーク１６を介してインターネットに接続可能な携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、小型コンピュータ等が考えられる。ユーザは、クライアント１２を用いて、サーバ側のアプリケーションにより提供されるサービスを要求する。その要求に対し、一群のサーバ１４の少なくともいずれか１つが、アプリケーションに従ってサービスの提供を行う。例えば、ユーザは、クライアントにおいて実行されるＷｅｂブラウザを用いて、データの要求を行い、データベースエンジンから送信されるデータの表示等を行うことができる。なお、データベースエンジンとは、サーバにおいてデータの格納および検索の管理を行うプログラムをいう。

クライアント１２は、１以上のクライアント群２０にグループ化されている。本実施形態において、１つのクライアント群２０は、同じアクセスポイント１８を介してネットワーク１６に接続するクライアント１２のグループである。クライアント１２は、例えば、クライアント群２０内で割り当てられる静的なＩＤ、もしくはクライアント１２のＩＰアドレスに基づき動的に割り当てられるＩＤにより、クライアント群２０の一員であると認識される。なお、クライアント１２をクライアント群２０にグループ化する方法としては、上述したものの他に様々な方法が考えられることは言うまでもない。例えば、それぞれのクライアント群２０にクライアントが１つしか含まれないようにしてもよいし、特定のサービスプロバイダのサービスを利用するクライアント、ＷＡＮにおいて同じ基地局を利用するクライアント等を同じグループとするようにしてもよい。

ユーザからの要求を含め、クライアント１２から送出される全てのデータは、ネットワーク１６を介してサーバ１４に送信される前に、必ずアクセスポイント１８を通過する。クライアント１２はアクセスポイント１８に接続するために、異なるアクセス経路２６に対応した複数のネットワークインタフェースを備えていてもよい。アクセスポイント１８は通信ハブとして機能する。従って、例えば、ＩＥＥＥ８０２．１１ｂと呼ばれる通信規格に準拠した無線通信クライアントは、アクセスポイント１８を介して有線ＬＡＮに接続することができる。さらに、アクセスポイント１８は、クライアント群２０の中において、クライアント１２から送出される要求を受信し、それに修正を加えた後、他の装置に対し送出することができる。その際、アクセスポイント１８は、クライアント１２から受信した要求に対し、クライアント群２０のＩＤ、ユーザのＩＤ、アクセス経路のＩＤ等の識別子をタグとして付加するが、それらの処理の詳細については後述する。なお、クライアントサーバシステム１０は複数のアクセスポイント１８を含んでおり、それぞれのアクセスポイント１８は複数のクライアント１２により利用される。

図２に示されるように、ネットワーク１６に接続されている複数のサーバ１４は、サーバファーム２２と呼ばれるグループを形成している。クライアント１２はサーバファーム２２に対し要求を行うことができ、その要求はサーバファーム２２に含まれるいずれかのサーバ１４により処理される。サーバファーム２２に含まれるサーバ１４の初期構成は、通常、サービスプロバイダのシステム管理者により決定される。すなわち、システム管理者は、クライアント１２により要求されるサービスを提供するための一群のサーバ１４を、サーバファーム２２の構成員として決定する。

本実施形態において、サーバファーム２２に含まれるサーバ１４のそれぞれは、クライアント１２から送出される様々な種類の要求のいずれに対しても同様に応答を行うことが可能である。すなわち、サーバファーム２２内のサーバ１４は、それぞれ、同じアプリケーションやデータを格納することができる。しかしながら、サーバファーム２２に含まれるサーバ１４のそれぞれは、常に全く同じ内容のデータ等を保持する必要はなく、例えば、クライアント１２からの要求に対し応答を行う際に、必要に応じてサーバファーム２２に含まれる他のサーバ１４から、必要なデータやアプリケーションの複製を取得するようにしてもよい。

クライアントサーバシステム１０は、負荷分散エージェント２４を、少なくとも１つ、備えている。負荷分散エージェント２４は、サーバファーム２２に要求が到達した際に、その要求を適当なサーバ１４に動的に割り当てる装置もしくはアプリケーションである。複数の負荷分散エージェント２４が同時に機能することはなく、例えば、サーバファーム２２に含まれるサーバ１４のうちの１つが負荷分散エージェント２４の機能を実行する。以下、負荷分散エージェント２４の機能を実行するサーバ１４を、負荷分散サーバ１４ｓと呼ぶ。なお、複数のサーバ１４が、負荷分散エージェント２４の実行に要するアプリケーションおよびデータの複製を保持するように構成されていてもよい。システム管理者は、どのサーバ１４に負荷分散サーバ１４ｓの役割を担わせるかを決定することができる。サーバファーム２２に含まれるいずれのサーバ１４も、負荷分散サーバ１４ｓの役割を果たすことができる。いずれかのサーバ１４に負荷分散エージェントの機能を実行させる代わりに、サーバファーム２２とネットワーク１６との接続経路上に、スイッチ等の専用装置を配置し、その専用装置に負荷分散エージェント２４の機能を実行させるようにしてもよい。サーバファーム２２内において複数のサーバ１４間の負荷を分散するために、負荷分散エージェント２４はクライアント１２からサーバファーム２２に対し送られてくる要求のそれぞれを受信し、受信した要求を一時留保して、その要求に対し応答を行うサーバ１４を１つ選択する。負荷分散エージェント２４は、クライアント１２からの要求を受信し一時保留するために、例えばＨＴＴＰを利用するアプリケーションに従い、それぞれのサーバ１４から負荷分散エージェント２４に対し、各サービスに応じたＵＲＬの送出を行わせる。その結果、サーバ１４のそれぞれからはＵＲＬおよびＩＰアドレスを示す数値の組が送出され、その数値の組は、ＤＮＳサーバによりバインド処理され格納される。ＤＮＳサーバにおいて、サーバファーム２２に含まれる各サーバ１４のサービスに対応したＵＲＬは、全て、負荷分散エージェント２４を実行する負荷分散サーバ１４ｓのＩＰアドレスにバインドされる。そして、ＤＮＳサーバに対し、どのＵＲＬに対応するＩＰアドレスの検索要求がなされても、ＤＮＳサーバは、そのＵＲＬに対応するＩＰアドレスとして、常に負荷分散エージェント２４のＩＰアドレスを返す。その結果、負荷分散エージェント２４は、サーバファーム２２に対する全ての要求を受信し、それらを一時保留することができる。

負荷分散エージェント２４は、クライアント１２からの要求を受信して一時保留すると、その要求に応じた処理を行うサーバ１４を選択するためのサーバ間の負荷分散処理を行う。その処理のため、負荷分散エージェント２４はサーバファーム２２に含まれるサーバ１４のリストを持っており、サーバ１４のあるものが一時的に使用不可、通信不能等に陥るとそのリストを更新することにより、どのサーバ１４がクライアント１２からの要求に応答可能であるかを監視している。さらに、負荷分散エージェント２４は、サーバファーム２２において各種の要求に対する処理を行うアプリケーションのそれぞれに関し、処理に要した待ち時間を、例えば待ち時間の平均および分散といった基準指標の形態で、常に記録している。負荷分散エージェント２４は、そのように記録している基準指標に基づき、サーバファーム２２に含まれるサーバ１４の１つを、クライアント１２からの要求のそれぞれに対し割り当てる。そのような負荷分散処理の詳細は後述する。

［２．１．待ち時間の計測］
サーバファーム２２に含まれるサーバ１４の間で負荷分散を行うために、負荷分散エージェント２４は、クライアント１２からの要求の対象であるアプリケーションのそれぞれに関し、処理に要した待ち時間、総データ通信時間およびサービス時間の平均および分散を取得する必要がある。負荷分散エージェント２４がこれらの基準指標を収集し、また他の装置に送信する方法としては、様々のものが考えられる。例えば、クライアント１２のそれぞれに、自機より送出される全ての要求に関する情報を記録するライブラリプログラム（以下、単に「ライブラリ」と呼ぶ）を備えさせ、そのライブラリにより記録された情報を用いて、クライアント１２がサーバ１４に対する要求のそれぞれに関し、待ち時間Ｗを計測するようにしてもよい。例えば、Ｊａｖａ（登録商標）プログラムに従い動作するクライアント１２は、Ｊ２ＭＥ（Ｊａｖａ ２ Ｐｌａｔｆｏｒｍ， Ｍｉｃｒｏ Ｅｄｉｔｉｏｎ）に含まれるライブラリに従った処理により、クライアント１２がＨＴＴＰに従って送出する全ての要求を記録することができる。より具体的には、例えば、以下のメソッドをＪ２ＭＥのｊａｖａ．ｎｅｔライブラリに追加することにより、ＨＴＭＬで記述されたフォームやＵＲＬに関する処理について、情報を収集することが可能となる。

このメソッドにより、要求とその要求に対する応答が、その要求に用いられるフォームとともに記録され、そのフォームに含まれる全ての要求の数が数えられる。

そして、それぞれの要求と応答の組み合わせに関し、それらの時刻情報の差により、待ち時間が計測される。例えば、クライアント１２は、クライアント１２からサーバ１４に送信されるＨＴＴＰに従った要求、例えばＰＯＳＴメソッドやＧＥＴメソッド等の情報を全て記録する。例えば、ＧＥＴメソッドもしくはＰＯＳＴメソッドが実行されると、クライアント１２は第１の時刻情報を取得する。サーバ１４により、ＧＥＴメソッドもしくはＰＯＳＴメソッドに対する応答が生成され、その応答がクライアント１２により受信され、Ｗｅｂブラウザにより表示されると、クライアント１２は第２の時刻情報を取得する。その後、クライアント１２は、第１および第２の時刻情報の差を待ち時間として算出する。

ユーザからの要求に対するサーバ１４における処理時間、すなわちサービス時間Ｓに関しては、サーバ１４がタイマを用いて計測を行う。すなわち、サーバ１４は、要求を受信した時刻、例えばサーバ１４のアプリケーションにおいてＳｅｒｖｉｃｅ（）メソッドがユーザからの要求に応じて呼び出された時刻と、その要求に対する応答が生成された時刻との差を算出し、サービス時間Ｓを計測する。サーバ１４は計測したサービス時間Ｓを、要求に対する応答とともに、クライアント１２に返送する。クライアント１２は、上記のようにして待ち時間Ｗとサービス時間Ｓを取得すると、上記の式（１）に従い、待ち時間Ｗとサービス時間Ｓとの差である総データ通信時間Ｃを算出する。

［２．２．待ち時間の計測結果の収集および配信］
クライアント１２は、要求先のアプリケーション毎に、実行時における待ち時間、総データ通信時間およびサービス時間の平均および分散を常時更新している。以下、本実施形態において計測される待ち時間、総データ通信時間およびサービス時間の平均をＡ（Ｗ）、Ａ（Ｃ）およびＡ（Ｓ）と表し、また待ち時間、総データ通信時間およびサービス時間の分散をＶ（Ｗ）、Ｖ（Ｃ）およびＶ（Ｓ）で表すものとする。具体的には、クライアント１２はライブラリに従い、所定の時間間隔Ｔの間に上述のようにして計測した待ち時間を用いて、その平均および分散、すなわちＡ（Ｗ）およびＶ（Ｗ）を算出し、その結果を記憶する。すなわち、Ａ（Ｗ）およびＶ（Ｗ）の算出に用いられる待ち時間は、過去の時間間隔Ｔの間に計測されたもののみである。同様に、クライアント１２は、所定の時間間隔Ｔの間に、上述のように取得したサービス時間Ｓおよび総データ通信時間Ｃを用いて、Ａ（Ｃ）およびＶ（Ｃ）並びにＡ（Ｓ）およびＶ（Ｓ）を、それぞれ算出する。以下、Ａ（Ｗ）、Ａ（Ｃ）、Ａ（Ｓ）、Ｖ（Ｗ）、Ｖ（Ｃ）およびＶ（Ｓ）を「待ち時間に関する基準指標」と総称する。

上述した例に代えて、例えば、第１のクライアント１２ａが、サーバファーム２２との通信において同じアクセスポイント１８を利用している第２のクライアント１２ｂから、Ａ（Ｃ）に関する情報を取得する構成としてもよい。その場合、例えば、第２のクライアント１２ｂはＷ、ＣおよびＳを算出し、それらをキャッシュメモリに記憶する。サーバファーム２２に含まれるサーバ１４のうちの１つは、どのクライアント１２が同じアクセスポイント１８を利用しているかに関する情報を有しており、そのサーバ１４を介して、第２のクライアント１２ｂのキャッシュメモリに記憶された内容と第１のクライアント１２ａのキャッシュメモリの内容との間では同期が取られる。システム管理者は、どのサーバ１４が、第２のクライアント１２ｂのキャッシュと第１のクライアント１２ａのキャッシュとの同期を管理するかを指定する。以下、キャッシュ間の同期を管理するサーバ１４がサーバ１４ａであるものとする。同じアクセスポイント１８を利用しているクライアント１２は全て、システム管理者により設定された時間間隔で定期的に、サーバ１４ａに対しキャッシュに記憶されているＡ（Ｃ）に関する情報を送信する。サーバ１４ａはクライアント１２ａの要求に応じて、これらの情報を集約し、その結果を、サーバ１４間における負荷の平滑化のための間隔情報とともにクライアント１２ａに送信する。平滑化のための間隔情報とは、同じサーバ１４が一定量の処理を連続して行うことを許可する時間間隔を表す所定の値である。

さらに、第２のクライアント１２ｂのキャッシュに記憶されたＡ（Ｃ）に関する情報は、この情報を必要としている第１のクライアント１２ａとクライアント１２ｂとの間で、直接同期が取られる構成としてもよい。この場合、クライアント１２のそれぞれは、自機のキャッシュに記憶されている情報を他のクライアント１２に対し、例えばＢｌｕｅｔｏｏｔｈ、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）、ＩＥＥＥ８０２．１１ｂ等で規格化されているローカルなネットワーク接続を介して、個々にブロードキャストする。その際、ブロードキャストされる情報は、ネットワーク１６を介してクライアント１２とサーバ１４との間で送受信される必要はなく、クライアント１２の間で個別に送受信されてもよい。なお、平滑化のための間隔情報としては、システム管理者が固定的な値を設定するようにしてもよいし、分散配置されたクライアント１２が相互に合意形成のための処理を行うことにより、１つの値が決定されるようにしてもよい。

さらに、Ａ（Ｗ）、Ａ（Ｃ）、Ｖ（Ｗ）およびＶ（Ｃ）は、クライアント１２がサーバ１４と通信を行う際に用いられるアクセス経路２６のそれぞれに応じて計測される構成としてもよい。ユーザがアプリケーションに対する要求の内容について思考している時間、すなわち思考時間ＴＴの間に、クライアント１２は、例えばＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）を用いた方法により、クライアント１２が利用可能な異なるアクセス経路２６のそれぞれに関し、Ａ（Ｃ）およびＶ（Ｃ）に関する情報を収集する。例えば、クライアント１２はアクセス経路２６を介して定期的にＩＣＭＰメッセージをサーバ１４に送信する。クライアント１２は、送信したＩＣＭＰメッセージに対しサーバ１４から返信されてくる応答メッセージに基づきデータ通信時間を算出し、そのデータ通信時間により、そのアクセス経路２６の遅延時間の平均値を算出する。Ａ（Ｗ）およびＶ（Ｗ）は、上述した式（２）および（３）に従い、それぞれＡ（Ｓ）およびＡ（Ｃ）、Ｖ（Ｓ）およびＶ（Ｃ）を加算することにより、利用可能なアクセス経路２６のそれぞれについて算出される。このようにして算出された待ち時間に関する基準指標は、クライアント１２において、アクセス経路２６のそれぞれに関しアクセス経路２６のＩＤとともに記憶され、サーバ間の負荷分散の決定に用いられる。その決定処理に関しては、後述する。

システム管理者は、クライアント１２が待ち時間に関する基準指標をアプリケーション単位で計測するか、それともアプリケーションとユーザの組み合わせ単位で計測するか、を選択することができる。これらの選択は、クライアント１２が動作を開始する前に設定され、動作中に変更されない構成としてもよいし、クライアント１２が動作を開始した後に動的に変更可能な構成としてもよい。クライアント１２が待ち時間に関する基準指標をアプリケーション単位で計測する場合、負荷分散エージェント２４はこれらの情報を、いずれのユーザが要求を行っているかを考慮することなく扱う。一方、クライアント１２がこれらの基準指標をアプリケーションとユーザの組み合わせ単位で計測する場合、負荷分散エージェント２４により実行されるサーバ間の負荷分散の処理は、異なるユーザの特性に応じて、微調整される。

ある要求に関する１組の待ち時間に関する基準指標について、その要求を行ったクライアント１２は、その要求の送信元ノードおよび送信先ノードをそれぞれ示す複数の処理ＩＤを記憶する。例えば、送信先ノードを示す処理ＩＤは、クライアント１２が、自機から送出された要求に対し応答を行ったサーバ１４を特定するＩＤである。送信先ノードを示す処理ＩＤは、サーバファーム２２においてサーバ１４を特定するＩＤであり、例えばサーバ１４のＩＰアドレス等が利用可能である。一方、送信元ノードを示す処理ＩＤは、例えば、要求を行ったクライアント１２を含むクライアント群２０を特定するＩＤである。また、クライアント１２が、アプリケーションとユーザの組み合わせ単位で待ち時間に関する基準指標の計測を行う構成である場合には、送信元ノードを示す処理ＩＤは個々のユーザを特定するＩＤである。さらに、送信元ノードを示す処理ＩＤは、クライアント１２がサーバファーム２２との間で通信を行う際に用いるアクセス経路２６を特定するＩＤであってもよい。

負荷分散エージェント２４がサーバ間の負荷分散処理において待ち時間に関する基準指標を利用可能とするために、クライアント１２はサーバ１４に対し、あるアプリケーションに関する要求を送る際、その要求とともに、計測した待ち時間に関する基準指標と、その要求に対応する処理ＩＤとを送信する。その結果、サーバ１４は複数のクライアント１２から、多数のクライアント１２に関し、同じアプリケーションについての待ち時間の平均や分散を算出することが可能となる。ところで、クライアント１２から受信した待ち時間に関する基準指標を個々のサーバ１４がどのように利用するかは、個別に決定することができる。システム管理者は、あるサーバ１４に関して、個々のクライアント１２についての待ち時間に関する基準指標を、同じアクセスポイント１８を利用しているクライアント１２、すなわち同じクライアント群２０に属するクライアント１２について集約するように構成することができる。また、システム管理者は、あるサーバ１４に関して、例えばＰＨＣＭプロトコルによりネットワーク層から得られる近接情報に基づき、クライアント１２との間の距離が所定の距離以下であるものについて、待ち時間に関する基準指標の集約を行うように構成することもできる。

負荷分散エージェント２４は、サーバファーム２２において実行可能なアプリケーションのそれぞれについて、サーバファーム２２に含まれるサーバ１４のそれぞれから待ち時間に関する基準指標を収集し、それらの基準指標をテーブル３０として負荷分散サーバ１４ｓのメモリに記憶させる。図３は、テーブル３０の構成を例示した図である。テーブル３０には複数のレコード３２を含んでおり、レコード３２のそれぞれは待ち時間に関する基準指標および対応する処理ＩＤを含んでいる。そのため、テーブル３０に格納されたデータにより、負荷分散エージェント２４は個々のレコード３２に含まれる待ち時間に関する基準指標が、サーバファーム２２に含まれるどのサーバ１４、どのクライアント群２０、どのユーザ、そしてどのアクセス経路２６に関するものであるかを特定することができる。

上記のように負荷分散エージェント２４がサーバ１４から待ち時間に関する基準指標を収集する構成とする代わりに、それぞれのクライアント１２が定期的に、待ち時間に関する基準指標を負荷分散エージェント２４に対し直接送信する構成としてもよい。その場合、負荷分散エージェント２４は、上述したようにシステム管理者により決定されたクライアント１２のグループ化の方針に従い、クライアント１２から送信される情報を集約する。

［３．サーバ間の負荷分散処理］
以下、図４を用いて、本実施形態におけるサーバ間の負荷分散処理５０の動作フローを説明する。

［３．１．要求の生成］
まず、クライアント群２０に含まれるクライアント１２は、サーバファーム２２に含まれるサーバ１４に対するＨＴＴＰに従ったデータ処理の要求（以下、「ＨＴＴＰ要求」と呼ぶ）を生成する（ステップ５２）。ＨＴＴＰに従ったデータ処理においては、通常、クライアント１２とサーバ１４との間で通信接続が確立され、クライアント１２からサーバ１４に対し要求メッセージが送信され、サーバ１４からクライアント１２に対し応答メッセージが返信され、その後、通信接続の切断が行われる。ＨＴＴＰ要求は、通常、要求行、ヘッダおよび本体から構成されている。要求行には、ＰＯＳＴメソッドやＧＥＴメソッド等のＨＴＴＰコマンド、クライアント１２がサーバ１４に対し処理の要求を行っている対象のリソース、そしてＨＴＴＰのバージョンをそれぞれ指定する情報が含まれている。ただし、処理対象のリソースは含まれない場合もある。ヘッダには通常、複数の行が含まれており、各行はクライアント１２、サーバ１４および送信されるデータの構成に関する情報を含んでいる。本体には、例えば、要求行にＰＯＳＴメソッドを指定する情報が含まれている場合の、サーバ１４に対し送信されるデータ本体が含まれている

［３．２．タグの付加］
ステップ５２において生成されたＨＴＴＰ要求は、アクセスポイント１８に送信される。アクセスポイント１８は、ＨＴＴＰ要求を受け取ると、そのヘッダに、そのＨＴＴＰ要求の送信元のクライアント群２０および送信先のサーバ１４を特定するフィールドを持つタグを付加する（ステップ５４）。なお、システム管理者は、アクセスポイント１８がＨＴＴＰ要求を受け取った際に、そのＨＴＴＰ要求を送信したユーザおよびそのＨＴＴＰ要求の送信に用いられたアクセス経路２６をそれぞれ特定するフィールドを持つタグを、さらにヘッダに付加するように構成することもできる。

［３．３．要求の一時保留］
続いて、サーバファーム２２において、いずれかのサーバ１４によりＨＴＴＰ要求が処理される前に、ＨＴＴＰ要求は負荷分散エージェント２４により一時保留される（ステップ５６）。上述したように、全てのＨＴＴＰ要求はＤＮＳサーバにより、負荷分散エージェント２４のＩＰアドレスにバインドされている。負荷分散エージェント２４はＨＴＴＰ要求に含まれる要求行の情報から、どのアプリケーションの処理が要求されているか、またＨＴＴＰ要求に含まれるヘッダの情報から、どのクライアント群２０からそのＨＴＴＰ要求が送出されているか、を特定する。また、負荷分散エージェント２４は、ＨＴＴＰ要求に含まれるヘッダの情報から、そのＨＴＴＰ要求の送出を行ったユーザや、クライアント１２がそのＨＴＴＰ要求を送出する際に利用したアクセス経路２６を特定するようにしてもよい。

［３．４．サーバの選択］
続いて、負荷分散エージェント２４は、一時保留しているＨＴＴＰ要求に対し応答するサーバ１４を、サーバファーム２２の中から選択する。負荷分散エージェント２４は、処理の要求先のアプリケーションに関する待ち時間、総データ通信時間およびサービス時間に基づき、様々な種類のサーバ間の負荷分散処理を実行することができる。図５は、負荷分散エージェント２４により実行されるサーバ１４の選択処理の例を模式的に示した動作フロー図である。図５は、特定のクライアント群２０からの要求に対するサービスの提供に関し、待ち時間の平均が最小であるサーバ１４を選択する方法を例示している。なお、図５の方法においては、待ち時間の平均が最小となるサーバ１４が複数存在する場合、さらに待ち時間の分散が最小となるサーバ１４が選択される。

より具体的に説明すると、クライアント１２がサーバファーム２２に含まれるサーバ１４に対し実行を要求できるアプリケーションのそれぞれに関し、システム管理者は待ち時間の平均についての閾値である最大平均値Ａ＿Ｔを設定することができる。さらに、アプリケーションのそれぞれに関し、システム管理者は待ち時間の分散についての閾値である最大分散値Ｖ＿Ｔを設定することができる。上述したように、負荷分散エージェント２４はサーバファーム２２に含まれる個々のサーバ１４に関し、計測された待ち時間に関する基準指標をテーブル３０として記憶しており、常にそれらを利用することができる。

負荷分散エージェント２４は、まず、ＨＴＴＰ要求の対象であるアプリケーションに関連付けて記憶されている複数のＡ（Ｗ）の中から、Ａ（Ｗ）の最小値を抽出する（ステップ７０）。このＡ（Ｗ）の最小値とは、サーバファーム２２に含まれるいずれかのサーバ１４が対象のアプリケーションを実行した場合のＡ（Ｗ）の最小値である。より具体的には、負荷分散エージェント２４は、記憶している待ち時間に関する基準指標のテーブル、すなわちテーブル３０の中から、ステップ５４において付加されたタグにより特定されるクライアント群２０に対応するＡ（Ｗ）のうち最小のものを抽出する。なお、ＨＴＴＰ要求に含まれるヘッダにユーザを特定するタグが付加されている場合、負荷分散エージェント２４はクライアント群２０に対応する複数のＡ（Ｗ）のうち、タグにより特定されるユーザにより送出されたＨＴＴＰ要求に対応するＡ（Ｗ）のみの中から最小のものを抽出する。同様に、ＨＴＴＰ要求に含まれるヘッダにアクセス経路２６を特定するタグが付加されている場合、負荷分散エージェント２４はタグにより特定されるアクセス経路２６に対応するＡ（Ｗ）のみの中から最小のものを抽出する。このような負荷分散エージェント２４によるタグに基づくＡ（Ｗ）の抽出処理により、負荷分散処理の方法がＨＴＴＰ要求を送出したクライアント群２０や利用されるアクセス経路２６に応じて調整され、サーバファーム２２において処理されるデータトラフィックが個々のユーザの希望を満たすようにサーバ１４間で配分される結果、ユーザにより体感されるシステムのパフォーマンスが最適化される。

サーバファーム２２に含まれる全てのサーバ１４に対応するＡ（Ｗ）の中から、上記の条件を満たすＡ（Ｗ）の最小値が１つだけ抽出された場合、負荷分散エージェント２４は抽出されたＡ（Ｗ）の最小値に対応するサーバ１４のＩＰアドレスを特定する（ステップ７２）。

続いて、負荷分散エージェント２４は、Ａ（Ｗ）の最小値が対象のアプリケーションに対し設定されている最大平均値Ａ＿Ｔより小さいか否かを判定する（ステップ７４）。ステップ７４において、Ａ（Ｗ）がＡ＿Ｔよりも小さいと判定された場合、負荷分散エージェント２４はＨＴＴＰ要求をステップ７２において特定したサーバ１４のＩＰアドレスに対し送信する（ステップ７６）。一方、ステップ７４において、Ａ（Ｗ）の最小値が最大平均値Ａ＿Ｔよりも大きいと判定された場合、負荷分散エージェント２４は対象のアプリケーションの実行用オブジェクトであるインスタンスの作成を行わない（ステップ７８）。そして、待ち時間に関する状況が改善し、Ａ（Ｗ）の最小値が最大平均値Ａ＿Ｔを下回った後に、インスタンスの作成が行われ、ＨＴＴＰ要求がサーバ１４のＩＰアドレス宛に送信される結果、アプリケーションによるＨＴＴＰ要求に応じた処理が行われる。

ところで、ステップ７０において、複数のサーバ１４に関し、同じＡ（Ｗ）の最小値が抽出された場合、負荷分散エージェント２４は待ち時間の分散、すなわちＶ（Ｗ）が最小であるものを抽出する（ステップ８０）。なお、ステップ８０においても、負荷分散エージェント２４はステップ７０において述べた条件を満たすＶ（Ｗ）、例えばステップ５６において付加されたタグにより特定されるクライアント群２０に対応するＶ（Ｗ）の中から、最小となるＶ（Ｗ）を抽出する。ステップ８０において、複数のサーバ１４に関し、同じＶ（Ｗ）の最小値が抽出された場合、負荷分散エージェント２４はそれら複数のサーバ１４の中から、任意に１つのサーバ１４を選択する。負荷分散エージェント２４は、Ｖ（Ｗ）の最小値に基づき１つのサーバ１４を選択すると、選択したサーバ１４に対しＨＴＴＰ要求を送信する（ステップ８２）。また、図６に示すように、図５に示した動作フローに修正を加え、負荷分散エージェント２４が、ステップ８０において抽出したＡ（Ｗ）の最小値が最大分散値Ｖ＿Ｔよりも大きいか否かを判定し、その判定結果が肯定的な場合にのみ、そのＡ（Ｗ）の最小値に対応するサーバ１４に対し、ＨＴＴＰ要求を送信する構成としてもよい。

なお、図５および図６において模式的に示したサーバ１４の選択処理は例示であり、本発明の技術的特徴を限定するものではないことは言うまでもない。すなわち、待ち時間に関する基準指標を用いる他の方法により、負荷分散エージェント２４がサーバ１４の選択を行う構成としてもよい。例えば、サーバ１４の抽出において、最初に待ち時間の分散Ｖ（Ｗ）に基づく抽出を行い、Ｖ（Ｗ）が最小となるサーバ１４に対してＨＴＴＰ要求の送信を行う構成としてもよい。

再度、図４を参照しつつ、説明を続ける。負荷分散エージェント２４は、ステップ５８においてＨＴＴＰに応答するサーバ１４を選択すると、選択したサーバ１４を特定する情報をキャッシュに記憶し、再度、同じクライアント１２から同じアプリケーションを対象とするＨＴＴＰ要求を受け取った場合に、その情報に基づき、自動的にそのＨＴＴＰ要求を前回選択したサーバ１４に送信する。選択されたサーバ１４を特定する情報は、所定の時間を経過すると無効化され、その後は上述した処理により、再度、ＨＴＴＰ要求に応答するサーバ１４の選択が行われる。

また、負荷分散エージェント２４は、サーバファーム２２に含まれる全てのサーバ１４のＩＰアドレスをリストとして記憶しておき、上述した選択処理によりＨＴＴＰ要求に応答するサーバ１４を選択すると、選択したサーバ１４のＩＰアドレスをＨＴＴＰ要求の送信元のクライアント１２に対し送信するようにしてもよい。そうすれば、ＨＴＴＰ要求を送信したクライアント１２は、その後に同様のＨＴＴＰ要求を送出する場合、前回に選択されたサーバ１４に宛てて直接、ＨＴＴＰ要求を送信することができる。その場合、負荷分散エージェント２４は通過モードでＨＴＴＰ要求を処理する。すなわち、負荷分散エージェント２４はクライアント１２により指定されるサーバ１４に対し、単にＨＴＴＰ要求を転送する以外の処理は行わない。その結果、負荷分散エージェント２４は、ＨＴＴＰ要求の宛先変更による負荷分散処理に伴う負荷を削減することができる。

また、クライアント１２は、サーバ１４との間でセッションの確立を必要とするような処理をサーバ１４に対し要求したい場合がある。この場合、セッションとは、複数のＨＴＴＰ要求が一連となったＨＴＴＰ要求群をいう。本実施形態においてセッションの確立のために用いられる通信プロトコルはいずれの通信プロトコルであってもよく、例えば、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などが利用可能である。セッションが確立されると、負荷分散エージェント２４はそのセッションにおいて最初に受信したＨＴＴＰ要求に対し応答するように選択したサーバ１４とクライアント１２との間でバインド処理を行い、そのセッションが確立されている間、そのサーバ１４とクライアント１２との間のバインドを維持する。その結果、クライアント１２はセッションが確立されている間、ＨＴＴＰ要求を負荷分散エージェント２４に宛てて送信し、負荷分散エージェント２４はそのＨＴＴＰ要求を全て、同じサーバ１４に対し転送することにより、通過モードと同様の処理を実現することができる。

しかしながら、負荷分散エージェント２４はセッションの確立中であっても、例えば、基準となる待ち時間の平均と計測される待ち時間との差が所定の最大値Ｄｅｌｔａ＿Ａ（Ｗ）を超える等の所定の条件が満たされる場合には、再度、図５に示したサーバ１４の選択処理を実行し、異なるサーバ１４にクライアント１２からのＨＴＴＰ要求に対する応答を行わせるように構成してもよい。

［３．５．サーバの過負荷状態等の検出］
負荷分散エージェント２４は、クライアント１２からのＨＴＴＰ要求に対し応答を行う適当なサーバ１４の選択に加えて、クライアントサーバシステム１０が過負荷状態に陥り、ユーザを満足させるようなパフォーマンスを実現できない状態の検出も行う（ステップ６０）。図７は、過負荷状態の検出処理を模式的に示した動作フロー図である。まず、負荷分散エージェント２４は、所定時間内に新たなインスタンスの生成が行われない回数が、システム管理者により予め設定された閾値Ｂ＿Ｔよりも大きいか否かを判定する（ステップ９０）。この場合、新たなインスタンスとは、例えばＧＥＴメソッドやＰＯＳＴメソッドを指定するＨＴＴＰ要求等により、サーバ１４に対し新たなコネクションの確立を要求する場合に生成される実行用のオブジェクトのことである。上述したように、インスタンスの生成は、例えば、待ち時間の平均Ａ（Ｗ）が所定の最大平均値Ａ＿Ｔよりも大きい場合には行われない。ＨＴＴＰ要求に応じたインスタンスの生成が行われない回数が閾値Ｂ＿Ｔよりも大きくなると、負荷分散エージェント２４は、その待ち時間の増大がサーバファーム２２とネットワーク１６のいずれの原因によりもたらされているかを判定する（ステップ９２）。具体的には、負荷分散エージェント２４は、総データ通信時間の平均Ａ（Ｃ）がサービス時間の平均Ａ（Ｓ）と比較して際だって大きい場合、ネットワーク１６に輻輳が生じていると判定し、その旨をシステム管理者に対し通知するための処理を行う（ステップ９６）。一方、サービス時間の平均Ａ（Ｓ）が総データ通信時間の平均Ａ（Ｃ）と比較して際だって大きい場合、負荷分散エージェント２４は、サーバファーム２２に輻輳が生じていると判定し、その旨をシステム管理者に対し通知するための処理を行う（ステップ９４）。

さらに、ステップ９０において、インスタンスの生成が行われない回数が閾値Ｂ＿Ｔよりも大きくない場合であっても、負荷分散エージェント２４が、ネットワーク１６およびサーバファーム２２における輻輳の有無の判定を行う。具体的には、負荷分散エージェント２４は、サービス時間の分散Ｖ（Ｓ）が、予めシステム管理者によって設定された閾値ＶＳ＿Ｔを超えているか否かの判定を行う（ステップ９８）。サービス時間の分散Ｖ（Ｓ）が閾値ＶＳ＿Ｔを超えている場合、負荷分散エージェント２４はシステム管理者に対し、サーバファーム２２に輻輳が生じていることを通知するための処理を行う（ステップ１００）。続いて、負荷分散エージェント２４は、総データ通信時間の分散Ｖ（Ｃ）が、予めシステム管理者によって設定された閾値ＶＣ＿Ｔを超えているか否かの判定を行う（ステップ１０２）。総データ通信時間の分散Ｖ（Ｃ）が閾値ＶＳ＿Ｃを超えている場合、負荷分散エージェント２４はシステム管理者に対し、ネットワーク１６に輻輳が生じていることを通知するための処理を行う（ステップ１０４）。

上述した過負荷状態および輻輳の検出処理はリアルタイムで行われ、過負荷状態もしくは輻輳が検出された場合には、リアルタイムに電子メール等にてシステム管理者に通知される。その結果、要求に伴う待ち時間が長く、ユーザがクライアントサーバシステム１０に関し好ましくない印象を持つような場合に、システム管理者はクライアントサーバシステム１０に対し、適する処置を施すことができる。

［３．６．サーバの処理状態の検出］
さらに、負荷分散エージェント２４は、クライアント１２からのＨＴＴＰ要求に応答するサーバとして以前に選択したサーバ１４が、ＨＴＴＰ要求に応じられない状態に陥ったり、またそのような処理不能な状態から回復したりした場合、それらの状態変化を検出する（ステップ６２）。そのため、負荷分散エージェント２４はサーバファーム２２に含まれるサーバ１４のうち、いずれのサーバ１４が現在利用可能であるかを示すリストを記憶し、常に更新している。例えば、システム管理者は、サーバファーム２２に含まれる全てのサーバ１４のＩＰアドレスおよびＭＡＣアドレスを含むリストを負荷分散エージェント２４に入力する。そして、負荷分散エージェント２４は、定期的にそれぞれのサーバ１４に対し、ＰＩＮＧ（Ｐａｃｋｅｔ Ｉｎｔｅｒｎｅｔ Ｇｒｏｐｅｒ）による処理を実行することにより、データがサーバ１４に到達するか否かをチェックする。ＰＩＮＧの処理の実行間隔は、例えばシステム管理者により設定される。新たなサーバ１４がサーバファーム２２に追加された場合、そのサーバ１４は、次のＰＩＮＧが行われるまで、サーバファーム２２において利用可能とはならない。あるサーバ１４がＨＴＴＰ要求に対する応答を開始した後、そのサーバ１４がサーバファーム２２から離脱した等の理由で、そのサーバ１４からの応答が途絶えた場合、負荷分散エージェント２４はそのサーバ１４との通信が途絶えたことを、ＰＩＮＧの処理に対する応答時間がタイムオーバーとなることにより検出する。

負荷分散エージェント２４は、クライアント１２からのＨＴＴＰ要求をいずれかのサーバ１４に割り当てている状態で、そのサーバ１４との間で上述したようなタイムオーバーが発生したことを検出すると、そのＨＴＴＰ要求の処理をサーバファーム２２に含まれる新たなサーバ１４に割り当てなおす。その際、新たなサーバ１４は、ステップ５８において説明した選択処理により選択されるが、その選択処理において、応答時間がタイムオーバーとなったサーバ１４に対応する待ち時間の平均Ａ（Ｗ）は選択肢から除外される。

［３．７．負荷分散エージェントの処理状態の検出］
現在、負荷分散エージェント２４として機能しているサーバ１４が処理不能な状態に陥った場合、そのサーバ１４に代わって他のサーバ１４が負荷分散エージェント２４として機能する（ステップ６４）。そのような負荷分散エージェント２４の交代においては、サーバファーム２２に含まれるサーバ１４のうち、処理可能な状態であり、かつ、負荷分散エージェント２４に関するデータの完全な複製を保持しているサーバ１４の１つが新たな負荷分散エージェント２４として選択される。

具体的には、ステップ６４の処理において、ＩＳＩＳ（Ｉｎｔｅｒｍｅｄｉａｔｅ−Ｓｙｓｔｅｍ ｔｏ Ｉｎｔｅｒｍｅｄｉａｔｅ−Ｓｙｓｔｅｍ）等のグループ管理プロトコルが利用可能である。グループ管理プロトコルとは、ネットワーク内リソースのグループ管理を行う通信プロトコルであり、多数のサーバをグループ化しサーバファームを維持管理する際に利用可能である。あるサーバ１４をサーバファーム２２の構成員としてグループに含めるか否かを決定するにあたっては、例えば、コンセンサス法が用いられる。また、ある構成員のグループからの離脱を検出するにあたっては、例えば、時刻情報により応答時間のタイムオーバーを判定するハートビート法が用いられる。そして、構成員であるサーバ１４が処理不能な状態に陥り、サーバファーム２２から離脱したような場合、サーバファーム２２の構成員の再構成が行われる。また、サーバファーム２２と外部の装置等との間のデータ通信を調整する役割を果たすリーダとしてのサーバ１４を選択するために、例えば、リーダ選択法が用いられる。なお、サーバファーム２２においてリーダとなるサーバ１４を選択する際に、例えば最小のＩＰアドレスが割り当てられているサーバ１４を選択する、といった方法が採用されてもよい。

本実施形態において、サーバファーム２２においてリーダとして選択されたサーバ１４は、負荷分散エージェント２４としての役割を果たす。そして、そのサーバ１４が処理不能となり、負荷分散エージェント２４からの応答が途絶えた場合、サーバファーム２２により新たなリーダが選択される。新たなリーダは、負荷分散エージェント２４に関するデータの複製を作成し、保持している必要がある。新たにリーダとして選択され、負荷分散エージェント２４として機能することとなったサーバ１４のＩＰアドレスは、ＤＮＳサーバに送信され、ＤＮＳサーバのバインド処理により、新たな負荷分散エージェント２４はクライアント１２から送信されるＨＴＴＰ要求を一時保留することが可能となる。

［３．８．サーバへの要求送信］
負荷分散エージェント２４は、ステップ５８において選択したサーバ１４に対し、クライアント１２からのＨＴＴＰ要求を送信することにより、それを割り当てる（ステップ６６）。その際、負荷分散エージェント２４は、一定時間ＴＴの間に同じサーバ１４に対し送信するＨＴＴＰ要求の最大値を所定数Ｎに限ることにより、同じサーバ１４に対し過大数のＨＴＴＰ要求が集中的に送信されることを回避する。その場合、一定時間ＴＴおよび所定数Ｎは、クライアントサーバシステム１０に含まれる装置のハードウェア構成等に応じて、システム管理者が決定することができる。

以上が本実施形態の説明であるが、本実施形態において示した具体例は本発明の内容を明らかにするための例示であり、本発明の技術的特徴を限定するものではない。また、本実施形態に対しては、本発明の技術的思想の範囲内において、様々な変形および変更を加えることが可能であることは言うまでもない。

サーバクライアントシステムに含まれるユーザインタフェースにおいて生成される要求の発生から消滅までを時系列的に示した図である。 本実施形態に係るサーバ間の負荷分散を行うクライアントサーバシステムをモデル的に示した図である。 本実施形態に係るクライアントサーバシステムにおいてサーバ間の負荷分散を行うために用いられる待ち時間に関する基準指標を格納するテーブルの構成を示した図である 本実施形態におけるサーバ間の負荷分散処理を示す動作フロー図である。 本実施形態におけるサーバの選択処理を示す動作フロー図である。 本実施形態におけるサーバの選択処理を示す動作フロー図である。 本実施形態における過負荷状態等の検出処理を示す動作フロー図である。

符号の説明

１０…クライアントサーバシステム、１２…クライアント、１４…サーバ、１６…ネットワーク、１８…アクセスポイント、２０…クライアント群、２２…サーバファーム、２４…負荷分散エージェント、２６…アクセス経路、３０…テーブル、３２…レコード、５０…負荷分散処理。

Claims (4)

1. １以上のクライアントを含むクライアント群から、複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを受信し一時保留するステップと、
   過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を特定するステップと、
   前記待ち時間に基づき、前記サーバ群の中から、一時保留している要求データに応じたデータ処理を行うサーバを選択するステップと
   を備えることを特徴とするサーバ間の負荷分散方法。
2. 複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを生成可能なクライアントを、１以上含むクライアント群と、
   過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を記憶する記憶装置と、
   前記サーバ群に含まれるいずれかのサーバにおいて、前記クライアント群から要求データを受信して一時保留し、前記待ち時間に基づいて、前記サーバ群の中から、一時保留している要求データに応じたデータ処理を行うサーバを選択する負荷分散エージェントと
   を備えることを特徴とするサーバ間の負荷分散システム。
3. クライアントを１以上含むクライアント群から、複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを受信する受信部と、
   過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を記憶する記憶部と、
   前記受信部が要求データを受信した場合、前記待ち時間に基づいて、前記サーバ群の中から、当該要求データに応じたデータ処理を行うサーバを選択する選択部と
   を備えることを特徴とする負荷分散サーバ。
4. プロセッサに、
   クライアントを１以上含むクライアント群から、複数のサーバを含むサーバ群に対しデータ処理を要求する要求データを受信する受信処理と、
   過去において、前記サーバ群に含まれるサーバが、前記クライアント群から送信された要求データに応じて行ったデータ処理における待ち時間を記憶する記憶処理と、
   前記受信処理において要求データが受信された場合、前記待ち時間に基づいて、前記サーバ群の中から、当該要求データに応じたデータ処理を行うサーバを選択する選択処理と
   を実行させるプログラム。

Images