JP7426636B2 - 分散型エッジクラウドコンピューティングのための方法およびシステム - Google Patents

Description

発明の分野
本開示は、一般にクラウドコンピューティングに関する。具体的には、該本開示は、分散型エッジクラウドコンピューティングのための方法およびシステムに関する。

発明の背景
一般的には、最もポピュラーな民生用アプリケーションおよびソリューション、および企業向けアプリケーションおよびソリューションのうちのいくつかは、通常「クラウド」と呼ばれているデータセンターにホストされている。クラウドコンピューティングは、Ｆａｃｅｂｏｏｋ（登録商標）、ＹｏｕＴｕｂｅ（登録商標）、Ｉｎｓｔａｇｒａｍ（登録商標）、ＤｒｏｐＢｏｘ（登録商標）等のアプリケーションを使用可能にするのに必要不可欠になってきている。基本的なアーキテクチャは、いくつかのノードまたはコンピューティングデバイスが「サーバ」として機能し、および他のノードまたはコンピューティングデバイスが「クライアント」として機能するクライアント／サーバアーキテクチャに対応している。今日のコンピューティングデバイスまたはノードの大多数は、サーバの大部分が、世界中に散在しているサーバファームで構成されたデータセンターに配設されているクライアント／サーバモードで作動する。このような据え付けのおよび階層的なクライアントサーバアーキテクチャは、コンテンツおよび情報をリモートサーバから多数のクライアント装置へアクセスできるようにしているアプリケーションのホスティングにとって効率的である可能性がある。典型的には、ソリューションのバックエンドは、数値計算タスクを処理する該サーバ上にホストされ、また、ソリューションのクライアントアプリケーションソフトウェア（フロントエンド）は、コマンドの入力、コンテンツのキャッシュへの格納、およびエンドユーザのための情報のレンダリング等の、よりシンプルな機能に用いられる「エッジデバイス」上にホストされている。

このアーキテクチャの利点の一つは、可視化テクノロジーおよびオーケストレーションテクノロジーを活用した、多くのアプリケーション間で共用される汎用サーバ上での（コンピューティングおよび／またはストレージ集約的）アプリケーションの迅速かつ低コストでの展開である。しかし、最近十年間では、階層的クライアント／サーバアーキテクチャをあまり効率的でないものにするさまざまな傾向が見られている。現在の階層的アーキテクチャにおける中央クラウドリソースおよびネットワーク接続性は、将来的な成長にとって潜在的なボトルネックである。数千億のクライアント装置から数千万の集中型クラウドサーバへのデータの送信は、帯域幅およびエネルギーの浪費につながり、および深刻な社会的および経済的な影響を及ぼす。

中央クラウドアーキテクチャのさらに別のデメリットは、クラウドサービスプロバイダのサーバに格納されたまたは該サーバで処理される該アプリケーションおよびデータにアクセスできる該プロバイダへの開発者の依存である。その結果として、今日では、一握りの大企業が、消費者データおよび企業データの大部分を管理している。さらに、すべての洗練されたセキュリティ対策にもかかわらず、サードパーティーリソースへのデータの格納およびアプリケーションのホスティングは、該情報の所有者を多くのリスクにさらしている。クラウドリソースは、脆弱性やセキュリティホールを同様に増す数百万の開発者およびアプリケーションサービスプロバイダへの容易なアクセスのために設計されてきた。このことは、場合によっては、消費者データおよび企業データのプライバシーおよびセキュリティの甚だしい悪習をもたらしている。

発明の概要
少なくとも上記で強調した課題や欠点に対処するための有効で実行可能なアプローチを実施するシステムおよび方法が開示されている。実施形態において、該システムは、任意のコンピューティングデバイスまたはエッジノードを一つのクラウドサーバに変えることにより、該クラウドの分散化を実施する。エッジコンピューティングデバイスをクラウドサーバに変えることにより、多くのアプリケーションに対しての中央ホスティングサービスが必要ではないため、ディジタル仲介者およびサードパーティートラスト要素の役割を低減することが可能である。このようにして、現在の「中央クラウド」ファブリックよりも潜在的に桁違いに大きい物理的な「エッジクラウドファブリック」が生み出される。

エッジクラウドコンピューティングデバイスの実施形態が開示されている。実施形態において、該エッジクラウドコンピューティングデバイスは、該エッジクラウドコンピューティングデバイスで作動しているアプリケーションからの要求を受信して、該受信した要求に応えるのに必要な一つ以上のマイクロサービスの種類を判断するように構成されたエッジノード有効化モジュールを含む。該エッジノード有効化モジュールはさらに、該判断された種類が、該エッジクラウドコンピューティングデバイスにローカルにホストされた一つ以上のマイクロサービスに対応する場合に、該要求を該エッジクラウドコンピューティングデバイスでローカルに処理するように構成されている。実施形態において、該エッジノード有効化モジュールはさらに、前記ローカルにホストされた一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を提供するように構成されている。実施形態において、該エッジノード有効化モジュールはさらに、前記要求を前記ローカルにホストされた一つ以上のマイクロサービスに送信するためのローカルにホストされたＡＰＩゲートウェイを提供するように構成されている。該一つ以上のマイクロサービスは、前記要求に応えて、前記アプリケーションに応答を返信するように構成されている。

実施形態において、該エッジノード有効化モジュールはさらに、前記受信した要求に応えるのに必要な、前記一つ以上のマイクロサービスの判断された種類が、中央クラウドコンピューティングデバイスにグローバルにホストされた一つ以上のマイクロサービスに対応する場合に、該受信した要求に対応するｈｔｔｐ／ｈｔｔｐｓリクエストを前記アプリケーションから、前記中央クラウドコンピューティングデバイスにホストされたＡＰＩゲートウェイに送信するように構成されている。前記エッジノード有効化モジュールはさらに、前記中央クラウドコンピューティングデバイスにホストされた前記ＡＰＩゲートウェイから、前記ｈｔｔｐ／ｈｔｔｐｓリクエストに対するｈｔｔｐ／ｈｔｔｐｓレスポンスを受信するように構成され、および前記ｈｔｔｐ／ｈｔｔｐｓリクエストには、前記中央クラウドコンピューティングデバイスにグローバルにホストされた前記一つ以上のマイクロサービスが応える。

実施形態において、該エッジノード有効化モジュールはさらに、前記中央クラウドコンピューティングデバイスにホストされたＡＰＩゲートウェイに前記ｈｔｔｐ／ｈｔｔｐｓリクエストを送信するためのローカルにホストされたＡＰＩゲートウェイを提供するように構成されている。実施形態において、該エッジノード有効化モジュールはさらに、前記受信した要求に応えるのに必要な前記一つ以上のマイクロサービスの判断された種類が、別のエッジクラウドコンピューティングデバイスにホストされた一つ以上のマイクロサービスに対応する場合に、該別のエッジクラウドコンピューティングデバイスにホストされた一つ以上のマイクロサービスに前記要求を直接送信するように構成されている。実施形態において、該エッジノード有効化モジュールはさらに、サイドカーパターンを実施して、前記エッジクラウドコンピューティングデバイスにローカルにホストされた前記一つ以上のマイクロサービスおよび前記別のエッジクラウドコンピューティングデバイスにホストされた前記一つ以上のマイクロサービスに対応するサービスメッシュを形成するように構成されている。

実施形態において、該エッジノード有効化モジュールはさらに、一つ以上の他のエッジクラウドコンピューティングデバイスとの接続を確立するためのパラメータの第一のセットに基づいて、該一つ以上の他のエッジクラウドコンピューティングデバイスを見つけるように、および一つ以上のエッジクラウドコンピューティングデバイス間で確立された前記接続に関連する前記ローカルにホストされた一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を提供するように構成されている。前記パラメータの第一のセットは、前記一つ以上のエッジクラウドコンピューティングデバイスの各々に関連するユーザアカウントと、該一つ以上のエッジクラウドコンピューティングデバイスに関連するネットワークと、該一つ以上のエッジクラウドコンピューティングデバイスの近接性とを含む。実施形態において、該エッジノード有効化モジュールはさらに、前記一つ以上のエッジクラウドコンピューティングデバイスによってサポートされた一つ以上のマイクロサービスを見つけるように構成されている。

実施形態において、該エッジノード有効化モジュールはさらに、前記一つ以上のエッジクラウドコンピューティングデバイスを有する一つ以上のクラスターを動的形式に構成するように、および前記一つ以上のエッジクラウドコンピューティングデバイスとマイクロサービスレベルで直接的に、または前記一つ以上のクラスターにわたって、他のエッジクラウドコンピューティングデバイスを介して情報をやり取りするように構成されている。実施形態において、該エッジノード有効化モジュールはさらに、前記ローカルにホストされた一つ以上のマイクロサービスのサービスを、共通の埋め込みウェブサーバを介して一つ以上のエッジクラウドコンピューティングデバイスに呈示するように構成されている。実施形態において、該エッジノード有効化モジュールは、中に埋め込まれたウェブサーバを含み、該ウェブサーバは、前記エッジクラウドコンピューティングデバイスに関連するオペレーティングシステムに基づく特定の言語を用いたコンテナ管理ＡＰＩを提供するように構成されている。

また、本願明細書に記載されているさまざまな技術を実施する命令を有するコンピューティングデバイスおよびコンピュータ可読媒体も開示されている。実例のコンピュータ可読媒体は、プロセッサによって実行可能なコンピュータが実行可能な命令を有する、有形の非一時的なコンピュータ可読記憶媒体を備えることができ、該命令は、該プロセッサによって実行される場合、該プロセッサに、本願明細書に記載されているさまざまな方法とアプローチの任意の組合せを実行させる。実例のコンピューティングデバイスは、プロセッサと、記憶装置と、本願明細書に記載されている該方法を実行するように構成されたクライアントアプリケーションおよび／またはネットワークサービスとを備えるサーバまたはクライアント装置を含むことができる。

上記の概要は例示にすぎず、および決して限定しようとするものではない。それらの例示的な態様、実施形態および上述した形状構成に加えて、さらなる態様、実施形態および形状構成は、図面および以下の詳細な説明を参照することによって明らかになるであろう。

図１は、マイクロサービスを用いる実施例のクラウドアーキテクチャ１００を示す。 図２は、マイクロサービスを用いるクラウドアーキテクチャ２００の別の実施例を示す。 図３は、エッジクラウドコンピューティングネットワークの例示的な実施形態３００を示す。 図４は、実施形態によるエッジクラウドアーキテクチャ４００の基本的な構成単位を示す。 図５は、実施形態によるエッジクラウドコンピューティングデバイス５００を示す。 図６は、実施形態による例示的なバックエンドマイクロサービス配信６００を示す。 図７は、実施形態による例示的なエッジクラウドコンピューティングアーキテクチャ７００を示す。 図８は、実施形態による、エッジクラウドアーキテクチャ８００内の同じユーザＩＤに属する二つのエッジクラウドコンピューティングデバイスの場合のディスカバリー、接続および通信の例示的な実施形態を示す。 図９は、実施形態による、サイドカーパターンにおいてサーバレスのマイクロサービスを用いて実施する例示的なエッジクラウドアーキテクチャ９００を示す。 図１０は、実施形態による、ローカルにおよびグローバルにホストされたマイクロサービスを利用するアプリケーションのための例示的なサーバレスのマイクロサービス１０００を示す。 図１１は、クラウドコンピューティングインフラストラクチャを提供する方法１１００の例示的な実施形態を示す。 図１２は、クラウドコンピューティングインフラストラクチャを提供する方法１２００の別の実施形態を示す。

図面の詳細な説明
任意の当業者が該本発明を構成しおよび利用することを可能にするために、該以下の詳細な説明を提示する。説明目的のため、該本発明の完璧な理解を実現できるように具体的な詳細が記載されている。しかし、それらの具体的な詳細は、該本発明を実施するのに必要なものではないことは当業者には明白であろう。具体的な適用に関する記載は、典型的な実施例として記載されているにすぎない。好適な実施形態に関するさまざまな変更は、熟練者には容易に分かるであろうし、また、本願明細書で定義されている一般的原理は、該本発明の範囲から逸脱することなく、他の実施形態および用途に当てはめることができる。該本発明は、示されている該実施形態に限定しようとするものではないが、本願明細書に開示されている該原理および形状構成に適合する最も広い可能な範囲を認めるべきである。

該クラウドコンピューティングアーキテクチャの最新の展開は、モノリシックなバックエンドソリューションを、ＡＰＩゲートウェイの背後にある場合に、動的にインスタンス化される（サーバレスである）マイクロサービスの集団に分解するマイクロサービスに関する戦略である。このような展開は、特にクラウドコンピューティング環境という観点から、マイクロサービス通信およびクラスター管理にマイクロサービスの新たな複雑性を生じさせる。例えば、図１は、マイクロサービスを用いる実施例のクラウドアーキテクチャ１００を示す。図示されているように、コンピューティングデバイス（クライアント装置またはノード）１０２は、ｈｔｔｐ／ｈｔｔｐｓリクエスト１０６をＡＰＩゲートウェイ１０８へ送信するクライアントアプリケーション１０４を作動させる。該ＡＰＩゲートウェイ１０８は、中央クラウドコンピューティングデバイス１１４にホストされているクラウドバックエンド１１２からｈｔｔｐ／ｈｔｔｐｓレスポンス１１０を送信する。該クラウドバックエンド１１２には、グローバルにホストされたマイクロサービス１１６、１１８および１２０の集団もホストされている。該ｈｔｔｐ／ｈｔｔｐｓレスポンス１１０は、該ｈｔｔｐ／ｈｔｔｐｓリクエスト１０６に応答して開始された該マイクロサービスのうちの一つ（例えば、符号１２０）に対応することができる。このようなアーキテクチャは、通常、コンピューティングデバイス（例えば、符号１０２）上のクライアントアプリケーション（例えば、符号１０４）と、ＡＰＩゲートウェイ（例えば、符号１０８）を介して到達可能な一連のマイクロサービス（例えば、符号１１６、１１８、１２０）で一般的に構成されている該ソリューションのバックエンドのホスティングをサポートするための中央クラウド機能の集団とを含む。このような状況において、すべてのｈｔｔｐリクエストが、典型的なサーバ／クライアントアーキテクチャの場合と同じように、該「クライアント装置」から、該中央クラウド内の該サーバー（例えば、符号１１４）へ送信される。

クライアント／クライアント間の通信の場合のクラウドアーキテクチャ２００のまた別の実施例を図２に示す。クライアントアプリケーション２０４を作動させている第一のクライアント装置２０２が、クライアントアプリケーション２３２を作動させている第二のクライアント装置２３０に情報を送信しようとしている該状況について考察する。該クライアントアプリケーション２０４は、該中央クラウド２１２にホストされているＡＰＩゲートウェイ２０８に行き着くｈｔｔｐリクエスト２０６を送信する。該ｈｔｔｐｓリクエスト２０６は、要求２１０によって対応されて開始される、該中央クラウド２１２にホストされた適当なマイクロサービス（例えば、符号２１６、２１８、２２０）に対応する。該開始されたマイクロサービス（例えば、符号２１６）は、該第一のクライアント装置（符号２２８）から利用可能な情報を第二のクライアント装置２３０に伝えるために、トリガ２１４をプッシュ通知サービス２２２に送る。次に、第二のクライアント装置２３０内で作動している該クライアントアプリケーション２３２は、ここでもまた該中央クラウドにホストされているマイクロサービス（例えば、符号２１６）によって応える（情報取得）要求２２４によって該ＡＰＩゲートウェイ２０８に応答する。次いで、該サービスに応えるマイクロサービス（例えば、符号２１６）は、第一のクライアント装置から第二のクライアント装置２３０へ該情報を送信する（符号２２６）。そのため、該二つのクライアント装置（第一のクライアント装置および第二のクライアント装置）が近接していて同じローカルネットワーク上にある場合であっても、すべての通信およびデータは、準最適でありかつ望ましくない可能性のある、数百マイル離れている可能性のあるデータセンター内のサーバを経由する必要があるであろう。

この問題に対応するための有効で実行可能なアプローチは、任意のコンピューティングデバイスが、クラウドサーバの機能を果たすことを可能にすることである。コンピューティングデバイスがクラウドサーバの機能を果たすことを可能にすることは、該アプリケーションが必ずしも必要ではない、サードパーティークラウドサービスへの依存を潜在的に低減することができる。さらに、このアプローチは、該バックエンドから（この時点ではサーバの機能を果たしている）該コンピューティングデバイスへマイクロサービスを動的に展開することによって、マイクロサービスベースのソリューションを、よりフレキシブルなるようにすることも可能にする。該中央クラウド内で実行される該機能のほとんどは、サーバとして「の機能を果たし」または「構成されている」エッジデバイス上で実行することができる。一旦、該コンピューティングデバイスが、サーバとして作動するように構成されると、既存の中央クラウドよりも桁違いに大きい、分散化したエッジクラウドコンピューティング（アーキテクチャ）を提供することができる。このようなアーキテクチャには、クラウドホスティングコストの低減、通信帯域幅およびネットワーク効率の低減、エネルギー消費および炭素放出の低減、レイテンシの低減、アプリケーション開発時間の低減、マイクロサービスのトレンドを受け入れるという利点、データプライバシーの向上、および消費者や企業がそれらのデータに関するより良い管理を実行するための備えを含む多くの利益がある。

実施形態において、このことを遂行するための第一のステップは、サーバがデータセンター内にのみ存在できるという制約を取り除くことである。これは、今日のインターネットに対して有力な据え付けの階層的クライアント／サーバのインフラストラクチャを定義する基本的な制約である。任意のコンピューティングデバイスが、アプリケーションのリアルタイムの必要性に基づいて、クライアントおよび／またはサーバのいずれかの機能を果たすことを可能にすることによって実用的なアプローチに追従する代替的なアーキテクチャが本願明細書に開示されている。

前述したように、既存の階層的クライアント／サーバアーキテクチャをあまり効率的でないものにするさまざまなトレンドが目の当たりにされてきた。例えば、第一のトレンドは、コンピューティングデバイスおよびあらゆるものにおける埋め込みコンピューティングの急増、および該エッジデバイスの能力の増強である。例えば、今日のスマートフォンの中には、ちょうど十年前の強力なサーバよりも多くの利用可能な演算能力、メモリおよびストレージがある。例えば、第二のトレンドは、それらの（エッジ）デバイス上で生成される膨大なデータの量である。モバイル機器上でのソーシャルメディアの出現により、該クラウド内の中央サーバにホストされている大手のスタジオや放送局からの優れたコンテンツよりも桁違いに多い、より個人的なマルチメディアコンテンツ（写真、動画、センサデータ等）がデバイス上で生成されている。今日、（エッジ）デバイス上で生成された該データのほとんどは、処理のためにおよびシェアリングを容易にするために、該中央クラウドへ返信されている。第三のトレンドは、マイクロサービスの集団におけるソリューションの分解、および容量的にまたは地理的にさえも、該要求にぴったり適合するスケーラビリティによって、バックエンドソリューションをより動的に（サーバレスに）する展開の自動化である。

実例として、現在、８０００万個以上のＳｏｎｙ ＰｌａｙＳｔａｔｉｏｎ４（ＰＳ４（商標））用コンソールが人々の家にある。このことは、６億個以上のプロセッサコアと、約４０，０００ペタバイトのストレージとを表している。対照的に、このことは、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＡＷＳ（登録商標））のインフラストラクチャ全体よりも、全体としてかなり多くのコンピューティング、ストレージおよびメモリリソースを示している。潜在的にクラウドサーバの機能を果たすことができ、および該既存の「中央クラウド」よりも桁違いに大きい演算能力を集団で有することができる、数十億個のＰＣ、セットトップボックス、ゲームコンソール、ストリーミングプレーヤー、ルーター、スマートフォン、タブレットおよびその他のコンピューティングデバイスがある。該本開示は、該既存の中央クラウドよりも桁違いに多い、数十億個のエッジクラウドコンピューティングデバイス（またはノードまたはエッジノード）で構成されたクラウドファブリックを創造するためのシステムおよび方法を提供する。

