Amazon MLA-C01: MLOps とモデルのライフサイクル管理 — 学習ガイド
こちらの一部です: AWS Machine Learning Engineer Associate MLA-C01 — 学習ガイド. 検証済みの解答で練習: Amazon試験ハブ, または時間制限付き模擬試験に挑戦: ExamRoll.io.
コアコンセプト
AWSにおけるモデルライフサイクル管理は、モデルをバージョン管理されたアーティファクトとして扱い、監査可能なリネージ、自動化された昇格ゲート、再現性のあるパイプラインを確保することに重点を置いています。Amazon SageMakerは、そのための基本機能(プリミティブ)を提供します。具体的には、オーケストレーションのためのSageMaker Pipelines、バージョニングと承認状態管理のためのSageMaker Model Registry(ModelPackage/ModelPackageGroup)、CI/CDのためのSageMaker ProjectsとCodePipeline、そして継続的な品質とバイアスのチェックのためのModel Monitor/Clarifyです。堅牢なライフサイクルは、再現可能な入力から始まります。すなわち、サーバー側のKMS暗号化と厳格なバケットポリシーまたはLake Formationのコントロールが適用されたS3上の不変のトレーニングデータ、ソースリポジトリでバージョン管理されたコード、そしてCreateTrainingJobやsagemaker SDKのTrainingStepに渡されるコンテナイメージURIとインスタンスタイプで宣言されたトレーニング環境です。
運用上のコントロールには、CreateTrainingJobのVpcConfig(SubnetsとSecurityGroupIds)およびEnableNetworkIsolationによる外部へのegressを防ぐネットワーク分離や、最小権限でスコープされたIAMロール(特定のバケットに対するs3:GetObject、kms:Decryptを持つSageMakerExecutionRole)が含まれます。トレーニングジョブが完了したら、CreateModelPackageまたはSDKのregister_model呼び出しをModelPackageGroupNameと共に使用してアーティファクトをModel Registryに登録し、ModelApprovalStatusを"PendingManualApproval"に設定して、人手によるゲートを設けます。リネージメタデータ(トレーニングのハイパーパラメータ、Dockerイメージ、入力データのS3 URI、Gitのコミットなど)は、モデルパッケージのメタデータとして添付し、後続のCI/CDや監査が本番エンドポイントからコードやデータセットまで遡って追跡できるようにすべきです。
ML向けのCI/CDは、アーティファクト(モデル、ベースライン、モニター)が大規模で、非決定的な出力を持つため、従来のCI/CDとは異なります。CI/CDは、SageMaker Projectsのテンプレートに加えてAWS CodePipelineとCodeBuildを使用して実装します。CodeBuildを使用して、単体テスト、モデルトレーニングのスモークテスト(例:短いエポック数やデータの一部を使用)、統合テストを実行します。CodePipelineを使用して、ソース→ビルド→モデル登録のステップをオーケストレーションし、ManualApprovalアクションやLambdaベースのカスタムアクションを組み込んで、UpdateModelPackageを介してModelPackageのModelApprovalStatusを切り替えます。自動昇格のためには、CodePipelineからSageMakerのCreateEndpointConfigおよびCreateEndpoint APIを呼び出すか、SageMaker Projectsによって生成されたCloudFormationスタックを使用して、予測可能なInfrastructure-as-Codeでデプロイします。
主要なサービスと設定
SageMaker Pipelinesはオーケストレーション層です。PythonでProcessingStep、TrainingStep、ModelStep、TransformStep、RegisterModelのステップオブジェクトを宣言します。ステップでCacheConfig(enable_caching=True, expire_after=timedelta(days=1))を使用すると、入力とパラメータが変更されていない場合にステップが出力を再利用するため、不要なインスタンスのプロビジョニングを回避できます。RegisterModelにはsagemaker.workflow.steps.RegisterModelを使用し、model_package_group_nameとmodel_approval_statusを"PendingManualApproval"に設定して、承認ゲートをパイプライングラフに統合します。pipeline.start() APIを使用して実行を開始し、pipeline.get_steps()またはコンソールを使用して実行ステータスとリネージを検査します。
SageMaker Model Registryは、モデルパッケージをModelPackageGroupNameの下に保存し、ModelPackageVersion識別子を割り当てます。関連するAPIは、ModelApprovalStatusを"Approved"または"Rejected"に変更するためのCreateModelPackageGroup、CreateModelPackage、DescribeModelPackage、およびUpdateModelPackageです。ModelPackageオブジェクトには、InferenceSpecification(Containers、SupportedContentTypes、SupportedResponseMIMETypes)やModelApprovalStatusなどのメタデータフィールドを含めるべきです。デプロイ時には、モデルパッケージのARNを使用してModelNameとPrimaryContainerを指定してCreateModelを呼び出し、次にDataCaptureConfig(EnableCapture=true、SamplingPercentage、DestinationS3Uri)を指定してCreateEndpointConfigを呼び出し、推論キャプチャを有効にします。
モニタリングとバイアス検出には、SageMaker Model MonitorとSageMaker Clarifyを使用します。Model Monitorでは、DefaultModelMonitor.suggest_baselineを介して作成されたベースラインが必要です。これはベースラインの統計情報と制約を取得するためにCreateProcessingJobを呼び出します。これらのベースラインはS3に保存され
設計パターンとトレードオフ
一般的なパターンはパイプラインファーストです。データの前処理 (ProcessingStep)、トレーニング (TrainingStep)、モデル評価 (ProcessingStep または ClarifyProcessor)、モデルの登録 (RegisterModel)、デプロイ (ModelStep または手動プロモーション) を含む SageMaker Pipeline を作成します。ステップキャッシングを使用して、冗長なコンピューティングを最小限に抑え、反復的な開発を高速化します。安全なプロモーションのために、model_approval_status を “PendingManualApproval” に設定し、CodePipeline の ManualApproval アクションまたはモデルパッケージを更新する承認 Lambda を統合します。この設計は、ヒューマンインザループのガバナンスを可能にしながら、データとコードから本番環境までの監査可能な経路を提供します。
CI/CD では、2つのトレードオフから選択します。メトリクスゲートに基づく完全自動プロモーション (高速、手動ステップが少ない) か、手動承認ワークフロー (コンプライアンス重視) かです。メトリクスベースのゲーティングは、CodeBuild で小さな evaluate.py を実行して実装します。このスクリプトは、SageMaker Runtime を呼び出すか、モデルパッケージをロードしてメトリクスを計算し、CodePipeline が合否を判断するために使用するアーティファクトを出力します。コンプライアンスで人的な承認が必要な場合は、SNS 経由でメールをトリガーし、指定された承認者が続行する必要がある AWS CodePipeline ManualApprovalAction を挿入します。または、Model Registry の状態を信頼できる唯一の情報源 (canonical source of truth) として使用し、ModelApprovalStatus が “Approved” の場合にのみデプロイを許可します。
トレーニングジョブの起動レイテンシーを削減するには、多くの場合、完全なプロビジョニングの繰り返しを避けることが重要です。多くのパイプライン実行が同一の入力で再トレーニングを行う場合は、Pipeline CacheConfig を有効にして、入力が変更されていないときに TrainingStep がスキップされるようにします。実行ごとにトレーニングが必要で、かつ低レイテンシーが求められるイテレーションの場合は、SageMaker Studio でより小さなインスタンスタイプを使用して高速にプロトタイピングを行うか、永続的な Amazon EC2 インスタンスや EKS ベースのカスタムトレーニングオーケストレーターで複数の実験を実行して、コンテナのコールドスタートを回避します。これは、運用オーバーヘッドと引き換えに低レイテンシーを得るトレードオフです。本番環境レベルのスケーラビリティのためには、ある程度の起動遅延を受け入れ、代わりに再現性を自動化します。
よくある落とし穴と判断基準
よくある間違いは、デプロイ時にDataCaptureConfigを有効にせず、ドリフト検出をエンドポイントのログのみに依存することです。キャプチャを行わないと、Model MonitorとClarifyは実際の推論入力を分析できません。常にCreateEndpointConfigでDataCaptureConfig(EnableCapture=true, DestinationS3Uri, CaptureOptions, InitialSamplingPercentage)を設定し、CreateMonitoringScheduleを介してベースライン統計にリンクするモニタリングスケジュールをセットアップしてください。
もう一つの落とし穴は、不十分なS3とネットワークセキュリティです。隔離を維持する必要があるトレーニングジョブでは、CreateTrainingJobでVpcConfigを使用し、S3オブジェクトに対してKMS暗号化を有効にする必要があります。パブリックアクセスコントロールに依存せず、代わりにS3バケットポリシー、VPCエンドポイント(com.amazonaws.region.s3)、IAMロールのスコープ設定を使用してください。最後に、評価メトリクスとモデルカードのメタデータをモデルパッケージに組み込み、アーティファクトを上書きする代わりに不変のバージョニング(ModelPackageVersion)を使用することで、脆弱なCI/CDを避けてください。
実践的な問題:ユースケースシナリオ
AcmePay — トランザクションストリームの不正検出。ここでの課題は、S3のトランザクションログ、顧客プロファイル、オンプレミスのMySQLテーブルを集約し、XGBoost不正分類器をトレーニングし、本番環境へのデプロイ前に手動承認を行う中央モデルレジストリを維持し、データとバイアスのドリフトをオンデマンドで検出し、バージョニングと反復実行の運用オーバーヘッドを最小限に抑える、安全で監査可能なライフサイクルを構築することです。
データの集中管理:AWS Glueを使用して、S3トランザクションログとオンプレミスのMySQLをAWS Glue JDBCコネクタ(ネットワークアクセスにはセキュアなDataSync転送またはVPCピアリングを使用)経由でクロールします。データセットをGlueデータカタログにカタログ化し、AWS Lake Formationを介してアクセスを強制します。キュレーションされたトレーニングセットを暗号化されたS3プレフィックス(KMS CMK)に保存し、バケットポリシーとVpcEndpointを使用してパブリックアクセスを防ぎます。
再現可能なパイプラインの構築:特徴量エンジニアリングのためのProcessingStep(Data WranglerまたはGlue ETLエクスポート)、ハイパーパラメータ付きの組み込みXGBoostコンテナを実行するTrainingStep、そしてmodel_package_group_name=“acmepay-fraud-group"とmodel_approval_status=“PendingManualApproval"を指定してRegisterModelを呼び出すRegisterModelステップを持つSageMaker Pipelineを作成します。前処理とトレーニングのステップでCacheConfigを有効にし、入力/コードが変更されていない場合に出力を再利用することで、インスタンスの繰り返しのプロビジョニングを削減します。
CI/CDと承認:AWS CodePipelineの雛形を作成するSageMaker Projectを作成します。パイプラインはCodeBuildで単体テストを実行し、SageMaker Pipelineをトリガーし、RegisterModelの後にCodePipelineのManualApprovalアクションを含みます。手動承認アクションが承認されると、Lambdaを呼び出してUpdateModelPackageを呼び出し、ModelApprovalStatusを"Approved"に設定し、その後CreateEndpointConfigとCreateEndpointをトリガーしてデプロイします。SageMaker Projectsによって生成されたCloudFormationリソースを使用して、インフラの再現性を維持します。
安全なトレーニングとデプロイ:CreateTrainingJobでVpcConfig(SubnetIds, SecurityGroupIds)とEnableNetworkIsolation=trueを指定してトレーニングジョブをサブミットします。SageMaker実行ロールがKMSキーに対するkms:Decryptと、キュレーションされたデータセットプレフィックスに対するs3:GetObjectのみを持つことを確認します。エンドポイントについては、推論データがモニタリングのために保持されるように、DataCaptureConfig(EnableCapture=true, SamplingPercentage=100, DestinationS3Uri=s3://acmepay-prod/capture)を指定してCreateEndpointConfigを作成します。
オンデマンドのドリフトとバイアスのチェック:キャプチャされた推論データとグラウンドトゥルースラベル(利用可能な場合)に対してProcessingJobでSageMaker Clarifyを使用し、オンデマンドでModelBiasおよびModelExplainability分析を実行します。データサイエンスチームが評価を要求したときに、LambdaまたはStep FunctionsからClarifyProcessor.run() APIを介して呼び出します。継続的なドリフトアラートのためには、DefaultModelMonitor.suggest_baselineを介してModel Monitorのベースラインを作成し、MonitoringScheduleを作成します。CreateMonitoringScheduleを使用して定期的なチェックを実行し、違反に対するSNS通知を設定します。
AWSの論理的根拠:Glue + Lake Formationは、最小限のカスタムETLコードで異種ソースを集中管理し、セキュリティを確保します。SageMaker Pipelines + CacheConfigは、反復実行のためのインフラの頻繁な再構築を最小限に抑えます。モデルレジストリは、不変のバージョニングとメタデータ(ModelPackageGroupNameおよびModelPackageVersion)を提供し、ModelApprovalStatusを介して承認ワークフローとネイティブに統合します。そして、SageMaker ClarifyとModel Monitorは、オンデマンドのバイアス評価とスケジュールされたドリフト検出の両方を提供します。SageMaker ProjectsとCodePipelineを使用することで、CI/CDを標準化し、“PendingManualApproval"から"Approved"への監査可能で反復可能な本番環境へのプロモーションを強制します。
← モデルのデプロイと推論 · すべてのドメイン · モデルのモニタリングと可観測性 →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →