JP4916567B2 - 分散コンピューティングシステムの処理方法 - Google Patents

Description

本発明は、分散コンピューティングシステムの処理方法に関する。

昨今、リソースの効率的利用等を目的とした分散コンピューティングがクラウドと呼ばれて注目され、各種のサービスが提供されている。分散コンピューティングでは、セルを構成する複数のコンピューティングデバイスがクライアントから指示されたタスクを協働して行うため、コンピューティングデバイス間で合意形成することが必要であり、このような合意形成のアルゴリズムとして、例えば特許文献１乃至特許文献３に記載のように、Paxosアルゴリズムが知られている。

Paxosアルゴリズムは、セルを構成するサーバがリーダ又はエージェントとなって、分散コンピューティングシステムが所定のコマンドを実行する前に、セルを構成する過半数以上のサーバがそのコマンドを実行することに対して合意するか否かを諮り、合意が形成されれば実行を開始するコンセンサスアルゴリズムである。このようなアルゴリズムにより、コンピューティングデバイス間の同期を簡易に図ることができ、高可用性を実現することができる。

具体的には、Paxosアルゴリズム（Simple Paxos）は、クライアントからの要求を受け付けたリーダが、Paxos合意の内容を示す提案番号であるラウンド値を他のエージェントとなるサーバに送る［ラウンド値の提案］。
エージェントは自らが所持するラウンド値とリーダから受信したラウンド値とを比較し、自らが所持するラウンド値の方が大きければリーダに対して拒否信号を返し、そうでなければ送られた提案を受理し了承信号を返す［了承］。
リーダは、了承信号を受信したエージェントが全エージェントの過半数マイナス１以上である場合には（自身は合意しているため）、エージェントから返された提案があればその中から所定の一つを選び、当該提案がなければクライアントからの提案を選び他のエージェントにラウンド値を付して提案を送る。エージェントは自らが所持するラウンド値とリーダから受信したラウンド値とを比較し、自らが所持するラウンド値の方が大きければリーダに対して拒否信号を返し、そうでなければ送られた提案を受理し受諾信号を返す［受諾］。
リーダは、受諾信号を受信したエージェントが全エージェントの過半数マイナス１以上である場合には（自身は合意しているため）、合意成立と決定する［合意成立］（この決定は覆らないことがPaxosアルゴリズムにより保証されている）。
その後、リーダは、インスタンスの実行指示を行い、合意形成されたインスタンスの実行に移行する［インスタンス実行］。

その後、継続的にインスタンスが実行されることになるが、その際には、再び、ラウンド値の提案、了承、受諾、合意成立（以下、「ラウンド獲得」という。）及びインスタンスの実行といった経過を辿ることになる。そのため、この方法では、各インスタンスで、毎回ラウンド獲得をする一連の処理を行わなければならず、非常に非効率的である。

そこで、上記問題点を解決するために、ラウンド値の合意成立が終了した後は、ラウンド獲得の合意がなされたものとして、インスタンスの合意形成及び実行に移行するMulti-Paxos方式が提案された。この方式によれば、一旦ラウンド値の提案から合意成立という経緯を経た後は、これらのステップが不必要となるという点で有利となる。

特開２００５−１９６７６３号公報 特開２００６−００４４３３号公報 特開２００６−１５５６１４号公報

しかし、Multi−Paxos方式においても、複数のインスタンスを処理するにあたり、個々のインスタンスの内容に対しては、一つのインスタンスごとに合意形成を行いながら実行対象のインスタンスを逐次実行しなければならなかった。そのため、従来の方法と比べても、ラウンド獲得の処理を省略する以上の高速化は期待することができないという問題点を有していた。

本発明は、上記の課題を解決するためになされたものであり、複数のインスタンスの処理の多重化を行い、並列処理を可能とした分散コンピューティングシステムの処理方法を提供することを目的としている。

上記課題を解決するために、本発明の分散コンピューティングシステムの処理方法は、セルを構成する複数のコンピューティングデバイスが、一部がリーダとなり他がエージェントとなり、Paxosアルゴリズムにより合意を形成することにより、上記複数のコンピューティングデバイスが実行すべき複数のインスタンスから形成されるインスタンス群を決定し、予め定められた実行順序で上記インスタンス群を実行する分散コンピューティングシステムにおいて、上記リーダが、上記各エージェントに対して、上記実行すべきインスタンス群の内容を示す提案番号であるラウンド値及び所定数毎にグルーピングされている上記インスタンス群の識別情報（メタデータを含む）を含むラウンド提案信号を送信するラウンド提案信号送信ステップと、上記各エージェントは受信した上記ラウンド値と、自らが保有しているラウンド値とを比較し、上記受信したラウンド値が上記自らが保有しているラウンド値以上の場合には、上記リーダに対して上記ラウンド値を受け入れることを示すラウンド了承信号を送信するラウンド了承信号送信ステップと、上記リーダは、上記セルを構成する複数の上記エージェントの過半数から１を減じた数以上から上記ラウンド了承信号を受信したか否かのラウンド了承信号受信条件の成否を判定するラウンド獲得判定ステップと、上記ラウンド了承信号受信条件を満たした場合には、上記各エージェントに対して、上記ラウンド値及び上記インスタンス群のうちの対象となるインスタンスの識別情報と関連づけられており、上記インスタンスの実行に必要である実体データを含むインスタンス提案信号を、所望の順序で連続的に送信するインスタンス提案信号送信ステップと、上記インスタンス提案信号を受信した上記各エージェントが、上記各インスタンスのラウンド値と自らが保有しているラウンド値を比較し、受信した上記ラウンド値が上記自らが保有しているラウンド値以上のときには、上記リーダに対して、上記対象となるインスタンスの実行を受け入れることを示すインスタンス了承信号を送信するインスタンス了承信号送信ステップと、上記リーダが、上記セルを構成する複数の上記エージェントの過半数から１を減じた数以上から上記インスタンス了承信号を受信したか否かのインスタンス了承信号受信条件の成否を判定するインスタンス合意判定ステップと、上記インスタンス了承信号受信条件を満たした場合には、上記各エージェントに対して、上記予め定められた実行順序で、上記所定数に至るまで上記対象となるインスタンスの実行を命令するインスタンス実行指示信号を送信するインスタンス実行指示信号送信ステップと、上記インスタンス実行指示信号を受信したエージェントは、対象となる上記インスタンスを実行するインスタンス実行ステップと、を含み、上記インスタンス提案信号送信ステップにおいて、上記リーダは、上記インスタンス了承信号受信条件を満たしたことを確認することなく、他のインスタンス提案信号を送信することを特徴としている。

