エッジでのビジュアル品質検査のためのエンドツーエンドのMLOpsパイプラインの構築-パート3
ビューティー&ファッションのエキスパートが語る!エンドツーエンドのMLOpsパイプラインによるビジュアル品質検査 - パート3
この記事は、エッジにおける視覚品質検査のためのMLOpsパイプラインを設計・実装するシリーズの第3部です。この投稿では、エンドツーエンドのMLOpsパイプラインのエッジ展開部分を自動化する方法に焦点を当てます。あなたにAWS IoT Greengrassを使用してエッジでのモデルの推論を管理し、AWS Step FunctionsなどのAWSサービスを使用してプロセスを自動化する方法をご紹介します。
ソリューションの概要
このシリーズの第1部では、データのラベリングからモデルのトレーニング、そしてエッジでの展開まで、機械学習(ML)の全体的な過程を自動化するためのエンドツーエンドのMLOpsパイプラインのアーキテクチャを説明しました。そして、第2部では、パイプラインのラベリングとモデルのトレーニングの部分を自動化する方法を紹介しました。
このシリーズで使用したサンプルユースケースは、製造プロセスの一部として展開できる、金属タグの欠陥を検出する視覚品質検査ソリューションです。以下の図は、このシリーズの最初に定義したMLOpsパイプラインの高レベルアーキテクチャを示しています。まだ読んでいない場合は、第1部をご覧いただくことをおすすめします。
- カスタム分類モデルでの予測の品質を向上させるには、Amazon Comprehendを使用します
- 「AWS Trainiumを使用した高速で費用効果の高いLLaMA 2の微調整」
- 「Amazon SageMaker JumpStartを使用してFalconでHCLS文書要約アプリケーションを作成する」
MLモデルのエッジ展開の自動化
MLモデルのトレーニングと評価が終わった後、ビジネス価値を生み出すために、それを本番システムに展開する必要があります。モデルはクラウド環境でトレーニングされたモデルとは異なる場所に設置されることが多いため、エッジ設定では展開と実行のプロセスが複雑になることがあります。エッジでの機械学習に固有のいくつかの課題を以下に挙げます:
- エッジデバイスのリソース制約により、MLモデルを最適化する必要があること
- エッジデバイスはクラウドのサーバーのように再配置または交換することができないため、堅牢なモデルの展開とデバイスの管理プロセスが必要なこと
- デバイスとクラウド間の通信は効率的かつ安全である必要があり、信頼されていない低帯域幅のネットワークを経由することが多いこと
それでは、これらの課題をAWSのサービスを使用して解決する方法と、モデルをONNX形式でエクスポートすることで、モデルのサイズを制約デバイス向けに縮小するための量子化などの最適化を適用できる方法を見てみましょう。ONNXは最も一般的なエッジハードウェアプラットフォーム向けの最適化されたランタイムも提供しています。
エッジ展開プロセスを分解すると、次の2つのコンポーネントが必要です:
- モデルのデリバリーのための展開メカニズム。これにはモデル自体とモデルの管理やインタラクションに関するビジネスロジックが含まれます。
- 全体プロセスをオーケストレートすることができるワークフローエンジン。これにより、堅牢性と繰り返し可能性が確保されます。
この例では、必要なすべてのコンポーネントを統合した自動化されたエッジ展開メカニズムを構築するために、さまざまなAWSサービスを使用します。
まず、エッジデバイスをシミュレートします。エンドツーエンドのワークフローを簡単に進めるために、Amazon Elastic Compute Cloud(Amazon EC2)インスタンスを使用してエッジデバイスをシミュレートします。これにより、AWS IoT Greengrass Coreソフトウェアをインストールしたインスタンス上でエッジデバイスをシミュレートできます。実際のエッジプロダクションデバイスに展開する前に、QAプロセスでさまざまなコンポーネントを検証するためにも、EC2インスタンスを使用できます。AWS IoT Greengrassは、インターネットオブシングス(IoT)のオープンソースエッジランタイムおよびクラウドサービスであり、エッジデバイスソフトウェアの構築、展開、管理を支援します。AWS IoT Greengrassは、セキュアかつスケーラブルな方法でエッジデバイスソフトウェアを構築、展開、管理する手間を減らします。デバイスにAWS IoT Greengrass Coreソフトウェアをインストールした後、機能やコンポーネントを追加または削除し、AWS IoT Greengrassを使用してIoTデバイスアプリケーションを管理することができます。エンドツーエンドの暗号化をサポートするStreamManagerやMQTTブローカーコンポーネントなど、生活をより簡単にするための多くの組み込みコンポーネントが提供されています。これらの機能を使用して、推論結果や画像を効率的にアップロードできます。
プロダクション環境では、通常、産業用カメラが画像を提供し、MLモデルが予測を行う必要があります。私たちのセットアップでは、エッジデバイスの特定のディレクトリにあらかじめ設定した画像をアップロードすることで、この画像入力をシミュレートしています。その後、これらの画像をモデルの推論入力として使用します。
モデルをクラウドでトレーニングし、エッジ環境に展開し、予測に使用するために、全体の展開と推論プロセスを3つの連続したステップに分割しました:
- 準備 – トレーニング済みモデルをエッジ展開用にパッケージ化します。
- 展開 – モデルと推論コンポーネントのクラウドからエッジデバイスへの転送。
- 推論 – モデルを読み込み、画像の予測のための推論コードを実行します。
以下のアーキテクチャ図は、この3ステップのプロセスの詳細と、AWSサービスを使用していかに実装されたかを示しています。
以下のセクションでは、各ステップの詳細について説明し、このプロセスをMLモデルと対応する推論コードのための自動化および繰り返し可能なオーケストレーションおよびCI/CDワークフローに組み込む方法を示します。
準備
エッジデバイスは、パワフルなCPUやGPUが容易にMLモデルを実行できるクラウド環境と比較して、計算能力やメモリが制限されている場合があります。さまざまなモデル最適化技術を使用して、予測速度を向上させるための特定のソフトウェアまたはハードウェアプラットフォームにモデルを合わせることができます。
この例では、トレーニングパイプラインでトレーニングされたモデルを移植性、可能な最適化、および最適化されたエッジランタイムのためにONNX形式でエクスポートし、Amazon SageMakerモデルレジストリに登録しました。このステップでは、次の展開のための最新の登録済みモデルを含む新しいGreengrassモデルコンポーネントを作成します。
展開
クラウドからエッジデバイスにモデルを展開する際には、安全で信頼性のある展開メカニズムが重要です。AWS IoT Greengrassは既に強力で安全なエッジ展開システムを組み込んでいるため、展開目的でこれを使用しています。詳細な展開プロセスを見る前に、AWS IoT Greengrassデプロイメントがどのように機能するかについて簡単に確認しましょう。AWS IoT Greengrassデプロイメントシステムの中核には、エッジデバイス上で実行されるAWS IoT Greengrass Coreが稼働するソフトウェアモジュールを定義するコンポーネントがあります。これらはビルドしたプライベートコンポーネントまたはAWSまたは
広範なGreengrassコミュニティによって提供されるパブリックコンポーネントである場合があります。複数のコンポーネントを一緒にバンドルして展開の一部とすることができます。デプロイメント構成は、展開に含まれるコンポーネントとデプロイメントの対象デバイスを定義します。これはデプロイメント構成ファイル(JSON)で定義することも、AWS IoT Greengrassコンソールで新しいデプロイメントを作成する際にも行うことができます。
以下の2つのGreengrassコンポーネントを作成し、次の展開プロセスを介してエッジデバイスに展開します:
- Packaged model(プライベートコンポーネント) – このコンポーネントにはONNX形式の訓練済みMLモデルが含まれています。
- Inference code(プライベートコンポーネント) – MLモデル自体に加えて、データの準備、推論のためのモデルとの通信、推論結果の事後処理などのタスクを処理するアプリケーションロジックを実装する必要があります。この例では、以下のタスクを処理するためにPythonベースのプライベートコンポーネントを開発しました:
- Ultralytics YOLOv8 Pythonパッケージなどの必要なランタイムコンポーネントをインストールします。
- カメラのライブストリームから画像を取得する代わりに、準備した画像を特定のディレクトリからロードし、モデルの入力要件に合わせて画像データを準備します。
- 準備した画像データでロードされたモデルに対して推論呼び出しを行います。
- 予測をチェックし、推論結果をクラウドにアップロードします。
ビルドした推論コードの詳細を確認したい場合は、GitHubリポジトリを参照してください。
推論
上記のコンポーネントのデプロイが完了した後、エッジデバイス上でモデルの推論プロセスが自動的に開始されます。カスタム推論コンポーネントは、ローカルディレクトリから定期的にMLモデルを画像とともに実行します。モデルから返される各画像の推論結果は、以下の内容を持つテンソルです。
- 信頼度スコア – モデルが検出に関してどれだけ自信を持っているか
- オブジェクトの座標 – 画像中でモデルが検出したスクラッチオブジェクトの座標 (x, y, 幅, 高さ)
私たちの場合、推論コンポーネントは推論結果をAWS IoT上の特定のMQTTトピックに送信する役割を担っており、これによりさらなる処理のために読み取ることができます。これらのメッセージは、デバッグのためにAWS IoTコンソール上のMQTTテストクライアントで表示することができます。本番環境では、製造ラインから不良な金属タグを自動的に除去するシステムに通知することを自動的に決定することができます。
オーケストレーション
前のセクションで確認したように、MLモデルとそれに対応する推論コード、およびエッジデバイスに必要なランタイムやエージェントを準備してデプロイするには、複数のステップが必要です。Step Functionsは、これらの専用のステップを組み合わせ、ワークフローをステートマシンの形式で設計することができる、完全に管理されたサービスです。このサービスのサーバーレスな性質と、AWSサービスAPI連携などのネイティブなステップ関数の機能により、このワークフローを迅速に設定することができます。リトライやログ出力の組み込み機能は、堅牢なオーケストレーションを構築するための重要なポイントです。ステートマシンの定義そのものの詳細については、GitHubリポジトリを参照するか、この例をアカウントにデプロイした後にStep Functionsコンソール上のステートマシングラフを確認してください。
インフラストラクチャのデプロイとCI/CDへの統合
必要なインフラストラクチャコンポーネントを統合し、ビルドするためのCI/CDパイプラインは、このシリーズのPart 1で説明されているパターンに従います。AWSクラウド開発キット(AWS CDK)を使用して、AWS CodePipelineから必要なパイプラインをデプロイします。
学び
自動化された堅牢で安全なMLモデルのエッジデプロイメントシステムのアーキテクチャを構築するための複数の方法がありますが、それは使用ケースやその他の要件に非常に依存することがよくあります。ただし、以下は共有したいいくつかのポイントです:
- 追加のAWS IoT Greengrassコンピュートリソース要件が制約のあるエッジデバイスに適合するかどうかを事前に評価します。
- エッジデバイスで実行する前に、展開アーティファクトの検証ステップが組み込まれたデプロイメントメカニズムを確立し、データ伝送中の改ざんがないことを確認します。
- デプロイメントコンポーネントを可能な限りモジュラーで自己完結型に保つことは良い習慣です。例えば、比較的小さな推論コードモジュールがあるが、MLモデルのサイズが大きい場合、推論コードのみが変更された場合に、両方をデプロイしたくないことがあります。帯域幅が制限されているか、高コストのエッジデバイス接続性を持つ場合に特に重要です。
結論
エッジでの視覚品質検査のためのエンドツーエンドのMLOpsパイプラインの構築についての3部作は以上です。モデルのパッケージングや複雑なデプロイメントオーケストレーションなど、エッジでのMLモデルの展開に伴うさまざまな課題を見てきました。このシリーズで実装したパイプラインは、堅牢で安全、繰り返し可能、追跡可能な方法でモデルを本番環境に展開するために完全に自動化されています。このシリーズで開発されたアーキテクチャと実装を次のMLプロジェクトの出発点として自由に使用してください。ご自身の環境に対してこのようなシステムを設計・構築する方法についての質問がある場合は、お気軽にお問い合わせください。他のトピックやユースケースについては、弊社の機械学習およびIoTブログを参照してください。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles