JP5449471B2 - 共有データに対する更新処理の同期処理方法、データ共有システムおよびデータ共有プログラム - Google Patents

Description

本発明は、共有データに対する更新処理の同期処理方法、データ共有システムおよびデータ共有プログラムに関する。

複数のノードによって共有データを扱う分散システムでは、各ノードが共有データのコピーを重複して個別に保持する。特許文献１には、このようなデータ共有装置の構成の例が記載されている。特許文献１の構成では、各ノードが非同期処理によって更新を反映する。

特開２０１０−１２２７２４号公報

しかしながら、従来の構成では、共有データの更新が発生した場合において、ノード間のデータを同期させる処理が遅延するという問題があった。

たとえば、特許文献１の構成は、処理順序に依存しない更新関数を使用するシステムにしか適用できず、更新の順序性が要求される場合には全ノードの排他制御が必要となり、処理遅延により性能が低下する。
また、更新が発生した時刻に基づいて同期処理を行うシステムでは、ある時刻以前の更新処理が反映されているか否かを簡単に確認する方法がない。また、反映されていない処理を発見した場合の対応に時間がかかる。
さらに、更新処理の順序を表す通し番号に基づいて同期処理を行うシステムでは、同期処理間の依存関係を簡単に確認する方法がなく、依存関係のない独立した更新処理に遅延が発生した場合でも後続の更新処理すべてに遅延が波及する。

この発明は、このような問題点を解決するためになされたものであり、共有データの更新が発生した場合において、整合性を維持しながらノード間のデータを高速に同期させられる同期処理方法、データ共有システムおよびデータ共有プログラムを提供することを目的とする。

上述の問題点を解決するため、この発明に係る共有データに対する更新処理の同期処理方法は、複数のノードによって共有される共有データに対する更新処理の同期処理方法であって、共有データに対して、互いに順序関係を有する複数の更新処理が実行され、複数の更新処理のうち少なくとも２つが、それぞれ異なるノードによって実行され、各ノードには、更新処理を要求したアプリケーションを識別するサービスＩＤのいずれかが関連付けられる更新処理の同期処理方法において、ノードの少なくとも１つが、更新処理の起点ノードとして、
‐更新されるデータを識別するデータキーと、
‐更新後のデータ内容を表すデータボディと、
‐更新処理よりも順序関係において先の更新処理を識別するプレイベントＩＤと、
‐先の更新処理を要求したアプリケーションを識別するプレサービスＩＤと、
‐先の更新処理によって更新されたデータを識別するプレデータキーと、
を取得するステップと、
起点ノードが、
‐当該更新処理を識別するイベントＩＤと、
‐データキーと、
‐データボディと、
‐プレイベントＩＤと、
‐プレサービスＩＤと、
‐プレデータキーと、
を含む反映要求メッセージを、他のノードに送信するステップと、
反映要求メッセージを受信したノードが、更新処理の反映ノードとして、プレイベントＩＤと、当該反映要求メッセージより前に受信されたイベントＩＤとに基づき、その反映ノードにおいて先の更新処理がすでに実行されたか否かを判定するステップと、
反映ノードにおいて先の更新処理が実行されていない場合に、その更新反映ノードが、
‐プレサービスＩＤと、
‐プレデータキーと、
を含む欠落データ要求メッセージを、他のノード（ただし起点ノードを含んでもよい）に送信するステップと、
欠落データ要求メッセージに含まれるプレサービスＩＤに対応するノードが、欠落データ要求メッセージに含まれるプレデータキーによって識別されるデータボディを含む欠落データ応答メッセージを、反映ノードに送信するステップと
を含む。

反映要求メッセージ、欠落データ要求メッセージおよび欠落データ応答メッセージは、いずれもブロードキャスト方式のメッセージであってもよい。
欠落データ要求メッセージは、イベントＩＤおよびプレイベントＩＤのいずれも含まないものであってもよい。
反映ノードにおいて、欠落データ要求メッセージを送信するステップは、反映要求メッセージを受信した後、所定時間が経過するまでは実行されないものであってもよい。
各ノードは、演算手段および記憶手段を備えるコンピュータによって構成されてもよい。

この発明に係るデータ共有システムは、複数のノードを備え、上述の方法を実行する。

この発明に係るデータ共有プログラムは、コンピュータを、上述の
‐起点ノード、
‐反映ノード、および
‐欠落データ応答メッセージを送信するノード
として機能させる。

