特開 2023-174221 フォールトトレラントシステム及びデータ処理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023174221

(43)【公開日】2023-12-07

(54)【発明の名称】フォールトトレラントシステム及びデータ処理方法

(51)【国際特許分類】

   G06F 9/52 20060101AFI20231130BHJP

   G06F 11/20 20060101ALI20231130BHJP

【ＦＩ】

G06F9/52 150Z

G06F11/20 620

【審査請求】未請求

【請求項の数】8

【出願形態】ＯＬ

(21)【出願番号】P 2022086961

(22)【出願日】2022-05-27

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110002365

【氏名又は名称】弁理士法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】河合 英宏

【テーマコード（参考）】

5B034

【Ｆターム（参考）】

5B034AA05

5B034DD06

(57)【要約】      （修正有）

【課題】同期による負荷を抑制しながらノード間の振る舞いを一致化できる、低遅延でスケーラブルなフォールトトレラントシステム及びデータ処理方法を提供する。
【解決手段】多重化された複数のノード１０が通信ネットワーク２を介して接続されるフォールトトレラントシステム１において、各ノード１０で動作するアプリケーションは、入力に対して決定論的に出力を生成する１以上のタスク２０から構成され、複数のノード１０のうちの１つがリーダノードとなり、それ以外がフォロワノードとなり、リーダノードとフォロワノードは、それぞれ同一のタスクを実行するように構成され、タスク２０が複数のメッセージ送信元を持つ送信先タスクにメッセージを送信するとき、複数のノード１０のプロセッサは、送信先タスクに対するメッセージの配送順について複数のノード間で合意形成し、合意形成された配送順に従ってメッセージを送信する。
【選択図】図３

【特許請求の範囲】

【請求項1】

多重化された複数のノードが通信ネットワークを介して接続されるフォールトトレラントシステムであって、
前記複数のノードは、それぞれプロセッサ、メモリ、及び記憶領域を有し、
各前記ノードにおいて前記プロセッサが前記記憶領域からプログラムを前記メモリに読み出して実行することによって動作するアプリケーションは、入力に対して決定論的に出力を生成する１以上のタスクから構成され、
前記複数のノードのうちの１つがリーダノードとなり、リーダノード以外のノードがフォロワノードとなり、前記リーダノードと前記フォロワノードは、それぞれ同一のタスクを実行するように構成され、
各前記タスクは、自タスクの状態を示すローカルステートに１対１で紐付けられ、
前記タスクの入力は、システム外部または他のタスクから受信したメッセージ、及び当該タスクに紐付けられた前記ローカルステートへのアクセスを含み、
前記タスクの出力は、当該タスクがシステム外部または他のタスクに送信するメッセージ、及び当該タスクに紐付けられた前記ローカルステートの更新を含み、
前記タスクが複数のメッセージ送信元を持つ送信先タスクにメッセージを送信するとき、前記複数のノードのプロセッサは、前記送信先タスクに対するメッセージの配送順について前記複数のノード間で合意形成し、合意形成された配送順に従って前記メッセージを配送、及び処理する
ことを特徴とするフォールトトレラントシステム。

【請求項2】

前記タスクが複数のメッセージ送信元を持つ送信先タスクにメッセージを送信するとき、前記送信先タスクに対するメッセージの配送順について前記複数のノード間で合意形成がなされるまでは、前記送信先タスクに対するメッセージの送信を一時的に保留する
ことを特徴とする請求項１に記載のフォールトトレラントシステム。

【請求項3】

１以上の第１のタスクから既存の第１のメッセージパスが生成されている第２のタスクに対して、前記第１のタスクとは異なる第３のタスクから新規に第２のメッセージパスを追加するとき、前記プロセッサが、当該第２のメッセージパスが追加されることについて前記複数のノード間で認識合わせを行う
ことを特徴とする請求項２に記載のフォールトトレラントシステム。

【請求項4】

追加しようとする前記第２のメッセージパスが前記第２のタスクに対する２番目のメッセージパスである場合、
前記プロセッサは、前記第１のメッセージパス上で何番目のメッセージまでをディスパッチした後に前記第２のメッセージパスを追加するかについて、前記複数のノード間で合意形成し、当該合意形成が得られるまでは前記第１のメッセージパス上のメッセージの送信を一時的に保留する
ことを特徴とする請求項３に記載のフォールトトレラントシステム。

【請求項5】

追加しようとする前記第２のメッセージパスが前記第２のタスクに対する２番目のメッセージパスである場合に、
前記リーダノードのプロセッサは、各ノードにおいて前記第１のメッセージパス上でディスパッチ済みのメッセージの通番の最大値を判別し、前記第１のメッセージパス上で前記最大値の通番のメッセージがディスパッチされた後に前記第２のメッセージパスを追加することを前記複数のノード間で合意形成する
ことを特徴とする請求項４に記載のフォールトトレラントシステム。

【請求項6】

各前記ノードのプロセッサは、前記第２のメッセージパスとして前記第２のタスクに対する２番目のメッセージパスを追加しようとするときに、当該第２のメッセージパスの追加に関するメッセージパス情報を他のノードにブロードキャストし、
前記メッセージパス情報には、当該ノードにおいて前記第１のメッセージパス上でディスパッチ済みのメッセージの通番が示され、
前記メッセージパス情報を受信した前記他のノードのプロセッサは、前記第１のメッセージパス上で何番目のメッセージまでをディスパッチした後に前記第２のメッセージパスを追加するかについて前記複数のノード間で合意形成することに先行して、当該メッセージパス情報に示される通番の最大値まで自ノードにおける前記第１のメッセージパス上のメッセージをディスパッチする
ことを特徴とする請求項４に記載のフォールトトレラントシステム。

【請求項7】

前記フォロワノードのプロセッサは、前記第２のメッセージパスとして前記第２のタスクに対する２番目のメッセージパスを追加しようとするとき、当該第２のメッセージパスの追加に関するメッセージパス情報を他のノードにブロードキャストし、
前記リーダノードが全てのノードから前記第２のメッセージパスの追加に関するメッセージパス情報を受信していく途中において、前記リーダノードが何れかのノードから受信したメッセージパス情報に示される前記第１のメッセージパス上でディスパッチ済みのメッセージの通番の最大値が、前記リーダノードにおいて前記第１のメッセージパス上でディスパッチ済みのメッセージの通番の最大値を超えた時点で、当該メッセージパス情報に示される通番の最大値まで自ノードにおける前記第１のメッセージパス上のメッセージをディスパッチすることについてノード間で合意形成する
ことを特徴とする請求項４に記載のフォールトトレラントシステム。

【請求項8】

多重化された複数のノードが通信ネットワークを介して接続されるフォールトトレラントシステムによるデータ処理方法であって、
前記複数のノードは、それぞれプロセッサ、メモリ、及び記憶領域を有し、
各前記ノードにおいて前記プロセッサが前記記憶領域からプログラムを前記メモリに読み出して実行することによって動作するアプリケーションは、入力に対して決定論的に出力を生成する１以上のタスクから構成され、
前記複数のノードのうちの１つがリーダノードとなり、リーダノード以外のノードがフォロワノードとなり、前記リーダノードと前記フォロワノードは、それぞれ同一のタスクを実行するように構成され、
各前記タスクは、自タスクの状態を示すローカルステートに１対１で紐付けられ、
前記タスクの入力は、システム外部または他のタスクから受信したメッセージ、及び当該タスクに紐付けられた前記ローカルステートへのアクセスを含み、
前記タスクの出力は、当該タスクがシステム外部または他のタスクに送信するメッセージ、及び当該タスクに紐付けられた前記ローカルステートの更新を含み、
前記タスクが複数のメッセージ送信元を持つ送信先タスクにメッセージを送信するとき、前記複数のノードのプロセッサは、前記送信先タスクに対するメッセージの配送順について前記複数のノード間で合意形成し、合意形成された配送順に従って前記メッセージを送信する
ことを特徴とするデータ処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、フォールトトレラントシステムの技術を適用する多重系処理システムに関する。

【背景技術】

【0002】

多重化された計算機（ノード）間で同じ処理を実施し、その何れかの計算機上で障害が発生しても無停止で業務を継続可能とする計算機システムとして、フォールトトレラントシステムが知られている。

【0003】

フォールトトレラントシステムを実現するアプローチの１つとして、ステートマシンレプリケーションが知られている。ステートマシンレプリケーションでは、同一のステートを持つ各複製ノードに対して同一の入力を与え、その入力とステートを用いて決定論的に処理を行う。結果として各ノードは同一の出力をして、同一のステートに更新される。これにより、一部のノードに障害が発生したとしても、残りのノードで不整合が生じることなく、業務を継続することができる。

【0004】

ここで、複数のタスクを並列実行するよう構成されたアプリケーションの場合、全体としての振る舞いをノード間で一致化させるには、共有ステートへのアクセス順を一致化させればよい。

【0005】

例えば特許文献１に開示されたデータ処理方法では、リーダノードが、共有データへアクセスを行う都度、そのアクセス順をフォロワノードに伝達し、一方でフォロワノードは、共有データにアクセスを行う都度、リーダノードからのアクセス順の指示を待ち、その順に従って処理する。これにより、特許文献１のデータ処理方法は、複製ノード間の振る舞いを一致化している。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】国際公開第２０１２／１２７６５２号

【発明の概要】

【発明が解決しようとする課題】

【0007】

しかし、上述した特許文献１では、タスク間の共有データへのアクセスの順序を、アクセスの都度、ノード間で一致化することによって決定性を保証している。すなわち、特許文献１のデータ処理方法においては、タスク間で共有されるデータへのアクセス要求が発生する都度、リーダノードとフォロワノード間で通信が発生するため、ワークロードによっては同期のための負荷が増大するおそれがあった。

【0008】

本発明は以上の点を考慮してなされたもので、同期による負荷を抑制しながらノード間の振る舞いを一致化できる、低遅延でスケーラブルなフォールトトレラントシステム及びデータ処理方法を提供しようとするものである。

【課題を解決するための手段】

【0009】

