JP2011138202A - サーバ装置、サーバ負荷分散装置、サーバ負荷分散方法、及びプログラム - Google Patents

Abstract

【課題】フロントサーバ層の先に更にエンドサーバ層が接続され各層のサーバが相互に連携して処理を実行するシステムで、アプリケーション単位でのフロントサーバ及びエンドサーバの最適な負荷分散制御を実現する。
【解決手段】フロントサーバ１０２で稼働する負荷計測エージェント１０９において、エンドサーバ取得統計情報解析処理（Ｓ２０１）では、自装置がアクセスするエンドサーバ１０３上のアプリケーションを決定するためのアプリケーションパス情報が取得される。エンドサーバ統計情報取得処理（Ｓ２０２）では、アプリケーションパス情報に基づいて決定されるエンドサーバ１０３の負荷状態がアプリケーションパス管理情報として取得される。統計情報通知処理部（Ｓ２０３）では、アプリケーションパス管理情報が、サーバ負荷分散装置１０１に通知される。サーバ負荷分散装置１０１では、アプリケーションパス管理情報とクライアントからフロントサーバへのコネクション数とに基づいて、複数のサーバ装置に対するリクエストの振分け制御が実施される、
【選択図】図２

Description

サーバ装置への負荷分散（ロードバランシング）を行うサーバ負荷分散装置及びそのサーバ装置に関する。

インターネットの普及によりインターネット利用者数は増加している。それに従いインターネット上のワールドワイドウェブ（以下、「Ｗｅｂ」と記述する）サイトへのリクエストも増加している。

リクエストが増加すると、Ｗｅｂサイトの応答が遅くなったり、Ｗｅｂサイトに接続しにくくなったり等、サービスの低下が懸念される。
これらの問題を回避するために、次のような機能を実現するサーバ負荷分散装置が知られている。
・Ｗｅｂサイトの能力が不足してきたときにＷｅｂサイトの能力を容易に拡張できる
機能（スケーラビリティ：拡張性）
・故障が発生してもＷｅｂサービスが停止しない機能（アベイラビリティ：可用性）
・Ｗｅｂサービスを止めずにＷｅｂサービスを提供するサーバコンピュータの保守や修理ができる機能（アベイラビリティ：可用性）

ここで、スケーラビリティは、システムの拡張性を表す。スケーラビリティの高いシステムであれば、能力が不足することが判ったときに、必要に応じてシステムを拡張できる。このため、必要な能力を予め予測するのが難しいＷｅｂサイトではスケーラビリティが重要となる。

スケーラビリティ機能を実現するサーバ負荷分散装置では、複数のサーバを代表するＩＰ（インターネットプロトコル）アドレスが決められる。このような代表ＩＰアドレスは仮想ＩＰアドレスと呼ばれ、利用者にはこの仮想ＩＰアドレスが通知される。そして、この仮想ＩＰアドレスがサーバ負荷分散装置に設定され、サーバ負荷分散装置がインターネットに接続される。これにより、インターネットに接続されたパーソナルコンピュータや携帯端末等の利用者からの仮想ＩＰアドレスを指定したリクエストは、サーバ負荷分散装置に送信される。サーバ負荷分散装置には、各種処理を行うサーバが接続されている。そして、受信した利用者からのリクエストが各サーバに均等に分散される。その結果、利用者からは、実際には複数あるサーバが、あたかも１台の高性能サーバのように見えることになる。実際のサーバの数が増減されても、利用者にはその変化は見えない。利用者は、いつもと同じ仮想的なサーバにリクエストを送ればよく、サーバ負荷分散装置が、その時の実際のサーバの構成に応じて、適切なサーバにリクエストを分散する。

このように、サーバ負荷分散装置を利用すると、サービスに影響を与えずにサイトの処理能力を増強することができる。
上述のスケーラビリティ機能において、各サーバを効率的に使用することによりサーバ負荷分散システム全体の能力を最大限に発揮させるためには、リクエストを振り分ける「分散方式」が重要である。分散方式は、サーバが提供するサービス(プロトコル)の特性に応じて、その方式を最適なものとする必要がある。例えば、以下に示されるような分散方式が組み合わせられて提供される。

＜ラウンドロビン＞
各サーバに、順番にリクエストが振り分けられる。
＜静的な重み付きラウンドロビン＞
各サーバに、予め設定された比率でリクエストが振り分けられる。
＜最小コネクション数＞
処理中のコネクションが少ないサーバにリクエストが振り分けられる。
＜最小クライアント数＞
接続中のクライアントが少ないサーバにリクエストが振り分けられる。
＜最小データ通信量＞
処理中のデータ通信量が少ないサーバにリクエストが振り分けられる。
＜最小応答時間＞
応答時間が短いサーバにリクエストが振り分けられる。
＜最小サーバ負荷＞
ＣＰＵ、メモリ、Ｉ／Ｏの利用率が低いサーバにリクエストが振り分けられる。

これらのサーバ負荷分散方式のうち「ラウンドロビン」及び「静的な重み付きラウンドロビン」の２方式は、「静的分散」に分類される。静的分散は、予め決められた順序でリクエストが各サーバに振り分けられる方式である。この方式では、分散対象サーバの全てが、同じ処理能力を持っていること、又はシステムの設計者が各サーバの処理能力を把握していることが必要となる。

一方、「最小コネクション数」「最小クライアント数」「最小データ通信量」「最小応答時間」「最小サーバ負荷」等の方式は、「動的分散」に分類される。動的分散は、振分け対象サーバの状態がリアルタイムに測定され、それを基にリクエストが各サーバに振り分けられる方式である。

ここで、中・大規模のポータルサイトシステムや社内イントラネットシステムを想定する。この場合、振分け対象サーバとして、それぞれ同一の処理を実行する同様の種類のＷｅｂサーバだけでなく、様々なサーバがサーバ負荷分散装置に接続される可能性がある。例えば、データベースアプリケーションサーバや各種情報処理アプリケーションサーバ等である。このようなシステムには、静的分散方式ではなく動的分散方式で負荷分散を行うサーバ負荷分散装置が適する。

このような動的分散方式では、サーバ負荷分散装置が振分け対象サーバ等の他の装置と連携することにより、効率的に負荷分散処理を実行することが重要である。
ここで、中・大規模のネットワークシステムにおいては、次のような構成が一般的によく採用される。即ち、Ｗｅｂサーバ等のフロントサーバ層の先に更に、データベースアプリケーションサーバ、情報処理アプリケーションサーバ、ストレージアプリケーションサーバ等のエンドサーバ層が接続され、各層のサーバが相互に連携して処理を実行する。なお、これらに関係する特許文献として以下のものがある。

特願平１１−２９２９０６号 特願２００４−５７０８６０号 特開２００６−２６８１５５号公報

上記特許文献１，２，３に記載のいずれのサーバ構成においても、サーバ負荷分散装置における直接の振分け対象サーバであるフロントサーバの負荷状態によりリクエストが分散されても、フロントサーバの後ろにあるエンドサーバでの負荷が均等になるとは限らない。

しかし、従来のサーバ負荷分散装置は、フロントサーバにおける負荷状態しか収集することができなかった。例えば、応答時間が短いエンドサーバ上のアプリケーションを多く処理しているフロントサーバに対しては、より多くのリクエストが送り込まれても、そのリクエストを十分に処理できる。一方、応答時間が長いエンドサーバ上のアプリケーションを処理しているフロントサーバに対しては、あまり多くのリクエストは送り込まないほうがよい。従来のように、単にフロントサーバが処理しているリクエストの要求数や平均応答時間等の負荷状態を計測しただけでは、処理の重いリクエストも軽いリクエストも一括して判断されてしまう。例えば、１つのエンドサーバにおいて、処理時間が長くかかるアプリケーションと処理時間が短いアプリケーションが同時に実行されているような場合を考える。そして、エンドサーバにおいては、処理時間が長いアプリケーションにＣＰＵ時間を割り当てすぎないように制御がされているとする。このような場合、たとえ処理時間の長いアプリケーションが実行されていても、エンドサーバは、処理時間の短いアプリケーションを実行するだけの余裕が十分にある場合がある。しかし、フロントサーバが、リクエストの発行状態をエンドサーバ単位でしか監視しない場合には、次のような問題が発生し得る。即ち、フロントサーバが、あるタイミングにおいて、処理時間が長いアプリケーションへのリクエストをエンドサーバに対して発行した場合、そのリクエストの応答時間は長くなる。このため、フロントサーバは、あるタイミングにおいてその応答時間のみを判断する結果、そのエンドサーバの負荷が高いと判断してしまう。しかし実際には、エンドサーバは、処理時間の短いリクエストを処理するだけの負荷の余裕が十分にある場合があるのである。この結果、フロントサーバが、リクエストの発行状態をエンドサーバ単位でしか監視しない場合には、サーバ負荷分散装置は、各フロントサーバへの、各エンドサーバの負荷状態も加味した正確なリクエストの振り分け制御を行うことができない。この結果、サーバ負荷分散装置は、各フロントサーバへの、各エンドサーバの負荷状態も加味した正確なリクエストの振り分け制御を行うことができないという問題点を有していた。

そこで、本発明の課題は、フロントサーバ層の先にエンドサーバ層が接続され各層のサーバが連携して処理を実行するシステムで、各エンドサーバへのアクセス状況が正確に反映された各フロントサーバに対する負荷分散制御をすることである。

本発明の態様の一例のサーバ装置は、エンドサーバと通信を行いながら、サーバ負荷分散装置によって振り分けられるクライアントからのリクエストを処理するフロントサーバとして機能するサーバ装置において、自装置がアクセスするエンドサーバ毎に各エンドサーバ上の負荷状態毎の識別情報を取得し、識別情報に基づいて負荷状態をエンドサーバ負荷状態の統計情報として計測する計測手段と、エンドサーバ負荷状態の統計情報を、サーバ負荷分散装置に通知する通知手段とを具備する。

本発明の態様の他の例のサーバ負荷分散装置は、エンドサーバと通信を行いながらクライアントからのリクエストを処理するフロントサーバに対して、前記クライアントからのリクエストを振り分けるサーバ負荷分散装置において、少なくとも一台の前記エンドサーバが接続されるべきフロントサーバを介して前記エンドサーバの負荷状態の統計情報を受信する受信手段と、前記統計情報と前記フロントサーバへの前記リクエストのコネクション数とから算出される負荷情報に基づいて前記各フロントサーバの振り分け比率を計算し、前記フロントサーバへの前記リクエストの振分けを制御するフロントサーバ負荷分散手段と、を具備する。

各フロントサーバであるサーバ装置において、自装置がアクセスするエンドサーバ上の負荷状態の統計情報を取得でき、これに基づいてサーバ負荷分散装置によって各フロントサーバを振分け制御することにより、エンドサーバの負荷状態に沿った正確なサーバ負荷分散を実現でき、システム全体の負荷の最適化を容易に実現することが可能となる。

実施形態のシステムの全体構成図である。 フロントサーバにおける負荷計測エージェントを含む実施形態のシステム構成図である。 サーバ負荷分散装置における統計情報受信制御部／振分け処理部／コネクション管理部のシステム構成図である。 フロントサーバにおけるエンドサーバ取得統計情報解析処理の詳細を示すフローチャートである。 フロントサーバにおけるエンドサーバ統計情報取得処理（エンドサーバ通信監視（生存監視））の詳細を示すフローチャートである。 フロントサーバにおけるエンドサーバ統計情報取得処理（要求数計算処理）の詳細を示すフローチャートである。 フロントサーバにおけるエンドサーバ統計情報取得処理（応答時間計測処理）の詳細を示すフローチャートである。 フロントサーバにおける統計情報通知処理の詳細を示すフローチャートである。 サーバ負荷分散装置における統計情報受信処理の詳細を示すフローチャートである。 サーバ負荷分散装置における振分け比率設定処理の詳細を示すフローチャートである。 サーバ負荷分散装置における振分け処理の詳細を示すフローチャートである。 サーバ負荷分散装置におけるコネクション確立・解放処理の詳細を示すフローチャートである。 ＰＳコマンドによる起動デーモンの調査処理の例を示す図である。 フロントサーバがＷｅｂサーバである場合のアプリケーションパス情報の取得処理の説明図である。 負荷計測エージェントの設定情報ファイルのデータ構成の一例を示す図である。 アプリケーションパス管理情報のデータ構成の一例を示す図である。 サーバ統計情報のデータ構成の一例を示す図である。 振分け情報のデータ構成の一例を示す図である。 コネクション情報のデータ構成の一例を示す図である。 通知データのデータ構成の一例を示す図である。 統計情報通知の制御シーケンスを示す図である。 実施形態の動作シーケンス例を示す（その１）である。 実施形態の動作シーケンス例を示す（その２）である。 実施形態の動作シーケンス例を示す（その３）である。 実施形態の動作シーケンス例を示す（その４）である。 実施形態のシステムを実現できるコンピュータのハードウェア構成の一例を示す図である。

