JP6530471B2 - バーストモード制御 - Google Patents

Description

いくつかの大手テクノロジー組織が、「サービス型ソフトウェア」（ｓｏｆｔｗａｒｅ
−ａｓ−ａ−ｓｅｒｖｉｃｅ）を販売するテクノロジーの構築に投資している。このよう
なサービスは、クライアントもしくはサービス利用者に、共有ストレージ（例えば、デー
タベースシステム）及び／またはコンピューティングリソースへのアクセスを提供する。
多層電子商取引システムにおいて、物理または仮想マシン全体、ＣＰＵ、メモリ、ネット
ワーク帯域、または入出力容量等の異なる種類のリソースの組合せが、サービス利用者及
び／またはサービス利用者のアプリケーションに割当てられうる。

クライアントにサービスを提供するシステムはすべて、システムをオーバーロード状態
にする可能性のある過大な負荷のサービス要求から防御する必要がある。一般にウェブサ
ービスまたはリモートプロシージャコール（ＲＰＣ）サービスにおいて、システムが受信
した一部のクライアント要求に対し期待される品質を提供できない場合、システムは「オ
ーバーロード」状態であるとみなされる。オーバーロード状態のシステムにより適用され
る共通の解決策には、システムがオーバーロード状態から脱するまで、クライアントに対
しサービスを拒否する、または受信要求を特定の数に制限することが含まれる。

一部の現行のシステムは、要求率を固定または可変グローバル閾値と比較し、要求率が
この閾値を超えると、選択的にクライアントに対しサービスを拒否することで、オーバー
ロードのシナリオを回避する。しかしながら、この手法では、サービスに対する異なる種
類及び／またはインスタンスのサービス要求を受付けることで実行されうる作業量の違い
が考慮されていない。加えて、変動的で予測不能な率で異なる種類の要求を受信し、当該
要求を果たすために必要となる作業量もまた変動的で予測不可能であるシステムにおいて
、有意義な単一のグローバル閾値（まして許容レベルのパフォーマンスを提供する単一の
グローバル閾値等）を定義することは、不可能ではなくとも困難である。数多くのサービ
スが、クライアント要求が時間的に均一に分散している時に最も良く稼働するように設計
されているが、実際にはそのような作業分散における時間的均一性はめったに起こらない
。さらに、少なくともいくつかの環境において、作業量は、時間に関して不均一であるば
かりではなく、操作されるデータセットに関しても不均一でありうる。例えば、一部のデ
ータは、他のデータより頻繁にアクセスまたは修正されうる。高いレベルの顧客満足の達
成及び維持を目指すサービスプロバイダは、より精巧に作業量の変動に対処する技術を実
装する必要があるだろう。

図１ａは作業要求到着率の例示的変動を示す図であり、図１ｂは少なくともいくつかの実施形態による、そのような変動が起こった際トークンバケットを使用して受付制御判断を行いうるシステムを示す図である。 少なくともいくつかの実施形態による、トークンベースの受付制御機構の高次概観図である。 少なくともいくつかの実施形態による、受付制御に使用されるトークンバケットの例示的構成プロパティを示す図である。 少なくともいくつかの実施形態による、プロビジョン能力バケットからバーストモードバケットへの未使用トークンの蓄積の実施例を示す図である。 少なくともいくつかの実施形態による、読出し及び書込みの受付制御のためのそれぞれのトークンバケットの使用を示す図である。 少なくともいくつかの実施形態による、１以上のローカルバースト限度バケットと、１以上の共有リソース能力バケットと、１以上の複製管理バケットとを含むバーストモードトークンバケットセットを示す図である。 少なくともいくつかの実施形態による、受付制御のための作業要求バーストのカテゴリ分類の実施例を示す図である。 少なくともいくつかの実施形態による、バーストモード受付制御のためのピークバーストトークンバケットと持続バーストトークンバケットの組合せを含む複合トークンバケットの使用の実施例を示す図である。 少なくともいくつかの実施形態による、作業処理のそれぞれのカテゴリ専用のピークバースト及び持続バーストバケットの使用を示す図である。 少なくともいくつかの実施形態による、ネットワークアクセス可能なサービスにおいて作業要求に対しトークンベースの受付制御機構を実行するために行われうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、ネットワークアクセス可能なサービスにおいて複数のバーストモードトークンバケットを使用してバーストモード処理に対処するトークンベースの受付制御機構を実行するために行われうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、受付制御のために行われうるトークンの消費、補充、及び譲渡処理の態様を示すフロー図である。 少なくともいくつかの実施形態による、受付済作業要求に対応する作業処理が完了した後に、１以上のトークンバケットにおけるトークン数を調整するために行われうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、管理イベントに応じてバーストモード受付制御パラメータを修正するために行われうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、トークンベースのバーストモード受付制御に使用されるパラメータを調整するために行われうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、作業要求到着率の不均一性と共に、サービスにより管理されるデータの異なるサブセットに関する作業要求の例示的不均一分散を示す図である。 少なくともいくつかの実施形態による、データアクセスの空間的不均一性の影響を緩和するために実行されうるトークン共有プロトコルの例示的反復を示す図である。 少なくともいくつかの実施形態による、データパーティションが複製される環境において確立されうるトークン共有ピアグループの実施例を示す図である。 少なくともいくつかの実施形態による、二次インデックスの作業量管理に対応するための、データベースサービスにおけるトークン共有の使用の実施例を示す図である。 図２０ａ〜２０ｄは、少なくともいくつかの実施形態による、トークン共有プロトコルの関与者間の例示的メッセージシーケンスの流れを示す図である。 少なくともいくつかの実施形態による、バーストモード処理のトークン共有に対応するために行われうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、リソースを共有する作業対象のプロビジョン能力の合計より大きい処理能力限度を有する共有リソースの実施例を示す図である。 少なくともいくつかの実施形態による、サービスのストレージノードにおいて作業対象により共有されうるリソースの実施例を示す図である。 少なくともいくつかの実施形態による、リソースを共有する作業対象に分配する余剰トークンの数を計算するために行われる処理の実施例を示す図である。 少なくともいくつかの実施形態による、リソースを共有する作業対象に余剰トークンの公平分配を実施するために行われうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、バーストモード処理のために実行されうる価格設定マネジャーの例示的コンポーネントを示す図である。 少なくともいくつかの実施形態による、トークンベースの価格設定ポリシーの例示的要素を示す図である。 少なくともいくつかの実施形態による、バーストモード処理の請求額を決定するために行われうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、条件付きバーストモード価格設定に関連する処理態様を示すフロー図である。 少なくともいくつかの実施形態による、価格設定ポリシーのクライアント選択を可能にするために実行されうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、バーストモードトークンのマーケットプレイスを有効にするために実行されうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、作業対象の異なるパーティション間のトークン譲渡に対して価格設定を行うために実行されうる処理態様を示すフロー図である。 少なくともいくつかの実施形態による、トークンバケットの構成設定の変更に対して価格設定を行うために実行されうる処理態様を示すフロー図である。 少なくともいくつかの実施形態において使用されうる例示的コンピューティングデバイスを示すブロック図である。

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

トークンバケット及びそれに関連する価格設定ポリシーを使用するバーストモード受付
制御を実施するための方法及び装置の様々な実施形態が説明される。本明細書において「
受付制御」という用語は、受信した作業要求（ストレージサービスに対する読出しまたは
書込み要求等）を実行対象として受付けるか否かを判断するために行われる処理を表すの
に使用され、そして受付制御の実行に関わるソフトウェア及び／またはハードウェアエン
ティティ一式は、集合的に「受付コントローラ」と称されうる。トークンバケットを使用
する受付制御は、例えば、ネットワークアクセス可能なサービス（マルチテナントストレ
ージサービスまたはデータベースサービス等）がプロビジョン作業量モデルに対応する様
々な環境において採用されうる。プロビジョン作業量モデルにおいて、作業要求先の所定
オブジェクトは通常、作業要求に関して、特定の作業要求率（「プロビジョン処理能力」
）まで容認可能な応答時間で対応可能であるように設定または構成されうる。本明細書に
おいて「処理能力」という用語は、所定の率で作業要求を完了するリソース（例えば、ス
トレージオブジェクト、データベーステーブル、またはストレージオブジェクトもしくは
データベーステーブルのパーティション）の能力を表すのに使用される。例えば、ストレ
ージリソースの場合、処理能力は、毎秒の論理的もしくは物理的な読出しもしくは書込み
処理数といった、毎秒の作業処理数等の単位で表現されうる。本明細書において「作業対
象」という用語は、作業要求先のネットワークアクセス可能なサービスにより実行及び／
または管理されるリソースまたはオブジェクトを表すのに使用されうる。少なくともいく
つかの実施形態において、所定の受付コントローラは、複数の作業対象に関して受付判断
を行う責任を担いうる。

一実施形態において、例えば、ネットワークアクセス可能なマルチテナントデータベー
スサービスは、毎秒Ｘ回までの読出しまたは書込み処理に対処するように構成されたデー
タベーステーブル（作業対象）を設置しうる（すなわちテーブルのプロビジョン処理能力
は毎秒Ｘ処理に設定されうる）。本明細書において「プロビジョン処理能力」及び「プロ
ビジョン能力」という用語は、同義に使用されうる。少なくともいくつかの実施形態にお
いて、該当するクライアントがテーブルの確立と使用に関する支払いにおいて同意すべき
金額は、プロビジョン能力に基づきうる。例えば、作業オブジェクトに関するクライアン
トとのサービスレベル合意の結果、クライアントは、サービスがプロビジョン能力までの
作業要求到着率に対応可能であるべきであると期待するだろう（少なくとも致命的なイベ
ントが起こる等の異常な状況にない場合）。プロビジョン能力に対応可能であるために、
データベースサービスは、テーブルコンテンツの記憶、かつ所望の処理レベル及び応答時
間の対応に十分な記憶容量及び性能を有するストレージデバイスを特定かつ使用し、作業
量の均衡化目的で多数のこのようなデバイスに対しテーブルコンテンツの一部を分配する
等、様々なステップを実行しうる。このような例示的シナリオにおいて、テーブルに対し
プロビジョン処理能力が決定または設定された後（例えば、指定の処理能力を有するテー
ブルの作成を求めるクライアント要求が受付けられた場合、または対応するサービスレベ
ル合意が関係当事者により認められた場合）、当該テーブルに対する読出しまたは書込み
要求が毎秒Ｘ要求の要求率以下で到着する限り、データベースサービスは一般に、適切な
応答時間で要求を受付け実行する責任を担いうる。しかしながら、オブジェクトに対する
作業要求がプロビジョン能力より高い率で到着すると、オブジェクトは「バーストモード
」運転で作動していると見なされ、サービスはこのようなバーストモード作業要求を受付
け実行するためにベストエフォートを試みるが、一部のバーストモード作業要求は延期ま
たは拒否されうる。いくつかの実施形態において、所定の作業対象のプロビジョン能力は
、ネットワークアクセス可能なサービスにより管理目的のため内部で使用されうる。例え
ば、作業対象及びその作業量を様々な低次リソース（ストレージデバイスまたはストレー
ジサーバ等）へマッピングするパラメータを特定するのにプロビジョン能力が内部で使用
されうるが、サービスはクライアントに対して当該プロビジョン能力を必ずしも明らかに
しなくてよい。

プロビジョン作業量モデルが採用されるいくつかの実施形態において、リソースの利用
可能処理能力を表すために、論理コンテナすなわち「バケット」に配置された作業トーク
ンが使用され、このようなバケットは従って、所定の作業要求が実行対象として受付けら
れるべきか否かを判断するのに使用されうる。本明細書において「利用可能処理能力」と
いう用語は、現在の作業量を考慮した場合、リソースはどれ位の追加処理能力を提供可能
かを示す推定量または測定量を表すのに使用されうる。例えば、所定のストレージデバイ
スは、毎秒１００作業処理（例えば、読出しまたは書込み）のプロビジョン能力を有する
ように構成され、そして所定の秒間、毎秒６０処理の作業量に対応しうる。当実施例にお
いて、当該ストレージデバイスの利用可能処理能力は、毎秒（１００−６０）すなわち４
０処理でありうる。一実装例において、バケットには、プロビジョン能力に相当する毎秒
１００トークンが追加（すなわち「補充」）されうる。作業要求が到着すると、プロビジ
ョン能力バケットと称されうるバケットからトークンが消費されうる。例えば６０の作業
要求が到着し、６０トークンが１秒で消費され、残り４０トークンが利用可能処理能力を
表す。作業要求率がプロビジョン能力より高くならない限り、ストレージデバイスは通常
に、すなわち通常モードで作動しているとみなされ、そして通常処理に適用可能なパラメ
ータセットが受付制御のために使用されうる。さらに詳しく後述されるように、作業要求
到着率がプロビジョン処理能力（例えば、当実施例においては毎秒１００作業処理）を超
える場合、ストレージデバイスは通常モードとは対照的なバーストモードで作動している
とみなされ、別の受付制御パラメータセットが使用されうる。プロビジョン能力バケット
のトークン集合が使い切られると、バーストモードの間に受付制御に対処するために、１
以上の追加バケット（バーストモードバケットと称される）が使用されうる。例えば特定
の制約内でサービスがバーストモード処理に対しベストエフォート対応を提供できるよう
に、異なる実施形態において、バーストモードバケット（複数可）のトークンを追加し消
費するための数多くの異なる手法が取られうる。所定のリソースの利用可能処理能力（ゆ
えにバーストモード処理に対応する作業量レベル）は、基礎をなすハードウェアもしくは
ソフトウェアの性能、及び／または（負荷均衡の考慮、公平性の考慮、ビジネス／価格設
定の考慮、またはハードウェア／ソフトウェアの本来の性能以外の要因の何らかの組合せ
に基づいて）リソースの処理能力を制御もしくは制限するために実施されるポリシー等、
異なる実施形態における様々な異なる要因の任意の組合せに依存しうることに留意された
い。

一実施形態によれば、作業対象に対する作業要求率が特定レベル（例えば、作業対象の
プロビジョン能力）以下である限り、当該作業対象は通常モードで作動しているとみなさ
れ、そして作業要求率が当該特定レベルを超える場合、バーストモードで作動していると
見なされうる。任意の作業要求が受信されると、作業対象に対応付けられた通常モードト
ークンバケットのトークン集合数が特定されうる。通常モードトークンバケットのトーク
ン集合数が閾値基準を満たす場合（例えば、トークン集合数が１より大きい、またはある
閾値を超える場合）、作業対象は通常モードであるということが受付コントローラに対し
示されうる。従って、このような実施形態において、受付コントローラは作動モードを判
定するために直接到着率を監視する必要がなく、その代りにモード判定のために通常モー
ドトークンバケットのトークン数が使用されるため、受付制御のために到着率を監視する
必要のあるシナリオに関連する受付コントローラの作業量が削減される可能性がある。通
常モードにおいて要求は実行対象として受付けられ、そして１以上のトークンが通常モー
ドバケットから消費されうる。

しかしながら、通常モードバケットのトークン集合数が閾値基準を満たさない場合、作
業対象はバーストモードであるとみなされるか、または作業要求が実行対象として受付け
られた場合に作業対象はバーストモードに突入するだろうという判定が少なくとも下され
うる。よって、受付コントローラはバーストモードトークンバケットセットのうち少なく
とも１つのバケットのトークン集合数を特定しうる。１つまたは複数のバーストモードト
ークンバケットのトークン集合数が第二閾値基準を満たす場合（例えば、バーストモード
トークンバケットが少なくとも１つのトークンを含む場合）、作業要求は実行対象として
受付けられうる。１つまたは複数のバーストモードバケットのトークン集合数は、作業要
求が受付けられると、この事実を反映するために修正されうる。少なくとも一実施形態に
おいて、受付コントローラは、例えば作業要求を完了するまたは満たすために行われる作
業量の見積りに基づいて、及び／またはバーストモード処理に適用可能なトークン消費ポ
リシーに基づいて、バーストモードトークンバケット（複数可）から特定の数のトークン
を消費しうる。作業要求が受付けられた後に、１以上の作業処理（例えば、ストレージオ
ブジェクトまたはデータベースオブジェクトを含む作業対象の場合は読出しまたは書込み
）が当該作業要求に従って開始されうる。

少なくともいくつかの実施形態によれば、通常モードトークンバケットのトークン集合
数により作業対象がバーストモードで作動していることが示されない場合、受付制御には
当該通常モードトークンバケットが単独で使用されうる（例えば、前述のように、受付け
られた各作業要求に対し通常モードトークンバケットからいくつかのトークンが消費され
うる）。従って、少なくともいくつかの実施形態において、通常モードの受付制御処理の
間、バーストモードバケット（複数可）のトークン集合が活用されることはありえない。
いくつかの実施形態においては、通常モード処理の間でも、作業要求が受付けられると、
バーストモードバケット及び通常モードバケットのそれぞれのトークン消費ポリシーに従
って、１以上の通常モードトークンバケットだけでなく１以上のバーストモードバケット
からも、トークンが消費されうる。少なくともいくつかの実施形態において、通常モード
の間でも、適用補充ポリシーに従って、バーストモードバケットにトークンが追加されう
ることに留意されたい。作業対象がバーストモードで作動し、かつ１つまたは複数のバー
ストモードバケットのトークン集合数が第二閾値基準を満たさない場合（例えば、作業要
求を受付けるのに十分なトークンがバーストモードバケットに確認されない場合）、いく
つかの実施形態において、作業要求は拒否、延期、または再試行されうる。少なくともい
くつかの実施形態において、所定の作業要求を受付けるのに十分なトークンが利用不可能
な場合、当該作業要求は、当該作業要求を送信したクライアントに知らせることなく１回
以上（例えば、設定可能な再試行上限回数まで）再試行されうる。作業要求が最終的に受
付けられた場合、当該作業要求を出したクライアントは、当該要求関して通常の総応答時
間よりも長い総応答時間を経験しうるが、当該要求が少なくとも１回拒否されたことには
気付かずにいるだろう。

さらに詳しく後述されるように、通常モードトークンバケット及びバーストモードトー
クンバケットは、様々な時点においてそれぞれの補充ポリシーに従ってトークンが補充さ
れうる。一実施形態において、通常モードトークンバケットは、最大トークン集合数限度
を条件に、作業対象のプロビジョン能力と等しい率で補充されうる。少なくともいくつか
の実施形態において、このような通常モードトークンバケットは、プロビジョン能力トー
クンバケットと称されうる。少なくともいくつかの実施形態において、１以上のバースト
モードトークンバケットは、作業対象のプロビジョン処理能力に比例する率（必ずしも等
しくはない率）で補充されうる。バーストモードバケットの補充率を作業対象のプロビジ
ョン能力と比例するように維持することで、異なる作業対象がそれぞれのプロビジョン能
力に比例するバーストモード作業量に対処することが確実となりうる。例えば、データベ
ースサービスのクライアントＣ１がプロビジョン能力Ｐ１のテーブルＴ１に対し金額Ａ１
を支払い、かつクライアントＣ２がプロビジョン能力Ｐ２のテーブルＴ２に対し金額Ａ２
を支払う（Ｐ１＞Ｐ２かつＡ１＞Ａ２）場合、Ｔ１に対するバーストモードトークンバケ
ット（複数可）は、Ｔ２に対するバーストモードトークンバケット（複数可）より高い率
で補充されうるため、Ａ１＞Ａ２であることから期待されるように、Ｔ１はＴ２と比べて
より高い作業要求のバースト率に対応可能である。

いくつかの実施形態において、サービスは異なる種類の作業要求到着率バーストに対し
、異なる受付制御パラメータを使用しうる。例えば、プロビジョン能力毎秒Ｐ処理のサー
ビスＳにより実行される作業対象Ｗを考察する。毎秒Ｐより大きい率の作業要求到着は、
バーストとして分類されうる。しかしながら、全てのバーストが同じ様にサービスＳに影
響を与えるとは限らない。例えば、クライアントが作業要求を毎秒１００Ｐの率で送信し
た場合、サービスＳが、他のクライアントに悪影響を与える、またはリソースに尽きるこ
となく、要求に対処できるのは、非常に短い時間でしかない。しかしながら、クライアン
トが作業要求を毎秒２Ｐの率で送信した場合、サービスはより長時間、要求を対処可能で
ある。よって、一実施形態において、到着率における急激で短期のピークに対処するピー
クバーストバケット、及びより低い最大要求率でより長いバーストに対処する持続バース
トバケット等、複数のバーストモードトークンバケットが設定されうる。ピークバースト
トークンバケット及び持続バーストトークンバケットの組合せは、本明細書において「複
合」トークンバケット（もしくは複合バケット）と称されうる。このような実施形態にお
いて、受付コントローラは、作業対象に対する作業要求が実行対象として受付けられるピ
ークバースト率、及びピークバースト率で作業要求が受付けられる最大継続時間を示すピ
ークバースト時間窓サイズを決定しうる。さらに、受付コントローラは、ピークバースト
率より低い持続バースト率、かつピークバースト時間窓サイズより大きい持続バースト時
間窓サイズを決定しうる。持続バースト時間窓サイズは、持続バースト率で作業対象に対
する作業要求が受付けられる最大継続時間を示す。いくつかの実施形態において、時間窓
サイズは一般に、それぞれのバースト率が特定の条件下（例えば、バースト状態の間は補
充なしと仮定する）で対応可能な継続時間を示すが、実際に達成される継続時間は時間窓
サイズに正確には一致し得ない（例えば、バースト状態の間に補充処理が実際行われたた
め）。２つのバーストモードバケットの最大トークン集合数は、それぞれの最大バースト
率に基づいて設定されうる。例えば一実装例において、ピークバーストバケットの最大ト
ークン集合数は、ピークバースト率とピークバースト時間窓サイズの積に設定され、一方
持続バーストバケットの最大トークン集合数は、持続バースト率と持続バースト時間窓サ
イズの積に設定されうる。両バケットはバーストモード処理の間、受付制御のために使用
されうる。例えば、作業対象に対する作業要求を受信したことに応じて、受付コントロー
ラは、ピークバーストトークンバケット及び持続バーストトークンバケットのそれぞれの
トークン集合数に少なくとも部分的に基づいて、作業要求を実行対象として受付けうる。
少なくともいくつかの実施形態において、ピークバーストバケット及び持続バーストバケ
ットに対し、異なる消費率及び／または異なる補充率が適用されうる。

このような実施形態において、複合バケット技術を使用することで、受付コントローラ
は、短時間の非常に高いバースト率、及び長時間のより低いバースト率に対応可能である
。作業対象のプロビジョン能力（ｐｒ）が毎秒１００処理（１００処理／秒）であり、ピ
ークバーストバケットＰＢＢに対応付けられたピークバースト率（ｐｂｒ）が１０００処
理／秒であり、ピークバースト時間窓サイズ（ｐｂｗ）が６秒であり、持続バースト時間
窓ＳＢＢに対応付けられた持続バースト率（ｓｂｒ）が２００処理／秒であり、そして持
続バースト時間窓サイズ（ｓｂｗ）が６０秒である、例示的シナリオを考察する。さらに
、ピークバーストバケットの最大トークン集合数（最大ＰＢＢ）は、ｐｂｒとｐｂｗの積
（１０００^*６、すなわち６０００トークン）に設定され、そして持続バーストバケット
の最大トークン集合数（最大ＳＢＢ）は、ｓｂｒとｓｂｗの積（２００^*６０、すなわち
１２０００トークン）に設定されると仮定する。時間Ｔに始まる作業要求のバーストＢを
考察する（すなわち、当例示的シナリオにおいては、受付コントローラにより通常モード
バケットは時間Ｔに通常モード処理を行うのに十分なトークンを有さないと判定されたた
め、バーストモードパラメータが適用される）。説明を簡易にするために、当実施例に関
して、ＰＢＢは毎秒２００トークンが補充され（最大ＰＢＢを上限とする）、かつＳＢＢ
は毎秒１００トークンが補充され（最大ＳＢＢを上限とする）、かつ作業対象はバースト
モード状態のままであると仮定する。各作業要求は１個の実作業処理（例えば、読出しま
たは書込み）に至るとし、そして所定の要求を受付けるために、ＰＢＢ（ピークバースト
バケット）及びＳＢＢ（持続バーストバケット）の各バーストモードバケットから１トー
クンが消費される。ＰＢＢ及びＳＢＢの両者は時間Ｔに最大限のトークンを有すると仮定
する。すなわちＰＢＢは６０００トークンを有し、ＳＢＢは１２０００トークンを有する
。

初めに、バーストＢが１０００要求／秒の要求到着から成るシナリオを考察する。ＰＢ
Ｂは６０００トークンで始まり、要求到着により１０００トークンが消費され、そしてＰ
ＢＢの補充ポリシーに従って２００トークンが追加されたため、１秒後の時間Ｔ＋１にＰ
ＢＢのトークン集合数は（６０００−１０００＋２００）、すなわち５２００トークンに
なりうる。同様に、時間Ｔ＋１にＳＢＢのトークン集合数は（１２０００−１０００＋１
００）、すなわち１１１００トークンになりうる。作業要求が１０００要求／秒で到着す
る間、続く数秒間の秒毎に、ＰＢＢの正味のトークン集合数は８００トークン減り、一方
ＳＢＢのトークン集合数は９００トークン減る。従って、ＰＢＢのトークン集合数（集合
（ＰＢＢ）と称する）及びＳＢＢのトークン集合数（集合（ＳＢＢ）と称する）は以下の
ように低下する。時間Ｔ＋２に、集合（ＰＢＢ）＝４４００、集合（ＳＢＢ）＝１０２０
０となり、時間Ｔ＋３に、集合（ＰＢＢ）＝３６００、集合（ＳＢＢ）＝９３００となり
、時間Ｔ＋４に、集合（ＰＢＢ）＝２８００、集合（ＳＢＢ）＝８４００となり、時間Ｔ
＋５に、集合（ＰＢＢ）＝２０００、集合（ＳＢＢ）＝７５００となり、時間Ｔ＋６に、
集合（ＰＢＢ）＝１２００、集合（ＳＢＢ）＝６６００となり、時間Ｔ＋７に、集合（Ｐ
ＢＢ）＝４００、集合（ＳＢＢ）＝５７００となる。

Ｔ＋７以降の秒間もバーストＢが毎秒１０００要求で続くとすると、当実施例において
、ＰＢＢはトークンを使い切ることとなり、少なくとも一部の要求は拒否されうる（ＳＢ
Ｂはまだ十分なトークンを有しているにもかかわらず）。このように当実施例において、
毎秒１０００要求という高到着率のバーストは、約７、８秒間しか対応できない。

これに対して、バーストＢが毎秒２００要求から成るシナリオを考察する。ＰＢＢは、
毎秒、２００トークンが消費され、かつ２００トークンが補充され、正味のトークンを損
失しない。ＳＢＢ（１２０００トークンで開始）は、毎秒、２００トークンが消費され、
かつ１００トークンが補充され、１００トークンを損失する。よって、ＳＢＢを使い尽く
すのに約１２０００／１００＝１２０秒かかるため、２００要求／秒のバーストは、約１
２０秒間想定されるパラメータ設定で対応可能である。このように当例示的シナリオにお
いて、２００要求／秒というより低いバースト率は、１０００要求／秒という急激なバー
ストと比べて、より長い時間対応されうる。様々な実施形態において、実際の演算はさら
に複雑でありうる。例えば、通常モードバケットは補充されると活用されるようになるた
めバーストモード到着率は仮定されるように横ばいのままではなく、そして他の要因（異
なる種類の要求に対し異なる数のトークンを必要とする消費ポリシー等）を考慮する必要
があるだろう。

いくつかの実施形態において、それぞれのバーストモードバケットが作業要求の異なる
カテゴリごとに使用されうる。例えば、ストレージサービスまたはデータベースサービス
の環境においては、読出し処理要求のために１以上のバーストモードバケットが保持され
、そして書込み処理要求のために１以上のバーストモードバケットが保持されうる。プロ
ビジョン能力バケットが使用される一実施形態において、特定の時間間隔後にプロビジョ
ン能力バケットの一部のトークンが未使用のままである場合、未使用トークンは「貯蓄さ
れる」、すなわち１以上のバーストモードバケットへ論理的に譲渡され、少なくとも原則
的にクライアントは未使用のプロビジョン能力トークンをバースト状態の間に使用できる
こととなる。いくつかの実施形態において、１以上の共有リソースの処理能力限度を考慮
するために、バーストモードトークンバケットセットが使用されうる。例えば、データベ
ーステーブルのパーティションが、他のテーブルのパーティションも配置される共有スト
レージデバイスに配置される場合、前述のバーストモードバケットを使用することに加え
、共有リソース能力バケットが共有ストレージデバイスの利用可能処理能力を表すのに使
用され、そして作業要求を受付けるために共有リソース能力バケットからもトークンが消
費されうる。いくつかの実施形態において、所定の作業要求を受付けるために消費される
トークンの数は当該要求に必要となる作業の見積りに基づき、そして初期の見積りが不正
確であると判明した場合、実際に行われる作業量が明らかになった時に、様々なバケット
のトークンが消費されうる（または様々なバケットにトークンが追加される）。バースト
モード処理に対するトークンベースの受付制御ポリシーのこれら及び様々な別の態様に関
する詳細が、以下に提供される。

一部の種類のネットワークアクセス可能なストレージ関連サービスの場合、いくつかの
実施形態において、それぞれトークンバケットセットを使って独立して受付制御が行われ
る複数の作業対象に対し、所定のクライアントデータセットが分配されうる。例えばデー
タベースサービスは、Ｎ個のパーティションセットを有する大きなテーブルを管理し、所
定のパーティションに対する作業要求を受付けるか否かに関するトークンベースの判断が
、他のパーティションから独立して行われる。このような実施形態において、クライアン
トの作業量の不均一性の問題には、時間的不均一性の特質に加えて、空間的特質も追加さ
れうる。つまり、全てのクライアントデータの合計作業量から考察すると、作業要求が経
時的に不均一に分散している（すなわち、一部の時間帯において作業要求が他の時間帯よ
りはるかに高い率で到着する）だけでなく、作業要求はデータ空間上も不均一に分散して
いる（すなわち、クライアントデータの一部のサブセットは他のクライアントデータのサ
ブセットより頻繁にアクセス及び／または更新される）という場合がありうる。空間的不
均一性を有するいくつかの例示的シナリオにおいて、少なくとも一部の時間帯において、
所定のクライアントＣ１が所有する１つのデータパーティションＰ１における利用可能な
トークン数は、同一のクライアントＣ１が所有する別のデータパーティションＰ２におけ
る利用可能なトークン数よりはるかに大きいが、作業量に関してはＰ１よりＰ２のほうが
はるかに大きいという場合がありうる。全てのクライアントパーティションが一体として
みなされた場合に作業要求拒否を回避するのに十分なトークンが利用可能であるにもかか
わらず、このような事例は、大量にアクセスされるパーティションにおいて作業要求拒否
をもたらしうる。このため、少なくともいくつかの実施形態において、作業対象グループ
におけるトークン共有機構が実行されうる。

トークン共有が実施される一実施形態において、複数の作業対象が、それぞれの受付制
御用のトークンバケットと共に構成されうる。トークン共有プロトコルの反復は、特定の
作業対象ＷＴ１においてトークン共有評価基準が満たされたと判断された時に開始される
。つまり、ＷＴ１は、１以上の他の作業対象から追加トークンを取得するか、または１以
上の他の作業対象に対しトークンを譲渡するか、どちらを試みる方がＷＴ１にとって有益
であるかを評価するように構成されうる。異なる実施形態において、このような評価を始
めるために異なる基準が使用されうる。例えばいくつかの実施形態において、各作業対象
は、デフォルトで毎Ｘ秒または分に一度トークン共有を評価するように構成され、別の実
施形態においては、所定の作業対象は、自身のトークンバケットのあるセットにおけるト
ークン数がある閾値より低く、または別の閾値より高くなった場合に、または作業要求に
対する拒否率が閾値より高くなった場合に、トークン共有を評価するように構成されうる
。

評価プロセスの一部として、いくつかの実施形態において、作業対象ＷＴ１は、あるト
ークンバケットセットに属するトークン集合数情報を交換する第二作業対象ＷＴ２を特定
しうる。例えば一実装例において、バーストモードトークンバケットのトークン集合数が
ＷＴ１とＷＴ２の間で交換されうる。トークン数の比較に少なくとも一部基づいて、２つ
の作業対象は、いくつかのトークンが共有すなわち譲渡されるべきかを判断しうる。例え
ば、より多いトークンを有する作業対象は譲渡元バケットから、より少ないトークンを有
する作業対象の譲渡先バケットに対し、一部のトークンを提供することに同意しうる。ト
ークンを渡す判断が下されると、譲渡先バケットのトークン集合数は、いくつかのトーク
ンＮｔ分増加し、そして譲渡元バケットのトークン集合数はＮｔ分増加しうる。トークン
が譲渡された後、関与している両作業対象における新たに修正されたトークン集合数を使
って受付制御判断が下されうる。本明細書において、トークン共有プロトコルに関与する
ものは、「トークン共有ピア」と称され、そして当該プロトコルに関与する作業対象グル
ープは、「トークン共有グループ」または「トークン共有ピアグループ」と称されうる。
いくつかの実装例において、トークン共有プロトコルステップ（例えば、プロトコルの評
価ステップ及びトークン共有ステップ）は、例えば、トリガー条件が満たされたことに基
づき、または選択された回数ランダムに、または決定性スケジュールに従って、反復的に
行われうる。少なくともいくつかの実施形態において、異なる作業対象の対が異なる反復
に関与しうる。すなわち、トークン共有ピアグループの全ての作業対象が、所定のプロト
コル反復に関与するわけではない。いくつかの実施形態において、トークン共有プロトコ
ルは、トークン共有グループの作業対象の受付コントローラによって集合的に実行されう
る。

トークン共有グループの構成員は、異なる実施形態におけるいくつかの要因のいずれか
に基づきうる。いくつかの実施形態において、例えばトークンは単一のデータベーステー
ブルのパーティション間でのみ共有されうる。別の実施形態においては、トークンは、同
一のクライアントまたはある協働クライアントセットが所有するテーブルセットの全ての
パーティション間で共有されうる。さらに詳しく後述されるように、非リレーショナルデ
ータベースサービスが派生テーブルを利用する所定のベーステーブルに対して二次インデ
ックスを実装する一実施形態において、トークン共有は、ベーステーブルのパーティショ
ン及び派生テーブル（複数可）のパーティション間で実行されうる。いくつかの実施形態
において、クライアントはトークン共有グループの構成員作業対象を明確に指定可能であ
るが、別の実施形態においては、クライアントではなくサービスがトークン共有構成員を
決定しうる。同様に、トークン共有が使用されるトークンバケットの特定の種類は、異な
る実施形態において異なりうる。例えばいくつかの実施形態において、トークンはバース
トモードトークンバケット間のみの作業対象により共有されるが、別の実施形態において
は、トークンはさらに、または代わりに通常モードバケット間で共有されうる。

異なる作業対象にそれぞれのプロビジョン処理能力が割当てられたいくつかの実施形態
において、異なるクライアントに属するテーブルパーティション等のいくつかの作業対象
は、ストレージデバイス等の単一のリソースを共有しうる。共有されたリソースはそれ自
身の処理能力限度ＴＬを有し、これはリソースを共有する作業対象セットのプロビジョン
能力（ＰＣ）の合計より一般的に高くありうる。共有リソースのオーバーロード状態を回
避するために、例えば、作業対象において実施されるネットワークアクセス可能なサービ
スは、作業対象がクライアント作業処理を完了するために依存する共有リソースの処理能
力限度を、作業対象のプロビジョン能力の合計が超えないように、作業対象を構成してい
る。このようなシナリオの作業対象は、「リソース共有グループ」の構成員と称されうる
。このような作業対象はそれぞれ、１以上の通常モードトークンバケット及び１以上のバ
ーストモードトークンバケット等の関連トークンバケットセットを有しうる。

従って、少なくともいくつかの実装例において、共有リソースにより対応可能な最大処
理能力に関して、リソース共有グループのプロビジョン能力の合計と相対する余剰能力の
バッファが保持されうる。つまり、リソース共有グループの全作業対象がこれらの全プロ
ビジョン能力に相当する作業要求を受付けたとしても、共有リソースは追加の負荷に対処
可能である。いくつかの事例において、例えばリソース共有グループの１以上の作業対象
が対処不可能な高い作業要求到着率のバーストに遭遇した場合、いくつかの追加トークン
をリソース共有作業対象に分配（例えば、作業対象のそれぞれのバケット補充ポリシーに
基づいて、作業対象に既に生成されたトークン数に加えて分配）できると便利だろう。追
加トークンは、共有リソースの余剰能力バッファの少なくとも一部を表すものとみなされ
うる。このような「余剰」トークンは、余剰トークンを分配する判断が下される前に必ず
しも任意の所定のバケットに対応付けられるとは限らず、すなわち、少なくともいくつか
の実施形態においては、分配のために新規のトークンが生成されうることに留意されたい
。別の実施形態においては、余剰トークンは、共有リソースの処理能力が明確に示される
バケットに存在しうる。ネットワークアクセス可能なサービスのプロバイダは、このよう
な余剰トークンを分配する際、あるレベルの分配公平性の確保を所望しうる。これにより
、例えば、所定クライアントの作業対象ＷＴ１は、同一のリソースを共有する別のクライ
アントの作業対象ＷＴ２に余剰トークンが全く提供されない中、全ての余剰トークンを蓄
積することが許可されるという特別待遇を受けない。余剰トークンを分配する際、いくつ
かの異なる公平性関連要因を教慮する必要がありうる。例えば、一実施形態において、余
剰トークンは、作業対象のそれぞれのプロビジョン能力に基づいて、及び／または作業対
象の最近の作業要求到着率に基づいて、作業対象に分配されうる。

前述のように、少なくともいくつかの実施形態によれば、ネットワークアクセス可能な
サービスのいくつかの作業対象（データベースサービスのデータベーステーブルパーティ
ション等）は、受付けた作業要求に応じて共有リソース（共有ストレージデバイス等）を
使用するように構成されうる。このような作業対象はそれぞれ、到着作業要求の受付制御
のために設定された各自のトークンバケットセットを有しうる。すなわち、所定の作業対
象において作業要求を実行対象として受付けるか拒否するかに関する判断は、当該作業対
象の１以上のバケットのトークン集合数に基づいて行われうる。いくつかの実施形態にお
いて、共有リソースに対応付けられたトークン分配器等のサービス管理コンポーネントは
、あるスケジュールに従って開始された各サイクルまたは反復で、または一部のトリガー
条件の検出に基づいて、トークン分配を反復して行うように構成されうる。少なくともい
くつかの実施形態において、トークン分配器は、トークン分配プロトコルの反復に対応す
る所定時間において、リソース共有作業対象のバケットに分配する余剰トークンの合計数
を決定する。合計数は、例えば共有リソースの処理能力限度と作業対象のプロビジョン能
力の総数の差の関数でありうる。

トークンは、異なる実施形態におけるいくつかの要因の組合せに基づいて、作業対象間
に分配されうる。いくつかの実施形態において、異なる作業対象に提供される特定の数の
トークンは、当該作業対象の相対到着率及び相対プロビジョン能力に少なくとも一部基づ
いて、別の関数として計算されうる。リソース共有グループの各作業対象の作業要求到着
率は監視され、そして各継続５分間隔の平均到着率等、経時的な到着率に関するある統計
計量が計算されうる。所定のトークン分配反復に関して、最近のいくつかの間隔における
到着率計量が計算に使用されうる。例えば、所定の５分間トークン分配反復に対し、前の
５分間の到着率の比が考慮されうる、または最近のＫ個の５分間隔の到着率の比が考慮さ
れうる。トークンの合計数がそこで、到着率の比かつプロビジョン能力の比に基づいて、
１以上の作業対象に分配されうる（例えば、作業対象のそれぞれのバーストモードバケッ
ト等、作業対象の１以上のバケットのトークン集合を増加させることによって）。分配に
より調整されたトークンバケット集合（複数可）は、作業対象における受付制御のために
利用されうる。

少なくともいくつかの事例において、例えば作業対象のプロビジョン能力の合計が共有
リソースにより対応可能なピークの処理能力に近いことが判明した場合、または到着率が
非常に低い場合、分配器は、所定の反復において余剰トークンを全く分配しないと決定し
うることに留意されたい。例えば異なる作業対象において、どれだけ分配機構が作業要求
拒否を削減または回避することに成功しているかに基づいて、時間の経過と共に、トーク
ン分配機構における到着率計量及び／またはプロビジョン能力計量に割当てられた比重が
調整されうる、またはトークン分配を統御する機能が調整されうる。いくつかの実施形態
において、余剰トークンはバーストモードバケットにのみ追加され、一方別の実施形態に
おいては、トークンはさらに、または代わりに、通常モードバケットに追加されうる。い
くつかの実施形態において、作業要求到着率及びプロビジョン能力以外の要因の組合せが
、余剰共有リソース能力の公平な分配のために使用されうる。少なくともいくつかの実装
例において、トークンを分配するか否か、及びいくつのトークンを分配するかを決定する
際、複数の共有リソースの処理能力限度が考慮されうる。

少なくともいくつかの実施形態において、トークンベースの受付制御が使用されるネッ
トワークアクセス可能なサービスを利用するクライアントは、バーストモードの間に行わ
れる処理に対する金額、または今後のバースト時作業量を見越して行われうる処理（トー
クン共有及び余剰トークン分配等）に対する金額とは異なる金額が、通常モード処理に対
して請求されうる。いくつかのこのような実施形態において、通常モードバケット及びバ
ーストモードバケットのそれぞれの価格ポリシーが、トークン消費及び／または譲渡に対
応付けられうる。いくつかの実施形態において、サービスの価格設定マネジャーコンポー
ネントは、様々な条件下における様々なバケットのトークン集合数変更に対応付けられる
価格設定ポリシーを定義し、かつ受付制御と連携して（または一部として）実施する責任
を担いうる。一実施形態において、特定のトークンバケットに適用されるトークン価格設
定ポリシーが特定されうる（例えば、クライアントによって選ばれた価格設定ポリシーに
基づいて、またはサービスの内部構成設定に基づいて）。価格設定ポリシーは、ポリシー
が適用されるトークン集合数変更の種類と、１以上の適用基準（例えば、特定の時間窓の
間のみポリシーが適用されるか否か、またはバーストモード処理の間にいくつかのバケッ
ト集合数が特定の閾値より小さくなった時のみポリシーが適用されるか否か）と、トーク
ン集合数に対する特定の変更に関しクライアントに請求する価格を計算するのに使用され
うる式または関数とを定義する。いくつかの実施形態において、クライアントは、トーク
ン集合数変更の異なるカテゴリに対して異なる金額が請求されうる。例えば一事例におい
て、クライアントは、特定のバーストモードバケットＢ１から任意のトークンを消費した
場合にある料金が請求され、そしてバケットＢ２からバケットＢ１へトークンが譲渡され
た場合には別の料金が請求される。少なくとも一実施形態において、クライアントは、い
くつの（そしてどの種類の）トークンバケットが受付制御に使用されたかに基づいて、異
なる金額が請求されうる。例えば、複合トークンバケットを使って多種類のバーストモー
ド様態に対応することを所望するクライアントは、より少ないバーストモードバケットを
使用するより単純な技術を利用する意思のクライアントより、多く請求されうる。価格設
定マネジャーは、様々なトークンバケットの集合数に対する変更を、経時的に、例えばバ
ーストモード処理の様々な時間帯において、記録しうる。クライアントの請求額は、記録
された集合数の変更に基づいて作成されうる。

少なくとも一実施形態において、ネットワークアクセス可能なサービスは、例えば、ク
ライアントがバーストモード及び／または通常モード作動中に受付制御に使用可能なトー
クンを売る、買う、または交換するために利用しうるプログラム的インターフェイス（１
以上のウェブページ、ウェブサイト、グラフィカルユーザインターフェイス、コマンドラ
インツール、及び／またはＡＰＩ等）を実装することで、トークンマーケットプレイスを
実現しうる。いくつかのこのようなマーケットプレイスにおいて、例えば、所定の先の時
間帯において自身のトークンの一部は使用されないであろうことを認識しているクライア
ントは、オークション機構を使用した入札のためにトークンの可給性を宣伝しうる。当初
の予測よりも多い作業量（ゆえに自身の作業対象のプロビジョン能力より多い作業量）に
対応する必要のある別のクライアントは、トークンに対して入札し、（入札が成功した場
合）売り手からトークンを購入しうる。少なくともいくつかの実施形態において、ネット
ワークアクセス可能なサービスの価格設定マネジャー及び／または他のコンポーネントは
、このようなオークション及び他のマーケットプレイスの取引を簡易化し、トークン譲渡
及び価格の経過を記録し、そしてマーケットプレイスの取引をクライアントに対し作成さ
れた請求額に適切に取入れうる。価格マネジャー及び関連コンポーネントの機能性の様々
な態様に関する追加詳細もまた以下に提供される。
例示的システム環境

図１ａは作業要求到着率の例示的変動を示す図であり、図１ｂは少なくともいくつかの
実施形態による、そのような変動が起こった際トークンバケットを使用して受付制御判断
を行いうるシステムを示す図である。図１ａにおいて、Ｘ軸は時間を表し、Ｙ軸はネット
ワークアクセス可能なサービスのストレージオブジェクトまたはデータベーステーブル等
の作業対象に対する作業要求の到着率１１０を表す。所定の作業要求により、要求クライ
アントが作業対象に関連する特定の論理処理または物理処理のセットの実行を所望するこ
とが示されうる。例えば、単一の作業要求は、作業対象の一部に対する１以上の読出し処
理、１以上の修正処理、一連の計算、作業待ち行列への挿入または作業待ち行列からの除
去、またはこのような処理の何らかの組合せに変換されうる。少なくともいくつかの実施
形態において、クライアントが作業要求において比較的高い次元の論理処理を示すと、作
業対象を実行するサービスは、作業要求が受付けられた場合に実行する必要がありうる低
次の物理処理または論理処理のある該当セットを特定する責任を担いうる。図１ａ及び１
ｂは、作業対象における平均的または典型的なカテゴリの作業要求の到着率及び受付制御
を例示する。さらに詳しく後述されるように、一般に到着率は作業要求の異なるカテゴリ
に関して個別にプロットされ、そして異なる作業要求カテゴリに対してそれぞれの受付制
御パラメータが使用されうる。図１ａにおいて、作業対象のプロビジョン能力１１２（画
一のまたは平均的な作業要求と仮定する）が、Ｙ軸に「ｐｒ」で交わる水平線により表さ
れる。図１ａのように、到着率は一連の時間間隔にわたって監視されうる（例えば、到着
する作業要求の数が毎秒測定され、そして要求数／秒がグラフに描かれうる）。表される
ように、作業要求の到着率は時間と共に変化する。一部の時間帯において、到着率がプロ
ビジョン能力ｐｒより少ないと、通常期Ｎ１、Ｎ２、及びＮ３等のこれらの時間帯におい
て作業対象は通常モードであるとみなされる。バースト期Ｂ１及びＢ２等、到着率がｐｒ
を超える間、作業対象はバーストモードで作動しているとみなされうる。

いくつかの実施形態において、ネットワークアクセス可能なサービスは、ｐｒまでの作
業要求率に対応する義務がありうる（例えば、サービスレベル合意により契約上義務があ
りうる）。図１ｂに示されるように、サービスの受付コントローラ１８０は、通常モード
の間、受付制御を判断する１以上のバケットを含む通常モードトークンバケットセット１
２０を使用するように構成されうる。受付コントローラ１８０は、バーストモードの間、
通常モードバケットに適用されるパラメータセットとは異なるパラメータセットが適用さ
れた１以上の受付制御用のトークンバケットを含むバーストモードトークンバケットセッ
ト１２５を使用するように構成されうる。少なくとも一実施形態において、作業要求１７
０が受信されると、受付コントローラは初めに通常モードバケットのトークン集合数を特
定しうる。通常モードバケットのトークン集合数が閾値より小さい場合（例えば、作業要
求１７０を受付けることで消費されるトークン数Ｎより小さい場合）、受付コントローラ
は、作業対象１０２がバーストモードにある、または作業要求１７０が実行対象として受
付けられた場合には、作業対象１０２がバーストモードに入るだろうと断定しうる。

例えば通常モードバケットセットを使用して、バーストモードパラメータを適用すると
決定した際、描写された実施形態において、受付コントローラ１８０は、バーストモード
トークンセット１２５のうち少なくとも１つのバケットのトークン集合数を特定しうる。
トークン集合数が特定の基準を満たす場合、例えば少なくとも１つのバーストモードトー
クンバケットにおいてＮトークンが利用可能である場合、作業要求１７０が実行対象とし
て受付けられ、そして受付済作業要求に対応する１以上の処理１７９が開始されうる。バ
ーストモードバケットセット１２５のトークン集合数が特定の基準を満たさない場合、矢
印１８９により示されるように、作業要求１７０は拒否されうる。様々な実施形態におい
て、通常モードバケットセット１２０及びバーストモードバケットセット１２５の各トー
クンバケットに対し、各自のパラメータ及びポリシーのセットが適用されうる。例えば、
異なるバケットは、異なるトークン消費ポリシー（様々な状況において消費されるトーク
ン数を示す）、及び異なるトークン補充ポリシー（トークンが追加される状況、及び毎秒
追加されるトークン数を示す）を有しうる。描写された実施形態において、一般にサービ
ス及び受付コントローラ１８０は、通常モード処理に対応し、そしてバーストモード処理
の間、クライアント要求を受付け完了するためにベストエフォートを行う義務がありうる
。

作業対象がそれぞれの定義されたプロビジョン処理能力を必ずしも有さないいくつかの
実施形態において、例えば、サービスレベル合意により、サービスプロバイダが、一部ま
たは全ての作業対象に関して明確に指定されたある処理能力レベルに対応する義務を負わ
ないいくつかの実施形態において、受付制御のためにトークンバケットを使用する前述の
ような技術が使用されうることに留意されたい。例えば一実施形態において、サービスプ
ロバイダは、作業要求到着率が毎秒Ｒ処理を超えると必ずバーストモードが起こると簡潔
に定義し、受付制御のためにバーストモードトークンバケットをこのような条件下で使用
しうる。従って、異なる実施形態において、作業対象がバーストモードにあるか否かの判
断を行うために取られる手法が異なりうる。いくつかの事例においては、プロビジョン処
理能力が通常モードとバーストモードの間の境界線を定義するが、別の実施形態において
は、他のバーストモードの定義が使用されうる。
トークンベースの受付制御の概要

図２は、少なくともいくつかの実施形態による、トークンベースの受付制御機構の高次
概観図である。トークンを含む単一のバケット２０２を使用する機構が、簡潔な説明のた
めに示される。前述のように、いくつかの実施形態において、通常モード受付制御用の１
以上のバケット、及びバーストモード受付制御用の１以上のバケット等、複数のバケット
の組合せが使用されうる。当該機構によれば、データオブジェクト、オブジェクトパーテ
ィション、またはパーティションレプリカ等の特定の作業対象１０２に関連する受付制御
目的のために設定されたバケット２０２（例えば、少なくともいくつかの実施形態におい
て、ソフトウェアプログラム内にデータ構造として実装されうる論理コンテナ）には、矢
印２０４Ａにより示されるように、バケット初期化中にトークン２０８の初期セットが追
加されうる。初期集合数は、例えば、作業量の予測、サービスレベル合意、該当するデー
タオブジェクトを所有または管理するクライアントにより指定されたプロビジョニング予
算、または様々な実施形態におけるこのような要因の何らかの組合せに基づいて、決定さ
れうる。いくつかの実施形態において、一部の種類のバケットに対し、初期集合数はゼロ
に設定されうる。いくつかの実装例においては、少なくとも１つのバケットの初期集合数
は、当該バケットに設定された最大集合数に設定されうる。

描写された実施形態において、新規の作業要求１７０（ストレージオブジェクトまたは
データベースオブジェクトの場合は、読出し要求または書込み要求等）の指示が受付コン
トローラ１８０に受信されると、受付コントローラは、Ｎ個のトークン（Ｎは１以上であ
り、実行内容または構成パラメータに依存する）がバケット２０２に存在するか否か判断
を試みうる。その数のトークンが当該バケットにおいて利用可能な場合、作業要求１７０
は実行対象として受付または許可され、そして当該バケットからトークンが消費または除
去されうる（矢印２１０）。Ｎトークンが存在しなければ、作業要求１７０は拒否されう
る。例示的実施例において、作業要求１７０Ａは受付けられ、作業要求１７０Ｂは拒否さ
れ、そして作業要求１７０Ｃ、１７０Ｄ、及び１７０Ｅは受付コントローラ１８０により
まだ検討されていない。

図３を参照して後述するように、バケット２０２は、矢印２０４Ｂにより示されるよう
に、バケットに対応付けられた補充率等の構成パラメータに基づいて経時的に補充または
再追加もされうる。いくつかの実装例において、トークン補充処理は消費処理と同時に起
こりうる、または時間的に近接して行われうる。例えば、単一のソフトウェアのルーチン
内で、要求を受付けることでＮトークンが消費され、そして補充率及び前回バケットが補
充されてから経過した時間に基づいてＭトークンが追加されうる。同様に後述されるよう
に、いくつかのシナリオにおいて、いくつかのバケットはまた、他のバケットの未使用の
トークンの数に基づいて追加されうる。いくつかの実施形態において、例えば構成パラメ
ータを使用して、バケットが保持してもよいトークン最大数、及び／またはトークン最小
数が制限されうる。異なる実施形態において、特に所定のオブジェクトまたはリソースに
対し受付を制御するために多数のバケットが一緒に使用された時に、構成パラメータ設定
の様々な組合せを利用して、かなり高度な受付制御スキームが実行されうる。

単純な一例示的シナリオにおいて、毎秒１００作業要求という安定した負荷に対応する
ために、図２のバケット２０２は、初期集合数が１００トークン、最大許容集合数が１０
０トークン、そして最小許容集合数がゼロトークンに設定されうる。Ｎは１に設定され、
そして補充率は毎秒１００トークンに設定され、１０ミリ秒毎に一度、１トークンが補充
目的で追加されうる（最大集合数制限を超えないという前提）。作業要求１７０が到着す
ると、各作業要求に１トークンが消費されうる。各秒均一に分散した毎秒１００作業要求
という定常作業量が適用される場合、補充率及び作業量到着率は釣り合いうる。いくつか
の実施形態において、上記のバケットパラメータを考慮した場合、このような定常作業量
は無期限に対応されうる。

上記の実施例を拡張させて、到着率及び／または補充率が均一でないとすると、一部の
（一般に短い）時間間隔においてバケット２０２が空の状態になるシナリオが起こりうる
（例えば、ある急速に連続した作業要求のセットにより、補充機構が元に戻すことのでき
るトークン数より多くのトークンが消費される場合）。このような事例において、単一の
バケット２０２のみが受付制御に使用されている場合、到着する作業要求は拒否されうる
（または延期後再試行されうる）。作業量の時間的不均一性に対処するために、図１ｂを
参照して説明されたように、追加バーストモードトークンバケットの使用等、異なる実施
形態において様々な技術が使用される。

図３は、少なくともいくつかの実施形態による、様々な種類の受付制御ポリシーを実施
するのに使用されうるバケット２０２等のトークンバケットの例示的構成プロパティ３０
２を示す図である。いくつかの実装例において、トークンバケットは、受付コントローラ
１８０のインメモリデータ構造として実装され、必要に応じ永続的ストレージに書込まれ
うる。このようなデータ構造は、現在のトークン集合数、集合数が最後に修正された時間
、及び／または図３に示される様々なパラメータ及びポリシーの値を表すフィールドを備
えうる。

トークン消費ポリシー３１０により、受付制御ためのトークン消費方法が示されうる。
いくつかの実施形態において、消費ポリシー３１０は、異なる受付前ポリシー及び受付後
ポリシーを含み、及び／または他のバケットの状態もしくは作業対象の作動モードに依存
しうる。例えば、一実施形態において、プロビジョン能力バケットＰＢ（例えば、通常モ
ードバケットセット１２０内）及びバーストモードバケットＢＢ（例えば、バーストモー
ドバケットセット１２５内）の、２つのバケットが所定の作業対象に対する受付制御に使
用されうる。当実施例において実施されている受付前ポリシーに従って、新規の要求を許
可するために、ＰＢの集合数がチェックされ、少なくとも１トークンが存在するか否かが
判定される。そして要求が許可された場合、受付後ポリシーに従って、ＰＢの集合数は１
つ削減されうる。ＰＢがトークンを有する場合、要求を許可する前にＢＢの集合数はチェ
ックされなくてもよい。しかしながら、要求が受付けられると、いくつかの実施形態にお
いて実施されている受付後ポリシーに従って、１トークンがＢＢからもなお消費されうる
。実施例を続けると、これとは対照的にＰＢがトークンを全く有していない場合、作業対
象はバーストモードにあるとみなされ、ＢＢの集合数がチェックされ、ＢＢが少なくとも
１トークンを有するか否かが判定されうる。バーストモードの間、ＢＢが利用可能なトー
クンを有する時のみ要求は許可され、要求が許可されると、ＢＢからトークンが消費され
うる。（いくつかの実装例においては、バーストモードの間に、要求受付の際にＰＢのト
ークン集合数も削減され、これによりＰＢの集合数がマイナスになる可能性がある。）い
くつかの実施形態において、所定のバケットから、当該バケットの消費ポリシーに基づい
て、異なる数のトークンが異なる種類の処理に対し消費されうる。いくつかの実施形態に
おいて、トークン消費ポリシーはまた、該当するデータオブジェクトがしばらく前から作
業要求の対象ではなくなった場合、バケットからトークンが削除されるべきか否か（及び
その消費率）を示す遊休中崩壊パラメータ、または、ある時間間隔においてトークンが使
用されなかった場合、１つのバケットから別のバケットへトークンを譲渡すべきか否かを
示す遊休時譲渡パラメータを指定しうる。一実施形態において、老朽ポリシーは、特定の
時間間隔に消費されなかったトークンを消費するために使用されうる。例えば、各トーク
ンは有効期間に対応付けられ、この期間を過ぎるとトークンは受付制御目的に使用できな
くなる。本明細書において、所定のカテゴリのバケットに適用可能なトークンポリシー（
及び後述されるような様々な他のポリシー）は、カテゴリに基づいた名称により特定され
うる。例えば、通常モードバケットに適用可能な消費ポリシーは通常モード消費ポリシー
と称され、そしてバーストモードバケットに適用可能な消費ポリシーはバーストモード消
費ポリシーと称されうる。

描写された実施形態において、プロパティ３０２は、開始時または初期化時にバケット
内に配置されるトークン数を示す初期トークン集合数パラメータ３０６を含みうる。トー
クン補充ポリシーパラメータ３１４は、例えばバケットに対応付けられた作業対象に設定
された作業率を維持するのを支持するために、バケットにトークンが追加される率、及び
／またはバケットにトークンが追加される状況を示しうる。いくつかの実施形態において
、バケットの１以上のパラメータは時間と共に変更されうる。例えば、デフォルトの補充
率がバケットに適用されるが、特定の条件下では非デフォルト率が使用されうる。最大集
合数パラメータ３１８はバケットの最大能力を示し、そして最小集合数パラメータ３２２
はバケットの集合数の下限を示しうる。いくつかの実装例において、一部の状況下でバケ
ットの集合数は、マイナスになるとみなされうる（例えば、最小集合数はゼロ未満になり
うる）。例えば、作業対象が読出し及び書込み等の入出力処理に対応する一実施形態にお
いて、受付コントローラ１８０は、簡潔化のため、受信クライアント要求はそれぞれおよ
そ１個の実入出力処理に至ると推測または推定しうる。しかしながら、処理要求Ｒを受付
けた後、いくつかの事例においてＲを許可した結果必要となる実作業量は、推測した１入
出力処理よりも実質的に大きくありうる。例えば、１読出し処理で遂行されると予測した
読出し要求は、最終的に１０００読出し処理を要するテーブル走査処理になりうる。この
ようなシナリオにおいて、予期せぬ追加作業の影響がその後の受付制御判断に確実に反映
されるように、追加作業に対応するある数のトークン（例えば、１０００−１＝９９９ト
ークン）がバケットから差し引かれ、当該バケットのトークン数は少なくとも一時的にマ
イナスになりうる。トークン数は、例えばバケットの補充率及び受信要求率に基づいて、
最終的にはプラスに戻りうる。トークン不足ポリシーパラメータ３２４は、トークン不足
（すなわちマイナス集合数）が許容される状況、不足状態が許容される時間の長さ、不足
から回復するために取られるべき処置等に関する規則を指定しうる。いくつかの実施形態
において、異なる種類の処理は異なる受付制御規則を有し、そしてバケットが使用される
処理の種類は、適用処理種類パラメータ３２６において指定されうる。少なくともいくつ
かの実施形態において、バケットのトークンの使用に関してクライアントに請求する金額
を決定するために使用されうる１以上の価格設定ポリシー３２８が、バケットプロパティ
内に示されうる。価格設定ポリシー３２８が含みうる例示的要素の種類は、図１７に示さ
れ、さらに詳しく後述される。異なる実施形態においては、図３に示される例示的パラメ
ータのサブセットのみが使用され、一方別の実施形態においては、図３に示されるパラメ
ータ以上の追加バケット構成パラメータが使用されうる。少なくともいくつかの実施形態
において、図３に示される様々なプロパティの値及び／または設定は、バーストモード作
動に対応するか否かといった他の受付制御設定と同様に、プログラムで設定または修正さ
れうる（例えばウェブサービスコールを使用して）。
未使用トークンの貯蓄

いくつかの実施形態において、適用補充率に従って、定期的に、または作業要求に対す
る受付制御判断の完了または開始等のトリガーイベントに応じて、所定のトークンバケッ
トにトークンが補充されうる（すなわちバケットにトークンが追加されうる）。このよう
な実施形態において、例えば前の時間間隔において作業要求が平均的にプロビジョン能力
より低い率で到着したため、通常モードトークンバケットが、補充される時点でいくつか
の未使用トークンを有する場合がありうる。一実施形態において、１以上のバケットから
の未使用トークンは、例えばバースト時に後ほど使用できるように、１以上の他のトーク
ンバケットに貯蓄または蓄積されうる。図４は、少なくともいくつかの実施形態による、
プロビジョン能力バケットからバーストバケットへ未使用トークンの蓄積の実施例を示す
図である。

図４に描写された実施形態において、通常モードバケットセット１２０は、最大トーク
ン集合数Ｍが設定されたプロビジョン能力バケット４２０を備え、一方バーストモードト
ークンバケットセット１２５は、Ｍ以上の最大トークン集合数Ｂが設定されたバーストモ
ードバケット４２２を備える。矢印４５２で示されるように、プロビジョン能力バケット
４２０は、最大集合数Ｍを条件に、プロビジョン能力ｐｒと等しい率で補充される。従っ
て、例えばｐｒが１００処理／秒、Ｍ＝１００、かつ毎秒一度補充処理が行われる場合、
毎秒最大１００トークンがバケット４２０に追加されうる。矢印４５４で示されるように
、受信した作業量要求に基づいた率で、バケット４２０からトークンが消費されうる。２
つの時点、Ｔ１及びＴ２（Ｔ２はＴ１の１秒後）を考察する。Ｔ１の時点でバケット４２
０は１００トークンを有し、そして次の秒の間にそのうちの７５トークンが、受信作業要
求１７０に関連する受付制御処理に消費されたと仮定する。当実施例シナリオにおいて、
Ｔ２の時点でバケット４２０はまだ２５未使用トークンを有する。

描写された実施形態において、矢印４６０で示されるように、このような未使用トーク
ンはバーストモードバケット４２２に蓄積されうる。実施例を続けると、従ってＴ２の時
点で２５トークンがバケット４２２に追加されうる。さらに、描写された実施形態におい
て、矢印４５６で示されるように、トークンは、プロビジョン率ｐｒの関数でもありうる
バケット４２２の補充率で（最大集合数限度Ｂを条件に）バケット４２２に追加されうる
。バーストモード処理の間、作業要求の到着率に基づいた率で、バケット４２２からトー
クンが消費されうる。図４の矢印４５８で示されるように、少なくともいくつかの実施形
態において、作動モードに関係なく、作業要求の到着率に基づいて、バケット４２２から
トークンが消費されうる。例えば、作業要求が実行対象として受付けられる度に、通常モ
ードバケット４２０からいくつかのトークンが消費され、そしてバーストモードバケット
４２２からいくつかのトークンが消費されうる。いくつかの実施形態において、到着率に
関係なく、かつ他の受付制御設定に関係なく、作業対象に使用されるコンピューティング
デバイスのハードウェア及び／またはソフトウェアの限度に基づく所定の最大対応可能率
より高い率では、作業要求を受付けられないことに留意されたい。このような最大限度は
、例えば、コンピューティングデバイスに対応能力を超えるストレスが加わっている場合
、コンピューティングデバイス上のデータが壊れないように守るために設定されうる。

図４に描写された実施形態において、バーストモードバケット４２２の集合数は、バケ
ット４２０においてますます多くのトークンが未使用になるにつれ、経時的に増加する（
最大集合数限度Ｂ、及び受付済作業要求に対するバーストモードトークンの消費を条件と
して）。これにより受付コントローラ１８０は、バケット４２２の補充率のみがバケット
４２２の集合数に貢献している時に対処可能なバーストよりも、大きいバーストに対処可
能になる。未使用トークンを後ほど使用するために貯蓄するこのような技術は、クライア
ントがプロビジョン能力だけでなくバーストモード処理に関しても請求される実施形態に
おいて、バケット間で未使用トークンを物理的に譲渡することでクライアントが全体の費
用を削減できるため、特に役立つ。いくつかの実施形態において、同様の種類の未使用ト
ークンの譲渡もまた、他の譲渡元及び譲渡先バケットペアにより対応されうる。例えば、
個別のトークンバケットが作業要求のそれぞれのカテゴリに対し保持され、そして特定カ
テゴリＣ１用のバケットから未使用トークンが別のカテゴリＣ２用のバケットへ譲渡され
うる。
特定の種類の処理用のトークンバケット

いくつかの実施形態において、所定の作業対象は、異なるカテゴリの処理の作業要求に
対応しうる。例えば、一実施形態において、データベーステーブルは読出し及び書込み処
理に対応する。「書込み処理」または「書込み」という用語は、データベーステーブル、
ファイル、または値等のオブジェクトのデータ及び／またはメタデータに、例えば作成（
新規または追加データの書込み）、更新（インプレース上書きまたは例えば一部のライト
ワンス環境においてデータの新バージョンの作成を伴う既存のデータへの変更）、削除、
名前の変更、及び／または移動を含む修正が行われる処理を指しうる。「読出し処理」ま
たは「読出し」という用語は、修正を伴わない処理を指しうる。書込み要求に応えるため
に必要となる総作業量は、読出し要求に応えるために必要となる作業量とは異なりうる。
例えば、いくつかの実施形態において、所定のデータベーステーブルまたはテーブルパー
ティションの多数のレプリカが保持されるため、書込み作業要求が完了したとみなされる
には、複数のレプリカにおいて書込みを完了する必要があり、これに対して読出し要求は
たった１つのレプリカにのみアクセスすることが求められうる。いくつかの実装例におい
て、書込み処理はログをとる必要があり、またはインデックス変更等の他の副作用を有し
うる。しかし読出し処理にこれらは必要ないだろう。その結果、所定作業対象における読
出し処理能力は、その書込み処理能力と異なりうる。従って、受付制御判断に関して、読
出しと書込みの扱いは異なりうる。図５は、少なくともいくつかの実施形態による、読出
し及び書込みの受付制御のためのそれぞれのトークンバケットの使用を示す図である。

