JP5746351B2 - コンピューティング能力に対する要求を動的に管理するための方法およびシステム - Google Patents

Description

関連出願の相互参照
本願は、２０１０年９月２１日に出願された米国非仮出願第１２／８８７，２４１号の利益を主張し、その開示が参照により全体として本明細書に組み込まれる。

企業および組織は、それらの業務をサポートするために多数のコンピューティングシステムを相互接続するコンピュータネットワークを運用する。コンピューティングシステムは、単一の地理的位置に（例えば、ローカルネットワークの一部として）配置できるか、または（例えば、１つまたは複数のプライベートまたはパブリック中間ネットワークを介して接続された）複数の別個の地理的位置に配置できる。データセンターは、例えば、単一の組織によって運用されるプライベートデータセンター、およびコンピューティング資源を顧客に提供するために第三者によって運営されるパブリックデータセンターなど、かなりの数の相互接続されたコンピューティングシステムを収容し得る。パブリックおよびプライベートのデータセンターは、ネットワークアクセス、電力、ハードウェア資源（例えば、コンピューティングおよび記憶装置）、ならびにそのデータセンター、組織によって、または他の顧客によって所有されるハードウェアのための安全な設置施設を提供し得る。

データセンター資源の増大した利用を容易にするため、仮想化技術は、単一の物理コンピューティングマシンが、接続されたコンピュータユーザーに対して、単独のコンピュータマシンとして見えて動作する、仮想マシンの１つまたは複数のインスタンスをホストできるようにし得る。仮想化を用いると、単一の物理コンピューティング装置は、仮想マシンを、動的な方法で、作成、維持、または削除することができる。その結果として、ユーザーがデータセンターからコンピュータ資源を要求し、「必要に応じて」ベースで、または少なくとも「要求に応じて」ベースで、様々な数の仮想マシン資源が提供されることが可能になる。

データセンターの規模および範囲が増大してきたのにつれて、データセンターの物理および仮想コンピューティング資源の提供、管理、および運営が次第に複雑になってきた。

全ての図にわたって、参照番号は、参照される要素間の対応を示すために再使用され得る。図は、本明細書に記載する実施形態例を図解するために提供され、本開示の範囲を制限することは意図していない。

複数のユーザーコンピューティングシステムに通信ネットワークを介してコンピューティング資源を提供できるプログラム実行サービスの一例を概略的に示すネットワーク図である。 プログラム実行サービスのユーザーによるコンピューティング資源に対する要求を管理するように構成された対話型要求マネージャのコンポーネントを示す概略ブロック図である。 ユーザーコンピューティングシステムとプログラム実行サービスの対話型要求マネージャとの間の相互作用例を概略的に示すネットワーク図である。 対話型要求マネージャのコンポーネントによって実装される対話型要求マネージャルーチンを示す流れ図である。 対話型要求マネージャのコンポーネントによって実装される対話型要求マネージャルーチンを示す流れ図である。 対話型要求マネージャの実施形態が、それによって、割り当てられたコンピューティング資源の設定を変更するためにユーザーコンピューティングシステムと通信できる、ルーチンの一例を概略的に示す流れ図である。 対話型要求マネージャの実施形態が、それによって、ユーザーによる選択のために複数の仮想化環境を提供するために、ユーザーコンピューティングシステムと通信できる、ルーチンの一例を概略的に示す流れ図である。

コンピューティング資源のプロバイダ（プログラム実行サービス）からのコンピューティング能力に対する要求を動的に管理するためのシステムおよび方法の実施形態を説明する。実例として、コンピューティング資源には、プログラム実行能力、データ記憶または管理能力、データベース管理能力、ネットワーク帯域幅、アプリケーションモニタリングまたはロギング、問題に対処するために是正処置をとる能力などを含み得る。いくつかの実施形態では、ユーザーは、現在または将来の利用期間中に、ユーザーのためにコンピュータ資源を管理できる仮想化環境が生成されることを要求できる。例えば、ユーザーは、ユーザーのカスタムソフトウェアアプリケーションを実行でき、かつ、利用期間中、そのユーザーのために、適切なプログラム実行能力、データ記憶容量、データベース管理オプション、および／もしくはネットワーク帯域幅を管理または確保できる仮想化環境が生成されることを要求できる。コンピューティング資源プロバイダは、プロバイダのどのコンピュータ資源が、ユーザーの要求を満たすために利用可能にできるかを決定でき、要求された利用期間中、それらのコンピュータ資源をユーザーに割り当てることができる。

ユーザーの要求の利用期間および／または他のパラメータは、コンピュータ資源に対するユーザーの必要性を満たすために、高度な柔軟性をもって選択され得る。ユーザーの要求は、ユーザーによる好み、制約、および／または要件を指定するために、１つまたは複数のユーザー選択可能パラメータを含み得る。例えば、ユーザーの要求は、利用期間中に特定のプログラム（または複数のプログラム）が実行されること、利用期間中にあるタイプまたは地理的分散のコンピュータ資源が使用されること、利用期間が所望の開始日、終了日、および／または継続期間を有すること、などを指定できる。いくつかの実施形態では、コンピューティング資源プロバイダは、ユーザーによって提出できる要求パラメータの範囲にほとんどまたは全く制限を加えない。

可能な一例として、ユーザーは、特定のプログラムがコンピュータ資源のセット上で実行されることを要求することが可能であり得、それには、１つまたは複数の地理的位置におけるコンピュータ資源を含み得る。ユーザーは、プログラムおよびプログラム実行パラメータを仮想化環境生成のためにプログラム実行サービスに伝達するために、アプリケーションプログラミングインタフェース（ＡＰＩ）または他のタイプのコンピューティングインタフェースを使用することが可能であり得る。例えば、ユーザーは、Ｊａｖａ ＷＡＲファイルなどのウェブアプリケーションアーカイブを用いて、ソフトウェアアプリケーションをアップロードし得る。プログラム実行サービスは、次いで、自動的に仮想化環境（例えば、「アプリケーションコンテナ」）を構成し得、それは、ユーザーのプログラムをプログラム実行サービス上で実行するための１つまたは複数のインフラストラクチャサービスと共に、ユーザーのプログラムのためのアプリケーションソフトウェアスタックを含む実行時環境であり得る。アプリケーションコンテナは、ユーザー選択可能なオペレーティングシステム（例えば、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓなど）、アプリケーションサーバー（例えば、Ａｐａｃｈｅ Ｔｏｍｃａｔ）、システムまたはアプリケーション構成などを含むことができる。仮想化環境は、特定のＵＲＬでホストされるように構成できる。インフラストラクチャサービスは、要求されたコンピューティング資源にわたって作業負荷を分散するための負荷分散装置、負荷または需要の変動に応じてコンピューティング資源をスケーリングするための負荷スケーラ（ｌｏａｄ ｓｃａｌｅｒ）、ユーザーがプログラムの実行をモニタリングできるようにするモニタリングインタフェース、データ記憶資源（例えば、拡張可能なボリュームブロックストレージ）などを含むことができるが、それらに限定されない。いくつかの実施形態では、ユーザーは、コンテナ内に含めることができる１つもしくは複数のプログラムまたはサービスを選択することが可能であり得る。例えば、ユーザーは、複数のデータベースモデル（例えば、リレーショナルデータベース、ＳＱＬデータベース、Ｏｒａｃｌｅデータベースなど）から選択することが可能であり得る。いくつかの実施形態では、インフラストラクチャサービスは、複数のユーザー間で共有されている資源ではなく、むしろ、ユーザーに対してカスタマイズできる。例えば、いくつかのかかる実施形態では、負荷分散装置は、プログラム実行サービスのいく人かのユーザー間で共有または分散されているのではなく、ユーザーのアプリケーション用に個別にカスタマイズできる。

仮想化環境のある実施形態の考えられる利点は、コンピューティングシステムが、ユーザーがそのように望めば、ユーザーがある程度の柔軟性を有し、アプリケーションコンテナの内容について制御できるようにすることである。例えば、ある場合には、ユーザーは、ユーザーのプログラムのみを提供し得、コンピューティングシステムが、仮想化環境によって使用される全ての残りのインフラストラクチャの配備を自動的に管理し得る。他の場合には、ユーザーは、仮想化環境に含まれる１つまたは複数のインフラストラクチャサービスを選択および／または構成し得る。ある場合には、ユーザーは、ユーザーのアプリケーションに対して所望の配備トポロジを達成するために、様々な地理的地域におけるコンピューティング資源を選択し得る。配備トポロジは、任意の所望の方法で構成または選択され得る。例えば、配備トポロジは、アプリケーションの性能を向上させる（例えば、ネットワーク待ち時間を減少させる）ために、ユーザーの顧客の位置または地域に基づき得る。別の例として、配備トポロジは、例えば、特定の地域または区域における（例えば、ある地域または区域における悪天候による）コンピューティング資源の障害に対するアプリケーションの障害許容性（ｒｅｓｉｌｉｅｎｃｙ）を向上させることにより、ユーザーのアプリケーションの頑強性を向上させるために、１つもしくは複数の地域または区域におけるコンピューティング資源を使用するように構成され得る。また、ある実施形態では、ユーザーは、プログラムの実行中にコンピューティング資源へのアクセスを保持し、ユーザーは、実行中にコンピューティング資源の一部または全部を制御し得る。例えば、いくつかのかかる実施形態では、ユーザーがそのように望めば、ユーザーは、ユーザーのアプリケーションを仮想化環境の外に移動させることを選択し得る。

ある料金ベースの実施態様では、コンピュータ資源のプロバイダは、ユーザーに要求に対する予約料金を請求し得る（例えば、要求が許可された場合）か、および／または利用期間中に利用可能なコンピュータ資源の利用の提供に対する利用料金を請求し得る。様々なタイプまたは段階の料金取り決めが可能である。例えば、コンピュータ資源は、ユーザーにより即時利用のために要求され得る（「オンデマンド資源」）。いくつかのかかる場合には、ユーザーは、予約料金を支払うのではなく、もっと高い利用料金を支払い得るだろう。別の例として、ユーザーは、将来の利用期間中の保証された可用性に対してコンピュータ資源を予約し得る（「予約された資源」）。ユーザーは、予約をすることに対して予約料金を請求され得、また、利用期間中に実際に使用されたコンピュータ資源の量に基づいて利用料金も請求され得る。いくつかのかかる場合には、予約された資源に対する利用料金は、オンデマンドの資源に対する利用料金から割り引かれ得るか、かつ／または予約料金は、要求が行われた時の近くではなく、むしろ利用期間に近い時に請求され得る。別の例では、コンピュータ資源プロバイダは、ユーザーが未使用のコンピュータ資源（「スポット資源」）に入札できるようにし得る。いくつかのかかる場合には、コンピュータ資源プロバイダは、資源に対する供給と需要に基づいて変わるスポット価格を設定し得、その資源は、スポット価格に合致するか、またはそれを上回る付け値のユーザーに対して利用可能になり得る。

ここで、本開示の様々な態様を、ある例および実施形態に関して説明するが、それらは、本開示を制限するのではなく、例証することを意図する。

