JP2024515247A - 構成可能なエッジデバイスプラットフォーム - Google Patents

Abstract

本明細書で議論される技術は、構成可能なエッジデバイスの提供に関する。いくつかの実施形態において、クラウドコンピューティングエッジデバイスにおいて実行すべきサービスセットを指定するユーザ要求は、クラウドコンピューティングプロバイダによって動作されるコンピューティングデバイスによって受信され得る。マニフェストは、ユーザ要求に従って生成され得る。当該マニフェストは、クラウドコンピューティングエッジデバイスの構成を指定し得る。別のエッジデバイスで実行すべきサービスの同じセットまたは異なるセットを指定する別の要求が受信され得る。当該エッジデバイスのための構成を指定する別のマニフェストが生成され、その後、当該デバイス上のサービスの要求セットをプロビジョニングするために使用され得る。このように、マニフェストは、任意の所与のエッジデバイスで利用すべきプラットフォームを構成するために使用され得る。

Description

関連出願の相互参照
本願は、２０２１年１１月１９日に出願された、「Composable Edge Device Platforms（構成可能なエッジデバイスプラットフォーム）」と題する米国特許出願第１７／５３１，６３２号、および２０２１年４月９日に出願された、「Cloud Computing Edge Computing Device（Rover）（クラウドコンピューティング・エッジコンピューティングデバイス（Rover））」と題する米国特許仮出願第６３／１７３，２４４号の優先権を主張し、これらの開示内容は、あらゆる目的で、引用により本明細書に援用する。

技術分野
本開示は、一般に、エッジデバイスプラットフォームに関する。より具体的には、本開示は、当該デバイスの構成を指定する、対応するマニフェストを利用して、これらのプラットフォームを構成することに関する。

背景
クラウドコンピューティングでは、処理および格納は、一般に、集中ロケーションで実装された１つ以上のサービスプロバイダによって実行される。データを、集中ロケーションにおいて顧客から受信し、そこで処理することができ、その後、処理された（または他の）データを、顧客に送信して返すことができる。しかしながら、クラウドインフラストラクチャコンポーネントの集中ロケーションを有することは、さまざまなシナリオにおいて理想的でない場合がある。たとえば、中央サーバにデータを送信するＩｏＴ（Internet of Things）デバイスが何百または何千とあり、特にそれらのＩｏＴデバイスがクラウドインフラストラクチャ・コンピューティングデバイスに地理的に近くない場合、従来の集中型システムは理想的ではない。これらのＩｏＴデバイスは、中央サーバに近くないという意味で、「エッジ」にあると考えられる。

さらに、クラウドコンポーネントにとって集中ロケーションが理想的でない場合もある。たとえば、データが切断された地域またはインターネット接続のない場所（たとえば遠隔地）において（たとえばＩｏＴデバイスによって）収集される場合である。現在の集中型クラウドコンピューティング環境では、広域ネットワーク接続に固有のレイテンシがあるため、データのストリーミング時に時間感度の要件を満たせない場合がある。リモートで生成されたデータは、（たとえば、異常を検出するために）従来の集中型クラウドコンピューティングシステムが可能にするよりも迅速に処理しなければならない場合がある。このように、集中型コンポーネントに依存する従来のクラウドコンピューティング環境を管理することには課題がある。たとえば、集中型ワークフローマネージャは、地理的に離れたデバイスのワークフローを管理するには最適ではない可能性もある。

簡潔な概要
クラウドインフラストラクチャ・エッジコンピューティングデバイス（たとえば、集中データセンターから分離され、パブリック／プライベートネットワーク接続のないリモートロケーションでコンピューティングおよびストレージを提供するように構成されたコンピューティングデバイス）などのさまざまなプラットフォームを構成するための技術（たとえば、方法、システム、１つ以上のプロセッサによって実行可能なコードまたは命令を格納した非一時的なコンピュータ読取可能媒体）が提供される。いくつかの実施形態において、これらのプラットフォームを構成することは、当該デバイスのための構成を指定する、対応するマニフェストを利用し得る。本明細書では、方法、システム、１つ以上のプロセッサによって実行可能なプログラム、コード、または命令を格納した非一時的なコンピュータ読取可能記憶媒体を含む、さまざまな実施形態について記載する。

一実施形態は、クラウドインフラストラクチャ・エッジコンピューティングデバイス（簡潔にエッジデバイスと呼ばれることもある）のプラットフォームを構成するための方法に関する。方法は、クラウドコンピューティングプロバイダによって動作されるコンピューティングデバイスが、第１のクラウドコンピューティングエッジデバイスにおいて実行すべき第１のサービスセットを指定する第１のマニフェストを含む第１のユーザ要求を受信することを含み得る。いくつかの実施形態において、クラウドコンピューティングエッジデバイスは、パブリックネットワークへのアクセスがない隔離されたコンピューティング環境内で実行されている間、隔離されたコンピューティング環境内で選択的に実行されるように構成されたデバイスであり得る。方法はさらに、第１のクラウドコンピューティングエッジデバイスにおいて実行すべき第１のサービスセットに対応する第１のコンテナ画像セットを取得することを含み得る。方法はさらに、第１のユーザ要求に従って、第１のクラウドコンピューティングエッジデバイスに、第１のコンテナ画像セットを含むコンテナをプロビジョニングすることを含み得る。方法はさらに、第２のクラウドコンピューティングエッジデバイスにおいて実行すべき第２のサービスセットを指定する第２のマニフェストを含む第２のユーザ要求を受信することを含み得る。方法はさらに、メモリから、第２のクラウドコンピューティングエッジデバイスにおいて実行すべき第２のサービスセットに対応する第２のコンテナ画像セットを取得することを含み得る。方法はさらに、第２のユーザ要求に従って、第２のクラウドコンピューティングエッジデバイスに、第２のコンテナ画像セットを含む第２のコンテナセットをプロビジョニングすることを含み得る。いくつかの実施形態において、第２のクラウドコンピューティングエッジデバイスに、第１のクラウドコンピューティングエッジデバイスにおいてプロビジョニングされるサービスと同じまたは異なるサービスがプロビジョニングされ得る。

いくつかの実施形態において、コンピューティングデバイスが開示される。コンピューティングデバイスは、１つ以上のプロセッサと、１つ以上のプロセッサによって実行されると、コンピューティングデバイスに上記の段落に開示された方法を実行させる実行可能命令で構成された１つ以上のメモリとで構成され得る。

いくつかの実施形態は、コンピューティングデバイスの１つ以上のプロセッサによって実行されると、コンピューティングデバイスに本明細書に開示された方法を実行させるコンピュータ実行可能命令を含む非一時的なコンピュータ読取可能記憶媒体を開示する。

少なくとも１つの実施形態に係る、クラウドインフラストラクチャ・エッジコンピューティングデバイスのための例示的なハイレベルアーキテクチャを示すブロック図である。 少なくとも１つの実施形態に係る、ユーザコンピューティングデバイスをクラウドインフラストラクチャ・エッジコンピューティングデバイスに接続するための例示的なアーキテクチャを示すブロック図である。 少なくとも１つの実施形態に係る、クラウドインフラストラクチャ・エッジコンピューティングデバイスの例示的な筐体を示すブロック図である。 少なくとも１つの実施形態に係る、本明細書に記載のクラウドインフラストラクチャ・エッジコンピューティングデバイスを示す分解図である。 少なくとも１つの実施形態に係る、クラウドインフラストラクチャ・エッジコンピューティングデバイスの例示的なコンピュータアーキテクチャを示すブロック図である。 少なくとも１つの実施形態に係る、１つ以上のエッジコンピューティングデバイスを含む分散コンピューティングクラスタを示すブロック図である。 少なくとも１つの実施形態に係る、クラウドインフラストラクチャ・エッジコンピューティングデバイスの１つ以上のコンポーネントによってワークフローを実行するための制御プレーンおよびフローを示すブロック図である。 少なくとも１つの実施形態に係る、ユーザ要求からマニフェストを生成するためのフローを示すブロック図である。 少なくとも１つの実施形態に係る、例示的なマニフェストを示すブロック図である。 少なくとも１つの実施形態に係る、ユーザ要求からマニフェストを生成するための別のフローを示すブロック図である。 少なくとも１つの実施形態に係る、エッジコンピューティングデバイスにおいて１つ以上のデータプレーンリソースをプロビジョニングするためのアーキテクチャおよびフローを示すブロック図である。 少なくとも１つの実施形態に係る、異なるマニフェストに従って異なるエッジデバイスをプロビジョニングするための例示的な方法を示すブロック図である。

詳細な説明
以下の説明では、さまざまな実施形態について説明する。説明の目的で、実施形態の完全な理解を提供するために、特定の構成および詳細について記載する。しかしながら、具体的な詳細がなくても実施形態が実施され得ることも当業者には明らかであろう。さらに、記載する実施形態を不明瞭にしないために、周知の特徴を省略または簡略化する場合がある。

はじめに
いくつかの例では、クラウド統合型エッジサービス（たとえば、エッジコンピューティングデバイスにおいて実装される）が、集中データセンター（たとえば、クラウドインフラストラクチャ・サービスプロバイダのデータセンター）の外で時間的制約のあるクラウドインフラストラクチャアプリケーションを実行したいという願望に対処する上で不可欠な場合がある。このようなエッジコンピューティングデバイスは、エッジで、および／または、切断された場所（たとえば、集中データセンターから分離され、パブリック／プライベートネットワーク接続（たとえば、インターネット接続、ＶＰＮ接続、専用接続など）がない遠隔地）で、コンピューティングおよびストレージを提供して、データ生成および取り込みの時点またはその近傍で低レイテンシ処理を可能にし得る。場合によっては、クラウド技術が技術的に実現不可能であるか、実現するにはコストがかかりすぎると考えられてきた遠隔地に、物理的にクラウドインフラストラクチャサービスを提供するために、ポータブルな（保護のために耐久性を有することもある）サーバノードのフリート（たとえば、エッジデバイスのフリート）が構成されることがある。

顧客（たとえば、ユーザ）にとって、エッジコンピューティングデバイスは、仮想マシン（virtual machine：ＶＭ）、コンテナ、機能およびデータファイルを含むクラウドインフラストラクチャの延長として作用することができ、ブロックボリュームまたはオブジェクトストアサービスは、クラウドインフラストラクチャテナンシ（たとえば、集中型クラウドコンピューティング環境のテナンシ）から、ほとんど変更を加えることなく配信することができ、顧客のエクスペリエンスは、集中型クラウドコンピューティングエクスペリエンスと変化しないままであってもよい。さらに、エッジコンピューティングデバイスは、クラウドインフラストラクチャ・サービスプロバイダの一部である制御プレーンとデータプレーンとの両方を実装するように構成され得る。データプレーンは、データ格納、移行、処理などを管理するように構成することができる一方で、制御プランは、コンピューティングデバイスのさまざまなサービスおよびアーキテクチャコンポーネントを制御するために構成することができる。エッジコンピューティングデバイスが（たとえば、ローカルエリアネットワーク（local area network：ＬＡＮ）を介して）顧客のコンピューティングデバイスに適切に接続されると、顧客は、集中型クラウドサービスで使用されるのと同じＳＤＫおよびＡＰＩを使用して、ＩａａＳサービス（または少なくともそのサブセット）を利用し得る。

エッジコンピューティングデバイスは、顧客に要求され得る唯一のアクションが、ノードをネットワーク（たとえば、ユーザコンピューティングデバイスによってアクセス可能なローカル／オンプレミスネットワーク）に接続し、それらの電源を入れ、および／またはログインすることであるように、事前に設定された形態で顧客に提供することができる。デバイスは、顧客の好み／要求に基づいてさまざまな方法で事前に構成することができ、またはさまざまな構成（ストレージ中心、コンピュート中心など）のいずれかにすることもできる。ノードまたはノードのクラスタはポータブルであり、移動可能であることが意図されている。すなわち、移動されて再びセットアップされると（または移動中に使用されると）、デプロイメントは電源を切ったところから（または継続的に）実行され続ける。エッジコンピューティングデバイスは、広域ネットワーク（wide area network：ＷＡＮ）接続の可用性（インターネットなど）を監視することもでき、ＷＡＮに接続されると、顧客データおよび管理データをクラウドと同期させることができる。

エッジコンピューティングデバイスの潜在的な使用事例には、格納および処理、コンピュートおよび入出力（Ｉ／Ｏ）集約型アプリケーション、機械学習、リモートコンピューティング、低レイテンシデータベースおよび分析、ならびにデータ収集および移行が含まれる。より具体的には、エッジデバイスは、ＷＡＮ接続が潜在的であるまたは利用不可能な環境（遠隔地、石油オフショアプラットフォームなど）で生成された大量の画像、ビデオ、オーディオ、およびＩｏＴセンサーデータの格納ならびに処理に使用できる。このデータは、前処理され、フィルタリングされ、圧縮され、および／または保護されると、クラウドサービスプロバイダに移送または転送され、そこで集中型サーバ（たとえば、従来のクラウドサービスプロバイダ）によってさらに処理することができる。このデバイスは、戦術偵察または５Ｇ通信など、低レイテンシが最重要であるコンピュートおよびＩ／Ｏ集約型アプリケーションで使用することもできる。また、製造、文書管理、輸送、石油・ガス採掘、および／もしくは電気通信における効率、インテリジェンス、ならびに／または生産性を向上させるために、クラウドで訓練されたモデルを切断された場所で実行する機械学習に使用することもできる。また、高度なセキュリティとデータの密閉性とを必要とするリモートコンピューティングにも使用できる。さらに、このデバイスは、低レイテンシのデータベースおよびアナリティクスワークロードに使用することができ、時間の経過とともに最適化されるアプリケーションが増える。さらに、デバイスは、たとえば、ＷＡＮ転送よりも高速かつ低コストで、オブジェクトおよびデータベース管理システム（database management system：ＤＢＭＳ）データの大規模セットのデータ収集およびクラウドサービスプロバイダへの移行にも使用できる。