分散型クラウドアーキテクチャの該開示した実施形態は、専用ハードウェアを用いた新たなネットワークノードの形成を必要としない。その代わりに、該開示したアーキテクチャは、ＰＣ、タブレット、セットトップボックス（ＳＴＢ）またはホームルーター等の既存のコンピューティングデバイスが、妥当な場合に、該クラウドネットワークのエッジにおいてクラウドサーバノードの機能を果たすことを可能にする。該開示したアプローチは、それらのデバイスの詳細設計への変更を少しも必要としない。必要なものは、該ハードウェア、または、既存のデバイスのＯＳカーネルに関する何らかの変更を要することなく、既存のオペレーティングシステム上で作動する、ダウンロード可能なアプリケーション（例えば、エッジノード有効化モジュール）である。該開示したアーキテクチャは、開発者が該既存のクラウドインフラストラクチャを分散化するための強力な手段を提供することに加えて、消費者に、彼らの個人的データに関してより多くの管理権を与える。さらに、特に該開示したアプローチは、アプリケーションおよびサービスのホスティングおよび配信のコストを最小限にし、ネットワークパフォーマンスを向上させ、およびレイテンシを最小限にする。

エッジクラウドコンピューティングプラットフォームの実施形態が開示されている。該開示したクラウドプラットフォームは、クラウドコンピューティングにおける次の変革として該分散化を加速させる。クラウド分散化における最初のステップは、サーバが、データセンター内にのみ存在することができるという制約を取り除くことである。これは、今日のインターネットの場合の支配的なクライアント／サーバインフラストラクチャを定義する基本的な制約である。該本開示は、アプリケーションの該リアルタイムの必要性に基づいて、任意のコンピューティングデバイスが、クライアントまたはサーバのいずれかの機能を果たすことを可能にすることによって、これを実現するための代替的なアーキテクチャ／プラットフォームおよび実用的なアプローチを提供する。また、エッジノード有効化モジュールおよび一つ以上のバックエンドサービスを用いて該エッジクラウドファブリックを形成するためのクラウドプラットフォームも開示されている。

開示したアーキテクチャおよびプラットフォームの便益および利点は、クラウドホスティングコストの低減、通信帯域幅の低減、ネットワーク効率の向上、エネルギー消費および炭素放出の低減、レイテンシの低減、消費者データおよび企業データに関するプライバシーおよびより良好な管理の向上を含む。

エッジクラウドコンピューティングインフラストラクチャを通信ネットワーク内に設ける方法の実施形態が開示されている。該通信ネットワークは、少なくとも一つのサーバコンピューティングデバイスと通信する一つ以上のエッジクラウドコンピューティングデバイスを含む。実施形態において、該方法は、第一のエッジクラウドコンピューティングデバイスによって、該第一のエッジクラウドコンピューティングデバイス内で作動しているアプリケーションからの要求に対応する一つ以上のマイクロサービスの種類を判断することを含む。該方法は、前記判断した種類が、前記第一のエッジクラウドコンピューティングデバイスにローカルにホストされた一つ以上のマイクロサービスに対応する場合に、該第一のエッジクラウドコンピューティングデバイス内で前記要求を、前記第一のエッジクラウドコンピューティングデバイスによってローカルに処理することをさらに含む。該方法は、前記ローカルにホストされた一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を、前記第一のエッジクラウドコンピューティングデバイスによって提供することをさらに含む。

実施形態において、該方法は、前記第一のエッジクラウドコンピューティングデバイスにより、前記ローカルにホストされた一つ以上のマイクロサービスに該要求を送信するための、ローカルにホストされたＡＰＩゲートウェイを提供することをさらに含む。実施形態において、該方法は、前記一つ以上のマイクロサービスの判断された種類が、中央クラウドコンピューティングデバイスにグローバルにホストされた一つ以上のマイクロサービスに対応する場合に、前記第一のエッジクラウドコンピューティングデバイスによって、前記アプリケーションからの該要求に対応するｈｔｔｐ／ｈｔｔｐｓリクエストを、前記中央クラウドコンピューティングデバイスにホストされたＡＰＩゲートウェイに送信することをさらに含む。該方法は、前記第一のエッジクラウドコンピューティングデバイスによって、前記ｈｔｔｐ／ｈｔｔｐｓリクエストに対するｈｔｔｐ／ｈｔｔｐｓレスポンスを、前記中央クラウドコンピューティングデバイスにホストされた該ＡＰＩゲートウェイから受信することをさらに含み、およびこの場合、該ｈｔｔｐ／ｈｔｔｐｓリクエストには、該中央クラウドコンピューティングデバイスにグローバルにホストされた前記一つ以上のマイクロサービスが応える。実施形態において、該方法は、前記中央クラウドコンピューティングデバイスにホストされた該ＡＰＩゲートウェイに前記ｈｔｔｐ／ｈｔｔｐｓリクエストを送信するための、ローカルにホストされたＡＰＩゲートウェイを、前記第一のエッジクラウドコンピューティングデバイスによって提供することをさらに含む。

実施形態において、該方法は、前記第一のエッジクラウドコンピューティングデバイスにより、前記アプリケーションからの該要求の判断された種類が、第二のエッジクラウドコンピューティングデバイスに対するデータ要求に対応する場合に、該データ要求を前記ローカルにホストされた一つ以上のマイクロサービスから、前記第二のエッジクラウドコンピューティングデバイスにホストされた一つ以上のマイクロサービスに直接送信することをさらに含む。また別の実施形態において、該方法は、前記第一のエッジクラウドコンピューティングデバイス内で作動している前記アプリケーションをサポートするためのサービスメッシュを構成するサイドカーパターンを、前記第一のエッジクラウドコンピューティングデバイスによって提供することをさらに含む。該方法は、前記第一のエッジクラウドコンピューティングデバイスにより、前記ローカルにホストされた一つ以上のマイクロサービスのサービスを共通の埋め込みウェブサーバを介して一つ以上のエッジクラウドコンピューティングデバイスに呈示することをさらに含む。実施形態において、該方法は、前記第一のエッジクラウドコンピューティングデバイスにより、該エッジクラウドコンピューティングデバイスに関連するオペレーティングシステムに基づく特定の言語を用いたコンテナ管理ＡＰＩを提供することをさらに含む。

実施形態において、該方法は、前記第一のエッジクラウドコンピューティングデバイスにより、一つ以上の他のエッジクラウドコンピューティングデバイスとの間の接続を確立するための該デバイスを見つけることと、該第一のエッジクラウドコンピューティングデバイスにより、一つ以上のエッジクラウドコンピューティングデバイス間に確立された前記接続に関連する前記ローカルにホストされた一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を提供することとをさらに含む。実施形態において、該方法は、前記第一のエッジクラウドコンピューティングデバイスにより、前記見つかった一つ以上の他のエッジクラウドコンピューティングデバイスにホストされた一つ以上のマイクロサービスを見つけることと、該第一のエッジクラウドコンピューティングデバイスにより、前記ローカルにホストされた一つ以上のマイクロサービスと、前記一つ以上のエッジクラウドコンピューティングデバイス内の前記見つかった一つ以上のマイクロサービスとの間のダイレクトマイクロサービスレベルの接続を確立することとをさらに含む。実施形態において、該方法は、前記第一のエッジクラウドコンピューティングデバイスにより、前記アプリケーションからの前記要求に応えるのに必要な一つ以上のマイクロサービスをロードして実行することをさらに含む。また、該方法は、前記アプリケーションからの前記要求に一旦、応えられると、前記ロードされた一つ以上のマイクロサービスを該第一のエッジクラウドコンピューティングデバイスによって停止することをさらに含む。

図３は、エッジクラウドコンピューティングネットワーク３００の実施形態を示す。該既存の「中央クラウド」モデルにおいては、より多くのデバイスが追加され、または、より多くのコンテンツがデバイスによって生成されるため、それらをサポートするために、データセンター内のより多くのサーバを追加する必要がある。図３に示すような分散型のエッジクラウドコンピューティングネットワーク３００の場合、エッジデバイスの数に対応するクラウドファブリックを形成することができる。このことは、該エッジデバイスの数および該エッジデバイスによって生成されるコンテンツが増大するため、データセンター内の追加サーバに対する必要性を減らす。

現在行われている説明において、該「エッジデバイス」は、置換え可能に「ノード」または「エッジノード」または「エッジコンピューティングデバイス」または「エッジクラウドコンピューティングデバイス」と呼称されるものとする。したがって、エッジクラウドコンピューティングデバイスの該数が増大するにつれて、該「クラウド」の容量が増加する。さらに、該データのほとんどが該エッジで生成されると仮定すると、アプリケーションに対する移植コストおよびレイテンシが最小化される。該開示したアプローチにおいて、該処理のほとんどは該エッジで実行され、通信は、可能な限りローカルで維持され、およびエッジクラウドコンピューティングデバイスは、コンピューティングおよび他のリソースを協働および共有する。該現在行われている説明の目的のために、該「中央クラウド」または「中央クラウドコンピューティングデバイス」は、有用性の高いリソースは中央ストレージまたは中央処理を必要とする多くのアプリケーションにとって必要不可欠である可能性があるため、該有用性の高いリソースのままでいるデータセンター内の一つ以上のサーバを指すものとする。しかし、提案されているエッジクラウドプラットフォームおよびアーキテクチャにおいて、該中央クラウドはもはやボトルネックまたは「不可欠な」信頼要素ではなく、およびエッジノードの増大に比例して増大させる必要がなくなる。データセンターリソースは、中央処理に対する必要性のみに適応するように、無理のないペースで増やす必要がある可能性があることに留意されたい。すべての他の可能性のあるタスクおよび機能は、今日の該データのほとんどが生成される該エッジノードに委ねることができる。

図３に示すように、該エッジクラウドコンピューティングネットワーク３００は、ラップトップ３０２、タブレットＰＣ３０４、中央「クラウド」３０６、自動車インフォテイメントシステム３０８、セキュリティカメラ３１０、サーバコンピューティングデバイス３１２、モバイル機器３１４およびゲーミングコンソール３１６等の複数のエッジクラウドコンピューティングデバイスを含む。例示的な実施形態において、該エッジクラウドコンピューティングデバイスの各々は、該エッジクラウドコンピューティングネットワーク３００の必要性により、クライアントまたはサーバの機能を果たすように構成することができる。さらに、該図３は、該エッジクラウドコンピューティングデバイス間の接続または通信経路を点線で示す。当業者により正しく認識されるように、該アーキテクチャは、一つ以上のデバイスが「サーバ」としての機能を常に果たすように、および他のデバイスが「クライアント」の機能を常に果たすように設計されている従来のクライアント／サーバモードに追従しない。

該エッジクラウドコンピューティングネットワーク３００の該提案されているアーキテクチャにおいては、該提案されているアーキテクチャを実現可能にするための課題になる可能性のある、オペレーティングシステムおよびネットワークにおける断片化が存在する。例えば、該エッジクラウドコンピューティングデバイスの各々は、Ｌｉｎｕｘ（登録商標）、ａｎｄｒｏｉｄ、ｉＯＳ（登録商標）、ｍａｃＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、Ｆｅｄｏｒａ（商標）等の多くのバージョン違いの異なるオペレーティングシステムを利用する可能性がある。さらに、該エッジクラウドコンピューティングデバイスは、固定式（イーサネット、ファイバー、ｘＤＳＬ、ＤＯＣＳＩＳ（登録商標）、ＵＳＢ等）、モバイルＷＡＮ（２Ｇ、３Ｇ、４Ｇ等）、ワイヤレスＬＡＮ（ＷｉＦｉ（登録商標）等）、ワイヤレスＰＡＮ（Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＧｉｇ、ＺＷａｖｅ（登録商標）、ＺｉｇＢｅｅ（登録商標）、ＩｒＤＡ等）およびマシンネットワーク（ＳｉｇＦｏｘ（登録商標）、ＬｏＲａ（登録商標）、ＲＰＭＡ等）等の異なるネットワーキング技術を用いて作動するように構成することができる。この課題に対処するために、該提案されているクラウドアーキテクチャは、「有効化された」場合に、多くの断片化されたオペレーティングシステムおよびネットワーク技術にわたって、他のエッジクラウドコンピューティングデバイスと接続し、通信しおよび協働するように構成されているエッジクラウドコンピューティングデバイス（例えば、符号３１４）を含む。

該本開示の別の態様において、ネットワークリソースの可用性は、該エッジクラウドコンピューティングネットワーク３００における課題になる可能性がある。したがって、一旦、エッジクラウドコンピューティングデバイス（例えば、符号３１２、３１４）が、サーバとしての機能を果たすと、それらのデバイスは、アップリンクネットワークリソースを用いて他のエッジノードと接続して通信することができる。ネットワーク接続性は、徐々に対称的になっていくが、典型的には、利用可能なアップリンクリソースよりも多くのダウンリンクリソースがある。例示的な実施例として、一つのエッジノードから、他の三つのエッジノードによって消費される該中央クラウドへの動画の投稿は、該ソースから宛先ノードに該動画を（直接的に）ストリーミングするのと比較して、異なるアップリンク／ダウンリンクリソースを直接的に必要とする。該集中型クラウドネットワークにおいては、アップリンクに関する一つのインスタンスと、ダウンリンクに関する三つのインスタンスがあり、また、該提案されている分散型エッジクラウドコンピューティングネットワーク３００においては、（ファイヤーウォールの背後に何もないと仮定して）アップリンクに関する三つのインスタンスがある。そのため、ネットワークリソースの可用性は、実現可能にするための該分散型エッジクラウドプラットフォームにとって重要な側面になるであろう。このことに関する解決策を、「メリトクラシー」原理に関連して説明する。

該本開示のまた別の態様においては、ほとんどのエッジノードは、データセンター内のサーバとは違って、本質的に非永続的である可能性がある。それらの可用性および信頼性に関しては、特に電池式のモバイル機器の場合、制御性が低い可能性がある。該提案されているエッジクラウドコンピューティングアーキテクチャは、以下で説明する「マイクロサービス」アプローチによってこの課題を克服している。実施形態において、該エッジノードの該非永続的な性質は、永続ノードが本質的である特定のアプリケーションが構成される場合に考慮される。永続ノードは、他の協働エッジノードを用いて常に用意することができ、または最悪の場合は、中央クラウドを用いることができる。

克服されるべきまた別の課題は、配信管理である。データセンターにおいては、該配信管理は、ＣＰＵ負荷、メモリ制約およびＩＯ等のよりシンプルな基準に基づいてリソース可用性を処理する。配信管理のスコープは、該ソリューション（バックエンド）が作動している特定のデータセンターである。エッジクラウドの場合、配信管理のための基準は、かなり多様であり、電力可用性および消費電力、信頼性、およびデバイス機能を含む。後述するように、エッジクラウドコンピューティングアーキテクチャの場合、ほとんどのデバイスは特定のユーザに属しているため、配信のスコープは、ネットワーク、近接性およびアカウントに及ぶ。

既存の中央クラウドアーキテクチャは、中心的な場所／デバイスにおいて該情報が生成及び／又は格納され、およびほとんどのエッジノードが、ワールドワイドウェブから（ｈｔｔｐを介して到達可能な一連の専用サーバを介して）当該情報を受信するのに用いられる場合に有効である可能性がある。しかし、ソーシャルメディア、ユーザが生成するコンテンツ、ＩｏＴ（ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）およびマシン生成データの急激な増大により、エッジノードが、今日の該データのほとんどを生成している。そのため、重要な考慮すべき事柄の一つは、該現在行われている開示で提案されているような、データの生成および利用における根本的な変化に最も適している該アーキテクチャである。
該分散型エッジクラウドの場合、該「中央クラウド」（例えば、図３の符号３０６）を含むすべてのノードは、クラウドサーバの機能を果たすことができ、および指定された恒久的な信頼要素はない。エッジノードまたはエッジクラウドコンピューティングデバイスは、必要でない限り、サードパーティー信頼（中央）要素に頼ることなく、直接通信し、協働し、およびリソースを直接的に共有するように構成されている。このアプローチの場合、中央クラウドリソースは、必要な場合にのみ、例えば、グローバルなストレージ、アーカイブ化、集中型データベースの更新、集中型登録等の必要性がある場合に用いられる。該エッジノードが対処することができる他の任意の機能、例えば、デバイス間のメッセージング、または、マシン間の制御信号のハンドシェイク、または、小さなクラスター内のノード間のデータ送信をそれらに割り当てることができる。

さらに、ソフトウェア業界で現在進行中のトレンドは、正に該提案されている分散化を実現可能にしている。過去の大量のコンポーネントで作り出されたソフトウェアソリューションを管理するという複雑性がモノリシックなソリューションにつながった。しかし、Ｄｏｃｋｅｒ（登録商標）＆ＣｏｒｅＯＳ（登録商標）、オンデマンドＩＴのコンシューマライゼーション、およびリッチコミュニケーションの容易さ（ＡＰＩ）のようなよりライトなコンテナ管理プラットフォームを目的とする仮想化技術の発展が、該複雑性を著しく低減した。良好なソフトウェアデザインの実施は、本願明細書において以後「マイクロサービス」と呼ぶ専用の明確に定義されたコンポーネントの多くのインスタンスの集団としてソリューションを開発することである。

このようにしてクラウドシステムを設計することの結果が、需要曲線に密に追従するためのインフラストラクチャリソースのより粒度の細かい利用、複雑な属性（セッション、貸借）のデザインの簡略化、データセンター内またはデータセンター間のコンピューティングリソースのより良好な配信および利用、およびより迅速なアプリケーション開発時間およびソフトウェアの更新およびメンテナンスの容易さのための、モノリシックなアーキテクチャからマイクロサービスアーキテクチャへのソリューションのクライアントのさらなる分解である。該提案されているアーキテクチャにおけるソフトウェアソリューションのより高い効率を実現するために、マイクロサービスが、該マイクロサービス自体に対して実行されたＡＰＩコールに基づいてインスタンス化（開始されおよび作動）される、「サーバのない」または「サーバレスの」アーキテクチャとも呼ばれる一時的なマイクロサービスを用いたプログラミングが実施される。

例示的な実施形態において、該クラウドは、コンピューティングリソースを正しく認識して呈示し、および利用可能な場合に、それらを日和見的方法で利用することにより、該エッジまで拡張される。さらに、一時的なマイクロサービスが、可用性、ポリシーおよび（ソーシャルレベルのイベントおよび他のアプリケーションレベルのイベントを含む）コンテキストに基づいて展開される方法に関して分析を加えることは、該エッジクラウドコンピューティングネットワーク３００上でのアプリケーションの最適な展開を可能にする。

該開示したアーキテクチャは、既存のエッジクラウドコンピューティングデバイスを、エッジクラウドサーバ（または、エッジクラウドサーバコンピューティングデバイス）に容易に変えることができると仮定している。該説明の範囲内では、開発者は、（該エッジクラウドによってサポートされる）アプリケーションを、可能な限り少しの努力で作り上げることができることが想定されている。該エッジクラウドコンピューティングデバイスの異なる性質を仮定して、該開示したアプローチは、デバイス機能に基づいて機能的役割を割り当てる。開発者によるアプリケーション開発を容易にするために、該中央クラウドのものと同様のＡＰＩセマンティクス、例えば、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（登録商標）（ＡＷＳ）またはＭｉｃｒｏｓｏｆｔ Ａｚｕｒｅ（登録商標）が実施されて追従される。さらに、エッジノード上で該マイクロサービスを作動させるためのライトなコンテナと、既存のコンテナ技術、例えば、Ｄｏｃｋｅｒ（登録商標）またはＣｏｒｅＯＳ（登録商標）の該セマンティクスが実装される。

該開示したアプローチにおいて、エッジノードまたはエッジクラウドコンピューティングデバイスは、潜在的なエッジクラウドサーバまたはエッジクラウドサーバコンピューティングデバイスになるための複数の能力を実演するように構成されている。該複数の能力は、該オペレーティングシステム（ＯＳ）またはそれらに関連するネットワークに関係なく、他のエッジノードまたはエッジクラウドコンピューティングデバイスの存在を見つけるための該能力を含む。また、該複数の能力は、他のノードの能力および機能（例えば、ハードウェアスペック、ＯＳ、永続性等）を見つけるための該能力を含む。該複数の能力は、他のエッジノードまたはエッジクラウドコンピューティングデバイスによってサポートされる一つ以上のマイクロサービスを見つけて、特にネットワーク、近接性およびユーザアカウントが存在している他のエッジノードまたはエッジクラウドコンピューティングデバイスとともにクラスターを動的に構成するための該能力をさらに含む。

別の実施形態において、該複数の能力は、異なるクラスターにわたって、他のノードと該マイクロサービスレベルで直接または他のノードを介して通信し、および該他のノードがデータ、サービスおよび／またはリソースを共有することを選択した場合に、他のノードと接続する該能力をさらに含む。さらに別の実施形態において、該複数の能力は、リソースおよび能力に基づいて、割り当てられた機能および役割に適合するように、およびデータをローカルに処理して分析する該能力をさらに含む。さらに、該複数の能力は、該中央クラウドと同じくらい安全で信頼できるようになる該能力をさらに含む。

実施形態において、該複数の能力を実演するための該エッジノードまたはエッジクラウドコンピューティングデバイスの該コンフィギュレーションは、プラットフォームに依存しないアプローチで実現される。実施形態においては、任意のエッジクラウドコンピューティングデバイスをエッジクラウドサーバに変え、その結果として、エンドツーエンドのエッジクラウドプラットフォームを作り上げる、ダウンロード可能なアプリケーションレベルのソフトウェア（例えば、エッジノード有効化モジュール）が提供される。当業者は、該提案されているアプローチは、該デバイスのハードウェア、ＯＳカーネルまたはドライバおよびほとんどの現代のハードウェア（ＰＣ、ＳＴＢ、ルータータブレット、スマートフォン等）上での作業に関して全く変更を要しないことに留意すべきである。また、該提案されているソフトウェアレベルのアプリケーションは、非常に小さなメモリフットプリントを有し、および複数の該エッジクラウドコンピューティングデバイスにわたって容易にロードし、作動させおよび停止することのできるマイクロサービスをサポートすることにも留意すべきである。

さらに、該開示したアプローチは、多数の顧客をサポートするためのソフトウェアの単一のインスタンスを備えた、マルチテナンシー、マルチアプリケーションおよびマイクロサービスをサポートする。該開示したクラウドプラットフォームは、「中央クラウド」（例えば、図３の符号３０６）にホストされたライトであるが、高度にスケーラブルなバックエンド（サービス）を有し、および該ノードまたは他のエッジクラウドコンピューティングデバイスの登録のためのブートストラップメカニズムを用いる。該開示したクラウドプラットフォームは、同じネットワーク、近接性および（ユーザ）アカウント内でのエッジノードから成る動的クラスターを作成し、およびクラスター間およびクラスター内のノードの移動性特性（出現および消失）を管理する該能力を提供する。

実施形態において、該エッジクラウドコンピューティングネットワーク３００は、該エッジノードまたはエッジクラウドコンピューティングデバイス間での直接的な、または中間のノードを介した通信の管理、および該エッジノードからの要求に基づくバックエンドリソースまたはサービスの動的インスタンス化を提供する。さらに、エッジクラウドコンピューティングネットワーク３００は、協働するエッジノードおよび／またはリソースを動的に引き寄せることにより、有効な永続性を生み出す。

エッジノードのパワーを利用して、巨大な分散化したエッジクラウドを生み出すために、該開示したアプローチは、該エッジクラウドアーキテクチャにおけるさまざまな原理を考慮して実施する。該開示したアプローチによって実施される分散化の第一の原理は、「メリトクラシー」である。すべてのノードは、該エッジクラウドコンピューティングネットワーク３００に参加する等しい機会を有している。ノードは、それらの能力に基づいて何らかの役割を演じることができる。ノード所有者によって可能にされる能力は、ノードプロファイルに格納されている。例えば、大きなストレージを有するノードは、「キャッシュノード」または「バックアップストレージノード」になることができ、大きなネットワーク接続性を有するノードは、「プロキシノード」とすることができ、および永続ノードは、ノードから成るクラスターのためのナレッジ（例えば、デバイスおよび能力／役割プロファイル）の所有者になることができる等々である。メリトクラシーは、所定の役割を有する中央要素を備える必要性をなくし、このことは、ノードの階層構造をもたらす。

実施形態において、メリトクラシーが作用するために必要な他の原理、例えば「透明性」も該開示したアプローチにおいて実装される。例えば、該ノードは、それらのプロファイルに関する真実を透明性のある方法で伝えるべきであり、そうでなければ、メリトクラシーの該原理を有効に適用することができない。該開示したアーキテクチャは、嘘をつく（例えば、何らかのノード固有の特典または権利を提供しない）動機を取り除く。嘘をつく明白な動機がない（例えば、誤った情報、誤解を与えるような情報または偽情報を提供する）場合であっても、該開示したアーキテクチャは、それらのプロファイルに関して嘘をついて、該エッジクラウドコンピューティングネットワーク１００内のクラスターの稼動に害を及ぼすノードをブラックリストに載せるメカニズムを実装している。さらに、該メリトクラシーは、時間とともに変化する可能性が有り、およびノードは、それらの能力およびプロファイルをアップグレードまたはダウングレードしてもよい。該開示したアーキテクチャは、このような該ノードに関する何らかの変化にリアルタイムで適応する。

該「メリトクラシー」原理に関する重視すべき事柄の一つは、該提案されているアーキテクチャにおける中央クラウドリソースのメリットである。該中央クラウドアーキテクチャは、該エッジノードがクライアントとしてのみ使用される、エッジクラウドコンピューティングアーキテクチャの特殊なケースとして考えることができる。そのため、ホスティングコスト、レイテンシおよびプライバシーを犠牲にしながら、開発の速度を上げるために、該既存のバッドプラクティスをやめるか、または、中央クラウド上の容易に利用可能なリソースに頼ることが望ましい可能性がある。該メリトクラシー原理が有効に作用するために、すべてのノードは、他のノードに対する潜在的な「サーバ」と見なされ、およびすべての要求は、ノードが能動的である該クラスターに対してローカルに保持される必要がある。

該開示したアプローチによって実施される分散化の第二の原理は、「分散型ディスカバリー」である。該エッジクラウドコンピューティングネットワーク１００内のノードは、他のノードを見つける必要がある。該現在行われている開示において、ディスカバリーは、スコープに基づく「フィルター処理した検索」作業であることが意図されている。スコープの例示的で非限定的な実施例は、ユーザアカウント（同じアカウントＩＤで登録されたノード）と、ネットワーク（該同じリンクローカルクラスターネットワークのメンバーであるノード）と、近接性（ある地理的位置に、または、地理空間クエリによって定義される領域内に物理的に存在する場合にそれら自体について報告されているノード）とを含む。実施形態において、該ディスカバリープロセスは、専用の中央ノード、例えば、プレゼンスサーバとしての機能を果たしている中央ノードを要することなく、それらまたはその他のスコープの任意の組合せを利用する。あるノードがファイヤーウォールの背後に位置し、および外部から到達可能ではない場合、ディスカバリー可能になるように到達可能である任意のノードに頼るべきである。該ノードは、絶対的に必要ではない限り、中央エンティティに頼るべきではない。実施形態において、該ディスカバリープロセスは、どのようにデバイスに接続して通信するか、重要な特性、役割、およびエッジノードが選ぶことができる人物に関する情報を含む。該役割は、キャッシュノード（スペアストレージを備えたノード）、プロキシノード（インターネットへの良好な接続性）、ＣＰＵリソース（マイクロサービスを作動させるためのスペアＣＰＵを備えたノード）等を含むことができる。

該開示したアプローチによって実施される分散化の第三の原理は、「クラスタリング」である。人とマシンはクラスター内で通信する。人類学者のＲｏｂｅｒｔ Ｄｕｎｂａｒは、人間が人々と安定した関係を持つことのできる認知限界は１５０人であると提唱している。換言すると、人間は、制約された集団内で連絡を取り合う。くわえて、人間は、密な関係のサークル内のすべての人と定期的にまたは頻繁に連絡を取り合うことはめったにない。実際に、日々の連絡は、一握りの非常に密な関係者に限られる可能性がある。そのため、エッジクラウドコンピューティングアーキテクチャのための該提案されている通信フレームワークは、クラスター内のノードに役割および責務を割り当てる場合を考慮することが論理的に意味を成す。

しかしながら、上記の連絡の特性は人間に限定されない。マシン間の該通信は非常に似ており、また、該通信のほとんどは、多くの場合、いつでもクラスター内のノードの非常に小さなセット間である。そのため、すべての通信は、可能な限り該クラスターに対してローカルに行われるように最適化することができる。該提案されているアーキテクチャにおいて、どのノードも、他のすべてのノードとハンドシェイクしなければならないという要件を取り除くために、該クラスター内の一つのノード（スーパーノード）には、該クラスターのナレッジ所有者としての特別な役割が与えられる。該スーパーノードには、グローバルディスカバリーまたは他のクラスター内のノードのために／に対して、このナレッジを伝えるという役割が割り当てられる。該提案されているアプローチは、ノードが、前述した該三つの所定のスコープに基づいて、それら自体のアドホックのクラスターを動的に構成することを可能にする。ノードは、ノードおよびルールに関する一連のノードの特性に基づいて、他のノードによる選択または選定を介して役割を動的に担う。そのようにすることにより、該ノードは、エッジクラウドの該ファブリック（すなわち、Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｃｌｏｕｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を動的に構成する。ノードがクラスターに入り、およびクラスターから出る際に、該役割は動的に割り当てし直される。

ノードは、主に（制約された）クラスター内で通信する。そのため、該開示されている該エッジクラウド内の通信フレームワークは、このことを、役割および責務をクラスター内のノードに割り当てるときに考慮する。クラスターは、所定のスコープに基づいて、第一のアクティブノード（または、第一のエッジクラウドコンピューティングデバイス）によって形成されている。ノードが「有効化」されると、該ノードはまず、（該現在行われている説明においては、「スーパーエッジクラウドコンピューティングデバイス」とも呼称される）「スーパーノード」を探す。該スーパーノードは、グローバルディスカバリーを監視し、および該エッジクラウドのナレッジを保持する。スーパーノードが見つからない場合は、該第一のノード（または、該第一のエッジクラウドコンピューティングデバイス）自体が、該スーパーノードとして宣言し、または指定する。通信ネットワークが利用可能な場合には、該スーパーノードは、グローバルディスカバリーにその存在を知らせて、該所定のスコープ内のノードのリストを受取る。該スーパーノードは、効率を維持するために、そのスコープ内の他のノードに知らせる。その後、より良好なスーパーノードを認識してもよく、そして、当該のより良好なスーパーノードは、該グローバルディスカバリーにその存在を知らせた後に、該スーパーノードとして機能することができる。

一旦、クラスターが該スーパーノードによって形成されると、該クラスターに入るその後のノードは、該既存のスーパーノードを見つけて、それらを該スーパーノードに登録し、およびそれらのスコープ内の該ノードのリストを受取るように構成される。該新たなノードは、それらのスコープ内の他のノードにそれらの存在を知らせる。該開示されているエッジクラウドは、グローバルであるかまたはローカルであるかに関わらず、任意のノードをオーバーロードさせるのを回避するために、このブートストラップモデルを実装し、それによってトラフィックおよびチャティネスを低減し、およびライトでスケーラブルなアーキテクチャを形成する。該ノードの該潜在的な移動性を仮定すると、プレゼンス通知は、他のどのノードが通知することを望んでいるかを判断する該責務とともに、該ノード自体の機能である。したがって、該開示されているエッジクラウドアーキテクチャは、該開示されているエッジクラウドコンピューティングネットワーク内に単一のグローバルプレゼンスサーバまたは登録のポイントを実装しない。同様に、該開示されているアーキテクチャは、該ノード間の該インフラストラクチャレベルに「キープアライブ」メカニズムを有していない。実施形態において、このようなメカニズムは、特定の状況において必要に応じて、マイクロサービスに割り当てることができる。

該開示されているアプローチによって実施される分散化の第四の原理は、「マイクロサービス間の通信」である。分散型エッジクラウドファブリックを形成するために、エッジクラウドコンピューティングデバイスまたはノード上のアプリケーションは、絶対に必要でない限り、サードパーティー信頼要素を要することなく、直接通信してもよい。このことは、該デバイスが、該ネットワークレベルで該エッジノードに一緒に接続することを可能にすることができる。しかし、デバイスまたはエッジノードを物理的ネットワークレベルで接続することは十分ではない。該エッジノード上で作動しているマイクロサービスは、直接通信する必要がある。実施形態において、エッジノード内の該エッジノード有効化モジュールは、エッジノード上のマイクロサービスの展開およびホスティングが、該形成されたエッジ「クラウドファブリック」を利用して、他のマイクロサービスと直接通信することを可能にし、それによって、「サービスメッシュ」を形成する、ライトなコンテナを提供する。さらに、エッジノードは、該エッジクラウドコンピューティングネットワーク１００内の任意の他のエッジノード上でマイクロサービスをロードし、始動させおよび停止するように構成されている。このコンフィギュレーションは、該開示されているクラウドプラットフォームにわたるマイクロサービス管理が、中央エンティティを要することなく、分散されたままであることを確実にする。

実施形態において、該エッジノード上で使用可能にされた該マイクロサービスは、それらのサービスを共通の埋め込みウェブサーバを介して呈示する。各サービスのためのＡＰＩエンドポイントは、エッジクラスター内の他のすべてのエッジノードから利用可能である。実施形態において、該エッジクラウドは、複数のエッジノードにわたるマイクロサービスのシームレスの到達可能性が、サービスメッシュを直接的に、または、より詳細に後述する「サイドカーパターン」を介して構成することを可能にする。コンテナデーモンを作動させることができる環境（例えば、Ｌｉｎｕｘ）において、該開示されているエッジクラウドプラットフォームは、エッジノードから成るアドホッククラスターを管理するための機能性を提供する。コンテナデーモンを作動させることができない環境（例えば、スマートフォン）においては、該開示されているエッジクラウドプラットフォームは、マイクロサービスをダウンロードし、展開しおよび稼働させるための能力を備えた、追加の「ライトな」コンテナ能力を提供する。

該開示されているアプローチによって実施される分散化の第五の原理は、「動的なリソースインスタンス化」である。分散化を有効にする場合、クラスターに連なり、クラスターから離れ、または、割り当てられたリソースを取得するための、該ノードに関連するオーバヘッドが非常に少ないことが望ましい。該現在行われている説明の目的のために、該開示されているエッジクラウドアーキテクチャによって実施される該ソリューションを、「動的なリソースインスタンス化」と呼称する。この原理によれば、シグナリングおよびデータリソースは、ネットワークの状態と、一つ以上のクラスター内のエッジノードからの要求とに基づいて、（バックエンドサービスにより）動的に展開され、それにより、コンピューティングリソースを用意しておく必要性をなくす。このことは、必要な場合にのみインスタンス化される該エンドポイント（例えば、ＳＥＰ、ＢＥＰ）を動的に展開することにより、効率を向上させ、およびコストを低減する。該開示されているクラウドプラットフォームは、該エッジノードが、トンネリングを日和見的に設定して、シグナリングおよびデータ帯域幅効率を上げるのを支援する。リソースは、ネットワークトポロジーに基づくパラメータと、該エッジノード上で作動している該アプリケーションによる要求とに基づいて展開される。実施形態において、該パラメータは、稼動開始のための時間、同時接続の数、および通信プロトコル（ＨＴＴＰ、ＳＳＨ、ウェブソケットまたはＵＤＰトンネリング）を含む。必要に応じて、エンドポイントは、所定のクラスターの最も近い近接性の範囲内の利用可能なコンピューティングリソース上で展開することができる。

該開示されているアプローチによって実施される分散化の第六の原理は、「協働（ｃｏｌｌａｂｏｒａｔｉｏｎ）」である。該分散化されたエッジクラウドネットワーク内のエッジノードの集団的パワーを活用するためには、複数の該エッジノードがリソースを協働させて共有することが望ましい。分散化されたクラウドリソースの該共有は、中央クラウドの場合と同じようにシームレスにすることが望ましい。第一のステップとして、該開示されているクラウドアーキテクチャは、すべての該エッジクラウドコンピューティングデバイスの集団的リソースを利用することができる。例えば、動画は、携帯電話３１４でＨＤフォーマットで記録され、該記録されたコンテンツは、シームレスで該ラップトップ３０２に、または、接続されたストレージドングルにも格納される。次のステップとして、該開示されているアーキテクチャは、友人や家族とのリソースの共有を可能にする。例えば、家族の一員が、ファミリーリソースとしてネットワークアタッチトストレージ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ：ＮＡＳ）を共有することを可能にする。実施形態において、該開示されているアーキテクチャは、コンピューティングリソースを他人に貸し、およびさらに大きなエッジクラウドを形成する該能力も提供する。このようにして、クラウドファブリックは、該中央クラウドよりも桁違いに多い多数のエッジノードから形成される。

該開示されているアプローチは、協働させるためにエッジクラウドをきつく結合することは意図されていないことに留意されたい。エッジクラウドは、複数のエッジノードにわたる協働およびリソース共有を利用する機会を与える。しかし、協働がない場合であっても、エッジクラウドは、上述した便益のうちの多くをもたらす。基本的なステップとして、任意のエッジデバイス上に構成された任意のアプリケーションは、マイクロサービスをホストして、該アプリケーションの要件に基づいて、そのクラスター内の他のノードに応えるために、（中央リソースまたはグローバルリソースの代わりに）そのローカルリソースを用いて優先順位を付ける。例えば、ジャック（Ｊａｃｋ）のデバイスは、ジャックのアプリケーションをホストするためのサーバとして用いるべきである。しかし、協働の場合、該アプローチは、他のノード上のリソースを利用するためにさらに拡張することができる。例えば、ジル（Ｊｉｌｌ）の電話機は、アクティブセッション中ではない場合であっても、ジャックのアプリケーションのためにマイクロサービスを作動させることができ、または、ジャックは、彼のデバイス上に、ジルの動画用のスペアストレージを提供することができ、または、ジルは、その時に、彼女の不十分なセルラー接続の代わりに、ジャックの光ファイバー接続を利用することができる。換言すると、協働は、効率およびスケーリングを著しく向上させることができるが、エッジクラウドを有用にすることは必要ない可能性がある。

該開示されているアプローチによって実施される分散化の第七の原理は、「インフラストラクチャ非依存性」である。前述したように、クラウド分散化の場合、該開示されているクラウドプラットフォームが、オペレーティングシステム、ネットワーク（タイプおよび技術）およびロケーションに依存しないことが望ましい。さまざまな理由により、ノード間の分散化された通信を標準化するための多くの失敗した産業的試みがある。そのため、該提案されている分散化クラウドプラットフォームは、該オペレーティングシステムおよびネットワークの発展と無関係である。換言すると、該開示されているクラウドプラットフォームは、アプリケーション層において、既存のオペレーティングシステムおよびネットワーキング規格のトップで稼動する。この原理は、該開示されているクラウドプラットフォームが、最小限の依存で、または、一切依存せずに、長期的に確実に展開されおよび維持される。また、該開示されているクラウドプラットフォームは、レガシープロトコル、モジュール、ライブラリ、データ等に伴う問題も回避する。

