(57)【要約】      （修正有）【課題】オークションに基づく公平な割り当て及び使用を容易にする。【解決手段】オンデマンドサービス環境において、方法は、ネットワークを通じて複数の組織からジョブ要求及び入札を受信するステップを有する。各ジョブ要求とその対応する入札とは、ネットワークを通じてコンピューティング装置においてユーザインタフェースを介して、マルチテナントデータベースシステム内でリソース通貨値を有する組織に関連付けられたユーザによって出される。さらに、複数の組織に関する保留ジョブに関連付けられるリソース通貨値を特定するステップを有する。リソース通貨値は、保留ジョブに対して専用にされるリソースに対応する。専用にされておらず購入に利用可能なままであるリソースについて、上記の受信した入札のオークションを実行するステップも有する。入札は、利用可能なリソースを購入するための購入要求を含む。【選択図】図３
2019040613.tif 000002
【特許請求の範囲】
【請求項１】
オークションサーバ計算装置（「オークション装置」）を有するマルチテナントデータベース環境においてテナント間でオークションベース・リソース共有するデータベースシステムにおいて実行される方法であって、前記オークション装置は、１つ又は複数の処理デバイスと、前記１つ又は複数の処理デバイスに前記方法を実行させるスレッドリソース管理機構をホスティングする関連メモリデバイスとを有し、前記方法は、
前記オークション装置が、前記マルチテナントデータベース環境のテナントから、新しいジョブと保留状態のジョブとのうち少なくとも１つのリソースを求めるビッドを受け取るステップであって、前記スレッドリソース管理機構はテナント間のオークションベース・リソース共有を行うオークションベース・リソース共有ロジックを含む処理フレームワークを含む、ステップと、
前記オークション装置が、前記ビッドに対しリソース割り当て決定を行う２レベルスケジューリング方式を実行するステップであって、前記２レベルスケジューリング方式は前記テナントに関連する優先順位と、前記新しいジョブ及び保留状態のジョブのメッセージタイプとを考慮し、優先順位を考慮することは前記テナントと前記メッセージタイプとの１つ又は複数の履歴考慮をレビューすることを含み、前記履歴考慮は１つ又は複数のテナントが１つ又は複数のジョブを要求していることが知られる頻度と、１つ又は複数のメッセージタイプを処理する期待ランタイムを示すランタイム履歴とのうち少なくとも１つを含む、ステップと、
前記２レベルスケジューリング方式に基づいて、前記オークション装置が、第１のテナントが第１の新しいジョブと第１の保留状態のジョブとのうち少なくとも１つの前記リソースの第１の部分の割り当てるビッドを勝つのに十分な通貨を有するか判断するステップであって、前記判断することはさらに、第２のテナントの第２の保留状態のジョブが、前記第２の保留状態のジョブの完了のために前記第２のテナントに対して確保された前記リソースの第２の部分を消費せずに完了したか評価することを含む、ステップと、
前記オークション装置が、前記第１のテナントによる前記ビッドに応じて前記第１のテナントに前記リソースの第１の部分を割り当てるステップであって、前記第１の部分は新しいセットのリソースと前記第２のテナントの未使用の割り当てられたリソースとのうち少なくとも１つを含み、割り当てすることは、考慮された優先順位から、前記第１のテナントと、前記第１の新しいジョブまたは前記第１の保留状態のジョブのメッセージタイプとに関連する１つ又は複数のジョブ優先順位に基づく、ステップとを含む、
方法。
【請求項２】
割り当てることはさらに、第３のテナントによる実際のリソース使用量が前記第３のテナントの期待リソース使用量より少ない場合、前記リソースの第３の部分を、後続の新しいジョブ要求または前記第３のテナントによりなされたビッドに応じて他のメッセージタイプに対応する第３の保留状態のジョブを実行する第３のテナントに関連付けることを含む、
請求項１に記載の方法。
【請求項３】
前記オークション装置が、ジョブまたはビッドの優位性のうち１つ又は複数に基づき、前記リソースの第１の部分と第３の部分をそれぞれ前記第１のテナントと第３のテナントとに購入することを許すことをさらに含む、
請求項１に記載の方法。
【請求項４】
前記オークション装置が、前記ビッドを前記テナントにブロードキャストして、ブロードキャストされたビッドが前記テナントからの追加的ビッドを促進することをさらに含む、    
請求項１に記載の方法。
【請求項５】
前記ビッドは、クラウドベースネットワーク、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、パーソナルエリアネットワーク（ＰＡＮ）、イントラネット、エクストラネット、及びインターネットのうち１つ又は複数を含む通信ネットワークを介して、前記オークション装置により受け取られる、
請求項１に記載の方法。
【請求項６】
マルチテナントデータベース環境においてテナント間でオークションベース・リソース共有をするオークションサーバ計算装置（「オークション装置」）を有するデータベースシステムであって、前記オークション装置は、１つ又は複数の処理デバイスと関連メモリデバイスとを有し、前記１つ又は複数の処理デバイスに動作を実行させるスレッドリソース管理機構をホスティングし、前記動作は、
前記マルチテナントデータベース環境のテナントから、新しいジョブと既存のジョブとのうち少なくとも１つのリソースを求めるビッドを受け取るステップであって、前記スレッドリソース管理機構はテナント間のオークションベース・リソース共有を行うオークションベース・リソース共有ロジックを含む処理フレームワークを含む、ステップと、
前記ビッドに対しリソース割り当て決定を行う２レベルスケジューリング方式を実行するステップであって、前記２レベルスケジューリング方式は前記テナントに関連する優先度と、前記新しいジョブ及び既存のジョブのメッセージタイプとを考慮し、優先度を考慮することは前記テナントと前記メッセージタイプとの１つ又は複数の履歴考慮をレビューすることを含み、前記履歴考慮は１つ又は複数のテナントが１つ又は複数のジョブを要求していることが知られる頻度と、１つ又は複数のメッセージタイプを処理する期待ランタイムを示すランタイム履歴とのうち少なくとも１つを含む、ステップと、
前記２レベルスケジューリング方式に基づいて、第１のテナントが第１の新しいジョブと第１の既存のジョブとのうち少なくとも１つの前記リソースの第１の部分の割り当てるビッドを勝つのに十分な通貨を有するか判断するステップであって、前記判断することはさらに、第２のテナントの第２の既存のジョブが、前記第２の既存のジョブの完了のために前記第２のテナントに対して確保された前記リソースの第２の部分を消費せずに完了したか評価することを含む、ステップと、
前記第１のテナントによる前記ビッドに応じて前記第１のテナントに前記リソースの第１の部分を割り当てるステップであって、前記第１の部分は新しいセットのリソースと前記第２のテナントの未使用の割り当てられたリソースとのうち少なくとも１つを含み、割り当てすることは、考慮された優先順位から、前記第１のテナントと、前記第１の新しいジョブまたは第１の保留状態のジョブのメッセージタイプとに関連する１つ又は複数のジョブ優先順位に基づく、ステップとを含む、
データベースシステム。
【請求項７】
割り当てることはさらに、第３のテナントによる実際のリソース使用量が前記第３のテナントの期待リソース使用量より少ない場合、前記リソースの第３の部分を、後続の新しいジョブ要求または前記第３のテナントによりなされたビッドに応じて他のメッセージタイプに対応する第３の保留状態のジョブを実行する第３のテナントに関連付けることを含む、
請求項６に記載のデータベースシステム。
【請求項８】
前記動作はさらに、ジョブまたはビッドの優位性のうち１つ又は複数に基づき、前記リソースの第１の部分と第３の部分をそれぞれ前記第１のテナントと第３のテナントとに購入することを許すステップを含む、
請求項６に記載のデータベースシステム。
【請求項９】
前記動作はさらに、前記ビッドを前記テナントにブロードキャストして、ブロードキャストされたビッドが前記テナントからの追加的ビッドを促進するステップをさらに含む、
請求項６に記載のデータベースシステム。
【請求項１０】
前記ビッドは、クラウドベースネットワーク、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、パーソナルエリアネットワーク（ＰＡＮ）、イントラネット、エクストラネット、及びインターネットのうち１つ又は複数を含む通信ネットワークを介して、前記オークション装置により受け取られる、
請求項６に記載のデータベースシステム。
【請求項１１】
プロセッサにより実行されると、前記プロセッサに、請求項１ないし５いずれか一項に記載の方法を実施または実行させるコンピュータプログラム。
【請求項１２】
請求項１ないし５いずれか一項に記載の方法を実施または実行する手段を有する装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してデータ管理に関し、より具体的にはオンデマンドサービス環境におけるメッセージキューのためのオークションに基づくリソース共有を容易にするメカニズムに関する。
【背景技術】
【０００２】
大規模なクラウドプラットフォームベンダやサービス提供者は、数百万という非同期のリソース集中的な顧客要求を毎日受信し、こうした要求は、サービス提供者に対して非常に面倒なリソース割り当て及びスケーラビリティ要件を生み出す。従来手法のいずれもが、こうした要求への応答におけるいかなるリアルタイム性保証も提供しないため、大抵の顧客は、自身の要求が満たされるのを待つうちに失望する。さらに、マルチテナンシーは、複数のユーザが限られたリソースプールのために競合することを意味し、顧客期待と調和する態様におけるリソースの適切なスケジューリングを確保することをさらにいっそう複雑にする。
【０００３】
アプリケーションサーバスレッド時間などの配信リソースのポイントを種々のタイプのメッセージの間で公正に配布することは、特にマルチテナントオンデマンドシステムにおいて、挑戦であった。メッセージとは、アプリケーションサーバ上で実行される作業の単位をさす。メッセージは、任意の数のタイプにグループ化されてよく、例えばおおよそ３００タイプであってよく、ダッシュボード上の報告をリフレッシュするなどのユーザ対面作業から、使用されていないファイルを削除するなどの内部作業までに及んでよい。こうしたものとして、メッセージは、スレッド時間を含め、メッセージが消費するリソースの量において、広範なばらつきを示す。このことは、長く実行されるメッセージによる枯渇につながる可能性があり、長く実行されるメッセージは、短いメッセージがその公平な共有分のスレッド時間を受け取ることを奪う。このことが、ダッシュボードなどの顧客対面作業に影響する場合、顧客は、パフォーマンス低下に面したときに嫌がり、不満を言う可能性が高い。
【０００４】
背景セクションにおいて論じられた対象事項は、単にその言及が背景セクションにあることの結果として先行技術であると仮定されるべきではない。同様にして、背景セクションにおいて又は背景セクションの対象事項に関連付けられて言及される問題は、先行技術においてこれまでに認識されていると仮定されるべきではない。背景セクションに論じられる対象事項は、種々のアプローチを単に表す。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来のデータベースシステムにおいて、ユーザは、１つの論理データベースの中の自身のデータリソースにアクセスする。こうした従来システムのユーザは、通常、ユーザの独自システムを使用して、上記システムからデータを読み出し、上記システムにデータを記憶する。ユーザシステムは複数のサーバシステムのうち１つに遠隔からアクセスすることがあり、このサーバシステムが今度はデータベースシステムにアクセスすることがある。システムからのデータ読み出しには、ユーザシステムからデータベースシステムへのクエリの発行を含むことがある。データベースシステムは、クエリにおいて受信した情報の要求を処理し、要求に関連する情報をユーザシステムに送信することがある。正確な情報の安全かつ効率的な読み出しと、ユーザシステムへのこの情報の後続の配信とが、データベースシステムの管理者の目標であったし、あり続ける。不幸なことに、従来のデータベースアプローチは、様々な制限に関連付けられる。
【課題を解決するための手段】
【０００６】
本願実施形態に従い、オンデマンドサービス環境において一実施形態に従ってユーザメッセージのためのスレッドリソースのオークションに基づく公平な割り当て及び使用を容易にするメカニズム及び方法が提供される。一実施形態において、例として、方法が、ネットワークを通じて複数の組織からジョブ要求及び入札を受信するステップであり、各ジョブ要求とその対応する入札とは、ネットワークを通じてコンピューティング装置においてユーザインタフェースを介して、マルチテナントデータベースシステム内でリソース通貨値を有する組織に関連付けられたユーザによって出される、ステップと、複数の組織に関する保留ジョブに関連付けられるリソース通貨値を特定するステップであり、リソース通貨値は、保留ジョブに対して専用にされるリソースに対応する、ステップと、専用にされておらず購入に利用可能なままであるリソースについて、上記の受信した入札のオークションを実行するステップであり、入札は、利用可能なリソースを購入するための購入要求を含む、ステップと、を含む。上記方法は、専用にされるリソースと利用可能なリソースのオークションとに基づいてジョブ要求の優先順位をつけるステップと、優先順位をつけられたジョブ要求に基づいてジョブ要求を処理するステップと、をさらに含んでもよい。
【０００７】
本発明は、オンデマンドサービス環境におけるデータの管理を容易にする手法が、複数のテナントをサポートする能力があるオンデマンドデータベースサービスのためのフロントエンドを提供するアプリケーションサーバを有するシステムにおいて実施される実施形態を参照して説明されるが、本発明は、マルチテナントデータベースにもアプリケーションサーバ上の配置にも制限されない。本願実施形態は、請求される本願実施形態の範囲から逸脱することなく他のデータベースアーキテクチャ、すなわちＯＲＡＣＬＥ（登録商標）、ＩＢＭのＤＢ２（登録商標）などを使用して実施されてもよい。
【０００８】
上記実施形態のうち任意のものが、単独で、あるいは任意の組み合わせにおいて互いに一緒に使用されてよい。本明細書に包含される実施形態には、本文献の概要又は要約において部分的にのみ言及され又は示唆され、あるいはまったく言及されず又は示唆されない実施形態も含み得る。本発明の様々な実施形態が従来技術と共に様々な欠陥によって動機付けされている可能性があり、このことは本明細書の１又は複数の箇所において論じられ又は示唆されている可能性があるが、本発明の実施形態は、必ずしも上記の欠陥のいずれかに対処するものではない。換言すると、本発明の種々の実施形態が、本明細書に論じられている可能性がある種々の欠陥に対処し得る。いくつかの実施形態は、本明細書に論じられている可能性があるいくつかの欠陥に又は１つの欠陥だけに部分的に対処することがあり、いくつかの実施形態は、上記の欠陥のいずれにも対処しないことがある。
【図面の簡単な説明】
【０００９】
下記の図面において、同様の参照番号は、同様の要素を示すように使用される。下記の図は様々な例を表すが、１又は複数の実施例が、図に表される例に限られない。
【図１】一実施形態に従う、スレッドリソース管理メカニズムを採用するコンピューティング装置を示す。
【図２】一実施形態に従う、スレッドリソース管理メカニズムを示す。
【図３】一実施形態に従う、図１のスレッドリソース管理メカニズムにより提供される、メッセージキューのためのスレッドリソースのオークションに基づく公平な割り当てを容易にするアーキテクチャを示す。
【図４Ａ】一実施形態に従う、ユーザメッセージのためのスレッドリソースのオークションに基づく公平な割り当て及び使用を容易にする方法を示す。
【図４Ｂ】一実施形態に従う、ユーザメッセージのためのスレッドリソースのオークションに基づく公平な割り当て及び使用を容易にするトランザクションシーケンスを示す。
【図４Ｃ】一実施形態に従う、ユーザメッセージのためのスレッドリソースのオークションに基づく公平な割り当て及び使用を容易にするトランザクションシーケンスを示す。
【図５】一実施形態に従うコンピュータシステムを示す。
【図６】一実施形態に従う、オンデマンドデータベースサービスが使用され得る環境を示す。
【図７】一実施形態に従う、図６の環境の要素とこれらの要素間の様々なとり得る相互接続とを示す。
【発明を実施するための形態】
【００１０】
オンデマンドサービス環境において、一実施形態に従い、ユーザメッセージのためのスレッドリソースのオークションに基づく公平な割り当て及び使用を容易にする方法及びシステムが提供される。一実施形態において例として、方法が、ネットワークを通じて複数の組織からジョブ要求及び入札を受信するステップであり、各ジョブ要求とその対応する入札とは、ネットワークを通じてコンピューティング装置においてユーザインタフェースを介して、マルチテナントデータベースシステム内でリソース通貨値を有する組織に関連付けられたユーザによって出される、ステップと、複数の組織に関する保留ジョブに関連付けられるリソース通貨値を特定するステップであり、リソース通貨値は、保留ジョブに対して専用にされる（dedicated）リソースに対応する、ステップと、専用にされておらず購入に利用可能なままであるリソースについて、上記の受信した入札のオークションを実行するステップであり、入札は、利用可能なリソースを購入するための購入要求を含む、ステップと、を含む。上記方法は、専用にされるリソースと利用可能なリソースのオークションとに基づいてジョブ要求の優先順位をつける（prioritizing）ステップと、優先順位をつけられたジョブ要求に基づいてジョブ要求を処理するステップと、をさらに含んでもよい。
【００１１】
大規模なクラウドプラットフォームベンダやサービス提供者は、数百万という非同期のリソース集中的な（resource-intensive）顧客要求を毎日受信し、こうした要求は、サービス提供者に対して非常に面倒なリソース割り当て及びスケーラビリティ要件を生み出す。さらに、マルチテナンシー（multi-tenancy）は、複数のユーザが限られたリソースプールのために競合することを意味し、顧客期待と調和する態様におけるリソースの適切なスケジューリングを確保することをさらにいっそう複雑にする。本願実施形態は、新規のスケジューリングフレームワークを有する新規のメカニズムを提供して、１）タスクのレイテンシに基づいて顧客要求を区別し、したがって、低レイテンシタスクは長く実行されるバックグラウンドタスクの後に実行され、２）ある顧客によって要求されるタスクがシステム全体を占有し、かつ他の顧客によって要求される他のタスクを枯渇させることがないように、タスクをそのリソース要件及び／又は顧客申し込みに基づいて分離する。本願実施形態は、リソースを効率的に利用して、コンテンションが高いときでさえ高いスループットを確保するメカニズムをさらに提供し、例えば、タスクがスケジュールされるのを待っている場合、いかなる利用可能なリソースもアイドルのままであることがない。
【００１２】
本願実施形態は、マルチテナント環境において公平かつ効率的なリソース割り当てを達成するようにオークションに基づくアプローチを可能にする。現在、マルチテナント環境における大抵のリソースは、各組織についての静的に定義された制限と共に測定フレームワークを使用して供給される。例えば、ある短い時間フレーム内で自身の固定数のアプリケーションプログラミングインタフェース（ＡＰＩ）要求を超える組織は、スロットル調整される（throttled）可能性がある。しかしながら、上記の制限を手動で指定することは、面倒な、間違いの元の処理になる可能性がある。こうした強固な制限は、リソースが十分に利用されないという非効率につながる可能性もある。代わって、本明細書に開示されるテクノロジーは、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍによる配置ポイント（Point  of  Deployment；ＰＯＤ）の割り当てを中心にして、オークションに基づく経済性を構築することができる。ＰＯＤとは、ホストマシンの集合をさしてよく、ホストマシンは、その提供者の顧客（例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍの顧客）のためのデータを記憶し、処理する。例えば、上記提供者に属する各々の物理的なデータセンターは、複数のＰＯＤを有してよく、各ＰＯＤは、独立して動作し、データベース、一群のワーカホスト、一群のキューホストなどで構成され、上記ＰＯＤに割り付けられた顧客の要求を果たすことができる。それから、組織からの競合する要求の数に依存して、本明細書に開示されるテクノロジーはリソースの価格を調整し、このリソースの価格が今度は各組織が受け取るリソースの量を特定する。
【００１３】
本願実施形態は、オークションに基づくアプローチを採用し、提供して、マルチテナント環境において公平かつ効率的なリソース割り当てを達成する。本願実施形態は、よりリッチなキューイングセマンティクス（queuing  semantics）を提供し、効率的なリソース利用を可能にする。本願実施形態は、自身の公平なリソースの共有分を超える顧客についてのパフォーマンス分離（performance  isolation）をさらに提供し、顧客負荷における変化に基づいてリソース割り当てを動的に調整することによって利用可能なリソースがアイドルのままでないことを確保する間に、配布型の（distributed）態様で決定を行うことによって数十万という顧客に対するスケーラビリティを容易にする。
【００１４】
本明細書において、用語のマルチテナントデータベースシステムは、データベースシステムのハードウェア及びソフトウェアの様々な要素が１又は複数の顧客によって共有され得るシステムをさす。例えば、所与のアプリケーションサーバが、多数の顧客のための要求を同時に処理することができ、所与のデータベーステーブルが、潜在的に非常に多数の顧客のための行を記憶することができる。本明細書において、用語のクエリプランは、データベースシステムの中の情報にアクセスすることに使用される一組のステップをさす。
【００１５】
本願実施形態は、オンデマンドサービス環境におけるデータの管理を容易にする手法が、複数のテナントをサポートする能力があるオンデマンドデータベースサービスのためのフロントエンドを提供するアプリケーションサーバを有するシステムにおいて実施される実施形態を参照して説明され、本願実施形態は、マルチテナントデータベースにもアプリケーションサーバ上の配置にも制限されない。本願実施形態は、請求される本願実施形態の範囲から逸脱することなく他のデータベースアーキテクチャ、すなわち、ＯＲＡＣＬＥ（登録商標）、ＩＢＭによるＤＢ２（登録商標）などを使用して実施されてもよい。本明細書に開示されるテクノロジーは、メッセージキューにおけるリソース供給のための新規のフレームワークを含み、このフレームワークは、競合する組織の間でのＰＯＤリソースのオークションに基づく公平な割り当てを提供することができる。上記アプローチは、データベース、コンピュータ、ディスク、ネットワーク帯域幅などのリソースの任意の単位（unit）に適用されてよい。上記アプローチは、マップリデュースタスクをスケジュールすることなどの他の領域に拡張されてもよい。
【００１６】
次に、オークションに基づくアプローチを採用し、提供して、オンデマンドサービス環境におけるマルチテナント環境において公平かつ効率的なリソース割り当てを達成するメカニズムを容易にするメカニズム及び方法が、例示的な実施形態を参照して説明される。
【００１７】
図１は、一実施形態に従う、スレッドリソース管理メカニズム１１０を採用するコンピューティング装置１００を示す。一実施形態において、コンピューティング装置１００は、スレッドリソースとそのトラッキング、割り当て、ルーティングなどを含む対応メッセージとの公平かつ効率的な管理を容易にするアプリケーションサーバスレッドリソースの動的管理を容易にするためのメッセージキューのスレッドリソース管理メカニズム（「リソースメカニズム」）１１０を採用するホストマシンとしての役割を果たして、システムリソースのより良い管理を提供し、ユーザ（例えば、会社、法人、組織、企業、機関、団体など）により通常所望され又は必要とされる様々なサービスのユーザ制御とカスタマイズとを促進する。ユーザとは、コンピューティング装置１００などのホストマシンにおいてリソースメカニズム１１０を提供し及び管理するサービス提供者（例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ）の顧客をさす。
【００１８】
コンピューティング装置１００には、サーバコンピュータ（例えば、クラウドサーバコンピュータなど）、デスクトップコンピュータ、クラスタベースのコンピュータ、セットトップボックス（例えば、インターネットベースのケーブルテレビジョンセットトップボックスなど）などを含んでよい。コンピューティング装置１００には、スマートフォン（例えば、Ａｐｐｌｅ（登録商標）のｉＰｈｏｎｅ（登録商標）、Ｒｅｓｅａｒｃｈ  ｉｎ  Ｍｏｔｉｏｎ（登録商標）のＢｌａｃｋＢｅｒｒｙ（登録商標）など）を含む携帯電話、ハンドヘルドコンピューティング装置、パーソナルデジタルアシスタント（ＰＤＡ）などのモバイルコンピューティング装置、タブレットコンピュータ（例えば、Ａｐｐｌｅ（登録商標）のｉＰａｄ（登録商標）、Ｓａｍｓｕｎｇ（登録商標）のＧａｌａｘｙ（登録商標）など）、ラップトップコンピュータ（例えば、ノートブック、ネットブック、ｕｌｔｒａｂｏｏｋＴＭなど）、電子リーダ（例えば、Ａｍａｚｏｎ．ｃｏｍ（登録商標）のＫｉｎｄｌｅ（登録商標）、Ｂａｒｎｅｓ  ａｎｄ  Ｎｏｂｌｅｓ（登録商標）のＮｏｏｋ（登録商標）など）、グローバルポジショニングシステム（ＧＰＳ）ベースのナビゲーションシステムなどの小型コンピュータを含んでもよい。
【００１９】
コンピューティング装置１００には、コンピューティング装置１００の任意のハードウェア又は物理リソースとユーザとの間のインタフェースの役割を果たすオペレーティングシステム（ＯＳ）１０６を含む。コンピューティング装置１００は、１又は複数のプロセッサ１０２、メモリ装置１０４、ネットワーク装置、ドライバなどと、タッチスクリーン、タッチパネル、タッチパッド、仮想又は通常のキーボード、仮想又は通常のマウスなどの入力／出力（Ｉ／Ｏ）ソース１０８とをさらに含む。「ノード」、「コンピューティングノード」、「クライアント」、「クライアント装置」、「サーバ」、「サーバ装置」、「クラウドコンピュータ」、「クラウドサーバ」、「クラウドサーバコンピュータ」、「マシン」、「ホストマシン」、「装置」、「コンピューティング装置」、「コンピュータ」、「コンピューティングシステム」、「マルチテナントオンデマンドデータシステム」などの用語は、本文献にわたって置き換え可能に使用され得ることが留意されるべきである。さらに、「アプリケーション」、「ソフトウェアアプリケーション」、「プログラム」、「ソフトウェアプログラム」、「パッケージ」及び「ソフトエアパッケージ」などの用語は、本文献にわたって置き換え可能に使用され得ることが留意されるべきである。さらに、「ジョブ」、「要求」及び「メッセージ」などの用語は、本文献にわたって置き換え可能に使用され得る。
【００２０】
図２は、一実施形態に従い、スレッドリソース管理メカニズム１１０を示す。一実施形態において、リソースメカニズム１１０は、メッセージキューのためのオークションに基づくリソース共有を提供して、配信のポイントにおける競合するメッセージタイプの間でのスレッドリソースのオークションに基づく公平な割り当てを容易にする。
【００２１】
例示される実施形態において、リソースメカニズム１１０は、要求受信及び認証ロジック２０２と解析部２０４と通信／アクセスロジック２０６と互換性ロジック２０８とを含む管理フレームワーク２００などの、様々なコンポーネントを含んでよい。リソースメカニズム１１０は、リソース割り当てロジック２１２とオークションに基づくリソース共有ロジック２３２と定数に基づくブローカヘルスロジック（quorum-based  broker  health  logic）２５２と作業負荷スケジューリングルーティングロジック２６２とスライディングウィンドウ維持ロジック２７２とを有する処理フレームワーク２１０などの、追加のコンポーネントをさらに含む。一実施形態において、オークションに基づくリソース共有ロジック２３２は、メッセージ及び入札受信モジュール２３４と、通貨発行部２３５と、通貨予約２４４と、強制（enforcement）モジュール２４６と、オークションに基づくジョブスケジューラ２４７と、ジョブ実行エンジン２４８と、残高確認モジュール２３８、算定モジュール２４０、評価及び能力モジュール２４２及びカウンタ２５０を含む決定ロジック２３６とを含んでよい。
【００２２】
特定の特徴を追加し、除去し、及び／又は向上させることを含む様々な実施形態を容易にするように、任意の数及びタイプのコンポーネントがリソースメカニズム１１０に追加され、かつ／あるいはリソースメカニズム１１０から除去されてよいと考えられる。リソースメカニズム１１０の理解を簡潔に、明確に及び簡易にするために、コンピューティング装置のコンポーネントなどの標準及び／又は既知のコンポーネントの多くが、ここでは示されず、あるいは論じられない。本願実施形態は、いかなる特定のテクノロジー、トポロジー、システム、アーキテクチャ及び／又は標準にも制限されず、任意の将来の変化を採用し、及びこれに適応するほど十分に動的であると考えられる。
【００２３】
いくつかの実施形態において、リソースメカニズム１１０は、メッセージングキューに関するデータ、メタデータ、テーブル、レポートなどを記憶するデータベース２８０と通信してよい。リソースメカニズム１１０は、さらに、ネットワーク２８５を通じてクライアントコンピューティング装置２９０などの任意の数及びタイプのクライアントコンピューティング装置と通信してよい。本文献にわたって、用語「ロジック」は、「フレームワーク」又は「コンポーネント」若しくは「モジュール」と置き換え可能に呼ばれてもよく、例として、ソフトウェア、ハードウェア、及び／又はファームウェアなどのソフトウェアとハードウェアとの任意の組み合わせを含んでよい。リソースメカニズム１１０を通して提供されるこのコンポーネントの組み合わせは、特定のデータプロダクト／ソフトウェアアプリケーション（例えば、ソーシャルウェブサイト、ビジネスウェブサイト、ワードプロセシング、スプレッドシート、データベースプロダクトなど）が、ユーザにより所望され又は必要とされるとおり、及びネットワーク２９０を通じてクライアントコンピューティング装置２９２におけるユーザインタフェース２９４を通して通信されるとおり、任意の数及びタイプのフォーマットで操作され、共有され、通信され、表示されることを容易にする。
【００２４】
ユーザには、管理ユーザ又はエンドユーザを含んでよいと考えらえる。管理ユーザには、システム管理者、ソフトウェア開発者、コンピュータプログラマなどの、承認され及び／又は訓練されたユーザを含んでよい。対照的に、エンドユーザは、ソフトウェアアプリケーション又はインターネットブラウザを介してなどでクライアントコンピューティング装置にアクセスすることができる任意のユーザであってよい。一実施形態において、ユーザは、クライアントコンピューティング装置２９０においてユーザインタフェース２９４を介して、ユーザにより所望され又は必要とされるとおりの特定のフォーマット（例えば、テーブル、スプレッドシートなど）で、データを操作し又は要求し、該データと任意の関連するメタデータとを見ることができる。ユーザの例には、これらに限られないが、サービス提供者（例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ）の組織的顧客（例えば、小企業及び大企業、会社、法人、学術団体、政府機関、非営利組織など）などの組織に関する顧客（例えば、エンドユーザ）又は従業員（例えば、管理ユーザ）を含んでよい。「ユーザ」、「顧客」、「組織」、「テナント」、「企業」、「会社」などの用語は、本文献にわたって置き換え可能に使用され得ることが留意されるべきである。
【００２５】
一実施形態において、リソースメカニズム１１０は、図１のコンピューティング装置１００などのサーバコンピューティングシステムにおいて採用されてよく、ネットワーク２８５などのネットワーク（例えば、クラウドベースのネットワーク、インターネットなど）を通じて、クライアントコンピューティング装置２９０などの１又は複数のクライアントコンピューティング装置と通信してよい。前述されたとおり、ユーザには、リソースメカニズム１１０へのアクセスを（クライアントコンピュータ２９０を介してなどで）提供する提供者（例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ）に対する顧客である会社、企業などの、組織又は組織的顧客を含んでよい。同様にして、ユーザには、組織／組織的顧客の顧客であって、別のクライアントコンピューティング装置を介してリソースメカニズム１１０にアクセスする個人又は小企業などをさらに含んでよい。クライアントコンピューティング装置２９０は、図１のコンピューティング装置１００と同一又は同様であってよく、モバイルコンピューティング装置（例えば、スマートフォン、タブレットコンピュータなど）又はより大型のコンピュータ（例えば、デスクトップコンピュータ、サーバコンピュータなど）を含んでよい。
【００２６】
一実施形態において、リソースメカニズム１１０は、アプリケーションサーバなどのシステムリソースの効率的な管理のためのメッセージルーティング及びキューの公平かつ効率的な管理を容易にし、より良い顧客サービスを提供し、ユーザは、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍのＣｈａｔｔｅｒ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）、ＬｉｎｋｅｄＩｎ（登録商標）などのソーシャル及びビジネスネットワーキングプロダクトを採用する任意の数及びタイプのソフトウェアアプリケーション（例えば、ウェブサイトなど）を通して提供されるユーザインタフェース２９４を介して、上記のサービスにアクセスすることができる。
【００２７】
一実施形態において、要求受信及び認証ロジック２０２は、クライアントコンピューティング装置２９０を介してネットワーク２８５を通じてユーザにより出された要求（例えば、文書印刷、文書移動、文書マージ、レポート実行、データ表示など）を受信することに使用されてよい。さらに、要求受信及び認証ロジック２０２は、受信した要求を認証すること、並びに、ユーザ（及び／又は、対応顧客）及び／又はユーザが要求を出すことを可能にされる前はコンピューティング装置２９０を認証することに使用されてもよい。認証処理は、いくつかの実施形態において、コンピューティング装置２９０がリソースメカニズム１１０へのアクセスを最初に可能にされたときに行われるワンタイム処理であってよく、あるいは、認証は、いくつかの実施形態において、要求がネットワーク２８５を介してクラウドベースのサーバコンピューティング装置におけるリソースメカニズム１１０において要求受信及び認証ロジック２０２によって受信されるたびに実行される繰り返しの処理であってよいと考えられる。
【００２８】
認証処理が終了すると、要求は、解析のために解析部２０４に送信され、解析の結果に基づいて、要求は、１又は複数のコンポーネント２１２、２３２、２５２、２６２、２７２とこれらのサブコンポーネント２３４‐２５０とによる適切な処理のために処理フレームワーク２１０に転送される。通信／アクセスロジック２０６は、リソースメカニズム１１０をホストするサーバコンピューティング装置とコンピュータ装置２９０及び他のクライアントコンピューティング装置（任意の数のユーザ／顧客によってアクセスされる能力がある）を含む他のコンピューティング装置と他のサーバコンピューティング装置との間の通信を容易にする。互換性ロジック２０８は、コンピューティング装置（例えば、コンピューティング装置２９０）とネットワーク（例えば、ネットワーク２８５）と任意の数及びタイプのソフトウェアパッケージ（例えば、ウェブサイト、ソーシャルネットワーキングサイトなど）との間の動的互換性を容易にする。
【００２９】
一実施形態において、リソースメカニズム１１０とそのオークションに基づくリソース共有ロジック２３２とは、オークションに基づくアプローチを可能にして、マルチテナント環境においてリソースの公平かつ効率的な割り当てを達成する。一実施形態において、本明細書に開示されるテクノロジーは、リソースについての自身の公平な共有分を超える組織を不利にすることによってパフォーマンス分離を提供して、リソースが公平に配布され（distributed）、アイドルのままでないことを確保する。割り当ては、競合する組織からのトラフィックにおける変化に基づいて動的に調整されてよい。さらに、このモデルは、意思決定が複数のオークションサーバにわたって配布されることを可能にすることによって、数十万の同時的な組織に対してスケール変更する（scales）。本明細書に開示されるテクノロジーは、供給の問題を解決するための一組のアルゴリズムとオークションに基づくリソース供給モデルとを提供する。上記テクノロジーは、組織間の公平性と作業負荷における変化に適応する効率的なリソース利用とサービスレベル保証をとらえるリッチなキューイングセマンティクスとオークション決定を配布し及びスケールアウトするメカニズムとを確保するための公平なマルチテナントスケジューリングを含む。
【００３０】
Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ（登録商標）などの大規模クラウドプラットフォームベンダは、数百万という非同期のリソース集中的な顧客要求を毎日サービスし、したがって、枯渇とリソース利用とは、継続するスケーラビリティに対する重要な挑戦である。顧客は、リアルタイム応答時間保証を必要としない上記の要求を待つことを厭わない。上記には、例えば、バックグラウンドタスクとして実行される軽量ダッシュボードタスクや長く実行されるＡｐｅｘ負荷要求を含む。さらに、マルチテナンシーは、複数のユーザがリソースの限られたプールのために競合する場合である。したがって、本願実施形態が提供する新規のテクノロジーにおいて、要求が顧客期待と調和する態様においてスケジュールされ及び実行されることを確保するように、追加的な配慮がとられる。具体的に、オークションに基づくジョブスケジューラ（「スケジューラ」）２４７が、低レイテンシタスクが長く実行されるバックグラウンドタスク未満で遅延されるように顧客要求を区別してよく、単一の顧客がシステム全体を占有し、かつ他の顧客を枯渇させることができないようにパフォーマンス分離を提供してよい。最後、スケジューラ２４７は、コンテンションが高いときでさえ高いスループットを確保するように効率的にリソースを利用することができ、すなわち、リソースは、タスクがスケジュールされるのを待っている場合にアイドルのままであることがない。
【００３１】
例えば、Ｏｒａｃｌｅ（登録商標）  Ａｄｖａｎｃｅｄ  Ｑｕｅｕｅ（“ＡＱ”）などの従来のキューは、枯渇とリソース利用とに関して、現在のメッセージキューフレームワークの柔軟性を制限する。さらに、ＡＱなどの上記のキューはマルチテナントを感知しないため、すべての顧客メッセージは単一のテーブルに記憶され、単一のテーブルから処理され、これにおいて、アプリケーションはキューの中の最初の数百のメッセージ（例えば、いくつかの場合、４００）をピークすることができる。このことは、一握りの顧客がその要求で最初の数百のメッセージをあふれさせ、残りの顧客を枯渇させ、極度の枯渇を引き起こす可能性があるため、パフォーマンス分離を複雑にする。さらに、よりリッチなキューイングセマンティクスを備えることは、従来の手法では困難であり、時に実行不可能であり、例えば、顧客ごとにメッセージタイプの優先順位をつけるなどである。現在のフレームワークにおける上記の制限に対処する１つのアプローチが、顧客に基づく同時的制限を導入して、各顧客が利用できるリソースの最大量を制限して、単一の顧客がすべての利用可能なリソースを使い果たすことを防止することができるようにすることである。これのトレードオフは、アイドルリソースであり、例えば、多くのアクティビティを有する一顧客に向かって作業負荷が非常に偏っている場合、他の顧客からの十分な要求がキューの中になくてすべての利用可能なリソースを使い果たしている可能性がある。
【００３２】
一実施形態において、リソースメカニズム１１０のオークションに基づくリソース共有ロジック２３２は、よりリッチなキューイングセマンティクスを提供し、かつ効率的なリソース利用を可能にするモデルを容易にする新規のテクノロジーを提供する。さらに、本明細書に開示されるテクノロジーは、マルチテナント環境において公平かつ効率的なリソース割り当てを達成するように、オークションに基づくアプローチを採用する。具体的に、本明細書に開示されるテクノロジーは、リソースについての自身の公平な共有分を超える顧客を不利にすることによってパフォーマンス分離を提供し、顧客負荷における変化に基づいて割り当てを動的に調整することによってリソースがアイドルのままでないことを確保する。本明細書に開示されるテクノロジーは、マルチテナント環境において配布型の態様で決定を行うことによって任意の数（数十万など）の同時的な顧客に対してスケール変更し、公平なマルチテナントスケジューリング、顧客に基づく割り当て、市場に基づくスロットル調整などのある一定の期待されるものを提供する。
【００３３】
公平なマルチテナントスケジューリング
いくつかの実施形態において、オークションに基づくリソース共有ロジック２３２は、マルチテナント環境に公平性の厳密な気付きを提供する。マルチテナント公平性は、個々の顧客要求の枯渇を単に防止するのではない。代わって、本明細書に開示されるテクノロジーは、公平であるリソース割り当ての期待されるレベルを定義し、スケジューリングの間、顧客に割り当てられるリソースが期待に合致することを確保する。本明細書に開示されるテクノロジーは、予め定義された期待からのずれを測定することによって公平性の評価を提供する。
【００３４】
顧客に基づく割り当て
本明細書に開示される実施形態は、顧客ごとのきめ細かいリソース割り当てをサポートする。一実施形態において、オークションに基づくリソース共有ロジック２３２は柔軟なポリシーを提供し、これにおいて、本明細書に開示されるテクノロジーは保守的なアプローチをとり、すべての顧客を等しく重み付けし、重要な顧客を区別することができ、例えば、サービス提供者にとっての申し込み者の数又は合計収益によって顧客を重み付けする。例えば、ランタイムにおいて、顧客は、自身の重み付けに比例してリソースを割り当てられてよく、したがって、重み付け合計のうち一定のパーセンテージ（例えば、５％）に貢献する顧客は、平均で、その貢献と同じ割合（fraction）のリソースを受け取ることができる。
【００３５】
市場に基づくスロットル調整
本願実施形態は、リソースメカニズム１１０のオークションに基づくリソース共有ロジック２３２によって、顧客における仮想通貨を資金提供し（fund）、管理して、公平性を確保する。具体的に、要求をまれに提出する（submit）顧客は報われ、長く実行されるバッチ指向のタスクを連続的に提出する顧客はある時間にわたり不利にされる。
【００３６】
効率的なリソース利用
本願実施形態は、リソースメカニズム１１０のオークションに基づくリソース共有ロジック２３２によって、顧客ごとの効率的なリソース利用を容易にする。
【００３７】
適応的なリソース割り当て
一実施形態において、オークションに基づくリソース共有ロジック２３２は、保留している要求とリソースの量とからのリソースの競合などのシステム負荷における変化に基づいて、各顧客に割り当てられるリソースの量を動的に調整する。このことは、割り当てが公平なままであり、個々の顧客を枯渇させないことを確保する。さらに、静的な同時的な制限に頼るのではなく、本明細書に開示されるテクノロジーは、リソースがアイドルのままでないように特定の顧客に対して割り当てを増加させることによって、システム負荷に動的に適応する。
【００３８】
よりリッチなキューイングセマンティクス
本願実施形態は、顧客ごとのメッセージに基づく優先順位又は顧客ごとのサービスレベル保証を容易にし、上記の目標に向かう。一実施形態において、組織が、より高い金銭値を有するなどのより高い又は上等の入札を出して、利用可能なリソースからある量の追加のリソースを購入することできる。例えば、様々な組織により高い又は上等の入札を出すよう勧めるように、入札がその対応オークションサーバを通して様々な組織にブロードキャストされてよい。利用可能なリソースとは、保留しているジョブ要求のいずれに対してもまだ専用にされておらず、したがって最も高い入札者が取るべく利用可能なままであるリソースをさす。利用可能なリソースを入札者に割り当てることに加えて、ジョブ要求のサイズも考慮に入れられる。例えば、より多くの量のリソースを必要とする大きいサイズのものは、引き受けられなくてよく、かつ／あるいは上等の入札が受理されることを必要としてよい。同様にして、保留しているジョブ要求が、すべての専用にされたリソースを使用することなく完了された場合、専用にされたリソースの残りの部分は、自身のジョブを早く終了した組織が別のジョブ要求のためにそのリソースを使用できてもよく、あるいはリソースを明け渡して入札に利用できるようにしてもよい。
【００３９】
本願実施形態は、（１）メッセージに基づく優先順位、（２）顧客要求の可変価格設定、（３）サービス保証の厳格な品質、及び（４）対処される研究課題を提供する。メッセージに基づく優先順位に関して、本願実施形態は、（１）一実施形態において、オークションに基づくリソース共有ロジック２３２が、決定ロジック２３６を採用して、２段階のスケジューリングスキームを採用することにより顧客と要求タイプとの双方を考慮に入れることによって、リソース割り当て決定を実行する。例えば、配布型のオークションに基づくプロトコルが実行されて、サービスに対して各顧客からのメッセージの数を決定する。顧客の要求がデキューされるとき、きめ細かい選択処理が、決定ロジック２３６の様々なコンポーネント２３８‐２４４によって容易にされ、顧客の要求のうちどれを次に評価するかをユーザ指定のポリシーに基づいて選定する。これらのポリシーは、ローカルであってもよく、例えば顧客ごとの要求タイプによる優先順位などであり、あるいはグローバルであってもよく、例えばすべての顧客にわたる特定の要求タイプによるレート制限などである。
【００４０】
顧客要求の可変価格設定に関して、本願実施形態は、さらに、（２）強制モジュール２４６を使用して、顧客が自身の要求が迅速に処理されることを確保するためにより多く支払うことを厭わないことを示すことによって、顧客が自身のメッセージの価値を区別できるようにする。同様にして、顧客は、レイテンシの影響を受けないメッセージについて、自身の入札を下げることができる。クライアント側において、顧客は、ユーザインタフェース２９４を介してシステムに単にアクセスし、例えば、自身がリソースのためにいくら支払うことを厭わないかを特定する価格設定係数を動的に調整することによって、上記を達成することができる。
【００４１】
サービス保証の厳格な品質に関して、本願実施形態は、（３）サービス保証の厳格な品質を提供する。いくつかのアプリケーションは、完了時間に関して厳格なリアルタイム性の制約を有するため、オークションに基づくリソース共有ロジック２３２は、こうしたアプリケーションのために一部のリソースの動的割り当てを可能にする有用な特徴を提供し、これにより、顧客は、所与の時間にわたり処理できる要求の数についての下限などの、最小レベルのサービスを予約することができる。
【００４２】
様々な研究課題に関して、本願実施形態は、（４）対処される研究課題を提供し、これには、既存の義務のサービスレベル保証に合わないいかなる新しい予約も拒絶する能力を有する堅牢な受け入れポリシーを含み、予約が使用されていない場合にリソースがアイドルのままでないことを確保し、顧客が最小割合のリソースを予約すること及び自身が支払う価格を市場に特定させることを可能にする。
【００４３】
配布及びスケール変更
決定ロジック２３６により行われるリソース割り当て決定は、迅速（例えば、小さいオーバヘッド）でスケーラブルである（例えば、並列に配布され、評価される）ように設計される。一実施形態において、通貨予約２４４は、各カスタマがどれほどのリソース通貨を通貨予約２４４に有するかの残高を維持する。通貨予約２４４は、残高確認モジュール２３８によってアクセスされ、評価のために算定モジュール２４０によって所望され又は必要とされるとおりに算定されてよい。キャパシティモジュール２４２は、各顧客に関してその対応する要求がエンキューされたときに収集され又は集約されたリソース通貨情報に基づいて、各顧客のリソースキャパシティを特定することに使用される。この情報は、それから、区分され、強制モジュール２４０を使用して複数のアプリケーション又はオークションサーバに配布されてよい。
【００４４】
一実施形態において、複数のサーバコンピューティングシステム（例えば、アプリケーションサーバ）が、リソースメカニズム１１０をホストするサーバコンピューティングシステムと通信するよう置かれてよく、あるいは、別の実施形態において、複数のアプリケーションサーバが、リソースメカニズム１１０のすべて又はオークションに基づくリソースロジック２３２などの一部を各々ホストしてオークションに基づく意思決定能力を有して、一組の顧客のための役割を果たし、責任を負い、この一組の顧客のうちの各顧客に割り当てるべきリソースの量を決定してよい。したがって、いくつかの実施形態において、顧客の数が増えるとき、本明細書に開示されるテクノロジーは、オークションサーバの役割を果たすさらなる追加のアプリケーションサーバにわたって（水平に）スケール変更されてよい。
【００４５】
顧客固有の有用性メトリック
顧客にとって、要求を完了させる価値は、時間に応じてしばしば変化する。例えば、業界アナリストは、可能な限り速く会社収益報告を理想的には受け取りたいであろうし、報告の価値は、後になって届けられる場合、時間と共に落ちる。したがって、要求の有用性又は顧客査定を正確にとらえることで、システムは、最も高い価値を顧客に届けるタスクを可能な限り速く完了することに、より多くのリソースを充てることができるようになる。顧客は、単一の厳格な期限から、より精巧な、線形、指数、区分的などの減衰関数に及ぶ様々な方法で、自身の有用性関数を指定することを選ぶことができる。一実施形態において、ユーザは、適切かつ効率的な処理のために自身の要求に値を割り付ける能力を供与されてよい。別の実施形態において、通貨予約２４４におけるデータと決定ロジック２３６が利用可能な他の情報（例えば、要求又は顧客履歴など）とが、ユーザ要求に値を自動的に割り付けることに使用されてよく、各要求に値を割り付けるという負担からユーザを解放することができる。
【００４６】
コンテキスト感知スケジューリング
リソース制約された環境において、スケジューラ２４７は、同じディスク、ネットワーク、データベースリソースなどのために争う複数の要求をスケジュールすることを、回避することができる。一実施形態において、スケジューリングにおけるリソースバリアが低減されて、並列性を増加させ、リソース利用を向上させる。例えば、複数のディスク集中的な要求が保留されている場合、決定ロジック２３６は、中央処理ユニット（ＣＰＵ）が重くなる要求を最初選択して、アイドルＣＰＵ時間を低減することができる。このことを達成する一方法は、相互排他スケジューリングなどと同様にグラフモデルにおいて要求のリソース要件をとらえることを含み、最も少ない衝突、例えば共有リソースを争うバリアを用いて要求を選定する。
【００４７】
パフォーマンスメトリクス
一実施形態において、決定ロジック２３６は、一組の標準化されたパフォーマンスメトリクスを使用して、ベンチマークを含む様々なキューイングアルゴリズムを評価し、比較してよい。例えば、値のメトリクスには、顧客が自身の理想の割り当てに比例するサービスを受けているなどの公平性、効率性（例えば、システムスループット、及びリソースがアイドルのままである時間の量）、応答時間（例えば、エンキューとデキューとの間の、要求のための最大又は平均の待ち時間）などを含んでよい。
【００４８】
オークションに基づく手法
一実施形態において、オークションに基づくリソースロジック２３２は、マルチテナント環境におけるメッセージキュースレッドのオークションに基づく割り当てを容易にし、ユーザが同じリソースに対して種々の入札を出すことを可能にする。例えば、デフォルトで、すべての顧客は、消費されるリソースの単位ごとに同じ価格を課金されてよいが、可変価格設定が、顧客がリソースについての自身の真の査定を明らかにするのを確保し、リソースを維持し及び節約するのに役立つ。例えば、リソースクレジット（resource  credits）が、顧客がリソースを購入することに使用できる（通貨予約２４４に記憶された）仮想通貨とみなされてよい。例えば、クレジットは、購入できるリソースの単位の観点で見られてよく、例えば、１０００クレジットが、単一のＭＱスレッドにおける時間の１０００秒、又は１０個のＭＱスレッド各々における１００秒に換算されるなどする。
【００４９】
通貨予約２４４に記憶されるこうした通貨クレジットは、決定ロジック２３６及び強制モジュール２４６によっていくつかの方法で採用され、使用されてよく、例えば、クレジットは、顧客に基づくリソース供給を強制する（enforce）ことに使用されてよく、これにおいて、顧客があるパーセンテージ（例えば、２０％）の合計未決済クレジットを所持する場合、この顧客は、最小で、リソース合計のうち上記パーセンテージ、例えば２０％を受け取ってよい。これは、最小限とみなされる。他の顧客がいかなる要求も提出しないことを選ぶことができ、より多くのリソースが利用可能なままになるからである。クレジットは、いくらかの顧客をレート制限することによって公平性を強制することに使用されてもよい。具体的に、継続的に要求を提出し、キューをあふれさせる顧客は、より速いレートでクレジットを消耗する可能性が高い。一方、要求をまれにエンキューする顧客は、自身が実行させるとき、より大きい割合のリソースを受け取ってよい。さらに、これらのクレジットは初期化において割り付けられ、これにおいて、クレジットの数は、例えば、クレジット資金提供ポリシー（例えば、外部からの資金提供クレジット、又は資金が補充される頻度についてのオプション）に従って顧客に割り当てられる。
【００５０】
リソース割り当てのアトミックな単位は、単一のＭＱスレッドにおける実行時間の１単位とみなされてよい。例えば、リソースは、ワーカホスト上でマシンにより時間定義され（machine-timed）てよく、これにおいて、リソース割り当てのアトミックな単位は、単一のワーカホスト上で費やされるマシン時間の１単位であってよい。ＭＱスレッドの観点でリソースを称することは、全体のシステムリソース利用についての良い近似である。しかしながら、一実施形態において、ＣＰＵリソース、データベースリソース、ディスクリソース又はネットワークリソースなどのさらにきめ細かい供給が採用される。メッセージ又はジョブは、顧客に関連付けられたユーザがキューに提出する個々のタスクとみなされる。各メッセージに関連付けられるのはコストであってよく、コストは、所与のメッセージを評価するのに必要とされるリソースの単位を表してよく、これは、メッセージがＭＱスレッド上で実行される時間（例えば、秒数）の代理とみられてよい。さらに、様々な文字が顧客入札処理に関連付けられてよく、例えば、“Ｏ”は入札を提出する顧客を表し、“Ｃ”はクレジットの量を表し、“Ｍ”は顧客からのすべてのメッセージの合計コストを表し、“Ｎ”は顧客からの別個のメッセージの合計数を表すなどである。クレジットは、顧客が予約することができるリソースの量をとらえることができ、すべてのメッセージの合計コストは、顧客が実際に必要とするリソースをとらえることができる。合計メッセージコストを追跡するために、メッセージがエンキューされ、ＭＱからデキューされるときに、保留メッセージの実行カウンタが顧客ごとに更新されてよい。例えば、デキューされ、実行される各メッセージについて、顧客から消耗されるクレジットの数は、メッセージコストに比例してよい。メッセージコストが実行時間の代理であるため、いかなる軽量メッセージも、いかなる長く実行されるメッセージ、バッチ指向メッセージなどより少なく課金されてよい。
【００５１】
任意の価格設定形態が顧客に対して採用されてよく、本願実施形態はいかなる特定の価格設定形態にも限られず、あるいは依存しないことが考えられる。一実施形態において、価格設定が均一に保持され、したがって消費されるリソースの単位ごとに各顧客が同数のクレジットを支払うように、均一の価格設定が導入されてよい。別の実施形態において、顧客が自身のメッセージの重要度を区別し、それに応じて値／入札を設定できるように、可変価格設定を指定することが導入されてよい。こうした入札は、顧客の残りのクレジットの量に対する新しいメッセージの到着レートに基づいて、明示的に（例えば、メッセージがエンキューされたときに顧客によって供給され、あるいは暗黙的に）取得されてよい。
【００５２】
供給手法
一実施形態において、評価及び能力モジュール２４２が、オークションに基づくフレームワークを提供して、顧客入札を評価して、公平かつ効率的な態様でリソースを割り当てる。一実施形態において、決定スケールが、オークションサーバの役割を果たす複数のアプリケーションサーバにわたって供給されてよく、顧客ごとにメッセージタイプによってサービスレベル保証を提供するアプローチを探求することができる。
【００５３】
割り当てシナリオ
本明細書に開示されるテクノロジーは、最初、３の顧客（Ｏ１、Ｏ２及びＯ３）を含む例を使用してマルチテナントリソース割り当てにおける様々な検討を例示することができる。簡潔さのため、本明細書に開示されるテクノロジーは、各メッセージが完了するのに正確にＭＱスレッドごとに１単位の実行時間を必要とする単一のメッセージタイプを有することができる。例えば、メッセージごとにリソースの１単位のコストである。本明細書に開示されるテクノロジーは、１０００クレジットを用いてシステムを初期化することができ、これにおいて、本明細書に開示されるテクノロジーが顧客Ｏ１、Ｏ２及びＯ３に割り付けることができる量は、それぞれ、７００、２００及び１００であり、したがって、顧客Ｏ１は、平均で、リソースの７０％を受け取ることができる。
【００５４】
高コンテンション
例えば、スケジューラ２４７は、すべてのＭＱスレッドにわたって利用可能な１００単位の実行時間を有し、例えば、２５個のＭＱスレッドごとに４単位の実行時間である。さらに、キューの初期状態は高コンテンションであり、これにおいて、すべての顧客は、そのリソース割り当てを使い果たすのに十分なメッセージを有し、対応する入札は、下記のとおりであってよい：＜Ｏ１，７００，３００，３００＞、＜Ｏ２，２００，４２，４２＞及び＜Ｏ３，１００，１２，１２＞。メッセージごとにリソースの１単位のコストが存在し得るため、メッセージの数とメッセージの合計コストとは、顧客ごとに同一である。
【００５５】
本例において、一実施形態において、割り当て公平性は、クレジットの量に基づいてよい。より多くのクレジットを有する顧客は、顧客がより高いレートでメッセージをエンキューする大きな組織であること、又は、顧客がメッセージをまれに提出し、自身が提出するときに高い割り当てを受け取れることを示し得る。一実施形態において、決定ロジック２３６は、通貨予約２４４におけるクレジットを、公平性の代理として使用してよい。すなわち、大口顧客はより高いリソース割り当てを当初受けることができ、自身のクレジットが消耗するときにその割り当てが徐々に低減する可能性があり、したがって、平均で、顧客が受け取るリソースの量は、自身が当初割り付けられたクレジットの数に比例し得る。上記の例を続けると、当初割り付けられたクレジットの数に基づいて、評価及び能力モジュールは、強制モジュール２４６に、７０単位の実行時間をＯ１に、２０単位の実行時間をＯ２に、及び１０単位の実行時間をＯ３に割り当てるように促してよい。したがって、顧客Ｏ１、Ｏ２及びＯ３からの７０、２０及び１０のメッセージが処理され、同等数のクレジットが各顧客から差し引かれる。
【００５６】
中コンテンション
追加の１００単位の実行時間が利用可能にされると、各顧客は、メッセージ及びクレジットの残数に基づいて、下記の改訂された入札を提出する：＜Ｏ１，６３０，２３０，２３０＞、＜Ｏ２，１８０，２２，２２＞及び＜Ｏ３，９０，２，２＞。この場合、コンテンションは、顧客Ｏ３が１０単位の実行時間という自身の割り当てを使い果たすほど十分なメッセージを有していないため、中間である。したがって、アイドルＭＱスレッドをもたらすことになるＯ３へのリソースの過剰割り当てを防止するために、２単位が割り当てられる。残りの９８単位の実行時間は、Ｏ１及びＯ２が有する残りのクレジットの数に比例してＯ１とＯ２とに割り当てられてよく、これはおよそ、Ｏ１とＯ２とに対して、それぞれ、７６単位と２２単位とになる。
【００５７】
低コンテンション
上記の次の回の割り当てにおいて、顧客Ｏ２及びＯ３からのメッセージは使い果たされているため、顧客Ｏ１が入札を提出する：＜Ｏ１，５５４，１５４，１５４＞。他の顧客からのコンテンションがないため、Ｏ１は割り当ての共有分全体を受け取り、したがってＭＱスレッドのいずれもアイドルのままではなくなる。上記の３つのシナリオは、コンテンションが高いとき、リソースは、顧客に割り付けられたクレジットの数に基づいて比例的に配布できることを例示する。コンテンションが低いとき、リソースは、アクティブな顧客の間で十分にかつ比例的に割り当てられて、ＭＱスレッドがアイドルのままでないことを確保する。
【００５８】
入札評価
一実施形態において、評価及び能力モジュール２４２は、様々な顧客からの入札を評価して前述のスケジューリングストラテジを実施し、例えば、Ｒ単位の所与のリソース（例えば、スレッド又はデータベース接続のプール）を割り当て、オークションサーバＡに上記リソースを顧客Ｏ１に割り当てる責任を負わせる。同様にして、顧客は先に説明されたフォーマットを使用して入札を含むベクトルを提出することができ、これにおいて、Ｃｓｕｍは、すべての顧客からの合計残クレジット又はＣ１＋．．．＋Ｃｎとして定義されてよい。さらに、オークションサーバは、最初、各顧客を通して繰り返し、顧客Ｏｉが購入したいであろうリソースの実際数を説明する入札ｂ（ｉ）を計算してよい。これは、デフォルトで、エンキューされる顧客からのすべてのメッセージの合計コストである。しかしながら、顧客は、自身のメッセージのすべてを満たすために必要とされるリソースを取得するほど十分なクレジットを有さないことがあり、顧客Ｏｉの入札は、ｂ（ｉ）＝ｍｉｎ｛Ｍ（Ｏｉ），Ｃｉ＊Ｒ／Ｃｓｕｍ｝として定義されてよい。
【００５９】
Ｍ（Ｏｉ）は、Ｏｉからのメッセージの合計コストをとらえ、Ｃｉ＊Ｒ／Ｃｓｕｍは、現在の割り当てＲのうちＯｉが自身の残クレジットに基づいて予約することができる期待量を説明する。それから、オークションサーバはすべての顧客からの入札を総計し、これはｂ（ｓｕｍ）として表される。最後、顧客Ｏｉに割り当てられるリソースの実際量が、ｒ（ｉ）＝ｍｉｎ｛Ｍ（Ｏｉ），ｂ（ｉ）＊Ｒ／ｂ（ｓｕｍ）｝として計算され、ここで、Ｍ（Ｏｉ）は、顧客が必要とするよりも多いリソースの割り当てを防止する。オークションに基づくリソースロジック２３２によって強制される入札評価アルゴリズムは、各顧客が、利用可能合計リソースのうちこれらが割り付けられたクレジットの量に比例する割合を平均で消費する点で、公平である。さらに、オークションに基づくリソースロジック２３２は、割り付けられるリソースの割合をシステム負荷に基づいて動的に調整するので、リソースを効率的に利用する。例えば、ｂ（ｉ）は、Ｏｉからのメッセージの実コストに応じる。
【００６０】
最適性
本願実施形態は小部分（fractional）メッセージのための最適性を提供し、これにおいて、本願実施形態は、Ｏｉに割り当てられたリソースを超えた場合、Ｏｉからのメッセージの実行を阻止することができる。小部分メッセージ処理について、最適性は、小部分ナップザック問題に対応づけることによって示すことができる。ここで、最適性とは、割り当てられたリソースの量が期待に合致することを意味する。例えば、クレジットが顧客Ｏｉに割り当てられた場合、本明細書に開示されるテクノロジーは、Ｃｉ＊Ｒ／Ｃｓｕｍ単位のリソースがＯｉに割り当てられると期待することができる。しかしながら、Ｏｉにより提出されるメッセージの合計数（Ｍ（Ｏｉ））が上記の量より少ない場合、評価及び能力モジュール２４２はＭ（Ｏｉ）単位だけのリソースを割り当てることができ、小部分メッセージについて、ｒ（ｉ）＝ｍｉｎ｛Ｍ（Ｏｉ），Ｃｉ＊Ｒ／Ｃｓｕｍ｝のリソースがＯｉに割り当てられる。
【００６１】
配布型の入札評価
前述されたとおり、複数のアプリケーションサーバが採用されてオークションサーバの役割を果たしてよく、この場合、複数のオークションサーバは、オークションが数十万の顧客に対してスケール変更できるようにその入札を並列で評価してよい。配布型の入札評価を可能にするために、追加のネットワークラウンドトリップが、複数のオークションサーバ間で入札情報を配布することに使用されてよい。具体的に、一実施形態において、個々のオークションサーバが一組の顧客を割り付けられて、該サーバ上でローカルの入札を計算する。これにおいて、ローカルの入札は、それから、各サーバがグローバルに最適な割り当て決定に達することができるように、複数のオークションサーバ間で配布される。
【００６２】
例えば、当初、ｋ台のオークションサーバＡ１乃至Ａｋが採用されてよく、これにおいて、各オークションサーバは、合計利用可能リソースＲのサブセットを顧客のサブセットに割り当てることの責任を負う。サーバＡｉが、その顧客にＲｉを割り当てることの責任を負ってよく、ここでＲ＝Ｒ１＋．．．＋Ｒｋであり、顧客は、オークションサーバ間で等しく区分されることができる（例えば、入札ベクトルが固定サイズであるため、負荷の偏りは大きい懸念事項ではない）。グローバルに最適な割り当てに達するために、各オークションサーバは、最初、自体が割り付けられた顧客のサブセットから入札を収集する。それから、オークションサーバは、顧客ごとの個々の入札ｂ（ｉ）を、先に説明されたとおりに（ＲとＣｓｕｍとのグローバル値を使用して）計算する。次いで、各サーバは、そのローカルの顧客のサブセットからの入札を総計し、これにおいて、ｂｉ（ｓｕｍ）は、オークションサーバＡｉからの顧客入札の総計を表す。ローカルの総計は、この決定に参加しているすべてのオークションサーバにブロードキャストされる。収集されると、各オークションサーバは、自体がその顧客に割り当てることの責任を負うリソースの割合を計算する：Ｒｉ＝ｂｉ（ｓｕｍ）＊Ｒ／（ｂ１（ｓｕｍ）＋．．．＋ｂｋ（ｓｕｍ））。
【００６３】
さらに、各オークションサーバＡｉは、その顧客のサブセットについて、Ｒｉとローカルに計算されたＣｓｕｍとを使用して、先に説明された入札評価アルゴリズムを実行する。例えば、オークションサーバ間で中間の入札値を配布するためのいくらかの追加のネットワークラウンドトリップのコストは、キューサイズと合計残クレジットとに関するグローバルの総統計を使用してＲ１，．．．，Ｒｋの合理的に良好な近似を達成することによって、完全に除去することができる。
【００６４】
可変価格設定
いくつかの例において、顧客は、自身のメッセージが迅速に処理されるのを確保するために、より多くのクレジットを費やすのを厭わないことがある。例えば、顧客は、メッセージをまれに提出し、結果として大量の残クレジットを累積する場合がある。顧客は、一群のレイテンシの影響を受けるメッセージに割り当てられるリソースの量を、一時的に強化したい場合がある。一実施形態において、顧客は、価格設定レートｐを指定することによってリソースの査定を区別することが可能にされてよい。レートｐは、顧客が、例えば、自身のメッセージがレイテンシの影響を受けないときにクレジットが消費されるレートを減少させることを可能にし、あるいは、自身がより速いレートでクレジットを費やす余裕があるときに割り当てられるリソースの量を強化することを可能にする。
【００６５】
ｐの値が０＜ｐ＜１であるとき、顧客は、消費されるリソースの単位ごとに、１クレジットの標準レートよりも少なく支払う。ｐ＞１について、顧客は、リソースを過大評価し、標準レートをいくつかの係数上回って支払うことを厭わない。例えば、ｐ（ｉ）を顧客Ｏｉのレートとすると、ｐ（ｉ）は下記のとおり顧客の入札に影響する：ｂ（ｉ）＝ｍｉｎ｛Ｍ（Ｏｉ），Ｃｉ＊Ｒ＊ｐ（ｉ）／Ｃｓｕｍ，Ｃｉ／ｐ（ｉ）｝。Ｃｉ＊Ｒ＊ｐ（ｉ）／Ｃｓｕｍは、顧客が自身の残クレジットに対して受け取るリソースの割合を低減し又は強化することを可能にし、例えば、ｐ（ｉ）＞１の場合、顧客は、自身のメッセージを処理するためにリソースの単位ごとに過剰に支払うことを厭わない。最後、Ｃｉ／ｐ（ｉ）は、ｐ（ｉ）と残クレジットとに基づいてＯｉが予約することができるリソースの最大量の境界を示す。これは、残高確認モジュール２３８による確認を確立して、ほとんどクレジットを有さない顧客が自身が買う余裕があるよりも多くのリソースを予約することを防止する。さらに、他の顧客からのシステムコンテンション又は競合が、顧客が入札処理の間にどれほどのリソースを実際に受け取るかを決定づけることがあり、このことは、先の例から高コンテンションシナリオと低コンテンションシナリオとの双方について例示することができる。
【００６６】
高コンテンション
先の例から下記の高コンテンションシナリオを検討する。例えば、価格設定係数ｐ（ｉ）が、顧客ごとに入札ベクトルの終わりに添えられ、これにおいて、顧客Ｏ２は、リソースのために標準レートの３倍を支払うことを厭わない：＜Ｏ１，７００，３００，３００，１＞、＜Ｏ２，２００，４２，４２，３＞及び＜Ｏ３，１００，１２，１２，１＞。これらの入札は、各顧客についてそれぞれ下記のｂ（ｉ）になる：７０、４２及び１０（例えば、顧客Ｏ２の入札が２０から４２に増加したことに留意する）。今度は、リソースが下記の比率で顧客に割り当てられる：５７（Ｏ１）、３５（Ｏ２）及び８（Ｏ３）。顧客Ｏ２は、自身のメッセージの大半を単一の回で完了することができ、しかし、他の顧客よりもかなり速いレートでクレジットを消耗する。最初の回の後、各顧客からの残クレジット及びメッセージの数は、下記のとおり示される：顧客Ｏ１に２４３メッセージと６４３（７００−５７）残クレジット、Ｏ２に７メッセージと１２６（２００−３５＊２．１）残クレジット、及びＯ３に４メッセージと９２（１００−８）残クレジット。
【００６７】
顧客Ｏ２に対して課金される実際の価格設定係数は、３とは対照的に２．１であることにさらに留意する。これは、Ｏ２が３という係数まで自身の入札を増加させた場合、実際の入札が６０になることになるからである。しかしながら、オークションに基づくリソースロジック２３２の評価及び能力モジュール２４２は、Ｍ（Ｏｉ）とＣｉ＊Ｒ＊ｐ（ｉ）／Ｃｓｕｍとの最小を使用して、Ｏ２が実際に必要とするよりも多くのリソースをＯ２に割り当てることを防止し、したがってＯ２は、その許容される最大入札よりも少ないリソースを割り付けられる。さらに、一実施形態において、評価及び能力モジュール２４２は、価格設定を下方へ遡及的に調整して、Ｏ２が３５単位のリソース（例えば、Ｏ２が実際に消費したもの）を取得するために提出しなければならなかったｐ（ｉ）の実際の価格設定レートを反映する能力を有し、改訂されたｐ（ｉ）は、ｐ（ｉ）＝ｂ（ｉ）＊Ｃｓｕｍ／（Ｃｉ＊Ｒ）である。上記の式について解くと、（（４２＊１０００）／（２００＊１００））が２．１の価格設定レートをもたらし、このことは、Ｏ２が、自身が実際に消費した３５単位のリソースを取得するために標準レートの２．１倍を入札することが必要とされることを意味する。
【００６８】
低コンテンション
次に、Ｏ１のメッセージがキューに残っている先の例からの低コンテンションを検討する。顧客のメッセージがレイテンシの影響を受けない場合、顧客は、自身の価格設定係数を低減して後のために自身のクレジットを節約してもよい。コンテンションが高いとき、顧客は、より小さい割合のリソースを受け取ることがあるが、コンテンションが低いとき、顧客は、自身のクレジットをかなりゆっくりしたレートで消耗して同一量のリソースを予約することができる。Ｏ１からの下記の入札を検討する：＜Ｏ１，５５４，１５４，１５４，０．５＞。この入札は、Ｏ１が、受け取る２単位のリソースごとに１クレジットを支払うことを厭わないことを示す。しかしながら、Ｏ１が入札している顧客であるため、Ｏ１は割り当ての全共有分を受け取る。結局、Ｏ１は、５０４クレジット（５５４−１００＊０．５）と共にキューに残る５４メッセージを有すると期待される。
【００６９】
サービス保証
例えば、レイテンシの影響を受けるアプリケーションを有するいくらかの顧客は、ある割合のリソースを予約して最小レベルのサービスを確保したい場合がある。このことは、例えば、顧客が固定割合を指定することを可能にすることによって達成することができ、これにおいて、自身が支払いたい価格設定係数ｐ（ｉ）は、入札処理の間に市場によって特定されてよい。入札処理は、オークションに基づくリソース共有ロジック２３２によって実行されてよく、これにおいて、サービスレベル保証を必要としない顧客が入札を提出することがあり、それから、こうした入札が、特定割合の利用可能なリソースを予約したい顧客のために入札量を計算することに使用される。２回目の入札フェーズが完了すると、グローバルリソース割り当て決定が、決定ロジック２３６によって行われる。例えば、ｐ（ｉ）に加えて、各顧客の入札ベクトルに添えられるのは、顧客所望のリソースの予約ｆ（ｉ）であり、ここでｆ（ｉ）は、顧客が取得したいリソースの割合をとらえる。
【００７０】
顧客は、ｐ（ｉ）又はｆ（ｉ）のいずれかを指定するが、双方を指定しなくてもよく、これは、価格設定と予約とが互いに二重性があるからであることに留意する。例えば、価格を固定することは、顧客がどれほどのリソースを予約することができるかを特定し、予約を固定することは、顧客がどれほど支払うかを特定する：＜Ｏ１，７００，３００，３００，１＞、＜Ｏ２，２００，４２，４２，３５％＞及び＜Ｏ３，１００，１２，１２，１＞。さらに、顧客Ｏ１及びＯ３はその価格設定ｐ（ｉ）を１に固定し、Ｏ２はその所望の予約を利用可能リソースの３５％に固定していることに留意する。アイドルリソースを防止するために、決定ロジック２３６は、キューに保留しているＯ２からのメッセージの数だけ予約することを決定し、例えば、Ｏ２がキューに１０メッセージを有する場合、対応するエントリを介して、通貨予約２４４に、リソースの１０％が予約されてよく、こうしたことが記録されてよい。
【００７１】
最初の入札フェーズにおいて、オークションサーバは、その対応するすべての顧客からの予約の合計量を集計する。この場合、Ｏ２はリソースの３５％（又は３５単位）を予約し、これがＲｆで表され、ここで、残りの顧客のために残されたリソースは、Ｒｐ（Ｒ−Ｒｆ）で表されてよい。したがって、一実施形態において、顧客は、２つのクラスに区分されてよい：１）Ｒｐリソースのベストエフォート型割り当てに満足する顧客、及び、２）特定量のリソースＲｆを予約したい顧客。一実施形態において、決定ロジック２３６の算定モジュール２４０がベストエフォート型顧客の各々のための入札を計算してよく、これはｂｐ（ｓｕｍ）（例えば、ベストエフォート型グループの入札の総計）に総計される。特定割合のリソースを予約するために、顧客は、その値がｂ（ｓｕｍ）のうち同じ割合である入札を提出してよく、ここで、ｂｆ（ｓｕｍ）は、Ｏ２が提出する入札であり（未知のもの）、この入札は、Ｒｆリソースを予約することができるように下記の割合を満たす：ｂｆ（ｓｕｍ）／（ｂｆ（ｓｕｍ）＋ｂｐ（ｓｕｍ））＝Ｒｆ／Ｒ。上記式におけるｂｆ（ｓｕｍ）について解くと、ｂｆ（ｓｕｍ）＝（Ｒｆ＊ｂｐ（ｓｕｍ））／（Ｒ−Ｒｆ）がもたらされる。
【００７２】
配布型の予約
予約を複雑にする複数のオークションサーバ間でのリソース割り当て決定を配布することに由来し得るいかなる予約の複雑性も防止するために、各オークションサーバは、追加のネットワークラウンドトリップを招くことなく追加のスカラー値をブロードキャストするように設定されてよい。ｋ台のオークションサーバＡ１，．．．，Ａｋにおける配布型のオークションについて、各オークションサーバＡｉがローカルの入札値の総計ｂｉ（ｓｕｍ）を計算し、これをすべての他のオークションサーバにブロードキャストすることを思い起こされたい。今度は、各サーバＡｉは、すべての入札値を通じてグローバルの総計を計算し、自体が顧客に割り当てることができるリソースの量Ｒｉを特定する。
【００７３】
予約を用いて、オークションサーバは、ある最小割合のリソースを必要とする顧客を割り付けられてよく、これにおいて、顧客の入札は、当初、未知である。オークションサーバＡｉに割り付けられた顧客により予約されたリソースの量をＲｆｉで表すこととし、リソースを予約しておらずベストエフォート型スケジューリングを必要とし得る顧客からの入札の総計をｂｐｉ（ｓｕｍ）で表すこととする。したがって、Ａｉは、下記のローカルのベクトルをすべての他のオークションサーバにブロードキャストしてよい：＜Ｒｆｉ，ｂｐｉ（ｓｕｍ）＞。ローカルのベクトルが収集されると、各オークションサーバは、リソースを予約しているその対応するすべての顧客からの入札のグローバルの合計を下記のとおり計算してよい：ｂｆ（ｓｕｍ）＝（（Ｒｆ１＋．．．＋Ｒｆｋ）＊（ｂｐ１（ｓｕｍ）＋．．．＋ｂｐｋ（ｓｕｍ）））／（Ｒ−（Ｒｆｌ＋．．．＋Ｒｆｋ））。Ｒｆ１＋．．．＋Ｒｆｋは予約されるリソースの合計量を表し、ｂｐ１（ｓｕｍ）＋．．．＋ｂｐｋ（ｓｕｍ）はすべてのベストエフォート型顧客からの入札の総計を表す。それから、この情報を使用して、各オークションサーバＡｉは、リソースを予約している該サーバの顧客の各々のための入札量を計算することができる。供給セクションにおいて、顧客に割り当てられるリソースの量は顧客の入札に直接比例し得ることが言及されたことを思い起こされたい。顧客Ｏｉがｒ（ｉ）リソースを予約したと仮定すると、その入札量は：ｂ（ｉ）＝ｒ（ｉ）＊（ｂｐ（ｓｕｍ）＋ｂｆ（ｓｕｍ））／Ｒとして計算される。
【００７４】
前述のとおり、一実施形態において、各オークションサーバは、リソースメカニズム１１０のコンポーネントの任意の数及び組み合わせを採用するよう個々に装備されて、本文献にわたって論じられる様々な処理を実行する。別の実施形態において、サーバコンピューティング装置が、リソースメカニズム１１０を採用して処理のすべてを実行し、あるいは場合により、処理の大部分を実行すると同時にサーバコンピューティング装置と通信する様々なオークションサーバに処理の残りを選択的に委託する。
【００７５】
例を具体的にするために、２台のオークションサーバがグローバルに最適な決定に達する高コンテンションシナリオを考えることとし、顧客Ｏ１、Ｏ２、Ｏ３が下記の入札ベクトルを提出することとする：＜Ｏ１，７００，３００，３００，１＞、＜Ｏ２，２００，４２，４２，３５％＞及び＜Ｏ３，１００，１２，１２，１＞。例えば、一実施形態において、入札処理は、２台のオークションサーバにわたってスケール変更されてよく、これにおいてＡ１はＯ１及びＯ２の責任を負い、Ａ２はＯ３の責任を負う。Ｏ２及びＯ３の入札値は未知であって、配布型の態様で後から計算されてよい。ここで、各オークションサーバは、最初、下記のローカルのベクトルを計算し、ブロードキャストしてよい（これにおいて、予約されるリソースの量Ｒｆｉの後に、ローカルの入札の総計ｂｐｉ（ｓｕｍ）が続く）：Ａｌ：＜３５，７０＞及びＡ２：＜１２，０＞。次いで、各オークションサーバは、リソースを予約したすべての顧客（例えば、Ｏ２及びＯ３）からの入札の総計を計算する：ｂｆ（ｓｕｍ）＝（（Ｒｆ１＋Ｒｆ２）＊（ｂｐ１（ｓｕｍ）＋ｂｐ２（ｓｕｍ）））/（Ｒ−Ｒｆ１−Ｒｆ２）＝（（３５＋１２）＊（７０＋０））／（１００−３５−１２）＝６２。最後、続いて、サーバＡ１は、Ｏ２が利用可能なリソースの３５％を予約するために提出することができる入札を計算する：ｂ（２）＝ｒ（２）＊（ｂｐ（ｓｕｍ）＋ｂｆ（ｓｕｍ））／Ｒ＝３５＊（７０＋６２）／１００＝４６．２。同様にして、Ａ２は、Ｏ３のための入札を１５．８と計算する。これらの入札は、単一のオークションサーバで決定ロジック２３６によって決定されたであろう値に合致する。
【００７６】
資金提供ポリシー及びスロットル調整
一実施形態において、オークションに基づくリソース共有ロジック２３２は、決定ロジック２３６によって意思決定を容易にする手法をさらに提供して、１）顧客が継続的にクレジットへの資金を受け取り、リソースを購入する方法、及び、２）要求をまれに提出する「行儀のよい」顧客に報いることとキューをあふれさせる顧客を不利にすることとの間で継続的にバランスをとること、に対処する。
【００７７】
クレジット資金提供頻度及び量
一実施形態において、決定ロジック２３６が、顧客クレジットがどのように補充されるかを対処し、特定することに使用されてよく、続いて、強制モジュール２４６が、決定ロジック２３６により達成されたクレジット決定を強制することに使用されてよい。顧客クレジットがどのように補充されるかには、１）ソース、２）量、及び３）頻度などの様々なコンポーネントを包含してよい。例えば、ソースコンポーネントは、クレジットがどのように始められるかに取り組み、これにおいて、自然なオプションは、クレジットが外部のソースを通して顧客によって増加的に資金提供されることができるところのオープンな市場に基づくシステムを実施することであり、例えば、お金が顧客のアカウントに追加される。このことは、メッセージを処理する動作コストにクレジットを直接マップすること及びこれに応じて使用に基づいて顧客に課金することを可能にする。オープンシステムはさらに、顧客が自身が大量の低レイテンシメッセージを見込むときに資金を追加することができるメッセージ処理を通じて、より卓越した制御を顧客に提供する。しかしながら、アカウンティングの複雑性及びコストを下げるために、代替手段及びアプローチには、クレジットが連続的に内部的に資金提供されるクローズドシステムを含む。本願実施形態は、クローズドのクレジット／アカウンティングシステム及びオープンなクレジット／アカウンティングシステムの双方と任意の他の利用可能なクレジット／アカウンティングシステムとをサポートするが、理解の簡潔さ及び容易さのために、残りの議論について、クローズドシステムが仮定され、論じられる。
【００７８】
量コンポーネントには、各顧客に供給するクレジットの初期量を含んでよく、これにおいて、クレジットの量は、顧客がクレジットを１日以内に消耗しそうにないように十分に多くすることができる。さらに、クレジットが各顧客に割り付けられるように、クレジット全体のうちのある割合が検討されてよく、これにおいて、ｆｅ（ｉ）は、他の顧客に対して顧客Ｏｉに割り付けることができるリソースのうち期待される公平な割合を表し、この割合は、いくつかの方法で、例えば申し込み者の数（収益）、顧客データのサイズ（使用）などによって、算定モジュール２４０によって計算することができる。申し込み者とデータサイズとの双方は、公平性の良い近似であり、これにおいて、Ｃｉを顧客Ｏｉに与えられるクレジットの初期量とし、Ｃｓｕｍはすべての顧客に与えられるクレジットの総計を表す。このようなものとして、下記の式が、決定ロジック２３６によって使用されてよく、リソースが正しく割り当てられることの確保を持続することができる：ｆｅ（ｉ）＝Ｃｉ／Ｃｓｕｍ。
【００７９】
さらに、頻度コンポーネントが、顧客が継続的にリソースのために入札できることを確保するようにクレジットが補充されるところと考えられ、供給アルゴリズムがある時間にわたる公平性変化の定義のとおりに割り当て決定を調整することを可能にする。顧客クレジットが補充されるレートは、利用可能なリソースの量に比例させられてよい。例えば、リソース割り当ての単位は、例えば、スレッドごとに１秒の実行時間とされ、３０個のＭＱスレッドは、この次の５分間などの時間、利用可能であると期待されてよい。
【００８０】
上記の例を続けると、１８００クレジット（３０＊６０単位のリソース）が、５分間、顧客に分ごとに配布されてよい。配布される１８００クレジットのうち、顧客Ｏｉが受け取る量はｆｅ（ｉ）に比例してよく、例えば、本明細書に開示されるテクノロジーが、Ｏｉの公平な割り当てがｆｅ（ｉ）＝０．３であると期待することができる場合、Ｏｉは、５４０の追加のクレジットを毎分受け取る。クレジットの補充は、リソースが利用可能であるが顧客がクレジットの不足に起因して自身のメッセージを実行することができないときに、始動されてもよい。キュー上のすべてのメッセージが単一の顧客に属し、この顧客がクレジットの自身の共有分を既に消耗しているという極端な例を検討する。この場合、クレジットの比例的な配布が、リソースがアイドルのままでないようにすべての顧客に対して始動される。
【００８１】
さらに、決定ロジック２３６が、スレッドリソースの割り当てにおける公平性を維持するようにある時間にわたりクレジットの配布をインテリジェントに微調整してよい。例えば、自身の申し込みを終了している顧客、又は自身の申し込みをある時間にわたり徐々に増加させる顧客を検討する。様々な理由で、リソース割り当て決定は変化することがあり、任意の余剰クレジットが残りの顧客の間で再配布されることができる。クレジットの配布を微調整するために、一実施形態において、公平割合ｆｅ（ｉ）は、顧客ごとに手動で又は自動的に使用されてよい（例えば、終了した顧客のクレジットの、１又は複数の残りの顧客への、比例的な態様における再配布など）。理解の簡潔さ及び容易さのために、本文献の残りにわたって、任意の新しいクレジットが、顧客Ｏｉに配布されてよく、更新されたｆｅ（ｉ）に比例してよく、ある時間にわたり、複数の顧客間でのクレジットの配布は、各顧客Ｏｉに割り当てることを期待され得るリソースの割合ｆｅ（ｉ）を反映してよい。
【００８２】
ヘビーユーザとまれなユーザとのバランス
メッセージでキューを連続的にあふれさせるヘビーユーザとメッセージをまれに提出する「行儀の良い」顧客とにおけるバランスをとることに関して、ある大きい割合の利用可能なリソースを消費する長く実行されるメッセージを連続的に提出する顧客は、自身のクレジットをより速いレートで消耗することがある。このことは、一実施形態において、顧客を不利にすることがある。割り当てられるリソースの割合が、消耗されるクレジットと共に減少し、こうした顧客は、長く実行されるメッセージをスケジュールするほど十分なクレジットを有さないことがあるからである。反対に、一実施形態において、メッセージをまれに提出する顧客は、ＭＱリソースを節約することについて、報われることがある。こうした顧客は多くのクレジット予約を累積することができ、したがって、自身がメッセージを提出するとき、供給アルゴリズムにより決定づけられるとおり、より大きい割合のリソースを受け取ることができる。
【００８３】
こうした２つのグループの顧客について、前述の不利益と報いとのバランスをとるために、決定ロジック２３６の算定モジュール２４０は、上限及び借入資金提供ポリシーを採用してよく、したがって、余剰キャパシティが利用可能である場合、急速なレートでクレジットを消耗する顧客が、クレジットを借り入れてメッセージをスケジュールすることができ得る。発生する借り入れについて、２つの条件が満たされる必要があってよい：１）入札処理の後に使用されていないリソースが存在することの判定、及び、２）いくらかの顧客が、自身の保留メッセージをスケジュールするほど十分なクレジットを有していない可能性があること。このことが発生したとき、決定ロジック２３６は、いくらか又はすべての顧客に対してクレジット配布の追加回を開始してよく（本文献のクレジット及び資金提供セクションにおいて説明されたとおり）、したがって、より多くのメッセージがスケジュールされることができ、利用可能なリソースがアイドルのままでなくなる。このことは、ＭＱリソースのコンテンションが高いとき、キューを連続的にあふれさせる顧客が不利にされる（例えば、自身のメッセージを実行するのにクレジットが不足する）ことを確保し、しかしＭＱリソースが豊富である場合、ヘビーユーザは、追加のクレジットを借り入れて自身のメッセージを実行し、さらなるシステムキャパシティを活用することが可能にされる。
【００８４】
ＭＱリソースを節約し、メッセージをまれに提出する顧客に報いるために、一実施形態において、決定ロジック２３６は、こうした顧客がいかなる使用されていないクレジットも累積することを可能にし、処理において、顧客が実行するときに割り当てられるリソースの割合（例えば、優先順位）を増加させる。しかしながら、顧客が一度に数週間非アクティブのままである場合、こうした顧客は多くのクレジット予約を累積することができ、こうした顧客がメッセージを提出するとき、入札処理を支配し、他の顧客を枯渇させる。例えば、一実施形態において、算定モジュール２４０は、任意の一顧客が累積することができるリソースの最大量の境界を示す上限を検討し、提案してよい。例えば、いかなる使用されていないクレジットも、資金提供された２４時間後に失効する。この手法は、自身の予算化された量のクレジットの範囲内にとどまる他の顧客を不公平に不利にすることなく、まれな顧客に報いる。前述の上限及び借入スキームは、手動の介入又は処理を必要とせず、本願実施形態は、顧客が自身のクレジットを非常に急速に消耗する場合に該顧客を不利にする態様で顧客作業負荷が適応される点において、オークションに基づくリソース共有ロジック２３２によって自動的に実行される条件及び借入スキームを提供することに留意すべきである。
【００８５】
入札頻度
作業負荷アクセスパターンは時間と共に急速に展開し、したがって、リソース割り当て決定は静的なままであることができず、これに応じて適応される。先の例において、顧客Ｏ１、Ｏ２及びＯ３が一回の入札を完了し、第４の顧客Ｏ４が自身のメッセージでキューを即座にあふれさせることを検討する。リソース割り当て決定は、Ｏ１、Ｏ２及びＯ３に割り当てられるリソースを低減することとこれらをＯ４に割り付けることとによってＯ４のメッセージを反映するように更新されてよい。さらに、更新は、リソース供給アルゴリズムを実行するオーバヘッドが複数のメッセージを通じて償却され、低いままであることを確保するように周期的に（例えば、新しい１０００メッセージの到着ごと、又は毎分）始動されてよく、公平なリソースの割り当てが、低い粒度レベルにおいても達成されることができる。
【００８６】
孤立（Orphaned）リソース：過剰割り当て及び過少割り当て
一実施形態において、オークションに基づくリソース共有ロジック２３２は、顧客に対するいかなる過剰割り当て及び過少割り当ても回避又は防止する手法を提供して、リソースの公平な割り当てを維持することができる。例えば、顧客の入札が、算定モジュール２４０によってｂ（ｉ）＝ｍｉｎ｛Ｍ（Ｏｉ），Ｃｉ＊Ｒ／Ｃｓｕｍ｝として算定されてよいことを思い起こされたい。顧客Ｏ１が自身の１０メッセージを処理するために必要とするリソースの正確な割合を予約する（例えば、１０％で予約する）ことによって、標準レートだけ支払うことが保証される。なぜならば、今度は、Ｏ１が自身が必要とするものを正確につかみ、かつ残りの９０単位のリソースがＯ２に割り当てられるので、新しい入札がより低くなることが保証されるからである。換言すると、Ｏ１の入札をＳＬＡ予約で書き換えることによって、リソースの過剰割り当てを防止する。
【００８７】
対照的に、リソースの過少割り当てを回避するために、孤立リソースが一緒にプールされ、ランダム化が採用されて、実行される顧客メッセージを選択してもよい。例えば、実行される顧客メッセージを選択するために、リソースがプールされてよく、ランダム処理が採用されてよい。これにおいて、リソースをプールすることは、より少ないクレジット又は長く実行されるメッセージを有する顧客が自身が単独で買う余裕がないメッセージを実行できることを可能にし、孤立リソースは、最大限に利用される。さらに、この手法を使用し、入力として上記を前提とすると、関数ＰｒｏｖｉｓｉｏｎＯｒｐｈａｎｅｄＲｅｓｏｕｒｃｅｓが、下記のとおり、顧客にリソースを割り当てることができる：ＰｒｏｖｉｓｉｏｎＯｒｐｈａｎｅｄＲｅｓｏｕｒｃｅｓ（Ｃｕｓｔｏｍｅｒｓ（Ｏ１−Ｏｎ），Ｐｒｏｂａｂｉｌｉｔｉｅｓ（ｐ（１）−ｐ（ｎ）），Ｒｏ）、ただしＲｏ＞０、ｅｘｉｓｔＭｅｓｓａｇｅ（Ｃｕｓｔｏｍｅｒｓ，Ｒｏ）、ＣｕｓｔｏｍｅｒｓからＣをランダムに選択する（Ｏｉは、確率ｐ（ｉ）を用いて選択される）、Ｍ＝ｇｅｔＮｅｘｔＭｅｓｓａｇｅ（Ｃ）、（Ｃｏｓｔ（Ｍ）＜Ｒｏ）の場合、Ｒｏ＝Ｒｏ−Ｃｏｓｔ（Ｍ）、ａｌｌｏｃａｔｅ（Ｃ）＝ａｌｌｏｃａｔｅ（Ｃ）＋ｃｏｓｔ（Ｍ）。この手法を使用すると、次の顧客が選定されたとき、各顧客Ｏｉは、選択される確率ｐ（ｉ）を有し（例えば、上記のＣ選択）、これにおいて、顧客の次メッセージが評価され（例えば、ｇｅｔＮｅｘｔＭｅｓｓａｇｅ）、メッセージがＲｏリソースより少ないリソースを利用する場合、リソースはＲｏから差し引かれ、顧客に割り当てられてよい。
【００８８】
メッセージコストの推定
一実施形態において、算定モジュール２４０は、メッセージコストを正確に推定して評価及び能力モジュール２４２を支援して、強制モジュール２４６により強制され、ジョブ実行エンジン２４８により処理されるとおり、正確なリソース割り当て決定を確保する。例えば、ＭＱに関して、このことは、各々のメッセージタイプと顧客との組み合わせについて、期待されるランタイムを迅速に特定することができることを意味し、例えば、一実施形態において、メッセージタイプと顧客との組み合わせごとにランタイム履歴を構築する既存のアプローチによってできることを意味し得る。それから、同じタイプのメッセージの推定が、前の実行に基づいて算定されてよい。別の実施形態において、マシン学習の適用が、メッセージタイプと現在のシステム状態とを説明するランタイム使用メタデータを推定することに適用されてよい。マシン学習スキームは前の実行からトレーニングデータを使用してよく、このデータはデータベース２８０から抽出することができる。しかしながら、算定モジュール２４０が十分なメッセージを経験したら、算定モジュール２４０は、新しいメッセージを同様のタイプのメッセージと比較することによって、合理的な正確さで新しいメッセージタイプを推定することができる。
【００８９】
マシン学習に有用である特徴は、システムに関連した特徴及びメッセージ固有の特徴に広範に分類されてよい。メッセージ固有の特徴には、ＣＰＵが重いかのメッセージ、データベース２８０を利用するかのメッセージ、メッセージにリソース制約フィルタが定義されているか、メッセージがどこで生成されたか、顧客のサイズはどれほどかなどを含んでよい。システム状態について、良い候補には、失敗した／リトライしたハンドラの数、キューにおける合計メッセージ、エンキューとデキューとのレート、競合する顧客の数、保持されるデータベース接続の数、ＣＰＵ、ディスク、ネットワーク、データベースなどのリソースの利用、クラスタにおけるキュープロセッサ及びスレーブスレッドの数、並びにＭＱ監視スレッドにより始動される信号などを含んでよい。
【００９０】
さらに、マシン学習は、アプリケーションサーバとデータベースＣＰＵとに設定されるリソース閾値に基づいてどのメッセージを次に実行するかを特定することに使用されてもよい。例えば、算定モジュール２４０は評価及び能力２４２と共に、通貨予約２４４によりデータベース２８０から抽出された情報を使用して、現在のシステム状態を所与としてメッセージのＣＰＵ利用を推定してよい。さらに、顧客は、メッセージがＣＰＵリソースを圧倒するのを防止すること、ＭＱアラートが高いリソース利用に起因して始動されるのを防止すること、及びメッセージスロットル調整ロジックを動かすことを可能にされることができ、例えば、ＣＰＵ使用によってメッセージをバケツでくむこと（bucketing）、マシン学習に対してラウンドロビン態様においてメッセージをスケジュールすることなどであり、これは、維持するのがより容易である。
【００９１】
メッセージに基づくキューイングポリシー
マルチテナンシーは、各顧客が他の顧客から別個に管理することができる顧客独自の仮想キューを有することを必要とすることがある。例えば、顧客は、顧客独自のキュー内でメッセージの優先順位をカスタマイズすることができてよい。一実施形態において、こうした要件に関連するいかなる潜在的な問題も防止するために、仮想キューが採用されてよく、オークションに基づくリソース共有ロジック２３２を使用して、仮想キューは顧客ごと及びメッセージタイプごとに提供されてよい。例えば、各顧客は一組の仮想キューを（例えば、メッセージタイプごとに１つ）受け取り、それから、この仮想キューを顧客が管理することができる。さらに、グローバルの、ＰＯＤ規模のキューイングポリシーが採用されてもよい。例えば、長く実行されるメッセージタイプがＭＱスレッドの大きい割合を占有し、後続のメッセージを枯渇させることを防止するために、レート制限ポリシーが採用されてよい。
【００９２】
一実施形態において、さらなるユーザに基づく制御が顧客に与えられてよく、ゆえに、顧客は、キューの状態を保留メッセージの数及び期待される待ち時間と共に見ることができる。さらに、顧客は、メッセージ優先順位を調整して特定のメッセージタイプをスピードアップし又はスロットル調整することが可能にされてよく、したがって、ベストエフォート型割り当てが、ユーザにより増加される顧客可視性とＭＱに関する制御とを与えることによって容易にされる。
【００９３】
メッセージタイプによる優先順位
メッセージタイプによる優先順位を維持するために、一実施形態において、カウンタ２５０が、決定ロジック２３６の一部として採用されて、メッセージタイプごとに各顧客についてキューの中のメッセージの数を追跡してよい。例えば、カウンタ２５０は、エンキュー及びデキューの間、顧客及びメッセージタイプの組み合わせごとにインクリメントし及び／又はデクリメントすることに使用されてよい。さらに、顧客は、カスタマイズされるメッセージ優先順位を与えられてもよく、したがって、２の顧客が、種々のメッセージタイプの相対的な重要度のための種々の順位付けを有することができる。顧客Ｏ１及びＯ２のための下記のキュー状態を検討する。これにおいて、クレジット／メッセージは、メッセージごとに必要とされるリソースの量を表す。各顧客は、メッセージタイプごとに優先順位を定義する優先順位選好を提供することができる。例えば、高優先順位メッセージは、より低い優先順位の低優先順位メッセージより前に処理されてよい。
【００９４】
一実施形態において、決定ロジック２３６は、顧客が粗いレベルでどれほどのリソースを利用するかに基づいて、２段階スケジューリングを使用して、顧客ごとにどのメッセージを実行するかを選んでよい。例えば、精細なレベルにおいて、キュー状態と顧客の優先順位選好とは、どのメッセージタイプを次に実行するかと各タイプのどれほどを次に実行するかとを顧客ごとに特定することにおいて考慮される。このことは、カウンタ２５０によって、リソースが使い果たされていない限り優先順位を減少させることと追加のメッセージをスケジューリングすることとを顧客のメッセージを通して繰り返すことによって達成される。メッセージタイプが、割り当てられるよりも多くのリソースを必要とする場合、カウンタ２５０は、割り振られた量のリソース内でスケジュールすることができる次のメッセージタイプまでスキップする。さらに、多数の低優先順位メッセージがそのリソース割り振りを使用してスケジュールされ、高優先順位メッセージがバイパスされて、顧客リソースが最大の態様で利用されアイドルのままでないことを確保してもよい。２つのメッセージタイプが同じ優先順位を有する場合、一実施形態において、この２つのメッセージのうち一方がラウンドロビン態様で選択されてよいことに留意する。
【００９５】
グローバルポリシー
同様にして、いくつかの実施形態において、グローバルのレート制限ポリシーが、メッセージの数及びタイプを限定するように採用されてよく、例えば、アプリケーション／オークションサーバＣＰＵ利用が例えば６５％を超える場合、ＣＰＵが重くなるメッセージがブロックされる。例えば、１）システム負荷における変化に基づいて特定のタイプのメッセージをブロックし又は許可すること、及び、２）所与のタイプのメッセージの数を限定する所定の同時的な制限、を含む２つのポリシー分類が存在し得る。前者のポリシー決定は、各オークションサーバに配布されて独立して適用されてよく、後者は、メッセージがデキューされるときに考慮され、ランタイムにおいて決定されてよい。一実施形態において、既存のデキューロジックは、グローバルのメッセージタイプに基づく同時的な制限を強制するために、オークションに基づくリソース共有ロジック２３２によって容易にされてよい。
【００９６】
新しいトランスポートのためのキューのスケーラビリティ
いくつかの実施形態において、リソースメカニズム１１０は、新しいトランスポートにおける組織に基づくキュー（例えば、組織ごとに１つのキュー）、メッセージ／クラスタに基づくキュー（例えば、メッセージタイプ又はデータベースノード組み合わせごとに１つのキュー）、組織／メッセージに基づくキュー（例えば、組織／メッセージタイプ組み合わせごとに１つのキュー）などをサポートする。クラスタ又はノード組み合わせとは、Ｏｒａｃｌｅ（登録商標）のＲｅａｌ  Ａｐｐｌｉｃａｔｉｏｎ  Ｃｌｕｓｔｅｒｓ（ＲＡＣ（登録商標））などの、複数のデータベースの統合（「データベースノード」又は単に「ノード」）をさす。ＲＡＣは、データベースをスケール変更するデータベーステクノロジーを提供することができ、これにおいて、ＲＡＣノードは、様々なワーカホストからのデータベースクエリを処理するデータベースコンピューティングホストを含んでよい。例えば、一実施形態において、新しいトランスポートが稼働中にサポートする必要があるであろう空でないクエリの数を、カウンタ２５０がカウントしてもよく、あるいは算定モジュール２４０が測定してもよい。さらに、１０メッセージより大きいキューの数が測定されて、いくつかのメッセージを有するキューを単一の物理的なキューに合体すること、及びオーバーヘッドを正当化するほど十分なメッセージが存在する場合に新しいトランスポートに新しい物理的なキューを供給することを容易にすることができる。さらに、組織に基づくキューのオーバヘッドは、（いくつかのメッセージを有する）特定の組織が同じ物理的なキューを共有することを可能にすることによって低減することができ、一実施形態において、キューは、１つの組織が非常に大きく成長した場合に分割されてもよく、あるいは、より少ないメッセージを有する他の組織と合体してもよい。
【００９７】
本明細書に開示されるテクノロジーの使用を例示する例は、限定又は優先とみなされるべきではない。上記の例は、開示されるテクノロジーを過度に複雑にすることなく十分に例示する。開示されるテクノロジーのすべてを例示することは意図されない。
【００９８】
当業者は、本願開示の１又は複数の実施例のための多くの潜在的な適用が存在することを十分理解するであろう。したがって、本明細書に開示される上記の実施例は、いかなる態様においても本願開示を限定するものではない。
【００９９】
図３は、一実施形態に従い、図１のスレッドリソース管理メカニズム１１０によって提供されるとおり、メッセージキューのためのスレッドリソースのオークションに基づく公平な割り当てを容易にするアーキテクチャ３００を例示する。理解の簡潔さ及び容易さのために、図２を参照して説明された処理及びコンポーネントの多くは、ここで図３において、あるいは後続の図のいずれに関しても繰り返されないことに留意されたい。例示される実施形態において、テナント３０２（例えば、顧客、顧客に関連付けられたユーザなど）は、クライアントコンピューティング装置を介して、保留メッセージ／ジョブと入札ベクトルとを、クライアントコンピューティング装置におけるユーザインタフェースを介してネットワークを通じて、例えば、図２のクライアントコンピューティング装置２９０のユーザインタフェース２９４を介してネットワーク２８５を通じて提出する。図２を参照して広く説明されたとおり、提出されたユーザジョブと入札ベクトルとは、これらが例示された実施形態のオークションに基づくジョブスケジューラ２４７によって扱われるよう提供される前に、図２のオークションに基づくリソース共有ロジック２３２によって処理される。
【０１００】
一実施形態において、通貨発行部２３５は、図２を参照して説明されたとおりのオークションに基づくリソース共有ロジック２３２の様々なコンポーネントによって実行される処理に基づいて、通貨予約２４４にテナント３０２のためのさらなるリソース通貨を発行し、あるいは資金提供してよい。テナント３０２のためのリソース通貨残高が、収集され、あるいは集められ、その適切な適用のためにスケジューラ２４７に提供される。こうしたリソース割り当て決定は、ジョブ実行エンジン２４８に転送され、それから、ジョブ実行エンジン２４８が、１又は複数のワークホスト３０４（例えば、サーバ又はコンピューティング装置）における実行のためにユーザ要求されたジョブを提出する。さらに、例示されたとおり、ジョブ実行エンジン２４８は、スケジューラ２４７と通信したままでワーカホスト３０４における利用可能なリソースキャパシティにアクセスしてもよい。
【０１０１】
図４Ａは、一実施形態に従う、ユーザメッセージのためのスレッドリソースのオークションに基づく公平な割り当て及び使用を容易にする方法４００を例示する。方法４００は、ハードウェア（例えば、回路、専用回路、プログラマブルロジックなど）、ソフトウェア（処理装置上で実行される命令など）又はこれらの組み合わせを含み得る処理ロジックによって実行されてよい。一実施形態において、方法４００は、図１のスレッドリソース管理メカニズム１１０によって実行されてよい。
【０１０２】
方法４００は、図２のオークションに基づくジョブスケジューラ２４７に関与するオークションに基づくジョブスケジューラトランザクションに関し、これを説明する。方法４００は、ブロック４０２において、テナント（例えば、顧客）から入札ベクトルと保留ジョブとを受信することから始まる。ブロック４０４において、残りの通貨の残高が、保留ジョブを有する各テナントから収集される。ブロック４０６において、特定のテナントが十分な資金を有するかに関して判定が行われる。そうでない場合、ブロック４０８において、十分な資金を有さないテナントについて、そのジョブの処理はブロックされる。そうである場合、ブロック４１０において、入札が各テナントについて算定されて、合計リソースのうち購入することができる割合を特定する。ブロック４１２において、ワーカホストのクラスタから利用可能なキャパシティが集められて、次のエポック（epoch）の間に各テナントに割り当てるワーカホストの数を特定する。エポックとは、時間期間又は時間間隔をさす。さらに、エポックは、オークションがどれほどの頻度で行われ若しくは実行され又は再実行されるかによって特定されてもよく、この場合、エポックとは、２の連続したオークション間の時間をさしてもよい。例えば、１０分のマークに達するごとにオークションを再実行してリソースが種々の顧客にどのように割り当てられるべきかを評価する機会が存在するように、エポックが１０分に予め定義され、設定されてよい。エポックは、各テナントの購入力によって、例えば、様々なテナントの利用可能な資金又は残りのクレジットを使用して特定されてもよく、エポックは、特定のジョブの実行に割り当てられてよい。ブロック４１４において、要求されたジョブは、図２のオークションに基づくリソース共有ロジック２３２によって説明されたとおり、リソース割り当て決定に基づいて実行のために提出される。
【０１０３】
図４Ｂは、一実施形態に従う、ユーザメッセージのためのスレッドリソースのオークションに基づく公平な割り当て及び使用を容易にするトランザクションシーケンス４２０を例示する。トランザクションシーケンス４２０は、ハードウェア（例えば、回路、専用回路、プログラマブルロジックなど）、ソフトウェア（処理装置上で実行される命令など）又はこれらの組み合わせを含み得る処理ロジックによって実行されてよい。一実施形態において、トランザクションシーケンス４２０は、図１のスレッドリソース管理メカニズム１１０によって実行されてよい。
【０１０４】
トランザクションシーケンス４２０は、図２のオークションに基づくジョブスケジューラ２４７に関与するオークションに基づくジョブスケジューラトランザクションに関し、これを説明する。一実施形態において、オークションサーバ４２２は、テナント３０２から入札ベクトル及び保留ジョブを受信する（４２４）。一方、残りのリソース通貨資金が、オークションサーバ４２２において、通貨サーバ２４４から収集される（４２６）。それから、入札が算定されて、オークションサーバ４２２における各テナントの購入力を特定し（４２８）、ワーカホストに関するいかなる利用可能なキャパシティもが、オークションサーバ４２２において、実行エンジン２４８から受信される（４３０）。
【０１０５】
一実施形態において、各テナントに関するいかなる保留ジョブ及びリソース割り当て決定もが、オークションサーバ４２２からジョブ実行エンジン２４８に送信される（４３２）。さらに、ジョブ実行エンジン２４８において、保留ジョブは、次のエポックの間の実行のために提出される（４３４）。通貨予約２４４において、エポックの間に完了したジョブに関するいかなる資金もが差し引かれ（４３６）、いかなるエポックの終わりにおける未完成のジョブ及び完了したジョブからの結果もが集められ、ジョブ実行エンジン２４８からテナント３０２に伝えられる（４３８）。
【０１０６】
図４Ｃは、一実施形態に従う、ユーザメッセージのためのスレッドリソースのオークションに基づく公平な割り当て及び使用を容易にするトランザクションシーケンス４４０を例示する。トランザクションシーケンス４４０は、ハードウェア（例えば、回路、専用回路、プログラマブルロジックなど）、ソフトウェア（処理装置上で実行される命令など）又はこれらの組み合わせを含み得る処理ロジックによって実行されてよい。一実施形態において、トランザクションシーケンス４４０は、図１のスレッドリソース管理メカニズム１１０によって実行されてよい。
【０１０７】
トランザクションシーケンス４４０は、図２のオークションに基づくジョブスケジューラ２４７に関与する配布型の入札を用いたオークションに基づくジョブスケジューラトランザクションに関し、これを説明する。例示される実施形態において、複数のオークションサーバ４４４が、その対応する複数のテナント（例えば、顧客）４４２から入札ベクトルとジョブとを受信する（４５４）。複数のオークションサーバ４４４の各々において、入札が、テナントのうちローカルのサブセットについて、算定される（４５６）。それから、ローカルの入札はすべてのオークションサーバ間にブロードキャストされ（４５８）、それから、各テナントの購入力がオークションサーバ４４４において算定される（４６０）。ワーカノードにおける利用可能なキャパシティが集められ、ジョブ実行エンジン２４８から複数のオークションサーバ４４４に伝えられ（４６２）、ジョブ及びリソース割り当て決定がオークションサーバ４４４からジョブ実行エンジン２４８に送信される（４６４）。ジョブ実行エンジン２４８において、ジョブは、エポックの間の実行のために提出され（４６６）、未完成のジョブと完了したジョブの結果とが集められ、ジョブ実行エンジンン２４８から複数のテナント４４２に伝えられる（４６８）。
【０１０８】
図５は、一実施形態に従う、コンピュータシステムの例示的な形態におけるマシン５００の図表現を例示し、これにおいて、本明細書に論じられる方法論のうち任意の１又は複数をマシン５００に実行させる命令セットが実行されてよい。マシン５００は、それぞれ、図１及び図２のコンピューティング装置１００及びコンピューティング装置２９０と同一又は同様である。別の実施形態において、マシンは、クラウドベースのネットワーク、ローカルリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、パーソナルエリアネットワーク（ＰＡＮ）、イントラネット、エクストラネット又はインターネットなどのネットワークの中の他のマシンに接続され（例えば、ネットワークでつながれ）てもよい（例えば、図１のホストマシン１００が図２のネットワーク２８５を通じてクライアントマシン２９０に接続される）。マシンは、クライアント‐サーバネットワーク環境におけるサーバ又はクライアントマシンのキャパシティにおいて、あるいはピアツーピア（又は分散型（distributed））ネットワーク環境におけるピアマシンとして、あるいはマルチテナントデータベースストレージサービスを提供するオンデマンド環境を含むオンデマンドサービス環境内で一サーバ若しくは一連のサーバとして動作してよい。マシンの特定の実施形態が、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、パーソナルデジタルアシスタント（ＰＤＡ）、セルラー電話、ウェブ電化製品、サーバ、ネットワークルータ若しくはスイッチ若しくはブリッジ、コンピューティングシステム、又はマシンが取るべきアクションを指定する命令セットを（順次又はその他の方法で）実行する能力がある任意のマシンの形態であってよい。さらに、単一のマシンだけが例示されているが、用語「マシン」は、一の（又は複数の）命令セットを個々に又は連帯して実行して本明細書に論じられる方法論のうち任意の１又は複数を実行するマシン（例えば、コンピュータ）の任意の集合を含むとみなされるものとする。
【０１０９】
例示的なコンピュータシステム５００は、プロセッサ５０２と、メインメモリ５０４（例えば、読取専用メモリ（ＲＯＭ）、フラッシュメモリ、同期型ＤＲＡＭ（ＳＤＲＡＭ）又はラムバスＤＲＡＭ（ＲＤＲＡＭ）などのダイナミックランダムアクセスメモリ（ＤＲＡＭ）、フラッシュメモリ、スタティックランダムアクセスメモリ（ＳＲＡＭ）、揮発性だが高データレートのＲＡＭなどのスタティックメモリ）と、二次メモリ５１８（例えば、ハードディスクドライブを含む永続的記憶装置、永続的マルチテナントデータベース実装）とを含み、これらはバス５３０を介して互いに通信する。メインメモリ５０４は、発せられる実行データ５２４（例えば、ロギングフレームワークによって発せられるデータ）と、本明細書に論じられる方法論を実行する処理ロジック５２６及びプロセッサ５０２と関連して動作する１又は複数のトレース選好５２３とを含む。
【０１１０】
プロセッサ５０２は、マイクロプロセッサ、中央処理ユニットなどの、１又は複数の汎用目的処理装置を表す。より具体的には、プロセッサ５０２は、複合命令セットコンピューティング（ＣＩＳＣ）マイクロプロセッサ、縮小命令セットコンピューティング（ＲＩＳＣ）マイクロプロセッサ、超長命令語（ＶＬＩＷ）マイクロプロセッサ、他の命令セットを実施するプロセッサ、又は命令セットの組み合わせを実施するプロセッサであってよい。プロセッサ５０２は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタルシグナルプロセッサ（ＤＳＰ）、ネットワークプロセッサなどの、１又は複数の特別目的処理装置であってもよい。プロセッサ５０２は、図１と本明細書に論じられる他の図とを参照して説明されるとおり、スレッドリソース管理メカニズム１１０の動作及び機能性を実行する処理ロジック５２６を実行するように構成される。
【０１１１】
コンピュータシステム５００は、ネットワークインタフェースカード５０８をさらに含んでよい。コンピュータシステム５００は、ユーザインタフェース５１０（ビデオディスプレイユニット、液晶ディスプレイ（ＬＣＤ）、又は陰極線管（ＣＲＴ）など）と、英数字入力装置５１２（例えば、キーボード）と、カーソル制御装置５１４（例えば、マウス）と、信号生成装置５１６（例えば、統合型スピーカ）とを含んでもよい。コンピュータシステム５００は、周辺装置５３６（例えば、無線又は有線の通信装置、メモリ装置、記憶装置、オーディオ処理装置、ビデオ処理装置など）をさらに含んでよい。コンピュータシステム５００は、サービスのための到来する要求を実行し、かつこうした到来する要求の実現に応答して実行データを発する能力があるハードウェアベースＡＰＩロギングフレームワーク５３４をさらに含んでよい。
【０１１２】
二次メモリ５１８は、マシン可読記憶媒体（又は、より具体的に、マシンアクセス可能記憶媒体）５３１を含んでよく、マシン可読媒体５３１上に、図１と本明細書に説明される他の図とを参照して説明されるとおりのスレッドリソース管理メカニズム１１０の方法論又は機能のうち任意の１又は複数を具現化する１又は複数の命令セット（例えば、ソフトウェア５２２）が記憶される。ソフトウェア５２２は、コンピュータシステム５００によるその実行の間、メインメモリ５０４内に及び／又はプロセッサ５０２内に、完全に又は少なくとも部分的に存在してもよく、メインメモリ５０４とプロセッサ５０２とがマシン可読記憶媒体を構成してもよい。ソフトウェア５２２はさらに、ネットワークインタフェースカード５０８を介してネットワーク５２０を通じて送信され、あるいは受信されてもよい。マシン可読記憶媒体５３１には、一時的又は非一時的なマシン可読記憶媒体を含んでよい。
【０１１３】
様々な実施形態の部分が、コンピュータプログラム製品として提供されてよく、これには、コンピュータプログラム命令を記憶させたマシン可読媒体を含んでよく、上記コンピュータプログラム命令は、コンピュータ（又は、他の電子装置）をプログラムして本願実施形態に従って処理を実行することに使用されてよい。マシン可読媒体は、これらに限られないが、フロッピーディスケット、光ディスク、コンパクトディスク読取専用メモリ（ＣＤ‐ＲＯＭ）、光磁気ディスク、ＲＯＭ、ＲＡＭ、消去可能プログラマブル読取専用メモリ（ＥＰＲＯＭ）、電気的ＥＰＲＯＭ（ＥＥＰＲＯＭ）、磁気若しくは光カード、フラッシュメモリ、又は電子的命令を記憶することに適した他のタイプの媒体／マシン可読媒体を含んでよい。
【０１１４】
図面に示される手法は、１又は複数の電子装置（例えば、終端局、ネットワーク要素）において記憶され及び実行されるコード及びデータを使用して実施されてよい。こうした電子装置は、非一時的コンピュータ可読記憶媒体（例えば、磁気ディスク、光ディスク、ランダムアクセスメモリ、読取専用メモリ、フラッシュメモリ装置、相変化メモリ）と一時的コンピュータ可読送信媒体（例えば、電子的、光学的、音響的又は他の形式の伝搬信号  ‐  例えば、搬送波、赤外線信号、デジタル信号など）となどのコンピュータ可読媒体を使用してコード及びデータを記憶し、通信する（内部的に、及び／又はネットワークを通じて他の電子装置と）。さらに、上記の電子装置は、１又は複数の記憶装置（非一時的マシン可読記憶媒体）とユーザ入力／出力装置（例えば、キーボード、タッチスクリーン及び／又はディスプレイ）とネットワーク接続となどの１又は複数の他のコンポーネントに結合された一組の１又は複数のプロセッサを通常含む。一組のプロセッサと他のコンポーネントとの結合は、通常、１又は複数のバス及びブリッジ（バスコントローラとも呼ばれる）による。したがって、所与の電子装置の記憶装置は、該電子装置の一組の１又は複数のプロセッサ上に実行のためのコード及び／又はデータを通常記憶する。当然ながら、一実施形態の１又は複数の部分が、ソフトウェア、ファームウェア及び／又はハードウェアの種々の組み合わせを使用して実施されてよい。
【０１１５】
図６は、オンデマンドデータベースサービスを使用することができる環境６１０のブロック図を例示する。環境６１０は、ユーザシステム６１２、ネットワーク６１４、システム６１６、プロセッサシステム６１７、アプリケーションプラットフォーム６１８、ネットワークインタフェース６２０、テナントデータストレージ６２２、システムデータストレージ６２４、プログラムコード６２６及び処理空間６２８を含んでよい。他の実施形態において、環境６１０は、列挙された上記コンポーネントのすべてを有さなくてもよく、かつ／あるいは、上記で列挙されたものに代わって又は加えて他の要素を有してもよい。
【０１１６】
環境６１０は、オンデマンドデータベースサービスが存在する環境である。ユーザシステム６１２は、ユーザがデータベースユーザシステムにアクセスするのに使用される任意のマシン又はシステムであってよい。例えば、ユーザシステム６１２のうち任意のものが、ハンドヘルドコンピューティング装置、携帯電話、ラップトップコンピュータ、ワークステーション、及び／又はコンピューティング装置のネットワークであってよい。本明細書において図６に（及び、より詳細に図７に）示されるとおり、ユーザシステム６１２は、ネットワーク６１４を介してオンデマンドデータベースサービスと対話してよく、システム６１６は、オンデマンドデータベースサービスである。
【０１１７】
システム６１６などのオンデマンドデータベースサービスは、外部ユーザに利用可能にされたデータベースシステムであり、上記ユーザは、データベースシステムを構築し及び／又は維持することに必ずしも携わる必要がないが、代わって、ユーザがデータベースシステムを必要とするときに（例えば、ユーザの需要に対して）ユーザ自身のために利用可能であり得る。いくつかのオンデマンドデータベースサービスは、共通データベースイメージのテーブルに記憶された１又は複数のテナントからの情報を記憶してマルチテナントデータベースシステム（ＭＴＳ）を形成してよい。したがって、「オンデマンドデータベースサービス６１６」及び「システム６１６」は、本明細書において、置き換え可能に使用されることになる。データベースイメージは、１又は複数のデータベースオブジェクトを含んでよい。リレーショナルデータベース管理システム（ＲＤＭＳ）又はその均等物が、（１又は複数の）データベースオブジェクトに対して情報の記憶及び読み出しを実行してよい。アプリケーションプラットフォーム６１８は、システム６１６のアプリケーションが実行されるのを可能にするフレームワークであってよく、例えば、オペレーションシステムのハードウェア及び／又はソフトウェアなどである。一実施形態において、オンデマンドデータベースサービス６１６は、アプリケーションプラットフォーム６１８を含んでよく、アプリケーションプラットフォーム６１８は、オンデマンドデータベースサービスの提供者、ユーザシステム６１２を介してオンデマンドデータベースサービスにアクセスするユーザ、又はユーザシステム６１２を介してオンデマンドデータベースサービスにアクセスするサードパーティアプリケーション開発者によって開発される１又は複数のアプリケーションを作成し、管理し、及び実行することを可能にする。
【０１１８】
ユーザシステム６１２のユーザは、そのそれぞれのキャパシティの点で異なってよく、特定のユーザシステム６１２のキャパシティは、現在のユーザのための許可（許可レベル）によって全体的に特定されてよい。例えば、販売員が特定のユーザシステム６１２を使用してシステム６１６と対話する場合、上記ユーザシステムは、上記販売員に割り振られたキャパシティを有する。しかしながら、管理者が上記ユーザシステムを使用してシステム６１６と対話する間、上記ユーザシステムは、上記管理者に割り振られたキャパシティを有する。階層的なロールモデルを有するシステムにおいて、ある許可レベルにおけるユーザは、より低い許可レベルのユーザがアクセス可能なアプリケーション、データ及びデータベース情報へのアクセスを有することがあり、しかし、より高い許可レベルにおけるユーザがアクセス可能な特定のアプリケーション、データベース情報及びデータへのアクセスを有さないことがある。したがって、種々のユーザが、ユーザのセキュリティ又は許可レベルに依存して、アプリケーション及びデータベース情報にアクセスすること及びこれらを修正することに関して種々の能力を有することになる。
【０１１９】
ネットワーク６１４は、互いに通信する装置から成る任意のネットワーク又はネットワークの組み合わせである。例えば、ネットワーク６１４は、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、電話網、ワイヤレスネットワーク、ポイントツーポイントネットワーク、スター型ネットワーク、トークンリング型ネットワーク、ハブネットワーク又は他の適切な構成のうちの任意の１つ又は任意の組み合わせであってよい。現在使用されている最も基本的なタイプのコンピュータネットワークは、例えば大文字の「Ｉ」を用いた「Ｉｎｔｅｒｎｅｔ」としてしばしば参照されるネットワークのグローバルなインターネットワークなどの、ＴＣＰ／ＩＰ（トランスファーコントロールプロトコル及びインターネットプロトコル）ネットワークであるため、上記ネットワークは、本明細書における例の多くにおいて使用されることになる。しかしながら、ＴＣＰ／ＩＰが頻繁に実施されるプロトコルであるが、１又は複数の実施例が使用し得るネットワークは上記のように限られないことが理解されるべきである。
【０１２０】
ユーザシステム６１２は、ＴＣＰ／ＩＰを使用してシステム６１６と通信してよく、より高いネットワークレベルにおいて、ＨＴＴＰ、ＦＴＰ、ＡＦＳ、ＷＡＰなどの他の一般的なインターネットプロトコルを使用して通信してよい。ＨＴＴＰが使用される一例において、ユーザシステム６１２は、「ブラウザ」と一般的に呼ばれるＨＴＴＰクライアントを含んで、システム６１６におけるＨＴＴＰサーバにＨＴＴＰメッセージを送信し、該ＨＴＴＰサーバからＨＴＴＰメッセージを受信してよい。上記のＨＴＴＰサーバは、システム６１６とネットワーク６１４とにおける唯一のネットワークインタフェースとして実施されてよいが、他の手法が同様に又は代わって使用されてもよい。いくつかの実施例において、システム６１６とネットワーク６１４とにおけるインタフェースは、ラウンドロビンＨＴＴＰ要求分配器などの負荷共有機能性を含んで負荷のバランスをとり、到来するＨＴＴＰ要求を複数のサーバにわたって均等に配布する。少なくとも上記サーバにアクセスするユーザに関して、複数のサーバの各々はＭＴＳのデータへのアクセスを有し、しかしながら、他の代替的な構成が代わって使用されてもよい。
【０１２１】
一実施形態において、図６に示されるシステム６１６は、ウェブベースの顧客関係管理（ＣＲＭ）システムを実施する。例えば、一実施形態において、システム６１６は、アプリケーションサーバを含み、該アプリケーションサーバは、ＣＲＭソフトウェアアプリケーションを実施し及び実行し、関連するデータ、コード、フォーム、ウェブページ及び他の情報をユーザシステム６１２との間でやりとりし、関連するデータ、オブジェクト及びウェブページコンテンツをデータベースシステムに記憶し及びデータベースシステムから読み出すように構成される。マルチテナントシステムを用いて、複数のテナントのためのデータが同一の物理的なデータベースオブジェクトに記憶されてよく、しかしながら、テナントデータは、通常、あるテナントのデータが他のテナントのデータから論理的に別個に保持されるように配置され、したがって、あるテナントは、別のテナントのデータが明示的に共有されない限り、こうしたデータへのアクセスを有さない。特定の実施形態において、システム６１６は、ＣＲＭアプリケーション以外のアプリケーション、又はＣＲＭアプリケーションに対して追加のアプリケーションを実施する。例えば、システム６１６は、ＣＲＭアプリケーションを含む複数のホストされる（標準及びカスタム）アプリケーションに対してテナントアクセスを提供してよい。ユーザ（又はサードパーティ開発者）アプリケーションは、ＣＲＭを含んでも含まなくてもよく、アプリケーションプラットフォーム６１８によりサポートされてよく、アプリケーションプラットフォーム６１８は、アプリケーションの作成と、該アプリケーションの１又は複数のデータベースオブジェクトへの記憶と、システム６１６の処理空間における仮想マシンにおけるアプリケーションの実行とを管理する。
【０１２２】
システム６１６の要素のための一配置が図６に示されており、ネットワークインタフェース６２０と、アプリケーションプラットフォーム６１８と、テナントデータ６２３のためのテナントデータストレージ６２２と、システム６１６と可能性として複数のテナントとがアクセス可能なシステムデータ６２５のためのシステムデータストレージ６２４と、システム６１６の様々な機能を実施するプログラムコード６２６と、アプリケーションホスティングサービスの一部としてアプリケーションを実行することなどのＭＴＳシステム処理及びテナント固有処理を実行する処理空間６２８とを含む。システム６１６上で実行され得るさらなる処理には、データベース索引付け処理を含む。
【０１２３】
図６に示されるシステムにおけるいくつかの要素は、ここではごく簡単に説明される従来の周知の要素を含む。例えば、各ユーザシステム６１２は、デスクトップパーソナルコンピュータ、ワークステーション、ラップトップ、ＰＤＡ、携帯電話、モバイル装置、若しくは任意のワイヤレスアクセスプロトコル（ＷＡＰ）対応装置、又は、インターネット若しくは他のネットワーク接続に対して直接若しくは間接的にインターフェースをとる能力がある任意の他のコンピューティング装置を含んでよい。ユーザシステム６１２は、通常、ＨＴＴＰクライアントを実行し、これは、例えば、マイクロソフトのインターネットエクスプローラブラウザ、ネットスケープのナビゲータブラウザ、オペラのブラウザ、又は携帯電話、ＰＤＡ若しくは他のワイヤレス装置の場合におけるＷＡＰ対応ブラウザなどのブラウジングプログラムであり、ユーザシステム６１２のユーザ（例えば、マルチテナントデータベースシステムの申し込み者）がネットワーク６１４を通じてシステム６１６から自身が利用可能な情報、ページ及びアプリケーションにアクセスし、該情報、ページ及びアプリケーションを処理し、見ることを可能にする。ユーザシステム６１２は、モバイルＯＳ（例えば、Ａｐｐｌｅ（登録商標）のｉＯＳ（登録商標）、Ａｄｎｒｏｉｄ（登録商標）、Ｐａｌｍ（登録商標）のＷｅｂＯＳ（登録商標）など）をさらに含む。各ユーザシステムは、通常、システム６１６又は他のシステム若しくはサーバにより提供されるページ、フォーム、アプリケーション及び他の情報と関連してディスプレイ（例えば、モニタ画面、ＬＣＤディスプレイなど）上にブラウザにより提供されるグラフィカルユーザインタフェース（ＧＵＩ）と対話するための、キーボード、マウス、トラックボール、タッチパッド、タッチスクリーン、ペンなどの１又は複数のユーザインタフェース装置も含む。例えば、ユーザインタフェース装置を使用して、システム６１６によりホストされるデータ及びアプリケーションにアクセスし、記憶されたデータに対して検索を実行し、ユーザに提示され得る様々なＧＵＩページとユーザが対話することをその他の方法で可能にすることができる。上記で論じられたとおり、本願実施形態は、インターネットを用いた使用に適しており、インターネットとは、ネットワークの特定のグローバルなインターネットワークをさす。しかしながら、他のネットワークがインターネットの代わりに使用されてよいことが理解されるべきであり、例えば、イントラネット、エクストラネット、仮想プライベートネットワーク（ＶＰＮ）、非ＴＣＰ／ＩＰベースのネットワーク、任意のＬＡＮ若しくはＷＡＮなどである。
【０１２４】
一実施形態に従い、各ユーザシステム６１２とそのコンポーネントのすべてとは、Ｉｎｔｅｌ  Ｃｏｒｅ（登録商標）プロセッサなどの中央処理ユニットを使用したコンピュータコード実行を含むアプリケーション、例えばブラウザなどを使用して、オペレータ構成可能である。同様にして、システム６１６（及び、２以上が存在する場合、ＭＴＳのさらなるインスタンス）とそのコンポーネントのすべてとは、プロセッサ６１７などの中央処理ユニットを使用して実行するコンピュータコードを含む（１又は複数の）アプリケーションを使用してオペレータ構成可能であってよく、プロセッサシステム６１７には、Ｉｎｔｅｌ  Ｐｅｔｎｔｉｕｍ（登録商標）プロセッサなど及び／又は複数のプロセッサユニットを含んでよい。コンピュータプログラム製品実施形態は、媒体上／媒体内に命令を記憶させた（１又は複数の）マシン可読記憶媒体を含み、これは、コンピュータをプログラムして本明細書に説明される実施形態の処理のうち任意のものを実行するのに使用されてよい。本明細書に説明されるとおり、ウェブページ、アプリケーション並びに他のデータ及びメディアコンテンツを交わし合い、処理するように、システム６１６を動作させ、構成するコンピュータコードは、好ましくは、ダウンロードされ、ハードディスクに記憶される。しかし、プログラムコード全体又はその一部が、周知である任意の他の揮発性又は不揮発性のメモリ媒体又は装置に記憶されてもよく、例えば、ＲＯＭ又はＲＡＭなどであり、あるいは、プログラムコードを記憶する能力がある任意の媒体上で提供されてもよく、例えば、フロッピーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、コンパクトディスク（ＣＤ）、マイクロドライブ及び光磁気ディスクを含む任意のタイプの回転媒体、磁気若しくは光カード、ナノシステム（分子メモリＩＣを含む）、又は、命令及び／若しくはデータを記憶するのに適した任意のタイプの媒体若しくは装置などである。さらに、プログラムコード全体又はその一部は、周知のとおり、送信媒体を通じて、例えばインターネットを通じてソフトウェアソースから、又は別のサーバから、送信され、ダウンロードされてもよく、あるいは、周知である任意の他の通信媒体及びプロトコル（例えば、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、イーサネットなど）を使用して周知である任意の他の従来のネットワーク接続（例えば、エクストラネット、ＶＰＮ、ＬＡＮなど）を通じて送信されてもよい。本願実施形態を実施するコンピュータコードは、クライアントシステム及び／又はサーバ若しくはサーバシステム上で実行できる任意のプログラミング言語で実施されてよいことも十分理解されるものであり、例えば、Ｃ、Ｃ＋＋、ＨＴＭＬ、任意の他のマークアップ言語、ＪａｖａＴＭ、ＪａｖａＳｃｒｉｐｔ、ＡｃｔｉｖｅＸ、ＶＢＳｃｒｉｐｔなどの任意の他のスクリプト言語、及び、周知である多くの他のプログラミング言語が使用されてよい（ＪａｖａＴＭは、サンマイクロシステムズ社の商標である）。
【０１２５】
一実施形態に従い、各システム６１６は、ウェブページ、フォーム、アプリケーション、データ及びメディアコンテンツをユーザ（クライアント）システム６１２に提供して、システム６１６のテナントとしてのユーザシステム６１２によるアクセスをサポートするように構成される。このようなものとして、システム６１６は、データが共有されない限り各テナントのデータを別個に保持するようにセキュリティメカニズムを提供する。２以上のＭＴＳが使用される場合、これらは互いにすぐ近くに（例えば、単一のビル又はキャンパスの中に位置するサーバファームに）位置してよく、あるいは、これらは互いから離れた位置に分散されてもよい（例えば、１又は複数のサーバがＡ市に位置し、１又は複数のサーバがＢ市に位置する）。本明細書において、各ＭＴＳは、ローカルに又は１若しくは複数の地理的位置にわたって分散された１又は複数の論理的及び／又は物理的に接続されたサーバを含んでよい。さらに、用語「サーバ」は、コンピュータシステムを含むことが意図され、処理ハードウェア及び（１又は複数の）処理空間と、当分野において周知である関連するストレージシステム及びデータベースアプリケーション（例えば、ＯＯＤＢＭＳ又はＲＤＢＭＳ）とを含む。「サーバシステム」及び「サーバ」は、本明細書において置き換え可能にしばしば使用されることも理解されるべきである。同様にして、本明細書に説明されるデータベースオブジェクトは、単一データベース、分散型データベース、分散型データベースの集合、冗長オンライン若しくはオフラインバックアップ又は他の冗長性を有するデータベースなどとして実施されてよく、分散型データベース又はストレージネットワークと関連する処理知能とを含んでよい。
【０１２６】
図７は、環境６１０をさらに示す。しかしながら、図７において、一実施形態におけるシステム６１６の要素と様々な相互接続とがさらに示される。図７は、ユーザシステム６１２がプロセッサシステム６１２Ａ、メモリシステム６１２Ｂ、入力システム６１２Ｃ及び出力システム６１２Ｄを含んでよいことを示す。図７は、ネットワーク６１４とシステム６１６とを示す。図７は、システム６１６がテナントデータストレージ６２２、テナントデータ６２３、システムデータストレージ６２４、システムデータ６２５、ユーザインタフェース（ＵＩ）７３０、アプリケーションプログラムインタフェース（ＡＰＩ）７３２、ＰＬ／ＳＯＱＬ７３４、保存ルーチン７３６、アプリケーションセットアップメカニズム７３８、アプリケーションサーバ７００１‐７００Ｎ、システム処理空間７０２、テナント処理空間７０４、テナント管理処理空間７１０、テナントストレージエリア７１２、ユーザストレージ７１４及びアプリケーションメタデータ７１６を含んでよいことも示す。他の実施形態において、環境６１０は、上記で列挙されたものと同じ要素を有さなくてもよく、かつ／あるいは上記で列挙されたものに代わって又は加えて他の要素を有してもよい。
【０１２７】
ユーザシステム６１２、ネットワーク６１４、システム６１６、テナントデータストレージ６２２及びシステムデータストレージ６２４は、上記で図６において論じられた。ユーザシステム６１２に関して、プロセッサシステム６１２Ａは、１又は複数のプロセッサの任意の組み合わせであってよい。メモリシステム６１２Ｂは、１又は複数のメモリ装置、短期メモリ及び／又は長期メモリの任意の組み合わせであってよい。入力システム６１２Ｃは、１又は複数のキーボード、マウス、トラックボール、スキャナ、カメラ及び／又はネットワークに対するインタフェースなどの入力装置の任意の組み合わせであってよい。出力システム６１２Ｄは、１又は複数のモニタ、プリンタ及び／又はネットワークに対するインタフェースなどの出力装置の任意の組み合わせであってよい。図７に示されるとおり、システム６１６は、一組のＨＴＴＰアプリケーションサーバ７００、アプリケーションプラットフォーム６１８、テナントデータストレージ６２２及びシステムデータストレージ６２４として実施される（図６の）ネットワークインタフェース６２０を含んでよい。さらに、システム処理空間７０２が示され、個々のテナント処理空間７０４とテナント管理処理空間７１０とを含む。各アプリケーションサーバ７００は、ユーザシステム６１２の要求にかなうようにテナントデータストレージ６２２及びその内部のテナントデータ６２３とシステムデータストレージ６２４及びその内部のシステムデータ６２５とを構成されてよい。テナントデータ６２３は、個々のテナントストレージエリア７１２に分けられてよく、これは、データの物理的配置及び／又は論理的配置のいずれであってもよい。各テナントストレージエリア７１２内に、ユーザストレージ７１４とアプリケーションメタデータ７１６とがユーザごとに同様に割り当てられてよい。例えば、ユーザの最も最近使用した（ＭＲＵ）項目のコピーが、ユーザストレージ７１４に記憶されてよい。同様にして、テナントである組織全体のためのＭＲＵ項目のコピーが、テナントストレージエリア７１２に記憶されてよい。ＵＩ７３０は、ユーザインタフェースを提供し、ＡＰＩ７３２は、ユーザシステム６１２におけるユーザ及び／又は開発者に、システム６１６常駐処理に対するアプリケーションプログラマインタフェースを提供する。テナントデータとシステムデータとは、１又は複数のＯｒａｃｌｅＴＭデータベースなどの様々なデータベースに記憶されてよい。
【０１２８】
アプリケーションプラットフォーム６１８は、アプリケーション開発者によるアプリケーションの作成及び管理をサポートするアプリケーションセットアップメカニズム７３９を含み、上記アプリケーションは、保存ルーチン７３６によってメタデータとしてテナントデータストレージ６２２に保存されて、例えば、テナント管理処理７１０により管理される１又は複数のテナント処理空間７０４として申し込み者によって実行されてよい。こうしたアプリケーションに対する呼び出しは、ＰＬ／ＳＯＱＬを使用してコード化されてよく、プログラミング言語型インタフェース拡張をＡＰＩ７３２に提供する。いくつかのＰＬ／ＳＯＱＬ言語実施形態の詳細な説明が、“Ｍｅｔｈｏｄ  ａｎｄ  Ｓｙｓｔｅｍ  ｆｏｒ  Ａｌｌｏｗｉｎｇ  Ａｃｃｅｓｓ  ｔｏ  Ｄｅｖｅｌｏｐｅｄ  Ａｐｐｌｉｃａｎｔｓ  ｖｉａ  ａ  Ｍｕｌｔｉ‐Ｔｅｎａｎｔ  Ｄａｔａｂａｓｅ  Ｏｎ‐Ｄｅｍａｎｄ  Ｄａｔａｂａｓｅ  Ｓｅｒｖｉｃｅ”と題され２０１０年６月１日にＣｒａｉｇ  Ｗｅｉｓｓｍａｎに交付された共通して所有される米国特許第７，７３０，４７８号に論じられており、該特許文献は、その全体をすべての目的のために本明細書において援用される。アプリケーションに対する呼び出しは、１又は複数のシステム処理によって検出されてよく、システム処理は、呼び出しを行う申し込み者のためにアプリケーションメタデータ７１６を読み出すことと仮想マシンにおいてアプリケーションとして上記メタデータを実行することとを管理する。
【０１２９】
各アプリケーションサーバ７００は、データベースシステムに通信可能に結合されてよく、例えば、異なるネットワーク接続を介してシステムデータ６２５とテナントデータ６２３とへのアクセスを有する。例えば、あるアプリケーションサーバ７００１がネットワーク６１４（例えば、インターネット）を介して結合されてよく、別のアプリケーションサーバ７００Ｎ−１が直接のネットワークリンクを介して結合されてよく、別のアプリケーションサーバ７００Ｎがさらに異なるネットワーク接続によって結合されてよい。トランスファーコントロールプロトコル及びインターネットプロトコル（ＴＣＰ／ＩＰ）は、アプリケーションサーバ７００とデータベースシステムとにおける通信のための典型的なプロトコルである。しかしながら、ネットワーク相互接続に依存してシステムを最適化するように他のトランスポートプロトコルが使用されてよいことが当業者に明らかになるであろう。
【０１３０】
特定の実施形態において、各アプリケーションサーバ７００は、テナントである任意の組織に関連付けられた任意のユーザの要求を扱うように構成される。任意の理由でいかなる時でもアプリケーションサーバを追加し、及びサーバプールから削除することが可能であるのが望ましいため、好ましくは、特定のアプリケーションサーバ７００に対してユーザ及び／又は組織へのサーバ親和性は存在しない。それゆえに、一実施形態において、ロードバランシング機能（例えば、Ｆ５のＢｉｇ‐ＩＰロードバランサ）を実施するインタフェースシステムが、アプリケーションサーバ７００とユーザシステム６１２との間で通信可能に結合されて要求をアプリケーションサーバ７００に配布する。一実施形態において、ロードバランサは、最小接続アルゴリズムを使用してアプリケーションサーバ７００に対してユーザ要求のルートを決める。ロードバランシングアルゴリズムの他の例が使用されてもよく、例えば、ラウンドロビン及び応答時間観察などである。例えば、特定の実施形態において、同じユーザからの３つの連続した要求が３つの異なるアプリケーションサーバ７００に行き当たる可能性があり、異なるユーザからの３つの要求が同じアプリケーションサーバ７００に行き当たる可能性がある。このように、システム６１６はマルチテナントであり、システム６１６は、いろいろなユーザ及び組織にわたって種々のオブジェクト、データ及びアプリケーションのストレージとアクセスとを扱う。
【０１３１】
ストレージの一例として、あるテナントが、各販売員がシステム６１６を使用して自身の販売処理を管理する販売陣を採用する会社であってよい。したがって、ユーザは、連絡先データ、リードデータ、顧客フォローアップデータ、パフォーマンスデータ、ゴール及び進捗データなどを維持することができ、これらはすべて、（例えば、テナントデータストレージ６２２において）該ユーザの個人の販売処理に適用できてよい。ＭＴＳ配置の一例において、アクセス、閲覧、修正、報告、送信及び算定などすべきデータ及びアプリケーションのすべてが、ネットワークアクセスを有するに過ぎないユーザシステムによって維持され、アクセスされるため、ユーザは、多くの種々のユーザシステムのうちいずれかから自身の販売成果及びサイクルを管理することができる。例えば、販売員が顧客を訪問し、この顧客がそのロビーにインターネットアクセスを有する場合、上記販売員は、顧客がロビーに到着するのを待ちながら、この顧客に関する重大なアップデートを得ることができる。
【０１３２】
各ユーザのデータは、各ユーザの雇用主にかかわらず他のユーザのデータから別個であってよいが、いくつかのデータは、テナントである所与の組織の複数のユーザ又はすべてのユーザによって共有され又はアクセス可能な組織規模のデータであってよい。したがって、テナントレベルにおいて割り当てられ、システム６１６によって管理されるいくつかのデータ構造が存在してよく、他のデータ構造が、ユーザレベルにおいて管理されてよい。ＭＴＳは、競合者を可能性として含む複数のテナントをサポートしてよいため、ＭＴＳは、データ、アプリケーション及びアプリケーション使用を別個に保持するセキュリティプロトコルを有するべきである。さらに、多くのテナントが、自身の独自のシステムを維持するのではなくＭＴＳへのアクセス選んでよいため、ＭＴＳに実施され得るさらなる機能は、冗長性、アップタイム及びバックアップである。ユーザ固有データ及びテナント固有データに加えて、システム６１６は、複数のテナントにより使用可能なシステムレベルデータ又は他のデータを維持してもよい。こうしたシステムレベルデータには、複数のテナント間で共有可能である産業レポート、ニュース、投稿メッセージ（posting）などを含んでよい。
【０１３３】
特定の実施形態において、ユーザシステム６１２（これは、クライアントシステムであり得る）は、アプリケーションサーバ７００と通信して、システム６１６のシステムレベル及びテナントレベルデータを要求し、更新し、システム６１６は、１又は複数のクエリをテナントデータストレージ６２２及び／又はシステムデータストレージ６２４に送信することを必要としてよい。システム６１６（例えば、システム６１６におけるアプリケーションサーバ７００）は、所望される情報にアクセスするように設計された１又は複数のＳＱＬステートメント（例えば、１又は複数のＳＱＬクエリ）を自動的に生成する。システムデータストレージ６２４は、データベースのうちの要求されたデータにアクセスするようにクエリプランを生成してよい。
【０１３４】
各データベースは、概して、所定カテゴリに適合したデータを含むオブジェクトの集合、例えば一組の論理テーブルなどと見なされてよい。「テーブル」は、データオブジェクトの一表現であり、本明細書においてオブジェクト及びカスタムオブジェクトの概念的説明を簡素化するために使用され得る。「テーブル」と「オブジェクト」とは本明細書において置き換え可能に使用され得ることが理解されるべきである。各テーブルは、見ることができるスキーマにおける列又はフィールドとして論理的に配置された１又は複数のデータカテゴリを一般に含む。テーブルの各行又はレコードは、フィールドによって定義されたカテゴリごとにデータのインスタンスを含む。例えば、ＣＲＭデータベースは、氏名、住所、電話番号、ファクス番号などの基本連絡先情報のためのフィールドを用いて顧客を説明するテーブルを含んでよい。別のテーブルが、顧客、製品、販売価格、日付などの情報のためのフィールドを含む購入指示を説明してよい。いくつかのマルチテナントデータベースシステムにおいて、標準エンティティテーブルが、すべてのテナントによる使用のために提供されてよい。ＣＲＭデータベースアプリケーションについて、こうした標準エンティティにはアカウント、連絡先、リード及び機会データのためのテーブルを含んでよく、各々が所定フィールドを含んでよい。単語「エンティティ」は本明細書において「オブジェクト」及び「テーブル」と置き換え可能に使用されてもよいことが理解されるべきである。
【０１３５】
いくつかのマルチテナントデータベースシステムにおいて、テナントは、カスタムオブジェクトを作成し、記憶することが可能にされてよく、あるいは、テナントは、例えば、カスタムインデクスフィールドを含む標準オブジェクトのためのカスタムフィールドを作成することによって、標準エンティティ又はオブジェクトをカスタマイズすることが可能にされてよい。２００４年４月２日に申請され“Ｃｕｓｔｏｍ  Ｅｎｔｉｔｉｅｓ  ａｎｄ  Ｆｉｅｌｄｓ  ｉｎ  ａ  Ｍｕｌｔｉ‐Ｔｅｎａｎｔ  Ｄａｔａｂａｓｅ  Ｓｙｓｔｅｍ”と題され、本明細書において参照により援用される米国特許出願第１０／８１７，１６１号は、マルチテナントデータベースシステムにおいてカスタムオブジェクトを作成し、かつ標準オブジェクトをカスタマイズするためのシステム及び方法を教示している。特定の実施形態において、例えば、すべての顧客エンティティデータ行は、単一のマルチテナント物理テーブルに記憶され、該テーブルは、組織ごとの複数の論理テーブルを含んでよい。顧客の複数の「テーブル」が実際には１の大きいテーブルに記憶され、あるいは顧客のデータが他の顧客のデータと同じテーブルに記憶される可能性があることは、顧客に対して透過的である。
【０１３６】
上記実施形態のうち任意のものが、単独で、あるいは任意の組み合わせにおいて互いと一緒に使用されてよい。本明細書に包含される実施形態には、本文献の概要又は要約において部分的にのみ言及され又は示唆され、あるいはまったく言及されず又は示唆されない実施形態も含み得る。様々な実施形態が従来技術と共に様々な欠陥によって動機付けされている可能性があり、このことは本明細書の１又は複数の箇所において論じられ又は示唆されている可能性があるが、上記実施形態は、必ずしも上記の欠陥のいずれかに対処するものではない。換言すると、種々の実施形態が、本明細書に論じられている可能性がある種々の欠陥に対処し得る。いくつかの実施形態は、本明細書に論じられている可能性があるいくつかの欠陥に又は１つの欠陥だけに部分的に対処することがあり、いくつかの実施形態は、上記の欠陥のいずれにも対処しないことがある。
【０１３７】
１又は複数の実施例が、例として、特定の実施形態の観点から説明されたが、１又は複数の実施例が、開示された実施形態に限定されないことが理解されるべきである。反対に、当業者に明らかであろう様々な修正と同様の配置とをカバーすることが意図される。それゆえに、別記の請求項の範囲は、すべてのこうした修正と同様の配置とを包含するように、最も広い解釈を認められるべきである。上記の説明は限定的でなく例示的なものであることが理解されるべきである。
【０１３８】
優先の主張
本出願は、Ｘｉａｏｄａｎ  Ｗａｎｇらにより“Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ａｌｌｏｃａｔｉｏｎ  ｏｆ  Ｒｅｓｏｕｒｃｅｓ  ｉｎ  ａｎ  Ｏｎ−Ｄｅｍａｎｄ  Ｓｙｓｔｅｍ”と題され２０１２年１０月１日に申請された米国仮特許出願第６１／７０８，２８３号（代理人整理番号:８９５６１１４Ｚ）、Ｘｉａｏｄａｎ  Ｗａｎｇらにより“Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ａｕｃｔｉｏｎ‐Ｂａｓｅｄ  Ｍｕｌｔｉ‐Ｔｅｎａｎｔ  Ｒｅｓｏｕｒｃｅ  Ｓｈａｒｉｎｇ”と題され２０１２年１０月１０日に申請された米国仮特許出願第６１／７１１，８３７号（代理人整理番号:８９５６１１５Ｚ）、Ｘｉａｏｄａｎ  Ｗａｎｇらにより“Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｑｕｏｒｕｍ‐Ｂａｓｅｄ  Ｃｏｏｒｄｉｎａｔｉｏｎ  ｏｆ  Ｂｒｏｋｅｒ  Ｈｅａｌｔｈ”と題され２０１２年１０月３日に申請された米国仮特許出願第６１／７０９，２６３号（代理人整理番号：８９５６１１６Ｚ）、Ｘｉａｏｄａｎ  Ｗａｎｇらにより“Ａｄａｐｔｉｖｅ，Ｔｉｅｒｅｄ，ａｎｄ  Ｍｕｌｔｉ-Ｔｅｎａｎｔ  Ｒｏｕｔｉｎｇ  Ｆｒａｍｅｗｏｒｋ  ｆｏｒ  Ｗｏｒｋｌｏａｄ  Ｓｃｈｅｄｕｌｉｎｇ”と題され２０１２年９月１２日に申請された米国仮特許出願第６１／７００，０３２号（代理人整理番号：８９５６１１７Ｚ）、Ｘｉａｏｄａｎ  Ｗａｎｇらにより“Ｓｌｉｄｉｎｇ  Ｗｉｎｄｏｗ  Ｒｅｓｏｕｒｃｅ  Ｔｒａｃｋｉｎｇ  ｉｎ  Ｍｅｓｓａｇｅ  Ｑｕｅｕｅ”と題され２０１２年９月１２日に申請された米国仮特許出願第６１／７００，０３７号（代理人整理番号：８９５６１１８Ｚ）の利益を主張し、これらの内容全体が本明細書において参照により援用され、優先がこれらから主張される。
【０１３９】
著作権表示
本特許文献の開示の一部は、著作権保護を受ける資料を包含する。著作権所有者は、それが特許商標庁の包袋又は記録に現れるとき、何人による本特許文献又は本特許開示のファクシミリ複製にも異議を有さないが、そうでなければいかなる著作権もすべて留保する。
さらに実施形態を付記する。
（付記１）  ネットワークを通じて複数の組織からジョブ要求と入札とを受信するステップであり、各ジョブ要求とその対応する入札とは、前記ネットワークを通じてコンピューティング装置においてユーザインタフェースを介して、マルチテナントデータベースシステム内でリソース通貨値を有する組織に関連付けられたユーザによって出される、ステップと、
前記複数の組織に関する保留ジョブに関連付けられるリソース通貨値を特定するステップであり、前記リソース通貨値は、前記保留ジョブに対して専用にされるリソースに対応する、ステップと、
専用にされておらず購入に利用可能なままであるリソースについて、前記の受信した入札のオークションを実行するステップであり、入札は、前記の利用可能なリソースを購入するための購入要求を含む、ステップと、
前記の専用にされたリソースと前記利用可能なリソースの前記オークションとに基づいて、前記ジョブ要求の優先順位をつけるステップと、
前記優先順位をつけられたジョブ要求に基づいて、前記ジョブ要求を処理するステップと、
を含む方法。
（付記２）  組織の保留ジョブ要求がその関連付けられたリソース通貨値を消費することなく完了した場合、前記優先順位をつけられたジョブ要求に基づいて、前記専用にされたリソースの余剰量を、該組織によって出される追加のジョブ要求に割り当てるステップ、をさらに含む付記１に記載の方法。
（付記３）  前記優先順位をつけられたジョブ要求に基づいて、前記複数の組織の第１のサブセットによって出された前記受信した入札のうち１又は複数について、前記利用可能なリソースのある量を専用にするステップ、をさらに含む付記１に記載の方法。
（付記４）  利用可能なリソースの前記量を、前記複数の組織の前記サブセットに、前記利用可能なリソースと組織の前記サブセットの前記利用可能なリソースを購入する能力とに基づいて割り当てるステップであり、前記購入する能力は、組織の前記サブセットによって出された１若しくは複数のジョブ要求のサイズ又は１若しくは複数の入札の優位性に少なくとも部分的に基づいて特定され、前記優位性は金銭値に基づく、ステップ、をさらに含む付記３に記載の方法。
（付記５）  組織の前記サブセットに対する前記利用可能なリソースの前記量の割り当てを、組織の前記サブセットによって出された１若しくは複数のジョブ要求のサイズ又は１若しくは複数の入札の金銭値に基づいて、組織の前記サブセットの前記利用可能なリソースを購入する能力の不足に起因して拒否するステップ、をさらに含む付記３に記載の方法。
（付記６）  前記複数の組織に関連付けられた１又は複数のオークションサーバの間で前記入札をブロードキャストするステップであり、前記ブロードキャストに応答して前記複数の組織のうち１又は複数から上等の入札が受信される、ステップ、をさらに含む付記３に記載の方法。
（付記７）  前記ユーザインタフェースは、前記コンピューティング装置においてソフトウェアアプリケーションによって提供され、前記ソフトウェアアプリケーションは、ビジネスソフトウェアアプリケーション、ビジネスネットワーキングウェブサイト及びソーシャルネットワーキングウェブサイトのうち１又は複数を含み、前記コンピューティング装置は、前記ネットワークを通じてサーバコンピューティング装置に結合されるクライアントコンピューティング装置を含む、付記１に記載の方法。
（付記８）  前記ネットワークは、クラウドベースのネットワーク、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、パーソナルエリアネットワーク（ＰＡＮ）、イントラネット、エクストラネット及びインターネットのうち１又は複数を含む、付記７に記載の方法。
（付記９）  命令を記憶するメモリを有するコンピューティング装置と、前記命令を実行する処理装置と、を含み、前記コンピューティング装置は、
ネットワークを通じて複数の組織からジョブ要求と入札とを受信するステップであり、各ジョブ要求とその対応する入札とは、前記ネットワークを通じてコンピューティング装置においてユーザインタフェースを介して、マルチテナントデータベースシステム内でリソース通貨値を有する組織に関連付けられたユーザによって出される、ステップと、
前記複数の組織に関する保留ジョブに関連付けられるリソース通貨値を特定するステップであり、前記リソース通貨値は、前記保留ジョブに対して専用にされるリソースに対応する、ステップと、
専用にされておらず購入に利用可能なままであるリソースについて、前記の受信した入札のオークションを実行するステップであり、入札は、前記の利用可能なリソースを購入するための購入要求を含む、ステップと、
前記の専用にされたリソースと前記利用可能なリソースの前記オークションとに基づいて、前記ジョブ要求の優先順位をつけるステップと、
前記優先順位をつけられたジョブ要求に基づいて、前記ジョブ要求を処理するステップと、
を実行するメカニズムをさらに有する、システム。
（付記１０）  前記メカニズムはさらに、組織の保留ジョブ要求がその関連付けられたリソース通貨値を消費することなく完了した場合、前記優先順位をつけられたジョブ要求に基づいて、前記専用にされたリソースの余剰量を、該組織によって出される追加のジョブ要求に割り当てる、付記９に記載のシステム。
（付記１１）  前記メカニズムはさらに、前記優先順位をつけられたジョブ要求に基づいて、前記複数の組織の第１のサブセットによって出された前記受信した入札のうち１又は複数について、前記利用可能なリソースのある量を専用にする、付記９に記載のシステム。
（付記１２）  前記メカニズムはさらに、利用可能なリソースの前記量を、前記複数の組織の前記サブセットに、前記利用可能なリソースと組織の前記サブセットの前記利用可能なリソースを購入する能力とに基づいて割り当て、前記購入する能力は、組織の前記サブセットによって出された１若しくは複数のジョブ要求のサイズ又は１若しくは複数の入札の優位性に少なくとも部分的に基づいて特定され、前記優位性は金銭値に基づく、付記１１に記載のシステム。
（付記１３）  前記メカニズムはさらに、組織の前記サブセットに対する前記利用可能なリソースの前記量の割り当てを、組織の前記サブセットによって出された１若しくは複数のジョブ要求のサイズ又は１若しくは複数の入札の金銭値に基づいて、組織の前記サブセットの前記利用可能なリソースを購入する能力の不足に起因して拒否する、付記１１に記載のシステム。
（付記１４）  前記メカニズムはさらに、前記複数の組織に関連付けられた１又は複数のオークションサーバの間で前記入札をブロードキャストし、前記ブロードキャストに応答して前記複数の組織のうち１又は複数から上等の入札が受信される、付記１１に記載のシステム。
（付記１５）  前記ユーザインタフェースは、前記コンピューティング装置においてソフトウェアアプリケーションによって提供され、前記ソフトウェアアプリケーションは、ビジネスソフトウェアアプリケーション、ビジネスネットワーキングウェブサイト及びソーシャルネットワーキングウェブサイトのうち１又は複数を含み、前記コンピューティング装置は、前記ネットワークを通じてサーバコンピューティング装置に結合されるクライアントコンピューティング装置を含み、前記ネットワークは、クラウドベースのネットワーク、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、パーソナルエリアネットワーク（ＰＡＮ）、イントラネット、エクストラネット及びインターネットのうち１又は複数を含む、付記９に記載のシステム。
（付記１６）  命令を記憶させたコンピュータ可読媒体であって、前記命令は、プロセッサにより実行されると、前記プロセッサに、
ネットワークを通じて複数の組織からジョブ要求と入札とを受信するステップであり、各ジョブ要求とその対応する入札とは、前記ネットワークを通じてコンピューティング装置においてユーザインタフェースを介して、マルチテナントデータベースシステム内でリソース通貨値を有する組織に関連付けられたユーザによって出される、ステップと、
前記複数の組織に関する保留ジョブに関連付けられるリソース通貨値を特定するステップであり、前記リソース通貨値は、前記保留ジョブに対して専用にされるリソースに対応する、ステップと、
専用にされておらず購入に利用可能なままであるリソースについて、前記の受信した入札のオークションを実行するステップであり、入札は、前記の利用可能なリソースを購入するための購入要求を含む、ステップと、
前記の専用にされたリソースと前記利用可能なリソースの前記オークションとに基づいて、前記ジョブ要求の優先順位をつけるステップと、
前記優先順位をつけられたジョブ要求に基づいて、前記ジョブ要求を処理するステップと、
を実行させる、コンピュータ可読媒体。
（付記１７）  前記プロセッサはさらに、組織の保留ジョブ要求がその関連付けられたリソース通貨値を消費することなく完了した場合、前記優先順位をつけられたジョブ要求に基づいて、前記専用にされたリソースの余剰量を、該組織によって出される追加のジョブ要求に割り当てる、付記１６に記載のコンピュータ可読媒体。
（付記１８）  前記プロセッサはさらに、前記優先順位をつけられたジョブ要求に基づいて、前記複数の組織の第１のサブセットによって出された前記受信した入札のうち１又は複数について、前記利用可能なリソースのある量を専用にする、付記１６に記載のコンピュータ可読媒体。
（付記１９）  前記プロセッサはさらに、利用可能なリソースの前記量を、前記複数の組織の前記サブセットに、前記利用可能なリソースと組織の前記サブセットの前記利用可能なリソースを購入する能力とに基づいて割り当て、前記購入する能力は、組織の前記サブセットによって出された１若しくは複数のジョブ要求のサイズ又は１若しくは複数の入札の優位性に少なくとも部分的に基づいて特定され、前記優位性は金銭値に基づく、付記１８に記載のコンピュータ可読媒体。
（付記２０）  前記プロセッサはさらに、組織の前記サブセットに対する前記利用可能なリソースの前記量の割り当てを、組織の前記サブセットによって出された１若しくは複数のジョブ要求のサイズ又は１若しくは複数の入札の金銭値に基づいて、組織の前記サブセットの前記利用可能なリソースを購入する能力の不足に起因して拒否する、付記１８に記載のコンピュータ可読媒体。
（付記２１）  前記プロセッサはさらに、前記複数の組織に関連付けられた１又は複数のオークションサーバの間で前記入札をブロードキャストし、前記ブロードキャストに応答して前記複数の組織のうち１又は複数から上等の入札が受信される、付記１８に記載のコンピュータ可読媒体。
（付記２２）  前記ユーザインタフェースは、前記コンピューティング装置においてソフトウェアアプリケーションによって提供され、前記ソフトウェアアプリケーションは、ビジネスソフトウェアアプリケーション、ビジネスネットワーキングウェブサイト及びソーシャルネットワーキングウェブサイトのうち１又は複数を含み、前記コンピューティング装置は、前記ネットワークを通じてサーバコンピューティング装置に結合されるクライアントコンピューティング装置を含み、前記ネットワークは、クラウドベースのネットワーク、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、パーソナルエリアネットワーク（ＰＡＮ）、イントラネット、エクストラネット及びインターネットのうち１又は複数を含む、付記１６に記載のコンピュータ可読媒体。
【図１】
2019040613.tif 000003
【図２】
2019040613.tif 000004
【図３】
2019040613.tif 000005
【図４Ａ】
2019040613.tif 000006
【図４Ｂ】
2019040613.tif 000007
【図４Ｃ】
2019040613.tif 000008
【図５】
2019040613.tif 000009
【図６】
2019040613.tif 000010
【図７】
2019040613.tif 000011
【外国語明細書】
2019040613000001.pdf