図１は、コンピューティング資源を、通信ネットワーク１０８を経由して複数のユーザーコンピューティングシステム１０４に提供できるプログラム実行サービス１００の一例を概略的に示すネットワーク図である。例えば、プログラム実行サービス１００は、ユーザーからの、プログラムまたはプログラムのセットをユーザーの代わりに実行する要求を管理できる。少なくともいくつかのユーザーコンピューティングシステム１０４は、プログラム実行サービス１００から離れたところにあり得る。この例では、ユーザーは、通信ネットワーク１０８を介して、プログラム実行サービス１００にアクセスするためにコンピューティングシステム１０４を利用できる。ネットワーク１０８は、例えば、インターネットなどの、おそらくは様々な別個の関係者によって運用されている、リンクされたネットワークの公的にアクセス可能なネットワークであり得る。他の実施形態では、ネットワーク１０８は、例えば、特権のないユーザーは、完全にまたは部分的にアクセスできない企業または大学のネットワークなど、プライベートネットワークであり得る。さらに他の実施形態では、ネットワーク１０８は、インターネットへのおよび／またはインターネットからのアクセスを有する、１つまたは複数のプライベートネットワークであり得る。

プログラム実行サービス１００は、複数のユーザーに対するプログラム実行を管理するための様々な機能性を提供する。図１に示す例では、プログラム実行サービス１００は、ユーザーの代わりにプログラムを実行できる複数のコンピューティングノード１１２を含む。コンピューティングノード１１２は、１つもしくは複数の物理コンピューティングシステム１１６および／または１つもしくは複数の物理コンピューティングシステム上でホストされる１つもしくは複数の仮想マシン１２０を含み得る。例えば、ホストコンピューティングシステムは、複数の仮想マシン１２０を提供し得、それらの仮想マシンを管理するために仮想マシン（「ＶＭ」）マネージャ１２４（例えば、ハイパーバイザまたは他の仮想マシンモニター）を含み得る。

図１に示す例では、コンピューティングノード１１２の各々は、１つまたは複数のプログラムの実行に利用可能なある量のコンピューティング資源を有する。各コンピューティングノード１１２は、特定量のプログラム実行能力を提供するように構成され得、それは、例えば、処理能力（例えば、処理装置の数および／またはサイズ）、メモリ容量、記憶容量、ネットワーク帯域幅容量、非ネットワーク通信帯域幅などのうちの１つまたは複数の組合せによって測定され得る。いくつかの実施形態では、プログラム実行サービス１００は、事前に構成されたコンピューティングノード１１２を提供し得、その各事前に構成されたコンピューティングノードは、ユーザーの代わりにプログラムを実行するために利用可能な同様および／または均等量の資源を有する。他の実施形態では、プログラム実行サービス１００は、ユーザーが、ユーザーの代わりにプログラムを実行するために選択し得る、様々な異なるコンピューティングノード１１２の選択を提供し得る。さらに別の実施形態では、プログラム実行サービス１００は、ユーザーおよびユーザーのプログラム実行に固有である様々なコンピューティングノードを生成し得る。いくつかのかかる実施形態では、コンピューティングノード１１２は、変化する量および／またはタイプのコンピューティング資源（例えば、処理装置のサイズ、速度および／またはタイプ；処理装置の数；メモリおよび／または記憶容量；３２ビットまたは６４ビット、オペレーティングシステムなどのプラットフォーム構成）を有し得る。

プログラム実行サービス１００は、データ、プログラム、および他のユーザー情報の大容量記憶を提供する記憶ノード１３４へのアクセスを有するユーザーコンピューティングシステム１０４を提供し得る。記憶ノード１３４は、例えば、ハードディスクドライブ、光ディスクドライブなどの不揮発性メモリ装置など、任意のタイプの永続的なデータ記憶を含み得る。図１に示す例では、コンピューティングノード１１２は、ネットワーク１２８を経由して記憶ノード１３４にアクセスできる。ネットワーク１２８は、例えば、スイッチ、エッジルーター、コアルーターなどの、複数のネットワーク装置（図示せず）を含み得る。ネットワーク１２８は、図１に示すネットワーク１０８とは異なるネットワークであり得るが、その必要はない。

プログラム実行サービス１００のユーザーは、プログラム実行サービスの好ましいおよび／または必要な資源（例えば、プログラム実行能力および／または記憶資源）を要求するために、対話型要求マネージャ１３０を通じて、プログラム実行サービス１００と対話できる。対話型要求マネージャ１３０は、ネットワーク１２８を経由して、コンピューティングノード１１２および記憶ノード１３４に接続できる。対話型要求マネージャ１３０は、資源に対する要求を、ユーザーコンピューティングシステム１０４からネットワーク１０８を介して受信できる。ユーザーは、サービス１００が、ユーザー（またはそのユーザーによって認可された他のユーザー）の代わりに、プログラム（または複数のプログラム）を実行するための１つまたは複数のコンピューティングノードを提供することを、対話型要求マネージャ１３０を通じて要求し得る。いくつかの実施形態では、ユーザーは、対話型要求マネージャ１３０を通じて、サービス１００が、ユーザーの代わりにプログラム（または複数のプログラム）を実行するために必要であり得るコンピューティング資源を管理および確保できる１つまたは複数のコンピューティングノードを生成することを要求し得る。様々な実施形態では、コンピューティング資源は、ユーザーの代わりにプログラム実行の要求時に、および／または、例えば、ユーザーがプログラム実行サービス１００のサービスを利用するために登録および／または申込みを行う時など、一度もしくは複数の他の時に指定され得る。いくつかの実施形態では、対話型要求マネージャ１３０は、一人または複数のユーザーに申込みおよび／または登録サービスを提供し得、ユーザーが、ユーザーの代わりに実行する１つまたは複数のプログラムに関連する情報（例えば、プログラム、ソースコード、１つまたは複数のプログラムのアドレス可能位置など）、アカウント情報（例えば、ユーザー名、課金情報など）、利用期間などを指定し得るようにする。いくつかの実施形態では、ユーザーがサービスの申込みおよび／または登録のために対話型要求マネージャ１３０と対話した後、ユーザーは、そのユーザーに関連し、ユーザーの代わりでのプログラム実行とともに使用される、１つまたは複数の要求識別子（例えば、キー、トークン、ユーザー名、パスワードなど）が発行され得る。他の実施形態では、対話型要求マネージャ１３０以外のモジュールが、プログラム実行サービス１００の申込みおよび／または登録サービスに関連する様々な操作を実行するために提供され得る。

いくつかの実施形態では、対話型要求マネージャ１３０は、１つもしくは複数の物理または仮想コンピューティングシステムによって実行されるか、または具現化される。例えば、いくつかの実施形態では、ＣＰＵ、入出力コンポーネント、記憶装置、およびメモリを含むコンポーネントを有するサーバーコンピューティングシステムが、対話型要求マネージャ１３０を実行するために使用され得る。入出力コンポーネントは、ディスプレイ、ネットワーク１２８へのネットワーク接続、コンピュータ可読媒体ドライブ、および他の入出力装置（例えば、キーボード、マウス、スピーカなど）を含む。対話型要求マネージャ１３０の実施形態は、１つまたは複数の実行可能プログラムモジュールとしてサーバーのメモリに格納でき、対話型要求マネージャ１３０は、ネットワーク１２８を介して、コンピューティングノード１１２（例えば、物理コンピューティングシステム１１６および／またはＶＭ １２０）と対話できる。対話型要求マネージャ１３０は、プログラム実行サービス１００のコンピューティング資源に対するユーザーからの要求を、ネットワーク１０８を介して受信できる。

図２Ａは、ユーザーの代わりにプログラムを実行するための要求を管理するように構成された対話型要求マネージャ１３０の実施形態の例示的なコンポーネントの概略ブロック図である。この実施形態では、対話型要求マネージャは、資源生成モジュール２０４、資源スケジューリングモジュール２０８、モニタリングおよび報告モジュール２１２、ならびに課金モジュール２１６を含む。

資源生成モジュール２０４は、例えば、利用期間中にユーザーのプログラム（または複数のプログラム）実行のために利用可能なコンピューティング資源を管理および確保するために、１つまたは複数のコンピューティングノードを生成する要求など、プログラム実行サービス１００のコンピューティング資源に対するユーザーからの要求を受信する。ユーザーは、プログラム実行コンピューティングノードが直ちに利用可能になることを要求し得るか、プログラム実行コンピューティングノードが将来生成されることを要求し得るか、または、プログラム実行コンピューティングノードが他の基準に基づいて生成されることを要求し得る。プログラム実行コンピューティングノードに対する要求は、資源生成モジュール２０４によって様々な方法で受信され得る。例えば、要求は、直接ユーザーから（例えば、対話型コンソールまたはプログラム実行サービスによって提供される他のＧＵＩを用いて）、それ自身の他のプログラムまたは他のインスタンスの実行を自動的に開始するユーザーの実行プログラムから、プログラミングツール（例えば、コマンド行ツール、統合開発環境（例えば、Ｅｃｌｉｐｓｅ）など）から、プログラム実行サービスによって提供されるアプリケーションプログラミングインタフェース（ＡＰＩ）（例えば、ウェブサービスを利用するＡＰＩ）を通じて対話型要求マネージャと対話するプログラムなどから、受信できる。

コンピューティングノードに対する要求は、コンピューティングノードの数および／またはタイプ、使用するコンピューティングノードの最小および／または最大数、その間そのコンピューティングノードの可用性が保証される利用期間、要求の満了時間などを含み得る。要求は、利用期間中、あるプログラム（または複数のプログラム）のみが、生成されたコンピューティングノード上で実行されることを指定し得る。コンピューティングノードに対する要求は、他のタイプの好み、要件、および／または制約（例えば、記憶容量またはネットワーク帯域幅の量、ノードに対する地理的および／または論理的位置、終了基準など）を含み得る。

いくつかの実施形態では、要求は、ユーザーのプログラム（または複数のプログラム）を含み、資源生成モジュール２０４は、ユーザーのプログラム（または複数のプログラム）がプログラム実行サービス１００によって実行できるように、インフラストラクチャ資源を自動的に提供する。例えば、資源生成モジュール２０４は、ユーザーのプログラムを実行するための１つまたは複数のインフラストラクチャサービスと共に、ユーザーのプログラムのためのアプリケーションソフトウェアスタックを含む実行時環境であり得る、仮想化環境を自動的に構成し得る。仮想化環境は、ユーザー選択可能なオペレーティングシステム（例えば、Ｌｉｎｕｘ、Ｗｉｎｄｏｗｓなど）、アプリケーションサーバー（例えば、Ａｐａｃｈｅ Ｔｏｍｃａｔ）、およびシステムまたはアプリケーション構成など含むことができる。仮想化環境は、特定のＵＲＬでホストされるように構成できる。インフラストラクチャサービスは、要求されたコンピューティング資源にわたって作業負荷（例えば、アプリケーショントラフィック）を分散するための負荷分散装置、負荷または需要の変動に応じてコンピューティング資源をスケーリングするための負荷スケーラ、ユーザーがプログラムの実行をモニタリングできるようにするモニタリングインタフェース、データ記憶資源（例えば、拡張可能なボリュームブロックストレージ）などを含むことができるが、それらに限定されない。いくつかの実施形態では、ユーザーは、仮想化環境内に含めることができる、プログラム実行サービス１００によって提供される１つもしくは複数のプログラムまたはサービスを選択することが可能であり得る。例えば、ユーザーは、複数のデータベースモデル（例えば、リレーショナルデータベース、ＳＱＬデータベース、Ｏｒａｃｌｅデータベースなど）から選択することが可能であり得る。いくつかの実施形態では、インフラストラクチャサービスは、プログラム実行サービス１００の複数のユーザー間で共有されている資源ではなく、むしろ、ユーザーに対してカスタマイズできる。例えば、いくつかのかかる実施形態では、負荷分散装置は、プログラム実行サービス１００のいく人かのユーザー間で共有または分散されているのではなく、ユーザーのアプリケーション用に個別にカスタマイズできる。いくつかの実施形態では、仮想化環境は、ユーザーのアプリケーションが、他のアプリケーションと通信するために、プロセススレッドをスポーン（ｓｐａｗｎ）できるか、または任意の適切なポート（例えば、ポート８０以外のポート）をオープンできるように構成できる。例えば、仮想化環境は、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）ポートをサポートし得る。

対話型要求マネージャ１３０のある実施形態の考えられる利点は、ユーザーがカスタムアプリケーションをプログラム実行サービス１００に単にアップロードし得ると、対話型要求マネージャ１３０が次いで、ユーザーのカスタムアプリケーションをプログラム実行サービス１００上で実行するために使用される資源およびアプリケーションスタックを含む仮想化環境を生成できるということである。ユーザープログラムの実行を可能にするために必要な対話型要求マネージャ１３０とのユーザーの相互作用の量は、比較的わずかな相互作用（例えば、Ｊａｖａ ＷＡＲファイルを使用したプログラムのアップロードにすぎない）から比較的高度な相互作用（例えば、ユーザーが、実質的に仮想化環境の全ての態様をカスタマイズし得る）まで及び得る。その結果、対話型要求マネージャ１３０の実施形態は、仮想化環境に対して比較的高度な柔軟性およびカスタマイズ可能性を提供し得る。いくつかの実施形態では、プログラム実行サービス１００（または他のプロバイダ）は、サービス１００のユーザーによる使用のために、１つまたは複数の標準または既定の仮想化環境を利用可能にする。

プログラム実行能力に対する要求は、その間、コンピューティング資源がそのユーザーに対して利用可能になる利用期間を指定し得る。いくつかの実施態様では、プログラム実行サービス１００は、利用期間中、要求されたコンピューティング資源が利用可能であるという保証をユーザーに対して提供し得る。利用期間は、様々な実施形態において様々な方法で指定され得る。例えば、利用期間は、初期時間から始まって満了時間に終了する、指定された期間（例えば、時間、日、週、月、年などの数）を示し得る。初期時間および／または満了時間は、時刻（例えば、７：００ａ．ｍ．）および日付（例えば、２０１０年１月２３日）を含み得る。初期時間は、例えば、１時間もしくは数時間後、１日もしくは数日後、１週間もしくは数週間後、または１年もしくは数年後など、ある将来の時間にできる。ある場合には、将来の利用期間は、例えば、少なくとも１時間後、１日後、１週間後、１か月後、またはそれ以上など、少なくともある期間だけ、要求（または要求の確認）の時間より後に開始され得る。

対話型要求マネージャ１３０のいくつかの実施態様では、コンピューティングノードに対する要求が対話型要求マネージャ１３０によって受信された時と、要求が許可される時か、または確認がユーザーに提供される時との間に遅延期間が生じ得る。例えば、遅延期間は、対話型要求マネージャ１３０またはプログラム実行サービス１００によって実行される様々な処理操作、管理操作、会計操作などに起因して生じ得る。いくつかのかかる実施態様では、要求された利用期間は、かかる遅延期間を考慮に入れた後（または実質的に後）に生じる期間を指す。例えば、ある実施態様では、遅延期間は、数秒、数分、または数時間であり得る。あるかかる実施態様では、要求された将来の利用期間の初期時間は、かかる遅延期間を超える将来の時間であり得る。対話型要求マネージャ１３０のある他の実施態様における初期時間は、ユーザーの要求が提出されるか、プログラム実行サービス１００によって受信されるか、または許可される時であり得る。

ある場合には、要求は、利用期間がユーザーによって明確に終了されるまで満了しない（例えば、設定された満了時間がない）ことを指定し得る。継続期間は、１時間〜１週間、１週間〜１か月、１か月または数か月、１年以上、または何らかの他の期間の範囲であり得る。いくつかの実施形態では、利用期間は、ユーザーに、コンピュータ資源のスケジューリングにおける高度な柔軟性を提供するために、前述の（または他の）要因の組合せを含み得る。

ある場合には、プログラムサービス１００が、ユーザーの要求を満足するコンピューティングノードを生成した後、ユーザーは、プログラムのまたは１つもしくは複数のコンピューティングノードの設定に対して１つまたは複数の変更を行うことができる。例えば、ユーザーは、１つもしくは複数のコンピューティングノードに関連する記憶装置またはネットワーク帯域幅の量もしくはタイプを変更し得、１つもしくは複数のコンピューティングノードに関連する利用期間または終了基準を変更し得、プログラムの実行を終了し得る。ユーザーは、本明細書で説明するように、１つまたは複数の変更を様々な方法で要求できる。例えば、ユーザーは、ＧＵＩ、コマンド行ツール、統合開発環境（例えば、Ｅｃｌｉｐｓｅ）、ＡＰＩ呼出しなどを通じて、１つまたは複数の変更を要求できる。

コンピューティングノードに対する要求が資源生成モジュール２０４によって受信された後、資源スケジューリングモジュール２０８が、要求を実現するためにコンピューティングノードのスケジューリングおよび割当てを行うことができる。例えば、プログラム実行能力に対する要求を受信した後、資源スケジューリングモジュール２０８は、プログラム実行のために使用する１つまたは複数のコンピューティングノード１１２を決定し得る。いくつかの実施形態では、使用するコンピューティングノード１１２の決定は、たとえ、その要求が将来の可用性に対するものであっても、要求時に実行される。他の実施形態では、コンピューティングノードの決定は、例えば、決定が、その後利用可能になる情報に基づくことができるように、利用期間の開始前など、後まで延期される。

資源スケジューリングモジュール２０８は、要求された利用期間中、ユーザーによる利用のために、コンピューティングノード１１２から１つまたは複数のコンピューティングノードを割り当て得る。いくつかの実施形態では、１つまたは複数の特定のコンピューティングノード１１２（例えば、１つまたは複数の特定の物理コンピューティングノード１１６および／または仮想コンピューティングノード１２０）が、全利用期間にわたって、ユーザー（または認可されたユーザー）による優先利用のために割り当てられる。

他の実施形態では、利用期間中、特定のコンピューティングノードを特定のユーザーに割り当てるよりむしろ、資源スケジューリングモジュール２０８は、コンピューティングノードプールからコンピューティングノードを割り当て得る。コンピューティングノードプールは、ユーザーまたは認可されたユーザーによるプログラム実行に対する要求を満足するのに十分な資源を備えた適切な量のコンピューティングノードを含み得る。いくつかのかかる実施形態では、要求が、１つまたは複数のプログラムを実行するために利用期間中に受信された後、その１つまたは複数のプログラムを実行するのに十分な適切な量のコンピューティングノードがコンピューティングノードプールから選択され得、プログラム実行が選択されたノード上で開始される。選択された量のコンピューティングノードが、要求を実行するためにもはや使用されなくなった後（例えば、要求された実行の終了および／または完了の後）、それらのコンピューティングノードは、利用期間中、そのユーザーまたは他の認可されたユーザーによる使用のために、コンピューティングノードプールに戻され得る。いくつかの実施態様では、コンピューティングノードプールのノードは、ユーザー（または認可されたユーザー）による専用、排他的、または優先的利用のために割り当てられる。いくつかのかかる実施形態では、ユーザー（または認可されたユーザー）によって使用されていないコンピューティングノードプールのノードは、プログラム実行のために他のユーザーに割り当てられ得、そして、かかるノードが要求された能力を実現するためにユーザー（または認可されたユーザー）によって必要とされる場合、他のユーザーのプログラムは終了できる。

利用期間中、ユーザー（または認可されたユーザー）は、割り当てられたコンピューティングノード上で１つまたは複数のプログラムを実行するための要求を、対話型要求マネージャ１３０に提出し得る。プログラム実行に対する要求は、実行するプログラムの実行可能なコピーまたは他のコピー、実行のために以前に登録されたか、または他の方法で提供されたプログラムの指示、および同時に実行するべきプログラムのインスタンス数（例えば、インスタンスの単一の所望の数として、所望のインスタンスの最小および最大数として、などと表される）など、１つまたは複数のプログラム実行の開始において使用される様々な情報を含み得る。要求は、プログラム実行のためのコンピューティングノードの数および／またはタイプ、使用するコンピューティングノードの最小および／または最大数、要求の満了時間、好ましい実行時間および／または実行の期間などを指定し得る。要求は、１つまたは複数のプログラムの実行に対する、他のタイプの好みおよび／または要件を含み得る（例えば、資源割当て、実行の地理的および／または論理的位置、他のプログラムおよび／またはコンピューティングノードに対する実行の近接、タイミングに関する基準、終了基準など）。

資源スケジューリングモジュール２０８は、各プログラムインスタンスの実行用にどの割り当てられたコンピューティングノードを使用するのかを、要求内に指定されたか、またはプログラムおよび／もしくは関連するユーザーに対して他の方法で指定された、任意の好み、制約、および／もしくは要件に基づくことを含めて、様々な方法で決定し得る。例えば、基準が、プログラムインスタンスの実行のために好ましいか、かつ／または必要な資源（例えば、メモリおよび／または記憶装置；ＣＰＵのタイプ、サイクルまたは他の性能測定基準；ネットワーク容量；プラットフォームのタイプなど）に対して決定される場合、プログラムインスタンスの実行に適切なコンピューティングノードの決定は、少なくとも部分的には、コンピューティングノードが、それらの資源基準を満足するために利用可能な十分な資源を有するか否かに基づき得る。

利用期間中、ユーザーまたは認可されたユーザーの代わりに、割り当てられたコンピューティングノード上でプログラムを実行するために資源生成モジュール２０４によって受信された要求は、１つまたは複数の割り当てられたコンピューティングノード上でのプログラム実行の開始という結果になり得る。ある場合には、割り当てられたコンピューティングノードの全てが使用中である（例えば、プログラムを実行している）ように、利用期間中、プログラム実行に対する十分な要求が受信され得る。利用期間中に受信されたプログラム実行に対する追加の要求は、拒絶され得るかまたは、１つもしくは複数のノードが利用可能になるまで、資源スケジューリングモジュール２０８によって保持もしくはキュー登録され得る。

いくつかの実施形態では、資源スケジューリングモジュール２０８は、例えば、利用期間または要求に関連する他の制約の実施、要求を実現するためのコンピューティング資源の解放、要求および／または要求しているユーザーの認可および／または認証などの、要求の実現に関する１つまたは複数の管理操作を実行し得る。例えば、ある場合には、ユーザーからの要求は、利用期間中、あるユーザー（または複数のユーザー）のみが、割り当てられたコンピューティングノードへのアクセスを許可されることを指定し得る。ある場合には、ユーザーからの要求は、利用期間中、１つまたは複数の指定されたプログラムのみが、割り当てられたノード上で実行されることを指定し得る。他の制約には、プログラム実行の継続期間に関する制約、プログラム実行中に被る料金に関する制約などを含むことができる。１つもしくは複数の前述した制約（または他の制約）の組合せがユーザーによって指定され得、割り当てられたコンピューティングノードへのアクセスを許可する前に、対話型要求マネージャ１３０によってチェックされ得る。