描写された実施形態において示されるように、通常モードバケットセット１２０は、読
出しプロビジョン能力バケット５０２と、別の書込みプロビジョン能力バケット５０４と
を備える。バーストモードバケットセット１２５は、読出しバーストバケット５０６と、
書込みバーストバケット５０８とを備える。作業要求が到着すると、受付コントローラは
、作業要求が読出しであるか書込みであるか判定し、そして該当する種類のバケットのト
ークン集合を使用して、（ａ）当該作業要求を受付けると通常モード作動になるか、バー
ストモード作動になるか、そして（ｂ）当該作業要求を受付けるのに、適切なバケットに
おいて消費に十分なトークンが利用可能であるか否か、を判定しうる。描写された実施形
態において、読出しバケットにおけるトークンの消費及び／または補充は、書込みバケッ
トにおける消費及び／または補充から独立しており、そして図３に描写された一部または
全てのプロパティ及びポリシーは、各種類のバケットに対し独立して設定されうる。従っ
て、所定の時点において、作業対象は、読出しに関して通常モードで、書込みに関してバ
ーストモードである、またはその逆（すなわち、書込みに関して通常モードで、読出しに
関してバーストモード）である場合がありうる。作業対象はまた、読出し及び書込みの両
方に関して通常モードでありうる、または読出し及び書込みの両方に関してバーストモー
ドでありうる。いくつかの実施形態において、未使用のトークンは、読出しバケットから
書込みバケットへ、またはその反対に譲渡されうる。例えば、図５に描写された実施形態
において、時間間隔の終わりに書込みバーストバケット５０８にいくつかのトークンが未
使用のまま残っている時、該当する数のトークンは、読出しバーストバケット５０６の集
合数が閾値を下回る場合に、読出しバーストバケット５０６へ追加されうる。
共有リソース及び複製管理

いくつかの実施形態において、各作業対象に対し、図４及び５に示される種類のバース
トモードトークンバケットのそれぞれのセットが確立されうる。少なくともいくつかの実
施形態において、データベーステーブルまたはテーブルパーティション等の所定の作業対
象は、他の作業対象により共有される少なくともいくつかのリソースを使用しうる。例え
ば、テーブルＴａｂｌｅ１の一部は、テーブルＴａｂｌｅ２の一部と同じストレージデバ
イス上に配置されうる。受付制御判断を下す際、作業対象を実行するネットワークアクセ
ス可能なサービスは、共有リソースの能力も考慮に入れる必要がありうる。例えば、一実
装例において、所定のストレージデバイスは毎秒Ｎ読出し処理以下に対処可能であり、そ
して当該ストレージデバイスが２つの異なる作業対象ＷＴ１とＷＴ２に使用される場合、
１つの対象（ＷＴ１）の利用可能読出し処理能力は、もう片方の対象（ＷＴ２）の読出し
作業量に影響されうる。いくつかの実施形態において、多数の作業対象により共有される
リソースの利用可能処理能力が、自身のトークン集合数により表される共有リソースバケ
ットは、各作業対象におけるバーストモード受付制御判断に使用されうる。後述されるよ
うに、作業対象の多数のレプリカが保持される実施形態において、特定の種類の作業要求
（書込み処理につながる要求等）に対し、複製管理に対応付けられた１以上のバケットも
使用されうる。いくつかの実施形態において、複製管理バケットは、いくつかの種類の作
業要求の受付制御にのみ使用されうる。例えば、このような実施形態において、これらの
複製管理バケットは書込みに使用され、読出しには使用されない。図６は、少なくともい
くつかの実施形態による、１以上のローカルバースト限度バケット６０４と、１以上の共
有リソース能力バケット６０６と、１以上の複製管理バケット６０８とを含むバーストモ
ードトークンバケットセットを示す図である。

図６に示される三種類のバーストモードトークンバケットは、受付制御のために集合的
に使用され、例えば、各種類のバケットは利用可能なトークンがあるか順番に確認され、
そして全ての関連バケットがそれぞれのトークン消費ポリシーに従って十分なトークンを
含んでいる場合にのみ、作業要求１７０は受付けられる。異なる実施形態において、異な
るバケットが受付制御のために確認される順番は異なる。ローカルバースト限度バケット
６０４は、例えば共有リソースの処理能力限度を考慮せず、かつ複製を考慮せず、孤立し
ているとみなされる作業対象の利用可能処理能力を表すトークンを含みうる。一実施形態
において、作業要求が受信されると、ローカルバースト限度バケット６０４（複数可）が
まず確認されうる。ローカルバースト限度バケットが十分なトークンを含む場合、共有リ
ソース能力バケット６０６が次に確認されうる。共有リソース能力バケットに十分なトー
クンが確認され、かつ作業要求に応じることでデータ複製が要求される場合、複製管理バ
ケット６０８が次に確認されうる。描写された実施形態において、全ての確認済みバケッ
トが十分なトークンを含む場合、作業要求が受付けられうる。確認済みバケットのいずれ
か１つでも十分なトークンを含まない場合、作業要求は拒否、延期、または再試行されう
る。

ローカルバースト限度バケット６０４が十分なトークンを含まず、示される他の種類の
バケットより前に確認されるシナリオにおいて、共有リソース能力バケット６０６及び／
または複製管理バケット６０８がそれぞれの消費ポリシーに基づいて要求を受付けるのに
十分なトークンを含んでいても、作業要求は拒否されうる。いくつかの実施形態において
、各ローカルバースト限度バケット６０４は読出し要求及び書込み要求のために保持され
、及び／または各共有リソースバケット６０６は読出し要求及び書込み要求のために保持
されうる。

いくつかの実施形態において、受付制御中に、例えば共有リソースバケットのそれぞれ
のインスタンスを使用して、いくつかの異なる種類の共有リソースが考慮されうる。例え
ば、一実施形態において、読出し処理を行うのに必要なメモリバッファの限定数は、作業
対象が実装されたサーバにおいて入手可能であり、そして利用可能メモリバッファを表す
共有リソース能力バケット６０６が確立されうる。同様に、別の実施形態において、デー
タ構造の種類（作業対象に使用されている所定のオペレーティングシステムのインスタン
スにおいてその限定数が入手可能なファイル記述子等）が各作業処理に使用され、そして
利用可能ファイル記述子を表す別の共有リソース能力バケット６０６が確立されうる。さ
らに詳しく後述されるように、いくつかの実施形態において、１以上の共有リソースの余
剰処理能力（リソースを共有する作業対象のプロビジョン能力の合計に相対する）を表す
トークンが、反復手法を使った公平な方法で作業対象間に分配されうる。

一実施形態によれば、作業対象（データベーステーブル、ファイル、またはストレージ
ボリューム等）のコンテンツが、サービスによって１以上の論理パーティションに分配さ
れうる。例えば、データベースサービスのクライアントにより、テーブルはおよそＸテラ
バイト（ＴＢ）のデータを保有可能であり、かつ毎秒Ｙ読出しまたは書込み処理の作業量
に対応可能であることが指定されうる。そしてデータベースサービスにより、Ｐ個の論理
パーティションを有するテーブルを設定することが決定され、各論理パーティションがＸ
／Ｐテラバイト（ＴＢ）のデータを記憶し、かつＹ／Ｐ処理というプロビジョン能力限度
に対応するのに十分なリソースが、各論理パーティションに最初に割当てられる。（いく
つかの実施形態において、例えば、一部のパーティションが他のパーティションに比べて
「より負荷の高い」、すなわちより高い平均要求率を有することが検知、または予測され
た場合に、パーティション間でプロビジョン処理能力の不均一な分配が行われうる。）少
なくともいくつかのこのような実施形態において、受付制御判断が論理パーティションレ
ベルで行われうる。各論理パーティションに対応して、データオブジェクトに対するデー
タ耐久性ポリシーまたはデータ複製ポリシーに従って、パーティションのデータのマスタ
レプリカと１以上のスレーブレプリカが設定されうる。機器故障、電力損失、及び／また
は自然災害等の要因によるデータ損失の確率を閾値未満に保つために、耐久性／複製ポリ
シーは、データ書込みが十分な数の別の物理的位置に確実に複製されるように設計されう
る。いくつかの実施形態において、書込み要求に対する受付制御判断はマスタレプリカに
おいて行われ、一方読出し要求に対する受付制御判断はマスタレプリカ、またはスレーブ
レプリカ（特にクライアントが少し古い可能性のあるバージョンのデータからの読出しで
も受入れる場合）のいずれかで行われうる。いくつかの実施形態において、クライアント
からの書込み要求が受付けられると、複製ポリシーに従って、例えば、書込みが成功した
という肯定応答がクライアントに提供される前に、Ｎ個のレプリカ（マスタレプリカとＮ
−１個のスレーブレプリカ）において修正データの複製が無事に完了される必要があるだ
ろう。よって、書込み要求の正常完了にはスレーブリソースの使用が必要になるため、書
込みに関する受付制御判断中に、スレーブ（複数可）における利用可能処理能力が（マス
タと同様に）考慮される必要があるだろう。一実施形態において、設定されたスレーブレ
プリカの数は、複製ポリシーで求められる最小数を超えうる。複製ポリシーは、書込みが
成功したとみなされる前に、書込みの定足数Ｑ個の永続的コピーが作成されることを要求
しうるため、最小（Ｑ−１）個のスレーブレプリカが必要となる可能性がありうる。しか
しながら、このような実施形態において、読出し負荷の均衡、高い可用性等の様々な理由
から、保持されるスレーブレプリカの数はＱ−１を超えうる。様々な実施形態において、
特定のレプリカのスレーブまたはマスタ指定は、時間と共に変化しうることに留意された
い。例えば、所定の論理パーティションのマスタがインスタンス化されたデバイスが故障
、または到達不可能になった場合、前にスレーブとして指定された別のレプリカがマスタ
として選択されうる。いくつかの実施形態において、スレーブレプリカの数は、例えば、
データオブジェクトを所有するクライアントからの要求に応じて、当該データオブジェク
トの存続期間中に変更されうる。レプリカが必ずしもマスタまたはスレーブとして指定さ
れないいくつかの実施形態において、ピアツーピア環境においても、トークンベースの受
付制御に関する技術が適用されうる。このような実施形態において、受信書込み要求に対
する受付制御判断が行われたレプリカは、本明細書に説明されるように（行われる処理の
種類に関して）マスタレプリカに該当しうる。従って、レプリカが概してお互いに同等な
責任を有するピアツーピア複製を使用するいくつかの実施形態において、所定のピアＰ１
に書込み要求が受信された場合、少なくとももう１つのピアＰ２の利用可能処理能力に関
する情報を使用して、書込み要求を実行対象として受付けるか否かが判断されうる。

前述のように、書込みが複製される少なくともいくつかの実施形態において、書込みの
受付制御中に、複数のレプリカ（例えばマスタと少なくとも１つのスレーブ）における利
用可能処理能力が考慮される必要があり、これに応じて１以上の複製管理バケット３０８
が使用されうる。例えば、ローカルバースト限度バケット６０４は孤立しているとみなさ
れるマスタレプリカにおける利用可能処理能力を表しうるが、複製管理バケット３０８は
マスタから見た１以上のスレーブレプリカにおける利用可能処理能力を表しうる。

少なくともいくつかの実施形態において、複製管理バケット６０８（複数可）における
スレーブ（複数可）の状態の情報をリフレッシュするために、スレーブ能力更新プロトコ
ルが使用されうる（例えばマスタにおける複製管理バケット６０８（複数可）のトークン
集合数が、スレーブから受信した情報に基づいて更新されうる）。いくつかの実施形態に
おいて、マスタでバケットが使用される方法と同様の方法で（ただし同一ではない）、ス
レーブにおいてもトークンバケットが処理能力管理のために使用されうる。このような一
実施形態において、スレーブ能力更新プロトコルに従って、スレーブはマスタに対し、１
以上のスレーブローカルトークンバケット（プロビジョン能力バケット及び／またはバー
ストモードバケットを含みうる）の集合数スナップショット（すなわち時点表示）を提供
しうる。例えば、マスタにおける共有リソース能力バケット６０６と同様に、１つの特定
スレーブ側トークンバケットは、少なくとも一部のスレーブデータが記憶される共有スト
レージデバイスにおける利用可能能力を表し、そしてこのようなバケットの集合数のスナ
ップショットがマスタに提供されうる。異なる実施形態において、スレーブからスナップ
ショットを提供するために、様々な手法のいずれかが使用されうる。例えば、マスタによ
り書込み複製が要求された場合、スナップショットはスレーブからマスタへ送る書込み肯
定応答に添付またはピギーバックされうる、またはスレーブはスナップショットを、マス
タに当該スレーブが稼働していることを知らせるためにマスタへ送られる必要のあるハー
トビートメッセージに添付しうる。
複合トークンバケット

前述のように、異なる種類の作業要求到着バーストがネットワークアクセス可能なサー
ビスに与える影響は異なりうる。サービスは非常に高いバースト率を短い時間対処可能で
あるが、より低いバースト率には長い時間耐えうる。いくつかの実施形態において、受付
コントローラ１８０は、異なる種類のバーストがサービスに与える影響に基づいて、異な
る種類のバーストの継続時間を限定するように構成され、そして受付制御を支援するため
にバースト時作業要求到着様態は複数のカテゴリに分類されうる。図７は、少なくともい
くつかの実施形態による、受付制御のための作業要求バーストのカテゴリ分類の実施例を
示す図である。

図７において（図１ａと同様に）、Ｘ軸は時間を表し、Ｙ軸は所定の作業対象１０２に
おける作業要求到着率１１０を表す。例えば、毎秒（または毎Ｎ秒）受信される作業要求
の数を監視し、１秒あたりの要求数を計算し、そして時間間隔毎の１秒あたりの要求数を
表す点をつなぐことで、図７のようなグラフがプロットされうる。作業対象のプロビジョ
ン能力１１２は、Ｙ軸にｐｒにおいて交差する水平線により表される。作業対象は、到着
率がｐｒ以下である限り通常モードで作動し、そして到着率がｐｒを上回る度にバースト
モードで作動すると想定される。作業対象は、Ｔ０からＴ７までの時間に、Ｔ０とＴ１の
間の時間帯、Ｔ２とＴ３の間の時間帯、Ｔ４とＴ５の間の時間帯、及びＴ６とＴ７の間の
時間帯等、いくつかの時間帯で通常モードにある。しかしながら、３つの時間帯（Ｔ１か
らＴ２、Ｔ３からＴ４、及びＴ５からＴ６）において、作業対象はバーストモードにある
。グラフで表されるバーストＢ狭幅１（Ｔ１−Ｔ２間隔）とＢ狭幅２（Ｔ５−Ｔ６間隔）
の形は同様であり、どちらの形もバーストＢ広幅１の形とは異なる。バーストピーク率７
０２Ａ（Ｂ狭幅１の間の最大作業要求到着率）及びバーストピーク率７０２Ｃ（Ｂ狭幅２
の間の最大作業要求到着率）は、バーストピーク率７０２Ｂ（Ｂ広幅１の間の最大作業要
求到着率）より大幅に高い。

描写された実施形態において、受付コントローラ１８０は、２つの基礎トークンバケッ
トを含む複合バーストモードトークンバケットを維持するように構成されうる。後述され
るように、基礎トークンバケットの１つは、プロビジョン能力ｐｒと比べて非常に高い到
着率の短期バースト（Ｂ狭幅１またはＢ狭幅２等）を許可するために、かつこのような高
い到着率が非常に長く続くことを防止するためにも使用されうる。複合トークンバケット
のもう１つの基礎トークンバケットは、Ｂ広幅１等のより低いピーク率でより長いバース
トを許可するために使用されうる。適用可能なパラメータ及び／またはポリシー（例えば
、補充率）は、基礎バケットにより異なる。少なくともいくつかの実施形態において、バ
ーストモードの間に作業要求を実行対象として受付けるために、両方の基礎バケットから
トークンが消費されうる。

図８は、少なくともいくつかの実施形態による、バーストモード受付制御のためのピー
クバーストバケット（ＰＢＢ）８０２と持続バーストバケット（ＳＢＢ）８０４とを含む
複合トークンバケット８０１の使用の実施例を示す図である。描写された実施形態におい
て示されるように、複合トークンバケット８０１は、作業対象１０２のためのバーストモ
ードトークンバケッセット１２５の一部を成す。各バケット８０２と８０４は各自のバー
スト率（バケットがモデルとする最大到着率を表す）及び各自のバースト時間窓（モデル
にされたバーストの継続時間を示す）により特徴づけられる。ピークバースト率（ｐｂｒ
）パラメータは、ＰＢＢを使って対応する最大到着率を表し、ピークバースト時間窓サイ
ズ（ｐｂｗ）パラメータは、作業対象がこのような到着率に対応可能であるべき継続時間
を示す（補充処理なし等の特定条件を仮定する）。持続バースト率（ｓｂｒ）パラメータ
は、理想的には長い持続バースト時間窓（ｓｂｗ）の間対応するべきバースト到着率（ｐ
ｂｒより低い）を表す。様々な実施形態において、それぞれの時間窓は一般に、それぞれ
のバケットがバーストに対応する継続時間の相対的長さを示しうる一方、実際にそれぞれ
の率のバーストに対応する実継続時間は、時間窓に必ずしも一致し得ないことに留意され
たい。よって、少なくともいくつかの実施形態において、時間窓は、対象とするバースト
の継続時間を示すと言われうるが、必ずしも実バースト継続時間に等しいわけではない。
ＰＢＢ８０２とＳＢＢ８０４の最大トークン集合数は、バースト率と時間窓の積を計算す
ることで事例ごとに取得される。例えば、ＰＢＢの最大集合数は（ｐｂｒ^*ｐｂｗ）であ
り、そしてＳＢＢの最大集合数は（ｓｂｒ*ｓｂｗ）である。矢印８５６、８５８により
示されるように、複合バケット８０１の各バケットから実際にトークンが消費される率は
、作業要求の到着率（少なくともバーストモードの間に、そしていくつかの実施形態にお
いては作業対象がバーストモードと通常モードのどちらにあるのか関係なく）に依存しう
る。少なくともいくつかの実施形態において、要求が受付けられると、ＰＢＢ８０２及び
ＳＢＢ８０４の両方からトークンが消費される。すなわちＰＢＢ及びＳＢＢからトークン
が消費される率は同一である。

非常に高い到着率のバーストの長過ぎる持続を確実に許可しないために、所定の作業要
求を実行対象として受付ける際、描写された実施形態の各バケットからトークンが消費さ
れうる。前に提供した実施例を繰り返すと、プロビジョン能力（ｐｒ）が毎秒１００処理
（１００処理／秒）であり、ピークバースト率（ｐｂｒ）が１０００処理／秒であり、ピ
ークバースト時間窓サイズ（ｐｂｗ）が６秒であり、持続バースト率（ｓｂｒ）が２００
処理／秒であり、そして持続バースト時間窓サイズ（ｓｂｗ）が６０秒であるシナリオを
考察する。従って、ＰＢＢの最大集合数は１０００^*６、すなわち６０００トークンであ
り、またＳＢＢの最大集合数は、２００^*６０の積、すなわち１２０００トークンに設定
される。例示的シナリオにおいて、所定の要求を受付けるために、ＰＢＢとＳＢＢに対し
それぞれ１トークンが要求される。ＰＢＢ及びＳＢＢの両方が満杯である（ＰＢＢは６０
００トークンを有し、ＳＢＢは１２０００トークンを有する）時間Ｔに始まる作業要求Ｂ
のバーストを考察する。そしてＰＢＢは毎秒２００トークン補充され、一方ＳＢＢは毎秒
１００トークン補充されると仮定する。バーストＢが１０００要求／秒の要求到着で構成
されている場合、ＰＢＢの集合数が毎秒約８００トークン（１０００消費し、２００補充
される）の率で減少し、一方ＳＢＢの集合数が毎秒約９００トークン（１０００消費し、
１００補充される）減少するため、Ｂの要求は７から８秒の間受付けられうる。この時間
を過ぎると、複合バケットは１０００要求／秒に対応不可能になる。しかしながら、バー
ストＢが毎秒２００要求の要求到着で構成されている場合、ＰＢＢは毎秒正味トークンの
損失はなく（２００消費し、２００補充される）、一方ＳＢＢは毎秒１００トークン（２
００消費し、１００補充される）損失しうる。このように当例示的シナリオにおいて、よ
り低いバースト率（２００要求／秒）は、急激なバースト（７から８秒間の１０００要求
／秒のバースト）より、長い時間（１２０秒）対応しうる。

前述のように、様々な実施形態において、複合トークンバケット８０１の当例示的使用
に関する算術は、到着率の変動、作業対象の通常モードへの復帰、及び／または異なる種
類の要求に対し異なる数のトークンを必要とする消費ポリシー等の様々な要因により、実
際さらに複雑でありうる。

描写された実施形態において、例えばＰＢＢの補充率は、プロビジョン能力ｐｒの関数
（ｆ１（ｐｒ））であり、そして作業対象のプロビジョン能力バケットにおける未使用ト
ークンの数「ｕ」の関数（ｆ２（ｕ））である。同様に、ＳＢＢの補充率は、プロビジョ
ン能力の関数（ｆ３（ｐｒ））及びｕの関数（ｆ４（ｕ））である。一実装例において、
ＰＢＢ、ＳＢＢ、またはこれら両方のいずれかの補充率は、プロビジョン能力バケットに
おける未使用トークンの絶対数に基づく代わりに、未使用トークンがプロビジョン能力バ
ケットに蓄積する率に基づきうる。いくつかの実施形態において、前の実施例のように、
ＰＢＢの最大集合数はＳＢＢの最大集合数よりも小さく設定されうる一方、ＰＢＢの補充
率はＳＢＢの補充率よりも高く設定されうる。異なる実施形態が、様々な種類の関数ｆ１
、ｆ２、ｆ３、ｆ４の所望する任意の組合せを使用しうる。

様々な実施形態において、パラメータ（ｐｂｒ、ｐｂｗ、ｓｂｒ、及びｓｂｗ等）並び
に関数（ｆ１、ｆ２、ｆ３、及びｆ４）の定義は調整可能または設定可能である。例えば
受付コントローラ１８０は、パラメータの値及び関数の定義を、設定ファイルから、また
はネットワークアクセス可能なサービスの管理者からの入力により、特定するように構成
されうる。受付コントローラは、パラメータ値及び関数を特定し、最大集合数を計算また
は設定し、パラメータ通りにバケット８０２、８０４にトークンを追加し、そして受信作
業要求を待ち受けうる。バーストモードの間に作業要求が受付けられると、ＰＢＢ及びＳ
ＢＢのいずれか、またはこれら両方のトークン集合数に少なくとも一部基づいて、作業要
求は実行対象として受付けられうる（または拒否されうる）。作業要求が受付けられた場
合、ＰＢＢ及びＳＢＢの２つのバケットのそれぞれの消費ポリシーに基づいて、１以上の
トークンがＰＢＢ、ＳＢＢ、またはこれら両方のいずれかから消費されうる。図１２に関
してさらに詳しく後述されるように、ＰＢＢ及びＳＢＢは、様々な時点においてそれぞれ
の補充率に基づいて補充されうる。少なくともいくつかの実施形態において、関数ｆ１、
ｆ２、ｆ３、及びｆ４のうちのいくつかは、同一の関数でありうる。例えばｆ１（ｐｒ）
＝ｐｒの場合に同一の関数でありうる。一実施形態において、関数ｆ１、ｆ２、ｆ３、及
びｆ４のうちのいくつかは、別の一部の関数と同一でありうる。例えば、この４つの関数
は異なるという要件はないだろう。いくつかの実施形態において、プロビジョン能力バケ
ットの未使用トークンの数「ｕ」は補充率に寄与し得ない。例えば、補充率は未使用トー
クンの蓄積とは無関係である場合もありうる。少なくともいくつかの実施形態において、
ＰＢＢ及び／またはＳＢＢは、通常モードで作動中に、これらの補充ポリシーに従って（
及びこれらの最大トークン集合数限度を条件に）補充され、作業要求到着率がバーストモ
ードの閾値より低い間でも、ＰＢＢ及び／またはＳＢＢにトークンが蓄積される。このよ
うな通常モードの間のバーストモードバケットの補充は、例えばシステムが今後のバース
トに対処できるように準備をするのに役立ちうる。

いくつかの実施形態において、作業対象を実行するサービスは、異なる作業要求カテゴ
リに対するそれぞれのパラメータセットを使用して、ピーク及び持続バーストモードの受
付制御を行うことを所望しうる。例えば、読出しには、書込みとは異なるピークバースト
率（または持続バースト継続時間）の使用が適切でありうる、または優先度ベースのそれ
ぞれの作業要求カテゴリには、異なるピークバースト率（または持続バースト継続時間）
の使用が適切でありうる。例えば、極めて時間依存性の高いある作業要求カテゴリに対し
、他の時間依存性の低い作業要求カテゴリと比べて、より高いピークバーストに対応でき
ることがサービスで所望されうる。いくつかの実施形態において、受付コントローラ１８
０は、複数の複合バケットを実行して、このような使用事例に対処しうる。図９は、少な
くともいくつかの実施形態による、作業処理のそれぞれのカテゴリ専用のピークバースト
及び持続バーストバケットの使用を示す図である。

描写された実施形態において示されるように、バーストモードバケットセット１２５に
は、そのローカルバースト限度バケット６０４集合の中に、それぞれ１以上の作業要求カ
テゴリ専用の複合バケット８０１Ａ、８０１Ｂ、及び８０１Ｃを含む複数の複合バケット
８０１が含まれうる。例えば、複合バケット８０１Ａは、カテゴリＣ１の要求に対する受
付制御のために使用され、複合バケット８０１Ｂは、カテゴリＣ２の要求に対する受付制
御のために使用され、そして複合バケット８０１Ｃは、カテゴリＣ３及びカテゴリＣ４の
要求に対する受付制御のために使用されうる。異なる実施形態において、カテゴリの定義
はサービスに依存しうる。例えば、１つのサービスでは、行われる処理の種類に基づいて
カテゴリが定義され（例えば読出し及び書込みは別のカテゴリになりうる）、別のサービ
スでは、リソースの平均消費量に基づいてカテゴリが定義され（例えば、短い処理対長い
処理）、別のサービスでは、クライアントが指定した優先度またはサービスが割当てた優
先度に基づいてカテゴリが定義されうる。

各複合バケット８０１は、ｐｂｒ、ｐｂｗ、ｓｂｒ、及びｓｂｗのパラメータ設定のそ
れぞれの（異なりうる）セットを有する、少なくとも１つのＰＢＢ８０２と少なくとも１
つのＳＢＢ８０４とを含みうる。例えば、複合バケット８０１ＡはＰＢＢ８０２ＡとＳＢ
Ｂ８０４Ａとを含み、複合バケット８０１ＢはＰＢＢ８０２ＢとＳＢＢ８０４Ｂとを含み
、一方複合バケット８０４ＣはＰＢＢ８０２Ｃ、８０２Ｄと単一のＳＢＢ８０４Ｃとを含
む。複合バケット８０１Ｃの場合、カテゴリＣ３の作業要求のバーストモード受付制御は
、ＰＢＢ８０２Ｃ及びＳＢＢ８０４Ｃを使用して管理され、一方カテゴリＣ４の作業要求
のバーストモード受付制御は、ＰＢＢ８０２Ｄ及び共有ＳＢＢ８０４Ｃを使用して対処さ
れる。従って、当例示的シナリオにおいて、カテゴリＣ３のバーストモード作業要求が受
信されると、ＰＢＢ８０２Ｃ及びＳＢＢ８０４Ｃの集合数が確認され、そしてカテゴリＣ
４のバーストモード作業要求が受信されると、ＰＢＢ８０２Ｄ及びＳＢＢ８０４Ｃの集合
数が確認される。異なる作業要求カテゴリ（または作業要求カテゴリの組合せ）に対する
個別の複合バケットを実行することで、サービスは、単一の複合バケットが使用された場
合に実行可能なバーストモード様態の制御と比べて、より細やかな粒度でバーストモード
様態を制御可能である。図９のバーストモードバケットセット１２５はまた、１以上の共
有リソース能力バケット６０６（例えば、バーストモード受付制御中に共有リソースの能
力限度を確実に考慮する）と、１以上の複製管理バケット６０８（例えば、複製する必要
のある書込み等の処理に対する受付制御判断を、複数のレプリカにおける利用可能処理能
力に少なくとも一部基づいて確実に行う）とを含みうる。
バーストモード受付制御の方法

図１０は、少なくともいくつかの実施形態による、ネットワークアクセス可能なサービ
スにおいて作業要求に対しトークンベースの受付制御機構を実行するために行われうる処
理態様を示すフロー図である。構成要素１００１で示されるように、例えばクライアント
からのプロビジョニング要求に応じて、作業対象に適用される通常モード処理能力限度が
決定される。例えば、データベースサービスのクライアントが、毎秒Ｎ読出しまたは書込
み処理に対応可能なテーブルが作成されるよう要求すると、これに応じて当該テーブルの
通常モード処理能力限度はＮに設定されうる。サービスの受付コントローラ１８０は、例
えばデフォルト設定に基づいて、またはクライアントに要求されたもしくはクライアント
と取り決めた要件に基づいて、通常モードバケットセット及びバーストモードバケットセ
ットに使用される様々な他のパラメータ（バケットの数、初期トークン集合数、補充率等
）を決定しうる。そして通常モードバケットセット１２０及びバーストモードバケットセ
ット１２５のバケットは、例えばインスタンスが生成され、そしてトークンが追加される
等、初期化されうる（構成要素１００６）。

受付コントローラにおいて次の作業要求が受信される（構成要素１０１０）。少なくと
も１つの通常モードバケットのトークン集合数が確認されうる。通常モードトークン集合
数が閾値基準Ｔ１を満たす場合（構成要素１０１４にて検出）、１以上のトークンが通常
モードトークンバケット（複数可）から消費され（すなわち、トークン集合数は変更され
うる）、そして作業要求が実行対象として受付けられうる（構成要素１０１６）。単純な
一実装例において、例えば、通常モードトークンバケットは、閾値基準Ｔを満たすために
少なくとも１トークンを有する必要があり、そして受付済作業要求毎に１トークンが消費
されうる。いくつかの実施形態において、通常モード作動中に作業要求が受付けられると
、１以上のバーストモードバケットから（１以上の通常モードバケットからと同様に）ト
ークンが消費されうる。一般に消費されるトークンの数は、バケット（複数可）で実施さ
れているトークン消費ポリシーを含む様々な実施形態の要因の組合せに、及び／または作
業要求に応じるために必要となりうる作業量の見積りに依存しうる。少なくともいくつか
の実施形態において、受付コントローラ１８０は、例えばクライアントにより作業要求内
で指定された詳細、過去に実際要求された同様の要求の作業量の蓄積された経歴または統
計等に基づいて、このような見積もりを作成するように構成されうる。いくつかの実施形
態において、実施されている補充ポリシーによって、様々なトークンバケット（例えば、
通常モードバケット、バーストモードバケット、またはこれら両方のいずれか）は、受付
制御判断が行われた時点で任意で補充されうる（すなわちこれらのバケットの補充ポリシ
ー及び最大集合数限度に従って、これらのバケットにトークンが追加される）。図１２に
関して後述されるように、異なる実施形態において、トークンバケット補充につながる特
定の時間またはイベントは異なる。通常モードトークン集合数が閾値基準Ｔ１を満たさな
い場合（同様に構成要素１０１４にて検出）、受付コントローラ１８０は、作業要求を受
付けた場合に作業対象はバーストモード作動となり、これに応じて１以上のバーストモー
ドトークンバケットのトークン集合数が特定されなくてはならないと結論付けうる。

描写された実施形態において、受付コントローラ１８０は、少なくとも１つのバースト
モードトークンバケットのトークン集合数を特定しうる。バーストモードトークン集合数
が閾値基準Ｔ２を満たす場合（構成要素１０１８にて判定）、１以上のトークンがバース
トモードバケット（複数可）から消費され、そして作業要求がバーストモードにおける実
行対象として受付けられうる（構成要素１０２０）。単純な一実装例において、例えば、
バーストモードトークンバケットは、閾値基準Ｔ２を満たすために少なくとも１トークン
を有する必要がありうる。従って、少なくともいくつかの実装例において、通常モード及
びバーストモード両方のバケットに対するトークン集合数閾値が同じ場合もありうる。一
般にバーストモードトークンバケットから消費されるトークンの数もまた、バーストモー
ドバケット（複数可）で実施されているトークン消費ポリシーを含む様々な実施形態の要
因の組合せに、及び／または作業要求に応じるために必要となりうる作業量の見積りに依
存しうる。バーストモード受付判断が行われると、作業要求の通常モード受付に応じた処
理の場合のように、１以上のバケットが、これらバケットの補充ポリシーに基づき、そし
てこれらバケットの最大トークン集合数限度を条件に、任意で補充されうる。

