知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-06-03
(54)【発明の名称】分散ワークロードを処理する方法及びシステム
(51)【国際特許分類】
G06F 9/50 20060101AFI20240527BHJP
【ＦＩ】
G06F9/50 150A
G06F9/50 150E
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023576348
(86)(22)【出願日】2022-06-09
(85)【翻訳文提出日】2024-01-12
(86)【国際出願番号】 US2022072833
(87)【国際公開番号】W WO2022261652
(87)【国際公開日】2022-12-15
(31)【優先権主張番号】63/209,002
(32)【優先日】2021-06-10
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】523464749
【氏名又は名称】セイリオン インコーポレイテッド
(74)【代理人】
【識別番号】240000327
【弁護士】
【氏名又は名称】弁護士法人クレオ国際法律特許事務所
(72)【発明者】
【氏名】グロス タイラー
(72)【発明者】
【氏名】フェリス ロナルド エイ．
(57)【要約】
処理すべき計算モデル及びデータを異種分散計算デバイスに分散する方法及びシステムを開示する。計算モデル及び一部のデータは、ベンチマークシステムにおいて処理され、タイミングを利用して、各計算デバイスに対してジョブ実行速度を推定する。推定に基づいて、計算デバイスを選択して、データチャンクを割り当てることにより、分散処理を所定の期間内に完了する。計算ジョブをリモートデバイスに転送するように構成されたペイロードマネージャ及びデータメッセージを転送するように構成されたメッセージングエンジンなど、個別のプロセスを使用して、計算モデル及びデータチャンクは、個別の計算デバイスに送信され、ペイロードマネージャ及びメッセージングエンジンは、計算デバイスにおける対応するソフトウェアエンジンと通信する。
【特許請求の範囲】
【請求項1】
異種分散コンピューティング環境において、複数の計算デバイスにデータ処理ジョブを分散する方法であって、前記複数の計算デバイスの各々は、個別のデバイスタイプを有し、かつ、個別のネットワークアドレスと、利用可能なデバイスリソースと、を有し、当該利用可能なデバイスリソースは、処理リソース及びストレージリソースを含み、
前記方法は、
実行可能な計算モデルと、前記計算モデルによって処理されるジョブデータと、を含むジョブペイロードをセントラルサーバで受信するステップであって、前記ジョブデータは、複数のデータチャンクに分割可能であり、各々のデータチャンクは前記計算モデルによって個別に処理される、ステップと、
ベンチマーク計算プラットフォームを使用して、受信した前記ジョブデータの第１の部分において、受信した前記計算モデルを実行することによりベンチマークジョブ計算速度を決定するステップと、
少なくとも１つのデータチャンクにおいて前記計算モデルを実行するのに十分である利用可能なデバイスリソースを有する複数の計算デバイスを識別するステップと、
前記ベンチマークジョブ計算速度に基づいて、前記複数の計算デバイスのそれぞれに対して、個別の推定ジョブ実行速度を決定するステップと、
前記複数のデータチャンクにおいて前記計算モデルを実行するために、前記複数の計算デバイスから計算デバイスのクラスタを選択するステップと、
前記データチャンクのそれぞれを前記クラスタにおける個別の計算デバイスに割り当てるステップであって、前記クラスタにおける各デバイスには、少なくとも１つのデータチャンクが割り当てられ、個別の計算デバイスは、前記個別の推定ジョブ実行速度に基づいて、前記計算モデルによる、割り当てられた前記データチャンクの処理を完了させるための予め決められた値よりも短い推定時間を有する、ステップと、
前記クラスタにおける個別の計算デバイスに、個別の計算デバイスに割り当てられた前記計算モデル及び前記データチャンクを送信するステップと、
前記個別の計算デバイスから計算結果データセットを受信するステップと、
を含み、
各々の計算結果データセットは、個別のデータチャンクに関連付けられる、ことを特徴とする方法。
【請求項2】
前記クラスタにおける個別の計算デバイスに、個別の計算デバイスに割り当てられた前記計算モデル及び前記データチャンクを送信するステップは、第１のソフトウェアエンジンを使用して、前記計算モデルを前記個別の計算デバイスに送信するステップと、
前記第１のソフトウェアエンジンとは別の第２のソフトウェアエンジンを使用して、前記データチャンクを前記個別の計算デバイスに送信するステップと、
を含む、ことを特徴とする請求項１に記載の方法。
【請求項3】
前記第１のソフトウェアエンジンは、計算ペイロードマネージャを含み、当該計算ペイロードマネージャは、識別されたリモートデバイスにおいて、対応するペイロードサービスと通信するように構成されるとともに、計算ジョブを有するペイロードを前記識別されたリモートデバイスに転送するように構成され、前記ペイロードサービスは、前記ペイロードから前記計算ジョブを抽出し、選択されたデータにおける前記計算ジョブを実行するように動作可能であり、
前記第２のソフトウェアエンジンは、データメッセージを、リモートデバイスにおける対応するメッセージングエンジンに転送するように構成されたメッセージングエンジンを含む、ことを特徴とする請求項２に記載の方法。
【請求項4】
前記ベンチマークジョブ計算速度を決定するステップは、前記受信した計算モデルと、前記受信したジョブの第１の部分とを、既知の動作特徴を有するコンピュータシステムに送信するステップを含む、ことを特徴とする請求項１に記載の方法。
【請求項5】
ベンチマークプラットフォームは、複数のベンチマークコンピュータを含み、当該複数のベンチマークコンピュータの各々は相互に異なるデバイスタイプを有し、前記複数のベンチマークコンピュータの各々は、前記受信した計算モデルと、前記受信したジョブの第１の部分と、が送信され、個別のベンチマークジョブ計算速度を有し、
前記方法は、類似性ベクトルにしたがって、前記複数のベンチマークコンピュータのうち他のベンチマークコンピュータよりも前記個別の計算デバイスの動作特徴に類似した動作特徴を有する対応する個別のベンチマークコンピュータを、個別の計算デバイスに対して、識別するステップを更に含み、
個別の計算デバイスの前記決定された推定ジョブ実行速度は、前記対応するベンチマークコンピュータの前記ベンチマークジョブ計算速度に基づく、ことを特徴とする請求項１に記載の方法。
【請求項6】
前記クラスタにおける第１の計算デバイスのための、前記個別の推定ジョブ実行速度に基づいて、前記第１の計算デバイスから計算結果を受信する期限を決定するステップと、前記第１の計算デバイスから結果が受信されずに前記期限が経過したという決定に応答して、計算結果が受信されなかった前記第１の計算デバイスに割り当てられた前記データチャンクを、前記複数の計算デバイスから選択された別の計算デバイスに再割り当てを行うステップと、
を更に含む、ことを特徴とする請求項１に記載の方法。
【請求項7】
前記別の計算デバイスは、前記クラスタに存在しない複数の計算デバイスから選択される、ことを特徴とする請求項６に記載の方法。
【請求項8】
前記クラスタにおける第１の計算デバイスから、健康状態メッセージを受信するステップと、前記健康状態メッセージが健康警報を含むという決定に応答して、計算結果が受信されなかった前記第１の計算デバイスに割り当てられた前記データチャンクを、前記複数の計算デバイスから選択された別の計算デバイスに再割り当てを行うステップと、
を更に含む、ことを特徴とする請求項１に記載の方法。
【請求項9】
前記クラスタにおける個別の計算デバイスから、前記個別の計算デバイスの健康状態を示す応答メッセージを定期的に要求するステップを更に含む、ことを特徴とする請求項８に記載の方法。
【請求項10】
前記第１の計算デバイスは、バッテリー電源式デバイスであり、前記健康警報は、低バッテリー表示を含む、ことを特徴とする請求項８に記載の方法。
【請求項11】
異種分散コンピューティング環境においてデータ処理ジョブを分散するシステムであって、プロセッサを含むコンピュータ管理プラットフォームを含み、
前記プロセッサは、コンピュータメモリと通信し、ネットワークに接続され、前記管理プラットフォームは、前記ネットワークを介して複数の計算デバイスと通信可能であり、
前記メモリは、個別の計算デバイスに対して、個別のネットワークアドレス、デバイスタイプ及び利用可能なデバイスリソースを特定するデータを記憶し、
前記利用可能なデバイスリソースは、処理リソース及びストレージリソースを含み、
前記メモリは、コンピュータ命令を記憶し、
前記コンピュータ命令は、実行されると、
実行可能な計算モデルと、当該計算モデルによって処理されるジョブデータと、を含むジョブペイロードを受信することであって、前記ジョブデータは、各々が前記計算モデルによって個別に処理される複数のデータチャンクに分割可能である、ジョブペイロードを受信することと、
ベンチマーク計算プラットフォームによる、受信した前記ジョブデータの第１の部分における受信した前記計算モデルの実行に基づいてベンチマークジョブ計算速度を決定することと、
少なくとも１つのデータチャンクにおける前記計算モデルの実行に十分である利用可能なデバイスリソースを有する複数の計算デバイスを識別することと、
前記ベンチマークジョブ計算速度に基づいて、前記複数の計算デバイスのそれぞれに対して、個別の推定ジョブ実行速度を決定することと、
前記複数のデータチャンクにおいて記計算モデルを実行するために、前記複数の計算デバイスから計算デバイスのクラスタを選択することと、
前記クラスタにおける個別の計算デバイスに前記データチャンクのそれぞれを割り当てることであって、前記クラスタにおける各デバイスに少なくとも１つのデータチャンクが割り当てられ、個別の計算デバイスは、前記個別の推定ジョブ実行速度に基づいて、前記計算モデルによって実行される割り当てられたデータチャンクの処理を完了させるための推定時間を有し、当該推定時間は予め決められた値よりも短い、前記データチャンクのそれぞれを割り当てること、
前記クラスタにおける個別の計算デバイスに、前記個別の計算デバイスに割り当てられた前記計算モデル及び前記データチャンクを送信することと、
前記個別の計算デバイスから計算結果データセットを受信することと、
を実行するように前記プロセッサを構成し、
各計算結果データセットは、個別のデータチャンクに関連付けられている、ことを特徴とするシステム。
【請求項12】
前記コンピュータ命令は、更に、第１のソフトウェアエンジンを使用して、前記計算モデルを前記個別の計算デバイスに送信することと、
前記第１のソフトウェアエンジンとは別の第２のソフトウェアエンジンを使用して、前記データチャンクを前記個別の計算デバイスに送信することと、
を実行するように、前記プロセッサを構成する、ことを特徴とする請求項１１に記載のシステム。
【請求項13】
前記第１のソフトウェアエンジンは、計算ペイロードマネージャを有し、前記計算ペイロードマネージャは、識別されたリモートデバイスにおいて対応するペイロードサービスと通信するように構成され、かつ、計算ジョブを有するペイロードを前記識別されたリモートデバイスに転送するように構成され、
前記ペイロードサービスは、前記ペイロードから前記計算ジョブを抽出し、選択されたデータにおける前記計算ジョブを実行するように動作可能であり、
前記第２のソフトウェアエンジンはメッセージングエンジンを有し、当該メッセージングエンジンは、リモートデバイスにおける対応するメッセージングエンジンにデータメッセージを転送するように構成されている、ことを特徴とする請求項１２に記載のシステム。
【請求項14】
ベンチマークプラットフォームは、各々が相互に異なるデバイスタイプを有する複数のベンチマークコンピュータを含み、前記コンピュータ命令は、更に、
個別のベンチマークコンピュータに対して個別のベンチマークジョブ計算速度を決定するために、前記複数のベンチマークコンピュータのそれぞれに、前記受信した計算モデルと、前記受信したジョブの第１の部分とを送信することと、
類似性ベクトルにしたがって、前記複数のベンチマークコンピュータのうち他の複数のベンチマークコンピュータよりも前記個別の計算デバイスの動作特徴に類似した動作特徴を有する対応する個別のベンチマークコンピュータを、前記各個別の計算デバイスに対して、識別することと、
を実行するように前記プロセッサを構成し、
個別の計算デバイスの前記決定された推定ジョブ実行速度は、前記対応するベンチマークコンピュータの前記ベンチマークジョブ計算速度に基づく、ことを特徴とする請求項１１に記載のシステム。
【請求項15】
前記コンピュータ命令は、更に、前記クラスタにおける第１の計算デバイスのための、前記個別の推定ジョブ実行速度に基づいて、前記第１の計算デバイスから計算結果を受信する期限を決定することと、
前記第１の計算デバイスから結果が受信されずに前記期限が経過したという決定に応答して、計算結果が受信されなかった前記第１の計算デバイスに割り当てられた前記データチャンクを、前記複数の計算デバイスから選択された別の計算デバイスに再割り当てを行うことと、
を実行するように前記プロセッサを構成する、ことを特徴とする請求項１１に記載のシステム。
【請求項16】
前記別の計算デバイスは、前記クラスタに存在しない複数の計算デバイスから選択される、ことを特徴とする請求項１５に記載のシステム。
【請求項17】
前記コンピュータ命令は、更に、前記クラスタにおける第１の計算デバイスから、健康状態メッセージを受信することと、
前記健康状態メッセージが健康警報を含むという決定に応答して、計算結果が受信されなかった前記第１の計算デバイスに割り当てられた前記データチャンクを、前記複数の計算デバイスから選択された別の計算デバイスに再割り当てを行うことと、
を実行するように前記プロセッサを構成する、ことを特徴とする請求項１１に記載のシステム。
【請求項18】
前記コンピュータ命令は、更に、前記クラスタにおける個別の計算デバイスから、前記個別の計算デバイスの健康状態を示す応答メッセージを定期的に要求するように前記プロセッサを構成する、ことを特徴とする請求項１７に記載のシステム。
【請求項19】
前記第１の計算デバイスは、バッテリー電源式デバイスであり、前記健康警報は、低バッテリー表示を含む、ことを特徴とする請求項１７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
（関連出願の相互参照）
本願は、２０２１年６月１０日に出願された米国仮特許出願第６３／２０９，００２号の優先権を主張するものであり、その内容全体は、参照により本明細書に組み込まれるものとする。
本願は、２０２１年６月１０日に出願された米国仮特許出願第６３／２０９，００２号の優先権を主張するものであり、その内容全体は、参照により本明細書に組み込まれるものとする。
【0002】
本開示は、一般に、計算ジョブ及びワークロードをリモートデバイス及びモバイルデバイスに分散及び分解し、これらのデバイスからジョブ処理結果を収集するコンピュータシステム及び方法に関する。
【背景技術】
【0003】
個人又は会社は、大量のデータセットを分析するためにリソース集約的な計算を実行する必要があるが、直接利用可能なコンピューティングリソースを有しないため、第三者のオンデマンドサービス、例えば、サーバの閉域網（クローズドネットワーク）が存在する１つ以上のデータセンターに構築された様々な商業用クラウドコンピューティングプラットフォームに頼る状況が多い。特定の種類のこのような計算は、データセット全体において全体として動作するのではなく、個別のチャンクにおいてデータを処理することができる。そのようなワークロードは、深層学習の分類及び予測モデル、時系列、多変量及び確率モデルなどを含むが、これらに限定されない。これらの種類の計算は、デバイス間で均等にチャンク化されるより小さなジョブに分けることができる。これを達成するために、計算ノードデバイス間において強制的に均一にする必要があり、及び／又は、結果としてコンピューティング資産の利用が不十分となり、これにより、ワークロード及びデバイス利用の効率が非常に悪くなる。そのようなクラウドコンピューティングデータセンターの構築及び維持は、高価であり、コンピュータハードウェアに大幅な投資をする必要があり、所要電力が大きい。
【0004】
異種分散コンピューティング環境での実行ワークロードを分散できるシステム及び方法を提供することは、有利であり、また、このようなシステム及び方法は、スマートフォン及びタブレットなどのポータブルモバイルデバイスを計算リソースとして使用して確実に動作できれば、より有利である。これらのポータブルモバイルデバイスは、ジョブデータを受信しジョブ結果を返信するネットワークアクセスに制限が課され一貫性がない可能性があり、また、任意の所定のデバイスの動作は、利用可能なバッテリー寿命と、所定のモバイルデバイスのユーザが他の目的のためにデバイスを使用する必要性とによって制約される。
【発明の概要】
【発明が解決しようとする課題】
【0005】
専用サーバ又はクラウドベースシステムである中央管理プラットフォームの動作で、データ処理ジョブを、リモートアクセス可能である複数のネットワーク接続型の計算デバイスに分散し、かつ、相互に関係のない異種デバイスを含む方法及びシステムにより、上記及び他の問題は解決される。各計算デバイスは、例えば、特定のタイプのスマートフォン又はＩｏＴデバイスなどのデバイスタイプを有し、個別のネットワークアドレスを有し、かつ、処理リソース及びストレージリソースなどの利用可能な様々なデバイスリソースにより特徴付けられる。
【0006】
実行可能な計算モデル及び関連データを含むジョブペイロードが管理プラットフォームに提出される場合、受信されたデータの一部を使用して、受信された計算モデルをベンチマークシステムに適用し、受信されたペイロードに対してベンチマークジョブ計算速度を決定する。ベンチマークシステムは、既知の特徴を有する単一のプラットフォームであってもよく、システムによって使用可能な計算デバイスのタイプを反映する複数の異なるタイプのデバイスであってもよい。
【0007】
ベンチマーク計算速度は、複数の計算デバイスに対してジョブ実行速度を推定するために使用される。そして、推定実行速度は、複数の計算デバイスから、計算モデルを実行する計算デバイスのクラスタを選択する場合に使用される。複数の異なるタイプのベンチマークデバイスが使用される場合、所定の計算デバイスに対するジョブ実行速度の推定は、デバイス特徴の類似性ベクトルの値などで示されるような、個別の計算デバイスに本質的に最も近いと見なされるベンチマークデバイスのベンチマークデータに基づいて行うことができる。
【0008】
割り当てられた全てのデータチャンクの処理を所定の計算デバイスが完了するための総時間が所定の時間未満となるように、デバイスの選択と１つ以上のデータチャンクの割り当てを行う。例えば、時間ｔ以内に計算ジョブ全体を計算する必要がある場合、各計算デバイスが選択され、推定ジョブ実行速度に基づいて、時間ｔ以内に完成されるデータチャンクが割り当てられる。遅延の可能性を考慮して、バッファ（例えば、１０％）を含んでもよい。
【0009】
計算デバイスの選択とデータチャンクの割り当ては、所望の動作条件を最大化するために行われる。一実施例において、期限までに割り当てられたワークを完了するのに必要な計算デバイスよりも高速の計算デバイスを使用することを回避するように選択を行う。パフォーマンスの制約の範囲内で全てのジョブを完了するために十分な計算デバイスを利用できない場合は、商業用クラウドコンピューティングサービスを使用して１つ以上の仮想計算デバイスを作成又は起動してもよい。
【0010】
データチャンクを様々な計算デバイスに割り当てた後、割り当てられた計算モデル及びデータをクラスタにおける個別の計算デバイスに送信する。任意の所定の計算デバイスに対して、割り当てられた全てのデータチャンクを一括して送信して処理してもよく、計算デバイスに対して、データチャンクを与えないか、あるいは、データチャンクのうちの１つ又はいくつかのみを与えて、残りのデータチャンクをデータチャンク識別子のみとしてもよい。他のデータチャンクが完成すると、必要に応じて管理プラットフォームから新しいデータチャンクを取得する。その後、計算デバイスによって生成された処理データ結果を、管理プラットフォームに返信し、要求側が利用できるようにする。
【0011】
一実施例において、計算モデル及びデータチャンクを個別の通信転送方法で送信する。例えば、計算モデルペイロードを送信する第１の転送機構は、管理プラットフォームのエッジコンピューティングソフトウェアの形式であってもよく、指定されたデータにおけるペイロードを抽出して実行する計算デバイスの対応するペイロード処理エンジンに計算ペイロードを配信するように構成されている。第２の転送機構は、一般的なイベント駆動及びアプリケーション間のメッセージングのために構成された、ペイロード処理システムの追加オーバーヘッドのない合理化メッセージブローカーサービスなどであり、第２の転送機構を使用して、データチャンクを送信する。計算デバイスにおいて動作する対応するメッセージングソフトウェアは、計算デバイスで受信されたデータチャンクをペイロード処理エンジンに利用できるように動作する。また、メッセージングサービスを使用して計算の結果を返信してもよい。
【0012】
計算モデル及びデータを割り当てて計算デバイスに送信した後、計算デバイスの動作を監視して潜在的なエラー状況を検出する。一実施例では、デバイスの推定ジョブ実行速度に基づいて、所定の計算デバイスの完了期限を決定する。計算結果が受信されずに期限が経過した場合、割り当てられたデータチャンクを、管理プラットフォームにより別の計算デバイス（別の計算デバイスは、複数の計算デバイスから選択することができ、クラスタに既に存在するデバイスであってもよく、クラスタに存在しない計算デバイスであってもよい）に再び割り当てるので、計算モデル及び再び割り当てられたデータチャンクを送信する必要がある。
【0013】
また、計算デバイスの動作は監視される。計算デバイスにおけるソフトウェアは、健康問題又は他の動作問題を検出して、必要に応じて管理プラットフォームに健康警報を送信するように動作する。管理プラットフォームは、また、計算デバイスを定期的にポーリング（ｐｏｌｌ）して、個別の計算デバイスの健康状態を示す応答メッセージを要求する。健康警報メッセージを受信、あるいは、ポーリング応答を受信した場合であって、それが、割り当てられたデータチャンクの処理を計算デバイスが期間内に完了できないか又は完了できない可能性があるといった類の警報又は健康状態を示す場合、１つ以上の割り当てられたチャンクを別の計算デバイスに再び割り当てる。計算デバイスが電池式のデバイスである場合、特定の健康警報は、計算デバイスが割り当てられたワークを完了するために利用できる電力が不十分であるという低バッテリー状態を示す。
【0014】
また、計算デバイス自身は、自身の健康を監視することができ、低バッテリー、メモリ不足又はＣＰＵリソース不足などの健康状態又は警報を検出した場合、中央管理プラットフォームに警報を送信することに加えて、計算デバイスは、その未処理のデータチャンクの一部又は全部を別の計算デバイスに予めオフロードして処理する。このような特徴は、管理プラットフォームへのネットワークリンクが継続して利用できず、管理プラットフォームが結果を受信する予定期限よりもかなり前に健康問題が発生するような動作環境において特に有用である。
【0015】
ワークロード又はジョブ結果を転送するために選択された目標の計算デバイスは、管理プラットフォームへのインターネット接続が利用できなくても、ＷｉＦｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣなどのローカル接続を介してアクセス可能であるデバイスであってもよい。管理プラットフォームは、いずれか一方又は両方の計算デバイスから、利用可能なネットワーク接続により許可されている未処理又は処理済みのワークロードのオフロードに関する情報を得る。このような場合、管理プラットフォームは、例えば、ジョブ完了期限を満たす必要があると見なされれば、再割り当てを維持するか否か、又はデータチャンクの一部若しくは全部を第３の計算デバイスに再び割り当てるか否かを決定する。同様に、ネットワーク接続性の問題によりデータ結果を返信することができない場合、計算デバイスは、管理プラットフォームへのネットワーク接続を有し、かつ、データを返信することができる別の計算デバイスに結果を転送するように動作する。
【図面の簡単な説明】
【0016】
本発明の更なる特徴及び利点、並びに本発明の様々な態様の構造及び動作について、以下、添付図面を参照しながら詳細に説明する。
【0017】
【発明を実施するための形態】
【0018】
図１は、分散ワークロード処理に使用されるシステム１００の概略図である。システム１００は、計算管理プラットフォーム１１０を含み、計算管理プラットフォーム１１０は、ネットワーク１０５に接続されるとともに、ネットワーク１０５を介して、デバイス１１５ａ，１１５ｂなどの複数の計算デバイス１１５と通信を行う。計算デバイス１１５は、計算ジョブを実行するために使用される。計算ジョブは、実行可能な計算モデルと、モデルによって処理されるデータと、を含む。本明細書に更に記載されるように、管理プラットフォーム１１０は、計算ジョブの実行に使用される計算デバイス１１５を１つ以上選択する。分解プロセスは、ワークロードデータを、１つ以上の個々のレコードからなるデータチャンクに分けるために使用され、各レコードは、計算モデルによって処理される。デバイスの能力に基づいて、データチャンクはサイズが決められ、計算デバイス１１５に割り当てられ、ワークロードデータチャンクは、使用される様々な計算デバイスのリソース及び能力に応じて、サイズが異なってもよい。１つ以上のデータチャンクがデバイスに割り当てられて処理される。管理プラットフォーム１００は、モデル及びジョブデータのチャンクを選択された計算デバイス１１５に分散する。計算デバイス１１５で動作するアプリケーションソフトウェア１４０は、モデルを受信して、受信されたデータのチャンクに適用し、処理済みのデータ結果を管理プラットフォーム１１０に返信するように動作する。各計算デバイス１１５の実行結果は、管理プラットフォーム１１０内で取得され、集約され、最終結果は、計算要求者に返信される。
【0019】
顧客又はシステム管理者は、遠隔計算デバイス１２０を介して管理プラットフォーム１１０にアクセスする。アクセスインタフェース１２５は、計算ジョブ及びデータの提出、結果の検索、システム設定の制御、管理プラットフォーム１１０若しくは様々な計算デバイス１１５の動作の監視、あるいは他の目的に使用することができる。インタフェース１２５は、インターネットのウェブサーバインタフェース形式によるなどの、ネットワーク１０５を介して又は適切なＡＰＩを介して、管理プラットフォーム１１０への直接接続を提供する。
【0020】
ネットワーク１０５は、インターネット、ＬＡＮ、ＷＡＮあるいは他のオープンネットワーク又はクローズドネットワークなどの分散ネットワークであってもよい。管理プラットフォーム１１０及び計算デバイス１１５は、ハードワイヤードイーサネット（登録商標）などの従来のハードウェア及びソフトウェア、又は無線Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、セルラー、あるいは、適切なネットワーク接続を確立することができる他のデータリンクを含む。アクセスポイント及びルータなどの中間ネットワークデバイス（図示せず）、携帯電話の基地局（セルタワー）、並びに、ネットワーク１０５に接続する中間ネットワークは、ネットワーク１０５への接続を確立するために使用可能である。図１は、単一のネットワーク１０５のみを示すが、本明細書に更に説明されるように、様々な実施例において、デバイス間の通信に１つ以上のネットワークを使用してもよい。
【0021】
管理プラットフォーム１１０は、１つ以上のコンピュータシステムを含むコンピュータサーバプラットフォームにおいて実施され、１つ以上のコンピュータシステムは、計算デバイスの登録を維持し、ジョブモデル及びデータを受信し、モデル及びデータを様々な計算デバイスに分散し、ユーザに返信される結果を受信し集約するのに適した処理能力、ネットワーク接続性及びデータ記憶能力を有する。適切なハードウェアプラットフォームは、当業者にとって既知であり、特定の属性、例えば、オペレーティングシステム及びアクセス方法は、実施態様によって異なってもよい。特定の実施例において、管理プラットフォーム１１０は、クラウドストレージを有する仮想コンピュータ又はクラウドコンピュータなどの１つ以上の仮想化技術を使用したクラウドコンピューティングシステムにおいて実施される。これにより、管理プラットフォーム１１０の能力の実施及び拡張を容易にすることができる。また、特定の機能を１つの個別のコンピュータで実現し、他の機能をクラウドコンピューティングプラットフォームにオフロードするハイブリッド手法を使用してもよい。
【0022】
また、テストプラットフォーム１３０は、管理プラットフォーム１１０に接続することができる。本明細書に更に説明されるように、テストプラットフォーム１３０は、モデルベンチマーク動作に使用される。
【0023】
図２は、管理プラットフォーム１１０のソフトウェア構造の概略図である。本明細書に説明されるように、管理（Ａｄｍｉｎ）エンジン２０５は、管理プラットフォーム１１０の主要機能を提供する。ソフトウェアを使用して実施され、ソフトウェア自体は、様々なアプリケーション及びプロセスに分けることができる。Ａｄｍｉｎエンジン２０５は、メモリ２１０と通信し、メモリ２１０は、様々な個別のストレージの組み合わせであり、ローカルネットワークドライブ並びにクラウドストレージとして、短期（ＲＡＭ）ストレージ及び長期ストレージの混合を含んでもよい。Ａｄｍｉｎエンジン２０５によって使用される動作ソフトウェアを記憶することに加えて、メモリ２１０はまた、実行される１つ以上のモデル２１１と、モデルによって処理されるデータ２１２と、モデルと共に処理されるために、データのチャンクを伴って又は伴わずに配信されるペイロード２１３と、モデルをデータチャンクにおいて実行することにより生成され、管理プラットフォーム１１０に返信される結果データ２１４と、を記憶するために使用される。メモリ２１０はまた、システム１００において使用されるために呼び出される計算デバイス１１５のデバイス登録データ２１８と、システム１００のユーザのユーザ情報２１６と、を記憶するために使用される。システム１００のユーザは、処理されるジョブ及びデータを提出する顧客、登録した計算デバイス１１５に関連付けられた者、及びシステム１００の管理者を含む。また、操作データ及びシステムログなどの追加情報２１７を記憶させてもよい。
【0024】
ペイロードマネージャエンジン２１５は、計算デバイス１１５のソフトウェア１４０と通信して、ペイロードを計算デバイス１１５に送信し、ペイロードは、計算モデルを含み、また、モデルを使用して処理するデータチャンクを１つ以上含む。個別のメッセージングエンジン２２０も、計算デバイス１１５のソフトウェア１４０と通信するために使用される。本明細書に更に記載するように、一実施例において、ペイロードマネージャを使用してモデルが計算デバイスに送信され、メッセージングエンジン２２０は、モデルによって処理されるデータチャンクを送信し、結果を受信するために使用される。ペイロードマネージャ２１５及びメッセージングエンジン２２０は、同一の下位ネットワークインタフェース２２５を使用して、ネットワーク１０５に接続される。また、ネットワーク１０５’などの他のネットワークに接続されてもよい。ネットワーク１０５などのネットワークを介して、又は直接接続を介して、テストプラットフォーム１３０にアクセスすることができる。ユーザ又は管理者の管理プラットフォーム１１０への一般的なアクセスは、ウェブページインタフェース２３０に接続するウェブブラウザーを介して行うことができる。
【0025】
システム１００には、典型的に、複数の個別の計算デバイス１１５が存在し、計算デバイス１１５のそれぞれは、少なくとも一部の時間に計算ジョブを実行するために管理プラットフォーム１１０が呼び出し可能な計算容量を有する。システム１００は、同種又は異種の一連の計算デバイスと共に動作するので、様々な異なるタイプの計算デバイスを同時に使用することができる。
【0026】
特定の計算デバイス１１５は、電池式のスマートフォン又はタブレット又はラップトップコンピュータなどのポータブルモバイルデバイス、ＩｏＴデバイス、あるいは、ネットワーク接続型の他のコンピューティングデバイスであってもよい。また、計算デバイス１１５は、固定位置デバイスであってもよく、固定位置デバイスは、外部電源、デスクトップＰＣなどのコンピュータ、あるいは、スタンドアロン環境で動作するか又はデータセンターの一部として利用可能であるコンピュータサーバを有する。また、他のタイプの計算デバイス１１５が使用されてもよい。
【0027】
図３は、代表的な計算デバイス１１５の概略的なハードウェアブロック図を示す。典型的な計算デバイス１１５は、メモリ３１０に接続されたマイクロコントローラ３０５を含み、メモリ３１０は、ＲＡＭ、ＲＯＭなどの短期ストレージ及び長期ストレージの両方、ソリッドステートドライブなどを含んでもよい。メモリ３１０は、マイクロコントローラ３０５によって実行されるソフトウェアを記憶する。ソフトウェアは、オペレーティングシステム用のプログラムストレージと、システム１００に使用されるアプリケーションソフトウェア１４０と、他のアプリケーション用のソフトウェアと、ソフトウェアによって使用されるデータストレージと、を含んでもよい。また、１つ以上のネットワークインタフェースは、ネットワーク１０５及び他のネットワークに接続するために設けられる。利用可能なネットワーク接続は、イーサネット（登録商標）接続などの有線ネットワーク接続３１５と、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（ＮＦＣ）、セルラーデータを含む１つ以上のタイプの無線データ接続３２０と、を含む。ネットワーク接続３１５，３２０は、ネットワーク１０５を介して管理プラットフォーム１１０と通信するために使用される。また、ネットワーク接続は、他の計算デバイス１１５を識別し、それらと通信するために使用される。計算デバイスは、外部給電されるか又はバッテリー３２５によって給電されてもよい。計算デバイスのタイプに応じて、視覚ディスプレイ３３０と、キーボード又はタッチスクリーンなどのユーザ入力デバイス３３５と、を備えてもよい。様々なセンサ３４０は、マイクロコントローラ温度及びバッテリーレベルなどのデバイス状態を監視するために設けられてもよい。
【0028】
計算デバイス１１５は、他の目的に使用され、モバイルデバイスであってもよい。したがって、任意の所定の計算デバイス１１５に対して、計算リソースを連続的又は間欠的に利用してもよく、リソースが利用可能である場合、リソースは、実質的に計算デバイス１１５の全容量又は一部容量のみを反映してもよい。所定の計算デバイス１１５の利用可能な容量は、経時的に変化してもよい。
【0029】
図４は、アプリケーションソフトウェア１４０のソフトウェア構造の概略図である。ペイロードサービス４１０は、ペイロードマネージャ２１５から送信されたペイロードなどを管理プラットフォーム１１０から受信し、選択されたデータのセットに計算ジョブを実行し、結果を記憶するように動作する。ペイロードサービス４１０は、ペイロードマネージャ２１５との通信を管理するエッジサービス４１１と、受信されたモデル及びデータを実行する機能を有するペイロード処理エンジン４１２と、を含んでもよい。受信されたモデルは、計算デバイス１１５のメモリ３１０内のモデルストレージ４２０に記憶される。モデルに適用されるデータのセット（データチャンク）は、メモリ３１０のデータストレージ領域４２５に記憶される。受信されたデータチャンクに適用されたモデルからの計算データは、メモリ３１０の結果データ領域４３０に記憶される。
【0030】
以下に更に説明されるように、一実施例において、モデルによって処理されるデータチャンクは、管理プラットフォーム１１０のメッセージングエンジン２２０からスーパーバイザサービス４０５に提供することができる。スーパーバイザサービス４０５は、管理プラットフォーム１１０のメッセージングエンジン２２０と通信するメッセージングエンジン４０６と、スーパーバイザエンジン４０７と、を含む。スーパーバイザエンジン４０７は、ペイロードサービス４１０に既知でありかつ利用可能な方式で、受信されたデータチャンクをデータストレージ領域４２５に記憶する動作機能を有する。ペイロードサービス４１０は、そのデータにモデルを適用する。同様に、結果データは、スーパーバイザサービス４０５によってアクセスされ、結果データは、スーパーバイザエンジン４０７によりメッセージングエンジン４０６を介して管理プラットフォーム１１０に返信される。スーパーバイザエンジン４０７は、本明細書に更に記載される様々な他の機能を実行する。
【0031】
アプリケーションソフトウェア１４０は、デバイスオペレーティングシステムと通信して計算デバイス１１５において動作し、デバイスオペレーティングシステムを介して、データ通信及び他の機能用の、ソフトウェア及びファームウェアを含む、様々なシステム機能、入力及び出力などにアクセスする。また、図４は、健康リソースモニター４４０を示し、健康リソースモニター４４０は、必要に応じて、スーパーバイザサービス４０５及びペイロードサービス４１０に対して、ＣＰＵ温度、バッテリーレベル、利用可能なメモリ、プロセッサ、及び他のシステムリソースの状態を含むシステム状態を信号で伝える。健康リソースモニター４４０は、単一のモジュールとして示されているが、様々な個別のモジュールを使用してもよい。監視は、アプリケーションソフトウェア１４０の一部であってもよく、あるいは、計算デバイスのハードウェア、ファームウェア及び／又はＯ／Ｓ４３５若しくは他のソフトウェアにおいて実施されてもよい。健康リソースモニター４４０は、Ｏ／Ｓに対してシステムクエリーを発行してシステム状態データを取得し、システムの中断を監視する。システムの中断は、低バッテリー警報、過剰なＣＰＵ温度、メモリ不足によるエラーなどの重要な問題を信号で伝える。
【0032】
所定の計算デバイス１１５から利用可能なリソース及び容量についての詳細は、計算デバイス１１５の管理プラットフォーム１１０への初期登録期間中に収集することができる。初期登録では、計算デバイス１１５に関する情報は、デバイス登録データベース２１８などのメモリ２１０に収集されて記憶される。また、エンドユーザアプリケーション１４０は、登録期間中に計算デバイスにインストールされることにより、本明細書に開示されるように、システム１００と情報を交換して、割り当てられた計算ジョブを受信して実行し、結果を返信する。アプリケーション１４０の全体の動作は、具体的な実施の詳細が異なるが、異なるタイプの計算デバイスで同じであってもよい。アプリケーションソフトウェア１４０は、段階的にインストールすることができ、初期インストールでは、ノードデバイスがハードウェア及びソフトウェアのプラットフォームの動作要件の最小の要件を満たすことを検証する。
【0033】
各計算デバイス１１５は、関連付けられた固有のＩＰ又は計算デバイス１１５と通信するために使用することができる他のネットワークアドレスを有する。また、登録期間中に個別のデバイスＩＤを割り当てることができる。デバイス能力に応じて、１つ以上の通信アドレスが利用可能であり、これらの個別のアドレスが記憶される。管理プラットフォーム１１０は、ネットワークの可用性及び通信のタイプに応じて、利用可能なアドレスの中から選択を行う。例えば、多くの通信は、ネットワーク１０５を介して行われることが想定され、ネットワーク１０５は、インターネットであってもよい。しかし、主ネットワーク接続が利用できないが、なおも通信が望まれる場合、セルラーネットワークを介して、ＳＭＳメッセージングなどの個別のプロトコルを使用して、いくつかのメッセージを通信してもよい。
【0034】
これらの計算リソースの幅広い分散及び多様性により、能力及び持続性が異なるネットワークを介して、登録期間中に各デバイスの様々な計算メタデータ属性を収集することもできる。メタデータは、登録された計算デバイスの個々の能力を特定する。デバイスの容量を反映するデバイス属性は、ＣＰＵのタイプ及び速度、ＲＡＭ及びソフトウェアの記憶空間、ネットワーク遅延、オペレーティングシステム、システムがバッテリー電源式か否か又はバッテリー電源式の可能性があるか否か、及び利用可能なネットワーク接続のタイプ、のうちの１つ又は複数を含んでもよい。他のメタデータは、システム１００による使用のために登録したデバイスが利用可能であるか又は利用不可能である日数／時間の制限を含んでもよい。そのようなメタデータの一部又は全部は、管理プラットフォーム１１０により使用され、実行のために所定の計算ジョブが送信される利用可能な計算デバイス１１５を識別し、どのようにデータをチャンク化して、選択されたデバイスに分散するかを決定する。
【0035】
計算デバイスの利用可能な能力は、経時的に変化してもよい。例えば、所定のデバイスは、通常の業務時間外にその１００％の計算能力及びメモリを提供するが、平日の午前９時～午後５時には２５％のみを提供してもよい。また、登録プロセスにおいて、予想される可用性についての詳細を収集してもよい。また、可用性パターンを経時的に監視してデバイスプロファイルを開発してもよい。また、所定のデバイスの利用可能な能力は、動的に変化することができる。デバイスは、アイドリング中における時間ｔにおいて１００％の容量を有してもよいが、デバイスが他の理由でアクティブに使用される場合、一部の容量のみが現在のシステムに提供される。したがって、システム登録内に最初に設定されるか、あるいは、時間と共に学習された、所定のデバイスの能力は、任意の計算ジョブをデバイスに割り当てる前に管理プラットフォーム１１０によって確認される。また、計算デバイス１１５は、管理プラットフォーム１１０に、その利用可能なリソースを報告するメッセージを定期的に送信するか、あるいは、管理プラットフォーム１１０は、定期的に計算デバイスにクエリーを行って情報を取得する。
【0036】
システム１００の一般的な動作中に、管理システム１１０により、登録された計算デバイスの全体状態が監視され、現在の計算デバイス状態の内部レコードが維持される。計算デバイスが正常に動作している場合（例えば、定期的に、あるいは、システムクエリーに応答して、計算デバイスから送信されたメッセージによって示されてもよい）、デバイス状態は、アクティブに設定される。ノードが全容量で動作していない場合、例えば、予定のリソースが一部のみ利用可能であるが、計算ノードが少なくとも一部の状況での使用のために十分なリソースが残る場合、計算ノード状態は、縮退レベル（ｄｅｇｒａｄｅｄ ｌｅｖｅｌ）に設定することができる。そして、この縮退レベルは、ノードをランキングし選択してワークロードパッケージを受信するときに使用することができる。デバイスが動作していない場合、又は利用可能なリソースが最小要件を満たさない場合、ノードデバイス状態は、一時停止（ｓｕｓｐｅｎｄｅｄ）に設定することができる。
【0037】
場合によっては、利用可能なインベントリから計算デバイスを一時的又は永続的に除去する必要がある。計算デバイスが現在ジョブを実行している場合、ジョブが完了したとき、あるいは、計算デバイスを定期的にクエリーできるとき、管理プラットフォーム１１０システムにメッセージを送信するように計算デバイスに指示がなされる。また、デバイスが使われていないという通知を受信した場合、デバイスはインベントリから除去される。
【0038】
図５Ａ及び図５Ｂは、モデル及びデータを含むジョブペイロードをユーザが提出して検証する、概略的なフローチャートを示す。初期ステップにおいて、ユーザは、ウェブインタフェース２３０などを介して管理プラットフォーム１１０に接続して、サインインする。ユーザを認証し、ユーザにジョブを提出する権限が与えられることをチェックするために、初期チェックが行われる（ステップ５０２～５１２）。ユーザが適切な権限を有していれば、ペイロードアップロードオプションの選択に応答して、ペイロードに関する情報、例えば、処理ジョブの一般タイプ、データ量、完了予定時間／日などを提供するようにユーザを促す。チェックを行って、入力データが正しく、ユーザ権限を超えないことを確認する。例えば、最大ジョブサイズを、設定してもよい。（ステップ５１４～５１８）。ブロッキング問題がなければ、顧客は、例えば、ジョブモデルファイル及び１つ以上のジョブデータファイルをタグ付けするなど、従来のメカニズムを使用して、ペイロードをアップロードする（ステップ５２２）。
【0039】
ユーザのペイロードをアップロードした後、初期セキュリティチェックが実行される。ウイルススキャンを実行し、ペイロードが不審に思える場合、ペイロードを隔離して顧客に問題を報告する（ステップ５２４～５２９）。また、モデル及びデータに（単独に又は組み合わせて）チェックサム又は同様の検証を実行し、データと、ユーザによって提供されたチェックデータ又はアップロードされたペイロードに埋め込まれたチェックデータと、を比較して、データエラーを検出する。エラーを検出した場合、ペイロードを拒否し、エラーをユーザに通知する。（ステップ５３０～５３６）。
【0040】
異なるタイプのモデル分析は、計算複雑性が異なる。ジョブを目標時間だけ実行できる一連の計算デバイスの選択を支援するために、ジョブ提出者に対して、例えば、予め決められた一連の分析タイプから選択することにより、ワークロードモデルが実行している分析のタイプを識別するように要求することもできる。分析のタイプは、所定のプロセッサが所定量の典型的なデータを処理する速度を推定するために使用され、これにより、所定の計算デバイス１１５がデータチャンクを処理するためにかかる時間が推定される。
【0041】
アップロードプロセスの一部として、ペイロードモデルタイプの確認を実行して、ペイロードにコード化されたモデルタイプ又はアルゴリズムが、顧客によって指定されたモデル又はアルゴリズムのタイプと一致することを確認する（ステップ５３８）。パターンマッチングは、異なる分析タイプに使用される共通タイプのルーティンを識別するために、コードで使用される。また、他のメタデータであってもよい。例えば、テンソルフローライトで作られた単純分類モデルは、テンソルフローで作られた物体検出モデルに比べてパフォーマンス特徴が異なる。モデル不一致があれば、顧客に報告される（ステップ５４０～５４２）。ＡＩベースのパターンマッチングモデルタイプの検出は、システム１００の動作に伴って経時的に学習されたＡＩモデルと共に使用される。
【0042】
提出者からのジョブタイプ情報の取得に加えて、あるいは、その代わりに、管理プラットフォーム１１０は、所定のジョブに対する計算速度の測定を決定するベンチマーク動作を実行してもよい（ステップ５４４）。また、ベンチマークは、提供された計算モデルが機能的であり、提供されたデータに動作できる検証を有利に提供する。ベンチマークに複数の異なるデバイスが使用される場合に、ベンチマークが識別するのは、計算モデルに適合せず、そうでなければ利用可能であっても、そのジョブへの使用には選択されるべきではないプラットフォームである。
【0043】
一実施例において、ジョブの処理対象の実際のデータの一部を使用した、提出された計算モデルは、テストプラットフォーム１３０において、ベンチマークを行うための既知の計算特徴を有する１つ以上のコンピュータにおいて実行される。図６を参照すると、提出されたモデル及びそれに適用すべきデータを受信した後（ステップ６０２）、１つ以上のベンチマークマシンを選択し（ステップ６０４）、提出されたモデルに適用すべき代表的なデータを提出されたデータセットから抽出する（ステップ６０６）。続いて、ジョブの実際のモデル及び代表的データを使用したベンチマークテストをベンチマークマシンに送信して実行する（ステップ６０８，６１０）。
【0044】
管理プラットフォーム１１０は、ネットワーク１０５とは別のリンク、例えば、ＬＡＮ、又は他の直接接続若しくはローカル接続を使用して、テストプラットフォーム１３０においてコンピュータに接続される。代わりに、テストプラットフォーム１３０におけるコンピュータは、ネットワーク１０５を介してアクセス可能であってもよい。ベンチマークの結果を送受信するために、テストプラットフォーム１３０におけるコンピュータは、計算デバイス１１５と同じように、管理プラットフォーム１１０により取り扱われる。各ベンチマークマシンが同じモデル及びデータセットで動作する場合、単一の共通ペイロードを用意して各ベンチマークマシンに送信し、プロセスは、各ベンチマークマシンにおいてほぼ並行して動作する。
【0045】
既知の動作特徴を有する単一のテストコンピュータは、処理速度のベンチマーク測定を得るために使用することができるが、一実施例において、登録済又は登録予定の典型的な計算デバイス１１５のタイプを代表する複数のテストコンピュータが使用される。例えば、複数のテストコンピュータは、ｉＯＳを実行するいくつかの異なるｉＰｈｏｎｅ（登録商標）モデル、Ａｎｄｒｏｉｄ（登録商標）ベースのスマートフォン、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムを実行する一般のＣＰＵ構成を有するデスクトップコンピュータなど、異なるブランド及びモデルのスマートフォンを含んでもよい。テストコンピュータ１３０は、それぞれ適切なアプリケーションソフトウェアを実行して管理プラットフォーム１１０と通信し、ジョブを受信して実行して結果を返信する。
【0046】
ベンチマークに使用される計算データのサンプル部分のサイズは、ジョブの実際の処理時に使用されるデータチャンクのサイズと同等であってもよいが、通常は、それよりはるかに小さいと想定される。これは、ベンチマークの目的は、大量のデータを処理することではなく、代表的なデータを使用して、対象となるモデルの計算速度を測定することであるためである。それにもかかわらず、処理速度が入力データの値に依存する場合、十分に大きなサンプルを選択することで、データのばらつきによる処理時間の差が平均化される。例えば、モデルが画像処理アルゴリズム用である場合、ソース画像が、より詳細であれば、計算により時間がかかる可能性があるため、ベンチマークをより正確にするように、複雑度の異なる複数のピクチャを処理する必要がある。
【0047】
一実施例において、ベンチマーク中にモデルから出力されるデータを破棄することができる。代わりに、かつ、特に、ベンチマークに使用されるデータの容量が大きい場合、データを記憶し、残りのソースデータのみをチャンク化し、計算デバイスに分散して処理してもよい。
【0048】
続いて、ベンチマークにおいてデータを処理するのに必要な時間を使用して、提出されたモデル及びデータの処理速度を決定する（ステップ６１２）。ベンチマークデータは、所定の計算デバイス１１５がデータチャンクを処理するためにかかる時間を推定するために使用され、この情報を使用して、ジョブに使用される計算デバイスの選択、及び、計算デバイスのデータチャンクの割り当てを行う。
【0049】
より具体的には、１つ以上のテストマシンからのベンチマークデータが与えられる場合、提出されたモデルを提出されたデータのデータチャンクに所定の計算デバイス１１５が適用する時間は、テストマシンのベンチマーク時間に基づいて推定される。複数のテストデバイスが利用可能である場合、計算デバイス１１５の予定された動作特徴に最も近いと見なされる、テストプラットフォーム１３０におけるコンピュータのベンチマーク時間を使用してもよい。特定のテストデバイスに対する計算デバイス１１５の近接性は、デバイスのタイプ又はブランド、所定のタイプのモデル又はバージョン、オペレーティングシステム及びオペレーティングシステムバージョン、プロセッサ構造及び他の要因との一致の近接性に基づいて、数値を伴う次元を有する類似性ベクトルの大きさを決定することにより、測定される。
【0050】
また、計算デバイス１１５とテストプラットフォームデバイス（複数可）との間の計算能力の違いを反映するために、スケール因子（スケールファクタ）をベンチマーク処理速度に適用することができる。処理時間に影響を与える能力の違いは、ＣＰＵのタイプ及び速度、共処理デバイスの可用性、オペレーティングシステム、利用可能なメモリ及びストレージの量及び速度を含む。所定の計算デバイスのベンチマーク時間をスケーリングするための情報は、管理プラットフォーム１１０への計算デバイスの初期登録期間中に取得される。デバイスの特徴を使用してスケール因子（スケールファクタ）を推定する。加えて、又は代わりに、初期ベンチマークテストは、登録時又は他のタイミングで新しい計算デバイスにおいて実行される。テストプラットフォーム内のデバイスに対して、同一又は同等のベンチマークテストを実行し、結果を用いて、１つ以上のベンチマークテストデバイスと比較した、特定の計算デバイス１１５の相対的なパフォーマンススケール因子（スケールファクタ）が提供される。初期ベンチマークテストは、任意の特定の提出された計算ジョブとは無関係であってもよい。複数のテストデバイスが利用可能である場合、計算デバイス１１５の予定された動作特徴に最も近いと見なされる、テストプラットフォーム１３０におけるコンピュータのベンチマーク時間は、計算デバイス１１５のパフォーマンスを推定するために使用されてもよい。特定のテストデバイスに対する計算デバイス１１５の近接性は、デバイスのタイプ又はブランド、オペレーティングシステム、プロセッサ構造などによって測定される。
【0051】
図７は、ａｄｍｉｎエンジン２０５及びペイロードマネージャ２１５などの、管理プラットフォーム１１０内で実行可能なジョブ配置の一般的なプロセスの概略的なフローチャートである。計算ジョブが実行のために提出される場合、システムは、利用可能なデバイスのリストをコンパイルした後、所定の基準を満たすように、集約された計算要求に対応するため、一連のデバイスを識別する。例えば、最小数のデバイスを使用し、ジョブ要件を満たす計画完了時間を有するために選択される。一実施例において、最初に、ジョブ情報を取得する（ステップ７０２）。計算デバイスがそのジョブに使用するハードウェア最小要件を決定する（ステップ７０４）。ハードウェア最小要件は、実行されるモデルのタイプ、モデルサイズ及び利用可能な記憶空間によって決定される。例えば、計算デバイスは、いくつかのジョブタイプに適するが、他のジョブタイプに適さない計算容量を有する場合がある。利用可能な記憶空間は、計算モデル、モデルに適用される少なくとも１つのデータチャンク、及び計算の結果を記憶するのに十分であるべきである（例えば、図４のメモリ３１０，４２０，４２５，４３０参照）。利用可能な記憶空間は、ジョブ配置の一環として、所定の計算デバイスにどのくらいのデータを割り当てることができるか、どれぐらいのデータチャンクを一括して配信できるか、あるいは、データチャンクを経時的にストリーミングできるかを決定するために使用される。
【0052】
最大実行時間を計算し（ステップ７０６）、参照のために使用することができる。最大実行時間は、データセット全体の計算ワークロードを実行するためにかかる時間の長さの表示である。実行時間は、計算デバイスの集合全体の平均データ処理速度を使用して計算される。代わりに、最大実行時間は、指定された期限までにジョブを完了させることができる最大時間として見なされてもよい。
【0053】
チェックを行って、登録したどの計算デバイス１１５が利用可能であるかを決定する（ステップ７０８）。計算デバイス１１５が管理プラットフォーム１１０からペイロードを受信可能な状態であれば、計算デバイス１１５は利用可能と見なすことができる。可用性基準は、デバイスの連結性などの要因と、デバイス健康測定値と、を含み、測定値は、デバイスストレージの状態、ＣＰＵ温度、バッテリー電源式デバイスの充電状態からなる。更なる実施例において、計算デバイスの予定される将来の可用性が考えられるのは、管理プラットフォーム１１０が新しいジョブ及びデータをその計算デバイスに送信することが予定される前に、計算デバイスが利用可能であると想定される場合である。
【0054】
割り当てられた期間内にジョブを完了するために利用可能な計算デバイスが十分にあることを確認するために、利用可能な計算デバイスへのジョブの初期割り当てを行うことができる。ベンチマークプロセスで決定された利用可能な計算デバイスの推定データ処理率は、デバイスの選択及びデータチャンク割り当ての様々なシナリオの下でジョブ完了時間を推定するために使用される。計算デバイスが十分ではない場合（ステップ７１０）、容量不足信号が生成される（ステップ７１２）。管理プラットフォーム１１０は、提出ユーザに問題を信号で伝え、利用可能な全容量と一致するように目標の完了期限を調整する（ステップ７１６）。
【0055】
代わりに又は加えて、管理プラットフォーム１１０の使用に利用可能な登録された計算デバイスが、目標の完了時間までに総ワークロードを完了するのに十分な容量を有していない場合、必要な計算リソースを提供して目標を達成するために、仮想計算デバイスを作成又は起動する（ステップ７１４）。例えば、管理プラットフォーム１１０は、従来の商業用クラウドコンピューティングサービス、例えば、Ａｍａｚｏｎ（登録商標）ウェブサービスに新しい仮想デバイスを作成するか、あるいは、そのサービスに予め設定された既存の、おそらく休止状態にある仮想デバイスを起動するように構成される。続いて、仮想デバイスは、ジョブに使用されるために、利用可能な計算デバイスのセットに追加され、それに応じて、データチャンクが割り当てられ、モデルと共に分散される。第三者のクラウドサービスは通常、仮想デバイスの使用料金を課すため、登録された計算デバイス１１５の代替又は補強のために仮想マシンを使用することは、登録された計算デバイスが計算要件を満たすのに不十分である場合に限定される。仮想マシンと通信して計算モデル及び割り当てられたデータチャンクを送信するためのプロトコルは、システム１００用のアプリケーションソフトウェア１４０を使用した計算デバイス１１５のものとは異なるプロトコルを使用して行われる必要がある。代わりに、計算デバイスで使用されるアプリケーションソフトウェア１４０のバージョンを仮想マシンにロードすることができ、それにより、仮想マシンは、登録した計算デバイス１１５と同じように、管理プラットフォーム１１０により取り扱われる。
【0056】
デバイス初期選択を行った後、デバイスのデバイス可用性及びリソースを確認し、デバイスをクラスタに割り当てる。一実施例において、所定の計算デバイス１１５からの利用可能なリソースが確認され、デバイスが選択されると、所定の計算デバイスのオペレーティングシステムなど及び他の要因に対して可能な限り、これらのリソースを特定期間にわたって予約するように、アプリケーションソフトウェア１４０に指示がなされるので、管理プラットフォーム１１０は、指定され確認されたリソースに依存して、ジョブを割り当て、分散することができる。デバイスの検証及びリソースの予約は、計算デバイスの選択期間中に様々な段階で行われる。
【0057】
利用可能な計算デバイスをクラスタに割り当て、予約状態に設定する（ステップ７１８，７２０）。一実施例において、所定の計算デバイス１１５からの利用可能なリソースが確認され、デバイスが選択されると、所定の計算デバイスのオペレーティングシステムなど及び他の要因に対して可能な限り、これらのリソースを特定期間にわたって予約するように、アプリケーションソフトウェア１４０に指示がなされるので、管理プラットフォーム１１０は、指定され確認されたリソースに依存して、ジョブを割り当て、分散することができる。デバイスの検証及びリソースの予約は、計算デバイスの選択期間中に様々な段階で行われる。
【0058】
管理プラットフォーム１１０システムは、計算ジョブの要件に基づいて、計算デバイスの利用可能なメタデータを使用して、利用可能なデバイスのリストから計算デバイス１１５のセットを選択し、データチャンク又は処理される複数のチャンクを、分解プロセスにおいて、各計算デバイスに割り当てる（ステップ７２２）。データの順次処理を必要としない場合のセキュリティを高めるために、データレコードをランダム化してから、デバイスに順次割り当てるか（チャンクサイズが単一のレコードである場合）、あるいは、デバイスに割り当てられるチャンクに順次割り当てることができる。また、データレコードの非ランダムなストライプ選択を使用してもよい。このようにデータレコードを分散すると、連続データレコードによって収集される情報を除去又は低減することにより、個々のデバイスへのハッキングの価値を低下できる。シャッフルされたレコードの順序を記憶することにより、計算結果は、最初に提供されたレコード順序と一致するように配置される。
【0059】
選択要因は、利用可能なＲＡＭ、他の記憶空間、ネットワーク遅延、コンピューティングプラットフォームのハードウェア及びソフトウェアを含んでもよい。異なる計算モデルは、特定のコンピューティング環境を必要とする場合があるため、利用可能なデバイスをフィルタリングして、配置されるモデルを実行する能力を持たないデバイスを排除する。また、ベンチマークデータなどに基づくジョブの実行速度の推定を使用してもよい。
【0060】
どの計算デバイス１１５をジョブに使用するか、及び、どのようにデータチャンクをそれらの間に割り当てるかを選択して、１つ以上の要因に対して優先順位をつける。プロセスはまた、デバイス及び実行に提供されるデータ量を選択することができ、それにより、所定の計算デバイス１１５に割り当てられたワークロードは、少なくとも特定量の最大ストレージ利用率を使用し、例えば、モデルサイズと、送信されるデータチャンクのサイズ及び数量と、データ処理結果を管理プラットフォーム１１０に返すためにオフロードできるまでにデータ処理結果を記憶するのに必要なメモリと、を考慮する場合、最大ストレージ利用率の１０～１５％以内を使用する。
【0061】
利用可能な計算デバイスにおけるモデルの実行時間速度を推定した場合、目標の完了時間要件を満たす推定ジョブ完了時間を提供する選択が行われる。このような選択では、必要以上に高速の計算デバイスの使用を回避しながら、完了期限を満たすように計算デバイスを選択する。
【0062】
デバイスの選択において、集約ポイントと計算デバイスとの間のネットワーク遅延がさらに考慮される。遅延が長引くと、計算中断と、データ分散中断と、データを再送して潜在的損失を克服する必要とを引き起こす可能性がある。これは、推定完了時間に影響を与える可能性がある。目標とするジョブが設定時間又はその前に完了するか、あるいは、他の基準を満たす場合、ネットワーク遅延からの影響の統計的推定は、デバイスの選択に含まれてもよい。
【0063】
また、計算デバイスの位置をデバイスの選択において付加的に考慮してもよい。計算デバイスの可用性の検証の一環として、デバイス位置をクエリーし、現在位置を記録する。ジョブ提出者は、ジョブデータを送信できる場所を制限してもよい。例えば、ある種の機密情報は、出力制限（エクスポートコントロール）の対象となる。また、計算デバイスの位置の制限は、利用可能な計算デバイスをフィルタリングして選択するために使用されてもよい。
【0064】
ジョブに使用される計算デバイス１１５のセットを選択し、かつデータチャンクを割り当てた後、モデルと、実行のために、選択された計算デバイス１１５に割り当てられたデータチャンクと、を含むペイロードが用意される（ステップ７２４）。
【0065】
ペイロードデータの分散は、ネットワーク接続を介して完全かつ凝集のペイロードを送信する形式であってもよい。所定の計算デバイス１１５によって実行される計算データのセット全体を予め送信することができ、ペイロード分散中に指定されたデバイスの間において、初期ジョブを分散している間に、ワークロードの全てのデータが分散される。これは、初期ペイロード分散を完全な計算ジョブに対して行うことができるという利点を有する。代わりに、特に所定の計算デバイス１１５が限られたストレージを有する場合、デバイスは、必要に応じて、所定の計算ワークロードに対して、複数のペイロードチャンクを受信あるいはフェッチするように構成されていてもよく、チャンクは、順次取得される。例えば、１つのペイロードチャンクに利用可能なストレージを有するデバイスには、３つのペイロードチャンクが割り当てられ、処理のために提供された初期チャンクのみを有してもよい。既存のチャンクが完了した場合、あるいは、管理プラットフォームが、データチャンクの処理が完了した表示に応答して、例えば、完了したチャンクの処理データを受信後に、既存のチャンクを排除した場合、デバイスは、次に続くチャンクを自動的に要求する。また、他の方法を使用してもよい。以下、モデル及びデータを分散する特定の分散方法について、更に説明する。
【0066】
モデル及びデータチャンクを計算デバイスに送信する前に、選択された計算デバイス１１５への接続を行って準備を確認する（ステップ７２６）。計算ワークロードを実行するのに十分なメモリ及び利用可能な他のリソースが存在することを検証することにより、準備を決定する。バッテリー電源式デバイスに対して、計算ワークロードを実行するバッテリー電力が十分であるか否かという判断を利用してもよい。デバイスが準備できていない場合、デバイスを拒否し、別のデバイスを要求する（ステップ７２８，７３０）。デバイスの交換には、少なくとも部分的に再割り当てを実行する必要がある。また、リソースの予約が行われていない場合、現時点で次回のジョブに使用されるリソースを予約するように各計算デバイス１１５に指示がなされる。デバイスの準備ができている場合、モデル及びデータペイロードが配信される（ステップ７３２）。配信を阻止するエラーが繰り返された場合、計算デバイスを拒否して交換する（ステップ７３４）。
【0067】
一実施例において、異なる転送機構を使用して、選択された計算デバイス１１５に管理プラットフォーム１１０から、計算モデル及び割り当てられたデータチャンクを送信する。各転送機構は、計算デバイス１１５において管理プラットフォーム１１０に、対応するソフトウェアエンジン又はエージェントを有し、送信を容易にする。第１の転送機構は、ペイロードをエッジデバイスに配信し、エッジデバイス内で動作してペイロードを抽出し実行するように設計された従来のエッジコンピューティングソフトウェア、例えば、管理プラットフォーム１１０におけるペイロードマネージャ２１５、計算デバイスにおけるペイロードサービス４１０の形式であってもよい。第２の転送機構は、データチャンクの転送、より一般的なイベント駆動、及び計算デバイスと管理プラットフォームとの間の他のメッセージングのために使用される合理化メッセージブローカーサービス、例えば、管理プラットフォーム１１０におけるメッセージングエンジン２２０及び計算デバイスにおけるメッセージングエンジン４０６であってもよい。個別の転送機構が使用されるが、主にアプリケーション層と、場合によってはプロトコル層で相違し、同じ下位通信層を使用して、ネットワーク１０５を介して、指定されたネットワークアドレスに対してデータを送受信する。
【0068】
第１の転送機構の適切なプラットフォームは、オープンホライズン（Ｏｐｅｎ Ｈｏｒｉｚｏｎ）（ＯＨ）プラットフォームである。第２の転送機構の適切なメッセージブローカーサービスは、アパッチカフカ（Ａｐａｃｈｅ Ｋａｆｋａ）（登録商標）である。管理プラットフォーム１１０におけるＯＨ管理ハブは、計算ノード１１５にインストールされたエッジサービス４１１として機能するＯＨエッジエージェントと通信するために、ペイロードマネージャ２１５として使用される。計算ノード１１５におけるＯＨエッジエージェント４１１は、計算モデルをＯＨエッジサービスに提供し、ＯＨエッジサービスは、計算ノードにおいてペイロード処理エンジン４１２として動作し、提供されたデータにおいてモデルを実行する。ＯＨプラットフォームは、配信パッケージにデータを含めることができるが、モデルに適用するデータチャンクは各計算デバイスにより異なるため、各計算デバイスは、個別のパッケージを必要とし、各パッケージは、独自の計算モデルのコピーを有する。所定のジョブに使用される計算デバイスの数が増加するにつれて、システムプロセッサ及びメモリリソースを消費する割合が増加する。また、配信プロセスにより、同じジョブ全体を継続しながら、１つのデバイスからデータチャンクを再び割り当てることが煩雑になる。
【0069】
この実施例において、計算モデルを含むがデータを含まない単一のパッケージが生成され記憶される。続いて、ＯＨなどの第１の転送機構を使用して、選択された計算デバイスのそれぞれにパッケージが送信される。第２の転送機構を使用して、計算デバイスのそれぞれに割り当てられたデータチャンクを計算デバイスのそれぞれに転送する。計算デバイスにおけるアプリケーションソフトウェア１４０の追加機能は、データチャンクを受信してメモリに記憶するため、エッジサービスは、受信された計算モデルにデータを適用することができる。同様に、計算デバイスからの計算結果を管理プラットフォームに返信するために第２の転送機構を使用することができる。
【0070】
図８のフローチャートを参照しながら、計算デバイスを選択し、データを複数の計算デバイスに分解する実施例について、より詳細に説明する。最初に、利用可能なデバイスのリストを作成する（ステップ８０２）。続いて、所望の最適化に基づいて、リストをソートする。ストレージ最適化された分解のために、利用可能なデータストレージのサイズに基づいて、デバイスのリストの順序付けを行い（ステップ８０４）、ペイロードアプリケーションに使用可能なストレージをリストから決定する（ステップ８０６）。十分なストレージがあることを確保するために、例えば８０％といった、実際の利用可能なストレージの割合のみが考慮されるので、デバイスが１ＧＢの実際の利用可能なストレージを有していれば、ペイロード割り当てに対して考慮されるのは、０．８ＧＢだけとなる。
【0071】
作業用のＲＡＭ及びＣＰＵのタイプ、速度、又は現在のジョブのベンチマークデータに基づく推定データ処理速度などの他の制約は、デバイスの選択に使用される。例えば、以下の点を考慮して、モデルの実行への適性に基づいてデバイスをランク付けする。すなわち、ＧＰＵがあるか又はＣＰＵのみがあるか否かと、その違いがジョブの実行に影響を与えるか否かと、モデルの実行により、プロセッサの要求が、計算デバイスの登録期間又は他の時間に設定可能な特定の閾値を超えるか否かと、デバイスに割り当て可能であって、設定された残余容量のデバイス閾値を超えないデータペイロード全体の割合と、ネットワーク遅延と、である。また、データチャンクサイズも選択される（ステップ８０８）。ユーザによって提供された初期ジョブ情報に基づいて、ジョブとともにアップロードされたファイル若しくはデータセグメントのサイズ、又はその他の手段によって、チャンクサイズが決定される。
【0072】
ソートされたリストから計算デバイスを順に選択し、入力データのチャンクをデバイスに割り当て、選択されたデバイスに送信されるペイロードに追加する（ステップ８１０～８１４）。全てのデータチャンクが割り当てられるまで、デバイスを順番に考慮する（ステップ８１６～８１８）。所定のバッファ、例えば、１０％又は１５％のバッファを有して、目標期限の前に最終的な割り当てを完了させるために、割り当ては、各計算デバイスに対して推定されるベンチマークデータ処理速度を考慮する。ストレージを最適化する場合、選択されたデバイスに一度の配信で割り当て可能なデータチャンクの最大数を選択する。例えば、データの複数のチャンクを最初に送信する場合には、記憶可能であり、かつ出力データを記憶する余地があるチャンクの最大数を選択する。レコードを分割しないように、データチャンクを割り当てる。例えば、レコード長が１Ｋ（１０２４バイト）であり、５０００バイトが利用可能である場合、４０９６バイトのデータのみを割り当てる。また、まず最も低速のデバイスを使用し、低速のデバイスが適していない他のジョブに利用できる、より高速のデバイスを残すように、デバイスの選択を行う。このプロセスは、選択された計算デバイスのいくつかが使用されない可能性があることに留意すべきである。そのような場合、後続のジョブで使用するために計算デバイスを解放することができる。選択されたデバイス全てにデータが割り当てられ、かつ追加データが依然として利用可能である場合、仮想デバイスに適用可能なコンテナと、まだなされていなければ、起動されたデバイスとに、残りのデータを割り当てる（ステップ８２０）。
【0073】
割り当てプロセスにおいて、データを直接割り当ててペイロードを作成するのではなく、代わりに、初期分解プロセスは、所定のデバイスに割り当てられるデータチャンクの数を決定する。続いて、全ての割り当てが完了した後に、実際のデータチャンクが割り当てられる。実際のデータチャンクは、所定のデバイスによって処理されるように割り当てられる。割り当てられたデータチャンクを一括して送信してもよい。データチャンクを経時的にストリーミング配信する場合、割り当てられたデータチャンクの数と、次のチャンクの送信必要時の特定チャンクの割り当てとが計算デバイスに通知される。これにより、必要可能性のある計算デバイスを再度割り当てることが簡略化される。
【0074】
個々のデバイスをサイズ決定する実施例において、計算デバイスは、２ＧＢのネイティブストレージと１ＧＢのディスク開始空き容量を有していてもよい。利用可能な容量は、データ出力及び予約のためのバッファによって低減される。２０％のバッファは、８００ＭＢのディスク容量をもたらす。モデル及びアルゴリズム記憶要件を５ＭＢとすると、７９５ＭＢのストレージが入力データに利用可能になる。
【0075】
デバイスの選択の実施例において、計算ワークロードは、２５６ＭＢのモデルと、合計１ＧＢのデータペイロードと、を含む。システムは、特定のペイロード要件に基づいて、ワークロードのサポート可能性を決定し、ペイロード要件は、計算モデル又はアルゴリズムの最小サイズ要件と、デバイスの得られるデータストレージ可用性との両方を含んでもよい。所望のパラメータを最適化するために、利用可能なデバイスから、データの部分及びモデルが分散される。モデルをサポートするのに十分なストレージを有さないデバイスは選択されない。同様に、最小サイズのデータチャンク及びデータ処理の結果を記憶するのに十分なメモリを有さないデバイスも選択されない。利用可能なストレージに基づいて、データチャンクを残りのデバイスから分散する。
【0076】
リソースの可用性及びペイロードチャンクの割り当てを示すデバイスの表
上記表において、最少量の利用可能なストレージを有さないデバイスは選択されない。所定のワークロードに対して最適と見なされるＲＡＭ量を有するノードデバイスを識別するために、リストはフィルタリング済みである。
【表1】
【0077】
図９は、計算デバイス１１５のアプリケーションソフトウェア１４０の動作の概略的なフローチャートである。前述のように、計算デバイス１１５は、計算モデルを含むペイロードを受信する（ステップ９０２）。計算モデルを、例えば、ストレージ４２０に記憶する（ステップ９０４）。また、計算モデルに適用されるデータチャンクを受信し（ステップ９０６）、例えば、ストレージ４２５に記憶する（ステップ９０８）。実行に応じて、ペイロードサービス４１０に送信されたペイロードの一部として、あるいは、個別のメッセージングサービス４０６を介して、データチャンクを初期バッチで受信してもよい。また、アプリケーションソフトウェア１４０は、追加データチャンクが必要であると決定し、例えば、メッセージングサービス４０６を介して、管理プラットフォーム１１０に要求を発行する。ペイロード処理エンジン４１２は、データチャンクをモデルに適用して、結果を、例えば、ストレージ４３０に記憶する（ステップ９１０）。続いて、計算の結果を管理プラットフォーム１１０に返信する（ステップ９１２）。
【0078】
結果は、例えば、単一のデータセットの処理が完了するたびに、間欠的に返信され、あるいは、複数の処理済みのデータチャンクからの結果を、計算デバイスに蓄積して保存し、バッチとして返信する。結果は結果パッケージで返信され、結果パッケージは、管理プラットフォームが結果を既知の計算ワークロードと関連付けるために使用する計算ワークロード識別子を含む。セキュリティのために、識別は、結果設定レベルで行われてもよいが、データ所有者に関して匿名化される。また、データチャンク及び処理結果をより安全に送信するために暗号化されてもよい。
【0079】
各データチャンクは、独自の一意識別子を有することができ、そのチャンクに対して返されたデータ処理結果で参照される。また、識別子は、ジョブからの結果のセットを適切な順序で配置するために使用される。非系列データの場合、計算ワークロード識別子は、なおも、返信又は生成結果を、既知の計算ワークロード要求と関連付けることができる。
【0080】
計算デバイス１１５におけるアプリケーションソフトウェア１４０はまた、デバイス健康を監視して、割り当てられたワークロードが完了する速度又は完全に完了する能力に影響を及ぼしそうな状態を検出することができる。図１０を参照すると、アプリケーションソフトウェア１４０における健康リソース監視モジュール４４０は、ワークロードを処理している間に、システム状態を定期的にポーリングするか又は監視する（ステップ１００２）。健康監視モジュールは、計算デバイスのオペレーティングシステム、ファームウェア及び／又はハードウェアに内蔵されたネイティブ健康監視機能に依存し、ネイティブ機能が引き金となる関連する中断に応答する。監視されるか又は中断によって信号で伝えることが可能な状態は、ＣＰＵ温度、メモリ不足又は利用可能なストレージ、バッテリー充電不足を含む。健康状態を検出した場合（ステップ１００４）、アプリケーションソフトウェア１４０は、その状態に関する健康警報メッセージを管理プラットフォーム１１０に送信する（ステップ１００６）。それに応答して、管理プラットフォーム１１０は、リソースの低減を考慮して、計算デバイスに割り当てられたデータチャンクの推定完了時間を再評価し、目標の完了期限又は他の性能指標を見逃すことなく、デバイスに対するデータチャンクの割り当てを維持できるか否かを決定する。また、計算デバイス１１５の実行速度、利用可能なメモリ又は別の必要なリソースが十分ではなくなった場合、問題のある計算デバイスに割り当てられたデータチャンクの一部又は全部を、所定の計算ジョブを実行するために既に選択されたデバイスである異なる計算デバイス、あるいは、このジョブにまだ使用されていない別の計算デバイスに、再び割り当てることができる。ワークロードを再び割り当てる必要が生じた場合、ワークロードは、デバイスを識別してその部分を割り当てる目的で新しいジョブのワークロードとして取り扱われてもよい。ワークロードを再び割り当てるためのデバイスの選択は、新しいジョブに割り当てるデバイスの選択よりも優先される。登録した計算デバイスが利用可能ではない場合、仮想デバイスを起動することができる。
【0081】
また、デバイスがオフラインになった場合、あるいは、デバイスが健康警報を受信しなくても想定されたレベルで実行していない場合、所定のデバイスに割り当てられたワークロード部分を再度割り当てる必要が生じる。例えば、計算デバイスとのネットワーク接続が長時間にわたって失われている場合、あるいは、デバイスのソフトウェア又はハードウェアの問題により、パフォーマンスが低下しているにもかかわらず、まだ報告されていない場合がある。所定の計算デバイスがネットワーク接続を回復しない、あるいは、結果ペイロードを完了予定期限までに返信しない場合、デバイスは、ジョブ要求を完了するために利用可能でないと見なされる。ストリーミングプロトコルを介してデータをデバイスに配信している場合、デバイスは、試みられたペイロードの配信を数回再試行した後、ジョブ要求を完了するために利用可能でないと見なされる。
【0082】
多くのタイプのエッジノードが一時的なネットワーク接続を維持すると仮定すると、システム１００は、一定時間にわたって、デバイスを接続切断状態に維持し続ける。許容接続切断時間は、計算デバイスがワークロードを実行するためにかかる予想時間に依存してもよい。この推定は、１つ以上のデータチャンクが所定の計算デバイスに提供された時刻、データチャンクのサイズ、及び計算デバイスのベンチマーク由来処理速度に基づいて行われる。また、オフライン許容時間は、ペイロードの配置前に既知であるデータペイロード配信方法に含まれてもよい。
【0083】
図１１は、管理プラットフォームにおいて、定期的に又は継続的に又は必要に応じて非周期的に実行可能な、健康状態監視機能の概略的なフローチャートである。計算デバイス１１５の予測データ処理速度を使用して、いつ計算デバイスから結果を受信すべきかを決定する（ステップ１１０２）。実行時間が経過していない場合（ステップ１１０４）、任意で、次のデバイスをチェックする（ステップ１１０６）。次に、デバイスの可用性及び状態をチェックする（ステップ１１０８）。計算デバイスにクエリーして健康状態情報を返信すること、及び／又は最近受信されたデータをチェックすることとを含んでもよい（ステップ１１０８）。計算デバイスを利用できない時間が最大許容時間を超える場合（ステップ１１１０）、デバイスが故障したと判断される（ステップ１１１２）。新しいデバイスを要求し、未処理のデータチャンクを交換デバイスに割り当て、新しいデバイスをクラスタに追加し、ペイロードを配置する（ステップ１１１４）。デバイスが利用可能である場合、健康をチェックする（ステップ１１１６）。健康が損なわれていない場合（ステップ１１１８）、次の計算デバイスをチェックする。健康が異常なし（ＯＫ）ではない場合、計算ワークロードの再起動が可能であるか否かを含めて、影響を考慮する（ステップ１１２０）。再起動が不可能である場合、あるいは、割り当てられたデータチャンクを完全に又は要求された時間内に完了できない健康状態である場合、データチャンクの一部又は全部を異なるノードに再び割り当てる（ステップ１１１４）。
【0084】
場合によっては、ワークロードの処理に使用されている計算デバイスは、他の目的に使用されるためにワークロードに割り当てられたリソースを再取得する必要がある。例えば、計算デバイスがラップトップコンピュータである場合、ラップトップコンピュータのユーザは、リソース集約プログラムを実行する必要がある。一実施例において、これが発生するのは、エンドユーザアプリケーションである。
【0085】
外部デバイスのユーザが、管理プラットフォーム１１０を登録し、ユーザのデバイスを計算デバイス１１５として利用可能にするアプリケーションソフトウェア１４０をインストールして、そのデバイスをアプリケーションソフトウェア１４０によるジョブの実行に使用する場合、金銭上の又は他の補償を受ける。補償の尺度は、所定の計算デバイスが処理するデータの量に基づくものであってもよい。
【0086】
ワークロードが割り当てられた計算デバイス１１５のユーザは、ワークロードが実行されると予定される時間に、計算デバイスを他の目的に使用する必要が生じる可能性がある。そのため、ワークロードの実行に利用可能なリソースが低減され、ワークロードのデータ処理速度が低下する。計算デバイス１１５におけるシステム１００の一部として使用されたアプリケーションソフトウェア１４０は、システム活動を監視して、いつそのようなリソース低減が発生するか、及び、リソース低減が所定の閾値よりも大きいか否かを検出する。タスクの影響の尺度は、利用可能なＣＰＵサイクルが所定量減少するか否かに基づくものであってもよい。また、影響は、ワークロードの計算結果を記憶するのに利用可能なメモリの減少に因る可能性があり、例えば、１つのチャンク、処理するために計算デバイスに記憶された総数のチャンク、あるいは、全てのチャンクが配信されていない場合の計算デバイスに割り当てられた総数のチャンクといった、関連数のデータチャンクを処理した結果を記憶するのに利用可能なメモリが不足することである。また、リソースの低減が一時的であるか又は一時的であると予想されるかを考慮することができる。
【0087】
リソースの低減が所定の期間を超えて所定の閾値を上回る場合、健康警報に類似するものとして扱われ、計算デバイス１１５から管理プラットフォーム１１０にリソース変化（例えば、ＣＰＵの実質的な低速化、メモリ不足など）を示すメッセージが送信される。それに応答して、管理プラットフォーム１１０は、変化を評価し、シグナリングデバイスから異なる計算デバイスへデータチャンクを再度割り当てる要求に対して十分な影響であるか否かを決定し、そうであれば、健康警報の処理と同じように適切な操作を行う。
【0088】
また、計算デバイス１１５におけるアプリケーションソフトウェア１４０は、システム１００との接続切断の活動など、計算デバイス１１５における他の活動を監視して、実際の又は潜在的なリソース低減が、オペレーティングシステムに必要な活動ではなく、新しいアプリケーション又はタスクの起動などのユーザ操作に起因するか否かを決定する。低減がユーザ操作に起因し、特に、そのような低減が、割り当てられた計算ジョブの動作に対して、低減が非常に大きいことを示す閾値を超えて影響する場合、計算デバイス１１５のディスプレイにメッセージを出力して、その操作を継続するには、アクティブなワークロードに割り当てられるリソースを使用する必要があることをユーザに通知する。一実施例において、アプリケーションソフトウェア１４０は、ユーザがタスクを継続すべきことを肯定的に示すまで、新しいリソース消費タスクの優先度を一時的に中断又は低減するように作動する。ユーザがリソース消費タスクを継続すると、特定の計算デバイスを利用可能にするためにユーザが受けるべきいかなる補償に対しても、金銭上又はその他のペナルティが課される。
【0089】
なお、計算デバイス１１５がワークロードの処理を完了すると、計算結果が管理プラットフォーム１１０に返信される。アプリケーションソフトウェア１４０は、ネットワーク１０５を介して管理プラットフォーム１１０に結果を直接送信する。しかし、直接ネットワーク接続が利用できない場合がある。図１を参照すると、デバイス１１５ａは、データリンク１０６を介してネットワーク１０５に接続され、データリンク１０６は、例えば、インターネットアクセスを有するノードとの、セルラーデータインターネット接続又はＷｉ－Ｆｉ（登録商標）接続などであってもよい。時には、ネットワーク接続１０６は、デバイス１１５ａに利用できない場合がある。ネットワーク１０５への接続が利用可能ではなく、デバイス１１５ａなどの計算デバイスがワークロードを完了しており、管理プラットフォーム１１０に返信する計算データを有する場合、デバイス１１５ａは、直接Ｗｉ－Ｆｉ（登録商標）接続、又はＢｌｕｅｔｏｏｔｈ（登録商標）、Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）を使用した接続、又はＮＦＣプロトコルなどの代替データ接続を使用して、計算デバイス１１５ｂなどの別の周辺デバイスとの接続を確立する。完了した計算結果を計算デバイス１１５ａから計算デバイス１１５ｂに転送する。そして、計算デバイス１１５ｂは、デバイス１１５ａからの結果を管理プラットフォーム１１０に転送する。
【0090】
そのような接続の確立を支援するために、計算デバイスにおけるアプリケーションソフトウェア１４０は、通信範囲内において他の計算デバイスにより発見、認識されるように、デバイスにその存在をブロードキャストさせてもよい。例えば、計算デバイス１１５ｂは、ＢＬＥフォロワーデバイスとして、接続の可用性を示すＢＬＥ広告メッセージを定期的に送信する。また、広告メッセージは、計算デバイス１１５ｂがアプリケーションソフトウェア１４０を起動中であることを示す局所名（ローカルネーム）などのペイロードデータを含んでもよい。２つのデバイス間のデータ接続を確立するために、フォロワーデバイスは、接続に利用可能であることを示す広告メッセージを送信する。中央デバイスは、広告パケットをスキャンする。適切なフォロワーデバイスからの広告パケットを検出した場合、リーダーデバイスは、フォロワーデバイスに接続要求パケットを送信し、フォロワーが適切に応答すると、データ接続を確立する。
【0091】
ＮＦＣデータ接続は、かなり高速であるが、約１０ｃｍなどの短距離でのみ、データリンクを提供する。ＮＦＣリンクを介する接続のオプションにより、個人は、計算結果データの転送もしくは計算ジョブの転送が必要とされる１つの計算デバイス１１５を、第２の計算デバイスに近接して配置することができ、デバイス内のアプリケーションソフトウェア１４０は、転送を実行する。これが有用であるシナリオは、低バッテリーレベル状態になったモバイルデバイスにおいてジョブが実行されている場合である。低バッテリー計算デバイスは、データ及び／又は計算ジョブを第２の計算デバイスに転送するために十分に給電された第２の計算デバイスに隣接して配置される。
【0092】
図１２Ａ～１２Ｃは、データ及び／又は割り当てられた計算ジョブを１つの計算デバイスから別の計算デバイスに転送することをもたらす、警報監視プロセスを示すフローチャートである。デバイス１１５ａにおける健康リソースモニター４４０は、状態及び／又はデバイス生成警報を監視し、それに応答して、スーパーバイザサービス４０５に通知する。また、ペイロード処理エンジン４１２からの警報を監視する（ステップ１２０２）。警報を受信した場合、応答は、警報タイプに依存する（ステップ１２０４）。ワークロード完了警報の場合、ネットワークデータ送信の可用性のチェックを行う（ステップ１２０６）。データネットワークが利用可能である場合、結果データを返信する（ステップ１２０７）。そうでない場合、結果データをピアデバイスに転送するプロセスを開始する（ステップ１２０８）。システムは、オフロードプロセスを開始する前に、閾値時間を超えてネットワークデータが利用できないことを維持する要求を行ってもよい。
【0093】
デバイス１１５ａにおけるソフトウェアは、適切なソフトウェアを実行しているエッジ計算デバイス、例えば、アプリケーションソフトウェアを有するデバイス１１５ｂの存在を定期的にチェックして、データ転送を可能にする（ステップ１２１０）。Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＮＦＣなどの１つ以上の利用可能なネットワークについてチェックを行う。また、通常のネットワーク状態のチェックを行ってもよく、ネットワーク接続を再確立した場合、計算データを返信する通常プロセスを再開する（ステップ１２１２，１２１４）。
【0094】
適切なデバイスが見つかった場合、デバイスへの接続を確立する（ステップ１２１６）。接続されたデバイス１１５ｂの状態をクエリーし、これは、管理プラットフォーム１１０からのデバイスクエリーと同様に行うことができ、デバイス１１５ｂが計算データの受信に十分なストレージを有するか否かを決定する（ステップ１２１８，１２２０）。クエリーされたデバイスにおけるアプリケーションソフトウェア１４０は、例えば、自身の計算ジョブに関連して、まだ使用のために予約されていないか又は割り当てられていない利用可能なストレージを決定し、そのデータを返信するか、或いは、クエリーされたデバイスは、利用可能で割り当てられたストレージに関するより一般的なデータ、及び、開始デバイスで決定されたストレージの量を返信する。
【0095】
十分なストレージが利用可能ではない場合、別のデバイスへの接続が試みられる。十分なストレージが利用可能である場合、計算データを有するペイロードを用意し、データと共に送信して、ペイロードのコンテンツ及びその発信元のデバイスを識別する（ステップ１２２２）。また、管理プラットフォーム１１０にデータハンドオフを通知するために、管理プラットフォーム１１０へのメッセージを配信のためにキューイングする（ステップ１２２４）。各計算デバイスは、自身のＩＤを有する。データハンドオフの一環として、計算デバイス１１５ａは、自身のＩＤを、接続された他の計算デバイス１１５ｂに転送する。この情報は、その後にデバイス１１５ｂによって管理プラットフォーム１１０に転送されるデータの一部として含まれる。これにより、管理プラットフォーム１１０は、行われた転送を追跡することができる。デバイス１１５ｂにネットワーク接続の問題がある場合、ある時点で、自身のプロセスを開始してデータを転送してもよい。デバイス１１５ｂは、デバイス１１５ａからのデータが管理プラットフォームに返信される（もしくは、別のデバイス１１５に転送される）前に、デバイス１１５ａへの接続を試みてもよい。計算デバイスが、そこから最初にデータを取得したデバイスにデータを返信している状態にある場合、ターゲットデバイスは、クエリーされ、管理プラットフォーム１１０にデータを返信することができるネットワーク接続がある場合にのみ、ネットワーク状態と、そのデバイスに返信されたデータとを示すので、データ返信に適切なネットワーク接続のないデバイス間にデータを繰り返して渡すことが回避される。
【0096】
警報がデバイス健康警報又はリソース警報である場合、プロセスは同様である（ステップ１２０４）。ネットワークデータ接続が利用可能である場合（ステップ１２５０）、メッセージを管理プラットフォーム１１０に送信して、この問題を指示する（ステップ１２５８）。ネットワーク接続がアクティブであると仮定すると、管理プラットフォーム１１０は、計算ジョブの再割り当てについて管理する。
【0097】
管理プラットフォーム１１０へのネットワーク接続が利用可能ではない場合、別の計算デバイスへの計算ジョブワークロードの転送を開始するプロセスを開始する（ステップ１２５０，１２５２）。デバイス１１５ａにおけるソフトウェアは、適切なソフトウェアを実行しているエッジ計算デバイス、例えば、アプリケーションソフトウェアを有するデバイス１１５ｂの存在を定期的にチェックして、データ転送を可能にする（ステップ１２５４）。また、通常のネットワーク状態のチェックを行い、ネットワーク接続を再確立した場合、警報を管理プラットフォームに通知する（ステップ１２５６，１２５８）。
【0098】
適切なデバイス１１５ｂが見つかった場合、デバイスへの接続を確立する（ステップ１２６０）。接続されたデバイス１１５ｂの状態をクエリーし、これは、管理プラットフォーム１１０からのデバイスクエリーと同様に行うことができ、デバイス１１５ｂが計算データの受信に十分なストレージを有するか否かを決定する（ステップ１２６２，１２６４）。十分なストレージが利用可能ではない場合、別のデバイスへの接続を試みる。デバイス１１５ｂがワークロードのペイロードを受信できる十分なストレージを有する場合、それを、適切なデバイス及びジョブＩＤ情報と共に、デバイス１１５ａからデバイス１１５ｂに送信し、ネットワーク接続を再確立するときに転送を通知するために、管理プラットフォームへのメッセージをキューイングする（ステップ１２６６，１２６８）。
【0099】
デバイス１１５ｂがジョブを実行していない場合、デバイス１１５ａからのモデル及びデータをデバイス１１５ｂに送信し、デバイス１１５ｂは、管理プラットフォーム１１０からジョブを直接受信した場合と同様にモデル及びデータを処理する。また、デバイス１１５ｂは、管理プラットフォーム１１０にメッセージを伝達して、転送されたジョブを通知する。一般に、デバイス１１５ｂが既に計算ジョブを実行している場合、ジョブ転送を行わない。しかし、デバイス１１５ｂが、デバイス１１５ａと同じ計算モデルだが、データチャンクのみが異なるジョブを実行している場合、転送されたデータチャンクのみ（又は、データチャンクを要求に応じてストリーミング配信する場合には、データチャンクＩＤのみ）の転送が行われる。デバイス１１５ａは、最初にデバイス１１５ｂを予備として保持しておき、現時点でジョブが割り当てられていない別の計算デバイスを探すことができる。デバイス１１５ｂが処理すべきデータチャンクの数を増やすと、デバイス１１５ｂによるジョブの完了時間に影響があると思われる。しかし、デバイス１１５ａがそのジョブを有意義な方法で処理できないと推定されるため、転送により、処理を継続することができ、管理プラットフォーム１１０は、その後、デバイス１１５ａのデータチャンクをデバイス１１５ｂから別の適切な計算デバイスに転送する。
【0100】
ハンドオフ後、計算デバイス１１５ａは、ネットワーク接続が回復しているか否かを定期的にチェックする（ステップ１２２６，１２２８）。接続が回復した場合、管理プラットフォーム１１０に連絡して、ハンドオフされたジョブ／ジョブ結果の状態をチェックする（ステップ１２３０）。別のデバイスでジョブが完了したことを管理プラットフォーム１１０が示す場合（ステップ１２３２）、デバイス１１５ａは、ハンドオフが発生したデバイス１１５ｂに連絡して、ハンドオフの状態をチェックする（ステップ１２３４）。デバイス１１５ａ／１１５ｂ間の接続がアクティブではなくなった場合、再接続を試みることができる。デバイス１１５ｂが圏外にあるか又は到達できない場合、状態チェックは中止される。
【0101】
データ結果ハンドオフ及びジョブ処理ハンドオフの両方のシナリオにおいて、計算デバイス１１５ａがネットワークに接続されていない間に、管理プラットフォーム１１０は、計算デバイス１１５ａがオフラインであると決定し、ワークロードを別の計算デバイスに既に転送している可能性が生じる。予定された結果をデバイス１１５ａから既に受信したことを管理プラットフォーム１１０が示す場合、転送されたデータを削除すること／転送されたジョブをキャンセルすることをデバイス１１５ｂに通知する。管理プラットフォーム１１０がジョブ結果を受信していない場合、デバイス１１５ｂに信号で伝えて、転送された結果データを返送することを要求し、デバイス１１５ａは、それを管理プラットフォーム１１０に返送する。同様に、例えば、計算デバイス１１５ｂがデータチャンクを現在処理しており、かつ処理すべき追加チャンクが残っている場合、計算デバイス１１５ａは、転送されたワークロードの全部又は一部を返送するように要求することができる（ステップ１２３６～１２４２）。計算結果データ又はワークロードを戻り転送することは、初期ハンドオフプロセスと同様に行うことができる。
【0102】
図１３は、クラウドコンピューティング実装におけるシステム１００の様々な要素間の通信及びデータの流れを示す概略図である。Ａｄｍｉｎエンジン２０５は、ウェブサーバ２３０と組み合わせて示される。同様に、クラウドプラットフォーム内の様々な他のモジュール及びエンジンは、異なる方式で組み合わせられて、同じ全体機能を提供する。ペイロードマネージャ２１５に接続されたＡｄｍｉｎエンジン２０５は、計算デバイスを登録し管理し、それらに関するサービスメタデータを公開するために使用される。ウェブサーバにより、ペイロードデータは、ペイロードコンテナストレージ２１３に記憶される。また、管理エンジン／ウェブサーバ２３０は、他のクラウドデータストレージにアクセスして、他のデータを記憶し検索する。
【0103】
ペイロードマネージャ２１５は、ペイロードコンテナストレージ２１３からのペイロードデータにアクセスし、ペイロードサービス４１０に接続して、計算モデルペイロードを計算デバイスに提供する。また、ペイロードサービス４１０への接続は、ペイロード処理状態をチェックし、他のペイロードインフラストラクチャタスクを扱うために使用される。管理エンジンからメッセージングサービス２３０への接続は、計算デバイス１１５と通信し、サービスに関するデータをプッシュ／プルし、データチャンクを計算デバイスに送信するために使用され、チャンクは、メッセージングサービス２２０によりペイロードコンテナストレージ２１３又は他のストレージから取得される。
【0104】
管理者１２０’は、ウェブサーバインタフェース２３０を介してシステムに接続し、ａｄｍｉｎエンジン２０５の機能、例えば、ユーザアカウント及び計算デバイスの作成及び管理にアクセスする。権限のある管理者もまた、メッセージングアプリを使用して、メッセージングサービス２２０を介して、システムにアクセスすることができる。ペイロードマネージャへの（直接、あるいは、ウェブサーバ２３０又はメッセージングサービス２２０などのフロントエンドインタフェースを介する）接続は、システムを適切なエッジノード計算デバイスに配置するために、パターン又はポリシー伴う、配置の管理及び計算ノードの登録に使用される。一般ユーザは、ウェブサーバ２３０を介してシステム１００にアクセスすることができる。ユーザリンクは、ユーザアカウントの作成並びに管理、エッジサービスおよび計算ペイロードの公開並びに管理、並びに、自身の計算ノードの登録／管理に使用される。
【0105】
本明細書は、本発明の様々な形態、実施形態及び実施例を開示し、記載する。特許請求の範囲に定義される本発明の趣旨及び範囲から逸脱することなく、当業者であれば、変更、追加及び修正を行うことができる。
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図12C】
【図13】
【国際調査報告】