Amazon SageMaker、HashiCorp Terraform、およびGitLab CI/CDを使用したモデルモニタリングと再トレーニングによるバッチ推論のためのMLOps

Amazon SageMaker、HashiCorp Terraform、GitLab CI/CDを使用したMLOpsによるバッチ推論のモデルモニタリングと再トレーニング

機械学習（ML）ワークフローの本番環境における維持は、MLコードとモデルのための継続的な統合と継続的な配信（CI/CD）パイプラインの作成、モデルのバージョニング、データと概念のドリフトの監視、モデルの再学習、およびパフォーマンスとコンプライアンスの要件の両方を満たすための手動承認プロセスが必要なため、課題があります。

この記事では、Amazon SageMaker、Amazon EventBridge、AWS Lambda、Amazon Simple Notification Service（Amazon SNS）、HashiCorp Terraform、およびGitLab CI/CDを使用して、バッチ推論のためのMLOpsワークフローを作成する方法を説明します。提案されたMLOpsワークフローは、自動化、監視、監査可能性、およびスケーラビリティを通じてMLライフサイクルの管理のための再利用可能なテンプレートを提供し、本番環境でのバッチ推論ワークロードの複雑さとコストを削減します。

ソリューションの概要

次の図は、GitLab CI/CDとTerraformのインフラストラクチャ・コード（IaC）を使用する組織のバッチ推論のための提案されたターゲットMLOpsアーキテクチャを示しています。GitLab CI/CDは、ソース取得、ビルド、およびAmazon SageMaker PipelinesとSageMaker Python SDKおよびTerraformを使用してSageMaker Pipelinesと関連リソースのプロビジョニングを含む「モデルビルド」と「モデルデプロイ」のパイプラインをマクロオーケストレータとして提供します。SageMaker Python SDKは、トレーニング、ハイパーパラメータ最適化（HPO）を伴うトレーニング、およびバッチ推論のためのSageMakerパイプラインの作成または更新に使用されます。Terraformは、イベントブリッジルール、Lambda関数、およびSNSトピックなどの追加のリソースを作成するために使用され、SageMakerパイプラインの監視と通知（たとえば、パイプラインステップの失敗または成功時）を行います。SageMaker Pipelinesは、MLモデルのトレーニングと推論のワークフローのオーケストレータとして機能します。

このアーキテクチャ設計は、MLモデルが中央のモデルレジストリにビルド、トレーニング、および登録され、データサイエンス開発アカウント（通常のアプリケーション開発アカウントよりも制御が多い）内で行われるマルチアカウント戦略を表しています。その後、GitLab CI/CDなどのDevOpsツールからステージングアカウントと本番アカウントに推論パイプラインが展開されます。中央のモデルレジストリは、必要に応じて共有サービスアカウントに配置することもできます。MLのマルチアカウント戦略のベストプラクティスに関しては、操作モデルを参照してください。

• 「フレームワークによりロボットは連続した順序で対話的なタスクを実行できる」
• 「効率的な変数選択のための新しいアルゴリズムが提案されました」
• これらの便利なドローンは、空中で結合してより大きく、より強力なロボットを形成することができます

次のサブセクションでは、アーキテクチャ設計のさまざまな側面について詳しく説明します。

インフラストラクチャ・コード

IaCは、機械可読なファイルを使用してITインフラストラクチャを管理する方法を提供し、効率的なバージョン管理を保証します。この記事と添付のコードサンプルでは、HashiCorp TerraformとGitLab CI/CDを使用してAWSリソースを効果的に管理する方法を示しています。このアプローチは、IaCの主な利点であるITインフラストラクチャ管理の透明性と繰り返し可能なプロセスを強調しています。

モデルのトレーニングと再トレーニング

この設計では、SageMakerトレーニングパイプラインはスケジュール（EventBridge経由）またはAmazon Simple Storage Service（Amazon S3）のイベントトリガー（たとえば、トリガーファイルまたは新しいトレーニングデータ（単一のトレーニングデータオブジェクトの場合）がAmazon S3に配置された場合）に基づいて、新しいデータで定期的にモデルを再キャリブレーションします。このパイプラインでは、エンタープライズモデルレビュープロセスで承認された固定ハイパーパラメータを使用するため、モデルに構造的または物質的な変更は導入されません。

