JP2018537776A - コード実行要請ルーティング - Google Patents

Abstract

低待ち時間の算出能力を提供するためのシステムが提供される。システムは、複数の仮想マシンインスタンス上で実行される特定のコンテナを用いるというユーザ指示に基づいて、入力コード実行要請を送るように構成してもよい。システムを、コード実行要請を処理することと、同様のタイプの要請を扱うために以前に用いた特定のコンテナをコード実行要請を扱うために用いるべきというユーザ指示に基づいて特定することと、特定のコンテナを用いてコード実行要請を扱うことと、を行なうように構成してもよい。【選択図】図３

Description

一般的に述べると、コンピューティングデバイスは通信ネットワーク、または一連の通信ネットワークを用いて、データを交換する。企業及び組織は、いくらかのコンピューティングデバイスを相互接続して、運用をサポートする、または、第三者にサービスを提供する、コンピュータネットワークを運用する。コンピューティングシステムは、単一の地理的場所にあり、または複数の異なる地理的場所にある可能性がある（例えば、プライベートまたは公衆通信ネットワークを介して相互接続される）。具体的には、本明細書では一般的に「データセンタ」と呼ばれるデータセンタまたはデータ処理センタは、コンピューティングリソースをデータセンタのユーザに提供するために、いくらかの相互接続されたコンピューティングシステムを含んでもよい。データセンタは、組織の代わりに運用されるプライベートデータセンタ、または一般公衆の代わりに、もしくはそのために運用される公衆データセンタであってもよい。

データセンタリソースの利用増加を容易にするために、単一の物理コンピューティングデバイスが、データセンタのユーザに対して独立したコンピューティングデバイスのように見えてそのように動作する仮想マシンの１つ以上のインスタンスのホストとして働くことが、仮想化技術によって可能になる場合がある。仮想化によって、単一の物理コンピューティングデバイスは、仮想マシンを動的に形成、維持、削除、または他の方法で管理することができる。同様に、ユーザは、単一のコンピューティングデバイス、またはネットワーク化されたコンピューティングデバイスの構成を含む、コンピュータリソースを、データセンタから要請し、種々の数の仮想マシンリソースが提供されることができる。

いくつかのシナリオでは、仮想マシンインスタンスを、特定の機能を提供するように、多くの仮想マシンインスタンスタイプにより構成してもよい。例えば、様々なコンピューティングデバイスは、コンピューティングデバイスが、異なる所望の機能性を提供すること、または同様の機能性をより効率的に提供することを可能にするために、オペレーティングシステムまたはオペレーティングシステム構成、仮想ハードウェアリソース、及びソフトウェアアプリケーションの異なる組み合わせに関連付けられてもよい。これらの仮想マシンインスタンスタイプの構成は多くの場合に、デバイス画像内に含まれている。デバイス画像には、開始したら仮想マシンが実行するソフトウェア（例えば、ＯＳ及びアプリケーションとともに、それらの構成及びデータファイルなど）を含む静的データが含まれる。デバイス画像は典型的に、インスタンスを形成または初期化するために用いるディスク上に記憶される。従って、コンピューティングデバイスは、所望のソフトウェア構成を実施するために、デバイス画像を処理してもよい。

前述の態様及び本開示の付随する優位点の多くは、以下の詳細な説明を添付図面とともに参照することによってより良好に理解されるため、より容易に理解される。

態様例により、低待ち時間の算出能力を提供するための例示的な環境を示すブロック図である。 態様例により、コード実行要請を送るためのルーティングマネージャを提供するコンピューティングデバイスの一般的なアーキテクチャを示す図である。 態様例により、ルーティングマネージャが実施するコード実行要請ルーティングルーチンを例示するフロー図である。 態様例により、コンテナへの要請のルーティングを例示するマッピングテーブル例を示す図である。 態様例により、ルーティングマネージャが実施するコード実行結果キャッシングルーチンを例示するフロー図である。 態様例により、ルーティングマネージャが実施するコンテナライフサイクル管理ルーチンを例示するフロー図である。

会社及び組織はもはや、演算処理を実行する（例えば、スレッド、プログラム、関数、ソフトウェア、ルーチン、サブルーチン、プロセスなどのコードを実行する）ためにその独自のデータセンタを取得して管理する必要はない。クラウドコンピューティングの出現により、従来ハードウェアコンピューティングデバイスによって得られていた記憶領域及び算出能力が今では、インターネット上で数分間で取得及び構成することができる。したがって、開発者は、所望の量のコンピューティングリソースを、物理マシンの取得について心配することなく迅速に購入することができる。そのようなコンピューティングリソースは、通常、仮想コンピューティングリソースまたは仮想マシンインスタンスの形態で購入されることができる。仮想マシンのこれらのインスタンスは、物理マシン（例えば、コンピュータ）のソフトウェア実装である。これらは、物理コンピューティングデバイス上でホストされ、従来は物理マシン上に提供されるオペレーティングシステム及びアプリケーションを含んでいてもよい。これらの仮想マシンインスタンスは、仮想マシンインスタンス上で起動するアプリケーションが要請し及び物理コンピュータと同じ様式で活用されることができる、一式のコンピューティングリソース（例えば、メモリ、ＣＰＵ、ディスク、ネットワーク等）で構成される。

しかし、仮想コンピューティングリソースを購入するときでさえ、開発者はやはり、いくつ及び何のタイプの仮想マシンインスタンスを購入して、どのくらいそれらを保持するのかを決めなければならない。例えば、仮想マシンインスタンスを用いるコストは、タイプ及びそれらを借りる時間に応じて変わる場合がある。加えて、仮想マシンがレンタルされ得る最短時間は、通常、約数時間である。さらに、開発者は、仮想マシン上にインストールするハードウェア及びソフトウェアリソース（例えば、オペレーティングシステムのタイプ及び言語ランタイムなど）を指定しなくてならない。彼らが持ち得る他の懸念事項としては次が上げられる。過剰利用（例えば、取得するコンピューティングリソースが少なすぎて、性能問題を被る）、過少利用（例えば、取得するコンピューティングリソースが、コードの実行に必要な量よりも多いために、余分に払う）、トラフィックの変化の予測（例えば、スケールアップまたはダウンするときを知るため）、インスタンス及び言語ランタイムスタートアップ遅延（ユーザが秒またはミリ秒でさえのオーダーの算出能力を希望したとしても、３〜１０分間（またはそれ以上）かかる可能性がある）。

本開示の態様によれば、ユーザ要請を受け取ったらすぐに使える状態である事前初期化された仮想マシンインスタンスのプールを維持して、入力要請に応えるためにプール内で利用可能な能力の量を自動的に管理することによって、ユーザコード（例えば、インスタンス及び言語ランタイムスタートアップ時間）を実行することに関連する遅延（しばしば、待ち時間と言われる）を著しく減らすことができ、利用を向上させることができる。

一般的に述べると、仮想算出システムにおける仮想マシンインスタンスの管理を容易にするシステム及び方法が開示されている。仮想算出システムは、そこにロードされた１つ以上のソフトウェアコンポーネント（例えば、オペレーティングシステム、言語ランタイム、ライブラリ等）を有する仮想マシンインスタンスのプールを維持する。仮想マシンインスタンスのプールを維持することは、新しいインスタンスを形成することと、外部のインスタンスプロビジョニングサービスから新しいインスタンスを取得することと、インスタンスを破壊することと、インスタンスをユーザに割り当てる／再割り当てすることと、インスタンス（例えば、コンテナまたは内部のリソース）を変更すること等を伴ってもよい。プール内の仮想マシンインスタンスを、プログラムコードを実行するユーザ要請に応えるように指定することができる。本開示では、語句「プログラムコード」、「ユーザコード」、及び「クラウド機能」はしばしば交換可能に用いる場合がある。プログラムコードは、仮想マシンインスタンス上で作成された分離したコンテナ内で実行されることができる。要請を受け取る時までに、プール内の仮想マシンインスタンスはすでに起動されていて、特定のオペレーティングシステム及び言語ランタイムがロードされているために、要請を扱うことが（例えば、仮想マシンインスタンス上に形成された１つ以上のコンテナ内のユーザコードを実行することによって）可能である算出能力を見つけることに関連する遅延が著しく減る。

別の態様では、仮想算出システムは、仮想算出システムが受け取る入力コード実行要請と、これらのコード実行要請を扱うために用いる算出能力との間に、マッピングを形成して管理してもよい。マッピングによって、複数の要請によるあるコンテナ固有リソースの利用及び再利用が容易になる場合がある。例えば、所定のコンテナを、コード実行結果を記憶するキャッシュに関連付けてもよく、また所定のコンテナ内で実行される任意のプログラムコードによってアクセスしてもよい。したがって、要請に関連するコード実行結果がキャッシュ内に記憶されたら、同じタイプの後続の要請が、所定のコンテナに送られているならば、キャッシュ内に記憶されたコード実行結果を用いてより効率的に扱われる場合がある。したがって、仮想算出システム上で実行される適切なコンテナに要請を送ることによって、待ち時間利得が達成される場合がある。

次に本開示の特定の実施形態及び例示的適用について、図面を参照して説明する。これらの実施形態及び例示的適用は、本開示を限定するのではなく、例示することを意図する。仮想算出システムを含む例示的環境

図１を参照して、仮想環境１００の実施形態を例示するブロック図について説明する。図１に示す例に含まれる仮想環境１００では、ユーザコンピューティングデバイス１０２のユーザ（例えば、開発者など）が、仮想算出システム１１０が提供する仮想コンピューティングリソースを用いて、種々のプログラムコードを実行してもよい。

例として、仮想算出システム１１０と通信している種々のユーザコンピューティングデバイス例１０２を示す（例えば、デスクトップコンピュータ、ラップトップ、及び携帯電話）。全般的に、ユーザコンピューティングデバイス１０２は、任意のコンピューティングデバイス、例えばデスクトップ、ラップトップ、携帯電話（またはスマートフォン）、タブレット、キオスク、無線デバイス、及び他の電子デバイスとすることができる。加えて、ユーザコンピューティングデバイス１０２は、同じまたは異なるデータセンタ上で実行されるウェブサービスを含んでいてもよい。ここでは、例えば、異なるウェブサービスが互いとプログラム的に通信して、本明細書で説明する１つ以上の技術を実行してもよい。その上、ユーザコンピューティングデバイス１０２は、インターネット家電及び接続デバイス等のモノのインターネット（ＩｏＴ）デバイスを含んでもよい。仮想算出システム１１０は、ユーザコンピューティングデバイス１０２に、１人以上のユーザインターフェース、コマンドラインインターフェース（ＣＬＩ）、アプリケーションプログラミングインターフェース（ＡＰＩ）、及び／または他のプログラムマチックインターフェースであって、ユーザコードを生成及びアップロードし、ユーザコードを呼び出し（例えば、仮想算出システム１１０上でユーザコードを実行する要請をサブミットする）、イベントベースのジョブまたは時限ジョブをスケジューリングし、ユーザコードを追跡し、及び／またはその要請及び／またはユーザコードに関係する他のロギングまたは監視情報を見るためのプログラムマチックインターフェースを与えてもよい。１つ以上の実施形態について、本明細書では、ユーザインターフェースを用いると説明する場合があるが、当然のことながら、このような実施形態では、付加的または代替的に、任意のＣＬＩ、ＡＰＩ、または他のプログラムマチックインターフェースを用いてもよい。

ユーザコンピューティングデバイス１０２は、仮想算出システム１１０に、ネットワーク１０４を介してアクセスする。ネットワーク１０４は、任意の有線ネットワーク、無線ネットワーク、またはそれらの組み合わせであってもよい。加えて、ネットワーク１０４は、パーソナルエリアネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、オーバージエアブロードキャストネットワーク（例えば、ラジオまたはテレビジョン用）、ケーブルネットワーク、人工衛星ネットワーク、セルラー電話ネットワーク、またはそれらの組み合わせであってもよい。例えば、ネットワーク１０４は、リンクされたネットワークの公にアクセス可能なネットワーク、可能性として様々な別個の当事者が動作させるもの、例えばインターネットであってもよい。いくつかの実施形態では、ネットワーク１０４は、プライベートまたはセミプライベートネットワーク、例えば法人または大学イントラネットであってもよい。ネットワーク１０４は、１つ以上の無線ネットワーク、例えばグローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）ネットワーク、符号分割多元接続（ＣＤＭＡ）ネットワーク、ロングタームエボリューション（ＬＴＥ）ネットワーク、または任意の他のタイプの無線ネットワークを含んでいてもよい。ネットワーク１０４は、インターネットまたは他の前述したタイプのネットワークのいずれかを介して通信するためのプロトコル及びコンポーネントを用いることができる。例えば、ネットワーク１０４に使用されるプルトコルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ハイパーテキスト転送プロトコル保全（ＨＴＴＰＳ）、メッセージ待ち行列テレメトリートランスポート（ＭＱＴＴ）、制約アプリケーションプルトコル（ＣｏＡＰ）、及び同等物を含んでもよい。インターネットまたは他の前述の種類の通信ネットワークのいずれかを介して通信するためのプロトコル及びコンポーネントは、当業者に周知であるため、本明細書により詳細に記載されない。

仮想算出システム１１０は、図１では、１つ以上のコンピュータネットワークを用いて相互接続されたいくつかのコンピュータシステムを含む分散コンピューティング環境で動作すると示している。仮想算出システム１１０は、図１に例示したものよりも少ないかまたは多いデバイスを有するコンピューティング環境内で動作することもできる。したがって、図１の仮想算出システム１１０の表現は例示的であり、本開示を限定するものではないと理解すべきである。例えば、仮想算出システム１１０またはその種々の構成成分は、種々のウェブサービスコンポーネント、ホスト型または「クラウド」コンピューティング環境、及び／またはピアトゥピアネットワーク構成を実施して、本明細書で説明するプロセスの少なくとも一部を実施することができる。

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