エッジデバイスは、分散クラウドパラダイムをネイティブにサポートすることができ、複雑な多段階のコンピュートワークフローを個々のコンポーネントに分離することができ、これらのコンポーネントは、エッジデバイスのインフラストラクチャに、オンプレミスで、および／またはクラウドにデプロイすることができる。このような分散ワークフローの例を以下のシナリオに示す。インターネットにアクセスできない偵察活動中の飛行機（たとえば、軍用ジェット機）にデプロイされたエッジコンピューティングノード（たとえば、切断されたエッジコンピューティングデバイス）によって、大量のデータを収集することができ、このデータは、エッジデバイスを提供したクラウドサービスプロバイダによって事前に訓練された機械学習モデルによって、ほぼリアルタイムで前処理される。モデルを用いてデータを処理する最初のパスでさえ、重大な異常を検出し、担当者に直ちに警告（たとえば、橋が破壊されている可能性があるため、部隊を迂回させる必要がある）を発することができる。飛行機が着陸すると、エッジコンピューティングデバイスをネットワーク（たとえば、滑走路に配備される可能性のあるエッジステーション）に物理的に接続することができる。前処理され、フィルタリングされたより小さなデータセットを、エッジステーションにおいてエッジコンピューティングデバイスノードのクラスタに最終処理のためにロードすることができる。元のエッジコンピューティングデバイスは解放され、たとえば次のミッションをサポートするために、別の（または同じ）飛行機にロードすることができる。エッジステーションでの処理が完了すると、３Ｄマップの更新が発行され、すぐに使用できるようになる。変更セットは、その後、エッジステーションクラスタによってデータセンターにアップロードされ、偵察活動などにインテリジェントな戦術的予測を提供する将来のモデルを構築するために使用することができる。

以下の技術は、電気通信、石油・ガス、ヘルスケア、ホスピタリティ、農業、輸送、およびロジスティクスなどのさまざまな文脈で採用され得ることが理解されるべきである。

本明細書に記載する実施形態は、個別的および集合的に、これらの問題および他の問題に対処する。具体的には、本開示の実施形態は、クラウドインフラストラクチャ・エッジコンピューティングデバイスを提供する。

エッジデバイスアーキテクチャ
エッジコンピューティングデバイス（「クラウドコンピューティングエッジデバイス」、「クラウドインフラストラクチャ・エッジコンピューティングデバイス」、または簡潔に「エッジデバイス」と呼ばれることもある）は、データが生成される場所に顧客のインフラストラクチャおよびプラットフォームサービスを物理的に配置することによって、すなわち、エッジで、オンプレミスで、または完全に切断することによって、ユーザの集中型クラウドコンピューティングテナンシを拡張する。各デプロイメントは、顧客の集中型クラウドテナンシからＶＭインスタンス画像とデータとをプロビジョニングすることで、顧客の特定のニーズに対応するように作成される。これらのワークロードは、エッジデバイスが接続状態に適応し、過酷な環境条件で動作し、接続が再確立されるたびにクラウドと同期する準備ができているため、オフラインで完全に機能する。

図１は、少なくとも１つの実施形態に係る、クラウドインフラストラクチャ・エッジコンピューティングデバイス（たとえば、エッジデバイス１００）のための例示的なハイレベルアーキテクチャを示すブロック図である。エッジデバイス１００のソフトウェアおよびハードウェアコンポーネントの概要が以下に提供される。

いくつかの例では、エッジデバイス１００は、１つ以上のコンテナ（たとえば、コンテナ（複数可）１０４Ａ，１０４Ｂ，１０４Ｃ～１０４Ｎに対応し、集合的に「コンテナ（複数可）１０４」と呼ばれる）を実装するように構成されたコンテナ化エンジン１０２（たとえば、Ｄｏｃｋｅｒ，Ｋｕｂｅｒｎｅｔｅｓなど）を含み得る。コンテナ化エンジン（たとえば、コンテナ化エンジン１０２）は、コンピュータアプリケーションのデプロイメント、スケーリング、および管理を自動化するためのコンテナオーケストレーションシステムであってもよい。いくつかの実施形態では、コンテナ化エンジンは、ＯＳレベルの仮想化を提供してコンテナと呼ばれるパッケージでソフトウェアを提供するように構成され得る。これらのコンテナは、互いに分離され、それぞれのソフトウェア、ライブラリ、および構成ファイルを利用することができ、適切に定義されたチャネルを介して互いに通信することができる。いくつかの実施形態では、サービス（複数可）１０４は、任意の適切な数のサービス（たとえば、１つ以上）を含み得る。これらのサービスは、集中型クラウド機能の少なくとも一部を実装し得る。各サービスは、スタンドアロンであってもよいし、分散クラスタとして動作してもよい。エッジデバイス１００はさらに、１つ以上の仮想マシン（たとえば、仮想マシン１０８Ａ，１０８Ｂ，１０８Ｃ～１０８Ｎ、集合的に「仮想マシン（複数可）１０８」または「ＶＭ１０８」と呼ばれる）を実装するように構成されたハイパーバイザ１０６を含み得る。

いくつかの例では、エッジデバイス１００は、ストレージ１１０（たとえば、ローカルデータを格納するためのオブジェクトストレージおよび／またはブロックストレージ）を含む。エッジデバイス１００は、オペレーティングシステム（operating system：ＯＳ）１１２を含む。いくつかの実施形態では、ＯＳ１１２は、エッジデバイス上で実行するために最適化されてもよく、かつ／またはエッジデバイス上での実行に特化されてもよい。ＯＳ１１２は、エッジデバイス１００のハードウェアを管理し、エッジデバイス１００上で実行されるサービスのデータプレーンをサポートするように構成され得る。ＯＳ１１２は、特定のデプロイメントタイプ（たとえば、単一のエッジデバイスデプロイメント、または特定のエッジデバイスクラスタ構成）をサポートするように構成されてもよい。ＯＳ１１２は、顧客による直接アクセスを禁止または他の態様ではブロックすることによって、エッジデバイスをセキュアにするように構成され得る。

いくつかの実施形態では、エッジデバイス１００は、任意の適切な数の中央処理装置（central processing unit：ＣＰＵ）および／またはストレージドライブなどのハードウェアを含み得る。たとえば、図１に示すエッジデバイス１００は、処理装置ごとにさまざまな数のコアを有する、１つ、２つ、またはそれ以上のＣＰＵを備えてもよく、任意の数のストレージドライブ（たとえば、６．４テラバイト（terabyte：ＴＢ）ドライブなど）を含んでもよい。非限定的な例として、エッジデバイス１００は、任意の適切なサイズのブロックおよび／またはオブジェクトストレージを含んでもよい。エッジデバイス１００は、任意の適切な数の中央処理装置（ＣＰＵ）、グラフィック処理装置（graphics processing unit：ＧＰＵ）、任意の適切なサイズのランダムアクセスメモリ（random access memory：ＲＡＭ）、１つ以上のポート（たとえば、ＱＳＦＰ２８、ＲＪ４５、デュアルポートなど）、不正開封防止シール、または上記コンポーネントの任意の適切な組み合わせを含み得る。

いくつかの例では、基本的なシステム機能／サービスは、Ｌｉｎｕｘ（登録商標）に基づくソフトウェアのカスタムロードを有するＲＥＳＴｆｕｌ ＡＰＩを介してアクセスすることができる。仮想マシン（複数可）１０８は、個々に、カーネルベースの仮想マシン（Kernel-based Virtual Machine：ＫＶＭ）（たとえば、カーネルがハイパーバイザとして機能することを可能にするＬｉｎｕｘカーネル内の仮想化モジュールによって管理される仮想マシン）および／またはハードウェアベースの仮想マシン（たとえば、仮想マシンが多数のハードウェアアーキテクチャをエミュレートすることを可能にするハードウェア仮想化を実行することができるＱｕｉｃｋ ＥＭＵｌａｔｏｒ（ＱＥＭＵ）などのバーチュアライザによって管理される仮想マシン）であってもよい。ストレージ１１０は、サービス（複数可）１０４およびＶＭ（複数可）１０８とは別のコンポーネントとして表されているが、コンテナ（たとえば、コンテナ１０４Ａ）として、またはＶＭ（たとえば、ＶＭ１０８Ａ）内で、実行することができる。いくつかの例では、ストレージ１１０（たとえば、オブジェクトストレージ、ブロックストレージなど）をコンテナとして実装することが好ましい場合がある。

図２は、本明細書で説明するエッジデバイス（たとえば、図１のエッジデバイス１００）をコンピューティングデバイス２０２（たとえば、ユーザコンピューティングデバイス）に接続するための例示的なアーキテクチャ２００を示す。コンピューティングデバイス２０２は、ラップトップコンピュータ、デスクトップコンピュータなどを含むが、これらに限定されない任意のタイプのコンピューティングデバイスであり得る。エッジデバイス２０４（図１のエッジデバイス１００の一例）は、コンテナ化エンジン２０６（図１のコンテナ化エンジン１０２の一例）、ハイパーバイザ２０８（１のハイパーバイザ１０６の一例）、およびストレージ２１０（１のストレージ１１０の一例）を含み得る。

さらに、簡潔に上述したように、エッジデバイス１００は、コンピューティングデバイス２０２から受信されるＲＥＳＴｆｕｌ ＡＰＩコールを管理するためのＡＰＩプロキシ２１２を含み得る。ＡＰＩコールは、エッジデバイス２０４内部のネットワークインターフェイスカード（network interface card：ＮＩＣ）２１４を介してエッジデバイス２０４に入り得る。ＮＩＣ２１４は、ローカルエリアネットワーク（たとえば、ＬＡＮ２１６）を介してエッジデバイス２０４をコンピューティングデバイス２０２に接続するために使用され得る。ＮＩＣ２１４によって受信されたＡＰＩコールは、ウェブサーバを実装し得る公開されたエンドポイント（たとえば、エンドポイント２１８）に送信され得る。ウェブサーバは要求をＡＰＩプロキシ２１２に送信することができ、ＡＰＩプロキシ２１２は、要求を適切なサービス（たとえば、コンテナ化エンジン２０６、ハイパーバイザ２０８、および／またはストレージ２１０）にルーティングすることができる。また、公開されたエンドポイント／ウェブサーバは、顧客が使用するための軽量コンソール（たとえば、コンピューティングデバイス２０２上に表示されるユーザインターフェイス）を実装するように構成され得る。

軽量コンソールは、ラップトップコンピュータ、デスクトップコンピュータ、またはエッジデバイス２０４に（たとえば、ルータ、ケーブルなどを介して）ネットワーク接続されている他のネットワークアクセス可能な（たとえば、ローカルエリアネットワーク（ＬＡＮ２１６）に接続されている）デバイス上のウェブブラウザ（たとえば、Ｍｏｚｉｌｌａ（登録商標）Ｆｉｒｅｆｏｘ（登録商標）など）内で実行することができる。エッジデバイス２０４は、コンソール接続用のエンドポイント２１８を公開することができ、ウェブサーバは、ＬＡＮ２１６を介してコンピューティングデバイス２０２のウェブブラウザにデータを送信することができる。

図３は、本明細書で説明するエッジデバイス（たとえば、図１のエッジデバイス１００）の例示的な物理的筐体３００を示す。エッジコンピューティングデバイスを収容することができる（たとえば耐久性のある）箱を構築するために、さまざまな異なるフォームファクタ、形状、色などを採用することができる。物理的筐体は、図示されるように、ハンドル３０２を含むことができ、誰かが筐体を割って開けるとそれが明らかになるような、不正開封防止要素を含み得る。このようにして、エッジコンピューティングデバイスを提供するサービスプロバイダは、デバイスが変更されていないと保証することができる。いくつかの例では、物理的筐体３００は開けることができない場合がある。しかしながら、場合によっては可能かもしれないが、極端な手段が必要である。

図４は、少なくとも１つの実施形態に係る、本明細書で説明するクラウドインフラストラクチャ・エッジコンピューティングデバイス（たとえば、図１のエッジデバイス１００の一例であるエッジデバイス４００）を示す分解図である。図１および図２に関して説明されるさまざまなコンポーネントを、エッジデバイス４００内の１つ以上のマザーボードおよび／またはインターフェイスカードに通信可能に取り付けることができる。図示されたコンポーネントの構成は、一実現例に過ぎない。図示されたコンポーネントの特定の位置は、限定することを意図したものではなく、前述のように、本明細書に記載された機能を実現することが可能な任意の構成が許容される。コンポーネントを取り付けたら、箱全体を閉じ、密封し、不正開封防止コンポーネントで施錠することができる。

エッジデバイス４００は、単一の筐体である。筐体は、任意の適切な数のＳＡＳ（serially attached SCSI）ソリッドステートドライブ（solid-state drive：ＳＳＤ）、および筐体内の他のすべてのコンポーネント（たとえば、ＣＰＵ、メモリ、ＧＰＵなど）を収容するように設計され得る。システムは、Ｌ字ブラケット／棚に載せた標準の１９インチラック内に、テーブルトップ上に、またはフロアスタンドを使用して机の横に直立した状態で収まるように設計された完全収納シートメタル筐体内の各ドライブへの１つ以上の（たとえば、１２Ｇｂ）ＳＡＳ接続を含み得る。

システムは、不正開封防止筐体、フロントベゼルを所定の位置に保持するネジを覆う、リアセキュリティインターロック機能を有するフロントセキュリティプラグを含み得る。いくつかの実施形態では、システムは、デュアルソケットマザーボードおよび任意の適切な容量のＤＲＡＭを含み得る。いくつかの実施形態では、システムは、任意の適切な数（たとえば、２，３など）のＳＡＴＡ ＳＳＤ、ストレージコントローラ、組み込みネットワーク接続、１つ以上のポート（たとえば、デュアルポート、シリアルポートなど）、冷却システムの一部としての１つ以上のファン、または上記の任意の適切な組み合わせを含み得る。

非限定的な例として、エッジデバイス４００は、通気ベゼルと、データ転送および管理に必要なＩ／Ｏ接続のみを露出させたリアパネルとを用いて前面を固定した外部押し出しアルミニウムケースで構成されてもよい。取り付けは、任意の適切なマザーボード、ファン、および電源を取り付けるように設計することができる。

図５は、少なくとも１つの実施形態に係る、クラウドインフラストラクチャ・エッジコンピューティングデバイス（たとえば、図１および図２のエッジデバイス１００および２０４のそれぞれの一例であるエッジデバイス５００）の例示的なコンピュータアーキテクチャを示すブロック図である。エッジデバイス５００は、従来のクラウド機能の一部または全部を、クラウドデータセンターがアクセスできない、またはクラウドデータセンターにアクセスできない可能性のある場所に拡張するクラウド統合サービスと考えることができる。これは、ＷＡＮ接続のない場所でクラウドに似た機能を提供する、ポータブルで耐久性のあるサーバノードを介して実現できる。これにより、顧客は、選択したクラウドワークロードをリモートロケーションにシフトし、クラウドインフラストラクチャのエッジにおけるデータ取り込みポイントの近くで集中的なデータ処理動作を可能にすることができる。

エッジデバイス５００は、任意の適切な数のサービス（たとえば、サービス（複数可）５０２）を含み得る。各サービスは、エッジデバイス５００上でローカルにコンテナ（たとえば、Ｄｏｃｋｅｒコンテナ）として実行され得る。サービス（複数可）５０２は、サービス間の通信が（たとえば、ＭＡＣｓｅｃなどのセキュリティプロトコルに従って）暗号化されるように、基板ネットワーク５０４を介して通信可能に接続され得る。各コンテナには、トラフィックをアドレス指定できる基板ＩＰアドレス（たとえば、静的アドレス）が割り当てられ得る。いくつかの実施形態では、セキュリティプロトコル（たとえば、ＭＡＣｓｅｃ）は、プロビジョニング時（たとえば、エッジデバイス５００がユーザに出荷される前）に構成されている。エッジデバイスのシステムソフトウェア（サービス（複数可）５０２を含む）は、ブートセキュリティソフトウェア（たとえば、Trenchboot Secure Launch）によって保護されたセキュア環境で実行され得る。ユーザは、セキュアな環境および／または基板ネットワーク５０４へのアクセスを制限され得る。これらのサービスによって使用されるリソースの量を最小にするために、サービスコードは、エッジデバイス５００上のＣＰＵ負荷を減少させるだけでなく、ＲＡＭスペースを減少させるために、コンパイルされ、ディスクに保存されてもよい。

サービス（複数可）５０２に含まれるいくつかの例示的なサービスは、ＵＩコンソールサービス、アイデンティティ制御プレーン（control plane：ＣＰ）サービス、アイデンティティデータプレーン（data plane：ＤＰ）サービス、コンピュートアプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）サービス、コンピュートワーカースレッドサービス、仮想ネットワーク（virtual network：ＶＮ）ＡＰＩサービス、ブロックストレージＡＰＩサービス、function-as-a-serviceサービス、イベントサービス、（たとえば、Ceph Storageなどのストレージプラットフォームを実装する）オブジェクトストレージ管理サービス、コンピュートＤＰサービス（たとえば、図２のハイパーバイザ２０８の例）、ＶＮ ＤＰサービス、ブロックストレージ管理サービス、function-as-a-serviceＡＰＩサービス、function-as-a-serviceロードバランシング（load balancing：ＬＢ）サービス、function-as-a-serviceプロセススレッドサービス、分散データストア管理サービス（ｅｔｃｄ３など）、ダイナミックホスト構成プロトコルサービス、ドメイン名システムサービス、ネットワークタイムプロトコル（network time protocol：ＮＴＰ）サービスなどである。これらのサービスによって提供されるいくつかの機能例を以下で説明する。

一例として、コンピュートＤＰサービスは、同一のハイパーバイザホスト上のＶＭ（複数可）５０８を分離するように構成され得る（たとえば、エッジデバイス５００上に事前設定され、プロビジョニングされ得る）。コンピュートＤＰサービスは、任意の適切なコンテナエンジン（たとえば、Ｄｏｃｋｅｒコンテナ、ＭｉｃｒｏＣｏｎｔａｉｎｅｒなど）を利用して、同じハイパーバイザホスト上のＶＭ（複数可）５０８を互いに分離することができる。コンピュートＤＰサービスは、任意の適切なハイパーバイザ（たとえば、Ｑｕｉｃｋ ＥＭＵｌａｔｏｒ（ＱＥＭＵ）、Ｋｅｒｎｅｌ－ｂａｓｅｄ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＫＶＭ）等）を利用して、ＶＭ（複数可）５０８に仮想ハードウェアエミュレーションを提供し得る。いくつかの実施形態では、ＶＮＩＣ（複数可）５０６は、任意の適切な数の仮想ネットワーク（たとえば、プライベート仮想ネットワーク（複数可）（ＰＶＮ（複数可））５０５のサブネットに接続され、プライベート・インターネット・プロトコル（ＩＰ）アドレスが割り当てられる。１つのＶＭは、異なるＶＣＮおよび異なるサブネットからの複数のＶＮＩＣを有し得る。ＶＮＩＣの最大数は、事前に定義された閾値（たとえば、ＶＭ数当たりのＶＮＩＣなどを定義する「ＶＭ形状」、ＶＮＩＣ形状と呼ばれる構成データ）によって制限することができる。いくつかの実施形態では、事前に定義された閾値は、ＶＭ（複数可）５０８の各々に適用される。ＶＮＩＣ（複数可）５０６によって利用されるサブネットは、ＶＬＡＮによって分離され得る。いくつかの実施形態では、ＶＮＩＣ（複数可）５０６の一部またはすべてに、パブリックＩＰアドレスおよび／またはプライベートＩＰアドレスが割り当てられてもよい。パブリックＩＰアドレスはネットワーク５２０内のアドレスであり、プライベートＩＰアドレスは、ＰＶＮ（複数可）５０５のＩＰアドレスを指す。

いくつかの実施形態では、エッジデバイス５００は、ネットワークアドレス変換（network address translation：ＮＡＴ）サービス、ダイナミックホスト構成プロトコル（dynamic host configuration protocol：ＤＨＣＰ）サービス、ドメイン名システム（domain name system：ＤＮＳ）サービス、ネットワークタイムプロトコル（network time protocol：ＮＴＰ）サービス、メタデータサービス、およびパブリックＡＰＩサービスなどの多数のサービスを介して、さまざまなネットワーク機能を実現する。メタデータサービスは、初期化データおよび他のメタデータを全てのＶＭ（複数可）５０８に提供し得る。いくつかの実施形態では、ＤＨＣＰサービスは、ＶＮＩＣ（複数可）５０６の各々にプライベートＩＰアドレスを割り当て、ＶＭ（複数可）５０８の各々は、１つ以上のＶＮＩＣＳを有する。ＤＮＳサービスは、エッジデバイス５００上のＶＭ（複数可）５０８にドメイン名解決を提供し得る。ＮＴＰは、ＶＭ（複数可）５０８に時間同期を提供し得る。いくつかの実施形態では、サービス（複数可）５０２の一部として実行されるパブリックＩＰサービスは、ＶＭにパブリックＩＰを割り当てることなく、またサービス・ゲートウェイを構成することなく、ＶＭがパブリックＡＰＩにアクセスすることを可能にし得る。

いくつかの実施形態において、ＶＭ（複数可）５０８のうちの少なくとも１つは、ブロック（またはオブジェクト）ストレージを実装し得る。いくつかの実施形態では、仮想マシンに関連付けられたハイパーバイザは、ハイパーバイザが分散データストレージプラットフォーム（たとえば、Ｃｅｐｈ）を使用することを可能にするライブラリを含み得る。ライブラリは、当該ストレージプラットフォームに関連付けられたプロトコル（たとえば、ＲＢＤ（RADOS Block Device））を利用して、ブロックベースのデータの格納を容易にし得る。分散データストレージプラットフォームは、複数の仮想マシン上で実装され得る。いくつかの実施形態では、分散データストレージプラットフォームは、スナップショットの作成とブロックボリュームのコピーとをサポートする。ＶＭ画像およびＶＭブロックボリュームは、Ｃｅｐｈブロックデバイスであり得る。いくつかの実施形態では、分散データストレージプラットフォームを実装するＶＭ（複数可）は、システム予約リソース（たとえば、８つのＣＰＵコア、またはエッジデバイス５００で利用可能なＣＰＵの総数の任意のサブセット）を使用する。たとえば、ブートボリュームをプロビジョニングするために、ブロックデバイス画像は、ブロックデバイスのブートボリュームにコピーされ得る。分散データストレージプラットフォームは、冗長性のために複数のノードを含むブロックデバイスを使用し得る。一部のノードが故障した場合、ブロックデバイスは動作を継続することができる。いくつかの実施形態では、分散データストレージプラットフォーム（たとえば、Ｃｅｐｈなど）は、少数のノードに障害が発生した場合に、ブロックデバイスのデータを自動的に回復する。ブロックストレージは、任意の適切なデプロイ可能リソースの画像を格納するために利用され得る。一例として、画像は、ＶＭを起動するために利用され得る。いくつかの実施形態では、画像は、特定のＶＭ形状（たとえば、コンピュートヘビーＶＭ、ＧＰＵ最適化ＶＭ、ストレージＶＭなど）に対応し得る。

コンピュートＡＰＩサービスは、１）ＶＭの起動および終了、２）ＶＭの停止、起動、再起動、３）ＶＭのリストおよび／または特定のＶＭに関する情報の取得、４）ＶＭコンソール履歴ＡＰＩの取得、５）ＶＭスナップショットの取得、６）ブロックボリュームの追加（attach）／取り外し（detach）等の動作をサポートし得る。いくつかの実施形態では、コンピュートＡＰＩサービスは、他のサービス（たとえば、コンピュートＤＰサービス、認証および認可のためのアイデンティティＤＰサービス等）を呼び出すために使用することができる。

他のサービスの機能の一部は、図７に関連して説明する。一般に、各サービスについては本明細書では詳細に説明しない場合があるが、サービス（複数可）５０２によって提供される一般的な機能は、リモートクラウドサービスプロバイダによって提供されるクラウドサービスの機能を含み得る。いくつかの実施形態では、エッジデバイス５００は、サービス（複数可）５０２の一部が、単一のインスタンスとして１つ以上のローカルデバイス（１つ以上のエッジデバイス）上で動作しているにもかかわらず、または顧客に関連付けられたクラウドコンピューティング環境へのパブリックネットワークアクセスを有しないか、または断続的に有する可能性がある分散サービスの一部として動作しているかにかかわらず、クラウドコンピューティング環境で動作しているかのように動作することができるように、事前に定義された領域および／またはレルムに関連付けられ得る。「領域」とは、サービスセンターが存在する地理的な場所を指す。「レルム」とは、領域の論理的な集まりを指す。レルムは互いに隔離されてもよく、データを共有しなくてもよい。

