JP6522128B2 - リソースサイジングの自動管理システム、方法及び非一時的コンピュータ可読記憶媒体 - Google Patents

Description

他の出願の相互参照
本願の出願人は、２０１４年９月３０日に、次の米国特許出願を出願した。
出願番号 １４／５０２，９９２
発明の名称 サービスとしてのスレッディング

さらに、本願の出願人は、２０１４年１２月５日に、次の米国特許出願を出願した。
出願番号 １４／５６２，６０１
発明の名称 リソースサイジングの自動判定

上記で参照された出願の開示は、参照によりその全体が本明細書に組み込まれる。

一般に言われているように、コンピューティングデバイスは、データを交換するために、１つの通信ネットワークまたは一連の通信ネットワークを利用する。企業や組織は、動作をサポートするため、または、サードパーティにサービスを提供するため、いくつかのコンピューティングデバイスを相互接続するコンピュータネットワークを運用する。コンピューティングシステムは、１つの地理的位置に配置されてもよく、または、多数の別個の地理的位置に配置されてもよい（例えば、プライベートまたはパブリック通信ネットワークを介して相互接続されてよい）。具体的には、本明細書において一般に「データセンター」と呼ばれるデータセンターまたはデータ処理センターは、データセンターのユーザにコンピューティングリソースを提供するように、いくつかの相互接続されたコンピューティングシステムを含んでよい。データセンターは、組織に代わって運用されるプライベートデータセンター、または、不特定多数の人々に代わって、もしくは不特定多数の人々の利益のために運用されるパブリックデータセンターであってよい。

データセンターリソースの利用の増加を促進するため、仮想化技術により、１つの物理的なコンピューティングデバイスが、データセンターのユーザにとって独立したコンピューティングデバイスとして出現及び動作する仮想マシンの１つまたは複数のインスタンスをホストすることが可能となり得る。仮想化により、１つの物理的なコンピューティングデバイスは、動的な方法で仮想マシンを作成、保守、削除、あるいは管理し得る。その結果、ユーザは、１つのコンピューティングデバイスまたはネットワーク化されたコンピューティングデバイスの構成を含み、且つ、種々の数の仮想マシンリソースを備える、データセンターからのコンピュータリソースを要求し得る。

いくつかのシナリオにおいて、仮想マシンインスタンスは、特定の機能性を提供するように、いくつかの仮想マシンインスタンスタイプに応じて構成されてよい。例えば、コンピューティングデバイスが異なる所望の機能性を提供すること、または、同様の機能性をより効率的に提供することを可能にするように、様々なコンピューティングデバイスは、オペレーティングシステムまたはオペレーティングシステム構成、仮想化されたハードウェアリソース及びソフトウェアアプリケーションの異なる組合せと関連してよい。これらの仮想マシンインスタンスタイプの構成は、多くの場合デバイスイメージ内に収容され、デバイスイメージは、仮想マシンがいったん始動されると実行するソフトウェア（例えば、ＯＳ及びアプリケーション、ならびに、それらの構成及びデータファイル等）を収容する静的データを含む。デバイスイメージは一般に、インスタンスを作成または初期化するのに使用されるディスクに記憶される。それゆえ、コンピューティングデバイスは、所望のソフトウェア構成を実行するため、デバイスイメージを処理してよい。

自動的なリソースリサイジングを提供するためのシステムが提供される。システムは、複数の仮想マシンインスタンスを保守するように構成されてよい。システムはさらに、プログラムコードを実行するための要求を受信するように、及び、仮想マシンインスタンスの１つ上でプログラムコードを実行するためにコンピューティングリソースを割り当てるように構成されてよい。プログラムコードを実行するために割り当てられるリソースの量は、要求によって指定されてよく、また、必要に応じて調整されてよい。

前述の態様及び本開示の付随する利点の多くが、添付の図面と併用して以下の詳細な説明を参照することにより、一層容易に理解され、同様に、良好に理解される。

例示的な態様に従った、低レイテンシコンピュートキャパシティを提供するための説明的な環境を表すブロック図である。 例示的な態様に従った、低レイテンシコンピュートキャパシティを管理するためのリソースマネージャを提供するコンピューティングデバイスの一般的なアーキテクチャを表す。 例示的な態様に従った、リソースマネージャにより実行されるリソースサイジングルーチンを示す流れ図である。 別の例示的な態様に従った、リソースマネージャにより実行されるリソースサイジングルーチンを示す流れ図である。 別の例示的な態様に従った、リソースマネージャにより実行されるリソースサイジングルーチンを示す流れ図である。 例示的な態様に従った、リソースマネージャにより実施されるリソースサイジングを示す。 例示的な態様に従った、リソースマネージャにより実施されるリソースサイジングを示す。 例示的な態様に従った、リソースマネージャにより実施されるリソースサイジングを示す。 別の例示的な態様に従った、リソースマネージャにより実施されるリソースサイジングを示す。 別の例示的な態様に従った、リソースマネージャにより実施されるリソースサイジングを示す。 別の例示的な態様に従った、リソースマネージャにより実施されるリソースサイジングを示す。

企業や組織はもはや、コンピューティング動作を実施（例えば、スレッド、プログラム、機能、ソフトウェア、ルーチン、サブルーチン、プロセス等を含むコードを実行）するために、自身の所有するデータセンターを獲得及び管理する必要はない。クラウドコンピューティングの出現により、ハードウェアコンピューティングデバイスにより従来提供されたストレージ空間及び演算能力は、今や、インターネット上において数分で取得及び構成され得る。それゆえ、開発者は、物理的なマシンの獲得を懸念する必要なく、所望の量のコンピューティングリソースを迅速に購入し得る。このようなコンピューティングリソースは、仮想コンピューティングリソースまたは仮想マシンインスタンスの形で一般に購入される。仮想マシンのこれらのインスタンスは、物理的なコンピューティングデバイス上でホストされる物理的なマシン（例えば、コンピュータ）のソフトウェア実施態様であり、物理的なマシン上に従来提供されるオペレーティングシステム及びアプリケーションを含んでよい。これらの仮想マシンインスタンスは、仮想マシンインスタンス上で実行するアプリケーションが要求してよく、また、物理的なコンピュータと同じ方法で利用されてよい、一連のコンピューティングリソース（例えば、メモリ、ＣＰＵ、ディスク、ネットワーク等）を備えて構成される。

しかしながら、仮想コンピューティングリソースが（例えば、仮想マシンインスタンスの形で）購入された場合でさえ、いくつの及びどんな種類の仮想マシンインスタンスを購入するか、ならびに、それらをいつまで維持するかを、開発者は依然として決定しなければならない。例えば、仮想マシンインスタンスを使用するコストは、タイプ及びそれらが貸し出される時間数により変動し得る。加えて、仮想マシンを貸し出すことのできる最短時間は、一般に約数時間である。さらに、開発者は、仮想マシンにインストールするためにハードウェア及びソフトウェアリソース（例えば、オペレーティングシステム及び言語ランタイム等のタイプ）を指定しなければならない。彼らが抱えることのある他の懸念は、過剰利用（例えば、獲得するコンピューティングリソースが少な過ぎて、パフォーマンス問題に悩まされること）、過少利用（例えば、コードを実行するのに必要とされるよりも多くのコンピューティングリソースを獲得し、それゆえ余計に支払うこと）、トラフィックの変化の予測（例えば、これにより、彼らはいつスケールアップまたはスケールダウンするかが分かる）、及び、インスタンス及び言語ランタイム起動遅延を含む。こうした遅延は、ユーザが、約数秒またはさらに約ミリ秒でコンピューティングキャパシティを所望することがあるにも関わらず、３〜１０分またはそれよりも長くかかることがあるものである。それゆえ、ユーザが、サービスプロバイダにより提供される仮想マシンインスタンスを活用することを可能にする改善された方法が所望される。

本開示の態様によれば、ユーザ要求が受信されるとすぐに使用の準備ができている、予め初期化された仮想マシンインスタンスのプールを保守することにより、ユーザコードを実行すること（例えばインスタンス及び言語ランタイム起動時間）と関連した遅延（レイテンシと呼ばれることもある）が、著しく削減され得る。

一般に言われているように、本開示の態様は、仮想マシンインスタンス、及び仮想マシンインスタンスに作成されるコンテナの管理に関する。具体的には、仮想コンピュートシステムにおける仮想マシンインスタンスの管理を促進するシステム及び方法が開示される。仮想コンピュートシステムは、そこにロードされた１つまたは複数のソフトウェア構成要素（例えば、オペレーティングシステム、言語ランタイム、ライブラリ等）を有する仮想マシンインスタンスのプールを保守する。仮想マシンインスタンスのプールを保守することは、新たなインスタンスを作成すること、外部のインスタンスプロビジョニングサービスから新たなインスタンスを取得すること、インスタンスをデストロイすること、インスタンスをユーザに割り当てること／再び割り当てること、インスタンス（例えば、コンテナまたはその中のリソース）を修正すること等を含んでよい。プールにおける仮想マシンインスタンスは、プログラムコードを実行するためのユーザ要求にサービスするように指定されてよい。本開示において、「プログラムコード」、「ユーザコード」、及び「クラウド機能」といった表現は、時として区別なく使用されることがある。プログラムコードは、仮想マシンインスタンス上に作成された、隔離されたコンテナにおいて実行されてよい。プールにおける仮想マシンインスタンスは、要求が受信される時までに既に立ち上げられ、且つ、特定のオペレーティングシステム及び言語ランタイムをロードしているので、（例えば、仮想マシンインスタンス上に作成される１つまたは複数のコンテナにおいてユーザコードを実行することにより）要求に対処し得るコンピュートキャパシティを発見することと関連した遅延が著しく削減される。

別の態様において、仮想コンピュートシステムは、ユーザコードを実行するために割り当てられるリソースの量に関連した情報をモニタ及びログしてよい。そうすることにより、仮想コンピュートシステムは、割り当てられるリソースの量を調整することにより、ユーザコード実行のパフォーマンスを改善するための機会を識別可能であってよい。誤り率は、過剰利用の場合、割り当てられるリソースの量を増加させることによって減少でき、また、過少利用の場合、ユーザコードの実行と関連したコストが、割り当てられるリソースの量を減少させることによって削減できる。

本開示の特定の実施形態及び例示的な用途が、次に図面を参照して説明される。これらの実施形態及び例示的な用途は、本開示を説明することを意図しており、本開示を限定することを意図しない。

図１を参照して、仮想環境１００の実施形態を示すブロック図が説明される。図１に示された実施例は、ユーザコンピューティングデバイス１０２のユーザ（例えば、開発者等）が仮想コンピュートシステム１１０により提供される仮想コンピューティングリソースを使用して様々なプログラムコードを実行し得る、仮想環境１００を含む。

実例として、デスクトップコンピュータ、ラップトップ、及び携帯電話を含め、仮想コンピュートシステム１１０と通信する様々な例示的なユーザコンピューティングデバイス１０２が示される。一般に、ユーザコンピューティングデバイス１０２は、デスクトップ、ラップトップ、携帯電話（またはスマートフォン）、タブレット、キオスク、無線デバイス、及び他の電子デバイスなど、任意のコンピューティングデバイスであってよい。加えて、ユーザコンピューティングデバイス１０２は、同一または異なるデータセンター上で実行するウェブサービスを含んでよく、そこでは、例えば、異なるウェブサービスが、本明細書において説明される１つまたは複数の技法を実施するように、互いにプログラムで通信してよい。さらに、ユーザコンピューティングデバイス１０２は、インターネットアプライアンス及び接続されるデバイスなど、モノのインターネット（ＩｏＴ）デバイスを含んでよい。仮想コンピュートシステム１１０は、ユーザコードを生成及びアップロードし、ユーザコードを呼び出し（例えば、仮想コンピュートシステム１１０上でユーザコードを実行するための要求をサブミットし）、イベントベースのジョブまたは時間指定されたジョブをスケジューリングし、ユーザコードを追跡し、ならびに／または、それらの要求及び／またはユーザコードに関連するその他のロギングまたはモニタリング情報を表示するための、１つまたは複数のユーザインターフェース、コマンドラインインターフェース（ＣＬＩ）、アプリケーションプログラミングインターフェース（ＡＰＩ）、及び／または、他のプログラマチックインターフェースを、ユーザコンピューティングデバイス１０２に提供してよい。１つまたは複数の実施形態が、ユーザインターフェースを使用するものとして本明細書において説明され得るが、そのような実施形態が、追加的または代替的に、任意のＣＬＩ、ＡＰＩ、または他のプログラマチックインターフェースを使用してもよいことを理解すべきである。

ユーザコンピューティングデバイス１０２は、ネットワーク１０４を介して仮想コンピュートシステム１１０にアクセスする。ネットワーク１０４は、任意の有線ネットワーク、無線ネットワーク、またはそれらの組合せであってよい。加えて、ネットワーク１０４は、パーソナルエリアネットワーク、ローカルエリアネットワーク、広域ネットワーク、無線の放送網ネットワーク（例えば、ラジオまたはテレビ用）、ケーブルネットワーク、衛星ネットワーク、携帯電話ネットワーク、またはそれらの組合せであってよい。例えば、ネットワーク１０４は、インターネットなど、場合によっては様々な別個の当事者により動作される、接続されたネットワークのうちの公衆にアクセス可能なネットワークであってよい。いくつかの実施形態において、ネットワーク１０４は、法人または大学のイントラネットなど、プライベートまたは準プライベートネットワークであってよい。ネットワーク１０４は、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ）ネットワーク、符号分割多元接続（ＣＤＭＡ）ネットワーク、ロングタームエボリューション（ＬＴＥ）ネットワーク、または任意の他のタイプの無線ネットワークなど、１つまたは複数の無線ネットワークを含んでよい。ネットワーク１０４は、インターネットまたは他の前述のタイプのネットワークのいずれかを介して通信するためのプロトコル及び構成要素を使用してよい。例えば、ネットワーク１０４により使用されるプロトコルは、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）、ＨＴＴＰセキュア（ＨＴＴＰＳ）、Ｍｅｓｓａｇｅ Ｑｕｅｕｅ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ（ＭＱＴＴ）、Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）等を含んでよい。インターネットまたは他の前述のタイプの通信ネットワークのいずれかを介して通信するためのプロトコル及び構成要素は、当業者によく知られており、それゆえ、本明細書ではより詳細に説明されない。