かかる課題を解決するため本発明においては、多重化された複数のノードが通信ネットワークを介して接続されるフォールトトレラントシステムであって、前記複数のノードは、それぞれプロセッサ、メモリ、及び記憶領域を有し、各前記ノードにおいて前記プロセッサが前記記憶領域からプログラムを前記メモリに読み出して実行することによって動作するアプリケーションは、入力に対して決定論的に出力を生成する１以上のタスクから構成され、前記複数のノードのうちの１つがリーダノードとなり、リーダノード以外のノードがフォロワノードとなり、前記リーダノードと前記フォロワノードは、それぞれ同一のタスクを実行するように構成され、各前記タスクは、自タスクの状態を示すローカルステートに１対１で紐付けられ、前記タスクの入力は、システム外部または他のタスクから受信したメッセージ、及び当該タスクに紐付けられた前記ローカルステートへのアクセスを含み、前記タスクの出力は、当該タスクがシステム外部または他のタスクに送信するメッセージ、及び当該タスクに紐付けられた前記ローカルステートの更新を含み、前記タスクが複数のメッセージ送信元を持つ送信先タスクにメッセージを送信するとき、前記複数のノードのプロセッサは、前記送信先タスクに対するメッセージの配送順について前記複数のノード間で合意形成し、合意形成された配送順に従って前記メッセージを送信することを特徴とするフォールトトレラントシステムが提供される。

【0010】

また、かかる課題を解決するため本発明においては、多重化された複数のノードが通信ネットワークを介して接続されるフォールトトレラントシステムによるデータ処理方法であって、前記複数のノードは、それぞれプロセッサ、メモリ、及び記憶領域を有し、各前記ノードにおいて前記プロセッサが前記記憶領域からプログラムを前記メモリに読み出して実行することによって動作するアプリケーションは、入力に対して決定論的に出力を生成する１以上のタスクから構成され、前記複数のノードのうちの１つがリーダノードとなり、リーダノード以外のノードがフォロワノードとなり、前記リーダノードと前記フォロワノードは、それぞれ同一のタスクを実行するように構成され、各前記タスクは、自タスクの状態を示すローカルステートに１対１で紐付けられ、前記タスクの入力は、システム外部または他のタスクから受信したメッセージ、及び当該タスクに紐付けられた前記ローカルステートへのアクセスを含み、前記タスクの出力は、当該タスクがシステム外部または他のタスクに送信するメッセージ、及び当該タスクに紐付けられた前記ローカルステートの更新を含み、前記タスクが複数のメッセージ送信元を持つ送信先タスクにメッセージを送信するとき、前記複数のノードのプロセッサは、前記送信先タスクに対するメッセージの配送順について前記複数のノード間で合意形成し、合意形成された配送順に従って前記メッセージを送信することを特徴とするデータ処理方法が提供される。

【発明の効果】

【0011】

本発明によれば、同期による負荷を抑制しながらノード間の振る舞いを一致化できる、低遅延でスケーラブルなフォールトトレラントシステム及びデータ処理方法を提供することができる。

【図面の簡単な説明】

【0012】

【図1】本発明の一実施形態に係るフォールトトレラントシステム（ＦＴシステム）１の構成例を示すブロック図である。

【図2】ＦＴシステム１におけるイベント発生時の全体的な処理の特徴を示すイメージ図である。

【図3】ノード間の相関関係を説明するイメージ図である。

【図4】メッセージの特徴を説明するための図である。

【図5】タスク２０の動作例を示すイメージ図である。

【図6】メッセージパス管理テーブル３５の一例を示す図である。

【図7】ノード間におけるイベントログの合意形成の特徴を説明するための図である。

【図8】イベントログの合意形成におけるリーダの処理手順の一例を示すフローチャートである。

【図9】イベントログの合意形成におけるフォロワの処理手順の一例を示すフローチャートである。

【図10】リーダの入力処理部３１による受信処理の処理手順例を示すフローチャートである。

【図11】イベントログ３４に保持される外部入力タイプのログエントリのデータ構成例を示す図である。

【図12】メッセージ要求受付処理の処理手順例を示すフローチャートである。

【図13】メッセージ配送タイプのログエントリの具体例を示す図である。

【図14】メッセージパスを追加するときのノード間の関係を説明するためのモデル図である。

【図15】メッセージパス追加処理の処理手順例を示すフローチャートである。

【図16】メッセージパス追加タイプのログエントリの一例を示す図である。

【図17】メッセージパス追加タイプのログエントリの別例を示す図である。

【図18】メッセージパス情報の一例を示す図である。

【図19】メッセージパス情報受信処理の処理手順例を示すフローチャートである。

【図20】メッセージパス管理テーブル３５の具体例を示す図である。

【図21】メッセージパス情報タイプのログエントリの一例を示す図である。

【図22】第２の改善方法によるメッセージパス追加の処理手順例を示すシーケンス図である。

【図23】第２の改善方法によるメッセージパス追加処理の処理手順例を示すフローチャートである。

【図24】第２の改善方法によるメッセージパス情報受信処理の処理手順例を示すフローチャートである。

【図25】外部出力の順序保証を説明するイメージ図である。

【図26】複数のノードからの外部出力を調整して出力する構成を説明するイメージ図である。

【発明を実施するための形態】

【0013】

以下、図面を参照して、本発明の実施形態を詳述する。

【0014】

なお、以下の記載及び図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略及び簡略化がなされている。また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。本発明が実施形態に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。本発明は、当業者であれば本発明の範囲内で様々な追加や変更等を行うことができる。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は複数でも単数でも構わない。

【0015】

以下の説明では、「テーブル」、「表」、「リスト」、「キュー」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。

【0016】

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られたＩＤを使用することがある。

【0017】

また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、少なくとも１以上のプロセッサ（例えばＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノード、ストレージシステム、ストレージ装置、サーバ、管理計算機、クライアント、又は、ホストであってもよい。プログラムを実行して行う処理の主体（例えばプロセッサ）は、処理の一部又は全部を行うハードウェア回路を含んでもよい。例えば、プログラムを実行して行う処理の主体は、暗号化及び復号化、又は圧縮及び伸張を実行するハードウェア回路を含んでもよい。プロセッサは、プログラムに従って動作することによって、所定の機能を実現する機能部として動作する。プロセッサを含む装置及びシステムは、これらの機能部を含む装置及びシステムである。

【0018】

プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

【0019】

（１）構成
図１は、本発明の一実施形態に係るフォールトトレラントシステム（ＦＴシステム）１の構成例を示すブロック図である。図１に示すように、ＦＴシステム１は、通信ネットワーク２を介して接続される複数の計算機（ノード１０）から構成される計算機システムである。

【0020】

本実施形態に係るＦＴシステム１は、いわゆるリーダ－フォロワ型分散システムであって、複数のノード１０のうちの１台がリーダノード（リーダとも呼ぶ）となり、リーダノード以外のノードがフォロワノード（フォロワとも呼ぶ）となる。具体的には例えば、分散合意アルゴリズムのＲＡＦＴにおけるリーダ及びフォロワを想定する。ＦＴシステム１では、複数のノード１０上に複製されたイベント駆動型のアプリケーションに対して同じ入力が与えられ、同じ出力を得る。イベント駆動型のアプリケーションは、独立動作可能な複数の処理モジュールであるタスク２０から構成される。すなわち、ＦＴシステム１は、イベントの発生時に、リーダノードとフォロワノードとで、それぞれ同一のタスク２０が実行されるように構成される。

【0021】

なお、ＦＴシステム１が正常に稼働している間は、リーダのノード１０とフォロワのノード１０が入れ替わることはないが、例えばリーダのノード１０に何らかの障害が発生した可能性があるときは、当該ノード１０はＦＴシステム１から切り離され、フォロワのノード１０のうちの１台が新たにリーダとなってＦＴシステム１は処理を継続する。このような構成により、スケーラブルなＦＴシステム１が実現される。

【0022】

また、ＦＴシステム１は、通信ネットワーク２を介して１台以上の端末３と接続され、端末３とデータの送受信を行う。通信ネットワーク２は、例えばＬＡＮ（Local Area Network）であるが、これに限定されない。端末３は、ユーザが使用する計算機であって、例えば、クライアントとしてＦＴシステム１にイベントを送信したり、イベントの処理結果をＦＴシステム１から受信したりする。なお、後述する図２に示すように、ＦＴシステム１ではリーダノードがイベントを最初に受け取る。

【0023】

ノード１０は、ＣＰＵ（Central Processing Unit）等のプロセッサ、メモリ、記憶装置（記憶領域）、及び通信インタフェース等を備えた計算機である。記憶装置には、ノード１０で実行されるイベント処理基盤３０及びタスク２０等の各種プログラム及びデータが記憶される。そして、プロセッサが、記憶装置からこれらの各種プログラムを読み出してメモリに展開し、実行する。

【0024】

タスク２０は、１以上のノード１０の複数のタスク群でアプリケーションを構成する、独立動作可能なイベント駆動型の処理モジュール（プログラム）である。タスク２０は、具体的には例えば、マイクロサービスや、ＦａａＳ（Function as a Service）上のFunctionや、ＯＳ（Operating System）上のプロセス等である。

【0025】

本実施形態において、アプリケーションのステートは、タスク２０ごとに独立してステート（ローカルステート）２１によって管理される。ステート２１は、排他的にアクセスされる。各タスク２０は、自タスクの状態を示すステート２１と１対１で紐付けられ、他のタスク２０と疎結合に連係動作する。すなわち、各タスク２０は、直接的な共有のアプリデータを持たず、他のタスク２０が管理するアプリデータ（ステート２１）にアクセスする際には、処理を要求する一方向性のメッセージ（以後は、単にメッセージと記載する）によって排他的に実施される。そして、各タスク２０は決定論的に振る舞うように構成される。すなわち、入力と現在のステートが決定すれば、出力と処理後のステートの組み合わせが一意に定まる。

【0026】

イベント処理基盤３０は、イベントを処理するオペレーションシステムである。イベント処理基盤３０は、マルチタスク処理が可能で、複数のタスク２０を並列に実行することができる。イベント処理基盤３０は、入力処理部３１、メッセージ処理部３２、出力処理部３３、イベントログ３４、メッセージパス管理テーブル３５、及びメッセージ待機キュー３６を有する。

【0027】

入力処理部３１は、発生したイベントを外部（端末３）あるいはリーダノードから受け付け、イベント発生順に当該イベントを処理する適切なタスクを呼び出す。

【0028】

メッセージ処理部３２は、タスク２０からのメッセージ要求を受け付け、対象のタスク２０へのメッセージを実施する。このとき、メッセージ処理部３２は、システム全体の決定性保証に必要なメッセージパス管理テーブル３５の管理やノード間同期処理を行う。

【0029】

出力処理部３３は、必要に応じて各ノード１０の処理結果の調停を行い、最終的にそれを外部に送信する。処理結果の調停は、例えば、多数決により選ばれた結果を送信する方法、または、先着優先で送信する方法等を採用することができる。

【0030】

