JP2022069420A - コンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品（エッジコンピューティング環境における障害管理） - Google Patents

Abstract

【課題】エッジコンピューティング環境における障害を動的に管理する。【解決手段】エッジコンピューティング環境における障害を動的に管理するためのコンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品が提供される。方法によれば、エッジ装置上で実行されるタスクをスケジュールするのに用いられる定義されたプロセスに従って、タスクの実行要求を第１のエッジ装置に送信することができる。第１のエッジ装置がタスクの実行に失敗した場合に、定義されたプロセスを一時中断することができる。そして、タスクの実行要求を第２のエッジ装置に送信することができる。第１のエッジ装置または第２のエッジ装置のいずれかからのタスク結果であって最初に受信したタスク結果を、タスクのタスク結果とすることができる。そして、定義されたプロセスの残りの部分を続行することができる。【選択図】図９

Description

本開示は、コンピュータ技術全般に関し、より具体的には、エッジコンピューティング環境における障害（failure）を動的に管理するための方法、システムおよびコンピュータプログラム製品に関する。

クラウドコンピューティングやインターネットオブシングス（ＩｏＴ：Internet of Things）技術の発展に伴い、より強力な計算能力を実現するための新たな方向性として、エッジコンピューティングが注目されつつある。ＩｏＴの分野において「エッジ（edge）」とは、例えば、産業機械、産業用コントローラ、産業用センサ、モバイル装置などのデータの発生源（sources of data）に近いところに存在するコンピューティングインフラストラクチャを指す。データの発生源である機械／装置を、エッジ装置と呼ぶ場合がある。エッジ装置は通常、クラウドで利用可能な集中型のコンピューティングリソースから離れた場所に存在する。エッジコンピューティングにおいて、情報技術（ＩＴ）管理者は、一部のアプリケーション、データ処理、およびモデルを中央のクラウドデータセンタからエッジ装置に近いエッジ側に移動させることで、クラウドデータセンタへのデータトラフィック量を削減することができる。

本開示は、エッジコンピューティング環境においてエッジ装置に発生する障害を動的に管理するための方法、システムおよびコンピュータプログラム製品を提供することを目的とする。

本開示の一の実施形態によれば、エッジコンピューティング環境における障害を動的に管理するためのコンピュータ実装方法が提供される。このコンピュータ実装方法によれば、エッジ装置上で実行されるタスクをスケジュールするのに用いられる定義されたプロセスに従って、タスクの実行要求を第１のエッジ装置に送信することができる。第１のエッジ装置がタスクの実行に失敗した場合に、定義されたプロセスは一時中断される。そして、タスクの実行要求が第２のエッジ装置に送信される。第１のエッジ装置または第２のエッジ装置のいずれかからのタスク結果であって最初に受信したタスク結果を、タスクのタスク結果とすることができる。方法はさらに、定義されたプロセスの残りの部分を続行することを含む。

本開示の他の実施形態によれば、エッジコンピューティング環境における障害を動的に管理するためのコンピュータシステムが提供される。このコンピュータシステムは、１つまたは複数のプロセッサと、１つまたは複数のプロセッサに接続されたコンピュータ可読メモリとを含む。コンピュータ可読メモリは、１つまたは複数のプロセッサによって実行されることで上記の方法における動作を実行する命令を含む。

本開示のさらに他の実施形態によれば、エッジコンピューティング環境における障害を動的に管理するためのコンピュータプログラム製品が提供される。このコンピュータプログラム製品は、プログラム命令が実装されたコンピュータ可読記憶媒体を含む。プログラム命令はプロセッサによって実行可能であり、プロセッサに上記の方法における動作を実行させる。

以下、本開示の上記および他の目的、特徴ならびに効果をより明らかにするため、添付図面を参照して、本開示のいくつかの実施形態についてより詳細に説明する。本開示の実施形態における類似の要素については、基本的に同一の符号を用いることとする。

図１は、本開示の実施形態による、コンピュータシステム／サーバの例を示す概略図である。 図２は、本開示の実施形態による、クラウドコンピューティング環境を示す図である。 図３は、本開示の実施形態による、抽象化モデルレイヤを示す図である。 図４は、本開示のいくつかの実施形態による、エッジコンピューティング環境の一例を示す図である。 図５は、本開示のいくつかの実施形態による、エッジコンピューティング環境の一例を示す図である。 図６は、本開示のいくつかの実施形態による、障害管理システムの例を示す図である。 図７Ａは、本開示のいくつかの実施形態による、障害管理プロセスのシナリオの例を示す図である。 図７Ｂは、本開示のいくつかの実施形態による、障害管理プロセスのシナリオの他の例を示す図である。 図７Ｃは、本開示のいくつかの実施形態による、障害管理プロセスのシナリオのさらに他の例を示す図である。 図８は、本開示のいくつかの実施形態による、エッジコンピューティング環境においてタスクを動的に管理するための一例としての方法を示すフローチャートである。 図９は、本開示のいくつかの実施形態による、エッジコンピューティング環境においてタスクを動的に管理するための他の例としての方法を示すフローチャートである。

以下、添付図面を参照して、本開示のいくつかの実施形態についてより詳細に説明する。添付図面は、本開示のいくつかの実施形態を図示したものである。ただし、本開示は種々の態様で実施することができるため、ここに開示する実施形態に限定されるものと解釈すべきではない。

本開示はクラウドコンピューティングに関する詳細な説明を含むが、本明細書に記載した教示の実装形態はクラウドコンピューティング環境に限定されない。むしろ、本発明の実施形態は、現在公知のまたは将来開発される他の任意の種類のコンピュータ環境と共に実施することができる。

クラウドコンピューティングは、設定可能なコンピューティングリソースの共有プール（例えばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、記憶装置、アプリケーション、仮想マシンおよびサービス）へ、簡便かつオンデマンドのネットワークアクセスを可能にするためのサービス提供のモデルであり、最小限の管理労力または最小限のサービスプロバイダとのやり取りによって速やかに準備（provision）およびリリースできるものである。このクラウドモデルは、少なくとも５つの特性、少なくとも３つのサービスモデル、および少なくとも４つの実装モデルを含むことがある。

特性は以下の通りである。
・オンデマンド・セルフサービス：クラウドのコンシューマは、サービスプロバイダとの人的な対話を必要することなく、必要に応じて自動的に、サーバ時間やネットワークストレージなどのコンピューティング能力を一方的に準備することができる。
・ブロード・ネットワークアクセス：コンピューティング能力はネットワーク経由で利用可能であり、また、標準的なメカニズムを介してアクセスできる。それにより、異種のシンまたはシッククライアントプラットフォーム（例えば、携帯電話、ラップトップ、ＰＤＡ）による利用が促進される。
・リソースプーリング：プロバイダのコンピューティングリソースはプールされ、マルチテナントモデルを利用して複数のコンシューマに提供される。様々な物理リソースおよび仮想リソースが、需要に応じて動的に割り当ておよび再割り当てされる。一般にコンシューマは、提供されたリソースの正確な位置を管理または把握していないため、位置非依存（location independence）の感覚がある。ただしコンシューマは、より高い抽象レベル（例えば、国、州、データセンタ）では場所を特定可能な場合がある。
・迅速な柔軟性（elasticity）：コンピューティング能力は、迅速かつ柔軟に準備することができるため、場合によっては自動的に、直ちにスケールアウトし、また、速やかにリリースされて直ちにスケールインすることができる。コンシューマにとって、準備に利用可能なコンピューティング能力は無制限に見える場合が多く、任意の時間に任意の数量で購入することができる。
・測定されるサービス：クラウドシステムは、サービスの種類（例えば、ストレージ、処理、帯域幅、アクティブユーザアカウント）に適したある程度の抽象化レベルでの測定機能を活用して、リソースの使用を自動的に制御し最適化する。リソース使用量を監視、制御、および報告して、利用されるサービスのプロバイダおよびコンシューマの両方に透明性を提供することができる。

サービスモデルは以下の通りである。
・サービスとしてのソフトウェア（ＳａａＳ）：コンシューマに提供される機能は、クラウドインフラストラクチャ上で動作するプロバイダのアプリケーションを利用できることである。当該そのアプリケーションは、ウェブブラウザ（例えばウェブメール）などのシンクライアントインタフェースを介して、各種のクライアント装置からアクセスできる。コンシューマは、ネットワーク、サーバ、オペレーティングシステム、ストレージや、個別のアプリケーション機能さえも含めて、基礎となるクラウドインフラストラクチャの管理や制御は行わない。ただし、ユーザ固有の限られたアプリケーション構成の設定はその限りではない。
・サービスとしてのプラットフォーム（ＰａａＳ）：コンシューマに提供される機能は、プロバイダによってサポートされるプログラム言語およびツールを用いて、コンシューマが作成または取得したアプリケーションを、クラウドインフラストラクチャに展開（deploy）することである。コンシューマは、ネットワーク、サーバ、オペレーティングシステム、ストレージを含む、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、展開されたアプリケーションを制御でき、かつ場合によってはそのホスティング環境の構成も制御できる。
・サービスとしてのインフラストラクチャ（ＩａａＳ）：コンシューマに提供される機能は、オペレーティングシステムやアプリケーションを含む任意のソフトウェアをコンシューマが展開および実行可能な、プロセッサ、ストレージ、ネットワーク、および他の基本的なコンピューティングリソースを準備することである。コンシューマは、基礎となるクラウドインフラストラクチャの管理や制御は行わないが、オペレーティングシステム、ストレージ、および展開されたアプリケーションを制御でき、かつ場合によっては一部のネットワークコンポーネント（例えばホストファイアウォール）を部分的に制御できる。

展開モデルは以下の通りである。
・プライベートクラウド：このクラウドインフラストラクチャは、特定の組織専用で運用される。このクラウドインフラストラクチャは、当該組織またはサードパーティーによって管理することができ、オンプレミスまたはオフプレミスで存在することができる。
・コミュニティクラウド：このクラウドインフラストラクチャは、複数の組織によって共有され、共通の関心事（例えば、ミッション、セキュリティ要件、ポリシー、およびコンプライアンス）を持つ特定のコミュニティをサポートする。このクラウドインフラストラクチャは、当該組織または第三者によって管理することができ、オンプレミスまたはオフプレミスで存在することができる。
・パブリッククラウド：このクラウドインフラストラクチャは、不特定多数の人々や大規模な業界団体に提供され、クラウドサービスを販売する組織によって所有される。
・ハイブリッドクラウド：このクラウドインフラストラクチャは、２つ以上のクラウドモデル（プライベート、コミュニティまたはパブリック）を組み合わせたものとなる。それぞれのモデル固有の実体は保持するが、標準または個別の技術によってバインドされ、データとアプリケーションの可搬性（例えば、クラウド間の負荷分散のためのクラウドバースティング）を実現する。

クラウドコンピューティング環境は、ステートレス性（statelessness）、低結合性（low coupling）、モジュール性（modularity）および意味論的相互運用性（semantic interoperability）に重点を置いたサービス指向型環境である。クラウドコンピューティングの中核にあるのは、相互接続されたノードのネットワークを含むインフラストラクチャである。

図１は、コンピュータシステム／サーバの例を示す概略図である。いくつかの実施形態において、コンピュータシステム／サーバは、他の数多くの汎用または専用のコンピューティングシステム環境または構成と共に動作可能な、通信装置などの携帯型電子装置としてもよい。コンピュータシステム／サーバ１２と共に使用するのに適した周知のコンピューティングシステム、環境もしくは構成またはその組み合わせの一例としては、パーソナルコンピュータシステム、サーバコンピュータシステム、シンクライアント、シッククライアント、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家電製品、ネットワークＰＣ、ミニコンピュータシステム、メインフレームコンピュータシステム、上記のシステムまたはデバイスのいずれかを含む分散型クラウドコンピューティング環境などが挙げられる。

コンピュータシステム／サーバ１２のいくつかの実施形態について、コンピュータシステムによって実行されるプログラムモジュールなどの、コンピュータシステム実行可能命令との一般的な関連において説明する。一般に、プログラムモジュールは、特定のタスクを実行するかまたは特定のデータ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、ロジック、データ構造などを含むことができる。コンピュータシステム／サーバ１２は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散型クラウドコンピューティング環境で実施することができる。分散型クラウドコンピューティング環境において、プログラムモジュールは、メモリ記憶装置を含む、ローカルおよびリモート両方のコンピュータシステム記憶媒体に記憶することができる。

図１では、コンピュータシステム／サーバ１２を汎用コンピュータ装置として示している。コンピュータシステム／サーバ１２のコンポーネントの一例としては、１つ以上のプロセッサまたは処理ユニット１６、システムメモリ２８、およびシステムメモリ２８を含む種々のシステムコンポーネントをプロセッサ１６に接続するバス１８が挙げられる。

バス１８は、種々のバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート（ＡＧＰ）、およびプロセッサまたはローカルバスを含む複数種類のバス構造のうち１つ以上の任意のものを表すことができる。一例として、かかるアーキテクチャは、インダストリスタンダードアーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（ＶＥＳＡ）ローカルバス、およびペリフェラルコンポーネントインターコネクト（ＰＣＩ）バスを含む。

コンピュータシステム／サーバ１２は、種々のコンピュータシステム可読媒体を含むことができる。かかる媒体は、コンピュータシステム／サーバ１２によってアクセス可能な任意の利用可能な媒体でよく、揮発性媒体および不揮発性媒体の両方と、取り外し可能媒体および取り外し不能媒体の両方とを含むことができる。

システムメモリ２８は、ＲＡＭ３０もしくはキャッシュメモリ３２またはその両方など、揮発性メモリとしてのコンピュータシステム可読媒体を含むことができる。コンピュータシステム／サーバ１２はさらに、他の取り外し可能／取り外し不能コンピュータシステム可読媒体および揮発性／不揮発性コンピュータシステム可読媒体を含んでもよい。一例として、ストレージシステム３４は、取り外し不能な不揮発性磁気媒体（不図示。一般に「ハードドライブ」と呼ばれる）への読み書きのために設けることができる。また、図示は省略するが、取り外し可能な不揮発性磁気ディスク（例えば、フロッピーディスク）への読み書きのための磁気ディスクドライブ、および取り外し可能な不揮発性光学ディスク（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭや他の光学媒体など）への読み書きのための光学ディスクドライブを設けることができる。これらの例において、それぞれを、１つ以上のデータ媒体インタフェースによってバス１８に接続することができる。以下でさらに図示および説明するように、メモリ２８は、本開示の実施形態の機能を実行するように構成可能なプログラムモジュールのセット（例えば、少なくとも１つ）を有する少なくとも１つのプログラム製品を含むことができる。

一例として、プログラムモジュール４２のセット（少なくとも１つ）を有するプログラム／ユーティリティ４０は、オペレーティングシステム、１つ以上のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータと同様に、メモリ２８に記憶することができる。オペレーティングシステム、１つ以上のアプリケーションプログラム、他のプログラムモジュール、およびプログラムデータ、またはそれらのいくつかの組み合わせの各々は、ネットワーク環境またはそのコンポーネントの実装形態を含むことができる。プログラムモジュール４２は一般に、本開示の実施形態の機能もしくは方法またはその両方を実行する。

また、コンピュータシステム／サーバ１２は、キーボードやポインティングデバイスなどの１つ以上の外部装置１４、ディスプレイ２４、ユーザとコンピュータシステム／サーバ１２との対話を可能にする１つ以上の装置、もしくはコンピュータシステム／サーバ１２と１つ以上の他のコンピュータ装置との通信を可能にする１つ以上の装置（例えば、ネットワークカードやモデムなど）またはこれらの組み合わせと通信することができる。かかる通信は、入力／出力（Ｉ／Ｏ）インタフェース２２を介して行うことができる。さらに、コンピュータシステム／サーバ１２は、ネットワークアダプタ２０を介して１つ以上のネットワーク（ローカルエリアネットワーク（ＬＡＮ）、汎用広域ネットワーク（ＷＡＮ）、もしくはパブリックネットワーク（例えばインターネット）またはこれらの組み合わせなど）と通信することができる。図示するように、ネットワークアダプタ２０は、バス１８を介してコンピュータシステム／サーバ１２の他のコンポーネントと通信することができる。なお、図示は省略するが、他のハードウェアコンポーネントもしくはソフトウェアコンポーネントまたはその両方を、コンピュータシステム／サーバ１２と併用することができる。それらの一例としては、マイクロコード、デバイスドライバ、冗長化処理ユニット、外付けディスクドライブアレイ、ＲＡＩＤシステム、テープドライブ、データアーカイブストレージシステムなどがある。

図１に示すコンピュータシステム／サーバは、図２に示すクラウドコンピューティングノード１０などのクラウドコンピューティングノードであってもよい。また、図１に示すコンピュータシステム／サーバは、本開示のいくつかの実施形態例に従って、図４および図５に示すエッジコンピューティング環境例におけるハードウェアコンポーネントであってもよい。

図２に、本開示のいくつかの実施形態に係る例示的なクラウドコンピューティング環境５０を示す。図示するように、クラウドコンピューティング環境５０は１つ以上のクラウドコンピューティングノード１０を含む。これらに対して、クラウドコンシューマが使用するローカルコンピュータ装置（例えば、ＰＤＡもしくは携帯電話５４Ａ、デスクトップコンピュータ５４Ｂ、ラップトップコンピュータ５４Ｃ、もしくは自動車コンピュータシステム５４Ｎまたはこれらの組み合わせなど）は通信を行うことができる。ノード１０は互いに通信することができる。ノード１０は、例えば、上述のプライベート、コミュニティ、パブリックもしくはハイブリッドクラウドまたはこれらの組み合わせなど、１つ以上のネットワークにおいて、物理的または仮想的にグループ化（不図示）することができる。これにより、クラウドコンピューティング環境５０は、サービスとしてのインフラストラクチャ、プラットフォームもしくはソフトウェアまたはこれらの組み合わせを提供することができ、クラウドコンシューマはこれらについて、ローカルコンピュータ装置上にリソースを維持する必要がない。なお、図２に示すコンピュータ装置５４Ａ～Ｎの種類は例示に過ぎず、コンピューティングノード１０およびクラウドコンピューティング環境５０は、任意の種類のネットワークもしくはネットワークアドレス指定可能接続（例えば、ウェブブラウザの使用）またはその両方を介して、任意の種類の電子装置と通信可能であることを理解されたい。

次に、本開示のいくつかの実施形態に係る、クラウドコンピューティング環境５０（図２）によって提供される機能的抽象化レイヤのセットを図３に示す。なお、図３に示すコンポーネント、レイヤおよび機能は例示に過ぎず、本発明の実施形態はこれらに限定されないことをあらかじめ理解されたい。図示するように、以下のレイヤおよび対応する機能が提供される。

ハードウェアおよびソフトウェアレイヤ６０は、ハードウェアコンポーネントおよびソフトウェアコンポーネントを含むことができる。ハードウェアコンポーネントの例には、メインフレーム６１、縮小命令セットコンピュータ（ＲＩＳＣ）アーキテクチャベースのサーバ６２、サーバ６３、ブレードサーバ６４、記憶装置６５、ならびにネットワークおよびネットワークコンポーネント６６が含まれる。いくつかの実施形態において、ソフトウェアコンポーネントは、ネットワークアプリケーションサーバソフトウェア６７およびデータベースソフトウェア６８を含むことができる。

仮想化レイヤ７０は、抽象化レイヤを提供する。当該レイヤから、例えば、仮想サーバ７１、仮想ストレージ７２、仮想プライベートネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティングシステム７４、ならびに仮想クライアント７５などの仮想エンティティを提供することができる。

一例として、管理レイヤ８０は以下の機能を提供することができる。リソース準備８１は、クラウドコンピューティング環境内でタスクを実行するために利用されるコンピューティングリソースおよび他のリソースの動的な調達を可能にする。計量および価格設定８２は、クラウドコンピューティング環境内でリソースが利用される際のコスト追跡、およびこれらのリソースの消費に対する請求またはインボイス送付を可能にする。一例として、これらのリソースはアプリケーションソフトウェアのライセンスを含むことができる。セキュリティは、データおよび他のリソースに対する保護のみならず、クラウドコンシューマおよびタスクの識別確認を可能にする。ユーザポータル８３は、コンシューマおよびシステム管理者にクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、要求されたサービスレベルが満たされるように、クラウドコンピューティングリソースの割り当ておよび管理を可能にする。サービス品質保証（ＳＬＡ）の計画および履行８５は、ＳＬＡに従って将来必要になると予想されるクラウドコンピューティングリソースの事前手配および調達を可能にする。

ワークロードレイヤ９０は、クラウドコンピューティング環境の利用が可能な機能の例を提供する。このレイヤから提供可能なワークロードおよび機能の例には、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想教室教育の配信９３、データ分析処理９４、取引処理９５、ならびに、エッジコントローラ９６が含まれる。

なお、図３に示す機能的抽象化レイヤは例示に過ぎない。必要に応じて、１つ以上のレイヤを追加してもよいし、図３に示す１つ以上のレイヤを統合したり削除したりしてもよい。さらに、図３の各レイヤにおいて、一部のコンポーネントを統合したり削除したりしてもよいし、１つ以上のコンポーネントを追加してもよい。

（コンピューティング環境の例）
上述したように、クラウドコンピューティングやＩｏＴ技術の発展に伴い、より強力な計算能力を実現するための新たな方向性として、エッジコンピューティングが注目されつつある。エッジコンピューティングは、インダストリアルＩｏＴ（ＩＩＯＴ：Industrial Internet of Things）における重要性を急速に高めており、デジタルトランスフォーメーション（digital transformation）の加速に貢献している。このトレンドの代表例として、インテリジェントマニュファクチャリング（intelligent manufacture）が挙げられる。一般的にエッジコンピューティングは、データの発生源として機能する産業機械などの「物」に実際に取り付け可能な装置や技術に着目することができる。エッジコンピューティングにより、データの発生源においてデータ分析や収集を行うことが可能になる。

いくつかの用途および実施形態において、エッジコンピューティングは、クラウドコンピューティングシステムに対する最適化技術として機能することができ、クラウドコンピューティングと協働することができる。エッジコンピューティングがメリットをもたらすシナリオとして、低レイテンシ（latency）を必要とする状況や、帯域幅に制約がある状況が挙げられる。また、インターネット接続やセルラー接続が不安定（spotty）な場合にも、エッジコンピューティングが重要となり得る。一方、クラウドコンピューティングは、機械から送られる膨大なデータ量を効率的に管理するために大きな計算能力（computing power）が必要な場合に、より優位となることが多い。しかし、多くの産業活動にとって、今日の高度かつ多岐にわたる大量のデータを最大限活用するためには、クラウドコンピューティングとエッジコンピューティングの両方が望ましいと言える。産業界やサーバプロバイダはこの両者を組み合わせることにより、エッジ装置からのデータをエッジにおいて、クラウドにおいて、またはこの２つの組み合わせにおいて柔軟に管理および処理し、最適な運用を実現することができる。

図４は、いくつかの実施形態に係るエッジコンピューティング環境の一例を示す図である。この例のエッジコンピューティング環境は、クラウドレイヤとエッジシステムレイヤの両方で動作するコンポーネントもしくはモジュールまたはその両方を含むことができる。この例のエッジコンピューティング環境では、データセンタまたはクラウドは、一般的なクラウドコンピューティング環境のようにコンピューティングノード／サーバと接続されているのではなく、エッジシステムおよびエッジ装置と接続することができる。

