JP2017524202A - ポリシーベースのリソース管理および割当てシステム - Google Patents

Abstract

本開示は概して、構成可能なコンピューティングリソースの管理およびプロビジョニングを向上させることに関する。構成可能なコンピューティングリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）をリソースポリシーに基づいて管理およびプロビジョニングするための特定の技術が本明細書に開示される。これらの技術のうちの１つは、構成可能なコンピューティングリソースのプロビジョニングを、デマンドベースのポリシーおよび／またはコントリビューションベースのポリシーに基づいてある程度制御する能力をユーザに提供する。

Description

優先権主張
本願は、２０１５年８月６日に出願され「CONTRIBUTION POLICY-BASED RESOURCE MANAGEMENT AND ALLOCATION SYSTEM（コントリビューションポリシーベースのリソース管理および割当てシステム）」と題された米国非仮出願番号第１４／８１９，８２７号、および２０１５年８月６日に出願され「DEMAND POLICY-BASED RESOURCE MANAGEMENT AND ALLOCATION SYSTEM（デマンドポリシーベースのリソース管理および割当てシステム）」と題された米国非仮出願番号第１４／８１９，８１５号に基づく優先権および利益を主張するものであり、上記両出願は、２０１４年８月８日に出願され「RESOURCE MANAGEMENT AND ALLOCATION SYSTEM（リソース管理および割当てシステム）」と題された米国仮出願番号第６２／０３５，３７０号に基づく優先権を主張する。上記出願の各々の内容全体を、すべての目的のために本明細書に引用により援用する。

背景
本開示は概してコンピュータシステムおよびソフトウェアに関し、より特定的には、分散コンピューティング環境におけるサービスのプロビジョニングを容易にし自動化するための技術に関する。クラウドコンピューティング環境などの分散コンピューティング環境は、最小限の管理努力またはサービスのプロバイダとのインタラクションで迅速にプロビジョニングおよびリリースされ得る構成可能なコンピューティングリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）の共有プールに対する簡便なオンデマンドのネットワークアクセスを可能にするためのサービス配信のモデルである。プロバイダは、分散コンピューティング環境を介してさまざまなサービスを提供し得る。これらのサービスは、サービスとしてのソフトウェア（Software as a Service：ＳａａＳ）カテゴリ、サービスとしてのプラットフォーム（Platform as a Service：ＰａａＳ）カテゴリ、サービスとしてのインフラストラクチャ（Infrastructure as a Service：ＩａａＳ）カテゴリ、またはその他の、ハイブリッドサービスを含むサービスのカテゴリの下で提供される１つ以上のサービスを含み得る。

ユーザ（たとえば顧客またはクライアント）は、オーダーまたはサービスサブスクリプションを介して、分散コンピューティング環境によって提供されるサービスの１つ以上をオーダーし得る。次いで、分散コンピューティング環境は、ユーザのサブスクリプションオーダー内に要求されたサービスを提供するために処理（たとえばプロビジョニング、管理、および追跡）を実行する。典型的に、プロバイダ（たとえばクラウドサービスプロバイダ）が１つ以上のサービスにサブスクライブするオーダーまたはサービスサブスクリプションを受信すると、分散コンピューティング環境は、１つ以上のサービスに対して構成可能なコンピューティングリソースを、要求を行っているユーザに対してプロビジョニングまたは割当てる。しかし、要求を行っているユーザは、構成可能なコンピューティングリソースがどのようにプロビジョニングまたは割当てられるかに対する制御を有しておらず、分散コンピューティング環境は、構成可能なコンピューティングリソースを、構成可能なコンピューティングリソースについての要求を行っているユーザからのデマンドを予想するように管理することもしない。これらの課題は、自動化、パフォーマンス、および使用性の問題を提起し得、これらの問題には、構成可能なコンピューティングリソースをプロビジョニングまたは割当てる既存の分散コンピューティング環境によって容易に対処することができない。

簡単な概要
本開示は概して、構成可能なコンピューティングリソースの管理およびプロビジョニングを向上させることに関する。インフラストラクチャセットアップ時間を減らすかなくすために、反復可能な複雑な統合を自動化するために、人間の介入を回避するために、かつ構成可能なコンピューティングリソースのより良い管理および使用性を提供するために、構成可能なコンピューティングリソースをリソースポリシーに基づいて管理およびプロビジョニングするための特定の技術が本明細書に開示される。

いくつかの実施形態では、本発明は、構成可能なコンピューティングリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）のプロビジョニングをリソースポリシーに基づいてある程度制御する能力をユーザに提供する。たとえば、ユーザは、リソースがプロビジョニングされる地理的位置を規定する能力を有し得；サービスがマルチテナントサービスである（たとえば、同一のリソースが２人の別のユーザによって共有され得る）場合、ユーザは、当該ユーザがリソースを共有したくないことを示す能力を有し得；サービスがマルチテナントサービスである場合、ユーザは、特定のテナントに対するアフィニティを示す能力を有し得（たとえば、ユーザは自身がテナントＸとリソースを共有したいことを示す能力を有し得）、または対照的に、ユーザは、自身が特定のテナントと共有したくないことを示す能力を有し得；ユーザは、要求可能な構成可能なコンピューティングリソースと交換に分散コンピューティング環境のリソースプールに１つ以上の構成可能なコンピューティングリソースをコントリビューションする能力を有し得；ユーザは、サービスについての別個のＰＯＤプロビジョニングおよびサービスプロビジョニングを制御する能力を有し得る；等である。

いくつかの実施形態では、本発明は、構成可能なコンピューティングリソースまたは構成可能なコンピューティングリソースのセットアップまたはグループを、リソースポリシーに基づいて管理し、予想し、予め作成する能力を分散コンピューティング環境に提供する。たとえば、分散コンピューティング環境は、リソースポリシー、および構成可能なコンピューティングリソースを含むサービス要求の現在のパーセンテージに基づいて、いくつかの構成可能なコンピューティングリソースを自動的に予め作成する能力を有し得；分散コンピューティング環境は、リソースポリシー、および新たなサービスまたはプロダクトリリースの進行に基づいて、いくつかの構成可能なコンピューティングリソースを自動的に予め作成する能力を有し得；分散コンピューティング環境は、ともに使用されるリソースのセットまたはグループに対するデマンドのパーセンテージを監視し、リソースポリシー、および構成可能なコンピューティングリソースに対するデマンドに基づいて、構成可能なコンピューティングリソースの特定されたセットまたはグループを予め作成するまたはオンデマンドで作成する能力を有し得；分散コンピューティング環境は、リソースポリシー、および構成可能なコンピューティングリソースに対するデマンドに基づいて、ユーザが分散コンピューティング環境にコントリビューション可能であるかコントリビューションしたいくつかの構成可能なコンピューティングリソースと、コントリビューションされた構成可能なコンピューティングリソースと交換にユーザに提供可能であるかユーザに提供されたいくつかの構成可能なコンピューティングリソースとを制御する能力を有し得る；等である。

少なくとも一実施形態において、方法はコンピューティングシステムによって実行され、方法は、ユーザによるサービスのオーダーを受信することを含む。サービスは一部はリソースの割当てによって可能になる。方法はさらに、オーダーをパースして、リクエスタ、リソース、および要求時間を含む要求データを特定することを含み得る。方法はさらに、要求データをアグリゲートデータ構造に追加することとを含み得、アグリゲートデータ構造は、以前にパースされたオーダーについての要求データのアグリゲートを含む。方法はさらに、アグリゲートデータ構造に基づいて、リソースに対するリアルタイムデマンドを示す値を決定することを含み得る。方法はさらに、要求データの少なくとも１つのコンポーネントが、オーダーと、以前にパースされたオーダーからの少なくとも１つの他のオーダーとの間で同一であることに基づいて、オーダーを少なくとも１つの他のオーダーと相関付けることと、オーダーを少なくとも１つの他のオーダーと相関付けたことに基づいて、少なくとも１つのリソースセットを特定することとを含み得、少なくとも１つのリソースセットは、オーダーからのリソースと、少なくとも１つの他のオーダーから要求された別のリソースとを含む。

任意に、方法はさらに、リソースに対するリアルタイムデマンドを示す、決定された値に基づいて、リソースの割当てに対する１つ以上のデマンドポリシーを生成または更新することと、１つ以上のデマンドポリシーに基づいて、リソースを予め作成することと、１つ以上のデマンドポリシーに基づいて、予め作成されたリソースを１人以上のユーザに割当てることとを含み得る。リソースに対するリアルタイムデマンドを示す値は、以前にパースされたオーダーについての要求データのアグリゲートから取得されるリソースについての現在の要求ボリュームを用いて決定される。

少なくとも一実施形態において、命令が格納されている非一時的な機械読取可能記憶媒体が提供され、命令は、１つ以上のプロセッサによって実行されると１つ以上のプロセッサに方法を実行させ、方法は、要求データのアグリゲートに基づいて、リソースプール内のリソースに対するリアルタイムデマンドを示す値を決定することを含む。要求データのアグリゲートは、サービスを可能にする少なくとも一部としてリソースを含んでいたサービスに対する以前に受信された任意の数のオーダーから取得される。１つ以上のプロセッサによって実行される方法はさらに、リソースに対するリアルタイムデマンドを示す、決定された値に基づいて、リソースの割当てに対する１つ以上のデマンドポリシーを生成または更新することと、１つ以上のデマンドポリシーに基づいて、リソースを予め作成することと、１つ以上のデマンドポリシーに基づいて、予め作成されたリソースを１人以上のユーザに割当てることとを含み得る。

任意に、リアルタイムデマンドを計算することは、リアルタイムデマンドを示す値を決定することは、以前に受信されたオーダーについての要求データのアグリゲートを用いて、特定の期間内にリソースを含むオーダーのパーセンテージを決定することを含む。

少なくとも一実施形態において、１つ以上のプロセッサおよび非一時的な機械読取可能記憶媒体を含むシステムが提供される。システムはさらに、要求データのアグリゲートに基づいて、リソースプール内のリソースに対するリアルタイムデマンドを示す値を決定するように構成されたプログラム命令を含み得る。要求データのアグリゲートは、サービスを可能にする少なくとも一部としてリソースを含んでいたサービスに対する以前に受信された任意の数のオーダーから取得される。プログラム命令はさらに、要求データの少なくとも１つのコンポーネントが、サービスのオーダーと、以前に受信されたオーダーからの少なくとも１つの他のオーダーとの間で同一であることに基づいて、オーダーを少なくとも１つの他のオーダーと相関付け、オーダーを少なくとも１つの他のオーダーと相関付けたことに基づいて、少なくとも１つのリソースセットを特定するように構成され得る。少なくとも１つのリソースセットは、オーダーからのリソースと、少なくとも１つの他のオーダーから要求された別のリソースとを含む。プログラム命令はさらに、リソースプール内のリソースの利用を追跡し、（ｉ）リソースに対するリアルタイムデマンドを示す、決定された値、（ｉｉ）リソースを含む少なくとも１つのリソースセット、および（ｉｉｉ）追跡されたリソースの利用、の少なくとも１つに基づいて、リソースの割当てに対する１つ以上のデマンドポリシーを生成または更新するように構成され得る。プログラム命令はさらに、１つ以上のデマンドポリシーに基づいて、（ｉ）リソースを予め作成する、（ｉｉ）リソースをリソースプールに追加する、（ｉｉｉ）リソースをクリーンにする、の少なくとも１つを行うように構成され得る。プログラム命令は、１つ以上のプロセッサによって実行されるように、非一時的な機械読取可能記憶媒体上に格納されている。

任意に、システムはさらに、１つ以上のデマンドポリシーに基づいてリソースを１人以上のユーザに割当てるプログラム命令を含み得る。

少なくとも一実施形態において、方法はコンピューティングシステムによって実行され、方法は、ユーザからのリソース提出を受信することを含む。リソース提出はコントリビューション可能なリソースを特定している。方法はさらに、リソース提出に対するコントリビューションポリシーを特定することを含み得る。コントリビューションポリシーは、コントリビューション可能なリソースのリソースタイプと、要求可能なリソースの１つ以上のリソースタイプとの間のマッピングに基づいて特定される。方法はさらに、リソース提出に対して特定されたコントリビューションポリシーに基づいて、要求可能なリソースの１つ以上のリソースタイプを、ユーザと関連付けられているクライアントコンピューティングシステムに送信することを含み得る。方法はさらに、要求可能なリソースの１つ以上のリソースタイプのうちの、ユーザによる１つのリソースタイプの選択を示す情報を、クライアントコンピューティングシステムから受信することを含み得る。

任意に、方法はさらに、ユーザによるサービスのオーダーを受信することを含み得る。サービスは一部はリソースの割当てによって可能になる。方法はさらに、リソースのタイプがユーザによって選択された１つのリソースタイプと一致すると判断することと、コントリビューション可能なリソースと交換に、サービスに対するリソースへのアクセスを可能にすることとを含み得る。

少なくとも一実施形態において、命令が格納されている非一時的な機械読取可能記憶媒体が提供され、命令は、１つ以上のプロセッサによって実行されると１つ以上のプロセッサに方法を実行させ、方法は、ユーザからのリソース提出を受信することを含み、リソース提出はコントリビューション可能なリソースを特定しており、方法はさらに、リソース提出に基づいて、コントリビューション可能なリソースのリソースタイプを決定することを含む。１つ以上のプロセッサによって実行される方法はさらに、リソース提出に対するコントリビューションポリシーを特定することを含み得る。コントリビューションポリシーを特定することは、リソースタイプが、コントリビューションポリシーにおいて要求可能なリソースの１つ以上のリソースタイプにマップしているコントリビューション可能なリソースの１つ以上のリソースタイプと一致すると判断することを含む。１つ以上のプロセッサによって実行される方法はさらに、リソース提出に対して特定されたコントリビューションポリシーに基づいて、要求可能なリソースの１つ以上のリソースタイプを、ユーザと関連付けられているクライアントコンピューティングシステムに送信することを含み得る。１つ以上のプロセッサによって実行される方法はさらに、要求可能なリソースの１つ以上のリソースタイプのうちの、ユーザによる１つのリソースタイプの選択を示す情報を、クライアントコンピューティングシステムから受信することを含み得る。

任意に、１つ以上のプロセッサによって実行される方法はさらに、コントリビューション可能なリソースと交換に、ユーザによって選択された１つのリソースタイプと一致するタイプのリソースを割当てることを含み得る。割当てることは、ユーザにサービスするためにリソースを構成することを含む。

少なくとも一実施形態において、１つ以上のプロセッサおよび非一時的な機械読取可能記憶媒体を含むシステムが提供される。システムはさらに、ユーザからのサービスのオーダーを受信するように構成されたプログラム命令を含み得、オーダーはコントリビューション可能なリソースおよび要求可能なリソースを特定している。コントリビューション可能なリソースは、要求可能なリソースと交換にリソースプールに提供されることになっている。プログラム命令はさらに、コントリビューションポリシーに基づいてリソース提出を受付けるように構成され得る。コントリビューションポリシーは、コントリビューション可能なリソースのタイプの第１のリソースタイプと要求可能なリソースのタイプの第２のリソースタイプとの間のマッピングを定義している。加えて、プログラム命令はさらに、コントリビューション可能なリソースへのアクセスおよびコントリビューション可能なリソースに対する制御を提供するアクセスクレデンシャルを受信し、分散システムの１人以上のユーザにサービスするためにコントリビューション可能なリソースの可用性を示すように、リソースプールを更新し、要求可能なリソースをユーザに割当てるように構成され得る。プログラム命令は、１つ以上のプロセッサによって実行されるように、非一時的な機械読取可能記憶媒体上に格納されている。

任意に、コントリビューション可能なリソースはユーザによって管理され、要求可能なリソースは別のユーザによって管理される。または、コントリビューション可能なリソースはユーザによって管理され、要求可能なリソースは、分散システムのリソースマネージャによって管理されるリソースプールのコンポーネントである。

上記は、他の特徴および実施形態とともに、以下の明細書、特許請求の範囲、および添付の図面を参照するとより明らかになるであろう。

本発明の実施形態に係るクラウドインフラストラクチャシステムの論理図である。 本発明の実施形態に係るポリシーベースのリソース割当ておよび管理システムの簡略化したダイアグラムの図である。 本発明の実施形態に係る配置ポリシーベースのリソース割当ておよび管理の例を表わす図である。 本発明の実施形態に係るクライアントデバイスおよびリソースマネージャのより詳細な高レベルのダイアグラムの図である。 本発明の実施形態に係るコントリビューションポリシーベースのリソース割当ておよび管理システムの簡略化したダイアグラムの図である。 本発明の実施形態に係るクライアントデバイスおよびリソースマネージャのより詳細な高レベルのダイアグラムの図である。 本発明の実施形態に係るコントリビューションポリシーベースのリソース割当てのために実行される処理を表わす簡略化したフローチャートの図である。 本発明の実施形態に係るコントリビューションポリシーベースのリソース割当てのために実行される処理を表わす別の簡略化したフローチャートの図である。 本発明の実施形態に係るデマンドポリシーベースのリソース割当てのために実行される処理を表わす簡略化したフローチャートの図である。 本発明の実施形態に係るデマンドポリシーベースのリソース割当てのために実行される処理を表わす別の簡略化したフローチャートの図である。 本発明の実施形態を組込むことができるネットワーク環境の簡略化した高レベルのダイアグラムの図である。 本発明の教示を組込むことができる別の実施形態を表わす図である。 実施形態を実現するための分散システムの簡略化したダイアグラムの図である。 本開示の実施形態に従う、サービスがクラウドサービスとして供給され得るシステム環境の１つ以上のコンポーネントの簡略化したブロックダイアグラムの図である。 本発明の実施形態を実現するために用いられ得る例示的なコンピュータシステムを示す図である。

詳細な説明
以下の説明では、本発明の実施形態が十分に理解されるようにするために、説明の目的で具体的詳細を記載する。しかし、これらの具体的詳細がなくてもさまざまな実施形態を実施できることは明らかであろう。図面および説明は、限定的であるよう意図されるものではない。

本開示は概して、構成可能なコンピューティングリソースをリソースポリシーに基づいて管理して割当てることに関する。この開示の目的のために、構成可能なコンピューティングリソースの管理および割当ては、少なくとも一部は、クラウドコンピューティング環境などの分散コンピューティング環境のサービスプロバイダによって提供される１つ以上のサービスにサブスクライブする１つ以上のサブスクリプションオーダーに応答して実行されると仮定する。いくつかの実施形態は、ＳａａＳ、ＰａａＳおよびＩａａＳを含むサービスモデルの下で提供される構成可能なコンピューティングリソースの管理および割当てに関して本明細書に開示されているが、これは限定的であるよう意図されるものではない。ＳａａＳ、ＰａａＳおよびＩａａＳに加えて、本明細書に開示される教示は他のサービスモデルにも適用可能である。たとえば、教示は、構成可能なコンピューティングリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）の共有プールに対する簡便なオンデマンドのネットワークアクセスを可能にするためのサービス配信の任意のモデルに適用可能である。

特定の実施形態では、クラウドコンピューティング環境などの分散コンピューティング環境は、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様でユーザに与えられる一連のアプリケーション、ミドルウェアおよびデータベースサービス提供品を含み得る。クラウドコンピューティング環境は、クラウドコンピューティング環境においてサービスおよびリソースのユーザのサブスクリプションをプロビジョニング、管理および追跡する機能、クラウドコンピューティング環境においてサービスを利用するユーザに予測可能な作業費用を提供する機能、クラウドコンピューティング環境においてユーザのデータのロバストなアイデンティティドメインの分離および保護を提供する機能、クラウドコンピューティング環境の設計の透過的なアーキテクチャおよび制御をユーザに提供する機能、データ保護の保証とデータプライバシ基準および規制の順守とをユーザに提供する機能、クラウドコンピューティング環境においてサービスを構築およびデプロイするための統合された開発経験をユーザに提供する機能、ならびにクラウドコンピューティング環境においてビジネスソフトウェア、ミドルウェア、データベースおよびインフラストラクチャサービスの間のシームレスな統合をユーザに提供する機能を含むがこれらに限定されるものではない多くの機能を提供することができる。

特定の実施形態では、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストアおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービスなどの、クラウドコンピューティング環境のユーザがオンデマンドで利用できるようにされる多数のサービスを含み得る。クラウドコンピューティング環境によって提供されるサービスは、そのユーザのニーズを満たすように動的にスケーリング可能である。クラウドコンピューティング環境によって提供されるサービスの具体的なインスタンス化は、本明細書ではサービスインスタンスと称される。一般に、クラウドサービスプロバイダのシステムからインターネットなどの通信ネットワークを介してユーザが利用できるようにされるサービスはいずれも、クラウドサービスと称される。典型的に、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、ユーザ自身のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストし得、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションをオーダーし、使用し得る。

コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダによってユーザに提供されるかまたはそうでなければ当該技術分野において公知のストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、または他のサービスへの保護されたコンピュータネットワークアクセスを含む。たとえば、サービスは、インターネットを介したクラウド上のリモートストレージへの、パスワードによって保護されたアクセスを含んでいてもよい。別の例として、サービスは、ネットワーク化された開発者による私的使用のためのウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含んでいてもよい。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含んでいてもよい。

図１は、本発明のいくつかの実施形態に係るクラウドコンピューティング環境１０の論理図である。クラウドコンピューティング環境１０は、クラウドまたはネットワーク化された環境を介してさまざまなサービスを提供し得る。これらのサービスは、ＳａａＳ、ＰａａＳ、ＩａａＳ、またはその他の、ハイブリッドサービスを含むサービスのカテゴリの下で提供される１つ以上のサービスを含み得る。ユーザは、サブスクリプションオーダーを介して、クラウドコンピューティング環境１０によって提供される１つ以上のサービスをオーダーし得る。次いで、クラウドコンピューティング環境１０は、ユーザのサブスクリプションオーダーにおけるサービスを提供するために処理を実行する。

クラウドコンピューティング環境１０は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。たとえば、サービスはパブリッククラウドモデルの下で提供されてもよく、パブリッククラウドモデルでは、クラウドコンピューティング環境１０が（たとえばオラクルが所有する）クラウドサービスを販売する組織によって所有され、サービスは一般的な公営企業またはさまざまな産業企業が利用できるようにされる。別の例として、サービスはプライベートクラウドモデルの下で提供されてもよく、プライベートクラウドモデルでは、クラウドコンピューティング環境１０が単一の組織のために単独で運営され、当該組織内の１つ以上のエンティティにサービスを提供することができる。また、クラウドサービスはコミュニティクラウドモデルの下で提供されてもよく、コミュニティクラウドモデルでは、クラウドインフラストラクチャシステム１００およびクラウドコンピューティング環境１０によって提供されるサービスが関連のコミュニティの中のいくつかの組織によって共有される。また、クラウドサービスは、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供されてもよい。

図１に示されるように、クラウドコンピューティング環境１０は、クラウドコンピューティング環境１０によって提供されるサービスのプロビジョニングを可能にする、連携して動作する複数のコンポーネントを含み得る。図１に示される実施形態では、クラウドコンピューティング環境１０は、ＳａａＳプラットフォーム１５と、ＰａａＳプラットフォーム２０と、ＩａａＳプラットフォーム２５と、インフラストラクチャリソース３０と、クラウド管理機能３５とを含む。これらのコンポーネントは、ハードウェアまたはソフトウェアまたはそれらの組み合わせで実現されてもよい。

ＳａａＳプラットフォーム１５は、ＳａａＳカテゴリに分類されるクラウドサービスを提供するように構成される。たとえば、ＳａａＳプラットフォーム１５は、統合された開発およびデプロイメントプラットフォーム上で一連のオンデマンドのアプリケーションを構築および供給する機能を提供し得る。ＳａａＳプラットフォーム１５は、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ＳａａＳプラットフォーム１５によって提供されるサービスを利用することによって、ユーザは、クラウドコンピューティング環境１０上で実行されるアプリケーションを利用することができる。ユーザは、ユーザが別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。

さまざまな異なるＳａａＳサービスが提供され得る。例としては、大規模組織に販売実績管理、企業統合およびビジネスの柔軟性などのためのソリューションを提供するサービスが挙げられるが、これらに限定されるものではない。一実施形態では、ＳａａＳサービスは、ユーザ関係管理（User Relationship Management：ＣＲＭ）サービス４０（たとえばオラクルクラウドによって提供されるフュージョンＣＲＭサービス）、人材管理（Human Capital Management：ＨＣＭ）／才能管理サービス４５などを含んでいてもよい。ＣＲＭサービス４０は、ユーザへの販売活動サイクルの報告および管理に向けられるサービスなどを含んでいてもよい。ＨＣＭ／才能サービス４５は、ユーザへのグローバルな労働力ライフサイクル管理および才能管理サービスの提供に向けられるサービスを含んでいてもよい。

標準化された、共有の、弾性的にスケーラブルなアプリケーション開発およびデプロイメントプラットフォームにおけるＰａａＳプラットフォーム２０によって、さまざまな異なるＰａａＳサービスが提供され得る。ＰａａＳサービスの例としては、共有される共通のアーキテクチャ上で既存のアプリケーションを（オラクルなどの）組織が集約することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する能力が挙げられ得るが、これらに限定されるものではない。ＰａａＳプラットフォーム２０は、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ユーザは、ユーザが別個のライセンスおよびサポートを購入する必要なく、クラウドコンピューティング環境１０によって提供されるＰａａＳサービスを取得することができる。ＰａａＳサービスの例としては、オラクルＪａｖａ（登録商標）クラウドサービス（Java Cloud Service：ＪＣＳ）、オラクルデータベースクラウドサービス（Oracle Database Cloud Service：ＤＢＣＳ）などが挙げられるが、これらに限定されるものではない。

ＰａａＳプラットフォーム２０によって提供されるサービスを利用することによって、ユーザは、クラウドコンピューティング環境１０によってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態では、クラウドコンピューティング環境１０によって提供されるＰａａＳサービスは、データベースクラウドサービス５０と、ミドルウェアクラウドサービス（たとえばオラクルフュージョンミドルウェアサービス）５５と、Ｊａｖａクラウドサービス６０とを含んでいてもよい。一実施形態では、データベースクラウドサービス５０は、組織がデータベースリソースをプールし、データベースクラウドの形態でデータベース・アズ・ア・サービスをユーザに供給することを可能にする共有のサービスデプロイメントモデルをサポートし得、ミドルウェアクラウドサービス５５は、さまざまなビジネスアプリケーションを開発およびデプロイするためにユーザにプラットフォームを提供し、Ｊａｖａクラウドサービス６０は、クラウドコンピューティング環境１０においてＪａｖａアプリケーションをデプロイするためにユーザにプラットフォームを提供する。図１に示されるＳａａＳプラットフォーム１５およびＰａａＳプラットフォーム２０におけるコンポーネントは、単に例示の目的で示されており、本発明の実施形態の範囲を限定することを意図したものではない。代替的な実施形態では、ＳａａＳプラットフォーム１５およびＰａａＳプラットフォーム２０は、クラウドコンピューティング環境１０のユーザに追加のサービスを提供するための追加のコンポーネントを含んでいてもよい。

ＩａａＳプラットフォーム２０によってさまざまな異なるＩａａＳサービスが提供され得る。ＩａａＳサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用するユーザのために、ストレージ、ネットワークおよび他の基礎的なコンピューティングリソースなどの基本的なコンピューティングリソースの管理および制御を容易にする。

特定の実施形態では、クラウドコンピューティング環境１０は、クラウドコンピューティング環境１０のユーザにさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース３０を含む。一実施形態では、インフラストラクチャリソース３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するために、サーバ、ストレージおよびネットワーキングリソースなどのハードウェアの予め作成された、最適化された組み合わせ（たとえばグループまたはセット）を含む。

特定の実施形態では、クラウド管理機能３５は、クラウドコンピューティング環境１０においてクラウドサービス（たとえばＳａａＳ、ＰａａＳ、ＩａａＳサービス）の包括的な管理を提供する。一実施形態では、クラウド管理機能３５は、クラウドインフラストラクチャシステム１０によって受信されたユーザのオーダーまたはサブスクリプションをプロビジョニング、管理および追跡するための機能などを含む。

図２は、本発明の実施形態に係るポリシーベースのリソース割当ておよび管理システム１００の簡略化した高レベルのダイアグラムを表わす。図２に示されるように、リソース管理システム１０５（たとえば１つ以上のコンピューティングデバイスを含むサービスプロバイダのコンピューティングシステム）は、ユーザまたはユーザ１１０（たとえばクライアントもしくはコンピューティングデバイス）から、１つ以上の構成可能なコンピューティングリソース１１５Ａ〜１１５Ｊに対するオーダーまたはサービスサブスクリプション１０７を受信し得る。ユーザ１１０に提供されるリソース１１５Ａ〜１１５Ｊは、異なる地理的領域１２５Ａ〜１２０−Ｄ内に位置し得る、１つ以上のデータセンター１２０Ａ〜１２０Ｄ内に位置し得る。旧来のサービスプロバイダは、プロバイダにとって最も費用効果の高い態様でリソースをプロビジョニングして割当てるものであり、ユーザは、ユーザのニーズに最良に適合するようにリソースがどのようにまたはどこでプロビジョニングされるかを規定することはできない。加えて、先行技術のシステムは、オンデマンドでリソースを提供するという点で反応的である。しかし、これらのシステムは、現在のデマンドに基づいて要求を予想せず、またはリソースのセットもしくはグループを特定および提供しない。本発明の実施形態は、これらおよび他の問題に対処する。

本発明の局面に従うと、１つ以上の構成可能なコンピューティングリソース１１５Ａ〜１１５Ｊ（すなわち、コントリビューション可能なまたは要求可能なリソースタイプ）は、ネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等であり得る。ＰＯＤは、以下のうちの１つを表わし得る論理エンティティである：（Ｊａｖａサービスの場合と同様に）予めプロビジョニングされた匿名のシングルテナントデプロイメント；または、（データベースサービスの場合と同様に）複数のテナントをサーブするマルチテナントスタック（物理的または仮想的）。たとえば、ＰＯＤは物理的なスタック上へのサービスのデプロイメントである。ＰＯＤは１つ以上のサービスインスタンスを収容することができる。ＰＯＤは先験的に作成することができるか、または、サービスインスタンスが所与の顧客のために作成されるときにオンデマンドで作成することができる。いくつかの例では、ＰＯＤは、サービスを実行させるためのソフトウェアスタックのインスタンス化である。このため、ＰＯＤを用いてサービスを実行する。たとえば、Ｊａｖａサービスに対応するＰＯＤは仮想マシンのスタックを含んでいてもよい。別の例として、データベースサービスのためのＰＯＤは、データベースのインスタンスを含んでいてもよい。ＰＯＤは、サービスをホストすることのできるサブシステムと見なされてもよい。異なるＰＯＤを異なるサービスのために用いてもよい。

図３は、本発明の実施形態に係る配置ポリシーベースのリソース割当ておよび管理の例示的なフローダイアグラム２００を表わす。上述のように、典型的なサービスプロバイダでは、ユーザまたはユーザは、自身が要求した構成可能なコンピューティングリソースがどのようにどこでプロビジョニングされるかを定義することができない。代わりに、構成可能なコンピューティングリソースは典型的に、サービスプロバイダにとって最も費用効果の高い何らかの態様で割当てられる。しかし、サービスプロバイダにとって最良の割当ては、エンドユーザに最良の経験を提供しない場合がある。

本発明の実施形態は、エンドユーザが自身の構成可能なコンピューティングリソース要求に対する配置ポリシー（すなわちリソースポリシー）を定義できるようにすることによって、ファイングレインのリソース割当て機能をユーザに与える。これは、いくつかの利点をエンドユーザに提供し得る。たとえば、ＩａａＳの文脈では、エンドユーザは、特に自身のデータが他のユーザのデータと同一のコンピューティングノード上に格納され得る場合、自身のデータのセキュリティに懸念を抱き得る。ＩａａＳプロバイダはデータセキュリティについて保証するが、これらの保証では不十分なユーザがいる場合もある。ユーザは代わりに、その他のユーザと共有されない自身の専用のコンピューティングノードを望む場合がある。他のユーザは、データセキュリティについてはそれほど懸念を抱いていないが、具体的に定義されたリソース割当てによって最良にサーブされ得る特定のパフォーマンスまたは冗長要件を有する場合がある。したがって、本発明の実施形態は、エンドユーザのニーズに対応するために複数の配置ポリシーを含む。本明細書における配置ポリシーとは、構成可能なコンピューティングリソース（たとえばコンピューティングノード）がユーザにサービスするためにどのように割当てられるかを定義する規則を指す。

本発明の局面に従うと、配置ポリシーは、いくつかの異なる要因に基づいてリソースを割当てることができる。たとえば、ＩａａＳの文脈では、パフォーマンスが問題である場合、コンピューティングリソースは同一のハイパーバイザまたは１セットのハイパーバイザ（たとえば、仮想マシン（ＶＭ）を作成して実行する１つのコンピュータソフトウェア、ファームウェア、および／またはハードウェアである、仮想マシンモニタ（ＶＭＭ）または１セットのＶＭＭ）上で実行されるようにグループ化され得る。これによって、ネットワーキング層への呼出を減少させることによって、異なるハイパーバイザ同士またはハイパーバイザのセット同士の間で分散しているリソースと比較して、ネットワーク通信および要求／応答時間が改善され得る。たとえば、共有のストレージリソースは、パフォーマンスを向上させるために、その関連付けられたコンピュートノードと同一の１つのハイパーバイザまたは１セットのハイパーバイザにおいて最良に割当てられ得る。上述のように、セキュリティの懸念は、専用のハイパーバイザ上でリソースを実行することによって対処され得る。これを用いて、異なるユーザ同士の間の、または別個に維持される必要がある同一のユーザによって制御されるデータのセット同士の間の悪意のアクセスまたは不注意なアクセスからデータを保護することができる。同様に、地理的制約（たとえばリソースをホストするデータセンターの位置についての限定）も、特定のセキュリティ、パフォーマンス、または規制要件を満たすように提供され得る。加えて、特定のリソースを別個のハイパーバイザまたはハイパーバイザのセット上で実行することによって、分離および／または冗長性が維持され得る。これを用いて、（たとえばダウンタイムを減少させるために）他のリソースに影響を及ぼすことなく、故障した場合にデータを保存すること、または、１セットのリソースに対して管理、事務、またはインフラストラクチャ操作（パッチングなど）を実行することができる。いくつかの実施形態では、企業デザイン、統合要件、または他の機能要件は、コンポーネントが同一のハイパーバイザ（たとえばソフトウェア定義インフラストラクチャ（ＳＤＩ））の範囲内でのみ相互運用可能であることを要求し得る。

配置ポリシーの例としては、ＩａａＳの文脈では、割当てられたリソースが、１セットのハイパーバイザに対して配置された仮想マシン上で実行される、専用のハイパーバイザポリシーが挙げられる。この１セットのハイパーバイザは、それらが他のユーザと共有されないという点で専用である。ベストフィット配置ポリシーによって仮想マシンが１セットのハイパーバイザに割当てられて、コンピューティングリソース利用が最適化され得る。たとえば、１セットのハイパーバイザは、リソースを節約し、リソース利用を最大化し、フラグメンテーションを減少させるために、または他のリソース最適化のために、必要に応じて他のユーザと共有され（かつ、他のリソースを実行し）得る。いくつかの実施形態では、配置ポリシーがユーザによって規定されない場合は、ベストフィット配置ポリシーはデフォルトで選択され得る。コンピューティングリソースの特定の部分がともに実行されるべきである場合は、グループフィット配置ポリシーが使用され得る。仮想マシンはともにグループ化され、同一のハイパーバイザプール内の１つ以上のハイパーバイザ上で実行され得る。配置ポリシーは必要に応じてエンドユーザによってカスタマイズされ、上述の、またはその他の配置ポリシーの１つ以上からの特徴を組込むハイブリッド配置ポリシーが作成され得る。

図３に示されるように、ユーザ２０５は、トポロジ定義２１５を含むオーダーまたはサービスサブスクリプション２１０を、リソースマネージャ（たとえば図２に関して説明したリソース管理システム１０５）に提出し得る。トポロジ定義は、メモリ、ＣＰＵの数、ストレージ要件、およびエンドユーザが要求した他の仕様などの、個別の構成可能なコンピューティングリソース（たとえばコンピュートノード）についての要件を含み得る。たとえば、トポロジ定義２１５において示されるように、オーダーまたはサービスサブスクリプション２１０は９個の仮想マシン２２０Ａ〜２２０Ｉを含み、その各々が独自の仕様（たとえばメモリ、ＣＰＵの数、およびストレージ）を有している。９個の仮想マシンは、グループ１が３個の仮想マシン２２０Ａ〜２２０Ｃを含み、グループ２が２個の仮想マシン２２０Ｄ〜２２０Ｅを含み、残りの４個の仮想マシン２２０Ｆ〜２２０Ｉがグループ化されないように、グループ化される。このトポロジ定義２１５は、要求された仮想マシンの一部に対して２つのグループが規定されており、残りの仮想マシンにベストフィットポリシーが適用され得るという点で、ハイブリッド配置ポリシーを表わしている。

いくつかの実施形態では、トポロジ定義は、以下のリスティング１に示されるように、テキストフォーマットで提供され得る。

リスティング１に示されるように、２つのグループにおける１３個の仮想マシンが要求されている。いくつかの実施形態では、グループは、明示的なグループＩＤを有さずに、ＶＭの名前に基づいて特定され得る。リスティング１は、ユーザ関係マネージャ（user relations manager：ＣＲＭ）デプロイメントに対する例示的なトポロジを定義している。トポロジ定義における各ＶＭは、ＶＭ数（ＶＭ＿ＮＯ）、ＣＰＵの規定数（ＶＭ＿ＣＰＵ＿ＣＯＵＮＴ）、メモリの規定量（ＶＭ＿ＭＥＭ＿ＲＥＱＵＩＲＥＤ）、ＶＭ名（ＶＭ＿ＣＯＭＭＥＮＴＳ）、およびオペレーティングシステム定義（ＶＭ＿ＯＳ＿ＴＥＭＰＬＡＴＥ）、およびグループＩＤ（ＧＲＯＵＰ＿ＩＤ）を含む。いくつかの実施形態では、トポロジ定義はより多いまたは少ない要件を含んでいてもよい。たとえば、いくつかの実施形態では、ＶＭ毎のトポロジ定義は、プロキシノードを使用すべきか否かを示すフラッグを含み得る。ＶＭ３〜５などのいくつかのＶＭは、ＣＰＵまたはメモリ要件なしで要求され得、これらのＶＭはデプロイメントのためのＩＰアドレスとしてセットアップされ得る。

上記に示したように、グループは、トポロジ定義に基づいて自動的に特定され得、および／またはトポロジ定義において明示的に定義され得る。たとえば、リスティング１では、「ＲＡＣ＿^*」と名付けられた各仮想マシンが、自動的に特定されてグループ化され得る。いくつかの実施形態では、推奨されるグループがノード名に基づいて特定され、確認のためにユーザに提示され得る。いくつかの実施形態では、明示的なグループＩＤがトポロジ定義に含まれ得る。たとえば、リスティング１に示されるように、ＶＭ１〜５は１のGroup＿ＩＤを含むのに対して、ＶＭ６〜１３は０のGroup＿ＩＤを含む。いくつかの実施形態では、Group＿ＩＤが既存のグループに対応する場合、新たに要求されるＶＭは当該既存のグループに追加され得る。

図３に示されるように、ＩａａＳの文脈では、オーダーまたはサービスサブスクリプション内の要求されたリソースは、トポロジ定義２１５に基づいてリソースプール２２５から割当てられ得る。いくつかの実施形態では、リソースプール２２５はＩａａＳプロバイダによって管理されるハイパーバイザプールであり得る。いくつかの実施形態では、リソースプール２２５は、複数のリモートデータセンターにわたって分散している複数のリソースプールを含み得る。

図４は、本発明の実施形態に係るクライアントデバイスおよびリソースマネージャのより詳細な高レベルのダイアグラム３００を表わす。図４に示されるように、エンドユーザは、ユーザコンピュータ３１０を用いてリソースマネージャ３０５（たとえば図２に関して上述したリソース管理システム１０５）と通信して、リソース要求およびトポロジ定義３２０を含むオーダーまたはサービスサブスクリプション３１５を送信し得る。オーダーまたはサービスサブスクリプション３１５はリソース要求インターフェイス３２５によって受信され、リソースプール３３０およびポリシーマネージャ３３５に転送され得る。リソースプール３３０は、リソースマネージャ３０５によって管理される１つ以上のデータセンターにおける１つ以上のリソースプール（たとえば図３に関して説明したリソースプール２２５）へのインターフェイスの役割を果たし得る。リソースプール３３０は、データセンターインデックス３４０およびリソースインデックス３４５を維持し得る。各インデックス３４０および３４５は、特定のデータセンターにおいて現在利用可能な構成可能なコンピューティングリソース、および／または各データセンターが提供可能な構成可能なコンピューティングリソースを示し得る。たとえば、データセンターインデックス３４０は、接続された各データセンターにおいていくつのハイパーバイザが利用可能であるか、ならびに、それらのハイパーバイザが専用の配置ポリシーについて共有および／または使用され得るか否かを示し得る。同様に、リソースインデックス３４５は、現在利用可能なアプリケーションサーバ、リアルアプリケーションクラスタ（ＲＡＣ）ノード、ストレージノードなどの、どの既存の構成可能なコンピューティングリソースが任意の所与のデータセンターにおいて利用可能であるかを示し得る。リソース割当てモジュール３５０はオーダーまたはサービスサブスクリプション３１５を受信し得、要求されている構成可能なコンピューティングリソースを決定し得、配置ポリシーが存在する場合はどの配置ポリシーに従っているかを決定し得る。リソース割当てモジュール３５０はポリシーマネージャ３３５と通信して、規定された配置ポリシーの要件を特定して決定し得る。ポリシーマネージャ３３５は、デマンドポリシー３６０、コントリビューションポリシー３６５、および配置ポリシー３７０を含む複数のポリシー定義３５５を維持し得る。また、ポリシーマネージャ３３５は、必要に応じてポリシー定義３５５を更新し得るポリシー更新モジュール３７５を含み得る。

図５は、本発明の実施形態に係るコントリビューションポリシーベースのリソース割当ておよび管理システムの簡略化したダイアグラムを表わす。いくつかの実施形態では、ユーザは、さまざまな構成可能なコンピューティングリソース、オーダーもしくはサービスサブスクリプションについてのディスカウント、または他の形態の補償と交換に、不使用のまたは余分な構成可能なコンピューティングリソースをコントリビューションし得る。たとえば、プライベートクラウドインフラストラクチャプロバイダなどのサービスプロバイダは、複数の異なるユーザおよび／または組織から、構成可能なコンピューティングリソースの共有プールから、オーダーまたはサービスサブスクリプションをサービスし得る。各ユーザまたは組織（たとえば顧客）は、完全には利用され得ないか、またはもはや使用され得ない、たとえばハイパーバイザ、ストレージノード、または他の構成可能なコンピューティングリソースなどの、自身のハードウェアおよび／またはソフトウェアリソースを所有または制御し得る。図５に示される実施形態では、これらのユーザおよび／または組織は、支払と交換に、および／またはコントリビューションしているユーザが使用する予定の他の構成可能なコンピューティングリソースと交換に、自身の不使用の構成可能なコンピューティングリソースをコントリビューションすることができる。たとえば、ＩａａＳの文脈では、ユーザは、ユーザが必要としない余分なストレージノードを有する場合がある。自身の余分なストレージノードをコントリビューションするのと交換に、ユーザはＲＡＣノードを要求することが可能であり得る。ユーザは、ハイパーバイザ、ソフトウェア、ネットワーク、ＰＯＤ、または他の構成可能なコンピューティングリソースもコントリビューションし得る。

図５に示されるように、各ユーザ４０５はコントリビューション可能なリソース４１０と関連付けられ得る。いくつかの実施形態では、コントリビューション可能なリソース４１０はユーザによって管理され、完全には利用され得ないか、またはもはや使用され得ない、たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等のハードウェアおよび／またはソフトウェアのタイプのリソースであり得る。各ユーザ４０５は、コントリビューションされているリソースの記述を含むリソース提出４１５をリソースマネージャ４２０（たとえば図１に関して上述したリソース管理システム１０５）に送信し得る。たとえば、記述は、コントリビューションされているリソースのタイプ（たとえばサーバ）と、リソースの名前、メモリ、ＣＰＵ情報、オペレーティングシステム、追加のハードウェアおよび／またはソフトウェア等のリソースの仕様とを含み得る。リソースマネージャ４２０は、現在のリソース可用性および／またはリソースデマンドに鑑みてコントリビューション可能なリソース４１０を評価し、ユーザ４０５がコントリビューション可能なリソース４１０と交換に受信し得る要求可能なリソース４２５の１つ以上のタイプを定義する交換オファーを戻し得る。いくつかの実施形態では、要求可能なリソース４２５はリソースマネージャ４２０によって管理され、ユーザにサービスするのに利用可能な、たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等の、ハードウェアおよび／またはソフトウェアタイプのリソースであり得る。交換（たとえば、要求可能なリソース４２５に対してコントリビューション可能なリソース４１０）がコントリビューションしているユーザ４０５のニーズを満たす場合、ユーザ４０５はオファーを受付け、コントリビューション可能なリソース４１０の制御をリソースマネージャ４２０に引継ぐことができる。たとえば、ユーザ４０５は、コントリビューション可能なリソース４１０へのアクセスおよびリソース４１０に対する制御を提供するアクセスクレデンシャル（たとえばユーザ名およびパスワード）をリソースマネージャ４２０に提供し得る。次いで、ユーザ４０５は、交渉した要求可能なリソース４２５をリソースマネージャ４０６から受信し得る。

これは、ユーザが必要としない構成可能なコンピューティングリソースの１つのタイプを、ユーザが必要としない構成可能なコンピューティングリソースの異なるタイプと交換することができるユーザにとって有利である。いくつかの実施形態では、ユーザが交換に受信する構成可能なコンピューティングリソース（たとえば要求可能なリソース）は、ユーザが所望の構成可能なコンピューティングリソースをセットアップする必要なしに、リソースプール内の任意のハイパーバイザ上で実行されていてもよい。たとえば、ユーザはコンピュートノードを購入しているが、そのコンピュートノード上で構成可能なコンピューティングリソースをセットアップする際に特定の専門知識をまったく有していない場合がある。このコンピュートノードをコントリビューションすることによって、ユーザは、ユーザによるいずれのセットアップも必要とせずに、異なるコンピュートノード上で実行される、所望の構成可能なコンピューティングリソースを交換に受信することができる。これは組織によって内部でも使用され得る。大規模なソフトウェア開発会社などの組織は、予測される必要性に基づいて、構成可能なコンピューティングリソースを組織の異なるサブグループに割当て得る。新たなプロジェクトを実施するために、または市場の需要の変化のためにサブグループの変更が必要となった場合、組織が構成可能なコンピューティングリソースをサブグループ同士の間で再割当てすることは困難であり得る。コントリビューションポリシーベースのリソース管理および割当てシステムを用いて、サブグループは、組織による再割当てを必要とせずに、リソースを自然発生的にリバランスすることができる。コントリビューションポリシーは、デマンドに基づいてリソースコントリビューションについての「交換レート」（たとえばコントリビューション可能なリソースと要求可能なリソースとの間のマッピング）を定義することができ、かつ、動的に更新され得る。同様に、このようなコントリビューションポリシーベースのシステムは複数の組織にわたって使用され得る。リソースマネージャは、組織がそれらのコンピューティングリソースをコントリビューションするための標準化プロトコルを提供する、信頼できるパーティの役割を果たし得る。これは、ある組織からの機密情報がライバル組織のコンピューティングリソースに晒されないことを保証するために、上述の配置ポリシーベースのシステムと組み合わされて用いられ得る。

図６は、本発明の実施形態に係るクライアントデバイスおよびリソースマネージャのより詳細な高レベルのダイアグラム５００を表わす。図６に示されるように、リソースマネージャ５０５（たとえば、それぞれ図２、図４および図５に関して上述したリソース管理システム１０５またはリソースマネージャ３０５；４２０）は、リソース提出インターフェイス５１０、ユーザアカウント履歴５１５およびデマンドモニタ５２０を含むいくつかのサブシステムまたはモジュールを含む。加えて、リソースマネージャ５０５は、ポリシーマネージャ５２５、リソースプール５３０、およびリソース要求インターフェイス５３５（たとえば、図３に関して上述したポリシーマネージャ３３５、リソースプール３３０、およびリソース要求インターフェイス３２５）を含み得る。これらのサブシステムは、ソフトウェア（たとえばプログラムコード、１つ以上のプロセッサによって実行可能な命令）で、ハードウェアで、またはこれらの組み合わせで実現され得る。いくつかの実施形態では、ソフトウェアはメモリ（たとえば非一時的なコンピュータ読取可能媒体）内に、メモリデバイス上に、または何らかの他の物理メモリ上に格納され得、１つ以上の処理ユニット（たとえば１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のＧＰＵ等）によって実行され得る。

図６に表わされるように、ユーザコンピュータ５４０はブラウザ５４５などのウェブアプリケーションを実行し得、ブラウザ５４５は、ユーザコンピュータ５４０のユーザがリソース提出をリソースマネージャ５０５に送信して、構成可能なコンピューティングリソース（たとえばコントリビューション可能なリソース）をリソースマネージャ５０５にコントリビューションすることを可能にする。リソース提出は、コントリビューションされているリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）のタイプと、リソースの名前、メモリ、ＣＰＵ情報、オペレーティングシステム、追加のハードウェアおよび／またはソフトウェア等のリソースの仕様とを規定し得る。コントリビューション可能なリソースは、ユーザがネットワーク５５５を介してアクセス可能なローカルリソース５５０Ａおよび／またはリモートリソース５５０Ｂなどのように、ユーザによって所有またはそうでなければ制御（たとえば管理）される（たとえば、ユーザがもはや完全には使用していないか部分的に使用しているリソース）。

一実施形態では、リリソース提出インターフェイス５１０はリソース提出を受信してポリシーマネージャ５２５と通信し、リソース提出に適用され得る１つ以上のコントリビューションポリシーを特定し得る。たとえば、各コントリビューションポリシーは、コントリビューションされているリソースのタイプと交換に提供され得る要求可能なリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）の１つ以上のタイプを規定し得る。適用可能なコントリビューションポリシーが特定されると、ポリシーマネージャ５２５は、リソース提出に対して特定された要求可能なリソースの１つ以上のタイプを戻すことができる。したがって、各コントリビューションポリシーは要求可能なリソースの１つ以上のタイプのオファーを効果的に表わし、ユーザはコントリビューション可能なリソースと交換にこれを受付けるか拒絶することができる。ユーザが要求可能なリソースの１つ以上のタイプのうちの１つを選択または受付けると、ユーザアカウント履歴５６０は、コントリビューション履歴５６５においてユーザによってコントリビューションされているリソースを示すように更新され得る。その後、ユーザは、以前に選択または受付けられたタイプの要求可能なリソースのリソース要求を含むオーダーまたはサービスサブスクリプションを提出し得、リソースマネージャ５０５は要求可能なリソースの割当てで応答し得る。加えて、ユーザがオーダーまたはサービスサブスクリプションを提出すると、リソース要求履歴５７０はリソースの要求で同様に更新され得る。ユーザのコントリビューションおよびオーダーまたはサブサービススクリプション履歴を追跡することによって、リソースマネージャ５０５は、ユーザがコントリビューション可能なリソースと交換に合意した要求可能なリソースを受信したか否かを追跡することができる。

いくつかの実施形態では、コントリビューションポリシーは、特定のユーザのコントリビューション履歴に基づいて特定のユーザに対して調整され得る。たとえば、多くの構成可能なコンピューティングリソースをコントリビューションした履歴を有するユーザは、コントリビューション履歴が限られているユーザよりも有利なオファー（たとえば、現在のデマンドに基づいて提供されるであろうよりも、コントリビューションと交換に、より多くの構成可能なコンピューティングリソース）を受信し得る。

代替的な実施形態では、リソース提出インターフェイス５１０は、１つ以上の要求可能なリソースと交換にリソースの１つ以上のタイプをコントリビューションするオファーを含むオーダーまたはサービスサブスクリプションを受信し得、ポリシーマネージャ５２５と通信して、当該オファーが満たされ得るか否かを判断する。たとえば、オーダーまたはサービスサブスクリプションは、ユーザが好む１つ以上の要求可能なリソースと交換にコントリビューションされ得る１つ以上のリソースを定義し得る。加えて、オーダーまたはサービスサブスクリプションは、１つ以上の要求可能なリソースを提供し得る１人以上のユーザおよび／または１つ以上の地理的領域を定義し得る。したがって、各オーダーまたはサービスサブスクリプションは、コントリビューション可能なリソースの１つ以上のタイプを、ポリシーマネージャ５２０が受付け得る、拒絶し得る、または無効にし得る（たとえば、ポリシーマネージャ５２５によって維持されるコントリビューションポリシーに基づいて構成可能なコンピューティングリソースの１つ以上の他のタイプを提案し得る）要求可能なリソースの１つ以上のタイプと交換するオファーを効果的に表わす。ポリシーマネージャ５２５がオファーを受付けると、ユーザアカウント履歴５６０は、コントリビューション履歴５６５においてユーザによる１つ以上のリソースのコントリビューションを示すように更新され得る。加えて、リソース要求履歴５７０は、ユーザが要求した１つ以上のリソースで同様に更新され得る。オファーの受付けは、コントリビューション可能なまたは要求可能なリソースを提供し得る１人以上のユーザから付与される許可、コントリビューション可能なまたは要求可能なリソースのタイプの可用性および／またはデマンド、コントリビューション可能なリソースのタイプと要求可能なリソースのタイプとの交換の同等性、ポリシーマネージャ５２５によって維持されるコントリビューションポリシーなどを含むがこれらに限定されるものではないいくつかの要因に基づいて、ポリシーマネージャ５２５によって決定され得る。このような実施形態では、プロジェクトまたはジョブについて第１のユーザ「Ａ」が第２のユーザ「Ｂ」と連携し、１つ以上のリソースを互いに共有してプロジェクトもしくはジョブの各ユーザの部分を完了すること、および／または互いに１つ以上のリソースを交換するための同意を交わすことが可能である。

いくつかの実施形態では、ポリシーマネージャ５２５によって維持されるリソースポリシー（たとえばコントリビューションポリシー）は、コントリビューション可能なおよび／または要求可能なリソースの異なるタイプに対する現在のデマンドに基づいて動的に更新され得る。デマンドモニタ５７５は、オーダーまたはサービスサブスクリプションがリソース要求インターフェイス５３５からポリシーマネージャ５２５に転送されると、要求インターセプタ５８０を用いて当該オーダーまたはサービスサブスクリプションをインターセプトまたは受信し得る。いくつかの実施形態では、デマンドモニタ５７５は、各オーダーまたはサービスサブスクリプションをインターセプトまたは受信することなく、ポリシーマネージャ５２５から報告期間の最後に（たとえば毎日または毎時間）オーダーまたはサービスサブスクリプションをバッチで受信し得る。デマンドモニタ５７５がオーダーまたはサービスサブスクリプションをインターセプトまたは受信すると、デマンドモニタ５７５はオーダーまたはサービスサブスクリプションをポリシーマネージャ５２５に転送し、オーダーまたはサービスサブスクリプションのコピーを保存し得る。要求パーサ５８３はオーダーまたはサービスサブスクリプションを分析して、要求されている構成可能なコンピューティングリソース、リソースを要求したエンティティ、およびリソースが要求された時間を決定し得る。次いで、パースされたオーダーまたはサービスサブスクリプションはアグリゲート要求履歴５８５に追加され得る。アグリゲート要求履歴５８５は、時間、リクエスタ、および要求されたリソースでソートされたオーダーまたはサービスサブスクリプションの実行リストを格納するデータ構造を含み得る。リアルタイムデマンドカルキュレータ５９０は、特定の期間または要求ボリュームにわたってアグリゲート要求履歴５８５を分析し、その期間中のデマンドを決定し得る。リソースデマンドコリレータ５９５もアグリゲート要求履歴５８５を分析し、オーダーまたはサービスサブスクリプションにおけるパターンを決定し得る。所与の構成可能なコンピューティングリソースが要求されると、動的リソースセット内の他のリソースも要求されたリソースと通信するようにプロビジョニングおよび構成されるように、構成可能なコンピューティングリソースの動的リソースセットまたはグループが、オーダーまたはサービスサブスクリプションパターンに基づいて定義され得る。

図７〜図１０は、本発明の実施形態に係るコントリビューションポリシーベースの、およびデマンドポリシーベースのリソース割当てのために実行される処理を表わす簡略化したフローチャートを表わす。図７〜図１０のステップは、たとえば図１〜図６および図１１〜図１５の環境において実現され得る。本明細書に記載されるように、図７〜図１０のフローチャートは、本発明のさまざまな実施形態に係るシステム、方法、およびコンピュータプログラムプロダクトのアーキテクチャ、機能、および可能な実装例の動作を示す。この点において、フローチャートまたはブロックダイアグラム内の各ブロックは、規定された論理機能を実現するための１つ以上の実行可能な命令を含むモジュール、セグメント、またはコードの一部を表わし得る。また、いくつかの代替的な実装例では、ブロック内に示される機能は図に示される順序以外でも起こり得ることに留意すべきである。たとえば、連続して示される２つのブロックは、実際は、実質的に同時に実行されてもよく、または、ブロックは、関連の機能に依存して、場合によっては逆の順序で実行されてもよい。また、ブロックダイアグラムおよび／またはフローチャート図の各ブロック、ならびにブロックダイアグラムおよび／またはフローチャート図中のブロック同士の組み合わせは、規定された機能もしくは行為を実行する専用のハードウェアベースのシステム、または専用のハードウェアとコンピュータ命令との組み合わせによって実現可能であることに留意すべきである。

図７は、ポリシーマネージャによって維持されるコントリビューションポリシーを用いるコントリビューションポリシーベースのリソース割当てのために実行される処理を表わす簡略化したフローチャート６００を表わす。ステップ６０５において、コントリビューション可能なリソースを特定するリソース提出が受信され得る。たとえば上述のように、リソース提出インターフェイス５１０はリソース提出をユーザコンピュータ５４０から受信し、リソース提出をポリシーマネージャ５２５に転送し得る。リソース提出は、コントリビューションされているリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）のタイプと、リソースの名前、メモリ、ＣＰＵ情報、オペレーティングシステム、追加のハードウェアおよび／またはソフトウェア等のリソースの仕様とを規定し得る。コントリビューション可能なリソースは、ローカルリソース５５０Ａおよび／またはリモートリソース５５０Ｂなどのように、ユーザによって所有またはそうでなければ制御（たとえば管理）される（たとえば、ユーザがもはや完全には使用していないか部分的に使用しているリソース）。

ステップ６１０において、リソース提出に適用され得る１つ以上のコントリビューションポリシーが特定され得る。たとえば、各コントリビューションポリシーは、コントリビューションされているリソースのタイプと交換に提供され得る要求可能なリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）の１つ以上のリソースタイプを規定し得る。１つ以上のコントリビューションポリシーの特定は、リソース提出に基づいてコントリビューション可能なリソースのリソースタイプを決定することと、リソースタイプが（１つ以上のコントリビューションポリシー内の）コントリビューション可能なリソースの１つ以上のリソースタイプと一致すると判断することとを含み得、コントリビューション可能なリソースの１つ以上のリソースタイプは、１つ以上のコントリビューションポリシーにおいて要求可能なリソースの１つ以上のリソースタイプにマップしている。したがって、各コントリビューションポリシーは要求可能なリソースの１つ以上のタイプのオファーを効果的に表わし、ユーザはコントリビューション可能なリソースと交換にこれを受付けるか拒絶することができる。適用可能なコントリビューションポリシーが特定されると、ポリシーマネージャ５２５は、リソース提出に対して特定された要求可能なリソースの１つ以上のタイプを戻すことができる。いくつかの実施形態では、１つ以上のコントリビューションポリシーの特定は、ユーザが利用可能な要求可能なリソースの１つ以上のタイプ、コントリビューション可能なおよび／または要求可能なリソースの１つ以上のタイプのデマンドレベル、ならびにユーザのリソースコントリビューションの履歴を含む任意の数の要因に基づいてより狭く調整または定義されるコントリビューションポリシーを用いてさらに展開され得、たとえば、多くのリソースをコントリビューションした履歴を有するユーザは、コントリビューション履歴が限られているユーザよりも有利なコントリビューションポリシーまたはオファー（たとえば、現在のデマンドに基づいて提供されるであろうよりも、コントリビューションと交換に、より多くのリソース）を受信し得る。

ステップ６１５において、コントリビューションされているリソースのタイプと交換に提供され得る要求可能なリソースの１つ以上のリソースタイプの特定が、特定された１つ以上のコントリビューションポリシーに基づいてユーザに送信され得る。たとえば、リソース提出インターフェイス５１０は、特定された１つ以上のコントリビューションポリシーに基づいて、要求可能なリソースの１つ以上のリソースタイプの特定をポリシーマネージャ５２５からユーザコンピュータ５４０に送信し得る。ステップ６２０において、要求可能なリソースの少なくとも１つのタイプがユーザによって拒絶されると、拒絶が受信され得る。たとえば、上述のように、リソース提出インターフェイス５１０は、要求可能なリソースの少なくとも１つのタイプの拒絶をユーザコンピュータ５４０から受信し得る。ステップ６２５において、要求可能なリソースの少なくとも１つのタイプがユーザによって選択または受付けられると、要求可能なリソースの少なくとも１つのタイプの選択または受付けを示す情報が受信され得る。たとえば、上述のように、リソース提出インターフェイス５１０は、要求可能なリソースの少なくとも１つのタイプの選択または受付けを示す情報をユーザコンピュータ５４０から受信し得る。いくつかの実施形態では、当該情報は、リソース提出において特定されたコントリビューション可能なリソースへのアクセスならびに当該リソースに対する制御を提供するアクセスクレデンシャル（たとえばユーザ名およびパスワード）をさらに含み得る。

