JP2015520440A - 分散合意プロトコルにおいてｃｒｕｄ型のプロトコルをバインドする - Google Patents

Abstract

様々な実施形態により、「クラウド」サービスのような、冗長サービスまたはレプリカサービスが、地理的に分散された場所で実行されることが可能になる。各レプリカは、一般的に、すべてのレプリカにわたって全く同じように行われる操作を行うことができる。１つの場所において中断が発生した場合、他の場所にあるサービスが、迅速に、かつ自動的に、操作を引き継ぐことができる。１つまたは複数の実施形態では、分散合意プロトコルが使用されて、ＣＲＵＤ型プロトコルを状態機械としてバインドする。バインドは、サービスが分散される場所のそれぞれに配置されたリバースプロキシを使用することにより行われる。少なくとも一部の実施形態では、分散合意プロトコルは、Ｐａｘｏｓプロトコルもしくはその変形物として実装される、および／またはＣＲＵＤ型プロトコルは、ＨＴＴＰプロトコルを含む。

Description

本願発明の一実施例は、例えば、分散合意プロトコルにおいてＣＲＵＤ型のプロトコルをバインドすることに関する。

[0001]インターネットを通じて提供されるサービス、例えばいわゆる「クラウド」サービスなどは、ユーザー体験を低下させる恐れのある中断を経験する可能性がある。このような中断は、ユーザー体験を低下させることに加えて、実際の金銭の損失ならびに信用の損失など、ビジネスコストに関して多大な組織的影響を与える可能性がある。

本願発明の一実施例は、例えば、分散合意プロトコルにおいてＣＲＵＤ型のプロトコルをバインドすることに関する。

[0002]この発明の概要により、以下の発明を実施するための形態でさらに説明する概念の抜粋を簡略化して紹介する。この発明の概要は、特許請求の範囲に記載する主題の主要な特徴または本質的特徴を特定するものではない。

[0003]様々な実施形態により、「クラウド」サービスのような、冗長サービスまたはレプリカサービスが、地理的に分散された場所で実行されることが可能になる。各レプリカは、一般的に、すべてのレプリカにわたって全く同じように行われる操作を行うことができる。１つの場所において中断が発生した場合、他の場所にあるサービスが、迅速に、かつ自動的に、操作を引き継ぐことができる。

[0004]１つまたは複数の実施形態では、分散合意プロトコルが使用されて、ＣＲＵＤ型プロトコルを状態機械としてバインドする。バインドは、サービスが分散される場所のそれぞれに配置されたリバースプロキシを使用することにより行われる。少なくとも一部の実施形態では、分散合意プロトコルは、Ｐａｘｏｓプロトコルもしくはその変形物として実装される、および／またはＣＲＵＤ型プロトコルは、ハイパーテキストトランスポートプロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ：ＨＴＴＰ）を含む。

[0005]図面を通して同じ番号が使用されて、同様の特徴に参照符号を付ける。

[0006]１つまたは複数の実施形態に従った例示的動作環境を示す図である。 [0007]１つまたは複数の実施形態に従った例示的動作環境を示す図である。 [0008]１つまたは複数の実施形態に従った方法のステップを説明する流れ図である。 [0009]１つまたは複数の実施形態に従った例示的システムを示す図である。 [0010]１つまたは複数の実施形態に従った例示的デバイスを示す図である。

概説
[0011]様々な実施形態により、「クラウド」サービスのような、冗長サービスまたはレプリカサービスが、地理的に分散された場所で実行されることが可能になる。各レプリカは、一般的に、すべてのレプリカにわたって全く同じように行われる操作を行うことができる。１つの場所において中断が発生した場合、他の場所にあるサービスが、迅速に、かつ自動的に、操作を引き継ぐことができる。