図１に例示した環境では、仮想環境１００には仮想算出システム１１０が含まれている。仮想算出システム１１０には、フロントエンド１２０、ウォーミングプールマネージャ１３０、ワーカーマネージャ１４０、及びルーティングマネージャ１５０が含まれている。図示した例では、仮想マシンインスタンス（「インスタンス」）１５２、１５４を、ウォーミングプールマネージャ１３０によって管理されたウォーミングプール１３０Ａ内に示し、インスタンス１５６、１５７、１５８、１５９を、ワーカーマネージャ１４０によって管理されたアクティブプール１４０Ａ内に示す。いくつかの実施形態では、用語「仮想マシンインスタンス」は、ソフトウェアを実行し得る環境またはプラットフォーム（「実行環境」）を提供するようにハードウェアをエミュレートするソフトウェアまたは他の実行可能コードを実行することを指す場合がある。仮想マシンインスタンスは全般的に、物理ハードウェアデバイスによって実行される。物理ハードウェアデバイスは、仮想マシンインスタンスがエミュレートするハードウェアとは異なっていてもよい。例えば、仮想マシンは、第１のタイプのプロセッサ及びメモリをエミュレートする一方で、第２のタイプのプロセッサ及びメモリ上で実行してもよい。したがって、仮想マシンを用いて、第２の実行環境（例えば、第２のオペレーティングシステム）を実行している物理デバイス上での第１の実行環境（例えば、第１のオペレーティングシステム）を対象としたソフトウェアを実行することができる。ある場合には、仮想マシンインスタンスがエミュレートするハードウェアは、基礎をなすデバイスのハードウェアと同じまたは同様であってもよい。例えば、第１のタイプのプロセッサを伴うデバイスが複数の仮想マシンインスタンスを実施してもよい。それぞれ、その第１のタイプのプロセッサのインスタンスをエミュレートする。したがって、仮想マシンインスタンスを用いて、単一のデバイスを多くの論理サブデバイス（それぞれ「仮想マシンインスタンス」と言う）に分割することができる。仮想マシンインスタンスは全般的に、基礎をなす物理デバイスのハードウェアから離れた抽象化のレベルを与えることができるが、この抽象化は必要ではない。例えば、デバイスが複数の仮想マシンインスタンスを実施すると想定する。それぞれ、デバイスが与えるものと同一のハードウェアをエミュレートする。このようなシナリオの下で、各仮想マシンインスタンスによって、ソフトウェアアプリケーションが、基礎をなすハードウェア上で、トランスレーションすることなくコードを実行することができて、一方で、他の仮想マシンインスタンス上で実行されるソフトウェアアプリケーション間の論理的な分離を維持することができる場合がある。このプロセスは、全般的に「ネイティブ実行」と言われるが、仮想マシンインスタンスの速度または性能を増加させるために用いてもよい。基礎をなすハードウェアの直接利用を可能にする他の技術（例えば、ハードウェアパススルー技術）は、当該技術分野で知られている。

仮想算出システム１１０内の種々のコンポーネントの説明は本質的に論理的であり、コンポーネントの１つ以上を、単一のコンピューティングデバイスまたは複数のコンピューティングデバイスによって実施することができる。例えば、インスタンス１５２、１５４、１５６、１５７、１５８、１５９を、異なる種々の地理的地域における１つ以上の物理コンピューティングデバイス上で実施することができる。同様に、フロントエンド１２０、ウォーミングプールマネージャ１３０、ワーカーマネージャ１４０、及びルーティングマネージャ１５０をそれぞれ、複数の物理コンピューティングデバイスに渡って実施することができる。代替的に、フロントエンド１２０、ウォーミングプールマネージャ１３０、ワーカーマネージャ１４０、及びルーティングマネージャ１５０のうちの１つ以上を、単一の物理コンピューティングデバイス上で実施することができる。いくつかの実施形態では、仮想算出システム１１０には、複数のフロントエンド、複数のウォーミングプールマネージャ、複数のワーカーマネージャ、及び／または複数の能力マネージャが含まれていてもよい。６つの仮想マシンインスタンスを図１の例には示しているが、本明細書で説明する実施形態はこのようには限定されず、当業者であれば分かるように、仮想算出システム１１０は、任意の数の物理コンピューティングデバイスを用いて実施される任意の数の仮想マシンインスタンスを含んでいてもよい。同様に、単一のウォーミングプール及び単一のアクティブプールを図１の例に示しているが、本明細書で説明する実施形態はこのようには限定されず、当業者であれば分かるように、仮想算出システム１１０には、任意の数のウォーミングプール及びアクティブプールが含まれていてもよい。

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

ユーザは仮想算出システム１１０を用いて、そこの上でユーザコードを実行してもよい。例えば、ユーザは、ユーザが開発したウェブまたはモバイルアプリケーションと通信する数個のコードを起動することを願い得る。コードを実行する１つの方法は、仮想マシンインスタンスをサービスプロバイダから取得することであって、サービスプロバイダは、インフラストラクチャをサービスとして提供し、ユーザの要求に適合するように仮想マシンインスタンスを構成し、構成された仮想マシンインスタンスを用いてコードを実行する、取得することである。代替的に、ユーザは仮想算出システム１１０にコード実行要請を送ってもよい。仮想算出システム１１０は、コード実行要請に基づいて、算出能力（例えば、下記により詳細に説明される、コンテナ、インスタンス等）の獲得及び構成に対処でき、算出能力を使用して、コードを実行できる。仮想算出システム１１０は、ボリュームに基づいて自動的にスケールアップ及びダウンする場合があり、そのため、ユーザは、過剰利用（例えば、取得するコンピューティングリソースが少なすぎて、性能問題を被る）または過少利用（例えば、取得するコンピューティングリソースが、コードの実行に必要な量よりも多いために、余分に払う）について心配しなければならない負担から解放される。フロントエンド

フロントエンド１２０は、仮想算出システム１１０上でユーザコードを実行するすべての要請を処理する。一実施形態では、フロントエンド１２０は、仮想算出システム１１０によって提供される他の全てのサービスに対するフロントドアとして役割を果たす。フロントエンド１２０は要請を処理して、要請が適切に許可されたことを確かめる。例えば、フロントエンド１２０は、要請に関連するユーザが、要請内で指定されたユーザコードにアクセスすることが許可されているか否かを判定してもよい。

ユーザコードは、本明細書で用いる場合、特定のプログラム言語で書かれた任意のプログラムコード（例えば、プログラム、ルーチン、サブルーチン、スレッドなど）を指してもよい。本開示では、用語「コード」、「ユーザコード」、及び「プログラムコード」は交換可能に用いてもよい。このようなユーザコードを実行して、特定のタスクを、例えば、ユーザが開発した特定のウェブアプリケーションまたはモバイルアプリケーションと共に、達成してもよい。例えば、ユーザコードは、ジャバスクリプト（ｎｏｄｅ．ｊｓ）、ジャバ、パイソン、及び／またはルビーに書いてもよい。要請には、ユーザコード（またはその場所）とユーザコードを実行するために用いるべき１つ以上の引数とが含まれていてもよい。例えば、ユーザはユーザコードを、ユーザコードを実行する要請と一緒に与えてもよい。別の例では、要請は、以前にアップロードされたプログラムコード（例えば、コードをアップロードするためのＡＰＩを用いて）を、その名前またはその固有のＩＤによって特定してもよい。さらに別の例では、コードを、要請に含めてもよく、ならびに別個の場所（例えば、ストレージサービス１０８または仮想算出システム１１０内部のストレージシステム）に、仮想算出システム１１０が要請を受け取る前にアップロードしてもよい。仮想算出システム１１０は、要請が処理されるときのコードが利用可能である場所に基づいて、そのコード実行戦略を変化させ得る。

フロントエンド１２０は、このようなユーザコードを実行する要請を、ユーザからのハイパーテキスト転送プロトコル保全（ＨＴＴＰＳ）要請に応答して受け取ってもよい。また、ＨＴＴＰＳ要請に含まれる任意の情報（例えば、ヘッダ及びパラメータ）をユーザコードを実行するときに処理して用いてもよい。前述したように、任意の他のプロトコル（例えば、ＨＴＴＰ、ＭＱＴＴ、及びＣｏＡＰなど）を用いて、コード実行要請を含むメッセージをフロントエンド１２０に伝達してもよい。またフロントエンド１２０は、イベント（例えば、自動的な要請生成を引き起こすようにユーザが登録したイベント）が検出されたときに、要請を受け取ってこのようなユーザコードを実行してもよい。例えば、ユーザは、ユーザコードを補助サービス１０６に登録し、特定のイベントが発生する（例えば、新しいファイルがアップロードされる）ときはいつでも、ユーザコードを実行する要請をフロントエンド１２０に送ることを、指定してもよい。代替的に、ユーザは時限ジョブ（例えば、ユーザコードを２４時間ごとに実行する）を登録してもよい。このような例では、スケジュールされた時間が時限ジョブに達したら、ユーザコードを実行する要請をフロントエンド１２０に送ってもよい。さらに別の例では、フロントエンド１２０は入力コード実行要請の待ち行列を有していてもよく、仮想算出システムの作業待ち行列からユーザのバッチジョブが取り除かれたときに、フロントエンド１２０はユーザ要請を処理してもよい。さらに別の例では、要請は、仮想算出システム１１０または図１に例示されていない他のサーバもしくはサービス内の別のコンポーネントから発生してもよい。

ユーザ要請は、ユーザコードと一緒に用いるべき１つ以上の第三者ライブラリ（ネイティブライブラリを含む）を指定してもよい。一実施形態では、ユーザ要請は、ユーザコード及び任意のライブラリ（及び／またはその記憶場所の識別）を含むＺＩＰファイルである。いくつかの実施形態では、ユーザ要請には、実行すべきプログラムコードを示すメタデータ、プログラムコードを書く言語、要請に関連するユーザ、及び／またはプログラムコードを実行するために確保すべきコンピューティングリソース（例えば、メモリなど）が含まれる。例えば、プログラムコードを、要請によって与えてもよいし、あらかじめユーザがアップロードしてもよいし、仮想算出システム１１０が与えてもよいし（例えば、標準ルーチン）、及び／またはサードパーティが与えてもよい。いくつかの実施形態では、このようなリソースレベルの制約（例えば、どのくらいのメモリを、特定のユーザコードを実行するために割り当てるか）を、特定のユーザコードに対して指定し、制約はユーザコードの各実行に渡って変わらなくてもよい。そのような場合、仮想算出システム１１０は、各個別要請が受信される前に、そのようなリソースレベル制約にアクセスしてもよく、個別要請は、そのようなリソースレベル制約を具体化しない場合がある。いくつかの実施形態では、ユーザ要請は、他の制約（例えば、ユーザコードを実行するために要請が有する許可の種類を示す許可データ）を指定してもよい。このような許可データを仮想算出システム１１０が用いてプライベートリソースにアクセスしてもよい（例えば、プライベートネットワーク上で）。

いくつかの実施形態では、ユーザ要請は、ユーザ要請を扱うために採用すべき挙動を指定してもよい。そのような実施形態では、ユーザ要請は、ユーザ要請に関連付けられるユーザコードが実行される１つ以上の実行モードを有効にするためのインジケータを含んでもよい。例えば、要請は、ユーザコードの実行に関連して生成され得るデバック及び／またはログ出力が（コンソールユーザインターフェースを介して）ユーザに戻すように提供されるデバッグモードでユーザコードが実行されるべきかどうかを示すためのフラグまたはヘッダを含んでもよい。そのような例では、仮想算出システム１１０は、要請を点検し、フラグまたはヘッダを探してもよく、それが存在する場合、仮想算出システム１１０は、ユーザコードが実行されるコンテナの挙動（ロギング機能）を修正し、出力データをユーザに戻すように提供させる。いくつかの実施形態では、挙動／モードインジケータを、仮想算出システム１１０がユーザに与えたユーザインターフェースによって要請に加える。他の特徴（例えば、ソースコードプロファイリング、リモートデバッギングなど）を、要請内に与えられた指示に基づいて有効または無効にしてもよい。

いくつかの実施形態では、仮想算出システム１１０は複数のフロントエンド１２０を含んでいてもよい。このような実施形態では、ロードバランサを、入力要請を複数のフロントエンド１２０に（例えばラウンドロビン方式で）分配するために設けてもよい。いくつかの実施形態では、ロードバランサが入力要請を複数のフロントエンド１２０に分配する方法は、ウォーミングプール１３０Ａ及び／またはアクティブプール１４０Ａの状態に基づいてもよい。例えば、ウォーミングプール１３０Ａの能力は、十分であると思われる場合、要請は、フロントエンド１２０の個別能力に基づいて（例えば、１つ以上のロードバランシング制限に基づいて）、複数のフロントエンド１２０に分散されてもよい。他方では、ウォーミングプール１３０Ａ内の能力が閾値よりも小さい場合、このようなロードバランシング制限のうちの１つ以上を取り除いて、ウォーミングプール１３０Ａから取る仮想マシンインスタンスの数を減らすかまたは最小にするように、要請が複数のフロントエンド１２０に分配され得るようにしてもよい。例えば、ロードバランシング制限によって要請がフロントエンドＡに送られるべき場合であっても、フロントエンドＡが要請を使用可能にするためにインスタンスをウォーミングプール１３０Ａから取り出す必要があるが、フロントエンドＢが同じ要請を使用可能にするためにアクティブプール内のインスタンスの１つを使用できる場合、要請がフロントエンドＢに送られてもよい。ウォーミングプールマネージャ

