JP2003208414A - 負荷分散機能付きサーバおよびクライアント - Google Patents

Abstract

(57)【要約】 【課題】負荷分散処理システムにおいて、負荷分散先の
選出を行うプロキシサーバの過負荷状態や、処理待機時
間を基に負荷分散先サーバの選出を行うことによる不適
切な負荷分散先の選出を防止する。 【解決手段】サーバ２は、自身を含むネットワーク内の
全てのサーバ２について、処理を委託した際の内容（具
体的には、該サーバに委託した処理ごとに、該処理の実
行日時、該処理の処理時間、該処理に関するデータ量、
および、該処理時のデータ転送時間）を履歴３として保
持するようにし、クライアント１から処理要求があった
場合に、保持している履歴３を参照して、該処理の実行
に要するであろう時間が短いサーバ２を推測し、そのよ
うなサーバ２を負荷分散先サーバ２として選出し、選出
したサーバ２に処理の実行を委託する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のサーバが接
続されたネットワークで、サーバでの処理をネットワー
ク内の他のサーバに負荷分散できるような負荷分散処理
システムに関するものである。

【０００２】

【従来の技術】複数のサーバが存在するネットワークに
おいて、クライアントからサーバへの処理要求を、各サ
ーバの負荷状況に応じて負荷分散を行う場合、従来は、
プロキシサーバが負荷分散先となるサーバを選出するよ
うになっていた。

【０００３】具体的には、従来の負荷分散処理システム
においては、図２に示すように、クライアントＡ（１−
ａ）、クライアントＢ（１−ｂ）、クライアントＣ（１
−ｃ）と、サーバＡ（２−ａ）、サーバＢ（２−ｂ）、
サーバＣ（２−ｃ）との間に、各サーバ２の負荷分散状
態を監視するプロキシサーバ４を用意し、このプロキシ
サーバ４が、クライアント１からサーバ２への処理要求
があった場合に、負荷分散先となるサーバ２を選出し、
選出したサーバ２に処理要求を行うようになっていた。

【０００４】そして、プロキシサーバ４は、各サーバ２
のＣＰＵ使用率やメモリ使用量から処理の待機時間を算
出し、算出した処理の待機時間を基に各サーバ２の負荷
状況を把握し、負荷状況の小さいサーバ２を、負荷分散
先として選出するようになっていた。

【０００５】

【発明が解決しようとする課題】図２を用いて説明した
ように、従来の負荷分散処理システムにおいては、各サ
ーバ２の負荷分散状態を監視するプロキシサーバ４が、
クライアント１からサーバ２への処理要求を受けたとき
に、負荷状況の小さいサーバ２を選出し、選出したサー
バ２に処理要求を行うのが一般的であった。

【０００６】しかし、図３に示すように、クライアント
１の数が増加すると、負荷分散先選出するプロキシサー
バ４へのクライアント１からの処理要求が集中してしま
うので、プロキシサーバ４の処理が負荷分散処理システ
ム全体のボトルネックとなってしまうという問題があっ
た。

【０００７】また、図２を用いて説明したように、従来
の負荷分散処理システムにおいては、プロキシサーバ４
が、負荷分散先となるサーバ２の選出を行う際には、各
サーバ２のＣＰＵ使用率やメモリ使用量から処理の待機
時間を算出し、算出した処理の待機時間を基に行うのが
一般的であった。

【０００８】しかし、実際には、プロキシサーバ４が負
荷分散先として選出したサーバ２に処理要求を行う際に
は、処理を実行する上で必要となるデータの転送も行わ
れることとなる。このため、処理を実行する上で必要と
なるデータのデータ量が大きいと、負荷分散を行うより
も、自身の処理系にて処理を行う方がかえって効率よく
処理できる場合が少なからずあった。

