屋良 世界有数の作物栄養会社であり、環境および農業ソリューションのプロバイダーです。 ヤラの野心は、顧客、株主、社会全体に価値を生み出し、より持続可能な食品バリューチェーンを提供する自然に優しい食品の未来を育てることに焦点を当てています。 ヤラは、飢餓のない世界と尊重される地球という私たちのビジョンをサポートし、持続可能な価値成長の戦略を追求し、気候に優しい作物の栄養とゼロエミッションのエネルギーソリューションを推進しています。 屋良は、アンモニア、硝酸塩、硝酸塩の世界最大の生産国でもあります。 NPK 肥料。 したがって、彼らの生産セグメントは、安全性、環境フットプリント、品質、生産コストなどの指標で世界をリードするという明確な野心を持って、使命を果たすための不可欠な構成要素です。 Yara の長期目標は、排出ゼロで低コストの「未来の工場」です。
Yara はリーン トランスフォーメーションに基づいて、デジタル ソリューションへの注力を強化し、目標の達成を支援しています。 この取り組みを主導するために、ヤラはデジタル プロダクションと呼ばれるグローバル ユニットを設立しました。 デジタル プロダクションとそのソリューションの成功は、Yara にとって重要な優先事項であり、Yara はこの分野での取り組みを大幅に拡大しました。 重要な重点分野は、業務の一環として生成される膨大な量のデータを活用することです。 したがって、Yara は、生産の最適化、製品の品質の向上、生産現場の信頼性の向上、排出量の削減、労働者の安全性と生産性の向上、手動プロセスの自動化などに役立つデータ駆動型の製品を構築しています。
エネルギーは、多くの生産工場にとって主要なコスト要素です。 したがって、エネルギー効率は収益性に大きな影響を与えます。 ただし、優れたパフォーマンスがどのようなもので、どのようにしてそこに到達するかについての確固たる参考文献が不足していることがよくあります。 Yara のエネルギー負荷曲線 (ELC) は、現在のパフォーマンスに対して保持されたエネルギー消費に関する過去の最高のパフォーマンスを使用するソリューションです。 現在の消費量が過去の最高値から大きく外れている場合、ツールはエネルギー消費量を抑えるためにオペレータに推奨事項を提供します。
ELC を生産工場に展開し、それを世界中の複数のサイトに拡張するために、Yara は MLOps プラットフォームを構築する必要がありました。 これにより、Yara は確実かつ効率的にモデルをトレーニング、展開、維持することができます。 さらに、これを複数のサイトに拡張するために、Yara は展開とメンテナンスのプロセスを自動化する必要がありました。 この投稿では、Yara がどのように使用しているかについて説明します アマゾンセージメーカー モデルレジストリを含む機能 Amazon SageMakerモデルモニター, AmazonSageMakerパイプライン MLOps プラクティスを自動化および標準化することにより、機械学習 (ML) ライフサイクルを合理化します。 セットアップの概要を説明し、世界中のプラントの ML モデルを構築、トレーニング、デプロイ、監視するプロセスを紹介します。
ソリューションの概要
ELC は、プラントからのモノのインターネット (IoT) センサー データを使用します。 これらのセンサーは、生産スループット、周囲条件、原材料の状態などのメトリックを測定します。このデータは、エネルギー予測モデルのトレーニングに使用され、その後、XNUMX 時間ごとの予測を生成するために使用されます。 プラントのオペレーターは、実際のエネルギー消費量を監視し、ELC が予測した最適な消費量と比較します。 現在のエネルギー消費量が最適ポイントから大きく外れている場合、ELC は分析モデルに基づいてエネルギー効率を最適化するために内部プロセス変数を調整するアクションを提供します。
ELC はクラウドでホストされています。 プラントからセンサー データをリアルタイムでストリーミングするために、Yara は以下を使用します。 AWS IoT Greengrass と安全に通信する AWS IoTコア IoT データを AWS クラウドにエクスポートします。 AWS IoT サイトワイズ は、産業機器から機器データを大規模に収集、整理、検索、および使用できるマネージド サービスです。 Yara は以下を使用して API を構築しました アマゾンAPIゲートウェイ センサー データを ELC などのアプリケーションに公開します。
ELC アプリケーション バックエンドは Amazon ECS 経由でデプロイされ、プラント オペレータが使用するフロント エンドの ELC ダッシュボードを強化します。 ELC アプリケーションは、XNUMX 時間ごとの予測エネルギー消費指標をプラント オペレータに提供する役割を果たします。 エネルギー消費特性が異なるため、各プラントには独自のモデルが取り付けられています。 さらに、植物はその場所に基づいて異なる AWS リージョンにクラスター化されます。
次の図は、このアーキテクチャを示しています。
ELC を構築し、複数のプラントにスケーリングするには、以下をサポートする MLOps ソリューションが必要でした。
- スケーラビリティ – データ量に応じて拡張できます。 一部のプラントは、他のプラントよりも多くのデータを生成します。 各プラントは、XNUMX 日あたり数ギガバイトのデータを生成できます。
- 拡張性 – 新しいリージョンとアカウントに展開できます。
- 再現性 – 新しいプラントのオンボードに使用できる共通のテンプレートがあります。
- 柔軟性 – 各プラントのニーズに基づいて展開構成を変更できます。
- 信頼性と監視 – テストを実行し、アクティブなすべてのプラントのステータスを明確に把握できます。 障害が発生した場合は、以前の安定した状態にロールバックできます。
- メンテナンス – ソリューションのメンテナンス オーバーヘッドは低くなければなりません。 インフラストラクチャのフットプリントを削減するために、可能な場合はサーバーレス サービスを使用する必要があります。
ML について、Yara は SageMaker を使用することにしました。 SageMaker は、ML ワークフロー全体をカバーするフルマネージド サービスです。 SageMaker を選択する際には、次の機能が重要でした。
- SageMaker フレームワークコンテナ – Yara は TensorFlow で ELC 予測モデルをトレーニングし、SageMaker フレームワーク コンテナーを使用して、Yara は最小限のコード変更でこれらのモデルを SageMaker にリフト アンド シフトすることができました。
- SageMakerパイプライン – SageMaker Pipelines は、データ サイエンティストが ML パイプラインを作成するための Python インターフェースを提供します。 ELC コードの大部分は、Python で定義されたトレーニングと推論パイプラインで構成されています。
- SageMakerモデルレジストリ – SageMaker モデルレジストリにより、モデルのカタログ化とバージョン管理が可能になります。 さらに、トレーニング メトリックなどのモデル メタデータの管理が容易になります。
- SageMakerモデルモニター – Yara は、受信データの品質と分布、および ELC モデルのパフォーマンスを監視したいと考えていました。 SageMaker Model Monitor API は、データとモデルの品質モニタリングを提供します。
ML パイプラインの継続的インテグレーションと継続的デリバリー (CI/CD) を管理するために、Yara は以下を使用します。 Amazon デプロイ フレームワーク （ADF）。 ADF は、AWS 組織内の複数の AWS アカウントとリージョンにわたってリソースを管理およびデプロイするために、AWS によって開発されたオープンソース フレームワークです。 ADF では、で定義された構造を介して、アプリケーションまたはリソースの段階的、並列、マルチアカウント、およびリージョン間のデプロイが可能です。 AWS組織などのサービスを利用しながら、 AWS コードパイプライン, AWS コードビルド, AWS コードコミット, AWS CloudFormation 従来の CI/CD セットアップと比較して、手間のかかる作業と管理を軽減します。
ソリューションの概要
MLOps プラットフォームのソリューション全体は、 AWSプロフェッショナルサービス. このプロジェクトに取り組んでいるチームは、データ サイエンティスト、データ エンジニア、および DevOps スペシャリストで構成されていました。 マルチチーム環境での迅速な開発を促進するために、Yara は以下を使用することを選択しました AWS ランディング ゾーne さまざまな AWS アカウントを一元的に作成、管理、管理する組織。 たとえば、Yara には中央展開アカウントがあり、ワークロード アカウントを使用してビジネス アプリケーションをホストしています。 ELC はプロセス最適化のユース ケースであり、ワークロード アカウントを最適化するために展開されます。 Yara Digital Production チームは、最適化以外の分野での ML ユースケースにも取り組んでいます。 MLOps フレームワークは、組織を介してアカウントが作成されている限り、任意のワークロード アカウントへのデプロイをサポートします。
次の図は、このアーキテクチャを示しています。
中央展開アカウントを使用すると、共通のアーティファクトと CI/CD パイプラインを簡単に管理できます。 これらの一般的なアーティファクトのアクセス管理とセキュリティに関しては、アクセス許可の境界と暗号化キーが XNUMX か所で集中管理されるため、よりシンプルな設計になります。 以下のセクションでは、新しいユース ケースを Yara の MLOps プラットフォームにオンボードするために必要な手順について説明します。
アカウント戦略に関しては、Yara にはサンドボックス、DEV、TEST、および PROD のセットアップがあります。 サンドボックス アカウントは、実験や新しいアイデアの試行に使用されます。 DEV アカウントは CI/CD パイプラインの開始点であり、すべての開発はここから始まります。 デプロイ アカウントには CI/CD パイプライン定義が含まれており、DEV、TEST、および PROD アカウントにデプロイできます。 このアカウント設定を次の図に示します。
新しいユースケースのオンボーディング
この投稿では、ユースケースの実用的なプロトタイプがあり、それを運用したいと考えています。 このユース ケースが新しい製品領域に属している場合、最初に Organizations を使用してアカウントをプロビジョニングする必要があります。これにより、ADF が自動的にトリガーされ、これらのアカウントの展開がブートストラップされます。 Yara は DEV>TEST>PROD アカウント戦略に従います。 ただし、この構成は必須ではありません。 データ アカウントはデータ アクセス用の API を公開します。新しいユース ケースでは、ロールに必要な権限を付与する必要があります。 AWS IDおよびアクセス管理 (IAM) 権限を付与して、Data API にアクセスできるようにします。
次に、このユースケースがデプロイされるアカウントを定義する必要があります。 これは、ADF のデプロイメント マップを使用して行われます。 デプロイ マップは、パイプラインのステージとターゲットのマッピングを含む構成ファイルです。 デプロイ マップを実行するために、ADF は CodePipeline を使用します。 ADF は、スタックがデプロイされるターゲット環境ごとにパラメーターを管理する柔軟性を提供します。 これにより、デプロイメントの管理と小さなインスタンスでのテストが容易になります。
コード、データ、モデル ファイルなどのすべてのアーティファクトを暗号化するために、 AWSキー管理サービス (AWS KMS) キー。 サーバー側の暗号化も使用できます。 ただし、生成されたアーティファクトの一部はアカウント間でアクセスされるため、独自のキーを生成し、そのアクセス許可ポリシーを管理してクロスアカウント アクセスを許可する必要があります。
最後に、モデル パッケージ グループを作成して、SageMaker モデル レジストリを使用して異なるバージョンのモデルをグループ化する必要があります。これは、モデルが ML ライフサイクルを移動するときにモデルを追跡および管理する SageMaker の機能です。
モデル トレーニング パイプライン
ELC にオンボーディングされた新しいプラントごとに、新しい SageMaker トレーニング パイプラインを作成します。 このパイプラインは、データの前処理とモデルのトレーニング ステップで構成されます。 SageMaker パイプラインは、ML ワークフローを定義するための Python インターフェースを提供するため、Yara に適しています。 さらに、ワークフローのさまざまなステップを構成して、異なるスケーリングを行うことができます。 たとえば、モデル評価ステップよりもトレーニング用にはるかに大きなインスタンスを定義できます。 パイプラインの各ステップの入力パラメーターと出力パラメーターが保存されるため、各実行とその出力を簡単に追跡できます。 トレーニング ワークフローの概要は次のとおりです。
モデル評価段階の一部として、評価データセットを使用して、トレーニング済みモデルの精度や二乗平均誤差 (RMSE) 偏差などの指標を生成します。 これらのメトリックは、モデルをモデル レジストリに登録する前に、モデル メタデータに追加されます。 現在、モデルは手動でより高い環境に昇格され、モデル承認者はモデル メトリックを表示して、新しいバージョンが現在のモデルよりも優れたパフォーマンスを発揮することを確認できます。
モデルはモデル レジストリでバージョン管理され、各プラントには独自のモデル パッケージ グループがあります。 さらに、モデル レジストリを使用して、どのモデル バージョンがどの環境にデプロイされているかを追跡できます。 モデルは 拒否され, 手動承認待ちまたは 承認 状態、および状態にあるモデルのみ 承認 状態で展開できます。 これにより、モデルの承認されていないバージョンを誤って展開することからの保護も提供されます。
モデルの推論とモニタリングのパイプライン
モデルをデプロイしてモデル監視をセットアップするために、XNUMX つ目の SageMaker パイプラインをセットアップします。 ELC アプリケーションは、プラント オペレータにオンデマンドで予測を提供するため、ELC バックエンドから行われる API 呼び出しを介してモデルにアクセスします。 SageMaker 推論エンドポイントは、API レイヤーを備えたフルマネージド モデル ホスティング ソリューションを提供します。 エンドポイントはモデル入力をペイロードとして受け取り、予測を返します。 遅延は、更新された予測を取得するまで長く待ちたくないエンドユーザーにとっても重要な要素であるため、Yara は SageMaker リアルタイム推論エンドポイントを選択しました。これは、遅延要件が非常に低いワークロードに特に適しています。 最後に、更新されたモデルがデプロイされている間、ELC アプリケーションはダウンタイムを持つことができないため、SageMaker リアルタイム エンドポイントのブルー/グリーン デプロイ機能に依存して、新しいバージョンがデプロイされるまで古いモデル バージョンが予測を提供し続けることを保証します。 .
次の図は、展開と監視のセットアップを示しています。
モデルのモニタリングのために、Yara は SageMaker を実行します データ品質, モデルの品質, モデルの説明可能性 モニタリング。 データ品質モニタリングは、一貫性をチェックし、データ分散統計を生成します。 モデル品質モニタリングは、モデルのパフォーマンスをチェックし、モデルの精度をトレーニング メトリックと比較します. モデル監視レポートは、XNUMX 時間ごとに生成されます。 これらのレポートは、本番環境でのモデルのパフォーマンスを監視するために使用されます。 モデルの説明可能性モニタリングは、どの機能が予測に最も貢献するかを理解するために使用されます。
このモデルの説明可能性の結果は、ELC ダッシュボードで共有され、エネルギー消費の原動力についてより多くのコンテキストをプラント オペレータに提供します。 これは、エネルギー消費が最適なポイントから逸脱した場合に、内部プロセスを調整するためのアクションの決定もサポートします。
CI/CD フロー
トレーニング パイプラインの CI/CD フローは、DEV アカウントで開始されます。 Yara は機能ベースの開発モデルに従っており、新しい機能が開発されると、機能ブランチがトランクにマージされ、展開が開始されます。 ELC モデルは DEV アカウントでトレーニングされ、モデルがトレーニングおよび評価された後、モデル レジストリに登録されます。 モデルの承認者は、モデルのステータスを更新する前にサニティ チェックを実行します。 承認. このアクションにより、モデル推論パイプラインのデプロイをトリガーするイベントが生成されます。 モデル推論パイプラインは、新しいモデル バージョンを DEV の SageMaker エンドポイントにデプロイします。
エンドポイントのデプロイ後、セットアップの動作を確認するためのテストが開始されます。 テストのために、Yara は CodeBuild テスト レポート. この機能により、開発者は、単体テスト、構成テスト、機能テストを展開前と展開後に実行できます。 この場合、Yara は、テスト ペイロードを SageMaker エンドポイントに渡し、応答を評価することで、機能テストを実行します。 これらのテストに合格すると、パイプラインは SageMaker エンドポイントを TEST にデプロイします。 ELC バックエンドも TEST にデプロイされるため、この環境でアプリのエンド ツー エンドのテストが可能になります。 さらに、Yara は TEST でユーザー受け入れテストを実行します。 TEST から PROD 展開へのトリガーは、手動の承認アクションです。 新しいモデル バージョンが TEST での機能テストとユーザー受け入れテストの両方に合格した後、エンジニアリング チームは PROD へのモデルの展開を承認します。
次の図は、このワークフローを示しています。
一般的なコンポーネント
ELC では、すべての展開段階 (DEV、TEST、PROD) とモデルに共通するいくつかのコンポーネントを使用します。 これらのコンポーネントはデプロイ アカウントに存在し、モデルのバージョン管理、コンテナー イメージ リポジトリ、暗号化キー、および共通のアーティファクトを格納するためのバケットが含まれます。
共通成果物を使用することには、いくつかの利点があります。 たとえば、すべてのアカウントに対してリソースを作成する必要がないため、アカウント間の互換性が確保されます。 つまり、コンテナー イメージを一度ビルドすると、すべてのターゲット アカウントで再利用できるため、ビルド時間が短縮されます。
このパイプラインは、さまざまなモデル バージョンをデプロイ アカウントの共通モデル レジストリに格納します。 この中央の場所から、モデルを転送せずにすべてのアカウントに展開できます。 同様に、一元的に保存された暗号化キーを使用すると、キーとクロスアカウントのアクセス許可を簡単に管理できます。
一般的なアーティファクトを使用することの欠点の XNUMX つは、新しいユース ケースのオンボーディング手順がより複雑になる可能性があることです。 新しいユース ケースをオンボードするには、新しいモデル レジストリを作成し、必要に応じて新しいコンテナー イメージ リポジトリを作成する必要があります。 また、リソースと保存されたデータを厳密に分離するために、新しい暗号化キーを作成することをお勧めします。
まとめ
この投稿では、Yara が SageMaker と ADF を使用して高度にスケーラブルな MLOps プラットフォームを構築する方法を示しました。 ML は機能横断的な機能であり、チームはモデルをさまざまなビジネス ユニット アカウントに展開します。 したがって、Organizations とのネイティブ統合を提供する ADF は、アカウントをブートストラップして CI/CD パイプラインをセットアップするための理想的な候補になります。 運用上、ADF パイプラインは中央のデプロイ アカウントで実行されるため、デプロイの全体的な状態を簡単に把握できます。 最後に、ADF は CodeBuild、CodeDeploy、CodePipeline、CloudFormation などの AWS マネージド サービスを使用して、構成と保守を容易にします。
SageMaker は、幅広い ML 機能を提供します。これにより、チームは、インフラストラクチャの構築と保守よりも、ビジネス上の問題の解決により集中できるようになります。 さらに、SageMaker Pipelines は、ML ワークフローを作成、更新、およびデプロイするための API の豊富なセットを提供するため、MLOps に最適です。
最後に、MLOps は、本番環境で ML モデルを確実かつ効率的にデプロイおよび維持するためのベスト プラクティスを提供します。 大規模な ML ソリューションを作成してデプロイするチームにとって、MLOps を実装することは重要です。 Yara の場合、MLOps は、新しいプラントのオンボーディング、ELC への更新の展開、およびモデルの品質の監視に必要な労力を大幅に削減します。
ADF を使用してアプリケーションをデプロイする方法の詳細については、 例.
著者について
シャヒール・マンスール AWS のデータサイエンティストです。 彼は、AI ソリューションを大規模にホストできる機械学習プラットフォームの構築に重点を置いています。 彼が興味を持っている分野は、MLOps、フィーチャー ストア、モデル ホスティング、およびモデル モニタリングです。
ティム・ベッカー Yara International のシニア データ サイエンティストです。 デジタル プロダクション内では、アンモニアと硝酸の生産プロセスの最適化に重点を置いています。 彼は熱力学の博士号を取得しており、プロセス エンジニアリングと機械学習を結びつけることに情熱を注いでいます。
ヨンギョス・ケオピタクン Yara International のデジタル プロダクション チームのシニア データ サイエンティストです。 彼は AI/機械学習の博士号を取得しており、機械学習、コンピューター ビジョン、自然言語処理モデルを活用して困難なビジネス上の問題を解決するための長年の実務経験があります。