トレーニングパイプラインは、モデルが事前定義されたモデルパフォーマンスの閾値（回帰の場合はRMSE、分類の場合はF1スコアなど）を超えた場合、新しくトレーニングされたモデルバージョンをAmazon SageMakerモデルレジストリに登録します。モデルの新しいバージョンがモデルレジストリに登録されると、Amazon SNSを介して責任あるデータサイエンティストに通知がトリガされます。その後、データサイエンティストは、Amazon SageMaker Studio UIまたはAWS Command Line Interface（AWS CLI）またはAWS SDK for Python（Boto3）を使用してAPI呼び出しを行い、新しいバージョンのモデルを推論に利用する前に、モデルの最新バージョンを確認および承認する必要があります。

SageMakerトレーニングパイプラインとそのサポートリソースは、GitLabの「モデルビルド」パイプラインによって作成されます。これは、GitLabパイプラインの手動実行または「モデルビルド」Gitリポジトリの「main」ブランチにコードがマージされたときに自動的に行われます。

バッチ推論

SageMakerのバッチ推論パイプラインは、スケジュール（EventBridgeを介して）またはS3イベントトリガーに基づいて実行されます。バッチ推論パイプラインは、モデルレジストリから最新の承認済みバージョンのモデルを自動的に取得し、推論に使用します。バッチ推論パイプラインには、トレーニングパイプラインによって作成されたベースラインに対するデータ品質のチェックステップ、およびグラウンドトゥルースラベルが利用可能な場合のモデル品質（モデルのパフォーマンス）のチェックステップが含まれています。

バッチ推論パイプラインがデータ品質の問題を発見した場合、Amazon SNSを介して責任あるデータサイエンティストに通知します。モデル品質の問題（例えば、RMSEが事前に指定された閾値を上回る場合）が発見されると、モデル品質チェックのパイプラインステップは失敗し、それによってHPOパイプラインを使用したトレーニングを開始するためのEventBridgeイベントがトリガーされます。

SageMakerのバッチ推論パイプラインおよびそのサポートリソースは、GitLabのmodel deployパイプラインによって作成されます。GitLabパイプラインの手動実行またはmodel deploy Gitリポジトリのmainブランチにコードがマージされた時に自動的に作成されます。

モデルの調整と再調整

バッチ推論パイプラインのモデル品質チェックステップが失敗した場合、SageMakerのHPOパイプラインによるトレーニングがトリガーされます。モデル品質チェックは、モデルの予測と実際のグラウンドトゥルースラベルを比較することで行われます。モデル品質メトリック（例えば、回帰の場合はRMSE、分類の場合はF1スコア）が事前に指定された基準を満たさない場合、モデル品質チェックステップは失敗とマークされます。必要に応じて、責任あるデータサイエンティストはSageMaker Studio UIまたはAWS CLIやSageMaker Python SDKを使用したAPI呼び出しによって、SageMakerのHPOパイプラインを手動でトリガーすることもできます。モデルのハイパーパラメータが変更されるため、新しいモデルバージョンがモデルレジストリで承認される前に、責任あるデータサイエンティストはエンタープライズモデルレビューボードの承認を取得する必要があります。

SageMakerのHPOパイプラインとそのサポートリソースは、GitLabのmodel buildパイプラインによって作成されます。GitLabパイプラインの手動実行またはmodel build Gitリポジトリのmainブランチにコードがマージされた時に自動的に作成されます。

モデルのモニタリング

トレーニングとHPOパイプラインの一部として、データの統計および制約のベースラインが生成されます。これらはAmazon S3に保存され、モデル品質の評価に合格した場合はモデルレジストリにも登録されます。バッチ推論パイプラインの提案されたアーキテクチャでは、データ品質のチェックにはAmazon SageMaker Model Monitorを使用し、モデル品質のチェックにはカスタムのAmazon SageMaker Processingステップを使用します。この設計により、データとモデルの品質チェックを分離することができ、データドリフトが検出された場合には警告通知のみを送信し、モデル品質の違反が検出された場合にはHPOパイプラインのトレーニングをトリガーすることができます。

