JP5815000B2 - ノードおよびプログラム - Google Patents

Description

本発明は、複数サーバを並べたクラスタ構成において、激甚災害などの同時に多くのサーバが故障や離脱をするような場合でも、管理しているデータが失われることなくサービスを継続するためのノードおよびプログラムに関する。

近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のサーバを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。

分散処理を行う際には、クラスタを構成する各サーバ（以下、「ノード」または「クラスタメンバ」と称する。）が担当するデータを決定する必要がある。このとき、クラスタ全体での処理能力を高めるためには、各ノードが担当するデータ数（データ量）は平均化されていることが望ましい。

代表的なデータの管理手法として、各データのｋｅｙをハッシュ関数にかけた値（以下、「ｈａｓｈ（ｋｅｙ）」と称する。）をノード数Ｎで割った余り、すなわち「ｈａｓｈ（ｋｅｙ） ｍｏｄ Ｎ」を番号として持つノードがデータを管理する手法がある。この場合、各ノードに事前に「０」から「Ｎ−１」までの番号を割り当てていることが前提となる。このような管理手法を用いた場合、ノードを追加・離脱すると、Ｎの値が変化して、多くのデータについて、そのデータの保存を担当するノードが変更になるため、担当するデータを再配置することが必要になる。

そこで、ノードの追加・離脱に伴い担当するクラスタメンバが変更になるデータ数を約１／Ｎに抑える方法として、コンシステントハッシュ（Consistent Hashing）法（非特許文献１参照）を用いた管理手法がある。このコンシステントハッシュ法は、Amazon Dynamo（非特許文献２参照）等において用いられている。

このコンシステントハッシュ法を用いたデータ管理手法では、ノードとデータの双方にＩＤ（IDentifier）を割り当てる。そして、データのＩＤから閉じたＩＤ空間を時計回りに辿った場合に最初に遭遇するノードをそのデータの担当とする。ノードに対するＩＤの与え方の例としては、ＩＰアドレスをハッシュ関数にかけた値（hash（ＩＰアドレス））が挙げられる。

クラスタ構成の分散システムでは、各ノードの処理性能が等しい場合には、各ノードが担当するデータ量を等しくする、すなわち、コンシステントハッシュ法のＩＤ空間における、ノード間の距離（以下、「ノードの担当範囲」または「ハッシュＩＤ範囲」と称する。）を等しくすることが望ましい。この点を解決するため、各ノードに仮想的に複数のＩＤを持たせる手法が用いられている（非特許文献１参照）。各ノードが複数の仮想ＩＤを持つことで、仮想ＩＤ毎の担当範囲は異なっていても、大数の法則に従いノードの担当範囲は平均化される。

図１４は、複数のノードをクラスタ構成にした場合に、各ノードをコンシステントハッシュのＩＤ空間（環状のＩＤ空間）上に配置し、データを管理する手法（以下、「コンシステントハッシュ法によるデータ管理手法」と称する。）を説明するための図である（特許文献１参照）。なお、ここで、データの管理とは、各ノードが行うデータの取得や更新、データの複製を行うこと等を意味する。

図１４に示すように、コンシステントハッシュ法では、各ノードがコンシステントハッシュのＩＤ空間（以下、単に「ＩＤ空間」と称する場合がある。）にマッピングされる。そして、各ノードは、図１４に示すように、自身が担当するハッシュＩＤの範囲（「ハッシュＩＤ範囲」）を持っている。あるデータを取得する際は、データを一意に特定するｋｅｙ情報をハッシュ関数にかけ、導出されたコンシステントハッシュのＩＤ空間上の位置（図１４においては、黒丸（●）で表示）から所定の方向（図１４では時計回り）に進んで最初に遭遇するノードからデータを取得する（図１４においては、矢印（→）で表示）。例えば、図１４において、データＡについては、ＩＤ空間上を時計回りに進み最初に遭遇したノード「１」が担当となる。なお、更新時も同様にノードを特定する。

また、複製データは、ＩＤ空間上で時計回り（若しくは反時計回り）に隣のノードに作成する（冗長数が「２」の場合）。図１４では、ノード「１」においてデータＡの更新を行った場合、ノード「２」にデータＡの複製を作成する。このようにすることにより、ノード「１」が故障等の理由でクラスタから離脱しても、データへの問い合わせはデータＡの複製を持つノード「２」に振り分けられるため、ノード「２」において処理を継続することが可能となる。

次に、コンシステントハッシュ法によるデータ管理手法において、クラスタに新たなノードが参加（追加）する場合の動作について説明する。
図１５は、コンシステントハッシュのＩＤ空間上に、新たにノードが参加した場合の動作例を説明するための図である。

図１５においては、図１４に示すノードの配置において、ノード「１」とノード「４」との間に、ノード「５」が新たに配置された例を示している。
コンシステントハッシュのＩＤ空間にノード「５」が参加した後、ノード「５」がデータを保持するハッシュＩＤ範囲に位置するデータの問い合わせがあった場合、参加直後のノード「５」はデータを持っていないため、ノード「５」の参加以前に該当データを担当していたノード「１」からデータを引き継いで処理を行う。その後、ノード「５」はノード「４」の複製データ（図１５においては、「データＤの複製」と表記。）を保持し、ノード「１」はノード「４」のハッシュＩＤ範囲のデータの複製（「データＤの複製」）を保持する必要がなくなるため、破棄を行う。また、ノード「２」は、ノード「１」のハッシュＩＤ範囲ではなくなった「データＡの複製」を保持する必要がなくたるため、破棄を行う。以降は、図１４の複製作成処理と同様に動作する。
なお、データの再配置を一度に実行すると、新たに参加したノード「５」の負荷が高くなり通常サービスに影響を及ぼす可能性があるため、データに対する処理が発生したタイミングや、負荷を調整しながらバックグラウンドで処理を行うことが望ましい。

David karger, et al.,"Consistent Hashing and Random Trees:Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web"，［online］，1997，ACM，［平成25年10月2日検索］，インターネット<ＵＲＬ:http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf> Giuseppe DeCandia，et al.，"Dynamo: Amazon’s Highly Available Key-value Store"， SOSP’07, October 14-17, 2007, Stevenson, Washington, USA，［online］，［平成25年10月2日検索］，インターネット<ＵＲＬ:http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf>

特開２０１２−２４８０９１号公報

コンシステントハッシュ法によるデータ管理手法は、クラスタを構成するノードの追加や離脱に伴うデータの移行が全データに対する一部のデータに限られるため、クラスタ構成の動的な変更（ノードの追加・離脱）が頻繁に起こるシステムに対して有効である。また、クラスタを構成するノードの障害に備えて、原本データを保持するノード以外の１つ以上のノードに対して複製データを保持させることで、耐故障性を高めている。しかしながら、ノードの物理的な配置（エリア等の位置情報）を考慮しないと、激甚災害等による大規模故障が発生した場合、該当データを保持したすべてのノードに障害が同時に発生してしまう可能性がある。以下、具体的に説明する。

図１６は、従来のコンシステントハッシュに基づくデータ管理を行う分散システムを、物理的に配置した例を示している。図１４および図１５において示したように、コンシステントハッシュのＩＤ空間上に複数のノードを配置し、クラスタを構成している。図１６（ａ）に示すように、実際の物理ノードを１種類（１箇所）のデータセンタエリアにおいて実現する場合、例えば、関東エリアにデータセンタが設置される場合は、関東に激甚災害が発生したときに、クラスタで管理しているすべてのデータを損失する可能性がある（図１６（ｂ）参照）。