以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。
図１は、負荷分散制御を実現する実施形態のシステムの全体構成図である。サーバ負荷分散装置１０１には、ＬＡＮ（ローカルエリアネットワーク）１１１を介して、＃Ａ及び＃Ｂの複数台のフロントサーバ１０２（フロントサーバＡ、フロントサーバＢ）が接続される。サーバ負荷分散装置１０１は、＃Ａ及び＃Ｂのフロントサーバ１０２に対して、負荷分散制御を実施する。各フロントサーバ１０２には、ＬＡＮ１１２を介して、＃Ａ及び＃Ｂの複数台のエンドサーバ１０３（エンドサーバＡ、エンドサーバＢ）と仮想サーバ１０４（仮想サーバＥ）が接続される。仮想サーバ１０４には、ＬＡＮ１１３を介して、更に＃Ｃ及び＃Ｄのエンドサーバ１０３（エンドサーバＣ、エンドサーバＤ）が接続される。仮想サーバ１０４は、＃Ｃ及び＃Ｄのエンドサーバ１０３に対して、負荷分散制御を実施する。なお、フロントサーバ１０２やエンドサーバ１０３の数は、２台に限られるものではない。サーバ負荷分散装置１０１には、インターネット１１４を介して、利用者のパーソナルコンピュータ等であるクライアント１０５が接続される。

フロントサーバ１０２は、例えば、クライアント１０５からのＷｅｂリクエストを受け付けるＷｅｂサーバとして動作する。また、エンドサーバ１０３は、データベースアプリケーションや各種情報処理アプリケーションを、アプリケーション１〜４（図１中ではアプリ１、アプリ２、アプリ３、アプリ４などと表示する）として実行する。エンドサーバ１０３は、＃Ａのエンドサーバ１０３のように、＃１及び＃２等の複数のアプリケーション１１０（アプリ１、アプリ２）を実行する場合がある。また、＃Ｂのエンドサーバ１０３のように、＃３のアプリケーション１１０（アプリ３）を実行する場合がある。フロントサーバ１０２の配下にあるエンドサーバ１０３は、個別に決められている。従って、フロントサーバＡがフロントサーバＢに切り替わったとするならそれに対応して、例えばエンドサーバＡはエンドサーバＢに切り替わる。エンドサーバＡとエンドサーバＢは、少なくとも１つの同一のアプリケーション、例えばアプリ１を実行する。

本実施形態では、＃Ｃ及び＃Ｄ等の複数台のエンドサーバ１０３をまとめるようなかたちでフロントサーバ１０２の後段層に、仮想サーバ１０４（仮想サーバＥ）を設置できる。この場合、仮想サーバ１０４は、＃Ｃ及び＃Ｄ等の複数台のエンドサーバ１０３において分散して実行される＃４の１種類のアプリケーション１１０（アプリ４）に対して、負荷分散制御を実施する。ここでの負荷分散制御方式としては、従来のサーバ負荷分散装置がそれに接続される単一階層の複数のサーバに対して実行する一般的な負荷分散制御を適用することができる。

各振分け対象サーバであるフロントサーバ１０２には、それぞれ負荷計測エージェント１０９が実装される。負荷計測エージェント１０９は、後述するアプリケーションパス管理情報に基づいて、各エンドサーバ１０３で実行される各アプリケーション１１０の負荷を判断するための統計情報を収集する。そして、その統計情報をサーバ負荷分散装置１０１に通知する。

サーバ負荷分散装置１０１には、統計情報受信制御部１０６、コネクション管理部１０７、及び振分け処理部１０８が実装され、それぞれが以下の処理を実行する。
即ち、統計情報受信制御部１０６は、各フロントサーバ１０２から統計情報を収集し、エンドサーバ１０３を含めた負荷状態を管理する。

コネクション管理部１０７は、クライアント１０５からリクエストに基づいて、各フロントサーバ１０２へのコネクションの確立・解放を制御する。また、この制御に基づいて、コネクション管理部１０７は、各フロントサーバ１０２に対して確立しているアプリケーション毎の現在のコネクション数を管理する。

振分け処理部１０８は、各エンドサーバ１０３及び各フロントサーバ１０２の負荷情報と、各フロントサーバ１０２の振分け情報に基づいて、各アプリケーション毎のコネクション数により、振分け対象のフロントサーバ１０２を決定する。

図２は、各フロントサーバ１０２において実行される負荷計測エージェント１０９のシステム構成図である。負荷計測エージェント１０９は、以下のエンドサーバ統計情報取得処理、エンドサーバ取得統計情報解析処理、及び統計情報通知処理を実行する。

まず、エンドサーバ取得統計情報解析処理（ステップＳ２０１）では、次に説明するエンドサーバ統計情報取得処理にて統計情報を収集すべき各アプリケーション１１０を決定するためのアプリケーションパス情報が取得される。このアプリケーションパス情報は例えば、フロントサーバ１０２上で実行されているサーバアプリケーションにおいて定義ファイル（例えばhttpd.conf）として設定されている設定情報から自動収集できる。或いは、ユーザにより定義された設定情報にて指定される解析方法に基づいて収集できる。このアプリケーションパス情報は各アプリケーションのディレクトリ情報であって言い換えれば、エンドサーバのアプリケーション毎の負荷状態の識別情報である。このアプリケーションパス情報は、自装置がアクセスするエンドサーバ毎に、アプリケーション１１０のプログラム実行状態として、各エンドサーバ上のアプリケーションの使用状態、すなわち負荷状態として計測するために必要となるディレクトリ情報である。

次に、エンドサーバ統計情報取得処理（ステップＳ２０２）では、各エンドサーバ１０３（エンドサーバＡ〜Ｄ）で実行される各アプリケーション１１０（アプリ１〜４）について、以下の処理が実行される。なお、各アプリケーション１１０は、ステップＳ２０１のエンドサーバ取得統計情報解析処理にて取得されたアプリケーションパス情報に基づいて決定される。まず、アプリケーションパス情報に対応するアプリケーション１１０毎に、各アプリケーション１１０が動作しているか否かを検査する生存監視処理が、定期的に実行される。また、アプリケーションパス情報に対応する、アプリケーション１１０毎に負荷状態を判断するための統計情報が取得される。統計情報は例えば、サーバ負荷分散装置１０１から到達する上記アプリケーション１１０向けのリクエストの要求数と、エンドサーバ１０３上の上記アプリケーション１１０に発行されたリクエストの応答時間の平均・最小・最大値である。リクエストの要求数は、サーバ負荷分散装置１０１から自身のフロントサーバ１０２への該当するリクエストの到達時にカウントアップされる。リクエストの応答時間は、フロントサーバ１０２からエンドサーバ１０３へ該当するリクエストが発行されてからその応答が受信されるまでの時間として計測される。これらの統計情報は言い換えれば、アプリケーションパス情報に基づいて特定される自装置がアクセスする各エンドサーバ上の負荷発生単位毎のエンドサーバ負荷状態の統計情報であるといえる。

次に、統計情報通知処理（ステップＳ２０３）では、上述のアプリケーション１１０毎の統計情報と、自装置であるフロントサーバ１０２自身の負荷情報が、一定時間毎にサーバ負荷分散装置１０１に通知される。フロントサーバ１０２自身の負荷情報は例えば、ＣＰＵ（中央演算処理装置）の負荷率やバッファ使用率等である。

図３は、サーバ負荷分散装置１０１において実行される統計情報受信制御部１０６、振分け処理部１０８、及びコネクション管理部１０７のシステム構成図である。
統計情報受信制御部１０６は、以下の統計情報受信処理及び振分け比率設定処理を実行する。

まず、統計情報受信処理では、各フロントサーバ１０２の負荷計測エージェント１０９と定期的に通信が実行される。この通信は、前述のステップＳ２０３の統計情報通知処理との間で実行される。これにより、各フロントサーバ１０２におけるアプリケーション１１０毎の統計情報とコネクション数がサーバ統計情報３０１として管理される。

そして、振分け比率設定処理では、コネクション管理部１０７が管理するコネクション情報３０３と統計情報受信処理で受信された統計情報とに基づいて、各フロントサーバ１０２への振分け比率が計算される。その計算結果は、振分け情報３０２として、振分け処理部１０８に保持される。

次に、振分け処理部１０８は、コネクション管理部１０７からのフロントサーバ１０２の選択要求に対して、振分け情報３０２に基づいてフロントサーバ１０２を決定し、その決定結果をコネクション管理部１０７に通知する。

コネクション管理部１０７は、クライアント１０５（図１）からのリクエストを、フロントサーバ１０２に振り分け、コネクション毎に管理する。また、コネクション管理部１０７は、コネクションの確立時に、振分け処理部１０８にフロントサーバ１０２の選択要求を通知し、決定されたフロントサーバ１０２の情報を受け取る。そして、コネクション管理部１０７は、振分け処理部１０８から通知されたフロントサーバ１０２との間で、コネクションを確立する。ここで、フロントサーバ１０２とエンドサーバ１０３間に確立されている、ある時点のサーバ負荷分散装置１０１とフロントサーバ１０２とのコネクションのアプリケーション毎の数が、アプリケーション毎（負荷状態毎）のコネクション数として定義される。コネクション管理部１０７は、このアプリケーション毎のコネクション数をコネクション情報３０３として保持する。このように、コネクション数がアプリケーション毎に管理されることにより、アプリケーションのコネクション数が把握されることになる。

以上説明した本実施形態の構成の詳細な動作について、図４から図１２での各動作フローチャート、図１３から図１９でのデータ構成例を示す図、及び図２０及至２４の制御シーケンスの動作説明図に基づいて順次説明する。図４から図１２及び図２２から図２５に示す処理は、例えばＣＰＵとメモリと外部記憶装置とを搭載したコンピュータが実行する。

図４は、各フロントサーバ１０２の負荷計測エージェント１０９において実行される、図２のステップＳ２０１のエンドサーバ取得統計情報解析処理の詳細を示す動作フローチャートである。ここでは、アプリケーションパス情報が取得される。

前述したように、このアプリケーションパス情報の取得は、ユーザ、すなわちフロントサーバ設定者により定義された解析方法に基づいてでも、自動収集に基づいてでも、どちらでもよい。ユーザが解析方法を定義する場合には、ユーザは例えば予め、解析方法を指定する設定情報ファイルを、フロントサーバ１０２上のファイルシステム内の所定のファイルパスに保存する。

まず、ユーザにより解析方法が指定されているかが判定される（ステップＳ４０１）。
ユーザにより解析方法が指定されておらずステップＳ４０１の判定がＮＯならば、フロントサーバ１０２にて起動されているデーモンアプリケーションが調査される（ステップＳ４０２）。デーモンアプリケーションとは、フロントサーバ１０２のメモリ上に常駐して実行中のプログラムをいう。デーモンアプリケーションの調査は、フロントサーバ１０２において現在実行されているプロセスを調査するためのコマンドにより、実施することができる。例えば、ＰＳ（プロセス）コマンドと呼ばれるコマンドにより起動デーモンを調べる。

図１３は、ＰＳコマンドによる起動デーモンの調査処理の動作例を示す図である。この動作例では、破線枠で囲まれた部分からわかるように、デーモンアプリケーションとして、ａｐａｃｈｅと呼ばれるＷｅｂサーバアプリケーションが起動されていることを示している。

次に、デーモンアプリケーションの種類に応じたアプリケーションパス情報設定場所から、アプリケーションパス情報が取得される（ステップＳ４０３）。例えば図１３に示されるように、デーモンアプリケーションとしてＷｅｂ（ＷＷＷ）サーバアプリケーションが起動されている場合を考える。この場合、図１３の破線枠で囲まれた部分のパス情報より、アプリケーションパス情報の設定場所が、
/var/www/conf/httpd.conf
というファイルパスに存在する定義ファイルhttpd.conf内に記述されていることが、Ｗｅｂサーバアプリケーションの実装規則から認識することができる。認識のための具体的な処理としては、次のような方式が採用できる。即ち例えば、起動する可能性のあるデーモンアプリケーション毎に、ステップＳ４０２での調査結果出力（検出パス）とアプリケーションパス情報設定場所（定義ファイル）との対応関係が予めコーディングされる。或いは、そのような対応関係が対応テーブルとして記憶される。そして、ステップＳ４０２での調査結果出力を使って、コーディング規則又は対応テーブルが検索され、アプリケーションパス情報の設定場所が検出される。