この発明に係る共有データに対する更新処理の同期処理方法は、複数のノードによって共有される共有データに対する更新処理の同期処理方法であって、共有データに対して、互いに順序関係を有する複数の更新処理が実行され、複数の更新処理のうち少なくとも２つが、それぞれ異なるノードによって実行され、各ノードには、更新処理を要求したアプリケーションを識別するサービスＩＤのいずれかが関連付けられる更新処理の同期処理方法において、ノードの少なくとも１つが、更新処理の起点ノードとして、
‐更新されるデータを識別するデータキーと、
‐更新後のデータ内容を表すデータボディと、
‐更新処理よりも順序関係において先の更新処理を識別するプレイベントＩＤと、
‐先の更新処理を要求したアプリケーションを識別するプレサービスＩＤと、
‐先の更新処理によって更新されたデータを識別するプレデータキーと、
を取得するステップと、
起点ノードが、
‐当該更新処理を識別するイベントＩＤと、
‐データキーと、
‐データボディと、
‐プレイベントＩＤと、
‐プレサービスＩＤと、
‐プレデータキーと、
を含む反映要求メッセージを、他のノードに送信するステップと、
反映要求メッセージを受信したノードが、更新処理の反映ノードとして、プレイベントＩＤと、当該反映要求メッセージより前に受信されたイベントＩＤとに基づき、その反映ノードにおいて先の更新処理がすでに実行されたか否かを判定するステップと、
反映ノードにおいて先の更新処理が実行されていない場合に、その更新反映ノードが、
‐プレサービスＩＤと、
‐プレデータキーと、
を含む欠落データ要求メッセージを、他のノード（ただし起点ノードを含んでもよい）に送信するステップと、
欠落データ要求メッセージに含まれるプレサービスＩＤに対応するノードが、欠落データ要求メッセージに含まれるプレデータキーによって識別されるデータボディを含む欠落データ応答メッセージを、反映ノードに送信するステップと
を含むので、整合性を維持しながらノード間のデータを高速に同期させることができる。
また、この発明に係るデータ共有システムは、複数のノードを備え、上述の方法を実行するので、整合性を維持しながらノード間のデータを高速に同期させることができる。
また、この発明に係るデータ共有プログラムは、コンピュータを、上述の
‐起点ノード、
‐反映ノード、および
‐欠落データ応答メッセージを送信するノード
として機能させるので、整合性を維持しながらノード間のデータを高速に同期させることができる。

本発明の実施の形態１に係るデータ共有システムの構成の例を示す図である。 図１のノードの構成の例を示す図である。 図１の共有データ保存領域の構成の例を示す図である。 図１の更新履歴情報の構成の例を示す図である。 更新処理の順序関係の例を示す図である。 各ノードの共有データ処理部の動作の概要を示すフローチャートである。 更新依頼の構成を示す図である。 図６のステップＳ２の詳細を示すフローチャートである。 反映要求メッセージの構成の例を示す図である。 図６のステップＳ４の詳細を示すフローチャートである。 欠落データ要求メッセージの構成の例を示す図である。 欠落データ応答メッセージの構成の例を示す図である。 図６のステップＳ７の詳細を示すフローチャートである。 各ノードの処理の流れの例を説明する図である。

以下、この発明の実施の形態を添付図面に基づいて説明する。
実施の形態１．
図１に、本発明の実施の形態１に係るデータ共有システムの構成の例を示す。このデータ共有システムは、複数のノードによって共有される共有データに対する更新処理を扱うものであり、本発明の実施の形態１に係る同期処理方法を実行する。

データ共有システムは、データを共有する複数のノードＡ、Ａ’、Ｂ、Ｂ’、Ｃ、Ｃ’を備える。各ノードには、ノードを一意に識別するノードＩＤ（図１には示さず）が関連付けられる。また、各ノードは、通信ネットワーク１００を介して互いに通信可能に接続される。通信ネットワーク１００はたとえばＬＡＮであり、少なくともブロードキャスト方式の通信を可能とする。

各ノードは、それぞれ異なるアプリケーションを実行する（ただし同一のアプリケーションを実行するノードを含んでもよい）。すなわち、複数の更新処理が、場合に応じて異なるノードによって実行される。また、各ノードは、それぞれが格納する共有データを互いに同期させるよう動作する。すなわち、図１のシステムは、アプリケーション分散型のデータ共有システムである。

ノードのうち少なくとも１つは、ノード障害に備えて冗長に構成される。すなわち、通常時にアプリケーションを実行するマスタノードと、マスタノードに障害が発生した際にマスタノードに代わってアプリケーションを実行するスレーブノード（１つまたは複数。待機ノードとも呼ばれる）との組が構成される。図１の例では、ノードＡ、Ｂ、Ｃがマスタノードであり、ノードＡ’、Ｂ’、Ｃ’がそれぞれ対応するスレーブノードである。
スレーブノードは、対応するマスタノードが正常に動作している間はアプリケーションを実行せず、データ同期処理のみを実行する。そして、対応するマスタノードにおいて障害が発生した場合には、スレーブノードがマスタノードと同一のアプリケーションを実行する。

マスタノードとスレーブノードとは、アプリケーションを一意に識別するサービスＩＤによって関連付けられる。
ただし、待機中のスレーブノードはサービスＩＤを持たない。すなわち、ノードＡ、ＢおよびＣは互いに異なるサービスＩＤを有し、ノードＡ’、Ｂ’およびＣ’はサービスＩＤを持たない。そして、たとえばノードＡにおいて障害が発生すると、ノードＡ’が、それまでのノードＡと同じサービスＩＤを与えられてマスターノードへと切り替わる。

このサービスＩＤは、更新処理を要求したアプリケーションを一意に識別するものである。すなわち、アプリケーションプログラムが、コンピュータを、更新処理を要求するアプリケーションとして機能させ、これによって、コンピュータに更新処理を要求させる。なお、１つのノードで複数のアプリケーションが動作する場合には、１つのノードに複数のサービスＩＤが関連付けられてもよい。

図２に、ノードの構成を示す。ノードＡを例にとって説明するが、他のノードも図２のノードＡと同様の構成を有する。
ノードＡは、周知のコンピュータとしての構成を有し、演算を行う演算手段１０と、情報を格納する記憶手段２０とを備える。演算手段１０はＣＰＵ（中央処理装置）を含み、記憶手段２０は半導体メモリおよびＨＤＤ（ハードディスクドライブ）等の記憶媒体を含む。