本発明において、上記ラウンド提案信号における上記インスタンス群の識別情報は、メタデータから形成されていることとすれば、通信容量の制約がある通信方式であっても、Paxosアルゴリズムによる合意成立を迅速に行うことが可能となるため好適である。

ここで、ラウンド値とは、リーダが各エージェントに対して提示する、処理を行うインスタンス群の内容を示す提案番号のことをいう。このラウンド値は、大きいほど、その強度は強く、既に行ったラウンド値より小さい提案番号の処理を行うことができないことが定められている。
また、インスタンスとは、所定のタスクを実行するためのコマンドを含む処理実体のことをいう。

対象となるインスタンスを実行するにあたっては、上記インスタンス了承信号受信条件を満たしていることが必要となる。ところで、本発明では、予め定められた実行順序でインスタンスが実行されることが前提となるが、リーダは実行対象のインスタンスがインスタンス了承信号受信条件を満たしたことを確認することなく、エージェントに対して他のインスタンス提案信号を送信する処理（いわゆる、突き放し制御）を行っている。このように、本発明によれば、リーダがエージェントに対して、他の通番のインスタンスに関するインスタンス提案信号を連続的に送信するという突き放し制御を行うことで、インスタンス処理の多重化を図り、その並列処理を可能とすることができる。したがって、Paxosアルゴリズムによるインスタンス実行の合意成立に要する待ち時間を極力少なくすることにより、複数のインスタンスを迅速に実行することができる。

本発明によれば、複数のインスタンスの処理の多重化を行い、並列処理を可能とすることにより、分散コンピューティングシステムの高速な処理を行うことができる。

本発明の対象とする分散コンピューティングシステムを示す説明図である。 本発明の対象とする分散コンピューティングシステムの概略構成図である。 本発明の分散コンピューティングの概略処理方法を示すフロー図である。 本発明の分散コンピューティングの詳細処理方法を示すフロー図である。 図４に続く本発明の散コンピューティングの詳細処理方法を示すフロー図である。 （ａ）ラウンド提案信号の説明図である。 （ｂ）ラウンド了承信号の説明図である。（ｃ）ラウンド未了承信号の説明図である。 （ａ）決定データ要求信号の説明図である。 （ｂ）決定データ応答信号の説明図である。 （ａ）インスタンス提案信号の説明図である。 （ｂ）インスタンス提案代行信号の説明図である。 （ａ）インスタンス了承信号の説明図である。 （ｂ）インスタンス未了承信号の説明図である。（ｃ）インスタンス実行指示信号の説明図である。

本発明を実施するための一形態について、図面を参照して詳細に説明する。

〔分散コンピューティングシステムＳの全体構成〕
図１及び図２に示すように、本発明の分散コンピューティングシステムＳ（以下、「本システム」という。）は、複数台のサーバ（コンピューティングデバイス）がインターネット等のネットワークＮ及びＬＡＮ（符号Ｌ）を介して接続されていることにより構成されている。以下、説明の便宜上、１台のリーダサーバＥ（以下、「リーダ」という。）と、４台のエージェントサーバＡ〜Ｄ（以下、「エージェント」という。）（なお、以下、５台のサーバを総称して「各サーバ」という場合がある。）を例として説明する。

本システムＳは、セルＰを構成する複数のサーバの中の一部（通常は１台）がリーダＥとなり、他のサーバがエージェントＡ〜Ｄとなり、Paxosアルゴリズムにより合意を形成して、実行すべき複数のインスタンス（以下、「インスタンス群」という）を決定し、当該インスタンス群を連続的に実行するものである。
上記リーダＥは、予め所定の方法（例えば、本システムＳに加入した時刻が最も古いサーバをリーダとする、いわゆる最長老方式など）により、決定されることになる。

但し、上記各サーバＡ〜Ｅは、名称を変えて説明しているが、その構成は同様であり、それぞれがクライアントＫの要求に応じて他のサーバの役割を担うことができる装置となっている。そのため、同一の構成要素を説明するに際し、当該構成要素を総称する場合には同一の符号を付すことを原則とするが、サーバの違いによる構成要素の違いを示す必要がある際には当該符号の末尾にさらに、Ａ〜Ｅを付して区別するものとする。