ステップ６３０において、ユーザアカウント履歴およびリソースプールは、要求可能なリソースの少なくとも１つのタイプの選択または受付けから実現される変更を示すように更新され得る。たとえば、ユーザアカウント履歴５６０は、コントリビューション履歴５６５において要求可能なリソースの少なくとも１つのタイプと交換に提供されるコントリビューション可能なリソースを示すように更新され得る。加えて、リソースプール５３０内のデータセンターインデックスおよび／またはリソースインデックスは、リソースマネージャ（たとえばサービスプロバイダによって管理される分散システム）の１人以上のユーザにサービスするためにコントリビューション可能なリソースの可用性を示すように更新され得る。

ステップ６３５において、要求可能なリソースに対するオーダーまたはサービスサブスクリプションがユーザから受信され得る。たとえば、リソース提出インターフェイス５１０は、オーダーまたはサービスサブスクリプションをユーザコンピュータ５４０から受信し、オーダーまたはサービスサブスクリプションをリソースマネージャ５０５に転送し得る。ステップ６４０において、要求可能なリソースが、以前のリソース提出交換を通してユーザが利用可能であるタイプ（すなわち、コントリビューション可能なリソースと交換に以前に選択または受付けられたタイプの要求可能なリソース）であるか否かについて判断がなされ得る。たとえば、リソースマネージャ５０５はユーザアカウント履歴５６０を確認して、要求可能なリソースが、コントリビューション可能なリソースと交換に約束されたタイプであるか否かを判断し得る。ステップ６４５において、要求可能なリソースがコントリビューション可能なリソースと交換に約束されたタイプではない場合、要求可能なリソースは、本明細書に記載される配置もしくはデマンドポリシーベースのシステムなどの他のオーダーもしくはサービスサブスクリプションポリシー、および／または旧来のオーダーもしくはサービスサブスクリプションポリシーに従ってユーザに割当てられ得る。

ステップ６５０において、要求可能なリソースが、コントリビューション可能なリソースと交換に約束されたタイプである場合、要求可能なリソースは、以前に特定された１つ以上のコントリビューションポリシーに基づいてユーザに割当てられ得る。たとえば、要求可能なリソースがコントリビューション可能なリソースと交換に約束されたタイプである場合、リソースマネージャ５０５は、ユーザまたは顧客にサービスするためにリソースプール５３０から要求可能なリソースを割当てて構成し、要求可能なリソースが割当てられたという確認メッセージをユーザまたは顧客に送信し得る。要求可能なリソースは、ユーザによって選択または受付けられたタイプの任意の構成可能なコンピューティングリソースであり得る。たとえば、選択された要求可能なリソースのタイプがＲＡＣノードであった場合は、通常は共有される一組のデータファイルに対して１つのインスタンスのみを実行する１つのＲＡＣノードに対する要求が、ユーザまたは顧客にサービスするために割当てられて構成され得る。

いくつかの実施形態では、要求されるリソースがそこから割当てられるリソースプール５３０は、ＩａａＳプロバイダによって管理されるハイパーバイザプールであり得る。いくつかの実施形態では、リソースプール５３０は、複数のリモートデータセンターにわたって分散している複数のリソースプールを含み得る。理解されるべきであるように、要求されたリソースの割当ておよび構成は、図３および図４に関して上記に詳述したように、トポロジ定義および配置ポリシーに基づいてさらに定義され得る。

ステップ６５５において、ユーザアカウント履歴およびリソースプールは、要求可能なリソースに対するオーダーまたはサービスサブスクリプションから実現される変更を示すように更新され得る。たとえば、ユーザアカウント履歴５６０は、リソース要求履歴５７０において要求可能なリソースがユーザに割当てられたことを示すように更新され得る。ユーザのコントリビューションおよびオーダーまたはサブサービススクリプション履歴を追跡することによって、リソースマネージャ５０５は、ユーザがコントリビューション可能なリソースと交換に合意した要求可能なリソースを受信したか否かを追跡することができる。加えて、リソースプール５３０内のデータセンターインデックスおよび／またはリソースインデックスは、ユーザにサービスするために要求可能なリソースの割当てを示すように更新され得る。

図８は、ユーザによって提供されるオーダーまたはサブサービススクリプションを用いるコントリビューションポリシーベースのリソース割当てのために実行される処理を表わす簡略化したフローチャート７００を表わす。ステップ７０５において、１つ以上の要求可能なリソースと交換に１つ以上のリソースをコントリビューションするオファーを含むオーダーまたはサービスサブスクリプションが受信され得る。たとえば、上述のように、リソース提出インターフェイス５１０はオーダーまたはサービスサブスクリプションをユーザコンピュータ５４０から受信し、オーダーまたはサービスサブスクリプションをポリシーマネージャ５２５に転送し得る。オーダーまたはサービスサブスクリプションは、リソースマネージャ５０５によって管理されるリソースのプールにコントリビューションすることをユーザが意図しているローカルリソース５５０Ａおよび／またはリモートリソース５５０Ｂなどのように、ユーザによって所有またはそうでなければ制御される１つ以上のリソースを規定し得る。加えて、リソース提出は、ユーザが使用するのに好まれる１つ以上の要求可能なリソースを規定し得る。いくつかの実施形態では、オーダーまたはサービスサブスクリプションは、１つ以上のコントリビューション可能なリソースがサービスすることが意図されている１人以上のユーザ、１つ以上の要求可能なリソースを提供し得る１人以上のユーザ（デフォルトはリソースプールであり得る）、および／または１つ以上の要求可能なリソースを提供し得る１つ以上の地理的領域をさらに特定し得る。

ステップ７１０において、オファーが受付けられ得るか、拒絶され得るか、または無効にされ得る。たとえば、オーダーまたはサービスサブスクリプションは、コントリビューション可能なリソースの１つ以上のタイプを、ポリシーマネージャ５２５が受付け得る、拒絶し得る、または無効にし得る要求可能なリソースの１つ以上のタイプと交換するオファー（たとえば、図７のステップ６０５および６１０に関して説明したのと同様のプロセスにおいてポリシーマネージャ５２５によって維持されるコントリビューションポリシーに基づく要求可能なリソースの１つ以上の他のタイプのカウンターオファー）を効果的に表わし得る。オーダーまたはサービスサブスクリプションの受付け、拒絶、または無効化は、コントリビューション可能なおよび／または要求可能なリソースを提供し得る１人以上のユーザから付与される許可、コントリビューション可能なおよび／または要求可能なリソースの可用性および／またはデマンド、コントリビューション可能なリソースのタイプと要求可能なリソースのタイプとの交換の同等性、ポリシーマネージャ５２５によって維持されるコントリビューションポリシーなどを含むがこれらに限定されるものではない多数の要因に基づいて、ポリシーマネージャ５２５によって決定され得る。

ステップ７１５において、オファーが拒絶されると、オーダーまたはサービスサブスクリプションの拒絶がユーザに送信され得、プロセスが終了する。ステップ７２０において、オファーのカウンタオファーが出されると、１つ以上のコントリビューションポリシーに基づいてオーダーまたはサービスサブスクリプションを少なくとも一部満たしていると特定される要求可能なリソースの１つ以上の他のタイプがユーザに送信され得る。たとえば、リソース提出インターフェイス５１０は、図７のステップ６１０および６１５に関して説明したのと同様のプロセスにおいて、要求可能なリソースの１つ以上の他のタイプをポリシーマネージャ５２５からユーザコンピュータ５４０に送信し得る。その後、プロセスは、図７のステップ６２０〜６５５に関して説明したのと同様の態様で継続し得る。

ステップ７２５において、オファーが受付けられると、オーダーまたはサービスサブスクリプションの受付けがユーザに送信され得る。たとえば上述のように、リソース提出インターフェイス５１０はオファーの受付けをポリシーマネージャ５２５から受信し、受付けをユーザコンピュータ５４０に転送し得る。ステップ７３０において、コントリビューションされている１つ以上のリソースへのアクセスおよび当該リソースに対する制御を提供するアクセスクレデンシャル（たとえばユーザ名およびパスワード）が受信され得る。たとえば、リソース提出インターフェイス５１０はアクセスクレデンシャルをユーザコンピュータ５４０から受信し、アクセスクレデンシャルをリソースマネージャ５０５に転送し得る。ステップ７３５において、ユーザアカウント履歴およびリソースプールは、オファーの受付けから実現される変更を示すように更新され得る。たとえば、ユーザアカウント履歴５６０は、コントリビューション履歴５６５において１つ以上の要求可能なリソースと交換にユーザによってコントリビューションされる１つ以上のリソースを示すように更新され得る。加えて、リソースプール５３０内のデータセンターインデックスおよび／またはリソースインデックスは、リソースマネージャ（たとえばサービスプロバイダによって管理される分散システム）の１人以上のユーザにサービスするためにコントリビューションされる１つ以上のリソースの可用性を示すように更新され得る。

ステップ７４０において、オーダーまたはサービスサブスクリプションにおいて特定された１つ以上の要求されたリソースが割当てられ得る。たとえば、リソースマネージャ５０５は、ユーザにサービスするためにリソースプール５３０から１つ以上の要求されたリソースを割当て、１つ以上の要求されたリソースが割当てられたという確認メッセージを送信し得る。いくつかの実施形態では、リソースプール５３０はＩａａＳプロバイダによって管理されるハイパーバイザプールであり得る。いくつかの実施形態では、リソースプール５３０は、複数のリモートデータセンターにわたって分散している複数のリソースプールを含み得る。理解されるべきであるように、１つ以上の要求されたリソースの割当ては、図３および図４に関して上記に詳述したように、トポロジ定義および配置ポリシーに基づいてさらに定義され得る。

ステップ７４５において、ユーザアカウント履歴およびリソースプールは、オーダーまたはサービスサブスクリプションの受付けから実現される変更を示すように更新され得る。たとえば、ユーザアカウント履歴５６０は、リソース要求履歴５７０において１つ以上の要求可能なリソースがユーザに割当てられたことを示すように更新され得る。ユーザのコントリビューションおよび要求履歴を追跡することによって、リソースマネージャ５０５は、ユーザが１つ以上のコントリビューション可能なリソースと交換に合意した１つ以上の要求可能なリソースを受信したか否かを追跡することができる。加えて、リソースプール５３０内のデータセンターインデックスおよび／またはリソースインデックスは、ユーザにサービスするために１つ以上の要求されたリソースの割当てを示すように更新され得る。

上述のように、かつ図６に示すように、リソースマネージャ５０５は、構成可能なコンピューティングリソース（たとえばネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等）に対するデマンド、および構成可能なコンピューティングリソースの特定のセットに対するデマンドを追跡可能なデマンドモニタ５７５を含み得る。このような監視によって、リソースマネージャ５０５は、カスタマイズ可能なデマンドポリシーに基づいて、複雑な有線接続されたリソースセット／グループを予想して予め作成することができる。これは、管理者による介入を必要とせずに自動的に実行され得る。これによってセットアップ時間が減少し、セットアップ時間がほとんどないか全くなしでエンドユーザの要求に応答してエンドユーザが必要としている構成可能なコンピューティングリソース（すなわちリソース）を提供することによって、エンドユーザの体験が向上する。

いくつかの実施形態では、デマンドポリシーはリソース同士の間の公知の従属に基づいて生成され得る。たとえば、第２のリソースも要求しなければ第１のリソースを使用できない場合は、いずれか一方のリソースに対する要求は他方に対する要求を自動的に含み得る。加えて、デマンドポリシーは公知の「トレンド」に基づき得る。たとえば、リソースのアップグレードまたは新たなリリースの発売が促進されている場合、リソースの新バージョンに対する要求の数が受信されるにつれ、予め作成されたリソースの旧バージョンの数は減少し得る。たとえば、あるアプリケーションの第１のバージョンは第１のリリースデータベースを必要とし得るのに対して、当該アプリケーションの第２のバージョンは第２のリリースデータベースを必要とし得る。アプリケーションの第２のバージョンが採用されると、アプリケーションの第２のバージョンからの要求またはジョブの数が増加することになる。このアクティビティが増加すると、アプリケーションと関連付けられているデマンドポリシーが、第２のリリースデータベースに対するデマンドの増加を示すように自動的に更新され得る。このデマンドポリシーが適用されると、データベースの第２のリリースのためのセットアップがデータベースの第１のリリースよりも優先され、利用可能な第２のリリースデータベースの数が徐々に増加する。いくつかの実施形態では、さらに、さまざまなリソースの新バージョンのリリース日を用いて、リソースの各バージョンがどれだけ予め作成されるかを自動的に更新することができる。

いくつかの実施形態では、デマンドモニタによって計算されるリアルタイムデマンドを用いて、デマンドが増加しているリソースを予め作成することができる。たとえば、リソース要求の特定のパーセンテージがＰＯＤの特定のタイプを含む場合は、デマンドポリシーは、ＰＯＤのその特定のタイプをより多く自動的に予め作成するように更新され得る。加えて、リソースの中には、特定の１セットのリソースが正確に機能することを要求するものもある。たとえば、アプリケーションスイートは、データベースおよびエンタープライズマネージャをさらに要求し得る。これらの公知の従属は、アプリケーションスイートが要求されると、従属リソースもアプリケーションスイートと通信するようにプロビジョニングおよび構成されるように、デマンドポリシーに格納され得る。いくつかの実施形態では、当該１セットのリソースはデマンドに基づいて動的に変化し得る。たとえば、リソースデマンドコリレータ５９５は、（たとえば追加のリソースを含むリソース要求のパーセンテージに基づいて）従属リソースに加えて規則的に要求される追加のリソースを特定し得る。これらの実施形態では、デマンドポリシーはこれらの追加のリソースを含むように動的に更新され得る。ともに用いられるリソースのグループに対するデマンドを監視することによって、デマンドポリシーは個々のリソースの代わりにリソースのセットを予め作成し、ユーザが要求したときにリソースをセットアップするのに必要な時間を減少させることができる。

いくつかの実施形態では、既存のリソースのライフサイクルは、現在のデマンドおよびリソース使用に基づいて同様に管理され得る。リソースがもはや使用されていない場合、当該リソースは典型的にリソースマネージャによってクリーンにされてリソースプールに戻される。リソースがもはや使用されていないときを決定することは、使用（たとえば、どれほど頻繁に当該リソースが使用されるか）またはヘルス（たとえば、他のリソースが当該リソースに接続可能か、当該リソースが一杯であるか、等）に基づき得る。使用の欠如、または故障は、リソースに対するクリーンアップまたはメンテナンスアクションをもたらし得る。しかし、使用されていないリソースについてのこの追加のクリーンアップステップは不要であり、需要のあるリソースにとっては時間が掛かる。特定のリソースの利用期間／トレンドを追跡することによって、リソースマネージャはリソースがこれまでに使用されたことがあるか否かを判断することができる。たとえば、ストレージノードが作成されているが、当該ノードにデータが格納されたことがない、または当該ノードからデータが取出されたことがない場合は、リソースマネージャは当該リソースは使用されていないと判断することができ、当該リソースを最初にクリーンにすることなく当該リソースを他のユーザが利用できるようにすることができる。

図９は、本発明の実施形態に係るデマンドポリシーベースのリソース割当てのために実行される処理を表わす簡略化したフローチャート８００を表わす。ステップ８０５において、サービスのオーダーまたはサブスクリプションがインターセプトまたは受信され得る。たとえば図６に関して上述したように、デマンドモニタ５７５は要求インターセプタ５８０を用いてリアルタイムでオーダーをインターセプトまたは受信した後に、リソースマネージャ５０５におけるさらに他の処理のために当該オーダーをパスし得る。いくつかの実施形態では、オーダーは非リアルタイム処理のためにバッチで周期的にデマンドモニタ５７５に送信され得る。ステップ８１０において、オーダーをパースして、１つ以上の要求されたリソース、リクエスタ、および他の要求データ（たとえば要求時間）を含む要求データを特定することができる。たとえば、要求パーサ５８３はオーダー（すなわち入力データ）を受け、オーダー内に要求データ（たとえば１つ以上の要求されたリソース、リクエスタ、および他の要求データ）の構造表現を提供するデータ構造（たとえばパースツリーまたは他の階層構造）を構築し得、これによってパターンマッチングおよびデータの抽出が可能になる。

ステップ８１５において、要求データはアグリゲート履歴データ構造に追加され得る。たとえば、オーダーからの要求データの構造表現を提供するデータ構造が、リソースプール内のリソースについての要求データのアグリゲートを含むアグリゲート履歴データ構造５８５に追加され得る。アグリゲート履歴データ構造５８５は、サービスに対する以前にパースされた任意の数のオーダーまたはサブスクリプションからのデータ構造を含む。各オーダーは、オーダーが受信されるとタイムスタンプされ得、アグリゲート履歴データ構造５８５はリソース、リクエスタ、または他の要求データによってソートされ得る。ステップ８２０において、所与のリソース（たとえばオーダーにおいて要求されたリソースまたはリソースプール内の任意のリソース）に対して、リソースプール内のリソースについての要求データのアグリゲートから取得される現在の要求ボリュームを用いて、当該所与のリソースに対するリアルタイムデマンドが計算され得る。たとえば、特定の期間（ローリング平均、履歴期間など）において、所与のリソースを含むオーダーのパーセンテージが、リアルタイムデマンドカルキュレータ５９０およびアグリゲート履歴データ構造５８５を用いて決定され得る。加えて、オーダーのパーセンテージは、リアルタイムデマンドカルキュレータ５９０およびアグリゲート履歴データ構造５８５を用いて、リソースプール内の他のリソースに相対的な所与のリソースについて計算されたリアルタイムデマンドと相関付けられ得る。

ステップ８２５において、ステップ８０５で受信したオーダーは、要求データの少なくとも１つのコンポーネントが、当該オーダーと、サービスに対する以前にパースされたオーダーまたはサブスクリプションからの少なくとも１つの他のオーダーとの間で同一であることに基づいて、当該少なくとも１つの他のオーダーと相関付けられ得る。たとえば、リソースデマンドコリレータ５９５は、同一のユーザが２つ以上のオーダーを提出したことに基づいて、当該オーダー同士の間の相関を決定し得る（たとえば、アプリケーションスイートを要求するユーザについては、当該ユーザはデータベースを同時にまたは後で要求するため、リソースデマンドコリレータ５９５はデータベースをアプリケーションスイートと相関付け得る）。オーダーは、リクエスタもしくはユーザ、リソース要求が取得された特定の時間帯、要求されたリソースのタイプ、および／またはその他のデータを含むアグリゲートデータ構造から取得可能な任意の数のデータコンポーネントに基づいて、少なくとも１つの他のオーダーと相関付けられ得る。ステップ８３０において、相関付けられたオーダーに基づいて、複数のユーザにわたって一般に要求されるリソースのセットが特定され得る。たとえば、デマンドモニタ５７５は、一次リソース（たとえばアプリケーションスイート）が要求されると、従属リソース（たとえばデータベース）も一次リソースと通信するようにプロビジョニングおよび構成されるように、相関付けられたオーダーに基づいて、１セットのリソースとしてのリソース同士の間の公知の従属を特定して格納し得る。いくつかの実施形態では、当該１セットのリソースは、ステップ８２０からのリソースに対して計算されたリアルタイムデマンドに基づいて動的に変化し得る。たとえば、リソースデマンドコリレータ５９５は、一次および従属リソースに加えて定期的に要求される追加のリソースを（たとえば一次リソース、従属リソース、および追加のリソースを含むオーダーのパーセンテージに基づいて）特定し得る。これらの実施形態では、特定されて格納されたリソースのセットは、これらの追加のリソースを含むように自動的に更新され得る。

図１０は、本発明の実施形態に係るデマンドポリシーベースのリソース割当てのために実行される処理を表わす簡略化したフローチャート８５０を表わす。ステップ８５５において、リソースプール内の各リソースの利用が追跡され得る。たとえば、特定の期間（ローリング平均、履歴期間など）において、リソースプール５３０、リアルタイムデマンドカルキュレータ５９０、およびアグリゲート履歴データ構造５８５を用いて、各リソースの使用が決定され得る。特定のリソースの利用期間／トレンドを追跡することによって、リソースマネージャ５０５は、リソースがこれまでに使用されたことがあるか否か、リソースが最近使用されたか否か、リソースの使用の頻度、および／またはリソースが現在使用されているか否かを判断することができる。

