(57)【特許請求の範囲】
【請求項１】
クラスタを構成する複数のノードそれぞれが、処理を担当するデータを、原本データまたは前記原本データの複製である複製データとして保持する分散処理システムの前記ノードであって、
前記ノードそれぞれが物理的に設置された地域を示す位置情報と、当該地域に設置された前記ノードの識別子とに対応付けて、前記ノードそれぞれが処理を担当するデータが、前記原本データ、または、当該原本データを保持するノードとは異なる地域に設置されたノードに配置される前記複製データとして格納されるノード管理情報、が記憶される記憶部と、
前記位置情報に対応付けた前記ノードそれぞれの、所定時刻における故障確率を示す故障確率情報を受け付け、
前記原本データを保持するノードについて、前記故障確率情報を参照し、前記故障確率が所定の閾値を超えるノードを救済ノードとして抽出し、前記抽出した救済ノードが保持する原本データに対応する複製データを保持するノードを、前記ノード管理情報を参照して検出し、前記検出した複製データを保持するノードのうち、前記故障確率情報を参照し、前記故障確率が最も低いノードを交換先ノードとして決定し、
前記救済ノードと前記交換先ノードとの間で、前記原本データを処理する機能と前記複製データを処理する機能とを交換するデータ救済部と、
を備えることを特徴とするノード。
【請求項２】
クラスタを構成する複数のノードそれぞれが、処理を担当するデータを、原本データまたは前記原本データの複製である複製データとして保持する分散処理システムにおける前記ノードのデータ救済方法であって、
前記ノードは、
前記ノードそれぞれが物理的に設置された地域を示す位置情報と、当該地域に設置された前記ノードの識別子とに対応付けて、前記ノードそれぞれが処理を担当するデータが、前記原本データ、または、当該原本データを保持するノードとは異なる地域に設置されたノードに配置される前記複製データとして格納されるノード管理情報、が記憶される記憶部を備えており、
前記位置情報に対応付けた前記ノードそれぞれの、所定時刻における故障確率を示す故障確率情報を受け付けるステップと、
前記原本データを保持するノードについて、前記故障確率情報を参照し、前記故障確率が所定の閾値を超えるノードを救済ノードとして抽出し、前記抽出した救済ノードが保持する原本データに対応する複製データを保持するノードを、前記ノード管理情報を参照して検出し、前記検出した複製データを保持するノードのうち、前記故障確率情報を参照し、前記故障確率が最も低いノードを交換先ノードとして決定するステップと、
前記救済ノードと前記交換先ノードとの間で、前記原本データを処理する機能と前記複製データを処理する機能とを交換するステップと、
を実行することを特徴とするデータ救済方法。
【請求項３】
請求項２に記載のデータ救済方法を、コンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタ構成の高可用システムを利用したサービスにおいて、大規模な災害等が発生した場合でもサービスを継続するために、災害等により影響を受けないようにデータを救済する技術に関する。
【背景技術】
【０００２】
従来のクラスタ構成の高可用システムでは、サービスの利用状況や負荷変動に応じて、クラスタを構成する各サーバ（以下、「ノード」と称する場合がある。）を増設・減設することにより、動的な計算資源の最適化（保守増減設）が実行される。例えば、データの原本（以下、「原本データ」と称する場合がある。）を保持するサーバが故障した場合や、故障の可能性が高い場合に、以下の処理手順（保守減設）が実行される。
【０００３】
（１）その原本データの複製（以下、「複製データ」と称する場合がある。）を、原本データに昇格させる。
（２）原本データの複製（複製データ）を、予め設定された冗長数を保つように再配置する。
（３）故障したサーバ（故障の可能性の高いサーバ）をクラスタから切り離す。
このような保守減設を行うことにより、原本データを救済し、サービスを継続させている。なお、故障の可能性が高いサーバは、ハードウェアの劣化や異常発熱による温度上昇などの進行性の障害がある場合に検出されたり、ＳＮＭＰ（Simple Network Management Protocol）ｔｒａｐや、ｓｙｓｌｏｇ等による障害情報や警報等を取得することにより検出されたりする。
【０００４】
しかしながら、大規模な災害等が発生した場合において、冗長化している原本データと複製データとが、同じ拠点（データセンタが存在するエリア（以下、「データセンタエリア」と称する場合がある。））に設置されているときには、原本データと複製データとが同時に失われてしまうことが起こり得る。そこで、冗長化している原本データと複製データとが、同時に失われることがないように、原本データと複製データとを異なる拠点のサーバに配置するクラスタ構成の高可用システムが提案されている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−０８２１２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
前記した特許文献１に記載の高可用システムでは、大規模な災害等が発生した場合においても、原本データか複製データのいずれかは失わず、サービスを継続することができる。しかし、大規模災害等に伴う大規模障害が発生し原本データが消失すると、サーバの故障検知の処理を実行し、故障したサーバについては、前記した保守減設の処理を実行することに加え、正常性確認等のためサービス自体を利用するリクエストが増加すること等により、トラヒックが増加する。これにより、システムの性能が不足してしまう上に、遠隔地のサーバへのデータの複製や再配置により、ネットワークコスト（通信コストやインフラコスト）が増大することや、冗長化を実現したシステム（冗長化システム）を再構成するまでの遅延が発生することが課題となる。
また、例えば、緊急地震速報のように、災害の予報から災害までの間が短く、突発的にデータ救済を実施しなければならない場合、保守減設のように複雑な手順を追うと救済が間に合わないことも課題となる。
【０００７】
このような背景を鑑みて本発明がなされたのであり、本発明は、大規模災害等に伴う大規模障害が発生した場合においても、ネットワークコストの増加や、システム再構成の遅延を抑えた上で、原本データを救済することができる、ノード、データ救済方法およびプログラムを提供することを課題とする。
【課題を解決するための手段】
【０００８】
前記した課題を解決するため、請求項１に記載の発明は、クラスタを構成する複数のノードそれぞれが、処理を担当するデータを、原本データまたは前記原本データの複製である複製データとして保持する分散処理システムの前記ノードであって、前記ノードそれぞれが物理的に設置された地域を示す位置情報と、当該地域に設置された前記ノードの識別子とに対応付けて、前記ノードそれぞれが処理を担当するデータが、前記原本データ、または、当該原本データを保持するノードとは異なる地域に設置されたノードに配置される前記複製データとして格納されるノード管理情報、が記憶される記憶部と、前記位置情報に対応付けた前記ノードそれぞれの、所定時刻における故障確率を示す故障確率情報を受け付け、前記原本データを保持するノードについて、前記故障確率情報を参照し、前記故障確率が所定の閾値を超えるノードを救済ノードとして抽出し、前記抽出した救済ノードが保持する原本データに対応する複製データを保持するノードを、前記ノード管理情報を参照して検出し、前記検出した複製データを保持するノードのうち、前記故障確率情報を参照し、前記故障確率が最も低いノードを交換先ノードとして決定し、前記救済ノードと前記交換先ノードとの間で、前記原本データを処理する機能と前記複製データを処理する機能とを交換するデータ救済部と、を備えることを特徴とするノードとした。
【０００９】
また、請求項２に記載の発明は、クラスタを構成する複数のノードそれぞれが、処理を担当するデータを、原本データまたは前記原本データの複製である複製データとして保持する分散処理システムにおける前記ノードのデータ救済方法であって、前記ノードが、前記ノードそれぞれが物理的に設置された地域を示す位置情報と、当該地域に設置された前記ノードの識別子とに対応付けて、前記ノードそれぞれが処理を担当するデータが、前記原本データ、または、当該原本データを保持するノードとは異なる地域に設置されたノードに配置される前記複製データとして格納されるノード管理情報、が記憶される記憶部を備えており、前記位置情報に対応付けた前記ノードそれぞれの、所定時刻における故障確率を示す故障確率情報を受け付けるステップと、前記原本データを保持するノードについて、前記故障確率情報を参照し、前記故障確率が所定の閾値を超えるノードを救済ノードとして抽出し、前記抽出した救済ノードが保持する原本データに対応する複製データを保持するノードを、前記ノード管理情報を参照して検出し、前記検出した複製データを保持するノードのうち、前記故障確率情報を参照し、前記故障確率が最も低いノードを交換先ノードとして決定するステップと、前記救済ノードと前記交換先ノードとの間で、前記原本データを処理する機能と前記複製データを処理する機能とを交換するステップと、を実行することを特徴とするデータ救済方法とした。
【００１０】
このようにすることで、例えば、大規模災害等に伴う大規模障害が発生する前に、故障確率が所定の閾値を超えるノードについては、原本データを処理する機能と複製データを処理する機能とを異なる地域のノード間で交換しておくため、その後大規模障害が発生した場合でも、原本データを消失することなく処理を継続することができる。また、原本データを処理する機能と複製データを処理する機能とを交換するだけであるため、当該データについて複製や再配置をする必要がないため、ネットワークコストの増加や、システム再構成の遅延を抑えた上で、原本データを救済することができる。
【００１１】
請求項３に記載の発明は、請求項２に記載のデータ救済方法を、コンピュータに実行させるためのプログラムとした。
【００１２】
このようなプログラムによれば、請求項２に記載のデータ救済方法を、一般的なコンピュータで実現することができる。
【発明の効果】
【００１３】
本発明によれば、大規模災害等に伴う大規模障害が発生した場合においても、ネットワークコストの増加や、システム再構成の遅延を抑えた上で、原本データを救済する、ノード、データ救済方法およびプログラムを提供することができる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態に係るノードを含む分散処理システムの全体構成を示す図である。
【図２】本実施形態に係るノードを含む分散処理システムの処理概要を説明するための図である。
【図３】本実施形態に係るノードの構成例を示す機能ブロック図である。
【図４】本実施形態に係るノード管理テーブルのデータ構成例を示す図である。
【図５】本実施形態に係る死活監視テーブルのデータ構成例を示す図である。
【図６】本実施形態に係る故障確率情報のデータ構成例を示す図である。
【図７】本実施形態に係るノードが実行するデータ救済処理の流れを示すフローチャートである。
【図８】コンシステントハッシュに基づくデータ管理を行う分散処理システムの各ノードをＩＤ空間上に配置した場合に、原本データと複製データの両方が消失する例を示す図である。
【図９】比較例の分散処理システムが行う、ノード参加時のＩＤ空間におけるノード挿入位置決定処理の流れを示すフローチャートである。
【図１０】比較例の分散処理システムが行う、ノード参加時のＩＤ空間におけるノード挿入位置決定処理を説明するための図である。
【発明を実施するための形態】
【００１５】
＜比較例の分散処理システム＞
まず、本実施形態に係るクラスタ構成の高可用システム（以下、「分散処理システム」ともいう。）の比較例として、前記した特許文献１に係る分散処理システムについて説明する。
【００１６】
特許文献１に係る分散処理システムでは、クラスタを構成する各サーバ（以下、「ノード」と称する場合がある。）が担当するデータをコンシステントハッシュ法に基づき決定する。具体的には、コンシステントハッシュ法では、ノードとデータの双方にＩＤ（IDentifier）を割り当てる。そして、各ノードがコンシステントハッシュのＩＤ空間（以下、単に「ＩＤ空間」と称する場合がある。）にマッピングされることで、各ノードは自身が担当するハッシュＩＤの範囲（「担当領域」ともいう。）を持つ。データを処理する際には、そのデータを一意に特定するｋｅｙ情報をハッシュ関数にかけ、導出されたコンシステントハッシュのＩＤ空間上の位置から所定の方法（例えば、時計回り）に進んで最初に遭遇するノードが、そのデータの処理を担当するノード（原本データを保持するノード）となる。また、複製データは、ＩＤ空間上で時計回り（若しくは、反時計回り）に隣のノードに作成する（冗長数が「２」の場合）。冗長数が「３」以上の場合には、さらに時計回りに隣のノードに、というように複製データを作成していく。なお、冗長数は、原本データを保持するノードと複製データを保持するノードとを合わせた数である。
このようにすることにより、原本データを保持するノードが故障等の理由によりクラスタから離脱しても、そのデータへの問い合わせを、複製データを保持するノードに振り分けることで、処理を継続することが可能となる。
【００１７】
上記のような、コンシステントハッシュ法によるデータ管理手法は、クラスタを構成するノードの追加や離脱に伴うデータの移行が全データに対する一部のデータに限られるため、クラスタ構成の動的な変更（ノードの追加・離脱）が頻繁に起こるシステムに対して有効である。また、クラスタを構成するノードの障害に備えて、原本データを保持するノード以外の１つ以上のノードに対して複製データを保持させることで、耐故障性を高めている。しかしながら、ノードの物理的な配置（エリア等の位置情報）を考慮しないと、大規模災害等による大規模故障が発生した場合、該当データを保持したすべてのノードに障害が同時に発生してしまう可能性がある。以下、具体的に説明する。
【００１８】
図８は、コンシステントハッシュに基づくデータ管理を行う分散処理システムの各ノードを、物理的に配置した例を示している。図８（ａ）は、大規模災害等が発生する前の状態を示し、図８（ｂ）は、大規模災害等が発生した後の状態を示している。図８（ａ）に示すように、コンシステントハッシュのＩＤ空間上に、日本全国の各拠点（データセンタエリア）に属する複数のノードを配置し、クラスタを構成している。
【００１９】
ここで、関東エリアにおいて、大規模災害等が発生した場合、コンシステントハッシュのＩＤ空間上の関東エリアのノードが故障し、ＩＤ空間から離脱する。このとき、図８に示すような通常のデータ管理手法では、ノードの物理的な配置（エリア等の位置情報）が考慮されていないため、同じ関東エリアのノードが隣り合うことが想定され、図８（ｂ）に示すように、原本データもその複製データも同時に失われる可能性がある（冗長数「２」の場合）。
このように、冗長化している原本データと複製データとが、同時に失われることがないように、原本データと複製データとを異なる拠点のサーバに配置する手法が、特許文献１に係る分散処理システムで提案されている。
【００２０】
特許文献１に係る分散処理システムでは、大規模災害等に伴う大規模障害が発生し、コンシステントハッシュのＩＤ空間上で連続するＭ個（Ｍ≧２，Ｍは「冗長数」）のノードが同時に離脱した場合においても、原本データおよび複製データの両方が消失することを防ぐため、少なくともＭ−Ｘ個は、新たに挿入するノードの拠点（データセンタエリア）と異なる拠点のノードに複製データを配置するようにして、ＩＤ空間へのノード挿入位置決定処理を実行する。ここで、Ｘ（１≦Ｘ＜Ｍ）は、あるデータ（原本データおよび複製データの合計Ｍ個）について大規模災害等の大規模障害で同時に失われて良いと設定するデータ数である。なお、Ｍ−Ｘ個は、大規模障害後でも失われない、拠点が異なるノードの数に相当する。
【００２１】
以下、図９および図１０を参照して、特許文献１に係る分散処理システムにおける、ノード挿入位置決定処理を説明する。
図９は、特許文献１に係る分散処理システムが行う、ノード参加時のＩＤ空間におけるノード挿入位置決定処理の流れを示すフローチャートである。また、図１０は、ノード参加時のＩＤ空間におけるノード挿入位置決定処理を説明するための図である。なお、このノード挿入位置決定処理は、特許文献１に係る分散処理システムの各ノードから選出された特定のノード（特権ノード）が行ってもよいし、分散処理システムの全体を管理する管理装置等が行ってもよいが、ここでは、当該分散処理システムを構成する特権ノード（以下、単に「ノード」という。）が行うものとして説明する。
【００２２】
まず、拠点（データセンタエリア）毎に、クラスタを構成するすべてのノードの数（一つの物理ノードに複数の仮想ノードを割り当てている場合には、仮想ノードの数）を合計した値を算出する（ステップＳ１）。
【００２３】
続いて、ステップＳ１で算出した拠点の合計値が、最も小さい拠点のサーバ（ノード）を選択する（ステップＳ２）。
図１０では、例として「○（白丸）」の拠点（データセンタエリア）に属する待機中のサーバが選択されたことを示している（図１０のＴ１）。
【００２４】
次に、所定のＩＤ割当手法（例えば、ランダムやＩＤ空間上の最大領域を２分割する手法）に従い、ＩＤ空間上におけるＩＤ（挿入位置）の候補を選択する（ステップＳ３）。
図１０では、例として「△（白三角）」で示される拠点のサーバと、「□（白四角）」で示される拠点のサーバとの間のＩＤが、挿入位置として選択されたことを示している（図１０のＴ２）。
【００２５】
そして、選択された挿入位置から周囲（左右（両側）それぞれ）Ｍ−１個のノードの属する拠点を確認し、Ｍ−Ｘ個以上のノードの属する拠点が新たに挿入するノードの拠点と異なるか否かを判定する（ステップＳ４、図１０のＴ３）。なお、「Ｍ−Ｘ個以上のノードの属する拠点が新たに挿入するノードの拠点と異なる」ことを、以下、「大規模障害に耐えるためのノード挿入条件」と呼ぶことがある。
ここで、この大規模障害に耐えるためのノード挿入条件を満たさない場合は（ステップＳ４→Ｎｏ）、ステップＳ３に戻り、所定のＩＤ割当手法を用いて、それまでに選択されたＩＤ（挿入位置）の候補を除いた上で、再度、挿入位置の選択処理を実行して処理を繰り返す。一方、この大規模障害に耐えるためのノード挿入条件を満たす場合には（ステップＳ４→Ｙｅｓ）、ステップＳ３で選択したＩＤを、新たに参加するノードのＩＤ空間上の挿入位置として決定する（ステップＳ５）。そして、処理を終了する。
【００２６】
このようにすることで、特許文献１に係る分散処理システムでは、クラスタに新たなサーバが参加する際、その挿入位置の周囲Ｍ−１個のノードが属する拠点のうち、Ｍ−Ｘ個以上のノードの属する拠点が新たに挿入するノードの拠点と異なるように配置することができる。よって、ノード（特権ノード）は、新たなサーバ（ノード）を参加させる際に、このノード挿入位置決定処理に基づく配置をクラスタ内で繰り返すことにより、同一拠点のノードがＩＤ空間上で隣接するケースを低減させて、複製データの偏りやノード離脱時のデータ取得の処理の発生を抑制することができる。
しかしながら、前記したように特許文献１に係る分散処理システムでは、大規模災害等に伴う大規模障害が発生し原本データを消失した場合においては、保守減設等を実行するためトラヒックが増加し、システムの性能が不足するとともに、遠隔地のサーバへのデータの複製や再配置により、ネットワークコストが増大することや、冗長化システムを再構成するまでの遅延が発生することが課題となる。この課題を解決するための本発明に係る実施の形態について以下説明する。
【００２７】
＜本実施形態の分散処理システム＞
次に、本発明を実施するための形態（以下、「本実施形態」と称する。）に係るノード１（図３参照）を含む分散処理システム１０００（図１参照）について説明する。
【００２８】
≪分散システムの全体構成≫
まず、本実施形態に係るノード１を含む分散処理システム１０００の全体構成について説明する。
図１は、本実施形態に係るノード１を含む分散処理システム１０００の全体構成を示す図である。
【００２９】
この分散処理システム１０００は、各クライアント２からのメッセージを受け付けるロードバランサ３と、振り分け装置４と、クラスタを構成する複数のノード１とを含んで構成される。ロードバランサ３は、クライアント２からのメッセージを単純なラウンドロビン法等により各振り分け装置４に振り分ける。振り分け装置４は、受信したメッセージを、例えば、コンシステントハッシュ法等に基づき、各ノード１に振り分ける。各ノード１では、メッセージ処理を行い、クライアント２にサービスを提供する。
【００３０】
図１においては、振り分け装置４とノード１とを別装置として記載したが、同一サーバ上で別々の機能として動作させることも可能である。また、振り分け装置４も、図１に示すように、クラスタ構成をとることができる。さらに、ロードバランサ３が存在せず、クライアント２から任意の振り分け装置４にメッセージを送信することも可能である。
【００３１】
≪処理概要≫
本実施形態の分散処理システム１０００は、前記した比較例の分散処理システムにおけるノードの物理的な配置（エリア等の位置情報）を考慮したＩＤ空間上でのサーバ配置を実行することに加え、大規模災害等に伴う大規模障害の発生に備えて、以下の処理を実行する。
【００３２】
まず、本実施形態に係る分散処理システム１０００では、将来発生が予測される大規模災害等により各拠点のサーバが故障する確率を示す情報（以下、「故障確率情報」と称する。）を外部装置等から受信する。そして、その故障確率が所定の閾値を超えるサーバ（後記する「救済サーバ」（救済ノード））を抽出する（図２の符号ａ参照）。次に、抽出したサーバが保持する原本データに対応する複製データを保持するサーバ（異なる地域に位置するサーバ）を検索し、その複製データを保持するサーバのうち、故障確率が最も低いサーバを交換先サーバ（交換先ノード）として決定する（図２の符号ｂ参照）。そして、その決定した複製データを保持するサーバ（交換先サーバ）と、原本データを保持するサーバ（救済サーバ）とにおいて、原本と複製の役割を交換する（図２の符号ｃ参照）。つまり、複製データを原本データに昇格させ、当該複製データを保持していたサーバ（交換先サーバ）が、当該データの処理（原本データに対する処理）を担当する。一方、原本データを複製データに降格させ、原本データを保持していたサーバ（救済サーバ）は、役割変更以後にそのデータの処理（原本データに対する処理）を行わず、保持していた原本データを複製データとして処理する。
【００３３】
図２においては、故障確率が所定の閾値を超えるとして抽出されたサーバ（救済サーバ）が保持する原本データ「Original（図２においては、「Ｏ」と記載。）」に対応する２つの複製データ「Replica（図２においては「Ｒ１」「Ｒ２」と記載。）」のうち、故障確率が最も低いサーバとして「Ｒ１」の複製データを保持するサーバが交換先サーバとして決定される例を示している。そして、原本データ「Ｏ」を保持するサーバ（救済サーバ）と、複製データ「Ｒ１」を保持するサーバ（交換先サーバ）とにおいて、原本と複製の役割を交換する。
【００３４】
このようにすることにより、本実施形態に係るノード１を含む分散処理システム１０００では、大規模災害等に伴う大規模障害が発生する前に、原本と複製の役割を異なる地域のノード間で適切に交換しておくため、その後大規模障害が発生した場合でも、原本データを消失することなく処理を継続することができる。また、原本と複製の役割を交換するだけであるため、当該データについて複製や再配置をする必要がないため、大規模障害が発生した場合において、ネットワークコストの増加や、システム再構成の遅延を抑えた上で、原本データを救済することができる。
以下、本実施形態に係るノード１の具体的な構成および処理について説明する。
【００３５】
＜ノード＞
次に、本実施形態に係る分散処理システム１０００を構成するノード１について、具体的に説明する。なお、本実施形態に係るノード１は、分散処理システム１０００の複数のノード１のうち、後記するノード管理テーブル１００（ノード管理情報）を管理する特権ノードとなる場合と、特権ノードからノード管理テーブル１００の情報を受け取り自身のノード管理テーブル１００を更新する特権ノードではない場合とが存在する。なお、特権ノードが行う処理等については、後記する。
【００３６】
図３は、本実施形態に係るノード１の構成例を示す機能ブロック図である。
ノード１は、図１に示したように、各振り分け装置４と通信可能に接続されると共に、クラスタを構成する自身以外の他のノード１とも通信可能に接続される。そして、クライアント２からのメッセージを受信し、サービスを提供する。また、このノード１は、自身が原本データとして保持する情報を、予め設定された冗長数に応じて、他のノード１に対して送信することにより、他のノード１に複製データを保持させる。
なお、本実施形態に係るノード１のデータ管理手法として、コンシステントハッシュ法に基づき、データの振り分け先や複製先を決定する例を以下において説明するが、本発明は、コンシステントハッシュ法に限定されず、複数のノード１がクラスタ構成され、原本データとそれに対応する複製データとを分散してデータ処理するシステムであれば適応可能である。
このノード１は、図３に示すように、制御部１０と、入出力部１１と、記憶部１２とを含んで構成される。
【００３７】
入出力部１１は、振り分け装置４や、自身以外の他のノード１との間の情報の入出力を行う。また、この入出力部１１は、通信回線を介して情報の送受信を行う不図示の通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
【００３８】
記憶部１２は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等の記憶手段からなり、処理の対象となる原本データや複製データ（いずれも不図示）、ノード管理テーブル１００（図４参照）や、死活監視テーブル２００（図５参照）、故障確率情報３００（図６参照）等が記憶される。なお、ノード管理テーブル１００、死活監視テーブル２００および故障確率情報３００の詳細は後記する。また、記憶部１２には、各パラメータの値（Ｍ：冗長数、Ｘ：Ｍ個のうち大規模障害で同時に失われて良いと設定するデータ数、後記する判定に用いる所定の閾値）が記憶される。
【００３９】
制御部１０は、ノード１全体の制御を司り、図３に示すように、ノード管理部１０１、ノード配置決定部１０２、メッセージ処理部１０３、データ複製処理部１０４、死活監視部１０５、データ救済部１０６を含んで構成される。このうちデータ救済部１０６は、さらに、故障情報受付部１０７、データ検索部１０８および原本・複製交換処理部１０９の機能を含んで構成される。
また、この制御部１０は、例えば、記憶部１２に格納されたプログラムをＣＰＵ（Central Processing Unit）がＲＡＭに展開し実行することで実現される。
【００４０】
ノード管理部１０１は、クラスタを構成する各ノード１に関する識別情報や、担当データの情報、物理位置（データセンタエリア等の位置情報）に関する情報、原本・複製交換情報（詳細は後記）等を、ノード管理テーブル１００（ノード管理情報：図４参照）として管理する。ノード管理部１０１は、自身が特権ノードである場合に、クラスタへのノード１の追加や離脱の情報を受信し、自身が保持するノード管理テーブル１００の情報を更新する。そして、ノード管理部１０１は、その更新したノード管理テーブル１００の更新情報を、クラスタ内の自身以外の他のノード１や振り分け装置４に送信する。
また、ノード管理部１０１は、自身が特権ノードではない場合には、特権ノードからノード管理テーブル１００の情報（更新情報）を受信し、自身が保持するノード管理テーブル１００を更新する。
このようにすることにより、クラスタ内の各ノード１や各振り分け装置４は、常に、同一内容のノード管理テーブル１００を備える。
【００４１】
なお、ノード管理部１０１は、ノード管理テーブル１００が更新された場合、つまり、ノード１の追加や離脱があった場合に、データ複製処理部１０４に対して、原本データや複製データの再配置を実行させるため、データ複製指示を出力する。
【００４２】
図４は、本実施形態に係るノード管理テーブル１００（ノード管理情報）のデータ構成例を示す図である。図４に示すように、ノード管理テーブル１００は、クラスタを構成する各ノード１のノード識別子１１０、担当データ１２０、サーバ名（アドレス）１３０、地域ＩＤ１４０および原本・複製交換情報１５０を含んで構成される。
なお、図４（ａ）は、データ救済部１０６によるデータ救済処理（詳細は後記）が実行されていない状態を示している。具体的には、原本・複製交換情報１５０のデータ項目に何も情報が格納されていない。これに対し、図４（ｂ）は、データ救済部１０６によるデータ救済処理が実行中である状態を示している。具体的には、原本・複製交換情報１５０のデータ項目に、「原本と複製の役割を交換したことを示す情報」が格納される。
ここでは、図４（ａ）の状態におけるノード管理テーブル１００について説明し、図４（ｂ）の状態におけるノード管理テーブル１００については、後記する。
【００４３】
ノード識別子１１０は、コンシステントハッシュ法のＩＤ空間上でのノードＩＤに対応する。また、コンシステントハッシュ法において仮想ＩＤを用いる場合には、ノード識別子１１０は、仮想ＩＤ毎に割り当てられ、ノード管理テーブル１００に登録される。そして、このノード管理テーブル１００では、例えば、コンシステントハッシュのＩＤ空間におけるＩＤ（または仮想ＩＤ）を昇順に並べて管理する。つまり、ノード管理テーブル１００において、ノード識別子１１０（ノードＩＤ）を昇順に並べたときの自身のノード１の行の次の行のノード１が、ＩＤ空間上での右隣（時計回りに次）のノード１となる。
例えば、図４においては、コンシステントハッシュのＩＤ空間に基づくデータ識別子が「０」から「５６」であるデータについては、同図の第１行目に示すノード（ノード識別子「５６」、サーバ名「サーバＡ」であるノード）がそのデータに関する処理（原本データの記憶や更新、データの抽出等を含む）を担当する。同様に、データ識別子が「５６」に１を加えた「５７」から「１７２」であるデータについては、第２行目に示すノード（ノード識別子「１７２」、サーバ名「サーバＢ」であるノード）がそのデータに関する処理を担当する。以下、同様である。
【００４４】
担当データ１２０には、そのサーバが原本データとして担当するデータのＩＤが格納される。上記のように、第１行目に示すノード（ノード識別子「５６」、サーバ名「サーバＡ」であるノード）が原本データとして担当するデータのデータＩＤが「０」〜「５６」として格納される。なお、図４においては、データＩＤが「０」〜「５６」であり、「サーバＡ」が原本データとして管理するデータを、「データａ」とまとめて表記する。
同様に、第２行目に示すノード（ノード識別子「１７２」、サーバ名「サーバＢ」であるノード）が原本データとして担当するデータとして、「データｂ」（データＩＤが「５７」〜「１７２」）が格納される。以下同様である。
【００４５】
サーバ名（アドレス）１３０は、クラスタを構成する各ノード１の識別子を表す。このサーバ名１３０は、ノード１それぞれのアドレス（例えば、ＩＰアドレス）に対応付けられて記憶される。
【００４６】
地域ＩＤ１４０は、物理位置（データセンタエリア等の位置情報）に関する情報である拠点（Ｋ箇所）の識別子を表す。例えば、地域ＩＤ１４０が「００」は「拠点α（九州エリア）」を表し、地域ＩＤ１４０「０１」は、「拠点β（関西エリア）」を表し、地域ＩＤ１４０が「０２」は、「拠点γ（関東エリア）」を表す。
原本・複製交換情報（交換先サーバ）１５０については、後記するが、データ救済部１０６によるデータ救済処理が実行されていない状態では、何も情報が格納されていないものとなる。
【００４７】
なお、このノード管理テーブル１００のノード識別子１１０は、特権ノードのノード管理部１０１が各ノード１に対して付与することもできるし、外部装置（例えば、ネットワーク管理装置等）が各ノード１に対して付与したノード識別子１１０を受信して格納することも可能である。また、特権ノードを設けず、分散処理システム１０００についての管理装置を設け、その管理装置が、ノード管理テーブル１００に関するノード１の離脱や追加（参加）を管理し、更新したノード管理テーブル１００を各ノード１に配信するようにしてもよい。
さらに、このノード管理テーブル１００には、処理で必要となる他の付加情報（例えば、各ノード１のクラスタへの参加日時等）を加えることも可能である。
【００４８】
このノード管理部１０１は、自身が特権ノードである場合に、自身の死活監視部１０５や、特権ノードでない他のノード１、外部装置（ネットワーク管理装置等）から、ノード１の離脱の情報を受信した場合に、ノード管理テーブル１００において、その離脱させるノード１の情報（ノード識別子１１０、担当データ１２０、サーバ名（アドレス）１３０、地域ＩＤ１４０および原本・複製交換情報１５０）を含むレコードを削除する。
また、ノード管理部１０１は、自身が特権ノードである場合に、ノード管理テーブル１００において、新たに追加するノード１の情報（ノード識別子１１０、担当データ１２０、サーバ名（アドレス）１３０、地域ＩＤ１４０および原本・複製交換情報１５０）を含むレコードを、ノード配置決定部１０２が決定した位置に挿入する。
【００４９】
ノード配置決定部１０２は、自身が特権ノードである場合に、自身の死活監視部１０５や、特権ノードでない他のノード１、外部装置（ネットワーク管理装置等）から、ノード１の追加（参加）の情報を受信し、ＩＤ空間（ノード管理テーブル１００）に新たなノードを追加しようとするとき、次のようなノード挿入位置決定処理を行う。なお、このノード挿入位置決定処理は、図９および図１０を参照して説明した処理と同様の処理である。
ノード配置決定部１０２は、新たなノードを追加するノードＩＤの周囲（左右それぞれ）Ｍ−１個のノードのうちＭ−Ｘ個以上のノードが、追加するノードが属する拠点（データセンタエリア）と異なる拠点（データセンタエリア）となるように配置を決定する。つまり、ノード配置決定部１０２は、Ｍ−Ｘ個のノードの拠点および追加するノードの拠点のそれぞれが異なる拠点となるようなＩＤ空間の挿入位置を、新たに追加するノードの挿入位置として決定する。そして、ノード配置決定部１０２は、ノード管理部１０１を介して、新たに追加するノード１の情報をノード管理テーブル１００の決定した挿入位置に挿入させる。
このノード配置決定部１０２が実行するノード挿入位置決定処理に基づく配置をクラスタ内で繰り返すことにより、同一拠点のノードがＩＤ空間上で隣接するケースを低減させて、複製データの偏りやノード離脱時のデータ取得の処理の発生を抑制することができる。
【００５０】
メッセージ処理部１０３は、振り分け装置４から振り分けられたメッセージを受信し、そのメッセージの処理を実行し、処理結果をクライアント２に返信することにより、サービスを提供する。また、メッセージ処理部１０３は、メッセージの処理に必要なデータをそのノード１自身が保持していなかった場合には、他のノード１（ノード管理テーブル１００で自身の次の行のノード１、さらに、その次の行のノード１等）に要求すること等により、そのデータを取得することが可能である。
また、メッセージ処理部１０３は、受信したメッセージの処理により、原本データを新たに格納したり、更新したりした場合には、新たに格納した原本データや更新後の原本データを複製して、複製データとして他のノードに格納させるため、データ複製処理部１０４に対して、データ複製指示を出力する。
【００５１】
さらに、メッセージ処理部１０３は、メッセージを受信した際に、ノード管理テーブル１００を参照し、原本・複製交換情報１５０に、「原本と複製の役割を交換したことを示す情報」が格納されている場合には、当該情報に応じて、原本データを保持する役割のノード１としての処理、または、複製データを保持する役割のノード１としての処理を交換した役割として実行する。なお、詳細は後記する。
【００５２】
データ複製処理部１０４は、自身が保持するデータ（原本データ）について、ノード管理テーブル１００を参照し、自身のレコードの次の（下の）行のノード（つまり、ＩＤ空間での右隣のノード）を、複製データを保持させるノードとして選択し、原本データの複製を生成して複製データとして送信する。データ複製処理部１０４は、冗長数が「Ｍ」個の場合に、ノード管理テーブル１００を参照し、上記のように自身のレコードの次の行のノード、また、次の行のノードという順（ＩＤ空間で右隣、さらに、右隣りの順）に、複製データを保持させるノードを「Ｍ−１」個決定して、複製データを送信する。
【００５３】
また、データ複製処理部１０４は、ノード管理テーブル１００の原本・複製交換情報１５０に「原本と複製の役割を交換したことを示す情報」が格納されている場合において、自身が原本の役割を示す情報が格納されているときには、救済サーバとして格納されているサーバに対して、複製データを送信するとともに、その救済サーバが複製データを送信していたサーバのうち、自身以外のサーバに対して、当該複製データを送信する。つまり、原本データを保持するサーバに代わって、データの冗長度を保持するための複製データの送信処理を実行する。
【００５４】
死活監視部１０５は、死活監視テーブル２００（後記する図５）を参照して、指定されたノード１（例えば、自身の次の行のノード）と所定の時間間隔で死活監視信号のやり取りを行い、クラスタを構成するノード１の障害を検出する。ノード１の障害を検出した場合、死活監視部１０５は、自身が特権ノードの場合はノード管理部１０１に、自身が特権ノードでない場合は特権ノードに通知（障害発生通知）を行う。なお、特権ノードを設けず、ノード管理テーブル１００を管理する管理装置を設けた場合には、各ノード１の死活監視部１０５は、その管理装置に対して、障害発生通知を送信する。
【００５５】
図５は、本実施形態に係る死活監視テーブル２００のデータ構成例を示す図である。
死活監視テーブル２００は、１台の物理装置を単位として作成され、監視対象となるノード１（サーバ）がリスト化されたものである。死活監視テーブル２００には、例えば、サーバ名とそれに紐付くアドレス（ＩＰアドレス）とが記憶される。
【００５６】
死活監視テーブル２００は、論理装置（仮想ノード）単位でノードが構成されるパターンを考慮して、その論理装置を構築する物理装置が少なくとも１回は監視対象となるように設定される。また、クラスタを構成するノード１に追加や離脱があった場合、ノード管理テーブル１００と同期的に更新されるものとする。よって、ノード管理テーブル１００のノード識別子１１０が、論理装置単位で構成された仮想ＩＤによるものではなく、物理装置単位のＩＤである場合には、死活監視テーブル２００とノード管理テーブル１００とについて、同一のものを用いてもよい。また、この場合、死活監視テーブル２００を生成せず、ノード管理テーブル１００を用いて、死活監視部１０５が各ノード１の死活監視を行うようにしてもよい。
【００５７】
ここで、クラスタ内における複数のノード１の中から特権ノードを決定する処理について説明する。
各ノード１は、ノード管理テーブル１００に付加情報として、前記したように、各ノード１のクラスタへの参加日時等が格納されている場合、その参加日時が古い順に、特権ノードが選択されるようにしてもよい。また、各ノード１は、死活監視テーブル２００を参照し、死活監視テーブル２００の一番上の行から順に、特権ノードとなるように設定してもよい。
ノード１が新たに特権ノードになった場合、自身が特権ノードであることを示す情報を、各ノード１等に送信する。そして、特権ノードは、クラスタ内のノード１に離脱や追加（参加）があった場合に、自身のノード管理テーブル１００を更新し、その更新情報を各ノード１や振り分け装置４等に配信する。
【００５８】
図３に戻り、データ救済部１０６について説明する。
データ救済部１０６は、大規模災害等に伴う大規模障害により原本データを消失しないようにする「データ救済処理」を実行する。このデータ救済処理において、データ救済部１０６は、外部装置（図示省略）から、将来発生が予測される大規模災害等により各拠点のサーバが故障する確率を示す情報（故障確率情報）を受信し、その故障確率が所定の閾値を超えるサーバ（救済サーバ（救済ノード））を抽出する。そして、データ救済部１０６は、抽出したサーバ（救済サーバ）が保持する原本データに対応する複製データを保持するサーバを検索し、その中から故障確率の最も低いサーバを交換先サーバ（交換先ノード）として決定する。データ救済部１０６は、その決定した複製データを保持するサーバ（交換先サーバ）と、原本データを保持するサーバ（救済サーバ）とについて、原本データと複製データを処理する役割を交換させる。
このデータ救済部１０６は、故障情報受付部１０７と、データ検索部１０８と、原本・複製交換処理部１０９とを含んで構成される。
【００５９】
故障情報受付部１０７は、入出力部１１を介して、外部装置等から故障確率情報３００を受信する。そして、故障情報受付部１０７は、記憶部１２に故障確率情報３００を記憶する。故障情報受付部１０７は、所定の時間間隔で故障確率情報３００を受信する場合には、記憶部１２に記憶されている故障確率情報３００を最新の情報に更新する。また、故障情報受付部１０７は、不定期に受信する故障確率情報３００、例えば、突発的な緊急地震速報に伴い算出された故障確率情報３００を受信し、記憶部１２に記憶されている故障確率情報３００を更新するようにしてもよい。
【００６０】
図６は、本実施形態に係る故障確率情報３００のデータ構成例を示す図である。
故障確率情報３００は、各拠点のノード１（サーバ）それぞれが、将来発生が予測される大規模災害等により故障する確率（障害が発生する確率）を示す情報である。なお、大規模災害等とは、例えば、台風や暴風雨、竜巻、落雷、大雨、河川の氾濫、津波、地震等であり、数日若しくは数秒から数時間後に、拠点が位置する地域において、上記災害による物理的な損傷（ネットワークの切断等も含む）や、停電の発生、若しくは、サーバの管理者がサーバ設置施設に近付けない等を含む障害によりサーバが使用不能となる予測される確率を示す情報である。
【００６１】
この故障確率情報３００は、地域ＩＤ３１０、サーバ名３２０、時刻３３０、故障確率３４０のデータ項目から構成される。
地域ＩＤ３１０は、図４に示したノード管理テーブル１００の地域ＩＤ１４０と同様の情報である。サーバ名３２０も、図４に示したノード管理テーブル１００のサーバ名１３０と同様の情報である。
時刻３３０および故障確率３４０は、地域ＩＤ３１０およびサーバ名３２０に対応付けて格納される情報である。故障確率３４０には、時刻３３０（所定時刻）における当該サーバの故障確率（％）が格納される。なお、図６においては、時刻３３０は、１時間毎に設定される例を示している。
例えば、故障確率情報３００の１行目に示すように、地域ＩＤ３１０が「００（拠点α）」に位置するサーバ名３２０の「サーバＡ」は、時刻３３０で示される「2015年6月1日」の13時から14時の間の故障確率３４０が「１０（％）」、14時から15時の間の故障確率３４０が「３０（％）」であることを示している。
【００６２】
図３に戻り、データ検索部１０８は、故障情報受付部１０７が故障確率情報３００を受け付けたこと等を契機として、原本データを保持する各サーバについて、受け付けた故障確率情報３００を参照し、例えば、現在時刻を基準として、直近の故障確率を抽出し、所定の閾値を越えているか否かを判定する。
図６に示す故障確率情報３００の例では、現在時刻が2015年6月1日の12時50分である場合に、時刻３３０の「20150601（13：00〜）」を参照し、故障確率３４０として「１０（％）」を抽出する。そして、データ検索部１０８は、所定の閾値（例えば、２０（％））を超えるか否かを判定する。ここでは、データ検索部１０８は、所定の閾値を超えないと判定する。
また、データ検索部１０８は、現在時刻が2015年6月1日の13時50分である場合に、時刻３３０の「20150601（14：00〜）」を参照し、故障確率３４０として「３０（％）」を抽出する。そして、データ検索部１０８は、予め設定された閾値（例えば、２０（％））を超えるか否かを判定する。ここでは、データ検索部１０８は、所定の閾値を超えると判定する。
【００６３】
データ検索部１０８は、所定の閾値を超えるサーバ（救済サーバ）が存在すると判定した場合に、当該サーバ（救済サーバ）が保持する原本データを、ノード管理テーブル１００（図４）の担当データ１２０を参照して抽出する。また、データ検索部１０８は、当該サーバ（救済サーバ）が保持する原本データの複製データを保持するサーバを検索する。そして、データ検索部１０８は、検索した複製データを保持するサーバの同時刻における故障確率３４０を故障確率情報３００において参照し、故障確率の最も低いサーバを交換先サーバとして決定する。
【００６４】
原本・複製交換処理部１０９は、データ検索部１０８が所定の閾値を超えると判定したサーバ（救済サーバ）と、当該サーバ（救済サーバ）が保持する原本データの複製データを保持するサーバの中から決定された交換先サーバの情報に基づき、原本と複製の役割を交換させる処理を実行する。
具体的には、原本・複製交換処理部１０９は、ノード管理テーブル１００（図４参照）の原本・複製交換情報１５０の欄において、救済サーバとされたサーバには、原本データを複製データとして扱う旨の情報（図４（ｂ）においては、「原本→複製」）を格納する。このとき、原本・複製交換処理部１０９は、交換先サーバの識別情報を対応付けて記憶する（図４（ｂ）においては、「交換先サーバ：サーバＢ」）。
また、原本・複製交換処理部１０９は、ノード管理テーブル１００の原本・複製交換情報１５０の欄において、交換先サーバとして決定されたサーバには、複製データを原本データとして扱う旨の情報（図４（ｂ）においては、「複製→原本」）を格納する。このとき、原本・複製交換処理部１０９は、救済サーバの識別情報を対応付けて記憶する（図４（ｂ）においては、「救済サーバ：サーバＡ」）。
【００６５】
このように、ノード管理テーブル１００において、原本と複製の役割を交換したサーバの情報を格納しておく。ノード１のメッセージ処理部１０３は、新たなメッセージを受け付けた場合に、そのデータの原本データを保存するサーバについて、ノード管理テーブル１００の原本・複製交換情報１５０を参照し、原本と複製の役割を交換したことを示す情報が設定されているか否かを確認する。そして、自身のサーバが原本データとして処理すべきデータについて、当該サーバの役割が「原本→複製」となっていた場合には、当該要求を原本データとして処理せず、複製データとして処理すると判定する。一方、メッセージ処理部１０３は、そのデータについて、ノード管理テーブル１００の原本・複製交換情報１５０を参照し、自身のサーバが原本データとして処理すべきデータではないデータについて、原本と複製の役割を交換したことを示す情報が設定されているか否かを確認し、当該サーバの役割が「原本→複製」となっており、かつ、その交換先サーバとして自身のサーバが設定されている場合には、そのデータを原本データとして処理する。
【００６６】
なお、このとき、データ複製処理部１０４は、ノード管理テーブル１００において、自身のサーバのレコードに格納された原本・複製交換情報１５０の救済サーバの識別情報を確認し、その救済サーバに対して、メッセージ処理により更新されたデータ（複製データ）を送信する。また、データ複製処理部１０４は、その救済サーバが複製データを送信していたサーバを、ノード管理テーブル１００を参照して抽出し、その抽出したサーバのうち、自身以外のサーバに対して更新された複製データを送信する処理を実行する。このようにすることで、原本データと複製データを再配置することがなく、システム全体としての冗長度を保つことができる。
【００６７】
また、データ検索部１０８は、データ救済処理を実行した後、時間が経過し、前回の処理において、救済サーバであると判定したサーバについて、その次のデータ救済処理を実行した場合に、所定の閾値以下となったと判定した場合には、原本・複製交換処理部１０９を介して、ノード管理テーブル１００の原本・複製交換情報１５０に格納した原本と複製の役割を交換したことを示す情報を消去する。これにより、原本と複製の役割を元の状態に容易に戻すことができる。
【００６８】
＜処理の流れ＞
次に、本実施形態に係るノード１が実行する、データ救済処理について、図７を参照して説明する。図７は、本実施形態に係るノード１が実行するデータ救済処理の流れを示すフローチャートである。
【００６９】
まず、ノード１の故障情報受付部１０７が、外部装置等から故障確率情報３００を受信する（ステップＳ１０）。そして、故障情報受付部１０７は、受信した故障確率情報３００を記憶部１２に記憶する。
【００７０】
続いて、ノード１のデータ検索部１０８は、故障情報受付部１０７が故障確率情報３００を受け付けたこと等を契機として、原本データを保持する各サーバについて、受け付けた故障確率情報３００を参照し、例えば、現在時刻を基準として、直近の故障確率を抽出し、所定の閾値（例えば、２０（％））を超えているか否かを判定する（ステップＳ１１）。
【００７１】
そして、データ検索部１０８は、原本データを保持するサーバが、所定の閾値を超えていないと判定した場合には（ステップＳ１１→Ｎｏ）、処理を終了する。一方、データ検索部１０８は、原本データを保持するサーバが、所定の閾値を超えていると判定した場合には（ステップＳ１１→Ｙｅｓ）、当該サーバを原本データの救済が必要なサーバ（救済サーバ）であるとし、当該サーバ（救済サーバ）が保持する原本データ（の識別子）を、ノード管理テーブル１００（図４）の担当データ１２０を参照して抽出する（ステップＳ１２）。
なお、ステップＳ１２以降ステップＳ１６までの処理は、救済サーバとして判定されたサーバ毎に実行される処理である。
【００７２】
続いて、データ検索部１０８は、当該サーバ（救済サーバ）が保持する原本データの複製データを保持するサーバを、ノード管理テーブル１００を参照して検索する（ステップＳ１３）。具体的には、データ検索部１０８は、ノード管理テーブル１００（図４（ａ）参照）において、当該サーバ（救済サーバ）の位置する行を基準として、次の「Ｍ−１」個の行までに記載されたノードを、複製データを保持するサーバとして検索する。
【００７３】
次に、データ検索部１０８は、検索した複製データを保持するサーバの同時刻における故障確率３４０を故障確率情報３００において参照し、故障確率の最も低いサーバを決定する（ステップＳ１４）。なお、データ検索部１０８は、故障確率が最も低いサーバが複数存在する場合には、例えば、その中から、ランダムに決定してもよいし、ノード管理テーブル１００において救済サーバにより近い行のサーバ（ＩＤ空間上でより隣のサーバ）に決定してもよい。
【００７４】
そして、データ検索部１０８は、ステップＳ１４において決定したサーバの故障確率が、前記した所定の閾値（例えば、２０（％））を超えるか否かを判定する（ステップＳ１５）。ここで、決定したサーバの故障確率が、所定の閾値を超えていれば（ステップＳ１５→Ｙｅｓ）、処理を終了する。一方、決定したサーバの故障確率が所定の閾値を超えていなければ（ステップＳ１５→Ｎｏ）、データ検索部１０８は、ステップＳ１４において決定したサーバを交換先サーバとし、次のステップＳ１６に進む。
【００７５】
ステップＳ１６において、ノード１の原本・複製交換処理部１０９は、データ検索部１０８がステップＳ１１において閾値を超えると判定したサーバ（救済サーバ）と、当該サーバ（救済サーバ）が保持する原本データの複製データを保持するサーバの中から決定された交換先サーバ（ステップＳ１４で決定されたサーバ）の情報に基づき、原本と複製の役割を交換させる処理を実行する。
具体的には、原本・複製交換処理部１０９は、図４（ｂ）に示す例のように、ノード管理テーブル１００の原本・複製交換情報１５０の欄において、救済サーバとされたサーバには、原本データを複製データとして扱う旨の情報（図４（ｂ）においては、「原本→複製」）を格納する。このとき、原本・複製交換処理部１０９は、交換先サーバの識別情報を対応付けて記憶する。
また、原本・複製交換処理部１０９は、ノード管理テーブル１００の原本・複製交換情報１５０の欄において、交換先サーバとして決定されたサーバには、複製データを原本データとして扱う旨の情報（図４（ｂ）においては、「複製→原本」）を格納する。このとき、原本・複製交換処理部１０９は、救済サーバの識別情報を対応付けて記憶する。
このようにして、救済サーバと判定したすべてのノードについて処理を実行し、ノード１によるデータ救済処理を終了する。
【００７６】
なお、ノード１のデータ検索部１０８は、ステップＳ１１において、原本データを保持するサーバが、所定の閾値を超えていると判断した場合に（ステップＳ１１→Ｙｅｓ）、現在時刻から故障確率情報３００の時刻３３０で設定されている時刻までの時間（該当する故障発生確率に至るまでの時間）が、原本と複製の役割を交換に必要となる時間（ステップＳ１６を実行する時間）よりも長いときに、当該所定の閾値を超えたサーバを救済サーバとし、ステップＳ１２以降の処理を実行するようにしてもよい。ここで、原本と複製の役割を交換に必要となる時間は、たとえば、それまでの実測値の平均等に基づき、予め設定しておく。
また、上記の処理の流れの説明では、ステップＳ１５における所定の閾値を、ステップＳ１１での原本データの救済の対象となるサーバを判定する際に用いた閾値と同じ閾値として説明した。しかしながら、ステップＳ１１とステップＳ１５の閾値は同一である必要はなく、別々に任意の値を設定してもよい。
【００７７】
以上、説明したように、本実施形態に係るノード１、データ救済方法およびプログラムによれば、大規模災害等に伴う大規模障害が発生する前に、原本と複製の役割を異なる地域のノード間で適切に交換しておくため、その後大規模障害が発生した場合でも、原本データを消失することなく処理を継続することができる。また、原本と複製の役割を交換するだけであるため、当該データについて複製や再配置をする必要がないため、大規模障害が発生した場合において、ネットワークコストの増加や、システム再構成の遅延を抑えた上で、原本データを救済することができる。
【００７８】
なお、前記したように、本実施形態に係るノードのデータ管理手法は、コンシステントハッシュ法に限定されるものではなく、複数のノードがクラスタ構成され、原本データとそれに対応する複製データとを分散してデータ処理するシステムであれば適応可能である。例えば、各ノードは、各拠点のサーバに配置されるデータの一覧表を備える。そして、そのデータの一覧表において、各サーバに配置されるデータには、原本データであるか複製データであるかの識別情報が付されるともに、図４おいて示した、原本・複製交換情報１５０が付される。このようにすることにより、各ノードは、原本と複製の役割を交換したことを示す情報を参照した上で、そのデータを処理することができる。
【符号の説明】
【００７９】
１      ノード
２      クライアント
３      ロードバランサ
４      振り分け装置
１０    制御部
１１    入出力部
１２    記憶部
１００  ノード管理テーブル（ノード管理情報）
１０１  ノード管理部
１０２  ノード配置決定部
１０３  メッセージ処理部
１０４  データ複製処理部
１０５  死活監視部
１０６  データ救済部
１０７  故障情報受付部
１０８  データ検索部
１０９  原本・複製交換処理部
２００  死活監視テーブル
３００  故障確率情報
１０００  分散処理システム
【図１】
0006322161.tif 000002
【図２】
0006322161.tif 000003
【図３】
0006322161.tif 000004
【図４】
0006322161.tif 000005
【図５】
0006322161.tif 000006
【図６】
0006322161.tif 000007
【図７】
0006322161.tif 000008
【図８】
0006322161.tif 000009
【図９】
0006322161.tif 000010
【図１０】
0006322161.tif 000011