上記の通り、本システムＳでは、各サーバＡ〜Ｅが、それらのＩＰアドレスを把握するクライアントＫにネットワークＮを介して接続されている。各サーバＡ〜Ｅは、クライアントＫからの指示を受け、操作実行手段（図示せず）を介して、演算処理等のインスタンスを実行することにより所望のタスクを行うことができるようになっている。

上記インスタンスを実行するためのアプリケーションプログラム及びインスタンスを分散処理するための分散コンピューティング用のプログラムは、ここでは各サーバＡ〜Ｅのそれぞれに予めインストールされている。
各サーバＡ〜Ｅは、それぞれ汎用コンピュータであり、ＣＰＵ（図示せず）を備えているが、便宜上、そのＣＰＵ、記憶装置等のプロセッサ能力、ストレージ能力を合意形成部４Ａ〜４Ｅと実行部５Ａ〜５Ｅに分けて説明する（図２）。

合意形成部４Ａ〜４Ｅは、セルＰの内部で既知であるPaxosにより合意を形成するためのPaxos装置を構成している。この合意形成部４Ａ〜４Ｅは、本システムＳとして、あるインスタンスを実行する前に、定足数以上のサーバがそのインスタンスを実行することに対して合意するか否かをリーダＥが各エージェントＡ〜Ｄに諮り、合意が形成されれば実行を開始することを可能とすることにより、各サーバＡ〜Ｅ間の同期を実現することができる装置となっている（後述する）。
また、上記分散コンピューティング用プログラムに従って、各合意形成部４Ａ〜４Ｅ同士が所定の帯域内の通信方式（例えばＵＤＰ）によりメタデータを値渡しすることができるようになっている。

なお、合意形成部４Ａ〜４Ｅでは、あくまで、インスタンスを実行するか否かの合意を図るものであり、実行すべきインスタンスはアプリケーションプログラムで決定されることになる。

また、実行部５Ａ〜５Ｅは、上記合意形成部４Ａ〜４Ｅにより決定されたインスタンスを上記アプリケーションプログラムに適用することにより、タスクを実行することができるようになっている。

〔分散コンピューティングシステムＳの処理方法〕
本システムＳでは、複数のインスタンスを実行するにあたり、リーダ交替が生じない限りおいて、一度のラウンドの獲得、各インスタンス合意形成及び各インスタンスの実行という３段階の処理を行うことを特徴としている。

＜ラウンドの獲得＞
まず、リーダＥは各インスタンスを実行する前にラウンドの獲得を行うことになる。この処理は、ラウンド提案信号送信ステップ（ＳＴ１）、ラウンド了承信号送信ステップ（ＳＴ２）及びラウンド獲得判定ステップ（ＳＴ３）から構成されている（図３）。

ラウンドの獲得（以下、「ラウンド獲得」という。）とは、リーダＥが各エージェントＡ〜Ｄに対して、処理を行うインスタンス群の内容を示す提案番号であるラウンド値を含む下記ラウンド提案信号を送信し、各エージェントＡ〜Ｄのうちの「過半数−１」のエージェントから当該インスタンス群の内容の実行の合意を取り付けることをいう。
このラウンド値は、予め割り当てられているリーダＥの装置番号と、通番から構成されており、本システムＳの全体で一意に定められている。このラウンド値の大小は、まず通番を比較することにより判断されることになる。このとき、通番の値が大きいほどその強度が強くなるように設定されている。そして、当該通番が同じ場合には、装置番号が小さいほどその強度が強くなるように設定されている。
一方、各サーバＡ〜Ｅが、ラウンド値の提案を行う（以下、「ラウンド値を払い出す」とも称する。）場合には、自身が保有しているラウンド値（以下、「保有ラウンド値」という。）の通番に１を加えるとともに、自身の装置番号をその装置番号とする。
これにより、各サーバＡ〜Ｅは、本システムＳの全体として、一意のラウンド値を提案することができ、以前に行われたインスタンス群と同一の処理を行うことがないようになっている。

（１）ラウンド提案信号送信ステップ（ＳＴ１）
図４に示すように、本ステップは、リーダＥが、各エージェントＡ〜Ｄに対してラウンド値と、当該ラウンド値に対応し、合意を形成すべき実行内容を示す所定数毎（本実施形態ではＢ個）にグルーピングされているインスタンス群の識別情報を含むラウンド提案信号を、当該各エージェントＡ〜Ｄに対して送信する処理を行うステップである（Ｓ３０）。

本システムＳでは、リーダＥが自己の提案するインスタンス群のデータを各エージェントＡ〜Ｄに対して送信し、各エージェントＡ〜Ｄは、そのインスタンス群のデータと、自己のインスタンスの実行状態のデータを比較して、その後の処理を決定することになる。そのため、ラウンド提案信号には、当該Ｂ個のインスタンスの識別情報を含まなければならない。しかし、通信容量等の制約がある場合が存在するため、インスタンス群の識別情報として、対応するインスタンスを実行するために必要となる後記提案値のメタデータ（以下、「提案値メタデータ」という。）のみを送信している。
なお、後記するように、インスタンスの実行にあたっては、提案値の実体データ（以下、「提案値実体データ」という。）が必要となるが、当該提案値実体データは、各インスタンスの識別情報と関連づけられているため、データ処理上における問題が生じることはない。

上記ラウンド提案信号は、データ種別を区別するための識別情報であるラウンド提案（略称Collect）タイプ、予め割り当てられている送信元サーバ装置番号（リーダＥの装置番号）及び送信先サーバ装置番号（エージェントＡ〜Ｄの装置番号）、ラウンド値、ブロック番号、１つのブロックを構成するＢ個のインスタンスの識別情報（インスタンス通番、フラグ情報、提案ラウンド値、提案値メタデータ）を含むデータから形成されている（図６（ａ））。