また、図１７に示すように、物理ノードが全国に跨ってＫ種類（Ｋ箇所）のデータセンタエリアにおいて実現する場合、関東において激甚災害が発生したときに、コンシステントハッシュのＩＤ空間上の関東エリアのノードがＩＤ空間から離脱する。このとき、コンシステントハッシュは、物理位置（エリア等の位置情報）を考慮した分散にはなっていないため、コンシステントハッシュのＩＤ空間上でどの位置にあるノードが離脱するかはランダムであり、原本データもその複製データも同時に失われる可能性がある。
図１７（ａ）に示す例では、Ｋ種類（ここでは、５種類）のデータセンタエリアが存在し、冗長数「２」として、コンシステントハッシュのＩＤ空間上にそのデータセンタエリアに属する各ノードが配置されている。なお、冗長数は、原本データを保持するノードと複製データを保持するノードとを合わした数である。
コンシステントハッシュのＩＤ空間上では、物理位置（エリア等の位置情報）に関係なくランダムに各データセンタのノードが配置されるため、原本データと複製データが同一エリア（図１７（ａ）では「□（白四角）」において示される関東エリア）に属するノードの場合、原本データと複製データとが同時に失われる可能性がある（図１７（ｂ）参照）。

このような背景を鑑みて本発明がなされたのであり、本発明は、激甚災害等の広いエリアにおいて複数台のノードが同時に離脱した場合においても、データを損失させず、継続処理を可能とするノードおよびプログラムを提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、環状のＩＤ（IDentifier）空間に、処理対象の複数のデータのＩＤ、および、クラスタを構成し前記データに関するリクエストを処理する複数のノードのＩＤが、割り当てられ、前記ＩＤ空間において前記データのＩＤから所定方向回りに辿って最初に遭遇した前記ノードまでの間に位置する前記データを当該ノードが原本データとして保持するとともに、前記クラスタ内の自身以外の他のノードに前記原本データの複製である複製データを保持させる分散システムの前記ノードであって、前記ＩＤ空間における、前記ノードそれぞれのＩＤを、前記ノードそれぞれが物理的に存在する地域を示す位置情報に対応付けたノード管理情報、前記クラスタ内における前記データの前記原本データおよび前記複製データの保持数である冗長数（Ｍ（≧２））、並びに、前記原本データおよび前記複製データのうち障害により同時に失われても良いと設定するデータ数（Ｘ）を記憶する記憶部と、前記ノード管理情報の前記位置情報を参照することにより、前記ＩＤ空間の自身のノードのＩＤから所定方向回りに辿って遭遇する前記ノードのうち、少なくともＭ−Ｘ個は、前記原本データおよび前記複製データを保持する前記ノードの地域を示す前記位置情報がそれぞれ異なるように、前記複製データの配置先となる前記ノードを決定するデータ複製処理部と、を備えることを特徴とするノードとした。

このように、ノードは、ＩＤ空間におけるＩＤと地域を示す位置情報とを対応付けたノード管理情報を記憶しており、ＩＤ空間の自身のノードのＩＤから所定方向回りに辿って遭遇するノードのうち、少なくともＭ−Ｘ個は、位置情報がそれぞれ異なるようにして、複製データの配置先を決定することができる。よって、大規模障害が発生した場合であっても、少なくともＭ−Ｘ個は、地域が異なるノードから複製データを保持するノードが選択されているので、データを損失させず、継続して処理を行うことができる。

請求項２に記載の発明は、前記ノードが、前記クラスタを構成する前記ノードの障害発生情報を取得した場合に、障害の発生により離脱したノードのＩＤと当該ノードの前記位置情報とを、前記ノード管理情報から削除する更新を行うノード識別子管理部をさらに備え、前記データ複製処理部が、前記ノード管理情報が更新されると、前記複製データの配置先となる前記ノードの決定処理を、再度実行することを特徴とする請求項１に記載のノードとした。

このようにすることで、クラスタを構成するノードが離脱したことにより、少なくともＭ−Ｘ個は、位置情報がそれぞれ異なるようにして、複製データを配置するという条件を満たさなくなった場合においても、再度、データ複製処理部が複製データの配置先となるノードの決定処理を実行することにより、当該条件を満たす複製データの配置に設定することができる。

請求項３に記載の発明は、前記ノードが、前記クラスタに参加する新たなノードの前記ＩＤ空間における挿入位置を決定する際に、所定のＩＤ割当手法において選択された挿入位置の両側それぞれＭ−１個のノードの属する前記位置情報を、前記ノード管理情報を参照して確認し、Ｍ−Ｘ個以上のノードの位置情報が、新たに挿入するノードの位置情報と異なる場合に、前記選択された挿入位置を、前記参加する新たなノードのＩＤとして決定するノード配置決定部を、さらに備えることを特徴とする請求項１または請求項２に記載のノードとした。

このようにすることにより、ＩＤ空間における挿入位置の両側それぞれＭ−１個のノードの属する地域を示す位置情報のうち、Ｍ−Ｘ個以上の位置情報が、新たに挿入するノードの位置情報と異なることが保証される。よって、ノード参加時毎に、ノード配置決定部によるノード挿入位置決定処理を繰り返すことにより、同一地域のノードがＩＤ空間上において、隣り合う状況となる場合を低減することができる。これにより、ノード離脱時のデータ取得や複製データの偏りが発生することを抑えることができる（詳細は後記する）。

請求項４に記載の発明は、コンピュータを請求項１乃至請求項３のいずれか一項に記載のノードとして機能させるためのプログラムとした。

これによれば、このようなプログラムを実装したコンピュータを本発明のノードとして機能させることができる。

本発明によれば、激甚災害等の広いエリアにおいて複数台のノードが同時に離脱した場合においても、データを損失させず、継続処理を可能とするノードおよびプログラムを提供することができる。

本発明の第１の実施形態に係るノードを含む分散システムの全体構成を示す図である。 本発明の第１の実施形態に係るノードの構成例を示す機能ブロック図である。 本発明の第１の実施形態に係るノード管理テーブルのデータ構成例を示す図である。 本発明の第１の実施形態に係る死活監視テーブルのデータ構成例を示す図である。 本発明の第１の実施形態に係るノード（データ複製処理部）が行うデータの複製先決定処理の流れを示すフローチャートである。 本実施形態におけるデータ複製先決定処理の具体例を説明するための図である。 本発明の第２の実施形態に係るノードの構成例を示す機能ブロック図である。 本発明の第２の実施形態に係るノードの課題を説明するための図である。（ａ）は、ノード離脱時のデータ取得の処理の発生を説明するための図である。（ｂ）は、複製データの偏りを説明するための図である。 本発明の第２の実施形態に係るノードのノード離脱時における課題を説明するための図である。 本発明の第２の実施形態に係るノード（ノード配置決定部）が行う、ノード参加時のＩＤ空間におけるノード挿入位置決定処理の流れを示すフローチャートである。 ノード参加時のＩＤ空間におけるノード挿入位置決定処理を説明するための図である。 本発明の第２の実施形態に係るノードが行う、ノード離脱時のノード管理テーブルの更新処理の流れを示すフローチャートである。 ノード離脱時のデータ複製先の決定処理を説明するための図である。 コンシステントハッシュ法によるデータ管理手法を説明するための図である。 コンシステントハッシュのＩＤ空間上に、新たにノードが参加した場合の動作例を説明するための図である。 コンシステントハッシュに基づきデータ管理を行う分散システムを、１種類のデータセンタエリアに配置した例を示す図である。 従来のコンシステントハッシュのＩＤ空間上で、原本データと複製データとが同時に失われる可能性を説明するための図である。