仮想コンピュートシステム１１０は、１つまたは複数のコンピュータネットワークを使用して相互接続されるいくつかのコンピュータシステムを含む分散コンピューティング環境において動作するものとして、図１に表わされる。仮想コンピュートシステム１１０はまた、図１に示したよりも少ない数または多い数のデバイスを有するコンピューティング環境内で動作してもよい。それゆえ、図１における仮想コンピュートシステム１１０の描写は、説明的なものとして受け取られるべきであり、本開示に限定するものでない。例えば、仮想コンピュートシステム１１０またはその様々な構成要素は、本明細書において説明されるプロセスの少なくとも一部を実行するように、様々なウェブサービス構成要素、ホストまたは「クラウド」コンピューティング環境、及び／または、ピアツーピアネットワーク構成を実行してよい。

さらに、仮想コンピュートシステム１１０は、ハードウェア及び／またはソフトウェアにおいて実行されてよく、例えば、本明細書において説明される様々な特徴を実施するための、コンピュータにより実行可能な命令を実行するように構成される、物理的なコンピュータハードウェア上で実行される１つまたは複数の物理的または仮想サーバを含んでよい。１つまたは複数のサーバは、地理的に分散されてもよく、または、例えば１つまたは複数のデータセンターにおいて地理的に同じ場所に配置されてもよい。

図１に示した環境において、仮想環境１００は、仮想コンピュートシステム１１０を含み、仮想コンピュートシステム１１０は、フロントエンド１２０、ウォーミングプールマネージャ１３０、ワーカマネージャ１４０、及び、リソースマネージャ１５０を含む。表された実施例において、仮想マシンインスタンス（「インスタンス」）１５２、１５４が、ウォーミングプールマネージャ１３０により管理されるウォーミングプール１３０Ａにおいて示され、インスタンス１５６、１５７、１５８、１５９が、ワーカマネージャ１４０により管理されるアクティブプール１４０Ａにおいて示される。仮想コンピュートシステム１１０内の様々な構成要素の実例は、実際には論理的なものであり、構成要素の１つまたは複数は、１つのコンピューティングデバイスまたは多数のコンピューティングデバイスにより実行されてよい。例えば、インスタンス１５２、１５４、１５６、１５７、１５８、１５９は、異なる様々な地理的領域における１つまたは複数の物理的なコンピューティングデバイス上で実行されてよい。同様に、フロントエンド１２０、ウォーミングプールマネージャ１３０、ワーカマネージャ１４０、及びリソースマネージャ１５０のそれぞれは、多数の物理的なコンピューティングデバイス間で実行されてよい。あるいは、フロントエンド１２０、ウォーミングプールマネージャ１３０、ワーカマネージャ１４０、及びリソースマネージャ１５０の１つまたは複数が、１つの物理的なコンピューティングデバイス上で実行されてよい。いくつかの実施形態において、仮想コンピュートシステム１１０は、多数のフロントエンド、多数のウォーミングプールマネージャ、多数のワーカマネージャ、及び／または、多数のキャパシティマネージャを含んでよい。６つの仮想マシンインスタンスが図１の実施例に示されるが、本明細書において説明される実施形態はそのように限定されず、仮想コンピュートシステム１１０が、任意の数の物理的なコンピューティングデバイスを使用して実行される任意の数の仮想マシンインスタンスを含んでよいことを当業者は理解する。同様に、１つのウォーミングプール及び１つのアクティブプールが図１の実施例に示されるが、本明細書において説明される実施形態はそのように限定されず、仮想コンピュートシステム１１０が、任意の数のウォーミングプール及びアクティブプールを含んでよいことを当業者は理解する。

図１の実施例において、仮想コンピュートシステム１１０は、ネットワーク１０４に接続されるものとして示される。いくつかの実施形態において、仮想コンピュートシステム１１０内の構成要素のいずれかは、仮想環境１００の他の構成要素（例えば、ユーザコンピューティングデバイス１０２及び補助サービス１０６であり、補助サービス１０６は、モニタリング／ロギング／ビリングサービス１０７、ストレージサービス１０８、インスタンスプロビジョニングサービス１０９、及び／または、仮想コンピュートシステム１１０と通信し得る他のサービスを含んでよい）とネットワーク１０４を介して通信してよい。他の実施形態において、仮想コンピュートシステム１１０の全ての構成要素が、仮想環境１００の他の構成要素と通信可能であるとは限らない。１つの実施例において、フロントエンド１２０のみがネットワーク１０４に接続されてよく、仮想コンピュートシステム１１０の他の構成要素は、フロントエンド１２０を介して、仮想環境１００の他の構成要素と通信してよい。

ユーザは、仮想コンピュートシステム１１０を、そこにあるユーザコードを実行するために使用してよい。例えば、ユーザは、ユーザが開発したウェブまたはモバイルアプリケーションに関連して１つのコードを実行することを望むことがある。コードを実行する１つの方法は、サービスとしてインフラストラクチャを提供するサービスプロバイダから仮想マシンインスタンスを獲得し、当該仮想マシンインスタンスをユーザのニーズに適合するように構成し、構成された仮想マシンインスタンスを、コードを実行するのに使用することであろう。あるいは、ユーザは、仮想コンピュートシステム１１０へコード実行要求を送信してもよい。仮想コンピュートシステム１１０は、コード実行要求に基づいて、コンピュートキャパシティ（例えば、以下でより詳細に説明されるコンテナ、インスタンス等）の獲得及び構成に対処してよく、コンピュートキャパシティを使用してコードを実行してよい。仮想コンピュートシステム１１０は、ボリュームに基づいて自動的にスケールアップまたはスケールダウンしてよく、これにより、過剰利用（例えば、獲得するコンピューティングリソースが少な過ぎて、パフォーマンス問題に悩まされること）、または、過少利用（例えば、コードを実行するのに必要とされるよりも多くのコンピューティングリソースを獲得し、それゆえ余計に支払うこと）を懸念しなければならないという負担から、ユーザが解放される。

フロントエンド１２０は、仮想コンピュートシステム１１０上でユーザコードを実行するための要求全てを処理する。１つの実施形態において、フロントエンド１２０は、仮想コンピュートシステム１１０により提供される他のサービス全てにとってのフロントドアとしての働きをする。フロントエンド１２０は、要求を処理し、当該要求が適切にオーソライズされることを確認する。例えば、フロントエンド１２０は、要求と関連したユーザが、要求において指定されたユーザコードにアクセスするのにオーソライズされるかどうかを判定してよい。

本明細書において使用されるユーザコードは、特定のプログラム言語で記述された任意のプログラムコード（例えば、プログラム、ルーチン、サブルーチン、スレッド等）を参照してよい。本開示において、「コード」、「ユーザコード」及び「プログラムコード」という用語は、区別なく使用され得る。このようなユーザコードは、例えば、ユーザにより開発される特定のウェブアプリケーションまたはモバイルアプリケーションに関連して特定のタスクを達成するように実行されてよい。例えば、ユーザコードは、ＪａｖａＳｃｒｉｐｔ（登録商標）（ｎｏｄｅ．ｊｓ）、Ｊａｖａ（登録商標）、Ｐｙｔｈｏｎ（登録商標）、及び／または、Ｒｕｂｙ（登録商標）で記述されてよい。要求は、ユーザコード（またはその位置）、及びユーザコードを実行するために使用される１つまたは複数の引数を含んでよい。例えば、ユーザは、ユーザコードを実行するための要求と共にユーザコードを提供してよい。別の実施例において、要求は、予めアップロードされたプログラムコードを、（例えば、コードをアップロードするためのＡＰＩを使用して）その名前またはそのユニークなＩＤによって識別してよい。さらに別の実施例において、コードは、要求に含まれてもよく、また、要求が仮想コンピュートシステム１１０により受信される前に、別個の位置（例えば、ストレージサービス１０８、または仮想コンピュートシステム１１０内のストレージシステム）においてアップロードされてもよい。仮想コンピュートシステム１１０は、要求が処理される時点でコードが利用可能である場所に基づいて、そのコード実行ストラテジを変更してよい。

フロントエンド１２０は、ユーザからのハイパーテキストトランスファープロトコルセキュア（ＨＴＴＰＳ）要求に応答して、そのようなユーザコードを実行するための要求を受信してよい。また、ユーザコードを実行するとき、ＨＴＴＰＳ要求に含まれる任意の情報（例えば、ヘッダ及びパラメータ）がさらに処理及び利用されてもよい。上述のように、例えば、ＨＴＴＰ、ＭＱＴＴ及びＣｏＡＰを含め、任意の他のプロトコルが、コード実行要求を収容するメッセージをフロントエンド１２０に転送するのに使用されてよい。フロントエンド１２０はまた、自動の要求生成をトリガするためにユーザが登録したイベントなどのイベントが検出されたときに、そのようなユーザコードを実行するための要求を受信してもよい。例えば、ユーザは、補助サービス１０６によりユーザコードを登録していてもよく、また、特定のイベントが発生する（例えば、新たなファイルがアップロードされる）たびに、ユーザコードを実行するための要求がフロントエンド１２０へ送信されることを指定していてもよい。あるいは、ユーザは、時間指定されたジョブ（例えば、２４時間毎にユーザコードを実行する）を登録していてもよい。このような実施例において、時間指定されたジョブについてスケジュールされた時間がやってくるとき、ユーザコードを実行するための要求が、フロントエンド１２０に送信されてよい。さらに別の実施例において、フロントエンド１２０は、入来するコード実行要求のキューを有してよく、ユーザのバッチジョブが仮想コンピュートシステムのワークキューから削除されるとき、フロントエンド１２０はユーザ要求を処理してよい。さらに別の実施例において、要求は、仮想コンピュートシステム１１０内の別の構成要素または図１に示されない他のサーバもしくはサービスから発生されてよい。

ユーザ要求は、ユーザコードと共に使用すべき１つまたは複数のサードパーティのライブラリ（ネイティブライブラリを含む）を指定してよい。１つの実施形態において、ユーザ要求は、ユーザコード及び任意のライブラリ（及び／またはそのストレージ位置の識別）を収容するＺＩＰファイルである。いくつかの実施形態において、ユーザ要求は、実行すべきプログラムコードを示すメタデータ、プログラムコードを記述する言語、要求と関連したユーザ、及び／または、プログラムコードを実行するためにリザーブすべきコンピューティングリソース（例えば、メモリ、ＣＰＵ、ストレージ、ネットワークパケット等）を含む。例えば、プログラムコードは、要求を備えてもよく、ユーザにより予めアップロードされてもよく、仮想コンピュートシステム１１０（例えば、標準ルーチン）により提供されてもよく、及び／または、サードパーティにより提供されてもよい。いくつかの実施形態において、リソースレベルの制約（例えば、特定のユーザコードを実行するためにどのくらいのメモリを割り当てるべきか）は、特定のユーザコードに対して指定され、ユーザコードの各実行と共に変化するものでなくてよい。このような場合、仮想コンピュートシステム１１０は、各個々の要求が受信される前にそのようなリソースレベルの制約を利用してよく、個々の要求がそのようなリソースレベルの制約を指定しなくてよい。いくつかの実施形態において、リソースレベルの制約は、経時的に調整され、また、１つのプログラムコードの様々な実行によって変化し得る。例えば、同一のプログラムコードが、データの２つの異なるセットを処理するのに使用されてよく、そこでは、データの１つのセットが、もう一方よりも多くのリソースを必要とする。このような場合、ユーザは、２つの異なる実行のために異なるリソース制約を指定してよく、または、仮想コンピュートシステム１１０は、ユーザ及び／またはプログラムコードについての空間的（例えば、仮想コンピュートシステム１１０の他の部分における）傾向、または履歴的（例えば、経時的）傾向に基づいて、プログラムコードの各実行に割り当てられるリソースの量を自動的に調整してよい。いくつかの実施形態において、ユーザ要求は、ユーザコードを実行するためにどのようなパーミッションを要求が有するのかを示すパーミッションデータなど、他の制約を指定してよい。このようなパーミッションデータは、（例えば、プライベートネットワーク上の）プライベートリソースにアクセスするために、仮想コンピュートシステム１１０により使用されてよい。

いくつかの実施形態において、ユーザ要求は、ユーザ要求に対処するために用いるべきビヘイビアを指定してよい。このような実施形態において、ユーザ要求は、ユーザ要求と関連したユーザコードが実行され得る１つまたは複数の実行モードを可能にするための標識を含んでよい。例えば、要求は、ユーザコードの実行に関連して生成され得るデバッギング及び／またはロギング出力が（例えば、コンソールユーザインターフェースを介して）ユーザに提供されるデバッグモードにおいて、ユーザコードを実行すべきかどうかを示すためのフラグまたはヘッダを含んでよい。このような実施例において、仮想コンピュートシステム１１０は要求を検査してよく、フラグまたはヘッダを探してよく、それが存在する場合には、仮想コンピュートシステム１１０は、ユーザコードが実行されるコンテナのビヘイビア（例えば、ロギングファシリティ）を修正してよく、出力データをユーザに提供させてよい。いくつかの実施形態において、ビヘイビア／モード標識は、仮想コンピュートシステム１１０によりユーザに提供されるユーザインターフェースによって要求に追加される。ソースコードプロファイリング、リモートデバッギング等などの他の特徴はまた、要求において提供されるインディケーションに基づいて有効または無効にされてよい。

いくつかの実施形態において、仮想コンピュートシステム１１０は、多数のフロントエンド１２０を含んでよい。このような実施形態において、ロードバランサが、例えばラウンドロビン方式で、入来する要求を多数のフロントエンド１２０へ分散するように提供されてよい。いくつかの実施形態において、ロードバランサが、入来する要求を多数のフロントエンド１２０へ分散する方法は、ウォーミングプール１３０Ａ及び／またはアクティブプール１４０Ａの状態に基づくものであってよい。例えば、ウォーミングプール１３０Ａにおけるキャパシティが十分であると考えられる場合、要求は、フロントエンド１２０の個々のキャパシティに基づいて（例えば、１つまたは複数のロードバランシング制限に基づいて）、多数のフロントエンド１２０へ分散されてよい。一方、ウォーミングプール１３０Ａにおけるキャパシティが閾値量よりも低い場合、そのようなロードバランシング制限の１つまたは複数は削除されてよく、その結果、ウォーミングプール１３０Ａから取得される仮想マシンインスタンスの数を削減または最小にする方法で、要求は、多数のフロントエンド１２０へ分散されてよい。例えば、ロードバランシング制限に従って、要求がフロントエンドＡにルートされるべきであっても、フロントエンドＡは、要求にサービスするためにウォーミングプール１３０Ａからインスタンスを取得する必要があるが、フロントエンドＢは、同一の要求にサービスするために、そのアクティブプールおけるインスタンスの１つを使用し得る場合、要求は、フロントエンドＢにルートされてよい。

