JP2022521412A - 分散システムにおける非同期ストレージ管理 - Google Patents

Abstract

いくつかの例では、システムは、ストレージにおけるデータの格納に関係する格納動作のためのユーザ要求をユーザ装置から受信してもよく。更新は、格納動作の性能を示す応答をユーザ装置へ送信することに先立って、格納動作を維持するために更新キューへ追加されてもよい。例えば、更新を更新キューへ追加することは、格納動作のタイプを規定すること及び／又は格納動作により達成される状態に基づき、更新が更新キューへ追加されるようにするための要求を送信することを含んでもよい。加えて、更新に関する情報は、更新を他のプロセッサにより管理される別の更新キューへ追加するために別のプロセッサへ送信されてもよい。その後、更新は更新キューから取得され、そして格納動作を行うために処理されてもよい。

Description

本開示はデータストレージの技術分野に関する。

データオブジェクトは、データをオブジェクトとして管理するオブジェクトストレージアーキテクチャで格納されてもよい。格納されたデータの管理のための多くの動作は、コンピュータ的に高価であり得、そして直列に行われると、いくつかのアプリケーションに望ましい応答時間より長い応答時間をもたらし得る。特定のストレージ管理動作を非同期的に行うための従来の解決策は、各動作の正確さを保証するためにそれらの能力において制限され得る。例えば、従来の解決策はいくつかの動作が必要とし得る保証の十分な原子性を有していないことがある。加えて、一定期間後のオブジェクトの保持の期限切れなどのいくつかの動作は、本来非同期であり得る。したがって、複雑なデータ管理システムの高性能を可能にするために、効率的且つ信頼できる保護機構が望ましい。

本明細書におけるいくつかの実施形態は永続更新キューを含む。例えば、システムは、ストレージでのデータの格納に関係する格納動作についてのユーザ要求を、ユーザ装置から受信してもよい。格納動作の性能を示す応答をユーザ装置へ送信することに先立って、更新は、格納動作を維持するために更新キューへ追加されてもよい。例えば、更新を更新キューへ追加することは、格納動作のタイプを規定すること及び／又は格納動作により達成される状態に少なくとも基づき、更新を更新キューへ追加されるようにするための要求を送信することを含んでもよい。加えて、更新に関する情報は、他のプロセッサにより管理される別の更新キューへ更新を追加するために別のプロセッサへ送信され得る。その後、更新は更新キューから入手され、そして格納動作を行うために処理されてもよい。

詳細説明は添付図面を参照して記載される。図面では、参照番号の最も左の桁は参照番号が最初に出現する図を識別する。異なる図内の同じ参照番号の使用は同様又は同一なアイテム又は特徴を示す。

図１は、いくつかの実施形態に係るデータを格納することができるシステムのアーキテクチャ例を示す。

図２は、いくつかの実施形態に係る複数のサービス計算装置の構成例を示すブロック図である。

図３は、いくつかの実施形態係るエンキュー及び折り畳み更新動作の実行例を示すブロック図である。

図４は、いくつかの実施形態に係る高優先度動作によるエンキューの実行例を示すブロック図である。

図５は、いくつかの実施形態に係るワーク取得動作の実行例を示すブロック図である。

図６は、いくつかの実施形態に係るワーク取得動作の実行例を示すブロック図である。

図７は、いくつかの実施形態に係るデキュー動作の実行例を示すブロック図である。

図８は、いくつかの実施形態に係るリキュー動作の実行例を示すブロック図である。

図９は、いくつかの実施形態に係る進行中リスト動作の実行例を示すブロック図である。

図１０は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１１は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１２は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１３は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１４は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１５は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１６は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１７は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１８は、いくつかの実施形態に係る非同期管理プログラムの動作例を示すブロック図である。

図１９は、いくつかの実施形態による更新を管理するための永続更新キューを採用する処理を示す流れ図である。

本明細書におけるいくつかの実施形態は、ユーザ要求及び他のストレージ更新を維持する高可用性永続更新キュー（Ｄｕｒａｂｌｅ ｕｐｄａｔｅ Ｑｕｅｕｅ：ＤＵＱ）を含む分散コンピュータシステムのための技術及び配置へ向けられる。例えば、非同期管理プログラムは、ストレージ管理動作が正しい順番で且つ指示されたとおりに実行され且つ完了されることを保証するためにＤＵＱを管理するバックグラウンドサービスとして実行されてもよい。いくつかのケースでは、ＤＵＱに対する更新は、ユーザ要求の性能又は他のストレージイベントと同じトランザクションにおいて実行されてもよく、ＤＵＱを高効率且つ一貫したものにする。ＤＵＱの冗長性はラフト合意アルゴリズム又は他の好適な合意アルゴリズムを介してされてもよい。さらに、一例として、ＤＵＱはログ構造化マージツリー（ＬＳＭツリー）データ構造を使用して格納されてもよい。

いくつかの例では、効率化と安全性との両方を支援するために、本明細書における高可用性ＤＵＱは、非同期で処理される更新を格納するための冗長性により維持されてもよい。ＤＵＱの少なくとも３つの複製が存在してもよいので、コンピュータシステムは、ＤＵＱが格納されるストレージ装置の故障に耐えることができる。ＤＵＱは、任意の汎用の更新に関する情報を保持してもよく、任意のタイプの一般的方針又は動作のために採用されてもよい。ＤＵＱに対する更新は他の状態変更と同じトランザクション内で行われてもよい。これは、ユーザへ応答を返す前に更新がＤＵＱに維持されることを保証する。加えて、更新は依然として、ユーザに対する応答に続きコンピュータシステム内のさらなる処理を必要としてもよい。

いくつかのケースでは、指標を変更するトランザクションもまた、別の指標に対し行わせる更新を引き起こしててもよい。したがって、他の指標に対する更新もＤＵＱへ追加されてもよい。一例として、ＤＵＱへ以前に追加された他の指標の更新が既に存在し、そしてこの更新が未だ処理されていなければ、ＤＵＱは、複数の更新を単一更新へ折り畳んでもよい。これらの複数の更新は、状態を含んでいる場合には、状態同士が一貫するように、２つの更新をマージする方法か個々に制御してもよい。その結果、本明細書における実施形態は、後の処理のために任意の更新を格納するための柔軟なシステムを含む。一貫性は、更新が失われる機会又は逆に更新がＤＵＱ内に記録される間に変更が失われる機会を低減又は削除するために、システムに対する変更の残りと同じトランザクションにおいてＤＵＱへ更新を追加することにより維持されてもよい。

いくつかの例では、非同期管理プログラムは、処理される更新のためのＤＵＱを定期的にポーリングしてもよい。非同期管理プログラムは、処理されるＤＵＱにおける更新を「進行中」としてマーキングすることによりこれらの更新を処理してもよく、そして、ワーカが次に処理するために、インメモリキューへ更新を内部的に追加してもよい。このワーカは、二次指標を更新すること、システムへメッセージを送信することなどの更新に関連するどんな変更も行ってもよい。更新が処理された後、ＤＵＱのサイズが絶えず成長しないように、ＤＵＱから更新がデキューされてもよい。

一例として、コンピュータシステムの一部分が、第１のユーザを含む環境内に配備され、且つ、第１のユーザが、システム内に数か月間保持される一組の映像を取り込むためにユーザアプリケーションを使用していると仮定する。さらに、その後、特定の基準に基づいて選択されたそれらの映像の部分が、それらへ適用される特定メタデータタグを有する必要があり、そして次にアーカイブのためにリモートサイトへ移動される必要があると仮定する。したがって、この例は特定のやり方に適用される一連の動作を説明する。さらに、この例における一連の動作はかなり複雑であるが、はるかに複雑な一連の動作が、本明細書におけるシステムの現実世界での実施形態においてしばしば適用されてもよい。

上述の例では、上記一連の動作を完了するために、データの全ライフサイクルを通じてシステムにより実行される高価な性質の複数の格納関連動作が存在する。一連の動作例を達成するために、映像群の各映像の取り込み時に映像群の保持を設定するための更新がＤＵＱ内へ挿入されてもよい。同様に、上記基準に基づいて指標付けジョブを開始するための更新もまたＤＵＱ内へ挿入されてもよい。次に、指標付けの結果は、メタデータタグに関連付けられる一組のオブジェクトを問い合わせるために使用されてもよい。メタデータタグの貼り付けの時点でタグ付きオブジェクトをアーカイブのためにリモートサイトへ移動するための動作を設定するために、別の更新がＤＵＱ内へ挿入されてもよい。

本明細書におけるＤＵＱの利点例は、ＤＵＱ内へ挿入される一連の更新が、以前に適用された動作の結果に基づきトリガされてもよいことである。別の例として、データを移動するための更新がＤＵＱへ追加された後、ＤＵＱの１つの複製が存在するシステム内のノードは機能停止する又はそうでなければ利用不能になると仮定する。ＤＵＱはシステム内の複数のノード上で冗長的に維持されてもよいので、上記例の処理は依然として、システム内の別のノード上に維持されたＤＵＱの冗長な複製を使用することにより指示されたように実行されてもよい。