イベントログ３４は、ノード１０間で合意形成する（または合意形成した）情報を管理するデータ構造である。具体的には例えば、分散合意アルゴリズムのＲＡＦＴにおけるログを想定する。イベントログ３４は、ログエントリの集合によって構成される。ログエントリは、合意形成する情報の単位であり、最初にリーダがログに追記し、それをフォロワに複製する。リーダが過半数のフォロワからログエントリの複製完了の報告を受けたとき、古いログエントリから順に、ログエントリがコミットされる。そしてリーダは、ログエントリをどこまでコミットしたかをフォロワに通知する。各ノード１０は、コミット済みのログエントリを、古いものから順に適用する。どのように適用するかは、ログエントリのタイプによって異なる。

【0031】

メッセージパス管理テーブル３５は、メッセージパスを管理するデータである。メッセージパスは、メッセージの送信元とメッセージの送信先とを結ぶ経路である。詳細は後述するが、メッセージパス管理テーブル３５は、自ノードを含む各ノードから受信するメッセージパス情報に基づいて登録される。

【0032】

メッセージ待機キュー３６は、メッセージパスごとに用意される。メッセージ要求が発生した場合に、メッセージ要求はメッセージ待機キュー３６に順にキューイングされる。メッセージ待機キュー３６がブロック状態ではない場合、所定のタイミングでメッセージ待機キュー３６の先頭からメッセージ要求がデキューされ、メッセージ送信先に送信される。

【0033】

（２）イベント処理の概要
図２は、ＦＴシステム１におけるイベント発生時の全体的な処理の特徴を示すイメージ図である。図２に示した外部入力３８は、イベントの外部入力またはフォロワノード１０Ｂ，１０Ｃへの転送、及び外部入力されたイベントに関するノード間の合意形成を行う。外部入力３８は、具体的には図１に示した入力処理部３１に相当する。外部出力３９は、ノード１０における処理結果をリーダノード１０Ａまたは外部に出力する。外部出力３９は、具体的には図１に示した出力処理部３３に相当する。

【0034】

図２に示すように、本実施形態に係るＦＴシステム１では、リーダノード１０Ａの外部入力３８が最初にイベントを受け取り、受け取ったイベントをフォロワノード１０Ｂ，１０Ｃの外部入力３８に転送し、ノード間で合意形成を行う。そして各ノード１０Ａ，１０Ｂ，１０Ｃは、受け取ったイベントに対して、リーダノード１０Ａが決定した順に、適切なタスク２０を呼び出して処理を行う。

【0035】

図２において各タスク２０は受信メッセージに対し逐次的、かつ決定論的に処理を行う。例えばタスクＡがメッセージＭａ１、Ｍａ２を順に受信した場合、まずメッセージＭａ１を処理し、その結果としてメッセージＭｂ１をタスクＢに送信し、次にメッセージＭａ２を処理し、その結果としてメッセージＭｂ２をタスクＢに送信する。このとき、タスクＢは単一のメッセージ送信元しか持たないため、どのノードにおいてもメッセージＭｂ１、Ｍｂ２の順に逐次的、かつ決定論的に処理する。このように、ＦＴシステム１において、単一パスのメッセージ配送については、同期を取ることなく決定性が維持される。

【0036】

また、図２においてタスクＤからタスクＢに破線で示したように、１のタスクから別の１のタスクに対して初回にメッセージパスが追加されるときは、当該メッセージがあったことについて、ノード間で合意形成する。これにより、パスに複数のメッセージ送信元が生じた場合、以降はメッセージ処理順の合意形成を行うようにする。

【0037】

また、図２においてタスクＢ，またはＤからのメッセージ受信によりタスクＣが動作するといったように、複数パスからのメッセージ配送がある場合については、メッセージ処理順をノード間で合意形成する。これにより、複数パスを持つタスク（例えばタスクＣ）の振る舞いがノード間で一致する。

【0038】

そして、各ノード１０Ａ，１０Ｂ，１０Ｃでタスク２０の処理が行われた後は、外部出力３９が、必要に応じて多数決等の調停を行い、処理結果を外部（端末３）に出力する。

【0039】

（３）タスク動作の決定性保証
図３は、ノード間の相関関係を説明するイメージ図である。図３では、図面の左半分にリーダノード（リーダ）１０Ａを示し、図面の右半分に１つのフォロワノード（フォロワ）１０Ｂを示し、それらの相関関係を表している。なお、詳細は後述するが、外部出力は様々な方法を採用できることから、出力処理部３３は、リーダ１０Ａ，フォロワ１０Ｂの区別を付けずに図示している。図３に示すように、ノード間では、外部入力、メッセージパス追加、及びメッセージ配送順（タスクの呼び出し順）の３種類の合意形成が行われる。

【0040】

図４は、メッセージ配送の特徴を説明するための図である。図４に示すように、タスク間及び外部入出力とタスク間は、メッセージ１０１によって情報交換及び連係動作をする。なお、本実施形態で扱うメッセージは一方向性であり、例えばタスクＡからタスクＢに向けたメッセージに対する応答は、タスクＢからタスクＡへのメッセージとみなして扱う。

【0041】

１つのメッセージパス上に流れるメッセージは、そのパス上で順序が入れ替わることはない。それぞれのメッセージ１０１には、メッセージパスごとに、送信順を示す通番が付与される。本説明では、同一のメッセージパス内でのメッセージの通番（メッセージ通番）を、送信順に＃１，＃２，・・・と表記する。メッセージ通番は、メッセージパス管理テーブル３５で管理される。

【0042】

例えば図４に示すように、タスクＢからタスクＣに向かうメッセージパスにおいて、タスクＢから＃１、＃２の順にメッセージが送信された場合、タスクＣは＃１、＃２の順にメッセージを受信する。一方、タスクＢから外部出力に向かうメッセージ「Ｂ→外 ＃２」とタスクＢからタスクＣに向かうメッセージ「Ｂ→Ｃ ＃１」のように、送信元が同じで送信先が異なるメッセージパス上のメッセージでは、どちらのメッセージが先に送信先に届くかはその送信順に関係しない。

【0043】

また、前述したように、タスク２０は、メッセージ１０１の受信を契機に動作するイベント駆動型タスクである。各タスク２０は決定論的に振る舞うものとし、入力に対して一意の処理結果を出力する。ここで、タスク２０への入力は、外部入力３８や他のタスク２０から受信したメッセージ１０１の内容または自身のローカルステート２１の内容である。また、タスク２０からの出力は、他のタスク２０や外部出力３９に送信するメッセージ１０１または自身のローカルステート２１への更新内容である。各タスク２０は、同時に１つのメッセージ１０１を処理する。複数のメッセージ１０１を受信した場合には、逐次的に１つずつメッセージ１０１を処理する。ローカルステート２１は、タスク２０単位で独立しており、他のタスク２０から直接アクセスされない。あるタスク２０が他のタスク２０のローカルステート２１にアクセスしたい場合には、当該他のタスク２０にアクセス要求を依頼するメッセージ１０１を発行することで実現される。

【0044】

図５は、タスク２０の動作例を示すイメージ図である。図５（Ａ）はメッセージ送信元が複数である場合の構成例を示しており、図５（Ｂ）はメッセージ送信元が単一である場合の構成例を示している。図５を参照しながら、本実施形態において各ノード１０によるアプリケーション（具体的にはタスク動作）の決定性が保証される原理について説明する。

【0045】

図５（Ａ）において、タスクＣは、タスクＡ，Ｂからのメッセージ１０１Ａ，１０１Ｂの内容と、ローカルステート２１Ｃの内容をもとに処理を行い、ローカルステート２１Ｃを更新し、処理結果を外部出力３９に出力する。このとき、ノード１０間でメッセージ配送順（処理順）について合意形成を行わないと、タスクＡからのメッセージ１０１Ａを先に処理した場合と、タスクＢからのメッセージ１０１Ｂを先に処理した場合とで、タスクＣの出力内容や最終的なローカルステート２１Ｃに差異が生じることがある。具体的には、例えばタスクＡからのメッセージ１０１Ａを先に処理する場合、タスクＣはメッセージ１０１ＡによってタスクＣのローカルステート２１Ｃを更新し、その更新後のローカルステート２１Ｃの内容を、タスクＢからのメッセージ１０１Ｂの処理において入力として利用するためである。

【0046】

上記のような問題を解消してシステム全体として処理結果の決定性を保証する（言い換えれば、ノード１０間で同じ処理結果を得る）ために、本実施形態では、タスク単体が決定論的に振る舞うことに加えて、複数のメッセージ送信元を持つタスク２０について、どの順番でメッセージをディスパッチするかをノード１０間で合意を形成する。合意形成の詳細は後述する。

【0047】

一方、図５（Ｂ）のタスクＣのように、単一のメッセージ送信元（タスクＡ）しか持たない場合には、前述した通り、タスクＣにおいてメッセージ１０１Ａがどの処理順でディスパッチされるかは一意に決定される。具体的には、タスクＣにおいてメッセージ１０１Ａは＃３，＃４の処理順でディスパッチされる。したがって、単一のメッセージ送信元しか持たない単一パスの場合には、図５（Ａ）の場合のような合意形成は不要である。

【0048】

図６は、メッセージパス管理テーブル３５の一例を示す図である。図６に示したメッセージパス管理テーブル１１０は、図１に示したメッセージパス管理テーブル３５の一例であって、メッセージパスごとに、当該メッセージパスにおいてディスパッチ済みのメッセージ通番を管理する。メッセージパス管理テーブル１１０は、メッセージパス１１１、状態１１２，及びディスパッチ済みメッセージ通番１１３の項目を有して構成される。

【0049】

メッセージパス１１１は、当該レコードで管理するメッセージパスの送信元及び送信先を示す。

【0050】

状態１１２は、各メッセージパスについて、「ブロック状態」か否かの状態を示す。具体的には例えば、当該レコードのメッセージパスが「ブロック状態」とされている場合に、状態１１２に「ブロック」が設定される。詳細はメッセージ処理部による処理の説明で後述するが、あるメッセージ配送先タスクについて１番目のメッセージパスが存在するときに新たに２番目のメッセージパスが追加されるとき、２番目のメッセージパスに関する合意形成が完了するまで、１番目のメッセージパスは「ブロック状態」とされ、１番目のメッセージパス上のメッセージのディスパッチが保留される。この１番目のメッセージパスのブロック状態は、２番目のメッセージパスの追加に関する「メッセージパス追加」のログエントリについて合意形成が完了し、このログエントリが適用されるタイミングで、解除される。

【0051】