図１４は、フロントサーバ１０２が例えばＷｅｂサーバである場合のアプリケーションパス情報の取得動作の説明図である。
まず代表的なＷｅｂサーバアプリケーションでは、httpd.confのような定義ファイル内には、例えば図１４に示される「Directory」項目と呼ばれる項目が設定されている。この項目は、クライアント１０５からのリクエストに基づいて実行されるプログラムの格納場所を示している。例えば、
<Directory “/var/www/cgi-bin/apl01”>
というディレクトリ項目の記述は、以下の意味を有する。即ち、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）というプログラムインタフェース仕様に準拠した外部プログラムが、フロントサーバ１０２のファイルシステム内の“/var/www/cgi-bin/apl01”というディレクトリパス内に格納されていることが設定される。同様に例えば、
<Directory “/var/www/servlet/apl02”>
<Directory “/var/www/servlet/apl03”>
というディレクトリ項目の記述は、以下の意味を有する。即ち、Ｊａｖａ Ｓｅｒｖｌｅｔと呼ばれるプログラムインタフェース仕様に準拠した外部プログラムが格納されている場所が、フロントサーバ１０２のファイルシステム内の“/var/www/cgi-bin/apl02”又は“/var/www/cgi-bin/apl03”というディレクトリパス内に格納されていることが設定される。

上述のディレクトリ項目から認識される各パス情報について更に、各ディレクトリ内に格納されているファイルの一覧を表示するコマンドにより、各ディレクトリ内に格納されているアプリケーションプログラムを調査することができる。例えば、ｌｓコマンドと呼ばれるコマンドがよく知られている。例えば下記に示されるコマンドが実行される。
ls /var/www/cgi-bin/apl01
この結果、このディレクトリ内に格納されている例えば下記に示されるようなプログラムのリストが表示される。
index.php
proc01.php
これらの例えば２つのプログラムは、ＰＨＰと呼ばれるスクリプト言語によって記述されたプログラムである。

以上のディレクトリ項目のパス情報とｌｓコマンドの実行情報とに基づいて、例えば下記に示されるような実行パスをアプリケーションパス情報の一部として抽出することができる。
cgi-bin/apl01/index.php
servlet/apl02/proc02
servlet/apl03/proc03
なお、「/var/www/cgi-bin/apl01/proc01.php」は、エンドサーバ１０３にアクセスしないプログラムであるため、実行パスとしては抽出されない。また、「/var/www/」の記述部分は、「DocumentRoot」と呼ばれる、実行パスにおいては省略される。この部分は、クライアント１０５がＷｅｂリクエストを発行する際にＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）と呼ばれる形式でアプリケーションの実行パスを指定する場合には、省略されるディレクトリパス部分である。これらの実行パスは、クライアント１０５がリクエストを発行する際に指定するＵＲＩとしてそのまま記述される。

ここで、「index.php」「proc02」「proc03」等のプログラムは、フロントサーバ１０２上で実行されるが、これらのプログラム内から、エンドサーバ１０３上のアプリケーション１１０（アプリ１、アプリ２、アプリ３等）がアクセスされる。例えば、リクエスト中のＵＲＩにおいて、
cgi-bin/apl01/index.php
が指定されると、「index.php」のスクリプトプログラム内から、エンドサーバＡで実行されるアプリ１がアクセスされる。また例えば、
servlet/apl02/proc02
が指定されると、「proc02」のサーブレット（サーブレットａ）内から、エンドサーバＡで実行されるアプリ２がアクセスされる。更に例えば、
servlet/apl03/proc03
が指定されると、「proc03」のサーブレット（サーブレットｂ）内から、エンドサーバＢで実行されるアプリ３がアクセスされる。

本実施形態では、上述の実行パスと共に、それらによって実行されるプログラムがアクセスするエンドサーバ１０３の「所在」、例えばホスト名が、実行パスで指定される各プログラムから抽出される。例えばエンドサーバＡにて実行されるアプリ１がデータベースにアクセスするアプリケーションプログラムであった場合を考える。この場合、例えば「index.php」内では、図１４の下方に示されるような「pg_connect」というデータベース接続関数によって、エンドサーバＡのホスト名“APsv1”が指定されている。従って、データベースアプリケーションの種別がわかっている場合には、ＰＨＰスクリプトやＪａｖａ Ｓｅｒｖｌｅｔプログラム内から上述の「pg_connect」として例示されるようなデータベース接続関数をキーとして、所在情報を抽出することができる。本実施形態では、この所在情報も、上述のアプリケーションパス情報の一部として扱われる。なお、エンドサーバＣ及びエンドサーバＤのように複数のエンドサーバ１０３が仮想サーバ１０４（仮想サーバＥ）によって分散制御されているような場合には、単一の仮想的なホスト名“Vsv1”が所在情報として抽出される。これにより、あたかも１台のエンドサーバに対してアクセスするような制御が実現される。

以上のようにして、図４のステップＳ４０３において、実行パス及び所在情報からなるアプリケーションパス情報が抽出できると、ステップＳ４０４の判定がＹＥＳとなる。その後、上述のようにして取得された各アプリケーションパス情報を各エントリ行として有する、図１４に示されるアプリケーションパス管理情報１４０１が、フロントサーバ１０２内に保持される（ステップＳ４０９）。この部分の処理は、図２２の動作シーケンス図において、Ｓ４０９として示される。アプリケーションパス管理情報１４０１において、実行パス及び所在からなるアプリケーションパス情報のほかの、「状態」及び「統計情報」を示す部分は、初期登録時には未登録である。

ステップＳ４０９の処理の後、負荷計測エージェント１０９により、エンドサーバ取得統計情報解析処理を終了する。
ここで、なんらかの理由によりアプリケーションパス情報が抽出できずステップＳ４０４での判定がＮＯとなった場合には、次の処理が実行される。即ち、フロントサーバ１０２にインストールされているアプリケーション中に、Ｗｅｂサーバアプリケーションのような、エンドサーバ１０３への中継が可能なアプリケーションが存在するか否かが調べられる（ステップＳ４０５）。例えば、フロントサーバ１０２のハードディスク記憶装置上のファイルシステム内のシステムディレクトリが検索され、該当する実行アプリケーションが見つけられる。

次に、該当するアプリケーションが存在するか否かが判定される（ステップＳ４０６）。
該当するアプリケーションが見つかってステップＳ４０６の判定がＹＥＳならば、インストールされているアプリケーションの種類に応じたアプリケーションパス情報設定場所から、アプリケーションパス情報が取得される（ステップＳ４０７）。ここでの処理は、前述したステップＳ４０３の場合と同様である。

ステップＳ４０７において、実行パス及び所在情報からなるアプリケーションパス情報が抽出された後、図１４に示されるアプリケーションパス管理情報１４０１が、フロントサーバ１０２内に保持される（ステップＳ４０９）。

ステップＳ４０９の処理の後、負荷計測エージェント１０９により、エンドサーバ取得統計情報解析処理を終了する。
一方、インストールされているアプリケーション中からも該当するアプリケーションが見つからずステップＳ４０６の判定がＮＯならば、そのまま、エンドサーバ取得統計情報解析処理を終了する。このように、アプリケーションパス情報が取得できない場合には、その後、負荷計測エージェント１０９が動作できないため、フロントサーバ１０２の異常と認識される。この場合には、後述するエンドサーバ統計情報取得処理及び統計情報通知処理が実行されず、フロントサーバ１０２は振り分け対象のサーバにはならない。

エンドサーバ取得統計情報解析処理において、ユーザにより解析方法が指定されていて前述したステップＳ４０１の判定がＹＥＳならば、まずユーザが設定した設定情報ファイルの内容が読み取られる。これにより、その設定情報により指定された解析方法から、アプリケーションパス情報が取得される（ステップＳ４０８）。

図１５は、設定情報ファイルのデータ構成例を示す図である。この設定情報ファイルには例えば、前述したステップＳ４０３にて検出された実行パスと同様のものが設定されている。この実行パス（例えば、cgi-bin/ap101/index.php）とその実行パスで指定されるプログラムから検出された所在情報(例えば、APsv1)とからなるアプリケーションパス情報が取得される。なお、設定情報ファイルには、後述するアプリケーション１１０の生存監視処理の方法を指定する設定も含めることができる。例えば、生存監視処理時のエンドサーバ１０３へのアクセス方法（「method GET」の部分）、監視間隔時間（「interval-time 10」）、再試行回数（「retry-count 5」の部分）等の設定が含まれる。

ステップＳ４０８において、実行パス及び所在情報からなるアプリケーションパス情報が抽出された後、図１４に示されるアプリケーションパス管理情報１４０１が、フロントサーバ１０２内に保持される（ステップＳ４０９）。

ステップＳ４０９の処理の後、負荷計測エージェント１０９により、エンドサーバ取得統計情報解析処理を終了する。

次に、図５は、負荷計測エージェント１０９により実行される図２のステップＳ２０２のエンドサーバ統計情報取得処理のうち、エンドサーバ通信監視（生存監視）の処理の詳細を示す動作フローチャートである。ここでは前述したように、各エンドサーバ１０３で実行される各アプリケーション１１０について、各アプリケーション１１０が動作しているか否かを検査する生存監視処理が、定期的に実行される。

まず、図４にて説明したエンドサーバ取得統計情報解析処理に基づいて取得されたアプリケーションパス情報が取得される（ステップＳ５０１）。アプリケーションパス情報は、図４のステップＳ４０９にて保持されたアプリケーションパス管理情報１４０１中の実行パス及び所在情報の各エントリ行として取得することができる。

次に、ステップＳ５０１で取得されたアプリケーションパス情報の全ての実行パスが検査されたか否かが判定される（ステップＳ５０２）。
全ての実行パスが検査されておらずステップＳ５０２の判定がＮＯならば、ステップＳ５０１で取得されたアプリケーションパス情報から１つのエントリ行中の実行パスと所在情報が取り出される。そして、所在情報（例えばホスト名）によって指示されるエンドサーバ１０３の実行パスに対して生存監視が行われる（ステップＳ５０３）。例えば、フロントサーバ１０２がＷｅｂ（ＷＷＷ）サーバアプリケーションを起動しており、ＨＴＴＰ（ハイパーテキストトランスファプロトコル）による通信を実行している場合、以下の処理が実行される。即ち、実行パスで指定されるＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）パスへ、ＨＴＴＰにて規定されるＧＥＴ又はＨＥＡＤメソッドによる生存確認のＨＴＴＰリクエストが送信され、応答が受信される。なお、このメソッド即ちエンドサーバ１０３へのアクセス方法は例えば、図１５に示される前述した設定情報ファイル（「method GET」の部分）にて指定することもできる。ここで、ＵＲＬによって指定されているパスが、図１の仮想サーバ１０４を指している場合であっても、そのことを意識する必要はなく、単にそのＵＲＬパスへＨＴＴＰリクエストが送信されればよい。以上の処理は、図２２の動作シーケンス図において、Ｓ５０３として示される。

次に、上述の生存監視の応答が受信されたか否かが判定される（ステップＳ５０４）。
一定時間内に生存監視の応答が受信できずステップＳ５０４の判定がＮＯならば、以下の処理が実行される。即ち、図１４のアプリケーションパス管理情報１４０１中の該当するエントリ行において、「状態」項目に「down」が登録され、「エラー発生回数」項目の値がカウントアップされ、「エラー発生率」項目の値が再計算される（ステップＳ５０５）。この処理は、図２２の動作シーケンス図において、Ｓ５０５として示される。「エラー発生率」項目の値は、「エラー発生回数」項目の値を「要求数」項目の値で除算して得られる値として算出される。「エラー発生率」項目の値は、エンドサーバ１０３の安定度評価の指標として用いられる。なお、ここでは、生存確認が何回か再試行されるような構成が採用されてもよい。この場合の再試行回数は例えば、図１５に示される前述した設定情報ファイル（「retry-count 5」の部分）にて指定することもできる。

その後、ステップＳ５０２の処理に戻り、次のアプリケーションパス情報の取得が試みられる。
一定時間内に生存監視の応答が受信できてステップＳ５０４の判定がＹＥＳならば、図１４のアプリケーションパス管理情報１４０１中の該当するエントリ行において、「状態」が「down」ならば「up」に変更される（ステップＳ５０６）。この処理は、図２２の動作シーケンス図において、Ｓ５０６として示される。