図４は、分散型エッジクラウドプラットフォーム４００の実施形態によるエッジクラウドコンピューティングアーキテクチャの基本的な構成ブロックを示す。該開示されている分散型エッジクラウドプラットフォーム４００は、該上述した原理に基づいて設計され、および展開される。エッジクラウドサーバとして機能するように、すべてのエッジクラウドコンピューティングデバイスを構成することにより、エッジクラウドを有効にする実用的な方法になることが想定されている。前述したように、このようなコンフィギュレーションは、ハードウェアプラットフォーム、オペレーティングシステムおよび基礎となるネットワーキング技術に依存しない、完全に分散化された方法で実行される。該開示されているクラウドプラットフォーム、マイクロサービス、エッジノード（または、エッジクラウドコンピューティングデバイス）、およびクラウドクラスターは、任意のオペレーティングシステム上で作動するように、および任意のネットワークを通じて通信するように構成されている。さらに、該開示されているクラウドプラットフォームおよび分散化されたクラウドサービスは、任意のインフラストラクチャとは無関係である。

図４に示すように、該分散化されたエッジクラウドプラットフォーム４００は、その基本的な構成単位である、中央要素およびエッジ要素を含むエンドツーエンドシステムである。該中央要素は、サーバコンピューティングデバイスによって提供されるバックエンドサービスモジュール４０２を含み、また、該エッジ要素は、該エッジノード有効化モジュール４２６と、一つ以上のマイクロサービス（例えば、図５を参照して後述する符号５１８、５２０、５２２）とを含む。当業者により、該開示されているアーキテクチャが分散されるように意図されていること、および（中央またはエッジの）該要素は、任意の到達可能なエッジクラウドコンピューティングデバイス（例えば、符号３０２、３０４、３０６、３１２）上のどこにでも存在できることは正しく認識されるであろう。

該分散型エッジクラウドプラットフォーム４００の該中央要素について説明すると、該バックエンドサービスモジュール４０２は、インターネットを介して到達可能なサーバ上にホストされ、および該エッジクラウドにわたって該エッジノードまたはエッジクラウドコンピューティングデバイスをサポートするための必要なサービスを提供する。該現在行われている説明の目的のために、エッジクラウドは、ノード（例えば、符号３０２、３０４）から成る集団として定義され、該ノードの各々は、特定のデバイスの能力のコンテキストまたはスコープに基づくグローバルに固有のＩＤを有している。実施形態において、所定のノードは、多数のクラスターのメンバー（例えば、図７のノード７３０を参照）とすることができる。例えば、第一のクラスターは、該ノードを登録した該ユーザに属する該ノードから成る該クラスターである、ユーザアカウントクラスターに対応させることができる。第二のクラスターは、それが物理的に接続されている該リンクローカルネットワーククラスターであるネットワーククラスター（例えば、符号７２６）に対応させることができる。第三のクラスターは、特定の周囲領域内のノードから成る該クラスターである近接クラスター（例えば、符号７３６）に対応させることができる。

実施形態において、該バックエンドサービスモジュール４０２は、ディスカバリーサービス４０６、シグナリングサービス４０８、アイデンティティサービス４１０を含む一つ以上のバックエンドサービスを提供するように構成されている。該シグナリングサービス４０８はさらに、シグナリングエンドポイント（ＳＥＰ）４１２およびベアラエンドポイント（ＢＥＰ）４１４等のリソースを提供する。実施形態において、該一つ以上のバックエンドサービスはさらに、サーバトークンサービス４１６およびレジストリサービス４１８を含む。該サーバトークンサービス４１６は、サービスのためのセキュリティトークン認証／承認機能と関連付けることができる。該バックエンドサービスモジュール４０２は、限定するものではないが、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（登録商標）（ＡＷＳ）等のクラウドウェブサービス４２０を用いて該サーバコンピューティングデバイス（例えば、符号３１２）または該クラウド３０６にホストされる。

実施形態において、該ディスカバリーサービス４０６および該シグナリングサービス４０８の断片または一部は、該バックエンドサーバ（例えば、符号３１２）およびエッジノード（例えば、符号３０２）の両方に実装される。例えば、各クラスター内のネットワークプロキシ（またはノード）は、該シグナリングサービス４０８の一部であり、また、各クラスター内のスーパーノード（または、スーパーエッジクラウドコンピューティングデバイス）は、該ディスカバリーサービス４０６の一部である。該当業者により正しく認識できるように、該開示したクラウドアーキテクチャは、「該エッジ上での該クラウド・クライアント間のサービス」という既存の概念から逸脱している。その価値は、（図７を参照して後述するように）中央クラウド（例えば、符号３０６）から幅広く該エッジノードまでの全範囲にわたるサービスの分散から来ている。

該ディスカバリーサービス４０６は、一つ以上のクラスター、該クラスターの全体のステータス、およびそれらのクラスター内の該ノードを構成するためのナレッジを保持しおよび提供するように構成されている。一旦、クラスターが構成されると、任意の新たなノードが、後に該スーパーノードを介して該ディスカバリーサービス４０６を知らせる該スーパーノードに登録される。スケーラビリティのためにトラフィックを低減するために、該スーパーノードから該ディスカバリーサービス４０６へのアップデートは、日和見的に、および該一つ以上のクラスター内で変化が生じたときにのみ行われる。

実施形態において、該ディスカバリーサービス４０６は、スーパーノードに対して到達可能性テストを実行するように構成されている。スーパーノードがそれ自体を登録した場合、該ディスカバリーサービス４０６は到達可能性を調べる。該スーパーノードは、ファイヤーウォールの背後にあってもよく、それは、該ディスカバリーサービス４０６に発呼を開始することができるが、該ディスカバリーサービスまたは他の外部ノードは、該スーパーノードへの発呼は真似することはできなくてもよい。このような場合、該ディスカバリーサービス４０６は、該クラスターのためのシグナリングエンドポイント（ＳＥＰ）（例えば、符号４１２）を動的に展開するように、該シグナリングサービス４０８に要求することになる。その後、該ディスカバリーサービス４０６は、ＳＥＰアドレスを該スーパーノードに戻す。

また別の実施形態において、該ディスカバリーサービス４０６は、ノードおよびクラスターのプロファイルの完全な一覧表を格納するように構成されている。この一覧表は、すべてのノード上のコンピューティングリソースの詳細と、各ノードのステータスと、各ノードの位置と、各ノード上で利用可能なサービスとを含む。該一覧表は、各ノードおよび該クラスターに到達するためのエンドツーエンドネットワークトポロジーと、該クラスターの該到達可能性と、リソースおよび他の関連のある情報の利用可能性とをさらに含む。換言すると、該ディスカバリーサービス４０６は、該エッジクラウドコンピューティングネットワーク３００にわたるすべてのリソースに対する完全な可視性を有し、および該ネットワーク内の任意の利用可能なリソース上にリアルタイムでサービスを動的に展開するために、この情報を供給することができる。実施形態において、該開示されているアーキテクチャは、開発者が、中央クラウドリソースの場合と同じように同様の方法で該リソースを提示するのを容易にするために、標準的なアマゾンセマンティクスを用いる。

実施形態において、該アイデンティティサービス４１０は、パブリッククラウドに存在し、およびノードに関する認証プロファイルを生成および維持する、例えば、ＯＡｕｔｈ２．０に基づくサードパーティーアイデンティティＳａａＳ（ｓｏｆｔｗａｒｅ ａｓ ａ ｓｅｒｖｉｃｅ）に対応する。実施形態において、該開示されているクラウドプラットフォームは、一つ以上のトークンホルダーのためのトークン生成および管理によって、ノードの認証のために（該サーバトークンサービス４１６とともに）該アイデンティティサービス４１０を用いる。該トークンホルダーは、該エッジノード有効化モジュール（例えば、符号４２６、５０８）、該エッジノード有効化モジュールを用いる該マイクロサービス（例えば、符号５１８、５２０、５２２）、該エッジノード有効化モジュールを利用するアプリケーション開発者、ならびに該アプリケーションの該エンドユーザとすることができる。該開示されているクラウドプラットフォームは、該トークンを利用して、該トークンホルダーのクレデンシャル、正当性を確認し、および該バックエンドサービスモジュール４０２によって提供される該一つ以上のバックエンドサービスへのアクセスを承認する。実施形態において、該承認は、ジェイソンウェブトークン（Ｊａｓｏｎ Ｗｅｂ Ｔｏｋｅｎ：ＪＷＴ）と、該トークンホルダーの該アイデンティティを確認するための標準的な属性情報（ｃｌａｉｍｓ）から成るサブセットの利用を介して実行される。

実施形態において、該シグナリングエンドポイント（ＳＥＰ）４１２および該ベアラエンドポイント（ＢＥＰ）４１４はともに、例えば、該ディスカバリーサービス４０６または該シグナリングサービス４０８から受信した要求に基づいて動的にかつ要求に応じて展開されるリソースである。その結果として、コンピューティングリソースを用意しておく必要はない。このことは、必要な時にだけ該エンドポイントを展開することにより、効率を上げ、およびコストを低減する。該ＳＥＰは、シグナリング通信のために用いられ、一方、ＢＥＰは、データ通信のために用いられ、およびこれらは一緒に、該ノードがトンネリングを日和見的に設定して、シグナリングおよびデータ帯域幅の効率を上げるのを支援する。ＳＥＰおよびＢＥＰは、限定するものではないが、稼動開始の時間、同時接続の数、および通信プロトコル（ＨＴＴＰ、ＳＳＨ、ウェブソケットまたはＵＤＰトンネリング）等のパラメータに基づいて展開される。必要に応じて、エンドポイントは、該最も近い近接性の該クラスター内の利用可能なコンピューティングリソース上に展開することができる。

実施形態において、該サーバトークンサービス４１６は、ＯＡｕｔｈ２．０に基づくＳａａＳベースのソリューションである。実施形態において、該サーバトークンサービス４１６は、トークンをサービスに伝えて、他のサービスに要求を行う。実施形態において、該サーバトークンサービス４１６は、該パブリッククラウドに存在し、およびシステムマップに従ってサービストークンを発行する。さらに、該サーバトークンサービス４１６は、“ｃｌｉｅｎｔ＿ｃｒｅｄｅｎｔａｉｌｓ”フローおよび「リフレッシュトークン（ｒｅｆｒｅｓｈ＿ｔｏｋｅｎｓ）」フローを実装する。マイクロサービスが別のマイクロサービスを呼び出す必要がある場合、該マイクロサービスは、既に有効なトークンを有しているため、該要求を直接実行することができるか、または、パーミッション（または、スコープ）のリストを含むトークンを要求するかのいずれかである。実施形態において、受けるサービスは、入って来る／受けた要求を叶えるために、トークンシグネチャおよびスコープを確認する。実施形態において、トークンを提供するためのこのようなサービスは短命である。

実施形態において、（ＩＴレポジトリともいう）該レジストリサービス４１８は、該パブリッククラウドに存在し、およびすべての該バックエンドマイクロサービスと、それらが属する該クラスターとから成る該リストを維持するＳａａＳソリューションである。該レジストリサービス４１８は、多くの場合、管理目的のために用いられ、クラスターナレッジを維持し、およびクラスターが、コンフィギュレーション目的のためにセルフマネージドできるようになっている。実施形態において、該レジストリサービス４１８は、必要なときに、該シグナリングサービス４０８を識別して該ＳＥＰ４１２またはＢＥＰ４１４を呼び出すために、他のサービス（例えば、該ディスカバリーサービス４０６）が用いることができるクラスターのジオロケーションリスト（または、図６を参照して後述するコンフィギュレーション）を提供する。

次に、該分散型エッジクラウドプラットフォームの該エッジ要素に目を向けると、該エッジクラウドコンピューティングデバイス４０４は、エッジノード有効化モジュール４２６を含む。前述したように、該エッジノード有効化モジュール４２６は、ＯＳレイヤー４２８のトップに位置し、および該マイクロサービスランタイム環境モジュール４２４を用いて、該一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を提供する。また、一つ以上のサードパーティーアプリケーション４２２も、該エッジノード有効化モジュール４２６によりサービスを提供される該エッジクラウドコンピューティングデバイス４０４にホストされている。実施形態において、開発者は、該エッジノード有効化モジュール４２６によって提供されるコンテナマネージャを用いて、該エッジデバイスまたはエッジノードにホストすることができる該開発者自身のマイクロサービスを開発することができる。

実施形態において、該エッジノード有効化モジュール４２６は、任意のエッジデバイス（または、エッジクラウドコンピューティングデバイス）をクラウドサーバに変えて、該クラウドコンピューティングインフラストラクチャを当該の新たなエッジまで拡張するように構成されている。エッジデバイスは、ラップトップ（例えば、符号３０２）、セットトップボックス、ホームゲートウェイおよびＩｏＴゲートウェイ、ゲームコンソールが接続されたＴＶ、車載情報システム（例えば、符号３０８）、スマートフォン（例えば、符号３１４）等の、基本的なコンピューティング能力を備えた任意のデバイスとすることができる。どのようなエッジデバイスも、該エッジノード有効化モジュール４２６をダウンロードし、およびそれを実行してクラウドサーバに「なる」ことができる。該現在行われている説明の目的のために、該エッジノード有効化モジュール４２６を実行した任意のエッジデバイスは、「ノード」と呼ぶこととする。このようなノードは、該開示されているエッジクラウドプラットフォームおよびアーキテクチャを対象としている一つ以上の特性を有している。該一つ以上の特性は、該ＯＳおよびネットワークと無関係に、互いに（または、他のノードを）動的に見つけるための該能力を含み、および該コンピューティングおよび利用可能な能力および機能を互いに呈示する該能力を含む。該一つ以上の特性は、クラスター（エッジクラスター）に構成および組織化して、インターネットの可用性がない場合であっても該クラスター内で、および複数のクラスターにわたって通信する該能力をさらに含む。

該開示されているエッジクラウドプラットフォームは、上述したようなクラスタリングに関する該第三の原理に従って、クラスターノードの形成によって作動する。一つ以上のクラスターは、特定のスコープに基づいて、第一のアクティブノード（または、第一のエッジクラウドコンピューティングデバイス）によって構成される。ノード（例えば、第一のエッジクラウドコンピューティングデバイス）が有効化（エッジノード有効化モジュール４２６によって使用可能に）されると、該ノードは先ず、グローバルディスカバリーを管理し、および該エッジクラウドの該ナレッジを保持するスーパーノードを探す。スーパーノードが見つからない場合、該第一のノードは、それ自体を該スーパーノードとして宣言する。インターネットが利用可能である場合には、該スーパーノードは、その存在をグローバルディスカバリーに知らせ、および該所定のスコープ内のノードの該リストを受信する。該スーパーノードは、効率を維持するために、そのスコープ内の他のノードに知らせる。

該スーパーノードによりクラスターの形成に続いて、該クラスターに入る後続のノードは、該既存のスーパーノードを見つけて、それら自体を該スーパーノードに登録し、およびそれらのスコープ内のノードの該リストを受信する。該新たなノードは、それらのスコープ内の他のノードに存在を知らせる。このブートストラップモデルは、グローバルかまたはローカルかに関わらず、任意のノードのオーバーロードを避けて、それによってトラフィックおよびチャティネスを低減するために、該開示されているクラウドアーキテクチャによって用いられる。該ノードの潜在的な非永続性を仮定すると、プレゼンス通知は、他のどのノードに通知するかを判断する該責務とともに、該ノードそれ自体の機能として意図されている。

上述したように、該エッジノード有効化モジュール４２６は、任意のエッジクラウドコンピューティングデバイスまたはサーバ上に存在することができ、およびさまざまなハードウェアプラットフォームおよびオペレーティングシステムに対して利用可能にすることができる。実施形態において、該エッジノード有効化モジュール４２６は、アプリケーションレベルのソフトウェアに相当し、そのため多くの種類のエッジクラウドコンピューティングデバイスにダウンロードすることができる。該バックエンドサービスモジュール４０２は、中央クラウド（例えば、符号３０６）にホストされた一つ以上のバックエンドサービス、または、十分なコンピューティングおよびメモリを備えた任意の到達可能で信頼性のあるコンピューティングリソースを提供し、および該エッジノードをサポートするための必要なサービスを提供する。

図５は、実施形態によるエッジクラウドコンピューティングデバイス５００を示す。図示されているように、該エッジクラウドコンピューティングデバイス５００は、メモリ５０４に結合されたプロセッサ５０２を含む。該メモリは、本願明細書に記載されているさまざまな技術を実施する命令を有する非一時的なコンピュータ可読媒体に相当する。実例のコンピュータ可読媒体は、該プロセッサ５０２によって実行可能なコンピュータが実行可能な命令を有する、有形の非一時的なコンピュータ可読記憶媒体を備えることができ、該命令は、該プロセッサによって実行される場合に、該プロセッサに、本願明細書に記載されているさまざまな方法およびアプローチの任意の組合せを実行させる。図示されてはいないが、すべての該エッジクラウドコンピューティングデバイス（符号３０２、３０４、３０８、３１０、３１２、３１４、３１６、４０４）および該中央クラウド（例えば、符号３０６）が、少なくともプロセッサ（例えば、符号５０２）と、メモリ（例えば、符号５０４）と、および／または該プロセッサによって実行される場合に、本願明細書に記載されている該方法およびアプローチを実行する、該メモリに格納された他のさまざまなアプリケーションまたはモジュールを含むことは正しく認識することができる。

該メモリ５０４は、ＯＳレイヤー５０６と、エッジノード有効化モジュール５０８とを含む。該エッジノード有効化モジュール５０８は、ＡＰＩゲートウェイを有するネットモジュール５１０をさらに含む。また、該エッジノード有効化モジュール５０８は、コンテナマネージャマイクロサービス（μＳ）イメージリポジトリ５１２と、ＨＴＴＰリクエストラッパー（ｌｉｂ．）５１４と、埋め込みウェブサーバ５１６も含む。前述したように、該エッジノード有効化モジュール５０８は、一つ以上のマイクロサービスを、一つ以上のエッジノードに呈示するように構成されている。実施形態において、該エッジノード有効化モジュール５０８は、ダウンロードを開始／停止させ、該エッジクラウド内の任意のサービスを展開し、および該ＡＰＩゲートウェイを用いて該サービスを呈示するように構成されている。この目的のために、該エッジノード有効化モジュール５０８は、一つ以上のクラスター（内または、にわたる）他のエッジノードを見つけて、該エッジノードと接続して通信するように構成されている。また、該メモリ５０４は、図５において符号５１８、５２０および５２２として示す一つ以上のマイクロサービス（μＳ）も含む。該マイクロサービス５２２は、ユーザインタフェース（ＵＩ）アプリ５２４の一部であるように図示されている。また、該メモリ５０４は、中にマイクロサービスがない他のＵＩアプリ５２６も含む。すべての該マイクロサービス（符号５１８、５２０および５２２）と該ＵＩアプリ（符号５２４および５２６）は、図５に符号５２８として示すサードパーティーが呈示するＡＰＩを介してアクセス可能である。