いくつかの実施態様では、利用期間が満了した後、資源スケジューリングモジュール２０８は、割り当てられたコンピューティングノード（例えば、専用コンピューティングノードまたはコンピューティングノードプール内のノード）を他の人によって使用するために解放する。いくつかのかかる実施態様では、利用期間の満了時に実行されているプログラムは終了される。他の実施態様では、かかる実行中のプログラムは、終了されず、もっと高い優先度のユーザー要求がそのコンピューティングノードにアクセスするまで、実行を継続することが許可される。

図２Ａに示す実施形態では、モニタリングおよび報告モジュール２１２は、利用期間中、割り当てられたコンピューティングノードの使用をモニタリングおよび追跡し、利用に関する情報および統計値をユーザーに報告する。例えば、モニタリングおよび報告モジュール２１２は、割り当てられたコンピューティングノード上でプログラムを実行するユーザーの利用パターンを追跡し得る。利用パターンには、ノードにアクセスするユーザーの数もしくは識別、プログラム実行の開始／終了時間および継続期間、ならびに／または他のユーザー指定パターンもしくは診断を含むことができる。いくつかのかかる実施形態では、モニタリングおよび報告モジュール２１２は、例えば、いつおよび／またはどれくらいの期間プログラムがコンピューティングノード上で実行されそうであり得るかの指示、ノードに対する実際または予測された需要などを含む、対話型フィードバックをユーザーに提供し得る。いくつかの実施形態では、モニタリングおよび報告モジュール２１２は、利用統計値を詳述または要約する報告を生成でき、その報告を電子メールでユーザーに伝達するか、またはウェブサービスを通じて、その報告、利用統計値、もしくは対話型フィードバックへのアクセスを提供できる。

いくつかのプログラム実行サービス１００は、料金ベースであり得、サービスが、そのユーザーによる１つまたは複数の料金の支払いと引き換えに、ユーザーの代わりに、プログラムを実行するか、またはコンピューティング資源を割り当てる。いくつかの料金ベースのサービスでは、対話型要求マネージャ１３０は、随意に、図２Ａに概略的に示す課金モジュール２１６を含み得る。例えば、いくつかの実施形態では、料金は、ユーザーのプログラムを実行するために割り当てられた処理装置の数、メモリ容量、記憶容量、ネットワーク資源容量などのうちの１つまたは複数に基づくように、ユーザーの代わりに１つまたは複数のプログラムを実行するために割り当てられたプログラム実行能力の量および／またはタイプに基づきユーザーに請求され得る。いくつかの実施形態では、料金は、例えば、ＣＰＵの機能または性能、プラットフォームのタイプ（例えば、３２ビット、６４ビットなど）などに基づくように、プログラムを実行するために使用されるコンピューティング資源の様々な特性などの他の要因に基づき得る。いくつかの実施形態では、料金は、サービスの利用あたりの価格、コンピューティングサービスが利用される単位時間あたりの価格、利用した記憶装置あたりの価格、転送入および／または転送出されるデータあたりの価格など、様々な利用要因に基づき、請求され得る。

料金は、プログラム実行能力に対する要求および／またはプログラム実行に関連する様々な特性（例えば、実行の連続性、耐障害性など）に関連してなど、様々な他の要因に基づき得る。少なくともいくつかの実施形態では、プログラム実行サービスは、複数のユーザーの代わりに、プログラムを実行するためのサービスまたは機能の様々な段階、タイプおよび／またはレベルのうちの１つもしくは複数を提供し得、また、いくつかのかかる実施形態では、様々な料金は、様々な段階、タイプおよび／またはレベルのサービスに関連し得る。課金モジュール２１６は、コンピュータ資源の利用をモニタリングおよび追跡でき、利用に対して当然支払うべき料金を計算できる。

ユーザーは、コンピューティング能力の予約に対して固定料金の支払い（例えば、前払いまたは定期的に請求）を請求され得、また、ある場合には、他の利用料金（例えば、電気、物理ラックスペース、ネットワーク利用など、様々な資源の利用に関連する様々な料金）が請求され得る。一例として、利用期間中にコンピューティング資源の可用性に対する要求を行うユーザーは、要求が行われたか、または要求がプログラム実行サービス１００によって許可された場合に、予約料金が請求され得る。予約料金は、例えば、要求された資源の量、利用期間の開始時間および／または継続期間、その要求を実現するためにサービスが、追加のコンピューティングハードウェアを購入する必要があるか否かなど、に基づき得る。例えば、予約料金は、開始時間がずっと先である場合よりも、開始時間が近い将来であれば、高くなり得る。さらに、ユーザー（または認可されたユーザー）は、利用期間中の資源の利用に対して利用料金を請求され得る。例えば、利用期間中に、割り当てられたコンピューティングノード上でプログラムの実行を要求する認可されたユーザーは、例えば、プログラム実行の継続期間、プログラムを実行するために利用する資源のタイプなどに基づき、利用料金を請求され得る。前述したように、様々なタイプまたは段階の料金取り決めが可能である。例えば、即時利用のためにオンデマンド資源を要求するユーザーは、予約料金を請求され得るのではなく、将来の利用期間の資源に対して予約を行うために予約料金を支払うユーザーに請求されるよりも高い利用料金を請求され得る。

課金モジュール２１６は、利用を追跡し得、適切な料金を計算し得、そして、ユーザーおよび／または認可されたユーザーに請求し得る（または、課金情報を会計モジュールまたはサービスに提供し得る）。ある場合には、ユーザーによる要求は、認可されたユーザーによって負担される利用料金の一部または全部が、認可されたユーザーに対してよりはむしろ、そのユーザーに請求されることを示し得る。いくつかのかかる場合には、課金モジュール２１６は、ユーザーおよび認可されたユーザー間で料金を適切に分割し得る。

対話型要求マネージャ１３０は、図２Ａに示すものとは異なって構成できる。例えば、図示されたモジュールによって提供される様々な機能は、結合、再配置、追加、または削除できる。いくつかの実施形態では、追加のまたは異なるプロセッサまたはモジュールは、図２Ａに示す実施形態例に関して説明した機能の一部または全部を実行し得る。多くの実施態様の変形が可能である。

プログラム実行能力の管理に関して大まかに説明したが、他の実施形態では、対話型要求マネージャ１３０は、複数のユーザーによる使用のために、追加または代替タイプのコンピューティング関連資源を管理し、これらのコンピューティング関連資源の可用性に対して柔軟な保証を提供するように構成できる。これらの資源は、次のうちの１つまたは複数を含み得る：永続的なデータ記憶能力（例えば、ハードディスクドライブなどの、不揮発性メモリ装置上）；一時的なデータ記憶能力（例えば、ＲＡＭなどの揮発性メモリ上）；メッセージのキュー登録および／または受渡し能力；他のタイプの通信能力（例えば、ネットワークソケット、仮想通信回路など）；データベース管理能力；専用帯域幅または他のネットワーク関連資源；非ネットワーク帯域幅；入力装置能力；出力装置能力；ＣＰＵサイクルまたは他の命令実行能力など。

図２Ｂは、ユーザーコンピューティングシステム１０４ａとプログラム実行サービス１００の対話型要求マネージャ１３０との間の相互作用例を概略的に示すネットワーク図である。プログラム実行サービス１００は、コンピューティング資源を複数のユーザーコンピューティングシステム１０４ａ、１０４ｂ、・・・、１０４ｎに提供できる。この実例では、プログラム実行サービス１００は、対話型要求マネージャ１３０とプログラムで対話するために、ユーザーコンピューティングシステム１０４ａ、１０４ｂ、・・・、１０４ｎに対してＡＰＩを提供する。図２Ｂは、要求ＡＰＩを利用して、プログラム実行サービス１００のコンピューティング資源上でのプログラム実行に対する要求を伝達しているユーザーコンピューティングシステム１０４ａを実例として示す。要求ＡＰＩ（１）は、ネットワーク１０８を介して伝達され、（２）が、プログラム実行サービス１００の対話型要求マネージャ１３０によって受信される。要求ＡＰＩは、例えば、ユーザーのプログラム（例えば、実行するプログラムの実行可能なコピーもしくは他のコピー、または実行のために以前に登録されたか、もしくは他の方法で提供されたプログラムの指示など）、コンピューティングノードの数および／またはタイプ、使用するコンピューティングノードの最小および／または最大数、コンピューティングノードの可用性がその間要求される（または利用可能であると保証される）利用期間、要求の満了時間などの、ユーザーの要求に関する情報を含むことができる。要求ＡＰＩは、ユーザーのプログラムまたはコンピューティング資源に対するユーザーの必要性に関連する好み、要件、および／または制約などの、要求に関する他の情報を含むことができる。例えば、要求ＡＰＩは、利用期間中どのユーザーがコンピューティング資源へのアクセスを許可されるか、利用期間中どのプログラム（または複数のプログラム）が実行できるか、記憶容量またはネットワーク帯域幅の量、ノードに対する地理的および／または論理的位置、終了基準などに関する情報を含むことができる。

図２Ｂに示す例では、対話型要求マネージャ１３０は、ネットワーク１０８を経由して確認ＡＰＩ（３）を伝達するが、それは、ユーザーコンピューティングシステム１０４ａによって受信される（４）である。確認ＡＰＩは、プログラム実行サービス１００が、要求を（全部または一部において）要求された利用期間中（または異なる利用期間中）、許可できるか否かに関する情報を含むことができる。確認ＡＰＩは、ユーザーの要求に関連し、利用期間中に、割り当てられたコンピューティング資源へのアクセスとともに使用される、１つまたは複数の要求識別子（例えば、キー、トークン、ユーザー名、パスワードなど）も含み得る。確認ＡＰＩは、ユーザーの好み、要件、および／または制約が満足できることを確認する情報などの、他の情報を含むことができる。

図２Ｂは、ＡＰＩを介して、プログラム実行サービス１００の対話型要求マネージャ１３０とプログラムで対話するユーザーコンピューティングシステム１０４ａを実例として示す。プログラム実行サービス１００は、サービスのコンピューティング資源の可用性に対する要求を、ＡＰＩを介して、他のユーザーコンピューティングシステム（例えば、ユーザーコンピューティングシステム１０４ｂ、・・・、１０４ｎ）から受信でき、ＡＰＩを介して確認を他のユーザーコンピューティングシステムに伝達できる（かかる要求および確認は、図２Ｂに示す実例には図示されていない）。対話型要求マネージャ１３０（または、他の適切なコンポーネント）は、複数のユーザーコンピューティングシステムからの要求をスケジューリングすることができ、様々な要求された利用期間中にコンピューティング資源を割り当てることができる。プログラム実行サービス１００とユーザーコンピューティングシステムとの間の他のタイプのプログラムでの対話が（追加または代替として）可能である。例えば、要求は、直接ユーザーから（例えば、対話型コンソールまたはプログラム実行サービスによって提供される他のＧＵＩを用いて）、それ自身の他のプログラムまたは他のインスタンスの実行を自動的に開始するユーザーのプログラム実行から等、受信できる。