図４に示すように、この例のエッジコンピューティング環境は、クラウドレイヤ４１０のデータセンタ、エッジシステムレイヤ４２０、およびエッジ装置レイヤ４３０を含むことができる。この例のエッジコンピューティング環境における各レイヤのハードウェアコンポーネントは、図１に示すコンピュータシステム／サーバ１２であってもよい。図１に示すコンピュータシステム／サーバ１２は、この例のエッジコンピューティング環境におけるいずれかの機能として実装される、もしくはいずれかの機能を実行する、またはその両方とすることができる。この例のエッジコンピューティング環境におけるすべてのコンポーネントもしくはモジュールまたはその両方は、通信ネットワークを介して直接的または間接的に接続することができる。図４のネットワークは、ＷＡＮ、ＬＡＮ、電気通信ネットワーク、無線ネットワーク、公衆交換ネットワークもしくは衛星ネットワークまたはこれらの組み合わせなど、種々のタイプの通信ネットワークを含むことができる。また、通信ネットワークは、有線、無線通信リンク、または光ファイバケーブルなどの接続部（connections）を含むことができる。

図示のエッジコンピューティング環境全体のレイヤとモジュール、およびエッジ装置の数は、あくまでも例示である。いくつかのエッジコンピューティング環境の実施形態において、１つ以上の他のレイヤおよびモジュールが存在してもよく、またエッジ装置の数や配置態様が異なっていてもよい。

クラウドレイヤ４１０のデータセンタは、図２および図３を参照して上述した既存のクラウドコンピューティング環境５０の一部でもよい。実際には、製造またはサービスにおける実際の要件および条件に応じて、クラウドコンピューティングセンタは、所望の計算能力の一部（例えば、モデルおよびアプリケーションの一部）をエッジシステム４２０に配置してエッジ装置４３０の管理を実行してもよい。

図４に示すように、クラウドレイヤ４１０のデータセンタ内のモジュールは例えば、ストアシステム４１１、ＡＰＩサーバ４１２、およびエッジコントローラ９６を含むことができる。ストアシステム４１１は、ＡＰＩサーバ４１２が必要とするメタデータを格納することができる。例えば、ストアシステム４１１は、一貫性のある（consistent）分散キーバリューストア（distributed key-value store）とすることができる。ストアシステム４１１に格納されたデータは、分散システムまたは機械によってアクセスすることができる。ＡＰＩサーバ４１２は、ＡＰＩ操作の処理に用いてもよく、ユーザによって呼び出されてもよい。クラウドレイヤ４１０のコンポーネントは、メッセージ配信（message delivery）をＡＰＩサーバ４１２に依存してもよい。エッジコントローラ９６は、中央管理（central management）を実行するために、クラウドレイヤ４１０のデータセンタとエッジシステムレイヤ４２０との間の通信に用いることができる。

図４の実施形態において、エッジシステムレイヤ４２０のモジュールは例えば、ストアモジュール４２１、同期サービスモジュール４２２、エッジエージェントモジュール４２３、およびイベントモジュール４２４を含むことができる。ストアモジュール４２１は、エッジシステム４２０およびエッジ装置４３０のためのメタデータを格納することができる。同期サービスモジュール４２２は、エッジシステム４２０の中央データ処理モジュールとすることができ、クラウド４１０とエッジシステム４２０間でのモデルおよびデータの同期に用いることができる。エッジエージェントモジュール４２３およびイベントモジュール４２４は、エッジ装置４３０上で実行されるタスクの管理モジュールとすることができる。エッジエージェント４２３は、タスクの実行要求のためのプロセスを定義することができる。定義されたプロセスは、タスクと、当該タスクを実行するように適合（adapted）された各エッジ装置との間のマッピング関係（mapping relationship）を示すことができる。また、定義されたプロセスは、対応するエッジ装置上で実行されるタスクをスケジュールするのに用いることができる。実行されるタスクは、製造ミッションを達成することであってもよいし、サービス機能を実行することであってもよい。イベントモジュール４２４は、レシーバモジュール４２４１およびディスパッチャ（dispatcher）モジュール４２４２をさらに含むことができる。レシーバモジュール４２４１は、エッジ装置からのタスクの実行結果（running result）の受信に用いることができる。ディスパッチャモジュール４２４２は、定義されたプロセスに従って、次のタスクを対応するエッジ装置に割り当てるために、エッジエージェント４２３を呼び出すことができる。なお、図４に示すエッジシステム４２０の実施形態は実装環境の例示に過ぎず、これとは異なる実施形態を実装可能な環境に対していかなる制限を行うものでもよい。図示の環境に対して多くの変更が可能である。

エッジ装置は、企業やサービスプロバイダのコアネットワークへのエントリーポイントとすることができる。エッジシステムは、エッジ装置のデータを処理することができ、処理済みのデータまたは中央処理に適したデータを、ネットワーク上でクラウドのデータセンタに送信することができる。このようにして、未処理のデータをネットワーク上で大量に送信することを回避すると共に、中央処理の時間を節約することができる。図４に示すように、エッジ装置レイヤ４３０は例えば、デバイスＡ、Ｂ、Ｃ、Ｄ、およびＥなどの複数のエッジ装置を含むことができる。一方、本実施形態のエッジ装置は例えば、コンテナおよびプロキシモジュールを含むことができる。コンテナは、サービスグリッド、またはタスクの要求を実行するモジュールとすることができる。プロキシモジュールは、タスクの管理および制御に用いることができる。

図４に示すこの例のエッジコンピューティング環境は、サーバレスコンピューティング環境（serverless computing environment）またはプラットフォームとすることができ、その一例はサービスとしての機能（ＦａａＳ）である。サーバレスコンピューティング環境は、イベントによって発生（trigger）させてもよい。エッジコンピューティング環境において、製造ミッションやサービス機能を実行または実現することができる。製造ミッションを達成するため、またはサービス機能を実行するために、エッジ装置に対して種々のタスクの実行を要求することができる。そして、各エッジ装置は対応するタスクを実行することができる。このように、製造ミッションまたはサービス機能を実現するプロセスは、対応するエッジ装置上で一連のタスクを実行するプロセスとすることができる。

上述したように、エッジエージェントは、タスクを実行するためのプロセスを定義することができる。エッジエージェントは、タスクの実行要求を受信すると、どのエッジ装置が当該タスクの実行に適合するかを動的に決定することができる。例えば、適合するエッジ装置は、各エッジ装置の属性およびタスクの要件に基づいて決定することができる。各タスクは、対応するエッジ装置に割り当てることができる。エッジエージェントは、定義されたプロセスに従って、対応するエッジ装置上で実行されるタスクをスケジュールすることができる。また、適合するエッジデバイスは、履歴データや慣例などに基づいて決定するなど、他の適切な方法で決定してもよい。決定の方法によって本開示の範囲が不当に限定されるものではない。

次に、図４を参照して、例えば４つのタスク（タスク１、タスク２、タスク３、およびタスク４）があり、これらのタスクが、本明細書における定義されたプロセスに従って、それぞれエッジ装置Ａ、Ｂ、Ｃ、およびＤ上で順番に実行されるように適合されているとする。なお、これらのタスクは例示に過ぎず、説明と簡略化のために具体例として示すものであり、本開示に対する限定を何ら示唆するものではない。実際の製造やサービスの実施においては、実行されるタスクは膨大かつ複雑な場合がある。本開示の実施形態は、あらゆる種類のタスクに適用することができる。