通常モード（構成要素１０１６）またはバーストモード（構成要素１０２０）のいずれ
かで作業要求が受付けられると、作業要求に対応する１以上の処理が開始されうる（構成
要素１０２２）。いくつかの実施形態において、処理が完了すると、受付コントローラ１
８０は、実際に行われた作業量と、消費するトークン数を決定するのに使用された作業見
積りを、非同期的に比較しうる（構成要素１０２４）。元の作業見積りが間違っていた場
合、これに応じて、該当する作業要求の受付制御に使用された１以上のバケットにおける
トークン数が調整されうる。見積りが実際に行われた作業よりも小さい場合、受付制御に
使用されたバケットから追加でいくつかのトークンが取除かれうる。いくつかの実施形態
において、このように追加で消費されるトークンの数は、作業見積りと実作業の違いに基
づいて計算されうる。見積りが大きすぎた場合、いくつかのトークンが受付制御に使用さ
れたバケットから取除かれうる。

描写された実施形態において、通常モードトークンバケットセットの集合数が基準Ｔ１
を満たさず、かつバーストモードバケットセットのトークン集合数が基準Ｔ２を満たさな
い場合、作業要求は拒否、延期、または再試行されうる（構成要素１０８０）。いくつか
の実施形態において、作業要求を受付けない判断が下された場合、実施されている補充ポ
リシーによって、通常モードバケット（複数可）、バーストモードバケット（複数可）、
またはこれら両方のいずれかに対し、１以上のトークンが任意で追加されうる。受付制御
判断が行われた後（例えば、作業要求は受付けられたか、拒否されたかのいずれか）、受
付コントローラは次の作業要求を待ち受け、そして構成要素１０１０以降に該当する処理
が繰り返されうる。

図１１は、少なくともいくつかの実施形態による、ネットワークアクセス可能なサービ
スにおいて、複合バケットを含む複数のバーストモードトークンバケットを使用してバー
ストモード処理に対処するトークンベースの受付制御機構を実行するために行われうる処
理態様を示すフロー図である。構成要素１１０１に示されるように、受付コントローラ１
８０は、所定の作業対象における高い到着率の短期バースト及び低い到着率の長期バース
トのバーストモード受付制御に使用するいくつかのパラメータを決定しうる。決定された
パラメータには、例えば、対応するピークバースト率（ｐｂｒ）、ピークバースト率に対
応する継続時間を示すピークバースト時間窓サイズ（ｐｂｗ）、持続バースト率（ｓｂｒ
）（一般にｐｂｒより低いが、必須ではない）、及び持続バースト時間窓サイズ（ｓｂｗ
）（一般にｐｂｗより小さいが、必須ではない）が含まれうる。少なくともいくつかの実
施形態において、例えば共有リソース能力バケット及び／または複製管理バケットを含む
他のバケットが設定されるべきか、様々なバケットの初期集合数設定等の他のパラメータ
もまた決定されうる。少なくともいくつかのパラメータは、例えば管理者による入力また
はサービスのオートチューニングに応じて設定可能であり、そしていくつかの実装例にお
いて１以上のパラメータが設定ファイルを介して読み出されうる。

構成要素１１０６に示されるように、少なくとも１つのピークバーストバケット（ＰＢ
Ｂ）と１つの持続バーストバケット（ＳＢＢ）とを含む複合バケットは、例えばバケット
のそれぞれの初期集合数３０６等のパラメータ設定に基づいてバケットのインスタンスを
生成し、トークンを追加することで、初期化されうる。描写された実施形態において、Ｐ
ＢＢの最大トークン集合数はｐｂｒとｐｂｗの積に設定され、ＳＢＢの最大トークン集合
数はｓｂｒとｓｂｗの積に設定されうる。ＰＢＢ及び／またはＳＢＢの補充率は、作業対
象のプロビジョン処理能力に少なくとも一部基づいて設定されうる。いくつかの実施形態
において、ＰＢＢ及び／またはＳＢＢの補充率は、プロビジョン能力バケットまたは別の
通常モードバケットにおいて未使用トークンが蓄積する率、及び／またはこのようなバケ
ットにおける未使用トークンの数にも基づきうる。

バーストモードの間に受付コントローラにて次のバーストモード作業要求が受信されう
る（構成要素１１１０）（すなわち、作業要求が受信され、そして受付コントローラは、
プロビジョン能力バケット等の通常モードバケットのトークン集合数を使用して、または
作業対象の作動モードを示すある別のインジケータを使用して、作業対象がバーストモー
ド状態にあると判定しうる）。受付コントローラはＰＢＢ及び／またはＳＢＢのトークン
集合数を特定し、消費ポリシー及び／または作業要求に対応付けられる見積作業量に基づ
いて、作業要求を受付けるのに十分なトークンが利用可能か否かを確認しうる。描写され
た実施形態において、ＰＢＢ及び／またはＳＢＢに十分なトークンが存在する場合（構成
要素１１１４にて検出）、受付コントローラは、検討中の作業要求のために集合数を同様
に確認する必要のある別のバケットがバーストモードトークンバケットセットに含まれる
か否かを判断しうる。例えば、いくつかの実施形態において、バーストモードトークンバ
ケットセットは、１以上の共有リソース能力バケット６０６及び／または１以上の複製管
理バケット６０８を含みうる。追加のバーストモードトークンバケットが実装されていて
、かつ作業要求に関連するこれらの残りのバーストモードトークンバケットのそれぞれに
十分なトークンが確認される場合（構成要素１１１８にて検出）、各関連バケットから適
切な数のトークンが消費され（例えば、適用消費ポリシーに従って）、そして作業要求が
実行対象として受付けられうる（構成要素１１２０）。少なくともいくつかの実施形態に
おいて、いくつかの追加バーストモードトークンバケットは特定の作業要求カテゴリにの
み関連しうることに留意されたい。例えば、一実施形態において、複製管理トークンバケ
ット６０８の集合数は、書込み要求受付制御のためにのみ確認され、このような実施形態
において、読出し要求を受付けるか否か判断する際は確認され得ない。従って、いくつか
の実施形態において、バーストモードトークンバケットが存在したとしても、受信された
全ての作業要求の受付制御のために当該バケットが使用されなければならない、とは意味
し得ない。

描写された実施形態において、複合トークンバケットペア（すなわちＰＢＢ及び／また
はＳＢＢ）（構成要素１１１４にて検出）または関連追加バーストモードトークンバケッ
ト（構成要素１１１８にて検出）のいずれにおいても消費されるのに十分なトークンが利
用可能でない場合、作業要求は拒否、延期、または再試行されうる（構成要素１１３８）
。いくつかの実施形態において、作業要求が受付けられたか、拒否されたかに関係なく、
受付制御に使用される１以上のバケット（例えば通常モードトークンバケットセット１２
０のバケット及び／またはバーストモードバケットセット１２５のバケットを含む）は、
受付制御判断が行われた後に、対応する補充ポリシーに従って補充されうる（構成要素１
１４０）。所定の作業要求に対応する自身の処理を完了後、受付コントローラ１８０は次
の作業要求が到着するのを待ち受け、そしてバーストモード時に受信された次の作業要求
に対し、構成要素１１１０以降に対応する処理が繰り返されうる。

異なる実施形態において、トークン補充処理（すなわち所定のトークンバケットに対し
トークンを追加する処理）は、異なるイベントに応じて、または異なるスケジュールに基
づいて、行われうる。図１２は、少なくともいくつかの実施形態による、受付制御のため
に行われうるトークンの消費、補充、及び譲渡処理の態様を示すフロー図である。構成要
素１２０１に示されるように、受付コントローラは、バケット集合数の変更につながりう
るトリガーイベントの種類を特定しうる（例えば、構成パラメータを調べることによって
）。いくつかの実施形態において、新規作業要求の到着及び／または対応する受付制御判
断の完了が、トークン集合数の変更を引き起こしうる。一実施形態においては、バケット
における最期の集合数変更からの時間間隔（例えばＮ１ミリ秒またはＮ２秒）の経過が、
トークン集合数を引き起こしうる。さらに別の実施形態においては、時間間隔の経過、作
業要求の到着、及び／または作業要求受付制御の完了の組合せが、トークン集合数の変更
を引き起こしうる。次のトリガーイベントの発生が検出されうる（構成要素１２０６）。
例えば通常モードバケット及びバーストモードバケットを含む様々なトークンバケットの
現在の集合数が特定されうる（構成要素１２１０）。いくつかの実施形態において、様々
なトークンバケットに対する読出し及び書込みは、全て単一のアトミック処理（データベ
ーストランザクションと同類）で行われ、そしてこのような実施形態において、当該アト
ミック処理は、現在のトークン集合数の読出しから始まりうる。

描写された実施形態において、トリガーイベントがトークンの消費または破棄を伴う場
合（構成要素１２１４にて検出）、各バケットの消費されるまたは破棄されるトークン数
が決定され（構成要素１２１７）、そしてバケット集合数（複数可）が適宜調整されうる
。前述のように、様々な実施形態において、受付けられた各作業要求に対し、いくつかの
トークンが消費されうる。いくつかの実施形態において、トークンは最大存続期間を有し
、それぞれの最大存続期間中ずっと未使用のトークンは、トークン老朽ポリシーに従って
破棄されうる。

少なくともいくつかの実施形態において、１つのバケットに未使用のまま残るトークン
は、別のバケットに「譲渡」されうる。例えば、プロビジョン能力バケットの未使用トー
クンは、１つまたは複数のバーストモードバケットに蓄積または貯蓄されうる。様々な実
施形態において、トークンの「譲渡」には、例えば特定の時点にプロビジョン能力バケッ
トに未使用のＮトークンが見つかった場合、バーストモードバケットにＮトークン分追加
され、かつプロビジョン能力バケットのトークン集合数はＮ分削減される、論理処理が含
まれることに留意されたい。すなわち、このような実施形態において、譲渡元及び譲渡先
のトークン集合数が調整され、トークンは実際に送信または移動等され得ない。いくつか
の実施形態において、譲渡元バケットに未使用のＮトークンが見つかった場合、Ｎトーク
ンは複数の譲渡先バケットのそれぞれに追加されうる（例えば、プロビジョン能力バケッ
トにおけるたった１つの未使用のトークンの検出により、複合トークンバケット８０１の
ＰＢＢ及びＳＢＢ両方の集合数は増加するに至る）。このような譲渡が行われると（構成
要素１２２０にて検出）、譲渡元バケット（複数可）の集合数は削減され、かつ譲渡先バ
ケット（複数可）の集合数は増加されうる（構成要素１２２３）。

必要に応じて、様々なバケットに対し、それぞれの補充ポリシーに従ってトークンが追
加され（構成要素１２２７）、そして構成要素１２１０に対応する処理において、アトミ
ック処理すなわちトランザクションが開始されていた場合、当該アトミック処理は終了さ
れうる（構成要素１２３０）。いくつかの実施形態において、トークンが消費、破棄、ま
たは譲渡されたかに関係なく、このような補充処理が行われうる（すなわち、このような
実施形態において、構成要素１２１４及び１２２０において判断された肯定的及び否定的
結果の両方に対し、補充処理が続いて行われうる。）このような実施形態において、単一
のアトミック処理にて説明された様々なトークン集合数の調整を行うことで、受付コント
ローラは、多数のバケット組合せにわたって所望するレベルの一貫性を確保しうる。受付
コントローラはその後次のトリガーイベントを待ち受け、そして次のトリガーイベントが
検出されると、構成要素１２０６以降に対応する処理が繰り返されうる。

前述のように、少なくともいくつかの実施形態において、受付制御判断の結果、及び／
または作業要求の受付に伴い消費されるトークン数は、作業要求が受付けられた場合に行
われるはずの作業量の見積りに少なくとも一部基づきうる。いくつかの実施形態において
、見積りが不正確であると判明する場合もあり、受付コントローラ１８０は、例えば受付
けられた作業要求の作業が完了し、作業量の不一致が（もしある場合）明らかになった時
に、このような見積りエラーを補償するように構成されうる。図１３は、少なくともいく
つかの実施形態による、受付済作業要求に対応する作業処理が完了した後に、１以上のト
ークンバケットにおけるトークン数を調整するために行われうる処理態様を示すフロー図
である。構成要素１３０１に示されるように、受付コントローラは、作業要求に対応する
作業の完了を示す次の通知を受信しうる。このような通知は、例えば作業対象が実行され
るサービスの管理コンポーネントにより受付コントローラに対し非同期的に提供され、そ
して作業要求に対して実際に行われた作業量の計量を含みうる。

描写された実施形態において、受付コントローラ１８０は、実際に行われた作業量に関
して、元の見積りが大きすぎたのか小さすぎたのかを判定しうる。見積りよりも多くの作
業が行われた場合（構成要素１３０４にて判定）、受付コントローラは、過小見積りに対
する補償として、１以上のトークンバケットから差し引くトークン数を決定し（構成要素
１３０８）、これに応じて当該バケットの集合数を下方修正しうる。場合によっては、当
該下方修正により、トークン集合数がマイナスになりうる。少なくともいくつかの実施形
態において、最終的にはトークン集合数は補充処理によりプラスの値に戻りうるが、所定
のバケットにおけるトークン集合数がマイナスの状態の間、新規の作業要求の受付判断は
所定のバケットの集合数に基づいて行われるため、新規の作業要求は拒否されうる。

少なくとも一実施形態によれば、元の作業見積りが大きすぎた場合（構成要素１３１２
にて判定）、受付コントローラ１８０は任意で、１以上のバケットに追加するトークン数
を決定し、これに応じてバケット集合数を設定しうる（構成要素１３１６）。描写された
実施形態において、受付コントローラは、作業見積りの正確度に関する記録を保持するよ
うに構成されうる。例えば、期間を通して受付けられた一部または全ての作業要求に対す
る見積り及び実作業量の記録が、データベースまたはログに保持されうる。従って、見積
りが正確であろうがなかろうが、かつエラーがあった場合は当該エラーの種類に関わらず
（例えば、見積りが大きすぎようが小さすぎようが）、受付コントローラは作業見積りエ
ラーに関する記録を更新しうる（構成要素１３２３）。このような記録維持は、例えば、
受付コントローラはエラーに基づいて見積手順を適合させるため、経時的な見積りの正確
度の向上に役立ちうる。いくつかの実施形態において、このような記録は、作業要求のサ
ブセット（例えばランダムサンプル）に関してのみ保持されうる、またはそのエラーの大
きさが閾値を超える作業要求に関してのみ保持されうる。描写された実施形態において、
記録の更新後、受付コントローラは次の完了に関して知らせが来るのを待ち、構成要素１
３０１以降に対応する処理が繰り返されうる。いくつかの実施形態において、図１３に示
される処理と同様の処理が、通常モードバケットだけでなくバーストモードバケットにお
いても行われうる。少なくとも一実施形態において、図１３に示される種類のバケット集
合数に対する遡及訂正は、受信するクライアント作業要求の受付制御判断において低い優
先順位で、またはバックグランドタスクとして、行われうる。

いくつかの実施形態において、所定の作業対象の利用可能処理能力は、受信作業要求以
外の要因に影響されうる。例えば、作業対象の状態が復元される障害からの復旧等のある
種類の管理処理、または様々な種類の保守処理により、クライアント要求に対して利用可
能な処理能力は低下しうる。図１４は、少なくともいくつかの実施形態による、管理イベ
ントに応じてバーストモード受付制御パラメータを修正するために行われうる処理態様を
示すフロー図である。構成要素１４０１に示されるように、受付コントローラ１８０は、
１以上の作業対象の利用可能処理能力の低下につながりうる復旧処理の開始等のバックグ
ラウンドイベントまたは管理イベント（すなわち、クライアント作業要求が直接の原因で
起こらないイベント）の通知を受信しうる。それから受付コントローラは、イベントを考
慮して、バースト対応（例えばプロビジョン処理能力よりも高い率での対応）を一時的に
無効にするか否かを判断しうる。バースト対応が無効化される場合（構成要素１４０４に
て決定）、イベントが完了するまで通常モード受付制御のみが対応されうる（構成要素１
４０８）。

バースト対応が完全に無効化されない場合（同様に構成要素１４０４にて決定）、いく
つかの実施形態において、受付コントローラは、例えば１以上のバケットからいくつかの
トークンを取除く、または補充率を一時的に下方修正する等して、許容バースト対応量を
制限するように構成されうる。このような実施形態において、受付コントローラは、差し
引くトークンの数、及び／または補充率を下げる程度を決定しうる（構成要素１４１２）
。これに応じて１以上のバケットの集合数が調整され、及び／または補充率が決定通りに
修正されうる。少なくとも一実施形態において、場合によっては、所定のバケットの集合
数は調整の結果マイナスになりうる。そして受付コントローラは、管理またはバックグラ
ウンドイベントが完了したことを示す通知を待ち受けうる（構成要素１４１５）。イベン
トの完了後、少なくともいくつかの実施形態において、受付コントローラは、イベントが
原因で行われた一部または全ての変更を任意で元に戻しうる（構成要素１４１８）。例え
ば、一部のバケットの集合数は増やされ、及び／または補充率は元の値に戻されうる。い
くつかの実施形態において、イベント通知の受信前に使用されていた元のパラメータによ
るバーストモード受付制御が再開される。少なくともいくつかの実施形態において、通常
モード受付制御は（バーストモードとは対照的に）、バックグラウンドまたは管理イベン
トが起こっている間、影響を受けずに継続されうることに留意されたい。少なくともいく
つかの実施形態において、管理イベントの間、補充率（修正された可能性あり）に従って
、バーストモードバケットに対しトークンが継続して追加されうる。

所定の作業対象に関するバーストモード受付制御を統御する少なくともいくつかのパラ
メータ（補充率、最大バケット集合数等）は、時間と共に修正される必要がありうる。図
１５は、少なくともいくつかの実施形態による、トークンベースのバーストモード受付制
御に使用されるパラメータを調整するために行われうる処理態様を示すフロー図である。
描写された実施形態において、構成要素１５０１に示されるように、１以上の作業対象に
関する作業要求到着率、受付率、及び／または拒否率が監視されうる（例えば、受付コン
トローラにより、または作業対象（複数可）を実行するサービスと提携する最適化エンジ
ンにより）。受付、拒否、及び到着率に関する収集されたデータは、作業対象から収集さ
れた、または作業対象に対応付けられたリソース使用計量と共に、分析されうる。分析に
より、バーストモード受付制御を統御するパラメータが変更されるべきであることが示唆
された場合（構成要素１５０４にて判定）、受付コントローラまたは別のサービスコンポ
ーネントにより、パラメータ変更を実行した場合の見積費用が特定されうる（構成要素１
５０８）。分析によりパラメータ変更は必要ないと示唆された場合、構成要素１５０１の
監視処理が再開されうる。

いくつかの事例において、費用（または少なくともクライアントに請求されうる費用の
一部）は、ごく少額またはゼロでありうる。このようなシナリオにおいては、作業対象を
設定したクライアントとの更なる対話なしに、パラメータ変更が行われうる。別の事例に
おいては、一または複数のクライアントは、提案されたパラメータ変更の可能性のある費
用及び可能性のある効果に関して通知されうる（構成要素１５１０）。１以上のバースト
モードパラメータのパラメータ変更要求をクライアントが返答した場合（構成要素１５１
２）、パラメータ変更が実行されうる（構成要素１５１６）。受付コントローラは、到着
率、受付率、及び拒否率の監視を再開しうる（構成要素１５０１）。いくつかの実施形態
において、図１５に示されるものと同様の受付制御パラメータ変更が、構成要素１５０１
及び１５０４に示される監視された計量の分析に直接関係のない理由で、導入されうるこ
とに留意されたい。例えば、いくつかの実施形態において、クライアントは所定の作業対
象のプロビジョン処理能力の変更を要求し、そして当該作業対象のプロビジョン処理能力
の変更要求が受付けられると、受付制御パラメータ（少なくともいくつかはプロビジョン
処理能力の関数でありうる）は自動的に変更されうる。別の実施形態においては、作業対
象を実行するサービスの管理者が、ウィンドウズ（登録商標）のメンテナンス、アップグ
レード、機器変更等、様々な他の理由で、少なくともいくつかの受付制御パラメータを少
なくとも一時的に変更しうる。少なくともいくつかの実施形態において、クライアントは
パラメータのサブセットにのみアクセス可能であるため、パラメータ変更に対する実質的
管理制御が可能となる。
作業対象間トークン共有

前述のように、少なくともいくつかの環境において、作業要求は時間に関してだけでな
く、対象とした特定のデータサブセットに関しても不均一に分散しうる。図１６は、少な
くともいくつかの実施形態による、作業要求到着率の不均一性と共に、サービスにより管
理されるデータの異なるサブセットに関する作業要求の例示的不均一分散を示す図である
。描写された実施形態において、データオブジェクト２０１０Ａ（例えばデータベーステ
ーブルを含みうる）はＯ１−Ｐ１、Ｏ１−Ｐ２、Ｏ１−Ｐ３の３つのパーティションを含
み、一方別のデータオブジェクト２０１０BはパーティションＯ２−Ｐ１を含む。各パー
ティションは、各自のプロビジョン能力（例えば、読出し／秒、書込み／秒等、毎秒対応
される作業要求の数により表される）を有する個別の作業対象とみなされうる。プロビジ
ョン能力はＰＣ１等と称されるオブジェクトにより示される（パーティションＯ１−Ｐ１
、Ｏ１−Ｐ２、Ｏ１−Ｐ３、及びＯ１−Ｐ４のプロビジョン能力は、それぞれＰＣ１、Ｐ
Ｃ２、ＰＣ３、及びＰＣ４である）。描写された実施形態において、受信作業要求を受付
けるか拒否するかに関する受付制御判断は、各パーティションの各自のトークンバケット
セットを使って、パーティションごとに個別に行われる。いくつかの実施形態において、
各パーティションは、例えば各自の通常モードトークンバケットセット及びバーストモー
ドトークンバケットセットを有しうる。データオブジェクト２０１０Ａ及び２０１０Ｂは
単一のクライアントエンティティに所有され、または割当てられ、そしてあるクライアン
トアプリケーションセット等の共通目的のために使用されうる。従って、データオブジェ
クトの所有者の観点からすると、４つのパーティションは全て同一のデータセットの一部
とみなされうる。一般的に４つのパーティションは、サイズ（すなわち、各パーティショ
ンにおいて保有されるデータ量）及び／またはプロビジョン能力においてそれぞれ異なり
うる。

時間窓Ｔ０−Ｔ１の間に各パーティションすなわち各作業対象に到着する作業要求の率
Ｗが、図１６に含まれるグラフで示される。矢印２０５１、２０５２、２０５３、及び２
０５４で示されるように、パーティションＯ１−Ｐ１、Ｏ１−Ｐ２、Ｏ１−Ｐ３、及びＯ
２−Ｐ１における作業要求到着率が、曲線Ｗ１、Ｗ２、Ｗ３、及びＷ４でそれぞれ表され
る。各パーティションのプロビジョン能力もまた示される。Ｏ１−Ｐ１の場合、作業要求
到着率Ｗ１は描写された時間窓の間、一貫してプロビジョン能力ＰＣ１より低い。Ｏ１−
Ｐ２に関しては、到着率Ｗ２は時間帯Ｔ０−Ｔ１の大部分の間、プロビジョン能力ＰＣ２
を超えている。従って、Ｏ１−Ｐ２は示された時間帯の大部分においてバーストモードで
あり続けたであろう。Ｏ１−Ｐ３に関しては、到着率は概してプロビジョン能力ＰＣ３に
近く、そしてＯ２−Ｐ１の到着率Ｗ４はほんのわずかの間、プロビジョン能力ＰＣ４を超
える。Ｏ１−Ｐ２における作業要求拒否率Ｒ２により示されるように、例えば受付制御に
おけるバーストモードバケットの使用にもかかわらず、いくつかの作業要求がＯ１−Ｐ２
において拒否された可能性がある。

示されるように、異なるパーティションを対象とした作業要求の到着率は、同一の時間
間隔の間でも、実質的に異なりうる。一部のパーティション（例えば、Ｏ１−Ｐ１）はそ
の通常モードトークンも全て使い切ってすらいないのに対し、同一オブジェクトの（また
は同一の所有者の別のオブジェクトの）他のパーティションは、１以上のバーストモード
バケットを実装しているにもかかわらず、作業要求を拒否しなければならないほど大きな
作業量を有しうる。従って、描写された実施形態において、４つのパーティションはトー
クン共有グループ２００２の構成員とみなされ、そして示された空間的不均一性の影響を
低減するために、グループ２００２において反復トークン共有プロトコルが実行されうる
。

トークン共有プロトコルが契機となって、いくつかまたは全てのパーティションすなわ
ち作業対象（例えば、各パーティションの受付コントローラ）により、トークン共有反復
の評価を試みるべきであるか否かに関する判断が行われる（例えば、一定の間隔で、また
はランダムな長さの時間が経った後に）。すなわち、Ｏ１−Ｐ２等の所定の作業対象は、
様々な基準のいずれかに基づいて、現在のバケット集合数と最近の作業量とを考慮した上
で、トークンを交換可能な１以上のパートナー作業対象を見つけ出すことが有意義である
か否かを判断しうる。トークン共有の評価を行うという判断が下された場合、作業対象は
、現在のプロトコル反復においてトークン共有イニシエータの役割を担い、そして１以上
のバケット種類に関するトークン集合数情報を交換するための１以上のパートナー作業対
象（同一のトークン共有グループの構成員）を特定しうる。イニシエータ及びパートナー
ピアのトークン集合数の分析後、イニシエータから関与する第二ピアの方向に、またはそ
の反対方向に、いくつかのトークンが譲渡されるべきか否かに関する、第二の判断が行わ
れうる。従って、例えば図１６において、Ｏ１−Ｐ２はイニシエータとなり、そしてバー
ストモードトークンバケットに関するトークン集合数情報をＯ１−Ｐ１と交換しうる。Ｏ
１−Ｐ２のバーストモードバケットが、Ｏ１−Ｐ１の対応するバーストモードバケットよ
りも大幅に少ないトークン数を有する場合、Ｏ１−Ｐ１はＯ１−Ｐ２に対しＮ個のトーク
ンを譲渡すべきであると、Ｏ１−Ｐ１及びＯ１−Ｐ２はお互いに断定しうる。これに応じ
て、Ｏ１−Ｐ２のバケットにＮトークンが追加され、そしてＯ１−ＰのバケットからＮト
ークンが削除されうる。トークンの追加により、Ｏ１−Ｐ２は図１６に示されるより大き
な作業量に対応可能となり、一方Ｏ１−Ｐ１におけるトークンの削減は、Ｏ１−Ｐ１にお
ける低い要求率を考えると、悪影響を少しもたらしていないだろう。その後、引き続くト
ークン共有プロトコルの反復において、必要であればある別のピア作業対象が、大きく負
荷がかかることになったいずれの作業対象にでもトークンを譲渡しうる。例えば、Ｏ１−
Ｐ２はその後、他のパーティションのいずれかにトークンを譲渡する立場にありうるが、
Ｏ１−Ｐ１は他のパーティションにトークンを提供する代わりに、トークンを要求するに
至りうる。いくつかの実施形態において、論理的に譲渡されるトークンの正確な数は、例
えばトークン集合数の違いに基づいて、及び／または作業対象のうちの１つにより要求さ
れるトークン数に基づいて等、所定の譲渡に関わる作業対象間における双方の合意により
決定されうる。

少なくともいくつかの実施形態において、このようなトークン譲渡に「ゴシッププロト
コル」が使用されうる。このような実施形態において、各作業対象は、ランダムな長さの
時間が経った後、イニシエータとして作動し、そして無作為抽出法を使用して、集合数情
報交換を行う別の作業対象を特定するように構成されうる。いくつかの実施形態において
、トークン譲渡に（トークン集合数情報交換にも）関与するか否かに関する判断は、各作
業対象によって自主的に行われうる。トークン共有グループの構成員は、異なる実施形態
における様々な要因に基づいて決定されうる。例えば、いくつかの実施形態において、所
定クライアントＣ１は、自身のデータオブジェクトＯ１、Ｏ２、及びＯ３は１つのトーク
ン共有グループＧ１の構成員とみなし、データオブジェクトＯ４及びＯ５は別のトークン
共有グループＧ２の構成要素とみなすが、データオブジェクトＯ６のトークンは共有しな
いことを示しうる。いくつかの実施形態において、ネットワークアクセス可能なサービス
により、少なくともいくつかのトークン共有グループ構成員決定が行われるが、別の実施
形態においては、クライアントからの明確な要求があった時にのみ、所定の作業対象セッ
トに対しトークン共有が実行されうる。いくつかの実施形態において、いくつかの異なる
クライアントが必要に応じて、それらのデータオブジェクト間でトークンを共有すること
を判断しうる。すなわち、トークン共有グループの全ての構成員が、同一のクライアント
エンティティ（企業組織またはネットワークアクセス可能なサービスの個人ユーザ等）に
所有されている必要はない。
例示的トークン共有プロトコル反復

図１７は、少なくともいくつかの実施形態による、データアクセスの空間的不均一性の
影響を緩和するために実行されうるトークン共有プロトコルの例示的反復を示す図である
。３つのピア作業対象（例えば、テーブルパーティション）ピアＡ、ピアＢ、及びピアＣ
が、示された実施例における同一のトークン共有グループの構成員であり、そしてそれぞ
れがトークン共有に関わる単一のトークンバケット（例えば、バーストモードバケット、
または通常モードバケット）を有する。連続するプロトコルの反復の発生に伴う３つのピ
アのバケットのトークン集合数が、図の上部から下部に向かって増加する時間と共に経時
的に示される。実施例を簡潔にするために、プロトコルの反復１から順方向に開始し、補
充率、作業要求の受付、または他の要素から起こるトークン集合数の変化は無視し、そし
てトークン共有プロトコルを実行した結果起こるトークン集合数の変化にのみ着目する。

図１７に示される時間帯の始めに、各ピアは１０００トークンをバケットに有する。プ
ロトコルの第一反復が始まる時点で、矢印２１５０で示される受信作業要求によりピアＡ
は５０トークンのみを有するが、ピアＢ及びピアＣはまだ１０００トークンを有する。示
された実施例において、反復毎に、当該ピアのうちの１つがもう１つ別のピアとトークン
集合数情報の交換を開始する（いくつかの実施形態において、所定の反復には多数のピア
の対が関与しうる。図１７においてはプロトコルの作動に関する単純化された実施例のみ
が提供される）。関与する２つのピアが、それぞれのトークン集合数Ｐ１及びＰ２を比較
し、そして（ここではＰ１＞Ｐ２と仮定する）、トークンの多いピアからトークンの少な
いピアに対し（Ｐ１−Ｐ２）／２トークン（整数に丸められたトークン数）を譲渡するこ
とを決定する。様々な実装例において、譲渡されるトークン数は様々な異なる要因に基づ
いて決定されうる。例えば（Ｐ１−Ｐ２）／２以外の式または関数が使用されうる。

従って、示された実施例における反復１の間、ピアＣ（１０００トークンを有する）は
ピアＡ（５０トークン）と集合数情報交換を開始し、そしてトークン譲渡サイズが（１０
００−５０）／２＝４７５に決定される。よって、ピアＣからピアＡへの矢印によって示
されるように、４７５トークンがピアＡのバケットに追加され、４７５トークンがピアＣ
から取除かれる。譲渡の後、ピアＡ及びピアＣの両方が５２５トークンを有する。

反復２において、イニシエータとして作動するピアＢ（１０００トークン）とピアＡ（
５２５トークン）の間でトークン集合数情報が交換され、（１０００−５２５）／２すな
わち約２３７トークンがピアＢからピアAへ譲渡されるに至る。その結果、ピアＡはこの
時点で合計７６３トークンを有し、そしてピアＢは７６２トークンを有する。（描写され
た実施形態においては、端数のトークンに非対応のため、反復２の終了時点でピアＡとＢ
のトークン数には１の差がある。別の実施形態においては、端数のトークン数に対応可能
であるため、この場合にはピアＡ及びピアＢの両者が７６２．５トークンを有しうる。）

反復３において、ピアＡ（７６３トークン）及びピアＣ（５２５トークン）が再びトー
クン集合数情報を交換し、そしてピアＡは（７６３−５２５）／２＝１１９すなわち１１
９トークンをピアＣへ譲渡する。反復４において、ピアＢ（７６２トークン）はピアＣ（
６４４トークン）へ５９トークンを譲渡し、そして反復５においては、ピアＢ（７０３ト
ークン）がピアＡ（６４４トークン）へ２９トークンを譲渡する。追加の反復（図示せず
）により、トークンの多いピアからトークンの少ないピアへさらなるトークンの譲渡が行
われうる。図１７に示される例示的反復は、描写された実施形態において実施される特定
のトークン共有プロトコルの高次特徴を示すことを目的とし、より一般に、または別の実
施形態に対し必ず適用可能であるプロトコルルールを含むことを目的としないことに留意
されたい。