演算手段１０は、記憶手段２０に記憶されるデータ共有プログラム（図２には示さず）を実行することにより、本明細書において説明する各機能を実行することができる。たとえば、データ共有プログラムは、演算手段１０をアプリケーション処理部１１、共有データ処理部１２およびネットワーク処理部１３として機能させる。別の表現では、このデータ共有プログラムは、コンピュータを、後述の起点ノード、反映ノード、および応答ノードとして機能させる。

アプリケーション処理部１１は、共有データ処理部１２にアクセス依頼を送信することにより、共有データに対するアクセスを行う。このアクセス依頼の種別の例として、参照依頼および更新依頼がある。また、本実施形態では、アプリケーション処理部１１は、同じノードの共有データ処理部１２に対してのみアクセス依頼を送信するものであり、他のノードの共有データ処理部１２に直接的にアクセス依頼を送信することはない。なお、上述のように、アプリケーション処理部１１にはサービスＩＤが関連付けられる。

共有データ処理部１２の機能については図６等を用いて後述するが、概要は次のようなものである。共有データ処理部１２は、アプリケーション処理部１１からのアクセス依頼に応じて共有データへのアクセスを行う。また、アクセス依頼が更新依頼である場合には、各ノードの共有データ処理部１２が互いに連携して共有データの更新を同期させ、結果を各ノードのアプリケーション処理部１１に通知する。

上述のように、マスタノードが正常に動作している間は、スレーブノードのアプリケーション処理部１１は動作せず、共有データ処理部１２のみが動作する。そして、対応するマスタノードにおいて障害が発生した場合には、アプリケーション処理部１１が動作を開始し、マスタノードと同一のアプリケーションを実行する。

ネットワーク処理部１３は、共有データ処理部１２からの依頼に応じて他のノードのネットワーク処理部１３と通信することにより、異なるノード間での共有データ処理部１２どうしの通信を可能にする。

記憶手段２０には、共有データ保存領域２１および更新履歴情報２２が格納される。
図３に共有データ保存領域２１の構成の例を示す。共有データ保存領域２１は共有データを保存するための領域であり、データ共有システムはこの共有データを各ノードについて同期させるよう動作する。共有データ保存領域２１に保存される共有データは、データの値を表すデータボディと、データボディを一意に識別するデータキーとを含む。データキーおよびデータボディはたとえば可変長であり、データキーはたとえば最大２５０バイトであり、データボディはたとえば最大１メガバイトである。データキーおよびデータボディは、共有データ保存領域２１を管理するためのデータ共有システム内部管理データを含んでもよい。

図４に更新履歴情報２２の構成の例を示す。更新履歴情報２２は、そのノード内での共有データ保存領域２１の更新処理の履歴を含む。各更新処理は、アプリケーション処理部１１が各更新処理を一意に識別するための更新処理ＩＤによって表される。更新処理ＩＤには、それぞれ、共有データ処理部１２が各更新処理を一意に識別するためのイベントＩＤと、アプリケーションを一意に識別するサービスＩＤと、更新されるデータボディを一意に識別するデータキーとが関連付けられている。図４の例では、該当するノードにおいて、更新処理ＩＤ「００１」（イベントＩＤ「Ａ１」）によって表される更新処理や、更新処理ＩＤ「００３」（イベントＩＤ「Ｂ１」）によって表される更新処理は完了していることがわかる。が、イベントＩＤを検索するとイベントＩＤ「Ｂ２」が存在しないので、イベントＩＤ「Ｂ２」によって表される更新処理はまだ完了していないことが示されている。更新履歴情報２２は、図７を用いて後述する更新依頼Ｍ１の情報を全て記憶し、共有データ処理部１２は、更新履歴情報２２にイベントＩＤが存在する場合は該当のイベントＩＤは完了済み、イベントＩＤが存在しない場合は該当のイベントＩＤは未完了と判定する。

図５に、データ共有システムが実行する更新処理の順序関係の例を示す。更新処理は互いに順序関係を有する。本明細書において、「順序関係」とは、２つの更新処理の間で定義され、一方の更新処理を開始するためには他方の更新処理が完了していなければならないという関係を表す。たとえば、図５の例では、更新処理Ｃ１の実行を開始するためには、更新処理Ｂ１が完了していなければならない。すなわち、データ共有システムは、これら２つの更新処理を実行するに際し、まず更新処理Ｂ１を実行し、次に更新処理Ｃ１を実行しなければならない。このような順序関係について、本明細書では、後に実行されるべき更新処理（たとえば更新処理Ｃ１）を基準として、先に実行されるべき更新処理（たとえば更新処理Ｂ１）を「先の更新処理」と呼ぶ。同様に、更新処理Ｂ２を基準とすると、更新処理Ａ１が先の更新処理となる。

順序関係は２つの更新処理の間で定義されるが、単一の更新処理が複数の順序関係に関連してもよい。たとえば、図５の例では、更新処理Ｂ１は、更新処理Ａ１、Ｃ１およびＣ２との間でそれぞれ順序関係を有する。このようにして順序関係の連鎖が形成される。また、このような順序関係の連鎖は、図５のような有向グラフとして表現することができる。