[0012]１つまたは複数の実施形態では、分散合意プロトコルが使用されて、ＣＲＵＤ型プロトコルを状態機械としてバインドする。バインドは、サービスが分散される場所のそれぞれに配置されたリバースプロキシを使用することにより行われる。少なくとも一部の実施形態では、分散合意プロトコルは、Ｐａｘｏｓプロトコルもしくはその変形物として実装される、および／またはＣＲＵＤ型プロトコルは、ハイパーテキストトランスポートプロトコル（ＨＴＴＰ）を含む。しかしながら、この文書に記載する技法は、任意の好適なステートレスＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）プロトコルに関連して使用されることが可能であることは認識され、理解されよう。当業者には認識されるように、ＲＥＳＴは、一連のアーキテクチャ理念を定義し、それによりウェブサービスは、異なる言語で書かれた広範なクライアントによりＨＴＴＰを通じてリソース状態がアドレス指定され、転送される方法を含み、システムのリソースに焦点を当てるように設計されることが可能である。当業者には認識されるように、ＲＥＳＴ型アーキテクチャは、クライアントおよびサーバーと関連して利用される。一般的にクライアントが、サーバーへの要求を開始し、その後サーバーが要求を処理し、適切な応答を返す。要求および応答は、リソースの表現の転送を中心に構築される。リソースは、アドレス指定されることが可能な、任意の首尾一貫した有意味な概念を含むことができる。リソースの表現は、通常、リソースの現在の、または意図される状態を記録するドキュメントである。クライアントは、新しい状態へ遷移する用意ができているとき、要求を送信することによって通信を開始する。１つまたは複数の要求が未処理である間、クライアントは遷移中であるとみなされる。各状態の表現は、リンクを含むことができ、クライアントが次に新しい状態遷移を開始することを選択するとき、これを使用することができる。

[0013]次の説明では最初に、本明細書に記載する技法を使用することができる例示的環境について述べる。次に、例示的環境ならびに他の環境で行われることが可能である例示的手順について述べる。その結果として、例示的手順の実行は、例示的環境に限定されず、例示的環境は、例示的手順の実行に限定されない。
例示的環境
[0014]図１は、全体として１００において、１つまたは複数の実施形態に従った例示的動作環境を示す。環境１００は、１つまたは複数のプロセッサ１０４と、１つまたは複数のコンピューター可読記憶媒体１０６と、コンピューター可読記憶媒体上にあり、プロセッサ１０４によって実行される１つまたは複数のアプリケーション１０８とを有するローカルクライアントマシンの形式のコンピューティングデバイス１０２を含む。またコンピューティングデバイス１０２は、ウェブブラウザー１１０と、以下に述べるように動作するオペレーティングシステム１１１とを含む。

[0015]コンピューティングデバイス１０２は、例として、限定ではないが、デスクトップコンピューター、ポータブルコンピューター、携帯情報端末（ＰＤＡ）のようなハンドヘルドコンピューター、携帯電話、テレビ、タブレットコンピューターなど、任意の好適なコンピューティングデバイスとして具体化されることが可能である。コンピューターデバイス１０２の多種多様な例の１つが、図４および５に示され、説明される。

[0016]アプリケーション１０８は、任意の好適なタイプのアプリケーションを含むことができる。ウェブブラウザー１１０は、ネットワーク１１２を介してナビゲートするように構成される。ネットワーク１１２は、インターネットとして図示されているが、ネットワークは、幅広い構成を想定することができる。例えば、ネットワーク１１２は、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、無線網、公衆電話網、イントラネットなどを含むことができる。さらに、単一のネットワーク１１２が示されているが、ネットワーク１１２は、複数のネットワークを含むように構成されることが可能である。

[0017]ブラウザーは、ウェブサーバーのような１つまたは複数のサーバー１１４から入手できるコンテンツと対話する、ならびに１つまたは複数のサーバー１１４にデータを伝える、例えばダウンロードおよびアップロードを行うために、ネットワーク１１２を介してナビゲートするように構成されることが可能である。サーバー１１４は、ネットワーク１１２を介してアクセス可能であり、コンピューティングデバイス１０２によって消費されることが可能である、ウェブサービス（「クラウドサービス」とも呼ばれる）のような、１つまたは複数のサービスを提供するように構成されることが可能である。このようなサービスの例には、地図サービス、電子メール、ウェブページ、写真共有サイト、ソーシャルネットワーク、コンテンツ共有サービス、メディアストリーミングサービス、データ検索および／または表示サービスなどが含まれる。