ユーザーコンピューティングシステム１０４ａとプログラム実行サービス１００の対話型要求マネージャ１３０との間の対話の追加的な実例として、ユーザーは、対話型要求マネージャ１３０にユーザープログラム用にアプリケーションコンテナを生成するよう要求し得る。要求ＡＰＩ（１）を利用すると、ユーザーはＪａｖａ ＷＡＲファイル経由などで、プログラムをアップロードすることができる。ユーザーは、ウェブブラウザ、コマンド行ツール、または統合開発環境を用いてプログラムをアップロードすることができる。プログラムは、ユーザーが所望する任意のアプリケーションであり得る。例えば、プログラムは、ウェブアプリケーションであり得る。対話型要求マネージャ１３０は、次いで、プログラム（例えば、要求ＡＰＩ（２））を受信できる。対話型要求マネージャ３０は、次いで、ユーザーのプログラム用にアプリケーションコンテナを自動的に生成することにより、ユーザーの要求を処理し得る。アプリケーションコンテナは、ユーザーのプログラムをスケーラブルで耐障害性にできるようにするため、ユーザーに対する他のサービスを含むことができる。いくつかの実施形態では、対話型要求マネージャ３０は、ユーザーからのさらなる入力なしで、アプリケーションコンテナを（インフラストラクチャサービスを含めて）自動的に生成する。他の実施形態では、ユーザーは、アプリケーションコンテナの生成に対してある程度の制御を（例えば、コンテナ内に含まれるインフラストラクチャサービスを選択および／または構成することにより）行使することを選択できる。ユーザーの代わりに、アプリケーションスタック、自動スケーリング、負荷分散、バージョン管理、ストレージ、および／または他のサービスを生成するアプリケーションコンテナが作成できる。例えば、対話型要求マネージャ１３０は、例えば、ユーザーのプログラムを実行するための負荷分散、モニタリング、および自動スケーリングなどの１つまたは複数のサービスとともに、Ｌｉｎｕｘオペレーティングシステム、Ａｐａｃｈｅ Ｔｏｍｃａｔサーバー、Ｏｒａｃｌｅリレーショナルデータベースのインスタンスを生成し得る。対話型要求マネージャ１３０は、次いで、確認ＡＰＩ（３）および（４）を介して、アプリケーションコンテナの作成をユーザーに確認する。

確認ＡＰＩ（４）の受信後、ユーザーは、プログラムを局所的に変更し得る。例えば、ユーザーは、統合開発環境を利用して、アプリケーションを局所的に更新および／またはテストし得、更新されたプログラムを対話型要求マネージャ１３０に（例えば、後続の要求ＡＰＩ（１）、（２）を介して）再度送信し得る。対話型要求マネージャ１３０は、前述したように、改訂されたプログラム用のアプリケーションコンテナを（さらなるユーザー入力の有無にかかわらず）自動的に生成または更新し得る。アプリケーションコンテナの生成後、ユーザーは、対話型要求マネージャ１３０によって生成されたサービスを変更できる。ユーザーは、ユーザープログラムの実行が開始される前または後に、ウェブページ、対話型コンソールなどを用いて、これらの変更を行うことができる。例えば、ユーザーは、ＬｉｎｕｘオペレーティングシステムよりむしろＷｉｎｄｏｗｓオペレーティングシステムを好み得るか、またはＯｒａｃｌｅデータベースよりむしろＭｉｃｒｏｓｏｆｔ ＳＱＬデータベースを好み得、そして、例えば、ＡＰＩまたは対話型コンソールを用いて、対話型要求マネージャ１３０がこれらの変更を行うことを要求できる。別の例として、ユーザーは、使用するポートなど、Ａｐａｃｈｅ Ｔｏｍｃａｔサーバーインスタンスに対する設定を変更することを所望し得、例えば、ＡＰＩまたは対話型コンソールなどを用いて、その変更を要求し得る。さらに別の例として、ユーザーは、負荷分散をオフにすることを好み得、対話型要求マネージャ１３０に負荷分散を無効にするように要求できる。その結果、ユーザーは、所望する任意の種類の変更を要求することができ、対話型要求マネージャ１３０は、ユーザーの所望する変更を実施しようと試みることができる。ユーザーは、アプリケーションコンテナを任意の他のユーザーと共有することもできる。ユーザーは、いかなる時でも、ユーザーのプログラムを削除して、アプリケーションコンテナのコンピューティング資源の割当てを解除することも要求し得る。

本明細書で説明したように、アプリケーションコンテナは、ユーザーのプログラムに対するモニタリングサービスも含み得る。モニタリングサービスは、アプリケーションコンテナ内のユーザーのプログラムおよび／またはサービスの性能をモニタリングすることができる。例えば、モニタリングサービスは、負荷分散および／または自動スケーリングサービスの性能をモニタリングし得るか、またはサーバーの性能をモニタリングし得る。モニタリングサービスは、性能の報告をユーザーに提供し得る。モニタリングサービスは、ユーザーのプログラムの実行中に何か問題が生じた場合に、是正処置をとることもできる。例えば、モニタリングサービスが、ユーザーのプログラムが応答していない（例えば、１つまたは複数のコンピューティングノードが故障している）ことを検出すると、モニタリングサービスは、１つまたは複数のコンピューティングノードを再起動できるか、かつ／または故障したノードの役目を引き継ぐために追加のコンピューティングノードを要求できる。別の例として、ユーザーのアプリケーションに対する需要が増加して、ユーザープログラムの性能に影響を及ぼすリスクがあるようになると、モニタリングサービスは、ユーザープログラムの代わりに追加のコンピューティング資源を割り当てることができ、かつ／またはユーザーにその割当てを通知できる。ユーザーは、対話型要求マネージャ１３０に対して、どのようにまたはいつ通知するかを指定できる。例えば、ユーザーは、ＡＰＩまたは対話型コンソールを用いて、何かエラーが生じると、対話型要求マネージャ１３０が電子メールメッセージをユーザーに伝達することを指定し得る。別の例として、ユーザーは、対話型要求マネージャ１３０が、任意のエラーについて電子メールメッセージをユーザーに伝達し、何か是正処置をとる前に、ユーザーから承認を受信することを指定し得る。ユーザーは通知設定を任意の所望する方法で構成できる。前述は、ユーザーと対話型要求マネージャ１３０の様々な実施形態との間の対話のタイプの実例として意図しており、制限することを意図するものでない。

図３Ａおよび図３Ｂは、対話型要求マネージャルーチン３００の実施形態例を概略的に示す流れ図である。いくつかの実施態様では、ルーチン３００は、図１および図２に関連して説明したプログラム実行サービス１００の対話型要求マネージャ１３０の実施形態によって提供できる。ルーチン例３００は、例えば、利用期間中にプログラム実行サービスの１つまたは複数のコンピューティングノードを実行するためのプログラムなど、プログラム実行能力に対する要求を行う第１のユーザー（例えば、図３Ａを参照）、および利用期間中にプログラム実行能力に対する変更を要求する第２のユーザー（例えば、図３Ｂを参照）の観点から説明される。以下で説明するように、第１のユーザーおよび第２のユーザーは、異なるユーザーである必要はなく、同じユーザーに言及し得る。ルーチン例３００は、対話型要求マネージャ１３０の様々な態様を示すことを意図するが、それらに限定されない。

図３Ａを参照すると、ブロック３０４で、利用期間中にプログラム実行サービス１００によるプログラム（または複数のプログラム）の実行に対する要求が、対話型要求マネージャ１３０によって第１のユーザーから受信される。前述したように、その要求は、プログラム（または複数）、コンピューティングノードの数および／またはタイプ、使用するコンピューティングノードの最小および／または最大数、その間そのコンピューティングノードの可用性が保証される将来の利用期間、要求の満了時間などを含み得る。要求は、利用期間中、あるユーザー（または複数のユーザー）のみがそのコンピューティングノードへのアクセスを許可されること、または、利用期間中、あるプログラム（または複数のプログラム）のみがそのコンピューティングノード上で実行されることを指定し得る。コンピューティング資源に対する要求は、他のタイプの好み、要件、および／または制約（例えば、メモリまたは記憶容量の量、ネットワーク帯域幅、ノードに対する地理的および／または論理的位置、終了基準など）を含み得る。

ブロック３０８で、対話型要求マネージャ１３０は、要求が実現できるか否かを判断する。例えば、ある場合には、プログラム実行サービス１００が、要求を満足するのに十分な能力を有し得るか、または利用期間が、追加のコンピューティング資源が取得できる（必要な場合）十分に先の将来である。要求が実現できる場合には、ブロック３２０で、要求が実現できるという確認が第１のユーザーに提供される。例えば、電子メールを通じてメッセージが第１のユーザーに伝達され得るか、または、プログラム実行サービスが、ウェブサービスを通じてか、もしくは対話型コンソールかプログラム実行サービスによって提供される他のＧＵＩを通じて、確認を提供し得る。確認は、図２Ｂに関連して説明したように、確認ＡＰＩを介して提供され得る。

要求が、全部または一部において実現できない場合、ルーチン３００は、ブロック３１２に進み、そこでは、対話型要求マネージャが、要求が、要求されたのとは異なるように、全部または一部において実現できるか否かを判断しようと試みる。例えば、ルーチン３００は、要求が異なる利用期間中に実現できること、または、要求が要求された利用期間中に一部（例えば、要求されたよりも少ないノードを用いて）実現できることを判断し得る。ある場合には、ルーチン３００は、ブロック３１２で、１つまたは複数の追加のイベントを条件として、要求された利用期間中に要求が実現できることを判断し得る。例えば、ルーチン３００は、十分な追加のコンピューティング資源がプログラム実行サービスによって取得されることを条件として、かつ、それら追加の資源が、要求された利用期間の開始前に供給およびインストールされることを条件として、要求が実現できることを判断し得る。ブロック３１６で、ルーチン３００は、１つもしくは複数の考えられる変更または要求に関連する付随的な事柄に関する情報を第１のユーザーに提供し、その後、ルーチン３００は終了する。例えば、メッセージが、電子メールを通じて第１のユーザーに伝達され得るか、またはプログラム実行サービスが、ウェブサービスを通じてか、または対話型コンソールもしくはプログラム実行サービスによって提供される他のＧＵＩを通じて、情報を提供し得る。情報は、ＡＰＩを介して提供され得る（例えば、図２Ｂを参照）。第１のユーザーは、考えられる変更または要求に関連する付随的な事柄に関する情報を使用でき、次いで、必要なら、新しい要求を提出できる。

例示した実施形態では、要求が実現できる場合、ルーチン３００はブロック３２４に進み、そこでは、対話型要求マネージャが、ユーザーのプログラムおよびプログラム実行サービス上でそのプログラムを実行するための適切なインフラストラクチャを含む仮想化環境（例えば、アプリケーションコンテナ）を生成する。対話型要求マネージャは、仮想化環境を実行できるコンピューティングノードのグループを決定する。いくつかの実施態様では、ユーザーは、プログラム実行のために使用されるコンピューティングノードに対して、特定の数、地理的分散などを要求し得る。コンピューティングノードのグループ内のコンピューティングノードの数（および／または地理的分散）は、ユーザーによって要求されたコンピューティングノードの数と異なり得るが、その必要はない。例えば、グループ内のコンピューティングノードの数は、万一、利用期間中に実際に要求されたコンピューティングノードの数がグループ内のコンピューティングノードの数よりも多い場合には、プログラム実行サービスが十分な余分のコンピューティング容量を有するので、要求された数よりも少ない可能性がある。他の場合には、グループ内のコンピューティングノードの数は、利用期間中に予測される需要を安全に満足するために十分なコンピューティングノードがあることを確実にしようとする（例えは、グループ内の１つまたは複数のコンピューティングノードの故障に備えて、予備のノードを提供する）ために、要求された数よりも多い可能性がある。様々な実施形態では、ユーザーは、仮想化環境またはノードのグループに関連する設定（例えば、記憶容量またはネットワーク帯域幅の量またはタイプ、ノードに対する地理的および／または論理的位置、終了基準など）に対して１つまたは複数の変更を行うことができる。ルーチン３００は、１つまたは複数の変更が実現できるか、または満足できることを検証できる。ブロック３２８で、コンピューティングノードのグループが、利用期間中、第１のユーザーが利用するために割り当てられる。資源スケジューリングモジュール２０８に関して前述したように、コンピューティングノードの割り当てられたグループは、特定のコンピューティングノードまたはコンピューティングノードプールから選択されたノードを含み得る。