いくつかの実施形態では、エッジデバイス５００は、計算、メモリ、およびネットワーキングリソース（たとえば、仮想ネットワークインターフェイスカード（複数可）（virtual network interface card：ＶＮＩＣ）（複数可）５０６）を使用して、任意の適切な数の仮想ネットワーク（たとえば、ＰＶＮ５０５）を提供し得る。仮想ネットワークは、物理的な基板ネットワークの上で実行される論理ネットワークである。サービス（複数可）５０２を使用して、仮想マシン（たとえば、コンピュートインスタンスを実行する仮想マシン（複数可）（ＶＭ（複数可））５０８）などの１つ以上の顧客リソースまたはワークロードを、これらのプライベート仮想ネットワーク上に展開することができる。ＶＭ（複数可）５０８の任意の適切な組み合わせは、仮想ＮＩＣ（たとえば、仮想ＮＩＣ（複数可）５０６の１つ）を介して個別にアクセス可能な機能（たとえば、コンピュートインスタンス、格納など）を実行することができる。ＰＶＮの一部である各ＶＭは、ＶＭ（たとえば、コンピュートインスタンス）がＰＶＮのサブネットのメンバになることを可能にするＶＮＩＣと関連付けられる。ＶＭに関連付けられたＶＮＩＣは、ＶＭとの間のパケットまたはフレームの通信を容易にする。ＶＮＩＣは、ＶＭの作成時にＶＭに関連付けることができる。ＰＶＮ（複数可）５０５は、ピアツーピアネットワーク、ＩＰネットワークなど、多くの形態を取ることができる。いくつかの実施形態では、サービス（複数可）５０２の基板ネットワークトラフィックは、エッジデバイス５００上で実行される１つ以上のＶＭ（複数可）５０８のネットワークトラフィックから（たとえば、異なるＰＶＮもしくはサブネットによって）暗号化および／または分離され得る。

このように、エッジデバイス５００は、顧客が、可用性が高く、物理的にローカルで、仮想ホストされた環境において、広範なアプリケーション（たとえば、コンピュートインスタンス）、サービス、および／またはストレージを構築し、実行することを可能にするインフラストラクチャならびに一連の補完的サービスを提供する。顧客は、エッジデバイス５００によって提供される基礎となる物理リソースを管理または制御しないが、仮想マシン（たとえば、コンピュートインスタンス、仮想ＮＩＣ、ブロックもしくはオブジェクトストレージなど）の拡張または縮小、それらの仮想マシンへのアプリケーションのデプロイなどを制御する。エッジデバイス５００上の全てのワークロードは、異なるＣＰＵセット（たとえば、ＶＭおよび非ＶＭ）に分割されてもよい。一方のセット（たとえば、サービス（複数可）５０２によって実行されるワークロードなどの非ＶＭ）は、エッジデバイス５００のＣＰＵコア（たとえば、８）のサブセットを利用し、他方のセット（たとえば、ＶＭ（複数可）によって実行されるＶＭワークロード）。

エッジデバイス５００は、ＶＭ（複数可）５０８と対話する、および／またはＶＭ（複数可）５０８を管理するために、１つ以上のネットワークインターフェイス（たとえば、ＮＩＣ２および／またはＮＩＣ４）ならびにネットワーク５２０を介してユーザデバイス（たとえば、図２のコンピューティングデバイス２０２）と通信可能に接続され得る。特定の実施形態では、エッジデバイス５００にアクセスし、これを管理するために使用することができるウェブベースのユーザインターフェイスを介して、ユーザデバイスにおいて軽量コンソールを提供することができる。いくつかの実現例では、コンソールは、エッジデバイス５００によって提供されるウェブベースのアプリケーション（たとえば、サービス（複数可）５０２の１つ）である。

図５は、単一のエッジデバイスを示す。しかしながら、２つ以上のエッジデバイスが分散コンピューティングクラスタとして利用されてもよいことが理解されるべきである。

図６は、少なくとも１つの実施形態に係る、１つ以上のエッジコンピューティングデバイス（たとえば、各々は図５のエッジデバイス５００の一例であるエッジデバイス６０２および６０４）を含む分散コンピューティングクラスタ６００を示すブロック図である。

分散コンピューティングクラスタ６００の各エッジデバイスは、基板ネットワーク６０６（図５の基板ネットワーク５０４の一例）を介して接続され得る。いくつかの実施形態では、分散コンピューティングクラスタ６００のエッジデバイス（「エッジコンピューティングノード」または「エッジノード」と呼ばれることもある）は、１つ以上のスイッチ（たとえば、スイッチ６０８および／または６１０）を使用して、基板ネットワーク６０６によって接続され得る。いくつかの実施形態では、ＮＩＣ１およびＮＩＣ５は、特定のコネクタ（たとえば、ＲＪ４５コネクタ）を含んでもよく、ＮＩＣ３およびＮＩＣ８は、同じコネクタまたは異なるコネクタ（たとえば、ＱＳＦＰ２８ １００ＧｂＥコネクタ）を含み得る。いくつかの実施形態では、分散コンピューティングクラスタ６００の１つのエッジデバイスのみが、ネットワーク（複数可）６２０（図５のネットワーク５２０の一例）などの顧客ネットワークに接続される。したがって、エッジデバイスのサービス間のトラフィックが暗号化され、所与のエッジデバイスの他のトラフィックから分離され得るだけでなく、複数のエッジデバイスにわたって動作する分散サービス間のトラフィックも暗号化され、コンピューティングクラスタの他のトラフィックから分離され得る。いくつかの実施形態では、各エッジデバイスは、分散コンピューティングクラスタ６００の特定のノードとして事前設定される。他の実施形態では、ユーザは、分散コンピューティングクラスタ６００のエッジデバイスの数およびトポロジを設定することができる。

図７は、少なくとも１つの実施形態に係る、クラウドインフラストラクチャ・エッジコンピューティングデバイスの１つ以上コンポーネントによってワークフローを実行するためのフロー７００を示すブロック図である。フロー７００を実行するコンポーネントは、ＡＰＩサービス７０２、データベース（database：ＤＢ）７０４、サービス７０６、ハイパーバイザサービス７０８、ＰＶＮ ＣＰサービス、ブロックストレージＣＰサービス７１４を含み得るが、より多くのまたはより少ないサービスが含まれてもよい。いくつかの実施形態では、図７の各サービスは、図５のサービス（複数可）５０２のうちのサービスの一例である。いくつかの実施形態では、図７のサービスに関連して説明した機能の少なくとも一部は、任意の適切な組み合わせで組み合わされ、単一のサービスまたは同じサービスのインスタンスとして提供され得る。一例として、いくつかの実施形態では、サービス７０２～７０８の機能は、単一のサービス（たとえば、図５に関連して上述したコンピュートＣＰサービス）によって提供され得る。いくつかの実施形態では、サービス７０２～７０８によって提供される機能は、単一のエッジデバイス（たとえば、図５のエッジデバイス５００）によって提供されてもよく、または２つ以上のエッジデバイス（たとえば、図６のエッジデバイス６０２およびエッジデバイス６０４）によって提供されてもよい。

いくつかの実施形態において、ＡＰＩサービス７０２は、データプレーンリソース（たとえば、図５のＶＭ（複数可）５０８）のセットの意図された状態を記述する意図された状態データを含む作業要求を受け入れるように構成され得る。非限定的な例として、ユーザ７２０は、ユーザデバイス（たとえば、図２のユーザデバイス２０２）を利用して、ＶＭを起動する要望を示すさまざまな選択を行うことができるユーザインターフェイスにアクセスし得る。ユーザ入力は、作業要求（work request：ＷＲ）（たとえば、ＷＲ７２２）を生成し、分散データベース（たとえば、ＤＢ７０４）に作業要求を格納するように事前に定義されたＬａｕｎｃｈ ＶＭ ＡＰＩを利用し得るＡＰＩサービス７０２（図５のコンピュートＣＰサービスの一例）によって受信され得る。いくつかの実施形態において、ＤＢ７０４は、即時一貫性、高可用性、トランザクション可能な分散データベースとしてｅｔｃｄ３を使用するように構成されたコンピューティングクラスタであってもよい。一般に、作業要求は、ＶＭ（複数可）５０８のようなデータプレーンリソースを作成および／または修正するために必要な要望および情報を示す。いくつかの実施形態では、作業要求は、データプレーンリソースの所望の状態を示す状態情報を含む。いくつかの実施形態では、ＤＢ７０４は、任意のエッジデバイス上で動作する全てのサービスが（および分散コンピューティングクラスタ６００のようなエッジデバイスクラスタの任意の適切なエッジデバイス上で動作するサービスによって）アクセス可能であり得る。

サービス７０６（たとえば、図５のコンピュートＣＰサービスの一例）は、１つ以上のワーカープロセス（たとえば、コンピューティングスレッド７１０などの１つ以上のコンピューティングスレッド）を実行するように構成され得る。これらのワーカープロセスの一部は、連続的および／または継続的な事前に定義されたワークフローを実行するように、任意の適切な時間にサービス７０６によって構成されてもよい。一例として、サービス７０６は、（たとえば、コンピューティングスレッド７１０を含む）１つ以上のワーカースレッドを構成して、新たな作業要求（たとえば、ＷＲ７２２）についてＤＢ７０４を監視してもよい。コンピューティングスレッドは、作業要求ＷＲ７２２が既にアテンドされているかどうかを判定するように構成され得る。いくつかの実施形態では、これは、ＷＲ７２２に関連付けられた一意の識別子について、ＤＢ７０４内の事前に定義されたストレージバケットをチェックすることを伴う。ＷＲ７２２内に含まれる一意のＩＤがバケット内に現れない場合（または、他の態様ではＷＲが処理のためにピックアップされていないと示される場合）、コンピューティングスレッド７１０（たとえば、ナニースレッド）は、ワークフロースレッド（たとえば、コンピューティングスレッド７１０の別のインスタンス）を初期化してもよく、このワークフロースレッドは、次に、コンピューティングスレッド７１０によって、ＷＲ７２２に対応するＶＭを起動することに対応するワークフローを実行するように構成されてもよい。

初期化されたワークフロースレッドは、ワークフローサービス（図示せず）に（たとえば、図５の基板ネットワーク５０４を介して）通信可能に結合され得る。ワークフローサービスは、１つ以上の事前に定義されたワークフローから、ＶＭの起動、したがってＷＲ７２２に対応する事前に定義されたワークフローを特定するように構成され得る。これらの事前に定義されたワークフローは、事前に定義された目標（たとえば、仮想マシンの起動、仮想マシンの停止／起動、仮想マシンの終了、ブロックボリュームの作成、ブロックボリュームの削除等）を達成するために、実行すべき１つ以上のステップ／動作、およびそれらのステップに対するシーケンスを特定する。ワークフロースレッドは、ＶＭワークフローを起動し、さまざまな他のエンティティによる実行を監督し得る。いくつかの実施形態では、ワークフロースレッドは、ＤＰリソースの意図された状態データの任意の適切な部分を、任意の適切なサービスの組み合わせに渡し得る。

非限定的な例として、仮想マシン（たとえば、ハイパーバイザサービス７０８によってホストされるＶＭ）を起動するためのワークフローの一部として、ＶＮＩＣを作成および追加するために、１つ以上のＡＰＩを呼び出すことができる。同様に、ブロックストレージボリュームＡＰＩを作成および／または追加するために、多数のＡＰＩが提供され得る。いくつかの実施形態では、ワークフロースレッドは、ＰＶＮ ＣＰサービス７１２の機能を呼び出すために、１つ以上のＡＰＩへの任意の適切な呼び出しを実行することができ、ＰＶＮ ＣＰサービス７１２は、ＶＮＩＣを作成および追加するように構成され得る。ワークフロースレッドは次に、ブロックストレージＣＰサービス７１４を呼び出し、ブロックストレージＣＰサービス７１４は、ブロックストレージボリュームを作成し追加するための任意の適切な動作を実行し得る。ワークフローを監督するワーカースレッドは、指定された順序（たとえば、ブロックボリュームを作成する前に最初にＶＮＩＣを作成する）を保証し得る。このワーカースレッドは、呼び出した１つ以上のサービスからのエラーおよび／または例外を捉えるように構成され得る。例外／エラーが発生しない場合、ワークフローを監督するワーカースレッドは、（基板ネットワークを介して）ハイパーバイザサービス７０８に適切なデータを提供することができ、ハイパーバイザサービス７０８は、要求されたＶＭを作成するための機能を実行する。ハイパーバイザサービス７０８は、新しく起動されたＶＭの実際の状態データを提供し得る。いくつかの実施形態では、ワークフローを監督するワーカースレッドは、（たとえば、モニタが、実際の状態データが要求された状態データと一致し、変更が必要ないことを示すか、または実際の状態データが要求された状態データと一致せず、データプレーンリソースの変更が必要であることを示すかを判断し得る場合）、後で参照するために、実際の状態データをＤＢ７０４に格納することができる。

いくつかの実施形態では、ワークフロースレッドは、クラスタマネージャ（図示せず）に通信可能に結合され得る。クラスタマネージャは、任意の適切な数のコンピューティングクラスタを管理するように構成され得る。いくつかの実施形態において、クラスタマネージャは、任意の適切なタイプのコンピューティングクラスタ（たとえば、Ｋｕｂｅｒｎｅｔｅｓクラスタ、コンテナ化されたアプリケーションを実行するために使用されるコンピューティングノードのセットなど）を管理するように構成され得る。ワークフロースレッドは、ＤＰリソース（複数可）を意図された状態データと一致させるために特定された指示に従って、クラスタマネージャにＤＰリソース（複数可）（たとえば、ＶＭ）上で任意の適切なオーケストレーション動作を実行させるために、任意の適切な動作を実行するように構成され得る。いくつかの実施形態において、監視エンティティ（たとえば、ワークフロースレッド、ワークフロースレッドによって起動されたスレッド）は、ＤＰリソース（複数可）１１６に通信可能に結合され、ＤＰリソース（複数可）の健全性を監視するように構成され得る。いくつかの実施形態では、監視エンティティは、任意の適切な健全性データをＤＢ７０４に格納するように構成され得る。

