JP7275171B2 - オンデマンドネットワークコード実行システムにおけるオペレーティングシステムカスタマイゼーション - Google Patents

Description

コンピューティングデバイスは通信ネットワークを用いてデータを交換することができる。会社および組織は、多くのコンピューティングデバイスを相互接続するコンピュータネットワークを稼働させて、業務をサポートするか、または第三者にサービスを提供する。コンピューティングシステムは、単一の地理的位置に配置することもできるし、または複数の別個の地理的位置に配置することもできる（たとえば、プライベートまたはパブリック通信ネットワークを介して相互接続されている）。具体的には、データセンタまたはデータ処理センタ（本明細書では、全般的に「データセンタ」と言う）には、多くの相互接続されたコンピューティングシステムが含まれており、データセンタのユーザにコンピューティングリソースを提供することができる。データセンタは、組織の代わりに運営されるプライベートデータセンタの場合もあるし、一般大衆の代わりにもしくは一般大衆の利益のために運営されるパブリックデータセンタの場合もある。

データセンタリソースの利用の増加を促すために、仮想化技術を用いることで、単一の物理コンピューティングデバイスが仮想マシンの１つ以上のインスタンスをホストすることができる。仮想マシンの１つ以上のインスタンスは、データセンタのユーザに対して独立したコンピューティングデバイスのように見えてそのように稼働する。仮想化によって、単一の物理コンピューティングデバイスは、仮想マシンを動的な方法で形成し、保持し、削除し、または他の方法で管理することができる。その結果、ユーザは、データセンタからコンピュータリソース（たとえば、単一のコンピューティングデバイスまたはネットワーク接続されたコンピューティングデバイスの構成）を得ることがリクエストでき、様々な数の仮想マシンリソースを受けることができる。

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

オンデマンドコード実行システムが動作して、コード（オンデマンドコード実行システムのユーザが送出してもよい）に対応するタスクを実行することができ、また仮想マシンオペレーティングシステムのカスタマイゼーションを可能にして送出されたコードの実行を容易にすることができる例示的な環境を示すブロック図である。 図１のオンデマンドコード実行システムでのタスクの実行を容易にするために用いられるＯＳのカスタマイゼーションを容易にするように構成されたＯＳカスタマイズシステムを提供するコンピューティングデバイスの一般的なアーキテクチャを示す。 図１のオンデマンドコード実行システムにタスクに対応するコードを送信し、オンデマンドコード実行システムが、オンデマンドコード実行システムでのタスクの実行を容易にするためのカスタマイズされたオペレーティングシステムを提供するための例示的な相互作用を示すフロー図である。 図１のオンデマンドコード実行システムで提供されるカスタマイズされたオペレーティングシステムを用いてタスクを実行するための例示的な相互作用を示すフロー図である。 図１のオンデマンドコード実行システムでの実行タスクの分析に基づいて、図１のオンデマンドコード実行システムのカスタマイズされたオペレーティングシステムを変更するための例示的な相互作用を示すフロー図である。 図１のオンデマンドコード実行システムでのタスクの実行を容易にするために生成または選択され得るカスタマイズされたオペレーティングシステムの例示的な可視化を示す図である。 図１のオンデマンドコード実行システムでのタスクの実行を容易にするＯＳ構成を決定するための例示的なルーチンを示すフローチャートである。

概略的に述べると、本開示の態様はオンデマンドコード実行システムに関する。オンデマンドコード実行システムによりコードの迅速な実行が可能になる。コードは、オンデマンドコード実行システムのユーザが供給してもよい。より具体的には、本開示の実施形態は、オンデマンドコード実行システムにおけるコードの迅速な実行を容易にするように仮想マシンオペレーティングシステムをカスタマイズすることに関する。本明細書で詳細に説明するように、オンデマンドコード実行システムによって、オンデマンドコード実行システムで仮想マシンインスタンスが実行すべきコンピュータ実行可能なコードをユーザが送出または指定することができるようにするネットワークアクセス可能なサービスを提供し得る。オンデマンドコード実行システムの各コードセットは、「タスク」を規定してもよく、オンデマンドコード実行システムの仮想マシンインスタンスで実行されたときに、そのタスクに対応する特定の機能を実施してもよい。オンデマンドコード実行システムのタスクの個々の実施態様をタスクの「実行」（または「タスク実行」）と言ってもよい。オンデマンドコード実行システムによってさらに、ユーザが、種々の潜在的なイベント（たとえば、ネットワークベースのストレージシステムにおいて新しいデータを検出すること、オンデマンドコード実行システムにアプリケーションプログラミングインターフェース（「ＡＰＩ」）コールを送信すること、またはオンデマンドコード実行システムに特別にフォーマットされたハイパーテキストトランスポートプロトコル（「ＨＴＴＰ」）パケットを送信すること）に基づいて、タスクの実行をトリガーすることができる。こうして、ユーザは、オンデマンドコード実行システムを用いて、任意の指定の実行可能コードを「オンデマンド」で実行することが、コードが実行される基盤となるハードウェアまたはインフラストラクチャの構成またはメンテナンスを必要とせずに可能となる。さらに、オンデマンドコード実行システムを、タスクを迅速に（たとえば、１００ミリ秒［ｍｓ］未満で）実行するように構成してもよく、その結果、実行タスクを「リアルタイム」で（たとえば、エンドユーザに対する認知できる遅延がほとんどないかまたはまったくない状態で）実行することができる。

オンデマンドコード実行システムによって仮想マシンインスタンスをインスタンス化して、指定のタスクを、オンデマンドで実行してもよい。仮想マシンインスタンスにオペレーティングシステムをプロビジョニングしてもよい。オペレーティングシステムによって、ユーザ指定の実行可能コードが実行中に必要とし得る機能が提供される。たとえば、オペレーティングシステムによって、たとえば、タスクスケジューリング、ファイルシステム管理、メモリ管理、キャッシング、プロファイリング、ネットワーキング、ハードウェアデバイスドライバなどの機能を提供し得る。ある場合には、仮想マシンインスタンスをインスタンス化して、それにオペレーティングシステムをプロビジョニングするために必要な時間は、タスクを実行するために必要な全時間と比べて著しい場合がある。

本開示を考慮すれば当業者に理解されるように、本明細書で開示した実施形態によって、オンデマンドコード実行システムなどのコンピューティングシステムが効率的にコードを実行する能力が向上する。また、本開示の実施形態は、コンピューティングシステム内での固有の技術的な問題に対処する。具体的には、コードを実行する際に用いるコンピューティングリソースの性質が限定されていること、コード実行を容易にするために仮想マシンにオペレーティングシステムをプロビジョニングすることに付随するリソースオーバーヘッド、および使用されていない機能をプロビジョニングすることによって生じる非効率性である。これらの技術的な問題に、本明細書で説明する種々の技術的解決法が対処する。たとえば、実行すべきコードによって要求される機能に基づいて、カスタマイズされたオペレーティングシステムを実行環境にプロビジョニングすることである。したがって、本開示では、全般的に、既存のデータ処理システムおよびコンピューティングシステムに対する改善を表す。

オンデマンドコード実行システムには、仮想マシンインスタンスマネージャであって、仮想マシンインスタンスのユーザ構成を必要とすることなく、ユーザコード（スレッド、プログラムなど、種々のプログラミング言語のいずれかで構成されている）を受け取って、高度に拡張可能で低遅延な方法でコードを実行するように構成されている仮想マシンインスタンスマネージャが含まれていてもよい。具体的には、仮想マシンインスタンスマネージャは、ユーザコードを受け取る前に、またユーザから何らかの特定の仮想マシンインスタンス構成に関する何らかの情報を受け取る前に、所定の構成のセットに従って仮想マシンインスタンスを生成および構成することができる。各構成は種々のランタイム環境のいずれか１つ以上に対応する。その後、仮想マシンインスタンスマネージャは、コードを実行するユーザ開始リクエストを受け取り、リクエストに付随する構成情報に基づいてコードを実行する事前構成済み仮想マシンインスタンスを特定する。仮想マシンインスタンスマネージャはさらに、特定した仮想マシンインスタンスを割り当ててユーザのコードを実行することができ、これは、少なくとも部分的に、割り当てられた仮想マシンインスタンス内にコンテナを生成および構成し、コンテナにタスクのコードならびに依存関係コードオブジェクトをプロビジョニングすることによって行うことができる。仮想マシンインスタンスマネージャを実施するための、および仮想マシンインスタンスでユーザコードを実行するための種々の実施形態が、以下の文献により詳細に説明されている。米国特許第９，３２３，５５６号、発明の名称「ＰＲＯＧＲＡＭＭＡＴＩＣ ＥＶＥＮＴ ＤＥＴＥＣＴＩＯＮ ＡＮＤ ＭＥＳＳＡＧＥ ＧＥＮＥＲＡＴＩＯＮ ＦＯＲ ＲＥＱＵＥＳＴＳ ＴＯ ＥＸＥＣＵＴＥ ＰＲＯＧＲＡＭ ＣＯＤＥ」（２０１４年９月３０日に出願）（以下、「’５５６特許」という）。この文献の全体が参照により本明細書に組み込まれている。

本明細書で用いる場合、用語「仮想マシンインスタンス」は、ソフトウェアを実行し得る環境またはプラットフォーム（「実行環境」）を提供するハードウェアをエミュレートするソフトウェアまたは他の実行可能コードの実行を指すことが意図されている。仮想マシンインスタンスは一般的に、ハードウェアデバイスによって実行される。ハードウェアデバイスは、仮想マシンインスタンスがエミュレートする物理ハードウェアとは異なる場合がある。たとえば、仮想マシンは、第２の種類のプロセッサおよびメモリで実行されている間に、第１の種類のプロセッサおよびメモリをエミュレートしてもよい。したがって、仮想マシンを用いて、第２の実行環境（たとえば、第２のオペレーティングシステム）を実行する物理デバイスで、第１の実行環境（たとえば、第１のオペレーティングシステム）を対象としたソフトウェアを実行することができる。場合によっては、仮想マシンインスタンスがエミュレートするハードウェアは、基盤となるデバイスのハードウェアと同じかまたは同様であってもよい。たとえば、第１の種類のプロセッサを伴うデバイスが、複数の仮想マシンインスタンス（それぞれが、その第１の種類のプロセッサのインスタンスをエミュレートする）を実施してもよい。したがって、仮想マシンインスタンスを用いて、デバイスを多くのロジカルサブデバイス（それぞれを「仮想マシンインスタンス」と言う）に分割することができる。仮想マシンインスタンスは一般的に、基盤となる物理デバイスのハードウェアから離れたレベルの抽象化を提供することができるが、この抽象化は必須ではない。たとえば、デバイスが複数の仮想マシンインスタンス（それぞれが、デバイスが提供するハードウェアと同一のものをエミュレートする）を実施することを想定する。このようなシナリオの下で、各仮想マシンインスタンスによって、ソフトウェアアプリケーションが、基盤となるハードウェアでコードを変換せずに実行することができ、それと同時に、他の仮想マシンインスタンスで実行されるソフトウェアアプリケーション間の論理的な分離を維持することができてもよい。このプロセス（一般的に「ネイティブ実行」と言ってもよい）を用いて、仮想マシンインスタンスの速度または性能を上げてもよい。基盤となるハードウェアの直接利用を可能にする他の技術（たとえば、ハードウェアパススルー技術）を用いてもよい。

本明細書では、実行環境の一例として、オペレーティングシステムを実行する仮想マシンについて説明しているが、他の実行環境も可能である。たとえば、タスクまたは他のプロセスをソフトウェア「コンテナ」内で実行してもよい。「コンテナ」はランタイム環境を提供するが、それ自体はハードウェアの仮想化はもたらさない。コンテナは、さらなるセキュリティを提供するために、仮想マシンの中で実施してもよいし、仮想マシンインスタンスの外で実行してもよい。

前述の態様、および本開示の付随する利点の多くは、添付の図面と関連してとらえると、以下の説明を参照することにより、同様のことがよりよく理解されるようになるため、より容易に理解されるであろう。

図１は、例示的な動作環境１００のブロック図である。動作環境１００では、オンデマンドコード実行システム１１０が、ユーザコンピューティングデバイス１０２、補助サービス１０６、およびネットワークベースのデータ記憶サービス１０８との通信に基づいて動作してもよい。例として、種々のユーザコンピューティングデバイス１０２が、図示では、オンデマンドコード実行システム１１０と通信している。ユーザコンピューティングデバイス１０２としては、デスクトップコンピュータ、ラップトップ、および携帯電話が挙げられる。一般的に、ユーザコンピューティングデバイス１０２は、たとえば、デスクトップ、ラップトップまたはタブレットコンピュータ、パーソナルコンピュータ、ウェアラブルコンピュータ、サーバ、携帯情報端末（ＰＤＡ）、ハイブリッドＰＤＡ／携帯電話、携帯電話、電子ブックリーダ、セットトップボックス、音声コマンドデバイス、カメラ、デジタルメディアプレーヤなどの任意のコンピューティングデバイスとすることができる。オンデマンドコード実行システム１１０は、ユーザコンピューティングデバイス１０２に、１つ以上のユーザインターフェース、コマンドラインインターフェース（ＣＬＩ）、アプリケーションプログラミングインターフェース（ＡＰＩ）、および／または他のプログラマチックインターフェースであって、ユーザ実行可能コード（たとえば、アップロードされたコードに対する依存関係コードオブジェクトを特定するメタデータなど）を生成およびアップロードし、ユーザ提供コードを呼び出し（たとえば、オンデマンドコード実行システム１１０でユーザコードを実行するリクエストを送出し）、イベントベースのジョブまたは時限ジョブをスケジュールし、ユーザ提供コードを追跡し、ならびに／またはそのリクエストおよび／もしくはユーザコードに関する他のログインもしくはモニタリング情報を視認するためのプログラマチックインターフェース、を提供し得る。本明細書では、１つ以上の実施形態についてユーザインターフェースを用いていると説明する場合があるが、当然のことながら、このような実施形態は、それに加えてまたはその代わりに、任意のＣＬＩ、ＡＰＩ、または他のプログラマチックインターフェースを用いてもよい。

例示的な環境１００にはさらに、１つ以上の補助サービス１０６が含まれている。補助サービス１０６は、ワンデマンドコード実行環境１１０と相互に対話して、ユーザの代わりに所望の機能を実施することができる。補助サービス１０６は、サーバなどのネットワーク接続されたコンピューティングデバイスに対応することができる。これは、ワンデマンドコード実行環境１１０がアクセス可能なデータを生成するか、または他の方法でワンデマンドコード実行環境１１０と通信する。たとえば、補助サービス１０６は、ウェブサービス（たとえば、ユーザコンピューティングデバイス１０２、オンデマンドコード実行システム１１０、または第三者と対応付けられる）、データベース、本当にシンプルなシンジケーション（「ＲＳＳ」）リーダ、ソーシャルネットワーキングサイト、またはネットワークにアクセス可能なサービスの任意の他のソースもしくはデータソース、を含み得る。場合によっては、補助サービス１０６をオンデマンドコード実行システム１１０と対応付けて、たとえば、オンデマンドコード実行システム１１０にビリングまたはロギングサービスを提供してもよい。場合によっては、補助サービス１０６は、ＡＰＩコールまたは他のタスクトリガリング情報などの情報を、オンデマンドコード実行システム１１０に能動的に送信する。場合によっては、オンデマンドコード実行システム１１０によるアクセスに対してデータが利用可能になるように、補助サービス１０６は受動的であってもよい。たとえば、オンデマンドコード実行システム１１０のコンポーネントは、このような受動的なデータソースを定期的にポーリングし、提供されたデータに基づいてオンデマンドコード実行システム１１０内でタスクの実行をトリガーしてもよい。図１では、ユーザコンピューティングデバイス１０２およびオンデマンドコード実行システム１１０とは別個であると示しているが、いくつかの実施形態では、種々の補助サービス１０６をユーザコンピューティングデバイス１０２またはオンデマンドコード実行システム１１０のいずれかが実施してもよい。

例示的な環境１００にはさらに、１つ以上のネットワークベースのデータ記憶サービス１０８（オンデマンドコード実行システム１１０が１つ以上の永続的なまたは実質的に永続的なデータソースにデータを記憶して取り出すことができるように構成されている）が含まれている。例示的に、ネットワークベースのデータ記憶サービス１０８は、オンデマンドコード実行システム１１０が、コードまたはメタデータなどのタスクに対応する情報を記憶し、タスクの依存関係を表すさらなるコードオブジェクトを記憶し、処理すべきデータをタスクの実行中に取り出し、およびその実行に関する情報（たとえば、結果）を記憶することを可能にし得る。ネットワークベースのデータ記憶サービス１０８は、たとえば、リレーショナルまたは非リレーショナルデータベースを表してもよい。別の例では、ネットワークベースのデータ記憶サービス１０８は、ネットワーク接続された記憶装置（ＮＡＳ）（ファイルシステムとして配置されたデータにアクセスするように構成されている）を表してもよい。ネットワークベースのデータ記憶サービス１０８によってさらに、オンデマンドコード実行システム１１０が、オンデマンドコード実行システム１１０内に記憶されたデータに関する情報について問い合わせて取り出すことが、たとえば、多くの関連するファイルまたはレコード、これらのファイルまたはレコードのサイズ、ファイルまたはレコードの名前、ファイルまたはレコードの作成時間などについて問い合わせることによって可能になってもよい。場合によっては、ネットワークベースのデータ記憶サービス１０８は、データを論理グループ（たとえば、個々のアカウントに対応付けられるグループなど）に分離することができる等のさらなる機能を提供してもよい。補助サービス１０６とは別個であると示しているが、ネットワークベースのデータ記憶サービス１０８は、ある場合には、補助サービス１０６の種類を表してもよい。

ユーザコンピューティングデバイス１０２、補助サービス１０６、およびネットワークベースのデータ記憶サービス１０８は、オンデマンドコード実行システム１１０とネットワーク１０４を介して通信してもよい。ネットワーク１０４としては、任意の有線ネットワーク、無線ネットワーク、またはそれらの組み合わせを挙げてもよい。たとえば、ネットワーク１０４は、パーソナルエリアネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、オーバージエアブロードキャストネットワーク（たとえば、ラジオまたはテレビジョン用）、ケーブルネットワーク、衛星ネットワーク、セルラー電話ネットワーク、またはそれらの組み合わせであってもよい。さらなる例として、ネットワーク１０４は、リンクされたネットワーク（可能性として、種々の別個の当事者が稼働させる）のうちの公衆アクセス可能なネットワーク、たとえばインターネットであってもよい。いくつかの実施形態では、ネットワーク１０４は、企業または大学のイントラネットなどのプライベートまたはセミプライベートネットワークであってもよい。ネットワーク１０４は、モバイル通信用グローバルシステム（ＧＳＭ）ネットワーク、符号分割多元接続（ＣＤＭＡ）ネットワーク、ロングタームエボリューション（ＬＴＥ）ネットワーク、または任意の他の種類の無線ネットワークなどの１つ以上の無線ネットワークを含み得る。ネットワーク１０４は、インターネットまたはその他の前述の種類のネットワークのいずれかを介して通信するためのプロトコルおよびコンポーネントを用いることができる。たとえば、ネットワーク１０４が用いるプロトコルとしては、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ＨＴＴＰセキュア（ＨＴＴＰＳ）、メッセージキューテレメトリートランスポート（ＭＱＴＴ）、制約アプリケーションプロトコル（ＣｏＡＰ）などを挙げてもよい。インターネットまたはその他の前述の種類の通信ネットワークのいずれかを介して通信するためのプロトコルおよびコンポーネントは、当業者には良く知られているので、本明細書ではこれ以上詳細には説明しない。

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

さらに、オンデマンドコード実行システム１１０は、直接ハードウェアでまたはハードウェアデバイスが実行するソフトウェアで実施してもよく、また、たとえば、本明細書で説明する種々の特徴を実施するためのコンピュータ実行可能命令を実行するように構成された物理コンピュータハードウェアで実施される１つ以上の物理または仮想サーバが含まれていてもよい。１つ以上のサーバは地理的に分散させてもよいし、または地理的に同じ場所（たとえば、１つ以上のデータセンタ）に配置してもよい。ある場合には、１つ以上のサーバは、速やかにプロビジョニングおよびリリースされるコンピューティングリソース（「クラウドコンピューティング環境」と言われることが多い）のシステムの一部として動作してもよい。

図１の例では、オンデマンドコード実行システム１１０はネットワーク１０４に接続されているとして例示している。いくつかの実施形態では、オンデマンドコード実行システム１１０内のコンポーネントのいずれかが、オンデマンドコード実行システム１１０の他のコンポーネントとネットワーク１０４を介して通信することができる。他の実施形態では、オンデマンドコード実行システム１１０のすべてのコンポーネントが仮想環境１００の他のコンポーネントと通信できるわけではない。一例では、フロントエンド１２０（ある場合には複数のフロントエンド１２０を表すことがある）のみをネットワーク１０４に接続してもよく、オンデマンドコード実行システム１１０の他のコンポーネントは環境１００の他のコンポーネントとフロントエンド１２０を介して通信してもよい。

図１において、ユーザは、ユーザコンピューティングデバイス１０２によって、オンデマンドコード実行システム１１０と相互に対話して、実行可能コードを提供し、またこのようなコードをいつどのようにオンデマンドコード実行システム１１０で実行すべきかを規定するルールまたはロジックを設定することによって、「タスク」を設定してもよい。たとえば、ユーザは、コードの一部を、ユーザが開発したウェブまたはモバイルアプリケーションとともに実行することを望む場合がある。コードを実行する１つの方法は、サービスとしてインフラストラクチャを提供するサービスプロバイダから仮想マシンインスタンスを取得し、ユーザのニーズに適合する仮想マシンインスタンスを構成し、構成済み仮想マシンインスタンスを用いてコードを実行することである。このプロセスの複雑さを回避するために、ユーザは代替的に、オンデマンドコード実行システム１１０にコードを提供して、オンデマンドコード実行システム１１０がコードを実行することをリクエストしてもよい。オンデマンドコード実行システム１１０は、コード実行リクエストに基づいてコンピューティング能力（たとえば、コンテナ、インスタンスなど。これらは以下で詳細に説明する）の取得および構成を取り扱うことができ、コンピューティング能力を用いてコードを実行することができる。オンデマンドコード実行システム１１０は、ボリュームに基づいて自動的にスケールアップおよびスケールダウンしてもよく、その結果、ユーザが過剰利用（たとえば、取得するコンピューティングリソースが少なすぎて性能問題を被る）または過少利用（たとえば、取得するコンピューティングリソースが、コードの実行に必要な量よりも多いために、余分に払う）について心配しなければならない負担から解放される。本開示の実施形態によれば、また以下に詳細に説明するように、オンデマンドコード実行システム１１０は、カスタマイズされたオペレーティングシステムを用いて仮想マシンインスタンスを構成して、ユーザのコードをより効率的に実行し、コンピューティングリソースの利用を減らしてもよい。

オンデマンドコード実行システム１１０との相互作用を可能にするために、システム１１０には１つ以上のフロントエンド１２０が含まれる。フロントエンド１２０によって、オンデマンドコード実行システム１１０との相互作用が可能になる。例示的な実施形態では、フロントエンド１２０は、オンデマンドコード実行システム１１０が提供する他のサービスに対する「フロントドア」として機能し、ユーザが（ユーザコンピューティングデバイス１０２を介して）コンピュータ実行可能コードのリクエスト実行を提供してその結果を視認することができるようにする。フロントエンド１２０には、オンデマンドコード実行システム１１０と他のコンピューティングデバイスとの間の相互作用を可能にする種々のコンポーネントが含まれる。たとえば、各フロントエンド１２０には、ユーザコンピューティングデバイス１０２が、オンデマンドコード実行システム１１０にユーザ指定コードをアップロードまたは他の方法で伝達して、その後にそのコードの実行をリクエストできるようにするリクエストインターフェースが含まれていてもよい。一実施形態では、リクエストインターフェースは、外部のコンピューティングデバイス（たとえば、ユーザコンピューティングデバイス１０２、補助サービス１０６など）と、グラフィカルユーザインターフェース（ＧＵＩ）、ＣＬＩ、またはＡＰＩを介して通信する。フロントエンド１２０は、リクエストを処理して、リクエストが適切に認証されたことを確かめる。たとえば、フロントエンド１２０は、リクエストに対応付けられるユーザが、リクエストにおいて指定されるユーザコードにアクセスすることが認証されているか否かを判定してもよい。

本明細書で用いるユーザコードに言及する場合、特定のプログラム言語で記述された任意のプログラムコード（たとえば、プログラム、ルーチン、サブルーチン、スレッドなど）を指す場合がある。本開示では、用語「コード」、「ユーザコード」、および「プログラムコード」を交換可能に用いてもよい。このようなユーザコードを実行して、特定の機能を、たとえばユーザが開発した特定のウェブアプリケーションまたはモバイルアプリケーションとともに実現してもよい。前述したように、ユーザコードの個々の集まり（たとえば、特定の機能を実現するため）を本明細書では「タスク」と言う。一方で、そのコードの特定の実行（たとえば、コードをコンパイルすること、コードをインタープリットすること、または他の方法でコードを実行可能にすることが挙げられる）を「タスク実行」または単純に「実行」と言う。タスクを、非限定的な例として、ＪａｖａＳｃｒｉｐｔ（たとえば、ｎｏｄｅ．ｊｓ）、Ｊａｖａ、Ｐｙｔｈｏｎ、および／またはＲｕｂｙ（および／または別のプログラミング言語）で書いてもよい。タスクを、オンデマンドコード実行システム１１０で種々の方法で実行するために「トリガー」してもよい。一実施形態では、ユーザまたは他のコンピューティングデバイスは、タスクを実行するリクエストを送信してもよく、これは一般的に、タスクの実行に対する「コール」と言うことができる。このようなコールには、実行すべきユーザコード（またはその場所）と、ユーザコードを実行するために用いるべき１つ以上の引数とが含まれていてもよい。たとえば、コールは、タスクのユーザコードを、タスクを実行するリクエストとともに提供してもよい。別の例では、コールは、以前にアップロードしたタスクをその名前または識別子によって特定してもよい。さらに別の例では、タスクに対応するコードを、タスクに対するコールに含めてもよく、ならびに、オンデマンドコード実行システム１１０がリクエストを受け取る前に、別個の場所（たとえば、補助サービス１０６の記憶装置またはオンデマンドコード実行システム１１０内部のストレージシステム）にアップロードしてもよい。前述したように、タスクに対するコードは、オンデマンドコード実行システム１１０において保持されるさらなるコードオブジェクトの参照を、これらのコードオブジェクトの識別子を用いることによって行って、コードオブジェクトが実行環境におけるタスクのコードと、タスクの実行前に組み合わされるようにしてもよい。オンデマンドコード実行システム１１０は、タスクに対するコールが処理されるときにタスクのコードが利用可能である場所に基づいて、タスクに対するその実行戦略を変えてもよい。フロントエンド１２０のリクエストインターフェースは、タスクを実行するコールを、ユーザからのハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）リクエストとして受け取ってもよい。また、ＨＴＴＰＳリクエストに含まれる任意の情報（たとえば、ヘッダおよびパラメータ）も処理して、タスクを実行するときに用いてもよい。前述したように、任意の他のプロトコル（たとえば、ＨＴＴＰ、ＭＱＴＴ、およびＣｏＡＰが挙げられる）を用いて、タスクコールを含むメッセージをリクエストインターフェース１２２に伝達してもよい。

タスクを実行するコールによって、タスクに対応するユーザコードと一緒に用いるべき１つ以上のサードパーティライブラリ（ネイティブライブラリを含む）を指定してもよい。一実施形態では、コールは、オンデマンドコード実行システム１１０に、ユーザコードと実行がリクエストされたタスクに対応する任意のライブラリ（および／またはその記憶場所の特定）とを含むファイルを提供してもよい。いくつかの実施形態では、コールには、メタデータであって、実行すべきタスクのプログラムコード、プログラムコードが記述された言語、コールに対応付けられるユーザ、および／またはプログラムコードを実行するために予約すべきコンピューティングリソース（たとえば、メモリなど）を示すメタデータが含まれる。たとえば、タスクのプログラムコードは、コールを用いて提供してもよいし、ユーザがあらかじめアップロードしてもよいし、オンデマンドコード実行システム１１０が提供してもよいし（たとえば、標準ルーチン）、および／または第三者が提供してもよい。例示的に、コードがコール内に含まれておらず、ユーザによってあらかじめアップロードもされていない場合、コードに対応付けられるＵＲＩを用いることによってタスクのメタデータ内で参照してもよい。いくつかの実施形態では、このようなリソースレベル制約（たとえば、特定のユーザコードを実行するためにどれくらいのメモリを割り当てるべきか）を、特定のタスクに対して指定して、タスクを実行する度に変えなくてもよい。このような場合には、オンデマンドコード実行システム１１０は、それぞれの個々のコールを受け取る前にこのようなリソースレベル制約にアクセスしてもよく、個々のコールはこのようなリソースレベル制約を指定しなくてもよい。いくつかの実施形態では、コールは、タスクを実行するためにコールがどんな種類の許可または権限を呼び出すかを示す許可データなどの他の制約を指定してもよい。このような許可データをオンデマンドコード実行システム１１０が用いて、プライベートリソース（たとえば、プライベートネットワーク上の）にアクセスしてもよい。いくつかの実施形態では、個々のコードオブジェクトを許可または認証に対応付けてもよい。たとえば、第三者がコードオブジェクトを送信して、オブジェクトをユーザのサブセットのみが読取可能であると指定してもよい。オンデマンドコード実行システム１１０には、コードオブジェクトに対するこれらの許可または認証を実行する機能が含まれていてもよい。

いくつかの実施形態では、コールは、コールを取り扱うために採用すべき動作を指定してもよい。このような実施形態では、コールには、コール内で参照されたタスクを実行する１つ以上の実行モードを可能にするためのインジケータが含まれていてもよい。たとえば、コールには、タスクをデバッグモードで実行すべきか否かを示すためのフラッグまたはヘッダが含まれていてもよい。デバッグモードでは、タスクの実行に関連して生成され得るデバッギングおよび／またはログイン出力がユーザに戻される（たとえば、コンソールユーザインターフェースを介して）。このような例では、オンデマンドコード実行システム１１０はコールを検査してフラッグまたはヘッダを探してもよく、存在する場合には、オンデマンドコード実行システム１１０は、タスクが実行されるコンテナの動作（たとえば、ロギングファシリティ）を変更して、出力データをユーザに戻してもよい。いくつかの実施形態では、オンデマンドコード実行システム１１０によってユーザに提供されたユーザインターフェースによって、動作／モードインジケータがコールに加えられる。ソースコードプロファイリング、リモートデバッギングなどの他の特徴も、コールで提供される表示に基づいて有効または無効にしてもよい。

コード実行に対するリクエストを管理するために、フロントエンド１２０に実行キュー（図１に示さず）を含めることができる。実行キューは、リクエストされたタスク実行の記録を保持することができる。例示的に、オンデマンドコード実行システム１１０による同時のタスク実行の数は限定されている。したがって、オンデマンドコード実行システム１１０において開始される新しいタスク実行（たとえば、ＡＰＩコールを介して、実行済みまたは実行中タスクからのコールを介して等）を、実行キュー１２４に配置して、たとえば、先入れ先出しの順番で処理してもよい。いくつかの実施形態では、オンデマンドコード実行システム１１０には、複数の実行キュー（たとえば、各ユーザアカウントに対する個々の実行キュー）が含まれていてもよい。たとえば、オンデマンドコード実行システム１１０のユーザは、オンデマンドコード実行システム１１０でのタスク実行のレートを限定したいと希望する場合がある（たとえば、コスト的な理由で）。したがって、オンデマンドコード実行システム１１０は、アカウント特有の実行キューを用いて、特定のユーザアカウントによる同時のタスク実行のレートを抑えてもよい。場合によっては、オンデマンドコード実行システム１１０がタスク実行に優先順位を付けて、特定のアカウントまたは指定の優先権のタスク実行が実行キュー内で回避されるかまたは優先されるようにしてもよい。他の場合では、オンデマンドコード実行システム１１０は、タスクの実行を、そのタスクに対するコールを受け取った直後または実質的に直後に行ってもよく、したがって実行キューを省略してもよい。

前述したように、ユーザコンピューティングデバイス１０２からの明示的コールに基づいて（たとえば、リクエストインターフェースにおいて受け取ったときに）、タスクをオンデマンドコード実行システム１１０において実行するようにトリガーしてもよい。その代わりにまたはそれに加えて、１つ以上の補助サービス１０６またはネットワークベースのデータ記憶サービス１０８から取り出したデータに基づいて、タスクをオンデマンドコード実行システム１１０において実行するようにトリガーしてもよい。補助サービス１０６との相互作用を容易にするために、フロントエンド１２０にはポーリングインターフェース（図１に示さず）を含めることができる。ポーリングインターフェースは、補助サービス１０６またはデータ記憶サービス１０８に、データに対してポーリングするように動作する。例示的に、ポーリングインターフェースは、１つ以上のユーザ指定の補助サービス１０６またはデータ記憶サービス１０８にリクエストを定期的に送信して、任意の新たに利用可能なデータ（たとえば、ソーシャルネットワーク「ポスト」、ニュース記事、ファイル、レコードなど）を取り出し、そのデータが、オンデマンドコード実行システム１１０上でのタスクの実行をトリガーするユーザ設定の基準に対応するか否かを判定してよい。例示的に、タスクの実行に対する基準は、これに限定するものではないが、補助サービス１０６またはデータ記憶サービス１０８において新しいデータが利用できるか否か、データの種類もしくは内容、またはデータに対応するタイミング情報を挙げてもよい。場合によっては、補助サービス１０６またはデータ記憶サービス１０８は、フロントエンド１２０に新しいデータが利用できることを通知するように機能してもよく、したがって、ポーリングサービスはこのようなサービスに対しては不要であってもよい。

補助サービス１０６からの明示的なユーザコールおよびデータに基づいて実行されるタスクに加えて、オンデマンドコード実行システム１１０は、ある場合には、タスクの実行を独立にトリガーするように動作してもよい。たとえば、オンデマンドコード実行システム１１０は、多くの指定の時間間隔ごと（たとえば、１０分ごと）にタスクの実行をトリガーするように動作してもよい（ユーザからの命令に基づいて）。

フロントエンド１２０にはさらに、オンデマンドコード実行システム１１０でのタスクの実行に関する情報を出力するように構成された出力インターフェース（図１に示さず）を含めることができる。例示的に、出力インターフェースは、タスク実行に関するデータ（たとえば、タスクの結果、タスク実行に関するエラー、またはタスク実行の詳細、たとえば、実行を終了するのに必要な合計時間、実行によって処理された合計データなど）を、ユーザコンピューティングデバイス１０２または補助サービス１０６（たとえば、ビリングサービスまたはロギングサービスが含まれていてもよい）に送信してもよい。出力インターフェースによってさらに、補助サービス１０６へのデータ送信（たとえば、サービスコール）が可能になってもよい。たとえば、出力インターフェースをタスクの実行中に用いて、ＡＰＩリクエストを外部サービス１０６に送信してもよい（たとえば、タスクの実行中に生成されたデータを記憶するため）。

いくつかの実施形態では、オンデマンドコード実行システム１１０には複数のフロントエンド１２０が含まれていてもよい。このような実施形態では、ロードバランサ（図１に示さず）を提供して、複数のフロントエンド１２０に入力コールを、たとえばラウンドロビン方式で分配してもよい。いくつかの実施形態では、ロードバランサが複数のフロントエンド１２０に入力コールを分配する方法は、オンデマンドコード実行システム１１０の他のコンポーネントの場所または状態に基づいてもよい。たとえば、ロードバランサは、地理的に近くのフロントエンド１２０にまたはコールをサービスする能力があるフロントエンドに、コールを分配してもよい。各フロントエンド１２０がオンデマンドコード実行システムの別のコンポーネント（たとえば、後述するアクティブプール１４０Ａ）の個々のインスタンスに対応する場合には、ロードバランサは、これら他のコンポーネント上の容量または負荷に従ってコールを分配してもよい。後に詳細に説明するように、コールを、ある場合には、フロントエンド１２０間に確定的に分配して、タスクを実行する所与のコールが常に（またはほとんど常に）同じフロントエンド１２０にルーティングされるようにしてもよい。これは、たとえば、タスクに対する正確な実行記録を保持するのを助けて、タスクが所望の回数だけ実行されるのを確実にしてもよい。ロードバランサを介してコールを分配することについて例示的に説明しているが、エニーキャストルーティングなどの他の分配技術も当業者には明らかである。