【０００９】そこで、本発明の目的は、負荷分散処理シ
ステムにおいて、負荷分散先の選出を行うプロキシサー
バの過負荷状態や、処理の待機時間を基に負荷分散先サ
ーバの選出を行うことによる不適切な負荷分散先の選出
を防止することにある。

【００１０】

【課題を解決するための手段】上記目的を達成するため
に、本発明は、負荷分散先の選出を行うプロキシサーバ
での処理が集中することを防ぐために、負荷分散先の選
出を、各サーバが行うようにしている。

【００１１】そして、各サーバは、自身を含むネットワ
ーク内の全てのサーバについて、処理を委託した際の内
容（具体的には、該サーバに委託した処理ごとに、該処
理の実行日時、該処理の処理時間、該処理に関するデー
タ量、および、該処理時のデータ転送時間）を履歴とし
て保持するようにし、上記ネットワークに接続されたク
ライアントから処理が要求された場合に、上記履歴情報
記憶手段が保持している履歴情報に基づいて、該処理の
実行に要するであろう時間が短いサーバを推測し、その
ようなサーバを負荷分散先サーバとして選出し、選出し
たサーバに処理の実行を委託するようにしている。

【００１２】

【発明の実施の形態】以下、本発明の実施の形態につい
て図面を参照して説明する。

【００１３】（第１の実施形態）図１は、第１の実施形
態に係る負荷分散処理システムの構成例を示す図であ
る。

【００１４】図１に示すように、第１の実施形態に係る
負荷分散処理システムは、ネットワークで接続されたサ
ーバＡ（２−ａ）、サーバＢ（２−ｂ）、サーバＣ（２
−ｃ）と、各サーバ２へ処理を要求するクライアント１
とを備えて構成される。なお、図１では、１つのクライ
アント１のみを記載しているが、実際には、２つ以上の
クライアント１が存在しているのが一般的である。

【００１５】各サーバ２は、履歴Ａ（３−ａ）、履歴Ｂ
（３−ｂ）、履歴Ｃ（３−ｃ）を保持し、これらの履歴
３には、以前に自サーバ２で処理を行った際の履歴内容
と、以前に他のサーバ２へ処理を委託した際の履歴内容
とが格納される。

【００１６】第１の実施形態においては、図１に示すよ
うに、クライアント１から処理要求を受けたサーバ（例
えば、サーバ２−ａ）が、自身の履歴Ａ（３−ａ）を参
照し、処理の実行に最適なサーバ（例えば、サーバＣ
（２−ｃ））を選出し、そのサーバＣ（３−ｃ）に処理
の委託を行うようにするものである。

【００１７】以下、サーバＡ（２−ａ）が、クライアン
ト１から処理要求を受けた場合の動作について説明す
る。

【００１８】ここで、各サーバ２の特徴として、 サーバＡ（２−ａ）…処理の待機時間長い、処理速度普
通 サーバＢ（２−ｂ）…処理の待機時間短い、処理速度速
い、サーバＡ（２−ａ）との間のデータ転送時間普通 サーバＣ（２−ｃ）…処理の待機時間短い、処理速度遅
い、サーバＡ（２−ａ）との間のデータ転送時間短い という特徴があるものとし、また、クライアント１から
サーバＡ（２−ａ）が処理要求を受けた時刻を、８月８
日００時００分００秒であるものとする。

【００１９】図４〜図６に、サーバＡ（２−ａ）が保持
する履歴Ａ（３−ａ）の内容を示す。図４は、サーバＡ
（２−ａ）自身についての履歴内容を示し、図５はサー
バＢ（２−ｂ）についての履歴内容を示し、図６はサー
バＣ（２−ｃ）についての履歴内容を示している。

【００２０】図４に示すように、サーバＡ（２−ａ）
は、自サーバＡ（２−ａ）についての履歴内容として、 時間Ａ…処理が実行され、処理結果を得るまでにかかっ
た時間 時間Ｂ…処理が実行されていた時間 時間Ｃ…処理の待機時間 時間Ｄ…委託先に転送するデータのデータ転送時間 時間Ｅ…委託先から委託元に転送されるデータのデータ
転送時間 データ量Ａ…処理の実行に必要なデータのデータ量 データ量Ｂ…処理完了後に生成されるデータのデータ量 を保持している。