図７に関連して議論された特定の動作およびサービスは、本質的に例示的なものであり、本開示の範囲を限定することを意図するものではない。実行される特定の動作および利用されるサービスは、要求された動作に関連する特定のワークフローに応じて変化し得る。

図８は、少なくとも１つの実施形態に係る、ユーザ要求からマニフェストを生成するためのフロー８００を示すブロック図である。図８は、サービスプロバイダコンピュータ（たとえば、サービスプロバイダコンピュータ８０２）を示す。サービスプロバイダコンピュータ８０２を、クラウドコンピューティングプロバイダによって、またはクラウドコンピューティングプロバイダの代わりに、動作させることができる。いくつかの実施形態では、図８のサービスプロバイダコンピュータは、１つ以上のエッジデバイスを構成することができるマニフェストを生成するためのクラウドコンピューティングサービスを実現する。図８のサービスプロバイダコンピュータは、クラウドコンピューティングプロバイダによって動作されるクラウドコンピューティング環境の一部に通信可能に接続されるか、またはその一部として動作され得る。ユーザデバイス８０４は、任意の適切な電子デバイス（たとえば、ラップトップ、デスクトップ、スマートフォンなど）であってよく、ネットワーク（たとえば、パブリックネットワークまたはプライベートネットワーク）を介してサービスプロバイダコンピュータ８０２に通信可能に接続され得る。サービスプロバイダコンピュータ８０２は、ユーザ入力が提供され得る１つ以上のインターフェイスをホストするように構成され得る。これらのユーザインターフェイスは、構成された１つ以上のエッジデバイスに関連し得る。

フロー８００は、サービスプロバイダコンピュータ８０２が、ユーザ入力を得ることができる１つ以上のユーザインターフェイスを公開する８１０において開始し得る。いくつかの実施形態において、これらのユーザインターフェイスは、ユーザが、１つ以上のエッジデバイス（エッジデバイス８０６はその一例である）において構成されるさまざまなサービスおよび／またはデータプレーンリソースを選択することを可能にする。一例として、これらのインターフェイスは、構成（たとえば、サービスの特定のセット、仮想マシンの特定の数および／もしくはタイプ、またはエッジデバイス８０６の任意の適切な属性）を定義するために使用され得る。いくつかの実施形態では、ユーザは、エッジデバイスのクラスタおよびそれらの対応する構成を定義し得る。したがって、これらのインターフェイスを介して、ユーザは、エッジデバイス８０６がコンピュート集約型（たとえば、エッジデバイス８０６において実行される仮想マシンの大多数がコンピューティングリソースを提供する）、ストレージ集約型（たとえば、エッジデバイス８０６において実行される仮想マシンの大多数がストレージリソースを提供する）、ＧＰＵ集約型（たとえば、エッジデバイス８０６において実行される仮想マシンの大多数がＧＰＵリソースを提供する）など（たとえば、要求された仮想マシンの数およびユーザによって選択されたこれらの仮想マシンの特定の構成に少なくとも部分的に基づく）であると示すことができる。ユーザインターフェイスは、ユーザが１つ以上のエッジデバイス（たとえば、エッジデバイス８０６）のこれらの属性を選択および／または定義することを可能にする任意の適切な形式であってよい。

８１２において、ユーザデバイス８０４は、サービスプロバイダコンピュータ８０２によって受信されたユーザ要求においてユーザ入力を提出し得る。サービスプロバイダコンピュータ８０２は、クラウドコンピューティング環境内でビルドサービスをホストしている可能性がある。

８１４において、サービスプロバイダコンピュータ８０２は、ユーザ要求に対応するマニフェスト８１５（たとえば、レコード、ファイルなど）を生成し得る。マニフェスト８１５は、完了すると、ユーザ要求に従ってエッジデバイスを構成するために利用され得る。いくつかの実施形態において、サービスプロバイダコンピュータ８０２は、事前に定義されたテンプレートに少なくとも部分的に基づいて、マニフェスト８１５を生成し得る。いくつかの実施形態において、マニフェスト８１５は、任意の適切なフォーマット（たとえば、ＪＳＯＮ、ＸＭＬなど）であってもよい。生成されると、サービスプロバイダコンピュータ８０２は、ユーザ要求に対応するようにマニフェスト８１５の修正を開始し得る。一例として、マニフェスト８１５は、１つ以上のエッジデバイスの構成情報を含むように修正されてもよい。

図９は、少なくとも１つの実施形態に係る、例示的なマニフェスト９００（図８のマニフェスト８１５の一例）を示すブロック図である。マニフェスト９００は、セクション９０２および９０４を含む。セクション９０２は１つのエッジデバイスに対応し、セクション９０４は別のエッジデバイスに対応する。マニフェスト９００は、クラスタとして動作する複数のエッジデバイスの構成を定義し得る。いくつかの実施形態では、マニフェスト９００は、９０２においてクラスタ識別子を定義し得る。セクション９０４において、任意の適切な数のノードが提供され得る。いくつかの実施形態では、ノードに、９０６で示されるような名前を割り当てられ得る。マニフェスト９００は、９０８において、所与のノード（たとえば、特定のエッジデバイス）のデバイス属性のセットを示し得る。

マニフェストは、１つ以上のネットワークインターフェイスカードに関連する任意の適切な情報を含み得る。ネットワークインターフェイスカードは、メディアアクセス制御（media access control：ＭＡＣ）アドレス、または名前などの他の適切な識別子を有するものとして定義され得る。いくつかの実施形態では、マニフェスト９００は、セクション９１０内でネットワークインターフェイスカードのドライバを識別し得る。セクション９１０は、任意の適切な数のＮＩＣ定義を含み得る。

マニフェストは、任意の適切な数のサービスを識別し得る。マニフェスト９００は、少なくとも１つのサービスを示す。マニフェスト内では、さまざまなサービスレベル属性が識別され得る。一例として、セクション９１２は、サービスの名前、サービスの画像を見つけることができる場所、サービスが動作するデフォルトのネットワーク名、サービスがブート時に開始するかどうかを示すインジケータ、およびサービスのＩＰアドレスを含み得る。マニフェスト９００は、セクション９１２内に任意の適切な数のサービスを含み得る。

マニフェスト９００はクラスタ、ノード、またはデバイスの特定の属性を含むように示されているが、マニフェストはクラスタ、ノード、またはデバイスの任意の適切な属性を識別し得ることを理解されたい。したがって、図９に示す例示的な属性は、任意の所与のマニフェストに含まれ得る属性の網羅的なリストと見なされることを意図していない。

図８に戻ると、８１６において、サービスプロバイダコンピュータ８０２は、ユーザ入力からサービスのリストを生成し、そのサービスのリストに対応するアーティファクト（たとえば、コンテナ画像、ＯＳｔｒｅｅコミットなど）を収集するための任意の適切な動作を実行し得る。いくつかの実施形態では、サービスプロバイダコンピュータ８０２は、サービスプロバイダコンピュータ８０２が属するクラウドコンピューティング環境の１つ以上の格納場所から、これらのアーティファクトを収集し得る。いくつかの実施形態では、これらのアーティファクトの一部は、所与のエッジデバイスに対して要求されたサービスセットの各々のコンテナを含み得る。サービスプロバイダコンピュータ８０２は、ユーザ要求において定義されたエッジデバイスの数に対応する任意の適切な数のアーティファクトを収集するように構成され得る。

８１８において、マニフェスト８１５は、エッジデバイスにおいて動作される特定のサービスの構成属性／詳細を示すように修正され得る。一例として、８１６において収集された各アーティファクトは、実行されると、アーティファクトが関連するサービスに対応するエントリを含むようにマニフェストファイルを修正する実行可能スクリプトを含み得る。サービスプロバイダコンピュータ８０２は、各アーティファクトの各スクリプトを実行するように構成され得る。各スクリプトは、それぞれのサービスに対応する構成情報を含むようにマニフェストファイルを修正するように構成されてもよい。各スクリプトは、任意の適切なエンティティ定義を含むようにマニフェストを修正してもよく、エンティティ定義は、デバイスまたはサービスの属性を定義する。

８２０において、サービスプロバイダコンピュータ８０２は、マニフェスト８１５内で識別された任意の適切な数のデバイス／エンティティ／サービスに１つ以上のネットワークアドレスを割り当てるための事前に定義されたルールセットを実行し得る。一例として、クラスタの各ノード（たとえば、エッジデバイスのクラスタ内のノードとして動作する各エッジデバイス）にＩＰアドレスが割り当てられてもよい。

８２２において、サービスプロバイダコンピュータ８０２は、８１８において収集されたアーティファクトに少なくとも部分的に基づいて、エッジデバイス（ＥＤ）画像を生成し得る。いくつかの実施形態では、ＥＤ画像は、所与のエッジデバイスのコンテナおよびＯＳｔｒｅｅオンボックスリポジトリの全体を含む超ＴＡＲ書庫（uber-tarball）であり得る。

８２４において、サービスプロバイダコンピュータ８０２は、任意の適切な事前に定義された構成ファイル、クレデンシャル（たとえば、ＡＰＩキー、データボリュームパスワード、Ｍａｃｓｅｃキーまたは他の適切な暗号化キーなど）エージェント（たとえば、ネットブートエージェント）などを収集するように構成され得る。

８２６において、サービスプロバイダコンピュータ８０２は、ＥＤ画像、マニフェスト、構成ファイル、クレデンシャル、およびエージェントをエッジデバイス８０６に提供することによって、エッジデバイス８０６をプロビジョニングし得る。いくつかの実施形態では、マニフェストを作成したものとは別のサービスプロバイダコンピュータ（たとえば、プロビジョニングセンターに位置するサービスプロバイダコンピュータ）が、プロビジョニング動作を実行し得ることが理解されるべきである。

８２８において、エッジデバイス８０６は、マニフェスト８１５に従ってエッジデバイス８０６をプロビジョニングするための任意の適切な動作を実行し得る。一例として、エッジデバイス８０６上で実行されるネットブートエージェントが、ＰＸＥブート、パーティション、ｄｍｃｒｙｐｔのセットアップ、ファイルシステムのフォーマット、サービスプロバイダコンピュータへのアーティファクトＵＲＬの問い合わせ、ＵＲＬを使用したアーティファクトのフェッチ、ルートファイルシステムのＯＳｔｒｅｅリポジトリへのコミット、コンテナのコンテナリポジトリへのロード、ＯＳｔｒｅｅコミットのデプロイ、リモートキーのフェッチおよびローカルキーのインストール、Ｔｒｅｎｃｈｂｏｏｔのインストール、クレデンシャルとして提供された顧客パスワードを使用した、（たとえば、チップ、ハードウェアセキュリティモジュール、集積回路プラットフォーム、またはエッジデバイスのセキュアな初期化、および暗号鍵（複数可）を含む格納された秘密のセキュリティ管理を提供するための他のハードウェア、ファームウェア、および／またはソフトウェアなどの信頼できるプラットフォームモジュールにおける）ＯＳパーティションＬＵＫＳキーの封印といった動作を実行し得る。

エッジデバイス（複数可）（エッジデバイス８０６はその一例である）が構成された後、クラウドコンピューティングプロバイダは、エッジデバイス（複数可）を出荷し得るか、または他の態様では顧客に配送し得る。エッジデバイスは、８１２において提供されたユーザ入力に従って構成され得る。

図１０は、少なくとも１つの実施形態に係る、ユーザ要求からマニフェスト１００２を生成するための別のフロー１０００を示すブロック図である。図１０は、サービスプロバイダコンピュータ１００４（たとえば、図８のサービスプロバイダコンピュータ８０２の一例）を示す。サービスプロバイダコンピュータ１００４は、クラウドコンピューティングプロバイダによって、またはクラウドコンピューティングプロバイダの代わりに、動作され得る。いくつかの実施形態では、図１０のサービスプロバイダコンピュータは、１つ以上のエッジデバイスを構成可能なマニフェスト（たとえば、マニフェスト１００２）を生成するためのクラウドコンピューティングサービスを実現する（各々が図８のエッジデバイス８０６の一例である、エッジデバイス１００６および１００８）。図１０のサービスプロバイダコンピュータは、クラウドコンピューティングプロバイダによって動作されるクラウドコンピューティング環境に通信可能に接続されるか、またはその一部として動作し得る。ユーザデバイス１０１０は、任意の適切な電子デバイス（たとえば、ラップトップ、デスクトップ、スマートフォンなど）であってよく、ネットワーク（たとえば、図示されていないパブリックネットワークまたはプライベートネットワーク）を介してサービスプロバイダコンピュータ１００４に通信可能に接続され得る。サービスプロバイダコンピュータ１００４は、ユーザ入力が提供され得る１つ以上のインターフェイスをホストするように構成され得る。これらのユーザインターフェイスは、構成された１つ以上のエッジデバイスに関連し得る。いくつかの実施形態では、ユーザは、少なくともエッジデバイス１００６および１００８を使用して分散コンピューティングクラスタ１０１２を動作させることを望む場合がある。任意の適切な数のエッジデバイスが、分散コンピューティングクラスタ１０１２で利用されてもよい。