タスクを実行するために、オンデマンドコード実行システム１１０には１つ以上の事前構成済みＯＳライブラリ１３０が含まれており、その結果、１つ以上の事前構成済みオペレーティングシステムバリアントが含まれている。図１に例示した例では、事前構成済みＯＳライブラリ１３０には、事前構成済みＯＳ１３２（カーネル１３２Ａおよびモジュール１３２Ｂが含まれる）と、事前構成済みＯＳ１３４（カーネル１３４Ａが含まれる）とが含まれる。いくつかの実施形態では、以下に詳細に説明するように、カーネル１３２Ａおよびカーネル１３４Ａは同じであってもよく、事前構成済みＯＳ１３２と事前構成済みＯＳ１３４との違いはモジュール１３２Ｂの有無であってもよい。他の実施形態では、異なる事前構成済みＯＳ１３２および１３４は、異なるカーネル１３２Ａおよび１３４Ａを有していてもよい。たとえば、カーネル１３４Ａには、カーネル１３２Ａが実施するオペレーティングシステム機能のサブセットが含まれていてもよく、カーネル１３２Ａおよび１３４Ａはそれぞれ別個の機能を提供してもよい。他の実施形態では、事前構成済みＯＳライブラリ１３０には、事前構成済みＯＳのライブラリが含まれるのではなく、オペレーティングシステムを組み立てるためのカーネルモジュールまたは他の「ビルディングブロック」が含まれていてもよい。事前構成済みＯＳ１３２と事前構成済みＯＳ１３４とは、いくつかの実施形態では、同じオペレーティングシステムのバリアントであってもよく、ユーザレベルで提供されるかまたは組み込まれる機能（たとえば、アプリケーション、ランタイム、ユーザ選好、非ネイティブライブラリなど）とは対照的に、オペレーティングシステムレベルでカーネル１３２Ａおよび１３４Ａに組み込まれる機能（「カーネル空間機能」）の点で異なっていてもよい。

事前構成済みＯＳライブラリ１３０は、仮想マシンインスタンス（たとえば、仮想マシンインスタンス１５０および１５２）を迅速にプロビジョニングおよび構成することをサポートする。一実施形態では、特定のライブラリ１３０における事前構成済みＯＳを、同じかまたは実質的に同様の方法で事前構成してもよい。たとえば、事前構成済みＯＳは、特定のカーネルサブシステムまたはモジュールが含まれているかまたは除外されている、特定のＯＳライブラリが含まれているかまたは除外されている、特定のデバイスドライバが含まれているかまたは除外されている等の特定のオペレーティングシステムのバリアントであってもよい。別の例として、特定のライブラリ１３０における事前構成済みＯＳはすべて、特定のセットのオペレーティングシステム機能（たとえば、ファイルシステムＡＰＩまたはネットワーキングＡＰＩ）を省略してもよい。いくつかの実施形態では、事前構成済みＯＳライブラリ１３０をそれぞれ、特定のワーカーマネージャ１４０に対応付けてもよい。ワーカーマネージャ１４０は、ライブラリ１３０の事前構成済みＯＳに対応するリソースを管理してもよい。たとえば、特定のワーカーマネージャ１４０を、記憶媒体にアクセスすることなくプロビジョニングしてもよく、ファイルシステム機能をもたらさないオペレーティングシステムの事前構成済みＯＳライブラリ１３０に対応付けてもよい。

オンデマンドコード実行システム１１０にはさらに、ＯＳ構成システム１６０が含まれている。ＯＳ構成システム１６０は、本開示の態様（たとえば、特定のタスクに対して、カスタマイズされたＯＳバリアントを生成または選択することなど）を実施する。いくつかの実施形態では、ＯＳ構成システム１６０には静的ランタイムアナライザ１６２が含まれている。静的ランタイムアナライザ１６２は、ユーザがフロントエンド１２０を介してコードを送信して、送出されたコードとともに用いるべきＯＳバリアントを決定するときに呼び出してもよい。以下に詳細に説明するように、静的ランタイムアナライザ１６２はユーザのコードを分析して、たとえば、ＡＰＩコール、オペレーティングシステムコール、関数呼び出し、または実行中にコードが必要とするＯＳ機能の他の表示を特定してもよい。種々の実施形態では、静的ランタイムアナライザ１６２は、キーワード、シンボル、ヘッダ、指令、またはユーザのコードの他の態様を分析してもよい。さらなる実施形態では、オンデマンドコード実行システム１１０には動的ランタイムアナライザ１６４が含まれている。動的ランタイムアナライザ１６４は、ユーザのコードがそれを実行して、コードの実行中に実際に使用されるＯＳ機能を分析するときに呼び出してもよい。動的ランタイムアナライザ１６４は、たとえば、特定のＯＳ機能を必要とするが実行中にめったにまたは全く到達しないソースコード部分を特定してもよい。たとえば、ユーザのコードは特定のエラー状態に遭遇した場合にログファイルに書き込んでもよいが、エラーは比較的まれであってもよく（たとえば、ユーザのコードはエラー状態に遭遇することなく完了まで実行されることが多い）、他の場合にはコードは何らのファイルシステム読み出しも書き込みも行わなくてもよい。

本開示の態様によれば、ＯＳ構成システム１６０にはさらに、プロビジョニングユニット１６６が含まれている。プロビジョニングユニット１６６は、カスタマイズされたＯＳを、静的ランタイムアナライザ１６２、動的ランタイムアナライザ１６４、または両方によって特定された機能でプロビジョニングするように構成されている。具体的には、以下でより詳細に述べるように、プロビジョニングユニット１６６は、事前構成済みＯＳライブラリ１３０から事前構成済みＯＳをプロビジョニングしてもよいし、またはＯＳを選択するか、生成するか、もしくはプロビジョニングするための命令または他の構成情報を生成してもよい。構成情報を記憶して（たとえば、データ記憶サービス１０８に）、後にコード実行がリクエストされたときにワーカーマネージャ１４０が後で用いることに備えてもよい。したがって、プロビジョニングユニット１６６は、オペレーティングシステムから未使用コードを取り除いてインスタンスのオーバーヘッド要件を低減することによって、仮想マシンインスタンスをプロビジョニングする間に全体としてシステム１１０の動作を改善するように動作することができる。

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

タスクを実行するトリガー事象をフロントエンド１２０が正常に処理したら、フロントエンド１２０はワーカーマネージャ１４０にリクエストを送ってタスクを実行する。一実施形態では、各フロントエンド１２０を、対応するワーカーマネージャ１４０（たとえば、フロントエンド１２０と同じ場所に配置されているかまたは地理的に近くのワーカーマネージャ１４０）に対応付けてもよく、したがって、フロントエンド１２０はリクエストの大部分または全部をそのワーカーマネージャ１４０に送ってもよい。別の実施形態では、フロントエンド１２０には、実行リクエストを送る先のワーカーマネージャ１４０を決定するように構成されたロケーションセレクタが含まれていてもよい。一実施形態では、ロケーションセレクタは、コールを受け取るワーカーマネージャ１４０の決定を、コールをハッシングし、ハッシュした値に基づいて（たとえば、ハッシュリングを介して）選択したワーカーマネージャ１４０にコールを分配することに基づいて行ってもよい。ワーカーマネージャ１４０間でコールを分配するための他の種々のメカニズムが当業者には明らかである。本開示の実施形態によれば、ワーカーマネージャ１４０は、仮想マシンインスタンスをプロビジョニングするときにＯＳ構成および／または事前構成済みＯＳを取得することができる。

図１に示すように、インスタンスはオペレーティングシステム（ＯＳ）、言語ランタイム、およびコンテナを有していてもよい。コンテナは、ＯＳ、ランタイム、およびそこにロードされた種々のタスクに対応するユーザコードの個々のコピーを有していてもよい。図１の例では、ワーカーマネージャ１４０が管理するアクティブプール１４０Ａにはインスタンス１５０および１５２が含まれる。インスタンス１５０は、事前構成済みＯＳ１５０Ａ、ランタイム１５０Ｂおよび１５０Ｃ、ならびにコンテナ１５０Ｄおよび１５０Ｅを有している。コンテナ１５０Ｄには、ランタイム１５０Ｂのコピーとコード１５０Ｄ－１のコピーとが含まれている。コンテナ１５０Ｅには、ランタイム１５０Ｃのコピーとコード１５０Ｅ－１のコピーとが含まれている。インスタンス１５２は、事前構成済みＯＳ１５２Ａ、ランタイム１５２Ｂ、１５２Ｃ、１５２Ｅ、および１５２Ｆ、コンテナ１５２Ｄ、およびコード１５２Ｇおよび１５２Ｈを有している。コンテナ１５２Ｄは、ランタイム１５２Ｂのコピーとコード１５２Ｄ－１のコピーとを有している。図１に例示するように、インスタンスにはユーザコードがロードされていてもよく、そのインスタンス内のコンテナにもユーザコードがロードされていてもよい。いくつかの実施形態では、ランタイムもユーザ提供であってもよい。オンデマンドコード実行システムでユーザ提供のランタイムを利用することについての説明例が以下の文献に記載されている。米国特許出願第１５／８４１，１３２号、発明の名称「ＭＡＮＡＧＩＮＧ ＣＵＳＴＯＭ ＲＵＮＴＩＭＥＳ ＩＮ ＡＮ ＯＮ－ＤＥＭＡＮＤ ＣＯＤＥ ＥＸＥＣＵＴＩＯＮ ＳＹＳＴＥＭ」（２０１７年１２月１３日に出願）（以下、「’１３２出願」という）。この文献の全体が参照により本明細書に組み込まれている。いくつかの実施形態では、ワーカーマネージャ１４０は、アクティブプール１４０Ａ内にインスタンスのリストを保持してもよい。インスタンスのリストはさらに、インスタンスの構成（たとえば、ＯＳ、ランタイム、コンテナなど）を指定してもよい。いくつかの実施形態では、ワーカーマネージャ１４０は、ウォーミングプール内のインスタンスのリスト（たとえば、インスタンスの数および種類など）にアクセスしてもよい。他の実施形態では、ワーカーマネージャ１４０は、ウォーミングプール内の仮想マシンインスタンスを知ることなく、ウォーミングプールマネージャからコンピューティング能力をリクエストする。

図１に例示した例では、タスクは、コンテナと言われる隔離された実行環境（たとえば、コンテナ１５０Ｄ、１５０Ｅ、１５２Ｄ）内で実行される。コンテナは、そのインスタンスで利用可能なリソースを用いて仮想マシンインスタンス内に作成された論理ユニットである。たとえば、各ワーカーマネージャ１４０は、タスクを実行するコール内で指定された情報に基づいて、新しいコンテナを作成してもよいし、または既存のコンテナをアクティブプール１４０Ａ内のインスタンスの１つに配置して、コンテナをタスクの実行を取り扱うコールに割り当ててもよい。

本明細書では、いくつかの機能について、オンデマンドコード実行システム１１０の個々のコンポーネントを参照して概略的に述べているが、それに加えてまたはその代わりに、他のコンポーネントまたはコンポーネントの組み合わせがこのような機能を実施してもよい。たとえば、ワーカーマネージャ１４０は、事前構成済みＯＳを選択するように動作してもよいし、またはＯＳ構成システム１６０を参照して本明細書で説明したものと同様または同一の方法でＯＳを生成するように動作してもよい。

図２に、オンデマンドコード実行システム１１０内のＯＳバリアントを決定するように動作するコンピューティングシステムの一般的なアーキテクチャ（ＯＳ構成システム１６０と参照する）を示す。図２に示したＯＳ構成システム１６０の一般的なアーキテクチャには、本開示の態様を実施するために用いてもよいコンピュータハードウェアおよびソフトウェアモジュールの配置が含まれる。ハードウェアモジュールは物理的な電子デバイスを用いて実施してもよい。これについては後で詳述する。ＯＳ構成システム１６０には、図２に示したものよりも多い（または少ない）要素が含まれていてもよい。しかし、実施可能な程度の開示を提供するためにこれらの一般的に従来の要素をすべて示す必要はない。さらに、図２に例示した一般的なアーキテクチャを用いて、図１に例示した他のコンポーネントのうちの１つ以上を実施してもよい。例示するように、ＯＳ構成システム１６０には、処理ユニット２９０、ネットワークインターフェース２９２、コンピュータ可読媒体ドライブ２９４、および入出力装置インターフェース２９６が含まれている。これらはすべて、通信バスによって互いに通信してもよい。ネットワークインターフェース２９２によって、１つ以上のネットワークまたはコンピューティングシステムに接続性を提供してもよい。その結果、処理ユニット２９０は、ネットワーク１０４を介して他のコンピューティングシステムまたはサービスから情報および命令を受け取ってもよい。また処理ユニット２９０はメモリ２８０との間で通信してもよく、さらに入出力装置インターフェース２９６を介して任意的なディスプレイ（図示せず）に対する出力情報を提供してもよい。また入出力装置インターフェース２９６は任意的な入力デバイス（図示せず）から入力を受け入れてもよい。

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