[0018]アプリケーション１０８の１つまたは複数は、例えば自ら直接に、および／またはブラウザーを介して、ネットワーク１１２にアクセスするように構成されることも可能である。例えば、アプリケーション１０８の１つまたは複数は、電子メール、インスタントメッセージなどのメッセージを伝えるように構成されることが可能である。さらなる例では、例えばアプリケーション１０８は、ソーシャルネットワークにアクセスする、天気の更新を取得する、ウェブサーバー１１４の１つまたは複数によって実装される書店サービスと対話する、文書処理を支援する、スプレッドシート機能を提供する、プレゼンテーションの作成および出力を支援するなどを行うように構成されることが可能である。

[0019]したがって、アプリケーション１０８は、直接または間接のネットワーク１１２アクセスを伴うことがある様々な機能に合わせて構成されることも可能である。例えば、アプリケーション１０８は、アプリケーション１０８によってローカルに利用されるとともに、別のコンピューティングデバイス上で実行されるアプリケーションと同期されることが可能である、構成設定および他のデータを含むことができる。このようにして、これらの設定は、デバイスによって共有されることが可能である。様々な他の例もまた検討される。したがって、コンピューティングデバイス１０２は、多種多様なソースから様々な方法でコンテンツと対話することができる。

[0020]図示され説明される実施形態では、サーバー１１４が、冗長ウェブサービスであるウェブサービスをそれぞれ支援することができる。すなわち、各冗長ウェブサービスは、他のウェブサービスのコピーまたはレプリカである。これらのウェブサービスは、地理的に分散された場所で運営される、または実行されることが可能であり、通常そのようにされる。各レプリカサービスは、一般的に、すべてのレプリカにわたって全く同じように行われる操作を行うことができる。１つの場所において中断が発生した場合、他の場所にあるサービスが、迅速に、かつ自動的に、操作を引き継ぐことができる。

[0021]１つまたは複数の実施形態では、分散合意プロトコルが使用されて、ＣＲＵＤ型プロトコルを状態機械としてバインドする。バインドは、サービスが分散される場所のそれぞれに配置されたリバースプロキシを使用することにより行われる。少なくとも一部の実施形態では、分散合意プロトコルは、Ｐａｘｏｓプロトコルもしくはその変形物として実装される、および／またはＣＲＵＤ型プロトコルは、以下で明らかになるように、ＨＴＴＰプロトコルを含む。

[0022]一般的に、本明細書に記載する機能のいずれも、ソフトウェア、ファームウェア、ハードウェア（例えば固定論理回路）、またはこれらの実装の組合せを使用して、実装されることが可能である。本明細書で使用する「モジュール」、「機能」、および「論理」という用語は、一般的に、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せを表す。ソフトウェア実装の場合、モジュール、機能、または論理は、プロセッサ（例えば、１つまたは複数のＣＰＵ）で実行されると指定されたタスクを行うプログラムコードを表す。プログラムコードは、１つまたは複数のコンピューター可読メモリ装置に格納されることが可能である。以下に記載する技法の特徴は、プラットフォームに依存しないことであり、この技法は、様々なプロセッサを有する様々な商用コンピューティングプラットフォーム上に実装可能であることを意味する。

[0023]例えば、コンピューティングデバイス１０２は、コンピューティングデバイス１０２のハードウェアまたは仮想マシンに、例えばプロセッサ、機能ブロックなど、操作を行わせるエンティティ（例えばソフトウェア）を含むこともできる。例えば、コンピューティングデバイス１０２は、コンピューティングデバイス、より詳細にはコンピューティングデバイス１０２のオペレーティングシステムおよび関連するハードウェアに操作を行わせる命令を保持するように構成されることが可能であるコンピューター可読媒体を含むことができる。したがって、命令は、オペレーティングシステムおよび関連するハードウェアを、その操作を行う構成にするように機能し、このようにして結果的に、オペレーションシステムおよび関連するハードウェアが機能を行うように変換される。命令は、コンピューター可読媒体によって、多種多様な構成によりコンピューティングデバイス１０２に提供されることが可能である。