フロー１０００は、サービスプロバイダコンピュータ１００４が、ユーザ入力が（たとえば、ユーザデバイス１０１０から）取得され得る１つ以上のユーザインターフェイスを公開する１０１４において開始し得る。いくつかの実施形態において、これらのユーザインターフェイスは、ユーザが、エッジデバイス１００６および１００８において構成されるさまざまなサービスおよび／またはデータプレーンリソースを選択することを可能にする。一例として、これらのインターフェイスは、構成（たとえば、サービスの特定のセット、仮想マシンの特定の数および／またはタイプ、またはエッジデバイス１００６および１００８の任意の適切な属性）を定義するために使用され得る。いくつかの実施形態では、ユーザは、エッジデバイス１００６および１００８が同じ構成／サービスセットを有することを望む場合がある。他の実施形態では、ユーザは、それぞれのエッジデバイスに対して異なる構成および／またはサービスセットを指定し得る（たとえば、一方はコンピュート集約型であり、一方はストレージ集約型であってもよい）。ユーザインターフェイスは、ユーザが１つ以上のエッジデバイス（たとえば、エッジデバイス８０６）のこれらの属性を選択および／または定義することを可能にする任意の適切なフォーマットであってよい。

１０１６において、ユーザデバイス１０１０は、サービスプロバイダコンピュータ１００４によって受信されるユーザ要求において、ユーザ入力を提出し得る。サービスプロバイダコンピュータ１００４は、クラウドコンピューティング環境内でビルドサービスをホストしている可能性がある。ビルドサービスは、ユーザ要求を受信するように構成され得る。

１０１８において、サービスプロバイダコンピュータ８０２は、ユーザ要求に対応するマニフェスト１００２（たとえば、レコード、ファイルなど）を生成し得る。マニフェスト１００２は、完了すると、ユーザ要求に従ってエッジデバイス１００６および１００８を構成するために利用され得る。いくつかの実施形態において、サービスプロバイダコンピュータ１００４は、事前に定義されたテンプレートに少なくとも部分的に基づいて、マニフェスト１００２を生成し得る。上述したように、マニフェスト１００２は、任意の適切なフォーマット（たとえば、ＪＳＯＮ，ＸＭＬなど）であってもよい。生成されると、サービスプロバイダコンピュータ１００４は、ユーザ要求に対応するようにマニフェスト１００２の修正を開始し得る。一例として、マニフェスト１００２は、１つ以上のエッジデバイスの構成情報を含むように修正され得る。

１０２０において、ユーザ要求に従ってマニフェスト１００２を修正し、ユーザ要求によって指定されたサービスに対応するアーティファクト、クレデンシャル、構成ファイル、エージェントなどを取得することに少なくとも部分的に基づいてＥＤ画像を生成するために、図８のステップ８１６～８２４に関して説明した動作の任意の適切な組み合わせが実行され得る。

１０２６において、サービスプロバイダコンピュータ１００４は、ＥＤ画像、マニフェスト、構成ファイル、クレデンシャル、およびエージェントをエッジデバイスに提供することによって、エッジデバイス１００６および１００８をプロビジョニングし得る。いくつかの実施形態では、マニフェストを作成したもの以外の別のサービスプロバイダコンピュータ（たとえば、プロビジョニングセンターに位置するサービスプロバイダコンピュータ）が、分散コンピューティングクラスタ１０１２のエッジデバイス（この場合、エッジデバイス１００６および１００８）に対するプロビジョニング動作を実行可能であることが理解されるべきである。

１０２８において、各エッジデバイスは、マニフェスト１００２に従って１つ以上のデータプレーンリソースをプロビジョニングするための任意の適切な動作を実行し得る。一例として、エッジデバイス１００６（および／またはエッジデバイス１００８）上で実行されるネットブートエージェントが、ＰＸＥブート、パーティション、ｄｍｃｒｙｐｔのセットアップ、ファイルシステムのフォーマット、（サービスプロバイダコンピュータへの）アーティファクトＵＲＬの問い合わせ、ＵＲＬを使用したデータストアからのアーティファクトのフェッチ、ルートファイルシステムのＯＳｔｒｅｅリポジトリへのコミット、コンテナのコンテナリポジトリへのロード、ＯＳｔｒｅｅコミットのデプロイ、リモートキー（たとえば、オブジェクトストアディスクにアクセスするための顧客パスワード）のフェッチおよびローカルキーのインストール、Ｔｒｅｎｃｈｂｏｏｔのインストール、およびＯＳパーティションＬＵＫＳキーのブートパーティションへの封印、といった動作を実行し得る。

エッジデバイス（複数可）１００６および１００８が構成された後、クラウドコンピューティングプロバイダは、エッジデバイス（複数可）を出荷するか、または他の態様では顧客に配送し得る。エッジデバイスは、１０１６で提供されたユーザ入力に従って、分散コンピューティングクラスタ１０１２として動作するように構成され得る。

その後、エッジデバイス１００８は、何らかの理由（たとえば、１０３０においてシステム障害が発生）で動作を停止することがある。１０３４において、ユーザデバイス１０１０（または任意の適切なユーザデバイス）は、代替デバイス（たとえば、図８のエッジデバイス８０２とエッジデバイス１００６および１００８との一例であるエッジデバイス１０３２）を要求するために使用可能である。

１０３６において、サービスプロバイダコンピュータ８０２は、ユーザ要求に従ってエッジデバイス１０３２を構成するのに必要な構成情報を含むように、マニフェスト１００２を更新し得る。いくつかの実施形態において、ユーザ要求は、エッジデバイス１０３２が、同じ構成（たとえば、サービスセット、データプレーンリソースなど）で、エッジデバイス１００８の正確な代替として構成されることを指定し得るか、またはいくつかの実施形態において、ユーザ要求は、異なる構成が使用されることを示すことができる。

１０３８において、図８のステップ８１６～８２４に関して議論された動作と１０２０における動作との任意の適切な組み合わせが、ユーザ要求に従ってマニフェスト１００２を修正し、ユーザ要求によって指定されたサービスに対応するアーティファクト、クレデンシャル、構成ファイル、エージェントなどを取得することに少なくとも部分的に基づいてＥＤ画像を生成するために、実行され得る。

１０４０において、サービスプロバイダコンピュータ１００４は、ＥＤ画像、マニフェスト、構成ファイル、クレデンシャル、およびエージェントをエッジデバイスに提供するエッジデバイス１０３２をプロビジョニングし得る。いくつかの実施形態では、マニフェストを作成したものとは別のサービスプロバイダコンピュータ（たとえば、プロビジョニングセンターに位置するサービスプロバイダコンピュータ）が、エッジデバイス１０３２のためのプロビジョニング動作を実行し得ることが理解されるべきである。構成されると、エッジデバイス１０３２は、分散コンピューティングクラスタ１０１２の一部として動作し得る。

図示されていないが、任意の適切な時間に、エッジデバイス１００８（または分散コンピューティングクラスタ１０１２の任意のエッジデバイス）は、サービスプロバイダに物理的に返され、同じまたは異なるマニフェスト（たとえば、マニフェスト１００２）を使用して以前に提供された構成と同じ構成および／または異なる構成で再構成され得る。

図１１は、少なくとも１つの実施形態に係る、エッジコンピューティングデバイス（図１～図８、図１０および図１１のエッジデバイスの一例）において１つ以上のデータプレーンリソースをプロビジョニングするためのアーキテクチャ１１００およびフローを示すブロック図である。アーキテクチャ１１００は、制御プレーン１１０２およびデータプレーン１１０４を含み得る。

いくつかの実施形態において、制御プレーン１１０２は、１つ以上のデータプレーンリソースのセットの意図された状態を記述する意図された状態データを含む作業要求を受け入れる役割を担い得る。たとえば、作業要求は、制御プレーンアプリケーションプログラミングインタフェース（ＡＰＩ）１１０６によって受信され得る。いくつかの実施形態において、作業要求は、マニフェスト（たとえば、図８のフロー８００または図１０のフロー１０００によって生成されたマニフェストの例であるマニフェスト１００１）の形態であり得る。いくつかの実施形態において、制御プレーンＡＰＩ１１０６は、図５のサービス（複数可）５０２の一例であり得る。制御プレーンＡＰＩ１１０６は、ユーザデバイスから１つ以上のデータリソース（たとえば、仮想マシン、仮想マシンのクラスタなど）に対応する任意の適切な数の作業要求（たとえば、マニフェスト１００１）を受信するように構成され得る。

いくつかの実施形態では、マニフェスト１００１は、マニフェスト１００１を他の作業要求と区別できるように、作業要求として一意に識別し得る識別子を含み得る。要求識別子は、その作業要求に固有であり、かつその作業要求を識別することができる、任意の適切な長さの英数字の文字列とすることができる。意図された状態データは、任意の適切な数のパラメータを含み得る。これらのパラメータは、リソースの識別子、可用性ドメイン、ノードに対応する形状、リソースの処理ユニット数、リソースのランダムアクセスメモリ（ＲＡＭ）の容量、ディスクメモリの容量、役割（たとえば、データノード、マスターノードなど）、状態（たとえば、健全性）などを含むが、これらに限定されない、要求されたデータプレーンリソースの属性を定義し得る。いくつかの実施形態において、制御プレーンＡＰＩ１１０６は、すべての受信された作業要求（たとえば、マニフェスト１００１）をデータストア（たとえば、図１１のコンポーネントを実行するエッジデバイスが動作するエッジデバイスのクラスタによって実現される分散データストアである制御プレーン（ＣＰ）データストア１１０８）に格納するように構成され得る。

いくつかの実施形態において、ＣＰデータストア１１０８は、データプレーン１１０４の意図された状態に対応する作業要求および／または意図された状態データを格納するように構成され得る。いくつかの実施形態において、ＣＰデータストア１１０８は、ＤＰリソース１１１２（複数可）の１つ以上のデータプレーン識別子（data plane identifier：ＤＰＩＤ）と、意図された状態データおよび／または現在の状態データとのマッピングを記憶するように構成され得る。意図された状態データとは、要求され、かつそれに対してＤＰリソースが修正されることが意図されているＤＰリソースの１つ以上の態様を指定するデータである。現在の状態データ（「実際の状態データ」と呼ばれることもある）は、現在動作しているＤＰリソースの１つ以上の現在の態様を特定する１つ以上のパラメータに対応する。

制御プレーン１１０２は、制御プレーン（control plane：ＣＰ）監視コンポーネント１１１０を含み得る。ＣＰ監視コンポーネント１１１０は、制御プレーンＡＰＩ１１０６によって受信され、かつＣＰデータストア１１０８に格納された（たとえば、以前に受信された作業要求からの）意図された状態データが、対応するＤＰリソース（そのＤＰリソースが現在存在する場合）について格納された現在の状態データと一致するかどうかを、定期的に（たとえば、所定の頻度、スケジュール等に従って）判定するように構成され得る。ＣＰ監視コンポーネント１１１０は、（たとえば、図５の基板ネットワーク５０４を介して）非コンピュートサービス（複数可）１１１４に通信可能に結合されてもよく、非計算サービス（複数可）１１１４は、課金、ＩＤ、認可などを管理するように構成された任意の適切な数のクラウドコンピューティングサービスを含み得る。いくつかの実施形態では、ＣＰ監視コンポーネント１１１０、インメモリワークフローマネージャ１１１６、およびＣＰワーカー（複数可）１１１８は、共通のサービス（たとえば、図７のサービス７０６）によって提供される。サービス７０６は、図５のサービス（複数可）５０２のうちの１つであり得る。非コンピュートサービス（複数可）１１１４は、制御プレーンＡＰＩ１１０６と、ＣＰ監視コンポーネント１１１０、インメモリワークフローマネージャ１１１６、およびＣＰワーカー１１１８（複数可）を実装するサービス（たとえば、サービス７０６）とを除く、サービス（複数可）５０２の残りのサービスセットであり得る。いくつかの実施形態において、ＣＰ監視コンポーネント１１１０は、インメモリワークフローマネージャ１１１６と通信可能に結合されてもよく、インメモリワークフローマネージャ１１１６によって提供される機能を呼び出すように構成され得る。一例として、ＣＰ監視コンポーネント１１１０は、ＤＰリソースの現在の状態データがＣＰデータストア８１４に格納された意図された状態データに沿っていない（たとえば、一致しない）と判定した場合、不一致を修正するためにインメモリワークフローマネージャ１１１６の機能を呼び出し得る。