ウォーミングプールマネージャ１３０は、仮想算出システム１１０上でユーザコードを実行する要請を仮想算出システム１１０が受け取ったときに、仮想マシンインスタンスがワーカーマネージャ１４０によって用いられる準備ができていることを確実にする。図１で説明される例において、ウォーミングプールマネージャ１３０はウォーミングプール１３０Ａを管理する。ウォーミングプール１３０Ａは、入力ユーザコード実行要請に応えるために用いてもよい事前初期化及び事前構成された仮想マシンインスタンスのグループ（しばしば、プールと言われる）である。いくつかの実施形態では、ウォーミングプールマネージャ１３０は、仮想マシンインスタンスを、仮想算出システム１１０内の１つ以上の物理コンピューティングマシン上でブートさせ、ウォーミングプール１３０Ａに追加させる。他の実施形態では、ウォーミングプールマネージャ１３０は、補助仮想マシンインスタンスサービス（例えば、図１のインスタンスプロビジョニングサービス１０９）と通信して新しいインスタンスを形成し、ウォーミングプール１３０Ａに加える。いくつかの実施形態では、ウォーミングプールマネージャ１３０は、仮想算出システム１１０内の物理コンピューティングデバイスと、１つ以上の仮想マシンインスタンスサービスとの両方を用いて、フロントエンド１２０が受け取るコード実行要請に応えるために用いることができる算出能力を取得して維持してもよい。いくつかの実施形態では、仮想算出システム１１０は、ウォーミングプール１３０Ａ内の利用可能な能力を制御する（例えば、増加または減少させる）ための１つ以上の論理ノブまたはスイッチを含んでいてもよい。例えば、システム管理者は、そのようなノブまたはスイッチを使用して、ピーク時間中、ウォーミングプール１３０Ａ内で利用可能である能力（例えば、事前にブートされるインスタンスの数）を増加させてもよい。いくつかの実施形態では、ウォーミングプール１３０Ａ内の仮想マシンインスタンスは、ユーザのコードを実行する特定のユーザ要請から独立した所定の構成セットに基づいて構成することができる。所定の構成セットは、ユーザコードを実行するために種々のタイプの仮想マシンインスタンスに対応することができる。ウォーミングプールマネージャ１３０は、現在または以前のユーザコード実行に関する１つ以上の指標に基づいて、ウォーミングプール１３０Ａ内の仮想マシンインスタンスのタイプ及び数を最適化することができる。

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

いくつかの実施形態では、ウォーミングプール１３０Ａ内の仮想マシンインスタンスを用いて、任意のユーザの要請に応えてもよい。一実施形態では、ウォーミングプール１３０Ａ内の全ての仮想マシンインスタンスは、同じまたは実質的に同類の様式で構成されてもよい。別の実施形態では、ウォーミングプール１３０Ａ内の仮想マシンインスタンスを、異なるユーザの要求に適合するように別の仕方で構成してもよい。例えば、仮想マシンインスタンスには、異なるオペレーティングシステム、異なる言語ランタイム、及び／または異なるライブラリをロードしてもよい。さらに別の実施形態では、ウォーミングプール１３０Ａ内の仮想マシンインスタンスは、（例えば、同じＯＳ、言語ランタイム、及び／またはライブラリで）同じまたは実質的に同類の様式で構成されてもよいが、それらのインスタンスの一部は、異なるコンテナ構成を有してもよい。例えば、２つのインスタンスがパイソン及びルビーの両方に対するランタイムを有していてもよいが、あるインスタンスが、パイソンコードを実行するように構成されたコンテナを有していてもよく、他のインスタンスが、ルビーコードを実行するように構成されたコンテナを有していてもよい。いくつかの実施形態では、複数のウォーミングプール１３０Ａ（それぞれ、等しく構成された仮想マシンインスタンスを有する）が設けられている。

ウォーミングプールマネージャ１３０は、ウォーミングプール１３０Ａ内で仮想マシンインスタンスを事前構成して、仮想算出システム１１０上でプログラムコードを実行するユーザ要請が要請または指定し得る動作条件のうちの少なくとも１つを満たすように各仮想マシンインスタンスが構成されるようにしてもよい。一実施形態では、動作条件は、潜在的ユーザコードが書き込まれ得るプログラミング言語を含んでもよい。例えば、このような言語としては、ジャバ、ジャバスクリプト、パイソン、ルビーなどを挙げてもよい。いくつかの実施形態では、ユーザコードが書き込まれ得る言語のセットを、所定のセット（例えば、４言語のセットであるが、いくつかの実施形態では、４言語よりも多いまたは少ないセットが提供される）に限定して、ユーザコードを実行する要請を満たすことができる仮想マシンインスタンスの事前初期化を容易にしてもよい。例えば、ユーザが、仮想算出システム１１０が与えるユーザインターフェースを介して要請を構成しているとき、ユーザインターフェースは、ユーザに、ユーザコードを実行するための所定の動作条件のうちの１つを指定するように促してもよい。別の例では、仮想算出システム１１０が提供するサービスを用いるためのサービスレベルアグリーメント（ＳＬＡ）が、ユーザ要請が満たすべき条件のセット（例えば、プログラミング言語、コンピューティングリソースなど）を指定してもよく、仮想算出システム１１０は、要請を扱うときに要請が条件のセットを満たすことを想定してもよい。別の例では、要請内で指定される動作条件は、以下のものを含んでいてもよい。要請を処理するために用いるべき算出能力の量、要請のタイプ（例えば、ＨＴＴＰ対トリガされたイベント）、要請に対するタイムアウト（例えば、その時間の後に要請を終了してもよい閾値時間）、セキュリティポリシー（例えば、ウォーミングプール１３０Ａ内のどのインスタンスがどのユーザによって利用可能であるかを制御してもよい）、スケジューリング情報（例えば、その時間までに、仮想算出システムがプログラムコードの実行を要請される時間、その時間の後に、仮想算出システムがプログラムコードの実行を要請される時間、その中で、仮想算出システムがプログラムコードの実行を要請される時間窓など）等。ワーカーマネージャ

ワーカーマネージャ１４０は、入力コード実行要請に応えるために用いるインスタンスを管理する。図１で説明される例において、ワーカーマネージャ１４０はアクティブプール１４０Ａを管理している。アクティブプール１４０Ａは、１人以上のユーザに現時点で割り当てられている仮想マシンインスタンスのグループ（しばしば、プールと言われる）である。仮想マシンインスタンスが特定のユーザに割り当てられるように本明細書に説明されるが、いくつかの実施形態では、インスタンスがユーザのグループに割り当てられることにより、インスタンスがユーザのグループに関係付けられ、グループの任意のメンバーがインスタンス上のリソースを利用することができる。例えば、同じグループ内のユーザが同じセキュリティグループに属して（例えば、そのセキュリティ証明書に基づいて）、コンテナ内のあるメンバーのコードを特定のインスタンス上で実行することを、別のメンバーのコードを同じインスタンス上の別のコンテナ内で実行した後に行なっても、セキュリティリスクを引き起こさないようにしてもよい。同様に、ワーカーマネージャ１４０は、１つ以上のポリシに従って、インスタンス及びコンテナを割り当ててもよく、そのポリシは、どの要請がどのコンテナ内で実行できるか、どのインスタンスがどのユーザに割り当てられるかを指図する。例示的ポリシは、インスタンスが、同じアカウント（例えば、仮想算出システム１１０によって提供されるサービスにアクセスするためのアカウント）を共有するユーザのコレクションに割り当てられることを具体化してもよい。いくつかの実施形態では、同じユーザグループに関連する要請は同じコンテナを共有してもよい（例えば、関連するユーザコードが同一である場合）。いくつかの実施形態では、要請はグループの異なるユーザを区別せず、要請に関連するユーザが属するグループを示すだけである。

図１に例示する例において、ユーザコードを隔離された算出システム（コンテナと言われる）において実行する。コンテナは、仮想マシンインスタンス内に、そのインスタンス上で利用可能なリソースを用いて形成された論理ユニットである。例えば、ワーカーマネージャ１４０は、ユーザコードを実行する要請内で指定された情報に基づいて、アクティブプール１４０Ａ内のインスタンスのうちの１つにおいて新しいコンテナを形成するかまたは既存のコンテナの位置を特定し、コンテナを要請に割り当てて、要請に関連するユーザコードの実行を扱ってもよい。一実施形態では、このようなコンテナはリナックスコンテナとして実施する。アクティブプール１４０Ａ内の仮想マシンインスタンス上には、１つ以上のコンテナが形成されていてもよく、またユーザに関連する１つ以上のプログラムコードがロードされていてもよい（例えば、コンテナの１つまたはインスタンスのローカルキャッシュ内に）。

図１に示すように、インスタンスは、オペレーティングシステム（ＯＳ）、言語ランタイム、及びコンテナを有していてもよい。コンテナには、ＯＳ及び言語ランタイム及びユーザコードの個々のコピーをロードしてもよい。図１の実施例では、ワーカーマネージャ１４０が管理するアクティブプール１４０Ａには、インスタンス１５６、１５７、１５８、１５９が含まれている。インスタンス１５６は、コンテナ１５６Ａ、１５６Ｂを含む。コンテナ１５６Ａは、ＯＳ１５６Ａ−１、ランタイム１５６Ａ−２、及びそれにロードされたコード１５６Ａ−３を有する。示された例では、コンテナ１５６Ａは、それ自体のＯＳ、ランタイム、それにロードされたコードを有する。一実施形態では、ＯＳ１５６Ａ−１（例えば、そのカーネル）、ランタイム１５６Ａ−２、及び／またはコード１５６Ａ−３は、コンテナ１５６Ａ、１５６Ｂ（及び図１に例示されていない任意の他のコンテナ）間で共有されている。別の実施形態では、ＯＳ１５６Ａ−１（例えば、カーネルの外側で実行される任意のコード）、ランタイム１５６Ａ−２、及び／またはコード１５６Ａ−３は、インスタンス１５６上のコンテナ１５６Ａに対して形成されて他のコンテナとは共有されていない独立したコピーである。さらに他の実施形態では、ＯＳ１５６Ａ−１、ランタイム１５６Ａ−２、及び／またはコード１５６Ａ−３の一部がインスタンス１５６上のコンテナ間で共有され、その他の部分はコンテナ１５６Ａに固有の独立したコピーである。インスタンス１５７は、コンテナ１５７Ａ、１５７Ｂ、１５７Ｃを含む。インスタンス１５８には、コンテナ１５８Ａ、１５８Ｂ及びリソース１５８Ｃが含まれている。インスタンス１５９には、コンテナ１５９Ａ及びリソース１５９Ａ−１が含まれている。リソース１５８Ｃは、インスタンス固有リソース（例えば、メモリ、ディスクストレージ、データベースなど）であって、そこに形成される任意のコンテナ（またはそこで実行される任意のコード）からアクセス可能なものであってもよい。リソース１５９Ａ−１は、コンテナ固有リソース（例えば、メモリ、ディスクストレージ、データベースなど）であって、そこで実行される任意のコードからアクセス可能なものであってもよい。

図１の例では、図１に示すコンテナのサイズは、コンテナの実際のサイズに比例していてもよい。例えば、インスタンス１５６上でコンテナ１５６Ａが占有するスペースはコンテナ１５６Ｂの場合よりも広くてもよい。同様に、コンテナ１５７Ａ、１５７Ｂ、１５７Ｃは等しいサイズであってもよく、コンテナ１５８Ａ及び１５８Ｂは等しいサイズであってもよい。インスタンス１５８、１５９内に示す「Ｃ」と標示される点線入りボックスは、インスタンス上に残っているスペースであって、新しいインスタンスを形成するために用いてもよいスペースを示している。いくつかの実施形態では、コンテナのサイズは６４ＭＢまたはその任意の倍数であってもよい。他の実施形態では、コンテナのサイズは、コンテナが形成されているインスタンスのサイズ以下の何らかの任意のサイズであってもよい。いくつかの実施形態では、コンテナのサイズは、コンテナが作成されるインスタンスのサイズよりも小さい、それに等しい、またはそれよりも大きい任意のサイズのいずれかであってもよい。コンテナのサイズがインスタンスのサイズを超えることができる量は、そのコンテナがインスタンスによって提供される能力をどれくらい上回って利用され得るかに基づいて、判定されてもよい。

コンテナ１５６Ｂ、１５７Ａ、１５７Ｂ、１５７Ｃ、１５８Ａ、１５８Ｂ、１５９Ａ内部のコンポーネントは、図１の例には例示していないが、これらのコンテナはそれぞれ、種々のオペレーティングシステム、言語ランタイム、ライブラリ、及び／またはユーザコードを有していてもよい。いくつかの実施形態では、インスタンス上にはユーザコードがロードされていてもよく（例えば、インスタンスレベルキャッシュ例えばリソース１５８Ｃ内に）、これらインスタンス内のコンテナ上にもユーザコードがロードされていてもよい。いくつかの実施形態では、ワーカーマネージャ１４０は、アクティブプール１４０Ａ内のインスタンスのリストを維持してもよい。インスタンスのリストは、さらに、インスタンスの構成（例えば、ＯＳ、ランタイム、コンテナ等）を具体化してもよい。いくつかの実施形態では、ワーカーマネージャ１４０は、ウォーミングプール１３０Ａ内のインスタンスのリスト（例えば、インスタンスの数及び種類を含む）へのアクセスを有してもよい。他の実施形態では、ワーカーマネージャ１４０は、ウォーミングプール１３０Ａ内の仮想マシンインスタンスの知識を有することなく、ウォーミングプールマネージャ１３０から算出能力を要請する。

要請がフロントエンド１２０によって成功裏に処理された後に、ワーカーマネージャ１４０は、仮想算出システム１１０上でユーザコードを実行する要請に応える能力を見つける。例えば、アクティブプール１４０Ａ内に、同じユーザコード（例えば、コンテナ１５６Ａ内に示すコード１５６Ａ−３）がロードされたコンテナを有する特定の仮想マシンインスタンスが存在する場合、ワーカーマネージャ１４０は、コンテナを要請に割り当てて、ユーザコードをコンテナ内で実行してもよい。代替的に、ユーザコードが仮想マシンインスタンスのうちの１つのローカルキャッシュ内で利用可能である（例えば、インスタンス１５８上に記憶されるが、任意の個々のコンテナには属しない）ならば、ワーカーマネージャ１４０は、このようなインスタンス上で新しいコンテナを形成し、コンテナを要請に割り当てて、コンテナ内にユーザコードをロードして実行してもよい。

