実際のユースケースを通じて、エッジでの機械学習の謎を解き明かす

エッジ（Edge） は、クラウドやビッグデータセンターから遠く離れた、（エッジ）アプリケーションを実行できるコンピューターデバイス（エッジデバイス）がある場所を指す用語です。 エッジコンピューティングは、これらのエッジデバイスでワークロードを実行する行為です。 エッジでの機械学習（ML @ Edge）は、MLモデルをローカルで実行する機能をエッジデバイスにもたらす概念です。 これらのMLモデルは、エッジアプリケーションから呼び出すことができます。 ML @ Edgeは、生データがクラウドから遠く離れたソースから収集される多くのシナリオで重要です。 これらのシナリオには、特定の要件または制限がある場合もあります。

• 低遅延のリアルタイム予測
• クラウドへの接続が不十分または存在しない
• 外部サービスへのデータ送信を許可しない法的制限
• クラウドに応答を送信する前にローカルで前処理する必要がある大規模なデータセット

以下は、予測に使用されるデータを生成する機器の近くで実行されるMLモデルから恩恵を受けることができる多くのユースケースの一部です。

• セキュリティと安全 –自動ポートで大型機械が稼働する制限区域は、カメラによって監視されます。 人が誤ってこのエリアに入ると、安全機構が作動して機械を停止し、人を保護します。
• 予知保全 –振動センサーとオーディオセンサーは、風力タービンのギアボックスからデータを収集します。 異常検出モデルはセンサーデータを処理し、機器に異常があるかどうかを識別します。 異常が検出された場合、エッジデバイスは、ブレークをオンにしたり、発電機をグリッドから切断したりするなど、機器の損傷を回避するために、リアルタイムで不測の事態の測定を開始できます。
• 生産ラインでの欠陥検出 –カメラがコンベヤーベルト上の製品の画像をキャプチャし、画像分類モデルでフレームを処理します。 欠陥が検出された場合、製品は手動の介入なしに自動的に廃棄できます。

ML @ Edgeは多くのユースケースに対応できますが、安全で堅牢で信頼性の高い設計を実現するには、解決する必要のある複雑なアーキテクチャ上の課題があります。 この投稿では、ML @ Edge、関連トピック、およびAWSサービスを使用してこれらの課題を克服し、エッジワークロードでMLの完全なソリューションを実装する方法について詳しく学びます。

ML@Edgeの概要

ML @Edgeとモノのインターネット（IoT）に関してはよくある混乱があります。したがって、ML @ EdgeがIoTとどのように異なり、特定の場合に強力なソリューションを提供するために両者がどのように連携できるかを明確にすることが重要です。

ML @ Edgeを使用するエッジソリューションには、エッジアプリケーションとエッジデバイスで実行されるMLモデル（アプリケーションによって呼び出される）のXNUMXつの主要なコンポーネントがあります。 ML @ Edgeは、エッジデバイスのフリートにデプロイされたXNUMXつ以上のMLモデルのライフサイクルを制御することを目的としています。 MLモデルのライフサイクルは、クラウド側から開始できます（ アマゾンセージメーカーたとえば）。ただし、通常は、エッジデバイスでのモデルのスタンドアロン展開で終了します。 各シナリオでは、データ収集などの多くの段階で構成できるさまざまなMLモデルのライフサイクルが必要です。 データの準備; モデルの構築、コンパイル、およびエッジデバイスへの展開。 モデルのロードと実行。 ライフサイクルを繰り返します。

ML @ Edgeメカニズムは、アプリケーションのライフサイクルを担当しません。 そのためには、別のアプローチを採用する必要があります。 MLモデルのライフサイクルとアプリケーションのライフサイクルを切り離すことで、さまざまなペースでそれらを進化させ続けるための自由と柔軟性が得られます。 MLモデルを画像やXMLファイルなどのリソースとして埋め込むモバイルアプリケーションを想像してみてください。 この場合、新しいモデルをトレーニングして携帯電話にデプロイするたびに、アプリケーション全体を再デプロイする必要があります。 これは時間とお金を消費し、アプリケーションにバグをもたらす可能性があります。 MLモデルのライフサイクルを切り離すことで、モバイルアプリを一度公開し、必要な数のバージョンのMLモデルをデプロイします。