モデルの承認

新しくトレーニングされたモデルがモデルレジストリに登録されると、責任あるデータサイエンティストは通知を受け取ります。モデルがトレーニングパイプラインによってトレーニングされた場合（ハイパーパラメータは固定されたまま新しいトレーニングデータで再キャリブレーションされる）、企業モデルレビューボードの承認は不要です。データサイエンティストは、モデルの新しいバージョンを独立して確認および承認することができます。一方、モデルがHPOパイプラインによってトレーニングされた場合（ハイパーパラメータを変更して再チューニング）、新しいモデルバージョンは本番推論で使用される前にエンタープライズレビュープロセスを経る必要があります。レビュープロセスが完了すると、データサイエンティストはモデルレジストリでの新しいバージョンの承認を進めることができます。モデルパッケージのステータスをApprovedに変更すると、Lambda関数がEventBridgeを介してトリガーされ、それによってAPI呼び出しを介してGitLabのmodel deployパイプラインがトリガーされます。これにより、SageMakerのバッチ推論パイプラインが最新の承認済みモデルバージョンを推論に使用するように自動的に更新されます。

モデルレジストリで新しいモデルバージョンを承認または拒否する2つの主要な方法があります：AWS SDK for Python（Boto3）を使用するか、SageMaker Studio UIから行うかです。デフォルトでは、トレーニングパイプラインとHPOパイプラインの両方でModelApprovalStatusはPendingManualApprovalに設定されます。責任あるデータサイエンティストは、Boto3からupdate_model_package APIを呼び出すことでモデルの承認ステータスを更新することができます。モデルの承認ステータスの更新方法については、SageMaker Studio UIを介したモデルの承認ステータスの更新の詳細を参照してください。

データの入出力設計

SageMakerは、トレーニングおよび推論パイプラインの個々のステップの入力を読み取り、出力をAmazon S3に直接保存するためにAmazon S3と直接やり取りします。以下の図は、異なるPythonスクリプト、生および加工されたトレーニングデータ、生および加工された推論データ、推論結果およびグラウンドトゥルースラベル（モデル品質モニタリングのために利用可能な場合）、モデルアーティファクト、トレーニングおよび推論評価メトリック（モデル品質モニタリング）、データ品質ベースラインおよび違反レポート（データ品質モニタリング）をS3バケット内でどのように組織するかを示しています。図内の矢印の方向は、SageMakerパイプラインの各ステップの入力または出力ファイルを示しています。矢印は、読みやすくするためにパイプラインステップのタイプに基づいて色分けされています。パイプラインは、GitLabリポジトリからPythonスクリプトを自動的にアップロードし、各ステップの出力ファイルまたはモデルアーティファクトを適切なS3パスに保存します。

データエンジニアは以下の責任を持ちます：

• 適切なパスにラベル付きトレーニングデータをAmazon S3にアップロードする。これには、トレーニングパイプラインとHPOパイプラインが最新のトレーニングデータにアクセスできるように、定期的に新しいトレーニングデータを追加することが含まれます。
• 推論パイプラインの計画された実行前に、入力データをS3バケットの適切なパスにアップロードする。
• モデルの品質監視のために、グラウンドトゥルースラベルを適切なS3パスにアップロードする。

データサイエンティストは以下の責任を持ちます：

• グラウンドトゥルースラベルを準備し、それらをデータエンジニアリングチームに提供してAmazon S3にアップロードする。
• トレーニングしてHPOパイプラインで訓練されたモデルバージョンをエンタープライズレビュープロセスを通じて取得し、必要な承認を得る。
• モデルレジストリで新しくトレーニングされたモデルバージョンを手動で承認または拒否する。
• 推論パイプラインとサポートリソースのプロダクションゲートを承認し、プロダクションに昇格させる。

サンプルコード

このセクションでは、以下のアーキテクチャ図に示すようなシングルアカウント設定を使用したバッチ推論操作のサンプルコードを紹介します。サンプルコードはGitHubリポジトリ内で見つけることができ、エンタープライズで必要とされるモデルモニタリングと品質ゲートを使用した自動再トレーニングによるバッチ推論の出発点として利用できます。サンプルコードは次の点でターゲットアーキテクチャと異なります：