仮想コンピュートシステム１１０が、仮想コンピュートシステム１１０上でユーザコードを実行するための要求を受信するとき、仮想マシンインスタンスがワーカマネージャ１４０によりすぐに使用されることができることを、ウォーミングプールマネージャ１３０が確実にする。図１に示した実施例において、ウォーミングプールマネージャ１３０は、入来するユーザコード実行要求にサービスするのに使用され得る予め初期化され且つ予め構成された仮想マシンインスタンスのグループ（プールと呼ばれることもある）である、ウォーミングプール１３０Ａを管理する。いくつかの実施形態において、ウォーミングプールマネージャ１３０は、仮想マシンインスタンスを、仮想コンピュートシステム１１０内の１つまたは複数の物理的なコンピューティングマシン上で立ち上げさせて、ウォーミングプール１３０Ａに追加させる。他の実施形態において、ウォーミングプールマネージャ１３０は、新たなインスタンスを作成してそれをウォーミングプール１３０Ａに追加するように、補助仮想マシンインスタンスサービス（例えば、図１のインスタンスプロビジョニングサービス１０９）と通信する。いくつかの実施形態において、ウォーミングプールマネージャ１３０は、フロントエンド１２０により受信されるコード実行要求にサービスするのに使用され得るコンピュートキャパシティを獲得及び保守するように、仮想コンピュートシステム１１０内の物理的なコンピューティングデバイスと、１つまたは複数の仮想マシンインスタンスサービスとの両方を利用してよい。いくつかの実施形態において、仮想コンピュートシステム１１０は、ウォーミングプール１３０Ａにおける利用可能なキャパシティを制御（例えば、増加または削減）するための１つまたは複数の論理ノブまたはスイッチを含んでよい。例えば、システム管理者は、ピーク時の間、ウォーミングプール１３０Ａにおいて利用可能なキャパシティ（例えば、予め立ち上げられたインスタンスの数）を増加するように、そのようなノブまたはスイッチを使用してよい。いくつかの実施形態において、ウォーミングプール１３０Ａにおける仮想マシンインスタンスは、ユーザのコードを実行するための、特定のユーザ要求から独立した構成の所定のセットに基づいて構成されてよい。構成の所定のセットは、ユーザコードを実行するように様々なタイプの仮想マシンインスタンスに対応してよい。ウォーミングプールマネージャ１３０は、現在または以前のユーザコード実行に関連する１つまたは複数のメトリクスに基づいて、ウォーミングプール１３０Ａにおける仮想マシンインスタンスのタイプ及び数を最適化してよい。

図１に示すように、インスタンスは、そこにロードされたオペレーティングシステム（ＯＳ）及び／または言語ランタイムを有してよい。例えば、ウォーミングプールマネージャ１３０により管理されるウォーミングプール１３０Ａは、インスタンス１５２、１５４を含む。インスタンス１５２は、ＯＳ１５２Ａ及びランタイム１５２Ｂを含む。インスタンス１５４は、ＯＳ１５４Ａを含む。いくつかの実施形態において、ウォーミングプール１３０Ａにおけるインスタンスはまた、以下でより詳細に説明される、（オペレーティングシステム、ランタイム、ユーザコード等のコピーをさらに含んでよい）コンテナを含んでもよい。インスタンス１５２が１つのランタイムを含むように図１に示されるが、他の実施形態において、図１に表されたインスタンスは、２つまたはそれよりも多いランタイムを含んでもよく、そのそれぞれが異なるユーザコードを実行するために使用されてよい。いくつかの実施形態において、ウォーミングプールマネージャ１３０は、ウォーミングプール１３０Ａにおけるインスタンスのリストを保持してよい。インスタンスのリストはさらに、インスタンスの構成（例えば、ＯＳ、ランタイム、コンテナ等）を指定してよい。

いくつかの実施形態において、ウォーミングプール１３０Ａにおける仮想マシンインスタンスは、任意のユーザの要求に応対するのに使用されてよい。１つの実施形態において、ウォーミングプール１３０Ａにおける仮想マシンインスタンス全ては、同一または実質的に同様の方法で構成される。別の実施形態において、ウォーミングプール１３０Ａにおける仮想マシンインスタンスは、異なるユーザのニーズに適合するように異なって構成されてよい。例えば、仮想マシンインスタンスは、そこにロードされた異なるオペレーティングシステム、異なる言語ランタイム、及び／または、異なるライブラリを有してよい。さらに別の実施形態において、ウォーミングプール１３０Ａにおける仮想マシンインスタンスは、同一または実質的に同様の方法で（例えば、同一のＯＳ、言語ランタイム、及び／または、ライブラリを備えて）構成されてよいが、これらのインスタンスのうちのいくつかが異なるコンテナ構成を有してもよい。例えば、２つのインスタンスはＰｙｔｈｏｎ（登録商標）とＲｕｂｙ（登録商標）の両方のためのランタイムを有してもよいが、一方のインスタンスは、Ｐｙｔｈｏｎ（登録商標）コードを実行するように構成されるコンテナを有してよく、他方のインスタンスは、Ｒｕｂｙ（登録商標）コードを実行するように構成されるコンテナを有してよい。いくつかの実施形態において、それぞれが全く同様に構成された仮想マシンインスタンスを有する多数のウォーミングプール１３０Ａが提供される。

各仮想マシンインスタンスが、仮想コンピュートシステム１１０上でプログラムコードを実行するためのユーザ要求により要求または指定され得る動作条件の少なくとも１つを満たすように構成されるように、ウォーミングプールマネージャ１３０は、ウォーミングプール１３０Ａにおける仮想マシンインスタンスを予め構成してよい。１つの実施形態において、動作条件は、可能なユーザコードを記述できるプログラム言語を含んでよい。例えば、そのような言語は、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｙｔｈｏｎ（登録商標）、Ｒｕｂｙ（登録商標）等を含んでよい。いくつかの実施形態において、ユーザコードを記述できる言語のセットは、ユーザコードを実行するための要求を満たし得る仮想マシンインスタンスの事前初期化を促進するため、所定のセット（例えば４言語のセットであるが、いくつかの実施形態においては、４言語よりも多い、または少ないセットが提供される）に限定されてよい。例えば、ユーザが、仮想コンピュートシステム１１０により提供されるユーザインターフェースを介して要求を構成しているとき、ユーザインターフェースは、ユーザコードを実行するために所定の動作条件の１つを指定するようユーザに促してよい。別の実施例において、仮想コンピュートシステム１１０により提供されるサービスの利用に関するサービス水準合意（ＳＬＡ）は、ユーザ要求が満たすべき一連の条件（例えば、プログラミング言語、コンピューティングリソース等）を指定してよく、仮想コンピュートシステム１１０は、要求に対処するにあたり、要求が一連の条件を満たすと想定してよい。別の実施例において、要求において指定された動作条件は、要求を処理するために使用される演算能力の量、要求のタイプ（例えば、ＨＴＴＰ対トリガされるイベント）、要求のためのタイムアウト（例えば、要求を終了し得た後の閾値時間）、セキュリティポリシー（例えば、ウォーミングプール１３０Ａにおけるどのインスタンスがどのユーザにより使用可能かを制御してよい）等を含んでよい。

ワーカマネージャ１４０は、入来するコード実行要求にサービスするために使用されるインスタンスを管理する。図１に示した実施例において、ワーカマネージャ１４０は、１人または複数のユーザに現在割り当てられている仮想マシンインスタンスのグループ（プールと呼ばれることもある）であるアクティブプール１４０Ａを管理する。仮想マシンインスタンスが、特定のユーザに割り当てられるものとしてここでは説明されるが、いくつかの実施形態において、インスタンスは、ユーザのグループに割り当てられてもよく、これにより、インスタンスはユーザのグループに結び付けられて、グループのどのメンバーもインスタンス上のリソースを利用することができる。例えば、同一グループにおけるユーザは、（例えば、ユーザのセキュリティ証明書に基づいて）同一のセキュリティグループに属してよく、これにより、１人のメンバーのコードを特定のインスタンス上のコンテナにおいて実行する前に、別のメンバーのコードが同一のインスタンス上の別のコンテナにおいて実行されていても、セキュリティ上のリスクは生じない。同様に、どのコンテナにおいてどの要求を実行できるか、及び、どのインスタンスをどのユーザに割り当てることができるかを規定する１つまたは複数のポリシーに従って、ワーカマネージャ１４０は、インスタンス及びコンテナを割り当ててよい。例示的なポリシーは、インスタンスが、同一のアカウント（例えば、仮想コンピュートシステム１１０により提供されるサービスにアクセスするためのアカウント）を共有するユーザの集まりに割り当てられることを指定してよい。いくつかの実施形態において、同一のユーザグループと関連した要求は、（例えば、それに関連したユーザコードが全く同一である場合）同一のコンテナを共有してよい。いくつかの実施形態において、要求は、グループの中の異なるユーザ間で区別されず、要求と関連したユーザが属するグループを示すに過ぎない。

図１に示した実施例において、ユーザコードは、コンテナと呼ばれる隔離されたコンピュートシステムにおいて実行される。コンテナは、仮想マシンインスタンス内で、そのインスタンス上で利用可能なリソースを使用して作成される論理ユニットである。例えば、ワーカマネージャ１４０は、ユーザコードを実行するための要求において指定された情報に基づいて、新たなコンテナを作成してよく、または、アクティブプール１４０Ａにおけるインスタンスの１つに既存のコンテナを配置してよく、また、要求と関連したユーザコードの実行に対処するように、当該コンテナを要求に割り当てる。１つの実施形態において、そのようなコンテナは、Ｌｉｎｕｘコンテナとして実行される。アクティブプール１４０Ａにおける仮想マシンインスタンスは、そこに作成される１つまたは複数のコンテナを有してよく、（例えば、コンテナのうちの１つ、またはインスタンスのローカルキャッシュのいずれかにおいて）そこにロードされた、ユーザと関連した１つまたは複数のプログラムコードを有してよい。

図１に示すように、インスタンスは、オペレーティングシステム（ＯＳ）、言語ランタイム、及びコンテナを有してよい。コンテナは、ＯＳ及び言語ランタイムの個々のコピーならびにそこにロードされたユーザコードを有してよい。図１の実施例において、ワーカマネージャ１４０により管理されるアクティブプール１４０Ａは、インスタンス１５６、１５７、１５８、１５９を含む。インスタンス１５６は、コンテナ１５６Ａ、１５６Ｂを有する。コンテナ１５６Ａは、その中にロードされたＯＳ１５６Ａ‐１、ランタイム１５６Ａ‐２、及びコード１５６Ａ‐３を有する。表された実施例において、コンテナ１５６Ａは、その中にロードされた、それ自体のＯＳ、ランタイム、及びコードを有する。１つの実施形態において、ＯＳ１５６Ａ‐１（例えば、そのカーネル）、ランタイム１５６Ａ‐２、及び／または、コード１５６Ａ‐３は、コンテナ１５６Ａ、１５６Ｂ（及び図１に示されない任意の他のコンテナ）の間で共有される。別の実施形態において、ＯＳ１５６Ａ‐１（例えば、カーネルの外で実行する任意のコード）、ランタイム１５６Ａ‐２、及び／または、コード１５６Ａ‐３は、コンテナ１５６Ａのために作成される独立したコピーであり、インスタンス１５６上の他のコンテナと共有されない。さらに別の実施形態において、ＯＳ１５６Ａ‐１、ランタイム１５６Ａ‐２、及び／または、コード１５６Ａ‐３のいくつかの部分が、インスタンス１５６上のコンテナ間で共有され、それらの他の部分は、コンテナ１５６Ａに特有の独立したコピーである。インスタンス１５７はコンテナ１５７Ａ、１５７Ｂ、１５７Ｃを含み、インスタンス１５８はコンテナ１５８Ａを含み、インスタンス１５９は、コンテナ１５９Ａを含む。

図１の実施例において、図１に表されたコンテナのサイズは、コンテナの実際のサイズに比例してよい。例えば、コンテナ１５６Ａは、インスタンス１５６上のコンテナ１５６Ｂよりも多くの空間を占有する。同様に、コンテナ１５７Ａ、１５７Ｂ、１５７Ｃ、１５９Ａは、等しいサイズにされてよく、コンテナ１５８Ａは、コンテナ１５７Ａ、１５７Ｂ、１５７Ｃ、１５９Ａよりも大きくてよい（例えば、そこに割り当てられた、より多くのコンピューティングリソースを有してよい）。インスタンス１５９に示される「Ｃ」と付された点線のボックスは、新たなインスタンスを作成するのに使用され得る、インスタンス上に残されている空間を示す。いくつかの実施形態において、コンテナのサイズは、６４ＭＢまたは任意のその倍数であってよい。他の実施形態において、コンテナのサイズは、コンテナが作成されるインスタンスのサイズよりも小さいか、またはそれと等しい、どんな任意のサイズであってもよい。いくつかの実施形態において、コンテナのサイズは、コンテナが作成されるインスタンスのサイズよりも小さいか、それと等しいか、またはそれよりも大きい、どんな任意のサイズであってもよい。コンテナのサイズがインスタンスのサイズをどのくらい上回ってよいかは、これらのコンテナが、インスタンスにより提供されるキャパシティを超えて利用されることのある可能性がどの程度かに基づいて決定されてよい。例えば、１ＧＢのメモリサイズを有する５つのコンテナ（合計５ＧＢ）が、４ＧＢのメモリサイズを有するインスタンスに作成されてよい。コンテナのそれぞれが、１ＧＢの全キャパシティに達しない場合、コンテナは、オーバーサブスクリプションにもかかわらず、適切に機能し得る。

コンテナ１５６Ｂ、１５７Ａ、１５７Ｂ、１５７Ｃ、１５８Ａ、１５９Ａ内部の構成要素は、図１の実施例に示されていないが、これらのコンテナのそれぞれは、様々なオペレーティングシステム、言語ランタイム、ライブラリ、及び／または、ユーザコードを有してよい。いくつかの実施形態において、インスタンスは、（例えば、インスタンスレベルのキャッシュにおいて）そこにロードされたユーザコードを有してよく、これらのインスタンス内のコンテナはまた、その中にロードされたユーザコードを有してよい。いくつかの実施形態において、ワーカマネージャ１４０は、アクティブプール１４０Ａにおけるインスタンスのリストを保持してよい。インスタンスのリストはさらに、インスタンスの構成（例えば、ＯＳ、ランタイム、コンテナ等）を指定してよい。いくつかの実施形態において、ワーカマネージャ１４０は、ウォーミングプール１３０Ａにおける（例えば、インスタンスの数及びタイプを含む）インスタンスのリストを利用してよい。他の実施形態において、ワーカマネージャ１４０は、ウォーミングプール１３０Ａにおける仮想マシンインスタンスの知識を有することなく、ウォーミングプールマネージャ１３０からコンピュートキャパシティを要求する。