≪第１の実施形態≫
次に、本発明を実施するための形態（以下、「本実施形態」と称する。）について説明する。

＜分散システムの全体構成＞
まず、本発明の第１の実施形態に係るノード１を含む分散システム１０００の全体構成について説明する。
図１は、本発明の第１の実施形態に係るノード１を含む分散システム１０００の全体構成を示す図である。

この分散システム１０００は、各クライアント２からのメッセージを受け付けるロードバランサ３と、振り分け装置４と、クラスタを構成する複数のノード１とを含んで構成される。ロードバランサ３は、クライアント２からのメッセージを単純なラウンドロビン法等により各振り分け装置４に振り分ける。振り分け装置４は、受信したメッセージを、例えば、コンシステントハッシュ法等に基づき、各ノード１に振り分ける。各ノード１では、メッセージ処理を行い、クライアント２にサービスを提供する。

図１においては、振り分け装置４とノード１とを別装置として記載したが、同一サーバ上で別々の機能として動作させることも可能である。また、振り分け装置４も、図１に示すように、クラスタ構成をとることができる。さらに、ロードバランサ３が存在せず、クライアント２から任意の振り分け装置４にメッセージを送信することも可能である。

＜処理概要＞
本発明の第１の実施形態に係るノード１は、自身が原本として格納するデータについて、複製データを配置する際に、配置先の候補となるノードの物理位置（エリア等の位置情報）を確認し、自身が属するエリア（後記において、「データセンタエリア」や「拠点」と称する。）と異なるエリアのノードに少なくとも所定数は複製データが配置されるように処理する。つまり、ノード１は、複製データの配置時に、ノードの物理位置（エリア等の位置情報）を利用し、他のエリアのノード１に対して複製データを配置する。

このように他のエリアのノード１に複製データを配置することで、本発明の第１の実施形態に係るノード１を含む分散システム１０００によれば、激甚災害等により広いエリアで複数台のノード１が同時に障害発生等により離脱した場合であっても、データを損失させず、継続して処理を行うことが可能となる。

＜ノード＞
次に、本発明の第１の実施形態に係る分散システム１０００を構成するノード１について、具体的に説明する。なお、本実施形態に係るノード１は、分散システム１０００の複数のノード１のうち、後記するノード管理テーブル１００（ノード管理情報）を管理する特権ノードとなる場合と、特権ノードからノード管理テーブル１００の情報を受け取り自身のノード管理テーブル１００を更新する特権ノードではない場合とが存在する。なお、特権ノードが行う処理等については、後記する。

図２は、本発明の第１の実施形態に係るノード１の構成例を示す機能ブロック図である。
ノード１は、図１に示したように、各振り分け装置４と通信可能に接続されると共に、クラスタを構成する自身以外の他のノード１とも通信可能に接続される。そして、クライアント２からのメッセージを受信し、サービスを提供する。また、このノード１は、自身が原本データとして保持する情報を、後記する複製データの配置のための所定の条件を満たす他のノード１に対して送信することにより、他のノード１に複製データを保持させる。
このノード１は、図２に示すように、制御部１０と、入出力部１１と、記憶部１２とを含んで構成される。

入出力部１１は、振り分け装置４や、自身以外の他のノード１との間の情報の入出力を行う。また、この入出力部１１は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。

制御部１０は、ノード１全体の制御を司り、ノード識別子管理部１０１、メッセージ処理部１０２、データ複製処理部１０３、死活監視部１０４を含んで構成される。なお、この制御部１０は、例えば、記憶部１２に格納されたプログラムをＣＰＵ（Central Processing Unit）がＲＡＭ（Random Access Memory）に展開し実行することで実現される。

ノード識別子管理部１０１は、クラスタを構成する各ノード１に関する識別情報と物理位置（エリア等の位置情報）に関する情報とを、ノード管理テーブル１００（ノード管理情報：図３参照）として管理する。ノード識別子管理部１０１は、自身が特権ノードである場合に、クラスタへのノード１の追加や離脱の情報を受信し、自身が保持するノード管理テーブル１００の情報を更新する。そして、ノード識別子管理部１０１は、その更新したノード管理テーブル１００の更新情報を、クラスタ内の自身以外の他のノード１や振り分け装置４に送信する。
また、ノード識別子管理部１０１は、自身が特権ノードではない場合には、特権ノードからノード管理テーブル１００の情報（更新情報）を受信し、自身が保持するノード管理テーブル１００を更新する。
このようにすることにより、クラスタ内の各ノード１は、常に、同一内容のノード管理テーブル１００を備える。
なお、ノード識別子管理部１０１は、ノード管理テーブル１００が更新された場合、つまり、ノード１の追加や離脱があった場合に、データ複製処理部１０３に対して、複製データの再配置を実行させるため、データ複製指示を出力する。また、ノード管理テーブル１００の更新により原本データの再配置が必要になった場合には、図示しない原本データ再配置部に対して、原本データ再配置指示を出力し、同部は原本データの再配置を実行する。

図３は、本発明の第１の実施形態に係るノード管理テーブル１００（ノード管理情報）のデータ構成例を示す図である。図３に示すように、ノード管理テーブル１００は、クラスタを構成する各ノード１のノード識別子１１０、サーバ名（アドレス）１２０および地域ＩＤ１３０を含んで構成される。

このノード識別子１１０は、コンシステントハッシュ法のＩＤ空間上でのノードＩＤに対応する。また、コンシステントハッシュ法において仮想ＩＤを用いる場合には、ノード識別子１１０は、仮想ＩＤ毎に割り当てられ、ノード管理テーブル１００に登録される。そして、このノード管理テーブル１００では、例えば、コンシステントハッシュのＩＤ空間におけるＩＤ（または仮想ＩＤ）を昇順に並べて管理する。つまり、ノード管理テーブル１００において、ノード識別子１１０（ノードＩＤ）を昇順に並べたときの自身のノード１の行の次の行のノード１が、ＩＤ空間上での右隣（時計回りに次）のノード１となる。
例えば、図３においては、コンシステントハッシュのＩＤ空間に基づくデータ識別子が「０」から「５６」であるデータについては、同図の第１行目に指すノード（ノード識別子「５６」、サーバ名「サーバＡ」であるノード）がそのデータに関する処理（原本データの記憶や更新、データの抽出等を含む）を担当する。同様に、データ識別子が「５６」に１を加えた「５７」から「１７２」であるデータについては、第２行目に指すノード（ノード識別子「１７２」、サーバ名「サーバＢ」であるノード）がそのデータに関する処理を担当する。以下、同様である。

サーバ名（アドレス）１２０は、クラスタを構成する各ノード１の識別子を表す。このサーバ名１２０は、ノード１それぞれのアドレス（例えば、ＩＰアドレス）に対応付けられて記憶される。

地域ＩＤ１３０は、物理位置（エリア等の位置情報）に関する情報であるデータセンタエリア（Ｋ種類）の識別子を表す。例えば、地域ＩＤ１３０が「００」は「データセンタエリアα（九州エリア）」を表し、地域ＩＤ１３０「０１」は、「データセンタエリアβ（関西エリア）」を表し、地域ＩＤ１３０が「０２」は、「データセンタエリアγ（関東エリア）」を表す。