ワーカーマネージャ１４０が、要請に関連するユーザコードがアクティブプール１４０Ａ内のいずれのインスタンス上（例えば、インスタンスのコンテナまたはローカルキャッシュ内）でも見出されないと判定した場合、ワーカーマネージャ１４０は、アクティブプール１４０Ａ内のいずれかのインスタンスが、要請に関連するユーザに現時点で割り当てられているか否か、及び現在の要請を扱う算出能力を有しているか否かを判定してもよい。そのようなインスタンスがある場合、ワーカーマネージャ１４０は、インスタンス上に新しいコンテナを作成し、コンテナを要請に割り当てられてもよい。代替的に、ワーカーマネージャ１４０はさらに、ユーザに割り当てられたインスタンス上に既存のコンテナを構成して、コンテナを要請に割り当ててもよい。例えば、現在のユーザ要請によって求められる特定のライブラリがコンテナ上にロードされる場合、ワーカーマネージャ１４０は、既存のコンテナがユーザコードを実行するために使用されてもよい。そのような場合、ワーカーマネージャ１４０は、特定のライブラリ及びユーザコードをコンテナ上にロードし、コンテナを使用してユーザコードを実行してもよい。

アクティブプール１４０Ａが、ユーザに現時点で割り当てられているインスタンスを何ら含んでいない場合、ワーカーマネージャ１４０は、ウォーミングプール１３０Ａから新しい仮想マシンインスタンスを引き出して、インスタンスを、要請に関連するユーザに割り当て、インスタンス上に新しいコンテナを形成して、コンテナを要請に割り当て、ユーザコードをコンテナ上にダウンロードして実行する。

いくつかの実施形態では、仮想算出システム１１０は、ユーザコードの実行を、それを（例えば、フロントエンド１２０によって）受け取った直後に始めるように適合されている。時間周期は、ユーザコードの実行の初期化（例えば、ユーザに関連付けられる仮想マシンインスタンス上のコンテナ内で行われる）と、ユーザコードを実行する要請の受信（例えば、フロントエンドによって受信される）との間の時間差として定義されることができる。仮想算出システム１１０は、既定の時間よりも短い時間周期内でユーザコードの実行を始めるように適合される。一実施形態では、規定の時間は５００ｍｓである。別の実施形態では、規定の時間は３００ｍｓである。別の実施形態では、規定の時間は１００ｍｓである。別の実施形態では、規定の時間は５０ｍｓである。別の実施形態では、規定の時間は１０ｍｓである。別の実施形態では、規定の時間は１０ｍｓ〜５００ｍｓの範囲から選択した任意の値であってもよい。いくつかの実施形態では、仮想算出システム１１０は、１つ以上の条件が満たされたら、規定の時間よりも短い時間周期内でユーザコードの実行を始めるように適合されている。例えば、１つ以上の条件には以下のうちのいずれか１つが含まれていてもよい。（１）要請を受け取った時に、ユーザコードをアクティブプール１４０Ａ内のコンテナ上にロードするか、（２）要請を受け取った時に、アクティブプール１４０Ａ内のインスタンスのコードキャッシュ内にユーザコードを記憶するか、（３）要請を受け取った時に、アクティブプール１４０Ａは、要請に関連するユーザに割り当てられたインスタンスを含んでいるか、または（４）要請を受け取った時に、ウォーミングプール１３０Ａは要請を扱う能力を有する。いくつかの実施形態では、要請されたコード実行を、コード実行要請を受け取ったらすぐに開始する代わりに、仮想算出システム１１０は、要請によって与えられるスケジューリング情報に従ってコード実行をスケジュールしてもよい。例えば、要請は、仮想算出システム１１０がコード実行の実行を要請される時間窓（例えば、３：００ＡＭ〜次の月曜日４：００ＡＭ）を指定してもよく、仮想算出システム１１０は、ある性能考察（例えば、作業負荷、待ち時間など）に基づいてコード実行をスケジュールしてもよい。

ユーザコードを補助サービス１０６（例えば、図１のストレージサービス１０８）からダウンロードしてもよい。図１に例示されたデータ１０８Ａは、１人以上のユーザによってアップロードされたユーザコード、このようなユーザコードに関連するメタデータ、または任意の他のデータであって、本明細書で説明する１つ以上の技術を実行するために仮想算出システム１１０が用いるデータを含んでいてもよい。図１の例ではストレージサービス１０８のみを例示しているが、仮想環境１００には、ユーザコードをダウンロードしてもよい他のレベルのストレージシステムが含まれていてもよい。例えば、各インスタンスは、１つ以上のストレージシステムであって、コンテナが形成されるインスタンスと物理的に関連するストレージシステム（例えば、インスタンスが実行されている物理的なコンピューティングシステム上に常駐するローカルストレージ）、または論理的に関連するストレージシステム（例えば、インスタンスとネットワーク通信し、仮想算出システム１１０の内または外に設けられたネットワーク接続ストレージシステム）を有していてもよい。代替的に、コードを、ストレージサービス１０８が与えるウェブベースのデータストアからダウンロードしてもよい。

ワーカーマネージャ１４０が、ウォーミングプール１３０Ａ内の仮想マシンインスタンスのうちの、ユーザコード実行要請に応えるために用いることができる１つの位置を特定した時点で、ウォーミングプールマネージャ１３０またはワーカーマネージャ１４０は、ウォーミングプール１３０Ａからインスタンスを取り出して、それを、要請に関連するユーザに割り当てる。割り当てられた仮想マシンインスタンスは、ウォーミングプール１３０Ａから取り出され、アクティブプール１４０Ａ内にセットされる。いくつかの実施形態では、いったん仮想マシンインスタンスが特定のユーザに割り当てられると、同じ仮想マシンインスタンスは、任意の他のユーザの要請を使用可能にするために使用されることができない。これは、ユーザリソースの混合の可能性を防ぐことによって、セキュリティの利点をユーザに提供する。代替的に、いくつかの実施形態では、異なるユーザに属する（または、異なるユーザに関連する要請に割り当てられた）複数のコンテナが、単一の仮想マシンインスタンス上で共存してもよい。このようなアプローチによって、利用可能な算出能力の利用が向上する場合がある。いくつかの実施形態では、仮想算出システム１１０は、別個のキャッシュであって、仮想マシンインスタンスのローカルキャッシュとウェブベースのネットワークストレージ（例えば、ネットワーク１０４を介してアクセス可能な）との間のキャッシングシステムの中間レベルとして機能するようにユーザコードが記憶される別個のキャッシュを維持してもよい。

ユーザコードを実行した後で、ワーカーマネージャ１４０は、ユーザコードを実行するために用いたコンテナを解体して、それが占有していたリソースを解放し、インスタンス内の他のコンテナが利用できるようにしてもよい。代替的に、ワーカーマネージャ１４０はコンテナを実行し続けて、同じユーザからのさらなる要請に応えるためにそれを用いてもよい。例えば、コンテナ内にすでにロードされているものと同じユーザコードに関連する別の要請を受け取った場合、要請を同じコンテナに割り当てることができ、その結果、新しいコンテナを形成してコンテナにユーザコードをロードすることに関連する遅延をなくすことができる。いくつかの実施形態では、ワーカーマネージャ１４０は、ユーザコードを実行するために用いるコンテナが形成されたインスタンスを解体してもよい。代替的に、ワーカーマネージャ１４０はインスタンス実行し続けて、同じユーザからのさらなる要請に応えるためにそれを用いてもよい。ユーザコードの実行が終了した後にコンテナ及び／またはインスタンスを実行し続けるか否かの決定は、以下に基づいてもよい。閾値時間、ユーザのタイプ、ユーザの平均の要請ボリューム、周期性情報（例えば、現時点でユーザコードを実行していないアクティブプール１４０Ａ内のコンテナ／インスタンスを、（ｉ）生かしておくことができるか（さらなる要請がすぐに到達することが予想されると周期性情報が示す場合）、または（ｉｉ）終了することができる（さらなる要請が、コンテナ／インスタンスを生かしておくことを妥当なものにするほど十分すぐに到達する可能性はないと、周期性情報が示す場合））、及び／または他の動作条件。例えば、何らの活動状態（例えば、コードの実行）も伴わずに閾値時間が経過した後で（例えば、５分間、３０分間、１時間、２４時間、３０日間など）、コンテナ及び／または仮想マシンインスタンスをシャットダウンして（例えば、削除する、終了する等）、そこに割り当てられているリソースを解放する。いくつかの実施形態では、コンテナが解体される前に経過する閾値時間は、インスタンスが解体される前に経過する閾値時間よりも短い。

いくつかの実施形態では、仮想算出システム１１０は、入力コード実行要請に応えるときに、補助サービス１０６のうちの１つ以上にデータを与えてもよい。例えば、仮想算出システム１１０は監視／ロギング／請求サービス１０７と通信してもよい。監視／ロギング／請求サービス１０７には以下が含まれていてもよい。仮想算出システム１１０から受け取った監視情報（例えば、コンテナのステータスと仮想算出システム１１０上のインスタンス）を管理するための監視サービス、；仮想算出システム１１０から受け取ったロギング情報（例えば、コンテナが行なう活動状態と仮想算出システム１１０上のインスタンス）を管理するためのロギングサービス；仮想算出システム１１０上でのユーザコードの実行に関連する請求情報を生成するための請求サービス（例えば、監視サービス及びロギングサービスが管理する監視情報及び／またはロギング情報に基づいて）。上記に説明されるような（例えば、仮想算出システム１１０に代わりに）監視／ロギング／請求サービス１０７によって行われる場合があるシステムレベル活動に加えて、監視／ロギング／請求サービス１０７は、仮想算出システム１１０上で実行されるユーザコードの代わりに、アプリケーションレベルのサービスを提供してもよい。例えば、監視／ロギング／請求サービス１０７は、仮想算出システム１１０上で実行されるユーザコードの代わりに、様々な入力、出力、または他のデータ及びパラメータを監視及び／またはロギングしてもよい。単一のブロックとして示しているが、監視、ロギング、及び請求サービス１０７は別個のサービスとして設けてもよい。

いくつかの実施形態では、ワーカーマネージャ１４０は、ワーカーマネージャ１４０が管理するインスタンス及びコンテナ（例えば、アクティブプール１４０Ａ内のもの）に対してヘルスチェックを実行してもよい。例えば、ワーカーマネージャ１４０によって行われるヘルスチェックは、ワーカーマネージャ１４０によって管理されるインスタンス及びコンテナが、（１）過って構成されたネットワーク及び／または開始構成、（２）メモリの消耗、（３）ファイルシステムの破損、（４）互換性のないカーネル、及び／またはインスタンス及びコンテナの性能を悪くし得る他の課題のいずれかのうちの、いずれかの問題があるかどうかを判定することを含んでもよい。一実施形態では、ワーカーマネージャ１４０はヘルスチェックを周期的に実行する（例えば、５分ごと、３０分ごと、１時間ごと、２４時間ごとなど）。いくつかの実施形態では、ヘルスチェックの頻度は、ヘルスチェックの結果に基づいて、自動的に調整されてもよい。他の実施形態では、ヘルスチェックの頻度はユーザ要請に基づいて調整してもよい。いくつかの実施形態では、ワーカーマネージャ１４０は、ウォーミングプール１３０Ａ内のインスタンス及び／またはコンテナ上で同様のヘルスチェックを実行してもよい。ウォーミングプール１３０Ａ内のインスタンス及び／またはコンテナは、アクティブプール１４０Ａ内のそのインスタンス及びコンテナと一緒または別個のいずれかで、管理されてもよい。いくつかの実施形態では、ウォーミングプール１３０Ａ内のインスタンス及び／またはコンテナのヘルス状態をアクティブプール１４０Ａとは別個に管理している場合、ウォーミングプールマネージャ１３０が、ワーカーマネージャ１４０代わりに、前述したヘルスチェックを、ウォーミングプール１３０Ａ内のインスタンス及び／またはコンテナ上で実行してもよい。
ルーティングマネージャ

ルーティングマネージャ１５０は、仮想算出システム１１０が受け取った入力コード実行要請と、このコード実行要請を扱うために用いる算出能力との間のマッピングを形成して管理する。マッピングによって、複数の要請によるあるコンテナ固有リソースの利用及び再利用が容易になる場合がある。例えば、所定のコンテナを、コード実行結果を記憶するキャッシュに関連付けてもよく、所定のコンテナ内で実行される任意のプログラムコードによってアクセスしてもよい。したがって、要請に関連するコード実行結果がキャッシュ内に記憶されたら、同じタイプの後続の要請が、所定のコンテナに送られているならば、キャッシュ内に記憶されたコード実行結果を用いてより効率的に扱われる場合がある。ルーティングマネージャ１５０を、仮想算出システム１１０内の別個のコンポーネントとして例示しているが、ルーティングマネージャ１５０の機能の一部または全部を、フロントエンド１２０、ウォーミングプールマネージャ１３０、及び／またはワーカーマネージャ１４０によって行なってもよい。例えば、ルーティングマネージャ１５０を全体的に、仮想算出システム１１０の他のコンポーネントの１つの中で、または仮想算出システム１１０の他のコンポーネントに渡って分散して、実施してもよい。図１の実施例では、ルーティングマネージャ１５０にはマッピングデータ１５０Ａが含まれる。マッピングデータ１５０Ａには、仮想算出システム１１０上で実行されるコンテナに入力コード実行要請をどのように送るべきかを示すデータが含まれていてもよい。マッピングデータ１５０Ａにはまた、仮想算出システム１１０が受け取った入力要請を送るためにユーザが指定したかまたはルーティングマネージャ１５０が決定した任意のコンテナ／ルーティングポリシーが含まれていてもよい。マッピングデータ１５０Ａを、仮想算出システム１１０内部のストレージデバイス内に記憶してもよく、及び／または外部ストレージデバイス（例えば、ストレージサービス１０８）内に記憶して、周期的にバックアップしてもよい。