したがって、本明細書における実施形態は、持続的ＤＵＱの使用により分散計算システム内の非同期更新を可能にする。本明細書においてＤＵＱへ追加される更新は、正確さを保証するために状態変更の残りの部分とはアトミックである。本明細書における技術は、更新が、ユーザ要求と同期的に行われた対応する変更と共存するかどうかの問題をなくす。更新は同期的変更の前にキューされなくてもよいので、恒久的に持続するＤＵＱ内の更新のいかなるリスクも無い。これは、ＤＵＱは、対応状態が同期的に追加されること無しには実行されないためである。加えて、更新は同期更新後にキューされてしまうことがないので、必要とされる更新の無い同期変更のいかなるリスクも無い。更新はＤＵＱから取り出されると直ちに安全に消費されてもよく、そして、対応状態変更が適用されてしまえば、更新がＤＵＱ内に無いいかなるリスクも無い。

論述目的のために、いくつかの例示的実施形態は、オブジェクト及び／又は他のデータ並びに関連メタデータの格納を管理するためのクラウドストレージシステムと通信する複数のサービス計算装置の環境において説明される。しかし、本明細書の開示に照らし当業者に明らかになるように、本明細書における実施形態は、提供される特定例へ制限されることはなく、そして他のタイプの計算システムアーキテクチャ、他のタイプのストレージ環境、他のタイプのユーザ構成、他のタイプのデータ等に拡張されてもよい。

図１はいくつかの実施形態に係るデータを格納することができるシステム１００のアーキテクチャ例を示す。システム１００は、例えば１つ又は複数のネットワーク１０６を介して少なくとも１つのストレージシステム１０４と通信することができる又はそうでなければそれと接続される複数のサービス計算装置１０２（１）～１０２（Ｎ）を含む。さらに、サービス計算装置１０２は、以下に追加的に論述されるように様々なタイプの計算装置のいずれかであってもよいユーザ装置１０８（１）、１０８（２）、．．．などの１つ又は複数のユーザ計算装置１０８とネットワーク１０６上で通信することができる。

いくつかの例では、サービス計算装置１０２は、任意数のやり方で具現化されてもよい１又は複数のサーバを含んでもよい。例えば、サービス計算装置１０２のプログラム、他の機能要素、及びデータストレージの少なくとも一部は、例えばサーバのクラスタ、サーバファーム、データセンター、クラウドホスト型コンピュータサービス等内の少なくとも１つのサーバ上に実装されてもよいが、他のコンピュータアーキテクチャが追加的に又は代替的に使用されてもよい。図示の例では、サービス計算装置１０２は、１又は複数のプロセッサ１１０、１又は複数のコンピュータ可読媒体１１２、及び１又は複数の通信インターフェース１１４を含む、又はそれらと関連付けられてもよい。

各プロセッサ１１０は、単一処理ユニット又は多数の処理ユニットであってもよく、単一又は複数の計算ユニット若しくは処理コアを含んでもよい。プロセッサ１１０は、１つ又は複数の中央処理ユニット、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、ステートマシン、論理回路系、及び／又は動作命令に基づいて信号を操作する任意の装置として実装されてもよい。一例として、プロセッサ１１０は、本明細書において説明されるアルゴリズム及び処理を実行するように特別にプログラムされた又は構成された任意の好適なタイプの１つ又は複数のハードウェアプロセッサ及び／又は論理回路を含んでもよい。プロセッサ１１０は、本明細書において説明される機能をプロセッサ１１０が実行するようにプログラムすることができるコンピュータ可読媒体１１２内に格納されるコンピュータ可読命令をフェッチ及び実行するように構成されてもよい。

コンピュータ可読媒体１１２は、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータなどの情報の格納のための任意のタイプの技術で実現される揮発性及び非揮発性メモリ並びに／又は着脱可能及び着脱不能媒体を含んでもよい。例えば、コンピュータ可読媒体１１２は、限定しないがＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、光学ストレージ、ソリッドステートストレージ、磁気テープ、磁気ディスクストレージ、ＲＡＩＤストレージシステム、ストレージアレイ、ネットワーク接続ストレージ、ストレージエリアネットワーク、クラウドストレージ、又は所望情報を格納するために使用でき、計算装置によりアクセスできる任意の他の媒体を含んでもよい。サービス計算装置１０２の構成に依存して、コンピュータ可読媒体１１２は、非一時的コンピュータ可読媒体がエネルギー、搬送波信号、電磁波、及び／又は信号それ自体などの媒体を排除すると述べる限りにおいて有形な非一時的媒体であってよい。いくつかのケースでは、コンピュータ可読媒体１１２は、サービス計算装置１０２と同じ位置に在ってもよく、一方、他の例では、コンピュータ可読媒体１１２はサービス計算装置１０２から部分的に離れていてもよい。例えば、いくつかのケースでは、コンピュータ可読媒体１１２はストレージシステム１０４内のストレージの一部を含んでもよい。

コンピュータ可読媒体１１２はプロセッサ１１０により実行可能である任意数の機能構成部を格納するために使用されてもよい。多くの実施形態では、これらの機能構成部は、プロセッサ１１０により実行可能である命令又はプログラムであって、実行されると本明細書でサービス計算装置１０２に帰する動作を行うようにプロセッサ１１０を特にプログラムする命令又はプログラムを含む。コンピュータ可読媒体１１２内に格納される機能構成部は、それぞれが１つ又は複数のコンピュータプログラム、アプリケーション、実行可能コード又はその一部を含んでもよいサーバプログラム１１６及びストレージプログラム１１８を含んでもよい。例えば、サーバプログラム１１６はユーザ装置１０８及びストレージシステム１０４と通信する機能を提供してもよい。

ストレージプログラム１１８は、非同期管理プログラム１２０を含んでもよく、そして、サービス計算装置１０２（１）～１０２（Ｎ）により格納され管理されるデータに関係するメタデータを含むメタデータデータ構造（ＤＳ：ｄａｔａ ｓｔｒｕｃｔｕｒｅ）１２２（１）～１２２（Ｎ）を生成し管理するためのデータベース管理機能をさらに含んでもよい。例えば、ストレージプログラム１１８は、ストレージプログラム１１８にファイルシステム、オブジェクト情報、データ管理情報、及びメタデータデータ構造１２２（１）～１２２（Ｎ）の一部としての他の情報を維持させるように構成された実行可能命令を含んでもよい。ストレージプログラム１１８はさらに、ユーザ情報１２６などのメタデータデータ構造１２２（１）～１２２（Ｎ）に含まれる他のタイプの情報を管理するための管理機能を実行してもよい。

非同期管理プログラム１２０は永続更新キュー（ＤＵＱ）１２４を管理及び維持してもよい。例えば、ＤＵＱ１２４は、以下に追加的に論述されるように、サービス計算装置１０２により格納されたデータに対する更新を管理するために使用されてもよい。コンピュータ可読媒体１１２に格納された追加機能構成部は、サービス計算装置１０２の様々な機能を制御及び管理するためのオペレーティングシステム（図１に示さず）を含んでもよい。いくつかのケースでは、機能構成部は、コンピュータ可読媒体１１２のストレージ部内に格納され、コンピュータ可読媒体１１２のローカルメモリ部内へロードされ、１つ又は複数のプロセッサ１１０により実行されてもよい。

加えて、コンピュータ可読媒体１１２は、本明細書において説明される機能及びサービスを実行するために使用されるデータ、データ構造及び他の情報を格納してもよい。例えば、コンピュータ可読媒体１１２はメタデータデータ構造１２２（１）～１２２（Ｎ）及びＤＵＱ１２４を格納してもよい。加えて、コンピュータ可読媒体１１２は、以下に追加的に論述されるように、本明細書において説明される機能のうちのいくつかを実行する際にストレージプログラム１１８により使用されるアプリケーションプログラムインターフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）情報１２６及び／又は非同期管理プログラム１２０を格納してもよい。さらに、コンピュータ可読媒体１１２は、例えば、ユーザ装置１０８などとの相互作用に基づく、各サービス計算装置１０２（１）～１０２（Ｎ）により格納されるデータであってもよいローカルデータ１２８（１）～１２８（Ｎ）を格納してもよい。

サービス計算装置１０２はまた、他の機能構成部及びデータを含み維持してもよく、機能構成部及びデータは、プログラム、ドライバなど、機能構成部により使用され、又は生成されるデータを含む。さらに、サービス計算装置１０２は多くの他の論理構成部、プログラム構成部、及び物理構成部を含んでもよく、上述のものは本明細書における論述に関連する単なる一例である。