ディスパッチ済みメッセージ通番１１３は、当該レコードのメッセージパスにおいて、何番目のメッセージまでがディスパッチ済みであるかをメッセージ通番で示す。メッセージ通番は、メッセージパスごとにカウントされ、そのメッセージパス上でメッセージが発生するごとに１ずつカウントアップされて、その値が当該メッセージに付与される。この結果、メッセージパスとメッセージ通番は、各メッセージを一意に識別するために用いることができる。

【0052】

なお、メッセージパス管理テーブル１１０にメッセージ送信先とメッセージ送信元のペアが存在しない場合、新規メッセージパスとして扱い、メッセージパス管理テーブル１１０に新たなレコードを追加登録する。メッセージパス管理テーブル１１０への新規メッセージパスの追加は、新規メッセージパス追加に伴う合意形成後に行われる。すなわち、合意形成中に当該新規メッセージパスへのメッセージが再び発生した場合も、新規メッセージパスとして扱われる。

【0053】

また、メッセージパス管理テーブル１１０への登録は、ＦＴシステム１の実運用時に、メッセージが発生するごとに各メッセージパスを新規に登録することが想定されるが、変形例として、事前にある程度のメッセージパスを登録しておくようにしてもよい。すなわち、システムのテスト時に構築したメッセージパス管理テーブルの内容をファイル出力し、実運用時にはファイル出力した内容をメッセージパス管理テーブル１１０にロードしておくことで、ある程度のメッセージパスが構築された状態で実運用を開始するようにしてもよい。このようにすることで、実運用時のメッセージパスの登録処理に掛かる負荷を低減することができる。

【0054】

（４）合意形成処理
以下では、本実施形態に係るＦＴシステム１におけるノード１０間の合意形成について説明する。

【0055】

ＦＴシステム１において、ノード１０間で各種の合意形成をするにあたり、イベントログ３４（あるいは単にログ）が、その合意形成の過程や結果を管理する。合意形成プロトコルとしてはＲＡＦＴが知られており、本実施形態に係るＦＴシステム１は、基本的な点ではＲＡＦＴを用いて、ノード１０間の合意形成を行う。但し、説明の簡略のため、本実施形態の説明では、ＲＡＦＴを単純化して表現しており、例えばＲＡＦＴのリーダ再選出プロトコル等は記載を省略する。ＲＡＦＴにおけるログエントリの適用は、ログエントリの内容をステートマシンに反映させることを意味する。そして本実施形態におけるログエントリの適用は、ログエントリのタイプによって処理内容が異なる。

【0056】

本実施形態で取扱うログエントリのタイプは、「外部入力」、「メッセージ配送」、「メッセージパス追加」の３種類に大別することができる。

【0057】

「外部入力」のログエントリは、リーダが受信した外部からのイベントをフォロワに対して複製し、各ノードで同じ順にディスパッチすることを保証する、ことを目的とする。「外部入力」のログエントリを適用するときの具体的な動作としては、メッセージ処理部３２が、外部入力イベントの内容に応じて、これを処理する適切なタスクに、イベント内容をディスパッチする。外部入力のログエントリのデータ構成例は、図１１に示される。

【0058】

「メッセージ配送」のログエントリは、複数のメッセージ送信元を持つケースにおいて、どの順番でメッセージをディスパッチするかをノード間で一致化する、ことを目的とする。このようなログエントリの適用により、各メッセージは、メッセージパスとメッセージ通番の組合せによって一意に識別される。「メッセージ配送」のログエントリを適用するときの具体的な動作としては、メッセージ処理部３２が当該メッセージをディスパッチする。メッセージ配送のログエントリの具体例は、図１３に示される。

【0059】

「メッセージパス追加」のログエントリは、どのようなメッセージパスが存在するかをノード間で認識合わせをする、ことを目的とする。特に、１番目のメッセージパスが存在するときに新たに２番目のメッセージパスが追加されるときには、１番目のメッセージパスにおいて何番のメッセージ通番までディスパッチした後に２番目のメッセージパスを追加するか、についても併せてノード間で認識合わせする。「メッセージパス追加」のログエントリを適用するときの具体的な動作としては、メッセージ処理部３２が、メッセージパス管理テーブル３５（図５のメッセージパス管理テーブル１１０）に当該メッセージパスを追加する。さらに、１番目のメッセージパスの追加である場合、メッセージ処理部３２は、当該メッセージパスのメッセージ待機キュー３６上のメッセージを順にディスパッチする。また、２番目のメッセージパスの追加である場合、メッセージ処理部３２は、１番目のメッセージパスのメッセージ待機キュー３６上のメッセージを、合意したメッセージ通番まで順にディスパッチした後で、１番目のメッセージパスの「ブロック状態」を解除した上で、２番目のメッセージパスをメッセージパス管理テーブル３５（図５のメッセージパス管理テーブル１１０）に追加する。メッセージ追加パスのログエントリの具体例は、図１７，図１８に示される。

【0060】

図７は、ノード間におけるイベントログの合意形成の特徴を説明するための図である。図７には、異なるノード１０（リーダ、フォロワ１、フォロワ２）におけるログエントリの進行例が示されている。

【0061】

上記した３種類のログエントリに共通して、本実施形態におけるノード間のイベントログ３４の合意形成は、図７の場合、以下のように行われる。

【0062】

図７において、フォロワ１は＃５までログエントリの追記が完了しており、フォロワ２は＃６までログエントリの追記が完了している。このとき、リーダがフォロワ１，２からそれぞれの追記完了の通知を受信している場合、リーダは、自ノードを含む過半数のノードにおいて＃６まで追記が完了していることから、リーダは＃６までログエントリをコミットし、どこまでコミット済みかをフォロワ１，２に通知する。そして各ノードは、コミット済み、かつ未適用のログエントリがあれば、順に適用する。

【0063】

このようなイベントログ３４の合意形成の詳細な処理手順について、図８及び図９を参照しながら説明する。

【0064】

図８は、イベントログの合意形成におけるリーダの処理手順の一例を示すフローチャートである。図９は、イベントログの合意形成におけるフォロワの処理手順の一例を示すフローチャートである。なお、図８及び図９に示す処理は、ログエントリが「外部入力」タイプの場合は入力処理部３１によって実行され、「メッセージ配送」タイプや「メッセージパス追加」タイプの場合はメッセージ処理部３２によって実行されるが、以下の説明では簡略化して、メッセージ処理部３２が実行するものとして記載する。

【0065】

図８によればまず、リーダのメッセージ処理部３２が、ログエントリをログ（イベントログ３４）に追記する（ステップＳ１１）。次に、リーダのメッセージ処理部３２は、フォロワに、ログエントリの追記を要求する（ステップＳ１２）。

【0066】

ここで、図９に示すように、フォロワのメッセージ処理部３２は、図８のステップＳ１２の要求を受け取ると（ステップＳ２１）、当該ログエントリをメッセージパス上の送信順にログ（イベントログ３４）に追記する（ステップＳ２２）。そして、ログエントリの追記成功をリーダに通知する（ステップＳ２３）。

【0067】

次に図８では、リーダのメッセージ処理部３２が、ＦＴシステム１を構成する複数のフォロワのうちの過半数のフォロワから、ステップＳ２３の追記成功の通知を受け取ったか否かを判定する（ステップＳ１３）。ステップＳ１３では、自身を含めて過半数のノードが追記成功したかどうかを判定する。そして、過半数のフォロワから追記成功の通知を受け取った場合は（ステップＳ１３のＹＥＳ）、ステップＳ１４に進む。一方、過半数のフォロワから追記成功の通知を受け取っていない場合（ステップＳ１３のＮＯ）、リーダは図８の処理を終了し、過半数のフォロワから追記成功の通知を受け取るまで待機する。

【0068】

ステップＳ１４では、リーダのメッセージ処理部３２は、ステップＳ１３で過半数の通知があったログエントリを追記順が古いほうから順にコミットする。次に、リーダのメッセージ処理部３２は、フォロワに対して、どのログエントリまで（どのログエントリ通番まで）コミットしたかを通知する（ステップＳ１５）。そして最後に、リーダのメッセージ処理部３２は、コミット済みかつ未適用のログエントリを古いものから順に適用し（ステップＳ１６）、合意形成の処理を終了する。

【0069】

一方、フォロワでは、ステップＳ２３でログエントリの追記成功をリーダに通知した後、メッセージ処理部３２が、リーダからステップＳ１５のコミット通知を受信したか否かを判定する（ステップＳ２４）。コミット通知を受信した場合は（ステップＳ２４のＹＥＳ）、コミット済みかつ未適用のログエントリを古いものから順に適用し（ステップＳ２５）、合意形成の処理を終了する。また、コミット通知を受信していない場合は（ステップＳ２４のＮＯ）、特段の処理を行わずに処理を終了する。

【0070】

以上の図８及び図９の処理は、説明を簡便にするために、逐次的に処理が行われるフローチャートであったが、本実施形態はこれに限定されるものではなく、例えば、他のノードからの各種メッセージを待機する処理を挟む等、合意形成の処理を非同期に実施するようにしてもよい。また、以降の説明において「ログエントリのイベントログへの追記」が示される場合には、そのバックグラウンドにおいて図８及び図９に示した合意形成処理が動作するものとする（個々の説明を省略する）。

【0071】

（５）入力処理部３１
以下では、入力処理部３１による処理について詳しく説明する。より具体的には、外部入力されたイベントに対する入力処理部３１の受信処理について説明する。

【0072】

図１０は、リーダの入力処理部３１による受信処理の処理手順例を示すフローチャートである。図１０に示す処理は、リーダの入力処理部３１によって例えば定期的に実行される。

【0073】

図１０に示すように、リーダの入力処理部３１は、外部入力イベントを受信したか否かを判定する（ステップＳ３１）。外部入力イベントを受信していない場合（ステップＳ３１のＮＯ）、入力処理部３１は次の周期でステップＳ３１の処理を繰り返す。外部入力イベントを受信した場合（ステップＳ３１のＹＥＳ）、入力処理部３１は、受信した外部入力イベントのログエントリをログ（イベントログ３４）に追記する（ステップＳ３２）。

【0074】

図１１は、イベントログ３４に保持される外部入力タイプのログエントリのデータ構成例を示す図である。図１１に示したように、外部入力タイプのログエントリ１２０は、タイプ１２１及び外部入力１２２を有して構成される。タイプ１２１には、ログエントリの種類が示され、外部入力１２２には、外部入力の内容が示される。すなわち、外部入力タイプのログエントリは、外部から受信したイベントがそのまま、イベントログ３４に保持される。

【0075】

ステップＳ３２において入力処理部３１が外部入力イベントのログエントリをイベントログ３４に追記することで、図８及び図９を参照しながら説明した通り、合意形成処理が動作し、結果として、当該外部入力イベントの内容がリーダからフォロワに転送される。したがって、フォロワは、図１０のような外部入力イベントを直接受信する処理を持たない。