ユーザインターフェースユニット２８２に加えておよび／またはそれと組み合わせて、メモリ２８０には、静的ランタイムアナライザ１６２、動的ランタイムアナライザ１６４、およびプロビジョニングユニット１６６（処理ユニット２９０が実行してもよい）が含まれていてもよい。一実施形態では、静的ランタイムアナライザ１６２、動的ランタイムアナライザ１６４、およびプロビジョニングユニット１６６は、本開示の種々の態様を別個にまたは一括して実施する。たとえば、オンデマンドコード実行システム１１０内のカスタマイズされたオペレーティングシステムバリアントを生成または選択する、コードまたはコード実行を分析して必要なＯＳ機能を決定する等である。これらについては、以下でさらに説明する。

静的ランタイムアナライザ１６２、動的ランタイムアナライザ１６４、およびプロビジョニングユニット１６６を、図２ではＯＳ構成システム１６０の一部として示しているが、他の実施形態では、静的ランタイムアナライザ１６２、動的ランタイムアナライザ１６４、およびプロビジョニングユニット１６６の全部または一部を、オンデマンドコード実行システム１１０の他のコンポーネントおよび／または別のコンピューティングデバイスが実施してもよい。たとえば、本開示のある実施形態では、オンデマンドコード実行システム１１０と通信している別のコンピューティングデバイスに、ＯＳ構成システム１６０の一部として例示したモジュールおよびコンポーネントに対して同様に動作するいくつかのモジュールまたはコンポーネントが含まれていてもよい。

いくつかの実施形態では、ＯＳ構成システム１６０にはさらに、図２に例示したもの以外のコンポーネントが含まれていてもよい。たとえば、メモリ２８０にはさらに、タスクに実行環境を割り当てるためのインスタンス割り当てユニット、実行環境内でのタスクの実行を容易にするユーザコード実行ユニット、または仮想マシンインスタンス内でのコンテナの形成、準備、および構成を管理するためのコンテナマネージャが含まれていてもよい。

図３を参照して、ＯＳバリアントを決定するための例示的な相互作用を示す。図３の相互作用は（１）から始まる。ここでは、ユーザデバイス１０２が、オンデマンドコード実行システム１１０で実行するためのタスクコードを生成してもよい。例示的に、ユーザは、コードとして、種々のシステムコールを行い、したがって、対応する機能が得られるオペレーティングシステムを必要とするコードを生成してもよい。（２）において、ユーザデバイス１０２は、フロントエンド１２０にタスクコードを、たとえばフロントエンド１２０のＡＰＩまたは他のインターフェースを用いて送出する。（３）において、フロントエンド１２０は送出されたタスクコードを検証する。検証としては、たとえば、オンデマンドコード実行システム１１０がタスクコードを実行できることを検証することを挙げることができる。

（４）において、フロントエンド１２０はＯＳ構成システム１６０に、タスクに対するＯＳバリアントを生成または選択するようリクエストを送信する。その結果、（５）においてＯＳ構成システム１６０はタスクコードを分析して、好適なＯＳバリアントを決定する。例示的に、ＯＳ構成システムの静的ランタイムアナライザ１６２は、タスクコードを書くプログラミング言語（複数可）、たとえば、Ｐｅｒｌ、Ｒｕｂｙ、Ｐｙｔｈｏｎ、ＪａｖａＳｃｒｉｐｔ、Ｊａｖａなどを特定してもよい。静的ランタイムアナライザ１６２はさらに、オペレーティングシステム機能に対応付けられる言語キーワードを特定してもよい。たとえば、静的ランタイムアナライザ１６２は、Ｊａｖａで記述されたタスクがＪａｖａ．ｉｏ．ｆｉｌｅパッケージをインポートすることを決定してもよく、したがって、ファイルシステム機能を含むＯＳを必要としてもよい。静的ランタイムアナライザ１６２はさらに、タスクコードを分析して、特定の機能に対応付けられる特定のキーワードまたは動作を特定してもよい。たとえば、静的ランタイムアナライザ１６２は以下のことを決定してもよい。すなわち、タスクコードは、ネットワーク接続されたデータストリームからのＵＤＰデータグラムの読み出しをＯＳが容易にすることを必要とするが、データストリームへの書き込みをＯＳが容易にすることも、データストリームをバッファに入れることも、ＵＤＰ以外のネットワークプロトコルも、他のネットワーキング機能も必要としないということである。

いくつかの実施形態では、ＯＳ構成システム１６０は、事前構成済みＯＳを図１の事前構成済みＯＳライブラリ１３０などのライブラリから選択することによって、タスクに対するＯＳバリアントを決定してもよい。たとえば、ＯＳ構成システム１６０は、タスクコードが必要とするＯＳ機能を特定してもよく、またこの機能を提供する１つ以上の事前構成済みＯＳを特定してもよい。いくつかの実施形態では、ＯＳ構成システム１６０は、必要な機能を提供する多くの事前構成済みＯＳの中から、リソース要件、負荷時間、応答時間などの基準または適格なＯＳを比較もしくはランク付けする他の基準に基づいて、ＯＳバリアントを選択してもよい。さらなる実施形態では、事前構成済みＯＳライブラリ１３０は、事前構成済みＯＳに関するランク付けまたは等級付けを記憶してもよく、ＯＳ構成システム１６０は、必要な機能を提供する事前構成済みＯＳを、ランク付けまたは等級付けに基づいて選択してもよい。

一例として、ＯＳ構成システム１６０は、特定のタスクに対するタスクコードが、仮想マシンインスタンスに割り当てられた物理メモリを使い果たすことなく完了まで実行できることを決定してもよい。したがって、ＯＳ構成システム１６０は、仮想マシンインスタンスのＯＳバリアントは、スワッピング、ページング、アドレストランスレーションなどのメモリ管理機能を実施する必要がないと判断することができる。なぜならば、これらの機能は仮想マシンインスタンスのライフサイクルにおいて必要でないからである。その結果、ＯＳ構成システム１６０は、事前構成済みＯＳバリアントとして、これらの機能を実施せず、タスクコードが要求する機能（たとえば、スレッディングおよびプロセス間通信に関する機能）を実施するＯＳバリアントを取得する。

いくつかの実施形態では、ＯＳ構成システム１６０は、タスクが要求する特定の機能を提供するＯＳバリアントを生成してもよい。たとえば、ＯＳ構成システムは、ローダブルカーネルモジュール、ユーザスペースプロセス、または必要な機能を提供する他のコンポーネントのセットを特定してもよく、これらの特定のコンポーネントを含むＯＳバリアントを生成してもよい。いくつかの実施形態では、ＯＳ構成システム１６０はマイクロカーネルアーキテクチャを実施または使用して、カスタムＯＳバリアントを生成してもよい。他の実施形態では、ＯＳ構成システム１６０は、前述したように、異なるモノリシックカーネルを伴う事前構成済みＯＳバリアントのライブラリを用いてもよい。

（６）において、ＯＳ構成システム１６０は、決定されたＯＳバリアント（および、いくつかの実施形態では、検証されたタスクコード）を特定する情報をデータ記憶装置１０８などの記憶装置に記憶してもよい。その結果、オンデマンドコード実行システム１１０は、タスクコードを実行するリクエストを受け取ったときにコードの分析およびＯＳバリアントの決定に費やす時間を削減できる場合がある。これについては、以下でより詳細に述べる。

いくつかの実施形態では、前述した動作の順序付けおよび実施態様を変更してもよいし、またはこれらの相互作用を、オンデマンドコード実行システム１１０の付加的または代替的な要素が行ってもよい。たとえば、一実施形態では、フロントエンド１２０が、ライブラリ１３０（またはライブラリ１３０内の利用可能なＯＳのサブセット）から事前構成済みＯＳをユーザ選択することを可能にしてもよく、またＯＳ構成システム１６０がタスクコードを分析して、タスクコードをユーザ選択のＯＳバリアントによって実行することを妨げる任意の問題点を特定および報告してもよい。さらなる例として、別の実施形態では、ＯＳ構成システム１６０は、図１のアクティブプール１４０Ａ内で、現時点で使用中のＯＳバリアントのセットの中からＯＳバリアントを特定してもよい。さらにまた、別の実施形態では、ワーカーマネージャ１４０をそれらが実行するＯＳバリアント（複数可）に従って分類してもよく、ＯＳ構成システム１６０は、タスクコードを実行してもよいワーカーマネージャ（複数可）１４０を指定することによって、ＯＳバリアントを選択してもよい。

決定されたＯＳバリアントを用いてオンデマンドコード実行システム１１０でタスクを実行するための例示的な相互作用について、図４を参照して説明する。（１）において、ユーザデバイス１０２はタスク実行をリクエストしてもよい。いくつかの実施形態では、前述したように、フロントエンド１２０は、リクエストを受け取ることなくタスク実行を開始してもよい。この場合、（１）における相互作用は省略してもよい。

（２）において、フロントエンド１２０は実行用のタスクをワーカーマネージャ１４０に分配する。タスク実行を分配する前に、フロントエンド１２０は、リクエストをキューに入れる、リクエストを検証するなどのいくつかのさらなる相互作用のいずれかを始めてもよい。これについては、’５５６特許（前述で参照により組み込まれている）の中でより詳細に説明されている。

（３）において、ワーカーマネージャ１４０は、タスクに対するＯＳバリアントを特定する情報をリクエストする。いくつかの実施形態では、前述したように、タスクのコードが検証用に送出されたとき（たとえば、図３に例示した相互作用を行うことによって）、ＯＳバリアントを決定してもよい。図５を参照して後述するように、他の実施形態では、ＯＳバリアントを以前のタスク実行の分析（複数可）に基づいて決定または更新してもよい。（４）において、ワーカーマネージャ１４０は、データ記憶装置１０８から、以前に決定したＯＳバリアントを特定する情報を受け取る。いくつかの実施形態では、ワーカーマネージャ１４０はまた、タスクに対応付けられるユーザ送出コードをリクエストして受け取ってもよい。他の実施形態では、ワーカーマネージャ１４０は、タスクが実行に対して分配されたときに、フロントエンド１２０からユーザ送出コードを受け取ってもよい。

その後、（５）において、ワーカーマネージャ１４０は、事前構成済みＯＳライブラリ１３０から、決定したＯＳバリアントに対応する事前構成済みＯＳをリクエストする。いくつかの実施形態では、前述したように、ワーカーマネージャ１４０は、その代わりに、所望のＯＳバリアントを有するそのアクティブプール内の仮想マシンインスタンスを特定してもよい。他の実施形態では、ワーカーマネージャ１４０は、カスタマイズされたＯＳの生成をリクエストしてもよいし、またはカスタマイズされたＯＳをコンポーネントまたはモジュールを組み立てることによって生成してもよい。（６）において、ワーカーマネージャ１４０はリクエストされたＯＳを受け取る。いくつかの実施形態では、ワーカーマネージャ１４０は、特定したＯＳバリアントを仮想マシンにプロビジョニングするのに十分なリソースを有していないと決定してもよいし、またはより早い段階で（たとえば、（３）における相互作用の前に）、ＯＳバリアントとは関係なくタスクを実行するのに十分なリソースを有していないと判定してもよい。たとえば、ワーカーマネージャ１４０は、データ記憶装置が含まれていないリソースのプールを管理してもよく、特定したＯＳバリアントはファイルシステム機能を提供するものであってもよい。このような実施形態では、ワーカーマネージャ１４０は、図１のプロビジョニングユニット１６６（またはオンデマンドコード実行システム１１０の別のコンポーネント）が代替的なワーカーマネージャ１４０を選択してタスクを実行することをリクエストしてもよい。他の実施形態では、ワーカーマネージャ１４０は、特定したＯＳバリアントを実行するあらかじめインスタンス化された仮想マシンをワーカーマネージャ１４０が有さないときはいつも、プロビジョニングユニット１６６が代替的なワーカーマネージャ１４０を選択してタスクを実行することを、リクエストしてもよい。このような構成は、たとえば、特定したＯＳバリアントを実行するあらかじめインスタンス化された仮想マシンによって、ワーカーマネージャ１４０が多くのまたはすべての実行をサービスすることが予想されるため、相互作用（５）および（６）に対する必要性を減らすかまたは無くしてもよい。さらに多くの実施形態において、ワーカーマネージャ１４０でＯＳバリアントを実行する仮想マシンを生成することを、プロビジョニングユニット１６６が処理してもよい。したがって、たとえば、特定したＯＳバリアントを実行するあらかじめインスタンス化された仮想マシンがワーカーマネージャ１４０には利用できないとワーカーマネージャ１４０が決定した場合、ワーカーマネージャ１４０は、ワーカーマネージャ１４０の制御下にあるホスト装置でこのような仮想マシンをプロビジョニングユニット１６６が生成することをリクエストしてもよい。