実施形態において、該エッジノード有効化モジュール５０８は、ソフトウェアライブラリと、対応するＡＰＩとから成るコレクションに相当する。新たなハイパー接続されおよび高度にモバイル分散化されたエッジコンピューティングワールド内でのノードのネットワーク化に関する基本的な課題を有効に解決するために、開発者が該ソフトウェアライブラリおよびＡＰＩも用いることができることが意図されている。該エッジノード有効化モジュール３０８は、任意のエッジクラウドコンピューティングデバイスに関連するＯＳ、製造会社および接続ネットワークに関係なく、異種環境に供給することができる。さらに、該エッジノード有効化モジュール５０８は、該アプリケーションのユースケースにより、任意のＰＣ、サーバ、モバイル機器、固定ゲートウェイ、自律式自動車ゲートウェイ、コネクテッドＴＶ上でまたは該クラウド内でも作動する（実行させる）ことができる。前述したように、一旦、該エッジノード有効化モジュール５０８がエッジデバイスにロードされると、該エッジデバイスはエッジクラウドノードになる。

図５に示すように、該エッジノード有効化モジュール５０８は、オペレーティングシステムレイヤー５０６と、エンドユーザアプリケーション（例えば、符号５２４、５２６）との間に存在する。該エッジノード５００から利用可能ないくつかのマイクロサービス（例えば、符号５１８、５２０、５２２）があり、および該エッジノード有効化モジュール５０８は、サードパーティーが、それら自体のマイクロサービスを開発するための該能力を提供する。また、該エッジノード有効化モジュール５０８は、マイクロサービスランタイム環境も提供する。前述したように、該エッジノード有効化モジュール５０８を組み込むことにより、コンピューティングデバイスは、一つ以上のクラスターを構成することができるインテリジェントなネットワークノードまたはエッジノードに変換される。該エッジノード有効化モジュール５０８は、特に分散型エッジクラウドノードでのネットワーク化の複雑性を取り除き、それによって、開発者が、小さなモバイル機器（例えば、符号３１４）であってもマイクロサービスモデルにおけるそれらのソリューションに集中することを可能にする。

クラスター内のノードは、物理的なハードウェア能力、ＯＳ、付随するネットワーク接続性、各ノード上で作動するマイクロサービスの種類、および利用法／プライバシーポリシー設定により、特定の役割または役割の組合せを担うように構成されている。いくつかの役割は、選択のプロセス、その時々での該クラスター内の他のノードの考慮を介して割り当てられ、一方、他の役割は、選定のプロセスを介して割り当てられる。前述したように、クラスターにおける最も重要な役割の一つは、すべてのメンバーノードによってノードがそれに選択されるスーパーノード（または、スーパーエッジクラウドコンピューティングデバイス）である。単一ノードクラスターの自明なケースにおいて、ノードは、それ自体のスーパーノードとして作用する。スーパーノードは、クラスターおよびすべてのそのメンバーノードに関する情報のベアラ―になるように構成されている。それは、該クラスターのための「信頼できる唯一の情報源（ｓｉｎｇｌｅ ｓｏｕｒｃｅ ｏｆ ｔｒｕｔｈ）」である。該スーパーノードは、他のノードに関連する情報、各ノード上に展開されるマイクロサービス、ならびにエッジノード有効化モジュール５０８の動作によるヒストリカルアーチファクトを維持するように構成されている。該スーパーノードは、リンクローカルプロキシおよびリンクローカルキャッシュ等の役割を該クラスター内の他のノードに割り当てるように構成されている。リンクローカルプロキシノードは、クラスターノードがファイヤーウォールの背後に存在する場合に通信をサポートする。一方、大量の物理的ストレージを伴うノードには、該クラスターのための該リンクローカルキャッシュの役割を割り当てることができる。

各ノードに対して、該エッジノード有効化モジュール５０８は、ユニークユーザおよび多数のマイクロサービスおよびアプリケーションプロバイダ（「テナント」ともいう）をサポートする。換言すると、ユーザが、それらすべてが該エッジノード有効化モジュール５０８を採用するモバイル機器に多数のアプリケーションをロードした場合であっても、機能および能力は、当該ユーザに関連している（および当該ユーザのために承認される）。

実施形態において、該エッジノード有効化モジュール５０８は、物理的レベルおよびマイクロサービスレベルの両方で、エッジデバイス間でのディスカバリー、接続および通信を提供できる。例えば、該エッジノード有効化モジュール５０８は、ローカルおよびグローバルのネットワーク内でのエッジノード有効化モジュールのインスタンスを用いたすべてのノードに対するオートディスカバリーおよびオートルーティングにより、ノードおよびサービスディスカバリーを提供する。同様に、該エッジノード有効化モジュール５０８は、自己管理されたクラスターを構成するノードから成るアドホックのエッジクラウド内でノードおよびサービス接続を提供する。実施形態において、該エッジノード有効化モジュール５０８は、マイクロサービスインスタンスを（リモートで／ローカルで）ローディングし、作動させおよび管理することにより、該一つ以上のマイクロサービスを管理するためのライトなコンテナを提供するように構成されている。前述したように、該エッジノード有効化モジュール５０８は、マイクロサービスランタイム環境を提供するためのエッジウェブサーバを含む。

前述したように、該エッジノード有効化モジュール５０８を有するノードは、互いに見つけ、接続して通信するように構成されている。実施形態において、ディスカバリーは、あるユーザアカウント、すなわち、同じユーザアカウントＩＤの下で登録されたノードに対応する一つ以上のスコープに基づく「フィルタ処理検索」作業である。実施形態において、該エッジノード有効化モジュール５０８は、（該バックエンドサービスモジュール４０２によって提供される該アイデンティティサービス４１０として用いられる）サードパーティーアイデンティティＳａａＳプロバイダを介してＯＡｕｔｈ２．０ベースのＯｐｅnＩＤ規格を採用している。また、該スコープは、同じリンクローカルクラスターネットワークの一員であるノード等のネットワークに対応することもできる。この場合の該リンクローカル識別子は、パブリックＩＰアドレスと該リンクローカルネットワークアドレスを組合せることによって形成される。また、該スコープは、近接性、例えば、ある地理的位置に、または、地理空間クエリによって定義された領域内に物理的に存在するとしてそれら自体を報告するノードに対応することもできる。該エッジノード有効化モジュール５０８によって実行されるディスカバリープロセスは、該上述したスコープの任意の組合せを利用することができる。それらの各ノード上のおよびクラスターにわたるマイクロサービスは、該エッジクラウドを利用して、ＡＰＩを介して互いに呼び出すことによって、それら自体のサービスメッシュを構成することができる。さらに、ノードおよびノード上で作動するマイクロサービスは、固有識別子を有し、例えば、特定のノード上の特定のマイクロサービス（例えば、ドライブ）は、固有に、ローカルにおよびグローバルに対応可能である。

さらに、該エッジノード有効化モジュール５０８は、マイクロサービスに関連する該サービスを共通の埋め込みウェブサーバを介して呈示するためのマイクロサービスランタイム環境（ライトなコンテナ）を提供する。各サービスのためのＡＰＩエンドポイントは、該ネットモジュール５１０の一部である該ＡＰＩゲートウェイを介して、エッジクラスター内の他のすべてのノードからアクセス可能である。該エッジノード有効化モジュール５０８は、コンテナデーモン（または、Ｄｏｃｋｅｒ（登録商標））を二つの異なる方法で補完する。コンテナデーモンを作動させることができる環境（例えば、Ｌｉｎｕｘ（登録商標））において、該エッジノード有効化モジュール５０８は、前述したようなエッジノードから成るアドホッククラスターを管理するための機能を提供する。コンテナデーモンを作動させることができない環境（例えば、スマートフォン）では、該エッジノード有効化モジュール５０８は、マイクロサービスをダウンロードし、展開しおよび作動させる該能力を備えた追加的な「ライトな」コンテナ性能を提供する。該埋め込みウェブサーバ（例えば、符号５１６）は、一つ以上の制約を備えたコンテナ管理（例えば、Ｄｏｃｋｅｒ（登録商標））ＡＰＩのサブセットを提供する。該一つ以上の制約は、基礎を成すＯＳ（アンドロイド（登録商標）用のｊａｖａ、ｉＯＳ（登録商標）用のオブジェクティブｃ等）に基づく特定の言語の利用を含む。該一つ以上の制約は、該基礎を成すプラットフォーム上の限定されたリソースの使用を最適化するための（エッジノード有効化モジュール５０８によって提供される）該「ライトな」コンテナ環境で作動する該マイクロサービスによる、該エッジノード有効化モジュール５０８によって提供される該ウェブサーバの該利用を含む。

該エッジノード有効化モジュール５０８は、開発者が、任意のノード上にマイクロサービスを構成してホストすることを可能にする。該開示されているクラウドアーキテクチャは、アプリケーション開発の速度を上げ、および開発者が、該分散型エッジクラウドプラットフォームをすぐに活用することを可能にするために、該エッジノード有効化モジュール５０８を利用するさまざまなマイクロサービスも提案している。例えば、ドライブマイクロサービスの場合、エッジノード上で利用可能なストレージへのアブストラクトなアクセス、およびポピュラーなＡＰＩを介した分散型ファイル管理を提供することができる。別の例示的な実施例においては、ノードからノードへおよび／またはサービスへ、ピアツーピア、一対一および一対多数方式でコンテンツを送るビーム（ｂｅａｍ）マイクロサービスが提供される。

実施形態において、該エッジノード有効化モジュール５０８は、アプリケーションを異なる技術を用いて構成されたコンポーネントに分解できるようにするサイドカーパターンを実装している。該サイドカーパターンを用いることで、アプリケーションの任意のコンポーネントを単独で構成して展開することができる。該レイテンシは、該アプリケーションおよびコンポーネントを有する該サイドカーの近接性により低減され、該アプリケーション自体を変更することなく、機能を追加することができる。該サイドカーパターンは、該サービスメッシュに対処するという該複雑性の多くを取り除く。このことは、それらの複雑性の多くが、該エッジクラウドにわたって展開されたマイクロサービスの該種類とは無関係であるため、該開示されているエッジクラウドコンピューティングアーキテクチャにおいて可能である。しかし、該サイドカーパターンは、該ネットワークの分散型の性状を隠さない可能性がある。実施例として、ＡＰＩゲートウェイまたはセキュリティトークン管理は、サイドカーパターンを用いて構成することができる。実施形態において、該ＡＰＩゲートウェイは、該エッジノード有効化モジュール５０８内の該ネットモジュール５１０の一部である。該ＡＰＩゲートウェイは、各サービスのための該ＡＰＩエンドポイントを、クラスター内の他のすべてのノードからアクセス可能にする。このＡＰＩゲートウェイを提供することにより、該エッジノード有効化モジュール５０８は、異なるクラスター内で他のマイクロサービスを扱うという該複雑性を取り除く機能を提供する。

該エッジノードにおいて、セキュリティは、マイクロサービスがどのように通信するかという極めて重要な側面になる。ファイヤーウォールおよびネットワークのパーティション化のようないくつかの要素は、中央クラウドにおいてごく一般的であるが、一般的には、該エッジ上に存在していなくてもよい。したがって、多くのレベルのセキュリティを取り扱うことが必要である可能性がある。例えば、該リンクローカルクラスター上では、該クラスター内のノードはドメイン名を有していないため、ｈｔｔｐｓを用いることは可能ではない。そのため、該同じリンクローカルネットワーク内のノード間の該通信は暗号化される。さらに、各マイクロサービスの該ＡＰＩは、トークンを介して保護される。一般に、該エッジノード有効化モジュール５０８は、トラストレスなネットワーク環境内で作動する。そのため、該ファイヤーウォールが、エッジノード上で作動している該マイクロサービスを保護することを仮定することはできない。実施形態において、有効で期限切れではないトークンを有することに対処することは、該サイドカーパターンによって取り除かれる。他のノード（例えば、キャッシュノード、または、リンクローカルプロキシノード）からのデータを管理することができるいくつかの特別なノードがあるため、ユーザペイロードは、許可されたパーティーに対してのみ見えるように暗号化される必要性がある可能性がある。実施形態において、キーの取得、ユーザペイロードの暗号化および解読も該サイドカーによって取り除かれる。

近接性およびユーザアカウントクラスターの場合、正しいノードへのルーティングは、該スーパーノードおよびリンクローカルプロキシノードの扱いを要する複雑な作業である。実施形態において、該サイドカーは、この複雑性を、該マイクロサービスの該開発者から隠し、および該開発者は、該クラスター内の該適切なマイクロサービスを実施することのみが必要である。分散型システムは、フォールトトレランスを確保するためのリトライメカニズムを必要とする。実施形態において、該サイドカーは、リトライコールおよびリトライストラテジーを扱う。開発者は、分散型システムの該複雑性にではなく、それらのマイクロサービスの開発に集中することができる。開発者がサービスメッシュを扱うのを補助するイスティオ（Ｉｓｔｉｏ）のようなバックエンド技術と同様に、該エッジノード有効化モジュール５０８は、該エッジにおいて該サービスメッシュを扱い、およびエッジデバイスをサーバとして用いるというすべての該制約に対処する。

図６は、実施形態による例示的なバックエンドマイクロサービス分散６００を示す。実施形態において、該エッジクラウドコンピューティングプラットフォームの該バックエンドシステムは、図６に示すようなマイクロサービスベースのアーキテクチャを用いて設計および展開される。図６を参照すると、各要素は、地理的に分散されたデータストア６１４にリンクされているマイクロサービス６０４、６０６、６０８、６１０および６１２から成る地理的に展開されたクラスターから成るグループ６０２で構成されている。実施形態においては、該同じクラスターまたは異なるクラスター内の該一つ以上のマイクロサービスが、同じ見解を有することを確実にするために、該ディスカバリーサービス（例えば、符号４０６）、該レジストリサービス（例えば、符号４１８）、該サーバトークンサービス（例えば、符号４１６）および該アイデンティティサービス（例えば、符号４１０）のための該データストア（例えば、符号６１２）は、矛盾のない方法で同期される必要がある。

実施形態において、該シグナリングサービス、ＳＥＰ（例えば、符号４１２）およびＢＥＰ（例えば、符号４１４）の場合、各マイクロサービスクラスターは、地理的に独立している。該シグナリングサービス（例えば、符号４０８）は、ＳＥＰ（例えば、符号４１２）コンポーネントおよびＢＥＰ（例えば、符号４１４）コンポーネントを起動するためのＡＰＩを提供するのに用いられる。該シグナリングサービス４０８は、該シグナリングサービス４０８のクラスター内の該既存のＢＥＰ４１４およびＳＥＰ４１２の経過を追い、および該ＢＥＰおよびＳＥＰを適切に負荷平衡させるのに必要な情報を提供する。該ＢＥＰおよびＳＥＰがどこに必要かに基づく最適なレイテンシを提供するために、該シグナリングサービス４０８は、独立して地理的に分散される。

実施形態において、該マイクロサービスから成る地理的に展開されたクラスターは、エッジクラウドコンピューティングデバイスから成るそれぞれのクラスターに対応することができる。換言すると、最良の状況の場合、クラスター内のエッジクラウドコンピューティングデバイスにホストされている該マイクロサービスは、該クラスター内の該エッジノードに対して利用可能なマイクロサービスのクラスターを構成することができる。実施形態において、該マイクロサービスから成る地理的に展開されたクラスターは、エッジクラウドコンピューティングデバイスから成る多数のクラスターに対応することができる。換言すると、次に最良の状況の場合、異なるクラスター（例えば、二つのクラスター）内のエッジクラウドコンピューティングデバイスにホストされた該マイクロサービスは、該（二つの）クラスター内の該エッジノードに利用可能なマイクロサービスから成るクラスターを構成することができる。

図７は、実施形態による例示的なエッジクラウドアーキテクチャ７００を示す。前述したように、分散化したクラウドの該価値は、中央クラウド（例えば、符号３０６）から幅広く該エッジノードまでの全範囲にわたるサービスの分散から来ている。図７は、ディスカバリーサービス７０４と、シグナリングサービス７０６と、アイデンティティサービス７１２と、サーバトークンサービス７１４と、レジストリサービス７１６とを含む一つ以上のバックエンドサービスを提供するように構成されているバックエンドサービスモジュール７０２を示す。該シグナリングサービス７０６は、シグナリングエンドポイント（ＳＥＰ）７０８およびベアラエンドポイント（ＢＥＰ）７１０を提供するように構成されている。該一つ以上のバックエンドサービスは、クラウドウェブサービス７１８上にホストされている。該開示されているクラウドアーキテクチャは、該バックエンドサービスモジュール７０２と、該クラウド内の該一つ以上のノードとの協働が、一つ以上のクラスターを構成することを可能にしている。

例えば、図７は、三つのクラスター、すなわち、ネットワーククラスター１（符号７２６）と、ネットワーククラスター２（符号７３２）と、近接クラスター３（符号７３６）とを示す。該ネットワーククラスター１（符号７２６）は、三つのノード、すなわち、スーパーノード（符号７２０）であるノード１と、ノード２（符号７２２）と、ネットワークプロキシノード（符号７２４）であるノード３とを含む。該ネットワーククラスター２（符号７３２）は、二つのノード、すなわち、スーパーノードであり、かつネットワークプロキシノード７２８であるノード５と、キャッシュプロキシノード７３０であるノード６とを含む。該近接クラスター３（符号７３６）は、二つのノード、すなわち、ノード４（符号７３４）と、キャッシュプロキシノード７３０であるノード６とを含む。前述したように、これらのノードの各々は、エッジノード有効化モジュール（例えば、符号４２６、５０８）と、一つ以上のマイクロサービス（例えば、符号５１８、５２０）と、一つ以上のサードパーティーアプリ（例えば、符号４２２、５２４、５２６）とを含む。該上述したクラスターは、前述したような一つ以上のスコープに基づくものとして構成されている。例えば、該ネットワーククラスター１および２（符号７２２および７２８）は、スコープとしてのネットワークに基づいて構成され、および該近接クラスター３は、スコープとしての近接性に基づいて構成されている。また、図７に示すように、所定のノードを、二つのクラスターの一部とすることができ、例えば、キャッシュプロキシノード７２６であるノード６は、ネットワーククラスター２（７２８）および近接クラスター３（符号７３２）の一部である。前述した考察に基づいて、さまざまな役割がさまざまなノードに割り当てられている。

該シグナリング（ＳＥＰ）およびベアラ（ＢＥＰ）エンドポイントの仕組みは、図８に示す該実施例によって最も良く例示することができる。図８は、同じユーザＩＤに属する二つのエッジクラウドコンピューティングデバイスのためのディスカバリー、接続および通信を有するシステム８００の例示的な実施形態を示す。図７と同様に、図８は、クラウドウェブサービス８１８にホストされたディスカバリーサービス８０４、シグナリングサービス８０６、アイデンティティサービス８１２、サーバトークンサービス８１４、レジストリサービス８１６を含む一つ以上のバックエンドサービスを提供するように構成されたバックエンドサービスモジュール８０２を示す。該シグナリングサービス８０６は、シグナリングエンドポイント（ＳＥＰ）８０８およびベアラエンドポイント（ＢＥＰ）８１０等のリソースを動的に展開するように構成されている。

また、図８は、二つのクラスター、すなわち、ネットワーククラスター１（符号８２６）およびネットワーククラスター２（符号８３２）も示している。該ネットワーククラスター１（符号８２６）は、三つのノード、すなわち、スーパーノード（符号８２０）であるノード１と、ノード２（符号８２２）と、ネットワークプロキシノード（符号８２４）であるノード３とを含む。該ネットワーククラスター２（符号８３２）は、二つのノード、すなわち、スーパーノードであり、かつネットワークプロキシノード８２８であるノード５と、キャッシュプロキシノード８３０であるノード６とを含む。