所定の作業対象が正確にいつ、どのような状況でトークン集合数情報交換を開始するべ
きか、集合数情報交換をどの他の作業対象と行うべきか、そして（もしあれば）譲渡すべ
きトークン数を決定するのに何の基準が使用されるべきかに関する判断は、全て異なる実
施形態における異なる基準セットに基づいて行われうる。いくつかの実施形態において、
例えば、所定の作業対象における受付コントローラまたは他のサービス管理コンポーネン
トにより、当該作業対象における拒否率が閾値より大きいことが明らかとなった場合、ト
ークン共有プロトコルの新規反復が開始されうる。別の実施形態においては、あるセット
のバケット（例えばバーストモードバケット）のトークン数が閾値より小さくなった場合
、トークン共有プロトコルの新規反復が開始されうる。いくつかの実装例において、前述
のように、プロトコルの反復はランダムに選択された作業対象からランダムな時間に開始
され、そして集合数情報を交換する作業対象もまたランダムに選択されうる。少なくとも
一実施形態において、連続するトークン共有プロトコル反復があまりにも頻繁に実行され
ることで生じうる負荷を低減するために、トークン共有に関する制限ポリシーが実施され
る。これにより、例えばＸ秒またはＸ分毎に、所定作業対象が任意の他の作業対象に対し
譲渡可能な、または任意の他の作業対象から受取可能な最大トークン数が、Ｔｍａｘ個に
制限される。別の実装例において、同一の作業対象ペア間における行き戻りトークン譲渡
をある最大率までに制限する等、別の制限ポリシーが適用されうる。例えば、作業対象Ｗ
Ｔ１及びＷＴ２は、１５分毎に最大Ｋ回トークン譲渡に関与してもよい。いくつかの事例
において、作業対象ペアＷＴ１及びＷＴ２の間で、時間Ｔｋより前の特定の時間窓内にあ
るトークン譲渡が起こった場合、時間Ｔｋにおいて新規のトークン譲渡は許可され得ない
。

図１７に示される実施例において、譲渡されるトークン数は、トークン数が多いピアと
トークン数が少ないピアの差の半分として単純計算される。別の実施形態においては、譲
渡サイズは、例えば各作業対象がトークン譲渡に関して最小トークン集合数を有する等（
このため最小レベルに達すると、別の作業対象が自分よりも小さいトークン数を有してい
てもトークンは全く譲渡されない）、別の要因に基づいて決定され、または譲渡されるト
ークン数は、作業対象における最近の作業量レベル、もしくは作業対象におけるプロビジ
ョン能力に少なくとも一部基づきうる。少なくともいくつかの実施形態において、別の作
業対象へのトークンの贈与は任意で行われうる。例えば、所定の作業対象ＷＴ１がピアＷ
Ｔ２よりもより多くのトークンを有していたとしても、ＷＴ１はＷＴ２に対しトークンを
譲渡する義務はないだろう（例えば、近いうちにＷＴ１において重い作業要求バーストが
起こると予想されるため、別の作業対象へトークンを譲渡することは適切ではない）。
データ複製役割に対応する環境におけるトークン共有

いくつかの実施形態において、前述のように、データベースサービスまたはストレージ
サービスは、クライアントのデータの多数のレプリカを記憶し、そして異なるレプリカは
作業要求の受付制御に関して異なる役割を担いうる。例えば、作業要求が読出し及び書込
みを含む環境において、いくつかのレプリカは読出しだけでなく書込みに対しても受付制
御の責任を担い、一方他のレプリカは読出しのみ対処しうる。このような実施形態におい
て、トークン共有プロトコルが実行されるピア作業対象のグループは、少なくとも一部は
レプリカの役割により決定されうる。図１８は、少なくともいくつかの実施形態による、
データパーティションが複製される環境において確立されうるトークン共有ピアグループ
の実施例を示す図である。

オブジェクト２２０１Ａ、２２０１Ｂ、２２０１Ｃ及び２２０１Ｄ等のデータオブジェ
クト２２０１（例えば、データベーステーブルまたはストレージボリューム）は、それぞ
れ１以上の論理パーティションを備え、それぞれの論理パーティションに対応して、２つ
以上の物理レプリカが、サービスのデータ耐久性要件に従って記憶されうる。描写された
実施形態において、物理レプリカのうちの１つは「マスタ」レプリカ（または単純にマス
タ）と称され、そして残りのレプリカは「スレーブ」レプリカ（または単純にスレーブ）
と称されうる。描写された実施形態において、マスタレプリカは、書込みを含む作業要求
の受付制御の責任を担い、一方読出し要求は、いずれのレプリカにおいても（スレーブレ
プリカ（複数可）だけでなくマスタにおいても）実行対象として受付けられうる。従って
、所定の論理パーティションに対する書込み要求は、マスタレプリカに向けられ、このマ
スタレプリカにて当該書込みを受付けるか拒否するかに関する判断が行われうる。書込み
が受付けられると、対応するデータ修正は、まずマスタにおいて行われ、それからスレー
ブへ広められうる。図１８に示される実施形態において、読出し要求はいずれかのレプリ
カに向けられうる（その結果、スレーブで読まれたあるデータは、直近の書込み要求によ
る変更がスレーブにおいて複製されていないことを考慮すると、最新のものではあり得な
い）。各物理レプリカは、例えばマスタレプリカにはマスタバケット、そして各スレーブ
レプリカにはスレーブバケットセットというように、受付制御用の関連トークンバケット
セットを有しうる。所定の物理レプリカに割当てられた「マスタ」及び「スレーブ」の役
割は、時間と共に変更しうる。例えばマスタへの接続障害または接続切断のため、スレー
ブがマスタ役に昇進しうる。別の実施形態においては、マスタ及びスレーブ役に対応付け
られる責任は異なりうる。例えば、いくつかの実施形態においては、読出しの受付制御も
マスタにおいて行われうる。

図１８に示される実施形態において、データオブジェクト２２０１Ａは、物理パーティ
ションＯ１−Ｐ１、Ｏ１−Ｐ２、Ｏ１−Ｐ３を有する。所定の論理パーティションＯｘ−
ＰｙのマスタレプリカはＯｘ−Ｐｙ−Ｍと称され、ｋ番目のスレーブレプリカはＯｘ−Ｐ
ｙ−Ｓｋと称される。Ｏ１−Ｐ１−Ｍと称されるＯ１−Ｐ１のマスタレプリカは、サービ
スのストレージノード２２１０Ａに属するストレージデバイス２２０２Ａに配置される。
Ｏ１−Ｐ１−Ｓ１と称されるＯ１−Ｐ１のスレーブレプリカは、ストレージノード２２１
０Ｂのストレージデバイス２２０２Ｂに配置される。データオブジェクト２２０１Ｂは論
理パーティションＯ２−Ｐ１及びＯ２−Ｐ２を有し、データオブジェクト２２０１Ｃは論
理パーティションＯ３−Ｐ１及びＯ３−Ｐ２を有し、そしてデータオブジェクト２２０１
Ｄは論理パーティションＯ４−Ｐ１〜Ｏ４−Ｐｎを有する。描写された実施形態において
、一般に同一の論理パーティションの多数のレプリカは、データ耐久性のため、同一のス
トレージデバイスまたは同一のストレージノードに記憶され得ない。このような耐久性由
来の制約を除いては、レプリカは一般に、描写された実施形態において、十分な利用可能
な領域を有するどの（例えば、ランダムに選ばれた）ストレージデバイスまたはストレー
ジノードにでも記憶可能である。例えば、ストレージデバイス２２０２Ａはまた、データ
オブジェクト２２０１Ｂの論理パーティションＯ２−Ｐ１のスレーブレプリカＯ２−Ｐ１
−Ｓ１と、データオブジェクト２２０１Ｃの論理パーティションＯ３−Ｐ１のスレーブレ
プリカＯ３−Ｐ１−Ｓ２とを含み、一方ストレージデバイス２２０２Ｂは、スレーブレプ
リカＯ４−Ｐ２−Ｓ２とマスタレプリカＯ２−Ｐ１−Ｍとを含み、そして同様にストレー
ジノード２２１０Ｂに属するストレージデバイス２２０２Ｃは、マスタレプリカＯ１−Ｐ
３−Ｍと、スレーブレプリカＯ２−Ｐ１−Ｓ１及びＯ４−Ｐ１−Ｓ１を含む。（空間に限
りがあるため、データオブジェクト２２０１Ａ〜２２０１Ｄのいくつかのパーティション
のいくつかのレプリカのみが図１８に示される）。

各物理レプリカは、スレーブ、マスタのいずれも、レプリカに対する作業要求の受付制
御用の各自のトークンバケットセットを有する。例えば、マスタレプリカＯ１−Ｐ１−Ｍ
、Ｏ２−Ｐ１−Ｍ、及びＯ１−Ｐ３−Ｍはそれぞれ、マスタバケットセット２２５２Ａ、
２２５２Ｂ、及び２２５２Ｃを有する。ストレージデバイス２２０２ＡのスレーブＯ２−
Ｐ１−Ｓ１及びＯ３−Ｐ１−Ｓ２は、スレーブバケットセット２２７２Ａ及び２２７２Ｂ
を有し、一方スレーブＯ１−Ｐ１−Ｓ１及びＯ４−Ｐ２−Ｓ２はスレーブバケットセット
２２７２Ｃ及び２２７２Ｄを有し、そしてスレーブＯ２−Ｐ２−Ｓ１及びＯ４−Ｐ２−Ｓ
１はスレーブバケットセット２２７２Ｅ及び２２７２Ｆを有する。各バケットセットは、
前述のバケットと同様の、例えば１以上の通常モードトークンバケット及び／またはバー
ストモードトークンバケット（場合によっては、複合バーストモードトークンバケットを
含む）を含む、１以上のトークンバケットを有しうる。個別のトークンバケットが読出し
及び書込み用に構成され（例えば、図５に示されるように）、かつスレーブレプリカが書
込みの受付制御には関与しないいくつかの実施形態において、スレーブバケットセット２
２７２は読出しトークンバケットのみを含み、一方マスタバケットセット２２５２は読出
しバケット及び書込みバケットの両方を含みうる。

マスタ役及びスレーブ役は異なる受付制御責任を担うことから、描写された実施形態に
おいて、所定のマスタレプリカは他のマスタレプリカのみとトークン共有プロトコルに関
与することが許され、同様に、スレーブレプリカは他のスレーブレプリカのみとトークン
を共有しうる。従って、図１８に示されるレプリカは、トークン共有ピアグループ２２４
２Ａ及び２２４２Ｂの２つに分類されうる。トークン共有ピアグループ２２４２Ａは、マ
スタＯ１−Ｐ１−Ｍ、Ｏ２−Ｐ１−Ｍ、及びＯ１−Ｐ３−Ｍ等の、あるデータオブジェク
トセットのマスタレプリカを含みうる。オブジェクト２２０１Ａ〜２２０１Ｄの、図１８
に図示されていない別のマスタレプリカは、グループ２２４２Ａに同様に含まれうる。ト
ークン共有ピアグループ２２４２Ｂは、スレーブＯ２−Ｐ１−Ｓ１、Ｏ３−Ｐ１−Ｓ２、
Ｏ１−Ｐ１−Ｓ１、Ｏ４−Ｐ２−Ｓ２、Ｏ２−Ｐ２−Ｓ１、及びＯ４−Ｐ１−Ｓ１を（図
１８に図示されていない別のスレーブレプリカと同様に）有しうる。従って、描写された
実施形態において、マスタレプリカは他のマスタとトークン集合数情報を交換し、他のマ
スタへトークンを譲渡し、他のマスタからトークンを受理し、そしてスレーブレプリカは
他のスレーブとトークン集合数情報及び／またはトークンを交換しうる。マスタはスレー
ブよりも多くの受付制御責任を担うことから、マスタにおけるトークンの損失または獲得
は、スレーブにおけるトークンの損失または獲得とは異なる影響を与えうるという仮定の
ように、例えばスレーブのトークン値と比較したマスタのトークン値に関する仮定が、こ
のような制限に反映されうる。いくつかの実施形態においては、このような役割ベースの
制限は実施され得ないため、マスタはさらに、または代わりに、スレーブへトークンを譲
渡し、その反対も行われうる。
二次インデックスのためのトークン共有

いくつかの実施形態において、トークンベースの受付制御は、最近人気の様々な種類の
「ＮｏＳＱＬ」サービスのいずれかの非リレーショナルデータベースサービスに対し実行
されうる。多数のこのようなデータベースサービスにおいて、一般に所定のテーブルの異
なる行は、異なる列コラムセットを有しうる。従って、少なくともいくつかの事例におい
て、各行は（主キー、値）対とみなされ、主キーコンポーネントは一次インデックスに使
用され、一方値コンポーネントは各コラムに対応する値のある任意集合を含みうる。多く
の場合にクライアントは、自分の非リレーショナルデータの二次インデックス、すなわち
主キー以外のコラムのインデックスの使用を所望しうる。いくつかの実施形態において、
このような二次インデックスは、導出テーブルを使用して実装されうる。例えば、所定の
テーブル（ベーステーブルと称されうる）に対応するデータの少なくともあるサブセット
は、二次インデックスを介した素早いアクセスに対応する導出テーブルとしても編制され
うる。いくつかの事例においては、ベーステーブルの全てのコラムが導出テーブルに複製
されることはない。いくつかの実施形態において、ベーステーブル及び１以上の二次イン
デックスに使用された導出テーブルは、受付制御用のトークンバケットをそれぞれ有する
１以上の論理及び／または物理パーティションをそれぞれ含みうる。いくつかの実施形態
において、ベーステーブルのパーティション及び導出テーブルのパーティションは、前述
のプロトコルと同様のトークン共有プロトコルのピアとして関与しうる。いくつかの実装
例において、ベーステーブルのそれぞれのサブセット（例えば、それぞれのパーティショ
ン）に対して、個別の二次インデックス（及び個別の導出テーブル）が設定されうる。別
の実装例においては、ベーステーブルの全てのパーティションに対応するデータを含む単
一の導出テーブルが、所定の二次インデックスに対して設定される。後者のシナリオにお
いて、ベーステーブル全体（ベーステーブルのサブセットではなく）に対応するデータに
アクセス可能になるため、二次インデックスは「グローバル二次インデックス」またはＧ
ＳＩと称されうる。

図１９は、少なくともいくつかの実施形態による、二次インデックスの作業量管理に対
応するための、データベースサービスにおけるトークン共有の使用の実施例を示す図であ
る。描写された実施形態において、ベーステーブル２３１０はＮ個のパーティションＢＴ
−Ｐ１、ＢＴ−Ｐ２、・・・、ＢＴ−ＰＮを含む。導出テーブル２３２０はベーステーブ
ルのＧＳＩに対応するように設定され、かつ当該導出テーブルはパーティションＧＳＩＴ
−Ｐ１、ＧＳＩＴ−Ｐ２、・・・、ＧＳＩＴ−ＰＱを含む。図１９においてレプリカは図
示されていないが、いくつかの実装例において、ベーステーブル２３１０及び／または導
出テーブル２３２０のパーティションは、データ耐久性のために複製されうる。一般に、
所定のベーステーブル用に設定された各ＧＳＩに対し、別の導出テーブルが作成されうる
。ベーステーブルパーティションに関してはＢＴＰＣ１、ＢＴＰＣ２、・・・と称される
構成要素により、そして導出テーブルに関してはＳＩＰＣ１、ＳＩＰＣ２、・・・と称さ
れた構成要素により示されるように、ベーステーブルの各パーティション及び導出テーブ
ルの各パーティションは、各自のプロビジョン能力を有する。描写された実施形態におい
て、受付制御判断はいずれのテーブルの各パーティションに対し独立して行われ、そして
各パーティションはトークンバケットのセット（１以上の通常モードトークンバケット及
び／またはバーストモードトークンバケット）を有しうる。いくつかの事例において、ベ
ーステーブルに対し導出テーブルとは異なる種類のバケットが実装されうる。例えば、ベ
ーステーブルは複合バーストモードバケットを使用し、一方導出テーブルは単純（非複合
）バーストモードバケットを使用しうる。

少なくともいくつかの実施形態において、クライアントの書込み要求に対応する更新は
、まずベーステーブルにおいて行われ、その後導出テーブルに広げられる。例えば、パー
ティションＢＴ−Ｐ１用の更新送信バッファ２３２５Ａ、パーティションＢＴ−Ｐ２用の
更新送信バッファ２３２５Ｂ、パーティションＢＴ−Ｐ３用の更新送信バッファ２３２５
Ｃ、及びパーティションＢＴ−ＰＮ用の更新送信バッファ２３２５Ｎ等、各ベーステーブ
ルパーティションに対して更新送信バッファが確立されうる。ベーステーブルパーティシ
ョンで行われた更新は、伝達のために（矢印２３５０で示されるように）対応する送信バ
ッファの待ち行列に入れられ、そして最終的には、導出テーブルのデータに適用される前
に、導出テーブルパーティションの対応する更新受信バッファ２３３０（例えば、受信バ
ッファ２３３０Ａ、２３３０Ｂ、２３３０Ｃ、及び２３３０Ｑ）に受信されうる。一般に
、ベーステーブルと導出テーブルのパーティションの間に一対一のマッピングはあり得な
い。例えば、パーティションＢＴ−Ｐ１における所定の更新は、導出テーブルパーティシ
ョンＧＳＩＴ−Ｐ３においてデータを修正することを要求し、一方パーティションＢＴ−
Ｐ１における別の更新は、ＧＳＩＴ−Ｐ１への修正に至りうる。ベーステーブルにまず適
用され、それから導出テーブルに適用される書込みと対照的に、読出しは、その読出し要
求の性質によって、ベーステーブルへの参照なしに導出テーブルのみで遂行されうる。例
えば、ＧＳＩのキーに関して作成された読出しクエリは導出テーブルを使用して応答され
うるが、他のキーに基づいた読出しクエリは、ベーステーブルまたは導出テーブルのいず
れかを使用して応答されうる。

少なくともいくつかの実施形態において、ベーステーブル及び導出テーブルに対し、プ
ロビジョン能力がそれぞれ独立して割当てられうる。従って、一実施形態において、クラ
イアントがテーブル作成を要求する場合、クライアントは下記と同様の命令文の論理的同
値を使用して、ベーステーブルのプロビジョン能力を指定し、確立されるべきＧＳＩ（複
数可）の指示を提供しうる。
ハッシュキーｋ１、毎秒読出し＝１２、毎秒書込み＝８のテーブルＴ１を作成、
ハッシュキーｋ２のグローバルインデックスＧ１；

当実施例において、主キー（この場合ハッシュキー）がｋ１であり、かつプロビジョン
処理能力が毎秒１２読出し処理及び毎秒８書込み処理であるベーステーブルＴ１が作成さ
れる。クライアントはまた、異なるハッシュキーｋ２のグローバル二次インデックスＧ１
が作成されるように指示しているが、当該ＧＳＩのプロビジョン処理能力は指定していな
い。このようなシナリオにおいて、データベースサービスは、クライアントにより指定さ
れたベーステーブルの総プロビジョン処理能力に基づいて、ベーステーブルパーティショ
ンにプロビジョン処理能力を割当てうる。そして導出テーブルのパーティション（ＧＳＩ
に使用される）に対しては、さらなるクライアントとの対話なしに、プロビジョン能力を
割当てなければならないだろう。様々な実施形態において、データベースサービスは、数
多くの異なる手法のいずれかを使用して、導出テーブルのパーティションのプロビジョン
能力を決定しうる。

当実施例の目的のため、２つのパーティションＢＴ−Ｐ１及びＢＴ−Ｐ２がベーステー
ブルに設定され、そして２つのパーティションＧＳＩＴ−Ｐ１及びＧＳＩＴ−Ｐ２がイン
デックスＧ１に対応する導出テーブルに設定されると仮定する。一手法において、クライ
アントに指示された総プロビジョン能力は、一緒に用いられるベーステーブルと導出テー
ブルの両方で処理されるべき読出し及び書込みの数を表すと仮定されうる。この場合、１
２読出し／秒はＢＴ−Ｐ１、ＢＴＲ−Ｐ２、ＧＳＩＴ−Ｐ１、及びＧＳＩＴ−Ｐ２のそれ
ぞれに対し３読出し／秒に分割され、８書込み／秒は同様に当該４つのパーティションの
それぞれに対し２書込み／秒に分割されうる。別の手法において、データベースサービス
は、クライアントが要求したプロビジョン能力はベーステーブルにのみ適用し、そして導
出テーブルのパーティションにおける追加の読出し及び書込みはプロビジョニングされる
必要があると仮定しうる。この２つ目の手法において、ＢＴ−Ｐ１及びＢＴ−Ｐ２のそれ
ぞれに、６読出し／秒及び４書込み／秒のプロビジョン能力が割当てられ、一方ＧＳＩＴ
−Ｐ１及びＧＳＩＴ−Ｐ２のそれぞれには、「ｖ」読出し／秒及び「ｗ」書込み／秒のプ
ロビジョン能力が割当てられうる。ｖ及びｗは、いくつかのヒューリスティックに基づい
て、または同様のＧＳＩによる以前の経験に基づいて、推定されうる。

いくつかの実施形態において、クライアントはＧＳＩに対し明確にプロビジョン能力を
指定（及び支払い）可能でありうる。例えば、クライアントはテーブルの作成を要求する
際、以下の論理的同値を指定しうる。
ハッシュキーｋ１、毎秒読出し＝１２、毎秒書込み＝８のテーブルＴ１を作成、
ハッシュキーｋ、毎秒読出し＝６、毎秒書込み＝６のグローバルインデックスＧ２；

当実施例において、クライアントはＧＳＩに所望するプロビジョン読出し及び書込み率
を、ベーステーブルのプロビジョン読出し及び書込み率とは別に指示し、そしてこれに応
じてデータベースサービスが、ベーステーブル及び導出テーブルのパーティションにプロ
ビジョン能力を割当てうる。いくつかの実装例において、ハッシュキー以外のインデック
スキー（例えば、範囲キー）がさらに、または代わりに指定されうることに留意されたい
。少なくとも一実施形態において、既存のテーブルに対しＧＳＩが作成されうる。例えば
クライアントは、ベーステーブルが作成される時に必要とするＧＳＩのセットに決める必
要はないだろう。

時間と共に、ベーステーブルのパーティション及び導出テーブルのパーティションに対
する作業量は大幅に変動し、そして所定の時間間隔において、読出し及び／または書込み
要求は、両種類のテーブルのパーティション中に不均一に分配されうる。空間的不均一性
による悪影響（作業要求拒否等）を低減するために、ベーステーブル２３１０及び導出テ
ーブル２３２０の全てのパーティションは、単一のトークン共有ピアグループ２３４２の
構成員となる。よって、パーティションＢＴ−Ｐｘ及びＧＳＩＴ−Ｐｙはそれぞれ、各自
のトークンバケットのトークン集合数情報の交換に関与し、そして双方の合意に基づいて
前述のようなトークン譲渡に関与しうる。
例示的トークン共有メッセージシーケンス

図２０ａ〜２０ｄは、少なくともいくつかの実施形態による、トークン共有プロトコル
の関与者間の例示的メッセージシーケンスの流れを示す図である。前述のように、トーク
ン共有プロトコルにより、１つの作業対象（例えば、テーブルパーティション）は、第二
作業対象とトークン集合数情報の交換を開始し、そして双方合意後、トークンの論理的譲
渡（すなわちトークンオブジェクトの移動は全くなしに、両作業対象のトークン集合数の
変更）が行われうる。本明細書において、集合数情報交換を開始する作業対象は「トーク
ン共有イニシエータピア」またはＴＳＩＰと称され、一方集合数情報の受信者は「トーク
ン共有パートナーピア」またはＴＳＰＰと称されうる。図２０ａ〜２０ｄに示される実施
形態において、ＴＳＩＰ２４０２とＴＳＰＰ２４０５の間で、少なくとも三種類のメッセ
ージ、トークン共有要求メッセージＴＳＲｅｑ、トークン共有受付メッセージＴＳＡｃｃ
、及びトークン共有拒否メッセージＴＳＲｅｊが流れうる。

図２０ａに描写された対話において、ＴＳＩＰ２４０２は選ばれたＴＳＰＰ２４０５へ
ＴＳＲｅｑメッセージ２４１０を送信する。ＴＳＲｅｑメッセージ２４１０は、ＴＳＩＰ
２４０２の特定バケット（例えばバーストモードバケット）のトークン集合数を示す情報
を含みうる。いくつかの実装例において、ＴＳＲｅｑメッセージはまた、ＴＳＩＰが取得
を所望する追加トークン数の指示も含みうる、または場合によっては、ＴＳＩＰがＴＳＰ
Ｐ２４０５に提供しうるトークン数の指示も含みうる。これに応じて、ＴＳＰＰ２４０５
は受付メッセージＴＳＡｃｃ２４２０を送信する。ＴＳＡｃｃメッセージ２４２０は、例
えば、ＴＳＰＰのトークン集合数、及び／またはＴＳＰＰ２４０５がＴＳＩＰ２４０２に
提供する意思のあるトークン数（またはＴＳＰＰがＴＳＩＰから受取る意思のあるトーク
ン数）を示しうる。描写された実施形態において、ＴＳＲｅｑ及びＴＳＡｃｃが交換され
た後、ＴＳＩＰ及びＴＳＰＰの両者は、双方合意譲渡に従って、それぞれのトークン集合
数を修正しうる。

図２０ｂに描写された対話において、ＴＳＩＰ２４０２は同様のＴＳＲｅｑメッセージ
４２０を送信し、しかしこの事例においてＴＳＰＰ２４０５は、提案されたトークン譲渡
を当該ＴＳＰＰは受入れられないことを示す拒否メッセージＴＳＲｅｊ２４３０をＴＳＩ
Ｐに返信する。これに応じて、ＴＳＩＰ２４０２は、自身のニーズ次第で、ある別のパー
トナーピアとトークン集合数情報交換の開始を試みうる、またはトークン共有プロトコル
の別の反復が開始されるまで待ちうる。いくつかの実装例において、ＴＳＲｅｑメッセー
ジに対するＴＳＰＰからの返答が特定の時間窓内にない場合、拒否に相当するとみなされ
うる。一実施例において、ＴＳＩＰ２４０２は、ＴＳＰＰ２４０５が要求したトークン譲
渡に対応不可能であると想定する前に、数回ＴＳＲｅｑメッセージを再送しうる。

図２０ｃにおいて、ＴＳＰＰ２４０２はＴＳＰＰ２４０５に対し、同種類の情報（例え
ば、ＴＳＰＰのトークン集合数、及び任意で、要求したトークン譲渡の性質またはサイズ
の指示）を含むＴＳＲｅｑ２４１０Ａを送信する。ＴＳＰＰ２４０５は要求を受信し、そ
して修正申込み、すなわちＴＳＲｅｑ２４１０Ａに示される内容と異なる内容の譲渡の要
求を行うことを決断する。よって、ＴＳＰＰ２４０５は、ＴＳＰＰのトークン集合数と、
ＴＳＰＰが所望するトークンの譲渡方向及び譲渡数の指示とを示す別のＴＳＲｅｑ２４１
０Ｂを返信する。ＴＳＩＰ２４０２はＴＳＲｅｑ２４１０Ａを受信し、修正譲渡案を受入
れるためにＴＳＡｃｃメッセージ２４２０を送信し、そして両サイドにおいてそれぞれの
トークン集合数が適宜調整されうる。

図２０ｄにおいて、ＴＳＰＰ２４０２はＴＳＲｅｑ２４１０Ａを送信し、そしてＴＳＰ
Ｐは、図２０ｃに示される方法と同様の方法で、自身のＴＳＲｅｑ２４１０Ｂを返信する
。この事例において、ＴＳＩＰ２４０２はＴＳＲｅｑ２４１０Ｂを拒否し、そしてＴＳＰ
Ｐ２４０５に拒否を知らせるために拒否メッセージＴＳＲｅｊ２４３０を送信する。

異なる実施形態において、図２０ａ〜２０ｄに示される種類の対話に対し、変更及び拡
張が実行されうることに留意されたい。例えば、いくつかの実施形態においては、ＴＳＡ
ｃｃメッセージが送信された後、追加の受入確認メッセージが返信されうる。一実装例に
おいて、ＴＳＲｅｊ拒否メッセージを送信する際、送信者は受信者に対し、どの他の作業
対象が拒否したトークン譲渡の良い候補者になりうるか（例えば、他の作業対象との最近
の通信に基づいて）に関するヒントを提供しうる。別の実装例において、ＴＳＩＰは、所
望する譲渡トークン数、または所望する譲渡方向を自身のＴＳＲｅｑメッセージにおいて
示し得ない。その代りＴＳＩＰのトークン集合数を示す情報のみが提供され、いずれの方
向でも譲渡は適切か否かの判定がＴＳＰＰに委ねられうる。このようなシナリオにおいて
、ＴＳＰＰによりどの譲渡も適切ではないと決定された場合、ＴＳＰＰは単に拒否メッセ
ージを送信するか、またはＴＳＲｅｑを完全に無視しうる。そしてＴＳＰＰによりトーク
ン譲渡が適切であると決定された場合、図２０ｃまたは２０ｄのように、ＴＳＰＰは自身
のＴＳＲｅｑをＴＳＩＰに対し返信しうる。いくつかの実施形態において、ＴＳＩＰは、
追加トークンが必要な場合にのみＴＳＲｅｑメッセージを送信し、自身のトークンの一部
を使用できる場合は送信しないように構成されうる。別の実施形態においては、ＴＳＩＰ
は、ＴＳＩＰが追加のトークンを必要とする、または他にトークンを譲渡する意思がある
ことを示すＴＳＲｅｑメッセージを送信しうる。
トークン共有方法

図２１は、少なくともいくつかの実施形態による、バーストモード処理のトークン共有
に対応するために行われうる処理態様を示すフロー図である。構成要素２５０１に示され
るように、通常モードバケット及びバーストモードバケットを含むトークンバケットは、
トークン共有グループの構成員として選定された、いくつかの作業対象（テーブルパーテ
ィション等）それぞれの受付制御用に構成されうる。いくつかの実施形態において、トー
クン共有グループの構成員は暗黙の存在でありうる。例えば、所定のテーブルの全てのパ
ーティションは、デフォルトでトークン共有グループの構成員とみなされうる。いくつか
の実施形態において、構成員はストレージオブジェクトの所有権に基づきうる。例えば、
特定クライアントに所有される全てのテーブルの全てのパーティションは（二次インデッ
クスに使用される任意の導出テーブルと同様に）、トークン共有グループの構成員とみな
されうる。別の実施形態においては、クライアントは、所定のトークン共有グループに含
めたい特定の作業対象を指示可能である。いくつかの実施形態において、いくつかの異な
る協働クライアントエンティティは、それぞれの作業対象をトークン共有グループに含め
ることを決定しうる。図１８の説明で前述されたように、データオブジェクトが複製され
、かつ異なるレプリカが受付制御に関する異なる役割（マスタ及びスレーブ役）に割当て
られたいくつかの実施形態において、所定のトークン共有グループは、１つの役割に対応
するレプリカのみを含み、他の役割に対応するレプリカは含まない。いくつかの実施形態
において、トークン共有は、特定の種類のトークンバケットにのみ許可されうる。例えば
、いくつかの実装例において、バーストモードバケットのみがトークン共有に関与可能で
ある、または読出しトークンバケットのみがトークン共有に関与可能である。

いくつかの実施形態において、トークン共有プロトコルが、図１７に示される方法と同
様の方法で、反復して実行されうる。所定の作業対象Ｗ１は少しの間、受信作業要求の受
付制御判断を行い、そして受付けた作業要求に対応する作業を実行する等、一般的な処理
（トークン共有と関係のない処理）を行いうる。前回の反復からある長さの時間が経った
こと、Ｗ１の１以上のバケットのトークン数が閾値レベルに達したという判断、及び／ま
たはＷ１における作業要求の拒否率が閾値レベルに達したという判断等、１以上の基準が
満たされた結果（構成要素２５０４）、トークン共有プロトコルの反復が開始されうる。

描写された実施形態において、プロトコルの反復の間、Ｗ１は実現する可能性のあるト
ークン譲渡のパートナーピア作業対象を連続的に１以上特定し、そして１以上のトークン
共有メッセージを一度に１つのパートナーに対し送信する（例えば、図２０に示される方
法と同様の方法で）。Ｗ１及びパートナーの１以上のバケット（例えば、バーストモード
バケット）のトークン集合数が比較され、そしてＷ１とパートナーの間でいくつかのトー
クンを譲渡するか否かに関する決定が、これら２つの作業対象の合意により行われうる。
よって、構成要素２５０７に示されるように、Ｗ１は、トークン共有グループの構成要素
のある作業対象を、実現する可能性のあるトークン譲渡に関して連絡を取る次のパートナ
ーＷ２として選択しうる。様々な実施形態において、どの具体的な作業対象が選ばれるべ
きかを特定するのに異なる技術が使用されうる。例えば、いくつかの実施形態において、
ゴシップコントロールが使用され、そしてパートナーはランダムに選択されうる。別の実
施形態においては、トークン共有グループの作業対象の中から一番長い時間Ｗ１が連絡を
取っていなかった特定の作業対象を選ぶ（「最長未連絡時間」手法と称されうる）等、よ
り決定論的選択技術が使用されうる、またはラウンドロビン手法が使用されうる。一実装
例において、特定の時間窓の間に、イニシエータと所定の作業対象の間でトークン譲渡が
起こっていない場合にのみ、所定の作業対象はパートナーとして選択可能でありうる。