• MLモデルとサポートリソースの構築と展開には、単一のAWSアカウントを使用します。AWSでのマルチアカウント設定のガイダンスについては、「複数のアカウントを使用したAWS環境の整理」を参照してください。
• MLモデルとサポートリソースの構築と展開には、単一のGitLab CI/CDパイプラインを使用します。
• モデルの新しいバージョンが訓練されて承認された場合、GitLab CI/CDパイプラインは自動的にトリガされず、責任を持つデータサイエンティストがマニュアルで実行する必要があります。この際、SageMakerバッチ推論パイプラインは最新の承認済みモデルバージョンで更新されます。
• SageMakerトレーニングと推論パイプラインの実行には、S3イベントベースのトリガーのみをサポートしています。

前提条件

このソリューションを展開する前に、以下の前提条件を満たしている必要があります：

• AWSアカウント
• SageMaker Studio
• Amazon S3の読み取り/書き込みおよびAWS Key Management Service（AWS KMS）の暗号化/復号化権限を持つSageMaker実行ロール
• データ、スクリプト、およびモデルアーティファクトを格納するためのS3バケット
• Terraformバージョン0.13.5以上
• GitLabで動作するDockerランナーがあること
• AWS CLI
• jq
• unzip
• Python3（Python 3.7以上）および以下のPythonパッケージ：
  • boto3
  • sagemaker
  • pandas
  • pyyaml

リポジトリの構造

GitHubリポジトリには、以下のディレクトリとファイルが含まれています：

• /code/lambda_function/ – このディレクトリには、SageMakerパイプラインのステップ状態の変更について通知メッセージ（Amazon SNS経由）を準備して送信するLambda関数のPythonファイルが含まれています
• /data/ – このディレクトリには、生データファイル（トレーニング、推論、およびグラウンドトゥルースデータ）が含まれています
• /env_files/ – このディレクトリには、Terraformの入力変数ファイルが含まれています
• /pipeline_scripts/ – このディレクトリには、トレーニング、推論、およびHPOトレーニング用のSageMakerパイプラインの作成と更新に使用する3つのPythonスクリプト、および各パイプラインのパラメータを指定するための設定ファイルが含まれています
• /scripts/ – このディレクトリには、トレーニング、推論、およびHPOパイプラインで参照される追加のPythonスクリプト（前処理および評価など）が含まれています
• .gitlab-ci.yml – このファイルは、GitLab CI/CDパイプラインの設定を指定します
• /events.tf – このファイルは、EventBridgeリソースを定義します
• /lambda.tf – このファイルは、Lambda通知関数と関連するAWS Identity and Access Management（IAM）リソースを定義します
• /main.tf – このファイルは、Terraformデータソースとローカル変数を定義します
• /sns.tf – このファイルは、Amazon SNSリソースを定義します
• /tags.json – このJSONファイルは、ローカル変数を使用してTerraformリソースにカスタムタグキーバリューペアを宣言し、それらを追加することができます
• /variables.tf – このファイルは、すべてのTerraform変数を宣言します

変数と設定

次の表は、このソリューションのパラメータ化に使用される変数を示しています。詳細については、./env_files/dev_env.tfvarsファイルを参照してください。