以上のように構成されるデータ共有システムの動作を以下に説明する。
各マスタノードのアプリケーション処理部１１に対して、複数の更新処理の順序関係（たとえば図５の有向グラフを表すデータ）があらかじめ指定されている。アプリケーション処理部１１は、この順序関係に従って、共有データの更新処理を依頼する。図５の例では、まずノードＡのアプリケーション処理部１１が更新処理Ａ１に係る更新依頼を共有データ処理部１２に送信する。そして、各ノードの共有データ処理部１２が各ノードにおいて更新後のデータを同期させ、各ノードのアプリケーション処理部１１に更新完了を通知する。この通知を受けたノードＢのアプリケーション処理部１１は、更新処理Ｂ１およびＢ２に係る更新依頼を共有データ処理部１２に送信する。同様にして更新後のデータが同期され、次にノードＣにおいて更新処理Ｃ１〜Ｃ３の更新依頼が送信される。このようにしてすべての更新処理が完了する。

図６は、各ノードの共有データ処理部１２の動作の概要を示すフローチャートである。 まず共有データ処理部１２は、アプリケーション処理部１１から更新依頼を受信したか否かを判定する（ステップＳ１）。更新依頼を受信していた場合、共有データ処理部１２は、更新の起点として他のノードに更新の反映を要求するノード（以下「起点ノード」と呼ぶ）の共有データ処理部１２として機能する（ステップＳ２）。

図７に、更新依頼Ｍ１の構成の例を示す。更新依頼Ｍ１は次の情報を含む。
‐その更新依頼を一意に識別する更新処理ＩＤ
‐更新されるデータを識別するデータキー
‐更新後のデータ内容を表すデータボディ
‐該当する更新処理よりも順序関係において先の更新処理を識別するプレイベントＩＤ
‐先の更新処理に係るアプリケーションを識別するプレサービスＩＤ
‐先の更新処理によって更新されたデータを識別するプレデータキー
ただし、先の更新処理が存在しない場合（すなわち、他の更新処理とは独立して実行可能な更新処理である場合）には、プレイベントＩＤ、プレサービスＩＤおよびプレデータキーは含まれない。
ステップＳ１は、共有データ処理部１２を主体として見ると、外部の構成要素であるアプリケーション処理部１１から送信されてきた更新依頼Ｍ１を受信し、これによって更新処理ＩＤ、データキー、データボディ、プレイベントＩＤ、プレサービスＩＤおよびプレデータキーを取得するステップであると解釈できる。一方、アプリケーション処理部１１および共有データ処理部１２を含むノード全体を主体として見ると、まず更新処理ＩＤ、データキー、データボディ、プレイベントＩＤ、プレサービスＩＤおよびプレデータキーを取得し、これに応じて更新依頼Ｍ１を内部で送受信するステップであると解釈できる。

ここで、更新依頼Ｍ１は先の更新処理を特定するための情報（プレイベントＩＤ）を含んでいるので、共有データ処理部１２は、図５のような有向グラフをあらかじめ記憶していなくても、更新履歴情報２２を参照して更新処理間の順序関係を認識することができる。

図８に、ステップＳ２の詳細を示す。ステップＳ２は、より詳細な処理として、ステップＳ２１〜Ｓ２６を含む。
ステップＳ２において、まず共有データ処理部１２は、更新依頼Ｍ１に従って共有データを更新する（ステップＳ２１）。すなわち、データキーによって特定されるデータの値を、データボディによって表される値に書き換える。次に、共有データ処理部１２は、当該ノード内でこの更新処理を一意に識別するイベントＩＤを生成する（ステップＳ２２）。

次に、共有データ処理部１２は更新履歴情報２２を更新する（ステップＳ２３）。たとえば、更新依頼Ｍ１に指定された更新処理ＩＤおよびデータキーと、自ノード（すなわち更新依頼Ｍ１を送信してきたアプリケーション処理部１１のノード）のサービスＩＤと、ステップＳ２２で生成したイベントＩＤとを関連付けて、更新履歴情報２２に記憶する。そして、更新依頼Ｍ１に関連する更新処理が完了したことを、当該イベントＩＤとともにアプリケーション処理部１１に通知する（ステップＳ２４）。この処理は、更新依頼Ｍ１を送信したアプリケーション処理部１１に対する更新のコミットに相当する。なお、当該更新処理から見て後続となる更新処理が存在する場合、アプリケーション処理部１１は、この通知に含まれるイベントＩＤを、後続の更新依頼においてプレイベントＩＤとして指定することになる。
このように、共有データ処理部１２は、アプリケーション処理部１１に対する完了通知と、他のノードへの同期処理とを非同期に実行するので、データ共有システム全体の動作が比較的高速となる。

次に、共有データ処理部１２は、反映要求メッセージＭ２を作成し（ステップＳ２５）、ネットワーク処理部１３を介して他の各ノードにブロードキャストする（ステップＳ２６）。

図９に、反映要求メッセージＭ２の構成の例を示す。反映要求メッセージＭ２は次の情報を含む。
‐更新処理を識別するためのイベント識別情報
‐更新依頼Ｍ１において指定された更新処理ＩＤ
‐起点ノードのアプリケーション処理部１１を一意に識別するサービスＩＤ
‐更新依頼Ｍ１において指定されたデータキー
‐更新依頼Ｍ１において指定されたデータボディ
‐更新依頼Ｍ１において指定された先の更新処理を識別するためのプレイベント識別情報
‐更新依頼Ｍ１において指定されたプレサービスＩＤ
‐更新依頼Ｍ１において指定されたプレデータキー