ここで、提案値メタデータは、対象インスタンスを実行するための提案値実体データを当初有していたサーバ装置番号と当該提案値実体データを現在所持している提案サーバ装置番号から形成されている。
また、提案ラウンド値とは、送信時にリーダＥが保有し、各エージェントＡ〜Ｄに対して払い出した（送信した）ラウンド値である。

フラグ情報とは、各インスタンスの処理状態を示すデータであり、決定済（後記インスタンス実行指示信号の送信がなされている状態、すなわちインスタンスの合意形成がなされている状態）、提案中（後記インスタンス提案信号の送信がなされている状態）、提案なし（後記インスタンス提案信号の送信がなされていない状態）の３つの状態を示すものである。

また、インスタンス通番とは、各インスタンスに付されたシーケンス番号（順序番号）である。
ブロック番号とは、各ブロックに付されたシーケンス番号（順序番号）である。

（２）ラウンド了承信号送信ステップ（ＳＴ２）
本ステップは、当該ラウンド提案信号を受信した各エージェントＡ〜Ｄが、受信したラウンド値（以下、「受信ラウンド値」という。）と、自らが保有しているラウンド値（以下、「保有ラウンド値」という。）とを比較し（Ｓ３１）、受信ラウンド値が、保有ラウンド値以上の場合（Ｓ３１のＹｅｓ）には、リーダＥに対して当該受信ラウンド値を受け入れることを示すラウンド了承信号を送信する（Ｓ３２）処理を行うステップである。このとき、受信ラウンド値が保有ラウンド値以上であるため、各エージェントＡ〜Ｄは保有ラウンド値を受信ラウンド値に更新することになる。

一方、上記条件を満たさない（受信ラウンド値が保有ラウンド値より小さい）場合（Ｓ３１のＮｏ）には、エージェントＡ〜ＤはリーダＥに対してラウンド未了承信号を送信する（Ｓ３３）。

なお、ラウンド了承信号は、データ種別を区別するための識別情報であるラウンド了承タイプ（略称Last）、送信元サーバ装置番号（エージェントＡ〜Ｄの装置番号）及び送信先サーバ装置番号（リーダＥの装置番号）、ラウンド値、ブロック番号、Ｂ個のインスタンスの識別情報（インスタンス通番、フラグ情報、提案ラウンド値、提案値メタデータ）から形成されている（図６（ｂ））。
また、ラウンド未了承信号は、データ種別を区別するための識別情報であるラウンド未了承タイプ（略称OldRound1）、送信元サーバ装置番号（エージェンＡ〜Ｄの装置番号）及び送信先サーバ装置番号（リーダＥの装置番号）、ラウンド値を含むデータから形成されている（図６（ｃ））。

さらに、本ステップでは、エージェントＡ〜Ｄは、リーダ交替直前におけるリーダＥにおける各インスタンスの状態と、自らのインスタンスの状態とを比較して、下記の処理を行うことになる。すなわち、リーダＥにおける各インスタンスの状態は、ラウンド提案信号におけるフラグ情報（以下、単に「フラグ情報」という。）によって区別されることになるが、エージェントＡ〜Ｄの各インスタンス（以下、「エージェントインスタンス」という。）の状態に応じて、下記の処理を行う（表１）。
なお、上記処理は、リーダＥが各エージェントＡ〜Ｄからインスタンスの実行状態のデータを収集し、前のラウンドの獲得時に未処理のインスタンスが存在する場合には、今回のラウンド獲得時にそのインスタンスを実行するために行うものである。

まず、フラグ情報が「決定済」であり、エージェントインスタンスが「決定済」であるときは、既に対応するインスタンスは前のラウンド獲得時にその実行が約束されているため、エージェントＡ〜Ｄはラウンド提案信号のコピーを作成し、その内容をラウンド承諾信号としてリーダＥに対して送信することになる。

フラグ情報が「決定済」であり、エージェントインスタンスが、「提案中又は提案なし」であるときは、エージェントＡ〜Ｄは、ラウンド提案信号のコピーを作成し（但し、送信元サーバ装置番号及び送信先サーバ装置番号は除く、以下同様）、その内容をラウンド承諾信号として、リーダＥに対して送信するとともに、リーダＥに対して決定データ要求信号を送信することになる。
この状態は、既にインスタンスの実行合意（後記）がなされているが、エージェントＡ〜Ｄは実行するインスタンスの合意形成に参加していない状態であるため、リーダＥに対して、対象インスタンスを実行するために必要となるデータを含む決定データの送信を要求する（決定データ要求信号を送信する）ものである。
なお、決定データ要求信号は、決定データ要求タイプ、送信元サーバ装置番号、送信先サーバ装置番号、インスタンス通番から形成されている。（図７（ａ））

フラグ情報が「提案中又は提案なし」であり、エージェントインスタンスが「決定済」であるときは、エージェントＡ〜Ｄは、ラウンド提案信号の内容（提案ラウンド値及び提案値メタデータ）、を修正して、ラウンド承諾信号としてリーダＥに対して送信するとともに、リーダＥに対して決定データ応答信号を送信することになる。
この状態は、リーダ交替時に生じうるものであり、リーダＥが対象インスタンスを実行するために、エージェントＡ〜ＤがリーダＥに対して、そのインスタンスの実行に必要となるデータを含む決定データ応答信号を、送信するものである。
なお、決定データ応答信号は、決定データ応答タイプ、送信元サーバ装置番号、送信先サーバ装置番号、インスタンス通番、提案値メタデータ、提案値実体データから形成されている（図７（ｂ））。

