JP7210713B2 - オンデマンドコード実行システムにおける実行環境についての効率的な状態メンテナンス - Google Patents

Description

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

データセンターリソースの利用度を向上させるために、仮想化技術により、単一の物理コンピューティングデバイスが、データセンターのユーザに対して独立したコンピューティングデバイスとして表示され、かつ動作する仮想マシンの１つ以上のインスタンスをホストすることができる。仮想化に伴い、単一の物理コンピューティングデバイスは、仮想マシンの作成、維持、削除、またはその他の方法による管理を動的に行い得る。結果として、ユーザは、単一のコンピューティングデバイス、またはネットワーク接続されたコンピューティングデバイスの構成を含むコンピュータリソースをデータセンターに要求することができ、ユーザにはさまざまな数の仮想マシンリソースが提供され得る。

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

データセンターの使用の一例は、大規模なデータセットを処理する、または解析することであり、これらの大規模なデータセットを、単一のコンピューティングデバイスを使用して解析することは非実用的である場合がある。複数のコンピューティングデバイス（または場合によっては単一のコンピューティングデバイス内の複数のプロセッサ）がデータを同時に処理することを可能にするために、さまざまな技法が開発されている。この同時データ処理は、時には「並列化」と称される。データセットを処理する際に並列化を可能にする１つの技法は、「ＭａｐＲｅｄｕｃｅ」プログラミングモデルである。このプログラミングモデルは、デバイスセット内の個別のコンピューティングデバイスによる２つの関数の実行を制御する、集中型「インフラストラクチャ」または「フレームワーク」を一般に必要とする。第一関数である「ｍａｐ」関数の実行により、複数のデバイスに、完全な生データセットの部分（または「チャンク」）を処理させて、テキストのコーパス内の個々の単語のカウントなどの中間結果セットを生成させる。第二関数である「ｒｅｄｕｃｅ」関数の実行により、１つ以上のデバイスに、複数の中間結果セット（複数のｍａｐ関数からの）を組み合わせて、集計結果セットを生成させる。ｒｅｄｕｃｅ関数を複数回実行することができ、実行するたびに、単一の集計結果記録が作成されるまで、集計結果数をさらにｒｅｄｕｃｅ処理させる。ＭａｐＲｅｄｕｃｅプログラミングモデルの従来の実装では、インフラストラクチャまたはフレームワークは、通常、結果が提供されるまでｍａｐ関数およびｒｅｄｕｃｅ関数の実行を調整するために、連続して実行する必要がある。

オンデマンドコード実行システム内の個別の実行環境が、状態情報を維持することを必要としないように、オンデマンドコード実行システムが、データセットを処理するためにポーリングデバイスを利用して状態情報を維持することによってデータセットを処理するように動作することができる、例示的な環境を示すブロック図である。 図１のワーカーマネージャを提供するコンピューティングデバイスの一般的なアーキテクチャを示す。 図１のオンデマンドコード実行システムの実行環境内でのコードの実行を介してデータセットを処理するために、ポーリングデバイスを利用して状態情報を維持するための例示的なインタラクションを示す流れ図である。 データセットを処理する、具体的には、独立して各処理されることができる複数のサブセットにデータ項目セットを分割することを可能にする、デバイスの再分散中に、図１のポーラーデバイス間の状態情報の転送をグラフィックで示す図解である。 データセットを処理する、具体的には、複数のデータ項目セットを単一のスーパーセットにマージすることを可能にする、デバイスの再分散中に、図１のポーラーデバイス間の状態情報の転送をグラフィックで示す図解である。 図１のオンデマンドコード実行システムの実行環境内でのコードの実行を介してデータセットを処理するために、ポーリングデバイスを利用して状態情報を維持するための例示的なルーティンである。

一般的に説明すれば、本開示の態様は、クライアントがデータセットを処理するためにユーザ定義コードの実行を要求することを可能にするオンデマンドコード実行環境に関する。より具体的には、本開示の態様は、コードを実行する実行環境に状態情報を維持することを必要とせずに、データセットをステートフルに処理することを可能にする。データセットの処理との関連で、ステートフル処理は、動作が保持された状態情報に依存しないステートレス処理とは対照的に、一般に、セット内のより後のデータ項目の処理結果が以前に処理されたデータ項目に関連する、保持された状態情報に少なくとも部分的に依存する処理を指す。ステートフル処理を利用して、例えば、セット内の特定のデータ項目の出現回数をカウントすることなどによって、ＭａｐＲｅｄｕｃｅプログラミングモデルを実装することができる。ステートフル処理はエンドユーザにとって望ましいことが多いが、ステートフル処理の正常でレジリエンスのある実装は、分散システムに課題を提示する可能性がある。通常、このような処理は、状態情報をローカルに格納するコードによって実装されるため、より後のデータ項目の処理は、ローカルに格納された状態情報に基づくことができる。ただし、状態情報のローカルストレージは、正しい状態情報を含む環境にデータセット内の各データ項目をルーティングする必要があるため、コード実行の移植性を阻害する。また、状態情報のローカルストレージは、状態情報の損失がデータセットの解析を非決定状態にする可能性があるため、実行環境のレジリエンスに関する追加要件を作成する。これらの理由、そして他の理由のために、本来であればオンデマンドコード実行システム（時には「サーバーレス」計算システムと称される）のような、ステートフル処理に使用することが望ましいかもしれない多くのシステムは、一般に、ステートフルコード実行をサポートしない。本明細書に開示される実施形態は、実行環境内での状態情報のローカルストレージを必要とせずに、実行環境内でのステートフル処理に提供することによって、これらの問題に対処する。

説明を容易にするために、本開示の実施形態は、ＭａｐＲｅｄｕｃｅプログラミングモデルの実装を参照して説明され、このＭａｐＲｅｄｕｃｅプログラミングモデルは、大規模なデータセットを解析するために使用されることができ、一般に、ステートフルコードに少なくとも部分的に依存して、モデルの最初の「ｍａｐ」段階の出力を「ｒｅｄｕｃｅ」処理する。当該技術分野で知られているように、ＭａｐＲｅｄｕｃｅプログラミングモデルは、分散コンピューティングシステム（例えば、互いに通信する複数の別個のデバイスを含む）がデータセット、そして特に大規模なデータセット（例えば、ギガバイト、テラバイト、ペタバイトなどのオーダーで）を処理することを可能にするために使用される論理データ処理モデルである。一般に、ＭａｐＲｅｄｕｃｅプログラミングモデルは、少なくとも２つのデータ処理段階（ｍａｐ段階とｒｅｄｕｃｅ段階）を含む。ｍａｐ段階中に、分散コンピューティングシステム内の個別のデバイスは、データセットの一部分（例えば、ｎギガバイトのチャンク）を収集し、その部分のコンテンツを出力セットに「ｍａｐ」処理する。次に、各出力セットを「ｒｅｄｕｃｅ」関数によって処理し、出力セット内のコンテンツの処理結果を集計する、または組み合わせる、またはその他の方法により決定する。ＭａｐＲｅｄｕｃｅパラダイムの一般的な例は、コーパス内の単語の出現をカウントすることである。例えば、ユーザがマルチテラバイトのテキストデータセットを取得することをサポートし、このデータセット内に存在する単語と、各単語が出現する頻度を決定したい。単一のデバイスを利用すると、このデータセットを処理するには、過度の時間がかかる場合がある。ただし、ＭａｐＲｅｄｕｃｅモデル下では、分散システム内の各デバイスは、ｍａｐ関数に従ってデータセットの制限された部分（または「チャンク」）を処理することができる。この例では、ｍａｐ関数は、データセットの部分内の各単語の出現をカウントすることに対応することができる。このシステム内のデバイスの数を増やすことにより、処理速度を上げることができる。このような処理の制限は、各デバイスがデータセットの制限された部分のみを処理することであるため、その部分内の単語カウントのみを認識している。デバイス間でカウントを集計するために、ｒｅｄｕｃｅ関数を使用する。単一のデバイスを使用して各ｍａｐ関数で生成される単語カウントを集計することができるかもしれないが、このコンフィグレーションは、処理のボトルネックも作り出す。これに対処するために、ＭａｐＲｅｄｕｃｅモデルは、複数のｒｅｄｕｃｅ関数が分散システム全体に実装されることを可能にし、各関数は、出力の属性に従って、ｍａｐ関数の出力サブセットを処理する。例えば、単語カウントの例では、２６個のｒｅｄｕｃｅ関数を実装して、それぞれが英語のアルファベットの特定の文字で始まる単語のカウントを作成することができる。例示的に、第一ｒｅｄｕｃｅ関数はｍａｐ関数からアルファベット「ａ」で始まる単語のすべてのカウントを取得することができ、第二ｒｅｄｕｃｅ関数は「ｂ」で始まる単語のすべてのカウントを取得することができるなど、である。したがって、各ｒｅｄｕｃｅ関数は、コーパス内の単語のある特定の部分についての全体的な単語カウントを得ることができる。ｒｅｄｕｃｅ関数の出力を組み合わせて、合計単語カウントを取得することができる。多くの場合、ｒｅｄｕｃｅ関数の出力を組み合わせることは、それらの出力が明確に異なり重複しないため、比較的低コストの操作である。したがって、ＭａｐＲｅｄｕｃｅプログラミングモデルを利用して、データセットの迅速な分散処理を容易にすることができる。

上記に照らして理解されるように、ＭａｐＲｅｄｕｃｅモデルのｒｅｄｕｃｅ段階は、データセット内のｎ番目のデータ項目の処理結果が（ｎ－１）番目のデータ項目の処理結果に一般に依存するため、ステートフルに実装されることが多い。ステートフルなｒｅｄｕｃｅ段階に提供するために、ＭａｐＲｅｄｕｃｅモデルは、専用の分散システムに従来実装されており、このシステム内のワーカーコンピュータノードの生成およびコンフィグレーションを処理するようにフレームワークソフトウェアで構成されている。専用のワーカーノードの使用は、他の潜在的な利点の中でも、ワーカーノードと、それらがｒｅｄｕｃｅ段階を実装するデータセットの部分との間にアフィニティを提供する。各ワーカーノードには、ｍａｐ段階の出力の適切な部分を提供することができるため、その部分に関してｒｅｄｕｃｅ段階の正確な実装を確保することができる。ただし、従来のＭａｐＲｅｄｕｃｅ実装もまた不利な点がある。例えば、ワーカーノードは、通常、ＭａｐＲｅｄｕｃｅモデルの実装のみに専用であり、それらの機能が他のコンピューティングタスクを行うことを制限する。したがって、このような分散システムを確立することは、特にユーザがＭａｐＲｅｄｕｃｅモデルの実装に継続的な専用システムを必要としない場合、時間がかかり、非効率的である可能性がある。

本開示の実施形態は、オンデマンドコード実行システムによって提供されるようなステートレスな実行環境内に実装される、ＭａｐＲｅｄｕｃｅプログラミングモデルのｒｅｄｕｃｅ段階などの典型的なステートフル処理を可能にすることによって、上記の問題に対処する。以下でより詳細に説明されるように、本開示の実施形態は、中間デバイスが、反復データ処理（例えば、ＭａｐＲｅｄｕｃｅモデルのｒｅｄｕｃｅ段階）に関連する状態情報を維持し、オンデマンドコード実行システム上でコードを実行する各要求に状態情報をサブミットすることを可能にする。中間デバイスは、各呼び出しに応答して更新された状態情報を取得し、更新された状態情報を次の呼び出しに含むことができる。このようにして、オンデマンドコード実行システム上の実行環境は、状態情報を維持する義務から解放され、ステートレスに動作し続けることができる。ただし、それにもかかわらず、データセットの処理中に状態情報を維持することができるため、データセットの正常なステートフル解析を可能にする。以下に説明されるように、中間デバイスは、データセットを処理するシステム内の不具合を識別して訂正することができるように、動作のレジリエンスを確保するように構成されることができる。さらに、中間デバイスは、効率的なレジリエンスを確保するように構成されることができるため、レジリエンスを提供することは、データセットを処理するシステムの機能に実質的な悪影響を及ぼさない。

一実施形態では、中間デバイスは、ポーラーデバイスであり、このポーラーデバイスは、オンデマンドコード実行システム上でコードを呼び出すための呼び出しセットを取得し（例えば、呼び出しに含まれるか参照されるデータ項目を処理するために）、そして各呼び出しをオンデマンドコード実行システムに渡すように動作する。呼び出しセットは、ストリームデータ処理システム上のメッセージキューなどのキューとして例示的に維持されることができる。例示的に、本開示の実施形態によるポーラーデバイスは、キュー上のデータ項目を処理するための初期状態情報を決定し（例えば、ヌル状態として）、キューから呼び出しの初期バッチを取得し、キューの処理状態を表す現在の状態情報に加えて各呼び出しを、オンデマンドコード実行システムに繰り返しサブミットすることができる。ポーラーデバイスは、各呼び出しに応答して更新された状態情報を受信するように構成されることができ、この情報は、後続の呼び出しに含まれることができる。キューについての状態情報を各呼び出しに渡すため、オンデマンドコード実行システム上の環境自体は、状態情報を維持するために必要とされない。このため、アフィニティは、ポーラーデバイスと、呼び出しが処理される環境との間に一般に必要とされない。むしろ、オンデマンドコード実行システムは、ポーラーデバイスから任意の適切な環境に呼び出しをルーティングすることができ、呼び出しに対応するコードを実行する際のオンデマンドコード実行システムの柔軟性を向上させる。ポーラーデバイスは、レジリエンスのあるストレージシステム（例えば、ビルトイン冗長性を有するネットワークストレージ位置）に状態情報を定期的に保存し、その保存された状態情報に基づいて不具合イベント中に処理を再開するように構成されることができる。したがって、ポーラーデバイスに状態情報を維持することは、オンデマンドコード実行システムでのステートフルなデータ処理を可能にする効率的なメカニズムを提供する。