要求がフロントエンド１２０により正常に処理された後、ワーカマネージャ１４０は、仮想コンピュートシステム１１０上でユーザコードを実行するための要求にサービスするキャパシティを発見する。例えば、アクティブプール１４０Ａにおいて、その中にロードされた同一のユーザコード（例えば、コンテナ１５６Ａに示したコード１５６Ａ‐３）を備えるコンテナを有する特定の仮想マシンインスタンスが存在する場合、ワーカマネージャ１４０は、当該コンテナを要求に割り当ててよく、ユーザコードを当該コンテナにおいて実行させてよい。あるいは、ユーザコードが、仮想マシンインスタンスの１つのローカルキャッシュにおいて利用可能である（例えば、インスタンス１５８にストアされるが、いずれの個々のコンテナにも属さない）場合、ワーカマネージャ１４０は、そのようなインスタンス上に新たなコンテナを作成してよく、当該コンテナを要求に割り当ててよく、ユーザコードを当該コンテナにロードさせて、そこで実行させてよい。

要求と関連したユーザコードが、アクティブプール１４０Ａにおけるインスタンスのいずれにおいても（例えば、コンテナ、またはインスタンスのローカルキャッシュのいずれにおいても）発見されないとワーカマネージャ１４０が判定する場合、アクティブプール１４０Ａにおけるインスタンスのいずれかが、要求と関連したユーザに現在割り当てられているかどうか、及び、現在の要求に対処するためのコンピュートキャパシティを有するかどうかを、ワーカマネージャ１４０は判定してよい。そのようなインスタンスがある場合、ワーカマネージャ１４０は、インスタンス上に新たなコンテナを作成してよく、当該コンテナを要求に割り当ててよい。あるいは、ワーカマネージャ１４０はさらに、ユーザに割り当てられるインスタンス上に既存のコンテナを構成してよく、当該コンテナを要求に割り当ててよい。例えば、既存のコンテナが、現在のユーザ要求により要求される特定のライブラリがそのコンテナにロードされている場合に、ユーザコードを実行するのに使用されてよいことを、ワーカマネージャ１４０は判定してよい。このような場合、ワーカマネージャ１４０は、当該コンテナ上へ特定のライブラリ及びユーザコードをロードしてよく、ユーザコードを実行するように当該コンテナを使用してよい。

アクティブプール１４０Ａが、ユーザに現在割り当てられているいずれのインスタンスも含まない場合、ワーカマネージャ１４０は、ウォーミングプール１３０Ａから新たな仮想マシンインスタンスをプルし、要求と関連したユーザに当該インスタンスを割り当て、当該インスタンス上に新たなコンテナを作成し、当該コンテナを要求に割り当て、ユーザコードを、当該コンテナにダウンロードさせてそこで実行させる。

いくつかの実施形態において、仮想コンピュートシステム１１０は、ユーザコードの実行を、それが（例えば、フロントエンド１２０により）受信された後すぐに開始するように適合される。時間間隔は、（例えば、ユーザと関連した仮想マシンインスタンス上のコンテナにおいて）ユーザコードの実行を開始することと、（例えば、フロントエンドにより受信される）ユーザコードを実行するための要求を受信することの間の時間差として決定されてよい。仮想コンピュートシステム１１０は、所定の期間よりも短い時間間隔内でユーザコードの実行を開始するように適合される。１つの実施形態において、所定の期間は５００ｍｓである。別の実施形態において、所定の期間は３００ｍｓである。別の実施形態において、所定の期間は１００ｍｓである。別の実施形態において、所定の期間は５０ｍｓである。別の実施形態において、所定の期間は１０ｍｓである。別の実施形態において、所定の期間は、１０ｍｓから５００ｍｓの範囲から選択される任意の値であってよい。いくつかの実施形態において、仮想コンピュートシステム１１０は、１つまたは複数の条件が満たされる場合、所定の期間よりも短い時間間隔内でユーザコードの実行を開始するように適合される。例えば、１つまたは複数の条件は、（１）要求が受信される時点で、ユーザコードがアクティブプール１４０Ａにおけるコンテナにロードされること、（２）要求が受信される時点で、ユーザコードがアクティブプール１４０Ａにおけるインスタンスのコードキャッシュにストアされること（３）要求が受信される時点で、アクティブプール１４０Ａが、要求と関連したユーザに割り当てられるインスタンスを含むこと、または（４）要求が受信される時点で、ウォーミングプール１３０Ａが、要求に対処するキャパシティを有すること、のいずれか１つを含んでよい。

ユーザコードは、図１のストレージサービス１０８などの補助サービス１０６からダウンロードされてよい。図１に示したデータ１０８Ａは、１人または複数のユーザによりアップロードされたユーザコード、そのようなユーザコードと関連したメタデータ、または、本明細書において説明される１つまたは複数の技法を実施するために仮想コンピュートシステム１１０により利用される任意の他のデータを含んでよい。ストレージサービス１０８のみが図１の実施例に示されているが、仮想環境１００は、他のレベルのストレージシステムを含んでよく、そこから、ユーザコードがダウンロードされてもよい。例えば、各インスタンスは、物理的（例えば、インスタンスが起動している物理的なコンピューティングシステムに常駐するローカルストレージ）または論理的（例えば、インスタンスとのネットワーク通信における、仮想コンピュートシステム１１０の内または外に提供されるネットワークアタッチトストレージシステム）のいずれかで、コンテナが作成されるインスタンスと関連した１つまたは複数のストレージシステムを有してよい。あるいは、コードは、ストレージサービス１０８により提供されるウェブベースのデータストアからダウロードされてよい。

ワーカマネージャ１４０が、ユーザコード実行要求に応対するのに使用され得るウォーミングプール１３０Ａに、仮想マシンインスタンスの１つをいったん配置すると、ウォーミングプールマネージャ１３０またはワーカマネージャ１４０は、ウォーミングプール１３０Ａからインスタンスを取得し、それを、要求と関連したユーザに割り当てる。割り当てられる仮想マシンインスタンスは、ウォーミングプール１３０Ａから取得され、アクティブプール１４０Ａに配置される。いくつかの実施形態において、仮想マシンインスタンスが特定のユーザにいったん割り当てられると、同一の仮想マシンインスタンスは、いずれの他のユーザの要求にサービスするのに使用できない。これは、ユーザリソースの起こり得る混合を防止することにより、セキュリティ上の利点をユーザに提供する。あるいは、いくつかの実施形態において、異なるユーザに属する（または、異なるユーザと関連した要求に割り当てられる）多数のコンテナが、１つの仮想マシンインスタンス上で共存してもよい。このようなアプローチは、利用可能なコンピュートキャパシティの利用を改善し得る。いくつかの実施形態において、仮想コンピュートシステム１１０は、別個のキャッシュを保守してよく、当該別個のキャッシュにおいて、ユーザコードは、仮想マシンインスタンスのローカルキャッシュと（例えば、ネットワーク１０４を介してアクセス可能な）ウェブベースのネットワークストレージとの間の中間レベルのキャッシングシステムとしての働きをするようにストアされる。

ユーザコードが実行された後、ワーカマネージャ１４０は、ユーザコードを実行するのに使用されるコンテナを分解して、そのコンテナが占有していたリソースを、インスタンスにおける他のコンテナのために使用されるように解放してよい。あるいは、ワーカマネージャ１４０は、コンテナを起動し続けて、同一のユーザからの追加の要求にサービスするようにコンテナを使用してよい。例えば、別の要求が、コンテナに既にロードされた同一のユーザコードと関連する場合、当該要求は、同一のコンテナに割り当てられてよく、これにより、新たなコンテナの作成及びコンテナにおけるユーザコードのローディングと関連した遅延が取り除かれる。いくつかの実施形態において、ワーカマネージャ１４０は、ユーザコードを実行するのに使用されるコンテナが作成されたインスタンスを分解してよい。あるいは、ワーカマネージャ１４０は、インスタンスを起動し続けて、同一のユーザからの追加の要求にサービスするようにインスタンスを使用してよい。ユーザコードが実行を終了した後に、コンテナ及び／またはインスタンスを起動し続けるかどうかの判定は、閾値時間、ユーザのタイプ、ユーザの平均要求量、及び／または、他の動作条件に基づくものであってよい。例えば、閾値時間が、何らのアクティビティ（例えば、コードの実行）を伴わずに経過した後（例えば、５分、３０分、１時間、２４時間、３０日等）、コンテナ及び／または仮想マシンインスタンスが停止され（例えば、削除される、終了される等）、そこに割り当てられたリソースがリリースされる。いくつかの実施形態において、コンテナが分解される前に経過した閾値時間は、インスタンスが分解される前に経過した閾値時間よりも短い。

いくつかの実施形態において、仮想コンピュートシステム１１０は、入来するコード実行要求にサービスするとき、補助サービス１０６の１つまたは複数にデータを提供してよい。例えば、仮想コンピュートシステム１１０は、モニタリング／ロギング／ビリングサービス１０７と通信してよい。モニタリング／ロギング／ビリングサービス１０７は、仮想コンピュートシステム１１０上のコンテナ及びインスタンスのステータスなど、仮想コンピュートシステム１１０から受信されるモニタリング情報を管理するためのモニタリングサービス、仮想コンピュートシステム１１０上のコンテナ及びインスタンスにより実施されるアクティビティなど、仮想コンピュートシステム１１０から受信されるロギング情報を管理するためのロギングサービス、及び、（例えば、モニタリングサービス及びロギングサービスにより管理されるモニタリング情報及び／またはロギング情報に基づいて）仮想コンピュートシステム１１０上でのユーザコードの実行と関連したビリング情報を発生させるためのビリングサービスを含んでよい。上述のように、（例えば、仮想コンピュートシステム１１０に代わって）モニタリング／ロギング／ビリングサービス１０７により実施され得るシステムレベルのアクティビティに加えて、モニタリング／ロギング／ビリングサービス１０７は、仮想コンピュートシステム１１０上で実行されるユーザコードに代わって、アプリケーションレベルのサービスを提供してよい。例えば、モニタリング／ロギング／ビリングサービス１０７は、ユーザコードが仮想コンピュートシステム１１０上で実行されることに代わって、様々な入力、出力、または他のデータ及びパラメータをモニタ及び／またはログしてよい。１つのブロックとして示されているが、モニタリング、ロギング、及びビリングサービス１０７は、別個のサービスとして提供されてもよい。モニタリング／ロギング／ビリングサービス１０７は、リソースマネージャ１５０が、仮想コンピュートシステム１５０上で様々なプログラムコードを実行するために使用されるリソースの適切な量を決定することを可能とするように、リソースマネージャ１５０と通信してよい。

いくつかの実施形態において、ワーカマネージャ１４０は、ワーカマネージャ１４０により管理されるインスタンス及びコンテナ（例えば、アクティブプール１４０Ａにおけるこれら）に関するヘルスチェックを実施してよい。例えば、ワーカマネージャ１４０により実施されるヘルスチェックは、ワーカマネージャ１４０により管理されるインスタンス及びコンテナが、（１）不適切に構成されたネットワークキング及び／または起動構成、（２）枯渇したメモリ、（３）破損したファイルシステム、（４）互換性のないカーネル、及び／または、インスタンス及びコンテナのパフォーマンスを低下させ得る任意の他の問題のうちのいずれかの問題を有するかどうかを判定することを含んでよい。１つの実施形態において、ワーカマネージャ１４０は、周期的に（例えば、５分毎、３０分毎、１時間毎、２４時間毎等）ヘルスチェックを実行する。いくつかの実施形態において、ヘルスチェックの頻度は、ヘルスチェックの結果に基づいて自動的に調整されてよい。他の実施形態において、ヘルスチェックの頻度はユーザ要求に基づいて調整されてよい。いくつかの実施形態において、ワーカマネージャ１４０は、ウォーミングプール１３０Ａにおけるインスタンス及び／またはコンテナに関する同様のヘルスチェックを実施してよい。ウォーミングプール１３０Ａにおけるインスタンス及び／またはコンテナは、アクティブプール１４０Ａにおけるこれらのインスタンス及びコンテナと一緒または別個のいずれかで管理されてよい。いくつかの実施形態において、ウォーミングプール１３０Ａにおけるインスタンス及び／またはコンテナの健全性がアクティブプール１４０Ａとは別個に管理される場合、ウォーミングプールマネージャ１３０が、ワーカマネージャ１４０の代わりに、ウォーミングプール１３０Ａにおけるインスタンス及び／またはコンテナに関して上述のヘルスチェックを実施してよい。

リソースマネージャ１５０は、仮想コンピュートシステム１１０上でユーザコードを実行するための、入来する要求を処理するために割り当てられるリソースの量を管理する。例えば、リソースマネージャ１５０は、仮想コンピュートシステム１１０上で実行される様々なプログラムコードに割り当てられる（及び、様々なプログラムコードによって使用される）コンピュートキャパシティをモニタ及び管理するように、フロントエンド１２０、ウォーミングプールマネージャ１３０、ワーカマネージャ１４０、及び／または、補助サービス１０６と通信してよい。リソースマネージャ１５０が、仮想コンピュートシステム１１０内の別個の構成要素として示されているが、リソースマネージャ１５０の機能性の一部または全部は、フロントエンド１２０、ウォーミングプールマネージャ１３０、ワーカマネージャ１４０、及び／または、補助サービス１０６によって実施されてもよい。例えば、リソースマネージャ１５０は、仮想コンピュートシステム１１０の他の構成要素の１つ内で全面的に、または、仮想コンピュートシステム１１０の他の構成要素間に分散して、実行されてよい。図１の実施例において、リソースマネージャ１５０は、リソース管理データ１５０Ａを含む。リソース管理データ１５０Ａは、仮想コンピュートシステム１１０上で実行されるプログラムコードのパフォーマンス（例えば、割り当てられるリソースの利用）をモニタ、ログ、調整、改善、及び／または、最適化するように、入来する要求の履歴（例えば、特定のプログラムコードと関連した入来する要求の量、これらの要求が受信されるピーク時間等）、入来する要求によって指定されるリソースレベルの制約、入来する要求に割り当てられるリソースの量、入来する要求により実際に利用される、割り当てられたリソースの部分、及び、リソースマネージャ１５０により使用され得る任意の他の特性またはメトリックに関するデータを含んでよい。リソース管理データ１５０Ａはまた、ユーザによって指定される、または、仮想コンピュートシステム１１０上でリソースを管理するためにリソースマネージャ１５０により決定される任意の管理ポリシーを含んでよく、これはさらに詳細に以下で説明される。