以上のようにして、１組のアプリケーションパス情報に対する生存確認の処理が終了すると、ステップＳ５０２の処理に戻り、次のアプリケーションパス情報の取得が試みられる。

ステップＳ５０１で取得されたアプリケーションパス情報の全ての実行パスが検査されステップＳ５０２の判定がＹＥＳになると、生存監視間隔タイマが起動される（ステップＳ５０７）。この処理は、図２２の動作シーケンス図において、Ｓ５０７として示される。

その後、生存監視間隔タイマがタイムアウトして監視間隔時間が経過したか否かが判定される（ステップＳ５０８）。なお、この生存監視間隔タイマが計測する監視間隔時間は例えば、図１５に示される前述した設定情報ファイル（「interval-time 10」の部分）にて指定することもできる。

監視間隔時間が経過しておらずステップＳ５０８の判定がＮＯならば、負荷計測エージェント１０９の終了が指示されたか判定される（ステップＳ５０９）。
負荷計測エージェント１０９の終了が指示されておらずステップＳ５０９の判定がＮＯならば、再びステップＳ５０８に戻って、監視間隔時間が経過したか否かが判定される。

監視間隔時間が経過しステップＳ５０８の判定がＹＥＳとなると、ステップＳ５０２の判定に戻って、ステップＳ５０１で取得されたアプリケーションパス情報について再度、順次アプリケーションパス情報の取得が試みられる。

負荷計測エージェント１０９の終了が指示されステップＳ５０９の判定がＹＥＳとなると、図５のエンドサーバ統計情報取得処理（エンドサーバ通信監視（生存監視））を終了する。

以上のようにして、監視間隔時間毎に、各エンドサーバ１０３の各アプリケーション１１０について、生存監視を行うことができる。この結果、図２２から続く図２３のＳ５０３、Ｓ５０５又はＳ５０６、Ｓ５０７、図２３から続く図２４のＳ５０３、Ｓ５０５又はＳ５０６、Ｓ５０７といった動作シーケンスが繰り返されることになる。

図６は、負荷計測エージェント１０９により実行される図２のステップＳ２０２のエンドサーバ統計情報取得処理のうち、要求数計算処理の詳細を示す動作フローチャートである。この動作フローチャートの処理は、フロントサーバ１０２がサーバ負荷分散装置１０１よりクライアント１０５からのリクエストを受信する毎に実行される。

まず、図４にて説明したエンドサーバ取得統計情報解析処理に基づいて生成されたアプリケーションパス管理情報１４０１において、受信リクエスト中のＵＲＩを実行パスとして有するアプリケーションパス情報が取得される（ステップＳ６０１）。

次に、受信リクエストがエンドサーバへの要求であるか否かが判定される（ステップＳ６０２）。
ステップＳ６０２の判定がＹＥＳならば、ステップＳ６０１でアプリケーションパス情報が取得されたアプリケーションパス管理情報１４０１中の該当エントリ行において、「要求数」項目の値がカウントアップされる（ステップＳ６０３）。この処理は、図２３から続く図２４の動作シーケンス図において、Ｓ６０３として示される。その後、図６の動作フローチャートの処理を終了する。

以上のようにして、サーバ負荷分散装置１０１からフロントサーバ１０２への要求数（リクエストの数）が計測される。

図７（ａ）は、負荷計測エージェント１０９により実行される図２のステップＳ２０２のエンドサーバ統計情報取得処理のうち、応答時間計測処理の前半部分の処理の詳細を示す動作フローチャートである。この動作フローチャートの処理は、フロントサーバ１０２がサーバ負荷分散装置１０１よりクライアント１０５からのリクエストを受信する毎に実行される。

まず、図４にて説明したエンドサーバ取得統計情報解析処理に基づいて生成されたアプリケーションパス管理情報１４０１において、受信リクエスト中のＵＲＩを実行パスとして有するアプリケーションパス情報が取得される（ステップＳ７０１）。

次に、ステップＳ７０１にて取得されたアプリケーションパス情報中の所在情報が確認されることにより、受信リクエストがエンドサーバ１０３へのリクエストか否かが判定される（ステップＳ７０２）。なお、受信リクエストが仮想サーバ１０４へのリクエストである場合（図１４において「所在」が例えば「Vsv1」である場合）も、エンドサーバ１０３へのリクエストであると判定される。

受信リクエストがエンドサーバ１０３へのリクエストではなくステップＳ７０２の判定がＮＯならば、そのリクエストはフロントサーバ１０２内で処理されるため、図７（ａ）の動作フローチャートの処理を終了する。

受信リクエストがエンドサーバ１０３へのリクエストでステップＳ７０２の判定がＹＥＳならば、以下の処理が実行される。即ち、受信リクエストが、ステップＳ７０１にて取得されたアプリケーションパス情報中の所在情報で示されるエンドサーバ１０３へ送信される（ステップＳ７０３）。

最後に、ステップＳ７０１にて取得されたアプリケーションパス情報に対応するエンドサーバ１０３の実行パスに対応して、応答時間を計測するためのタイマがスタートされ、応答時間の計測が開始される（ステップ７０４）。この処理は、図２３から続く図２４の動作シーケンス図において、Ｓ７０４として示される。

その後、リクエスト受信時の図７（ａ）の動作フローチャートの処理が終了する。
図７（ｂ）は、負荷計測エージェント１０９により実行される図２のステップＳ２０２のエンドサーバ統計情報取得処理のうち、応答時間計測処理の後半の処理の詳細を示す動作フローチャートである。この動作フローチャートの処理は、１つのリクエストがエンドサーバ１０３に送信される毎に、そのリクエストに対応する応答をエンドサーバ１０３から待ち受ける処理として起動される。この処理は、図７（ａ）の動作フローチャートにて受信リクエストがエンドサーバ１０３に送信されたときに、そのリクエストに対応するアプリケーションパス情報（実行パス及び所在情報）を保持している。

まず、上記所在情報に対応するエンドサーバ１０３の、上記実行パスに対応するアプリケーション１１０から、送信されたリクエストに対応する応答を、一定時間内に受信できたか否かが判定される（ステップＳ７０５）。

一定時間内に応答が受信できずステップＳ７０５の判定がＮＯならば、上記アプリケーションパス情報に対応するエンドサーバ１０３の実行パスに対応して起動されていた応答時間の計測タイマがストップされる。これにより、応答時間の計測が停止される（ステップＳ７０６）。

その後、図７（ｂ）の動作フローチャートの処理を終了する。
一定時間内に応答が受信できステップＳ７０５の判定がＹＥＳになると、まず、上記アプリケーションパス情報に対応するエンドサーバ１０３の実行パスに対応して起動されていた応答時間の計測タイマがストップされる。これにより、応答時間の計測が停止され、そのタイマ値として応答時間が取得される（ステップＳ７０７）。この処理は、図２４から続く図２５の動作シーケンス図において、Ｓ７０５及びＳ７０７として示される。

次に、図１４のアプリケーションパス管理情報１４０１中の上記アプリケーションパス情報に対応するエントリ行において、統計情報中の各応答時間情報が更新される（ステップＳ７０８）。まず、「平均応答時間」項目の値が、ステップＳ７０７にて新たに取得された応答時間の計測値を用いて再計算され記録される。また、「最小応答時間」項目の値として、今回の応答時間の計測値が「最小応答時間」項目に現在設定されている値未満である場合に、その項目値が今回の計測値に更新される。更に、「最大応答時間」項目の値として、今回の応答時間の計測値が「最大応答時間」項目に現在設定されている値より大きい場合に、その項目値が今回の計測値に更新される。以上の処理は、図２４から続く図２５の動作シーケンス図において、Ｓ７０８として示される。

その後、図７（ｂ）の動作フローチャートの処理を終了する。
以上の図７（ａ）及び図７（ｂ）の動作フローチャートの処理により、各エンドサーバ１０３で実行される各アプリケーション１１０毎に、そのアプリケーション１１０に対するリクエストの要求数と、応答時間情報を取得することができる。

図１６は、図１のフロントサーバＡ及びフロントサーバＢの各々について、負荷計測エージェント１０９による図２のステップＳ２０２のエンドサーバ統計情報取得処理により取得されるアプリケーションパス管理情報１４０１のデータ構成例を示す図である。この図から理解されるように、各フロントサーバ１０２において、実行パスと所在情報とで規定されるアプリケーションパス情報毎の稼働状態とリクエスト発行に関する統計情報が取得できることがわかる。これらの情報は、言い換えれば、各エンドサーバ１０３の各アプリケーション１１０毎の負荷状態を示している情報であるといえる。このように、本実施形態では、各フロントサーバ１０２において、リクエスト発行に対する各エンドサーバ１０３の各アプリケーション１１０毎の負荷状態を取得することが可能となる。

図８は、負荷計測エージェント１０９により実行される図２のステップＳ２０３の統計情報通知処理の詳細を示す動作フローチャートである。この処理では、前述したように、アプリケーションパス情報毎の状態及び統計情報と、自装置であるフロントサーバ１０２自身の負荷状態が、一定時間毎にサーバ負荷分散装置１０１に通知される。

まず、サーバ負荷分散装置１０１からの制御コネクションの確立が待たれる（ステップＳ８０１）。制御コネクションの確立処理について後述する。
制御コネクションが確立したら、制御コネクションの切断が発生しているか否かが確認されながら、サーバ負荷分散装置１０１からの統計情報通知開始要求の制御パケットの受信が待たれる（ステップＳ８０２→Ｓ８０３→Ｓ８０２の処理の繰返し）。

サーバ負荷分散装置１０１からの統計情報通知開始要求の制御パケットが受信されると、まず、送信時間間隔タイマが起動される（ステップＳ８０４）。この処理は、図２２の動作シーケンス図において、Ｓ８０４として示される。

次に、制御コネクションの切断が発生しているか否かが確認されながら、送信時間間隔タイマがタイムアウトして送信間隔時間が経過したか否かが判定される（ステップＳ８０５→Ｓ８０６→Ｓ８０５の処理の繰返し）。

送信間隔時間が経過しステップＳ８０６の判定がＹＥＳになると、図１４又は図１６に示されるアプリケーションパス管理情報１４０１が取得される。そして、図２０（ｂ）に示されるデータ構成例を有する統計情報通知の制御パケットに格納される（ステップＳ８０７）。この制御パケットは例えば、プロトコルを識別するプロトコル識別子と、「統計情報通知」が設定されたパケット種別と、統計情報のデータ長が格納された統計情報長と、統計情報種別とそれに対応する統計情報値との組とからなる情報を含む。この制御パケットの基本フォーマットは例えば、ＵＤＰ（ユーザ・データグラム・プロトコル）に従うが、ＴＣＰ／ＩＰ(トランスファ・コントロール・プロトコル／インターネット・プロトコル)でも良い。

次に、フロントサーバ１０２自身の最新の負荷状態が取得され、上記と同様の統計情報通知の制御パケットに、フロントサーバ１０２の負荷状態として格納される（ステップＳ８０８）。フロントサーバ１０２自身の従来の負荷状態は例えば、ＣＰＵ（中央演算処理装置）の負荷率やバッファ使用率等である。 そして、サーバ負荷分散装置１０１に、ステップＳ８０７及びＳ８０８にて作成された統計情報通知の制御パケットが送信される（ステップＳ８０９）。その後、ステップＳ８０４に戻って、次の送信間隔タイマが起動される。

以上のステップＳ８０７からＳ８０９までの一連の処理は、図２２から続く図２３の動作シーケンス図において、Ｓ８０７，Ｓ８０８，Ｓ８０９として示される。
その後、ステップＳ８０４の処理に戻る。この処理は、図２２から続く図２３の動作シーケンス図において、Ｓ８０４として示される。

以上のようにして、一定の送信間隔時間毎に、各フロントサーバ１０２の負荷計測エージェント１０９からサーバ負荷分散装置１０１に、アプリケーションパス管理情報１４０１と、フロントサーバ１０２自身の最新の負荷状態を送信することができる。この結果、図２２から続く図２３のＳ８０７，Ｓ８０８，Ｓ８０９，Ｓ８０４、図２４から続く図２５のＳ８０７，Ｓ８０８，Ｓ８０９，Ｓ８０４といった動作シーケンスが繰り返されることになる。これにより、サーバ負荷分散装置１０１は、各エンドサーバ１０３から直接負荷状態を収集することなく、各エンドサーバ１０３に対するアプリケーション１１０毎のアクセス状況も含めた各エンドサーバ１０３の正確な負荷状態をフロントサーバ１０２を介して収集することが可能となる。