１つ又は複数の通信インターフェース（Ｉ／Ｆ）１１４は、１つ又は複数のネットワーク１０６上などの様々な他の装置との通信を可能にするための１つ又は複数のソフトウェア及びハードウェア構成部を含んでもよい。したがって、通信インターフェース１１４は、ストレージシステム１０４、他のサービス計算装置１０２、及びユーザ装置１０８と通信するためのネットワーク１０６への接続を提供する１つ又は複数のポートを含んでもよいし又はそれと接続してもよい。例えば、通信インターフェース１１４は、本明細書の他のどこかで追加的に列挙されるようなＬＡＮ、インターネット、ケーブルネットワーク、セルラーネットワーク、無線ネットワーク（例えばＷｉ－Ｆｉ）及び有線ネットワーク（例えばファイバーチャネル、光ファイバ、イーサーネット（登録商標））、直接接続、並びにＢＬＵＥＴＯＯＴＨ（登録商標）などの近距離通信等のうちの１つ又は複数を介した通信を可能にしてもよい。

１つ又は複数のネットワーク１０６は、インターネットなどの広域ネットワーク；イントラネットなどのローカルエリアネットワーク（ＬＡＮ）；セルラーネットワーク、Ｗｉ－Ｆｉなどのローカル無線ネットワーク、及び／又はブルートゥース（登録商標）などの短距離無線通信などの無線ネットワーク；ファイバーチャネル、光ファイバ、イーサーネット、又は任意の他のこのようなネットワークを含む優先ネットワーク、直接有線接続、又はそれらの任意の組み合わせ含む任意の好適なネットワークを含んでもよい。したがって、１つ又は複数のネットワーク１０６は有線及び／又は無線通信技術の両方を含んでもよい。このような通信に使用される構成部はネットワークのタイプ、選択される環境、又はその両方に少なくとも部分的に依存し得る。このようなネットワーク上で通信するためのプロトコルは周知であり、したがって本明細書では詳細には論述されない。したがって、サービス計算装置１０２、ネットワークストレージシステム１０４、及びユーザ装置１０８は、有線又は無線接続部及びそれらの組み合わせを使用して１又は複数のネットワーク１０６上で通信することができる。

各ユーザ装置１０８は、デスクトップ、ラップトップ、タブレット計算装置、モバイル装置、スマートフォン、ウェアラブル装置、及び／又はネットワーク上でデータを送信することができる任意の他のタイプの計算装置などの任意の好適なタイプの計算装置であってよい。ユーザ１３０（１）、１３０（２）、．．．は、例えばそれぞれのユーザアカウント、ユーザログイン信用証明書などを介して、ユーザ装置１０８（１）、１０８（２）、．．．にそれぞれ関連付けられてもよい。さらに、ユーザ装置１０８は、１又は複数のネットワーク１０６を介し、別のネットワークを介し、又は任意の他の好適なタイプの通信接続を介してサービス計算装置１０２と通信することができてもよい。非常に多くの他の変形形態が本明細書の開示の利益を有する当業者に明らかになるであろう。

さらに、各ユーザ装置１０８（１）、１０８（２）、．．．、は、例えばネットワークストレージシステム１０４上の格納のためにユーザデータを送信するため、及び／又はネットワークストレージシステム１０４から格納データを受信するためのサーバプログラム１１６と通信するためのそれぞれのユーザ装置１０８（１）、１０８（２）、．．．上で実行してもよいユーザアプリケーション１３６（１）、１３６（２）、．．．、のそれぞれのインスタンスを含んでもよい。いくつかのケースでは、アプリケーション１３６はブラウザを含んでもよいし又はブラウザを介し動作してもよいが、他のケースでは、アプリケーション１３６は、１つ又は複数のネットワーク１０６上でのサーバプログラム１１６との通信を可能にする通信機能を有する任意の他のタイプのアプリケーションを含んでもよい。

ストレージシステム１０４は、１又は複数のストレージ計算装置１４０を含んでもよく、ストレージ計算装置は、サービス計算装置１０２に関し上に論述された例のうちの任意のものなどの１又は複数のサーバ又は任意の他の好適な計算装置を含んでもよい。ストレージコンピュータ装置１４０はそれぞれ、１又は複数のプロセッサ１４２、１又は複数のコンピュータ可読媒体１４４、及び１又は複数の通信インターフェース１４６を含んでもよい。例えば、プロセッサ１４２はプロセッサ１１０に関して上に論述された例のうちの任意のものに対応してもよく、コンピュータ可読媒体１４４は、コンピュータ可読媒体１１２に関して上に論述された例のうちの任意のものに対応してもよく、通信インターフェース１４６は通信インターフェース１１４に関して上に論述された例のうちの任意のものに対応してもよい。

加えて、コンピュータ可読媒体１４４は、ストレージシステム１０４内に含まれるストレージ１５０上のデータの格納を管理するための１又は複数のプロセッサ１４２により実行される機能構成部としてストレージプログラム１４８を含んでもよい。ストレージ１５０は、ストレージ装置１５６などの１又は複数のアレイ１５４上にデータを格納するためのストレージ１５０に関連する１又は複数のコントローラ１５２を含んでもよい。例えば、コントローラ１５２は、例えばアレイ１５４をＲＡＩＤ構成、ＪＢＯＤ構成などで構成するために、及び／又はストレージ装置１５６に基づく論理ユニットをストレージプログラム１４８へ提示するために、そして下位にある物理的ストレージ装置１５６上に格納されるクラウドデータ１５８のようなデータオブジェクト又は他のデータなどのデータを管理するためにアレイ１５４を制御してもよい。ストレージ装置１５６は、ハードディスクドライブ、ソリッドステートドライイブ、光ドライブ、磁気テープ、及びそれらの組み合わせ等々などの任意のタイプのストレージ装置であってもよい。いくつかの例では、ネットワークストレージシステム１０４は当該技術分野で知られているような商業的なクラウドストレージを含んでもよく、一方、他の例では、ネットワークストレージシステム１０４はサービス計算装置１０２に関連するエンティティだけによりアクセス可能な私的又は企業ストレージシステムを含んでもよい。

システム１００では、ユーザ１３０は、それぞれのユーザ装置１０８が通信状態に在るサービス計算装置１０２へデータを格納し、それからデータを受信してもよい。したがって、サービス計算装置１０２はユーザ１３０及びそれぞれのユーザ装置１０８のためのローカルストレージを提供してもよい。定常状態動作中、サービス計算装置１０２と定期的に通信するユーザ１０８が存在してもよい。加えて、サービス計算装置は、万一サービス計算装置１０２が故障した場合にメタデータデータ構造１２２の回復を可能にするために、メタデータデータ構造１２２をメタデータデータ構造バックアップ１６８としてネットワークストレージシステム１０４へ定期的にバックアップしてもよい。

いくつかのケースでは、サービス計算装置１０２は１又は複数のグループ、クラスタ、システム等へ配置されてもよい。例えば、いくつかの例では（図１に示さず）、サービス計算装置１０２は、第１のサービス計算装置１０２と第２のサービス計算装置１０２とが、格納及びデータ管理サービスを複数のユーザ装置１０８へ提供するための計算ノードを併せて形成するように、第１のサービス計算装置１０２が第２のサービス計算装置１０２へ接続されるようにペアとして配置されてもよい。例えば、少なくともメタデータデータ構造１２２を維持することに関し、第１のサービス計算装置１０２（１）が主計算装置として働いてもよく、一方で第２のサービス計算装置１０２（２）は副計算装置として働いてもよい。追加的に又はその代わりに、いくつかの例では、サービス計算装置１０２は、複製及び災害復旧を可能にするために地理的に分離され且つ離れた位置において複数のクラスタで配置されてもよい。無数の他の構成は本明細書の開示の利益を受ける当業者に明らかになる。

上述のように、いくつかのケースでは、複数のサービス計算装置１０２は、複数の位置におけるＤＵＱ１２４の管理のための及びＤＵＱ１２４の冗長性を提供するためのラフト構成で構成されてもよい。例えば、持続的ＤＵＱ１２４は、分散計算システム１００内で非同期更新が実行されることを可能にする。ＤＵＱ１２４へ追加される更新は、正確さを保証するために状態変更の残りの部分とはアトミックであってもよい。ＤＵＱ１２４の使用は、更新が、ユーザ要求と同期して行われた対応変更と共存することを保証する。さらに、同期的変更の前に更新はキューされないので、恒久的に持続するＤＵＱ内の更新のリスクも無い。これは、ＤＵＱは対応状態が同期的に追加されること無しには実行され得ないためである。加えて、同期的更新後に更新はキューされないので、予測される更新の無い同期変更のいかなるリスクも無い。更新はＤＵＱ１２４から取り出されると直ちに安全に消費されてもよく、そして、対応状態変更が適用されていれば、更新がＤＵＱ内に無いといういかなるリスクも無い。ＤＵＱ１２４の追加の特徴及び応用について以下に論述する。