ルーティングマネージャ１５０には以下が含まれていてもよい。所定のコード実行要請に関連するルーティングパラメータを判定するためのルーティングパラメータ決定ユニット、及び判定したルーティングパラメータに基づいて、所定のコード実行要請を扱うために用いるべき適切なコンテナを判定するためのコンテナルックアップユニット。ルーティングマネージャ１５０の構成例について、図２を参照して以下に詳細に説明する。
コンテナに関連するリソースを維持する

いくつかの実施形態では、仮想算出システム１１０上で実行するコンテナを、コンテナ内で実行する任意のプログラムコードからアクセス可能なコンテナ固有リソース（例えば、メモリ、ディスクストレージ、データベースなど）に関連付けてもよい。例えば、コンテナ内で実行されたプログラムコードのコード実行結果を、コンテナに関連するローカルメモリ内にキャッシュしてもよい。キャッシュされた結果を仮想算出システム１１０が用いて、同じタイプの他のコード実行要請（例えば、同じプログラムコード及び同じ引数セットに関連する要請）を容易にしてもよい。一例では、ユーザは、人がｚｉｐコードを打ち込んでそのｚｉｐコードに関連する気象情報を見ることができる気象サービスを提供することを望んでもよい。ｚｉｐコードを入力する度に、要請が仮想算出システム１１０に送られて、入力したｚｉｐコードを用いて気象情報ルックアップ機能（例えば、ユーザに割り当てられた仮想マシンインスタンス上に形成されたコンテナ内で）を実行してもよい。ルックアップ機能は、ｚｉｐコードを用いて気象データベースから気象情報を取り出して、取り出した気象情報を出力してよい。また取り出した気象情報を、コンテナに関連するメモリに記憶して、任意の将来のコード実行要請が記憶情報を利用できるようにしてもよい。例えば、同じｚｉｐコードを有する別の要請を受け取ったら（例えば、閾値時間周期内に）、気象情報ルックアップ機能が、気象データベースに進むことなく、キャッシュされた結果を単純に戻すことによって、多少の待ち時間利得が達成される場合がある。たとえ現在の気象情報がキャッシュされても、キャッシュした情報にアクセスすることができない異なるコンテナに後続の要請が送られる場合には、キャッシュした情報を気象情報ルックアップ機能が利用することはできず、待ち時間利得は達成できないであろう。それに加えてまたはその代わりに、仮想算出システム１１０には以下が含まれていてもよい。他のリソース（例えば、メモリ、ディスクストレージ、データベースなど）であって、インスタンスレベルにおいてアクセス可能な（例えば、特定のインスタンスまたはその上の任意のコンテナ上で実行される任意のプログラムコードによってアクセス可能である）、及び／またはアカウントレベルにおいてアクセス可能な（例えば、ユーザに関連するインスタンス上で実行される任意のプログラムコードによってアクセス可能である）もの。
要請と特定のコンテナとの間のマッピング

いくつかの実施形態では、ルーティングマネージャ１５０は、入力コード実行要請を処理して、どのコンテナに要請を送るべきかを決定する。例えば、仮想算出システム１１０が、所定のプログラムコードに関連する要請を初めて受け取るとき、仮想算出システム１１０上で実行される特定のコンテナに要請を送るマッピングはない場合がある。このような要請を受け取ったら、インスタンスを、ウォーミングプール１３０Ａからアクティブプール１４０Ａへ移動して、要請に関連するユーザに割り当ててもよい。次に、仮想算出システム１１０は、インスタンス上にコンテナを形成し、コンテナ上にプログラムコードをロードし、コンテナ内でプログラムコードを実行することができる。プログラムコードを実行する間に生成または取得された任意の情報を、コンテナに関連する１つ以上のコンピューティングリソースに記憶してもよい。コンピューティングリソースは、コンテナのみがアクセス可能なローカルメモリ及び／またはディスクストレージを含んでいてもよい。コンピューティングリソースはまた、仮想算出システム１１０または外部サービス（例えば、補助サービス１０６）上に維持されたデータベースを含んでいてもよい。プログラムコードを１つ以上のコンピューティングリソースにおいて実行する間に生成または取得された情報を記憶したら、ルーティングマネージャ１５０は、マッピングデータ１５０Ａの更新を、記憶されたコンテナ固有情報を用いることによって利益を得る場合がある将来の要請を、この特定のコンテナに送るように行なってもよい。

ルーティングマネージャ１５０は、任意の知られたハッシング方式または他のデータ構造を用いて、マッピングデータ１５０Ａを更新及び維持してもよい。例えば、要請に含まれる実行パラメータをハッシュして、コンテナのＩＤにマッピングしてもよい。マッピングデータ１５０Ａは、仮想算出システム１１０上で実行される各プログラムコードに対して、実行パラメータの種々の組み合わせを特定のコンテナにマッピングするテーブルを含んでいてもよい。ルーティングマネージャ１５０は、要請に含まれる実行パラメータのうちの１つ以上をハッシュしてルーティングパラメータを決定してもよく、ルーティングパラメータを用いて、マッピングデータ１５０Ａがルーティングパラメータをマッピングする特定のコンテナを決定してもよい。例えば、第１の要請が、引数「現在温度」及び「９００２０」を用いて関数Ｆｏｏを実行することを要請した場合、ルーティングマネージャ１５０は、第１の要請を第１のコンテナへ送ってもよく、第２の要請が、引数「現在温度」及び「１００１２」を用いて関数Ｆｏｏを実行することを要請した場合、ルーティングマネージャ１５０は第２の要請を第２のコンテナへ送ってもよい。別の例では、要請は、要請がその管理または変更を行なうように構成されているデータベースの名前を指定してもよい。このような例では、データベース名は、特定のコンテナにマッピングされたルーティングパラメータとして機能してもよい（例えば、コンテナＡにマッピングされたデータベースＡに関連する要請、コンテナＢ、Ｃ、及びＤにマッピングされたデータベースＢに関連する要請、コンテナＥにマッピングされたデータベースＣ、Ｄ、及びＥに関連する要請など）。

他の実施形態では、パラメータのサブセットのみを、ルーティングパラメータを生成するときに考慮する。このような例では、関数Ｆｏｏと引数「現在温度」とに関連する各要請を、他の引数値とは関係なく、同じコンテナに送ってもよい。さらに別の例では、マッピングデータ１５０Ａは、関数Ｆｏｏに関連するすべての要請を特定のコンテナに送るべきということを示してもよい。特定のコンテナに対するルーティングの例を本開示のいくつかの実施形態で用いているが、特定のインスタンス、特定のフロントエンド、特定の地理的位置、特定のワーカーマネージャなどに要請をマッピングするマッピングデータ１５０Ａを提供することに、本明細書で説明する技術を適用して、関連レベルの粒度におけるコンピューティングリソース（例えば、インスタンス固有リソース、アカウント固有リソース、場所固有リソースなど）を要請が用い得るようにしてもよい。

マッピングデータ１５０Ａを、ユーザが、例えば１つ以上のＵＩ、ＣＬＩ、ＡＰＩ、及び／または他のプログラムマチックインターフェースを介して、与えてもよい。仮想算出システム１１０が、あるコンテナ情報をユーザに、例えば、コンテナが形成または終了されたときに与えて、ユーザが特定のコンテナに対するマッピングデータを与えられるようにしてもよい。いくつかの実施形態では、第１のグループの要請（例えば、関数Ｆｏｏに関連する要請、ユーザが指定する特定のパラメータを含む要請、ある時間の間に受け取る要請など）をあるコンテナに送るべきであり、第２のグループの要請を別のコンテナに送るべきであると、マッピングデータ１５０Ａは指定してもよい。要請は特定のコンテナを用いて扱うべきであるという指示を要請内に与えることによって、及び／またはパラメータ値（例えば、ハッシュ値）と特定のコンテナとの間のマッピングを与えることによって、ユーザは、どの要請をどのコンテナを用いて（したがって、どのコンテナ固有リソースにアクセスして）扱うのかを制御する場合がある、また、コンテナ固有リソース（例えば、コンテナ内に局所的に記憶されたデータ）を用いる費用のかかる動作を省略することによって、要請に関連する待ち時間の減少を達成する場合がある。マッピングデータ１５０Ａは、以下に基づいてルーティングを提供してもよい。ユーザアカウント（例えば、異なるコンテナに送られた異なるユーザアカウントに関連する要請）、プログラムコード（例えば、異なるコンテナに送られた異なるプログラムコードに関連する要請）、時刻（例えば、異なるコンテナに送られた異なる時間、日、月、年などに受け取った要請）、地理的地域（例えば、異なるコンテナに送られた異なる地理的地域に関連する要請）、関数引数（例えば、異なるコンテナに送られたパラメータまたは引数の異なる組み合わせを有する要請）、他の要請パラメータまたはメタデータなど。いくつかの実施形態では、マッピングデータ１５０Ａのうち、このような要請をこの特定のコンテナに送る部分を、コンテナが終了したら（例えば、使用されていないことに起因して）削除する。
バックエンドリソースの管理

いくつかの実施形態では、ルーティングマネージャ１５０は、入力コード実行要請と共に用いられるバックエンドリソースを監視してもよい。ある場合には、第三者またはユーザ所有のリソース（例えば、ディスクストレージ、データベース、ネットワークなど）を、仮想算出システム１１０上で実行されるプログラムコードが用いてもよく、このようなリソースは、仮想算出システム１１０が管理するものと同じ様にスケール変更しなくてもよく（例えば、大きなバーストトラフィックを扱う）、その結果、インピーダンス不整合が形成される。このような場合には、仮想算出システム１１０によって、ユーザが要請とコンテナとの間のマッピングを指定できるようにして、バックエンドリソースがより制御された方法で利用されるようにしてもよい。例えば、マッピングデータ１５０Ａによって、第１のバックエンドリソースを用いるすべての要請を第１のコンテナに送るべきであり、第２のバックエンドリソースを用いるすべての要請を、１０コンテナのグループのうちのいずれかに送るべきであるということが与えられてもよい。このような例では、プログラムコードが第１のコンテナ内で実行されているときに、ユーザは、プログラムコードは第１のバックエンドリソースをアクセスまたは管理する唯一のものであり、第１のバックエンドリソースが多数の同時要請によって過度な負担をかけられることはないということを、確信することができる。
算出能力のユーザカスタマイゼーション

いくつかの実施形態では、仮想算出システム１１０によってユーザが、本人の要請を扱うために用いるインスタンスをカスタマイズできるようにしてもよい。例えば、ユーザは、例えば、１つ以上のＵＩ、ＣＬＩ、ＡＰＩ、及び／または他のプログラムマチックインターフェースを介して、特定のバージョンの言語ランタイム（または他のソフトウェアコンポーネント）が、ユーザに関連するコード実行要請に応えるインスタンス上に提供されることを、指定してもよい。これに応じて、仮想算出システム１１０は、新しいインスタンスがユーザに割り当てられたときに、指定されたバージョンの言語ランタイムをインストールして、新しいインスタンス上に形成される任意のコンテナが、インストールされる言語ランタイムにアクセスできるようにしてもよい。いくつかの実施形態では、ルーティングマネージャ１５０は、マッピングデータ１５０Ａを更新して、これらのカスタマイズされたインスタンス上で実行される１つ以上のコンテナにユーザに関連する要請が送られるようにして、最初のカスタマイゼーション（及び関連する待ち時間ヒット）の後で、カスタマイズされたインスタンス上に形成される後続のコンテナが、カスタマイゼーションを利用できるようにしてもよい。
フロントエンド／ルーティングマネージャゴシッピングルーティング情報

いくつかの実施形態では、仮想算出システム１１０は、複数のフロントエンド１２０が、ウォーミングプールマネージャ１３０とワーカーマネージャ１４０との異なるセットに関連していてもよい。このような実施形態では、ルーティングマネージャ１５０は、各フロントエンド１２０と通信して、入力コード実行要請を特定のコンテナ（またはインスタンス）に送るために用いるルーティング情報を与えてもよい。他の実施形態では、各フロントエンド１２０を異なるルーティングマネージャ１５０に関連付けてもよい。このような実施形態では、フロントエンド１２０及び／またはルーティングマネージャ１５０は、新しいルーティング情報（例えば、マッピングデータ１５０Ａ）が利用可能になったらすぐに、互いに情報をゴシップして、入力コード実行要請を適切なコンテナにルーティングできるようにしてもよい。例えば、フロントエンド１２０またはルーティングマネージャ１５０のうちの１つが新しいマッピング情報を得るかまたは決定したらすぐに、マッピング情報を仮想算出システム１１０上のすべてのフロントエンド１２０またはルーティングマネージャ１５０と共有する。
アカウント−、インスタンス−、関数−及びコンテナ−レベルリソース（１１）

いくつかの実施形態では、仮想算出システム１１０は１つ以上のコンピューティングリソースを種々のレベルで維持する。例えば、仮想算出システム１１０は、以下のものを維持してもよい。１つ以上のアカウントレベルリソース（例えば、同じアカウントに関連する任意のコード実行によってアクセス可能である）、１つ以上のインスタンスレベルリソース（例えば、同じインスタンス上の任意のコード実行によってアクセス可能である）、１つ以上の関数レベルリソース（例えば、同じ関数またはプログラムコードに関連する任意のコード実行によってアクセス可能である）、１つ以上のコンテナレベルリソース（例えば、同じコンテナ内の任意のコード実行によってアクセス可能である）など。コンピューティングリソースは、メモリ、ディスクストレージ、データベース、ネットワーク、または任意の他のリソースであって、コード実行中にアクセスし得るものを含んでいてもよい。コンテナライフサイクルを制御する外部サービス

いくつかの実施形態では、仮想算出システム１１０によって、第三者サービス（例えば、アプリケーション性能監視サービス、ロギングサービスなど）が、仮想算出システム１１０上に形成されたコンテナのライフサイクルに渡ってある量の制御を行使することができてもよい。ある場合には、これらのサービスには、特定のレートでのみまたは特定の種類のデータのみを取り込む能力があってもよい。このような場合には、コンテナが形成及び／または終了される速さをこれらのサービスが制御することが、仮想算出システム１１０によって可能であってもよい。これは例えば、コンテナが形成または終了される前後でこれらのサービスが１つ以上の動作を実行できるようにすることによって行なってもよい。一例では、ロギングサービスは、あるロギング動作をコンテナのライフサイクルの終わりに実行して、ロギング及び浄化動作を実行してもよい。別の例では、外部サービスが、特定のタイプの要請のみを外部サービスが管理するコンテナに送るべきであるということを指定してもよい。それに応じて、ルーティングマネージャ１５０は、マッピングデータ１５０Ａを更新して、指定したタイプの要請のみが、外部サービスが管理するコンテナに送られるようにしてもよい。コンテナライフサイクル管理