【００２１】また、図５および図６に示すように、サー
バＡ（２−ａ）は、サーバＢ（２−ｂ）およびサーバＣ
（２−ｃ）についての履歴内容として、 時間Ａ…他サーバへ処理を委託して処理が実行され、処
理結果を受け取るまでにかかった時間 時間Ｂ…委託先で実際に処理が実行されていた時間 時間Ｃ…委託先での処理の待機時間 時間Ｄ…委託先に転送するデータのデータ転送時間 時間Ｅ…委託先から委託元に転送されるデータのデータ
転送時間 データ量Ａ…委託先に転送するデータのデータ量 データ量Ｂ…委託先から委託元に転送されるデータのデ
ータ量 を保持している。

【００２２】ここで、履歴内容の導出方法について、ク
ライアント１からサーバＡ（２−ａ）が処理要求を受
け、サーバＡ（２−ａ）がサーバＢ（２−ｂ）へ処理を
委託した場合に、サーバＡ（２−ａ）に保持される履歴
内容を例にして、図７を用いて説明する。

【００２３】図７に示すように、サーバＡ（２−ａ）
は、まず、クライアント１から処理要求があった際に、
そのときの時刻ａ１を保持し、続いて、サーバB（２−
b）に処理を委託する際に、そのときの時刻ａ２を保持
すると共に、処理の実行に必要なデータのデータ量、す
なわち、サーバＢ（２−ｂ）への転送データ量Ａ１を保
持する。

【００２４】サーバＢ（２−ｂ）は、サーバＡ（２−
ａ）から処理が委託された際に、そのときの時刻ｂ１を
保持し、続いて、処理を実行する際に、処理開始時の時
刻ｂ２および処理終了時の時刻ｂ３を保持する。そし
て、サーバＢ（２−ｂ）は、委託された処理を終える
と、処理結果、すなわち、処理完了後に生成されたデー
タを、サーバＡ（２−ａ）に返送するが、その際に、そ
のときの時刻ｂ４を保持すると共に、処理完了後に生成
されたデータのデータ量、すなわち、サーバＡ（２−
ａ）への転送データ量Ｂ１を保持する。ここで、処理結
果の返送時には、パラメータとして、サーバＢ（２−
ｂ）からサーバＡ（２−ａ）に対して、時刻ｂ１、時刻
ｂ２、時刻ｂ３、時刻ｂ４、データ量Ｂ１も送信され
る。

【００２５】サーバＡ（２−ａ）は、サーバＢ（２−
ｂ）から処理結果を受信すると、そのときの時刻ａ３を
保持する。

【００２６】このようにして、保持・取得した時刻か
ら、サーバＡ（２−ａ）は、 時間Ａ＝時刻ａ３−時刻ａ２ 時間Ｂ＝時刻ｂ３−時刻ｂ２ 時間Ｃ＝時刻ｂ２−時刻ｂ１ 時間Ｄ＝時刻ｂ１−時刻ａ２ 時間Ｅ＝時刻ａ３−時刻ｂ４ データ量Ａ＝データ量Ａ１ データ量Ｂ＝データ量Ｂ１ を求め、サーバＢ（２−ｂ）についての履歴内容に格納
することができる。

【００２７】なお、サーバＡ（２−ａ）とサーバＢ（２
−ｂ）との間で時刻が一致していることが前提なのは言
うまでもない。また、サーバＡ（２−ａ）が最初に保持
する時刻ａ１は、自身で処理を実行するときに、時刻ｂ
１と同様に扱われるものである。