なお、このノード管理テーブル１００のノード識別子１１０は、特権ノードのノード識別子管理部１０１が各ノード１に対して付与することもできるし、外部装置（例えば、ネットワーク管理装置等）が各ノード１に対して付与したノード識別子１１０を受信して格納することも可能である。また、後記するように、特権ノードを設けず、分散システム１０００についての管理装置を設け、その管理装置が、ノード管理テーブル１００に関するノード１の離脱や追加（参加）を管理し、更新したノード管理テーブル１００を各ノード１に配信するようにしてもよい。
さらに、このノード管理テーブル１００には、処理で必要となる他の付加情報（例えば、各ノード１のクラスタへの参加日時等）を加えることも可能である。

このノード識別子管理部１０１は、自身が特権ノードである場合に、自身の死活監視部１０４や、特権ノードでない他のノード１、外部装置（ネットワーク管理装置等）から、ノード１の離脱の情報を受信した場合に、ノード管理テーブル１００において、その離脱させるノード１の情報（ノード識別子１１０、サーバ名（アドレス）１２０および地域ＩＤ１３０）を含むレコードを削除する。
また、ノード識別子管理部１０１は、自身が特権ノードである場合に、自身の死活監視部１０４や、特権ノードでない他のノード１、外部装置（ネットワーク管理装置等）から、ノード１の追加（参加）の情報を受信した場合に、所定の手法（例えば、ランダムやＩＤ空間上の最大領域を２分割する方法等）により、待機状態にあるノードの中から追加するノードの識別子（ノード識別子１１０）を決定し、その追加させるノード１の情報（ノード識別子１１０、サーバ名（アドレス）１２０および地域ＩＤ１３０）を含むレコードをノード管理テーブル１００に挿入する。なお、挿入位置は、追加するノード１を含めた昇順に並ぶ位置にそのレコードが追加される。

図２に戻り、メッセージ処理部１０２は、振り分け装置４から振り分けられたメッセージを受信し、そのメッセージの処理を実行し、処理結果をクライアント２に返信することにより、サービスを提供する。また、メッセージ処理部１０２は、メッセージの処理に必要なデータをそのノード１自身が保持していなかった場合には、他のノード１（ノード管理テーブル１００で自身の次の行のノード１、さらに、その次の行のノード１等）に要求すること等により、そのデータを取得することが可能である。
また、メッセージ処理部１０２は、受信したメッセージの処理により、原本データが更新された場合には、更新後の原本データを複製して、複製データとして他のノードに格納させるため、データ複製処理部１０３に対して、データ複製指示を出力する。

データ複製処理部１０３は、自身が保持するデータ（原本データ）について、自身以外の他のノード１を所定の条件に基づき選択して、そのデータを送信することにより、他のノード１に複製データを保持させる。これにより、データの冗長化を実現する。複製データを複数生成する場合には、さらに他のノード１にデータを送信することにより、複製データを保持させる。
ここで、データの冗長数（原本データと複製データの合計数）をＭ（≧２）、あるデータ（原本データおよび複製データとの合計Ｍ個）について激甚災害等の大規模障害で同時に失われて良いと設定するデータ数をＸ（１≦Ｘ＜Ｍ）とおく。データ複製処理部１０３は、データ複製時に、ＩＤ空間を自身のノードＩＤから時計回り（右回り）にみた際に、Ｍ−Ｘ個は、原本データおよび複製データを保持する拠点（データセンタエリア）それぞれが異なるようにノード１を選択して複製データを配置する。なお、このＭ−Ｘ個は、大規模障害後でも失われない、拠点が異なるノードの数に相当する。ここで、本実施形態においては、Ｋ種類（箇所）の拠点のうち、２種類（箇所）以上で激甚災害が同時に発生しないことを前提とする。このデータ複製処理部１０３によるデータの複製先決定処理については、図５および図６を参照して詳細に説明する。

死活監視部１０４は、死活監視テーブル２００（後記する図４）を参照して、指定されたノード１（例えば、自身の次の行のノード）と所定の時間間隔で死活監視信号のやり取りを行い、クラスタを構成するノード１の障害を検出する。ノード１の障害を検出した場合、死活監視部１０４は、自身が特権ノードの場合はノード識別子管理部１０１に、自身が特権ノードでない場合は特権ノードに通知（障害発生通知）を行う。なお、後記するように、特権ノードを設けず、ノード管理テーブル１００を管理する管理装置を設けた場合には、各ノード１の死活監視部１０４は、その管理装置に対して、障害発生通知を送信する。

図４は、本発明の第１の実施形態に係る死活監視テーブル２００のデータ構成例を示す図である。
死活監視テーブル２００は、１台の物理装置を単位として作成され、監視対象となるノード１（サーバ）がリスト化されたものである。死活監視テーブル２００には、例えば、サーバ名とそれに紐付くアドレス（ＩＰアドレス）とが記憶される。

死活監視テーブル２００は、論理装置（仮想ノード）単位でノードが構成されるパターンを考慮して、その論理装置を構築する物理装置が少なくとも１回は監視対象となるように設定される。また、クラスタを構成するノード１に追加や離脱があった場合、ノード管理テーブル１００と同期的に更新されるものとする。よって、ノード管理テーブル１００のノード識別子１１０が、論理装置単位で構成された仮想ＩＤによるものではなく、物理装置単位のＩＤである場合には、死活監視テーブル２００とノード管理テーブル１００とについて、同一のものを用いてもよい。また、この場合、死活監視テーブル２００を生成せず、ノード管理テーブル１００を用いて、死活監視部１０４が各ノード１の死活監視を行うようにしてもよい。

ここで、クラスタ内における複数のノード１の中から特権ノードを決定する処理について説明する。
各ノードは、ノード管理テーブル１００に付加情報として、前記したように、各ノード１のクラスタへの参加日時等が格納されている場合、その参加日時が古い順に、特権ノードが選択されるようにしてもよい。また、各ノード１は、死活監視テーブル２００を参照し、死活監視テーブル２００の一番上の行から順に、特権ノードとなるように設定してもよい。
ノード１が新たに特権ノードになった場合、自身が特権ノードであることを示す情報を、各ノード１等に送信する。そして、特権ノードは、クラスタ内のノード１に離脱や追加（参加）があった場合に、自身のノード管理テーブル１００を更新し、その更新情報を各ノード１や振り分け装置４等に配信する。

図２に戻り、記憶部１２は、ハードディスクやフラッシュメモリ、ＲＡＭ等の記憶手段からなり、処理の対象となる原本データや複製データ（いずれも不図示）、前記したノード管理テーブル１００（図３参照）や死活監視テーブル２００（図４参照）が記憶される。また、記憶部１２には、データ複製処理部１０３が用いる各パラメータの値（Ｍ：冗長数、Ｘ：Ｍ個のうち大規模障害で同時に失われて良いと設定するデータ数）が記憶される。

＜処理の流れ＞
次に、本発明の第１の実施形態に係るノード１のデータの複製先決定処理の流れについて、図５および図６を参照して説明する。