（７）において、ワーカーマネージャ１４０は、ＯＳバリアントおよびタスクコードによって仮想マシンインスタンスを構成し（および、いくつかの実施形態ではプロビジョニングし）、そしてタスクを実行する。タスクの実行には、たとえば、実行環境を配置およびプロビジョニングすることが含まれていてもよい。これについては、参照により組み込まれている’５５６特許内で、より詳細に説明されている。

いくつかの実施形態では、前述した動作の順序付けおよび実施態様を変更してもよいし、またはこれらの相互作用を、オンデマンドコード実行システムの付加的または代替的な要素が行ってもよい。たとえば、一実施形態では、フロントエンド１２０を、前述の相互作用（３）および（４）に従ってＯＳバリアントをリクエストするように構成してもよい。これらの相互作用は、たとえば、ワーカーマネージャ１４０にタスク実行が分配される前に行ってもよい。ワーカーマネージャ１４０は次に、タスク実行および対応付けられるＯＳバリアントの分配を受け取って、実行環境にタスクを実行するように指示を出す。このような命令に基づいて、環境は次に相互作用（４）および（５）を実施して、事前構成済みＯＳをライブラリ１３０から取得してもよい。その後、実行環境はタスクのコードを実行することによって、フロントエンド１２０の実行命令を遂行してもよい。タスクを実行するために環境がコードオブジェクトを特定して取り出す例示的なメカニズムについては、’１３２出願（前述で参照により組み込まれている）の中でより詳細に説明されている。

図５に、タスクコードの実行（複数可）に基づいてＯＳバリアントを決定するための例示的な相互作用を示す。（１）において、ワーカーマネージャ１４０は仮想マシンインスタンス内でタスクを実行する。いくつかの実施形態では、タスクを、標準またはデフォルトのＯＳなどの未構成のＯＳによって仮想マシンインスタンスで実行してもよい。他の実施形態では、仮想マシンインスタンスで、コードが送出されたときに決定されたＯＳバリアントによって（たとえば、図３を参照して前述したように）タスクを実行してもよく、または図５に示した相互作用を行うことによって以前に決定されたＯＳバリアントによってタスクを実行してもよい。

（２）において、ＯＳ構成システム１６０は、仮想マシンインスタンス内でのタスクの実行をモニタしてもよい。例示的に、ＯＳ構成システム１６０の動的ランタイムアナライザ１６４は、タスクの実行中に形成されたシステムコールを特定して、タスクが必要とするＯＳ機能を決定してもよい。たとえば、動的ランタイムアナライザ１６４は、タスクの実行（複数可）が、あるハードウェアデバイスドライバ、スレッディングおよびプロセススケジューリング、ならびにメモリ管理に関するＯＳ機能を呼び出したが、ネットワーキングまたはファイルシステムに関するＯＳ機能は呼び出さなかったと判定してもよい。その後、（３）において、ＯＳ構成システム１６０はＯＳバリアントを決定してもよい。前述したように、ＯＳ構成システム１６０は、タスクを実行するために必要な機能を提供する一方で、ＯＳのリソースフットプリントを最小限にするＯＳバリアントを決定してもよい。

いくつかの実施形態では、ＯＳ構成システム１６０は、タスクが特定のＯＳ機能または機能のセットを必要とする確率を決定してもよい。たとえば、ＯＳ構成システム１６０は、特定のタスクの複数の実行をモニタして、タスクは典型的にネットワーキング機能を必要としないがまれに必要とすることを判定してもよい。その結果、ＯＳ構成システム１６０は費用便益分析を行って、ＯＳ内の機能を提供した場合と提供しない場合のどちらの方がタスクの実行が効率的であるかを評価してもよい。たとえば、機能を提供することに付随するリソースコスト（たとえば、負荷時間、メモリフットプリント、待ち時間など）を決定してもよい。このリソースを、機能を提供しないことに付随するリソースコスト、ならびに機能は必要だったが提供されなかった状況から回復することに付随するリソースコストと比べてもよい。たとえば、ＯＳ構成システム１６０は、機能を提供するＯＳで構成された第２の仮想マシンインスタンスでタスクの全部または一部をリロードおよび再実行することに付随するコストを決定してもよい。いくつかの実施形態では、状態情報、部分的な結果、または他の情報をある仮想マシンインスタンスから別の仮想マシンインスタンスへ伝達して、ＯＳ機能は必要だったが提供されなかった状況からの回復を促進してもよい。さらなる実施形態では、ＯＳ構成システム１６０は、特定した機能を提供しないＯＳバリアントと特定した機能を提供する「フォールバック」ＯＳバリアントとを決定してもよく、また欠けている機能が必要となった場合に回復を促進するための命令を記憶してもよい。さらに他の実施形態では、ＯＳ構成システム１６０は、デフォルトのフル機能ＯＳで構成された仮想マシンインスタンスでタスク全体を再実行する方が、カスタマイズされたＯＳバリアントによって仮想マシンインスタンスでタスクを実行する試みの全部または一部を救い出すことを試みるよりも、速い（または他の場合には、効率的である）と判定してもよい。

（４）において、ＯＳ構成システム１６０は、決定されたＯＳバリアント（複数可）をデータストア（たとえば、データ記憶サービス１０８）に記憶してもよい。いくつかの実施形態では、ＯＳ構成システム１６０は、タスクのＯＳ要件の動的分析（たとえば、実行タスク上で行われる分析）が、以前に行った静的分析（たとえば、送出されたタスクコード上で行われた分析）と一致しているか否かを判定してもよく、それに応じて、静的分析に対するそのパラメータを更新してもよい。たとえば、ＯＳ構成システム１６０は、タスクコードの特定の要素（たとえば、特定のモジュールをインポートする指令）と、あるＯＳ機能を必要とすることとの間の関係を決定してもよく、さらなら静的分析を行うときにこの関係を考慮に入れてもよい。いくつかの実施形態では、ＯＳ構成システム１６０は、モジュールまたは他のコンポーネントからＯＳバリアントを構築するための「レシピ」または他の命令を記憶してもよい。他の実施形態では、ＯＳ構成システム１６０は、事前構成済みＯＳを特定する情報、タスクコードが要求するＯＳ機能に関する情報、または他の情報であって、ワーカーマネージャ１４０が、インスタンスが実行するタスクコードに対してカスタマイズされたＯＳを仮想マシンインスタンスにプロビジョニングおよび構成することができるようにする情報を記憶してもよい。

事前構成済みオペレーティングシステムの例示的な可視化を図６に示す。例示的な可視化には、事前構成済みＯＳ１３２、１３４、および１３６が含まれ、オペレーティングシステムが提供する種々の機能は、機能ブロックまたはモジュールとして表している。種々の実施形態では、これらのブロックは、ＯＳカーネルのモジュールもしくは要素、ユーザスペースプロセスもしくはサブシステム、ライブラリ、ドライバ、またはオペレーティングシステムの他の要素であって互いに機能的に分離することができるものを表してもよい。

図６に示す可視化において、事前構成済みＯＳ１３２はフルセットＯＳ機能を含む「フル」オペレーティングシステムである。事前構成済みＯＳ１３２は、たとえば、一般的に利用可能なＯＳ（たとえば、標準リナックスディストロ）に対応してもよい。いくつかの実施形態では、事前構成済みＯＳ１３２は、カスタムＯＳとして、オンデマンドコード実行システムがサポートする機能のすべてを実施するが、一般的に、オペレーティングシステムがサポートする機能のすべては実施しないカスタムＯＳに対応してもよい。たとえば、オンデマンドコード実行システムは、単純化されたファイルシステム（たとえば、ディレクトリを伴わない「フラット」ファイルシステム）のみをサポートしてもよく、事前構成済みＯＳ１３２は、ファイルシステム関連のシステムコールのサブセットのみを実施してもよい。例示した実施形態では、事前構成済みＯＳ１３２には、スケジューラ６３２Ａ、メモリ管理サブシステム６３２Ｂ、ファイルシステム管理サブシステム６３２Ｃ、ネットワーキングサブシステム６３２Ｄ、およびハードウェアデバイスドライバ６３２Ｅが含まれている。当業者であれば分かるように、コンポーネント６３２Ａ～Ｅのリストは例を目的として示しており、本開示には、オペレーティングシステムのコンポーネントが図６に示したものと比べて多い、少ない、または異なる実施形態も含まれる。たとえば、事前構成済みＯＳ１３２には、ファイルシステムに読み出しおよびファイルシステムに書き込むための別個のモジュール、または異なるネットワークプロトコル（たとえば、ＴＣＰ／ＩＰネットワーキングモジュールおよびＵＤＰネットワーキングモジュール）に対する異なるネットワーキングサブシステムが含まれていてもよい。

事前構成済みＯＳ１３４は、事前構成済みＯＳ１３２が提供する機能のサブセットを実施するバリアントであり、スケジューラ６３４Ａ、メモリ管理サブシステム６３４Ｂ、およびネットワーキングサブシステム６３４Ｄが含まれる。事前構成済みＯＳ１３４には、ファイルシステム管理またはハードウェアデバイスドライバに関する機能は含まれておらず、そのため、これらの機能を必要としないタスクに対してのみ好適であり得る。いくつかの実施形態では、スケジューラ６３４Ａは、スケジューラ６３２Ａと同じ機能を提供してもよい（またはスケジューラ６３２Ａと同一であってもよい）し、または異なる機能を提供してもよい。事前構成済みＯＳ１３６にはさらに、スケジューラ６３６Ａのみを提供する最小のＯＳバリアントが例示されており、図６に示す他の機能のどれも含まれていない。一実施形態では、事前構成済みＯＳライブラリ（たとえば、図１の事前構成済みＯＳライブラリ１３０）には、事前構成済みＯＳ１３２、１３４、および１３６上での数十または数百の他の変形が含まれていてもよい（たとえば、スケジューラがもたらされていない変形）。別の実施形態では、ライブラリ内の事前構成済みＯＳはすべて、タスクスケジューリングなどのある「コア」ＯＳ機能を実施してもよく、他の機能については異なっていてもよい。さらなる実施形態では、事前構成済みＯＳは、図６に示すサブシステムまたはモジュールのうちの１つ内で実施される機能については異なっていてもよい。たとえば、事前構成済みＯＳは、ハードウェアデバイスドライバが別の事前構成済みＯＳの場合と比べて少なくても、多くても、もしくは異なっていてもよいし、または読み取り専用ネットワーキングを実施してもよい。

いくつかの実施形態では、前述したように、図１のＯＳ構成システム１６０（またはオンデマンドコード実行システム１１０の別のコンポーネント）は、ＯＳ１３４などの事前構成済みＯＳを選択するのではなく、個々のモジュールまたは要素からＯＳバリアントを構築してもよい。たとえば、ＯＳ構成システム１６０は、特定のタスクが、タスクスケジューリング、メモリ管理、およびネットワーキングなどのＯＳ機能を必要とすることを決定してもよく、したがって、個々のコンポーネント、たとえば、スケジューラ６３２Ａ、メモリ管理サブシステム６３２Ｂ、ネットワーキングサブシステム６３２Ｄ、および他のこのようなコンポーネントから、ＯＳを組み立ててもよい。さらなる実施形態では、ＯＳ構成システム１６０は、最小機能を含むベースＯＳから始めてもよく、そしてタスクが必要とする場合がある特定の機能を加えてもよい。他の実施形態では、ＯＳ構成システム１６０は、フル機能ＯＳから始めてもよく、タスクが必要としない場合がある機能を取り除いてもよい。