【００２８】さて、第１の実施形態において、サーバＡ
（２−ａ）は、クライアント１から処理要求を受けた場
合に、自身を含めた全てのサーバ２のうちから、クライ
アント１から要求された処理の実行に要するであろう時
間が短いサーバ２を推測し、そのようなサーバ２を委託
先サーバ２として選出し、委託先サーバ２に処理を委託
するようにする。

【００２９】この推測は、クライアント１から受けた処
理要求のデータ量と、履歴Ａ（３−ａ）の内容とに基づ
いて、後述する関数ｆ（Ｘ）の値を算出することで行わ
れる。

【００３０】すなわち、サーバＡ（２−ａ）は、まず、
関数ｆ（Ｘ）で用いられる係数の設定を行う。ここで、
関数ｆ（Ｘ）の係数設定について説明する。

【００３１】サーバＡ（２−ａ）は、履歴Ａ（３−ａ）
の内容に基づいて、係数ａi、係数ｂi、係数ｃi、係数
ｄi、係数ｅiを求める。 ａi＝時間Ｄ／データ量Ａ ｂi＝時間Ｅ／データ量Ｂ ｃi＝時間Ｂ／データ量Ａ ｄi＝時間Ｃ ｅi＝データ量Ｂ／データ量Ａ

【００３２】続いて、サーバＡ（２−ａ）は、履歴Ａ
（３−ａ）中の日時を参照し、委託先サーバ２の選出を
行う日時に近いレコード（履歴Ａ（３−ａ）中のＮｏ．
単位のデータ）ほど、委託先選出のレコードとして有用
なものと捉え、履歴Ａ（３−ａ）中の各レコードについ
て重み付けを行う。

【００３３】第１の実施形態では、例えば、 重要度１…１時間以内の履歴 重要度２…１日以内の履歴 重要度３…３日以内の履歴 重要度４…３日を超える履歴 という４つの重要度を設け、数字が小さいものほど、重
要度が高いものとする。

【００３４】そして、サーバＡ（２−ａ）は、図８に示
すように、これらの重要度と、先に求めた係数ａi、係
数ｂi、係数ｃi、係数ｄi、係数ｅiとを用いて、係数
Ａ、係数Ｂ、係数Ｃ、係数Ｄ、係数Ｅを求める。

【００３５】そして、サーバＡ（２−ａ）は、クライア
ント１から受けた処理に必要なデータのデータ量を変数
Ｘ（ｋＢｙｔｅ）として、この変数Ｘと、図８に示すよ
うにして求めた係数Ａ、係数Ｂ、係数Ｃ、係数Ｄ、係数
Ｅとから、以下に示す関数ｆ（Ｘ）を計算する。

【００３６】 ｆ（Ｘ）＝（Ａ＋Ｃ）×Ｘ＋Ｂ×Ｅ×Ｘ＋Ｄ なお、ｆ（Ｘ）値を求める計算は、履歴Ａ（３−ａ）中
の全てのレコードごとに行われる。

【００３７】ｆ（Ｘ）値は、処理の実行に要するであろ
う時間の目安となるので、サーバＡ（２−ａ）は、この
ｆ（Ｘ）値が小さいレコードに対応するサーバ２を委託
先サーバ２として選出するようにする。

【００３８】図９は、Ｘの値と各サーバ２のｆ（Ｘ）値
との関係を表したグラフである。

【００３９】このグラフから、クライアント１から受け
た処理に必要なデータのデータ量の大きさに応じて、委
託先サーバ２が、サーバＣ（２−ｃ）→サーバＢ（２−
ｂ）→サーバＡ（２−ａ）という順に選出されることが
わかる。

【００４０】なお、第１の実施形態において、関数ｆ
（Ｘ）や重み付けの方法は、一例であり、本発明の主旨
を損なわない限り、ユーザが自由に設定／変更できるも
のである。

【００４１】（第２の実施形態）