ここで、イベント識別情報は、イベントの種別（この例では、当該イベントが反映要求メッセージに関連するものであることを示す）と、起点ノードのノードＩＤと、ステップＳ２２において生成されたイベントＩＤとを含む。また、プレイベント識別情報は、先の更新処理のイベント種別と、先の更新処理の起点ノードのノードＩＤと、更新履歴情報２２において先の更新処理の更新処理ＩＤに関連付けられたイベントＩＤ（プレイベントＩＤ）とを含む。共有データ処理部１２は、プレイベント識別情報をどのようにして取得してもよいが、たとえば更新履歴情報２２にイベントＩＤに関連付けて記憶しておき、プレイベントＩＤをキーとして検索することによって取得してもよい。

ここで、反映要求メッセージＭ２は先の更新処理を特定するための情報（プレイベントＩＤ）を含んでいるので、共有データ処理部１２は、図５のような有向グラフをあらかじめ記憶していなくても、更新処理間の順序関係を認識することができる。
このようにしてステップＳ２（図６）が実行され、その後、共有データ処理部１２の処理はステップＳ１に戻る。

図６のステップＳ１において、更新依頼Ｍ１を受信していない場合、共有データ処理部１２は、他のノードからネットワーク処理部１３を介して反映要求メッセージＭ２を受信したか否かを判定する（ステップＳ３）。反映要求メッセージＭ２を受信していた場合、共有データ処理部１２は、他のノードで発生した更新を反映することによりデータを同期させるノード（以下「反映ノード」と呼ぶ）の共有データ処理部１２として機能する（ステップＳ４）。

図１０に、ステップＳ４の詳細を示す。ステップＳ４は、より詳細な処理として、ステップＳ４１〜Ｓ４９を含む。
ステップＳ４において、まず共有データ処理部１２は、反映要求メッセージＭ２に先の更新処理が指定されているか否かを判定する（ステップＳ４１）。この判定は、たとえば反映要求メッセージＭ２がプレイベント識別情報を含むか否かを判定することによって行われる。

先の更新処理が指定されていない場合、共有データ処理部１２は反映要求メッセージＭ２に従って共有データを更新し（ステップＳ４７）、更新履歴情報２２を更新し（ステップＳ４８）、反映要求メッセージＭ２に関連する更新処理が完了したことをアプリケーション処理部１１に通知する（ステップＳ４９）。これらの処理は、それぞれ図８のステップＳ２１、Ｓ２３およびＳ２４と同様である。このようにして各ノードで更新が反映され、データ共有システム全体で共有データが同期される。

なお、反映ノードのアプリケーション処理部１１は、ステップＳ４９の通知によって特定の更新処理が完了したことを認識し、あらかじめ記憶している図５の順序関係に従って次の更新処理を依頼することができるが、このような処理については公知技術であるので詳細な説明を省略する。

ステップＳ４１において、先の更新処理が指定されている場合、共有データ処理部１２は先の更新処理がそのノードにおいて既に実行されているか否かを判定する（ステップＳ４２）。この判定は、反映要求メッセージＭ２のプレイベントＩＤと、その反映要求メッセージＭ２より前に受信されたイベントＩＤとに基づいて行われる。たとえば、反映要求メッセージＭ２に指定されたプレイベントＩＤが、更新履歴情報２２に記憶されたイベントＩＤのいずれかと一致するか否かを判定することによって行われる。
先の更新処理が既に実行されていた場合、処理は上述のステップＳ４７以降に進む。

先の更新処理がまだ実行されていなかった場合、共有データ処理部１２は先の更新処理が実行されるまで所定時間待機する（ステップＳ４３）。すなわち、反映要求メッセージＭ２を受信した後、所定時間が経過する前に先の更新処理が実行され更新履歴情報２２に記憶された場合にはステップＳ４７に進むが、そうでない場合（すなわち、所定時間が経過するまで先の更新処理が実行されなかった場合）にはステップＳ４４に進む。

所定時間が経過するまで先の更新処理が実行されなかった場合、共有データ処理部１２は、欠落データ要求メッセージＭ３を作成し（ステップＳ４４）、ネットワーク処理部１３を介して他の各ノードにブロードキャストする（ステップＳ４５）。なお、この例では欠落データ要求メッセージＭ３はブロードキャストされるので起点ノードにも送信されることになるが、起点ノードを送信対象から除外する構成としてもよい。

図１１に、欠落データ要求メッセージＭ３の構成の例を示す。欠落データ要求メッセージＭ３は次の情報を含む。
‐反映要求メッセージＭ２において指定されたプレサービスＩＤ
‐反映要求メッセージＭ２において指定されたプレデータキー
このように、欠落データ要求メッセージＭ３は、反映要求メッセージＭ２自体の再送を要求するものではないが、実質的に最新のデータの再送信処理を要求するものであり、再送要求と解釈することもできる。なお、欠落データ要求メッセージＭ３はイベントの一種として扱われてもよく、図９の反映要求メッセージＭ２と同様に、イベントの種別、反映ノードのノードＩＤ、イベントＩＤ等の情報を含んでもよい。

ここで、プレサービスＩＤすなわち先の更新処理を依頼したアプリケーション処理部１１を特定するサービスＩＤは、この欠落データ要求メッセージＭ３に応答すべきノード（応答すべきアプリケーション処理部１１を含むノード。以下「応答ノード」と呼ぶ）を識別する情報として機能する。ノードＩＤでなくサービスＩＤを用いてノードを特定することにより、ノード障害への耐性が高まる。たとえば、先の更新処理を実行したノードＢにおいて障害が発生し、ノードＢ’に切り替わっていた場合、ノードＢ’が応答ノードとなるべきであるが、これらのノードは異なるノードＩＤを有するので、ノードＩＤのみによって応答ノードを特定するのは困難である。本実施形態のようにサービスＩＤを用いて応答ノードを特定することにより、ノードＢに代わってノードＢ’が応答ノードとなることができる。

