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

バーストモード制御 Download PDF

Info

Publication number
JP2016529597A
JP2016529597A JP2016524171A JP2016524171A JP2016529597A JP 2016529597 A JP2016529597 A JP 2016529597A JP 2016524171 A JP2016524171 A JP 2016524171A JP 2016524171 A JP2016524171 A JP 2016524171A JP 2016529597 A JP2016529597 A JP 2016529597A
Authority
JP
Japan
Prior art keywords
token
work
bucket
tokens
burst
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016524171A
Other languages
English (en)
Other versions
JP6247388B2 (ja
Inventor
シャオ，ウェイ
スウィフト，ビョーン・パトリック
ムニスワミー−レディ，キラン−クマール
フィリペ，ミゲル・マスカレニャス
ルー，イージュン
マーシャル，スチュワート・ヘンリー・シーライ
ステファニー，ステファノ
ハミルトン，ジェームズ・アール
Original Assignee
アマゾン・テクノロジーズ・インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/926,697 external-priority patent/US9385956B2/en
Priority claimed from US13/926,694 external-priority patent/US10764185B2/en
Priority claimed from US13/926,686 external-priority patent/US9471393B2/en
Priority claimed from US13/926,708 external-priority patent/US9218221B2/en
Priority claimed from US13/926,684 external-priority patent/US9553821B2/en
Application filed by アマゾン・テクノロジーズ・インコーポレーテッド filed Critical アマゾン・テクノロジーズ・インコーポレーテッド
Publication of JP2016529597A publication Critical patent/JP2016529597A/ja
Application granted granted Critical
Publication of JP6247388B2 publication Critical patent/JP6247388B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/215—Flow control; Congestion control using token-bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/29—Flow control; Congestion control using a combination of thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/52—Queue scheduling by attributing bandwidth to queues
    • H04L47/525—Queue scheduling by attributing bandwidth to queues by redistribution of residual bandwidth

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Debugging And Monitoring (AREA)

Abstract

共有リソース余剰処理能力の公平分配に関する方法及び装置が開示される。第一及び第二作業対象は、受付けた作業要求を実行するために共有リソースにアクセスするように構成される。作業対象において、それぞれのトークンバケットを使用して受付制御が管理される。ある時間間隔における作業対象の作業要求到着率を示す第一計量と、作業対象のプロビジョン能力に関連する第二計量が特定される。共有リソースの処理能力限度に基づいて決定された数のトークンが、その次の時間間隔における受付制御に使用されるように、作業対象に分配される。各作業対象に分配されたトークン数は、第一計量及び／または第二計量に基づく。

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. １以上のプロセッサ及び、プログラム命令を記憶する１以上のメモリを備えるシステムであって、前記プログラム命令は１以上のプロセッサ上で実行されると、
    作業対象に対する作業要求を受信し、
    第一閾値基準に少なくとも一部基づいて前記作業対象がバーストモードで作動しているという判断に応じて、
    前記作業対象に対応付けられたバーストモードトークンバケットセットの少なくとも１つのバケットの前記トークン集合数が第二閾値基準を満たすと判断し、
    前記作業要求を実行対象として受付ける、
    前記システム。
JP2016524171A 2013-06-25 2014-06-25 バーストモード制御 Active JP6247388B2 (ja)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US13/926,697 US9385956B2 (en) 2013-06-25 2013-06-25 Compound token buckets for burst-mode admission control
US13/926,694 US10764185B2 (en) 2013-06-25 2013-06-25 Token-based policies burst-mode operations
US13/926,684 2013-06-25
US13/926,697 2013-06-25
US13/926,686 US9471393B2 (en) 2013-06-25 2013-06-25 Burst-mode admission control using token buckets
US13/926,694 2013-06-25
US13/926,708 2013-06-25
US13/926,708 US9218221B2 (en) 2013-06-25 2013-06-25 Token sharing mechanisms for burst-mode operations
US13/926,686 2013-06-25
US13/926,684 US9553821B2 (en) 2013-06-25 2013-06-25 Equitable distribution of excess shared-resource throughput capacity
PCT/US2014/044188 WO2014210221A1 (en) 2013-06-25 2014-06-25 Burst mode control

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2017220600A Division JP6530471B2 (ja) 2013-06-25 2017-11-16 バーストモード制御

Publications (2)

Publication Number Publication Date
JP2016529597A true JP2016529597A (ja) 2016-09-23
JP6247388B2 JP6247388B2 (ja) 2017-12-13

Family

ID=52142660

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2016524171A Active JP6247388B2 (ja) 2013-06-25 2014-06-25 バーストモード制御
JP2017220600A Active JP6530471B2 (ja) 2013-06-25 2017-11-16 バーストモード制御

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2017220600A Active JP6530471B2 (ja) 2013-06-25 2017-11-16 バーストモード制御

Country Status (8)

Country Link
EP (1) EP3014804B1 (ja)
JP (2) JP6247388B2 (ja)
KR (4) KR101903623B1 (ja)
CN (1) CN105409171B (ja)
AU (2) AU2014302426B2 (ja)
CA (1) CA2915996C (ja)
SG (2) SG11201510427QA (ja)
WO (1) WO2014210221A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018018275A (ja) * 2016-07-27 2018-02-01 富士ゼロックス株式会社 情報処理装置及びプログラム
WO2023027081A1 (ja) * 2021-08-27 2023-03-02 株式会社日立製作所 管理装置、方法、およびプログラム

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180097817A1 (en) * 2016-09-30 2018-04-05 Microsoft Technology Licensing, Llc Generating short-term signatures for accessing cloud storage
CN108270744B (zh) * 2016-12-30 2021-05-07 北京国双科技有限公司 媒体数据访问方法及装置
CN109802895B (zh) * 2017-11-16 2023-01-13 阿里巴巴集团控股有限公司 数据处理系统、方法及令牌管理方法
CN108573013A (zh) * 2017-12-08 2018-09-25 北京金山云网络技术有限公司 请求处理方法、装置、电子设备及计算机可读存储介质
CN108667744B (zh) * 2018-02-26 2020-09-25 华为技术有限公司 流量控制方法及装置
CN110413209B (zh) * 2018-04-28 2023-05-30 伊姆西Ip控股有限责任公司 管理存储系统的方法和设备
WO2019217530A1 (en) * 2018-05-08 2019-11-14 Idac Holdings, Inc. Methods for logical channel prioritization and traffic shaping in wireless systems
CN113468214B (zh) * 2020-03-30 2022-04-29 阿里巴巴集团控股有限公司 数据库访问控制方法、装置、电子设备及可读存储介质
CN112600761B (zh) * 2020-12-11 2024-04-09 腾讯科技（深圳）有限公司 一种资源分配的方法、装置及存储介质
FI20215093A1 (en) * 2021-01-28 2022-07-29 Nokia Solutions & Networks Oy Apparatus and method for scheduling traffic
CN113422736B (zh) * 2021-06-16 2022-06-14 中移（杭州）信息技术有限公司 基于令牌桶的请求管理方法、装置、设备及存储介质
CN114860334B (zh) * 2022-04-24 2024-01-26 曙光信息产业(北京)有限公司 虚拟机启动风暴的处理方法、装置、设备及介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005501316A (ja) * 2001-06-07 2005-01-13 マルコニ ユーケイ インテレクチュアル プロパティー リミテッド リアルタイム処理

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5944789A (en) * 1996-08-14 1999-08-31 Emc Corporation Network file server maintaining local caches of file directory information in data mover computers
WO1999065184A2 (en) * 1998-06-05 1999-12-16 British Telecommunications Public Limited Company Accounting in a communications network
US6337865B1 (en) 1998-09-23 2002-01-08 Maxtor Corporation Fair buffer credit distribution flow control
US6738813B1 (en) * 2000-09-11 2004-05-18 Mercury Interactive Corporation System and method for monitoring performance of a server system using otherwise unused processing capacity of user computing devices
JP3904922B2 (ja) 2001-12-28 2007-04-11 株式会社日立製作所 トラヒックシェーパーおよび集線装置
US7307949B1 (en) * 2002-11-19 2007-12-11 Juniper Networks, Inc. Hierarchical policers for enforcing differentiated traffic behavior
CA2529128A1 (en) * 2003-06-13 2005-01-06 Dow Global Technologies Inc. High performance polyurethane carpet backings containing modified vegetable oil polyols
JP4036799B2 (ja) 2003-07-29 2008-01-23 京セラ株式会社 通信装置
JP4710559B2 (ja) 2005-11-15 2011-06-29 Ｋｄｄｉ株式会社 トークンバッファサイズを制御する通信端末及びシステム
US20070147404A1 (en) * 2005-12-27 2007-06-28 Lucent Technologies, Inc. Method and apparatus for policing connections using a leaky bucket algorithm with token bucket queuing
CA2655555A1 (en) * 2006-06-19 2007-12-27 Liquid Computing Corporation Methods, systems and protocols for application to application communications
US7760641B2 (en) 2006-07-10 2010-07-20 International Business Machines Corporation Distributed traffic shaping across a cluster
US20080077932A1 (en) * 2006-09-25 2008-03-27 International Business Machines Corporation Mechanism for Automatically Managing the Resource Consumption of Transactional Workloads
US7948882B2 (en) * 2006-10-09 2011-05-24 Agere Systems Inc. Dual leaky bucket flow control method and system
US20110078303A1 (en) * 2009-09-30 2011-03-31 Alcatel-Lucent Usa Inc. Dynamic load balancing and scaling of allocated cloud resources in an enterprise network
US8190593B1 (en) * 2010-04-14 2012-05-29 A9.Com, Inc. Dynamic request throttling
US8542594B2 (en) 2010-06-28 2013-09-24 Kddi Corporation Traffic control method and apparatus for wireless communication
CN102299861B (zh) * 2011-09-22 2015-09-02 迈普通信技术股份有限公司 一种报文流量控制方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005501316A (ja) * 2001-06-07 2005-01-13 マルコニ ユーケイ インテレクチュアル プロパティー リミテッド リアルタイム処理

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
大場義洋ほか: "ＡＴＭ網におけるバースト性を持つトラヒックのフロー抑制制御", 電子情報通信学会技術研究報告, vol. Ｖｏｌ．９０ Ｎｏ．４５３, JPN6017010779, 6 March 1991 (1991-03-06), JP, pages ３７−４２ページ *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018018275A (ja) * 2016-07-27 2018-02-01 富士ゼロックス株式会社 情報処理装置及びプログラム
WO2023027081A1 (ja) * 2021-08-27 2023-03-02 株式会社日立製作所 管理装置、方法、およびプログラム

Also Published As

Publication number Publication date
KR101903623B1 (ko) 2018-10-04
SG11201510427QA (en) 2016-01-28
JP6247388B2 (ja) 2017-12-13
JP2018077852A (ja) 2018-05-17
KR20180014883A (ko) 2018-02-09
JP6530471B2 (ja) 2019-06-12
EP3014804A1 (en) 2016-05-04
KR101948502B1 (ko) 2019-02-14
SG10201709194PA (en) 2017-12-28
EP3014804B1 (en) 2019-08-07
WO2014210221A1 (en) 2014-12-31
KR101865318B1 (ko) 2018-06-08
KR20180063371A (ko) 2018-06-11
EP3014804A4 (en) 2017-03-01
CA2915996C (en) 2020-06-30
CN105409171A (zh) 2016-03-16
AU2017203274A1 (en) 2017-06-08
AU2017203274B2 (en) 2018-06-21
AU2014302426A1 (en) 2016-01-28
CA2915996A1 (en) 2014-12-31
KR20180108901A (ko) 2018-10-04
AU2014302426B2 (en) 2017-02-23
CN105409171B (zh) 2019-03-29
KR20160020529A (ko) 2016-02-23
KR101826969B1 (ko) 2018-03-22

Similar Documents

Publication Publication Date Title
JP6247388B2 (ja) バーストモード制御
US9917782B2 (en) Equitable distribution of excess shared-resource throughput capacity
US9471393B2 (en) Burst-mode admission control using token buckets
US9385956B2 (en) Compound token buckets for burst-mode admission control
US9218221B2 (en) Token sharing mechanisms for burst-mode operations
US10764185B2 (en) Token-based policies burst-mode operations
US7634430B2 (en) System and method for allocating resources in a distributed computational system using proportional share auctions
Van den Bossche et al. Online cost-efficient scheduling of deadline-constrained workloads on hybrid clouds
Yu et al. Challenges and opportunities for trust management in crowdsourcing
CN105204924A (zh) 管理程序执行能力的私有使用
CN112997469A (zh) 用于分布式计算和存储的智能、分散和自主市场
TWI621080B (zh) 計費式授權管理方法
Chikhaoui et al. A cost model for hybrid storage systems in a cloud federations
Depoorter et al. Advance reservation, co-allocation and pricing of network and computational resources in grids
Llull Microeconomic Models for Managing Shared Datacenters
CN114328708A (zh) 一种计费方法、装置和存储介质
Du et al. Leveraging Slack Capacity in IaaS Contract Cloud Services
Mian et al. Technical Report No. 2015-624 Cost-Effective Resource Configurations for Multi-tenant Database Systems in Public Clouds1
Ferguson et al. An Economy for Managing Replicated Data in Autonomous Decentralized Systems (Proceedings of International Symposium on Autonomous and Decentralized Systems, 1993)

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170411

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170711

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20171017

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171116

R150 Certificate of patent or registration of utility model

Ref document number: 6247388

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250