****名前****	****説明****
bucket_name	データ、スクリプト、およびモデルアーティファクトを保存するために使用されるS3バケット
bucket_prefix	MLプロジェクトのためのS3プレフィックス
bucket_train_prefix	トレーニングデータのためのS3プレフィックス
bucket_inf_prefix	推論データのためのS3プレフィックス
notification_function_name	SageMakerパイプラインのステップ状態の変更について通知メッセージを準備して送信するLambda関数の名前
custom_notification_config	特定のパイプライン実行ステータスが検出されたときに特定のSageMakerパイプラインステップの通知メッセージをカスタマイズするための設定
email_recipient	SageMakerパイプラインのステップ状態の変更通知を受け取るためのメールアドレスリスト
pipeline_inf	SageMaker推論パイプラインの名前
pipeline_train	SageMakerトレーニングパイプラインの名前
pipeline_trainwhpo	SageMaker HPOパイプラインの名前
recreate_pipelines	GitLab CI/CDが実行されると、既存の3つのSageMakerパイプライン（トレーニング、推論、HPOを使用したトレーニング）が削除され、新しいものが作成される場合はtrueに設定します
model_package_group_name	モデルパッケージグループの名前
accuracy_mse_threshold	モデルの更新が必要になる前のMSEの最大値
role_arn	SageMakerパイプラインの実行ロールのIAMロールARN
kms_key	Amazon S3およびSageMakerの暗号化のためのKMSキーARN
subnet_id	SageMakerネットワーキング構成のサブネットID
sg_id	SageMakerネットワーキング構成のセキュリティグループID
upload_training_data	設定がtrueに設定されている場合、トレーニングデータがAmazon S3にアップロードされ、このアップロード操作によってトレーニングパイプラインが実行されます
upload_inference_data	設定がtrueに設定されている場合、推論データがAmazon S3にアップロードされ、このアップロード操作によって推論パイプラインが実行されます
user_id	SageMakerリソースにタグとして追加されるSageMakerユーザーの社員ID

ソリューションの展開

次の手順を完了して、AWSアカウントにソリューションを展開します：

1. GitHubリポジトリを作業ディレクトリにクローンします。
2. GitLab CI/CDパイプラインの設定を確認および変更して、環境に合わせます。設定は./gitlab-ci.ymlファイルで指定されています。
3. READMEファイルを参照して、./env_files/dev_env.tfvarsファイルの一般的なソリューション変数を更新します。このファイルには、PythonスクリプトとTerraformオートメーションの両方の変数が含まれています。
   1. ./batch_scoring_pipeline/pipeline_scripts/配下のYAMLファイルで定義されている追加のSageMakerパイプラインパラメータを確認し、必要に応じてパラメータを更新します。
4. ./pipeline_scripts/内のSageMakerパイプライン作成スクリプトとそれを参照するスクリプトを./scripts/フォルダに確認します。GitHubリポジトリで提供される例のスクリプトは、アバローンデータセットを基にしています。異なるデータセットを使用する場合は、スクリプトを特定の問題に合わせて更新する必要があります。
5. 次の命名規則を使用して、データファイルを./data/フォルダに配置します。提供された例のスクリプトと一緒にアバローンデータセットを使用している場合、データファイルはヘッダーなしであること、トレーニングデータには独立変数とターゲット変数の両方が含まれ、列の元の順序が保持されていること、推論データには独立変数のみが含まれていること、グラウンドトゥルースファイルにはターゲット変数のみが含まれていることを確認してください。
   1. training-data.csv
   2. inference-data.csv
   3. ground-truth.csv
6. コードをリポジトリにコミットしてプッシュし、GitLab CI/CDパイプライン実行（最初の実行）をトリガーします。最初のパイプライン実行では、推論パイプラインスクリプトが使用する承認されたモデルバージョンがまだないため、pipelineステージで失敗します。ステップログを確認し、新しいSageMakerパイプラインのTrainingPipelineが正常に作成されたことを確認してください。

• 1. SageMaker Studio UIを開き、トレーニングパイプラインを確認および実行します。
  2. トレーニングパイプラインの実行が成功した後、モデルレジストリで登録されたモデルバージョンを承認し、全体のGitLab CI/CDパイプラインを再実行します。

1. buildステージでTerraformのプラン出力を確認します。GitLab CI/CDパイプラインで手動のapplyステージを承認して、パイプラインの実行を再開し、Terraformに対してモニタリングおよび通知リソースを作成する権限を与えます。
2. 最後に、SageMakerパイプラインの実行状況と出力をSageMaker Studio UIで確認し、通知メッセージの確認にメールをチェックします。以下のスクリーンショットに示すように、デフォルトのメッセージ本文はJSON形式です。

SageMakerパイプライン

このセクションでは、MLOpsワークフロー内の3つのSageMakerパイプラインについて説明します。

トレーニングパイプライン

トレーニングパイプラインは、次のステップで構成されています：

