[概要]前提条件と制限アーキテクチャツールベストプラクティスエピックトラブルシューティング関連リソース

Amazon SageMaker と Azure を使用して MLOps ワークフローを構築する DevOps

ディーピカ・クマール（AWS）とサラ・ヴァン・デ・ムースダイク（AWS）によって作成されました

環境:本稼働	テクノロジー:機械学習 & AI; オペレーション DevOps	ワークロード： Microsoft
AWS サービス:Amazon API Gateway; Amazon ECR; Amazon EventBridge; AWS Lambda; Amazon SageMaker

[概要]

機械学習オペレーション (MLOps) は、機械学習 (ML) のワークフローとデプロイを自動化および簡素化する一連のプラクティスです。MLOps は ML ライフサイクルの自動化に重点を置いています。これにより、モデルを開発するだけでなく、デプロイ、監視、再トレーニングを体系的かつ繰り返し行えるようになります。 DevOps 機械学習に原則をもたらします。MLOps により、ML モデルの展開が速くなり、時間が経つにつれて精度が向上し、実際のビジネス価値がもたらされるという保証が強化されます。

多くの場合、Organizations は MLOps の導入を開始する前に、 DevOps 既存のツールやデータストレージソリューションを用意しています。このパターンは、Microsoft Azure と AWS の両方の長所を活用する方法を示しています。Azure DevOps と Amazon SageMaker を統合して MLOps ワークフローを作成するのに役立ちます。

このソリューションにより、Azure と AWS 間の作業が簡単になります。開発には Azure を、機械学習には AWS を使用できます。データ処理、トレーニング、AWS へのデプロイなど、機械学習モデルを最初から最後まで作成するための効果的なプロセスを促進します。効率を上げるために、これらのプロセスは Azure DevOps パイプラインを通じて管理します。

前提条件と制限

前提条件

Azure サブスクリプション — Azure などの Azure サービスにアクセスして DevOps、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを設定します。
アクティブ AWS アカウント — このパターンで使用される AWS サービスを使用する権限。
データ — 機械学習モデルをトレーニングするための履歴データへのアクセス。
ML の概念に精通していること — Python、Jupyter ノートブック、機械学習モデル開発についての理解
セキュリティ設定 — Azure と AWS の両方でロール、ポリシー、権限を適切に構成して、安全なデータ転送とアクセスを確保します。

制約事項

このガイダンスは、クラウド間の安全なデータ転送に関するガイダンスを提供するものではありません。クロスクラウドデータ転送の詳細については、「ハイブリッドおよびマルチクラウド向けの AWS ソリューション」を参照してください。
マルチクラウドソリューションでは、リアルタイムのデータ処理とモデル推論のレイテンシーが増加する可能性があります。
このガイダンスでは、マルチアカウント MLOps アーキテクチャの一例を紹介します。機械学習と AWS 戦略に基づいて調整する必要があります。

アーキテクチャ

ターゲットアーキテクチャ

ターゲットアーキテクチャは Azure DevOps と Amazon を統合し SageMaker、クロスクラウド ML ワークフローを作成します。CI/CD プロセスと ML SageMaker モデルのトレーニングとデプロイに Azure を使用しています。モデル構築とデプロイを通じて (Amazon S3、Snowflake、Azure Data Lake などのソースから) データを取得するプロセスの概要を説明しています。主なコンポーネントには、モデルの構築とデプロイ、データ準備、インフラストラクチャ管理用の CI/CD パイプライン、ML モデルのトレーニング、評価、 SageMaker デプロイ用の Amazon などがあります。このアーキテクチャは、クラウドプラットフォーム全体で効率的で自動化された、スケーラブルな ML ワークフローを提供するように設計されています。

Azure DevOps を使用する MLOps ワークフローのアーキテクチャ図と SageMaker

このアーキテクチャは、以下のコンポーネントで構成されています。