とくに、メッセージ送信がすべてブロードキャスト方式で行われる非同期ネットワークでは、同じデータキーが指すデータ内容がノードごとに異なる可能性があるが、このようにサービスＩＤを用いて応答ノードを特定することにより、最新のデータを持つノードのみを応答ノードとして機能させることが可能である。

また、本実施形態では、欠落データ要求メッセージＭ３は、反映要求メッセージＭ２に指定されたイベントＩＤもプレイベントＩＤも含まない。しかしながら、プレサービスＩＤによって先の更新処理を実行したアプリケーション処理部１１を特定することができ、プレデータキーによってそのアプリケーション処理部１１が更新したデータを特定することができるので、先の更新処理が完了した時点の最新データを特定することが可能である。

次に、共有データ処理部１２は、欠落データ応答メッセージＭ４を、ネットワーク処理部１３を介して受信する（ステップＳ４６）。すなわち、欠落データ応答メッセージＭ４を受信するまで後続の処理を遅延させる。この欠落データ応答メッセージＭ４は他のノードから送信されるものであり、送信側のノード（応答ノード）での処理については図１３を用いて後述する。

図１２に、欠落データ応答メッセージＭ４の構成の例を示す。欠落データ応答メッセージＭ４は次の情報を含む。
‐欠落データ要求メッセージＭ３において指定されたプレデータキー
‐当該プレデータキーによって特定されるデータの内容を表すデータボディ
その後、共有データ処理部１２の処理は、上述のステップＳ４７以降に進む。なお、この場合、ステップＳ４７における更新処理は、反映要求メッセージＭ２ではなく欠落データ応答メッセージＭ４に従って行われる。なお、欠落データ応答メッセージＭ４はイベントの一種として扱われてもよく、図９の反映要求メッセージＭ２と同様に、イベントの種別、応答ノードのノードＩＤ、イベントＩＤ等の情報を含んでもよい。

このようにしてステップＳ４（図６）が実行され、その後、共有データ処理部１２の処理はステップＳ１に戻る。

図６のステップＳ３において、反映要求メッセージＭ２を受信していない場合、共有データ処理部１２は、他のノードからネットワーク処理部１３を介して欠落データ要求メッセージＭ３を受信したか否かを判定する（ステップＳ５）。欠落データ要求メッセージＭ３を受信していない場合、処理はステップＳ１に戻る。一方、欠落データ要求メッセージＭ３を受信していた場合、そのメッセージの宛先が自ノードであるか否かを判定する（ステップＳ６）。この判定は、たとえば、欠落データ要求メッセージＭ３に含まれるプレサービスＩＤが、自身のサービスＩＤ（すなわち、自ノードに含まれるアプリケーション処理部１１のサービスＩＤ）と一致するか否かを判定することによって行われる。宛先が自ノードでない場合、処理はステップＳ１に戻る。

宛先が自ノードである場合、共有データ処理部１２は応答ノードの共有データ処理部１２として機能する（ステップＳ７）。
図１３に、ステップＳ７の詳細を示す。ステップＳ７は、より詳細な処理として、ステップＳ７１およびＳ７２を含む。
ステップＳ７において、まず共有データ処理部１２は、欠落データ応答メッセージＭ４を作成し（ステップＳ７１）、ネットワーク処理部１３を介して他の各ノードにブロードキャストする（ステップＳ７２）。欠落データ応答メッセージＭ４は、図１２に示すように、欠落データ要求メッセージＭ３に含まれるプレデータキーと、このプレデータキーによって識別されるデータボディとに基づいて作成される。

なお、ステップＳ７２においてブロードキャストされた欠落データ応答メッセージＭ４は、上述のように欠落データ要求メッセージＭ３を送信した反映ノードによって受信され、データの更新に用いられる。

図１４は、以上のように動作するデータ共有システムにおける、ある更新処理に関する各ノードの処理の流れの例を説明する図である。
各ノードのアプリケーション処理部１１は、図５に示す有向グラフに沿って更新処理を依頼する。ここで、ノードＢが更新処理Ｂ２を行い、その反映がノードＣにおいて完了したとする。ただし、何らかの原因によりノードＡではこの反映がなされなかったものとする。

ノードＣのアプリケーション処理部１１は、図５の有向グラフを参照し、完了した更新処理Ｂ２の後続となる更新処理Ｃ３に係る更新依頼Ｍ１を発行する。これに応じ、ノードＣは起点ノードとして機能し、反映要求メッセージＭ２をブロードキャストする。この時点における各ノードの更新履歴情報２２の内容を図１４に示す（なお理解を容易にするため図４とは異なり有向グラフの形式で表している）。

ノードＡおよびノードＢは、反映要求メッセージＭ２を受信して反映ノードとして機能し、プレイベントＩＤに基づいて更新処理Ｂ２が完了しているか否かを判定する。ノードＢでは更新処理Ｂ２が完了しているので、そのまま更新処理Ｃ３を反映する。一方、ノードＡは更新処理Ｂ２が未済であることを認識し、プレサービスＩＤおよびプレデータキーを指定して欠落データ要求メッセージＭ３をブロードキャストする。（なお、この欠落データ要求メッセージＭ３にはイベントＩＤやプレイベントＩＤの指定は不要である。）