図２はいくつかの実施形態に係る複数のサービス計算装置１０２の構成例２００を示すブロック図である。サービス計算装置１０２（１）～１０２（３）はいくつかの例ではＤＵＱ１２４を管理するためのラフト合意アルゴリズムを実行するように構成されてもよい。例えば、計算システムは、主ストレージとしてクラウドストレージ又は他のネットワークストレージを使用する分散オブジェクトストアとして配置され、いくつかの例では、計算システムは、オブジェクトを、ユーザにより生成されるバケット（図２に示さず）内にオブジェクトを格納してもよい。

図２の例では、ＤＵＱ１２４は、メタデータゲートウェイ２０２と呼ばれる非同期管理プログラム１２０により生成される処理の内部の他の状態と共に常在してもよい。したがって、各サービス計算装置１０２（１）～１０２（３）は、それぞれが、ＤＵＱ１２４及び他状態２０６（１）～２０６（３）を含む持続的状態２０４（１）～２０４（３）を有するそれぞれのメタデータゲートウェイ２０２（１）～２０２（３）を含んでもよい。メタデータゲートウェイ２０２は、それぞれのサービス計算装置１０２（１）～１０２（３）により行われるメタデータ関連動作を管理する。メタデータゲートウェイ２０２は、例えばサービス計算装置１０２がバケットを生成することなど特定のより高いレベル動作を実行するための呼び出しを行うことを可能にするＡＰＩ情報１２６から、１又は複数のＡＰＩを提供する、またはそれらにアクセスしてもよい。いくつかのケースでは、これらの動作を実行することは２つ以上の指標（図２に示さず）と相互作用することを必要とする。一例として、バケット生成動作は３つの指標と相互作用することを含んでもよい。したがって、副指標を更新することは、すべての更新が一貫した副指標を提供するために正しく実行されるということを保証するためのＤＵＱ１２４の使用を含んでもよい。加えて、ＤＵＱ１２４は、分散システム内の様々な維持タスクを実行すること、いくつかの基準を満たすオブジェクトを自動的に削除すること、並びに、いくつかの動作、条件などに対し実行され得る方針をユーザが定義することを許容することなどのユーザ定義動作を管理すること等の予定された対策を実行するために使用されてもよい。

上述のように、いくつかのケースでは、サービス計算装置１０２（１）～１０２（３）は、ＤＵＱ１２４の冗長性を提供するためにラフトグループとして動作するように構成されてもよい。例えば、非同期管理プログラム１２０は、複数のサービス計算装置１０２にわたるＤＵＱ１２４及び他状態２０６を含む持続的状態２０４の一貫性を維持するためにラフトアルゴリズムを採用してもよい。ラフトアルゴリズムは、各サービス計算装置１０２（１）～１０２（３）が同じ一連の状態遷移に同意することを保証する。したがって、ラフト合意２０８は、ＤＵＱ１２４が、付随状態（例えば他状態２０６）と共に、そして典型的には、他状態２０６と独立しないでラフト合意プロトコルを使用して複製されてもよいので、ＤＵＱ１２４だけでなく持続的状態２０４全体へ適用してもよい。ラフトグループは選択されたリーダを介して合意を達成する、例えば、ラフトグループ内のサービス計算装置１０２はリーダ又はフォロアのいずれかであってよい。リーダはフォロアに対するＤＵＱ１２４複製の責任があってもよい。リーダは、ハートビートメッセージを送信することによりその存在をフォロアに定期的に通知してもよい。

この例では、指示された方針に従ってオブジェクトを格納するためのユーザ要求２１０は、例えば図１に関して上述されたユーザ装置１０８から受信されると仮定する。さらに、第１サービス計算装置１０２（１）がラフトグループリーダであり、サービス計算装置１０２（２）、１０２（３）が第１サービス計算装置１０２（１）のラフトグループフォロアであると仮定する。したがって、ユーザ要求２１０は、ストレージプログラムにオブジェクトを格納させ、少なくとも１つの更新を第１サービス計算装置１０２（１）における単一トランザクションとしてＤＵＱ１２４へ書き込ませる。加えて、ラフトリーダ、サービス計算装置１０２（１）は、ＤＵＱ１２４に対する少なくとも１つの更新をラフトフォロア、サービス計算装置１０２（２）、１０２（３）へ伝えてもよい。したがって、２０８に示すように、ラフト合意アルゴリズムを介し、ラフトリーダは少なくとも１つのＤＵＱ更新２１４を第２サービス計算装置１０２（２）及び第３サービス計算装置１０２（３）へ送信してもよい。加えて、上に述べたように、いくつかの例では、他状態２０６に関係する情報はまた、その性質がＤＵＱ１２４を介して適用される更新に少なくとも部分的に依存し得るラフト合意２０８を介して更新されてもよい。したがって、ＤＵＱ１２４の冗長な複製は、ラフトアルゴリズムに基づき定期的に更新されてもよい。ＤＵＱ１２４の複数の複製は複数の異なるストレージ装置上に維持されるので、システムはＤＵＱ１２４が維持されるストレージ装置又は計算装置の故障に耐えることができる。さらに、ユーザ要求と同じトランザクションにおいてＤＵＱ１２４の更新を行うことにより、このイベントは、ユーザへ応答を返すまで維持され、メタデータデータ構造の更新までの待ち時間が低減され、そしてＤＵＱ１２４から処理されるいかなる以降の更新も非同期的に処理されてもよい。さらに、現存の更新の処理が別のデータ構造、オブジェクトなどに対する追加処理の必要となれば、追加更新として追加処理がＤＵＱ１２４へ追加され、追加処理が非同期的に行われてもよい。

ＤＵＱ１２４は、ログ構造化マージツリーデータ構造として格納される冗長優先度キューであってもよく、システムの状態の残りと同じストレージ内に維持されてもよい。これは、ＤＵＱ１２４がシステムの状態の残りとともにアトミック的に更新されることを可能にする。ＤＵＱ１２４に対する各更新は複数の属性を含んでもよい。優先度属性はＤＵＱ１２４内の項目の優先度を示す整数であってもよい。例えば、優先度は、ＤＵＱ１２４内の更新が処理される順番を判断するための第１の考慮事項であってもよい。高優先度を有する更新は低優先度を有する更新より早く処理されてもよい。

キュー番号属性はまた、更新毎にＤＵＱ１２４に関し、一意的であってもよい整数であってもよい。例えば、各更新がＤＵＱ１２４へ挿入されると、各更新は単調増加カウンタから番号が割り当てられてもよい。高いキュー番号を有する更新は低いキュー番号を有する更新の後にＤＵＱ１２４内へ挿入されてもよい。したがって、キュー番号は更新が処理される順番を判断する第２の考慮事項であってもよい。２つの更新が同じ優先度を有する場合には、低いキュー番号を有する更新は、高いキュー番号を有する更新より早く処理されてもよい。

別属性は、更新のタイプであってもよく、更新が非同期管理プログラムにより処理される方法だけでなく、同じキーに関して更新を折り畳む方法を判断する列挙タイプであってもよい。キー属性は、ＤＵＱ１２４が更新を重複解除し得る機構をＤＵＱ１２４に与えるブロブ（ｂｌｏｂ）であってもよい。加えて、プロセッサ識別子（ＩＤ）属性は、システム内の、どのプロセッサが特定更新を現在処理しているかを示す個々のプロセッサの一意なＩＤであってもよい。処理されていない更新に関して、プロセッサＩＤ属性は設定されない。さらに、状態属性は、上に論述された他のフィールドのうちのいずれかにおいても利用可能でない更新に関連するすべてのものを含むブロブであってもよい。

加えて、ＤＵＱ１２４はＡＰＩ情報１２６に含まれてもよい以下の１又は複数のＡＰＩを採用してもよい。いくつかのケースでは、これらのＡＰＩのすべてはアトミックであってもよい。「エンキュー」ＡＰＩは、更新をＤＵＱ１２４内に挿入することに責任があってもよい。「ワーク取得」ＡＰＩは、ＤＵＱ１２４からワークを取り出すことに責任があってもよい。「デキュー」ＡＰＩは、完了した更新をＤＵＱ１２４から一掃することに責任があってもよい。「リキュー」ＡＰＩは、ＤＵＱ１２４が、潜在的他のプロセッサによりさらに処理されるように未完了のワークをＤＵＱ１２４へ戻すことに責任があってもよい。進行中リストＡＰＩは、プロセッサにより既に処理されているワークを入手することに責任があってもよい。上述のＡＰＩのそれぞれの機能の例は、以下に提示され、図３～９に示される。