オンデマンドコード実行システムでステートフルなデータ処理を可能にする他のメカニズムが本明細書で企図されているが、これらの他のメカニズムは、中間（例えば、ポーラー）デバイスに状態情報を維持することよりも一般に望ましくない。例えば、各呼び出しが同じ実行環境にルーティングされるように、オンデマンドコード実行システムが、所与のコードセットを実行するために複数の呼び出しにアフィニティを提供するように構成されることが考えられる。さらに、オンデマンドコード実行システムによって、そのような各環境がローカル状態情報を維持することが可能であることで、この環境内でコードのステートフル実行が可能であることが考えられる。ただし、このアプローチは、オンデマンドコード実行システムの操作の柔軟性を大幅に低下させるため、システムが実行環境を長期間維持することを要求する。さらに、このアプローチは、動作のレジリエンスを提供する必要性、または動作負荷の変化に応答して多数の環境をスケールアップもしくはスケールダウンする必要性など、分散処理システムで頻繁に発生する問題に対処するにはあまり適していない可能性がある。例えば、これらの問題に対処するために、オンデマンドコード実行システムは、各環境の状態情報を頻繁に保存することが要求される場合があり、システムのリソース使用量が大幅に増加する。また、システムは、スケールアップまたはスケールダウンイベント中に環境間で状態情報の転送のために提供することが要求される場合があり、それらのような環境の管理の複雑さが増す。呼び出しの処理間で状態情報を保持するための別の可能なメカニズムは、呼び出しの処理中に、その状態情報をネットワークデータストレージなどの永続的な外部位置に書き込むように各実行環境を設定することである。したがって、後続の実行は、永続的な位置から状態情報を取得して、後続の呼び出しの処理を容易にすることができる。ただし、分散システムでは、外部ストレージ位置への書き込みは、呼び出しを処理するために使用されるコンピューティングリソースを大幅に増加させる可能性があるため、一般に「重い」操作とみなされる。例えば、ネットワーク位置への書き込みは、ネットワーク位置とのトランスポート制御プロトコル（ＴＣＰ）セッション、およびかなりの時間とリソースを必要とする可能性がある（本来であれば単一の呼び出しを処理することが要求されるリソースの観点から）プロセスの開始を要求する場合がある。呼び出しの数が多い場合（例えば、マルチテラバイトのデータセットを処理する場合）、このような重い操作に要求される追加のオーバーヘッドは相当になる可能性がある。

本開示の実施形態は、これらの不利な点なしで、呼び出しの処理間で状態情報を維持することを可能にする。例えば、中間デバイスは、呼び出しをオンデマンドコード実行システムにサブミットすると同時に、呼び出しについての状態情報を渡すことができ、その呼び出しへの応答として更新された状態情報を受信することができる。したがって、追加のネットワーク通信は、オンデマンドコード実行システムでは要求されない。さらに、中間デバイスは、このデバイスに利用可能なリソースと、不具合イベント中に動作を再開するために要求されるオーバーヘッドとに基づいて調整されることができる周期で、状態情報を定期的に保存することによってレジリエンスを提供することを実装することができる。具体的には、中間デバイスは「長期」ビューの呼び出しキューを処理することが可能であるため、このデバイスは、各呼び出し後に状態情報を、オンデマンドコード実行システムまたは外部データストアが保存することができる場合、保存することを確保することが要求されない。

本明細書で詳細に説明されるように、オンデマンドコード実行システムは、オンデマンドコード実行システム上で仮想マシンインスタンスによって実行されるコンピュータ実行可能コードをユーザがサブミットする、または指定することを可能にするネットワークアクセス可能なサービスを提供することができる。オンデマンドコード実行システム上の各コードセットは、「タスク」を定義し、オンデマンドコード実行システムの仮想マシンインスタンス上で実行されるときに、そのタスクに対応する特定の機能を実装することができる。オンデマンドコード実行システム上でのタスクの個別の実装は、タスクの「実行」（または「タスク実行」）と称されることができる。さらに、オンデマンドコード実行システムによって、ユーザは、ネットワークベースのストレージシステムでの新しいデータの検出、オンデマンドコード実行システムへのアプリケーションプログラミングインタフェース（「ＡＰＩ」）呼び出しの送信、または特別にフォーマットされたハイパーテキスト転送プロトコル（「ＨＴＴＰ」）パケットのオンデマンドコード実行システムへの送信のような、さまざまな潜在的なイベントに基づいてタスクの実行をトリガすることができる。したがって、コードが実行される、基盤となるハードウェアまたはインフラストラクチャのコンフィグレーションまたはメンテナンスを必要とせずに、ユーザは、オンデマンドコード実行システムを利用して、いずれかの指定された実行可能コードを「オンデマンド」で実行することができる。さらに、オンデマンドコード実行システムは、タスクを迅速な方式で（例えば、１００ミリ秒［ｍｓ］未満で）実行するように構成されることができることで、タスク実行を「リアルタイム」で（例えば、エンドユーザに認知可能な遅延がほとんどない、またはまったくない状態で）可能にする。

オンデマンドコード実行システムが、コードを実行する基盤となるデバイスのコンフィグレーションなしで、タスクをオンデマンドで実行する機能を提供することができるため、オンデマンドコード実行システムは、ＭａｐＲｅｄｕｃｅプログラミングモデルを実装するための優れたプラットフォームを提供することができる。例えば、「ＭＡＰＲＥＤＵＣＥ ＩＭＰＬＥＭＥＮＴＡＴＩＯＮ ＩＮ ＡＮ ＯＮ－ＤＥＭＡＮＤ ＮＥＴＷＯＲＫ ＣＯＤＥ ＥＸＥＣＵＴＩＯＮ ＳＹＳＴＥＭ ＡＮＤ ＳＴＲＥＡＭ ＤＡＴＡ ＰＲＯＣＥＳＳＩＮＧ ＳＹＳＴＥＭ」と題され、２０１８年９月２７日に出願された米国特許出願第１６／１４４，９９７号（「’９９７出願」）に記載されているように、この出願は、その全体が参照により本明細書に援用され、オンデマンドコード実行システムをストリームデータ処理システムと組み合わせて使用して、集中型コントローラを必要とせずにＭａｐＲｅｄｕｃｅプログラミングモデルを実装することができる。本開示は、ＭａｐＲｅｄｕｃｅプログラミングモデルまたは他のデータ解析を実装するオンデマンドコード実行システムの動作を、そのようなデータ解析のために状態情報を維持する効率的な方法を提供することによって、そのような状態情報をオンデマンドコード実行システムの環境内に維持すること、またはそのような環境によって追加の外部位置に永続化することを必要とせずに、さらに改善することができる。

本開示に照らして当業者に理解されるように、本明細書に開示される実施形態は、並列化可能な方法でデータセットを処理して解析する、オンデマンドコード実行システムなどのコンピューティングシステムの機能を改善する。より具体的には、本開示の実施形態は、そのような状態情報がシステムの実行環境に維持されることを必要とせずに、オンデマンドコード実行システム上でのコード実行間に状態情報を効率的に維持することを可能にする。さらに、現在開示されている実施形態は、コンピューティングシステム内に固有の技術的問題、具体的には、データセットをステートフルに処理するときに状態情報を維持する必要性と、そのような情報を、データセットを処理するために使用されるコンピューティングリソースを増加させることなく、またはそのような処理が発生する位置の柔軟性を低下させることなく維持することの困難とに対処する。これらの技術的問題は、キューからオンデマンドコード実行システムへの呼び出しを取得し、これらの呼び出しによって渡される状態情報を維持しながらオンデマンドコード実行システムに呼び出しを繰り返しサブミットするための中間デバイスの使用を含む、本明細書に記載されるさまざまな技術的解決策によって対処される。よって、本開示は、概して、既存のデータ処理システムおよびコンピューティングシステムに対する改善を表す。

次に、オンデマンドコード実行環境上でのタスクの一般的な実行を考察する。具体的には、タスクを実行するために、本明細書に記載されるオンデマンドコード実行環境は、ユーザ要求を受信するとすぐに使える状態である、事前に初期化された仮想マシンインスタンスのプールを維持することができる。これらの仮想マシンは、事前に初期化されているために、ユーザコードの実行に伴う（レイテンシと呼ばれることもある）遅延（例えば、インスタンスおよび言語ランタイムの起動時間）を、多くの場合は１００ミリ秒より下のレベルまで、大幅に減らすことができる。実例として、オンデマンドコード実行環境は、１つ以上の物理コンピューティングデバイス上で仮想マシンインスタンスのプールを維持してもよく、そこでそれぞれの仮想マシンインスタンスは、そのデバイス上にロードされた１つ以上のソフトウェア構成要素（例えば、オペレーティングシステム、言語ランタイム、ライブラリなど）を有する。オンデマンドコード実行環境が、ユーザのプログラムコードを実行する要求（タスク）であって、そのユーザのプログラムコードを実行するための１つ以上の計算制約を指定する要求を受信した際に、オンデマンドコード実行環境では、要求によって指定された１つ以上の計算制約に基づいてユーザのプログラムコードを実行するための仮想マシンインスタンスが選択され、選択された仮想マシンインスタンス上でユーザのプログラムコードが実行されるようにしてもよい。プログラムコードは、仮想マシンインスタンス上に作成される隔離されたコンテナ内で実行させることができる。プール内の仮想マシンインスタンスは、要求が受信されるときまでに、特定のオペレーティングシステムおよび言語ランタイムとともに既にブートされてロードされているので、要求を（例えば、仮想マシンインスタンス上に作成された１つ以上のコンテナ内でユーザコードを実行することによって）処理することができる算出能力を検出するのに伴う遅延は大幅に減少する。

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

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

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

本開示の上に述べた態様と付随する利点の多くとは、添付の図面と併用されると、以下の説明を参照することにより、それらが一層よく理解されるようになるので、さらに容易に認識されるようになる。

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

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

例示的な環境１００にはさらに、１つ以上のネットワークベースのデータストレージサービス１０８（オンデマンドコード実行システム１１０が１つ以上の永続的なまたは実質的に永続的なデータソースにデータを記憶して取り出すことができるように構成されている）が含まれている。例示的に、ネットワークベースのデータストレージサービス１０８は、オンデマンドコード実行システム１１０が、解析されるデータセットを取得し、その解析に関する情報（例えば、結果）を格納することを可能とし得る。ネットワークベースのデータストレージサービス１０８は、例えば、リレーショナルデータベースまたは非リレーショナルデータベースを表すことができる。別の例では、ネットワークベースのデータストレージサービス１０８は、ファイルシステムとして配列されるデータへのアクセスを提供するように構成される、ネットワークアタッチドストレージ（ＮＡＳ）を表すことができる。本開示の実施形態内で使用可能なネットワークベースのデータストレージサービス１０８内に、さまざまな他の機能を含むことができる。さらに、ネットワークベースのデータストレージサービス１０８は、オンデマンドコード実行システム１１０が、複数の関連するファイルまたは記録、それらのファイルまたは記録のサイズ、ファイルまたは記録名、ファイルまたは記録の作成時間などについてのクエリを行うことなどによって、オンデマンドコード実行システム１１０内に格納されるデータに関する情報にクエリを行い、この情報を取得することを可能にしてもよい。場合によっては、ネットワークベースのデータストレージサービス１０８は、データを論理グループ（例えば、個別のアカウントに関連するグループなど）に分離する機能などの追加機能を提供することができる。補助サービス１０６とは異なるように示されるが、ネットワークベースのデータストレージサービス１０８は、ある場合には、補助サービス１０６のタイプも表すことができる。