【0076】

以上のような受信処理を行うことにより、入力処理部３１は、どのノード１０でも同じイベントを同じ順番でディスパッチすることを保証する。

【0077】

その後、入力処理部３１は、外部入力イベントの内容に応じて、それを処理する適切なタスク２０に対してメッセージを行うことにより、当該イベントを処理させる。具体的には、入力処理部３１は、メッセージ処理部２２に対してタスク２０の動作を要求するメッセージ要求を送信し、このメッセージ要求を受信したメッセージ処理部２２が、後述する図１２のメッセージ要求受付処理を行うことにより、タスク２０にメッセージを送信する。

【0078】

なお、後述するように、タスク間のメッセージにおいては、当該メッセージのディスパッチ順をノード間で一致させるための合意形成（メッセージ配送順の合意形成）が行われるが、外部入力イベントについてのメッセージは、当該メッセージを行う時点でノード間におけるディスパッチ順が一致していることから、メッセージ配送順の合意形成の対象外である。

【0079】

（６）メッセージ処理部３２
以下では、メッセージ処理部３２による各種の処理について詳しく説明する。

【0080】

（６－１）メッセージ要求受付処理
図１２は、メッセージ要求受付処理の処理手順例を示すフローチャートである。図１２に示すメッセージ要求受付処理は、メッセージ処理部２２がタスク２０からのメッセージ要求を受理したときに実行される。

【0081】

図１２によればまず、メッセージ処理部２２は、受理したメッセージ要求が新規のメッセージパス上のメッセージ配送を要求するものであるか否かを判定する（ステップＳ４１）。具体的には、メッセージ処理部２２は、メッセージ要求が示すメッセージ送信先とメッセージ送信元との組み合わせがメッセージパス管理テーブル１１０に登録されているかを確認し、メッセージパス管理テーブル１１０にメッセージ送信先とメッセージ送信元のペアが存在しない場合に新規メッセージパスと判定することができる。

【0082】

ステップＳ４１において新規のメッセージパスである場合（ステップＳ４１のＹＥＳ）、メッセージ処理部２２は、新規のメッセージパスを追加するメッセージパス追加処理を行う（ステップＳ４２）。詳細は図１５等を参照しながら後述するが、ステップＳ４２のメッセージパス追加処理では、「メッセージパス追加」タイプのログエントリがログ（イベントログ３４）に追記される。このとき、前述した通り、ログエントリのログへの追記に伴って、図８及び図９に示した合意形成処理が動作する。そしてステップＳ４２の処理後、メッセージ処理部２２は、受理したメッセージ要求をメッセージ待機キュー３６に追加し（ステップＳ４３）、処理を終了する。

【0083】

ステップＳ４１において新規のメッセージパスではない場合（ステップＳ４１のＮＯ）、メッセージ処理部２２は、受理したメッセージ要求によるメッセージが、複数のメッセージ送信元を持つタスク２０に対するメッセージであるか否かを判定する（ステップＳ４４）。

【0084】

ステップＳ４４において複数のメッセージ送信元を持つタスク２０に対するメッセージであった場合（ステップＳ４４のＹＥＳ）、メッセージ処理部２２は、「メッセージ配送」タイプのログエントリをログ（イベントログ３４）に追記する（ステップＳ４５）。その後は、ノード間で合意形成するまでメッセージを実行できないため、前述したステップＳ４３に進み、受理したメッセージ要求をメッセージ待機キュー３６に追加して処理を終了する。

【0085】

ステップＳ４４において複数のメッセージ送信元を持たない（すなわち単一パスで繋がれた）タスク２０に対するメッセージであった場合（ステップＳ４４のＮＯ）、メッセージ処理部２２は、当該メッセージパスがブロック状態とされているか否かを確認する（ステップＳ４６）。当該メッセージパスがブロック状態である場合（ステップＳ４６のＹＥＳ）、ノード間で合意形成するまでメッセージを実行できないため、前述したステップＳ４３に進み、受理したメッセージ要求をメッセージ待機キュー３６に追加して処理を終了する。一方、当該メッセージパスがブロック状態ではない場合には（ステップＳ４６のＮＯ）、合意形成は不要であることから、メッセージ処理部２２は、受理したメッセージ要求による当該メッセージを実行し（ステップＳ４７）、処理を終了する。

【0086】

以上のように図１２に示すメッセージ要求受付処理によれば、新規のメッセージパスによるメッセージの場合、及び複数のメッセージ送信元を持つタスクへのメッセージの場合には、ノード間で合意形成するまでは当該メッセージを実行しないため、メッセージ待機キュー３６にメッセージ要求を一時保留させる。また、既存の単一メッセージパスに対する要求については、当該メッセージパスがブロック状態でない限りは、合意形成することなしにメッセージを実行することができる。また、送信先のタスクに対する２番目のメッセージパスの追加中（ノード間で合意形成中）は、１番目のメッセージパスによるメッセージはブロックされる。

【0087】

図１３は、メッセージ配送タイプのログエントリの具体例を示す図である。図１３に示したように、メッセージ配送タイプのログエントリ１３０は、タイプ１３１及びメッセージ１３２を有して構成される。タイプ１３１には、当該ログエントリが有する情報のタイプとして、メッセージパスとメッセージ通番が示される。そしてメッセージ１３２には、タイプ１３１に示された各タイプの情報の内容が示される。

【0088】

複数のメッセージ送信元を持つメッセージ送信先へのメッセージについては、図１３に示したログエントリ１３０のような「メッセージ配送」タイプのログエントリをログ（イベントログ３４）に追記し、どの順番でメッセージをディスパッチするかをノード間で合意形成する。具体的には、図１３に示したログエントリ１３０が適用される場合、タスクＡからタスクＣへのメッセージパス「Ａ→Ｃ」上のメッセージ通番「３」のメッセージが、タスクＣに対してディスパッチされる。

【0089】

（６－２）メッセージパス追加処理
以下では、新規のメッセージパスが追加されるときの処理について詳しく説明する。

【0090】

前述したように、ＦＴシステム１では、複数のメッセージ送信元を持つメッセージ送信先へのメッセージについては、ノード１０間においてメッセージのディスパッチ順の一致化が必要となる。しかし、複数のメッセージ送信元が存在するか否かは、事前に容易に把握できないことがある。そこで、本実施形態では、イベント発生に基づくタスク２０の実行時に、新規のメッセージパスを追加できるようにする。そしてこのときに不整合が起きないよう、各ノード１０が同じ状態（ディスパッチするメッセージ通番を揃えた状態）で新規のメッセージパスを追加するように合意形成する。

【0091】

図１４は、メッセージパスを追加するときのノード間の関係を説明するためのモデル図である。図１４を参照しながら、新規のメッセージパスを追加するときの合意形成の必要性について、より具体的に説明する。

【0092】

図１４には、既存のメッセージパス「Ａ→Ｂ」が存在する状況で、新規のメッセージパス「Ｄ→Ｂ」を追加するというケースが例示されている。なお、図１４において着色済みのメッセージ１０１は、ディスパッチ済みのメッセージを表している。具体的には、図１４の場合、ノード１（リーダ）は＃５までディスパッチ済みであり、ノード２（フォロワ１）は＃６までディスパッチ済みである。

【0093】

図１４において、新規のメッセージパス「Ｄ→Ｂ」を追加するまでは、タスクＢをメッセージ送信先とするメッセージパスは「Ａ→Ｂ」の単一のメッセージパスしか存在しないため、「Ａ→Ｂ」上のメッセージについてノード間の同期が行われない。したがって、「Ｄ→Ｂ」のメッセージパスを追加しようとした時点で、何番までメッセージをディスパッチ済みかはノード間で一致しないことがある。

【0094】

図１４のケースを用いて具体的に説明すると、仮に、ノード間で合意形成を行わずに、各ノードが各自のタイミングで新規のメッセージパス「Ｄ→Ｂ」を追加してメッセージのディスパッチを行うとした場合、ノード１では、「Ａ→Ｂ」上の＃５のメッセージがディスパッチされた後に、新規のメッセージパス「Ｄ→Ｂ」が追加され、「Ｄ→Ｂ」上の＃１のメッセージがディスパッチされ、その後に「Ａ→Ｂ」上の＃６，＃７のメッセージが順にディスパッチされることになる。このとき、ノード１（リーダ）のイベントログ３４には、「Ａ→Ｂ ＃５」、「Ｄ→Ｂ 追加」、「Ｄ→Ｂ ＃１」、「Ａ→Ｂ ＃６」、「Ａ→Ｂ ＃７」の順でログエントリが記録される。新規のメッセージパスの追加とその直前のメッセージ（上記の１番目と２番目）は、不可分な１つのログエントリとして記録されてもよい。

【0095】

一方、ノード２では、新規のメッセージパス「Ｄ→Ｂ」が追加される前に、「Ａ→Ｂ」上の＃６のメッセージがディスパッチ済みであることから、「Ａ→Ｂ」上の＃６のメッセージがディスパッチされた後に、「Ｄ→Ｂ」上の＃１のメッセージがディスパッチされ、その後に「Ａ→Ｂ」上の＃７のメッセージがディスパッチされることになる。このとき、ノード２（フォロワ）のイベントログ３４には、「Ａ→Ｂ ＃６」、「Ｄ→Ｂ 追加」、「Ｄ→Ｂ ＃１」、「Ａ→Ｂ ＃７」の順でログエントリが記録される。ノード１の場合と同様、新規のメッセージパスの追加とその直前のメッセージ（上記の１番目と２番目）は、不可分な１つのログエントリとして記録されてもよい。

【0096】

上記したノード１及びノード２の処理結果を比較すると、イベントログ３４には異なるログエントリが記録され、ノード１とノード２との間では同期を維持できなくなることが分かる。

【0097】

そこで、本実施形態では、「Ｄ→Ｂ」のメッセージパスを追加した後、「Ａ→Ｂ」上のメッセージと「Ｄ→Ｂ」上のメッセージについて、どのような順にディスパッチするか、ノード間で一致化させる必要がある。すなわち、「Ａ→Ｂのメッセージパス上のメッセージをＸ番までディスパッチしたところで、Ｄ→Ｂのメッセージパスを追加する」ということを、ノード間で合意形成する必要がある。

【0098】