[0024]コンピューター可読媒体のそのような１つの構成が、信号伝送媒体（ｓｉｇｎａｌ ｂｅａｒｉｎｇ ｍｅｄｉｕｍ）であり、したがって、例えばネットワークを介してコンピューティングデバイスに命令を（例えば、搬送波として）送信するように構成される。コンピューター可読媒体は、コンピューター可読記憶媒体として構成されることも可能であり、したがって信号伝送媒体ではない。コンピューター可読記憶媒体の例には、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、光ディスク、フラッシュメモリ、ハードディスクメモリ、ならびに磁気式、光学式、および他の技法を使用して命令およびその他のデータを格納することができる他のメモリデバイスが含まれる。

[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]図４は、図１を参照して説明したコンピューティングデバイス１０２を含んだ例示的システム４００を示す。例示的システム４００は、パーソナルコンピューター（ＰＣ）、テレビ装置、および／またはモバイルデバイスでアプリケーションを実行時のシームレスなユーザー体験のためのユビキタス環境を可能にする。アプリケーションを使用する、ビデオゲームをプレイする、ビデオを観る、その他を行いながら、あるデバイスから次のデバイスへ移るとき、サービスおよびアプリケーションが、一般的なユーザー体験に対する３つの環境すべてにおいて、実質的に同様に動作する。

[00100]例示的システム４００では、複数のデバイスが、中央コンピューティングデバイスを介して相互接続される。中央コンピューティングデバイスは、複数のデバイスに対してローカルにあることがある、または複数のデバイスからリモートに位置していることがある。１つの実施形態では、中央コンピューティングデバイスは、ネットワーク、インターネット、または他のデータ通信リンクを介して複数のデバイスに接続されている１つまたは複数のサーバーコンピューターのクラウドとすることができる。１つの実施形態では、この相互接続アーキテクチャにより、複数のデバイスにわたって機能が配信されて、複数のデバイスのユーザーに共通の、シームレスな体験を提供することができるようになる。複数のデバイスのそれぞれは、異なる物理的要件および能力を有する可能性があり、中央コンピューティングデバイスは、デバイスに合わせられ、なおかつすべてのデバイスに共通の、デバイスへの体験の配信を可能にするプラットフォームを使用する。１つの実施形態では、ターゲットデバイスのクラスが作成され、体験は、デバイスの汎用クラス（ｇｅｎｅｒｉｃ ｃｌａｓｓ）に合わせられる。デバイスのクラスは、物理的特徴、使用のタイプ、またはデバイスの他の共通の特徴によって定義されることが可能である。

[00101]様々な実行において、コンピューティングデバイス１０２は、コンピューター４０２利用、モバイル４０４利用、およびテレビ４０６利用のためなど、様々な異なる構成を想定することができる。これらの構成のそれぞれが、一般的に異なる構成および能力を有する可能性があるデバイスを含み、したがって、コンピューティングデバイス１０２は、異なるデバイスクラスの１つまたは複数に従って構成されることが可能である。例えば、コンピューティングデバイス１０２は、パーソナルコンピューター、デスクトップコンピューター、マルチスクリーンコンピューター、ラップトップコンピューター、ネットブックなどを含むコンピューター４０２クラスのデバイスとして実装されることが可能である。これらの異なる構成のそれぞれが、（１つまたは複数の）アプリケーション１０８、ウェブブラウザー１１０、およびオペレーティングシステム１１１を含めることにより説明されるように、本明細書に記載する技法を使用することができる。