いくつかの実施形態では、インメモリワークフローマネージャ１１１６は、対応する意図された状態データに従ってＤＰリソース（複数可）１１１２を構成するために実行する動作を個々に識別する１つ以上の事前に定義されたワークフローを識別するように構成され得る。いくつかの実施形態において、インメモリワークフローマネージャ１１１６は、制御プレーン（ＣＰ）ワーカー（複数可）１１１８の１つ以上のワーカー（たとえば、計算スレッド）を開始し、受信した意図された状態データに従って対応するＤＰリソース（複数可）を構成することに関連する動作を実行するために、ワークフロー命令および／または意図された状態データを、所与のＣＰワーカーに転送するように構成され得る。いくつかの実施形態では、ＣＰワーカー（複数可）１１１８は、サービス固有のオーケストレーション動作を提供し得る。ＣＰワーカー（複数可）１１１８は、コンピュートサービス、格納サービスなどの任意の適切な組み合わせを含む任意の適切な数のサービス（たとえば、非コンピュートサービス（複数可）１１１４）に通信可能に結合され得る。いくつかの実施形態では、ＣＰワーカー（複数可）１１１８は、１つ以上のＤＰリソースを構成するための指示を、データプレーン（ＤＰ）マネージャ１１２２に提供するように構成され得る。ＤＰマネージャ１１２２（たとえば、図７のハイパーバイザサービス７０８の例）は、任意の適切なＤＰリソースを作成、修正、および／または除去または削除するように構成され得る。

いくつかの実施形態では、ＤＰマネージャ１１２２は、任意の適切な数のコンピューティングコンポーネント（たとえば、集合的に、コンピューティングクラスタの例であり得るＤＰリソース（複数可）１１１２）を管理するように構成され得る。いくつかの実施形態では、ＤＰマネージャ１１２２は、任意の適切なタイプのコンピューティングクラスタ（たとえば、Ｋｕｂｅｒｎｅｔｅｓクラスタ、コンテナ化されたアプリケーションを実行するために使用されるコンピューティングノードのセットなど）を管理するように構成され得る。ＣＰワーカー（複数可）１１１８は、意図された状態データに従ってＤＰリソース（複数可）１１１２を構成するために、インメモリワークフローマネージャ１１１６によって識別された命令に従って、ＤＰマネージャ（複数可）１１２２に、ＤＰリソース（複数可）１１１２上で任意の適切なオーケストレーション動作を実行させるために、任意の適切な動作を実行するように構成されてもよい。いくつかの実施形態において、ＣＰ監視コンポーネント１１１０は、ＤＰリソース（複数可）１１１２に通信可能に結合され、ＤＰリソース（複数可）１１１２の健全性を監視するように構成され得る。いくつかの実施形態において、ＣＰ監視コンポーネント１１１０は、ＤＰリソース（複数可）１１１２の１つ以上の健全性を示す任意の適切な健全性データを（たとえば、任意の適切な形態の電子通信を使用してユーザデバイスに）送信するように構成され得る。一例として、ＣＰ監視コンポーネント１１１０は、制御プレーンＡＰＩ１１０６を介して、任意の適切な健全性データをユーザデバイスに送信し得る。

いくつかの実施形態において、ＣＰ監視コンポーネント１１１０は、ＤＰリソース（複数可）１１１２の現在の状態データを監視し、評価するように構成され得る。いくつかの実施形態において、ＣＰ監視コンポーネント１１１０は、ＣＰデータストア１１０８内のＤＰリソース（複数可）１１１２の現在の状態データを格納／更新し得る。現在の状態データは、ＤＰマネージャ１１２２によって対応するＣＰワーカーに提供されてもよく、ＣＰワーカーは、現在の状態データをインメモリワークフローマネージャ８２０に提供してもよく、インメモリワークフローマネージャ８２０は、現在の状態データをＣＰ監視コンポーネント１１１０に提供し得る。いくつかの実施形態では、ＣＰワーカー１１１８（複数可）および／またはインメモリワークフローマネージャ１１１６は、所与のＤＰリソースの現在の状態データがＣＰ監視コンポーネント１１１０によって任意の適切な時間に取得されるように、ＣＰデータストア１１０８を任意の適切なＤＰリソースの現在の状態データで直接更新してもよい。

ＣＰ監視コンポーネント１１１０、インメモリワークフローマネージャ１１１６、およびＣＰワーカー（複数可）１１１８は、制御プレーン１１０２の別個のコンポーネントとして示されているが、いくつかの実施形態では、ＣＰ監視コンポーネント１１１０、インメモリワークフローマネージャ１１１６、および／またはＣＰワーカー（複数可）１１１８の任意の適切な組み合わせが、１つのサービス（たとえば、図７のサービス７０６、図５のサービス（複数可）５０２のうちのサービスの１つの例）によって提供され得る。

図１２は、少なくとも１つの実施形態に係る、エッジコンピューティングデバイスにおいてインメモリワークフロー管理を提供するための例示的な方法１２００を示すブロック図である。方法１２００は、任意の適切な数のサービスプロバイダコンピュータ（たとえば、図８のサービスプロバイダコンピュータ）によって実行され得る。いくつかの実施形態では、方法１２００は、図１２に示す数よりも多いまたは少ない数のステップを含み得る。方法１２００のステップは、任意の適切な順序で実行されてもよいことが理解されるべきである。

方法１２００は、第１のクラウドコンピューティングエッジデバイスにおいて実行すべき第１のサービスセットを指定する第１のユーザ要求が、クラウドコンピューティングプロバイダによって動作されるコンピューティングデバイスによって受信され得る１２０２において開始し得る。このコンピューティングデバイスの例は、図８のサービスプロバイダコンピュータ８０２を含み得る。いくつかの実施形態において、クラウドコンピューティングエッジデバイスは、パブリックネットワークへのアクセスがない隔離されたコンピューティング環境内で実行されている間、隔離されたコンピューティング環境内で選択的に実行するように構成されたデバイスであり得る。たとえば、クラウドコンピューティングエッジデバイスは、図１～図８、図１０、および図１１に関して上述したエッジデバイスの一例であってもよい。

１２０４において、第１のマニフェストが、第１のユーザ要求に少なくとも部分的に基づいて生成され得る。第１のマニフェストは、第１のクラウドコンピューティングエッジデバイスのための第１の構成を指定し得る。いくつかの実施形態において、第１の構成は、第１のユーザ要求に従って、第１のサービスセットを構成する。第１のマニフェストは、図９のマニフェスト９００の一例であってもよい。

１２０６において、第１のクラウドコンピューティングエッジデバイスに、第１のマニフェストに従って、第１のサービスセットがプロビジョニングされ得る。

１２０８において、第２のクラウドコンピューティングエッジデバイスにおいて実行すべき第２のサービスセットを指定する第２のユーザ要求が、コンピューティングデバイスによって受信され得る。いくつかの実施形態において、第２のサービスセットは、第１のサービスセットと異なり得る。

１２１０において、第２のマニフェストが、第２のユーザ要求に少なくとも部分的に基づいて生成され得る。いくつかの実施形態において、第２のマニフェストは、第２のクラウドコンピューティングエッジデバイスのための第２の構成を指定し、第２の構成は第２のサービスセットを含む。第２のマニフェストは、図９のマニフェスト９００の別の例であってもよい。

１２１２において、第２のクラウドコンピューティングエッジデバイスに、第２のマニフェストに従って、第２のサービスセットがプロビジョニングされ得る。いくつかの実施形態では、第２のクラウドコンピューティングエッジデバイスに、第１のクラウドコンピューティングエッジデバイスにおいてプロビジョニングされたサービスとは異なるサービスがプロビジョニングされ得る。

特定の実施形態を説明してきたが、さまざまな変更、改変、代替構成、および均等物も本開示の範囲内に包含される。実施形態は、特定のデータ処理環境内での動作に限定されず、複数のデータ処理環境内で自由に動作することができる。さらに、特定の一連の処理およびステップを用いて実施形態を説明してきたが、本開示の範囲が説明された一連の処理およびステップに限定されないことは、当業者には明らかであろう。上述した実施形態のさまざまな特徴および態様は、個別にまたは共同で使用することができる。

さらに、ハードウェアおよびソフトウェアの特定の組み合わせを用いて実施形態を説明してきたが、ハードウェアおよびソフトウェアの他の組み合わせも本開示の範囲内に含まれることを認識すべきである。ハードウェアのみにおいて、ソフトウェアのみにおいて、またはそれらの組み合わせを用いて、実施形態を実施することができる。本開示に記載されたさまざまなプロセスは、同一のプロセッサまたは任意の組み合わせの異なるプロセッサ上で実行することができる。したがって、コンポーネントまたはモジュールが特定の動作を実行するように構成されると説明する場合、その構成は、たとえば、その処理を実行するように電子回路を設計することによって、その動作を実行するようにプログラム可能な電子回路（マイクロプロセッサなど）をプログラムすることによって、またはそれらの組み合わせによって、実現することができる。プロセスは、プロセス間通信を行う従来技術を含むがこれに限定されないさまざまな技術を用いて、通信を行うことができる。異なる対のプロセスは、異なる技術を使用することができ、または同じ対のプロセスは、異なる時間に異なる技術を使用することができる。実施形態は、プロセッサによって実行されると、プロセッサに本開示に記載の方法のいずれかを実行させるコンピュータプログラム命令を含むコンピュータプログラム製品を使用することによって、実施することができる。

したがって、明細書および図面は、限定的な意味ではなく例示的な意味であるとみなされるべきである。しかしながら、特許請求の範囲により定められた幅広い主旨および範囲から逸脱することなく、追加、削減、削除および他の修正および変更を行ってもよいことは、明らかであろう。したがって、本開示の特定の実施形態を説明したが、これらの実施形態は、限定することを意図していない。さまざまな修正および等価物は、添付の特許請求の範囲に含まれる。

本開示を説明する文脈（特に特許請求の範囲の文脈）において使用された不定冠詞「a」、「an」、定冠詞「the」および同様の参照は、本開示に特に明記しない限りまたは内容上明らかに他の意味を示す場合を除き、単数および複数の両方を含むように解釈すべきである。用語「備える（comprising）」、「有する（having）」、「含む（including）」、および「含有する（containing）」は、特に明記しない限り、非限定的な用語（すなわち、「含むがこれに限定されない」という意味）として解釈されるべきである。「接続されている」という用語は、たとえ何かが介在していても、その一部または全部が内部に含まれている、取り付けられている、または一緒に結合されていると解釈されるべきである。本開示における値の範囲の記載は、単にその範囲内に入る各個別の値を個別に参照するための略記法としての役割を果たすことを意図したものであり、本明細書に特に明記しない限り、各個別の値は、本明細書において個別に記載されているかのように、本開示に組み込まれる。本明細書において特に明記しない限り、または内容上明らかに他の意味を示す場合を除き、本明細書に記載の全ての方法は、任意の適切な順序で実行することができる。本明細書において記載されるあらゆる例、または例示的な文言（たとえば、「～のような」）の使用は、単に実施形態をより明らかにすることを意図しており、別段の主張がない限り、本開示の範囲を限定するものではない。本明細書中のいかなる用語も、本開示の実施に不可欠な任意の非請求要素を示すものと解釈すべきではない。

「Ｘ，ＹまたはＺの少なくとも１つ」というフレーズのような選言的言語は、特に断らない限り、項目、用語などがＸ，ＹもしくはＺ、またはそれらの任意の組み合わせ（たとえば、Ｘ，Ｙおよび／またはＺ）のいずれかであってもよいことを示すために、一般的に用いられるものとして文脈内で理解されることを意図している。したがって、このような選言的言語は、特定の実施形態が、Ｘの少なくとも１つ、Ｙの少なくとも１つ、またはＺの少なくとも１つが存在することを必要とすると一般的に意図しておらず、また、それを暗示していない。

本開示を実施するために知られている最良の形態を含む本開示の好ましい実施形態が本明細書に記載されている。これらの好ましい実施形態の変形例は、前述の説明を読めば当業者には明らかになるであろう。当業者は、適宜、このような変形例を採用することができ、本開示は、本明細書に具体的に記載されている以外の態様で実施されてもよい。したがって、本開示は、適用法によって許容される、本明細書に添付の特許請求の範囲に記載された主題のすべての変形および均等物を含む。さらに、本明細書において別段の記載がない限り、上述した要素のあらゆる可能な変形における組み合わせは、本開示に包含される。

本明細書に引用された刊行物、特許出願、および特許を含む全ての参考文献は、各文献が引用により援用されることが個別にかつ明確に示され、その全体が本明細書に記載された場合と同じ程度に、引用により援用されるものとする。

前述の明細書において、本開示の態様は、その特定の実施形態を参照して説明されているが、当業者であれば、本開示がそれに限定されないことを認識するであろう。上述の開示のさまざまな特徴および態様は、個々にまたは共同で使用されてもよい。さらに、実施形態は、本明細書のより広い精神および範囲から逸脱することなく、本明細書に記載されるものを超える任意の数の環境および用途において利用することができる。したがって、明細書および図面は、限定的ではなく例示的であると見なされるべきである。

Claims (21)