フラグ情報が「提案中」であり、エージェントインスタンスが「提案なし」であるときは、当該時点において、対応するインスタンスの合意を形成中であるため、エージェントＡ〜Ｄはラウンド提案信号のコピーを作成し、その内容をラウンド承諾信号として、リーダＥに対して送信することになる。

フラグ情報が「提案中」であり、エージェントインスタンスが「提案中」であるときは、下記の通常の処理方法にしたがって、エージェントＡ〜Ｄは受信ラウンド値が保有ラウンド値以上の場合に、ラウンド提案信号の内容を修正し、ラウンド了承信号を作成して、リーダＥに対して送信する（受信ラウンド値が保有ラウンド値未満の場合には、ラウンド未了信号を送信する）ことになる。

フラグ情報が「提案なし」であり、エージェントインスタンスが「提案中」であるときは、エージェントＡ〜Ｄが認識しており、リーダＥが処理していないインスタンスが存在していることになる。そのため、エージェントＡ〜Ｄは、当該インスタンスの情報を含むようにラウンド提案信号の内容（提案ラウンド値及び提案値メタデータ）を修正して、ラウンド承諾信号としてリーダＥに対して送信することになる。

（３）ラウンド獲得判定ステップ（ＳＴ３）
本ステップは、リーダＥが、セルＰを構成するエージェントＡ〜Ｄの過半数から１を減じた数以上からラウンド了承信号を受信したか否かのラウンド了承信号受信条件の成否を判定する処理を行う（Ｓ３４）ステップである。
上記処理を行う際に、リーダＥは、ラウンド了承信号に対応する提案ラウンド値を自ら各エージェントＡ〜Ｄに送信しているため、当然に提案ラウンド値を受け入れることになる。したがって、自身とラウンド了承信号を受信したエージェントの数の合計が、セルＰを構成するサーバＡ〜Ｅの過半数（本実施の形態の場合は、５台中３台。以下、この過半数を「定足数」という。）であることを、Paxosアルゴリズムによるラウンド獲得の合意（以下、「ラウンド獲得合意」という。）の条件としたものである。
なお、セルＰを構成するサーバとは、通常は、本システムＳの初期動作時におけるリーダＥと各エージェントＡ〜Ｄをいう。

本ステップでは、上記ラウンド了承信号受信条件を満たしていると判定された場合（Ｓ３４のＹｅｓ）には、インスタンス提案信号送信ステップ（ＳＴ４）に移行することになる。
一方、リーダＥが上記定足数のサーバからラウンド了承信号を受信していない場合（Ｓ３４のＮｏ）には、当該ラウンド値に基づくインスタンス群を実行することに関するラウンド獲得合意が形成されないことになる。このとき、リーダＥであることが維持されている場合には、一定時間経過後にラウンド値を大きい値に変更し、各エージェントＡ〜Ｄに対してラウンド提案信号を再送信し（Ｓ３０）、再度、ラウンド了承信号送信ステップ（ＳＴ２）を実行することになる。なお、リーダＥであることが維持されていない場合には、他のリーダの配下になる。

＜インスタンスの合意形成＞
以降のステップは、ラウンド獲得合意が形成されたことにより、実行対象の各インスタンスの合意形成を行うためのステップである。このとき、各インスタンスの実行にあたっては、Paxosアルゴリズムによる当該インスタンスに関する実行合意が形成される必要がある。

以下のステップは、インスタンス提案信号送信ステップ（ＳＴ４）、インスタンス了承信号送信ステップ（ＳＴ５）、インスタンス合意判定ステップ（ＳＴ６）、インスタンス実行指示信号送信ステップ（ＳＴ７）の各ステップから構成されている（図３）。

（４）インスタンス提案信号送信ステップ（ＳＴ４）
本ステップは、ラウンド獲得判定ステップ（ＳＴ３）において、リーダＥが定足数のサーバから当該ラウンド了承信号を受信している場合（Ｓ３４のＹｅｓ）に、当該ラウンド獲得合意が形成されたものと判断し、リーダＥが各エージェントＡ〜Ｄに対して、当該ラウンド値及び所望の順序で選択された実行対象となるインスタンスの識別情報を含むインスタンス提案信号を送信する（Ｓ３５）処理を行うステップである。
本ステップでは、ラウンド了承信号送信ステップ（ＳＴ２）において説明した、リーダＥとエージェントＡ〜Ｄのインスタンスの処理状態に応じて、その処理が異なることになる。

まず、リーダＥのフラグ情報が「決定済」であり、エージェントインスタンスが「決定済」であるときは、既に対応するインスタンスは前のラウンド獲得時にその実行が約束されているため、以下のステップは不必要となる。

続いて、リーダＥのフラグ情報が「決定済」であり、エージェントインスタンスが「提案中又は提案なし」であるときは、エージェントＡ〜Ｄは、リーダＥに対して、決定データ要求信号を送信することになる。決定データ要求信号を受信したリーダＥは、要求をしたエージェントＡ〜Ｄに対して決定データを送信し、決定データを受信したエージェントＡ〜Ｄは、当該決定データを用いてインスタンスを実行することになる（この場合には、本システムＳにおいて既にインスタンスに関しては合意形成がなされているため、以下のステップは必要ない）。