【００４２】さて、第１の実施形態では、委託先サーバ
２の選出を行う際に、履歴３中の日時に基づいて、履歴
３中の各レコードについて重み付けを行っているが、日
時だけではなく、履歴３中のデータ量Ａに基づいて重み
付けを行うようにしてもよい。

【００４３】以下、このようにする場合を、第２の実施
形態として説明する。

【００４４】第２の実施形態において、データ量Ａに基
づく重み付けは、クライアント１から受けた処理に必要
なデータのデータ量に近いレコードほど、委託先選出の
レコードとして有用なものと捉えることを意味してい
る。

【００４５】第２の実施形態では、例えば、 重要度１…１時間以内の履歴、かつ、データ量Ａとの差
が５０ｋＢｙｔｅ以内の履歴 重要度２…１日以内の履歴、かつ、データ量Ａとの差が
５０ｋＢｙｔｅ以内の履歴 重要度２…１時間以内の履歴、かつ、データ量Ａとの差
が５０ｋＢｙｔｅより大きく３００ｋＢｙｔｅ以内の履
歴 重要度３…３日以内の履歴、かつ、データ量Ａとの差が
５０ｋＢｙｔｅ以内の履歴 重要度３…１時間以内の履歴、かつ、データ量Ａとの差
が３００ｋＢｙｔｅより大きく１０００ｋＢｙｔｅ以内
の履歴 重要度４…１日以内の履歴、かつ、データ量Ａとの差が
５０ｋＢｙｔｅより大きく３００ｋＢｙｔｅ以内の履歴 重要度５…３日を超える履歴、かつ、データ量Ａとの差
が５０ｋＢｙｔｅ以内の履歴 重要度５…１時間以内の履歴、かつ、データ量Ａとの差
が１０００ｋＢｙｔｅより大きい履歴 重要度６…３日以内の履歴、かつ、データ量Ａとの差が
５０ｋＢｙｔｅより大きく３００ｋＢｙｔｅ以内の履歴 重要度６…１日以内の履歴、かつ、データ量Ａとの差が
３００ｋＢｙｔｅより大きく１０００ｋＢｙｔｅ以内の
履歴 重要度７…３日を超える履歴、かつ、データ量Ａとの差
が５０ｋＢｙｔｅより大きく３００ｋＢｙｔｅ以内の履
歴 重要度７…３日以内の履歴、かつ、データ量Ａとの差が
３００ｋＢｙｔｅより大きく１０００ｋＢｙｔｅ以内の
履歴 重要度７…１日以内の履歴、かつ、データ量Ａとの差が
１０００ｋＢｙｔｅより大きい履歴 重要度８…３日を超える履歴、かつ、データ量Ａとの差
が３００ｋＢｙｔｅより大きく１０００ｋＢｙｔｅ以内
の履歴 重要度８…３日以内の履歴、かつ、データ量Ａとの差が
１０００ｋＢｙｔｅより大きい履歴 重要度９…３日を超える履歴、かつ、データ量Ａとの差
が１０００ｋＢｙｔｅより大きい履歴 という９つの重要度を設け、重要度の数字が小さいもの
ほど、重要度が高いものとする。

【００４６】そして、係数ａi、係数ｂi、係数ｃi、係
数ｄi、係数ｅiを求める式、および、係数Ａ、係数Ｂ、
係数Ｃ、係数Ｄ、係数Ｅを求める式は、第１の実施形態
と同様であるが、Ｗ（ｘi）については、例えば、図１
０に示すようする。

【００４７】図１１は、Ｘの値と各サーバ２のｆ（Ｘ）
値との関係を表したグラフである。

【００４８】このグラフから、クライアント１から受け
た処理に必要なデータのデータ量の大きさに応じて、委
託先サーバ２が、サーバＣ（２−ｃ）→サーバＢ（２−
ｂ）→サーバＡ（２−ａ）という順に選出されることが
わかる。

