モノのインターネット (IoT) により、製造、自動車、エネルギーなど、複数の業界の顧客が実世界の環境を監視および制御できるようになりました。 カメラ、サーモスタット、センサーなどのさまざまなエッジ IoT デバイスをデプロイすることで、データを収集してクラウドに送信し、機械学習 (ML) モデルを構築して異常や障害などを予測できます。 ただし、ユースケースでリアルタイムの予測が必要な場合は、IoT ソリューションをエッジでの ML (ML@Edge) 機能で強化する必要があります。 ML @ Edge ML モデルのライフサイクルをアプリのライフサイクルから分離し、データの準備、モデルの構築、モデルのコンパイルと最適化、モデルのデプロイ (エッジ デバイスのフリートへの) を含むエンドツーエンドの ML パイプラインを実行できるようにする概念です。モデルの実行、モデルの監視と管理。 アプリを XNUMX 回デプロイすると、必要な回数だけ ML パイプラインを実行できます。
ご想像のとおり、ML@Edge の概念によって提案されたすべての手順を実装するのは簡単ではありません。 完全な ML@Edge ソリューションを実装するために開発者が対処する必要がある多くの質問があります。たとえば、次のとおりです。
- エッジのフリート (数百、数千、または数百万) のデバイスで ML モデルを操作するにはどうすればよいですか?
- モデルをエッジでデプロイして実行しながら、モデルを保護するにはどうすればよいですか？
- モデルのパフォーマンスを監視し、必要に応じて再トレーニングするにはどうすればよいですか？
この投稿では、これらすべての質問に答え、ML@Edge パイプラインを自動化するためのエンド ツー エンドのソリューションを構築する方法を学びます。 使い方がわかります Amazon SageMaker エッジマネージャー, Amazon SageMakerスタジオ, AWS IoT グリーングラス v2 ML モデルを構築して多数のエッジ デバイスにデプロイするプロセスを自動化する MLOps (ML オペレーション) 環境を作成します。
次のセクションでは、エッジ ワークロードに重点を置いた MLOps の完全なソリューションを構築するために必要なすべてのコンポーネントとワークフローを詳述するリファレンス アーキテクチャを紹介します。 次に、このソリューションが自動的に実行して新しいモデルを構築および準備する手順について詳しく説明します。 また、ML モデルのデプロイ、実行、監視を開始するためにエッジ デバイスを準備する方法を示し、デバイスのフリートにデプロイされた ML モデルを監視および維持する方法を示します。
ソリューションの概要
堅牢な ML モデルの製品化には、データ サイエンティスト、ML エンジニア、データ エンジニア、ビジネス関係者などの複数のペルソナが、特定の操作に従う半自動インフラストラクチャ (MLOps) の下でコラボレーションする必要があります。 また、環境のモジュール化は、これらすべての異なるペルソナに、担当するコンポーネントを (ワークフローとは無関係に) 開発または改善するための柔軟性と機敏性を与えるために重要です。 このようなインフラストラクチャの例は、複数の AWS アカウントで構成され、クラウドとエッジ デバイスの両方で ML モデルのコラボレーションと生産を可能にします。 次の参照アーキテクチャでは、ML モデルを構築してエッジにデプロイするためのエンドツーエンドの MLOps プラットフォームを構成する複数のアカウントとサービスをどのように編成したかを示します。
このソリューションは、次のアカウントで構成されています。
- データレイク アカウント – データ エンジニアは、オンプレミス データベースや IoT デバイスなど、複数のデータ ソースからデータを取り込み、保存し、準備します。
- ツーリングアカウント – IT オペレーターは、CI/CD パイプラインを管理およびチェックして、リモート エッジ デバイスの運用前および運用アカウント全体で ML モデル パッケージの自動化された継続的な配信と展開を行います。 CI/CD パイプラインの実行は、 アマゾンイベントブリッジ、ML モデルとターゲットの変更ステータス イベントを監視します AWS コードパイプライン.
- 実験・開発アカウント – データ サイエンティストは、複数のモデリング手法とアルゴリズムを使用して調査と実験を行い、ML に基づいてビジネス上の問題を解決し、概念実証ソリューションを作成できます。 ML エンジニアとデータ サイエンティストが協力して概念実証を拡大し、 AmazonSageMakerパイプライン データを準備し、ML モデルを構築、トレーニング、パッケージ化します。 パイプラインの展開は CI/CD パイプラインを介して駆動され、モデルのバージョン管理は Amazon SageMaker モデルレジストリ. データ サイエンティストは、複数のモデル バージョンのメトリックを評価し、CI/CD パイプラインをトリガーして、最適なモデルを本番環境に昇格するように要求します。
- 試作アカウント – モデルを実稼働環境にプロモートする前に、モデルをテストして、シミュレーション環境での堅牢性を確保する必要があります。 したがって、本番前環境は本番環境のシミュレーターであり、SageMaker モデルのエンドポイントが自動的にデプロイおよびテストされます。 テスト方法には、統合テスト、ストレス テスト、または推論結果に対する ML 固有のテストが含まれる場合があります。 この場合、本番環境は SageMaker モデルのエンドポイントではなく、エッジ デバイスです。 本番前のエッジ デバイスをシミュレートするには、次の XNUMX つの方法が考えられます。 アマゾン エラスティック コンピューティング クラウド (Amazon EC2) インスタンスと同じハードウェア特性を持つか、実際のデバイスで構成されるラボ内のテストベッドを使用します。 このインフラストラクチャでは、CI/CD パイプラインがモデルを対応するシミュレーターにデプロイし、複数のテストを自動的に実施します。 テストが正常に実行された後、CI/CD パイプラインには手動の承認が必要です (たとえば、モデルを運用環境に昇格させるために IoT 利害関係者から)。
- プロダクションアカウント – AWS クラウドでモデルをホストする場合、CI/CD パイプラインは本番アカウントに SageMaker モデル エンドポイントをデプロイします。 この場合、本番環境はエッジ デバイスの複数のフリートで構成されます。 したがって、CI/CD パイプラインは Edge Manager を使用して、対応するデバイスのフリートにモデルをデプロイします。
- エッジデバイス – リモート エッジ デバイスは、Edge Manager を使用して ML モデルを実行できるハードウェア デバイスです。 これらのデバイス上のアプリケーションは、モデルを管理し、モデルに対して推論を実行し、データを安全にキャプチャすることができます。 Amazon シンプル ストレージ サービス （Amazon S3）。
SageMakerプロジェクト これらの各アカウント内でリソースをプロビジョニングするプロセスを自動化するのに役立ちます。 この機能については深く掘り下げませんが、アカウント間で ML モデルをデプロイする SageMaker プロジェクト テンプレートを構築する方法について詳しくは、以下をご覧ください。 AmazonSageMakerパイプラインを使用したマルチアカウントモデルのデプロイ.
運用前アカウント: デジタルツイン
トレーニング プロセスの後、結果のモデルを評価する必要があります。 運用前アカウントには、シミュレートされた Edge デバイスがあります。 それは、 デジタルツイン ML モデルが本番環境で実行されるエッジ デバイスの。 この環境には、従来のテスト (ユニット、統合、スモークなど) を実行することと、開発チームの遊び場になるという 2 つの目的があります。 このデバイスは、ML モデルの管理に必要なすべてのコンポーネントがデプロイされた ECXNUMX インスタンスを使用してシミュレートされます。
関連するサービスは次のとおりです。
- AWS IoTコア - を使用しております AWS IoTコア AWS IoT Thing オブジェクトの作成、デバイス フリートの作成、デバイス フリートを登録してクラウドとやり取りできるようにする、X.509 証明書を作成してエッジ デバイスを AWS IoT Core に認証する、ロール エイリアスを作成時に生成された AWS IoT Core に関連付けるフリートが作成し、認証情報プロバイダーの AWS アカウント固有のエンドポイントを取得し、公式の Amazon ルート CA ファイルを取得して、Amazon CA ファイルを Amazon S3 にアップロードします。
- Amazon Sagemaker Neo – セージメーカー ネオ 推論用の機械学習モデルを自動的に最適化し、精度を損なうことなく高速に実行します。 これは、DarkNet、Keras、MXNet、PyTorch、TensorFlow、TensorFlow-Lite、ONNX、または XGBoost で既に構築され、Amazon SageMaker またはその他の場所でトレーニングされた機械学習モデルをサポートしています。 次に、ターゲット ハードウェア プラットフォームを選択します。これは、Ambarella、Apple、ARM、Intel、MediaTek、Nvidia、NXP、Qualcomm、RockChip、Texas Instruments、または Xilinx のプロセッサに基づく SageMaker ホスティング インスタンスまたはエッジ デバイスです。
- エッジマネージャー – Edge Manager を使用して、Sagemaker フリート内のエッジ デバイスを登録および管理します。 フリートは、データの収集と分析に使用できる、論理的にグループ化されたデバイスのコレクションです。 さらに、Edge Manager パッケージャーは、最適化されたモデルをパッケージ化し、直接デプロイできる AWS IoT Greengrass V2 コンポーネントを作成します。 Edge Manager を使用して、一連のスマート カメラ、スマート スピーカー、ロボット、およびその他の SageMaker デバイス フリートで ML モデルを操作できます。
- AWS IoT グリーングラス V2 – AWS IoT Greengrass EC2 インスタンスを使用して、シミュレートされたデバイスにコンポーネントをデプロイできます。 EC2 インスタンスで AWS IoT Greengrass V2 エージェントを使用することで、Edge Manager エージェントとモデルのデバイスへのアクセス、管理、デプロイを簡素化できます。 AWS IoT Greengrass V2 がない場合、Edge Manager を使用するようにデバイスとフリートをセットアップするには、S3 リリース バケットからエージェントを手動でコピーする必要があります。 AWS IoT Greengrass V2 と Edge Manager の統合により、AWS IoT Greengrass V2 コンポーネントを使用できます。 コンポーネントは、AWS IoT Greengrass を介してエッジ デバイスを AWS のサービスまたはサードパーティのサービスに接続できる事前構築済みのソフトウェア モジュールです。
- EdgeManagerエージェント – Edge Manager エージェントは、AWS IoT Greengrass V2 を介して EC2 インスタンスにデプロイされます。 エージェントは、一度に複数のモデルをロードし、エッジ デバイスにロードされたモデルを使用して推論を行うことができます。 エージェントがロードできるモデルの数は、デバイスで使用可能なメモリによって決まります。
- アマゾンS3 – S3 バケットを使用して、Edge Manager エージェントからキャプチャされた推論データを保存します。
実際のエッジ デバイスに移行する前に ML モデルをテストするためのデジタル ツインとして、運用前アカウントを定義できます。 これには次の利点があります。
- 敏捷性と柔軟性 – データ サイエンティストと ML エンジニアは、ML モデルと関連するスクリプト (前処理スクリプトと推論スクリプト) がデバイス エッジで機能するかどうかを迅速に検証する必要があります。 ただし、大企業の IoT 部門とデータ サイエンス部門は別のエンティティである可能性があります。 テクノロジー スタックをクラウドにまったく同じように複製することで、データ サイエンティストと ML エンジニアは、展開前にアーティファクトを繰り返して統合できます。
- リスク評価と生産時間の短縮 – エッジ デバイスへの展開は、プロセスの最終段階です。 隔離された自己完結型の環境ですべてを検証したら、品質、パフォーマンス、および統合に関してエッジに必要な仕様に準拠するように保護します。 これにより、IoT 部門の他の人がアーティファクト バージョンの修正と反復にさらに関与することを回避できます。
- チームコラボレーションの改善と品質とパフォーマンスの向上 – 開発チームは、エッジ ハードウェア メトリックを分析し、サードパーティ ツールとの相互作用のレベル (I/O レートなど) を測定することで、ML モデルの影響をすぐに評価できます。 その後、IoT チームは運用環境へのデプロイのみを担当し、成果物が運用環境に対して正確であることを確信できます。
- テスト用の統合プレイグラウンド – ML モデルのターゲットを考えると、従来のワークフローの運用前環境は、クラウド環境外のエッジ デバイスで表す必要があります。 これにより、別のレベルの複雑さが生じます。 指標とフィードバックを収集するには、統合が必要です。 代わりに、デジタル ツインのシミュレートされた環境を使用することで、やり取りが減り、市場投入までの時間が短縮されます。
本番アカウントとエッジ環境
テストが完了し、アーティファクトの安定性が達成されたら、パイプラインを介して本番環境のデプロイに進むことができます。 アーティファクトのデプロイは、オペレーターがアーティファクトを承認した後、プログラムによって行われます。 ただし、 AWSマネジメントコンソール フリートに関連付けられたメタデータを監視できるため、デプロイされた ML モデルのバージョンやライフサイクルに関連付けられたその他のメトリックを把握できるように、読み取り専用モードのオペレーターに付与されます。
エッジ デバイス フリートは AWS 本番アカウントに属します。 このアカウントには、クラウドとエッジ デバイス間の通信を可能にする特定のセキュリティおよびネットワーク構成があります。 本番アカウントにデプロイされた主な AWS サービスは、すべてのデバイス フリートの管理、データの収集、および ML モデルの操作を担当する Edge Manager と、IoT モノのオブジェクト、証明書、ロール エイリアス、およびエンドポイントを管理する AWS IoT Core です。
同時に、ML モデルを管理するためのサービスとコンポーネントを使用してエッジ デバイスを構成する必要があります。 主なコンポーネントは次のとおりです。
- AWS IoT グリーングラス V2
- Edge Manager エージェント
- AWS IoT 証明書
- 推論プロセスのオーケストレーションを担当する Application.py (エッジ データ ソースから情報を取得し、Edge Manager エージェントと読み込まれた ML モデルを使用して推論を実行する)
- 推論されたデータを保存するための Amazon S3 またはデータ レイク アカウントへの接続
自動 ML パイプライン
リファレンス アーキテクチャの構成とコンポーネントについて理解を深めたところで、開発アカウント内で ML モデルを構築、トレーニング、評価するために使用する ML パイプラインについて詳しく見ていきましょう。
パイプライン (を使用して構築 AmazonSageMakerモデル構築パイプライン) は、JSON パイプライン定義によって定義される相互接続された一連のステップです。 このパイプライン定義は、有向非巡回グラフ (DAG) を使用してパイプラインをエンコードします。 この DAG は、パイプラインの各ステップの要件と関係に関する情報を提供します。 パイプラインの DAG の構造は、ステップ間のデータの依存関係によって決まります。 これらのデータの依存関係は、ステップの出力のプロパティが入力として別のステップに渡されるときに作成されます。
データ サイエンス チームが新しいバージョンの ML モデルの作成を簡単に自動化できるようにするには、ML モデルを継続的にフィードおよび改善するための検証手順と自動化されたデータ、およびパイプライン トリガーを有効にするためのモデル監視戦略を導入することが重要です。 次の図は、パイプラインの例を示しています。
自動化と MLOps 機能を有効にするには、さまざまなステップや ML ユース ケースで共有できる再利用可能なコード アーティファクトを作成するためのモジュラー コンポーネントを作成することが重要です。 これにより、移行を自動化することで、実装を実験フェーズから実稼働フェーズにすばやく移行できます。
ML モデルの継続的なトレーニングとバージョン管理を可能にする ML パイプラインを定義する手順は次のとおりです。
- 前処理 – ML アルゴリズムをトレーニングするためのデータ クリーニング、特徴量エンジニアリング、およびデータセット作成のプロセス
- トレーニング – 新しいバージョンの ML モデル アーティファクトを生成するために開発された ML アルゴリズムをトレーニングするプロセス
- 評価 – 生成された ML モデルの評価プロセス。トレーニング フェーズ中に見られなかった新しいデータのモデルの動作に関連する主要な指標を抽出します。
- 参加申し込み – 抽出されたメトリクスを生成されたアーティファクトにリンクすることにより、新しいトレーニング済み ML モデル アーティファクトをバージョン管理するプロセス
以下で、SageMaker パイプラインを構築する方法の詳細を確認できます。 ノート.
EventBridge を使用して CI/CD パイプラインをトリガーする
モデルの構築が完了したら、デプロイ プロセスを開始できます。 前のセクションで定義した SageMaker パイプラインの最後のステップでは、モデルの新しいバージョンを特定の SageMaker モデル レジストリ グループに登録します。 ML モデルの新しいバージョンのデプロイは、モデル レジストリのステータスを使用して管理されます。 ML モデルのバージョンを手動で承認または拒否することにより、このステップで EventBridge によってキャプチャされるイベントが発生します。 このイベントは、AWS IoT Greengrass コンポーネントの新しいバージョンを作成するための新しいパイプライン (今回は CI/CD) を開始し、それを本番前および本番アカウントにデプロイできます。 次のスクリーンショットは、定義済みの EventBridge ルールを示しています。
このルールは、ステータスでモデルパッケージの更新を探すことにより、SageMaker モデルパッケージグループを監視します Approved or Rejected.
次に、EventBridge ルールが CodePipeline をターゲットにするように設定されます。これにより、新しい AWS IoT Greengrass コンポーネントを作成するワークフローが開始されます。 Amazon SageMaker ネオ とエッジ マネージャー。
ターゲット アーキテクチャに合わせて ML モデルを最適化する
Neo を使用すると、エッジ デバイス (およびクラウド) で推論を実行するために ML モデルを最適化できます。 ターゲット アーキテクチャに基づいてパフォーマンスを向上させるために ML モデルを自動的に最適化し、元のフレームワークからモデルを切り離して、軽量のランタイムで実行できるようにします。
以下を参照 ノート Neo を使用して PyTorch Resnet18 モデルをコンパイルする方法の例については、
AWS IoT Greengrass コンポーネントを含めてデプロイ パッケージを構築する
Edge Manager を使用すると、一連のエッジ デバイスに対するモデルを管理、保護、デプロイ、および監視できます。 以下では ノートでは、エッジ デバイスの最小限のフリートを構築し、この機能を使用していくつかの実験を実行する方法の詳細を確認できます。
フリートを構成してモデルをコンパイルしたら、Edge Manager のパッケージ化ジョブを実行する必要があります。これにより、モデルをフリートにデプロイする準備が整います。 Boto3 SDK を使用してパッケージング ジョブを開始できます。 パラメータには、最適化されたモデルとモデル メタデータを使用します。 次のパラメーターを追加することにより、 OutputConfig、ジョブはモデルを使用して AWS IoT Greengrass V2 コンポーネントも準備します。
PresetDeploymentTypePresetDeploymentConfig
次のコードを参照してください。
ML モデルをエッジに大規模にデプロイする
次に、モデルを一連のエッジ デバイスにデプロイします。 まず、必要なものがあることを確認する必要があります AWS IDおよびアクセス管理 （わたし） パーミッション IoT デバイスをプロビジョニングし、コンポーネントをデプロイできるようにします。 IoT プラットフォームへのデバイスのオンボーディングを開始するには、次の XNUMX つの基本要素が必要です。
- IAMポリシー – このポリシーにより、プロビジョニングを実行するユーザーまたはロールに関連付けられた、そのようなデバイスの自動プロビジョニングが可能になります。 IoT のモノとグループを作成し、必要なポリシーをデバイスにアタッチするには、IoT 書き込みアクセス許可が必要です。 詳細については、次を参照してください。 インストーラーがリソースをプロビジョニングするための最小限の IAM ポリシー.
- IAMの役割 – この役割は、私たちが作成する IoT のモノとグループに関連付けられます。 プロビジョニング時に基本的なアクセス許可でこのロールを作成できますが、Amazon S3 へのアクセスや AWSキー管理サービス (AWS KMS) 後で必要になる可能性があります。 このロールを事前に作成し、デバイスのプロビジョニング時に再利用できます。 詳細については、次を参照してください。 コア デバイスに AWS とのやり取りを許可する.
AWS IoT Greengrass のインストールとプロビジョニング
IAM ポリシーとロールを配置したら、準備完了です 自動リソース プロビジョニングを使用して AWS IoT Greengrass Core ソフトウェアをインストールする. 手動の手順に従って IoT リソースをプロビジョニングすることは可能ですが、AWS IoT Greengrass v2 ニュークリアスのインストール中にこれらのリソースを自動的にプロビジョニングする便利な手順があります。 これは、新しいデバイスをプラットフォームにすばやくオンボードするための推奨オプションです。 その上 default-jdk、その他のパッケージをインストールする必要があります。 curl, unzip, python3.
デバイスをプロビジョニングするとき、IoT モノの名前は Edge Manager で定義されたエッジ デバイスとまったく同じである必要があります。そうでない場合、データは宛先 S3 バケットにキャプチャされません。
インストーラーは、AWS IoT Greengrass ロールとエイリアスが存在しない場合、インストール中に作成できます。 ただし、それらは最小限のアクセス許可で作成され、Amazon S3 などの他のサービスとやり取りするには、ポリシーを手動で追加する必要があります。 前に示したように、事前にこれらの IAM リソースを作成し、新しいデバイスをアカウントにオンボードするときに再利用することをお勧めします。
モデルと推論コンポーネントのパッケージ化
コードが開発されたら、コード (推論用) と ML モデルの両方をコンポーネントとしてデバイスにデプロイできます。
ML モデルが SageMaker でトレーニングされた後、Sagemaker コンパイル ジョブを使用して Neo でモデルを最適化できます。 コンパイルされたモデル アーティファクトは、Edge Manager パッケージャーを使用して GreenGrass V2 コンポーネントにパッケージ化できます。 次に、カスタムコンポーネントとして登録できます 私のコンポーネント AWS IoT Greengrass コンソールのセクション。 このコンポーネントには、モデル アーティファクトをデバイスにダウンロードして解凍するために必要なライフサイクル コマンドが既に含まれているため、推論コードはそれを読み込んで、キャプチャした画像を送信できます。
推論コードに関しては、コンソールを使用してコンポーネントを作成するか、 AWSコマンドラインインターフェイス (AWS CLI)。 まず、ソース推論コードと必要な依存関係を Amazon S3 にパックします。 コードをアップロードしたら、次の例のように .yaml または JSON のレシピを使用してコンポーネントを作成できます。
このサンプル レシピは、コンポーネントの名前と説明、および run script コマンドの前に必要な前提条件を示しています。 レシピはデバイスの作業フォルダー環境でアーティファクトを解凍し、そのパスを使用して推論コードを実行します。 このようなレシピを作成する AWS CLI コマンドは次のとおりです。
AWS IoT Greengrass コンソールで作成されたこのコンポーネントを確認できるようになりました。
コンポーネントのバージョンが重要であり、レシピ ファイルで指定する必要があることに注意してください。 同じバージョン番号を繰り返すと、エラーが返されます。
モデルと推論コードをコンポーネントとしてセットアップしたら、それらをデプロイする準備が整いました。
AWS IoT Greengrass を使用してアプリケーションとモデルをデプロイする
前のセクションでは、推論コードと ML モデルをパッケージ化する方法を学びました。 これで、推論コードがエッジ デバイスのモデルと対話するために必要なコンポーネントと構成の両方を含む複数のコンポーネントを含むデプロイを作成できます。
Edge Manager エージェントは、すべての Edge Manager 機能を有効にするために各エッジ デバイスにインストールする必要があるコンポーネントです。 SageMaker コンソールでは、関連付けられた S3 バケットを持つデバイス フリートが定義されています。 フリートに関連付けられているすべてのエッジ デバイスは、データをキャプチャして、この S3 パスに報告します。 エージェントは AWS IoT Greengrass v2 のコンポーネントとしてデプロイできるため、エージェントをスタンドアロン モードでデプロイする場合よりもインストールと設定が簡単になります。 エージェントをコンポーネントとして展開する場合、その構成パラメーター、つまりデバイス フリートと S3 パスを指定する必要があります。
作成したばかりのモデルとコードのカスタム コンポーネントを使用してデプロイ構成を作成します。 このセットアップは、デプロイメント名とターゲット、およびデプロイメント内のコンポーネントをリストする JSON ファイルで定義されます。 フリート名とバケットを指定する Edge Manager エージェントなど、各コンポーネントの構成パラメーターを追加および更新できます。
モデル、推論コンポーネント、エージェントだけでなく、コンポーネントとして AWS IoT Greengrass CLI と核も追加したことは注目に値します。 前者は、特定の展開をデバイス上でローカルにデバッグするのに役立ちます。 後者は、必要に応じてデバイス自体から必要なネットワーク アクセスを構成するためにデプロイに追加されます (プロキシ設定など)。また、AWS IoT Greengrass v2 ニュークリアスの OTA アップグレードを実行する場合にも使用されます。 ニュークリアスはデバイスにインストールされているため展開されず、構成の更新のみが適用されます (アップグレードが行われている場合を除く)。 展開するには、前の構成に対して次のコマンドを実行するだけです。 デプロイが適用されるターゲット ARN (IoT モノまたは IoT グループ) を忘れずに設定してください。 これらのコンポーネントをコンソールからデプロイすることもできます。
エッジにデプロイされた ML モデルを監視および管理する
アプリケーションがエッジ デバイスで実行されるようになったので、今度はフリートを監視してガバナンス、メンテナンス、および可視性を向上させる方法を理解します。 SageMaker コンソールで、選択します エッジマネージャー ナビゲーションペインで、を選択します エッジデバイスフリート. ここから、艦隊を選択します。
フリートの詳細ページでは、フリートの各デバイスで実行されているモデルのメタデータを確認できます。 フリート レポートは 24 時間ごとに生成されます。
Edge Agent を介して各デバイスによってキャプチャされたデータは、JSON ライン形式 (JSONL) で S3 バケットに送信されます。 キャプチャされたデータを送信するプロセスは、アプリケーションの観点から管理されます。 したがって、このデータを送信するかどうか、送信する方法と頻度を自由に決定できます。
このデータは、データのドリフトやモデルの品質の監視、新しいデータセットの構築、データ レイクの強化など、さまざまな用途に使用できます。 このデータを利用する方法の簡単な例は、ユーザーがアプリケーションと対話する方法でデータのドリフトを特定し、新しいモデルをトレーニングする必要がある場合です。 次に、キャプチャしたデータを使用して新しいデータセットを構築し、それを開発アカウントにコピーします。 これにより、環境の新しい実行が自動的に開始され、新しいモデルが構築され、それがフリート全体に再デプロイされて、デプロイされたソリューションのパフォーマンスが維持されます。
まとめ
この投稿では、AWS サービスを使用して MLOps と ML@Edge を組み合わせた完全なソリューションを構築する方法を学びました。 このようなソリューションを構築することは簡単ではありませんが、この記事で紹介するリファレンス アーキテクチャが刺激となり、ビジネス上の課題に対応する堅実なアーキテクチャを構築するのに役立つことを願っています。 既存の MLOps 環境と統合するこのアーキテクチャの一部またはモジュールのみを使用することもできます。 一度に XNUMX つのモジュールのプロトタイプを作成し、適切な AWS のサービスを使用してこの課題の各部分に対処することで、堅牢な MLOps 環境を構築する方法を学び、最終的なアーキテクチャをさらに簡素化することもできます。
次のステップとして、エッジのライフサイクルで ML を管理するために Sagemaker Edge Manager を試すことをお勧めします。 Edge Manager の動作の詳細については、次を参照してください。 SageMaker Edge Manager を使用してモデルをエッジにデプロイする .
著者について
ブルーノ・ピストン ミラノを拠点とする AWS の AI/ML スペシャリスト ソリューション アーキテクトです。 彼は、あらゆる規模の顧客と協力して、技術的なニーズを深く理解し、AWS クラウドと Amazon Machine Learning スタックを最大限に活用する AI および機械学習ソリューションを設計できるよう支援しています。 彼の専門分野は、機械学習のエンド ツー エンド、機械学習の産業化、MLOps です。 彼は友達と時間を過ごし、新しい場所を探索したり、新しい目的地に旅行したりすることを楽しんでいます。
マッテオ・カラブレーゼ AWS プロフェッショナル サービス チームの AI/ML カスタマー デリバリー アーキテクトです。 AI / ML プロジェクトで EMEA 大企業と協力し、ML 生産ワークロードの提案、設計、提供、スケーリング、最適化を支援しています。 彼の主な専門知識は、ML オペレーション (MLOps) とエッジでの機械学習です。 彼の目標は、AWS のベストプラクティスを提供することで、価値実現までの時間を短縮し、ビジネス成果を加速することです。 余暇には、ハイキングや旅行を楽しんでいます。
ラウルディアスガルシア AWS プロフェッショナル サービス チームのシニア データ サイエンティストです。 彼は EMEA 全域の大企業顧客と協力しており、IoT 分野でのコンピューター ビジョンと機械学習に関連するソリューションを顧客が実現できるよう支援しています。
ソクラティス・カルタキス アマゾンウェブサービスのシニア機械学習スペシャリストソリューションアーキテクトです。 Sokratisは、AWSサービスを活用し、運用モデル（MLOps基盤）を形成し、ベスト開発プラクティスを活用した変革ロードマップを作成することで、企業のお客様が機械学習（ML）ソリューションを産業化できるようにすることに重点を置いています。 彼は、エネルギー、小売、健康、金融/銀行、モータースポーツなどの分野で革新的なエンドツーエンドの生産レベルのMLおよびモノのインターネット（IoT）ソリューションの発明、設計、主導、および実装に15年以上を費やしてきました。 Sokratisは、家族や友人と暇な時間を過ごしたり、バイクに乗ったりするのが好きです。
サミール・アラウージョ AWSのAI / MLソリューションアーキテクトです。 彼は、AWSを使用してビジネス上の課題を解決するAI / MLソリューションを作成する顧客を支援しています。 彼は、コンピュータービジョン、自然言語処理、予測、エッジでのMLなどに関連するいくつかのAI / MLプロジェクトに取り組んできました。 彼は自由な時間にハードウェアと自動化プロジェクトで遊ぶのが好きで、ロボット工学に特に興味があります。