エッジエージェント４２３は、上述した例のタスクの実行要求を受信し、プロセスを定義すると、線４３１で示すように、タスク１の実行要求をエッジ装置Ａに送信することができる。そして、エッジ装置Ａのコンテナがタスク１を実行し、エッジ装置Ａのプロキシが、線４３２で示すように、タスクの実行結果をレシーバモジュール４２４１に送信することができる。本明細書において、タスクの実行結果を、当該タスクのタスク結果と呼ぶ場合がある。各タスクは、対応するタスク結果を有することができる。次に、ディスパッチャモジュール４２４２がエッジエージェント４２３を呼び出し、線４３３で示すように、タスク２を実行する次の要求をエッジ装置Ｂに送信し、定義されたプロセスを続行することができる。エッジ装置Ｂは、同様にタスク２を実行し、線４３４で示すように、タスク結果をレシーバモジュール４２４１に送信することができる。次に、ディスパッチャモジュール４２４２がエッジエージェント４２３を呼び出し、線４３５で示すように、タスク３を実行する別の要求をエッジ装置Ｃに送信し、定義されたプロセスの実行を続行することができる。エッジ装置Ｃは、線４３６で示すように、タスク結果をレシーバモジュール４２４１に送信することができ、エッジエージェント４２３は、線４３７で示すように、タスク４を実行する次の要求をエッジ装置Ｄに送信することができる。線４３８で示すように、エッジ装置Ｄがタスク４のタスク結果をレシーバモジュール４２４１に送信すると、定義されたプロセスを完了することができる。この例のタスクを実行して製造ミッションを達成またはサービス機能を実行するための定義されたプロセスを、線４３１～４３８にて示すことができる。

この例において、エッジ装置Ａ、Ｂ、Ｃ、Ｄでのタスクの実行中に、エッジ装置Ａ、Ｂ、Ｃ、Ｄのいずれかが対象タスクの実行または完了に失敗した場合、定義されたプロセスの中断（interruption）が発生する可能性がある。実行プロセスを続行するために、エッジエージェント４２３は、未完了のタスクを別のエッジ装置に再割り当てして、障害が発生している装置を置き換える場合がある。例えば、装置Ｂが不安定な接続や他の不具合により故障し、エッジエージェント４２３が、線４３９で示すように装置Ｂからステータス情報を取得できなかった場合、エッジエージェント４２３は、装置Ｅなど別のエッジ装置を、装置Ｂの代替として決定することがある。そして、破線４３３’で示すように、タスク２をエッジ装置Ｅに再割り当てすることがある。装置Ｅによるタスク２の実行中に装置Ｂが復旧し、装置Ｂが装置Ｅよりも先にタスク結果を送信したとしても、装置Ｂのタスク結果はレシーバモジュール４２４１によって採用されない場合がある。そして、破線４３４’で示すように、レシーバモジュール４２４１は装置Ｅからのタスク２のタスク結果を依然として待っている場合があり、リソースの浪費につながる可能性がある。

この例において、定義されたプロセスに関係する各エッジ装置の可用性（availability）が、全体としての実行効率にとって重要である。すなわち、いずれか１つの装置の障害または不具合が、プロセス全体の実行に影響を及ぼす可能性がある。この既存のエッジコンピューティング環境の実施形態では、エッジ装置は、分散型または点在型（spotted）の装置の場合もあるし、工業団地内の機械やモバイル装置のように移動している状態の場合もある。さらに、エッジ装置のインターネット接続やセルラー接続は、不安定であったり途切れたりする場合がある。このような状況は、エッジ装置の障害発生につながりやすく、それにより、タスクの実行が失敗する可能性がある。これらの障害は、長時間続く場合もあれば、短時間しか続かず、すぐに復旧して前回の実行を続行できる場合もある。さらに、割り当てられたタスクを完了する前に、代替のエッジ装置も障害を起こす可能性がある。したがって、エッジ環境におけるエッジ装置の障害は、頻繁に発生しかつ複雑である可能性があり、エッジ装置の高可用性および高耐故障性（fault tolerance）を確保するために、エッジ環境において実行に失敗したタスクを管理することが望ましい。また、既存のエッジコンピューティング環境において、リソースを節約し、エッジサービスの高可用性を確保するために、実行に失敗したタスクを自動的に管理することが望ましい。

したがって、本開示の特徴および効果の１つは、いくつかの実施形態によって、エッジコンピューティング環境において失敗したタスクを自動的に管理する手法の一部として、上述した問題を解決できることである。

以下、図５～図８を参照して、本開示の実施形態を詳細に説明する。

図５は、本開示の実施形態による、エッジコンピューティング環境の一例を示す図である。図４のモジュールや要素に類似する、もしくは対応する、またはその両方に該当するモジュールや要素は、図５において同様の符号で示し、その説明は省略する。なお、図５は、実装環境の例示に過ぎず、これとは異なる実施形態を実装可能な環境に対していかなる限定を行うものでもよい。図示の環境に対して多くの変更が可能である。

図５に示すように、エッジエージェント４２３内にタスクラッパ（task wrapper）モジュール５２３１を構成することができる。また、レシーバモジュール４２４１内に、タスクチェッカ（task checker）モジュール５２４３およびタスクキャンセラ（task canceler）モジュール５２４４を構成することができる。図４に示す既存のコンピューティング環境と比較して、これら３つのモジュールは、実行に失敗したタスクを管理するように構成することができ、ソフトウェア、ハードウェア、ファームウェアもしくはこれらのいずれかの組み合わせまたはその両方で実装することができる。実行に失敗したタスクを管理するプロセスを、本明細書では障害管理プロセス（failure management process）と呼ぶ。なお、これらのモジュールは例示に過ぎない。本開示のいくつかの実施形態に係るエッジコンピューティング環境において、同様の機能または意図を達成するために、これより多い数のモジュールやこれより少ない数のモジュールが構成されていてもよい。また、モジュールは、その数だけでなく、異なる種類でもよく、他の態様で配置されていてもよい。

本開示の実施形態によれば、タスクラッパモジュール５２３１、タスクチェッカモジュール５２４３、およびタスクキャンセラモジュール５２４４は、障害の発生時にタスク実行プロセスを管理するように構成することができる。エッジエージェント４２３は、定義されたプロセス中にいずれかの装置からステータス情報を取得できなかった場合、定義されたプロセスを一時中断（suspend）し、タスクラッパモジュール５２３１を呼び出して、障害管理プロセスを開始することができる。同時に、障害に関係するメタデータ情報を取得し、ストアモジュール４２１に格納することができる。タスクラッパモジュール５２３１は、障害が発生した装置の代替となるエッジ装置を決定し、実行に失敗したタスクを当該代替装置に再割り当てすることができる。タスクチェッカモジュール５２４３は、受信したタスク結果を、当該タスクのタスク結果としてよいか否かを確認するように構成することができる。タスクキャンセラモジュール５２４４は、タスクが完了した場合、代替装置による実行をキャンセルするように構成することができる。タスクが完了すると、障害管理プロセスは終了し、ディスパッチャモジュール４２４２がエッジエージェントを呼び出し、定義されたプロセスに従って残りのタスクの実行を続行させることができる。

いくつかの実施形態および用途において、タスクの実行中に代替装置にも障害が発生した場合、タスクラッパモジュール５２３１は、実行に失敗したタスクをさらに別の装置に送信するなどしてもよい。タスクラッパモジュール５２３１は、タスクを実行するのにどの装置が適切であるかを決定することができるが、これについては本明細書では詳細な説明を省略する。実際の製造やサービスの実施は複雑な場合があり、代替装置にも障害が発生することがあり得るため、エッジコンピューティング環境においては、障害が発生した装置の頻繁な置き換えが必要な場合がある。説明を簡略化するために、本開示では代替装置にはそれ以上障害が発生しない状況のみを説明がするが、それによって本開示の範囲が不当に限定されるものではない。

（定義されたプロセスおよび障害管理プロセス）
本開示の実施形態によれば、タスクを実行するための定義されたプロセスとは、障害の発生を考慮することなく、エッジエージェントが決定した適合エッジ装置によってタスクを実行するプロセスを意味することができる。タスクを実行するための定義されたプロセスは、タスクの実行要求が受信されると、エッジエージェント４２３によって作成することができる。図示の例のタスクの場合、定義されたプロセスは順にタスク１、タスク２、タスク３、タスク４であり、図４の線４３１～４３８で示すように、それぞれエッジ装置Ａ、Ｂ、Ｃ、Ｄによって実行される。障害管理プロセスとは、タスクを実行するためのプロセス全体の中で、実行に失敗したタスクの管理に特化したサブプロセスを意味することができる。障害が発生しない場合には、定義されたプロセスに従ってタスクを実行することができる。しかし、障害発生時には、エッジエージェントは障害管理プロセスを呼び出して、対応する定義されたプロセスを置き換えることができる。障害管理プロセスは、図５に示すタスクラッパモジュール５２３１、タスクチェッカモジュール５２４３、およびタスクキャンセラモジュール５２４４によって実行することができ、これらを総称して「障害管理システム（failure management system）」と呼ぶ場合がある。

