"コンシステントハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムであって、前記負荷分散装置は、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたIDIDentifier、および、前記分散処理システムへの参加日時を記憶する記憶部と、前記クライアントマシンから、処理対象のデータの生成日時と当該データのIDとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのIDと前記リクエストにおけるデータのIDとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ID空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、前記選定したサーバに、前記リクエスト送信する処理部と、を有することを特徴とする分散処理システム。コンシステントハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける分散処理方法であって、前記負荷分散装置は、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたIDIDentifier、および、前記分散処理システムへの参加日時を記憶する記憶部と、処理部と、を有しており、前記処理部は、前記クライアントマシンから、処理対象のデータの生成日時と当該データのIDとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのIDと前記リクエストにおけるデータのIDとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ID空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、前記選定したサーバに、前記リクエスト送信することを特徴とする分散処理方法。コンシステントハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置であって、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたIDIDentifier、および、前記分散処理システムへの参加日時を記憶する記憶部と、前記クライアントマシンから、処理対象のデータの生成日時と当該データのIDとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのIDと前記リクエストにおけるデータのIDとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ID空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、前記選定したサーバに、前記リクエスト送信する処理部と、を有することを特徴とする負荷分散装置。コンシステントハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置による負荷分散方法であって、前記負荷分散装置は、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたIDIDentifier、および、前記分散処理システムへの参加日時を記憶する記憶部と、処理部と、を有しており、前記処理部は、前記クライアントマシンから、処理対象のデータの生成日時と当該データのIDとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのIDと前記リクエストにおけるデータのIDとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ID空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、前記選定したサーバに、前記リクエスト送信することを特徴とする負荷分散方法。コンピュータを請求項3に記載の負荷分散装置として機能させるための負荷分散プログラム。コンシステントハッシュ法を用いたデータ振り分けを実施した場合、クラスタメンバの追加や削除に伴い担当が変更となるデータ数を抑えることができ、追加や削除に伴うクラスタ全体に対する負荷を軽減することが可能である。しかし、クラスタメンバを追加する場合、追加されたクラスタメンバに着目して考えると、ID空間上で担当する領域にあるデータを他のクラスタメンバから移動する必要が生じるため、追加直後に高い負荷が生じることになる。即ち、クラスタメンバを追加したにも関わらず、追加直後にはクラスタ全体での性能が向上しないことが考えられる。そこで、本発明は、前記した事情に鑑みて創作されたものであり、コンシステントハッシュ法を用いた分散処理システムにおいて、クラスタメンバを追加した場合に、既存データの移行を行わないことで、システム全体に対する負担の増加を抑制することを課題とする。前記課題を解決するために、本発明は、コンシステントハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムであって、前記負荷分散装置は、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたID、および、前記分散処理システムへの参加日時を記憶する記憶部と、前記クライアントマシンから、処理対象のデータの生成日時と当該データのIDとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのIDと前記リクエストにおけるデータのIDとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ID空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、前記選定したサーバに、前記リクエスト送信する処理部と、を有することを特徴とする。これによれば、コンシステントハッシュ法を用いた分散処理システムにおいて、負荷分散装置は、データの生成日時が候補のサーバの参加日時よりも古いときは、前記したようにして候補のサーバを選定し直すことで、クラスタメンバサーバを追加した場合でも、既存データの移行を行う必要がなく、システム全体に対する負担の増加を抑制することができる。また、本発明は、コンシステントハッシュ法に基づいて、データを管理する複数のサーバ、および、クライアントマシンから受け取ったリクエストを前記複数のサーバのいずれかに振り分ける負荷分散装置を備える分散処理システムにおける前記負荷分散装置であって、前記複数のサーバそれぞれについて、所定のハッシュ値変換によって算出されたID、および、前記分散処理システムへの参加日時を記憶する記憶部と、前記クライアントマシンから、処理対象のデータの生成日時と当該データのIDとを含むリクエストを受け取った場合、前記複数のサーバそれぞれのIDと前記リクエストにおけるデータのIDとに基づいて、前記リクエストを振り分ける前記サーバの候補を選定し、前記データの生成日時と前記候補のサーバの前記参加日時とを比較して、前記データの生成日時が前記候補のサーバの前記参加日時よりも古いときは、ID空間上の次の前記サーバを候補として選定し直し、当該データの生成日時よりも前記参加日時の古い前記サーバが見つかるまで前記サーバの候補を選定し直し、前記選定したサーバに、前記リクエスト送信する処理部と、を有することを特徴とする。これによれば、コンシステントハッシュ法を用いた分散処理システムにおける負荷分散装置は、データの生成日時が候補のサーバの参加日時よりも古いときは、前記したようにして候補のサーバを選定し直すことで、クラスタメンバサーバを追加した場合でも、既存データの移行を行う必要がなく、システム全体に対する負担の増加を抑制することができる。また、本発明は、コンピュータを前記負荷分散装置として機能させるためのプログラムである。これによれば、このようなプログラムを実装したコンピュータを負荷分散装置として機能させることができる。本発明によれば、コンシステントハッシュ法を用いた分散処理システムにおいて、クラスタメンバを追加した場合に、既存データの移行を行わないことで、システム全体に対する負担の増加を抑制することができる。以下、本発明を実施するための形態以下、実施形態と称する。について、図面を参照言及図以外の図も適宜参照しながら説明する。図1に示すように、本実施形態の分散処理システム1000は、クライアントマシン1からのリクエストメッセージとも称する。をネットワーク2経由で受け取るロードバランサ3負荷分散装置と、ロードバランサ3によって振り分けられたリクエストを受け取ってデータ処理を行う複数のサーバ44a,4b,4c,4dとを備えて構成される。なお、複数のサーバ4について、特に区別しないときはサーバ4と表記し、区別するときはサーバ4aなどと表記する。また、本実施形態では、まず、サーバ4a,4b,4cの3台が稼動していて、途中でサーバ4dが追加されるものとする。ロードバランサ3は、コンピュータであり、処理部31、記憶部32、入力部33、表示部34および通信部35を備える。処理部31は、記憶部32に記憶された情報に基づいて各種演算処理を行う手段であり、例えば、CPUCentralProcessingUnitとメモリによって実現される。記憶部32は、各種情報を記憶する手段であり、例えば、ROMReadOnlyMemoryやHDDHardDiskDriveなどによって実現される。また、記憶部32はサーバ管理テーブル321を格納する詳細は後記。入力部33は、ロードバランサ3のユーザが情報を入力する手段であり、例えば、キーボードやマウスによって実現される。表示部34は、情報を表示する手段であり、例えば、LCDLiquidCrystalDisplayによって実現される。通信部35は、外部装置との通信に用いられる通信インタフェースである。サーバ4は、例えば、セッション制御サーバである。複数のサーバ4がクラスタ構成で協調して動作する。また、セッションの確立に用いられる通信プロトコルはSIPSessionInitiationProtocolJRosenbergetalSIPSessionInitiationProtocolRFC3261IETF20026参照であるものとする。また、クラスタを構成する各サーバ4で管理しているデータは、呼状態データであるものとする。ここで、分散処理システム1000における動作の概要について説明する。クラスタにサーバ4dが追加された後、ロードバランサ3は、クライアントマシン1からのリクエストを、コンシステントハッシュ法と、リクエストの対象となるデータの生成日時INVITEの処理日時およびサーバ4の分散処理システム1000への参加日時に基づき決定する振り分け先の決定方法は後記。そして、追加されたサーバ4dには新規データへのリクエストサーバ4dの追加以降にINVITEがロードバランサ3に到着したリクエストのみが割り当てられ、残りのサーバ4a,4b,4cには、既存データへのリクエストサーバ4dの追加以前にINVITEがロードバランサ3に到着したリクエストと新規リクエストが割り当てられる。次に、図2を参照して、ロードバランサ3の記憶部32に格納されるサーバ管理テーブル321について説明する。図2に示すように、サーバ管理テーブル321a321は、サーバ4のID、サーバ名、および、分散処理システム1000への参加日時のカラムを含んで構成され、サーバ4のIDの昇順でソートされている。なお、サーバ管理テーブル321aは、サーバ4dが追加される前のものであるので、サーバ4a,4b,4cに関する情報のみが格納されている。また、サーバ4のIDの作成方法例としては、IPアドレスをハッシュ値変換したものが挙げられる。分散処理システム1000にサーバ4dが追加された場合には、そのサーバ4dからロードバランサ3に通知を行い、それを受けてロードバランサ3がサーバ管理テーブル321を更新する。なお、サーバ管理テーブル321に格納される参加日時としては、ロードバランサ3がサーバ管理テーブル321を更新したときのタイムスタンプを使用すればよい。また、ハッシュ値変換する対象は、IPアドレスに限らず、その他、MACMediaAccessControlアドレスや、あらかじめ決めた名前など、そのサーバ4を特定できるものであれば何でもよい。次に、呼状態データへのID付与方法の例について説明する。呼状態データのIDは、例えば、SIPメッセージのリクエストヘッダのCall-IDとViaヘッダのbranchを組み合わせた値をハッシュ値変換したものとすればよい。また、IDをINVITE受信時に計算してSIPメッセージのToヘッダのTag等に書き込むことで、ロードバランサ3でToヘッダのTagに書き込みがあるかで新規呼InitialINVITEと既存呼非InitialINVITEを判別することも可能である。ロードバランサ3は、SIPメッセージからIDと呼状態データの生成日時を取得し、振り分けアルゴリズム後記に従ってSIPメッセージを各サーバ4に振り分ける。振り分けられたサーバ4ではSIPメッセージの処理を行い、呼状態データを保持する。次に、図3を参照して、データの振り分けについて概念的に説明する。図3は、コンシステントハッシュ法のID空間を示した図であり、サーバ4dの追加前の状態を示す図である。つまり、図3は図2に対応している。図3のID空間では、図7と同様、黒丸●がサーバ4のIDを示し、線分|がデータのIDを示している。そして、各データA~Eは、ID空間内を時計回りに回った場合に最初に出合うサーバ4によって担当される。具体的には、データA、Bはサーバ4cに担当され、データC、Dはサーバ4aに担当され、データEはサーバ4bに担当される。次に、図4,5を参照して、分散処理システム1000にサーバ4dが追加された場合のサーバ管理テーブルの構成とデータの振り分けについて説明する。図4は図2に対応し、図5は図3に対応している。図4に示すように、サーバ4dが追加された場合のサーバ管理テーブル321b321は、サーバ4bの行の下にサーバ4dの行が追加されている。つまり、ここでは、サーバ4dについて算出したIDの数値が、サーバ4bのIDの数値よりも大きく、サーバ4cのIDの数値よりも小さかったものとする。この場合、図5に示すように、ID空間では、サーバ4bから時計回りに少し移動した位置にサーバ4dが配置される。そして、その後に処理対象となったデータサーバ4dの参加日時より新しいデータのIDをα、β、γ、δとし、図5のように配置されたものとする。この場合、各データのうち、データA以外は、ID空間内を時計回りに回った場合に最初に出合うサーバ4によって担当される。そして、データAは、ID空間内を時計回りに回った場合に最初に出合うサーバ4dではなく、その次に出合うサーバ4cによって担当される。これらを実現するためのアルゴリズムに基づく処理の流れについて、以下で説明を行う。図6に示すように、ロードバランサ3の処理部31は、クライアントマシン1からネットワーク2経由でメッセージを受け取ると、そのメッセージから呼状態データのIDを取得するステップS1。次に、処理部31は、コンシステントハッシュ法に基づき、メッセージを振り分けるサーバ4の候補を選定するステップS2。次に、処理部31は、そのメッセージから呼状態データの生成日時を取得し、その呼状態データの生成日時が、該当するサーバ4ステップS2で選定したサーバ4の参加日時記憶部32のサーバ管理テーブル321から取得よりも新しいか否かを判断しステップS3、Yesの場合はステップS4に進み、Noの場合はステップS5に進む。つまり、サーバ4の参加日時の方が古い場合ステップS3でYes、当該データはその選定したサーバ4が管理していることになるので、ステップS4に進む。一方、データの生成日時の方が古い場合ステップS3でNo、当該データが生成された日時にはその選定したサーバ4が存在していなかったことになるため、ステップS5に進んで異なるサーバ4を選定する。なお、コンシステントハッシュ法の性質上、次に当該データを管理している可能性の高いサーバ4は、サーバ管理テーブル321における次の1行下のサーバ4なので、ステップS5でそのサーバ4を選定する。ステップS5において、処理部31は、ステップS2で選定したサーバ4を基準にID空間を時計回りに回って次に出合うサーバ4を新たに選定し、その新たに選定したサーバ4の参加日時を、記憶部32のサーバ管理テーブル321を参照することで確認し、ステップS3に戻る。ステップS4において、処理部31は、そのメッセージをそのサーバ4ステップS2またはステップS5で選定したサーバ4に送信し、処理を終了する。そのメッセージを受信したそのサーバ4は、メッセージに基づいたデータ処理を行う。なお、ロードバランサ3は、クライアントマシン1からメッセージを受け取るたびに、この図6に示す処理を行う。このようにして、本実施形態によれば、コンシステントハッシュ法を用いた分散処理システム1000において、クラスタメンバサーバ4dを追加した場合に、既存データの移行を行わないことで、システム全体に対する負担の増加を抑制することができる。つまり、各データについて担当するサーバ4を決定するロードバランサ3は、データの再配置を行わなくてもいいように、リクエストが既存データに対するものであるかを判別し、既存データに対するリクエストの場合には、データを保持しているサーバ4にリクエストを割り当てる。そして、ロードバランサ3は、追加されたサーバ4dに対しては既存データを割り当てず、そのサーバ4dの追加以降にクラスタで管理することになった新規データについてのみ割り当てを行う。なお、新規データは、追加されたサーバ4dを含むすべてのサーバ4に振り分けられる。これらの処理により、追加されたサーバ4dに既存データを移行する必要がないため、追加直後に高い負荷が生じることはない。なお、本実施形態による手法は、特に、SIPの呼状態のように、データの更新頻度が高く、既存データより新規データの処理の方が多い場合に有効である。以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。例えば、本発明は、コンピュータをロードバランサ3として機能させるためのプログラムとしても具現化可能である。その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。"