いくつかの実施形態では、ルーティングマネージャ１５０は、１つ以上のコンテナを、コンテナ内のコード実行が終了した直後または間もなくしてそれらを終了することを控えることによって、生かしておいてもよい。例えば、ルーティングマネージャ１５０は、あるコンテナを生かしておくことを、たとえそのコンテナを用いて任意の既存のコード実行要請に応えることができないとしても行なってもよい。このようなコンテナを生かしておくかどうかの判定は、コンテナを用いて扱うであろう要請を仮想算出システム１１０がどのくらい頻繁に受け取ると予想されるか、及び／またはこのようなコンテナに関連して、どのくらいの量の情報が、コンテナ固有コンピューティングリソースに記憶されているかに基づいてもよい。コンテナをその通常のスケジュール以上に生かしておくプロセスについて、図６を参照して以下に詳細に説明する。
将来のコード実行に関する情報

いくつかの実施形態では、ルーティングマネージャ１５０は、将来のコード実行に関する実行情報を仮想算出システム１１０上に維持してもよい。例えば、このような情報によって、関数Ｙの実行は関数Ｘの実行が成功したら行なうべきであり、関数Ｚの実行は関数Ｘの実行が不成功だったら行うべきであるということが与えられてもよい。このような例では、ルーティングマネージャ１５０は、プログラムコードの各実行の試みの後に実行情報をチェックして、次の行動方針を決定してもよい。別の例では、ルーティングマネージャ１５０は、プログラムコードが実行されるコンテナに関連する１つ以上のコンピューティングリソース内に実行情報を維持してもよく、コンテナに要請を送った後に実行情報をチェックしてもよい（これは例えば、ルーティングマネージャ１５０が、キャッシュした情報をチェックして、プログラムコードを実行すべきか否かまたはどのように実行すべきかを判定するときと同時に行なう）。
ローカルタイマ

いくつかの実施形態では、ルーティングマネージャ１５０は個々のコンテナ内にローカルタイマを維持してもよい。例えば、第１のコンテナは、第１のコンテナに関連するコンピューティングリソース（例えば、メモリ、ディスクストレージなど）内でローカルタイマを維持してもよく、第１のコンテナに送られた任意の要請は、第１のコンテナ内でコードを実行するためにローカルタイマを用いてもよい。第１のコンテナに送られる要請が利用することができるローカルタイマを維持することによって、ルーティングマネージャ１５０は、ある外部サービス（例えば、仮想算出システム１１０の外部のスケジューリングサービス）にアクセスしてタイミング情報を監視する必要がなくなり（例えば、要請はローカルタイマを単純に利用することができる）、その結果、待ち時間利得が達成される。
ルーティングマネージャの一般的なアーキテクチャ

図２に示すのは、仮想算出システム１１０内の仮想マシンインスタンスを管理するコンピューティングシステム（ルーティングマネージャ１５０と参照される）の一般的なアーキテクチャである。図２に示すルーティングマネージャの一般的なアーキテクチャ１５０には、本開示の態様を実施するために用いてもよいコンピュータハードウェア及びソフトウェアモジュールの配置が含まれている。ルーティングマネージャ１５０には、図２に示すものよりもはるかに多い（または少ない）要素が含まれていてもよい。しかしながら、有効な開示を提供するために、これらの一般的従来型要素の全てが示されることは必要ではない。例示したように、ルーティングマネージャ１５０には、プロセシングユニット１９０、ネットワークインターフェース１９２、コンピュータ可読媒体ドライブ１９４、入出力デバイスインターフェース１９６が含まれる。これらはすべて、通信バスを経由して互いに通信してもよい。ネットワークインターフェース１９２によって、１つ以上のネットワークまたはコンピューティングシステムに対する接続性が得られてもよい。プロセシングユニット１９０はこうして、情報及び命令を他のコンピューティングシステムまたはサービスから、ネットワーク１０４を介して受け取ってもよい。またプロセシングユニット１９０はメモリ１８０との間で通信して、任意的なディスプレイ（図示せず）に対する出力情報を、入出力デバイスインターフェース１９６を介してさらに与えてもよい。入出力デバイスインターフェース１９６はまた、任意的な入力デバイス（図示せず）から入力を受け入れてもよい。

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

ユーザインターフェースユニット１８２に加えて及び／またはそれと組み合わせて、メモリ１８０は、プロセシングユニット１９０が実行してもよいルーティングパラメータ決定ユニット１８６及びコンテナルックアップユニット１８８を含んでいてもよい。一実施形態では、ユーザインターフェースユニット１８２、ルーティングパラメータ決定ユニット１８６、及びコンテナルックアップユニット１８８は、本開示の種々の態様を別個にまたは一括で実施する。例えば、適切なコンテナに要請を送るためのルーティング情報を維持すること、入力コード実行要請を処理すること、要請に関連するルーティングパラメータを決定すること、要請を扱うために用いるべきコンテナを特定するなどである。以下でさらに説明する。

ルーティングパラメータ決定ユニット１８６は、所定のコード実行要請に関連するルーティングパラメータを決定する。例えば、ルーティングパラメータ決定ユニット１８６はコード実行要請を処理して、要請に含まれているルーティングパラメータを取り出す。付加的または代替的に、ルーティングパラメータ決定ユニット１８６は、以下のうちの１つ以上に基づいてルーティングパラメータを決定する。要請に関連するアカウント、要請に関連するプログラムコード、要請に含まれる実行パラメータ、または他のメタデータであって、要請に関連するもの（例えば、受け取り時間など）。

コンテナルックアップユニット１８８は、決定したルーティングパラメータを用いて、要請を送るべき適切なコンテナを検索する。任意の知られたハッシング及び／またはルックアップ方式を用いて、ルーティングパラメータを特定のコンテナに関連付けて、ルーティングパラメータに基づいて適切なコンテナを決定してもよい。

ルーティングパラメータ決定ユニット１８６とコンテナルックアップユニット１８８とを、図２では、ルーティングマネージャ１５０の一部として示しているが、他の実施形態では、ルーティングパラメータ決定ユニット１８６とコンテナルックアップユニット１８８の全部または一部を、単一のユニットとして、別個のユニットとして、または分散して、仮想算出システム１１０及び／または別のコンピューティングデバイスの他のコンポーネントによって実施してもよい。例えば、本開示のある実施形態では、仮想算出システム１１０と通信している別のコンピューティングデバイスは、ルーティングマネージャ１５０の一部として例示したモジュール及びコンポーネントと同様に動作するいくつかのモジュールまたはコンポーネントを含んでいてもよい。
コード実行要請を送るためのルーチン例

次に図３を参照して、仮想算出システム１１０の１つ以上のコンポーネント（例えば、ルーティングマネージャ１５０）が実施するルーチン３００について説明する。ルーチン３００をルーティングマネージャ１５０による実施に関して説明しているが、当業者であれば分かるように、代替的なコンポーネントがルーチン３００を実施してもよいし、またはブロックのうちの１つ以上を異なるコンポーネントによってもしくは分散して実施してもよい。

例示的なルーチン３００のブロック３０２において、ルーティングマネージャ１５０は、複数の仮想マシンインスタンスを維持する。複数の仮想マシンインスタンスには、ウォーミングプール（例えば、ウォーミングプール１３０Ａ）であって、１つ以上のソフトウェアコンポーネントがロードされた仮想マシンインスタンスを含み、ユーザに割り当てられるのを待っている、ウォーミングプールと、アクティブプール（例えば、アクティブプール１４０Ａ）であって、１人以上のユーザに現時点で割り当てられている仮想マシンインスタンスを含む、アクティブプールと、が含まれていてもよい。アクティブプール内の仮想マシンインスタンスには、そこでプログラムコードを実行するために１つ以上のコンテナが形成されていてもよい。

ブロック３０４において、ルーティングマネージャ１５０は、プログラムコードを実行する要請を仮想算出システム１１０上で処理する。要請には、ユーザ指示として、プログラムコードの実行を、プログラムコードを事前に実行することによって変更された１つ以上のコンピューティングリソースに基づいて行なうべきというユーザ指示が含まれていてもよい。例えば、プログラムコードを事前に実行したら、あるデータ（例えば、データベースに記憶されたキー値ペア、関数戻り値など）を取り出してもよく（例えば、仮想算出システム１１０と通信している外部データベースサービスから）、または計算して、事前の実行が行なわれたコンテナに局所的に記憶してもよく、また記憶データにアクセスすることによって利益を得る場合がある任意の後続の要請、またはこのような記憶データを用いるというユーザ指示を含む任意の後続の要請を、事前の実行が行なわれたコンテナに送ることによって、局所的に記憶したデータに後続の実行がアクセスしてもよい。要請にはまた、ユーザアカウント情報（例えば、ユーザに関連するアカウントの身元）、プログラムコード情報（例えば、実行すべき第１のプログラムコードの身元）、及び第１のプログラムコードを実行するために用いるべき１つ以上のパラメータ（例えば、実行パラメータ、関数引数など）が含まれていてもよい。

ブロック３０６において、ルーティングマネージャ１５０は、ユーザ指示であって、プログラムコードの実行はプログラムコードの事前の実行によって変更された１つ以上のコンピューティングリソースに基づいて行なうべきというユーザ指示に基づいて、複数の仮想マシンインスタンスのうちの、１つ以上のコンピューティングリソースに関連する第１の仮想マシンインスタンス上のコンテナを特定する。例えば、ルーティングマネージャ１５０は、要請内に与えられるユーザ指示に基づいてハッシュ値を計算し、仮想算出システム上に維持された、特定のコンテナにハッシュ値をマッピングするマッピングテーブル（例えば、マッピングデータ１５０Ａ）内でのハッシュ値のルックアップを実行してもよい。例えば、ユーザ指示（または仮想算出システム１１０上に維持されたマッピングデータ１５０Ａ）はさらに、同じパラメータ（例えば、気象情報を検索するために用いるべきｚｉｐコード）に関連する要請は、同じコンテナに送らなくてはいけないことを示してもよい。コンテナを宛先例として用いているが、要請またはマッピングデータ１５０Ａは、複数のコンテナまたはコンテナのグループのうちの１つに要請を送るべきということを示してもよい。

ブロック３０８において、ルーティングマネージャ１５０はプログラムコードをコンテナ内で実行する。一例では、ルーティングマネージャ１５０（または仮想算出システム１１０の別のコンポーネント、例えばワーカーマネージャ１４０）は、同じタイプの要請がコンテナ内で処理されたか否かを判定してもよく、そうである場合には、コンテナに関連する１つ以上のコンピュータリソースが、プログラムコードの実行を容易にする可能性がある情報を含むか否かを判定してもよい。例えば、プログラムコードに関連する事前の実行結果を、コンテナに関連するメモリに記憶してもよい。このような場合、プログラムコードの現在の実行は、事前の実行結果の利用可能性に基づいて、事前の実行結果を出力するかもしくは戻してもよいし、またはある演算処理（例えば、データ取り出し、関数呼び出し、データ計算など）を省略してもよく、その結果、待ち時間の減少が実現する。

図３のルーチン３００を、ブロック３０２〜３０８を参照して前述したが、本明細書で説明する実施形態はこのようには限定されず、本開示の趣旨から逸脱することなく、１つ以上のブロックを省略、変更、または切り換えてもよい。
マッピングテーブル例

次に図４を参照して、図１の仮想算出システム１１０または補助サービス１０６が維持するマッピングテーブル例について説明する。図４に例示するように、表４００には、「要請Ａ」、「要請Ｂ」、「要請Ｃ」、及び「要請Ｄ」と標示された入力コード実行要請が含まれている。これらはそれぞれ、ルーティングパラメータとコンテナＩＤとに関連している。例えば、要請Ａはルーティングパラメータ値がＸでコンテナＩＤが２であり、要請Ｂはルーティングパラメータ値がＹでコンテナＩＤが７であり、要請Ｃはルーティングパラメータ値がＣでコンテナＩＤが２であり、要請Ｄはルーティングパラメータ値がＤでコンテナＩＤが１である。図４の実施例では、要請Ａ〜Ｄが仮想算出システム１１０によって順次に（例えば、Ａ、次にＢ、次にＣ、次にＤと）受け取られると仮定する。ルーティングマネージャ１５０は、要請Ａに関連するルーティングパラメータを、要請に含まれるルーティングパラメータに基づいて、または要請の種類（例えば、関連ユーザアカウント、関数など）に基づいて、決定してもよい。ルーティングマネージャ１５０は、要請Ａのルーティングパラメータは「Ｘ」であると決定し、ルーティングパラメータＸに関連するコンテナを特定する。これはＩＤ値が２のコンテナである。要請Ａを処理した後で、要請Ｂを受け取って、決定したルーティングパラメータ値「Ｙ」に基づいてＩＤ値が７のコンテナに送る。要請Ｃを受け取ったら、ルーティングマネージャ１５０は、要請Ｃは、以前に扱った要請Ａと同じルーティングパラメータ値を有していると判定する。マッピングテーブル４００に従って、要請ＣもＩＤ値が２のコンテナを用いて扱うことで、要請Ｃが、要請Ａによって処理されてＩＤ値が２のコンテナに関連して記憶された情報を用いることができるならば、多少の待ち時間利得を潜在的に達成することができる。次に、要請Ｄを受け取って、ＩＤ値が１のコンテナに送ることを、判定したルーティングパラメータ値「Ｚ」に基づいて行なう。いくつかの実施形態では、ルーティングパラメータ値は、プログラムコードを実行するために要請された特定のリソース（例えば、図１のリソース例えばリソース１５８Ｃ及びリソース１５９Ａ−１を特定するリソースＩＤ）を示してもよい。例えば、同じリソースを用いることを要請する要請を、同じコンテナまたは同じコンテナグループに送ってもよい。