しかし、IoTはML @Edgeとどのように相関していますか？ IoTは、センサー、処理能力、ソフトウェアなどのテクノロジーが組み込まれた物理オブジェクトに関連しています。 これらのオブジェクトは、データを交換するために、インターネットまたは他の通信ネットワークを介して他のデバイスやシステムに接続されます。 次の図は、このアーキテクチャを示しています。 この概念は当初、エッジからデータを収集し、単純なローカル処理を実行し、その結果を、意思決定において人々や企業を支援する分析プロセスを実行するより強力なコンピューティングユニティに送信する単純なデバイスを考えるときに作成されました。 IoTソリューションは、エッジアプリケーションのライフサイクルを制御する役割を果たします。 IoTの詳細については、を参照してください。 モノのインターネット.

すでにIoTアプリケーションをお持ちの場合は、次の図に示すように、ML@Edge機能を追加して製品をより効率的にすることができます。 ML @ EdgeはIoTに依存していませんが、それらを組み合わせてより強力なソリューションを作成できることに注意してください。 これを行うと、単純なデバイスの可能性が高まり、後で処理するためにデータをクラウドに送信するよりも速く、ビジネスのリアルタイムの洞察を生成できます。

ML @ Edge機能を使用して新しいエッジソリューションを最初から作成する場合は、アプリケーションとMLモデルの両方のライフサイクルをサポートする柔軟なアーキテクチャを設計することが重要です。 この投稿の後半で、ML@Edgeを使用したエッジアプリケーションのリファレンスアーキテクチャをいくつか提供します。 ただし、最初に、エッジコンピューティングについて詳しく調べ、環境の制限に基づいて、ソリューションに適したエッジデバイスを選択する方法を学びましょう。

エッジコンピューティング

デバイスがクラウドまたはビッグデータセンター（ベース）からどれだけ離れているかに応じて、システムのパフォーマンスと寿命を最大化するために、エッジデバイスのXNUMXつの主要な特性、つまりコンピューティングとストレージの容量、接続性、および消費電力を考慮する必要があります。 次の図は、ベースからの距離に応じて、これらの特性のさまざまな仕様を組み合わせたXNUMXつのグループのエッジデバイスを示しています。

グループは次のとおりです。

• MEC（マルチアクセスエッジコンピューティング） –低または超低遅延と高帯域幅を特徴とするMECまたは小規模データセンターは、ML@Edgeがクラウドワークロードと比較して大きな制限なしにメリットをもたらすことができる一般的な環境です。 工場、倉庫、研究所などの5Gアンテナとサーバーは、エネルギーの制約が最小限で、インターネット接続が良好であるため、GPUとCPU、仮想マシン、コンテナー、ベアメタルサーバーでMLモデルを実行するさまざまな方法が提供されます。
• ニアエッジ –これは、モビリティまたはデータ集約が要件であり、デバイスに消費電力と処理能力に関するいくつかの制約がある場合ですが、遅延が高く、スループットが制限され、「エッジに近い」よりも高価ですが、信頼性の高い接続があります。 このグループには、モバイルアプリケーション、MLモデルを高速化するための特定のボード、またはMLモデルを実行する能力を備えたシンプルなデバイスが含まれます。
• 遠端 –この極端なシナリオでは、エッジデバイスには厳しい電力消費または接続の制約があります。 その結果、処理能力も多くの遠端シナリオで制限されます。 農業、鉱業、監視とセキュリティ、および海上輸送は、遠端デバイスが重要な役割を果たすいくつかの分野です。 通常はGPUやその他のAIアクセラレータを使用しない、単純なボードが一般的です。 これらは、単純なMLモデルを読み込んで実行し、予測をローカルデータベースに保存し、次の予測サイクルまでスリープするように設計されています。 リアルタイムデータを処理する必要のあるデバイスは、データの損失を防ぐために大きなローカルストレージを持つことができます。