具体的には、まず、ＲＡＦＴには規定されていない本実施形態固有のプロトコルとして、各ノードは、新規のメッセージパスを追加した場合に、図１４の右側に示したように、そのメッセージパス追加に関するメッセージパス情報１０２を他のノードにブロードキャストする。例えば、図１４に示された（ノード１，Ａ→Ｂ，５）というメッセージパス情報１０２は、「ノード１」において、「Ａ→Ｂ」のメッセージパス上で「＃５」のメッセージがディスパッチ済みとなったタイミングで、新たなメッセージパスが追加されたことを表している。次に、リーダが、各ノードからブロードキャストされたメッセージパス情報１０２に基づいて、各ノードにおいて既存のメッセージパス「Ａ→Ｂ」上でディスパッチ済みのメッセージ通番の最大値（例えば＃６）を判別する。そして、以上の処理を踏まえて、各ノードが、「「Ａ→Ｂ」上のディスパッチ済みのメッセージ通番の最大値（＃６）の後に、「Ｄ→Ｂ」のメッセージパスを追加すること」をノード間で合意形成することにより、全てのノードで同期をとることができる。

【0099】

以下に、上記の合意形成の契機となる、メッセージパスを追加する処理（メッセージパス追加処理）について詳しく説明する。

【0100】

図１５は、メッセージパス追加処理の処理手順例を示すフローチャートである。図１５に示すメッセージパス追加処理は、図１２のステップＳ４２に相当する処理であって、メッセージ送信要求の受理によって新規のメッセージパスの追加が必要となる場合に、各ノード１０のメッセージ処理部２２によって実行される。

【0101】

図１５によればまず、メッセージ処理部２２は、新規に追加するメッセージパス（以後、新規メッセージパス）が、メッセージ送信先にとって２番目のパスであるか否かを判定する（ステップＳ５１）。

【0102】

ステップＳ５１において新規メッセージパスが２番目のメッセージパスである場合（ステップＳ５１のＹＥＳ）、メッセージ処理部２２は、１番目のメッセージパスをブロック状態に設定する（ステップＳ５２）。次いで、メッセージ処理部２２は、既存のメッセージパスのメッセージパス情報（図１４及び図１８を参照）を、他ノードにブロードキャストし（ステップＳ５３）、メッセージパス追加処理を終了する。

【0103】

なお、ステップＳ５３のブロードキャストを受信した各ノードでは、後述する図１９のメッセージパス情報受信処理が行われることにより、受信したメッセージパス情報がメッセージパス管理テーブル３５に登録され、リーダノードが、ノード間で一致化させるディスパッチ順を決定する。

【0104】

ステップＳ５１において新規メッセージパスが２番目のメッセージパスではない、すなわち、１番目または３番目以降のメッセージパスである場合（ステップＳ５１のＮＯ）、メッセージ処理部２２は、自ノードがリーダであるか否かを確認する（ステップＳ５４）。自ノードがリーダである場合（ステップＳ５４のＹＥＳ）、メッセージ処理部２２は、「メッセージパス追加」タイプのログエントリをログ（イベントログ３４）に追記し（ステップＳ５５）、メッセージパス追加処理を終了する。自ノードがフォロワである場合（ステップＳ５４のＮＯ）、メッセージ処理部２２は、特段の処理を行うことなくメッセージパス追加処理を終了する。

【0105】

図１６は、メッセージパス追加タイプのログエントリの一例を示す図である。図１６に示したログエントリ１４０は、新規メッセージパスが１番目または３番目以降のメッセージパスである場合に、図１５のステップＳ５５でログ（イベントログ３４）に追記されるログエントリの一例である。

【0106】

ログエントリ１４０は、新規メッセージパスの追加を単位として管理されるデータであって、既存のメッセージパスを示す既存メッセージパス１４１と、新規メッセージパスを示す追加メッセージパス１４２と、新規メッセージパスの追加時に既存のメッセージパス上でディスパッチ済みのメッセージの通番を示すディスパッチ済み通番１４３とを有する。

【0107】

図１６のログエントリ１４０の場合は、新規メッセージパスがメッセージ送信先にとって２番目のメッセージパスではないため、既存メッセージパスのメッセージパス情報をブロードキャストする処理（図１５のステップＳ５３）は行われない。さらに、図１５のステップＳ５３を受けて各ノードで実行される図１９のメッセージパス情報追加処理も実行されないので、ディスパッチ通番を参照する必要もない（図１９のステップＳ６４が行われない）。したがって、図１６のログエントリ１４０では、既存メッセージパス１４１及びディスパッチ済み通番１４３に値を指定しなくてよく、追加メッセージパス１４２に、新規メッセージパスがタスクＡからタスクＢに向けたメッセージパスであることを示す「Ａ→Ｂ」が指定される。

【0108】

図１７は、メッセージパス追加タイプのログエントリの別例を示す図である。図１７に示したログエントリ１５０は、新規メッセージパスが１番目または３番目以降のメッセージパスである場合に、後述する図１９のステップＳ６４でログ（イベントログ３４）に追記されるログエントリの一例である。

【0109】

ログエントリ１５０は、図１６のログエントリ１４０と同様に、新規メッセージパスの追加を単位として管理されるデータであって、既存のメッセージパスを示す既存メッセージパス１５１と、新規メッセージパスを示す追加メッセージパス１５２と、新規メッセージパスの追加時に既存のメッセージパス上でディスパッチ済みのメッセージの通番を示すディスパッチ済み通番１５３とを有する。

【0110】

具体的には、図１７のログエントリ１５０を適用した場合には、既存の「Ａ→Ｂ」のメッセージパス上でメッセージ通番「５」番までをディスパッチした後、「Ｄ→Ｂ」のメッセージパスがメッセージパス管理テーブル３５に追加される。

【0111】

図１８は、メッセージパス情報の一例を示す図である。メッセージパス情報は、あるメッセージ送信先に対する２番目のメッセージパスが追加される際に、１番目のメッセージパス上でどこまでメッセージがディスパッチされたかをノード間で共有するためのデータである。また、メッセージパス情報は、どのタイミングでメッセージパスの追加を行うか、リーダが判断するためのヒントとして用いられる。

【0112】

図１８に示すメッセージパス情報１６０は、ノードＩＤ１６１、既存メッセージパス１６２、追加メッセージパス１６３、及びディスパッチ済み通番１６４を有する。ノードＩＤ１６１は、当該メッセージパス情報１６０の送信元のノード１０の識別子を示す。既存メッセージパス１６２は、既存の１番目のメッセージパスの送信元及び送信先を示す。追加メッセージパス１６３は、追加しようとしているメッセージパス（すなわち、既存メッセージパスと同じメッセージ送信先を持つ２番目のメッセージパス）の送信元及び送信先を示す。ディスパッチ済み通番１６４は、既存メッセージパス１６２に示される１番目のメッセージパスにおいてディスパッチ済みのメッセージ通番の最大値を示す。

【0113】

図１９は、メッセージパス情報受信処理の処理手順例を示すフローチャートである。図１９に示すメッセージパス情報受信処理は、図１５のステップＳ５３で既存のメッセージパスのメッセージパス情報がブロードキャストされたときに、このメッセージパス情報を受信した各ノード１０においてメッセージ処理部２２が実行する処理である。すなわち、メッセージパス情報受信処理は、新規メッセージパスがメッセージ送信先にとって２番目のパスである場合に実行される。

【0114】

図１９によればまず、メッセージ処理部２２は、受信したメッセージパス情報をメッセージパス管理テーブル３５に登録する（ステップＳ６１）。メッセージパス管理テーブル３５の具体例は、後述する図２０に示される。

【0115】

次に、メッセージ処理部２２は、自ノードがリーダであるか否かを確認する（ステップＳ６２）。自ノードがリーダである場合は（ステップＳ６２のＹＥＳ）、ステップＳ６３に進み、自ノードがリーダではない、すなわちフォロワである場合は（ステップＳ６２のＮＯ）、メッセージパス情報受信処理を終了する。

【0116】

ステップＳ６３では、リーダのメッセージ処理部２２は、他の全ノードから、当該新規メッセージパスの追加に関するメッセージパス情報を受信済みであるか否かを判定する。他の全ノードから上記メッセージパス情報を受信済みである場合（ステップＳ６３のＹＥＳ）、ステップＳ６４に進み、他の全ノードからの上記メッセージパス情報が揃っていない場合は（ステップＳ６３のＮＯ）、メッセージパス情報受信処理を終了する。

【0117】

ステップＳ６４では、リーダのメッセージ処理部２２は、自ノードを含むの全てのノードからのメッセージパス情報に基づいて、既存のメッセージパス上のディスパッチ済みのメッセージ通番の最大値を判別する。そして、判別した最大値のメッセージ通番をディスパッチ済み通番とした「メッセージパス追加」タイプのログエントリをログ（イベントログ３４）に追記し、メッセージパス情報受信処理を終了する。

【0118】

図２０は、メッセージパス管理テーブル３５の具体例を示す図である。図２０に示したメッセージパス管理テーブル１７０は、メッセージパス１７１及びディスパッチ済みメッセージ通番１７２を有する。メッセージパス１７１は、既存のメッセージパスの送信元及び送信先を示し、ディスパッチ済みメッセージ通番１７２は、既存メッセージパス上のディスパッチ済みのメッセージ通番を示す。

【0119】

ここで、図２０のメッセージパス管理テーブル１７０は、「Ａ→Ｂ」のメッセージパス１７１におけるディスパッチ済みメッセージ通番１７２が「５，８」となっている。これは例えば、他ノードからのメッセージパス情報の受信（図１９のステップＳ６１）において、メッセージパス「Ａ→Ｂ」上のディスパッチ済み通番が「５」であることを示すメッセージパス情報（例えば図１８に示したノードＩＤ「２」からのメッセージパス情報１６０）とは別に、メッセージパス「Ａ→Ｂ」上のディスパッチ済み通番が「８」であることを示すメッセージパス情報を受信したことを意味する。このようなメッセージパス管理テーブル１７０がリーダノード１０Ａのメッセージパス管理テーブル３５である場合、図１９のステップＳ６４において、リーダのメッセージ処理部２２は、メッセージパス「Ａ→Ｂ」上のディスパッチ済みのメッセージ通番の最大値が「８」であると判別する。したがって、ステップＳ６４においてリーダのメッセージ処理部２２は、既存メッセージパス１５１を「Ａ→Ｂ」、追加メッセージパス１５２を「Ｄ→Ｂ」、ディスパッチ済み通番１５３を「８」とした「メッセージパス追加」タイプのログエントリを、ログ（イベントログ３４）に追記することになる。

【0120】

以上に説明した図１５のメッセージパス追加処理及び図１９のメッセージパス情報受信処理は、以下のような特徴を備える。

【0121】