フラグ情報が「提案中又は提案なし」であり、エージェントインスタンスが「決定済」であるときは、エージェントＡ〜ＤがリーダＥに対して、そのインスタンスを実行するために必要となるデータを含む決定データ応答信号を送信する。決定データ応答信号を受信したリーダＥは、当該データを用いてインスタンスを実行することになる（この場合には、本システムＳにおいて既にインスタンスに関しては合意形成がなされているため、以下のステップは必要ない）。

フラグ情報が「提案中」（「提案なし」の場合も含む）、又はエージェントインスタンスが「提案中」（「提案なし」の場合も含む）である場合（但し、両者が「提案なし」の場合はない）には、リーダ交替前のインスタンスが提案されている状態である。そのため、これらのインスタンスを優先して処理するために、リーダＥは、当該インスタンスに関し、各エージェントＡ〜Ｄに対してインスタンス提案信号を送信する。
そして、それらのインスタンスの処理が終了した後に、リーダＥは、リーダ交替後に指示されたインスタンスに対して、各エージェントＡ〜Ｄに対してインスタンス提案信号を送信することになる。

本ステップでは、上記インスタンス提案信号を送信するに当たり、リーダＥは、後記インスタンス了承信号受信条件の成立を待つことなく、各エージェントＡ〜Ｅに対して、インスタンス通番の順序（昇順）にしたがって連続的にインスタンス提案信号を送信するという、突き放し制御を実行することになる。

なお、インスタンス提案信号は、データ種別を区別するための識別情報であるインスタンス提案タイプ（略称Begin）、インスタンス了承信号を返信すべき返信先サーバ装置番号及び送信先サーバ装置番号（リーダＥの装置番号）、ラウンド値、実行対象であるインスタンス情報（インスタンス通番、提案値メタデータ、提案値実体データ）を含むデータから形成されている（図８（ａ））。
ここで、提案値実体データとは、対象となるインスタンスを実行するために必要となる実際のデータであり、インスタンス通番により提案値メタデータと対応づけられている。

ところで、リーダＥは提案値実体データを有していることが一般的である。しかし、処理の間にリーダ交替が生じた場合には、新たなリーダが提案値実体データを保有していない場合が生じうる。その場合には、新たなリーダは、提案値実体データを保有しているエージェントに対して、インスタンス提案代行信号を送信し、そのエージェントから提案値実体データを送信すべき他のエージェントに提案値実体データを送信させることになる。
なお、インスタンス提案代行信号は、データ種別を区別するための識別情報であるインスタンス提案代行タイプ（略称Beginリダイレクト）、送信元サーバ装置番号、送信先サーバ装置番号、提案値実体データを取得した場合にインスタンス了承信号を返信すべき返信先サーバ装置番号（通常はリーダＥの装置番号）、ラウンド値、実行対象であるインスタンス通番を含むデータから形成されている（図８（ｂ））。

（５）インスタンス了承信号送信ステップ（ＳＴ５）
本ステップは、各エージェントＡ〜Ｄにおいて、自身が受信した対象となる各インスタンスのラウンド値（受信ラウンド値）と、保有ラウンド値とを比較し（Ｓ３６）、当該受信ラウンド値が保有ラウンド値以上の場合（Ｓ３６のＹｅｓ）には、当該各エージェンＡ〜Ｄが、リーダＥに対してインスタンス了承信号を送信する（Ｓ３７）処理を行うステップである。

一方、上記受信ラウンド値が、保有ラウンド値より小さい場合（Ｓ３６のＮｏ）には、エージェントＡ〜ＤはリーダＥに対してインスタンス未了承信号を送信する（Ｓ３８）。インスタンス未了承信号を受信したリーダＥは、リーダＥであることが維持されている場合には、一定時間経過後に保有ラウンド値を当初のラウンド値よりも大きい値に変更し、各エージェントＡ〜Ｄに対してラウンド提案信号を再送信し（Ｓ３０）、再度、ラウンド了承信号送信ステップＳＴ２を実行することになる。なお、リーダＥであることが維持されていない場合には、他のリーダの配下になる。

インスタンス了承信号は、データ種別を区別するための識別情報であるインスタンス了承タイプ（略称Accept）、送信元サーバ装置番号（エージェントＡ〜Ｄの装置番号）及び送信先サーバ装置番号（リーダＥの装置番号）、実行対象のインスタンス通番を含むデータから形成されている（図９（ａ））。
また、インスタンス未了承信号は、データ種別を区別するための識別情報であるラウンド未了承タイプ（略称OldRound2）、送信元サーバ装置番号（エージェントＡ〜Ｄの装置番号）及び送信先サーバ装置番号（リーダＥの装置番号）、ラウンド値を含むデータから形成されている（図９（ｂ））。

（６）インスタンス合意判定ステップ（ＳＴ６）
図５に示すように、本ステップは、リーダＥが、セルＰを構成するエージェントＡ〜Ｄの過半数から１を減じた数以上からインスタンス了承信号を受信したか否かのインスタンス了承信号受信条件の成否を判定する（Ｓ３９）処理を行う。
リーダＥは、インスタンス了承信号に対応するインスタンスを自ら各エージェントに送信しているため、当然に当該インスタンスの実行を了承する（以下、「インスタンスの実行合意」という。）ことになる。したがって、自身とインスタンス了承信号を受信したエージェントの数の合計が、セルを構成するサーバの過半数であることを、Paxosアルゴリズムによるインスタンスの実行合意の条件としたものである。