課題

同じモデルとエッジアプリケーションを実行しているデバイスが数百または数千（場合によっては数百万）あるML@Edgeシナリオが一般的です。 システムを拡張するときは、サポートする必要のあるデバイスの数を管理できる堅牢なソリューションを用意することが重要です。 これは複雑なタスクであり、これらのシナリオでは、多くの質問をする必要があります。

• エッジにある一連のデバイスでMLモデルを操作するにはどうすればよいですか？
• MLモデルを構築、最適化して、複数のエッジデバイスにデプロイするにはどうすればよいですか？
• モデルをエッジでデプロイして実行しながら、モデルを保護するにはどうすればよいですか？
• モデルのパフォーマンスを監視し、必要に応じて再トレーニングするにはどうすればよいですか？
• 制限されたデバイスにTensorFlowやPyTorchなどの大きなフレームワークをインストールする必要をなくすにはどうすればよいですか？
• エッジアプリケーションでXNUMXつまたは複数のモデルを単純なAPIとして公開するにはどうすればよいですか？
• エッジデバイスによってキャプチャされたペイロードと予測を使用して新しいデータセットを作成するにはどうすればよいですか？
• これらすべてのタスクを自動的に実行するにはどうすればよいですか（MLOpsとML @ Edge）？

次のセクションでは、ユースケースの例とリファレンスアーキテクチャを通じて、これらすべての質問に対する回答を提供します。 また、調査した各シナリオの完全なソリューションを構築するために組み合わせることができるAWSサービスについても説明します。 ただし、AWSが提供するサービスの一部を使用してML @ Edgeソリューションを作成する方法を説明する非常に単純なフローから始めたい場合は、次の例を参照してください。

SageMakerを使用すると、データセットを簡単に準備し、エッジデバイスにデプロイされるMLモデルを構築できます。 と Amazon SageMaker ネオ、選択した特定のエッジデバイスに合わせてトレーニングしたモデルをコンパイルおよび最適化できます。 モデルをコンパイルした後、それを実行するために必要なのは軽いランタイムだけです（サービスによって提供されます）。 Amazon SageMaker エッジマネージャー エッジデバイスのフリートにデプロイされたすべてのMLモデルのライフサイクルを管理する責任があります。 Edge Managerは、最大数百万のデバイスのフリートを管理できます。 エッジデバイスのそれぞれにインストールされたエージェントは、デプロイされたMLモデルをAPIとしてアプリケーションに公開します。 エージェントは、必要に応じてモデルを再トレーニングするための新しいデータセットの監視または構築に使用できるメトリック、ペイロード、および予測の収集も担当します。 最後に、 AmazonSageMakerパイプライン、MLモデルを構築、最適化、およびデバイス群にデプロイするために必要なすべてのステップを備えた自動パイプラインを作成できます。 この自動化されたパイプラインは、人間の介入なしに、定義した単純なイベントによってトリガーできます。

ユースケース1

飛行機の製造業者が、生産格納庫内の部品やツールを検出して追跡したいとします。 生産性を向上させるには、生産の各段階でエンジニアが必要なすべての部品と適切なツールを利用できるようにする必要があります。 次のような質問に答えられるようにしたいと考えています。パートAはどこにありますか？ またはツールBはどこにありますか？ 複数のIPカメラがすでにインストールされており、ローカルネットワークに接続されています。 カメラは格納庫全体をカバーし、ネットワークを介してリアルタイムのHDビデオをストリーミングできます。