図５は、本発明の第１の実施形態に係るノード１（データ複製処理部１０３）が行うデータの複製先決定処理の流れを示すフローチャートである。図６は、本実施形態におけるデータ複製先決定処理の具体例を説明するための図である。
ここでは、データの冗長数Ｍ（Ｍ≧２）と、大規模障害等で同時に失われて良いと設定するデータ数Ｘ（１≦Ｘ＜Ｍ）が、予めノード１の記憶部１２に記憶されているものとする。
データ複製処理部１０３は、データ複製時に、ＩＤ空間を自身のノードのノードＩＤから時計回り（右回り）に見た際に、少なくともＭ−Ｘ個は拠点（データセンタエリア）が異なるノードに複製データを配置する処理を行う。Ｍ−Ｘ個を超える複製データについては、通常のコンシステントハッシュの配置手法に従い、すでに複製データが配置されているノードを除いたノードのうち、時計回りに一番近いノードに複製データを配置する。
なお、ここでは、図５のフローチャートとともに、図６（ａ）に示す（Ｍ＝４、Ｘ＝２）の場合を具体例として合わせて説明する。

まず、データ複製処理部１０３は、ノード識別子管理部１０１やメッセージ処理部１０２から、データ複製指示を受信する（ステップＳ１０）。

次に、データ複製処理部１０３は、記憶部１２のノード管理テーブル１００を参照し、自身の位置情報（地域ＩＤ１３０：拠点（データセンタエリア））を確認する（ステップＳ１１）。
図６（ａ）においては、データＡが、「●（黒丸）」において示される拠点（データセンタエリア）に配置されたノードのハッシュＩＤ範囲に含まれるもの、つまり、「●（黒丸）」の拠点（データセンタエリア）に属するノードが原本データを保持するものとして説明する。する。なお、図６（ｂ）〜（ｅ）も同様である。

続いて、データ複製処理部１０３は、複製データの配置数を「０」に初期化する（ステップＳ１２）。

そして、データ複製処理部１０３は、前回確認したノードを起点（初回は、原本ノードを保持するノードを起点）に、ＩＤ空間上で右隣のノードの位置情報（地域ＩＤ１３０：拠点（データセンタエリア））を確認する（ステップＳ１３）。つまり、データ複製処理部１０３は、ノード管理テーブル１００を参照し、前回確認したノード（サーバ）の行（初回は、原本ノードを保持する自身のノードの行）の次のノード（サーバ）の行の地域ＩＤ１３０を確認する。
図６（ａ）においては、ＩＤ空間上の右隣のノードの地域ＩＤ１３０は、「□（白四角）」において示される拠点（データセンタエリア）となる。

次に、データ複製処理部１０３は、ステップＳ１３において確認した位置情報（地域ＩＤ１３０：拠点（データセンタエリア））が、原本データ若しくは複製データを既に配置したノードの位置情報（地域ＩＤ１３０：拠点（データセンタエリア））と一致するか否かを判定する（ステップＳ１４）。そして、一致する場合には（ステップＳ１４→Ｙｅｓ）、ステップＳ１３に戻り、ＩＤ空間において次の右隣のノードの位置情報を確認する。一方、一致しない場合には（ステップＳ１４→Ｎｏ）、次のステップＳ１５に進む。
図６（ａ）に示す例において、ステップＳ１３で「□（白四角）」の拠点（データセンタエリア）が確認され、ステップＳ１１で確認された原本データの配置されるノードである「●（黒丸）」の拠点（データセンタエリア）と異なる。よって、ここでは、ステップＳ１５に進む。

続いて、データ複製処理部１０３は、ステップＳ１５において、ステップＳ１３で確認した右隣のノードに複製データを配置する。
図６（ａ）に示す例においては、原本データを格納するノード（「１番目」とする。）から数えて２番目のノードであり、「□（白四角）」のデータセンタエリアに属するノードに複製データが配置される。なお、図６（ａ）においては、配置順を説明するために［１］と表記する。

そして、データ複製処理部１０３は、複製データの配置数を「＋１」とする（ステップＳ１６）。
図６（ａ）に示す例においては、複製データの配置数が「１」となる。

次に、データ複製処理部１０３は、複製データの配置数が、Ｍ−Ｘよりも小さいか否かを確認する（ステップＳ１７）。そして、条件を満たす場合に（ステップＳ１７→Ｙｅｓ）、ステップＳ１３に戻る。一方、条件を満たさない場合には（ステップＳ１７→Ｎｏ）、次のステップＳ１８に進む。
図６（ａ）に示す例においては、複製データの配置数が「１」であり、Ｍ−Ｘ＝２であるので条件を満たし（ステップＳ１７→Ｙｅｓ）、ステップＳ１３に戻る。そして、データ複製処理部１０３は、ＩＤ空間上で右隣のノードの位置情報（地域ＩＤ１３０：拠点（データセンタエリア））を「△（白三角）」のデータセンタエリアと確認する（ステップＳ１３）。さらに、この「△（白三角）」のデータセンタエリアは、既に配置したノードの位置情報（地域ＩＤ１３０：拠点（データセンタエリア））と一致しないことから（ステップＳ１４→Ｎｏ）、データ複製処理部１０３は、この右隣の「△（白三角）」のデータセンタエリアのノードに複製データを配置し（ステップＳ１５）（図６（ａ）において、２番目に複製データが配置されたことを示す［２］と表記）、複製データの配置数を「＋１」して「２」とする（ステップＳ１６）。そして、ステップＳ１７において、複製データの配置数「２」が、Ｍ−Ｘ（＝２）よりも小さいという条件を満たさないため（ステップＳ１７→Ｎｏ）、次のステップＳ１８に進む。

次に、ステップＳ１８において、データ複製処理部１０３は、複製データの配置数が、冗長数Ｍ−１よりも小さいか否かを判定する。そして、この条件を満たさない場合には（ステップＳ１８→Ｎｏ）、データ複製先の決定処理を終了する。一方、この条件を満たす場合には（ステップＳ１８→Ｙｅｓ）、次のステップＳ１９に進む。
図６（ａ）に示す例においては、複製データの配置数が「２」であり、冗長数Ｍ−１が「３」であるので、条件を満たし（ステップＳ１８→Ｙｅｓ）、次のステップＳ１９に進む。

ステップＳ１９において、データ複製処理部１０３は、複製データを配置するノード配置の起点を原本ノードに戻す。
図６（ａ）に示す例においては、原本データを保持する「●（黒丸）」の拠点（データセンタエリア）に属するノードに起点が戻される。

続いて、データ複製処理部１０３は、前回確認したノードを起点（ここでの初回は、原本ノードを保持するノードを起点）に、ＩＤ空間上で右隣のノードの位置情報（地域ＩＤ１３０：拠点（データセンタエリア））を確認する（ステップＳ２０）。
図６（ａ）に示す例においては、ＩＤ空間上で原本データを保持するノードの右隣のノードの地域ＩＤ１３０は、「□（白四角）」において示される拠点（データセンタエリア）となる。

続いて、ステップＳ２０において確認したノードが、既に複製データが配置されているか否かを判定する（ステップＳ２１）。そして、既に複製データは配置されている場合には（ステップＳ２１→Ｙｅｓ）、ステップＳ２０に戻り処理を続ける。一方、複製データが配置されていない場合には（ステップＳ２１→Ｎｏ）、次のステップＳ２２に進む。
図６（ａ）に示す例においては、原本データの右隣のノード「□（白四角）」に示されるノードは、すでに複製データが配置されているため、ステップＳ２０に戻る。そして、再び、その右隣の「△（白三角）」に示されるノードにもすでに複製データが配置されているため、再度ステップＳ２０に戻り、その次の右隣の「●（黒丸）」に示されるノードを確認し、ステップＳ２１において、データ複製処理部１０３は、この「●（黒丸）」に示されるノードには、複製データが配置されていないと判定し（ステップＳ２１→Ｎｏ）、次のステップＳ２２に進む。