図９は、図１のサーバ負荷分散装置１０１内の統計情報受信制御部１０６によって実行される図３のステップＳ３０１の統計情報受信処理の詳細を示す動作フローチャートである。この処理では、前述したように、上述した負荷計測エージェント１０９による統計情報通知処理（図２のステップＳ２０３）によって送信されたアプリケーションパス管理情報１４０１とフロントサーバ１０２自身の最新の負荷状態が受信される。

まず、サーバ負荷分散装置１０１に定義されている振分け対象のフロントサーバ１０２の負荷計測エージェント１０９に対して、制御コネクションの確立処理が実行される（ステップＳ９０１）。

続いて、図１の振分け処理部１０８から各フロントサーバ１０２の負荷計測エージェント１０９に対して、統計情報通知開始要求の制御パケットが送信される（ステップＳ９０２）。この処理は、図２２の動作シーケンス図において、Ｓ９０２として示される。図２０（ａ）は、統計情報通知開始要求の制御パケットのデータ構成例を示す図である。この制御パケットは例えば、プロトコルを識別するプロトコル識別子と、「統計情報通知開始要求」が設定されたパケット種別の情報を含む。この制御パケットの基本フォーマットは例えば、ＵＤＰに従うが、ＴＣＰ／ＩＰでもよい。

次に、各フロントサーバ１０２の負荷計測エージェント１０９から、一定時間内に統計情報通知の制御パケットが受信されたか否かが判定される（ステップＳ９０３）。
一定時間内に統計情報通知の制御パケットが受信されずステップＳ９０３の判定がＮＯになったならば、一定回数だけ統計情報通知の制御パケットの未受信状態が繰り返されたか否かが判定される（ステップＳ９０４）。

未受信状態が一定回数に達しておらずステップＳ９０４の判定がＮＯならば、ステップＳ９０２の処理に戻り、統計情報通知開始要求の制御パケットの送信が再試行される。
未受信状態が一定回数に達してステップＳ９０４の判定がＹＥＳになると、該当するフロントサーバ１０２の負荷計測エージェント１０９が異常であると判断される。そして、そのフロントサーバ１０２に対する統計情報受信処理が、一定時間後に再開するまで休止される（ステップＳ９０５）。

一方、一定時間内に統計情報通知の制御パケットが受信されステップＳ９０３の判定がＹＥＳになると、以下の処理が実行される。即ち、受信された統計情報通知の制御パケットに問題がなければ、サーバ負荷分散装置１０１内のサーバ統計情報３０１（図３）が、受信された統計情報通知の制御パケット内の統計情報で更新される（ステップＳ９０６）。この処理は、図２２から続く図２３又は図２４から続く図２５の動作シーケンス図において、Ｓ９０６として示される。制御パケットに問題があるか否かは、例えば制御パケットに付加されている誤り訂正符号をチェックして判定される。なお、受信した統計情報通知の制御パケットに問題があれば、未受信として扱われる。

その後、ステップＳ９０３の処理に戻って、次の統計情報通知の制御パケットの受信が待たれる。
上述の動作フローチャートでは特には図示しないが、サーバ負荷分散装置１０１は、各フロントサーバ１０２の負荷計測エージェント１０９に対し、統計情報通知終了要求の制御パケットを送信する。これにより、上述の統計情報受信処理を終了させることができる。図２０（ｃ）は、統計情報通知開始要求の制御パケットのデータ構成例を示す図である。この制御パケットは例えば、プロトコルを識別するプロトコル識別子と、「統計情報通知終了要求」が設定されたパケット種別の情報を含む。この制御パケットの基本フォーマットは例えば、ＵＤＰに従うが、ＴＣＰ／ＩＰでも良い。図２１は、上述した統計情報通知の制御シーケンスを示す図である。サーバ負荷分散装置１０１から各フロントサーバ１０２に統計情報通知開始要求の制御パケットが送信されることにより、統計情報の通知シーケンスが開始される。これ以後、各フロントサーバ１０２からサーバ負荷分散装置１０１に統計情報通知の制御パケットが送信される。送信終了後、サーバ負荷分散装置１０１が各フロントサーバ１０２に統計情報通知終了要求の制御パケットを送信し、それに対して各フロントサーバ１０２がサーバ負荷分散装置１０１に統計情報通知終了応答の制御パケットを返信する。これにより、統計情報の通知シーケンスが終了する。

統計情報受信処理によって、図１の統計情報受信制御部１０６は、例えば図１７のデータ構成例を有するサーバ統計情報３０１（図３）を取得することができる。図１７に示されるサーバ統計情報３０１において、フロントサーバ１０２を識別するための「サーバ識別情報」項目として、各フロントサーバ１０２のＩＰアドレスが設定される。また、「状態」項目として、稼働状態を示す「up」又は非稼働状態を示す「down」が設定される。この値は、図９のステップＳ９０５が実行されたときに「down」にされ、ステップＳ９０６が実行されたときに「up」にされる。「フロントサーバ統計情報」項目には、図８のステップＳ８０８及びＳ８０９の各処理に基づいて通知されたフロントサーバ１０２の負荷情報が設定される。「実行パス」「所在」「状態」「エンドサーバ統計情報には、図８のステップＳ８０７及びＳ８０９の各処理に基づいて通知されたアプリケーションパス管理情報１４０１（図１４又は図１６参照）の各内容が設定される。

以上のようにして、サーバ負荷分散装置１０１の統計情報受信制御部１０６は、各フロントサーバ１０２から、各エンドサーバ１０３の各アプリケーション１１０毎の負荷状態を示す統計情報と、従来の各フロントサーバ１０２自身の負荷状態を収集できる。

図１０は、図１のサーバ負荷分散装置１０１内の統計情報受信制御部１０６によって実行される図３のステップＳ３０２の振分け比率設定処理の詳細を示す動作フローチャートである。この処理では、前述したように、コネクション管理部１０７が管理するコネクション情報３０３と上述の統計情報受信処理（図３のステップＳ３０１）で受信された統計情報とに基づいて、各フロントサーバ１０２への振分け比率が計算される。この動作フローチャートの処理は、一定時間毎に実行される。

まず、図３のサーバ統計情報３０１が更新されたか否かが判定される（ステップＳ１００１）。このサーバ統計情報３０１は、上述した統計情報受信処理（図３のステップＳ３０１）によって更新される。

サーバ統計情報３０１が更新されておらずステップＳ１００１の判定がＮＯならば、今回の振分け比率設定処理を終了する。
サーバ統計情報３０１が更新されおりステップＳ１００１の判定がＹＥＳならば、図１のコネクション管理部１０７から図３のコネクション情報３０３が取得される（ステップＳ１００２）。コネクション情報３０３は、例えば図１９に示されるデータ構成例を有し、各フロントサーバ１０２の各アプリケーションパス情報毎に、現在確立しているコネクション数を記憶している。各フロントサーバ１０２は、図１７に示されるサーバ統計情報３０１内の「サーバ識別情報」によって識別される。アプリケーションパス情報は、サーバ統計情報３０１内の「実行パス」及び「所在」を含むエンドサーバ負荷状態毎の情報である。コネクション情報３０３は、コネクション管理部１０７が実行するコネクションの確立・解放処理によって更新される。例えば、サーバ識別情報の項目がＩＰアドレスならば、フロントサーバＡのＩＰアドレスを意味する。このとき実行パスの項がcgi-bin/ap101/index.phpならば、そのアプリケーションへの所在はエンドサーバのApsv1で、そのアプリケーションへのコネクション数は１１である。

次に、図１の統計情報受信制御部１０６からサーバ統計情報３０１が取得される（ステップＳ１００３）。
そして、ステップＳ１００２で取得されたコネクション情報３０３とステップＳ１００３で取得されたサーバ統計情報３０１から、各フロントサーバ１０２への振分け比率が計算される（ステップＳ１００４）。
振分け比率は、フロントサーバ１０２毎に、そのフロントサーバ１０２に接続する各エンドサーバ１０３のアプリケーションパス情報毎の負荷を重視し、更にアプリケーションパス情報毎のコネクション数を考慮して決定される。例えば、以下のような計算で、振分け比率が算出される。なお、Ｎは、計算対象のフロントサーバに対応するアプリケーションパス管理情報１４０１のエントリ数である。
計算対象のフロントサーバの負荷＝
（（アプリケーションパス情報１に対応するアプリケーションの
コネクション数 × 平均応答時間 ）
＋ ・・・・・＋
（アプリケーションパス情報Ｎに対応するアプリケーションの
コネクション数 × 平均応答時間 ）)
計算対象のフロントサーバへの振分け比率＝
計算対象のフロントサーバの負荷／全フロントサーバの負荷の和

図１６及び図１９の状態において、フロントサーバＡとフロントサーバＢに対する負荷及び振り分け比率は以下となる。
フロントサーバＡの負荷
＝（１１×４）＋（２２×４）＋（４×１２）＋（８×５）＝２２０
フロントサーバＢの負荷
＝（１０×４）＋（２０×４）＋（５×１２）＋（９×５）＝２２５
フロントサーバＡへの振り分け比率＝２２０／（２２０＋２２５）＝０．４９
フロントサーバＢへの振り分け比率＝２２５／（２２０＋２２５）＝０．５１

ここで、例えば、応答時間が短いアプリケーション１１０を多く処理しているフロントサーバ１０２に対しては、より多くのリクエストが送り込まれても、そのリクエストを十分に処理できる。一方、応答時間が長いアプリケーション１１０を処理しているフロントサーバ１０２に対しては、あまり多くのリクエストは送り込まないほうがよい。

しかし、従来のように、単にフロントサーバ１０２が処理しているリクエストの要求数や平均応答時間を計測しただけでは、処理の重いリクエストも軽いリクエストも一括して判断されてしまう。このため、短時間で見たときに、各フロントサーバ１０２において、各エンドサーバ１０３の負荷状態を正確に計測することができない。

また、各フロントサーバ１０２が、各エンドサーバ１０３毎に区別してリクエストの要求数や平均応答時間を計測できたと仮定する。しかしこの場合も、エンドサーバ１０３で処理時間が大幅に異なる複数のアプリケーション１１０が実行されているようなケースでは、各フロントサーバ１０２において、各エンドサーバ１０３上の各アプリケーション１１０へのアクセス状況も含めた負荷状態を正確に計測することができない。

本実施形態では、サーバ負荷分散装置１０１は、各フロントサーバ１０２について、そのフロントサーバ１０２に接続されるエンドサーバ１０３が処理しているアプリケーション毎＝アプリケーションパス情報毎に次の計算を実行する。即ち、アプリケーションパス情報毎に、（アプリケーションのコネクション数×応答時間）を計算する。そして、フロントサーバ１０２上での全てのアプリケーションパス情報に対応する各計算結果の総和を計算し、その結果をそのフロントサーバ１０２の負荷値とする。このように、本実施形態では、各フロントサーバにおける各エンドサーバ１０３の各アプリケーション１１０でのアクセス状況即ち負荷状態が正確に反映された負荷を正しく計算することができる。そして、このようにして計算された各フロントサーバ１０２の負荷の比率を振分け比率として計算し、この振分け比率に基づいてサーバ負荷分散装置１０１から各フロントサーバ１０２へのリクエストの振分けを実行することにより、適切なサーバ負荷分散制御が実現される。

なお、上述の例では、フロントサーバ１０２の負荷は、各エンドサーバ１０３のアプリケーション１１０毎のアクセス状況を反映した負荷状態のみを含む負荷として計算されている。これに対して更に、フロントサーバ１０２自身でのＣＰＵ／バッファ使用率の比率や、最大応答時間、最小応答時間や、他の情報値を併せて含むように負荷計算が行われてもよい。これにより、フロントサーバ１０２に接続される各エンドサーバ１０３のアプリケーション１１０毎のアクセス状況に加えて、そのフロントサーバ１０２自身の負荷状態も加味した負荷分散制御を実現することができる。フロントサーバ自身の負荷状態による負荷分散制御は従来技術に従う。

また、エンドサーバ１０３のアプリケーション１１０毎の負荷は、更に処理の信頼度を加え、
（エンドサーバのアプリケーションのコネクション数 × 平均応答時間 ）
× ｛１/１−エラー発生率｝
などとして決定されてもよい。なお、平均応答時間及びエラー発生率は、サーバ統計情報３０１として取得された、フロントサーバ１０２からのアプリケーションパス管理情報１４０１中に含まれている。