メッセージ送信先のタスク等にとって新規メッセージパスが２番目のメッセージパスである場合に、メッセージパス情報受信処理において「メッセージパス追加」タイプのログエントリがログに追記される（図１９のステップＳ６４）ことに伴って、ノード間でメッセージパス追加の合意形成が行われる。このとき、新規メッセージパスの追加に関する合意形成が完了するまで、当該メッセージ送信先へのメッセージのディスパッチが保留される（図１５のステップＳ５２）。

【0122】

また、メッセージパス追加の合意形成が完了し、当該ログエントリがコミット及び適用されることで、当該メッセージパスがメッセージパス管理テーブル３５に追加される（図１５のステップＳ５５，図１９のステップＳ６１）。

【0123】

新規メッセージパスが１番目のメッセージパスである場合、メッセージパス管理テーブル３５に当該メッセージパスが追加されるまで、１番目のメッセージパス上のメッセージのディスパッチを保留する。

【0124】

新規メッセージパスが３番目以降のメッセージパスである場合、当該新規メッセージパスの追加以降に発生するメッセージ送信先へのメッセージについては、当該新規メッセージパスの追加に相当する「メッセージパス追加」タイプのログエントリの後に、ログに追記されることから、結果として、新規メッセージパスの追加が完了するまでディスパッチが保留されることになる。

【0125】

（６－３）メッセージパス追加時のメッセージ待機時間の改善
前述した通り、２番目のメッセージパスを追記する際には、「メッセージパス追加」タイプのログエントリについてノード間の合意形成が完了し、メッセージパス管理テーブルに当該メッセージパスが追加されるまで、１番目のメッセージパス上のメッセージは、一時的にディスパッチが保留される。このとき、ＦＴシステム１では、ディスパッチが保留されている時間（メッセージ待機時間）だけ、処理が停滞する。

【0126】

このような処理の停滞を抑制するために、例えば、システムテストの段階でメッセージパス管理テーブル３５の内容をある程度構築してその内容を退避させ、実運用時に当該内容を復元することが考えられる。この方法によれば、動的なメッセージパスの追加の発生頻度をある程度抑制することができるが、さらなる抑制ができるとより好ましい。

【0127】

そこで、本実施形態では、メッセージ待機時間をさらに改善する方法として、例えば以下の２つの改善方法を採用することができる。

【0128】

（６－３－１）第１の改善方法
第１の改善方法は、ノードが、２番目のメッセージパスの追加に関するメッセージパス情報を他ノードから受信した時点で、メッセージパス管理テーブル３５へのメッセージパス情報の追記（図１９のステップＳ６１）に先行して、当該メッセージパス情報に記載されたディスパッチ済みメッセージ通番の最大値まで、１番目のメッセージパス上のメッセージをディスパッチするものである。

【0129】

第１の改善方法は、ノードの増減が殆どない状況に適しており、最大限、ディスパッチの保留による遅延を抑制することができる。

【0130】

但し、第１の改善方法は、ノードの増減頻度が高い状況では、次のようなリスクを有する。メッセージパス情報でディスパッチ済みメッセージ通番の最大値Ｍを報告したノードが、当該メッセージパス情報をリーダに伝える前に障害停止した場合、リーダはＮ＜ＭとなるＮをディスパッチ済みメッセージ通番として、「メッセージパス追加」タイプのログエントリをログに追記する。このとき既にＭまでディスパッチ済みのノードが存在した場合、そのノードはリーダから指示された通りにログエントリを適用することができず、クラスタから除外する必要がある。したがって、ノードの増減頻度が高いほど、ＦＴシステム１におけるノード１０の多重系を維持できなくなるリスクが上昇する。

【0131】

（６－３－２）第２の改善方法
第２の改善方法は、メッセージパス追加の合意形成において、上述した方法のようにリーダが全てのノードから２番目のメッセージパスの追加に関するメッセージパス情報を受信してからノード間で合意形成するのではなく、リーダが全てのノードから２番目のメッセージパスの追加に関するメッセージパス情報を受信していく途中で、メッセージ済み通番の最大値が更新された場合に都度、ＲＡＦＴなどの合意形成プロトコルに基づきノード間でメッセージパス追加の合意形成を行い、合意形成できた段階までメッセージをディスパッチするものである。以下に、第２の改善方法を実現するための構成及び処理について詳しく説明する。

【0132】

第２の改善方法を採用する場合、ＦＴシステム１は、新たな種類のログエントリとして、「メッセージパス情報」タイプのログエントリを導入する。

【0133】

「メッセージパス情報」のログエントリは、あるメッセージ送信先に２本目のメッセージパスを追加する際に、既存のメッセージパス上のディスパッチ済みメッセージ通番について、「少なくともＮ番までディスパッチした後に新規メッセージパスを追加する」ことについてノード間で合意をとる、ことを目的とする。合意形成は過半数のノードからの応答があれば可能であるため、このような「メッセージパス情報」のログエントリを利用することにより、リーダが全てのフォロワからメッセージパス情報を受信する前に、先行的に、Ｎ番までのメッセージ要求をディスパッチすることができる。「メッセージパス情報」のログエントリを適用するときの具体的な動作としては、「ブロック状態」が設定された既存のメッセージパス上で滞留しているメッセージ要求について、当該「メッセージパス情報」のログエントリに示されるディスパッチ済みメッセージ通番に対応するメッセージ要求までを、順にディスパッチする。

【0134】

図２１は、メッセージパス情報タイプのログエントリの一例を示す図である。図２１に示したように、メッセージパス情報タイプのログエントリ１８０は、タイプ１８１及びメッセージパス情報１８２を有して構成される。タイプ１８１には、当該ログエントリが有する情報のタイプとして、ノードＩＤ、既存メッセージパス、追加メッセージパス、及びディスパッチ済み通番が示される。そしてメッセージパス情報１８２には、タイプ１８１に示された各タイプの情報の内容が示される。

【0135】

図２２は、第２の改善方法によるメッセージパス追加の処理手順例を示すシーケンス図である。図２２では、説明のために簡略化したノード構成として、１つのリーダ（ノードＩＤ＝１）と２つのフォロワ（ノードＩＤ＝２，３）とが示されている。また、後述する各ステップの処理は、対応するノードのメッセージ処理部３２が実行する。

【0136】

図２２において、ログエントリ１９１，１９３は、ステップＳ７１，Ｓ７３でログ（イベントログ３４）に追記される「メッセージパス情報」タイプのログエントリの一例であり、ログエントリ１９５は、ステップＳ７５でログ（イベントログ３４）に追記される「メッセージパス追加」タイプのログエントリの一例である。また、メッセージパス情報１９２，１９４は、ステップＳ７２，Ｓ７４でブロードキャストされるメッセージパス情報の一例である。メッセージパス情報１９２，１９４は、ＲＡＦＴには規定されていない本実施形態固有のプロトコルによって、あるノードから他ノードにブロードキャストされる通知である。

【0137】

図２２によればまず、リーダノードであるノード１が、自ノードの「メッセージパス情報」のログエントリ１９１をログに追記する（ステップＳ７１）。このログへの追記の結果、ＲＡＦＴプロトコルに従って、当該ログの複製がフォロワノード（ノード２，３）にブロードキャストされる。そして各ノードは、ログエントリ１９１のコミットを完了し次第、これを適用する。この結果、各ノードは、具体的には、メッセージ通番「５」まで、メッセージパス「Ａ→Ｂ」上でブロックされていたメッセージ要求をディスパッチする。

【0138】

その後、フォロワノードであるノード３から、メッセージ通番「６」をディスパッチ済みとするメッセージパス情報１９２がブロードキャストされたとする（ステップＳ７２）。

【0139】

この場合、メッセージパス情報１９２を受信したノード１は、メッセージパス情報１９２におけるメッセージパス「Ａ→Ｂ」上のディスパッチ済みメッセージ通番が「６」となっており、ステップＳ７１でログに追記したログエントリ１９１に示されるディスパッチ済みメッセージ通番の「５」よりも大きいことから、メッセージパス情報１９２の内容を示す「メッセージパス情報」タイプのログエントリ１９３をログに追記する（ステップＳ７３）。この追記により、「メッセージパス情報」タイプのログエントリにおけるディスパッチ済みメッセージ通番が「６」に更新される。そして、ステップＳ７１におけるログへの追記と同様、ノード１は、ＲＡＦＴプロトコルに従って、当該ログの複製をフォロワノード（ノード２，３）にブロードキャストし、各ノードはコミットが完了し次第、これを適用する。

【0140】

またその後、フォロワノードであるノード２から、メッセージ通番「４」をディスパッチ済みとするメッセージパス情報１９４がブロードキャストされたとする（ステップＳ７４）。この場合、メッセージパス情報１９４を受信したノード１は、メッセージパス情報１９４におけるメッセージパス「Ａ→Ｂ」上のディスパッチ済みメッセージ通番が「４」であり、これまでのディスパッチ済みメッセージ通番の最大値である「６」よりも小さいので、特段の処理を行わない。

【0141】

そして、リーダノードであるノード１は、全てのノードからのメッセージパス情報を受信すると、最終的にログに追記された「メッセージパス情報」タイプのログエントリに基づいて、「メッセージパス追加」タイプのログエントリを生成し、これをログ（イベントログ３４）に追記する（ステップＳ７５）。具体的には、メッセージパス「Ａ→Ｂ」上のディスパッチ済みメッセージ通番を「６」とし、追加メッセージパスを「Ｄ→Ｂ」とする「メッセージパス追加」タイプのログエントリ１９５をログに追記する。なお、このログ追記以降の適用処理等は、図１２で説明した処理と同様である。

【0142】

上記のように、第２の改善方法では、メッセージパスを追加する際に「メッセージパス情報」のログエントリを利用して合意形成を行うため、図１５に示したメッセージパス追加処理と、図１９に示したメッセージパス情報受信処理の処理手順が、以下のように一部変更される。

【0143】

図２３は、第２の改善方法によるメッセージパス追加処理の処理手順例を示すフローチャートである。図２３のフローチャートについて、図１５に示したメッセージパス追加処理との相違点を中心に説明し、共通する処理の説明は省略する。

【0144】

図２３によれば、ステップＳ５２において１番目のメッセージパスをブロック状態に設定した後、メッセージ処理部２２が、自ノードがリーダであるか否かを確認する（ステップＳ８１）。そして、自ノードがリーダである場合に（ステップＳ８１のＹＥＳ）、メッセージ処理部２２は、自ノードの「メッセージパス情報」のログエントリをログに追記する（ステップＳ８２）。このステップＳ８２の処理は、ＲＡＦＴプロトコルにおけるログ追記によって実現され、図２２のステップＳ７１で説明したように、ログへの追記の結果、ＲＡＦＴプロトコルに従って、当該ログの複製がフォロワにブロードキャストされる。一方、自ノードがリーダではない、すなわちフォロワであった場合は（ステップＳ８１のＮＯ）、図２２のステップＳ７２，Ｓ７４で説明したように、メッセージ処理部２２が、ＲＡＦＴプロトコルから独立した本実施形態固有のメッセージ送信によって、既存のメッセージパスのメッセージパス情報を他ノードにブロードキャストする（ステップＳ５３）。