1. コンピュータによって実現される方法であって、
   クラウドコンピューティングプロバイダによって動作されるコンピューティングデバイスが、第１のクラウドコンピューティングエッジデバイスにおいて実行すべき第１のサービスセットを指定する第１のユーザ要求を受信することを含み、クラウドコンピューティングエッジデバイスは、パブリックネットワークへのアクセスがない隔離されたコンピューティング環境内で実行されている間、前記隔離されたコンピューティング環境内で選択的に実行されるように構成されたデバイスであり、前記方法はさらに、
   コンピューティングデバイスが、前記第１のユーザ要求に少なくとも部分的に基づいて、前記第１のクラウドコンピューティングエッジデバイスのための第１の構成を指定する第１のマニフェストを生成することを含み、前記第１の構成は前記第１のサービスセットを含み、前記方法はさらに、
   前記コンピューティングデバイスが、前記第１のマニフェストに従って、前記第１のクラウドコンピューティングエッジデバイスに前記第１のサービスセットをプロビジョニングすることと、
   前記コンピューティングデバイスが、第２のクラウドコンピューティングエッジデバイスにおいて実行すべき第２のサービスセットを指定する第２のユーザ要求を受信することと、
   前記コンピューティングデバイスが、前記第２のユーザ要求に少なくとも部分的に基づいて、前記第２のクラウドコンピューティングエッジデバイスのための第２の構成を指定する第２のマニフェストを生成することとを含み、前記第２の構成は第２のサービスセットを含み、前記方法はさらに、
   前記コンピューティングデバイスが、前記第２のマニフェストに従って、前記第２のクラウドコンピューティングエッジデバイスに前記第２のサービスセットをプロビジョニングすることを含む、方法。
2. 前記第１のマニフェストまたは前記第２のマニフェストの少なくとも１つが事前に定義され、クラウドコンピューティングエッジデバイスに関連付けられたシリアル番号、前記クラウドコンピューティングエッジデバイスに対応するホスト名、前記クラウドコンピューティングエッジデバイスのネットワークインターフェイスデバイスに対応するアドレスを有するメディアアクセスコントローラ、または１つ以上のサービスに対応する１つ以上のネットワークアドレスのうちの少なくとも１つをさらに指定する、請求項１に記載のコンピュータによって実現される方法。
3. 前記第１のクラウドコンピューティングエッジデバイスは、前記隔離されたコンピューティング環境内でコンピューティングクラスタとして動作するように構成された複数のクラウドコンピューティングエッジデバイスのうちの１つであり、前記第１のマニフェストは、前記複数のクラウドコンピューティングエッジデバイスの各クラウドコンピューティングエッジデバイスにおいて実行すべき対応するサービスセットを指定する、請求項１または２に記載のコンピュータによって実現される方法。
4. 前記第１のサービスセットと前記第２のサービスセットとは同じである、請求項１～３のいずれか１項に記載のコンピュータによって実現される方法。
5. 前記第１のマニフェストを生成することは、前記第１のユーザ要求で指定された前記第１のサービスセットの各サービスに対応するアーティファクトを取得することを含む、請求項１～４のいずれか１項に記載のコンピュータによって実現される方法。
6. 前記第１のマニフェストを生成することは、前記第１のサービスセットのうちのサービスに対応するアーティファクトに個別に関連付けられた１つ以上の実行可能スクリプトを実行することを含み、前記１つ以上の実行可能スクリプトを実行することは、１つ以上のエンティティ定義を含むように前記第１のマニフェストを修正し、各エンティティ定義は、デバイスまたはサービスに対応する、請求項１～５のいずれか１項に記載のコンピュータによって実現される方法。
7. 前記第１のマニフェストを生成することは、前記マニフェスト内で定義された１つ以上のエンティティにネットワークアドレスを割り当てることを含む、請求項１～６のいずれか１項に記載のコンピュータによって実現される方法。
8. コンピューティングデバイスであって、
   １つ以上のプロセッサと、
   コンピュータ実行可能命令を含む１つ以上のメモリとを備え、前記コンピュータ実行可能命令は、前記１つ以上のプロセッサによって実行されると、前記コンピューティングデバイスに、
   第１のクラウドコンピューティングエッジデバイスにおいて実行すべき第１のサービスセットを指定する第１のユーザ要求を受信させ、クラウドコンピューティングエッジデバイスは、パブリックネットワークへのアクセスがない隔離されたコンピューティング環境内で実行されている間、前記隔離されたコンピューティング環境内で選択的に実行されるように構成されたデバイスであり、前記コンピューティングデバイスはクラウドコンピューティングプロバイダによって動作され、前記コンピュータ実行可能命令はさらに前記コンピューティングデバイスに、
   前記第１のユーザ要求に少なくとも部分的に基づいて、前記第１のクラウドコンピューティングエッジデバイスのための第１の構成を指定する第１のマニフェストを生成させ、前記第１の構成は前記第１のサービスセットを含み、前記コンピュータ実行可能命令はさらに前記コンピューティングデバイスに、
   前記第１のマニフェストに従って、前記第１のクラウドコンピューティングエッジデバイスに前記第１のサービスセットをプロビジョニングさせ、
   第２のクラウドコンピューティングエッジデバイスにおいて実行すべき第２のサービスセットを指定する第２のユーザ要求を受信させ、
   前記第２のユーザ要求に少なくとも部分的に基づいて、前記第２のクラウドコンピューティングエッジデバイスのための第２の構成を指定する第２のマニフェストを生成させ、前記第２の構成は前記第２のサービスセットを含み、前記コンピュータ実行可能命令はさらに、
   前記第２のマニフェストに従って、前記第２のクラウドコンピューティングエッジデバイスに前記第２のサービスセットをプロビジョニングさせる、コンピューティングデバイス。
9. 前記第１のマニフェストまたは前記第２のマニフェストの少なくとも１つは、事前に定義されており、クラウドコンピューティングエッジデバイスに関連付けられたシリアル番号、前記クラウドコンピューティングエッジデバイスに対応するホスト名、前記クラウドコンピューティングエッジデバイスのネットワークインターフェイスデバイスに対応するアドレスを有するメディアアクセスコントローラ、または１つ以上のサービスに対応する１つ以上のネットワークアドレスのうちの少なくとも１つをさらに指定する、請求項８に記載のコンピューティングデバイス。
10. 前記第１のクラウドコンピューティングエッジデバイスは、前記隔離されたコンピューティング環境内でコンピューティングクラスタとして動作するように構成された複数のクラウドコンピューティングエッジデバイスのうちの１つであり、前記第１のマニフェストは、前記複数のクラウドコンピューティングエッジデバイスの各クラウドコンピューティングエッジデバイスにおいて実行すべき対応するサービスセットを指定する、請求項８または９に記載のコンピューティングデバイス。
11. 前記第１のサービスセットと前記第２のサービスセットとは同じである、請求項８～１０のいずれか１項に記載のコンピューティングデバイス。
12. 前記第１のマニフェストを生成することは、前記第１のユーザ要求で指定された前記第１のサービスセットの各サービスに対応するアーティファクトを取得することを含む、請求項８～１１のいずれか１項に記載のコンピューティングデバイス。
13. 前記第１のマニフェストを生成することは、前記第１のサービスセットのうちのサービスに対応するアーティファクトに個別に関連付けられた１つ以上の実行可能スクリプトを実行することを含み、前記１つ以上の実行可能スクリプトを実行することは、１つ以上のエンティティ定義を含むように前記第１のマニフェストを修正し、各エンティティ定義は、デバイスまたはサービスに対応する、請求項８～１２のいずれか１項に記載のコンピューティングデバイス。
14. 前記第１のマニフェストを生成することは、前記マニフェスト内で定義された１つ以上のエンティティにネットワークアドレスを割り当てることを含む、請求項８～１３のいずれか１項に記載のコンピューティングデバイス。
15. コンピュータ読取可能命令を格納した非一時的なコンピュータ読取可能記憶媒体であって、前記コンピュータ読取可能命令は、クラウドコンピューティングプロバイダによって動作されるコンピューティングデバイスの１つ以上のプロセッサによって実行されると、前記コンピューティングデバイスに、
    第１のクラウドコンピューティングエッジデバイスにおいて実行すべき第１のサービスセットを指定する第１のユーザ要求を受信させ、クラウドコンピューティングエッジデバイスは、パブリックネットワークへのアクセスがない隔離されたコンピューティング環境内で実行されている間、前記隔離されたコンピューティング環境内で選択的に実行されるように構成されたデバイスであり、前記コンピュータ読取可能命令はさらに前記コンピューティングデバイスに、
    前記第１のユーザ要求に少なくとも部分的に基づいて、前記第１のクラウドコンピューティングエッジデバイスのための第１の構成を指定する第１のマニフェストを生成させ、前記第１の構成は前記第１のサービスセットを含み、前記コンピュータ読取可能命令はさらに前記コンピューティングデバイスに、
    前記第１のマニフェストに従って、前記第１のクラウドコンピューティングエッジデバイスに前記第１のサービスセットをプロビジョニングさせ、
    第２のクラウドコンピューティングエッジデバイスにおいて実行すべき第２のサービスセットを指定する第２のユーザ要求を受信させ、
    前記第２のユーザ要求に少なくとも部分的に基づいて、前記第２のクラウドコンピューティングエッジデバイスのための第２の構成を指定する第２のマニフェストを生成させ、前記第２の構成は前記第２のサービスセットを含み、前記コンピュータ読取可能命令はさらに前記コンピューティングデバイスに、
    前記第２のマニフェストに従って、前記第２のクラウドコンピューティングエッジデバイスに前記第２のサービスセットをプロビジョニングさせる、非一時的なコンピュータ読取可能記憶媒体。
16. 前記第１のマニフェストまたは前記第２のマニフェストの少なくとも１つが事前に定義され、クラウドコンピューティングエッジデバイスに関連付けられたシリアル番号、前記クラウドコンピューティングエッジデバイスに対応するホスト名、前記クラウドコンピューティングエッジデバイスのネットワークインターフェイスデバイスに対応するアドレスを有するメディアアクセスコントローラ、または１つ以上のサービスに対応する１つ以上のネットワークアドレスのうちの少なくとも１つをさらに指定する、請求項１５に記載の非一時的なコンピュータ読取可能記憶媒体。
17. 前記第１のクラウドコンピューティングエッジデバイスは、前記隔離されたコンピューティング環境内でコンピューティングクラスタとして動作するように構成された複数のクラウドコンピューティングエッジデバイスのうちの１つであり、前記第１のマニフェストは、前記複数のクラウドコンピューティングエッジデバイスの各クラウドコンピューティングエッジデバイスにおいて実行すべき対応するサービスセットを指定する、請求項１５または１６に記載の非一時的なコンピュータ読取可能記憶媒体。
18. 前記第１のサービスセットと前記第２のサービスセットとは同じである、請求項１５～１７のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
19. 前記第１のマニフェストを生成することは、前記第１のユーザ要求で指定された前記第１のサービスセットの各サービスに対応するアーティファクトを取得することを含む、請求項１５～１８のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
20. 前記第１のマニフェストを生成することは、
    前記第１のサービスセットのうちのサービスに対応するアーティファクトに個別に関連付けられた１つ以上の実行可能スクリプトを実行することを含み、前記１つ以上の実行可能スクリプトを実行することは、１つ以上のエンティティ定義を含むように前記第１のマニフェストを修正し、各エンティティ定義は、デバイスまたはサービスに対応し、前記第１のマニフェストを生成することはさらに、
    前記マニフェスト内で定義された１つ以上のエンティティにネットワークアドレスを割り当てることを含む、請求項１５～１９のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
21. コンピュータプログラム命令を含むコンピュータプログラム製品であって、前記コンピュータプログラム命令は、プロセッサによって実行されると、前記プロセッサに、
    第１のクラウドコンピューティングエッジデバイスにおいて実行すべき第１のサービスセットを指定する第１のユーザ要求を受信させ、クラウドコンピューティングエッジデバイスは、パブリックネットワークへのアクセスがない隔離されたコンピューティング環境内で実行されている間、前記隔離されたコンピューティング環境内で選択的に実行されるように構成されたデバイスであり、前記コンピュータプログラム命令はさらに前記プロセッサに、
    前記第１のユーザ要求に少なくとも部分的に基づいて、前記第１のクラウドコンピューティングエッジデバイスのための第１の構成を指定する第１のマニフェストを生成させ、前記第１の構成は前記第１のサービスセットを含み、前記コンピュータプログラム命令はさらに前記プロセッサに、
    前記第１のマニフェストに従って、前記第１のクラウドコンピューティングエッジデバイスに前記第１のサービスセットをプロビジョニングさせ、
    第２のクラウドコンピューティングエッジデバイスにおいて実行すべき第２のサービスセットを指定する第２のユーザ要求を受信させ、
    前記第２のユーザ要求に少なくとも部分的に基づいて、前記第２のクラウドコンピューティングエッジデバイスのための第２の構成を指定する第２のマニフェストを生成させ、前記第２の構成は前記第２のサービスセットを含み、前記コンピュータプログラム命令はさらに、
    前記第２のマニフェストに従って、前記第２のクラウドコンピューティングエッジデバイスに前記第２のサービスセットをプロビジョニングさせる、コンピュータプログラム製品。

Images