トークン譲渡により影響を受ける可能性のあるバケット（複数可）のトークン集合数を
比較するために、パートナーピアと１以上のメッセージが交換されうる（構成要素２５１
０）。いくつかの実施形態において、メッセージ（複数可）は、トークン集合数情報の代
わりに、またはトークン集合数情報に加えて、要求トークン数、または譲渡において受入
れ可能なトークン数範囲、ならびに所望するトークン譲渡方向も示しうる。少なくとも一
実施形態においては、トークン集合数の比較は必要ではないだろう。その代りに、例えば
、パートナーピアにいくつかのトークンを提供するか、またはパートナーピアにいくつか
のトークンを要求するかに関する決定が、イニシエータピアＷ１のトークン数に基づいて
、または他の基準もしくは閾値に基づいて、行われうる。同様に、このような実施形態に
おいて、パートナーピアからの応答も、トークン数の比較なしで生成されうる。イニシエ
ータピアＷ１またはパートナーピアＷ２において１以上の基準が使用され、トークン譲渡
は合意されるべきか否か、もし合意されるのであれば、いくつのトークンが譲渡されるべ
きか（すなわち、譲渡サイズ）、そしてどちらの方向に譲渡されるべきか（譲渡方向）が
決定されうる。例えば、いくつかの実施形態において、Ｗ２等の所定の作業対象は、Ｗ２
のトークンバケット集合数がある閾値より下である場合、Ｗ２がＷ１よりも多くのトーク
ンを有していたとしても、トークンを譲渡する意向を持ち得ない。または、Ｗ２が過去の
傾向から近い将来に作業要求のバーストを予測している場合、Ｗ２はＷ１にトークンを贈
与する意向を持ちえない。いくつかの実施形態において、作業対象は、単純にトークン集
合数の違いに基づいてトークンを共有するように構成されうる。例えば、Ｗ２がＷ１より
多くのトークンを有する場合、Ｗ２はいくつかのトークンをＷ１と共有（例えば、図１７
に示されるようにトークン集合数の違いの半分を譲渡）しなければならない。少なくとも
一実施形態において、「スラッシング」動作（例えば、所定の作業対象ペア間で行き戻り
の激しい譲渡）を避けるために、所定の作業対象間の譲渡の回数（または譲渡されるトー
クン数）は、特定の率を超えては許可され得ない。譲渡サイズは、イニシエータピアとパ
ートナーピアの間の合意により決定されうる。いくつかの実施形態において、ピアのうち
の１つが少なくともＴトークンを与えてもよいという場合にのみ、トークン譲渡は実施さ
れうる。Ｔはプロトコルの設定可能なパラメータでありうる。従って、非常に小さい数の
トークンを譲渡しようとしても意味がないとみなされうる。

トークン譲渡基準が満たされた場合（構成要素２５１４にて判定）、決定された譲渡サ
イズに等しい数のトークンが、当該作業対象のうちの１つの作業対象（例えば、イニシエ
ータまたはパートナーのいずれか）の１以上のバケットに追加され、そして等しい数のト
ークンが、もう一方の作業対象の１以上のバケットの対応セットから取除かれうる（構成
要素２５１８）。ほとんどの場合、トークンはトークン集合数の多いピアからトークン集
合数の少ないピアへと譲渡されうる。しかしながら、少なくともいくつかの実施形態にお
いて、逆の方向の譲渡も許容されうる（例えば、一例示的シナリオにおいて、Ｗ１がＷ２
よりも少ないトークンを有していても、Ｗ２が予測される大きなバーストを見越したトー
クンを要求した場合、Ｗ１はＷ２にトークンを譲渡しうる）。

描写された実施形態において、トークン譲渡が合意されたか否かに関わらず、他のパー
トナー作業対象に連絡を取るか否かに関する決断が下されうる。例えば、いくつかの実施
形態において、Ｗ１はＮトークンの獲得を所望するが、しかしＷ２からはＭトークンのみ
（Ｍ＜Ｎ）が入手可能であったため、Ｗ１は追加のトークンを他のパートナーから取得す
ることを試みることを望む場合がある。いくつかの実施形態において、所定の時間内にＷ
１等の所定のイニシエータが連絡しうる異なるパートナーの数に関して、上限が設定され
うる。追加のピアと連絡を取る場合（構成要素２５２２にて決定）、例えば構成要素２５
０７に関して前述された手法と同様の手法を使って、次のパートナーが特定され、そして
構成要素２５１０、２５１４、及び２５１８に対応する処理が次のパートナーと一緒に行
われうる。

追加のパートナーと連絡を取らない場合（同様に構成要素２５２２にて決定）、例えば
イニシエータが所望する数のトークンを取得（または贈与）できた場合、トークン共有プ
ロトコルの反復は完了したとみなされうる（構成要素２５２６）。描写された実施形態に
おいて、イニシエータは、次の反復が開始されるまで通常処理を再開し（構成要素２５０
４）、次の反復が開始されると、構成要素２５０７以降に対応する処理が繰り返されうる
。
共有リソースの余剰能力を表すトークンの分配

前述のように、いくつかの実施形態において、データベースサービスにより管理される
いくつかのデータベーステーブルパーティション等、所定のネットワークアクセス可能な
サービスのいくつかの作業対象は、クライアント要求に応じて行われる作業を成し遂げる
ために、１以上の共有リソース（例えば、ディスクドライブまたは他のストレージデバイ
ス）を使用するように構成されうる。一般に、共有リソースに作業対象を割当てる場合、
サービスは、共有リソースのいずれかにより対応可能な処理能力限度が、作業対象のプロ
ビジョン能力の合計を確実に超えるようにする。バケット集合数が処理能力を表すいくつ
かの実施形態において、これは、共有リソースは追加作業要求を処理可能であっても、１
以上の作業対象は受信作業要求を受付できない（例えば、バーストモードバケットの使用
にも関わらず）というシナリオに帰着しうる。よって、少なくともいくつかの実施形態に
おいて、共有リソース（複数可）の余剰処理能力を表すトークンが、後述される公平な方
法で、作業対象間に分配されうる。図２２は、少なくともいくつかの実施形態による、リ
ソースを共有する作業対象のプロビジョン能力の合計より大きい処理能力限度を有する共
有リソースの実施例を示す図である。

図２２に描写された実施形態において、リソース３０４４は、少なくとも４つの作業対
象３００１Ａ、３００１Ｂ、３００１Ｃ、及び３００１Ｄにより共有される。これらの作
業対象は、リソース３０４４に関するリソース共有グループ３０７０の構成員と呼ばれう
る。共有リソース３０４４は、作業対象のプロビジョン能力の合計（ＰＣ１＋ＰＣ２＋Ｐ
Ｃ３＋ＰＣ４）を超える処理能力限度ＳＲＴＬ３０２０を有する。図２２の下部のグラフ
は、矢印３０５１、３０５２、３０５３、及び３０５４で示されるように、時間間隔Ｔ０
−Ｔ１における当該４つの作業対象のそれぞれの作業要求到着率を示す。示されるように
、作業対象３００１Ａの作業要求到着率Ｗ１は、時間間隔Ｔ０−Ｔ１の間、プロビジョン
能力ＰＣ１よりも低い。作業対象３００１Ｂの作業要求到着率Ｗ２は、時間間隔の大部分
の間、プロビジョン能力ＰＣ２を超えている。そしてその結果、拒否率Ｒ２で示されるよ
うに、いくつかの作業要求が拒否されている。このような拒否は、各作業対象において、
前述のようなバーストモードトークンバケットが使用されても起こりうる。作業対象３０
０１Ｃは、ゼロ到着率Ｗ３で示されるように、作業要求の受信が全くない。作業対象Ｗ４
においては、到着率Ｗ４は、時間間隔Ｔ０−Ｔ１の一部でプロビジョン能力を超えるが、
しかし拒否は起こっていない（例えば、バーストモードトークンバケットの使用の結果）
。

いくつかの実施形態において、トークン分配器３０８０は、共有リソース３０４４の未
使用処理能力を表す任意の追加トークン（すなわち、バケット補充率に基づいて既に生成
されたトークンの数を超えるトークン）が、所定の時間帯においてリソース共有グループ
の作業対象３００１間に分配されるべきか否かを決断するように構成されうる。さらに、
示された実施形態において、トークン分配器３０８０は、各作業対象に提供されるべきこ
のようなトークンの数を決定する責任を担いうる。いくつかの実施形態において、「余剰
」トークンは必要に応じて作成され、一方別の実施形態においては、共有リソースに対応
付けられたバケットが共有オブジェクトの処理能力を表すトークンを含むように構成され
、そして余剰トークンはこのようなバケットから分配されうる。

トークン分配器３０８０は、作業対象のそれぞれのプロビジョン能力、ならびに作業対
象３００１のいくつかの最近の活動の計量（すなわち、作業要求到着率）という要因も考
慮する、公平な分配ポリシーを実施しうる。少なくともいくつかの実施形態において、所
定のクライアントが特定の作業対象にアクセスするのに請求される金額は、当該作業対象
のプロビジョン能力の関数であるため、それぞれのプロビジョン能力は、分配アルゴリズ
ムに因数として含まれうる。従って、作業対象を管理するサービスは、少なくともある程
度、リソース共有グループ３０７０の構成員のプロビジョン能力に準じて、共有リソース
の未使用能力に関連する余剰トークン等の資産または特典の分配を試みうる。同時に、最
近全く作業要求を受信していない３００１Ｃ、または最近少しの作業量を受けた作業対象
３００１Ａ等の作業対象にトークンを分配することは特に有意義ではなく、このような軽
い負荷の作業対象はいかなる追加のトークンを受けても有効利用できないことから、トー
クン分配器３０８０は最近の作業量レベルを考慮しうる。いくつかの実施形態において、
様々な作業対象における最近の時間帯にわたる拒否率、今後予期される作業要求到着率等
、他の要因も考慮されうる。

少なくともいくつかの実施形態において、トークン分配器３０８０は、ある時間間隔に
おけるリソース共有グループの様々な構成員に関する到着率の計量を収集し、それからそ
の次の時間間隔においてトークンを分配するか否か、及びどのように分配するかを決定し
うる。従って、トークン分配器は、時間帯Ｔｍ（例えば、Ｔ０−Ｔ１）における作業対象
に関する到着率の比、ならびに作業対象に関するプロビジョン処理能力の比を決定しうる
。少なくともいくつかの実施形態においては、到着率及びプロビジョン処理能力のいずれ
の比も必ずしも計算される必要はなく、その代りに到着率及びプロビジョン処理能力を示
す、または到着率及びプロビジョン処理能力に関連する他の計量が使用されうる。そして
時間帯Ｔｎにおける受付制御用に作業対象間で分配されるトークンの合計数が、共有リソ
ース３０４４の処理能力限度に少なくとも一部基づいて決定されうる。例えば、一実施形
態において、当該トークン合計数は、作業対象のプロビジョン能力の合計（例えば、図２
２の実施例のＰＣ１＋ＰＣ２＋ＰＣ３＋ＰＣ４）を、共有リソースの処理能力限度（図２
２のＳＲＴＬ３０２０）から減じることにより計算されうる。トークンの合計数は、少な
くとも（ａ）それぞれの作業要求到着率の比または計量、及び（ｂ）作業対象のプロビジ
ョン能力に応じて、作業対象に分配されうる。それから追加のトークンは、作業対象のバ
ケット補充率に基づいて生成されうるトークンと共に、時間帯Ｔｎに（及び／またはその
後の時間帯に）要求受信作業対象において受付制御に使用されうる。少なくともいくつか
の実施形態において、余剰トークンは作業対象がバーストモード処理に対処するのを手伝
うことを第一目的としうるため、作業対象のバーストモードトークンバケットにのみ余剰
トークンは分配されうる。別の実施形態においては、トークンは、バーストモードトーク
ンバケットと同様に、またはバーストモードトークンバケットの代わりに、通常モードト
ークンバケットに分配されうる。いくつかの実施形態において、トークンは読出しトーク
ンバケット等の特定の種類の作業要求に関するトークンバケットに分配されうる。

作業要求到着率に加え、トークン分配器が決断する際に考慮しなければならないプロビ
ジョン能力を含む他の要因は、時間間隔ごとに変化しうることに留意されたい。例えば、
いくつかの実施形態において、クライアント（またはサービス）は任意の時点に所定の作
業対象のプロビジョン能力を変更しようと決断しうる。さらに、所定のリソースへのアク
セスを共有する作業対象の数も変化しうる。例えば、いくつかの実施形態において、スト
レージデバイスを共有するために任意の時点にテーブルパーティションが追加されうる、
または既存のパーティションが削除されうる。従って、このような実施形態において、ト
ークン分配器は、作業要求到着率の計量を取得することに加えて、様々な種類の設定変更
の経過を記録する必要がありうる。

いくつかの実施形態において、リソース共有者に分配すべきトークン数を決定する際、
いくつかの異なる共有リソースの処理能力限度が考慮されうる。図２３は、少なくともい
くつかの実施形態による、サービス（データベースサービスまたはより一般的なストレー
ジサービス等）のストレージノードにおいて作業対象により共有されうる異なる種類のリ
ソースの実施例を示す図である。示されるように、ストレージノード３１１０は、それぞ
れプロビジョン能力ＰＣ１、ＰＣ２、及びＰＣ３を有する少なくとも３つのデータオブジ
ェクトパーティション（すなわち作業対象）Ｏ１−Ｐ１、Ｏ２−Ｐ３、及びＯ３−Ｐ２が
記憶される共有ストレージデバイス３１０２を含みうる。描写された実施形態において、
共有ストレージデバイス３１０２は、処理能力限度ＳＲＴＬ３１２０Ａを有しうる。

パーティションＯ１−Ｐ１、Ｏ２−Ｐ３、またはＯ３−Ｐ２に対する作業要求は、スト
レージデバイスに加えて、ストレージノード３３１０内またはストレージノード外に配置
された別の共有リソースの使用も必要でありうる。例えば、オペレーティングシステムバ
ッファ、ソケット、Ｉノード、またはアプリケーションレベルオブジェクト（例えば、様
々な種類のロックのいずれか）等の共有データ構造３１１５は、作業処理を行うのに必要
であり、そしてこのような共有データ構造は、それぞれ各自の処理能力限度ＳＲＴＬ３１
２０Ｂを有しうる。描写された実施形態において、共有揮発性メモリ３１１６（例えば、
ストレージノードのメインメモリ）の一部は作業処理に必要であり、そしてメモリは自身
の処理能力限度３１２０Ｃを有しうる。共有処理要素３１１８（例えば、ＣＰＵまたはコ
ア）は、作業要求に対応する作業処理を行うのに使用され、そして処理要素は自身の処理
能力限度３１２０Ｄを有しうる。作業要求及び対応する応答は、処理能力限度がＳＲＴＬ
３１２０Ｅのネットワークインターフェイスカード等の共有ネットワークデバイス３１２
２の使用を要しうる。処理能力限度３１２０Ｆの共有ネットワークリンク３１３２は、作
業要求に必要でありうる。いくつかの事例においては、処理能力限度３１２０Ｇの構成デ
ータベース等の外部リソース３１３６へのアクセスもまた、少なくとも一部の作業処理に
おいて必要とされうる。

描写された実施形態において、余剰トークンが一部または全ての種類のリソースを共有
する作業対象に分配されるか否かに関して決定する際、トークン分配器は、全ての適用可
能な共有リソースのそれぞれの処理能力限度の関数を計算するように構成されうる。いく
つかの事例において、当該計算は、例えば様々なＳＲＴＬのうち最小ＳＲＴＬを特定し、
そしてこの最小値を、共有リソースの組合せに関連する有効処理能力限度として使用する
ことを伴いうる。図２３に示される異なる種類の共有リソースの全てが任意の実装例にお
いて使用されるとは限らない。いくつかの実施形態において、図２３に示されていない他
の種類の共有リソースが使用されうる。

図２４は、少なくともいくつかの実施形態による、リソースを共有する作業対象に分配
する余剰トークンの数を計算するために行われる処理の実施例を示す図である。示される
ように、トークン分配器３０８０は、有効共有リソース処理能力限度３２３０を、１以上
の共有リソースのそれぞれのＳＲＴＬ３２２０（例えば、３２２０Ａ、３２２０Ｂ、．．
．３２２０Ｎ）の関数ｆ１として計算しうる。例えば、いくつかの実装例において、有効
ＳＲＴＬとして最小ＳＲＴＬが選択され、一方別の実装例においては、ある別の関数が使
用されうる。描写された実施形態において、到着率モニタ３２２７（複数可）は、リソー
ス共有グループの様々な作業対象３２０１（例えば、３２０１Ａ、３２０１Ｂ、及び３２
０１Ｃ）における関連作業要求到着率を示す計量３２４０を特定する責任を担いうる。例
えば、一実装例において、余剰トークン分配に関する決定はＮ分毎に一度行われるため、
これに応じてＮ分の時間窓に関して計量３２４０が特定されうる。いくつかの実施形態に
おいて、到着率モニタ３２７７は、作業対象のそれぞれの受付コントローラ１８０内に取
込まれうる。

図２４に描写された実施形態において、トークン分配器３０８０は、共有リソースにお
ける余剰処理能力を表す余剰トークン３２４０の数を、有効ＳＲＴＬ３２３０及びリソー
ス共有グループの作業対象のプロビジョン能力の関数ｆ２として特定しうる。従って、一
実装例において、例えば、所定の時間窓Ｔｍにおける有効ＳＲＴＬ３２４０が毎秒Ｘ処理
であり、かつ作業対象のプロビジョン能力の合計（例えば、図２４においてＰＣ１＋ＰＣ
２＋ＰＣ３）は所定の時間窓Ｔｍにおいて毎秒Ｙ処理であったとすると、（ｍ＋１）番目
の時間窓Ｔ（ｍ＋１）において分配される余剰トークンは、Ｘ−Ｙとして計算されうる。
別の実装例においては、さらに複雑な関数ｆ２が使用されうる。少なくともいくつかのシ
ナリオにおいて、複数の共有リソースのＳＲＴＬ（ゆえに有効ＳＲＴＬ３２３０）は、時
間と共に変化しうることに留意されたい。同様に、作業対象のプロビジョン能力もまた、
例えばクライアント要求によって、時間と共に変化しうる。その結果、少なくともいくつ
かの実施形態において、余剰トークン３２４０の数もまた変動しうる。いくつかの実施形
態における少なくとも一部の時間窓に関して、例えば少なくとも一時的に共有リソースに
おいて利用可能な余剰能力がないというように、所定の時間窓中に分配される余剰トーク
ンの数がゼロでありうることに留意されたい。

分配する余剰トークン３２４０の数が特定されると、トークン分配器３０８０は次に（
もしあれば）各作業対象に提供すべきトークンの数を決定しうる。所定の作業対象の分配
余剰トークン（ＤＥＴ）３２４２（例えば、作業対象３２０１ＡにＤＥＴ３２４２Ａ、作
業対象３２０１ＢにＤＥＴ３２４２Ｂ、及び作業対象３２０１ＣにＤＥＴ３２４２Ｃ）は
、作業対象の到着率計量３２４０及び作業対象のプロビジョン能力の関数ｆ３として計算
されうる。時間窓Ｔｍにおける３つの作業対象３２０１Ａ、３２０１Ｂ、及び３２０１Ｃ
のそれぞれの到着率計量値が、Ａ１、Ａ２、及びＡ３である例示的シナリオを考察する。
一実装例において、各作業対象ｋに関して、到着率比は、Ａ＿ｒａｔｉｏ＿ｋ＝（Ａｋ／
（Ａ１＋Ａ２＋Ａ３））として特定され、かつプロビジョン能力比は、Ｐ＿ｒａｔｉｏ＿
ｋ＝（ＰＣｋ／（ＰＣ１＋ＰＣ２＋ＰＣ３））として特定されうる。さらに、（ｍ＋１）
番目の時間窓に分配する余剰トークンの合計数がＥであると仮定する。作業対象ｋに分配
される余剰トークンＤＥＴｋは、以下のように計算されうる（ａｌｐｈａは定数）：ＤＥ
Ｔｋ＝Ｅ×（（ａｌｐｈａ×Ａ＿ｒａｔｉｏ＿ｋ）＋（（１−ａｌｐｈａ）×Ｐ＿ｒａｔ
ｉｏ＿ｋ）））。当実施例において、ａｌｐｈａは、到着率とプロビジョン能力という２
つの異なる考慮要素に対し与えられる比重を表す。いくつかの実施形態において、トーク
ン分配器３０８０は、例えば到着率と対応する拒否率との実測傾向に応じて、時間と共に
ａｌｐｈａを調整しうる。少なくともいくつかの実施形態において、ｍ番目の時間窓にお
ける合計到着率が閾値を超える場合にのみ、余剰トークン３２４０は（ｍ＋１）番目の時
間窓において分配されうる。例えば各到着率が作業対象のプロビジョン能力より低い場合
は、余剰トークンは（ｍ＋１）番目の時間窓において分配され得ない。一実施形態におい
て、余剰トークンを分配する際、長時間にわたる到着率が考慮されうる。例えば、５分の
時間窓の間に所定の作業対象に分配すべきトークン数を決定する際、トークン分配器３０
８０は、当該作業対象に関して取得した前の６０分間の到着率計量を考慮しうる。いくつ
かの実施形態において、所定の時間間隔に所定の作業対象における到着率がゼロの場合（
例えば、図２の作業対象３００１Ｃは時間間隔Ｔ０−Ｔ１において遊休状態にある）、そ
の次の時間間隔において当該作業対象に対し、そのプロビジョン能力に関係なく、トーク
ンは全く分配されえない。
共有リソースの余剰能力を表すトークンの分配方法

図２５は、少なくともいくつかの実施形態による、リソースを共有する作業対象に余剰
トークンの公平分配を実施するために行われうる処理態様を示すフロー図である。構成要
素３３０１に示されるように、作業対象セットは、クライアント作業要求に対応する処理
を行う際、１以上の共有リソースを使用するように構成されうる。このような作業対象を
リソース共有グループと称しうる。各共有リソースは、各自の処理能力限度ＳＲＴＬを有
しうる。例えば前述のものと同様の１以上の通常モードバケット及び／または１以上のバ
ーストモードバケットを含むトークンバケットの各セットは、リソース共有グループの各
作業対象の受付制御用に構成されうる（構成要素３３０４）。少なくともいくつかの実施
形態において、補充率、最大トークン集合数等、トークンバケットの様々なパラメータは
、作業対象に対応付けられたそれぞれの処理能力に少なくとも一部基づきうる。

作業要求到着率計量、拒否率計量、プロビジョン能力の変更、及び／または共有リソー
スの処理能力限度の変更等、いくつかの計量が、リソース共有グループの構成員及び共有
リソース（複数可）のために収集されうる。いくつかの実施形態において、時間窓ベース
のトークン分配プロトコルが実施され、１以上の時間窓の所定セットにおいて取得された
計量は、後続の時間窓のあるセット間におけるトークン分配に使用される。描写された実
施形態において、時間窓ｔ_j+1におけるトークン分配を決定するために、時間窓ｔ_jにおい
て計量が収集されうる（構成要素３３０７）。時間窓ｔ_j+1において分配される余剰トー
クンの合計数（ＤＥＴ合計）は、共有リソース処理能力限度（ＳＲＴＬ）及び作業対象の
プロビジョン能力の関数として特定されうる（構成要素３３１０）。例えば、一実装例に
おいて、有効ＳＲＴＬが計算され（例えば、複数の共有リソースが考慮されている場合、
個々のＳＲＴＬのうち最小のＳＲＴＬ）、そしてＤＥＴ合計は、有効ＳＲＴＬから作業対
象のプロビジョン能力の合計を減じることで計算されうる。

少なくともいくつかの実装例において、特定の時間窓においてＤＥＴ合計がゼロである
、すなわち分配する余剰トークンが全くない場合もありうる。ＤＥＴ合計がゼロを超える
場合（構成要素３３１３にて判定）、例えば作業対象のそれぞれの到着率及び／またはそ
れぞれの処理能力に関連する計量の関数として、各作業対象ｋに提供されるトークンＤＥ
Ｔ−ｋの数が計算されうる（構成要素３３１６）。例えば、図２４の説明に併せて考察さ
れたように、異なる作業対象の到着率計量及びプロビジョン能力計量に比重ａｌｐｈａを
割当てる関数は、ＤＥＴ−ｋ値を取得するために、いくつかの実施形態において使用され
うる。その後、作業対象に対応付けられた１以上のバケットのトークン集合数が、決定さ
れたＤＥＴ−ｋ値に基づいて調整されうる（構成要素３３１９）。トークンが追加された
後、受付制御判断が以前のように行われうるが、少なくともいくつかの余剰トークンを受
取った作業対象においては、多くの作業量に対応する能力が向上している。いくつかの実
施形態において、余剰トークンはバーストモードトークンバケットにのみ追加され、一方
別の実施形態においては、余剰トークンは、バーストモードバケットの代わりに、または
バーストモードバケットに加えて、通常モードトークンバケットに追加されうる。少なく
ともいくつかの実施形態において、個別のトークンバケットが、読出し対書込み等の異な
る種類の作業要求用に維持されうる。このような場合、余剰トークンは、いくつかの実施
形態においては、ある種類のバケットにのみ（例えば読出しバケットにのみ、または書込
みバケットにのみ）分配され、別の実施形態においては、全ての種類のバケットに分配さ
れうる。

少なくともいくつかの実施形態において、前述の分配余剰トークン数（ＤＥＴ）を特定
するのに使用される、図２４に示される関数ｆ１、ｆ２、及びｆ３等の様々な関数及び式
は、例えばトークン分配器３０８０または管理者により、時間と共に調整されうる。例え
ば、トークン分配技術の成果は、高い到着率の時間帯における様々な作業対象の拒否率、
様々な共有リソースの使用レベル等のいくつかの計量を監視することで評価され、これに
応じて到着率計量対プロビジョン能力計量に割当てられる比重ａｌｐｈａが調整されうる
、または時間窓のサイズが調整されうる。

少なくともいくつかの実施形態において、単一または複合トークンバケットと、作業対
象間のトークン共有と、共有リソースの余剰能力の公平分配との使用を含む、前述のよう
な受付制御に関連する様々な技術は、プロバイダネットワークにより提供される複数のサ
ービスにおいて使用されうる。一部または全ての技術の組合せが、所定の実施形態におい
て使用されうる。例えば複合バーストモードトークンバケットの使用は、作業対象間のト
ークン共有及び余剰トークンの分配と組み合わせられうる。インターネット及び／または
その他のネットワークからアクセス可能な１以上のこのようなサービス（様々な種類のク
ラウドベースのストレージ、コンピューティングまたはデータベースのサービス等）を分
散したクライアントセットに提供するために、会社や公的機関等の事業体が構築したネッ
トワークは、プロバイダネットワークと称されうる。所定のプロバイダネットワークには
、プロバイダによって提供されるインフラストラクチャ及びサービスを実装、構成及び配
給するのに必要な物理及び／または仮想化コンピュータサーバ、１以上のストレージデバ
イスをそれぞれ有するストレージサーバ、ネットワーク機器等の集合といった、様々なリ
ソースプールを提供する多数のデータセンタ（異なる地域にわたって分散しうる）が含ま
れうる。その一部が異なるデータセンタまたは異なる地域においてインスタンス化または
実行されうるいくつかの異なるハードウェア及び／またはソフトウェアコンポーネントは
、様々な実施形態において、受付制御技術を実行するために集合的に使用されうる。
バーストモード処理に対するトークンベースの価格設定

いくつかの実施形態において、バーストモードに対応するようにクライアントのために
行われた作業に対して、クライアントは、通常モード処理に使用されるものとは異なる価
格設定方法に基づいて請求されうる。前述のように、いくつかの実施形態において、作業
対象間のトークン共有及び共有リソース能力を表す余剰トークンの分配はまた、バースト
モード作業量に対応するために実施され、そしてトークン共有及び／または余剰トークン
分配に対する請求額もまた、通常モード処理に対する請求額とは異なりうる。図２６は、
少なくともいくつかの実施形態による、バーストモード処理のために実行されうる価格設
定マネジャー４０８０の例示的コンポーネントを示す図である。示されるように、通常モ
ードトークンバケットセット１２０及びバーストモードトークンバケットセット１２５の
インスタンスが、作業対象に対し生成されうる。受付コントローラ１８０は、例えば様々
な実施形態に関して前述のものと同様の技術または技術の組合せを使用して、通常モード
トークンバケットセットの１以上のプロビジョン能力バケット４２０のトークン集合数、
及び／またはバーストモードトークンバケットセット１２５の１以上のバーストモードバ
ケット４２２のトークン集合数に基づいて、受信作業要求を受付けるか否か決定する責任
を担いうる。

図１６に示される実施形態において、価格設定マネジャー４０８０は、バーストモード
トークンバケットセット１２５及び／または通常モードトークンバケットセット１２０の
トークンの使用に対応付けられた１以上の価格設定ポリシーを実施するように構成されう
る。１以上のバーストモード価格設定ポリシー４００５Ｂ及び１以上の通常モード価格設
定ポリシー４００５Ａが、作動モードに依存して、１以上のバケットのトークンの消費及
び／または譲渡に関してクライアントに請求する額を決定するのに使用されうる。通常モ
ード処理に関して、例えばプロビジョン処理能力までの率のトークン使用に関しては、通
常モード価格設定ポリシー４００５Ａに従った不変すなわち固定価格が適用され、一方バ
ーストモード価格設定ポリシー４００５Ｂは、後述のように少なくともいくつかの実施形
態において、より変動的でありうる。価格設定マネジャー４０８０は、受付コントローラ
１８０からトークン集合数の変化に関する情報を収集し、及び／または受付コントローラ
１８０に受付制御判断を行う際に考慮すべき制約に関する情報を知らせるように構成され
うる（例えば、価格設定マネジャー４０８０は、バーストモード間の特定のバーストモー
ドバケット４２２のトークンの消費に対し、特定のバーストモード価格設定ポリシーに従
って、受付コントローラの判断に影響を与えうるクライアントの予算制約が適用されるこ
とを、受付コントローラに知らせうる）。

いくつかの実施形態において、価格設定マネジャー４０８０は、いくつかの異なるサブ
コンポーネントを含みうる。例えば、インターフェイスマネジャー４０２０は、一実施形
態において、クライアント入力に基づいた価格設定ポリシー選択等のクライアントとの様
々な価格設定関連対話に使用されうる、または後述の種類の様々な態様のマーケットプレ
イス取引を行うのに使用されうる、１以上のウェブページ、ＡＰＩ、ＧＵＩ（グラフィカ
ルユーザインターフェイス）、コマンドラインツール等のプログラム的インターフェイス
セットを実行する責任を担いうる。インターフェイスマネジャー４０２０はまた、いくつ
かの実装例において、価格設定マネジャー４０８０と受付コントローラ１８０の間の通信
等、ネットワークアクセス可能なサービスにおけるいくつかの種類の内部対話の責任も担
いうる。いくつかの実施形態において、トークンマーケットプレイスが確立され、これに
より一部のクライアントは、他のクライアントが買い取れる余剰トークンの可給性を宣伝
することが可能になる。少なくともいくつかのこのような実施形態において、いくつかの
種類のマーケットプレイス取引に関して、トークンの価格は不変すなわち固定であり、一
方他の取引に関しては、トークン価格は変動的に決定されうる（例えば、オークションと
同様の技術を使用する、または時間窓に基づく）。描写された実施形態において、価格設
定マネジャー４０８０のマーケットプレイスマネジャーコンポーネント４０４０は、マー
ケットプレイス取引に対応する責任を担いうる。

描写された実施形態において、１以上の計量コンポーネント４０３０は、受付コントロ
ーラ１８０からトークン使用／消費計量を収集するように構成されうる。少なくとも一実
施形態において、受付コントローラ１８０の複数のインスタンスが実行され（例えば、各
作業対象に対し１つの受付コントローラインスタンス、またはＮ作業対象に対し１つのイ
ンスタンス）、そしてこのような実施形態において計量コンポーネントは、複数の受付コ
ントローラ１８０からトークン使用データを集計しうる。いくつかの実施形態において、
トークンの消費または譲渡に関する価格は、作業要求を遂行するために使用される様々な
リソースのリソース使用レベル（例えば、プロセッサ使用レベル、ストレージデバイス使
用レベル、またはネットワーク使用レベル）に基づいて変動しうる。トークン価格設定が
リソース使用レベルの関数であるこのような実施形態において、計量コンポーネント４０
３０はまた、ネットワークアクセス可能なサービスに構築されたインフラストラクチャの
様々な部分から使用情報を収集しうる。請求額ジェネレータ４０５０は、受付コントロー
ラ（複数可）から収集された様々なトークン関連計量を分析し、そして実施されている１
つまたは複数の価格設定ポリシーに基づいて、クライアントに請求する請求額を生成する
ように構成されうる。いくつかの実施形態において、価格設定マネジャー４０８０は、例
えば価格設定ポリシー詳細及び／または請求履歴情報が保存されうる価格設定データベー
ス４０６０を含みうる。いくつかの実施形態において、価格設定データベース４０６０は
傾向分析にも使用され、例えば、以前の価格設定変更に基づいた、及び／または請求履歴
から導き出される使用パターンに基づいた、変動価格設定のコンポーネントを決定しうる
。少なくとも一実施形態によれば、価格設定マネジャー４０８０の１以上のサブコンポー
ネントは、受付コントローラ１８０内に取込まれうる。いくつかの実施形態において、価
格設定マネジャー４０８０は、１以上のコンピューティングデバイスに分散された複数の
ソフトウェア及び／またはハードウェアコンポーネントを含みうる。
トークンベース価格設定ポリシー要素