該現在行われている説明の目的のために、二つのノード（ネットワーククラスター１内に符号８２２として図示されているノード２と、ネットワーククラスター２内に符号８３０として示されているノード６）が、該同じユーザ（アカウント）に属し、および既に、それらそれぞれのリンクローカルネットワーククラスターに登録されていると仮定する。これら二つのノードは、該同じユーザアカウントに属しているが、二つの異なるクラスターの一部であることに留意すべきである。該開示されているエッジアーキテクチャは、直接アクセス可能であるかのように、ノード２（符号８２２）と通信するのに用いることができる、ノード６（符号８３０）のための到達可能なエンドポイントとして該ＳＥＰ８０８を提供する。これら二つのノード間の該通信は、該ＳＥＰ８０８を用いたクラスター間方式で実行される。該シグナリングが確立された後、該ＢＥＰ８１０が、該二つのノード８２２および８３０間での大量のやり取りのために提供される。別々のシグナリングという柔軟性およびベアラチャネルは、ＨＴＴＰベースのサービス供給に制限されない「サービス専用の」ＢＥＰの形成を可能にする。

前述したように、ディスカバリー、ノード間の接続および通信のプロセスは、スコープ（例えば、ネットワーク）に属するノードのために（新たなノードによる）ディスカバリーリクエストを該スーパーノード（例えば、符号８２０）に送信するという第一のステップを含む。該プロセスは、該スーパーノードからの適切なシグナリング情報とともに、ノードのリストを取得するステップをさらに含む。該プロセスは、ＳＥＰ（例えば、符号８０６）を介して（異なるクラスター内の）リモートノードにリクエストを送信することをさらに含む。また、該プロセスは、サービスを提供するためのリモートノードリクエストＢＥＰ（例えば、符号８１０）も含む。該プロセスは、用意されている該ＢＥＰを介して該サービスを消費するために接続して通信するという該ステップで終わる。

前述したように、該エッジノード有効化モジュール４２６の主な利点のうちの一つは、該マイクロサービスの概念およびアーキテクチャを用いて、典型的なクライアント装置にフロントエンドアプリケーションを展開する該能力である。マイクロサービスへの移動は、三つの主要なトレンドによって起動される。第一に、マイクロサービスは、（ＨＴＴＰ ＲＥＳＴベースの）ＲＥＳＴｆｕｌ ＡＰＩを実装し、および呈示する。使い勝手の良いＡＰＩのセットは、内部の複雑性を隠し、およびシステム内でのマイクロサービス間の通信を容易にする。第二に、パイプラインインフラストラクチャ（例えば、Ｊｅｎｋｉｎｓ）によって制御される展開スクリプト（例えば、Ａｎｓｉｂｌｅ）を用いて、マイクロサービスを自動的に展開することにより、潜在的に大量のシステム要素で構成された複雑なシステムを構築することが可能である。さらに、自動化した展開は、展開をどこで起こすかを決定する該能力を与えることにより、フレキシブルなシステムを構築するのを助けることができる。第三に、ＩＴリソース（例えば、ＣＰＵ、ストレージおよびネットワーク）をシンプルなＡＰＩを介して要求し、およびそれらのリソースをほぼリアルタイムで取得する該能力は、大きなおよびスケーラブルなシステムの形成を、より実現可能にする。

しかし、マイクロサービスおよびエッジクラウドへの移行は、異なる知識と専門技術が一緒に混ざっているため、より密接に作業する開発チームを要する可能性がある。例えば、バックエンド開発者のスキルを要する可能性がある。数十億の小さなクライアント（例えば、ＩｏＴ）をサポートするのは、該中央クラウドにとってかなりの負担である。一方、多すぎるリソースは、該エッジ上のクライアントからの信号を待っているアイドリング状態のままでいる可能性がある。他方においては、時々、アプリケーションの性能要求を満たすことは、実現可能でない可能性がある。例えば、欧州のクライアントをサポートするために、米国内でバックエンドシステムを展開することは、多くのアプリケーションに対するレイテンシ制約を満たさない可能性がある。そのため、バックエンド開発者は、これらの新たな要求をサポートするのを助けるために、クライアントリソースをより良く活用する必要がある。彼等は、該アプリケーションを作動させている該「クライアント」装置に該バックエンドシステムの一部を展開することが必要な場合であっても、該アプリケーションにより近い該機能の多くを強制的にオフロードすることができる。

該移行の実施に必要なまた別の専門技術は、ＩＴ／ＤｅｖＯｐｓである。長い間、ＩＴチームは、ソリューションを展開すべき該インフラストラクチャを考え出して管理することに対して責任を負ってきた。彼等は、展開コストおよび稼働コスト、スケーラビリティおよび弾力性等の多くの制約やパラメータを考慮しなければならない。ほとんどのアプリケーションの場合、該クラウドインフラストラクチャの該スコープは、単一のデータセンターであり、その主なタスクは、コンピューティングおよびネットワーキングリソースの制約に対応することである。該エッジにおけるデバイスおよびデータの急増をサポートするためには、該スコープを、適切なときにおよび（一般的にはデータセンターの該スコープを越えた）適切な場所にＩＴリソースを展開することまで拡張すべきである。近接性、アカウントおよびリンクローカルプレゼンス等の新たなスコープは、有効な展開および運用を確実にするように考慮する必要がある。

該移行の実施に必要なまた別の専門技術は、フロントエンド開発者である。該フロントエンドアプリケーションは、該バックエンドへの情報の入力および送信、および／または該バックエンドから来る情報のレンダリング等のシンプルなタスクを実行するのに用いられる。該複雑な機能のほとんどは、一般に、該バックエンドサーバへ追いやられる。しかし、該エッジで生成されるデータの急増を仮定すると、キャッシング、拡張現実（ＡＲ）、画像認識、承認および認証等の多くの新たな機能を「クライアント装置」でサポートしなければならない。その結果として、フロントエンドアプリケーションは、より大きくかつより複雑になって来ている（例えば、ｉＯＳ（登録商標）上でのＦａｃｅｂｏｏｋ（登録商標）アプリは、二年に満たないうちにサイズが三倍になって、３００Ｍバイトを超えてきている）。そのため、モノリシックのフロントエンドアプリデザインからマイクロサービスアーキテクチャへ移行し、および該フロントエンドアプリサブシステムをマイクロサービスに分解する機会がある。その場合、該アプリは、（中央クラウドにホストされている）該バックエンドで作動しているものとともに、該デバイス上でローカルであるマイクロサービスをシームレスに呼び出すことができる。

マイクロサービスベースのシステムの多くの結果のうちの一つは、マルチテナンシーとシングルテナンシーの間の選択である。パブリッククラウドの主な便益は、多くのアプリケーションが、パブリッククラウドリソースと、該リソース上に展開されたマイクロサービスとを共有することができるマルチテナンシーである。しかし、いくつかのアプリケーションは、セキュリティまたはデータプライバシー等のさまざまな理由のために、シングルテナントのままでいる必要があるマイクロサービスを展開しなければならない可能性がある。そのため、あるマイクロサービスがマルチテナントであるか、またはシングルテナントであるかを選択することができるハイブリッドアプローチが、より良好なアプローチである可能性がある。

また別の重要な側面は、マイクロサービスがシングルユーザであるか、またはマルチユーザであるかである。一見して、マルチユーザマイクロサービスがより望ましいと思われる。しかし、常にそうとは限らない可能性がある。例えば、マイクロサービスが、一方のみがクライアントとして作動し、他方がサーバとして作動する、一つの「クライアント装置」内または「クライアント装置」のペア内のシングルユーザに常にサービスを提供する場合、マルチユーザプラットフォームは非効率的である可能性がある。そのため、マイクロサービスがマルチユーザであるか、またはシングルユーザであるかを選択することができるハイブリッドアプローチが、より良好なアプローチである可能性がある。

システムの該複雑性が増すにつれて、それらの両側面に対するハイブリッドアプローチの恩恵が最も重要になる。実施形態において、該エッジノード有効化モジュール（例えば、符号４２６）は、バックエンド、フロントエンドおよびＤｅｖＯｐｓに利益をもたらすハイブリッドアプローチの実施の柔軟性および容易さを与えるために、スクラッチから開発してもよい。該便益は、図９および図１０に関連して記載されているように、簡潔さ、柔軟性、繰り返し展開能力、および該展開のスケーラビリティを含むことができる。

図９は、実施形態による、サイドカーパターンでサーバレスのマイクロサービスを用いて実装された例示的なエッジクラウドアーキテクチャ９００を示す。図示されているように、該アーキテクチャ９００は、サードパーティーアプリケーションまたはクライアントアプリケーション９０４を作動させるクライアント装置９０２を含む。該クライアント装置９０２は、エッジノード有効化モジュール９２２と、一つ以上のローカルにホストされたマイクロサービス９２６、９２８および９３０とを含む。該エッジノード有効化モジュール９２２は、該中央９１２にまたは該クラウドコンピューティングデバイス９１４にホストされたＡＰＩゲートウェイ９０８と通信するＡＰＩゲートウェイ９２４を含む。実施形態において、該エッジノード有効化モジュール９２２は、該クライアントアプリケーション９０４からリクエストを受取り、該リクエストに応えるのに必要な一つ以上のマイクロサービスの種類を判断する。該リクエストに、ローカルにホストされたマイクロサービス（例えば、符号９２６、９２８、９３０）が応えることができる場合には、該ＡＰＩゲートウェイ９２４が、インスタンス化され、または開始されている該適切なマイクロサービスに該リクエストを送信する。該ローカルにホストされたマイクロサービスは、リモートデバイスからロードすることができ、または、該クライアントアプリケーション９０４からの該要求に基づいて（実行時に）動的にインスタンス化することができる。該開始されたマイクロサービス（例えば、符号９２６）は、該リクエストに応えて、レスポンスを該ＡＰＩゲートウェイ９２４を介して該クライアントアプリケーション９０４に返信する。

しかし、該リクエストに応えるのに必要なマイクロサービスの該判断された種類がグローバルなタイプである場合、または、グローバルにホストされたマイクロサービスに相当する場合には、該ＡＰＩゲートウェイ９２４は、ｈｔｔｐ／ｈｔｔｐｓリクエスト９０６を該ＡＰＩゲートウェイ９０８に送信する。該ＡＰＩゲートウェイ９０８は、該ｈｔｔｐ／ｈｔｔｐｓリクエスト９０６に応えるために、該中央クラウド９１２にグローバルにまたは中央にホストされている適切なマイクロサービス（例えば、符号９１６、９１８、９２０）を開始する。該ＡＰＩゲートウェイ９０８は、ｈｔｔｐ／ｈｔｔｐｓレスポンス９１０を該ＡＰＩゲートウェイ９２４に送信する。図１とは対照的に、該クライアントアプリケーション９０４は、該エッジノード有効化モジュール９２２によって呈示されている、ローカルにホストされたマイクロサービスを、および該ＡＰＩゲートウェイ９０８によって呈示されている該グローバルにホストされたマイクロサービスも活用することができる。

実施形態において、バックエンド開発者は、妥当と思われる場合、マルチユーザマイクロサービスから、該アプリケーションに対して最も近いリソース上に、すなわち、該フロントエンドアプリケーションが作動している該同じリソース上に存在するシングルユーザマイクロサービスに容易に移行することができる。実施形態において、該リソースは、該アプリケーションが、該エッジノード有効化モジュールによって提供される該ＡＰＩゲートウェイを介してリクエストを実行した場合にのみ、該アプリケーションが存在する際におよび該マイクロサービスが存在する際に存在する。このことは、マルチユーザマイクロサービスの展開の該複雑性を低減し、およびサーバレスマイクロサービスモデルを、中央クラウドを越えてあらゆる種類のエッジリソースにもたらす。サーバレスマイクロサービス（例えば、符号９２６）が、それらのＲＥＳＴｆｕｌ ＡＰＩを呈示する限り、マイクロサービスをクロスドメインで利用することができる。

一方、該ＩＴ／ＤｅｖＯｐｓは、中央クラウド内で管理するための、より少ない数のマイクロサービスを有し、このことは、複雑性および運用コストを低減するのを補助する。マイクロサービスが、必要な該アプリケーションに近接して（例えば、該クライアント装置９０２上に）存在する場合、最小限の水平拡張性が、または、ホスティングコストなしも実現される。また、該エッジにおけるリソースは、（異なる制約にも関わらず）該中央クラウド上の該リソースと同じように思われるため、異なるインフラストラクチャナレッジの必要がないので、該複雑性も低減される。

さらに、該フロントエンドアプリケーション開発者は、バックエンド開発メソドロジーに従うことができ、および該フロントエンドアプリケーションの該複雑性を、図９に示すように、サーバレスマイクロサービスおよびサイドカーパターンに分解することができる。該エッジノード有効化モジュール（例えば、符号４２６、５０８、９２２）を用いてアプリケーションを開発することは、該開発者が、アプリケーションが有効な場所を判断し、およびノードから成るクラスター内のどこで、すなわち、中央クラウド上で、ローカルデバイス上で、または、該クラスター内の別のデバイスで作動する必要があるマイクロサービスを判断するための該柔軟性を与える。その結果として、該開発者は、通常はモノリシックブロックとして書かれているクライアントアプリケーションをマイクロサービスに分解し、およびバックエンド開発において共通するマイクロサービスアーキテクチャに関する該便益のすべて、すなわち、スケーラビリティ、柔軟性、技術の選択、他のモジュールまたは機能への分離した影響、開発の容易さ等を享受するための、より多くの選択肢を有する。

図１０は、実施形態による、ローカルにおよびグローバルにホストされたマイクロサービスを活用するアプリケーションの場合の例示的なサーバレスマイクロサービス１０００を示す。図１および図２に示す該中央クラウドアプローチとは対照的に、該クライアントアプリケーションは、該中央クラウド内の該ＡＰＩゲートウェイにだけではなく、該同じデバイスにもローカルでリクエストを実行することができる。換言すると、該アプリケーションは、ローカル機能のためにローカルにホストされ、およびローカルにホストすることのできないそれらの機能のために該中央クラウドにグローバルにホストされたマイクロサービスを活用することができる。この概念は、クライアント間通信の実施例のための図１０に示すように、多数のデバイスおよびエッジノードにまで広げることができる。

図示されているように、該アーキテクチャ１０００は、サードパーティーアプリケーションまたはクライアントアプリケーション１００４および１０４０をそれぞれ作動させる二つのクライアント装置１００２および１０３８を含む。該クライアント装置１００２および１０３８は、それぞれ、エッジノード有効化モジュール１０２２および１０４２を含む。該クライアント装置の各々は、一つ以上のマイクロサービスをローカルにホストしている。例えば、該クライアント装置１００２はマイクロサービス１０２６、１０２８および１０３０をホストしている。同様に、該クライアント装置１０３８は、マイクロサービス１０４６、１０４８および１０５０をホストしている。該エッジノード有効化モジュール１０２２は、該中央１０１２にホストされているＡＰＩゲートウェイ１００８と通信するように構成されたＡＰＩゲートウェイ１０２４を含む。実施形態において、該エッジノード有効化モジュール１０２２は、該クライアントアプリケーション１００４からリクエスト１０２０を受取り、そして、該リクエストに応えるのに必要な一つ以上のマイクロサービスの種類を判断する。該判断された種類が、一つ以上のローカルにホストされたマイクロサービス（例えば、符号１０２６、１０２８、１０３０）に対応する場合には、該ＡＰＩゲートウェイ１０２４は、該サービスリクエスト１０３２を、インスタンス化されおよび開始される該適切なマイクロサービスに送る。実施形態において、該ローカルにホストされたマイクロサービスは、リモートデバイスからロードしてもよく、または、該クライアントアプリケーション１００４からの該要求に基づいてインスタンス化することができる。該マイクロサービス（例えば、符号１０２６）は、該リクエストに応えて、該ＡＰＩゲートウェイ１０２４を介してレスポンスを該クライアントアプリケーション１００４に返信する。

しかし、該リクエストに応えるのに必要なマイクロサービスの該判断された種類がグローバルなタイプである場合、または、グローバルにホストされたマイクロサービスに対応する場合には、該ＡＰＩゲートウェイ１０２４は、ｈｔｔｐ／ｈｔｔｐｓリクエスト１００６を該ＡＰＩゲートウェイ１００８に送信する。該ＡＰＩゲートウェイ１００８は、該リクエストに応えるために、該中央クラウド１０１２にグローバルにまたは中央にホストされている適切なマイクロサービス（例えば、符号１０１４、１０１６、１０１８）を開始する。該ＡＰＩゲートウェイ１００８は、ｈｔｔｐ／ｈｔｔｐｓレスポンス１０１０を該ＡＰＩゲートウェイ１０２４に送信する。

実施形態において、該エッジノード有効化モジュール１０２２は、該リクエスト１０２０に応えるのに必要な一つ以上のマイクロサービスの該種類が、別のクライアント装置（例えば、符号１０３８）にホストされているマイクロサービスに対応することを判断する。該エッジノード有効化モジュール１０２２は、該ＡＰＩゲートウェイ１０４２との直接通信を可能にする。また別の実施形態においては、該エッジノード有効化モジュール１０２２は、マイクロサービス１０３０、１０４６間の直接通信を可能にする。例えば、該マイクロサービス１０３０は、データリクエスト１０３４を該マイクロサービス１０４６に送信する。該マイクロサービス１０４６は、該データリクエストに応えて、レスポンス１０３６を該マイクロサービス１０３０に送信する。エッジデバイスがクライアントとしての役割のみを果たしている、図２に示す該中央クラウドアプローチとは対照的に、該クライアント間通信は、上述したように、エッジデバイス／クライアント装置間で直接（または、中央クラウド内のサーバを介して）起こすことができる。このことは、該開発者に、クラウドホスティングコスト、レイテンシ、帯域幅使用、データプライバシー、および典型的なバックエンド機能のための該マイクロサービスアーキテクチャに付随する他のすべての便益等の、開発のすべての側面を最適化する機会を与える。

その結果として、エッジノード有効化モジュールの開示されている実施形態は、該同じモデルおよびＡＰＩを用いることにより、オンデマンドＩＴリソースという概念を該エッジにまでシームレスに広げることによって、該開発者に便益をもたらす。それは、新たなクラスタースコープ、すなわち、ユーザアカウント、近接性およびネットワークを追加することにより、クラスタリングの該概念をさらに広げる。それは、サイドカーパターンを該エッジに提供して、該エッジにローカルに、グローバルにまたは中央クラウド内にかかわらず、他のマイクロサービスとの通信のために該ＡＰＩゲートウェイ、セキュリティおよびルーティングを扱うことによって、サービスメッシュという概念をさらに広げる。

実施形態において、エッジノード有効化モジュール（例えば、符号４２６、５０８、９２２、１０２２）を用いてアプリケーションを開発することは、より多くの選択肢、簡潔性および柔軟性を備えた該開発者を可能にする。ソリューション開発者は、該データが、ソリューションビジネスロジックに基づいてどこに存在するかに関する該判断を実行することができる。その結果、本願明細書に記載されていることは、現在使われていない、または十分に活用されていないエッジリソースを活用する、桁違いに多い処理能力、ストレージおよびメモリを備えたエッジクラウドを構築するための実用的なアプローチである。これは、桁違いに大きく、安く、速いクラウドファブリックを生み出すことができ、およびすべての消費者アプリケーションおよび企業アプリケーションに対して、より良好なデータプライバシーを提供することができる。

図１１は、クラウドコンピューティングインフラストラクチャまたはプラットフォームを提供する方法１１００の例示的な実施形態を示す。図１～図１０を参照すると、該エッジクラウドコンピューティングインフラストラクチャは、サーバコンピューティングデバイス（例えば、符号３１２）と情報をやり取りする一つ以上のエッジクラウドコンピューティングデバイス（例えば、符号３０２、３０４）を含む通信ネットワーク（例えば、エッジクラウドコンピューティングネットワーク３００）内に実装される。