図７を参照して、オンデマンドコード実行システム１１０でタスクを実行するためのＯＳバリアントを決定するための１つの例示的なルーチン７００について説明する。ルーチン７００は、たとえば、図１のＯＳ構成システム１６０が行ってもよい。一実施形態では、ルーチン７００の全部または一部（たとえば、ブロック７０２～７０６）を、オンデマンドコード実行システム１１０上のタスクを形成することとともに行う。別の実施形態では、ルーチン７００の全部または一部（たとえば、ブロック７０６～７１６）を、オンデマンドコード実行システム１１０でタスクを実行することとともに行ってもよい。それに加えてまたはその代わりに、ルーチン７００の全部または一部を、他のときに、たとえば、定期的に（たとえば、日、週、月に１回など）または実行メトリクスもしくはリソース利用メトリクスが閾値から外れたことを検出したことに基づいて行ってもよい。

ルーチン７００はブロック７０２から開始する。ここでは、ＯＳ構成システム１６０がタスクに対するコード（たとえば、ユーザが送出したもの）を取得する。一実施形態では、タスクに対するコードをコードオブジェクト（たとえば、タスクに対するソースコードを含む圧縮ファイル）として表す。次にルーチン７００はブロック７０４および７０６へと続き、ＯＳ構成システム１６０が、タスクに対するＯＳバリアントを決定する（図７ではブロック集まり７２０として示す）。

ブロック７０４において、ＯＳ構成システム１６０は、取得したタスクコードを分析して、コード実行中に必要とされ得るＯＳ機能を特定する。例示的に、ＯＳ構成システム１６０は、システムコール、ＡＰＩコール、ライブラリ、プログラミング言語機能、または特定のＯＳ機能が必要とし得る他の表示（すでにより詳細に説明している）を特定してもよい。いくつかの実施形態では、ＯＳ構成システム１６０は、取得したタスクコードをオンデマンドコード実行システム１１０が実行する他のタスクコードと比べてもよく、必要なＯＳ機能を特定する類似性または共通の特徴を特定してもよい。他の実施形態では、ＯＳ構成システム１６０は、取得したタスクコードの以前の実行を特定して、これらの実行中に必要なＯＳ機能を決定してもよい。種々の実施形態では、ＯＳ機能を、特定のセットの機能（たとえば、ネットワーキング機能）として、特定のＡＰＩもしくはサブシステムとして、または個々の機能もしくはシステムコールとして特定してもよい。

ブロック７０６において、ＯＳ構成システム１６０は、ブロック７０４で特定した機能を含む事前構成済みＯＳを特定する。いくつかの実施形態では、前述したように、ＯＳ構成システム１６０は、特定した機能を含む複数の事前構成済みＯＳを特定してもよく、また種々の基準（事前構成済みＯＳの負荷時間、実行速度、等級付け、またはランク付けなど）を適用して、どの事前構成済みＯＳを選択するかを決定してもよい。他の実施形態では、ＯＳ構成システム１６０は、上記でより詳細に説明したように、必要な機能を伴うＯＳを生成または組み立ててもよい。いくつかの実施形態では、ＯＳ構成システム１６０は、特定したＯＳ構成およびタスクコードをデータストアに記憶して、後で用いることに備えてもよく、またブロック７０６の後のルーチン７００の部分を、タスクコードを実行したときに別個のルーチンとして呼び出してもよい。

ブロック７０８において、フロントエンド１２０（またはオンデマンドコード実行システム１１０の別の要素）が、タスクコードを実行するリクエストを受け取る。一実施形態では、オンデマンドコード実行システム１１０は、リクエストなしでタスクコードを実行してもよい。たとえば、オンデマンドコード実行システム１１０は、前述したように、定期的にタスクコードを実行してもよいし、またはある基準が満足されたときにタスクコードを実行してもよい。

ブロック７１０において、ワーカーマネージャ１４０または別のコンポーネントは、特定した事前構成済みＯＳおよびタスクコードを仮想マシンインスタンスにプロビジョニングする。種々の実施形態では、ワーカーマネージャ１４０は、事前構成済みＯＳがすでにプロビジョニングされた既存の仮想マシンインスタンス（たとえば、ウォーミングプールまたは他のスタンドバイモード内の仮想マシンインスタンスなど。’５５６特許（前述で参照により組み込まれている）で説明されている）を選択してもよいし、コンポーネントからカスタムＯＳを構築してもよいし、または他の場合には、タスクコードが必要とし得る機能を提供するＯＳバリアントを仮想マシンにプロビジョニングしてもよい。他の実施形態では、ワーカーマネージャ１４０を特定のＯＳバリアント（複数可）またはバリアントに対応付けてもよく、フロントエンド１２０または別のコンポーネントが、そのワーカーマネージャ１４０がサポートするＯＳバリアント（複数可）に基づいて、特定のワーカーマネージャ１４０を選択してもよい。

ブロック７１２において、ワーカーマネージャ１４０はタスクコードを実行する。ブロック７１４において、ＯＳ構成システム１６０は、タスクコードの実行を分析して、実行中に必要となるＯＳ機能を特定してもよい。ＯＳ構成システム１６０は、たとえば、ログファイル、ネットワークアクティビティ、ファイルシステムアクティビティ、またはタスクコードの実行中に生成もしくは収集した他の情報を分析してもよい。ブロック７１４における分析はブロック７０４で行う分析と同様の目的であるが、コードを分析してそれがどの機能を呼び出し得るかを決定するではなく、実行中に実際に呼び出される機能を分析する。したがって、ブロック７１４における分析は、特定のＯＳ機能を必要とするが、実行中にめったに呼び出されないか、または全く呼び出されないタスクコード部分を特定してもよい。たとえば、ＯＳが特定のデバイスドライバを提供することを、コード中のサブルーチンが要求してもよいが、コードはブロック７１２における実行中にサブルーチンに到達しなくてもよい。いくつかの実施形態では、ＯＳ構成システム１６０は、前述したように、タスクコードのいくつかの実行を分析して、実行中に特定のＯＳ機能が必要とされる確率を決定してもよい。

判定ブロック７１６において、ＯＳ構成システム１６０は、タスクコードが要求する機能と特定したＯＳバリアントが提供する機能との間に不一致があるか否かを判定してもよい。当然のことながら、不一致は両方向であってもよい。たとえば、ＯＳ構成システム１６０は、特定したＯＳバリアントはタスクの実行に必要なものよりも多い機能を提供すると判定してもよく、その結果、異なるＯＳバリアントを特定することによってさらなる効率向上を実現してもよい。代替的に、ＯＳ構成システム１６０は、特定したＯＳバリアントが必要な機能をすべて提供するわけではないと判定してもよい。たとえば、ＯＳ構成システム１６０は、ワーカーマネージャ１４０が、最初に特定したものとは異なるＯＳバリアントによりタスクコードの実行を再開しなければならなかったと判定してもよい。いくつかの実施形態では、ＯＳバリアントは、ワーカーマネージャ１４０にこの状況を修正させるために必要な機能が欠けているという「カーネルパニック」または他の表示を生成してもよい。判定ブロック７１６における判定が、異なるＯＳバリアントが必要であるというものならば、ルーチン７００は分岐してブロック７０６へ行き、新しいＯＳバリアントを特定する。そうでない場合は、ルーチン７００は分岐してブロック７０８へ行き、タスクコードを実行する次のリクエストを待ち、これは最新のＯＳバリアントによって実現される。

本開示の実施形態では、前述したルーチンのブロックは変わってもよい。たとえば、いずれかのルーチンのいくつかの実施態様において、ＯＳ構成システム１６０を、さらなるＯＳバリアントを生成および記憶することなどのさらなる機能を実施するように構成してもよい。したがって、種々の実施形態により、ルーチンにはさらなるブロックが含まれていてもよいし、またはルーチンのブロックを並べ替えてもよい。

前述した本方法およびプロセスはすべて、１つ以上のコンピュータまたはプロセッサが実行するソフトウェアコードモジュールによって具体化してもよく、また完全に自動化してもよい。コードモジュールを、任意の種類の非一時的コンピュータ可読媒体または他のコンピュータ記憶装置に記憶してもよい。代替的に、本方法の一部または全部を専用のコンピュータハードウェアで具体化してもよい。

条件付き言語、たとえば、とりわけ、「できる（ｃａｎ）」、「できる（ｃｏｕｌｄ）」、「してもよい（ｍｉｇｈｔ）」、または「してもよい（ｍａｙ）」は、特に記載のない限り、一般的に用いられる場合と同様に、本来、文脈内で理解され、ある実施形態には、ある特徴、要素、および／またはステップが含まれるが、他の実施形態には含まれていない、ということを示している。したがって、このような条件付き言語は一般的に、特徴、要素、および／もしくはステップが多少なりとも１つ以上の実施形態にとって必要であるということ、または１つ以上の実施形態には必ず、ロジックとして、ユーザ入力またはプロンプティングがあってもなくても、これらの特徴、要素、および／もしくはステップが何らかの特定の実施形態に含まれているかもしくはそこで行うべきかを決定するロジックが含まれるということを意味するものではないことが意図されている。

離接的な言葉、たとえば語句「Ｘ、Ｙ、またはＺのうちの少なくとも１つ」は、特に記載のない限り、一般的に用いられる場合と同様に、本来、文脈を用いて理解され、事項、用語などは、Ｘ、Ｙ、もしくはＺ、またはそれらの任意の組み合わせ（たとえば、Ｘ、Ｙ、および／またはＺ）であり得るということを示している。したがって、このような離接的な言葉は一般的に、ある実施形態ではＸのうちの少なくとも１つ、Ｙのうちの少なくとも１つ、またはＺのうちの少なくとも１つがそれぞれ存在する必要があるということを意味することは意図しておらず、また意味すべきではない。

特に明記しない限り、「ａ」または「ａｎ」などの冠詞は一般的に、記載事項を１つ以上含むと解釈すべきである。したがって、「構成されたデバイス」などの語句は、説明したデバイスを１つ以上含むことが意図されている。このような１つ以上の説明したデバイスを、述べた説明を実施するように一括して構成することができる。たとえば、「説明Ａ、Ｂ、およびＣを行うように構成されたプロセッサ」には、説明Ａを行うように構成された第１のプロセッサが、説明ＢおよびＣを行うように構成された第２のプロセッサとともに動作することを含めることができる。

本明細書で説明したおよび／または添付図に示したフロー図における任意のルーチン記載、要素、またはブロックは、１つ以上のルーチン内の特定の論理機能または要素を実施するための実行可能命令が含まれるモジュール、セグメント、またはコード部分を潜在的に表すと理解すべきである。本明細書で説明する実施形態の範囲には、代替的な実施態様が含まれ、すなわち、当業者であれば理解されるように、含まれる機能に応じて、要素もしくは機能が削除される場合があり、または図示もしくは説明したもの（たとえば、実質的に同期してもしくは逆の順序で）から順序が外れて実行される場合がある。

前述の実施形態に対して多くの変形および変更を行ってもよく、その要素は他の許容できる例の中にあると理解すべきであることを、強調しておかなければならない。このような変更および変化はすべて、本明細書では、本開示の範囲に含まれ、以下の特許請求の範囲によって保護されることが意図されている。

本開示の実施形態の例は、以下の条項に鑑みて説明することができる。

条項１．
システムであって、
複数のオペレーティングシステム（「ＯＳ」）バリアントを記憶する物理データストアであって、前記複数のＯＳバリアントの個々のＯＳバリアントは、対応するＯＳ機能の組を提供する、前記物理データストアと、
コンピューティングデバイスであって、前記コンピューティングデバイスは実行可能命令によって、
オンデマンドコード実行システムで実行可能なユーザ送出コードを受け取ることと、
前記オンデマンドコード実行システムで実行されたときに前記ユーザ送出コードが呼び出すことが予想される第１の組のＯＳ機能を決定することと、
前記複数のＯＳバリアントのうちの第１のＯＳバリアントを特定することであって、第１のＯＳ構成は少なくとも前記第１の組のＯＳ機能を提供する、前記特定することと、
前記ユーザ送出コードの実行をリクエストすることに応じて、前記第１のＯＳバリアントと前記ユーザ送出コードとを仮想マシンインスタンスにプロビジョニングすることと、
を行うように構成された、前記コンピューティングデバイスと、
を含む、前記システム。