続いて、データ複製処理部１０３は、ステップＳ２２において、ステップＳ２０において直前に確認したノードに複製データを配置する。
図６（ａ）に示す例においては、原本データを格納するノード（「１番目」）から数えて４番目のノードであり、「●（黒丸）」のデータセンタエリアに属するノードに複製データが配置される（図６（ａ）において（３）と表記）。

そして、データ複製処理部１０３は、複製データの配置数を「＋１」とする（ステップＳ２３）。
図６（ａ）に示す例においては、複製データの配置数が「３」となる。

次に、データ複製処理部１０３は、複製データの配置数が、Ｍ−１よりも小さいか否かを確認する（ステップＳ２４）。そして、条件を満たす場合に（ステップＳ２４→Ｙｅｓ）、ステップＳ２０に戻る。一方、条件を満たさない場合には（ステップＳ２４→Ｎｏ）、データ複製先の決定処理を終了する。
図６（ａ）に示す例においては、複製データの配置数が「３」であり、Ｍ−１＝３であるので条件を満たさず（ステップＳ２４→Ｎｏ）、データ複製先の決定処理を終了する。

なお、このデータ複製先の決定処理（図５）のうち、ステップＳ１０〜Ｓ１７の処理が、少なくともＭ−Ｘ個は、拠点（データセンタエリア）が異なるノードに複製データを配置することを保証するものである。このＭ−Ｘ個の拠点が異なるノードへの複製データの配置が保証される処理において決定された複製先のノードを、図６においては、前記したように角カッコで囲んで、［１］のようにその決定順を示している。また、データ複製先決定処理（図５）のうち、ステップＳ１８〜Ｓ２４の処理は、すでに複製データが配置されているノードを除いたノードのうち、時計回りに一番近いにノードに複製データを配置する処理である。この処理中に決定された複製データの配置先は、図６において、前記したように丸カッコで囲んで、（３）のようにその決定順を示している。
図６（ｂ）および図６（ｃ）は、Ｍ＝４、Ｘ＝２のときの、データ複製先の決定処理の他の例を示している。また、図６（ｄ）および図６（ｅ）は、Ｍ＝３、Ｘ＝１のときの、データ複製先の決定処理の例を示している。
図６（ａ）〜（ｅ）は、いずれも、ＩＤ空間を原本データのノードのノードＩＤから時計回り（右回り）に見た際に、Ｍ−Ｘ個は、原本データおよび複製データを保持する拠点（データセンタエリア）それぞれが異なるように、複製データを配置するノード１が決定されている。また、Ｍ−Ｘ個を超える複製データについては、すでに複製データが配置されているノードを除いたノードのうち、時計回りに一番近いにノードに配置される。

このようにすることで、本実施形態に係るノード１によれば、激甚災害等による大規模障害が発生した場合であっても、少なくともＭ−Ｘ個は拠点（データセンタエリア）の異なるノードから選択されることになるので、データを損失させず、継続して処理を行うことが可能となる。

＜第２実施形態＞
次に、本発明の第２の実施形態に係るノード１Ａについて説明する。
本発明の第１の実施形態に係るノード１においては、複製データの配置時（データの複製先を決定する際）に、ノードの位置情報（地域ＩＤ１３０：拠点（データセンタエリア））を利用し、少なくともＭ−Ｘ個は拠点（データセンタエリア）が異なるノードに複製データを配置する処理を行った。本発明の第２の実施形態に係るノード１Ａは、第１の実施形態に係るノード１の機能（データ複製処理部１０３によるデータの複製先決定処理）に加えて、新たなノードをクラスタに参加させる時点において、複製データの配置先となるノードが異なる拠点から選択されるようにＩＤ空間へのノード挿入位置を決定する。つまり、新たに参加するノードのＩＤ空間上の挿入位置を確認し、激甚災害等により同一拠点のサーバすべてに障害が発生した場合でも、データを損失しないような挿入位置に新たなノードを配置するものである。このようにすることで、複製データの偏りやノード離脱時のデータ取得の処理の発生を抑制することができる（詳細は後記）。以下、具体的に説明する。

図７は、本発明の第２の実施形態に係るノード１Ａの構成例を示す機能ブロック図である。図２において示した第１の実施形態に係るノード１との違いは、第２の実施形態に係るノード１Ａは、第１の実施形態に係るノード１の構成に加えて、ノード配置決定部１０５を備えていることである。その他の構成については、図７において、図２に示した第１に実施形態に係るノード１と同一の名称と符号を付し、説明を省略する。また、分散システム１０００の全体構成も第１の実施形態における図１と同一であるので説明を省略する。
従来のコンシステントハッシュによるデータ管理手法では、クラスタに新たにノードを追加（参加）しようとする場合、サーバの物理位置を考慮せずにその新たに追加するノードを分散（配置）させている。一方、本発明の第２の実施形態に係るノード配置決定部１０５は、ＩＤ空間（ノード管理テーブル１００）に新たなノードを追加しようとする場合、新たなノードを追加するノードＩＤの周囲（左右それぞれ）Ｍ−１個のノードのうちＭ−Ｘ個以上のノードが、追加するノードが属する拠点（データセンタエリア）と異なる拠点（データセンタエリア）となるように配置する。つまり、ノード配置決定部１０５は、Ｍ−Ｘ個のノードの拠点および追加するノードの拠点のそれぞれが異なる拠点となるようなＩＤ空間の挿入位置を、新たに追加するノードの挿入位置として決定する。

（第２の実施形態に係るノード１Ａの課題）
本発明の第１の実施形態に係るノード１においては、激甚災害等による大規模障害が発生した場合であっても、少なくともＭ−Ｘ個は拠点（データセンタエリア）の異なるノードから選択されることになるので、データを損失させず、継続して処理を行うことが可能となるという顕著な効果を奏する。その一方で、この手法を用いた場合、従来のコンシステントハッシュ法によるデータ管理手法と異なり、複製データが、ＩＤ空間上で時計回り（若しくは反時計回り）に隣接するノード１に必ず作成されるものとは限らない。第１の実施形態に係る複製データの配置処理を実行すると、特に隣接ノードが同一拠点のサーバである場合に、その隣接ノードが複製データを保持していない場合がでてくる。このような場合において、原本データを保持したノードに障害が発生すると、原本データを保持したノードの隣接ノードが新たにその原本データのハッシュＩＤ範囲を担当することになるが、原本データを保持していないため、複製データを保持するノード１からそのデータを取得する処理が必要となる。つまり、原本データを保持したノードに障害が発生した場合に、隣接ノードが複製データを保持していないため、他のノードから複製データを取得することなく、処理を継続できるという利点が得られなくなってしまう。以下、具体的に説明する。