上述のように、要求それ自体が、要求と関連したプログラムコードを実行するために使用されるコンピューティングリソース（例えば、メモリ、ＣＰＵ、ストレージ、ネットワークパケット等）の量を指定してよい。そのような要求が処理され、また、仮想マシンインスタンスが当該要求と関連したユーザに割り当てられた後、リソースマネージャ１５０は、同量のリソースでコンテナを作成することにより、要求において指定されたリソースの量を、要求に割り当ててよい。例えば、要求が、５１２ＭＢのメモリが要求と関連したプログラムコードを実行するために使用されるべきであると指定する場合、リソースマネージャ１５０は、要求と関連したユーザに割り当てられる、インスタンス上で５１２ＭＢのメモリサイズを有するコンテナを作成してよい。いくつかの実施形態において、要求、プログラムコード、またはユーザと関連した他の構成情報が、プログラムコードを実行するために使用されるコンピューティングリソースの量を指定してよい。このような構成情報は、要求と共に、または、要求とは別個のいずれかで、仮想コンピュートシステム１１０に提供されてよい。リソースマネージャ１５０は、要求と関連した特定のプログラムコードのためのデフォルト設定として、要求において指定されたリソースの量を維持してよく、仮想コンピュートシステム１１０上で処理される任意の後続の要求のために同量を使用してよい。いくつかの実施形態において、１つまたは複数の後続の要求が、デフォルトの量とは異なるリソースの量が、１つまたは複数の後続の要求に割り当てられるべきであることを示す場合、リソースマネージャ１５０は、１つまたは複数の後続の要求がそのようなデフォルト設定に優先することを可能にしてよい。例えば、後続の要求は、デフォルトの量を１０％上回るリソースの量が、プログラムコードを実行するために後続の要求に割り当てられるべきであることを示してよい。代替的な量のリソースが、プログラムコードを実行するために後続の要求に割り当てられるべきであることを後続の要求が示すと判定すると、リソースマネージャ１５０は、そうした代替的な量のリソースを後続の要求に割り当てる。

いくつかの実施形態において、要求において指定されたリソースの量は、要求に割り当てられたリソースの実際の量と異なってもよい。例えば、いくつかのシナリオにおいて、仮想コンピュートシステム１１０は、要求において指定されたリソースの量を超える閾値パーセンテージである、或る量のリソースを、要求に割り当ててよい。他の状況において、仮想コンピュートシステム１１０は、要求において指定されたリソースの量より低い閾値パーセンテージである、或る量のリソースを、要求に割り当ててよい。特定のリソースをオーバーサブスクライブする（ｏｖｅｒ‐ｓｕｂｓｃｒｉｂｅ）かまたはアンダーサブスクライブする（ｕｎｄｅｒ‐ｓｕｂｓｃｒｉｂｅ）かは、特定のリソース、ユーザ、要求、及び／または、特定のリソースが提供される物理的なハードウェア（例えば、それと関連する任意のトレランスまたは差異）のタイプに基づいて判定されてよい。いくつかの実施形態において、要求に割り当てられるリソースの量は、特定のリソース、ユーザ、要求、及び／または、特定のリソースが提供される物理的なハードウェア（例えば、それと関連する任意のトレランスまたは差異）のタイプに基づいて判定される最大値（または、要求において指定された量を上回るパーセンテージ）より少なくてよく、及び／または、最小値（または、要求において指定された量を下回るパーセンテージ）よりも多くてよい。

いくつかの実施形態において、要求において指定される特定のタイプのリソース（例えば、メモリ）は、仮想コンピュートシステム１１０上で利用可能な他のタイプのリソースを割り当てるためのガイドラインとしての働きをする。例えば、５１２ＭＢのメモリが、要求と関連したプログラムコードを実行するために使用されるべきであると要求が指定し、また、ユーザに割り当てられる、インスタンス上のメモリの全体の（例えば、物理的または仮想的な最大の）量または利用可能な（例えば、他のコンテナにより現在占有されていないリソース）量が２ＧＢである場合、インスタンス上で利用可能な他のタイプのリソース（例えば、ＣＰＵ、ストレージ、ネットワークパケット等）がまた、比例した量で割り当てられる（例えば、ＣＰＵの４分の１、ストレージの４分の１、ネットワークパケットの４分の１等がコンテナに割り当てられる）。一方で、ユーザに割り当てられる、インスタンス上のメモリの全体量または利用可能な量が１ＧＢである場合、ＣＰＵの半分、ストレージの半分、ネットワークパケットの半分がコンテナに割り当てられるだろう。いくつかの実施形態において、要求により指定され得る、あるいは、コンテナに割り当てられ得るメモリの量は、６４ＭＢインクリメントにおいて、６４ＭＢから１ＧＢの範囲に及ぶ。いくつかの実施形態において、他の量が、要求によって指定されてよく、及び／または、コンテナに割り当てられてよい。メモリが実施例として使用されたが、任意の他のリソースが選択されてもよく、また、要求を処理するために（例えば、プログラムコードを実行するために）割り当てられるべきリソース全ての量を設定するためのガイドラインとして使用されてもよい。いくつかの実施形態において、１つの形態のリソース（例えば、最も理解し易く、最もユーザフレンドリーであり、最もベーシックであり、絶対数において最大、または絶対数において最小のもの）が、全ての他の形態のリソースの代表であるように選択される。要求は、特定のタイプのリソースの量の代わりに、リソース全てを割り当てるために使用され得るパーセンテージを指定してもよい。さらに、要求は、１つよりも多いリソースの量を指定してよい。

いくつかの実施形態において、リソースマネージャ１５０は、新たなコンテナを作成し、且つ、指定された量のリソースをそうしたコンテナに割り当てる代わりに、指定された量のリソースを有する既存のコンテナを配置してよく、また、当該既存のコンテナにおいてプログラムコードを実行させてよい。既存のコンテナに割り当てられたリソースの量は、指定された量のリソースに正確に一致しないが、指定された量のリソースの閾値パーセンテージ以内にある。いくつかの実施形態において、リソースマネージャ１５０は、より少ないまたはより多い量のコンピューティングリソース（複数可）を割り当てることにより、既存のコンテナをリサイズしてよく、また、特定のプログラムコードと関連したプログラムコードに対処するように、調整されたリソースサイズを有する既存のコンテナを指定してよい。リソースマネージャ１５０が既存のコンテナを動的にリサイズし得るかどうかは、プログラムコードにより使用される言語ランタイムに依存してよい。例えば、Ｊａｖａ（登録商標）ランタイムは動的なリサイジングが可能でなく、一方で、Ｐｙｔｈｏｎ（登録商標）ランタイムは可能であろう。

指定された量のリソースを有するコンテナが作成または配置された後、要求と関連したプログラムコードがコンテナにおいて実行される。コンテナに割り当てられた（例えば、ユーザによって要求される）リソースの量、及び／または、プログラムコードにより実際に利用されたリソースの量は、さらなる分析のために、（例えば、モニタリング／ロギング／ビリングサービス１０７及び／またはリソースマネージャ１５０により）ログされてよい。例えば、ログされた情報は、コンテナにおいてプログラムコードの１つまたは複数の実行の間に使用される、メモリの量、ＣＰＵサイクルの量、ネットワークパケットの量、及びストレージの量を含んでよい。さらに、ログされた情報は、リソース利用、誤り率、レイテンシ、及び、プログラムコードの実行の間に発生する任意のエラーまたは例外を含んでよい。いくつかの実施形態において、コンテナに割り当てられるリソースの量に関連した任意のエラー（例えば、メモリ不足の例外）が、特別な印でタグ付けされ、リソースマネージャ１５０によってさらに分析される。

いくつかの実施形態において、リソースマネージャ１５０は、ユーザの多数のクラスを作成または利用してよく、また、ユーザの異なるクラスのために異なるルールを適用してよい。例えば、より高度なユーザには、一層の制御（例えば、個々のリソースパラメータの制御）が与えられてよく、一方で、その他のユーザには、彼らは、１つの代表的なパラメータのみを制御することが可能とされてよく、その他のパラメータは代表的なパラメータに基づいたサイズとされてよい。

いくつかの実施形態において、リソースマネージャ１５０は、モニタリング／ロギング／ビリングサービス１０７及び／またはリソースマネージャ１５０によりログされる情報に基づいて、ユーザに、プログラムコードのパフォーマンスを改善するため、または、仮想コンピュートシステム１１０上でのプログラムコードの実行と関連したコストを削減するため、ユーザが何をし得るか関していくつかのガイダンスを提供する。例えば、リソースマネージャ１５０は、メモリ不足の例外の繰り返される発生を経験した後、ユーザが常に、特定のユーザコードを実行するためにメモリ（または他のリソース）を過少に設定しているようであるという指示をユーザに提供してよい。同様に、特定のユーザコードの呼び出しが、慢性的に、それらに割り当てられるリソースのごく一部しか使用していないと判定した後、リソースマネージャ１５０は、ユーザがメモリ（または他のリソース）を過多に設定しているであろうという指示をユーザに提供してよい。指示は、特定のリソース（複数可）が調整されるべき量を指定してよい。いくつかの実施形態において、このような指示は、閾値数のエラー、例外、または他の明確な状況（例えば、レイテンシの増加）がリソースマネージャ１５０によって処理された後に、ユーザに提供される。リソースマネージャ１５０は、ｅメール、プッシュ通知サービス、ＳＭＳ、ソーシャルネットワークサービス等を含む任意の通知機構を介して、指示を提供してよい。いくつかの実施形態において、リソースサイジング調整が必要とされるという指示は、１つまたは複数のリソースを調整すべき量が閾値の値またはパーセンテージを超える場合に、ユーザに提供される。例えば、リソースマネージャ１５０が、良好または最適のパフォーマンスを達成するために、ユーザにより指定されたメモリサイズを０．５％増加すべきであると判定する場合、リソースマネージャ１５０は、通知をユーザに全く送信しなくてもよいが、リソースマネージャ１５０が、良好または最適のパフォーマンスを達成するために、ユーザにより指定されたメモリサイズを１０％増加すべきであると判定する場合、リソースマネージャ１５０は、通知をユーザに送信してよい。

いくつかの実施形態において、リソースマネージャ１５０は、プログラムコードの実行がリソースの要求量を超えることが可能とされる場合、制限されたオーバーサブスクリプションを提供してよい。例えば、要求が６４ＭＢのメモリを指定した場合、リソースマネージャ１５０は、プログラムコードが最大７０または８０ＭＢのメモリを使用することを可能としてよい。このような場合、プログラムコードは正常に実行されてよいが、プログラムコードが、要求された量のメモリを超えており、また、プログラムコードを実行するための更なる要求が、より多い量のメモリを指定すべきであるという通知が、ユーザに提供されてよい。オーバーサブスクリプションは、閾値数の使用量の後、失効してよい。

いくつかの実施形態において、仮想コンピュートシステム１１０は、個々のコード実行要求に割り当てられるリソースの量を自動的に調整してよい。例えば、ユーザがリソースパラメータを指定し得る他の実施形態において、ユーザが適正な量のリソースを指定しそこなう場合、プログラムコードの実行は、パフォーマンス結果に悩まされることがある。例えば、要求が、６４ＭＢのメモリが、特定のプログラムコードを実行するために使用されるべきであると指定し、当該プログラムが、実際には実行のために１ＧＢを必要とする場合、ユーザは、多くの問題に遭遇するおそれがある（例えば、プログラムコードが、単に実行できないおそれがある）。仮想コンピュートシステム１１０が、要求において指定されたリソースの量を調整するためにユーザに依拠する場合、問題がユーザによって対処されるまで、仮想コンピュートシステム１１０は、数千または数百万の失敗した要求を受信することがある。このようなシナリオにおいて、要求において指定されたリソースの量が不十分であると判定する際、リソースマネージャ１５０は、特定のプログラムコードを実行するための、入来する要求に割り当てられるリソースの量を自動的に調整してよい。いくつかの実施形態において、閾値数のエラー、例外、または他の明確な状況（例えば、レイテンシの増加）がリソースマネージャ１５０によって処理された後に、このような調整が成される。それゆえ、自動的なリソース調整がリソースマネージャ１５０によって成されても、最初のいくつかの要求は失敗することがあるが、後続の要求は、ユーザの介入を伴わなくとも、所望の結果を最終的に生成し得る。

いくつかの実施形態において、リソースマネージャ１５０は、個々のプログラムコードを実行するために、リソースサイジングを改善するようにコード特有の特性を利用してよい。例えば、画像処理を扱うプログラムコードは、多くのメモリを要求することがあり、一方で、データベースアクセスを作成するプログラムコードは、同量のメモリを必要としないであろう。別の実施例において、特定のプログラムコードにとっては、６４ＭＢが大抵の場合に十分であろうが、仮想コンピュートシステム１１０が、毎晩午後８時に、ユーザと関連したコード実行要求を一気に受信するかもしれず、このため、リソースマネージャ１５０は、ユーザと関連した要求に対処するコンテナ及び／またはインスタンスに、より多くのメモリを割り当てることがある。このようなコード特有の特性は、リソースマネージャ１５０によって維持されてよく、個々のプログラムコードのリソースサイジングは、それに応じて調整されてよい。

いくつかの実施形態において、リソースマネージャ１５０は、最大量のリソースをプログラムコードに初めに割り当ててよく、プログラムコードを実行した後に、プログラムコードが実際には最大量の１／１０を使用しているとリソースマネージャ１５０が判定する場合、リソースマネージャ１５０は、プログラムコードを実行するための後続の要求に、最大量の半分を割り当ててよい。プログラムコードが最大量の１／１０を使用しているとリソースマネージャ１５０が依然として判定する場合、リソースマネージャ１５０はさらに、プログラムコードに割り当てられたリソースの量を半分に削減してよい。プログラムコードがプログラムコードに割り当てられたリソースのかなりの部分（例えば、５０％、７５％、または別の閾値の値）を使用するまで、リソースマネージャ１５０はこうしたプロセスを繰り返してよい。