例示的な環境１００は、ストリームデータ処理システム１７０をさらに含む。上記に考察されるように、ストリームデータ処理システムは、特定の「トピック」に基づいて指定されることができる、「メッセージ」をストリーム１７２上に公開することなどによって、アップストリームデバイスがデータをメッセージストリーム１７２上に置く機能を提供することができる。単一のストリーム１７２が図１に示されているが、システム１７０は、複数の当事者らに代わって複数のストリームを提供することができる。システム１７０は、ストリーム１７２内のメッセージを、しばしば「先入れ先出し」（「ＦＩＦＯ」）またはほぼＦＩＦＯの順序で、ダウンストリームデバイスに利用可能にすることができる。いくつかの例では、ストリームデータ処理システム１７０は、メッセージをダウンストリームデバイスに「プッシュ」する。他の例では、ダウンストリームデバイスは、要求に応じてメッセージストリーム１７２からメッセージを「プル」する。一般に、ストリームに正常に公開されたデータが、ストリームデータ処理システム１７０のデバイスの不具合のために失われる可能性が低いように、ストリームデータ処理システム１７０は、レジリエンスを提供するように構成される。例えば、システム１７０は、ストリーム１７２上に置かれているメッセージを、このストリームを実装するために使用される複数のコンピューティングデバイス（例えば、物理コンピューティングデバイス、または物理ホストに実装される仮想デバイス）上に複製することができる。さらに、ストリームデータ処理システム１７０は、メッセージストリーム１７２を維持するデバイスの並列化を提供するように構成されることができる。例えば、メッセージストリームを構成するユーザは、ストリームについてのパーティションキーを指定し、このパーティションキーを使用して、ストリームをサブストリームに分割し、各サブストリームを１つ以上の並列化されたデバイスによって処理することを可能にする。サブストリームをメッセージシャード１７４Ａ～Ｎとして図１に示す。各メッセージシャード１７４は、１つ以上のコンピューティングデバイスを一般的に表すことができ、これらのコンピューティングデバイスは、パーティションキーに従ってシステム１７０が選択するメッセージストリーム上のメッセージのサブセットと、ストリーム１７２上のメッセージのボリュームとを取得して利用可能にするように構成される（例えば、ストリーム１７２上のメッセージにサービスを提供するためのシャード１７４の容量に基づいて、追加のシャードが作成される、または余分なシャードが破棄されるように）。当該技術分野で知られているストリームデータ処理システムの例は、ＡＭＡＺＯＮ（商標）ＫＩＮＥＳＩＳ（商標）ネットワークサービス、およびＡＰＡＣＨＥ（商標）ＫＡＦＫＡ（商標）システムを含む。

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

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

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

図１の例では、オンデマンドコード実行システム１１０およびストリームデータ処理システム１７０は、ネットワーク１０４に接続されているものとして示されている。いくつかの実施形態では、オンデマンドコード実行システム１１０およびストリームデータ処理システム１７０内のコンポーネントのいずれかは、オンデマンドコード実行システム１１０およびストリームデータ処理システム１７０の他のコンポーネントとネットワーク１０４を介して通信することができる。他の実施形態では、別のネットワーク（図１に示されていないプライベートネットワークなど）は、オンデマンドコード実行システム１１０およびストリームデータ処理システム１７０のそれぞれの内のコンポーネント間、またはそれらのシステム間の通信を可能にすることができる。

図１では、ユーザは、ユーザコンピューティングデバイス１０２によって、オンデマンドコード実行システム１１０と相互に対話して、実行可能コードを提供し、またこのようなコードをいつどのようにオンデマンドコード実行システム１１０で実行すべきかを規定するルールまたはロジックを設定することによって、「タスク」を設定してもよい。例えば、ユーザは、コードの一部を、ユーザが開発したウェブまたはモバイルアプリケーションとともに実行することを望む場合がある。コードを起動する１つの方法は、仮想マシンインスタンスを、サービスとしてインフラストラクチャを提供するサービスプロバイダから獲得し、ユーザの要望に合わせるように仮想マシンインスタンスを構成し、コードを起動するように構成された仮想マシンインスタンスを使用するためのものであろう。このプロセスの複雑さを回避するために、ユーザは、代わりに、オンデマンドコード実行システム１１０にコードを提供し、オンデマンドコード実行システム１１０が１つ以上の事前に確立された仮想マシンインスタンスを使用してコードを実行することを要求することができる。オンデマンドコード実行システム１１０は、コード実行要求に基づいて、算出能力（例えば、下記により詳細に説明される、コンテナ、インスタンス等）の取得およびコンフィグレーションを処理し、算出能力を使用してコードを実行することができる。オンデマンドコード実行システム１１０は、ボリュームに基づいて、自動的にスケールアップおよびスケールダウンすることによって、過度の使用率（例えば、取得するコンピューティングリソースがかなり少なく、パフォーマンス問題を被る）、または少ない使用率（例えば、コードを実行するために必要なものよりも多いコンピューティングリソースを取得することによる過払い）について心配しなければならない負担から、ユーザを解放することができる。本開示の実施形態によれば、ユーザによって確立されるタスクは、データセットに関して「ｒｅｄｕｃｅ」関数、または全体としてデータセットに基づいて結果を集計する、もしくは組み合わせる、もしくはその他の方法で決定する他の関数を実装するために実行可能なコードに対応することができる。

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

本明細書で使用されるユーザコードへの言及は、特定のプログラム言語で記述された任意のプログラムコード（例えば、プログラム、ルーティン、サブルーティン、スレッド等）を指し得る。本開示では、用語「コード」、「ユーザコード」、および「プログラムコード」は、互換的に使用されてもよい。このようなユーザコードは、例えば、ユーザによって開発された特定のウェブアプリケーションまたはモバイルアプリケーションに関連して、特定の機能を実現するように実行され得る。上記のように、ユーザコードの個別のコレクション（例えば、特定の機能を達成するための）は、本明細書では「タスク」と称され、そのコードの特定の実行は、「タスク実行」または単に「実行」と称される。タスクは、非限定的な例として、ＪａｖａＳｃｒｉｐｔ（例えば、ｎｏｄｅ．ｊｓ）、Ｊａｖａ、Ｐｙｔｈｏｎ、および／またはＲｕｂｙ（および／または別のプログラミング言語）で記述され得る。タスクは、さまざまな方式で、オンデマンドコード実行システム１１０上での実行のために「トリガ」されることができる。一実施形態では、ユーザまたは他のコンピューティングデバイスは、タスクを実行する要求を送信することができ、この要求は、一般的にはタスクを実行する「呼び出し」と称されることができる。それらのような呼び出しは、実行されるユーザコード（または、その位置）およびユーザコードを実行するために使用される１つ以上の引数を含むことができる。例えば、呼び出しは、タスクを実行する要求と併せてタスクのユーザコードを提供し得る。別の例では、呼び出しは、その名前または識別子によって、以前にアップロードされたタスクを識別し得る。さらなる別の例では、タスクに対応するコードは、タスクに関する呼び出しに含まれることができ、オンデマンドコード実行システム１１０が要求を受信する前に、別個の位置（例えば、補助サービス１０６のストレージ、またはオンデマンドコード実行システム１１０の内部のストレージシステム）にアップロードされる。オンデマンドコード実行システム１１０は、タスクについての呼び出しが処理されるときにタスクのコードが利用可能である位置に基づいて、タスクについてのその実行戦略を変えることができる。フロントエンド１２０の要求インタフェースは、ユーザから、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）要求としてタスクを実行する呼び出しを受信することができる。また、ＨＴＴＰＳ要求に含まれる任意の情報（例えば、ヘッダおよびパラメータ）も、タスクを実行するときに処理され利用され得る。上記で考察されるように、例えば、ＨＴＴＰ、ＭＱＴＴ、およびＣｏＡＰを含む任意の他のプロトコルを使用して、タスク呼び出しを含むメッセージを要求インタフェースに転送することができる。

タスクを実行する呼び出しは、タスクに対応するユーザコードとともに使用される１つ以上の第三者ライブラリ（ネイティブライブラリを含む）を指定することができる。一実施形態では、呼び出しは、ユーザコードと、実行のために要求されるタスクに対応する任意のライブラリ（および／またはそのストレージ位置の識別）とを含むＺＩＰファイルをオンデマンドコード実行システム１１０に提供してよい。いくつかの実施形態では、呼び出しは、実行されるタスクのプログラムコード、プログラムコードを書き込む言語、呼び出しに関連するユーザ、および／またはプログラムコードを実行するために予約されるコンピューティングリソース（例えば、メモリなど）を示すメタデータを含む。例えば、タスクのプログラムコードは、呼び出しを提供されること、ユーザによって事前にアップロードされること、オンデマンドコード実行システム１１０（例えば、標準ルーティン）によって提供されること、および／または第三者によって提供されることができる。いくつかの実施形態では、そのようなリソースレベルの制約（例えば、特定のユーザコードを実行するために、どれだけのメモリが割り当てられるべきか）は、特定のタスクに対して指定され、タスクの各実行にわたり変えなくてもよい。それらのような場合、オンデマンドコード実行システム１１０は、個々の呼び出しを受信する前に、そのようなリソースレベルの制約にアクセスすることができ、個々の呼び出しは、そのようなリソースレベルの制約を指定しなくてよい。いくつかの実施形態では、呼び出しは、パーミッションデータなどの他の制約を指定することができ、このパーミッションデータは、呼び出しがタスクを実行するために講じるのはどの種類のパーミッションまたは権限かを示す。そのようなパーミッションデータは、プライベートリソース（例えば、プライベートネットワーク上の）にアクセスするためにオンデマンドコード実行システム１１０によって使用されてもよい。

いくつかの実施形態では、呼び出しは、呼び出しを処理するために採用されるビヘイビアを指定してよい。そのような実施形態では、呼び出しは、呼び出しで参照されるタスクを実行するための１つ以上の実行モードを有効にするためのインジケータを含んでもよい。例えば、呼び出しは、タスクの実行に関連して生成され得るデバッグおよび/またはログの出力が（例えば、コンソールユーザインタフェースを介して）ユーザに返されるデバッグモードでタスクが実行される必要があるかどうかを示すフラグまたはヘッダを含んでもよい。このような例では、オンデマンドコード実行システム１１０は、呼び出しにインスペクションを実行し、フラグまたはヘッダを探してよく、フラグまたはヘッダが存在する場合には、オンデマンドコード実行システム１１０は、タスクが実行されるコンテナのビヘイビア（例えば、ロギング機能）を変更し、出力データがユーザに返されるようにしてもよい。いくつかの実施形態では、ビヘイビア／モードインジケータは、オンデマンドコード実行システム１１０によってユーザに提供されるユーザインタフェースによって呼び出しに追加される。ソースコードプロファイリング、リモートデバッギングなどの他の特徴も、呼び出しにおいて提供されるインジケーションに基づいて、有効または無効にされてもよい。

本開示の実施形態によれば、ユーザがサブミットしたコードは、データセットについての解析関数に対応することができる。この関数は、オンデマンドコード実行システム１１０上の１つ以上の解析タスク１６４によって表される、コンピュータ実行可能コードに具現化されることができる。一実施形態では、解析タスク１６４は、ＭａｐＲｅｄｕｃｅプログラミングモデルのｒｅｄｕｃｅ段階を実装する。このようなモデルでのｒｅｄｕｃｅ段階の特定の機能は、処理されるデータによって異なる場合がある。ただし、一般的には、ｒｅｄｕｃｅ関数は、複数の中間結果を集計結果に「ｒｅｄｕｃｅ」処理する、または集計するコードに対応する。例えば、初期ｍａｐ関数は、単語のコーパス（例えば、本または本のコレクション）を処理し、このコーパス内の個別の単語（または、場合によっては、姓などの特定のクラスの単語）のカウントを生成するコードに対応することができる。対応するｒｅｄｕｃｅ関数は、ｍａｐ関数の個別の実行によって生成されるような、個別の単語のカウントを集計するコードに対応することができる。実例として、ｒｅｄｕｃｅ関数は、ｍａｐ関数の１０００個のインスタンスによって生成されるような、１０００個の中間カウントデータファイルを取り、１０００個の中間カウントデータファイル内の各単語のカウントを集計する単一のデータファイルを生成することができる。単一のｒｅｄｕｃｅ関数のみが実行される場合、単一のデータファイルは解析の結果を表すことができる。複数のｒｅｄｕｃｅ関数が実行された結果、複数の出力（入力セット内の単語のカウントを各集計する）になる場合、追加のｒｅｄｕｃｅ関数は、それらの複数の出力を処理して、単語のカウントをさらに集計することができる。このプロセスを、単一のｒｅｄｕｃｅ関数が呼び出されるまで続行することができ、解析の結果として単一の出力ファイルをもたらす。あるいは、複数のｒｅｄｕｃｅ関数のそれぞれは、解析の最終出力として、出力を共通の位置（データベースなど）に書き込むことができる。

解析関数は処理されるデータに特有であることが多いため、これらの関数に対応するコードは、対応するデータセットの解析を要求するエンドユーザによって提供されることができる。場合によっては、オンデマンドコード実行システム１１０は、対応する解析関数の１つ以上のセットをも提供することができる（例えば、一般的に望まれている解析タイプに対応し、所期のフォーマット内でデータを処理するように構成される）。

これらのタスクのストレージを可能にするために、オンデマンドコード実行システム１１０は、タスクデータストア１６０を含むことができ、このタスクデータストア１６０は、ハードドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＤＤ）、ネットワークアタッチドストレージ（ＮＡＳ）、テープドライブ、またはそれらの任意の組み合わせなど、永続的な、または実質的に永続的なデータストアに対応することができる。本開示の実施形態によれば、タスクデータストアは、１つ以上の解析タスク１６４を含み得る。

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

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

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

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

オンデマンドコード実行システム１１０は、１つ以上のワーカーマネージャ１４０をさらに含み、１つ以上のワーカーマネージャ１４０は、着信呼び出しにタスクを実行するサービスを提供するために使用される、仮想マシンインスタンス１５０（ＶＭインスタンス１５０Ａおよび１５０Ｂとして示され、一般に「ＶＭ」と称される）などの実行環境を管理し、実行環境のメモリ状態を管理する。以下は、それらのような環境の例として仮想マシンインスタンス１５０を参照して説明されるが、本開示の実施形態は、ソフトウェアコンテナなどの他の環境を利用することができる。図１に示される例では、各ワーカーマネージャ１４０は、アクティブプール１４０Ａを管理し、このアクティブプール１４０Ａは、所与のタスクを実行するために初期化される（インスタンスにロードされるタスクコードおよび依存関係データオブジェクトを含むことによって）１つ以上の物理ホストコンピューティングデバイス上で実行される仮想マシンインスタンス１５０のグループ（時にはプールと称される）である。アクティブプール１４０Ａは、例示的に、ワーカーマネージャ１４０を実装する、またはその制御下にあるホストデバイスのプライマリメモリ（例えば、ＲＡＭ）を使用して実装される。