ステップＳ１００４で計算された振分け比率は、図３の振分け情報３０２として、振分け処理部１０８に保持される。図１８は、振分け情報３０２のデータ構成例を示す図である。フロントサーバ１０２毎に、振分け比率が決定される。図１８において、「サーバ識別情報」「状態」「実行パス」「所在」及び「エンド状態」は、それぞれ図１７に示されるサーバ統計情報３０１内の「サーバ識別情報」「状態」「実行パス」「所在」及びフロントサーバ１０２から通知された統計情報の一部である「状態」から転記される。

以上のステップＳ１００２からＳ１００４までの一連の処理は、図２２から続く図２３又は図２４から続く図２５の動作シーケンス図において、Ｓ１００２，Ｓ１００３，Ｓ１００４として示される。

その後、図１０の振分け比率設定処理が終了する。
図１１は、サーバ負荷分散装置１０１内の振分け処理部１０８によって実行される振分け処理の詳細を示す動作フローチャートである。この処理は、図１のコネクション管理部１０７からの依頼に基づいて起動される。この処理では、前述したように、各エンドサーバ１０３及び各フロントサーバ１０２の負荷情報と、各フロントサーバ１０２の振分け情報に基づいて、各コネクション毎に、振分け対象のフロントサーバ１０２が決定される。

まず、振分け可能なフロントサーバ１０２が存在するか否かが判定される（ステップＳ１１０１）。
振分け可能なフロントサーバ１０２が存在しステップＳ１１０１の判定がＹＥＳならば、図３の振分け情報３０２とコネクション情報３０３からフロントサーバ１０２が選択され、その選択結果がコネクション確立・解放処理に通知される（ステップＳ１１０２）。この処理は、図２３から続く図２４の動作シーケンス図において、Ｓ１１０２として示される。例えば、図１８の振分け情報３０２のデータ構成例では、フロントサーバＡとフロントサーバＢの振り分け比率は、以下であった。
フロントサーバＡの振り分け比率＝０．４９
フロントサーバＢの振り分け比率＝０．５１

この結果、通常では、振分け比率の低いフロントサーバＡが振分け先として選択される。ただし、振分け比率が最小のフロントサーバ１０２であっても、コネクション情報３０３（図１９参照）を参照した結果、以下のような場合が発生し得る。即ち、そのフロントサーバ１０２に対するコネクションの合計値が、そのフロントサーバ１０２が処理可能なコネクション数を超えてしまうような場合がある。このような場合には、そのフロントサーバ１０２は選択されないように制御することができる。

振分け可能なフロントサーバ１０２が存在せずステップＳ１１０１の判定がＮＯならば、フロントサーバ１０２は選択されないため、振分け先なしとしてコネクション確立・解放処理に通知される。

図１２は、サーバ負荷分散装置１０１内のコネクション管理部１０７内の振分け処理部１０８によって実行されるコネクション確立・解放処理の詳細を示す動作フローチャートである。

まず、クライアント１０５からのリクエストがコネクション確立のリクエストであるか否かが判定される（ステップＳ１２０１）。
クライアント１０５からのリクエストがコネクション確立のリクエストでステップＳ１２０１の判定がＹＥＳならば、そのリクエストが振分け条件に一致する通信であるか否かが判定される（ステップＳ１２０２）。

リクエストが振分け条件に一致しない通信でステップＳ１２０２の判定がＮＯならば、クライアント１０５とのコネクションが切断される（ステップＳ１２０７）。
リクエストが振分け条件に一致する通信でステップＳ１２０２の判定がＹＥＳならば、振分け処理部１０８に振分け先となるフロントサーバ１０２の選択が依頼される（ステップＳ１２０３）。この処理は、図２３から続く図２４の動作シーケンス図において、Ｓ１２０３として示される。
この結果、振分け処理部１０８は、上述した図１１の振分け処理によって振分け先のフロントサーバ１０２を決定し、コネクション管理部１０７に通知する。この処理は、図２３から続く図２４の動作シーケンス図において、Ｓ１１０２として示される。

この通知を受けて、振分け先のフロントサーバ１０２が存在するか否かが判定される（ステップＳ１２０４）。
振分け先のフロントサーバ１０２が存在せずステップＳ１２０４の判定がＮＯならば、クライアント１０５とのコネクションが切断される（ステップＳ１２０７）。

振分け先のフロントサーバ１０２が存在しステップＳ１２０４の判定がＹＥＳならば、振分け先のフロントサーバ１０２との間でコネクションを確立する制御処理が実行される（ステップＳ１２０５）。この処理は、図２３から続く図２４の動作シーケンス図において、Ｓ１２０５として示される。

そして、図１９のデータ構成例を有する図３のコネクション情報３０３において、以下の更新が行われる。即ち、クライアント１０５からのリクエストにて指定されているＵＲＩに対応する実行パスと、振分け先のフロントサーバ１０２に対応するサーバ識別情報（ＩＰアドレス）とに対応するコネクション数が、カウントアップされる（ステップＳ１２０６）。このコネクション数は、ある時点でのサーバ負荷分散装置１０１とフロントサーバ１０２との間のコネクション数であるが、アプロケーション毎のコネクション数に分割され、フロントサーバ１０２とエンドサーバ１０３間に確立されている、ある時点でのアプリケーションのコネクション数となる。この処理は、図２３から続く図２４の動作シーケンス図において、Ｓ１２０６として示される。

クライアント１０５からのリクエストがコネクション確立のリクエストではなくステップＳ１２０１の判定がＮＯならば、クライアント１０５からのリクエストがコネクション解放のリクエストであるか否かが判定される（ステップＳ１２０８）。

クライアント１０５からのリクエストがコネクション解放のリクエストではなくステップＳ１２０８の判定がＮＯならば、何もせずに終了する。
クライアント１０５からのリクエストがコネクション解放のリクエストでステップＳ１２０８の判定がＹＥＳならば、振分け先のフロントサーバ１０２との間のコネクションが解放される（ステップＳ１２０９）この処理は、図２４から続く図２５の動作シーケンス図において、Ｓ１２０３として示される。

そして、図１９のデータ構成例を有する図３のコネクション情報３０３において、以下の更新が行われる。即ち、クライアント１０５からのリクエストにて指定されているＵＲＩに対応する実行パスと、今まで振り分けられていたフロントサーバ１０２に対応するサーバ識別情報（ＩＰアドレス）とに対応するコネクション数が、カウントダウンされる（ステップＳ１２０６）。

以上のステップＳ１２０９とＳ１２１０の処理は、図２４から続く図２５の動作シーケンス図において、Ｓ１２０９，Ｓ１２１０として示される。
以上の実施形態で、負荷計測エージェント１０９が収集する統計情報として、アプリケーションパス情報毎の応答時間に関する情報のほかに、アプリケーションパス情報毎のデータ量や、その他様々な統計情報を計測するような方式を実現することができる。

以上説明したように、本実施形態では、サーバ負荷分散装置によって振分け制御される各フロントサーバであるサーバ装置において、以下の動作が可能となる。即ち、自装置がアクセスするエンドサーバ上のアプリケーションプログラムを示すアプリケーションパス情報毎の稼働状態とリクエスト発行に関する統計情報を取得できる。そして、各エンドサーバの各アプリケーションプログラム毎の負荷状態を示す情報を取得することが可能となる。

そして、上述の各エンドサーバの各アプリケーションプログラム毎の負荷状態を示す情報を、サーバ負荷分散装置が各サーバ装置から収集し、さらに負荷分散装置とフロントサーバとのコネクション数、すなわちフロントサーバとエンドサーバは1対１の関係にあるから負荷分散装置とエンドサーバとのコネクション数を用いて、それらに基づいて各サーバ装置の振り分け比率を決定する。これにより、フロントサーバに接続される各エンドサーバのアプリケーションプログラム毎の負荷状態に沿った正確なサーバ負荷分散を実現でき、システム全体の負荷の最適化を容易に実現することが可能となる。

サーバ負荷分散装置がエンドサーバと直接に通信をできないような環境下においても、サーバ負荷分散装置は、各エンドサーバに対するアプリケーション毎のアクセス状況も含めた各フロントサーバの正確な負荷状態を収集することが可能となる。そして、それに基づいて最適な負荷分散制御が実現できる。
また、複数のサーバ負荷分散装置間で更に連携を取るような複雑な制御を行う必要もない。

図２６は、上述の各実施形態のシステムを実現できるコンピュータのハードウェア構成の一例を示す図である。
図２６に示されるコンピュータは、ＣＰＵ２６０１、メモリ２６０２、入出力装置２６０３、外部記憶装置２６０５、可搬記録媒体２６０９が挿入される可搬記録媒体駆動装置２６０６、及び通信インターフェース２６０７を有し、これらがバス２６０８によって相互に接続された構成を有する。

ＣＰＵ２６０１は、当該コンピュータ全体の制御を行う。メモリ２６０２は、プログラムの実行、データ更新等の際に、外部記憶装置２６０５（或いは可搬記録媒体２６０９）に記憶されているプログラム又はデータを一時的に格納するＲＡＭ等のメモリである。ＣＵＰ２６０１は、プログラムをメモリ２６０２に読み出して実行することにより、全体の制御を行う。

入出力装置２６０３は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をＣＰＵ２６０１に通知し、ＣＰＵ２６０１の制御によって送られてくるデータを表示装置や印刷装置に出力する。

外部記憶装置２６０５は、例えばハードディスク記憶装置である。可搬記録媒体駆動装置２６０６は、可搬記録媒体２６０９を収容するものである。通信インターフェース２６０７は、例えばＬＡＮ（ローカルエリアネットワーク）の通信回線を接続するための装置である。

実施形態によるシステムは、その機能を実現する各フローチャートに対応する各制御プログラムを、ＣＰＵ２６０１が実行することで実現される。そのプログラムは、例えば外部記憶装置２６０５や可搬記録媒体２６０９に記録され、或いは通信インターフェース２６０７によりネットワークから取得できるようにしてもよい。

上述の図２６のコンピュータは、図１のサーバ負荷分散装置１０１を、以下のようにして実現できる。即ち、図１に示される統計情報受信制御部１０６、コネクション管理部１０７、及び振分け処理部１０８を実現する図９〜図１２に示されるフローチャートに対応する機能を搭載したプログラムを、ＣＰＵ２６０１が実行することで実現できる。

図２６のコンピュータは、図１のフロントサーバ１０２を、以下のようにして実現できる。即ち、図１に示される負荷計測エージェント１０９を実現する図４〜図８に示されるフローチャートに対応する機能を搭載したプログラムを、ＣＰＵ２６０１が実行することで実現できる。