AWSパノラマ この場合、うまく収まります。 AWS Panoramaは、既存のIPカメラ群にコンピュータービジョン（CV）を追加して自動化できる、MLアプライアンスとマネージドサービスを提供します。 AWSパノラマを使用すると、既存のインターネットプロトコル（IP）カメラにCVを追加し、従来は人間による検査と監視が必要だったタスクを自動化できます。

次のリファレンスアーキテクチャでは、AWSパノラマアプライアンスで実行されているアプリケーションの主要なコンポーネントを示しています。 パノラマアプリケーションSDKを使用すると、カメラストリームからビデオをキャプチャし、複数のMLモデルのパイプラインで推論を実行し、コンテナー内で実行されているPythonコードを使用して結果を処理できます。 TensorFlow、PyTorch、TensorRTなどの一般的なMLライブラリからモデルを実行できます。 モデルの結果は、ローカルエリアネットワーク上のビジネスシステムと統合できるため、イベントにリアルタイムで対応できます。

このソリューションは、次の手順で構成されています。

1. AWSPanoramaデバイスを同じローカルネットワークに接続して設定します。
2. MLモデル（オブジェクト検出）をトレーニングして、各フレームのパーツとツールを識別します。
3. MLモデルから予測を取得し、各オブジェクトにトラッキングメカニズムを適用し、結果をリアルタイムデータベースに送信するAWSパノラマアプリケーションを構築します。
4. オペレーターは、データベースにクエリを送信して、部品とツールを見つけることができます。

ユースケース2

次のユースケースでは、歩行者の回避など、さまざまな状況でドライバーをサポートできる車両用のドライブレコーダーを作成していると想像してください。 AmbarallaのCV25ボード。 システムリソースが限られているデバイスでMLモデルをホストするのは難しい場合があります。 この場合、エッジデバイスに必要なアプリケーションコンポーネントを展開するための確立された無線（OTA）配信メカニズムがすでに整っていると仮定します。 ただし、モデル自体のOTAデプロイメントを実行できることで、アプリケーションのライフサイクルとモデルのライフサイクルを分離できるというメリットがあります。

Amazon SageMaker エッジマネージャー & Amazon SageMaker ネオ このユースケースに適しています。

Edge Managerを使用すると、MLエッジ開発者は、クラウドまたはエッジデバイスで同じ使い慣れたツールを簡単に使用できます。 モデルを本番環境に移行するために必要な時間と労力を削減すると同時に、デバイスフリート全体でモデルの品質を継続的に監視および改善できます。 SageMaker Edgeには、アプリケーションやデバイスのファームウェアに関係なく、フリートにモデルをデプロイするのに役立つOTAデプロイメントメカニズムが含まれています。 The EdgeManagerエージェント 同じデバイスで複数のモデルを実行できます。 エージェントは、間隔など、制御するロジックに基づいて予測データを収集し、それをクラウドにアップロードして、モデルを定期的に再トレーニングできるようにします。 SageMaker Edgeはモデルに暗号で署名するため、モデルがクラウドからエッジデバイスに移動するときにモデルが改ざんされていないことを確認できます。

Neoはサービスとしてのコンパイラであり、このユースケースに特に適しています。 Neoは、クラウドインスタンスとエッジデバイスでの推論のためにMLモデルを自動的に最適化して、精度を損なうことなく高速に実行します。 まず、次のいずれかで構築されたMLモデルから始めます。 サポートされているフレームワーク SageMakerまたはその他の場所でトレーニングを受けています。 次に、ターゲットハードウェアプラットフォームを選択します（のリストを参照してください） サポートされているデバイス）。 ワンクリックで、Neoはトレーニングされたモデルを最適化し、軽量のSageMakerEdgeランタイムを使用して実行できるパッケージにコンパイルします。 コンパイラーはMLモデルを使用して、クラウドインスタンスまたはエッジデバイスでモデルに利用可能な最高のパフォーマンスを抽出するパフォーマンス最適化を適用します。 次に、モデルをSageMakerエンドポイントとして、またはサポートされているエッジデバイスにデプロイし、予測を開始します。