仮想マシンインスタンス１５０が特定のタスクに割り当てられるように本明細書に説明されるが、いくつかの実施形態では、インスタンスをタスクグループに関係付け、グループのいずれかのタスクをインスタンス内で実行することができるように、インスタンスをタスクグループに割り当てることができる。例えば、１つのタスクが特定のインスタンス１５０上の１つのコンテナ内で実行された後に同じインスタンス上の別のコンテナ内で別のタスクを実行することによって、セキュリティリスクをもたらさないように、同じグループ内のタスクは、同じセキュリティグループに属する（例えば、そのセキュリティクレデンシャルに基づいて）ことができる。別の例として、グループの１つのタスクを実行するために使用される環境を迅速に変更して、グループ内の別のタスクの実行をサポートすることができるように、グループのタスクは、共通の依存関係を共有することができる。

タスクを実行するトリガイベントがフロントエンド１２０によって正常に処理されると、フロントエンド１２０は、タスクを実行する要求をワーカーマネージャ１４０に渡す。一実施形態では、各フロントエンド１２０は、対応するワーカーマネージャ１４０（例えば、フロントエンド１２０と同じ位置にある、または地理的に近いワーカーマネージャ１４０）に関連付けられていてもよく、したがって、フロントエンド１２０は、ほとんど、またはすべての要求をそのワーカーマネージャ１４０に渡すことができる。別の実施形態では、フロントエンド１２０は、実行要求を渡すワーカーマネージャ１４０を決定するように構成されるロケーションセレクタを含むことができる。一実施形態では、ロケーションセレクタは、呼び出しをハッシュ化することと、ハッシュ化した値に基づいて（例えば、ハッシュリングを介して）選択したワーカーマネージャ１４０に呼び出しを分散することとに基づいて、呼び出しを受信するワーカーマネージャ１４０を決定してもよい。ワーカーマネージャ１４０間で呼び出しを分散するさまざまな他のメカニズムは当業者に明らかであろう。

その後、ワーカーマネージャ１４０は、仮想マシンインスタンス１５０を変更し（必要に応じて）、インスタンス１５０内でタスクのコードを実行することができる。図１に示されるように、それぞれのインスタンス１５０は、オペレーティングシステム（ＯＳ）１５２（ＯＳ１５２Ａおよび１５２Ｂとして示される）、言語ランタイム１５４（ランタイム１５４Ａおよび１５４Ｂとして示される）、およびユーザコード１５６（ユーザコード１５６Ａおよび１５６Ｂとして示される）を含むことができる。ＯＳ１５２、ランタイム１５４、およびユーザコード１５６は、合わせて、ユーザコードの実行がタスクを実装することを可能にしてもよい。場合によっては、各ＶＭ１５０は、タスクの個々の実行にわたって維持される状態情報などの追加情報に関連付けられることができる。例えば、最初に作成されたとき、ＶＭ１５０はＯＳ１５２を初期化することができ、ユーザコード１５６がＶＭ１５０で実行されるたびに、ＶＭ１５０の状態は変化することができる。ＶＭ１５０の状態は、例えば、ＶＭ１５０の仮想ＣＰＵのレジスタ内、ＶＭ１５０のＲＡＭ内、ＶＭ１５０の仮想ディスクドライブ内などで維持されることができる。本開示の実施形態によれば、解析タスク１６４は、ＶＭ１５０がそのような状態情報を維持することができるように構成される場合でも、ＶＭ１５０で維持される状態を必要とせずにデータセット全体で実行されることができる。有利なことに、これにより、解析タスク１６４を実行するための呼び出しは、適切な状態情報が格納されているＶＭ１５０ではなく、いずれかの利用可能なＶＭ１５０にルーティングされることが可能となり得る。

前述したように、ユーザコンピューティングデバイス１０２からの明示的呼び出しに基づいて（例えば、リクエストインタフェース１２２において受け取ったときに）、タスクをオンデマンドコード実行システム１１０において実行するようにトリガしてもよい。代替に、または追加で、１つ以上の補助サービス１０６、ネットワークベースのデータストレージサービス１０８、またはストリームデータ処理システム１７０から取得されるデータに基づいて、オンデマンドコード実行システム１１０での実行のためにタスクをトリガしてよい。

補助サービス１０６とのインタラクションを容易にするために、システム１１０は、ポーリングフリート１３０を含み、このポーリングフリート１３０は、データについて補助サービス１０６、データストレージサービス１０８、またはストリームデータ処理システム１７０をポーリングするように動作する。例示的に、ポーリングフリート１３０は、１つ以上のコンピューティングデバイス（図１にポーラーデバイス１３２Ａ～Ｎとして示される）を含むことができる。これらのコンピューティングデバイスは、いずれかの新たに利用可能なデータ（例えば、ソーシャルネットワークの「投稿」、ニュース記事、ファイル、記録など）を取得し、そのデータがオンデマンドコード実行システム１１０上でタスクの実行をトリガするユーザが確立した基準に対応するかどうかを決定する要求を、補助サービス１０６、データストレージサービス１０８、またはストリームデータ処理システム１７０に定期的に送信するように構成される。例示的に、タスクの実行についての基準は、新しいデータが、補助サービス１０６、データストレージサービス１０８、もしくはストリームデータ処理システム１７０において利用可能かどうか、データのタイプもしくはコンテンツ、またはデータに対応するタイミング情報を含むことができるが、これらに限定されない。場合によっては、補助サービス１０６、データストレージサービス１０８、またはストリームデータ処理システム１７０は、フロントエンド１２０に新しいデータの可用性を通知するように機能することができてもよく、したがって、それらのようなサービスに対して、ポーリングフリート１３０は不要であってもよい。

本開示の実施形態によれば、メッセージストリーム１７２は、データセット内のデータ項目を処理する呼び出しを格納するように構成されることができる。例示的に、メッセージストリーム上の各メッセージは、データセット内の個々のデータ項目に関して解析タスク１６４を実行する呼び出しに対応することができる。メッセージは、メッセージストリーム１７２についてのパーティションキーに基づいてシャード１７４Ａ～Ｎ間に分散されることができ、このキーは、メッセージのデータ項目によって表されることができる、またはそのデータ項目中に含まれることができる。一実施形態では、メッセージは、ＭａｐＲｅｄｕｅｃモデルのｍａｐ段階の動作を介してメッセージストリーム１７２上に置かれる。そのようなｍａｐ段階の動作についての例示的な実施形態は、上記に参照によって援用されている、’９９７出願において考察されている。別の実施形態では、メッセージは、解析されるデータを生成するデバイスの動作中（例えば、「リアルタイム」）などに、他のメカニズムを介してストリーム１７２に置かれる。

図１に示されるように、ポーラーフリート１３０は、メッセージストリーム１７２内のメッセージシャード１７４の数に基づいて、動的な数のポーラーデバイス１３２Ａ～Ｎ（例えば、基礎となるコンピューティングシステム上の仮想マシンインスタンスとして実装される）を含むように構成されることができる。例えば、図１の点線で示されるように、メッセージシャード１７４Ａはポーラーデバイス１３２Ａに対応することができ、メッセージシャード１７４Ｂはポーラーデバイス１３２Ｂに対応することができるなど。したがって、メッセージシャード１７４の数が変化するにつれて（例えば、メッセージストリームのボリュームが原因で）、ポーラーデバイス１３２の数もまた変化することができる。そのようなものとして、ポーラーフリート１３０は、ストリームデータ処理システム１７０と通信することができ、システム１７０は、メッセージシャード１７４に対する変化をポーラーフリート１３０に通知することができる。そのようなコンフィグレーションでは、各ポーラーデバイス１３２Ａは、メッセージシャード１７４をポーリングして、メッセージシャードに対応するサブストリーム内のメッセージを取得するように構成されることができる。メッセージを個別に、またはバッチ（例えば、１０個のメッセージ、５０個のメッセージ、１００個のメッセージ、５００個のメッセージなどのバッチ）で取得することができる。その後、ポーラーデバイス１３２は、各メッセージを処理する呼び出しを解析タスク１６４に呼び出すことができ、この呼び出しは、ポーラーデバイス１３２に対応するシャード１７４内のメッセージの現在の処理状態についての状態情報を含む。メッセージを処理する解析タスク１６４の実行の結果を受信すると、デバイス１３２は、その状態情報を更新することができ、次に、その情報を後続の呼び出しとともにデバイス１３２がサブミットすることができる。一実施形態では、解析タスク１６４への呼び出しを、個々のメッセージごとに行うことができる。別の実施形態では、解析タスク１６４への呼び出しは、メッセージシャードからのメッセージの取得のためのバッチサイズにマッチングするバッチサイズで、または異なるバッチサイズで、メッセージのバッチごとに行うことができる。場合によっては、各ポーラーデバイス１３２から解析タスク１６４への呼び出しの実行は、ポーラーデバイス１３２が次の呼び出しを行う前に、実行が成功したことの確認を待機するように、同期して行われることができる。同期呼び出しの使用は、ポーラーデバイス１３２の数と解析タスク１６４の実行数との間に一般に１対１の対応関係が維持されるように、ｒｅｄｕｃｅタスクへの呼び出しを有利に速度制限することができる。

本明細書では、いくつかの機能について、オンデマンドコード実行システム１１０またはストリームデータ処理システム１７０の個々のコンポーネントを参照して概略的に述べているが、それに加えて、またはその代わりに、他のコンポーネント、またはコンポーネントの組み合わせがこのような機能を実装してもよい。例えば、ポーラーデバイス１３２Ａは、メッセージについてのメッセージシャード１７４をポーリングするように動作することができるが、追加で、または代替に、メッセージシャード１７４は、シャード１７４上の新しいメッセージをオンデマンドコード実行システム１１０（例えば、フロントエンド）に通知するように構成されることができる。

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

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

ユーザインタフェースユニット１８２に加えて、および／またはそれと組み合わせて、メモリ１８０は、処理ユニット１９０によって実行されることができる、インスタンス割り振りユニット１８６およびユーザコード実行ユニット１８８を含んでもよい。一実施形態では、ユーザインタフェースユニット１８２、インスタンス割り振りユニット１８６、およびユーザコード実行ユニット１８８は、個別に、または合わせて、本開示のさまざまな態様、例えば、以下でさらに説明されるような、ユーザコードを実行するために使用される算出能力（例えば、コンテナ）を見つけること、およびユーザコードをコンテナにロードさせて実行させることなどを実装する。

インスタンス割り振りユニット１８６は、ユーザコードを実行する要求にサービスするために使用される算出能力を見つける。例えば、インスタンス割り振りユニット１８６は、要求によって指定されるいずれかの制約を満たす仮想マシンインスタンスおよび／またはコンテナを識別し、識別された仮想マシンインスタンスおよび／またはコンテナをユーザまたは要求自体に割り当てる。インスタンス割り振りユニット１８６は、ユーザコードを書き込むプログラミング言語に基づいて、そのような識別を実行することができる。例えば、ユーザコードがＰｙｔｈｏｎで書き込まれる場合、インスタンス割り振りユニット１８６は、その上にプリロードされるＰｙｔｈｏｎランタイムを有するｎ個の仮想マシンインスタンス（例えば、図１のアクティブプール１４０Ａ内の）を見つけて、仮想マシンインスタンスをユーザに割り当てることができる。別の例では、ユーザの要求に指定されるプログラムコードが、既存のコンテナ上に、またはユーザに割り当てられる別の仮想マシンインスタンス（例えば、図１のアクティブプール１４０Ａ内の）上に、既にロードされている場合、インスタンス割り振りユニット１８６は、コンテナ内で、または仮想マシンインスタンス上の新しいコンテナ内で要求を処理させることができる。いくつかの実施形態では、仮想マシンインスタンスがその上にロードされる複数の言語ランタイムを有する場合、インスタンス割り振りユニット１８６は、仮想マシンインスタンス上に新しいコンテナを作成し、要求で指定されるコンピューティング制約に基づいてコンテナ上に適切な言語ランタイムをロードすることができる。

特定の仮想マシンインスタンスが要求に関連するユーザに割り当てられており、特定の仮想マシンインスタンス上のコンテナが要求に割り当てられていると、ユーザコード実行ユニット１８８は、ユーザの要求によって指定されるプログラムコードの実行を管理する。ユーザに割り当てられる仮想マシンインスタンス上のコンテナにコードがプリロードされている場合、コードはコンテナ内で単純に実行される。コードがネットワークストレージ（例えば、図１のストレージサービス１０８）を介して利用可能である場合、ユーザコード実行ユニット１８８は、コードを仮想マシンインスタンス上のコンテナ内にダウンロードし、それをダウンロードすると、コードを実行させる（例えば、図１のフロントエンド１２０と通信することによって）。