図８（ａ）では、データＸ（Ｋｅｙ「Ｘ」）の原本データを保持するノード１がノード「Ａ」であり、本発明の第１の実施形態に係るノード１の複製データ配置手法により複製データが他の拠点のノード「Ｄ」に格納されている例を示している。なお、ノード「Ａ」「Ｂ」「Ｃ」は同一拠点（「●（黒丸）」）のノードである。ここで、ノード「Ａ」に障害が発生した場合を考えると、振り分け装置４は、ノード「Ａ」の障害（離脱）の通知（ノード管理テーブル１００の更新情報）を受けること等により、ＩＤ空間上で時計回りの次のノードであるノード「Ｂ」にデータＸに関するリクエストを送信する。しかしながら、ノード「Ｂ」はデータＸを保持していないため、複製データを保持するノード「Ｄ」からデータを取得してから処理する必要がある。つまり、ノード障害時に複製データを持つノードに自動的に信号が振り分けられる従来の利点が得られなくなる。

また、次に示す複製データを保持するノード１が偏るという課題もある。
同一拠点の異なるサーバのＩＤ（ノード識別子１１０）が、ＩＤ空間上で連続していると、複製データを保持するサーバが偏る可能性がある。図８（ｂ）に示すように、ノード「Ａ」「Ｂ」「Ｃ」が同一拠点（「●（黒丸）」）上にあり連続していると、例えばＭ＝２、Ｘ＝１の場合に、ノード「Ａ」「Ｂ」「Ｃ」のすべてのノードが保持する原本データの複製データが拠点の異なるノード「Ｄ」において保持されることになる。

一方、ノードをクラスタに参加（追加）させる場合、ＩＤ空間におけるサーバの挿入位置の両端（左右）のサーバが属さない拠点（データセンタエリア）に属するサーバをクラスタの参加するサーバとして選択する（図９のＴ１）技術が開示されている（特開２０１３−１８２５４６号公報）。この技術によれば、ＩＤ空間において同じ拠点のサーバは隣り合うことがないので、３つ以上の拠点のうちの１つの拠点に存在するすべてのサーバがダウンしても、データを損失する事態を回避することができる。図９は、クラスタのノードを追加する場合に、Ｍ＝２とし、挿入位置の両端のサーバが属さない拠点のサーバを選択する。しかしながら、この技術は、ノードの参加を行っている時点では問題ないが、図９のＴ２に示すように、ノードの離脱が発生すると、同一拠点の異なるサーバが隣り合う事態が発生してしまうため、激甚災害等の大規模障害が発生した場合に、データを損失する事態が起こる可能性がある。

本発明の第２の実施形態に係るノード１Ａは、本発明の実施形態１に係るデータの複製先決定処理と、ノード１Ａのノード配置決定部１０５による、クラスタへの新たなノードの参加時におけるノード挿入位置決定処理とを組み合わせる。これにより、本発明の第２の実施形態に係るノード１Ａは、上記において説明したコンシステントハッシュの利点を損なわず、複製データの偏りを低減し、ノードの離脱が起こった場合においても、大規模障害に耐えるための条件（少なくともＭ−Ｘ個は、拠点（データセンタエリア）が異なるノードに複製データを配置すること）を満たすデータ配置を実現することができる。

＜処理の流れ＞
次に、本発明の第２の実施形態に係るノード１Ａ（ノード配置決定部１０５）が実行する、クラスタへのノード参加時のＩＤ空間におけるノード挿入位置決定処理について、図１０および図１１を参照して説明する。

≪ノードの参加（追加時）のノード挿入位置決定処理≫
図１０は、本発明の第２の実施形態に係るノード１Ａ（ノード配置決定部１０５）が行う、ノード参加時のＩＤ空間におけるノード挿入位置決定処理の流れを示すフローチャートである。また、図１１は、ノード参加時のＩＤ空間におけるノード挿入位置決定処理を説明するための図である。なお、以下においては、図１０を参照して処理の流れを説明し、適宜図１１を参照して説明を加えるものとする。

図１０に示すように、まず、ノード配置決定部１０５は、ノード管理テーブル１００を参照し、拠点（データセンタエリア）毎に、クラスタを構成するすべてのノードの数（一つの物理ノードに複数の仮想ノードを割り当てている場合には、仮想ノードの数）を合計した値を算出する（ステップＳ３０）。

続いて、ノード配置決定部１０５は、ステップＳ３０で算出した拠点の合計値が、最も小さい拠点のサーバ（ノード１）を選択する（ステップＳ３１）。
図１１では、例として「○（白丸）」の拠点（データセンタエリア）に属する待機中のノード１が選択されたことを示している（図１１のＴ１０）。

次に、ノード配置決定部１０５は、所定のＩＤ割当手法（例えば、ランダムやＩＤ空間上の最大領域を２分割する手法）に従い、ＩＤ空間上におけるＩＤ（挿入位置）の候補を選択する（ステップＳ３２）。
図１１では、例として「△（白三角）」で示される拠点のノード１と、「□（白四角）」で示される拠点のノード１との間のＩＤが、挿入位置として選択されたことを示している（図１１のＴ１１）。

そして、ノード配置決定部１０５は、選択された挿入位置から周囲（左右（両側）それぞれ）Ｍ−１個のノードの属する拠点を、ノード管理テーブル１００を参照して確認し、Ｍ−Ｘ個以上のノードの属する拠点が新たに挿入するノードの拠点と異なるか否かを判定する（ステップＳ３３、図１１のＴ１２）。なお、「Ｍ−Ｘ個以上のノードの属する拠点が新たに挿入するノードの拠点と異なる」ことを、以下、「大規模障害に耐えるための挿入条件」と呼ぶことがある。
ここで、この大規模障害に耐えるための挿入条件を満たさない場合は（ステップＳ３３→Ｎｏ）、ステップＳ３２に戻り、所定のＩＤ割当手法を用いて、それまでに選択されたＩＤ（挿入位置）の候補を除いた上で、再度、挿入位置の選択処理を実行して処理を繰り返す。一方、この大規模障害に耐えるための挿入条件を満たす場合には（ステップＳ３３→Ｙｅｓ）、ステップＳ３２で選択したＩＤを、新たに参加するノードのＩＤ空間上の挿入位置として決定する（ステップＳ３４）。そして、処理を終了する。

このようにすることで、クラスタに新たなノード１Ａが参加する際、ノード１Ａ（ノード配置決定部１０５）は、挿入位置の周囲Ｍ−１個のノードが属する拠点のうち、Ｍ−Ｘ個以上のノードの属する拠点が新たに挿入するノードの拠点と異なるように配置することができる。よって、ノード１Ａは、ノード配置決定部１０５のノード挿入位置決定処理に基づく配置をクラスタ内で繰り返すことにより、同一拠点のノードがＩＤ空間上で隣接するケースを低減させて、複製データの偏りやノード離脱時のデータ取得の処理の発生を抑制することができる。

≪ノード離脱時の処理≫
次に、本発明の第２の実施形態に係るノード１Ａによる、ノード離脱時の処理の流れについて説明する。
図１２は、本発明の第２の実施形態に係るノード１Ａが行う、ノード離脱時のノード管理テーブル１００の更新処理の流れを示すフローチャートである。図１３は、ノード離脱時のデータ複製先の決定処理を説明するための図である。

図１２に示すように、まず、ノード１Ａの死活監視部１０４が、死活監視テーブル（図４）を参照して、死活監視信号を他のノード１Ａとやりとりすることにより、クラスタを構成するノード１Ａの障害を検出する（ステップＳ４０）。障害を検出した場合、死活監視部１０４は、自身が特権ノードの場合はノード識別子管理部１０１に、自身が特権ノード以外のノード１の場合は特権ノードに通知を行う。