例示したタスクを実行するのに適した障害管理システムの実施形態例を、図６に示す。障害管理プロセスのいくつかの実施形態によれば、タスクチェッカモジュール５２４３は、装置Ｂの実行結果を考慮せずに単に装置Ｂを装置Ｅに置き換えるのではなく、装置Ｂおよび装置Ｅの両方からのタスク結果を確認することができる。本開示の実施形態によれば、最初に受信したタスク結果を、そのタスクのタスク結果とすることができる。以下、障害管理プロセスの具体的な実施方法について詳細に説明する。

例示したタスクについて、各タスクの実行中に、装置Ｂによって実行されるタスクが完了していないのに装置Ｂが利用できない（not available）ことをエッジエージェント４２３が発見した場合、エッジエージェント４２３は、定義されたプロセスを一時中断し、タスクラッパモジュール５２３１を呼び出して障害管理プロセスを開始することができる。タスクラッパモジュール５２３１は、直前の装置（すなわち装置Ｂ）の代替として別の装置（例えば、装置Ｅ）を決定し、図５の線５３３’で示すように、タスク２の実行要求を当該別の装置（例えば、装置Ｅ）に再割り当てすることができる。エッジエージェントは、タスクの実行要求を送信した後に、有効期間（ＴＴＬ：time to live）を設定してもよい。エッジ装置のプロキシは、ＴＴＬの間にエッジエージェントに応答し、「実行中」や「完了」などの自身のステータスを送信することが求められる。例えば、ＴＴＬの間に装置Ｂからステータス報告を受信できなかった場合、エッジエージェント４２３は、デバイスＢに障害が発生しているか、または利用できないと判定し、故障管理プロセスを開始してよい。なお、ステータス情報の取得は、任意の適切な方法で行うことができる。

エッジ装置Ｅはタスク２を実行し、線５３４’で示すように、タスク結果をレシーバモジュール４２４１に送信することができる。いくつかのエッジコンピューティング環境においては、装置の多くの障害が、接続が不安定であったり途切れたりすることが原因で発生する可能性がある。このような環境においては、装置Ｂが短時間で動作を再開し、線５３４で示すように、タスク結果をレシーバモジュール４２４１に送信する可能性がある。例示したタスクについては、次の３つのシナリオが考えられる。

１つ目の可能なシナリオを図７Ａに示す。このシナリオでは、装置Ｂは常に障害発生状態にあり、装置Ｅはタスク結果をレシーバモジュール４２４１に送信することができ、エッジシステムは、装置Ｅからのタスク結果をタスク２のタスク結果として用いることができる。

２つ目の可能なシナリオを図７Ｂに示す。このシナリオでは、装置Ｂが短時間で動作を再開し、タスク結果をレシーバモジュール４２４１に送信する。装置Ｅはまだタスク２を実行中であり、装置Ｂの方が先にタスク２のタスク結果をレシーバモジュール４２４１に送信することができる。そして、エッジシステムは、装置Ｂのタスク結果をタスク２のタスク結果として用いることができる。タスク２を実行中の装置Ｅは、キャンセルすることができる。このシナリオでは、リソースを節約することができる。

３つ目の可能なシナリオを図７Ｃに示す。このシナリオでは、装置Ｂが動作を再開し、タスク結果をレシーバモジュール４２４１に送信する。しかし、タスク２は完了済み、すなわち、装置Ｅが装置Ｂよりも先にタスク結果をレシーバモジュール４２４１に既に送信している。このシナリオの場合、エッジシステムは装置Ｂからのタスク結果を無視することができる。

（方法例）
図８は、本開示のいくつかの実施形態による、エッジコンピューティング環境においてタスクを動的に管理するための一例としての方法８００を示すフローチャートである。方法８００は、図５に示す環境において実施することができる。また、方法８００は、工程８０２～８１８を含むことができる。このうち、工程８０２および８１８は、定義されたプロセスに従った工程とすることができ、工程８０４～８１６は、図７Ａ～７Ｃに示した３つのシナリオに対応する障害管理プロセスの工程とすることができる。工程８０４～８１６は、図６に示す障害管理システムによって実行することができる。

図４および図５を参照して上述したように、工程８０２にて、エッジエージェント４２３はタスクの実行要求を受信すると、対応するエッジ装置上でタスクを実行するために、上述の定義されたプロセスを定義することができる。そして、エッジエージェント４２３は、定義されたプロセスに従って、対応する装置上で実行される各タスクをスケジュールすることができる。

工程８０４にて、装置Ｂによって実行されるタスク２が完了していないのに装置Ｂが利用できないことをエッジエージェント４２３が発見した場合、エッジエージェント４２３は、定義されたプロセスを一時中断し、タスクラッパモジュール５２３１を呼び出して障害管理プロセスを開始することができる。そして、タスクラッパモジュール５２３１は、装置Ｂの代替として、装置Ｅなどの別のエッジ装置にタスク２を送信することができる。

工程８０６にて、レシーバモジュール４２４１は、タスク結果を受信することができる。当該タスク結果は、装置Ｅからのタスク２のタスク結果の場合もあるし、装置Ｂが障害から復旧してタスク２の実行を続行している可能性があるため、装置Ｂからのタスク２のタスク結果の場合もある。

工程８０８にて、タスクチェッカモジュール５２４３は、タスク２が完了済みとしてマーク（mark）されているか否かを確認することができる。

タスク２が完了済みとしてマークされていない場合、工程８１０にて、タスクチェッカモジュール５２４３は、受信したタスク結果が、最初に受信したタスク結果であると判定することができる。そして、タスクチェッカモジュール５２４３は、受信したタスク結果をタスク２のタスク結果とし、タスク２を完了済みとしてマークすることができる。

工程８１２にて、タスクチェッカモジュール５２４３はさらに、ストアモジュール４２１内のメタデータ情報を用いて、受信したタスク結果が装置Ｂからのものであるか否かを確認することができる。メタデータ情報は、表１に示すようなものとすることができる。なお、表１に示すデータ構造はあくまでも例示であり、何らの限定も意図していない。ＸＭＬファイルやテキスト（．ｔｘｔ）ファイルなど、他のデータ構造も適用可能である。

タスク結果が装置Ｂからのものでない場合、方法８００は、工程８１８に直接進むことができる。この分岐は、図７Ａに示すシナリオに対応することができる。受信したタスク結果が装置Ｂからのものである場合、タスクチェッカモジュール５２４３は、変数「ｃａｎｃｅｌ＿ｏｔｈｅｒ＿ｄｅｖｉｃｅ」を真に設定することができる。変数「ｃａｎｃｅｌ＿ｏｔｈｅｒ＿ｄｅｖｉｃｅ」が真に設定されたことに応じて、タスクキャンセラモジュール５２４４は、工程８１４にて、装置Ｅにキャンセル要求を送信することができる。その後、方法８００は、工程８１８に進むことができる。この分岐は、図７Ｂに示すシナリオに対応する。タスク２が完了済みとしてマークされると、障害管理プロセスは終了し、ディスパッチャモジュール４２４２がエッジエージェントを呼び出して、定義されたプロセスの残りを続行させることができる。

タスク２が完了済みとしてマークされている場合、工程８１６にて、受信したタスク結果を無視することができる。装置Ｅによってタスク２が完了済みであり、装置Ｂが装置Ｅよりも後にタスク結果を送信していると判定することができる。この分岐は、図７Ｃに示すシナリオに対応する。