データサイエンティストは開発アカウントで ML 実験を行い、さまざまなデータソースを使用して ML ユースケースのさまざまなアプローチを検討します。データサイエンティストは単体テストとトライアルを行います。モデル評価の後、データサイエンティストは Azure でホストされている Model Build DevOps リポジトリにコードをプッシュしてマージします。このリポジトリには、多段階のモデル構築パイプラインのコードが含まれています。
Azure では DevOps、継続的インテグレーション (CI) を提供するモデルビルドパイプラインは、メインブランチへのコードのマージ時に自動または手動でアクティブ化できます。Automation アカウントでは、これによりデータの前処理、モデルトレーニングと評価、 SageMaker 精度に基づく条件付きモデル登録のためのパイプラインがアクティブ化されます。
自動化アカウントは、ML 環境 (Amazon ECR)、モデル (Amazon S3)、モデルメタデータ (SageMaker モデルレジストリ)、機能 (SageMaker 機能ストア)、自動パイプライン (パイプライン)、および ML ログインサイト (SageMaker CloudWatch OpenSearch およびサービス) をホストする ML プラットフォーム全体の中央アカウントです。このアカウントにより ML アセットの再利用が可能になり、ベストプラクティスを適用して ML ユースケースの配信を迅速化できます。
SageMaker 最新のモデルバージョンがモデルレジストリに追加され、レビューされます。モデルバージョンとそれぞれのアーティファクト (系統とメタデータ) を追跡します。また、モデルのステータス (承認、拒否、保留中) を管理し、ダウンストリーム展開用のバージョンを管理します。
Model Registry のトレーニング済みモデルがスタジオインターフェイスまたは API 呼び出しで承認されたら、イベントを Amazon に送信できます。 EventBridge EventBridge Azure でモデルデプロイパイプラインを開始します。 DevOps
継続的デプロイ (CD) を提供するモデルデプロイパイプラインは、Model Deploy リポジトリからソースをチェックアウトします。ソースには、コード、モデルデプロイ用の設定、品質ベンチマーク用のテストスクリプトが含まれています。Model Deploy パイプラインは、推論タイプに合わせてカスタマイズできます。
品質管理チェックの後、Model Deploy パイプラインはモデルをステージングアカウントにデプロイします。ステージングアカウントはプロダクションアカウントのコピーで、統合テストと評価に使用されます。バッチ変換の場合、Model Deploy パイプラインは、承認された最新のモデルバージョンを使用するようにバッチ推論プロセスを自動的に更新できます。リアルタイム、サーバーレス、または非同期の推論では、それぞれのモデルエンドポイントを設定または更新します。
ステージングアカウントでのテストが成功したら、Model Deploy パイプラインを通じて手動で承認することで、モデルをプロダクションアカウントにデプロイできます。このパイプラインは、Deploy to Production ステップで、モデル監視やデータフィードバックメカニズムを含む本番環境のエンドポイントをプロビジョニングします。
モデルが本番稼働状態になったら、 SageMaker Model Monitor や SageMaker Clarify などのツールを使用して、バイアスの特定、ドリフトの検出、モデルのパフォーマンスの継続的な監視を行います。

自動化とスケール

コードとしてのインフラストラクチャ (IaC) を使用して、複数のアカウントや環境に自動的にデプロイします。MLOps ワークフローの設定プロセスを自動化することで、さまざまなプロジェクトに取り組む ML チームが使用する環境を分離できます。AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS リソースのモデル化、プロビジョニング、管理を支援します。

ツール

AWS サービス