図２７は、少なくともいくつかの実施形態による、トークンベースの価格設定ポリシー
４００５の例示的要素を示す図である。いくつかの実施形態において、受付制御に使用さ
れる異なるバケットに、それぞれの価格設定ポリシーが適用されうる。すなわち、クライ
アントが請求される価格は、通常モードトークンバケットセット１２０の異なるバケット
によって、及び／またはバーストモードトークンバケットセット１２５の異なるバケット
によって、異なりうる。描写された実施形態において、バケットセットの１以上のバケッ
トに対応付けられた所定の価格設定ポリシー４００５に関して、例えばバケットにおける
１以上のトークン集合数変更処理に対するクライアント請求額を決定するために価格設定
ポリシーが使用される条件を示す、１以上の適用基準４１０５が指定されうる。単純な一
実装例において、例えば、特定の価格設定ポリシー４００５がバーストモードバケット４
２２から消費される全てのトークンに適用されうる。このようなシナリオにおいて、適用
基準４１０５は、「消費される各トークンに対しこの価格設定ポリシーを適用する」とい
う論理的同値を単純に示しうる。いくつかの実施形態においては、ある他の１つまたは複
数のバケットのトークン集合数に基づいた基準（例えば「バケットＢ２のトークン集合数
がＢ２低−Ｂ２高の範囲内にある場合にのみ、バケットＢ１のトークン消費に対しこの価
格設定を適用する」という論理的同値）、クライアントの予算に基づいた基準（例えば「
Ｃ１の残りのバーストモードトークンの予算が価格Ａを上回る場合にのみ、Ｃ１のバケッ
トＢ１に対しこの価格設定を適用する」という論理的同値）、時間窓に基づいた基準（例
えば「平日の午前１時から午前６時までの時間帯においてバケットＢ１から消費されるト
ークンに対しこの価格設定を適用する」）等、より複雑な適用基準４１０５が指定されう
る。いくつかの事例において、適用基準は使用されるバケットの数及び種類に依存する。
例えば、一部の価格設定ポリシーは、複合トークンバケットがバーストモード受付制御に
も使用されている場合にのみ、所定の共有リソース能力バーストモードバケットＢ１に対
して適用されうる。

一般的にトークン集合数の変更（例えば、トークン消費または譲渡）に対応付けられた
価格設定は、不変価格設定コンポーネント４１０８（例えば、特定の時間帯において特定
の料金でバーストモードトークンを特定数まで消費するための先払料金）と、変動価格設
定コンポーネント４１１１（例えば、平日の異なる時間窓によって変動しうる料金、また
は需要と供給に基づいて変動しうる料金）とを含みうる。描写された実施形態において、
一部の価格設定ポリシーは、不変及び変動価格設定コンポーネントの両方を含み、一方別
のポリシーは、不変コンポーネントのみ、または変動コンポーネントのみを含みうる。少
なくともいくつかの実施形態において、ある特定の種類のトークン譲渡または売買に関す
る変動価格設定は、オークションを利用して実行されうる。少なくとも一実施形態におい
て、少なくとも一部のトークンバケットの価格設定は、需要と供給に基づいて変わりうる
。例えば、入札時に特定のクライアントの付け値が現在のスポット価格以上である場合に
のみ、当該クライアントにトークンが供給されうるという、バーストモードトークンの「
スポット」価格設定ポリシーが実施されうる。

いくつかの実施形態において、複数のクライアントが所定のトークン取引に関与しうる
。例えば、価格設定マネジャー４０８０がトークンマーケットプレイスを実施する実施形
態において、クライアントＣ１は、クライアントＣ１の所有するいくつかのトークン（例
えば、バーストモード処理に使用可能なトークン）が他のクライアントに販売可能である
ことを示したい場合がある。価格設定マネジャー４０８０は、トークンの可給性を宣伝し
（またはトークンを購入する可能性のある候補者の特定クライアントに知らせ）、そして
別のクライアントＣ２がＣ１からトークンを購入しうる。このようなシナリオにおいて、
クライアント間の支払振替は、価格設定マネジャー４０８０により、例えば描写された実
施形態においてはクライアント間支払振替ポリシー４１１７（特定種類のトークンバケッ
ト用の、クライアントＡの価格設定ポリシーに、クライアントＣ２の価格設定ポリシーに
、または両クライアントポリシーに含まれうる）に従って、簡易化されうる。クライアン
ト間支払振替ポリシー４１１７は、例えば、買い手または売り手のいずれかが売買に関し
て負いうるサービス料、及び／またはクライアント間の支払いが処理されるスケジュール
（例えば、１つのスケジュールに従って週に一度蓄積された支払が決済すなわち振替えら
れうる）を示しうる。いくつかの実施形態において、トークンは価格設定目的で、通貨の
論理的同値として使用されうる（少なくとも一時的に）。例えば、クライアントＣ１はサ
ービスにＮトークンの借りがあり（または別のクライアントにＮトークンの借りがあり）
、そして当該負債は実際の通貨を使用して、または代替トークンを使用して返済されうる
（例えば、Ｎトークンの負債は、Ｎ＋ｋトークンを振替えることで返済されうる。この時
ｋトークンは負債の「利息」を表し、負債者が当該負債を返済するのにかかった時間に基
づいて計算される）。異なるクライアントが所有する作業対象も含む多数の作業対象によ
ってトークンが共有されるいくつかの実施形態において、クライアント間支払振替ポリシ
ーはまた、図１７に示された例示的トークン共有プロトコル等の前述のものと同様のトー
クン共有技術にも適用可能でありうる。

少なくともいくつかの実施形態において、受付コントローラ１８０は、少なくとも一部
の種類のトークンバケットに関して、将来の受付制御判断の確実な保証を何も提供できな
い。例えば、前述のように、バーストモード受付制御に関して「ベストエフォート」手法
が使用されるが、一般に作業要求は通常モード間よりもバーストモード間において拒否さ
れる確率が高い。いくつかの実施形態において、価格設定ポリシー４００５は、価格設定
ポリシーに従って取得または消費されたトークンに適用されうる１以上のベストエフォー
ト制約４１２０の指示を含みうる。一例を挙げれば、受付コントローラのベストエフォー
トにもかかわらず、かつバーストモードトークンをいくつか取得するためにクライアント
が負った料金にもかかわらず、例えばバーストモードの間に作業対象が共有物理または論
理リソースの処理能力限度に達した場合、作業要求は拒否または延期されなければならな
い可能性があることを、制約４１２０はクライアントに知らせうる。よって、ベストエフ
ォート制約４１２０は、一部の（一般に珍しい）状況において、クライアントのトークン
購入は、クライアントの全作業要求に対する高い受付率または高品質の応答を確保するの
に十分でない可能性があることを示す、クライアントへのリマインダーとして役立ちうる
。いくつかの実施形態において、少なくとも一部のクライアントは、価格設定ポリシー４
００５において示される割引ポリシー４１２４に従って割引を提案されうる。例えば、ク
ライアントに責任のない様々な制約または原因のいずれかにより、クライアントが購入済
バーストモードトークンのＸ％以下しか使えない場合、一部または全ての購入済バースト
モードトークンがクライアントに返済されうる。一実施形態においては、数量割引（例え
ば、購入済みトークンの総数に基づいた払戻し）に対応可能であり、そして割引ポリシー
４１２４がこのような割引の料金を示しうる。様々な実施形態において、図２７に示され
る一部の種類の要素は、所定の価格設定ポリシー４００５に含まれず、及び／または図２
７に示されない他の要素が含まれうる。
トークン価格設定方法

図２８は、少なくともいくつかの実施形態による、バーストモード処理の請求額を決定
するために行われうる処理態様を示すフロー図である。構成要素４２０１に示されるよう
に、描写された実施形態において、前述の種類の１以上のモード（通常モード及びバース
トモード等）で作動するように構成された１以上の作業対象における作業量管理のために
、いくつかのトークンバケットのインスタンスが生成されうる。作業対象において作業要
求を実行対象として受付けるか否かに関する判断は、１以上のバケットのトークン集合数
に基づいて行われ、そして作業要求を受付ける判断は、例えば１以上のバケットのいくつ
かのトークンの消費を伴いうる。構成要素４２０４に示されるように、一部または全ての
バケットのトークン集合数の変更に至る処理に適用する１以上の価格設定ポリシーは、例
えばクライアントのポリシー選択要求に価格設定マネジャー４０８０が応じることによっ
て、またはネットワークアクセス可能なサービスの内部構成パラメータに基づいて、決定
されうる。例えば、価格設定ポリシーはクライアントに、バーストモードの間のバケット
Ｂ１のトークン消費に関して、１つのバケットＢ１から別のバケットＢ２へのトークン譲
渡に関して、バケット補充率及び／または最大トークン集合数限度の短期的または長期的
変更に関して、またはこれらの種類の変更のある組合せに関して、請求される額を示しう
る。一部の価格設定ポリシーはバーストモードの間にのみ適用され、一方他の価格設定ポ
リシーは通常モードの間にのみ適用されうる、または将来のバーストモードに対する備え
に適用されうる（前述のように通常モードバケットからバーストモードバケットへの未使
用トークンの譲渡、作業対象間のトークン共有、または余剰トークンの分配等）。少なく
とも一実施形態において、通常モード価格設定ポリシーは、プロビジョン処理能力を上限
とする作業要求を受付けるのに消費されうるプロビジョン能力バケット４２０のトークン
に対する定額料金を含みうる。このような料金は、プロビジョン能力バケットから使用さ
れる実際のトークン数にかかわらず、変化し得ない。いくつかの実施形態において、一部
の価格設定ポリシーは、例えば価格設定マネジャー４０８０において、または価格設定マ
ネジャー４０８０により実行されるプログラム的インターフェイスを使用して対応されう
るトークンマーケットプレイスを利用して行われる取引に対し適用可能でありうる。

各価格設定ポリシーは、例えば、ポリシーに対する１以上の適用基準（ポリシーが適用
されるバーストモード等の処理モード（複数可）と、ポリシーが適用されるのに満たされ
なければならない他の特定条件とを指定しうる）と、トークン集合数の変更に至る処理に
対応付けられた１以上の不変もしくは変動価格設定コンポーネントまたは価格設定額とを
含みうる。いくつかの実装例において、絶対価格設定額の代わりに、例えば要因の組合せ
による関数の形の価格設定式が、価格設定ポリシーにおいて指定されうる。いくつかの実
施形態において、価格設定ポリシーは、クライアント間支払振替ポリシー、割引ポリシー
等、図２７で示されたものと同様の１以上の追加要素を含みうる。価格設定マネジャー４
０８０は、価格設定ポリシーに対応付けられた様々なバケットにおけるトークン集合数の
変更と、トークン集合数のどの変更一式に対してどの価格設定ポリシーが適用されたかを
示す情報とを、様々な時間帯において収集、集約、記録するように構成されうる（構成要
素４２０８）。異なる実施形態において、トークン集合数の変更に関するデータ集合に対
し、様々な集約技術のいずれかが使用されうる。例えば、いくつかの実施形態において、
所定のバケットのトークン集合数に関わる全ての変更はそれぞれ記録され、一方別の実施
形態においては、トークン数は定期的にサンプリングされうる、または予定された時間間
隔で収集されうる。いくつかの実装例において、クライアントが全く課金されない一部の
種類のトークン集合数変更がありうることに留意されたい。例えば、少なくとも一部のク
ライアントに対し、一部のトークン処理は無料でありうる。

いくつかの実施形態において、ある時間間隔においてトークン集合数に変更がない場合
、クライアントはバケットのトークンに対して課金されず、一方別の実施形態においては
、クライアントは少なくともある種のトークンに対し、それらが未使用で残ったとしても
（例えば、所定の時間間隔において所定のバケットのトークン集合数が変化しなかったと
しても）課金されうる。一実施形態において、請求額はトークンの異なるカテゴリによっ
て変動しうる。例えば、通常モードの間、またはバーストモードの間、または通常及びバ
ーストの両モードの間、書込みは読出しより料金が高くありうる、またはその逆も同様で
ありうる。描写された実施形態において、１以上のバケットのトークン集合数変更の記録
に少なくとも一部、かつ１つまたは複数の価格設定ポリシーに少なくとも一部基づいて、
クライアントに対し請求額が生成されうる（構成要素４２１２）。様々な実施形態におい
て、前述のトークンベースの受付制御の一部または全ての異なる態様に対し、例えば複数
のカテゴリのバーストに対応する複合トークンバケットの使用に適用されるポリシー、優
先度ベースカテゴリのトークンバケットに適用されるポリシー等を含む、価格設定ポリシ
ーが選択されうることに留意されたい。

図２９は、少なくともいくつかの実施形態による、条件付きバーストモード価格設定に
関連する処理態様を示すフロー図である。描写された実施形態において、バーストモード
バケットセット１２５は、ローカルバースト限度バケット６０４及び１以上の共有リソー
ス能力バケット６０６を含む複数のバケットを備え、そして異なる価格設定ポリシーが複
数のバーストモードバケットのうちの１つのバケットのトークン集合数に、別のバースト
モードバケットの集合数に基づいて、適用されうる。作業対象に対する次の作業要求が受
信される（構成要素４３０１）。作業対象がバーストモードで作動していない場合（構成
要素４３０４にて検出）、例えば１以上の通常モードトークンバケットのトークン集合数
に基づいて、通常モード価格設定ポリシーを使用して作業要求に適用される価格設定が決
定される（構成要素４３０８）。例えば、いくつかの実施形態において、前述のように通
常モードの間、作業対象のプロビジョン処理能力に比例する定額先払料金が、プロビジョ
ン処理能力を作業要求到着率が超えない限り、消費される実際のトークン数に関係なく、
クライアントに課金されうる。

同様に構成要素４３０４で検出されるように、作業対象がバーストモードで作動してい
る場合、描写された実施形態において、少なくとも１つの共有リソース能力バケット６０
６のトークン集合数が特定されうる。１つまたは複数の共有リソース能力バケットが、実
施されている消費ポリシーに基づいて十分な数のトークンを含む場合（構成要素４３１２
）、作業対象に適用可能なローカルバースト限度バケット６０４のトークン集合数が次に
確認されうる。描写された実施形態において、ローカルバースト限度バケット６０４の集
合数は、例えば、作業対象は孤立しているとみなした時の（共有リソースを考慮しない）
作業対象に割当てられた処理能力限度に基づいた利用可能処理能力を示しうる。描写され
た実施形態において、作業要求を実行対象として受付けるための価格設定は、共有リソー
ス能力バケット（複数可）及びローカルバースト限度バケットの両方の集合数に依存しう
る。共有リソース能力バケット（複数可）及びローカルバースト限度バケットの両方が、
それぞれの消費ポリシーに基づいて十分なトークンを含む場合（構成要素４３１２及び４
３１６にて判定）、作業要求は受付けられ、１以上のトークンが両方の種類のバケットか
ら消費され、そして第一バーストモード価格設定ポリシーが適用されうる（構成要素４３
２０）。描写された実施形態において、１つまたは複数の共有リソース能力バケットは十
分なトークンを含むが、ローカルバースト限度バケットは含まない場合、作業要求はなお
実行対象として受付けられうる。１以上のトークンが共有リソース能力バケット（複数可
）から消費され、そして第二バーストモード価格設定ポリシーが適用されうる（構成要素
４３２４）。共有リソース能力バケット（複数可）及びローカルバースト限度バケットの
両方が十分なトークンを含まない場合、作業要求は拒否、再試行、または延期されうる（
構成要素４３２８）。受付制御判断が行われ、受付け（構成要素４３２０または４３２４
）または拒否（構成要素４３２８）のいずれかに結果が決まった後、次の受信済作業要求
が、例えば構成要素４３０１以降に対応する処理を実行することで対応されうる。図２９
に示される条件付きバーストモード価格設定手法は、例えば、ローカルバースト限度バケ
ットの最大集合数は控えめに設定され、一方で共有リソース能力バケット（複数可）にお
いてその利用可能処理能力が表される共有リソースは、少なくとも一部の時間帯において
、ローカルバースト限度バケットのみを使用した場合に対応可能な作業要求到着率よりも
高い作業要求到着率に対応可能でありうる環境において使用されうる。共有リソースを使
用するいくつかの作業対象の作業量が時間と共に大幅に変動する場合、ローカルバースト
限度バケットが空であっても、短期バーストに対応するのに十分な能力が共有リソースに
おいて利用可能になる時間帯がありえ、そして少なくともこのようなシナリオにおいては
第二価格設定ポリシーが役立ちうる。図２９に示されるものと同様の価格設定技術はまた
、前述の共有リソースの余剰能力を表すトークンの公平分配の技術と共に使用されうる。

図３０は、少なくともいくつかの実施形態による、価格設定ポリシーのクライアント選
択を可能にするために実行されうる処理態様を示すフロー図である。構成要素４４０１に
示されるように、ウェブページ、ウェブサイト、またはＡＰＩ等の１以上のプログラム的
インターフェイスが実行され、これによりクライアントは複数の対応価格設定ポリシーの
中から選択することができる。少なくともいくつかの実施形態において、価格設定マネジ
ャー４０８０のインターフェイスマネジャーサブコンポーネントが、当該インターフェイ
スの実行の責任を担いうる。いくつかの実施形態において、複数の価格設定ポリシーがバ
ーストモード処理において利用可能であり、一方別の実施形態においては、複数のポリシ
ーが通常モード及びバーストモードの両処理において対応されうる。少なくともいくつか
の実施形態において、特定の種類のパラメータ変更（補充率または最大トークン集合数限
度の短期的または長期的変更等）に特定的に適用する価格設定ポリシーは、インターフェ
イスを介して選択可能でありうる。利用可能な価格設定ポリシーの表示、または記入もし
くはパラメータ化可能なポリシーテンプレートが、クライアントに提供されうる（構成要
素４４０４）。例えば、一実装例において、異なる価格設定ポリシーの様々な要素（図２
７に示される要素等）に関する詳細は、ウェブサイトを介して提供されうる。

作業量のニーズ及び／または予算に基づいて、所定のクライアントは使用する選択ポリ
シー及び／またはパラメータを、例えば実行インターフェイスのうちの１つを使用して提
出した価格設定ポリシー要求を介して、指示しうる（構成要素４４０８）。このような要
求に応じて、価格設定マネジャー４０８０は、クライアントのために選択価格設定ポリシ
ー及び／またはパラメータの実行を開始しうる（構成要素４４１２）。少なくともいくつ
かの実装例において、例えば、価格設定マネジャー４０８０は、価格設定ポリシーの使用
を開始するために、受付コントローラ１８０と通信しうる。

図３１は、少なくともいくつかの実施形態による、バーストモードトークンのマーケッ
トプレイスを有効にするために実行されうる処理態様を示すフロー図である。描写された
実施形態において、構成要素４５０１に示されるように、バーストモード受付制御及び／
または通常モード受付制御に使用可能なトークンの宣伝、販売、購入、共有、または譲渡
に関わる様々な種類の取引に対応するために、ウェブページ及び／またはＡＰＩ等の１以
上のプログラム的インターフェイスが実行されうる（例えばインターフェイスマネジャー
４０２０により）。マーケットプレイスマネジャー４０４０（例えば、価格設定マネジャ
ーのサブコンポーネント）は、実行インターフェイスを介して１以上のクライアントから
、トークンの販売、オークション、または購入の提案等、トークン取引提案の通知を受信
し（構成要素４５０４）、そして当該提案を他のクライアントに公表または宣伝しうる。
少なくともいくつかの実施形態において、価格設定マネジャー及び／または受付コントロ
ーラは、トークンが必要なクライアント（例えば、最近の時間間隔において、作業要求に
関して通常の拒否率よりも高い拒否率を経験したクライアント）を認識しており、そして
このようなトークン消費候補者とトークン提案を合わせることが可能でありうる。

マーケットプレイスマネジャー４０４０は、固定価格またはオークションの落札に基づ
いた、あるトークンセットの販売または譲渡に関わる取引等の取引完了の通知を、１以上
のインターフェイスを介して受信しうる（構成要素４５０８）。これに応じて、描写され
た実施形態において、マーケットプレイスマネジャー４０４０は、例えば１以上の譲渡元
バケットのトークン数を削減し、及び／または１以上の他のバケットのトークン数を増加
させることによって、影響を受けたバケット（複数可）のトークン集合数を変更しうる（
構成要素４５１２）。クライアントに課金される請求額（例えば所定のマーケットプレイ
ス取引の買い手クライアント及び売り手クライアントの両方にかかるサービス料を含みう
る）は、取引の詳細及び１つまたは複数の適用価格設定ポリシー４００５に従って生成さ
れうる（構成要素４５１６）。

少なくともいくつかの実施形態において、前述のように、データベーステーブル等の作
業対象は複数の論理パーティションに分割され、そして受付制御は、各パーティションで
使用されているそれぞれの受付制御パラメータセット及びトークンバケットにより論理パ
ーティションレベルにおいて行われうる。例えば、１テラバイトのデータを含む大きなデ
ータベーステーブルは、各自の受付制御用トークンバケットセットを有する、各２５０メ
ガバイトの４つの論理パーティションで構成されうる。いくつかの実装例において、同様
に前述のように、例えばデータ耐久性のため及び／または高い可用性のために、各論理パ
ーティションの多数の論理レプリカが保持されうる。いくつかのシナリオにおいて、クラ
イアント作業量は必ずしもパーティション間に均一に分散し得ない。その結果、所定の時
点に、ある使用頻度が高いパーティションにおけるトークンバケット（バーストモードバ
ケット４２２等）の利用可能トークン数は、他の使用頻度の低いパーティションにおける
対応するトークンバケットの利用可能トークン数より大幅に少ない可能性がある。従って
、非常に不均等な作業量により起こりうる作業要求拒否の数を減らすために、異なるパー
ティションの受付コントローラ１８０（複数可）は、いくつかの実施形態において、図１
６〜図２１を参照して説明されたようなトークン共有プロトコルを使用し、そしてパーテ
ィションを所有または使用するクライアントは、パーティション間トークン共有に関する
価格設定ポリシーに従って、トークン共有に対し課金されうる。図３２は、少なくともい
くつかの実施形態による、作業対象の異なるパーティション間のトークン譲渡に対して価
格設定を行うために実行されうる処理態様を示すフロー図である。

図３２の構成要素４６０１に示されるように、作業対象（データベーステーブルまたは
論理ボリューム等）は、各自の通常モードバケットセット及び各自のバーストモードバケ
ットセット等、それぞれが各自の受付制御用トークンバケットを有するパーティションの
集合として構成されうる。従って、描写された実施形態において、各パーティションは独
立的に設定可能な受付制御パラメータを有する個別の作業対象としてみなされうる。価格
設定マネジャー４０８０は、異なるパーティションのバケット間のトークン譲渡に適用す
る価格設定ポリシーを決定するように構成されうる（構成要素４６０４）。例えば、Ｎト
ークンをパーティションＰ１のバーストモードトークンバケットＢＢ１から、パーティシ
ョンＰ２のバーストモードトークンバケットＢＢ２へ譲渡するための価格設定ポリシーは
、クライアントの入力に基づいて、または設定可能なパラメータに基づいて特定されうる
。このようなトークン譲渡は、トークン集合数が閾値を下回ったことの検出、前回パーテ
ィション間のトークン譲渡の必要性が検討されてから特定の時間が経ったことの検出、作
業要求に対する閾値拒否率の検出等、異なる実施形態において様々な種類のトリガーイベ
ントの発生に基づいて実行されうる。構成要素４６０８に示されるように、パーティショ
ン間のトークン譲渡を試みるべきであるか否かを調べるトリガーイベントが検出されうる
。

どれか１つのパーティションのトークン数が閾値Ｔ１を下回っているかを調べるために
、サブセットまたは全てのパーティションのトークン集合数が調査されうる。描写された
実施形態において、トークン数が閾値Ｔ１を下回るパーティション「ｐ」が見つかり（構
成要素４６１２にて判定）、かつ別のパーティション「ｑ」のトークン集合数が閾値Ｔ２
を上回ることが判明した（構成要素４６１６にて判定）場合、いくつかのトークンがパー
ティション「ｑ」からパーティション「ｐ」に譲渡されうる（構成要素４６２０）。いく
つかの事例において、閾値Ｔ１を下回るトークン数を有する複数のパーティションが見つ
かり、及び／またはＴ２を上回るトークン集合数を有する複数のパーティションが見つか
った場合、多数の譲渡元及び譲渡先バケットペアの間でトークン譲渡が開始されうる。例
えば、一実装例において、パーティションｐ、ｑ、ｒ、ｓの現在のトークン集合数に関す
る所定の調査において、パーティションｐ及びｒは閾値Ｔ１を下回るトークン集合数を有
していることがわかり、一方パーティションｑはＴ２＋Ｎトークンを有していることがわ
かり、そしてパーティションｓは譲渡するのに十分なトークンを有していない場合、Ｎ／
２トークンがパーティションｐ及びｒに追加され、パーティションｑはＮトークン分削減
されうる。１つまたは複数の譲渡の記録が保持され、そして最終的に譲渡に関してクライ
アントに請求する請求額が、記録（複数可）及び価格設定ポリシーに基づいて生成されう
る（構成要素４６２４）。パーティション間でトークンを譲渡するか否かに関する判断が
行われた後（肯定的判断、否定的判断のいずれでも）、次のトリガーイベント及び／また
は異なる譲渡元と譲渡先パーティションペアに対し、構成要素４６０８以降に対応する処
理が繰り返されうる。

前述のように、少なくともいくつかの実施形態において、受付制御に使用されるトーク
ンバケットはそれぞれ、補充率、最大トークン集合数等の設定可能パラメータセットを有
しうる。いくつかの実施形態において、クライアントは、所定のトークンバケットに対応
付けられた１以上のパラメータの短期間または長期間の変更を所望しうる。例えば、クラ
イアントは、翌日または翌週に非常に高い作業要求バーストが不定期に起こりうることを
予測可能であり、そしてこのようなバーストに対応するために余分に支払う意思を有しう
る。従って、いくつかの実施形態において、トークンバケット補充率の変更及び／または
他の構成設定の変更を行うための価格設定ポリシーが対応されうる。図３３は、少なくと
もいくつかの実施形態による、トークンバケットの構成設定の変更に対して価格設定を行
うために実行されうる処理態様を示すフロー図である。構成要素４７０１に示されるよう
に、初期ポリシー及びパラメータは、例えば作業対象が初期化される時に、通常モードバ
ケット及びバーストモードバケットを含む１以上のトークンバケットに対し設定されうる
。バケット（複数可）のパラメータ変更に対する価格設定ポリシーが特定され（構成要素
４７０４）、クライアントはパラメータ変更に関連する費用を知らされうる。例えば特定
の時間窓において補充率または最大トークン集合数を変更するといった、１つまたは複数
の特定バケットに対する１以上のパラメータの変更要求が受信されうる（構成要素４７０
８）。当該要求に基づいてパラメータが変更され（構成要素４７１２）（例えば、当該時
間窓の間はパラメータに対し新しい値が使用され、当該時間窓が終了すると初期値が再度
適用されうる）、そして実行されたパラメータ変更及び価格設定ポリシーに基づいて、最
終的に請求額が生成されうる（構成要素４７１６）。

様々な実施形態において、図１０〜１５、図２１、図２５、及び図２８〜３３のフロー
チャートに示される処理は、示されるものとは異なった順序で実行可能、及び／または並
列して実行可能であることに留意されたい。いくつかの実施形態において、本明細書にお
いて示される１以上の処理は省略可能であり、及び／または図示されていない他の処理も
実行可能である。
活用事例

トークンベース受付制御及びバーストモード処理の価格設定に関する前述の技術は、様
々な異なるシナリオにおいて役立ちうる。例えば、いくつかのデータベース環境において
、クライアントは、非常に大きい（テラバイトまたはペタバイトレベルの）テーブルまた
はテーブルセットを有し、そして当該テーブルにおいて一部の時間帯にのみ（他の時間帯
ではなく）非常に高い入出力率を命令しうる。同様に、他のネットワークアクセス可能な
サービス（汎用ストレージサービス、コンピューティング集約サービス等）もまた、高い
作業量の一時的期間を経験しうる。一般に、データベーステーブル等の所定の作業対象に
対する作業量の経時的な変化を予測することは非常に難しいだろう。クライアントは時々
または稀にしか起こらない高い作業量レベルに対し支払いたくないだろう。同時に、サー
ビスのプロバイダは非常に高いレベルの作業要求を長い時間にわたって対処するのに十分
なリソースを備えておきたくないかもしれないが、しかし多数の要求を拒否することなく
、または顧客要求の応答時間を大幅に増加することなく、到着率における一時的バースト
に可能な限り対応したいだろう。本明細書で説明される種類のトークンベース受付制御手
法を使用することで、プロバイダはリソースを無駄にせずに、要求到着率におけるバース
トの大部分（全てではなくとも）に対応可能でありうる。トークン共有技術及び共有リソ
ースの余剰能力の公平分配の使用はまた、不均等に分散した作業要求到着率にクライアン
トが対処することを支援しうる。

バーストモード処理及び／または通常モード処理に対する柔軟な（例えばクライアント
選択の）価格設定の対応は、様々な種類の不均一な作業量に対応する間もクライアントの
予算優先性が守られるという、クライアントの信頼感を高めうる。トークンマーケットプ
レイスにおいてトークンを購入及び販売できることは、クライアントが時に不正確な作業
量予測をしても、このような不正確さに対するペナルティは最小化できるという可能性を
高めうる
例示的コンピュータシステム

少なくともいくつかの実施形態において、トークンベース受付コントローラ、トークン
分配器、価格設定マネジャー、及び／または様々な種類の作業対象を実行する技術を含む
、本明細書で説明される１以上の技術の一部または全てを実施するサーバは、１以上のコ
ンピュータアクセス可能な媒体を含む、またはこのような媒体にアクセスするように構成
された汎用コンピュータシステムを含みうる。図３４は、このような汎用コンピューティ
ングデバイス８０００を示す。図示された実施形態において、コンピューティングデバイ
ス８０００は、入出力インターフェイス８０３０を介してシステムメモリ８０２０に接続
された１以上のプロセッサ８０１０を含む。コンピューティングデバイス８０００はさら
に、入出力インターフェイス８０３０に接続されたネットワークインターフェイス８０４
０を含む。

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

システムメモリ８０２０は命令と、プロセッサ８０１０（複数可）がアクセス可能なデ
ータを記憶するように構成されうる。様々な実施形態において、システムメモリ８０２０
は、静的ランダムアクセスメモリ（ＳＲＡＭ）、同期式動的ＲＡＭ（ＳＤＲＡＭ）、不揮
発性／フラッシュメモリ、またはその他の種類のメモリ等、任意の好適なメモリ技術を使
用して実行されうる。図示された実施形態において、前述の方法、技術及びデータ等、１
以上の所望する機能を実行するプログラム命令及びデータは、システムメモリ８０２０に
おいてコード８０２５及びデータ８０２６として記憶されることが示される。

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

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

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

