マスターサーバと、複数のスレーブサーバとを有し、前記マスターサーバが、複数のデータを記憶するテーブルを分割することによって前記複数のスレーブサーバのそれぞれに複数の部分テーブルを割り当て、前記複数のスレーブサーバのそれぞれが、前記割り当てられた複数の部分テーブルを、当該複数の部分テーブルのそれぞれへの更新情報を記憶するWALログを用いて管理する分散データストアシステムであって、前記複数のスレーブサーバのそれぞれは、当該スレーブサーバが管理している複数の部分テーブルのそれぞれを複数のグループのいずれかに分類し、該複数のグループのそれぞれと、前記WALログを複数のファイルに分割することによって生成された、前記複数のグループのそれぞれに属する部分テーブルへの更新情報を記憶する複数の分割WALログのそれぞれとを対応付けるWALログ管理部を有し、前記マスターサーバは、前記複数のスレーブサーバのそれぞれに障害が発生したことを検知する障害検知部と、前記障害検知部にて前記複数のスレーブサーバのいずれかに障害が発生したことが検知されると、当該障害が発生したスレーブサーバの複数の分割WALログのそれぞれを選択し、該選択された分割WALログに対応するグループに属する部分テーブルを管理させるスレーブサーバを、前記複数のスレーブサーバのうち、当該障害が発生したスレーブサーバ以外のスレーブサーバの中からリカバリ用スレーブサーバとして選択するリカバリ要求部と、を有し、前記複数のスレーブサーバのそれぞれは、前記リカバリ要求部にて当該スレーブサーバが前記リカバリ用スレーブサーバとして選択された場合、前記選択された分割WALログを読み込むことにより、当該選択された分割WALログに対応するグループに属する部分テーブルの管理を開始するリカバリ処理部を有する分散データストアシステム。請求項1に記載の分散データストアシステムにおいて、前記リカバリ要求部は、前記複数のスレーブサーバのそれぞれが管理している部分テーブルの数に応じ、前記複数のスレーブサーバのうち、当該障害が発生したスレーブサーバ以外のスレーブサーバの中から前記リカバリ用スレーブサーバを選択する分散データストアシステム。請求項1または請求項2に記載の分散データストアシステムにおいて、前記マスターサーバは、前記複数のスレーブサーバのそれぞれが管理している部分テーブルの数が、当該複数のスレーブサーバ間で均一化されているかどうかを判定する均一化判定を実行するリバランス部をさらに有し、前記リバランス部は、前記均一化判定において均一化されていないと判定した場合、前記複数のスレーブサーバの中から、管理している部分テーブルの数が最多のスレーブサーバを最多スレーブサーバとして選択するとともに、管理している部分テーブルの数が最少のスレーブサーバを最少スレーブサーバとして選択し、前記複数のスレーブサーバのそれぞれは、前記リバランス部にて当該スレーブサーバが前記最多スレーブサーバとして選択された場合、当該スレーブサーバにて管理している部分テーブルのうちのいずれかを選択し、該選択した部分テーブルを管理対象から除外するアンロード部と、前記リバランス部にて当該スレーブサーバが前記最少スレーブサーバとして選択された場合、前記管理対象から除外された部分テーブルを、当該スレーブサーバが管理する部分テーブルとするロード部と、をさらに有する分散データストアシステム。マスターサーバと、複数のスレーブサーバとを有し、前記マスターサーバが、複数のデータを記憶するテーブルを分割することによって前記複数のスレーブサーバのそれぞれに複数の部分テーブルを割り当て、前記複数のスレーブサーバのそれぞれが、前記割り当てられた複数の部分テーブルを、当該複数の部分テーブルのそれぞれへの更新情報を記憶するWALログを用いて管理する分散データストアシステムにおける障害復旧方法であって、前記複数のスレーブサーバのそれぞれが、当該スレーブサーバが管理している複数の部分テーブルのそれぞれを複数のグループのいずれかに分類し、該複数のグループのそれぞれと、前記WALログを複数のファイルに分割することによって生成された、前記複数のグループのそれぞれに属する部分テーブルへの更新情報を記憶する複数の分割WALログのそれぞれとを対応付ける処理と、前記マスターサーバが、前記複数のスレーブサーバのいずれかに障害が発生したことを検知すると、当該障害が発生したスレーブサーバの複数の分割WALログのそれぞれを選択する処理と、前記マスターサーバが、前記選択された分割WALログに対応するグループに属する部分テーブルを管理させるスレーブサーバを、前記複数のスレーブサーバのうち、当該障害が発生したスレーブサーバ以外のスレーブサーバの中からリカバリ用スレーブサーバとして選択する選択処理と、前記複数のスレーブサーバのそれぞれが、当該スレーブサーバが前記リカバリ用スレーブサーバとして選択された場合、前記選択された分割WALログを読み込むことにより、当該選択された分割WALログに対応するグループに属する部分テーブルの管理を開始する処理と、を有する障害復旧方法。請求項4に記載の障害復旧方法において、前記選択処理は、前記マスターサーバが、前記複数のスレーブサーバのそれぞれが管理している部分テーブルの数に応じ、前記複数のスレーブサーバのうち、当該障害が発生したスレーブサーバ以外のスレーブサーバの中から前記リカバリ用スレーブサーバを選択する処理である障害復旧方法。請求項4または請求項5に記載の障害復旧方法において、前記マスターサーバが、前記複数のスレーブサーバのそれぞれが管理している部分テーブルの数が、当該複数のスレーブサーバ間で均一化されているかどうかを判定する均一化判定を実行する処理と、前記マスターサーバが、前記均一化判定において均一化されていないと判定した場合、前記複数のスレーブサーバの中から、管理している部分テーブルの数が最多のスレーブサーバを最多スレーブサーバとして選択するとともに、管理している部分テーブルの数が最少のスレーブサーバを最少スレーブサーバとして選択する処理と、前記複数のスレーブサーバのそれぞれが、当該スレーブサーバが前記最多スレーブサーバとして選択された場合、当該スレーブサーバにて管理している部分テーブルのうちのいずれかを選択し、該選択した部分テーブルを管理対象から除外する処理と、前記複数のスレーブサーバのそれぞれが、当該スレーブサーバが前記最少スレーブサーバとして選択された場合、前記管理対象から除外された部分テーブルを、当該スレーブサーバが管理する部分テーブルとする処理と、をさらに有する障害復旧方法。上述したBigtableをはじめとする分散KeyValueストアシステムでは、複数のサーバのいずれかに障害が発生した場合、その複数のサーバのうち障害が発生したサーバ以外の1台のサーバが、障害が発生したサーバのWALログを読み出して、自身に読み込ませる。これにより、障害が発生したサーバが管理していた複数の部分テーブルの管理が再開され、分散KeyValueストアシステムが障害から復旧することになる。ここで、WALログのサイズが大きな場合、そのWALログを読み出して、自身に読み込ませるのには長い時間を要する。従って、分散KeyValueストアシステムが障害から復旧するまでの時間が長くなり、システムの可用性が低くなってしまうという問題点がある。そのため、Bigtableアーキテクチャでは、複数のサーバのいずれかに障害が発生した場合、その複数のサーバのうち障害が発生したサーバ以外の1台のサーバが、障害が発生したサーバのWALログを読み出して複数のファイルに分割する。以降、この複数のファイルのそれぞれのことを分割WALログという。そして、複数の分割WALログのそれぞれを、相互に異なる複数のサーバのそれぞれに読み込ませることによって障害から復旧するまでの時間を短縮している。しかしながら、例えば2GB程度のサイズのWALログを読み出して複数の分割WALログに分割し、その複数の分割WALログのそれぞれを相互に異なる複数のサーバのそれぞれに読み込ませたとしても、分散KeyValueストアシステムが障害から復旧するまでには1時間程度かかってしまう。従って、Bigtableアーキテクチャで用いられている上記の手法は、システムの可用性が低くなってしまうという問題点を解決するのに十分な手法とはいえない。本発明は、高可用性を確保した分散データストアシステムおよび障害復旧方法を提供することを目的とする。上記目的を達成するために本発明の分散データストアシステムは、マスターサーバと、複数のスレーブサーバとを有し、前記マスターサーバが、複数のデータを記憶するテーブルを分割することによって前記複数のスレーブサーバのそれぞれに複数の部分テーブルを割り当て、前記複数のスレーブサーバのそれぞれが、前記割り当てられた複数の部分テーブルを、当該複数の部分テーブルのそれぞれへの更新情報を記憶するWALログを用いて管理する分散データストアシステムであって、前記複数のスレーブサーバのそれぞれは、当該スレーブサーバが管理している複数の部分テーブルのそれぞれを複数のグループのいずれかに分類し、該複数のグループのそれぞれと、前記WALログを複数のファイルに分割することによって生成された、前記複数のグループのそれぞれに属する部分テーブルへの更新情報を記憶する複数の分割WALログのそれぞれとを対応付けるWALログ管理部を有し、前記マスターサーバは、前記複数のスレーブサーバのそれぞれに障害が発生したことを検知する障害検知部と、前記障害検知部にて前記複数のスレーブサーバのいずれかに障害が発生したことが検知されると、当該障害が発生したスレーブサーバの複数の分割WALログのそれぞれを選択し、該選択された分割WALログに対応するグループに属する部分テーブルを管理させるスレーブサーバを、前記複数のスレーブサーバのうち、当該障害が発生したスレーブサーバ以外のスレーブサーバの中からリカバリ用スレーブサーバとして選択するリカバリ要求部と、を有し、前記複数のスレーブサーバのそれぞれは、前記リカバリ要求部にて当該スレーブサーバが前記リカバリ用スレーブサーバとして選択された場合、前記選択された分割WALログを読み込むことにより、当該選択された分割WALログに対応するグループに属する部分テーブルの管理を開始するリカバリ処理部を有する。また、上記目的を達成するために本発明の障害復旧方法は、マスターサーバと、複数のスレーブサーバとを有し、前記マスターサーバが、複数のデータを記憶するテーブルを分割することによって前記複数のスレーブサーバのそれぞれに複数の部分テーブルを割り当て、前記複数のスレーブサーバのそれぞれが、前記割り当てられた複数の部分テーブルを、当該複数の部分テーブルのそれぞれへの更新情報を記憶するWALログを用いて管理する分散データストアシステムにおける障害復旧方法であって、前記複数のスレーブサーバのそれぞれが、当該スレーブサーバが管理している複数の部分テーブルのそれぞれを複数のグループのいずれかに分類し、該複数のグループのそれぞれと、前記WALログを複数のファイルに分割することによって生成された、前記複数のグループのそれぞれに属する部分テーブルへの更新情報を記憶する複数の分割WALログのそれぞれとを対応付ける処理と、前記マスターサーバが、前記複数のスレーブサーバのいずれかに障害が発生したことを検知すると、当該障害が発生したスレーブサーバの複数の分割WALログのそれぞれを選択する処理と、前記マスターサーバが、前記選択された分割WALログに対応するグループに属する部分テーブルを管理させるスレーブサーバを、前記複数のスレーブサーバのうち、当該障害が発生したスレーブサーバ以外のスレーブサーバの中からリカバリ用スレーブサーバとして選択する選択処理と、前記複数のスレーブサーバのそれぞれが、当該スレーブサーバが前記リカバリ用スレーブサーバとして選択された場合、前記選択された分割WALログを読み込むことにより、当該選択された分割WALログに対応するグループに属する部分テーブルの管理を開始する処理と、を有する。本発明は以上説明したように構成されているので、複数のスレーブサーバのそれぞれに障害が発生した場合に、その障害が発生したスレーブサーバのWALログを読み込んで分割する必要がない。従って、分散データストアシステムにおいて高可用性を確保することが可能となる。以下に、本発明の実施の形態について図面を参照して説明するが、その前に、上述したBigtableのアーキテクチャについてさらに詳細に説明する。図1は、Bigtableのアーキテクチャの構成を説明するための図である。Bigtableのアーキテクチャは、1つのマスターサーバと、複数のスレーブサーバとから構成される。図1に示すデーブルAには、KeyとValueとのペアからなるデータが複数記憶されている。図1では、1つのデータをKey0value0のように表している。なお、テーブルAは、Keyによってソートされているため、Keyの範囲によって分割することが可能である。図1は、テーブルAを分割することにより、複数のスレーブサーバのそれぞれに複数の部分テーブルが割り当てられている状態を示している。図1に示す例において例えばスレーブサーバAには、Key0からKey99までの部分テーブルと、Key300からKey399までの部分テーブルとが割り当てられている。複数の部分テーブルのそれぞれを複数のスレーブサーバのうちのどのスレーブサーバに割り当てるかは、マスターサーバによって決定される。なお、図1では、100エントリ毎にテーブルAを分割した場合を一例として示しているが、エントリ数ではなくデータサイズによってテーブルAを分割することも可能である。図2は、Bigtableのアーキテクチャにおける部分テーブルの管理方法を説明するための図である。スレーブサーバAは、割り当てられた複数の部分テーブルのそれぞれを複数のAreaのそれぞれとして管理している。すなわち、スレーブサーバAは、複数のAreaのそれぞれを管理している。複数のAreaのそれぞれは、スレーブサーバAのメモリ上のバッファ以降、メモリ上バッファというと、分散ファイルシステム上のファイルである複数のソート済みKeyValueファイルとからなる。なお、以降、ソート済みKeyValueファイルのことをKVファイルという。ここでは、スレーブサーバAは、Area1およびArea2への更新情報を記憶するWALログを用いて、Area1およびArea2を管理しているものとする。ここで、図2を参照しながら、Area1に新たなデータが追加された場合のスレーブサーバAの動作について説明する。新たなデータが追加された場合のスレーブサーバAの動作は、以下に示す1-a~dの順番に実行される。なお、図2においてもこの1-a~1-dを示している。1-aスレーブサーバAは、をWALログに書き込む。なお、WALログは、分散ファイルシステム上のファイルであり、WALログへの書き込みが成功した場合には永続性が保証される。1-bスレーブサーバAは、をメモリ上バッファに書き込む。なお、スレーブサーバAに対して、ユーザから検索要求がされた場合には、メモリ上バッファとKVファイルとを読み込み、検索結果をユーザへ返却する。1-cメモリ上バッファのサイズが大きくなった場合、KVファイルとして分散ファイルシステム上へ書き出しを行う。上記の1-cの分散ファイルシステム上への書き出しは、メモリ上バッファのデータを永続化することを目的として実行されるものである。そのため、KVファイルとしての書き出しが成功した時点で、メモリ上バッファのデータは必要なくなる。そのため、スレーブサーバAは、メモリ上バッファをクリアする。なお、メモリ上バッファのサイズが大きくない場合、上記の1-cの動作は実行されない。次に、Bigtableのアーキテクチャを構成するスレーブサーバに障害が発生した場合の動作について説明する。Bigtableのアーキテクチャを構成するスレーブサーバに障害が発生した場合、複数のスレーブサーバのうち、障害が発生したスレーブサーバ以外のスレーブサーバは、マスターサーバの指示に従い、障害が発生したスレーブサーバが管理しているAreaを管理することになる。以降、この処理のことをリカバリ処理という。図3は、Bigtableのアーキテクチャにおけるリカバリ処理の概要を説明するための図である。ここでは、スレーブサーバAに障害が発生した場合について説明する。Bigtableアーキテクチャにおいてリカバリ処理は、以下に示す2-a~fの順番に実行される。なお、図3においてもこの2-a~fを示している。2-aマスターサーバは、スレーブサーバAに障害が発生したことを検知する。なお、ここでは、スレーブサーバAは、Area1~6を管理しているものとする。そのため、WALログには、Area1~6への更新情報が記憶されている。2-bマスターサーバは、リカバリ処理を行う単位にWALログを分割するための分割指示を例えばスレーブサーバBに対して行う。2-cスレーブサーバBは、マスターサーバからの分割指示に従い、スレーブサーバAのWALログを読み込み、そのWALログを例えば3つに分割した分割WALログ1~3を分散ファイルシステム上に生成する。なお、ここでは、分割WALログ1はArea1およびArea4に対応し、WALログ2はArea2およびArea6に対応し、WALログ3はArea3およびArea5に対応しているものとする。2-dスレーブサーバBは、WALログの分割が完了すると、マスターサーバへ分割完了通知を送信する。2-eスレーブサーバBから送信された分割完了通知を受信したマスターサーバは、リカバリ処理を行うスレーブサーバを選択しここでは、スレーブサーバC~Eが選択されたものとする、スレーブサーバC~Eのそれぞれにリカバリ要求を送信する。2-fマスターサーバから送信されたリカバリ要求を受信したスレーブサーバC~Eのそれぞれは、分割WALログ1~3のそれぞれを読み込むことにより、Area1~6のそれぞれの管理を開始する。ここでは、スレーブサーバCが分割WALログ1を読み込むことによってArea1およびArea4の管理を開始し、スレーブサーバDが分割WALログ2を読み込むことによってArea2およびArea6の管理を開始し、スレーブサーバEが分割WALログ3を読み込むことによってArea3およびArea5の管理を開始するものとする。ここで、スレーブサーバAのWALログのサイズを例えば2GB程度とした場合、上記2-a~fが完了するまでに、上述したように1時間程度要することとなる。ここで、WALログの上限サイズを小さくすることによってリカバリ処理に要する時間を短くすることも考えられる。WALログの上限サイズを小さくした場合、WALログの削除を頻繁に行う必要がある。WALログの削除を行うときには、メモリ上バッファをKVファイルとして分散ファイルシステム上へ書き出す必要がある。この場合、分散ファイルシステム上への書き出しが小さな単位で大量に行われることになり、リカバリ処理にかかる時間を短縮することができたとしても、検索や更新のトータルスループットが低下することが知られている。これは、分散ファイルシステムがサイズの小さなデータの書き込みや読み出しには向いていないためである。次に、本発明の実施の形態について説明する。図4は、本発明の分散データストアシステムを適用した分散KeyValueストアシステムの実施の一形態の構成を示すブロック図である。なお、本実施形態では、上述したBigtableのアーキテクチャに基づいて説明するが、Bigtableのアーキテクチャにおいて既に提供されている機能の説明は原則として省略し、本発明の特徴となる機能について主に説明する。本実施形態の分散KeyValueストアシステムは図4に示すように、マスターサーバ10と、マスターサーバと例えばネットワークスイッチによって接続されたスレーブサーバ20-1~20-nとを備えている。本実施形態においてスレーブサーバ20-1~20-nのそれぞれは、そのスレーブサーバに割り当てられた複数のArea部分テーブルを、ユーザ等によって予め決められた数の複数の分割WALログを用いて管理する。図5は、図4に示した分散KeyValueストアシステムを構成するサーバの一構成例を示すブロック図であり、aはマスターサーバ10の一構成例を示すブロック図、bはスレーブサーバ20-1の一構成例を示すブロック図である。なお、スレーブサーバ20-2~20-nも、スレーブサーバ20-1と同様の構成である。マスターサーバ10は図5aに示すように、スレーブサーバ管理部11と、障害検知部12と、リカバリ要求部13と、リバランス部14とを備えている。スレーブサーバ管理部11は、スレーブサーバ20-1~20-nのそれぞれに関する情報を記憶するスレーブサーバ管理リストを備えている。スレーブサーバ管理部11は、マスターサーバ10が起動されると、スレーブサーバ管理リストを初期化する。そして、スレーブサーバ管理部11は、スレーブサーバ20-1~20-nのそれぞれから送信された接続要求を受信する。接続要求には、スレーブサーバ20-1~20-nのそれぞれを識別するスレーブサーバ識別情報と、そのスレーブサーバのロケーション情報とが含まれている。なお、ロケーション情報は例えば、IPアドレスである。そして、スレーブサーバ管理部11は、受信した接続要求に含まれるスレーブサーバ識別情報と、ロケーション情報とを対応付けてスレーブサーバ管理リストに記憶させる。また、スレーブサーバ管理部11は、受信した接続要求の送信元のスレーブサーバに管理させる複数のAreaのそれぞれの最初のkeyStartkeyおよび最後のkeyEndkeyを含む接続応答をそのスレーブサーバへ送信する。そして、スレーブサーバ管理部11は、受信した接続要求の送信元のスレーブサーバに管理させる複数のAreaの数を示す管理数情報を、そのスレーブサーバを識別するスレーブサーバ識別情報と対応付けてスレーブサーバ管理リストに記憶させる。障害検知部12は、第1の所定時間を計測するための第1のタイマー不図示を備えている。障害検知部12は、第1のタイマーの経過時間が第1の所定時間を超える度に、スレーブサーバ管理リストに記憶されたスレーブサーバ識別情報にて識別されるスレーブサーバへ状態確認要求を送信する。状態確認要求は、スレーブサーバの稼働状態を確認するためのコマンドである。その後、障害検知部12は、状態確認要求の送信先から送信された状態応答を受信する。そして、障害検知部12は、受信した状態応答が異常を示している場合、受信した状態応答の送信元のスレーブサーバを識別するスレーブサーバ識別情報に対応するロケーション情報を、スレーブサーバ管理リストから取得する。そして、障害検知部12は、取得したロケーション情報をリカバリ要求部13へ出力する。なお、上述した状態確認要求や状態応答確認の処理は、MBurrowsTheChubbyLockServiceforLooselyCoupledDistributedSystemsOSDIに記載されている分散ロックファイルシステムの死活監視機能を利用して行ってもよい。リカバリ要求部13は、障害検知部12から出力されたロケーション情報を受け付ける。次に、リカバリ要求部13は、予め決められた数の複数の分割WALログのそれぞれを識別する複数の分割WALログ番号のうちのいずれか1つを選択する。例えば、予め決められた数が3である場合、複数の分割WALログのそれぞれは例えば、分割WALログ1、分割WALログ2、分割WALログ3のように識別される。次に、リカバリ要求部13は、スレーブサーバ管理リストに記憶されたスレーブサーバ識別情報のうち、受け付けたロケーション情報に対応するスレーブサーバ識別情報以外のスレーブサーバ識別情報の中から、対応する管理数情報が示す数が最も少ないスレーブサーバ識別情報を選択する。すなわち、リカバリ要求部13は、管理しているAreaの数が最も少ないスレーブサーバをリカバリ用スレーブサーバとして選択する。次に、リカバリ要求部13は、選択した分割WALログ番号と、受け付けたロケーション情報とを含むリカバリ要求を、選択したスレーブサーバ識別情報にて識別されるリカバリ用スレーブサーバへ送信する。そして、リカバリ要求部13は、選択したスレーブサーバ識別情報に対応する管理数情報が示す数を1つ増加させることにより、スレーブサーバ管理リストを更新する。そして、リカバリ要求部13は、複数の分割WALログ番号うち未選択の分割WALログ番号を選択し、上述した動作を繰り返し行う。なお、ここでは、リカバリ要求部13が、対応する管理数情報が示す数が最も少ないスレーブサーバ識別情報を選択する場合について説明したが、それ以外にも、ランダムに選択したり、ラウンドロビンで選択したりしてもよい。なお、リバランス部14の構成および動作については後述する。スレーブサーバ20-1は図5bに示すように、マスターサーバ接続部21と、WALログ管理部22と、リカバリ処理部23と、ロード部24と、アンロード部25と、稼働状態確認部26とを備えている。スレーブサーバ20-1~20-nのそれぞれは、マスターサーバ10のロケーションを示すマスターサーバロケーション情報を入力として起動され、初期化される。マスターサーバロケーション情報は例えば、IPアドレスや、IPアドレスを記述した分散ファイルシステム上のファイルのパス、IPアドレスが記述された分散ロックシステム上のファイルのパスなどである。分散ロックシステムについては、上述したMBurrowsTheChubbyLockServiceforLooselyCoupledDistributedSystemsOSDIに記載されている。マスターサーバ接続部21は、起動の際に入力されたマスターサーバロケーション情報を用いてマスターサーバ10へ接続要求を送信する。その後、マスターサーバ接続部21は、マスターサーバ10から送信された接続応答を受信する。そして、マスターサーバ接続部21は、受信した接続応答に含まれる複数のStartkeyおよびEndkeyをWALログ管理部22へ出力する。なお、マスターサーバ10からは通常、スレーブサーバ20-1が以前に管理していたAreaを再度管理するように要求される。そのため、マスターサーバ接続部21は、自身のWALログとKVファイルのインデックス情報等を読み込む。これにより、スレーブサーバ20-1にて複数のAreaの管理が開始される。WALログ管理部22は、マスターサーバ接続部21から出力された複数のStartkeyおよびEndkeyを受け付ける。そして、WALログ管理部22は、予め決められた分割WALログの数と、受け付けたStartKeyまたはEndKeyとから、受け付けたStartKeyおよびEndKeyにて示されるAreaが属するグループであるAreaGroupを決定する。つまり、WALログ管理部22は、スレーブサーバ20-1に割り当てられた複数のArea部分テーブルのそれぞれを複数のグループのいずれかに分類する。具体的には、WALログ管理部22はまず、StartKeyまたはEndKeyのmd5やsha1などのハッシュ値を算出する。次に、WALログ管理部22は、算出したハッシュ値を分割WALログの数で除算することで剰余を得る。そして、WALログ管理部22は、その剰余の整数部分の値に応じ、受け付けたStartKeyおよびEndKeyにて示されるAreaが属するAreaGroupを決定する。図6は、図5bに示したWALログ管理部22によって複数のグループに分類されたAreaの一例を説明するための図である。図6に示す例において、スレーブサーバ20-1は、Area1~6を管理しているものとし、予め決められた分割WALログの数を3つとしている。図6に示すように、スレーブサーバ20-1においてArea1~6のそれぞれは、Area1とArea4とがAreaGroupAに属している。同様に、Area2とArea6とがAreaGroupBに属し、Area3とArea5とがAreaGroupCに属している。そして、Area1およびArea4への更新情報は、例えば分割WALログ1に記憶され、Area2およびArea6への更新情報は、例えば分割WALログ2に記憶され、Area3およびArea5への更新情報は、例えば分割WALログ3に記憶される。つまり、複数のAreaGroupのそれぞれと、複数の分割WALログのそれぞれとが1対1に対応している。なお、ここでは、説明を簡単にするため、AreaGroupの数を3つとしたが、実際には要求されるリカバリ処理の時間に応じてAreaGroupの数を増減することが可能である。AreaGroupの数をより多くすれば、リカバリ処理に要する時間はより短くなるが、AreaGroupのサイズを大きくしすぎると分割WALログのサイズが大きくなり、同時にオープンされるファイル数が多くなる。この場合、分散ファイルシステムに負荷がかかり、結果として検索や更新のトータルスループットが向上しない。AreaGroupの数は、分散ファイルシステムにおいて同時にオープンすることが可能なファイル数に応じて決定すればよい。例えば、複数の分割WALログのそれぞれのサイズを400MBとすれば、リカバリ処理の時間を10分程度とすることができる。また、本実施形態において、複数のスレーブサーバのそれぞれが1つのWALログを用いて複数のAreaを管理している場合に想定された分散ファイルシステム上への大量の書き出しは発生しない。本実施形態では、WALログを複数の分割WALログに予め分割している。そのため、1つの分割WALログに対応するAreaの数は、WALログを予め分割していない場合に、そのWALログに対応するAreaの数に比べて少なくなるからである。例えば、1つのスレーブサーバが、3000個のAreaを1個のWALログを用いて管理している場合を考えてみる。この場合、その1個のWALログには、3000個のAreaのそれぞれへの更新情報が記憶されるため、WALログの削除を行う場合には、多くのメモリ上バッファをKVファイルとして分散ファイルシステム上へ書き出す必要がある。次に、1つのスレーブサーバが、3000個のAreaを16個の分割WALログファイルを用いて管理している場合を考えてみる。この場合、1つの分割WALログを削除する際に、メモリ上バッファをKVファイルとして分散ファイルシステム上へ書き出す対象となるAreaの数は高々200個となる。従って、1つのスレーブサーバが1つのWALログを用いてAreaを管理している場合に比べ、1つのスレーブサーバが16個の分割WALログを用いてAreaを管理している場合には小さなKVファイルができにくい。再度、図5bを参照すると、リカバリ処理部23は、マスターサーバ10から送信されたリカバリ要求を受信する。そして、リカバリ処理部23は、受信したリカバリ要求に含まれる分割WALログ番号とロケーション情報とから、分割WALログへのファイルパスを生成する。リカバリ処理部23は、分割WALログへのファイルのパスを、例えば以下のようにして生成する。なお、以下に示すファイルのパスにおいてNは、予め決められた分割WALログの数である。スレーブサーバのIPアドレスwallog1wallogスレーブサーバのIPアドレスwallogNwallogそして、リカバリ処理部23は、生成したファイルパスを用いて分割WALログを読み込み、読み込んだ分割WALログをメモリ上へ展開する。これによりメモリ上バッファが再構築され、新たなAreaの管理が開始されることになる。すなわち、リカバリの対象となったAreaに対する検索や更新が可能となる。図7は、図4~図6に示した分散KeyValueストアシステムにおけるリカバリ処理の概要を説明するための図である。ここでは、スレーブサーバ20-1に障害が発生した場合について説明する。図4~図6に示した分散KeyValueストアシステムにおいてリカバリ処理は、以下に示す3-a~cの順番に実行される。なお、図7においてもこの3-a~cを示している。3-aマスターサーバ10は、スレーブサーバ20-1に障害が発生したことを検知する。ここでは、スレーブサーバ20-1は、Area1~6を管理しているものとする。そして、分割WALログ1には、Area1およびArea4への更新情報が記憶され、分割WALログ2には、Area2およびArea6への更新情報が記憶され、分割WALログ3には、Area3およびArea5への更新情報が記憶されているものとする。3-bマスターサーバ10は、リカバリ処理を行うスレーブサーバを選択しここでは、スレーブサーバ20-2~20-4が選択されたものとする、スレーブサーバ20-2~20-4のそれぞれにリカバリ要求を送信する。3-cマスターサーバ10から送信されたリカバリ要求を受信したスレーブサーバ20-2~20-4のそれぞれは、分割WALログ1~3のそれぞれを読み込むことにより、Area1~6のそれぞれの管理を開始する。ここでは、スレーブサーバ20-2が分割WALログ1を読み込むことによってArea1およびArea4の管理を開始し、スレーブサーバ20-3が分割WALログ2を読み込むことによってArea2およびArea6を管理を開始し、スレーブサーバ20-4が分割WALログ3を読み込むことによってArea3およびArea5の管理を開始するものとする。このように、図4~図6に示した分散KeyValueストアシステムにおいては、スレーブサーバに障害が発生した場合に、図3を参照しながら説明した2-b~dの処理を行う必要がない。図8は、図5bに示したリカバリ処理部23によるリカバリ処理の実行後に複数のスレーブサーバのそれぞれが管理するAreaの一例を示す図である。なお、図8は、図7を参照しながら説明したリカバリ処理が実行された後の状態を示している。図8に示すようにスレーブサーバ20-2~20-4は、スレーブサーバ20-1が管理していたArea1~6のそれぞれを管理している。一方、スレーブサーバ20-5~20-nは、図7を参照しながら説明したリカバリ処理を実行していないため、スレーブサーバ20-1が管理していたArea1~6が管理対象として追加されていない。つまり、リカバリ処理を実行したかどうかにより、複数のスレーブサーバ間で管理しているAreaの数が不均一になる場合がある。図8においては、管理するAreaの数の差は2であるが、実際には数百程度の差が生じることになる。ここで、再度、図5aを参照すると、リバランス部14は、第2の所定時間を計測するための第2のタイマー不図示を備えている。リバランス部14は、第2のタイマーの経過時間が第2の所定時間が超える度に、スレーブサーバ管理リストに記憶された複数のスレーブサーバ識別情報のそれぞれに対応する管理数情報が示す数が、複数のスレーブサーバ識別情報間で均一化されているかどうかを判定する。すなわち、リバランス部14は、スレーブサーバ管理リストに記憶された複数のスレーブサーバ識別情報のそれぞれにて識別される複数のスレーブサーバ間で、管理しているAreaの数が均一化されているかどうかを判定する均一化判定を実行する。均一化判定のロジックとしては、例えば以下の2つが考えられる。以下の説明におけるαおよびβは、本実施形態の分散KeyValueストアシステムのユーザ等が予め決めておく。管理しているAreaの数が最大N1個とするのスレーブサーバと、管理しているAreaの数が最小N2個とするのスレーブサーバとにおいて、N1-N2≦αを満たす場合、リバランス部14は、均一化されていると判定する。管理しているAreaの数が最大N3個とするのスレーブサーバと、管理しているAreaの数が最小N4個とするのスレーブサーバとにおいて、N3/N4≦βを満たす場合、リバランス部14は、均一化されているものとする。均一化判定の結果、均一化されていないと判定した場合、リバランス部14は、対応する管理数情報が示す数が最も多いスレーブサーバ識別情報と、最も少ないスレーブサーバ識別情報とをスレーブサーバ管理リストから選択する。すなわち、リバランス部14は、管理しているAreaの数が最も多いスレーブサーバを最多スレーブサーバとして選択し、管理しているAreaの数が最も少ないスレーブサーバを最少スレーブサーバとして選択する。そして、リバランス部14は、対応する管理数情報が示す数が最も多いスレーブサーバ識別情報にて識別される最多スレーブサーバへアンロード要求を送信する。なお、アンロード要求は、スレーブサーバが管理しているAreaのうちのいずれかを管理対象から除外することを要求するためのコマンドである。その後、リバランス部14は、最多スレーブサーバから送信されたアンロード完了通知を受信する。アンロード完了通知は、Areaを管理対象から除外したことを示す通知であり、管理対象から除外したAreaのKVファイルへのパスを示すパス情報を含む。そして、リバランス部14は、対応する管理数情報が示す数が最も少ないスレーブサーバ識別情報にて識別される最少スレーブサーバへロード要求を送信する。ロード要求は、新たなAreaの管理を開始させるためのコマンドであり、受信したアンロード完了通知に含まれるパス情報を含む。その後、リバランス部14は、最少スレーブサーバから送信されたロード完了通知を受信する。ロード完了通知は、新たなAreaの管理を開始したことを示す通知である。そして、リバランス部14は、最少スレーブサーバを識別するスレーブサーバ識別情報に対応する管理数情報が示す数を1つ増加させ、最多スレーブサーバを識別するスレーブサーバ識別情報に対応する管理数情報が示す数を1つ減少させることにより、スレーブサーバ管理リストを更新する。再度、図5bを参照すると、ロード部24は、マスターサーバ10から送信されたロード要求を受信する。そして、ロード部24は、受信したロード要求に含まれるKVファイルのパス情報から、Areaのインデックス情報等を読み込む。これにより、スレーブサーバ20-1にて新たなAreaの管理が開始される。そして、ロード部24は、ロード完了通知をマスターサーバ10へ送信する。アンロード部25は、マスターサーバ10から送信されたアンロード要求を受信する。そして、アンロード部25は、スレーブサーバ20-1が管理しているAreaのうちのいずれか1つを選択する。次に、アンロード部25は、選択したAreaのメモリ上バッファをKVファイルとして分散ファイルシステム上へ書き出し、スレーブサーバ20-1による管理対象から、選択したAreaを除外する。そして、アンロード部25は、選択したAreaのKVファイルのパス情報を含むアンロード完了通知をマスターサーバ10へ送信する。なお、アンロード部25が、スレーブサーバ20-1にて管理されているAreaのうちのいずれかを選択する方法としては例えば、以下のiおよびiiに示すような方法が挙げられる。iランダムに1つ選択する。ii属しているAreaの数が最も多いAreaGroupを選択し、選択したAreaGroupからランダムに1つ選択する。上記のiに示した方法は、新たなAreaが割り当てられた複数のスレーブサーバ間で管理するAreaの数が均一になることを目的としている。上記のiiは、リカバリフローが繰り返し行われた場合に、一部のAreaGroupのみ、そのサイズが大きくなって、リカバリ処理の時間が長くなるのを回避することを目的としている。稼働状態確認部26は、マスターサーバ10から送信された状態確認要求を受信する。そして、稼働状態確認部26は、スレーブサーバ20-1の稼働状態を確認する。確認の結果、スレーブサーバ20-1の稼働状態が異常である場合、例えばスレーブサーバ20-1に障害が発生している場合、異常を示す状態応答をマスターサーバ10へ送信する。一方、確認の結果、スレーブサーバ20-1の稼働状態が正常である場合、正常を示す状態応答をマスターサーバ10へ送信する。以下に、上記のように構成された分散KeyValueストアシステムの動作について説明する。まず、図4~図8に示した分散KeyValueストアシステムにおいてスレーブサーバ20-1~20-nのそれぞれが起動したときの動作について説明する。図9は、図4~図8に示した分散KeyValueストアシステムにおいてスレーブサーバ20-1~20-nのそれぞれが起動したときの動作を説明するためのフローチャートである。なお、マスターサーバ10は既に起動済みであるものとする。スレーブサーバ20-1~20-nのそれぞれは、マスターサーバロケーション情報を入力として起動されステップS1、初期化されるステップS2。次に、マスターサーバ接続部21は、そのマスターサーバロケーション情報を用いてマスターサーバ10へ接続要求を送信するステップS3。スレーブサーバ管理部11は、スレーブサーバ20-1~20-nのそれぞれから送信された接続要求を受信するステップS4。次に、スレーブサーバ管理部11は、受信した接続要求に含まれるスレーブサーバ識別情報と、ロケーション情報とを対応付けてスレーブサーバ管理リストに記憶させるステップS5。そして、スレーブサーバ管理部11は、受信した接続要求の送信元のスレーブサーバに管理させる複数のAreaのそれぞれのStartkeyおよびEndkeyを含む接続応答を、そのスレーブサーバへ送信するステップS6。また、スレーブサーバ管理部11は、受信した接続要求の送信元のスレーブサーバに管理させる複数のAreaの数を示す管理数情報と、そのスレーブサーバを識別するスレーブサーバ識別情報とを対応付けてスレーブサーバ管理リストに記憶させる。マスターサーバ接続部21は、マスターサーバ10から送信された接続応答を受信するステップS7。そして、マスターサーバ接続部21は、自身のWALログとKVファイルのインデックス情報等を読み込む。これにより、Areaの管理が開始されるステップS8。次に、図4~図8に示した分散KeyValueストアシステムにおいてスレーブサーバ20-1~20-nのそれぞれに障害が発生したのを検知する動作について説明する。図10は、図4~図8に示した分散KeyValueストアシステムにおいてスレーブサーバ20-1~20-nのそれぞれに障害が発生したのを検知する動作を説明するためのフローチャートである。障害検知部12は、第1のタイマーをスタートさせるステップS21次に、障害検知部12は、第1のタイマーの経過時間が第1の所定時間を超えたかどうかを確認するステップS22。ステップS22における確認の結果、第1のタイマーの経過時間が第1の所定時間を超えていない場合、ステップS22の動作へ遷移する。すなわち、障害検知部12は、第1のタイマーの経過時間が第1の所定時間を超えたかどうかの確認を継続する。一方、ステップS22における確認の結果、第1のタイマーの経過時間が第1の所定時間を超えている場合、障害検知部12は、第1のタイマーをリセットし、再スタートさせるステップS23。次に、障害検知部12は、スレーブ管理リストに記憶されているスレーブサーバ識別情報のうちのいずれか1つを選択するステップS24。そして、障害検知部12は、選択したスレーブサーバ識別情報にて識別されるスレーブサーバへ状態確認要求を送信するステップS25。稼働状態確認部26は、マスターサーバ10から送信された状態確認要求を受信するステップS26。次に、稼働状態確認部26は、自身が備えられたスレーブサーバの稼働状態を確認する。そして、稼働状態確認部26は、確認した稼働状態に応じた内容の状態応答をマスターサーバ10へ送信するステップS27。障害検知部12は、スレーブサーバ20-1から送信された状態応答を受信するステップS28。次に、障害検知部12は、受信した状態応答が正常を示しているかどうかを確認するステップS29。ステップS29における確認の結果、受信した状態応答が正常を示している場合、障害検知部12は、スレーブ管理リストに記憶されているすべてのスレーブサーバ識別情報を選択済みかどうかを確認するステップS30。ステップS30における確認の結果、スレーブ管理リストに記憶されているすべてのスレーブサーバ識別情報を選択済みでない場合、障害検知部12は、スレーブ管理リストに記憶されているスレーブサーバ識別情報のうち未選択のスレーブサーバ識別情報のいずれか1つを選択するステップS31。そして、ステップS25の動作へ遷移する。一方、ステップS30における確認の結果、スレーブ管理リストに記憶されているすべてのスレーブサーバ識別情報を選択済みである場合、ステップS22の動作へ遷移する。ここで、ステップS29における確認の結果、受信した状態応答が異常を示している場合、障害検知部12は、選択したスレーブサーバ識別情報に対応するロケーション情報を、スレーブサーバ管理リストから取得する。次に、障害検知部12は、取得したロケーション情報をリカバリ要求部13へ出力するステップS32。そして、ステップS30の動作へ遷移する。次に、図4~図8に示した分散KeyValueストアシステムにおいてリカバリ処理を行うときの動作について説明する。図11は、図4~図8に示した分散KeyValueストアシステムにおいてリカバリ処理を行うときの動作を説明するためのフローチャートであり、aはマスターサーバ10の動作を説明するためのフローチャート、bはスレーブサーバ20-1~20-nのそれぞれの動作を説明するためのフローチャートである。まず、図11aを参照しながら、マスターサーバ10の動作について説明する。リカバリ要求部13は、障害検知部12から出力されたロケーション情報を受け付けたかどうかを確認するステップS41。ステップS41における確認の結果、障害検知部12から出力されたロケーション情報を受け付けていない場合、ステップS41の動作へ遷移する。すなわち、リカバリ要求部13は、障害検知部12から出力されたロケーション情報を受け付けたかどうかの確認を継続する。一方、ステップS41における確認の結果、障害検知部12から出力されたロケーション情報を受け付けた場合、リカバリ要求部13は、予め決められた数の複数の分割WALログのそれぞれを識別する複数の分割WALログ番号のうちのいずれか1つを選択する。ステップS42。次に、リカバリ要求部13は、スレーブサーバ管理リストに記憶されたスレーブサーバ識別情報のうち、受け付けたロケーション情報に対応するスレーブサーバ識別情報以外のスレーブサーバ識別情報の中から、対応する管理数情報が示す数が最も少ないスレーブサーバ識別情報を選択するステップS43。次に、リカバリ要求部13は、選択した分割WALログ番号と、受け付けたロケーション情報とを含むリカバリ要求を、選択したスレーブサーバ識別情報にて識別されるリカバリ用スレーブサーバへ送信するステップS44。次に、リカバリ要求部13は、選択したスレーブサーバ識別情報に対応する管理数情報が示す数を1つ増加させることにより、スレーブサーバ管理リストを更新するステップS45。次に、リカバリ要求部13は、予め決められた数の複数の分割WALログのそれぞれを識別する複数の分割WALログ番号のすべてを選択済みかどうかを確認するステップS46。ステップS46における確認の結果、予め決められた数の複数の分割WALログのそれぞれを識別する複数の分割WALログ番号のすべてを選択済みである場合、ステップS41の動作へ遷移する。一方、ステップS46における確認の結果、予め決められた数の複数の分割WALログのそれぞれを識別する複数の分割WALログ番号のすべてを選択済みでない場合、リカバリ要求部13は、複数の分割WALログ番号のうち未選択の分割WALログ番号を選択するステップS47。そして、ステップS43の動作へ遷移する。次に、図11bを参照しながら、スレーブサーバ20-1~20-nのそれぞれの動作について説明する。リカバリ処理部23は、マスターサーバ10から送信されたリカバリ要求を受信したかどうかを確認するステップS61。ステップS61における確認の結果、マスターサーバ10から送信されたリカバリ要求を受信していない場合、ステップS61の動作へ遷移する。すなわち、リカバリ処理部23は、マスターサーバ10から送信されたリカバリ要求を受信したかどうかの確認を継続する。一方、ステップS61における確認の結果、マスターサーバ10から送信されたリカバリ要求を受信した場合、リカバリ処理部23は、受信したリカバリ要求に含まれる分割WALログ番号とロケーション情報とから、分割WALログへのファイルパスを生成するステップS62。次に、リカバリ処理部23は、生成したファイルバスを用いて分割WALログを読み込むステップS63。次に、リカバリ処理部23は、読み込んだ分割WALログをメモリ上に展開するステップS64。これにより、新たなAreaの管理が開始されることになる。そして、ステップS61の動作へ遷移する。次に、図4~図8に示した分散KeyValueストアシステムにおいて管理するAreaの数を複数のスレーブサーバ間で均一化するときの動作について説明する。図12は、図4~図8に示した分散KeyValueストアシステムにおいて管理するAreaの数を複数のスレーブサーバ間で均一化するときのマスターサーバ10の動作を説明するためのフローチャートである。また、図13は、図4~図8に示した分散KeyValueストアシステムにおいて管理するAreaの数を複数のスレーブサーバ間で均一化するときのスレーブサーバ20-1~20-nのそれぞれの動作を説明するためのフローチャートであり、aはアンロード要求を受信したスレーブサーバの動作を説明するためのフローチャート、bはロード要求を受信したスレーブサーバの動作を説明するためのフローチャートである。まず、図12を参照しながら、分散KeyValueストアシステムにおいて管理するAreaの数を複数のスレーブサーバ間で均一化するときのマスターサーバ10の動作について説明する。リバランス部14は、第2のタイマーをスタートさせるステップS81。次に、リバランス部14は、第2のタイマーの経過時間が第2の所定時間を超えたかどうかを確認するステップS82。ステップS82における確認の結果、第2のタイマーの経過時間が第2の所定時間を超えていない場合、ステップS82の動作へ遷移する。すなわち、リバランス部14は、第2のタイマーの経過時間が第2の所定時間を超えたかどうかの確認を継続する。一方、ステップS82における確認の結果、第2のタイマーの経過時間が第2の所定時間を超えている場合、リバランス部14は、第2のタイマーをリセットし、再スタートさせるステップS83。次に、リバランス部14は、スレーブサーバ管理リストに記憶された複数のスレーブサーバ識別情報のそれぞれに対応する管理数情報が示す数が、複数のスレーブサーバ識別情報間で均一化されているかどうかを判定するステップS84。ステップS84における判定の結果、均一化されていると判定された場合、ステップS82の動作へ遷移する。一方、ステップS84における判定の結果、均一化されていないと判定された場合、リバランス部14は、対応する管理数情報が示す数が最も多いスレーブサーバ識別情報と、最も少ないスレーブサーバ識別情報とをスレーブサーバ管理リストから選択するステップS85。次に、リバランス部14は、対応する管理数情報が示す数が最も多いスレーブサーバ識別情報にて識別される最多スレーブサーバへアンロード要求を送信するステップS86。次に、リバランス部14は、アンロード完了通知を受信したかどうかを確認するステップS87。ステップS87における確認の結果、アンロード完了通知を受信していない場合、ステップS87の動作へ遷移する。すなわち、リバランス部14は、アンロード完了通知を受信したかどうかの確認を継続する。一方、ステップS87における確認の結果、アンロード完了通知を受信した場合、リバランス部14は、対応する管理数情報が示す数が最も少ないスレーブサーバ識別情報にて識別される最少スレーブサーバへロード要求を送信するステップS88。次に、リバランス部14は、ロード完了通知を受信したかどうかを確認するステップS89。ステップS89における確認の結果、ロード完了通知を受信していない場合、ステップS89の動作へ遷移する。すなわち、リバランス部14は、ロード完了通知を受信したかどうかの確認を継続する。一方、ステップS89における確認の結果、ロード完了通知を受信した場合、最少スレーブサーバを識別するスレーブサーバ識別情報に対応する管理数情報が示す数を1つ増加させ、最多スレーブサーバを識別するスレーブサーバ識別情報に対応する管理数情報が示す数を1つ減少させることにより、スレーブサーバ管理リストを更新する。ステップS90。そして、ステップS82の動作へ遷移する。次に、図13aを参照しながら、アンロード要求を受信したスレーブサーバの動作について説明する。アンロード部25は、マスターサーバ10から送信されたアンロード要求を受信したかどうかを確認するステップS101。ステップS101における確認の結果、マスターサーバ10から送信されたアンロード要求を受信していない場合、ステップS101の動作へ遷移する。すなわち、アンロード部25は、マスターサーバ10から送信されたアンロード要求を受信したかどうかの確認を継続する。一方、ステップS101における確認の結果、マスターサーバ10から送信されたアンロード要求を受信した場合、アンロード部25は、当該スレーブサーバにて管理しているAreaのうちのいずれかを選択するステップS102。次に、アンロード部25は、選択したAreaのメモリ上バッファを分散ファイルシステム上へKVファイルとして書き出すステップS103。そして、アンロード部25は、選択したAreaのKVファイルのパス情報を含むアンロード完了通知をマスターサーバ10へ送信するステップS104。そして、ステップS101の動作へ遷移する。次に、図13bを参照しながら、ロード要求を受信したスレーブサーバの動作について説明する。ロード部24は、マスターサーバ10から送信されたロード要求を受信したかどうかを確認するステップS121。ステップS121における確認の結果、マスターサーバ10から送信されたロード要求を受信していない場合、ステップS121の動作へ遷移する。すなわち、ロード部24は、マスターサーバ10から送信されたロード要求を受信したかどうかの確認を継続する。一方、ステップS121における確認の結果、マスターサーバ10から送信されたロード要求を受信した場合、ロード部24は、受信したロード要求に含まれるKVファイルのパス情報から、Areaのインデックス情報等を読み込むステップS122。これにより、新たなAreaの管理が開始される。次に、ロード部24は、ロード完了通知をマスターサーバ10へ送信するステップS123。そして、ステップS121の動作へ遷移する。このように本実施形態において、スレーブサーバ20-1~20-nのそれぞれは、当該スレーブサーバが管理している複数の部分テーブルのそれぞれを複数のグループのいずれかに分類し、複数のグループのそれぞれと、WALログを複数のファイルに分割することによって生成された、複数のグループのそれぞれに属する部分テーブルへの更新情報を記憶する複数の分割WALログのそれぞれとを対応付けるWALログ管理部22を有する。また、マスターサーバ10は、複数のスレーブサーバのそれぞれに障害が発生したことを検知する障害検知部12を有する。また、マスターサーバ10は、障害検知部12にて複数のスレーブサーバのいずれかに障害が発生したことが検知されると、当該障害が発生したスレーブサーバの複数の分割WALログのそれぞれを選択し、選択された分割WALログに対応するグループに属する部分テーブルを管理させるスレーブサーバを、複数のスレーブサーバのうち、当該障害が発生したスレーブサーバ以外のスレーブサーバの中からリカバリ用スレーブサーバとして選択するリカバリ要求部13を有する。そして、スレーブサーバ20-1~20-nのそれぞれは、リカバリ要求部13にて当該スレーブサーバがリカバリ用スレーブサーバとして選択された場合、選択された分割WALログを読み込むことにより、当該選択された分割WALログに対応するグループに属する部分テーブルの管理を開始するリカバリ処理部23を有する。これにより、複数のスレーブサーバのそれぞれに障害が発生した場合に、その障害が発生したスレーブサーバのWALログを読み込んで分割する必要がない。従って、分散データストアシステムにおいて高可用性を確保することが可能となる。また、本実施形態において、マスターサーバ10は、複数のスレーブサーバのそれぞれが管理している複数の部分テーブルの数が、当該複数のスレーブサーバ間で均一化されているかどうかを判定する均一化判定を実行するリバランス部14を有する。リバランス部14は、均一化判定において均一化されていないと判定した場合、複数のスレーブサーバの中から、管理している部分テーブルの数が最多のスレーブサーバを最多スレーブサーバとして選択するとともに、管理している部分テーブルの数が最少のスレーブサーバを最少スレーブサーバとして選択する。そして、スレーブサーバ20-1~20-nのそれぞれは、リバランス部14にて当該スレーブサーバが最多スレーブサーバとして選択された場合、当該スレーブサーバにて管理している複数の部分テーブルのうちのいずれかを選択し、選択した部分テーブルを管理対象から除外するアンロード部25を有する。また、スレーブサーバ20-1~20-nのそれぞれは、リバランス部14にて当該スレーブサーバが最少スレーブサーバとして選択された場合、上記の管理対象から除外された部分テーブルを、当該スレーブサーバが管理する部分テーブルとするロード部24を有する。これにより、スレーブサーバ20-1~20-nのそれぞれか管理する複数の部分テーブルの数が均一化される。従って、検索や更新などのオペレーションに対するスケーラビリティが向上する。また、分散KeyValueストアシステムにおける負荷分散が実現できるとともに、検索や更新などのオペレーションの際に特定のスレーブサーバがボトルネックとなるのを回避することができる。