インスタンス割り振りユニット１８６およびユーザコード実行ユニット１８８がワーカーマネージャ１４０の一部分として図２に示されているが、他の実施形態では、インスタンス割り振りユニット１８６およびユーザコード実行ユニット１８８の全部または一部分は、オンデマンドコード実行システム１１０および／または別のコンピューティングデバイスの他のコンポーネントによって実装されることができる。例えば、本開示のある実施形態では、オンデマンドコード実行システム１１０と通信している別のコンピューティングデバイスは、ワーカーマネージャ１４０の一部分として示されるモジュールおよびコンポーネントに対して同様に動作するいくつかのモジュールまたはコンポーネントを含むことができる。

いくつかの実施形態では、ワーカーマネージャ１４０は、図２に示されているもの以外のコンポーネントをさらに含むことができる。例えば、メモリ１８０は、仮想マシンインスタンス内のコンテナの作成、準備、およびコンフィグレーションを管理するためのコンテナマネージャをさらに含むことができる。

図３を参照して、ポーラーデバイス１３２でのそのような解析のために状態情報を維持しながら、オンデマンドコード実行システム１１０上で解析タスク１６４の実行を介してデータ項目セットを解析するための例示的なインタラクションを示す。一実施形態では、図３のインタラクションは、ＭａｐＲｅｄｕｃｅプログラミングモデルのｒｅｄｕｃｅ段階を実装するためにシステム１１０によって行われることができるものの例示である。

図３のインタラクションは、（１）から始まり、（１）では、サブミットするデバイス３０１はメッセージストリーム１７２上に解析タスク１６４への呼び出しをエンキューする。サブミットするデバイス３０１は、一般に、任意のデバイスに対応することができ、任意のデバイスは、ユーザデバイス１０２、補助サービス１０６のデバイス、オンデマンドコード実行システム１１０のデバイスなどを含むことができる。例えば、サブミットするデバイス３０１は、ｍａｐ関数を実行したオンデマンドコード実行システム１１０のデバイスであることができる。別の例として、サブミットするデバイス３０１は、解析関数を介して解析されるデータをサブミットするエンドユーザデバイスであることができる。エンキューされた呼び出しは、一般に、データセットの一部分として解析されるデータ項目を含み、そのデータセットは、メッセージストリーム１７２上に呼び出しによって表される。場合によっては、エンキューされた呼び出しは、解析タスク１６４を識別することなどによって、解析タスク１６４を呼び出すための明示的な呼び出しであることができる。他の例では、エンキューされた呼び出しは明示的な呼び出しでなくてもよいが、代わりにデータ項目を単純に渡すことができるにもかかわらず、ストリーム１７２、オンデマンドコード実行システム１１０、または両方のコンフィグレーションが原因で、データ項目を処理する、解析タスク１６４への呼び出しをもたらす。

（２）では、メッセージストリーム１７２（例えば、メッセージストリーム１７２をホストするストリームデータ処理システム１７０）は、ストリーム１７２の適切なシャード１７４上に呼び出しをエンキューする。上記に考察されるように、呼び出しが置かれている特定のシャードは、例えば、呼び出しのデータ項目に適用されるようなストリーム１７２についてのパーティションキーに依存することができる。例えば、ストリームデータ処理システム１７０は、コンシステントハッシュメカニズム（その例は当該技術分野で知られている）を実装して、ストリーム１７２についてのパーティションキーとして指定されたデータ項目の属性に基づいて呼び出しを置くべきシャード１７４を選択することができる。（３）では、ストリーム１７２は、呼び出しがエンキューされたことをサブミットするデバイス３０１に肯定応答する。

図３では、インタラクション（１）から（３）は、非同期呼び出しループ３０２を表し、この非同期呼び出しループ３０２は、ストリーム１７２上に追加の呼び出しをエンキューするために任意の回数繰り返されることができる。各エンキューへの肯定応答が呼び出しの実際の実装に関して非同期で渡されるため、ループ３０２は、非同期呼び出しに関連するものとして指定される。したがって、非同期呼び出しループ３０２のインタラクションは、他のインタラクションから独立して発生することができる。例えば、ループ３０２のインタラクションは、他のインタラクションより前のものとして図３に示されているが、これらのインタラクションは、他のインタラクションと少なくとも部分的に同時に繰り返されることができる。さらに、これらのインタラクションは、複数の異なるサブミットするデバイス３０１によって繰り返されることができる。したがって、インタラクション（１）～（３）の繰り返しにより、複数の呼び出し（例えば、解析されるデータセットのデータ項目に各関係する）をメッセージストリーム１７２上にエンキューすることができる。

インタラクション（４）から（１０）は、オンデマンドコード実行システム１１０へのそれらの呼び出しのサブミッションを介して、メッセージストリーム１７２の個々のシャード１７４からの呼び出しを処理するために生じることができるそれらのインタラクションの例示である。インタラクション（４）から（１０）が特定のシャード１７４およびポーラーデバイス１３２に関して説明されているが、これらのインタラクションは、各シャード１７４の呼び出しを処理するために繰り返されることができる（例えば、少なくとも部分的に並列して動作する異なるポーラーデバイス１３２によって）。

具体的には、（４）において、ポーラーデバイス１３２は、ストリーム１７２のシャード１７４から１つ以上の次の呼び出しを取得する。場合によっては、ポーラーデバイス１３２は、シャード１７４から単一の呼び出しを取得することができる。他の例では、ポーラーデバイス１３２は、シャード１７４の次の１０、１００、または５００回の呼び出しなど、複数の呼び出しを取得することができる。参照を容易にするために、１つ以上の次の呼び出しは、本明細書では呼び出しの「バッチ」と称される。したがって、インタラクション（４）から（１０）は、図３にバッチループ３０４として指定される。これらのインタラクションは、例えば、所与のシャード１７４内に呼び出しが存在する間、繰り返されることができる。

上記のように、シャード１７４は、一般的に（そして潜在的に厳密に）先入れ先出し（「ＦＩＦＯ」）方式で例示的に動作した。したがって、インタラクション（１）から（３）はシャード１７４の「バック」に呼び出しを概念的にエンキューし、インタラクション（４）はシャード１７４の「フロント」から呼び出しを取得する。

その後、ポーラーデバイス１３２は、同期呼び出しループ３０６に入り、その間、処理のために受信したバッチからの個々の呼び出しをオンデマンドコード実行システム１００に渡し、その処理を反映する状態情報をポーラーデバイス１３２に維持する。具体的には、（５）において、ポーラーデバイス１３２は、現在のバッチ内の次のまだ処理されていない呼び出しをオンデマンドコード実行システム（例えば、フロントエンド１２０）にサブミットする。例示的には、ループ３０６の第一インスタンスにおいて、サブミットされた呼び出しは、シャード１７４にエンキューされる第一呼び出しであることができる。この呼び出しは、ＡＰＩ呼び出しなどを介して、システム１１０によって受け入れられる任意のサブミッションプロセスを介してサブミットされることができる。その後、（６）において、システム１１０は、図３にＶＭインスタンス１５０として示される実行環境に呼び出しを分散し、この実行環境中で、呼び出しを処理するために解析タスク１６４のコードを実行する。次に、（７）では、この環境内で解析タスク１６４を実行し、（８）では、その実行の結果をポーラーデバイス１３２に返す。

解析タスク１６４の実行を容易にするために、インタラクション（５）において、ポーラーデバイス１３２は、呼び出しに加えて、シャード１７４内のデータ項目の現在の処理状態を反映する状態情報を、オンデマンドコード実行システム１１０にサブミットする。ポーラーデバイス１３２は、状態情報をヌル値に初期化することができる。したがって、オンデマンドコード実行システム１１０への第一呼び出しは、ヌル値を含むことができる、または状態情報を除外することができる。（８）において返されるタスク実行の結果は、タスク実行を反映するために更新された新しい状態情報を含むことができる。（９）では、ポーラーデバイス１３２は、その現在の状態情報を新しい状態情報によって更新する（例えば、それ自体の状態情報を新しい状態情報と置き換えることによって）ことに続き、この更新された状態情報を、インタラクション（５）が繰り返される場合、次の呼び出しに渡すことができる。

インタラクション（５）から（１０）の具体例として、コーパス内の単語をカウントすることが意図されるＭａｐＲｅｄｕｃｅモデルの実装を検討する。そのようなシナリオでは、特定のシャード１７４内の各呼び出しは、データ項目としてコーパスの単語を含むことができる。ポーラーデバイス１３２は、シャード１７４についての単語がカウントされていないことを示すヌル値に、状態情報を最初に設定することができる。各呼び出しをオンデマンドコード実行システム１１０にサブミットする場合、実行環境は、現在の呼び出し内の単語に基づいてインクリメントされる現在のカウント値（例えば、最初はヌル）を反映する状態情報を返すことができる。したがって、「ａｐｐｌｅ」のデータ項目を用いる第一呼び出しは、「ａｐｐｌｅ」という単語の現在のカウントが「１」であることを示す、「｛ａｐｐｌｅ：１｝」の状態情報をもたらすことができる。第二呼び出しは、その状態情報、および「ｂａｌｌ」という単語の処理のための呼び出しを含むことができる。この呼び出しに関する解析タスク１６４の実行は、「｛ａｐｐｌｅ：１；ｂａｌｌ：１｝」の状態情報をもたらすことができる。このプロセスは、各タスクの実行によって返される状態情報が、ストリームのシャード１７４内の各呼び出しを処理することを表すように継続することができる。単純化された単語カウントの例が本明細書に提供されているが、当業者は、データ解析アプリケーションが実際には、さまざまな非常に複雑な解析を網羅することができることを理解するであろう。

図３では、ループ３０６は、同期呼び出しループとして指定され、この同期呼び出しループは、これらの例示的なインタラクションでは、解析タスク１６４の実行が完了した後にのみ、システム１１０への各呼び出しに対する応答が受信され、その実行の結果を含むことを示す。例えば、インタラクション（５）および（８）は、それぞれＨＴＴＰ呼び出しおよび応答を表すことができるため、「同期ＨＴＴＰ要求」と称されることができる。同期要求の使用は、ポーラーデバイス１３２と実行環境との間で状態情報を渡すために必要なコンピューティングリソースを有利にｒｅｄｕｃｅ処理することができる。なぜなら、そのような状態情報は、オンデマンドコード実行システム１１０がいかなる場合でも提供する要求および応答内で渡されることができるからである。したがって、例えば、タスク実行の状態情報をポーラーデバイス１３２に渡すために、追加のネットワーク接続を実行環境に必要としない。ただし、いくつかの実施形態では、非同期呼び出しがポーラーデバイス１３２によっても利用されることができることが企図される。例えば、ポーラーデバイス１３２は、シャード１７４からの呼び出しを処理する非同期要求をシステム１１０にサブミットすることができ、タスク実行は、実行環境にポーラーデバイス１３２との通信を開始させて、タスク実行についての状態情報を返させることができる。

データ解析がメッセージストリーム１７２の呼び出しの順序に依存する場合などのいくつかの実施形態では、ポーラーデバイス１３２がシステム１１０に次の呼び出しをサブミットする前に、呼び出しループ３６０は、各呼び出しをシステム１１０にサブミットして結果を受信する必要があるため、厳密に反復して発生する場合がある。他の例では、ポーラーデバイス１３２は、システム１１０に複数の呼び出しを同時にサブミットすることなどによって、少なくとも部分的に並列して呼び出しループ３０６を実装することができる。

上記を考慮して理解されるように、インタラクション（５）から（９）は、一般に、オンデマンドコード実行システム１１０による特定の実行環境への呼び出しのいかなる特定の分散にも依存しない。例えば、呼び出しループ３０６の各インスタンスは、呼び出しが異なる実行環境に分散される結果となる可能性がある。有利には、このコンフィグレーションは、メッセージストリーム１７２の処理状態に関するいかなる情報も維持する必要がないように、環境がステートレスに動作することを可能にする。ステートレス動作は、環境が適切な状態情報を含むかどうかに基づくのではなく、そのような環境に利用可能なコンピューティングリソースなどに基づいて環境に呼び出しを分散することによって、オンデマンドコード実行システム１１０がより効率的に動作することを可能にすることができる。このようにして、代替の状態メンテナンス解決策と比較して、全体的な効率が向上する。

上記に考察されるように、分散システム内の１つ以上のデバイスの不具合がシステム全体の動作に著しく影響しないように、分散システムがレジリエンスで動作することが一般的に望ましい。本発明のモデルでは、メッセージストリーム上にエンキューされるメッセージの冗長ストレージを提供することなどによって、メッセージストリーム１７２がほとんどの不具合のシナリオの下にレジリエンスで動作すると仮定する。同様に、異なる物理デバイス上に複数の実行環境を提供することなどによって、システム１１０全体がほとんどの不具合のシナリオの下にレジリエンスで動作すると仮定する。システム１１０が異なる（不具合のない）環境に例示的に分散することができる、解析タスク１６４を実行するためのいずれかの不具合のある呼び出しを再試行するようにポーラーデバイス１３２が構成されることができるので、各実行環境がレジリエンスを保証する必要は一般にない。実際には、レジリエンスを提供することがそのような環境を提供するために必要なコンピューティングリソースを一般に増加させるので、システム１１０上の個々の実行環境のレジリエンスを提供する努力をほとんど、または全く行わないことが望ましい場合がある。

