(57)【要約】【課題】信号処理装置が、少ない信号量と処理量にてビザンチン障害耐性を得る。【解決手段】相互に通信可能に接続された複数台のサーバ２の３分の１を超える台数を占める代表装置を選出して、それぞれクライアント装置３から送信されたリクエスト信号を入力する選出のステップと、代表装置のサーバ２が、他のサーバ２に、それぞれリクエスト信号を複製して送信する準備のステップと、代表装置のサーバ２がリクエスト信号の送信先である他のサーバ２から処理結果を受信し、システム全体の所定割合の多数決で合意を形成するコミットのステップと、代表装置の各サーバ２間で合意を相互に確認する確認のステップと、代表装置の各サーバ２からクライアント装置３へ合意した処理結果を応答する応答のステップとを実行する。【選択図】図３
2015146165.tif 000002
【特許請求の範囲】
【請求項１】
システムに複数台が相互に通信可能に接続される障害耐性信号処理装置であって、
複数台の前記障害耐性信号処理装置のうち３分の１を超える台数を代表装置として選出する選出部と、
クライアント装置からリクエスト信号を最初に受信したならば、前記リクエスト信号を前記代表装置に振り分ける振分部と、
振り分けられた前記リクエスト信号を受信したならば、自装置以外の障害耐性信号処理装置に、それぞれ前記リクエスト信号を複製して送信する準備部と、
前記リクエスト信号の送信先の障害耐性信号処理装置から処理結果を受信し、前記システム全体の所定割合の多数決で合意を形成するコミット部と、
各前記代表装置間で合意を相互に確認する確認部と、
前記クライアント装置へ合意した処理結果を応答する応答部と、
を備えることを特徴とする障害耐性信号処理装置。
【請求項２】
各前記代表装置の前記コミット部は、合意を形成するステップにおいて、前記システム全体の少なくとも３分の２以上の多数決を行う、
ことを特徴とする請求項１に記載の障害耐性信号処理装置。
【請求項３】
前記クライアント装置から前記リクエスト信号を最初に受信した障害耐性信号処理装置は、前記選出部により複数台の前記障害耐性信号処理装置のうち３分の１を超える台数を前記代表装置として選出して、前記振分部により前記代表装置に前記リクエスト信号を振り分ける、
ことを特徴とする請求項１に記載の障害耐性信号処理装置。
【請求項４】
前記準備部は、振り分けられた前記リクエスト信号を受信すると、自装置が前記代表装置として選出されたと判断する。
ことを特徴とする請求項３に記載の障害耐性信号処理装置。
【請求項５】
システムに相互に通信可能に接続された複数台の障害耐性信号処理装置の３分の１を超える台数を占める代表装置を選出して、それぞれクライアント装置から送信されたリクエスト信号を入力するステップと、
各前記代表装置が、自装置以外の障害耐性信号処理装置に、それぞれ前記リクエスト信号を複製して送信するステップと、
各前記代表装置が、前記リクエスト信号の送信先の障害耐性信号処理装置から処理結果を受信し、前記システム全体の所定割合の多数決で合意を形成するステップと、
各前記代表装置間で合意を相互に確認するステップと、
各前記代表装置から前記クライアント装置へ合意した処理結果を応答するステップと、
を実行することを特徴とする障害耐性信号処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、サーバなどで構成される信号処理装置群の連携処理中に、一部の装置で障害発生した場合において、システム全体として正しい合意を形成するための障害耐性信号処理装置および障害耐性信号処理方法に関する。
【背景技術】
【０００２】
近年の情報通信サービスを担うシステムは、複数の処理装置が協調・連携動作することで実現している。例えば、ユーザ認証、データベース検索、コンテンツ配信などのＷｅｂサービスに関する一連の処理をＷｅｂ三層モデルで実現する場合を考える。このＷｅｂ三層モデルは、クライアント端末からのリクエスト信号を受け付けるＷｅｂサーバ、データ処理を行うデータベースサーバ、サービス／ビジネスロジックを実現するＡＰサーバの３つから構成され、これらの連携動作によってサービスを実現している。
これら相互に通信しあう装置群が、その通信あるいは装置自体の故障または故意によって障害が発生し、誤った処理あるいは信号を伝達する虞がある状況においても、システム全体として正しい処理結果を得て合意形成をする必要がある。この問題をビザンチン将軍問題と呼び、その障害のことをビザンチン障害と呼ぶ。
銀行のオンライン決済など、全サーバ間でトランザクションの一貫性が求められる高信頼サーバシステムでは、ビザンチン障害への対処が求められている。
【０００３】
ビザンチン将軍問題とは、例えば、司令官と第１副官と第２副官とからなる将軍達が、それぞれ軍団を率いて単一の都市を包囲している状況で発生する問題である。将軍達は、それぞれ離れた場所に各軍団を配置している。一部の将軍だけで都市に攻撃を仕掛けても敗北するため、将軍達は、使者を相互に送ることで、攻撃か撤退かを全員一致で決めなければならない。ここで問題となるのは、一部の将軍が反逆者（裏切り者）である場合である。
【０００４】
第１ケースとして、第２副官が反逆者であり、司令官が攻撃指示したと仮定する。反逆者の第２副官は、司令官の攻撃指示にも関わらず、第１副官に撤退指示する。このとき、第１副官は、司令官からは攻撃指示を受けるが、裏切り者の第２副官からは撤退指示を受ける。
第２ケースとして、司令官が反逆者であり、第１副官には攻撃指示し、第２副官には撤退指示したと仮定する。第２副官は、司令官の撤退指示を第１副官に伝達する。このとき、第１副官は、先のケースと同様に、司令官からは攻撃指示を受け、第２副官からは撤退指示を受ける。よって、第１副官は、司令官と第２副官から異なる指示を受けたとき、いずれが反逆者であるか判断できず、多数決による合意形成はできない。一般的に反逆者の人数が将軍の人数の３分の１以上のとき、正しい合意形成ができなくなる。
【０００５】
非特許文献１には、このビザンチン将軍問題が、分散コンピューティング分野における合意問題として定式化されている。
非特許文献１が発表されたことを発端として、分散コンピューティング分野でビザンチン将軍問題に関する議論・検討が高まった。非特許文献１では、システム全体で正しい合意を形成するには、障害ノード数が全体ノード数の３分の１未満である必要があることを証明している。また、当時のビザンチン将軍問題の解決手法として、アルゴリズムＯＭ（Oral Message Algorithm）と、アルゴリズムＳＭ（Signed Message Algorithm）とが提案されている。
アルゴリズムＯＭ（Oral Message Algorithm）とは、信号を受信したノードが、その信号を他の関連ノードに伝達し、最終的に全ノードの多数決にてシステム全体の合意を取るものである。信号をノード間で口頭伝達する様からOral Message Algorithmと名付けられた。アルゴリズムＯＭは、最初の信号伝達ノードが他ノードへそれぞれ異なる信号を伝達した場合に、システム全体の合意が取れない問題と、どのノードが誤った信号を伝達したかが不明であるという問題とがあった。
アルゴリズムＳＭは、ノード間で伝達する信号に、各ノードがそれぞれ電子署名を付けることにより、アルゴリズムＯＭの問題を解決するものである。
しかし、これらの手法は、実際のコンピュータシステムに適用するには複雑であり、処理量が嵩むことから実用化されなかった。
【０００６】
非特許文献２には、実用的なビザンチン障害耐性を得るためのノード間レプリケーションプロトコルが記載されている。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】Lamport, L.; Shostak, R.; Pease, M、“The Byzantine Generals Problem”、ACM Transactions on Programming Languages and Systems、July 1982、4 (3)、pp.382-401.
【非特許文献２】M. Castro and B. Liskov、“Practical Byzantine Fault Tolerance and Proactive Recovery”、ACM Transactions on Computer Systems、2002、Vol. 20、No.4、pp.398-461
【発明の概要】
【発明が解決しようとする課題】
【０００８】
非特許文献２に記載の技術では、必要以上の信号がノード間で複製され伝達されるため、信号量と処理量とが極めて大きくなる虞がある。総ノード数をｎとすると、ノード間で伝達・複製される信号量は、２ｎ2−１となるためである。
非特許文献２に記載の技術では更に、クライアント装置が受信するリプライ信号が全ノードから送信される。クライアント装置は、全ノードからのリプライを受信して内容を検証しなければならず、クライアント装置側の処理負荷が大きくなる虞がある。
また、非特許文献２に記載の技術では、アルゴリズムＯＭと同様に、クライアント装置から最初にリクエスト信号を受け取るノードに障害がある場合には、どのノードに障害があったかをシステム全体で把握できないという問題がある。
【０００９】
本発明は、前記した問題を解決し、信号処理装置が、少ない信号量と処理量にてビザンチン障害耐性を得るための障害耐性信号処理方法および、これを実行する障害耐性信号処理装置を提供することを課題とする。
【課題を解決するための手段】
【００１０】
前記課題を解決するため、請求項１に記載の発明は、システムに複数台が相互に通信可能に接続される障害耐性信号処理装置であって、複数台の前記障害耐性信号処理装置のうち３分の１を超える台数を代表装置として選出する選出部と、クライアント装置からリクエスト信号を最初に受信したならば、前記リクエスト信号を前記代表装置に振り分ける振分部と、振り分けられた前記リクエスト信号を受信したならば、自装置以外の障害耐性信号処理装置に、それぞれ前記リクエスト信号を複製して送信する準備部と、前記リクエスト信号の送信先の障害耐性信号処理装置から処理結果を受信し、前記システム全体の所定割合の多数決で合意を形成するコミット部と、各前記代表装置間で合意を相互に確認する確認部と、前記クライアント装置へ合意した処理結果を応答する応答部と、を備えることを特徴とする障害耐性信号処理装置とした。
【００１１】
このようにすることで、少ない信号量と処理量にてビザンチン障害耐性を得ることができる。
【００１２】
請求項２に記載の発明は、各前記代表装置の前記コミット部は、合意を形成するステップにおいて、前記システム全体の少なくとも３分の２以上の多数決を行う、ことを特徴とする請求項１に記載の障害耐性信号処理装置とした。
【００１３】
このようにすることで、複数台の障害耐性信号処理装置のうち一部が故障していた場合であっても、合意を形成することができる。
【００１４】
請求項３に記載の発明は、前記クライアント装置から前記リクエスト信号を最初に受信した障害耐性信号処理装置は、前記選出部により複数台の前記障害耐性信号処理装置のうち３分の１を超える台数を前記代表装置として選出して、前記振分部により前記代表装置に前記リクエスト信号を振り分ける、ことを特徴とする請求項１に記載の障害耐性信号処理装置とした。
【００１５】
このようにすることで、サーバ２の台数（ノード数ｎ）が動的に変化しても、適切な台数の代表装置を選出できる。
【００１６】
請求項４に記載の発明は、前記準備部は、振り分けられた前記リクエスト信号を受信すると、自装置が前記代表装置として選出されたと判断することを特徴とする請求項３に記載の障害耐性信号処理装置とした。
【００１７】
このようにすることで、代表装置として選出したことを通知する信号の送信を省略することができる。
【００１８】
請求項５に記載の発明は、システムに相互に通信可能に接続された複数台の障害耐性信号処理装置の３分の１を超える台数を占める代表装置を選出して、それぞれクライアント装置から送信されたリクエスト信号を入力するステップと、各前記代表装置が、自装置以外の障害耐性信号処理装置に、それぞれ前記リクエスト信号を複製して送信するステップと、各前記代表装置が、前記リクエスト信号の送信先の障害耐性信号処理装置から処理結果を受信し、前記システム全体の所定割合の多数決で合意を形成するステップと、各前記代表装置間で合意を相互に確認するステップと、各前記代表装置から前記クライアント装置へ合意した処理結果を応答するステップと、を実行することを特徴とする障害耐性信号処理方法とした。
【００１９】
このようにすることで、少ない信号量と処理量にてビザンチン障害耐性を得ることができる。
【発明の効果】
【００２０】
本発明によれば、信号処理装置が、少ない信号量と処理量にてビザンチン障害耐性を得るための障害耐性信号処理方法および、これを実行する障害耐性信号処理装置を提供することが可能となる。
【図面の簡単な説明】
【００２１】
【図１】本実施形態における障害耐性信号処理システムを示す概略の構成図である。
【図２】本実施形態におけるサーバを示す概略の構成図である。
【図３】本実施形態における各信号のシーケンス図である。
【図４】本実施形態と比較例のサーバ数と信号量の関係を示すグラフである。
【図５】比較例の障害耐性信号処理システムを示す概略の構成図である。
【図６】比較例のサーバを示す概略の構成図である。
【図７】比較例の信号のシーケンス図である。
【発明を実施するための形態】
【００２２】
最初、比較例について、適宜図面を参照しながら詳細に説明する。
図５は、比較例の障害耐性信号処理システム１Ａを示す概略の構成図である。
図５に示すように、障害耐性信号処理システム１Ａは、サーバ２Ａ−０〜２Ａ−３を備えている。サーバ２Ａ−０〜２Ａ−３は、相互に通信可能に接続されている。サーバ２Ａ−０〜２Ａ−３は、クライアント装置３のリクエスト信号を分散して処理する信号処理装置群であると共に、ビザンチン障害耐性を有する障害耐性信号処理装置である。サーバ２Ａ−０〜２Ａ−３は、図では「サーバ＃０〜＃３」と記載している。以下、サーバ２Ａ−０〜２Ａ−３を特に区別しないときには、単に「サーバ２Ａ」と記載している場合がある。
【００２３】
図６は、比較例のサーバ２Ａ−１を示す概略の構成図である。なお、サーバ２Ａ−０，２Ａ−２，２Ａ−３も、サーバ２Ａ−１と同様に構成されている。
図６に示すように、サーバ２Ａ−１は、振分部２２と、準備部２３と、コミット部２４と、応答送信部２６と、信号署名部２７と、信号処理部２８とを備えている。
振分部２２は、クライアント装置３から受信したリクエスト信号を、他のサーバ２Ａ−０，２Ａ−２，２Ａ−３に振り分けるものである。他のサーバ２Ａ−０，２Ａ−２，２Ａ−３は、振り分けられたリクエスト信号を信号処理部２８で信号処理して、処理結果を得る。
【００２４】
準備部２３は、信号処理部２８の処理結果を、他のサーバ２Ａ−０，２Ａ−２，２Ａ−３に振り分けるものである。これにより、障害耐性信号処理システム１Ａは、処理結果を各サーバ２Ａで共有することができる。
コミット部２４は、他のサーバ２Ａから受信した複数の処理結果を、多数決を行って合意するものである。
応答送信部２６は、クライアント装置３に処理結果を応答するものである。
信号署名部２７は、リクエスト信号に電子署名するものである。電子署名したリクエスト信号は、更に他のサーバ２Ａに送信される。
信号処理部２８は、リクエスト信号を信号処理するものである。
【００２５】
図７は、比較例の各信号のシーケンス図である。
ここでは、サーバ２Ａ−３が故障しているときのシーケンスを例示している。各ステップの下には、比較例の全体のノード数（サーバ数）をｎとした場合の、このステップにおける理論上の信号量が記載されている。ここで理論上の信号量とは、いずれのサーバ２Ａも故障していないときの信号量である。
要求ステップにおいて、クライアント装置３は、リクエスト信号Ｓ０を、サーバ２Ａ−０に送信する。要求ステップにおける理論上の信号量は、１である。
前準備ステップにおいて、サーバ２Ａ−０は、振分部２２（図６参照）により、リクエスト信号Ｓ１を他のサーバ２Ａ−０，２Ａ−２，２Ａ−３に振り分ける。前準備ステップにおける理論上の信号量は、（ｎ−１）である。前準備ステップが終了すると、サーバ２Ａ−０〜２Ａ−２は、信号処理部２８（図６参照）により、リクエスト信号Ｓ１を信号処理する。サーバ２Ａ−３は故障しているため、この信号処理を行わない。
【００２６】
準備ステップにおいて、サーバ２Ａ−１，２Ａ−２は、振分部２２により、処理結果Ｒ０を他のサーバ２Ａに振り分ける。サーバ２Ａ−３は故障しているため、この振り分けを行わない。準備ステップにおける理論上の信号量は、（ｎ−１）2である。
コミットステップにおいて、サーバ２Ａ−０〜２Ａ−２は、コミット部２４により、障害耐性信号処理システム１Ａのすべてのサーバ２Ａの処理結果Ｒ０を多数決して、合意した処理結果Ｒ１を形成する。サーバ２Ａ−０〜２Ａ−２は、それぞれ他のサーバ２Ａに合意した処理結果Ｒ１を送信する。サーバ２Ａ−３は故障しているため、この処理を行わない。コミットステップにおける理論上の信号量は、ｎ2である。
【００２７】
応答ステップにおいて、サーバ２Ａ−０〜２Ａ−２は、応答送信部２６により、クライアント装置３に処理結果Ｒ３Ａを応答する。サーバ２Ａ−３は故障しているため、この処理を行わない。応答ステップにおける理論上の信号量は、ｎである。クライアント装置３は、サーバ２Ａ−０〜２Ａ−２から受信した全ノードからのリプライを受信して内容を検証しなければならない。
【００２８】
比較例の全体のサーバ２Ａの台数（ノード数）をｎとし、故障したサーバ２Ａの台数（故障ノード数）をｋとする。以下の式（１）を満たすときに、リクエスト信号の処理結果の合意を形成できる。
【数１】
2015146165.tif 000003
【００２９】
比較例では、全サーバ２Ａ（全ノード）が、フルメッシュで相互のリクエスト信号の処理結果を共有しているため、サーバ２Ａの台数の増加に伴って信号量が飛躍的に増加する。しかし、式（１）によれば、全サーバ２Ａの総数の３分の１以上のサーバ２Ａ（ノード）で信号集約しても、同様の品質を満たすことができる。すなわち、以下の式（２）のノード数のサーバ２Ａに、全ノード処理結果を集約することができる。ここで［ｘ］は、ｘ以下の最大の整数を示す記法である。
【数２】
2015146165.tif 000004
【００３０】
次に、本発明を実施するための形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
図１は、本実施形態における障害耐性信号処理システム１を示す概略の構成図である。
図１に示すように、障害耐性信号処理システム１は、サーバ２−０〜２−４を備えている。サーバ２−０〜２−４は、相互に通信可能に接続されている。サーバ２−０〜２−４は、クライアント装置３のリクエスト信号を分散して処理する信号処理装置群であると共に、ビザンチン障害耐性を有する障害耐性信号処理装置である。サーバ２−０〜２−４は、図では「サーバ＃０〜＃４」と記載している。以下、サーバ２−０〜２−４を特に区別しないときには、単に「サーバ２」と記載している場合がある。
【００３１】
図２は、本実施形態におけるサーバ２−１を示す概略の構成図である。なお、サーバ２−０，２−２〜２−４も、サーバ２−１と同様に構成されている。
図２に示すように、サーバ２−１は、選出部２１と、振分部２２と、準備部２３と、コミット部２４と、確認部２５と、応答送信部２６と、信号署名部２７と、信号処理部２８とを備えている。
選出部２１は、障害耐性信号処理システム１が備えるサーバ２から代表装置を選出するものである。選出部２１は、複数台のサーバ２のうち３分の１を超える台数を代表装置として選出する。
振分部２２は、選出部２１が選出した代表装置に、クライアント装置３から受信したリクエスト信号を振り分けるものである。クライアント装置３は、いずれのサーバ２にリクエスト信号を送信してもよいので、障害耐性が向上する。
【００３２】
準備部２３は、振分部２２により振り分けられたリクエスト信号を、他のすべてのサーバ２に振り分けるものである。
コミット部２４は、他のサーバ２から受信した複数の処理結果を、多数決を行って合意するものである。
確認部２５は、コミット部２４により合意した処理結果を、更に代表装置の間で確認するものである。
応答送信部２６は、コミット部２４により合意して、確認部２５により確認した合意結果を、クライアント装置３に応答するものである。
信号署名部２７は、リクエスト信号に電子署名するものである。電子署名したリクエスト信号は、更に他のサーバ２に送信される。
信号処理部２８は、リクエスト信号を信号処理して処理結果を生成するものである。
【００３３】
図３は、本実施形態における各信号のシーケンス図である。本実施形態では、以下の処理ステップを実行することにより、ビザンチン障害耐性を実現する。各ステップの下には、本実施形態の全体のサーバ数（ノード数）をｎとした場合の、このステップにおける理論上の信号量が記載されている。
要求ステップにおいて、クライアント装置３は、リクエスト信号Ｓ０をサーバ２−４に送信する。サーバ２−４は、クライアント装置３からリクエスト信号Ｓ０を受信する。要求ステップにおける理論上の信号量は、１である。ここで、サーバ２−４は、ノードとしてではなく、ロードバランサとして動作しているため、障害耐性信号処理装置の台数には含まれない。本実施形態の全体のサーバ数（ノード数）は、４である。
選出ステップにおいて、サーバ２−４は、選出部２１によりサーバ２−０，２−２を代表装置として選出する。選出部２１は、少なくとも以下の式（３）で示される台数の代表装置を選出する。
【数３】
2015146165.tif 000005
【００３４】
サーバ２−４は、クライアント装置３からリクエスト信号Ｓ０を最初に受信したとき、選出部２１によりサーバ２−０，２−２を代表装置として、動的に選出している。これにより、サーバ２の台数（ノード数ｎ）が動的に変化しても、適切な台数の代表装置を選出できる。
サーバ２−４は更に、振分部２２により、これら代表装置に、クライアント装置３から受信したリクエスト信号Ｓ０を複製して、リクエスト信号Ｓ１として振り分ける。サーバ２−０，２−２は、振り分けられたリクエスト信号Ｓ１を受信すると、自装置が代表装置として選出されたと判断する。これにより、代表装置として選出されたことを通知する信号の送信を省略することができる。この選出ステップにおける理論上の信号量は、式（３）で示される代表装置の選出数と同一である。
選出部２１は、式（３）で示される台数以上の代表装置を選出してもよい。すなわち、選出部２１は、障害耐性信号処理装置の３分の１を超える台数を占めるように、代表装置を選出してもよい。
このリクエスト信号Ｓ０を複製して振り分ける処理は、ノード自体ではなく、例えばロードバランサなどの別装置を使うことが望ましい。
【００３５】
準備ステップにおいて、代表装置として選出されたサーバ２−０，２−２は、準備部２３により、自装置に振り分けられたリクエスト信号Ｓ１を複製して、リクエスト信号Ｓ２として自装置以外の全サーバ２に伝達する。リクエスト信号Ｓ２を受け取った各サーバ２および自装置は、信号内の処理命令に基づいて信号処理を行う。
準備ステップにおける理論上の信号量は、以下の式（４）で示され、自装置以外の全サーバ２の台数と選出した代表装置の台数との積である。
【数４】
2015146165.tif 000006
【００３６】
コミットステップにおいて、各サーバ２は、処理結果Ｒ１を、リクエスト信号Ｓ２の伝達元のノードであるサーバ２−０，２−２に返却する。代表装置であるサーバ２−０，２−２は、リクエスト信号Ｓ２の送信先のサーバ２から処理結果Ｒ１を受信し、障害耐性信号処理システム１全体のノード数の３分の２以上の割合の多数決で合意を形成する。合意には全サーバ２−０〜２−３（全ノード）のうち、３分の２以上の票数が必要である。
コミットステップにおける理論上の信号量は、以下の式（５）で示され、選出した代表装置の台数と自装置以外の全サーバ２の台数との積である。
【数５】
2015146165.tif 000007
【００３７】
確認ステップにおいて、代表装置であるサーバ２−０，２−２は、各代表装置間で合意を相互に確認して各々が合意した処理結果Ｒ２を共有し、合意結果Ｒ３を生成する。この確認ステップが設けられた理由は、代表装置であるサーバ２−０，２−２自体の障害中である可能性を考慮したためである。
ここでは、全ての代表装置の処理結果Ｒ２が同一、すなわち全会一致となるはずである。しかし、万が一、全会一致とならなかった場合には、一部の代表装置が障害中である可能性が高いため、エラーとする。
確認ステップにおける理論上の信号量は、以下の式（６）で示され、代表装置の選出数と同一である。
【数６】
2015146165.tif 000008
【００３８】
応答ステップにおいて、代表装置であるサーバ２−０，２−２は、サーバ２−４を介してクライアント装置３に合意結果Ｒ３を送信する。クライアント装置３は、全ての代表装置の合意結果Ｒ３を受信して、これらの内容が全て一致していることを確認する。クライアント装置３が確認を行うのは、いずれかの代表装置に障害が発生する場合を考慮したためである。
この合意結果Ｒ３を含むクライアント装置３への応答信号には、代表装置（選出ノード）の総数を含んでいる。代表装置（選出ノード）の総数は、図３に示す例では２である。クライアント装置３が、何個の応答信号を受信すればよいかを把握するためである。
応答ステップにおける理論上の信号量は、以下の式（７）で示され、代表装置の選出数と同一である。
【数７】
2015146165.tif 000009
【００３９】
本実施形態において、サーバ数をｎとしたときの選出ステップから応答ステップまでの理論上の信号量は、以下の式（８）で示される。
【数８】
2015146165.tif 000010
【００４０】
これに対して比較例では、前準備ステップから応答ステップまでの理論上の信号量は、以下の式（９）で示される。
【数９】
2015146165.tif 000011
【００４１】
図４は、本実施形態と比較例のサーバ数と信号量の関係を示すグラフである。図４の横軸は、サーバ数を示している。図４の縦軸は、理論上の信号量を示している。図４に示すグラフは、上記した式（８）と式（９）に基づくものである。
図４に示したように、本実施形態では、比較例に比べて信号量を約半分以下に削減することが可能となる。信号量の半減に伴い、各ノードの処理量も半減させることができる。更にクライアント装置３の応答信号の信号量と、その処理量とは、約３分の１に削減することができる。
【００４２】
（変形例）
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、例えば以下のような変更実施が可能である。
（ａ）  図３に示した確認ステップにおいて、各代表装置は、全代表装置が合意した処理結果が全会一致とならなかった場合には、代表装置のノード数の３分の２以上の割合の多数決で合意結果を確認してもよい。これにより、代表装置のいずれかが故障していた場合であっても、クライアント装置３に、適切な合意結果を応答することができる。
【００４３】
（ｂ）  障害耐性信号処理システム１は、リクエスト信号Ｓ０を複製して振り分ける専用のロードバランサなどの別装置を備えていてもよい。
（ｃ）  代表装置は、本実施形態のように動的に選出されてもよく、システム起動時などに予め静的に決められていてもよく、限定されない。
（ｄ）  代表装置は、予め決められたサーバ２（ノード）であってもよい。これにより、リクエスト信号Ｓ０の受信時の処理量を減らすことができる。
【符号の説明】
【００４４】
１，１Ａ  障害耐性信号処理システム
２，２Ａ  サーバ  （障害耐性信号処理装置）
３  クライアント装置
２１  選出部
２２  振分部
２３  準備部
２４  コミット部
２５  確認部
２６  応答送信部
２７  信号署名部
２８  信号処理部
【図１】
2015146165.tif 000012
【図２】
2015146165.tif 000013
【図３】
2015146165.tif 000014
【図４】
2015146165.tif 000015
【図５】
2015146165.tif 000016
【図６】
2015146165.tif 000017
【図７】
2015146165.tif 000018