以上の実施形態に関して、更に以下の付記を開示する。
（付記１）
エンドサーバと通信を行いながら、サーバ負荷分散装置によって振り分けられるクライアントからのリクエストを処理するフロントサーバとして機能するサーバ装置において、
自装置がアクセスするエンドサーバ毎に前記各エンドサーバ上の負荷状態毎の識別情報を取得し、前記識別情報に基づいて前記負荷状態をエンドサーバ負荷状態の統計情報として計測する計測手段と、
前記エンドサーバ負荷状態の統計情報を、前記サーバ負荷分散装置に通知する通知手段と、
を具備することを特徴とするサーバ装置。
（付記２）
前記識別情報は、自装置がアクセスする前記エンドサーバ上のアプリケーションプログラムの設定場所を決定するアプリケーションパス情報である、
ことを特徴とする付記１記載のサーバ装置。
（付記３）
前記計測手段は、
自装置がアクセスする前記エンドサーバ上のアプリケーションプログラムの設定場所を前記エンドサーバにアクセスするプログラムの設定情報から解析して前記アプリケーションパス情報を取得するエンドサーバ取得統計情報解析処理部と、
前記アプリケーションパス情報に基づいて決定される前記エンドサーバの負荷状態をアプリケーションパス管理情報として取得するエンドサーバ統計情報取得処理部とからなり、
前記通知手段は、
前記アプリケーションパス管理情報を、前記サーバ負荷分散装置に通知する統計情報通知処理部からなる、
ことを特徴とする付記２記載のサーバ装置。
（付記４）
前記エンドサーバ取得統計情報解析処理部は、
自装置上での起動デーモンプログラムを調査することにより、前記エンドサーバにアクセスするプログラムを特定し、
前記プログラムに対する前記設定情報を調査することにより、前記エンドサーバ上のアプリケーションプログラムにアクセスする自装置上のプログラムが格納されているディレクトリを特定し、
前記ファイルがアクセスするエンドサーバ及びアプリケーションプログラムを特定し、
前記特定されたエンドサーバ及びアプリケーションプログラムを、前記アプリケーションパス情報として取得する、
ことを特徴とする付記３に記載のサーバ装置。
（付記５）
前記エンドサーバ取得統計情報解析処理部は、
ユーザが設定する設定情報に基づいて前記アプリケーションパス情報を取得する、
ことを特徴とする付記４に記載のサーバ装置。
（付記６）
前記エンドサーバ統計情報取得処理部は、
前記アプリケーションパス情報に基づいて決定される前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎に、前記組合せに対応するアプリケーションプログラムが動作しているか否かを定期的に検査し、
前記組合せに対応するアプリケーションプログラムの自装置上での負荷状態を判断するための統計情報を取得する、
ことを特徴とする付記３に記載のサーバ装置。
（付記７）
前記統計情報は、前記サーバ負荷分散装置から到達する前記アプリケーションプログラム向けの前記リクエストの要求数と、前記アプリケーションプログラムに発行された前記リクエストの応答時間の平均・最小・最大値と、前記アプリケーションプログラムに発行された前記リクエストのエラー発生回数及びエラー発生率を含む、
ことを特徴とする付記６に記載のサーバ装置。
（付記８）
前記統計情報通知処理部は、自装置の負荷状態をフロントサーバ負荷情報として更に前記サーバ負荷分散装置に通知し、
前記サーバ負荷分散装置は、前記アプリケーションパス管理情報及び前記フロントサーバ負荷情報に基づいて、複数の前記サーバ装置に対する前記リクエストの振り分け制御を実施する、
ことを特徴とする付記３に記載のサーバ装置。
（付記９）
前記エンドサーバの位置に、複数のエンドサーバに対して負荷分散制御を実施する仮想サーバ装置を配置する、
ことを特徴とする付記３に記載のサーバ装置。
（付記１０）
エンドサーバと通信を行いながらクライアントからのリクエストを処理するフロントサーバに対して、前記クライアントからのリクエストを振り分けるサーバ負荷分散装置において、
少なくとも一台の前記エンドサーバが接続されるべきフロントサーバを介して前記エンドサーバの負荷状態の統計情報を受信する受信手段と、
前記統計情報と前記フロントサーバへの前記リクエストのコネクション数とから算出される負荷情報に基づいて前記各フロントサーバの振り分け比率を計算し、前記フロントサーバへの前記リクエストの振分けを制御するフロントサーバ負荷分散手段と、
を具備するサーバ負荷分散装置。
（付記１１）
前記統計情報は前記エンドサーバ上の負荷状態の識別情報に基づいて前記フロントサーバが取得し、
前記コネクション数は自装置と前記フロントサーバとの間の前記エンドサーバ上の負荷状態語とのコネクション数である、
ことを特徴とする付記１０記載のサーバ負荷分散装置。
（付記１２）
前記受信手段は、
前記各フロントサーバから、前記エンドサーバ及び前記エンドサーバが実行するアプリケーションプログラムの組合せ毎に前記組合せに対応する負荷状態を示すアプリケーションパス管理情報を受信し、サーバ統計情報として管理する統計情報受信処理部からなり、
前記負荷分散手段は、
前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を含むコネクション情報と、前記アプリケーションパス管理情報とに基づいて、前記各フロントサーバへのリクエストの振分け比率を示す振分け情報を算出する振分け比率設定処理部と、
前記クライアントからのリクエストに基づくコネクションの設定時に、前記振分け情報に基づいて振分け先のフロントサーバを決定する振分け処理部と、
前記クライアントからのリクエストに基づいて、前記振分け処理部によって決定される振分け先のフロントサーバとの間で、コネクションの確立及び解放を行うと共に、前記コネクションに対応する前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を前記コネクション情報上で更新するコネクション管理部と、
を具備することを特徴とする付記１０記載のサーバ負荷分散装置。
（付記１３）
前記統計情報受信処理部は、
前記各フロントサーバから、前記エンドサーバの負荷状態とこれに基づく前記各フロントサーバの負荷状態を示すフロントサーバ負荷情報を受信し、
前記振分け比率設定処理部は、前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を含むコネクション情報と、前記アプリケーションパス管理情報と、前記フロントサーバ負荷情報とに基づいて、前記各フロントサーバへのリクエストの振分け比率を示す振分け情報を算出する、
ことを特徴とする付記１２に記載のサーバ負荷分散装置。
（付記１４）
エンドサーバにて実行されているアプリケーションプログラムと通信を行いながらクライアントからのリクエストを処理するフロントサーバに対して、サーバ負荷分散装置が前記クライアントからのリクエストを振り分けるサーバ負荷分散システムにおいて、
前記フロントサーバは、
自装置がアクセスするエンドサーバ毎に前記各エンドサーバ上の負荷状態を取得し、前記負荷状態をエンドサーバ負荷状態の統計情報として計測する計測手段と、
前記エンドサーバ負荷状態の統計情報を、前記サーバ負荷分散装置に通知する通知手段と、
を具備し、
前記サーバ負荷分散装置は、
少なくとも一台の前記エンドサーバが接続されるべき前記フロントサーバを介して前記エンドサーバの負荷状態の統計情報を受信する受信手段と、
前記統計情報を含む計測情報に基づいて前記各フロントサーバの振り分け比率を計算し、前記フロントサーバへの前記リクエストの振分けを制御するフロントサーバ負荷分散手段と、
を具備することを特徴とするサーバ負荷分散システム。
（付記１５）
エンドサーバと通信を行いながら、サーバ負荷分散装置によって振り分けられるクライアントからのリクエストを処理するフロントサーバとして機能するサーバ装置に、
自装置がアクセスするエンドサーバ毎に前記各エンドサーバ上の負荷状態毎の識別情報を取得し、前記識別情報に基づいて前記負荷状態をエンドサーバ負荷状態の統計情報として計測する計測機能と、
前記エンドサーバ負荷状態の統計情報を、前記サーバ負荷分散装置に通知する通知機能と、
を実行させるためのプログラム。
（付記１６）
前記識別情報は、自装置がアクセスする前記エンドサーバ上のアプリケーションプログラムの設定場所を決定するアプリケーションパス情報である、
ことを特徴とする付記１５記載のプログラム。
（付記１７）
前記計測機能は、
自装置がアクセスする前記エンドサーバ上のアプリケーションプログラムの設定場所を前記エンドサーバにアクセスするプログラムの設定情報から解析して前記アプリケーションパス情報を取得するエンドサーバ取得統計情報解析処理機能と、
前記アプリケーションパス情報に基づいて決定される前記エンドサーバの負荷状態をアプリケーションパス管理情報として取得するエンドサーバ統計情報取得処理機能とからなり、
前記通知機能は、
前記アプリケーションパス管理情報を、前記サーバ負荷分散装置に通知する統計情報通知処理機能からなる、
ことを特徴とする付記１６記載のプログラム。
（付記１８）
前記エンドサーバ取得統計情報解析処理機能は、
自装置上での起動デーモンプログラムを調査することにより、前記エンドサーバにアクセスするプログラムを特定し、
前記プログラムに対する前記設定情報を調査することにより、前記エンドサーバ上のアプリケーションプログラムにアクセスする自装置上のプログラムが格納されているディレクトリを特定し、
前記ファイルがアクセスするエンドサーバ及びアプリケーションプログラムを特定し、
前記特定されたエンドサーバ及びアプリケーションプログラムを、前記アプリケーションパス情報として取得する、
ことを特徴とする付記１７に記載のプログラム。
（付記１９）
前記エンドサーバ取得統計情報解析処理機能は、
ユーザが設定する設定情報に基づいて前記アプリケーションパス情報を取得する、
ことを特徴とする付記１８に記載のプログラム。
（付記２０）
前記エンドサーバ統計情報取得処理機能は、
前記アプリケーションパス情報に基づいて決定される前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎に、前記組合せに対応するアプリケーションプログラムが動作しているか否かを定期的に検査し、
前記組合せに対応するアプリケーションプログラムの自装置上での負荷状態を判断するための統計情報を取得する、
ことを特徴とする付記１７に記載のプログラム。
（付記２１）
前記統計情報は、前記サーバ負荷分散装置から到達する前記アプリケーションプログラム向けの前記リクエストの要求数と、前記アプリケーションプログラムに発行された前記リクエストの応答時間の平均・最小・最大値と、前記アプリケーションプログラムに発行された前記リクエストのエラー発生回数及びエラー発生率を含む、
ことを特徴とする付記２０に記載のプログラム。
（付記２２）
前記統計情報通知処理機能は、前記エンドサーバの負荷状態をフロントサーバ負荷情報として更に前記サーバ負荷分散装置に通知し、
前記サーバ負荷分散装置は、前記アプリケーションパス管理情報及び前記フロントサーバ負荷情報に基づいて、複数の前記サーバ装置に対する前記リクエストの振り分け制御を実施する、
ことを特徴とする付記１７に記載のプログラム。
（付記２３）
前記エンドサーバの位置に、複数のエンドサーバに対して負荷分散制御を実施する仮想サーバ装置を配置する、
ことを特徴とする付記１７に記載のプログラム。
（付記２４）
エンドサーバと通信を行いながらクライアントからのリクエストを処理するフロントサーバに対して、前記クライアントからのリクエストを振り分けるサーバ負荷分散装置に、
少なくとも一台の前記エンドサーバが接続されるべきフロントサーバを介して前記エンドサーバの負荷状態の統計情報を受信する受信機能と、
前記統計情報と前記フロントサーバへの前記リクエストのコネクション数とから算出される負荷情報に基づいて前記各フロントサーバの振り分け比率を計算し、前記フロントサーバへの前記リクエストの振分けを制御するフロントサーバ負荷分散機能と、
を実行させるためのプログラム。
（付記２５）
前記統計情報は前記エンドサーバ上の負荷状態の識別情報に基づいて前記フロントサーバが取得し、
前記コネクション数は自装置と前記フロントサーバとの間の前記エンドサーバ上の負荷状態語とのコネクション数である、
ことを特徴とする付記２４記載のプログラム。
（付記２６）
前記受信機能は、
前記各フロントサーバから、前記エンドサーバ及び前記エンドサーバが実行するアプリケーションプログラムの組合せ毎に前記組合せに対応する負荷状態を示すアプリケーションパス管理情報を受信し、サーバ統計情報として管理する統計情報受信処理機能からなり、
前記負荷分散機能は、
前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を含むコネクション情報と、前記アプリケーションパス管理情報とに基づいて、前記各フロントサーバへのリクエストの振分け比率を示す振分け情報を算出する振分け比率設定処理機能と、
前記クライアントからのリクエストに基づくコネクションの設定時に、前記振分け情報に基づいて振分け先のフロントサーバを決定する振分け処理機能と、
前記クライアントからのリクエストに基づいて、前記振分け処理機能によって決定される振分け先のフロントサーバとの間で、コネクションの確立及び解放を行うと共に、前記コネクションに対応する前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を前記コネクション情報上で更新するコネクション管理機能と、
を具備することを特徴とする付記２４記載のプログラム。
（付記２７）
前記統計情報受信処理機能は、
前記各フロントサーバから、前記エンドサーバの負荷状態とこれに基づく前記各フロントサーバの負荷状態を示すフロントサーバ負荷情報を受信し、
前記振分け比率設定処理機能は、前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を含むコネクション情報と、前記アプリケーションパス管理情報と、前記フロントサーバ負荷情報とに基づいて、前記各フロントサーバへのリクエストの振分け比率を示す振分け情報を算出する、
ことを特徴とする付記２６に記載のプログラム。
（付記２８）
コンピュータがエンドサーバと通信を行いながら、サーバ負荷分散装置によって振り分けられるクライアントからのリクエストを処理するフロントサーバとして機能するサーバ装置を制御する方法において、
自装置がアクセスするエンドサーバ毎に前記各エンドサーバ上の負荷状態毎の識別情報を取得し、前記識別情報に基づいて前記負荷状態をエンドサーバ負荷状態の統計情報として計測し、
前記エンドサーバ負荷状態の統計情報を、前記サーバ負荷分散装置に通知する、
ことを特徴とするサーバ負荷分散方法。
（付記２９）
前記識別情報は、自装置がアクセスする前記エンドサーバ上のアプリケーションプログラムの設定場所を決定するアプリケーションパス情報である、
ことを特徴とする付記２８記載のサーバ負荷分散方法。
（付記３０）
前記エンドサーバ負荷状態の統計情報の計測において、自装置がアクセスする前記エンドサーバ上のアプリケーションプログラムの設定場所を前記エンドサーバにアクセスするプログラムの設定情報から解析して前記アプリケーションパス情報を取得し、前記アプリケーションパス情報に基づいて決定される前記エンドサーバの負荷状態をアプリケーションパス管理情報として取得し、
前記エンドサーバ負荷状態の統計情報の前記サーバ負荷分散装置への通知において、前記アプリケーションパス管理情報を、前記サーバ負荷分散装置に通知する、
ことを特徴とする付記２９記載のサーバ負荷分散方法。
（付記３１）
前記アプリケーションパス情報の取得において、自装置上での起動デーモンプログラムを調査することにより、前記エンドサーバにアクセスするプログラムを特定し、前記プログラムに対する前記設定情報を調査することにより、前記エンドサーバ上のアプリケーションプログラムにアクセスする自装置上のプログラムが格納されているディレクトリを特定し、前記ファイルがアクセスするエンドサーバ及びアプリケーションプログラムを特定し、前記特定されたエンドサーバ及びアプリケーションプログラムを、前記アプリケーションパス情報として取得する、
ことを特徴とする付記３０に記載のサーバ負荷分散方法。
（付記３２）
前記アプリケーションパス情報の取得において、ユーザが設定する設定情報に基づいて前記アプリケーションパス情報を取得する、
ことを特徴とする付記３１に記載のサーバ負荷分散方法。
（付記３３）
前記アプリケーションパス管理情報の取得において、前記アプリケーションパス情報に基づいて決定される前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎に、前記組合せに対応するアプリケーションプログラムが動作しているか否かを定期的に検査し、前記組合せに対応するアプリケーションプログラムの自装置上での負荷状態を判断するための統計情報を取得する、
ことを特徴とする付記３０に記載のサーバ負荷分散方法。
（付記３４）
前記統計情報は、前記サーバ負荷分散装置から到達する前記アプリケーションプログラム向けの前記リクエストの要求数と、前記アプリケーションプログラムに発行された前記リクエストの応答時間の平均・最小・最大値と、前記アプリケーションプログラムに発行された前記リクエストのエラー発生回数及びエラー発生率を含む、
ことを特徴とする付記３３に記載のサーバ負荷分散方法。
（付記３５）
前記アプリケーションパス管理情報の前記サーバ負荷分散装置への通知において、前記エンドサーバの負荷状態をフロントサーバ負荷情報として更に前記サーバ負荷分散装置に通知し、
前記サーバ負荷分散装置は、前記アプリケーションパス管理情報及び前記フロントサーバ負荷情報に基づいて、複数の前記サーバ装置に対する前記リクエストの振り分け制御を実施する、
ことを特徴とする付記３０に記載のサーバ負荷分散方法。
（付記３６）
前記エンドサーバの位置に、複数のエンドサーバに対して負荷分散制御を実施する仮想サーバ装置を配置する、
ことを特徴とする付記３０に記載のサーバ負荷分散方法。
（付記３７）
コンピュータがエンドサーバと通信を行いながらクライアントからのリクエストを処理するフロントサーバに対して、前記クライアントからのリクエストを振り分けるサーバ負荷分散方法において、
少なくとも一台の前記エンドサーバが接続されるべきフロントサーバを介して前記エンドサーバの負荷状態の統計情報を受信し、
前記統計情報と前記フロントサーバへの前記リクエストのコネクション数とから算出される負荷情報に基づいて前記各フロントサーバの振り分け比率を計算し、
前記フロントサーバへの前記リクエストの振分けを制御する、
ことを特徴とするサーバ負荷分散方法。
（付記３８）
前記統計情報は前記エンドサーバ上の負荷状態の識別情報に基づいて前記フロントサーバが取得し、
前記コネクション数は自装置と前記フロントサーバとの間の前記エンドサーバ上の負荷状態語とのコネクション数である、
ことを特徴とする付記３７記載のサーバ負荷分散方法。
（付記３９）
前記エンドサーバの負荷状態の統計情報の受信において、前記各フロントサーバから、前記エンドサーバ及び前記エンドサーバが実行するアプリケーションプログラムの組合せ毎に前記組合せに対応する負荷状態を示すアプリケーションパス管理情報を受信し、サーバ統計情報として管理し、
前記フロントサーバへの前記リクエストの振分けの制御において、前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を含むコネクション情報と、前記アプリケーションパス管理情報とに基づいて、前記各フロントサーバへのリクエストの振分け比率を示す振分け情報を算出し、前記クライアントからのリクエストに基づくコネクションの設定時に、前記振分け情報に基づいて振分け先のフロントサーバを決定し、前記クライアントからのリクエストに基づいて、前記振分け処理機能によって決定される振分け先のフロントサーバとの間で、コネクションの確立及び解放を行うと共に、前記コネクションに対応する前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を前記コネクション情報上で更新する、
ことを特徴とする付記３７記載のサーバ負荷分散方法。
（付記４０）
前記アプリケーションパス管理情報の受信において、前記各フロントサーバから、前記エンドサーバの負荷状態とこれに基づく前記各フロントサーバの負荷状態を示すフロントサーバ負荷情報を受信し、
前記振分け情報の算出において、前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を含むコネクション情報と、前記アプリケーションパス管理情報と、前記フロントサーバ負荷情報とに基づいて、前記各フロントサーバへのリクエストの振分け比率を示す振分け情報を算出する、
ことを特徴とする付記３９に記載のサーバ負荷分散方法。
（付記４１）
コンピュータがエンドサーバにて実行されているアプリケーションプログラムと通信を行いながらクライアントからのリクエストを処理するフロントサーバに対して、サーバ負荷分散装置が前記クライアントからのリクエストを振り分けるサーバ負荷分散方法において、
前記フロントサーバにおいて、
自装置がアクセスするエンドサーバ毎に前記各エンドサーバ上の負荷状態を取得し、前記負荷状態をエンドサーバ負荷状態の統計情報として計測し、
前記エンドサーバ負荷状態の統計情報を、前記サーバ負荷分散装置に通知し、
前記サーバ負荷分散装置において、
少なくとも一台の前記エンドサーバが接続されるべき前記フロントサーバを介して前記エンドサーバの負荷状態の統計情報を受信し、
前記統計情報を含む計測情報に基づいて前記各フロントサーバの振り分け比率を計算し、
前記フロントサーバへの前記リクエストの振分けを制御する、
ことを特徴とするサーバ負荷分散方法。