図９は、本開示のいくつかの実施形態による、エッジコンピューティング環境においてタスクを動的に管理するための他の例としての方法９００を示すフローチャートである。説明のために、図５を参照しながら方法９００について説明する。

工程９１０にて、エッジエージェント４２３は、定義されたプロセスに従って、タスクの実行要求を第１のエッジ装置に送信することができる。ここで、定義されたプロセスは、エッジ装置上で実行されるタスクをスケジュールするために用いることができる。第１のエッジ装置がタスクの実行に失敗した場合、工程９２０にて、エッジエージェント４２３は、定義されたプロセスを一時中断することができる。工程９３０にて、タスクラッパモジュール５２３１は、当該タスクの実行要求を第２のエッジ装置に送信することができる。工程９４０にて、タスクチェッカモジュール５２４３は、最初に受信したタスク結果を、当該タスクのタスク結果とすることができる。ここで、タスク結果は、第１のエッジ装置または第２のエッジ装置のいずれかからのものである。工程９５０にて、ディスパッチャモジュール４２４２はエッジエージェント４２３を呼び出して、定義されたプロセスの残りの部分を続行させることができる。

いくつかの実施形態では、工程９４０にて、タスクのタスク結果を受信した場合、タスクチェッカモジュール５２４３は、当該タスクが完了済みとしてマークされているか否かを確認してもよい。タスクが完了済みとしてマークされていない場合、タスクチェッカモジュール５２４３は、受信したタスク結果が、最初に受信したタスク結果であると判定し、当該タスクを完了済みとしてマークすることができる。タスクが完了済みとしてマークされている場合、タスクチェッカモジュール５２４３は、受信したタスク結果が、最初に受信したタスク結果ではないと判定し、受信したタスク結果を無視することができる。

いくつかの実施形態では、工程９４０にて、タスクチェッカモジュール５２４３は、受信したタスク結果が第１のエッジ装置からのものであるか否かを確認してもよい。受信したタスク結果が第１のエッジ装置からのものである場合、タスクチェッカモジュール５２４３は、第２のエッジ装置に対してタスクの実行を中止する命令を送信することができる。

いくつかの実施形態では、方法９００において、ストアシステム５１１が、タスクおよびエッジ装置のメタデータ情報を取得し、記憶してもよい。メタデータ情報は、タスクのＩＤ、第１のエッジ装置のＩＤ、および第２のエッジ装置のＩＤのうち少なくとも１つの識別子を含むことができる。

本開示の実施形態によるタスク管理プロセスは、図１のコンピュータシステム／サーバ１２によって実施してもよい。

本開示の実施態様は、任意の可能な技術詳細レベルで統合されたシステム、方法もしくはコンピュータプログラム製品またはそれらの組み合せとすることができる。コンピュータプログラム製品は、プロセッサに本開示の態様を実行させるためのコンピュータ可読プログラム命令を記憶したコンピュータ可読記憶媒体を含んでよい。

コンピュータ可読記憶媒体は、命令実行装置によって使用される命令を保持し、記憶することができる有形の装置とすることができる。コンピュータ可読記憶媒体は、一例として、電子記憶装置、磁気記憶装置、光学記憶装置、電磁記憶装置、半導体記憶装置またはこれらの適切な組み合わせであってよい。コンピュータ可読記憶媒体のより具体的な一例としては、ポータブルコンピュータディスケット、ハードディスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ（またはフラッシュメモリ）、ＳＲＡＭ、ＣＤ－ＲＯＭ、ＤＶＤ、メモリスティック、フロッピーディスク、パンチカードまたは溝内の隆起構造などに命令を記録した機械的に符号化された装置、およびこれらの適切な組み合せが挙げられる。本明細書で使用されるコンピュータ可読記憶装置は、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を介して伝播する電磁波（例えば、光ファイバケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号のような、一過性の信号それ自体を含むものとして解釈されるべきではない。

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピュータ装置／処理装置へダウンロードすることができる。あるいは、ネットワーク（例えばインターネット、ＬＡＮ、ＷＡＮもしくはワイヤレスネットワークまたはこれらの組み合わせ）を介して、外部コンピュータまたは外部記憶装置へダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータもしくはエッジサーバまたはこれらの組み合わせを備えることができる。各コンピュータ装置／処理装置内のネットワークアダプタカードまたはネットワークインタフェースは、ネットワークからコンピュータ可読プログラム命令を受信することができ、当該コンピュータ可読プログラム命令を、各々のコンピュータ装置／処理装置におけるコンピュータ可読記憶媒体に記憶するために転送することができる。

いくつかの実施形態における動作を実施するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用構成データ、または、スモールトークやＣ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語や類似のプログラミング言語などの手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで記述されたソースコードもしくはオブジェクトコードのいずれかを含むことができる。コンピュータ可読プログラム命令は、スタンドアロン型ソフトウェアパッケージとして完全にユーザのコンピュータ上で、または部分的にユーザのコンピュータ上で実行可能である。あるいは、部分的にユーザのコンピュータ上でかつ部分的にリモートコンピュータ上で、または、完全にリモートコンピュータもしくはサーバ上で実行可能である。後者の場合、リモートコンピュータは、ＬＡＮやＷＡＮを含む任意の種類のネットワークを介してユーザのコンピュータに接続してもよいし、外部コンピュータに（例えば、インターネットサービスプロバイダを使用してインターネットを介して）接続してもよい。いくつかの実施形態において、例えばプログラマブル論理回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブル論理アレイ（ＰＬＡ）を含む電子回路は、本開示の態様を実行する目的で当該電子回路をカスタマイズするために、コンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行することができる。

本開示の各態様は、本明細書において、本発明の実施形態に係る方法、装置（システム）、およびコンピュータプログラム製品のフローチャートもしくはブロック図またはその両方を参照して説明されている。フローチャートもしくはブロック図またはその両方における各ブロック、および、フローチャートもしくはブロック図またはその両方における複数のブロックの組み合わせは、コンピュータ可読プログラム命令によって実行することができる。

上記のコンピュータ可読プログラム命令は、機械を生産するために、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサに提供してよい。これにより、かかるコンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行できるこれらの命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行できる。上記のコンピュータ可読プログラム命令はさらに、コンピュータ、プログラマブルデータ処理装置もしくは他の装置またはこれらの組み合わせに対して特定の態様で機能するよう命令可能なコンピュータ可読記憶媒体に記憶してよい。これにより、命令が記憶された当該コンピュータ可読記憶媒体は、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作の態様を実行できる命令を含む製品を構成する。

また、コンピュータ可読プログラム命令を、コンピュータ、他のプログラマブル装置、または他の装置にロードし、一連の動作を当該コンピュータ、他のプログラマブル装置、または他の装置に実行させることにより、コンピュータ実行プロセスを生成してもよい。これにより、当該コンピュータ、他のプログラマブル装置、または他の装置上で実行される命令が、フローチャートもしくはブロック図またはその両方における１つ以上のブロックにて特定される機能／動作を実行する。

図面におけるフローチャートおよびブロック図は、本開示の種々の実施形態に係るシステム、方法およびコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示している。この点に関して、フローチャートまたはブロック図における各ブロックは、特定の論理機能を実行するための１つ以上の実行可能な命令を含む、命令のモジュール、セグメント、または部分を表すことができる。他の一部の実装形態において、ブロック内に示した機能は、各図に示す順序とは異なる順序で実行してもよい。例えば、連続して示される２つのブロックは、実際には、関係する機能に応じて、１つの工程として達成してもよいし、同時もしくは略同時に実行してもよいし、部分的もしくは全体的に時間的に重複した態様で実行してもよいし、または場合により逆順で実行してもよい。なお、ブロック図もしくはフローチャートまたはその両方における各ブロック、および、ブロック図もしくはフローチャートまたはその両方における複数のブロックの組み合わせは、特定の機能または動作を行う専用ハードウェアベースのシステムによって、または専用ハードウェアとコンピュータ命令との組み合わせによって実行することができる。