【0145】

図２４は、第２の改善方法によるメッセージパス情報受信処理の処理手順例を示すフローチャートである。図２４のフローチャートについて、図１９に示したメッセージパス情報受信処理との相違点を中心に説明し、共通する処理の説明は省略する。

【0146】

図２４によれば、メッセージパス情報を受信したノードのメッセージ処理部２２が当該メッセージパス情報をメッセージパス管理テーブル３５に登録し（ステップＳ６１）、当該ノードがリーダノードであった場合に（ステップＳ６２のＹＥＳ）、新規メッセージパスの追加に関するメッセージパス情報を他の全てのノードから受信済みであるか否かを判定する（ステップＳ６３）。

【0147】

そして、ステップＳ６３においてリーダが新規メッセージパスの追加に関するメッセージパス情報を他の全てのノードから受信済みでない場合に（ステップＳ６３のＮＯ）、リーダのメッセージ処理部２２は、ステップＳ６１におけるメッセージパス情報のメッセージパス管理テーブル３５への登録によってディスパッチ済みメッセージ通番の最大値が更新されたか否かを確認する（ステップＳ９１）。

【0148】

ステップＳ９１においてディスパッチ済みメッセージ通番の最大値が更新されていた場合（ステップＳ９１のＹＥＳ）、リーダのメッセージ処理部２２は、ステップＳ６１で受信したメッセージパス情報に基づいて、「メッセージパス情報」タイプのログエントリをログに追記し（ステップＳ９２）、メッセージパス情報受信処理を終了する。ステップＳ９２の処理は、図２２のステップＳ７１の処理に相当する。すなわち、リーダのメッセージ処理部２２は、既存のメッセージパス上のディスパッチ済みメッセージ通番について、現時点で他ノードから受信したメッセージパス情報のなかで自ノード分も含めた「最大値」が更新された場合に、すべてのノードからメッセージパス情報を受信する前の途中でも、「メッセージパス情報」タイプのログエントリをログに追記する。

【0149】

一方、ステップＳ９１においてディスパッチ済みメッセージ通番の最大値が更新されていなかった場合（ステップＳ９１のＮＯ）、リーダのメッセージ処理部２２は特段の処理を行わずにメッセージパス情報受信処理を終了する。この処理手順は、図２２のステップＳ７４においてフォロワ（ノード２）からメッセージパス情報１９４がブロードキャストされた場合に、このメッセージパス情報１９４を受け取ったリーダ（ノード１）が特段の処理を行わないことに対応している。

【0150】

以上の説明をまとめると、メッセージパス追加時の第２の改善方法は、（６－２）で説明したメッセージパス追加処理の方法と比べたときに、次のような特徴を有する。

【0151】

第２の改善方法における（６－２）のメッセージパス追加処理との相違点として、まず、「メッセージパス情報」タイプのログエントリが導入される。そして、リーダノードは、メッセージパス情報をフォロワノードにブロードキャストする代わりに、「メッセージパス情報」タイプのログエントリをログに追記する。その結果、ＲＡＦＴプロトコルに従って、当該ログの複製がフォロワノードにブロードキャストされる。

【0152】

また、リーダノードがフォロワノードからメッセージパス情報を受信したとき、既存メッセージパスにおけるディスパッチ済みメッセージ通番の最大値が更新される場合には、リーダノードは、受信した上記メッセージパスに対応する「メッセージパス情報」タイプのログエントリをログに追記する。

【0153】

また、「メッセージパス情報」タイプのログエントリがコミットされ、このコミットを受けて各ノードが当該ログエントリの内容を適用する際には、当該ログエントリ（メッセージパス情報）に示されるディスパッチ済みメッセージ通番まで、既存メッセージパス上でブロックされているメッセージ要求がディスパッチされる。

【0154】

一方、第２の改善方法における（６－２）のメッセージパス追加処理との共通点としては、例えば、フォロワはメッセージパス情報を他のノードにブロードキャストすることが挙げられる。このような構成とする理由は、メッセージパス追加処理の最中にリーダが障害等によって停止し、新しくリーダとなったフォロワが当該メッセージパス追加処理を継続して実施する際には、各フォロワからブロードキャストされた情報が必要になるためである。また、リーダは、全てのノードからメッセージパス情報を受信したとき、「メッセージパス追加」タイプのログエントリをログに追記する。さらに、この「メッセージパス追加」タイプのログエントリを適用する際の処理も、（６－２）のメッセージパス追加処理と共通である。

【0155】

第２の改善方法は、上記のような特徴を備えることにより、リーダが全てのノードからメッセージパス情報を受信し終わる前に、ブロックされているメッセージ要求の一部を、安全にディスパッチすることができる。ここでの「安全」とは、処理途中で障害等によって一部のノードが離脱しても、図１４を参照しながら説明したような、ノード間で同期を維持できなくなる状況には陥らない、ことを意味する。第２の改善方法は、ＦＴシステム１において、他のノードに比べてメッセージパス情報の通知が遅いノードが存在し、かつ、ノードの離脱が起こりやすい構成である場合に、特に有効である。

【0156】

（７）出力処理部３３
以下では、出力処理部３３による処理について詳しく説明する。

【0157】

出力処理部３３は、各タスク２０の処理結果として外部出力要求を受け取り、所定のポリシーに従って外部出力する内容を決定し、決定した内容を外部（クライアント等の端末３）に送信する。

【0158】

これまで述べてきたように、本実施形態において各ノード１０のタスク群は、決定論的に振る舞うことが保証される。したがって、あるタスク２０に着目したとき、基本的にどのノード１０からも同じ内容の外部出力要求が、同じ順で送信される。

【0159】

一方、異なるタスク２０からの外部出力要求については、その要求順序はノード間で一致する補償はなく、実際に外部出力する順序も決定論的に決まらない（図２５（Ａ）参照）。しかし、一般的にはこれらの外部出力内容は互いに独立しており、外部出力の順序はシステムとしての結果に影響を与えないと想定される。もし、異なるタスク２０からの外部出力要求についてその順序性が重要である場合は、それぞれの外部出力内容を中継する共通のタスク（図２５（Ｂ）のタスクＣ）を置くことにより、出力順をノード間で一致化させることが可能である（図２５（Ｂ）参照）。

【0160】

図２５は、外部出力の順序保証を説明するイメージ図である。図２５（Ａ），（Ｂ）では何れも、異なるタスク２０Ａ，２０Ｂ（タスクＡ，Ｂ）からの外部出力要求が外部出力３９に送信される。外部出力３９は出力処理部３３と読み替えることができる。

【0161】

図２５（Ａ）の構成では、タスクＡから外部出力３９に対して「Ａ→外 ＃２」，「Ａ→外 ＃３」の外部出力要求のメッセージ１０１Ａが送信され、タスクＢから外部出力３９に対して「Ｂ→外 ＃４」の外部出力要求のメッセージ１０１Ｂが送信される。ここで、同一のタスクＡからの外部出力要求については、「Ａ→外 ＃２」の後に「Ａ→外 ＃３」が外部出力されることは保証される。一方、異なるタスクＡ，Ｂからの外部出力要求については、「Ａ→外 ＃２」と「Ｂ→外 ＃４」の何れが先に外部出力されるかの保証はなく、外部出力３９（出力処理部３３）に到着する順序もノード間で異なる場合がある。

【0162】

図２５（Ｂ）の構成は、図２５（Ａ）の構成に、それぞれの外部出力内容を集約して中継する共通のタスクＣを置いたものである。前述した通り、異なるタスクＡ，Ｂからの外部出力要求をタスクＣが受け取ることにより、タスクＣから外部出力３９（出力処理部３３）への外部出力の出力順をノード間で一致化させることができる。

【0163】

なお、出力処理部３３が外部出力する内容を決定する際に従う「所定のポリシー」は、例えば、先着優先のポリシーや多数決のポリシーが考えられる。

【0164】

先着優先のポリシーでは、各複製ノード（各ノード１０）から届いた外部出力要求のうち、最初に届いたものを外部出力し、残りは破棄する。多数決のポリシーでは、各複製ノード（各ノード１０）から届いた同一と考えられる外部出力要求に対して多数決を実施し、確からしい内容を選択して外部出力し、残りは破棄する。

【0165】

また、本実施形態のＦＴシステム１では、ノード１０における処理結果を外部装置（例えば端末３）に出力するために、専用の外部出力装置を備えるようにしてもよいが、以下の図２６に示すように構成することで、専用の外部出力装置がなくても各ノード１０の外部出力を調整して外部装置に出力することができる。

【0166】

図２６は、複数のノードからの外部出力を調整して出力する構成を説明するイメージ図である。図２６において、各ノードのタスクＡは、外部出力要求を送信する際に、各ノードの外部出力３９（出力処理部３３）にブロードキャストする。そして、外部出力３９（出力処理部３３）は、各ノードのタスクＡから受信した外部出力要求の内容を比較し、例えば多数決によって、正しいと判定されるものを外部装置（端末３）に送信する。図２６の場合は拡大図に示したように、ノード１及びノード２からの外部出力要求の内容が「α」であり、多数派となることから、「α」が外部出力される。

【0167】

また、図２６において、外部出力と３９と外部装置（端末３）との間の通信に、冪等なメッセージングプロトコルを用いるようにすれば、重複送信されたメッセージは外部装置側で破棄することができる。例えばセッション単位で送信メッセージに通番を付与し、受信側で通番順に１つずつ取り込むようにする。こうすることで、外部送信の前にノードが障害停止した場合であっても、外部装置は滞りなく処理結果を受信することができる。

【符号の説明】

【0168】

１ フォールトトレラント（ＦＴ）システム
２ 通信ネットワーク
３ 端末
１０ ノード
１０Ａ リーダノード（リーダ）
１０Ｂ，１０Ｃ フォロワノード（フォロワ）
２０ タスク
２１ ステート（ローカルステート）
３０ イベント処理基盤
３１ 入力処理部
３２ メッセージ処理部
３３ 出力処理部
３４ イベントログ
３５ メッセージパス管理テーブル
３６ メッセージ待機キュー
３８ 外部入力
３９ 外部出力

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】