[00102]コンピューティングデバイス１０２は、携帯電話、携帯音楽プレーヤー、携帯ゲーム機、タブレットコンピューター、マルチスクリーンコンピューターなどのモバイルデバイスを含むモバイル４０４クラスのデバイスとして実装されることも可能である。コンピューティングデバイス１０２は、不定期の視聴環境で一般的により大きい画面を有する、またはこれに接続されたデバイスを含むテレビ４０６クラスのデバイスとして実装されることも可能である。これらのデバイスは、テレビ、セットトップボックス、ゲーム機本体などを含む。本明細書に記載する技法は、これらの様々な構成のコンピューティングデバイス１０２によって支援されることが可能であり、本明細書に記載する特定の例の技法に限定されない。

[00103]クラウド４０８は、コンテンツサービス４１２のためのプラットフォーム４１０を含む、および／またはプラットフォーム４１０を表すものである。プラットフォーム４１０は、クラウド４０８のハードウェア（例えば、サーバー）およびソフトウェアリソースの基本的な機能を抽象化する。コンテンツサービス４１２は、コンピューターデバイス１０２から遠く離れているサーバー上でコンピューター処理が行われる間に利用されることが可能であるアプリケーションおよび／またはデータを含むことができる。コンテンツサービス４１２（例えば、クラウドサービスまたはウェブサービス）は、インターネットを通じたおよび／またはセルラー網もしくはＷｉ−Ｆｉ網のような加入者網を介したサービスとして提供されることが可能である。

[00104]プラットフォーム４１０は、リソースおよび機能を抽象化して、コンピューティングデバイス１０２を他のコンピューティングデバイスと接続することができる。プラットフォーム４１０は、リソースのスケーリングを抽象化するのに役立ち、プラットフォーム４１０を介して実装されるコンテンツサービス４１２の生じた需要に、対応するレベルのスケールを提供することもできる。したがって、相互接続されたデバイスの実施形態では、本明細書に記載する機能の実装は、システム４００全体にわたって分散されることが可能である。例えば、機能は、部分的にはコンピューティングデバイス１０２に、ならびにクラウド４０８の機能を抽象化するプラットフォーム４１０を介して、実装されることが可能である。

[00105]図５は、本明細書に記載する技法の実施形態を実装する上述の任意のタイプのコンピューティングデバイスとして実装されることが可能である例示的デバイス５００の様々な構成要素を示す。デバイス５００は、デバイスデータ５０４（例えば、受信されたデータ、受信中のデータ、ブロードキャストをスケジュールされたデータ、データのデータパケットなど）の有線および／または無線通信を可能にする通信デバイス５０２を含む。デバイスデータ５０４、または他のデバイスコンテンツは、デバイスの構成設定、デバイス上に格納されたメディアコンテンツ、および／またはデバイスのユーザーと関連する情報を含むことができる。デバイス５００に格納されたメディアコンテンツは、任意のタイプの音声、映像、および／または画像データを含むことができる。デバイス５００は、１つまたは複数のデータ入力装置５０６を含み、これを介して、ユーザーが選択可能な入力、メッセージ、音楽、テレビメディアコンテンツ、録画コンテンツ、ならびに任意のコンテンツおよび／またはデータソースから受信されるその他のタイプの音声、映像、および／または画像データなど、任意の他のタイプのデータ、メディアコンテンツ、および／または入力が受信されることが可能である。

[00106]デバイス５００は、シリアルおよび／またはパラレルインターフェイス、無線インターフェイス、任意のタイプのネットワークインターフェイス、モデムのうちのいずれか１つまたは複数として、および任意の他のタイプの通信インターフェイスとして実装されることが可能である通信インターフェイス５０８もまた含む。通信インターフェイス５０８は、デバイス５００と、通信網との間に、接続リンクおよび／または通信リンクを提供し、これにより他の電子装置、コンピューティング装置、および通信装置は、デバイス５００とデータを通信する。