次の図は、このアーキテクチャを示しています。

ソリューションワークフローは、次の手順で構成されています。

1. 開発者は、ダッシュカムに展開する必要のある最終的なモデルアーティファクトを構築、トレーニング、検証、および作成します。
2. Neoを呼び出して、トレーニング済みモデルをコンパイルします。
3. SageMaker Edgeエージェントは、Edgeデバイス（この場合はダッシュカム）にインストールおよび設定されます。
4. 署名されたモデルと、SageMakerEdgeエージェントが最適化されたモデルをロードして呼び出すために使用するランタイムを使用してデプロイパッケージを作成します。
5. 既存のOTA展開メカニズムを使用してパッケージを展開します。
6. エッジアプリケーションはSageMakerEdgeエージェントと対話して推論を行います。
7. エージェントは、モデルの監視と改良の目的で、アプリケーションからリアルタイムのサンプル入力データを送信するように構成できます（必要な場合）。

ユースケース3

顧客が風力タービンのメカニズム（ギアボックス、発電機、ローターなど）の異常を検出するアプリケーションを開発しているとします。 目標は、その場でローカル保護手順を実行することにより、機器の損傷を最小限に抑えることです。 これらのタービンは非常に高価であり、簡単にアクセスできない場所にあります。 各タービンには、タービンからのセンサーデータを監視するためのNVIDIAJetsonデバイスを装備できます。 次に、データをキャプチャし、MLアルゴリズムを使用して異常を検出するソリューションが必要です。 また、デバイス上のソフトウェアとMLモデルを最新の状態に保つためのOTAメカニズムも必要です。

AWS IoT グリーングラス V2 Edge Managerとともに、このユースケースにうまく適合します。 AWS IoT Greengrassは、デバイスでのIoTアプリケーションの構築、デプロイ、管理を支援するオープンソースのIoTエッジランタイムおよびクラウドサービスです。 AWS IoT Greengrassを使用して、事前に構築されたソフトウェアモジュールを使用してエッジアプリケーションを構築できます。 コンポーネント、エッジデバイスをAWSサービスまたはサードパーティサービスに接続できます。 AWS IoT Greengrassのこの機能により、SageMakerEdgeエージェントを含むデバイスにアセットを簡単にデプロイできます。 AWS IoT Greengrassはアプリケーションのライフサイクルの管理を担当し、EdgeManagerはMLモデルのライフサイクルを切り離します。 これにより、エッジアプリケーションとMLモデルの新しいバージョンを個別にデプロイすることで、ソリューション全体を進化させ続ける柔軟性が得られます。 次の図は、このアーキテクチャを示しています。

このソリューションは、次の手順で構成されています。

1. 開発者は、風力タービンに配備する必要のある最終的なモデルアーティファクトを構築、トレーニング、検証、および作成します。
2. Neoを呼び出して、トレーニング済みモデルをコンパイルします。
3. EdgeManagerとAWSIoTGreengrassV2統合を使用してモデルコンポーネントを作成します。
4. AWS IoTGreengrassV2をセットアップします。
5. AWS IoTGreengrassV2を使用して推論コンポーネントを作成します。
6. エッジアプリケーションはSageMakerEdgeエージェントと対話して推論を行います。
7. エージェントは、モデルの監視と改良の目的で、アプリケーションからリアルタイムのサンプル入力データを送信するように構成できます（必要な場合）。

ユースケース4

最後のユースケースとして、コンテナを輸送する船舶を見てみましょう。各コンテナにはXNUMXつのセンサーがあり、ローカルに展開されたコンピューティングおよびストレージインフラストラクチャに信号をストリーミングします。 課題は、各コンテナの内容と、各コンテナ内の温度、湿度、ガスに基づいて商品の状態を知りたいということです。 また、各コンテナ内のすべての商品を追跡したいと思います。 航海中はインターネットに接続できず、航海には数か月かかる場合があります。 このインフラストラクチャで実行されているMLモデルは、データを前処理し、すべての質問に答えるための情報を生成する必要があります。 生成されたデータは、数か月間ローカルに保存する必要があります。 エッジアプリケーションは、すべての推論をローカルデータベースに保存し、船舶が港に近づくと、結果をクラウドと同期します。