条項２．
前記コンピューティングデバイスはさらに、前記ユーザ送出コード内の１つ以上のシステムコールを特定するように構成され、
前記第１の組のＯＳ機能は、少なくとも部分的に前記１つ以上のシステムコールに基づいて決定される、条項１に記載のシステム。

条項３．
前記第１の組のＯＳ機能には、ページング機能、キャッシング機能、ファイルシステム機能、ネットワーキング機能、スレッディング機能、プロファイリング機能、スケジューリング機能、１つ以上のネットワーキングプロトコル実施態様、または１つ以上のハードウェアデバイスドライバのうちの１つ以上が含まれる、条項１に記載のシステム。

条項４．
前記コンピューティングデバイスはさらに、
前記複数のＯＳバリアントのうちの第２のＯＳバリアントを特定することであって、前記第２のＯＳバリアントは少なくとも前記第１の組のＯＳ機能を提供する、前記特定することと、
前記第１のＯＳバリアントは、前記第２のＯＳバリアントよりも第１のコンピューティングリソースの使用量が少ないことを判定することと、
を行うように構成されている、条項１に記載のシステム。

条項５．
前記第１のコンピューティングリソースには、処理時間、プロセッサ容量、バンド幅、メモリ、ストレージ、または待ち時間のうちの１つ以上が含まれる、条項４に記載のシステム。

条項６．
コンピュータ実装方法であって、
オンデマンドコード実行システムで実行可能なユーザ送出コードを受け取ることと、
少なくとも部分的に前記ユーザ送出コードに基づいて、前記オンデマンドコード実行システムで前記ユーザ送出コードを実行することに対応付けられる第１の組のＯＳ機能を決定することと、
少なくとも部分的に前記第１の組のＯＳ機能に基づいて、複数のＯＳバリアントのうちの第１のＯＳバリアントを特定することと、
前記ユーザ送出コードの実行をリクエストすることに応じて、第１の仮想マシンインスタンスで前記ユーザ送出コードを実行することであって、前記第１の仮想マシンインスタンスは前記第１のＯＳバリアントを有する、前記実行することと、
を含む、前記コンピュータ実装方法。

条項７．
前記第１の仮想マシンインスタンスに前記第１のＯＳバリアントをプロビジョニングすることをさらに含む、条項６に記載のコンピュータ実装方法。

条項８．
複数の事前構成済み仮想マシンインスタンスから前記第１のＯＳバリアントを有する前記第１の仮想マシンインスタンスを選択することをさらに含む、条項６に記載のコンピュータ実装方法。

条項９．
前記第１のＯＳバリアントを特定することは、少なくとも部分的に前記ユーザ送出コードの１つ以上の以前の実行に基づく、条項６に記載のコンピュータ実装方法。

条項１０．
前記ユーザ送出コードの一部は、前記第１のＯＳバリアントが提供しない少なくとも１つの機能を必要とする、条項６に記載のコンピュータ実装方法。

条項１１．
少なくとも部分的に前記ユーザ送出コードの１つ以上の以前の実行に基づいて、前記少なくとも１つの機能を必要とする前記ユーザ送出コードの前記一部が実行される確率を決定することをさらに含む、条項１０に記載のコンピュータ実装方法。

条項１２．
さらに、
前記第１のＯＳバリアントに対応付けられる第１のリソースを取得することと、
第２のＯＳバリアントに対応付けられる第２のリソースを取得することであって、前記第２のＯＳバリアントは前記少なくとも１つの機能を提供する、前記取得することと、を含み、
前記第１のＯＳバリアントを特定することは、少なくとも部分的に、前記第１のリソースと、前記第２のリソースと、前記少なくとも１つの機能を必要とする前記ユーザ送出コードの前記一部が実行される前記確率とに基づく、条項１１に記載のコンピュータ実装方法。

条項１３．
さらに、
前記第１の仮想マシンインスタンスで前記ユーザ送出コードを実行する間に、前記少なくとも１つの機能を必要とする前記ユーザ送出コードの前記実行を決定することと、
第２のＯＳバリアントを有する第２の仮想マシンインスタンスで前記ユーザ送出コードを実行することであって、前記第２のＯＳバリアントは前記少なくとも１つの機能を提供する、前記実行することと、
を含む、条項１０に記載のコンピュータ実装方法。

条項１４．
前記第２のＯＳバリアントはデフォルトのＯＳバリアントに対応する、条項１３に記載のコンピュータ実装方法。

条項１５．
さらに前記第１の仮想マシンインスタンスから前記第２の仮想マシンインスタンスに状態情報を伝達することを含む、条項１３に記載のコンピュータ実装方法。

条項１６．
コンピュータ実行可能命令を含む非一時的なコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、オンデマンドコード実行システムで実行されると、前記オンデマンドコード実行システムに、
オンデマンドコード実行システムで実行可能なユーザ送出コードを取得することと、
少なくとも部分的に前記ユーザ送出コードに基づいて、前記ユーザ送出コードを実行することに対応付けられる第１の組のＯＳ機能を決定することと、
少なくとも部分的に前記第１の組のＯＳ機能に基づいて、第１のＯＳバリアントを決定することと、
前記ユーザ送出コードを実行するリクエストに応じて、前記第１のＯＳバリアントを有する第１の仮想マシンインスタンスで前記ユーザ送出コードを実行することと、
を行わせる、前記非一時的なコンピュータ可読媒体。

条項１７．
前記命令はさらに、前記オンデマンドコード実行システムに、前記第１のＯＳバリアントを生成することを行わせる、条項１６に記載の非一時的なコンピュータ可読媒体。

条項１８．
前記命令はさらに、前記オンデマンドコード実行システムに、前記第１のＯＳバリアントを生成することを行わせる、条項１７に記載の非一時的なコンピュータ可読媒体。

条項１９．
前記第１のＯＳバリアントは複数の所定のＯＳ構成から選択される、条項１６に記載の非一時的なコンピュータ可読媒体。

条項２０．
前記命令はさらに、前記オンデマンドコード実行システムに、前記ユーザ送出コードを実行する第２のリクエストに応じて、前記第１のＯＳバリアントを有する第２の仮想マシンで前記ユーザ送出コードを実行することを行わせる、条項１６に記載の非一時的なコンピュータ可読媒体。

Claims (14)

1. 複数のＯＳバリアントを記憶する物理データストアであって、前記複数のＯＳバリアントの個々のＯＳバリアントは、対応するＯＳ機能の組を提供する物理データストアと、
   コンピューティングデバイスと、
   を含むシステムであって、
   前記コンピューティングデバイスは、実行可能命令によって、
   オンデマンドコード実行システムで実行可能なユーザ送出コードを受け取ることと、
   前記ユーザ送出コードに基づいて、前記オンデマンドコード実行システムで前記ユーザ送出コードを実行することに対応付けられる第１の組のＯＳ機能を決定することと、
   前記第１の組のＯＳ機能に基づいて、前記複数のＯＳバリアントのうちの第１のＯＳバリアントを特定することと、
   前記ユーザ送出コードの実行をリクエストすることに応じて、前記第１のＯＳバリアントと前記ユーザ送出コードとを仮想マシンインスタンスにプロビジョニングすることと、
   を行うように構成されている、
   システム。
2. 前記コンピューティングデバイスは、さらに、前記ユーザ送出コード内の１つ以上のシステムコールを特定するように構成され、
   前記第１の組のＯＳ機能は、前記１つ以上のシステムコールに基づいて決定される、
   請求項１に記載のシステム。
3. 前記第１の組のＯＳ機能には、ページング機能、キャッシング機能、ファイルシステム機能、ネットワーキング機能、スレッディング機能、プロファイリング機能、スケジューリング機能、１つ以上のネットワーキングプロトコル実施態様、または、１つ以上のハードウェアデバイスドライバのうちの１つ以上が含まれる、
   請求項１に記載のシステム。
4. 前記コンピューティングデバイスは、さらに、
   前記複数のＯＳバリアントのうちの第２のＯＳバリアントを特定することであって、前記第２のＯＳバリアントは少なくとも前記第１の組のＯＳ機能を提供することと、
   前記第１のＯＳバリアントが前記第２のＯＳバリアントよりも第１のコンピューティングリソースの使用量が少ないことを決定することと、
   を行うように構成されている、
   請求項１に記載のシステム。
5. コンピュータ実装方法であって、
   オンデマンドコード実行システムで実行可能なユーザ送出コードを受け取ることと、
   前記ユーザ送出コードに基づいて、前記オンデマンドコード実行システムで前記ユーザ送出コードを実行することに対応付けられる第１の組のＯＳ機能を決定することと、
   前記第１の組のＯＳ機能に基づいて、複数のＯＳバリアントのうちの第１のＯＳバリアントを特定することと、
   前記ユーザ送出コードの実行をリクエストすることに応じて、第１の仮想マシンインスタンスで前記ユーザ送出コードを実行することであって、前記第１の仮想マシンインスタンスは、前記第１のＯＳバリアントを有することと、
   を含むコンピュータ実装方法。
6. 前記コンピュータ実装方法は、複数の事前構成済み仮想マシンインスタンスから前記第１のＯＳバリアントを有する前記第１の仮想マシンインスタンスを選択することをさらに含む、
   請求項５に記載のコンピュータ実装方法。
7. 前記ユーザ送出コードの一部は、前記第１のＯＳバリアントが提供しない少なくとも１つの機能を必要とする、
   請求項５に記載のコンピュータ実装方法。
8. 前記コンピュータ実装方法は、
   前記ユーザ送出コードの１つ以上の以前の実行に基づいて、前記少なくとも１つの機能を必要とする前記ユーザ送出コードの前記一部が実行される確率を決定することと、
   前記第１のＯＳバリアントに対応付けられる第１のリソースコストを取得することと、
   第２のＯＳバリアントに対応付けられる第２のリソースコストを取得することであって、前記第２のＯＳバリアントは、前記少なくとも１つの機能を提供することと、
   をさらに含み、
   前記第１のＯＳバリアントを特定することは、前記第１のリソースコストと、前記第２のリソースコストと、前記少なくとも１つの機能を必要とする前記ユーザ送出コードの前記一部が実行される前記確率と、に基づく、
   請求項７に記載のコンピュータ実装方法。
9. 前記コンピュータ実装方法は、さらに、
   前記第１の仮想マシンインスタンスで前記ユーザ送出コードを実行する間に、前記少なくとも１つの機能を必要とする前記ユーザ送出コードの前記実行を決定することと、
   第２のＯＳバリアントを有する第２の仮想マシンインスタンスで前記ユーザ送出コードを実行することであって、前記第２のＯＳバリアントは、前記少なくとも１つの機能を提供することと、
   を含む、
   請求項７に記載のコンピュータ実装方法。
10. 前記コンピュータ実装方法は、さらに、前記第１の仮想マシンインスタンスから前記第２の仮想マシンインスタンスに状態情報を伝達することを含む、
    請求項９に記載のコンピュータ実装方法。
11. コンピュータ実行可能命令を含む非一時的なコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、オンデマンドコード実行システムで実行されると、前記オンデマンドコード実行システムに、
    オンデマンドコード実行システムで実行可能なユーザ送出コードを取得することと、
    前記ユーザ送出コードに基づいて、前記ユーザ送出コードを実行することに対応付けられる第１の組のＯＳ機能を決定することと、
    前記第１の組のＯＳ機能に基づいて、第１のＯＳバリアントを決定することと、
    前記ユーザ送出コードを実行するリクエストに応じて、前記第１のＯＳバリアントを有する第１の仮想マシンインスタンスで前記ユーザ送出コードを実行することと、
    を行わせる非一時的なコンピュータ可読媒体。
12. 前記命令は、さらに、前記オンデマンドコード実行システムに、前記第１のＯＳバリアントを生成することを行わせる、
    請求項１１に記載の非一時的なコンピュータ可読媒体。
13. 前記第１のＯＳバリアントは、マイクロカーネルおよび１つ以上のシステムプロセスを含む、
    請求項１２に記載の非一時的なコンピュータ可読媒体。
14. 前記命令は、さらに、前記オンデマンドコード実行システムに、前記ユーザ送出コードを実行する第２のリクエストに応じて、前記第１のＯＳバリアントを有する第２の仮想マシンインスタンスで前記ユーザ送出コードを実行することを行わせる、
    請求項１１に記載の非一時的なコンピュータ可読媒体。

Images