【００４９】なお、第２の実施形態においても、第１の
実施形態と同様に、関数ｆ（Ｘ）や重み付けの方法は、
一例であり、本発明の主旨を損なわない限り、ユーザが
自由に設定／変更できるものである。

【００５０】ところで、第１の実施形態および第２の実
施形態のいずれにおいても、ｆ（Ｘ）値を算出したとこ
ろ、ｆ（Ｘ）値が小さいレコードが複数のサーバ２に対
応しており、いずれのサーバ２を委託先サーバ２として
選出しても、処理の実行に要するであろう時間に差がな
いと推測された場合は、履歴３の少ない（レコード数の
少ない）サーバ２を、委託先サーバ２として選出するよ
うにすることができる。このようにすれば、サーバ２が
保持する履歴３の充実化を図り、負荷分散システムの効
率を高めることが可能となる。

【００５１】また、第１の実施形態および第２の実施形
態のいずれにおいても、履歴３の内容に基づいて、委託
先サーバ２を選出するようにしているが、自サーバ２を
含む全てのサーバ２の負荷状態を収集し、収集した負荷
状態および履歴３に基づいて、委託先サーバ２を選出す
るようにしてもよい。

【００５２】また、第１の実施形態および第２の実施形
態のいずれにおいても、委託元サーバ２が、委託先サー
バ２を選出し、選出した委託先サーバ２に処理を委託し
た後、委託先サーバ２が、該処理に要するであろう時間
を見積もり、見積もり結果を委託元サーバ２に返答する
ようにしてもよい。このようにすれば、委託元サーバ２
は、返答された見積もり結果によっては、委託先サーバ
２の再選出を行うようにすることが可能となる。

【００５３】また、第１の実施形態および第２の実施形
態のいずれにおいても、例えば、図１２に示すように、
新規サーバＤ（２−ｄ）を追加する場合には、既存のサ
ーバＡ（２−ａ）の履歴Ａ（３−ａ）、サーバＢ（２−
Ｂ）の履歴Ｂ（３−ｂ）、サーバＣ（２−ｃ）の履歴Ｃ
（３−ｃ）の各々に、サーバＤ（２−ｄ）についての履
歴内容を追加すると共に、サーバＤ（２−ｄ）の履歴Ｄ
（３−ｄ）に、サーバＡ（２−ａ）についての履歴内
容、サーバＢ（２−Ｂ）についての履歴内容、サーバＣ
（２−ｃ）についての履歴内容、サーバＤ（２−ｄ）に
ついての履歴内容を保持させておくようにする。

【００５４】ここで、既存のサーバ２の履歴３に追加す
るサーバＤ（２−ｄ）についての履歴内容は、平均的な
デフォルト値であるようにすることが好ましい。また、
新規サーバＤ（２−ｄ）に保持させる履歴Ｄ（３−ｄ）
は、追加時点での既存のサーバ２の履歴３を入手するよ
うにしてもよいが、現実的には全く同じ履歴３とするこ
とは困難であるので、平均的なデフォルト値であってよ
い。

【００５５】また、第１の実施形態および第２の実施形
態のいずれにおいても、クライアント１から処理要求を
受けた場合だけではなく、さらに、他のサーバ２から処
理が委託された場合にも、自身の履歴３を参照して委託
先サーバ２の選出を行うようにし、自身よりも最適な委
託先サーバ２が選出されたならば、そのようなサーバ２
に委託するようにしてもよい。例えば、図１３では、ク
ライアント１から処理要求を受けたサーバＡ（２−ａ）
が、サーバＣ（２−ｃ）に処理を委託した場合に、サー
バＣ（２−ｃ）は、自身の履歴Ｃ（３−ｃ）を参照し、
委託先サーバ２としてサーバＢ（２−ｂ）が選出される
と、サーバＡ（２−ａ）から委託された処理を、サーバ
Ｂ（２−ｂ）に委託した例を示している。