いくつかの実施形態において、ユーザは、リソースマネージャ１５０の挙動を規定するリソース管理ポリシーを指定してよい。例えば、実に価格に敏感なユーザは、そのようにすることが彼または彼女のコストを最小化する場合、喜んで時折のエラーを経験するままにするであろう。それゆえ、このようなユーザは、現在指定された量のリソースが、時折、メモリ不足エラーという結果となっても、彼または彼女のプログラムコードを実行するために割り当てられるリソースの量を増加させることを望まないことがある。一方で、非常にエラーに敏感なユーザは、エラーまたは誤り（例えば、メモリ不足エラー、非常に高いレイテンシ、またはいくつかの他の問題）が起こるのを回避するために、どんな手段を取るのも厭わないであろう。このようなユーザは、プログラムコードを実行するために割り当てられるリソースが時として過少利用されていても、彼または彼女のプログラムコードが遭遇するエラーの数を最小にすることを望むことがある。いくつかの実施形態において、ユーザは、コスト、利用、リソースの量等のストップリミット（例えば、下限及び／または上限）を指定してよい。ユーザは、そうしたストップリミットを、指定された時間期間でのみそれらが適用可能であるようにさらに限定してよい。例えば、ユーザは、ユーザがプログラムコードを実行させるのに費やしたい金額の最小量及び最大量を指定してよいが、ユーザは、各四半期の最終週の間、リミットが適用されるべきでないとさらに指定してよい。

いくつかの実施形態において、リソースマネージャ１５０は、一定のリソースを、そのようなリソースがコード実行要求によって十分に利用されていないとリソースマネージャ１５０が判定する場合、選択的にオーバーサブスクライブしてよい。例えば、リソースマネージャ１５０は、１ＧＢのメモリを、４ＧＢの仮想または物理メモリを有する仮想マシンインスタンス上の５つの異なるコンテナに割り当ててよい。オーバーサブスクリプションの程度は、１つのインスタンス上に作成されたこれらのコンテナが、インスタンスのリソースの最大量を集合的に使い切るかもしれない可能性に基づくものであってよい。いくつかの実施形態において、ユーザは、割引値段で、オーバーサブスクライブされたリソースの利用を選択するという選択肢を与えられてよい。

いくつかの実施形態において、要求は、任意のリソースレベルの制約を指定しなくてもよいが、代わりに、リソースの量が仮想コンピュートシステム１１０によって自動的に判定されること、及び、仮想コンピュートシステム１１０により判定されたリソースの量がユーザに伝えられること（例えば、この結果、ユーザは、ユーザの要求にサービスするために割り当てられているリソースの量を知る）を要求してよい。あるいは、要求は、ユーザコードを実行するために使用されるべきリソースの量を指定してよいが、また、要求された量のリソースが、コード実行パフォーマンスに著しく影響を及ぼすことなく、（例えば、他のユーザとそれをシェアすることにより）オーバーサブスクライブされ得ると仮想コンピュートシステム１１０が判定する場合、仮想コンピュートシステム１１０は、より少なく（例えば、指定された量のリソースが通常かかるコストよりも少なく）ユーザにチャージすることによって、そのようにし得ることを示してよい。

いくつかの実施形態において、特定のコンテナに割り当てられるリソースの量は、当該特定のコンテナを縮小または拡張することによって（例えば、既存のコンテナに割り当てられるリソースの量を修正することによって）調整される。あるいは、リソースの量は、調整された量のリソースを有する新たなコンテナを作成すること、及び、当該新たなコンテナに何らかの将来的な要求を提供することにより古いコンテナを消滅させることによって調整されてよい。いくつかの実施形態において、リサイジングは、プログラムコードにより使用される特定の言語ランタイムの特性に基づいて実施される。（例えば、動的なリソースリサイジングができるものもあれば、できないものもある）。

リソースマネージャ１５０は、ユーザコードを実行するのに使用されるコンテナをサイジングする（例えば、コンテナに割り当てられるべきリソースの量を決定する）ためのリソースサイジングユニットと、リソースの量を、仮にするとしてもどの程度調整すべきかに関する通知をユーザに提供するためのリソースガイダンスユニットとを含んでよい。リソースマネージャ１５０の例示的な構成が、図２を参照して以下でさらに詳細に説明される。

図２は、仮想コンピュートシステム１１０における仮想マシンインスタンスを管理するコンピューティングシステム（リソースマネージャ１５０と呼ばれる）の一般的なアーキテクチャを表す。図２に表されたリソースマネージャ１５０の一般的なアーキテクチャは、本開示の態様を実行するのに使用され得るコンピュータハードウェア及びソフトウェアモジュールの構成を含む。リソースマネージャ１５０は、図２に示したものよりもさらに多くの（または少ない）要素を含んでよい。しかしながら、可能な開示を提供するため、これらの一般に従来の要素の全てが示される必要はない。図示するように、リソースマネージャ１５０は、処理ユニット１９０、ネットワークインターフェース１９２、コンピュータ可読媒体ドライブ１９４、入力／出力デバイスインターフェース１９６を含み、それらの全てが、コミュニケーションバスを介して互いに通信してよい。ネットワークインターフェース１９２は、１つまたは複数のネットワークまたはコンピューティングシステムへの接続を提供してよい。処理ユニット１９０は、それゆえ、他のコンピューティングシステムまたはサービスから、ネットワーク１０４を介して情報及び命令を受信してよい。処理ユニット１９０はまた、メモリ１８０へ及びメモリ１８０から通信してよく、入力／出力デバイスインターフェース１９６を介して随意のディスプレイ（図示せず）のための出力情報をさらに提供してよい。入力／出力デバイスインターフェース１９６はまた、随意の入力デバイス（図示せず）から入力を受け取ってよい。

メモリ１８０は、本開示の１つまたは複数の態様を実行するために、処理ユニット１９０が実行する（いくつかの実施形態において、モジュールとしてグループ化された）コンピュータプログラム命令を含んでよい。メモリ１８０は、一般に、ＲＡＭ、ＲＯＭ、及び／または、他の永続的な、補助的または非一時的なコンピュータ可読媒体を含む。メモリ１８０は、リソースマネージャ１５０の一般的な管理及び操作において処理ユニット１９０による使用のためのコンピュータプログラム命令を提供するオペレーティングシステム１８４をストアしてよい。メモリ１８０はさらに、本開示の態様を実行するためのコンピュータプログラム命令及び他の情報を含んでよい。例えば、１つの実施形態において、メモリ１８０は、例えば、コンピューティングデバイスにインストールされたブラウザまたはアプリケーションなど、ナビゲーション及び／またはブラウジングインターフェースを介して、コンピューティングデバイス上に表示するためのユーザインターフェース（及び／またはそれに対する命令）を生成するユーザインターフェースユニット１８２を含む。加えて、メモリ１８０は、例えば、ユーザプログラムコード及び／またはライブラリにアクセスするために、１つまたは複数のデータリポジトリ（図示せず）を含んでよく、及び／または、これと通信してよい。

ユーザインターフェースユニット１８２に加えて、及び／または、それと関連して、メモリ１８０は、処理ユニット１９０により実行され得るリソースサイジングユニット１８６及びリソースガイダンスユニット１８８を含んでよい。１つの実施形態において、ユーザインターフェースユニット１８２、リソースサイジングユニット１８６、及びリソースガイダンスユニット１８８は、個々にまたは集合的に、さらに以下で説明するように、例えば、仮想コンピュートシステム１１０上でのプログラムコードの実行のモニタリング及びロギング、特定のコンテナ及び／または要求に割り当てられるリソースの量を調整する必要性を判定すること、リソースの量を調整する必要性に関してユーザに通知を提供すること、リソースの量を自動的に調整すること等、本開示の様々な態様を実行する。

リソースサイジングユニット１８６は、仮想コンピュートシステム１１０上でのユーザコードの実行をモニタし、ユーザコードを実行するために、指定された量のリソース有するコンテナを提供し、当該コンテナに割り当てられるリソースの量を調整する。例えば、リソースサイジングユニット１８６が、特定のプログラムコードを実行するための要求が常にメモリ不足エラーを受けていると判定する場合、リソースサイジングユニット１８６は、特定のプログラムコードを実行するための後続の要求に割り当てられるメモリの量を増加させてよい。一方で、リソースサイジングユニット１８６が、特定のプログラムコードを実行するための要求が常に、要求に割り当てられるリソースのごく一部しか使用していないと判定する場合、リソースサイジングユニット１８６は、特定のプログラムコードを実行するための後続の要求に割り当てられるメモリの量を減少させてよい。

リソースガイダンスユニット１８８は、ユーザと関連した要求にサービスするために割り当てられているリソースの量を調整する必要性に関して、ユーザに通知を提供する。例えば、通知は、ユーザが常に、特定のプログラムコードを実行するために、過少または過多である量を指定していることを示してよい。通知は、改善された、または最適のパフォーマンスのために、リソースの量をどの程度調整すべきかをさらに指定してよい。

リソースサイジングユニット１８６及びリソースガイダンスユニット１８８がリソースマネージャ１５０の一部として図２に示されているが、他の実施形態において、リソースサイジングユニット１８６及びリソースガイダンスユニット１８８の全てまたは一部は、仮想コンピュートシステム１１０及び／または別のコンピューティングデバイスの他の構成要素によって実行されてもよい。例えば、本開示の一定の実施形態において、仮想コンピュートシステム１１０と通信する別のコンピューティングデバイスは、リソースマネージャ１５０の一部として示されるモジュール及び構成要素と同様に作動するいくつかのモジュールまたは構成要素を含んでよい。

次に図３に注目すると、仮想コンピュートシステム１１０の１つまたは複数の構成要素（例えば、リソースマネージャ１５０）により実行されるルーチン３００が説明される。ルーチン３００が、リソースマネージャ１５０による実施態様に関して説明されるが、当業者は、代替的な構成要素がルーチン３００を実行してよいこと、または、ブロックの１つまたは複数が、異なる構成要素により、もしくは分散して実行されてよいことを理解するであろう。

説明的なルーチン３００のブロック３０２で、リソースマネージャ１５０は、仮想コンピュートシステム１１０上でプログラムコードを実行するための要求に基づいて、第１のコンピューティングリソースのユーザ指定の量を決定する。例えば、第１のコンピューティングリソースは、仮想コンピュートシステム１１０上でプログラムコードを実行するために使用され得る、メモリ、ＣＰＵ、ディスク空間、または任意の他のコンピューティングリソースであってよい。仮想コンピュートシステム１１０上でプログラムコードを実行するための要求は、プログラムコードを実行するためにどのくらいのリソースを割り当てるべきかを示してよい。

次に、ブロック３０４で、リソースマネージャ１５０が、第１のコンピューティングリソースのユーザ指定の量に基づいて、第２のコンピューティングリソースの対応する量を決定する。例えば、リソースマネージャ１５０は、第１のコンピューティングリソースのユーザ指定の量と、要求に割り当てられ得る、第１のコンピューティングリソースの最大量との比を算出することにより、第２のコンピューティングリソースの対応する量を決定してよい。ユーザ指定の量が５１２ＭＢのメモリであり、要求に割り当てられ得るメモリの最大量が１ＧＢである場合、リソースマネージャ１５０は、対応する量は、要求に割り当てられ得る第２のコンピューティングリソースの最大量の２分の１とすべきであると判定してよい。例えば、第２のコンピューティングリソースがディスク空間であり、８ＧＢのディスク空間が割り当てに利用可能である場合、リソースマネージャ１５０は、対応する量は４ＧＢとすべきであると判定してよい。

ブロック３０６で、リソースマネージャ１５０は、第１のコンピューティングリソース（例えば、メモリ）のユーザ指定の量、及び、第２のコンピューティングリソース（例えば、ディスク空間）の対応する量を、プログラムコードを実行するために要求に割り当てる。上記の実施例において、リソースマネージャ１５０は、仮想コンピュートシステム上で利用可能な仮想マシンインスタンスの１つにコンテナを作成してよく、その場合、コンテナは５１２ＭＢのメモリ及び４ＧＢのディスク空間を割り当てられる。第１及び第２のコンピューティングリソースが図３の実施例において使用されたが、追加のリソースが使用されてもよく、そのような追加のリソースはまた、第１のコンピューティングリソースのユーザ指定の量と最大量との比に従ったサイズとされてよい。

図３のルーチン３００がブロック３０２〜３０６を参照して上述されたが、本明細書において説明される実施形態は、そのように限定されず、１つまたは複数のブロックが、本開示の精神から逸脱することなく、省略、修正、または交換されてよい。

次に図４に注目すると、仮想コンピュートシステム１１０の１つまたは複数の構成要素（例えば、リソースマネージャ１５０）により実行されるルーチン４００が説明される。ルーチン４００が、リソースマネージャ１５０による実施態様に関して説明されるが、当業者は、代替的な構成要素がルーチン４００を実行してよいこと、または、ブロックの１つまたは複数が、異なる構成要素により、もしくは分散して実行されてよいことを理解するであろう。

説明的なルーチン４００のブロック４０２で、リソースマネージャ１５０は、仮想コンピュートシステム１１０上でプログラムコードを実行するための要求に基づいて、コンピューティングリソースのユーザ指定の量を決定する。例えば、コンピューティングリソースは、仮想コンピュートシステム１１０上でプログラムコードを実行するために使用され得る、メモリ、ＣＰＵ、ディスク空間、または任意の他のコンピューティングリソースであってよい。ユーザ指定の量は特定のリソース（例えば、メモリ）の量であってよく、そうした特定のリソースの量は、プログラムコードを実行するためにどのくらいの特定のリソースを割り当てるべきかを指定する要求において示される（例えば、要求に含まれ、あるいは、要求に含まれる情報に基づいて判定可能である）。例えば、プログラムコードの開発者は、コード実行要求において、彼または彼女のプログラムコードを実行するためにどのくらいのメモリ（または他のコンピューティングリソース）を割り当てるべきかを指定してよい。

次に、ブロック４０４で、リソースマネージャ１５０は、プログラムコードを実行するためにコンピューティングリソースのユーザ指定の量を割り当てる。例えば、リソースマネージャ１５０は、ユーザと関連し、且つ、アクティブプール１４０Ａ内にあるインスタンスにおいて、コンピューティングリソースのユーザ指定の量を有するコンテナを作成してよい。別の実施例において、リソースマネージャ１５０は、ウォーミングプール１３０Ａからインスタンスを選択し、当該選択されたインスタンスをユーザに割り当て、当該選択されたインスタンスにおいて、コンピューティングリソースのユーザ指定の量を有するコンテナを作成してよい。