マッピングテーブル（またはマッピングデータ１５０Ａ）は、図４の例に示す構成には限定されず、要請をどのコンテナにどのように送るべきかを決定するために用いる任意の数のパラメータを含んでいてもよい。
コード実行結果をキャッシュするためのルーチン例

次に図５を参照して、仮想算出システム１１０の１つ以上のコンポーネント（例えば、ルーティングマネージャ１５０）が実施するルーチン５００について説明する。ルーチン５００をルーティングマネージャ１５０による実施に関して説明しているが、当業者であれば分かるように、代替的なコンポーネントがルーチン５００を実施してもよいし、またはブロックのうちの１つ以上を異なるコンポーネントによってもしくは分散して実施してもよい。

例示的なルーチン５００のブロック５０２において、ルーティングマネージャ１５０は、プログラムコードを実行する要請をコンテナに送る。要請を送るコンテナを、図３を参照して説明するルーチン３００に従って特定してもよい。

ブロック５０４において、ルーティングマネージャ１５０は、要請が用いてもよい事前のコード実行データが、コンテナに関連するリソース（例えば、メモリ、ディスクストレージ、データベースなど）のうちの１つにおいて利用可能であるか否かを判定する。いくつかの例では、ルーティングマネージャ１５０は、コンテナに関連するコンピューティングリソースに、現在の要請に関連して用いることに利用できる任意の情報（例えば、コード実行結果、または他のデータ、決定、及び／または計算）が含まれているか否かを判定してもよい。ルーティングマネージャ１５０が、要請が用いてもよい事前のコード実行データが利用できると判定した場合、ルーチンはブロック５１０に進む。ここでは、事前のコード実行データをプログラムコードに与える。そうでない場合は、ルーチン５００はブロック５０６に進む。

ブロック５０６において、ルーティングマネージャ１５０はプログラムコードをコンテナ内で実行する。プログラムコードを要請に含まれている１つ以上のパラメータを用いて実行してもよい。いくつかの実施形態では、キャッシュされたデータをプログラムコードに与えることによって、プログラムコードは、キャッシュされたデータがないときのプログラムコードとは異なる状態で開始する。プログラムコードは、キャッシュされたデータの利用可能性に基づいて、ある演算処理（例えばデータ取り出しまたは計算）を省略してもよい。コード実行が終了したら、ルーティングマネージャ１５０は、同じまたは同様のタイプの将来の要請の処理を容易にし得る任意の情報を、コンテナに関連する１つ以上のコンピューティングリソースに記憶してもよい。ブロック５０８において、ルーティングマネージャ１５０は、プログラムコードを実行することから取得したコード実行結果を出力する。ある場合には、出力したコード実行結果は、ブロック５１０においてプログラムコードに与えたキャッシュされたデータと同一であってもよい。別の場合では、プログラムコードは、キャッシュされたデータをさらに処理または変更して、キャッシュされたデータとは異なるコード実行結果を生成する。

図５のルーチン５００を、ブロック５０２〜５１０を参照して前述したが、本明細書で説明する実施形態はこのようには限定されず、本開示の趣旨から逸脱することなく、１つ以上のブロックを省略、変更、または切り換えてもよい。コンテナライフサイクルを管理するためのルーチン例

次に図６を参照して、仮想算出システム１１０の１つ以上のコンポーネント（例えば、ルーティングマネージャ１５０）が実施するルーチン６００について説明する。ルーチン６００をルーティングマネージャ１５０による実施に関して説明しているが、当業者であれば分かるように、代替的なコンポーネントがルーチン６００を実施してもよいし、またはブロックのうちの１つ以上を異なるコンポーネントによってもしくは分散して実施してもよい。

例示的なルーチン６００のブロック６０２において、ルーティングマネージャ１５０はコンテナ上でのプログラムコードの実行を終了する。ブロック６０４において、ルーティングマネージャ１５０は、コンテナに関連する１つ以上のコンピューティングリソースを、終了した実行に基づいて更新する。更新されたコンピューティングリソースには、同じまたは同様のタイプの将来の要請の処理を容易にし得る情報が含まれていてもよい。これについては、図５を参照して述べた通りである。

ブロック６０６において、ルーティングマネージャ１５０が、コンテナを生かしておくための１つ以上の閾値基準が満たされているか否かを判定する。ある場合には、たとえ仮想算出システム１１０に、コンテナを用いて扱うことができる何らの要請がなくても、このような要請がすぐに到着して、コンテナに関連して記憶された情報を用いることがあり得ると予想して、コンテナを即座にシャットダウンしなくてもよい。このような場合、コンテナを生かしておくこと及びコンテナを用いて将来の要請を扱うことによって達成される性能向上が、コンテナを生かしておくことのコストよりも重要である場合、ルーティングマネージャ１５０は、通常のスケジュールよりも長時間コンテナを生かすことを選択してもよい。閾値基準には、同じタイプの要請を受け取る閾値頻度レベルが含まれていてもよい。例えば、コンテナが、近い将来に多数が用いる可能性がある（例えば、閾値頻度レベルよりも大きい頻度で受け取ることが予想される）キャッシュした情報を有する場合、ルーティングマネージャ１５０はコンテナを生かしてもよい。閾値基準には、コンテナに関連して記憶した情報の閾値サイズが含まれていてもよい。コンテナが多くの情報（例えば、閾値よりも多い）をローカルメモリまたはストレージに記憶している場合、ルーティングマネージャ１５０はコンテナを生かしてもよい。ルーティングマネージャ１５０が閾値基準は満たされていないと判定した場合、ルーチン６００は６１０に進む。そうでない場合は、ルーチン６００はブロック６０８に進む。

ブロック６０８において、ルーティングマネージャ１５０は、将来のコード実行要請を扱うためにコンテナを実行し続ける。いくつかの実施形態では、コンテナをその通常のスケジュールを越えて生かす時間は、コンテナ内に記憶された情報のサイズまたはコンテナ内に記憶された情報を用いるであろう要請の受け取りが予想される頻度に比例している。他の実施形態では、コンテナを固定時間の間生かしておき、コンテナが固定時間の間使われないでいたら、コンテナをシャットダウンする。

ブロック６１０において、ルーティングマネージャ１５０は、コンテナに関連する任意のキャッシュされたデータを、コンテナをシャットダウンしたときに実行するように構成されているシャットダウンプログラムコード（またはシャットダウンフック）に与える。シャットダウンプログラムコードを用いて、任意のロギング、監視、浄化、または他の動作であってコンテナに関連するものを実行してもよい。ブロック６１２において、ルーティングマネージャ１５０はシャットダウンプログラムコードをコンテナ内で実行する。ブロック６１４において、ルーティングマネージャ１５０はコンテナをシャットダウンさせる。いくつかの実施形態では、ルーティングマネージャ１５０は、シャットダウンを行なう前にコンテナにシャットダウンを通知して、コンテナ固有コンピューティングリソース内に記憶された任意のデータを、コンテナをシャットダウンした後でさえ利用できるパーマネントストレージ内に記憶できるようにしてもよい。

図６のルーチン６００を、ブロック６０２〜６０８を参照して前述したが、本明細書で説明する実施形態はこのようには限定されず、本開示の趣旨から逸脱することなく、１つ以上のブロックを省略、変更、または切り換えてもよい。例えば、いくつかの実施形態では、ブロック６１４において、コンテナをシャットダウンしない代わりにリセットまたはクリアする。他の考察

当業者等であれば分かるように、本開示で説明した関数はすべて、開示したコンポーネント及び移動可能な通信デバイスの１つ以上の物理プロセッサによって実行されるソフトウェアにおいて具体化してもよい。ソフトウェアは、任意の種類の不揮発性ストレージ内に持続的に記憶されてもよい。

条件付き言語、例えば、とりわけ、「ｃａｎ」、「ｃｏｕｌｄ」、「ｍｉｇｈｔ」、または「ｍａｙ」は、特に記載のない限り、または用いたコンテキスト内で他の形式で理解されない限り、全般的に、ある実施形態に、他の実施形態には含まれていないが、ある特徴、要素及び／またはステップが含まれていると伝えることを意図している。したがって、そのような条件的言語は、概して、特徴、要素、及び／またはステップが、１つ以上の実施形態に任意の方法で要求されるか、または１つ以上の実施形態が、ユーザ入力もしくはプロンプトを用いて、もしくは用いずに、これらの特徴、要素、及び／もしくはステップが含まれるか、もしくは任意の特定の実施形態で行われるべきであるかを決定するための論理を必ず含むことを含意することは意図していない。

本明細書で説明し及び／または添付図に示したフロー図における任意のプロセス記述、要素、またはブロックは、プロセスにおける特定の論理機能またはステップを実施するための１つ以上の実行可能命令を含むコードのモジュール、セグメント、または一部を潜在的に表すと理解すべきである。代替的な実施態様は、本明細書に記載される実施形態の範囲内に含まれ、要素または機能が、当業者によって理解されるように、関係する機能性に応じて、実質的に同時または逆の順序を含む、示されるものとは異なる順序で、削除、実行、または説明され得る。さらに当然のことながら、前述したデータ及び／またはコンポーネントを、コンピュータ可読媒体上に記憶してもよく、またコンピューティングデバイスのメモリ内にロードしてもよい。これは、コンピュータ実行可能コンポーネントを記憶するコンピュータ可読記憶媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはネットワークインターフェース）に関連する駆動メカニズムを用いて行なう。さらに、コンポーネント及び／またはデータを、単一のデバイスに含めることもできるし、何らかの方法で分配することもできる。その結果、汎用コンピューティングデバイスは、上記に説明される様々なデータ及び／またはコンポーネントの処理及び／または実行とともに、本開示のプロセス、アルゴリズム、及び手順を実施するように構成され得る。

前述したことは、以下の条項を考慮することでより良好に理解される場合がある。
１．低待ち時間の算出能力を提供するためのシステムであって、複数のキー値ペアを記憶するように構成された外部データベースサービスと、特定のコンピュータ実行可能命令を実行する１つ以上のハードウェアコンピューティングデバイスを含む仮想算出システムであって、前記仮想算出システムは前記外部データベースサービスと通信しており、少なくとも、１つ以上の物理コンピューティングデバイス上で複数の仮想マシンインスタンスを維持することであって、前記複数の仮想マシンインスタンスは、１つ以上のソフトウェアコンポーネントがロードされる仮想マシンインスタンスであって、ユーザに割り当てられるのを待っている前記仮想マシンインスタンスを含むウォーミングプールと、現時点で１人以上のユーザに割り当てられている仮想マシンインスタンスを含むアクティブプールと、を含む、前記維持することと、前記仮想算出システム上で、第１のユーザに関連する第１のプログラムコードを実行する第１の要請を処理することであって、前記第１の要請は、前記第１のユーザの身元と、前記第１のプログラムコードを実行するために用いるべき１つ以上の第１の実行パラメータと、を含む、前記処理することと、前記第１のプログラムコードを、前記アクティブプール内の第１の仮想マシンインスタンス上に形成された第１のコンテナ内で、前記１つ以上の第１の実行パラメータを用いて実行することであって、前記プログラムコードの実行によって、前記複数のキー値ペアのうちの１つ以上のキー値ペアを、前記外部データベースサービスから取り出して、前記第１のコンテナ内に局所的に記憶する、前記実行することと、前記仮想算出システム上で前記第１のプログラムコードを実行する第２の要請を処理することであって、前記第２の要請は、前記第１のユーザの身元と、前記第１のプログラムコードを実行するために用いるべき１つ以上の第２の実行パラメータと、前記第２の要請は前記第１の要請を扱うために以前に用いた前記第１のコンテナを用いて扱うべきであるというユーザ指示と、を含む、前記処理することと、前記第２の要請は前記第１のコンテナを用いて扱うべきという前記ユーザ指示に基づいて、前記１つ以上の第２の実行パラメータを用いて前記第１のコンテナ内で前記第１のプログラムコードを実行することであって、前記第１のプログラムコードの実行は、前記第１のコンテナ内に局所的に記憶された前記１つ以上のキー値ペアへのアクセスを、前記１つ以上の第２の実行パラメータに基づく前記第１のプログラムコードの実行に関連する待ち時間が減るように行なう、前記実行することと、を行なうように構成されている、前記仮想算出システムと、を含む、前記システム。

２．前記仮想算出システムは、前記ユーザ指示に関連するハッシュ値を計算し、前記計算されたハッシュ値のルックアップを、前記仮想算出システムによって維持されるマッピングテーブル内で行なうことによって、前記第１のコンテナを特定することであって、前記マッピングテーブルは、１つ以上のハッシュ値を、前記複数の仮想マシンインスタンス上で実行される特定のコンテナにマッピングする、前記特定することと、を行なうように構成されている条項１に記載のシステム。

３．前記１つ以上の第２の実行パラメータを用いた前記第１のプログラムコードの実行は、前記第１のコンテナ内に局所的に記憶された前記１つ以上のキー値ペアに基づいて、前記外部データベースサービスからの少なくとも１回のデータの取り出しを省略する条項１に記載のシステム。

４．前記仮想算出システムはさらに、前記１つ以上の第２の実行パラメータを用いた前記第１のプログラムコードの実行が終了した後でさえ前記第１のコンテナを実行し続けて、前記第１のコンテナを用いるように指示を出す後続の要請を前記第１のコンテナを用いて扱うことができるように構成されている条項１に記載のシステム。