該方法は、第一のエッジクラウドコンピューティングデバイス（例えば、符号４０４、５００）により、エッジノード有効化モジュール（例えば、符号４２２、５０８）をステップ１１０２のように実行することを含む。実施形態において、該エッジノード有効化モジュールは、該第一のエッジクラウドコンピューティングデバイスによってダウンロード可能なソフトウェアレベルのアプリケーションである。該方法は、該第一のエッジクラウドコンピューティングデバイスにより、他のエッジクラウドコンピューティングデバイス（例えば、符号３１０）に関連する該オペレーティングシステムおよびネットワークに関係なく、該他のエッジクラウドコンピューティングデバイスを、ステップ１１０４のように動的に見つけることをさらに含む。該方法は、該第一のエッジクラウドコンピューティングデバイスにより、該見つけた他のエッジクラウドコンピューティングデバイス（例えば、符号３１０）のリソース可用性、能力および機能を、ステップ１１０６のように呈示することをさらに含む。該方法は、該第一のエッジクラウドコンピューティングデバイスにより、該見つけた他のエッジクラウドコンピューティングデバイスから成る一つ以上のクラスター（例えば、符号７２２、７３２）を、ステップ１１０８のように構成して組織化することをさらに含む。また、該方法は、該第一のエッジクラウドコンピューティングデバイスにより、該一つ以上のクラスター内で、および該一つ以上のクラスターにわたって、ステップ１１１０のように通信することも含む。

実施形態において、該方法は、該エッジノード有効化モジュール（例えば、符号４２２）の実行後に、該第一のエッジクラウドコンピューティングデバイスにより、スーパーエッジクラウドコンピューティングデバイス（または、スーパーノード）を探すことをさらに含む。前述したように、該スーパーエッジクラウドコンピューティングデバイスは、ディスカバリーをグローバルに管理するように構成されている。該方法は、該探索中に、スーパーエッジクラウドコンピューティングデバイスを見つけられなかった場合に、該第一のエッジクラウドコンピューティングデバイスにより、それ自体を該スーパーエッジクラウドコンピューティングデバイスとして指定することをさらに含む。別の実施形態においては、該方法は、該第一のエッジクラウドコンピューティングデバイスにより、その存在のグローバルディスカバリーをやり取りすることと、該第一のエッジクラウドコンピューティングデバイスにより、該第一のエッジクラウドコンピューティングデバイスのスコープ内の一つ以上のエッジクラウドコンピューティングデバイスのリストを受信することとを含む。

また別の実施形態において、該方法は、該第一のエッジクラウドコンピューティングデバイスにより、後に該一つ以上のクラスター内に入る一つ以上のエッジクラウドコンピューティングデバイスからの登録のリクエストを受信することをさらに含む。また、該方法は、該第一のエッジクラウドコンピューティングデバイスにより、該第一のエッジクラウドコンピューティングデバイスの該スコープ内の一つ以上の他のエッジクラウドコンピューティングデバイスのリストを、該登録された一つ以上のエッジクラウドコンピューティングデバイスへ送信することも含む。

図１２は、クラウドコンピューティングインフラストラクチャまたはプラットフォームを提供する方法１２００の例示的な実施形態を示す。図１～図１１を参照すると、該エッジクラウドコンピューティングインフラストラクチャは、サーバコンピューティングデバイス（例えば、符号３１２）と情報をやり取りする一つ以上のエッジクラウドコンピューティングデバイス（例えば、符号３０２、３０４、５００、９０２、１００２）を含む通信ネットワーク（例えば、エッジクラウドコンピューティングネットワーク３００）内に実装される。

該方法は、第一のエッジクラウドコンピューティングデバイス（例えば、符号９０２、１００２）によって実行され、およびステップ１２０２のように、該第一のエッジクラウドコンピューティングデバイスで作動しているクライアントアプリケーション（例えば、符号９０４、１００４）からの要求に対応するマイクロサービスの種類を判断することを含む。該方法は、ステップ１２０４のように、該マイクロサービスの種類がグローバルであるか否かの判断をさらに含む。換言すると、該クライアントアプリケーションからの該要求には、グローバルにまたは中央にホストされたマイクロサービス（例えば、符号９１６、９１８、９２０、１０１４、１０１６）のみが応えることができる。ステップ１２０４での肯定的な判断のときは、該第一のエッジクラウドコンピューティングデバイスは、ステップ１２０６のように、ｈｔｔｐ／ｈｔｔｐｓリクエスト（例えば、符号９０６、１００６）を、該中央クラウド（符号９１２、１０１２）内の該ＡＰＩゲートウェイ（例えば、符号９０８、１００８）に送信する。該方法は、ステップ１２０８のように、該グローバルにホストされたマイクロサービス（例えば、符号９１６、１０１４）を開始することと、レスポンス（例えば、ｈｔｔｐ／ｈｔｔｐｓレスポンス９１０、１０１０）を該第一のエッジクラウドコンピューティングデバイスに返すこととをさらに含む。

ステップ１２０４において否定的な判断のときは、該方法は、ステップ１２１０のように、該クライアントアプリケーションからの該要求に対応する該マイクロサービスの種類がローカルであるか否かの判断をさらに含む。肯定の場合、該方法は、該ステップ１２１２のように、ローカルにホストされたマイクロサービス（例えば、符号１０２６、９２６）を開始することによって該要求を処理することをさらに含む。否定の場合には、該方法は、ステップ１２１４のように、該要求を、別の（第二の）エッジクラウドコンピューティングデバイス（例えば、符号１０３８）にホストされたマイクロサービスに直接送信することを含む。該方法は、該別の（第二の）エッジクラウドコンピューティングデバイス（符号１０３８）にホストされたマイクロサービス（例えば、符号１０４６）を開始することと、該要求にレスポンスを返すこととをさらに含む。

本願明細書に記載されているように、該エッジノード有効化モジュールは、該エッジクラウドコンピューティングデバイスまたはクライアント装置が、マイクロサービスをローカルで動的に生成するかまたはインスタンス化することを可能にする。また、該エッジノード有効化モジュールは、所定のクラスター内または複数のクラスターにわたって存在する該他のエッジノードを見つけて、該見つけたエッジノードにホストされている一つ以上のマイクロサービスを呈示する。このようにして、任意のエッジノードは、「サーバ」または「クライアント」としての機能を果たすことができ、およびクライアントアプリケーションからの所定の要求には、該サービスリクエストの該要求（タイプ）により、ローカルにまたはグローバルに、あるいは他のエッジノードによって応えることができる。

サーバコンピューティングデバイスの実施形態が開示されている。該サーバコンピューティングデバイスは、該サーバコンピューティングデバイスと情報をやり取りする一つ以上のエッジクラウドコンピューティングデバイスを含む通信ネットワーク内での動作のために構成されている。実施形態において、該サーバコンピューティングデバイスは、該一つ以上のエッジクラウドコンピューティングデバイスをサポートするための一つ以上のバックエンドサービスを提供するように構成されたバックエンドサービスモジュールを含む。該一つ以上のバックエンドサービスは、該一つ以上のエッジクラウドコンピューティングデバイスから成る一つ以上のクラスターを構成するためのナレッジを提供するように構成されたディスカバリーサービスを含み、この場合、該一つ以上のクラスターの各々は、少なくとも一つのスーパーエッジクラウドコンピューティングデバイスを備えている。該バックエンドサービスは、該ディスカバリーサービスからの要求の受信時に、該一つ以上のクラスターに対して、シグナリングエンドポイント（ＳＥＰ）およびベアラエンドポイント（ＢＥＰ）を動的に展開するように構成されたシグナリングサービスをさらに含む。該バックエンドサービスは、該一つ以上のクラスター内の第一のエッジクラウドコンピューティングデバイスにおいてトークンをマイクロサービスに伝えて、該一つ以上のクラスター内の第二のエッジクラウドコンピューティングデバイスにおいて別のマイクロサービスに要求を行うように構成されたサーバトークンサービスをさらに含む。

実施形態において、該一つ以上のバックエンドサービスは、該一つ以上のエッジクラウドコンピューティングデバイスの認証プロファイルを生成して維持するように構成されたアイデンティティサービスをさらに含む。実施形態において、該一つ以上のバックエンドサービスは、該一つ以上のクラスター内に備えられたすべてのマイクロサービスと、関連するクラスター情報とから成るリストを維持するように構成されたレジストリサービスをさらに含む。実施形態において、該レジストリサービスはさらに、該一つ以上のクラスターをコンフィギュレーション目的のために自己管理できるようにするための、該一つ以上のクラスターのクラスターナレッジを維持するように構成されている。実施形態において、該レジストリサービスはさらに、クラスターと、前記一つ以上のバックエンドサービスによって用いられる関連するコンフィギュレーションの詳細とから成るジオロケーションリストを提供するように構成されている。

実施形態において、一つ以上のクラスターを構成するための前記ナレッジは、前記一つ以上のクラスターと、該一つ以上のクラスターを構成する前記一つ以上のエッジクラウドコンピューティングデバイスに関連するコンピューティングリソースの詳細と、該一つ以上のクラスターを構成する該一つ以上のエッジクラウドコンピューティングデバイスのステータスおよび／またはロケーションと、該一つ以上のクラスターを構成する該一つ以上のエッジクラウドコンピューティングデバイス上で利用可能な一つ以上のマイクロサービスと、該一つ以上のクラスターを構成する各エッジクラウドコンピューティングデバイスに到達するためのエンドツーエンドネットワークトポロジーと、該一つ以上のクラスターの到達可能性とから成るプロファイルを含む。実施形態において、該ディスカバリーサービスはさらに、前記通信ネットワーク内の任意の利用可能なエッジクラウドコンピューティングデバイス上で前記一つ以上のマイクロサービスをリアルタイムで動的に展開するために、該通信ネットワーク内で利用可能なリソースに関連する情報を提供するように構成されている。実施形態において、該アイデンティティサービスは、各エッジクラウドコンピューティングデバイス内のエッジノード有効化モジュールと、該エッジノード有効化モジュールを用いるマイクロサービスと、該エッジノード有効化モジュールを用いるアプリケーション開発者と、該エッジノード有効化モジュールによってサポートされるアプリケーションのエンドユーザのうちの一つ以上に対するトークンを生成して維持するように構成されている。

エッジクラウドコンピューティングデバイスの実施形態が開示されている。実施形態において、該エッジクラウドコンピューティングデバイスは、一つ以上のエッジクラウドコンピューティングデバイスとの接続を確立するための、パラメータの第一のセットに基づいて、一つ以上の他のエッジクラウドコンピューティングデバイスを見つけるように構成されたエッジノード有効化モジュールを含む。該エッジノード有効化モジュールはさらに、一つ以上のエッジクラウドコンピューティングデバイス間で確立された該接続に関連する一つ以上のマイクロサービスを実行するためにマイクロサービスランタイム環境を提供するように構成されている。実施形態において、該エッジノード有効化モジュールは、該一つ以上のエッジクラウドコンピューティングデバイスに関連するオペレーティングシステムおよび／またはネットワークの種類に関係なく、該一つ以上のエッジクラウドコンピューティングデバイスの存在を見つけるように構成されている。該エッジノード有効化モジュールはさらに、該一つ以上のエッジクラウドコンピューティングデバイスに関連する能力および挙動を見つけるように、および該一つ以上のエッジクラウドコンピューティングデバイスによってサポートされる該一つ以上のマイクロサービスを見つけるように構成されている。実施形態において、該パラメータの第一のセットは、該一つ以上のエッジクラウドコンピューティングデバイスの各々に関連するユーザアカウントと、該一つ以上のエッジクラウドコンピューティングデバイスに関連するネットワークと、該一つ以上のエッジクラウドコンピューティングデバイスの近接性とを含む。

該エッジノード有効化モジュールはさらに、該一つ以上のエッジクラウドコンピューティングデバイスによって一つ以上のクラスターを動的に構成し、および該一つ以上のエッジクラウドコンピューティングデバイスと、該一つ以上のクラスターにわたって、マイクロサービスレベルで直接、または、他のエッジクラウドコンピューティングデバイスを介して通信するように構成されている。実施形態において、該エッジノード有効化モジュールはさらに、該見つかった一つ以上のエッジクラウドコンピューティングデバイスが、データ、サービスおよび／またはリソースを共有することを選択した場合に、該見つかった一つ以上のエッジクラウドコンピューティングデバイスに接続するように構成されている。該エッジノード有効化モジュールはさらに、該一つ以上のマイクロサービスのサービスを、共通の埋め込みウェブサーバを介して呈示するように構成されている。実施形態において、各マイクロサービスのための一つ以上のＡＰＩエンドポイントは、ＡＰＩゲートウェイを介して、一つのクラスター内の該一つ以上のエッジクラウドコンピューティングデバイスからアクセス可能である。該エッジノード有効化モジュールはさらに、該一つ以上のエッジクラウドコンピューティングデバイスに関連するそれぞれのコンピューティング環境に少なくとも部分的に基づいて、フレキシブルなコンテナ能力を提供するように構成されている。該それぞれのコンピューティング環境は、該一つ以上のマイクロサービスをダウンロードし、展開しおよび動作させるためのコンテナデーモンを作動させる。

実施形態において、該コンピューティング環境は、該一つ以上のエッジクラウドコンピューティングデバイスから成るアドホックのクラスターを管理するためのコンテナデーモンを作動させる。該エッジノード有効化モジュールは、中に埋め込まれたウェブサーバをさらに含む。該ウェブサーバは、該エッジクラウドコンピューティングデバイスに関連するオペレーティングシステムに基づく特定の言語を用いて、コンテナ管理ＡＰＩを提供するように構成されている。該エッジノード有効化モジュールは、一つ以上のソフトウェアライブラリと、対応するＡＰＩとをさらに含む。

サーバコンピューティングデバイスの実施形態が開示されている。該実施形態は、該サーバコンピューティングデバイスと情報をやり取りする一つ以上のエッジクラウドコンピューティングデバイスを含む通信ネットワークに関連する。実施形態において、該サーバコンピューティングデバイスは、該一つ以上のエッジクラウドコンピューティングデバイスをサポートするための一つ以上のサービスを提供するように構成されたバックエンドサービスモジュールを含む。該一つ以上のバックエンドサービスは、該一つ以上のエッジクラウドコンピューティングデバイスから成る一つ以上のクラスターを構成するためのナレッジを提供するように構成されたディスカバリーサービスを含む。該一つ以上のクラスターの各々は、少なくとも一つのスーパーエッジクラウドコンピューティングデバイス（または、スーパーノード）を含む。該一つ以上のバックエンドサービスは、該ディスカバリーサービスからの要求の受信時に、該一つ以上のクラスターに対して、シグナリングエンドポイント（ＳＥＰ）およびベアラエンドポイント（ＢＥＰ）を動的に展開するように構成されたシグナリングサービスをさらに含む。該一つ以上のバックエンドサービスは、該一つ以上のエッジクラウドコンピューティングデバイスの認証プロファイルを生成して維持するように構成されたアイデンティティサービスをさらに含む。

一旦、第一のクラスターが構成されると、該ディスカバリーサービスは、該第一のクラスターの一部ではない新たなエッジクラウドコンピューティングデバイスが、該第一のクラスターに対応する該スーパーエッジクラウドコンピューティングデバイスを登録することを可能にするように構成される。実施形態において、該ディスカバリーサービスはさらに、該スーパーエッジクラウドコンピューティングデバイスの各々が、それ自体を登録することを可能にするように構成されている。実施形態において、一つ以上のクラスターを構成するための前記ナレッジは、前記一つ以上のクラスターと、該一つ以上のクラスターを構成する前記一つ以上のエッジクラウドコンピューティングデバイスに関連するコンピューティングリソースの詳細と、該一つ以上のクラスターを構成する該一つ以上のエッジクラウドコンピューティングデバイスのステータスおよびロケーションと、該一つ以上のクラスターを構成する該一つ以上のエッジクラウドコンピューティングデバイス上で利用可能な一つ以上のサービスと、該一つ以上のクラスターを構成する各エッジクラウドコンピューティングデバイスに到達するためのエンドツーエンドネットワークトポロジーと、該一つ以上のクラスターの到達可能性とから成るプロファイルを含む。

別の実施形態において、前記ディスカバリーサービスはさらに、前記通信ネットワーク内の任意の利用可能なエッジクラウドコンピューティングデバイス上に前記一つ以上のサービスをリアルタイムで動的に展開するために、該通信ネットワーク内で利用可能なリソースに関連する情報を提供するように構成されている。また別の実施形態においては、該シグナリングサービスは、該一つ以上のクラスター内のコンピューティングリソースに対する要求に基づいて、該シグナリングエンドポイント（ＳＥＰ）および該ベアラエンドポイント（ＢＥＰ）を動的に展開するように構成されている。

さらに別の実施形態において、該シグナリングエンドポイント（ＳＥＰ）は、シグナリング通信に用いられ、該ベアラエンドポイント（ＢＥＰ）は、データ通信に用いられる。該シグナリングエンドポイント（ＳＥＰ）および該ベアラエンドポイント（ＢＥＰ）の該動的展開は、該一つ以上のクラスター内の該一つ以上のエッジクラウドコンピューティングデバイスのためのシグナリング帯域幅およびデータ帯域幅を増加させる。該シグナリングサービスはさらに、一つ以上のパラメータに基づいて、該シグナリングエンドポイント（ＳＥＰ）および該ベアラエンドポイント（ＢＥＰ）を動的に展開するように構成されている。該一つ以上のパラメータは、該一つ以上のサービスを稼動開始する時間と、該一つ以上のクラスター内での同時接続の数と、該一つ以上のクラスター内の該一つ以上のエッジクラウドコンピューティングデバイスに関連する一つ以上の通信プロトコルとを含む。

実施形態において、該シグナリングサービスはさらに、該一つ以上のクラスターの最も近い近接性内の利用可能なエッジクラウドコンピューティングデバイスに、該シグナリングエンドポイント（ＳＥＰ）および該ベアラエンドポイント（ＢＥＰ）を動的に展開するように構成されている。該アイデンティティサービスは、各エッジクラウドコンピューティングデバイス内のエッジノード有効化モジュールと、該エッジノード有効化モジュールを用いるマイクロサービスと、該エッジノード有効化モジュールを用いるアプリケーション開発者と、該エッジノード有効化モジュールによってサポートされるアプリケーションのエンドユーザのうちの一つ以上に対するトークンを生成して維持するように構成されている。また別の実施形態においては、該アイデンティティサービスは、該トークンホルダーのクレデンシャルおよび正当性を確認し、および該バックエンドサービスモジュールによって提供される該一つ以上のサービスへの該トークンホルダーのアクセスを承認するように構成されている。

エッジクラウドコンピューティングインフラストラクチャ（またはプラットフォーム）を提供する方法の実施形態が開示されている。該方法は、サーバコンピューティングデバイスまたは中央クラウドと情報をやり取りする一つ以上のエッジクラウドコンピューティングデバイスを含む通信ネットワーク内で実施される。該方法は、第一のエッジクラウドコンピューティングデバイスによって、エッジノード有効化モジュールを実行することを含む。該方法は、他のエッジクラウドコンピューティングデバイスに関連する該オペレーティングシステムおよびネットワークに関係なく、該第一のエッジクラウドコンピューティングデバイスによって、該他のエッジクラウドコンピューティングデバイスを動的に見つけることをさらに含む。該方法は、該第一のエッジクラウドコンピューティングデバイスによって、該見つかった他のエッジクラウドコンピューティングデバイスのリソース可用性、能力および機能を呈示することをさらに含む。該方法は、該第一のエッジクラウドコンピューティングデバイスによって、該見つかった他のエッジクラウドコンピューティングデバイスから成る一つ以上のクラスターを構成して組織化することをさらに含む。また、該方法は、該第一のエッジクラウドコンピューティングデバイスによって、該一つ以上のクラスター内で、および該一つ以上のクラスターにわたって通信することも含む。