１０１ サーバ負荷分散装置
１０２ フロントサーバ
１０３ エンドサーバ
１０４ 仮想サーバ
１０５ クライアント
１０６ 統計情報受信制御部
１０７ コネクション管理部
１０８ 振分け処理部
１０９ 負荷計測エージェント
１１０ アプリケーション
１１１、１１２、１１３ ＬＡＮ
１１４ インターネット１１４
３０１ サーバ統計情報
３０２ 振分け情報
３０３ コネクション情報
１４０１ アプリケーションパス管理情報

Claims (8)

1. エンドサーバと通信を行いながら、サーバ負荷分散装置によって振り分けられるクライアントからのリクエストを処理するフロントサーバとして機能するサーバ装置において、
   自装置がアクセスするエンドサーバ毎に前記各エンドサーバ上の負荷状態毎の識別情報を取得し、前記識別情報に基づいて前記負荷状態をエンドサーバ負荷状態の統計情報として計測する計測手段と、
   前記エンドサーバ負荷状態の統計情報を、前記サーバ負荷分散装置に通知する通知手段と、
   を具備することを特徴とするサーバ装置。
2. 前記識別情報は、自装置がアクセスする前記エンドサーバ上のアプリケーションプログラムの設定場所を決定するアプリケーションパス情報である、
   ことを特徴とする請求項１記載のサーバ装置。
3. 前記計測手段は、
   自装置がアクセスする前記エンドサーバ上のアプリケーションプログラムの設定場所を前記エンドサーバにアクセスするプログラムの設定情報から解析して前記アプリケーションパス情報を取得するエンドサーバ取得統計情報解析処理部と、
   前記アプリケーションパス情報に基づいて決定される前記エンドサーバの負荷状態をアプリケーションパス管理情報として取得するエンドサーバ統計情報取得処理部とからなり、
   前記通知手段は、
   前記アプリケーションパス管理情報を、前記サーバ負荷分散装置に通知する統計情報通知処理部からなる、
   ことを特徴とする請求項２記載のサーバ装置。
4. 前記エンドサーバ取得統計情報解析処理部は、
   自装置上での起動デーモンプログラムを調査することにより、前記エンドサーバにアクセスするプログラムを特定し、
   前記プログラムに対する前記設定情報を調査することにより、前記エンドサーバ上のアプリケーションプログラムにアクセスする自装置上のプログラムが格納されているディレクトリを特定し、
   前記ファイルがアクセスするエンドサーバ及びアプリケーションプログラムを特定し、
   前記特定されたエンドサーバ及びアプリケーションプログラムを、前記アプリケーションパス情報として取得する、
   ことを特徴とする請求項３に記載のサーバ装置。
5. エンドサーバと通信を行いながらクライアントからのリクエストを処理するフロントサーバに対して、前記クライアントからのリクエストを振り分けるサーバ負荷分散装置において、
   少なくとも一台の前記エンドサーバが接続されるべきフロントサーバを介して前記エンドサーバの負荷状態の統計情報を受信する受信手段と、
   前記統計情報と前記フロントサーバへの前記リクエストのコネクション数とから算出される負荷情報に基づいて前記各フロントサーバの振り分け比率を計算し、前記フロントサーバへの前記リクエストの振分けを制御するフロントサーバ負荷分散手段と、
   を具備するサーバ負荷分散装置。
6. 前記受信手段は、
   前記各フロントサーバから、前記エンドサーバ及び前記エンドサーバが実行するアプリケーションプログラムの組合せ毎に前記組合せに対応する負荷状態を示すアプリケーションパス管理情報を受信し、サーバ統計情報として管理する統計情報受信処理部からなり、
   前記負荷分散手段は、
   前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を含むコネクション情報と、前記アプリケーションパス管理情報とに基づいて、前記各フロントサーバへのリクエストの振分け比率を示す振分け情報を算出する振分け比率設定処理部と、
   前記クライアントからのリクエストに基づくコネクションの設定時に、前記振分け情報に基づいて振分け先のフロントサーバを決定する振分け処理部と、
   前記クライアントからのリクエストに基づいて、前記振分け処理部によって決定される振分け先のフロントサーバとの間で、コネクションの確立及び解放を行うと共に、前記コネクションに対応する前記エンドサーバ及び前記アプリケーションプログラムの組合せ毎のコネクション数を前記コネクション情報上で更新するコネクション管理部と、
   を具備することを特徴とする請求項１０記載のサーバ負荷分散装置。
7. エンドサーバと通信を行いながら、サーバ負荷分散装置によって振り分けられるクライアントからのリクエストを処理するフロントサーバとして機能するサーバ装置に、
   自装置がアクセスするエンドサーバ毎に前記各エンドサーバ上の負荷状態毎の識別情報を取得し、前記識別情報に基づいて前記負荷状態をエンドサーバ負荷状態の統計情報として計測する計測機能と、
   前記エンドサーバ負荷状態の統計情報を、前記サーバ負荷分散装置に通知する通知機能と、
   を実行させるためのプログラム。
8. コンピュータがエンドサーバにて実行されているアプリケーションプログラムと通信を行いながらクライアントからのリクエストを処理するフロントサーバに対して、サーバ負荷分散装置が前記クライアントからのリクエストを振り分けるサーバ負荷分散方法において、
   前記フロントサーバにおいて、
   自装置がアクセスするエンドサーバ毎に前記各エンドサーバ上の負荷状態を取得し、前記負荷状態をエンドサーバ負荷状態の統計情報として計測し、
   前記エンドサーバ負荷状態の統計情報を、前記サーバ負荷分散装置に通知し、
   前記サーバ負荷分散装置において、
   少なくとも一台の前記エンドサーバが接続されるべき前記フロントサーバを介して前記エンドサーバの負荷状態の統計情報を受信し、
   前記統計情報を含む計測情報に基づいて前記各フロントサーバの振り分け比率を計算し、
   前記フロントサーバへの前記リクエストの振分けを制御する、
   ことを特徴とするサーバ負荷分散方法。