(57)【特許請求の範囲】
【請求項１】
１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記１つまたは複数のコンピューティングデバイスは、
第１ログベーストランザクションマネジャー（ＬＴＭ）にて、格納グループのクライアント側コンポーネントから、第１複数パーティショントランザクションの第１書き込みに対する第１コミット要求を受信することであって、前記第１書き込みは前記第１コミット要求内に示される第１読み出しの結果に依存し、前記第１読み出しは前記格納グループの第１パーティションを対象とした、前記第１複数パーティショントランザクションの前記第１書き込みに対する前記第１コミット要求を受信することと、
第２ＬＴＭにて、前記クライアント側コンポーネントから、前記第１複数パーティショントランザクションの第２書き込みに対する第２コミット要求を受信することであって、前記第２書き込みは前記第２コミット要求内に示される第２読み出しの結果に依存し、前記第２読み出しは前記格納グループの第２パーティションを対象とした、前記第１複数パーティショントランザクションの前記第２書き込みに対する前記第２コミット要求を受信することと、
前記第１ＬＴＭの第１持続的ログ内に、前記第１読み出しと前記第１持続的ログ内に記録されている書き込みの第１部分集合との間の読み出し書き込み競合に関して前記第１書き込みはコミット可能であることを示す、前記第１書き込みに対応する第１条件付きコミットレコードを格納することであって、前記第１条件付きコミットレコードは前記第１複数パーティショントランザクションに関するメタデータを含む、前記第１書き込みに対応する前記第１条件付きコミットレコードを格納することと、
前記第２ＬＴＭの第２持続的ログ内に、前記第２読み出しと前記第２持続的ログ内に記録されている書き込みの第２部分集合との間の読み出し書き込み競合に関して前記第２書き込みはコミット可能であることを示す、前記第２書き込みに対応する第２条件付きコミットレコードを格納することであって、前記第２条件付きコミットレコードは前記第１複数パーティショントランザクションに関する前記メタデータを含む、前記第２書き込みに対応する前記第２条件付きコミットレコードを格納することと、
（ａ）前記第１条件付きコミットレコードが格納され、かつ（ｂ）前記第２条件付きコミットレコードが格納されたことの特定に応じて、前記クライアント側コンポーネントにより、前記第１複数パーティショントランザクションに対応する第１無条件コミットレコードを、複数パーティションコミット判定レポジトリ（ＭＣＤＲ）に格納することと、
（ａ）前記第１条件付きコミットレコードに含まれる前記第１複数パーティショントランザクションに関する前記メタデータの調査と、（ｂ）前記第１無条件コミットレコードの調査と、に応じて、前記格納グループの特定パーティションに対応付けられた第１書き込みアプライヤにより、前記特定パーティションに対し前記第１書き込みを伝播することと、
を実行するように構成される、システム。
【請求項２】
前記１つまたは複数のコンピューティングデバイスはさらに、
前記第１ＬＴＭにて、別の複数パーティショントランザクションの第３書き込みに対する第３コミット要求を受信することであって、前記第３書き込みは前記第１パーティションを対象とし、前記第３コミット要求は前記別の複数パーティショントランザクションのタイムアウトの表現を含む、前記別の複数パーティショントランザクションの前記第３書き込みに対する前記第３コミット要求を受信することと、
前記第１持続的ログ内に、読み出し書き込み競合に関して前記第３書き込みがコミット可能であることを示す、前記第３書き込みに対応する第３条件付きコミットレコードを格納することと、
前記タイムアウトの経過後、前記別の複数パーティショントランザクションに対応する第２無条件コミットレコードが前記ＭＣＤＲに格納されていないことを検出することと、
前記第１パーティションに対する前記第３書き込みの伝播は実施しないことを決定することと、
を実行するように構成される、請求項１に記載のシステム。
【請求項３】
前記第１コミット要求は前記ＭＣＤＲの指示を含み、前記第１複数パーティショントランザクションに関する前記メタデータは前記ＭＣＤＲの前記指示を含む、請求項１に記載のシステム。
【請求項４】
前記１つまたは複数のコンピューティングデバイスはさらに、
前記第１コミット要求の前に、前記格納グループに対する１つまたは複数の種類の動作の目標性能レベルの指示を受信し、
（ａ）前記格納グループのために確立すべきＬＴＭの数、（ｂ）前記格納グループのために確立すべきＭＣＤＲの数、または（ｃ）前記格納グループのために確立すべき書き込みアプライヤの数、以上のうちの１つまたは複数を、前記目標性能レベルの前記指示に少なくとも部分的に基づいて決定する、
ように構成される、請求項１に記載のシステム。
【請求項５】
前記第１パーティションは前記格納グループのマスタパーティションに指定され、前記第１持続的ログは第１サーバの１つまたは複数の格納デバイスの少なくとも第１部分を備え、前記ＭＣＤＲは前記第１サーバの前記１つまたは複数の格納デバイスの少なくとも第２部分を備える、請求項１に記載のシステム。
【請求項６】
１つまたは複数のコンピューティングデバイスにより、
格納グループの第１ログベーストランザクションマネジャー（ＬＴＭ）の第１持続的ログ内に、前記第１ＬＴＭにより行われた第１競合検出分析に少なくとも部分的に基づいて第１書き込みがコミット可能であると指定されたことを示す、第１複数パーティショントランザクションの前記第１書き込みに対応する第１条件付きコミットレコードを格納することと、
前記格納グループの第２ＬＴＭの第２持続的ログ内に、前記第２ＬＴＭにより行われた第２競合検出分析に少なくとも部分的に基づいて第２書き込みがコミット可能であると指定されたことを示す、前記第１複数パーティショントランザクションの前記第２書き込みに対応する第２条件付きコミットレコードを格納することと、
前記第１及び第２書き込みがコミット可能であると指定されたことの検出に応じて、前記第１複数パーティショントランザクションに対応する第１無条件コミットレコードを格納することと、
（ａ）前記第１条件付きコミットレコードの調査と、（ｂ）前記第１無条件コミットレコードの調査とに応じて、第１書き込みアプライヤにより前記格納グループの特定パーティションに対し前記第１書き込みを伝播することと、
を含む方法。
【請求項７】
前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記第１ＬＴＭにて、別の複数パーティショントランザクションの別の書き込みに対するコミット要求を受信することであって、前記別の書き込みは第１パーティションを対象とし、前記コミット要求は前記別の複数パーティショントランザクションのタイムアウトの表現を含む、前記別の複数パーティショントランザクションの前記別の書き込みに対する前記コミット要求を受信することと、
前記第１持続的ログ内に、前記第１ＬＴＭにより行われた第３競合検出分析に少なくとも部分的に基づいて前記別の書き込みがコミット可能であることを示す、前記別の書き込みに対応する第３条件付きコミットレコードを格納することと、
前記タイムアウトの経過後、前記別の複数パーティショントランザクションに対応する第２無条件コミットレコードが複数パーティションコミット判定レポジトリ（ＭＣＤＲ）に格納されていないことを検出することと、
前記第１パーティションに対する前記別の書き込みの伝播は実施しないことを決定することと、
を含む請求項６に記載の方法。
【請求項８】
前記ＭＣＤＲは単調に増加する論理タイムスタンプ値を提供する関連論理クロックを有し、前記タイムアウトは前記関連論理クロックから取得が見込まれる特定の将来論理タイムスタンプ値を含む、請求項７に記載の方法。
【請求項９】
前記第１書き込みに対する第１コミット要求に応じて前記第１条件付きコミットレコードは格納され、前記第２書き込みに対する第２コミット要求に応じて前記第２条件付きコミット要求は格納され、前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記第１ＬＴＭにて、第２複数パーティショントランザクションの第３書き込みに対する第３コミット要求を受信することであって、前記第３書き込みは第１パーティションを対象とする第３読み出しの結果に依存する、前記第２複数パーティショントランザクションの前記第３書き込みに対する前記第３コミット要求を受信することと、
前記第２ＬＴＭにて、前記第２複数パーティショントランザクションの第４書き込みに対する第４コミット要求を受信することであって、前記第４書き込みは第２パーティションを対象とする第４読み出しの結果に依存する、前記第２複数パーティショントランザクションの前記第４書き込みに対する前記第４コミット要求を受信することと、
前記第１持続的ログ内に、前記第１ＬＴＭにより行われた第３競合検出分析に少なくとも部分的に基づいて前記第３書き込みがコミット可能であることを示す、前記第３書き込みに対応する第３条件付きコミットレコードを格納することと、
前記第２ＬＴＭにより検出された特定の競合に少なくとも部分的に基づいて、前記第２ＬＴＭにより前記第４コミット要求は拒否されたことを特定することと、
前記第４コミット要求が拒否されたことの開示に応じて、前記第３書き込みの伝播を破棄することと、
を含む請求項６に記載の方法。
【請求項１０】
前記第１ＬＴＭにて前記格納グループのクライアント側コンポーネントから受信された第１コミット要求に応じて前記第１条件付きコミットレコードは格納され、前記第１無条件コミットレコードの前記格納は前記クライアント側コンポーネントにより行われる、請求項６に記載の方法。
【請求項１１】
前記第１コミット要求は第１読み出しの開示を含み、前記第１書き込みは前記第１読み出しの結果に依存し、前記第１読み出しの前記開示は前記第１ＬＴＭにより前記第１競合検出分析を行うために使用される、請求項１０に記載の方法。
【請求項１２】
前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記格納グループに対する１つまたは複数の種類の動作の目標性能レベルの指示を受信することと、
（ａ）前記格納グループのために確立すべきＬＴＭの数、（ｂ）前記格納グループのために確立すべき複数パーティションコミット判定レポジトリの数、または（ｃ）前記格納グループのために確立すべき書き込みアプライヤの数、以上のうちの１つまたは複数を、前記目標性能レベルの前記指示に少なくとも部分的に基づいて決定することと、
を含む請求項６に記載の方法。
【請求項１３】
第１パーティションは前記格納グループのマスタパーティションに指定され、前記第１持続的ログは第１サーバの１つまたは複数の格納デバイスの少なくとも第１部分を備え、前記第１無条件コミットレコードは前記１つまたは複数の格納デバイスのうちの特定格納デバイスに格納される、請求項６に記載の方法。
【請求項１４】
前記第１無条件コミットレコードは、第１ノード及び第２ノードを含む複製有向非巡回グラフの複数のノードを備える複数パーティションコミット判定レポジトリ（ＭＣＤＲ）に格納され、前記第１無条件コミットレコードの前記格納は、前記第１ノード及び前記第２ノードに前記第１無条件コミットレコードのそれぞれのレプリカを格納することを含む、請求項６に記載の方法。
【請求項１５】
１つまたは複数のプロセッサと、
プログラム命令を記憶する１つまたは複数のメモリと、
を含むシステムであって、前記プログラム命令は前記１つまたは複数のプロセッサ上で実行されると、格納グループのクライアント側コンポーネントを実行し、前記クライアント側コンポーネントは、
格納グループの第１ログベーストランザクションマネジャー（ＬＴＭ）へ、第１複数パーティショントランザクションの第１書き込みに対する第１コミット要求を送信することであって、前記第１コミット要求は前記第１書き込みが依存する第１読み出しの開示を含み、前記第１読み出しは前記格納グループの第１パーティションを対象とした、前記第１複数パーティショントランザクションの前記第１書き込みに対する前記第１コミット要求を送信することと、
前記格納グループの第２ログベーストランザクションマネジャー（ＬＴＭ）へ、第１複数パーティショントランザクションの第２書き込みに対する第２コミット要求を送信することであって、前記第２コミット要求は前記第２書き込みが依存する第２読み出しの開示を含み、前記第２読み出しは前記格納グループの第２パーティションを対象とした、前記第１複数パーティショントランザクションの前記第２書き込みに対する前記第２コミット要求を送信することと、
（ａ）第１コミット分析に少なくとも部分的に基づいて前記第１ＬＴＭにより前記第１書き込みはコミット可能であると指定され、かつ（ｂ）第２コミット分析に少なくとも部分的に基づいて前記第２ＬＴＭにより前記第２書き込みはコミット可能であると指定されたことの特定に応じて、前記第１複数パーティショントランザクションに対応する第１無条件コミットレコードを選択位置に格納することと、
を実行するように構成される、システム。
【発明の詳細な説明】
【背景技術】
【０００１】
近年、ますます多くのコンピューティングアプリケーションが分散環境において実施されている。所定の分散アプリケーションは、例えば、プロバイダネットワークのいくつかのデータセンタに分散された多数の物理及び／または仮想サーバを利用し、数多くの異なる国の顧客に応対し得る。所定のアプリケーションに関わるサーバの数が増える程、及び／またはアプリケーションのネットワークの複雑さが増す程、様々な種類の障害イベント（プロセスまたはサーバの見かけ上または実際の障害、ネットワークメッセージレイテンシにおける実質的遅延、または対のサーバ間の接続損失等）に必然的に遭遇する割合は高くなる。そのため分散アプリケーションの設計者は、アプリケーション構成ステートの変更に応じると同時に、高いレベルのアプリケーション性能（例えばアプリケーション要求に対する高スループット及び低応答時間）の維持を試みるという課題に直面する。
【０００２】
ステート情報を管理するためのいくつかの従来技術は、整合的にアプリケーションステート変更を実施するために、ステート情報をロックすることを伴い得る。あいにくアプリケーションステート及び／またはデータに使われるロック機構は、アプリケーションのサイズ及び複雑さが増大すると、それ自体が性能障害となり得ることが多い。他の技術はロックを回避し得るが、アプリケーションのコンポーネント間に変更されたステート情報を伝播するために、通常動作を中断する必要があり得る。しかしながら、このような「全世界停止」期間は、特に世界中の異なる時間帯に分布する数百または数千の顧客によるミッションクリティカルな作業負荷に使用される、レイテンシに敏感なアプリケーションには、問題となり得る。ロック及び全世界一時停止を回避するいくつかの技術でも、非常に高いレートのステート遷移を扱う時には、障害に陥り得る。
【図面の簡単な説明】
【０００３】
【図１】少なくともいくつかの実施形態による、アプリケーションステート変更を管理するために複製ノードの動的ＤＡＧ（有向非巡回グラフ）が確立された例示的システム環境を示す。
【図２ａ】少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。
【図２ｂ】少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。
【図２ｃ】少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。
【図２ｄ】少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。
【図２ｅ】少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。
【図２ｆ】少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。
【図２ｇ】少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。
【図２ｈ】少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を集合的に示す。
【図３】少なくともいくつかの実施形態による、動的複製ＤＡＧにて生成され得るアプリケーションステートレコードとＤＡＧ構成デルタメッセージとの例示的コンポーネントを示す。
【図４】少なくともいくつかの実施形態による、プロバイダネットワークの複数の可用性コンテナにわたりメンバーノードが分散された例示的複製ＤＡＧを示す。
【図５】少なくともいくつかの実施形態による、複数の複製ＤＡＧのノードがマルチテナント様式で単一のホストに実装され得る例示的構成を示す。
【図６】少なくともいくつかの実施形態による、ステート遷移要求の受信に応じて複製ＤＡＧの受諾ノードで行われ得る動作態様を示すフロー図である。
【図７】少なくともいくつかの実施形態による、承認済みステート遷移メッセージの受信に応じて複製ＤＡＧの中間ノードで行われ得る動作態様を示すフロー図である。
【図８】少なくともいくつかの実施形態による、承認済みステート遷移メッセージの受信に応じて複製ＤＡＧのコミッタノードで行われ得る動作態様を示すフロー図である。
【図９】少なくともいくつかの実施形態による、複製ＤＡＧの構成マネジャーで行われ得る動作態様を示すフロー図である。
【図１０】少なくともいくつかの実施形態による、構成マネジャーからの構成デルタメッセージの受信に応じて複製ＤＡＧのメンバーノードで行われ得る動作態様を示すフロー図である。
【図１１ａ】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。
【図１１ｂ】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。
【図１１ｃ】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。
【図１１ｄ】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。
【図１１ｅ】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。
【図１１ｆ】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。
【図１１ｇ】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。
【図１１ｈ】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。
【図１２】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のステート複製グループのコミッタノードで行われ得る動作態様を示すフロー図である。
【図１３】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のステート複製グループの非コミッタノードで行われ得る動作態様を示すフロー図である。
【図１４】少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のステート複製グループの構成マネジャーで行われ得る動作態様を示すフロー図である。
【図１５】少なくともいくつかの実施形態による、複数のデータストアへの書き込みを含み得るトランザクションに対応する持続的変更ログを備える例示的システム環境を示す。
【図１６】少なくともいくつかの実施形態による、複製ＤＡＧを使用する持続的変更ログの例示的実施態様を示す。
【図１７】少なくともいくつかの実施形態による、ログサービスのクライアントにより提出され得るトランザクション要求記述子の例示的コンポーネント要素を示す。
【図１８】少なくともいくつかの実施形態による、ログベーストランザクションマネジャーにおける読み出し書き込み競合検出の実施例を示す。
【図１９】少なくともいくつかの実施形態による、ログサービスで行われ得る制御プレーン動作態様を示すフロー図である。
【図２０】少なくともいくつかの実施形態による、クライアントから受信されるトランザクション要求に応じてログサービスで行われ得る動作態様を示すフロー図である。
【図２１】少なくともいくつかの実施形態による、それぞれの特例整合性目標を達成するために使用され得るトランザクション要求記述子の実施例を示す。
【図２２】少なくともいくつかの実施形態による、ログベーストランザクションマネジャーで受信されるトランザクション要求に対応付けられた重複排除制約を施行する実施例を示す。
【図２３】少なくともいくつかの実施形態による、ログベーストランザクションマネジャーで受信されるトランザクション要求に対応付けられた順序付け制約を施行する実施例を示す。
【図２４】少なくともいくつかの実施形態による、複数の論理制約記述子を含むトランザクション要求記述子の実施例を示す。
【図２５】少なくともいくつかの実施形態による、１つまたは複数の論理制約を示すトランザクション要求に応じてログサービスで行われ得る動作態様を示すフロー図である。
【図２６】少なくともいくつかの実施形態による、それぞれのログ整合格納グループに対しそれぞれの価格設定ポリシーが実施され得る例示的システム環境を示す。
【図２７】少なくともいくつかの実施形態による、単一データストア及びデータストア横断書き込み動作の実施例を示す。
【図２８】少なくともいくつかの実施形態による、ログ整合格納グループに対する価格設定ポリシーを決定する際考慮され得る要素の実施例を示す。
【図２９】少なくともいくつかの実施形態による、ログ整合格納グループを実施するサービスのユーザに対し価格設定ポリシーの選択肢を示すために使用され得る例示的ウェブベースインターフェースを示す。
【図３０】少なくともいくつかの実施形態による、ログ整合格納グループに対応するサービスにて請求額を決定するために行われ得る動作態様を示すフロー図である。
【図３１】少なくともいくつかの実施形態による、トランザクション受諾のために読み出し位置ベース競合検出を使用することによりデータ不整合が生じ得る、格納システムにおける例示的一連イベントを示す。
【図３２】少なくともいくつかの実施形態による、読み出し要求に応じて提供される読み出し記述子が読み出し再現性検証メタデータ（ＲＲＶＭ）コンポーネントを含むシステム環境を示す。
【図３３】少なくともいくつかの実施形態による、読み出し記述子の例示的構成コンポーネントを示す。
【図３４】少なくともいくつかの実施形態による、格納システムのクライアント側コンポーネントに読み出し記述子が提供される前に読み出し記述子に適用され得る例示的変換を示す。
【図３５】少なくともいくつかの実施形態による、格納システムのクライアント側コンポーネントにおいて候補トランザクションコミット要求の生成を引き起こし得る例示的一連イベントを示す。
【図３６】少なくともいくつかの実施形態による、書き込み記述子と読み出し記述子とをそれぞれのログに格納する例示的トランザクションマネジャーを示す。
【図３７】少なくともいくつかの実施形態による、読み出し要求に応じて読み出し記述子が提供される、格納システムで行われ得る動作態様を示すフロー図である。
【図３８】少なくともいくつかの実施形態による、候補トランザクション要求がクライアント側コンポーネントにて生成される、格納システムで行われ得る動作態様を示すフロー図である。
【図３９】少なくともいくつかの実施形態による、格納グループの異なるパーティションに対しそれぞれのログベーストランザクションマネジャーが確立され得る例示的システム環境を示す。
【図４０】少なくともいくつかの実施形態による、格納グループの性能ベースのトランザクション管理構成の実施例を示す。
【図４１】少なくともいくつかの実施形態による、所定のデータストアのために複数のログベーストランザクションマネジャーが確立され得る例示的構成を示す。
【図４２】少なくともいくつかの実施形態による、格納グループの主要パーティションに対し確立されるログベーストランザクションマネジャーのログと共に、複数パーティションコミット判定レポジトリが共同配置される例示的構成を示す。
【図４３】少なくともいくつかの実施形態による、複数パーティショントランザクションに対応する格納グループで生成され得るコミット要求の例示的構成要素を示す。
【図４４ａ】少なくともいくつかの実施形態による、ログベーストランザクションマネジャーにより単一パーティショントランザクションと複数パーティショントランザクションに関してそれぞれ格納され得るコミットレコードの例示的構成要素を示す。
【図４４ｂ】少なくともいくつかの実施形態による、ログベーストランザクションマネジャーにより単一パーティショントランザクションと複数パーティショントランザクションに関してそれぞれ格納され得るコミットレコードの例示的構成要素を示す。
【図４５】少なくともいくつかの実施形態による、クライアント側コンポーネントと、複数パーティショントランザクションに対応する格納グループのそれぞれのパーティションのログベーストランザクションマネジャーとにより行われ得る動作態様を示すフロー図である。
【図４６】少なくともいくつかの実施形態による、複数パーティショントランザクションに対応する格納グループの書き込みアプライヤにより行われ得る動作態様を示すフロー図である。
【図４７】少なくともいくつかの実施形態において使用され得る例示的コンピューティングデバイスを示すブロック図である。
【発明を実施するための形態】
【０００４】
本明細書において、実施形態はいくつかの例示的実施形態及び例示的図面として説明されるが、実施形態は説明される実施形態または図面に限定されないことを、当業者は認識するであろう。図面とその詳細説明には、実施形態を開示される特定の形態に限定する意図はなく、それとは逆に、添付の特許請求の範囲により定義される趣旨及び範囲に入る全ての変更、均等物、及び代替案を包含する意図があることを理解されたい。本明細書において使用される見出しは、構成目的でのみ用いられ、説明または特許請求の範囲を限定するために用いられることを意図しない。本出願を通して使用される英単語“ｍａｙ”は、義務的な意味（すなわち「〜しなければならない」という意味）ではなく、許容的な意味（すなわち「〜する可能性がある」という意味）で使用される。同様に、英単語“ｉｎｃｌｕｄｅ”、“ｉｎｃｌｕｄｉｎｇ”、及び“ｉｎｃｌｕｄｅｓ”は「含む」ことを意味するが、その対象に限定されない。
【０００５】
グラフとして体系付けられた複製ノードを使用して分散アプリケーションステートを管理する方法及び装置の様々な実施形態、及びトランザクション管理に使用され得るログサービスを実施するためにこのようなグラフを展開する方法及び装置の様々な実施形態が説明される。いくつかの実施形態によれば、フォールトトレラント分散アプリケーションを築くための複製ステートマシンは、有向非巡回グラフ（ＤＡＧ）に配置された複数の複製ノードを使用して実施され得る。いくつかの実施態様において、特定複製ＤＡＧは、１個または複数の受諾ノードと、１個または複数のコミッタノードと、受諾ノードからコミッタノードまで導くＤＡＧ辺を含む複製経路に沿ってそれぞれ配置された０個または複数の中間ノードと、ノード障害時に他の種類のノードのうちの１つの責務を素早く引き継ぐように構成された０個または複数の待機ノードとを含み得る。複製ＤＡＧの受諾、中間、及び待機ノードは、本明細書において「非コミッタ」ノードとまとめて称され得る。「受諾」、「中間」、「コミッタ」、及び「待機」は、ＤＡＧノードが担い得る役割の集合としてまとめて称され得る。いくつかの実施形態において、受諾ノードはＤＡＧの「先頭」ノードとも称され、そしてコミッタノードは「末尾」ノードとも称され得る。
【０００６】
一般に、少なくともいくつかの実施形態において、特定複製ＤＡＧの各ノードは、少なくとも特定アプリケーションのステート情報を、例えばローカルディスクまたは他の同様の格納デバイスに書き込まれるステート遷移レコードの形態で複製する責務を担い得る。アプリケーションステート情報は、本明細書において複製経路またはコミット経路と称されるＤＡＧの受諾ノードからコミッタノードまで辺の集合に沿って伝播され得る。ＤＡＧ内で伝播される各ステート遷移メッセージには、対応ステート遷移要求が（例えば受諾ノードにおいて）処理された順序を示すそれぞれのシーケンス番号または論理タイムスタンプが含まれ得る。シーケンス番号は、異なる実施形態における様々な技術のうちのいずれかを使用して実施され得る。例えば、受諾ノードにより保持される単一Ｎビットカウンタが使用され得る、あるいはＤＡＧの構成マネジャー等のＤＡＧの管理コンポーネントにより生成される単調増加論理タイムスタンプ（時刻機構に関連するとは限らない）が使用され得る。例えばステート遷移レコードの十分な数のレプリカが複製経路に沿って保存された後、特定ステート遷移レコードがコミッタノードに達すると、遷移は明示的または暗示的にコミットされ得る。ある時点でのアプリケーションのステートは、いくつかの実施形態において、選択されたシーケンス番号までの全てのコミットされたステート遷移の結果の論理的蓄積として決定され得る。構成マネジャーは、後述のように構成デルタメッセージを非同期的にＤＡＧノードへ伝播することにより、ＤＡＧ構成に対する変更を管理する責務を担い得る（例えば障害のためノードがＤＡＧから離脱する、またはＤＡＧに参加／再参加する時）。いくつかの実施形態において、各複製ノードはそれぞれの決定性有限ステートマシンを実施し、そして構成マネジャーは別の決定性有限ステートマシンを実施し得る。ＤＡＧ構成変更を管理するために使用されるプロトコルは、様々な実施形態においてＤＡＧの可用性または「活性」を最大化するように設計され得る。例えば、ＤＡＧノードは、少なくともいくつかの実施形態においてＤＡＧの構成に対するそれらの見解を同期しなくてもよいため、複製経路沿いのノードのうちのいくつかが現行のＤＡＧ構成に対して他のノードとは異なる見解を有したとしても、アプリケーションステート遷移処理に使用されるプロトコルは正常に機能し得る。従って、１つの単純な例示的シナリオにおいて、ＤＡＧがノードＡ、Ｂ、Ｃ、Ｄの順序で構成される（すなわち複製経路Ａ〜Ｂ〜Ｃ〜Ｄを伴う）という仮定の下で、ＤＡＧの１つのノードＡはそのステート遷移処理責務を実行し続ける一方、別のノードＤは、ノードＣがＤＡＧを離脱したという構成デルタメッセージ結果を既に通知されたため、ＤのＤＡＧの見解を、変更後の経路Ａ〜Ｂ〜Ｄを含むものに更新したという場合もあり得る。現行のＤＡＧ構成に関してノードの見解が異なっている可能性があるにもかかわらず、構成マネジャーは、少なくともいくつかの実施形態においてステート遷移ノードの処理を中断するようＤＡＧノードに要求しなくてもよい。従って、いくつかのステート複製技術において要求され得る種々の「全世界停止」構成同期期間は、本明細書において説明される類の複製ＤＡＧを使用する場合、必要なくなり得る。
【０００７】
大抵の作動条件の下で、ＤＡＧ構成変更情報を伝播するために使用される技術により、様々なメンバーノードにおけるＤＡＧ構成の見解は最終的に収束した一貫性のあるものとなり、同時に、ノード障害／退出、ノード参加、またはノード役割変更に伴ういずれの中断時間も最小化または削除され得る。ステート管理プロトコルの正確性に関する正式な数学的証明は、少なくともいくつかの実施形態に関して利用可能であり得る。少なくともいくつかの実施形態において、複製ＤＡＧのプロトコルは、障害誤検出に対処する際、特に有効であり得る。例えば、前述の実施例において、ノードＤは構成マネジャーにより、ノードＣに実際障害は発生していないのに、ノードＣに障害が発生したことを通知され得た。従って、誤判定障害検出の後しばらくの間、Ｃの退出を示す構成デルタメッセージがＡ、Ｂ、Ｄに受信されるまでの間隔において、ステート遷移はＣにより（及びその隣接ノードＢとＤにより）依然正しく処理されるため、ステートが複製中のアプリケーションは、障害誤検出にもかかわらず進行可能となる。ＣがＤＡＧから削除されたことが最終的に通知されると、Ｃは構成マネジャーにＣは実際にはサービス対応可能であることを示し、ＤＡＧに再参加することを許可され得る（例えば待機ノードとして、または修正された複製経路沿いのいくつかの他の位置に）。
【０００８】
いくつかの実施形態において、受諾ノードは、複製ＤＡＧのクライアントからアプリケーションステート遷移要求を受信し、最終的なコミットのために特定要求遷移を受諾するべきか否かを判定し、受諾したステート遷移レコードのローカルレプリカを格納し、受諾したステート遷移レコードをコミッタノードに向けてＤＡＧの複製経路沿いの隣接ノードへ送信する責務を担い得る。使用事例により、ステート遷移レコードは、いくつかの実施形態において書き込みペイロードを含み得る。例えばアプリケーションステートがデータベースのコンテンツを含む場合、ステート遷移レコードは、ステート遷移に該当する遷移間に書き込まれるバイトを含み得る。受諾ノードは、少なくともいくつかの実施形態において、受諾したステート遷移のシーケンス番号を決定または生成する責務も担い得る。中間ノードは、受諾済みステート遷移レコードのローカルレプリカを格納し、受諾済みステート遷移を示すメッセージを、コミッタノードに向けて経路沿いの次のノードへ送信／転送する責務を担い得る。コミッタノードは、ステート遷移レコードの自身のレプリカを、例えばレコードがコミットされたことの開示と共に、ローカル格納域に格納し得る。対応ステート遷移がコミットされたことを示すレコードは、本明細書において「コミットレコード」と称され、一方対応ステート遷移が受諾されたが必ずしも既にコミットされたとは限らないことを示すレコードは「受諾レコード」と称され得る。いくつかの実施形態において、アプリケーションの必要に応じて、コミッタノードは、ステート遷移を要求したクライアントに対し（例えば受諾ノードを介して）コミット応答の送信を開始し得る。少なくとも一実施形態において、コミッタノードは、ステート遷移がコミットされたことを、複製経路沿いの一部または全てのノードに通知し得る。いくつかの実施形態において、コミットの開示がＤＡＧノードで受信されると、コミットレコードを現在示すように、現在コミットされたステート遷移の受諾レコードは、対応コミットレコードに置き換え、または修正され得る。別の実施形態において、所定のＤＡＧノードは、同じステート遷移に関して受諾レコードとコミットレコードの両方を、例えばそれぞれのシーケンス番号と共に格納し得る。いくつかの実施態様においては、別個のコミットレコード集合と受諾レコード集合とが様々なＤＡＧノードのローカル格納域に格納され、一方別の実施態様においては、所定のステート遷移に関して１度に１種類のレコード（受諾またはコミット）のみが所定のＤＡＧノードに格納され得る。
【０００９】
構成マネジャーは、いくつかの実施形態において、ＤＡＧの構成情報の正式な情報源として設計され、ＤＡＧ構成に対する変更を受諾し、ＤＡＧノードに対する変更を伝播する責務を担い得る。少なくともいくつかの実施形態において、構成マネジャー自体は、障害に対し回復力があるように、例えばＤＡＧ構成変更（ノードの削除または追加等）を、合意を介して集合的に承認し、かつ複数の構成マネジャー格納デバイスにおいてＤＡＧ構成を複製するノードのフォールトトレラントクラスタとして、設計され得る。「構成デルタ」という名称から暗示されるように、構成マネジャーによりＤＡＧノードへ送信されるメッセージは、特定の変更（例えばＤＡＧに参加するまたはＤＡＧから離脱するノードにより生じる変更、あるいはＤＡＧの既存ノードの役割／配置に関する変更）の開示のみを含み、ＤＡＧの構成全体の表現を含まなくても、またはＤＡＧのメンバー全体を列挙しなくてもよい。構成デルタメッセージの所定の受信ノードは従って、これまで受信した特定集合または一連の構成デルタメッセージに基づいて、ＤＡＧ構成の自身の見解を構築することが見込まれ得る。いくつかの実施態様において、構成デルタメッセージにはシーケンス番号も割り当てられ、例えばこれにより、構成デルタメッセージの受信ノードは、全ての前の構成デルタメッセージを自身が受信したか否かを判定可能となる。構成マネジャーは、別個のＤＡＧノードにより構成デルタメッセージが受信される順序または相対的タイミングを保証しようと試み得ないため、いくつかの実施形態において、前述の実施例により示されるように少なくともある時間、別個のノードによりＤＡＧ構成の現行の見解は異なり得る。
【００１０】
一実施形態によれば、構成デルタメッセージに応じてＤＡＧノードが取る行動は、構成変更が受信ノードのすぐ隣のノードに影響するか否かに基づいて異なり得る。ＤＡＧが、Ｔ０時点に受諾ノードＡ、中間ノードＢ、及びコミッタノードＣを含み、初期複製経路Ａ〜Ｂ〜Ｃを有する別の例示的シナリオを検討する。Ｔ１時点に、ＤＡＧの構成マネジャーＤＣＭ１は、例えば見かけ上の障害または接続損失の結果より、ＢがＤＡＧから離脱したことを認識する。ＤＣＭ１は、ステート遷移要求処理におけるいかなる中断も要求することなく、残りのノードＡ、Ｃに対しそれぞれの非同期構成デルタメッセージＤ１、Ｄ２をそれぞれ送信し得る。ＡがＴ３時点にＤ１を受信する前に、ＣがＴ２時点にＤ２を受信する場合、ある時間間隔（Ｔ３−Ｔ２）においてＡはＢに対してステート遷移メッセージを送り続け得る（しかしＮに実際に障害が起こった場合、Ａが送信したメッセージはＢにより処理され得ない）。同様に、ＣがＴ３時点にＤ２を受信する前に、ＡがＴ２時点にＤ１を受信する場合、ＤＡＧからＢの離脱をＣが認識するまでのある時間（Ｔ３−Ｔ２）、Ｃは、Ｂに障害が起こった時に送信過程にあったメッセージをＢから受信し、処理し続け得る。ノードＡがＤ１を受信した時に、ＡはＣから連絡をまだ受けていない場合、ノードＡは、古い複製経路（Ａ〜Ｂ〜Ｃ）に置き換わる新たな構成の複製経路（Ａ〜Ｃ）においてＡの新たな隣接後続ノードとなるＣに対し、接続を確立し得る。同様に、ＣがＤ２を受信した時に、Ｃは自身の新たな隣接先行ノードとなるＡに対し接続を確立し（ＡがＣにまだ連絡を取っていない場合）、そして少なくともいくつかの実施形態において、ＡからＢへ送信されたがまだＣに届いてないステート遷移レコードの再送信の要求を、ＣはＡに提出し得る。例えば、Ｃは再送信要求内に、これまでＣが受信済みのステート遷移レコードの最大シーケンス番号ＨＳＮ１を含ませ、これによりＡは、ＨＳＮ１より大きいシーケンス番号を有するいずれのステート遷移レコードも再送可能となる。
【００１１】
少なくともいくつかの実施形態において、構成マネジャーは、正常性検出機構またはＤＡＧノードが見かけ上不正常になった時を示すサービスに依拠しており、これによりＤＡＧ構成から見かけ上不正常なノードは除去され得る。分散環境における少なくともいくつかの正常性検出機構は、ノードの正常性ステータスに関して必ずしも正しい判断をするとは限らないハートビートまたは他の低次機構に依存し得る。同時に、構成マネジャーは、その構成デルタメッセージを送信する前に、実際のノード障害を確認するのをいつまでも待機する立場にはあり得ず、代わりに構成マネジャーは、ノード障害の可能性がある閾値（例えば８０％または９０％）を超えると判定した際、構成デルタメッセージを送信し得る、あるいはいくつかの他のヒューリスティックを使用してＤＡＧ構成変更及び対応デルタメッセージを引き起こし得る。前述のように、複製ＤＡＧにおいて使用されるステート管理プロトコルは、例えば「全世界停止」中断を回避することにより、誤判定障害「検出」の悪影響を緩和し得る。その結果、他のステート複製技術が使用された場合に容認されたであろう障害検査機構よりも、より迅速／安価な（しかし信頼性は低い可能性のある）障害検査機構が、複製ＤＡＧ採用時には使用可能となり得る。
【００１２】
少なくとも一実施形態において、整合一時停止技術が複製ＤＡＧに実施され得る。ある条件の下、例えば複数のＤＡＧリソースまたはノードが関わる大規模障害イベントが検出された場合、構成マネジャーは、ＤＡＧの生き残ったノードに対し、さらなるステート遷移の処理を停止し、それらのアプリケーションステート情報をお互いに同期し、同期されたアプリケーションステート情報をそれぞれの格納位置に格納し、再開命令を待つように指示し得る。いくつかの実施態様において、アプリケーションステートをローカルに保存した後、ＤＡＧノードはそれぞれ、クリーンシャットダウン及び再始動を実行し、再始動後に構成マネジャーに対し、自身がサービス対応可能であることを示す報告を行い得る。構成マネジャーにより一時停止命令が発行される前に障害が発生したノードがサービス対応可能であることを報告した場合、いくつかの実施形態において、構成マネジャーは、そのようなノードに対しそのアプリケーションステートを、アプリケーションステートが最新であるとわかっている（例えば構成マネジャーにより）別のノードと同期するように指示し得る。構成マネジャーは、十分な数のノードが（ａ）サービス対応可能となり、（ｂ）アプリケーションステートに関して最新になるまで待機し、（新しい可能性のある）ＤＡＧ構成を決定し、ＤＡＧ構成のメンバーノードに対しＤＡＧ構成を示す再開メッセージを送信することでＤＡＧを再開し得る。いくつかの実施形態において、このような制御され整合された一時停止／再始動戦略により、大規模障害イベントの後、このような戦略がない場合に可能であり得るアプリケーション回復と比べて、より迅速で信頼性の高いアプリケーション回復が可能となる。整合一時停止手法は、例えば複数の複製ノードからのアプリケーションステート情報の高速並列バックアップ／スナップショットのためといった、大規模障害に応じること以外の目的にも使用され得る。
【００１３】
前述の種類のＤＡＧベースの複製ステートマシンは、様々な実施形態における様々な異なるアプリケーションを管理するために使用され得る。いくつかの実施形態において、ログサービスが実施され、当該ログサービスでは、１つまたは複数のデータストア（例えばリレーショナルまたは非リレーショナルデータベース）が、複製ＤＡＧを使用して実施される持続的変化ログのインスタンスを介して、トランザクション管理に登録され得る。後でさらに詳しく説明されるように、いくつかの実施形態において、楽観的並行処理制御機構がこのようなログベーストランザクションマネジャーにより使用され得る。ログサービスのクライアントは、所定のトランザクション内で、１つまたは複数のソースデータストアに対し読み出し動作を行い、書き込み動作を行う（例えば読み出しの結果に基づいて）１つまたは複数のデータストア位置を特定し得る。読み出し集合、書き込み集合、並行処理制御要件、及び／またはトランザクションに対する論理制約の表現を含むトランザクション要求記述子は、ログサービスの競合検出器（例えば対応複製ＤＡＧの受諾ノードに対応付けられる競合検出論理）へ提出され得る。競合検出器は、前にコミットされたトランザクションのレコードをトランザクション記述子のコンテンツと一緒に使用して、コミットのためにトランザクション要求の受諾可能か否かを判定し得る。コミットのためにトランザクションが受諾されると、ログ用に確立されたＤＡＧの複数の複製ノードにおいて、対応コミットレコードの複製が開始され得る。従って、ログの所定レプリカに挿入されるレコードは各自、それぞれのアプリケーションステート遷移を表し得る。重複排除要件、トランザクション間コミット順序付け要件等、いくつかの異なる論理制約は、異なる実施形態において特定され、ログベーストランザクションマネジャーにより施行され得る。このようなログベーストランザクション管理機構により、いくつかの実施形態において、例えば基礎データストアは複数の書き込みを伴うトランザクションの原子性にネイティブに対応し得ないにもかかわらず、所定のトランザクションの書き込み集合に複数の書き込み位置が含まれる複数アイテムトランザクションまたは複数データベーストランザクションに対する対応が可能となり得る。コミット済みトランザクションに対応する書き込みは、少なくともいくつかの実施形態において、非同期的に関連データストアへ適用され得る。例えばトランザクションがコミットされたレコードは、対応書き込みが対象データストアに伝播される前のある時に、持続的変化ログに保存され得る。持続的変化ログは従って、少なくともいくつかの実施形態においてアプリケーションステートの正式な情報源となり、データストアは、当該ログがステート変更を記録した後に、アプリケーションステートに追いつき得る。
【００１４】
複製ＤＡＧは、様々な実施形態において、複製データベースインスタンス、高スループットデータストリーム管理、及び／または分散ロック管理のためにも使用され得る。いくつかの実施形態において、複製ＤＡＧは、演算インスタンス等の仮想リソースに対するステート変更を管理するために、プロバイダネットワーク内で使用され得る。少なくともいくつかの実施形態において、登録済みデータストア（書き込みの結果がデータストアのそれぞれの読み出しインターフェースを介して読み出し可能である）に対しコミット済みの書き込みを伝播することに加えて、ログサービスも自身の個別のアクセスインターフェースを定義及び実施し得るため、これにより関心のあるクライアントは、持続的ログインスタンスから直接、所定のクライアントアプリケーションのために格納されたレコードの少なくとも一部を読み出すことが可能になる。
【００１５】
例示的システム環境
図１は、少なくともいくつかの実施形態による、アプリケーションステート変更を管理するために複製ノードの動的ＤＡＧ（有向非巡回グラフ）が確立された例示的システム環境を示す。示されるように、システム１００において、アプリケーション１６０のステート遷移を管理するために確立された複製ＤＡＧ１４０は、受諾ノード１１０、中間ノード１１２、コミッタノード１１４の３つのノードを含む複製経路を備える。さらにＤＡＧ１４０は、描かれた実施形態において、必要があれば他のノードのうちのいずれかの責務を引き継ぐことが可能な待機ノード１３０を含む。他の複製ＤＡＧには、他の組み合わせのノードが配置され得る。例えば、いくつかのアプリケーションには複数の中間ノードが使用され得るが、他のアプリケーションには中間ノードは全く使われ得ない、あるいは待機ノードは確立され得ない。ＤＡＧ１４０の構成に対する変更は、後述のように、フォールトトレラントＤＡＧ構成マネジャー（ＤＣＭ）１６４により整合され得る。
【００１６】
受諾ノード１１０は、描かれた実施形態において、ＡＰＩ（アプリケーションプログラミングインターフェース）等の１つまたは複数のプログラム的インターフェースを介して、アプリケーションステート遷移要求（ＳＴＲ）１５０を受信し得る。受諾ノード１１０は、アプリケーション従属規則または論理を使用して、要求遷移を最終的コミットのために受諾し得る、あるいは要求を拒否し得る。遷移が受諾されると、例えば他の受諾された遷移に対して当該遷移が受諾された順序を示す、シーケンス番号が受諾ノード１１０により生成され得る。前述のように、いくつかの実施形態において、シーケンス番号は、受諾された遷移ごとに増加するカウンタを含み、一方別の実施形態においては、構成マネジャーにより提供される論理クロックまたはタイムスタンプ値が使用され得る。対応シーケンス番号を含むアプリケーションステートレコード（ＡＳＲ）１７２Ａの集合１７６Ａは、受諾ノードによりローカル持続的格納域に格納され得る。いくつかの実施形態において、アプリケーションステートレコードは、遷移受諾レコードと遷移コミットレコードの両方を含み得る（コミットレコードは、対応遷移がコミッタノードによりコミットされたことが受諾ノードに通知された後にのみ格納される）。別の実施形態においては、複製経路沿いの少なくともいくつかのノードが受諾レコードのみを格納し得る。受諾を示すステート遷移レコードを格納した後、受諾ノードは、承認を示すステート遷移メッセージ（ＳＴＭ）１５２Ａを、例示構成における中間ノード１１２といった複製経路沿いの自身の後続ノードに送信し得る。中間ノードは、対応ＡＳＲの自身のコピー１７２Ｂをシーケンス番号と共に、そのローカルＡＳＲ集合１７６Ｂに格納し得る。中間ノードは、自身のＳＴＭ１５２Ｂを、現行複製経路沿いの自身の隣接ノードに、例えば描かれた実施形態におけるコミッタノード１１４に、送信し得る。少なくともいくつかの実施態様において、ＳＴＭ１５２は、どのノードがＡＳＲのレプリカを既に格納済みかを示す開示を含み得る。例えばメッセージ１５２Ｂは、受諾を示すアプリケーションステートレコードのそれぞれのレプリカがノード１１０、１１２にそれぞれ既に格納済みであることを、コミッタノードに示し得る。
【００１７】
アプリケーションステートレコードの十分な数のレプリカが格納されたというコミッタノードにおける判断に応じて（十分なレプリカの正確な数はアプリケーション１６０の構成パラメータであり得る）、遷移がコミットされ得る。コミッタノードのＡＳＲ集合１７６Ｃは、描かれた実施形態において、トランザクションコミットのレコードを含み得る（承認の相対として）。従ってＡＳＲ１７２Ｃは、単なる受諾ではなくコミットを示し得る。少なくともいくつかの実施形態において、コミッタノード１１６は、遷移がコミットされたことを示す開示または通知を、受諾ノード及び／または中間ノードへ送信し得る。別の実施形態において、受諾及び／または中間ノードは、どの遷移がコミットされたかを特定するためにコミッタノード１１６に対し要求を提出し（例えば定期的に）、それらのＡＳＲ集合を適宜更新し得る。いくつかのアプリケーションに関して、明示的コミットは必要とされ得ないため、コミットの開示は何も格納され得ず、よって経路沿いのそれぞれのＤＡＧノードは、受諾を示すそれぞれのアプリケーションステートレコードを単純に格納し得る。描かれた実施形態において、コミット後ＳＴＭ１５４がコミッタノードから待機ノード１３０へ送信され、これにより待機ノードはそのＡＳＲ集合１７６Ｄを更新可能となるため（例えばコミットＡＳＲ１７２Ｄを格納することで）、別のＤＡＧノードを置き換えるように待機ノードが有効化される場合には、そのアプリケーションステート情報がコミッタノードのものと一致する。待機ノードが最新のコミット済みアプリケーションステートと常に同期しているという事実から、構成マネジャーは、いくつかの実施形態において他の３種類の役割のうちのいずれかに、例えば受諾ノード、中間ノード、またはコミッタノードとして、待機ノードを迅速に有効化することが可能になり得る。
【００１８】
フォールトトレラントＤＡＧ構成マネジャー（ＤＣＭ）１６４は、描かれた実施形態において必要に応じて、ＤＡＧ構成またはＤＡＧメンバーに対する変更を、構成デルタメッセージ１６６（例えばメッセージ１６６Ａ、１６６Ｂ、１６６Ｃ、１６６Ｄ）の形でＤＡＧノードに伝播する責務を担い得る。例えば、障害の結果等で所定のＤＡＧノードがＤＡＧ１４０を離脱する場合、ＤＣＭ１６４により１つまたは複数の生き残ったノードに対し、対応構成デルタメッセージ１６６が送信され得る。同様に、新たなノードがＤＡＧに参加する場合（例えば障害からの復旧後、またはアプリケーション１６０の耐久レベルを向上させるために）、参加イベント、ＤＡＧ内の参加ノードの位置、及び／または参加ノードに与えられた役割（例えば受諾、中間、コミッタ、または待機）を示す対応構成デルタメッセージが、ＤＣＭによりＤＡＧの１つまたは複数の現行メンバーノードに対し送信され得る。構成デルタメッセージ１６６は、お互いに関して非同期であり、アプリケーションステートの全体的複製に影響せずに、任意の順序でそれらの対象により受信され得る。ＤＡＧの各ノードは、受信した構成デルタメッセージに基づいて、他のノードが持ち得る構成見解１７４とは関係なく、ＤＡＧ構成の自身の見解１７４を構築する責務を担い得る。従って、例えば、それぞれのノード１１０、１１２、１１４、１３０にて受信される別個の構成デルタメッセージの相対的順序及び／またはタイミングのため、いくつかの実施形態において、構成見解１７４Ａ、１７４Ｂ、１７４Ｃ、１７４Ｄのうちの１つまたは複数は、少なくともある短い時間間隔において異なり得る。少なくともいくつかの実施形態において、各ＤＡＧノードは、それぞれのローカル構成変更レポジトリにおいて受信される複数の構成デルタメッセージの表現またはコンテンツを格納し得る。描かれた実施形態において、ＤＣＭ１６４は、ＤＡＧノードによるアプリケーションステート処理において全世界一時停止を施行し得ない。例えばこれにより、ノードは、構成デルタメッセージのタイミングまたは基礎ＤＡＧ構成変更に関係なく、アプリケーションステート遷移メッセージを受信または処理し続けることが可能になり得る。ＤＡＧノードが構成デルタメッセージに応じる方法の実施例は、図２ａ〜２ｈを参照して後述される。
【００１９】
図１は、各種類のノードを１つずつ含む単一線複製経路または「チェーン」を有するＤＡＧを示すが、少なくともいくつかの実施形態において複製ＤＡＧは、分岐経路及び／または各役割に対し複数のノードを含み得ることに留意されたい。すなわち、いくつかの受諾、中間、コミッタ、及び／または待機ノードが同一ＤＡＧ内に共存し、そしてＤＡＧの複製経路は、結合ノード（複数の先行ノードから遷移要求を受信するノード）、または分割ノード（遷移要求を複数の後続ノードに送信するノード）を含み得る。受諾ノード１１０またはコミッタノード１１６のどちらかが要求されたステート遷移を拒否する場合（例えば受諾ノードがアプリケーション特有受諾基準の集合を満たさないと判定したため、またはコミッタノードが受諾済みステート遷移要求メッセージを受信する時までに受諾済み遷移の十分な数のレプリカが作られていなかったため）、いくつかの実施形態において、遷移を要求したクライアントに遷移がコミットされなかったことが通知され得る。クライアントはその後、遷移を再試行し得る（例えば別のステート遷移要求を提出することにより）、あるいは要求を完全に放棄することに決め得る。いくつかの実施態様において、中間ノードもまた遷移要求をアボートすることが許され得る。
【００２０】
図２ａ〜２ｈは、少なくともいくつかの実施形態による、ＤＡＧのノードのうちの１つに障害が起こり得たという検出に応じて複製ＤＡＧにおいて行われ得る例示的一連動作を示す。図２ａは、３つのノード２０２Ａ、２０２Ｂ、２０２Ｃを含むＤＡＧ構成の初期状態を示す。ステート遷移要求（ＳＴＲ）１５０がノード２０２Ａにて受信される。受諾済みステート遷移レコードが、ノード２０２Ａ（ＳＴＲのローカル承認後）及びノード２０２Ｂ（ノード２０２Ｂが承認済みＳＴＭ２１１Ａを受信後）にて複製され、２０２Ｃにて（ノード２０２Ｃが承認済みＳＴＭ２１１Ｂを受信後）コミットされる。ＤＣＭ１６４は、ノード２０２Ｂに障害が発生した様子であることを示す正常性ステータス更新情報２５０を受信し得る。ノード２０２Ｂのステータスに関する正常性ステータス更新情報は、異なる実施形態において、様々な情報源のうちのいずれかから、例えば他のノード（２０２Ａまたは２０２Ｂ）のうちの１つから、またはＤＡＧの外部の正常性監視サービス（例えばＤＡＧノードがインスタンス化されたプロバイダネットワークに確立された汎用リソース正常性監視サービス）から、受信され得る。少なくとも一実施態様において、正常性ステータス更新情報は、ＤＡＧノードにハートビートメッセージを定期的に送信して、複数の連続ハートビートメッセージに対し許容時間窓内に何も応答が受信されない場合には所定ノードは非正常状態にあると判定する監視プロセス等、ＤＭＣ１６４自身のサブコンポーネントにより生成され得る。
【００２１】
描かれた実施形態において、ＤＣＭ１６４は、正常性ステータス更新情報に基づいて、ノード２０２ＢはＤＡＧから削除されるべきであること、そして新たなノード２０２Ｄがノード２０２Ｃの後続ノードとして追加されるべきであることを決定し得る。新たなノードには、例えばＤＡＧの新コミッタノードとして有効ステータスに昇格された待機ノードが含まれ得る。ＤＡＧの新構成（すなわちＤＡＧは現時点で複製チェーン２０２Ａ〜２０２Ｃ〜２０２Ｄを含むべきであること）を決定し、新構成の表現を持続的レポジトリに保存した後、ＤＣＭ１６４はノード２０２Ｄに対し、ノード２０２Ｃの後続ノードとしてＤＡＧに参加するよう命令２４１を発行し得る。少なくともいくつかの実施形態において、２０２Ｂ等のノードのＤＡＧからの削除は、必ずしも置き換えノードの即時追加を伴うとは限らず（特に削除が行われた後に経路上に残り接続状態のままのＤＡＧノードの数が、ステートが複製中のアプリケーションにより必要となる最小ノード数を超える場合）、ノード２０２Ｄの追加は、ＤＣＭがノード障害（または少なくとも見かけ上のノード障害）に応じ得るやり方の１つとして単純に例示されることに留意されたい。図２ｂにおいて示されるように、ノード２０２Ｂに実際障害は発生していなかった（すなわち２０２Ｂの障害に関して正常性更新情報は誤っていた）という場合もあり得る。このような誤判定シナリオにおいて、ステート遷移メッセージは、２０２Ａから２０２Ｂへ、そして２０２Ｂから２０２Ｃへ送信され続け、これによりアプリケーションは、ＤＣＭ１６４による削除判定後少なくともしばらくの間、進行し続けることができる。
【００２２】
少なくともいくつかの実施形態において、２０２Ｂ等のノードはＤＡＧから削除され、削除されたノードの隣接後続ノード（例えば２０２Ｃ）がＤＡＧに残る場合、削除されたノードに以前割り当てられていた役割は、隣接後続ノードに委譲され得る。従って、コミッタノードであり得たノード２０２Ｃは、ノード２０２Ｂの離脱に際し中間ノードとなり、新たに有効化されたノード２０２Ｄは新コミッタノードに選定され得る。削除されたノードが隣接後続ノードを有さない場合（例えば描かれた実施例においてノード２０２Ｂの代わりにノード２０２Ｃが削除された場合）、いくつかの実施形態において、削除されたノードに割り当てられていた役割が、新たに有効化された待機ノードに与えられ得る。別の実施形態において、役割はこのような順序的／直鎖的方法で委譲され得ない。例えば構成マネジャーは、削除されたノードと差向うノードの相対位置を考慮せずに、どの役割が所定ノードに与えられるべきかを決定し得る。
【００２３】
ノード２０２ＢがＤＡＧから削除されるべきと判定した後、描かれた実施形態において、ＤＣＭ１６４は、それぞれの非同期構成デルタメッセージ２４２Ａ、２４２Ｂをノード２０２Ａ、２０２Ｃへ送信し得る。示されるように、それぞれのデルタメッセージは、２０２ＢがＤＡＧを離脱し、２０２Ｄが参加したことを示し得る。描かれた実施形態において、構成に関する２つの変更が単一の構成デルタメッセージ内に示されるが、別の実施形態においては、２０２Ｂの削除と２０２Ｄの参加に関して個別の構成デルタメッセージが送信され得る。描かれた実施形態において、構成デルタメッセージは、ＤＡＧ構成に対する変更のみを示し、ＤＡＧの構成全体の表現を含み得ない。ノード２０２Ａが構成デルタメッセージ２４２Ａを受信するまで、あるいは２０２ＢはＤＡＧから離脱したことを認識するまで（例えばネットワーク接続の終了により）、ノード２０２Ａからノード２０２Ｂに対しＳＴＭは送られ続け得る。２０２Ｂに実際障害は発生していなかったというシナリオにおいて、ノード２０２Ｂは、ＤＡＧから削除されたことを認識する（例えば２０２Ａまたは２０２Ｃが２０２Ｂと通信停止した場合）まで、ステート遷移要求を処理し、メッセージ２１１Ｂをノード２０２Ｃへ送信し続け得る。
【００２４】
構成デルタメッセージ２４２は、非同期メッセージ機構を使用して送信されるため、それらの送信先に異なる時間に到着し得る。ノード２０２Ｃが構成デルタメッセージ２４２Ｂを受信する前にノード２０２Ａが構成デルタメッセージ２４２Ａを受信する場合、図２ｄに描かれるシナリオが達成され得る（ＤＡＧは少なくとも一時的に岐路を含む）。メッセージ２４２Ａに応じて、ノード２０２Ａは、構成変更の開示をローカル格納域に保存し、その後いかなるメッセージもノード２０２Ｂに送信することを停止し得る。さらに、ノード２０２Ａは、自身の新後続ノードは２０２Ｃであると判断し、よってノード２０２Ｃとのネットワーク接続を確立し、新たなステート遷移メッセージ２１１Ｃをノード２０２Ｃに送信することを開始し得る。描かれた実施形態において、２０２Ｂの削除を示すメッセージが残りのノードに届くとともに、ＤＡＧの様々なノードでステート遷移処理活動が継続され得る。例えば、ノード２０２Ｂに障害が起こったと思われたが実際は正常に機能し続けていたというシナリオにおいて、ノード２０２ＢがＤＡＧから削除されたということをノード２０２Ａが知らされた後でも、ノード２０２Ａから送信過程にあった１つまたは複数のステート遷移メッセージは、ノード２０２Ｂにて受信され得る。このような送信過程メッセージを受信すると、ノード２０２Ｂは、メッセージ内に示されるステート遷移情報をローカル格納域に複製し、別の同様のＳＴＭをノード２０２Ｃへ送信しようと試み得る。ノード２０２Ｃがノード２０２Ｂの削除をまだ知らない（または少なくともノード２０２Ｂとの自身の接続をまだ閉じていない）場合、ノード２０２Ｃはノード２０２Ｂからのメッセージを受信し、処理し得る。これにより、構成マネジャーによりノード２０２ＢはＤＡＧ構成から削除されたものの、アプリケーションは進行可能となる。
【００２５】
ノード２０２Ａが構成デルタメッセージ２４２Ａを受信する前にノード２０２Ｃが構成デルタメッセージ２４２Ｂする場合、図２ｅに例示されるシナリオが達成され得る。メッセージ２４２Ｂを受信すると、ノード２０２Ｃは、ノード２０２Ｂから送信される新規メッセージを受信することを停止し得る（例えばノード２０２Ｂとの自身の接続がまだ使用可能である場合は、当該接続を終了することにより）。ノード２０２Ｃは、ノード２０２ＡがＤＡＧ経路における自身の新たな隣接先行ノードであると理解すると、ノード２０２Ａへの接続を確立し得る。ノード２０２Ｃはまた、描かれた実施形態において、最大シーケンス番号ＨＳＮ１を特定し（ノード２０２Ｃが既に受信した承認済みＳＴＭのシーケンス番号の中から）、２０２Ｃが受信し損なった可能性のある全ての承認済みステート遷移メッセージ（すなわちＨＳＮ１より大きいシーケンス番号を有する全ての承認済みＳＴＭ）を再送するようにノード２０２Ａへ要求２６０を送信し得る。さらに、ノード２０２Ｃはまた、自身の新後続ノード２０２Ｄへの接続を確立し、続く承認済みＳＴＭ２１１Ｄをノード２０２Ｄへ送信することを開始し得る。
【００２６】
２０２Ａと２０２Ｃの両ノードがＤＡＧ構成変更について通知された後、図２ｆに例示されるＤＡＧの新たな複製経路（すなわち２０２Ａ〜２０２Ｃ〜２０２Ｄ）が、新たに受信されるステート遷移要求に使用され得る。構成デルタメッセージ２４２のタイミングのため、ノード２０２Ａが構成デルタメッセージ２４２Ａを受信する前に、ノード２０２Ａはノード２０２Ｃから構成変更を知らされる場合もあり得ることに留意されたい。同様に、いくつかの実施形態において、ノード２０２Ｃは、ノード２０２Ａから（またはノード２０２Ｄからでも）新構成について知らされ得る。従って、新構成に関する情報がＤＡＧのいずれかの所定ノードに到達し得る方法は複数あり、少なくともいくつかの実施形態において、構成デルタメッセージがそれらの全ての対象受信ノードに到達する前でも、ＤＡＧノードは新複製経路を部分的に使用開始し得る。
【００２７】
図２ｇに示されるように、ノード２０２Ｂは、ＤＡＧから削除された後（例えば実際の障害により、または誤判定障害検出により）のある時点で、ＤＣＭ１６４に対し自身はサービス開始可能であることを任意で示し得る。例えば、実際の障害の場合、ノード２０２Ｂは最終的に修復され再始動され、「サービス対応可能」メッセージ２８０を送信する前に復旧動作のある集合を実行し得る。ネットワーク接続損失の場合、「サービス対応可能」メッセージは、接続が再確立された後に送信され得る。これに応じて、描かれた実施形態においてＤＣＭ１６４は、ノード２０２ＢをＤＡＧの待機ノードとして追加し直すことを決定し得る。従って、図２ｈに示されるように、ＤＣＭは、参加コマンド２８２をノード２０２Ｂへ送信し、新たな構成デルタメッセージ集合２４４Ａ、２４４Ｂ、２４４Ｃをノード２０２Ａ、２０２Ｂ、２０２Ｄへそれぞれ送信してノード２０２Ｂの追加をそれらに通知し得る。図２ａ〜２ｈに例示される一連動作は実施例として提供されており、そしてＤＡＧノード及びＤＣＭは、様々な実施形態においてノード２０２Ｂの見かけ上の障害に応じて、図２ａ〜２ｈに例示される一連動作と異なる一連動作を実行し得ることに留意されたい。例えば、いくつかの実施形態において、ノード２０２Ｃの後続ノードとしてＤＡＧに新たなノードは何も追加され得ない。また、いくつかの実施形態において、ノード２０２Ｂは、サービス対応可能になった後に必ずしも同じＤＡＧに再参加するとは限らず、代わりに例えば、異なるＤＡＧへ配置され得る、あるいは新たなＤＡＧを構成する際使用され得るノードのプールに保持され得る。
【００２８】
図２ａ〜２ｈにおいて障害検出がＤＡＧ構成変更を引き起こすように示されるが、通常、様々な実施形態において、多数の異なる考察のうちのいずれかにより、ＤＡＧ構成の修正はもたらされ得る。例えば、アプリケーションオーナー（またはＤＣＭ）は、データ耐久性を向上するために、または可用性の理由で、ＤＡＧに対しノードを追加することを決定し得る。新たなノードの追加を示す構成デルタメッセージは、ステート遷移処理において「全世界停止」中断を要求することなく、いくつかの実施形態において前述される削除関連伝播と同様の非同期的方法で他のＤＡＧノードに伝播され得る。ＤＡＧノードは、いくつかの実施形態において、メンテナンス関連理由で、例えばソフトウェアのアップグレードのため、ソフトウェアエラーのデバッグのため、またはハードウェア修正のために、経路から外される必要があり得る。少なくとも一実施形態において、ノードのうちの１つまたは複数における作業負荷レベル（例えば毎秒処理されているステート遷移数）は閾値レベルに達しており、現在使用されているものより性能の高い（または性能の低い）ハードウェア／ソフトウェアスタックが使用されるべきであるという判定の結果、ＤＡＧの構成は変更され得る。いくつかの実施形態において、ＤＡＧ構成変更は、必ずしもノードを追加または削除することなく、特定のＤＡＧノードの位置または役割を変更することを伴い得る。例えば、構成マネジャーは、コミッタの役割を前に中間ノードだったノードに転嫁し、元コミッタノードを新構成における中間ノードに仕上げ得る。このような役割変更は、例えば、負荷分散目的で、特にいくつかの異なるＤＡＧのノードに対し同一ホストが使用されているマルチテナント環境において、実施され得る（そして対応構成デルタメッセージが伝播され得る）。このようなマルチテナント環境は、さらに詳しく後述される。
【００２９】
ステート遷移レコードと構成デルタメッセージ
図３は、少なくともいくつかの実施形態による、動的複製ＤＡＧにて生成され得るアプリケーションステートレコード（ＡＳＲ）とＤＡＧ構成デルタメッセージとの例示的コンポーネントを示す。前に示されたように、少なくともいくつかの実施形態において、それぞれが承認済みまたはコミット済みステート遷移を表現するアプリケーションステートレコードのコピーは、ＤＡＧの複製経路沿いのいくつかのノードのそれぞれに格納され得る。アプリケーションステートレコードは、本明細書においてステート遷移レコードとも称され得る。示されるように、アプリケーションステートレコード３２０には、例えば、要求されたステート遷移の承認が記録されているか否か、または承認済みステート遷移のコミットが記録されているか否かといった遷移の種類３０２の開示が含まれ得る。いくつかの実施形態において、前述のように、各ＤＡＧノードは承認及びコミットレコードの両方を格納し、一方別の実施形態においては、１種類のステート遷移レコードのみが格納され得る。例えば、１つのシナリオにおいて、承認レコードは非コミッタノードにて最初に複製され、そして承認レコードは、トランザクションがコミッタノードにより最終的にコミットされた後、コミットレコードに変更され得る。少なくとも一実施形態において、個別遷移種類フィールド３０２は、ＡＳＲ内にも、ＡＳＲの生成をもたらすメッセージ内にも含まれ得ない。代わりに、遷移の種類はＤＡＧノードにより、自身の現在の役割及び／またはメッセージを送信した情報源ＤＡＧノードの役割に関するノードの知識に基づいて、推測され得る。例えば、ステート遷移メッセージを受信する非コミッタノードは、メッセージが承認済みステート遷移を表すことを推測し得る。
【００３０】
描かれた実施形態において、ステート遷移レコード３２０は、遷移データ３０４を含み得る。遷移データコンポーネント３０４のコンテンツの特質は、ステートが管理されているアプリケーションにより異なり得る。いくつかの事例において、例えば、ステート遷移要求は、書き込みペイロード（書き込み予定の複数のバイトと、当該バイトが書き込まれるアドレス（複数可）とを示す）を含み、書き込みペイロードは遷移レコードに含まれ得る。別のアプリケーションに関して、各ステート遷移は、アプリケーションクライアントにより発行された各自の命令を示し、命令の表現はＡＳＲに含まれ得る。ＡＳＲ３２０は、ステート遷移に対応するシーケンス番号３０６（論理スタンプとも考えられる）も含み得る。シーケンス番号は、例えば、受諾ノードにてステート遷移要求が承認された時、またはコミッタノードにてステート遷移がコミットされた時、生成され得る。少なくともいくつかの実施形態において、ＤＡＧを使用して管理されているアプリケーションの現行ステートは、アプリケーションのある初期ステートから開始して、シーケンス番号が増加する順序で、コミット済みステートレコードの遷移データ（例えば書き込みペイロード、命令等）を適用することにより決定され得る。いくつかの実施形態において、例えばどのＤＡＧノードが同一の遷移に関する各自のＡＳＲを既に格納したか、及び／またはこれらのレコードが複製された順序を示す、遷移の複製履歴情報３０８もまた、ＡＳＲに含まれ得る。このような複製履歴情報は、例えば、コミットのために十分な数のノードが所定のステート遷移を記録したことを確認するために、いくつかの実施態様においてコミッタノードにより使用され得る。いくつかの実施形態において、ＡＳＲメッセージは、対応ステート遷移要求が受信された受諾ノードの識別を示し得るが、複製経路沿いの他のノードに関する情報は含まなくてもよい。少なくとも一実施態様において、コミッタノードは、承認済みステート遷移をコミットする前に、十分な数のノードがステート遷移レコードを複製したことを確認する必要はなくてよい。
【００３１】
ＤＡＧ構成デルタメッセージ３７０は、描かれた実施形態において、参加または離脱するノード（複数可）の識別子３５２と、実施されている変更の種類３５４（例えば参加、あるいは離脱）とを示し得る。いくつかの実施態様において、参加（または離脱）ノードに関する役割情報３５６が、任意で構成デルタメッセージに含まれ得る。少なくともいくつかの実施形態において、アプリケーションステートシーケンス番号がアプリケーションステート遷移に対応付けられるように、ＤＡＧ構成変更シーケンス番号３５８は、構成デルタメッセージに含まれ得る。このようなシーケンス番号は、例えば、構成デルタメッセージの受信ノードにより、当該受信ノードが全ての前の構成変更を受信したか否かを判定するために使用され得る。いくつかの構成変更が欠損している場合（例えばネットワークパケットが抜け落ちたため）、受信ノードは、欠損している構成デルタメッセージを再送するようにＤＣＭに要求を送信し得る。構成変更シーケンス番号３５８は、様々な実施形態において、ＤＣＭにおけるカウンタまたは論理タイムスタンプとして実施され得る。ＤＣＭが複数のノードを有するクラスタを備えるいくつかの実施態様において、構成変更シーケンス番号３５８の情報源として、クラスタマネジャーにより維持されるグローバル論理タイムスタンプが使用され得る。
【００３２】
プロバイダネットワーク環境における複製ＤＡＧ展開
図４は、少なくともいくつかの実施形態による、プロバイダネットワークの複数の可用性コンテナにわたりメンバーノードが分散された例示的複製ＤＡＧを示す。インターネット及び／または他のネットワークを介してアクセス可能な１つまたは複数のサービス（様々な種類のマルチテナント及び／または単一テナントのクラウドベースコンピューティングまたは格納サービス等）を、分散集合のクライアントに提供するために、企業または公的機関等の事業体が構築したネットワークは、本明細書においてプロバイダネットワークと称され得る。少なくともいくつかのプロバイダネットワークは、「パブリッククラウド」環境とも称され得る。所定のプロバイダネットワークには、プロバイダにより提供されるインフラストラクチャ及びサービスを実装、設定、及び配給するために必要となる物理及び／または仮想化コンピュータサーバ、格納デバイス、ネットワーク機器等の集合といった様々なリソースプールを提供する多数のデータセンタが含まれ得る。大きなプロバイダネットワーク内で、いくつかのデータセンタは他とは異なる市、州、または国に配置され、そしていくつかの実施形態において、所定アプリケーションに割り当てられたリソースは、所望されるレベルの可用性、耐障害性、性能を達成するために、このようないくつかの場所に分散され得る。
【００３３】
いくつかの実施形態において、プロバイダネットワークは、複数の地理的領域に編制され、そして各領域は、「可用性ゾーン」とも称され得る１つまたは複数の可用性コンテナを含み得る。次に可用性コンテナは、所定の可用性コンテナ内のリソースが他の可用性コンテナにおける障害から隔離される（例えば電力関連設備、冷却設備、及び／または物理的安全コンポーネント等の独立インフラストラクチャコンポーネントを有する）ように設計された１つまたは複数の別個の物理的建物またはデータセンタを含み得る。１つの可用性コンテナにおける障害がその他の可用性コンテナにおいて障害もたらすことは予期され得ないため、所定の物理ホストまたは仮想化サーバの可用性プロファイルは、別の可用性コンテナにおける他のホストまたはサーバの可用性プロファイルとは無関係であるように企図される。
【００３４】
図４に示されるように、いくつかの実施形態において、複製ＤＡＧの１つまたは複数のノードは、ＤＡＧの他のノードの可用性コンテナと異なる可用性コンテナ内にインスタンス化され得る。描かれた実施形態において、プロバイダネットワーク４０２は、３つの可用性コンテナ４６６Ａ、４６６Ｂ、４６６Ｃを含み、各可用性コンテナは複数のノードホスト４１０を備える。例えば、可用性コンテナ４６６Ａのノードホスト４１０Ａは、ＤＡＧノード４２２Ａと、ローカル持続的格納域（例えば１つまたは複数のディスクベースデバイス）４３０Ａと、ＤＡＧのクライアントと通信するためのフロントエンドとして使用され得るプロキシ４１２Ａとを備える。同様に、可用性コンテナ４６６Ｂ内のノードホスト４１０Ｂは、ＤＡＧノード４２２Ｂと、ローカル持続的格納域４３０Ｂと、プロキシ４１２Ｂとを備え、可用性コンテナ４６６Ｃ内のノードホスト４１０Ｃは、ＤＡＧノード４２２Ｃと、ローカル持続的格納域４３０Ｃと、プロキシ４１２Ｃとを備える。描かれた実施形態において、ＤＡＧノード４２２（及び／またはプロキシ４１２）はそれぞれ、１つまたは複数のプロセスの集合等、１つまたは複数の実行スレッドを含み得る。ローカル持続的格納デバイス４３０は、描かれた実施形態において、複製経路４９１沿いにアプリケーションステート情報のローカルレプリカ（及び／または複製経路４９１のＤＡＧノード４２２にて受信されるＤＡＧ構成デルタメッセージコンテンツ）を格納するのに使用され得る。
【００３５】
図４の実施形態において描かれるＤＡＧのＤＣＭ自体は、複数の可用性コンテナにわたって分散された複数のノードを備える。示されるように、同意ベースのＤＣＭクラスタ４９０が使用され、これには、可用性コンテナ４６６Ａに配置されたＤＣＭノード４７２ＡとＤＣＭ格納域４７５Ａ、並びに可用性コンテナ４６６Ｂに配置されたＤＣＭノード４７２ＢとＤＣＭ格納域４７５Ｂが含まれる。描かれたＤＣＭは従って、少なくとも障害が可用性コンテナの境界を越えないという点では、フォールトトレラントと考えられ得る。このようなフォールトトレラントＤＣＭのノードは、例えばＤＣＭにより管理されているＤＡＧのメンバーノードと対照的に、本明細書において「構成ノード」と称され得る。ＤＡＧ構成に対する変更（例えばノードの削除、追加、または役割変更を含む）は、ＤＣＭノード４７２間の同意ベースプロトコルを使用して承認され、そしてＤＡＧ構成の表現は、対応構成デルタメッセージがＤＡＧノード４２２に送信される前に、複数のＤＣＭノードにより持続的格納域に格納される必要があり得る。ＤＣＭ及び／または所定の複製ＤＡＧに使用される可用性コンテナの数は、異なる実施形態において、かつ、例えばアプリケーションの可用性要件またはデータ耐久性要件に応じて、異なるアプリケーションにより、変わり得る。いくつかの実施形態において、複製ＤＡＧは、プロバイダネットワークにて実施される他のサービスのリソースの構成を管理するために使用され得る。例えば、一実施形態において、仮想化コンピューティングサービスにより使用される演算インスタンス（仮想マシン）またはインスタンスホスト（物理ホスト）のステートに対する変更は、複製ＤＡＧを使用して管理され得る。
【００３６】
図５は、少なくともいくつかの実施形態による、複数の複製ＤＡＧのノードがマルチテナント様式で単一のホストに実装され得る例示的構成を示す。示されるように、３つの複製ＤＡＧ５５５Ａ、５５５Ｂ、５５５Ｃのノードは、４つのＤＡＧノードホスト５１０Ａ、５１０Ｂ、５１０Ｃ、５１０Ｄに分散される。一般に、ノードホストはそのリソース容量において異なり得る。例えば、あるホストのコンピューティング、格納、ネットワーク、及び／またはメモリリソースは、他のホストのものと異なり得る。例えば、ノードホスト５１０ＢはＤＡＧ情報に使用可能な２つの格納デバイス５３０Ｂ、５３０Ｃを有し、ノードホスト５１０Ｄは２つの格納デバイス５３０Ｅ、５３０Ｆを有し、一方ノードホスト５１０Ａと５１０Ｃは１つの格納デバイス（５３０Ａと５３０Ｄをそれぞれ）有する。
【００３７】
ホスト５１０Ａは、ＤＡＧ５５５Ａの受諾ノード５２２Ａと、ＤＡＧ５５５Ｃの中間ノード５２２Ｎとを備える。ホスト５１０Ｂは、ＤＡＧ５５５Ａの中間ノード５２２Ｂと、ＤＡＧ５５５Ｂのコミッタノード５２２Ｋと、ＤＡＧ５５５Ｃの中間ノード５２２Ｏとを備える。ＤＡＧ５５５Ａのコミッタノード５２２Ｃと、ＤＡＧ５５５Ｃのコミッタノード５２２Ｐは、ホスト５１０Ｃに実装され得る。最後に、ＤＡＧ５５５Ａの待機ノード５２２Ｃと、ＤＡＧ５５５Ｂの受諾ノード５２２Ｊと、ＤＡＧ５５５Ｃの受諾ノード５２２Ｍとが、ホスト５１０Ｄにてインスタンス化され得る。従って、一般に、所定のホストはＮ個の異なるＤＡＧのノードに使用され、各ＤＡＧはＭ個の異なるホストを使用し、Ｍ及びＮは、少なくともいくつかの実施形態において、設定可能なパラメータであり得る。それぞれのアプリケーションオーナーのために確立されたいくつかのＤＡＧのノードは、少なくともいくつかの実施形態において、マルチテナント様式で同一のホストに実装され得る。例えば、特定のアプリケーションオーナーにとって、そのアプリケーションのステート管理に使用されているリソースが、他のアプリケーションのステートの管理にも使用されていることは明らかではない場合がある。いくつかのプロバイダネットワーク環境において、所定のアプリケーションの複製ＤＡＧの所定のノードに使用する特定のホストを選択する配置サービスが実施され得る。異なる実施形態において、ステートが管理されているアプリケーションの性能要件、候補ホストの利用可能なリソース容量、負荷分散要求、価格設定約因等、様々な要素の組み合わせに基づいて、ノードホストは選択され得る。少なくともいくつかの実施態様において、ホストごとに複数のＤＡＧノードをインスタンス化することは、単一のＤＡＧノードのみがインスタンス化された場合に達成され得るホストの全体リソース使用レベルと比べて、ホストの全体リソース使用レベルを向上させるのに役に立ち得る。例えば、特にＤＡＧノードに使用される論理の大部分が単一スレッドである実施形態において、マルチテナントシナリオでは、単一テナントシナリオよりも多いマルチコアホストのプロセッサコアが同時に使用可能であり、これによりホストの平均ＣＰＵ使用率は向上する。
【００３８】
動的ＤＡＧベースのステート複製を実施する方法
前述のように、いくつかの実施形態において、複製ＤＡＧの所定ノードは、所定の時点にいくつかの役割のうちの１つが与えられ得る（例えば受諾、中間、コミッタ、または待機）。図６は、少なくともいくつかの実施形態による、ステート遷移要求（ＳＴＲ）の受信に応じて複製ＤＡＧの受諾ノードで行われ得る動作態様を示すフロー図である。構成要素６０１に示されるように、受諾ノードは、アプリケーションのＳＴＲを含むメッセージを、例えばステート複製サービスのクライアントから受信し得る。ＳＴＲは、アプリケーションの特質に部分的により、異なる実施形態において様々な構成要素を含み得る。例えば、さらに詳しく後述されるようにいくつかの実施形態において、ＤＡＧは、１つまたは複数のデータストアに対するトランザクションの楽観的並行処理制御に使用され、そしてＳＴＲは、前にコミットされたトランザクションとの競合を検出するために使用可能な読み出し集合及び書き込み集合等のデータを含み得る。複製ＤＡＧを使用してステート遷移が管理される各アプリケーションは、要求されたステート遷移に対する自身の受諾基準集合を有し、そして少なくともいくつかの事例において、遷移が受諾されるべきか拒否されるべきかを判定するために、ＳＴＲのコンテンツが使用され得る。いくつかの実施態様において、要求されたステート遷移を受諾／拒否するために、動作条件が同様または代わりに、使用され得る。例えば受諾ノードまたはＤＡＧの他のノードの作業負荷レベルが閾値以上の場合、ステート遷移は拒否され得る。遷移が受諾基準を満たす場合（構成要素６０４にて検出）、受諾ＳＴＲに対する新たな承認シーケンス番号が、例えばカウンタ値を増加させることで、またはある他の単調増加論理タイムスタンプ値を取得することで、生成され得る（構成要素６０７）。遷移が承認されたことを示すレコードは、シーケンス番号と一緒にローカル格納域に格納され得る（構成要素６１０）。いくつかのアプリケーションに関して、遷移要求は複製するデータ集合（書き込みペイロード等）を含み得る。受諾ノードは当該データ集合をローカル格納域に同様に格納し得る。一実施態様において、受諾ノードは、プロバイダネットワークの特定ホストで実行される１つまたは複数のプロセスを含み、そして遷移の承認のレコード、シーケンス番号、及び遷移のデータ集合は全て、当該特定ホストの持続的ディスクベース格納デバイスに格納され得る。いくつかの実施形態において、遷移のデータ、遷移が承認されたという開示、及びシーケンス番号は全て結合され、ログに挿入（または添付）されるログエントリ等、ローカル格納域に格納される単一オブジェクトに形成され得る。別の実施形態において、遷移のデータ集合は、遷移の承認を示すレコードとは別に格納され得る。
【００３９】
ステート遷移のレコードが無事格納された後、承認を示すステート遷移メッセージは、コミッタノードに向けてＤＡＧの複製経路沿いの隣接ノードへ送信され得る（構成要素６１３）。いくつかの事例において、ＤＡＧのトポロジーに応じて、複数のこのようなメッセージは、複製経路沿いのあるノードから各隣接ノードへ送信され得る。前述のように、ＤＡＧの各ノードは、ＤＡＧ構成に関する自身の見解を有し、これは所定の時点で必ずしも他のノードの見解と一致するとは限らない。描かれた実施形態において、受諾ノードはその受諾済みステート遷移メッセージを、ＤＡＧの構成の自身の現在の見解に示される隣接ノード（複数可）へ、たとえその現在の見解がＤＡＧのＤＣＭの見方と比べると（または１つまたは複数の他のＤＡＧノードの見方と比べると）図らずも古すぎるまたは誤りがあるとしても、送信し得る。メッセージ（複数可）の送信が完了すると、ステート遷移要求の処理は、受諾ノードにおいては完了したと見なされ得る（構成要素６１９）。要求された遷移がアプリケーションの受諾基準を満たさない場合（同様に構成要素６０４にて検出）、遷移は拒否され得る（構成要素６１６）。いくつかの実施態様において、拒否を示す通知または応答が、要求者に提供され得る。
【００４０】
図７は、少なくともいくつかの実施形態による、承認済みステート遷移メッセージの受信に応じて複製ＤＡＧの中間ノードで行われ得る動作態様を示すフロー図である。例えば受諾ノードから、または別の中間ノードから、このようなメッセージＳＴＭ１が受信された後（構成要素７０１）、いくつかの実施形態において、中間ノードは、より小さいシーケンス番号のステート遷移メッセージが欠損しているか否か（例えばＳＴＭ１がＳＮ１のシーケンス番号を有する場合、ＳＮ１より小さいシーケンス番号を有する未受信のＳＴＭが１つまたは複数存在するか否か）を判定し得る。描かれた実施形態において、このような欠損ステート遷移メッセージの証拠が見つかると（構成要素７０４）、中間ノードは、現在わかっている複製経路沿いの隣接先行ノードに対し、欠損ＳＴＭ（複数可）の再送要求を任意で提出し得る（構成要素７０７）。いくつかの実施態様において、中間ノードは、その再送要求に対する応答を受信するのを待ってから、ＳＴＭ１に対応する承認済みステート遷移のレコードをローカル格納域に格納し得る。ＳＴＭ１に対する承認レコードは、例えば承認シーケンス番号と、遷移に対応付けられた任意のデータ集合（書き込みペイロード等）と一緒に格納され得る（構成要素７１０）。ステート遷移メッセージ（既に受信されたメッセージとコンテンツが同様であり得る、あるいは既に受信されたメッセージとコンテンツが同一であり得る）はその後、コミッタノードに向けて現在わかっている複製経路（複数可）上の各隣接ノードに対し送信され得る（構成要素７１３）。ステート遷移の承認履歴がステート遷移メッセージに含まれるいくつかの実施態様において、中間ノードは、その（中間ノードの）識別子を、発信するステート遷移メッセージ内に示される承認者リストに追加し得る。
【００４１】
いくつかの実施形態において、ＳＴＭ１の承認レコードをローカル格納域に保存する前に欠損シーケンス番号を確認する代わりに、異なる手法が取られ得る。例えば、中間ノードは、承認レコードをローカル格納域に格納した後、及び／または対応ＳＴＭをコミッタノードに向けて送信した後、欠損シーケンス番号を確認し得る。
【００４２】
一実施態様において、所定の接続内でメッセージの順序正しい配信を保証する、ＴＣＰ（伝送制御プロトコル）等のネットワークプロトコルが、非受諾ノードにてＳＴＭを受信するためのプルモデルと組み合わせて使用され得る。このような実施態様において、中間ノード、コミッタノード、または待機ノードが複製経路沿いの自身の隣接先行ノードとのネットワーク接続を維持する限り、ネットワークプロトコルに依拠して、どのメッセージも確実に失わないようにし得る。このような実施態様において、所定ＤＡＧノードＮ１にて隣接先行ノードＰ１に対する接続を失った場合、Ｎ１は、Ｐ１に対する（またはＰ１がもはやＤＡＧの一部ではないことを示す構成デルタメッセージが受信された場合は異なる先行ノードに対する）新たな接続を確立し、前に受信済みの最大シーケンス番号より大きいシーケンス番号を有する全てのＳＴＭを送信するようにＰ１に要求する責務を担い得る。
【００４３】
図８は、少なくともいくつかの実施形態による、承認済みステート遷移メッセージの受信に応じて複製ＤＡＧのコミッタノードで行われ得る動作態様を示すフロー図である。例えば中間ノードから、または受諾ノードから、承認済みステート遷移メッセージを受信すると（構成要素８０１）、コミッタノードは、ステート遷移がアプリケーションのコミット基準を満たすか否かを判定し得る。いくつかの実施形態において、コミッタノードは、ＳＴＭのコンテンツ（承認履歴フィールド等）から、これまで保存されたアプリケーションステートレコードのレプリカの数を特定可能であり、そしてレプリカの数が閾値を超える場合には、遷移がコミット可能であると判断され得る。レプリカカウント閾値は、アプリケーションに基づいて異なり得る。例えば、いくつかのアプリケーションに関しては、受諾ノードに単一のレプリカで十分であり得る。別の実施形態において、コミッタノードはまた、遷移をコミットする前に、コミッタノードが現行のＳＴＭのシーケンス番号より小さいシーケンス番号を有する全てのＳＴＭを既に受信したか否か等、他の要素を考慮する必要があり得る。一実施形態において、例えば、コミッタノードは、現行遷移をコミットする前に、自身が全てのこのような前のＳＴＭを受信し処理するまで待機する必要があり得る。
【００４４】
コミット基準（アプリケーションにより異なり得る）が満たされた場合（構成要素８０４にて検出）、コミッタノードはコミットレコードを、ローカル格納域における自身のアプリケーションステートレコードの集合の中に、例えばシーケンス番号及び遷移データ集合（もしあれば）と一緒に格納し得る（構成要素８０７）。いくつかの実施態様において、コミット基準はデフォルトで、受諾ノードで既に検証された受諾基準に設定され得る。すなわち１度ステート遷移が受諾ノードで承認されると、コミッタノードは、いずれの追加条件も検証する必要なしに、受信したＳＴＭ内に示されるステート遷移をコミットし得る。いくつかの実施形態において、ＳＴＭ内に示される承認シーケンス番号のコピーが、コミットシーケンス番号として格納され得る。いくつかの承認済み遷移はコミットされ得ないため、少なくとも一実施形態において、承認に使用されるシーケンス番号の集合とは異なるシーケンス番号の集合がコミットに使用され得る（例えば一連のコミットシーケンス番号にいかなる欠落もないように）。待機ノードがＤＡＧに設定される場合、コミッタノードから１つまたは複数のこのような待機ノードに対し、コミット後ＳＴＭが送られ得る。少なくともいくつかの実施形態において、遷移がコミットされた後、ＤＡＧの１つまたは複数の他のノードがそれらのアプリケーションステート情報を更新できるように、及び／または遷移がコミットされたことを示す応答をステート遷移の要求クライアントに対し送信するために、コミットの通知がＤＡＧの１つまたは複数の他のノードへ提供され得る（構成要素８１０）。
【００４５】
欠損ＳＴＭがコミット基準に関した処理の一環として取り扱われないいくつかの実施形態において、コミッタノードは、欠損ＳＴＭに関して図７において示される行動と同様の行動を取り得る。従って、例えば、コミッタノードが１つまたは複数のＳＴＭ（受信したＳＴＭのシーケンス番号より小さいシーケンス番号を有するＳＴＭ）が欠損していると判定した場合（構成要素８１３）、欠損ＳＴＭの再送要求が隣接先行ノード（複数可）へ送信され（構成要素８１６）、受信したＳＴＭの処理は完了する（構成要素８２２）。コミット基準が満たされない場合、コミッタノードはステート遷移をアボートし得る（構成要素８１９）。いくつかの実施形態において、アボート通知が、ＤＡＧの１つまたは複数の他のノードへ、及び／またはステート遷移を要求したクライアントへ送信され得る。いくつかの実施態様において、前述のように、ステート遷移が受諾ノードにて承認された場合、複製ＤＡＧは、複製経路の１つまたは複数のノード（受諾ノード自体も含む）に障害が起こったとしても、（最終的に）ステート遷移をコミットする責務を担い得る。ステート遷移のアボートは、いくつかのこのような実施態様において、他のＤＡＧノードからの遷移の承認レコードの削除（または承認レコードが偶然格納されたノードのＤＡＧからの実際の削除）等、比較的重い変更を要し得る。図１１ａ〜図１４に関してさらに詳しく後述されるように、対応ステート遷移情報が所望数のＤＡＧノードに複製されることなくＳＴＭがコミッタノードに届くシナリオを回避するために、いくつかの実施形態において、先制的整合ＤＡＧ一時停止技術が使用され得る。
【００４６】
図９は、少なくともいくつかの実施形態による、複製ＤＡＧの構成マネジャー（ＤＣＭ）で行われ得る動作態様を示すフロー図である。構成要素９０１に示されるように、ＤＡＧにおける構成変更を潜在的に引き起こし得るイベントは、構成マネジャーにより検出され得る。このようなイベントは、「ノード障害が検出された」等のメッセージ（例えばＤＡＧノードから、またはプロバイダネットワークの正常性管理コンポーネントから）、または「サービス対応可能」等のメッセージ（例えば障害後に再始動したＤＡＧノードから）を受信することを含み得る。いくつかの実施形態において、構成マネジャー自体は、様々なＤＡＧノードの正常性ステータスを監視する責務を担い、そしてトリガーイベントは、構成マネジャーにより検出される、ノードのうちの１つが複数のハートビートメッセージまたは他の正常性確認に対し適時に応答しなかったことであり得る。少なくともいくつかの実施形態において、ＤＡＧノードは、いかなる見かけ上のノード障害も（例えば接続が突然終了した場合、または閾値より長い時間、隣接ノードから全くメッセージが受信されない場合）、ＤＣＭへ報告する責務を担い得る。ＤＡＧノードはまた、いくつかの実施形態において、ＤＡＧ構成変更をもたらし得る差し迫った変更（メンテナンスのためにノードが経路から外れる予定である場合等）を、ＤＣＭに通知する責務も担い得る。ＤＣＭは、描かれた実施形態において、示された構成変更（例えば障害が発生したノードの削除、または新たなノードの参加）を有効化するか否かを、例えばＤＣＭクラスタの複数のノード間で実施され得る同意プロトコルに基づいて、判定し得る（構成要素９０４）。例えば、いくつかの実施態様において、ＤＡＧノードに障害が発生したという１つのＤＣＭノードによる判定は、ＤＡＧノードが構成から削除される前に、クラスタの１つまたは複数の他のノードにおいて確認される必要があり得る（例えばＤＡＧノードから受信されるハートビート応答を他のＤＣＭノードにて再検討することにより）。別の実施態様において、可能性のある構成変更を適用するか否かに関する判定は、同意ベースプロトコルを使用せずに行われ得る。ＤＡＧ構成変更に対応付けられたシーケンス番号または論理タイムスタンプは、いくつかの実施形態において、例えばＤＡＧの他のノードに送信される構成デルタメッセージに含めるために決定または生成され、そのため構成変更は、ＤＡＧノードにて正しい順序で処理され得る。
【００４７】
構成変更がどのように承認されたかに関係なく、いくつかの実施形態において、変更が完了したとみなされる前に、構成変更の表現は、ＤＣＭの複数の格納位置に複製される必要があり得る（構成要素９０７）。構成変更に関する情報を複数の位置に保存することは、ＤＣＭがＤＡＧ構成情報の正式な情報源として機能する実施形態において、ＤＣＭの機能の重要な態様であり得る。少なくともいくつかの実施態様において、構成に対する変更のみ（例えば構成全体ではなく）が複製され得る。構成変更情報が保存された後、ＤＣＭから対応構成デルタメッセージ（構成に対し実施したばかりの変更を示し、必ずしもＤＡＧの構成全体を示さない）を送る送信先ＤＡＧノードの集合が特定され得る（構成要素９１０）。いくつかの実施形態において、全ＤＡＧメンバー（構成デルタメッセージ内に示される構成変更の一環としてＤＡＧから削除されるノードも潜在的に含む）は、構成デルタメッセージの送信先として選択され得る。一実施形態においては、現行のＤＡＧメンバーとみなされるノードのみが選択され得る。例えば、ノードが削除される、またはノードに障害が起こったと思われる場合には、当該ノードに対し構成デルタメッセージは送信され得ない。別の実施形態においては、メンバーのある部分集合が送信先として選択され、そしてその部分集合は、残りのノードに対し構成変更を伝播する責務を担い得る。メンバーの部分集合が送信先として選択される実施形態において、ＤＣＭは、いずれかの所定の時点でどの変更がどのメンバーに伝播されたか記録を保持する必要があり得る。送信先となるＤＡＧノードの集合が特定された後、それらに対しそれぞれの構成デルタメッセージが、お互いに非同期的に、そしてステート遷移メッセージ処理またはステート遷移要求処理におけるいかなる中断も要求することなく、送信され得る（構成要素９１３）。少なくともいくつかの実施形態において、構成デルタメッセージは、構成変更に対応付けられた構成シーケンス番号を含み得る。いくつかの実施態様において、複合構成デルタメッセージは、２つ以上の変更（例えば障害ノードの削除と交代ノードの参加）を示し得る。
【００４８】
図１０は、少なくともいくつかの実施形態による、構成マネジャーからの構成デルタメッセージの受信に応じて複製ＤＡＧのメンバーノードで行われ得る動作態様を示すフロー図である。ＤＣＭから構成変更シーケンス番号を含むような構成デルタメッセージを受信すると（構成要素１００１）、受信ＤＡＧノードは、描かれた実施形態において、例えば新たに受信したシーケンス番号を前に受信済みの最大シーケンス番号と比較することで、全ての前の構成デルタメッセージを自身が受信したか否かを判定し得る。受信ノードが、１つまたは複数の構成デルタメッセージをまだ受信していないと判定すると（構成要素１００４）、受信ノードは、構成更新要求をＤＣＭに送信し得る（構成要素１００７）。このような更新要求により、例えば、ＤＣＭは欠損構成デルタメッセージ（複数可）を再送する、またはＤＡＧの現行の構成全体が示される別の種類のメッセージが送信される。
【００４９】
欠損構成デルタメッセージが検出されない場合（同様に構成要素１００４の対応動作において）、受信ノードは、受信された構成変更情報を、ローカル格納域内の構成変更レポジトリに格納し得る。レポジトリに蓄積されるメッセージは、ＤＡＧ構成に関する受信ノードの見解を更新するのに使用され得る（構成要素１０１０）。ＤＡＧ構成のローカル見解を更新することは、例えば、先々の送信及び受信ステート遷移メッセージに使用する複製経路（複数可）の１つまたは複数のＤＡＧノード及び／または辺を特定することを含み得る。前述のように、メッセージ配信の非同期的特質のため、及びネットワークの異なる箇所において異なる遅延が発生し得るため、構成デルタメッセージが１つのＤＡＧノードにて取得される順序は、同じ構成デルタメッセージ集合が別のノードにて受信される順序とは異なり得る。従って、所定の時点で２つの異なるノードにて特定される複製経路は、お互いに異なり得る。描かれた実施形態において、受信ノードは、複製経路上の自身の隣接先行ノードが変更したら、もしくは自身の隣接後続ノードが変更したら、さらなる行動を取り得る。隣接後続ノードも隣接先行ノードも変更していない場合、いくつかの実施形態において、構成デルタメッセージの処理は、構成変更情報が受信ノードのローカル格納域に格納された後に終了し得る（構成要素１０２７）。
【００５０】
ＤＡＧのノードＣに関して隣接先行ノードが変更されるシナリオの実施例として、Ａ〜Ｂ〜ＣからＡ〜Ｃへの複製経路の部分的変更がある。更新された構成が受信ノードの隣接先行ノードの変更を伴い、かつ新たな隣接先行ノードからまだ直接メッセージが受信されていない場合（構成要素１０１３にて検出）、受信ノード（現実施例においてノードＣ）は、新隣接先行ノード（現実施例においてノードＡ）への接続を確立し得る。さらに、少なくともいくつかの実施形態において、受信ノード（例えばノードＣ）はまた、受信ノードがごく最近受信したシーケンス番号より大きいシーケンス番号を有するＳＴＭの再送要求を、新隣接先行ノード（例えばノードＡ）に送信し得る（構成要素１０１７）。ノードＣに後続ノードが存在する場合、ノードＣは、要求した再送をノードＡから受信するのを待ちながら、そのような後続ノードに対しいずれの承認待ちステート遷移メッセージも送信し続け得る。
【００５１】
受信ノードの隣接後続ノードが変更したことを構成デルタメッセージが示し（例えばノードＢがＤＡＧ離脱したことを示す、前述と同じ実施例の構成デルタメッセージをノードＡが受信し）、かつ新隣接後続ノードから何もメッセージが受信されていない場合（構成要素１０２１）、受信ノードは新後続ノードへの接続を確立し得る。前の実施例において、ノードＡは、その隣接後続ノードであるノードＣへの接続を確立し得る。ステート遷移メッセージは、引き続き新隣接後続ノードへ転送され得る（構成要素１０２４）。
【００５２】
複製ＤＡＧノードの整合一時停止
大多数のアプリケーションの略同時機能停止を生じ得る大規模な障害イベントは、プロバイダネットワークのオペレータにとって重大な課題である。長期間の機能停止の影響を受けるアプリケーションの顧客は、プロバイダネットワークがクリティカルアプリケーションに必要なレベルのサービスを提供する能力を信用できなくなり得る。知的インフラストラクチャ設計により、またインフラストラクチャの高可用性特性を利用し得るアプリケーションアーキテクチャを実装することにより、大規模な障害イベントの確率は低減され得るが、大規模障害を完全に取り除くことは不可能であり得る。従って、複数のリソースに影響する障害から分散アプリケーションがより速くクリーンに回復することを可能にし得る技術が、少なくともいくつかの実施形態において開発され得る。分散アプリケーションステート管理に前述の種類の複製ＤＡＧが採用されるいくつかの環境において、分散障害からのより効果的かつ効率的な復旧を支援するために、整合一時停止プロトコルが使用され得る。一実施形態において、例えば、障害シナリオの検出に応じて、ＤＡＧの複数のノードは、それらの通常アプリケーションステート遷移処理動作（例えばステート遷移要求メッセージの受信、アプリケーションステート情報のローカルコピーの格納、及びそれらの複製経路（複数可）沿ったステート遷移要求メッセージの送信）の実行を停止するように、構成マネジャーにより命じられ得る。それらの動作を一時停止した後、少なくともいくつかの実施形態において、ノードはそれらのローカルアプリケーションステートレコードを他のＤＡＧノードと同期させ、クリーンシャットダウン及び再始動を行い得る。ノードの再始動後、ノードは、自身がサービス再開可能であることを構成マネジャーに折り返し報告し、構成マネジャーによるＤＡＧの再開を待機し得る。
【００５３】
図１１ａ〜１１ｈは、少なくともいくつかの実施形態による、このような整合一時停止手続き中に複製ＤＡＧで行われ得る例示的一連動作を集合的に示す。例示的ＤＡＧにおける各ノードは、それぞれのコミットレコード集合を格納し、各コミットレコードは対応コミットシーケンス番号（ＣＳＮ）を含む（または例えばポインタにより示す）。ローカルコミットレコード集合は従って、ノードの視点から、ＤＡＧを使用して管理されているアプリケーションのステートを表し得る。承認済み（しかしまだコミットされていない）ステート遷移のレコードも、前述のように、一部または全てのノードにて保持され得る。ＤＡＧ構成変更に関してＤＡＧノードを更新し続けるために前述のようにＤＣＭが構成デルタメッセージを送信する動的複製ＤＡＧとの関連で、整合一時停止技術が本明細書において説明されるが、いくつかの実施形態において、同様の手法が他のステート複製技術にも採用され得ることに留意されたい。例えば、整合一時停止技術は、全てのノードが同期的に更新される世界停止再構成間隔を使用して複製ノードのグループに対する構成変更が実施される環境においても使用され、この場合、全てのノードが新構成に関して認識させられた後にのみ複製グループは作動可能になる。従って、動的複製ＤＡＧは、整合一時停止技術が異なる実施形態において実施され得る複数ノードステート複製グループ（ＳＲＧ）の一例を表し得るにすぎない。少なくともいくつかのこのようなＳＲＧは、前述のＤＣＭに類似した自身の構成マネジャーを有し、コミッタノードとして指定されたいくつかのノードと、非コミッタノードとして指定された他のノードとを有し得る。
【００５４】
５つのノード１１０２Ａ、１１０２Ｂ、１１０２Ｃ、１１０２Ｄ、１１０２Ｅを備える複製ＤＡＧが、ＤＣＭ１１８０と一緒に図１１ａに示される。描かれた実施例において、コミッタノード１１０２Ｅは、ＤＡＧのために整合一時停止手続きが開始されるべきであることを判定する一時停止トリガー検出器１１０６を備える。多数の異なる種類の原因が、異なる実施形態において一時停止手続きの開始を引き起こし得る。例えば、一時停止手続きが開始され得る理由として、（ａ）ある閾値数のノードに障害が起こり得たため（「Ｘ」印で示されるノード１１０２Ｂ及び１１０２Ｄにおける障害等）、（ｂ）構成デルタメッセージがコミッタノードにて（またはある他のノードにて）受信されているレートが閾値を超えるため、（ｃ）あるＤＡＧノードまたはＤＣＭにてネットワークパケットまたは接続が落ちているレートが閾値を超えるため、等が挙げられる。描かれた実施形態におけるコミッタノード１１０２Ｅは、コミッタノードのコミットレコード集合内に表されるシーケンス番号中の最大シーケンス番号を含むＤＡＧ一時停止要求１１５０を送信する。当該最大シーケンス番号は、本明細書において最大コミット済みシーケンス番号（ＨＣＳＮ）１１０８と称され、後述のように一時停止手続きのステップのうちの１つの間に、ＤＡＧノード間のコミットレコード集合を同期するための参照として使用され得る。いくつかの実施形態において、一時停止が開始されるべきであるという初期判定は、非コミッタノードのうちの１つにて、またはＤＣＭ１１８０自体にて行われ、そしてノードが自身のコミットレコード集合を更新する際目標とすべき目標シーケンス番号として、特定のコミットシーケンス番号（理想的にはＨＣＳＮであるが必ずしもではない）が選択され得る。
【００５５】
一時停止要求の受信に応じて、ＤＣＭ１１８０は、図１１ｂに示されるように、持続的格納域１１７５にＨＣＳＮを保存し得る。ＤＣＭはそれから、ＤＡＧノードの少なくとも部分集合に対しそれぞれの一時停止命令１１５２を、例えば描かれた例示的シナリオにおいてノード１１０２Ａ、１１０２Ｃに対し命令１１５２Ａ、１１５２Ｂをそれぞれ送信し得る。いくつかの実施形態において、ＤＣＭ１１８０は、ＤＣＭに保存されている最新のＤＡＧ構成（１１０２Ｂ及び１１０２Ｄ等の障害が起こり得たノードを含む）に従って、ＤＡＧのメンバーである全てのＤＡＧノードに対し、一時停止命令を送信し得る。一時停止命令はＨＣＳＮ１１０８を含み得る。
【００５６】
一時停止命令を受信すると、ＤＡＧノードは、ステート遷移要求／メッセージの処理を停止し、その代わりに自身のコミットレコード集合が、ＨＳＣＮに対応するコミットレコードを含むそれ以下のコミットレコードを全て含むことを検証するプロセスを開始し得る。例えば、ノード１１０２Ａ及びノード１１０２Ｃは、コミッタノード１１０２Ｅにより、ＨＣＳＮ以下のシーケンス番号を有する１つまたは複数のコミット済みステート遷移に関してまだ通知されていなかったという場合もあり得る。このようなシナリオにおいて、図１１ｃに示されるように、ノード１１０２Ａは、コミットレコード同期要求１１７２Ｂをコミッタノード１１０２Ｅに対し送信し（「１ａ」と表示される矢印により示されるように）、そしてノード１１０２Ｃは同様のコミットレコード同期要求１１７２Ｂをノード１１０２Ｅに対し送信し得る（「１ｂ」と表示される矢印により示されるように）。コミットレコード同期要求１１７２は、要求を送信したノードにて欠損しているコミットレコードの開示をそれぞれ含み、例えば、ノード１１０２Ａは、ＳＮ１までのシーケンス番号を有するコミットレコードを自身が既に有することを示し、一方ノード１１０２Ｃは、シーケンス番号ＳＮ２、ＳＮ３、ＳＮ４を有するコミットレコードを自身は受信していないことを示し得る。「２ａ」、「２ｂ」と表示される矢印により示されるように、その後、欠損コミットレコード１１７４Ａ、１１７４Ｂが、コミッタノードによりノード１１０２Ａ、１１０２Ｃに対しそれぞれ送信され得る。「３ａ」、「３ｂ」と表示される矢印により示されるように、ノード１１０２Ａ、１１０２Ｃはその後、それぞれの同期確認１１７６Ａ、１１７６ＢをＤＣＭ１１８０へ送信し得る。「４」と表示される矢印により示されるように、ＤＣＭ１１８０は、ＤＣＭの持続的格納域１１７５にて保持される最新状態ノードリスト１１３３（すなわちコミッタノード１１０２Ｅのコミットレコード集合に一致するように自身のコミットレコード集合を更新したノードのリスト）に、ノード１１０２Ａ、１１０２Ｃを追加し得る。
【００５７】
図１１ｄに示されるように、描かれた実施形態において、ＤＡＧのノードは、実行を終了し、自身を再始動し得る。障害が起こったノード１１０２Ｂ、１１０２Ｄは、例えば、自身の障害からの復旧の一環として再始動し得る。整合一時停止手続きの一環として、ノード１１０２Ａ、１１０２Ｃは、自身のコミットレコード集合がコミッタノードのものと同期された後に、自身のコミットレコード集合（及び／またはノードの動作に関係する追加メタデータ）をローカル格納域に保存し、それから制御された再始動を開始し得る。ノード１１０２Ｅは、描かれた実施形態において、自身が一時停止要求１１５０を送信した後、ある時間間隔待機し（少なくともいくつかの同期要求１１７２にコミッタノードが応答可能なように）、いずれのステートメタデータもローカル格納域に保存し、それから一時停止手続きの一環として自身の制御された再始動を開始し得る。
【００５８】
図１１ｅに示されるように、ＤＡＧノード１１０２Ａ〜１１０２Ｅが経路上に戻った後、いくつかの実施形態において、これらのノードはＤＣＭ１１８０に対し各自の「サービス対応可能」メッセージをそれぞれ送信し、再開命令を待ってから、それらのアプリケーションステート遷移処理動作を再開し得る。ＤＣＭは、ノード１１０２Ｂ、１１０２Ｄのコミットレコード集合は最新ではあり得ないことを識別可能であり（自身の最新状態ノードリスト１１３３を使用して）、従って、図１１ｆに示されるように、それぞれの同期命令１１９４をノード１１０２Ｂ、１１０２Ｄに対し送信し得る。少なくともいくつかの実施態様において、同期命令はＨＣＳＮ１１０８を示し得る。同期命令１１９４に応じて、ノード１１０２Ｂ、１１０２Ｄは、それぞれのコミットレコード集合において欠損しているコミットレコードを示す自身のコミットレコード同期要求１１７２Ｃ、１１７２Ｄを、最新とわかっているノードに対し各自送信し得る。例えば、ノード１１０２Ｂは、その同期要求１１７２Ｃをノード１１０２Ａに対し送信し、一方ノード１１０２Ｄはその同期要求をノード１１０２Ｅに対し送信し得る。いくつかの実施形態において、ＤＣＭは、コミットレコード同期要求を送るべき送信先ノードを特定し得る。一実施形態において、全ての非コミッタＤＡＧノードは、それらのコミッタレコード集合をコミッタノードと同期する必要があり得る。ノード１１０２Ｂ、１１０２Ｄは、それらの欠損コミットレコード１１７４Ｃ、１１７４Ｄをそれぞれ受信し、そのため最終的に全てのノードが自身のコミットレコード集合をＨＣＳＮまで同期される。いくつかの実施態様において、ノード１１０２Ｂ、１１０２Ｄは、それらのコミットレコード集合が更新／同期されたことを示す確認を、ＤＣＭ１１８０へ送信し得る。少なくとも一実施形態において、ＤＣＭは、その最新状態ノードリストに含まれないノードに関して、図１１ｆに関して前述されたものと比べて多少より受動的な役割を担い得る。このような実施形態において、障害が発生したノード（１１０２Ｂまたは１１０２Ｄ等）は、経路上に戻ると、新たに経路上に設定された当該ノードが全てのコミットレコードを受信したか否かを判定するためのメッセージを、ＤＣＭに対し送信する。ＤＣＭは当該ノードに対し、最新状態のノードとなるには、ＨＣＳＮまでのシーケンス番号を有するコミットレコードが必要であることを（例えば単純にＨＣＳＮを示すことにより）通知し得る。それから当該ノードは、自身を最新状態にする責務と、自身のコミットレコードをＨＣＳＮまで同期したらＤＣＭへ折り返し報告する責務を担い得る。従って、このような実施形態において、ＤＣＭは必ずしも同期命令１１９４を送信するとは限らず、代わりに新たに経路上に設定されたノードが、自身のコミットレコード集合を同期する主導権を握り得る。
【００５９】
少なくとも閾値数のノードがコミットレコード集合を更新したことを確認した後、ＤＣＭ１１８０は、再開後のＤＡＧの構成を決定し得る。いくつかの事例においては、一時停止の前に使用されていた構成と同じ構成が再使用され、一方、別の実施形態においては、異なる構成が選択され得る。例えば、ＤＡＧは最低４つのノードを有さなければならない場合もあり、そのためノード１１０２Ａ〜１１０２Ｅのうちの４つのみが最初に選択され得る。図１１ｇに示されるように、ＤＣＭ１１８０は、選択されたノード集合（描かれた実施例においては５つのノード全て）に対し、ＤＡＧの現行構成を示すそれぞれの再開メッセージを送信し得る。ＤＡＧノードはそれから、図１１ｈに示されるように、通常動作を再開し得る。いくつかの実施形態において、障害が発生しなかったＤＡＧノード（例えば１１０２Ａ、１１０２Ｃ、１１０２Ｅ）のうちの少なくともいくつかは、必ずしも自身を再始動するとは限らない。代わりに、このようなノードのうちの１つまたは複数は、このような実施形態において、自身のコミットレコード集合を同期した後、自身がＤＣＭから再開命令を受信するまで、さらなるステート遷移処理を単純に延期し得る。
【００６０】
図１２は、少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のＳＲＧのコミッタノードで行われ得る動作態様を示すフロー図である。構成要素１２０１に示されるように、コミッタノードは、ＳＲＧの整合一時停止のトリガー基準が満たされたことを判定し得る。例えば、応答可能な状態のＳＲＧノードの数が閾値を下回ったこと、またはＳＲＧの構成変更が起こっているレートが閾値を超えることが、コミッタノードにより検出されることを含む、様々な異なるトリガー条件により、整合一時停止が引き起こされ得る。いくつかの事例において、例えば、ネットワークパケットが抜け落ちるレートが閾値を超える場合、または最大許容レート以上のレートで接続が突然終了されている場合等、リソース作業負荷レベル、またはエラーレートが一時停止を引き起こし得る。一実施形態において、ＳＲＧの非コミッタノード、またはＤＣＭ等の構成マネジャーが、制御された一時停止を引き起こすであろう問題を最初に検出し、当該問題をコミッタノードに通知し得る。
【００６１】
描かれた実施形態において、コミッタノードは、制御された一時停止を開始することを決定した後、ステート遷移メッセージに関する自身の通常処理／複製を中断または停止し、まだ保存されておらず未処理のいずれのコミットレコードもローカル格納域に保存し得る（構成要素１２０４）。コミッタノードはそれから、ＨＣＳＮ（コミットレコードがコミッタノードにより格納された遷移のシーケンス番号の中で最大のコミット済みシーケンス番号）の開示を含む一時停止要求を、ＳＲＧの構成マネジャー（例えば複製ＤＡＧの場合はＤＣＭ）に対し送信し得る（構成要素１２０７）。ＨＣＳＮは、目標コミットシーケンス番号として機能し、ＳＲＧの現在作動中のノードは、自身のコミットレコード集合を当該目標コミットシーケンス番号まで同期する。
【００６２】
少なくともいくつかの実施形態において、コミッタノードは、一時停止要求を送信した後、他のＳＲＧノード（例えばＨＣＳＮまでのシーケンス番号を有する全てのコミットレコード集合を自身は有さないと判定したノード）から、複数のコミットレコード同期要求を受信し得る（構成要素１２１０）。描かれた実施形態において、コミッタノードは、設定可能時間窓の間に受信されたいずれのそのような同期要求に応答する。コミッタノードはそれから任意で、クリーンシャットダウン及び再始動を行い、サービス対応可能メッセージをＳＲＧの構成マネジャーに送信し得る（構成要素１２１３）。いくつかの実施形態において、クリーンシャットダウン及び再始動は省略され、そしてコミッタノードは単純にサービス対応可能メッセージを送信し得る、あるいはコミッタノードは構成マネジャーから再開命令を受信するまで、さらなるステート遷移関連処理を単純に延期し得る。最終的に、コミッタノードは、構成マネジャーからＤＡＧの現行一時停止後構成を示す再開メッセージを受信し、それからコミッタノードは、示される構成通りに、ステート遷移関連処理を再開し得る（構成要素１２１６）。例えば、いくつかの実施形態において、新たな一時停止後構成では、コミッタノードはもうコミッタの役割を与えられず、代わりに、受諾ノード、中間ノード、または待機ノードに設定され得る場合もあり得る。
【００６３】
図１３は、少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のステート複製グループの非コミッタノードで行われ得る動作態様を示すフロー図である。通常動作中、非コミッタノードは、対応遷移がコミットされた後のある時点に、コミットレコードをローカル格納域に格納し得る。その結果、非コミッタノードのローカルコミットレコード集合は、必ずしもコミッタノードのもの程最新であるとは限らない。構成要素１３０１に示されるように、非コミッタノードは、非コミッタノードが自身のローカルコミットレコード集合を同期する際目標とすべき目標シーケンス番号としてＨＣＳＮを示す一時停止命令を、構成マネジャーから受信し得る。
【００６４】
一時停止命令を受信すると、非コミッタノードは、新たなステート遷移メッセージの処理を中断または停止し得る。ＨＣＳＮより小さいシーケンス番号を有するいくつかのコミットレコードがローカルコミットレコード集合から欠損している場合、非コミッタノードは、欠損レコードのコミットレコード同期要求を、コミッタノードへ（または構成マネジャーにより欠損コミットレコードの情報源として指示された別のノードへ）送信し得る（構成要素１３０４）。非コミッタノードのコミットレコード集合がＨＣＳＮに関して既に最新状態である場合、非コミッタノードは、一時停止手続きの当段階において、他のノードと通信しなくてもよい。ＨＣＳＮまでのシーケンス番号を有するコミットレコードがローカル格納域に格納されたことが確認された後、描かれた実施形態において、非コミッタノードは、構成マネジャーに対し同期確認メッセージを送信し得る（構成要素１３０７）。非コミッタノードはそれから、構成マネジャーにより再開されるまで、さらなるアプリケーションステート遷移処理を延期し得る。任意で、非コミッタノードは、クリーンシャットダウン及び再始動を行い、再始動後、「サービス対応可能」メッセージを構成マネジャーに送信し得る（構成要素１３１０）。構成マネジャーからの再開メッセージに応じて、非コミッタノードは、ＳＲＧ構成に関する自身の見解を更新し、アプリケーションステート遷移処理を再開し得る（構成要素１３１３）。場合によっては、構成マネジャーにより、一時停止後構成において非コミッタノードに異なる役割が与えられ得る。例えば非コミッタノードの役割はコミッタノードに変更され得る。
【００６５】
図１４は、少なくともいくつかの実施形態による、整合一時停止手続き中に複製ＤＡＧ等のステート複製グループの構成マネジャーで行われ得る動作態様を示すフロー図である。構成要素１４０１に示されるように、構成マネジャーは、ＳＲＧのコミッタノードから、コミットレコードがコミッタノードに格納されている遷移のシーケンス番号のうちの最大コミット済みシーケンス番号（ＨＣＳＮ）を示す一時停止要求を受信し得る。いくつかの実施形態において、ＳＲＧ動作を一時停止する決定が最終的になされる前に、構成マネジャーの様々なノード間で同意プロトコルが採用され得る。構成マネジャーは、ＨＣＳＮを持続的格納域に格納し（構成要素１４０４）（例えば、構成マネジャークラスタのいくつかのノードにおけるそれぞれの格納デバイスにて）、ＨＣＳＮを示す一時停止命令をＳＲＧの１つまたは複数の他のノードへ送信し得る（構成要素１４０７）。いくつかの実施形態において、一時停止命令は、障害が起こったと思われるノードを含むＳＲＧのわかっているメンバー全てに対し送信され得る。ＳＲＧの受信ノードはそれぞれ、自身のローカルコミットレコード集合がＨＣＳＮに対応するコミットレコードを含むことを確認し得る（場合によっては、受信ノードは前述のようにコミッタノードから欠損コミットレコードを取得しなければならない）。一時停止命令の受信ノードは、自身のコミットレコード集合がＨＣＳＮに関して最新であることを確認した後、構成マネジャーに対し、自身のコミットレコード集合が現時点で最新であることを示す同期確認を送信し得る。従って、構成マネジャーは、ＳＲＧノードからこのような確認を受信すると、当該ノードを最新状態ノードのリストに追加し得る（構成要素１４１０）。
【００６６】
いくつかの実施形態において、構成マネジャーは、ＳＲＧノードからそれらがサービス対応可能であることを示すそれぞれのメッセージを受信するのを待ってよい。構成マネジャーは、そのようなメッセージをノードから受信すると（例えばノードがクリーンシャットダウン及び再始動を完了した後に、またはノードが障害後に経路上に戻った後に）、ノードが最新状態ノードリストに含まれるか否かを特定し得る。受信した「サービス対応可能」の開示の送信元であるノードがコミットレコードに関して最新であるかわからない場合、構成マネジャーは、例えば明示的同期命令で、またはノードからの暗示的または明示的クエリに応じて、ノードに対しＨＣＳＮの開示を送信し得る（構成要素１４１３）。それからノードは、コミットレコードを更新する際の目標シーケンス番号としてＨＣＳＮを使用して、既に最新状態の他のノードと通信することで、自身のローカルコミットレコード集合を更新し得る。いくつかの実施形態において、構成マネジャーは、同期命令に、古い状態のノードが欠損コミットレコードを取得するべき取得先となる情報源の開示を含み得る。
【００６７】
構成マネジャーは、必要最低数のＳＲＧノードが（ａ）サービス対応可能であり、（ｂ）アプリケーションコミットステートに関して最新状態であることを確認した後、ＳＲＧの一時停止後初期構成を完成し得る（構成要素１４１６）。それから構成マネジャーは、構成を示す再開メッセージを、初期構成に含まれる適切なノード集合に送信し得る（構成要素１４１９）。いくつかの実施形態において、初期構成情報は、一連の構成デルタメッセージとしてノードに対し提供され得る。
【００６８】
少なくともいくつかの実施形態において、同期のために選択される目標シーケンス番号（すなわちＳＲＧの複数のノードそれぞれが自身のローカルコミットレコード集合を更新する際目標とするシーケンス番号）は、必ずしも最大コミット済みシーケンス番号である必要はない。例えば、コミッタノードにおける最大コミット済みシーケンス番号がＳＮ１であり、そして速く拡大する大規模障害イベントの検出を受けてＳＲＧの動作を一時停止することが急務であるため、ＳＲＧ構成マネジャーは、ノードが自身のコミットレコードをより小さいシーケンス番号（ＳＮ１−ｋ）まで更新した後にそれらの動作を一時停止することを進んで許可し得る場合もあり得る。いくつかの実施態様において、ＳＲＧのノードは、一時停止／再始動する前に、自身のコミットレコードをあるより小さいシーケンス番号まで同期し、一時停止の後、例えばノードが再始動し、「サービス対応可能」メッセージを構成マネジャーに送信した後に、最大コミット済みシーケンス番号まで同期し得る。前述のように、いくつかの実施形態において、一時停止手続きは、非コミッタノードにより、または構成マネジャー自身により開始され得る。
【００６９】
複数データストアトランザクションのためのログベース楽観的並行処理制御
いくつかの実施形態において、複数の独立データストアを伴うトランザクションに対応することを可能にするログサービスを使用して楽観的並行処理制御技術を実施するために、前述の種類の複製ＤＡＧが使用され得る。図１５は、少なくともいくつかの実施形態による、複数のデータストアへの書き込みを含み得るトランザクションに対応する持続的変更ログを備える例示的システム環境を示す。システム１５００は、ログサービスを使用してインスタンス化され得る持続的変更ログ１５１０を示す。描かれた実施形態において、データストア１５３０Ａ（例えばＮｏＳＱＬまたは非リレーショナルデータベース）及びデータストア１５３０Ｂ（例えばリレーショナルデータベース）等の１つまたは複数のデータストア１５３０が、トランザクション管理のためにログサービスにおいて登録され得る。用語「並行処理制御」、「トランザクション管理」、及び「更新管理」は、ログサービスにより提供される機能に関して類義語として本明細書において使用され得る。ログサービスは、いくつかの実施形態において、プロバイダネットワークにて実施され得る複数の格納サービスのうちの一例とみなされ得る。
【００７０】
クライアント１５３２は、いくつかの実施形態において、それらが特定のアプリケーションのログベーストランザクション管理を適用したいデータソース集合を示す登録要求を、例えばログサービスマネジャー１５０１により提示される管理または制御プレーンプログラマチックインターフェースを介して、提出し得る。持続的変更ログ１５１０は、いくつかの実施形態において、このような登録要求に応じてインスタンス化され得る。一般に、所定の持続的変更ログインスタンスは、１つまたは複数の基礎データストアのトランザクションを管理するために作成され得る。すなわち、少なくともいくつかの展開において、ログベーストランザクション管理は、複数のデータストアに同時ではなく、単一のデータストアに使用され得る。本明細書において使用される用語「データストア」は、幅広い種類の持続的または一時的データレポジトリ及び／またはデータコンシューマのうちのいずれかのインスタンスを指し得る。例えば、いくつかのデータストアは、複数アイテムトランザクションに対しネイティブ対応を必ずしも提供するとは限らない持続的非リレーショナルデータベースを備え、一方、他のデータストアは、複数アイテムトランザクションに対しネイティブ対応を行い得る持続的リレーショナルデータベースを備え得る。いくつかの実施形態において、プロバイダネットワークのユーザが任意のサイズの非構造化データオブジェクトを格納することを可能にする、ウェブサービスインターフースを介してアクセス可能なプロバイダネットワークのネットワークアクセス可能格納サービスが、データストアのうちの１つとして登録され得る。他の種類のデータストアは、インメモリデータベース、分散キャッシュのインスタンス、ネットワークアクセス可能ブロック格納サービス、ファイルシステムサービス、またはマテリアライズドビューを含み得る。少なくとも一実施形態において、データストアのうちの１つまたは複数は、プロバイダネットワークにおいて実施される待ち行列サービス及び／または通知サービスのコンポーネントを含み得る。例えば新たなデータアーチファクトを生成するために、ログサービスにより記録されたコミット済み書き込みを使うエンティティは、別の種類のデータストアを表し、本明細書において一般的に「データコンシューマ」と称され得る。このようなデータストアは、例えば、ログサービスを介して管理される特定データ集合に対する特定クエリの結果を生成する責務を担う事前演算クエリ結果マネジャー（ＰＱＲＭ）（データストア１５３０Ｃと同様）を含み得る（特定データ集合は１つまたは複数の異なる他のデータストアに格納されたオブジェクトを含み得る）。いくつかの実施形態において、ログサービスを介して管理される一部または全てのコミット済みデータの時点スナップショットを生成するように構成されたスナップショットマネジャーは、別のカテゴリのデータストアを表し得る。このようなログスナップショットは、異なる実施形態において、バックアップのため、またはオフライン作業負荷分析のため等、様々な目的で格納され得る。用語「データコンシューマ」は、ＰＱＲＭ及びスナップショットマネジャー等のデータストアを指すために、本明細書において使用され得る。データストアのうちの少なくともいくつかは、他のデータストアの読み出しインターフェース１５３１とは異なる読み出しインターフェース１５３１を有し得る。例えば、描かれた実施形態において、データストア１５３０Ａのデータストア（ＤＳ）読み出しインターフェース１５３１Ａは、ＤＳ読み出しインターフェース１５３１Ｂまたは事前演算クエリインターフェース１５３１Ｃとは異なるＡＰＩ集合、ウェブベースインターフェース、コマンドラインツール、またはカスタムＧＵＩ（グラフィカルユーザインターフェース）を備え得る。
【００７１】
描かれた実施形態において、ログサービスクライアント１５３２は、トランザクション要求をローカルで構築し、それからトランザクション要求を、持続的変更ログ１５１０による承認及びコミットのために提出（または「提案」）し得る。一実施態様において、例えば、ログサービスのクライアント側ライブラリにより、クライアントは「トランザクション開始」要求の論理的均等物を発行することにより、候補トランザクションを開始することが可能となり得る。候補トランザクション内で、クライアントは、データストア１５３０における選択オブジェクト集合に対し複数の読み出しを行い、１つまたは複数のデータストアに対する提案書き込み集合をローカルで（例えばローカルメモリにおいて）行い得る。クライアントはそれから、「トランザクション終了」要求の均等物を発行することにより、候補トランザクションを提出し得る。描かれた実施形態において、候補トランザクション要求１５１６は、ログの書き込みインターフェース１５１２を介して、持続的変更ログ１５１０に対応付けられた競合検出器１５０５にて受信され得る。一般に、少なくともいくつかの実施形態において、所定のトランザクション要求１５１６は、１つまたは複数のデータストアそれぞれからの１つまたは複数の読み出しと、１つまたは複数のデータストアにそれぞれ対する１つまたは複数の提案書き込みとを含み、読み出されるデータストア集合は、書き込まれているデータストア集合と重複し得る、あるいは重複し得ない。いくつかの実施形態において、読み出しは、ネイティブＤＳ読み出しインターフェース１５３１を使用して行われ得る（しかし後述のように、いくつかのシナリオにおいて、クライアントは持続的変更ログ１５１０を介して読み出し専用動作も実行し得る）。
【００７２】
いくつかの実施形態において、所定のトランザクション要求内に示される書き込みのうちの少なくともいくつかは、読み出しのうちの１つまたは複数の結果に依存し得る。例えば、要求トランザクションは、データストアＤＳ１における位置Ｌ１から１つの値Ｖ１と、データストアＤＳ２における第２位置Ｌ２から第２値Ｖ２とを読み出し、関数Ｆ（Ｖ１、Ｖ２）を計算し、関数の結果をあるデータストアＤＳ３における位置Ｌ３に格納することを伴い得る。いくつかのロックベース並行処理制御機構においては、Ｌ３が更新される前に値Ｖ１及びＶ２が確実に変更しないように、Ｌ１及びＬ２に対し排他的ロックが取得される必要があり得る。図１５に例示されるログサービスの楽観的並行処理制御機構においては、ロックは全く取得される必要はなくてよい。代わりに、描かれた実施形態において、競合検出器１５０５は、トランザクション記述子１５１６のコンテンツと、持続的変更ログ１５１０のコミット済みトランザクションログレコード１５２７の集合とに少なくとも部分的に基づいて、要求トランザクション内で読み出されるデータアイテム集合は、それらがそれぞれのデータストアから読み出された時から更新されたか否かを判定し得る。さらに詳しく後述されるように、少なくともいくつかの実施形態において、このような読み出し書き込み競合が存在するか否かを判定するために、シーケンス番号に基づいた技術が使用され得る。競合検出器１５０５が、トランザクションが上書きされている間に読み出されたデータは何もないと判定すると、要求トランザクションはコミットのために受諾され、そしてこのようなコミット受諾済みトランザクション１５１４は、持続的変更ログにおける対応ログレコードの複製のために提出され得る。用語「承認」及び「受諾」は、拒否されなかった要求トランザクションに関する類義語として、本明細書において使用され得る。対応読み出しが起こった後に読み出しデータの一部が更新された場合（または競合検出器により推定されるデータが更新された確率が閾値より大きい場合）、描かれた実施形態において、要求トランザクション１５１６は代わりに拒否またはアボートされ得る。この種類の並行処理制御手法は、トランザクションの書き込み集合を続行するか否かに関する判定が初めに、読み出し書き込み競合はあり得ないという楽観的仮定の下行われ得るという点で、楽観的であるとみなされ得る。その結果、読み出し書き込み競合が実際めったに起こらないシナリオにおいて、より多くの従来型ロックベース技術が使用される場合に可能となり得るスループット及び応答時間よりも、高いスループット及び低い応答時間が達成され得る。
【００７３】
トランザクションがコミットのために受諾された場合、描かれた実施形態において、コミットが成功したとみなされる前に、コミット済みトランザクションログレコードのコンテンツが、持続的変更ログ１５１０に対応付けられた複製ＤＡＧの複数のノードにおいて複製され得る（より詳しく図１６に関して後述されるように）。必要数のレプリカが作成されない場合、描かれた実施形態において、トランザクションは拒否またはアボートされ得る。コミットに必要となるレプリカの数は、異なるアプリケーションまたはクライアントにより異なり得る。コミット済みトランザクションログレコードは、本明細書において「コミットレコード」とも称され得る。いくつかの実施形態において、要求トランザクションがコミットされると、要求クライアント１５３２に通知され得る。少なくとも一実施形態において、トランザクションが拒否されると、クライアント１５３２に通知され、従って例えば、所望の更新のために新たなトランザクション要求が生成され、提出され得る。
【００７４】
少なくともいくつかの実施形態において、コミットされたトランザクションごとに、コミットシーケンス番号（またはアプリケーションのコミット済みステートを示すある他の識別子）が生成され、持続的変更ログ１５３２に格納され得る（例えばコミット済みトランザクションログレコードのそれぞれのレプリカの一部として）。このようなコミットシーケンス番号は、ステート遷移のための複製ＤＡＧにおいて使用されるシーケンス番号に関して前述されるように、例えばカウンタとして、または論理タイムスタンプとして実施され得る。コミットシーケンス番号は、例えば、いくつかの実施形態において競合検出器により、または他の実施形態において持続的変更ログの別のコンポーネント（使用されている複製ＤＡＧのコミッタノード等）において、決定され得る。描かれた実施形態において、所定のトランザクションがコミットされ、そのコミットレコードが持続的変更ログに格納された後、トランザクションの書き込みは、データストア１５３０のうちの書き込み対象となる１つまたは複数に、適用または伝播され得る（またはＰＱＲＭ１５３０Ｃの場合のように、書き込みデータは使用される）。いくつかの実施態様において、書き込みは、対象データストア１５３０に非同期的にプッシュされ得る。従って、このような実施態様において、トランザクションがコミットされた時間（すなわちコミットレコードの必要数のレプリカが無事格納された時）と、コミット済みトランザクションの特定書き込み動作のペイロードが対応データストアに到達する時間の間に、ある遅延が生じ得る。図１５に示される実施形態において、一部または全ての書き込みを関連データストアに伝播するために、それぞれの非同期書き込みアプライヤ１５１７が使用され得る。例えば、書き込みアプライヤ１５１７Ａはデータストア１５３０Ａに関連する書き込み１５１５Ａを適用するように構成され、書き込みアプライヤ１５１７Ｂはデータストア１５３０Ｂに関連する書き込みをプッシュし、そして書き込みアプライヤ１５１７Ｃはデータストア１５３０Ｃにて使用される書き込みをプッシュする。いくつかの実施態様において、書き込みアプライヤは持続的変更ログ１５１０のサブコンポーネント（例えばスレッドまたはプロセス）を含み、一方、他の実施態様において、書き込みアプライヤ１５１７は持続的変更ログの外部エンティティとして実装され得る。いくつかの実施形態において、所定の書き込みアプライヤ１５１７は、複数のデータストア１５３０に書き込みを伝播する責務を担い得る、または単一のデータストア１５３０は、複数の書き込みアプライヤ１５１７から書き込みを受信し得る。少なくとも一実施態様において、書き込みデータをデータストアに伝播するのにプル技術が使用され得る。例えば、１つまたは複数のデータストア１５３０は、書き込みアプライヤ主導で書き込みデータを提供される代わりに、持続的変更ログ１５１０または書き込みアプライヤに対し書き込みの要求を提出し得る。トランザクション中に書き込まれるデータが対応データストアに適用された後、クライアント１５３２は、更新されたデータを、データストアのそれぞれの読み出しインターフェースを使用して読み出すことが可能であり得る。いくつかの実施形態において、書き込みアプライヤのうちの少なくとも１つは、同期書き込みを実行することが可能であり得る（例えば、そうするようにログサービスにより明示的に指示された時、またはアプライヤが担当する全ての書き込みに関して）。例えば、クライアントは、トランザクションがコミットされたことを通知されるより先に、所定のトランザクションの少なくとも１つの書き込み（トランザクションに伴う、複数のデータストアのうちの「マスタ」データストアに対する書き込み等）が適用されたことの確認を所望し得る。いくつかの実施形態において、同期的に行う特定の書き込みが、トランザクション要求１５１６内に示され得る。
【００７５】
さらに詳しく後述されるように、いくつかの実施形態において、所定のトランザクション要求１５１６は、トランザクションの読み出し集合のインジケータ（すなわちトランザクション中に読み出されるデータオブジェクト集合を特定する情報）、トランザクションの書き込み集合のインジケータ（すなわちトランザクションがコミットされると更新／書き込みが行われるデータオブジェクト集合を特定する情報）、書き込みペイロードのインジケータ（すなわち書き込みごとに格納されるデータバイト集合）、及び／または競合検査デリミタのインジケータ（トランザクションを受諾／拒否するために調べられるべきコミット済みトランザクションログレコードの部分集合の指示）を含み得る。トランザクション要求のこれらの構成要素のうちの一部または全ては、トランザクションのコミットシーケンス番号と一緒に、対応コミットレコード内に格納され得る。少なくとも一実施形態において、持続的変更ログ１５１０は、例えばデータストアからのクエリ、またはログサービスクライアントからのクエリに応じて、アプリケーションの最新コミット済みステートの識別子１５９０（これまでに生成された最大コミットシーケンス番号等）を提供し得る。描かれた実施形態において、書き込みアプライヤは、データストアに適用する書き込みに対応するコミットシーケンス番号を示し得る。従って、いずれかの所定の時点で、クライアント１５３２は、所定のデータストア１５３０における最新適用済み書き込みに対応するコミットシーケンス番号を特定することが可能であり得る（例えばデータストアに問い合わせることで）。
【００７６】
少なくともいくつかの実施形態において、トランザクション要求の生成中（例えばログサービスのクライアントライブラリにより）、トランザクション中にアクセスされるデータストアから最新適用済みコミットタイムスタンプが取得され、そしてこのようなコミットシーケンス番号のうちの１つまたは複数は、競合検査デリミタとしてトランザクション要求内に示され得る。例えば、特定のクライアントがデータストアＤＳ１における位置Ｌ１の読み出しを含むトランザクションを開始する時に、ＤＳ１における最新適用済み書き込みに対応するコミットシーケンス番号がＳＮ１であるシナリオを考察する。当実施例において、トランザクションの読み出し集合はＤＳ１のデータのみから成るとさらに仮定する。このようなシナリオにおいて、ＳＮ１は、トランザクション要求１５１６に含まれ得る。競合検出器は、要求トランザクションの読み出し書き込み競合に関して調べるコミットレコード集合として、ＳＮ１より大きいシーケンス番号を有するコミットレコードを特定し得る。特定されたコミットレコードの書き込み集合のうちのいずれかが、要求トランザクションの読み出し集合と重複する場合、トランザクションは拒否／アボートされ得る。そうでなければ、当例示的シナリオにおいてトランザクションはコミットに承認され得る。
【００７７】
描かれた実施形態において、クライアント１５３２が直接ログレコードを読みだせるように、ログサービスは、１つまたは複数のプログラマチックログ読み出しインターフェース１５１３（例えばＡＰＩ、ウェブページ、コマンドラインユーティリティ、ＧＵＩ等）を開示し得る。別の実施形態において、変更ログ１５１０へ直接アクセスすることを可能にするこのような読み出しＡＰＩは、実装され得ない。コミットされた特定トランザクションを示すログレコードに直接アクセスし、かつ特定トランザクションがコミットされた順序を確定する機能は、いくつかの実施形態において、データストアにのみ直接アクセスすることにより可能となり得る分析と比べ、新たな種類の分析を行うことを可能にし得る（データストアのうちの少なくともいくつかにより、通常読み出し者は、最新適用済みバージョンのデータオブジェクトを参照することのみ可能であり、データオブジェクトの履歴を参照することは不可能であるため）。
【００７８】
図１５に例示される楽観的並行処理制御機構は、少なくともいくつかのシナリオにおいて、基礎データストアの並行処理制御機構を使用することで可能であり得る原子動作と比べて、より複雑な種類の原子動作に対応することを可能にし得る。例えば、いくつかの高性能の非リレーショナルデータストアは、単一アイテムのトランザクションのみを許可し得る（すなわち書き込みは１度に１つ許可されるが、単一のバッチ更新において複数の書き込みが提出された場合、一緒に対応される複数書き込みには原始性／整合性保証は提供され得ない）。前述のログベース手法により、非リレーショナルデータストア（及び／または同様に他のデータストア）の複数の位置に対する書き込みをもたらす単一のトランザクションは、比較的容易に対応され得る。持続的変更ログ１５１０は、対応付けられた競合検出器１５０５と一緒に、本明細書においてログベーストランザクションマネジャーと称され得る。いくつかの実施形態において、書き込みアプライヤ１５１７もまた、トランザクションマネジャーのサブコンポーネントとみなされ得る。
【００７９】
前記のように、いくつかの実施形態において、持続的変更ログ１５１０は、前述される複製ＤＡＧを使用して実施され得る。図１６は、少なくともいくつかの実施形態による、複製ＤＡＧ１６４０を使用する持続的変更ログの例示的実施態様を示す。描かれた実施形態において、ＤＡＧにより管理されるアプリケーションステート遷移は、１つまたは複数のデータストアの集合を対象とする読み出し及び書き込みを含む適用の一部として、ログクライアント１６６０により要求されるトランザクションに対応する。アプリケーションのステートは、受諾ノード１６１０、中間ノード１６１２、及びコミッタノード１６１４を含む現行複製経路を有する受諾ノード１６１０、中間ノード１６１２、コミッタノード１６１４、及び待機ノード１６１６におけるローカル格納域に格納されるそれぞれのトランザクションレコード集合１６７２として形成され得る。いくつかの実施態様においては、承認（すなわち要求トランザクションがコミットに承認されたことを示す）とコミットの別個のトランザクションレコードが格納され、一方、別の実施形態においては、単一のトランザクションレコードが、トランザクションがコミットされたか否かを示すフィールドと共に格納され得る。シーケンス番号または論理タイムスタンプは、描かれた実施形態において、トランザクションレコードのうちの少なくともいくつかの部分として格納され得る、あるいはトランザクションレコードのうちの少なくともいくつかにより示され得る。
【００８０】
要求トランザクション１６５０がコミットのために承認されるか否かに関する判定は、描かれた実施形態において、受諾ノード１６１０に実装される競合検出器により行われ得るが、別の実施形態において、競合検出器は複製ＤＡＧの外に実装され得る。フォールトトレラントログ構成マネジャー１６４は、ＤＡＧノード１６１０、１６１２、１６１４、１６１６に対し、それぞれのメッセージがＤＡＧの構成全体ではなくＤＡＧ構成に対する変更を示し、かつクライアント１６６０により提出される受信トランザクション要求のストリームの処理を中断するようＤＡＧノードに要求しない、構成デルタメッセージを非同期的に送信し得る。各ＤＡＧノードは、受信した構成デルタメッセージを自主的に処理または集約して、現行ＤＡＧ構成に関する各自の見解１６７４（例えばノード１６１０における見解１６７４Ａ、ノード１６１２における見解１６７４Ｂ、ノード１６１４における見解１６７４Ｃ、及びノード１６１６における見解１６７４Ｄ）に到達させ得る。見解１６７４のうちの少なくともいくつかは、所定の時点で他のノードの見解と異なり得るが、このように、通常の動作条件の下、異なるＤＡＧノードは、お互いにそれらのＤＡＧ構成見解を同期させなくてもよい。承認された（しかしまだコミットされていない）トランザクションを示すメッセージ１６５２Ａ、１６５２Ｂが、受諾ノード１６１０、中間ノード１６１２から複製経路沿いにそれぞれ送信され得る。描かれた実施形態において、コミッタノード１６１４は、コミットを示すメッセージ１６５３を、受諾及び中間ノードへ、並びに待機ノード１６１６へ、送信し得る。図１６の実施形態において複製ＤＡＧの外にあるエンティティとして示される非同期書き込みアプライヤ１６９２は、様々なコミット済みトランザクションレコードからの書き込みを、適切なデータストアまたはデータコンシューマに伝播し得る。別の実施形態において、書き込みアプライヤは、例えばＤＡＧノード内で作動するそれぞれのプロセスのように、複製ＤＡＧ内に実装され得る。いくつかの実施態様において、コミット済み書き込みをそれらの目的データソースまたはコンシューマに伝播するために、ＤＡＧノードの部分集合のみがアプライヤ１６９２により読み出され得る。別の実施形態において、図１６に示されるように、アプライヤはＤＡＧノードのうちのいずれかからコミット済みトランザクションレコードを読み出し、前述のように書き込みペイロードのコンテンツをプッシュし得る。
【００８１】
トランザクション要求構成要素
図１７は、少なくともいくつかの実施形態による、ログサービスのクライアント１７３２により提出され得るトランザクション要求記述子１７４４の例示的コンポーネント要素を示す。示されるように、描かれた実施形態において、トランザクション記述子１７４４は、競合検査デリミタ１７０２と、読み出し集合記述子１７０４と、書き込み集合記述子１７０６と、書き込みペイロード（複数可）１７０８と、任意の論理制約記述子１７１０とを含み得る。示される実施例において、ログサービスクライアント１７３２は、トランザクション要求記述子を組み立てるために使用され得るクライアントライブラリ１７５６を備える。少なくともいくつかの実施形態において、クライアントライブラリは、トランザクション中にデータが読み出されるデータストア１７３０Ａ、１７３０Ｂ、１７３０Ｃ内のそれぞれの読み出し位置１７６１Ａ、１７６１Ｂ、１７６１Ｃ、及び／またはデータが書き込まれる書き込み位置１７７１（描かれた実施例におけるデータストア１７３０Ｃの書き込み位置１７７１）を、自動で記録し得る。いくつかの実施態様において、クライアントライブラリ１７５６はまた、それぞれのデータソース１７３０から、ごく最近データストアに適用された書き込みを含む最新トランザクションの対応コミットシーケンス番号（ＣＳＮ）も取得し得る。一実施形態において、このようなＣＳＮは、例えば、トランザクションの読み出しのうちのいずれかが対応データストアに発行される前に、取得され得る。別の実施形態において、ＣＳＮは、所定のデータストア１７３０から取得され得るが、それは、現行のトランザクション内のそのデータストアに向けられた第１読み出しが発行される直前である。
【００８２】
描かれた実施形態において、競合検査デリミタ１７０２は、最新適用済みＣＳＮが入力として提供される関数から引出され得る。例えば、一実施態様においては、トランザクション中に読み出される全てのデータストアから取得されるＣＳＮの中の最小シーケンス番号が使用され得る。別の実施態様においては、それぞれのデータストアからのＣＳＮから成るベクトルまたはアレイが、トランザクション要求記述子の競合検査デリミタ１７０２として含まれ得る。競合検査デリミタ１７０２はまた、要求トランザクションが依存する１つまたは複数のデータストアのコミット済みステートを表すため、本明細書においてコミット済みステート識別子（ＣＳＩ）とも称され得る。いくつかの実施形態において、読み出し記述子１７０４に含めるためのハッシュ値集合を取得するために、選択されたハッシュ関数が、それぞれの読み出し位置１７６１Ａ、１７６１Ｂ、または１７６１Ｃに適用され得る。同様に、書き込み集合記述子１７０６を生成するために、選択されたハッシュ関数（実施態様により、読み出し記述子に使用された関数と同じ関数、または異なる関数）が、トランザクションの書き込み（複数可）の位置に適用され得る。別の実施形態において、ハッシュ法は使用され得ず、代わりに、例えば非ハッシュ化位置識別子が、それぞれの読み出し及び書き込み集合エントリに使用され得る。書き込みペイロード１７０８は、トランザクションに含まれるそれぞれの書き込みの書き込むデータの表現を含み得る。任意の論理制約１７１０は、さらに詳しく後述されるように、重複検出／排除のために、及び／または特定トランザクションを他のトランザクションの前または後に順序付けるために、使用されるシグネチャを含み得る。トランザクション要求記述子１７４４のコンテンツの一部または全ては、いくつかの実施形態において、持続的変更ログ１５１０に複製されるトランザクションステートレコード（例えば承認済みトランザクションレコード及び／またはコミット済みトランザクションレコード）の一部として、格納され得る。
【００８３】
異なる実施形態において、または異なるデータストアに関して、読み出し記述子及び書き込み記述子を生成する基となる読み出し及び書き込み位置は、異なる格納粒度、または異なる種類の論理エンティティさえ表し得ることに留意されたい。例えば、特定のデータオブジェクトがコンテナ名（例えばテーブル名）と、ユーザ名（コンテナの所有者を示す）と、あるキー集合（例えばハッシュキー及び範囲キー）との組み合わせにより表される非リレーショナルデータベースを含むデータストアの場合、読み出し集合は、タプル（コンテナＩＤ、ユーザＩＤ、ハッシュキー、範囲キー）の関数として取得され得る。例えばリレーショナルデータベースの場合、タプル（テーブルＩＤ、ユーザＩＤ、ローＩＤ）または（テーブルＩＤ、ユーザＩＤ）が使用され得る。
【００８４】
様々な実施形態において、トランザクションマネジャーは、トランザクション要求のコンテンツと持続的変更ログとを使用して、トランザクション要求内に示される読み出しと、ログ内に示される書き込みとの競合を特定する責務を担い得る。比較的単純な読み出し動作の場合、読み出された位置に基づいてハッシュ値を生成して、読み出された位置のハッシュ値を変更ログ内に示される書き込みのハッシュ値と比較することは、競合を検出するのに十分であり得る。いくつかの実施形態におけるより複雑な読み出し要求の場合、位置ベースのハッシュ値を使用することは、必ずしも十分ではあり得ない。例えば、読み出し要求Ｒ１が「テーブルＴ１から文字“Ｇ”で始まる製品名を選択」というクエリを含み、そして元の結果集合は“Ｇｏｏｄ‐ｐｒｏｄｕｃｔ１”であったシナリオを考察する。Ｒ１の結果に依存する書き込みＷ１を含むトランザクション要求が受諾のために調べられるまでに、製品名“Ｇｒｅａｔ‐ｐｒｏｄｕｃｔ２”がテーブルに挿入された場合、“Ｇｏｏｄ‐ｐｒｏｄｕｃｔ１”のデータオブジェクトの位置は変更されておらず、よってログの書き込みレコードは示され得ないとしても、トランザクション受諾決定が行われた時にＲ１をもう１度実行したら、Ｒ１の結果集合は変わり得ることとなる。このような読み出しクエリに関する、または値の範囲を伴う読み出しクエリ（例えば「＄１０〜＄２０の価格の製品の製品名集合を選択」）に関する読み出し書き込み競合に対応するために、いくつかの実施形態において、論理または述語ベースの読み出し集合記述子が使用され得る。従って、前述の位置ベースの読み出し集合インジケータは、読み出し書き込み競合検出の様々な実施形態において使用され得る結果集合変更検出メタデータの単なる一例示的カテゴリとみなされ得る。
【００８５】
読み出し書き込み競合検出
図１８は、少なくともいくつかの実施形態による、ログベーストランザクションマネジャーにおける読み出し書き込み競合検出の実施例を示す。描かれた実施形態において、持続的変更ログ１８１０に格納されたトランザクションコミットレコード（ＣＲ）１８５２は、コミットシーケンス番号をログの上部から下部に向かって昇順で配置されるように示される。最新または最近のコミット済みトランザクションは、コミットシーケンス番号（ＣＳＮ）１８０４Ｆと書き込み集合記述子（ＷＳＤ）１８０５Ｆとを含むＣＲ１８５２Ｆにより表される。それぞれのＣＲ１８５２Ａ、１８５２Ｂ、１８５２Ｃ、１８５２Ｄ、１８５２Ｅは、対応ＣＳＮ１８０４（例えばＣＳＮ１８０４Ａ〜１８０４Ｅそれぞれ）と、対応ＷＳＤ１８０５（例えばＷＳＤ１８０５Ａ〜１８０５Ｅ）とを含む。
【００８６】
示されるように、トランザクション要求記述子１８４４は、競合検査デリミタ（またはコミット済みステート識別子）１８４２と、読み出し集合記述子１８４６と、書き込み集合記述子１８４８とを含む。（要求トランザクションの読み出し集合書き込みペイロードは図示せず）。ログベーストランザクション管理システムの競合検出器は、要求トランザクションの読み出し集合との競合検査対象となるログ１８１０のＣＲ集合を特定するように求められ得る。競合検査デリミタ１８４２は、「一致」と表示される矢印により示されるように、描かれた実施形態において、要求トランザクションとの読み出し書き込み競合の調査対象となる集合１８０９の開始ＣＲを特定するために競合検出器が使用し得る下限ＣＳＮを示す。集合１８０９は、いくつかの実施形態において、一致シーケンス番号から始まり、最新コミット済みトランザクション（ＣＲ１８５２Ｆ）までの全てのＣＲを含み得る。ＣＲ集合１８０９により示される書き込みのうちのいずれかが、トランザクション要求１８４４内に示される読み出しのうちのいずれかと重複する場合、このような読み出し書き込み競合は、要求トランザクションの拒否を引き起こし得る。異なる実施形態において、このような重複が存在するか否かを検査するために、様々な機構が使用され得る。一実施形態において、例えば、読み出し集合記述子１８４６内に示される読み出しがＣＲ集合１８０９内に示される書き込みと競合するか否かを判定するために、１つまたは複数のハッシュベースの演算またはプローブが使用され、これによりＣＲ集合の順次走査が回避される。いくつかの実施態様において、例えばＣＲ集合１８０９内のレコード数が閾値より小さい場合、ＣＲ集合１８０９の順次走査が使用され得る。ＣＲ集合１８０９内に示される書き込みの全てが要求トランザクションの読み出しのうちのいずれとも重複しない場合、トランザクション要求の準備中に読み出されたデータ全ては、それらが読み出されて以降変更し得なかったため、トランザクションは受諾され得る。少なくとも一実施形態において、トランザクション要求記述子はまた、競合検査対象となるトランザクションレコードのシーケンス番号の上限も示す。例えば、競合検査デリミタは、ＣＳ１８５２の集合内の開始ポイント及び終了ポイントの両方を示し得る。
【００８７】
楽観的ログベース並行処理制御の方法
図１９は、少なくともいくつかの実施形態による、ログサービスで行われ得る制御プレーン動作態様を示すフロー図である。示される管理または設定関連動作のうちの少なくともいくつかは、例えばログサービスに実装される１つまたは複数の管理プログラマチックインターフェースの呼び出しに応じて、図１５に例示されるようなログサービスマネジャー１５０１により実行され得る。構成要素１９０１に示されるように、１つまたは複数のデータストアは、例えば前述の読み出し書き込み競合検出手法を使用して楽観的並行処理制御機構を実施するログサービスを介して、トランザクション管理に登録され得る。それぞれの別個の読み出しインターフェースを有する様々な種類のデータストアのトランザクション管理は、異なる実施形態において、ログベース手法を使用して実施され得る。様々な種類のデータストアには、例えばリレーショナルデータベース、非リレーショナルデータベース、インメモリデータベース、プロバイダネットワーク実施格納サービス、分散キャッシュコンポーネント、事前演算クエリ結果マネジャー、スナップショットマネジャー、待ち行列サービス、通知サービス等のインスタンスが含まれる。いくつかの実施形態において、所定のログインスタンスを使用して管理される一部または全ての基礎データストアは、いくつかの従来型リレーショナルデータベースシステムにより対応されるＡＣＩＤ特性（原子性、一貫性、独立性、及び耐久性）のうちの少なくともいくつかに対応し得ない。
【００８８】
ログサービスは、例えばプロバイダネットワークで実施されるプロビジョニングサービスの助力を得て、登録データストアのために実施する持続的変更ログの複製ＤＡＧノードに使用するホスト集合を特定し得る（構成要素１９０４）。１つまたは複数のホストは、複製ＤＡＧの構成マネジャーのためにも特定され得る。例えば、前述のように、ＤＡＧ構成変更を実施するために同意ベースプロトコルを使用するノードのクラスタが、いくつかの実施態様において使用され得る。複製ノード及び構成マネジャーは、選択されたホストにおいてインスタンス化され得る。競合検出器、１つまたは複数の書き込みアプライヤ、及び持続的変更ログの任意の読み出しインターフェースマネジャーを含むログベーストランザクション管理機構の他のコンポーネントが設定され得る（構成要素１９０７）。ログの読み出しインターフェースマネジャーは、いくつかの実施形態において、ログに直接提出される（登録データストアの読み出しインターフェースに提出される代わりに）読み出し要求に応答する責務を担い得る。一例示的実施態様において、ログにおいてトランザクションがコミットされると、通知に従うそれぞれのプロセスまたはスレッドとして書き込みアプライヤがインスタンス化され得る。競合検出器は、いくつかの実施形態において、ログの読み出しインターフェースを使用するモジュールを備え得る。競合マネジャーの設定は、例えば、重複排除または順序付けに対応する制約検査動作に対し読み出し書き込み競合が特定される順序、クライアントに応答が提供される方法（例えばトランザクション拒否／コミットに関してクライアントが通知されるか否か、並びにどのように通知されるか）等を確立することを含み得る。いくつかの実施形態において、競合検出器、書き込みアプライヤ、及び／またはログ読み出しインターフェースマネジャーは、マルチテナント様式で実装され得る。例えば、所定の競合検出器、書き込みアプライヤ、または読み出しインターフェースマネジャーは、それぞれのログインスタンスが確立された複数のクライアントに対し自身のサービスを提供し得る。
【００８９】
持続的変更ログの様々なコンポーネントが設定された後、例えば適切なネットワークアドレス及び／または認証情報をクライアントに提供することで、クライアントからのトランザクション要求の流れが可能になり得る（構成要素１９１０）。少なくともいくつかの実施形態において、ログサービスにて行われる制御プレーン動作は、格納されたトランザクションステートレコードを部分的に削減またはアーカイブすることを含み得る（構成要素１９１４）。いくつかのこのような実施形態において、例えば、所定の持続的変更ログのトランザクションレコードに使用される格納量が閾値を超える場合、複数の最古トランザクションレコードは、異なる格納設備（プロバイダネットワーク格納サービス、または近頃のトランザクションレコード集合に使用される格納デバイスよりも遅い格納デバイス集合等）にコピーされ得る。別の実施形態において、最古トランザクションレコードは、単純に破棄され得る。少なくとも一実施形態において、例えば第１変更ログが閾値レコード保有数に達した場合、持続的変更ログのあるインスタンスを別のものと交換する等の他の制御プレーン動作は、必要に応じて実行され得る。
【００９０】
図２０は、少なくともいくつかの実施形態による、クライアントから受信されるトランザクション要求に応じてログサービスで行われ得る動作態様を示すフロー図である。構成要素２００１に示されるように、ログサービスの競合検出器は、例えば競合検査デリミタと、読み出し集合と、持続的変更ログがログサービスにより確立された１つまたは複数のデータストアにおけるそれぞれの位置に対する１つまたは複数の書き込みを含む書き込み集合とを示す、トランザクションＴ１のトランザクション要求記述子を受信し得る。競合検査デリミタは、トランザクションの読み出しの結果の取得元となる１つまたは複数のソースデータストアのコミット済みステートを示し、従ってコミット済みステート識別子（ＣＳＩ）として機能し得る。ＣＳＩはまた、ソースデータストアの時点論理スナップショットに対応し得るため、いくつかの環境において「スナップショットシーケンス番号」とも称され得る。例えば競合検査デリミタと、ログに格納されたトランザクションレコードのシーケンス番号とを使用して、要求トランザクションとの可能性のある競合を検査するための、持続的変更ログに格納されたトランザクションレコードの集合Ｓ１が特定され得る（構成要素２００４）。このような集合Ｓ１は、例えば、一実施形態において、競合検査デリミタ内に示されるシーケンス番号より大きいコミットシーケンス番号を有するトランザクションのレコード全てを含み得る。
【００９１】
読み出し書き込み競合が検出された場合（構成要素２００７）、例えば要求トランザクションの読み出し集合は集合Ｓ１のトランザクションのうちの１つの書き込み集合と少なくとも部分的に重複する場合、トランザクションＴ１は、拒否または破棄され得る（構成要素２０２２）。いくつかの実施形態において、このような重複が存在するか否かを判定するためにハッシュ関数が使用され得る。例えば読み出し集合のハッシュ値が書き込み集合と同じ場合、競合が生じたと推測され得る。いくつかの実施態様において、受信したトランザクション要求の送信元であるクライアントに対し拒否の開示または通知が提供され、これによりクライアントは、別の要求記述子を生成、提出してトランザクションを再試行することが可能になる。競合が検出されなかった場合（同様に構成要素２００７にて判定）、Ｔ１はコミットのために受諾され得る（構成要素２０１０）。描かれた実施形態において、Ｔ１のトランザクションレコードの複製が、持続的格納域に対し、例えばログの複数の複製ＤＡＧノードにおいて開始され得る。いくつかの実施形態において、Ｔ１がコミットのために受諾された場合、受諾シーケンス番号がＴ１に割り当てられ、受諾シーケンス番号は、トランザクション要求記述子構成要素のうちの少なくともいくつかのコンテンツと一緒に各レプリカに格納され得る。少なくとも一実施形態において、受諾シーケンス番号は、トランザクションが最終的にコミットされた場合に、コミットシーケンス番号として使用され得る。
【００９２】
トランザクションＴ１のコミットが完了する前に、トランザクションが管理されているアプリケーションのデータ耐久性要求に応じて、レプリカの閾値数が格納される必要があり得る。十分な数のレプリカが保存されると（構成要素２０１３にて判定）、コミットは成功したと推測され、コミット完了に関して、いくつかの実施形態において要求クライアントに対し通知が行われ得る（構成要素２０１４）。ある理由で持続的格納域に保存され得るレプリカの数が要求される閾値を下回る場合（同様に構成要素２０１３にて検出）、トランザクションはアボート／拒否され得る（構成要素２０２２）。Ｔ１コミット後、描かれた実施形態において、Ｔ１の書き込み集合内に示される書き込み動作は、例えば非同期書き込みアプライヤにより、対応データストアまたはデータコンシューマに適用され得る（構成要素２０１６）。いくつかの実施形態において、書き込みアプライヤのうちの少なくとも１つは同期式であり得る。例えば、更新が同期的に適用されるトランザクションの書き込みの部分集合をこのような同期書き込みアプライヤが完了して初めて、トランザクションはコミットされたことがクライアントに対し通知され得る。更新が適用された後、更新されたデータ要素は、それぞれのデータストアの読み出しインターフェースを介して受信されるクライアント読み出し要求に応じて読み出され得る（構成要素２０１９）。様々な登録済みデータストアにより対応される読み出しインターフェースに加えて、少なくともいくつかの実施形態において、持続的変更ログ自体も、例えばログサービスのプログラマチッククエリ／読み出しインターフェースを介して、トランザクションレコードコンテンツに関して直接問い合わせられ得る。データストアはログ内に既に存在する書き込みを伝播するために非同期アプライヤに依存し得るため、いくつかの実施態様において、このようなログサービスインターフェースを介してログを対象とする読み出しは、データストアを対象とする読み出しよりも、場合によってはより速く書き込み動作の結果を参照することが可能であり得る。いくつかの実施形態において、トランザクションがログにコミットされるとすぐにデータストアに書き込みを伝播する同期アプライヤが使用され得る。別の実施形態において、各アプライヤは、書き込みが対応データストアまたはコンシューマに伝播されなければならない設定可能時間窓を有し得るため、トランザクションコミットと、データストアにおけるトランザクションの変更データの出現との間の最大遅延を調整することが可能となる。
【００９３】
図２１は、少なくともいくつかの実施形態による、それぞれの特例整合性目標を達成するために使用され得るトランザクション要求記述子の実施例を示す。一実施形態において、ログサービスのクライアントは、書き込みがコミットされるとすぐにそれが全てのリーダーで参照可能となる「読み出し後書き込み」整合性セマンティックを施行することを所望し得る。読み出し後書き込み整合性を確保するために、すなわち読み出しでは常にデータのコミット直後に当該データを確実に「参照」するように、クライアントは、読み出し専用トランザクションであっても（並びに書き込みを含むトランザクションに関しても）トランザクション要求を提出することを所望し得る。読み出し専用トランザクション要求記述子（ＴＲＤ）２１４４は、例えば、空書き込み集合２１０６Ａと空書き込みペイロード２１０８Ａとを有するが、非空競合検査デリミタ２１０２Ａと非空読み出し集合記述子２１０４Ａとを有する。このような読み出し専用トランザクション要求記述子を受信すると、競合検出器は、要求内に示される読み出し集合と、競合検査デリミタ内に示されるシーケンス番号より大きいシーケンス番号を有するコミットされた書き込みとの間に、重複が存在するか否かを調べ得る。競合が検出された場合、読み出し専用トランザクションは拒否され、従って、要求トランザクションがこれらの読み出しに依存するいずれの書き込みも含まないにもかかわらず、競合検査デリミタが生成された後に書き込みがコミットされ得た位置に対する読み出しは却下される。
【００９４】
少なくともいくつかの実施形態において、書き込み専用トランザクション要求が、特定の状況下でログサービスに提出され得る。いくつかのアプリケーションに関して、クライアントは、少なくともいくつかの時間帯において、またはいくつかのデータストアに関して、読み出し書き込み整合性検査を施行することを所望しない場合もあり得る。代わりに、クライアントは、このような時間帯において、いくつかの書き込みがコミットのために無条件に受諾されることを所望し得る。従って、空読み出し集合２１０４Ｂ及び／または空競合検査デリミタ２１０２Ｂを有し、非空書き込み集合記述子２１０６Ｂ及び非空書き込みペイロード２１０８Ｂを有するトランザクション要求記述子２１４５が提出され得る。例えばデータストアまたはオブジェクトが初めにデータ投入されている場合、またはある時間帯に１つの書き込みクライアントのみが要求を提出していることが分かっている場合、このような書き込み専用要求が提出され得る。
【００９５】
前述のように、いくつかの実施形態において、持続的変更ログからのコミット済み書き込みのコンテンツを様々なデータストアまたはデータコンシューマに対し伝播するために、非同期書き込みアプライヤが使用され得る。書き込み伝播の非同期的特性の結果、いくつかの時点で、コミット済み書き込み集合がそれらの対象データストアへまだ伝播されていない場合もあり得る。少なくとも一実施形態において、書き込み専用トランザクションを使用して、このような非適用済み書き込みをフラッシュすることが可能であり得る。例えば、特定の書き込みアプライヤＷＡ１が所定のデータストアＤＳ１に対し未処理の非適用済み書き込みをＮ個までしか有さないように構成される場合、クライアントは、未処理のコミット済み書き込みをフラッシュするために特にまたは主に使用されるＤＳ１内の特別書き込み位置ＷＬ１に対し、ＴＲＤ２１４５等の書き込み専用トランザクション要求記述子を提出し得る。いくつかの事例において、このようなＴＲＤは、いずれの書き込みペイロードも全く有さなくてもよい（例えば、書き込みペイロード２１０８Ｂはヌルに設定され得る）。このような書き込み適用フラッシュトランザクション要求が受諾されると、新たな未処理コミット済み書き込みがログとＷＡ１の未処理要求待ち行列とに追加され得る。待ち行列の長さが増大すると、ＷＡ１は、非適用済み書き込みはＮ個以下という自身の要件を満たすために、待ち行列内の早期コミット済み書き込みを適用し始める必要があり得る。いくつかの実施形態において、確実にコミット済み書き込みが長時間未処理の状態で残されないように、このような書き込み適用フラッシュ要求は、例えば１秒に１度等、定期的に提出され得る。書き込み適用フラッシュトランザクションのコミット済み書き込みがアプライヤの待ち行列の先頭に達した時、いくつかの実施態様において、物理的書き込みが実行される必要はない。代わりに、例えばアプライヤは単純に、トランザクションに対応するコミットシーケンス番号を最新「適用済み」書き込みのインジケータとして、目的データストアへ送信し得る。
【００９６】
いくつかのアプリケーションに関して、クライアントは、少なくともいくつかの時間帯において、厳密なシリアライゼーションを施行することを所望し得る。すなわち、トランザクション中のデータ読み出しと、トランザクション準備が開始されてからコミットされ得た書き込みとの間に任意の競合が存在するか否かにかかわらず、１度に１つのみの（書き込み含有）トランザクションを進行することが許され得る。このようなシナリオにおいて、クライアントは、ログサービスに対し、厳密シリアライゼーショントランザクション要求記述子２１４６を、アプリケーションにより使用された全てのデータ集合の全コンテンツを示すその読み出し集合記述子２１０４Ｃと共に提出し得る。読み出し／書き込み位置のインジケータとしてハッシュ値が使用され、かつ競合検出のために書き込み集合エントリとのビット単位比較が使用される一実施態様において、例えば、読み出し集合記述子２４０２Ｃに含まれるハッシュ値は、一連の「１」（例えば１６ビットのハッシュ値の場合「１１１１１１１１１１１１１１１１」）に設定され得る。このようなＴＲＤ２１４６の競合検査デリミタ２１０２Ｃより大きいＣＳＮと共に、任意の書き込み含有トランザクションがコミットされた場合、ＴＲＤ２１４６に対応するトランザクションは拒否され得る。従って、書き込み集合記述子２１０６Ｃにより示される書き込みと、書き込みペイロード２１０８Ｃとは、記述子により示される競合検査間隔内に他の書き込みがコミットされていない場合にのみ（このような書き込みの位置に関係なく）、コミットされる。
【００９７】
重複排除及び順序付け制約
いくつかの実施形態において、ログサービスのクライアントは、重複エントリが１つまたは複数のデータストアに対し確実に書き込まれないことを所望し得る。このような一実施形態において、ログサービスは、前述の読み出し書き込み競合検出を行うことに加えて、トランザクション要求内に示される重複排除要件も施行する必要があり得る。図２２は、少なくともいくつかの実施形態による、ログベーストランザクションマネジャーで受信されるトランザクション要求に対応付けられた重複排除制約を施行する実施例を示す。示されるように、トランザクション要求記述子２２４４は、読み出し書き込み競合検査デリミタ２２１２と、読み出し集合記述子２２１４と、書き込み集合記述子２２１６と、論理制約デリミタ２２１８とを備える。ＴＲＤ２２４４の書き込みペイロードは、図２２に図示されない。論理制約記述子２２１８は、描かれた実施形態において、論理制約種類は重複排除制約であることを示すＬＣ種類フィールド２２１９と、重複排除検査デリミタ２２２０と、排除シグネチャ（複数可）２２２２とを含む。
【００９８】
要求トランザクションを受諾するか否かを判定するために、ログサービスは、描かれた実施形態において、２種類の検査を行う必要があり得る。１つは読み出し書き込み競合検出であり、もう１つは重複検出である。持続的変更ログ２２１０内のコミットレコード２２５２はそれぞれ、描かれた実施形態において、それぞれのコミットシーケンス番号（ＣＳＮ２２０４）と、書き込み集合記述子（ＷＳＤ）２２０５と、重複排除シグネチャ（ＤＤＳ）２２０６とを含み得る。読み出し書き込み競合が起こったか否かを判定するために、ログサービスは、読み出し書き込み競合検査デリミタ２２１２に対応するシーケンス番号から始まり、最新コミットレコード２２５２Ｆで終わるＣＲ集合２２０９を特定し得る。当該ＣＲ集合２２０９の書き込み集合は、要求トランザクションの読み出し集合記述子２２１４との重複に関して調べられる。読み出し書き込み競合が検出された場合（すなわちそのような重複が存在する場合）、要求トランザクションは前述のように拒否され得る。
【００９９】
要求トランザクションの書き込み（複数可）が重複を表すか否かを判定するために、描かれた実施形態において、重複排除検査デリミタ２２２０に対応するシーケンス番号から始まり、最新コミットレコード２２５２Ｆで終わる別のＣＲ集合２２５９が特定され得る。ＣＲ集合２２５９内のそれぞれのコミットレコードに関して、ログサービスは、コミットレコードに格納された重複排除シグネチャのうちのいずれかが、要求トランザクションの排除シグネチャ（複数可）２２２２に一致するか否かを調べ得る。重複はこのような一致が見つかった場合に検出され、そしてこのようなシナリオにおいて、要求トランザクションは、読み出し書き込み競合が検出されなかったとしても、拒否され得る。重複が検出されなかった場合、かつ読み出し書き込み競合が検出されなかった場合、トランザクションはコミットのために受諾され得る。
【０１００】
少なくともいくつかの実施形態において、重複排除シグネチャ２２０６は、対応トランザクションにより書き込まれるデータアイテムを、書き込み集合記述子とは異なる様式で（例えば異なるハッシュ関数を使用して生成されたハッシュ値で、またはより多くのビットを使用して記憶されたハッシュ値で）表現し得る。書き込み集合のこのような異なる符号化は、多数の理由のうちのいずれかの理由から、重複排除あるいは読み出し書き込み競合検出に使用され得る。例えば、いくつかのアプリケーションに関して、クライアントは、誤判定読み出し書き込み競合検出の結果から時折トランザクションを再提出する必要があることよりも、正確に重複を検出することにより一層関心を持ち得る。そのため、このようなアプリケーションに関して、読み出し書き込み競合検出におけるエラーの許容レートは、重複検出エラーの許容レートよりも高くあり得る。従って、いくつかの実施態様において、出力値が１２８または２５６ビットになる暗号化強度ハッシュ関数が、重複排除シグネチャに使用され、一方で出力が１６ビットまたは３２ビットを使用して記憶されるより単純なハッシュ関数が、ＷＳＤ内に含まれる書き込みシグネチャに使用され得る。いくつかのシナリオにおいて、重複排除は、使用されているデータストアの小部分集合に必要であり、一方で読み出し書き込み競合は、トランザクションのはるかに大きい集合に関して調べられる必要があり得る。このような場合、いくつかの実施形態において、重複排除シグネチャよりも小さいＷＤＳシグネチャを使用することにより、格納及びネットワークリソース使用量は削減され得る。読み出し書き込み競合検出機構と重複排除検出機構を合体させる代わりに、読み出し書き込み競合検出機構を重複排除検出機構から論理的に切り離すことは、例えばログサービスのユーザ間の混乱を避けるため、重複排除の別個の請求に対応可能であるため等の他の理由からも、有益であり得る。
【０１０１】
別の実施形態において、読み出し書き込み競合検出と重複排除の両目的のために、書き込み集合記述子が使用され得る（例えば別個の排除シグネチャは使用され得ない）。同様に、いくつかの実施形態において、同一のシーケンス番号値が、読み出し書き込み競合検査デリミタ及び重複排除検査デリミタとして使用され得る。すなわち、読み出し書き込み競合に関して調べられるコミットレコード集合は、重複に関しても検査され得る。少なくとも一実施形態において、重複排除は、例えば書き込み集合記述子を使用して、トランザクション要求記述子に論理制約記述子を含める必要なしに、デフォルトで実行され得る。
【０１０２】
いくつかのアプリケーションに関して、クライアントは、特定のトランザクション集合間にコミット順序を施行することに関心を持ち得る。例えば、トランザクションＴ１、Ｔ２、Ｔ３それぞれに対する３つの異なるトランザクション要求を提出するクライアントは、Ｔ１はＴ２の前にコミットされ、Ｔ３はＴ１とＴ２が両方ともコミットされた後にのみコミットされることを所望し得る。このようなコミット順序付け制約は、いくつかの実施形態において、第２種の論理制約記述子を使用して施行され得る。図２３は、少なくともいくつかの実施形態による、ログベーストランザクションマネジャーで受信されるトランザクション要求に対応付けられた順序付け制約を施行する実施例を示す。示されるように、トランザクション要求記述子２３４４は、読み出し書き込み競合検査デリミタ２３１２と、読み出し集合記述子２３１４と、書き込み集合記述子２３１６と、図２２の論理記述子２２１８とは異なる種類の論理制約デリミタ２３１８とを備える。ＴＲＤ２３４４の書き込みペイロードは、図２３に図示されない。論理制約記述子２３１８は、描かれた実施形態において、論理制約種類は順序付け制約であることを示すＬＣ種類フィールド２３１９と、順序付け検査デリミタ２２２０と、トランザクションＴ１、Ｔ２にそれぞれ対応する要求順序付けシグネチャ２３２２Ａ、２３２２Ｂとを含む。論理制約記述子２３１８はＴＲＤ２３４４に含まれ、両トランザクションＴ１、Ｔ２（順序付けシグネチャ２３２２Ａ、２３２２Ｂにより示される）が先にコミットされた場合にのみ要求トランザクションはコミットされることを確実にし得る。
【０１０３】
要求トランザクションを受諾するか否かを判定するために、ログサービスはもう１度、図２３に示される実施例における２種類の検査を行う必要があり得る。１つは読み出し書き込み競合検出であり、もう１つはトランザクションＴ１、Ｔ２がコミットされたことを確認することである。持続的変更ログ２３１０内のコミットレコード２３５２はそれぞれ、描かれた実施形態において、それぞれのコミットシーケンス番号（ＣＳＮ２３０４）と、書き込み集合記述子（ＷＳＤ）２３０５と、順序付けシグネチャ２３０６とを含み得る。読み出し書き込み競合が起こったか否かを判定するために、前述同様に、ログサービスは、読み出し書き込み競合検査デリミタ２３１２に対応するシーケンス番号から始まり、最新コミットレコード２３５２Ｆで終わるＣＲ集合２３０９を特定し得る。当該ＣＲ集合の書き込み集合は、要求トランザクションの読み出し集合記述子２３１４との重複に関して調べられる。読み出し書き込み競合が検出された場合（すなわちそのような重複が存在する場合）、要求トランザクションは拒否され得る。
【０１０４】
要求トランザクションの順序付け制約が満たされたか否かを判定するために、描かれた実施形態において、順序付け検査デリミタ２３２０に対応するシーケンス番号から始まり、最新コミットレコード２３５２Ｆで終わる別のＣＲ集合２３５９が特定され得る。ログサービスは、要求シグネチャ２３２２Ａ、２３２２Ｂと一致する順序付けシグネチャを有するそれぞれのコミットレコードが、ＣＲ集合２３５９内に存在することを確認する必要があり得る。要求シグネチャ２３２２のうちの少なくとも１つがＣＲ集合２２５９内に見つからない場合は、順序付け制約に違反することとなり、読み出し書き込み競合が検出されなかったとしても、要求トランザクションは拒否され得る。両方の順序付けシグネチャがＣＲ集合２３５９内に見つかった場合、かつ読み出し書き込み競合が検出されなかった場合、トランザクションはコミットのために受諾され得る。
【０１０５】
ＣＲ２３５２内（及びＴＲＤ２３４４内）に格納される順序付けシグネチャは、異なる実施形態において様々な技術を使用して生成され得る。いくつかの実施形態において、それらはトランザクションの書き込み集合から生成され得る。別の実施形態において、順序付けシグネチャは、他の要素に少なくとも部分的に基づき得る。例えば、いくつかの実施形態において書き込みシグネチャに加えて要求クライアントの識別が順序付けシグネチャに符号化され得る、トランザクションが要求された実時間が順序付けシグネチャに符号化され得る、あるいはトランザクションが要求された元の位置の開示が符号化され得る等がある。いくつかの実施形態において、順序付けシグネチャを表すために、書き込み集合シグネチャとは異なる技術を使用することに関して、前述と同様の考察が適用され得る。従って、いくつかの実施形態において、順序付けシグネチャと書き込み集合シグネチャの両方が同一の基礎書き込み位置から導出されるとしても、書き込み集合記述子コンテンツを生成するために使用される技術とは異なる技術が、順序付けシグネチャを生成するために使用され得る。例えば、異なるハッシュ関数または異なるハッシュ値サイズが使用され得る。しかしながら別の実施形態においては、読み出し書き込み競合検出と順序付け施行の両目的のために、書き込み集合記述子が使用され得る（例えば別個の順序付けシグネチャは使用され得ない）。同様に、いくつかの実施形態において、同一のシーケンス番号値が、読み出し書き込み競合検査デリミタ及び順序付け検査デリミタとして使用され得る。すなわち、読み出し書き込み競合に関して調べられるコミットレコード集合は、順序付けに関しても検査され得る。いくつかの事例においては、書き込み集合とは無関係の任意の数字または文字列が、順序付けシグネチャとして使用され得る。少なくとも一実施形態において、制約記述子はＬＣ種類フィールドを含み得ない。代わりに制約の種類は、トランザクション要求内における制約記述子の位置により示され得る。いくつかの実施形態において、例えば、ＬＣ種類フィールドを使用する代わりに、「要求」フラグが順序付けシグネチャに対応付けられ、そして「排除」フラグが重複排除シグネチャに対応付けられ得る。読み出し書き込み競合検査デリミタに関連して前述されたように、いくつかの実施形態において、制約検査に関して調べられるべきコミットレコードの範囲を示すために、ＣＳＮの下限のみを指定する代わりにＣＳＮの上限もトランザクション要求記述子内で指定され得る。
【０１０６】
いくつかの実施形態において、図２３に例示される順序付け制約よりも複雑な順序付け制約が施行され得る。例えば、クライアントは、ログサービスに対し単純に、要求トランザクションのコミットより前に両トランザクションＴ１、Ｔ２が必ずコミットされたこと（任意の順序で）を確認するよう要求する代わりに、Ｔ１が必ずＴ２より前にコミットされたことを要求することが可能であり得る。同様に、いくつかの実施形態において、クライアントは、例えば、要求トランザクションの前に、あるトランザクション集合｛Ｔ１、Ｔ２、Ｔｋ｝がある特定の順序で（または任意の順序で）コミットされなければならない、かつある他のトランザクション集合｛Ｔｐ、Ｔｓ｝はコミットされてはならないといった、否定的順序要件を要求することも可能であり得る。
【０１０７】
図２２及び図２３において、表示されたトランザクション要求内には、単一の種類の論理制約が示された。いくつかの実施形態において、クライアントは、様々なトランザクション上でいくつかの異なる種類の論理制約を施行することを所望し得る。図２４は、少なくともいくつかの実施形態による、複数の論理制約記述子を含むトランザクション要求記述子の実施例を示す。トランザクション記述子２４４４により表される同一の要求トランザクションに対し、１つの順序付け制約が適用され、かつ１つの重複排除制約が適用される。描かれた実施形態において、読み出し書き込み集合記述子は、読み出されるまたは書き込まれるデータアイテムごとに、３２ビット（４バイト）のハッシュ値を有する。例えば、それぞれの４バイト読み出しハッシュシグネチャ２４６４Ａ、２４６４Ｂは、読み出し集合記述子２４０４内で２つのデータアイテム位置を示し、そしてそれぞれの４バイト書き込みハッシュシグネチャ２４６５Ａ、２４６５Ｂは、書き込み集合記述子２４０６に含まれ、トランザクションがコミットされると書き込み対象となる２つの位置を示す。読み出し書き込み競合検査デリミタ２４０２は、持続的変更ログ内のシーケンス番号範囲の下限を選択するために使用され、当該シーケンス番号範囲のコミットレコードは、要求トランザクションとの読み出し書き込み競合の検査対象となる。
【０１０８】
トランザクション要求記述子２４４４はまた、描かれた実施形態において、順序付け制約記述子２４０８Ａと、重複排除制約記述子２４０８Ｂとを含み得る。順序付け制約記述子２４０８Ａは、制約種類フィールド２４０９Ａと、順序付け検査デリミタ２４１０と、要求トランザクションが受諾されるためにはコミットが完了してなければいけないトランザクションに対応する１つまたは複数の要求順序付けシグネチャ２４１２Ａ、２４１２Ｂ等とを含み得る。重複排除制約記述子２４０８Ｂは、制約種類フィールド２４０９Ｂと、重複排除検査デリミタ２４２０と、重複排除シグネチャ２４２２とを含み得る。
【０１０９】
示されるように、描かれた実施形態において、要求順序付けシグネチャ２４１２Ａ、２４１２Ｂと重複排除シグネチャ２４２２は、１２８ビット（１６バイト）ハッシュシグネチャ２４６６Ａ、２４６６Ｂ、２４６７をそれぞれ備え得る。このように、論理制約シグネチャはそれぞれ、描かれた実施例において読み出し及び書き込み集合シグネチャのデータアイテムごとに使用されるビットの４倍のビットを使用し得る。これにより、論理制約関連比較のハッシュ衝突数は、読み出し書き込み競合検出のために行われる比較と比べて、低減され得る。いくつかの実施形態において、順序付け及び／または重複排除シグネチャのために、ＭＤ５等の暗号化ハッシュ関数が使用され得る。少なくともいくつかのこのような実施形態において、暗号化ハッシュ関数の使用のおかげで、論理制約検査におけるエラー確率は、ゼロ近くまでに低減され得る。誤判定ハッシュ衝突に（例えば誤判定読み出し書き込み競合検出に）基づいたトランザクション拒否レートは合理的に低く、容認可能であり得るが、少なくともいくつかのクライアントは、誤判定ハッシュ衝突（例えばコミット順序付けの場合）によるトランザクションの受諾を回避することに一層関心を持ち、そして暗号化強度ハッシュ関数の使用のおかげで、このようなトランザクション誤受諾は回避され得る。いくつかの実施態様において、クライアントは、重複検出及び／または順序付け目的で使用するハッシュ関数を選択可能であり得る。いくつかの実施形態において、重複排除シグネチャ、順序付けシグネチャ、及び／または読み出しもしくは書き込みシグネチャに、図２４に示されるものとは異なるハッシュ関数及び／またはハッシュ値の長さが使用され得る。例えば、重複排除及び順序付けシグネチャは、サイズで異なり得る。少なくともいくつかの実施形態において、読み出し／書き込み集合シグネチャ、重複排除及び／または順序付けシグネチャに、読み出されるまたは書き込まれるデータアイテムのアドレスが、例えばアドレスから生成されるハッシュ値を使用する代わりに、使用され得る。一実施形態において、重複排除及び／または書き込みシグネチャは、データが書き込まれる先の位置から導出されることに加えて、またはこれに代わって、書き込みペイロードから導出され得る。
【０１１０】
いくつかの実施形態において、データ完全性／有効性制約、または最終コミット期限制約等の追加論理制約も、トランザクション要求記述子内に指定され得る。例示的データ完全性または有効性制約は、例えば特定の値Ｖ１は、異なる値Ｖ２がデータストアＤＳ１またはある他のデータストアに既に格納されている場合にのみデータストアＤＳ１に格納され得ることを、要求し得る。データ有効性制約は、特定のデータ種類または格納するデータアイテムに対し、許容範囲（無条件、または指定データストア位置の格納値に関して条件付き）を定義し得る。コミット期限制約は、トランザクションのコミットが完了されるべき最終期限を示し、最終期限が満たされない場合、トランザクションは中止またはアボートされなくてはならないという意図がある。
【０１１１】
図２５は、少なくともいくつかの実施形態による、１つまたは複数の論理制約を示すトランザクション要求に応じてログサービスで行われ得る動作態様を示すフロー図である。描かれた実施形態において、所定のトランザクションのコミット要件には、並行処理制御要件（例えば前述の類の読み出し書き込み競合は見つからないという要件）、並びに論理制約要件が含まれ得る。少なくともいくつかの実施形態において、重複排除及び順序付けの両論理制約は、単一のトランザクションに関して対応され得る（他の論理制約も対応され得るが、重複排除及び順序付けに関わる動作のみが図２５において示される）。構成要素２５０１において示されるように、トランザクションＴ１の１つまたは複数の論理制約記述子を含むトランザクション要求記述子が、ログサービスの特定の持続的変更ログインスタンスに対応付けられた競合検出器において受信され得る。描かれた実施形態において、論理記述子ごとに対応検査デリミタが指定され、これは、論理制約を満たすか違反するかを判定する分析対象となるコミットレコードの集合を選択するために使用される。１つまたは複数のシグネチャのそれぞれの集合も、論理制約ごとに指定され得る。要求トランザクションの読み出し及び書き込み集合も、読み出し書き込み競合検査デリミタと一緒に示され得る。前述のように、いくつかの実施形態において、読み出し書き込み競合の検査に使用されるデリミタと同じデリミタが、１つまたは複数の論理制約に使用され得る。また、少なくとも一実施形態において、論理制約に別個のシグネチャは必要ではあり得ない。代わりに、例えば書き込み集合シグネチャが、重複排除及び／または順序付けシグネチャとして使用され得る。
【０１１２】
描かれた実施形態において、読み出し書き込み競合検査デリミタを使用して、分析対象となるコミットレコード第１集合ＣＲＳ１が特定され得る。このような集合は、例えば、読み出し書き込み競合検査デリミタから始まり、最新格納コミットレコードのシーケンス番号まで（またはトランザクション要求内に示される別の上限まで）の範囲内に存在するシーケンス番号を有するコミットレコードを含み得る。読み出し書き込み競合が検出された場合（構成要素２５０４）（例えばＣＲＳ１のコミットレコードのうちのいずれかの書き込み集合が、要求トランザクションの読み出し集合と重複する場合）、トランザクションは拒否／アボートされ得る（構成要素２５３１）。本明細書において、読み出し書き込み競合の検査は、要求トランザクションが並行処理制御要件を満たすことの検証ともみなされ得る。いくつかの実施形態において、受信したトランザクション要求の送信元であるクライアントに対し、トランザクションがアボートされたことが通知され得る。
【０１１３】
描かれた実施形態において、読み出し書き込み競合が検出されなかった場合（同様に構成要素２５０４に対応する動作において）、対応記述子により示されるそれぞれの論理制約が順次検査され得る。次の順序の論理制約記述子が調べられ、制約に対応付けられた検査デリミタに基づいて、制約分析の対象となる新たなコミットレコード集合ＣＲＳ‐ｋが選択され得る（構成要素２５０７）。例えば、ＣＲＳ‐ｋは、デリミタから始まり、記録済み最大コミットシーケンス番号で終わる（またはトランザクション要求内に示される別の上限までの）範囲内のシーケンス番号を有するコミットレコード全てを含み得る。行われる分析は、論理制約記述子の種類に依存し得る。重複排除制約が検査内容であり、ＣＤＲ‐ｋの重複排除シグネチャと要求トランザクションを比較することで重複が見つかった場合（構成要素２５１０）、トランザクションは同様に拒否／アボートされ得る（構成要素２５３１）。制約が重複排除制約であり、重複が見つからなかった場合（同様に構成要素２５１０にて検出）、かつまだ他に分析されていない論理制約がある場合、次の論理制約記述子が調べられ、そして構成要素２５０７以降に対応する動作が次の論理記述子のために繰り返され得る。
【０１１４】
制約記述子がコミット済みトランザクションの１つまたは複数の要求シグネチャを示す順序付け制約を示す場合、順序付け制約に関してＣＲＳ‐ｋが調べられ、コミットが完了したトランザクションに関して要求シグネチャが実際に格納されたことが確認され得る。要求トランザクションのコミットレコードが見つからなかった場合（構成要素２５１３にて検出）、要求トランザクションは同様にアボート／拒否され得る（構成要素２５３１）。要求トランザクションのコミットレコードが見つかった場合（同様に構成要素２５１３に対応する動作において）、順序付け制約処理は完了し得る。読み出し書き込み競合検出の場合のように、論理制約検査も、少なくともいくつかの実施形態において、比較のためにハッシュ関数を使用して行われ、よってコミットレコード集合を走査するオーバーヘッドは回避される。いずれかの論理制約記述子が残っている場合（構成要素２５１６）、それらは順番に調べられ得る。論理制約記述子はもう残っていない場合（同様に構成要素２５１６にて検出）、トランザクションはコミットのために受諾され得る。描かれた実施形態において、トランザクションのコミットレコードを、持続的格納域に、例えば複製ＤＡＧのいくつかのノードに保存する手続きが開始され得る（構成要素２５１９）。複製が成功した場合（例えば十分な数のコミットレコードのコピーが無事にそれぞれの格納デバイスに格納された場合）（構成要素２５２２にて検出）、トランザクションのコミットは完了したとみなされ得る。ある理由で、要求される数のレプリカが格納されなかった場合、トランザクションはやはり拒否／アボートされ得る（構成要素２５３１）。いくつかの実施形態において、トランザクションが無事にコミットされたという通知が、要求クライアントへ送信され得る（構成要素２５２５）。
【０１１５】
いくつかの実施形態において、代わりに複数の論理制約を検査する動作が並行して行われ得る。一実施形態において、読み出し書き込み競合検出と論理制約検査の任意の組み合わせが、並行して行われ得る。いくつかの実施形態において、それぞれの指示された論理制約に関する応答が、制約のうちの１つまたは複数が満たされなかったとしても、要求クライアントに対し提供され得る。例えば、重複排除制約と順序付け制約とを有するトランザクション要求の場合、重複排除制約が満たされなかったとしても順序付け制約は検査され、そして両制約の調査結果がクライアントに対し提供され得る。いくつかの実施態様において、クライアントは、所定のトランザクション要求の論理制約の特定の部分集合または全てが検査されるように、明示的に要求することが可能であり得る。
【０１１６】
ログ整合格納グループの価格設定ポリシー
少なくとも書き込み含有トランザクションが前述のようにログベーストランザクションマネジャーを使用して集合的に管理されるデータストア集合は、本明細書において、ログ整合格納グループ（ＬＣＳＧ）のメンバーデータストアと称され得る。例えば、ＬＣＳＧは、非リレーショナルデータベースの１つまたは複数のインスタンス、リレーショナルデータベースの１つまたは複数のインスタンス、プロバイダネットワーク格納サービスの１つまたは複数の格納オブジェクト、インメモリデータベースインスタンス、待ち行列サービス実施の持続的待ち行列、通知サービス等の複数のデータストアインスタンスを含み得る。データストアメンバーのためにインスタンス化された特定のログベーストランザクションマネジャーも、ＬＣＳＧの一部とみなされ得る。少なくともいくつかの実施形態において、ＬＣＳＧによりユーザは、様々なデータストア横断動作を要求することが可能になり得る。例えば、ＬＣＳＧにおいて所定のトランザクション内で行われる単一の論理書き込みは、いくつかの異なるデータストアに適用される複数の物理的更新に最終的に変換され得る（すなわち結果的になる）。このようにして、同一の基礎変更に関するいくつかの異なる見解は、データストアのそれぞれのデータアクセスインターフェースを介してアクセス可能とされ得る。
【０１１７】
格納システムクライアントが、持続性及びデータ耐久性のデータシステムインスタンスと、書き込み要求の結果に対し低レイテンシアクセスのインメモリ分散キャッシュインスタンスと、オフライン分析のデータウェアハウジングサービスと、長期記録保持のアーカイブ格納サービスとにおいて、同一の書き込み要求のデータペイロードを可視化することを所望するシナリオを検討する。一実施形態において、クライアントは、アプリケーションデータに対する所定の論理変化の対象として、４つのデータストアそれぞれを明示的に示すトランザクションを構築し得る。別の実施形態において、データストア横断トランザクションに対応することに加えて、またはこれに代わって、ＬＣＳＧがインスタンス化されたログサービスは、全ての異なる書き込み対象が所定のトランザクション要求内で明示的に指定されることを要さない自動データストア横断変換に対応し得る。その代わり、例えば構成要求に応じて、またはＬＣＳＧ設定中に、クライアントは、データベースインスタンスに対するいずれの所定の書き込みに関しても、対応表現が自動でインメモリキャッシュ、データウェアハウジングサービス、及びアーカイブ格納サービスに伝播されるように示すことが可能であり得る。いくつかの実施形態において、所定のペアのデータストア間の両方向の変換が対応され得る。例えば、クライアントアプリケーションがデータベースインスタンスに直接書き込みを行う場合、書き込みの結果は、ログサービスによりインメモリキャッシュが望む好適な形式でインメモリキャッシュに自動で追加され、そしてクライアントアプリケーションがインメモリキャッシュに直接別の書き込みを行う場合、別の書き込みの結果は、データベースインスタンスが望む形式でデータベースインスタンスに自動で伝播され得る。
【０１１８】
ログサービスは、いくつかの実施形態において、ＬＣＳＧにおいて行われる動作に対し、いくつかの異なる価格設定ポリシーを実施し、価格設定ポリシーのうちの少なくともいくつかは、クライアントのために行われる動作種類の混合比に基づき得る（例えば、単一データストアに対する書き込みを伴った動作の数に対し、いくつのデータストア横断変換及び／またはトランザクションがある時間間隔に行われたか）。所定の請求期間にＬＣＳＧ顧客に課される請求額は、後述の多数の要因、及び顧客のために、または顧客により選択された価格設定ポリシー（複数可）に基づいて変わり得る。後述の価格設定ポリシーのうちの少なくともいくつかは、所定のクライアントに対し、お互い組み合わせて使用され得る。例えば、段階的価格設定が、準備スループット型及びベストエフォート型の両リソース割り当てモードに適用され、そしてＬＣＳＧの各データストアに対し、それぞれの準備スループット型価格設定ポリシーが適用され得る。
【０１１９】
少なくとも一実施形態において、所定のＬＣＳＧに含まれる異なるデータストアの数、含まれるデータストアの種類、及び／またはクライアントのために行われるデータストア横断動作の数（例えば最初特定のデータストアを対象とする書き込みの第２表現を別のデータストアに生成することを伴う動作またはトランザクション）が、請求額に影響し得る。例えば、１つの価格設定ポリシーに従うと、８つのデータストアを有するＬＣＳＧを確立することは、全体の作業負荷レベル及び／またはデータ集合サイズ等の他の要素が同一であると仮定すると、４つのデータストアを有するＬＣＳＧを確立する場合よりも費用がかかり得る。他の例示的価格設定ポリシーに従うと、特定の作業負荷レベルに対応する４つのリレーショナルデータベースインスタンスを有するＬＣＳＧは、同じ作業負荷レベルに対応する４つのインメモリデータベースインスタンスを有するＬＣＳＧよりも費用がかかり得る。いくつかの実施形態において、クライアントは、行われたデータストア横断動作ごとに特定の額が請求され得る。一実施形態において、データストア横断動作の費用もまた、関与するデータストアの種類に基づいて異なり得る。例えば、最初リレーショナルデータベースを対象とする書き込みをインメモリデータベースにおける追加書き込みに変換する動作は、最初非リレーショナルデータベースを対象とする書き込みをインメモリデータベースにおける別の書き込みに変換する動作とは異なる額がかかり得る。いくつかの実施形態において、書き込み伝播の方向もまた、動作の価格に影響し得る。例えばデータストアＤＳ１からＤＳ２への書き込み変換は、ＤＳ２からＤＳ１への書き込み変換とは異なる額がかかり得る。
【０１２０】
いくつかの実施形態において、いくつかのモードのうちの１つのモードのＬＣＳＧが使用するプロバイダネットワークにおいて、リソース（演算サーバ、格納デバイス、ネットワーク帯域、メモリ等）が割り当てられ得る。準備スループットモードのリソース割り当てにおいて、ログサービスのクライアントは、ＬＣＳＧのメンバーとして登録される特定のデータストアに対し目標スループットレート（例えば毎秒１００トランザクション）を指示し、ログサービスは、要求されるスループットに耐えられるような十分なリソースを確保し得る（例えば障害がないといった少なくとも通常の動作条件下で）。準備スループットモードに基づいた価格設定ポリシーに従って、所定の請求期間中にクライアントにより投入された実際の作業負荷が図らずも目標を下回ったとしても、クライアントは目標スループットレート分請求され得る。いくつかの実施形態において、所定のＬＣＳＧの様々なデータストアに対して、異なる準備スループットがクライアントにより要求され得る。いくつかの実施形態によれば、準備スループットに対する請求レートは、データストアによって異なり得る。例えば、非リレーショナルデータベースの毎秒１００トランザクションの準備スループットに対するレートは、同じＬＣＳＧのメンバーであるリレーショナルデータベースの毎秒１００トランザクションの準備スループットに対するレートとは異なり得る。
【０１２１】
少なくともいくつかの実施形態において、ベストエフォートモードと呼ばれる別のモードのリソース割り当てにおいて、ログサービスは、必ずしもクライアントの指定目標スループットに対応するリソースを確保または献呈し得ない。代わりに、例えば、共有プール（複数可）からのリソースが、クライアントのＬＣＳＧに割り当てられ得る。クライアントの作業負荷レベルは変動するため、ログサービスは、例えば共有プール内の利用可能能力に基づいて、クライアントに割り当てられたリソース集合に対し、ベストエフォート調整を行い得る。少なくともいくつかの実施形態において、同じ作業負荷レベルに対して、ベストエフォート型リソース割り当てモードの価格設定ポリシーは、準備スループット型リソース割り当てモードの価格設定ポリシーとは、請求レートが異なり得る。いくつかの実施形態において、準備スループットの事例のように、ベストエフォート型リソース割り当てに関しても、異なるデータストアに対し異なる請求レートが適用され得る。
【０１２２】
少なくとも一実施形態によれば、段階的スループットベース価格設定モデルが実施され得る。例えば、クライアントが毎秒０〜１０００トランザクションを投入した場合、請求レートＢ１（例えばトランザクションごと）が課され、これは毎秒１０００〜２０００トランザクションのトランザクションレートに対する請求レートＢ２等とは異なる。いくつかの実施形態において、同様の段階ベース価格設定が、帯域使用量にも適用され得る。例えば、転送ギガバイト総数が０〜１０ＧＢ／日の場合、転送ギガバイト総数が１０〜２０ＧＢ／日の場合とは、異なる転送データギガバイト毎請求レートが課され得る。いくつかの実施形態において、使用されている持続的変更ログに関して及び／またはＬＣＳＧのメンバーデータストアに関して、ＬＣＳＧクライアントが要求する高可用性、データ耐久性、レイテンシのレベルに少なくとも部分的に基づいて、請求額が変わり得る。少なくとも一実施形態において、特定のデータストア種類集合にネイティブに対応するだけでなく、例えばサービスによりネイティブに対応されるデータストア種類と、ネイティブに対応されていない別のデータストア種類との間の変換に関して、カスタム拡張が追加されることを許容する格納サービスにおいて、ＬＣＳＧが実施され得る。いくつかのこのような実施形態において、所定の拡張の使用に適用される請求レートは、ネイティブ対応のデータストア種類に使用される請求レートとは異なり得る。
【０１２３】
自身の価格設定ポリシーをそれぞれ実施するプロバイダネットワークの各自のサービスを介して、ＬＣＳＧの様々なデータストアがそれぞれ実施される一実施態様において、クライアントはそれらのプロバイダネットワークサービスの使用に対してと、ＬＣＳＧの使用に対してと、別個に請求され得る。例えば、ＬＣＳＧのデータベースインスタンスを対象とする読み出しの請求額は、データベースサービスの価格設定ポリシーに従って計算され、一方ＬＣＳＧトランザクション及びデータストア横断変換動作に対する請求は、ＬＣＳＧ価格設定ポリシーに従って決定され得る。
【０１２４】
少なくとも一実施形態において、ログサービスのクライアントが代替価格設定ポリシーを見て、及び／またはクライアントの好み及び要件に基づいて特定の価格設定ポリシーを選択できるように、１つまたは複数のプログラマチックインターフェース（ウェブページ、ＡＰＩ等）が実装され得る。全体要求トランザクション及び／または読み出しレート、行われたデータストア横断及び単一データストア動作数、使用されたネットワーク帯域等の作業負荷関連メトリクスが、顧客のＬＣＳＧのために割り当てられたリソースから収集され得る。少なくともいくつかの実施形態において、ＬＣＳＧを実施するログサービスの制御プレーンにより行われる請求関連作業の一部は、作業負荷レコードを、データストア横断動作を示す１つの部分集合、あるいは単一データストア動作を示す別の部分集合に分類することを含み得る。例えば、両種類の動作（単一データストアあるいはデータストア横断）の書き込みレコードは、所定のデータストアにおける同一のログに格納され、そして作業負荷分析制御プレーンコンポーネントが、書き込みレコードのコンテンツを調べて、書き込みレコードはデータストア横断書き込みを表すか単一データストア書き込みを表すかを判定する必要があり得る。一実施態様において、メトリクスの収集のために、ＬＣＳＧに使用されているプロバイダネットワークの分散監視エージェントの集合が使用され得る。ＬＣＳＧに選択された価格設定ポリシーと収集されたメトリクスとに応じて、特定の請求期間の請求額が決定され、クライアントに示され得る。
【０１２５】
図２６は、少なくともいくつかの実施形態による、それぞれのログ整合格納グループ（ＬＣＳＧ）に対しそれぞれの価格設定ポリシーが実施され得る例示的システム環境を示す。示されるように、システム２６００は、２つのＬＣＳＧ２６０５Ａ、２６０５Ｂを備える。ＬＣＳＧ２６０５Ａは２つのデータストア２６３０Ａ、２６３０Ｂを含み、一方ＬＣＳＧ２６０５Ｂは４つのデータストア２６３０Ｃ、２６３０Ｄ、２６３０Ｅ、２６３０Ｆを含む。競合検出器２６１５Ａと、持続的変更ログ２６０１Ａと、書き込みアプライヤ集合２６１７Ａとを含むログベーストランザクションマネジャー（ＬＴＭ）２６０２Ａは、データストア２６３０Ａ、２６３０Ｂに対するクライアントに指示された書き込みを含むトランザクション要求を取り扱うように構成される。同様に、競合検出器２６１５Ｂと、持続的変更ログ２６０１Ｂと、書き込みアプライヤ集合２６１７Ｂとを含むＬＴＭ２６０２Ｂは、データストア２６３０Ｃ〜２６３０Ｆに対するクライアントに指示された書き込みを管理するように構成される。持続的変更ログ２６０１は、本明細書において、書き込みログとも称され得る。
【０１２６】
ＬＣＳＧが実施されるログサービスまたは格納サービスの制御プレーン２６４９は、例えばＬＣＳＧメンバー情報の管理、クライアントアカウントとアカウントに割り当てられたサービスリソースとのマッピング、様々なＬＣＳＧに使用されている価格設定／請求ポリシーの追跡等を含む、設定及び管理タスクの責務を担う複数のコンポーネントを含み得る。描かれた実施形態において、請求マネジャー２６５１は、例えば、ＬＣＳＧ２６０５Ａ、２６０５Ｂを対象とする要求に関する１つまたは複数の価格設定ポリシー選択肢に基づいて、クライアントの請求額を生成する責務を担い得る。描かれた実施形態において、利用可能な価格設定ポリシー集合が、ＬＣＳＧを実施するサービスの実際の顧客または可能性のある顧客に対し、ウェブページ、ＡＰＩ、コマンドラインツール、またはカスタムＧＵＩ等の１つまたは複数のプログラマチックインターフェースを介して示され得る。少なくともいくつかの実施形態において、顧客も、このようなプログラマチックインターフェースを介して、例えば顧客が様々なデータストア２６３０をＬＣＳＧメンバーとして登録する時に、またはＬＣＳＧが設定された後のある時点に提出される価格設定ポリシー変更要求により、顧客のＬＣＳＧに適用する特定の価格設定ポリシーを指示し得る。描かれた実施形態において、ＬＣＳＧ２６０５Ａに対し価格設定ポリシー２６４４Ａが特定され、一方でＬＣＳＧ２６０５Ｂに対し別の価格設定ポリシー２５４４Ｂが選択されている。各価格設定ポリシーは、例えば、少なくとも特定の請求期間中に、様々な異なる動作種類及び／またはリソース利用単位に使用する請求レートを示し得る。所定の請求期間に顧客に課される請求額（例えばＢＡ１またはＢＡ２）は、請求期間中にそれらのＬＣＳＧに対し実施されている価格設定ポリシー（複数可）と、請求期間中に収集された様々なメトリクスの分析とに基づいて、請求マネジャー２６５１により決定され得る。
【０１２７】
メトリクスコレクタ２６５５Ａは、データストア２６３０Ａ及び／またはＬＴＭ２６０２に使用されるサーバ及びデバイス等の様々なリソースを監視し、収集されたメトリクスの開示を請求マネジャー２６５１に提供する責務を担い得る。例えばコンピューティングサービス、格納サービス等のプロバイダネットワークのサービスを使用して、プロバイダネットワーク内でＬＣＳＧが実施される実施形態において、一部または全てのサービスに既存のメトリクス収集インフラストラクチャが利用可能であり、請求マネジャーは、当該既存のメトリクス収集インフラストラクチャから、請求額を生成するために必要となるメトリクスのうちの少なくともいくつかを取得し得る。一実施形態において、制御プレーン２６４９は、例えば、各ＬＣＳＧのメンバーを特定する責務を担うメンバーシップマネジャー、収集された作業負荷メトリクスをクライアント毎及び／または動作種類毎のサブグループに分類するメトリクスアナライザ、及び選択された価格設定ポリシーと作業負荷メトリクスとに基づいて様々なクライアントに対する請求額を生成する請求書ジェネレータといった、様々な価格設定／請求関連タスクのそれぞれのコンポーネントを含み得る。
【０１２８】
ＬＣＳＧ２６０５に適用される所定の価格設定ポリシー２６４４において、例えば、ＬＣＳＧのメンバーであるデータストア２６３０の数及び／または種類、動作混合比（単一データストア書き込み対データストア横断書き込み）、使用したリソース割り当てモデル（例えば準備スループット型あるいはベストエフォート型）、要求トランザクションレート等、多数の異なる要素が考慮され得る。図２７は、少なくともいくつかの実施形態による、単一データストア及びデータストア横断書き込み動作の実施例を示す。描かれた実施形態において、ＬＣＳＧ２７０５は、ＮｏＳＱＬ  ＤＢインスタンス２７３０Ａ、キー値インメモリＤＢ  ２７３０Ｂ、分散キャッシュインスタンス２７３０Ｃ、リレーショナルＤＢインスタンス２７３０Ｄ、格納サービスオブジェクト２７３０Ｅ、アーカイブサービスオブジェクト２７３０Ｆの６つのメンバーデータストアを含む。例示されるように、所定ＬＣＳＧのメンバーデータストアは、非常に異なるデータモデルを実施し（例えばリレーショナルあるいは非リレーショナル、構造化レコードあるいは非構造化データオブジェクト等）、従って、少なくともいくつかの実施形態において、メンバーデータストアでは、異なる読み出しインターフェース及びデータ形式が使用され得る。
【０１２９】
クライアントによる要求トランザクションに明示的に含まれる書き込みと、ログサービスが自動的に行うように構成された書き込み（例えば明示的要求書き込みの結果または副作用として）の、２種類の書き込み動作が図２７において例示される。トランザクション要求２７０２Ａは、書き込みペイロードＷ１が、ＮｏＳＱＬ  ＤＢインスタンス２７３０Ａと、格納サービスオブジェクト２７３０Ｅも対象にすることを示す。従って、書き込みペイロードＷ１の表現Ｗ１‐ＡはＮｏＳＱＬ  ＤＢインスタンス２７３０Ａに格納され、同じ書き込みペイロードの別の表現Ｗ１‐Ｂは格納サービスオブジェクト２７３０Ｅに格納される。トランザクション要求２７０２Ｂも同様に、ペイロードＷ２のデータストア横断書き込みの要求を含む。従って、書き込みペイロードＷ２の第１表現Ｗ２‐ＡはリレーショナルＤＢインスタンス２７３０Ｄに格納され、一方、書き込みペイロードＷ２の第２表現Ｗ２‐Ｂは分散キャッシュインスタンス２７３０Ｃに格納される。トランザクション要求２７００２Ｃは、単一データストア書き込みを有する。トランザクション要求２７０２Ｃの書き込みペイロードＷ３の表現Ｗ３‐Ａは従って、ＮｏＳＱＬ  ＤＢインスタンス２７３０Ａに格納される。少なくともいくつかの実施形態において、単一データストア書き込みを有するトランザクションの請求レートは、データストア横断書き込みトランザクションの請求レートとは異なり得る。少なくともいくつかの実施態様において、基準請求レートがトランザクションごとに課され、そして追加請求額が、トランザクションに含まれる書き込みの数と対象データストアの種類とに基づいて課金され得る。
【０１３０】
要求トランザクション内に明示的に示される書き込みに加えて、ＬＣＳＧ２７０５は、自動変換及び／またはあるメンバーデータストアから別のメンバーデータストアへのデータのコピーにも対応し得る。このようなデータストア横断変換の２つの実施例が、図２７に示される。第１の実施例において、書き込みペイロードＷ１の第３表現Ｗ１‐Ｃが、格納サービスオブジェクト２７３０Ｅの表現Ｗ１‐Ｂから自動的に生成され、キー値インメモリデータベース２７３０Ｂに格納される。第２実施例において、Ｗ２‐Ａを変換元として使用して、書き込みペイロードＷ２の第３表現Ｗ２‐Ｃがアーカイブサービスオブジェクト２７３０Ｆに格納される。少なくとも一実施態様において、このような自動データストア横断変換動作が行われる変換元及び変換先データストアの各組に対し、それぞれの書き込みアプライヤが設定され得る。例えば、書き込み（Ｗ１‐Ｂ等）が格納サービスオブジェクト２７３０Ｅに適用された時に通知されるリスナーとして特定の書き込みアプライヤが登録され、そのため対応書き込み（Ｗ１‐Ｃ等）がキー値インメモリデータベース２７３０Ｂにて実行され得る。ＬＣＳＧ２７０５のために実施されている価格設定ポリシーに従って、描かれた実施形態において、各種類の自動データストア横断変換に対し、それぞれの請求レートが設定され得る。請求レートは、異なる実施形態において、例えば、具体的な変換元及び変換先データストアの種類、特定の書き込みが変換元データストアに適用されてから対応表現が変換先データストアに適用されるまでの許容遅延時間等、様々な要素に基づき得る。従って、例えば、リレーショナルＤＢインスタンス２７３０Ｄ（変換元データストア）に最初書き込まれるオブジェクトの別の表現をアーカイブ格納サービス２７３０Ｆ（変換先データストア）内で生成することに対し、請求レートＢＲ１が使用され、一方、同じオブジェクトの別の表現を分散キャッシュインスタンス２７３０Ｃ等の別の変換先データストア内で生成することに対し、別の請求レートＢＲ２が使用され得る。少なくともいくつかの実施形態において、所定の組のデータストアに関して、データストア横断変換動作の方向は、請求レートに影響し得る。
【０１３１】
図２８は、少なくともいくつかの実施形態による、ログ整合格納グループに対する価格設定ポリシーを決定する際考慮され得る要素の実施例を示す。データストアの数及び種類２８０２は、いくつかの実施形態において、クライアントに支払いが求められ得る最初の前払い金、並びに現行の利用ベース料金を含む、価格設定のいくつか態様に影響し得る。例えば、非リレーショナルデータベースの４つのインスタンスを有するＬＣＳＧを設定する場合、非リレーショナルデータベース、リレーショナルデータベース、分散キャッシュインスタンス、及びアーカイブサービスのアーカイブインスタンスそれぞれを１インスタンスずつ有するＬＣＳＧを設定する場合とは、請求額が異なり得る。ＬＣＳＧにおけるデータストアの数は、同一基礎データに対してクライアントがアクセスできる可能閲覧数も表し得る。
【０１３２】
作業負荷動作種類混合比２８０４は、少なくともいくつかの実施形態において、請求額に影響し得る。例えば前述のように、データストア横断動作の費用は、単一データストア動作とは異なり得る。いくつかの実施形態において、顧客の作業負荷における読み出し及び書き込みの混合比も請求額に影響を及ぼし得る。例えば読み出しの費用は通常、書き込みより安くあり得る。図１５に関して前述されたように、少なくともいくつかの実施形態において、ログ読み出しインターフェースにより、クライアントはＬＣＳＧの持続的ログに対し直接読み出しを発行可能となり、そしてこのようなインターフェースを使用する毎読み出し費用は、データストアのインターフェースを使用する毎読み出し費用とは異なり得る。データストアを対象とする読み出しがプロバイダネットワークのそれぞれのサービスにより取り扱われる（すなわち秒ごとにログサービスによるのではない）いくつかの実施態様において、データストアのネイティブ読み出しインターフェースを使用する読み出しに対する請求は、ログサービスの使用に対応付けられる請求とは別個に取り扱われ得る。
【０１３３】
ＬＣＳＧの使用に対する価格設定ポリシーは、いくつかの実施形態において、リソース割り当てモード２８０６に基づいて異なり得る。準備スループットモードにおいて、ログサービスは、クライアントの指定スループットレベルに対し利用可能な十分な能力が確実に残っているように、クライアントに対しリソースを確保または献呈する必要があり得る。対照的に、ベストエフォート型リソース割り当てモードにおいて、クライアント要求を遂行するために共有リソースが使用され、これにより、ログサービスリソースの平均使用レベルは準備スループットモードより高くなり得る。従って、少なくともいくつかの実施形態において、準備スループットモードが使用される時と、ベストエフォートモードが使用される時とでは、同一の実トランザクションレートに対し、異なる額がクライアントに課され得る。いくつかの実施形態において、要求レート段階２８０８が価格設定ポリシーに関して定義され得る。段階ベース価格設定に従って、所定のトランザクションに対する請求レートは、クライアントが毎秒０〜１０００トランザクション要求を発行したか否か、またはクライアントが毎秒１０００〜２０００トランザクションを発行したか否かに応じて異なり得る。少なくともいくつかの実施形態において、クライアントの作業負荷に対するネットワーク帯域使用量２８１０が、価格設定ポリシーに影響し得る。トランザクションの特徴に応じて、特定数Ｎ１個のトランザクション要求は、第１クライアントに対してＸギガバイトのトラフィックとなり、一方、Ｎ１個のトランザクションは、別のクライアントに対して（または第１クライアントに対しても別の時間間隔において）Ｙギガバイトのトラフィックとなり得る。ログサービスにより生じるリソース使用量の少なくとも一部はネットワーク帯域に比例して異なり得るため、ログサービスのいくつかの価格設定ポリシーは、測定帯域使用量に少なくとも部分的に基づき得る。様々な実施形態において、ログサービスにより使用される監視インフラストラクチャ（例えばメトリクスコレクタ２６５５Ａ）は、異なるクライアントに対し帯域使用量を割り当てる様々な技術を使用し得る。例えば、このような割り当ては、ネットワークパケットヘッダーに組み込まれるクライアントＩＰアドレス、パケットヘッダーまたは本体に組み込まれるクライアント識別子等に基づき得る。
【０１３４】
少なくともいくつかの実施形態において、価格設定ポリシーは、レイテンシ要件２８１２、可用性要件２８１４、及び／またはデータ耐久性要件２８１６に基づいて定義及び／または選択され得る。例えば、ほとんどのトランザクションは対応トランザクション要求が提出されて２秒以内に受諾されるという要件を１つのクライアントのアプリケーション集合が有し、そしてこのようなクライアントは、提出済みのトランザクションの少なくとも９５％が２秒以内に受諾されるのであれば、より高い毎トランザクションレートを支払う意思があり得る。このようなレイテンシパーセンタイル値測定または平均レイテンシに基づいた価格設定ポリシーは従って、このような実施形態においてログサービスにより対応され得る。異なるクライアント及び／またはクライアントアプリケーションは、いくつかの実施形態において、ログサービスに対し異なる高可用性要件２８１４（例えばＬＣＳＧの様々なコンポーネントが９９．９９％の時間、または９９．９９９９％の時間、オンラインで応答可能である必要がある）を有し、これは選択された価格設定ポリシーに影響し得る。少なくとも一実施形態において、データ耐久性に関する要件２８１６（例えばログレコードの最大許容データ損失レート）も価格設定に影響し得る。
【０１３５】
ログサービスは、例えばプロバイダネットワークにおいて実施されるプロプライエタリデータベースもしくは格納サービス、人気のオープンソースデータベース、キャッシュサービス等、多数の異なるデータストアの種類にネイティブに対応し得る。さらに、少なくともいくつかの実施形態において、ログサービスは、第三者またはクライアントにより拡張可能であり得る。このような実施形態において、拡張性インターフェース集合が開示され、これにより、ログサービスのオペレータ以外の組織または個人は、新たなデータストアの種類のログベーストランザクション管理に対しサポートを追加することが可能になる。例示的拡張は、ログサービスによりネイティブに対応されない様々なデータストアに対する書き込みアプライヤ、または、このようなデータストアが図２７に例示される類の自動データストア横断変換の変換元または変換先として機能することを可能にするデータトランスフォーマを含み得る。少なくともいくつかの実施形態において、ＬＣＳＧの価格設定ポリシーは、このような拡張の使用を考慮し得る。例えば、ネイティブに対応されるデータストアを使用するトランザクションに適用される料金とは異なる料金が、拡張を使用するトランザクションに適用され得る。
【０１３６】
様々な実施形態において、所定の顧客のための所定のＬＣＳＧに使用する具体的な価格設定ポリシーを特定するために、図２７に例示される要素のうちのいくつか（または全て）が結合され得ることに留意されたい。例えば、段階的価格設定及び／または帯域ベース価格設定は、いくつかの実施形態において、準備スループット型リソース割り当てモードまたはベストエフォート型リソース割り当てモードと組み合わせて適用され得る。同様に、ＬＣＳＧに含まれるデータストアの数及び種類は、様々な実施形態において、作業負荷動作混合比、スループット段階、レイテンシベース価格設定等と相まって、請求額に影響し得る。
【０１３７】
少なくともいくつかの実施形態において、ログサービスのクライアントは、いくつかの選択肢の中から価格設定ポリシーを選択する機会を与えられ得る。図２９は、少なくともいくつかの実施形態による、ログ整合格納グループを実施するサービスのユーザに対し価格設定ポリシーの選択肢を示すために使用され得る例示的ウェブベースインターフェースを示す。示されるように、ウェブページ２９０１は、メッセージエリア２９０４と、多数の書式フィールドとを備え、書式フィールドは、ログサービスユーザが、異なる価格設定ポリシーコンポーネントを試行して、ユーザの要件及び予算に最適である特定の価格設定ポリシー要素集合を選択するために、使用され得る。
【０１３８】
メッセージエリア２９０４に示されるように、描かれた実施形態におけるＬＣＳＧの使用に関する費用は、ログサービスを使用してトランザクションが管理されるデータストアの数及び種類に依存し得る。ユーザは、構成要素２９０７を使用して、ＬＣＳＧにいくつの異なる種類のデータストアを含めるか指示し、これを基に、価格がウェブページ２９０１を使用して推定または決定される。例えば、クライアントはゼロまたは複数のＮｏＳＱＬデータベースのインスタンス、ゼロまたは複数のリレーショナルデータベースのインスタンス、ゼロまたは複数のインメモリデータベースのインスタンス、及び／またはゼロまたは複数の他の種類のデータベースのインスタンスを選択し得る。データストアカウントフィールドを含むページ２９０１上に表示される書式フィールドのうちのいくつかに関して、ログサービスは初期設定値を示し得る（ＮｏＳＱＬデータベースインスタンスの数の初期設定値は１等）。いくつかの実施形態において、ユーザが様々な書式フィールド内に値を入力すると、ウェブページ２９０１の他の構成要素内のデータは、瞬時またはほぼ瞬時に更新され得る。例えば、ユーザがＮｏＳＱＬデータベースインスタンスの数を１から２に変更すると、総請求月額２９２５に対するこのような変更の影響が、リアルタイムに示され得る。
【０１３９】
描かれた実施形態において、ユーザは、書式フィールド２９１０を使用して、リソース割り当てモードに対する希望（例えば準備スループット型あるいはベストエフォート型）を指示し得る。図２９の例示的シナリオにおいて、単一データストア要求とデータストア横断要求の両方に対し、段階的価格設定モデルが使用され得る。データストア種類ごとに、書き込みの予想要求レート（例えば毎秒書き込み数）が、書式フィールド２９１３を使用して指示され得る。データストア横断書き込み（所定の変換元データストア種類と所定の変換先データストア種類の間）の予想要求レートが、書式フィールド２９１６を使用して指示され得る。他の変換元と変更先の組のデータストア横断変換の予想要求レートも、例えばフィールド２９１６内に示されるリンクをクリックして変換元、変換先、及びレートを指示することにより、同様に指示され得る。書き込み要求レートのフィールド等、１つまたは複数のフィールドに関して、ウェブページ２９０１は、個別の選択肢集合を有するドロップダウンメニューを提供し得る（例えばこれにより、ユーザがマイナスの要求レート等、対応エンティティの不対応値を指示することが防止される）。ユーザはまた、描かれた実施形態において、構成要素２９１９を使用して、帯域使用量段階を指定し得る。レイテンシ、データ耐久性及び／または可用性に関するカスタム希望指示は、構成要素２９２２内に示されるリンクをクリックすることにより提供され、そしてこのような希望指示も価格設定に影響し得る。ユーザが入力した値に基づいた請求月額の見積もりが、ウェブページ２９０１の構成要素２９２５内に提供され得る。ウェブページ２９０１は、ログサービスのクライアントが価格設定ポリシー選択肢から選択を行うことを可能にするために使用され得るプログラマチックインターフェースの一例にすぎないことに留意されたい。定義済み性能特性を有する事前定義のデータストアパッケージ（例えば「小さい」あるいは「中くらい」あるいは「大きい」ＬＣＳＧ）及び価格設定ポリシーの使用等、多数の他の手法が、別の実施形態において使用され得る。ユーザが最初に予算を指定して、その後そのような予算に対応可能な特定のデータストアの組み合わせ、作業負荷混合比等をユーザに案内する予算ベースモデル等、価格設定に対し他の手法をとるウェブページが、別の実施形態において使用され得る。いくつかの実施形態において、ＬＣＳＧ価格設定に影響すると示される要素は、図２９に示されるものとは異なり得る。様々な実施形態において、ウェブページよりも、ＡＰＩ、カスタム価格設定ＧＵＩ、または他のプログラマチックインターフェースが使用され得る。
【０１４０】
図３０は、少なくともいくつかの実施形態による、ログ整合格納グループ（ＬＣＳＧ）に対応するサービスにて請求額を決定するために行われ得る動作態様を示すフロー図である。構成要素３００１に示されるように、サービスは、クライアントのための特定のログ整合格納グループのメンバーとして指定された複数のデータストア（例えばリレーショナルデータベース、非リレーショナルデータベース、インメモリデータベース、分散キャッシュ環境、格納サービスオブジェクト集合、ファイルシステム等のインスタンス）を特定または同定し得る。いくつかの実施形態において、メンバー情報は、データストアが登録された時に（例えばクライアントの要求でＬＣＳＧが設定された時に）、サービスの制御プレーンコンポーネントにおいて取得され得る。別の実施形態において、現行メンバーを特定するために、ＬＣＳＧメンバー情報のレポジトリ（メンバーの追加または削除により経時的に変化し得る）が、例えば少なくとも請求期間ごとに１度、調べられ得る。読み出しは、データストアに対しそれぞれの読み出しインターフェースを介して送られ、一方書き込みは、書き込みレコードログのコンテンツに少なくとも部分的に基づいて、ＬＣＳＧのトランザクションマネジャーにより受諾または拒否され得る。
【０１４１】
構成要素３００４に示されるように、ＬＣＳＧの使用に対する請求額に影響する複数の価格設定ポリシーの選択肢または要素の指示が、クライアントに提供され得る。少なくともいくつかの実施形態において、クライアントは、図２９に示されるものと同様のプログラマチックインターフェースを使用して、所定のＬＣＳＧの可能性のあるデータストアの組み合わせを指示し、そしてサービスはクライアントの入力に応じて価格設定ポリシーの選択肢を表示し得る。価格設定ポリシー選択肢は、異なる実施形態において価格設定の決定に関与し得る幅広い種類の要素を含み得る。これには例えば、ＬＣＳＧのメンバーであるデータストアの数及び種類のある組み合わせ、動作種類の混合比（例えば単一データストア書き込み対複数データストア書き込み）、リソース割り当てモード（例えば準備スループット型あるいはベストエフォート型）、段階的または絶対的性能レベル（例えばスループットまたはレイテンシに関して）、帯域使用量、データ耐久性、可用性等が含まれる。
【０１４２】
特定の価格設定ポリシー、例えばデータストア選択、データストア横断書き込み等の異なる動作種類の予想作業負荷レベルに関してクライアントが提供した入力に少なくとも部分的に基づいて導出されるポリシーを、少なくともある時間帯に、クライアントのＬＣＳＧに対し使用するという指示が、クライアントから受信され得る（構成要素３００７）。当該時間帯に、価格設定ポリシーに関連する様々なメトリクスが収集され、例えばサービスの請求／価格設定制御プレーンコンポーネントに提供され得る。様々な種類のクライアント要求の数及びレート（かつクライアント要求に対応付けられた応答時間またはレイテンシ）を含む作業負荷関連メトリクス、並びにクライアントが使用したネットワーク帯域等のリソース関連メトリクスが収集され得る。いくつかの実施形態において、制御プレーンコンポーネントは、作業負荷レコード（及び／またはリソース使用量メトリクス）を、例えばデータストア横断書き込み、あるいは単一データストア書き込みといった、異なる動作カテゴリを表すサブグループに分類する責務を担い得る（構成要素３０１０）。描かれた実施形態において、収集されたメトリクスと、クライアントのために、またはクライアントにより選択された価格設定ポリシーとに基づいて、時間帯の請求額が決定され（構成要素３０１３）、クライアントに示され得る（構成要素３０１６）。少なくとも一実施形態において、クライアントは、サービスのプログラマチックインターフェースを使用して、先の請求時間帯の請求ポリシーを変更し得る。
【０１４３】
読み出し再現性検証のための記述子
前述のように、ログベーストランザクションマネジャーは、いくつかの種類の直接読み出し動作に関して、読み出し位置（すなわちトランザクション中にデータが読み出されるアドレスに関する情報）にのみ基づいて、後続の書き込みとの競合を検出することが可能であり得る。しかしながら、さらに複雑な読み出しに関しては、このような単なる位置ベース競合検出は、十分ではあり得ない。図３１は、少なくともいくつかの実施形態による、トランザクション受諾のために読み出し位置ベース競合検出を使用することによりデータ不整合が生じ得る、格納システムにおける例示的一連イベントを示す。タイムライン３１９９は、ログサービスのクライアントの観点からの一連のイベントＥ１、Ｅ２、Ｅ３、Ｅ４、Ｅ５を、より前のイベントは左側に、そしてより後のイベントは右側に示す。データストア３１１０は、Ｅ１より前に少なくとも３つレコードを有する「従業員」テーブルを備える。各レコードはそれぞれの位置（“Ｌｃ”等、接頭文字“Ｌ”の表示で示される）を有し、従業員名フィールド及び給与フィールドを含む。描かれた実施例において、従業員“Ａｎｄｙ”の給与は＄Ｘであり、従業員“Ａｎｎ”の給与は＄Ｙである。イベントＥ１は、クライアントによる、“Ａ”で始まる名前の従業員のレコードのコンテンツを取得する読み出し要求Ｒ１の提出に対応する（例えば、ＳＱＬのような疑似コードで、要求「従業員テーブルから従業員名が“Ａ”で始まる＊を選択」が提出され得る）。イベントＥ２は、従業員“Ａｎｄｙ”、“Ａｎｎ”のレコードを含むＲ１の結果集合を有する、データストアからの応答を含む。２つのレコードのアドレス／位置Ｌｃ、Ｌｋ、並びに最新のコミット済み書き込み（読み出しより前）がデータストア３１１０に適用された時を示す論理タイムスタンプＬＴＳ１も、クライアントに返される。
【０１４４】
その後クライアントは、Ｒ１の結果集合に基づいて、“Ａ”で始まる名前の従業員の平均給与（“Ａ＿ｓａｌ”）の計算を行う（イベントＥ３）。クライアントが受信した結果集合に従って、Ａ＿ｓａｌは、＄Ｘと＄Ｙの平均に設定される（すなわち（＄Ｘ＋＄Ｙ）／２）。その一方で、（ＬＴＳ１＋デルタ１）に対応するある時間に、新従業員“Ａｒｔ”（給与は＄Ｊ）のレコードが、書き込みアプライヤにより従業員テーブル内の位置Ｌｎに挿入される。クライアントは、挿入に気が付かずに、クライアントにより計算されたＡ＿ｓａｌの書き込みを含むトランザクション要求を準備する。ＴＲ１はまた、読み出し位置Ｌｃ、Ｌｋ（例えば２つの位置のそれぞれのハッシュシグネチャを使用する）と、競合検査デリミタとして論理タイムスタンプＬＴＳ１とを示す。ＴＲ１は、論理タイムスタンプ（ＬＴＳ１＋デルタ１＋デルタ２）に対応する時間に、データストア３１１０に割り当てられたログベーストランザクションマネジャー（ＬＴＭ）において調べられる（イベントＥ４）。競合検出の一環として、ログベーストランザクションマネジャーは、ＬＴＳ１以降に読み出し集合位置Ｌｃ、Ｌｋに対し書き込みが行われたか否かを検査し、いずれのそのような書き込みも発見しない。従って、（ＬＴＳ１＋デルタ１＋デルタ２）のコミット論理タイムスタンプと、Ａ＿ｓａｌの不整合／不正確な値とを有する要求トランザクションが、コミットのために受諾される（イベントＥ５）。（示される例示的一連イベントを考えると、Ａ＿ｓａｌの値は、（＄Ｘ＋＄Ｙ）／２の代わりに（＄Ｘ＋＄Ｙ＋＄Ｊ）／３に設定されるべきであり、故に不整合または不正確とみなされ得る。）不一致は、ＬＴＭによるエラーの結果ではなく、むしろいくつかの種類の読み出しに関してアドレスベースの読み出し書き込み競合検出は、必ずしも読み出し再現性を検証するのに使用可能とは限らないという事実の結果であることに留意されたい（すなわち読み出しの結果集合が変化していないことを検査するには、読み出しが再発行されなければならない）。
【０１４５】
図３１に例示される問題の類に対応するために、トランザクション要求に含められる読み出し記述子は、アドレスベースのハッシュシグネチャ等の位置インジケータよりも複雑なメタデータを含む必要があり得る。例えば、いくつかの種類の読み出しに関して、メタデータは、読み出しに使用されるクエリ述語（例えばＳＱＬのようなクエリの「ＷＨＥＲＥ句」）の少なくとも一部の符号化、または読み出し要求の全テキストさえ、含み得る。いくつかの事例において、読み出しの結果集合が変化したか否かを判定するために呼び出し可能な関数（または関数へのポインタ）が、メタデータ内に示され得る。いくつかの実施形態において、読み出しの結果が変化したか否かを判定するために評価され得る式が、ＲＲＶＭとして提供され得る。用語「読み出し再現性検証メタデータ」（ＲＲＶＭ）は、本明細書において、対応読み出し要求が再提出された場合でも、前の読み出し要求の提出時と同じ結果集合を生じるか否か、すなわち所定の読み出し要求は、最初の読み出し要求の提出後のある時点で「再現可能な読み出し」を表すか否かを、判定するために使用可能な情報を指すのに使用され得る。
【０１４６】
図３２は、少なくともいくつかの実施形態による、読み出し要求に応じて提供される読み出し記述子がＲＲＶＭコンポーネントを含むシステム環境を示す。示されるように、システム３２００は、格納サービスの異種格納グループ３２０１を含み、当該格納グループは、メンバーデータストア３２３０Ａ、３２３０Ｂを備える。各データストア３２３０は、例えばデータストア３２３０Ａの読み出しインターフェース３２２７Ａ、データストア３２３０Ｂの読み出しインターフェース３２２７Ｂ等、それぞれのプログラマチック読み出しインターフェースを提示し得る。２つのデータストアは、読み出しインターフェースのみではなく、基礎データモデルにおいても異なり得る（例えば１つのデータストアはリレーショナルデータベースのインスタンスを有し、一方もう一つのデータストアは非リレーショナルデータベースのインスタンスを表し得る）。データストア３２３０は、いくつかの実施形態において、データストアがプロバイダネットワークにてインスタンス化されたクライアント等、特定のクライアントの要求で、格納グループ３２０１のメンバーとして登録され得た。各データストアは、データストア３２３０Ａのオブジェクト３２１０Ａ〜３２１０Ｆ、及びデータストア３２３０Ｂのオブジェクト３２１０Ｍ〜３２１０Ｑ等、それぞれの複数のデータオブジェクト（例えばレコード、ファイル、ウェブサービスインターフェースを介してアクセス可能な非構造化データオブジェクト、キャッシュエントリ等、データソースの性質による）を含み得る。さらに、各データストアは、データストアで行われた様々な書き込み動作に対応する論理スタンプ等、１つまたは複数のステート遷移インジケータ３２２５を格納し得る。例えば、データストア３２３０Ａの事例において、３つの異なる書き込みＷ１‐Ａ、Ｗ２‐Ａ、Ｗ３‐Ａがこの順序で完了または適用された場合、Ｗ３‐Ａの書き込みが完了した後の少なくとも１つのＳＴＩ３２２５Ａは、Ｗ３‐Ａに対応付けられる論理タイムスタンプに該当し得る。同様に、データストア３２３０Ｂにおいて、書き込みＷ１‐Ｂ、Ｗ２‐Ｂがこの順序で完了した後の少なくとも１つのＳＴＩ３２２５Ｂは、Ｗ２‐Ｂに対応する論理タイムスタンプを表し得る。
【０１４７】
描かれた実施形態において、格納グループ３２０１の様々なメンバーデータストア３２３０はそれぞれ、共通読み出し記述子形式３２９８に従って、読み出し記述子を生成するように構成され得る。読み出しインターフェース３２２７Ａを介してデータストア３２３０Ａにて受信された読み出し要求Ｒ１‐Ａに応じて、例えば、ＳＴＩ３２４６ＡとＲＲＶＭ３２４４Ａを含む読み出し記述子３２４２Ａが、格納サービスのクライアント側コンポーネント３２３５へ提供され得る。前述のように、ＲＲＶＭは、最初のＲ１‐Ａ結果集合３２４０Ａが生成された後のある時点で、Ｒ１‐Ａの結果集合が変化したか否かを判定する（またはある高い確率で予測する）ために使用され得る。少なくともいくつかの実施形態において、クライアント側コンポーネント３２３５は、エンドユーザ３２６６からエンドユーザ読み出し要求（及び／または書き込み要求）を受信し、対応内部要求を好適なバックエンドデータストア３２３０へ送る格納サービスのフロントエンド要求ハンドラノードを備え得る。別の実施形態において、クライアント側コンポーネント３２３５は、格納サービスにより提供されるライブラリのコンポーネントを備え、当該ライブラリコンポーネントは、例えば異種格納グループ３２０１が実施されるプロバイダネットワークの外側、またはプロバイダネットワーク内で、クライアント所有のコンピューティングデバイスにてインストール及び実行され得る。一般に、異種格納グループが実施されるプロバイダネットワーク内、またはプロバイダネットワークの外側に配置され、かつ読み出し要求及び／またはコミット要求のために本明細書において説明されるプログラマチックインターフェースを使用可能な任意のプロセスまたはデバイスが、クライアント側コンポーネントとして機能し得る。同様に、読み出しインターフェース３２２７Ｂを介してデータストア３２３０Ｂへ送られる読み出し要求Ｒ１‐Ｂに応じて、Ｒ１‐Ｂの結果集合３２４０Ｂに加えて、読み出し記述子３２４２Ｂが、クライアント側コンポーネントに提供され得る。読み出し記述子３２４２Ｂは、Ｒ１‐Ｂが再現可能な読み出しであるか否かを検証するために使用可能なＲＲＶＭ３２４４Ｂと、Ｒ１‐Ｂの最初の結果集合３２４０Ｂが生成された時のデータストア３２３０Ｂのステートに対応するＳＴＩとを含み得る。少なくともいくつかの実施形態において、ＲＲＶＭ３２４４を含む読み出し記述子３２４２は、対応読み出しがこれからトランザクション要求に使用されるか否か（例えば書き込みが読み出し要求の結果集合に依存するか否か）とは関係なく、読み出し要求に応じて提供され得ることに留意されたい。同様に、ＲＲＶＭを含む読み出し記述子は、少なくともいくつかの実施形態において、データストアに対する書き込みがクライアント側コンポーネントにより直接行われるか否か、または書き込みが前述の類のログベーストランザクションマネジャーにより整合され、及び／または前述の類の書き込みアプライヤにより伝播されるか否かに関係なく、提供され得る。少なくともいくつかの実施形態において、単純な読み出し（例えば「テーブルＴ１からレコードＩＤがＲＩＤ１である*を選択」）に関して読み出し再現性を検証��るには、読み出しオブジェクトのアドレスの符号化（例えばハッシュシグネチャ）、または読み出しオブジェクトの識別子の符号化で十分であり得る。従って、より複雑な読み出しの再現性を検査するために述語ベースまたはクエリ句ベースのメタデータが生成される実施形態においてでも、いくつかのＲＲＶＭは位置ベースインジケータを含み得る。少なくとも一実施形態において、例えばＲＲＶＭが「単一位置ハッシュシグネチャ」であるか、「複雑クエリ符号化」であるか等、提供されるＲＲＶＭの種類を示すフィールドが、読み出し記述子内に含まれ得る。
【０１４８】
少なくともいくつかの実施形態において、データストアは、いくつかの異なる粒度でステート遷移に関する情報を格納し、そして複数のステート遷移インジケータが読み出し記述子に含まれ得る。図３３は、少なくともいくつかの実施形態による、読み出し記述子の例示的構成コンポーネントを示す。描かれた実施形態において、例示的データストア３３３０は、テーブル３３１０Ａ、３３１０Ｂ等、複数のテーブル３３１０を備える。各テーブルは多数のデータレコードを含み、各データレコードは、各自のレコード識別子すなわちＲＩＤ（レコードの位置インジケータとして機能し得る）３３１８と、レコードに対して適用された最新更新または書き込みを示す各自のレコード変更タイムスタンプ（ＲＭＴ）３３２０とを有する。従って、例えば、テーブル３３１０Ａは、ＲＩＤ３３１８Ａ、３３１８Ｂ、３３１８Ｃを有するレコードを含み、一方、テーブル３３１０Ｂは、ＲＩＤ３３１８Ｋ、３３１８Ｌ、３３１８Ｍを有するレコードを含む。各レコードは、図示されていない他のデータカラムまたは属性を含み得る。少なくともいくつかの実施形態において、ＲＭＴ３３２０は、論理タイムスタンプを表し（実時間ベースタイムスタンプの代わりに）、論理タイムスタンプは、例えば単調に増加するタイムスタンプ値を生成し、かつデータストアによりアクセス可能な論理クロックの出力値で表現される。描かれた実施形態において、レコードがテーブル３３１０に挿入されると、そのＲＭＴは挿入に対応する論理タイムスタンプ値に設定され得る。後で同一のレコードが更新されたとすると、当該ＲＭＴは、更新の論理タイムスタンプを示すように更新され得る。いくつかの実施形態において、論理クロックは、単調に増加する一連のタイムスタンプ値（実時間値に対応しないかもしれない）を提供する責務を担い得る。一実施態様において、格納グループごとに、単一の論理タイムスタンプ源が特定され得る（例えばグループのトランザクションマネジャーに対応付けられたクロック）。別の実施形態において、異なるデータストアが異なる論理クロックを使用し得る。
【０１４９】
描かれた実施形態において、レコードレベル変更時間情報に加えて、テーブルレベル変更時間情報も同様に、テーブル変更タイムスタンプ（ＴＭＴ）の形態で、例えばテーブル３３１０ＡのＴＭＴ３３１６Ａ、テーブル３３１０ＢのＴＭＴ３３１６Ｂ等で、保持され得る。描かれた実施形態において、テーブル３３１０のＴＭＴは、そのテーブルのレコードのＲＭＴの中で最新のＲＭＴを示し得る。従って、テーブル３３１０に関して、所定の時点でＲＩＤ３３１８Ｃを有するレコードがテーブル内で最新の書き込み対象レコードである場合、ＴＭＴ３３１６Ａも、ＲＭＴ３３２０Ｃと同じ論理タイムスタンプ値を含み得る。同様に、さらに高い粒度で、データストア変更タイムスタンプ（ＤＭＴ）３３０８が、データストア３３３０に格納されているレコードのうちのいずれかにおける最新の変更を示す、テーブルのＴＭＴの中で最新のＴＭＴ値に設定され得る。
【０１５０】
図３３に示される実施形態において、データストア３３１０内の所定のレコードに対する読み出しの読み出し記述子は、レコードレベル（例えば読み出されたレコードが最後に変更された時間を示す）、テーブルレベル、及びデータストアレベルの３つのレベルの階層全てに関する変更論理タイムスタンプを示し得る。示されるように、その結果集合がテーブル３３１０Ａのレコード３３１８Bを含む読み出し要求Ｒ１に応じて、生成された読み出し記述子ＲＤ１は、ＲＭＴ３３２０Ｂ、ＴＭＴ３３１６Ａ、及びＤＭＴ３３０８を含み得る（読み出し再現性検証メタデータ（ＲＲＶＭ）３３４０Ａに加えて）。同様に、その結果集合がテーブル３３１０Ｂのレコード３３１８Ｍを含む読み出し要求Ｒ２に応じて、読み出し記述子ＲＤ２は、ＲＭＴ３３２０Ｍ、ＴＭＴ３３１６Ｂ、ＤＭＴ３３０８、及び異なるＲＲＶＭ３３４０Ｂを含み得る。読み出しの結果集合がいくつかの異なるレコードを含む場合、いくつかの実施態様において、これらのレコードのＲＭＴのうち最小のＲＭＴが読み出し記述子に含まれ、一方、他の実施態様において、全てのレコードのＲＭＴが読み出し記述子に含まれ得る。同様に、所定の読み出し要求の結果が複数のテーブルからのレコードを含む場合、いくつかの実施形態において、テーブルのＴＭＴの中の最小ＴＭＴが読み出し記述子内に示され、一方、他の実施形態において、テーブルのＴＭＴ全てを含むベクトルが読み出し記述子に含まれ得る。異なる実施態様において、また異なる種類のデータストアに、ステート遷移レコードの他の階層が使用され得る。例えば、データストアテーブルがパーティションに分割される実施形態においては、パーティション変更タイムスタンプが読み出し記述子に含まれ得る（例えばＴＭＴに加えて、あるいはＴＭＴの代わりに）。いくつかの実施形態において、ファイルシステムを実施するデータストアには、ファイル、ディレクトリ、及びファイルシステムに対する書き込みの論理タイムスタンプが、ステート遷移インジケータの階層として使用され得る。いくつかの実施形態において、読み出し記述子にステート遷移インジケータの階層を含むことにより（ＤＭＴ等の単一値のみの代わりに）、ログベーストランザクションマネジャーは、異なるレベルの保守性にて並行処理制御決定を行うことが可能になり得る。例えば、一保守的手法において、トランザクションマネジャーは、ＤＭＴ以降にデータストアのレコードのうちのいずれかを対象とした全ての書き込みを競合書き込みとして特定し、一方、より保守性の低い手法においては、そのＲＭＴが競合とみなされ得る特定レコード（複数可）読み出しを対象とした書き込みのみを競合書き込みとして特定し得る。
【０１５１】
少なくともいくつかの実施形態において、図３２において示されるように、読み出し記述子が格納グループのデータストアにより、システムのクライアント側コンポーネントに対し提供され得る。いくつかのこのような実施形態において、読み出し記述子は、クライアント側コンポーネントにて生成されるトランザクションコミット要求内に組み込まれ、並行処理制御目的でトランザクションマネジャーにより調べられ得る。多数の理由から、読み出し記述子はトランザクションマネジャーにより解読可能でなければならないが、少なくともいくつかの実施形態において、ログサービスまたはプロバイダネットワークのオペレータは、読み出し記述子の内部詳細が、読み出し及び書き込み要求を提出するエンドユーザに対し可視状態であることを所望しないかもしれない。例えば、サービスオペレータは、読み出し記述子の形式またはコンテンツを変更する能力を保持することを所望し得る。しかしエンドユーザが固定サイズのエンドユーザ可読読み出し記述子を期待し慣れてしまった場合、そのような能力を保持することは難しくあり得る。従って、いくつかの実施形態において、読み出し記述子のコンテンツは、クライアント側コンポーネントに送信される前に、１つまたは複数の変換処理を施され得る。図３４は、少なくともいくつかの実施形態による、格納システムのクライアント側コンポーネントに読み出し記述子が提供される前に読み出し記述子に適用され得る例示的変換を示す。３つのレベルの格納階層のそれぞれの変更論理タイムスタンプ（データストア、テーブル、及びレコード）が、描かれた実施形態において生成される読み出し記述子に含まれる。示されるように、非修正または変換前状態の読み出し記述子３４０１は、元のＤＭＴ３４０８に使用されるＮ１バイトと、元のＴＭＴ３４１６に使用されるＮ２バイトと、元のＲＭＴ３４２０に使用されるＮ３バイトと、ＲＲＶＭ３４４０に使用されるＮ４バイトとを含む、Ｎ１＋Ｎ２＋Ｎ３＋Ｎ４バイトを有し得る。
【０１５２】
描かれた実施形態において、第１変換で、複数（Ｎ５）のバイトが、読み出し記述子に「パディング」として追加され得る。いくつかの実施形態において、例えば乱数ジェネレータを使用してパディングサイズのある選択された範囲内からパディングバイトの数を選択することで、異なる数のバイトが同じデータストアにて生成された異なる読み出し記述子に追加され得る。いくつかの実施形態において、パディングバイトには、ランダムに選択されたデータも投入され得る。このようなランダムに生成されたパディング要素のおかげで、エンドユーザは、全ての読み出し記述子が同一サイズであると想定しないようになり得る。
【０１５３】
いくつかの実施形態において、パディング変換に加えて、読み出し記述子が同様または代わりに、符号化または難読化され、そのため読み出し記述子の構成要素は、復号化なしでは解釈または理解不可能となる。従って、例えば、パディングされた読み出し記述子３４５１は、クライアント側コンポーネントに送信される前に、難読化読み出し記述子３４５８に暗号化または符号化され得る。描かれた実施形態において、格納サービスのサーバ側コンポーネント（読み出し記述子が復号化される必要があり得るトランザクションマネジャー等）は、必要なメタデータ（例えば復号化認証情報、または読み出し記述子の復号化に使用する機能または方法の指示）を有し得るが、難読化を取り消すために必要な情報は、エンドユーザによりアクセス可能ではあり得ない。様々な実施形態において、異なる２つの一連変換（パディング及び難読化）が行われ得る。例えば読み出し記述子の構成要素の原版は、いくつかの実施形態において、パディングバイトが追加される前に、まず符号化され得る。いくつかの実施形態において、パディングのみ、または難読化のみが使用され得る。少なくともいくつかの実施形態において、読み出し記述子はクライアント側コンポーネントに送信される前に、他の変換が同様に適用され得る。例えば記述子は圧縮され得る。
【０１５４】
ステートレスデータストア独立トランザクション
図３５は、少なくともいくつかの実施形態による、格納システムのクライアント側コンポーネントから候補トランザクションコミット要求の提出を引き起こす例示的一連動作を示す。クライアント側コンポーネントは、例えば、格納サービスのフロントエンド要求ハンドラで実行されるプロセス、またはクライアント所有コンピューティングデバイスにてインストール可能な格納サービスプロバイダライブラリのコンポーネントを備え得る。クライアント側コンポーネントタイムライン３５９９上の時間ｔ１に、ＢＥＧＩＮ＿ＴＲＡＮＳＡＣＴＩＯＮ要求が、例えばエンドユーザから、クライアント側コンポーネントにて受信され得る。クライアント側コンポーネントは、いくつかの実施形態において、ＢＥＧＩＮ＿ＴＲＡＮＳＡＣＴＩＯＮ要求に応じて、候補トランザクション要求を準備するために、メモリバッファ３５３５を割り当て得る、または確保し得る。別の実施形態において、メモリバッファ３５３５は、トランザクションの異なる読み出し及び／または書き込みが完了すると、動的に割り当てられ得る。
【０１５５】
タイムライン３５９９上の時間ｔ２に、読み出し要求Ｒ１が、クライアント側コンポーネントから（例えばサービスのフロントエンド要求ハンドラまたはライブラリコンポーネントにて受信されたエンドユーザ読み出し要求に応じて）、ステートレスプロトコルを介して異種格納グループ３５７５のデータストアＤＳ１に対し送られ得る。描かれた実施形態において、異種格納グループ３５７５は、メンバーデータストアＤＳ１、ＤＳ２、ＤＳ３、ＤＳ４を含み、それぞれは、書き込み動作がログベーストランザクションマネジャー（ＬＴＭ）を介して管理される格納グループのメンバーとして登録済みであり得る。格納グループ３５７５のメンバーはまた、読み出し要求に応じて、読み出し記述子（例えば前述の類のステート遷移インジケータ及びＲＲＶＭを含む記述子）を生成及び送信するように求められ得る。格納グループの少なくともいくつかのメンバーは、いくつかの実施形態において、異なるデータモデル（例えばリレーショナルあるいは非リレーショナルデータベース、構造化あるいは非構造化レコード）を、対応読み出しインターフェース及びレコード／オブジェクト格納形式で実施し得る。前述のように、例えば、リレーショナルデータベース、非リレーショナルデータベース、インメモリデータベース、分散キャッシュ、プロバイダネットワークサービスにより実施されるウェブサービスインターフェースを介してアクセス可能な格納オブジェクト集合、プロバイダネットワークにて実施される待ち行列サービス、またはプロバイダネットワークにて実施される通知サービスのインスタンスを含む、多数の異なるカテゴリのデータストアが格納グループに含まれ得る。描かれた実施形態において、読み出し要求Ｒ１に対応する結果集合３５１０Ａ及び読み出し記述子３５１２Ａがクライアント側コンポーネントに送信された後、ＤＳ１はクライアント側コンポーネントに関するいかなるセッションメタデータも保持し得ないという点で、読み出し要求Ｒ１に使用されるプロトコルは、ステートレスであり得る。異なる実施形態において、読み出し要求及び応答には、例えばＲＥＳＴ（具象的ステート転送）アーキテクチャに従う様々なＨＴＴＰ（ハイパーテキスト転送プロトコル）変体のうちのいずれか等、様々なステートレスアプリケーション層プロトコルのうちのいずれかが使用され得る。結果集合３５１０Ａ及び読み出し記述子３５１２Ａは、メモリバッファ３５３５に格納され得る。
【０１５６】
タイムライン３５９９上の時間ｔ３に、トランザクションの範囲内の第２読み出し要求Ｒ２が、例えばエンドユーザの別の読み出し要求に応じて、ステートレスプロトコルを介して格納グループ３５７５の第２データストアＤＳ２に対し提出され得る。前と同じように、結果集合３５１０Ｂ及び読み出し記述子３５１２Ｂをクライアント側コンポーネントに提供後、データストアＤＳ２は、Ｒ２またはクライアント側コンポーネントに関するいかなるセッションステートメタデータも保持し得ない。描かれた実施形態において、格納グループ３５７５のメンバーデータストアのいずれも、クライアント側コンポーネントにてトランザクションが始まったという事実を認識しておらず、データストアにとって、各読み出し要求は単純に、他のいかなる読み出しまたは書き込みにも無関係な独立要求として映り得る。
【０１５７】
時間ｔ４に、ペイロード３５２０ＡがＲ２の結果集合に依存し、最終的にデータストアＤＳ３に適用される（準備されている候補トランザクションが最終的にコミットされた場合に）書き込みＷ１は、ローカルに、例えば描かれた実施形態においてクライアント側バッファ３５３５内のメモリの一部に対し、実行され得る。Ｗ１が対象とする目標アドレスを示すＷ１の書き込み記述子３５２２Ａも、バッファ内で作成され得る。例えば、いくつかの実施態様において、目標アドレスのハッシュシグネチャが、書き込み記述子３５２２Ａとして使用され得る。時間ｔ５に、ペイロード３５２０ＢがＲ１の結果集合に依存し、ＤＳ４を対象とする書き込みＷ２は、同様にクライアント側コンポーネントのローカルメモリ内で実行され得る。描かれた実施形態において、Ｗ２の第２書き込み記述子３５２２Ｂもまた、クライアント側コンポーネントのメモリバッファ３５３５内で準備され得る。
【０１５８】
時間ｔ６に、ＣＯＭＭＩＴ＿ＴＲＡＮＳＡＣＴＩＯＮ要求が、エンドユーザから受信され得る。従って、読み出し記述子３５１２Ａ、３５１２Ｂ、書き込み記述子３５２２Ａ、３５２２Ｂ、及び書き込みペイロード３５２０Ａ、３５２０Ｂは全て、格納グループ３５７５のＬＴＭに提出する候補トランザクションコミット要求３５２４内に包括され得る。ＬＴＭの競合検出器３５６６は、読み出し記述子と、ＬＴＭのコミットレコードログの選択部分集合のコンテンツとの分析に基づいて（部分集合は読み出し記述子に少なくとも部分的に基づいて選択される）、候補トランザクションを受諾するか拒否するかを判定し得る。後続の書き込みが結果集合を変更し、読み出し要求が再提出されたら変更された結果集合が返されるため、Ｒ１またはＲ２は再現不可能であるという読み出し書き込み競合が検出された場合（例えば読み出し記述子のうちの１つに含まれるＲＲＶＭを使用した判定の結果）、候補トランザクションは拒否され得る。このようなシナリオで、クライアント側コンポーネントは、描かれた実施形態において、読み出しＲ１、Ｒ２を再試行して新たな結果集合と読み出し記述子とを取得し、ＬＴＭに提出する新たな候補トランザクションコミット要求を生成し得る。このような再試行は、試みのうちの１つが成功するまで、または要求中のトランザクションを有するエンドユーザにトランザクションが失敗したと通知されるまで、ある閾値回数実行され得る。
【０１５９】
描かれた実施形態において、競合検出器３５６６がコミット要求３５２４を受諾する場合、Ｗ１及びＷ２の書き込み記述子及びペイロードは、ＬＴＭのログに格納され得る。少なくともいくつかの実施形態において、競合を検出するために、前に格納された書き込み記述子により示される書き込みは、読み出し記述子により示される読み出しとの潜在的または実際の重複を検査される必要があり得る点で、書き込み記述子は、コミット要求に含まれる読み出し記述子の論理的「双対」とみなされ得る。従って、所定の実施態様において書き込みが書き込み記述子内に示される方法は、読み出しが読み出し記述子内に示される方法と、高いレベルで、論理的に適合する必要があり得る。ＬＴＭの書き込みアプライヤ３５６８は、受諾決定に関して同期的または非同期的に、書き込みＷ１、Ｗ２をその対象データストアＤＳ３、ＤＳ４に適用し得る。いくつかの実施形態において、書き込みアプライヤもステートレスプロトコルを使用し、対象データストアＤＳ３、ＤＳ４は、書き込みアプライヤ、または書き込みアプライヤにより発行される書き込み要求に関するいかなるセッション関連メタデータも格納する必要はなくてよい。
【０１６０】
従って、図３５に示される実施形態において、複数の書き込み（Ｗ１、Ｗ２等）は、いかなるトランザクション関連メタデータが関与データストアにて生成または格納されることなく、クライアント側コンポーネントにて準備される原子トランザクションの一環としてコミットされ得る。基礎データストアは複数書き込みトランザクションにネイティブに対応し得ないにもかかわらず、及び／または基礎データストアはステートレス読み出し及び書き込み動作にのみ対応し得るにもかかわらず、いくつかの実施形態において、このようなクライアント側複数書き込みトランザクションが実施され得る。すなわち、メンバーデータストアは所定の読み出しの発生時間から所定の読み出しの結果に依存する書き込みの発生時間までセッション情報（またはトランザクションステート情報）を保持しないにもかかわらず、トランザクション原子性及び整合性が異種格納グループのユーザに提供され得る。
【０１６１】
前述のように、ログベーストランザクションマネジャーは、コミット済み書き込みに対応する書き込み記述子（３５２２Ａ、３５２２Ｂ等）を持続的変更ログ（前述の複製ＤＡＧを使用して実施されるログ等）に格納し得る。いくつかの実施形態において、コミット済みトランザクションの読み出し記述子は先のコミット判定に不要であり得るにもかかわらず、読み出し記述子のコンテンツもトランザクションマネジャーにより保存され得る。図３６は、少なくともいくつかの実施形態による、書き込み記述子と読み出し記述子とをそれぞれのログに格納する例示的トランザクションマネジャーを示す。示されるように、ログベーストランザクションマネジャー３６０２は、書き込み記述子ログ３６１０と、読み出し記述子ログ３６２０との２つの別個の持続的ログを使用する。別の実施形態において、両種類の記述子は、共有持続的ログに格納され得る。読み出し記述子ログ３６１０のコンテンツは、前述の楽観的並行処理制御手法の一環として読み出し書き込み競合に関して、及び／または同様に前述の論理制約管理に関して、検査を行うために使用され得る。読み出し記述子ログ３６２０は、例えば異種格納グループの異なる部分にわたる読み出しの分散を決定するために、例えば作業負荷分析に使用され得る。いくつかの実施形態において、コミット済み及び拒否済みトランザクション両方の読み出し記述子は、作業負荷分析の目的で保持され得る。拒否済みトランザクションの読み出し記述子も、トランザクション拒否の原因を特定するために分析され、例えばトランザクション拒否の頻度を低減するために任意の行動が取られるべきか否か（多数のトランザクション拒否を生じるほど頻繁に読まれ頻繁に更新される特定のデータオブジェクトをパーティション分割する等）が判定され得る。
【０１６２】
図３７は、少なくともいくつかの実施形態による、読み出し要求に応じて読み出し記述子が提供される、格納システムで行われ得る動作態様を示すフロー図である。構成要素３７０１に示されるように、複数のデータストアを備える異種格納グループＨＳＧ１が確立され得る。グループのメンバーデータストアは、異なるデータモデル及び／または読み出しインターフェースに対応し得る。例えばグループは、リレーショナルデータベース、非リレーショナルデータベース、インメモリデータベース、分散キャッシュインスタンス、ファイルストアもしくはファイルシステム、ウェブサービスインターフェースを介してアクセス可能な非構造化データオブジェクトを含む格納サービス等の１つまたは複数のインスタンスを含み得る。ＨＳＧ１を実施するサービスのクライアントは、グループにデータストアを登録（追加）し得る、またはグループからデータストアをプログラムで削除し得る。少なくともいくつかの実施形態において、グループＨＳＧ１の全てのメンバーデータストアは、読み出し要求に対し、（読み出し結果集合に加えて）サービスにより指示される共通読み出し記述子形式に従った読み出し記述子で、応答するように求められ得る。
【０１６３】
ＨＳＧ１のデータストアＤＳ１を対象とする特定読み出し要求Ｒ１が受信され得る（構成要素３７０４）。Ｒ１は、その結果集合を決定するのに使用するフィルタ基準の指示を含み得る。フィルタ基準の特質は、対象とするデータストアの種類によって異なり得る。例えば、Ｒ１がＳＱＬ（構造化照会言語）またはＳＱＬ似のインターフェースに対応するデータベースである場合、フィルタ基準は、ＳＱＬのＳＥＬＥＣＴ句として表現され得る。ＤＳ１がウェブサービスインターフェースを提供する格納サービスである場合、フィルタ基準は、１つまたは複数のＵＲＬ（ユニバーサルリソースロケータ）として表現され得る。キー値データストアでは、フィルタ基準は、データストア内の特定レコード位置／アドレスに順に対応する一意キーの集合を含み得る。読み出し要求の結果集合が、データストアＤＳ１の前にコミット済みのステートを表すＤＳ１の１つまたは複数のステート遷移インジケータ（ＳＴＩ）と共に、特定され得る（構成要素３７０７）。結果集合が生成された時にコミット済み書き込みの結果が可視状態であるように、いくつかの実施形態において、ＳＴＩは、データストアに対するコミット済み書き込みの適用に対応する論理タイムスタンプを含み得る。一実施態様において、例えば、ＳＴＩは、データストアレベル変更論理タイムスタンプ、テーブルレベル変更論理タイムスタンプ、またはレコードレベル変更論理タイムスタンプ（例えば図３３に例示されるＤＭＴ、ＴＭＴ、及びＲＭＴ）、以上のうちの１つまたは複数含み得る。いくつかの実施形態において、論理タイムスタンプの代わりに、または論理タイムスタンプに加えて、実時間ベースタイムスタンプが使用され得る。
【０１６４】
Ｒ１に対応する読み出し記述子ＲＤ１が生成され得る（構成要素３７１０）。読み出し記述子は、例えば、ＳＴＩ（複数可）と、少なくともいくつかの読み出し再現性検証メタデータ（ＲＲＶＭ）を含み得る。ＲＲＶＭは、例えば、Ｒ１が再現可能な読み出しか否か、すなわち、最初に結果集合が取得された後のある時点でＲ１が再発行されたとしても、Ｒ１の結果集合は変化のないままであるか否かを判定するのに使用され得る。ＲＲＶＭの形式及びコンテンツは、異なる実施形態において、例えば再現性を判定する読み出しの種類、関与するデータストアの特質等に基づいて異なり得る。いくつかの実施形態において、例えば、ＲＲＶＭは、Ｒ１結果集合のオブジェクトが取得された取得先位置の符号化、例えば少なくとも１つのそのような位置のハッシュシグネチャ等を含み得る。範囲クエリ、または図３１に関連して議論された読み出しに類似するクエリ等、より複雑なフィルタ／選択基準を有する読み出しに関しては、クエリ述語またはＳＥＬＥＣＴ句の符号化がＲＲＶＭに含まれ得る。そしていくつかの実施形態において、Ｒ１の結果が変化したか否かを判定するために調査可能な式（または実行可能な関数）が、ＲＲＶＭ内に示され得る。一実施態様において、読み出し要求Ｒ１全体は、例えば符号化または圧縮された形式で、ＲＲＶＭに含まれ得る。いくつかの異なる種類のＲＲＶＭが生成され得る（例えばアドレスベースシグネチャ、あるいはクエリ述語符号化、あるいは関数）いくつかの実施形態において、ＲＲＶＭの種類は、読み出し記述子ＲＤ１内のフィールドにより示され得る。ＲＤ１は、ＨＳＧ１のクライアント側コンポーネント（例えばＨＳＧ１が実施されるサービスのフロントエンド要求ハンドラノード、またはサービスのライブラリコンポーネント）に送信され得る。ＲＤ１は、いくつかの実施形態においてトランザクションコミット要求を構成するために、または作業負荷分析等の他の目的で、クライアント側コンポーネントにて使用され得る。
【０１６５】
図３８は、少なくともいくつかの実施形態による、候補トランザクションコミット要求がクライアント側コンポーネントにて生成される、格納サービスで行われ得る動作態様を示すフロー図である。クライアント側コンポーネントには、例えば、格納サービスのフロントエンド要求ハンドラノードにて、または格納サービスにより顧客へ提供されるライブラリ内で、実行される１つまたは複数のプロセスが含まれ得る。構成要素３８０１に示されるように、候補トランザクションを準備するという指示、例えばサービスのアプリケーションプログラミングインターフェース（ＡＰＩ）を介して受信されるＢＥＧＩＮ＿ＴＲＡＮＳＡＣＴＩＯＮ要求等が、エンドユーザから異種格納グループＨＳＧ１のクライアント側コンポーネントにて受信され得る。いくつかの実施態様において、ＢＥＧＩＮ＿ＴＲＡＮＳＡＣＴＩＯＮ要求からＣＯＭＭＩＴ＿ＴＲＡＮＳＡＣＴＩＯＮ要求（またはＥＮＤ＿ＴＲＡＮＳＡＣＴＩＯＮ要求）までの間にクライアント側コンポーネントにて行われる動作集合は、例えば当該間隔内に発行された読み出しの再現性は、トランザクションの書き込みがコミットされる前に検証される必要があり得るという意味で、トランザクションの範囲内であるとみなされ得る。
【０１６６】
１つまたは複数の読み出し要求が、例えばエンドユーザによる読み出しＡＰＩ呼び出しに応じて、クライアント側コンポーネントにより、トランザクションの範囲内で、格納グループＨＳＧ１のデータストアに送られ得る。読み出しのうちの少なくともいくつかは、描かれた実施形態においてステートレスプロトコルを使用して実行され得る。すなわち、読み出しが対象とするデータストアは、クライアントセッション情報を維持する、または読み出し要求に関するその他の持続的メタデータを保持する必要はなくてよい。例えば、データストアは、読み出しの結果が書き込み動作またはトランザクションに使用される予定であることを示す情報を有し得ない。このような読み出し要求それぞれに応じて、対象データストアにより、読み出し集合と読み出し記述子とが提供され得る（構成要素３８０４）。所定の読み出し記述子は、読み出し集合が取得された時点でのデータストアのコミット済みステート（またはデータベースインスタンスの場合はテーブルもしくはレコードといったデータストアの部分集合のコミット済みステート）を示す１つまたは複数のステート遷移インジケータ（ＳＴＩ）を含み得る。さらに、読み出し記述子は、読み出し再現性検証メタデータ（ＲＲＶＭ）の少なくとも１つの要素、例えば、読み出しが再提出されたら読み出しの結果は変わるか否かを検査するのに使用可能な読み出しクエリもしくは述語の符号化等の情報、関数、または読み出し対象位置を表すハッシュシグネチャも含み得る。読み出し結果集合及び読み出し記述子は、クライアント側コンポーネントによりアクセス可能なメモリバッファに、例えばフロントエンド要求ハンドラノードにおける、またはクライアント所有コンピューティングデバイスにおけるローカルメモリに、格納され得る（構成要素３８０７）。
【０１６７】
書き込みペイロードが読み出し結果集合のうちの少なくとも１つに依存し得る１つまたは複数の書き込みは、ローカルメモリを使用して実行され得る。例えば書き込みペイロードは、クライアント側コンポーネントにより書き込み可能なバッファに格納され得る。少なくとも一実施形態において、トランザクションの範囲内の書き込みの結果として最終的に書き込まれるＨＳＧ１のデータストアにおける対象位置もまた、読み出し結果集合に依存し得る。いくつかの実施形態において、書き込み記述子（例えば書き込みの対象ＨＳＧ１位置に基づくハッシュシグネチャ）も、書き込みのうちの少なくともいくつかのために、クライアント側メモリバッファに格納され得る（構成要素３８１０）。いくつかの実施形態において、書き込み記述子は必要でなくてよいことに留意されたい。例えば、書き込みペイロードが書き込み位置の指示を含み、そして読み出し書き込み競合検出を行うには、当該位置で十分であり得る。トランザクションの全ての読み出し及び書き込みがローカルで実行された後、トランザクションのローカル動作が完了したことの開示（ＣＯＭＭＩＴ＿ＴＲＡＮＳＡＣＴＩＯＮまたはＥＮＤ＿ＴＲＡＮＳＡＣＴＩＯＮ要求等）が、クライアント側コンポーネントにて受信され得る。（構成要素３８１３）
【０１６８】
描かれた実施形態において、読み出し記述子と、書き込みペイロードと、書き込み記述子とを含む候補トランザクションのコミット要求が、クライアント側コンポーネントにて生成され得る（構成要素３８１６）。いくつかの実施形態において、トランザクションの範囲内に含まれる１つまたは複数の書き込みは、必ずしもトランザクション内に指示される読み出しの結果に依存するとは限らないことに留意されたい。例えば候補トランザクションがコミットのために受諾される前に前述の類の論理制約（例えば重複排除制約またはコミット順序付け制約）が検査されるいくつかの実施形態において、論理制約のために追加データシグネチャが生成され、コミット要求内に組み込まれ得る。ＨＳＧ１のためにコミット判定を行う責務を担うトランザクションマネジャー、例えば前述の類の楽観的並行処理制御機構を使用するように構成されたログベーストランザクションマネジャー等に対し、コミット要求は送信され得る（構成要素３８１９）。候補トランザクションをコミットするか拒否するかに関する判定は、前述のように例えば読み出し書き込み競合を特定するための読み出し記述子と選択されたログの部分集合とを使用して、トランザクションマネジャーにて行われ得る（構成要素３８２２）。候補トランザクションを受諾するという決定がなされた場合（例えば使用されている並行処理制御プロトコルに従って読み出し書き込み競合が検出されない場合）、新たなコミットレコードがトランザクションマネジャーのログに追加され得る。少なくともいくつかの実施形態において、ログは、前述のように複製有向非巡回グラフ（ＤＡＧ）を使用して実施され得る。
【０１６９】
拡張縮小性のための複数ログベーストランザクションマネジャーの使用
いくつかの実施形態において、単一のログベーストランザクションマネジャー（ＬＴＭ）は、前述の類の１つまたは複数のデータストアを含む格納グループにトランザクションが要求されるレートに、対応不可能であり得る。例えば、少なくともいくつかの実施態様において、要求コミットまたはトランザクションのレートが増加すると、コミットレコードを持続的ログに挿入するのに利用可能なＣＰＵリソース（例えば持続的ログに使用される複製ＤＡＧの所定のノードが実施されるホストにおける）が障壁となり得る。いくつかの事例において、ＣＰＵに加えて、またはＣＰＵの代わりに、ログレコードに使用される格納デバイス、及び／またはログへのネットワーク経路もしくはログからのネットワーク経路が、障壁となり得る。いずれかの単一のこのような障壁、またはこのような障壁の組み合わせは、結果的に所定のＬＴＭにより対応可能なトランザクションスループットを抑制し得る。所定のＬＴＭによる増大スループットに対応するためにより速い個別サーバ、より速い格納デバイス、またはより速いネットワークコンポーネントを配備することは、例えば費用の理由から、可用性の理由から、及び／または単純に最も速く利用可能なコンポーネントでもいくつかの作業負荷を処理不可能であり得るため、最終的には非実用的となり得る。
【０１７０】
従って、少なくともいくつかの実施形態において、楽観的ログベース並行処理制御が使用される格納グループの１つまたは複数のデータストアのデータは、論理的にパーティションに分割され、パーティションレベルの競合検出のために、異なるパーティションにそれぞれのＬＴＭが割り当てられる。例えば、テーブルＴ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５の集合を有するデータベースの場合、１つのＬＴＭがＴ１、Ｔ２、Ｔ３を有するパーティションに割り当てられ、別のＬＴＭがＴ４、Ｔ５を有するパーティションに割り当てられ得る。このようなＬＴＭは各自、１つの特定パーティションのコミットレコードが格納される自身の持続的ログに関して、ローカル競合検出を実行可能であり得る。読み出し及び書き込みが全て単一パーティションを対象とするトランザクションのコミット判定は、単一ＬＴＭにより前述と同様の方法で対処され得る。しかしながら、いくつかのトランザクションは、複数のパーティションからの読み出し（及び／または複数のパーティションへの書き込み）を伴い得る。このようなトランザクションは、本明細書において複数パーティショントランザクションと称され得る。複数パーティショントランザクションに対応する実施形態において、クライアント側コンポーネント（ログベーストランザクション管理が実施されている格納サービスのフロントエンド要求ハンドラにおけるプロセス、またはクライアント所有デバイスにインストールするためにそのようなサービスにより提供されるライブラリのコンポーネント等）は、関与するパーティションのローカル競合を検出するように割り当てられたそれぞれのＬＴＭと一緒に、後述のように複数パーティショントランザクションのコミットに参加する必要があり得る。
【０１７１】
（ａ）格納グループのパーティションＰ１を対象とし、かつＰ１に対する前の読み出しＲ１の結果に依存する書き込みＷ１、及び（ｂ）パーティションＰ２を対象とし、かつＰ２に対する前の読み出しＲ２の結果に依存する書き込みＷ２、以上を含む単純な例示的複数パーティショントランザクションＭＰＴ１を検討する。当実施例において、ログベーストランザクションマネジャーＬＴＭ１、ＬＴＭ２はそれぞれ、Ｐ１、Ｐ２に関する読み出し書き込み競合を検出するように指示される。一実施形態において、コミット要求ＣＲ１（Ｗ１の書き込み記述子とＲ１の読み出し記述子ＲＤ１とを含む）は、クライアント側コンポーネントＣＳＣ１によりＬＴＭ１に対し送信され得る。少なくともいくつかの実施形態において、読み出し記述子ＲＤ１は、例えば図３２〜図３８に関して前述された読み出し再現性検証メタデータ及びステート遷移インジケータの類を含み得る。ＲＤ１とコミット済み書き込みのＬＴＭ１のログとを使用して、ＬＴＭ１は、ＣＲ１がローカルで検出可能な競合、すなわちＬＴＭ１にて入手可能な情報を使用して特定可能な競合を有するか否かを判定し得る。ＬＴＭ１のログとＲＤ１とを使用してＬＴＭ１により競合が見つからなかった場合、ＬＴＭ１は、ＣＲ１を条件付きでコミット可能であると指定し、条件付きコミットレコードをＬＴＭ１のログに挿入し得る。Ｗ１が条件付きでコミット可能であると指定されたことが、クライアント側コンポーネントＣＳＣ１に通知され得る。ＭＰＴ１の第２書き込みＷ２に関して、ＣＳＣ１は同様に、第２コミット要求ＣＲ２をＬＴＭ２へ送信し得る。Ｗ２もローカルでコミット可能であること（例えばＷ２に対し条件付きコミットレコードがＬＴＭ２のログに格納されたこと）がＬＴＭ２によりＣＳＣ１に通知された場合、ＣＳＣ１は、ＭＰＴ１が全体的に、すなわち無条件でコミット可能であると判定し得る。ＣＳＣ１はそれから、ＭＰＴＲ１の無条件コミットレコードを、複数パーティションコミット判定レポジトリ（ＭＣＤＲ）に、例えばＣＲ１、ＣＲ２に対応する条件付きコミットレコード内のポインタが格納された位置に、挿入し得る。コミット済み書き込みをＰ１に伝播するように割り当てられた書き込みアプライヤＷＡ１は、Ｗ１は条件付きでコミット可能であると判定されたことを示す、ＣＲ１に応じて生成されたコミットレコードを調べ得る。ＷＡ１は、Ｗ１が条件付きでコミットされたと判定すると、対応する無条件コミットレコードをＭＣＤＲ内で検索し得る。いくつかの実施形態において、このような無条件コミットレコードが見つかった場合（例えば後述のようなタイムアウト内に）、Ｗ１はＰ１に伝播され得る。同様に、Ｐ２に対し書き込みを伝播するように指示された書き込みアプライヤ（ＷＡ１または別の書き込みアプライヤＷＡ２）は、ＣＲ２及びＷ２に対応する条件付きコミットレコードを調べ、ＭＰＴ１の無条件コミットレコードを探し、Ｐ２に対しＷ２を伝播し得る。書き込みアプライヤ（複数可）により無条件コミットレコードが見つからない場合、少なくともいくつかの実施形態において、書き込みは破棄され得る（例えばＷ１、Ｗ２のどちらもそれぞれの目的パーティションに伝播され得ない）。
【０１７２】
図３９は、少なくともいくつかの実施形態による、格納グループの異なるパーティションに対しそれぞれのログベーストランザクションマネジャー（ＬＴＭ）が確立され得る例示的システム環境を示す。示されるように、システム３９００において、パーティション分割された格納グループ３９０２は、３つの論理パーティション（ＬＰ）のＬＰ３９１０Ａ、３９１０Ｂ、３８１９Ｃを備え得る。一般に、前述の類の１つまたは複数のデータストア（例えば、リレーショナルデータベースインスタンス、非リレーショナルデータベースインスタンス、格納サービスオブジェクト、インメモリデータベースインスタンス、分散キャッシュインスタンス、ファイルシステム等）を備える格納グループは、後述のように、格納グループの目標性能要件等の様々な要素に応じて、様々な実施形態において任意の所望数のパーティションに論理的に細分化され得る。いくつかの実施形態において、論理パーティションは、それぞれの物理格納デバイスにも格納され得る。このような論理パーティションの物理的分離は要件ではあり得ないが、例えば、パーティションＰ１内のテーブルＴ１はディスクＤ１上に格納され、パーティションＰ２内のテーブルＴ２は別のディスクＤ２上に格納され得る等する。各論理パーティションは、対応ＬＴＭと、描かれた実施例において構成される対応書き込みアプライヤ（ＷＡ）とを有するが、ＬＴＭとＷＡ間のこのような１対１のマッピングは、少なくともいくつかの実施形態において必要でなくてよい。システム３９００において、ＬＰ３９１０Ａは持続的ログ３９１８Ａを含むＬＴＭ３９１５Ａを有し、ＬＰ３９１０Ｂは持続的ログ３９１８Ｂを含むＬＴＭ３９１５Ｂを有し、ＬＰ３９１０Ｃは持続的ログ３９１８Ｃを含むＬＴＭ３９１５Ｃを有する。いくつかの実施形態において、持続的ログ３９１８はそれぞれ、前述の複製ＤＡＧと同様の複製ＤＡＧを使用して実施され得る。ＷＡ３９２０Ａは、ログ３９１８Ａ内のコミットレコードを調べ、そこに指示される書き込みのうちの少なくともいくつかをＬＰ３９１０Ａに伝播するように構成され、同様に、ＷＡ３９２０Ｂは、ログ３９１８Ｂのコミットレコードを調べ、少なくともいくつかの書き込みをＬＰ３９１０Ｂに伝播するように構成され、そしてＷＡ３９２０Ｃは、ログ３９１８Ｃのコミットレコードを調べ、少なくともいくつかの書き込みをＬＰ３９１０Ｃに伝播するように構成される。
【０１７３】
矢印１ａ、１ｂで示されるように、格納グループ３９０２のクライアント側コンポーネント３９３０は、複数パーティショントランザクションＭＰＴ１のそれぞれのコミット要求Ｃ‐Ｒｅｑ１、Ｃ‐Ｒｅｑ２を、ＬＴＭ３９１５Ａ、ＬＴＭ３９１５Ｃに対しそれぞれ提出し得る。Ｃ‐Ｒｅｑ１は、ＬＰ３９１０Ａを対象とする前の読み出しＲ１に依存する少なくとも１つの書き込みＷ１を含み、一方、Ｃ‐Ｒｅｑ２は、ＬＰ３９１０Ｃを対象とする前の読み出しＲ２に依存する少なくとも１つの書き込みＷ２を含み得る。（ａ）コミット要求に含まれる読み出し記述子と（ｂ）ログ３９１８Ａ、３９１８Ｃとを使用して、ＬＴＭ３９１５Ａ、３９１５Ｃは、書き込みＷ１、Ｗ２が条件付きでコミット可能であるか否か（例えばそれぞれのローカルログとそれぞれの読み出し記述子とを使用して、書き込みとのいずれかの読み出し書き込み競合が検出され得るか否か）をそれぞれ判定し得る。描かれた実施形態において、複数パーティショントランザクションのＷ１またはＷ２等の書き込みは、所定のＬＴＭにより条件付きで（無条件ではなく）コミット可能であるとみなされ得る。なぜなら、ＬＴＭは、複数パーティショントランザクション全体としてのコミットに関して判定を行うのに十分な情報を有さなくてよいからである。実際に、少なくともいくつかの実施態様において、ＬＴＭは、複数パーティショントランザクションの他の書き込みを認識すらしなくてよい。ローカルで入手可能な情報を使用して競合が全く検出されない場合、例えば、Ｃ‐Ｒｅｑ１に対応する条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ１がＬＴＭ３９１０Ａによりログ３９１８Ｂに格納され、Ｃ‐Ｒｅｑ２に対応する条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ２がＬＴＭ３９１０Ｃによりログ３９１８Ｃに格納され得る。さらに、少なくともいくつかの実施形態において、要求書き込みが条件付きでコミットされたことを示すそれぞれの応答が、それぞれのＬＴＭ３９１５Ａ、３９１５Ｂにより、クライアント側コンポーネント３９３０に提供され得る。従って、矢印２ａで示されるように、応答Ｃ‐Ｒｅｓｐ１がＬＴＭ３９１５Ａによりクライアント側コンポーネント３９３０に提供され、そして矢印２ｂで示されるように、応答Ｃ‐Ｒｅｓｐ１がＬＴＭ３９１５Ｂにより提供され得る。コミット要求Ｃ‐Ｒｅｓｐ１、Ｃ‐Ｒｅｓｐ２は、少なくともいくつかの実施態様において並行して送信され、同様にコミット要求の処理もまた並行して行われ得ることに留意されたい。少なくともいくつかの実施形態において、複数パーティショントランザクションの異なるコミット要求は任意の順序でまたは並行して送信され、対応する条件付きコミットレコードはそれぞれのＬＴＭにより任意の順序でまたは並行して格納され、そしてコミット要求に対する応答はクライアント側コンポーネントにより任意の順序でまたは並行して受信され得る。
【０１７４】
描かれた実施形態において、書き込みＷ１、Ｗ２は両方とも条件付きでコミット可能であるという確認に応じて、クライアント側コンポーネント３９３０は、無条件コミットレコードＵｎｃｏｎｄ‐Ｃ‐Ｒｅｃを、複数パーティションコミット判定レポジトリ（ＭＣＤＲ）３９４０Ａに格納し得る（矢印３）。少なくともいくつかの実施形態において、クライアント側コンポーネントは通常、ＭＰＴ１等の所定の複数パーティショントランザクションの全ての書き込みが条件付きでコミット可能であると指定されたことを確認後、このような無条件コミットレコードを格納し得る。描かれた実施例において、２つのＭＣＤＲ３９４０Ａ、３９４０Ｂが、格納グループ３９０２に対し確立されている。後述のように例えば複数パーティショントランザクション要求の見込みまたは目標スループットに基づいて、一般に様々な実施形態において任意の所望数のＭＣＤＲが確立され得る。複数のＭＣＤＲが確立された実施形態において、所定の無条件コミットレコードにどのＭＣＤＲを使用するかに関する決定が、例えばトランザクションに関与する特定のパーティションに基づいて、クライアント側コンポーネントにより実施される負荷分散基準に基づいて等、様々な要素に基づいて行われ得る。少なくともいくつかの実施形態において、無条件コミットレコードを格納する位置の開示が、クライアント側コンポーネントによりＬＴＭへ送信されるコミット要求内に含まれ、かつログ３９１８に格納されている条件付きコミットレコードにも含まれ得る。いくつかの実施態様において、ＭＣＤＲは、持続的ログ（例えばログ３９１８と同様）のインスタンスとして実施され得る。
【０１７５】
条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ１がログ３９１８Ａに格納された後のある時点に、書き込みアプライヤ３９２０Ａが当該レコードを調べ得る（矢印４ａにより提示）。いくつかの事例において、このような調査は同期的であり（例えば条件付きコミットレコードはログ３９１８に書き込まれるとすぐに、格納グループのデータストアにコミット済み書き込みをプッシュする責務を担う書き込みアプライヤにより読み出され得る）、一方、他の事例において、書き込みアプライヤは、条件付きコミット判定とは非同期的にコミットレコードを調べ得る。Ｃｏｎｄ‐Ｃ‐Ｒｅｃ１を調べた際、ＷＡ３９２０Ａは、コミットが条件付きであると判断し、よって対応する無条件コミットレコードの検出を試み得る。少なくともいくつかの実施形態において、無条件コミットレコードＵｎｃｏｎｄ‐Ｃ‐Ｒｅｃの位置の開示が、条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ１に含まれ得る。別の実施形態において、書き込みアプライヤは、例えばデータベース内の複数パーティショントランザクションの識別子を検索することにより、他の情報源から無条件コミットレコードの位置を学び得る。矢印５ａで示されるように、描かれた実施形態において、ＷＡ３９２０Ａは、Ｕｎｃｏｎｄ‐Ｃ‐ＲｅｃをＭＣＤＲ３９４０Ａ内に発見し、よって条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ１内に示される書き込みを、その対象書き込み先に実際に適用することを確定し得る。矢印６ａに示されるように、書き込みＷ１は従って、パーティションＬＰ３９１０Ａに伝播され得る。描かれた実施形態において、書き込みアプライヤ３９２０Ｃは、ＷＡ３９０２０Ａと同様の手続きを行い得る。例えば書き込みアプライヤ３９２０Ｃは、条件付きコミットレコードＣｏｎｄ‐Ｃ‐Ｒｅｃ２を同期的または非同期的に調べ（矢印４ｂ）、対応する無条件コミットレコードが格納されていると見込まれる位置を特定し、Ｕｎｃｏｎｄ‐Ｃ‐Ｒｅｃを検索し得る（矢印５ｂ）。Ｗ２が属する複数パーティショントランザクションが無条件にコミットされていることを確認した後、ＷＡ３９２０Ｃは従って、Ｗ２をその目的書き込み先であるＬＰ３９１０Ｃに伝播し得る。
【０１７６】
さらに詳しく後述されるように、少なくともいくつかの実施形態においてタイムアウト機構が実施され、よって無条件コミットレコードＵｎｃｏｎｄ‐Ｃ‐Ｒｅｃがある時間間隔内に書き込まれたことをＷＡ３９２０のどちらかが確認不可能な場合には、Ｗ１またはＷ２等の対応書き込み（複数可）の伝播は破棄され得る。いくつかの実施形態において、複数パーティショントランザクションの書き込みがコミット不可能となる競合をＬＴＭ３９１５が発見した場合、クライアント側コンポーネント３９３０は、無条件コミットレコードの代わりに無条件アボートレコードをＭＣＤＲ３９４０Ａに格納し得る。ＬＴＭ３９１５ＡはＷ１を条件付きでコミット可能であると指定するが、ＬＴＭ３９１５Ｂは競合に基づきＷ２をコミット不可能であると指定するシナリオを検討する。後述のシナリオにおいて、Ｗ１が属する複数パーティショントランザクションの無条件コミットレコードを見つけようとＷＡ３９２０Ａが試みる場合、ＷＡ３９２０Ａは、代わりに複数パーティショントランザクションが破棄／アボートされたことを発見し、従って書き込みＷ１の伝播を破棄し得る。少なくともいくつかの実施形態において、複数パーティショントランザクションを破棄／アボートする決定がなされた場合、ログ３９１８内の条件付きコミットレコードは、変更（例えばアボートを示すように）または削除され得る。同様に、いくつかの実施形態において、複数パーティショントランザクションを無条件にコミットする決定がなされた場合、ログ３９１８内の対応する条件付きコミットレコードは、親複数パーティショントランザクションが無条件にコミットされたことを示すように変更され得る。コミット判定のための競合検出動作のうちの少なくともいくつかは、ログ３９１８のコンテンツに基づいて行われ得るため、このような実施形態において、コミットの条件制限の不明確さを解消することは、後続のコミット判定を行うのに役立ち得る。
【０１７７】
格納グループの構成に含めるＬＴＭ、ＷＡ、及びＭＣＤＲの数に関する決定は、異なる実施形態において、様々な要素に基づき得る。図４０は、少なくともいくつかの実施形態による、格納グループの性能ベースのトランザクション管理構成の実施例を示す。示されるように、分散格納サービス構成マネジャー４０８０は、２つの格納グループのそれぞれの構成要求４０５０Ａ、４０５０Ｂを受信し得る。構成要求４０５０Ａは、クライアントが、１００００の目標トランザクションスループットレートすなわちＴＰＳ（毎秒トランザクション）４００５Ａと、５０ミリ秒の目標書き込みレイテンシ４０１０Ａ（例えば書き込み要求と対応書き込みの対象データストアへの伝播との間の遅延が平均５０ミリ秒を超えない）とを有することを示し得る。例えば含まれるデータストアの種類、ストアの最大サイズ等を示す、クライアントの格納グループのデータストアリスト４０２０Ａ（例えばデータストアＤＳ１、ＤＳ２）も提供され得る。同様に、構成要求４０５０Ｂは、クライアントのデータストアリスト４０２０Ｂ（例えばデータストアＤＳ３、ＤＳ４、ＤＳ５）と、目標ＴＰＳ４００５Ｂ（例えば２００００）と、目標書き込みレイテンシ４０１０Ｂ（例えば２００ミリ秒）とを示し得る。
【０１７８】
構成要求のコンテンツに少なくとも部分的に基づいて、構成マネジャー４０８０（分散格納サービスの管理／制御プレーンのコンポーネントであり得る）は、それぞれの要求４０５０に対し、候補トランザクション管理構成を生成し得る。描かれた実施例において、構成要求４０５０Ａに応じて生成されたトランザクション管理構成４０６０Ａは、２つのＬＴＭ４０２５Ａ、４０２５Ｂと、４つの書き込みアプライヤ４０２７Ａ〜４０２７Ｄと、１つのＭＣＤＲ４０２９Ａとを含み得る。いくつかの実施形態において、提案されるトランザクション管理構成のＬＴＭの数は、クライアントの格納グループの提示または推薦パーティション分割に対応し得る（例えば論理パーティションごとに１つのＬＴＭが設定され得る）。このような実施形態において、クライアントが提案パーティション分割を了承する場合、クライアントまたは格納サービスのどちらかが、好適なパーティション分割プランを決定し得る。別の実施形態において、クライアントは、例えばクライアントの目標ＴＰＳに少なくとも部分的に基づいて、その格納グループをパーティション分割し、パーティション分割プランを構成要求の一部として構成マネジャーに提供するように求められ得る。
【０１７９】
図４０の描かれた実施例において、所定の構成に選ばれるＬＴＭの数は、目標ＴＰＳに比例する。従って、要求４０５０Ａに示される目標１００００ＴＰＳに対して、構成４０６０Ａ内に２つのＬＴＭが提示され、そして要求４０５０Ｂに示される目標２００００ＴＰＳに対して、４つのＬＴＭ（４０２５Ｋ〜４０２５Ｎ）が推薦される。推薦される書き込みアプライヤの数は、目標書き込みレイテンシに基づき、より小さい目標レイテンシにはより多くのアプライヤが推薦される。従って、５０ミリ秒の目標書き込みレイテンシのために４つの書き込みアプライヤが構成４０６０Ａに含まれ、一方要求４０５０Ｂに示される２００ミリ秒の書き込みレイテンシのためには、２つの書き込みアプライヤ４０２７Ｋ、４０２７Ｌのみが構成４０６０Ｂに含まれる。ＭＣＤＲの数もまた、異なる実施形態において、目標ＴＰＳ、複数パーティショントランザクションの目標分数等、様々な要素に基づいて選択され得る。示される実施例において、要求４０５０Ａに示されるパラメータに対して、２つのＭＣＤＲ４０２９Ｋ、４０２９Ｌが推薦される。
【０１８０】
構成要求４０５０に含まれるパラメータの種類、及びパラメータとトランザクション管理構成４０６０の推薦コンポーネント数との関係は、異なる実施形態において図４０に示されるものとは異なり得る。例えば、いくつかの実施形態において、クライアントは、複数パーティショントランザクション対単一パーティショントランザクションの目標割合も、自身の構成要求内に示す必要があり、このような割合は、構成マネジャーによりＭＣＤＲの推薦数を決定するのに使用され得る。少なくともいくつかの実施形態において、構成マネジャーがクライアントに対し推薦構成を提供した後、クライアントは、構成マネジャーがＬＴＭ、ＷＡ、及び／またはＭＣＤＲを配備／インスタンス化する前に、推薦内容を承認する必要があり得る。いくつかの実施形態において、格納グループに設定されるＭＣＤＲ、ＬＴＭ、及び／またはＷＡの数は、例えばトランザクション処理上の中断を要することなく、作業負荷が変化するとともに動的に調整され得る。
【０１８１】
少なくともいくつかの実施形態において、所定のデータストアは、ログベーストランザクション管理のために、いくつかの論理パーティションに分割され得る。すなわち、単一のデータストアの部分集合のために、競合検出及び条件付きコミット判定を管理するように、ＬＴＭが確立され得る。図４１は、少なくともいくつかの実施形態による、所定のデータストアのために複数のログベーストランザクションマネジャーが確立され得る例示的構成を示す。示されるように、描かれたシナリオにおいて、格納グループ４１０２は、データストア４１１０Ａ（例えば非リレーショナルデータベースのインスタンスを備え得る）と、データストア４１１０Ｂ（例えばインメモリデータベースのインスタンス）と、データストア４１１０Ｃ（例えば非構造化オブジェクトへインターフェース接続するウェブサービスを提供する格納サービスのオブジェクトの集合）とを含み得る。
【０１８２】
描かれた実施形態において、格納グループ４１０２は、６つの論理パーティション（ＬＰ）４１２０Ａ〜４１２０Ｆに分割されている。データストア４１１０ＡはＬＰ４１２０Ａ、４１２０Ｂを有し、データストア４１１０ＢはＬＰ４１２０Ｃを有し、そしてデータストア４１２０ＣはＬＰ４１２０Ｄ、４１２０Ｅ、４１２０Ｆを有する。各論理パーティション４１２０には、対応ＬＴＭ４１２５が確立され、例えばＬＰ４１２０ＡはＬＴＭ４１２５Ａを有し、ＬＰ４１２０ＢはＬＴＭ４１２５Ｂを有する等する。予想データ集合サイズはパーティションの数を決定する際の要素であり得るが、少なくともいくつかの実施態様において、所定のデータストアのためにインスタンス化される論理パーティション及び／またはＬＴＭの数は、データストア内に予想されるデータ量に必ずしも比例するとは限らない。様々な実施形態においてパーティション分割を決定するために、例えば、様々な種類のトランザクション（例えば単一パーティション、複数パーティション、またはデータストア横断トランザクション）の予想レート、ＬＴＭ４１２５に使用されるデータストア及び／またはサーバのネイティブ性能（例えばどれだけ速く書き込みがＬＴＭログに適用され得るか）、データストアに対する可用性またはデータ耐久性目標、クライアント予算目標、異なるデータストアに関する価格設定ポリシー差異等、他の要素も使用され得る。
【０１８３】
少なくともいくつかの実施形態において、いくつかのＬＴＭ４１２５は、特定の種類のトランザクションを実施するために協働する必要があり得る。例えば、ＬＰ４１２０ＡがテーブルＴ１を備え、そしてＬＰ４１２０Ｂが別のテーブルＴ２を備えるシナリオを検討する。複数パーティショントランザクションのコミット要求ＣＲ１が、クライアント側コンポーネントによりＬＴＭ４１２５Ａに送られる。ＣＲ１はＴ１に対する読み出しＲ１の読み出し記述子を示し、かつＲ１の結果に基づく２つの書き込み、Ｔ１に対する書き込みＷ１とＴ２に対する書き込みＷ２とを含む。このようなシナリオにおいて、ＬＴＭ４１２５ＡがそのローカルログとＲ１の読み出し記述子とに基づいていかなる競合も検出しない場合、Ｗ１とＷ２の両方ともコミット可能と指定され得る。しかしながら、Ｗ２はＴ１を備えるパーティションとは異なるパーティションを対象とする。このようなシナリオにおいて、少なくともいくつかの実施形態において、それぞれの条件付きコミットレコードが、ＬＴＭ４１２０ＡとＬＴＭ４１２０Ｂの両方のログに書き込まれ得る（例えばＬＴＭ４１２０ＡからＬＴＭ４１２０Ｂへ送られる要求の結果）。いくつかの実施形態において、格納グループの異なるデータストアのために確立されたＬＴＭ間で同様の協働が実施され得る。例えば、Ｗ２がＬＰ４１２０Ｄを対象とする場合、ＬＴＭ４１２０Ａは、Ｗ２の条件付きコミットを含むための要求をＬＴＭ４１２０Ｄへ送信し得る。
【０１８４】
前述のように、いくつかの実施態様において、複数パーティションコミット判定レポジトリ（ＭＣＤＲ）は、ＬＴＭにより使用される持続的ログと同様の持続的ログを使用して実施され得る。従って、このような一実施態様において、ＬＴＭに使用されるログが複製ＤＡＧを使用して実施され得るように、所定のＭＣＤＲは、図１に示される複製ＤＡＧと同様の複製ＤＡＧを使用して実施され得る。図４２は、少なくともいくつかの実施形態による、格納グループのマスタパーティションに対し確立されるログベーストランザクションマネジャーのログと共に、複数パーティションコミット判定レポジトリが共同配置される例示的構成を示す。描かれた実施形態において、格納グループ４２０２は、マスタ論理パーティション４２１０Ａと、非マスタ論理パーティション４２１０Ｂ、４２１０Ｃとに細分化されている。パーティションのうちの１つをマスタまたは主要に指定することは、異なる実施形態において、例えば、パーティションに格納されたデータの相対的重要度（格納グループ４２０２が確立されたクライアントの観点から）、目標性能、コンテンツがパーティションに含まれるデータストアの可用性またはデータ耐久性目標、及び／または他の要素に基づき得る。
【０１８５】
描かれた実施形態において、論理パーティション４２１０それぞれのために、それぞれのＬＴＭ４２１５が構成され得る。描かれた実施形態において、マスタＬＰ４２１０Ａのためにインスタンス化されたＬＴＭ４２１５ＡはマスタＬＴＭに指定され、一方、４２１５Ｂ、４２１５Ｃ等の残りのＬＴＭは非マスタＬＴＭに指定され得る。少なくとも一実施態様において、マスタＬＴＭ４２１５Ａは、非マスタＬＴＭのために配備されるサーバより大きな演算、格納、メモリ、及び／またはネットワーク能力を有する１つまたは複数のサーバを使用して実施され得るが、リソース能力におけるこのような非対称は要件でなくてよい。描かれた実施形態において、マスタＬＴＭのログ４２１８Ａは、格納グループ４２０２に使用されるＭＣＤＲ４２４０と共に、共同配置され得る（例えば演算、ネットワーク、格納、及び／またはメモリのために同じサーバのリソースを共有し得る）。ＭＣＤＲ４２４０及び／またはログ４２１８Ａはそれぞれ、共同配置されているノードのうちのいくつかと共に、いくつかの実施形態において、複数の複製ＤＡＧノードのそれぞれとして実施され得る。例えば、複製ＤＡＧ‐ＲＤ１のノードＮ１、Ｎ２、Ｎ３、Ｎ４がログ４２１８Ａに使用され、別の複製ＤＡＧのノードＮｋ、Ｎｌ、Ｎｍ、ＮｎがＭＣＤＲ４２４０に使用され、Ｎ１は所定のサーバ上でＮｋと共同配置され、Ｎ２は別のサーバ上でＮｌと共同配置される等する。少なくともいくつかの実施形態において、ＭＣＤＲ４２４０に使用される複製ＤＡＧのノードの数は、マスタＬＴＭのログ４２１８Ａに使用される複製ＤＡＧのノードの数と同一である必要はない。一実施形態において、ログ４２１８Ａ及びＭＣＤＲ４２４０のレコードに、同一の複製ＤＡＧが使用され得る。いくつかの実施形態において、ＬＴＭのうちの１つをマスタとして指定することは、必ずしもそのＬＴＭのリソースをＭＣＤＲと共有することを伴うとは限らないことに留意されたい。別の実施形態において、複数のＬＴＭログが、格納グループのそれぞれのＭＣＤＲと共同配置され得る。
【０１８６】
図４３は、少なくともいくつかの実施形態による、複数パーティショントランザクションに対応する格納グループで生成され得るコミット要求の例示的構成要素を示す。示されるように、コミット要求４３４４は、トランザクション種類４３０２（例えばコミットが要求されている書き込み（複数可）は、単一パーティショントランザクションの一環であるか、複数パーティショントランザクションの一環であるか）の開示を含み得る。いくつかの実施態様において、トランザクション種類４３０２の代わりに、コミット種類がコミット要求内に示され、例えば、複数パーティショントランザクションの書き込み（複数可）に対し「条件付き」コミット種類が示され、単一パーティショントランザクションの書き込み（複数可）に対し「無条件」コミット種類が示される。コミット要求は、１つまたは複数の書き込み記述子４３０６により表現される書き込みが依存する読み出しを示す１つまたは複数の読み出し記述子４３０４を含み得る。いくつかの実施形態において、読み出し記述子は、ＲＲＶＭ（読み出し再現性検証メタデータ）、及び／または読み出しが対象とするパーティションのコミット済みステートを表す１つまたは複数のステート遷移インジケータを含み、これらのＲＲＶＭとステート遷移インジケータは、（パーティションレベルで）前述のＲＲＶＭとステート遷移インジケータに類似する。
【０１８７】
書き込み記述子４３０６（図１７〜２５に関連して前論された書き込み集合記述子に類似し得る）は、例えばコミット要求の書き込みが対象とする位置の指示を含み得る。書き込みペイロード（複数可）４３０８は、書き込み記述子内に示されるアドレスに書き込むデータまたはコンテンツを示し得る。いくつかの実施形態において、重複排除制約及び／またはコミット順序付け制約等を参照して前述された論理制約は、それぞれの論理制約記述子４３１０を介して示され得る。（この論理制約記述子は、図２２〜２５を参照して論じられる論理制約記述子に類似し得る。）論理制約は、いくつかのこのような実施形態においてパーティションレベルで、他の実施形態において格納グループレベルで指示され得る。論理制約が格納グループレベルで指示される場合、コミット要求４３４４を受信するＬＴＭは、いくつかの実施形態において、要求された書き込みを条件付きで（または無条件に）コミットする前に確実に制約が満たされているように、他のＬＴＭと協働する必要があり得る。
【０１８８】
図４３に描かれた実施形態において、ＭＣＤＲ情報４３１２は、複数パーティショントランザクションのコミット要求内に含まれ得る。ＭＣＤＲ情報は、例えば、コミット要求に応じて作成されると予想される無条件コミットレコード（またはアボートレコード）にアクセスするために使用可能な識別子、キー、またはアドレスを含み得る。複数パーティショントランザクションを表す一意的識別子またはキーは、例えば、いくつかの実施形態において、ハッシュテーブルまたは同様の構造内で無条件コミットレコードを検索するために使用され得る。ＭＣＤＲ情報４３１２は、ＬＴＭログに格納されている条件付きコミットレコードに含まれ、そのため例えば書き込みアプライヤは無条件コミット／アボートレコードの位置を特定することが可能である。
【０１８９】
いくつかの実施形態において、コミットタイムアウト値４３１４がコミット要求内に指示され得る。コミットタイムアウト値は、複数パーティショントランザクションＭＴ１の条件付きコミットレコードＣＣＲ１を調べた書き込みアプライヤＷＡ１が、ＣＣＲ１の書き込み（複数可）の伝播を破棄する前に、ＭＴ１に対応する無条件コミットレコードＵＣＲがＭＣＤＲに書き込まれるのを待たなければならない最大時間を示し得る。従って、コミットタイムアウト値により、クライアント側コンポーネントがハングアップした場合または障害を生じた場合の問題を解決する方法が提供され得る。これがなければ、いくつかの実施態様において、複数パーティショントランザクションの結末（コミットまたはアボート）に関して不確定性を生じる可能性があり得る。少なくともいくつかの実施形態において、ＭＣＤＲは、単調に増加する論理タイムスタンプ値を提供する論理クロックを実施し、そしてタイムアウト値は、このようなクロックの将来論理タイムスタンプ値として表現され得る。例えば、１つのシナリオにおいて、コミット要求４３４４を準備するクライアント側コンポーネントは、ＭＣＤＲ論理クロックから現在の論理タイムスタンプ値ＬＴＳ１を読み出し、ある選択オフセット（例えば１０００）をＬＴＳ１に加えてタイムアウト値を取得し得る。タイムアウト値（ＬＴＳ１＋１０００）は、コミット要求４３４４を受信するＬＴＭにより生成される条件付きコミットレコード内に格納され得る。いくつかの実施形態において、そのコミット要求内に示される書き込みを伝播する責務を担う書き込みアプライヤは、無条件コミットレコード（または無条件アボートレコード）が適切なＭＣＤＲ内に存在するか否かを定期的に確認し得る。書き込みアプライヤは、無条件コミット／アボートレコードを発見できなかった場合、ＭＣＤＲの論理クロックから現在の論理タイムスタンプを取得し得る。当実施例において現在のタイムスタンプがＬＴＳ１＋１０００のタイムアウト値を超える場合、書き込みアプライヤは、条件付きコミットレコードの書き込みの伝播／適用を破棄し得る。いくつかの実施形態において図４３に示される全てのコンポーネントがコミット要求内に組み込まれ得るとは限らず、また他の実施形態においては図４３に図示されていない別のコンポーネントが含まれ得ることに留意されたい。ＭＣＤＲ情報４３１２及びコミットタイムアウト値４３１４は、コミット要求レコード４３４４に含まれ得る複数パーティショントランザクションメタデータの実施例としてみなされ得る。
【０１９０】
いくつかの実施形態において、単一パーティショントランザクションは、格納グループで処理される総作業負荷のうちかなりの割合（または過半数すら）を占め、コミット済み単一パーティショントランザクションの書き込みは、ＭＣＤＲを調べることなく書き込みアプライヤによりパーティションに伝播され得る。単一パーティショントランザクションの書き込みが依存する読み出しは、書き込み自体と同様に、複数のパーティションを対象とし得ないため、単一のＬＴＭのみがこのようなトランザクションに対し競合検出を行うように求められ得る。いくつかのこのような実施形態において、単一パーティショントランザクションに関してＬＴＭログに格納される情報の種類は、複数パーティショントランザクションに関して格納される情報の種類とは異なり得る。図４４ａと図４４ｂは、少なくともいくつかの実施形態による、ログベーストランザクションマネジャーにより単一パーティショントランザクションと複数パーティショントランザクションに関してそれぞれ格納され得るコミットレコードの例示的構成要素を示す。図４４ａに示されるように、単一パーティショントランザクションのコミット要求４４３１が、クライアント側コンポーネント４４３０により、そのパーティションに指定されたＬＴＭ４４０２に対し提出され得る。ＬＴＭ４４０２の競合検出器４４０２は、コミット要求４４３１に含まれる１つまたは複数の読み出し記述子を、持続的ログ４４４２に前に格納されているコミットレコードの選択集合と共に使用して、コミット要求４４３１内に示される読み出しが後続のコミット済み書き込みと競合するか否かを判定し得る。競合が検出されない場合、コミット要求４４３１に対応するコミットレコード４４４４Ａが、ログ４４４２に追加され得る。要求４４３１は単一パーティショントランザクションに対するものであるため、コミットを無条件として指定するために追加の整合（例えば複数パーティショントランザクションの場合にクライアント側コンポーネントにより行われる整合と同様の整合）は必要でなくてよい。従って、少なくともいくつかの実施形態において、コミットレコード４４４４Ａは、例えば示される種類フィールド４４５２Ａを使用して、コミットが無条件であることを示し得る。単一パーティションコミット要求のコミットレコード４４４４Ａはまた、例えば１つまたは複数の書き込みペイロードの指示と、書き込みが対象とするパーティション内の位置とを含む書き込み（複数可）情報４４６２Ａも含み得る。
【０１９１】
図４４ｂに示されるように、複数パーティショントランザクションの書き込みのコミット要求４４３２に応じて、（例えば要求４４３２の読み出し記述子（複数可）と、ログ４４４２に前に格納されたコミット要求の選択集合とに基づいて、）競合検出器４４４０は、単一パーティショントランザクションのコミット要求に行われたのと同類のローカル競合検出を行い得る。しかしながら、描かれた実施形態において、競合がローカルで検出されないイベントで、ログ４４４２に格納される新たなコミットレコード４４４４Ｂは、コミットレコード４４４４Ａとはいくつかの点で異なり得る。例えば、フィールド４４５２Ｂに示されるコミットの種類は、無条件に設定される代わりに条件付きに設定され得る。コミット種類フィールド及び書き込み情報４４６２Ｂに加えて、いくつかの実施形態において、ＭＣＤＲ検索情報４４５６がコミット要求に含まれ得る。ＭＣＤＲ検索情報（コミット要求４４３２のコンテンツに少なくとも部分的に基づき得る）により、書き込みアプライヤは、条件付きコミットレコード４４４４Ｂに対応する無条件コミット／アボートレコードが位置すると見込まれる場所を特定することが可能になり得る。実施態様により、異なる種類のエントリがＭＣＤＲ検索情報４４５６に含まれ得る。例えば無条件コミットレコードのアドレスまたは識別子が一実施態様において提供され得る、あるいはアドレスの検索に使用可能なキーが提供され得る、あるいはアドレスを取得するために呼び出し可能な関数が提供され得る。少なくともいくつかの実施形態において、例えば無条件コミット／アボートレコードがＭＣＤＲ内で取得可能となるべき最終時間を示すコミットタイムアウト４４５８が条件付きコミットレコード４４４４Ｂに含まれ、そのためタイムアウト経過後このような無条件コミット／アボートレコードが見つからなかった場合、条件付きコミットレコード４４４４Ｂの書き込み（複数可）は、それらの対象パーティションに伝播される必要はなくてよい。前述のように、少なくともいくつかの実施形態において、このようなタイムアウト値４４５８は、ＭＣＤＲの論理クロックから取得されると見込まれる論理タイムスタンプ値により表現され得る。ＭＣＤＲ検索情報及びコミットタイムアウト４４５８は、例えば書き込みアプライヤにより使用される、条件付きコミットレコード４４４４Ｂに格納される複数パーティショントランザクションメタデータの実施例としてみなされ得る。
【０１９２】
いくつかの実施形態において、単一パーティションまたは複数パーティションのコミットレコードのコンテンツは、図４４ａ、４４ｂに例示されるものとは異なり得る。例えば、一実施形態において、コミットレコードは、コミット種類フィールドの代わりにトランザクション種類フィールド（例えば単一パーティションあるいは複数パーティション）を含み、そして書き込みアプライヤは、トランザクション種類フィールドのコンテンツに基づいて、所定のコミットレコードに関してＭＣＤＲのコンテンツの調査が必要か否かを判定し得る。いくつかの実施態様において、ＭＣＤＲ検索情報４４５６は必要ではあり得ない。例えば、条件付きコミットの無条件レコードが見つかり得る場所を特定するために書き込みアプライヤが書き込み記述子のコンテンツを使用することを可能にするプロトコルが使用され得る。一実施形態において、タイムアウト値はコミットレコード内に示され得ない。代わりに例えば、書き込みアプライヤが、最初にコミットレコードを読み出した時に自身のタイムアウトを設定し、そのタイムアウトが経過した時に書き込み伝播の破棄を判定し得る。
【０１９３】
図４５は、少なくともいくつかの実施形態による、クライアント側コンポーネントと、複数パーティショントランザクションに対応する格納グループのそれぞれのパーティションのログベーストランザクションマネジャーとにより行われ得る動作態様を示すフロー図である。構成要素４５０２により示されるように、格納グループのクライアント側コンポーネントＣＳＣ１は、格納グループのパーティションＰ１に対応付けられた第１ログベーストランザクションマネジャーＬＴＭ１に対し、複数パーティショントランザクションＭＰＴ１の書き込みＷ１のコミット要求ＣＲ１を提出し得る。例えば、トランザクションが格納グループの複数のパーティションを対象とする読み出しに依存する場合、トランザクションはＣＳＣ１により複数パーティションとして指定され、従ってトランザクション全体としてのコミット判定は、複数のＬＴＭにより個々のコミット判定が行われる（例えばそれぞれの読み出し書き込み競合検出が行われる）ことを要し得る。図４５に例示される簡潔なシナリオにおいて、ＭＰＴ１は２つの書き込みＷ１、Ｗ２を含み得る。描かれた実施形態において、書き込みＷ１は、読み出し記述子ＲＤ１がＣＲ１に含まれる読み出しＲ１（パーティションＰ１を対象とする）の結果に依存し得る。ＬＴＭ１は、例えば自身の持続的ログＬ１とＲＤ１とを使用して競合検出を行い、ＬＴＭ１によりローカルで検出可能な読み出し書き込み競合の類に関してＷ１はコミット可能であるか否かを判定する。競合が見つからなかった場合（構成要素４５０６にて判定）、Ｗ１は条件付き、またはローカルでコミット可能であるとＬＴＭ１により指定されたことを示す新たな条件付きコミットレコードＣＣＲ１が、Ｌ１に格納され得る（構成要素４５１０）。いくつかの実施形態において、ＣＣＲ１はまた、コミットタイムアウト値、及び／またはＭＰＴ１が無条件でコミット可能であると判明した場合／時に無条件コミットレコードが書き込まれる見込みのＭＣＤＲの指示も含み得る。ＬＴＭ１はＣＳＣ１に対し、例えばＣＲ１に応じて、Ｗ１が条件付きでコミット可能であると判明したこと、かつＣＣＲ１がＬ１に書き込まれたことを通知し得る。描かれた実施形態において、Ｗ１がローカルでコミット可能ではない場合、例えば構成要素４５０６に対応する動作において１つまたは複数の競合がＬＴＭ１により検出された場合、ＣＣＲ１はＬ１に格納されず、そしてＷ１は拒否されたことがＣＳＣ１に通知され得る（構成要素４５１８）。
【０１９４】
描かれた実施形態において、ＣＳＣ１はまた、別の書き込みＷ２に対応するコミット要求ＣＲ２を、別のパーティションＰ２の競合検出の責務を担うログベーストランザクションマネジャーＬＴＭ２に対し提出し得る（構成要素４５０４）。ＣＲ２は、Ｗ２が依存する読み出し（複数可）を示す自身の読み出し記述子集合も含み得る。ＬＴＭ２は、ＬＴＭ２のログＬ２とＣＲ２の読み出し記述子とを使用して、Ｗ２に関する自身の競合検出を行い、Ｗ２がコミット可能であるか否かを判定し得る。ＬＴＭ２がＷ２を受諾することを妨げる競合が見つからなかった場合（構成要素４５０８）、Ｗ２の条件付きコミットレコードＣＣＲ２が、ＬＴＭ２のログＬ２に格納され得る（構成要素４５１２）。描かれた実施形態において、ＣＣＲ２はまた、コミットタイムアウト値（例えばＣＣＲ１に格納されたものと同じ値、またはＬＴＭ２により決定された異なる値）と、Ｗ２の無条件コミットレコードが見込まれるＭＣＤＲ位置の指示とを含み得る。例えばＬＴＭ２により生成されたＣＲ２に対する応答において、Ｗ２が条件付きまたはローカルでコミット可能であると指定されたこと、かつＣＣＲ２がＬ２に書き込まれたことが、ＣＳＣ１に通知され得る（構成要素４５１６）。Ｗ２がローカルでコミット可能ではない場合、例えば構成要素４５０８に対応する動作において１つまたは複数の競合がＬＴＭ２により検出された場合、ＣＣＲ２はＬ２に格納されず、そしてＷ２は拒否されたことがＣＳＣ１に通知され得る（構成要素４５２０）。
【０１９５】
描かれた実施形態において、例えばＬＴＭ１とＬＴＭ２の両者がそれぞれのログに対しそれぞれの条件付きコミットレコードＣＣＲ１、ＣＣＲ２を書き込んだという特定に基づいて、ＣＳＣ１がＷ１とＷ２の両方とも条件付きでコミットされたと判定した場合（構成要素４５２８）、ＣＳＣ１は、ＭＰＴ１の無条件コミットレコードを生成し、ＭＣＤＲ内に当該無条件コミットレコードを格納し得る（構成要素４５３１）。Ｗ１とＷ２のうちの１つ、または両方がコミット不可能であると拒否された場合（同様に構成要素４５２８にて検出）、例えば条件付きコミットレコードＣＣＲ１またはＣＣＲ２のうちの少なくとも１つが書き込まれていないとＣＳＣ１が判定した場合、ＣＳＣ１はＭＰＴ１の無条件コミットレコードをＭＣＤＲに格納し得ない。いくつかの実施形態において、代わりにアボートレコードがＭＣＤＲに、例えば両方の書き込みがコミット可能であると指定された場合に無条件コミットレコードが書き込まれ得る位置と同じ位置に、任意で格納され得る（構成要素４５３４）。ＭＰＴ１に関して２つの書き込みのみが論述されたが、一般に、複数パーティショントランザクションは任意の所望数の書き込みを含み、そしてＣＳＣは、少なくともいくつかの実施形態において、全ての書き込みがそれぞれのＬＴＭによりローカルでコミット可能であると指定されたことを確認した後に、無条件コミットレコードを格納し得ることに留意されたい。いくつかのシナリオにおいて、所定の複数パーティショントランザクションのいくつかの異なる書き込み（例えばＷｘ、Ｗｙ、Ｗｚ）は、単一のパーティション（例えばＬＰ１）を対象とし得る。いくつかの実施態様において、所定のパーティションに対するいくつかのこのような書き込みは、単一のコミット要求に含まれ得る。例えばＷｘ、Ｗｙ、Ｗｚを示す１つのコミット要求が、ＣＳＣ１によりＬＴＭ１に対し送られ得る。別の実施態様において、各書き込み要求は、個別のコミット要求を使用して処理され得る。いくつかの実施形態において、要求書き込みが条件付きでコミットされたか否かに関して通知されるのを待つ代わりに、ＣＳＣは、書き込みのステータスを特定するためにより能動的な役割を果たし得る。例えば、ＣＳＣは、直接ＬＴＭログを読み出し得る（例えば図１５に示されるインターフェース１５１３と同様のログ読み出しインターフェースを使用して）、あるいはＬＴＭに問い合わしてコミット要求の結果を特定し得る。
【０１９６】
少なくとも一実施形態において、クライアント側コンポーネントは、単一パーティショントランザクションを複数パーティショントランザクションの特例として扱い得る。例えば単一パーティショントランザクションの書き込みがＬＴＭによりコミットのために受諾されたことが特定されると、単一パーティショントランザクションの無条件コミットレコードは、単一パーティションと複数パーティションの両トランザクションに使用されるコミット判定レポジトリ（ＣＤＲ）に同様に格納され得る。このような実施形態において、ＣＤＲは、単一パーティショントランザクションに関して、並びに複数パーティショントランザクションに関して、書き込みアプライヤにより調べられ得る。別の実施形態において、コミット判定レポジトリは、複数パーティショントランザクションのためにのみ使用され得る。
【０１９７】
図４６は、少なくともいくつかの実施形態による、複数パーティショントランザクションに対応する格納グループの書き込みアプライヤにより行われ得る動作態様を示すフロー図である。構成要素４６０１に示されるように、格納グループの１つまたは複数のパーティションに変更を適用するように構成された書き込みアプライヤＷＡ１は、格納グループのパーティションＰ１に対応付けられたログベーストランザクションマネジャーＬＴＭ１の持続的ログに格納されているコミットレコードＣＲｅｃ１を調べ得る。対応コミットは条件付きであるとＣＲｅｃ１が示す場合（構成要素４６０４にて検出）、ＷＡ１は、ＣＲｅｃ１内に示される書き込み（複数可）は複数パーティショントランザクションの一部であること、かつ書き込みがそれらの対象書き込み先に伝播される前に無条件コミットレコードが発見されなければならないことを、推測し得る。従って、構成要素４６１０に示されるように、ＷＡ１は、（ａ）ＣＲｅｃ１に対応する無条件コミットレコードＵＣＲ１が格納されると見込まれるＭＣＤＲ内の位置と、（ｂ）複数パーティショントランザクションが破棄されないように、ＵＣＲ１が見つからなければならない最終時間を示すコミットタイムアウト値ＴＯ１とを、特定し得る。
【０１９８】
ＷＡ１は、ＵＣＲ１が既にＭＣＤＲに格納されているか否かを検査し得る（構成要素４６１４）。描かれた実施形態において、ＵＣＲ１が既に格納されている場合、ＷＡ１は、ＣＲｅｃ１内に示される書き込み（複数可）を、それらの書き込み先に伝播または適用し得る（構成要素４６２６）。ＵＣＲ１がＭＣＤＲ内に存在しない場合（同様に構成要素４６１４にて検出）、ＷＡ１は、（ａ）ＴＯ１により示されるタイムアウトが経過したか、（ｂ）ＣＲｅｃ１に対応するアボートレコードがＭＣＤＲに格納されているかを検査し得る（構成要素４６１７）。タイムアウトがＭＣＤＲの論理クロックの論理タイムスタンプ単位で表現される実施態様において、例えば、ＷＡ１は、現在の論理タイムスタンプに関してＭＣＤＲにクエリを提出し、タイムアウトが経過したか否かを判定し得る。タイムアウトが経過したこと、またはＣＲｅｃ１に対応する複数パーティショントランザクションが明示的にアボートされたことがＷＡ１により特定された場合、ＣＲｅｃ１の書き込み伝播及び／またはさらなる処理はＷＡ１により破棄され得る、すなわちＣＲｅｃ１の書き込みは、それらの書き込み先位置に適用される必要はない（構成要素４６２０）。タイムアウトは経過しておらず、かつアボートレコードも見つからない場合（同様に構成要素４６１７にて検出）、ＷＡ１は、ＣＲｅｃ１に対応する無条件コミットレコードがもう書き込まれたか否かを確認するためＭＣＤＲを再検査する前に（構成要素４６１４）、特定または調整可能ＭＣＤＲ検査間隔を待ち得る（構成要素４６２３）。描かれた実施形態において、ＭＣＤＲは、（ａ）ＣＲｅｃ１に対応する無条件コミットレコードＵＣＲ１が見つかった、（ｂ）ＣＲｅｃ１に対応するアボートレコードが見つかった、または（ｃ）タイムアウトが経過した、以上の３つのイベントのうちの１つが起こるまで、構成要素４６１４以降に従って、間隔を置いて検査され得る。（ａ）が起こった場合、ＣＲｅｃ１の書き込みは伝播され（構成要素４６２６）、他の場合には、書き込みは最終的に破棄され得る。いくつかの実施態様において、書き込みの伝播が破棄された場合、コミットレコードＣＲｅｃ１は、破棄を示すために、変更され得る、あるいはＬＴＭ１のログから削除され得る（例えばＷＡ１からの要求に応じて、ＷＡ１により、またはＬＴＭ１により）。
【０１９９】
図４６に描かれた実施形態において、同様に構成要素４６０４にて検出されるように、ＣＲｅｃ１がそのコミットは無条件であると示した場合（例えばＣＲｅｃ１内に示される書き込み（複数可）が複数パーティショントランザクションの代わりに単一パーティショントランザクションの一部である場合）、書き込みは、ＭＣＤＲのいかなる調査もすることなく、ＷＡ１によりそれらの目的書き込み先へ伝播され得る（構成要素４６２６）。別の実施形態において、前述のように、単一パーティション及び複数パーティションの両トランザクションは、無条件コミットレコードが両種類のトランザクションのコミット判定レポジトリに格納され得るという点で、統一した手法で処理され、そして書き込みアプライヤは、いずれの種類のトランザクションの書き込みも伝播する前に、このような無条件コミットレコードが書き込まれていることを確認する必要があり得る。
【０２００】
様々な実施形態において、図６、７、８、９、１０、１２、１３、１４、１９、２０、２５、３０、３７、３８、４５、４６のフロー図において例示される動作とは異なる動作が、前述の技術のうちの少なくともいくつかを実施するために使用され得ることに留意されたい。フローチャートに示される動作のうちのいくつかは、いくつかの実施形態において実行されなくてよい、または別の順序で実行され得る、または順次ではなく並行して実行され得る。
【０２０１】
使用事例
読み出し記述子とクライアント側トランザクション準備を使用するログベーストランザクション管理を含む、複製ＤＡＧを使用してアプリケーションステート変更を管理する前述の技術は、様々な実施形態において有用であり得る。より多くの組織が自身のコンピューティングをプロバイダネットワーク環境へ移行するにつれ、それぞれの整合性セマンティック及びそれぞれのインターフェースを有するより多様な分散格納アプリケーションが開発されてきた。いくつかの大アプリケーションは複数データストアインスタンスにわたり、そして複製ＤＡＧ及びログベーストランザクション管理技術は、分散格納アプリケーション管理に対する、統合され、柔軟で、拡大縮小可能な、可用性の高い手法を表し得る。ＤＡＧ構成のそれぞれの見解は少なくとも一時的に異なり得るが、複製ＤＡＧノードのアプリケーションステート遷移を進行させる能力は、より少ない動的複製技術が使用された場合に起こり得る、アプリケーション要求を処理する際の「全世界停止」中断のうちの少なくともいくつかを低減または削除し得る。ログベーストランザクション管理は、データストア横断トランザクション（並びに原子複数書き込みトランザクションに対応し得ないデータストアに対する複数アイテムトランザクション）を可能にし得るだけでなく、自動化クエリ応答生成、スナップショット生成等の機能の促進も行い得る。ログサービスの自身の読み出しインターフェースを使用することで、複数データストアにわたるデータ分析を行う完全に新しい方法が利用可能となり得る。このような新たな種類のデータストア横断動作の費用を明確にする価格設定ポリシーが実施され、これによりユーザは、自身のデータ変換要求に関して、情報に基づいた予算決定を行うことが可能となる。非常に高いスループットのアプリケーションのために、前述の手法を使用して、楽観的ログベーストランザクション管理は拡張され得る。拡張された楽観的ログベーストランザクション管理では、ログベーストランザクションマネジャーは所定格納グループのそれぞれのパーティションに設定され、そしていずれかの所定の複数パーティショントランザクションのコミットは、複数のこのようなトランザクションマネジャーと対話するクライアント側コンポーネントにより整合される。
【０２０２】
いくつかのプロバイダネットワーク環境において、仮想化コンピューティングサービス、格納サービス、またはデータベースサービス等、プロバイダネットワークにて実施される別のネットワークアクセス可能サービスの制御プレーン構成情報を格納するのに、複製ＤＡＧによるログベーストランザクション管理が使用され得る。このようなシナリオにおいて、ログを使用して管理されるトランザクションは、ネットワークアクセス可能サービスの様々なリソース（仮想コンピューティングサービスの事例における演算インスタンスまたは仮想ホスト等）の構成に対する変更を表し得る。
【０２０３】
例示的コンピュータシステム
少なくともいくつかの実施形態において、複製ＤＡＧの様々なコンポーネント、トランザクション管理のためのログサービス、または異種格納システム（フロントエンド要求ハンドラ等のクライアント側コンポーネント、並びに複数パーティションコミット判定レポジトリを含む）を実行する技術を含む、本明細書において説明される技術のうちの１つまたは複数の一部または全てを実施するサーバは、１つまたは複数のコンピュータアクセス可能媒体を含む、またはそのような媒体にアクセスするように構成された、汎用コンピュータシステムを含み得る。図４７は、このような汎用コンピューティングデバイス９０００を例示する。例示される実施形態において、コンピューティングデバイス９０００は、入出力（Ｉ／Ｏ）インターフェース９０３０を介してシステムメモリ９０２０（不揮発性及び揮発性メモリモジュールの両方を備え得る）に接続された１つまたは複数のプロセッサ９０１０を含む。コンピューティングデバイス９０００はさらに、Ｉ／Ｏインターフェース９０３０に接続されたネットワークインターフェース９０４０を含む。
【０２０４】
様々な実施形態において、コンピューティングデバイス９０００は、１つのプロセッサ９０１０を含むユニプロセッサシステム、またはいくつか（例えば２つ、４つ、８つもしくは別の好適な個数）のプロセッサ９０１０を含むマルチプロセッサシステムであり得る。プロセッサ９０１０は、命令を実行可能な任意の好適なプロセッサであり得る。例えば、様々な実施形態において、プロセッサ９０１０は、様々な命令集合アーキテクチャ（ＩＳＡ）、例えばｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、ＭＩＰＳ‐ＩＳＡ、またはその他の好適なＩＳＡ等、そのうちのいずれかを実施する汎用または組み込みプロセッサであり得る。マルチプロセッサシステムにおいて、それぞれのプロセッサ９０１０は一般に、必ずではないが、同一のＩＳＡを実施し得る。いくつかの実施態様において、従来のプロセッサの代わりに、または従来のプロセッサに加えて、グラフィック処理ユニット（ＧＰＵ）が使用され得る。
【０２０５】
システムメモリ９０２０は、プロセッサ９０１０（複数可）によりアクセス可能な命令及びデータを格納するように構成され得る。少なくともいくつかの実施形態において、システムメモリ９０２０は、揮発性及び不揮発性部分の両方を備え得る。別の実施形態においては、揮発性メモリのみが使用され得る。様々な実施形態において、システムメモリ９０２０の揮発性部分は、静的ランダムアクセスメモリ（ＳＲＡＭ）、同期式動的ＲＡＭ、またはその他の種類のメモリ等、任意の好適なメモリ技術を使用して実行され得る。システムメモリの不揮発性部分（例えば１つまたは複数のＮＶＤＩＭＭを備え得る）に関して、いくつかの実施形態において、ＮＡＮＤフラッシュデバイスを含むフラッシュベースメモリデバイスが使用され得る。少なくともいくつかの実施形態において、システムメモリの不揮発性部分は、超コンデンサまたは他の蓄電装置（例えば電池）等の電源を含み得る。様々な実施形態において、メモリスタベースの抵抗ランダムアクセスメモリ（ＲｅＲＡＭ）、３次元ＮＡＮＤ技術、強誘電性ＲＡＭ、磁気抵抗ＲＡＭ（ＭＲＡＭ）、または様々な種類の相変化メモリ（ＰＣＭ）のうちのいずれかが、少なくともシステムメモリの不揮発性部分に使用され得る。例示される実施形態において、前述の方法、技術、及びデータ等、１つまたは複数の所望する機能を実行するプログラム命令及びデータは、システムメモリ９０２０内にコード９０２５及びデータ９０２６として格納されることが示される。
【０２０６】
一実施形態において、Ｉ／Ｏインターフェース９０３０は、プロセッサ９０１０と、システムメモリ９０２０と、様々な種類の持続的及び／または揮発性格納デバイス等、ネットワークインターフェース９０４０または他の周辺インターフェースを含む任意の周辺デバイスとの間のデバイス内のＩ／Ｏトラフィックを調整するように構成され得る。いくつかの実施形態において、Ｉ／Ｏインターフェース９０３０は、１つのコンポーネント（例えばシステムメモリ９０２０）からのデータ信号を、別のコンポーネント（例えばプロセッサ９０１０）が使用するのに好適な形式に変換するために、任意の必要なプロトコル変換、タイミング変換、または他のデータ変換を行い得る。いくつかの実施形態において、Ｉ／Ｏインターフェース９０３０は、例えば周辺構成要素相互接続（ＰＣＩ）バス規格または汎用シリアルバス（ＵＳＢ）規格の変形等、様々な種類の周辺バスを介して取り付けられるデバイスのサポートを含み得る。いくつかの実施形態において、Ｉ／Ｏインターフェース９０３０の機能は、例えばノースブリッジとサウスブリッジといった２つ以上の別々のコンポーネントに分割され得る。また、いくつかの実施形態において、システムメモリ９０２０に対するインターフェース等、Ｉ／Ｏインターフェース９０３０の機能性のうちの一部または全ては、プロセッサ９０１０に直接組み込まれ得る。
【０２０７】
ネットワークインターフェース９０４０は、コンピューティングデバイス９０００と、例えば図１から図４６までにおいて例示される他のコンピュータシステムまたはデバイス等、ネットワーク９０５０（複数可）に接続される他のデバイス９０６０との間でデータ交換が可能なように構成され得る。様々な実施形態において、ネットワークインターフェース９０４０は、例えばイーサネット（登録商標）ネットワークの類等、任意の好適な有線または無線汎用データネットワークを介して、通信に対応し得る。さらに、ネットワークインターフェース９０４０は、アナログ音声ネットワークもしくはデジタルファイバ通信ネットワーク等の電気通信／電話ネットワークを介した、またはファイバチャネルＳＡＮ等の格納エリアネットワークを介した、またはその他の好適な種類のネットワーク及び／またはプロトコルを介した、通信に対応し得る。
【０２０８】
いくつかの実施形態において、システムメモリ９０２０は、対応方法及び装置の実施形態を実行するために、図１から図４６に関して前述されたプログラム命令及びデータを格納するように構成されたコンピュータアクセス可能媒体の一実施形態であり得る。しかしながら、別の実施形態において、プログラム命令及び／またはデータは、異なる種類のコンピュータアクセス可能媒体上で受信、送信、または格納され得る。一般に、コンピュータアクセス可能媒体には、例えばＩ／Ｏインターフェース９０３０を介してコンピューティングデバイス９０００に接続されるディスクまたはＤＶＤ／ＣＤといった磁気媒体または光学式媒体等の非一時的記憶媒体またはメモリ媒体が含まれ得る。非一時的コンピュータアクセス可能記憶媒体には、システムメモリ９０２０または別の種類のメモリとしてコンピューティングデバイス９０００のいくつかの実施形態に含まれ得るＲＡＭ（例えばＳＤＲＡＭ、ＤＤＲ‐ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の任意の揮発性または不揮発性媒体も含まれ得る。さらに、コンピュータアクセス可能媒体は、ネットワークインターフェース９０４０を通して実施され得るネットワーク及び／または無線リンク等の通信媒体を介して伝達される伝送媒体または電気、電磁、もしくはデジタル信号等の信号を含み得る。様々な実施形態において説明される機能性を実行するために、図４７に例示されるような複数のコンピューティングデバイスの一部または全てが使用され得る。例えば、様々な異なるデバイス及びサーバ上で稼働するソフトウェアコンポーネントは、協働して機能性を提供し得る。いくつかの実施形態において、説明される機能性の一部は、汎用コンピュータシステムを使用して実行されるのに加えて、またはそれに代わって、格納デバイス、ネットワークデバイス、または特殊目的コンピュータシステムを使用して実行され得る。本明細書で使用される「コンピューティングデバイス」という用語は、少なくとも全てのこれらの種類のデバイスを指し、かつこれらの種類のデバイスに限定されない。
【０２０９】
前述の内容は、以下の追加条項を考慮することでより理解され得る。
１．１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記１つまたは複数のコンピューティングデバイスは、
第１ログベーストランザクションマネジャー（ＬＴＭ）にて、格納グループのクライアント側コンポーネントから、第１複数パーティショントランザクションの第１書き込みに対する第１コミット要求を受信することであって、前記第１書き込みは前記第１コミット要求内に示される第１読み出しの結果に依存し、前記第１読み出しは前記格納グループの第１パーティションを対象とした、前記第１複数パーティショントランザクションの前記第１書き込みに対する前記第１コミット要求を受信することと、
第２ＬＴＭにて、前記クライアント側コンポーネントから、前記第１複数パーティショントランザクションの第２書き込みに対する第２コミット要求を受信することであって、前記第２書き込みは前記第２コミット要求内に示される第２読み出しの結果に依存し、前記第２読み出しは前記格納グループの第２パーティションを対象とした、前記第１複数パーティショントランザクションの前記第２書き込みに対する前記第２コミット要求を受信することと、
前記第１ＬＴＭの第１持続的ログ内に、前記第１読み出しと前記第１持続的ログ内に記録されている書き込みの第１部分集合との間の読み出し書き込み競合に関して前記第１書き込みはコミット可能であることを示す、前記第１書き込みに対応する第１条件付きコミットレコードを格納することであって、前記第１条件付きコミットレコードは前記第１複数パーティショントランザクションに関するメタデータを含む、前記第１書き込みに対応する前記第１条件付きコミットレコードを格納することと、
前記第２ＬＴＭの第２持続的ログ内に、前記第２読み出しと前記第２持続的ログ内に記録されている書き込みの第２部分集合との間の読み出し書き込み競合に関して前記第２書き込みはコミット可能であることを示す、前記第２書き込みに対応する第２条件付きコミットレコードを格納することであって、前記第２条件付きコミットレコードは前記第１複数パーティショントランザクションに関する前記メタデータを含む、前記第２書き込みに対応する前記第２条件付きコミットレコードを格納することと、
（ａ）前記第１条件付きコミットレコードが格納され、かつ（ｂ）前記第２条件付きコミットレコードが格納されたことの特定に応じて、前記クライアント側コンポーネントにより、前記第１複数パーティショントランザクションに対応する第１無条件コミットレコードを、複数パーティションコミット判定レポジトリ（ＭＣＤＲ）に格納することと、
（ａ）前記第１条件付きコミットレコードに含まれる前記第１複数パーティショントランザクションに関する前記メタデータの調査と、（ｂ）前記第１無条件コミットレコードの調査と、に応じて、前記格納グループの特定パーティションに対応付けられた第１書き込みアプライヤにより、前記特定パーティションに対し前記第１書き込みを伝播することと、
を実行するように構成される、前記システム。
【０２１０】
２．前記１つまたは複数のコンピューティングデバイスはさらに、
前記第１ＬＴＭにて、別の複数パーティショントランザクションの第３書き込みに対する第３コミット要求を受信することであって、前記第３書き込みは前記第１パーティションを対象とし、前記第３コミット要求は前記別の複数パーティショントランザクションのタイムアウトの表現を含む、前記別の複数パーティショントランザクションの前記第３書き込みに対する前記第３コミット要求を受信することと、
前記第１持続的ログ内に、読み出し書き込み競合に関して前記第３書き込みがコミット可能であることを示す、前記第３書き込みに対応する第３条件付きコミットレコードを格納することと、
前記タイムアウトの経過後、前記別の複数パーティショントランザクションに対応する第２無条件コミットレコードが前記ＭＣＤＲに格納されていないことを検出することと、
前記第１パーティションに対する前記第３書き込みの伝播は実施しないことを決定することと、
を実行するように構成される、条項１に記載のシステム。
【０２１１】
３．前記第１コミット要求は前記ＭＣＤＲの指示を含み、前記第１複数パーティショントランザクションに関する前記メタデータは前記ＭＣＤＲの前記指示を含む、条項１に記載のシステム。
【０２１２】
４．前記１つまたは複数のコンピューティングデバイスはさらに、
前記第１コミット要求の前に、前記格納グループに対する１つまたは複数の種類の動作の目標性能レベルの指示を受信し、
（ａ）前記格納グループのために確立すべきＬＴＭの数、（ｂ）前記格納グループのために確立すべきＭＣＤＲの数、または（ｃ）前記格納グループのために確立すべき書き込みアプライヤの数、以上のうちの１つまたは複数を、前記目標性能レベルの前記指示に少なくとも部分的に基づいて決定する、
ように構成される、条項１に記載のシステム。
【０２１３】
５．前記第１パーティションは前記格納グループのマスタパーティションに指定され、前記第１持続的ログは第１サーバの１つまたは複数の格納デバイスの少なくとも第１部分を備え、前記ＭＣＤＲは前記第１サーバの前記１つまたは複数の格納デバイスの少なくとも第２部分を備える、条項１に記載のシステム。
【０２１４】
６．１つまたは複数のコンピューティングデバイスにより、
格納グループの第１ログベーストランザクションマネジャー（ＬＴＭ）の第１持続的ログ内に、前記第１ＬＴＭにより行われた第１競合検出分析に少なくとも部分的に基づいて第１書き込みがコミット可能であると指定されたことを示す、第１複数パーティショントランザクションの前記第１書き込みに対応する第１条件付きコミットレコードを格納することと、
前記格納グループの第２ＬＴＭの第２持続的ログ内に、前記第２ＬＴＭにより行われた第２競合検出分析に少なくとも部分的に基づいて第２書き込みがコミット可能であると指定されたことを示す、前記第１複数パーティショントランザクションの前記第２書き込みに対応する第２条件付きコミットレコードを格納することと、
前記第１及び第２書き込みがコミット可能であると指定されたことの検出に応じて、前記第１複数パーティショントランザクションに対応する第１無条件コミットレコードを格納することと、
（ａ）前記第１条件付きコミットレコードの調査と、（ｂ）前記第１無条件コミットレコードの調査と、に応じて、第１書き込みアプライヤにより前記格納グループの特定パーティションに対し前記第１書き込みを伝播することと、
を含む方法。
【０２１５】
７．前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記第１ＬＴＭにて、別の複数パーティショントランザクションの別の書き込みに対するコミット要求を受信することであって、前記別の書き込みは前記第１パーティションを対象とし、前記コミット要求は前記別の複数パーティショントランザクションのタイムアウトの表現を含む、前記別の複数パーティショントランザクションの前記別の書き込みに対する前記コミット要求を受信することと、
前記第１持続的ログ内に、前記第１ＬＴＭにより行われた第３競合検出分析に少なくとも部分的に基づいて前記別の書き込みがコミット可能であることを示す、前記別の書き込みに対応する第３条件付きコミットレコードを格納することと、
前記タイムアウトの経過後、前記別の複数パーティショントランザクションに対応する第２無条件コミットレコードが複数パーティションコミット判定レポジトリ（ＭＣＤＲ）に格納されていないことを検出することと、
前記第１パーティションに対する前記別の書き込みの伝播は実施しないことを決定することと、
を含む条項６に記載の方法。
【０２１６】
８．前記ＭＣＤＲは単調に増加する論理タイムスタンプ値を提供する関連論理クロックを有し、前記タイムアウトは前記論理クロックから取得が見込まれる特定の将来論理タイムスタンプ値を含む、条項７に記載の方法。
【０２１７】
９．前記第１書き込みに対する第１コミット要求に応じて前記第１条件付きコミットレコードは格納され、前記第２書き込みに対する第２コミット要求に応じて前記第２条件付きコミット要求は格納され、前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記第１ＬＴＭにて、第２複数パーティショントランザクションの第３書き込みに対する第３コミット要求を受信することであって、前記第３書き込みは前記第１パーティションを対象とする第３読み出しの結果に依存する、前記第２複数パーティショントランザクションの前記第３書き込みに対する前記第３コミット要求を受信することと、
前記第２ＬＴＭにて、前記第２複数パーティショントランザクションの第４書き込みに対する第４コミット要求を受信することであって、前記第４書き込みは前記第２パーティションを対象とする第４読み出しの結果に依存する、前記第２複数パーティショントランザクションの前記第４書き込みに対する前記第４コミット要求を受信することと、
前記第１持続的ログ内に、前記第１ＬＴＭにより行われた第３競合検出分析に少なくとも部分的に基づいて前記第３書き込みがコミット可能であることを示す、前記第３書き込みに対応する第３条件付きコミットレコードを格納することと、
前記第２ＬＴＭにより検出された特定の競合に少なくとも部分的に基づいて、前記第２ＬＴＭにより前記第４コミット要求は拒否されたことを特定することと、
前記第４コミット要求が拒否されたことの前記開示に応じて、前記第３書き込みの伝播を破棄することと、
を含む請求項６に記載の方法。
【０２１８】
１０．前記第１ＬＴＭにて前記格納グループのクライアント側コンポーネントから受信された第１コミット要求に応じて前記第１条件付きコミットレコードは格納され、前記第１無条件コミットレコードの前記格納は前記クライアント側コンポーネントにより行われる、条項６に記載の方法。
【０２１９】
１１．前記第１コミット要求は、前記第１無条件コミットレコードが格納されるＭＣＤＲの指示を含む、条項１０に記載の方法。
【０２２０】
１２．前記第１コミット要求は第１読み出しの開示を含み、前記第１書き込みは前記第１読み出しの結果に依存し、前記第１読み出しの前記開示は前記第１ＬＴＭにより前記第１競合検出分析を行うために使用される、条項１０に記載の方法。
【０２２１】
１３．前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記格納グループに対する１つまたは複数の種類の動作の目標性能レベルの指示を受信することと、
（ａ）前記格納グループのために確立すべきＬＴＭの数、（ｂ）前記格納グループのために確立すべき複数パーティションコミット判定レポジトリの数、または（ｃ）前記格納グループのために確立すべき書き込みアプライヤの数、以上のうちの１つまたは複数を、前記目標性能レベルの前記指示に少なくとも部分的に基づいて決定することと、
を含む条項６に記載の方法。
【０２２２】
１４．前記第１パーティションは前記格納グループのマスタパーティションに指定され、前記第１持続的ログは第１サーバの１つまたは複数の格納デバイスの少なくとも第１部分を備え、前記第１無条件コミットレコードは前記１つまたは複数の格納デバイスのうちの特定格納デバイスに格納される、条項６に記載の方法。
【０２２３】
１５．前記第１無条件コミットレコードは、第１ノード及び第２ノードを含む複製有向非巡回グラフの複数のノードを備える複数パーティションコミット判定レポジトリ（ＭＣＤＲ）に格納され、前記第１無条件コミットレコードの前記格納は、前記第１ノード及び前記第２ノードに前記第１無条件コミットレコードのそれぞれのレプリカを格納することを含む、条項６に記載の方法。
【０２２４】
１６．プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって、前記プログラム命令は１つまたは複数のプロセッサ上で実行されると、格納グループのクライアント側コンポーネントを実行し、前記クライアント側コンポーネントは、
格納グループの第１ログベーストランザクションマネジャー（ＬＴＭ）へ、第１複数パーティショントランザクションの第１書き込みに対する第１コミット要求を送信することであって、前記第１コミット要求は前記第１書き込みが依存する第１読み出しの開示を含み、前記第１読み出しは前記格納グループの第１パーティションを対象とした、前記第１複数パーティショントランザクションの前記第１書き込みに対する前記第１コミット要求を送信することと、
前記格納グループの第２ログベーストランザクションマネジャー（ＬＴＭ）へ、第１複数パーティショントランザクションの第２書き込みに対する第２コミット要求を送信することであって、前記第２コミット要求は前記第２書き込みが依存する第２読み出しの開示を含み、前記第２読み出しは前記格納グループの第２パーティションを対象とした、前記第１複数パーティショントランザクションの前記第２書き込みに対する前記第２コミット要求を送信することと、
（ａ）第１コミット分析に少なくとも部分的に基づいて前記第１ＬＴＭにより前記第１書き込みはコミット可能であると指定され、かつ（ｂ）第２コミット分析に少なくとも部分的に基づいて前記第２ＬＴＭにより前記第２書き込みはコミット可能であると指定されたことの特定に応じて、前記第１複数パーティショントランザクションに対応する第１無条件コミットレコードを選択位置に格納することと、
を実行するように構成される、前記非一時的コンピュータアクセス可能記憶媒体。
【０２２５】
１７．前記第１コミット要求は、（ａ）前記選択位置の指示、または（ｂ）前記第１複数パーティショントランザクションのコミットタイムアウト、以上のうちの１つまたは複数を含む、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２２６】
１８．前記クライアント側コンポーネントはさらに、
前記第１ＬＴＭにより別の複数パーティショントランザクションの少なくとも１つの書き込みがコミット不可能であると指定されたことの特定に応じて、前記別の複数パーティショントランザクションに対応するアボートレコードを別の選択位置に格納する、
ように構成される、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２２７】
１９．プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって、前記プログラム命令は１つまたは複数のプロセッサ上で実行されると、格納グループの書き込みアプライヤを実行し、前記書き込みアプライヤは、
前記格納グループのログベーストランザクションマネジャーにより持続的ログ内に格納された特定レコードが、前記格納グループの第１パーティションを対象とする第１書き込みの条件付きコミットを表すことを特定し、
第１パーティションを対象とする１つまたは複数の書き込みを含む複数パーティショントランザクションの無条件コミットレコードを格納するように指定されたコミット判定レポジトリを特定し、
前記第１書き込みを含む第１複数パーティショントランザクションの無条件コミットレコードを前記コミット判定レポジトリが含むことの特定に応じて、前記格納グループの前記第１パーティションに対し前記第１書き込みを伝播する、
ように構成される、前記非一時的コンピュータアクセス可能記憶媒体。
【０２２８】
２０．前記書き込みアプライヤは、
第２複数パーティショントランザクションの一部であり、前記第１パーティションを対象とする第２書き込みの条件付きコミットを、前記持続的ログ内に格納された第２レコードが表すことを特定し、
前記第２複数パーティショントランザクションに対応付けられたコミットタイムアウトを特定し、
前記タイムアウトの経過前に前記コミット判定レポジトリに前記第２複数パーティショントランザクションに対応する無条件コミットレコードが書き込まれていないことの検出に少なくとも部分的に基づいて、前記第１パーティションに対する前記第２書き込みの伝播を破棄する、
ように構成される、条項１９に記載の前記非一時的コンピュータアクセス可能記憶媒体。
【０２２９】
２１．前記書き込みアプライヤは、
前記持続的ログ内に格納された第２レコードが、前記第１パーティションを対象とする第２書き込みの無条件コミットを表すことを特定し、
前記コミット判定レポジトリを調べることなく、前記第１パーティションに対し前記第２書き込みを伝播する、
ように構成される、条項１９に記載の前記非一時的コンピュータアクセス可能記憶媒体。
【０２３０】
さらに、前述の内容は、以下の追加条項を考慮することでより理解され得る。
１．１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記１つまたは複数のコンピューティングデバイスは、
第１データストア及び第２データストアを含む複数のデータストアを備える異種格納グループのクライアント側コンポーネントにて、前記第１データストアを対象とする第１読み出しに対応する第１読み出し記述子を含む、１つまたは複数の読み出しに対応するそれぞれの読み出し記述子を受信することであって、前記第１読み出し記述子は前記第１データストアにて適用されたステート遷移の開示を含み、前記第１データストアは、ステートレスプロトコルに従って、前記第１読み出し記述子が前記クライアント側コンポーネントに提供された後に前記クライアント側コンポーネントに関するセッションメタデータを保持しない、前記１つまたは複数の読み出しに対応する前記それぞれの読み出し記述子を受信することと、
前記クライアント側コンポーネントがアクセス可能な１つまたは複数のバッファに、前記異種格納グループの特定データストアを対象とする第１書き込みの第１書き込み記述子を含む、１つまたは複数の書き込みのそれぞれの書き込み記述子を格納することであって、前記第１書き込みのペイロードは前記第１読み出しの結果に少なくとも部分的に基づき、前記第１書き込み記述子は前記特定データストアにて変更するオブジェクトを示す、前記１つまたは複数の書き込みの前記それぞれの書き込み記述子を格納することと、
前記クライアント側コンポーネントにて、前記１つまたは複数の書き込みを含む候補トランザクションに対するコミット要求を生成することであって、前記コミット要求は少なくとも前記第１読み出し記述子と前記第１書き込み記述子とを含む、前記１つまたは複数の書き込みを含む前記候補トランザクションに対する前記コミット要求を生成することと、
前記クライアント側コンポーネントからトランザクションマネジャーに対し、前記コミット要求を送信することと、
前記トランザクションマネジャーにて、並行処理制御プロトコルに従った前記第１読み出し記述子の分析に少なくとも部分的に基づいて、前記候補トランザクションがコミットのために受諾されることを決定することと、
前記第１書き込み記述子内に示される前記オブジェクトの変更を開始することと、
を実行するように構成される、前記システム。
【０２３１】
２．前記クライアント側コンポーネントは、プロバイダネットワークにて実施される格納サービスの要求ハンドラノードを実行するプロセスを有する、条項１に記載のシステム。
【０２３２】
３．前記第１読み出し記述子は、少なくとも前記第１読み出しの読み出し再現性検証メタデータを含む、条項１に記載のシステム。
【０２３３】
４．前記コミット要求は前記第２データストアを対象とする第２読み出しに対応する第２読み出し記述子を含み、前記１つまたは複数の書き込みのうち少なくとも１つの書き込みのペイロードは前記第２読み出しの結果に少なくとも部分的に基づく、条項１に記載のシステム。
【０２３４】
５．前記１つまたは複数の書き込みは、前記特定データストアとは異なるデータストアを対象とする第２書き込みを含む、条項１に記載のシステム。
【０２３５】
６．１つまたは複数のコンピューティングデバイスにより、
第１データストアを含む１つまたは複数のデータストアを備える格納グループのクライアント側コンポーネントにて、前記第１データストアを対象とする第１読み出しに対応する第１読み出し記述子を含む、１つまたは複数の読み出しに対応するそれぞれの読み出し記述子を受信することであって、前記第１読み出し記述子は前記第１データストアにて適用されたステート遷移の開示を含む、前記１つまたは複数の読み出しに対応する前記それぞれの読み出し記述子を受信することと、
前記クライアント側コンポーネントにて、前記１つまたは複数のデータストアのうちの特定データストアを対象とする第１書き込みの第１書き込み記述子を含む、１つまたは複数の書き込みのそれぞれの書き込み記述子を生成することであって、前記第１書き込みのペイロードは前記第１読み出しの結果に少なくとも部分的に基づき、前記第１書き込み記述子は前記特定データストアにて変更するオブジェクトを示す、前記１つまたは複数の書き込みの前記それぞれの書き込み記述子を生成することと、
前記クライアント側コンポーネントからトランザクションマネジャーに対し、前記第１書き込みを含む１つまたは複数の書き込みを有する候補トランザクションに対するコミット要求を送信することであって、前記コミット要求は少なくとも前記第１読み出し記述子と前記第１書き込み記述子とを含む、前記１つまたは複数の書き込みを有する前記候補トランザクションに対する前記コミット要求を送信することと、
前記トランザクションマネジャーにて、前記第１読み出し記述子の分析に少なくとも部分的に基づいて、前記候補トランザクションがコミットのために受諾されることを決定することと
を含む方法。
【０２３６】
７．ステートレスプロトコルに従って前記第１データストアは、前記第１読み出し記述子が前記クライアント側コンポーネントに提供された後、前記第１読み出しに関するセッションメタデータを保持しない、条項６に記載の方法。
【０２３７】
８．前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記トランザクションマネジャーの持続的ログに、前記候補トランザクションがコミットのために受諾されたことを示すトランザクションレコードを格納することを含み、
前記候補トランザクションがコミットのために受諾されることの前記決定は、前記持続的ログに格納された１つまたは複数の他のトランザクションレコードの分析に少なくとも部分的に基づく、
条項６に記載の方法。
【０２３８】
９．前記持続的ログは複製グラフの複数のノードを使用して実施される、条項８に記載の方法。
【０２３９】
１０．前記候補トランザクションがコミットのために受諾されることの前記決定は、前記読み出し記述子が生成されてから前記第１読み出しの結果集合は変更されていないことを確認することを含む、条項６に記載の方法。
【０２４０】
１１．前記特定ステート遷移の前記開示は、論理タイムスタンプを含む、条項６に記載の方法。
【０２４１】
１２．前記第１読み出し記述子は、少なくとも前記第１読み出しの読み出し再現性検証メタデータを含む、条項６に記載の方法。
【０２４２】
１３．前記１つまたは複数のデータストアは第２データストアを有し、前記第１データストアは第１データモデルを実施し、前記第２データストアは別のデータモデルを実施し、前記コミット要求は前記第２データストアを対象とする第２読み出しに対応する第２読み出し記述子を含み、前記１つまたは複数の書き込みのうち少なくとも１つの書き込みのペイロードは前記第２読み出しの結果に少なくとも部分的に基づく、条項６に記載の方法。
【０２４３】
１４．前記第１データストアは、非リレーショナルデータベースシステム、リレーショナルデータベースシステム、非構造化データオブジェクトへのアクセスを可能にするウェブサービスインターフェースを実施する格納サービス、インメモリデータベース、分散キャッシュのインスタンス、待ち行列サービスのコンポーネント、または通知サービスのコンポーネント、以上のうちの１つを含む、条項１２に記載の方法。
【０２４４】
１５．前記第１データストアは複数の書き込みを含むトランザクションの原子性に対応しない、条項６に記載の方法。
【０２４５】
１６．プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって、前記プログラム命令が１つまたは複数のプロセッサにおいて実行されると、前記１つまたは複数のプロセッサは、
第１データストアを含む１つまたは複数のデータストアを備える格納グループのクライアント側コンポーネントにて、前記第１データストアを対象とする第１読み出しに対応する第１読み出し記述子を含む、１つまたは複数の読み出しに対応するそれぞれの読み出し記述子を受信することであって、前記第１読み出し記述子は前記第１データストアにて適用されたステート遷移の開示を含む、前記１つまたは複数の読み出しに対応する前記それぞれの読み出し記述子を受信することと、
前記クライアント側コンポーネントにて、前記１つまたは複数のデータストアのうちの特定データストアを対象とする第１書き込みの第１書き込み記述子を含む、１つまたは複数の書き込みのそれぞれの書き込み記述子を生成することであって、前記第１書き込みのペイロードは前記第１読み出しの結果に少なくとも部分的に基づき、前記第１書き込み記述子は前記特定データストアにて変更するオブジェクトを示す、前記１つまたは複数の書き込みの前記それぞれの書き込み記述子を生成することと、
前記クライアント側コンポーネントからトランザクションマネジャーに対し、前記第１書き込みを含む１つまたは複数の書き込みを有する候補トランザクションに対するコミット要求を送信することであって、前記コミット要求は少なくとも前記第１読み出し記述子と前記第１書き込み記述子とを含む、前記１つまたは複数の書き込みを有する前記候補トランザクションに対する前記コミット要求を送信することと
を実行する、前記非一時的コンピュータアクセス可能記憶媒体。
【０２４６】
１７．ステートレスプロトコルに従って前記第１データストアは、前記第１読み出しに関するセッションメタデータを保持しない、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２４７】
１８．前記第１読み出し記述子は、少なくとも前記第１読み出しの読み出し再現性検証メタデータを含む、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２４８】
１９．前記１つまたは複数のデータストアは第２データストアを有し、前記第１データストアは第１データモデルを実施し、前記第２データストアは別のデータモデルを実施し、前記コミット要求は前記第２データストアを対象とする第２読み出しに対応する第２読み出し記述子を含み、前記１つまたは複数の書き込みのうち少なくとも１つの書き込みのペイロードは前記第２読み出しの結果に少なくとも部分的に基づく、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２４９】
２０．前記第１データストアは複数の書き込みを含むトランザクションの原子性に対応しない、条項１６に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２５０】
さらに、前述の内容は、以下の追加条項を考慮することでより理解され得る。
１．１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記１つまたは複数のコンピューティングデバイスは、
異種格納グループの複数のデータストアの第１データストアを対象とする第１読み出し要求を受信することであって、前記第１読み出し要求は第１結果集合を特定するために使用する第１フィルタ基準を含む、前記第１読み出し要求を受信することと、
特定ステート遷移のインジケータを確定することであって、前記特定ステート遷移は、前記第１結果集合の特定の前に前記第１データストアに適用された１つまたは複数の変更を含む、前記特定ステート遷移の前記インジケータを確定することと、
前記第１フィルタ基準を使用して前記第１結果集合を特定することと、
（ａ）前記特定ステート遷移の前記インジケータと、（ｂ）前記第１読み出し要求が再現可能な読み出しを表すか否かを判定するために利用可能な読み出し再現性検証メタデータ（ＲＲＶＭ）と、を含む読み出し記述子を生成することと、
前記第１結果集合と前記読み出し記述子の表現とを、前記異種格納グループのクライアント側コンポーネントへ送信することと、
前記読み出し記述子の分析に少なくとも部分的に基づいて、前記第１読み出し要求に続く前記異種格納グループの特定データストアを対象とする書き込み要求が受諾基準を満たすと判定することと、
を実行するように構成される、前記システム。
【０２５１】
２．前記ＲＲＶＭは前記第１フィルタ基準の表現を含む、条項１に記載のシステム。
【０２５２】
３．前記ＲＲＶＭは前記第１結果集合に含まれるデータオブジェクトのアドレスに少なくとも部分的に基づく、条項１に記載のシステム。
【０２５３】
４．前記読み出し記述子の前記表現は、前記読み出し記述子の難読化版を含む、条項１に記載のシステム。
【０２５４】
５．１つまたは複数のコンピューティングデバイスにより、
第１データストアを対象とする第１読み出し要求を受信することと、
特定ステート遷移のインジケータを確定することであって、前記特定ステート遷移は、前記第１読み出し要求の第１結果集合の特定の前に前記第１データストアに適用された１つまたは複数の変更を含む、前記特定ステート遷移の前記インジケータを確定することと、
（ａ）前記特定ステート遷移の前記インジケータと、（ｂ）前記第１読み出し要求が再現可能な読み出しを表すか否かを判定するために利用可能な読み出し再現性検証メタデータ（ＲＲＶＭ）と、を含む読み出し記述子を生成することと、
前記第１読み出し要求に応じて、少なくとも前記読み出し記述子の表現と前記第１結果集合とを特定送信先へ送信することと、
を含む方法。
【０２５５】
６．前記ＲＲＶＭは、前記読み出し要求内に示される選択基準の表現を含む、条項５に記載の方法。
【０２５６】
７．前記ＲＲＶＭは、前記第１読み出し要求の再現が前記第１結果集合とは異なる結果集合を生じるか否かを判定するために呼び出す関数の表現を含む、条項５に記載の方法。
【０２５７】
８．前記ＲＲＶＭは、前記第１結果集合に含まれるデータオブジェクトのアドレスに少なくとも部分的に基づく、条項５に記載の方法。
【０２５８】
９．前記ＲＲＶＭは、前記第１結果集合に含まれるデータオブジェクトの前記アドレスに適用された選択ハッシュ関数の出力を含む、条項５に記載の方法。
【０２５９】
１０．前記特定ステート遷移の前記開示は、論理タイムスタンプを含む、条項５に記載の方法。
【０２６０】
１１．前記読み出し記述子は、前記第１結果集合のデータオブジェクトの最終変更時間の開示を含む、条項５に記載の方法。
【０２６１】
１２．前記読み出し記述子は前記第１データストアのテーブルの最終変更時間の開示を含み、前記テーブルは前記第１結果集合の１つまたは複数のデータオブジェクトを含む、条項５に記載の方法。
【０２６２】
１３．前記読み出し記述子の前記表現は、前記読み出し記述子の難読化版を含む、条項５に記載の方法。
【０２６３】
１４．前記１つまたは複数のコンピューティングデバイスにより、さらに、
前記読み出し記述子の前記表現に組み込むパディングバイト数を決定することであって、前記決定は乱数演算を使用することを含む、前記読み出し記述子の前記表現に組み込む前記パディングバイト数を決定することと、
前記読み出し記述子の前記表現の前記送信の前に、前記読み出し記述子の前記表現内に前記パディングバイト数を組み込むことと、
を含む条項５に記載の方法。
【０２６４】
１５．プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって、前記プログラム命令が１つまたは複数のプロセッサにおいて実行されると、前記１つまたは複数のプロセッサは、
格納グループの第１データストアに対する読み出し要求に応じて、前記読み出し要求の第１結果集合の生成の前に前記第１データストアにて適用された変更に対応する特定ステート遷移のインジケータを確定し、
（ａ）前記特定ステート遷移の開示と、（ｂ）前記第１読み出し要求が再現可能な読み出しを表すか否かを判定するために利用可能な読み出し再現性検証メタデータ（ＲＲＶＭ）と、を含む読み出し記述子を生成し、
前記格納グループのクライアント側コンポーネントに対し、前記読み出し記述子と、前記第１結果集合との送信を開始する、
前記非一時的コンピュータアクセス可能記憶媒体。
【０２６５】
１６．前記ＲＲＶＭは、前記読み出し要求内に示される選択基準の表現を含む、条項１５に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２６６】
１７．前記ＲＲＶＭは、前記読み出し要求の再現が前記第１結果集合とは異なる結果集合を生じるか否かを判定するために呼び出す関数の表現を含む、条項１５に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２６７】
１８．前記ＲＲＶＭは、前記第１結果集合に含まれるデータオブジェクトのアドレスに少なくとも部分的に基づく、条項１５に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２６８】
１９．前記特定ステート遷移の前記開示は、論理タイムスタンプを含む、条項１５に記載の非一時的コンピュータアクセス可能記憶媒体。
【０２６９】
結論
様々な実施形態はさらに、コンピュータアクセス可能媒体に関する前述の説明に従って実行される命令及び／またはデータの受信、送信、または格納処理を含み得る。一般に、コンピュータアクセス可能媒体は、例えばディスクまたはＤＶＤ／ＣＤ‐ＲＯＭ、ＲＡＭ（例えばＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発性または不揮発性媒体といった、磁気または光学式媒体等の記憶媒体またはメモリ媒体、並びに、ネットワーク及び／または無線リンク等の通信媒体を介して伝達される伝送媒体または電気、電磁、もしくはデジタル信号等の信号を含み得る。
【０２７０】
本明細書において図示及び説明される様々な方法は、方法の例示的実施形態を表す。方法は、ソフトウェア、ハードウェア、またはこれらの組み合せで実施され得る。方法の順序は変更され、そして様々な要素が追加、並替、結合、省略、変更等され得る。
【０２７１】
本開示の恩恵を受ける当業者には明らかであるように、様々な修正及び変更を行うことが可能である。本明細書には全てのこのような修正及び変更を包含する意図があり、従って前述の説明も制限的な意味ではなく例示的な意味で考慮されるものとする。
【図１】
0006346376.tif 000002
【図２ａ】
0006346376.tif 000003
【図２ｂ】
0006346376.tif 000004
【図２ｃ】
0006346376.tif 000005
【図２ｄ】
0006346376.tif 000006
【図２ｅ】
0006346376.tif 000007
【図２ｆ】
0006346376.tif 000008
【図２ｇ】
0006346376.tif 000009
【図２ｈ】
0006346376.tif 000010
【図３】
0006346376.tif 000011
【図４】
0006346376.tif 000012
【図５】
0006346376.tif 000013
【図６】
0006346376.tif 000014
【図７】
0006346376.tif 000015
【図８】
0006346376.tif 000016
【図９】
0006346376.tif 000017
【図１０】
0006346376.tif 000018
【図１１ａ】
0006346376.tif 000019
【図１１ｂ】
0006346376.tif 000020
【図１１ｃ】
0006346376.tif 000021
【図１１ｄ】
0006346376.tif 000022
【図１１ｅ】
0006346376.tif 000023
【図１１ｆ】
0006346376.tif 000024
【図１１ｇ】
0006346376.tif 000025
【図１１ｈ】
0006346376.tif 000026
【図１２】
0006346376.tif 000027
【図１３】
0006346376.tif 000028
【図１４】
0006346376.tif 000029
【図１５】
0006346376.tif 000030
【図１６】
0006346376.tif 000031
【図１７】
0006346376.tif 000032
【図１８】
0006346376.tif 000033
【図１９】
0006346376.tif 000034
【図２０】
0006346376.tif 000035
【図２１】
0006346376.tif 000036
【図２２】
0006346376.tif 000037
【図２３】
0006346376.tif 000038
【図２４】
0006346376.tif 000039
【図２５】
0006346376.tif 000040
【図２６】
0006346376.tif 000041
【図２７】
0006346376.tif 000042
【図２８】
0006346376.tif 000043
【図２９】
0006346376.tif 000044
【図３０】
0006346376.tif 000045
【図３１】
0006346376.tif 000046
【図３２】
0006346376.tif 000047
【図３３】
0006346376.tif 000048
【図３４】
0006346376.tif 000049
【図３５】
0006346376.tif 000050
【図３６】
0006346376.tif 000051
【図３７】
0006346376.tif 000052
【図３８】
0006346376.tif 000053
【図３９】
0006346376.tif 000054
【図４０】
0006346376.tif 000055
【図４１】
0006346376.tif 000056
【図４２】
0006346376.tif 000057
【図４３】
0006346376.tif 000058
【図４４ａ】
0006346376.tif 000059
【図４４ｂ】
0006346376.tif 000060
【図４５】
0006346376.tif 000061
【図４６】
0006346376.tif 000062
【図４７】
0006346376.tif 000063