図３はいくつかの実施形態に係るエンキュー及び折り畳み更新動作３００の実行例を示すブロック図である。上述のように、エンキューＡＰＩは更新をＤＵＱ１２４内へ挿入することに責任があってもよい。エンキューＡＰＩは、引き数として優先度、タイプ、キー、及び状態を取ってもよい。エンキューＡＰＩは、受信された更新がＤＵＱ１２４内に既に存在する更新と共に折り畳まれられるべきかどうかを判断してもよい。更新がＤＵＱ１２４内に実際に既に存在し、そして受信された更新と共に折り畳むのに適格である場合、更新は、既にＤＵＱ１２４内に存在している更新と同じ優先度及びキュー番号を有するように折り畳まれる。更新のタイプ及びキーは変更されない。更新は、処理されていなければ折り畳まれるのに適格であるので、更新のプロセッサＩＤはヌル（ｎｕｌｌ）になる。状態属性の値は、古い状態及び新しい状態を入力として受信する更新のタイプにより判断されでもよく、更新に含まれる状態ブロブを戻す。

他方で、更新がＤＵＱ１２４内に既に存在しない又は現存の更新が折り畳むのに適格でない場合は、新しい更新がＤＵＱ１２４へ追加されてもよい。キーの更新がＤＵＱ１２４内に存在しない場合、キーのＤＵＱ１２４内の更新が既に処理されている場合、又は更新のタイプが折り畳むことをサポートしていなければ、更新は、折り畳むのに適格でない。

図３の例では、更新３０２は、ＤＵＱ１２４内に既に存在しており、３に等しい優先度３０４、１に等しいキュー番号３０６、タイプ３０８「ＤＥＬＥＴＥ」、「Ｋｅｙ１」のキー３１０、ｎｕｌｌに等しいプロセッサＩＤ３１２、及び［ａ，ｂ］に等しい状態３１４を含む。エンキュー要求３１６が発生していると仮定する。エンキュー要求３１６が左側のＤＵＱ１２４に対し行われ、エンキュー要求３１６が完了された後、右側に示すようにＤＵＱ１２４の状態の変化という結果となる。

エンキュー要求３１６は、３の優先度３０４、タイプ３０８「ＤＥＬＥＴＥ」、ｋｅｙ１のキー３１０及び、［ｃ，ｄ］に等しい状態３１４を含む。したがって、優先度３０４、タイプ３０８、及びキー３１０はエンキュー要求３１６の既存更新に関して同じであるので、新しい更新は既存更新３０２と共に折り畳まれてもよく、既存更新３０２の状態３１４の変化という結果となる。したがって、更新のエンキュー及び折り畳みに続くＤＵＱ１２４内の状態３１４は、既存更新３０２の状態とエンキュー要求３１６の状態との組み合わせ、すなわち［ａ，ｂ，ｃ，ｄ］である。これは、状態３１４が、ＤＵＱ１２４内に既に存在する更新３０２とエンキュー要求３１６との間に折り畳まれた、この場合、エンキュー要求３１６からの状態をＤＵＱ１２４内に既に存在する更新３０２からの状態へ追加するためである。状態が折り畳まれる方法は個々の更新タイプに依存してもよい。

図４はいくつかの実施形態に係る高い優先度動作４００のエンキューの実行例を示すブロック図である。この例では、エンキュー要求４０２が受信される。エンキュー要求４０２は、優先度３０４の５、タイプ３０８のＣＲＥＡＴＥの、ｋｅｙ２に等しいキー３１０及び状態３１４を含む。エンキュー要求４０２が受信されるとき、ＤＵＱ１２４は、３に等しい優先度３０４を有する既存更新４０４を既に含む。したがって、エンキュー要求４０２は異なる優先度に起因して既存更新４０４と共に折り畳まれない。その代りに、右側のＤＵＱ１２４に示すように、新しい更新４０６が生成され、ＤＵＱ１２４内の既存更新４０４の前方に挿入される。これは、たとえ新しい更新４０６が低いキュー番号３０６を有していても新しい更新４０６はより高い優先度３０４、すなわち優先度＝５を有するためである。したがって、新しい更新４０６は、優先度＝３を有する既存更新４０４の前方にエンキューされる。

図５はいくつかの実施形態に係るワーク取得動作５００の実行例を示すブロック図である。上述のように、ワーク取得ＡＰＩは、ＤＵＱ１２４からワークを取り出すために採用されてもよい。ゲットワークＡＰＩは、引き数として、プロセッサＩＤ、最大優先度、及びカウントを取ってもよい。ワーク取得ＡＰＩは、処理すべきワーク取得ＡＰＩを呼び出しているプロセッサのための１又は複数の更新のリストをＤＵＱ１２４から取得してもよい。リストは、指定された最大優先度以下の最高優先度を有する更新を、提供されたカウント数まで検出することにより配置されてもよい。次に、ワーク取得ＡＰＩは、要求しているプロセッサの提供されたプロセッサＩＤによりこれらの更新をマーキングしてもよく、そしてプロセッサＩＤ３１２に対する変更して更新をＤＵＱ１２４へ戻して維持してもよく、要求しているプロセッサへ選択された更新のリストを返してもよい。要求しているプロセッサは、今や、他のプロセッサもまたこれらの更新を取得しようすることなく、これらの更新に対して動作することができる。ＤＵＱ１２４内には何千ものイベントがある可能性があるので、個々のワーク取得呼び出しにより取り出される更新の数を制限することが望ましい。イベントの数は、ＤＵＱ１２４又はキュープロセッサのいずれかが扱うことができる処理より多くなってもよい。したがって、カウント属性は、戻されるリストに含まれる更新の数を制限してもよい。ワーク取得要求を介して取り出された更新は、異なるワーク取得要求により返されなくてもよく、エンキュー要求中に折り畳まれる適格がなくてもよい。

図５の例では、ワーク取得要求５０２は、１のプロセッサＩＤ３１２を有するプロセッサから受信される。ワーク取得要求５０２は、さらに、４に等しい最大優先度５０４及び１０に等しいカウント５０６を含む。したがって、ワーク取得要求５０２は、現在ＤＵＱ１２４の前方に在る更新４０６の優先度３０４より低い最大優先度５０６を含む。その代りに、更新４０４の優先度３０４がワーク取得要求５０２内で規定された最大優先度５０６以下であるので第２の更新４０４が戻されてもよい。この特徴は、高優先度更新が、ＤＵＱ１２４内に長期間存在した可能性がある低優先度更新を飢えさせるのを防ぐことが可能であるように存在する。また、ワーク取得要求の結果として、ＤＵＱ１２４内の更新４０４は、更新４０４内のプロセッサＩＤ３１２がヌルからプロセッサＩＤ＝１へ変更されるように修正される。したがって、ワーク取得要求５０２を送信したプロセッサへ戻されるリスト内で、更新４０４は、ワーク取得要求５０２に含まれていたプロセッサＩＤの値に設定されたプロセッサＩＤを有する。プロセッサＩＤに更新４０４が割り当てられたので、任意のプロセッサからの将来のワーク取得要求への応答は、更新４０４を含まなくてもよい。加えて、以下に論述されるように、進行中リスト要求は、進行中リスト要求内のプロセッサＩＤが更新４０４内のプロセッサＩＤと同じである場合に更新４０４だけを戻してもよい。

図６はいくつかの実施形態に係るワーク取得動作６００の実行例を示すブロック図である。この例では、１に等しいプロセッサＩＤ３１２、１０の最大優先度５０６、及び１１に等しいカウント５０８を含むワーク取得要求６０２が受信される。さらに、この例におけるＤＵＱ１２４は、優先度＝５を有する更新６０２と、優先度＝３を有する更新６０４とを現在含む。ワーク取得要求６０２内に与えられている引き数により、ＤＵＱ１２４の前方における更新６０４が、処理のために選択され、リストに戻される。さらに、更新６０４内のプロセッサＩＤ３１２は「ｎｕｌｌ」から「１」へ変更される。カウントパラメータ５０８により示されるように、ワーク取得要求６０２が、応答は１つの結果だけを含むべきであると指定されているので、第２の更新６０６は、戻されない。したがって、実効されるべき多数の更新がＤＵＱ１２４内にあっても、ＤＵＱ１２４の消費者は、かれら自身の可用性に従って取り出されるワークの量を制限することができる。

図７はいくつかの実施形態に係るデキュー動作７００の実行例を示すブロック図である。上述のように、デキューＡＰＩは完了された更新をＤＵＱ１２４から一掃するために採用されてもよい。デキューＡＰＩは、引き数として、優先度、試行、キュー番号、及びプロセッサＩＤを含んでもよい。例えば、デキューＡＰＩは、更新のプロセッサＩＤがデキュー要求７０２に含まれるプロセッサＩＤと等しい場合には、所与の優先度及びキュー番号に対応する更新を消去してもよい。更新のプロセッサＩＤが、提供されたプロセッサＩＤに等しくない場合には、提供されたＩＤを有するプロセッサはデキューされている更新を処理すべきでないので、エラーが投じられる。更新はデキューされるためにプロセッサにより処理されるべきであるので、ワーク取得ＡＰＩを介して最初に入手し、処理することなく更新をデキューするいかなる方法も無い。加えて、デキューＡＰＩは、更新を完了されたとしてマーキングするためにシステムにより使用されてもよい。これは、更新がＤＵＱ１２４内にもはや出現しない又は任意のＡＰＩ要求により戻されるということを意味する。

