JP6677759B2 - 拡張縮小可能なログベーストランザクション管理 - Google Patents

Description

近年、ますます多くのコンピューティングアプリケーションが分散環境において実施さ
れている。所定の分散アプリケーションは、例えば、プロバイダネットワークのいくつか
のデータセンタに分散された多数の物理及び／または仮想サーバを利用し、数多くの異な
る国の顧客に応対し得る。所定のアプリケーションに関わるサーバの数が増える程、及び
／またはアプリケーションのネットワークの複雑さが増す程、様々な種類の障害イベント
（プロセスまたはサーバの見かけ上または実際の障害、ネットワークメッセージレイテン
シにおける実質的遅延、または対のサーバ間の接続損失等）に必然的に遭遇する割合は高
くなる。そのため分散アプリケーションの設計者は、アプリケーション構成ステートの変
更に応じると同時に、高いレベルのアプリケーション性能（例えばアプリケーション要求
に対する高スループット及び低応答時間）の維持を試みるという課題に直面する。

ステート情報を管理するためのいくつかの従来技術は、整合的にアプリケーションステ
ート変更を実施するために、ステート情報をロックすることを伴い得る。あいにくアプリ
ケーションステート及び／またはデータに使われるロック機構は、アプリケーションのサ
イズ及び複雑さが増大すると、それ自体が性能障害となり得ることが多い。他の技術はロ
ックを回避し得るが、アプリケーションのコンポーネント間に変更されたステート情報を
伝播するために、通常動作を中断する必要があり得る。しかしながら、このような「全世
界停止」期間は、特に世界中の異なる時間帯に分布する数百または数千の顧客によるミッ
ションクリティカルな作業負荷に使用される、レイテンシに敏感なアプリケーションには
、問題となり得る。ロック及び全世界一時停止を回避するいくつかの技術でも、非常に高
いレートのステート遷移を扱う時には、障害に陥り得る。

少なくともいくつかの実施形態による、アプリケーションステート変更を管理するために複製ノードの動的ＤＡＧ（有向非巡回グラフ）が確立された例示的システム環境を示す。 少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、動的複製ＤＡＧにて生成され得るアプリケーションステートレコードとＤＡＧ構成デルタメッセージとの例示的コンポーネントを示す。 少なくともいくつかの実施形態による、プロバイダネットワークの複数の可用性コンテナにわたりメンバーノードが分散された例示的複製ＤＡＧを示す。 少なくともいくつかの実施形態による、複数の複製ＤＡＧのノードがマルチテナント様式で単一のホストに実装され得る例示的構成を示す。 少なくともいくつかの実施形態による、ステート遷移要求の受信に応じて複製ＤＡＧの受諾ノードで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、承認済みステート遷移メッセージの受信に応じて複製ＤＡＧの中間ノードで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、承認済みステート遷移メッセージの受信に応じて複製ＤＡＧのコミッタノードで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、複製ＤＡＧの構成マネジャーで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、構成マネジャーからの構成デルタメッセージの受信に応じて複製ＤＡＧのメンバーノードで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のステート複製グループのコミッタノードで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のステート複製グループの非コミッタノードで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のステート複製グループの構成マネジャーで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、複数のデータストアへの書き込みを含み得るトランザクションに対応する持続的変更ログを備える例示的システム環境を示す。 少なくともいくつかの実施形態による、複製ＤＡＧを使用する持続的変更ログの例示的実施態様を示す。 少なくともいくつかの実施形態による、ログサービスのクライアントにより提出され得るトランザクション要求記述子の例示的コンポーネント要素を示す。 少なくともいくつかの実施形態による、ログベーストランザクションマネジャーにおける読み出し書き込み競合検出の実施例を示す。 少なくともいくつかの実施形態による、ログサービスで行われ得る制御プレーン動作態様を示すフロー図である。 少なくともいくつかの実施形態による、クライアントから受信されるトランザクション要求に応じてログサービスで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、それぞれの特例整合性目標を達成するために使用され得るトランザクション要求記述子の実施例を示す。 少なくともいくつかの実施形態による、ログベーストランザクションマネジャーで受信されるトランザクション要求に対応付けられた重複排除制約を施行する実施例を示す。 少なくともいくつかの実施形態による、ログベーストランザクションマネジャーで受信されるトランザクション要求に対応付けられた順序付け制約を施行する実施例を示す。 少なくともいくつかの実施形態による、複数の論理制約記述子を含むトランザクション要求記述子の実施例を示す。 少なくともいくつかの実施形態による、１つまたは複数の論理制約を示すトランザクション要求に応じてログサービスで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、それぞれのログ整合格納グループに対しそれぞれの価格設定ポリシーが実施され得る例示的システム環境を示す。 少なくともいくつかの実施形態による、単一データストア及びデータストア横断書き込み動作の実施例を示す。 少なくともいくつかの実施形態による、ログ整合格納グループに対する価格設定ポリシーを決定する際考慮され得る要素の実施例を示す。 少なくともいくつかの実施形態による、ログ整合格納グループを実施するサービスのユーザに対し価格設定ポリシーの選択肢を示すために使用され得る例示的ウェブベースインターフェースを示す。 少なくともいくつかの実施形態による、ログ整合格納グループに対応するサービスにて請求額を決定するために行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、トランザクション受諾のために読み出し位置ベース競合検出を使用することによりデータ不整合が生じ得る、格納システムにおける例示的一連イベントを示す。 少なくともいくつかの実施形態による、読み出し要求に応じて提供される読み出し記述子が読み出し再現性検証メタデータ（ＲＲＶＭ）コンポーネントを含むシステム環境を示す。 少なくともいくつかの実施形態による、読み出し記述子の例示的構成コンポーネントを示す。 少なくともいくつかの実施形態による、格納システムのクライアント側コンポーネントに読み出し記述子が提供される前に読み出し記述子に適用され得る例示的変換を示す。 少なくともいくつかの実施形態による、格納システムのクライアント側コンポーネントにおいて候補トランザクションコミット要求の生成を引き起こし得る例示的一連イベントを示す。 少なくともいくつかの実施形態による、書き込み記述子と読み出し記述子とをそれぞれのログに格納する例示的トランザクションマネジャーを示す。 少なくともいくつかの実施形態による、読み出し要求に応じて読み出し記述子が提供される、格納システムで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、候補トランザクション要求がクライアント側コンポーネントにて生成される、格納システムで行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、格納グループの異なるパーティションに対しそれぞれのログベーストランザクションマネジャーが確立され得る例示的システム環境を示す。 少なくともいくつかの実施形態による、格納グループの性能ベースのトランザクション管理構成の実施例を示す。 少なくともいくつかの実施形態による、所定のデータストアのために複数のログベーストランザクションマネジャーが確立され得る例示的構成を示す。 少なくともいくつかの実施形態による、格納グループの主要パーティションに対し確立されるログベーストランザクションマネジャーのログと共に、複数パーティションコミット判定レポジトリが共同配置される例示的構成を示す。 少なくともいくつかの実施形態による、複数パーティショントランザクションに対応する格納グループで生成され得るコミット要求の例示的構成要素を示す。 少なくともいくつかの実施形態による、ログベーストランザクションマネジャーにより単一パーティショントランザクションと複数パーティショントランザクションに関してそれぞれ格納され得るコミットレコードの例示的構成要素を示す。 少なくともいくつかの実施形態による、ログベーストランザクションマネジャーにより単一パーティショントランザクションと複数パーティショントランザクションに関してそれぞれ格納され得るコミットレコードの例示的構成要素を示す。 少なくともいくつかの実施形態による、クライアント側コンポーネントと、複数パーティショントランザクションに対応する格納グループのそれぞれのパーティションのログベーストランザクションマネジャーとにより行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態による、複数パーティショントランザクションに対応する格納グループの書き込みアプライヤにより行われ得る動作態様を示すフロー図である。 少なくともいくつかの実施形態において使用され得る例示的コンピューティングデバイスを示すブロック図である。

本明細書において、実施形態はいくつかの例示的実施形態及び例示的図面として説明さ
れるが、実施形態は説明される実施形態または図面に限定されないことを、当業者は認識
するであろう。図面とその詳細説明には、実施形態を開示される特定の形態に限定する意
図はなく、それとは逆に、添付の特許請求の範囲により定義される趣旨及び範囲に入る全
ての変更、均等物、及び代替案を包含する意図があることを理解されたい。本明細書にお
いて使用される見出しは、構成目的でのみ用いられ、説明または特許請求の範囲を限定す
るために用いられることを意図しない。本出願を通して使用される英単語“ｍａｙ”は、
義務的な意味（すなわち「〜しなければならない」という意味）ではなく、許容的な意味
（すなわち「〜する可能性がある」という意味）で使用される。同様に、英単語“ｉｎｃ
ｌｕｄｅ”、“ｉｎｃｌｕｄｉｎｇ”、及び“ｉｎｃｌｕｄｅｓ”は「含む」ことを意味
するが、その対象に限定されない。

グラフとして体系付けられた複製ノードを使用して分散アプリケーションステートを管
理する方法及び装置の様々な実施形態、及びトランザクション管理に使用され得るログサ
ービスを実施するためにこのようなグラフを展開する方法及び装置の様々な実施形態が説
明される。いくつかの実施形態によれば、フォールトトレラント分散アプリケーションを
築くための複製ステートマシンは、有向非巡回グラフ（ＤＡＧ）に配置された複数の複製
ノードを使用して実施され得る。いくつかの実施態様において、特定複製ＤＡＧは、１個
または複数の受諾ノードと、１個または複数のコミッタノードと、受諾ノードからコミッ
タノードまで導くＤＡＧ辺を含む複製経路に沿ってそれぞれ配置された０個または複数の
中間ノードと、ノード障害時に他の種類のノードのうちの１つの責務を素早く引き継ぐよ
うに構成された０個または複数の待機ノードとを含み得る。複製ＤＡＧの受諾、中間、及
び待機ノードは、本明細書において「非コミッタ」ノードとまとめて称され得る。「受諾
」、「中間」、「コミッタ」、及び「待機」は、ＤＡＧノードが担い得る役割の集合とし
てまとめて称され得る。いくつかの実施形態において、受諾ノードはＤＡＧの「先頭」ノ
ードとも称され、そしてコミッタノードは「末尾」ノードとも称され得る。

一般に、少なくともいくつかの実施形態において、特定複製ＤＡＧの各ノードは、少な
くとも特定アプリケーションのステート情報を、例えばローカルディスクまたは他の同様
の格納デバイスに書き込まれるステート遷移レコードの形態で複製する責務を担い得る。
アプリケーションステート情報は、本明細書において複製経路またはコミット経路と称さ
れるＤＡＧの受諾ノードからコミッタノードまで辺の集合に沿って伝播され得る。ＤＡＧ
内で伝播される各ステート遷移メッセージには、対応ステート遷移要求が（例えば受諾ノ
ードにおいて）処理された順序を示すそれぞれのシーケンス番号または論理タイムスタン
プが含まれ得る。シーケンス番号は、異なる実施形態における様々な技術のうちのいずれ
かを使用して実施され得る。例えば、受諾ノードにより保持される単一Ｎビットカウンタ
が使用され得る、あるいはＤＡＧの構成マネジャー等のＤＡＧの管理コンポーネントによ
り生成される単調増加論理タイムスタンプ（時刻機構に関連するとは限らない）が使用さ
れ得る。例えばステート遷移レコードの十分な数のレプリカが複製経路に沿って保存され
た後、特定ステート遷移レコードがコミッタノードに達すると、遷移は明示的または暗示
的にコミットされ得る。ある時点でのアプリケーションのステートは、いくつかの実施形
態において、選択されたシーケンス番号までの全てのコミットされたステート遷移の結果
の論理的蓄積として決定され得る。構成マネジャーは、後述のように構成デルタメッセー
ジを非同期的にＤＡＧノードへ伝播することにより、ＤＡＧ構成に対する変更を管理する
責務を担い得る（例えば障害のためノードがＤＡＧから離脱する、またはＤＡＧに参加／
再参加する時）。いくつかの実施形態において、各複製ノードはそれぞれの決定性有限ス
テートマシンを実施し、そして構成マネジャーは別の決定性有限ステートマシンを実施し
得る。ＤＡＧ構成変更を管理するために使用されるプロトコルは、様々な実施形態におい
てＤＡＧの可用性または「活性」を最大化するように設計され得る。例えば、ＤＡＧノー
ドは、少なくともいくつかの実施形態においてＤＡＧの構成に対するそれらの見解を同期
しなくてもよいため、複製経路沿いのノードのうちのいくつかが現行のＤＡＧ構成に対し
て他のノードとは異なる見解を有したとしても、アプリケーションステート遷移処理に使
用されるプロトコルは正常に機能し得る。従って、１つの単純な例示的シナリオにおいて
、ＤＡＧがノードＡ、Ｂ、Ｃ、Ｄの順序で構成される（すなわち複製経路Ａ〜Ｂ〜Ｃ〜Ｄ
を伴う）という仮定の下で、ＤＡＧの１つのノードＡはそのステート遷移処理責務を実行
し続ける一方、別のノードＤは、ノードＣがＤＡＧを離脱したという構成デルタメッセー
ジ結果を既に通知されたため、ＤのＤＡＧの見解を、変更後の経路Ａ〜Ｂ〜Ｄを含むもの
に更新したという場合もあり得る。現行のＤＡＧ構成に関してノードの見解が異なってい
る可能性があるにもかかわらず、構成マネジャーは、少なくともいくつかの実施形態にお
いてステート遷移ノードの処理を中断するようＤＡＧノードに要求しなくてもよい。従っ
て、いくつかのステート複製技術において要求され得る種々の「全世界停止」構成同期期
間は、本明細書において説明される類の複製ＤＡＧを使用する場合、必要なくなり得る。

大抵の作動条件の下で、ＤＡＧ構成変更情報を伝播するために使用される技術により、
様々なメンバーノードにおけるＤＡＧ構成の見解は最終的に収束した一貫性のあるものと
なり、同時に、ノード障害／退出、ノード参加、またはノード役割変更に伴ういずれの中
断時間も最小化または削除され得る。ステート管理プロトコルの正確性に関する正式な数
学的証明は、少なくともいくつかの実施形態に関して利用可能であり得る。少なくともい
くつかの実施形態において、複製ＤＡＧのプロトコルは、障害誤検出に対処する際、特に
有効であり得る。例えば、前述の実施例において、ノードＤは構成マネジャーにより、ノ
ードＣに実際障害は発生していないのに、ノードＣに障害が発生したことを通知され得た
。従って、誤判定障害検出の後しばらくの間、Ｃの退出を示す構成デルタメッセージがＡ
、Ｂ、Ｄに受信されるまでの間隔において、ステート遷移はＣにより（及びその隣接ノー
ドＢとＤにより）依然正しく処理されるため、ステートが複製中のアプリケーションは、
障害誤検出にもかかわらず進行可能となる。ＣがＤＡＧから削除されたことが最終的に通
知されると、Ｃは構成マネジャーにＣは実際にはサービス対応可能であることを示し、Ｄ
ＡＧに再参加することを許可され得る（例えば待機ノードとして、または修正された複製
経路沿いのいくつかの他の位置に）。

いくつかの実施形態において、受諾ノードは、複製ＤＡＧのクライアントからアプリケ
ーションステート遷移要求を受信し、最終的なコミットのために特定要求遷移を受諾する
べきか否かを判定し、受諾したステート遷移レコードのローカルレプリカを格納し、受諾
したステート遷移レコードをコミッタノードに向けてＤＡＧの複製経路沿いの隣接ノード
へ送信する責務を担い得る。使用事例により、ステート遷移レコードは、いくつかの実施
形態において書き込みペイロードを含み得る。例えばアプリケーションステートがデータ
ベースのコンテンツを含む場合、ステート遷移レコードは、ステート遷移に該当する遷移
間に書き込まれるバイトを含み得る。受諾ノードは、少なくともいくつかの実施形態にお
いて、受諾したステート遷移のシーケンス番号を決定または生成する責務も担い得る。中
間ノードは、受諾済みステート遷移レコードのローカルレプリカを格納し、受諾済みステ
ート遷移を示すメッセージを、コミッタノードに向けて経路沿いの次のノードへ送信／転
送する責務を担い得る。コミッタノードは、ステート遷移レコードの自身のレプリカを、
例えばレコードがコミットされたことの開示と共に、ローカル格納域に格納し得る。対応
ステート遷移がコミットされたことを示すレコードは、本明細書において「コミットレコ
ード」と称され、一方対応ステート遷移が受諾されたが必ずしも既にコミットされたとは
限らないことを示すレコードは「受諾レコード」と称され得る。いくつかの実施形態にお
いて、アプリケーションの必要に応じて、コミッタノードは、ステート遷移を要求したク
ライアントに対し（例えば受諾ノードを介して）コミット応答の送信を開始し得る。少な
くとも一実施形態において、コミッタノードは、ステート遷移がコミットされたことを、
複製経路沿いの一部または全てのノードに通知し得る。いくつかの実施形態において、コ
ミットの開示がＤＡＧノードで受信されると、コミットレコードを現在示すように、現在
コミットされたステート遷移の受諾レコードは、対応コミットレコードに置き換え、また
は修正され得る。別の実施形態において、所定のＤＡＧノードは、同じステート遷移に関
して受諾レコードとコミットレコードの両方を、例えばそれぞれのシーケンス番号と共に
格納し得る。いくつかの実施態様においては、別個のコミットレコード集合と受諾レコー
ド集合とが様々なＤＡＧノードのローカル格納域に格納され、一方別の実施態様において
は、所定のステート遷移に関して１度に１種類のレコード（受諾またはコミット）のみが
所定のＤＡＧノードに格納され得る。

構成マネジャーは、いくつかの実施形態において、ＤＡＧの構成情報の正式な情報源と
して設計され、ＤＡＧ構成に対する変更を受諾し、ＤＡＧノードに対する変更を伝播する
責務を担い得る。少なくともいくつかの実施形態において、構成マネジャー自体は、障害
に対し回復力があるように、例えばＤＡＧ構成変更（ノードの削除または追加等）を、合
意を介して集合的に承認し、かつ複数の構成マネジャー格納デバイスにおいてＤＡＧ構成
を複製するノードのフォールトトレラントクラスタとして、設計され得る。「構成デルタ
」という名称から暗示されるように、構成マネジャーによりＤＡＧノードへ送信されるメ
ッセージは、特定の変更（例えばＤＡＧに参加するまたはＤＡＧから離脱するノードによ
り生じる変更、あるいはＤＡＧの既存ノードの役割／配置に関する変更）の開示のみを含
み、ＤＡＧの構成全体の表現を含まなくても、またはＤＡＧのメンバー全体を列挙しなく
てもよい。構成デルタメッセージの所定の受信ノードは従って、これまで受信した特定集
合または一連の構成デルタメッセージに基づいて、ＤＡＧ構成の自身の見解を構築するこ
とが見込まれ得る。いくつかの実施態様において、構成デルタメッセージにはシーケンス
番号も割り当てられ、例えばこれにより、構成デルタメッセージの受信ノードは、全ての
前の構成デルタメッセージを自身が受信したか否かを判定可能となる。構成マネジャーは
、別個のＤＡＧノードにより構成デルタメッセージが受信される順序または相対的タイミ
ングを保証しようと試み得ないため、いくつかの実施形態において、前述の実施例により
示されるように少なくともある時間、別個のノードによりＤＡＧ構成の現行の見解は異な
り得る。

一実施形態によれば、構成デルタメッセージに応じてＤＡＧノードが取る行動は、構成
変更が受信ノードのすぐ隣のノードに影響するか否かに基づいて異なり得る。ＤＡＧが、
Ｔ０時点に受諾ノードＡ、中間ノードＢ、及びコミッタノードＣを含み、初期複製経路Ａ
〜Ｂ〜Ｃを有する別の例示的シナリオを検討する。Ｔ１時点に、ＤＡＧの構成マネジャー
ＤＣＭ１は、例えば見かけ上の障害または接続損失の結果より、ＢがＤＡＧから離脱した
ことを認識する。ＤＣＭ１は、ステート遷移要求処理におけるいかなる中断も要求するこ
となく、残りのノードＡ、Ｃに対しそれぞれの非同期構成デルタメッセージＤ１、Ｄ２を
それぞれ送信し得る。ＡがＴ３時点にＤ１を受信する前に、ＣがＴ２時点にＤ２を受信す
る場合、ある時間間隔（Ｔ３−Ｔ２）においてＡはＢに対してステート遷移メッセージを
送り続け得る（しかしＮに実際に障害が起こった場合、Ａが送信したメッセージはＢによ
り処理され得ない）。同様に、ＣがＴ３時点にＤ２を受信する前に、ＡがＴ２時点にＤ１
を受信する場合、ＤＡＧからＢの離脱をＣが認識するまでのある時間（Ｔ３−Ｔ２）、Ｃ
は、Ｂに障害が起こった時に送信過程にあったメッセージをＢから受信し、処理し続け得
る。ノードＡがＤ１を受信した時に、ＡはＣから連絡をまだ受けていない場合、ノードＡ
は、古い複製経路（Ａ〜Ｂ〜Ｃ）に置き換わる新たな構成の複製経路（Ａ〜Ｃ）において
Ａの新たな隣接後続ノードとなるＣに対し、接続を確立し得る。同様に、ＣがＤ２を受信
した時に、Ｃは自身の新たな隣接先行ノードとなるＡに対し接続を確立し（ＡがＣにまだ
連絡を取っていない場合）、そして少なくともいくつかの実施形態において、ＡからＢへ
送信されたがまだＣに届いてないステート遷移レコードの再送信の要求を、ＣはＡに提出
し得る。例えば、Ｃは再送信要求内に、これまでＣが受信済みのステート遷移レコードの
最大シーケンス番号ＨＳＮ１を含ませ、これによりＡは、ＨＳＮ１より大きいシーケンス
番号を有するいずれのステート遷移レコードも再送可能となる。

少なくともいくつかの実施形態において、構成マネジャーは、正常性検出機構またはＤ
ＡＧノードが見かけ上不正常になった時を示すサービスに依拠しており、これによりＤＡ
Ｇ構成から見かけ上不正常なノードは除去され得る。分散環境における少なくともいくつ
かの正常性検出機構は、ノードの正常性ステータスに関して必ずしも正しい判断をすると
は限らないハートビートまたは他の低次機構に依存し得る。同時に、構成マネジャーは、
その構成デルタメッセージを送信する前に、実際のノード障害を確認するのをいつまでも
待機する立場にはあり得ず、代わりに構成マネジャーは、ノード障害の可能性がある閾値
（例えば８０％または９０％）を超えると判定した際、構成デルタメッセージを送信し得
る、あるいはいくつかの他のヒューリスティックを使用してＤＡＧ構成変更及び対応デル
タメッセージを引き起こし得る。前述のように、複製ＤＡＧにおいて使用されるステート
管理プロトコルは、例えば「全世界停止」中断を回避することにより、誤判定障害「検出
」の悪影響を緩和し得る。その結果、他のステート複製技術が使用された場合に容認され
たであろう障害検査機構よりも、より迅速／安価な（しかし信頼性は低い可能性のある）
障害検査機構が、複製ＤＡＧ採用時には使用可能となり得る。

少なくとも一実施形態において、整合一時停止技術が複製ＤＡＧに実施され得る。ある
条件の下、例えば複数のＤＡＧリソースまたはノードが関わる大規模障害イベントが検出
された場合、構成マネジャーは、ＤＡＧの生き残ったノードに対し、さらなるステート遷
移の処理を停止し、それらのアプリケーションステート情報をお互いに同期し、同期され
たアプリケーションステート情報をそれぞれの格納位置に格納し、再開命令を待つように
指示し得る。いくつかの実施態様において、アプリケーションステートをローカルに保存
した後、ＤＡＧノードはそれぞれ、クリーンシャットダウン及び再始動を実行し、再始動
後に構成マネジャーに対し、自身がサービス対応可能であることを示す報告を行い得る。
構成マネジャーにより一時停止命令が発行される前に障害が発生したノードがサービス対
応可能であることを報告した場合、いくつかの実施形態において、構成マネジャーは、そ
のようなノードに対しそのアプリケーションステートを、アプリケーションステートが最
新であるとわかっている（例えば構成マネジャーにより）別のノードと同期するように指
示し得る。構成マネジャーは、十分な数のノードが（ａ）サービス対応可能となり、（ｂ
）アプリケーションステートに関して最新になるまで待機し、（新しい可能性のある）Ｄ
ＡＧ構成を決定し、ＤＡＧ構成のメンバーノードに対しＤＡＧ構成を示す再開メッセージ
を送信することでＤＡＧを再開し得る。いくつかの実施形態において、このような制御さ
れ整合された一時停止／再始動戦略により、大規模障害イベントの後、このような戦略が
ない場合に可能であり得るアプリケーション回復と比べて、より迅速で信頼性の高いアプ
リケーション回復が可能となる。整合一時停止手法は、例えば複数の複製ノードからのア
プリケーションステート情報の高速並列バックアップ／スナップショットのためといった
、大規模障害に応じること以外の目的にも使用され得る。

前述の種類のＤＡＧベースの複製ステートマシンは、様々な実施形態における様々な異
なるアプリケーションを管理するために使用され得る。いくつかの実施形態において、ロ
グサービスが実施され、当該ログサービスでは、１つまたは複数のデータストア（例えば
リレーショナルまたは非リレーショナルデータベース）が、複製ＤＡＧを使用して実施さ
れる持続的変化ログのインスタンスを介して、トランザクション管理に登録され得る。後
でさらに詳しく説明されるように、いくつかの実施形態において、楽観的並行処理制御機
構がこのようなログベーストランザクションマネジャーにより使用され得る。ログサービ
スのクライアントは、所定のトランザクション内で、１つまたは複数のソースデータスト
アに対し読み出し動作を行い、書き込み動作を行う（例えば読み出しの結果に基づいて）
１つまたは複数のデータストア位置を特定し得る。読み出し集合、書き込み集合、並行処
理制御要件、及び／またはトランザクションに対する論理制約の表現を含むトランザクシ
ョン要求記述子は、ログサービスの競合検出器（例えば対応複製ＤＡＧの受諾ノードに対
応付けられる競合検出論理）へ提出され得る。競合検出器は、前にコミットされたトラン
ザクションのレコードをトランザクション記述子のコンテンツと一緒に使用して、コミッ
トのためにトランザクション要求の受諾可能か否かを判定し得る。コミットのためにトラ
ンザクションが受諾されると、ログ用に確立されたＤＡＧの複数の複製ノードにおいて、
対応コミットレコードの複製が開始され得る。従って、ログの所定レプリカに挿入される
レコードは各自、それぞれのアプリケーションステート遷移を表し得る。重複排除要件、
トランザクション間コミット順序付け要件等、いくつかの異なる論理制約は、異なる実施
形態において特定され、ログベーストランザクションマネジャーにより施行され得る。こ
のようなログベーストランザクション管理機構により、いくつかの実施形態において、例
えば基礎データストアは複数の書き込みを伴うトランザクションの原子性にネイティブに
対応し得ないにもかかわらず、所定のトランザクションの書き込み集合に複数の書き込み
位置が含まれる複数アイテムトランザクションまたは複数データベーストランザクション
に対する対応が可能となり得る。コミット済みトランザクションに対応する書き込みは、
少なくともいくつかの実施形態において、非同期的に関連データストアへ適用され得る。
例えばトランザクションがコミットされたレコードは、対応書き込みが対象データストア
に伝播される前のある時に、持続的変化ログに保存され得る。持続的変化ログは従って、
少なくともいくつかの実施形態においてアプリケーションステートの正式な情報源となり
、データストアは、当該ログがステート変更を記録した後に、アプリケーションステート
に追いつき得る。

複製ＤＡＧは、様々な実施形態において、複製データベースインスタンス、高スループ
ットデータストリーム管理、及び／または分散ロック管理のためにも使用され得る。いく
つかの実施形態において、複製ＤＡＧは、演算インスタンス等の仮想リソースに対するス
テート変更を管理するために、プロバイダネットワーク内で使用され得る。少なくともい
くつかの実施形態において、登録済みデータストア（書き込みの結果がデータストアのそ
れぞれの読み出しインターフェースを介して読み出し可能である）に対しコミット済みの
書き込みを伝播することに加えて、ログサービスも自身の個別のアクセスインターフェー
スを定義及び実施し得るため、これにより関心のあるクライアントは、持続的ログインス
タンスから直接、所定のクライアントアプリケーションのために格納されたレコードの少
なくとも一部を読み出すことが可能になる。

例示的システム環境
図１は、少なくともいくつかの実施形態による、アプリケーションステート変更を管理
するために複製ノードの動的ＤＡＧ（有向非巡回グラフ）が確立された例示的システム環
境を示す。示されるように、システム１００において、アプリケーション１６０のステー
ト遷移を管理するために確立された複製ＤＡＧ１４０は、受諾ノード１１０、中間ノード
１１２、コミッタノード１１４の３つのノードを含む複製経路を備える。さらにＤＡＧ１
４０は、描かれた実施形態において、必要があれば他のノードのうちのいずれかの責務を
引き継ぐことが可能な待機ノード１３０を含む。他の複製ＤＡＧには、他の組み合わせの
ノードが配置され得る。例えば、いくつかのアプリケーションには複数の中間ノードが使
用され得るが、他のアプリケーションには中間ノードは全く使われ得ない、あるいは待機
ノードは確立され得ない。ＤＡＧ１４０の構成に対する変更は、後述のように、フォール
トトレラントＤＡＧ構成マネジャー（ＤＣＭ）１６４により整合され得る。

受諾ノード１１０は、描かれた実施形態において、ＡＰＩ（アプリケーションプログラ
ミングインターフェース）等の１つまたは複数のプログラム的インターフェースを介して
、アプリケーションステート遷移要求（ＳＴＲ）１５０を受信し得る。受諾ノード１１０
は、アプリケーション従属規則または論理を使用して、要求遷移を最終的コミットのため
に受諾し得る、あるいは要求を拒否し得る。遷移が受諾されると、例えば他の受諾された
遷移に対して当該遷移が受諾された順序を示す、シーケンス番号が受諾ノード１１０によ
り生成され得る。前述のように、いくつかの実施形態において、シーケンス番号は、受諾
された遷移ごとに増加するカウンタを含み、一方別の実施形態においては、構成マネジャ
ーにより提供される論理クロックまたはタイムスタンプ値が使用され得る。対応シーケン
ス番号を含むアプリケーションステートレコード（ＡＳＲ）１７２Ａの集合１７６Ａは、
受諾ノードによりローカル持続的格納域に格納され得る。いくつかの実施形態において、
アプリケーションステートレコードは、遷移受諾レコードと遷移コミットレコードの両方
を含み得る（コミットレコードは、対応遷移がコミッタノードによりコミットされたこと
が受諾ノードに通知された後にのみ格納される）。別の実施形態においては、複製経路沿
いの少なくともいくつかのノードが受諾レコードのみを格納し得る。受諾を示すステート
遷移レコードを格納した後、受諾ノードは、承認を示すステート遷移メッセージ（ＳＴＭ
）１５２Ａを、例示構成における中間ノード１１２といった複製経路沿いの自身の後続ノ
ードに送信し得る。中間ノードは、対応ＡＳＲの自身のコピー１７２Ｂをシーケンス番号
と共に、そのローカルＡＳＲ集合１７６Ｂに格納し得る。中間ノードは、自身のＳＴＭ１
５２Ｂを、現行複製経路沿いの自身の隣接ノードに、例えば描かれた実施形態におけるコ
ミッタノード１１４に、送信し得る。少なくともいくつかの実施態様において、ＳＴＭ１
５２は、どのノードがＡＳＲのレプリカを既に格納済みかを示す開示を含み得る。例えば
メッセージ１５２Ｂは、受諾を示すアプリケーションステートレコードのそれぞれのレプ
リカがノード１１０、１１２にそれぞれ既に格納済みであることを、コミッタノードに示
し得る。

アプリケーションステートレコードの十分な数のレプリカが格納されたというコミッタ
ノードにおける判断に応じて（十分なレプリカの正確な数はアプリケーション１６０の構
成パラメータであり得る）、遷移がコミットされ得る。コミッタノードのＡＳＲ集合１７
６Ｃは、描かれた実施形態において、トランザクションコミットのレコードを含み得る（
承認の相対として）。従ってＡＳＲ１７２Ｃは、単なる受諾ではなくコミットを示し得る
。少なくともいくつかの実施形態において、コミッタノード１１６は、遷移がコミットさ
れたことを示す開示または通知を、受諾ノード及び／または中間ノードへ送信し得る。別
の実施形態において、受諾及び／または中間ノードは、どの遷移がコミットされたかを特
定するためにコミッタノード１１６に対し要求を提出し（例えば定期的に）、それらのＡ
ＳＲ集合を適宜更新し得る。いくつかのアプリケーションに関して、明示的コミットは必
要とされ得ないため、コミットの開示は何も格納され得ず、よって経路沿いのそれぞれの
ＤＡＧノードは、受諾を示すそれぞれのアプリケーションステートレコードを単純に格納
し得る。描かれた実施形態において、コミット後ＳＴＭ１５４がコミッタノードから待機
ノード１３０へ送信され、これにより待機ノードはそのＡＳＲ集合１７６Ｄを更新可能と
なるため（例えばコミットＡＳＲ１７２Ｄを格納することで）、別のＤＡＧノードを置き
換えるように待機ノードが有効化される場合には、そのアプリケーションステート情報が
コミッタノードのものと一致する。待機ノードが最新のコミット済みアプリケーションス
テートと常に同期しているという事実から、構成マネジャーは、いくつかの実施形態にお
いて他の３種類の役割のうちのいずれかに、例えば受諾ノード、中間ノード、またはコミ
ッタノードとして、待機ノードを迅速に有効化することが可能になり得る。

フォールトトレラントＤＡＧ構成マネジャー（ＤＣＭ）１６４は、描かれた実施形態に
おいて必要に応じて、ＤＡＧ構成またはＤＡＧメンバーに対する変更を、構成デルタメッ
セージ１６６（例えばメッセージ１６６Ａ、１６６Ｂ、１６６Ｃ、１６６Ｄ）の形でＤＡ
Ｇノードに伝播する責務を担い得る。例えば、障害の結果等で所定のＤＡＧノードがＤＡ
Ｇ１４０を離脱する場合、ＤＣＭ１６４により１つまたは複数の生き残ったノードに対し
、対応構成デルタメッセージ１６６が送信され得る。同様に、新たなノードがＤＡＧに参
加する場合（例えば障害からの復旧後、またはアプリケーション１６０の耐久レベルを向
上させるために）、参加イベント、ＤＡＧ内の参加ノードの位置、及び／または参加ノー
ドに与えられた役割（例えば受諾、中間、コミッタ、または待機）を示す対応構成デルタ
メッセージが、ＤＣＭによりＤＡＧの１つまたは複数の現行メンバーノードに対し送信さ
れ得る。構成デルタメッセージ１６６は、お互いに関して非同期であり、アプリケーショ
ンステートの全体的複製に影響せずに、任意の順序でそれらの対象により受信され得る。
ＤＡＧの各ノードは、受信した構成デルタメッセージに基づいて、他のノードが持ち得る
構成見解１７４とは関係なく、ＤＡＧ構成の自身の見解１７４を構築する責務を担い得る
。従って、例えば、それぞれのノード１１０、１１２、１１４、１３０にて受信される別
個の構成デルタメッセージの相対的順序及び／またはタイミングのため、いくつかの実施
形態において、構成見解１７４Ａ、１７４Ｂ、１７４Ｃ、１７４Ｄのうちの１つまたは複
数は、少なくともある短い時間間隔において異なり得る。少なくともいくつかの実施形態
において、各ＤＡＧノードは、それぞれのローカル構成変更レポジトリにおいて受信され
る複数の構成デルタメッセージの表現またはコンテンツを格納し得る。描かれた実施形態
において、ＤＣＭ１６４は、ＤＡＧノードによるアプリケーションステート処理において
全世界一時停止を施行し得ない。例えばこれにより、ノードは、構成デルタメッセージの
タイミングまたは基礎ＤＡＧ構成変更に関係なく、アプリケーションステート遷移メッセ
ージを受信または処理し続けることが可能になり得る。ＤＡＧノードが構成デルタメッセ
ージに応じる方法の実施例は、図２ａ〜２ｈを参照して後述される。

図１は、各種類のノードを１つずつ含む単一線複製経路または「チェーン」を有するＤ
ＡＧを示すが、少なくともいくつかの実施形態において複製ＤＡＧは、分岐経路及び／ま
たは各役割に対し複数のノードを含み得ることに留意されたい。すなわち、いくつかの受
諾、中間、コミッタ、及び／または待機ノードが同一ＤＡＧ内に共存し、そしてＤＡＧの
複製経路は、結合ノード（複数の先行ノードから遷移要求を受信するノード）、または分
割ノード（遷移要求を複数の後続ノードに送信するノード）を含み得る。受諾ノード１１
０またはコミッタノード１１６のどちらかが要求されたステート遷移を拒否する場合（例
えば受諾ノードがアプリケーション特有受諾基準の集合を満たさないと判定したため、ま
たはコミッタノードが受諾済みステート遷移要求メッセージを受信する時までに受諾済み
遷移の十分な数のレプリカが作られていなかったため）、いくつかの実施形態において、
遷移を要求したクライアントに遷移がコミットされなかったことが通知され得る。クライ
アントはその後、遷移を再試行し得る（例えば別のステート遷移要求を提出することによ
り）、あるいは要求を完全に放棄することに決め得る。いくつかの実施態様において、中
間ノードもまた遷移要求をアボートすることが許され得る。

図２ａ〜２ｈは、少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つ
に障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を
示す。図２ａは、３つのノード２０２Ａ、２０２Ｂ、２０２Ｃを含むＤＡＧ構成の初期状
態を示す。ステート遷移要求（ＳＴＲ）１５０がノード２０２Ａにて受信される。受諾済
みステート遷移レコードが、ノード２０２Ａ（ＳＴＲのローカル承認後）及びノード２０
２Ｂ（ノード２０２Ｂが承認済みＳＴＭ２１１Ａを受信後）にて複製され、２０２Ｃにて
（ノード２０２Ｃが承認済みＳＴＭ２１１Ｂを受信後）コミットされる。ＤＣＭ１６４は
、ノード２０２Ｂに障害が発生した様子であることを示す正常性ステータス更新情報２５
０を受信し得る。ノード２０２Ｂのステータスに関する正常性ステータス更新情報は、異
なる実施形態において、様々な情報源のうちのいずれかから、例えば他のノード（２０２
Ａまたは２０２Ｂ）のうちの１つから、またはＤＡＧの外部の正常性監視サービス（例え
ばＤＡＧノードがインスタンス化されたプロバイダネットワークに確立された汎用リソー
ス正常性監視サービス）から、受信され得る。少なくとも一実施態様において、正常性ス
テータス更新情報は、ＤＡＧノードにハートビートメッセージを定期的に送信して、複数
の連続ハートビートメッセージに対し許容時間窓内に何も応答が受信されない場合には所
定ノードは非正常状態にあると判定する監視プロセス等、ＤＭＣ１６４自身のサブコンポ
ーネントにより生成され得る。

描かれた実施形態において、ＤＣＭ１６４は、正常性ステータス更新情報に基づいて、
ノード２０２ＢはＤＡＧから削除されるべきであること、そして新たなノード２０２Ｄが
ノード２０２Ｃの後続ノードとして追加されるべきであることを決定し得る。新たなノー
ドには、例えばＤＡＧの新コミッタノードとして有効ステータスに昇格された待機ノード
が含まれ得る。ＤＡＧの新構成（すなわちＤＡＧは現時点で複製チェーン２０２Ａ〜２０
２Ｃ〜２０２Ｄを含むべきであること）を決定し、新構成の表現を持続的レポジトリに保
存した後、ＤＣＭ１６４はノード２０２Ｄに対し、ノード２０２Ｃの後続ノードとしてＤ
ＡＧに参加するよう命令２４１を発行し得る。少なくともいくつかの実施形態において、
２０２Ｂ等のノードのＤＡＧからの削除は、必ずしも置き換えノードの即時追加を伴うと
は限らず（特に削除が行われた後に経路上に残り接続状態のままのＤＡＧノードの数が、
ステートが複製中のアプリケーションにより必要となる最小ノード数を超える場合）、ノ
ード２０２Ｄの追加は、ＤＣＭがノード障害（または少なくとも見かけ上のノード障害）
に応じ得るやり方の１つとして単純に例示されることに留意されたい。図２ｂにおいて示
されるように、ノード２０２Ｂに実際障害は発生していなかった（すなわち２０２Ｂの障
害に関して正常性更新情報は誤っていた）という場合もあり得る。このような誤判定シナ
リオにおいて、ステート遷移メッセージは、２０２Ａから２０２Ｂへ、そして２０２Ｂか
ら２０２Ｃへ送信され続け、これによりアプリケーションは、ＤＣＭ１６４による削除判
定後少なくともしばらくの間、進行し続けることができる。

少なくともいくつかの実施形態において、２０２Ｂ等のノードはＤＡＧから削除され、
削除されたノードの隣接後続ノード（例えば２０２Ｃ）がＤＡＧに残る場合、削除された
ノードに以前割り当てられていた役割は、隣接後続ノードに委譲され得る。従って、コミ
ッタノードであり得たノード２０２Ｃは、ノード２０２Ｂの離脱に際し中間ノードとなり
、新たに有効化されたノード２０２Ｄは新コミッタノードに選定され得る。削除されたノ
ードが隣接後続ノードを有さない場合（例えば描かれた実施例においてノード２０２Ｂの
代わりにノード２０２Ｃが削除された場合）、いくつかの実施形態において、削除された
ノードに割り当てられていた役割が、新たに有効化された待機ノードに与えられ得る。別
の実施形態において、役割はこのような順序的／直鎖的方法で委譲され得ない。例えば構
成マネジャーは、削除されたノードと差向うノードの相対位置を考慮せずに、どの役割が
所定ノードに与えられるべきかを決定し得る。

ノード２０２ＢがＤＡＧから削除されるべきと判定した後、描かれた実施形態において
、ＤＣＭ１６４は、それぞれの非同期構成デルタメッセージ２４２Ａ、２４２Ｂをノード
２０２Ａ、２０２Ｃへ送信し得る。示されるように、それぞれのデルタメッセージは、２
０２ＢがＤＡＧを離脱し、２０２Ｄが参加したことを示し得る。描かれた実施形態におい
て、構成に関する２つの変更が単一の構成デルタメッセージ内に示されるが、別の実施形
態においては、２０２Ｂの削除と２０２Ｄの参加に関して個別の構成デルタメッセージが
送信され得る。描かれた実施形態において、構成デルタメッセージは、ＤＡＧ構成に対す
る変更のみを示し、ＤＡＧの構成全体の表現を含み得ない。ノード２０２Ａが構成デルタ
メッセージ２４２Ａを受信するまで、あるいは２０２ＢはＤＡＧから離脱したことを認識
するまで（例えばネットワーク接続の終了により）、ノード２０２Ａからノード２０２Ｂ
に対しＳＴＭは送られ続け得る。２０２Ｂに実際障害は発生していなかったというシナリ
オにおいて、ノード２０２Ｂは、ＤＡＧから削除されたことを認識する（例えば２０２Ａ
または２０２Ｃが２０２Ｂと通信停止した場合）まで、ステート遷移要求を処理し、メッ
セージ２１１Ｂをノード２０２Ｃへ送信し続け得る。

構成デルタメッセージ２４２は、非同期メッセージ機構を使用して送信されるため、そ
れらの送信先に異なる時間に到着し得る。ノード２０２Ｃが構成デルタメッセージ２４２
Ｂを受信する前にノード２０２Ａが構成デルタメッセージ２４２Ａを受信する場合、図２
ｄに描かれるシナリオが達成され得る（ＤＡＧは少なくとも一時的に岐路を含む）。メッ
セージ２４２Ａに応じて、ノード２０２Ａは、構成変更の開示をローカル格納域に保存し
、その後いかなるメッセージもノード２０２Ｂに送信することを停止し得る。さらに、ノ
ード２０２Ａは、自身の新後続ノードは２０２Ｃであると判断し、よってノード２０２Ｃ
とのネットワーク接続を確立し、新たなステート遷移メッセージ２１１Ｃをノード２０２
Ｃに送信することを開始し得る。描かれた実施形態において、２０２Ｂの削除を示すメッ
セージが残りのノードに届くとともに、ＤＡＧの様々なノードでステート遷移処理活動が
継続され得る。例えば、ノード２０２Ｂに障害が起こったと思われたが実際は正常に機能
し続けていたというシナリオにおいて、ノード２０２ＢがＤＡＧから削除されたというこ
とをノード２０２Ａが知らされた後でも、ノード２０２Ａから送信過程にあった１つまた
は複数のステート遷移メッセージは、ノード２０２Ｂにて受信され得る。このような送信
過程メッセージを受信すると、ノード２０２Ｂは、メッセージ内に示されるステート遷移
情報をローカル格納域に複製し、別の同様のＳＴＭをノード２０２Ｃへ送信しようと試み
得る。ノード２０２Ｃがノード２０２Ｂの削除をまだ知らない（または少なくともノード
２０２Ｂとの自身の接続をまだ閉じていない）場合、ノード２０２Ｃはノード２０２Ｂか
らのメッセージを受信し、処理し得る。これにより、構成マネジャーによりノード２０２
ＢはＤＡＧ構成から削除されたものの、アプリケーションは進行可能となる。

ノード２０２Ａが構成デルタメッセージ２４２Ａを受信する前にノード２０２Ｃが構成
デルタメッセージ２４２Ｂする場合、図２ｅに例示されるシナリオが達成され得る。メッ
セージ２４２Ｂを受信すると、ノード２０２Ｃは、ノード２０２Ｂから送信される新規メ
ッセージを受信することを停止し得る（例えばノード２０２Ｂとの自身の接続がまだ使用
可能である場合は、当該接続を終了することにより）。ノード２０２Ｃは、ノード２０２
ＡがＤＡＧ経路における自身の新たな隣接先行ノードであると理解すると、ノード２０２
Ａへの接続を確立し得る。ノード２０２Ｃはまた、描かれた実施形態において、最大シー
ケンス番号ＨＳＮ１を特定し（ノード２０２Ｃが既に受信した承認済みＳＴＭのシーケン
ス番号の中から）、２０２Ｃが受信し損なった可能性のある全ての承認済みステート遷移
メッセージ（すなわちＨＳＮ１より大きいシーケンス番号を有する全ての承認済みＳＴＭ
）を再送するようにノード２０２Ａへ要求２６０を送信し得る。さらに、ノード２０２Ｃ
はまた、自身の新後続ノード２０２Ｄへの接続を確立し、続く承認済みＳＴＭ２１１Ｄを
ノード２０２Ｄへ送信することを開始し得る。

２０２Ａと２０２Ｃの両ノードがＤＡＧ構成変更について通知された後、図２ｆに例示
されるＤＡＧの新たな複製経路（すなわち２０２Ａ〜２０２Ｃ〜２０２Ｄ）が、新たに受
信されるステート遷移要求に使用され得る。構成デルタメッセージ２４２のタイミングの
ため、ノード２０２Ａが構成デルタメッセージ２４２Ａを受信する前に、ノード２０２Ａ
はノード２０２Ｃから構成変更を知らされる場合もあり得ることに留意されたい。同様に
、いくつかの実施形態において、ノード２０２Ｃは、ノード２０２Ａから（またはノード
２０２Ｄからでも）新構成について知らされ得る。従って、新構成に関する情報がＤＡＧ
のいずれかの所定ノードに到達し得る方法は複数あり、少なくともいくつかの実施形態に
おいて、構成デルタメッセージがそれらの全ての対象受信ノードに到達する前でも、ＤＡ
Ｇノードは新複製経路を部分的に使用開始し得る。

図２ｇに示されるように、ノード２０２Ｂは、ＤＡＧから削除された後（例えば実際の
障害により、または誤判定障害検出により）のある時点で、ＤＣＭ１６４に対し自身はサ
ービス開始可能であることを任意で示し得る。例えば、実際の障害の場合、ノード２０２
Ｂは最終的に修復され再始動され、「サービス対応可能」メッセージ２８０を送信する前
に復旧動作のある集合を実行し得る。ネットワーク接続損失の場合、「サービス対応可能
」メッセージは、接続が再確立された後に送信され得る。これに応じて、描かれた実施形
態においてＤＣＭ１６４は、ノード２０２ＢをＤＡＧの待機ノードとして追加し直すこと
を決定し得る。従って、図２ｈに示されるように、ＤＣＭは、参加コマンド２８２をノー
ド２０２Ｂへ送信し、新たな構成デルタメッセージ集合２４４Ａ、２４４Ｂ、２４４Ｃを
ノード２０２Ａ、２０２Ｂ、２０２Ｄへそれぞれ送信してノード２０２Ｂの追加をそれら
に通知し得る。図２ａ〜２ｈに例示される一連動作は実施例として提供されており、そし
てＤＡＧノード及びＤＣＭは、様々な実施形態においてノード２０２Ｂの見かけ上の障害
に応じて、図２ａ〜２ｈに例示される一連動作と異なる一連動作を実行し得ることに留意
されたい。例えば、いくつかの実施形態において、ノード２０２Ｃの後続ノードとしてＤ
ＡＧに新たなノードは何も追加され得ない。また、いくつかの実施形態において、ノード
２０２Ｂは、サービス対応可能になった後に必ずしも同じＤＡＧに再参加するとは限らず
、代わりに例えば、異なるＤＡＧへ配置され得る、あるいは新たなＤＡＧを構成する際使
用され得るノードのプールに保持され得る。

図２ａ〜２ｈにおいて障害検出がＤＡＧ構成変更を引き起こすように示されるが、通常
、様々な実施形態において、多数の異なる考察のうちのいずれかにより、ＤＡＧ構成の修
正はもたらされ得る。例えば、アプリケーションオーナー（またはＤＣＭ）は、データ耐
久性を向上するために、または可用性の理由で、ＤＡＧに対しノードを追加することを決
定し得る。新たなノードの追加を示す構成デルタメッセージは、ステート遷移処理におい
て「全世界停止」中断を要求することなく、いくつかの実施形態において前述される削除
関連伝播と同様の非同期的方法で他のＤＡＧノードに伝播され得る。ＤＡＧノードは、い
くつかの実施形態において、メンテナンス関連理由で、例えばソフトウェアのアップグレ
ードのため、ソフトウェアエラーのデバッグのため、またはハードウェア修正のために、
経路から外される必要があり得る。少なくとも一実施形態において、ノードのうちの１つ
または複数における作業負荷レベル（例えば毎秒処理されているステート遷移数）は閾値
レベルに達しており、現在使用されているものより性能の高い（または性能の低い）ハー
ドウェア／ソフトウェアスタックが使用されるべきであるという判定の結果、ＤＡＧの構
成は変更され得る。いくつかの実施形態において、ＤＡＧ構成変更は、必ずしもノードを
追加または削除することなく、特定のＤＡＧノードの位置または役割を変更することを伴
い得る。例えば、構成マネジャーは、コミッタの役割を前に中間ノードだったノードに転
嫁し、元コミッタノードを新構成における中間ノードに仕上げ得る。このような役割変更
は、例えば、負荷分散目的で、特にいくつかの異なるＤＡＧのノードに対し同一ホストが
使用されているマルチテナント環境において、実施され得る（そして対応構成デルタメッ
セージが伝播され得る）。このようなマルチテナント環境は、さらに詳しく後述される。

ステート遷移レコードと構成デルタメッセージ
図３は、少なくともいくつかの実施形態による、動的複製ＤＡＧにて生成され得るアプ
リケーションステートレコード（ＡＳＲ）とＤＡＧ構成デルタメッセージとの例示的コン
ポーネントを示す。前に示されたように、少なくともいくつかの実施形態において、それ
ぞれが承認済みまたはコミット済みステート遷移を表現するアプリケーションステートレ
コードのコピーは、ＤＡＧの複製経路沿いのいくつかのノードのそれぞれに格納され得る
。アプリケーションステートレコードは、本明細書においてステート遷移レコードとも称
され得る。示されるように、アプリケーションステートレコード３２０には、例えば、要
求されたステート遷移の承認が記録されているか否か、または承認済みステート遷移のコ
ミットが記録されているか否かといった遷移の種類３０２の開示が含まれ得る。いくつか
の実施形態において、前述のように、各ＤＡＧノードは承認及びコミットレコードの両方
を格納し、一方別の実施形態においては、１種類のステート遷移レコードのみが格納され
得る。例えば、１つのシナリオにおいて、承認レコードは非コミッタノードにて最初に複
製され、そして承認レコードは、トランザクションがコミッタノードにより最終的にコミ
ットされた後、コミットレコードに変更され得る。少なくとも一実施形態において、個別
遷移種類フィールド３０２は、ＡＳＲ内にも、ＡＳＲの生成をもたらすメッセージ内にも
含まれ得ない。代わりに、遷移の種類はＤＡＧノードにより、自身の現在の役割及び／ま
たはメッセージを送信した情報源ＤＡＧノードの役割に関するノードの知識に基づいて、
推測され得る。例えば、ステート遷移メッセージを受信する非コミッタノードは、メッセ
ージが承認済みステート遷移を表すことを推測し得る。

描かれた実施形態において、ステート遷移レコード３２０は、遷移データ３０４を含み
得る。遷移データコンポーネント３０４のコンテンツの特質は、ステートが管理されてい
るアプリケーションにより異なり得る。いくつかの事例において、例えば、ステート遷移
要求は、書き込みペイロード（書き込み予定の複数のバイトと、当該バイトが書き込まれ
るアドレス（複数可）とを示す）を含み、書き込みペイロードは遷移レコードに含まれ得
る。別のアプリケーションに関して、各ステート遷移は、アプリケーションクライアント
により発行された各自の命令を示し、命令の表現はＡＳＲに含まれ得る。ＡＳＲ３２０は
、ステート遷移に対応するシーケンス番号３０６（論理スタンプとも考えられる）も含み
得る。シーケンス番号は、例えば、受諾ノードにてステート遷移要求が承認された時、ま
たはコミッタノードにてステート遷移がコミットされた時、生成され得る。少なくともい
くつかの実施形態において、ＤＡＧを使用して管理されているアプリケーションの現行ス
テートは、アプリケーションのある初期ステートから開始して、シーケンス番号が増加す
る順序で、コミット済みステートレコードの遷移データ（例えば書き込みペイロード、命
令等）を適用することにより決定され得る。いくつかの実施形態において、例えばどのＤ
ＡＧノードが同一の遷移に関する各自のＡＳＲを既に格納したか、及び／またはこれらの
レコードが複製された順序を示す、遷移の複製履歴情報３０８もまた、ＡＳＲに含まれ得
る。このような複製履歴情報は、例えば、コミットのために十分な数のノードが所定のス
テート遷移を記録したことを確認するために、いくつかの実施態様においてコミッタノー
ドにより使用され得る。いくつかの実施形態において、ＡＳＲメッセージは、対応ステー
ト遷移要求が受信された受諾ノードの識別を示し得るが、複製経路沿いの他のノードに関
する情報は含まなくてもよい。少なくとも一実施態様において、コミッタノードは、承認
済みステート遷移をコミットする前に、十分な数のノードがステート遷移レコードを複製
したことを確認する必要はなくてよい。

ＤＡＧ構成デルタメッセージ３７０は、描かれた実施形態において、参加または離脱す
るノード（複数可）の識別子３５２と、実施されている変更の種類３５４（例えば参加、
あるいは離脱）とを示し得る。いくつかの実施態様において、参加（または離脱）ノード
に関する役割情報３５６が、任意で構成デルタメッセージに含まれ得る。少なくともいく
つかの実施形態において、アプリケーションステートシーケンス番号がアプリケーション
ステート遷移に対応付けられるように、ＤＡＧ構成変更シーケンス番号３５８は、構成デ
ルタメッセージに含まれ得る。このようなシーケンス番号は、例えば、構成デルタメッセ
ージの受信ノードにより、当該受信ノードが全ての前の構成変更を受信したか否かを判定
するために使用され得る。いくつかの構成変更が欠損している場合（例えばネットワーク
パケットが抜け落ちたため）、受信ノードは、欠損している構成デルタメッセージを再送
するようにＤＣＭに要求を送信し得る。構成変更シーケンス番号３５８は、様々な実施形
態において、ＤＣＭにおけるカウンタまたは論理タイムスタンプとして実施され得る。Ｄ
ＣＭが複数のノードを有するクラスタを備えるいくつかの実施態様において、構成変更シ
ーケンス番号３５８の情報源として、クラスタマネジャーにより維持されるグローバル論
理タイムスタンプが使用され得る。

プロバイダネットワーク環境における複製ＤＡＧ展開
図４は、少なくともいくつかの実施形態による、プロバイダネットワークの複数の可用
性コンテナにわたりメンバーノードが分散された例示的複製ＤＡＧを示す。インターネッ
ト及び／または他のネットワークを介してアクセス可能な１つまたは複数のサービス（様
々な種類のマルチテナント及び／または単一テナントのクラウドベースコンピューティン
グまたは格納サービス等）を、分散集合のクライアントに提供するために、企業または公
的機関等の事業体が構築したネットワークは、本明細書においてプロバイダネットワーク
と称され得る。少なくともいくつかのプロバイダネットワークは、「パブリッククラウド
」環境とも称され得る。所定のプロバイダネットワークには、プロバイダにより提供され
るインフラストラクチャ及びサービスを実装、設定、及び配給するために必要となる物理
及び／または仮想化コンピュータサーバ、格納デバイス、ネットワーク機器等の集合とい
った様々なリソースプールを提供する多数のデータセンタが含まれ得る。大きなプロバイ
ダネットワーク内で、いくつかのデータセンタは他とは異なる市、州、または国に配置さ
れ、そしていくつかの実施形態において、所定アプリケーションに割り当てられたリソー
スは、所望されるレベルの可用性、耐障害性、性能を達成するために、このようないくつ
かの場所に分散され得る。

いくつかの実施形態において、プロバイダネットワークは、複数の地理的領域に編制さ
れ、そして各領域は、「可用性ゾーン」とも称され得る１つまたは複数の可用性コンテナ
を含み得る。次に可用性コンテナは、所定の可用性コンテナ内のリソースが他の可用性コ
ンテナにおける障害から隔離される（例えば電力関連設備、冷却設備、及び／または物理
的安全コンポーネント等の独立インフラストラクチャコンポーネントを有する）ように設
計された１つまたは複数の別個の物理的建物またはデータセンタを含み得る。１つの可用
性コンテナにおける障害がその他の可用性コンテナにおいて障害もたらすことは予期され
得ないため、所定の物理ホストまたは仮想化サーバの可用性プロファイルは、別の可用性
コンテナにおける他のホストまたはサーバの可用性プロファイルとは無関係であるように
企図される。

図４に示されるように、いくつかの実施形態において、複製ＤＡＧの１つまたは複数の
ノードは、ＤＡＧの他のノードの可用性コンテナと異なる可用性コンテナ内にインスタン
ス化され得る。描かれた実施形態において、プロバイダネットワーク４０２は、３つの可
用性コンテナ４６６Ａ、４６６Ｂ、４６６Ｃを含み、各可用性コンテナは複数のノードホ
スト４１０を備える。例えば、可用性コンテナ４６６Ａのノードホスト４１０Ａは、ＤＡ
Ｇノード４２２Ａと、ローカル持続的格納域（例えば１つまたは複数のディスクベースデ
バイス）４３０Ａと、ＤＡＧのクライアントと通信するためのフロントエンドとして使用
され得るプロキシ４１２Ａとを備える。同様に、可用性コンテナ４６６Ｂ内のノードホス
ト４１０Ｂは、ＤＡＧノード４２２Ｂと、ローカル持続的格納域４３０Ｂと、プロキシ４
１２Ｂとを備え、可用性コンテナ４６６Ｃ内のノードホスト４１０Ｃは、ＤＡＧノード４
２２Ｃと、ローカル持続的格納域４３０Ｃと、プロキシ４１２Ｃとを備える。描かれた実
施形態において、ＤＡＧノード４２２（及び／またはプロキシ４１２）はそれぞれ、１つ
または複数のプロセスの集合等、１つまたは複数の実行スレッドを含み得る。ローカル持
続的格納デバイス４３０は、描かれた実施形態において、複製経路４９１沿いにアプリケ
ーションステート情報のローカルレプリカ（及び／または複製経路４９１のＤＡＧノード
４２２にて受信されるＤＡＧ構成デルタメッセージコンテンツ）を格納するのに使用され
得る。

図４の実施形態において描かれるＤＡＧのＤＣＭ自体は、複数の可用性コンテナにわた
って分散された複数のノードを備える。示されるように、同意ベースのＤＣＭクラスタ４
９０が使用され、これには、可用性コンテナ４６６Ａに配置されたＤＣＭノード４７２Ａ
とＤＣＭ格納域４７５Ａ、並びに可用性コンテナ４６６Ｂに配置されたＤＣＭノード４７
２ＢとＤＣＭ格納域４７５Ｂが含まれる。描かれたＤＣＭは従って、少なくとも障害が可
用性コンテナの境界を越えないという点では、フォールトトレラントと考えられ得る。こ
のようなフォールトトレラントＤＣＭのノードは、例えばＤＣＭにより管理されているＤ
ＡＧのメンバーノードと対照的に、本明細書において「構成ノード」と称され得る。ＤＡ
Ｇ構成に対する変更（例えばノードの削除、追加、または役割変更を含む）は、ＤＣＭノ
ード４７２間の同意ベースプロトコルを使用して承認され、そしてＤＡＧ構成の表現は、
対応構成デルタメッセージがＤＡＧノード４２２に送信される前に、複数のＤＣＭノード
により持続的格納域に格納される必要があり得る。ＤＣＭ及び／または所定の複製ＤＡＧ
に使用される可用性コンテナの数は、異なる実施形態において、かつ、例えばアプリケー
ションの可用性要件またはデータ耐久性要件に応じて、異なるアプリケーションにより、
変わり得る。いくつかの実施形態において、複製ＤＡＧは、プロバイダネットワークにて
実施される他のサービスのリソースの構成を管理するために使用され得る。例えば、一実
施形態において、仮想化コンピューティングサービスにより使用される演算インスタンス
（仮想マシン）またはインスタンスホスト（物理ホスト）のステートに対する変更は、複
製ＤＡＧを使用して管理され得る。

図５は、少なくともいくつかの実施形態による、複数の複製ＤＡＧのノードがマルチテ
ナント様式で単一のホストに実装され得る例示的構成を示す。示されるように、３つの複
製ＤＡＧ５５５Ａ、５５５Ｂ、５５５Ｃのノードは、４つのＤＡＧノードホスト５１０Ａ
、５１０Ｂ、５１０Ｃ、５１０Ｄに分散される。一般に、ノードホストはそのリソース容
量において異なり得る。例えば、あるホストのコンピューティング、格納、ネットワーク
、及び／またはメモリリソースは、他のホストのものと異なり得る。例えば、ノードホス
ト５１０ＢはＤＡＧ情報に使用可能な２つの格納デバイス５３０Ｂ、５３０Ｃを有し、ノ
ードホスト５１０Ｄは２つの格納デバイス５３０Ｅ、５３０Ｆを有し、一方ノードホスト
５１０Ａと５１０Ｃは１つの格納デバイス（５３０Ａと５３０Ｄをそれぞれ）有する。

ホスト５１０Ａは、ＤＡＧ５５５Ａの受諾ノード５２２Ａと、ＤＡＧ５５５Ｃの中間ノ
ード５２２Ｎとを備える。ホスト５１０Ｂは、ＤＡＧ５５５Ａの中間ノード５２２Ｂと、
ＤＡＧ５５５Ｂのコミッタノード５２２Ｋと、ＤＡＧ５５５Ｃの中間ノード５２２Ｏとを
備える。ＤＡＧ５５５Ａのコミッタノード５２２Ｃと、ＤＡＧ５５５Ｃのコミッタノード
５２２Ｐは、ホスト５１０Ｃに実装され得る。最後に、ＤＡＧ５５５Ａの待機ノード５２
２Ｃと、ＤＡＧ５５５Ｂの受諾ノード５２２Ｊと、ＤＡＧ５５５Ｃの受諾ノード５２２Ｍ
とが、ホスト５１０Ｄにてインスタンス化され得る。従って、一般に、所定のホストはＮ
個の異なるＤＡＧのノードに使用され、各ＤＡＧはＭ個の異なるホストを使用し、Ｍ及び
Ｎは、少なくともいくつかの実施形態において、設定可能なパラメータであり得る。それ
ぞれのアプリケーションオーナーのために確立されたいくつかのＤＡＧのノードは、少な
くともいくつかの実施形態において、マルチテナント様式で同一のホストに実装され得る
。例えば、特定のアプリケーションオーナーにとって、そのアプリケーションのステート
管理に使用されているリソースが、他のアプリケーションのステートの管理にも使用され
ていることは明らかではない場合がある。いくつかのプロバイダネットワーク環境におい
て、所定のアプリケーションの複製ＤＡＧの所定のノードに使用する特定のホストを選択
する配置サービスが実施され得る。異なる実施形態において、ステートが管理されている
アプリケーションの性能要件、候補ホストの利用可能なリソース容量、負荷分散要求、価
格設定約因等、様々な要素の組み合わせに基づいて、ノードホストは選択され得る。少な
くともいくつかの実施態様において、ホストごとに複数のＤＡＧノードをインスタンス化
することは、単一のＤＡＧノードのみがインスタンス化された場合に達成され得るホスト
の全体リソース使用レベルと比べて、ホストの全体リソース使用レベルを向上させるのに
役に立ち得る。例えば、特にＤＡＧノードに使用される論理の大部分が単一スレッドであ
る実施形態において、マルチテナントシナリオでは、単一テナントシナリオよりも多いマ
ルチコアホストのプロセッサコアが同時に使用可能であり、これによりホストの平均ＣＰ
Ｕ使用率は向上する。

動的ＤＡＧベースのステート複製を実施する方法
前述のように、いくつかの実施形態において、複製ＤＡＧの所定ノードは、所定の時点
にいくつかの役割のうちの１つが与えられ得る（例えば受諾、中間、コミッタ、または待
機）。図６は、少なくともいくつかの実施形態による、ステート遷移要求（ＳＴＲ）の受
信に応じて複製ＤＡＧの受諾ノードで行われ得る動作態様を示すフロー図である。構成要
素６０１に示されるように、受諾ノードは、アプリケーションのＳＴＲを含むメッセージ
を、例えばステート複製サービスのクライアントから受信し得る。ＳＴＲは、アプリケー
ションの特質に部分的により、異なる実施形態において様々な構成要素を含み得る。例え
ば、さらに詳しく後述されるようにいくつかの実施形態において、ＤＡＧは、１つまたは
複数のデータストアに対するトランザクションの楽観的並行処理制御に使用され、そして
ＳＴＲは、前にコミットされたトランザクションとの競合を検出するために使用可能な読
み出し集合及び書き込み集合等のデータを含み得る。複製ＤＡＧを使用してステート遷移
が管理される各アプリケーションは、要求されたステート遷移に対する自身の受諾基準集
合を有し、そして少なくともいくつかの事例において、遷移が受諾されるべきか拒否され
るべきかを判定するために、ＳＴＲのコンテンツが使用され得る。いくつかの実施態様に
おいて、要求されたステート遷移を受諾／拒否するために、動作条件が同様または代わり
に、使用され得る。例えば受諾ノードまたはＤＡＧの他のノードの作業負荷レベルが閾値
以上の場合、ステート遷移は拒否され得る。遷移が受諾基準を満たす場合（構成要素６０
４にて検出）、受諾ＳＴＲに対する新たな承認シーケンス番号が、例えばカウンタ値を増
加させることで、またはある他の単調増加論理タイムスタンプ値を取得することで、生成
され得る（構成要素６０７）。遷移が承認されたことを示すレコードは、シーケンス番号
と一緒にローカル格納域に格納され得る（構成要素６１０）。いくつかのアプリケーショ
ンに関して、遷移要求は複製するデータ集合（書き込みペイロード等）を含み得る。受諾
ノードは当該データ集合をローカル格納域に同様に格納し得る。一実施態様において、受
諾ノードは、プロバイダネットワークの特定ホストで実行される１つまたは複数のプロセ
スを含み、そして遷移の承認のレコード、シーケンス番号、及び遷移のデータ集合は全て
、当該特定ホストの持続的ディスクベース格納デバイスに格納され得る。いくつかの実施
形態において、遷移のデータ、遷移が承認されたという開示、及びシーケンス番号は全て
結合され、ログに挿入（または添付）されるログエントリ等、ローカル格納域に格納され
る単一オブジェクトに形成され得る。別の実施形態において、遷移のデータ集合は、遷移
の承認を示すレコードとは別に格納され得る。

ステート遷移のレコードが無事格納された後、承認を示すステート遷移メッセージは、
コミッタノードに向けてＤＡＧの複製経路沿いの隣接ノードへ送信され得る（構成要素６
１３）。いくつかの事例において、ＤＡＧのトポロジーに応じて、複数のこのようなメッ
セージは、複製経路沿いのあるノードから各隣接ノードへ送信され得る。前述のように、
ＤＡＧの各ノードは、ＤＡＧ構成に関する自身の見解を有し、これは所定の時点で必ずし
も他のノードの見解と一致するとは限らない。描かれた実施形態において、受諾ノードは
その受諾済みステート遷移メッセージを、ＤＡＧの構成の自身の現在の見解に示される隣
接ノード（複数可）へ、たとえその現在の見解がＤＡＧのＤＣＭの見方と比べると（また
は１つまたは複数の他のＤＡＧノードの見方と比べると）図らずも古すぎるまたは誤りが
あるとしても、送信し得る。メッセージ（複数可）の送信が完了すると、ステート遷移要
求の処理は、受諾ノードにおいては完了したと見なされ得る（構成要素６１９）。要求さ
れた遷移がアプリケーションの受諾基準を満たさない場合（同様に構成要素６０４にて検
出）、遷移は拒否され得る（構成要素６１６）。いくつかの実施態様において、拒否を示
す通知または応答が、要求者に提供され得る。

図７は、少なくともいくつかの実施形態による、承認済みステート遷移メッセージの受
信に応じて複製ＤＡＧの中間ノードで行われ得る動作態様を示すフロー図である。例えば
受諾ノードから、または別の中間ノードから、このようなメッセージＳＴＭ１が受信され
た後（構成要素７０１）、いくつかの実施形態において、中間ノードは、より小さいシー
ケンス番号のステート遷移メッセージが欠損しているか否か（例えばＳＴＭ１がＳＮ１の
シーケンス番号を有する場合、ＳＮ１より小さいシーケンス番号を有する未受信のＳＴＭ
が１つまたは複数存在するか否か）を判定し得る。描かれた実施形態において、このよう
な欠損ステート遷移メッセージの証拠が見つかると（構成要素７０４）、中間ノードは、
現在わかっている複製経路沿いの隣接先行ノードに対し、欠損ＳＴＭ（複数可）の再送要
求を任意で提出し得る（構成要素７０７）。いくつかの実施態様において、中間ノードは
、その再送要求に対する応答を受信するのを待ってから、ＳＴＭ１に対応する承認済みス
テート遷移のレコードをローカル格納域に格納し得る。ＳＴＭ１に対する承認レコードは
、例えば承認シーケンス番号と、遷移に対応付けられた任意のデータ集合（書き込みペイ
ロード等）と一緒に格納され得る（構成要素７１０）。ステート遷移メッセージ（既に受
信されたメッセージとコンテンツが同様であり得る、あるいは既に受信されたメッセージ
とコンテンツが同一であり得る）はその後、コミッタノードに向けて現在わかっている複
製経路（複数可）上の各隣接ノードに対し送信され得る（構成要素７１３）。ステート遷
移の承認履歴がステート遷移メッセージに含まれるいくつかの実施態様において、中間ノ
ードは、その（中間ノードの）識別子を、発信するステート遷移メッセージ内に示される
承認者リストに追加し得る。

いくつかの実施形態において、ＳＴＭ１の承認レコードをローカル格納域に保存する前
に欠損シーケンス番号を確認する代わりに、異なる手法が取られ得る。例えば、中間ノー
ドは、承認レコードをローカル格納域に格納した後、及び／または対応ＳＴＭをコミッタ
ノードに向けて送信した後、欠損シーケンス番号を確認し得る。

一実施態様において、所定の接続内でメッセージの順序正しい配信を保証する、ＴＣＰ
（伝送制御プロトコル）等のネットワークプロトコルが、非受諾ノードにてＳＴＭを受信
するためのプルモデルと組み合わせて使用され得る。このような実施態様において、中間
ノード、コミッタノード、または待機ノードが複製経路沿いの自身の隣接先行ノードとの
ネットワーク接続を維持する限り、ネットワークプロトコルに依拠して、どのメッセージ
も確実に失わないようにし得る。このような実施態様において、所定ＤＡＧノードＮ１に
て隣接先行ノードＰ１に対する接続を失った場合、Ｎ１は、Ｐ１に対する（またはＰ１が
もはやＤＡＧの一部ではないことを示す構成デルタメッセージが受信された場合は異なる
先行ノードに対する）新たな接続を確立し、前に受信済みの最大シーケンス番号より大き
いシーケンス番号を有する全てのＳＴＭを送信するようにＰ１に要求する責務を担い得る
。

図８は、少なくともいくつかの実施形態による、承認済みステート遷移メッセージの受
信に応じて複製ＤＡＧのコミッタノードで行われ得る動作態様を示すフロー図である。例
えば中間ノードから、または受諾ノードから、承認済みステート遷移メッセージを受信す
ると（構成要素８０１）、コミッタノードは、ステート遷移がアプリケーションのコミッ
ト基準を満たすか否かを判定し得る。いくつかの実施形態において、コミッタノードは、
ＳＴＭのコンテンツ（承認履歴フィールド等）から、これまで保存されたアプリケーショ
ンステートレコードのレプリカの数を特定可能であり、そしてレプリカの数が閾値を超え
る場合には、遷移がコミット可能であると判断され得る。レプリカカウント閾値は、アプ
リケーションに基づいて異なり得る。例えば、いくつかのアプリケーションに関しては、
受諾ノードに単一のレプリカで十分であり得る。別の実施形態において、コミッタノード
はまた、遷移をコミットする前に、コミッタノードが現行のＳＴＭのシーケンス番号より
小さいシーケンス番号を有する全てのＳＴＭを既に受信したか否か等、他の要素を考慮す
る必要があり得る。一実施形態において、例えば、コミッタノードは、現行遷移をコミッ
トする前に、自身が全てのこのような前のＳＴＭを受信し処理するまで待機する必要があ
り得る。

コミット基準（アプリケーションにより異なり得る）が満たされた場合（構成要素８０
４にて検出）、コミッタノードはコミットレコードを、ローカル格納域における自身のア
プリケーションステートレコードの集合の中に、例えばシーケンス番号及び遷移データ集
合（もしあれば）と一緒に格納し得る（構成要素８０７）。いくつかの実施態様において
、コミット基準はデフォルトで、受諾ノードで既に検証された受諾基準に設定され得る。
すなわち１度ステート遷移が受諾ノードで承認されると、コミッタノードは、いずれの追
加条件も検証する必要なしに、受信したＳＴＭ内に示されるステート遷移をコミットし得
る。いくつかの実施形態において、ＳＴＭ内に示される承認シーケンス番号のコピーが、
コミットシーケンス番号として格納され得る。いくつかの承認済み遷移はコミットされ得
ないため、少なくとも一実施形態において、承認に使用されるシーケンス番号の集合とは
異なるシーケンス番号の集合がコミットに使用され得る（例えば一連のコミットシーケン
ス番号にいかなる欠落もないように）。待機ノードがＤＡＧに設定される場合、コミッタ
ノードから１つまたは複数のこのような待機ノードに対し、コミット後ＳＴＭが送られ得
る。少なくともいくつかの実施形態において、遷移がコミットされた後、ＤＡＧの１つま
たは複数の他のノードがそれらのアプリケーションステート情報を更新できるように、及
び／または遷移がコミットされたことを示す応答をステート遷移の要求クライアントに対
し送信するために、コミットの通知がＤＡＧの１つまたは複数の他のノードへ提供され得
る（構成要素８１０）。

欠損ＳＴＭがコミット基準に関した処理の一環として取り扱われないいくつかの実施形
態において、コミッタノードは、欠損ＳＴＭに関して図７において示される行動と同様の
行動を取り得る。従って、例えば、コミッタノードが１つまたは複数のＳＴＭ（受信した
ＳＴＭのシーケンス番号より小さいシーケンス番号を有するＳＴＭ）が欠損していると判
定した場合（構成要素８１３）、欠損ＳＴＭの再送要求が隣接先行ノード（複数可）へ送
信され（構成要素８１６）、受信したＳＴＭの処理は完了する（構成要素８２２）。コミ
ット基準が満たされない場合、コミッタノードはステート遷移をアボートし得る（構成要
素８１９）。いくつかの実施形態において、アボート通知が、ＤＡＧの１つまたは複数の
他のノードへ、及び／またはステート遷移を要求したクライアントへ送信され得る。いく
つかの実施態様において、前述のように、ステート遷移が受諾ノードにて承認された場合
、複製ＤＡＧは、複製経路の１つまたは複数のノード（受諾ノード自体も含む）に障害が
起こったとしても、（最終的に）ステート遷移をコミットする責務を担い得る。ステート
遷移のアボートは、いくつかのこのような実施態様において、他のＤＡＧノードからの遷
移の承認レコードの削除（または承認レコードが偶然格納されたノードのＤＡＧからの実
際の削除）等、比較的重い変更を要し得る。図１１ａ〜図１４に関してさらに詳しく後述
されるように、対応ステート遷移情報が所望数のＤＡＧノードに複製されることなくＳＴ
Ｍがコミッタノードに届くシナリオを回避するために、いくつかの実施形態において、先
制的整合ＤＡＧ一時停止技術が使用され得る。

図９は、少なくともいくつかの実施形態による、複製ＤＡＧの構成マネジャー（ＤＣＭ
）で行われ得る動作態様を示すフロー図である。構成要素９０１に示されるように、ＤＡ
Ｇにおける構成変更を潜在的に引き起こし得るイベントは、構成マネジャーにより検出さ
れ得る。このようなイベントは、「ノード障害が検出された」等のメッセージ（例えばＤ
ＡＧノードから、またはプロバイダネットワークの正常性管理コンポーネントから）、ま
たは「サービス対応可能」等のメッセージ（例えば障害後に再始動したＤＡＧノードから
）を受信することを含み得る。いくつかの実施形態において、構成マネジャー自体は、様
々なＤＡＧノードの正常性ステータスを監視する責務を担い、そしてトリガーイベントは
、構成マネジャーにより検出される、ノードのうちの１つが複数のハートビートメッセー
ジまたは他の正常性確認に対し適時に応答しなかったことであり得る。少なくともいくつ
かの実施形態において、ＤＡＧノードは、いかなる見かけ上のノード障害も（例えば接続
が突然終了した場合、または閾値より長い時間、隣接ノードから全くメッセージが受信さ
れない場合）、ＤＣＭへ報告する責務を担い得る。ＤＡＧノードはまた、いくつかの実施
形態において、ＤＡＧ構成変更をもたらし得る差し迫った変更（メンテナンスのためにノ
ードが経路から外れる予定である場合等）を、ＤＣＭに通知する責務も担い得る。ＤＣＭ
は、描かれた実施形態において、示された構成変更（例えば障害が発生したノードの削除
、または新たなノードの参加）を有効化するか否かを、例えばＤＣＭクラスタの複数のノ
ード間で実施され得る同意プロトコルに基づいて、判定し得る（構成要素９０４）。例え
ば、いくつかの実施態様において、ＤＡＧノードに障害が発生したという１つのＤＣＭノ
ードによる判定は、ＤＡＧノードが構成から削除される前に、クラスタの１つまたは複数
の他のノードにおいて確認される必要があり得る（例えばＤＡＧノードから受信されるハ
ートビート応答を他のＤＣＭノードにて再検討することにより）。別の実施態様において
、可能性のある構成変更を適用するか否かに関する判定は、同意ベースプロトコルを使用
せずに行われ得る。ＤＡＧ構成変更に対応付けられたシーケンス番号または論理タイムス
タンプは、いくつかの実施形態において、例えばＤＡＧの他のノードに送信される構成デ
ルタメッセージに含めるために決定または生成され、そのため構成変更は、ＤＡＧノード
にて正しい順序で処理され得る。

構成変更がどのように承認されたかに関係なく、いくつかの実施形態において、変更が
完了したとみなされる前に、構成変更の表現は、ＤＣＭの複数の格納位置に複製される必
要があり得る（構成要素９０７）。構成変更に関する情報を複数の位置に保存することは
、ＤＣＭがＤＡＧ構成情報の正式な情報源として機能する実施形態において、ＤＣＭの機
能の重要な態様であり得る。少なくともいくつかの実施態様において、構成に対する変更
のみ（例えば構成全体ではなく）が複製され得る。構成変更情報が保存された後、ＤＣＭ
から対応構成デルタメッセージ（構成に対し実施したばかりの変更を示し、必ずしもＤＡ
Ｇの構成全体を示さない）を送る送信先ＤＡＧノードの集合が特定され得る（構成要素９
１０）。いくつかの実施形態において、全ＤＡＧメンバー（構成デルタメッセージ内に示
される構成変更の一環としてＤＡＧから削除されるノードも潜在的に含む）は、構成デル
タメッセージの送信先として選択され得る。一実施形態においては、現行のＤＡＧメンバ
ーとみなされるノードのみが選択され得る。例えば、ノードが削除される、またはノード
に障害が起こったと思われる場合には、当該ノードに対し構成デルタメッセージは送信さ
れ得ない。別の実施形態においては、メンバーのある部分集合が送信先として選択され、
そしてその部分集合は、残りのノードに対し構成変更を伝播する責務を担い得る。メンバ
ーの部分集合が送信先として選択される実施形態において、ＤＣＭは、いずれかの所定の
時点でどの変更がどのメンバーに伝播されたか記録を保持する必要があり得る。送信先と
なるＤＡＧノードの集合が特定された後、それらに対しそれぞれの構成デルタメッセージ
が、お互いに非同期的に、そしてステート遷移メッセージ処理またはステート遷移要求処
理におけるいかなる中断も要求することなく、送信され得る（構成要素９１３）。少なく
ともいくつかの実施形態において、構成デルタメッセージは、構成変更に対応付けられた
構成シーケンス番号を含み得る。いくつかの実施態様において、複合構成デルタメッセー
ジは、２つ以上の変更（例えば障害ノードの削除と交代ノードの参加）を示し得る。

図１０は、少なくともいくつかの実施形態による、構成マネジャーからの構成デルタメ
ッセージの受信に応じて複製ＤＡＧのメンバーノードで行われ得る動作態様を示すフロー
図である。ＤＣＭから構成変更シーケンス番号を含むような構成デルタメッセージを受信
すると（構成要素１００１）、受信ＤＡＧノードは、描かれた実施形態において、例えば
新たに受信したシーケンス番号を前に受信済みの最大シーケンス番号と比較することで、
全ての前の構成デルタメッセージを自身が受信したか否かを判定し得る。受信ノードが、
１つまたは複数の構成デルタメッセージをまだ受信していないと判定すると（構成要素１
００４）、受信ノードは、構成更新要求をＤＣＭに送信し得る（構成要素１００７）。こ
のような更新要求により、例えば、ＤＣＭは欠損構成デルタメッセージ（複数可）を再送
する、またはＤＡＧの現行の構成全体が示される別の種類のメッセージが送信される。

欠損構成デルタメッセージが検出されない場合（同様に構成要素１００４の対応動作に
おいて）、受信ノードは、受信された構成変更情報を、ローカル格納域内の構成変更レポ
ジトリに格納し得る。レポジトリに蓄積されるメッセージは、ＤＡＧ構成に関する受信ノ
ードの見解を更新するのに使用され得る（構成要素１０１０）。ＤＡＧ構成のローカル見
解を更新することは、例えば、先々の送信及び受信ステート遷移メッセージに使用する複
製経路（複数可）の１つまたは複数のＤＡＧノード及び／または辺を特定することを含み
得る。前述のように、メッセージ配信の非同期的特質のため、及びネットワークの異なる
箇所において異なる遅延が発生し得るため、構成デルタメッセージが１つのＤＡＧノード
にて取得される順序は、同じ構成デルタメッセージ集合が別のノードにて受信される順序
とは異なり得る。従って、所定の時点で２つの異なるノードにて特定される複製経路は、
お互いに異なり得る。描かれた実施形態において、受信ノードは、複製経路上の自身の隣
接先行ノードが変更したら、もしくは自身の隣接後続ノードが変更したら、さらなる行動
を取り得る。隣接後続ノードも隣接先行ノードも変更していない場合、いくつかの実施形
態において、構成デルタメッセージの処理は、構成変更情報が受信ノードのローカル格納
域に格納された後に終了し得る（構成要素１０２７）。

ＤＡＧのノードＣに関して隣接先行ノードが変更されるシナリオの実施例として、Ａ〜
Ｂ〜ＣからＡ〜Ｃへの複製経路の部分的変更がある。更新された構成が受信ノードの隣接
先行ノードの変更を伴い、かつ新たな隣接先行ノードからまだ直接メッセージが受信され
ていない場合（構成要素１０１３にて検出）、受信ノード（現実施例においてノードＣ）
は、新隣接先行ノード（現実施例においてノードＡ）への接続を確立し得る。さらに、少
なくともいくつかの実施形態において、受信ノード（例えばノードＣ）はまた、受信ノー
ドがごく最近受信したシーケンス番号より大きいシーケンス番号を有するＳＴＭの再送要
求を、新隣接先行ノード（例えばノードＡ）に送信し得る（構成要素１０１７）。ノード
Ｃに後続ノードが存在する場合、ノードＣは、要求した再送をノードＡから受信するのを
待ちながら、そのような後続ノードに対しいずれの承認待ちステート遷移メッセージも送
信し続け得る。

受信ノードの隣接後続ノードが変更したことを構成デルタメッセージが示し（例えばノ
ードＢがＤＡＧ離脱したことを示す、前述と同じ実施例の構成デルタメッセージをノード
Ａが受信し）、かつ新隣接後続ノードから何もメッセージが受信されていない場合（構成
要素１０２１）、受信ノードは新後続ノードへの接続を確立し得る。前の実施例において
、ノードＡは、その隣接後続ノードであるノードＣへの接続を確立し得る。ステート遷移
メッセージは、引き続き新隣接後続ノードへ転送され得る（構成要素１０２４）。

複製ＤＡＧノードの整合一時停止
大多数のアプリケーションの略同時機能停止を生じ得る大規模な障害イベントは、プロ
バイダネットワークのオペレータにとって重大な課題である。長期間の機能停止の影響を
受けるアプリケーションの顧客は、プロバイダネットワークがクリティカルアプリケーシ
ョンに必要なレベルのサービスを提供する能力を信用できなくなり得る。知的インフラス
トラクチャ設計により、またインフラストラクチャの高可用性特性を利用し得るアプリケ
ーションアーキテクチャを実装することにより、大規模な障害イベントの確率は低減され
得るが、大規模障害を完全に取り除くことは不可能であり得る。従って、複数のリソース
に影響する障害から分散アプリケーションがより速くクリーンに回復することを可能にし
得る技術が、少なくともいくつかの実施形態において開発され得る。分散アプリケーショ
ンステート管理に前述の種類の複製ＤＡＧが採用されるいくつかの環境において、分散障
害からのより効果的かつ効率的な復旧を支援するために、整合一時停止プロトコルが使用
され得る。一実施形態において、例えば、障害シナリオの検出に応じて、ＤＡＧの複数の
ノードは、それらの通常アプリケーションステート遷移処理動作（例えばステート遷移要
求メッセージの受信、アプリケーションステート情報のローカルコピーの格納、及びそれ
らの複製経路（複数可）沿ったステート遷移要求メッセージの送信）の実行を停止するよ
うに、構成マネジャーにより命じられ得る。それらの動作を一時停止した後、少なくとも
いくつかの実施形態において、ノードはそれらのローカルアプリケーションステートレコ
ードを他のＤＡＧノードと同期させ、クリーンシャットダウン及び再始動を行い得る。ノ
ードの再始動後、ノードは、自身がサービス再開可能であることを構成マネジャーに折り
返し報告し、構成マネジャーによるＤＡＧの再開を待機し得る。

図１１ａ〜１１ｈは、少なくともいくつかの実施形態による、このような整合一時停止
手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。例示的ＤＡＧにおけ
る各ノードは、それぞれのコミットレコード集合を格納し、各コミットレコードは対応コ
ミットシーケンス番号（ＣＳＮ）を含む（または例えばポインタにより示す）。ローカル
コミットレコード集合は従って、ノードの視点から、ＤＡＧを使用して管理されているア
プリケーションのステートを表し得る。承認済み（しかしまだコミットされていない）ス
テート遷移のレコードも、前述のように、一部または全てのノードにて保持され得る。Ｄ
ＡＧ構成変更に関してＤＡＧノードを更新し続けるために前述のようにＤＣＭが構成デル
タメッセージを送信する動的複製ＤＡＧとの関連で、整合一時停止技術が本明細書におい
て説明されるが、いくつかの実施形態において、同様の手法が他のステート複製技術にも
採用され得ることに留意されたい。例えば、整合一時停止技術は、全てのノードが同期的
に更新される世界停止再構成間隔を使用して複製ノードのグループに対する構成変更が実
施される環境においても使用され、この場合、全てのノードが新構成に関して認識させら
れた後にのみ複製グループは作動可能になる。従って、動的複製ＤＡＧは、整合一時停止
技術が異なる実施形態において実施され得る複数ノードステート複製グループ（ＳＲＧ）
の一例を表し得るにすぎない。少なくともいくつかのこのようなＳＲＧは、前述のＤＣＭ
に類似した自身の構成マネジャーを有し、コミッタノードとして指定されたいくつかのノ
ードと、非コミッタノードとして指定された他のノードとを有し得る。

５つのノード１１０２Ａ、１１０２Ｂ、１１０２Ｃ、１１０２Ｄ、１１０２Ｅを備える
複製ＤＡＧが、ＤＣＭ１１８０と一緒に図１１ａに示される。描かれた実施例において、
コミッタノード１１０２Ｅは、ＤＡＧのために整合一時停止手続きが開始されるべきであ
ることを判定する一時停止トリガー検出器１１０６を備える。多数の異なる種類の原因が
、異なる実施形態において一時停止手続きの開始を引き起こし得る。例えば、一時停止手
続きが開始され得る理由として、（ａ）ある閾値数のノードに障害が起こり得たため（「
Ｘ」印で示されるノード１１０２Ｂ及び１１０２Ｄにおける障害等）、（ｂ）構成デルタ
メッセージがコミッタノードにて（またはある他のノードにて）受信されているレートが
閾値を超えるため、（ｃ）あるＤＡＧノードまたはＤＣＭにてネットワークパケットまた
は接続が落ちているレートが閾値を超えるため、等が挙げられる。描かれた実施形態にお
けるコミッタノード１１０２Ｅは、コミッタノードのコミットレコード集合内に表される
シーケンス番号中の最大シーケンス番号を含むＤＡＧ一時停止要求１１５０を送信する。
当該最大シーケンス番号は、本明細書において最大コミット済みシーケンス番号（ＨＣＳ
Ｎ）１１０８と称され、後述のように一時停止手続きのステップのうちの１つの間に、Ｄ
ＡＧノード間のコミットレコード集合を同期するための参照として使用され得る。いくつ
かの実施形態において、一時停止が開始されるべきであるという初期判定は、非コミッタ
ノードのうちの１つにて、またはＤＣＭ１１８０自体にて行われ、そしてノードが自身の
コミットレコード集合を更新する際目標とすべき目標シーケンス番号として、特定のコミ
ットシーケンス番号（理想的にはＨＣＳＮであるが必ずしもではない）が選択され得る。

一時停止要求の受信に応じて、ＤＣＭ１１８０は、図１１ｂに示されるように、持続的
格納域１１７５にＨＣＳＮを保存し得る。ＤＣＭはそれから、ＤＡＧノードの少なくとも
部分集合に対しそれぞれの一時停止命令１１５２を、例えば描かれた例示的シナリオにお
いてノード１１０２Ａ、１１０２Ｃに対し命令１１５２Ａ、１１５２Ｂをそれぞれ送信し
得る。いくつかの実施形態において、ＤＣＭ１１８０は、ＤＣＭに保存されている最新の
ＤＡＧ構成（１１０２Ｂ及び１１０２Ｄ等の障害が起こり得たノードを含む）に従って、
ＤＡＧのメンバーである全てのＤＡＧノードに対し、一時停止命令を送信し得る。一時停
止命令はＨＣＳＮ１１０８を含み得る。

一時停止命令を受信すると、ＤＡＧノードは、ステート遷移要求／メッセージの処理を
停止し、その代わりに自身のコミットレコード集合が、ＨＳＣＮに対応するコミットレコ
ードを含むそれ以下のコミットレコードを全て含むことを検証するプロセスを開始し得る
。例えば、ノード１１０２Ａ及びノード１１０２Ｃは、コミッタノード１１０２Ｅにより
、ＨＣＳＮ以下のシーケンス番号を有する１つまたは複数のコミット済みステート遷移に
関してまだ通知されていなかったという場合もあり得る。このようなシナリオにおいて、
図１１ｃに示されるように、ノード１１０２Ａは、コミットレコード同期要求１１７２Ｂ
をコミッタノード１１０２Ｅに対し送信し（「１ａ」と表示される矢印により示されるよ
うに）、そしてノード１１０２Ｃは同様のコミットレコード同期要求１１７２Ｂをノード
１１０２Ｅに対し送信し得る（「１ｂ」と表示される矢印により示されるように）。コミ
ットレコード同期要求１１７２は、要求を送信したノードにて欠損しているコミットレコ
ードの開示をそれぞれ含み、例えば、ノード１１０２Ａは、ＳＮ１までのシーケンス番号
を有するコミットレコードを自身が既に有することを示し、一方ノード１１０２Ｃは、シ
ーケンス番号ＳＮ２、ＳＮ３、ＳＮ４を有するコミットレコードを自身は受信していない
ことを示し得る。「２ａ」、「２ｂ」と表示される矢印により示されるように、その後、
欠損コミットレコード１１７４Ａ、１１７４Ｂが、コミッタノードによりノード１１０２
Ａ、１１０２Ｃに対しそれぞれ送信され得る。「３ａ」、「３ｂ」と表示される矢印によ
り示されるように、ノード１１０２Ａ、１１０２Ｃはその後、それぞれの同期確認１１７
６Ａ、１１７６ＢをＤＣＭ１１８０へ送信し得る。「４」と表示される矢印により示され
るように、ＤＣＭ１１８０は、ＤＣＭの持続的格納域１１７５にて保持される最新状態ノ
ードリスト１１３３（すなわちコミッタノード１１０２Ｅのコミットレコード集合に一致
するように自身のコミットレコード集合を更新したノードのリスト）に、ノード１１０２
Ａ、１１０２Ｃを追加し得る。

図１１ｄに示されるように、描かれた実施形態において、ＤＡＧのノードは、実行を終
了し、自身を再始動し得る。障害が起こったノード１１０２Ｂ、１１０２Ｄは、例えば、
自身の障害からの復旧の一環として再始動し得る。整合一時停止手続きの一環として、ノ
ード１１０２Ａ、１１０２Ｃは、自身のコミットレコード集合がコミッタノードのものと
同期された後に、自身のコミットレコード集合（及び／またはノードの動作に関係する追
加メタデータ）をローカル格納域に保存し、それから制御された再始動を開始し得る。ノ
ード１１０２Ｅは、描かれた実施形態において、自身が一時停止要求１１５０を送信した
後、ある時間間隔待機し（少なくともいくつかの同期要求１１７２にコミッタノードが応
答可能なように）、いずれのステートメタデータもローカル格納域に保存し、それから一
時停止手続きの一環として自身の制御された再始動を開始し得る。

図１１ｅに示されるように、ＤＡＧノード１１０２Ａ〜１１０２Ｅが経路上に戻った後
、いくつかの実施形態において、これらのノードはＤＣＭ１１８０に対し各自の「サービ
ス対応可能」メッセージをそれぞれ送信し、再開命令を待ってから、それらのアプリケー
ションステート遷移処理動作を再開し得る。ＤＣＭは、ノード１１０２Ｂ、１１０２Ｄの
コミットレコード集合は最新ではあり得ないことを識別可能であり（自身の最新状態ノー
ドリスト１１３３を使用して）、従って、図１１ｆに示されるように、それぞれの同期命
令１１９４をノード１１０２Ｂ、１１０２Ｄに対し送信し得る。少なくともいくつかの実
施態様において、同期命令はＨＣＳＮ１１０８を示し得る。同期命令１１９４に応じて、
ノード１１０２Ｂ、１１０２Ｄは、それぞれのコミットレコード集合において欠損してい
るコミットレコードを示す自身のコミットレコード同期要求１１７２Ｃ、１１７２Ｄを、
最新とわかっているノードに対し各自送信し得る。例えば、ノード１１０２Ｂは、その同
期要求１１７２Ｃをノード１１０２Ａに対し送信し、一方ノード１１０２Ｄはその同期要
求をノード１１０２Ｅに対し送信し得る。いくつかの実施形態において、ＤＣＭは、コミ
ットレコード同期要求を送るべき送信先ノードを特定し得る。一実施形態において、全て
の非コミッタＤＡＧノードは、それらのコミッタレコード集合をコミッタノードと同期す
る必要があり得る。ノード１１０２Ｂ、１１０２Ｄは、それらの欠損コミットレコード１
１７４Ｃ、１１７４Ｄをそれぞれ受信し、そのため最終的に全てのノードが自身のコミッ
トレコード集合をＨＣＳＮまで同期される。いくつかの実施態様において、ノード１１０
２Ｂ、１１０２Ｄは、それらのコミットレコード集合が更新／同期されたことを示す確認
を、ＤＣＭ１１８０へ送信し得る。少なくとも一実施形態において、ＤＣＭは、その最新
状態ノードリストに含まれないノードに関して、図１１ｆに関して前述されたものと比べ
て多少より受動的な役割を担い得る。このような実施形態において、障害が発生したノー
ド（１１０２Ｂまたは１１０２Ｄ等）は、経路上に戻ると、新たに経路上に設定された当
該ノードが全てのコミットレコードを受信したか否かを判定するためのメッセージを、Ｄ
ＣＭに対し送信する。ＤＣＭは当該ノードに対し、最新状態のノードとなるには、ＨＣＳ
Ｎまでのシーケンス番号を有するコミットレコードが必要であることを（例えば単純にＨ
ＣＳＮを示すことにより）通知し得る。それから当該ノードは、自身を最新状態にする責
務と、自身のコミットレコードをＨＣＳＮまで同期したらＤＣＭへ折り返し報告する責務
を担い得る。従って、このような実施形態において、ＤＣＭは必ずしも同期命令１１９４
を送信するとは限らず、代わりに新たに経路上に設定されたノードが、自身のコミットレ
コード集合を同期する主導権を握り得る。

少なくとも閾値数のノードがコミットレコード集合を更新したことを確認した後、ＤＣ
Ｍ１１８０は、再開後のＤＡＧの構成を決定し得る。いくつかの事例においては、一時停
止の前に使用されていた構成と同じ構成が再使用され、一方、別の実施形態においては、
異なる構成が選択され得る。例えば、ＤＡＧは最低４つのノードを有さなければならない
場合もあり、そのためノード１１０２Ａ〜１１０２Ｅのうちの４つのみが最初に選択され
得る。図１１ｇに示されるように、ＤＣＭ１１８０は、選択されたノード集合（描かれた
実施例においては５つのノード全て）に対し、ＤＡＧの現行構成を示すそれぞれの再開メ
ッセージを送信し得る。ＤＡＧノードはそれから、図１１ｈに示されるように、通常動作
を再開し得る。いくつかの実施形態において、障害が発生しなかったＤＡＧノード（例え
ば１１０２Ａ、１１０２Ｃ、１１０２Ｅ）のうちの少なくともいくつかは、必ずしも自身
を再始動するとは限らない。代わりに、このようなノードのうちの１つまたは複数は、こ
のような実施形態において、自身のコミットレコード集合を同期した後、自身がＤＣＭか
ら再開命令を受信するまで、さらなるステート遷移処理を単純に延期し得る。

図１２は、少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ
等のＳＲＧのコミッタノードで行われ得る動作態様を示すフロー図である。構成要素１２
０１に示されるように、コミッタノードは、ＳＲＧの整合一時停止のトリガー基準が満た
されたことを判定し得る。例えば、応答可能な状態のＳＲＧノードの数が閾値を下回った
こと、またはＳＲＧの構成変更が起こっているレートが閾値を超えることが、コミッタノ
ードにより検出されることを含む、様々な異なるトリガー条件により、整合一時停止が引
き起こされ得る。いくつかの事例において、例えば、ネットワークパケットが抜け落ちる
レートが閾値を超える場合、または最大許容レート以上のレートで接続が突然終了されて
いる場合等、リソース作業負荷レベル、またはエラーレートが一時停止を引き起こし得る
。一実施形態において、ＳＲＧの非コミッタノード、またはＤＣＭ等の構成マネジャーが
、制御された一時停止を引き起こすであろう問題を最初に検出し、当該問題をコミッタノ
ードに通知し得る。

描かれた実施形態において、コミッタノードは、制御された一時停止を開始することを
決定した後、ステート遷移メッセージに関する自身の通常処理／複製を中断または停止し
、まだ保存されておらず未処理のいずれのコミットレコードもローカル格納域に保存し得
る（構成要素１２０４）。コミッタノードはそれから、ＨＣＳＮ（コミットレコードがコ
ミッタノードにより格納された遷移のシーケンス番号の中で最大のコミット済みシーケン
ス番号）の開示を含む一時停止要求を、ＳＲＧの構成マネジャー（例えば複製ＤＡＧの場
合はＤＣＭ）に対し送信し得る（構成要素１２０７）。ＨＣＳＮは、目標コミットシーケ
ンス番号として機能し、ＳＲＧの現在作動中のノードは、自身のコミットレコード集合を
当該目標コミットシーケンス番号まで同期する。

少なくともいくつかの実施形態において、コミッタノードは、一時停止要求を送信した
後、他のＳＲＧノード（例えばＨＣＳＮまでのシーケンス番号を有する全てのコミットレ
コード集合を自身は有さないと判定したノード）から、複数のコミットレコード同期要求
を受信し得る（構成要素１２１０）。描かれた実施形態において、コミッタノードは、設
定可能時間窓の間に受信されたいずれのそのような同期要求に応答する。コミッタノード
はそれから任意で、クリーンシャットダウン及び再始動を行い、サービス対応可能メッセ
ージをＳＲＧの構成マネジャーに送信し得る（構成要素１２１３）。いくつかの実施形態
において、クリーンシャットダウン及び再始動は省略され、そしてコミッタノードは単純
にサービス対応可能メッセージを送信し得る、あるいはコミッタノードは構成マネジャー
から再開命令を受信するまで、さらなるステート遷移関連処理を単純に延期し得る。最終
的に、コミッタノードは、構成マネジャーからＤＡＧの現行一時停止後構成を示す再開メ
ッセージを受信し、それからコミッタノードは、示される構成通りに、ステート遷移関連
処理を再開し得る（構成要素１２１６）。例えば、いくつかの実施形態において、新たな
一時停止後構成では、コミッタノードはもうコミッタの役割を与えられず、代わりに、受
諾ノード、中間ノード、または待機ノードに設定され得る場合もあり得る。

図１３は、少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ
等のステート複製グループの非コミッタノードで行われ得る動作態様を示すフロー図であ
る。通常動作中、非コミッタノードは、対応遷移がコミットされた後のある時点に、コミ
ットレコードをローカル格納域に格納し得る。その結果、非コミッタノードのローカルコ
ミットレコード集合は、必ずしもコミッタノードのもの程最新であるとは限らない。構成
要素１３０１に示されるように、非コミッタノードは、非コミッタノードが自身のローカ
ルコミットレコード集合を同期する際目標とすべき目標シーケンス番号としてＨＣＳＮを
示す一時停止命令を、構成マネジャーから受信し得る。

一時停止命令を受信すると、非コミッタノードは、新たなステート遷移メッセージの処
理を中断または停止し得る。ＨＣＳＮより小さいシーケンス番号を有するいくつかのコミ
ットレコードがローカルコミットレコード集合から欠損している場合、非コミッタノード
は、欠損レコードのコミットレコード同期要求を、コミッタノードへ（または構成マネジ
ャーにより欠損コミットレコードの情報源として指示された別のノードへ）送信し得る（
構成要素１３０４）。非コミッタノードのコミットレコード集合がＨＣＳＮに関して既に
最新状態である場合、非コミッタノードは、一時停止手続きの当段階において、他のノー
ドと通信しなくてもよい。ＨＣＳＮまでのシーケンス番号を有するコミットレコードがロ
ーカル格納域に格納されたことが確認された後、描かれた実施形態において、非コミッタ
ノードは、構成マネジャーに対し同期確認メッセージを送信し得る（構成要素１３０７）
。非コミッタノードはそれから、構成マネジャーにより再開されるまで、さらなるアプリ
ケーションステート遷移処理を延期し得る。任意で、非コミッタノードは、クリーンシャ
ットダウン及び再始動を行い、再始動後、「サービス対応可能」メッセージを構成マネジ
ャーに送信し得る（構成要素１３１０）。構成マネジャーからの再開メッセージに応じて
、非コミッタノードは、ＳＲＧ構成に関する自身の見解を更新し、アプリケーションステ
ート遷移処理を再開し得る（構成要素１３１３）。場合によっては、構成マネジャーによ
り、一時停止後構成において非コミッタノードに異なる役割が与えられ得る。例えば非コ
ミッタノードの役割はコミッタノードに変更され得る。

図１４は、少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ
等のステート複製グループの構成マネジャーで行われ得る動作態様を示すフロー図である
。構成要素１４０１に示されるように、構成マネジャーは、ＳＲＧのコミッタノードから
、コミットレコードがコミッタノードに格納されている遷移のシーケンス番号のうちの最
大コミット済みシーケンス番号（ＨＣＳＮ）を示す一時停止要求を受信し得る。いくつか
の実施形態において、ＳＲＧ動作を一時停止する決定が最終的になされる前に、構成マネ
ジャーの様々なノード間で同意プロトコルが採用され得る。構成マネジャーは、ＨＣＳＮ
を持続的格納域に格納し（構成要素１４０４）（例えば、構成マネジャークラスタのいく
つかのノードにおけるそれぞれの格納デバイスにて）、ＨＣＳＮを示す一時停止命令をＳ
ＲＧの１つまたは複数の他のノードへ送信し得る（構成要素１４０７）。いくつかの実施
形態において、一時停止命令は、障害が起こったと思われるノードを含むＳＲＧのわかっ
ているメンバー全てに対し送信され得る。ＳＲＧの受信ノードはそれぞれ、自身のローカ
ルコミットレコード集合がＨＣＳＮに対応するコミットレコードを含むことを確認し得る
（場合によっては、受信ノードは前述のようにコミッタノードから欠損コミットレコード
を取得しなければならない）。一時停止命令の受信ノードは、自身のコミットレコード集
合がＨＣＳＮに関して最新であることを確認した後、構成マネジャーに対し、自身のコミ
ットレコード集合が現時点で最新であることを示す同期確認を送信し得る。従って、構成
マネジャーは、ＳＲＧノードからこのような確認を受信すると、当該ノードを最新状態ノ
ードのリストに追加し得る（構成要素１４１０）。

いくつかの実施形態において、構成マネジャーは、ＳＲＧノードからそれらがサービス
対応可能であることを示すそれぞれのメッセージを受信するのを待ってよい。構成マネジ
ャーは、そのようなメッセージをノードから受信すると（例えばノードがクリーンシャッ
トダウン及び再始動を完了した後に、またはノードが障害後に経路上に戻った後に）、ノ
ードが最新状態ノードリストに含まれるか否かを特定し得る。受信した「サービス対応可
能」の開示の送信元であるノードがコミットレコードに関して最新であるかわからない場
合、構成マネジャーは、例えば明示的同期命令で、またはノードからの暗示的または明示
的クエリに応じて、ノードに対しＨＣＳＮの開示を送信し得る（構成要素１４１３）。そ
れからノードは、コミットレコードを更新する際の目標シーケンス番号としてＨＣＳＮを
使用して、既に最新状態の他のノードと通信することで、自身のローカルコミットレコー
ド集合を更新し得る。いくつかの実施形態において、構成マネジャーは、同期命令に、古
い状態のノードが欠損コミットレコードを取得するべき取得先となる情報源の開示を含み
得る。

構成マネジャーは、必要最低数のＳＲＧノードが（ａ）サービス対応可能であり、（ｂ
）アプリケーションコミットステートに関して最新状態であることを確認した後、ＳＲＧ
の一時停止後初期構成を完成し得る（構成要素１４１６）。それから構成マネジャーは、
構成を示す再開メッセージを、初期構成に含まれる適切なノード集合に送信し得る（構成
要素１４１９）。いくつかの実施形態において、初期構成情報は、一連の構成デルタメッ
セージとしてノードに対し提供され得る。

少なくともいくつかの実施形態において、同期のために選択される目標シーケンス番号
（すなわちＳＲＧの複数のノードそれぞれが自身のローカルコミットレコード集合を更新
する際目標とするシーケンス番号）は、必ずしも最大コミット済みシーケンス番号である
必要はない。例えば、コミッタノードにおける最大コミット済みシーケンス番号がＳＮ１
であり、そして速く拡大する大規模障害イベントの検出を受けてＳＲＧの動作を一時停止
することが急務であるため、ＳＲＧ構成マネジャーは、ノードが自身のコミットレコード
をより小さいシーケンス番号（ＳＮ１−ｋ）まで更新した後にそれらの動作を一時停止す
ることを進んで許可し得る場合もあり得る。いくつかの実施態様において、ＳＲＧのノー
ドは、一時停止／再始動する前に、自身のコミットレコードをあるより小さいシーケンス
番号まで同期し、一時停止の後、例えばノードが再始動し、「サービス対応可能」メッセ
ージを構成マネジャーに送信した後に、最大コミット済みシーケンス番号まで同期し得る
。前述のように、いくつかの実施形態において、一時停止手続きは、非コミッタノードに
より、または構成マネジャー自身により開始され得る。

複数データストアトランザクションのためのログベース楽観的並行処理制御
いくつかの実施形態において、複数の独立データストアを伴うトランザクションに対応
することを可能にするログサービスを使用して楽観的並行処理制御技術を実施するために
、前述の種類の複製ＤＡＧが使用され得る。図１５は、少なくともいくつかの実施形態に
よる、複数のデータストアへの書き込みを含み得るトランザクションに対応する持続的変
更ログを備える例示的システム環境を示す。システム１５００は、ログサービスを使用し
てインスタンス化され得る持続的変更ログ１５１０を示す。描かれた実施形態において、
データストア１５３０Ａ（例えばＮｏＳＱＬまたは非リレーショナルデータベース）及び
データストア１５３０Ｂ（例えばリレーショナルデータベース）等の１つまたは複数のデ
ータストア１５３０が、トランザクション管理のためにログサービスにおいて登録され得
る。用語「並行処理制御」、「トランザクション管理」、及び「更新管理」は、ログサー
ビスにより提供される機能に関して類義語として本明細書において使用され得る。ログサ
ービスは、いくつかの実施形態において、プロバイダネットワークにて実施され得る複数
の格納サービスのうちの一例とみなされ得る。

クライアント１５３２は、いくつかの実施形態において、それらが特定のアプリケーシ
ョンのログベーストランザクション管理を適用したいデータソース集合を示す登録要求を
、例えばログサービスマネジャー１５０１により提示される管理または制御プレーンプロ
グラマチックインターフェースを介して、提出し得る。持続的変更ログ１５１０は、いく
つかの実施形態において、このような登録要求に応じてインスタンス化され得る。一般に
、所定の持続的変更ログインスタンスは、１つまたは複数の基礎データストアのトランザ
クションを管理するために作成され得る。すなわち、少なくともいくつかの展開において
、ログベーストランザクション管理は、複数のデータストアに同時ではなく、単一のデー
タストアに使用され得る。本明細書において使用される用語「データストア」は、幅広い
種類の持続的または一時的データレポジトリ及び／またはデータコンシューマのうちのい
ずれかのインスタンスを指し得る。例えば、いくつかのデータストアは、複数アイテムト
ランザクションに対しネイティブ対応を必ずしも提供するとは限らない持続的非リレーシ
ョナルデータベースを備え、一方、他のデータストアは、複数アイテムトランザクション
に対しネイティブ対応を行い得る持続的リレーショナルデータベースを備え得る。いくつ
かの実施形態において、プロバイダネットワークのユーザが任意のサイズの非構造化デー
タオブジェクトを格納することを可能にする、ウェブサービスインターフースを介してア
クセス可能なプロバイダネットワークのネットワークアクセス可能格納サービスが、デー
タストアのうちの１つとして登録され得る。他の種類のデータストアは、インメモリデー
タベース、分散キャッシュのインスタンス、ネットワークアクセス可能ブロック格納サー
ビス、ファイルシステムサービス、またはマテリアライズドビューを含み得る。少なくと
も一実施形態において、データストアのうちの１つまたは複数は、プロバイダネットワー
クにおいて実施される待ち行列サービス及び／または通知サービスのコンポーネントを含
み得る。例えば新たなデータアーチファクトを生成するために、ログサービスにより記録
されたコミット済み書き込みを使うエンティティは、別の種類のデータストアを表し、本
明細書において一般的に「データコンシューマ」と称され得る。このようなデータストア
は、例えば、ログサービスを介して管理される特定データ集合に対する特定クエリの結果
を生成する責務を担う事前演算クエリ結果マネジャー（ＰＱＲＭ）（データストア１５３
０Ｃと同様）を含み得る（特定データ集合は１つまたは複数の異なる他のデータストアに
格納されたオブジェクトを含み得る）。いくつかの実施形態において、ログサービスを介
して管理される一部または全てのコミット済みデータの時点スナップショットを生成する
ように構成されたスナップショットマネジャーは、別のカテゴリのデータストアを表し得
る。このようなログスナップショットは、異なる実施形態において、バックアップのため
、またはオフライン作業負荷分析のため等、様々な目的で格納され得る。用語「データコ
ンシューマ」は、ＰＱＲＭ及びスナップショットマネジャー等のデータストアを指すため
に、本明細書において使用され得る。データストアのうちの少なくともいくつかは、他の
データストアの読み出しインターフェース１５３１とは異なる読み出しインターフェース
１５３１を有し得る。例えば、描かれた実施形態において、データストア１５３０Ａのデ
ータストア（ＤＳ）読み出しインターフェース１５３１Ａは、ＤＳ読み出しインターフェ
ース１５３１Ｂまたは事前演算クエリインターフェース１５３１Ｃとは異なるＡＰＩ集合
、ウェブベースインターフェース、コマンドラインツール、またはカスタムＧＵＩ（グラ
フィカルユーザインターフェース）を備え得る。

描かれた実施形態において、ログサービスクライアント１５３２は、トランザクション
要求をローカルで構築し、それからトランザクション要求を、持続的変更ログ１５１０に
よる承認及びコミットのために提出（または「提案」）し得る。一実施態様において、例
えば、ログサービスのクライアント側ライブラリにより、クライアントは「トランザクシ
ョン開始」要求の論理的均等物を発行することにより、候補トランザクションを開始する
ことが可能となり得る。候補トランザクション内で、クライアントは、データストア１５
３０における選択オブジェクト集合に対し複数の読み出しを行い、１つまたは複数のデー
タストアに対する提案書き込み集合をローカルで（例えばローカルメモリにおいて）行い
得る。クライアントはそれから、「トランザクション終了」要求の均等物を発行すること
により、候補トランザクションを提出し得る。描かれた実施形態において、候補トランザ
クション要求１５１６は、ログの書き込みインターフェース１５１２を介して、持続的変
更ログ１５１０に対応付けられた競合検出器１５０５にて受信され得る。一般に、少なく
ともいくつかの実施形態において、所定のトランザクション要求１５１６は、１つまたは
複数のデータストアそれぞれからの１つまたは複数の読み出しと、１つまたは複数のデー
タストアにそれぞれ対する１つまたは複数の提案書き込みとを含み、読み出されるデータ
ストア集合は、書き込まれているデータストア集合と重複し得る、あるいは重複し得ない
。いくつかの実施形態において、読み出しは、ネイティブＤＳ読み出しインターフェース
１５３１を使用して行われ得る（しかし後述のように、いくつかのシナリオにおいて、ク
ライアントは持続的変更ログ１５１０を介して読み出し専用動作も実行し得る）。

いくつかの実施形態において、所定のトランザクション要求内に示される書き込みのう
ちの少なくともいくつかは、読み出しのうちの１つまたは複数の結果に依存し得る。例え
ば、要求トランザクションは、データストアＤＳ１における位置Ｌ１から１つの値Ｖ１と
、データストアＤＳ２における第２位置Ｌ２から第２値Ｖ２とを読み出し、関数Ｆ（Ｖ１
、Ｖ２）を計算し、関数の結果をあるデータストアＤＳ３における位置Ｌ３に格納するこ
とを伴い得る。いくつかのロックベース並行処理制御機構においては、Ｌ３が更新される
前に値Ｖ１及びＶ２が確実に変更しないように、Ｌ１及びＬ２に対し排他的ロックが取得
される必要があり得る。図１５に例示されるログサービスの楽観的並行処理制御機構にお
いては、ロックは全く取得される必要はなくてよい。代わりに、描かれた実施形態におい
て、競合検出器１５０５は、トランザクション記述子１５１６のコンテンツと、持続的変
更ログ１５１０のコミット済みトランザクションログレコード１５２７の集合とに少なく
とも部分的に基づいて、要求トランザクション内で読み出されるデータアイテム集合は、
それらがそれぞれのデータストアから読み出された時から更新されたか否かを判定し得る
。さらに詳しく後述されるように、少なくともいくつかの実施形態において、このような
読み出し書き込み競合が存在するか否かを判定するために、シーケンス番号に基づいた技
術が使用され得る。競合検出器１５０５が、トランザクションが上書きされている間に読
み出されたデータは何もないと判定すると、要求トランザクションはコミットのために受
諾され、そしてこのようなコミット受諾済みトランザクション１５１４は、持続的変更ロ
グにおける対応ログレコードの複製のために提出され得る。用語「承認」及び「受諾」は
、拒否されなかった要求トランザクションに関する類義語として、本明細書において使用
され得る。対応読み出しが起こった後に読み出しデータの一部が更新された場合（または
競合検出器により推定されるデータが更新された確率が閾値より大きい場合）、描かれた
実施形態において、要求トランザクション１５１６は代わりに拒否またはアボートされ得
る。この種類の並行処理制御手法は、トランザクションの書き込み集合を続行するか否か
に関する判定が初めに、読み出し書き込み競合はあり得ないという楽観的仮定の下行われ
得るという点で、楽観的であるとみなされ得る。その結果、読み出し書き込み競合が実際
めったに起こらないシナリオにおいて、より多くの従来型ロックベース技術が使用される
場合に可能となり得るスループット及び応答時間よりも、高いスループット及び低い応答
時間が達成され得る。

トランザクションがコミットのために受諾された場合、描かれた実施形態において、コ
ミットが成功したとみなされる前に、コミット済みトランザクションログレコードのコン
テンツが、持続的変更ログ１５１０に対応付けられた複製ＤＡＧの複数のノードにおいて
複製され得る（より詳しく図１６に関して後述されるように）。必要数のレプリカが作成
されない場合、描かれた実施形態において、トランザクションは拒否またはアボートされ
得る。コミットに必要となるレプリカの数は、異なるアプリケーションまたはクライアン
トにより異なり得る。コミット済みトランザクションログレコードは、本明細書において
「コミットレコード」とも称され得る。いくつかの実施形態において、要求トランザクシ
ョンがコミットされると、要求クライアント１５３２に通知され得る。少なくとも一実施
形態において、トランザクションが拒否されると、クライアント１５３２に通知され、従
って例えば、所望の更新のために新たなトランザクション要求が生成され、提出され得る
。

少なくともいくつかの実施形態において、コミットされたトランザクションごとに、コ
ミットシーケンス番号（またはアプリケーションのコミット済みステートを示すある他の
識別子）が生成され、持続的変更ログ１５３２に格納され得る（例えばコミット済みトラ
ンザクションログレコードのそれぞれのレプリカの一部として）。このようなコミットシ
ーケンス番号は、ステート遷移のための複製ＤＡＧにおいて使用されるシーケンス番号に
関して前述されるように、例えばカウンタとして、または論理タイムスタンプとして実施
され得る。コミットシーケンス番号は、例えば、いくつかの実施形態において競合検出器
により、または他の実施形態において持続的変更ログの別のコンポーネント（使用されて
いる複製ＤＡＧのコミッタノード等）において、決定され得る。描かれた実施形態におい
て、所定のトランザクションがコミットされ、そのコミットレコードが持続的変更ログに
格納された後、トランザクションの書き込みは、データストア１５３０のうちの書き込み
対象となる１つまたは複数に、適用または伝播され得る（またはＰＱＲＭ１５３０Ｃの場
合のように、書き込みデータは使用される）。いくつかの実施態様において、書き込みは
、対象データストア１５３０に非同期的にプッシュされ得る。従って、このような実施態
様において、トランザクションがコミットされた時間（すなわちコミットレコードの必要
数のレプリカが無事格納された時）と、コミット済みトランザクションの特定書き込み動
作のペイロードが対応データストアに到達する時間の間に、ある遅延が生じ得る。図１５
に示される実施形態において、一部または全ての書き込みを関連データストアに伝播する
ために、それぞれの非同期書き込みアプライヤ１５１７が使用され得る。例えば、書き込
みアプライヤ１５１７Ａはデータストア１５３０Ａに関連する書き込み１５１５Ａを適用
するように構成され、書き込みアプライヤ１５１７Ｂはデータストア１５３０Ｂに関連す
る書き込みをプッシュし、そして書き込みアプライヤ１５１７Ｃはデータストア１５３０
Ｃにて使用される書き込みをプッシュする。いくつかの実施態様において、書き込みアプ
ライヤは持続的変更ログ１５１０のサブコンポーネント（例えばスレッドまたはプロセス
）を含み、一方、他の実施態様において、書き込みアプライヤ１５１７は持続的変更ログ
の外部エンティティとして実装され得る。いくつかの実施形態において、所定の書き込み
アプライヤ１５１７は、複数のデータストア１５３０に書き込みを伝播する責務を担い得
る、または単一のデータストア１５３０は、複数の書き込みアプライヤ１５１７から書き
込みを受信し得る。少なくとも一実施態様において、書き込みデータをデータストアに伝
播するのにプル技術が使用され得る。例えば、１つまたは複数のデータストア１５３０は
、書き込みアプライヤ主導で書き込みデータを提供される代わりに、持続的変更ログ１５
１０または書き込みアプライヤに対し書き込みの要求を提出し得る。トランザクション中
に書き込まれるデータが対応データストアに適用された後、クライアント１５３２は、更
新されたデータを、データストアのそれぞれの読み出しインターフェースを使用して読み
出すことが可能であり得る。いくつかの実施形態において、書き込みアプライヤのうちの
少なくとも１つは、同期書き込みを実行することが可能であり得る（例えば、そうするよ
うにログサービスにより明示的に指示された時、またはアプライヤが担当する全ての書き
込みに関して）。例えば、クライアントは、トランザクションがコミットされたことを通
知されるより先に、所定のトランザクションの少なくとも１つの書き込み（トランザクシ
ョンに伴う、複数のデータストアのうちの「マスタ」データストアに対する書き込み等）
が適用されたことの確認を所望し得る。いくつかの実施形態において、同期的に行う特定
の書き込みが、トランザクション要求１５１６内に示され得る。

さらに詳しく後述されるように、いくつかの実施形態において、所定のトランザクショ
ン要求１５１６は、トランザクションの読み出し集合のインジケータ（すなわちトランザ
クション中に読み出されるデータオブジェクト集合を特定する情報）、トランザクション
の書き込み集合のインジケータ（すなわちトランザクションがコミットされると更新／書
き込みが行われるデータオブジェクト集合を特定する情報）、書き込みペイロードのイン
ジケータ（すなわち書き込みごとに格納されるデータバイト集合）、及び／または競合検
査デリミタのインジケータ（トランザクションを受諾／拒否するために調べられるべきコ
ミット済みトランザクションログレコードの部分集合の指示）を含み得る。トランザクシ
ョン要求のこれらの構成要素のうちの一部または全ては、トランザクションのコミットシ
ーケンス番号と一緒に、対応コミットレコード内に格納され得る。少なくとも一実施形態
において、持続的変更ログ１５１０は、例えばデータストアからのクエリ、またはログサ
ービスクライアントからのクエリに応じて、アプリケーションの最新コミット済みステー
トの識別子１５９０（これまでに生成された最大コミットシーケンス番号等）を提供し得
る。描かれた実施形態において、書き込みアプライヤは、データストアに適用する書き込
みに対応するコミットシーケンス番号を示し得る。従って、いずれかの所定の時点で、ク
ライアント１５３２は、所定のデータストア１５３０における最新適用済み書き込みに対
応するコミットシーケンス番号を特定することが可能であり得る（例えばデータストアに
問い合わせることで）。

少なくともいくつかの実施形態において、トランザクション要求の生成中（例えばログ
サービスのクライアントライブラリにより）、トランザクション中にアクセスされるデー
タストアから最新適用済みコミットタイムスタンプが取得され、そしてこのようなコミッ
トシーケンス番号のうちの１つまたは複数は、競合検査デリミタとしてトランザクション
要求内に示され得る。例えば、特定のクライアントがデータストアＤＳ１における位置Ｌ
１の読み出しを含むトランザクションを開始する時に、ＤＳ１における最新適用済み書き
込みに対応するコミットシーケンス番号がＳＮ１であるシナリオを考察する。当実施例に
おいて、トランザクションの読み出し集合はＤＳ１のデータのみから成るとさらに仮定す
る。このようなシナリオにおいて、ＳＮ１は、トランザクション要求１５１６に含まれ得
る。競合検出器は、要求トランザクションの読み出し書き込み競合に関して調べるコミッ
トレコード集合として、ＳＮ１より大きいシーケンス番号を有するコミットレコードを特
定し得る。特定されたコミットレコードの書き込み集合のうちのいずれかが、要求トラン
ザクションの読み出し集合と重複する場合、トランザクションは拒否／アボートされ得る
。そうでなければ、当例示的シナリオにおいてトランザクションはコミットに承認され得
る。

描かれた実施形態において、クライアント１５３２が直接ログレコードを読みだせるよ
うに、ログサービスは、１つまたは複数のプログラマチックログ読み出しインターフェー
ス１５１３（例えばＡＰＩ、ウェブページ、コマンドラインユーティリティ、ＧＵＩ等）
を開示し得る。別の実施形態において、変更ログ１５１０へ直接アクセスすることを可能
にするこのような読み出しＡＰＩは、実装され得ない。コミットされた特定トランザクシ
ョンを示すログレコードに直接アクセスし、かつ特定トランザクションがコミットされた
順序を確定する機能は、いくつかの実施形態において、データストアにのみ直接アクセス
することにより可能となり得る分析と比べ、新たな種類の分析を行うことを可能にし得る
（データストアのうちの少なくともいくつかにより、通常読み出し者は、最新適用済みバ
ージョンのデータオブジェクトを参照することのみ可能であり、データオブジェクトの履
歴を参照することは不可能であるため）。

図１５に例示される楽観的並行処理制御機構は、少なくともいくつかのシナリオにおい
て、基礎データストアの並行処理制御機構を使用することで可能であり得る原子動作と比
べて、より複雑な種類の原子動作に対応することを可能にし得る。例えば、いくつかの高
性能の非リレーショナルデータストアは、単一アイテムのトランザクションのみを許可し
得る（すなわち書き込みは１度に１つ許可されるが、単一のバッチ更新において複数の書
き込みが提出された場合、一緒に対応される複数書き込みには原始性／整合性保証は提供
され得ない）。前述のログベース手法により、非リレーショナルデータストア（及び／ま
たは同様に他のデータストア）の複数の位置に対する書き込みをもたらす単一のトランザ
クションは、比較的容易に対応され得る。持続的変更ログ１５１０は、対応付けられた競
合検出器１５０５と一緒に、本明細書においてログベーストランザクションマネジャーと
称され得る。いくつかの実施形態において、書き込みアプライヤ１５１７もまた、トラン
ザクションマネジャーのサブコンポーネントとみなされ得る。

前記のように、いくつかの実施形態において、持続的変更ログ１５１０は、前述される
複製ＤＡＧを使用して実施され得る。図１６は、少なくともいくつかの実施形態による、
複製ＤＡＧ１６４０を使用する持続的変更ログの例示的実施態様を示す。描かれた実施形
態において、ＤＡＧにより管理されるアプリケーションステート遷移は、１つまたは複数
のデータストアの集合を対象とする読み出し及び書き込みを含む適用の一部として、ログ
クライアント１６６０により要求されるトランザクションに対応する。アプリケーション
のステートは、受諾ノード１６１０、中間ノード１６１２、及びコミッタノード１６１４
を含む現行複製経路を有する受諾ノード１６１０、中間ノード１６１２、コミッタノード
１６１４、及び待機ノード１６１６におけるローカル格納域に格納されるそれぞれのトラ
ンザクションレコード集合１６７２として形成され得る。いくつかの実施態様においては
、承認（すなわち要求トランザクションがコミットに承認されたことを示す）とコミット
の別個のトランザクションレコードが格納され、一方、別の実施形態においては、単一の
トランザクションレコードが、トランザクションがコミットされたか否かを示すフィール
ドと共に格納され得る。シーケンス番号または論理タイムスタンプは、描かれた実施形態
において、トランザクションレコードのうちの少なくともいくつかの部分として格納され
得る、あるいはトランザクションレコードのうちの少なくともいくつかにより示され得る
。

要求トランザクション１６５０がコミットのために承認されるか否かに関する判定は、
描かれた実施形態において、受諾ノード１６１０に実装される競合検出器により行われ得
るが、別の実施形態において、競合検出器は複製ＤＡＧの外に実装され得る。フォールト
トレラントログ構成マネジャー１６４は、ＤＡＧノード１６１０、１６１２、１６１４、
１６１６に対し、それぞれのメッセージがＤＡＧの構成全体ではなくＤＡＧ構成に対する
変更を示し、かつクライアント１６６０により提出される受信トランザクション要求のス
トリームの処理を中断するようＤＡＧノードに要求しない、構成デルタメッセージを非同
期的に送信し得る。各ＤＡＧノードは、受信した構成デルタメッセージを自主的に処理ま
たは集約して、現行ＤＡＧ構成に関する各自の見解１６７４（例えばノード１６１０にお
ける見解１６７４Ａ、ノード１６１２における見解１６７４Ｂ、ノード１６１４における
見解１６７４Ｃ、及びノード１６１６における見解１６７４Ｄ）に到達させ得る。見解１
６７４のうちの少なくともいくつかは、所定の時点で他のノードの見解と異なり得るが、
このように、通常の動作条件の下、異なるＤＡＧノードは、お互いにそれらのＤＡＧ構成
見解を同期させなくてもよい。承認された（しかしまだコミットされていない）トランザ
クションを示すメッセージ１６５２Ａ、１６５２Ｂが、受諾ノード１６１０、中間ノード
１６１２から複製経路沿いにそれぞれ送信され得る。描かれた実施形態において、コミッ
タノード１６１４は、コミットを示すメッセージ１６５３を、受諾及び中間ノードへ、並
びに待機ノード１６１６へ、送信し得る。図１６の実施形態において複製ＤＡＧの外にあ
るエンティティとして示される非同期書き込みアプライヤ１６９２は、様々なコミット済
みトランザクションレコードからの書き込みを、適切なデータストアまたはデータコンシ
ューマに伝播し得る。別の実施形態において、書き込みアプライヤは、例えばＤＡＧノー
ド内で作動するそれぞれのプロセスのように、複製ＤＡＧ内に実装され得る。いくつかの
実施態様において、コミット済み書き込みをそれらの目的データソースまたはコンシュー
マに伝播するために、ＤＡＧノードの部分集合のみがアプライヤ１６９２により読み出さ
れ得る。別の実施形態において、図１６に示されるように、アプライヤはＤＡＧノードの
うちのいずれかからコミット済みトランザクションレコードを読み出し、前述のように書
き込みペイロードのコンテンツをプッシュし得る。

トランザクション要求構成要素
図１７は、少なくともいくつかの実施形態による、ログサービスのクライアント１７３
２により提出され得るトランザクション要求記述子１７４４の例示的コンポーネント要素
を示す。示されるように、描かれた実施形態において、トランザクション記述子１７４４
は、競合検査デリミタ１７０２と、読み出し集合記述子１７０４と、書き込み集合記述子
１７０６と、書き込みペイロード（複数可）１７０８と、任意の論理制約記述子１７１０
とを含み得る。示される実施例において、ログサービスクライアント１７３２は、トラン
ザクション要求記述子を組み立てるために使用され得るクライアントライブラリ１７５６
を備える。少なくともいくつかの実施形態において、クライアントライブラリは、トラン
ザクション中にデータが読み出されるデータストア１７３０Ａ、１７３０Ｂ、１７３０Ｃ
内のそれぞれの読み出し位置１７６１Ａ、１７６１Ｂ、１７６１Ｃ、及び／またはデータ
が書き込まれる書き込み位置１７７１（描かれた実施例におけるデータストア１７３０Ｃ
の書き込み位置１７７１）を、自動で記録し得る。いくつかの実施態様において、クライ
アントライブラリ１７５６はまた、それぞれのデータソース１７３０から、ごく最近デー
タストアに適用された書き込みを含む最新トランザクションの対応コミットシーケンス番
号（ＣＳＮ）も取得し得る。一実施形態において、このようなＣＳＮは、例えば、トラン
ザクションの読み出しのうちのいずれかが対応データストアに発行される前に、取得され
得る。別の実施形態において、ＣＳＮは、所定のデータストア１７３０から取得され得る
が、それは、現行のトランザクション内のそのデータストアに向けられた第１読み出しが
発行される直前である。

描かれた実施形態において、競合検査デリミタ１７０２は、最新適用済みＣＳＮが入力
として提供される関数から引出され得る。例えば、一実施態様においては、トランザクシ
ョン中に読み出される全てのデータストアから取得されるＣＳＮの中の最小シーケンス番
号が使用され得る。別の実施態様においては、それぞれのデータストアからのＣＳＮから
成るベクトルまたはアレイが、トランザクション要求記述子の競合検査デリミタ１７０２
として含まれ得る。競合検査デリミタ１７０２はまた、要求トランザクションが依存する
１つまたは複数のデータストアのコミット済みステートを表すため、本明細書においてコ
ミット済みステート識別子（ＣＳＩ）とも称され得る。いくつかの実施形態において、読
み出し記述子１７０４に含めるためのハッシュ値集合を取得するために、選択されたハッ
シュ関数が、それぞれの読み出し位置１７６１Ａ、１７６１Ｂ、または１７６１Ｃに適用
され得る。同様に、書き込み集合記述子１７０６を生成するために、選択されたハッシュ
関数（実施態様により、読み出し記述子に使用された関数と同じ関数、または異なる関数
）が、トランザクションの書き込み（複数可）の位置に適用され得る。別の実施形態にお
いて、ハッシュ法は使用され得ず、代わりに、例えば非ハッシュ化位置識別子が、それぞ
れの読み出し及び書き込み集合エントリに使用され得る。書き込みペイロード１７０８は
、トランザクションに含まれるそれぞれの書き込みの書き込むデータの表現を含み得る。
任意の論理制約１７１０は、さらに詳しく後述されるように、重複検出／排除のために、
及び／または特定トランザクションを他のトランザクションの前または後に順序付けるた
めに、使用されるシグネチャを含み得る。トランザクション要求記述子１７４４のコンテ
ンツの一部または全ては、いくつかの実施形態において、持続的変更ログ１５１０に複製
されるトランザクションステートレコード（例えば承認済みトランザクションレコード及
び／またはコミット済みトランザクションレコード）の一部として、格納され得る。

異なる実施形態において、または異なるデータストアに関して、読み出し記述子及び書
き込み記述子を生成する基となる読み出し及び書き込み位置は、異なる格納粒度、または
異なる種類の論理エンティティさえ表し得ることに留意されたい。例えば、特定のデータ
オブジェクトがコンテナ名（例えばテーブル名）と、ユーザ名（コンテナの所有者を示す
）と、あるキー集合（例えばハッシュキー及び範囲キー）との組み合わせにより表される
非リレーショナルデータベースを含むデータストアの場合、読み出し集合は、タプル（コ
ンテナＩＤ、ユーザＩＤ、ハッシュキー、範囲キー）の関数として取得され得る。例えば
リレーショナルデータベースの場合、タプル（テーブルＩＤ、ユーザＩＤ、ローＩＤ）ま
たは（テーブルＩＤ、ユーザＩＤ）が使用され得る。

様々な実施形態において、トランザクションマネジャーは、トランザクション要求のコ
ンテンツと持続的変更ログとを使用して、トランザクション要求内に示される読み出しと
、ログ内に示される書き込みとの競合を特定する責務を担い得る。比較的単純な読み出し
動作の場合、読み出された位置に基づいてハッシュ値を生成して、読み出された位置のハ
ッシュ値を変更ログ内に示される書き込みのハッシュ値と比較することは、競合を検出す
るのに十分であり得る。いくつかの実施形態におけるより複雑な読み出し要求の場合、位
置ベースのハッシュ値を使用することは、必ずしも十分ではあり得ない。例えば、読み出
し要求Ｒ１が「テーブルＴ１から文字“Ｇ”で始まる製品名を選択」というクエリを含み
、そして元の結果集合は“Ｇｏｏｄ‐ｐｒｏｄｕｃｔ１”であったシナリオを考察する。
Ｒ１の結果に依存する書き込みＷ１を含むトランザクション要求が受諾のために調べられ
るまでに、製品名“Ｇｒｅａｔ‐ｐｒｏｄｕｃｔ２”がテーブルに挿入された場合、“Ｇ
ｏｏｄ‐ｐｒｏｄｕｃｔ１”のデータオブジェクトの位置は変更されておらず、よってロ
グの書き込みレコードは示され得ないとしても、トランザクション受諾決定が行われた時
にＲ１をもう１度実行したら、Ｒ１の結果集合は変わり得ることとなる。このような読み
出しクエリに関する、または値の範囲を伴う読み出しクエリ（例えば「＄１０〜＄２０の
価格の製品の製品名集合を選択」）に関する読み出し書き込み競合に対応するために、い
くつかの実施形態において、論理または述語ベースの読み出し集合記述子が使用され得る
。従って、前述の位置ベースの読み出し集合インジケータは、読み出し書き込み競合検出
の様々な実施形態において使用され得る結果集合変更検出メタデータの単なる一例示的カ
テゴリとみなされ得る。

読み出し書き込み競合検出
図１８は、少なくともいくつかの実施形態による、ログベーストランザクションマネジ
ャーにおける読み出し書き込み競合検出の実施例を示す。描かれた実施形態において、持
続的変更ログ１８１０に格納されたトランザクションコミットレコード（ＣＲ）１８５２
は、コミットシーケンス番号をログの上部から下部に向かって昇順で配置されるように示
される。最新または最近のコミット済みトランザクションは、コミットシーケンス番号（
ＣＳＮ）１８０４Ｆと書き込み集合記述子（ＷＳＤ）１８０５Ｆとを含むＣＲ１８５２Ｆ
により表される。それぞれのＣＲ１８５２Ａ、１８５２Ｂ、１８５２Ｃ、１８５２Ｄ、１
８５２Ｅは、対応ＣＳＮ１８０４（例えばＣＳＮ１８０４Ａ〜１８０４Ｅそれぞれ）と、
対応ＷＳＤ１８０５（例えばＷＳＤ１８０５Ａ〜１８０５Ｅ）とを含む。

示されるように、トランザクション要求記述子１８４４は、競合検査デリミタ（または
コミット済みステート識別子）１８４２と、読み出し集合記述子１８４６と、書き込み集
合記述子１８４８とを含む。（要求トランザクションの読み出し集合書き込みペイロード
は図示せず）。ログベーストランザクション管理システムの競合検出器は、要求トランザ
クションの読み出し集合との競合検査対象となるログ１８１０のＣＲ集合を特定するよう
に求められ得る。競合検査デリミタ１８４２は、「一致」と表示される矢印により示され
るように、描かれた実施形態において、要求トランザクションとの読み出し書き込み競合
の調査対象となる集合１８０９の開始ＣＲを特定するために競合検出器が使用し得る下限
ＣＳＮを示す。集合１８０９は、いくつかの実施形態において、一致シーケンス番号から
始まり、最新コミット済みトランザクション（ＣＲ１８５２Ｆ）までの全てのＣＲを含み
得る。ＣＲ集合１８０９により示される書き込みのうちのいずれかが、トランザクション
要求１８４４内に示される読み出しのうちのいずれかと重複する場合、このような読み出
し書き込み競合は、要求トランザクションの拒否を引き起こし得る。異なる実施形態にお
いて、このような重複が存在するか否かを検査するために、様々な機構が使用され得る。
一実施形態において、例えば、読み出し集合記述子１８４６内に示される読み出しがＣＲ
集合１８０９内に示される書き込みと競合するか否かを判定するために、１つまたは複数
のハッシュベースの演算またはプローブが使用され、これによりＣＲ集合の順次走査が回
避される。いくつかの実施態様において、例えばＣＲ集合１８０９内のレコード数が閾値
より小さい場合、ＣＲ集合１８０９の順次走査が使用され得る。ＣＲ集合１８０９内に示
される書き込みの全てが要求トランザクションの読み出しのうちのいずれとも重複しない
場合、トランザクション要求の準備中に読み出されたデータ全ては、それらが読み出され
て以降変更し得なかったため、トランザクションは受諾され得る。少なくとも一実施形態
において、トランザクション要求記述子はまた、競合検査対象となるトランザクションレ
コードのシーケンス番号の上限も示す。例えば、競合検査デリミタは、ＣＳ１８５２の集
合内の開始ポイント及び終了ポイントの両方を示し得る。

楽観的ログベース並行処理制御の方法
図１９は、少なくともいくつかの実施形態による、ログサービスで行われ得る制御プレ
ーン動作態様を示すフロー図である。示される管理または設定関連動作のうちの少なくと
もいくつかは、例えばログサービスに実装される１つまたは複数の管理プログラマチック
インターフェースの呼び出しに応じて、図１５に例示されるようなログサービスマネジャ
ー１５０１により実行され得る。構成要素１９０１に示されるように、１つまたは複数の
データストアは、例えば前述の読み出し書き込み競合検出手法を使用して楽観的並行処理
制御機構を実施するログサービスを介して、トランザクション管理に登録され得る。それ
ぞれの別個の読み出しインターフェースを有する様々な種類のデータストアのトランザク
ション管理は、異なる実施形態において、ログベース手法を使用して実施され得る。様々
な種類のデータストアには、例えばリレーショナルデータベース、非リレーショナルデー
タベース、インメモリデータベース、プロバイダネットワーク実施格納サービス、分散キ
ャッシュコンポーネント、事前演算クエリ結果マネジャー、スナップショットマネジャー
、待ち行列サービス、通知サービス等のインスタンスが含まれる。いくつかの実施形態に
おいて、所定のログインスタンスを使用して管理される一部または全ての基礎データスト
アは、いくつかの従来型リレーショナルデータベースシステムにより対応されるＡＣＩＤ
特性（原子性、一貫性、独立性、及び耐久性）のうちの少なくともいくつかに対応し得な
い。

ログサービスは、例えばプロバイダネットワークで実施されるプロビジョニングサービ
スの助力を得て、登録データストアのために実施する持続的変更ログの複製ＤＡＧノード
に使用するホスト集合を特定し得る（構成要素１９０４）。１つまたは複数のホストは、
複製ＤＡＧの構成マネジャーのためにも特定され得る。例えば、前述のように、ＤＡＧ構
成変更を実施するために同意ベースプロトコルを使用するノードのクラスタが、いくつか
の実施態様において使用され得る。複製ノード及び構成マネジャーは、選択されたホスト
においてインスタンス化され得る。競合検出器、１つまたは複数の書き込みアプライヤ、
及び持続的変更ログの任意の読み出しインターフェースマネジャーを含むログベーストラ
ンザクション管理機構の他のコンポーネントが設定され得る（構成要素１９０７）。ログ
の読み出しインターフェースマネジャーは、いくつかの実施形態において、ログに直接提
出される（登録データストアの読み出しインターフェースに提出される代わりに）読み出
し要求に応答する責務を担い得る。一例示的実施態様において、ログにおいてトランザク
ションがコミットされると、通知に従うそれぞれのプロセスまたはスレッドとして書き込
みアプライヤがインスタンス化され得る。競合検出器は、いくつかの実施形態において、
ログの読み出しインターフェースを使用するモジュールを備え得る。競合マネジャーの設
定は、例えば、重複排除または順序付けに対応する制約検査動作に対し読み出し書き込み
競合が特定される順序、クライアントに応答が提供される方法（例えばトランザクション
拒否／コミットに関してクライアントが通知されるか否か、並びにどのように通知される
か）等を確立することを含み得る。いくつかの実施形態において、競合検出器、書き込み
アプライヤ、及び／またはログ読み出しインターフェースマネジャーは、マルチテナント
様式で実装され得る。例えば、所定の競合検出器、書き込みアプライヤ、または読み出し
インターフェースマネジャーは、それぞれのログインスタンスが確立された複数のクライ
アントに対し自身のサービスを提供し得る。

持続的変更ログの様々なコンポーネントが設定された後、例えば適切なネットワークア
ドレス及び／または認証情報をクライアントに提供することで、クライアントからのトラ
ンザクション要求の流れが可能になり得る（構成要素１９１０）。少なくともいくつかの
実施形態において、ログサービスにて行われる制御プレーン動作は、格納されたトランザ
クションステートレコードを部分的に削減またはアーカイブすることを含み得る（構成要
素１９１４）。いくつかのこのような実施形態において、例えば、所定の持続的変更ログ
のトランザクションレコードに使用される格納量が閾値を超える場合、複数の最古トラン
ザクションレコードは、異なる格納設備（プロバイダネットワーク格納サービス、または
近頃のトランザクションレコード集合に使用される格納デバイスよりも遅い格納デバイス
集合等）にコピーされ得る。別の実施形態において、最古トランザクションレコードは、
単純に破棄され得る。少なくとも一実施形態において、例えば第１変更ログが閾値レコー
ド保有数に達した場合、持続的変更ログのあるインスタンスを別のものと交換する等の他
の制御プレーン動作は、必要に応じて実行され得る。

図２０は、少なくともいくつかの実施形態による、クライアントから受信されるトラン
ザクション要求に応じてログサービスで行われ得る動作態様を示すフロー図である。構成
要素２００１に示されるように、ログサービスの競合検出器は、例えば競合検査デリミタ
と、読み出し集合と、持続的変更ログがログサービスにより確立された１つまたは複数の
データストアにおけるそれぞれの位置に対する１つまたは複数の書き込みを含む書き込み
集合とを示す、トランザクションＴ１のトランザクション要求記述子を受信し得る。競合
検査デリミタは、トランザクションの読み出しの結果の取得元となる１つまたは複数のソ
ースデータストアのコミット済みステートを示し、従ってコミット済みステート識別子（
ＣＳＩ）として機能し得る。ＣＳＩはまた、ソースデータストアの時点論理スナップショ
ットに対応し得るため、いくつかの環境において「スナップショットシーケンス番号」と
も称され得る。例えば競合検査デリミタと、ログに格納されたトランザクションレコード
のシーケンス番号とを使用して、要求トランザクションとの可能性のある競合を検査する
ための、持続的変更ログに格納されたトランザクションレコードの集合Ｓ１が特定され得
る（構成要素２００４）。このような集合Ｓ１は、例えば、一実施形態において、競合検
査デリミタ内に示されるシーケンス番号より大きいコミットシーケンス番号を有するトラ
ンザクションのレコード全てを含み得る。

読み出し書き込み競合が検出された場合（構成要素２００７）、例えば要求トランザク
ションの読み出し集合は集合Ｓ１のトランザクションのうちの１つの書き込み集合と少な
くとも部分的に重複する場合、トランザクションＴ１は、拒否または破棄され得る（構成
要素２０２２）。いくつかの実施形態において、このような重複が存在するか否かを判定
するためにハッシュ関数が使用され得る。例えば読み出し集合のハッシュ値が書き込み集
合と同じ場合、競合が生じたと推測され得る。いくつかの実施態様において、受信したト
ランザクション要求の送信元であるクライアントに対し拒否の開示または通知が提供され
、これによりクライアントは、別の要求記述子を生成、提出してトランザクションを再試
行することが可能になる。競合が検出されなかった場合（同様に構成要素２００７にて判
定）、Ｔ１はコミットのために受諾され得る（構成要素２０１０）。描かれた実施形態に
おいて、Ｔ１のトランザクションレコードの複製が、持続的格納域に対し、例えばログの
複数の複製ＤＡＧノードにおいて開始され得る。いくつかの実施形態において、Ｔ１がコ
ミットのために受諾された場合、受諾シーケンス番号がＴ１に割り当てられ、受諾シーケ
ンス番号は、トランザクション要求記述子構成要素のうちの少なくともいくつかのコンテ
ンツと一緒に各レプリカに格納され得る。少なくとも一実施形態において、受諾シーケン
ス番号は、トランザクションが最終的にコミットされた場合に、コミットシーケンス番号
として使用され得る。

トランザクションＴ１のコミットが完了する前に、トランザクションが管理されている
アプリケーションのデータ耐久性要求に応じて、レプリカの閾値数が格納される必要があ
り得る。十分な数のレプリカが保存されると（構成要素２０１３にて判定）、コミットは
成功したと推測され、コミット完了に関して、いくつかの実施形態において要求クライア
ントに対し通知が行われ得る（構成要素２０１４）。ある理由で持続的格納域に保存され
得るレプリカの数が要求される閾値を下回る場合（同様に構成要素２０１３にて検出）、
トランザクションはアボート／拒否され得る（構成要素２０２２）。Ｔ１コミット後、描
かれた実施形態において、Ｔ１の書き込み集合内に示される書き込み動作は、例えば非同
期書き込みアプライヤにより、対応データストアまたはデータコンシューマに適用され得
る（構成要素２０１６）。いくつかの実施形態において、書き込みアプライヤのうちの少
なくとも１つは同期式であり得る。例えば、更新が同期的に適用されるトランザクション
の書き込みの部分集合をこのような同期書き込みアプライヤが完了して初めて、トランザ
クションはコミットされたことがクライアントに対し通知され得る。更新が適用された後
、更新されたデータ要素は、それぞれのデータストアの読み出しインターフェースを介し
て受信されるクライアント読み出し要求に応じて読み出され得る（構成要素２０１９）。
様々な登録済みデータストアにより対応される読み出しインターフェースに加えて、少な
くともいくつかの実施形態において、持続的変更ログ自体も、例えばログサービスのプロ
グラマチッククエリ／読み出しインターフェースを介して、トランザクションレコードコ
ンテンツに関して直接問い合わせられ得る。データストアはログ内に既に存在する書き込
みを伝播するために非同期アプライヤに依存し得るため、いくつかの実施態様において、
このようなログサービスインターフェースを介してログを対象とする読み出しは、データ
ストアを対象とする読み出しよりも、場合によってはより速く書き込み動作の結果を参照
することが可能であり得る。いくつかの実施形態において、トランザクションがログにコ
ミットされるとすぐにデータストアに書き込みを伝播する同期アプライヤが使用され得る
。別の実施形態において、各アプライヤは、書き込みが対応データストアまたはコンシュ
ーマに伝播されなければならない設定可能時間窓を有し得るため、トランザクションコミ
ットと、データストアにおけるトランザクションの変更データの出現との間の最大遅延を
調整することが可能となる。

図２１は、少なくともいくつかの実施形態による、それぞれの特例整合性目標を達成す
るために使用され得るトランザクション要求記述子の実施例を示す。一実施形態において
、ログサービスのクライアントは、書き込みがコミットされるとすぐにそれが全てのリー
ダーで参照可能となる「読み出し後書き込み」整合性セマンティックを施行することを所
望し得る。読み出し後書き込み整合性を確保するために、すなわち読み出しでは常にデー
タのコミット直後に当該データを確実に「参照」するように、クライアントは、読み出し
専用トランザクションであっても（並びに書き込みを含むトランザクションに関しても）
トランザクション要求を提出することを所望し得る。読み出し専用トランザクション要求
記述子（ＴＲＤ）２１４４は、例えば、空書き込み集合２１０６Ａと空書き込みペイロー
ド２１０８Ａとを有するが、非空競合検査デリミタ２１０２Ａと非空読み出し集合記述子
２１０４Ａとを有する。このような読み出し専用トランザクション要求記述子を受信する
と、競合検出器は、要求内に示される読み出し集合と、競合検査デリミタ内に示されるシ
ーケンス番号より大きいシーケンス番号を有するコミットされた書き込みとの間に、重複
が存在するか否かを調べ得る。競合が検出された場合、読み出し専用トランザクションは
拒否され、従って、要求トランザクションがこれらの読み出しに依存するいずれの書き込
みも含まないにもかかわらず、競合検査デリミタが生成された後に書き込みがコミットさ
れ得た位置に対する読み出しは却下される。

少なくともいくつかの実施形態において、書き込み専用トランザクション要求が、特定
の状況下でログサービスに提出され得る。いくつかのアプリケーションに関して、クライ
アントは、少なくともいくつかの時間帯において、またはいくつかのデータストアに関し
て、読み出し書き込み整合性検査を施行することを所望しない場合もあり得る。代わりに
、クライアントは、このような時間帯において、いくつかの書き込みがコミットのために
無条件に受諾されることを所望し得る。従って、空読み出し集合２１０４Ｂ及び／または
空競合検査デリミタ２１０２Ｂを有し、非空書き込み集合記述子２１０６Ｂ及び非空書き
込みペイロード２１０８Ｂを有するトランザクション要求記述子２１４５が提出され得る
。例えばデータストアまたはオブジェクトが初めにデータ投入されている場合、またはあ
る時間帯に１つの書き込みクライアントのみが要求を提出していることが分かっている場
合、このような書き込み専用要求が提出され得る。

前述のように、いくつかの実施形態において、持続的変更ログからのコミット済み書き
込みのコンテンツを様々なデータストアまたはデータコンシューマに対し伝播するために
、非同期書き込みアプライヤが使用され得る。書き込み伝播の非同期的特性の結果、いく
つかの時点で、コミット済み書き込み集合がそれらの対象データストアへまだ伝播されて
いない場合もあり得る。少なくとも一実施形態において、書き込み専用トランザクション
を使用して、このような非適用済み書き込みをフラッシュすることが可能であり得る。例
えば、特定の書き込みアプライヤＷＡ１が所定のデータストアＤＳ１に対し未処理の非適
用済み書き込みをＮ個までしか有さないように構成される場合、クライアントは、未処理
のコミット済み書き込みをフラッシュするために特にまたは主に使用されるＤＳ１内の特
別書き込み位置ＷＬ１に対し、ＴＲＤ２１４５等の書き込み専用トランザクション要求記
述子を提出し得る。いくつかの事例において、このようなＴＲＤは、いずれの書き込みペ
イロードも全く有さなくてもよい（例えば、書き込みペイロード２１０８Ｂはヌルに設定
され得る）。このような書き込み適用フラッシュトランザクション要求が受諾されると、
新たな未処理コミット済み書き込みがログとＷＡ１の未処理要求待ち行列とに追加され得
る。待ち行列の長さが増大すると、ＷＡ１は、非適用済み書き込みはＮ個以下という自身
の要件を満たすために、待ち行列内の早期コミット済み書き込みを適用し始める必要があ
り得る。いくつかの実施形態において、確実にコミット済み書き込みが長時間未処理の状
態で残されないように、このような書き込み適用フラッシュ要求は、例えば１秒に１度等
、定期的に提出され得る。書き込み適用フラッシュトランザクションのコミット済み書き
込みがアプライヤの待ち行列の先頭に達した時、いくつかの実施態様において、物理的書
き込みが実行される必要はない。代わりに、例えばアプライヤは単純に、トランザクショ
ンに対応するコミットシーケンス番号を最新「適用済み」書き込みのインジケータとして
、目的データストアへ送信し得る。

いくつかのアプリケーションに関して、クライアントは、少なくともいくつかの時間帯
において、厳密なシリアライゼーションを施行することを所望し得る。すなわち、トラン
ザクション中のデータ読み出しと、トランザクション準備が開始されてからコミットされ
得た書き込みとの間に任意の競合が存在するか否かにかかわらず、１度に１つのみの（書
き込み含有）トランザクションを進行することが許され得る。このようなシナリオにおい
て、クライアントは、ログサービスに対し、厳密シリアライゼーショントランザクション
要求記述子２１４６を、アプリケーションにより使用された全てのデータ集合の全コンテ
ンツを示すその読み出し集合記述子２１０４Ｃと共に提出し得る。読み出し／書き込み位
置のインジケータとしてハッシュ値が使用され、かつ競合検出のために書き込み集合エン
トリとのビット単位比較が使用される一実施態様において、例えば、読み出し集合記述子
２４０２Ｃに含まれるハッシュ値は、一連の「１」（例えば１６ビットのハッシュ値の場
合「１１１１１１１１１１１１１１１１」）に設定され得る。このようなＴＲＤ２１４６
の競合検査デリミタ２１０２Ｃより大きいＣＳＮと共に、任意の書き込み含有トランザク
ションがコミットされた場合、ＴＲＤ２１４６に対応するトランザクションは拒否され得
る。従って、書き込み集合記述子２１０６Ｃにより示される書き込みと、書き込みペイロ
ード２１０８Ｃとは、記述子により示される競合検査間隔内に他の書き込みがコミットさ
れていない場合にのみ（このような書き込みの位置に関係なく）、コミットされる。

重複排除及び順序付け制約
いくつかの実施形態において、ログサービスのクライアントは、重複エントリが１つま
たは複数のデータストアに対し確実に書き込まれないことを所望し得る。このような一実
施形態において、ログサービスは、前述の読み出し書き込み競合検出を行うことに加えて
、トランザクション要求内に示される重複排除要件も施行する必要があり得る。図２２は
、少なくともいくつかの実施形態による、ログベーストランザクションマネジャーで受信
されるトランザクション要求に対応付けられた重複排除制約を施行する実施例を示す。示
されるように、トランザクション要求記述子２２４４は、読み出し書き込み競合検査デリ
ミタ２２１２と、読み出し集合記述子２２１４と、書き込み集合記述子２２１６と、論理
制約デリミタ２２１８とを備える。ＴＲＤ２２４４の書き込みペイロードは、図２２に図
示されない。論理制約記述子２２１８は、描かれた実施形態において、論理制約種類は重
複排除制約であることを示すＬＣ種類フィールド２２１９と、重複排除検査デリミタ２２
２０と、排除シグネチャ（複数可）２２２２とを含む。

要求トランザクションを受諾するか否かを判定するために、ログサービスは、描かれた
実施形態において、２種類の検査を行う必要があり得る。１つは読み出し書き込み競合検
出であり、もう１つは重複検出である。持続的変更ログ２２１０内のコミットレコード２
２５２はそれぞれ、描かれた実施形態において、それぞれのコミットシーケンス番号（Ｃ
ＳＮ２２０４）と、書き込み集合記述子（ＷＳＤ）２２０５と、重複排除シグネチャ（Ｄ
ＤＳ）２２０６とを含み得る。読み出し書き込み競合が起こったか否かを判定するために
、ログサービスは、読み出し書き込み競合検査デリミタ２２１２に対応するシーケンス番
号から始まり、最新コミットレコード２２５２Ｆで終わるＣＲ集合２２０９を特定し得る
。当該ＣＲ集合２２０９の書き込み集合は、要求トランザクションの読み出し集合記述子
２２１４との重複に関して調べられる。読み出し書き込み競合が検出された場合（すなわ
ちそのような重複が存在する場合）、要求トランザクションは前述のように拒否され得る
。

要求トランザクションの書き込み（複数可）が重複を表すか否かを判定するために、描
かれた実施形態において、重複排除検査デリミタ２２２０に対応するシーケンス番号から
始まり、最新コミットレコード２２５２Ｆで終わる別のＣＲ集合２２５９が特定され得る
。ＣＲ集合２２５９内のそれぞれのコミットレコードに関して、ログサービスは、コミッ
トレコードに格納された重複排除シグネチャのうちのいずれかが、要求トランザクション
の排除シグネチャ（複数可）２２２２に一致するか否かを調べ得る。重複はこのような一
致が見つかった場合に検出され、そしてこのようなシナリオにおいて、要求トランザクシ
ョンは、読み出し書き込み競合が検出されなかったとしても、拒否され得る。重複が検出
されなかった場合、かつ読み出し書き込み競合が検出されなかった場合、トランザクショ
ンはコミットのために受諾され得る。

少なくともいくつかの実施形態において、重複排除シグネチャ２２０６は、対応トラン
ザクションにより書き込まれるデータアイテムを、書き込み集合記述子とは異なる様式で
（例えば異なるハッシュ関数を使用して生成されたハッシュ値で、またはより多くのビッ
トを使用して記憶されたハッシュ値で）表現し得る。書き込み集合のこのような異なる符
号化は、多数の理由のうちのいずれかの理由から、重複排除あるいは読み出し書き込み競
合検出に使用され得る。例えば、いくつかのアプリケーションに関して、クライアントは
、誤判定読み出し書き込み競合検出の結果から時折トランザクションを再提出する必要が
あることよりも、正確に重複を検出することにより一層関心を持ち得る。そのため、この
ようなアプリケーションに関して、読み出し書き込み競合検出におけるエラーの許容レー
トは、重複検出エラーの許容レートよりも高くあり得る。従って、いくつかの実施態様に
おいて、出力値が１２８または２５６ビットになる暗号化強度ハッシュ関数が、重複排除
シグネチャに使用され、一方で出力が１６ビットまたは３２ビットを使用して記憶される
より単純なハッシュ関数が、ＷＳＤ内に含まれる書き込みシグネチャに使用され得る。い
くつかのシナリオにおいて、重複排除は、使用されているデータストアの小部分集合に必
要であり、一方で読み出し書き込み競合は、トランザクションのはるかに大きい集合に関
して調べられる必要があり得る。このような場合、いくつかの実施形態において、重複排
除シグネチャよりも小さいＷＤＳシグネチャを使用することにより、格納及びネットワー
クリソース使用量は削減され得る。読み出し書き込み競合検出機構と重複排除検出機構を
合体させる代わりに、読み出し書き込み競合検出機構を重複排除検出機構から論理的に切
り離すことは、例えばログサービスのユーザ間の混乱を避けるため、重複排除の別個の請
求に対応可能であるため等の他の理由からも、有益であり得る。

別の実施形態において、読み出し書き込み競合検出と重複排除の両目的のために、書き
込み集合記述子が使用され得る（例えば別個の排除シグネチャは使用され得ない）。同様
に、いくつかの実施形態において、同一のシーケンス番号値が、読み出し書き込み競合検
査デリミタ及び重複排除検査デリミタとして使用され得る。すなわち、読み出し書き込み
競合に関して調べられるコミットレコード集合は、重複に関しても検査され得る。少なく
とも一実施形態において、重複排除は、例えば書き込み集合記述子を使用して、トランザ
クション要求記述子に論理制約記述子を含める必要なしに、デフォルトで実行され得る。

いくつかのアプリケーションに関して、クライアントは、特定のトランザクション集合
間にコミット順序を施行することに関心を持ち得る。例えば、トランザクションＴ１、Ｔ
２、Ｔ３それぞれに対する３つの異なるトランザクション要求を提出するクライアントは
、Ｔ１はＴ２の前にコミットされ、Ｔ３はＴ１とＴ２が両方ともコミットされた後にのみ
コミットされることを所望し得る。このようなコミット順序付け制約は、いくつかの実施
形態において、第２種の論理制約記述子を使用して施行され得る。図２３は、少なくとも
いくつかの実施形態による、ログベーストランザクションマネジャーで受信されるトラン
ザクション要求に対応付けられた順序付け制約を施行する実施例を示す。示されるように
、トランザクション要求記述子２３４４は、読み出し書き込み競合検査デリミタ２３１２
と、読み出し集合記述子２３１４と、書き込み集合記述子２３１６と、図２２の論理記述
子２２１８とは異なる種類の論理制約デリミタ２３１８とを備える。ＴＲＤ２３４４の書
き込みペイロードは、図２３に図示されない。論理制約記述子２３１８は、描かれた実施
形態において、論理制約種類は順序付け制約であることを示すＬＣ種類フィールド２３１
９と、順序付け検査デリミタ２２２０と、トランザクションＴ１、Ｔ２にそれぞれ対応す
る要求順序付けシグネチャ２３２２Ａ、２３２２Ｂとを含む。論理制約記述子２３１８は
ＴＲＤ２３４４に含まれ、両トランザクションＴ１、Ｔ２（順序付けシグネチャ２３２２
Ａ、２３２２Ｂにより示される）が先にコミットされた場合にのみ要求トランザクション
はコミットされることを確実にし得る。

要求トランザクションを受諾するか否かを判定するために、ログサービスはもう１度、
図２３に示される実施例における２種類の検査を行う必要があり得る。１つは読み出し書
き込み競合検出であり、もう１つはトランザクションＴ１、Ｔ２がコミットされたことを
確認することである。持続的変更ログ２３１０内のコミットレコード２３５２はそれぞれ
、描かれた実施形態において、それぞれのコミットシーケンス番号（ＣＳＮ２３０４）と
、書き込み集合記述子（ＷＳＤ）２３０５と、順序付けシグネチャ２３０６とを含み得る
。読み出し書き込み競合が起こったか否かを判定するために、前述同様に、ログサービス
は、読み出し書き込み競合検査デリミタ２３１２に対応するシーケンス番号から始まり、
最新コミットレコード２３５２Ｆで終わるＣＲ集合２３０９を特定し得る。当該ＣＲ集合
の書き込み集合は、要求トランザクションの読み出し集合記述子２３１４との重複に関し
て調べられる。読み出し書き込み競合が検出された場合（すなわちそのような重複が存在
する場合）、要求トランザクションは拒否され得る。

要求トランザクションの順序付け制約が満たされたか否かを判定するために、描かれた
実施形態において、順序付け検査デリミタ２３２０に対応するシーケンス番号から始まり
、最新コミットレコード２３５２Ｆで終わる別のＣＲ集合２３５９が特定され得る。ログ
サービスは、要求シグネチャ２３２２Ａ、２３２２Ｂと一致する順序付けシグネチャを有
するそれぞれのコミットレコードが、ＣＲ集合２３５９内に存在することを確認する必要
があり得る。要求シグネチャ２３２２のうちの少なくとも１つがＣＲ集合２２５９内に見
つからない場合は、順序付け制約に違反することとなり、読み出し書き込み競合が検出さ
れなかったとしても、要求トランザクションは拒否され得る。両方の順序付けシグネチャ
がＣＲ集合２３５９内に見つかった場合、かつ読み出し書き込み競合が検出されなかった
場合、トランザクションはコミットのために受諾され得る。

ＣＲ２３５２内（及びＴＲＤ２３４４内）に格納される順序付けシグネチャは、異なる
実施形態において様々な技術を使用して生成され得る。いくつかの実施形態において、そ
れらはトランザクションの書き込み集合から生成され得る。別の実施形態において、順序
付けシグネチャは、他の要素に少なくとも部分的に基づき得る。例えば、いくつかの実施
形態において書き込みシグネチャに加えて要求クライアントの識別が順序付けシグネチャ
に符号化され得る、トランザクションが要求された実時間が順序付けシグネチャに符号化
され得る、あるいはトランザクションが要求された元の位置の開示が符号化され得る等が
ある。いくつかの実施形態において、順序付けシグネチャを表すために、書き込み集合シ
グネチャとは異なる技術を使用することに関して、前述と同様の考察が適用され得る。従
って、いくつかの実施形態において、順序付けシグネチャと書き込み集合シグネチャの両
方が同一の基礎書き込み位置から導出されるとしても、書き込み集合記述子コンテンツを
生成するために使用される技術とは異なる技術が、順序付けシグネチャを生成するために
使用され得る。例えば、異なるハッシュ関数または異なるハッシュ値サイズが使用され得
る。しかしながら別の実施形態においては、読み出し書き込み競合検出と順序付け施行の
両目的のために、書き込み集合記述子が使用され得る（例えば別個の順序付けシグネチャ
は使用され得ない）。同様に、いくつかの実施形態において、同一のシーケンス番号値が
、読み出し書き込み競合検査デリミタ及び順序付け検査デリミタとして使用され得る。す
なわち、読み出し書き込み競合に関して調べられるコミットレコード集合は、順序付けに
関しても検査され得る。いくつかの事例においては、書き込み集合とは無関係の任意の数
字または文字列が、順序付けシグネチャとして使用され得る。少なくとも一実施形態にお
いて、制約記述子はＬＣ種類フィールドを含み得ない。代わりに制約の種類は、トランザ
クション要求内における制約記述子の位置により示され得る。いくつかの実施形態におい
て、例えば、ＬＣ種類フィールドを使用する代わりに、「要求」フラグが順序付けシグネ
チャに対応付けられ、そして「排除」フラグが重複排除シグネチャに対応付けられ得る。
読み出し書き込み競合検査デリミタに関連して前述されたように、いくつかの実施形態に
おいて、制約検査に関して調べられるべきコミットレコードの範囲を示すために、ＣＳＮ
の下限のみを指定する代わりにＣＳＮの上限もトランザクション要求記述子内で指定され
得る。

いくつかの実施形態において、図２３に例示される順序付け制約よりも複雑な順序付け
制約が施行され得る。例えば、クライアントは、ログサービスに対し単純に、要求トラン
ザクションのコミットより前に両トランザクションＴ１、Ｔ２が必ずコミットされたこと
（任意の順序で）を確認するよう要求する代わりに、Ｔ１が必ずＴ２より前にコミットさ
れたことを要求することが可能であり得る。同様に、いくつかの実施形態において、クラ
イアントは、例えば、要求トランザクションの前に、あるトランザクション集合｛Ｔ１、
Ｔ２、Ｔｋ｝がある特定の順序で（または任意の順序で）コミットされなければならない
、かつある他のトランザクション集合｛Ｔｐ、Ｔｓ｝はコミットされてはならないといっ
た、否定的順序要件を要求することも可能であり得る。

図２２及び図２３において、表示されたトランザクション要求内には、単一の種類の論
理制約が示された。いくつかの実施形態において、クライアントは、様々なトランザクシ
ョン上でいくつかの異なる種類の論理制約を施行することを所望し得る。図２４は、少な
くともいくつかの実施形態による、複数の論理制約記述子を含むトランザクション要求記
述子の実施例を示す。トランザクション記述子２４４４により表される同一の要求トラン
ザクションに対し、１つの順序付け制約が適用され、かつ１つの重複排除制約が適用され
る。描かれた実施形態において、読み出し書き込み集合記述子は、読み出されるまたは書
き込まれるデータアイテムごとに、３２ビット（４バイト）のハッシュ値を有する。例え
ば、それぞれの４バイト読み出しハッシュシグネチャ２４６４Ａ、２４６４Ｂは、読み出
し集合記述子２４０４内で２つのデータアイテム位置を示し、そしてそれぞれの４バイト
書き込みハッシュシグネチャ２４６５Ａ、２４６５Ｂは、書き込み集合記述子２４０６に
含まれ、トランザクションがコミットされると書き込み対象となる２つの位置を示す。読
み出し書き込み競合検査デリミタ２４０２は、持続的変更ログ内のシーケンス番号範囲の
下限を選択するために使用され、当該シーケンス番号範囲のコミットレコードは、要求ト
ランザクションとの読み出し書き込み競合の検査対象となる。

トランザクション要求記述子２４４４はまた、描かれた実施形態において、順序付け制
約記述子２４０８Ａと、重複排除制約記述子２４０８Ｂとを含み得る。順序付け制約記述
子２４０８Ａは、制約種類フィールド２４０９Ａと、順序付け検査デリミタ２４１０と、
要求トランザクションが受諾されるためにはコミットが完了してなければいけないトラン
ザクションに対応する１つまたは複数の要求順序付けシグネチャ２４１２Ａ、２４１２Ｂ
等とを含み得る。重複排除制約記述子２４０８Ｂは、制約種類フィールド２４０９Ｂと、
重複排除検査デリミタ２４２０と、重複排除シグネチャ２４２２とを含み得る。

示されるように、描かれた実施形態において、要求順序付けシグネチャ２４１２Ａ、２
４１２Ｂと重複排除シグネチャ２４２２は、１２８ビット（１６バイト）ハッシュシグネ
チャ２４６６Ａ、２４６６Ｂ、２４６７をそれぞれ備え得る。このように、論理制約シグ
ネチャはそれぞれ、描かれた実施例において読み出し及び書き込み集合シグネチャのデー
タアイテムごとに使用されるビットの４倍のビットを使用し得る。これにより、論理制約
関連比較のハッシュ衝突数は、読み出し書き込み競合検出のために行われる比較と比べて
、低減され得る。いくつかの実施形態において、順序付け及び／または重複排除シグネチ
ャのために、ＭＤ５等の暗号化ハッシュ関数が使用され得る。少なくともいくつかのこの
ような実施形態において、暗号化ハッシュ関数の使用のおかげで、論理制約検査における
エラー確率は、ゼロ近くまでに低減され得る。誤判定ハッシュ衝突に（例えば誤判定読み
出し書き込み競合検出に）基づいたトランザクション拒否レートは合理的に低く、容認可
能であり得るが、少なくともいくつかのクライアントは、誤判定ハッシュ衝突（例えばコ
ミット順序付けの場合）によるトランザクションの受諾を回避することに一層関心を持ち
、そして暗号化強度ハッシュ関数の使用のおかげで、このようなトランザクション誤受諾
は回避され得る。いくつかの実施態様において、クライアントは、重複検出及び／または
順序付け目的で使用するハッシュ関数を選択可能であり得る。いくつかの実施形態におい
て、重複排除シグネチャ、順序付けシグネチャ、及び／または読み出しもしくは書き込み
シグネチャに、図２４に示されるものとは異なるハッシュ関数及び／またはハッシュ値の
長さが使用され得る。例えば、重複排除及び順序付けシグネチャは、サイズで異なり得る
。少なくともいくつかの実施形態において、読み出し／書き込み集合シグネチャ、重複排
除及び／または順序付けシグネチャに、読み出されるまたは書き込まれるデータアイテム
のアドレスが、例えばアドレスから生成されるハッシュ値を使用する代わりに、使用され
得る。一実施形態において、重複排除及び／または書き込みシグネチャは、データが書き
込まれる先の位置から導出されることに加えて、またはこれに代わって、書き込みペイロ
ードから導出され得る。

いくつかの実施形態において、データ完全性／有効性制約、または最終コミット期限制
約等の追加論理制約も、トランザクション要求記述子内に指定され得る。例示的データ完
全性または有効性制約は、例えば特定の値Ｖ１は、異なる値Ｖ２がデータストアＤＳ１ま
たはある他のデータストアに既に格納されている場合にのみデータストアＤＳ１に格納さ
れ得ることを、要求し得る。データ有効性制約は、特定のデータ種類または格納するデー
タアイテムに対し、許容範囲（無条件、または指定データストア位置の格納値に関して条
件付き）を定義し得る。コミット期限制約は、トランザクションのコミットが完了される
べき最終期限を示し、最終期限が満たされない場合、トランザクションは中止またはアボ
ートされなくてはならないという意図がある。

図２５は、少なくともいくつかの実施形態による、１つまたは複数の論理制約を示すト
ランザクション要求に応じてログサービスで行われ得る動作態様を示すフロー図である。
描かれた実施形態において、所定のトランザクションのコミット要件には、並行処理制御
要件（例えば前述の類の読み出し書き込み競合は見つからないという要件）、並びに論理
制約要件が含まれ得る。少なくともいくつかの実施形態において、重複排除及び順序付け
の両論理制約は、単一のトランザクションに関して対応され得る（他の論理制約も対応さ
れ得るが、重複排除及び順序付けに関わる動作のみが図２５において示される）。構成要
素２５０１において示されるように、トランザクションＴ１の１つまたは複数の論理制約
記述子を含むトランザクション要求記述子が、ログサービスの特定の持続的変更ログイン
スタンスに対応付けられた競合検出器において受信され得る。描かれた実施形態において
、論理記述子ごとに対応検査デリミタが指定され、これは、論理制約を満たすか違反する
かを判定する分析対象となるコミットレコードの集合を選択するために使用される。１つ
または複数のシグネチャのそれぞれの集合も、論理制約ごとに指定され得る。要求トラン
ザクションの読み出し及び書き込み集合も、読み出し書き込み競合検査デリミタと一緒に
示され得る。前述のように、いくつかの実施形態において、読み出し書き込み競合の検査
に使用されるデリミタと同じデリミタが、１つまたは複数の論理制約に使用され得る。ま
た、少なくとも一実施形態において、論理制約に別個のシグネチャは必要ではあり得ない
。代わりに、例えば書き込み集合シグネチャが、重複排除及び／または順序付けシグネチ
ャとして使用され得る。

描かれた実施形態において、読み出し書き込み競合検査デリミタを使用して、分析対象
となるコミットレコード第１集合ＣＲＳ１が特定され得る。このような集合は、例えば、
読み出し書き込み競合検査デリミタから始まり、最新格納コミットレコードのシーケンス
番号まで（またはトランザクション要求内に示される別の上限まで）の範囲内に存在する
シーケンス番号を有するコミットレコードを含み得る。読み出し書き込み競合が検出され
た場合（構成要素２５０４）（例えばＣＲＳ１のコミットレコードのうちのいずれかの書
き込み集合が、要求トランザクションの読み出し集合と重複する場合）、トランザクショ
ンは拒否／アボートされ得る（構成要素２５３１）。本明細書において、読み出し書き込
み競合の検査は、要求トランザクションが並行処理制御要件を満たすことの検証ともみな
され得る。いくつかの実施形態において、受信したトランザクション要求の送信元である
クライアントに対し、トランザクションがアボートされたことが通知され得る。

描かれた実施形態において、読み出し書き込み競合が検出されなかった場合（同様に構
成要素２５０４に対応する動作において）、対応記述子により示されるそれぞれの論理制
約が順次検査され得る。次の順序の論理制約記述子が調べられ、制約に対応付けられた検
査デリミタに基づいて、制約分析の対象となる新たなコミットレコード集合ＣＲＳ‐ｋが
選択され得る（構成要素２５０７）。例えば、ＣＲＳ‐ｋは、デリミタから始まり、記録
済み最大コミットシーケンス番号で終わる（またはトランザクション要求内に示される別
の上限までの）範囲内のシーケンス番号を有するコミットレコード全てを含み得る。行わ
れる分析は、論理制約記述子の種類に依存し得る。重複排除制約が検査内容であり、ＣＤ
Ｒ‐ｋの重複排除シグネチャと要求トランザクションを比較することで重複が見つかった
場合（構成要素２５１０）、トランザクションは同様に拒否／アボートされ得る（構成要
素２５３１）。制約が重複排除制約であり、重複が見つからなかった場合（同様に構成要
素２５１０にて検出）、かつまだ他に分析されていない論理制約がある場合、次の論理制
約記述子が調べられ、そして構成要素２５０７以降に対応する動作が次の論理記述子のた
めに繰り返され得る。

制約記述子がコミット済みトランザクションの１つまたは複数の要求シグネチャを示す
順序付け制約を示す場合、順序付け制約に関してＣＲＳ‐ｋが調べられ、コミットが完了
したトランザクションに関して要求シグネチャが実際に格納されたことが確認され得る。
要求トランザクションのコミットレコードが見つからなかった場合（構成要素２５１３に
て検出）、要求トランザクションは同様にアボート／拒否され得る（構成要素２５３１）
。要求トランザクションのコミットレコードが見つかった場合（同様に構成要素２５１３
に対応する動作において）、順序付け制約処理は完了し得る。読み出し書き込み競合検出
の場合のように、論理制約検査も、少なくともいくつかの実施形態において、比較のため
にハッシュ関数を使用して行われ、よってコミットレコード集合を走査するオーバーヘッ
ドは回避される。いずれかの論理制約記述子が残っている場合（構成要素２５１６）、そ
れらは順番に調べられ得る。論理制約記述子はもう残っていない場合（同様に構成要素２
５１６にて検出）、トランザクションはコミットのために受諾され得る。描かれた実施形
態において、トランザクションのコミットレコードを、持続的格納域に、例えば複製ＤＡ
Ｇのいくつかのノードに保存する手続きが開始され得る（構成要素２５１９）。複製が成
功した場合（例えば十分な数のコミットレコードのコピーが無事にそれぞれの格納デバイ
スに格納された場合）（構成要素２５２２にて検出）、トランザクションのコミットは完
了したとみなされ得る。ある理由で、要求される数のレプリカが格納されなかった場合、
トランザクションはやはり拒否／アボートされ得る（構成要素２５３１）。いくつかの実
施形態において、トランザクションが無事にコミットされたという通知が、要求クライア
ントへ送信され得る（構成要素２５２５）。

いくつかの実施形態において、代わりに複数の論理制約を検査する動作が並行して行わ
れ得る。一実施形態において、読み出し書き込み競合検出と論理制約検査の任意の組み合
わせが、並行して行われ得る。いくつかの実施形態において、それぞれの指示された論理
制約に関する応答が、制約のうちの１つまたは複数が満たされなかったとしても、要求ク
ライアントに対し提供され得る。例えば、重複排除制約と順序付け制約とを有するトラン
ザクション要求の場合、重複排除制約が満たされなかったとしても順序付け制約は検査さ
れ、そして両制約の調査結果がクライアントに対し提供され得る。いくつかの実施態様に
おいて、クライアントは、所定のトランザクション要求の論理制約の特定の部分集合また
は全てが検査されるように、明示的に要求することが可能であり得る。

ログ整合格納グループの価格設定ポリシー
少なくとも書き込み含有トランザクションが前述のようにログベーストランザクション
マネジャーを使用して集合的に管理されるデータストア集合は、本明細書において、ログ
整合格納グループ（ＬＣＳＧ）のメンバーデータストアと称され得る。例えば、ＬＣＳＧ
は、非リレーショナルデータベースの１つまたは複数のインスタンス、リレーショナルデ
ータベースの１つまたは複数のインスタンス、プロバイダネットワーク格納サービスの１
つまたは複数の格納オブジェクト、インメモリデータベースインスタンス、待ち行列サー
ビス実施の持続的待ち行列、通知サービス等の複数のデータストアインスタンスを含み得
る。データストアメンバーのためにインスタンス化された特定のログベーストランザクシ
ョンマネジャーも、ＬＣＳＧの一部とみなされ得る。少なくともいくつかの実施形態にお
いて、ＬＣＳＧによりユーザは、様々なデータストア横断動作を要求することが可能にな
り得る。例えば、ＬＣＳＧにおいて所定のトランザクション内で行われる単一の論理書き
込みは、いくつかの異なるデータストアに適用される複数の物理的更新に最終的に変換さ
れ得る（すなわち結果的になる）。このようにして、同一の基礎変更に関するいくつかの
異なる見解は、データストアのそれぞれのデータアクセスインターフェースを介してアク
セス可能とされ得る。

格納システムクライアントが、持続性及びデータ耐久性のデータシステムインスタンス
と、書き込み要求の結果に対し低レイテンシアクセスのインメモリ分散キャッシュインス
タンスと、オフライン分析のデータウェアハウジングサービスと、長期記録保持のアーカ
イブ格納サービスとにおいて、同一の書き込み要求のデータペイロードを可視化すること
を所望するシナリオを検討する。一実施形態において、クライアントは、アプリケーショ
ンデータに対する所定の論理変化の対象として、４つのデータストアそれぞれを明示的に
示すトランザクションを構築し得る。別の実施形態において、データストア横断トランザ
クションに対応することに加えて、またはこれに代わって、ＬＣＳＧがインスタンス化さ
れたログサービスは、全ての異なる書き込み対象が所定のトランザクション要求内で明示
的に指定されることを要さない自動データストア横断変換に対応し得る。その代わり、例
えば構成要求に応じて、またはＬＣＳＧ設定中に、クライアントは、データベースインス
タンスに対するいずれの所定の書き込みに関しても、対応表現が自動でインメモリキャッ
シュ、データウェアハウジングサービス、及びアーカイブ格納サービスに伝播されるよう
に示すことが可能であり得る。いくつかの実施形態において、所定のペアのデータストア
間の両方向の変換が対応され得る。例えば、クライアントアプリケーションがデータベー
スインスタンスに直接書き込みを行う場合、書き込みの結果は、ログサービスによりイン
メモリキャッシュが望む好適な形式でインメモリキャッシュに自動で追加され、そしてク
ライアントアプリケーションがインメモリキャッシュに直接別の書き込みを行う場合、別
の書き込みの結果は、データベースインスタンスが望む形式でデータベースインスタンス
に自動で伝播され得る。

ログサービスは、いくつかの実施形態において、ＬＣＳＧにおいて行われる動作に対し
、いくつかの異なる価格設定ポリシーを実施し、価格設定ポリシーのうちの少なくともい
くつかは、クライアントのために行われる動作種類の混合比に基づき得る（例えば、単一
データストアに対する書き込みを伴った動作の数に対し、いくつのデータストア横断変換
及び／またはトランザクションがある時間間隔に行われたか）。所定の請求期間にＬＣＳ
Ｇ顧客に課される請求額は、後述の多数の要因、及び顧客のために、または顧客により選
択された価格設定ポリシー（複数可）に基づいて変わり得る。後述の価格設定ポリシーの
うちの少なくともいくつかは、所定のクライアントに対し、お互い組み合わせて使用され
得る。例えば、段階的価格設定が、準備スループット型及びベストエフォート型の両リソ
ース割り当てモードに適用され、そしてＬＣＳＧの各データストアに対し、それぞれの準
備スループット型価格設定ポリシーが適用され得る。

少なくとも一実施形態において、所定のＬＣＳＧに含まれる異なるデータストアの数、
含まれるデータストアの種類、及び／またはクライアントのために行われるデータストア
横断動作の数（例えば最初特定のデータストアを対象とする書き込みの第２表現を別のデ
ータストアに生成することを伴う動作またはトランザクション）が、請求額に影響し得る
。例えば、１つの価格設定ポリシーに従うと、８つのデータストアを有するＬＣＳＧを確
立することは、全体の作業負荷レベル及び／またはデータ集合サイズ等の他の要素が同一
であると仮定すると、４つのデータストアを有するＬＣＳＧを確立する場合よりも費用が
かかり得る。他の例示的価格設定ポリシーに従うと、特定の作業負荷レベルに対応する４
つのリレーショナルデータベースインスタンスを有するＬＣＳＧは、同じ作業負荷レベル
に対応する４つのインメモリデータベースインスタンスを有するＬＣＳＧよりも費用がか
かり得る。いくつかの実施形態において、クライアントは、行われたデータストア横断動
作ごとに特定の額が請求され得る。一実施形態において、データストア横断動作の費用も
また、関与するデータストアの種類に基づいて異なり得る。例えば、最初リレーショナル
データベースを対象とする書き込みをインメモリデータベースにおける追加書き込みに変
換する動作は、最初非リレーショナルデータベースを対象とする書き込みをインメモリデ
ータベースにおける別の書き込みに変換する動作とは異なる額がかかり得る。いくつかの
実施形態において、書き込み伝播の方向もまた、動作の価格に影響し得る。例えばデータ
ストアＤＳ１からＤＳ２への書き込み変換は、ＤＳ２からＤＳ１への書き込み変換とは異
なる額がかかり得る。

いくつかの実施形態において、いくつかのモードのうちの１つのモードのＬＣＳＧが使
用するプロバイダネットワークにおいて、リソース（演算サーバ、格納デバイス、ネット
ワーク帯域、メモリ等）が割り当てられ得る。準備スループットモードのリソース割り当
てにおいて、ログサービスのクライアントは、ＬＣＳＧのメンバーとして登録される特定
のデータストアに対し目標スループットレート（例えば毎秒１００トランザクション）を
指示し、ログサービスは、要求されるスループットに耐えられるような十分なリソースを
確保し得る（例えば障害がないといった少なくとも通常の動作条件下で）。準備スループ
ットモードに基づいた価格設定ポリシーに従って、所定の請求期間中にクライアントによ
り投入された実際の作業負荷が図らずも目標を下回ったとしても、クライアントは目標ス
ループットレート分請求され得る。いくつかの実施形態において、所定のＬＣＳＧの様々
なデータストアに対して、異なる準備スループットがクライアントにより要求され得る。
いくつかの実施形態によれば、準備スループットに対する請求レートは、データストアに
よって異なり得る。例えば、非リレーショナルデータベースの毎秒１００トランザクショ
ンの準備スループットに対するレートは、同じＬＣＳＧのメンバーであるリレーショナル
データベースの毎秒１００トランザクションの準備スループットに対するレートとは異な
り得る。

少なくともいくつかの実施形態において、ベストエフォートモードと呼ばれる別のモー
ドのリソース割り当てにおいて、ログサービスは、必ずしもクライアントの指定目標スル
ープットに対応するリソースを確保または献呈し得ない。代わりに、例えば、共有プール
（複数可）からのリソースが、クライアントのＬＣＳＧに割り当てられ得る。クライアン
トの作業負荷レベルは変動するため、ログサービスは、例えば共有プール内の利用可能能
力に基づいて、クライアントに割り当てられたリソース集合に対し、ベストエフォート調
整を行い得る。少なくともいくつかの実施形態において、同じ作業負荷レベルに対して、
ベストエフォート型リソース割り当てモードの価格設定ポリシーは、準備スループット型
リソース割り当てモードの価格設定ポリシーとは、請求レートが異なり得る。いくつかの
実施形態において、準備スループットの事例のように、ベストエフォート型リソース割り
当てに関しても、異なるデータストアに対し異なる請求レートが適用され得る。

少なくとも一実施形態によれば、段階的スループットベース価格設定モデルが実施され
得る。例えば、クライアントが毎秒０〜１０００トランザクションを投入した場合、請求
レートＢ１（例えばトランザクションごと）が課され、これは毎秒１０００〜２０００ト
ランザクションのトランザクションレートに対する請求レートＢ２等とは異なる。いくつ
かの実施形態において、同様の段階ベース価格設定が、帯域使用量にも適用され得る。例
えば、転送ギガバイト総数が０〜１０ＧＢ／日の場合、転送ギガバイト総数が１０〜２０
ＧＢ／日の場合とは、異なる転送データギガバイト毎請求レートが課され得る。いくつか
の実施形態において、使用されている持続的変更ログに関して及び／またはＬＣＳＧのメ
ンバーデータストアに関して、ＬＣＳＧクライアントが要求する高可用性、データ耐久性
、レイテンシのレベルに少なくとも部分的に基づいて、請求額が変わり得る。少なくとも
一実施形態において、特定のデータストア種類集合にネイティブに対応するだけでなく、
例えばサービスによりネイティブに対応されるデータストア種類と、ネイティブに対応さ
れていない別のデータストア種類との間の変換に関して、カスタム拡張が追加されること
を許容する格納サービスにおいて、ＬＣＳＧが実施され得る。いくつかのこのような実施
形態において、所定の拡張の使用に適用される請求レートは、ネイティブ対応のデータス
トア種類に使用される請求レートとは異なり得る。

自身の価格設定ポリシーをそれぞれ実施するプロバイダネットワークの各自のサービス
を介して、ＬＣＳＧの様々なデータストアがそれぞれ実施される一実施態様において、ク
ライアントはそれらのプロバイダネットワークサービスの使用に対してと、ＬＣＳＧの使
用に対してと、別個に請求され得る。例えば、ＬＣＳＧのデータベースインスタンスを対
象とする読み出しの請求額は、データベースサービスの価格設定ポリシーに従って計算さ
れ、一方ＬＣＳＧトランザクション及びデータストア横断変換動作に対する請求は、ＬＣ
ＳＧ価格設定ポリシーに従って決定され得る。

少なくとも一実施形態において、ログサービスのクライアントが代替価格設定ポリシー
を見て、及び／またはクライアントの好み及び要件に基づいて特定の価格設定ポリシーを
選択できるように、１つまたは複数のプログラマチックインターフェース（ウェブページ
、ＡＰＩ等）が実装され得る。全体要求トランザクション及び／または読み出しレート、
行われたデータストア横断及び単一データストア動作数、使用されたネットワーク帯域等
の作業負荷関連メトリクスが、顧客のＬＣＳＧのために割り当てられたリソースから収集
され得る。少なくともいくつかの実施形態において、ＬＣＳＧを実施するログサービスの
制御プレーンにより行われる請求関連作業の一部は、作業負荷レコードを、データストア
横断動作を示す１つの部分集合、あるいは単一データストア動作を示す別の部分集合に分
類することを含み得る。例えば、両種類の動作（単一データストアあるいはデータストア
横断）の書き込みレコードは、所定のデータストアにおける同一のログに格納され、そし
て作業負荷分析制御プレーンコンポーネントが、書き込みレコードのコンテンツを調べて
、書き込みレコードはデータストア横断書き込みを表すか単一データストア書き込みを表
すかを判定する必要があり得る。一実施態様において、メトリクスの収集のために、ＬＣ
ＳＧに使用されているプロバイダネットワークの分散監視エージェントの集合が使用され
得る。ＬＣＳＧに選択された価格設定ポリシーと収集されたメトリクスとに応じて、特定
の請求期間の請求額が決定され、クライアントに示され得る。

図２６は、少なくともいくつかの実施形態による、それぞれのログ整合格納グループ（
ＬＣＳＧ）に対しそれぞれの価格設定ポリシーが実施され得る例示的システム環境を示す
。示されるように、システム２６００は、２つのＬＣＳＧ２６０５Ａ、２６０５Ｂを備え
る。ＬＣＳＧ２６０５Ａは２つのデータストア２６３０Ａ、２６３０Ｂを含み、一方ＬＣ
ＳＧ２６０５Ｂは４つのデータストア２６３０Ｃ、２６３０Ｄ、２６３０Ｅ、２６３０Ｆ
を含む。競合検出器２６１５Ａと、持続的変更ログ２６０１Ａと、書き込みアプライヤ集
合２６１７Ａとを含むログベーストランザクションマネジャー（ＬＴＭ）２６０２Ａは、
データストア２６３０Ａ、２６３０Ｂに対するクライアントに指示された書き込みを含む
トランザクション要求を取り扱うように構成される。同様に、競合検出器２６１５Ｂと、
持続的変更ログ２６０１Ｂと、書き込みアプライヤ集合２６１７Ｂとを含むＬＴＭ２６０
２Ｂは、データストア２６３０Ｃ〜２６３０Ｆに対するクライアントに指示された書き込
みを管理するように構成される。持続的変更ログ２６０１は、本明細書において、書き込
みログとも称され得る。

ＬＣＳＧが実施されるログサービスまたは格納サービスの制御プレーン２６４９は、例
えばＬＣＳＧメンバー情報の管理、クライアントアカウントとアカウントに割り当てられ
たサービスリソースとのマッピング、様々なＬＣＳＧに使用されている価格設定／請求ポ
リシーの追跡等を含む、設定及び管理タスクの責務を担う複数のコンポーネントを含み得
る。描かれた実施形態において、請求マネジャー２６５１は、例えば、ＬＣＳＧ２６０５
Ａ、２６０５Ｂを対象とする要求に関する１つまたは複数の価格設定ポリシー選択肢に基
づいて、クライアントの請求額を生成する責務を担い得る。描かれた実施形態において、
利用可能な価格設定ポリシー集合が、ＬＣＳＧを実施するサービスの実際の顧客または可
能性のある顧客に対し、ウェブページ、ＡＰＩ、コマンドラインツール、またはカスタム
ＧＵＩ等の１つまたは複数のプログラマチックインターフェースを介して示され得る。少
なくともいくつかの実施形態において、顧客も、このようなプログラマチックインターフ
ェースを介して、例えば顧客が様々なデータストア２６３０をＬＣＳＧメンバーとして登
録する時に、またはＬＣＳＧが設定された後のある時点に提出される価格設定ポリシー変
更要求により、顧客のＬＣＳＧに適用する特定の価格設定ポリシーを指示し得る。描かれ
た実施形態において、ＬＣＳＧ２６０５Ａに対し価格設定ポリシー２６４４Ａが特定され
、一方でＬＣＳＧ２６０５Ｂに対し別の価格設定ポリシー２５４４Ｂが選択されている。
各価格設定ポリシーは、例えば、少なくとも特定の請求期間中に、様々な異なる動作種類
及び／またはリソース利用単位に使用する請求レートを示し得る。所定の請求期間に顧客
に課される請求額（例えばＢＡ１またはＢＡ２）は、請求期間中にそれらのＬＣＳＧに対
し実施されている価格設定ポリシー（複数可）と、請求期間中に収集された様々なメトリ
クスの分析とに基づいて、請求マネジャー２６５１により決定され得る。

メトリクスコレクタ２６５５Ａは、データストア２６３０Ａ及び／またはＬＴＭ２６０
２に使用されるサーバ及びデバイス等の様々なリソースを監視し、収集されたメトリクス
の開示を請求マネジャー２６５１に提供する責務を担い得る。例えばコンピューティング
サービス、格納サービス等のプロバイダネットワークのサービスを使用して、プロバイダ
ネットワーク内でＬＣＳＧが実施される実施形態において、一部または全てのサービスに
既存のメトリクス収集インフラストラクチャが利用可能であり、請求マネジャーは、当該
既存のメトリクス収集インフラストラクチャから、請求額を生成するために必要となるメ
トリクスのうちの少なくともいくつかを取得し得る。一実施形態において、制御プレーン
２６４９は、例えば、各ＬＣＳＧのメンバーを特定する責務を担うメンバーシップマネジ
ャー、収集された作業負荷メトリクスをクライアント毎及び／または動作種類毎のサブグ
ループに分類するメトリクスアナライザ、及び選択された価格設定ポリシーと作業負荷メ
トリクスとに基づいて様々なクライアントに対する請求額を生成する請求書ジェネレータ
といった、様々な価格設定／請求関連タスクのそれぞれのコンポーネントを含み得る。

ＬＣＳＧ２６０５に適用される所定の価格設定ポリシー２６４４において、例えば、Ｌ
ＣＳＧのメンバーであるデータストア２６３０の数及び／または種類、動作混合比（単一
データストア書き込み対データストア横断書き込み）、使用したリソース割り当てモデル
（例えば準備スループット型あるいはベストエフォート型）、要求トランザクションレー
ト等、多数の異なる要素が考慮され得る。図２７は、少なくともいくつかの実施形態によ
る、単一データストア及びデータストア横断書き込み動作の実施例を示す。描かれた実施
形態において、ＬＣＳＧ２７０５は、ＮｏＳＱＬ ＤＢインスタンス２７３０Ａ、キー値
インメモリＤＢ ２７３０Ｂ、分散キャッシュインスタンス２７３０Ｃ、リレーショナル
ＤＢインスタンス２７３０Ｄ、格納サービスオブジェクト２７３０Ｅ、アーカイブサービ
スオブジェクト２７３０Ｆの６つのメンバーデータストアを含む。例示されるように、所
定ＬＣＳＧのメンバーデータストアは、非常に異なるデータモデルを実施し（例えばリレ
ーショナルあるいは非リレーショナル、構造化レコードあるいは非構造化データオブジェ
クト等）、従って、少なくともいくつかの実施形態において、メンバーデータストアでは
、異なる読み出しインターフェース及びデータ形式が使用され得る。

クライアントによる要求トランザクションに明示的に含まれる書き込みと、ログサービ
スが自動的に行うように構成された書き込み（例えば明示的要求書き込みの結果または副
作用として）の、２種類の書き込み動作が図２７において例示される。トランザクション
要求２７０２Ａは、書き込みペイロードＷ１が、ＮｏＳＱＬ ＤＢインスタンス２７３０
Ａと、格納サービスオブジェクト２７３０Ｅも対象にすることを示す。従って、書き込み
ペイロードＷ１の表現Ｗ１‐ＡはＮｏＳＱＬ ＤＢインスタンス２７３０Ａに格納され、
同じ書き込みペイロードの別の表現Ｗ１‐Ｂは格納サービスオブジェクト２７３０Ｅに格
納される。トランザクション要求２７０２Ｂも同様に、ペイロードＷ２のデータストア横
断書き込みの要求を含む。従って、書き込みペイロードＷ２の第１表現Ｗ２‐Ａはリレー
ショナルＤＢインスタンス２７３０Ｄに格納され、一方、書き込みペイロードＷ２の第２
表現Ｗ２‐Ｂは分散キャッシュインスタンス２７３０Ｃに格納される。トランザクション
要求２７００２Ｃは、単一データストア書き込みを有する。トランザクション要求２７０
２Ｃの書き込みペイロードＷ３の表現Ｗ３‐Ａは従って、ＮｏＳＱＬ ＤＢインスタンス
２７３０Ａに格納される。少なくともいくつかの実施形態において、単一データストア書
き込みを有するトランザクションの請求レートは、データストア横断書き込みトランザク
ションの請求レートとは異なり得る。少なくともいくつかの実施態様において、基準請求
レートがトランザクションごとに課され、そして追加請求額が、トランザクションに含ま
れる書き込みの数と対象データストアの種類とに基づいて課金され得る。

要求トランザクション内に明示的に示される書き込みに加えて、ＬＣＳＧ２７０５は、
自動変換及び／またはあるメンバーデータストアから別のメンバーデータストアへのデー
タのコピーにも対応し得る。このようなデータストア横断変換の２つの実施例が、図２７
に示される。第１の実施例において、書き込みペイロードＷ１の第３表現Ｗ１‐Ｃが、格
納サービスオブジェクト２７３０Ｅの表現Ｗ１‐Ｂから自動的に生成され、キー値インメ
モリデータベース２７３０Ｂに格納される。第２実施例において、Ｗ２‐Ａを変換元とし
て使用して、書き込みペイロードＷ２の第３表現Ｗ２‐Ｃがアーカイブサービスオブジェ
クト２７３０Ｆに格納される。少なくとも一実施態様において、このような自動データス
トア横断変換動作が行われる変換元及び変換先データストアの各組に対し、それぞれの書
き込みアプライヤが設定され得る。例えば、書き込み（Ｗ１‐Ｂ等）が格納サービスオブ
ジェクト２７３０Ｅに適用された時に通知されるリスナーとして特定の書き込みアプライ
ヤが登録され、そのため対応書き込み（Ｗ１‐Ｃ等）がキー値インメモリデータベース２
７３０Ｂにて実行され得る。ＬＣＳＧ２７０５のために実施されている価格設定ポリシー
に従って、描かれた実施形態において、各種類の自動データストア横断変換に対し、それ
ぞれの請求レートが設定され得る。請求レートは、異なる実施形態において、例えば、具
体的な変換元及び変換先データストアの種類、特定の書き込みが変換元データストアに適
用されてから対応表現が変換先データストアに適用されるまでの許容遅延時間等、様々な
要素に基づき得る。従って、例えば、リレーショナルＤＢインスタンス２７３０Ｄ（変換
元データストア）に最初書き込まれるオブジェクトの別の表現をアーカイブ格納サービス
２７３０Ｆ（変換先データストア）内で生成することに対し、請求レートＢＲ１が使用さ
れ、一方、同じオブジェクトの別の表現を分散キャッシュインスタンス２７３０Ｃ等の別
の変換先データストア内で生成することに対し、別の請求レートＢＲ２が使用され得る。
少なくともいくつかの実施形態において、所定の組のデータストアに関して、データスト
ア横断変換動作の方向は、請求レートに影響し得る。

図２８は、少なくともいくつかの実施形態による、ログ整合格納グループに対する価格
設定ポリシーを決定する際考慮され得る要素の実施例を示す。データストアの数及び種類
２８０２は、いくつかの実施形態において、クライアントに支払いが求められ得る最初の
前払い金、並びに現行の利用ベース料金を含む、価格設定のいくつか態様に影響し得る。
例えば、非リレーショナルデータベースの４つのインスタンスを有するＬＣＳＧを設定す
る場合、非リレーショナルデータベース、リレーショナルデータベース、分散キャッシュ
インスタンス、及びアーカイブサービスのアーカイブインスタンスそれぞれを１インスタ
ンスずつ有するＬＣＳＧを設定する場合とは、請求額が異なり得る。ＬＣＳＧにおけるデ
ータストアの数は、同一基礎データに対してクライアントがアクセスできる可能閲覧数も
表し得る。

作業負荷動作種類混合比２８０４は、少なくともいくつかの実施形態において、請求額
に影響し得る。例えば前述のように、データストア横断動作の費用は、単一データストア
動作とは異なり得る。いくつかの実施形態において、顧客の作業負荷における読み出し及
び書き込みの混合比も請求額に影響を及ぼし得る。例えば読み出しの費用は通常、書き込
みより安くあり得る。図１５に関して前述されたように、少なくともいくつかの実施形態
において、ログ読み出しインターフェースにより、クライアントはＬＣＳＧの持続的ログ
に対し直接読み出しを発行可能となり、そしてこのようなインターフェースを使用する毎
読み出し費用は、データストアのインターフェースを使用する毎読み出し費用とは異なり
得る。データストアを対象とする読み出しがプロバイダネットワークのそれぞれのサービ
スにより取り扱われる（すなわち秒ごとにログサービスによるのではない）いくつかの実
施態様において、データストアのネイティブ読み出しインターフェースを使用する読み出
しに対する請求は、ログサービスの使用に対応付けられる請求とは別個に取り扱われ得る
。

ＬＣＳＧの使用に対する価格設定ポリシーは、いくつかの実施形態において、リソース
割り当てモード２８０６に基づいて異なり得る。準備スループットモードにおいて、ログ
サービスは、クライアントの指定スループットレベルに対し利用可能な十分な能力が確実
に残っているように、クライアントに対しリソースを確保または献呈する必要があり得る
。対照的に、ベストエフォート型リソース割り当てモードにおいて、クライアント要求を
遂行するために共有リソースが使用され、これにより、ログサービスリソースの平均使用
レベルは準備スループットモードより高くなり得る。従って、少なくともいくつかの実施
形態において、準備スループットモードが使用される時と、ベストエフォートモードが使
用される時とでは、同一の実トランザクションレートに対し、異なる額がクライアントに
課され得る。いくつかの実施形態において、要求レート段階２８０８が価格設定ポリシー
に関して定義され得る。段階ベース価格設定に従って、所定のトランザクションに対する
請求レートは、クライアントが毎秒０〜１０００トランザクション要求を発行したか否か
、またはクライアントが毎秒１０００〜２０００トランザクションを発行したか否かに応
じて異なり得る。少なくともいくつかの実施形態において、クライアントの作業負荷に対
するネットワーク帯域使用量２８１０が、価格設定ポリシーに影響し得る。トランザクシ
ョンの特徴に応じて、特定数Ｎ１個のトランザクション要求は、第１クライアントに対し
てＸギガバイトのトラフィックとなり、一方、Ｎ１個のトランザクションは、別のクライ
アントに対して（または第１クライアントに対しても別の時間間隔において）Ｙギガバイ
トのトラフィックとなり得る。ログサービスにより生じるリソース使用量の少なくとも一
部はネットワーク帯域に比例して異なり得るため、ログサービスのいくつかの価格設定ポ
リシーは、測定帯域使用量に少なくとも部分的に基づき得る。様々な実施形態において、
ログサービスにより使用される監視インフラストラクチャ（例えばメトリクスコレクタ２
６５５Ａ）は、異なるクライアントに対し帯域使用量を割り当てる様々な技術を使用し得
る。例えば、このような割り当ては、ネットワークパケットヘッダーに組み込まれるクラ
イアントＩＰアドレス、パケットヘッダーまたは本体に組み込まれるクライアント識別子
等に基づき得る。

少なくともいくつかの実施形態において、価格設定ポリシーは、レイテンシ要件２８１
２、可用性要件２８１４、及び／またはデータ耐久性要件２８１６に基づいて定義及び／
または選択され得る。例えば、ほとんどのトランザクションは対応トランザクション要求
が提出されて２秒以内に受諾されるという要件を１つのクライアントのアプリケーション
集合が有し、そしてこのようなクライアントは、提出済みのトランザクションの少なくと
も９５％が２秒以内に受諾されるのであれば、より高い毎トランザクションレートを支払
う意思があり得る。このようなレイテンシパーセンタイル値測定または平均レイテンシに
基づいた価格設定ポリシーは従って、このような実施形態においてログサービスにより対
応され得る。異なるクライアント及び／またはクライアントアプリケーションは、いくつ
かの実施形態において、ログサービスに対し異なる高可用性要件２８１４（例えばＬＣＳ
Ｇの様々なコンポーネントが９９．９９％の時間、または９９．９９９９％の時間、オン
ラインで応答可能である必要がある）を有し、これは選択された価格設定ポリシーに影響
し得る。少なくとも一実施形態において、データ耐久性に関する要件２８１６（例えばロ
グレコードの最大許容データ損失レート）も価格設定に影響し得る。

ログサービスは、例えばプロバイダネットワークにおいて実施されるプロプライエタリ
データベースもしくは格納サービス、人気のオープンソースデータベース、キャッシュサ
ービス等、多数の異なるデータストアの種類にネイティブに対応し得る。さらに、少なく
ともいくつかの実施形態において、ログサービスは、第三者またはクライアントにより拡
張可能であり得る。このような実施形態において、拡張性インターフェース集合が開示さ
れ、これにより、ログサービスのオペレータ以外の組織または個人は、新たなデータスト
アの種類のログベーストランザクション管理に対しサポートを追加することが可能になる
。例示的拡張は、ログサービスによりネイティブに対応されない様々なデータストアに対
する書き込みアプライヤ、または、このようなデータストアが図２７に例示される類の自
動データストア横断変換の変換元または変換先として機能することを可能にするデータト
ランスフォーマを含み得る。少なくともいくつかの実施形態において、ＬＣＳＧの価格設
定ポリシーは、このような拡張の使用を考慮し得る。例えば、ネイティブに対応されるデ
ータストアを使用するトランザクションに適用される料金とは異なる料金が、拡張を使用
するトランザクションに適用され得る。

様々な実施形態において、所定の顧客のための所定のＬＣＳＧに使用する具体的な価格
設定ポリシーを特定するために、図２７に例示される要素のうちのいくつか（または全て
）が結合され得ることに留意されたい。例えば、段階的価格設定及び／または帯域ベース
価格設定は、いくつかの実施形態において、準備スループット型リソース割り当てモード
またはベストエフォート型リソース割り当てモードと組み合わせて適用され得る。同様に
、ＬＣＳＧに含まれるデータストアの数及び種類は、様々な実施形態において、作業負荷
動作混合比、スループット段階、レイテンシベース価格設定等と相まって、請求額に影響
し得る。

少なくともいくつかの実施形態において、ログサービスのクライアントは、いくつかの
選択肢の中から価格設定ポリシーを選択する機会を与えられ得る。図２９は、少なくとも
いくつかの実施形態による、ログ整合格納グループを実施するサービスのユーザに対し価
格設定ポリシーの選択肢を示すために使用され得る例示的ウェブベースインターフェース
を示す。示されるように、ウェブページ２９０１は、メッセージエリア２９０４と、多数
の書式フィールドとを備え、書式フィールドは、ログサービスユーザが、異なる価格設定
ポリシーコンポーネントを試行して、ユーザの要件及び予算に最適である特定の価格設定
ポリシー要素集合を選択するために、使用され得る。

メッセージエリア２９０４に示されるように、描かれた実施形態におけるＬＣＳＧの使
用に関する費用は、ログサービスを使用してトランザクションが管理されるデータストア
の数及び種類に依存し得る。ユーザは、構成要素２９０７を使用して、ＬＣＳＧにいくつ
の異なる種類のデータストアを含めるか指示し、これを基に、価格がウェブページ２９０
１を使用して推定または決定される。例えば、クライアントはゼロまたは複数のＮｏＳＱ
Ｌデータベースのインスタンス、ゼロまたは複数のリレーショナルデータベースのインス
タンス、ゼロまたは複数のインメモリデータベースのインスタンス、及び／またはゼロま
たは複数の他の種類のデータベースのインスタンスを選択し得る。データストアカウント
フィールドを含むページ２９０１上に表示される書式フィールドのうちのいくつかに関し
て、ログサービスは初期設定値を示し得る（ＮｏＳＱＬデータベースインスタンスの数の
初期設定値は１等）。いくつかの実施形態において、ユーザが様々な書式フィールド内に
値を入力すると、ウェブページ２９０１の他の構成要素内のデータは、瞬時またはほぼ瞬
時に更新され得る。例えば、ユーザがＮｏＳＱＬデータベースインスタンスの数を１から
２に変更すると、総請求月額２９２５に対するこのような変更の影響が、リアルタイムに
示され得る。

描かれた実施形態において、ユーザは、書式フィールド２９１０を使用して、リソース
割り当てモードに対する希望（例えば準備スループット型あるいはベストエフォート型）
を指示し得る。図２９の例示的シナリオにおいて、単一データストア要求とデータストア
横断要求の両方に対し、段階的価格設定モデルが使用され得る。データストア種類ごとに
、書き込みの予想要求レート（例えば毎秒書き込み数）が、書式フィールド２９１３を使
用して指示され得る。データストア横断書き込み（所定の変換元データストア種類と所定
の変換先データストア種類の間）の予想要求レートが、書式フィールド２９１６を使用し
て指示され得る。他の変換元と変更先の組のデータストア横断変換の予想要求レートも、
例えばフィールド２９１６内に示されるリンクをクリックして変換元、変換先、及びレー
トを指示することにより、同様に指示され得る。書き込み要求レートのフィールド等、１
つまたは複数のフィールドに関して、ウェブページ２９０１は、個別の選択肢集合を有す
るドロップダウンメニューを提供し得る（例えばこれにより、ユーザがマイナスの要求レ
ート等、対応エンティティの不対応値を指示することが防止される）。ユーザはまた、描
かれた実施形態において、構成要素２９１９を使用して、帯域使用量段階を指定し得る。
レイテンシ、データ耐久性及び／または可用性に関するカスタム希望指示は、構成要素２
９２２内に示されるリンクをクリックすることにより提供され、そしてこのような希望指
示も価格設定に影響し得る。ユーザが入力した値に基づいた請求月額の見積もりが、ウェ
ブページ２９０１の構成要素２９２５内に提供され得る。ウェブページ２９０１は、ログ
サービスのクライアントが価格設定ポリシー選択肢から選択を行うことを可能にするため
に使用され得るプログラマチックインターフェースの一例にすぎないことに留意されたい
。定義済み性能特性を有する事前定義のデータストアパッケージ（例えば「小さい」ある
いは「中くらい」あるいは「大きい」ＬＣＳＧ）及び価格設定ポリシーの使用等、多数の
他の手法が、別の実施形態において使用され得る。ユーザが最初に予算を指定して、その
後そのような予算に対応可能な特定のデータストアの組み合わせ、作業負荷混合比等をユ
ーザに案内する予算ベースモデル等、価格設定に対し他の手法をとるウェブページが、別
の実施形態において使用され得る。いくつかの実施形態において、ＬＣＳＧ価格設定に影
響すると示される要素は、図２９に示されるものとは異なり得る。様々な実施形態におい
て、ウェブページよりも、ＡＰＩ、カスタム価格設定ＧＵＩ、または他のプログラマチッ
クインターフェースが使用され得る。

図３０は、少なくともいくつかの実施形態による、ログ整合格納グループ（ＬＣＳＧ）
に対応するサービスにて請求額を決定するために行われ得る動作態様を示すフロー図であ
る。構成要素３００１に示されるように、サービスは、クライアントのための特定のログ
整合格納グループのメンバーとして指定された複数のデータストア（例えばリレーショナ
ルデータベース、非リレーショナルデータベース、インメモリデータベース、分散キャッ
シュ環境、格納サービスオブジェクト集合、ファイルシステム等のインスタンス）を特定
または同定し得る。いくつかの実施形態において、メンバー情報は、データストアが登録
された時に（例えばクライアントの要求でＬＣＳＧが設定された時に）、サービスの制御
プレーンコンポーネントにおいて取得され得る。別の実施形態において、現行メンバーを
特定するために、ＬＣＳＧメンバー情報のレポジトリ（メンバーの追加または削除により
経時的に変化し得る）が、例えば少なくとも請求期間ごとに１度、調べられ得る。読み出
しは、データストアに対しそれぞれの読み出しインターフェースを介して送られ、一方書
き込みは、書き込みレコードログのコンテンツに少なくとも部分的に基づいて、ＬＣＳＧ
のトランザクションマネジャーにより受諾または拒否され得る。

構成要素３００４に示されるように、ＬＣＳＧの使用に対する請求額に影響する複数の
価格設定ポリシーの選択肢または要素の指示が、クライアントに提供され得る。少なくと
もいくつかの実施形態において、クライアントは、図２９に示されるものと同様のプログ
ラマチックインターフェースを使用して、所定のＬＣＳＧの可能性のあるデータストアの
組み合わせを指示し、そしてサービスはクライアントの入力に応じて価格設定ポリシーの
選択肢を表示し得る。価格設定ポリシー選択肢は、異なる実施形態において価格設定の決
定に関与し得る幅広い種類の要素を含み得る。これには例えば、ＬＣＳＧのメンバーであ
るデータストアの数及び種類のある組み合わせ、動作種類の混合比（例えば単一データス
トア書き込み対複数データストア書き込み）、リソース割り当てモード（例えば準備スル
ープット型あるいはベストエフォート型）、段階的または絶対的性能レベル（例えばスル
ープットまたはレイテンシに関して）、帯域使用量、データ耐久性、可用性等が含まれる
。

特定の価格設定ポリシー、例えばデータストア選択、データストア横断書き込み等の異
なる動作種類の予想作業負荷レベルに関してクライアントが提供した入力に少なくとも部
分的に基づいて導出されるポリシーを、少なくともある時間帯に、クライアントのＬＣＳ
Ｇに対し使用するという指示が、クライアントから受信され得る（構成要素３００７）。
当該時間帯に、価格設定ポリシーに関連する様々なメトリクスが収集され、例えばサービ
スの請求／価格設定制御プレーンコンポーネントに提供され得る。様々な種類のクライア
ント要求の数及びレート（かつクライアント要求に対応付けられた応答時間またはレイテ
ンシ）を含む作業負荷関連メトリクス、並びにクライアントが使用したネットワーク帯域
等のリソース関連メトリクスが収集され得る。いくつかの実施形態において、制御プレー
ンコンポーネントは、作業負荷レコード（及び／またはリソース使用量メトリクス）を、
例えばデータストア横断書き込み、あるいは単一データストア書き込みといった、異なる
動作カテゴリを表すサブグループに分類する責務を担い得る（構成要素３０１０）。描か
れた実施形態において、収集されたメトリクスと、クライアントのために、またはクライ
アントにより選択された価格設定ポリシーとに基づいて、時間帯の請求額が決定され（構
成要素３０１３）、クライアントに示され得る（構成要素３０１６）。少なくとも一実施
形態において、クライアントは、サービスのプログラマチックインターフェースを使用し
て、先の請求時間帯の請求ポリシーを変更し得る。

読み出し再現性検証のための記述子
前述のように、ログベーストランザクションマネジャーは、いくつかの種類の直接読み
出し動作に関して、読み出し位置（すなわちトランザクション中にデータが読み出される
アドレスに関する情報）にのみ基づいて、後続の書き込みとの競合を検出することが可能
であり得る。しかしながら、さらに複雑な読み出しに関しては、このような単なる位置ベ
ース競合検出は、十分ではあり得ない。図３１は、少なくともいくつかの実施形態による
、トランザクション受諾のために読み出し位置ベース競合検出を使用することによりデー
タ不整合が生じ得る、格納システムにおける例示的一連イベントを示す。タイムライン３
１９９は、ログサービスのクライアントの観点からの一連のイベントＥ１、Ｅ２、Ｅ３、
Ｅ４、Ｅ５を、より前のイベントは左側に、そしてより後のイベントは右側に示す。デー
タストア３１１０は、Ｅ１より前に少なくとも３つレコードを有する「従業員」テーブル
を備える。各レコードはそれぞれの位置（“Ｌｃ”等、接頭文字“Ｌ”の表示で示される
）を有し、従業員名フィールド及び給与フィールドを含む。描かれた実施例において、従
業員“Ａｎｄｙ”の給与は＄Ｘであり、従業員“Ａｎｎ”の給与は＄Ｙである。イベント
Ｅ１は、クライアントによる、“Ａ”で始まる名前の従業員のレコードのコンテンツを取
得する読み出し要求Ｒ１の提出に対応する（例えば、ＳＱＬのような疑似コードで、要求
「従業員テーブルから従業員名が“Ａ”で始まる＊を選択」が提出され得る）。イベント
Ｅ２は、従業員“Ａｎｄｙ”、“Ａｎｎ”のレコードを含むＲ１の結果集合を有する、デ
ータストアからの応答を含む。２つのレコードのアドレス／位置Ｌｃ、Ｌｋ、並びに最新
のコミット済み書き込み（読み出しより前）がデータストア３１１０に適用された時を示
す論理タイムスタンプＬＴＳ１も、クライアントに返される。

その後クライアントは、Ｒ１の結果集合に基づいて、“Ａ”で始まる名前の従業員の平
均給与（“Ａ＿ｓａｌ”）の計算を行う（イベントＥ３）。クライアントが受信した結果
集合に従って、Ａ＿ｓａｌは、＄Ｘと＄Ｙの平均に設定される（すなわち（＄Ｘ＋＄Ｙ）
／２）。その一方で、（ＬＴＳ１＋デルタ１）に対応するある時間に、新従業員“Ａｒｔ
”（給与は＄Ｊ）のレコードが、書き込みアプライヤにより従業員テーブル内の位置Ｌｎ
に挿入される。クライアントは、挿入に気が付かずに、クライアントにより計算されたＡ
＿ｓａｌの書き込みを含むトランザクション要求を準備する。ＴＲ１はまた、読み出し位
置Ｌｃ、Ｌｋ（例えば２つの位置のそれぞれのハッシュシグネチャを使用する）と、競合
検査デリミタとして論理タイムスタンプＬＴＳ１とを示す。ＴＲ１は、論理タイムスタン
プ（ＬＴＳ１＋デルタ１＋デルタ２）に対応する時間に、データストア３１１０に割り当
てられたログベーストランザクションマネジャー（ＬＴＭ）において調べられる（イベン
トＥ４）。競合検出の一環として、ログベーストランザクションマネジャーは、ＬＴＳ１
以降に読み出し集合位置Ｌｃ、Ｌｋに対し書き込みが行われたか否かを検査し、いずれの
そのような書き込みも発見しない。従って、（ＬＴＳ１＋デルタ１＋デルタ２）のコミッ
ト論理タイムスタンプと、Ａ＿ｓａｌの不整合／不正確な値とを有する要求トランザクシ
ョンが、コミットのために受諾される（イベントＥ５）。（示される例示的一連イベント
を考えると、Ａ＿ｓａｌの値は、（＄Ｘ＋＄Ｙ）／２の代わりに（＄Ｘ＋＄Ｙ＋＄Ｊ）／
３に設定されるべきであり、故に不整合または不正確とみなされ得る。）不一致は、ＬＴ
Ｍによるエラーの結果ではなく、むしろいくつかの種類の読み出しに関してアドレスベー
スの読み出し書き込み競合検出は、必ずしも読み出し再現性を検証するのに使用可能とは
限らないという事実の結果であることに留意されたい（すなわち読み出しの結果集合が変
化していないことを検査するには、読み出しが再発行されなければならない）。

図３１に例示される問題の類に対応するために、トランザクション要求に含められる読
み出し記述子は、アドレスベースのハッシュシグネチャ等の位置インジケータよりも複雑
なメタデータを含む必要があり得る。例えば、いくつかの種類の読み出しに関して、メタ
データは、読み出しに使用されるクエリ述語（例えばＳＱＬのようなクエリの「ＷＨＥＲ
Ｅ句」）の少なくとも一部の符号化、または読み出し要求の全テキストさえ、含み得る。
いくつかの事例において、読み出しの結果集合が変化したか否かを判定するために呼び出
し可能な関数（または関数へのポインタ）が、メタデータ内に示され得る。いくつかの実
施形態において、読み出しの結果が変化したか否かを判定するために評価され得る式が、
ＲＲＶＭとして提供され得る。用語「読み出し再現性検証メタデータ」（ＲＲＶＭ）は、
本明細書において、対応読み出し要求が再提出された場合でも、前の読み出し要求の提出
時と同じ結果集合を生じるか否か、すなわち所定の読み出し要求は、最初の読み出し要求
の提出後のある時点で「再現可能な読み出し」を表すか否かを、判定するために使用可能
な情報を指すのに使用され得る。

図３２は、少なくともいくつかの実施形態による、読み出し要求に応じて提供される読
み出し記述子がＲＲＶＭコンポーネントを含むシステム環境を示す。示されるように、シ
ステム３２００は、格納サービスの異種格納グループ３２０１を含み、当該格納グループ
は、メンバーデータストア３２３０Ａ、３２３０Ｂを備える。各データストア３２３０は
、例えばデータストア３２３０Ａの読み出しインターフェース３２２７Ａ、データストア
３２３０Ｂの読み出しインターフェース３２２７Ｂ等、それぞれのプログラマチック読み
出しインターフェースを提示し得る。２つのデータストアは、読み出しインターフェース
のみではなく、基礎データモデルにおいても異なり得る（例えば１つのデータストアはリ
レーショナルデータベースのインスタンスを有し、一方もう一つのデータストアは非リレ
ーショナルデータベースのインスタンスを表し得る）。データストア３２３０は、いくつ
かの実施形態において、データストアがプロバイダネットワークにてインスタンス化され
たクライアント等、特定のクライアントの要求で、格納グループ３２０１のメンバーとし
て登録され得た。各データストアは、データストア３２３０Ａのオブジェクト３２１０Ａ
〜３２１０Ｆ、及びデータストア３２３０Ｂのオブジェクト３２１０Ｍ〜３２１０Ｑ等、
それぞれの複数のデータオブジェクト（例えばレコード、ファイル、ウェブサービスイン
ターフェースを介してアクセス可能な非構造化データオブジェクト、キャッシュエントリ
等、データソースの性質による）を含み得る。さらに、各データストアは、データストア
で行われた様々な書き込み動作に対応する論理スタンプ等、１つまたは複数のステート遷
移インジケータ３２２５を格納し得る。例えば、データストア３２３０Ａの事例において
、３つの異なる書き込みＷ１‐Ａ、Ｗ２‐Ａ、Ｗ３‐Ａがこの順序で完了または適用され
た場合、Ｗ３‐Ａの書き込みが完了した後の少なくとも１つのＳＴＩ３２２５Ａは、Ｗ３
‐Ａに対応付けられる論理タイムスタンプに該当し得る。同様に、データストア３２３０
Ｂにおいて、書き込みＷ１‐Ｂ、Ｗ２‐Ｂがこの順序で完了した後の少なくとも１つのＳ
ＴＩ３２２５Ｂは、Ｗ２‐Ｂに対応する論理タイムスタンプを表し得る。

描かれた実施形態において、格納グループ３２０１の様々なメンバーデータストア３２
３０はそれぞれ、共通読み出し記述子形式３２９８に従って、読み出し記述子を生成する
ように構成され得る。読み出しインターフェース３２２７Ａを介してデータストア３２３
０Ａにて受信された読み出し要求Ｒ１‐Ａに応じて、例えば、ＳＴＩ３２４６ＡとＲＲＶ
Ｍ３２４４Ａを含む読み出し記述子３２４２Ａが、格納サービスのクライアント側コンポ
ーネント３２３５へ提供され得る。前述のように、ＲＲＶＭは、最初のＲ１‐Ａ結果集合
３２４０Ａが生成された後のある時点で、Ｒ１‐Ａの結果集合が変化したか否かを判定す
る（またはある高い確率で予測する）ために使用され得る。少なくともいくつかの実施形
態において、クライアント側コンポーネント３２３５は、エンドユーザ３２６６からエン
ドユーザ読み出し要求（及び／または書き込み要求）を受信し、対応内部要求を好適なバ
ックエンドデータストア３２３０へ送る格納サービスのフロントエンド要求ハンドラノー
ドを備え得る。別の実施形態において、クライアント側コンポーネント３２３５は、格納
サービスにより提供されるライブラリのコンポーネントを備え、当該ライブラリコンポー
ネントは、例えば異種格納グループ３２０１が実施されるプロバイダネットワークの外側
、またはプロバイダネットワーク内で、クライアント所有のコンピューティングデバイス
にてインストール及び実行され得る。一般に、異種格納グループが実施されるプロバイダ
ネットワーク内、またはプロバイダネットワークの外側に配置され、かつ読み出し要求及
び／またはコミット要求のために本明細書において説明されるプログラマチックインター
フェースを使用可能な任意のプロセスまたはデバイスが、クライアント側コンポーネント
として機能し得る。同様に、読み出しインターフェース３２２７Ｂを介してデータストア
３２３０Ｂへ送られる読み出し要求Ｒ１‐Ｂに応じて、Ｒ１‐Ｂの結果集合３２４０Ｂに
加えて、読み出し記述子３２４２Ｂが、クライアント側コンポーネントに提供され得る。
読み出し記述子３２４２Ｂは、Ｒ１‐Ｂが再現可能な読み出しであるか否かを検証するた
めに使用可能なＲＲＶＭ３２４４Ｂと、Ｒ１‐Ｂの最初の結果集合３２４０Ｂが生成され
た時のデータストア３２３０Ｂのステートに対応するＳＴＩとを含み得る。少なくともい
くつかの実施形態において、ＲＲＶＭ３２４４を含む読み出し記述子３２４２は、対応読
み出しがこれからトランザクション要求に使用されるか否か（例えば書き込みが読み出し
要求の結果集合に依存するか否か）とは関係なく、読み出し要求に応じて提供され得るこ
とに留意されたい。同様に、ＲＲＶＭを含む読み出し記述子は、少なくともいくつかの実
施形態において、データストアに対する書き込みがクライアント側コンポーネントにより
直接行われるか否か、または書き込みが前述の類のログベーストランザクションマネジャ
ーにより整合され、及び／または前述の類の書き込みアプライヤにより伝播されるか否か
に関係なく、提供され得る。少なくともいくつかの実施形態において、単純な読み出し（
例えば「テーブルＴ１からレコードＩＤがＲＩＤ１である^*を選択」）に関して読み出し
再現性を検証するには、読み出しオブジェクトのアドレスの符号化（例えばハッシュシグ
ネチャ）、または読み出しオブジェクトの識別子の符号化で十分であり得る。従って、よ
り複雑な読み出しの再現性を検査するために述語ベースまたはクエリ句ベースのメタデー
タが生成される実施形態においてでも、いくつかのＲＲＶＭは位置ベースインジケータを
含み得る。少なくとも一実施形態において、例えばＲＲＶＭが「単一位置ハッシュシグネ
チャ」であるか、「複雑クエリ符号化」であるか等、提供されるＲＲＶＭの種類を示すフ
ィールドが、読み出し記述子内に含まれ得る。

少なくともいくつかの実施形態において、データストアは、いくつかの異なる粒度でス
テート遷移に関する情報を格納し、そして複数のステート遷移インジケータが読み出し記
述子に含まれ得る。図３３は、少なくともいくつかの実施形態による、読み出し記述子の
例示的構成コンポーネントを示す。描かれた実施形態において、例示的データストア３３
３０は、テーブル３３１０Ａ、３３１０Ｂ等、複数のテーブル３３１０を備える。各テー
ブルは多数のデータレコードを含み、各データレコードは、各自のレコード識別子すなわ
ちＲＩＤ（レコードの位置インジケータとして機能し得る）３３１８と、レコードに対し
て適用された最新更新または書き込みを示す各自のレコード変更タイムスタンプ（ＲＭＴ
）３３２０とを有する。従って、例えば、テーブル３３１０Ａは、ＲＩＤ３３１８Ａ、３
３１８Ｂ、３３１８Ｃを有するレコードを含み、一方、テーブル３３１０Ｂは、ＲＩＤ３
３１８Ｋ、３３１８Ｌ、３３１８Ｍを有するレコードを含む。各レコードは、図示されて
いない他のデータカラムまたは属性を含み得る。少なくともいくつかの実施形態において
、ＲＭＴ３３２０は、論理タイムスタンプを表し（実時間ベースタイムスタンプの代わり
に）、論理タイムスタンプは、例えば単調に増加するタイムスタンプ値を生成し、かつデ
ータストアによりアクセス可能な論理クロックの出力値で表現される。描かれた実施形態
において、レコードがテーブル３３１０に挿入されると、そのＲＭＴは挿入に対応する論
理タイムスタンプ値に設定され得る。後で同一のレコードが更新されたとすると、当該Ｒ
ＭＴは、更新の論理タイムスタンプを示すように更新され得る。いくつかの実施形態にお
いて、論理クロックは、単調に増加する一連のタイムスタンプ値（実時間値に対応しない
かもしれない）を提供する責務を担い得る。一実施態様において、格納グループごとに、
単一の論理タイムスタンプ源が特定され得る（例えばグループのトランザクションマネジ
ャーに対応付けられたクロック）。別の実施形態において、異なるデータストアが異なる
論理クロックを使用し得る。

描かれた実施形態において、レコードレベル変更時間情報に加えて、テーブルレベル変
更時間情報も同様に、テーブル変更タイムスタンプ（ＴＭＴ）の形態で、例えばテーブル
３３１０ＡのＴＭＴ３３１６Ａ、テーブル３３１０ＢのＴＭＴ３３１６Ｂ等で、保持され
得る。描かれた実施形態において、テーブル３３１０のＴＭＴは、そのテーブルのレコー
ドのＲＭＴの中で最新のＲＭＴを示し得る。従って、テーブル３３１０に関して、所定の
時点でＲＩＤ３３１８Ｃを有するレコードがテーブル内で最新の書き込み対象レコードで
ある場合、ＴＭＴ３３１６Ａも、ＲＭＴ３３２０Ｃと同じ論理タイムスタンプ値を含み得
る。同様に、さらに高い粒度で、データストア変更タイムスタンプ（ＤＭＴ）３３０８が
、データストア３３３０に格納されているレコードのうちのいずれかにおける最新の変更
を示す、テーブルのＴＭＴの中で最新のＴＭＴ値に設定され得る。

図３３に示される実施形態において、データストア３３１０内の所定のレコードに対す
る読み出しの読み出し記述子は、レコードレベル（例えば読み出されたレコードが最後に
変更された時間を示す）、テーブルレベル、及びデータストアレベルの３つのレベルの階
層全てに関する変更論理タイムスタンプを示し得る。示されるように、その結果集合がテ
ーブル３３１０Ａのレコード３３１８Bを含む読み出し要求Ｒ１に応じて、生成された読
み出し記述子ＲＤ１は、ＲＭＴ３３２０Ｂ、ＴＭＴ３３１６Ａ、及びＤＭＴ３３０８を含
み得る（読み出し再現性検証メタデータ（ＲＲＶＭ）３３４０Ａに加えて）。同様に、そ
の結果集合がテーブル３３１０Ｂのレコード３３１８Ｍを含む読み出し要求Ｒ２に応じて
、読み出し記述子ＲＤ２は、ＲＭＴ３３２０Ｍ、ＴＭＴ３３１６Ｂ、ＤＭＴ３３０８、及
び異なるＲＲＶＭ３３４０Ｂを含み得る。読み出しの結果集合がいくつかの異なるレコー
ドを含む場合、いくつかの実施態様において、これらのレコードのＲＭＴのうち最小のＲ
ＭＴが読み出し記述子に含まれ、一方、他の実施態様において、全てのレコードのＲＭＴ
が読み出し記述子に含まれ得る。同様に、所定の読み出し要求の結果が複数のテーブルか
らのレコードを含む場合、いくつかの実施形態において、テーブルのＴＭＴの中の最小Ｔ
ＭＴが読み出し記述子内に示され、一方、他の実施形態において、テーブルのＴＭＴ全て
を含むベクトルが読み出し記述子に含まれ得る。異なる実施態様において、また異なる種
類のデータストアに、ステート遷移レコードの他の階層が使用され得る。例えば、データ
ストアテーブルがパーティションに分割される実施形態においては、パーティション変更
タイムスタンプが読み出し記述子に含まれ得る（例えばＴＭＴに加えて、あるいはＴＭＴ
の代わりに）。いくつかの実施形態において、ファイルシステムを実施するデータストア
には、ファイル、ディレクトリ、及びファイルシステムに対する書き込みの論理タイムス
タンプが、ステート遷移インジケータの階層として使用され得る。いくつかの実施形態に
おいて、読み出し記述子にステート遷移インジケータの階層を含むことにより（ＤＭＴ等
の単一値のみの代わりに）、ログベーストランザクションマネジャーは、異なるレベルの
保守性にて並行処理制御決定を行うことが可能になり得る。例えば、一保守的手法におい
て、トランザクションマネジャーは、ＤＭＴ以降にデータストアのレコードのうちのいず
れかを対象とした全ての書き込みを競合書き込みとして特定し、一方、より保守性の低い
手法においては、そのＲＭＴが競合とみなされ得る特定レコード（複数可）読み出しを対
象とした書き込みのみを競合書き込みとして特定し得る。

少なくともいくつかの実施形態において、図３２において示されるように、読み出し記
述子が格納グループのデータストアにより、システムのクライアント側コンポーネントに
対し提供され得る。いくつかのこのような実施形態において、読み出し記述子は、クライ
アント側コンポーネントにて生成されるトランザクションコミット要求内に組み込まれ、
並行処理制御目的でトランザクションマネジャーにより調べられ得る。多数の理由から、
読み出し記述子はトランザクションマネジャーにより解読可能でなければならないが、少
なくともいくつかの実施形態において、ログサービスまたはプロバイダネットワークのオ
ペレータは、読み出し記述子の内部詳細が、読み出し及び書き込み要求を提出するエンド
ユーザに対し可視状態であることを所望しないかもしれない。例えば、サービスオペレー
タは、読み出し記述子の形式またはコンテンツを変更する能力を保持することを所望し得
る。しかしエンドユーザが固定サイズのエンドユーザ可読読み出し記述子を期待し慣れて
しまった場合、そのような能力を保持することは難しくあり得る。従って、いくつかの実
施形態において、読み出し記述子のコンテンツは、クライアント側コンポーネントに送信
される前に、１つまたは複数の変換処理を施され得る。図３４は、少なくともいくつかの
実施形態による、格納システムのクライアント側コンポーネントに読み出し記述子が提供
される前に読み出し記述子に適用され得る例示的変換を示す。３つのレベルの格納階層の
それぞれの変更論理タイムスタンプ（データストア、テーブル、及びレコード）が、描か
れた実施形態において生成される読み出し記述子に含まれる。示されるように、非修正ま
たは変換前状態の読み出し記述子３４０１は、元のＤＭＴ３４０８に使用されるＮ１バイ
トと、元のＴＭＴ３４１６に使用されるＮ２バイトと、元のＲＭＴ３４２０に使用される
Ｎ３バイトと、ＲＲＶＭ３４４０に使用されるＮ４バイトとを含む、Ｎ１＋Ｎ２＋Ｎ３＋
Ｎ４バイトを有し得る。

描かれた実施形態において、第１変換で、複数（Ｎ５）のバイトが、読み出し記述子に
「パディング」として追加され得る。いくつかの実施形態において、例えば乱数ジェネレ
ータを使用してパディングサイズのある選択された範囲内からパディングバイトの数を選
択することで、異なる数のバイトが同じデータストアにて生成された異なる読み出し記述
子に追加され得る。いくつかの実施形態において、パディングバイトには、ランダムに選
択されたデータも投入され得る。このようなランダムに生成されたパディング要素のおか
げで、エンドユーザは、全ての読み出し記述子が同一サイズであると想定しないようにな
り得る。

いくつかの実施形態において、パディング変換に加えて、読み出し記述子が同様または
代わりに、符号化または難読化され、そのため読み出し記述子の構成要素は、復号化なし
では解釈または理解不可能となる。従って、例えば、パディングされた読み出し記述子３
４５１は、クライアント側コンポーネントに送信される前に、難読化読み出し記述子３４
５８に暗号化または符号化され得る。描かれた実施形態において、格納サービスのサーバ
側コンポーネント（読み出し記述子が復号化される必要があり得るトランザクションマネ
ジャー等）は、必要なメタデータ（例えば復号化認証情報、または読み出し記述子の復号
化に使用する機能または方法の指示）を有し得るが、難読化を取り消すために必要な情報
は、エンドユーザによりアクセス可能ではあり得ない。様々な実施形態において、異なる
２つの一連変換（パディング及び難読化）が行われ得る。例えば読み出し記述子の構成要
素の原版は、いくつかの実施形態において、パディングバイトが追加される前に、まず符
号化され得る。いくつかの実施形態において、パディングのみ、または難読化のみが使用
され得る。少なくともいくつかの実施形態において、読み出し記述子はクライアント側コ
ンポーネントに送信される前に、他の変換が同様に適用され得る。例えば記述子は圧縮さ
れ得る。

ステートレスデータストア独立トランザクション
図３５は、少なくともいくつかの実施形態による、格納システムのクライアント側コン
ポーネントから候補トランザクションコミット要求の提出を引き起こす例示的一連動作を
示す。クライアント側コンポーネントは、例えば、格納サービスのフロントエンド要求ハ
ンドラで実行されるプロセス、またはクライアント所有コンピューティングデバイスにて
インストール可能な格納サービスプロバイダライブラリのコンポーネントを備え得る。ク
ライアント側コンポーネントタイムライン３５９９上の時間ｔ１に、ＢＥＧＩＮ＿ＴＲＡ
ＮＳＡＣＴＩＯＮ要求が、例えばエンドユーザから、クライアント側コンポーネントにて
受信され得る。クライアント側コンポーネントは、いくつかの実施形態において、ＢＥＧ
ＩＮ＿ＴＲＡＮＳＡＣＴＩＯＮ要求に応じて、候補トランザクション要求を準備するため
に、メモリバッファ３５３５を割り当て得る、または確保し得る。別の実施形態において
、メモリバッファ３５３５は、トランザクションの異なる読み出し及び／または書き込み
が完了すると、動的に割り当てられ得る。

タイムライン３５９９上の時間ｔ２に、読み出し要求Ｒ１が、クライアント側コンポー
ネントから（例えばサービスのフロントエンド要求ハンドラまたはライブラリコンポーネ
ントにて受信されたエンドユーザ読み出し要求に応じて）、ステートレスプロトコルを介
して異種格納グループ３５７５のデータストアＤＳ１に対し送られ得る。描かれた実施形
態において、異種格納グループ３５７５は、メンバーデータストアＤＳ１、ＤＳ２、ＤＳ
３、ＤＳ４を含み、それぞれは、書き込み動作がログベーストランザクションマネジャー
（ＬＴＭ）を介して管理される格納グループのメンバーとして登録済みであり得る。格納
グループ３５７５のメンバーはまた、読み出し要求に応じて、読み出し記述子（例えば前
述の類のステート遷移インジケータ及びＲＲＶＭを含む記述子）を生成及び送信するよう
に求められ得る。格納グループの少なくともいくつかのメンバーは、いくつかの実施形態
において、異なるデータモデル（例えばリレーショナルあるいは非リレーショナルデータ
ベース、構造化あるいは非構造化レコード）を、対応読み出しインターフェース及びレコ
ード／オブジェクト格納形式で実施し得る。前述のように、例えば、リレーショナルデー
タベース、非リレーショナルデータベース、インメモリデータベース、分散キャッシュ、
プロバイダネットワークサービスにより実施されるウェブサービスインターフェースを介
してアクセス可能な格納オブジェクト集合、プロバイダネットワークにて実施される待ち
行列サービス、またはプロバイダネットワークにて実施される通知サービスのインスタン
スを含む、多数の異なるカテゴリのデータストアが格納グループに含まれ得る。描かれた
実施形態において、読み出し要求Ｒ１に対応する結果集合３５１０Ａ及び読み出し記述子
３５１２Ａがクライアント側コンポーネントに送信された後、ＤＳ１はクライアント側コ
ンポーネントに関するいかなるセッションメタデータも保持し得ないという点で、読み出
し要求Ｒ１に使用されるプロトコルは、ステートレスであり得る。異なる実施形態におい
て、読み出し要求及び応答には、例えばＲＥＳＴ（具象的ステート転送）アーキテクチャ
に従う様々なＨＴＴＰ（ハイパーテキスト転送プロトコル）変体のうちのいずれか等、様
々なステートレスアプリケーション層プロトコルのうちのいずれかが使用され得る。結果
集合３５１０Ａ及び読み出し記述子３５１２Ａは、メモリバッファ３５３５に格納され得
る。

タイムライン３５９９上の時間ｔ３に、トランザクションの範囲内の第２読み出し要求
Ｒ２が、例えばエンドユーザの別の読み出し要求に応じて、ステートレスプロトコルを介
して格納グループ３５７５の第２データストアＤＳ２に対し提出され得る。前と同じよう
に、結果集合３５１０Ｂ及び読み出し記述子３５１２Ｂをクライアント側コンポーネント
に提供後、データストアＤＳ２は、Ｒ２またはクライアント側コンポーネントに関するい
かなるセッションステートメタデータも保持し得ない。描かれた実施形態において、格納
グループ３５７５のメンバーデータストアのいずれも、クライアント側コンポーネントに
てトランザクションが始まったという事実を認識しておらず、データストアにとって、各
読み出し要求は単純に、他のいかなる読み出しまたは書き込みにも無関係な独立要求とし
て映り得る。

時間ｔ４に、ペイロード３５２０ＡがＲ２の結果集合に依存し、最終的にデータストア
ＤＳ３に適用される（準備されている候補トランザクションが最終的にコミットされた場
合に）書き込みＷ１は、ローカルに、例えば描かれた実施形態においてクライアント側バ
ッファ３５３５内のメモリの一部に対し、実行され得る。Ｗ１が対象とする目標アドレス
を示すＷ１の書き込み記述子３５２２Ａも、バッファ内で作成され得る。例えば、いくつ
かの実施態様において、目標アドレスのハッシュシグネチャが、書き込み記述子３５２２
Ａとして使用され得る。時間ｔ５に、ペイロード３５２０ＢがＲ１の結果集合に依存し、
ＤＳ４を対象とする書き込みＷ２は、同様にクライアント側コンポーネントのローカルメ
モリ内で実行され得る。描かれた実施形態において、Ｗ２の第２書き込み記述子３５２２
Ｂもまた、クライアント側コンポーネントのメモリバッファ３５３５内で準備され得る。

時間ｔ６に、ＣＯＭＭＩＴ＿ＴＲＡＮＳＡＣＴＩＯＮ要求が、エンドユーザから受信さ
れ得る。従って、読み出し記述子３５１２Ａ、３５１２Ｂ、書き込み記述子３５２２Ａ、
３５２２Ｂ、及び書き込みペイロード３５２０Ａ、３５２０Ｂは全て、格納グループ３５
７５のＬＴＭに提出する候補トランザクションコミット要求３５２４内に包括され得る。
ＬＴＭの競合検出器３５６６は、読み出し記述子と、ＬＴＭのコミットレコードログの選
択部分集合のコンテンツとの分析に基づいて（部分集合は読み出し記述子に少なくとも部
分的に基づいて選択される）、候補トランザクションを受諾するか拒否するかを判定し得
る。後続の書き込みが結果集合を変更し、読み出し要求が再提出されたら変更された結果
集合が返されるため、Ｒ１またはＲ２は再現不可能であるという読み出し書き込み競合が
検出された場合（例えば読み出し記述子のうちの１つに含まれるＲＲＶＭを使用した判定
の結果）、候補トランザクションは拒否され得る。このようなシナリオで、クライアント
側コンポーネントは、描かれた実施形態において、読み出しＲ１、Ｒ２を再試行して新た
な結果集合と読み出し記述子とを取得し、ＬＴＭに提出する新たな候補トランザクション
コミット要求を生成し得る。このような再試行は、試みのうちの１つが成功するまで、ま
たは要求中のトランザクションを有するエンドユーザにトランザクションが失敗したと通
知されるまで、ある閾値回数実行され得る。

描かれた実施形態において、競合検出器３５６６がコミット要求３５２４を受諾する場
合、Ｗ１及びＷ２の書き込み記述子及びペイロードは、ＬＴＭのログに格納され得る。少
なくともいくつかの実施形態において、競合を検出するために、前に格納された書き込み
記述子により示される書き込みは、読み出し記述子により示される読み出しとの潜在的ま
たは実際の重複を検査される必要があり得る点で、書き込み記述子は、コミット要求に含
まれる読み出し記述子の論理的「双対」とみなされ得る。従って、所定の実施態様におい
て書き込みが書き込み記述子内に示される方法は、読み出しが読み出し記述子内に示され
る方法と、高いレベルで、論理的に適合する必要があり得る。ＬＴＭの書き込みアプライ
ヤ３５６８は、受諾決定に関して同期的または非同期的に、書き込みＷ１、Ｗ２をその対
象データストアＤＳ３、ＤＳ４に適用し得る。いくつかの実施形態において、書き込みア
プライヤもステートレスプロトコルを使用し、対象データストアＤＳ３、ＤＳ４は、書き
込みアプライヤ、または書き込みアプライヤにより発行される書き込み要求に関するいか
なるセッション関連メタデータも格納する必要はなくてよい。

従って、図３５に示される実施形態において、複数の書き込み（Ｗ１、Ｗ２等）は、い
かなるトランザクション関連メタデータが関与データストアにて生成または格納されるこ
となく、クライアント側コンポーネントにて準備される原子トランザクションの一環とし
てコミットされ得る。基礎データストアは複数書き込みトランザクションにネイティブに
対応し得ないにもかかわらず、及び／または基礎データストアはステートレス読み出し及
び書き込み動作にのみ対応し得るにもかかわらず、いくつかの実施形態において、このよ
うなクライアント側複数書き込みトランザクションが実施され得る。すなわち、メンバー
データストアは所定の読み出しの発生時間から所定の読み出しの結果に依存する書き込み
の発生時間までセッション情報（またはトランザクションステート情報）を保持しないに
もかかわらず、トランザクション原子性及び整合性が異種格納グループのユーザに提供さ
れ得る。

前述のように、ログベーストランザクションマネジャーは、コミット済み書き込みに対
応する書き込み記述子（３５２２Ａ、３５２２Ｂ等）を持続的変更ログ（前述の複製ＤＡ
Ｇを使用して実施されるログ等）に格納し得る。いくつかの実施形態において、コミット
済みトランザクションの読み出し記述子は先のコミット判定に不要であり得るにもかかわ
らず、読み出し記述子のコンテンツもトランザクションマネジャーにより保存され得る。
図３６は、少なくともいくつかの実施形態による、書き込み記述子と読み出し記述子とを
それぞれのログに格納する例示的トランザクションマネジャーを示す。示されるように、
ログベーストランザクションマネジャー３６０２は、書き込み記述子ログ３６１０と、読
み出し記述子ログ３６２０との２つの別個の持続的ログを使用する。別の実施形態におい
て、両種類の記述子は、共有持続的ログに格納され得る。読み出し記述子ログ３６１０の
コンテンツは、前述の楽観的並行処理制御手法の一環として読み出し書き込み競合に関し
て、及び／または同様に前述の論理制約管理に関して、検査を行うために使用され得る。
読み出し記述子ログ３６２０は、例えば異種格納グループの異なる部分にわたる読み出し
の分散を決定するために、例えば作業負荷分析に使用され得る。いくつかの実施形態にお
いて、コミット済み及び拒否済みトランザクション両方の読み出し記述子は、作業負荷分
析の目的で保持され得る。拒否済みトランザクションの読み出し記述子も、トランザクシ
ョン拒否の原因を特定するために分析され、例えばトランザクション拒否の頻度を低減す
るために任意の行動が取られるべきか否か（多数のトランザクション拒否を生じるほど頻
繁に読まれ頻繁に更新される特定のデータオブジェクトをパーティション分割する等）が
判定され得る。

図３７は、少なくともいくつかの実施形態による、読み出し要求に応じて読み出し記述
子が提供される、格納システムで行われ得る動作態様を示すフロー図である。構成要素３
７０１に示されるように、複数のデータストアを備える異種格納グループＨＳＧ１が確立
され得る。グループのメンバーデータストアは、異なるデータモデル及び／または読み出
しインターフェースに対応し得る。例えばグループは、リレーショナルデータベース、非
リレーショナルデータベース、インメモリデータベース、分散キャッシュインスタンス、
ファイルストアもしくはファイルシステム、ウェブサービスインターフェースを介してア
クセス可能な非構造化データオブジェクトを含む格納サービス等の１つまたは複数のイン
スタンスを含み得る。ＨＳＧ１を実施するサービスのクライアントは、グループにデータ
ストアを登録（追加）し得る、またはグループからデータストアをプログラムで削除し得
る。少なくともいくつかの実施形態において、グループＨＳＧ１の全てのメンバーデータ
ストアは、読み出し要求に対し、（読み出し結果集合に加えて）サービスにより指示され
る共通読み出し記述子形式に従った読み出し記述子で、応答するように求められ得る。

ＨＳＧ１のデータストアＤＳ１を対象とする特定読み出し要求Ｒ１が受信され得る（構
成要素３７０４）。Ｒ１は、その結果集合を決定するのに使用するフィルタ基準の指示を
含み得る。フィルタ基準の特質は、対象とするデータストアの種類によって異なり得る。
例えば、Ｒ１がＳＱＬ（構造化照会言語）またはＳＱＬ似のインターフェースに対応する
データベースである場合、フィルタ基準は、ＳＱＬのＳＥＬＥＣＴ句として表現され得る
。ＤＳ１がウェブサービスインターフェースを提供する格納サービスである場合、フィル
タ基準は、１つまたは複数のＵＲＬ（ユニバーサルリソースロケータ）として表現され得
る。キー値データストアでは、フィルタ基準は、データストア内の特定レコード位置／ア
ドレスに順に対応する一意キーの集合を含み得る。読み出し要求の結果集合が、データス
トアＤＳ１の前にコミット済みのステートを表すＤＳ１の１つまたは複数のステート遷移
インジケータ（ＳＴＩ）と共に、特定され得る（構成要素３７０７）。結果集合が生成さ
れた時にコミット済み書き込みの結果が可視状態であるように、いくつかの実施形態にお
いて、ＳＴＩは、データストアに対するコミット済み書き込みの適用に対応する論理タイ
ムスタンプを含み得る。一実施態様において、例えば、ＳＴＩは、データストアレベル変
更論理タイムスタンプ、テーブルレベル変更論理タイムスタンプ、またはレコードレベル
変更論理タイムスタンプ（例えば図３３に例示されるＤＭＴ、ＴＭＴ、及びＲＭＴ）、以
上のうちの１つまたは複数含み得る。いくつかの実施形態において、論理タイムスタンプ
の代わりに、または論理タイムスタンプに加えて、実時間ベースタイムスタンプが使用さ
れ得る。

Ｒ１に対応する読み出し記述子ＲＤ１が生成され得る（構成要素３７１０）。読み出し
記述子は、例えば、ＳＴＩ（複数可）と、少なくともいくつかの読み出し再現性検証メタ
データ（ＲＲＶＭ）を含み得る。ＲＲＶＭは、例えば、Ｒ１が再現可能な読み出しか否か
、すなわち、最初に結果集合が取得された後のある時点でＲ１が再発行されたとしても、
Ｒ１の結果集合は変化のないままであるか否かを判定するのに使用され得る。ＲＲＶＭの
形式及びコンテンツは、異なる実施形態において、例えば再現性を判定する読み出しの種
類、関与するデータストアの特質等に基づいて異なり得る。いくつかの実施形態において
、例えば、ＲＲＶＭは、Ｒ１結果集合のオブジェクトが取得された取得先位置の符号化、
例えば少なくとも１つのそのような位置のハッシュシグネチャ等を含み得る。範囲クエリ
、または図３１に関連して議論された読み出しに類似するクエリ等、より複雑なフィルタ
／選択基準を有する読み出しに関しては、クエリ述語またはＳＥＬＥＣＴ句の符号化がＲ
ＲＶＭに含まれ得る。そしていくつかの実施形態において、Ｒ１の結果が変化したか否か
を判定するために調査可能な式（または実行可能な関数）が、ＲＲＶＭ内に示され得る。
一実施態様において、読み出し要求Ｒ１全体は、例えば符号化または圧縮された形式で、
ＲＲＶＭに含まれ得る。いくつかの異なる種類のＲＲＶＭが生成され得る（例えばアドレ
スベースシグネチャ、あるいはクエリ述語符号化、あるいは関数）いくつかの実施形態に
おいて、ＲＲＶＭの種類は、読み出し記述子ＲＤ１内のフィールドにより示され得る。Ｒ
Ｄ１は、ＨＳＧ１のクライアント側コンポーネント（例えばＨＳＧ１が実施されるサービ
スのフロントエンド要求ハンドラノード、またはサービスのライブラリコンポーネント）
に送信され得る。ＲＤ１は、いくつかの実施形態においてトランザクションコミット要求
を構成するために、または作業負荷分析等の他の目的で、クライアント側コンポーネント
にて使用され得る。

図３８は、少なくともいくつかの実施形態による、候補トランザクションコミット要求
がクライアント側コンポーネントにて生成される、格納サービスで行われ得る動作態様を
示すフロー図である。クライアント側コンポーネントには、例えば、格納サービスのフロ
ントエンド要求ハンドラノードにて、または格納サービスにより顧客へ提供されるライブ
ラリ内で、実行される１つまたは複数のプロセスが含まれ得る。構成要素３８０１に示さ
れるように、候補トランザクションを準備するという指示、例えばサービスのアプリケー
ションプログラミングインターフェース（ＡＰＩ）を介して受信されるＢＥＧＩＮ＿ＴＲ
ＡＮＳＡＣＴＩＯＮ要求等が、エンドユーザから異種格納グループＨＳＧ１のクライアン
ト側コンポーネントにて受信され得る。いくつかの実施態様において、ＢＥＧＩＮ＿ＴＲ
ＡＮＳＡＣＴＩＯＮ要求からＣＯＭＭＩＴ＿ＴＲＡＮＳＡＣＴＩＯＮ要求（またはＥＮＤ
＿ＴＲＡＮＳＡＣＴＩＯＮ要求）までの間にクライアント側コンポーネントにて行われる
動作集合は、例えば当該間隔内に発行された読み出しの再現性は、トランザクションの書
き込みがコミットされる前に検証される必要があり得るという意味で、トランザクション
の範囲内であるとみなされ得る。

１つまたは複数の読み出し要求が、例えばエンドユーザによる読み出しＡＰＩ呼び出し
に応じて、クライアント側コンポーネントにより、トランザクションの範囲内で、格納グ
ループＨＳＧ１のデータストアに送られ得る。読み出しのうちの少なくともいくつかは、
描かれた実施形態においてステートレスプロトコルを使用して実行され得る。すなわち、
読み出しが対象とするデータストアは、クライアントセッション情報を維持する、または
読み出し要求に関するその他の持続的メタデータを保持する必要はなくてよい。例えば、
データストアは、読み出しの結果が書き込み動作またはトランザクションに使用される予
定であることを示す情報を有し得ない。このような読み出し要求それぞれに応じて、対象
データストアにより、読み出し集合と読み出し記述子とが提供され得る（構成要素３８０
４）。所定の読み出し記述子は、読み出し集合が取得された時点でのデータストアのコミ
ット済みステート（またはデータベースインスタンスの場合はテーブルもしくはレコード
といったデータストアの部分集合のコミット済みステート）を示す１つまたは複数のステ
ート遷移インジケータ（ＳＴＩ）を含み得る。さらに、読み出し記述子は、読み出し再現
性検証メタデータ（ＲＲＶＭ）の少なくとも１つの要素、例えば、読み出しが再提出され
たら読み出しの結果は変わるか否かを検査するのに使用可能な読み出しクエリもしくは述
語の符号化等の情報、関数、または読み出し対象位置を表すハッシュシグネチャも含み得
る。読み出し結果集合及び読み出し記述子は、クライアント側コンポーネントによりアク
セス可能なメモリバッファに、例えばフロントエンド要求ハンドラノードにおける、また
はクライアント所有コンピューティングデバイスにおけるローカルメモリに、格納され得
る（構成要素３８０７）。

書き込みペイロードが読み出し結果集合のうちの少なくとも１つに依存し得る１つまた
は複数の書き込みは、ローカルメモリを使用して実行され得る。例えば書き込みペイロー
ドは、クライアント側コンポーネントにより書き込み可能なバッファに格納され得る。少
なくとも一実施形態において、トランザクションの範囲内の書き込みの結果として最終的
に書き込まれるＨＳＧ１のデータストアにおける対象位置もまた、読み出し結果集合に依
存し得る。いくつかの実施形態において、書き込み記述子（例えば書き込みの対象ＨＳＧ
１位置に基づくハッシュシグネチャ）も、書き込みのうちの少なくともいくつかのために
、クライアント側メモリバッファに格納され得る（構成要素３８１０）。いくつかの実施
形態において、書き込み記述子は必要でなくてよいことに留意されたい。例えば、書き込
みペイロードが書き込み位置の指示を含み、そして読み出し書き込み競合検出を行うには
、当該位置で十分であり得る。トランザクションの全ての読み出し及び書き込みがローカ
ルで実行された後、トランザクションのローカル動作が完了したことの開示（ＣＯＭＭＩ
Ｔ＿ＴＲＡＮＳＡＣＴＩＯＮまたはＥＮＤ＿ＴＲＡＮＳＡＣＴＩＯＮ要求等）が、クライ
アント側コンポーネントにて受信され得る。（構成要素３８１３）

描かれた実施形態において、読み出し記述子と、書き込みペイロードと、書き込み記述
子とを含む候補トランザクションのコミット要求が、クライアント側コンポーネントにて
生成され得る（構成要素３８１６）。いくつかの実施形態において、トランザクションの
範囲内に含まれる１つまたは複数の書き込みは、必ずしもトランザクション内に指示され
る読み出しの結果に依存するとは限らないことに留意されたい。例えば候補トランザクシ
ョンがコミットのために受諾される前に前述の類の論理制約（例えば重複排除制約または
コミット順序付け制約）が検査されるいくつかの実施形態において、論理制約のために追
加データシグネチャが生成され、コミット要求内に組み込まれ得る。ＨＳＧ１のためにコ
ミット判定を行う責務を担うトランザクションマネジャー、例えば前述の類の楽観的並行
処理制御機構を使用するように構成されたログベーストランザクションマネジャー等に対
し、コミット要求は送信され得る（構成要素３８１９）。候補トランザクションをコミッ
トするか拒否するかに関する判定は、前述のように例えば読み出し書き込み競合を特定す
るための読み出し記述子と選択されたログの部分集合とを使用して、トランザクションマ
ネジャーにて行われ得る（構成要素３８２２）。候補トランザクションを受諾するという
決定がなされた場合（例えば使用されている並行処理制御プロトコルに従って読み出し書
き込み競合が検出されない場合）、新たなコミットレコードがトランザクションマネジャ
ーのログに追加され得る。少なくともいくつかの実施形態において、ログは、前述のよう
に複製有向非巡回グラフ（ＤＡＧ）を使用して実施され得る。

拡張縮小性のための複数ログベーストランザクションマネジャーの使用
いくつかの実施形態において、単一のログベーストランザクションマネジャー（ＬＴＭ
）は、前述の類の１つまたは複数のデータストアを含む格納グループにトランザクション
が要求されるレートに、対応不可能であり得る。例えば、少なくともいくつかの実施態様
において、要求コミットまたはトランザクションのレートが増加すると、コミットレコー
ドを持続的ログに挿入するのに利用可能なＣＰＵリソース（例えば持続的ログに使用され
る複製ＤＡＧの所定のノードが実施されるホストにおける）が障壁となり得る。いくつか
の事例において、ＣＰＵに加えて、またはＣＰＵの代わりに、ログレコードに使用される
格納デバイス、及び／またはログへのネットワーク経路もしくはログからのネットワーク
経路が、障壁となり得る。いずれかの単一のこのような障壁、またはこのような障壁の組
み合わせは、結果的に所定のＬＴＭにより対応可能なトランザクションスループットを抑
制し得る。所定のＬＴＭによる増大スループットに対応するためにより速い個別サーバ、
より速い格納デバイス、またはより速いネットワークコンポーネントを配備することは、
例えば費用の理由から、可用性の理由から、及び／または単純に最も速く利用可能なコン
ポーネントでもいくつかの作業負荷を処理不可能であり得るため、最終的には非実用的と
なり得る。

従って、少なくともいくつかの実施形態において、楽観的ログベース並行処理制御が使
用される格納グループの１つまたは複数のデータストアのデータは、論理的にパーティシ
ョンに分割され、パーティションレベルの競合検出のために、異なるパーティションにそ
れぞれのＬＴＭが割り当てられる。例えば、テーブルＴ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５の集
合を有するデータベースの場合、１つのＬＴＭがＴ１、Ｔ２、Ｔ３を有するパーティショ
ンに割り当てられ、別のＬＴＭがＴ４、Ｔ５を有するパーティションに割り当てられ得る
。このようなＬＴＭは各自、１つの特定パーティションのコミットレコードが格納される
自身の持続的ログに関して、ローカル競合検出を実行可能であり得る。読み出し及び書き
込みが全て単一パーティションを対象とするトランザクションのコミット判定は、単一Ｌ
ＴＭにより前述と同様の方法で対処され得る。しかしながら、いくつかのトランザクショ
ンは、複数のパーティションからの読み出し（及び／または複数のパーティションへの書
き込み）を伴い得る。このようなトランザクションは、本明細書において複数パーティシ
ョントランザクションと称され得る。複数パーティショントランザクションに対応する実
施形態において、クライアント側コンポーネント（ログベーストランザクション管理が実
施されている格納サービスのフロントエンド要求ハンドラにおけるプロセス、またはクラ
イアント所有デバイスにインストールするためにそのようなサービスにより提供されるラ
イブラリのコンポーネント等）は、関与するパーティションのローカル競合を検出するよ
うに割り当てられたそれぞれのＬＴＭと一緒に、後述のように複数パーティショントラン
ザクションのコミットに参加する必要があり得る。

（ａ）格納グループのパーティションＰ１を対象とし、かつＰ１に対する前の読み出し
Ｒ１の結果に依存する書き込みＷ１、及び（ｂ）パーティションＰ２を対象とし、かつＰ
２に対する前の読み出しＲ２の結果に依存する書き込みＷ２、以上を含む単純な例示的複
数パーティショントランザクションＭＰＴ１を検討する。当実施例において、ログベース
トランザクションマネジャーＬＴＭ１、ＬＴＭ２はそれぞれ、Ｐ１、Ｐ２に関する読み出
し書き込み競合を検出するように指示される。一実施形態において、コミット要求ＣＲ１
（Ｗ１の書き込み記述子とＲ１の読み出し記述子ＲＤ１とを含む）は、クライアント側コ
ンポーネントＣＳＣ１によりＬＴＭ１に対し送信され得る。少なくともいくつかの実施形
態において、読み出し記述子ＲＤ１は、例えば図３２〜図３８に関して前述された読み出
し再現性検証メタデータ及びステート遷移インジケータの類を含み得る。ＲＤ１とコミッ
ト済み書き込みのＬＴＭ１のログとを使用して、ＬＴＭ１は、ＣＲ１がローカルで検出可
能な競合、すなわちＬＴＭ１にて入手可能な情報を使用して特定可能な競合を有するか否
かを判定し得る。ＬＴＭ１のログとＲＤ１とを使用してＬＴＭ１により競合が見つからな
かった場合、ＬＴＭ１は、ＣＲ１を条件付きでコミット可能であると指定し、条件付きコ
ミットレコードをＬＴＭ１のログに挿入し得る。Ｗ１が条件付きでコミット可能であると
指定されたことが、クライアント側コンポーネントＣＳＣ１に通知され得る。ＭＰＴ１の
第２書き込みＷ２に関して、ＣＳＣ１は同様に、第２コミット要求ＣＲ２をＬＴＭ２へ送
信し得る。Ｗ２もローカルでコミット可能であること（例えばＷ２に対し条件付きコミッ
トレコードがＬＴＭ２のログに格納されたこと）がＬＴＭ２によりＣＳＣ１に通知された
場合、ＣＳＣ１は、ＭＰＴ１が全体的に、すなわち無条件でコミット可能であると判定し
得る。ＣＳＣ１はそれから、ＭＰＴＲ１の無条件コミットレコードを、複数パーティショ
ンコミット判定レポジトリ（ＭＣＤＲ）に、例えばＣＲ１、ＣＲ２に対応する条件付きコ
ミットレコード内のポインタが格納された位置に、挿入し得る。コミット済み書き込みを
Ｐ１に伝播するように割り当てられた書き込みアプライヤＷＡ１は、Ｗ１は条件付きでコ
ミット可能であると判定されたことを示す、ＣＲ１に応じて生成されたコミットレコード
を調べ得る。ＷＡ１は、Ｗ１が条件付きでコミットされたと判定すると、対応する無条件
コミットレコードをＭＣＤＲ内で検索し得る。いくつかの実施形態において、このような
無条件コミットレコードが見つかった場合（例えば後述のようなタイムアウト内に）、Ｗ
１はＰ１に伝播され得る。同様に、Ｐ２に対し書き込みを伝播するように指示された書き
込みアプライヤ（ＷＡ１または別の書き込みアプライヤＷＡ２）は、ＣＲ２及びＷ２に対
応する条件付きコミットレコードを調べ、ＭＰＴ１の無条件コミットレコードを探し、Ｐ
２に対しＷ２を伝播し得る。書き込みアプライヤ（複数可）により無条件コミットレコー
ドが見つからない場合、少なくともいくつかの実施形態において、書き込みは破棄され得
る（例えばＷ１、Ｗ２のどちらもそれぞれの目的パーティションに伝播され得ない）。

図３９は、少なくともいくつかの実施形態による、格納グループの異なるパーティショ
ンに対しそれぞれのログベーストランザクションマネジャー（ＬＴＭ）が確立され得る例
示的システム環境を示す。示されるように、システム３９００において、パーティション
分割された格納グループ３９０２は、３つの論理パーティション（ＬＰ）のＬＰ３９１０
Ａ、３９１０Ｂ、３８１９Ｃを備え得る。一般に、前述の類の１つまたは複数のデータス
トア（例えば、リレーショナルデータベースインスタンス、非リレーショナルデータベー
スインスタンス、格納サービスオブジェクト、インメモリデータベースインスタンス、分
散キャッシュインスタンス、ファイルシステム等）を備える格納グループは、後述のよう
に、格納グループの目標性能要件等の様々な要素に応じて、様々な実施形態において任意
の所望数のパーティションに論理的に細分化され得る。いくつかの実施形態において、論
理パーティションは、それぞれの物理格納デバイスにも格納され得る。このような論理パ
ーティションの物理的分離は要件ではあり得ないが、例えば、パーティションＰ１内のテ
ーブルＴ１はディスクＤ１上に格納され、パーティションＰ２内のテーブルＴ２は別のデ
ィスクＤ２上に格納され得る等する。各論理パーティションは、対応ＬＴＭと、描かれた
実施例において構成される対応書き込みアプライヤ（ＷＡ）とを有するが、ＬＴＭとＷＡ
間のこのような１対１のマッピングは、少なくともいくつかの実施形態において必要でな
くてよい。システム３９００において、ＬＰ３９１０Ａは持続的ログ３９１８Ａを含むＬ
ＴＭ３９１５Ａを有し、ＬＰ３９１０Ｂは持続的ログ３９１８Ｂを含むＬＴＭ３９１５Ｂ
を有し、ＬＰ３９１０Ｃは持続的ログ３９１８Ｃを含むＬＴＭ３９１５Ｃを有する。いく
つかの実施形態において、持続的ログ３９１８はそれぞれ、前述の複製ＤＡＧと同様の複
製ＤＡＧを使用して実施され得る。ＷＡ３９２０Ａは、ログ３９１８Ａ内のコミットレコ
ードを調べ、そこに指示される書き込みのうちの少なくともいくつかをＬＰ３９１０Ａに
伝播するように構成され、同様に、ＷＡ３９２０Ｂは、ログ３９１８Ｂのコミットレコー
ドを調べ、少なくともいくつかの書き込みをＬＰ３９１０Ｂに伝播するように構成され、
そしてＷＡ３９２０Ｃは、ログ３９１８Ｃのコミットレコードを調べ、少なくともいくつ
かの書き込みをＬＰ３９１０Ｃに伝播するように構成される。

矢印１ａ、１ｂで示されるように、格納グループ３９０２のクライアント側コンポーネ
ント３９３０は、複数パーティショントランザクションＭＰＴ１のそれぞれのコミット要
求Ｃ‐Ｒｅｑ１、Ｃ‐Ｒｅｑ２を、ＬＴＭ３９１５Ａ、ＬＴＭ３９１５Ｃに対しそれぞれ
提出し得る。Ｃ‐Ｒｅｑ１は、ＬＰ３９１０Ａを対象とする前の読み出しＲ１に依存する
少なくとも１つの書き込みＷ１を含み、一方、Ｃ‐Ｒｅｑ２は、ＬＰ３９１０Ｃを対象と
する前の読み出しＲ２に依存する少なくとも１つの書き込みＷ２を含み得る。（ａ）コミ
ット要求に含まれる読み出し記述子と（ｂ）ログ３９１８Ａ、３９１８Ｃとを使用して、
ＬＴＭ３９１５Ａ、３９１５Ｃは、書き込みＷ１、Ｗ２が条件付きでコミット可能である
か否か（例えばそれぞれのローカルログとそれぞれの読み出し記述子とを使用して、書き
込みとのいずれかの読み出し書き込み競合が検出され得るか否か）をそれぞれ判定し得る
。描かれた実施形態において、複数パーティショントランザクションのＷ１またはＷ２等
の書き込みは、所定のＬＴＭにより条件付きで（無条件ではなく）コミット可能であると
みなされ得る。なぜなら、ＬＴＭは、複数パーティショントランザクション全体としての
コミットに関して判定を行うのに十分な情報を有さなくてよいからである。実際に、少な
くともいくつかの実施態様において、ＬＴＭは、複数パーティショントランザクションの
他の書き込みを認識すらしなくてよい。ローカルで入手可能な情報を使用して競合が全く
検出されない場合、例えば、Ｃ‐Ｒｅｑ１に対応する条件付きコミットレコードＣｏｎｄ
‐Ｃ‐Ｒｅｃ１がＬＴＭ３９１０Ａによりログ３９１８Ｂに格納され、Ｃ‐Ｒｅｑ２に対
応する条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ２がＬＴＭ３９１０Ｃによりログ
３９１８Ｃに格納され得る。さらに、少なくともいくつかの実施形態において、要求書き
込みが条件付きでコミットされたことを示すそれぞれの応答が、それぞれのＬＴＭ３９１
５Ａ、３９１５Ｂにより、クライアント側コンポーネント３９３０に提供され得る。従っ
て、矢印２ａで示されるように、応答Ｃ‐Ｒｅｓｐ１がＬＴＭ３９１５Ａによりクライア
ント側コンポーネント３９３０に提供され、そして矢印２ｂで示されるように、応答Ｃ‐
Ｒｅｓｐ１がＬＴＭ３９１５Ｂにより提供され得る。コミット要求Ｃ‐Ｒｅｓｐ１、Ｃ‐
Ｒｅｓｐ２は、少なくともいくつかの実施態様において並行して送信され、同様にコミッ
ト要求の処理もまた並行して行われ得ることに留意されたい。少なくともいくつかの実施
形態において、複数パーティショントランザクションの異なるコミット要求は任意の順序
でまたは並行して送信され、対応する条件付きコミットレコードはそれぞれのＬＴＭによ
り任意の順序でまたは並行して格納され、そしてコミット要求に対する応答はクライアン
ト側コンポーネントにより任意の順序でまたは並行して受信され得る。

描かれた実施形態において、書き込みＷ１、Ｗ２は両方とも条件付きでコミット可能で
あるという確認に応じて、クライアント側コンポーネント３９３０は、無条件コミットレ
コードＵｎｃｏｎｄ‐Ｃ‐Ｒｅｃを、複数パーティションコミット判定レポジトリ（ＭＣ
ＤＲ）３９４０Ａに格納し得る（矢印３）。少なくともいくつかの実施形態において、ク
ライアント側コンポーネントは通常、ＭＰＴ１等の所定の複数パーティショントランザク
ションの全ての書き込みが条件付きでコミット可能であると指定されたことを確認後、こ
のような無条件コミットレコードを格納し得る。描かれた実施例において、２つのＭＣＤ
Ｒ３９４０Ａ、３９４０Ｂが、格納グループ３９０２に対し確立されている。後述のよう
に例えば複数パーティショントランザクション要求の見込みまたは目標スループットに基
づいて、一般に様々な実施形態において任意の所望数のＭＣＤＲが確立され得る。複数の
ＭＣＤＲが確立された実施形態において、所定の無条件コミットレコードにどのＭＣＤＲ
を使用するかに関する決定が、例えばトランザクションに関与する特定のパーティション
に基づいて、クライアント側コンポーネントにより実施される負荷分散基準に基づいて等
、様々な要素に基づいて行われ得る。少なくともいくつかの実施形態において、無条件コ
ミットレコードを格納する位置の開示が、クライアント側コンポーネントによりＬＴＭへ
送信されるコミット要求内に含まれ、かつログ３９１８に格納されている条件付きコミッ
トレコードにも含まれ得る。いくつかの実施態様において、ＭＣＤＲは、持続的ログ（例
えばログ３９１８と同様）のインスタンスとして実施され得る。

条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ１がログ３９１８Ａに格納された後の
ある時点に、書き込みアプライヤ３９２０Ａが当該レコードを調べ得る（矢印４ａにより
提示）。いくつかの事例において、このような調査は同期的であり（例えば条件付きコミ
ットレコードはログ３９１８に書き込まれるとすぐに、格納グループのデータストアにコ
ミット済み書き込みをプッシュする責務を担う書き込みアプライヤにより読み出され得る
）、一方、他の事例において、書き込みアプライヤは、条件付きコミット判定とは非同期
的にコミットレコードを調べ得る。Ｃｏｎｄ‐Ｃ‐Ｒｅｃ１を調べた際、ＷＡ３９２０Ａ
は、コミットが条件付きであると判断し、よって対応する無条件コミットレコードの検出
を試み得る。少なくともいくつかの実施形態において、無条件コミットレコードＵｎｃｏ
ｎｄ‐Ｃ‐Ｒｅｃの位置の開示が、条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ１に
含まれ得る。別の実施形態において、書き込みアプライヤは、例えばデータベース内の複
数パーティショントランザクションの識別子を検索することにより、他の情報源から無条
件コミットレコードの位置を学び得る。矢印５ａで示されるように、描かれた実施形態に
おいて、ＷＡ３９２０Ａは、Ｕｎｃｏｎｄ‐Ｃ‐ＲｅｃをＭＣＤＲ３９４０Ａ内に発見し
、よって条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ１内に示される書き込みを、そ
の対象書き込み先に実際に適用することを確定し得る。矢印６ａに示されるように、書き
込みＷ１は従って、パーティションＬＰ３９１０Ａに伝播され得る。描かれた実施形態に
おいて、書き込みアプライヤ３９２０Ｃは、ＷＡ３９０２０Ａと同様の手続きを行い得る
。例えば書き込みアプライヤ３９２０Ｃは、条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒ
ｅｃ２を同期的または非同期的に調べ（矢印４ｂ）、対応する無条件コミットレコードが
格納されていると見込まれる位置を特定し、Ｕｎｃｏｎｄ‐Ｃ‐Ｒｅｃを検索し得る（矢
印５ｂ）。Ｗ２が属する複数パーティショントランザクションが無条件にコミットされて
いることを確認した後、ＷＡ３９２０Ｃは従って、Ｗ２をその目的書き込み先であるＬＰ
３９１０Ｃに伝播し得る。

さらに詳しく後述されるように、少なくともいくつかの実施形態においてタイムアウト
機構が実施され、よって無条件コミットレコードＵｎｃｏｎｄ‐Ｃ‐Ｒｅｃがある時間間
隔内に書き込まれたことをＷＡ３９２０のどちらかが確認不可能な場合には、Ｗ１または
Ｗ２等の対応書き込み（複数可）の伝播は破棄され得る。いくつかの実施形態において、
複数パーティショントランザクションの書き込みがコミット不可能となる競合をＬＴＭ３
９１５が発見した場合、クライアント側コンポーネント３９３０は、無条件コミットレコ
ードの代わりに無条件アボートレコードをＭＣＤＲ３９４０Ａに格納し得る。ＬＴＭ３９
１５ＡはＷ１を条件付きでコミット可能であると指定するが、ＬＴＭ３９１５Ｂは競合に
基づきＷ２をコミット不可能であると指定するシナリオを検討する。後述のシナリオにお
いて、Ｗ１が属する複数パーティショントランザクションの無条件コミットレコードを見
つけようとＷＡ３９２０Ａが試みる場合、ＷＡ３９２０Ａは、代わりに複数パーティショ
ントランザクションが破棄／アボートされたことを発見し、従って書き込みＷ１の伝播を
破棄し得る。少なくともいくつかの実施形態において、複数パーティショントランザクシ
ョンを破棄／アボートする決定がなされた場合、ログ３９１８内の条件付きコミットレコ
ードは、変更（例えばアボートを示すように）または削除され得る。同様に、いくつかの
実施形態において、複数パーティショントランザクションを無条件にコミットする決定が
なされた場合、ログ３９１８内の対応する条件付きコミットレコードは、親複数パーティ
ショントランザクションが無条件にコミットされたことを示すように変更され得る。コミ
ット判定のための競合検出動作のうちの少なくともいくつかは、ログ３９１８のコンテン
ツに基づいて行われ得るため、このような実施形態において、コミットの条件制限の不明
確さを解消することは、後続のコミット判定を行うのに役立ち得る。

格納グループの構成に含めるＬＴＭ、ＷＡ、及びＭＣＤＲの数に関する決定は、異なる
実施形態において、様々な要素に基づき得る。図４０は、少なくともいくつかの実施形態
による、格納グループの性能ベースのトランザクション管理構成の実施例を示す。示され
るように、分散格納サービス構成マネジャー４０８０は、２つの格納グループのそれぞれ
の構成要求４０５０Ａ、４０５０Ｂを受信し得る。構成要求４０５０Ａは、クライアント
が、１００００の目標トランザクションスループットレートすなわちＴＰＳ（毎秒トラン
ザクション）４００５Ａと、５０ミリ秒の目標書き込みレイテンシ４０１０Ａ（例えば書
き込み要求と対応書き込みの対象データストアへの伝播との間の遅延が平均５０ミリ秒を
超えない）とを有することを示し得る。例えば含まれるデータストアの種類、ストアの最
大サイズ等を示す、クライアントの格納グループのデータストアリスト４０２０Ａ（例え
ばデータストアＤＳ１、ＤＳ２）も提供され得る。同様に、構成要求４０５０Ｂは、クラ
イアントのデータストアリスト４０２０Ｂ（例えばデータストアＤＳ３、ＤＳ４、ＤＳ５
）と、目標ＴＰＳ４００５Ｂ（例えば２００００）と、目標書き込みレイテンシ４０１０
Ｂ（例えば２００ミリ秒）とを示し得る。

構成要求のコンテンツに少なくとも部分的に基づいて、構成マネジャー４０８０（分散
格納サービスの管理／制御プレーンのコンポーネントであり得る）は、それぞれの要求４
０５０に対し、候補トランザクション管理構成を生成し得る。描かれた実施例において、
構成要求４０５０Ａに応じて生成されたトランザクション管理構成４０６０Ａは、２つの
ＬＴＭ４０２５Ａ、４０２５Ｂと、４つの書き込みアプライヤ４０２７Ａ〜４０２７Ｄと
、１つのＭＣＤＲ４０２９Ａとを含み得る。いくつかの実施形態において、提案されるト
ランザクション管理構成のＬＴＭの数は、クライアントの格納グループの提示または推薦
パーティション分割に対応し得る（例えば論理パーティションごとに１つのＬＴＭが設定
され得る）。このような実施形態において、クライアントが提案パーティション分割を了
承する場合、クライアントまたは格納サービスのどちらかが、好適なパーティション分割
プランを決定し得る。別の実施形態において、クライアントは、例えばクライアントの目
標ＴＰＳに少なくとも部分的に基づいて、その格納グループをパーティション分割し、パ
ーティション分割プランを構成要求の一部として構成マネジャーに提供するように求めら
れ得る。

図４０の描かれた実施例において、所定の構成に選ばれるＬＴＭの数は、目標ＴＰＳに
比例する。従って、要求４０５０Ａに示される目標１００００ＴＰＳに対して、構成４０
６０Ａ内に２つのＬＴＭが提示され、そして要求４０５０Ｂに示される目標２００００Ｔ
ＰＳに対して、４つのＬＴＭ（４０２５Ｋ〜４０２５Ｎ）が推薦される。推薦される書き
込みアプライヤの数は、目標書き込みレイテンシに基づき、より小さい目標レイテンシに
はより多くのアプライヤが推薦される。従って、５０ミリ秒の目標書き込みレイテンシの
ために４つの書き込みアプライヤが構成４０６０Ａに含まれ、一方要求４０５０Ｂに示さ
れる２００ミリ秒の書き込みレイテンシのためには、２つの書き込みアプライヤ４０２７
Ｋ、４０２７Ｌのみが構成４０６０Ｂに含まれる。ＭＣＤＲの数もまた、異なる実施形態
において、目標ＴＰＳ、複数パーティショントランザクションの目標分数等、様々な要素
に基づいて選択され得る。示される実施例において、要求４０５０Ａに示されるパラメー
タに対して、２つのＭＣＤＲ４０２９Ｋ、４０２９Ｌが推薦される。

構成要求４０５０に含まれるパラメータの種類、及びパラメータとトランザクション管
理構成４０６０の推薦コンポーネント数との関係は、異なる実施形態において図４０に示
されるものとは異なり得る。例えば、いくつかの実施形態において、クライアントは、複
数パーティショントランザクション対単一パーティショントランザクションの目標割合も
、自身の構成要求内に示す必要があり、このような割合は、構成マネジャーによりＭＣＤ
Ｒの推薦数を決定するのに使用され得る。少なくともいくつかの実施形態において、構成
マネジャーがクライアントに対し推薦構成を提供した後、クライアントは、構成マネジャ
ーがＬＴＭ、ＷＡ、及び／またはＭＣＤＲを配備／インスタンス化する前に、推薦内容を
承認する必要があり得る。いくつかの実施形態において、格納グループに設定されるＭＣ
ＤＲ、ＬＴＭ、及び／またはＷＡの数は、例えばトランザクション処理上の中断を要する
ことなく、作業負荷が変化するとともに動的に調整され得る。

少なくともいくつかの実施形態において、所定のデータストアは、ログベーストランザ
クション管理のために、いくつかの論理パーティションに分割され得る。すなわち、単一
のデータストアの部分集合のために、競合検出及び条件付きコミット判定を管理するよう
に、ＬＴＭが確立され得る。図４１は、少なくともいくつかの実施形態による、所定のデ
ータストアのために複数のログベーストランザクションマネジャーが確立され得る例示的
構成を示す。示されるように、描かれたシナリオにおいて、格納グループ４１０２は、デ
ータストア４１１０Ａ（例えば非リレーショナルデータベースのインスタンスを備え得る
）と、データストア４１１０Ｂ（例えばインメモリデータベースのインスタンス）と、デ
ータストア４１１０Ｃ（例えば非構造化オブジェクトへインターフェース接続するウェブ
サービスを提供する格納サービスのオブジェクトの集合）とを含み得る。

描かれた実施形態において、格納グループ４１０２は、６つの論理パーティション（Ｌ
Ｐ）４１２０Ａ〜４１２０Ｆに分割されている。データストア４１１０ＡはＬＰ４１２０
Ａ、４１２０Ｂを有し、データストア４１１０ＢはＬＰ４１２０Ｃを有し、そしてデータ
ストア４１２０ＣはＬＰ４１２０Ｄ、４１２０Ｅ、４１２０Ｆを有する。各論理パーティ
ション４１２０には、対応ＬＴＭ４１２５が確立され、例えばＬＰ４１２０ＡはＬＴＭ４
１２５Ａを有し、ＬＰ４１２０ＢはＬＴＭ４１２５Ｂを有する等する。予想データ集合サ
イズはパーティションの数を決定する際の要素であり得るが、少なくともいくつかの実施
態様において、所定のデータストアのためにインスタンス化される論理パーティション及
び／またはＬＴＭの数は、データストア内に予想されるデータ量に必ずしも比例するとは
限らない。様々な実施形態においてパーティション分割を決定するために、例えば、様々
な種類のトランザクション（例えば単一パーティション、複数パーティション、またはデ
ータストア横断トランザクション）の予想レート、ＬＴＭ４１２５に使用されるデータス
トア及び／またはサーバのネイティブ性能（例えばどれだけ速く書き込みがＬＴＭログに
適用され得るか）、データストアに対する可用性またはデータ耐久性目標、クライアント
予算目標、異なるデータストアに関する価格設定ポリシー差異等、他の要素も使用され得
る。

少なくともいくつかの実施形態において、いくつかのＬＴＭ４１２５は、特定の種類の
トランザクションを実施するために協働する必要があり得る。例えば、ＬＰ４１２０Ａが
テーブルＴ１を備え、そしてＬＰ４１２０Ｂが別のテーブルＴ２を備えるシナリオを検討
する。複数パーティショントランザクションのコミット要求ＣＲ１が、クライアント側コ
ンポーネントによりＬＴＭ４１２５Ａに送られる。ＣＲ１はＴ１に対する読み出しＲ１の
読み出し記述子を示し、かつＲ１の結果に基づく２つの書き込み、Ｔ１に対する書き込み
Ｗ１とＴ２に対する書き込みＷ２とを含む。このようなシナリオにおいて、ＬＴＭ４１２
５ＡがそのローカルログとＲ１の読み出し記述子とに基づいていかなる競合も検出しない
場合、Ｗ１とＷ２の両方ともコミット可能と指定され得る。しかしながら、Ｗ２はＴ１を
備えるパーティションとは異なるパーティションを対象とする。このようなシナリオにお
いて、少なくともいくつかの実施形態において、それぞれの条件付きコミットレコードが
、ＬＴＭ４１２０ＡとＬＴＭ４１２０Ｂの両方のログに書き込まれ得る（例えばＬＴＭ４
１２０ＡからＬＴＭ４１２０Ｂへ送られる要求の結果）。いくつかの実施形態において、
格納グループの異なるデータストアのために確立されたＬＴＭ間で同様の協働が実施され
得る。例えば、Ｗ２がＬＰ４１２０Ｄを対象とする場合、ＬＴＭ４１２０Ａは、Ｗ２の条
件付きコミットを含むための要求をＬＴＭ４１２０Ｄへ送信し得る。

前述のように、いくつかの実施態様において、複数パーティションコミット判定レポジ
トリ（ＭＣＤＲ）は、ＬＴＭにより使用される持続的ログと同様の持続的ログを使用して
実施され得る。従って、このような一実施態様において、ＬＴＭに使用されるログが複製
ＤＡＧを使用して実施され得るように、所定のＭＣＤＲは、図１に示される複製ＤＡＧと
同様の複製ＤＡＧを使用して実施され得る。図４２は、少なくともいくつかの実施形態に
よる、格納グループのマスタパーティションに対し確立されるログベーストランザクショ
ンマネジャーのログと共に、複数パーティションコミット判定レポジトリが共同配置され
る例示的構成を示す。描かれた実施形態において、格納グループ４２０２は、マスタ論理
パーティション４２１０Ａと、非マスタ論理パーティション４２１０Ｂ、４２１０Ｃとに
細分化されている。パーティションのうちの１つをマスタまたは主要に指定することは、
異なる実施形態において、例えば、パーティションに格納されたデータの相対的重要度（
格納グループ４２０２が確立されたクライアントの観点から）、目標性能、コンテンツが
パーティションに含まれるデータストアの可用性またはデータ耐久性目標、及び／または
他の要素に基づき得る。

描かれた実施形態において、論理パーティション４２１０それぞれのために、それぞれ
のＬＴＭ４２１５が構成され得る。描かれた実施形態において、マスタＬＰ４２１０Ａの
ためにインスタンス化されたＬＴＭ４２１５ＡはマスタＬＴＭに指定され、一方、４２１
５Ｂ、４２１５Ｃ等の残りのＬＴＭは非マスタＬＴＭに指定され得る。少なくとも一実施
態様において、マスタＬＴＭ４２１５Ａは、非マスタＬＴＭのために配備されるサーバよ
り大きな演算、格納、メモリ、及び／またはネットワーク能力を有する１つまたは複数の
サーバを使用して実施され得るが、リソース能力におけるこのような非対称は要件でなく
てよい。描かれた実施形態において、マスタＬＴＭのログ４２１８Ａは、格納グループ４
２０２に使用されるＭＣＤＲ４２４０と共に、共同配置され得る（例えば演算、ネットワ
ーク、格納、及び／またはメモリのために同じサーバのリソースを共有し得る）。ＭＣＤ
Ｒ４２４０及び／またはログ４２１８Ａはそれぞれ、共同配置されているノードのうちの
いくつかと共に、いくつかの実施形態において、複数の複製ＤＡＧノードのそれぞれとし
て実施され得る。例えば、複製ＤＡＧ‐ＲＤ１のノードＮ１、Ｎ２、Ｎ３、Ｎ４がログ４
２１８Ａに使用され、別の複製ＤＡＧのノードＮｋ、Ｎｌ、Ｎｍ、ＮｎがＭＣＤＲ４２４
０に使用され、Ｎ１は所定のサーバ上でＮｋと共同配置され、Ｎ２は別のサーバ上でＮｌ
と共同配置される等する。少なくともいくつかの実施形態において、ＭＣＤＲ４２４０に
使用される複製ＤＡＧのノードの数は、マスタＬＴＭのログ４２１８Ａに使用される複製
ＤＡＧのノードの数と同一である必要はない。一実施形態において、ログ４２１８Ａ及び
ＭＣＤＲ４２４０のレコードに、同一の複製ＤＡＧが使用され得る。いくつかの実施形態
において、ＬＴＭのうちの１つをマスタとして指定することは、必ずしもそのＬＴＭのリ
ソースをＭＣＤＲと共有することを伴うとは限らないことに留意されたい。別の実施形態
において、複数のＬＴＭログが、格納グループのそれぞれのＭＣＤＲと共同配置され得る
。

図４３は、少なくともいくつかの実施形態による、複数パーティショントランザクショ
ンに対応する格納グループで生成され得るコミット要求の例示的構成要素を示す。示され
るように、コミット要求４３４４は、トランザクション種類４３０２（例えばコミットが
要求されている書き込み（複数可）は、単一パーティショントランザクションの一環であ
るか、複数パーティショントランザクションの一環であるか）の開示を含み得る。いくつ
かの実施態様において、トランザクション種類４３０２の代わりに、コミット種類がコミ
ット要求内に示され、例えば、複数パーティショントランザクションの書き込み（複数可
）に対し「条件付き」コミット種類が示され、単一パーティショントランザクションの書
き込み（複数可）に対し「無条件」コミット種類が示される。コミット要求は、１つまた
は複数の書き込み記述子４３０６により表現される書き込みが依存する読み出しを示す１
つまたは複数の読み出し記述子４３０４を含み得る。いくつかの実施形態において、読み
出し記述子は、ＲＲＶＭ（読み出し再現性検証メタデータ）、及び／または読み出しが対
象とするパーティションのコミット済みステートを表す１つまたは複数のステート遷移イ
ンジケータを含み、これらのＲＲＶＭとステート遷移インジケータは、（パーティション
レベルで）前述のＲＲＶＭとステート遷移インジケータに類似する。

書き込み記述子４３０６（図１７〜２５に関連して前論された書き込み集合記述子に類
似し得る）は、例えばコミット要求の書き込みが対象とする位置の指示を含み得る。書き
込みペイロード（複数可）４３０８は、書き込み記述子内に示されるアドレスに書き込む
データまたはコンテンツを示し得る。いくつかの実施形態において、重複排除制約及び／
またはコミット順序付け制約等を参照して前述された論理制約は、それぞれの論理制約記
述子４３１０を介して示され得る。（この論理制約記述子は、図２２〜２５を参照して論
じられる論理制約記述子に類似し得る。）論理制約は、いくつかのこのような実施形態に
おいてパーティションレベルで、他の実施形態において格納グループレベルで指示され得
る。論理制約が格納グループレベルで指示される場合、コミット要求４３４４を受信する
ＬＴＭは、いくつかの実施形態において、要求された書き込みを条件付きで（または無条
件に）コミットする前に確実に制約が満たされているように、他のＬＴＭと協働する必要
があり得る。

図４３に描かれた実施形態において、ＭＣＤＲ情報４３１２は、複数パーティショント
ランザクションのコミット要求内に含まれ得る。ＭＣＤＲ情報は、例えば、コミット要求
に応じて作成されると予想される無条件コミットレコード（またはアボートレコード）に
アクセスするために使用可能な識別子、キー、またはアドレスを含み得る。複数パーティ
ショントランザクションを表す一意的識別子またはキーは、例えば、いくつかの実施形態
において、ハッシュテーブルまたは同様の構造内で無条件コミットレコードを検索するた
めに使用され得る。ＭＣＤＲ情報４３１２は、ＬＴＭログに格納されている条件付きコミ
ットレコードに含まれ、そのため例えば書き込みアプライヤは無条件コミット／アボート
レコードの位置を特定することが可能である。

いくつかの実施形態において、コミットタイムアウト値４３１４がコミット要求内に指
示され得る。コミットタイムアウト値は、複数パーティショントランザクションＭＴ１の
条件付きコミットレコードＣＣＲ１を調べた書き込みアプライヤＷＡ１が、ＣＣＲ１の書
き込み（複数可）の伝播を破棄する前に、ＭＴ１に対応する無条件コミットレコードＵＣ
ＲがＭＣＤＲに書き込まれるのを待たなければならない最大時間を示し得る。従って、コ
ミットタイムアウト値により、クライアント側コンポーネントがハングアップした場合ま
たは障害を生じた場合の問題を解決する方法が提供され得る。これがなければ、いくつか
の実施態様において、複数パーティショントランザクションの結末（コミットまたはアボ
ート）に関して不確定性を生じる可能性があり得る。少なくともいくつかの実施形態にお
いて、ＭＣＤＲは、単調に増加する論理タイムスタンプ値を提供する論理クロックを実施
し、そしてタイムアウト値は、このようなクロックの将来論理タイムスタンプ値として表
現され得る。例えば、１つのシナリオにおいて、コミット要求４３４４を準備するクライ
アント側コンポーネントは、ＭＣＤＲ論理クロックから現在の論理タイムスタンプ値ＬＴ
Ｓ１を読み出し、ある選択オフセット（例えば１０００）をＬＴＳ１に加えてタイムアウ
ト値を取得し得る。タイムアウト値（ＬＴＳ１＋１０００）は、コミット要求４３４４を
受信するＬＴＭにより生成される条件付きコミットレコード内に格納され得る。いくつか
の実施形態において、そのコミット要求内に示される書き込みを伝播する責務を担う書き
込みアプライヤは、無条件コミットレコード（または無条件アボートレコード）が適切な
ＭＣＤＲ内に存在するか否かを定期的に確認し得る。書き込みアプライヤは、無条件コミ
ット／アボートレコードを発見できなかった場合、ＭＣＤＲの論理クロックから現在の論
理タイムスタンプを取得し得る。当実施例において現在のタイムスタンプがＬＴＳ１＋１
０００のタイムアウト値を超える場合、書き込みアプライヤは、条件付きコミットレコー
ドの書き込みの伝播／適用を破棄し得る。いくつかの実施形態において図４３に示される
全てのコンポーネントがコミット要求内に組み込まれ得るとは限らず、また他の実施形態
においては図４３に図示されていない別のコンポーネントが含まれ得ることに留意された
い。ＭＣＤＲ情報４３１２及びコミットタイムアウト値４３１４は、コミット要求レコー
ド４３４４に含まれ得る複数パーティショントランザクションメタデータの実施例として
みなされ得る。

いくつかの実施形態において、単一パーティショントランザクションは、格納グループ
で処理される総作業負荷のうちかなりの割合（または過半数すら）を占め、コミット済み
単一パーティショントランザクションの書き込みは、ＭＣＤＲを調べることなく書き込み
アプライヤによりパーティションに伝播され得る。単一パーティショントランザクション
の書き込みが依存する読み出しは、書き込み自体と同様に、複数のパーティションを対象
とし得ないため、単一のＬＴＭのみがこのようなトランザクションに対し競合検出を行う
ように求められ得る。いくつかのこのような実施形態において、単一パーティショントラ
ンザクションに関してＬＴＭログに格納される情報の種類は、複数パーティショントラン
ザクションに関して格納される情報の種類とは異なり得る。図４４ａと図４４ｂは、少な
くともいくつかの実施形態による、ログベーストランザクションマネジャーにより単一パ
ーティショントランザクションと複数パーティショントランザクションに関してそれぞれ
格納され得るコミットレコードの例示的構成要素を示す。図４４ａに示されるように、単
一パーティショントランザクションのコミット要求４４３１が、クライアント側コンポー
ネント４４３０により、そのパーティションに指定されたＬＴＭ４４０２に対し提出され
得る。ＬＴＭ４４０２の競合検出器４４０２は、コミット要求４４３１に含まれる１つま
たは複数の読み出し記述子を、持続的ログ４４４２に前に格納されているコミットレコー
ドの選択集合と共に使用して、コミット要求４４３１内に示される読み出しが後続のコミ
ット済み書き込みと競合するか否かを判定し得る。競合が検出されない場合、コミット要
求４４３１に対応するコミットレコード４４４４Ａが、ログ４４４２に追加され得る。要
求４４３１は単一パーティショントランザクションに対するものであるため、コミットを
無条件として指定するために追加の整合（例えば複数パーティショントランザクションの
場合にクライアント側コンポーネントにより行われる整合と同様の整合）は必要でなくて
よい。従って、少なくともいくつかの実施形態において、コミットレコード４４４４Ａは
、例えば示される種類フィールド４４５２Ａを使用して、コミットが無条件であることを
示し得る。単一パーティションコミット要求のコミットレコード４４４４Ａはまた、例え
ば１つまたは複数の書き込みペイロードの指示と、書き込みが対象とするパーティション
内の位置とを含む書き込み（複数可）情報４４６２Ａも含み得る。

図４４ｂに示されるように、複数パーティショントランザクションの書き込みのコミッ
ト要求４４３２に応じて、（例えば要求４４３２の読み出し記述子（複数可）と、ログ４
４４２に前に格納されたコミット要求の選択集合とに基づいて、）競合検出器４４４０は
、単一パーティショントランザクションのコミット要求に行われたのと同類のローカル競
合検出を行い得る。しかしながら、描かれた実施形態において、競合がローカルで検出さ
れないイベントで、ログ４４４２に格納される新たなコミットレコード４４４４Ｂは、コ
ミットレコード４４４４Ａとはいくつかの点で異なり得る。例えば、フィールド４４５２
Ｂに示されるコミットの種類は、無条件に設定される代わりに条件付きに設定され得る。
コミット種類フィールド及び書き込み情報４４６２Ｂに加えて、いくつかの実施形態にお
いて、ＭＣＤＲ検索情報４４５６がコミット要求に含まれ得る。ＭＣＤＲ検索情報（コミ
ット要求４４３２のコンテンツに少なくとも部分的に基づき得る）により、書き込みアプ
ライヤは、条件付きコミットレコード４４４４Ｂに対応する無条件コミット／アボートレ
コードが位置すると見込まれる場所を特定することが可能になり得る。実施態様により、
異なる種類のエントリがＭＣＤＲ検索情報４４５６に含まれ得る。例えば無条件コミット
レコードのアドレスまたは識別子が一実施態様において提供され得る、あるいはアドレス
の検索に使用可能なキーが提供され得る、あるいはアドレスを取得するために呼び出し可
能な関数が提供され得る。少なくともいくつかの実施形態において、例えば無条件コミッ
ト／アボートレコードがＭＣＤＲ内で取得可能となるべき最終時間を示すコミットタイム
アウト４４５８が条件付きコミットレコード４４４４Ｂに含まれ、そのためタイムアウト
経過後このような無条件コミット／アボートレコードが見つからなかった場合、条件付き
コミットレコード４４４４Ｂの書き込み（複数可）は、それらの対象パーティションに伝
播される必要はなくてよい。前述のように、少なくともいくつかの実施形態において、こ
のようなタイムアウト値４４５８は、ＭＣＤＲの論理クロックから取得されると見込まれ
る論理タイムスタンプ値により表現され得る。ＭＣＤＲ検索情報及びコミットタイムアウ
ト４４５８は、例えば書き込みアプライヤにより使用される、条件付きコミットレコード
４４４４Ｂに格納される複数パーティショントランザクションメタデータの実施例として
みなされ得る。

いくつかの実施形態において、単一パーティションまたは複数パーティションのコミッ
トレコードのコンテンツは、図４４ａ、４４ｂに例示されるものとは異なり得る。例えば
、一実施形態において、コミットレコードは、コミット種類フィールドの代わりにトラン
ザクション種類フィールド（例えば単一パーティションあるいは複数パーティション）を
含み、そして書き込みアプライヤは、トランザクション種類フィールドのコンテンツに基
づいて、所定のコミットレコードに関してＭＣＤＲのコンテンツの調査が必要か否かを判
定し得る。いくつかの実施態様において、ＭＣＤＲ検索情報４４５６は必要ではあり得な
い。例えば、条件付きコミットの無条件レコードが見つかり得る場所を特定するために書
き込みアプライヤが書き込み記述子のコンテンツを使用することを可能にするプロトコル
が使用され得る。一実施形態において、タイムアウト値はコミットレコード内に示され得
ない。代わりに例えば、書き込みアプライヤが、最初にコミットレコードを読み出した時
に自身のタイムアウトを設定し、そのタイムアウトが経過した時に書き込み伝播の破棄を
判定し得る。

図４５は、少なくともいくつかの実施形態による、クライアント側コンポーネントと、
複数パーティショントランザクションに対応する格納グループのそれぞれのパーティショ
ンのログベーストランザクションマネジャーとにより行われ得る動作態様を示すフロー図
である。構成要素４５０２により示されるように、格納グループのクライアント側コンポ
ーネントＣＳＣ１は、格納グループのパーティションＰ１に対応付けられた第１ログベー
ストランザクションマネジャーＬＴＭ１に対し、複数パーティショントランザクションＭ
ＰＴ１の書き込みＷ１のコミット要求ＣＲ１を提出し得る。例えば、トランザクションが
格納グループの複数のパーティションを対象とする読み出しに依存する場合、トランザク
ションはＣＳＣ１により複数パーティションとして指定され、従ってトランザクション全
体としてのコミット判定は、複数のＬＴＭにより個々のコミット判定が行われる（例えば
それぞれの読み出し書き込み競合検出が行われる）ことを要し得る。図４５に例示される
簡潔なシナリオにおいて、ＭＰＴ１は２つの書き込みＷ１、Ｗ２を含み得る。描かれた実
施形態において、書き込みＷ１は、読み出し記述子ＲＤ１がＣＲ１に含まれる読み出しＲ
１（パーティションＰ１を対象とする）の結果に依存し得る。ＬＴＭ１は、例えば自身の
持続的ログＬ１とＲＤ１とを使用して競合検出を行い、ＬＴＭ１によりローカルで検出可
能な読み出し書き込み競合の類に関してＷ１はコミット可能であるか否かを判定する。競
合が見つからなかった場合（構成要素４５０６にて判定）、Ｗ１は条件付き、またはロー
カルでコミット可能であるとＬＴＭ１により指定されたことを示す新たな条件付きコミッ
トレコードＣＣＲ１が、Ｌ１に格納され得る（構成要素４５１０）。いくつかの実施形態
において、ＣＣＲ１はまた、コミットタイムアウト値、及び／またはＭＰＴ１が無条件で
コミット可能であると判明した場合／時に無条件コミットレコードが書き込まれる見込み
のＭＣＤＲの指示も含み得る。ＬＴＭ１はＣＳＣ１に対し、例えばＣＲ１に応じて、Ｗ１
が条件付きでコミット可能であると判明したこと、かつＣＣＲ１がＬ１に書き込まれたこ
とを通知し得る。描かれた実施形態において、Ｗ１がローカルでコミット可能ではない場
合、例えば構成要素４５０６に対応する動作において１つまたは複数の競合がＬＴＭ１に
より検出された場合、ＣＣＲ１はＬ１に格納されず、そしてＷ１は拒否されたことがＣＳ
Ｃ１に通知され得る（構成要素４５１８）。

描かれた実施形態において、ＣＳＣ１はまた、別の書き込みＷ２に対応するコミット要
求ＣＲ２を、別のパーティションＰ２の競合検出の責務を担うログベーストランザクショ
ンマネジャーＬＴＭ２に対し提出し得る（構成要素４５０４）。ＣＲ２は、Ｗ２が依存す
る読み出し（複数可）を示す自身の読み出し記述子集合も含み得る。ＬＴＭ２は、ＬＴＭ
２のログＬ２とＣＲ２の読み出し記述子とを使用して、Ｗ２に関する自身の競合検出を行
い、Ｗ２がコミット可能であるか否かを判定し得る。ＬＴＭ２がＷ２を受諾することを妨
げる競合が見つからなかった場合（構成要素４５０８）、Ｗ２の条件付きコミットレコー
ドＣＣＲ２が、ＬＴＭ２のログＬ２に格納され得る（構成要素４５１２）。描かれた実施
形態において、ＣＣＲ２はまた、コミットタイムアウト値（例えばＣＣＲ１に格納された
ものと同じ値、またはＬＴＭ２により決定された異なる値）と、Ｗ２の無条件コミットレ
コードが見込まれるＭＣＤＲ位置の指示とを含み得る。例えばＬＴＭ２により生成された
ＣＲ２に対する応答において、Ｗ２が条件付きまたはローカルでコミット可能であると指
定されたこと、かつＣＣＲ２がＬ２に書き込まれたことが、ＣＳＣ１に通知され得る（構
成要素４５１６）。Ｗ２がローカルでコミット可能ではない場合、例えば構成要素４５０
８に対応する動作において１つまたは複数の競合がＬＴＭ２により検出された場合、ＣＣ
Ｒ２はＬ２に格納されず、そしてＷ２は拒否されたことがＣＳＣ１に通知され得る（構成
要素４５２０）。

描かれた実施形態において、例えばＬＴＭ１とＬＴＭ２の両者がそれぞれのログに対し
それぞれの条件付きコミットレコードＣＣＲ１、ＣＣＲ２を書き込んだという特定に基づ
いて、ＣＳＣ１がＷ１とＷ２の両方とも条件付きでコミットされたと判定した場合（構成
要素４５２８）、ＣＳＣ１は、ＭＰＴ１の無条件コミットレコードを生成し、ＭＣＤＲ内
に当該無条件コミットレコードを格納し得る（構成要素４５３１）。Ｗ１とＷ２のうちの
１つ、または両方がコミット不可能であると拒否された場合（同様に構成要素４５２８に
て検出）、例えば条件付きコミットレコードＣＣＲ１またはＣＣＲ２のうちの少なくとも
１つが書き込まれていないとＣＳＣ１が判定した場合、ＣＳＣ１はＭＰＴ１の無条件コミ
ットレコードをＭＣＤＲに格納し得ない。いくつかの実施形態において、代わりにアボー
トレコードがＭＣＤＲに、例えば両方の書き込みがコミット可能であると指定された場合
に無条件コミットレコードが書き込まれ得る位置と同じ位置に、任意で格納され得る（構
成要素４５３４）。ＭＰＴ１に関して２つの書き込みのみが論述されたが、一般に、複数
パーティショントランザクションは任意の所望数の書き込みを含み、そしてＣＳＣは、少
なくともいくつかの実施形態において、全ての書き込みがそれぞれのＬＴＭによりローカ
ルでコミット可能であると指定されたことを確認した後に、無条件コミットレコードを格
納し得ることに留意されたい。いくつかのシナリオにおいて、所定の複数パーティション
トランザクションのいくつかの異なる書き込み（例えばＷｘ、Ｗｙ、Ｗｚ）は、単一のパ
ーティション（例えばＬＰ１）を対象とし得る。いくつかの実施態様において、所定のパ
ーティションに対するいくつかのこのような書き込みは、単一のコミット要求に含まれ得
る。例えばＷｘ、Ｗｙ、Ｗｚを示す１つのコミット要求が、ＣＳＣ１によりＬＴＭ１に対
し送られ得る。別の実施態様において、各書き込み要求は、個別のコミット要求を使用し
て処理され得る。いくつかの実施形態において、要求書き込みが条件付きでコミットされ
たか否かに関して通知されるのを待つ代わりに、ＣＳＣは、書き込みのステータスを特定
するためにより能動的な役割を果たし得る。例えば、ＣＳＣは、直接ＬＴＭログを読み出
し得る（例えば図１５に示されるインターフェース１５１３と同様のログ読み出しインタ
ーフェースを使用して）、あるいはＬＴＭに問い合わしてコミット要求の結果を特定し得
る。

少なくとも一実施形態において、クライアント側コンポーネントは、単一パーティショ
ントランザクションを複数パーティショントランザクションの特例として扱い得る。例え
ば単一パーティショントランザクションの書き込みがＬＴＭによりコミットのために受諾
されたことが特定されると、単一パーティショントランザクションの無条件コミットレコ
ードは、単一パーティションと複数パーティションの両トランザクションに使用されるコ
ミット判定レポジトリ（ＣＤＲ）に同様に格納され得る。このような実施形態において、
ＣＤＲは、単一パーティショントランザクションに関して、並びに複数パーティショント
ランザクションに関して、書き込みアプライヤにより調べられ得る。別の実施形態におい
て、コミット判定レポジトリは、複数パーティショントランザクションのためにのみ使用
され得る。

図４６は、少なくともいくつかの実施形態による、複数パーティショントランザクショ
ンに対応する格納グループの書き込みアプライヤにより行われ得る動作態様を示すフロー
図である。構成要素４６０１に示されるように、格納グループの１つまたは複数のパーテ
ィションに変更を適用するように構成された書き込みアプライヤＷＡ１は、格納グループ
のパーティションＰ１に対応付けられたログベーストランザクションマネジャーＬＴＭ１
の持続的ログに格納されているコミットレコードＣＲｅｃ１を調べ得る。対応コミットは
条件付きであるとＣＲｅｃ１が示す場合（構成要素４６０４にて検出）、ＷＡ１は、ＣＲ
ｅｃ１内に示される書き込み（複数可）は複数パーティショントランザクションの一部で
あること、かつ書き込みがそれらの対象書き込み先に伝播される前に無条件コミットレコ
ードが発見されなければならないことを、推測し得る。従って、構成要素４６１０に示さ
れるように、ＷＡ１は、（ａ）ＣＲｅｃ１に対応する無条件コミットレコードＵＣＲ１が
格納されると見込まれるＭＣＤＲ内の位置と、（ｂ）複数パーティショントランザクショ
ンが破棄されないように、ＵＣＲ１が見つからなければならない最終時間を示すコミット
タイムアウト値ＴＯ１とを、特定し得る。

ＷＡ１は、ＵＣＲ１が既にＭＣＤＲに格納されているか否かを検査し得る（構成要素４
６１４）。描かれた実施形態において、ＵＣＲ１が既に格納されている場合、ＷＡ１は、
ＣＲｅｃ１内に示される書き込み（複数可）を、それらの書き込み先に伝播または適用し
得る（構成要素４６２６）。ＵＣＲ１がＭＣＤＲ内に存在しない場合（同様に構成要素４
６１４にて検出）、ＷＡ１は、（ａ）ＴＯ１により示されるタイムアウトが経過したか、
（ｂ）ＣＲｅｃ１に対応するアボートレコードがＭＣＤＲに格納されているかを検査し得
る（構成要素４６１７）。タイムアウトがＭＣＤＲの論理クロックの論理タイムスタンプ
単位で表現される実施態様において、例えば、ＷＡ１は、現在の論理タイムスタンプに関
してＭＣＤＲにクエリを提出し、タイムアウトが経過したか否かを判定し得る。タイムア
ウトが経過したこと、またはＣＲｅｃ１に対応する複数パーティショントランザクション
が明示的にアボートされたことがＷＡ１により特定された場合、ＣＲｅｃ１の書き込み伝
播及び／またはさらなる処理はＷＡ１により破棄され得る、すなわちＣＲｅｃ１の書き込
みは、それらの書き込み先位置に適用される必要はない（構成要素４６２０）。タイムア
ウトは経過しておらず、かつアボートレコードも見つからない場合（同様に構成要素４６
１７にて検出）、ＷＡ１は、ＣＲｅｃ１に対応する無条件コミットレコードがもう書き込
まれたか否かを確認するためＭＣＤＲを再検査する前に（構成要素４６１４）、特定また
は調整可能ＭＣＤＲ検査間隔を待ち得る（構成要素４６２３）。描かれた実施形態におい
て、ＭＣＤＲは、（ａ）ＣＲｅｃ１に対応する無条件コミットレコードＵＣＲ１が見つか
った、（ｂ）ＣＲｅｃ１に対応するアボートレコードが見つかった、または（ｃ）タイム
アウトが経過した、以上の３つのイベントのうちの１つが起こるまで、構成要素４６１４
以降に従って、間隔を置いて検査され得る。（ａ）が起こった場合、ＣＲｅｃ１の書き込
みは伝播され（構成要素４６２６）、他の場合には、書き込みは最終的に破棄され得る。
いくつかの実施態様において、書き込みの伝播が破棄された場合、コミットレコードＣＲ
ｅｃ１は、破棄を示すために、変更され得る、あるいはＬＴＭ１のログから削除され得る
（例えばＷＡ１からの要求に応じて、ＷＡ１により、またはＬＴＭ１により）。

図４６に描かれた実施形態において、同様に構成要素４６０４にて検出されるように、
ＣＲｅｃ１がそのコミットは無条件であると示した場合（例えばＣＲｅｃ１内に示される
書き込み（複数可）が複数パーティショントランザクションの代わりに単一パーティショ
ントランザクションの一部である場合）、書き込みは、ＭＣＤＲのいかなる調査もするこ
となく、ＷＡ１によりそれらの目的書き込み先へ伝播され得る（構成要素４６２６）。別
の実施形態において、前述のように、単一パーティション及び複数パーティションの両ト
ランザクションは、無条件コミットレコードが両種類のトランザクションのコミット判定
レポジトリに格納され得るという点で、統一した手法で処理され、そして書き込みアプラ
イヤは、いずれの種類のトランザクションの書き込みも伝播する前に、このような無条件
コミットレコードが書き込まれていることを確認する必要があり得る。

様々な実施形態において、図６、７、８、９、１０、１２、１３、１４、１９、２０、
２５、３０、３７、３８、４５、４６のフロー図において例示される動作とは異なる動作
が、前述の技術のうちの少なくともいくつかを実施するために使用され得ることに留意さ
れたい。フローチャートに示される動作のうちのいくつかは、いくつかの実施形態におい
て実行されなくてよい、または別の順序で実行され得る、または順次ではなく並行して実
行され得る。

使用事例
読み出し記述子とクライアント側トランザクション準備を使用するログベーストランザ
クション管理を含む、複製ＤＡＧを使用してアプリケーションステート変更を管理する前
述の技術は、様々な実施形態において有用であり得る。より多くの組織が自身のコンピュ
ーティングをプロバイダネットワーク環境へ移行するにつれ、それぞれの整合性セマンテ
ィック及びそれぞれのインターフェースを有するより多様な分散格納アプリケーションが
開発されてきた。いくつかの大アプリケーションは複数データストアインスタンスにわた
り、そして複製ＤＡＧ及びログベーストランザクション管理技術は、分散格納アプリケー
ション管理に対する、統合され、柔軟で、拡大縮小可能な、可用性の高い手法を表し得る
。ＤＡＧ構成のそれぞれの見解は少なくとも一時的に異なり得るが、複製ＤＡＧノードの
アプリケーションステート遷移を進行させる能力は、より少ない動的複製技術が使用され
た場合に起こり得る、アプリケーション要求を処理する際の「全世界停止」中断のうちの
少なくともいくつかを低減または削除し得る。ログベーストランザクション管理は、デー
タストア横断トランザクション（並びに原子複数書き込みトランザクションに対応し得な
いデータストアに対する複数アイテムトランザクション）を可能にし得るだけでなく、自
動化クエリ応答生成、スナップショット生成等の機能の促進も行い得る。ログサービスの
自身の読み出しインターフェースを使用することで、複数データストアにわたるデータ分
析を行う完全に新しい方法が利用可能となり得る。このような新たな種類のデータストア
横断動作の費用を明確にする価格設定ポリシーが実施され、これによりユーザは、自身の
データ変換要求に関して、情報に基づいた予算決定を行うことが可能となる。非常に高い
スループットのアプリケーションのために、前述の手法を使用して、楽観的ログベースト
ランザクション管理は拡張され得る。拡張された楽観的ログベーストランザクション管理
では、ログベーストランザクションマネジャーは所定格納グループのそれぞれのパーティ
ションに設定され、そしていずれかの所定の複数パーティショントランザクションのコミ
ットは、複数のこのようなトランザクションマネジャーと対話するクライアント側コンポ
ーネントにより整合される。

いくつかのプロバイダネットワーク環境において、仮想化コンピューティングサービス
、格納サービス、またはデータベースサービス等、プロバイダネットワークにて実施され
る別のネットワークアクセス可能サービスの制御プレーン構成情報を格納するのに、複製
ＤＡＧによるログベーストランザクション管理が使用され得る。このようなシナリオにお
いて、ログを使用して管理されるトランザクションは、ネットワークアクセス可能サービ
スの様々なリソース（仮想コンピューティングサービスの事例における演算インスタンス
または仮想ホスト等）の構成に対する変更を表し得る。

例示的コンピュータシステム
少なくともいくつかの実施形態において、複製ＤＡＧの様々なコンポーネント、トラン
ザクション管理のためのログサービス、または異種格納システム（フロントエンド要求ハ
ンドラ等のクライアント側コンポーネント、並びに複数パーティションコミット判定レポ
ジトリを含む）を実行する技術を含む、本明細書において説明される技術のうちの１つま
たは複数の一部または全てを実施するサーバは、１つまたは複数のコンピュータアクセス
可能媒体を含む、またはそのような媒体にアクセスするように構成された、汎用コンピュ
ータシステムを含み得る。図４７は、このような汎用コンピューティングデバイス９００
０を例示する。例示される実施形態において、コンピューティングデバイス９０００は、
入出力（Ｉ／Ｏ）インターフェース９０３０を介してシステムメモリ９０２０（不揮発性
及び揮発性メモリモジュールの両方を備え得る）に接続された１つまたは複数のプロセッ
サ９０１０を含む。コンピューティングデバイス９０００はさらに、Ｉ／Ｏインターフェ
ース９０３０に接続されたネットワークインターフェース９０４０を含む。

様々な実施形態において、コンピューティングデバイス９０００は、１つのプロセッサ
９０１０を含むユニプロセッサシステム、またはいくつか（例えば２つ、４つ、８つもし
くは別の好適な個数）のプロセッサ９０１０を含むマルチプロセッサシステムであり得る
。プロセッサ９０１０は、命令を実行可能な任意の好適なプロセッサであり得る。例えば
、様々な実施形態において、プロセッサ９０１０は、様々な命令集合アーキテクチャ（Ｉ
ＳＡ）、例えばｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、ＭＩＰＳ‐ＩＳＡ、またはその他
の好適なＩＳＡ等、そのうちのいずれかを実施する汎用または組み込みプロセッサであり
得る。マルチプロセッサシステムにおいて、それぞれのプロセッサ９０１０は一般に、必
ずではないが、同一のＩＳＡを実施し得る。いくつかの実施態様において、従来のプロセ
ッサの代わりに、または従来のプロセッサに加えて、グラフィック処理ユニット（ＧＰＵ
）が使用され得る。

システムメモリ９０２０は、プロセッサ９０１０（複数可）によりアクセス可能な命令
及びデータを格納するように構成され得る。少なくともいくつかの実施形態において、シ
ステムメモリ９０２０は、揮発性及び不揮発性部分の両方を備え得る。別の実施形態にお
いては、揮発性メモリのみが使用され得る。様々な実施形態において、システムメモリ９
０２０の揮発性部分は、静的ランダムアクセスメモリ（ＳＲＡＭ）、同期式動的ＲＡＭ、
またはその他の種類のメモリ等、任意の好適なメモリ技術を使用して実行され得る。シス
テムメモリの不揮発性部分（例えば１つまたは複数のＮＶＤＩＭＭを備え得る）に関して
、いくつかの実施形態において、ＮＡＮＤフラッシュデバイスを含むフラッシュベースメ
モリデバイスが使用され得る。少なくともいくつかの実施形態において、システムメモリ
の不揮発性部分は、超コンデンサまたは他の蓄電装置（例えば電池）等の電源を含み得る
。様々な実施形態において、メモリスタベースの抵抗ランダムアクセスメモリ（ＲｅＲＡ
Ｍ）、３次元ＮＡＮＤ技術、強誘電性ＲＡＭ、磁気抵抗ＲＡＭ（ＭＲＡＭ）、または様々
な種類の相変化メモリ（ＰＣＭ）のうちのいずれかが、少なくともシステムメモリの不揮
発性部分に使用され得る。例示される実施形態において、前述の方法、技術、及びデータ
等、１つまたは複数の所望する機能を実行するプログラム命令及びデータは、システムメ
モリ９０２０内にコード９０２５及びデータ９０２６として格納されることが示される。

一実施形態において、Ｉ／Ｏインターフェース９０３０は、プロセッサ９０１０と、シ
ステムメモリ９０２０と、様々な種類の持続的及び／または揮発性格納デバイス等、ネッ
トワークインターフェース９０４０または他の周辺インターフェースを含む任意の周辺デ
バイスとの間のデバイス内のＩ／Ｏトラフィックを調整するように構成され得る。いくつ
かの実施形態において、Ｉ／Ｏインターフェース９０３０は、１つのコンポーネント（例
えばシステムメモリ９０２０）からのデータ信号を、別のコンポーネント（例えばプロセ
ッサ９０１０）が使用するのに好適な形式に変換するために、任意の必要なプロトコル変
換、タイミング変換、または他のデータ変換を行い得る。いくつかの実施形態において、
Ｉ／Ｏインターフェース９０３０は、例えば周辺構成要素相互接続（ＰＣＩ）バス規格ま
たは汎用シリアルバス（ＵＳＢ）規格の変形等、様々な種類の周辺バスを介して取り付け
られるデバイスのサポートを含み得る。いくつかの実施形態において、Ｉ／Ｏインターフ
ェース９０３０の機能は、例えばノースブリッジとサウスブリッジといった２つ以上の別
々のコンポーネントに分割され得る。また、いくつかの実施形態において、システムメモ
リ９０２０に対するインターフェース等、Ｉ／Ｏインターフェース９０３０の機能性のう
ちの一部または全ては、プロセッサ９０１０に直接組み込まれ得る。

ネットワークインターフェース９０４０は、コンピューティングデバイス９０００と、
例えば図１から図４６までにおいて例示される他のコンピュータシステムまたはデバイス
等、ネットワーク９０５０（複数可）に接続される他のデバイス９０６０との間でデータ
交換が可能なように構成され得る。様々な実施形態において、ネットワークインターフェ
ース９０４０は、例えばイーサネット（登録商標）ネットワークの類等、任意の好適な有
線または無線汎用データネットワークを介して、通信に対応し得る。さらに、ネットワー
クインターフェース９０４０は、アナログ音声ネットワークもしくはデジタルファイバ通
信ネットワーク等の電気通信／電話ネットワークを介した、またはファイバチャネルＳＡ
Ｎ等の格納エリアネットワークを介した、またはその他の好適な種類のネットワーク及び
／またはプロトコルを介した、通信に対応し得る。

いくつかの実施形態において、システムメモリ９０２０は、対応方法及び装置の実施形
態を実行するために、図１から図４６に関して前述されたプログラム命令及びデータを格
納するように構成されたコンピュータアクセス可能媒体の一実施形態であり得る。しかし
ながら、別の実施形態において、プログラム命令及び／またはデータは、異なる種類のコ
ンピュータアクセス可能媒体上で受信、送信、または格納され得る。一般に、コンピュー
タアクセス可能媒体には、例えばＩ／Ｏインターフェース９０３０を介してコンピューテ
ィングデバイス９０００に接続されるディスクまたはＤＶＤ／ＣＤといった磁気媒体また
は光学式媒体等の非一時的記憶媒体またはメモリ媒体が含まれ得る。非一時的コンピュー
タアクセス可能記憶媒体には、システムメモリ９０２０または別の種類のメモリとしてコ
ンピューティングデバイス９０００のいくつかの実施形態に含まれ得るＲＡＭ（例えばＳ
ＤＲＡＭ、ＤＤＲ‐ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の任意の揮発性ま
たは不揮発性媒体も含まれ得る。さらに、コンピュータアクセス可能媒体は、ネットワー
クインターフェース９０４０を通して実施され得るネットワーク及び／または無線リンク
等の通信媒体を介して伝達される伝送媒体または電気、電磁、もしくはデジタル信号等の
信号を含み得る。様々な実施形態において説明される機能性を実行するために、図４７に
例示されるような複数のコンピューティングデバイスの一部または全てが使用され得る。
例えば、様々な異なるデバイス及びサーバ上で稼働するソフトウェアコンポーネントは、
協働して機能性を提供し得る。いくつかの実施形態において、説明される機能性の一部は
、汎用コンピュータシステムを使用して実行されるのに加えて、またはそれに代わって、
格納デバイス、ネットワークデバイス、または特殊目的コンピュータシステムを使用して
実行され得る。本明細書で使用される「コンピューティングデバイス」という用語は、少
なくとも全てのこれらの種類のデバイスを指し、かつこれらの種類のデバイスに限定され
ない。

前述の内容は、以下の追加条項を考慮することでより理解され得る。
１．１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記１
つまたは複数のコンピューティングデバイスは、
第１ログベーストランザクションマネジャー（ＬＴＭ）にて、格納グループのクライア
ント側コンポーネントから、第１複数パーティショントランザクションの第１書き込みに
対する第１コミット要求を受信することであって、前記第１書き込みは前記第１コミット
要求内に示される第１読み出しの結果に依存し、前記第１読み出しは前記格納グループの
第１パーティションを対象とした、前記第１複数パーティショントランザクションの前記
第１書き込みに対する前記第１コミット要求を受信することと、
第２ＬＴＭにて、前記クライアント側コンポーネントから、前記第１複数パーティショ
ントランザクションの第２書き込みに対する第２コミット要求を受信することであって、
前記第２書き込みは前記第２コミット要求内に示される第２読み出しの結果に依存し、前
記第２読み出しは前記格納グループの第２パーティションを対象とした、前記第１複数パ
ーティショントランザクションの前記第２書き込みに対する前記第２コミット要求を受信
することと、
前記第１ＬＴＭの第１持続的ログ内に、前記第１読み出しと前記第１持続的ログ内に記
録されている書き込みの第１部分集合との間の読み出し書き込み競合に関して前記第１書
き込みはコミット可能であることを示す、前記第１書き込みに対応する第１条件付きコミ
ットレコードを格納することであって、前記第１条件付きコミットレコードは前記第１複
数パーティショントランザクションに関するメタデータを含む、前記第１書き込みに対応
する前記第１条件付きコミットレコードを格納することと、
前記第２ＬＴＭの第２持続的ログ内に、前記第２読み出しと前記第２持続的ログ内に記
録されている書き込みの第２部分集合との間の読み出し書き込み競合に関して前記第２書
き込みはコミット可能であることを示す、前記第２書き込みに対応する第２条件付きコミ
ットレコードを格納することであって、前記第２条件付きコミットレコードは前記第１複
数パーティショントランザクションに関する前記メタデータを含む、前記第２書き込みに
対応する前記第２条件付きコミットレコードを格納することと、
（ａ）前記第１条件付きコミットレコードが格納され、かつ（ｂ）前記第２条件付きコ
ミットレコードが格納されたことの特定に応じて、前記クライアント側コンポーネントに
より、前記第１複数パーティショントランザクションに対応する第１無条件コミットレコ
ードを、複数パーティションコミット判定レポジトリ（ＭＣＤＲ）に格納することと、
（ａ）前記第１条件付きコミットレコードに含まれる前記第１複数パーティショントラ
ンザクションに関する前記メタデータの調査と、（ｂ）前記第１無条件コミットレコード
の調査と、に応じて、前記格納グループの特定パーティションに対応付けられた第１書き
込みアプライヤにより、前記特定パーティションに対し前記第１書き込みを伝播すること
と、
を実行するように構成される、前記システム。

２．前記１つまたは複数のコンピューティングデバイスはさらに、
前記第１ＬＴＭにて、別の複数パーティショントランザクションの第３書き込みに対す
る第３コミット要求を受信することであって、前記第３書き込みは前記第１パーティショ
ンを対象とし、前記第３コミット要求は前記別の複数パーティショントランザクションの
タイムアウトの表現を含む、前記別の複数パーティショントランザクションの前記第３書
き込みに対する前記第３コミット要求を受信することと、
前記第１持続的ログ内に、読み出し書き込み競合に関して前記第３書き込みがコミット
可能であることを示す、前記第３書き込みに対応する第３条件付きコミットレコードを格
納することと、
前記タイムアウトの経過後、前記別の複数パーティショントランザクションに対応する
第２無条件コミットレコードが前記ＭＣＤＲに格納されていないことを検出することと、
前記第１パーティションに対する前記第３書き込みの伝播は実施しないことを決定する
ことと、
を実行するように構成される、条項１に記載のシステム。

３．前記第１コミット要求は前記ＭＣＤＲの指示を含み、前記第１複数パーティション
トランザクションに関する前記メタデータは前記ＭＣＤＲの前記指示を含む、条項１に記
載のシステム。

４．前記１つまたは複数のコンピューティングデバイスはさらに、
前記第１コミット要求の前に、前記格納グループに対する１つまたは複数の種類の動作
の目標性能レベルの指示を受信し、
（ａ）前記格納グループのために確立すべきＬＴＭの数、（ｂ）前記格納グループのた
めに確立すべきＭＣＤＲの数、または（ｃ）前記格納グループのために確立すべき書き込
みアプライヤの数、以上のうちの１つまたは複数を、前記目標性能レベルの前記指示に少
なくとも部分的に基づいて決定する、
ように構成される、条項１に記載のシステム。

５．前記第１パーティションは前記格納グループのマスタパーティションに指定され、
前記第１持続的ログは第１サーバの１つまたは複数の格納デバイスの少なくとも第１部分
を備え、前記ＭＣＤＲは前記第１サーバの前記１つまたは複数の格納デバイスの少なくと
も第２部分を備える、条項１に記載のシステム。

６．１つまたは複数のコンピューティングデバイスにより、
格納グループの第１ログベーストランザクションマネジャー（ＬＴＭ）の第１持続的ロ
グ内に、前記第１ＬＴＭにより行われた第１競合検出分析に少なくとも部分的に基づいて
第１書き込みがコミット可能であると指定されたことを示す、第１複数パーティショント
ランザクションの前記第１書き込みに対応する第１条件付きコミットレコードを格納する
ことと、
前記格納グループの第２ＬＴＭの第２持続的ログ内に、前記第２ＬＴＭにより行われた
第２競合検出分析に少なくとも部分的に基づいて第２書き込みがコミット可能であると指
定されたことを示す、前記第１複数パーティショントランザクションの前記第２書き込み
に対応する第２条件付きコミットレコードを格納することと、
前記第１及び第２書き込みがコミット可能であると指定されたことの検出に応じて、前
記第１複数パーティショントランザクションに対応する第１無条件コミットレコードを格
納することと、
（ａ）前記第１条件付きコミットレコードの調査と、（ｂ）前記第１無条件コミットレ
コードの調査と、に応じて、第１書き込みアプライヤにより前記格納グループの特定パー
ティションに対し前記第１書き込みを伝播することと、
を含む方法。

７．前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記第１ＬＴＭにて、別の複数パーティショントランザクションの別の書き込みに対す
るコミット要求を受信することであって、前記別の書き込みは前記第１パーティションを
対象とし、前記コミット要求は前記別の複数パーティショントランザクションのタイムア
ウトの表現を含む、前記別の複数パーティショントランザクションの前記別の書き込みに
対する前記コミット要求を受信することと、
前記第１持続的ログ内に、前記第１ＬＴＭにより行われた第３競合検出分析に少なくと
も部分的に基づいて前記別の書き込みがコミット可能であることを示す、前記別の書き込
みに対応する第３条件付きコミットレコードを格納することと、
前記タイムアウトの経過後、前記別の複数パーティショントランザクションに対応する
第２無条件コミットレコードが複数パーティションコミット判定レポジトリ（ＭＣＤＲ）
に格納されていないことを検出することと、
前記第１パーティションに対する前記別の書き込みの伝播は実施しないことを決定する
ことと、
を含む条項６に記載の方法。

８．前記ＭＣＤＲは単調に増加する論理タイムスタンプ値を提供する関連論理クロック
を有し、前記タイムアウトは前記論理クロックから取得が見込まれる特定の将来論理タイ
ムスタンプ値を含む、条項７に記載の方法。

９．前記第１書き込みに対する第１コミット要求に応じて前記第１条件付きコミットレ
コードは格納され、前記第２書き込みに対する第２コミット要求に応じて前記第２条件付
きコミット要求は格納され、前記１つまたは複数のコンピューティングデバイスにより、
さらに、
前記第１ＬＴＭにて、第２複数パーティショントランザクションの第３書き込みに対す
る第３コミット要求を受信することであって、前記第３書き込みは前記第１パーティショ
ンを対象とする第３読み出しの結果に依存する、前記第２複数パーティショントランザク
ションの前記第３書き込みに対する前記第３コミット要求を受信することと、
前記第２ＬＴＭにて、前記第２複数パーティショントランザクションの第４書き込みに
対する第４コミット要求を受信することであって、前記第４書き込みは前記第２パーティ
ションを対象とする第４読み出しの結果に依存する、前記第２複数パーティショントラン
ザクションの前記第４書き込みに対する前記第４コミット要求を受信することと、
前記第１持続的ログ内に、前記第１ＬＴＭにより行われた第３競合検出分析に少なくと
も部分的に基づいて前記第３書き込みがコミット可能であることを示す、前記第３書き込
みに対応する第３条件付きコミットレコードを格納することと、
前記第２ＬＴＭにより検出された特定の競合に少なくとも部分的に基づいて、前記第２
ＬＴＭにより前記第４コミット要求は拒否されたことを特定することと、
前記第４コミット要求が拒否されたことの前記開示に応じて、前記第３書き込みの伝播
を破棄することと、
を含む請求項６に記載の方法。

１０．前記第１ＬＴＭにて前記格納グループのクライアント側コンポーネントから受信
された第１コミット要求に応じて前記第１条件付きコミットレコードは格納され、前記第
１無条件コミットレコードの前記格納は前記クライアント側コンポーネントにより行われ
る、条項６に記載の方法。

１１．前記第１コミット要求は、前記第１無条件コミットレコードが格納されるＭＣＤ
Ｒの指示を含む、条項１０に記載の方法。

１２．前記第１コミット要求は第１読み出しの開示を含み、前記第１書き込みは前記第
１読み出しの結果に依存し、前記第１読み出しの前記開示は前記第１ＬＴＭにより前記第
１競合検出分析を行うために使用される、条項１０に記載の方法。

１３．前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記格納グループに対する１つまたは複数の種類の動作の目標性能レベルの指示を受信
することと、
（ａ）前記格納グループのために確立すべきＬＴＭの数、（ｂ）前記格納グループのた
めに確立すべき複数パーティションコミット判定レポジトリの数、または（ｃ）前記格納
グループのために確立すべき書き込みアプライヤの数、以上のうちの１つまたは複数を、
前記目標性能レベルの前記指示に少なくとも部分的に基づいて決定することと、
を含む条項６に記載の方法。

１４．前記第１パーティションは前記格納グループのマスタパーティションに指定され
、前記第１持続的ログは第１サーバの１つまたは複数の格納デバイスの少なくとも第１部
分を備え、前記第１無条件コミットレコードは前記１つまたは複数の格納デバイスのうち
の特定格納デバイスに格納される、条項６に記載の方法。

１５．前記第１無条件コミットレコードは、第１ノード及び第２ノードを含む複製有向
非巡回グラフの複数のノードを備える複数パーティションコミット判定レポジトリ（ＭＣ
ＤＲ）に格納され、前記第１無条件コミットレコードの前記格納は、前記第１ノード及び
前記第２ノードに前記第１無条件コミットレコードのそれぞれのレプリカを格納すること
を含む、条項６に記載の方法。

１６．プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって
、前記プログラム命令は１つまたは複数のプロセッサ上で実行されると、格納グループの
クライアント側コンポーネントを実行し、前記クライアント側コンポーネントは、
格納グループの第１ログベーストランザクションマネジャー（ＬＴＭ）へ、第１複数パ
ーティショントランザクションの第１書き込みに対する第１コミット要求を送信すること
であって、前記第１コミット要求は前記第１書き込みが依存する第１読み出しの開示を含
み、前記第１読み出しは前記格納グループの第１パーティションを対象とした、前記第１
複数パーティショントランザクションの前記第１書き込みに対する前記第１コミット要求
を送信することと、
前記格納グループの第２ログベーストランザクションマネジャー（ＬＴＭ）へ、第１複
数パーティショントランザクションの第２書き込みに対する第２コミット要求を送信する
ことであって、前記第２コミット要求は前記第２書き込みが依存する第２読み出しの開示
を含み、前記第２読み出しは前記格納グループの第２パーティションを対象とした、前記
第１複数パーティショントランザクションの前記第２書き込みに対する前記第２コミット
要求を送信することと、
（ａ）第１コミット分析に少なくとも部分的に基づいて前記第１ＬＴＭにより前記第１
書き込みはコミット可能であると指定され、かつ（ｂ）第２コミット分析に少なくとも部
分的に基づいて前記第２ＬＴＭにより前記第２書き込みはコミット可能であると指定され
たことの特定に応じて、前記第１複数パーティショントランザクションに対応する第１無
条件コミットレコードを選択位置に格納することと、
を実行するように構成される、前記非一時的コンピュータアクセス可能記憶媒体。

１７．前記第１コミット要求は、（ａ）前記選択位置の指示、または（ｂ）前記第１複
数パーティショントランザクションのコミットタイムアウト、以上のうちの１つまたは複
数を含む、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。

１８．前記クライアント側コンポーネントはさらに、
前記第１ＬＴＭにより別の複数パーティショントランザクションの少なくとも１つの書
き込みがコミット不可能であると指定されたことの特定に応じて、前記別の複数パーティ
ショントランザクションに対応するアボートレコードを別の選択位置に格納する、
ように構成される、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。

１９．プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって
、前記プログラム命令は１つまたは複数のプロセッサ上で実行されると、格納グループの
書き込みアプライヤを実行し、前記書き込みアプライヤは、
前記格納グループのログベーストランザクションマネジャーにより持続的ログ内に格納
された特定レコードが、前記格納グループの第１パーティションを対象とする第１書き込
みの条件付きコミットを表すことを特定し、
第１パーティションを対象とする１つまたは複数の書き込みを含む複数パーティション
トランザクションの無条件コミットレコードを格納するように指定されたコミット判定レ
ポジトリを特定し、
前記第１書き込みを含む第１複数パーティショントランザクションの無条件コミットレ
コードを前記コミット判定レポジトリが含むことの特定に応じて、前記格納グループの前
記第１パーティションに対し前記第１書き込みを伝播する、
ように構成される、前記非一時的コンピュータアクセス可能記憶媒体。

２０．前記書き込みアプライヤは、
第２複数パーティショントランザクションの一部であり、前記第１パーティションを対
象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコー
ドが表すことを特定し、
前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウト
を特定し、
前記タイムアウトの経過前に前記コミット判定レポジトリに前記第２複数パーティショ
ントランザクションに対応する無条件コミットレコードが書き込まれていないことの検出
に少なくとも部分的に基づいて、前記第１パーティションに対する前記第２書き込みの伝
播を破棄する、
ように構成される、条項１９に記載の前記非一時的コンピュータアクセス可能記憶媒体
。

２１．前記書き込みアプライヤは、
前記持続的ログ内に格納された第２レコードが、前記第１パーティションを対象とする
第２書き込みの無条件コミットを表すことを特定し、
前記コミット判定レポジトリを調べることなく、前記第１パーティションに対し前記第
２書き込みを伝播する、
ように構成される、条項１９に記載の前記非一時的コンピュータアクセス可能記憶媒体
。

さらに、前述の内容は、以下の追加条項を考慮することでより理解され得る。
１．１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記１
つまたは複数のコンピューティングデバイスは、
第１データストア及び第２データストアを含む複数のデータストアを備える異種格納グ
ループのクライアント側コンポーネントにて、前記第１データストアを対象とする第１読
み出しに対応する第１読み出し記述子を含む、１つまたは複数の読み出しに対応するそれ
ぞれの読み出し記述子を受信することであって、前記第１読み出し記述子は前記第１デー
タストアにて適用されたステート遷移の開示を含み、前記第１データストアは、ステート
レスプロトコルに従って、前記第１読み出し記述子が前記クライアント側コンポーネント
に提供された後に前記クライアント側コンポーネントに関するセッションメタデータを保
持しない、前記１つまたは複数の読み出しに対応する前記それぞれの読み出し記述子を受
信することと、
前記クライアント側コンポーネントがアクセス可能な１つまたは複数のバッファに、前
記異種格納グループの特定データストアを対象とする第１書き込みの第１書き込み記述子
を含む、１つまたは複数の書き込みのそれぞれの書き込み記述子を格納することであって
、前記第１書き込みのペイロードは前記第１読み出しの結果に少なくとも部分的に基づき
、前記第１書き込み記述子は前記特定データストアにて変更するオブジェクトを示す、前
記１つまたは複数の書き込みの前記それぞれの書き込み記述子を格納することと、
前記クライアント側コンポーネントにて、前記１つまたは複数の書き込みを含む候補ト
ランザクションに対するコミット要求を生成することであって、前記コミット要求は少な
くとも前記第１読み出し記述子と前記第１書き込み記述子とを含む、前記１つまたは複数
の書き込みを含む前記候補トランザクションに対する前記コミット要求を生成することと
、
前記クライアント側コンポーネントからトランザクションマネジャーに対し、前記コミ
ット要求を送信することと、
前記トランザクションマネジャーにて、並行処理制御プロトコルに従った前記第１読み
出し記述子の分析に少なくとも部分的に基づいて、前記候補トランザクションがコミット
のために受諾されることを決定することと、
前記第１書き込み記述子内に示される前記オブジェクトの変更を開始することと、
を実行するように構成される、前記システム。

２．前記クライアント側コンポーネントは、プロバイダネットワークにて実施される格
納サービスの要求ハンドラノードを実行するプロセスを有する、条項１に記載のシステム
。

３．前記第１読み出し記述子は、少なくとも前記第１読み出しの読み出し再現性検証メ
タデータを含む、条項１に記載のシステム。

４．前記コミット要求は前記第２データストアを対象とする第２読み出しに対応する第
２読み出し記述子を含み、前記１つまたは複数の書き込みのうち少なくとも１つの書き込
みのペイロードは前記第２読み出しの結果に少なくとも部分的に基づく、条項１に記載の
システム。

５．前記１つまたは複数の書き込みは、前記特定データストアとは異なるデータストア
を対象とする第２書き込みを含む、条項１に記載のシステム。

６．１つまたは複数のコンピューティングデバイスにより、
第１データストアを含む１つまたは複数のデータストアを備える格納グループのクライ
アント側コンポーネントにて、前記第１データストアを対象とする第１読み出しに対応す
る第１読み出し記述子を含む、１つまたは複数の読み出しに対応するそれぞれの読み出し
記述子を受信することであって、前記第１読み出し記述子は前記第１データストアにて適
用されたステート遷移の開示を含む、前記１つまたは複数の読み出しに対応する前記それ
ぞれの読み出し記述子を受信することと、
前記クライアント側コンポーネントにて、前記１つまたは複数のデータストアのうちの
特定データストアを対象とする第１書き込みの第１書き込み記述子を含む、１つまたは複
数の書き込みのそれぞれの書き込み記述子を生成することであって、前記第１書き込みの
ペイロードは前記第１読み出しの結果に少なくとも部分的に基づき、前記第１書き込み記
述子は前記特定データストアにて変更するオブジェクトを示す、前記１つまたは複数の書
き込みの前記それぞれの書き込み記述子を生成することと、
前記クライアント側コンポーネントからトランザクションマネジャーに対し、前記第１
書き込みを含む１つまたは複数の書き込みを有する候補トランザクションに対するコミッ
ト要求を送信することであって、前記コミット要求は少なくとも前記第１読み出し記述子
と前記第１書き込み記述子とを含む、前記１つまたは複数の書き込みを有する前記候補ト
ランザクションに対する前記コミット要求を送信することと、
前記トランザクションマネジャーにて、前記第１読み出し記述子の分析に少なくとも部
分的に基づいて、前記候補トランザクションがコミットのために受諾されることを決定す
ることと
を含む方法。

７．ステートレスプロトコルに従って前記第１データストアは、前記第１読み出し記述
子が前記クライアント側コンポーネントに提供された後、前記第１読み出しに関するセッ
ションメタデータを保持しない、条項６に記載の方法。

８．前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記トランザクションマネジャーの持続的ログに、前記候補トランザクションがコミッ
トのために受諾されたことを示すトランザクションレコードを格納することを含み、
前記候補トランザクションがコミットのために受諾されることの前記決定は、前記持続
的ログに格納された１つまたは複数の他のトランザクションレコードの分析に少なくとも
部分的に基づく、
条項６に記載の方法。

９．前記持続的ログは複製グラフの複数のノードを使用して実施される、条項８に記載
の方法。

１０．前記候補トランザクションがコミットのために受諾されることの前記決定は、前
記読み出し記述子が生成されてから前記第１読み出しの結果集合は変更されていないこと
を確認することを含む、条項６に記載の方法。

１１．前記特定ステート遷移の前記開示は、論理タイムスタンプを含む、条項６に記載
の方法。

１２．前記第１読み出し記述子は、少なくとも前記第１読み出しの読み出し再現性検証
メタデータを含む、条項６に記載の方法。

１３．前記１つまたは複数のデータストアは第２データストアを有し、前記第１データ
ストアは第１データモデルを実施し、前記第２データストアは別のデータモデルを実施し
、前記コミット要求は前記第２データストアを対象とする第２読み出しに対応する第２読
み出し記述子を含み、前記１つまたは複数の書き込みのうち少なくとも１つの書き込みの
ペイロードは前記第２読み出しの結果に少なくとも部分的に基づく、条項６に記載の方法
。

１４．前記第１データストアは、非リレーショナルデータベースシステム、リレーショ
ナルデータベースシステム、非構造化データオブジェクトへのアクセスを可能にするウェ
ブサービスインターフェースを実施する格納サービス、インメモリデータベース、分散キ
ャッシュのインスタンス、待ち行列サービスのコンポーネント、または通知サービスのコ
ンポーネント、以上のうちの１つを含む、条項１２に記載の方法。

１５．前記第１データストアは複数の書き込みを含むトランザクションの原子性に対応
しない、条項６に記載の方法。

１６．プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって
、前記プログラム命令が１つまたは複数のプロセッサにおいて実行されると、前記１つま
たは複数のプロセッサは、
第１データストアを含む１つまたは複数のデータストアを備える格納グループのクライ
アント側コンポーネントにて、前記第１データストアを対象とする第１読み出しに対応す
る第１読み出し記述子を含む、１つまたは複数の読み出しに対応するそれぞれの読み出し
記述子を受信することであって、前記第１読み出し記述子は前記第１データストアにて適
用されたステート遷移の開示を含む、前記１つまたは複数の読み出しに対応する前記それ
ぞれの読み出し記述子を受信することと、
前記クライアント側コンポーネントにて、前記１つまたは複数のデータストアのうちの
特定データストアを対象とする第１書き込みの第１書き込み記述子を含む、１つまたは複
数の書き込みのそれぞれの書き込み記述子を生成することであって、前記第１書き込みの
ペイロードは前記第１読み出しの結果に少なくとも部分的に基づき、前記第１書き込み記
述子は前記特定データストアにて変更するオブジェクトを示す、前記１つまたは複数の書
き込みの前記それぞれの書き込み記述子を生成することと、
前記クライアント側コンポーネントからトランザクションマネジャーに対し、前記第１
書き込みを含む１つまたは複数の書き込みを有する候補トランザクションに対するコミッ
ト要求を送信することであって、前記コミット要求は少なくとも前記第１読み出し記述子
と前記第１書き込み記述子とを含む、前記１つまたは複数の書き込みを有する前記候補ト
ランザクションに対する前記コミット要求を送信することと
を実行する、前記非一時的コンピュータアクセス可能記憶媒体。

１７．ステートレスプロトコルに従って前記第１データストアは、前記第１読み出しに
関するセッションメタデータを保持しない、条項１６に記載の非一時的コンピュータアク
セス可能記憶媒体。

１８．前記第１読み出し記述子は、少なくとも前記第１読み出しの読み出し再現性検証
メタデータを含む、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。

１９．前記１つまたは複数のデータストアは第２データストアを有し、前記第１データ
ストアは第１データモデルを実施し、前記第２データストアは別のデータモデルを実施し
、前記コミット要求は前記第２データストアを対象とする第２読み出しに対応する第２読
み出し記述子を含み、前記１つまたは複数の書き込みのうち少なくとも１つの書き込みの
ペイロードは前記第２読み出しの結果に少なくとも部分的に基づく、条項１６に記載の非
一時的コンピュータアクセス可能記憶媒体。

２０．前記第１データストアは複数の書き込みを含むトランザクションの原子性に対応
しない、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。

さらに、前述の内容は、以下の追加条項を考慮することでより理解され得る。
１．１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記１
つまたは複数のコンピューティングデバイスは、
異種格納グループの複数のデータストアの第１データストアを対象とする第１読み出し
要求を受信することであって、前記第１読み出し要求は第１結果集合を特定するために使
用する第１フィルタ基準を含む、前記第１読み出し要求を受信することと、
特定ステート遷移のインジケータを確定することであって、前記特定ステート遷移は、
前記第１結果集合の特定の前に前記第１データストアに適用された１つまたは複数の変更
を含む、前記特定ステート遷移の前記インジケータを確定することと、
前記第１フィルタ基準を使用して前記第１結果集合を特定することと、
（ａ）前記特定ステート遷移の前記インジケータと、（ｂ）前記第１読み出し要求が再
現可能な読み出しを表すか否かを判定するために利用可能な読み出し再現性検証メタデー
タ（ＲＲＶＭ）と、を含む読み出し記述子を生成することと、
前記第１結果集合と前記読み出し記述子の表現とを、前記異種格納グループのクライア
ント側コンポーネントへ送信することと、
前記読み出し記述子の分析に少なくとも部分的に基づいて、前記第１読み出し要求に続
く前記異種格納グループの特定データストアを対象とする書き込み要求が受諾基準を満た
すと判定することと、
を実行するように構成される、前記システム。

２．前記ＲＲＶＭは前記第１フィルタ基準の表現を含む、条項１に記載のシステム。

３．前記ＲＲＶＭは前記第１結果集合に含まれるデータオブジェクトのアドレスに少な
くとも部分的に基づく、条項１に記載のシステム。

４．前記読み出し記述子の前記表現は、前記読み出し記述子の難読化版を含む、条項１
に記載のシステム。

５．１つまたは複数のコンピューティングデバイスにより、
第１データストアを対象とする第１読み出し要求を受信することと、
特定ステート遷移のインジケータを確定することであって、前記特定ステート遷移は、
前記第１読み出し要求の第１結果集合の特定の前に前記第１データストアに適用された１
つまたは複数の変更を含む、前記特定ステート遷移の前記インジケータを確定することと
、
（ａ）前記特定ステート遷移の前記インジケータと、（ｂ）前記第１読み出し要求が再
現可能な読み出しを表すか否かを判定するために利用可能な読み出し再現性検証メタデー
タ（ＲＲＶＭ）と、を含む読み出し記述子を生成することと、
前記第１読み出し要求に応じて、少なくとも前記読み出し記述子の表現と前記第１結果
集合とを特定送信先へ送信することと、
を含む方法。

６．前記ＲＲＶＭは、前記読み出し要求内に示される選択基準の表現を含む、条項５に
記載の方法。

７．前記ＲＲＶＭは、前記第１読み出し要求の再現が前記第１結果集合とは異なる結果
集合を生じるか否かを判定するために呼び出す関数の表現を含む、条項５に記載の方法。

８．前記ＲＲＶＭは、前記第１結果集合に含まれるデータオブジェクトのアドレスに少
なくとも部分的に基づく、条項５に記載の方法。

９．前記ＲＲＶＭは、前記第１結果集合に含まれるデータオブジェクトの前記アドレス
に適用された選択ハッシュ関数の出力を含む、条項５に記載の方法。

１０．前記特定ステート遷移の前記開示は、論理タイムスタンプを含む、条項５に記載
の方法。

１１．前記読み出し記述子は、前記第１結果集合のデータオブジェクトの最終変更時間
の開示を含む、条項５に記載の方法。

１２．前記読み出し記述子は前記第１データストアのテーブルの最終変更時間の開示を
含み、前記テーブルは前記第１結果集合の１つまたは複数のデータオブジェクトを含む、
条項５に記載の方法。

１３．前記読み出し記述子の前記表現は、前記読み出し記述子の難読化版を含む、条項
５に記載の方法。

１４．前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記読み出し記述子の前記表現に組み込むパディングバイト数を決定することであって
、前記決定は乱数演算を使用することを含む、前記読み出し記述子の前記表現に組み込む
前記パディングバイト数を決定することと、
前記読み出し記述子の前記表現の前記送信の前に、前記読み出し記述子の前記表現内に
前記パディングバイト数を組み込むことと、
を含む条項５に記載の方法。

１５．プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって
、前記プログラム命令が１つまたは複数のプロセッサにおいて実行されると、前記１つま
たは複数のプロセッサは、
格納グループの第１データストアに対する読み出し要求に応じて、前記読み出し要求の
第１結果集合の生成の前に前記第１データストアにて適用された変更に対応する特定ステ
ート遷移のインジケータを確定し、
（ａ）前記特定ステート遷移の開示と、（ｂ）前記第１読み出し要求が再現可能な読み
出しを表すか否かを判定するために利用可能な読み出し再現性検証メタデータ（ＲＲＶＭ
）と、を含む読み出し記述子を生成し、
前記格納グループのクライアント側コンポーネントに対し、前記読み出し記述子と、前
記第１結果集合との送信を開始する、
前記非一時的コンピュータアクセス可能記憶媒体。

１６．前記ＲＲＶＭは、前記読み出し要求内に示される選択基準の表現を含む、条項１
５に記載の非一時的コンピュータアクセス可能記憶媒体。

１７．前記ＲＲＶＭは、前記読み出し要求の再現が前記第１結果集合とは異なる結果集
合を生じるか否かを判定するために呼び出す関数の表現を含む、条項１５に記載の非一時
的コンピュータアクセス可能記憶媒体。

１８．前記ＲＲＶＭは、前記第１結果集合に含まれるデータオブジェクトのアドレスに
少なくとも部分的に基づく、条項１５に記載の非一時的コンピュータアクセス可能記憶媒
体。

１９．前記特定ステート遷移の前記開示は、論理タイムスタンプを含む、条項１５に記
載の非一時的コンピュータアクセス可能記憶媒体。

結論
様々な実施形態はさらに、コンピュータアクセス可能媒体に関する前述の説明に従って
実行される命令及び／またはデータの受信、送信、または格納処理を含み得る。一般に、
コンピュータアクセス可能媒体は、例えばディスクまたはＤＶＤ／ＣＤ‐ＲＯＭ、ＲＡＭ
（例えばＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発性または不揮
発性媒体といった、磁気または光学式媒体等の記憶媒体またはメモリ媒体、並びに、ネッ
トワーク及び／または無線リンク等の通信媒体を介して伝達される伝送媒体または電気、
電磁、もしくはデジタル信号等の信号を含み得る。

本明細書において図示及び説明される様々な方法は、方法の例示的実施形態を表す。方
法は、ソフトウェア、ハードウェア、またはこれらの組み合せで実施され得る。方法の順
序は変更され、そして様々な要素が追加、並替、結合、省略、変更等され得る。

本開示の恩恵を受ける当業者には明らかであるように、様々な修正及び変更を行うこと
が可能である。本明細書には全てのこのような修正及び変更を包含する意図があり、従っ
て前述の説明も制限的な意味ではなく例示的な意味で考慮されるものとする。

Claims (15)

1. コンピューティングデバイスであって、
   格納グループの書き込みアプライヤを実行するよう構成される１つまたは複数のプロセッサを備え、
   前記書き込みアプライヤは、
   前記格納グループのログベーストランザクションマネジャーにより持続的ログ内に格納された特定レコードが、前記格納グループの第１パーティションを対象とする第１書き込みの条件付きコミットを表すことを特定し、前記特定レコードは、他のトランザクションのために前記持続的ログ内に格納された他のレコードに基づく、前記第１書き込みとの読み出し書き込み競合が検出されないとの前記ログベーストランザクションマネジャーによる判定の後、前記持続的ログ内に格納されたものであり、
   第１パーティションを対象とする１つまたは複数の書き込みを含む複数パーティショントランザクションの無条件コミットレコードを格納するように指定されたコミット判定レポジトリを特定し、
   前記第１書き込みを含む第１複数パーティショントランザクションの無条件コミットレコードを前記コミット判定レポジトリが含むことの特定に応じて、前記格納グループの前記第１パーティションに対し前記第１書き込みを伝播する、
   ように構成される、コンピューティングデバイス。
2. 前記書き込みアプライヤは、
   第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定し、
   前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定し、
   前記タイムアウトの経過前に前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないこと、の検出に少なくとも部分的に基づいて、前記第１パーティションに対する前記第２書き込みの伝播を破棄する、
   ように構成される、請求項１に記載のコンピューティングデバイス。
3. 前記書き込みアプライヤは、
   前記持続的ログ内に格納された第２レコードが、前記第１パーティションを対象とする第２書き込みの無条件コミットを表すことを特定し、
   前記コミット判定レポジトリを調べることなく、前記第１パーティションに対し前記第２書き込みを伝播する、
   ように構成される、請求項１に記載のコンピューティングデバイス。
4. 前記書き込みアプライヤは、
   第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定し、
   前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定し、
   前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないことと、前記タイムアウトが経過しないことの特定に応じて、時間間隔を待ち、
   前記時間間隔後、前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていることを特定し、
   前記格納グループの前記第１パーティションに対し前記第２書き込みを伝播する、
   ように構成される、請求項１に記載のコンピューティングデバイス。
5. 前記書き込みアプライヤは、
   第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定し、
   前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定し、
   前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないことと、前記タイムアウトが経過しないことの特定に応じて、時間間隔を待ち、
   前記時間間隔後、前記タイムアウトが経過したことを特定し又は前記第２複数パーティショントランザクションに対応するアボートレコードを特定し、
   前記第１パーティションに対する前記第２書き込みの伝播を破棄する、
   ように構成される、請求項１に記載のコンピューティングデバイス。
6. １つまたは複数のプロセッサにより、
   格納グループのログベーストランザクションマネジャーにより持続的ログ内に格納された特定レコードが、前記格納グループの第１パーティションを対象とする第１書き込みの条件付きコミットを表すことを特定することであって、前記特定レコードは、他のトランザクションのために前記持続的ログ内に格納された他のレコードに基づく、前記第１書き込みとの読み出し書き込み競合が検出されないとの前記ログベーストランザクションマネジャーによる判定の後、前記持続的ログ内に格納されたものである、前記特定することと、
   第１パーティションを対象とする１つまたは複数の書き込みを含む複数パーティショントランザクションの無条件コミットレコードを格納するように指定されたコミット判定レポジトリを特定することと、
   前記第１書き込みを含む第１複数パーティショントランザクションの無条件コミットレコードを前記コミット判定レポジトリが含むことの特定に応じて、前記格納グループの前記第１パーティションに対し前記第１書き込みを伝播すること、
   を実行することを含む方法。
7. 第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定することと、
   前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定することと、
   前記タイムアウトの経過前に前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないこと、の検出に少なくとも部分的に基づいて、前記第１パーティションに対する前記第２書き込みの伝播を破棄すること、
   を更に含む、請求項６に記載の方法。
8. 前記持続的ログ内に格納された第２レコードが、前記第１パーティションを対象とする第２書き込みの無条件コミットを表すことを特定することと、
   前記コミット判定レポジトリを調べることなく、前記第１パーティションに対し前記第２書き込みを伝播すること、
   を更に含む、請求項６に記載の方法。
9. 第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定することと、
   前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定することと、
   前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないことと、前記タイムアウトが経過しないことの特定に応じて、時間間隔を待つことと、
   前記時間間隔後、前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていることを特定することと、
   前記格納グループの前記第１パーティションに対し前記第２書き込みを伝播すること、
   を更に含む、請求項６に記載の方法。
10. 第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定することと、
    前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定することと、
    前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないことと、前記タイムアウトが経過しないことの特定に応じて、時間間隔を待つことと、
    前記時間間隔後、前記タイムアウトが経過したことを特定し又は前記第２複数パーティショントランザクションに対応するアボートレコードを特定することと、
    前記第１パーティションに対する前記第２書き込みの伝播を破棄すること、
    を更に含む、請求項６に記載の方法。
11. 第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定することと、
    前記第２複数パーティショントランザクションに対応するアボートレコードを特定することと、
    前記第１パーティションに対する前記第２書き込みの伝播を破棄すること、
    を更に含む、請求項６に記載の方法。
12. プログラム命令を記憶するコンピュータアクセス可能記憶媒体であって、前記プログラム命令は１つまたは複数のプロセッサ上で実行されると、格納グループの書き込みアプライヤを実行し、前記書き込みアプライヤは、
    前記格納グループのログベーストランザクションマネジャーにより持続的ログ内に格納された特定レコードが、前記格納グループの第１パーティションを対象とする第１書き込みの条件付きコミットを表すことを特定し、前記特定レコードは、他のトランザクションのために前記持続的ログ内に格納された他のレコードに基づく、前記第１書き込みとの読み出し書き込み競合が検出されないとの前記ログベーストランザクションマネジャーによる判定の後、前記持続的ログ内に格納されたものであり、
    第１パーティションを対象とする１つまたは複数の書き込みを含む複数パーティショントランザクションの無条件コミットレコードを格納するように指定されたコミット判定レポジトリを特定し、
    前記第１書き込みを含む第１複数パーティショントランザクションの無条件コミットレコードを前記コミット判定レポジトリが含むことの特定に応じて、前記格納グループの前記第１パーティションに対し前記第１書き込みを伝播する、
    ように構成される、コンピュータアクセス可能記憶媒体。
13. 前記書き込みアプライヤは、
    第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定し、
    前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定し、
    前記タイムアウトの経過前に前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないこと、の検出に少なくとも部分的に基づいて、前記第１パーティションに対する前記第２書き込みの伝播を破棄する、
    ように構成される、請求項１２に記載のコンピュータアクセス可能記憶媒体。
14. 前記書き込みアプライヤは、
    前記持続的ログ内に格納された第２レコードが、前記第１パーティションを対象とする第２書き込みの無条件コミットを表すことを特定し、
    前記コミット判定レポジトリを調べることなく、前記第１パーティションに対し前記第２書き込みを伝播する、
    ように構成される、請求項１２に記載のコンピュータアクセス可能記憶媒体。
15. 前記書き込みアプライヤは、
    第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定し、
    前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定し、
    前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないことと、前記タイムアウトが経過しないことの特定に応じて、時間間隔を待ち、
    前記時間間隔後、前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていることを特定し、
    前記格納グループの前記第１パーティションに対し前記第２書き込みを伝播する、
    ように構成される、請求項１２に記載のコンピュータアクセス可能記憶媒体。

Images