前述の内容は以下の項目を参照することで、より理解されるだろう。
（第１項）
１以上のコンピューティングデバイスを備えるシステムであって、コンピューティング
デバイスは、
第一作業対象及び第二作業対象が、実行対象として受付けられた作業要求応じて共有リ
ソースを使用するように設定し、第一作業対象は第一プロビジョン処理能力率を有し、第
二作業対象は第二プロビジョン処理能力率を有し、そして共有リソースは処理能力限度を
有し、
第一作業対象及び第二作業対象が、作業要求の受付制御用のそれぞれのトークンバケッ
トセットを有するように設定し、各トークンバケットセットは作業要求を実行対象として
受付けるか否かを決定するのに使用されるトークン集合を有する１以上のバケットを備え
、
（ａ）第一時間間隔において第一及び第二作業対象が作業要求を受信した相対率を示す
到着率比と、（ｂ）第一及び第二プロビジョン処理能力率に少なくとも一部基づいたプロ
ビジョン処理能力比と、（ｃ）第二時間間隔において受付制御用の第一及び第二作業対象
のバケットセット間で分配するトークンの合計数とを特定し、合計数は共有リソースの処
理能力限度に少なくとも一部基づき、
到着率比及びプロビジョン処理能力比に少なくとも一部基づいて、第一作業対象の特定
バケットに、合計数を超えない特定数のトークンを追加し、
第一作業対象の特定バケットのトークン集合数に少なくとも一部基づいて、第二時間間
隔において、第一作業対象に対する特定の作業要求を実行対象として受付ける
ように構成された、システム。
（第２項）
トークンの合計数は、共有リソースの処理能力限度から第一及び第二プロビジョン処理
能力率の合計を減算することで、少なくとも一部決定される、第１項に記載のシステム。
（第３項）
第一作業対象のバケットセットは、作業要求到着率が閾値より低い通常モード作動中に
受付制御のためにトークン集合数が調べられる通常モードバケットと、作業要求到着率が
閾値以上のバーストモード作動中に受付制御のためにトークン集合数が調べられるバース
トモードバケットとを備え、特定バケットはバーストモードバケットを含む、第１項に記
載のシステム。
（第４項）
第一作業対象はネットワークアクセス可能なサービスにより管理される第一ストレージ
オブジェクトの少なくとも一部を備え、第二作業対象はネットワークアクセス可能なサー
ビスにより管理される第二ストレージオブジェクトの少なくとも一部を備え、共有リソー
スは第一作業対象及び第二作業対象が記憶されるストレージデバイスを備える、第１項に
記載のシステム。
（第５項）
特定の作業要求は（ａ）読出し処理、または（ｂ）書込み処理を１以上含む、第１項に
記載のシステム。
（第６項）
１以上のコンピュータデバイスにより、
第一作業対象及び第二作業対象が、実行対象として受付けられた作業要求応じて共有リ
ソースを使用するように設定し、第一作業対象は第一プロビジョン処理能力率を有し、第
二作業対象は第二プロビジョン処理能力率を有し、
第一作業対象及び第二作業対象が、作業要求の受付制御用のそれぞれのトークンバケッ
トセットを有するように設定し、各トークンバケットセットは作業要求を実行対象として
受付けるか否かを決定するのに使用されるトークン集合を有する１以上のバケットを備え
、
（ａ）第一時間間隔における第一及び第二作業対象の作業要求到着率を示す第一計量と
、（ｂ）第一及び第二プロビジョン処理能力率に関連する第二計量とを特定し、
第一計量、第二計量、及び共有リソースの処理能力限度に少なくとも一部基づいて、第
一作業対象の特定バケットに特定数のトークンを追加し、
第一作業対象の特定バケットのトークン集合数に少なくとも一部基づいて、第二時間間
隔において、第一作業対象に対する特定の作業要求を実行対象として受付ける
ことを含む方法。
（第７項）
１以上のコンピューティングデバイスにより、
共有リソースの処理能力限度に少なくとも一部基づいて、第一及び第二作業対象のバケ
ットセットに分配されるトークンの合計数を決定し、分配されるトークンの特定数は合計
数を超えない
ことをさらに含む第６項に記載の方法。
（第８項）
トークンの合計数は、共有リソースの処理能力限度から第一及び第二プロビジョン処理
能力率の合計を減算することで、少なくとも一部決定される、第７項に記載の方法。
（第９項）
第一作業対象のバケットセットは、作業要求到着率が閾値より低い通常モード作動中に
受付制御のためにトークン集合数が調べられる通常モードバケットと、作業要求到着率が
閾値以上のバーストモード作動中に受付制御のためにトークン集合数が調べられるバース
トモードバケットとを備え、特定バケットはバーストモードバケットを含む、第６項に記
載の方法。
（第１０項）
第一作業対象はネットワークアクセス可能なサービスにより管理される第一ストレージ
オブジェクトの少なくとも一部を備え、第二作業対象はネットワークアクセス可能なサー
ビスにより管理される第二ストレージオブジェクトの少なくとも一部を備え、共有リソー
スは第一作業対象及び第二作業対象が記憶されるストレージデバイスを備える、第６項に
記載の方法。
（第１１項）
第一作業対象はネットワークアクセス可能なマルチテナントデータベースサービスによ
り管理される第一テーブルパーティションの少なくとも一部を備え、第二作業対象はネッ
トワークアクセス可能なマルチテナントデータベースサービスにより管理される第二テー
ブルの少なくとも一部を備える、第６項に記載の方法。
（第１２項）
共有リソースはソフトウェアモジュールのデータ構造を備える、第６項に記載の方法。
（第１３項）
特定の作業要求は（ａ）読出し処理、または（ｂ）書込み処理を１以上含む、第６項に
記載の方法。
（第１４項）
１以上のコンピューティングデバイスにより、
第一計量、第二計量、及び処理能力限度の特定関数に少なくとも一部基づいて、分配さ
れるトークンの特定数を決定し、
第一及び第二作業対象に関連する１以上の追加計量を監視し、
１以上の追加計量に少なくとも一部基づいて、特定関数を修正する
ことをさらに含む第６項に記載の方法。
（第１５項）
プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって、プロ
グラム命令は１以上のプロセッサ上で実行されると、
第一作業対象及び第二作業対象が、実行対象として受付けられた作業要求応じて共有リ
ソースを使用するように設定し、第一作業対象は第一プロビジョン処理能力率を有し、第
二作業対象は第二プロビジョン処理能力率を有し、
第一作業対象及び第二作業対象が、作業要求の受付制御用のそれぞれのトークンバケッ
トセットを有するように設定し、各トークンバケットセットは作業要求を実行対象として
受付けるか否かを決定するのに使用されるトークン集合を有する１以上のバケットを備え
、
（ａ）第一時間間隔における第一及び第二作業対象の作業要求到着率を示す第一計量と
、（ｂ）第一及び第二プロビジョン処理能力率に関連する第二計量とを特定し、
第一計量、第二計量、及び共有リソースの処理能力限度に少なくとも一部基づいて、第
一作業対象の特定バケットに特定数のトークンを追加し、
第一作業対象の特定バケットのトークン集合数に少なくとも一部基づいて、第二時間間
隔において、第一作業対象に対する特定の作業要求を実行対象として受付ける、
非一時的コンピュータアクセス可能記憶媒体。
（第１６項）
プログラム命令は１以上のプロセッサ上で実行されると、
共有リソースの処理能力限度に少なくとも一部基づいて、第一及び第二作業対象のバケ
ットセットに分配されるトークンの合計数を決定し、分配されるトークンの特定数は合計
数を超えない、
第１５項に記載の非一時的コンピュータアクセス可能記憶媒体。
（第１７項）
第一作業対象のバケットセットは、作業要求到着率が閾値より低い通常モード作動中に
受付制御のためにトークン集合数が調べられる通常モードバケットと、作業要求到着率が
閾値以上のバーストモード作動中に受付制御のためにトークン集合数が調べられるバース
トモードバケットとを備え、特定バケットはバーストモードバケットを含む、第１５項に
記載の非一時的コンピュータアクセス可能記憶媒体。
（第１８項）
第一作業対象はネットワークアクセス可能なサービスにより管理される第一ストレージ
オブジェクトの少なくとも一部を備え、第二作業対象はネットワークアクセス可能なサー
ビスにより管理される第二ストレージオブジェクトの少なくとも一部を備え、共有リソー
スは第一作業対象及び第二作業対象が記憶されるストレージデバイスを備える、第１５項
に記載の非一時的コンピュータアクセス可能記憶媒体。
（第１９項）
共有リソースはオペレーティングシステムに実装された論理リソースを含む、第１５項
に記載の非一時的コンピュータアクセス可能記憶媒体。
（第２０項）
特定の作業要求は、（ａ）読出し処理、または（ｂ）書込み処理を１以上含む、第１５
項に記載の非一時的コンピュータアクセス可能記憶媒体。

前述の内容は以下の項目を参照することで、より理解されるだろう。
（第１項）
１以上のコンピューティングデバイスを備えるシステムであって、コンピューティング
デバイスは、
作業対象の作業量管理に対応付けられた１以上のトークンバケットのインスタンスを作
成し、作業対象は、作業要求を実行対象として受付けるためのそれぞれの受付制御パラメ
ータセットにより複数の作動モードで作動するように構成され、作業要求受付判断は、１
以上のトークンバケットのうち少なくとも１つのバケットのトークン集合数に少なくとも
一部基づいて行われ、
１以上のトークンバケットのうち特定のトークンバケットに適用するトークン価格設定
ポリシーを特定し、トークン価格設定ポリシーは（ａ）複数の作動モードのうちトークン
価格設定ポリシーが適用される少なくともバースト作動モードの特定を含む、トークン価
格設定ポリシーの１以上の適用基準と、（ｂ）特定のトークンバケットのトークン集合数
の変更に関してクライアントに請求する価格設定額とを示し、
１以上の適用基準を満たした作業対象のバーストモード作動中に起こった、特定のトー
クンバケットのトークン集合数に関する１以上の変更を、時間帯を通して記録し、
時間帯を通して記録された１以上の変更に少なくとも一部基づいて、クライアントに請
求する請求額を生成する
ように構成された、システム。
（第２項）
１以上のトークンバケットは、作業対象の作動モードを決定するためにトークン集合数
が使用される通常モードバケットと、バーストモード作動中に作業要求を受付けるか否か
を決定するためにトークン集合数が使用される１以上のバーストモードバケットとを備え
、特定のトークンバケットは当該の１以上のバーストモードバケットのうちのバーストモ
ードバケットを含む、第１項に記載のシステム。
（第３項）
１以上のバーストモードバケットは、トークン集合数が作業対象の利用可能処理能力を
示すローカルバースト限度バケットと、トークン集合数が複数の作業対象により共有され
るリソースの利用可能処理能力を示す共有リソース能力バケットとを含み、特定バケット
は共有能力バケットを含み、１以上の適用基準のうちの特定の適用基準は、ローカルバー
スト限度バケットのトークン集合数が特定の閾値を上回らないという判断に応じて適用す
る価格設定ポリシーを示す、第２項に記載のシステム。
（第４項）
特定のトークンバケットのトークン集合数の変更は、受信作業要求を実行対象として受
付けるのに１以上のトークンが消費された結果、トークン集合数が減少することを含む、
第１項に記載のシステム。
（第５項）
特定のトークンバケットのトークン集合数の変更は、トークンマーケットプレイスを使
用して行われたトークン販売処理に応じて１以上のトークンが別のバケットへ譲渡された
結果、トークン集合数が減少することを含む、第１項に記載のシステム。
（第６項）
１以上のコンピュータデバイスにより、
作業対象の作業量管理に対応付けられた１以上のトークンバケットのインスタンスを作
成し、作業対象に対する作業要求の受付判断は、１以上のトークンバケットのうち少なく
とも１つのバケットのトークン集合数に少なくとも一部基づいて行われ、
作業対象のバーストモード作動中に１以上のトークンバケットのうち特定のトークンバ
ケットに適用するトークン価格設定ポリシーを決定し、トークン価格設定ポリシーは、特
定のトークンバケットのトークン集合数の変更に関してクライアントに請求する価格設定
額を示し、
バーストモード作動中に行われた、特定のトークンバケットのトークン集合数に関する
１以上の変更を、時間帯を通して記録し、
時間帯を通して記録された１以上の変更に少なくとも一部基づいて、クライアントに請
求する請求額を生成する
ことを含む方法。
（第７項）
１以上のトークンバケットは、作業対象の作動モードを決定するためにトークン集合数
が使用される通常モードバケットと、バーストモード作動中に作業要求を受付けるか否か
を決定するためにトークン集合数が使用される１以上のバーストモードバケットとを備え
、特定のトークンバケットは当該の１以上のバーストモードバケットのうちのバーストモ
ードバケットを含む、第６項に記載の方法。
（第８項）
１以上のバーストモードバケットは、トークン集合数が作業対象の処理能力を示すロー
カルバースト限度バケットと、トークン集合数が複数の作業対象により共有されるリソー
スの利用可能処理能力を示す共有リソース能力バケットとを含み、特定バケットは共有能
力バケットを含み、価格設定ポリシーに従って１以上のコンピューティングデバイスによ
り、
ローカルバースト限度バケットのトークン集合数が閾値基準を満たすという判断に応じ
て、価格設定ポリシーを共有リソース能力バケットの特定のトークン集合数変更に適用す
ることをさらに含む、第７項に記載の方法。
（第９項）
特定のトークンバケットのトークン集合数の変更は、受信作業要求を実行対象として受
付けるのに１以上のトークンが消費された結果、トークン集合数が減少することを含む、
第６項に記載の方法。
（第１０項）
特定のトークンバケットのトークン集合数の変更は、トークンマーケットプレイスを使
用して行われたトークン販売処理に応じて１以上のトークンが別のバケットへ譲渡された
結果、トークン集合数が減少することを含む、第６項に記載の方法。
（第１１項）
１以上のコンピューティングデバイスにより、
トークンマーケットプレイスを介して特定トークンバケットのトークンが別のトークン
バケットへ譲渡可能であることをクライアントが示すことを可能にする１以上のプログラ
ム的インターフェイスを実行することをさらに含む、第１０項に記載の方法。
（第１２項）
トークン価格設定ポリシーは、特定バケットからトークンを別のバケットへ譲渡するの
に請求される金額は、譲渡に関して受けた１以上のオークション入札に少なくとも一部基
づいて決定されることを示す、第１１項に記載の方法。
（第１３項）
１以上のコンピューティングデバイスにより、
クライアントが複数のトークン価格設定ポリシーから１つのトークン価格設定ポリシー
を選択することを可能にする１以上のプログラム的インターフェイスを実行することをさ
らに含む、第６項に記載の方法。
（第１４項）
価格設定ポリシーはクライアント指定の予算限度を示し、１以上のコンピューティング
デバイスにより、
クライアント指定の予算限度に少なくとも一部基づいて、特定のトークンバケットの集
合数の変更の実施を決定することをさらに含む、第６項に記載の方法。
（第１５項）
作業対象はストレージオブジェクトの第一パーティションを備え、ストレージオブジェ
クトは少なくとも第一パーティション及び第二パーティションを含み、特定バケットのト
ークン集合数に関する１以上の変更のうち特定の変更は、特定バケットから第二パーティ
ションの作業量管理のために使用される別のバケットへのトークン譲渡の結果である、第
６項に記載の方法。
（第１６項）
プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって、プロ
グラム命令は１以上のプロセッサ上で実行されると、
作業対象の受付制御判断に使用される１以上のトークンバケットのうち特定のトークン
バケットに適用するトークン価格設定ポリシーを決定し、トークン価格設定ポリシーは作
業対象がバーストモード作動の間に適用され、トークン価格設定ポリシーは特定のトーク
ンバケットのトークン集合数の変更に関してクライアントに請求する価格設定額を示し、
バーストモード作動中の特定のトークンバケットのトークン集合数に関する１以上の変
更を、時間帯を通して記録し、
時間帯を通して記録された１以上の変更に少なくとも一部基づいて、クライアントに請
求する請求額を生成する、
非一時的コンピュータアクセス可能記憶媒体。
（第１７項）
１以上のトークンバケットは、作業対象の通常モード作動中に作業要求を受付けるか否
かを決定するためにトークン集合数が使用される通常モードバケットと、バーストモード
作動中に作業要求を受付けるか否かを決定するためにトークン集合数が使用される１以上
のバーストモードバケットとを備え、特定のトークンバケットは当該の１以上のバースト
モードバケットのうちのバーストモードバケットを含み、命令が１以上のプロセッサ上で
実行されると、
通常モードバケットのトークン集合数変更に適用される別のトークン価格設定ポリシー
を決定する、第１６項に記載の非一時的コンピュータアクセス可能記憶媒体。
（第１８項）
１以上のバーストモードバケットは、トークン集合数が作業対象の利用可能処理能力を
示すローカルバースト限度バケットと、トークン集合数が複数の作業対象により共有され
るリソースの利用可能処理能力を示す共有リソース能力バケットとを含み、特定バケット
は共有能力バケットを含み、価格設定ポリシーに従って命令が１以上のプロセッサ上で実
行されると、
ローカルバースト限度バケットのトークン集合数が閾値基準を満たすという判断に応じ
て、価格設定ポリシーを共有リソース能力バケットの特定のトークン集合数変更に適用す
る、第１７項に記載の非一時的コンピュータアクセス可能記憶媒体。
（第１９項）
特定のトークンバケットのトークン集合数の変更は、トークンマーケットプレイスを
使用して行われたトークン販売処理に応じて１以上のトークンが別のバケットへ譲渡され
た結果、トークン集合数が減少することを含む、第１６項に記載の非一時的コンピュータ
アクセス可能記憶媒体。
（第２０項）
特定バケットにはトークン補充率及び最大トークン集合数限度が設定され、価格設定ポ
リシーは（ａ）トークン補充率、または（ｂ）最大トークン集合数限度、の少なくとも１
つに対する変更に関してクライアントに請求する別の金額の指示を含む、第１６項に記載
の非一時的コンピュータアクセス可能記憶媒体。

前述の内容は以下の項目を参照することで、より理解されるだろう。
（第１項）
１以上のコンピューティングデバイスを備えるシステムであって、コンピューティング
デバイスは、
作業対象に対する作業要求を受信し、
作業対象に対応付けられた通常モードトークンバケットのトークン集合数が第一閾値基
準を満たすという判断に応じて、通常モードトークン消費ポリシーに従って通常モードト
ークンバケットから１以上のトークンを消費し、作業要求を実行対象として受付け、
通常モードトークンバケットのトークン集合数が第一閾値基準を満たさないという判断
に応じて、
バーストモードトークンバケットセットの少なくとも１つのバケットのトークン集合数
が第二閾値基準を満たすか否かを判定し、
バーストモードトークンバケットセットの少なくとも１つのバケットのトークン集合数
が第二閾値基準を満たすという判断に応じて、バーストモードトークン消費ポリシーに少
なくとも一部基づいてバーストモードトークンバケットセットの少なくとも１つのバケッ
トから１以上のトークンを消費し、作業要求を実行対象として受付け、
バーストモードトークンバケットセットの少なくとも１つのバケットのトークン集合数
が第二閾値基準を満たさないという判断に応じて、作業要求を拒否する
ように構成された、システム。
（第２項）
１以上のコンピューティングデバイスはさらに、
通常モードで作動中の作業対象において実行可能とする最大作業処理率を示すプロビジ
ョン処理能力を作業対象に割当て、
プロビジョン処理能力に少なくとも一部基づいた率で、通常モードトークンバケットを
補充し、
プロビジョン処理能力に少なくとも一部基づいた別の率で、バーストモードトークンバ
ケットセットの少なくとも１つのバケットを補充する
ように構成された、第１項に記載のシステム。
（第３項）
１以上のコンピューティングデバイスはさらに、
作業要求が受信された平均率が作業対象に指定されたプロビジョン率より低い特定の時
間帯の終わりに、１以上の作業トークンが通常モードトークンバケットに残っているとい
う判断に応じて、バーストモードトークンバケットセットの少なくとも１つのバケットの
トークン集合数を、通常モードトークンバケットに残る作業トークンの数に少なくとも一
部基づいた数量分だけ増加させる
ように構成された、第１項に記載のシステム。
（第４項）
バーストモードバケットセットは、作業対象における作業処理の最大対応バースト率を
最大トークン集合数で示すローカルバースト限度トークンバケットと、複数の作業オブジ
ェクトにより共有されるリソースの利用可能処理能力をトークン集合数で示す共有リソー
ストークンバケットとを備え、通常モードトークンバケットのトークン集合数が第一閾値
基準を満たさないという前述の判断に応じて、１以上のコンピューティングデバイスはさ
らに、
ローカルバースト限度トークンバケットのトークン集合数がゼロより大きく、かつ共有
リソーストークンバケットのトークン集合数がゼロより大きいと判断したことに応じて、
作業要求を実行対象として受付ける
ように構成された、第１項に記載のシステム。
（第５項）
１以上のコンピューティングデバイスはさらに、
作業要求を実行対象として受付ける前に、作業要求に応じて行われる作業量の見積りを
生成し、
作業要求の受付後に、作業要求に対応する実際に行われた作業量を特定し、
実際に行われた作業量と見積りとの差の特定に応じて、１以上の（ａ）バーストモード
トークンバケットセット、または（ｂ）バーストモードトークンバケットセットの少なく
とも１つのバケットのトークン集合数を、特定された差に少なくとも一部基づいて修正す
る
ように構成された、第１項に記載のシステム。
（第６項）
１以上のコンピュータデバイスにより、
作業対象に対する作業要求を受信し、
作業対象に対応付けられた通常モードトークンバケットのトークン集合数を特定し、
通常モードトークンバケットのトークン集合数が第一閾値基準を満たすという判断に応
じて、
作業対象に対応付けられたバーストモードトークンバケットセットの少なくとも１つの
バケットのトークン集合数が第二閾値基準を満たすと判断し、
作業要求を実行対象として受付け、
バーストモードトークンバケットセットの少なくとも１つのバケットのトークン集合数
を、バーストモードトークン消費ポリシーに少なくとも一部基づいて修正する
ことを含む方法。
（第７項）
１以上のコンピューティングデバイスにより、
通常モードで作動中の作業対象において実行可能とする最大作業処理率を示すプロビジ
ョン処理能力を作業対象に割当て、
プロビジョン処理能力に少なくとも一部基づいた率で、通常モードトークンバケットを
補充し、
プロビジョン処理能力に少なくとも一部基づいた別の率で、バーストモードトークンバ
ケットセットの少なくとも１つのバケットを補充する
ことをさらに含む第６項に記載の方法。
（第８項）
１以上のコンピューティングデバイスにより、
作業対象が通常モードで作動していた特定の時間帯の終わりに、１以上の作業トークン
が通常モードトークンバケットに残っているという判断に応じて、バーストモードトーク
ンバケットセットの少なくとも１つのバケットのトークン集合数を、通常モードトークン
バケットに残る作業トークンの数に少なくとも一部基づいた数量分だけ増加させる
ことをさらに含む第６項に記載の方法。
（第９項）
バーストモードバケットセットは、作業対象における作業処理の最大対応バースト率を
最大トークン集合数で示すローカルバースト限度トークンバケットと、複数の作業オブジ
ェクトにより共有されるリソースの利用可能処理能力をトークン集合数で示す共有リソー
ストークンバケットとを備え、通常モードトークンバケットのトークン集合数が第一閾値
基準を満たすという前述の判断に応じて、１以上のコンピューティングデバイスにより、
ローカルバースト限度トークンバケットのトークン集合数がゼロより大きく、かつ共有
リソーストークンバケットのトークン集合数がゼロより大きいと判断したことに応じて、
作業要求を実行対象として受付ける
ことをさらに含む第６項に記載の方法。
（第１０項）
１以上のコンピューティングデバイスにより、
作業要求を実行対象として受付ける前に、作業要求に応じて行われる作業量の見積りを
生成し、
当該作業要求の作業開始後に、作業要求に対応する実際に行われた作業量を特定し、
実際の作業量と見積りとの差の特定に応じて、１以上の（ａ）バーストモードトークン
バケットセット、または（ｂ）バーストモードトークンバケットセットの少なくとも１つ
のバケットのトークン集合数を、特定された差に少なくとも一部基づいて修正する
ことをさらに含む第６項に記載の方法。
（第１１項）
作業対象はストレージオブジェクトの少なくとも一部を備え、作業要求は（ａ）読出し
処理、または（ｂ）書込み処理のうち少なくとも１つを含む、第６項に記載の方法。
（第１２項）
バーストモードバケットセットは、読出し処理を含む作業要求の受付制御に使用される
読出しバーストトークンバケットと、書込み処理を含む作業要求の受付制御に使用される
書込みバーストトークンバケットとを備える、第６項に記載の方法。
（第１３項）
１以上のコンピューティングデバイスにより、
時間帯を通して作業要求到着率を監視し、
バーストモードトークンバケットセットの少なくとも１つのバケットの最大トークン集
合数限度を、作業要求到着率の監視結果に少なくとも一部基づいて修正する
ことをさらに含む第６項に記載の方法。
（第１４項）
１以上のコンピューティングデバイスにより、
作業対象のバーストモード処理に対応付けられた価格設定ポリシーの指示をクライアン
トに提供し、
バーストモードトークンバケットセットの少なくとも１つのバケットの最大トークン集
合数限度を、価格設定ポリシーに従って、クライアントから受信したバーストモード能力
増加要求に少なくとも一部基づいて修正する
ことをさらに含む第６項に記載の方法。
（第１５項）
プログラム命令を記憶する非一時的コンピュータアクセス可能記憶媒体であって、プロ
グラム命令は１以上のプロセッサ上で実行されると、
作業対象に対する作業要求を受信し、
第一閾値基準に少なくとも一部基づいて作業対象がバーストモードで作動しているとい
う判断に応じて、
作業対象に対応付けられたバーストモードトークンバケットセットの少なくとも１つの
バケットのトークン集合数が第二閾値基準を満たすと判断し、
作業要求を実行対象として受付ける、
非一時的コンピュータアクセス可能記憶媒体。
（第１６項）
プログラム命令は１以上のプロセッサ上で実行されると、
通常モードで作動中の作業対象において実行可能とする最大作業処理率を示すプロビジ
ョン処理能力を作業対象に割当て、
プロビジョン処理能力に少なくとも一部基づいた率で、作業対象に対応付けられた通常
モードトークンバケットを補充し、第一閾値基準は通常モードトークンバケットのトーク
ン集合数に少なくとも一部基づき、
プロビジョン処理能力に少なくとも基づいた別の率で、バーストモードトークンバケッ
トセットの少なくとも１つのバケットを補充する、
第１５項に記載の非一時的コンピュータアクセス可能記憶媒体。
（第１７項）
プログラム命令は１以上のプロセッサ上で実行されると、
特定の時間帯の終わりに、１以上の作業トークンが作業対象に対応付けられた通常モー
ドトークンバケットに残っているという判断に応じて、バーストモードトークンバケット
セットの少なくとも１つのバケットのトークン集合数を、通常モードトークンバケットに
残る作業トークンの数に少なくとも一部基づいた数量分だけ増加させる、
第１５項に記載の非一時的コンピュータアクセス可能記憶媒体。
（第１８項）
バーストモードバケットセットは、作業対象における作業処理の最大対応バースト率を
最大トークン集合数で示すローカルバースト限度トークンバケットと、複数の作業オブジ
ェクトにより共有されるリソースの利用可能処理能力をトークン集合数で示す共有リソー
ストークンバケットとを備え、第一閾値基準が満たされたという判断に応じてプログラム
命令が１以上のプロセッサ上で実行されると、
ローカルバースト限度トークンバケットのトークン集合数がゼロより大きく、かつ共有
リソーストークンバケットのトークン集合数がゼロより大きいと判断したことに応じて、
作業要求を実行対象として受付ける、
第１５項に記載の非一時的コンピュータアクセス可能記憶媒体。
（第１９項）
プログラム命令は１以上のプロセッサ上で実行されると、
バーストモードトークンバケットセットの少なくとも１つのバケットのトークン集合数
が第二閾値基準を満たすという判断に応じて、トークン消費ポリシーに従って、少なくと
も１つのバケットの少なくとも１つのトークンを消費する、
第１５項に記載の非一時的コンピュータアクセス可能記憶媒体。
（第２０項）
作業対象はデータベーステーブルのパーティションの少なくとも一部を備え、作業要求
は（ａ）読出し処理、または（ｂ）書込み処理のうち少なくとも１つを含む、第１５項に
記載の非一時的コンピュータアクセス可能記憶媒体。
結論

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

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

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

Claims (15)

1. トークンバケットの第一のセットを伴う第一の作業対象を含む、作業要求の許可制御のためのトークンバケットのそれぞれのセットを伴う複数の作業対象を構成するように、この場合、前記第一の作業対象における実行の作業要求を受け付ける判断は、前記第一のセットの一つ以上のトークンバケットのトークン集合数に少なくとも一部基づいている、
   トークン共有評価基準が、前記第一の作業対象において満たされているという判断に応じて、前記第一の作業対象からのトークン集合数情報をそれと交換する複数の作業対象の第二の作業対象を識別するように、この場合、前記第二の作業対象は、トークンバケットの第二のセットとともに構成され、
   前記第一のセットにおける第一のバケットおよび前記第二のセットにおける第二のバケットのそれぞれのトークン集合数の分析に少なくとも一部基づいて、前記第一のバケットと前記第二のバケットとの間のトークン転送を開始するか否かを判断するように、
   トークン転送を開始する判断に応じて、前記トークン転送に対して識別された転送方向に従って、特定数のトークンにより、前記第一および第二のバケットのうちの一方のバケットの前記トークン集合数を増加させ、および前記特定数のトークンにより、前記第一および第二のバケットのうちの他方のバケットの前記トークン集合数を減少させるように、
   第一の作業対象に向けられた作業要求の受信に応じて、前記第一のバケットの変更されたトークン集合数に少なくとも一部基づいて、前記実行に対する作業要求を受け付けるように、
   構成された一つ以上のコンピューティングデバイスを備えるシステム。
2. 前記複数の作業対象は、第一のクライアントのためのネットワークアクセス可能なストレージサービスで生成された一つ以上のストレージオブジェクトから成る第一の収集物と、第二のクライアントのためのネットワークアクセス可能なストレージサービスで生成された一つ以上のストレージオブジェクトから成る第二の収集物とを含み、前記第一の作業対象は、前記第一の収集物のストレージオブジェクトの少なくとも一部を備え、および前記第二の作業対象を識別するために、前記一つ以上のコンピューティングデバイスは、前記第一の収集物から前記第二の収集物を選択するように構成される、請求項１に記載のシステム。
3. 前記第一の作業対象は、ネットワークアクセス可能なデータベースサービスの特定のクライアントのためにインスタンス化されたベースデータベーステーブルの少なくとも一部を備え、前記第二の作業対象は、前記ベースデータベーステーブルに二次インデックスを実装するために前記ネットワークアクセス可能なデータベースサービスにおいてインスタンス化された派生データベーステーブルの少なくとも一部を備える、請求項１に記載のシステム。
4. 前記トークンバケットの第一のセットは、前記第一の作業対象の動作の通常モード中の許可制御に用いられる通常モードバケットと、前記第一の作業対象における動作のバーストモード中の許可制御に用いられる一つ以上のバーストモードトークンバケットとを備え、前記一つ以上のバーストモードトークンバケットは前記第一のバケットを含む、請求項１に記載のシステム。
5. 一つ以上のコンピューティングデバイスによって、
   第一のトークンバケットセットを伴う第一の作業対象を含む、作業要求の許可制御のためのそれぞれのトークンバケットセットを伴う複数の作業対象を構成することであって、前記第一の作業対象における実行の作業要求を受け付ける判断は、前記第一のトークンバケットセットの一つ以上のトークンバケットのトークン集合数に少なくとも一部基づいていることと、
   トークン共有評価基準が前記第一の作業対象において満たされているという判断に応じて、前記第一のトークンバケットセットの第一のバケットと、前記複数の作業対象の第二の作業対象に関連する第二のトークンバケットセットの第二のバケットとの間の特定の方向でトークン転送を開始することと、
   前記第一の作業対象に向けられた作業要求の受信に応じて、前記トークン転送の後の前記第一のバケットの前記トークン集合数に少なくとも一部基づいて、前記実行に対する作業要求を受け付けることと、
   を実行することを含む方法。
6. 前記複数の作業対象は、第一のクライアントのためのネットワークアクセス可能なストレージサービスで生成された一つ以上のストレージオブジェクトから成る第一の収集物と、第二のクライアントのためのネットワークアクセス可能なストレージサービスで生成された一つ以上のストレージオブジェクトから成る第二の収集物とを含み、前記第一の作業対象は、前記第一の収集物のストレージオブジェクトの少なくとも一部を備え、前記一つ以上のコンピューティングデバイスによって、前記第一の収集物から前記第二の作業対象を選択することをさらに含む、請求項５に記載の方法。
7. 前記第一の作業対象は、ネットワークアクセス可能なデータベースサービスの特定のクライアントのためにインスタンス化されたベースデータベーステーブルの少なくとも一部を備え、前記第二の作業対象は、前記ベースデータベーステーブルに二次インデックスを実装するために前記ネットワークアクセス可能なデータベースサービスにおいてインスタンス化された派生データベーステーブルの少なくとも一部を備える、請求項５に記載の方法。
8. 前記第一のトークンバケットセットは、前記第一の作業対象の動作の通常モード中の許可制御に用いられる通常モードバケットと、前記第一の作業対象における動作のバーストモード中の許可制御に用いられる一つ以上のバーストモードトークンバケットとを備え、前記一つ以上のバーストモードトークンバケットは前記第一のバケットを含む、請求項５に記載の方法。
9. 前記一つ以上のコンピューティングデバイスによって、
   任意選択ポリシーを用いて、前記第二の作業対象を選択することを実行することをさらに含む、請求項５に記載の方法。
10. 前記一つ以上のコンピューティングデバイスによって、
    ゴシッププロトコルに従って、前記第二の作業対象を選択することを実行することをさらに含む、請求項５に記載の方法。
11. 前記一つ以上のコンピューティングデバイスによって、
    （ａ）前記第一の作業対象において、前の評価が開始されてからの時間の量、（ｂ）前記第一のバケットの前記トークン集合数が第一の閾値以下に低下したという指示、（ｃ）前記第一のバケットの前記トークン集合数が、第二の閾値以上に増加したという指示、または、（ｄ）前記第一の作業対象における作業要求の拒否の割合が、特定の閾値以上になったという指示のうちの一つ以上に少なくとも一部基づいて、前記トークン共有評価基準が満たされているか否かを判断することを実行することをさらに含む、請求項５に記載の方法。
12. 前記第一の作業対象は、ストレージオブジェクトの第一の論理パーティションの複数のレプリカのうちの第一のレプリカを備え、前記複数のレプリカの各レプリカには、（ａ）マスタ役および（ｂ）スレーブ役のうちの一方を含む役割が割り当てられ、前記第一の論理パーティションに指示された書込み動作を含む作業要求に対する許可制御は、マスタ役がそれに割り当てられる前記レプリカにおいて実行され、前記第一のレプリカには、前記第一の論理パーティションに関する第一の役割が割り当てられ、前記一つ以上のコンピューティングデバイスによって、
    前記ストレージオブジェクトの第二の論理パーティションの特定のレプリカを前記第二の作業対象として選択することであって、前記特定のレプリカには、前記第一の論理パーティションに関する前記第一のレプリカの役割と同じ前記第二の論理パーティションに関する役割が割り当てられることを実行することをさらに含む、請求項５に記載の方法。
13. 前記第一のバケットと前記第二のバケットとの間の特定の方向で前記トークン転送を開始することは、特定の時間ウィンドウ内での、他のトークン転送が、前記第一の作業対象と前記第二の作業対象との間で実施されていないという判断に少なくとも一部基づいている、請求項５に記載の方法。
14. 前記特定の方向は、前記第一のバケットおよび第二のバケットの中のより大きなトークン集合数を伴うトークンバケットから、前記第一および第二のバケットの中のより小さなトークン集合数を伴うトークンバケットへの方向であり、前記方法は、前記一つ以上のコンピューティングデバイスによって、
    前記より大きなトークン集合数と、前記より小さなトークン集合数との差に応じて、転送されるトークンの数を決定することを実行することを含む、請求項５に記載の方法。
15. 一つ以上のプロセッサ上で実行される場合に、
    第一のトークンバケットセットの第一のバケットと、第二のトークンバケットセットの第二のバケットとの間で転送されるトークンの数を決定し、この場合、前記第一のトークンバケットセットは、複数の作業対象の第一の作業対象に向けられた作業要求の許可制御に用いられ、前記第二のトークンバケットセットは、前記複数の作業対象の第二の作業対象における許可制御に用いられ、
    前記第一のバケットと前記第二のバケットとの間の特定の方向で前記トークンの転送を開始し、
    前記第一の作業対象に向けられた作業要求の受信に応じて、前記トークンの転送の後の前記第一のバケットのトークン集合数に少なくとも一部基づいて、前記作業要求を受け付ける、
    プログラム命令を格納する非一時的コンピュータアクセス可能記憶媒体。

Images