[00107]デバイス５００は、デバイス５００の動作を制御するための、および本明細書に記載した技法の実施形態を実行するための、様々なコンピューター実行可能な命令を処理する１つまたは複数のプロセッサ５１０（例えば、マイクロプロセッサ、コントローラーなどのいずれか）を含む。代替的に、または追加として、デバイス５００は、全体的に５１２で識別される処理回路および制御回路と関連して実装されるハードウェア、ファームウェア、または固定論理回路のいずれか１つまたは組合せで実装されることが可能である。図示していないが、デバイス５００は、デバイス内の様々な構成要素を結合するシステムバスまたはデータ転送システムを含むことができる。システムバスは、メモリバスもしくはメモリコントローラー、周辺機器用バス、ユニバーサルシリアルバス、および／または様々なバスアーキテクチャのいずれかを使用するプロセッサバスもしくはローカルバスなど、様々なバス構造のいずれか１つまたは組合せを含むことができる。

[00108]デバイス５００は、１つまたは複数のメモリ要素などのコンピューター可読媒体５１４もまた含み、その例には、ランダムアクセスメモリ（ＲＡＭ）、不揮発性メモリ（例えば、リードオンリーメモリ（ＲＯＭ）、フラッシュメモリ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどのうち任意の１つまたは複数）、およびディスク記憶装置が含まれる。ディスク記憶装置は、ハードディスクドライブ、記録可能および／または書き換え可能コンパクトディスク（ＣＤ）、任意のタイプのデジタル多用途ディスク（ＤＶＤ）などのような、任意のタイプの磁気記憶装置または光記憶装置として実装されることが可能である。デバイス５００は、大容量記憶媒体装置５１６を含むこともできる。

[00109]コンピューター可読媒体５１４は、デバイスデータ５０４、ならびに様々なデバイスアプリケーション５１８、およびデバイス５００の操作面に関する任意のその他のタイプの情報および／またはデータを格納するためのデータ記憶機構を提供する。例えば、オペレーティングシステム５２０は、コンピューター可読媒体５１４とともにコンピューターアプリケーションとして管理され、プロセッサ５１０上で実行されることが可能である。デバイスアプリケーション５１８は、デバイスマネージャ（例えば、制御アプリケーション、ソフトウェアアプリケーション、信号処理および制御モジュール、特定のデバイスに固有のコード、特定のデバイスのハードウェアアブストラクションレイヤなど）を含むことができる。デバイスアプリケーション５１８は、本明細書に記載する技法の実施形態を実行する任意のシステム構成要素またはモジュールもまた含む。この例では、デバイスアプリケーション５１８は、ソフトウェアモジュールおよび／またはコンピューターアプリケーションとして示されるインターフェイスアプリケーション５２２および入力／出力モジュール５２４を含む。入力／出力モジュール５２４は、タッチスクリーン、トラックパッド、カメラ、マイクなど、入力を取り込むように構成されたデバイスとのインターフェイスを提供するように使用されるソフトウェアを表す。代替的に、または追加として、インターフェイスアプリケーション５２２および入力／出力モジュール５２４は、ハードウェア、ソフトウェア、ファームウェア、またはその任意の組合せとして実装されることが可能である。さらに、入力／出力モジュール５２４は、視覚入力および音声入力をそれぞれ取り込むための別個のデバイスなど、複数の入力デバイスを支援するように構成されることが可能である。

[00110]デバイス５００は、音声データを音声システム５２８に提供する、および／または映像データを表示システム５３０に提供する、音声および／または映像入力−出力システム５２６もまた含む。音声システム５２８および／または表示システム５３０は、音声、映像、および画像データを処理する、表示する、および／または他の場合はレンダリングするいかなるデバイスも含むことができる。映像信号および音声信号は、ＲＦ（高周波）リンク、Ｓ映像リンク、コンポジット映像リンク、コンポーネント映像リンク、ＤＶＩ（デジタルビデオインターフェイス）、アナログ音声接続、または他の同様の通信リンクを介して、装置５００から音声デバイスへ、および／または表示装置へ通信されることが可能である。一実施形態では、音声システム５２８および／または表示システム５３０は、デバイス５００の外部構成要素として実装される。あるいは、音声システム５２８および／または表示システム５３０は、例示のデバイス５００の内蔵構成要素として実装される。
結論
[00111]様々な実施形態により、「クラウド」サービスのような、冗長サービスまたはレプリカサービスが、地理的に分散された場所で実行されることが可能になる。各レプリカは、一般的に、すべてのレプリカにわたって全く同じように行われる操作を行うことができる。１つの場所において中断が発生した場合、他の場所にあるサービスが、迅速に、かつ自動的に、操作を引き継ぐことができる。