【００５６】なお、このようにする場合は、委託の度に
委託回数を付加するようにすると共に、委託回数に上限
値を設けるようにし、必要以上に処理のたらい回しが行
われないようにすることが好ましい。例えば、図１３の
例において、委託回数の上限値を２とした場合には、サ
ーバＡ（２−ａ）→サーバＣ（２−ｃ）→サーバＢ（２
−ｂ）と処理が委託されたときに、サーバＢ（２−ｂ）
においては、既に委託回数が２となっているので、サー
バＢ（２−ｂ）は、委託先サーバ２の選出を行わずに、
委託された処理を実行するようにする。

【００５７】また、第１の実施形態および第２の実施形
態のいずれにおいても、サーバ２は、２つ以上のサーバ
２を委託先サーバ２として選出し、これらの委託先サー
バ２に、処理を分割して委託するようにしてもよい。例
えば、図１４では、クライアント１から処理要求を受け
たサーバＡ（２−ａ）が、クライアント１から委託され
た処理５−ａを処理５−ｂおよび処理５−ｃの２つに分
割し、サーバＢ（２−ｂ）およびサーバＣ（２−ｃ）を
委託先サーバ２として選出し、サーバＢ（２−ｂ）に処
理５−ｂを委託し、サーバＣ（２−ｃ）に処理５−ｃを
委託した例を示している。

【００５８】さらに、クライアント１の処理能力によっ
ては、クライアント１が各サーバ２についての履歴を保
持するようにし、まず、クライアント１自身が、これら
の履歴を参照し、処理を要求すべきサーバ２を選出して
から、選出したサーバ２に処理要求を行うようにしても
よい。例えば、図１５では、クライアント１が、サーバ
Ａ（２−ａ）についての履歴Ａ（６−ａ）、サーバＢ
（２−ｂ）についての履歴Ｂ（６−ｂ）、サーバＣ（２
−ｃ）についての履歴Ｃ（６−ｃ）を参照し、処理要求
先としてサーバＣ（２−ｃ）を選出して処理要求を行っ
た例を示している。

【００５９】

【発明の効果】以上、説明したように、本発明によれ
ば、複数のサーバがネットワーク内に存在している環境
で負荷分散を行う際に、負荷分散先を決定するプロキシ
サーバでの処理集中による処理低下の問題を解決できる
だけでなく、プロキシサーバを設定しないことによるコ
スト面での利点が生ずる。

【００６０】また、負荷分散先の処理の待機時間だけで
はなく、データ転送速度を考慮することで、より適切な
負荷分散先の選出を行うことができ、サーバでの処理効
率の向上が見込まれる。

【図面の簡単な説明】

【図１】第１の実施形態に係る負荷分散処理システムの
構成図。

【図２】従来の負荷分散処理システムの構成図。

【図３】従来の負荷分散処理システムの構成図。

【図４】サーバＡが保持するサーバＡに関する履歴内容
の一例を示す説明図。

【図５】サーバＡが保持するサーバＢに関する履歴内容
の一例を示す説明図。

【図６】サーバＡが保持するサーバＣに関する履歴内容
の一例を示す説明図。

【図７】履歴内容の導出方法を示す説明図。

【図８】負荷分散先サーバ選出時に用いられる係数を求
めるための式を示す説明図。

【図９】処理の実行に必要なデータのデータ量と処理に
要するであろう時間との関係を表したグラフを示す説明
図。

【図１０】負荷分散先サーバ選出時に用いられる係数を
求めるための式を示す説明図。

【図１１】処理の実行に必要なデータのデータ量と処理
に要するであろう時間との関係を表したグラフを示す説
明図。

【図１２】新規サーバ導入時の説明図。

【図１３】再委託を行うようにした場合の説明図。

【図１４】処理の分割委託を行うようにした場合の説明
図。

【図１５】クライアントが履歴を保持するようにした場
合の説明図。

【符号の説明】