Amazon SageMaker はマネージド型の ML サービスで、ML モデルを構築してトレーニングし、本番環境ですぐに運用できるホスト環境にデプロイできます。
AWS Glue は、フルマネージド型の抽出、変換、ロード (ETL) サービスです。これにより、データストアとデータストリーム間でのデータの分類、整理、強化、移動を確実に行うことができます。
Amazon Simple Storage Service (Amazon S3) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。このパターンでは、Amazon S3 はデータストレージに使用され、モデルトレーニングとモデルオブジェクトに統合されます。 SageMaker
AWS Lambda は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。このパターンでは、Lamdba はデータの前処理と後処理のタスクに使用されます。
Amazon Elastic Container Registry (Amazon ECR) は、セキュリティ、スケーラビリティ、信頼性を備えたマネージドコンテナイメージレジストリサービスです。このパターンでは、 SageMaker トレーニング環境やデプロイ環境として使用する Docker コンテナを格納します。
Amazon EventBridge はサーバーレスのイベントバスサービスで、アプリケーションをさまざまなソースからのリアルタイムデータに接続するのに役立ちます。このパターンでは、 EventBridge イベント駆動型または時間ベースのワークフローをオーケストレーションして、モデルの自動再トレーニングまたはデプロイを開始します。
Amazon API Gateway は、REST、HTTP、および WebSocket API をあらゆる規模で作成、公開、保守、モニタリング、保護するのに役立ちます。このパターンでは、Amazon エンドポイントの外部向けの単一エントリポイントを作成するために使用されます。 SageMaker

その他のツール

Azure DevOps は CI/CD パイプラインの管理を支援し、コードのビルド、テスト、デプロイを容易にします。
Azure データレイクストレージや Snowflake は、ML モデルのトレーニングデータのサードパーティソースになる可能性があります。

ベストプラクティス

このマルチクラウド MLOps ワークフローのコンポーネントを実装する前に、以下のアクティビティを完了してください。

機械学習のワークフローとそれをサポートするのに必要なツールを定義し、理解してください。ユースケースが異なれば、必要なワークフローやコンポーネントも異なります。たとえば、パーソナライゼーションのユースケースではフィーチャの再利用や低レイテンシの推論にはフィーチャfeature store が必要ですが、他のユースケースでは必要ない場合があります。アーキテクチャをうまくカスタマイズするには、データサイエンスチームの対象となるワークフロー、ユースケース要件、および推奨コラボレーション方法を理解する必要があります。
アーキテクチャの各コンポーネントについて、責任を明確に分離してください。データストレージを Azure データレイクストレージ、スノーフレーク、Amazon S3 に分散させると、複雑さとコストが増す可能性があります。可能であれば、一貫性のあるストレージメカニズムを選択してください。同様に、Azure と AWS DevOps のサービスを組み合わせて使用したり、Azure と AWS ML サービスを組み合わせて使用したりすることは避けてください。
MLOps end-to-end ワークフローのテストを行うには、既存のモデルとデータセットを 1 つ以上選択してください。テストアーティファクトには、プラットフォームが本番環境に移行したときにデータサイエンスチームが開発する実際のユースケースが反映されている必要があります。

エピック

タスク	説明	必要なスキル
データソースを特定する。	現在およびfuture ユースケース、利用可能なデータソース、データの種類（機密データなど）に基づいて、MLOps プラットフォームとの統合が必要なデータソースを文書化します。データは Amazon S3、Azure データレイクストレージ、スノーフレーク、またはその他のソースに保存できます。これらのソースをプラットフォームと統合し、適切なリソースへのアクセスを保護するための計画を立ててください。	データエンジニア、データサイエンティスト、クラウドアーキテクト
該当するサービスを選択してください。	データサイエンスチームの希望するワークフロー、該当するデータソース、既存のクラウドアーキテクチャに基づいてサービスを追加または削除して、アーキテクチャをカスタマイズします。たとえば、データエンジニアやデータサイエンティストは SageMaker、AWS Glue や Amazon EMR でデータの前処理や機能エンジニアリングを行うことができます。3 つのサービスすべてが必要になることはまずありません。	AWS 管理者、データエンジニア、データサイエンティスト、ML エンジニア
セキュリティ要件を分析します。	セキュリティ要件を収集して文書化する。これには以下の決定が含まれます。どのチームまたはエンジニアが特定のデータソースにアクセスできるかチームが他のチームのコードやモデルにアクセスすることを許可されているかどうか開発用以外のアカウントについて、チームメンバーが (もしあれば) 持つべき権限クラウド間のデータ転送にはどのセキュリティ対策を実装する必要があるか	AWS 管理者、クラウドアーキテクト