[00112]１つまたは複数の実施形態では、分散合意プロトコルが使用されて、ＣＲＵＤ型プロトコルを状態機械としてバインドする。バインドは、サービスが分散される場所のそれぞれに配置されたリバースプロキシを使用することにより行われる。少なくとも一部の実施形態では、分散合意プロトコルは、Ｐａｘｏｓプロトコルもしくはその変形物として実装される、および／またはＣＲＵＤ型プロトコルは、ＨＴＴＰプロトコルを含む。

[00113]主題について、構造的特徴および／または方法論的動作に特有の言語で説明したが、添付の特許請求の範囲において定義される主題は、必ずしも上記の特定の特徴または動作に限定されないことを理解されたい。むしろ上記の特定の特徴および動作は、特許請求の範囲を実施する例示的な形態として開示される。

Claims (10)

1. コンピューターにより実行される方法であって、
   ＲＥＳＴｆｕｌウェブサーバーに向けられた、前記ＲＥＳＴｆｕｌウェブサーバーによって実行されるウェブサービスによって行われる操作と関連する通信を受信するステップと、
   前記受信するステップに応答して、１つまたは複数のノードと分散合意(distributed agreement)プロトコルを開始するステップと、
   前記分散合意プロトコルを使用して、前記ノードの間で前記操作に関連してコンセンサス(consensus)に達するステップと、
   前記操作の実行を可能にするステップと
   を含む方法。
2. 各ノードが、前記ウェブサービスを実行する異なるＲＥＳＴｆｕｌウェブサーバーに対応する、請求項１に記載の方法。
3. 各ノードが、前記ウェブサービスを実行する異なる地理的位置(geographically-located)のＲＥＳＴｆｕｌウェブサーバーに対応する、請求項１に記載の方法。
4. 前記操作が、ＣＲＵＤ型操作、またはＨＴＴＰ操作のうちの１つを含む、請求項１に記載の方法。
5. 前記分散合意プロトコルが、Ｐａｘｏｓプロトコルを含む、請求項１に記載の方法。
6. 前記受信するステップが、リバースプロキシ構成要素(component)によって行われる、請求項１に記載の方法。
7. 前記操作が、ＨＴＴＰ操作を含み、前記分散合意プロトコルが、Ｐａｘｏｓプロトコルを含む、請求項１に記載の方法。
8. コンピューター可読命令を具体化する(embodying)１つまたは複数のコンピューター可読記憶媒体であって、実行されるとき、
   ＲＥＳＴｆｕｌウェブサーバーに向けられた、前記ＲＥＳＴｆｕｌウェブサーバーによって実行されるウェブサービスによって行われる操作と関連する通信を受信するステップと、
   前記受信するステップに応答して、１つまたは複数のノードと分散合意プロトコルを開始するステップであって、各ノードが、前記ウェブサービスを実行する異なるＲＥＳＴｆｕｌウェブサーバーに対応するステップと、
   前記分散合意プロトコルを使用して、前記ノードの間で前記操作に関連してコンセンサスに達するステップと、
   前記操作の実行を可能にするステップと
   を含む方法を実行する、１つまたは複数のコンピューター可読記憶媒体。
9. 前記操作が、ＣＲＵＤ型操作を含み、前記分散合意プロトコルが、Ｐａｘｏｓプロトコルを含む、請求項８に記載の１つまたは複数のコンピューター可読記憶媒体。
10. 前記操作が、ＨＴＴＰ型操作を含み、前記分散合意プロトコルが、Ｐａｘｏｓプロトコルを含む、請求項８に記載の１つまたは複数のコンピューター可読記憶媒体。

Images