ステップ８６０において、（ｉ）（図９のステップ８２０で計算された）計算されたリソースに対するデマンド、（ii）（図９のステップ８３０で特定された）特定されたリソースおよびリソースのセット、（iii）（図９のステップ８３０で任意に特定された）リソースのセットに対する追加のリソースの特定、および（iv）（図１０のステップ８５５で特定された）追跡されたリソースの利用、の少なくとも１つに基づいて、１つ以上のデマンドポリシーが生成または更新され得る。いくつかの実施形態では、リソースがリソースマネージャ５０５によってプリエンプティブに作成されてリソースプールに追加され得るように、デマンドモニタ５７５によって計算されたリアルタイムデマンドを使用して、リソース割当てに対する１つ以上のデマンドポリシーを生成または更新することができる。たとえば、リソース要求の特定のパーセンテージが１つ以上の二次リソースを含む場合は、デマンドポリシーは、二次リソースの１つ以上の追加のインスタンスを自動的に予め作成するように更新され得、または、１つ以上のリソースを要求する新たなアプリケーションスイートが導入されている場合は、デマンドポリシーは、１つ以上のリソースのより多くのインスタンスを自動的に予め作成するように更新され得る。

加えて、いくつかの実施形態では、デマンドモニタ５７５は、一次リソースが要求されると、従属リソース（たとえばデータベース）も一次リソースと通信するようにプロビジョニングおよび構成されるように、相関付けられたリソース要求に基づいて１つ以上のデマンドポリシーにおいて１セットのリソースとしてのリソース同士の間の公知の従属を特定して格納し得る。たとえば、アプリケーションスイートは、データベースおよびエンタープライズマネージャをさらに必要し得る。これら公知の従属は、アプリケーションスイートが要求されると、データベースおよびエンタープライズマネージャもアプリケーションスイートと通信するようにプロビジョニングおよび構成されるように、デマンドポリシーに格納され得る。いくつかの実施形態では、特定された１セットのリソースは、リソースに対して計算されたデマンドに基づいて動的に変化し得る。たとえば、リソースデマンドコリレータ５９５は、従属リソースに加えて定期的に要求される追加のリソースを特定し得る。これらの実施形態では、デマンドポリシーはこれらの追加のリソースを含むように自動的に更新され得る。ともに使用されるリソースのグループに対するデマンドを監視することによって、デマンドポリシーを使用してリソースのセットをプリエンプティブに作成し、リソースを互いに通信するように構成し、リソースを個々のリソースの代わりにリソースプールに追加することによって、ユーザが要求したときにリソースをセットアップするのに必要な時間を減少させることができる。

加えて、いくつかの実施形態では、デマンドモニタ５７５は、一度も使用されていないリソース、最近使用されたリソース、各リソースの使用の頻度、および／またはリソースが現在使用されているか否か、を特定し、１つ以上のデマンドポリシーを生成または更新して、そのような利用情報に基づいてリソースの割当てを制御することができる。たとえば、リソースが作成されているが、ユーザが当該リソースに一度もアクセスしたことがない場合は、リソースマネージャ９０５は当該リソースは使用されていないと判断することができ、当該リソースは、当該リソースを最初にクリーンにすることなく、１つ以上のデマンドポリシーに基づいて他のユーザに再割当てされ得る。一方、リソースが作成されているが、ユーザが当該リソースに予め定められた期間（たとえば２ヶ月）アクセスしていない場合は、リソースマネージャ９０５は当該リソースはもはや使用されていないと判断することができ、当該リソースは、当該リソースをクリーンにした後に、１つ以上のデマンドポリシーに基づいて他のユーザに再割当てされ得る。

ステップ８６５において、１つ以上のリソースが自動的に予め作成され（プリエンプティブに作成され）、リソースプールに追加され、リソースプールから除去され、および／または生成もしくは更新された１つ以上のデマンドポリシーに基づいてクリーンにされ得る。たとえば、リソースマネージャ５０５は、１つ以上のリソースを自動的に予め作成し、生成または更新された１つ以上のデマンドポリシーに基づいて、予め作成された１つ以上のリソースを１人以上のユーザにサービスするためにリソースプールに追加し得る。いくつかの実施形態では、リソースマネージャ５０５は、生成または更新された１つ以上のデマンドポリシーに基づいて、リソースプールから１つ以上のリソースを自動的に除去し得る。他の実施形態では、リソースマネージャ５０５は、生成または更新された１つ以上のデマンドポリシーに基づいて、リソースプール内の１つ以上のリソースを自動的にクリーンにし得る。

ステップ８７０において、１つ以上のデマンドポリシーと関連付けられている１つ以上の要求されたリソースが１人以上のユーザに割当てられ得る。たとえば、リソースマネージャ５０５は、１つ以上のデマンドポリシーに基づいて、１人以上のユーザにサービスするためにリソースプールから１つ以上の要求されたリソースを割当て、１つ以上の要求されたリソースが割当てられたという確認メッセージを送信し得る。いくつかの実施形態では、リソースプールはＩａａＳプロバイダによって管理されるハイパーバイザプールであり得る。いくつかの実施形態では、リソースプールは、複数のリモートデータセンターにわたって分散している複数のリソースプールを含み得る。理解されるべきであるように、１つ以上の要求されたリソースの割当ては、図１〜図８に関して上記に詳述したように、トポロジ定義、配置ポリシー、およびコントリビューションポリシーに基づいてさらに定義され得る。ステップ８７５において、ユーザアカウント履歴およびリソースプールは、１つ以上のデマンドポリシーの利用から実現される変更を示すように更新され得る。たとえば、データセンターインデックス、リソースインデックス、および／またはユーザアカウント履歴５６０は、予め作成された、および／または１人以上のユーザに割当てられた１つ以上の要求されたリソースを示すように更新され得る。

いくつかの実施形態では、配置ポリシーベースの、コントリビューションポリシーベースの、およびデマンドポリシーベースのリソース管理および割当てを提供するための上述のシステムおよびプロセスは単一のリソースマネージャにおいて実現され得る。図１１は、本発明の実施形態を組込むことができるネットワーク環境９００の簡略化した高レベルのダイアグラムを表わす。図１１に示されるように、リソースマネージャ９０５（たとえば、それぞれ図２、図４および図６に関して上述したリソース管理システム１０５またはリソースマネージャ３０５；５０５）はユーザ９１０および９１５からの要求を管理し得る。これらの要求はユーザ９１０からのリソースコントリビューション提出を含み得、ユーザは、当該ユーザが所有、保有またはそうでなければ制御する１つ以上のリソースを、リソースプールに追加されるようにリソースマネージャ９０５が利用可能であるようにする。当該要求は、リソースプールからの１つ以上のリソースに対するユーザ９１５からのリソース要求をさらに含み得る。ユーザ９１０およびユーザ９１５は同一のユーザ、異なるユーザ、またはこれらの任意の組み合わせを含み得る。要求は、ネットワーク９２０Ａおよび／または９２０Ｂ上でリソースマネージャ９０５において１人以上のユーザ（またはクライアント）デバイスから受信され得る。いくつかの実施形態では、ユーザ９１０は、上述のように、その後のまたは同時のリソース要求に適用され得る特定の機能の保証、ディスカウント、または他のインセンティブと交換にリソースをコントリビューションし得る。

ユーザ９１０および９１５は、通信ネットワーク９２０Ａおよび９２０Ｂを介してリソースマネージャ９０５に通信可能に結合されている。図１１に表わされる実施形態は例に過ぎず、本発明の請求項の実施形態を不当に制限するよう意図されるものではない。当業者は、多くの変形例、代替例、および変更例を認識するであろう。たとえば、図１１に示すよりも多いまたは少ないユーザデバイスが存在していてもよい。ユーザデバイスは、パーソナルコンピュータ、デスクトップ、ラップトップ、携帯電話、タブレット等のモバイルまたはハンドヘルドデバイス、および他の種類のデバイスを含むがこれらに限定されるものではないさまざまな異なる種類であり得る。通信ネットワーク９２０Ａおよび９２０Ｂは、ユーザデバイスとリソースマネージャ９０５との間の通信を容易にする。通信ネットワーク９２０Ａおよび９２０Ｂはさまざまな種類であり得、１つ以上の通信ネットワークを含み得る。通信ネットワーク９２０Ａおよび９２０Ｂの例としては、インターネット、広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、イーサネット（登録商標）ネットワーク、パブリックまたはプライベートネットワーク、有線ネットワーク、無線ネットワーク、およびそれらの組み合わせが挙げられるがこれらに限定されるものではない。ＩＥＥＥ８０２．ＸＸプロトコルスイート、ＴＣＰ／ＩＰ、ＳＡＮ、Apple Talk、Bluetooth（登録商標）、および他のプロトコルなどの有線および無線プロトコルの双方を含む異なる通信プロトコルを用いて当該通信を容易にしてもよい。一般に、通信ネットワーク９２０Ａおよび９２０Ｂは、クライアントとリソースマネージャ９０５との間の通信を容易にする任意の通信ネットワークまたはインフラストラクチャを含み得る。

ユーザ９１０の各々は、１つ以上のコンピューティングリソース９２５−１から９２５−Ｍを所有、保有またはそうでなければ制御し得る。たとえば、ユーザは、当該ユーザが制御し得る別のクラウドインフラストラクチャプロバイダから特定の数のコンピューティングノードを購入済の場合がある。同様に、ユーザは、１つ以上の仮想マシンを実行し得るハイパーバイザプールを提供するように構成されるネットワーク接続されたハードウェアクラスタを所有している場合がある。上述のように、コンピューティングリソースは、ネットワーク、ネットワーク帯域幅、サーバ、ＰＯＤ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、サービス等を含み得る。

特定の実施形態では、ユーザは、当該ユーザのユーザデバイスによって実行されるプログラムまたはアプリケーションを用いてウェブページ要求を構成し得る。そのようなプログラムの例には、ウェブページ要求を生成し、当該要求に応答して受信したウェブページを出力するように用いられ得るウェブブラウザがある。たとえば、ユーザは、ウェブページに対応する統一資源位置指定子（ＵＲＬ）をブラウザに提供することによって、またはウェブページに対応するＵＲＬを呼出すアクションを取る（たとえばＵＲＬ上をクリックする）ことによって、ウェブページを要求し得る。これによってブラウザはウェブページ要求を生成し、次いで、この要求は特定のウェブページをホストするウェブサイトに通信される。次いで、ウェブページ要求に応答して受信されたウェブページは、ブラウザによってロードされてユーザに出力される。ブラウザの例として、さまざまなバージョンのWindows Internet Explorer（ＩＥ）、Apple Safari、Google Chrome、Mozilla Firefox、Operaなどが挙げられるが、これらに限定されるものではない。

上述のように、ユーザ９１０は、ユーザによってコントリビューションされているコンピューティングリソースを詳述するリソース提出をリソースマネージャ９０５に提出し得る。リソースマネージャ９０５は、リソース提出インターフェイス９３０を介して提出を受信し得る。ユーザ９１５は、ユーザが要求しているコンピューティングリソースを詳述するリソース要求をリソースマネージャ９０５に提出し得る。リソースマネージャ９０５は、リソース要求インターフェイス９５５を介して要求を受信し得る。リソースマネージャ９０５は、ポリシーマネージャ９３５、デマンドモニタ９４０、リソースプール９４５、およびユーザアカウント履歴９５０を含み得る。これらのモジュールを用いて、図４および図６に関して同様に説明したように、リソースマネージャ９０５は、図１〜図１０に関して上述したように、デマンドを予想してリソースおよびリソースのセットを予め作成し、リソースコントリビューションおよび要求を管理し、ユーザがリソース要求に対する配置ポリシーを規定することを可能にし得る。ユーザ９１５および９１０によって提供された、かつユーザ９１５および９１０に提供されたリソースおよびリソースのセットは、異なる地理的領域９６５Ａおよび９６５Ｂ内に位置し得る１つ以上のデータセンター９６０Ａ〜９６０Ｉ内に位置し得る。

図１〜図１１に表わされる実施形態では、リソースマネージャ９０５は、ユーザ９１０および９１５からリソース提出およびリソース要求を受信する中央管理プラットフォームの役割を果たし得る。図１２は、本発明の教示を組込むことができる代替的な実施形態９７０を表わす。図１１における共通のコンポーネントは同一の参照番号を用いて参照される。図１２に表わされる実施形態に示されるように、リソース管理機能および要求管理機能は互いに分離され得る。要求マネージャ９７５は、リソース提出インターフェイス９３０およびリソース要求インターフェイス９５５を含み得る。要求マネージャ９７５はさらに、図１〜図１１に関して上述した実施形態と実質的に同様に要求を分析するデマンドモニタ９４０と、ユーザアカウント履歴９５０とを含み得る。要求マネージャ９７５は、リソースおよび／またはコントリビューション要求をリソースマネージャ９０５に通信し得る。リソースマネージャ９０５はポリシーマネージャ９３５およびリソースプール９４５を含み得る。リソースマネージャ９０５は、要求マネージャ９７５から受信したメッセージに従ってデータセンター９６０Ａ〜９６０Ｉと通信し得る。

図１３は、実施形態を実現するための分散システム１０００の簡略化したダイアグラムを表わす。示される実施形態では、分散システム１０００は、１つ以上のネットワーク１０１０上でウェブブラウザ、プロプライエタリクライアント（たとえばオラクルフォームズ（Oracle Forms））などのクライアントアプリケーションを実行および操作するように構成された１つ以上のクライアントコンピューティングデバイス１００２、１００４、１００６、および１００８を含む。サーバ１０１２は、ネットワーク１０１０を介して遠隔のクライアントコンピューティングデバイス１００２、１００４、１００６、および１００８と通信可能に連結され得る。

さまざまな実施形態において、サーバ１０１２は、配置、コントリビューション、および／またはデマンドポリシーベースのリソース割当てのためのサービスおよびアプリケーションなどの１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。特定の実施形態では、サーバ１０１２はまた、非仮想および仮想環境を含み得るその他のサービスまたはソフトウェアアプリケーションを提供し得る。いくつかの実施形態では、これらのサービスは、クライアントコンピューティングデバイス１００２、１００４、１００６、および／または１００８のユーザに対して、ウェブベースのもしくはクラウドサービスとして、またはＳａａＳモデルの下で供給され得る。クライアントコンピューティングデバイス１００２、１００４、１００６、および／または１００８を操作するユーザは次に、１つ以上のクライアントアプリケーションを利用してサーバ１０１２と対話することにより、これらのコンポーネントが提供するサービスを利用し得る。

図１３に表わされる構成では、システム１０００のソフトウェアコンポーネント１０１８、１０２０および１０２２は、サーバ１０１２上に実装されるものとして示されている。他の実施形態では、システム１０００の上記コンポーネントおよび／またはこれらのコンポーネントが提供するサービスのうちの１つ以上が、クライアントコンピューティングデバイス１００２、１００４、１００６、および／または１００８のうちの１つ以上によって実装されてもよい。そうすると、クライアントコンピューティングデバイスを操作するユーザは、クライアントアプリケーションのうちの１つ以上を用いて、これらのコンポーネントが提供するサービスを利用することができる。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実装されてもよい。分散システム１０００とは異なり得る多種多様なシステム構成が可能であるということが認識されるべきである。図１３に示される実施形態はしたがって、ある実施形態のシステムを実現するための分散システムの一例であって、限定的であるよう意図されるものではない。

クライアントコンピューティングデバイス１００２、１００４、１００６、および／または１００８は、さまざまな種類のコンピューティングシステムを含み得る。たとえば、クライアントコンピューティングデバイスは、Microsoft Windows Mobile（登録商標）等のソフトウェア、および／またはiOS、Windows Phone、Android（登録商標）、BlackBerry（登録商標） 10、Palm ＯＳ等のさまざまなモバイルオペレーティングシステムを実行する、ポータブルハンドヘルドデバイス（たとえばiPhone（登録商標）、携帯電話、iPad（登録商標）、計算タブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）を含み得る。これらの装置は、さまざまなインターネット関連アプリケーション、電子メール、ショートメッセージサービス（ＳＭＳ）アプリケーション等のさまざまなアプリケーションをサポートし得るものであり、かつその他のさまざまな通信プロトコルを使用し得る。また、クライアントコンピューティングデバイスは、例として、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）および／またはLinux（登録商標）オペレーティングシステムを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む、汎用パーソナルコンピュータを含み得る。クライアントコンピューティングデバイスは、たとえばGoogle Chrome OS等の、さまざまなGNU／Linuxオペレーティングシステムを含むがこれらに限定されるものではないさまざまな市販のUNIX（登録商標）またはUNIXのようなオペレーティングシステムのうちのいずれかを実行するワークステーションコンピュータであってもよい。また、クライアントコンピューティングデバイスは、ネットワーク１０１０上で通信可能な、シンクライアントコンピュータ、インターネット接続可能なゲームシステム（たとえばKinect（登録商標）ジェスチャー入力装置を備えたもしくは備えていないMicrosoft Xboxゲーム機）、および／またはパーソナルメッセージングデバイス等の電子機器を含み得る。

図１３の分散システム１０００は４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされ得る。センサ等を有する装置といったその他の装置がサーバ１０１２と対話してもよい。

分散システム１０００内のネットワーク１０１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、Apple Talk等を含むがこれらに限定されるものではない、利用可能なさまざまなプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者にはよく知られているいずれかの種類のネットワークであればよい。ほんの一例として、ネットワーク１０１０は、ローカルエリアネットワーク（ＬＡＮ）、イーサネットに基づくネットワーク、トークンリング、広域ネットワーク、インターネット、仮想ネットワーク、仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば、米国電気電子技術者協会（ＩＥＥＥ）１００２．１１プロトコルスイートのうちのいずれか、Bluetooth（登録商標）、および／またはその他いずれかの無線プロトコルの下で機能するネットワーク）、および／またはこれらの組み合わせ、および／またはその他のネットワークであってもよい。

サーバ１０１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例として、ＰＣ（パーソナルコンピュータ）サーバ、UNIX（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント式サーバ等を含む）、サーバファーム、サーバクラスタ、またはその他いずれかの適切な構成および／または組み合わせで構成されていてもよい。サーバ１０１２は、仮想オペレーティングシステムまたは仮想化を伴うその他の計算アーキテクチャを実行する１つ以上の仮想マシンを含み得る。論理記憶装置の１つ以上のフレキシブルプールを仮想化することによって、サーバのための仮想記憶装置を維持することができる。仮想ネットワークは、サーバ１０１２がソフトウェア定義ネットワーキングを用いて制御することができる。さまざまな実施形態において、サーバ１０１２は、これまでの開示において説明した１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されていてもよい。たとえば、サーバ１０１２は、本開示のある実施形態に従う上記処理を実行するためのサーバに対応していてもよい。

サーバ１０１２は、上記のうちのいずれかを含むオペレーティングシステムおよび市販のいずれかのサーバオペレーティングシステムを実行し得る。サーバ１０１２はまた、ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバ等を含む、さまざまなその他のサーバアプリケーションおよび／またはミッドティアアプリケーションのうちのいずれかを実行し得る。代表的なデータベースサーバは、オラクル、マイクロソフト、サイベース、ＩＢＭ（International Business Machines）等から市販されているものを含むが、これらに限定されるものではない。

いくつかの実装例において、サーバ１０１２は、クライアントコンピューティングデバイス１００２、１００４、１００６、および１００８のユーザから受信したデータフィードおよび／またはイベントアップデートを分析し集約するための１つ以上のアプリケーションを含み得る。一例として、データフィードおよび／またはイベントアップデートは、センサデータアプリケーション、株式相場表示機、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通量モニタリング等に関連するリアルタイムイベントを含み得る、１つ以上の第三者情報源および連続データストリームから受信した、Twitter（登録商標）フィード、Facebook（登録商標）アップデートまたはリアルタイムアップデートを含み得るが、これらに限定されるものではない。また、サーバ１０１２は、クライアントコンピューティングデバイス１００２、１００４、１００６、および１００８の１つ以上の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含み得る。

分散システム１０００はまた、１つ以上のデータベース１０１４および１０１６を含み得る。これらのデータベースは、本発明の実施形態によって使用されるユーザ要求および／またはコントリビューション履歴、デマンドポリシーベースのリソース相関情報、ポリシー定義、およびその他の情報等の情報を格納するためのメカニズムを提供し得る。データベース１０１４および１０１６はさまざまな場所に存在し得る。例として、データベース１０１４および１０１６のうちの１つ以上が、サーバ１０１２にローカルな（および／または存在する）非一時的な記憶媒体上にあってもよい。これに代えて、データベース１０１４および１０１６は、サーバ１０１２から遠隔の場所にあってネットワークベースのまたは専用接続を介してサーバ１０１２と通信してもよい。一組の実施形態において、データベース１０１４および１０１６は、ストレージエリアネットワーク（ＳＡＮ）にあってもよい。同様に、サーバ１０１２から発生する機能を実行するために必要な任意のファイルは、適宜サーバ１０１２にローカルに格納されていてもよくおよび／または遠隔場所に格納されてもよい。一組の実施形態において、データベース１０１４および１０１６は、ＳＱＬフォーマットのコマンドに応じてデータを格納、更新、および取出すように適合された、オラクルが提供するデータベース等のリレーショナルデータベースを含み得る。