タスク	説明	必要なスキル
AWS Organizations を設定します。	ルート AWS アカウントに AWS Organizations を設定します。これにより、マルチアカウント MLOps 戦略の一環として今後作成するアカウントを管理しやすくなります。詳細については、AWS Organizations ドキュメントを参照してください。	AWS 管理者

タスク	説明	必要なスキル
AWS 開発アカウントを作成します。	データエンジニアとデータサイエンティストが ML モデルを試したり作成したりする権限を持つ AWS アカウントを作成します。手順については、AWS Organizations ドキュメントの「組織でのメンバーアカウントの作成」を参照してください。	AWS 管理者
`Model Build` リポジトリを作成します。	Azure に Git リポジトリを作成して、実験フェーズの完了後にデータサイエンティストがモデルビルドとデプロイコードをプッシュできるようにします。手順については、Azure DevOps ドキュメントの「Git リポジトリのセットアップ」を参照してください。	DevOps エンジニア、ML エンジニア
`Model Deploy` リポジトリを作成します。	標準のデプロイコードとテンプレートを格納する Git リポジトリを Azure に作成します。設計段階で特定したとおりに、組織が使用するすべてのデプロイオプションのコードを含める必要があります。たとえば、リアルタイムエンドポイント、非同期エンドポイント、サーバーレス推論、バッチトランスフォームなどを含める必要があります。手順については、Azure DevOps ドキュメントの「Git リポジトリのセットアップ」を参照してください。	DevOps エンジニア、ML エンジニア
Amazon ECR リポジトリを作成します。	承認された ML 環境を Docker イメージとして保存する Amazon ECR リポジトリを設定します。データサイエンティストと ML エンジニアが新しい環境を定義できるようにします。手順については、Amazon ECR ドキュメントの「プライベートリポジトリの作成」を参照してください。	ML エンジニア
SageMaker Studio をセットアップします。	以前に定義したセキュリティ要件と、選択した統合開発環境 (IDE) などの推奨データサイエンスツールに従って、開発アカウントに SageMaker Studio を設定します。ライフサイクル構成を使用して主要機能のインストールを自動化し、データサイエンティスト向けの統一された開発環境を構築します。詳細については、 SageMaker ドキュメントの「Amazon SageMaker Studio」を参照してください。	ML エンジニア、データサイエンティスト

タスク	説明	必要なスキル
自動化アカウントを作成する。	自動パイプラインとジョブを実行する AWS アカウントを作成します。データサイエンスチームにこのアカウントへの読み取り権限を付与できます。手順については、AWS Organizations ドキュメントの「組織でのメンバーアカウントの作成」を参照してください。	AWS 管理者
モデルレジストリを設定します。	Automation SageMaker アカウントでモデルレジストリを設定します。このレジストリには ML モデルのメタデータが保存され、特定のデータサイエンティストやチームリーダーがモデルを承認または却下する際に役立ちます。詳細については、ドキュメントの「モデルレジストリへのモデルの登録とデプロイ」を参照してください。 SageMaker	ML エンジニア
`Model Build`パイプラインを作成します。	Azure で、コードがリポジトリにプッシュされると手動または自動的に起動する CI/CD パイプラインを作成します。`Model Build`パイプラインはソースコードをチェックアウトし、Automation SageMaker アカウントでパイプラインを作成または更新する必要があります。パイプラインはモデルレジストリに新しいモデルを追加する必要があります。パイプラインの作成について詳しくは、Azure Pipelines のドキュメントをご覧ください。	DevOps エンジニア、ML エンジニア

