(57)【特許請求の範囲】
【請求項１】
コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムであって、
前記負荷分散装置は、
前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出された複数の仮想ＩＤ（IDentifier）を格納するサーバ管理情報を記憶する記憶部と、
前記分散処理システムに新たなサーバが追加された場合、その後、当該サーバから仮想ＩＤの追加リクエストを受け取ったときに、当該サーバについて、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤを前記所定のハッシュ値変換によって算出して前記サーバ管理情報に追加することで前記サーバ管理情報を更新し、当該更新したサーバ管理情報に基づいて、前記クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける処理部と、を有し、
前記追加されたサーバは、前記負荷分散装置に送信した仮想ＩＤの追加リクエストの回数が所定数に達するまで、自身の処理負荷が所定値以下になったときごとに、または、所定の時間間隔で、前記負荷分散装置に仮想ＩＤの追加リクエストを送信する
ことを特徴とする分散処理システム。
【請求項２】
コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムによる分散処理方法であって、
前記負荷分散装置は、
前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出された複数の仮想ＩＤ（IDentifier）を格納するサーバ管理情報を記憶する記憶部と、処理部と、を有しており、
前記処理部は、
前記分散処理システムに新たなサーバが追加された場合、その後、当該サーバから仮想ＩＤの追加リクエストを受け取ったときに、当該サーバについて、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤを前記所定のハッシュ値変換によって算出して前記サーバ管理情報に追加することで前記サーバ管理情報を更新し、当該更新したサーバ管理情報に基づいて、前記クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分け、
前記追加されたサーバは、
前記負荷分散装置に送信した仮想ＩＤの追加リクエストの回数が所定数に達するまで、自身の処理負荷が所定値以下になったときごとに、または、所定の時間間隔で、前記負荷分散装置に仮想ＩＤの追加リクエストを送信する
ことを特徴とする分散処理方法。
【請求項３】
コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置であって、
前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出された複数の仮想ＩＤ（IDentifier）を格納するサーバ管理情報を記憶する記憶部と、
前記分散処理システムに新たなサーバが追加され、前記追加されたサーバが、前記負荷分散装置に送信した仮想ＩＤの追加リクエストの回数が所定数に達するまで、自身の処理負荷が所定値以下になったときごとに、または、所定の時間間隔で、前記負荷分散装置に仮想ＩＤの追加リクエストを送信する場合に、
当該追加されたサーバから仮想ＩＤの追加リクエストを受け取ったときに、当該サーバについて、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤを前記所定のハッシュ値変換によって算出して前記サーバ管理情報に追加することで前記サーバ管理情報を更新し、当該更新したサーバ管理情報に基づいて、前記クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける処理部と、を有する
ことを特徴とする負荷分散装置。
【請求項４】
コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置による負荷分散方法であって、
前記負荷分散装置は、
前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出された複数の仮想ＩＤ（IDentifier）を格納するサーバ管理情報を記憶する記憶部と、処理部と、を有しており、
前記分散処理システムに新たなサーバが追加され、前記追加されたサーバが、前記負荷分散装置に送信した仮想ＩＤの追加リクエストの回数が所定数に達するまで、自身の処理負荷が所定値以下になったときごとに、または、所定の時間間隔で、前記負荷分散装置に仮想ＩＤの追加リクエストを送信する場合に、
前記処理部は、
当該追加されたサーバから仮想ＩＤの追加リクエストを受け取ったときに、当該サーバについて、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤを前記所定のハッシュ値変換によって算出して前記サーバ管理情報に追加することで前記サーバ管理情報を更新し、当該更新したサーバ管理情報に基づいて、前記クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける
ことを特徴とする負荷分散方法。
【請求項５】
コンピュータを請求項３に記載の負荷分散装置として機能させるための負荷分散プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のマシン（サーバ等のコンピュータ）が協調してデータ処理を行うクラスタ構成の分散処理システムにおける技術に関する。
【背景技術】
【０００２】
近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のマシンを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。
【０００３】
分散処理を行う際には、処理対象のデータを、クラスタを構成する各マシン（以下、「クラスタメンバ」とも称する。）に振り分けておく必要がある。このとき、クラスタ全体での処理能力を高めるためには、各クラスタメンバが担当するデータ数は平均化されていることが望ましい。
【０００４】
代表的なデータの振り分け手法として、各データのｋｅｙをハッシュ関数にかけた値（以下、「ｈａｓｈ（ｋｅｙ）」と称する。）をクラスタメンバ数Ｎで割った余り、即ち「ｈａｓｈ（ｋｅｙ）  ｍｏｄ  Ｎ」を番号として持つクラスタメンバにデータを振り分ける手法がある。この場合、各クラスタメンバに事前に０からＮ−１までの番号を割り当てていることが前提となる。このような振り分け手法を用いた場合、クラスタメンバを追加すると、Ｎの値が変化して、多くのデータについて、担当するクラスタメンバが変更になるため、担当するデータの再配置が必要になる。
【０００５】
そこで、クラスタメンバの追加に伴い担当するクラスタメンバが変更になるデータ数を約１／Ｎに抑える方法として、コンシステント・ハッシュ［Consistent Hashing］（非特許文献１参照）を用いた振り分け手法があり、Amazon Dynamo（非特許文献２参照）等で用いられている。このコンシステント・ハッシュ法を用いたデータ振り分け手法では、クラスタメンバとデータの双方にＩＤ（IDentifier）を割り当て、データのＩＤからＩＤ空間を時計回りに回った場合に最初に出合ったクラスタメンバを担当とする。また、クラスタメンバに対するＩＤの与え方の例としては、ＩＰ（Internet Protocol）アドレスをハッシュ関数にかけた値（以下、「ｈａｓｈ（ＩＰアドレス）」と称する。）が挙げられる。
【０００６】
ここで、図６を参照して、コンシステント・ハッシュ法についてさらに説明する。図６はＩＤ空間を表し、黒丸（●）がサーバのＩＤを示し、線分（｜）がデータのＩＤを示す。各データは、ＩＤ空間内を時計回りに回った場合に最初に出合うサーバによって担当される。
【０００７】
また、クラスタ構成の分散処理システムでは、各クラスタメンバの性能が等しい場合には、各クラスタメンバが担当するデータ量が等しいこと（即ち、コンシステント・ハッシュ法のＩＤ空間における、クラスタメンバ間の距離が等しいこと）が望ましい。なお、そのＩＤ空間において、各クラスタメンバが担当する領域を、以下、「担当領域」と称する。
【０００８】
前記した望ましい状態に近づけるために、例えば、各クラスタメンバに仮想的に複数のＩＤ（以下、「仮想ＩＤ」と称する。）を持たせる手法が用いられる（非特許文献１参照）。この手法によれば、各クラスタメンバが複数の仮想ＩＤを持つことで、仮想ＩＤごとの担当領域のサイズが異なっていても、大数の法則に従って、各クラスタメンバの担当領域のサイズは平均化される。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】David Karger et al., “Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”, [online], 1997, ACM, [平成23年7月1日検索], インターネット<ＵＲＬ：http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf>
【非特許文献２】Giuseppe DeCandia et al., “Dynamo: Amazon’s Highly Available Key-value Store”, [online], 2007, ACM, [平成23年7月1日検索], インターネット<ＵＲＬ：http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf >
【発明の概要】
【発明が解決しようとする課題】
【００１０】
コンシステント・ハッシュ法を用いたデータ振り分けを実施した場合、クラスタメンバの追加や削除に伴い担当が変更となるデータ数を抑えることができ、追加や削除に伴うクラスタ全体に対する負荷を軽減することが可能である。しかし、クラスタメンバを追加する場合、追加されたクラスタメンバに着目して考えると、ＩＤ空間上で担当する領域にあるデータを他のクラスタメンバから移動する必要が生じるため、追加直後に高い負荷が生じることになる。即ち、クラスタメンバを追加したにも関わらず、追加直後にはクラスタ全体での性能が向上しないことが考えられる。これは、各クラスタメンバに複数の仮想ＩＤを持たせる手法の場合でも同様に発生する問題である。
【００１１】
そこで、本発明は、前記した事情に鑑みて創作されたものであり、コンシステント・ハッシュ法を用いた分散処理システムにおいて、クラスタメンバを追加した場合に、システム全体に対する負担の増加を抑制することを課題とする。
【課題を解決するための手段】
【００１２】
前記課題を解決するために、本発明は、コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムであって、前記負荷分散装置は、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出された複数の仮想ＩＤを格納するサーバ管理情報を記憶する記憶部と、前記分散処理システムに新たなサーバが追加された場合、その後、当該サーバから仮想ＩＤの追加リクエストを受け取ったときに、当該サーバについて、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤを前記所定のハッシュ値変換によって算出して前記サーバ管理情報に追加することで前記サーバ管理情報を更新し、当該更新したサーバ管理情報に基づいて、前記クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける処理部と、を有し、前記追加されたサーバは、前記負荷分散装置に送信した仮想ＩＤの追加リクエストの回数が所定数に達するまで、自身の処理負荷が所定値以下になったときごとに、または、所定の時間間隔で、前記負荷分散装置に仮想ＩＤの追加リクエストを送信することを特徴とする。
【００１３】
また、本発明は、コンシステント・ハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置であって、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出された複数の仮想ＩＤを格納するサーバ管理情報を記憶する記憶部と、前記分散処理システムに新たなサーバが追加され、前記追加されたサーバが、前記負荷分散装置に送信した仮想ＩＤの追加リクエストの回数が所定数に達するまで、自身の処理負荷が所定値以下になったときごとに、または、所定の時間間隔で、前記負荷分散装置に仮想ＩＤの追加リクエストを送信する場合に、当該追加されたサーバから仮想ＩＤの追加リクエストを受け取ったときに、当該サーバについて、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤを前記所定のハッシュ値変換によって算出して前記サーバ管理情報に追加することで前記サーバ管理情報を更新し、当該更新したサーバ管理情報に基づいて、前記クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける処理部と、を有することを特徴とする。
【００１４】
これらによれば、コンシステント・ハッシュ法を用いた分散処理システムにおいて、分散処理システムに新たに追加されたサーバが、自身の処理負荷が所定値以下になったときごとに、または、所定の時間間隔で、負荷分散装置に仮想ＩＤの追加リクエストを送信し、負荷分散装置がその追加リクエストを受け取ったときごとに当該サーバについて、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤをサーバ管理情報に追加していくことで、システム全体に対するそのサーバの追加に起因する負担の増加を抑制することができる。
【００１５】
また、本発明は、コンピュータを前記負荷分散装置として機能させるためのプログラムである。
【００１６】
これによれば、このようなプログラムを実装したコンピュータを負荷分散装置として機能させることができる。
【発明の効果】
【００１７】
本発明によれば、コンシステント・ハッシュ法を用いた分散処理システムにおいて、クラスタメンバを追加した場合に、システム全体に対する負担の増加を抑制することができる。
【図面の簡単な説明】
【００１８】
【図１】本実施形態の分散処理システムを含む全体構成図である。
【図２】本実施形態のサーバ管理テーブルの構成図である。
【図３】本実施形態において、仮想ＩＤの追加タイミングの決定方法の一例を説明するための図である。
【図４】本実施形態において、追加されたサーバによる処理の流れを示すフローチャートである。
【図５】本実施形態において、ロードバランサによる処理の流れを示すフローチャートである。
【図６】従来のコンシステント・ハッシュ法を説明するためのＩＤ空間の概念図である。
【発明を実施するための形態】
【００１９】
以下、本発明を実施するための形態（以下、実施形態と称する。）について、図面を参照（言及図以外の図も適宜参照）しながら説明する。図１に示すように、本実施形態の分散処理システム１０００は、クライアントマシン１からのリクエストをネットワーク２経由で受け取るロードバランサ３（負荷分散装置）と、ロードバランサ３によって振り分けられたリクエストを受け取ってデータ処理を行う複数のサーバ４（４ａ，４ｂ，４ｃ，４ｄ）とを備えて構成される。なお、複数のサーバ４について、特に区別しないときは「サーバ４」と表記し、区別するときは「サーバ４ａ」などと表記する。また、本実施形態では、まず、サーバ４ａ，４ｂ，４ｃの３台が稼動していて、途中でサーバ４ｄが追加されるものとする。
【００２０】
ロードバランサ３は、コンピュータであり、処理部３１、記憶部３２、入力部３３、表示部３４および通信部３５を備える。
処理部３１は、記憶部３２に記憶された情報に基づいて各種演算処理を行う手段であり、例えば、ＣＰＵ（Central Processing Unit）とメモリによって実現される。
【００２１】
記憶部３２は、各種情報を記憶する手段であり、例えば、ＲＯＭ（Read Only Memory）やＨＤＤ（Hard Disk Drive）などによって実現される。また、記憶部３２はサーバ管理テーブル３２１（サーバ管理情報）を格納する（詳細は後記）。
【００２２】
入力部３３は、ロードバランサ３のユーザが情報を入力する手段であり、例えば、キーボードやマウスによって実現される。
表示部３４は、情報を表示する手段であり、例えば、ＬＣＤ（Liquid Crystal Display）によって実現される。
通信部３５は、外部装置との通信に用いられる通信インタフェースである。
【００２３】
サーバ４は、例えば、セッション制御サーバである。複数のサーバ４がクラスタ構成で協調して動作する。また、セッションの確立に用いられる通信プロトコルは、例えば、ＳＩＰ（Session Initiation Protocol）（「J.Rosenberg, et.al, “SIP: Session Initiation Protocol”, RFC3261, IETF, 2002.6」参照）である。
【００２４】
ここで、分散処理システム１０００における動作の概要について説明する。ロードバランサ３は、クライアントマシン１からリクエストを受け取ったとき、コンシステント・ハッシュ法に基づいて振り分け先のサーバ４を決定する。そのために、ロードバランサ３は、複数のサーバ４それぞれについて複数の仮想ＩＤを格納したサーバ管理テーブル３２１を保持している。例えば、クラスタにサーバ４ｄが追加された場合、ロードバランサ３は、サーバ管理テーブル３２１に、そのサーバ４ｄに対応する複数の仮想ＩＤを、一度にではなく、複数回に分けて、追加する。この仮想ＩＤの追加のタイミングは、例えば、追加したサーバ４ｄの処理負荷（ＣＰＵ使用率、トラヒック量、保持データ量（データ移行によりデータが徐々に増える。）等）や、事前に設定した時間間隔等により決定すればよい。このようにすることで、サーバ４ｄの追加にともなうサーバ４ｄに対するデータの移行が集中せずに済み、サーバ４ｄおよび分散処理システム１０００全体の負荷の増加を抑制できる。
【００２５】
次に、図２を参照して、ロードバランサ３の記憶部３２に格納されるサーバ管理テーブル３２１について説明する。図２に示すように、サーバ管理テーブル３２１は、サーバ４のＩＤ、および、サーバ名のカラムを含んで構成され、サーバ４のＩＤの昇順でソートされている。なお、前記したように、複数のサーバ４それぞれについて、複数の仮想ＩＤが格納されている。仮想ＩＤの作成方法例としては、ＩＰアドレスをハッシュ値変換したものが挙げられる。なお、ハッシュ値変換する対象は、ＩＰアドレスに限らず、その他、ＭＡＣ（Media Access Control）アドレスや、あらかじめ決めた名前など、そのサーバ４を特定できるものであれば何でもよい。複数の仮想ＩＤの作成については公知技術であるので詳細な説明を省略する。
【００２６】
次に、図３を参照して、追加したサーバ４ｄに関する仮想ＩＤの追加タイミングの決定方法の例について説明する。追加されたサーバ４ｄは、自身の処理負荷（例えばＣＰＵ使用率）を監視する。ＣＰＵ使用率が所定の基準値以下になった場合、サーバ４ｄはロードバランサ３に仮想ＩＤの追加リクエストを送信する。仮想ＩＤの追加リクエストを受け取ったロードバランサ３は、サーバ管理テーブル３２１に、サーバ４ｄについて、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤを追加する。その後、サーバ４ｄは、新しく追加された仮想ＩＤの担当領域に対応するデータの移行と、リクエストの処理を行うことになる。よって、サーバ４ｄは、負荷が増大し、ＣＰＵ使用率が上昇する。しかし、データの移行が完了すると、リクエストの処理のみとなるため、ＣＰＵ使用率は減少する。そこで、ＣＰＵ使用率が基準値以下になったら、再び仮想ＩＤの追加リクエストを送信する。これらの処理を、事前に設定した数の仮想ＩＤが振り終わるまで繰り返す。なお、ＣＰＵ使用率の細かい変動を考慮して、一定時間（数秒程度）の移動平均をとり、その値と基準値の比較を行うことが望ましい。
【００２７】
次に、図４を参照して、新たに追加されたサーバ４ｄにおける仮想ＩＤの追加リクエストの送信に関する処理について説明する。なお、サーバ４ｄは、以下で説明する処理のほかに、並行して、ロードバランサ３から受け取ったリクエストに対する処理も行う。
【００２８】
図４に示すように、サーバ４ｄは、所定数の仮想ＩＤの追加リクエストのロードバランサ３への送信が完了したか否かを判断し（ステップＳ４１）、Ｙｅｓの場合は、もう仮想ＩＤの追加リクエストをロードバランサ３に送信する必要がないため処理を終了し、Ｎｏの場合はステップＳ４２に進む。なお、サーバ４ｄが仮想ＩＤの追加リクエストをロードバランサ３に何回送ればよいかは、１回の追加リクエストによってロードバランサ３で追加されるサーバ４ｄについての仮想ＩＤの数と、サーバ４ｄに割り当てるべきすべての仮想ＩＤの数とから、予め決定しておくことができる。
【００２９】
ステップＳ４２において、サーバ４ｄは、自身のＣＰＵ使用率の移動平均を算出する。
次に、サーバ４ｄは、ステップＳ４２で算出した移動平均の値に基づいて、ＣＰＵ使用率が所定の基準値以下であるか否かを判断し（ステップＳ４３）、Ｙｅｓの場合はステップＳ４４に進み、Ｎｏの場合はステップＳ４２に戻る。
【００３０】
ステップＳ４４において、サーバ４ｄは、ロードバランサ３に仮想ＩＤの追加リクエストを送信し、ステップＳ４１に戻る。
【００３１】
次に、図５を参照して、ロードバランサ３における処理について説明する。図５に示すように、ロードバランサ３において、処理部３１は、サーバ４から仮想ＩＤの追加リクエストを受信したか否かを判断し（ステップＳ５１）、Ｙｅｓの場合はステップＳ５２に進み、Ｎｏの場合はステップＳ５４に進む。
【００３２】
以下、ステップＳ５１でサーバ４ｄから仮想ＩＤの追加リクエストを受信したものとして、ステップＳ５２、Ｓ５３について説明する。
ステップＳ５２において、処理部３１は、記憶部３２のサーバ管理テーブル３２１に、該当するサーバ（サーバ４ｄ）について、割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤを追加する。
【００３３】
その後、処理部３１は、ステップＳ５２でサーバ管理テーブル３２１に追加したサーバ４ｄの仮想ＩＤの担当領域に対応するデータの移行をサーバ４ｄに指示する。なお、ここでは、ステップＳ５２の直後にデータの移行を指示することとしたが、それ以外に、該当するデータへのリクエストをサーバ４ｄに割り当てるタイミングでデータの移行を指示してもよい。
【００３４】
また、データの移行は、具体的には、例えば次のようにして実施すればよい。既存のデータに関するリクエストが、追加されたサーバ４ｄに振り分けられた場合、コンシステント・ハッシュ法の性質上、そのデータは、ＩＤ空間上でサーバ４ｄから時計回りに回って最初に出合うサーバ４によって保持されている可能性が高い。したがって、サーバ４ｄは、そのサーバ４に問い合わせることで、そのデータを取得できる。ただし、複数のサーバ４が一度に追加された場合には、必ずしもＩＤ空間上でサーバ４ｄから時計回りに回って最初に出合うサーバ４がそのデータを保持しているとは限らないため、そのデータを保持しているサーバ４が見つかるまで、さらに隣のサーバ４に順次問い合わせを行う必要がある。そして、サーバ４ｄは、そのデータを格納しているサーバ４からそのデータを取得する。
【００３５】
ステップＳ５３の後、処理部３１は、クライアントマシン１からネットワーク２経由で受信したリクエストを、コンシステント・ハッシュ法に基づいて各サーバ４に振り分け（ステップＳ５４）、ステップＳ５１に戻る。
【００３６】
このようにして、本実施形態によれば、コンシステント・ハッシュ法を用いた分散処理システム１０００において、クラスタメンバ（サーバ４ｄ）を追加した場合に、追加されたサーバ４ｄが、自身の処理負荷が所定値以下になったときごとにロードバランサ３に仮想ＩＤの追加リクエストを送信し、ロードバランサ３がその追加リクエストを受け取ったときごとにサーバ４ｄについて割り当てるべきすべての数よりも少ない１つ以上の仮想ＩＤをサーバ管理テーブル３２１に追加していく（つまり、追加したクラスタメンバの仮想ＩＤをすべて一度にではなく複数回に分けて割り当てる）ことで、サーバ４ｄへのデータの移行が集中せず、システム全体に対する負担の増加を抑制することができる。
【００３７】
以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。
例えば、本発明は、コンピュータをロードバランサ３として機能させるためのプログラムとしても具現化可能である。
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００３８】
１      クライアントマシン
２      ネットワーク
３      ロードバランサ（負荷分散装置）
４，４ａ，４ｂ，４ｃ，４ｄ  サーバ
３１    処理部
３２    記憶部
３３    入力部
３４    表示部
３５    通信部
３２１  サーバ管理テーブル（サーバ管理情報）
１０００  分散処理システム
【図１】
0005544524.tif 000002
【図２】
0005544524.tif 000003
【図３】
0005544524.tif 000004
【図４】
0005544524.tif 000005
【図５】
0005544524.tif 000006
【図６】
0005544524.tif 000007