特権ノードのノード識別子管理部１０１は、ノード離脱が発生したことを示す通知を受信すると、ノード管理テーブル１００を参照し、その離脱したノードに関する行を削除する更新を行う（ステップＳ４１）。そして、特権ノードのノード識別子管理部１０１は、更新したノード管理テーブル１００の更新情報を、クラスタ内のすべてのノード１Ａや振り分け装置４に対して送信する（ステップＳ４２）。

そして、データＡの原本データを保持するノード１Ａは、ノード管理テーブル１００の更新情報を受信し、自身が担当するデータＡの複製データを保持するノード１Ａが離脱したことを検出した場合には、再度、図５に示す、データ複製先の決定処理を実行する（ステップＳ４３）。

このように、再度ノード１Ａがデータ複製先の決定処理を実行することで、ノードの離脱が起こった場合においても、大規模障害に耐えるための条件（少なくともＭ−Ｘ個は、拠点（データセンタエリア）が異なるノードに複製データを配置すること）を満たすデータ配置を実現することができる。

なお、本発明の第２の実施形態に係るノード１Ａは、前記したように、本発明の実施形態１に係るデータの複製先決定処理と、ノード１Ａのノード配置決定部１０５による、クラスタへの新たなノードの参加時におけるノード挿入位置決定処理とを組み合わせるものである。具体的には、ノード１Ａのノード配置決定部１０５の処理をノードの参加の度に行うことにより、図１３（ａ）のノード１の配置で示すように、Ｋ箇所（ここでは３箇所）の拠点が、例えば、「△（白三角）」、「●（黒丸）」、「「□（白四角）」の順に繰り返すように並ぶように（より最適に近い場合において）配置される。なお、図１３は、Ｍ＝３、Ｘ＝２の例を示している。

ここで、コンシステントハッシュのＩＤ空間において、図１３（ａ）に示すような最適な配置がノード１Ａのノード配置決定部１０５により実現できている場合に、原本データ（「データＡ」）の右隣のノードが故障等による障害発生で離脱したとする（図１３（ａ）参照）。このとき、原本データを保持するノードは、冗長数Ｍ＝３を保つため、データ複製先の決定処理を再度実行し、複製データの配置先を決定し直す（図１３（ｂ）参照）。これにより、大規模障害に耐えるための条件を満たすデータ配置を実現することができる。また、ノード参加時にノード挿入位置決定処理が行われているため、同一拠点の異なるサーバのＩＤ（ノード識別子１１０）が、ＩＤ空間上で連続するケースが低減されるため、複製データの偏りやノード離脱時のデータ取得の処理の発生が抑制されるものとなる。

以上より、本発明の第２の実施形態に係るノード１Ａによれば、ノード参加時には、ノード配置決定処理により、サーバの選択とＩＤ挿入位置が決定されるため、挿入位置の周囲Ｍ−１個のノードが属する拠点のうち、Ｍ−Ｘ個以上のノードの属する拠点が新たに挿入するノードの拠点と異なることが保証される。一方で、複製データの配置は、データ複製処理部１０３により、仮にノードが離脱して、上記の条件（大規模障害に耐えるための条件）を満たさなくなった場合であっても、再度、複製データの配置先を決定することにより、条件を満たすデータ配置を実現することができる。また、ノード参加時のノード配置決定処理により、ノード離脱時のデータ取得や複製データの偏りが出現しにくいものとすることができる。

以上、本発明の実施形態について説明したが、本発明は、ここで説明した実施形態に限定されるものではない。
例えば、本発明の第１および第２の実施形態においては、特権ノードが各ノード１からノードの離脱や追加に関する情報（障害等の情報）を取得し、特権ノードが保持するノード管理テーブル１００を更新して、その更新情報を各ノード１等に配信するものとした。しかしながら、この実施形態に限定されず、例えば、各ノード１や振り分け装置４と接続された管理装置を設け、その管理装置が、各ノード１から障害等の情報を取得し、ノード管理テーブル１００を更新して各ノード１に配信するようにしてもよい。
また、第２の実施形態においてノード１Ａが備えたノード配置決定部１０５（図７参照）の機能をノード配置決定手段として、前記した管理装置に備えるようにしてもよい。この場合、管理装置には、各ノード１と同一のノード管理テーブル１００が格納されており、クラスタに新たなノードを参加させる際に、管理装置が備えるノード配置決定手段が、ＩＤ空間におけるノード挿入位置決定処理（図１０参照）を実行する。

１，１Ａ ノード
２ クライアント
３ ロードバランサ
４ 振り分け装置
１０ 制御部
１１ 入出力部
１２ 記憶部
１００ ノード管理テーブル（ノード管理情報）
１０１ ノード識別子管理部
１０２ メッセージ処理部
１０３ データ複製処理部
１０４ 死活監視部
１０５ ノード配置決定部
１０００ 分散システム

Claims (4)

1. 環状のＩＤ（IDentifier）空間に、処理対象の複数のデータのＩＤ、および、クラスタを構成し前記データに関するリクエストを処理する複数のノードのＩＤが、割り当てられ、前記ＩＤ空間において前記データのＩＤから所定方向回りに辿って最初に遭遇した前記ノードまでの間に位置する前記データを当該ノードが原本データとして保持するとともに、前記クラスタ内の自身以外の他のノードに前記原本データの複製である複製データを保持させる分散システムの前記ノードであって、
   前記ＩＤ空間における、前記ノードそれぞれのＩＤを、前記ノードそれぞれが物理的に存在する地域を示す位置情報に対応付けたノード管理情報、前記クラスタ内における前記データの前記原本データおよび前記複製データの保持数である冗長数（Ｍ（≧２））、並びに、前記原本データおよび前記複製データのうち障害により同時に失われても良いと設定するデータ数（Ｘ）を記憶する記憶部と、
   前記ノード管理情報の前記位置情報を参照することにより、前記ＩＤ空間の自身のノードのＩＤから所定方向回りに辿って遭遇する前記ノードのうち、少なくともＭ−Ｘ個は、前記原本データおよび前記複製データを保持する前記ノードの地域を示す前記位置情報がそれぞれ異なるように、前記複製データの配置先となる前記ノードを決定するデータ複製処理部と、
   を備えることを特徴とするノード。
2. 前記ノードは、
   前記クラスタを構成する前記ノードの障害発生情報を取得した場合に、障害の発生により離脱したノードのＩＤと当該ノードの前記位置情報とを、前記ノード管理情報から削除する更新を行うノード識別子管理部をさらに備え、
   前記データ複製処理部は、前記ノード管理情報が更新されると、前記複製データの配置先となる前記ノードの決定処理を、再度実行すること
   を特徴とする請求項１に記載のノード。
3. 前記ノードは、
   前記クラスタに参加する新たなノードの前記ＩＤ空間における挿入位置を決定する際に、所定のＩＤ割当手法において選択された挿入位置の両側それぞれＭ−１個のノードの属する前記位置情報を、前記ノード管理情報を参照して確認し、Ｍ−Ｘ個以上のノードの位置情報が、新たに挿入するノードの位置情報と異なる場合に、前記選択された挿入位置を、前記参加する新たなノードのＩＤとして決定するノード配置決定部を、さらに備えること
   を特徴とする請求項１または請求項２に記載のノード。
4. コンピュータを請求項１乃至請求項３のいずれか一項に記載のノードとして機能させるためのプログラム。

Images