タスク	説明	必要なスキル
AWS のステージングアカウントとデプロイアカウントを作成します。	ML モデルのステージングとデプロイ用の AWS アカウントを作成します。本番環境に移行する前にステージング環境でモデルを正確にテストできるように、これらのアカウントは同一である必要があります。データサイエンスチームにステージングアカウントへの読み取り権限を付与できます。手順については、AWS Organizations ドキュメントの「組織でのメンバーアカウントの作成」を参照してください。	AWS 管理者
モデルモニタリング用に S3 バケットを設定します。	`Model Deploy`パイプラインによって作成されたデプロイ済みモデルのモデルモニタリングを有効にする場合は、このステップを完了してください。入出力データを保存するための Amazon S3 バケットを作成します。S3 バケットの作成の詳細については、Amazon S3 ドキュメントの「バケットの作成」を参照してください。自動モデルモニタリングジョブが Automation アカウントで実行されるように、クロスアカウント権限を設定します。詳細については、 SageMaker ドキュメントの「データとモデル品質の監視」を参照してください。	ML エンジニア
`Model Deploy`パイプラインを作成する。	Azure で CI/CD パイプラインを作成します。このパイプラインは、モデルがモデルレジストリで承認された時点で開始されます。パイプラインでは、ソースコードとモデルアーティファクトをチェックアウトし、ステージングアカウントとプロダクションアカウントにモデルをデプロイするためのインフラストラクチャテンプレートを構築し、ステージングアカウントにモデルをデプロイし、自動テストを実行し、手動承認を待って、承認されたモデルをプロダクションアカウントにデプロイする必要があります。パイプラインの作成について詳しくは、Azure Pipelines のドキュメントをご覧ください。	DevOps エンジニア、ML エンジニア

タスク	説明	必要なスキル
AWS CDK CloudFormation またはテンプレートをビルドします。	自動的にデプロイする必要があるすべての環境用の AWS Cloud Development Kit (AWS CDK) または AWS CloudFormation テンプレートを定義します。これには、開発環境、自動化環境、ステージング環境とデプロイ環境が含まれる場合があります。詳細については、AWS CDK CloudFormationとドキュメントを参照してください。	AWS DevOps
`Infrastructure`パイプラインを作成する。	Azure でインフラストラクチャをデプロイするための CI/CD パイプラインを作成します。管理者はこのパイプラインを開始して、新しい AWS アカウントを作成し、ML チームが必要とする環境を設定できます。	DevOps エンジニア

トラブルシューティング

問題	ソリューション
不十分な監視とドリフト検出 — 監視が不十分だと、モデルのパフォーマンスの問題やデータドリフトの検出に失敗する可能性があります。	Amazon CloudWatch、 SageMaker モデルモニター、 SageMaker クラリファイなどのツールでモニタリングフレームワークを強化します。特定された問題に直ちに対応するようにアラートを設定します。
CI パイプライントリガーエラー — Azure の CI パイプラインは、 DevOps 設定ミスによりコードのマージ時にトリガーされない場合があります。	Azure DevOps プロジェクトの設定をチェックして、Webhook が正しく設定され、正しいエンドポイントを指していることを確認します。 SageMaker
ガバナンス — 中央の Automation アカウントでは ML プラットフォーム全体でベストプラクティスが適用されないため、ワークフローに一貫性がなくなる可能性があります。	Automation アカウントの設定を監査し、すべての ML 環境とモデルが事前に定義されたベストプラクティスとポリシーに準拠していることを確認します。
モデルレジストリの承認遅延 — これは、レビューに時間がかかったり、技術的な問題が原因で、モデルの確認と承認が遅れた場合に発生します。	承認待ちのモデルについて関係者に警告する通知システムを実装し、レビュープロセスを効率化します。
モデル展開イベントの失敗 — モデル展開パイプラインを開始するために送出されたイベントが失敗し、展開が遅れる可能性があります。	Amazon に Azure EventBridge DevOps パイプラインを正常に呼び出すための適切な権限とイベントパターンがあることを確認します。
本番環境へのデプロイのボトルネック — 手動の承認プロセスではボトルネックが生じ、モデルの本番環境へのデプロイが遅れる可能性があります。	モデル展開パイプライン内の承認ワークフローを最適化し、タイムリーなレビューと明確なコミュニケーションチャネルを促進します。