図７の例では、デキュー要求７０２が受信される。デキュー要求７０２は、５に等しい優先度３０４、１に等しい試行７０４、１に等しいキュー番号３０６、及び１に等しいプロセッサＩＤ３１２を含む。デキュー要求７０２は、整合する更新をＤＵＱ１２４から位置を突き止め、除去する。この場合、更新７０６は、デキュー要求７０２内に指定されたパラメータが整合し、ＤＵＱ１２４から除去され、更新７０８がＤＵＱ１２４の先頭へ移動することになる。デキュー要求７０２内のプロセッサＩＤが更新７０６のプロセッサＩＤ３１２と整合しなければ、デキュー要求７０２は失敗し、エラーメッセージが生成されてもよい。

図８はいくつかの実施形態に係るリキュー動作８００の実行例を示すブロック図である。上述のように、リキューＡＰＩは、未完了の更新が、例えば他のプロセッサによりさらに処理されるように、未完了のワークをＤＵＱ１２４へ戻すために採用されてもよい。リキューＡＰＩは、引き数としてプロセッサＩＤ、優先度、キュー番号、新しい優先度及び、新しい状態を取る。リキューＡＰＩは、既存更新のプロセッサＩＤが、提供されたプロセッサＩＤと整合する場合には、最初に、提供された優先度及びキュー番号が整合する更新を除去してもよい。既存更新のプロセッサＩＤがリキュー要求で提供されたものと整合していない場合には、提供されたＩＤを有するプロセッサはリキューされている更新を処理しているべきでないので、エラーメッセージが管理者などに生成されてもよい。逆に、更新をリキューするために、更新はプロセッサによりもはや処理されていてはならないので、ワーク取得ＡＰＩを介して最初に更新を入手することなく更新をリキューする方法は存在しない。既存更新がＤＵＱ１２４から除去された後、新しい更新は、優先度＝新しい優先度、タイプ＝既存更新タイプ、キー＝既存更新キー、状態＝新しい状態のような引き数により、上記エンキューＡＰＩを呼び出すことによりエンキューされてもよい。リキューＡＰＩは、典型的にはさらなる処理を妨げたエラーに起因して、完了されなかったワークをＤＵＱ１２４内へ戻すためにシステムにより使用される。

図８の例では、リキュー要求８０２が受信される。リキュー要求は、１に等しいプロセッサＩＤ ３１２、３に等しい優先度３０４、２に等しいキュー番号３０６、４に等しい新しい優先度８０４、及び［ｅ，ｆ］の新しい状態８０６を含む。したがって、リキュー要求８０２は更新８１０と整合し、キュー番号２及び優先度３を有する更新がリキューされる。これは、例えば、キュー消費者が更新８１０を処理しようとし、更新８１０が後で再処理されることを望んでいる間にエラーに遭遇した、又は、更新８１０が他のいくつかの理由のために完全には処理されない等のように、任意数の理由のために発生する可能性がある。リキューでは、優先度３０４及びキュー番号３０６が整合するとともに、リキュー要求内のプロセッサＩＤ３１２に整合するプロセッサＩＤ３１２を有する既存更新が存在するはずである。図示の例では、ＤＵＱ１２４内の第２の更新８１０が、リキュー要求８０２に整合し、したがって、３に等しい新しいキュー番号３０６、４に等しい優先度３０４、及び新しい状態［ｅ，ｆ］を有する更新８１２においてリキューされる。新しい更新８１２では、プロセッサＩＤ ３１２はヌルへ設定されるので、いかなるプロセッサも新たにキューされた更新８１２を扱うことができる。さらに、他の既存更新８０８は、この例におけるリキュー要求の行為により影響を受けない。

図９はいくつかの実施形態に係る進行中リスト動作９００の実行例を示すブロック図である。上述のように、進行中リストＡＰＩは、プロセッサにより既に処理されているワークを入手するために採用されてもよい。進行中リストＡＰＩは、引き数としてプロセッサＩＤ及び限度を取る。進行中リストＡＰＩは、ワーク取得ＡＰＩとして同じ順番で、そして指定された限度まで、提供されたＩＤを有するプロセッサによりＤＵＱ１２４に従って現在処理されている更新を取り出してもよい。

図９の例では、進行中リスト要求が受信される。進行中リスト要求９０２は、１に等しいプロセッサＩＤ３１２及び１に等しい限度９０４を含む。整合するプロセッサＩＤ３１２を有するＤＵＱ１２４の先頭の更新９０６が返されてもよい。プロセッサＩＤ同士が一致しない場合には、更新９０６は返されず、その代りに第２の更新９０８が返されてもよい。したがって、ワーク取得要求と同様に、進行中リスト要求９０２は、１つの要求に応答して返される更新の総数を制限する能力を有する。この例では、１に等しい限度９０４に基づいて、１つの更新が返される。

図１０はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１０００を示すブロック図である。図１０の例はスタートアップにおける非同期管理プログラム１２０の状態を示す。この時点で、非同期管理プログラム１２０は、ワーカも有しないが、インメモリキュー１００２を実際に含む又はそれにアクセスすることができ、ＤＵＱ１２４のメモリ内の位置を知っている。この例では、ＤＵＱ１２４は、消費される準備ができている４つの既存更新１００４～１０１０を含む。非同期管理プログラム１２０はＤＵＱ１２４から更新を消費するように構成されてもよい。

この例では、更新１００４は、更新１００４内のプロセッサＩＤ１０１２（すなわちプロセッサＩＤ「Ｐ１」）によりマーキングされる仮定する。これは更新１００４が、例えば図５及び６に関し上に論述されたように、例えばワーク取得要求の実行に続くように、進行中（であることを示す。１つの非限定的例として、更新１００４の処理は開始されているが、中断されている、又は完了されていないと仮定する。非同期管理プログラム１２０が始まった後、非同期管理プログラム１２０は、図１１～図１８に関し説明される動作などの動作を実行してもよい。

図１１はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１１００を示すブロック図である。この例では、非同期管理プログラム１２０は、ＤＵＱ１２４から更新を消費するために実行するために又はＤＵＱ１２４に対する動作を実行するために、一群のワーカ１１０２、１１０４、１１０６を開始する。一例として、ワーカ１１０２～１１０６は、ＤＵＱ１２４内に維持された更新を処理するための非同期管理プログラム１２０を実行するプロセッサにより実行される複数の処理それぞれに対応してもよい。

図１２はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１２００を示すブロック図である。この例では、非同期管理プログラム１２０は、以前に実行されたときに完了しなかったワークを探すことを開始してもよい。非同期管理プログラム１２０は、ＤＵＱ１２４に対し進行中リスト要求を行うことによりそのようにする。したがって、非同期管理プログラム１２０は、非同期管理プログラム１２０が実行された最後の時に処理が開始されたが完了しなかった更新が存在するかどうかを判断するために、ＤＵＱ１２４に対し進行中リストＡＰＩ要求１２０２を行う。例えば、進行中リスト要求は、非同期管理プログラム１２０を実行するプロセッサのプロセッサＩＤをパラメータとして使用してもよく、パラメータとして例えば図９に関し上述された限度をさらに含んでもよい。非同期管理プログラム１２０は、ワーカ１１０２～１１０６が消費するために、いくつかの取り出された更新のリストをインメモリキュー１００２内に追加してもよい。新しい更新が取り出されない場合には、非同期管理プログラム１２０は、図１６に関し以下に論述されるようにワーク取得要求を実行してもよく、そして図１３～図１５をスキップしてもよい。

図示の例では非同期管理プログラム１２０を実行するプロセッサのプロセッサＩＤが、更新１００４をマーキングするプロセッサＩＤ１０１２（すなわち「Ｐ１」）に整合すると仮定する。したがって、更新１００４は進行中リスト要求１２０２に応答して返される。このことは、そのプロセッサＩＤがこの非同期管理プログラムのプロセッサに等しかったということを意味する。非同期管理プログラム１２０は更新１００４をそのインメモリキュー１００２内に入れてもよい。

図１３はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１３００を示すブロック図である。図１３の例では、非同期管理プログラム１２０は、上記図１２内の動作により見つけ出されたいくつかの進行中更新を処理してもよい。例えば、非同期管理プログラム１２０は、別の一団の更新を入手する前に、更新のすべてが一群のワーカ１００２～１００６の１又は複数のワーカにより処理されるのを待ってもよい。図１３の例では、ワーカ１１０２はインメモリキュー１００２から更新１００４を取り出した。いくつかのケースでは、非同期管理プログラム１２０はワーカ１１０２が更新１００４を処理することを完了するまで、ＤＵＱ１２４に対してそれ以上の要求をしない可能性がある。

