(58)【調査した分野】(Int.Cl.,DB名)
コンピュータにより実行可能な命令を保存する、非一時的コンピュータ可読記憶媒体であって、当該命令が、1つまたは複数のコンピューティングデバイスによって実行される場合、前記1つまたは複数のコンピューティングデバイスに、
1つまたは複数の物理的なコンピューティングデバイス上で複数の仮想マシンインスタンスを保守することと、
プログラムコードと、前記プログラムコードに関連したユーザと、前記プログラムコードを実行するために使用される仮想コンピュートシステムで使用可能なコンピューティングリソースの第1の量と、を示す情報を含む、前記仮想コンピュートシステム上で前記ユーザと関連したプログラムコードを実行するための要求を受信することと、
前記プログラムコードを実行するために使用される、前記複数の仮想マシンインスタンスから、少なくとも前記第1の量のコンピューティングリソースを有する、仮想マシンインスタンスを選択することと、
前記選択された仮想マシンインスタンスにおいて、前記コンピューティングリソースの第1の量を有するコンテナを作成することと、
前記ユーザと関連した前記プログラムコードを、前記コンテナ上へロードさせて、前記コンテナにおいて実行させることと、
前記選択された仮想マシンインスタンスにおいて作成された前記コンテナにおいて、前記プログラムコードを実行する間、前記プログラムコードによる前記コンピューティングリソースの使用量をモニタすることと、
前記プログラムコードによる前記コンピューティングリソースの前記使用量に基づいて、前記要求で示された第1の量が前記プログラムコードを実行するための閾値のリソース調整条件を満たすと判定することと、
プログラムコードと、前記プログラムコードに関連した前記ユーザと、前記プログラムコードを実行するために使用される前記仮想コンピュートシステムで使用可能なコンピューティングリソースの第1の量と、を示す情報を含む追加要求を受け取ったことに応答し、前記選択した仮想マシンインスタンスに、前記追加要求で示された前記第1の量とは異なるコンピューティングリソースの第2の量を有する、追加のコンテナを作成することと、
前記コンピューティングリソースの前記第2の量を有する前記追加のコンテナで、前記プログラムコードを実行させることと、
を含む動作を実施するように構成される、非一時的コンピュータ可読記憶媒体。
【発明を実施するための形態】
【0010】
企業や組織はもはや、コンピューティング動作を実施(例えば、スレッド、プログラム、機能、ソフトウェア、ルーチン、サブルーチン、プロセス等を含むコードを実行)するために、自身の所有するデータセンターを獲得及び管理する必要はない。クラウドコンピューティングの出現により、ハードウェアコンピューティングデバイスにより従来提供されたストレージ空間及び演算能力は、今や、インターネット上において数分で取得及び構成され得る。それゆえ、開発者は、物理的なマシンの獲得を懸念する必要なく、所望の量のコンピューティングリソースを迅速に購入し得る。このようなコンピューティングリソースは、仮想コンピューティングリソースまたは仮想マシンインスタンスの形で一般に購入される。仮想マシンのこれらのインスタンスは、物理的なコンピューティングデバイス上でホストされる物理的なマシン(例えば、コンピュータ)のソフトウェア実施態様であり、物理的なマシン上に従来提供されるオペレーティングシステム及びアプリケーションを含んでよい。これらの仮想マシンインスタンスは、仮想マシンインスタンス上で実行するアプリケーションが要求してよく、また、物理的なコンピュータと同じ方法で利用されてよい、一連のコンピューティングリソース(例えば、メモリ、CPU、ディスク、ネットワーク等)を備えて構成される。
【0011】
しかしながら、仮想コンピューティングリソースが(例えば、仮想マシンインスタンスの形で)購入された場合でさえ、いくつの及びどんな種類の仮想マシンインスタンスを購入するか、ならびに、それらをいつまで維持するかを、開発者は依然として決定しなければならない。例えば、仮想マシンインスタンスを使用するコストは、タイプ及びそれらが貸し出される時間数により変動し得る。加えて、仮想マシンを貸し出すことのできる最短時間は、一般に約数時間である。さらに、開発者は、仮想マシンにインストールするためにハードウェア及びソフトウェアリソース(例えば、オペレーティングシステム及び言語ランタイム等のタイプ)を指定しなければならない。彼らが抱えることのある他の懸念は、過剰利用(例えば、獲得するコンピューティングリソースが少な過ぎて、パフォーマンス問題に悩まされること)、過少利用(例えば、コードを実行するのに必要とされるよりも多くのコンピューティングリソースを獲得し、それゆえ余計に支払うこと)、トラフィックの変化の予測(例えば、これにより、彼らはいつスケールアップまたはスケールダウンするかが分かる)、及び、インスタンス及び言語ランタイム起動遅延を含む。こうした遅延は、ユーザが、約数秒またはさらに約ミリ秒でコンピューティングキャパシティを所望することがあるにも関わらず、3〜10分またはそれよりも長くかかることがあるものである。それゆえ、ユーザが、サービスプロバイダにより提供される仮想マシンインスタンスを活用することを可能にする改善された方法が所望される。
【0012】
本開示の態様によれば、ユーザ要求が受信されるとすぐに使用の準備ができている、予め初期化された仮想マシンインスタンスのプールを保守することにより、ユーザコードを実行すること(例えばインスタンス及び言語ランタイム起動時間)と関連した遅延(レイテンシと呼ばれることもある)が、著しく削減され得る。
【0013】
一般に言われているように、本開示の態様は、仮想マシンインスタンス、及び仮想マシンインスタンスに作成されるコンテナの管理に関する。具体的には、仮想コンピュートシステムにおける仮想マシンインスタンスの管理を促進するシステム及び方法が開示される。仮想コンピュートシステムは、そこにロードされた1つまたは複数のソフトウェア構成要素(例えば、オペレーティングシステム、言語ランタイム、ライブラリ等)を有する仮想マシンインスタンスのプールを保守する。仮想マシンインスタンスのプールを保守することは、新たなインスタンスを作成すること、外部のインスタンスプロビジョニングサービスから新たなインスタンスを取得すること、インスタンスをデストロイすること、インスタンスをユーザに割り当てること/再び割り当てること、インスタンス(例えば、コンテナまたはその中のリソース)を修正すること等を含んでよい。プールにおける仮想マシンインスタンスは、プログラムコードを実行するためのユーザ要求にサービスするように指定されてよい。本開示において、「プログラムコード」、「ユーザコード」、及び「クラウド機能」といった表現は、時として区別なく使用されることがある。プログラムコードは、仮想マシンインスタンス上に作成された、隔離されたコンテナにおいて実行されてよい。プールにおける仮想マシンインスタンスは、要求が受信される時までに既に立ち上げられ、且つ、特定のオペレーティングシステム及び言語ランタイムをロードしているので、(例えば、仮想マシンインスタンス上に作成される1つまたは複数のコンテナにおいてユーザコードを実行することにより)要求に対処し得るコンピュートキャパシティを発見することと関連した遅延が著しく削減される。
【0014】
別の態様において、仮想コンピュートシステムは、ユーザコードを実行するために割り当てられるリソースの量に関連した情報をモニタ及びログしてよい。そうすることにより、仮想コンピュートシステムは、割り当てられるリソースの量を調整することにより、ユーザコード実行のパフォーマンスを改善するための機会を識別可能であってよい。誤り率は、過剰利用の場合、割り当てられるリソースの量を増加させることによって減少でき、また、過少利用の場合、ユーザコードの実行と関連したコストが、割り当てられるリソースの量を減少させることによって削減できる。
【0015】
本開示の特定の実施形態及び例示的な用途が、次に図面を参照して説明される。これらの実施形態及び例示的な用途は、本開示を説明することを意図しており、本開示を限定することを意図しない。
【0016】
図1を参照して、仮想環境100の実施形態を示すブロック図が説明される。
図1に示された実施例は、ユーザコンピューティングデバイス102のユーザ(例えば、開発者等)が仮想コンピュートシステム110により提供される仮想コンピューティングリソースを使用して様々なプログラムコードを実行し得る、仮想環境100を含む。
【0017】
実例として、デスクトップコンピュータ、ラップトップ、及び携帯電話を含め、仮想コンピュートシステム110と通信する様々な例示的なユーザコンピューティングデバイス102が示される。一般に、ユーザコンピューティングデバイス102は、デスクトップ、ラップトップ、携帯電話(またはスマートフォン)、タブレット、キオスク、無線デバイス、及び他の電子デバイスなど、任意のコンピューティングデバイスであってよい。加えて、ユーザコンピューティングデバイス102は、同一または異なるデータセンター上で実行するウェブサービスを含んでよく、そこでは、例えば、異なるウェブサービスが、本明細書において説明される1つまたは複数の技法を実施するように、互いにプログラムで通信してよい。さらに、ユーザコンピューティングデバイス102は、インターネットアプライアンス及び接続されるデバイスなど、モノのインターネット(IoT)デバイスを含んでよい。仮想コンピュートシステム110は、ユーザコードを生成及びアップロードし、ユーザコードを呼び出し(例えば、仮想コンピュートシステム110上でユーザコードを実行するための要求をサブミットし)、イベントベースのジョブまたは時間指定されたジョブをスケジューリングし、ユーザコードを追跡し、ならびに/または、それらの要求及び/またはユーザコードに関連するその他のロギングまたはモニタリング情報を表示するための、1つまたは複数のユーザインターフェース、コマンドラインインターフェース(CLI)、アプリケーションプログラミングインターフェース(API)、及び/または、他のプログラマチックインターフェースを、ユーザコンピューティングデバイス102に提供してよい。1つまたは複数の実施形態が、ユーザインターフェースを使用するものとして本明細書において説明され得るが、そのような実施形態が、追加的または代替的に、任意のCLI、API、または他のプログラマチックインターフェースを使用してもよいことを理解すべきである。
【0018】
ユーザコンピューティングデバイス102は、ネットワーク104を介して仮想コンピュートシステム110にアクセスする。ネットワーク104は、任意の有線ネットワーク、無線ネットワーク、またはそれらの組合せであってよい。加えて、ネットワーク104は、パーソナルエリアネットワーク、ローカルエリアネットワーク、広域ネットワーク、無線の放送網ネットワーク(例えば、ラジオまたはテレビ用)、ケーブルネットワーク、衛星ネットワーク、携帯電話ネットワーク、またはそれらの組合せであってよい。例えば、ネットワーク104は、インターネットなど、場合によっては様々な別個の当事者により動作される、接続されたネットワークのうちの公衆にアクセス可能なネットワークであってよい。いくつかの実施形態において、ネットワーク104は、法人または大学のイントラネットなど、プライベートまたは準プライベートネットワークであってよい。ネットワーク104は、Global System for Mobile Communications(GSM)ネットワーク、符号分割多元接続(CDMA)ネットワーク、ロングタームエボリューション(LTE)ネットワーク、または任意の他のタイプの無線ネットワークなど、1つまたは複数の無線ネットワークを含んでよい。ネットワーク104は、インターネットまたは他の前述のタイプのネットワークのいずれかを介して通信するためのプロトコル及び構成要素を使用してよい。例えば、ネットワーク104により使用されるプロトコルは、ハイパーテキストトランスファープロトコル(HTTP)、HTTPセキュア(HTTPS)、Message Queue Telemetry Transport(MQTT)、Constrained Application Protocol(CoAP)等を含んでよい。インターネットまたは他の前述のタイプの通信ネットワークのいずれかを介して通信するためのプロトコル及び構成要素は、当業者によく知られており、それゆえ、本明細書ではより詳細に説明されない。
【0019】
仮想コンピュートシステム110は、1つまたは複数のコンピュータネットワークを使用して相互接続されるいくつかのコンピュータシステムを含む分散コンピューティング環境において動作するものとして、
図1に表わされる。仮想コンピュートシステム110はまた、
図1に示したよりも少ない数または多い数のデバイスを有するコンピューティング環境内で動作してもよい。それゆえ、
図1における仮想コンピュートシステム110の描写は、説明的なものとして受け取られるべきであり、本開示に限定するものでない。例えば、仮想コンピュートシステム110またはその様々な構成要素は、本明細書において説明されるプロセスの少なくとも一部を実行するように、様々なウェブサービス構成要素、ホストまたは「クラウド」コンピューティング環境、及び/または、ピアツーピアネットワーク構成を実行してよい。
【0020】
さらに、仮想コンピュートシステム110は、ハードウェア及び/またはソフトウェアにおいて実行されてよく、例えば、本明細書において説明される様々な特徴を実施するための、コンピュータにより実行可能な命令を実行するように構成される、物理的なコンピュータハードウェア上で実行される1つまたは複数の物理的または仮想サーバを含んでよい。1つまたは複数のサーバは、地理的に分散されてもよく、または、例えば1つまたは複数のデータセンターにおいて地理的に同じ場所に配置されてもよい。
【0021】
図1に示した環境において、仮想環境100は、仮想コンピュートシステム110を含み、仮想コンピュートシステム110は、フロントエンド120、ウォーミングプールマネージャ130、ワーカマネージャ140、及び、リソースマネージャ150を含む。表された実施例において、仮想マシンインスタンス(「インスタンス」)152、154が、ウォーミングプールマネージャ130により管理されるウォーミングプール130Aにおいて示され、インスタンス156、157、158、159が、ワーカマネージャ140により管理されるアクティブプール140Aにおいて示される。仮想コンピュートシステム110内の様々な構成要素の実例は、実際には論理的なものであり、構成要素の1つまたは複数は、1つのコンピューティングデバイスまたは多数のコンピューティングデバイスにより実行されてよい。例えば、インスタンス152、154、156、157、158、159は、異なる様々な地理的領域における1つまたは複数の物理的なコンピューティングデバイス上で実行されてよい。同様に、フロントエンド120、ウォーミングプールマネージャ130、ワーカマネージャ140、及びリソースマネージャ150のそれぞれは、多数の物理的なコンピューティングデバイス間で実行されてよい。あるいは、フロントエンド120、ウォーミングプールマネージャ130、ワーカマネージャ140、及びリソースマネージャ150の1つまたは複数が、1つの物理的なコンピューティングデバイス上で実行されてよい。いくつかの実施形態において、仮想コンピュートシステム110は、多数のフロントエンド、多数のウォーミングプールマネージャ、多数のワーカマネージャ、及び/または、多数のキャパシティマネージャを含んでよい。6つの仮想マシンインスタンスが
図1の実施例に示されるが、本明細書において説明される実施形態はそのように限定されず、仮想コンピュートシステム110が、任意の数の物理的なコンピューティングデバイスを使用して実行される任意の数の仮想マシンインスタンスを含んでよいことを当業者は理解する。同様に、1つのウォーミングプール及び1つのアクティブプールが
図1の実施例に示されるが、本明細書において説明される実施形態はそのように限定されず、仮想コンピュートシステム110が、任意の数のウォーミングプール及びアクティブプールを含んでよいことを当業者は理解する。
【0022】
図1の実施例において、仮想コンピュートシステム110は、ネットワーク104に接続されるものとして示される。いくつかの実施形態において、仮想コンピュートシステム110内の構成要素のいずれかは、仮想環境100の他の構成要素(例えば、ユーザコンピューティングデバイス102及び補助サービス106であり、補助サービス106は、モニタリング/ロギング/ビリングサービス107、ストレージサービス108、インスタンスプロビジョニングサービス109、及び/または、仮想コンピュートシステム110と通信し得る他のサービスを含んでよい)とネットワーク104を介して通信してよい。他の実施形態において、仮想コンピュートシステム110の全ての構成要素が、仮想環境100の他の構成要素と通信可能であるとは限らない。1つの実施例において、フロントエンド120のみがネットワーク104に接続されてよく、仮想コンピュートシステム110の他の構成要素は、フロントエンド120を介して、仮想環境100の他の構成要素と通信してよい。
【0023】
ユーザは、仮想コンピュートシステム110を、そこにあるユーザコードを実行するために使用してよい。例えば、ユーザは、ユーザが開発したウェブまたはモバイルアプリケーションに関連して1つのコードを実行することを望むことがある。コードを実行する1つの方法は、サービスとしてインフラストラクチャを提供するサービスプロバイダから仮想マシンインスタンスを獲得し、当該仮想マシンインスタンスをユーザのニーズに適合するように構成し、構成された仮想マシンインスタンスを、コードを実行するのに使用することであろう。あるいは、ユーザは、仮想コンピュートシステム110へコード実行要求を送信してもよい。仮想コンピュートシステム110は、コード実行要求に基づいて、コンピュートキャパシティ(例えば、以下でより詳細に説明されるコンテナ、インスタンス等)の獲得及び構成に対処してよく、コンピュートキャパシティを使用してコードを実行してよい。仮想コンピュートシステム110は、ボリュームに基づいて自動的にスケールアップまたはスケールダウンしてよく、これにより、過剰利用(例えば、獲得するコンピューティングリソースが少な過ぎて、パフォーマンス問題に悩まされること)、または、過少利用(例えば、コードを実行するのに必要とされるよりも多くのコンピューティングリソースを獲得し、それゆえ余計に支払うこと)を懸念しなければならないという負担から、ユーザが解放される。
【0024】
フロントエンド120は、仮想コンピュートシステム110上でユーザコードを実行するための要求全てを処理する。1つの実施形態において、フロントエンド120は、仮想コンピュートシステム110により提供される他のサービス全てにとってのフロントドアとしての働きをする。フロントエンド120は、要求を処理し、当該要求が適切にオーソライズされることを確認する。例えば、フロントエンド120は、要求と関連したユーザが、要求において指定されたユーザコードにアクセスするのにオーソライズされるかどうかを判定してよい。
【0025】
本明細書において使用されるユーザコードは、特定のプログラム言語で記述された任意のプログラムコード(例えば、プログラム、ルーチン、サブルーチン、スレッド等)を参照してよい。本開示において、「コード」、「ユーザコード」及び「プログラムコード」という用語は、区別なく使用され得る。このようなユーザコードは、例えば、ユーザにより開発される特定のウェブアプリケーションまたはモバイルアプリケーションに関連して特定のタスクを達成するように実行されてよい。例えば、ユーザコードは、JavaScript(登録商標)(node.js)、Java(登録商標)、Python(登録商標)、及び/または、Ruby(登録商標)で記述されてよい。要求は、ユーザコード(またはその位置)、及びユーザコードを実行するために使用される1つまたは複数の引数を含んでよい。例えば、ユーザは、ユーザコードを実行するための要求と共にユーザコードを提供してよい。別の実施例において、要求は、予めアップロードされたプログラムコードを、(例えば、コードをアップロードするためのAPIを使用して)その名前またはそのユニークなIDによって識別してよい。さらに別の実施例において、コードは、要求に含まれてもよく、また、要求が仮想コンピュートシステム110により受信される前に、別個の位置(例えば、ストレージサービス108、または仮想コンピュートシステム110内のストレージシステム)においてアップロードされてもよい。仮想コンピュートシステム110は、要求が処理される時点でコードが利用可能である場所に基づいて、そのコード実行ストラテジを変更してよい。
【0026】
フロントエンド120は、ユーザからのハイパーテキストトランスファープロトコルセキュア(HTTPS)要求に応答して、そのようなユーザコードを実行するための要求を受信してよい。また、ユーザコードを実行するとき、HTTPS要求に含まれる任意の情報(例えば、ヘッダ及びパラメータ)がさらに処理及び利用されてもよい。上述のように、例えば、HTTP、MQTT及びCoAPを含め、任意の他のプロトコルが、コード実行要求を収容するメッセージをフロントエンド120に転送するのに使用されてよい。フロントエンド120はまた、自動の要求生成をトリガするためにユーザが登録したイベントなどのイベントが検出されたときに、そのようなユーザコードを実行するための要求を受信してもよい。例えば、ユーザは、補助サービス106によりユーザコードを登録していてもよく、また、特定のイベントが発生する(例えば、新たなファイルがアップロードされる)たびに、ユーザコードを実行するための要求がフロントエンド120へ送信されることを指定していてもよい。あるいは、ユーザは、時間指定されたジョブ(例えば、24時間毎にユーザコードを実行する)を登録していてもよい。このような実施例において、時間指定されたジョブについてスケジュールされた時間がやってくるとき、ユーザコードを実行するための要求が、フロントエンド120に送信されてよい。さらに別の実施例において、フロントエンド120は、入来するコード実行要求のキューを有してよく、ユーザのバッチジョブが仮想コンピュートシステムのワークキューから削除されるとき、フロントエンド120はユーザ要求を処理してよい。さらに別の実施例において、要求は、仮想コンピュートシステム110内の別の構成要素または
図1に示されない他のサーバもしくはサービスから発生されてよい。
【0027】
ユーザ要求は、ユーザコードと共に使用すべき1つまたは複数のサードパーティのライブラリ(ネイティブライブラリを含む)を指定してよい。1つの実施形態において、ユーザ要求は、ユーザコード及び任意のライブラリ(及び/またはそのストレージ位置の識別)を収容するZIPファイルである。いくつかの実施形態において、ユーザ要求は、実行すべきプログラムコードを示すメタデータ、プログラムコードを記述する言語、要求と関連したユーザ、及び/または、プログラムコードを実行するためにリザーブすべきコンピューティングリソース(例えば、メモリ、CPU、ストレージ、ネットワークパケット等)を含む。例えば、プログラムコードは、要求を備えてもよく、ユーザにより予めアップロードされてもよく、仮想コンピュートシステム110(例えば、標準ルーチン)により提供されてもよく、及び/または、サードパーティにより提供されてもよい。いくつかの実施形態において、リソースレベルの制約(例えば、特定のユーザコードを実行するためにどのくらいのメモリを割り当てるべきか)は、特定のユーザコードに対して指定され、ユーザコードの各実行と共に変化するものでなくてよい。このような場合、仮想コンピュートシステム110は、各個々の要求が受信される前にそのようなリソースレベルの制約を利用してよく、個々の要求がそのようなリソースレベルの制約を指定しなくてよい。いくつかの実施形態において、リソースレベルの制約は、経時的に調整され、また、1つのプログラムコードの様々な実行によって変化し得る。例えば、同一のプログラムコードが、データの2つの異なるセットを処理するのに使用されてよく、そこでは、データの1つのセットが、もう一方よりも多くのリソースを必要とする。このような場合、ユーザは、2つの異なる実行のために異なるリソース制約を指定してよく、または、仮想コンピュートシステム110は、ユーザ及び/またはプログラムコードについての空間的(例えば、仮想コンピュートシステム110の他の部分における)傾向、または履歴的(例えば、経時的)傾向に基づいて、プログラムコードの各実行に割り当てられるリソースの量を自動的に調整してよい。いくつかの実施形態において、ユーザ要求は、ユーザコードを実行するためにどのようなパーミッションを要求が有するのかを示すパーミッションデータなど、他の制約を指定してよい。このようなパーミッションデータは、(例えば、プライベートネットワーク上の)プライベートリソースにアクセスするために、仮想コンピュートシステム110により使用されてよい。
【0028】
いくつかの実施形態において、ユーザ要求は、ユーザ要求に対処するために用いるべきビヘイビアを指定してよい。このような実施形態において、ユーザ要求は、ユーザ要求と関連したユーザコードが実行され得る1つまたは複数の実行モードを可能にするための標識を含んでよい。例えば、要求は、ユーザコードの実行に関連して生成され得るデバッギング及び/またはロギング出力が(例えば、コンソールユーザインターフェースを介して)ユーザに提供されるデバッグモードにおいて、ユーザコードを実行すべきかどうかを示すためのフラグまたはヘッダを含んでよい。このような実施例において、仮想コンピュートシステム110は要求を検査してよく、フラグまたはヘッダを探してよく、それが存在する場合には、仮想コンピュートシステム110は、ユーザコードが実行されるコンテナのビヘイビア(例えば、ロギングファシリティ)を修正してよく、出力データをユーザに提供させてよい。いくつかの実施形態において、ビヘイビア/モード標識は、仮想コンピュートシステム110によりユーザに提供されるユーザインターフェースによって要求に追加される。ソースコードプロファイリング、リモートデバッギング等などの他の特徴はまた、要求において提供されるインディケーションに基づいて有効または無効にされてよい。
【0029】
いくつかの実施形態において、仮想コンピュートシステム110は、多数のフロントエンド120を含んでよい。このような実施形態において、ロードバランサが、例えばラウンドロビン方式で、入来する要求を多数のフロントエンド120へ分散するように提供されてよい。いくつかの実施形態において、ロードバランサが、入来する要求を多数のフロントエンド120へ分散する方法は、ウォーミングプール130A及び/またはアクティブプール140Aの状態に基づくものであってよい。例えば、ウォーミングプール130Aにおけるキャパシティが十分であると考えられる場合、要求は、フロントエンド120の個々のキャパシティに基づいて(例えば、1つまたは複数のロードバランシング制限に基づいて)、多数のフロントエンド120へ分散されてよい。一方、ウォーミングプール130Aにおけるキャパシティが閾値量よりも低い場合、そのようなロードバランシング制限の1つまたは複数は削除されてよく、その結果、ウォーミングプール130Aから取得される仮想マシンインスタンスの数を削減または最小にする方法で、要求は、多数のフロントエンド120へ分散されてよい。例えば、ロードバランシング制限に従って、要求がフロントエンドAにルートされるべきであっても、フロントエンドAは、要求にサービスするためにウォーミングプール130Aからインスタンスを取得する必要があるが、フロントエンドBは、同一の要求にサービスするために、そのアクティブプールおけるインスタンスの1つを使用し得る場合、要求は、フロントエンドBにルートされてよい。
【0030】
仮想コンピュートシステム110が、仮想コンピュートシステム110上でユーザコードを実行するための要求を受信するとき、仮想マシンインスタンスがワーカマネージャ140によりすぐに使用されることができることを、ウォーミングプールマネージャ130が確実にする。
図1に示した実施例において、ウォーミングプールマネージャ130は、入来するユーザコード実行要求にサービスするのに使用され得る予め初期化され且つ予め構成された仮想マシンインスタンスのグループ(プールと呼ばれることもある)である、ウォーミングプール130Aを管理する。いくつかの実施形態において、ウォーミングプールマネージャ130は、仮想マシンインスタンスを、仮想コンピュートシステム110内の1つまたは複数の物理的なコンピューティングマシン上で立ち上げさせて、ウォーミングプール130Aに追加させる。他の実施形態において、ウォーミングプールマネージャ130は、新たなインスタンスを作成してそれをウォーミングプール130Aに追加するように、補助仮想マシンインスタンスサービス(例えば、
図1のインスタンスプロビジョニングサービス109)と通信する。いくつかの実施形態において、ウォーミングプールマネージャ130は、フロントエンド120により受信されるコード実行要求にサービスするのに使用され得るコンピュートキャパシティを獲得及び保守するように、仮想コンピュートシステム110内の物理的なコンピューティングデバイスと、1つまたは複数の仮想マシンインスタンスサービスとの両方を利用してよい。いくつかの実施形態において、仮想コンピュートシステム110は、ウォーミングプール130Aにおける利用可能なキャパシティを制御(例えば、増加または削減)するための1つまたは複数の論理ノブまたはスイッチを含んでよい。例えば、システム管理者は、ピーク時の間、ウォーミングプール130Aにおいて利用可能なキャパシティ(例えば、予め立ち上げられたインスタンスの数)を増加するように、そのようなノブまたはスイッチを使用してよい。いくつかの実施形態において、ウォーミングプール130Aにおける仮想マシンインスタンスは、ユーザのコードを実行するための、特定のユーザ要求から独立した構成の所定のセットに基づいて構成されてよい。構成の所定のセットは、ユーザコードを実行するように様々なタイプの仮想マシンインスタンスに対応してよい。ウォーミングプールマネージャ130は、現在または以前のユーザコード実行に関連する1つまたは複数のメトリクスに基づいて、ウォーミングプール130Aにおける仮想マシンインスタンスのタイプ及び数を最適化してよい。
【0031】
図1に示すように、インスタンスは、そこにロードされたオペレーティングシステム(OS)及び/または言語ランタイムを有してよい。例えば、ウォーミングプールマネージャ130により管理されるウォーミングプール130Aは、インスタンス152、154を含む。インスタンス152は、OS152A及びランタイム152Bを含む。インスタンス154は、OS154Aを含む。いくつかの実施形態において、ウォーミングプール130Aにおけるインスタンスはまた、以下でより詳細に説明される、(オペレーティングシステム、ランタイム、ユーザコード等のコピーをさらに含んでよい)コンテナを含んでもよい。インスタンス152が1つのランタイムを含むように
図1に示されるが、他の実施形態において、
図1に表されたインスタンスは、2つまたはそれよりも多いランタイムを含んでもよく、そのそれぞれが異なるユーザコードを実行するために使用されてよい。いくつかの実施形態において、ウォーミングプールマネージャ130は、ウォーミングプール130Aにおけるインスタンスのリストを保持してよい。インスタンスのリストはさらに、インスタンスの構成(例えば、OS、ランタイム、コンテナ等)を指定してよい。
【0032】
いくつかの実施形態において、ウォーミングプール130Aにおける仮想マシンインスタンスは、任意のユーザの要求に応対するのに使用されてよい。1つの実施形態において、ウォーミングプール130Aにおける仮想マシンインスタンス全ては、同一または実質的に同様の方法で構成される。別の実施形態において、ウォーミングプール130Aにおける仮想マシンインスタンスは、異なるユーザのニーズに適合するように異なって構成されてよい。例えば、仮想マシンインスタンスは、そこにロードされた異なるオペレーティングシステム、異なる言語ランタイム、及び/または、異なるライブラリを有してよい。さらに別の実施形態において、ウォーミングプール130Aにおける仮想マシンインスタンスは、同一または実質的に同様の方法で(例えば、同一のOS、言語ランタイム、及び/または、ライブラリを備えて)構成されてよいが、これらのインスタンスのうちのいくつかが異なるコンテナ構成を有してもよい。例えば、2つのインスタンスはPython(登録商標)とRuby(登録商標)の両方のためのランタイムを有してもよいが、一方のインスタンスは、Python(登録商標)コードを実行するように構成されるコンテナを有してよく、他方のインスタンスは、Ruby(登録商標)コードを実行するように構成されるコンテナを有してよい。いくつかの実施形態において、それぞれが全く同様に構成された仮想マシンインスタンスを有する多数のウォーミングプール130Aが提供される。
【0033】
各仮想マシンインスタンスが、仮想コンピュートシステム110上でプログラムコードを実行するためのユーザ要求により要求または指定され得る動作条件の少なくとも1つを満たすように構成されるように、ウォーミングプールマネージャ130は、ウォーミングプール130Aにおける仮想マシンインスタンスを予め構成してよい。1つの実施形態において、動作条件は、可能なユーザコードを記述できるプログラム言語を含んでよい。例えば、そのような言語は、Java(登録商標)、JavaScript(登録商標)、Python(登録商標)、Ruby(登録商標)等を含んでよい。いくつかの実施形態において、ユーザコードを記述できる言語のセットは、ユーザコードを実行するための要求を満たし得る仮想マシンインスタンスの事前初期化を促進するため、所定のセット(例えば4言語のセットであるが、いくつかの実施形態においては、4言語よりも多い、または少ないセットが提供される)に限定されてよい。例えば、ユーザが、仮想コンピュートシステム110により提供されるユーザインターフェースを介して要求を構成しているとき、ユーザインターフェースは、ユーザコードを実行するために所定の動作条件の1つを指定するようユーザに促してよい。別の実施例において、仮想コンピュートシステム110により提供されるサービスの利用に関するサービス水準合意(SLA)は、ユーザ要求が満たすべき一連の条件(例えば、プログラミング言語、コンピューティングリソース等)を指定してよく、仮想コンピュートシステム110は、要求に対処するにあたり、要求が一連の条件を満たすと想定してよい。別の実施例において、要求において指定された動作条件は、要求を処理するために使用される演算能力の量、要求のタイプ(例えば、HTTP対トリガされるイベント)、要求のためのタイムアウト(例えば、要求を終了し得た後の閾値時間)、セキュリティポリシー(例えば、ウォーミングプール130Aにおけるどのインスタンスがどのユーザにより使用可能かを制御してよい)等を含んでよい。
【0034】
ワーカマネージャ140は、入来するコード実行要求にサービスするために使用されるインスタンスを管理する。
図1に示した実施例において、ワーカマネージャ140は、1人または複数のユーザに現在割り当てられている仮想マシンインスタンスのグループ(プールと呼ばれることもある)であるアクティブプール140Aを管理する。仮想マシンインスタンスが、特定のユーザに割り当てられるものとしてここでは説明されるが、いくつかの実施形態において、インスタンスは、ユーザのグループに割り当てられてもよく、これにより、インスタンスはユーザのグループに結び付けられて、グループのどのメンバーもインスタンス上のリソースを利用することができる。例えば、同一グループにおけるユーザは、(例えば、ユーザのセキュリティ証明書に基づいて)同一のセキュリティグループに属してよく、これにより、1人のメンバーのコードを特定のインスタンス上のコンテナにおいて実行する前に、別のメンバーのコードが同一のインスタンス上の別のコンテナにおいて実行されていても、セキュリティ上のリスクは生じない。同様に、どのコンテナにおいてどの要求を実行できるか、及び、どのインスタンスをどのユーザに割り当てることができるかを規定する1つまたは複数のポリシーに従って、ワーカマネージャ140は、インスタンス及びコンテナを割り当ててよい。例示的なポリシーは、インスタンスが、同一のアカウント(例えば、仮想コンピュートシステム110により提供されるサービスにアクセスするためのアカウント)を共有するユーザの集まりに割り当てられることを指定してよい。いくつかの実施形態において、同一のユーザグループと関連した要求は、(例えば、それに関連したユーザコードが全く同一である場合)同一のコンテナを共有してよい。いくつかの実施形態において、要求は、グループの中の異なるユーザ間で区別されず、要求と関連したユーザが属するグループを示すに過ぎない。
【0035】
図1に示した実施例において、ユーザコードは、コンテナと呼ばれる隔離されたコンピュートシステムにおいて実行される。コンテナは、仮想マシンインスタンス内で、そのインスタンス上で利用可能なリソースを使用して作成される論理ユニットである。例えば、ワーカマネージャ140は、ユーザコードを実行するための要求において指定された情報に基づいて、新たなコンテナを作成してよく、または、アクティブプール140Aにおけるインスタンスの1つに既存のコンテナを配置してよく、また、要求と関連したユーザコードの実行に対処するように、当該コンテナを要求に割り当てる。1つの実施形態において、そのようなコンテナは、Linuxコンテナとして実行される。アクティブプール140Aにおける仮想マシンインスタンスは、そこに作成される1つまたは複数のコンテナを有してよく、(例えば、コンテナのうちの1つ、またはインスタンスのローカルキャッシュのいずれかにおいて)そこにロードされた、ユーザと関連した1つまたは複数のプログラムコードを有してよい。
【0036】
図1に示すように、インスタンスは、オペレーティングシステム(OS)、言語ランタイム、及びコンテナを有してよい。コンテナは、OS及び言語ランタイムの個々のコピーならびにそこにロードされたユーザコードを有してよい。
図1の実施例において、ワーカマネージャ140により管理されるアクティブプール140Aは、インスタンス156、157、158、159を含む。インスタンス156は、コンテナ156A、156Bを有する。コンテナ156Aは、その中にロードされたOS156A‐1、ランタイム156A‐2、及びコード156A‐3を有する。表された実施例において、コンテナ156Aは、その中にロードされた、それ自体のOS、ランタイム、及びコードを有する。1つの実施形態において、OS156A‐1(例えば、そのカーネル)、ランタイム156A‐2、及び/または、コード156A‐3は、コンテナ156A、156B(及び
図1に示されない任意の他のコンテナ)の間で共有される。別の実施形態において、OS156A‐1(例えば、カーネルの外で実行する任意のコード)、ランタイム156A‐2、及び/または、コード156A‐3は、コンテナ156Aのために作成される独立したコピーであり、インスタンス156上の他のコンテナと共有されない。さらに別の実施形態において、OS156A‐1、ランタイム156A‐2、及び/または、コード156A‐3のいくつかの部分が、インスタンス156上のコンテナ間で共有され、それらの他の部分は、コンテナ156Aに特有の独立したコピーである。インスタンス157はコンテナ157A、157B、157Cを含み、インスタンス158はコンテナ158Aを含み、インスタンス159は、コンテナ159Aを含む。
【0037】
図1の実施例において、
図1に表されたコンテナのサイズは、コンテナの実際のサイズに比例してよい。例えば、コンテナ156Aは、インスタンス156上のコンテナ156Bよりも多くの空間を占有する。同様に、コンテナ157A、157B、157C、159Aは、等しいサイズにされてよく、コンテナ158Aは、コンテナ157A、157B、157C、159Aよりも大きくてよい(例えば、そこに割り当てられた、より多くのコンピューティングリソースを有してよい)。インスタンス159に示される「C」と付された点線のボックスは、新たなインスタンスを作成するのに使用され得る、インスタンス上に残されている空間を示す。いくつかの実施形態において、コンテナのサイズは、64MBまたは任意のその倍数であってよい。他の実施形態において、コンテナのサイズは、コンテナが作成されるインスタンスのサイズよりも小さいか、またはそれと等しい、どんな任意のサイズであってもよい。いくつかの実施形態において、コンテナのサイズは、コンテナが作成されるインスタンスのサイズよりも小さいか、それと等しいか、またはそれよりも大きい、どんな任意のサイズであってもよい。コンテナのサイズがインスタンスのサイズをどのくらい上回ってよいかは、これらのコンテナが、インスタンスにより提供されるキャパシティを超えて利用されることのある可能性がどの程度かに基づいて決定されてよい。例えば、1GBのメモリサイズを有する5つのコンテナ(合計5GB)が、4GBのメモリサイズを有するインスタンスに作成されてよい。コンテナのそれぞれが、1GBの全キャパシティに達しない場合、コンテナは、オーバーサブスクリプションにもかかわらず、適切に機能し得る。
【0038】
コンテナ156B、157A、157B、157C、158A、159A内部の構成要素は、
図1の実施例に示されていないが、これらのコンテナのそれぞれは、様々なオペレーティングシステム、言語ランタイム、ライブラリ、及び/または、ユーザコードを有してよい。いくつかの実施形態において、インスタンスは、(例えば、インスタンスレベルのキャッシュにおいて)そこにロードされたユーザコードを有してよく、これらのインスタンス内のコンテナはまた、その中にロードされたユーザコードを有してよい。いくつかの実施形態において、ワーカマネージャ140は、アクティブプール140Aにおけるインスタンスのリストを保持してよい。インスタンスのリストはさらに、インスタンスの構成(例えば、OS、ランタイム、コンテナ等)を指定してよい。いくつかの実施形態において、ワーカマネージャ140は、ウォーミングプール130Aにおける(例えば、インスタンスの数及びタイプを含む)インスタンスのリストを利用してよい。他の実施形態において、ワーカマネージャ140は、ウォーミングプール130Aにおける仮想マシンインスタンスの知識を有することなく、ウォーミングプールマネージャ130からコンピュートキャパシティを要求する。
【0039】
要求がフロントエンド120により正常に処理された後、ワーカマネージャ140は、仮想コンピュートシステム110上でユーザコードを実行するための要求にサービスするキャパシティを発見する。例えば、アクティブプール140Aにおいて、その中にロードされた同一のユーザコード(例えば、コンテナ156Aに示したコード156A‐3)を備えるコンテナを有する特定の仮想マシンインスタンスが存在する場合、ワーカマネージャ140は、当該コンテナを要求に割り当ててよく、ユーザコードを当該コンテナにおいて実行させてよい。あるいは、ユーザコードが、仮想マシンインスタンスの1つのローカルキャッシュにおいて利用可能である(例えば、インスタンス158にストアされるが、いずれの個々のコンテナにも属さない)場合、ワーカマネージャ140は、そのようなインスタンス上に新たなコンテナを作成してよく、当該コンテナを要求に割り当ててよく、ユーザコードを当該コンテナにロードさせて、そこで実行させてよい。
【0040】
要求と関連したユーザコードが、アクティブプール140Aにおけるインスタンスのいずれにおいても(例えば、コンテナ、またはインスタンスのローカルキャッシュのいずれにおいても)発見されないとワーカマネージャ140が判定する場合、アクティブプール140Aにおけるインスタンスのいずれかが、要求と関連したユーザに現在割り当てられているかどうか、及び、現在の要求に対処するためのコンピュートキャパシティを有するかどうかを、ワーカマネージャ140は判定してよい。そのようなインスタンスがある場合、ワーカマネージャ140は、インスタンス上に新たなコンテナを作成してよく、当該コンテナを要求に割り当ててよい。あるいは、ワーカマネージャ140はさらに、ユーザに割り当てられるインスタンス上に既存のコンテナを構成してよく、当該コンテナを要求に割り当ててよい。例えば、既存のコンテナが、現在のユーザ要求により要求される特定のライブラリがそのコンテナにロードされている場合に、ユーザコードを実行するのに使用されてよいことを、ワーカマネージャ140は判定してよい。このような場合、ワーカマネージャ140は、当該コンテナ上へ特定のライブラリ及びユーザコードをロードしてよく、ユーザコードを実行するように当該コンテナを使用してよい。
【0041】
アクティブプール140Aが、ユーザに現在割り当てられているいずれのインスタンスも含まない場合、ワーカマネージャ140は、ウォーミングプール130Aから新たな仮想マシンインスタンスをプルし、要求と関連したユーザに当該インスタンスを割り当て、当該インスタンス上に新たなコンテナを作成し、当該コンテナを要求に割り当て、ユーザコードを、当該コンテナにダウンロードさせてそこで実行させる。
【0042】
いくつかの実施形態において、仮想コンピュートシステム110は、ユーザコードの実行を、それが(例えば、フロントエンド120により)受信された後すぐに開始するように適合される。時間間隔は、(例えば、ユーザと関連した仮想マシンインスタンス上のコンテナにおいて)ユーザコードの実行を開始することと、(例えば、フロントエンドにより受信される)ユーザコードを実行するための要求を受信することの間の時間差として決定されてよい。仮想コンピュートシステム110は、所定の期間よりも短い時間間隔内でユーザコードの実行を開始するように適合される。1つの実施形態において、所定の期間は500msである。別の実施形態において、所定の期間は300msである。別の実施形態において、所定の期間は100msである。別の実施形態において、所定の期間は50msである。別の実施形態において、所定の期間は10msである。別の実施形態において、所定の期間は、10msから500msの範囲から選択される任意の値であってよい。いくつかの実施形態において、仮想コンピュートシステム110は、1つまたは複数の条件が満たされる場合、所定の期間よりも短い時間間隔内でユーザコードの実行を開始するように適合される。例えば、1つまたは複数の条件は、(1)要求が受信される時点で、ユーザコードがアクティブプール140Aにおけるコンテナにロードされること、(2)要求が受信される時点で、ユーザコードがアクティブプール140Aにおけるインスタンスのコードキャッシュにストアされること(3)要求が受信される時点で、アクティブプール140Aが、要求と関連したユーザに割り当てられるインスタンスを含むこと、または(4)要求が受信される時点で、ウォーミングプール130Aが、要求に対処するキャパシティを有すること、のいずれか1つを含んでよい。
【0043】
ユーザコードは、
図1のストレージサービス108などの補助サービス106からダウンロードされてよい。
図1に示したデータ108Aは、1人または複数のユーザによりアップロードされたユーザコード、そのようなユーザコードと関連したメタデータ、または、本明細書において説明される1つまたは複数の技法を実施するために仮想コンピュートシステム110により利用される任意の他のデータを含んでよい。ストレージサービス108のみが
図1の実施例に示されているが、仮想環境100は、他のレベルのストレージシステムを含んでよく、そこから、ユーザコードがダウンロードされてもよい。例えば、各インスタンスは、物理的(例えば、インスタンスが起動している物理的なコンピューティングシステムに常駐するローカルストレージ)または論理的(例えば、インスタンスとのネットワーク通信における、仮想コンピュートシステム110の内または外に提供されるネットワークアタッチトストレージシステム)のいずれかで、コンテナが作成されるインスタンスと関連した1つまたは複数のストレージシステムを有してよい。あるいは、コードは、ストレージサービス108により提供されるウェブベースのデータストアからダウロードされてよい。
【0044】
ワーカマネージャ140が、ユーザコード実行要求に応対するのに使用され得るウォーミングプール130Aに、仮想マシンインスタンスの1つをいったん配置すると、ウォーミングプールマネージャ130またはワーカマネージャ140は、ウォーミングプール130Aからインスタンスを取得し、それを、要求と関連したユーザに割り当てる。割り当てられる仮想マシンインスタンスは、ウォーミングプール130Aから取得され、アクティブプール140Aに配置される。いくつかの実施形態において、仮想マシンインスタンスが特定のユーザにいったん割り当てられると、同一の仮想マシンインスタンスは、いずれの他のユーザの要求にサービスするのに使用できない。これは、ユーザリソースの起こり得る混合を防止することにより、セキュリティ上の利点をユーザに提供する。あるいは、いくつかの実施形態において、異なるユーザに属する(または、異なるユーザと関連した要求に割り当てられる)多数のコンテナが、1つの仮想マシンインスタンス上で共存してもよい。このようなアプローチは、利用可能なコンピュートキャパシティの利用を改善し得る。いくつかの実施形態において、仮想コンピュートシステム110は、別個のキャッシュを保守してよく、当該別個のキャッシュにおいて、ユーザコードは、仮想マシンインスタンスのローカルキャッシュと(例えば、ネットワーク104を介してアクセス可能な)ウェブベースのネットワークストレージとの間の中間レベルのキャッシングシステムとしての働きをするようにストアされる。
【0045】
ユーザコードが実行された後、ワーカマネージャ140は、ユーザコードを実行するのに使用されるコンテナを分解して、そのコンテナが占有していたリソースを、インスタンスにおける他のコンテナのために使用されるように解放してよい。あるいは、ワーカマネージャ140は、コンテナを起動し続けて、同一のユーザからの追加の要求にサービスするようにコンテナを使用してよい。例えば、別の要求が、コンテナに既にロードされた同一のユーザコードと関連する場合、当該要求は、同一のコンテナに割り当てられてよく、これにより、新たなコンテナの作成及びコンテナにおけるユーザコードのローディングと関連した遅延が取り除かれる。いくつかの実施形態において、ワーカマネージャ140は、ユーザコードを実行するのに使用されるコンテナが作成されたインスタンスを分解してよい。あるいは、ワーカマネージャ140は、インスタンスを起動し続けて、同一のユーザからの追加の要求にサービスするようにインスタンスを使用してよい。ユーザコードが実行を終了した後に、コンテナ及び/またはインスタンスを起動し続けるかどうかの判定は、閾値時間、ユーザのタイプ、ユーザの平均要求量、及び/または、他の動作条件に基づくものであってよい。例えば、閾値時間が、何らのアクティビティ(例えば、コードの実行)を伴わずに経過した後(例えば、5分、30分、1時間、24時間、30日等)、コンテナ及び/または仮想マシンインスタンスが停止され(例えば、削除される、終了される等)、そこに割り当てられたリソースがリリースされる。いくつかの実施形態において、コンテナが分解される前に経過した閾値時間は、インスタンスが分解される前に経過した閾値時間よりも短い。
【0046】
いくつかの実施形態において、仮想コンピュートシステム110は、入来するコード実行要求にサービスするとき、補助サービス106の1つまたは複数にデータを提供してよい。例えば、仮想コンピュートシステム110は、モニタリング/ロギング/ビリングサービス107と通信してよい。モニタリング/ロギング/ビリングサービス107は、仮想コンピュートシステム110上のコンテナ及びインスタンスのステータスなど、仮想コンピュートシステム110から受信されるモニタリング情報を管理するためのモニタリングサービス、仮想コンピュートシステム110上のコンテナ及びインスタンスにより実施されるアクティビティなど、仮想コンピュートシステム110から受信されるロギング情報を管理するためのロギングサービス、及び、(例えば、モニタリングサービス及びロギングサービスにより管理されるモニタリング情報及び/またはロギング情報に基づいて)仮想コンピュートシステム110上でのユーザコードの実行と関連したビリング情報を発生させるためのビリングサービスを含んでよい。上述のように、(例えば、仮想コンピュートシステム110に代わって)モニタリング/ロギング/ビリングサービス107により実施され得るシステムレベルのアクティビティに加えて、モニタリング/ロギング/ビリングサービス107は、仮想コンピュートシステム110上で実行されるユーザコードに代わって、アプリケーションレベルのサービスを提供してよい。例えば、モニタリング/ロギング/ビリングサービス107は、ユーザコードが仮想コンピュートシステム110上で実行されることに代わって、様々な入力、出力、または他のデータ及びパラメータをモニタ及び/またはログしてよい。1つのブロックとして示されているが、モニタリング、ロギング、及びビリングサービス107は、別個のサービスとして提供されてもよい。モニタリング/ロギング/ビリングサービス107は、リソースマネージャ150が、仮想コンピュートシステム150上で様々なプログラムコードを実行するために使用されるリソースの適切な量を決定することを可能とするように、リソースマネージャ150と通信してよい。
【0047】
いくつかの実施形態において、ワーカマネージャ140は、ワーカマネージャ140により管理されるインスタンス及びコンテナ(例えば、アクティブプール140Aにおけるこれら)に関するヘルスチェックを実施してよい。例えば、ワーカマネージャ140により実施されるヘルスチェックは、ワーカマネージャ140により管理されるインスタンス及びコンテナが、(1)不適切に構成されたネットワークキング及び/または起動構成、(2)枯渇したメモリ、(3)破損したファイルシステム、(4)互換性のないカーネル、及び/または、インスタンス及びコンテナのパフォーマンスを低下させ得る任意の他の問題のうちのいずれかの問題を有するかどうかを判定することを含んでよい。1つの実施形態において、ワーカマネージャ140は、周期的に(例えば、5分毎、30分毎、1時間毎、24時間毎等)ヘルスチェックを実行する。いくつかの実施形態において、ヘルスチェックの頻度は、ヘルスチェックの結果に基づいて自動的に調整されてよい。他の実施形態において、ヘルスチェックの頻度はユーザ要求に基づいて調整されてよい。いくつかの実施形態において、ワーカマネージャ140は、ウォーミングプール130Aにおけるインスタンス及び/またはコンテナに関する同様のヘルスチェックを実施してよい。ウォーミングプール130Aにおけるインスタンス及び/またはコンテナは、アクティブプール140Aにおけるこれらのインスタンス及びコンテナと一緒または別個のいずれかで管理されてよい。いくつかの実施形態において、ウォーミングプール130Aにおけるインスタンス及び/またはコンテナの健全性がアクティブプール140Aとは別個に管理される場合、ウォーミングプールマネージャ130が、ワーカマネージャ140の代わりに、ウォーミングプール130Aにおけるインスタンス及び/またはコンテナに関して上述のヘルスチェックを実施してよい。
【0048】
リソースマネージャ150は、仮想コンピュートシステム110上でユーザコードを実行するための、入来する要求を処理するために割り当てられるリソースの量を管理する。例えば、リソースマネージャ150は、仮想コンピュートシステム110上で実行される様々なプログラムコードに割り当てられる(及び、様々なプログラムコードによって使用される)コンピュートキャパシティをモニタ及び管理するように、フロントエンド120、ウォーミングプールマネージャ130、ワーカマネージャ140、及び/または、補助サービス106と通信してよい。リソースマネージャ150が、仮想コンピュートシステム110内の別個の構成要素として示されているが、リソースマネージャ150の機能性の一部または全部は、フロントエンド120、ウォーミングプールマネージャ130、ワーカマネージャ140、及び/または、補助サービス106によって実施されてもよい。例えば、リソースマネージャ150は、仮想コンピュートシステム110の他の構成要素の1つ内で全面的に、または、仮想コンピュートシステム110の他の構成要素間に分散して、実行されてよい。
図1の実施例において、リソースマネージャ150は、リソース管理データ150Aを含む。リソース管理データ150Aは、仮想コンピュートシステム110上で実行されるプログラムコードのパフォーマンス(例えば、割り当てられるリソースの利用)をモニタ、ログ、調整、改善、及び/または、最適化するように、入来する要求の履歴(例えば、特定のプログラムコードと関連した入来する要求の量、これらの要求が受信されるピーク時間等)、入来する要求によって指定されるリソースレベルの制約、入来する要求に割り当てられるリソースの量、入来する要求により実際に利用される、割り当てられたリソースの部分、及び、リソースマネージャ150により使用され得る任意の他の特性またはメトリックに関するデータを含んでよい。リソース管理データ150Aはまた、ユーザによって指定される、または、仮想コンピュートシステム110上でリソースを管理するためにリソースマネージャ150により決定される任意の管理ポリシーを含んでよく、これはさらに詳細に以下で説明される。
【0049】
上述のように、要求それ自体が、要求と関連したプログラムコードを実行するために使用されるコンピューティングリソース(例えば、メモリ、CPU、ストレージ、ネットワークパケット等)の量を指定してよい。そのような要求が処理され、また、仮想マシンインスタンスが当該要求と関連したユーザに割り当てられた後、リソースマネージャ150は、同量のリソースでコンテナを作成することにより、要求において指定されたリソースの量を、要求に割り当ててよい。例えば、要求が、512MBのメモリが要求と関連したプログラムコードを実行するために使用されるべきであると指定する場合、リソースマネージャ150は、要求と関連したユーザに割り当てられる、インスタンス上で512MBのメモリサイズを有するコンテナを作成してよい。いくつかの実施形態において、要求、プログラムコード、またはユーザと関連した他の構成情報が、プログラムコードを実行するために使用されるコンピューティングリソースの量を指定してよい。このような構成情報は、要求と共に、または、要求とは別個のいずれかで、仮想コンピュートシステム110に提供されてよい。リソースマネージャ150は、要求と関連した特定のプログラムコードのためのデフォルト設定として、要求において指定されたリソースの量を維持してよく、仮想コンピュートシステム110上で処理される任意の後続の要求のために同量を使用してよい。いくつかの実施形態において、1つまたは複数の後続の要求が、デフォルトの量とは異なるリソースの量が、1つまたは複数の後続の要求に割り当てられるべきであることを示す場合、リソースマネージャ150は、1つまたは複数の後続の要求がそのようなデフォルト設定に優先することを可能にしてよい。例えば、後続の要求は、デフォルトの量を10%上回るリソースの量が、プログラムコードを実行するために後続の要求に割り当てられるべきであることを示してよい。代替的な量のリソースが、プログラムコードを実行するために後続の要求に割り当てられるべきであることを後続の要求が示すと判定すると、リソースマネージャ150は、そうした代替的な量のリソースを後続の要求に割り当てる。
【0050】
いくつかの実施形態において、要求において指定されたリソースの量は、要求に割り当てられたリソースの実際の量と異なってもよい。例えば、いくつかのシナリオにおいて、仮想コンピュートシステム110は、要求において指定されたリソースの量を超える閾値パーセンテージである、或る量のリソースを、要求に割り当ててよい。他の状況において、仮想コンピュートシステム110は、要求において指定されたリソースの量より低い閾値パーセンテージである、或る量のリソースを、要求に割り当ててよい。特定のリソースをオーバーサブスクライブする(over‐subscribe)かまたはアンダーサブスクライブする(under‐subscribe)かは、特定のリソース、ユーザ、要求、及び/または、特定のリソースが提供される物理的なハードウェア(例えば、それと関連する任意のトレランスまたは差異)のタイプに基づいて判定されてよい。いくつかの実施形態において、要求に割り当てられるリソースの量は、特定のリソース、ユーザ、要求、及び/または、特定のリソースが提供される物理的なハードウェア(例えば、それと関連する任意のトレランスまたは差異)のタイプに基づいて判定される最大値(または、要求において指定された量を上回るパーセンテージ)より少なくてよく、及び/または、最小値(または、要求において指定された量を下回るパーセンテージ)よりも多くてよい。
【0051】
いくつかの実施形態において、要求において指定される特定のタイプのリソース(例えば、メモリ)は、仮想コンピュートシステム110上で利用可能な他のタイプのリソースを割り当てるためのガイドラインとしての働きをする。例えば、512MBのメモリが、要求と関連したプログラムコードを実行するために使用されるべきであると要求が指定し、また、ユーザに割り当てられる、インスタンス上のメモリの全体の(例えば、物理的または仮想的な最大の)量または利用可能な(例えば、他のコンテナにより現在占有されていないリソース)量が2GBである場合、インスタンス上で利用可能な他のタイプのリソース(例えば、CPU、ストレージ、ネットワークパケット等)がまた、比例した量で割り当てられる(例えば、CPUの4分の1、ストレージの4分の1、ネットワークパケットの4分の1等がコンテナに割り当てられる)。一方で、ユーザに割り当てられる、インスタンス上のメモリの全体量または利用可能な量が1GBである場合、CPUの半分、ストレージの半分、ネットワークパケットの半分がコンテナに割り当てられるだろう。いくつかの実施形態において、要求により指定され得る、あるいは、コンテナに割り当てられ得るメモリの量は、64MBインクリメントにおいて、64MBから1GBの範囲に及ぶ。いくつかの実施形態において、他の量が、要求によって指定されてよく、及び/または、コンテナに割り当てられてよい。メモリが実施例として使用されたが、任意の他のリソースが選択されてもよく、また、要求を処理するために(例えば、プログラムコードを実行するために)割り当てられるべきリソース全ての量を設定するためのガイドラインとして使用されてもよい。いくつかの実施形態において、1つの形態のリソース(例えば、最も理解し易く、最もユーザフレンドリーであり、最もベーシックであり、絶対数において最大、または絶対数において最小のもの)が、全ての他の形態のリソースの代表であるように選択される。要求は、特定のタイプのリソースの量の代わりに、リソース全てを割り当てるために使用され得るパーセンテージを指定してもよい。さらに、要求は、1つよりも多いリソースの量を指定してよい。
【0052】
いくつかの実施形態において、リソースマネージャ150は、新たなコンテナを作成し、且つ、指定された量のリソースをそうしたコンテナに割り当てる代わりに、指定された量のリソースを有する既存のコンテナを配置してよく、また、当該既存のコンテナにおいてプログラムコードを実行させてよい。既存のコンテナに割り当てられたリソースの量は、指定された量のリソースに正確に一致しないが、指定された量のリソースの閾値パーセンテージ以内にある。いくつかの実施形態において、リソースマネージャ150は、より少ないまたはより多い量のコンピューティングリソース(複数可)を割り当てることにより、既存のコンテナをリサイズしてよく、また、特定のプログラムコードと関連したプログラムコードに対処するように、調整されたリソースサイズを有する既存のコンテナを指定してよい。リソースマネージャ150が既存のコンテナを動的にリサイズし得るかどうかは、プログラムコードにより使用される言語ランタイムに依存してよい。例えば、Java(登録商標)ランタイムは動的なリサイジングが可能でなく、一方で、Python(登録商標)ランタイムは可能であろう。
【0053】
指定された量のリソースを有するコンテナが作成または配置された後、要求と関連したプログラムコードがコンテナにおいて実行される。コンテナに割り当てられた(例えば、ユーザによって要求される)リソースの量、及び/または、プログラムコードにより実際に利用されたリソースの量は、さらなる分析のために、(例えば、モニタリング/ロギング/ビリングサービス107及び/またはリソースマネージャ150により)ログされてよい。例えば、ログされた情報は、コンテナにおいてプログラムコードの1つまたは複数の実行の間に使用される、メモリの量、CPUサイクルの量、ネットワークパケットの量、及びストレージの量を含んでよい。さらに、ログされた情報は、リソース利用、誤り率、レイテンシ、及び、プログラムコードの実行の間に発生する任意のエラーまたは例外を含んでよい。いくつかの実施形態において、コンテナに割り当てられるリソースの量に関連した任意のエラー(例えば、メモリ不足の例外)が、特別な印でタグ付けされ、リソースマネージャ150によってさらに分析される。
【0054】
いくつかの実施形態において、リソースマネージャ150は、ユーザの多数のクラスを作成または利用してよく、また、ユーザの異なるクラスのために異なるルールを適用してよい。例えば、より高度なユーザには、一層の制御(例えば、個々のリソースパラメータの制御)が与えられてよく、一方で、その他のユーザには、彼らは、1つの代表的なパラメータのみを制御することが可能とされてよく、その他のパラメータは代表的なパラメータに基づいたサイズとされてよい。
【0055】
いくつかの実施形態において、リソースマネージャ150は、モニタリング/ロギング/ビリングサービス107及び/またはリソースマネージャ150によりログされる情報に基づいて、ユーザに、プログラムコードのパフォーマンスを改善するため、または、仮想コンピュートシステム110上でのプログラムコードの実行と関連したコストを削減するため、ユーザが何をし得るか関していくつかのガイダンスを提供する。例えば、リソースマネージャ150は、メモリ不足の例外の繰り返される発生を経験した後、ユーザが常に、特定のユーザコードを実行するためにメモリ(または他のリソース)を過少に設定しているようであるという指示をユーザに提供してよい。同様に、特定のユーザコードの呼び出しが、慢性的に、それらに割り当てられるリソースのごく一部しか使用していないと判定した後、リソースマネージャ150は、ユーザがメモリ(または他のリソース)を過多に設定しているであろうという指示をユーザに提供してよい。指示は、特定のリソース(複数可)が調整されるべき量を指定してよい。いくつかの実施形態において、このような指示は、閾値数のエラー、例外、または他の明確な状況(例えば、レイテンシの増加)がリソースマネージャ150によって処理された後に、ユーザに提供される。リソースマネージャ150は、eメール、プッシュ通知サービス、SMS、ソーシャルネットワークサービス等を含む任意の通知機構を介して、指示を提供してよい。いくつかの実施形態において、リソースサイジング調整が必要とされるという指示は、1つまたは複数のリソースを調整すべき量が閾値の値またはパーセンテージを超える場合に、ユーザに提供される。例えば、リソースマネージャ150が、良好または最適のパフォーマンスを達成するために、ユーザにより指定されたメモリサイズを0.5%増加すべきであると判定する場合、リソースマネージャ150は、通知をユーザに全く送信しなくてもよいが、リソースマネージャ150が、良好または最適のパフォーマンスを達成するために、ユーザにより指定されたメモリサイズを10%増加すべきであると判定する場合、リソースマネージャ150は、通知をユーザに送信してよい。
【0056】
いくつかの実施形態において、リソースマネージャ150は、プログラムコードの実行がリソースの要求量を超えることが可能とされる場合、制限されたオーバーサブスクリプションを提供してよい。例えば、要求が64MBのメモリを指定した場合、リソースマネージャ150は、プログラムコードが最大70または80MBのメモリを使用することを可能としてよい。このような場合、プログラムコードは正常に実行されてよいが、プログラムコードが、要求された量のメモリを超えており、また、プログラムコードを実行するための更なる要求が、より多い量のメモリを指定すべきであるという通知が、ユーザに提供されてよい。オーバーサブスクリプションは、閾値数の使用量の後、失効してよい。
【0057】
いくつかの実施形態において、仮想コンピュートシステム110は、個々のコード実行要求に割り当てられるリソースの量を自動的に調整してよい。例えば、ユーザがリソースパラメータを指定し得る他の実施形態において、ユーザが適正な量のリソースを指定しそこなう場合、プログラムコードの実行は、パフォーマンス結果に悩まされることがある。例えば、要求が、64MBのメモリが、特定のプログラムコードを実行するために使用されるべきであると指定し、当該プログラムが、実際には実行のために1GBを必要とする場合、ユーザは、多くの問題に遭遇するおそれがある(例えば、プログラムコードが、単に実行できないおそれがある)。仮想コンピュートシステム110が、要求において指定されたリソースの量を調整するためにユーザに依拠する場合、問題がユーザによって対処されるまで、仮想コンピュートシステム110は、数千または数百万の失敗した要求を受信することがある。このようなシナリオにおいて、要求において指定されたリソースの量が不十分であると判定する際、リソースマネージャ150は、特定のプログラムコードを実行するための、入来する要求に割り当てられるリソースの量を自動的に調整してよい。いくつかの実施形態において、閾値数のエラー、例外、または他の明確な状況(例えば、レイテンシの増加)がリソースマネージャ150によって処理された後に、このような調整が成される。それゆえ、自動的なリソース調整がリソースマネージャ150によって成されても、最初のいくつかの要求は失敗することがあるが、後続の要求は、ユーザの介入を伴わなくとも、所望の結果を最終的に生成し得る。
【0058】
いくつかの実施形態において、リソースマネージャ150は、個々のプログラムコードを実行するために、リソースサイジングを改善するようにコード特有の特性を利用してよい。例えば、画像処理を扱うプログラムコードは、多くのメモリを要求することがあり、一方で、データベースアクセスを作成するプログラムコードは、同量のメモリを必要としないであろう。別の実施例において、特定のプログラムコードにとっては、64MBが大抵の場合に十分であろうが、仮想コンピュートシステム110が、毎晩午後8時に、ユーザと関連したコード実行要求を一気に受信するかもしれず、このため、リソースマネージャ150は、ユーザと関連した要求に対処するコンテナ及び/またはインスタンスに、より多くのメモリを割り当てることがある。このようなコード特有の特性は、リソースマネージャ150によって維持されてよく、個々のプログラムコードのリソースサイジングは、それに応じて調整されてよい。
【0059】
いくつかの実施形態において、リソースマネージャ150は、最大量のリソースをプログラムコードに初めに割り当ててよく、プログラムコードを実行した後に、プログラムコードが実際には最大量の1/10を使用しているとリソースマネージャ150が判定する場合、リソースマネージャ150は、プログラムコードを実行するための後続の要求に、最大量の半分を割り当ててよい。プログラムコードが最大量の1/10を使用しているとリソースマネージャ150が依然として判定する場合、リソースマネージャ150はさらに、プログラムコードに割り当てられたリソースの量を半分に削減してよい。プログラムコードがプログラムコードに割り当てられたリソースのかなりの部分(例えば、50%、75%、または別の閾値の値)を使用するまで、リソースマネージャ150はこうしたプロセスを繰り返してよい。
【0060】
いくつかの実施形態において、ユーザは、リソースマネージャ150の挙動を規定するリソース管理ポリシーを指定してよい。例えば、実に価格に敏感なユーザは、そのようにすることが彼または彼女のコストを最小化する場合、喜んで時折のエラーを経験するままにするであろう。それゆえ、このようなユーザは、現在指定された量のリソースが、時折、メモリ不足エラーという結果となっても、彼または彼女のプログラムコードを実行するために割り当てられるリソースの量を増加させることを望まないことがある。一方で、非常にエラーに敏感なユーザは、エラーまたは誤り(例えば、メモリ不足エラー、非常に高いレイテンシ、またはいくつかの他の問題)が起こるのを回避するために、どんな手段を取るのも厭わないであろう。このようなユーザは、プログラムコードを実行するために割り当てられるリソースが時として過少利用されていても、彼または彼女のプログラムコードが遭遇するエラーの数を最小にすることを望むことがある。いくつかの実施形態において、ユーザは、コスト、利用、リソースの量等のストップリミット(例えば、下限及び/または上限)を指定してよい。ユーザは、そうしたストップリミットを、指定された時間期間でのみそれらが適用可能であるようにさらに限定してよい。例えば、ユーザは、ユーザがプログラムコードを実行させるのに費やしたい金額の最小量及び最大量を指定してよいが、ユーザは、各四半期の最終週の間、リミットが適用されるべきでないとさらに指定してよい。
【0061】
いくつかの実施形態において、リソースマネージャ150は、一定のリソースを、そのようなリソースがコード実行要求によって十分に利用されていないとリソースマネージャ150が判定する場合、選択的にオーバーサブスクライブしてよい。例えば、リソースマネージャ150は、1GBのメモリを、4GBの仮想または物理メモリを有する仮想マシンインスタンス上の5つの異なるコンテナに割り当ててよい。オーバーサブスクリプションの程度は、1つのインスタンス上に作成されたこれらのコンテナが、インスタンスのリソースの最大量を集合的に使い切るかもしれない可能性に基づくものであってよい。いくつかの実施形態において、ユーザは、割引値段で、オーバーサブスクライブされたリソースの利用を選択するという選択肢を与えられてよい。
【0062】
いくつかの実施形態において、要求は、任意のリソースレベルの制約を指定しなくてもよいが、代わりに、リソースの量が仮想コンピュートシステム110によって自動的に判定されること、及び、仮想コンピュートシステム110により判定されたリソースの量がユーザに伝えられること(例えば、この結果、ユーザは、ユーザの要求にサービスするために割り当てられているリソースの量を知る)を要求してよい。あるいは、要求は、ユーザコードを実行するために使用されるべきリソースの量を指定してよいが、また、要求された量のリソースが、コード実行パフォーマンスに著しく影響を及ぼすことなく、(例えば、他のユーザとそれをシェアすることにより)オーバーサブスクライブされ得ると仮想コンピュートシステム110が判定する場合、仮想コンピュートシステム110は、より少なく(例えば、指定された量のリソースが通常かかるコストよりも少なく)ユーザにチャージすることによって、そのようにし得ることを示してよい。
【0063】
いくつかの実施形態において、特定のコンテナに割り当てられるリソースの量は、当該特定のコンテナを縮小または拡張することによって(例えば、既存のコンテナに割り当てられるリソースの量を修正することによって)調整される。あるいは、リソースの量は、調整された量のリソースを有する新たなコンテナを作成すること、及び、当該新たなコンテナに何らかの将来的な要求を提供することにより古いコンテナを消滅させることによって調整されてよい。いくつかの実施形態において、リサイジングは、プログラムコードにより使用される特定の言語ランタイムの特性に基づいて実施される。(例えば、動的なリソースリサイジングができるものもあれば、できないものもある)。
【0064】
リソースマネージャ150は、ユーザコードを実行するのに使用されるコンテナをサイジングする(例えば、コンテナに割り当てられるべきリソースの量を決定する)ためのリソースサイジングユニットと、リソースの量を、仮にするとしてもどの程度調整すべきかに関する通知をユーザに提供するためのリソースガイダンスユニットとを含んでよい。リソースマネージャ150の例示的な構成が、
図2を参照して以下でさらに詳細に説明される。
【0065】
図2は、仮想コンピュートシステム110における仮想マシンインスタンスを管理するコンピューティングシステム(リソースマネージャ150と呼ばれる)の一般的なアーキテクチャを表す。
図2に表されたリソースマネージャ150の一般的なアーキテクチャは、本開示の態様を実行するのに使用され得るコンピュータハードウェア及びソフトウェアモジュールの構成を含む。リソースマネージャ150は、
図2に示したものよりもさらに多くの(または少ない)要素を含んでよい。しかしながら、可能な開示を提供するため、これらの一般に従来の要素の全てが示される必要はない。図示するように、リソースマネージャ150は、処理ユニット190、ネットワークインターフェース192、コンピュータ可読媒体ドライブ194、入力/出力デバイスインターフェース196を含み、それらの全てが、コミュニケーションバスを介して互いに通信してよい。ネットワークインターフェース192は、1つまたは複数のネットワークまたはコンピューティングシステムへの接続を提供してよい。処理ユニット190は、それゆえ、他のコンピューティングシステムまたはサービスから、ネットワーク104を介して情報及び命令を受信してよい。処理ユニット190はまた、メモリ180へ及びメモリ180から通信してよく、入力/出力デバイスインターフェース196を介して随意のディスプレイ(図示せず)のための出力情報をさらに提供してよい。入力/出力デバイスインターフェース196はまた、随意の入力デバイス(図示せず)から入力を受け取ってよい。
【0066】
メモリ180は、本開示の1つまたは複数の態様を実行するために、処理ユニット190が実行する(いくつかの実施形態において、モジュールとしてグループ化された)コンピュータプログラム命令を含んでよい。メモリ180は、一般に、RAM、ROM、及び/または、他の永続的な、補助的または非一時的なコンピュータ可読媒体を含む。メモリ180は、リソースマネージャ150の一般的な管理及び操作において処理ユニット190による使用のためのコンピュータプログラム命令を提供するオペレーティングシステム184をストアしてよい。メモリ180はさらに、本開示の態様を実行するためのコンピュータプログラム命令及び他の情報を含んでよい。例えば、1つの実施形態において、メモリ180は、例えば、コンピューティングデバイスにインストールされたブラウザまたはアプリケーションなど、ナビゲーション及び/またはブラウジングインターフェースを介して、コンピューティングデバイス上に表示するためのユーザインターフェース(及び/またはそれに対する命令)を生成するユーザインターフェースユニット182を含む。加えて、メモリ180は、例えば、ユーザプログラムコード及び/またはライブラリにアクセスするために、1つまたは複数のデータリポジトリ(図示せず)を含んでよく、及び/または、これと通信してよい。
【0067】
ユーザインターフェースユニット182に加えて、及び/または、それと関連して、メモリ180は、処理ユニット190により実行され得るリソースサイジングユニット186及びリソースガイダンスユニット188を含んでよい。1つの実施形態において、ユーザインターフェースユニット182、リソースサイジングユニット186、及びリソースガイダンスユニット188は、個々にまたは集合的に、さらに以下で説明するように、例えば、仮想コンピュートシステム110上でのプログラムコードの実行のモニタリング及びロギング、特定のコンテナ及び/または要求に割り当てられるリソースの量を調整する必要性を判定すること、リソースの量を調整する必要性に関してユーザに通知を提供すること、リソースの量を自動的に調整すること等、本開示の様々な態様を実行する。
【0068】
リソースサイジングユニット186は、仮想コンピュートシステム110上でのユーザコードの実行をモニタし、ユーザコードを実行するために、指定された量のリソース有するコンテナを提供し、当該コンテナに割り当てられるリソースの量を調整する。例えば、リソースサイジングユニット186が、特定のプログラムコードを実行するための要求が常にメモリ不足エラーを受けていると判定する場合、リソースサイジングユニット186は、特定のプログラムコードを実行するための後続の要求に割り当てられるメモリの量を増加させてよい。一方で、リソースサイジングユニット186が、特定のプログラムコードを実行するための要求が常に、要求に割り当てられるリソースのごく一部しか使用していないと判定する場合、リソースサイジングユニット186は、特定のプログラムコードを実行するための後続の要求に割り当てられるメモリの量を減少させてよい。
【0069】
リソースガイダンスユニット188は、ユーザと関連した要求にサービスするために割り当てられているリソースの量を調整する必要性に関して、ユーザに通知を提供する。例えば、通知は、ユーザが常に、特定のプログラムコードを実行するために、過少または過多である量を指定していることを示してよい。通知は、改善された、または最適のパフォーマンスのために、リソースの量をどの程度調整すべきかをさらに指定してよい。
【0070】
リソースサイジングユニット186及びリソースガイダンスユニット188がリソースマネージャ150の一部として
図2に示されているが、他の実施形態において、リソースサイジングユニット186及びリソースガイダンスユニット188の全てまたは一部は、仮想コンピュートシステム110及び/または別のコンピューティングデバイスの他の構成要素によって実行されてもよい。例えば、本開示の一定の実施形態において、仮想コンピュートシステム110と通信する別のコンピューティングデバイスは、リソースマネージャ150の一部として示されるモジュール及び構成要素と同様に作動するいくつかのモジュールまたは構成要素を含んでよい。
【0071】
次に
図3に注目すると、仮想コンピュートシステム110の1つまたは複数の構成要素(例えば、リソースマネージャ150)により実行されるルーチン300が説明される。ルーチン300が、リソースマネージャ150による実施態様に関して説明されるが、当業者は、代替的な構成要素がルーチン300を実行してよいこと、または、ブロックの1つまたは複数が、異なる構成要素により、もしくは分散して実行されてよいことを理解するであろう。
【0072】
説明的なルーチン300のブロック302で、リソースマネージャ150は、仮想コンピュートシステム110上でプログラムコードを実行するための要求に基づいて、第1のコンピューティングリソースのユーザ指定の量を決定する。例えば、第1のコンピューティングリソースは、仮想コンピュートシステム110上でプログラムコードを実行するために使用され得る、メモリ、CPU、ディスク空間、または任意の他のコンピューティングリソースであってよい。仮想コンピュートシステム110上でプログラムコードを実行するための要求は、プログラムコードを実行するためにどのくらいのリソースを割り当てるべきかを示してよい。
【0073】
次に、ブロック304で、リソースマネージャ150が、第1のコンピューティングリソースのユーザ指定の量に基づいて、第2のコンピューティングリソースの対応する量を決定する。例えば、リソースマネージャ150は、第1のコンピューティングリソースのユーザ指定の量と、要求に割り当てられ得る、第1のコンピューティングリソースの最大量との比を算出することにより、第2のコンピューティングリソースの対応する量を決定してよい。ユーザ指定の量が512MBのメモリであり、要求に割り当てられ得るメモリの最大量が1GBである場合、リソースマネージャ150は、対応する量は、要求に割り当てられ得る第2のコンピューティングリソースの最大量の2分の1とすべきであると判定してよい。例えば、第2のコンピューティングリソースがディスク空間であり、8GBのディスク空間が割り当てに利用可能である場合、リソースマネージャ150は、対応する量は4GBとすべきであると判定してよい。
【0074】
ブロック306で、リソースマネージャ150は、第1のコンピューティングリソース(例えば、メモリ)のユーザ指定の量、及び、第2のコンピューティングリソース(例えば、ディスク空間)の対応する量を、プログラムコードを実行するために要求に割り当てる。上記の実施例において、リソースマネージャ150は、仮想コンピュートシステム上で利用可能な仮想マシンインスタンスの1つにコンテナを作成してよく、その場合、コンテナは512MBのメモリ及び4GBのディスク空間を割り当てられる。第1及び第2のコンピューティングリソースが
図3の実施例において使用されたが、追加のリソースが使用されてもよく、そのような追加のリソースはまた、第1のコンピューティングリソースのユーザ指定の量と最大量との比に従ったサイズとされてよい。
【0075】
図3のルーチン300がブロック302〜306を参照して上述されたが、本明細書において説明される実施形態は、そのように限定されず、1つまたは複数のブロックが、本開示の精神から逸脱することなく、省略、修正、または交換されてよい。
【0076】
次に
図4に注目すると、仮想コンピュートシステム110の1つまたは複数の構成要素(例えば、リソースマネージャ150)により実行されるルーチン400が説明される。ルーチン400が、リソースマネージャ150による実施態様に関して説明されるが、当業者は、代替的な構成要素がルーチン400を実行してよいこと、または、ブロックの1つまたは複数が、異なる構成要素により、もしくは分散して実行されてよいことを理解するであろう。
【0077】
説明的なルーチン400のブロック402で、リソースマネージャ150は、仮想コンピュートシステム110上でプログラムコードを実行するための要求に基づいて、コンピューティングリソースのユーザ指定の量を決定する。例えば、コンピューティングリソースは、仮想コンピュートシステム110上でプログラムコードを実行するために使用され得る、メモリ、CPU、ディスク空間、または任意の他のコンピューティングリソースであってよい。ユーザ指定の量は特定のリソース(例えば、メモリ)の量であってよく、そうした特定のリソースの量は、プログラムコードを実行するためにどのくらいの特定のリソースを割り当てるべきかを指定する要求において示される(例えば、要求に含まれ、あるいは、要求に含まれる情報に基づいて判定可能である)。例えば、プログラムコードの開発者は、コード実行要求において、彼または彼女のプログラムコードを実行するためにどのくらいのメモリ(または他のコンピューティングリソース)を割り当てるべきかを指定してよい。
【0078】
次に、ブロック404で、リソースマネージャ150は、プログラムコードを実行するためにコンピューティングリソースのユーザ指定の量を割り当てる。例えば、リソースマネージャ150は、ユーザと関連し、且つ、アクティブプール140A内にあるインスタンスにおいて、コンピューティングリソースのユーザ指定の量を有するコンテナを作成してよい。別の実施例において、リソースマネージャ150は、ウォーミングプール130Aからインスタンスを選択し、当該選択されたインスタンスをユーザに割り当て、当該選択されたインスタンスにおいて、コンピューティングリソースのユーザ指定の量を有するコンテナを作成してよい。
【0079】
ブロック406で、リソースマネージャ150は、プログラムコードの1つまたは複数の実行の間、プログラムコードによるコンピューティングリソースの使用量をモニタする。例えば、リソースマネージャ150は、プログラムコードを、要求に対処するように指定されたコンテナ上にロードさせてよく、また、プログラムコードを当該コンテナにおいて実行させてよい。リソースマネージャ150は、プログラムコードの1つまたは複数の実行の間、1つまたは複数のパフォーマンス特性をモニタしてよい。このようなパフォーマンス特性は、誤り率、リソース利用、レイテンシ、使用されるリソースの%、ユーザにより要求されるリソースの%等を含んでよい。
【0080】
ブロック408で、リソースマネージャ150は、プログラムコードによるコンピューティングリソースの使用量をユーザ指定の量と比較し、ブロック410で、リソースマネージャ150は、当該比較に基づいて、プログラムコードを実行するために割り当てられる、コンピューティングリソースのユーザ指定の量を調整すべきであると判定する。例えば、ユーザが512MBのメモリを要求したが、プログラムコードの1つまたは複数の実行の間、平均して64MBしか使用されなかった場合、リソースマネージャ150は、ユーザ指定の量が、プログラムコードのパフォーマンスに著しく影響を及ぼすことなく削減され得ると判定してよい。一方で、ユーザが512MBのメモリを要求し、また、プログラムコードの1つまたは複数の実行の間、要求された量のほとんど全てが使用中であった場合、リソースマネージャ150は、過剰利用の問題を解決するために、ユーザ指定の量を増加すべきであると判定してよい。
【0081】
ブロック412で、リソースマネージャ150は、ユーザ指定の量をどの程度調整すべきかという指示を提供する。例えば、リソースマネージャ150は、ユーザ指定の量を適切な量だけ増加または削減すべきであることを示すeメール通知をユーザに提供してよい。
【0082】
図4のルーチン400がブロック402〜412を参照して上述されたが、本明細書において説明される実施形態はそのように限定されず、1つまたは複数のブロックが、本開示の精神から逸脱することなく、省略、修正、または交換されてよい。例えば、ルーチン400が1つのコンピューティングリソース(例えば、メモリ)に関して説明されたが、同様の技法は、残りのリソース次元(例えばCPU、ネットワーク、ディスク等)のそれぞれ上で実行されてよい。さらに、ルーチン400が、リソースベースで、1つのコンピューティングリソースをモニタ及び比較(例えば、要求された量のメモリ対実際に使用された量のメモリの比較、要求された量の処理能力対実際に使用された量の処理能力の比較等)するものとして説明されたが、同様の技法は、複合物ベースでルーチン400を実施するのに使用されてもよい。例えば、リソースマネージャ150は、要求と関連した最も制約されたリソースの、要求されたまたは割り当てられた量を、要求と関連した、プログラムコードにより使用される最も制約されたリソースの実際の量と比較してよく、また、最も制約されたリソースの要求されたまたは割り当てられた量が、プログラムコードにより使用される最も制約されたリソースの実際の量より少ないまたはより多い閾値パーセンテージ内にある場合、ブロック412における指示が、ユーザに提供されてよい。別の実施例において、リソースマネージャ150は、リソース次元のそれぞれについての利用の平均的なパーセンテージを算出してよく、平均的なパーセンテージが閾値利用値より低いまたはより高い場合(例えば、10%より低い、90%より高い等)、ユーザに指示を提供してよい。ユーザに提供される指示はまた、コンピューティングリソースのそれぞれの過剰使用または過少使用の分析を含んでよい。例えば、リソースマネージャ150は、次を述べる指示を提供してよい。「貴殿は現在、512MBのリソースサイジングダイアルをお持ちです。貴殿はそれ以上のメモリを使用したことがないので、これはメモリパフォーマンスに適したものです。しかしながら、弊社は、貴殿が現在の設定でネットワークリソースをたびたび使い果たしていると通知してきました。貴殿は、一層多くのネットワークリソースを獲得し、改善されたコード実行パフォーマンスを達成するために、リソースサイジングダイアルを10%増加するとよいでしょう。」
【0083】
次に
図5に注目すると、仮想コンピュートシステム110の1つまたは複数の構成要素(例えば、リソースマネージャ150)により実行されるルーチン500が説明される。ルーチン500が、リソースマネージャ150による実施態様に関して説明されるが、当業者は、代替的な構成要素がルーチン500を実行してよいこと、または、ブロックの1つまたは複数が異なる構成要素により、または分散して実行されてよいことを理解するであろう。
【0084】
説明的なルーチン500のブロック502で、リソースマネージャ150は、プログラムコードを実行するためにコンピューティングリソースの第1の量を割り当てる。例えば、リソースマネージャ150は、ユーザと関連し、且つ、アクティブプール140A内にあるインスタンスにおいて、コンピューティングリソースの第1の量を有するコンテナを作成してよい。別の実施例において、リソースマネージャ150は、ウォーミングプール130Aからインスタンスを選択し、当該選択されたインスタンスをユーザに割り当て、当該選択されたインスタンスにおいてコンピューティングリソースの第1の量を有するコンテナを作成してよい。コンピューティングリソースは、仮想コンピュートシステム110上でプログラムコードを実行するために使用され得る、メモリ、CPU、ディスク空間、または任意の他のコンピューティングリソースであってよい。第1の量は、要求に含まれる情報、及び/または、要求に含まれるそうした情報に基づいて確認可能な情報に基づいて、リソースマネージャ150よって判定されてよい。このような情報は、プログラムコード、ユーザタイプ(例えば、大規模ユーザまたは小規模ユーザ)、プログラムコードの特性(例えば、回線の数、高額通話の数等)等をコード化するのに使用されるプログラミング言語を含んでよい。
【0085】
次に、ブロック504で、リソースマネージャ150は、プログラムコードの1つまたは複数の実行の間、プログラムコードによるコンピューティングリソースの使用量をモニタしてよい。例えば、リソースマネージャ150は、プログラムコードを、要求に対処するように指定されたコンテナ上にロードさせてよく、また、プログラムコードを当該コンテナにおいて実行させてよい。リソースマネージャ150は、プログラムコードの1つまたは複数の実行の間、1つまたは複数のパフォーマンス特性をモニタしてよい。このようなパフォーマンス特性は、誤り率、リソース利用、レイテンシ、使用されるリソースの%、ユーザにより要求されるリソースの%等を含んでよい。
【0086】
ブロック506で、リソースマネージャ150は、プログラムコードによるコンピューティングリソースの使用量に基づいて、プログラムコードを実行するために割り当てられるコンピューティングリソースの第1の量を調整すべきであると判定する。例えば、ブロック502で512MBのメモリがプログラムコードを実行するために割り当てられたが、プログラムコードの1つまたは複数の実行の間、平均して64MBしか使用されなかった場合、リソースマネージャ150は、プログラムコードを実行するために割り当てられ量が、プログラムコードのパフォーマンスに著しく影響を及ぼすことなく削減され得ると判定してよい。一方で、512MBのメモリがプログラムコードを実行するために割り当てられ、また、プログラムコードの1つまたは複数の実行の間、割り当てられた量のほとんど全てが使用中であった場合、リソースマネージャ150は、過剰利用の問題を解決するために、プログラムコードを実行するために割り当てられた量を増加すべきであると判定してよい。
【0087】
ブロック508で、リソースマネージャ150は、第1の量とは異なる、コンピューティングリソースの第2の量を決定し、ブロック510で、リソースマネージャ150は、プログラムコードを実行するためにコンピューティングリソースの第2の量を割り当てる。512MBが割り当てられ、且つ、64MBが平均して使用された実施例において、リソースマネージャ150は、割り当てられたメモリの量が、プログラムコードのパフォーマンスに影響を及ぼすことなく128MBに安全に削減され得ると判定してよく、また、プログラムコードを実行するために(例えば、プログラムコードの将来的な実行のために)128MBを割り当ててよい。
【0088】
図5のルーチン500がブロック502〜512を参照して上述されたが、本明細書において説明される実施形態はそのように限定されず、1つまたは複数のブロックが、本開示の精神から逸脱することなく、省略、修正、または交換されてよい。例えば、
図4に関して述べられたように、ルーチン500が1つのコンピューティングリソース(例えば、メモリ)に関して説明されたが、同様の技法は、残りのリソース次元(例えば、CPU、ネットワーク、ディスク等)のそれぞれ上で実施されてよい。さらに、ルーチン500は、リソースベースで、1つのコンピューティングリソースをモニタ及び比較(例えば、現在割り当てられた量のメモリ対実際に使用された量のメモリの比較、現在割り当てられた量の処理能力対実際に使用された量の処理能力の比較等)するものとして説明されたが、同様の技法は、複合物ベースでルーチン500を実施するのに使用されてもよい。例えば、リソースマネージャ150は、要求と関連した最も制約されたリソースの、要求されたまたは割り当てられた量を、要求と関連した、プログラムコードにより使用される最も制約されたリソースの実際の量と比較してよく、また、ブロック506における決定は、最も制約されたリソースの要求されたまたは割り当てられた量が、プログラムコードにより使用される最も制約されたリソースの実際の量より少ないまたはより多い閾値パーセンテージ内にあるかどうかに基づくものであってよい。別の実施例において、リソースマネージャ150は、リソース次元のそれぞれについての利用の平均的なパーセンテージを算出してよく、また、平均的なパーセンテージが閾値利用値より低いまたはより高いかどうか(例えば、10%より低い、90%より高い等)に基づいて決定してよい。
【0089】
図6〜
図8を参照すると、例示的な実施形態に従った、リソースマネージャ150により実施されるリソースリサイジングが示される。
図6の実施例において、コンテナ158Aが、特定のプログラムコードと関連した入来するコード実行要求を処理するために利用されている。
図6に示すように、コンテナ158Aは、平均的なリソース利用が27%である。例えば、特定のプログラムコードは、コンテナ158Aにおける特定のプログラムコードの1つまたは複数の実行の間、コンテナ158Aに割り当てられたリソース(複数可)のうちの27%を利用している。リソースマネージャ150は、リソース利用を閾値の値(例えば、75%)と比較してよく、また、現在のリソース利用は少な過ぎであり、コンテナ158Aに割り当てられたリソース(複数可)の量を削減すべきであると判定してよい。
【0090】
図7において、リソースマネージャ150は、特定のプログラムコードを実行するために、コンテナ158Aに割り当てられたリソース(複数可)の量を(例えば、インスタンス158と関連したユーザの要求で、または、利用に基づいてリソースマネージャ150により成される判定に基づいて)削減しており、リソース利用は、コンテナ158Aにおける特定のプログラムコードの1つまたは複数の追加の実行の後、40%に増加している。既存のコンテナ(例えば、コンテナ158A)のリソースサイジングが調整されたが、別の実施形態において、そこに割り当てられるリソース(複数可)の調整された量を有する新たなコンテナが代わりに作成されてもよく、既存のコンテナは空にされてもよい。
図8に示すように、コンテナ158Aに割り当てられたリソース(複数可)の量は、さらに、リソース利用を80%に改善するように調整されている。リソースマネージャ150は、リソース利用レベルを閾値の値(例えば75%)と比較して、さらなるリソースリサイジングは必要でないと判定してよく、また、リソースマネージャ150が、さらなるリサイジングが必要とされると後に判定するまで、コンテナ158Aのリソースレベルを現在のレベルで維持してよい。
図6〜
図8に示した他の構成要素は
図1に示したものと同一であり、それゆえ、その詳細は簡潔さのために省略される。
【0091】
図9〜
図11を参照すると、別の例示的な実施形態に従った、リソースマネージャ150により実施されるリソースリサイジングが示される。
図9の実施例において、コンテナ159Aは、特定のプログラムコードと関連した入来するコード実行要求を処理するために利用されている。
図9に示すように、コンテナ159Aは、平均的な誤り率が90%である。例えば、特定のプログラムコードの実行の90%が、1つまたは複数のエラーを生成したおそれがあり、または、正常に実行するのに失敗したおそれがある。リソースマネージャ150は、リソース利用を閾値の値(例えば、5%)と比較してよく、また、現在の誤り率が高すぎであり、コンテナ159Aに割り当てられたリソース(複数可)の量を増加すべきであると判定してよい。
【0092】
図10において、リソースマネージャ150は、特定のプログラムコードを実行するために、コンテナ159Aに割り当てられたリソース(複数可)の量を(例えば、インスタンス159と関連したユーザの要求で、または、誤り率に基づいてリソースマネージャ150により成される判定に基づいて)増加しており、誤り率は、コンテナ159Aにおける特定のプログラムコードの1つまたは複数の追加の実行の後、20%まで減少している。既存のコンテナ(例えば、コンテナ159A)のリソースサイジングが調整されたが、別の実施形態において、そこに割り当てられるリソース(複数可)の調整された量を有する新たなコンテナが代わりに作成されてもよく、既存のコンテナは空にされてもよい。
図11に示すように、コンテナ159Aに割り当てられたリソース(複数可)の量は、誤り率を3%に改善するためにさらに調整されている。リソースマネージャ150は、誤り率を閾値の値(例えば、5%)と比較して、さらなるリソースリサイジングは必要でないと判定してよく、また、リソースマネージャ150が、さらなるリサイジングが必要とされると後に判定するまで、コンテナ159Aのリソースレベルを現在のレベルで維持してよい。
図9〜
図11に示した他の構成要素は、
図1に示したものと同一であり、それゆえ、その詳細は簡潔さのために省略される。
【0093】
本開示において説明された機能の全てが、開示された構成要素の1つまたは複数の物理的なプロセッサ及びモバイル通信デバイスにより実行されるソフトウェアにおいて具体化されてよいことが、当業者または他の者によって理解される。ソフトウェアは、任意のタイプの不揮発性ストレージに永続的に記憶されてよい。
【0094】
とりわけ「can」、「could」、「might」、または「may」などの条件付きの言い回しは、そうではないと明確に述べられる場合を除き、あるいは、使用される文脈において理解される場合を除き、概して、一定の実施形態が、他の実施形態が含まない一定の特徴、要素、及び/または、ステップを含むことを伝えるように意図される。それゆえ、そのような条件付きの言い回しは、概して、特徴、要素、及び/または、ステップが1つまたは複数の実施形態に多少なりとも必要とされること、または、1つまたは複数の実施形態が、ユーザ入力またはプロンプトにより、またはそれらを伴わずに、これらの特徴、要素、及び/または、ステップが、任意の特定の実施形態において含まれるかどうか、または実行すべきものであるかどうかを決定するための論理を必ず含むことを暗示するように意図されない。
【0095】
本明細書において説明される流れ図における、及び/または、添付の図面に表された、いずれのプロセスの説明、要素、またはブロックも、プロセスにおける特定の論理的機能またはステップを実行するための1つまたは複数の実行可能な命令を含むコードのモジュール、セグメント、または一部を潜在的に示すものとして理解すべきである。代替的な実施態様が、本明細書において説明される実施形態の範囲内に含まれ、代替的な実施形態において、当業者に理解されるように、含まれる機能性に応じて、要素または機能が削除されてもよく、実質的に同時実行または逆の順番を含め、図示または説明されたもとは違う順番で実行されてもよい。上述のデータ及び/または構成要素は、コンピュータ可読媒体にストアされてよく、また、CD‐ROM、DVD‐ROM、またはネットワークインターフェースなどのコンピュータにより実行可能な構成要素をストアするコンピュータ可読ストレージ媒体と関連した駆動機構を使用してコンピューティングデバイスのメモリにロードされてよいことがさらに理解されよう。さらに、構成要素及び/またはデータは1つのデバイスに含まれてもよく、または、任意の方法で分散されてもよい。従って、汎用のコンピューティングデバイスは、上述の様々なデータ及び/または構成要素の処理及び/または実行により、本開示のプロセス、アルゴリズム及び方法論を実行するように構成されてよい。
【0096】
上述の実施形態に対して多くの変形または修正が成されてよく、それらの要素が、他の許容可能な実施例に存在するものとして理解すべきであることを強調すべきである。全てのそのような修正及び変形は、本明細書において、本開示の範囲内に含まれるように、及び、以下の特許請求の範囲によって保護されるように意図される。