いくつかの実施形態では、クラウド環境は、配置、コントリビューション、および／またはデマンドポリシーベースのリソース割当てのための１つ以上のサービスを提供し得る。図１４は、本開示の実施形態に従う、サービスがクラウドサービスとして供給され得るシステム環境１１００の１つ以上のコンポーネントの簡略化したブロックダイアグラムである。図１４に示される実施形態では、システム環境１１００は、配置、コントリビューション、および／またはデマンドポリシーベースのリソース割当てのためのサービスを含むクラウドサービスを提供するクラウドインフラストラクチャシステム１１０２と対話するためにユーザによって使用され得る１つ以上のクライアントコンピューティングデバイス１１０４、１１０６、および１１０８を含む。クラウドインフラストラクチャシステム１１０２は、サーバ１０１２について上述したものを含み得る１つ以上のコンピュータおよび／またはサーバを含み得る。

図１４に表わされるクラウドインフラストラクチャシステム１１０２は、表わされるもの以外の他のコンポーネントを有していてもよいということが認識されるべきである。さらに、図１４に示される実施形態は、本発明の実施形態を組込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施形態では、クラウドインフラストラクチャシステム１１０２は、図に示されるものよりも多いもしくは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。

クライアントコンピューティングデバイス１１０４、１１０６、および１１０８は、クライアントコンピューティングデバイス１００２、１００４、１００６、および１００８についての上述のものと同様のデバイスであり得る。クライアントコンピューティングデバイス１１０４、１１０６、および１１０８は、ウェブブラウザ、プロプライエタリクライアント（たとえばオラクルフォームズ）等のクライアントアプリケーション、または何らかの他のアプリケーションを操作するように構成され得、クライアントコンピューティングデバイスのユーザは当該アプリケーションを使用してクラウドインフラストラクチャシステム１１０２と対話することにより、クラウドインフラストラクチャシステム１１０２が提供するサービスを使用し得る。例示的なシステム環境１１００が３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされ得る。センサ等を有する装置といったその他の装置がクラウドインフラストラクチャシステム１１０２と対話してもよい。

ネットワーク１１１０は、クライアントコンピューティングデバイス１１０４、１１０６、および１１０８とクラウドインフラストラクチャシステム１１０２との間でのデータの通信および交換を容易にし得る。各ネットワークは、ネットワーク１０１０について上述したものを含むさまざまな市販のプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者にはよく知られているいずれかの種類のネットワークであればよい。

特定の実施形態では、クラウドインフラストラクチャシステム１１０２が提供するサービスは、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用できるようにされる多数のサービスを含み得る。配置、コントリビューション、および／またはデマンドポリシーベースのリソース割当てに関するサービスに加えて、オンラインデータストアおよびバックアップソリューション、ウェブベースの電子メールサービス、ホスト型オフィススイートおよび文書コラボレーションサービス、データベース処理、管理された技術サポートサービス等を含むがこれらに限定されるものではないさまざまな他のサービスも供給され得る。クラウドインフラストラクチャシステムが提供するサービスは、そのユーザのニーズを満たすよう動的にスケーリング可能である。

特定の実施形態では、クラウドインフラストラクチャシステム１１０２が提供するサービスの具体的なインスタンス化は、本明細書では「サービスインスタンス」と称され得る。一般に、クラウドサービスプロバイダのシステムからインターネット等の通信ネットワークを介してユーザが利用できるようにされるサービスはいずれも、「クラウドサービス」と称される。典型的に、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、ユーザ自身のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストし得、ユーザは、インターネットなどの通信ネットワークを介してオンデマンドで当該アプリケーションをオーダーし、使用し得る。

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダによってユーザに提供されるかまたはそうでなければ当該技術分野において公知のストレージ、ホスト型データベース、ホスト型ウェブサーバ、ソフトウェアアプリケーション、または他のサービスへの保護されたコンピュータネットワークアクセスを含み得る。たとえば、サービスは、インターネットを通した、クラウド上の遠隔記憶域に対する、パスワードで保護されたアクセスを含み得る。別の例として、サービスは、ネットワーク接続された開発者の私的使用のためのウェブサービスベースのホスト型リレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされる電子メールソフトウェアアプリケーションへのアクセスを含み得る。

特定の実施形態では、クラウドインフラストラクチャシステム１１０２は、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルな、信頼性のある、高可用性の、安全な態様でユーザに与えられる一連のアプリケーション、ミドルウェアおよびデータベースサービス提供品を含み得る。このようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるオラクルパブリッククラウド（Oracle Public Cloud）である。

クラウドインフラストラクチャシステム１１０２はさらに、「ビッグデータ（big data）」関連の計算および分析サービスを提供し得る。「ビッグデータ」という用語は一般に、大量のデータを視覚化し、トレンドを検出し、および／またはそうでなければデータと対話するために、分析者および研究者によって格納および処理され得る極めて大きいデータ集合を指すために用いられる。このビッグデータおよび関連のアプリケーションは、多くのレベルで、かつさまざまなスケールでインフラストラクチャシステムによってホストおよび／または処理されてもよい。平行にリンクされた何十、何百または何千ものプロセッサがこのようなデータに対して作用可能であり、これにより、このようなデータを表示し得るか、または、データに対する外力をシミュレートし得るかもしくはそれが表しているものをシミュレートし得る。これらのデータ集合は、データベースにおいて編成されたデータ、もしくは構造化モデルに従ったデータ、および／または、非構造化データ（たとえば電子メール、画像、データブロブ（バイナリ大型オブジェクト）、ウェブページ、複雑なイベント処理）などの、構造化データを含み得る。目標物に対してより多くの（またはより少数の）コンピューティングリソースを比較的迅速に集中させるために実施形態の機能を強化することにより、ビジネス、政府関係機関、研究組織、私人、同じ目的をもった個々人もしくは組織のグループ、または他のエンティティから、要求に基づいて大量のデータ集合上でタスクを実行するために、クラウドインフラストラクチャシステムがより良好に利用可能となり得る。

さまざまな実施形態において、クラウドインフラストラクチャシステム１１０２は、クラウドインフラストラクチャシステム１１０２によって供給されるサービスへのユーザのサブスクリプションを自動的にプロビジョニング、管理および追跡するように適合され得る。クラウドインフラストラクチャシステム１１０２は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。たとえば、サービスはパブリッククラウドモデルの下で提供されてもよく、パブリッククラウドモデルでは、クラウドインフラストラクチャシステム１１０２が（たとえばオラクル社が所有する）クラウドサービスを販売する組織によって所有され、サービスは一般的な公営企業またはさまざまな産業企業が利用できるようにされる。別の例として、サービスはプライベートクラウドモデルの下で提供されてもよく、プライベートクラウドモデルでは、クラウドインフラストラクチャシステム１１０２が単一の組織のために単独で運営され、当該組織内の１つ以上のエンティティにサービスを提供することができる。また、クラウドサービスはコミュニティクラウドモデルの下で提供されてもよく、コミュニティクラウドモデルでは、クラウドインフラストラクチャシステム１１０２およびクラウドインフラストラクチャシステム１１０２によって提供されるサービスが関連のコミュニティの中のいくつかの組織によって共有される。また、クラウドサービスは、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で提供されてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム１１０２によって提供されるサービスは、ＳａａＳカテゴリ、ＰａａＳカテゴリ、ＩａａＳカテゴリ、またはその他の、ハイブリッドサービスを含むサービスのカテゴリの下で提供される１つ以上のサービスを含み得る。ユーザは、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスをオーダーし得る。次いで、クラウドインフラストラクチャシステム１１０２は、ユーザのサブスクリプションオーダーにおけるサービスを提供するために処理を実行する。

いくつかの実施形態では、クラウドインフラストラクチャシステム１１０２によって提供されるサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含み得るが、これらに限定されるものではない。いくつかの例では、アプリケーションサービスは、ＳａａＳプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリに分類されるクラウドサービスを提供するように構成され得る。たとえば、ＳａａＳプラットフォームは、統合された開発およびデプロイメントプラットフォーム上で一連のオンデマンドのアプリケーションを構築および供給する機能を提供し得る。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、ユーザは、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用することができる。ユーザは、ユーザが別個のライセンスおよびサポートを購入する必要なくアプリケーションサービスを取得することができる。さまざまな異なるＳａａＳサービスが提供されてもよい。例としては、大規模組織に販売実績管理、企業統合およびビジネスの柔軟性のためのソリューションを提供するサービスが挙げられるが、これらに限定されるものではない。

いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介してクラウドインフラストラクチャシステム１１０２によって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに分類されるクラウドサービスを提供するように構成され得る。プラットフォームサービスの例としては、共有される共通のアーキテクチャ上で既存のアプリケーションを（オラクルなどの）組織が集約することを可能にするサービス、および、プラットフォームによって提供される共有のサービスを活用する新たなアプリケーションを構築する能力が挙げられ得るが、これらに限定されるものではない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御し得る。ユーザは、ユーザが別々のライセンスおよびサポートを購入する必要なく、クラウドインフラストラクチャシステム１１０２によって提供されるＰａａＳサービスを取得することができる。プラットフォームサービスの例としては、オラクルＪａｖａクラウドサービス（ＪＣＳ）、オラクルデータベースクラウドサービス（ＤＢＣＳ）などが挙げられるが、これらに限定されるものではない。

ＰａａＳプラットフォームによって提供されるサービスを利用することによって、ユーザは、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを利用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえばオラクルフュージョンミドルウェアサービス）、およびＪａｖａクラウドサービスを含み得る。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、データベースクラウドの形態でデータベース・アズ・ア・サービスをユーザに供給することを可能にする共有のサービスデプロイメントモデルをサポートし得る。ミドルウェアクラウドサービスは、さまざまなビジネスアプリケーションを開発およびデプロイするためにユーザにプラットフォームを提供し得、Ｊａｖａクラウドサービスは、クラウドインフラストラクチャシステムにおいてＪａｖａアプリケーションをデプロイするためにユーザにプラットフォームを提供し得る。

さまざまな異なるインフラストラクチャサービスは、クラウドインフラストラクチャシステムにおけるＩａａＳプラットフォームによって提供されてもよい。インフラストラクチャサービスは、ストレージ、ネットワークなどの基本的な計算リソース、ならびに、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用するユーザのための他の基礎的な計算リソースの管理および制御を容易にする。

また、特定の実施形態では、クラウドインフラストラクチャシステム１１０２は、クラウドインフラストラクチャシステムのユーザにさまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース１１３０を含み得る。一実施形態では、インフラストラクチャリソース１１３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するための、サーバ、ストレージおよびネットワーキングリソース、ならびに他のリソースなどの、ハードウェアの事前に一体化された最適な組み合わせを含み得る。

いくつかの実施形態では、クラウドインフラストラクチャシステム１１０２におけるリソースは、複数のユーザによって共有され、デマンドごとに動的に再割当てされ得る。加えて、リソースは、異なる時間帯にユーザに割当てられ得る。たとえば、クラウドインフラストラクチャシステム１１０２は、第１の時間帯におけるユーザの第１の組が規定の時間にわたってクラウドインフラストラクチャシステムのリソースを利用することを可能にし、次いで、異なる時間帯に位置するユーザの別の組への同一のリソースの再割当てを可能にし、それによってリソースの利用を最大化することができる。

特定の実施形態では、クラウドインフラストラクチャシステム１１０２によるサービスの提供を可能にするために、クラウドインフラストラクチャシステム１１０２の異なるコンポーネントまたはモジュールによって共有されるいくつかの内部共有サービス１１３２が提供され得る。これらの内部共有サービスは、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性・バックアップおよび回復サービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されるものではない。

特定の実施形態では、クラウドインフラストラクチャシステム１１０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえばＳａａＳ、ＰａａＳおよびＩａａＳサービス）の包括的管理を提供し得る。一実施形態では、クラウド管理機能は、クラウドインフラストラクチャシステム１１０２によって受信したユーザのサブスクリプションをプロビジョニング、管理および追跡するための機能などを含み得る。

一実施形態では、図１４に表わされるように、クラウド管理機能は、オーダー管理モジュール１１２０、オーダーオーケストレーションモジュール１１２２、オーダープロビジョニングモジュール１１２４、オーダー管理および監視モジュール１１２６、ならびにアイデンティティ管理モジュール１１２８などの１つ以上のモジュールによって提供され得る。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他の適切な構成および／もしくは組み合わせであり得る１つ以上のコンピュータならびに／またはサーバを含み得るか、またはそれらを用いて提供され得る。

例示的なオペレーションでは、１１３４において、ユーザは、クラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスを要求し、クラウドインフラストラクチャシステム１１０２によって供給される１つ以上のサービスのサブスクリプションについてオーダーを行うことによって、クライアントコンピューティングデバイス１１０４、１１０６または１１０８などのクライアントデバイスを用いてクラウドインフラストラクチャシステム１１０２と対話し得る。特定の実施形態では、ユーザは、クラウドユーザインターフェース（User Interface：ＵＩ）、すなわちクラウドＵＩ１１１２、クラウドＵＩ１１１４および／またはクラウドＵＩ１１１６にアクセスして、これらのＵＩを介してサブスクリプションオーダーを行い得る。ユーザがオーダーを行ったことに応答してクラウドインフラストラクチャシステム１１０２によって受信されたオーダー情報は、ユーザおよびユーザがサブスクライブする予定のクラウドインフラストラクチャシステム１１０２によって供給される１つ以上のサービスを特定する情報を含み得る。

１１３６において、ユーザから受信したオーダー情報は、オーダーデータベース１１１８に格納され得る。これが新たなオーダーである場合、当該オーダーについての新たなレコードが作成され得る。一実施形態では、オーダーデータベース１１１８は、クラウドインフラストラクチャシステム１１１８によって動作され、かつ、他のシステム要素と連携して動作されるいくつかのデータベースのうちの１つであってもよい。

１１３８において、オーダー情報は、オーダー管理モジュール１１２０に転送され得、オーダー管理モジュール１１２０は、オーダーの確認、および確認時のオーダーの予約などの、オーダーに関連するビリングおよびアカウンティング機能を実行するように構成され得る。

１１４０において、オーダーについての情報は、オーダーオーケストレーションモジュール１１２２に通信され得、オーダーオーケストレーションモジュール１１２２は、ユーザによって行われたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレートするように構成される。いくつかの例では、オーダーオーケストレーションモジュール１１２２は、プロビジョニングのためにオーダープロビジョニングモジュール１１２４のサービスを使用し得る。特定の実施形態では、オーダーオーケストレーションモジュール１１２２は、各オーダーと関連付けられたビジネスプロセスの管理を可能にし、ビジネスロジックを適用して、オーダーがプロビジョニングに進むべきか否かを判断する。

図１４に表わされる実施形態に示されるように、１１４２において、新たなサブスクリプションのオーダーを受信すると、オーダーオーケストレーションモジュール１１２２は、リソースを割当てて、当該サブスクリプションオーダーを実現するために必要なリソースを構成するために、オーダープロビジョニングモジュール１１２４に要求を送信する。オーダープロビジョニングモジュール１１２４は、ユーザによってオーダーされたサービスのためのリソースの割当てを可能にする。オーダープロビジョニングモジュール１１２４は、クラウドインフラストラクチャシステム１１００によって提供されるクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理的実装層との間の抽象化のレベルを提供する。したがって、オーダーオーケストレーションモジュール１１２２は、サービスおよびリソースがオンザフライで実際にプロビジョニングされるか否か、または予めプロビジョニングされて要求時に単に配分／割当てられるか否かなどの実装詳細から切離され得る。

１１４４において、サービスおよびリソースがプロビジョニングされると、要求されたサービスが利用可能な状態となったことを示す通知が、サブスクライブを行うユーザに送信され得る。いくつかの例では、ユーザが要求されたサービスを使用し始めることを可能にする情報（たとえばリンク）がユーザに送信され得る。

１１４６において、ユーザのサブスクリプションオーダーがオーダー管理および監視モジュール１１２６によって管理および追跡され得る。いくつかの例では、オーダー管理および監視モジュール１１２６は、サブスクライブされたサービスのユーザ使用に関する使用統計を収集するように構成され得る。たとえば、統計は、使用されるストレージの量、転送されるデータの量、ユーザの数、ならびにシステムアップ時間およびシステムダウン時間の量などついて収集され得る。

特定の実施形態では、クラウドインフラストラクチャシステム１１００は、クラウドインフラストラクチャシステム１１００においてアクセス管理および認可サービスなどのアイデンティティサービスを提供するように構成されるアイデンティティ管理モジュール１１２８を含み得る。いくつかの実施形態では、アイデンティティ管理モジュール１１２８は、クラウドインフラストラクチャシステム１１０２によって提供されるサービスを利用したいユーザについての情報を制御し得る。このような情報は、このようなユーザのアイデンティティを認証する情報、および、さまざまなシステムリソース（たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらのユーザがどのアクションを実行することが認可されるかを記述する情報を含み得る。また、アイデンティティ管理モジュール１１２８は、各ユーザについての記述的情報および当該記述的情報がどのようにして誰によってアクセスおよび修正され得るかについての記述的情報の管理を含み得る。

図１５は、本発明の実施形態を実現するために用いられ得る例示的なコンピュータシステム１２００を示す。いくつかの実施形態では、コンピュータシステム１２００を用いて上記のさまざまなサーバおよびコンピュータシステムのうちのいずれかを実現してもよい。図１５に示されるように、コンピュータシステム１２００は、バスサブシステム１２０２を介していくつかの周辺サブシステムと通信する処理ユニット１２０４を含むさまざまなサブシステムを含む。これらの周辺サブシステムは、処理加速ユニット１２０６、Ｉ／Ｏサブシステム１２０８、記憶サブシステム１２１８、および通信サブシステム１２２４を含み得る。記憶サブシステム１２１８は、有形のコンピュータ読取可能記憶媒体１２２２およびシステムメモリ１２１０を含み得る。

バスサブシステム１２０２は、コンピュータシステム１２００のさまざまなコンポーネントおよびサブシステムを目的に応じて互いに通信させるためのメカニズムを提供する。バスサブシステム１２０２は単一のバスとして概略的に示されているが、バスサブシステムの代替的な実施形態は複数のバスを利用し得る。バスサブシステム１２０２は、さまざまなバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかの種類のバス構造のうちのいずれかであればよい。たとえば、このようなアーキテクチャは、ＩＥＥＥ Ｐ１３８６．１規格に従って製造されたメザニン（Mezzanine）バス等として実現できる、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、エンハンストＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクス標準協会（ＶＥＳＡ）ローカルバス、および周辺コンポーネントインターコネクト（ＰＣＩ）バスなどを含み得る。

処理サブシステム１２０４は、コンピュータシステム１２００のオペレーションを制御し、かつ、１つ以上の処理ユニット１２３２、１２３４等を含み得る。処理ユニットは、シングルコアもしくはマルチコアプロセッサ、プロセッサの１つ以上のコア、またはこれらの組み合わせを含む、１つ以上のプロセッサを含み得る。いくつかの実施形態では、処理サブシステム１２０４は、グラフィックプロセッサ、デジタル信号プロセッサ（ＤＳＰ）等といった１つ以上の専用コプロセッサを含み得る。いくつかの実施形態では、処理サブシステム１２０４の処理ユニットのうちのいくつかまたはすべてを、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）等のカスタマイズされた回路を用いて実現してもよい。

いくつかの実施形態では、処理サブシステム１２０４内の処理ユニットは、システムメモリ１２１０内にまたはコンピュータ読取可能記憶媒体１２２２上に格納されている命令を実行することができる。さまざまな実施形態において、処理ユニットは、さまざまなプログラムまたはコード命令を実行することができ、かつ、同時に実行される複数のプログラムまたはプロセスを維持することができる。任意の所与の時間に、実行すべきプログラムコードのうちのいくつかまたはすべてが、いくつかの例では１つ以上の記憶装置を含むシステムメモリ１２１０内におよび／またはコンピュータ読取可能記憶媒体８１０上にあってもよい。適切なプログラミングを通して、処理サブシステム１２０４は、配置、コントリビューション、および／またはデマンドポリシーベースのリソース割当てのために上記のさまざまな機能を提供することができる。

特定の実施形態では、コンピュータシステム１２００が実行する処理全体を加速することを目的として、カスタマイズされた処理を実行するためまたは処理サブシステム１２０４が実行する処理のうちの一部をオフロードするために、処理加速ユニット１２０６を設けてもよい。