実施形態において、該方法は、該エッジノード有効化モジュールの実行後に、該第一のエッジクラウドコンピューティングデバイスにより、スーパーエッジクラウドコンピューティングデバイス（該現在行われている説明においては、「スーパーノード」ともいう）を探すことを含む。該スーパーエッジクラウドコンピューティングデバイスは、ノードまたはエッジクラウドコンピューティングデバイスのグローバルディスカバリーを管理するように構成されている。

該探索中に、スーパーエッジクラウドコンピューティングデバイスを見つけられなかった場合、該方法は、該第一のエッジクラウドコンピューティングデバイスにより、それ自体を該スーパーエッジクラウドコンピューティングデバイスとして指定することをさらに含む。該方法は、該第一のエッジクラウドコンピューティングデバイスにより、その存在のグローバルディスカバリーをやり取りすることと、該第一のエッジクラウドコンピューティングデバイスにより、該第一のエッジクラウドコンピューティングデバイスのスコープ内の一つ以上のエッジクラウドコンピューティングデバイスのリストを受信することとをさらに含む。

該方法は、該第一のエッジクラウドコンピューティングデバイスによって、その後該一つ以上のクラスターに入って来る一つ以上のエッジクラウドコンピューティングデバイスからの登録の要求を受信することと、該第一のエッジクラウドコンピューティングデバイスによって、該第一のエッジクラウドコンピューティングデバイスの該スコープ内のおよび／または該登録された一つ以上のエッジクラウドコンピューティングデバイスの該スコープ内の一つ以上の他のエッジクラウドコンピューティングデバイスのリストを、該登録された一つ以上のエッジクラウドコンピューティングデバイスに送信することとをさらに含む。

本願においてクレームおよび明細書に使用されている「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」および「有する（ｈａｖｉｎｇ）」という用語は、明記されていない他の要素を含んでもよいオープングループを示すものと見なすべきである。「一つの（“ａ”または“ａｎ”）」という用語および言葉の単数形は、同じ言葉の複数形を含むように解釈すべきであり、その結果、該用語は、一つ以上の何かが記載されていることを意味する。「一つの（ｏｎｅ）」または「単一の（ｓｉｎｇｌｅ）」という用語は、一つおよび一つだけの何かが意図されていることを示すのに用いることができる。同様に、「二つの（ｔｗｏ）」等の他の特定の整数値は、特定の数のものが意図されている場合に用いることができる。「好ましくは（ｐｒｅｆｅｒａｂｌｙ）」、「好ましい（ｐｒｅｆｅｒｒｅｄ）」、「好む（ｐｒｅｆｅｒ）」、「必要に応じて（ｏｐｔｉｏｎａｌｌｙ）」、「してもよい（ｍａｙ）」という用語および同様の用語は、言及されている物品、状態またはステップが、該本発明の任意の（必要でない）形状構成であることを示すのに用いられる。

該本発明を、さまざまな具体的で好適な実施形態および技術に関して説明してきた。しかし、該本発明の趣旨および範囲内に留まりながら、多くの変形および変更を行えることを理解すべきである。本願明細書に具体的に記載されているもの以外の方法、デバイス、デバイス要素、材料、処理手順および技術を、過度な実験に頼ることなく、本願明細書に広範に開示されているように、該本発明の実施に適用することができることは、当業者には明らかであろう。本願明細書に記載されている方法、デバイス、デバイス要素、材料、処理手順および技術に関するすべての公知の機能的等価物は、この発明によって包含されることが意図されている。ある範囲が開示されているときは常に、すべての部分的範囲および個々の値は、包含されることが意図されている。この発明は、実施例として与えられ、および限定的ではない、該図面に示されているか、または、該明細書に例示されている任意のものを含めて、開示されている該実施形態によって限定されるべきではない。

該本発明を、限定された数の実施形態に関して説明してきたが、この開示の便益を有する当業者は、本願明細書に開示されているような該本発明の該範囲から逸脱しない他の実施形態を考え出すことができることは正しく認識するであろう。したがって、該本発明の該範囲は、添付クレームのみによって限定すべきである。

この出願全体におけるすべての参考文献、例えば、発行済みのまたは取得済みの特許または等価物、特許出願公報を含む特許文書、および非特許文献または他の基礎資料は、各参考文献が、該本出願における該開示に少なくとも部分的に矛盾しない範囲内で、参照により個別に組み込まれるかのように、参照により、それらの全体が本願明細書に組み込まれるものとする（例えば、部分的に矛盾している参考文献は、該参考文献の部分的に矛盾している部分を除いて、参照によって組み込まれる）。

Claims (37)

1. エッジクラウドコンピューティングデバイスで作動しているアプリケーションからの要求を受信するように、
   前記受信した要求に応えるのに必要な一つ以上のマイクロサービスの種類を判断するように、および
   前記判断された種類が、前記エッジクラウドコンピューティングデバイスにローカルにホストされた一つ以上のマイクロサービスに対応する場合に、前記要求を該エッジクラウドコンピューティングデバイスでローカルに処理するように、
   構成されたエッジノード有効化モジュールを備える、エッジクラウドコンピューティングデバイス。
2. 前記エッジノード有効化モジュールはさらに、前記ローカルにホストされた一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を提供するように構成される、請求項１に記載のエッジクラウドコンピューティングデバイス。
3. 前記エッジノード有効化モジュールはさらに、前記要求を前記ローカルにホストされた一つ以上のマイクロサービスに送信するためのローカルにホストされたＡＰＩゲートウェイを提供するように構成される、請求項１に記載のエッジクラウドコンピューティングデバイス。
4. 前記一つ以上のマイクロサービスは、前記要求に応えて、前記アプリケーションに応答を返信するように構成される、請求項１に記載のエッジクラウドコンピューティングデバイス。
5. 前記エッジノード有効化モジュールはさらに、前記受信した要求に応えるのに必要な、前記一つ以上のマイクロサービスの判断された種類が、中央クラウドコンピューティングデバイスにグローバルにホストされた一つ以上のマイクロサービスに対応する場合に、該受信した要求に対応するｈｔｔｐ／ｈｔｔｐｓリクエストを前記アプリケーションから、前記中央クラウドコンピューティングデバイスにホストされたＡＰＩゲートウェイに送信するように構成される、請求項１に記載のエッジクラウドコンピューティングデバイス。
6. 前記エッジノード有効化モジュールはさらに、前記中央クラウドコンピューティングデバイスにホストされた前記ＡＰＩゲートウェイから、前記ｈｔｔｐ／ｈｔｔｐｓリクエストに対するｈｔｔｐ／ｈｔｔｐｓレスポンスを受信するように構成され、および前記ｈｔｔｐ／ｈｔｔｐｓリクエストには、前記中央クラウドコンピューティングデバイスにグローバルにホストされた前記一つ以上のマイクロサービスが応える、請求項５に記載のエッジクラウドコンピューティングデバイス。
7. 前記エッジノード有効化モジュールはさらに、前記中央クラウドコンピューティングデバイスにホストされたＡＰＩゲートウェイに前記ｈｔｔｐ／ｈｔｔｐｓリクエストを送信するためのローカルにホストされたＡＰＩゲートウェイを提供するように構成される、請求項５に記載のエッジクラウドコンピューティングデバイス。
8. 前記エッジノード有効化モジュールはさらに、前記受信した要求に応えるのに必要な前記一つ以上のマイクロサービスの判断された種類が、別のエッジクラウドコンピューティングデバイスにホストされた一つ以上のマイクロサービスに対応する場合に、該別のエッジクラウドコンピューティングデバイスにホストされた一つ以上のマイクロサービスに前記要求を直接送信するように構成される、請求項１に記載のエッジクラウドコンピューティングデバイス。
9. 前記エッジノード有効化モジュールはさらに、サイドカーパターンを実施して、前記エッジクラウドコンピューティングデバイスにローカルにホストされた前記一つ以上のマイクロサービスおよび前記別のエッジクラウドコンピューティングデバイスにホストされた前記一つ以上のマイクロサービスに対応するサービスメッシュを形成するように構成される、請求項８に記載のエッジクラウドコンピューティングデバイス。
10. 前記エッジノード有効化モジュールはさらに、
    一つ以上の他のエッジクラウドコンピューティングデバイスとの接続を確立するためのパラメータの第一のセットに基づいて、該一つ以上の他のエッジクラウドコンピューティングデバイスを見つけるように、および
    一つ以上のエッジクラウドコンピューティングデバイス間で確立された前記接続に関連する前記ローカルにホストされた一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を提供するように、構成される、請求項１に記載のエッジクラウドコンピューティングデバイス。
11. 前記エッジノード有効化モジュールはさらに、前記一つ以上のエッジクラウドコンピューティングデバイスによってサポートされた一つ以上のマイクロサービスを見つけるように構成される、請求項１０に記載のエッジクラウドコンピューティングデバイス。
12. 前記パラメータの第一のセットは、前記一つ以上のエッジクラウドコンピューティングデバイスの各々に関連するユーザアカウントと、該一つ以上のエッジクラウドコンピューティングデバイスに関連するネットワークと、該一つ以上のエッジクラウドコンピューティングデバイスの近接性とを含む、請求項１０に記載のエッジクラウドコンピューティングデバイス。
13. 前記エッジノード有効化モジュールはさらに、
    前記一つ以上のエッジクラウドコンピューティングデバイスを有する一つ以上のクラスターを動的に構成するように、および
    前記一つ以上のエッジクラウドコンピューティングデバイスとマイクロサービスレベルで直接的に、または前記一つ以上のクラスターにわたって、他のエッジクラウドコンピューティングデバイスを介して情報をやり取りするように、構成される、請求項１０に記載のエッジクラウドコンピューティングデバイス。
14. 前記エッジノード有効化モジュールはさらに、前記ローカルにホストされた一つ以上のマイクロサービスのサービスを、共通の埋め込みウェブサーバを介して一つ以上のエッジクラウドコンピューティングデバイスに呈示するように構成される、請求項１に記載のエッジクラウドコンピューティングデバイス。
15. 前記エッジノード有効化モジュールは、中に埋め込まれたウェブサーバを備え、該ウェブサーバは、前記エッジクラウドコンピューティングデバイスに関連するオペレーティングシステムに基づく特定の言語を用いたコンテナ管理ＡＰＩを提供するように構成される、請求項１に記載のエッジクラウドコンピューティングデバイス。
16. サーバコンピューティングデバイスと通信する一つ以上のエッジクラウドコンピューティングデバイスを備える通信ネットワークでの作動のために構成されたサーバコンピューティングデバイスであって、該サーバコンピューティングデバイスが、
    前記一つ以上のエッジクラウドコンピューティングデバイスをサポートするための一つ以上のバックエンドサービスを提供するように構成されたバックエンドサービスモジュールを備え、該一つ以上のバックエンドサービスは、
    前記一つ以上のエッジクラウドコンピューティングデバイスから成る一つ以上のクラスターを構成するためのナレッジを提供するように構成されたディスカバリーサービスであって、該一つ以上のクラスターの各々が、少なくとも一つのスーパーエッジクラウドコンピューティングデバイスを備える、ディスカバリーサービスと、
    前記ディスカバリーサービスからの要求の受信時に、前記一つ以上のクラスターに対してシグナリングエンドポイント（ＳＥＰ）およびベアラエンドポイント（ＢＥＰ）を動的に展開するように構成されたシグナリングサービスと、
    前記一つ以上のクラスター内の第一のエッジクラウドコンピューティングデバイスにおいてトークンをマイクロサービスに伝えて、該一つ以上のクラスター内の第二のエッジクラウドコンピューティングデバイスにおいて別のマイクロサービスに要求を行うように構成されたサーバトークンサービスと、を備える、サーバコンピューティングデバイス。
17. 前記一つ以上のバックエンドサービスは、前記一つ以上のエッジクラウドコンピューティングデバイスの認証プロファイルを生成して維持するように構成されたアイデンティティサービスをさらに備える、請求項１６に記載のサーバコンピューティングデバイス。
18. 前記一つ以上のバックエンドサービスは、前記一つ以上のクラスター内で提供されるすべてのマイクロサービスと、関連するクラスター情報とから成るリストを維持するように構成されたレジストリサービスをさらに備える、請求項１６に記載のサーバコンピューティングデバイス。
19. 前記レジストリサービスはさらに、前記一つ以上のクラスターをコンフィギュレーション目的のために自己管理できるようにするための、該一つ以上のクラスターのクラスターナレッジを維持するように構成される、請求項１８に記載のサーバコンピューティングデバイス。
20. 前記レジストリサービスはさらに、クラスターと、前記一つ以上のバックエンドサービスによって用いられる関連するコンフィギュレーションの詳細とから成るジオロケーションリストを提供するように構成される、請求項１８に記載のサーバコンピューティングデバイス。
21. 一つ以上のクラスターを構成するための前記ナレッジは、
    前記一つ以上のクラスターと、該一つ以上のクラスターを構成する前記一つ以上のエッジクラウドコンピューティングデバイスに関連するコンピューティングリソースの詳細と、該一つ以上のクラスターを構成する該一つ以上のエッジクラウドコンピューティングデバイスのステータスおよび／またはロケーションと、該一つ以上のクラスターを構成する該一つ以上のエッジクラウドコンピューティングデバイス上で利用可能な一つ以上のマイクロサービスと、該一つ以上のクラスターを構成する各エッジクラウドコンピューティングデバイスに到達するためのエンドツーエンドネットワークトポロジーと、該一つ以上のクラスターの到達可能性とから成るプロファイルを備える、請求項１６に記載のサーバコンピューティングデバイス。
22. 前記ディスカバリーサービスはさらに、前記通信ネットワーク内の任意の利用可能なエッジクラウドコンピューティングデバイス上で前記一つ以上のマイクロサービスをリアルタイムで動的に展開するために、該通信ネットワーク内で利用可能なリソースに関連する情報を提供するように構成される、請求項１６に記載のサーバコンピューティングデバイス。
23. 前記アイデンティティサービスは、各エッジクラウドコンピューティングデバイス内のエッジノード有効化モジュールと、該エッジノード有効化モジュールを用いるマイクロサービスと、該エッジノード有効化モジュールを用いるアプリケーション開発者と、該エッジノード有効化モジュールによってサポートされるアプリケーションのエンドユーザのうちの一つ以上に対するトークンを生成して維持するように構成される、請求項１７に記載のサーバコンピューティングデバイス。
24. 少なくとも一つのサーバコンピューティングデバイスと通信する一つ以上のエッジクラウドコンピューティングデバイスを備える通信ネットワーク内にエッジクラウドコンピューティングインフラストラクチャを提供する方法であって、
    第一のエッジクラウドコンピューティングデバイスによって、該第一のエッジクラウドコンピューティングデバイス内で作動しているアプリケーションからの要求に対応する一つ以上のマイクロサービスの種類を判断することと、
    前記判断した種類が、前記第一のエッジクラウドコンピューティングデバイスにローカルにホストされた一つ以上のマイクロサービスに対応する場合に、該第一のエッジクラウドコンピューティングデバイス内で要求を、前記第一のエッジクラウドコンピューティングデバイスによってローカルに処理することと、を含む方法。
25. 前記ローカルにホストされた一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を、前記第一のエッジクラウドコンピューティングデバイスによって提供することをさらに含む、請求項２４に記載の方法。
26. 前記第一のエッジクラウドコンピューティングデバイスにより、前記ローカルにホストされた一つ以上のマイクロサービスに前記要求を送信するための、ローカルにホストされたＡＰＩゲートウェイを提供することをさらに含む、請求項２４に記載の方法。
27. 前記一つ以上のマイクロサービスの判断された種類が、中央クラウドコンピューティングデバイスにグローバルにホストされた一つ以上のマイクロサービスに対応する場合に、前記第一のエッジクラウドコンピューティングデバイスによって、前記アプリケーションからの要求に対応するｈｔｔｐ／ｈｔｔｐｓリクエストを、前記中央クラウドコンピューティングデバイスにホストされたＡＰＩゲートウェイに送信することをさらに含む、請求項２４に記載の方法。
28. 前記第一のエッジクラウドコンピューティングデバイスによって、前記ｈｔｔｐ／ｈｔｔｐｓリクエストに対するｈｔｔｐ／ｈｔｔｐｓレスポンスを、前記中央クラウドコンピューティングデバイスにホストされた前記ＡＰＩゲートウェイから受信することであって、該ｈｔｔｐ／ｈｔｔｐｓリクエストには、該中央クラウドコンピューティングデバイスにグローバルにホストされた前記一つ以上のマイクロサービスが応えることをさらに含む、請求項２７に記載の方法。
29. 前記中央クラウドコンピューティングデバイスにホストされたＡＰＩゲートウェイに前記ｈｔｔｐ／ｈｔｔｐｓリクエストを送信するための、ローカルにホストされたＡＰＩゲートウェイを、前記第一のエッジクラウドコンピューティングデバイスによって提供することをさらに含む、請求項２７に記載の方法。
30. 前記第一のエッジクラウドコンピューティングデバイスにより、前記アプリケーションからの前記要求の判断された種類が、第二のエッジクラウドコンピューティングデバイスに対するデータ要求に対応する場合に、前記ローカルにホストされた一つ以上のマイクロサービスからのデータ要求を、前記第二のエッジクラウドコンピューティングデバイスにホストされた一つ以上のマイクロサービスに直接送信することをさらに含む、請求項２４に記載の方法。
31. 前記第一のエッジクラウドコンピューティングデバイス内で作動している前記アプリケーションをサポートするためのサービスメッシュを構成するサイドカーパターンを、前記第一のエッジクラウドコンピューティングデバイスによって提供することをさらに含む、請求項２４に記載の方法。
32. 前記第一のエッジクラウドコンピューティングデバイスにより、前記ローカルにホストされた一つ以上のマイクロサービスのサービスを共通の埋め込みウェブサーバを介して一つ以上のエッジクラウドコンピューティングデバイスに呈示することをさらに含む、請求項２４に記載の方法。
33. 前記第一のエッジクラウドコンピューティングデバイスにより、該エッジクラウドコンピューティングデバイスに関連するオペレーティングシステムに基づく特定の言語を用いたコンテナ管理ＡＰＩを提供することをさらに含む、請求項２４に記載の方法。
34. 前記第一のエッジクラウドコンピューティングデバイスにより、一つ以上の他のエッジクラウドコンピューティングデバイスとの間の接続を確立するための該一つ以上の他のエッジクラウドコンピューティングデバイスを見つけることと、
    前記第一のエッジクラウドコンピューティングデバイスにより、一つ以上のエッジクラウドコンピューティングデバイス間に確立された接続に関連する前記ローカルにホストされた一つ以上のマイクロサービスを実行するためのマイクロサービスランタイム環境を提供することと、をさらに含む、請求項２４に記載の方法。
35. 前記第一のエッジクラウドコンピューティングデバイスにより、前記見つかった一つ以上の他のエッジクラウドコンピューティングデバイスにホストされた一つ以上のマイクロサービスを見つけることと、
    前記第一のエッジクラウドコンピューティングデバイスにより、前記ローカルにホストされた一つ以上のマイクロサービスと、前記一つ以上のエッジクラウドコンピューティングデバイス内の前記見つかった一つ以上のマイクロサービスとの間のダイレクトマイクロサービスレベルの接続を確立することと、をさらに含む、請求項３４に記載の方法。
36. 前記第一のエッジクラウドコンピューティングデバイスにより、前記アプリケーションからの要求に応えるのに必要な一つ以上のマイクロサービスをロードして実行することをさらに含む、請求項２４に記載の方法。
37. 前記アプリケーションからの要求に一旦、応えられると、前記ロードされた一つ以上のマイクロサービスを前記第一のエッジクラウドコンピューティングデバイスによって停止することをさらに含む、請求項３６に記載の方法。

Images