５．システムであって、特定のコンピュータ実行可能命令を実行する１つ以上のハードウェアコンピューティングデバイスを含む仮想算出システムであって、少なくとも、１つ以上の物理コンピューティングデバイス上で複数の仮想マシンインスタンスを維持することと、前記仮想算出システム上で第１のプログラムコードを実行する第１の要請を処理することであって、前記第１の要請は、ユーザアカウント情報と、前記第１のプログラムコードを実行するために用いるべき１つ以上のパラメータと、前記第１のプログラムコードは、前記第１のプログラムコードの事前の実行によって変更される１つ以上のコンピューティングリソースに基づいて実行すべきというユーザ指示と、を含む、前記処理することと、前記第１のプログラムコードは、前記第１のプログラムコードの事前の実行によって変更される１つ以上のコンピューティングリソースに基づいて実行すべきという前記ユーザ指示に基づいて、前記複数の仮想マシンインスタンスのうち、前記第１のプログラムコードの事前の実行によって変更される前記１つ以上のコンピューティングリソースに関連する第１の仮想マシンインスタンス上で、第１のコンテナを特定することと、前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースに基づいて、前記第１のプログラムコードを前記第１のコンテナ内で実行することと、を行なうように構成されている、前記仮想算出システム、を含む前記システム。

６．前記仮想算出システムは、入力コード実行要請に関連する１つ以上の値を前記複数の仮想マシンインスタンス上で実行される特定のコンテナにマッピングするマッピングテーブルを維持するように構成されている条項５に記載のシステム。

７．前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースは、前記仮想算出システムと通信している外部サービスから、前記第１のプログラムコードの事前の実行と共に取り出したデータを記憶する前記第１のコンテナ内に、ローカルストレージを含む条項５に記載のシステム。

８．前記仮想算出システムはさらに、前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースが、前記第１のプログラムコードの事前の実行に関連するキャッシュされたデータを含んでいると判定することと、前記キャッシュされたデータを前記第１のコンテナ内での前記第１のプログラムコードの実行に与えることであって、前記第１のプログラムコードの実行が、前記キャッシュされたデータに基づいて少なくとも１つの演算処理を省略することによって、待ち時間の減少が実現する、前記与えることと、を行なうように構成されている条項５に記載のシステム。

９．前記第１の仮想マシンインスタンスが、前記第１の仮想マシンインスタンス上で実行される１つ以上のコンテナによってアクセス可能な１つ以上のインスタンス固有コンピューティングリソースを有する条項５に記載のシステム。

１０．前記ユーザ指示は、前記仮想算出システムに前記第１の要請をユーザ選択のコンテナに送らせるようにするパラメータを指定する条項５に記載のシステム。

１１．前記仮想算出システムは、同じユーザ指示を含む入力コード実行要請を同じコンテナに送るように構成されている条項５に記載のシステム。

１２．前記仮想算出システムはさらに、前記第１のコンテナがシャットダウンされたときに、前記第１のコンテナに関連するシャットダウンプログラムコードを自動的に実行するように構成されている条項５に記載のシステム。

１３．コンピュータ実装方法であって、具体的な実行可能命令で構成される１つ以上のコンピューティングデバイスによって実施されるように、１つ以上の物理コンピューティングデバイス上で複数の仮想マシンインスタンスを維持することであって、前記仮想算出システム上で第１のプログラムコードを実行する第１の要請を処理することであって、前記第１の要請は、ユーザアカウント情報と、前記第１のプログラムコードを実行するために用いるべき１つ以上のパラメータと、前記第１のプログラムコードは、前記第１のプログラムコードの事前の実行によって変更される１つ以上のコンピューティングリソースに基づいて実行すべきというユーザ指示と、を含む、前記処理することと、前記第１のプログラムコードは、前記第１のプログラムコードの事前の実行によって変更される１つ以上のコンピューティングリソースに基づいて実行すべきという前記ユーザ指示に基づいて、前記複数の仮想マシンインスタンスのうち、前記第１のプログラムコードの事前の実行によって変更される前記１つ以上のコンピューティングリソースに関連する第１の仮想マシンインスタンス上で、第１のコンテナを特定することと、前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースに基づいて、前記第１のプログラムコードを前記第１のコンテナ内で実行する、ことと、を含む前記コンピュータ実装方法。

１４．前記入力コード実行要請に関連する１つ以上の値を前記複数の仮想マシンインスタンス上で実行される特定のコンテナにマッピングするマッピングテーブルを維持することをさらに含む条項１３に記載の方法。

１５．前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースは、前記仮想算出システムと通信している外部サービスから、前記第１のプログラムコードの事前の実行と共に取り出したデータを記憶する前記第１のコンテナ内に、ローカルストレージを含む条項１３に記載の方法。

１６．第１のコンテナに関連する１つ以上のコンピューティングリソースが、第１のプログラムコードの事前の実行に関連するキャッシュされたデータを含んでいるか否かを判定することと、前記キャッシュされたデータを前記第１のコンテナ内の前記第１のプログラムコードの実行に与えることであって、前記第１のプログラムコードの実行が、前記キャッシュされたデータに基づいて少なくとも１つの演算処理を省略することによって、待ち時間の減少が実現する、前記与えることと、をさらに含む条項１３に記載。

１７．前記第１の仮想マシンインスタンスが、前記第１の仮想マシンインスタンス上で実行される１つ以上のコンテナによってアクセス可能な１つ以上のインスタンス固有コンピューティングリソースを有する条項１３に記載の方法。

１８．前記ユーザ指示が、前記仮想算出システムに前記第１の要請をユーザ選択のコンテナに送らせるパラメータを指定する条項１３に記載の方法。

１９．同じユーザ指示を含む入力コード実行要請を同じコンテナに送ることをさらに含む条項１３に記載の方法。

２０．前記第１のコンテナをシャットダウンしたときに、前記第１のコンテナに関連するシャットダウンプログラムコードを自動的に実行することをさらに含む条項１３に記載の方法。

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

Claims (15)

1. 低待ち時間の算出能力を提供するためのシステムであって、
   複数のキー値ペアを記憶するように構成された外部データベースサービスと、
   特定のコンピュータ実行可能命令を実行する１つ以上のハードウェアコンピューティングデバイスを含む仮想算出システムであって、前記仮想算出システムは前記外部データベースサービスと通信しており、少なくとも、
   １つ以上の物理コンピューティングデバイス上で複数の仮想マシンインスタンスを維持することであって、前記複数の仮想マシンインスタンスは、
   １つ以上のソフトウェアコンポーネントがロードされる仮想マシンインスタンスであって、ユーザに割り当てられるのを待っている前記仮想マシンインスタンスを含むウォーミングプールと、
   現時点で１人以上のユーザに割り当てられている仮想マシンインスタンスを含むアクティブプールと、を含む、前記維持することと、
   前記仮想算出システム上で、第１のユーザに関連する第１のプログラムコードを実行する第１の要請を処理することであって、前記第１の要請は、前記第１のユーザの身元と、前記第１のプログラムコードを実行するために用いるべき１つ以上の第１の実行パラメータと、を含む、前記処理することと、
   前記第１のプログラムコードを、前記アクティブプール内の第１の仮想マシンインスタンス上に形成された第１のコンテナ内で、前記１つ以上の第１の実行パラメータを用いて実行することであって、前記プログラムコードの実行によって、前記複数のキー値ペアのうちの１つ以上のキー値ペアを、前記外部データベースサービスから取り出して、前記第１のコンテナ内に局所的に記憶する、前記実行することと、
   前記仮想算出システム上で前記第１のプログラムコードを実行する第２の要請を処理することであって、前記第２の要請は、前記第１のユーザの身元と、前記第１のプログラムコードを実行するために用いるべき１つ以上の第２の実行パラメータと、前記第２の要請は前記第１の要請を扱うために以前に用いた前記第１のコンテナを用いて扱うべきであるというユーザ指示と、を含む、前記処理することと、
   前記第２の要請は前記第１のコンテナを用いて扱うべきという前記ユーザ指示に基づいて、前記１つ以上の第２の実行パラメータを用いて前記第１のコンテナ内で前記第１のプログラムコードを実行することであって、前記第１のプログラムコードの実行は、前記第１のコンテナ内に局所的に記憶された前記１つ以上のキー値ペアへのアクセスを、前記１つ以上の第２の実行パラメータに基づく前記第１のプログラムコードの実行に関連する待ち時間が減るように行なう、前記実行することと、を行なうように構成されている、前記仮想算出システムと、を含む、前記システム。
2. 前記仮想算出システムは、前記ユーザ指示に関連するハッシュ値を計算し、前記計算されたハッシュ値のルックアップを、前記仮想算出システムによって維持されるマッピングテーブル内で行なうことによって、前記第１のコンテナを特定することであって、前記マッピングテーブルは、１つ以上のハッシュ値を、前記複数の仮想マシンインスタンス上で実行される特定のコンテナにマッピングする、前記特定すること、を行なうように構成されている請求項１に記載のシステム。
3. 前記１つ以上の第２の実行パラメータを用いた前記第１のプログラムコードの実行は、前記第１のコンテナ内に局所的に記憶された前記１つ以上のキー値ペアに基づいて、前記外部データベースサービスからの少なくとも１回のデータの取り出しを省略する請求項１に記載のシステム。
4. 前記仮想算出システムはさらに、前記１つ以上の第２の実行パラメータを用いた前記第１のプログラムコードの実行が終了した後でさえ前記第１のコンテナを実行し続けて、前記第１のコンテナを用いるように指示を出す後続の要請を前記第１のコンテナを用いて扱うことができるように構成されている請求項１に記載のシステム。
5. システムであって、
   特定のコンピュータ実行可能命令を実行する１つ以上のハードウェアコンピューティングデバイスを含む仮想算出システムであって、少なくとも、
   １つ以上の物理コンピューティングデバイス上で複数の仮想マシンインスタンスを維持することと、
   前記仮想算出システム上で第１のプログラムコードを実行する第１の要請を処理することであって、前記第１の要請は、ユーザアカウント情報と、前記第１のプログラムコードを実行するために用いるべき１つ以上のパラメータと、前記第１のプログラムコードは、前記第１のプログラムコードの事前の実行によって変更される１つ以上のコンピューティングリソースに基づいて実行すべきというユーザ指示と、を含む、前記処理することと、
   前記第１のプログラムコードは、前記第１のプログラムコードの事前の実行によって変更される１つ以上のコンピューティングリソースに基づいて実行すべきという前記ユーザ指示に基づいて、前記複数の仮想マシンインスタンスのうち、前記第１のプログラムコードの事前の実行によって変更される前記１つ以上のコンピューティングリソースに関連する第１の仮想マシンインスタンス上で、第１のコンテナを特定することと、
   前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースに基づいて、前記第１のプログラムコードを前記第１のコンテナ内で実行することと、を行なうように構成されている、前記仮想算出システム、を含む前記システム。
6. 前記仮想算出システムは、入力コード実行要請に関連する１つ以上の値を前記複数の仮想マシンインスタンス上で実行される特定のコンテナにマッピングするマッピングテーブルを維持するように構成されている請求項５に記載のシステム。
7. 前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースは、前記仮想算出システムと通信している外部サービスから、前記第１のプログラムコードの事前の実行と共に取り出したデータを記憶する前記第１のコンテナ内に、ローカルストレージを含む請求項５に記載のシステム。
8. 請求項に記載のシステムであって、前記仮想算出システムはさらに、
   前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースが、前記第１のプログラムコードの事前の実行に関連するキャッシュされたデータを含んでいると判定することと、
   前記キャッシュされたデータを前記第１のコンテナ内での前記第１のプログラムコードの実行に与えることであって、前記第１のプログラムコードの実行が、前記キャッシュされたデータに基づいて少なくとも１つの演算処理を省略することによって、待ち時間の減少が実現する、前記与えることと、を行なうように構成されている前記システム。
9. 前記第１の仮想マシンインスタンスが、前記第１の仮想マシンインスタンス上で実行される１つ以上のコンテナによってアクセス可能な１つ以上のインスタンス固有コンピューティングリソースを有する請求項５に記載のシステム。
10. 前記ユーザ指示は、前記仮想算出システムに前記第１の要請をユーザ選択のコンテナに送らせるようにするパラメータを指定する請求項５に記載のシステム。
11. 前記仮想算出システムは、同じユーザ指示を含む入力コード実行要請を同じコンテナに送るように構成されている請求項５に記載のシステム。
12. 前記仮想算出システムはさらに、前記第１のコンテナがシャットダウンされたときに、前記第１のコンテナに関連するシャットダウンプログラムコードを自動的に実行するように構成されている請求項５に記載のシステム。
13. コンピュータ実装方法であって、
    具体的な実行可能命令で構成される１つ以上のコンピューティングデバイスによって実施されるように、
    １つ以上の物理コンピューティングデバイス上で複数の仮想マシンインスタンスを維持することであって、
    前記仮想算出システム上で第１のプログラムコードを実行する第１の要請を処理することであって、前記第１の要請は、ユーザアカウント情報と、前記第１のプログラムコードを実行するために用いるべき１つ以上のパラメータと、前記第１のプログラムコードは、前記第１のプログラムコードの事前の実行によって変更される１つ以上のコンピューティングリソースに基づいて実行すべきというユーザ指示と、を含む、前記処理することと、
    前記第１のプログラムコードは、前記第１のプログラムコードの事前の実行によって変更される１つ以上のコンピューティングリソースに基づいて実行すべきという前記ユーザ指示に基づいて、前記複数の仮想マシンインスタンスのうち、前記第１のプログラムコードの事前の実行によって変更される前記１つ以上のコンピューティングリソースに関連する第１の仮想マシンインスタンス上で、第１のコンテナを特定することと、
    前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースに基づいて、前記第１のプログラムコードを前記第１のコンテナ内で実行する、ことと、を含む前記コンピュータ実装方法。
14. 前記入力コード実行要請に関連する１つ以上の値を前記複数の仮想マシンインスタンス上で実行される特定のコンテナにマッピングするマッピングテーブルを維持することをさらに含む請求項１３に記載の方法。
15. 前記第１のコンテナに関連する前記１つ以上のコンピューティングリソースは、前記仮想算出システムと通信している外部サービスから、前記第１のプログラムコードの事前の実行と共に取り出したデータを記憶する前記第１のコンテナ内に、ローカルストレージを含む請求項１３に記載の方法。