メッセージストリーム１７２およびオンデマンドコード実行システムの仮定されているレジリエンスを考慮すると、データ解析タスクが多種多様な不具合のシナリオの下でさえ進行することができるように、ポーラーデバイス１３２もレジリエンスで動作することが望ましい場合がある。そのようなレジリエンスを提供するために、ポーラーデバイス１３２は、ストリーム１７２のシャード１７４の処理状態を反映する現在の状態情報を、ネットワークデータストレージサービス１０８などのレジリエンスのあるデータストアに定期的に、または時折書き込むことができる。これらの書き込みが「重い」動作であることが多いため、これらのような書き込みが実行可能な限り頻繁に発生しないことが一般的に望ましい。図３の例示的なインタラクションでは、書き込みは、バッチループ３０４の終了時にインタラクション（１０）で発生することが示されている。したがって、ポーラーデバイス１３２が呼び出しの各バッチを処理するときに、そのバッチ（および任意の以前のバッチ）の処理を反映する状態情報をデータストレージサービス１０８に書き込むことができる。状態情報は、例示的に、ポーラーデバイス１３２によって処理された最後の呼び出しも反映する。最後の呼び出しは、例えば、ストリーム１７２のシャード１７４内の位置を参照して指定されることができる。

ポーラーフリート１３０は、ポーラーデバイス１３２に不具合があることを検出した場合、新しいポーラーデバイス１３２を作成し、最新の状態情報をデータストレージサービス１０８に書き込むことによって初期化することができる。次に、新しいポーラーデバイス１３２は、呼び出しの次のバッチ（例えば、処理された状態情報に反映されていないシャード１７４の次のメッセージ）を取得し、不具合のあるポーラーデバイス１３２の動作を効率的に再開して、ポーラーデバイス１３２のレジリエンスのある動作を提供することができる。バッチループ３０４の各インスタンス中の呼び出しの数（「バッチサイズ」）に基づいて、データストレージサービス１０８への書き込みの頻度を制御することができるので、所望の動作に基づいてポーラーデバイス１３２の動作をチューニングすることができる（例えば、管理者またはエンドユーザによって）。例えば、バッチサイズが大きい結果、外部書き込みの頻度が低くなり、ポーラーデバイス１３２のコンピューティングリソース使用量が減少する可能性があるが、不具合のあるシナリオの下で繰り返される必要のある呼び出しの量が増加する可能性がある。逆に、バッチサイズが小さい結果、外部書き込みの頻度が高くなる可能性があるが、不具合のある中で繰り返される呼び出しが減少する可能性がある。いずれの場合でも、本開示の実施形態は、オンデマンドコード実行システム１１０などの他のコンポーネントの動作から独立して、このトレードオフを選択することを可能にする。

本明細書に記載のストリームデータ処理システム１７０の有利な態様は、その中のメッセージのボリュームに基づいてメッセージストリーム１７２の容量をスケーリングする機能であるため、データ解析動作中でさえ、データ解析タスクについての並列化の量での変動性を可能にする。例えば、メッセージストリーム１７２にエンキューされる呼び出しの量が増加することが原因で、ストリームのシャード１７４の数が増加するため、ストリーム１７２の容量が増加することができる。逆に、呼び出しの量が減少することが原因で、シャード１７４の数が減少することができる。ポーラーデバイス１３２がシャード１７４と１対１の対応関係によって構成されることができるので、ポーラーデバイス１３２は、これらの条件下で適切に状態情報を転送してデータ解析の中断を防ぐように構成されることができる。状態情報をポーラーデバイス１３２間で渡すことができる方法の例示的な例を図４および図５に示す。

具体的には、図４は、第一シャード１７４Ａを２つの新しいシャード、それぞれシャード１７４Ｂおよび１７４Ｃに「分割」する場合に、第一シャード１７４Ａに対応する第一ポーラーデバイス１３２Ａから状態情報を転送することができる方法を示す。説明を容易にするために、図４のシャード１７４Ａ～Ｃがデータセット内のデータ項目の頻度をカウントする、データ解析タスクへの呼び出しを反映すると仮定する。さらに、データセットが「ａ、ｂ、ａ、ｂ、ａ、ｂ」などの繰り返しパターン内の文字「ａ」および「ｂ」からなると仮定する（単純さのために）。最初のシャード１７４Ａは、ストリーム１７２を２つのシャード１７４Ｂおよび１７４Ｃに分割するまで、最初はストリーム１７２の唯一のシャードであると仮定される。この例示的な例では、データセットの文字をストリーム１７２についてのパーティションキーとして選択する。したがって、シャード１７４Ｂは一連の文字「ａ」を含み、シャード１７４Ｃは一連の文字「ｂ」を含む。ストリーム１７２が処理されるときに、これらの文字の正確なカウントを維持することが、データセットの解析にとって例示的に望ましい。したがって、例えば、ストリーム１７２の第一メッセージ（シャード１７４Ａのメッセージ番号１）は、文字「ａ」について１のカウントをもたらすはずである。ストリーム１７２の第二メッセージ（シャード１７４Ａのメッセージ番号２）は、文字「ａ」については１、文字「ｂ」については１などのカウントをもたらすはずである。

図４では、ポーラーデバイス１３２ごとの状態情報４０２は、状態情報によって示されるそれぞれのシャード１７４内のメッセージの処理（例えば、解析タスク１６４を介して）に続いて、それぞれのポーラーデバイス１３２より上に示される。したがって、状態情報４０２Ａは、シャード１７４Ａ上のメッセージ番号２の処理後に、ポーラーデバイス１３２Ａで維持される状態情報を示す。図４の状態情報は、解析されているデータ項目の識別子（「Ｉ」）、データ項目の値（例えば、カウント）、およびデータ項目の値が最後に変更されたメッセージストリーム１７２内の位置を含む３つの値のタプルとして示されている。したがって、図４では、シャード１７４のメッセージ２を処理した後のポーラーデバイス１３２の状態４０２Ａは、最後のカウントがシャード１７４Ａの第一メッセージを表す「Ａ１」で行われているので、データ項目「ａ」が「１」回カウントされた状態と、最後のカウントがシャード１７４Ａの第一メッセージを表す「Ａ２」で行われているので、データ項目「ｂ」が「１」回カウントされた状態とである。

図４では、シャード１７４Ａのメッセージ番号２の処理後、このシャードをシャード１７４Ｂおよび１７４Ｃに分割すると仮定する。したがって、シャード１７４Ｂのメッセージ１はシャード１７４Ａの最初はメッセージ３であったものを表し、シャード１７４Ｃのメッセージ１はシャード１７４Ａの最初はメッセージ４であったものを表すなど。各ポーラーデバイス１３２がシャード１７４と１対１の対応関係を有すると仮定する。したがって、ポーラーデバイス１３２Ｂおよび１３２Ｃがヌル状態情報によって初期化した場合、それらの現在の状態情報は、それらの関連するシャード１７４に含まれるそれらのデータ値に関してストリーム１７２の状態を正確に反映しない。すなわち、ポーラーデバイス１３２Ｂは、シャード１７４Ｂのメッセージ１上の「ａ」が、実際には第二であるのに、ストリーム１７２の第一「ａ」であることを示す状態情報を保持することができる。

このシナリオに対処するために、各ポーラーデバイス１３２は、このデバイスに対応するシャード１７４のホルト状態時に、それらの現在の状態情報を「子」シャード１７４に対応するポーラーデバイス１３２に利用可能にするように構成されることができる。例示的に、各ポーラーデバイス１３２は、それらの状態情報をデータストレージサービス１０８に書き込むように構成されることができる。初期化時に、各ポーラーデバイス１３２は、対応するシャード１７４が前のシャード１７４の子であるかどうかを決定するように構成されることができる。例示的には、ストリームデータ処理システム１７０は、この情報をポーラーフリート１３０に利用可能にすることができる。ポーラーデバイス１３２が子シャード１７４に対応する場合、ポーラーデバイス１３２は、その状態情報として、親シャード１７４に対応するポーラーデバイス１３２の保存された状態情報を初期化するように構成されることができる。したがって、図４では、ポーラーデバイス１３２Ｂおよび１３２Ｃのそれぞれは、それらのそれぞれのシャード１７４Ｂおよび１７４Ｃのメッセージを処理する前に、ポーラーデバイス１３２Ａの動作がストリーム１７２のメッセージを最後に処理したときに、ポーラーデバイス１３２Ａの状態情報４０２Ａが存在した場合、このポーラーデバイス１３２Ａの状態情報４０２Ａによって初期化された。そのため、ポーラーデバイス１３２Ｂの状態情報４０２Ｂは、シャード１７４Ｂのメッセージ１の時点で、合計２のカウントを文字「ａ」に割り当てることを反映する。同様に、ポーラーデバイス１３２Ｃの状態情報４０２Ｃは、シャード１７４Ｃのメッセージ１の時点で、合計２のカウントを文字「ｂ」に割り当てることを反映する。したがって、それぞれのデバイス１３２ＢおよびＣの状態情報は、それらが対応するシャード１７４にパーティション化されるそれらのデータ項目に関する正確な状態を反映する。

図４に見られるように、それぞれのシャード１７４にパーティション化されるデータ項目についての正確な値に加えて、ポーラーデバイス１３２ＢおよびＣについての状態情報は、それぞれのシャード１７４にパーティション化されていないそれらのデータ項目に関する期限切れの状態情報も含む。例えば、状態情報４０２Ｂは、データ項目「ｂ」がシャード１７４Ｂ内に含まれていないようにシャード１７４Ｂがストリーム１７２からパーティション化されたとしても、データ項目「ｂ」に値「１」を反映する。同様に、状態情報４０２Ｃは、データ項目「ａ」がシャード１７４Ｃ内に含まれていないようにシャード１７４Ｃがストリーム１７２からパーティション化されたとしても、データ項目「ａ」に値「１」を反映する。

この冗長性は、さまざまなポーラーデバイス１３２の状態情報に反映される値を重複排除するように、ポーラーデバイス１３２を設定すること、またはストリーム１７２内の呼び出しの全体的な処理結果を取得したいいずれかの他のデバイスを構成することによって対処される。具体的には、データ項目についての値を更新したストリーム１７２内の最後の位置を各データ項目タプルが含むため、最新の位置タプルをデータ項目についての権限として指定することによって重複排除が発生することができる。

状態情報を重複排除する例示的な一例を図５に示す。図４と同様に、図５は、ストリーム１７２内のデータ項目に各対応する、それぞれのシャード１７４ＢおよびＣでの呼び出しの処理を反映する、ポーラーデバイス１３２Ｂおよび１３２Ｃについての例示的な状態情報を示す。図５では、ポーラーデバイス１３２Ｂおよび１３２Ｃのそれぞれは、それらのそれぞれのシャード１７４上の追加メッセージの処理を容易にしたと想定されるため、状態情報４０２ＢおよびＣは、それらのそれぞれのシャード１７４上で第三メッセージを処理することを反映している。

図５の図解は、２つのシャード１７４を単一のシャード１７４にマージする場合に、複数のデバイス１３２からの状態情報を組み合わせることができる方法を示す。具体的には、図５において、シャード１７４Ａおよび１７４Ｂは、シャード１７４Ｄにマージされるように描かれ、このシャード１７４Ｄは、シャード１７４Ａおよび１７４Ｂの子とみなされることができる。図４に記述されているように、それらのそれぞれのシャード１７４のホルト状態時に、ポーラーデバイス１３２Ｂおよび１３２Ｃのそれぞれは、それらの状態情報を、子シャード１７４Ｄに対応するポーラーデバイス１３２Ｄに渡すように構成されることができる。ただし、上記のインタラクションが原因で、状態情報４０２Ｂおよび４０２Ｃは、各データ項目「ａ」および「ｂ」について２つの潜在的な値を有する冗長な情報を含む。

冗長な情報を除去するために、ポーラーデバイス１３２Ｄは、各親シャードについて受信する状態情報を、各データ項目タプルの第三値によって図５に反映されるように、メッセージストリーム１７２内の最新の位置の値を含む、権限のある状態情報として取得することによって、重複排除するように構成される。したがって、位置の値「Ｂ３」（またはシャードＢのメッセージ３）を有する状態情報４０２Ｂからのもの、および位置の値「Ａ１」を有する状態情報４０２Ｃからのものという、データ項目「ａ」についての２つのタプルを比較する場合、ポーラーデバイス１３２Ｄは、シャード１７４Ｂがシャード１７４Ａの子であり、したがって、ストリーム１７２内のより後の位置であるため、状態情報４０２Ｂがデータ項目「ａ」について権限があると決定する。ポーラーデバイス１３２Ｄは、ストリーム１７２のシャード１７４間の関係を決定するために、必要に応じて、ストリームデータ処理システム１７０から祖先データを例示的に受信することができる。同様のプロセスを通じて、ポーラーデバイス１３２Ｄは、状態情報４０２Ｃがデータ項目「ｂ」についての値を表すと決定することができる。したがって、状態情報４０２Ｄは、シャード１７４Ｄの初期化の時点での両方のデータ項目についてのカウントの重複排除された正確な記録を反映する。