AWSSnowcone & AWSスノーボール AWSSnowファミリー このユースケースに非常によく適合します。

AWS Snowconeは、小型で頑丈、かつ安全なエッジコンピューティングおよびデータ移行デバイスです。 Snowconeは、XNUMX人で持ち上げ可能なデバイスのOSHA標準に準拠して設計されています。 Snowconeを使用すると、を使用してエッジワークロードを実行できます アマゾン エラスティック コンピューティング クラウド （Amazon EC2）コンピューティング、および石油リグ、捜索救助車、軍用車両、工場のフロア、リモートオフィス、病院、映画館などの過酷な接続されていないフィールド環境でのローカルストレージ。

Snowballは、Snowconeと比較してより多くのコンピューティングを追加するため、より要求の厳しいアプリケーションに最適な場合があります。 Compute Optimized機能は、オプションのNVIDIA Tesla V100 GPUとEC2インスタンスを提供して、切断された環境でのアプリケーションのパフォーマンスを加速します。 GPUオプションを使用すると、接続がほとんどまたはまったくない環境で、高度なMLやフルモーションビデオ分析などのアプリケーションを実行できます。

EC2インスタンスに加えて、あらゆるタイプのエッジソリューションを構築およびデプロイする自由があります。 例：あなたは使用することができます アマゾンECS または他のコンテナーマネージャーを使用して、エッジアプリケーション、エッジマネージャーエージェント、およびMLモデルを個別のコンテナーとしてデプロイします。 このアーキテクチャは、コンテナマネージャツールが追加されている点を除いて、ユースケース2に似ています（ほとんどの場合オフラインで動作することを除いて）。

次の図は、このソリューションアーキテクチャを示しています。

このソリューションを実装するには、Snowデバイスを AWSマネジメントコンソール リソースを起動します。

まとめ

この投稿では、ユースケースに基づいて使用できるエッジのさまざまな側面について説明しました。 また、ML @ Edgeに関するいくつかの重要な概念と、アプリケーションのライフサイクルとMLモデルのライフサイクルを分離することで、相互に依存することなくそれらを自由に進化させる方法についても説明しました。 ワークロードに適したエッジデバイスを選択し、ソリューションプロセス中に適切な質問をすることで、逆方向に作業し、適切なAWSサービスを絞り込むことができることを強調しました。 また、さまざまなユースケースとリファレンスアーキテクチャを紹介し、ワークロードで機能する独自のソリューションを作成するように促しました。

---

著者について

ディネシュ・クマール・スブラマニ は、スコットランドのエジンバラを拠点とするUKIRSMBチームのシニアソリューションアーキテクトです。 彼は人工知能と機械学習を専門としています。 Dineshは、さまざまな業界のお客様と協力して、AWSサービスに関する問題の解決を支援することを楽しんでいます。 仕事以外では、家族と過ごしたり、チェスをしたり、ジャンルを超えて音楽を楽しんだりするのが大好きです。

サミール・アラウージョ AWSのAI / MLソリューションアーキテクトです。 彼は、AWSを使用してビジネス上の課題を解決するAI / MLソリューションを作成する顧客を支援しています。 彼は、コンピュータービジョン、自然言語処理、予測、エッジでのMLなどに関連するいくつかのAI / MLプロジェクトに取り組んできました。 彼は自由な時間にハードウェアと自動化プロジェクトで遊ぶのが好きで、ロボット工学に特に興味があります。

• コインスマート。 ヨーロッパで最高のビットコインと暗号通貨取引所。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 出入り自由。
• CryptoHawk。 アルトコインレーダー。 無料トライアル。
• ソース：https：//aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/