本開示の種々の実施形態を例示として説明してきたが、網羅的であることや、これらの実施形態に限定することを意図したものではない。当業者には明らかなように、記載した各実施形態の範囲および要旨から逸脱することなく、多くの変更および変形が可能である。本明細書で用いられる用語は、各実施形態の原理、実際の用途、または市場で確認される技術に対する技術的な改善を説明するために、または、当業者が本明細書に開示する各実施形態を理解できるように選択されたものである。

したがって、本明細書に記載の実施形態は、あらゆる点で例示的なものであり、本開示を限定するものと見なすべきではない。本開示の範囲を決定するにあたっては、添付の特許請求の範囲を参照されたい。

Claims (20)

1. コンピュータ実装方法であって、１つまたは複数のプロセッサによって、
   エッジ装置上で実行されるタスクをスケジュールするのに用いられる定義されたプロセスに従って、タスクの実行要求を第１のエッジ装置に送信することと、
   前記第１のエッジ装置が前記タスクの実行に失敗した場合に、前記定義されたプロセスを一時中断することと、
   前記タスクの実行要求を第２のエッジ装置に送信することと、
   前記第１のエッジ装置または前記第２のエッジ装置のいずれかからのタスク結果であって最初に受信したタスク結果を、前記タスクのタスク結果とすることと、
   前記定義されたプロセスの残りの部分を続行することと、
   を含む、方法。
2. 前記最初に受信したタスク結果を前記タスクのタスク結果とすることは、
   前記タスクのタスク結果を受信した場合に、当該タスクが完了済みとしてマークされているか否かを確認することと、
   前記タスクが完了済みとしてマークされていない場合に、前記受信したタスク結果を前記最初に受信したタスク結果であると判定することと、
   前記タスクを完了済みとしてマークすることと、を含む、
   請求項１に記載の方法。
3. 前記タスクが完了済みとしてマークされている場合に、前記受信したタスク結果を前記最初に受信したタスク結果ではないと判定することと、
   前記受信したタスク結果を無視することと、をさらに含む、
   請求項２に記載の方法。
4. 前記受信したタスク結果が前記第１のエッジ装置からのものであるか否かを確認することと、
   前記受信したタスク結果が前記第１のエッジ装置からのものである場合に、前記第２のエッジ装置に対して前記タスクの実行を中止する命令を送信することと、をさらに含む、
   請求項２に記載の方法。
5. 前記受信したタスク結果が前記第１のエッジ装置からのものであるか否かを確認するために、前記タスク結果から前記タスクの情報を取得することをさらに含む、
   請求項４に記載の方法。
6. 前記情報は、前記タスクのＩＤおよび前記エッジ装置のＩＤからなるグループから選択される情報を含む、
   請求項５に記載の方法。
7. エッジエージェントによって、
   前記第１のエッジ装置に関するステータス情報を要求することと、
   前記ステータス情報の受信に失敗した場合に、タスクラッパモジュールを呼び出して障害管理プロセスを開始することと、をさらに含む、
   請求項１に記載の方法。
8. 前記タスクラッパモジュールによって、
   前記第１のエッジ装置の代替として前記第２のエッジ装置を決定することと、
   前記タスクを前記第２のエッジ装置に再割り当てすることと、をさらに含む、
   請求項７に記載の方法。
9. １つまたは複数のプロセッサと、
   前記プロセッサに接続されたコンピュータ可読メモリと、を含むコンピュータシステムであって、当該コンピュータ可読メモリは命令を含み、当該命令は当該プロセッサによって実行されることで、
   エッジ装置上で実行されるタスクをスケジュールするのに用いられる定義されたプロセスに従って、タスクの実行要求を第１のエッジ装置に送信することと、
   前記第１のエッジ装置が前記タスクの実行に失敗した場合に、前記定義されたプロセスを一時中断することと、
   前記タスクの実行要求を第２のエッジ装置に送信することと、
   前記第１のエッジ装置または前記第２のエッジ装置のいずれかからのタスク結果であって最初に受信したタスク結果を、前記タスクのタスク結果とすることと、
   前記定義されたプロセスの残りの部分を続行することと、
   を実行する、コンピュータシステム。
10. 前記最初に受信したタスク結果を前記タスクのタスク結果とすることは、
    前記タスクのタスク結果を受信した場合に、当該タスクが完了済みとしてマークされているか否かを確認することと、
    前記タスクが完了済みとしてマークされていない場合に、前記受信したタスク結果を前記最初に受信したタスク結果であると判定することと、
    前記タスクを完了済みとしてマークすることと、を含む、
    請求項９に記載のコンピュータシステム。
11. 前記タスクが完了済みとしてマークされている場合に、前記受信したタスク結果を前記最初に受信したタスク結果ではないと判定することと、
    前記受信したタスク結果を無視することと、をさらに含む、
    請求項１０に記載のコンピュータシステム。
12. 前記受信したタスク結果が前記第１のエッジ装置からのものであるか否かを確認することと、
    前記受信したタスク結果が前記第１のエッジ装置からのものである場合に、前記第２のエッジ装置に対して前記タスクの実行を中止する命令を送信することと、をさらに含む、
    請求項１０に記載のコンピュータシステム。
13. 前記受信したタスク結果が前記第１のエッジ装置からのものであるか否かを確認するために、前記タスク結果から前記タスクの情報を取得することをさらに含む、
    請求項１２に記載のコンピュータシステム。
14. 前記情報は、前記タスクのＩＤおよび前記エッジ装置のＩＤからなるグループから選択される情報を含む、
    請求項１３に記載のコンピュータシステム。
15. プログラム命令が実装されたコンピュータ可読記憶媒体を含むコンピュータプログラム製品であって、当該プログラム命令はプロセッサによって実行可能であり、当該プロセッサに、
    エッジ装置上で実行されるタスクをスケジュールするのに用いられる定義されたプロセスに従って、タスクの実行要求を第１のエッジ装置に送信する機能と、
    前記第１のエッジ装置が前記タスクの実行に失敗した場合に、前記定義されたプロセスを一時中断する機能と、
    前記タスクの実行要求を第２のエッジ装置に送信する機能と、
    前記第１のエッジ装置または前記第２のエッジ装置のいずれかからのタスク結果であって最初に受信したタスク結果を、前記タスクのタスク結果とする機能と、
    前記定義されたプロセスの残りの部分を続行する機能と、
    を実行させる、コンピュータプログラム製品。
16. 前記最初に受信したタスク結果を前記タスクのタスク結果とする機能は、
    前記タスクのタスク結果を受信した場合に、当該タスクが完了済みとしてマークされているか否かを確認する機能と、
    前記タスクが完了済みとしてマークされていない場合に、前記受信したタスク結果を前記最初に受信したタスク結果であると判定する機能と、
    前記タスクを完了済みとしてマークする機能と、を含む、
    請求項１５に記載のコンピュータプログラム製品。
17. 前記タスクが完了済みとしてマークされている場合に、１つまたは複数のプロセッサによって、前記受信したタスク結果を前記最初に受信したタスク結果ではないと判定する機能と、
    １つまたは複数のプロセッサによって、前記受信したタスク結果を無視する機能と、をさらに含む、
    請求項１６に記載のコンピュータプログラム製品。
18. 前記受信したタスク結果が前記第１のエッジ装置からのものであるか否かを確認する機能と、
    前記受信したタスク結果が前記第１のエッジ装置からのものである場合に、前記第２のエッジ装置に対して前記タスクの実行を中止する命令を送信する機能と、をさらに含む、
    請求項１６に記載のコンピュータプログラム製品。
19. 前記受信したタスク結果が前記第１のエッジ装置からのものであるか否かを確認するために、前記タスク結果から前記タスクの情報を取得する機能をさらに含む、
    請求項１８に記載のコンピュータプログラム製品。
20. 前記情報は、前記タスクのＩＤおよび前記エッジ装置のＩＤからなるグループから選択される情報を含む、
    請求項１９に記載のコンピュータプログラム製品。

Images