簡略化された例が上述されているが、当業者は、本開示を考慮して、ポーリングデバイス１３２間の状態情報の共有、およびそのような情報の重複排除によって、ポーリングデバイス１３２がそれらの対応するシャード１７４にパーティション化されるデータ項目に少なくとも関連して正確な値を維持することが可能でありながら、ストリーム１７２のシャード１７４の数に対する任意の数の変更が容易にされることができることを理解するであろう。さらに、状態情報を重複排除するための１つの技法が上記に考察されているが、他のものが本開示内で企図されている。例えば、データ項目の値が一方向にのみ変化することがわかっている状況（例えば、増加することしかできないカウント）では、データ項目について重複している値は、その方向の中で最も遠い値（例えば、最大カウント）を権限のあるものとみなすことによって重複排除されることができる。このようにして、重複排除は、維持される値ごとの位置を必要とせずに発生することができる。別の例として、シャード内の位置情報に加えて、またはその代替として、処理されている個々のデータ項目について他の順序付け情報を含むことができる。例えば、状態情報は、メッセージストリーム全体（例えば、複数のシャード全体）の絶対位置識別子を含むことができる、または順序付きメッセージに対応するタイムスタンプ情報を含むことができる。タイムスタンプ情報は、例えば、メッセージがメッセージストリームにエンキューされた時刻を含むことができる。したがって、状態情報についてのタイムスタンプ値が高いほど、メッセージストリーム内でより後のメッセージを処理する状態を状態情報が表すことを識別することができ、またメッセージストリーム内でより初期のメッセージを処理する状態を表す状態情報にわたって権限があるとみなされることができる。

図６を参照して、データセットを表すメッセージストリーム１７２上のメッセージ（例えば、データ項目を識別する呼び出し）の処理状態を反映する状態情報をポーラーデバイス１３２に維持するための、例示的なルーティン６００を示すブロック図を記述する。ルーティン６００は、メッセージストリーム１７２のシャード１７４に対応するポーラーデバイス１３２に例示的に実装されることができる。

ルーティン６００は、ブロック６０２で始まり、ブロック６０２では、ポーラーデバイス１３２は、シャード１７４に関連する、関連のある以前の状態情報を取得する。例示的に、以前のポーラーデバイス１３２がシャード１７４を処理していて不具合があった場合、現在のポーラーデバイス１３２は、以前のポーラーデバイス１３２の状態情報を取得し、シャード１７４の処理を、以前のポーラーデバイス１３２の状態情報に反映された最後の位置から再開することができる。さらなる例示として、シャード１７４が１つ以上の以前のシャード１７４の子である場合、ポーラーデバイス１３２は、シャード１７４の親に対応するポーラーデバイス１３２の状態情報を取得して採用することができる。例示的に、初期化時に、ポーラーデバイス１３２は、ストリームデータ処理システム１７０にクエリを行い、シャード１７４がいずれかの親シャード１７４を含むかどうかを識別することができる。そうである場合、ポーラーデバイス１３２は、データストレージサービス１０８などから、それらの親シャード１７４についての状態情報を取得することができる。親シャード１７４が存在しない場合、ポーラーデバイス１３２は、状態情報を、デバイス１３２のコンフィグレーション上に確立されているヌル値または所定の値に初期化することができる。

ブロック６０４では、ポーラーデバイス１３２は、いずれかの重複している情報が存在する場合、親シャードの状態情報を重複排除する。上記のように、重複排除は、所与のデータ項目について権限のあるものとして、メッセージストリーム１７２内の最も遠い位置に関連する値を取得することを含むことができる。

ブロック６０６では、ポーラーデバイス１３２は、図３を参照して上述されるように、バッチループ３０４に入り、ブロック６０６では、シャード１７４から呼び出しのバッチを取得する。各呼び出しは、シャード１７４にエンキューされるメッセージに対応し、解析されるデータセットからデータ項目を識別する、またはそのデータ項目を含むことができる。ブロック６０６において取得される呼び出しの数は、バッチループ３０４の所望の頻度に従って変えることができる。例示的に、呼び出しのバッチは、５００回の呼び出しを含むことができる。

ブロック６０８では、ポーラーデバイス１３２は、同期呼び出しループ３０６に入り、ポーラーデバイス１３２に維持されている現在の状態情報とともに、現在のバッチからの次の呼び出しをオンデマンドコード実行システム１１０にサブミットする。上記のように、状態情報を渡すことにより、システム１１０によって任意の適切な実行環境に呼び出しをルーティングすることができる。この呼び出しを、例えば、同期ＨＴＴＰ要求としてサブミットすることができる。

ブロック６１０では、ポーラーデバイス１３２は、新しい状態情報を含む、呼び出しへの応答を取得する。新しい状態情報は、オンデマンドコード実行システム１１０上での解析タスク１６４の実行によって更新された、呼び出し内に渡される状態情報を例示的に表す。したがって、ポーラーデバイス１３２は、シャード内で識別されるデータ項目の処理状態を反映するものとして、新しい状態情報を権限のあるものとみなすことができる。

ブロック６１２では、オンデマンドコード実行システムにサブミットされていない追加の呼び出しがバッチ内に存在する場合、ルーティン６００はブロック６０８に戻る。あるいは、ルーティン６００はブロック６１４に進む。ブロック６１４では、ポーラーデバイス１３２は、現在の状態情報をレジリエンスのあるネットワークデータストレージサービスに書き込むことなどによって、その状態をチェックポイントする。上記のように、ルーティン６００の実装中にポーラーデバイス１３２が不具合を起こした場合、後続のポーラーデバイス１３２は、状態情報を利用して、シャード１７４の処理を再開することができる。

ブロック６１６では、シャード１７４内に追加の呼び出しが存在する場合、ルーティン６００はブロック６０６に戻る。あるいは、シャード内のすべての呼び出しが処理された場合、シャードの処理は完了したとみなされることができ、ポーラーデバイス１３２の最後に書き込まれた状態情報は、シャード１７４上のすべてのデータ項目の処理を表す。したがって、ルーティン６００は、ブロック６１８で終了することができる。

上述の方法およびプロセスのすべては、１つ以上のコンピュータまたはプロセッサで実装されてよく、１つ以上のコンピュータまたはプロセッサによって実行されるソフトウェアコードモジュールを介して完全に自動化されてよい。コードモジュールは、任意の種類の非一過性のコンピュータ可読媒体または他のコンピュータストレージデバイス内に記憶され得る。本方法の一部またはすべては、代わりに専用コンピュータハードウェアで実装され得る。

特に明記しない限り、とりわけ、「できる（ｃａｎ）」、「できるであろう（ｃｏｕｌｄ）」、「可能性がある（ｍｉｇｈｔ）」、または「してよい（ｍａｙ）」等の条件的言語は、他の実施形態が特定の特徴、要素および／またはステップを含まない一方で、特定の実施形態が特定の特徴、要素および／またはステップを含むことを提示するために一般的に使用される文脈内で別様に理解される。したがって、そのような条件的言語は、概して、特徴、要素、および／またはステップが、１つ以上の実施形態に任意の方法で要求されるか、または１つ以上の実施形態が、ユーザ入力もしくはプロンプトを用いて、もしくは用いずに、これらの特徴、要素、および／またはステップが含まれるか、もしくは任意の特定の実施形態で行われるべきであるかを決定するための論理を必ず含むことを含意することは意図していない。

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

特に明記しない限り、「ａ」または「ａｎ」等の冠詞は、概して、１つ以上の記載された項目を含むと解釈すべきである。したがって、「～するように構成された装置」等の語句は、１つ以上の列挙された装置を含むことを意図している。そのような１つまたは複数の列挙された装置は、記載された列挙を実行するように集合的に構成されることもできる。例えば、「列挙Ａ、ＢおよびＣを実行するように構成されたプロセッサ」は、列挙ＢおよびＣを実行するように構成された第２のプロセッサと連動して機能し、列挙Ａを実行するように構成された第１のプロセッサを含む場合がある。

本明細書に説明する、および／または添付の図面に図示するフロー図のいずれのルーティンの記述、要素、またはブロックも、ルーティンにおける特定の論理的機能または要素を実装するための１つまたは複数の実行可能な命令を含む、モジュール、セグメント、またはコードの部分を潜在的に表すものとして理解されるべきである。代替の実施態様は、本明細書に説明される実施形態の範囲内に含まれ、その中で要素または機能は、当業者によって理解されるであろうように、関係する機能性に応じて、実質的に同時または逆の順序を含む、示されるものまたは説明されるものとは異なる順序で削除または実行され得る。

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

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

条項１．メッセージストリーム内にエンキューされるメッセージの処理状態を表す状態情報を維持するシステムであって、
前記メッセージストリームを維持するストリームデータ処理システムであって、前記メッセージストリーム内の個別のメッセージはデータセット内の個別のデータ項目を処理するユーザ指定コードを呼び出す要求に対応する、前記ストリームデータ処理システムと、
前記ユーザ指定コードを呼び出す前記要求を取得するように、そして個別の要求について、前記ユーザ指定コードを実行するオンデマンドコード実行システムの実行環境を選択するように構成される、前記オンデマンドコード実行システムと、
ポーラーデバイスであって、前記ポーラーデバイスはコンピュータ実行可能命令によって、
前記メッセージストリーム内にエンキューされる前記メッセージの処理状態を表す前記状態情報を初期化することと、
前記メッセージストリームからメッセージセットを取得することと、
前記メッセージセット内のメッセージごとに、
前記メッセージストリーム内にエンキューされる前記メッセージの処理状態を表す前記状態情報と、前記メッセージに対応する前記要求とを前記オンデマンドコード実行システムに送信することであって、前記要求は前記メッセージによって識別される前記個別のデータ項目を処理する前記ユーザ指定コードの呼び出しを要求する、前記送信することと、
前記個別のデータ項目の処理結果を含む呼び出しへの応答を受信することであって、前記個別のデータ項目の前記処理結果は前記メッセージストリーム内にエンキューされる前記メッセージの処理状態に少なくとも部分的に基づく、前記受信することと、
前記応答に少なくとも部分的に基づいて前記状態情報を更新することと、
を行うように構成される、前記ポーラーデバイスと、
を含む、前記システム。

条項２．前記オンデマンドコード実行システムは、ＭａｐＲｅｄｕｃｅプログラミングモデルのｍａｐ段階として前記メッセージストリーム内に前記個別のメッセージをエンキューするｍａｐタスクの複数の実行を実装するようにさらに構成され、前記ユーザ指定コードは、前記ＭａｐＲｅｄｕｃｅプログラミングモデルのｒｅｄｕｃｅ段階を実装する、条項１に記載のシステム。

条項３．前記メッセージストリームは、複数のメッセージシャードに分割され、前記メッセージストリーム内の前記個別のメッセージは、前記データ項目に従って前記複数のメッセージシャード間に分散され、前記ポーラーデバイスは、前記メッセージセットが取得される前記複数のシャードのうちの第一シャードに対応し、前記状態情報は、前記第一シャード内のメッセージの処理状態を表す、条項１に記載のシステム。

条項４．コンピュータ実行可能命令によって、
前記複数のシャードのうちの第二メッセージシャード内にエンキューされるメッセージの処理状態を表す第二状態情報を初期化することと、
前記第二メッセージシャードから第二メッセージセットを取得することと、
前記第二メッセージセット内のメッセージごとに、
前記第二メッセージシャード内にエンキューされる前記メッセージの処理状態を表す前記状態情報と、前記メッセージに対応する前記要求とを前記オンデマンドコード実行システムに送信することであって、前記要求は前記メッセージによって識別される前記個別のデータ項目を処理する前記ユーザ指定コードの前記呼び出しを要求する、前記送信することと、
前記個別のデータ項目の処理結果を含む前記要求への応答を受信することであって、前記個別のデータ項目の前記処理結果は前記第二メッセージシャード内にエンキューされる前記メッセージの処理状態に少なくとも部分的に基づく、前記受信することと、
前記応答に少なくとも部分的に基づいて前記第二メッセージシャード内にエンキューされる前記メッセージの処理状態を表す前記状態情報を更新することと、
を行うように構成される、
第二ポーラーデバイスをさらに含む、条項３に記載のシステム。

条項５．
メッセージストリーム内にエンキューされるメッセージの処理状態を表す状態情報を初期化することであって、前記メッセージストリーム内の個別のメッセージは、データセット内の個別のデータ項目を処理するユーザ指定コードをオンデマンドコード実行システムで実行する要求に対応する、前記初期化することと、
前記メッセージストリームからメッセージセットを取得することと、
前記メッセージセット内のメッセージごとに、
前記メッセージストリーム内にエンキューされる前記メッセージの処理状態を表す前記状態情報と、前記メッセージに対応する前記要求とを前記オンデマンドコード実行システムに送信することであって、前記要求は前記メッセージによって識別される前記個別のデータ項目を処理する前記ユーザ指定コードの呼び出しを要求する、前記送信することと、
前記個別のデータ項目の処理結果を含む前記要求への応答を受信することであって、前記個別のデータ項目の前記処理結果は前記メッセージストリーム内にエンキューされる前記メッセージの処理状態に少なくとも部分的に基づく、前記受信することと、
前記応答に少なくとも部分的に基づいて前記状態情報を更新することと、
を含む、コンピュータ実装方法。

条項６．前記状態情報を初期化することは、データストアから１つ以上の過去の状態情報インスタンスを取得すること、および前記１つ以上の過去の状態情報インスタンスに少なくとも部分的に基づいて前記状態情報を初期化することを含む、条項５に記載のコンピュータ実装方法。