図３Ｂを参照すると、利用期間中、第２のユーザーが、第１のユーザーに対して割り当てられているコンピューティングノード上での第１のユーザーのプログラム（または複数のプログラム）の実行に関連する１つまたは複数の変更を行い得る。前述したように、第２のユーザーは、第１のユーザーと異なり得るが、その必要はない。一シナリオ例では、第１のユーザーがプログラムの実行を要求している可能性がある。利用期間中、第１のユーザーは、コンピューティングノード上で実行しているプログラムのための設定に対する１つまたは複数の変更を提出し得る。このシナリオ例では、第２のユーザーは、第１のユーザーと同じであり得る。いくつかのかかるシナリオでは、第１のユーザーによる要求は、第１のユーザーのみが（他のユーザーではなく）、プログラム実行または割り当てられたコンピューティングノードに対する変更を行うことができることを示し得る。

他のシナリオ例では、第２のユーザーは、第１のユーザーとは異なるユーザーであり得る。例えば、第１のユーザーによる要求は、利用期間中、特定の第２のユーザー（または複数の第２のユーザー）が、コンピューティングノード上で実行しているプログラムに関する変更を行うことを許可されることを示し得る。このシナリオ例では、第２のユーザー（または複数の第２のユーザー）は、第１のユーザーとは異なるユーザーにできる。例えば、第１のユーザーは、最初にアップロードし、プログラム実行能力を要求したアプリケーション開発者であり得、第２のユーザーは、プログラムの進行中の実行をモニタリングするネットワーク管理者またはアプリケーション開発管理者であり得る。

別のシナリオ例では、第１のユーザーによる要求は、プログラム実行サービス１００の任意のユーザーが、かかる（第２の）ユーザーが適切な識別子情報を提出する限り、利用期間中にプログラム実行に対する変更を行うことができることを示し得る。かかるシナリオでは、第１のユーザーは、識別子（例えば、キー、トークン、パスワードなど）を様々な第２のユーザーに伝達し得る。これら第２のユーザーの誰かは、次いで、利用期間中に変更を行うための要求を行う際に、そのプログラム識別子を使用するであろう。いくつかのかかるシナリオでは、ユーザーが、割り当てられたコンピューティングノード上で実行しているプログラムに対する変更を要求したが、プログラム識別子を持っていなかった（または要求とともに提出しなかった）場合、対話型要求マネージャはその要求を拒絶するであろう。

ブロック３３６で、対話型要求マネージャは、第２のユーザーが、コンピューティングノード上でのプログラム実行に対して提供された仮想化環境に対する１つまたは複数の変更を要求できるようにするために、インタフェースを第２のユーザーに提供できる。前述したように、インタフェースは、様々な方法で提供できる。例えば、インタフェースは、対話型コンソールまたは他のＧＵＩ、コマンド行ツール、ウェブページ、および統合開発環境などを通じて提供できる。ブロック３４０で、第２のユーザーからの変更に対する要求が、対話型要求マネージャによって受信される。例えば、要求は、プログラムのインスタンスの実行を終了すること、プログラムを実行するための１つまたは複数の新しいインスタンスを開始すること、１つまたは複数のインスタンスの実行時設定を変更することなどであり得る。前述したように、要求は、例えば、資源割当てのタイプまたは量、実行のための地理的および／または論理的位置、タイミングに関する基準、終了基準など、割り当てられたコンピューティングノードに対して変更を行うことであり得る。

ブロック３４４で、対話型要求マネージャは、第２のユーザーからの変更要求が許可または実現できるか否かを判断する。例えば、第１のユーザーの要求は、コンピューティングノードに対して行われる可能性のある変更に加えられる１つもしくは複数の要件または制約を指定している可能性があり、第２のユーザーの要求がその要件または制約の一部もしくは全部を満足しない場合、第２のユーザーの要求は拒絶され得る。他の場合には、コンピューティングノードに対する変更が追加の資源または計算ノードを必要とし得、そのため、第２のユーザーの要求は、第２のユーザーの要求時に実現できない。かかる状況では、様々な実施形態において、対話型要求マネージャは、第２のユーザーの要求を拒絶し得るか、または、第２のユーザーによる使用のために十分なコンピューティングノードが生成できるまで、第２のユーザーの要求が保持もしくはキュー登録され得る。いくつかの実施態様では、対話型要求マネージャは、要求が実現できる予定時刻、要求が直ちに実現できるように要求をどのように変更できるかなどに関する情報を、第２のユーザーに提供し得る。

ブロック３４８で、第２のユーザーからのプログラム実行要求が実現できる場合、プログラム実行サービスは、第１のユーザーのプログラムまたは複数のプログラムを実行している可能性のあるコンピューティングノードまたは複数のノードに対する１つまたは複数の変更を実装する。

図３Ａを参照すると、ルーチン３００は、ブロック３５２に進み、そこでは、対話型要求マネージャが、プログラム実行のために割り当てられたノードのグループ上でのプログラム実行の利用をモニタリングおよび追跡する。モニタリングおよび報告モジュール２１２に関して説明したように、対話型要求マネージャは、割り当てられたコンピューティングノード上でプログラムを実行するユーザー（例えば、第１のユーザー）の利用パターンをモニタリングする。利用パターンは、割り当てられたノードに対して変更を行うユーザーの数または識別、プログラム実行の開始／終了時間および継続期間、ならびに／または他のユーザー固有のパターンもしくは診断を含むことができる。いくつかの実施形態では、ブロック３５２で、例えば、いつおよび／またはどれくらいの期間、割り当てられたコンピューティングノード上でプログラムが実行されそうであり得るかの指示、ノードに対する実際または予測された需要などを含む、対話型フィードバックが、第１のユーザーまたは第２のユーザーに提供され得る。いくつかの実施形態では、利用統計値を詳述または要約する報告が生成でき、電子メールを通じてか、または対話型コンソールもしくはプログラム実行サービスによって提供される他のＧＵＩを通じて、第１のユーザーに提供できる。

プログラム実行サービスが料金ベースである実施形態では、ブロック３５６で、対話型要求マネージャ（または他の会計もしくは課金マネージャ）が、１つまたは複数の料金を計算できる。例えば、第１のユーザーは、コンピューティング能力の要求に対して予約料金が請求され得、第１のユーザーまたは第２のユーザーは、利用期間中、割り当てられたノード上でのプログラム実行に対して利用料金が請求され得る。

ブロック３６０で、随意に、他のサービスが、ルーチン３００の実施形態によって実行できる。例えば、利用期間の満了後に他のユーザーによる使用のためにコンピューティングノードを解放することを含む、様々なハウスキーピング操作が実行され得る。ルーチン３００は、その後、ブロック３６４に進んで終了する。

図３Ｃは、対話型要求マネージャの実施形態が、それによって、コンピューティング資源に対する要求を確認するためにユーザーコンピューティングシステムと通信できる、ルーチン３７０の一例を概略的に示す流れ図である。いくつかの実施態様では、ルーチン３７０は、図１および図２に関して説明したプログラム実行サービス１００の対話型要求マネージャ１３０の実施形態によって実装できる。図３Ａのブロック３０４および３０８に関して説明したように、対話型要求マネージャは、第１のユーザーから利用期間中のプログラム実行能力に対する要求を受信でき、プログラム実行能力に対する要求が実現できるか否かを判断できる。

図３Ｃのブロック３７４に進み、要求が実現できる場合には、対話型要求マネージャは、確認を第１のユーザーに提供する。例えば、図２Ｂおよび図３Ａのブロック３２０に関して説明したように、確認は、プログラム実行サービスが、要求を（全部または一部において）要求された利用期間中（または異なる利用期間中）、許可できるか否かに関する情報を含むことができる。確認は、第１のユーザーの要求に関連し、利用期間中に、コンピューティング資源に対して変更を行うにあたって使用される、１つまたは複数の要求識別子（例えば、キー、トークン、ユーザー名、パスワードなど）も含み得る。確認は、ユーザーの好み、要件、および／または制約が満足できることを確認する情報などの、他の情報を含むことができる。いくつかの実施態様では、確認は、確認ＡＰＩを介して伝達できる（例えば、図２Ｂを参照）。

ある場合には、第１のユーザーのプログラム実行要件は、要求が確認された時（ブロック３７４で）と利用期間の開始との間で変わり得る。いくつかのかかる場合には、第１のユーザーは、要求の変更を対話型要求マネージャに提出し得る。例えば、変更された要求は、実行する変更されたプログラムに関する情報、コンピューティングノードの変更された数またはコンピューティングノードに関連する設定、利用期間の変更された開始時間、終了時間、および／もしくは継続時間、または第１のユーザーの他の好みもしくは要件における変更を含み得る。変更された要求は、全部または一部において、最初の要求を取り消し得る。その結果、かかる場合には、ブロック３７８で、対話型要求マネージャは、変更された要求を第１のユーザーから受信し得、その変更された要求が（全部または一部において）実現できるか否かを判断し得る。

ブロック３８２で、対話型要求マネージャは、更新された確認を第１のユーザーに提供し、それは、プログラム実行サービスが、変更された要求を（全部または一部において）要求された利用期間中（変更された要求内で変更されている可能性がある）、許可できるか否か、またはプログラム実行サービスが、変更された要求を（全部または一部において）異なる利用期間中に、許可できるか否かに関する情報を含むことができる。更新された確認は、第１のユーザーの変更された要求に関連し、（おそらくは更新された）将来の利用期間中に、コンピューティング資源に対して１つまたは複数の変更を行うにあたって使用される、１つまたは複数の更新された要求識別子（例えば、キー、トークン、ユーザー名、パスワードなど）も含み得る。更新された確認は、例えば、ユーザーの（おそらくは更新された）好み、要件、および／または制約が満足できることを確認する情報などの、他の情報を含むことができる。いくつかの実施態様では、更新された確認は、確認ＡＰＩを介して第１のユーザーに伝達される（例えば、図２Ｂを参照）。

ブロック３８６で、対話型要求マネージャは、利用期間中に、第１のユーザーに割り当てられたコンピューティング能力に対する１つまたは複数の変更を行うための要求を、第２のユーザーから受信できる。対話型要求マネージャは、通常、図３Ｂに関して説明したように、第２のユーザーからの要求を処理し得る。例えば、いくつかの実施態様では、第２のユーザーから受信された要求は、ブロック３７４で（および／または、変更された要求が第１のユーザーから受信された場合は、ブロック３８２で）、第１のユーザーに伝達された、割り当てられたコンピューティング能力に対する要求識別子を含み得る。