ノードＢおよびノードＣが欠落データ要求メッセージＭ３を受信する。プレサービスＩＤはノードＢのサービスＩＤと一致するので、ノードＢが応答ノードとして機能し、プレデータキーに対応するデータ（すなわち更新処理Ｂ２が実行済みとなったもの）を欠落データ応答メッセージＭ４に含めて送信する。ノードＡはこれを受信し、このデータに対して更新処理Ｃ３を実行する。

なお、マスタノードの切り替え処理（たとえば、マスタノードであるノードＡに障害が発生した場合に、対応するスレーブノードであるノードＡ’が新たなマスタノードとしてアプリケーションの動作を開始する処理）が発生した場合であっても、それに伴う特別な同期処理は不要である。スレーブノードもマスタノードと同様にすべての反映要求メッセージＭ２を受信し、状況に応じて欠落データ要求メッセージＭ３を送信してデータを同期させるので、どのようなタイミングであっても、データが完全に同期した状態または仕掛り中の更新を正しく認識している状態からマスタノードとしての動作を開始することができる。

以上説明するように、本発明の実施の形態１に係る同期処理方法によれば、複数のノードによって共有される共有データに対する更新処理の同期処理方法であって、共有データに対して、互いに順序関係を有する複数の更新処理が実行され、複数の更新処理のうち少なくとも２つが、それぞれ異なるノードによって実行され、各ノードには、更新処理を要求したアプリケーションを識別するサービスＩＤのいずれかが関連付けられる更新処理の同期処理方法において、ノードの少なくとも１つが、更新処理の起点ノードとして、
‐更新されるデータを識別するデータキーと、
‐更新後のデータ内容を表すデータボディと、
‐更新処理よりも順序関係において先の更新処理を識別するプレイベントＩＤと、
‐先の更新処理を要求したアプリケーションを識別するプレサービスＩＤと、
‐先の更新処理によって更新されたデータを識別するプレデータキーと、
を取得するステップと、
起点ノードが、
‐当該更新処理を識別するイベントＩＤと、
‐データキーと、
‐データボディと、
‐プレイベントＩＤと、
‐プレサービスＩＤと、
‐プレデータキーと、
を含む反映要求メッセージを、他のノードに送信するステップと、
反映要求メッセージを受信したノードが、更新処理の反映ノードとして、プレイベントＩＤと、当該反映要求メッセージより前に受信されたイベントＩＤとに基づき、その反映ノードにおいて先の更新処理がすでに実行されたか否かを判定するステップと、
反映ノードにおいて先の更新処理が実行されていない場合に、その更新反映ノードが、
‐プレサービスＩＤと、
‐プレデータキーと、
を含む欠落データ要求メッセージを、他のノード（ただし起点ノードを含んでもよい）に送信するステップと、
欠落データ要求メッセージに含まれるプレサービスＩＤに対応するノードが、欠落データ要求メッセージに含まれるプレデータキーによって識別されるデータボディを含む欠落データ応答メッセージを、反映ノードに送信するステップと
を含む。
また、この発明に係るデータ共有システムは、複数のノードを備え、上述の方法を実行する。
また、この発明に係るデータ共有プログラムは、コンピュータを、上述の
‐起点ノード、
‐反映ノード、および
‐欠落データ応答メッセージを送信するノード
として機能させる。

したがって、起点ノードからの反映要求メッセージＭ２には更新処理間の順序関係が指定されるので、先の更新を待ってから後の更新を行うことができ、共有データ全体の整合性を維持することができる。また、先の更新を待つのは順序関係がある場合に限られるので、すべての更新処理を通し番号順に行うようなシステムと比較すると高速に動作する。また、データの更新に係る排他制御はすべてノード内で完結しているので、更新処理ごとにデータ共有システム全体で排他制御を行うようなシステムと比較すると高速に動作する。
よって、本発明の実施の形態１に係る同期処理方法、データ共有システムおよびデータ共有プログラムによれば、共有データの更新が発生した場合において、整合性を維持しながらノード間のデータを高速に同期させることができる。

上述の実施の形態１において、次のような変形を施すことができる。
実施の形態１では６つのノードが存在するが、ノードの数は少なくとも２であればよい。また、実施の形態１では３つのノードがそれぞれ異なる更新処理を実行するが、ノードの数や更新処理の数に関わらず、少なくとも２つの更新処理がそれぞれ異なるノードによって実行される構成であれば本発明を適用することができる。

実施の形態１では、マスタノードの切り替え処理が発生した場合であっても、それに伴う特別な同期処理は実行されないが、変形例として、切り替え処理に応じて所定の同期処理を実行してもよい。たとえば、新たにマスタノードとなるノードは、更新履歴情報２２に記憶されたイベントＩＤに基づき、欠落しているデータを特定して送信を要求してもよい。たとえば、まず更新履歴情報２２によって表される有向グラフの終端となるイベントをすべて抽出し、抽出されたイベントのプレイベントにあたる更新処理が未済である場合に、そのプレイベントに係るデータが欠落しているデータであるとして特定することができる。

実施の形態１ではノードＡ〜Ｃのそれぞれに対応して待機ノードが設けられているが、待機ノードは必ずしもすべてのノードについて設けられなくともよく、また待機ノードを一切備えない構成であってもよい。

実施の形態１の処理（図６のフローチャート）によれば、単一のノードは、同時に起点ノード、反映ノードおよび応答ノードとして機能することができないが、変形例として同時または並列的に複数の機能を実行できるものであってもよい。たとえば、あるノードが、反映ノードとして欠落データ応答メッセージＭ４の受信を待っている間に他のイベントＩＤに係る欠落データ要求メッセージＭ３を受信した場合には、同時に応答ノードとして機能してもよい。