条項７．前記メッセージストリームは、複数のメッセージシャードに分割され、前記１つ以上の過去の状態情報インスタンスは、不具合のあるデバイスからの状態情報を含む、条項６に記載のコンピュータ実装方法。

条項８．前記メッセージストリームは、複数のメッセージシャードに分割され、前記メッセージセットは、前記複数のメッセージシャードのうちの第一シャードから取得され、前記１つ以上の過去の状態情報インスタンスは、前記第一シャードに対する１つ以上の親シャード内にエンキューされるメッセージを処理するデバイスからの状態情報を含む、条項６に記載のコンピュータ実装方法。

条項９．前記１つ以上の親シャードは、少なくとも２つの親シャードを含み、前記コンピュータ実装方法は、前記少なくとも２つの親シャードの状態情報を重複排除することをさらに含む、条項８に記載のコンピュータ実装方法。

条項１０．前記少なくとも２つの親シャードの前記状態情報は、前記少なくとも２つの親シャードの前記状態情報内の個別のデータ項目について、前記個別のデータ項目についての値が変更された、前記メッセージストリーム内の最後の位置を示す、条項９に記載のコンピュータ実装方法。

条項１１．前記メッセージセット内の各メッセージに対応する呼び出しごとに応答を受信することに続いて、前記状態情報をデータストアに書き込むことをさらに含む、条項５に記載のコンピュータ実装方法。

条項１２．前記コンピュータ実装方法の少なくとも一部分を実装するデバイスに不具合を検出すること、および前記状態情報を前記データストアから取得して前記コンピュータ実装方法の前記少なくとも一部分の実装を再開することをさらに含む、条項１１に記載のコンピュータ実装方法。

条項１３．コンピュータ実行可能命令を含む非一時的なコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、コンピューティングシステムによって実行されるとき、前記コンピューティングシステムに、
メッセージストリーム内にエンキューされるメッセージの処理状態を表す状態情報を初期化することであって、前記メッセージストリーム内の個別のメッセージは、データセット内の個別のデータ項目を処理するユーザ指定コードをオンデマンドコード実行システムで実行する要求に対応する、前記初期化することと、
前記メッセージストリームからメッセージセットを取得することと、
前記メッセージセット内のメッセージごとに、
前記メッセージストリーム内にエンキューされる前記メッセージの処理状態を表す前記状態情報と、前記メッセージに対応する前記要求とを前記オンデマンドコード実行システムに送信することであって、前記要求は前記メッセージによって識別される前記個別のデータ項目を処理する前記ユーザ指定コードの呼び出しを要求する、前記送信することと、
前記個別のデータ項目の処理結果を含む前記要求への応答を受信することであって、前記個別のデータ項目の前記処理結果は前記メッセージストリーム内にエンキューされる前記メッセージの処理状態に少なくとも部分的に基づく、前記受信することと、
前記応答に少なくとも部分的に基づいて前記状態情報を更新することと、
を引き起こす、前記非一時的なコンピュータ可読媒体。

条項１４．同期ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求は、前記状態情報および前記呼び出しを前記オンデマンドコード実行システムに送信するために使用される、条項１３に記載の非一時的なコンピュータ可読媒体。

条項１５．前記応答は前記ＨＴＴＰ要求へのＨＴＴＰ応答である、条項１４に記載の非一時的なコンピュータ可読媒体。

条項１６．前記ユーザ指定コードは、前記ユーザ指定コードを実行する呼び出しから独立して前記オンデマンドコード実行システムに維持される状態情報を参照することなく、ステートレスに前記オンデマンドコード実行システムで実行する、条項１４に記載の非一時的なコンピュータ可読媒体。

条項１７．前記状態情報を初期化するために、前記コンピュータ実行可能命令は、前記システムに、データストアから１つ以上の過去の状態情報インスタンスを取得すること、および前記１つ以上の過去のインスタンスに少なくとも部分的に基づいて前記状態情報を初期化することを引き起こす、条項１３に記載の非一時的なコンピュータ可読媒体。

条項１８．前記メッセージストリームは、複数のメッセージシャードに分割され、前記１つ以上の過去の状態情報インスタンスは、不具合のあるデバイスからの状態情報を含む、条項１３に記載の非一時的なコンピュータ可読媒体。

条項１９．前記メッセージストリームは、複数のメッセージシャードに分割され、前記メッセージセットは、前記複数のメッセージシャードのうちの第一シャードから取得され、前記１つ以上の過去の状態情報インスタンスは、前記第一シャードに対する１つ以上の親シャード内にエンキューされるメッセージを処理するデバイスからの状態情報を含む、条項１３に記載の非一時的なコンピュータ可読媒体。

条項２０．前記１つ以上の親シャードは、少なくとも２つの親シャードを含み、前記非一時的なコンピュータ可読媒体は、前記少なくとも２つの親シャードの前記状態情報を重複排除する、前記コンピューティングシステムによって実行可能なコンピュータ実行可能命令をさらに含む、条項１９に記載の非一時的なコンピュータ可読媒体。

条項２１．前記コンピュータ実行可能命令は、前記システムに、前記メッセージセット内の第一メッセージに対応する第一要求と、前記メッセージセット内の第二メッセージに対応する第二要求とを、前記オンデマンドコード実行システムに同時に送信することを引き起こす、条項１９に記載の非一時的なコンピュータ可読媒体。

Claims (15)

1. メッセージストリーム内にエンキューされるメッセージの処理状態を表す状態情報を維持するシステムであって、前記システムは、
   ストリームデータ処理システムと、
   オンデマンドコード実行システムと、
   ポーラーデバイスと、
   を含み、
   前記ストリームデータ処理システムは、前記メッセージストリームを維持し、前記メッセージストリーム内の個別のメッセージは、データセット内の個別のデータ項目を処理するユーザ指定コードを呼び出す呼び出しに対応し、
   前記オンデマンドコード実行システムは、前記呼び出しを取得するように構成され、
   前記ポーラーデバイスは、コンピュータ実行可能命令によって、
   前記メッセージストリーム内にエンキューされる前記メッセージの処理状態を表す前記状態情報を初期化し、
   前記メッセージストリームからメッセージセットを取得し、
   前記メッセージセット内のメッセージごとに、
   前記メッセージストリーム内にエンキューされる前記メッセージの処理状態を表す前記状態情報と前記メッセージに対応する前記呼び出しとを前記オンデマンドコード実行システムに送信し、前記呼び出しは、前記メッセージによって識別される前記個別のデータ項目を処理する前記ユーザ指定コードの呼び出しに対応し、
   前記個別のデータ項目の処理結果を含む呼び出しへの応答を受信し、前記個別のデータ項目の前記処理結果は、前記メッセージストリーム内にエンキューされる前記メッセージの処理状態に少なくとも部分的に基づき、
   前記応答に少なくとも部分的に基づいて前記状態情報を更新する、
   ように構成される、
   システム。
2. 前記オンデマンドコード実行システムは、ＭａｐＲｅｄｕｃｅプログラミングモデルのｍａｐ段階として前記メッセージストリーム内に前記個別のメッセージをエンキューするｍａｐタスクの複数の実行を実装するようにさらに構成され、
   前記ユーザ指定コードは、前記ＭａｐＲｅｄｕｃｅプログラミングモデルのｒｅｄｕｃｅ段階を実装する、
   請求項１に記載のシステム。
3. 前記メッセージストリームは、複数のメッセージシャードに分割され、
   前記メッセージストリーム内の前記個別のメッセージは、前記データ項目に従って前記複数のメッセージシャード間に分散され、
   前記ポーラーデバイスは、前記メッセージセットが取得される前記複数のメッセージシャードのうちの第一シャードに対応し、
   前記状態情報は、前記第一シャード内のメッセージの処理状態を表す、
   請求項１に記載のシステム。
4. 前記システムは、第二ポーラーデバイスをさらに含み、前記第二ポーラーデバイスは、コンピュータ実行可能命令によって、
   前記複数のメッセージシャードのうちの第二メッセージシャード内にエンキューされるメッセージの処理状態を表す第二状態情報を初期化し、
   前記第二メッセージシャードから第二メッセージセットを取得し、
   前記第二メッセージセット内のメッセージごとに、
   前記第二メッセージシャード内にエンキューされる前記メッセージの処理状態を表す前記状態情報と前記メッセージに対応する前記呼び出しとを前記オンデマンドコード実行システムに送信し、前記呼び出しは、前記メッセージによって識別される前記個別のデータ項目を処理する前記ユーザ指定コードの呼び出しに対応し、
   前記個別のデータ項目の処理結果を含む前記呼び出しへの応答を受信し、前記個別のデータ項目の前記処理結果は、前記第二メッセージシャード内にエンキューされる前記メッセージの処理状態に少なくとも部分的に基づき、
   前記応答に少なくとも部分的に基づいて前記第二メッセージシャード内にエンキューされる前記メッセージの処理状態を表す前記状態情報を更新する、
   ように構成される、
   請求項３に記載のシステム。
5. コンピュータにより実装されるコンピュータ実装方法において、
   メッセージストリーム内にエンキューされるメッセージの処理状態を表す状態情報を前記コンピュータにより初期化するステップであって、前記メッセージストリーム内の個別のメッセージは、データセット内の個別のデータ項目を処理するユーザ指定コードをオンデマンドコード実行システムで実行する呼び出しに対応するステップと、
   前記メッセージストリームからメッセージセットを前記コンピュータにより取得するステップと、
   前記メッセージセット内のメッセージごとに、
   前記メッセージストリーム内にエンキューされる前記メッセージの処理状態を表す前記状態情報と前記メッセージに対応する前記呼び出しとを前記オンデマンドコード実行システムに前記コンピュータにより送信するステップであって、前記呼び出しは、前記メッセージによって識別される前記個別のデータ項目を処理する前記ユーザ指定コードの呼び出しに対応するステップと、
   前記個別のデータ項目の処理結果を含む前記呼び出しへの応答を前記コンピュータにより受信するステップであって、前記個別のデータ項目の前記処理結果は、前記メッセージストリーム内にエンキューされる前記メッセージの処理状態に少なくとも部分的に基づくステップと、
   前記応答に少なくとも部分的に基づいて前記状態情報を前記コンピュータにより更新するステップと、
   を含むコンピュータ実装方法。
6. 前記状態情報を初期化するステップは、
   データストアから１つ以上の過去の状態情報インスタンスを前記コンピュータにより取得するステップと、
   前記１つ以上の過去の状態情報インスタンスに少なくとも部分的に基づいて前記状態情報を前記コンピュータにより初期化するステップと、
   を含む、
   請求項５に記載のコンピュータ実装方法。
7. 前記メッセージストリームは、複数のメッセージシャードに分割され、
   前記１つ以上の過去の状態情報インスタンスは、不具合のあるデバイスからの状態情報を含む、
   請求項６に記載のコンピュータ実装方法。
8. 前記メッセージストリームは、複数のメッセージシャードに分割され、
   前記メッセージセットは、前記複数のメッセージシャードのうちの第一シャードから取得され、
   前記１つ以上の過去の状態情報インスタンスは、前記第一シャードに対する１つ以上の親シャード内にエンキューされるメッセージを処理するデバイスからの状態情報を含む、
   請求項６に記載のコンピュータ実装方法。
9. 前記１つ以上の親シャードは、少なくとも２つの親シャードを含み、
   前記コンピュータ実装方法は、前記少なくとも２つの親シャードの状態情報を前記コンピュータにより重複排除するステップをさらに含む、
   請求項８に記載のコンピュータ実装方法。
10. 前記少なくとも２つの親シャードの前記状態情報は、前記少なくとも２つの親シャードの前記状態情報内の個別のデータ項目について、前記個別のデータ項目についての値が変更された、前記メッセージストリーム内の最後の位置を示す、
    請求項９に記載のコンピュータ実装方法。
11. 前記コンピュータ実装方法は、前記メッセージセット内の各メッセージに対応する呼び出しごとに応答を前記コンピュータにより受信するステップに続いて、前記状態情報をデータストアに前記コンピュータにより書き込むステップをさらに含む、
    請求項５に記載のコンピュータ実装方法。
12. 前記コンピュータ実装方法は、
    前記コンピュータ実装方法の少なくとも一部分を実装するデバイスに不具合を前記コンピュータにより検出するステップと、
    前記状態情報を前記データストアから取得して前記コンピュータ実装方法の前記少なくとも一部分の実装を前記コンピュータにより再開するステップと、
    をさらに含む、
    請求項１１に記載のコンピュータ実装方法。
13. 前記オンデマンドコード実行システムに前記状態情報および前記呼び出しを送信するステップは、同期ハイパーテキスト転送プロトコル（ＨＴＴＰ）要求を前記オンデマンドコード実行システムに前記コンピュータにより送信するステップを含む、
    請求項５に記載のコンピュータ実装方法。
14. 前記応答は、前記ＨＴＴＰ要求へのＨＴＴＰ応答である、
    請求項１３に記載のコンピュータ実装方法。
15. 前記ユーザ指定コードは、前記ユーザ指定コードを実行する呼び出しから独立して前記オンデマンドコード実行システムに維持される状態情報を参照することなく、ステートレスに前記オンデマンドコード実行システムで実行する、
    請求項５に記載のコンピュータ実装方法。

Images