図４は、対話型要求マネージャの実施形態が、それによって、ユーザーによる選択のために複数の仮想化環境（例えば、アプリケーションコンテナ）を提供するために、ユーザーコンピューティングシステムと通信できる、ルーチン４００の一例を概略的に示す流れ図である。いくつかの実施態様では、ルーチン４００は、図１および図２に関して説明したプログラム実行サービス１００の対話型要求マネージャ１３０の実施態様によって実装できる。図３Ｂのブロック３４０に関して説明したように、対話型要求マネージャは、ユーザーに対して生成された仮想化環境に関連する少なくとも１つの変更を受信するように構成できる。

図４のブロック４０４に進み、対話型要求マネージャが、第１のユーザーから仮想化環境を共有する要求を受信する。例えば、対話型要求マネージャが第１のユーザーに対して仮想化環境を生成した後、第１のユーザーは仮想化環境を他のユーザーと共有することを決定し得る。仮想化環境の共有を可能にするため、第１のユーザーは、仮想化環境を共有するための要求を対話型要求マネージャに伝達し得る。要求は、どの仮想化環境が共有されるかを指定し得る。いくつかの実施形態では、要求は、要求ＡＰＩを介して伝達される（例えば、図２Ｂを参照）。

ルーチン例４００のブロック４０８で、対話型要求マネージャが、仮想化環境の更新されたリストを作成するために、その仮想化環境を仮想化環境のリストに追加する。更新されたリストは、プログラム実行サービスの他のユーザーに提供され得る仮想化環境のリストを含み得る。場合によっては、更新されたリストは、第１のユーザーによってだけでなく、プログラム実行サービスによって、および／またはプログラム実行サービスの他のユーザーによって提供される仮想化環境を含み得る。いくつかの仮想化環境は、ユーザーに無料で提供され得、他の環境は有料で利用可能にされ得る。更新されたリストは、例えば、仮想化環境の説明、仮想化環境を生成したユーザーの名前、仮想化環境の利用料金、仮想化環境での使用に適したアプリケーションのタイプに関する推奨、同様のまたは関連する仮想化環境へのリンク、仮想化環境の性能に関する統計値、仮想化環境の属性に対する設定などを含み得る。いくつかの実施態様では、対話型要求マネージャが更新されたリストを作成した後、確認ＡＰＩを介して、確認が第１のユーザーに伝達される（例えば、図２Ｂを参照）。

ブロック４１２で、対話型要求マネージャは、アプリケーションコンテナの更新されたリストをプログラム実行サービスの第２のユーザーに提供し得る。第２のユーザーは、第１のユーザーと同じか、または異なり得る。いくつかの実施態様では、対話型要求マネージャは、ウェブインタフェース、ＧＵＩ、ＡＰＩ呼出しなどを通じて、更新されたリストを第２のユーザーに提供する。例えば、第２のユーザーは、利用期間中に、対話型要求マネージャがプログラムを実行することを要求し得る（例えば、図３を参照）。要求プロセス中、対話型要求マネージャは、第２のユーザーが、どの仮想化環境を第２のユーザーのアプリケーション実行のために使用すべきかを要求できるように、仮想化環境の更新されたリストを提供し得る。いくつかの実施態様では、第２のユーザーは、第２のユーザーのアプリケーション実行に対して、１つもしくは複数の好みまたは要件を提供し得、対話型要求マネージャは、第２のユーザーの好みまたは要件の一部もしくは全部を満足する１つもしくは複数の仮想化環境を推奨し得る。例えば、第２のユーザーは、第２のユーザーのアプリケーションに対する予期される需要、ユーザーの顧客の地理的位置、所望のプログラム実行能力（例えば、ＣＰＵ、メモリ、記憶装置、帯域幅など）などを示し得る。対話型要求マネージャは、第２のユーザーの好みの一部または全部に合致する１つまたは複数の仮想化環境を識別し得、この推奨を第２のユーザーに提供し得る。ある場合には、対話型要求マネージャは、推奨された仮想化環境を、第２のユーザーの好みまたは要件を満足する可能性の観点から、ランク付けまたはソートし得る。

ルーチン例４００のブロック４１２で、対話型要求マネージャは、第２のユーザーから、更新されたリストに含まれている少なくとも１つの仮想化環境の選択を受信し得る。いくつかの実施態様では、第２のユーザーは、選択の前または後に、１つまたは複数の仮想化環境に対して少なくとも１つの変更を行い得る。例えば、第２のユーザーは、第２のユーザーの選択に関する情報を対話型要求マネージャに提供する前に、特定の仮想化環境の１つまたは複数の設定を変更し得る。対話型要求マネージャは、次いで、選択された仮想化環境を使用して、第２のユーザーのアプリケーションのインスタンスを実行し得る（例えば、図３Ａを参照）。

いくつかの実施形態では、第２のユーザーが少なくとも１つの仮想化環境を選択した後、選択された仮想化環境を提供した第１のユーザーに料金が提供され得る。例えば、第２のユーザーは、前述したように、少なくとも１つの選択された仮想化環境を利用したユーザーのアプリケーション実行に対して、１つまたは複数の料金（例えば、予約料金、利用料金など）が請求され得る。１つまたは複数の料金の一部は、第１のユーザーに提供され得る。例えば、提供された料金は、固定料金または第２のユーザーに請求される料金の一部もしくは全部の一定の割合であり得る。提供された料金は、第２のユーザーが少なくとも１つの選択された仮想化環境に対して行っている変更の数、特定の仮想化環境を選択しているユーザーの数、特定の仮想化環境が存在しているか、または使用されている継続期間などに基づく、段階的料金（ｔｉｅｒｅｄ ｆｅｅ）でもあり得る。

ルーチン例４００のいくつかの実施態様では、第２のユーザーは、選択された仮想化環境に変更を行うことを選択し得る。例えば、第１のユーザーは、例えば、Ｊａｖａに基づく仮想化環境を提供している可能性があり、第２のユーザーは、それが別のプログラム言語（例えば、Ｒｕｂｙ）に基づくように、環境を変更し得る。第２のユーザーは、第２のユーザーによって行われた変更を含む変更された仮想化環境を、プログラム実行サービスの他のユーザーと共有することを選択し得る。第２のユーザーは、対話型要求マネージャが、この仮想化環境を他のユーザーと共有し（例えば、ブロック４０４を参照）、（随意に、）その利用に対する料金が提供されることを要求し得る。例えば、第３のユーザーは、第１のユーザーの仮想化環境、第１のユーザーの仮想化環境の第２のユーザーの変更バージョン、ならびに／またはプログラム実行サービスおよび／もしくは他のユーザーによって提供された仮想化環境を選択し得る。その結果、多岐にわたる仮想化環境（無料および／または料金ベース）を含む市場が発達し得、プログラム実行サービスのユーザーに対して利用可能になり得る。

いくつかの実施形態では、ユーザーのためにプログラムの実行を管理するように構成されたコンピューティングシステムが提供できる。システムは、プログラム実行サービスのユーザーのためにプログラムの実行を管理するように構成されている対話型要求マネージャコンポーネントを含み得る。対話型要求マネージャコンポーネントは、プログラム実行サービスのユーザーから、利用期間中にユーザーアプリケーションの実行のために仮想化環境を生成する要求を受信するように構成され得、要求は、プログラム実行サービスが、ユーザーアプリケーションに少なくとも一部基づいてプログラムを実行できるようにするユーザーアプリケーションに関連する情報、プログラム実行サービスの複数のユーザーのプログラムを実行し、仮想化環境を生成するように構成可能な複数のコンピューティングノードを提供するプログラム実行サービス、以下を含む１つまたは複数のプログラムサービス：（１）仮想化環境のコンピューティング資源にわたって作業負荷を分散するように構成された負荷分散装置、（２）ユーザーがプログラムの実行をモニタリングできるよう構成されたモニタリングインタフェース、（３）プログラムの実行に対する需要における変動に応じてコンピューティング資源をスケーリングするように構成された負荷スケーラ、および（４）複数のデータベース管理サービス、を含む仮想化環境を含む。対話型要求マネージャコンポーネントは、仮想化環境の１つまたは複数のインスタンスを１つまたは複数のコンピューティングノードのグループ上で実行し、仮想化環境の１つまたは複数のインスタンスの実行中に、仮想化環境に対するか、または１つもしくは複数のコンピューティングノードのグループ上で仮想化環境を実行している１つもしくは複数のインスタンスに対する少なくとも１つの変更を決定するようにさらに構成され得る。対話型要求マネージャコンポーネントは、仮想化環境の１つまたは複数のインスタンスの実行中に、少なくとも１つの変更を実装するようにさらに構成され得る。

いくつかの実施態様では、ユーザーのためにプログラムの実行を管理するように構成されたコンピューティングシステムが提供できる。システムは、プログラム実行サービスのユーザーのためにプログラムの実行を管理するように構成されている対話型要求マネージャコンポーネントを含み得る。対話型要求マネージャコンポーネントは、第１のユーザーから、第１のユーザーのために生成された第１の仮想化環境を、プログラム実行サービスのユーザーと共有する要求を受信し、第１の仮想化環境に関連する情報を含む仮想化環境の更新されたリストを提供するために、プログラム実行サービスのユーザーによる選択のために利用可能な仮想化環境のリストを更新し、そして、仮想化環境の更新されたリストをプログラム実行サービスのユーザーに提供するように構成され得る。対話型要求マネージャコンポーネントは、更新されたリストに含まれている第１の仮想化環境の選択をプログラム実行サービスの第２のユーザーから受信し、第２のユーザーのために第２の仮想化環境を生成するようにさらに構成され得、第２の仮想化環境は、第１の仮想化環境に少なくとも一部基づく。

前節で説明したプロセス、方法、およびアルゴリズムの各々は、１つまたは複数のコンピュータまたはコンピュータプロセッサによって実行されるコードモジュールで具体化され、かつ一部または全部が自動化され得る。コードモジュールは、ハードドライブ、ソリッドステートメモリ、光ディスク、および／または同様のものなどの、任意のタイプの持続的コンピュータ可読媒体またはコンピュータ記憶装置に格納され得る。システムおよびモジュールはまた、生成されたデータ信号として（例えば、搬送波または他のアナログもしくはデジタル伝搬信号の一部として）、無線ベースおよび有線／ケーブルベースの媒体を含む、様々なコンピュータ可読伝達媒体上に伝送され得、様々な形式を（例えば、単一もしくは多重化アナログ信号の一部として、または複数の離散デジタルパケットもしくはフレームとして）とり得る。プロセスおよびアルゴリズムは、アプリケーション固有回路内に部分的にまたは完全に実装され得る。開示されたプロセスおよびプロセスステップの結果は、例えば、揮発性または不揮発性の記憶装置など、任意のタイプの持続的コンピュータ記憶装置内に、永続的にまたは他の方法で格納され得る。

前述した様々な特徴およびプロセスは、互いに無関係に使用され得るか、または様々な方法で結合され得る。全ての可能な組合せおよび部分的組合せが、本開示の範囲内に含まれることを意図する。さらに、ある方法およびプロセスブロックがいくつかの実施態様では省略され得る。本明細書に記載する方法およびプロセスは、いかなる特定の順序にも限定されず、それらに関連するブロックまたは状態（ｓｔａｔｅ）は、適切な他の順序で実行できる。例えば、説明したブロックまたは状態は、具体的に開示した以外の順序で実行され得るか、または複数のブロックまたは状態が単一のブロックまたは状態に結合され得る。ブロックまたは状態の例は、連続して、並行して、または何らかの他の方法で実行され得る。ブロックまたは状態は、開示した実施形態例に追加され得るまたは、それから除去され得る。本明細書に記載するシステムおよびコンポーネントの例は、説明したのとは異なる方法で構成され得る。例えば、開示した実施形態例に要素が追加され得るか、それから要素が除去され得るか、またはそれに比較して再配置され得る。