実施の形態１では、反映要求メッセージＭ２、欠落データ要求メッセージＭ３および欠落データ応答メッセージＭ４はいずれもブロードキャスト方式のメッセージである。すなわち、送信先のノードを特定する情報を含まず、送信元ノードを除くすべてのノードに対して送信される。変形例として、送信先を特定するメッセージを用いてもよい。これらのメッセージは、ユニキャスト方式としてもよく、マルチキャスト方式としてもよい。

実施の形態１では各ノードが１つのコンピュータによって構成されるが、ノードとハードウェアとの対応はこれに限らない。たとえば複数のコンピュータが１つのノードを構成してもよく、あるいは１つのコンピュータ上で動作する複数のＯＳまたは複数の論理区画がそれぞれ異なるノードを構成してもよい。

実施の形態１では各メッセージはそれぞれ単一のステップにおいて一度に送信されるが、複数の単位に分割して送受信されてもよい。たとえば、反映要求メッセージは、イベントＩＤにデータキーおよびデータボディを関連付ける第１部分と、イベントＩＤにプレイベントＩＤ、プレサービスＩＤおよびプレデータキーを関連付ける第２部分とから構成されてもよく、各部分が独立して送受信されてもよい。また、各部分が異なるタイミングで送受信されてもよい。

１０ 演算手段、１１ アプリケーション処理部（更新処理を要求したアプリケーション）、１２ 共有データ処理部、１３ ネットワーク処理部、２０ 記憶手段、２１ 共有データ保存領域、２２ 更新履歴情報、１００ 通信ネットワーク、
Ａ，Ｂ，Ｃ，Ａ’，Ｂ’，Ｃ’ ノード（起点ノード、反映ノード、欠落データ応答メッセージを送信するノード）、Ａ１，Ｂ１，Ｂ２，Ｃ１〜Ｃ３ 更新処理、
Ｍ１ 更新依頼、Ｍ２ 反映要求メッセージ、Ｍ３ 欠落データ要求メッセージ、Ｍ４ 欠落データ応答メッセージ。

Claims (7)

1. 複数のノードによって共有される共有データに対する更新処理の同期処理方法であって、
   前記共有データに対して、互いに順序関係を有する複数の更新処理が実行され、
   前記複数の更新処理のうち少なくとも２つが、それぞれ異なるノードによって実行され、
   各ノードには、前記更新処理を要求したアプリケーションを識別するサービスＩＤのいずれかが関連付けられる
   更新処理の同期処理方法において、
   前記ノードの少なくとも１つが、更新処理の起点ノードとして、
   ‐更新されるデータを識別するデータキーと、
   ‐更新後のデータ内容を表すデータボディと、
   ‐前記更新処理よりも順序関係において先の更新処理を識別するプレイベントＩＤと、
   ‐前記先の更新処理を要求したアプリケーションを識別するプレサービスＩＤと、
   ‐前記先の更新処理によって更新されたデータを識別するプレデータキーと、
   を取得するステップと、
   前記起点ノードが、
   ‐当該更新処理を識別するイベントＩＤと、
   ‐前記データキーと、
   ‐前記データボディと、
   ‐前記プレイベントＩＤと、
   ‐前記プレサービスＩＤと、
   ‐前記プレデータキーと、
   を含む反映要求メッセージを、他のノードに送信するステップと、
   前記反映要求メッセージを受信したノードが、更新処理の反映ノードとして、前記プレイベントＩＤと、当該反映要求メッセージより前に受信されたイベントＩＤとに基づき、その反映ノードにおいて前記先の更新処理がすでに実行されたか否かを判定するステップと、
   前記反映ノードにおいて前記先の更新処理が実行されていない場合に、その更新反映ノードが、
   ‐前記プレサービスＩＤと、
   ‐前記プレデータキーと、
   を含む欠落データ要求メッセージを、他のノード（ただし前記起点ノードを含んでもよい）に送信するステップと、
   前記欠落データ要求メッセージに含まれる前記プレサービスＩＤに対応するノードが、前記欠落データ要求メッセージに含まれる前記プレデータキーによって識別されるデータボディを含む欠落データ応答メッセージを、前記反映ノードに送信するステップと
   を含む、同期処理方法。
2. 前記反映要求メッセージ、前記欠落データ要求メッセージおよび前記欠落データ応答メッセージは、いずれもブロードキャスト方式のメッセージである、請求項１に記載の方法。
3. 前記欠落データ要求メッセージは、前記イベントＩＤおよび前記プレイベントＩＤのいずれも含まない、請求項１または２に記載の方法。
4. 前記反映ノードにおいて、前記欠落データ要求メッセージを送信するステップは、前記反映要求メッセージを受信した後、所定時間が経過するまでは実行されない、請求項１〜３のいずれか一項に記載の方法。
5. 各前記ノードは、演算手段および記憶手段を備えるコンピュータによって構成される、請求項１〜４のいずれか一項に記載の方法。
6. 複数のノードを備え、請求項１〜５のいずれか一項に記載の方法を実行するデータ共有システム。
7. コンピュータを、請求項１〜５のいずれか一項に記載の
   ‐起点ノード、
   ‐反映ノード、および
   ‐欠落データ応答メッセージを送信するノード
   として機能させるデータ共有プログラム。

Images