一方、上記インスタンス了承信号受信条件を満たしていない場合（Ｓ３９のＮｏ）には、対応するインスタンス通番のインスタンスの実行合意が形成されないことになる。したがって、リーダＥであることが維持されている場合には、一定時間経過後に保有ラウンド値を当初のラウンド値よりも大きい値に変更し、各エージェントＡ〜Ｄに対してラウンド提案信号を再送信し（Ｓ３０）、再度、ラウンド了承信号送信ステップ（ＳＴ２）を実行することになる（図５のＢ及び図４のＢ）。なお、リーダＥであることが維持されていない場合には、他のリーダの配下になる。

（７）インスタンス実行指示信号送信ステップ（ＳＴ７）
本ステップは、インスタンス了承信号受信条件を満たした場合（Ｓ３９のＹｅｓ）には、当該所定の通番のインスタンスを実行することに関して、インスタンスの実行合意が形成されたものと判断する。そして、リーダＥは、各エージェントＡ〜Ｄに対し、当該インスタンス了承信号を送信した所定の通番のインスタンスに関するインスタンス実行指示信号を送信する（Ｓ４０）処理を行う。この処理は、一つのブロックを構成する連続するＢ個の総てのインスタンスの合意形成がなされるまで続けられる（Ｓ４１）。

上記インスタンス実行指示信号は、データ種別を区別するための識別情報である実行指示タイプ（略称Success）、送信元サーバ装置番号（リーダＥの装置番号）及び送信先サーバ装置番号（エージェントＡ〜Ｄの装置番号）、実行対象であるインスタンス情報（インスタンス通番、提案値メタデータ、提案値実体データ）を含むデータから形成されている（図９（ｃ））。

その後、１ブロックを構成する総てのインスタンスの実行指示信号が送信された場合には、当該ブロックの処理が終了したとする（Ｓ４２）。そして、各サーバＡ〜Ｅは自身のブロックの更新を行い、再び、上記インスタンス提案信号送信ステップ（ＳＴ４）に戻り、上記と同様の処理を行うことになる。

＜インスタンス実行＞
（８）インスタンス実行ステップ（ＳＴ８）
本ステップは、リーダＥが上記インスタンス了承信号受信条件を満たしていると判断した場合（Ｓ３９のＹｅｓ）において、当該インスタンス了承信号受信条件の成立を実行契機として、自らは実行対象のインスタンス通番のインスタンスを、その通番に対して昇順に実行し、また、リーダＥから実行指示信号を受信したエージェントＡ〜Ｄは、当該インスタンス実行指示信号の受信を実行契機として、対象となるインスタンスをその通番に対して昇順に実行する（Ｓ４７）ステップである。

◎インスタンスの実行順序の昇順制御
本システムＳでは、上記の通り、インスタンスの実行にあたっては、連続するＢ個のインスタンスが通番に対して昇順に実行されるようにプログラミングされている。
しかし、上記の通り、リーダＥは、エージェントＡ〜Ｄから送信されるインスタンス了承信号受信条件の成立を待つことなく、インスタンス通番の順序にしたがって連続的に、インスタンス提案信号を送信している（突き放し制御）。このとき、エージェントの動作状況若しくは通信回線の状態によって、インスタンス通番の順序に応じたインスタンスについて、実行合意が形成されない場合がある。そのため、定足数のサーバから受信したインスタンス了承信号のインスタンス通番が、実行された最新のインスタンスの次のインスタンス（以下、「次実行予定インスタンス」という。）のインスタンス通番であるかを判別し（Ｓ４３）、当該条件を満たす場合（Ｓ４３のＹｅｓ）には、そのインスタンスを実行する（Ｓ４７）。

一方、定足数のサーバから受信したインスタンス了承信号のインスタンス通番が、次実行予定インスタンスのインスタンス通番でない（一致しない）場合（Ｓ４３のＮｏ）には、次実行予定インスタンスの合意形成がなされるまでの間、該当するインスタンスの実行を一時的に保留する（Ｓ４４）。各サーバＡ〜Ｅは、次実行予定インスタンスに関してインスタンス了承信号受信条件を満たす（インスタンス実行の合意形成がなされる）までインスタンスの実行を行わず、次実行予定インスタンスに関するインスタンス了承信号受信条件が成立したとき（リーダＥの場合）、又は、当該インスタンス実行指示信号を受信したとき（エージェントＡ〜Ｄ）に、初めてそのインスタンスを実行することになる。

このとき、インスタンスの実行が進行している状況において、既にインスタンス実行の合意形成がなされており、実行可能な多数のインスタンスが一時的に保留される事態が生じうる。そこで、保留されている実行可能インスタンスの中に、次実行予定インスタンスが存在するかを検索し（Ｓ４５）、次実行予定インスタンスが存在している場合（Ｓ４５のＹｅｓ）には、保留インスタンスであることを解除して（Ｓ４６）、当該インスタンスを実行する（Ｓ４７）。
一方、保留されている実行可能インスタンスの中に、次実行予定インスタンスが存在しない場合（Ｓ４５のＮｏ）には、上記インスタンスの処理を継続することになる（図５のＤ）。

なお、上記インスタンス実行指示信号に基づいて、実行対象であるインスタンスが実行されることは上記した通りである。各インスタンスには、インスタンス通番が付されており、インスタンス実行指示信号には当該インスタンスを実行するための実体データが含まれているため、当該実体データを用いて、実行対象であるインスタンス通番に対応するインスタンスを適用して、その処理を行うことになる。