ブロック４０６で、リソースマネージャ１５０は、プログラムコードの１つまたは複数の実行の間、プログラムコードによるコンピューティングリソースの使用量をモニタする。例えば、リソースマネージャ１５０は、プログラムコードを、要求に対処するように指定されたコンテナ上にロードさせてよく、また、プログラムコードを当該コンテナにおいて実行させてよい。リソースマネージャ１５０は、プログラムコードの１つまたは複数の実行の間、１つまたは複数のパフォーマンス特性をモニタしてよい。このようなパフォーマンス特性は、誤り率、リソース利用、レイテンシ、使用されるリソースの％、ユーザにより要求されるリソースの％等を含んでよい。

ブロック４０８で、リソースマネージャ１５０は、プログラムコードによるコンピューティングリソースの使用量をユーザ指定の量と比較し、ブロック４１０で、リソースマネージャ１５０は、当該比較に基づいて、プログラムコードを実行するために割り当てられる、コンピューティングリソースのユーザ指定の量を調整すべきであると判定する。例えば、ユーザが５１２ＭＢのメモリを要求したが、プログラムコードの１つまたは複数の実行の間、平均して６４ＭＢしか使用されなかった場合、リソースマネージャ１５０は、ユーザ指定の量が、プログラムコードのパフォーマンスに著しく影響を及ぼすことなく削減され得ると判定してよい。一方で、ユーザが５１２ＭＢのメモリを要求し、また、プログラムコードの１つまたは複数の実行の間、要求された量のほとんど全てが使用中であった場合、リソースマネージャ１５０は、過剰利用の問題を解決するために、ユーザ指定の量を増加すべきであると判定してよい。

ブロック４１２で、リソースマネージャ１５０は、ユーザ指定の量をどの程度調整すべきかという指示を提供する。例えば、リソースマネージャ１５０は、ユーザ指定の量を適切な量だけ増加または削減すべきであることを示すｅメール通知をユーザに提供してよい。

図４のルーチン４００がブロック４０２〜４１２を参照して上述されたが、本明細書において説明される実施形態はそのように限定されず、１つまたは複数のブロックが、本開示の精神から逸脱することなく、省略、修正、または交換されてよい。例えば、ルーチン４００が１つのコンピューティングリソース（例えば、メモリ）に関して説明されたが、同様の技法は、残りのリソース次元（例えばＣＰＵ、ネットワーク、ディスク等）のそれぞれ上で実行されてよい。さらに、ルーチン４００が、リソースベースで、１つのコンピューティングリソースをモニタ及び比較（例えば、要求された量のメモリ対実際に使用された量のメモリの比較、要求された量の処理能力対実際に使用された量の処理能力の比較等）するものとして説明されたが、同様の技法は、複合物ベースでルーチン４００を実施するのに使用されてもよい。例えば、リソースマネージャ１５０は、要求と関連した最も制約されたリソースの、要求されたまたは割り当てられた量を、要求と関連した、プログラムコードにより使用される最も制約されたリソースの実際の量と比較してよく、また、最も制約されたリソースの要求されたまたは割り当てられた量が、プログラムコードにより使用される最も制約されたリソースの実際の量より少ないまたはより多い閾値パーセンテージ内にある場合、ブロック４１２における指示が、ユーザに提供されてよい。別の実施例において、リソースマネージャ１５０は、リソース次元のそれぞれについての利用の平均的なパーセンテージを算出してよく、平均的なパーセンテージが閾値利用値より低いまたはより高い場合（例えば、１０％より低い、９０％より高い等）、ユーザに指示を提供してよい。ユーザに提供される指示はまた、コンピューティングリソースのそれぞれの過剰使用または過少使用の分析を含んでよい。例えば、リソースマネージャ１５０は、次を述べる指示を提供してよい。「貴殿は現在、５１２ＭＢのリソースサイジングダイアルをお持ちです。貴殿はそれ以上のメモリを使用したことがないので、これはメモリパフォーマンスに適したものです。しかしながら、弊社は、貴殿が現在の設定でネットワークリソースをたびたび使い果たしていると通知してきました。貴殿は、一層多くのネットワークリソースを獲得し、改善されたコード実行パフォーマンスを達成するために、リソースサイジングダイアルを１０％増加するとよいでしょう。」

次に図５に注目すると、仮想コンピュートシステム１１０の１つまたは複数の構成要素（例えば、リソースマネージャ１５０）により実行されるルーチン５００が説明される。ルーチン５００が、リソースマネージャ１５０による実施態様に関して説明されるが、当業者は、代替的な構成要素がルーチン５００を実行してよいこと、または、ブロックの１つまたは複数が異なる構成要素により、または分散して実行されてよいことを理解するであろう。

説明的なルーチン５００のブロック５０２で、リソースマネージャ１５０は、プログラムコードを実行するためにコンピューティングリソースの第１の量を割り当てる。例えば、リソースマネージャ１５０は、ユーザと関連し、且つ、アクティブプール１４０Ａ内にあるインスタンスにおいて、コンピューティングリソースの第１の量を有するコンテナを作成してよい。別の実施例において、リソースマネージャ１５０は、ウォーミングプール１３０Ａからインスタンスを選択し、当該選択されたインスタンスをユーザに割り当て、当該選択されたインスタンスにおいてコンピューティングリソースの第１の量を有するコンテナを作成してよい。コンピューティングリソースは、仮想コンピュートシステム１１０上でプログラムコードを実行するために使用され得る、メモリ、ＣＰＵ、ディスク空間、または任意の他のコンピューティングリソースであってよい。第１の量は、要求に含まれる情報、及び／または、要求に含まれるそうした情報に基づいて確認可能な情報に基づいて、リソースマネージャ１５０よって判定されてよい。このような情報は、プログラムコード、ユーザタイプ（例えば、大規模ユーザまたは小規模ユーザ）、プログラムコードの特性（例えば、回線の数、高額通話の数等）等をコード化するのに使用されるプログラミング言語を含んでよい。

次に、ブロック５０４で、リソースマネージャ１５０は、プログラムコードの１つまたは複数の実行の間、プログラムコードによるコンピューティングリソースの使用量をモニタしてよい。例えば、リソースマネージャ１５０は、プログラムコードを、要求に対処するように指定されたコンテナ上にロードさせてよく、また、プログラムコードを当該コンテナにおいて実行させてよい。リソースマネージャ１５０は、プログラムコードの１つまたは複数の実行の間、１つまたは複数のパフォーマンス特性をモニタしてよい。このようなパフォーマンス特性は、誤り率、リソース利用、レイテンシ、使用されるリソースの％、ユーザにより要求されるリソースの％等を含んでよい。

ブロック５０６で、リソースマネージャ１５０は、プログラムコードによるコンピューティングリソースの使用量に基づいて、プログラムコードを実行するために割り当てられるコンピューティングリソースの第１の量を調整すべきであると判定する。例えば、ブロック５０２で５１２ＭＢのメモリがプログラムコードを実行するために割り当てられたが、プログラムコードの１つまたは複数の実行の間、平均して６４ＭＢしか使用されなかった場合、リソースマネージャ１５０は、プログラムコードを実行するために割り当てられ量が、プログラムコードのパフォーマンスに著しく影響を及ぼすことなく削減され得ると判定してよい。一方で、５１２ＭＢのメモリがプログラムコードを実行するために割り当てられ、また、プログラムコードの１つまたは複数の実行の間、割り当てられた量のほとんど全てが使用中であった場合、リソースマネージャ１５０は、過剰利用の問題を解決するために、プログラムコードを実行するために割り当てられた量を増加すべきであると判定してよい。

ブロック５０８で、リソースマネージャ１５０は、第１の量とは異なる、コンピューティングリソースの第２の量を決定し、ブロック５１０で、リソースマネージャ１５０は、プログラムコードを実行するためにコンピューティングリソースの第２の量を割り当てる。５１２ＭＢが割り当てられ、且つ、６４ＭＢが平均して使用された実施例において、リソースマネージャ１５０は、割り当てられたメモリの量が、プログラムコードのパフォーマンスに影響を及ぼすことなく１２８ＭＢに安全に削減され得ると判定してよく、また、プログラムコードを実行するために（例えば、プログラムコードの将来的な実行のために）１２８ＭＢを割り当ててよい。

図５のルーチン５００がブロック５０２〜５１２を参照して上述されたが、本明細書において説明される実施形態はそのように限定されず、１つまたは複数のブロックが、本開示の精神から逸脱することなく、省略、修正、または交換されてよい。例えば、図４に関して述べられたように、ルーチン５００が１つのコンピューティングリソース（例えば、メモリ）に関して説明されたが、同様の技法は、残りのリソース次元（例えば、ＣＰＵ、ネットワーク、ディスク等）のそれぞれ上で実施されてよい。さらに、ルーチン５００は、リソースベースで、１つのコンピューティングリソースをモニタ及び比較（例えば、現在割り当てられた量のメモリ対実際に使用された量のメモリの比較、現在割り当てられた量の処理能力対実際に使用された量の処理能力の比較等）するものとして説明されたが、同様の技法は、複合物ベースでルーチン５００を実施するのに使用されてもよい。例えば、リソースマネージャ１５０は、要求と関連した最も制約されたリソースの、要求されたまたは割り当てられた量を、要求と関連した、プログラムコードにより使用される最も制約されたリソースの実際の量と比較してよく、また、ブロック５０６における決定は、最も制約されたリソースの要求されたまたは割り当てられた量が、プログラムコードにより使用される最も制約されたリソースの実際の量より少ないまたはより多い閾値パーセンテージ内にあるかどうかに基づくものであってよい。別の実施例において、リソースマネージャ１５０は、リソース次元のそれぞれについての利用の平均的なパーセンテージを算出してよく、また、平均的なパーセンテージが閾値利用値より低いまたはより高いかどうか（例えば、１０％より低い、９０％より高い等）に基づいて決定してよい。

図６〜図８を参照すると、例示的な実施形態に従った、リソースマネージャ１５０により実施されるリソースリサイジングが示される。図６の実施例において、コンテナ１５８Ａが、特定のプログラムコードと関連した入来するコード実行要求を処理するために利用されている。図６に示すように、コンテナ１５８Ａは、平均的なリソース利用が２７％である。例えば、特定のプログラムコードは、コンテナ１５８Ａにおける特定のプログラムコードの１つまたは複数の実行の間、コンテナ１５８Ａに割り当てられたリソース（複数可）のうちの２７％を利用している。リソースマネージャ１５０は、リソース利用を閾値の値（例えば、７５％）と比較してよく、また、現在のリソース利用は少な過ぎであり、コンテナ１５８Ａに割り当てられたリソース（複数可）の量を削減すべきであると判定してよい。

図７において、リソースマネージャ１５０は、特定のプログラムコードを実行するために、コンテナ１５８Ａに割り当てられたリソース（複数可）の量を（例えば、インスタンス１５８と関連したユーザの要求で、または、利用に基づいてリソースマネージャ１５０により成される判定に基づいて）削減しており、リソース利用は、コンテナ１５８Ａにおける特定のプログラムコードの１つまたは複数の追加の実行の後、４０％に増加している。既存のコンテナ（例えば、コンテナ１５８Ａ）のリソースサイジングが調整されたが、別の実施形態において、そこに割り当てられるリソース（複数可）の調整された量を有する新たなコンテナが代わりに作成されてもよく、既存のコンテナは空にされてもよい。図８に示すように、コンテナ１５８Ａに割り当てられたリソース（複数可）の量は、さらに、リソース利用を８０％に改善するように調整されている。リソースマネージャ１５０は、リソース利用レベルを閾値の値（例えば７５％）と比較して、さらなるリソースリサイジングは必要でないと判定してよく、また、リソースマネージャ１５０が、さらなるリサイジングが必要とされると後に判定するまで、コンテナ１５８Ａのリソースレベルを現在のレベルで維持してよい。図６〜図８に示した他の構成要素は図１に示したものと同一であり、それゆえ、その詳細は簡潔さのために省略される。

図９〜図１１を参照すると、別の例示的な実施形態に従った、リソースマネージャ１５０により実施されるリソースリサイジングが示される。図９の実施例において、コンテナ１５９Ａは、特定のプログラムコードと関連した入来するコード実行要求を処理するために利用されている。図９に示すように、コンテナ１５９Ａは、平均的な誤り率が９０％である。例えば、特定のプログラムコードの実行の９０％が、１つまたは複数のエラーを生成したおそれがあり、または、正常に実行するのに失敗したおそれがある。リソースマネージャ１５０は、リソース利用を閾値の値（例えば、５％）と比較してよく、また、現在の誤り率が高すぎであり、コンテナ１５９Ａに割り当てられたリソース（複数可）の量を増加すべきであると判定してよい。

図１０において、リソースマネージャ１５０は、特定のプログラムコードを実行するために、コンテナ１５９Ａに割り当てられたリソース（複数可）の量を（例えば、インスタンス１５９と関連したユーザの要求で、または、誤り率に基づいてリソースマネージャ１５０により成される判定に基づいて）増加しており、誤り率は、コンテナ１５９Ａにおける特定のプログラムコードの１つまたは複数の追加の実行の後、２０％まで減少している。既存のコンテナ（例えば、コンテナ１５９Ａ）のリソースサイジングが調整されたが、別の実施形態において、そこに割り当てられるリソース（複数可）の調整された量を有する新たなコンテナが代わりに作成されてもよく、既存のコンテナは空にされてもよい。図１１に示すように、コンテナ１５９Ａに割り当てられたリソース（複数可）の量は、誤り率を３％に改善するためにさらに調整されている。リソースマネージャ１５０は、誤り率を閾値の値（例えば、５％）と比較して、さらなるリソースリサイジングは必要でないと判定してよく、また、リソースマネージャ１５０が、さらなるリサイジングが必要とされると後に判定するまで、コンテナ１５９Ａのリソースレベルを現在のレベルで維持してよい。図９〜図１１に示した他の構成要素は、図１に示したものと同一であり、それゆえ、その詳細は簡潔さのために省略される。

本開示において説明された機能の全てが、開示された構成要素の１つまたは複数の物理的なプロセッサ及びモバイル通信デバイスにより実行されるソフトウェアにおいて具体化されてよいことが、当業者または他の者によって理解される。ソフトウェアは、任意のタイプの不揮発性ストレージに永続的に記憶されてよい。