Ｉ／Ｏサブシステム１２０８は、情報をコンピュータシステム１２００に入力するためおよび／または情報をコンピュータシステム１２００からもしくはコンピュータシステム１２００を介して出力するための装置およびメカニズムを含み得る。一般に、「入力装置」という用語の使用は、情報をコンピュータシステム１２００に入力するための、可能なすべての種類の装置およびメカニズムを含むことを意図している。ユーザインターフェイス入力装置は、たとえば、キーボード、マウスまたはトラックボール等のポインティングデバイス、ディスプレイに組込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを備えた音声入力装置、マイク、およびその他の種類の入力装置を含み得る。ユーザインターフェイス入力装置はまた、ユーザが入力装置を制御し入力装置と対話できるようにするMicrosoft Kinect（登録商標）モーションセンサ、Microsoft Xbox（登録商標）360ゲームコントローラ、ジェスチャーおよび発話コマンドを用いた入力を受けるためのインターフェイスを提供する装置等の、モーション検知および／またはジェスチャー認識装置を含み得る。ユーザインターフェイス入力装置はまた、ユーザから目の動き（たとえば写真撮影時および／またはメニュー選択時の「まばたき」）を検出して目のジェスチャーを入力装置（たとえばGoogle Glass（登録商標））への入力として変換するGoogle Glass（登録商標）まばたき検出器等のアイジェスチャー認識装置を含み得る。加えて、ユーザインターフェイス入力装置は、ユーザが音声コマンドを通して音声認識システム（たとえばSiri（登録商標）ナビゲータ）と対話できるようにする音声認識検知装置を含み得る。

ユーザインターフェイス入力装置のその他の例は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレイヤー、ウェブカメラ、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダー、および視線トラッキング装置等のオーディオ／ビジュアル装置を含むが、これらに限定されるものではない。加えて、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジトロン断層撮影、医療用超音波検査装置等の、医療用撮像入力装置を含み得る。ユーザインターフェイス入力装置はまた、たとえば、ＭＩＤＩキーボード、デジタル音楽機器等といった音声入力装置を含み得る。

ユーザインターフェイス出力装置は、ディスプレイサブシステム、インジケータライト、または音声出力装置といった非ビジュアルディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、たとえば液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを用いるフラットパネル装置、投射装置、タッチスクリーン等であってもよい。一般に、「出力装置」という用語の使用は、情報をコンピュータシステム１２００からユーザまたはその他のコンピュータに出力するための可能なすべての種類の装置およびメカニズムを含むことを意図している。たとえば、ユーザインターフェイス出力装置は、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、作図装置、音声出力装置、およびモデムといった、テキスト、グラフィックおよびオーディオ／ビデオ情報を視覚的に伝えるさまざまな表示装置を含み得るが、これらに限定されるものではない。

記憶サブシステム１２１８は、コンピュータシステム１２００が使用する情報を格納するためのリポジトリまたはデータストアを提供する。記憶サブシステム１２１８は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形の非一時的なコンピュータ読取可能記憶媒体を提供する。処理サブシステム１２０４によって実行されたときに上記機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、記憶サブシステム１２１８に格納されてもよい。ソフトウェアは、処理サブシステム１２０４の１つ以上の処理ユニットによって実行されてもよい。記憶サブシステム１２１８はまた、本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。

記憶サブシステム１２１８は、揮発性および不揮発性メモリデバイスを含む１つ以上の非一時的なメモリデバイスを含み得る。図１５に示されるように、記憶サブシステム１２１８は、システムメモリ１２１０およびコンピュータ読取可能記憶媒体１２２２を含む。システムメモリ１２１０は、プログラム実行中に命令とデータを格納するための揮発性メインランダムアクセスメモリ（ＲＡＭ）および固定命令が格納されている不揮発性読取専用メモリ（ＲＯＭ）またはフラッシュメモリを含む、いくつかのメモリを含み得る。いくつかの実装例において、たとえば起動中のコンピュータシステム１２００内の要素間の情報転送を補助する基本的なルーチンを含む基本的な入力／出力システム（ＢＩＯＳ）は、典型的にＲＯＭに格納され得る。ＲＡＭは典型的に、処理サブシステム１２０４が現在操作および実行しているデータおよび／またはプログラムモジュールを含む。いくつかの実装例において、システムメモリ１２１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）等の種類が異なる複数のメモリを含み得る。

限定ではなく一例として、図１５に表わされるように、システムメモリ１２１０は、クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）等を含み得るアプリケーションプログラム１２１２と、プログラムデータ１２１４と、オペレーティングシステム１２１６とを格納し得る。一例として、オペレーティングシステム１２１６は、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはLinux（登録商標）オペレーティングシステム、さまざまな市販のUNIX（登録商標）またはUNIXのようなオペレーティングシステム（さまざまなGNU／Linuxオペレーティングシステム、Google Chrome（登録商標）ＯＳ等を含むがこれらに限定されるものではない）および／または、iOS、Windows（登録商標）Phone、Android（登録商標）ＯＳ、BlackBerry（登録商標） 10 ＯＳ、およびPalm（登録商標）ＯＳオペレーティングシステム等のモバイルオペレーティングシステムを含み得る。

コンピュータ読取可能記憶媒体１２２２は、いくつかの実施形態の機能を提供するプログラミングおよびデータ構造を格納し得る。処理サブシステム１２０４のプロセッサによって実行されたときに上記機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、記憶サブシステム１２１８に格納されてもよい。一例として、コンピュータ読取可能記憶媒体１２２２は、ハードディスクドライブ、磁気ディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤ、Blu-Ray（登録商標）ディスク、またはその他の光媒体等の光ディスクドライブといった、不揮発性メモリを含み得る。コンピュータ読取可能記憶媒体１２２２は、Zip（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープ等を含み得るが、これらに限定されるものではない。コンピュータ読取可能記憶媒体１２２２はまた、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭ等といった不揮発性メモリに基づくソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ等といった揮発性メモリに基づくＳＳＤ、ＤＲＡＭとフラッシュメモリベースのＳＳＤを組み合わせたものを用いる、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、およびハイブリッドＳＳＤを含み得る。コンピュータ読取可能媒体１２２２は、コンピュータ読取可能命令、データ構造、プログラムモジュール、およびコンピュータシステム１２００のためのその他のデータの記憶域を提供し得る。

特定の実施形態では、記憶サブシステム１２００はまた、コンピュータ読取可能記憶媒体１２２２にさらに接続することができるコンピュータ読取可能記憶媒体リーダ１２２０を含み得る。システムメモリ１２１０とともに、また、任意でシステムメモリ１２１０と組み合わされて、コンピュータ読取可能記憶媒体１２２２は、コンピュータ読取可能情報を格納するための、遠隔、ローカル、固定、および／またはリムーバブル記憶装置プラス記憶媒体を、包括的に代表し得る。

特定の実施形態では、コンピュータシステム１２００は、１つ以上の仮想マシンを実行するためのサポートを提供し得る。コンピュータシステム１２００は、仮想マシンの構成および管理を容易にするためのハイパーバイザといったプログラムを実行し得る。各仮想マシンに、メモリ、計算（たとえばプロセッサ、コア）、Ｉ／Ｏ、およびネットワーキングリソースが割当てられていてもよい。各仮想マシンは、典型的に、コンピュータシステム１２００が実行するその他の仮想マシンによって実行されるオペレーティングシステムと同じでも異なっていてもよい、自身のオペレーティングシステムを実行する。したがって、いくつかの例では複数のオペレーティングシステムがコンピュータシステム１２００によって同時に実行されるであろう。一般的に、各仮想マシンはその他の仮想マシンから独立して実行される。

通信サブシステム１２２４は、その他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム１２２４は、コンピュータシステム１２００以外のシステムからデータを受信しコンピュータシステム１２００以外のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム１２２４によって、コンピュータシステム１２００は、情報をコンピューティングデバイスから受信しかつ情報をコンピューティングデバイスに送信するために１つ以上のコンピューティングデバイスへのインターネットを介した通信チャネルを確立することができるであろう。

通信サブシステム１２２４は、有線通信プロトコルおよび／または無線通信プロトコル双方をサポートし得る。たとえば、特定の実施形態では、通信サブシステム１２２４は、（たとえば携帯電話技術、３Ｇ、４ＧまたはＥＤＧＥ（グローバル進化型高速データレート）等の高度データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格、またはその他のモバイル通信技術、またはそれらの任意の組み合わせ）を用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）トランシーバコンポーネント、グローバルポジショニングシステム（ＧＰＳ）レシーバコンポーネント、および／またはその他のコンポーネントを含み得る。いくつかの実施形態では、通信サブシステム１２２４は、無線インターフェイスに加えてまたはその代わりに有線ネットワーク接続（たとえばイーサネット）を提供することができる。

通信サブシステム１２２４は、さまざまな形態のデータを送受信することができる。たとえば、いくつかの実施形態では、通信サブシステム１２２４は、構造化および／または非構造化データフィード１２２６、イベントストリーム１２２８、イベントアップデート１２３０等の形態の入力通信を受信し得る。たとえば、通信サブシステム１２２４は、ソーシャルメディアネットワークおよび／またはその他の通信サービスのユーザから、リアルタイムで、Twitter（登録商標）フィード、Facebook（登録商標）アップデート、リッチサイトサマリー（ＲＳＳ）フィード等のウェブフィード、および／または１以上の第三者情報源からのリアルタイムアップデート等のデータフィード１２２６を、受信（または送信）するように構成されてもよい。

特定の実施形態では、通信サブシステム１２２４は、本質的に連続しているまたは無限であり明確な終わりがない場合がある、リアルタイムイベントのイベントストリーム１２２８および／またはイベントアップデート１２３０を含み得る、連続データストリームの形態のデータを受信するように構成されてもよい。連続データを生成するアプリケーションの例は、たとえば、センサデータアプリケーション、株式相場表示機、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通量モニタリング等を含み得る。

通信サブシステム１２２４はまた、構造化および／または非構造化データフィード１２２６、イベントストリーム１２２８、イベントアップデート１２３０等を、コンピュータシステム１２００に連結されている１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。

コンピュータシステム１２００は、ハンドヘルドポータブルデバイス（たとえばiPhone（登録商標）携帯電話、iPad（登録商標）計算タブレット、ＰＤＡ）、ウェアラブルデバイス（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまな種類のうちの１つであればよい。

コンピュータおよびネットワークは常に変化しているという性質のものであるので、図１５に表わされるコンピュータシステム１２００の説明は、専ら特定の例を意図している。図１５に表わされるシステムよりもコンポーネントが多いまたは少ないその他多数の構成が可能である。本明細書が提供する開示と教示に基づいて、当業者はさまざまな実施形態を実現するためのその他のやり方および／または方法を認識するであろう。

一実施形態によると、通信サブシステム１２２４および通信サブシステム１２２４に結合された処理サブシステム１２０４を含むコンピュータシステムが提供される。処理サブシステム１２０４は、ユーザによるサービスのオーダーを通信サブシステム１２２４を介して受信するように構成され、サービスは一部はリソースの割当てによって可能になる。処理サブシステム１２０４はさらに：オーダーをパースして、リクエスタ、リソース、および要求時間を含む要求データを特定し；要求データをアグリゲートデータ構造に追加するように構成される。アグリゲートデータ構造は、以前にパースされたオーダーについての要求データのアグリゲートを含む。処理サブシステム１２０４はさらに：アグリゲートデータ構造に基づいて、リソースに対するリアルタイムデマンドを示す値を決定し；要求データの少なくとも１つのコンポーネントが、オーダーと、以前にパースされたオーダーからの少なくとも１つの他のオーダーとの間で同一であることに基づいて、オーダーを少なくとも１つの他のオーダーと相関付け；オーダーを少なくとも１つの他のオーダーと相関付けたことに基づいて、少なくとも１つのリソースセットを特定するように構成され、少なくとも１つのリソースセットは、オーダーからのリソースと、少なくとも１つの他のオーダーから要求された別のリソースとを含む。

一実施形態によると、パースすることは、リクエスタ、リソース、および要求時間の構造表現を提供する要求データからデータ構造を構築することを含む。

一実施形態によると、アグリゲートデータ構造は、パースされたオーダーからのデータ構造と、以前にパースされたオーダーからの１つ以上のデータ構造とを含む。

一実施形態によると、リソースに対するリアルタイムデマンドを示す値は、以前にパースされたオーダーについての要求データのアグリゲートから取得されるリソースについての現在の要求ボリュームを用いて決定される。

一実施形態によると、処理サブシステム１２０４はさらに：リソースに対するリアルタイムデマンドを示す、決定された値に基づいて、リソースの割当てに対する１つ以上のデマンドポリシーを生成または更新し；１つ以上のデマンドポリシーに基づいて、リソースを予め作成し；１つ以上のデマンドポリシーに基づいて、予め作成されたリソースを通信サブシステム１２２４を介して１人以上のユーザに割当てるように構成される。

一実施形態によると、リアルタイムデマンドを示す値を決定することは、以前にパースされたオーダーについての要求データのアグリゲートを用いて、特定の期間内にリソースを含むオーダーのパーセンテージを決定することを含む。

一実施形態によると、リアルタイムデマンドを示す値を決定することは、以前にパースされたオーダーについての要求データのアグリゲートを用いて、決定されたオーダーのパーセンテージを、リソースプール内の他のリソースに相対的なリソースのリアルタイムデマンドと相関付けることをさらに含む。

一実施形態によると、要求データの少なくとも１つのコンポーネントはリクエスタを含む。

一実施形態によると、処理サブシステム１２０４はさらに、リソースおよび別のリソースに加えて定期的に要求される追加のリソースを、リソース、別のリソース、および追加のリソースを含む、以前にパースされたオーダーのパーセンテージに基づいて特定するように構成される。

一実施形態によると、処理サブシステム１２０４はさらに、特定された少なくとも１つのリソースセットを、追加のリソースを含むように更新するように構成される。

一実施形態によると、処理サブシステム１２０４はさらに：少なくとも１つのリソースセットの割当てに対する１つ以上のデマンドポリシーを生成または更新し；１つ以上のデマンドポリシーに基づいて、互いに有線接続されたリソースおよび別のリソースを予め作成し；１つ以上のデマンドポリシーに基づいて、互いに有線接続されたリソースおよび別のリソースを含む少なくとも１つのリソースセットを通信サブシステム１２２４を介して１人以上のユーザに割当てるように構成される。

一実施形態によると、要求データのアグリゲートに基づいて、リソースプール内のリソースに対するリアルタイムデマンドを示す値を決定するように構成されたデマンドモニタ５７５を含むリソースマネージャ１０５；３０５；５０５；９０５；９７５が提供される。要求データのアグリゲートは、サービスを可能にする少なくとも一部としてリソースを含んでいたサービスに対する以前に受信された任意の数のオーダーから取得される。リソースマネージャ１０５；３０５；５０５；９０５；９７５はさらに、リソースに対するリアルタイムデマンドを示す、決定された値に基づいて、リソースの割当てに対する１つ以上のデマンドポリシーを生成または更新するように構成されたポリシーマネージャ３３５；５２５；９３５を含む。リソースマネージャ１０５；３０５；５０５；９０５；９７５は、１つ以上のデマンドポリシーに基づいて、リソースを予め作成し、１つ以上のデマンドポリシーに基づいて、予め作成されたリソースを１人以上のユーザに割当てるように構成される。

一実施形態によると、リソースに対するリアルタイムデマンドを示す値は、要求データのアグリゲートから取得されるリソースについての現在の要求ボリュームを用いて決定される。

一実施形態によると、リアルタイムデマンドを示す値を決定することは、以前に受信されたオーダーについての要求データのアグリゲートを用いて、特定の期間内にリソースを含むオーダーのパーセンテージを決定することを含む。

一実施形態によると、リアルタイムデマンドを示す値を決定することはさらに、以前に受信されたオーダーについての要求データのアグリゲートを用いて、決定されたオーダーのパーセンテージを、リソースプール内の他のリソースに相対的なリソースのリアルタイムデマンドと相関付けることを含む。

一実施形態によると、リソースマネージャ１０５；３０５；５０５；９０５；９７５はさらに、予め作成されたリソースをリソースプールに追加するように構成される。

一実施形態によると、リソースマネージャ１０５；３０５；５０５；９０５；９７５はさらに、、リソースプールを、予め作成されたリソースの１人以上のユーザへの割当てを示すように更新するように構成される。

一実施形態によると、通信サブシステム１２２４および通信サブシステム１２２４に結合された処理サブシステム１２０４を含むコンピュータシステムが提供される。処理サブシステム１２０４は、要求データのアグリゲートに基づいて、リソースプール内のリソースに対するリアルタイムデマンドを示す値を決定するように構成される。要求データのアグリゲートは、サービスを可能にする少なくとも一部としてリソースを含んでいたサービスに対する以前に受信された任意の数のオーダーから取得される。処理サブシステム１２０４はさらに：要求データの少なくとも１つのコンポーネントが、サービスのオーダーと、以前に受信されたオーダーからの少なくとも１つの他のオーダーとの間で同一であることに基づいて、オーダーを少なくとも１つの他のオーダーと相関付け；オーダーを少なくとも１つの他のオーダーと相関付けたことに基づいて、少なくとも１つのリソースセットを特定するように構成される。少なくとも１つのリソースセットは、オーダーからのリソースと、少なくとも１つの他のオーダーから要求された別のリソースとを含む。処理サブシステム１２０４はさらに：リソースプール内のリソースの利用を追跡し；（ｉ）リソースに対するリアルタイムデマンドを示す、決定された値、（ｉｉ）リソースを含む少なくとも１つのリソースセット、および（ｉｉｉ）追跡されたリソースの利用、の少なくとも１つに基づいて、リソースの割当てに対する１つ以上のデマンドポリシーを生成または更新し；１つ以上のデマンドポリシーに基づいて、（ｉ）リソースを予め作成する、（ｉｉ）リソースをリソースプールに追加する、（ｉｉｉ）リソースをクリーンにするように構成される。

一実施形態によると、処理サブシステム１２０４はさらに、１つ以上のデマンドポリシーに基づいて、通信サブシステム１２２４を介してリソースを１人以上のユーザに割当てるように構成される。

一実施形態によると、リソースに対するリアルタイムデマンドを示す値は、以前に受信されたオーダーについての要求データのアグリゲートから取得されるリソースについての現在の要求ボリュームを用いて決定される。

一実施形態によると、通信サブシステム１２２４および通信サブシステム１２２４に結合された処理サブシステム１２０４を含むコンピュータシステムが提供される。処理サブシステム１２０４は、ユーザからのリソース提出を通信サブシステム１２２４を介して受信するように構成される。リソース提出はコントリビューション可能なリソースを特定している。処理サブシステム１２０４はさらに、リソース提出に対するコントリビューションポリシーを特定するように構成される。コントリビューションポリシーは、コントリビューション可能なリソースのリソースタイプと、要求可能なリソースの１つ以上のリソースタイプとの間のマッピングに基づいて特定される。処理サブシステム１２０４はさらに、リソース提出に対して特定されたコントリビューションポリシーに基づいて、要求可能なリソースの１つ以上のリソースタイプを、ユーザと関連付けられているクライアントコンピューティングシステムに、通信サブシステム１２２４を介して送信するように構成される。処理サブシステム１２０４はさらに、要求可能なリソースの１つ以上のリソースタイプのうちの、ユーザによる１つのリソースタイプの選択を示す情報を、クライアントコンピューティングシステムから通信サブシステム１２２４を介して受信するように構成される。

一実施形態によると、コントリビューション可能なリソースはユーザによって管理される。

一実施形態によると、処理サブシステム１２０４はさらに、リソース提出に基づいて、コントリビューション可能なリソースのリソースタイプを決定するように構成される。コントリビューションポリシーを特定することは、リソースタイプがコントリビューション可能なリソースの１つ以上のリソースタイプと一致すると判断することを含み、コントリビューション可能なリソースの１つ以上のリソースタイプは、コントリビューションポリシーにおいて要求可能なリソースの１つ以上のリソースタイプにマップしている。

一実施形態によると、コントリビューションポリシーを特定することは、ユーザのリソースコントリビューションの履歴に少なくとも基づいてさらに決定される。

一実施形態によると、処理サブシステム１２０４はさらに、リソース提出において特定されたコントリビューション可能なリソースについてのアクセスクレデンシャルを、通信サブシステム１２２４を介して受信するように構成される。

一実施形態によると、アクセスクレデンシャルは、ユーザがコントリビューション可能なリソースを管理することを可能にする。

一実施形態によると、処理サブシステム１２０４はさらに、ユーザアカウント履歴およびリソースプールを、要求可能なリソースの１つ以上のリソースタイプのうちの１つのリソースタイプの選択を示すように更新するように構成される。

一実施形態によると、処理サブシステム１２０４はさらに、ユーザによるサービスのオーダーを通信サブシステム１２２４を介して受信するように構成される。サービスは一部はリソースの割当てによって可能になる。処理サブシステム１２０４はさらに、リソースのタイプがユーザによって選択された１つのリソースタイプと一致すると判断し、コントリビューション可能なリソースと交換に、サービスに対するリソースへのアクセスを可能にするように構成される。

一実施形態によると、リソースへのアクセスを可能にすることは、リソースをユーザに割当てることと、ユーザにサービスするためにリソースを構成することと、リソースが割当てられたという確認メッセージをユーザに送信することとを含む。

一実施形態によると、処理サブシステム１２０４はさらに、コントリビューションポリシー内に定義されている要求可能なリソースの１つ以上のリソースタイプに対するデマンドに基づいて、コントリビューションポリシーを更新するように構成される。

一実施形態によると、ユーザからのリソース提出を受信するように構成されたリソース提出インターフェイス５１０を含むリソースマネージャ１０５；３０５；５０５；９０５；９７５が提供される。リソース提出はコントリビューション可能なリソースを特定している。リソースマネージャ１０５；３０５；５０５；９０５；９７５はさらに、リソース提出に基づいて、コントリビューション可能なリソースのリソースタイプを決定し、リソース提出に対するコントリビューションポリシーを特定するように構成されたポリシーマネージャ３３５；５２５；９３５を含む。コントリビューションポリシーを特定することは、リソースタイプが、コントリビューションポリシーにおいて要求可能なリソースの１つ以上のリソースタイプにマップしているコントリビューション可能なリソースの１つ以上のリソースタイプと一致すると判断することを含む。リソース提出インターフェイス５１０はさらに、リソース提出に対して特定されたコントリビューションポリシーに基づいて、要求可能なリソースの１つ以上のリソースタイプを、ユーザと関連付けられているクライアントコンピューティングシステムに送信するように構成される。リソース提出インターフェイス５１０はさらに、要求可能なリソースの１つ以上のリソースタイプのうちの、ユーザによる１つのリソースタイプの選択を示す情報を、クライアントコンピューティングシステムから受信するように構成される。

一実施形態によると、コントリビューション可能なリソースはユーザによって管理される。

一実施形態によると、リソース提出インターフェイス５１０はさらに、リソース提出において特定されたコントリビューション可能なリソースについてのアクセスクレデンシャルを受信するように構成される。アクセスクレデンシャルは、ユーザがコントリビューション可能なリソースを管理することを可能にする。

一実施形態によると、リソースマネージャ１０５；３０５；５０５；９０５；９７５はさらに、コントリビューション可能なリソースと交換に、ユーザによって選択された１つのリソースタイプと一致するタイプのリソースを割当てるように構成される。

一実施形態によると、割当てることは、ユーザにサービスするためにリソースを構成することを含む。

一実施形態によると、リソース提出インターフェイス５１０はさらに、ユーザによるサービスのオーダーを受信するように構成され、サービスは一部はリソースの割当てによって可能になる。リソースマネージャ１０５；３０５；５０５；９０５；９７５はさらに、リソースのタイプがユーザによって選択された１つのリソースタイプと一致すると判断し、コントリビューション可能なリソースと交換に、サービスに対するリソースへのアクセスを可能にするように構成される。

一実施形態によると、リソースマネージャ１０５；３０５；５０５；９０５；９７５はさらに、コントリビューションポリシー内に定義されているコントリビューション可能なリソースの１つ以上のリソースタイプまたは要求可能なリソースの１つ以上のリソースタイプに対するデマンドに基づいて、コントリビューションポリシーを更新するように構成される。

一実施形態によると、通信サブシステム１２２４および通信サブシステム１２２４に結合された処理サブシステム１２０４を含むコンピュータシステムが提供される。処理サブシステム１２０４は、ユーザからのサービスのオーダーを通信サブシステム１２２４を介して受信するように構成され、オーダーはコントリビューション可能なリソースおよび要求可能なリソースを特定している。コントリビューション可能なリソースは、要求可能なリソースと交換にリソースプールに提供されることになっている。処理サブシステム１２０４はさらに、コントリビューションポリシーに基づいてリソース提出を受付けるように構成される。コントリビューションポリシーは、コントリビューション可能なリソースのタイプの第１のリソースタイプと要求可能なリソースのタイプの第２のリソースタイプとの間のマッピングを定義している。処理サブシステム１２０４はさらに、コントリビューション可能なリソースへのアクセスおよびコントリビューション可能なリソースに対する制御を提供するアクセスクレデンシャルを通信サブシステム１２２４を介して受信するように構成される。処理サブシステム１２０４はさらに、リソースプールを、分散システムの１人以上のユーザにサービスするためにコントリビューション可能なリソースの可用性を示すように更新するように構成される。処理サブシステム１２０４はさらに、要求可能なリソースを通信サブシステム１２２４を介してユーザに割当てるように構成される。

一実施形態によると、コントリビューション可能なリソースはユーザによって管理され、要求可能なリソースは別のユーザによって管理される。

一実施形態によると、コントリビューション可能なリソースはユーザによって管理され、要求可能なリソースは、分散システムのリソースマネージャによって管理されるリソースプールのコンポーネントである。

本発明の特定の実施形態について説明してきたが、さまざまな変形例、変更例、代替的な構成および等価物も本発明の範囲内に包含される。変形例は、開示された特徴の任意の関連する組み合わせを含む。本発明の実施形態は、特定の具体的なデータ処理環境内での動作に限定されるものではなく、複数のデータ処理環境内で自由に動作できる。さらに、特定の一連のトランザクションおよびステップを使用して本発明の実施形態について説明してきたが、本発明の範囲が、記載されている一連のトランザクションおよびステップに限定されるものではないということが当業者に明らかであるべきである。上記の実施形態のさまざまな特徴および局面は、個別にまたはともに使用され得る。

さらに、ハードウェアおよびソフトウェアの特定の組み合わせを使用して本発明の実施形態について説明してきたが、ハードウェアおよびソフトウェアの他の組み合わせも本発明の範囲内であることが認識されるべきである。本発明の実施形態は、ハードウェアのみで実現されてもよく、またはソフトウェアのみで実現されてもよく、またはこれらの組み合わせを使用して実現されてもよい。本明細書に記載されるさまざまなプロセスは、同じプロセッサ上で、または任意に組み合わされたさまざまなプロセッサ上で実現することができる。したがって、コンポーネントまたはモジュールがいくつかのオペレーションを実行するように構成されるものと記載されているが、このような構成は、たとえば、オペレーションを実行するように電子回路を設計することによって、オペレーションを実行するようにプログラム可能な電子回路（マイクロプロセッサなど）をプログラミングすることによって、またはこれらを組み合わせることによって、達成することができる。プロセス同士は、プロセス間通信のための従来の技術を含むがこれらに限定されるものではないさまざまな技術を用いて通信することができ、異なる対のプロセスが異なる技術を用いてもよく、または、同じ対のプロセスが異なる時間に異なる技術を用いてもよい。

したがって、明細書および図面は、限定的な意味ではなく例示的な意味で考えられるべきである。しかし、特許請求の範囲に記載されているより広範な精神および範囲から逸脱することなく、追加、削減、削除ならびに他の変形および変更がそれに対してなされてもよいということは明白であろう。このように、特定の発明の実施形態を記載してきたが、これらは限定的であるよう意図されるものではない。さまざまな変更例および同等例は添付の特許請求の範囲内にある。

Claims (30)

1. 方法であって、
   ユーザによるサービスのオーダーをコンピューティングシステムによって受信することを備え、前記サービスは一部はリソースの割当てによって可能になり、前記方法はさらに、
   前記コンピューティングシステムによって前記オーダーをパースして、リクエスタ、前記リソース、および要求時間を備える要求データを特定することと、
   前記コンピューティングシステムによって前記要求データをアグリゲートデータ構造に追加することとを備え、前記アグリゲートデータ構造は、以前にパースされたオーダーについての前記要求データのアグリゲートを含み、前記方法はさらに、
   前記アグリゲートデータ構造に基づいて、前記リソースに対するリアルタイムデマンドを示す値を前記コンピューティングシステムによって決定することと、
   前記要求データの少なくとも１つのコンポーネントが、前記オーダーと、以前にパースされた前記オーダーからの少なくとも１つの他のオーダーとの間で同一であることに基づいて、前記コンピューティングシステムによって、前記オーダーを前記少なくとも１つの他のオーダーと相関付けることと、
   前記オーダーを前記少なくとも１つの他のオーダーと相関付けたことに基づいて、前記コンピューティングシステムによって少なくとも１つのリソースセットを特定することとを備え、前記少なくとも１つのリソースセットは、前記オーダーからの前記リソースと、前記少なくとも１つの他のオーダーから要求された別のリソースとを含む、方法。
2. 前記パースすることは、前記リクエスタ、前記リソース、および前記要求時間の構造表現を提供する前記要求データからデータ構造を構築することを備える、請求項１に記載の方法。
3. 前記アグリゲートデータ構造は、パースされた前記オーダーからの前記データ構造と、以前にパースされた前記オーダーからの１つ以上のデータ構造とを備える、請求項２に記載の方法。
4. 前記リソースに対する前記リアルタイムデマンドを示す前記値は、以前にパースされた前記オーダーについての前記要求データの前記アグリゲートから取得される前記リソースについての現在の要求ボリュームを用いて決定される、請求項１から３のいずれか一項に記載の方法。
5. 前記リソースに対する前記リアルタイムデマンドを示す、決定された前記値に基づいて、前記リソースの割当てに対する１つ以上のデマンドポリシーを前記コンピューティングシステムによって生成または更新することと、
   前記１つ以上のデマンドポリシーに基づいて、前記リソースを前記コンピューティングシステムによって予め作成することと、
   前記１つ以上のデマンドポリシーに基づいて、予め作成された前記リソースを、前記コンピューティングシステムによって１人以上のユーザに割当てることとをさらに備える、請求項４項に記載の方法。
6. 前記リアルタイムデマンドを示す値を決定することは、以前にパースされた前記オーダーについての前記要求データの前記アグリゲートを用いて、特定の期間内に前記リソースを含むオーダーのパーセンテージを決定することを備える、請求項１から３のいずれか一項に記載の方法。
7. 前記リアルタイムデマンドを示す値を決定することは、以前にパースされた前記オーダーについての前記要求データの前記アグリゲートを用いて、決定されたオーダーの前記パーセンテージを、リソースプール内の他のリソースに相対的な前記リソースの前記リアルタイムデマンドと相関付けることを備える、請求項６に記載の方法。
8. 前記要求データの前記少なくとも１つのコンポーネントは前記リクエスタを含む、請求項１から３のいずれか一項に記載の方法。
9. 前記リソースおよび前記別のリソースに加えて定期的に要求される追加のリソースを、前記リソース、前記別のリソース、および前記追加のリソースを含む、以前にパースされた前記オーダーのパーセンテージに基づいて、前記コンピューティングシステムによって特定することをさらに備える、請求項１から３のいずれか一項に記載の方法。
10. 特定された前記少なくとも１つのリソースセットを、前記追加のリソースを含むように、前記コンピューティングシステムによって更新することをさらに備える、請求項９に記載の方法。
11. 前記少なくとも１つのリソースセットの割当てに対する１つ以上のデマンドポリシーを前記コンピューティングシステムによって生成または更新することと、
    前記１つ以上のデマンドポリシーに基づいて、互いに有線接続された前記リソースおよび前記別のリソースを前記コンピューティングシステムによって予め作成することと、
    前記１つ以上のデマンドポリシーに基づいて、互いに有線接続された前記リソースおよび前記別のリソースを含む前記少なくとも１つのリソースセットを、前記コンピューティングシステムによって１人以上のユーザに割当てることとをさらに備える、請求項１から３のいずれか一項に記載の方法。
12. 命令が格納されている非一時的な機械読取可能記憶媒体であって、前記命令は、１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに方法を実行させ、前記方法は、
    要求データのアグリゲートに基づいて、リソースプール内のリソースに対するリアルタイムデマンドを示す値を決定することを備え、前記要求データの前記アグリゲートは、サービスを可能にする少なくとも一部として前記リソースを含んでいたサービスに対する以前に受信された任意の数のオーダーから取得され、前記方法はさらに、
    前記リソースに対する前記リアルタイムデマンドを示す、決定された前記値に基づいて、前記リソースの割当てに対する１つ以上のデマンドポリシーを生成または更新することと、
    前記１つ以上のデマンドポリシーに基づいて、前記リソースを予め作成することと、
    前記１つ以上のデマンドポリシーに基づいて、予め作成された前記リソースを１人以上のユーザに割当てることとを備える、非一時的な機械読取可能記憶媒体。
13. 前記リソースに対する前記リアルタイムデマンドを示す前記値は、前記要求データの前記アグリゲートから取得される前記リソースについての現在の要求ボリュームを用いて決定される、請求項１２に記載の非一時的な機械読取可能記憶媒体。
14. システムであって、
    １つ以上のプロセッサおよび非一時的な機械読取可能記憶媒体と、
    要求データのアグリゲートに基づいて、リソースプール内のリソースに対するリアルタイムデマンドを示す値を決定するプログラム命令とを備え、前記要求データの前記アグリゲートは、サービスを可能にする少なくとも一部として前記リソースを含んでいたサービスに対する以前に受信された任意の数のオーダーから取得され、前記システムはさらに、
    前記要求データの少なくとも１つのコンポーネントが、サービスのオーダーと、以前に受信された前記オーダーからの少なくとも１つの他のオーダーとの間で同一であることに基づいて、前記オーダーを前記少なくとも１つの他のオーダーと相関付けるプログラム命令と、
    前記オーダーを前記少なくとも１つの他のオーダーと相関付けたことに基づいて、少なくとも１つのリソースセットを特定するプログラム命令とを備え、前記少なくとも１つのリソースセットは、前記オーダーからの前記リソースと、前記少なくとも１つの他のオーダーから要求された別のリソースとを含み、前記システムはさらに、
    前記リソースプール内の前記リソースの利用を追跡するプログラム命令と、
    （ｉ）前記リソースに対する前記リアルタイムデマンドを示す、決定された前記値、（ｉｉ）前記リソースを含む前記少なくとも１つのリソースセット、および（ｉｉｉ）追跡された前記リソースの利用、の少なくとも１つに基づいて、リソースの割当てに対する１つ以上のデマンドポリシーを生成または更新するプログラム命令と、
    前記１つ以上のデマンドポリシーに基づいて、（ｉ）前記リソースを予め作成する、（ｉｉ）前記リソースを前記リソースプールに追加する、（ｉｉｉ）前記リソースをクリーンにする、の少なくとも１つを行うプログラム命令とを備え、
    前記プログラム命令は、前記１つ以上のプロセッサによって実行されるように、前記非一時的な機械読取可能記憶媒体上に格納されている、システム。
15. 前記１つ以上のデマンドポリシーに基づいて前記リソースを１人以上のユーザに割当てるプログラム命令をさらに備える、請求項１４に記載のシステム。
16. 前記リソースに対する前記リアルタイムデマンドを示す前記値は、以前に受信された前記オーダーについての前記要求データの前記アグリゲートから取得される前記リソースについての現在の要求ボリュームを用いて決定される、請求項１４に記載のシステム。
17. 方法であって、
    ユーザからのリソース提出をコンピューティングシステムによって受信することを備え、前記リソース提出はコントリビューション可能なリソースを特定しており、前記方法はさらに、
    前記リソース提出に対するコントリビューションポリシーを前記コンピューティングシステムによって特定することを備え、前記コントリビューションポリシーは、前記コントリビューション可能なリソースのリソースタイプと、要求可能なリソースの１つ以上のリソースタイプとの間のマッピングに基づいて特定され、前記方法はさらに、
    前記リソース提出に対して特定された前記コントリビューションポリシーに基づいて、前記要求可能なリソースの前記１つ以上のリソースタイプを、前記ユーザと関連付けられているクライアントコンピューティングシステムに、前記コンピューティングシステムによって送信することと、
    前記要求可能なリソースの前記１つ以上のリソースタイプのうちの、前記ユーザによる１つのリソースタイプの選択を示す情報を、前記クライアントコンピューティングシステムから前記コンピューティングシステムによって受信することとを備える、方法。
18. 前記コントリビューション可能なリソースは前記ユーザによって管理される、請求項１７に記載の方法。
19. 前記リソース提出に基づいて、前記コントリビューション可能なリソースの前記リソースタイプを前記コンピューティングシステムによって決定することをさらに備え、前記コントリビューションポリシーを特定することは、前記リソースタイプがコントリビューション可能なリソースの１つ以上のリソースタイプと一致すると判断することを含み、コントリビューション可能なリソースの前記１つ以上のリソースタイプは、前記コントリビューションポリシーにおいて前記要求可能なリソースの前記１つ以上のリソースタイプにマップしている、請求項１８に記載の方法。
20. 前記コントリビューションポリシーを特定することは、前記ユーザのリソースコントリビューションの履歴に少なくとも基づいてさらに決定される、請求項１７から１９のいずれか一項に記載の方法。
21. 前記リソース提出において特定された前記コントリビューション可能なリソースについてのアクセスクレデンシャルを、前記コンピューティングシステムによって受信することをさらに備える、請求項１７から１９のいずれか一項に記載の方法。
22. 前記アクセスクレデンシャルは、前記ユーザが前記コントリビューション可能なリソースを管理することを可能にする、請求項２１に記載の方法。
23. ユーザアカウント履歴およびリソースプールを、前記要求可能なリソースの前記１つ以上のリソースタイプのうちの前記１つのリソースタイプの選択を示すように、前記コンピューティングシステムによって更新することをさらに備える、請求項１７から１９のいずれか一項に記載の方法。
24. 前記ユーザによるサービスのオーダーを前記コンピューティングシステムによって受信することをさらに備え、前記サービスは一部はリソースの割当てによって可能になり、さらに、
    前記リソースのタイプが前記ユーザによって選択された前記１つのリソースタイプと一致すると、前記コンピューティングシステムによって判断することと、
    前記コントリビューション可能なリソースと交換に、前記サービスに対する前記リソースへのアクセスを、前記コンピューティングシステムによって可能にすることとを備える、請求項１７から１９のいずれか一項に記載の方法。
25. 前記コントリビューションポリシー内に定義されている要求可能なリソースの前記１つ以上のリソースタイプに対するデマンドに基づいて、前記コントリビューションポリシーを前記コンピューティングシステムによって更新することをさらに備える、請求項１７から１９のいずれか一項に記載の方法。
26. 命令が格納されている非一時的な機械読取可能記憶媒体であって、前記命令は、１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに方法を実行させ、前記方法は、
    ユーザからのリソース提出を受信することを備え、前記リソース提出はコントリビューション可能なリソースを特定しており、前記方法はさらに、
    前記リソース提出に基づいて、前記コントリビューション可能なリソースのリソースタイプを決定することと、
    前記リソース提出に対するコントリビューションポリシーを特定することとを備え、前記コントリビューションポリシーを特定することは、前記リソースタイプが、前記コントリビューションポリシーにおいて要求可能なリソースの１つ以上のリソースタイプにマップしているコントリビューション可能なリソースの１つ以上のリソースタイプと一致すると判断することを含み、前記方法はさらに、
    前記リソース提出に対して特定された前記コントリビューションポリシーに基づいて、前記要求可能なリソースの前記１つ以上のリソースタイプを、前記ユーザと関連付けられているクライアントコンピューティングシステムに送信することと、
    前記要求可能なリソースの前記１つ以上のリソースタイプのうちの、前記ユーザによる１つのリソースタイプの選択を示す情報を、前記クライアントコンピューティングシステムから受信することとを備える、非一時的な機械読取可能記憶媒体。
27. 前記方法は、前記コントリビューション可能なリソースと交換に、前記ユーザによって選択された前記１つのリソースタイプと一致するタイプのリソースを割当てることをさらに備える、請求項２６に記載の非一時的な機械読取可能記憶媒体。
28. システムであって、
    １つ以上のプロセッサおよび非一時的な機械読取可能記憶媒体と、
    ユーザからのサービスのオーダーを受信するプログラム命令とを備え、前記オーダーはコントリビューション可能なリソースおよび要求可能なリソースを特定しており、前記コントリビューション可能なリソースは、前記要求可能なリソースと交換にリソースプールに提供されることになっており、前記システムはさらに、
    コントリビューションポリシーに基づいてリソース提出を受付けるプログラム命令を備え、前記コントリビューションポリシーは、前記コントリビューション可能なリソースのタイプの第１のリソースタイプと前記要求可能なリソースのタイプの第２のリソースタイプとの間のマッピングを定義しており、前記システムはさらに、
    前記コントリビューション可能なリソースへのアクセスおよび前記コントリビューション可能なリソースに対する制御を提供するアクセスクレデンシャルを受信するプログラム命令と、
    前記リソースプールを、分散システムの１人以上のユーザにサービスするために前記コントリビューション可能なリソースの可用性を示すように更新するプログラム命令と、
    前記要求可能なリソースを前記ユーザに割当てるプログラム命令とを備え、
    前記プログラム命令は、前記１つ以上のプロセッサによって実行されるように、前記非一時的な機械読取可能記憶媒体上に格納されている、システム。
29. 前記コントリビューション可能なリソースは前記ユーザによって管理され、前記要求可能なリソースは別のユーザによって管理される、請求項２８に記載のシステム。
30. 前記コントリビューション可能なリソースは前記ユーザによって管理され、前記要求可能なリソースは、前記分散システムのリソースマネージャによって管理される前記リソースプールのコンポーネントである、請求項２８に記載のシステム。