本明細書で使用される条件付きの言語、例えば、とりわけ、「できる（ｃａｎ）」、「あり得る（ｃｏｕｌｄ）」、「かもしれない（ｍｉｇｈｔ）」、「し得る（ｍａｙ）」、「例えば（ｅ．ｇ．）」および同様のものは、特に明確に指定のない限り、または、使用されたコンテキストで違うように理解されない限り、一般に、ある特徴、要素および／またはステップを、ある実施形態では含むが、他の実施形態では含まないことを伝えることを意図する。従って、かかる条件付きの言語は、一般に、著者の入力または指示の有無にかかわらず、これらの特徴、要素および／もしくはステップが、任意の特定の実施形態に含まれているか、または任意の特定の実施形態で実行されるかにかかわらず、特徴、要素および／もしくはステップが、多少なりとも、１つもしくは複数の実施形態で必要であること、または１つもしくは複数の実施形態が決定のための論理を必ず含むことを意味することを意図しない。「含む（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、「有する（ｈａｖｉｎｇ）」および同様のものは同義語であり、包括的に、制約のない方法で使用され、追加の要素、特徴、動作、操作などを除外しない。また、「または（ｏｒ）」という用語は、例えば、要素のリストを接続するために使用される場合、用語「または」が、そのリスト内の１つ、いくつか、または全部を意味するように、その包括的な意味で（およびその排他的な意味ではなく）使用される。

ある実施形態例について説明してきたが、これらの実施形態は、例としてのみ提示されており、本明細書で開示した発明の範囲を制限することを意図していない。従って、前述の説明のいずれも、任意の特定の特徴、特性、ステップ、モジュールまたはブロックが必要または不可欠であることを意味することを意図していない。実際、本明細書に記載する新規の方法およびシステムは、様々な他の形式で具体化され得、さらに、本明細書に記載する方法ならびにシステムの形式における様々な省略、置換および変更が、本明細書で開示した発明の精神から逸脱することなく行われ得る。添付の特許請求の範囲およびそれらの相当物は、かかる形式または変更を、本明細書で開示したいくつかの発明の範囲および精神に含まれるように、カバーすることを意図する。

Claims (15)

1. プログラム実行サービスによって提供されるコンピューティング能力に対する要求を動的に管理するためのコンピュータ実装方法であって、
   各々が前記プログラム実行サービスの複数のユーザーの１つ以上のプログラムを実行するように構成可能な複数のコンピューティングノードを提供するプログラム実行サービスの制御下で、
   前記方法は、前記プログラム実行サービスのユーザーから、要求された期間中にユーザーアプリケーションの実行のための仮想化環境を生成する要求を受信するステップを含み、前記要求は、前記プログラム実行サービスが前記ユーザーアプリケーションに少なくとも部分的に基づいてプログラムを実行可能にする前記ユーザーアプリケーションに関連する情報を含み、
   前記方法は、前記仮想化環境を生成する前記要求が実現できるか否かを判断するステップを含み、
   前記要求が実現できないという判断に応答して、前記方法は、
   前記要求が、要求されたのとは異なるように、少なくとも一部において実現できるか否かを判断するステップと、
   １つもしくは複数の考えられる変更または前記要求に関連する付随的な事柄に関する情報を前記ユーザーに提供するステップと、
   を含み、
   前記方法は、前記仮想化環境を自動的に生成するステップを含み、前記仮想化環境は、ユーザー選択可能なオペレーティングシステムおよび前記プログラム実行サービスによって提供される１つ以上のプログラムサービスを含み、前記プログラムサービスは、（１）前記複数のコンピューティングノードのうちの１つ以上にわたって、または、前記仮想化環境の１つ以上のインスタンスにわたって、作業負荷を分散するように構成された負荷分散装置と、（２）前記ユーザーが前記プログラムの実行をモニタリングできるように構成されたモニタリングインタフェースと、（３）前記プログラムの実行に対する需要における変動に応じて前記プログラム実行サービスのコンピューティング資源をスケーリングするように構成された負荷スケーラと、（４）複数のデータベース管理サービスと、を含み、
   前記方法は、
   前記プログラム実行サービスの前記複数のコンピューティングノードから、前記ユーザーによる前記要求を満足できるコンピューティングノードのグループを決定するステップと、
   前記要求された期間中、前記仮想化環境の１つ以上のインスタンスをコンピューティングノードの前記グループ上で実行するステップと、
   前記ユーザーから、前記要求された期間中に、前記仮想化環境に対して、または、コンピューティングノードの前記グループ上で前記仮想化環境を実行する前記１つ以上のインスタンスに対して、少なくとも１つの変更を行う要求を受信するステップと、
   前記要求された期間中に、前記少なくとも１つの変更を自動的に実装するステップと、
   を含む方法。
2. 前記ユーザーに、前記仮想化環境の生成を要求するため、または、前記仮想化環境に対する変更を要求するためのコンピューティングインタフェースを提供するステップをさらに含む、
   請求項１に記載の方法。
3. 前記仮想化環境を生成する前記要求が、（１）オペレーティングシステムと、（２）アプリケーションサーバーと、（３）所望のプログラム実行能力または地理的分散を有する１つ以上のコンピューティングノードと、（４）前記複数のデータベース管理サービスのうちの少なくとも１つと、のうちの１つ以上を、前記プログラム実行サービスによって使用するための要求をさらに含む、
   請求項１または２に記載の方法。
4. 前記１つ以上のインスタンスのうちの少なくとも１つの障害を自動的に識別するステップと、
   コンピューティングノードの前記グループ上で前記仮想化環境を実行するための少なくとも１つの新しいインスタンスを自動的に開始するステップと、
   をさらに含む請求項１〜３のいずれかに記載の方法。
5. コンピューティングノードの前記グループのうちの少なくとも１つの障害を自動的に識別するステップと、
   前記プログラム実行サービスの前記複数のコンピューティングノードから少なくとも１つの新しいコンピューティングノードを自動的に割り当てるステップと、
   前記仮想化環境の少なくとも１つの新しいインスタンスを前記少なくとも１つの新しいコンピューティングノード上で自動的に実行するステップと、
   をさらに含む請求項１〜４のいずれかに記載の方法。
6. コンピューティングサービスのコンピューティング能力に対する要求を動的に管理するように構成されたシステムであって、
   前記システムは、コンピューティングサービスのコンピューティング能力に対する要求を動的に管理するための１つ以上のプログラムモジュールを格納するように構成されたコンピュータメモリを含み、前記コンピューティングサービスが複数のコンピューティングノードを含み、
   前記システムは、前記コンピュータメモリと通信し、かつ、前記コンピュータメモリに格納された前記１つ以上のプログラムモジュールを実行するように構成された対話型要求マネージャを含み、
   前記プログラムモジュールは、ユーザーから、利用期間中、ユーザーアプリケーション実行のための仮想化環境を生成する要求を受信するように構成され、前記要求は、前記コンピューティングサービスが前記ユーザーアプリケーションに少なくとも部分的に基づいてプログラムを実行可能にする前記ユーザーアプリケーションに関連する情報を含み、
   前記プログラムモジュールは、前記仮想化環境を生成する前記要求が実現できるか否かを判断するように構成されており、
   前記要求が実現できないという判断に応答して、前記プログラムモジュールは、
   前記要求が、要求されたのとは異なるように、少なくとも一部において実現できるか否かを判断し、
   １つもしくは複数の考えられる変更または前記要求に関連する付随的な事柄に関する情報を前記ユーザーに提供する、
   ように構成されており、
   前記プログラムモジュールは、ユーザー選択可能なオペレーティングシステムおよび１つ以上のプログラムサービスを含む前記仮想化環境を生成するように構成され、前記１つ以上のプログラムサービスは、（１）前記複数のコンピューティングノードのうちの１つ以上にわたって、または、前記仮想化環境の１つ以上のインスタンスにわたって、作業負荷を分散するように構成された負荷分散装置と、（２）前記ユーザーが前記プログラムの実行をモニタリングできるように構成されたモニタリングインタフェースと、（３）前記プログラムの実行に対する需要における変動に応じてコンピューティング資源をスケーリングするように構成された負荷スケーラと、（４）複数のデータベース管理サービスと、を含み、
   前記プログラムモジュールは、
   前記利用期間中に、前記仮想化環境の１つ以上のインスタンスを前記複数のコンピューティングノードのうちの１つ以上から成るグループ上で実行し、
   ユーザーから、前記利用期間中に、前記仮想化環境に対して、または、前記複数のコンピューティングノードのうちの１つ以上から成る前記グループ上で前記仮想化環境を実行している前記１つ以上のインスタンスに対して、少なくとも１つの変更を行う要求を受信し、
   前記利用期間中に、前記少なくとも１つの変更を実装するように構成されている、
   システム。
7. 前記コンピューティングサービスの前記複数のコンピューティングノードが、１つ以上の物理コンピューティングシステムを含む、
   請求項６に記載のシステム。
8. 前記複数のコンピューティングノードが、前記１つ以上の物理コンピューティングシステム上でホストされた１つ以上の仮想マシンを含む、
   請求項７に記載のシステム。
9. 前記利用期間が、前記１つ以上のインスタンスの前記実行が開始される開始時間、および、前記１つ以上のインスタンスの実行が終了する終了時間を含む、
   請求項６〜８のいずれかに記載のシステム。
10. 前記プログラムモジュールが、前記コンピューティングサービスの前記複数のコンピューティングノードから、前記仮想化環境の生成に対する前記ユーザーによる前記要求を満足できるコンピューティングノードのグループを決定するようにさらに構成されている、
    請求項６〜９のいずれかに記載のシステム。
11. 前記仮想化環境が、前記負荷分散装置を含み、かつ、前記負荷分散装置が、前記利用期間中、前記仮想化環境の前記１つ以上のインスタンスの実行を、前記複数のコンピューティングノードの１つ以上から成る前記グループにわたって平均させるように構成されている、
    請求項１０に記載のシステム。
12. 前記プログラムモジュールが、
    前記仮想化環境の前記１つ以上のインスタンスのうちの少なくとも１つの障害を識別し、
    前記仮想化環境の少なくとも１つの新しいインスタンスを前記複数のコンピューティングノードの１つ以上から成る前記グループ上で開始するように
    さらに構成されている、
    請求項１０に記載のシステム。
13. 前記プログラムモジュールが、
    前記仮想化環境の前記１つ以上のインスタンスの利用において、または、前記複数のコンピューティングノードの１つ以上から成る前記グループの利用において、エラーが検出された場合に、ユーザーに通知するようにさらに構成されている、
    請求項１０に記載のシステム。
14. 前記仮想化環境に対して少なくとも１つの変更を行う前記要求が、前記仮想化環境の少なくとも１つのインスタンスを、前記複数のコンピューティングノードの前記１つ以上から成る前記グループ内の少なくともいくつかの前記コンピューティングノードとは異なる地理的位置内のコンピューティングノード上で実行する要求を含む、
    請求項１０に記載のシステム。
15. 前記仮想化環境を生成する前記要求が、前記ユーザーアプリケーションを１つ以上の所望の地理的地域で実行する要求をさらに含む、
    請求項６〜１４のいずれかに記載のシステム。

Images