〔作用・効果〕
本発明によれば、複数のインスタンスを実行するにあたり、リーダ交替が生じない限りおいて、一度のラウンド獲得が完了すれば、それ以降、各インスタンスの実行にあたっては、これらの処理を不要とすることができる。そのため、所与の実行順序で連続的にインスタンスの実行を行うことができることから、その処理の高速化を実現することが可能になる。

また、対象となるインスタンスを実行するにあたっては、インスタンス了承信号条件を満たしていることが必要となる。ところで、本発明では、予め定められた実行順序（本実施形態では、インスタンス通番が昇順となる順序）でインスタンスが実行されることが前提となるが、実行順序となるインスタンスがインスタンス了承信号条件を満たしたことを確認することなく、他のインスタンス提案信号を連続的に送信する突き放し制御を行っている。このように、Paxosアルゴリズムによる合意成立を前提とした状態で、突き放し制御を行っているため、インスタンス処理の多重化を図り、その並列処理を可能とすることができる。したがって、インスタンスの実行合意の形成に要する待ち時間を極力少なくすることにより、複数のインスタンスを迅速に実行することができる。

また、ラウンド獲得にあたり、ラウンド提案信号及びラウンド了承信号を構成するデータにおいて、実行すべきインスタンスの内容を特定するために必要なインスタンスの識別情報のデータとして、提案値メタデータを使用しているので、通信容量の制約がある通信方式であっても、Paxosアルゴリズムによる合意成立を迅速に行うことが可能となる。

以上、本発明について、好適な実施形態についての一例を説明したが、本発明は当該実施形態に限られず、本発明の趣旨を逸脱しない範囲で適宜設計変更が可能である。
上記実施形態では、本システムが５台のサーバから構成される場合を例として説明したが、複数台のコンピューティングデバイスであれば、その種類や数はこれに限られるものではない。また、複数台の情報処理装置は、インターネットやＬＡＮ以外にも、どのような接続手段により接続されているものであってもよい。

本発明は、Paxosアルゴリズムを用いた分散コンピューティングシステムの処理方法において、インスタンスの種類を問わずに広く利用することができる。

Ｓ 分散コンピューティングシステム
Ｋ クライアント
Ａ，Ｂ，Ｃ，Ｄ サーバ（エージェント）
Ｅ サーバ（リーダ）
Ｐ セル
４Ａ，４Ｂ，４Ｃ，４Ｄ，４Ｅ 合意形成部
５Ａ，５Ｂ，５Ｃ，５Ｄ，５Ｅ 実行部

Claims (2)

1. セルを構成する複数のコンピューティングデバイスが、一部がリーダとなり他がエージェントとなり、Paxosアルゴリズムにより合意を形成することにより、前記複数のコンピューティングデバイスが実行すべき複数のインスタンスから形成されるインスタンス群を決定し、予め定められた実行順序で前記インスタンス群を実行する分散コンピューティングシステムにおいて、
   前記リーダが、前記各エージェントに対して、前記実行すべきインスタンス群の内容を示す提案番号であるラウンド値及び所定数毎にグルーピングされている前記インスタンス群の識別情報を含むラウンド提案信号を送信するラウンド提案信号送信ステップと、
   前記各エージェントは受信した前記ラウンド値と、自らが保有しているラウンド値とを比較し、前記受信したラウンド値が前記自ら保有しているラウンド値以上の場合には、前記リーダに対して前記ラウンド値を受け入れることを示すラウンド了承信号を送信するラウンド了承信号送信ステップと、
   前記リーダは、前記セルを構成する複数の前記エージェントの過半数から１を減じた数以上から前記ラウンド了承信号を受信したか否かのラウンド了承信号受信条件の成否を判定するラウンド獲得判定ステップと、
   前記ラウンド了承信号受信条件を満たした場合には、前記各エージェントに対して、前記ラウンド値及び前記インスタンス群のうちの対象となるインスタンスの識別情報と関連づけられており、前記インスタンスの実行に必要である実体データを含むインスタンス提案信号を、所望の順序で連続的に送信するインスタンス提案信号送信ステップと、
   前記インスタンス提案信号を受信した前記各エージェントが、前記各インスタンスのラウンド値と自らが保有しているラウンド値を比較し、受信した前記ラウンド値が前記自ら保有しているラウンド値以上のときには、前記リーダに対して、前記対象となるインスタンスの実行を受け入れることを示すインスタンス了承信号を送信するインスタンス了承信号送信ステップと、
   前記リーダが、前記セルを構成する複数の前記エージェントの過半数から１を減じた数以上から前記インスタンス了承信号を受信したか否かのインスタンス了承信号受信条件の成否を判定するインスタンス合意判定ステップと、
   前記インスタンス了承信号受信条件を満たした場合には、前記各エージェントに対して前記予め定められた実行順序で、前記所定数に至るまで前記対象となるインスタンスの実行を命令するインスタンス実行指示信号を送信するインスタンス実行指示信号送信ステップと、
   前記インスタンス実行指示信号を受信したエージェントは、対象となる前記インスタンスを実行するインスタンス実行ステップと、
   を含み、
   前記インスタンス提案信号送信ステップにおいて、前記リーダは、前記インスタンス了承信号受信条件を満たしたことを確認することなく、他のインスタンス提案信号を送信する、
   ことを特徴とする分散コンピューティングシステムの処理方法。
2. 前記ラウンド提案信号における前記インスタンス群の識別情報は、メタデータから形成されていることを特徴とする請求項１に記載の分散コンピューティングシステムの処理方法。