• 特徴変換とエンコーディングを含む前処理ステップ
• トレーニングデータを使用してデータ統計と制約ベースラインを生成するデータ品質チェックステップ
• トレーニングステップ
• トレーニング評価ステップ
• トレーニングされたモデルが事前に指定された性能基準を満たしているかどうかをチェックする条件ステップ
• トレーニングされたモデルが必要な性能基準を満たしている場合は、新しくトレーニングされたモデルをモデルレジストリに登録するモデル登録ステップ

トレーニングパイプラインでは、skip_check_data_qualityおよびregister_new_baseline_data_qualityパラメータがTrueに設定されています。これらのパラメータは、パイプラインにデータ品質のチェックをスキップし、トレーニングデータを使用してデータ統計または制約ベースラインを作成および登録するだけと指示します。以下の図は、トレーニングパイプラインの成功した実行を示しています。

バッチ推論パイプライン

バッチ推論パイプラインは以下のステップで構成されています：

• モデルレジストリ内の最新の承認済みモデルバージョンからモデルを作成する
• 特徴量変換とエンコーディングを含む前処理ステップ
• バッチ推論ステップ
• データ品質チェック前処理ステップ。これは、データ品質チェックに使用する入力データとモデルの予測値を含む新しいCSVファイルを作成します
• 登録されたモデルに関連する基準統計量と制約との比較を行うデータ品質チェックステップ
• グラウンドトゥルースデータが利用可能かどうかをチェックする条件ステップ。グラウンドトゥルースデータが利用可能な場合、モデル品質チェックステップが実行されます
• グラウンドトゥルースラベルに基づいてモデルのパフォーマンスを計算するモデル品質計算ステップ

推論パイプラインでは、skip_check_data_qualityおよびregister_new_baseline_data_qualityパラメータの両方がFalseに設定されています。これらのパラメータは、推論中にデータ統計量または制約のベースラインを使用してデータ品質チェックを実行し、推論中に新しいデータ統計量と制約のベースラインを作成または登録しないようにパイプラインに指示します。次の図は、バッチ推論パイプラインの実行例であり、データ品質チェックステップが推論データのモデルのパフォーマンスが低いために失敗した場合を示しています。この特定の場合では、モデルを微調整するために自動的にHPOパイプラインのトレーニングがトリガーされます。

HPOパイプラインでのトレーニング

HPOパイプラインでのトレーニングは以下のステップで構成されています：

• 前処理ステップ（特徴量変換およびエンコーディング）
• トレーニングデータを使用してデータ統計量と制約のベースラインを生成するデータ品質チェックステップ
• ハイパーパラメータチューニングステップ
• トレーニング評価ステップ
• 事前に指定された精度閾値を満たしているかどうかをチェックする条件ステップ
• 最良のトレーニング済みモデルが必要な精度閾値を満たす場合は、モデル登録ステップを実行する

HPOパイプラインでは、skip_check_data_qualityおよびregister_new_baseline_data_qualityパラメータの両方がTrueに設定されています。次の図は、HPOパイプラインの成功した実行例を示しています。

クリーンアップ

リソースをクリーンアップするには、以下の手順を完了します：

1. Terraformによってプロビジョニングされたすべてのリソースを削除するために、GitLab CI/CDパイプラインでdestroyステージを使用します。
2. Pythonスクリプトによって作成された残っているパイプラインをリストアップして削除するために、AWS CLIを使用します。
3. 必要に応じて、CI/CDパイプラインの外部で作成されたS3バケットやIAMロールなど、その他のAWSリソースを削除します。

結論

この記事では、Amazon SageMaker、Amazon EventBridge、AWS Lambda、Amazon SNS、HashiCorp Terraform、およびGitLab CI/CDを使用して、エンタープライズがバッチ推論ジョブのMLOpsワークフローを作成する方法を示しました。示されたワークフローは、データとモデルのモニタリング、モデルの再トレーニング、バッチジョブの実行、コードバージョニング、およびインフラストラクチャのプロビジョニングを自動化します。これにより、本番環境でのバッチ推論ジョブの複雑さとコストを大幅に削減することができます。詳細な実装については、GitHubリポジトリを参照してください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!