１：クライアント ２：サーバ ３：履歴 ４：プロキシサーバ ５：データ ６：履歴

───────────────────────────────────────────────────── フロントページの続き (72)発明者 影井 隆 神奈川県横浜市戸塚区戸塚町216番地 株 式会社日立製作所通信事業部内 (72)発明者 荒木 春彦 神奈川県横浜市戸塚区戸塚町216番地 株 式会社日立製作所通信事業部内 (72)発明者 鈴木 功二 神奈川県横浜市戸塚区戸塚町216番地 株 式会社日立製作所通信事業部内 Ｆターム(参考） 5B045 BB28 BB42 GG02 GG05 5B089 GA11 JA11 KA06 KC23 MA03 MC03

Claims (5)

【特許請求の範囲】
1. 【請求項１】複数のサーバと共にネットワークに接続さ
   れるサーバであって、 自身を含む全てのサーバの各々について、該サーバに委
   託した処理ごとに、該処理の実行日時、該処理の処理時
   間、該処理に関するデータ量、および、該処理時のデー
   タ転送時間を、少なくとも履歴情報として保持しておく
   履歴情報記憶手段と、 上記ネットワークに接続されたクライアントから処理が
   要求された場合に、上記履歴情報記憶手段が保持してい
   る履歴情報に基づいて、該処理の実行に要するであろう
   時間が短いサーバを推測し、負荷分散先サーバとして選
   出する負荷分散先サーバ選出手段と、 上記負荷分散先サーバ選出手段が選出したサーバに、上
   記クライアントから要求された処理の実行を委託する委
   託手段とを有することを特徴とする負荷分散機能付きサ
   ーバ。
2. 【請求項２】請求項１記載の負荷分散機能付きサーバで
   あって、 上記負荷分散先サーバ選出手段は、 上記履歴情報記憶手段が保持している履歴情報中の日時
   に応じて、各履歴情報に重み付けを行ってから、負荷分
   散先サーバを選出するか、 または、上記履歴情報記憶手段が保持している履歴情報
   中のデータ量と上記クライアントから要求された処理の
   実行に必要なデータのデータ量との近似性に応じて、各
   履歴情報に重み付けを行ってから、負荷分散先サーバを
   選出することを特徴とする負荷分散機能付きサーバ。
3. 【請求項３】請求項１または２記載の負荷分散機能付き
   サーバであって、 上記負荷分散先サーバ選出手段は、 負荷分散先サーバの候補が複数ある場合には、履歴情報
   が少ないサーバを負荷分散先サーバとして選出すること
   を特徴とする負荷分散機能付きサーバ。
4. 【請求項４】請求項１，２または３記載の負荷分散機能
   付きサーバであって、 上記負荷分散先サーバ選出手段は、 他のサーバから処理の実行を委託された場合にも、上記
   履歴情報記憶手段が保持している履歴情報に基づいて、
   該処理の実行に要するであろう時間が短いサーバを推測
   し、負荷分散先サーバとして選出することを特徴とする
   負荷分散機能付きサーバ。
5. 【請求項５】請求項１，２，３または４記載の負荷分散
   機能付きサーバとネットワークで接続されるクライアン
   トであって、 自身と接続された全てのサーバの各々について、該サー
   バに要求した処理ごとに、該処理の実行日時、該処理の
   処理時間、該処理に関するデータ量、および、該処理時
   のデータ転送時間を、少なくとも履歴情報として保持し
   ておく履歴情報記憶手段と、 いずれかのサーバに実行を要求すべき処理が発生した場
   合に、上記履歴情報記憶手段が保持している履歴情報に
   基づいて、該処理の実行に要するであろう時間が短いサ
   ーバを推測し、処理要求先サーバとして選出する処理要
   求先サーバ選出手段と、 上記処理要求先サーバ選出手段が選出したサーバに、処
   理の実行を要求する処理要求手段とを有することを特徴
   とするクライアント。