図１４はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１４００を示すブロック図である。この例では、更新１００４を処理の完了に続いて、ワーカ１１０２は、ＤＵＱ１２４から更新１００４をデキューするためにデキュー更新要求１４０２を送信してもよい。次に、更新１００４はＤＵＱ１２４から除去される。したがって、本明細書におけるいくつかの例では、更新は、例えば図７に関し上述したように、デキュー要求が行われるまでＤＵＱ１２４から除去されない。例えば、更新の処理が終了された後だけデキュー要求を呼び出すことにより、システムは、ＤＵＱ１２４に従って更新が完了されることを保証する。

図１５はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１５００を示すブロック図である。この例では、非同期管理プログラム１２０は、進行中リスト要求１５０２を送信することにより、いくつかの進行中更新をも判断するために別の要求を行ってもよい。今回、進行中更新は返されず、これは、非同期管理プログラム１２０は以前に終了されていなかったすべての進行中ワークの処理を完了しており、今は新しいワークを入手し得るということを示している。

図１６はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１６００を示すブロック図である。この例では、非同期管理プログラムが、引き数としてそのプロセッサＩＤ、最大優先度、３以上の限度を使用したＤＵＱ１２４に対するＡＰＩ呼び出しとしてワーク取得要求１６０２を行うと仮定する。例えば、非同期管理プログラム１２０にメモリを使い果たさせることを避けるために、非同期管理プログラム１２０は、インメモリキュー１００２が閾値サイズを越えた場合に追加更新を取り出さないように構成されてもよい。

ワーク取得要求１６０２に応答して、３つの更新１００６、１００８、１０１０のリスト１６０４が返されると仮定する。更新１００６、１００８、１０１０の各々は、非同期管理プログラム１２０を実行するプロセッサのプロセッサＩＤ１０１２、すなわちプロセッサＩＤ「Ｐ１」によりＤＵＱ１２４内でマーキングされてもよい。非同期管理プログラム１２０は取り出された更新のすべてを同じインメモリキュー１００２内へ追加してもよい。したがって、ＤＵＱ１２４は処理のために３つの新しい更新１００６～１０１０を返し、図５、６に関し上述されたように、他の消費者が可能性としてそれらの更新を消費するのを防止するために、更新の全ては、ＤＵＱ１２４内のそれらへ追加される非同期管理プログラムのプロセッサＩＤ１０１２を有する。

図１７はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１７００を示すブロック図である。非同期管理プログラム１２０は、非同期管理プログラム１２０の内部のワーカ１１０２～１１０６に、処理するべきそれぞれの更新を提供する。ワーカ１１０２～１１０６は更新１００６～１０１０をそれぞれ処理し始める。

図１８はいくつかの実施形態に係る非同期管理プログラム１２０の例示的動作１８００を示すブロック図である。この例では、非同期管理プログラムワーカ１１０２～１１０６がそれらのタスクにより何かをすべてをしたと仮定する。例えば、ワーカ１１０２、１１０４が更新１００６、１００８それぞれを正常に完了したと仮定する。したがって、ワーカ１１０２は、ＤＵＱ１２４から更新１００６をデキューするためにデキュー更新要求１８０２を送信し、ワーカ１１０４は、ＤＵＱ１２４から更新１００８をデキューするためにデキュー更新要求１８０４を送信する。

他方で、第３のワーカ１１０６が更新１０１０を正常に完了しなかったと仮定する。その結果、第３のワーカ１１０６は例えば図８に関して以下に論述されるように、リキュー更新要求１８０６を送信してもよい。したがって、更新１０１２はリキューされる。例えば、更新１０１０は、処理中にエラーに遭遇したかもしれない、又は追加処理を要求とするかもしれない。更新１０１２は、更新１０１０を処理する際にワーカ１１０６により既に完了されたかもしれない処理に基づき、元の更新１０１０とは、優先度、状態などの１つ又は複数の属性において異なってもよい。

更新を処理する際、非同期管理プログラムワーカ１１０２～１１０６は最初に、例えば優先度などに基づいてインメモリキュー１００２から更新を取得してもよい。ワーカがインメモリキュー１００２から更新を取得した後、いかなる他のワーカも当該更新について動作しようとしない。

処理する更新毎に、ワーカは最初に、何の種類の更新をワーカが処理しているかを、例えば図３～図９に関して上述されたタイプ属性３０８に基づき判断してもよい。これから、ワーカは、さらなる文脈のために上述されたキー属性３１０及び状態属性３１４を使用することにより、どのように更新を処理すべきかを決定してもよい。例えば、副指標が更新される必要があれば、ワーカは、主指標からこのキーに関する現在の情報を調べるために更新のキーを使用し、そして、次に、更新情報を得るために副指標を更新する可能性がある。これは、ＤＵＱ１２４内に列挙された更新の共通使用ケースであってもよい。

更新の別の可能な使用は、他のある非同期処理を駆動することである。例えば、更新は、第１の方針の実行をトリガするための第１の処理によりＤＵＱ１２４内へ挿入される可能性がある。例えば、第１の方針が延いては１又は複数の格納されたオブジェクト、オブジェクトメタデータなどの条件を変更する更新が行われるようにさせると仮定する。このシナリオは、いくつかの特性を有する映像へタグを追加する方針が格納場所に格納された複数の映像の下位集合に対し行われる、上述された例に対応してもよい。例えば、トリガされた方針は、指定された特性を有するデータセット内の映像を発見する可能性があり、この個々の映像を処理するために更新をＤＵＱ１２４へさらに追加してもよい。いくつかの特性を満足する映像へタグを追加するなど映像に対する更新が延いては処理されてもよい。さらに、タグを当該映像へ貼り付けることの一部として、例えばストレージ上のあるファイルサイズを越えるタグ付き映像のうちの任意のものを圧縮するため等の実行される別の方針が実行されるようにするさらに別の更新がＤＵＱ１２４へ追加されると仮定する。

ある理由のために更新が処理されることに失敗した場合には、例えば図８及び図１８に関し上述されたように、更新は、ＤＵＱ１２４のリキューＡＰＩを使用することによりリキューされてもよい。更新は多くの理由のうちのいくつかの理由のために失敗する可能性がある。例えば、上記例において映像が読み出されることに失敗した場合には、映像に対する更新は、リキューされ、そして更新が次にＤＵＱ１２４から出て来ると再び試みられてもよい。さらに、いくつかの例示的構成及び応用が上述されたが、非常に多くの他の変形形態が本明細書の開示の利益を有する当業者に明らかになる。

図１９はいくつかの実施形態に係る例示的処理を示す流れ図である。処理は一連の動作を表す論理フロー図内のブロックの集合として示され、そのいくつか又はすべてはハードウェア、ソフトウェア又はそれらの組み合わせで実装されてもよい。ソフトウェアの文脈では、ブロックは、１又は複数のプロセッサにより実行されるとプロセッサに列挙された動作を行うようにプログラムする１又は複数のコンピュータ可読媒体上に格納されるコンピュータ実行可能命令を表してもよい。一般的に、コンピュータ実行可能命令は、特定機能を行う又は特定データタイプを実装するルーチン、プログラム、オブジェクト、構成部、データ構造などを含む。ブロックが説明される順番は制限として解釈されるべきでない。説明されたブロックのうちの任意数のブロックは処理又は代替処理を実施するために任意の順番で及び／又は並列に組み合わせられてもよく、そしてブロックのすべてが実行される必要があるわけではない。論述目的のために、これらの処理は本明細書の例において説明される環境、フレームワーク、及びシステムを参照して説明されるが、これらの処理は幅広い種類の他の環境、フレームワーク及びシステムにおいて実装されてもよい。

図１９はいくつかの実施形態に係る更新を管理するために永続更新キューを採用するための例示的処理１９００を示す流れ図である。いくつかのケースでは、処理１９００は１又は複数のサービス計算装置１０２により少なくとも部分的に実行されてもよい。

１９０２において、計算装置は、ストレージにおけるデータの格納に関係する格納動作のユーザ要求をユーザ装置から受信してもよい。

１９０４において、計算装置は、格納動作の性能を示す応答をユーザ装置へ送信することに先立って格納動作を維持するために更新を更新キューへ追加してもよい。

１９０６において、計算装置は、可能であれば、この更新と更新キュー内に既に存在する既存更新とを結合することにより、更新を折り畳んでもよい。

１９０８において、計算装置は、少なくとも１つの他のプロセッサにより管理される少なくとも１つの他の更新キューへ更新を追加するために、更新に関する情報を少なくとも１つの他のプロセッサへ送信してもよい。

１９１０において、計算装置は、更新キュー内の更新を処理するために少なくとも１つのワーカ処理をインスタンス化してもよい。

１９１２において、計算装置は更新キューから更新を選択してもよい。

１９１４において、計算装置は、少なくとも１つのワーカ処理を実行する１又は複数のプロセッサのプロセッサに対応するプロセッサ識別子により、更新キュー内の更新をマーキングしてもよい。

１９１６において、計算装置は、更新を処理するとともに格納動作を実行するためにワーカ処理のうちの１つを実行してもよい。