とりわけ「ｃａｎ」、「ｃｏｕｌｄ」、「ｍｉｇｈｔ」、または「ｍａｙ」などの条件付きの言い回しは、そうではないと明確に述べられる場合を除き、あるいは、使用される文脈において理解される場合を除き、概して、一定の実施形態が、他の実施形態が含まない一定の特徴、要素、及び／または、ステップを含むことを伝えるように意図される。それゆえ、そのような条件付きの言い回しは、概して、特徴、要素、及び／または、ステップが１つまたは複数の実施形態に多少なりとも必要とされること、または、１つまたは複数の実施形態が、ユーザ入力またはプロンプトにより、またはそれらを伴わずに、これらの特徴、要素、及び／または、ステップが、任意の特定の実施形態において含まれるかどうか、または実行すべきものであるかどうかを決定するための論理を必ず含むことを暗示するように意図されない。

本明細書において説明される流れ図における、及び／または、添付の図面に表された、いずれのプロセスの説明、要素、またはブロックも、プロセスにおける特定の論理的機能またはステップを実行するための１つまたは複数の実行可能な命令を含むコードのモジュール、セグメント、または一部を潜在的に示すものとして理解すべきである。代替的な実施態様が、本明細書において説明される実施形態の範囲内に含まれ、代替的な実施形態において、当業者に理解されるように、含まれる機能性に応じて、要素または機能が削除されてもよく、実質的に同時実行または逆の順番を含め、図示または説明されたもとは違う順番で実行されてもよい。上述のデータ及び／または構成要素は、コンピュータ可読媒体にストアされてよく、また、ＣＤ‐ＲＯＭ、ＤＶＤ‐ＲＯＭ、またはネットワークインターフェースなどのコンピュータにより実行可能な構成要素をストアするコンピュータ可読ストレージ媒体と関連した駆動機構を使用してコンピューティングデバイスのメモリにロードされてよいことがさらに理解されよう。さらに、構成要素及び／またはデータは１つのデバイスに含まれてもよく、または、任意の方法で分散されてもよい。従って、汎用のコンピューティングデバイスは、上述の様々なデータ及び／または構成要素の処理及び／または実行により、本開示のプロセス、アルゴリズム及び方法論を実行するように構成されてよい。

上述の実施形態に対して多くの変形または修正が成されてよく、それらの要素が、他の許容可能な実施例に存在するものとして理解すべきであることを強調すべきである。全てのそのような修正及び変形は、本明細書において、本開示の範囲内に含まれるように、及び、以下の特許請求の範囲によって保護されるように意図される。

Claims (20)

1. システムであって、
   仮想コンピュートシステムを含み、前記仮想コンピュートシステムが、特定のコンピュータにより実行可能な命令を実行する１つまたは複数のハードウェアコンピューティングデバイスを含み、且つ、少なくとも、
   １つまたは複数の物理的なコンピューティングデバイス上で複数の仮想マシンインスタンスを保守し、
   前記仮想コンピュートシステム上でユーザと関連したプログラムコードを実行するため、前記プログラムコードと、前記プログラムコードに関連した前記ユーザと、前記プログラムコードを実行するために使用される前記仮想コンピュートシステムで使用可能なコンピューティングリソースの第１の量と、を示す情報を含む要求を受信し、
   前記プログラムコードを実行するために使用される、前記複数の仮想マシンインスタンスから、少なくとも前記第１の量のコンピューティングリソースを有する、仮想マシンインスタンスを選択し、
   前記選択された仮想マシンインスタンスにおいて、前記コンピューティングリソースの第１の量を有するコンテナを作成し、
   前記ユーザと関連した前記プログラムコードを、前記コンテナ上へロードさせて、前記コンテナにおいて実行させ、
   前記選択された仮想マシンインスタンスにおいて作成された前記コンテナにおいて、前記プログラムコードを実行する間、前記プログラムコードによる前記コンピューティングリソースの使用量をモニタし、
   前記プログラムコードによる前記コンピューティングリソースの前記使用量に基づいて、前記要求で示された第１の量が前記プログラムコードを実行するための閾値のリソース調整条件を満たすか否か判定し、
   プログラムコードと、前記プログラムコードに関連した前記ユーザと、前記プログラムコードを実行するために使用される前記仮想コンピュートシステムで使用可能なコンピューティングリソースの第１の量と、を示す情報を含む後続の要求を受け取ったことに応答し、前記選択した仮想マシンインスタンスに、前記後続の要求で示された前記第１の量とは異なるコンピューティングリソースの第２の量を有する、追加のコンテナを作成し、
   前記コンピューティングリソースの前記第２の量を有する前記追加のコンテナで、前記プログラムコードを実行させる、
   ように構成される、前記システム。
2. 請求項１に記載のシステムであって、前記仮想コンピュートシステムはさらに、
   前記要求で示されたユーザ指定の量、または前記要求、前記プログラムコードまたは前記仮想コンピュートシステム上で前記プログラムコードを実行する前記ユーザに関連する他の構成情報に基づいて、前記第１の量を決定し、
   前記プログラムコードによる前記コンピューティングリソースの前記使用量と、前記要求において示された前記ユーザ指定の量とを比較し、
   前記第１の量をどの程度調整すべきかという指示を提供する
   ように構成される、前記システム。
3. 請求項２に記載のシステムであって、前記指示を提供することが、（ａ）前記第１の量を増加すべきであると示すこと、（ｂ）前記第１の量を、第１の調整量だけ増加すべきであると示すこと、（ｃ）前記第１の量を削減すべきであると示すこと、または、（ｄ）前記第１の量を、第２の調整量だけ削減すべきであると示すこと、のうちの１つを含む、前記システム。
4. 請求項１に記載のシステムであって、前記仮想コンピュートシステムはさらに、
   前記プログラムコードによる前記コンピューティングリソースの前記使用量に基づいて第２の量を決定する ように構成される、前記システム。
5. 請求項４に記載のシステムであって、前記仮想コンピュートシステムは、前記プログラムコードと関連したユーザにより指定された閾値範囲内にあるように、前記第２の量を決定するように構成される、前記システム。
6. 請求項１に記載のシステムであって、前記仮想コンピュートシステムは、前記プログラムコードによる前記コンピューティングリソースの前記使用量が、最大の過剰量よりも少ない過剰量だけ前記第１の量を超えることを可能にするようにさらに構成される、前記システム。
7. 請求項２に記載のシステムであって、前記仮想コンピュートシステムはさらに、閾値利用値より低いまたはより高い場合における平均パーセンテージに基づき、指示を提供するように構成される、前記システム。
8. コンピュータにより実行される方法であって、
   特定の実行可能な命令を備えて構成される１つまたは複数のコンピューティングデバイスによって実行される場合、
   １つまたは複数の物理的なコンピューティングデバイス上で複数の仮想マシンインスタンスを保守することと、
   プログラムコードと、前記プログラムコードに関連したユーザと、前記プログラムコードを実行するために使用される仮想コンピュートシステムで使用可能なコンピューティングリソースの第１の量と、を示す情報を含む、前記仮想コンピュートシステム上で、前記ユーザと関連したプログラムコードを実行するための要求を受信することと、
   前記プログラムコードを実行するために使用される、前記複数の仮想マシンインスタンスから、少なくとも前記第１の量のコンピューティングリソースを有する、仮想マシンインスタンスを選択することと、
   前記選択された仮想マシンインスタンスにおいて、前記コンピューティングリソースの第１の量を有するコンテナを作成することと、
   前記ユーザと関連した前記プログラムコードを、前記コンテナ上へロードさせて、前記コンテナにおいて実行させることと、
   前記選択された仮想マシンインスタンスにおいて作成された前記コンテナにおいて、前記プログラムコードを実行する間、前記プログラムコードによる前記コンピューティングリソースの使用量をモニタすることと、
   前記プログラムコードによる前記コンピューティングリソースの前記使用量に基づいて、前記要求で示された第１の量が前記プログラムコードを実行するための閾値のリソース調整条件を満たすと判定することと、
   プログラムコードと、前記プログラムコードに関連した前記ユーザと、前記プログラムコードを実行するために使用される前記仮想コンピュートシステムで使用可能なコンピューティングリソースの第１の量と、を示す情報を含む後続の要求を受け取ったことに応答し、前記選択した仮想マシンインスタンスに、前記後続の要求で示された前記第１の量とは異なるコンピューティングリソースの第２の量を有する、追加のコンテナを作成することと、
   前記コンピューティングリソースの前記第２の量を有する前記追加のコンテナで、前記プログラムコードを実行させることと、
   を含む、前記方法。
   
9. 請求項８に記載のコンピュータにより実行される方法であって、さらに、
   前記要求で示されたユーザ指定の量、または前記要求、前記プログラムコードまたは前記仮想コンピュートシステム上で前記プログラムコードを実行する前記ユーザに関連する他の構成情報に基づいて、前記第１の量を決定することと、
   前記プログラムコードによる前記コンピューティングリソースの前記使用量と、前記要求において示された前記ユーザ指定の量とを比較することと、
   前記第１の量をどの程度調整すべきかという指示を提供することと、
   を含む、前記方法。
10. 請求項９に記載のコンピュータにより実行される方法であって、前記指示を提供することが、（ａ）前記第１の量を増加すべきであると示すこと、（ｂ）前記第１の量を、第１の調整量だけ増加すべきであると示すこと、（ｃ）前記第１の量を削減すべきであると示すこと、または、（ｄ）前記第１の量を、第２の調整量だけ削減すべきであると示すこと、のうちの１つを含む、前記方法。
11. 請求項８に記載のコンピュータにより実行される方法であって、さらに、
    前記プログラムコードによる前記コンピューティングリソースの前記使用量に基づいて前記第２の量を決定することと、 を含む、前記方法。
12. 請求項１１に記載のコンピュータにより実行される方法であって、前記第２の量を決定することは、前記プログラムコードと関連したユーザにより指定された閾値範囲内にあるように、前記第２の量を決定することを含む、前記方法。
13. 請求項８に記載のコンピュータにより実行される方法であって、さらに、前記プログラムコードによる前記コンピューティングリソースの前記使用量が、最大の過剰量よりも少ない過剰量だけ前記第１の量を超えることを可能にすることを含む、前記方法。
14. 請求項９に記載のコンピュータにより実行される方法であって、前記仮想コンピュートシステムはさらに、閾値利用値より低いまたはより高い場合における平均パーセンテージに基づき、指示を提供するように構成される、前記方法。
15. コンピュータにより実行可能な命令を保存する、非一時的コンピュータ可読記憶媒体であって、当該命令が、１つまたは複数のコンピューティングデバイスによって実行される場合、前記１つまたは複数のコンピューティングデバイスに、
    １つまたは複数の物理的なコンピューティングデバイス上で複数の仮想マシンインスタンスを保守することと、
    プログラムコードと、前記プログラムコードに関連したユーザと、前記プログラムコードを実行するために使用される仮想コンピュートシステムで使用可能なコンピューティングリソースの第１の量と、を示す情報を含む、前記仮想コンピュートシステム上で前記ユーザと関連したプログラムコードを実行するための要求を受信することと、
    前記プログラムコードを実行するために使用される、前記複数の仮想マシンインスタンスから、少なくとも前記第１の量のコンピューティングリソースを有する、仮想マシンインスタンスを選択することと、
    前記選択された仮想マシンインスタンスにおいて、前記コンピューティングリソースの第１の量を有するコンテナを作成することと、
    前記ユーザと関連した前記プログラムコードを、前記コンテナ上へロードさせて、前記コンテナにおいて実行させることと、
    前記選択された仮想マシンインスタンスにおいて作成された前記コンテナにおいて、前記プログラムコードを実行する間、前記プログラムコードによる前記コンピューティングリソースの使用量をモニタすることと、
    前記プログラムコードによる前記コンピューティングリソースの前記使用量に基づいて、前記要求で示された第１の量が前記プログラムコードを実行するための閾値のリソース調整条件を満たすと判定することと、
    プログラムコードと、前記プログラムコードに関連した前記ユーザと、前記プログラムコードを実行するために使用される前記仮想コンピュートシステムで使用可能なコンピューティングリソースの第１の量と、を示す情報を含む追加要求を受け取ったことに応答し、前記選択した仮想マシンインスタンスに、前記追加要求で示された前記第１の量とは異なるコンピューティングリソースの第２の量を有する、追加のコンテナを作成することと、
    前記コンピューティングリソースの前記第２の量を有する前記追加のコンテナで、前記プログラムコードを実行させることと、
    を含む動作を実施するように構成される、非一時的コンピュータ可読記憶媒体。
    
16. 請求項１５に記載の非一時的コンピュータ可読記憶媒体であって、前記動作はさらに、
    前記要求で示されたユーザ指定の量、または前記要求、前記プログラムコードまたは前記仮想コンピュートシステム上で前記プログラムコードを実行する前記ユーザに関連する他の構成情報に基づいて、前記第１の量を決定することと、
    前記プログラムコードによる前記コンピューティングリソースの前記使用量と、前記要求において示された前記ユーザ指定の量とを比較することと、
    前記第１の量をどの程度調整すべきかという指示を提供することと、
    を含む、前記非一時的コンピュータ可読記憶媒体。
17. 請求項１６に記載の非一時的コンピュータ可読記憶媒体であって、前記指示を提供することが、（ａ）前記第１の量を増加すべきであると示すこと、（ｂ）前記第１の量を、第１の調整量だけ増加すべきであると示すこと、（ｃ）前記第１の量を削減すべきであると示すこと、または、（ｄ）前記第１の量を、第２の調整量だけ削減すべきであると示すこと、のうちの１つを含む、非一時的コンピュータ可読記憶媒体。
18. 請求項１５に記載の非一時的コンピュータ可読記憶媒体であって、前記動作はさらに、
    前記プログラムコードによる前記コンピューティングリソースの前記使用量に基づいて前記第２の量を決定することと、
    を含む、前記非一時的コンピュータ可読記憶媒体。
19. 請求項１８に記載の非一時的コンピュータ可読記憶媒体であって、前記第２の量を決定することは、前記プログラムコードと関連したユーザにより指定された閾値範囲内にあるように、前記第２の量を決定することを含む、前記非一時的コンピュータ可読記憶媒体。
20. 請求項１５に記載の非一時的コンピュータ可読記憶媒体であって、前記動作がさらに、前記プログラムコードによる前記コンピューティングリソースの前記使用量が、最大の過剰量よりも少ない過剰量だけ前記第１の量を超えることを可能にすることを含む、前記非一時的コンピュータ可読記憶媒体。