１９１８において、ワーカ処理による更新の処理の完了に続いて、計算装置は、更新キューから更新をデキューするための要求を送信してもよい。

本明細書において説明される例示的処理は論述目的のために提供される処理の単なる例である。無数の他の変形形態が本明細書の開示に照らして当業者に明らかになる。さらに、本明細書の開示は処理を実行するための好適なフレームワーク、アーキテクチャ及び環境のいくつかの例を記載するが、本明細書における実施形態は示され論述された特定例に限定されない。さらに、本開示は添付図面において説明及び示したように様々な実施例を提供する。しかし、本開示は、本明細書で説明され示された実施形態に限定されないが、当業者に知られているであろう又は知られるようになるであろうような他の実施形態へ拡張し得る。

本明細書において説明される様々な命令、処理、及び技術は、コンピュータ可読媒体上に格納され本明細書のプロセッサにより実行されるプログラムなどのコンピュータ実行可能命令の一般的文脈において考慮され得る。一般的に、プログラムは、特定タスクを行う又は特定抽象データタイプを実装するためのアプリケーション、ルーチン、オブジェクト、部品、データ構造、実行可能コードなどを含む。これらのプログラムなどは仮想マシン又は他のジャストインタイムコンパイル実行環境などにおいて固有コードとして実行されてもよいし又はダウンロードされて実行されてもよい。典型的に、プログラムの機能は、様々な実施形態において所望に従って組み合わせられてもよいし又は分散されてもよい。これらのモジュール及び技術の実施形態はコンピュータ可読記憶媒体に格納されてもよいし又はある形式の通信媒体をわたって送信されてもよい。

本主題は構造的特徴及び／又は方法論的行為に固有の言語で説明されたが、添付の特許請求の範囲において定義される主題は必ずしも特定の特徴又は行為に限定されないということを理解すべきである。むしろ、特定の特徴及び行為は特許請求の範囲を実装する例示的形式として開示される。

Claims (15)

1. システムであって、
   実行可能命令により動作を実行するように構成された１つ又は複数のプロセッサを含み、
   前記動作は、
   ユーザ装置から、ストレージにおけるデータの格納に関係する格納動作についてのユーザ要求を受信すること；
   前記格納動作の性能を示す応答を前記ユーザ装置へ送信することに先立って、前記格納動作を維持するために更新を更新キューへ追加することであって、前記更新を前記更新キューへ追加することは、前記更新を前記更新キューへ追加させる要求を送信することを含み、前記要求は、前記格納動作により達成される前記格納動作のタイプ又は状態の少なくとも１つを指定する、追加すること；
   前記更新を少なくとも１つの他のプロセッサにより管理される少なくとも１つの他の更新キューへ追加するために、前記更新キューに対する前記更新に関する情報を少なくとも１つの前記他のプロセッサへ送信すること；及び
   その後に、前記更新キューから前記更新を取得し、前記格納動作を実行するために前記更新を処理することと、を含む
   システム。
2. 請求項１に記載のシステムにおいて、
   前記動作は、
   前記更新と前記更新キュー内に既に存在する既存更新とを結合することにより前記更新を折り畳むことをさらに含み、
   前記結合することは、前記格納動作により達成される前記状態と前記既存更新の格納動作により達成される状態とを結合することを含む、
   システム。
3. 請求項１に記載のシステムにおいて、
   前記更新と前記既存更新とを結合することは、同じ指定優先度の格納動作又は同じ指定タイプの格納動作のうちの少なくとも１つを含む前記更新及び前記既存更新の少なくとも一部に基づいている
   システム。
4. 請求項１に記載のシステムにおいて、
   前記動作は、前記更新キューへ前記更新を追加する時に：
   前記更新へ割り当てられた優先度と、前記更新キュー内に既に存在する１又は複数の更新へ割り当てられた優先度とを比較すること；及び
   前記更新を、前記更新キュー内において低い優先度を有する既存更新の前方に置くことをさらに含む、
   システム。
5. 請求項１に記載のシステムにおいて、
   その後に、前記更新キューから前記更新を取得し、前記格納動作を実行するために前記更新を処理することは：
   前記更新を処理するために少なくとも１つのワーカ処理をインスタンス化すること；
   前記更新キューから前記更新を選択すること；
   前記少なくとも１つのワーカ処理を実行する前記１又は複数のプロセッサのうちの１つのプロセッサに対応するプロセッサ識別子により前記更新キュー内の前記更新をマーキングすること；及び
   前記格納動作を実行するために前記ワーカ処理のうちの１つを実行することと、を含む、
   システム。
6. 請求項５に記載のシステムにおいて、
   前記更新キュー内の前記更新をマーキングする前記プロセッサ識別子は、前記更新キュー内の前記更新が処理されていることを示す、
   システム。
7. 請求項５に記載のシステムにおいて、
   前記動作は、前記ワーカ処理による前記更新の処理の完了に続いて、前記更新キューから前記更新をデキューするための要求を送信することをさらに含む、
   システム。
8. 請求項５に記載のシステムにおいて、
   前記動作は、前記更新の前記処理を完了することの失敗に続いて、前記更新の部分的処理に基づいて、更新された状態を有する新しい更新として前記更新をリキューするための要求を、前記ワーカ処理により送信することを更に含む、
   システム。
9. 請求項５に記載のシステムにおいて、
   前記更新キューから前記更新を取得することに先立って、前記プロセッサ識別子と前記更新キュー内の前記既存更新において示されているプロセッサ識別子とを整合することに少なくとも部分的に基づいて、処理され、且つ完了していない既存更新を決定するための要求を送信することをさらに含む、
   システム。
10. 請求項１に記載のシステムにおいて、
    その後に、前記更新キューから前記更新を取得することは、取り出された更新の最大優先度又は取り出された更新の最大数のうちの少なくとも１つを指定することを含む、
    システム。
11. 請求項１に記載のシステムにおいて、
    前記少なくとも１つの他の更新キューへ追加するために、前記更新に関する情報を前記少なくとも１つの他のプロセッサへ送信することは、ラフト合意アルゴリズムに従う前記情報を送信することを含む、
    システム。
12. 方法であって、
    １つ又は複数のプロセッサにより、ユーザ装置からストレージにおけるデータの格納に関係する格納動作のユーザ要求を受信すること；
    前記１つ又は複数のプロセッサにより、前記格納動作の性能を指示する応答を前記ユーザ装置へ送信することに先立って、前記格納動作を維持するために更新を更新キューへ追加することであって、前記更新を前記更新キューへ追加することは、前記更新を前記更新キューへ追加させる要求を送信することを含み、前記要求は、前記格納動作により達成される前記格納動作のタイプ又は状態の少なくとも１つを指定する、追加すること；
    前記１つ又は複数のプロセッサにより、前記更新を少なくとも１つの他のプロセッサにより管理される少なくとも１つの他の更新キューへ追加するために、前記更新キューに対する前記更新に関する情報を前記少なくとも１つの他のプロセッサへ送信すること；及び
    前記１つ又は複数のプロセッサにより、その後に、前記更新キューから前記更新を取得し、前記格納動作を行うために前記更新を処理することを含む
    方法。
13. 請求項１２に記載の方法において、
    前記更新と前記更新キュー内に既に存在する既存更新とを結合することにより前記更新を折り畳むことをさらに含み、前記結合することは、前記格納動作により達成される前記状態と前記既存更新の格納動作により達成される状態とを結合することをさらに含む、
    方法。
14. １つ又は複数のプロセッサにより実行されると、前記１つ又は複数のプロセッサを動作を実行するように構成する命令を格納する１又は複数の非一時的コンピュータ可読媒体であって、
    前記動作は、
    ユーザ装置から、ストレージにおけるデータの格納に関係する格納動作のユーザ要求を受信すること；
    前記格納動作の性能を指示する応答を前記ユーザ装置へ送信することに先立って、前記格納動作を維持するために更新を更新キューへ追加することであって、前記更新を前記更新キューへ追加することは、前記更新を前記更新キューへ追加させる要求を送信することを含み、前記要求は、前記格納動作により達成される前記格納動作のタイプ又は状態の少なくとも１つを指定する、追加すること；
    前記更新を少なくとも１つの他のプロセッサにより管理される少なくとも１つの他の更新キューへ追加するために、前記更新キューに対する前記更新に関する情報を前記少なくとも１つの前記他のプロセッサへ送信すること；
    その後、前記更新キューから前記更新をその後取得し、前記格納動作を行うために前記更新を処理することを含む、
    非一時的コンピュータ可読媒体。
15. 請求項１４に記載の非一時的コンピュータ可読媒体において、
    前記動作は、前記更新と前記更新キュー内に既に存在する既存更新とを結合することにより前記更新を折り畳むことをさらに含み、
    前記結合することは、前記格納動作により達成される前記状態と前記既存更新の格納動作により達成される状態とを結合することを含む、
    非一時的コンピュータ可読媒体。
    
    

Images