Amazon MLA-C01: モデルのデプロイと推論 — 学習ガイド

By Laurynas Brazys · 4 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

こちらの一部です： AWS Machine Learning Engineer Associate MLA-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

リアルタイム、サーバーレス、非同期、バッチエンドポイント — 中核概念

Amazon SageMakerのリアルタイム推論は、低レイテンシーでステートフルなサービスモデルです。Model、EndpointConfig、Endpointを作成し、プロビジョニングされたコンピューティング（ml.*インスタンスタイプ）を割り当て、InvokeEndpoint API経由でリクエストを処理するために常時利用可能な状態を維持します。CreateEndpointConfigはProductionVariantsを受け入れ、各ProductionVariantはModelName、InitialInstanceCount、InstanceType、InitialVariantWeightを定義します。トラフィックとキャパシティはUpdateEndpointWeightsAndCapacitiesまたはUpdateEndpointで変更できます。予測可能な低レイテンシーが求められる場合、プロビジョニングされたリアルタイムエンドポイントが主要な選択肢となり、前処理、モデル、後処理のコンテナを連結するマルチコンテナ推論パイプラインをサポートします。

サーバーレス推論はインスタンス管理を不要にし、エンドポイントレベルでServerlessConfigを使用して設定され、各ProductionVariantに対してMemorySizeInMBとMaxConcurrencyを指定します。SageMakerがコンテナのプロビジョニングを管理し、アイドル時にはゼロにスケールするため、スパイク的で低スループットなワークロードに最適です。非同期推論は、実行に長時間を要するリクエストや、クライアントが同期的なレスポンスを必要としない場合に最適化されています。非同期エンドポイントはCreateEndpointConfig内のAsyncInferenceConfig（S3OutputPathを持つOutputConfig、オプションのClientConfig、MaxConcurrentInvocationsPerInstance）で作成され、クライアントは入力S3 URIを指定してInvokeEndpointAsyncを呼び出します。結果は設定されたS3の出力場所に書き込まれます。バッチ変換は、大規模なオフライン推論ワークロードのための別のジョブタイプ（CreateTransformJob）です。このAPIはTransformInput（S3UriとS3DataTypeを持つS3DataSource）、TransformOutput（S3OutputPath、Accept、AssembleWith）、およびTransformResources（InstanceType、InstanceCount）を必要とします。バッチ変換は、レイテンシーよりもスループットが重要な場合に最適で、データセット全体にわたる大規模な並列処理をサポートします。

マルチモデルエンドポイント、推論パイプライン、シャドウイング、A/Bテスト — 主要サービスと設定

モデルあたりのQPSが低い多数のモデルをホストする場合、SageMakerマルチモデルエンドポイント（MME）を使用すると、単一のコンテナでS3に保存された数十から数千のモデルアーティファクトをホストし、オンデマンドでロードできます。SageMakerのマルチモデルサーバーパターンを実装したモデルサーバーコンテナを構築するか、サポートされているフレームワークイメージを使用し、モデルのtarballをS3にアップロードして、そのコンテナを参照するModelリソースを作成します。呼び出し時に、InvokeEndpoint APIのパラメータTargetModel（またはヘッダーX-Amzn-SageMaker-Target-Model）を介してターゲットモデル名を渡すことで、サーバーはそのモデルをS3からメモリにロードします。MMEは大規模なモデルフリートのメモリと運用コストを節約しますが、まだランタイムに常駐していないモデルにはコールドロードのレイテンシーが加わります。

推論パイプラインはマルチコンテナモデルとして実装され、ModelリソースでContainersを順番にリストします。エンドポイントはペイロードを最初のコンテナ（前処理）、次にモデルコンテナ、そして後処理コンテナへとルーティングします。CreateModelで、各コンテナに独自のModelDataUrlと環境変数を定義します。カナリアテストやブルー/グリーン方式のテストには、EndpointConfigで複数のProductionVariantsを使用し、InitialVariantWeightでトラフィック分割を制御し、後でUpdateEndpointWeightsAndCapacitiesを介して変更します。シャドウデプロイメントは、アプリケーション層で各リクエストのコピーをシャドウエンドポイントに送信する（本番エンドポイントにトラフィックの重み付けをしない）か、または低ウェイトのProductionVariantを作成してエンドポイントインフラストラクチャがミラーリングされたトラフィックを一部受信するようにすることで実現できます。アプリケーション層でのリクエスト複製により、実験の完全な分離と独立した可観測性が得られます。

オンデマンドおよび継続的なモニタリングのために、エンドポイント作成時にDataCaptureConfigを設定して、リクエストとレスポンスのペイロードをS3に永続化します。DataCaptureConfigの主要なフィールドには、EnableCapture (true)、InitialSamplingPercentage、DestinationS3Uri、およびCaptureOptions (REQUEST, RESPONSE) が含まれます。キャプチャされたデータは、SageMaker Model MonitorおよびSageMaker Clarifyのデプロイ後チェックの基礎となります。Model MonitorのCreateMonitoringScheduleでベースラインを作成し、組み込みのモデルモニタリングコンテナを使用して制約やドリフトメトリクスを計算するアドホックなProcessingジョブを実行できます。

設計パターンとトレードオフ

1桁から2桁台前半のミリ秒単位のレイテンシーが必要で、常時稼働のキャパシティを確保できる場合は、プロビジョニングされたリアルタイムエンドポイントを選択します。アイドル時の分単位のコストが主な制約であり、トラフィックが断続的である場合は、サーバーレスエンドポイントが運用を削減します。各バリアントに

undefined

と

undefined

を設定し、SageMaker に自動スケーリングを任せます。長時間の推論や重いペイロードのやり取りを伴うワークロードには、非同期エンドポイントがクライアントのライフタイムとコンピューティングを分離します。これらは入力/出力に S3 を必要とし、クライアントがポーリングまたは S3 通知で完了を確認できる場合に最も適しています。

マルチモデルエンドポイントは、メモリの重複と S3 オブジェクト管理の複雑さを軽減しますが、モデルごとのコールドスタートレイテンシーが加わり、オンデマンドでの S3 からの読み込みと適切なライフサイクル管理（eviction/LRU）が可能なモデルサーバーが必要になります。モデルごとのレイテンシーが重要な場合は、ホットモデルを専用の ProductionVariants でホストし、トラフィックの少ないモデルを MME にオフロードします。推論パイプラインは、前処理と後処理のロジックをモデルの近くに集約し、クライアント側のコードを削減し、トレーニングと推論の間で一貫した変換を保証しますが、エンドポイントの起動の複雑さを増し、堅牢なコンテナコントラクト設計（入出力コーデックとコンテントタイプ）が要求されます。

ProductionVariant の重みを使用した A/B テストは、トラフィックの分割やオフラインでのメトリクス収集には簡単ですが、本番環境のメトリクスに影響を与えずにトラフィックをシャドウイングしたい場合は、アプリケーションレベルのミラーリングを選択します。プログレッシブなロールアウトとロールバックの自動化には、UpdateEndpointWeightsAndCapacities を CodePipeline または Step Functions のワークフローに統合します。このワークフローには、CloudWatch メトリクス、Model Monitor アラートを使用した自動的なメトリクス評価、および最終的なプロモーションをゲートする手動承認アクションが含まれます。

よくある落とし穴と判断基準

よくある運用上の間違いは、Model Monitorがラベルの可用性の問題を検出してくれると想定することです。Model Monitorは、キャプチャされたリクエストから特徴量の分布ドリフトやデータ品質の違反を検出できますが、ラベルベースのメトリクス（F1、再現率）の劣化を測定するには、モニタリングジョブが消費できる形式で正解ラベルをS3に送り返し、予測と正解を比較計算するモニタリングジョブをスケジュールする必要があります。もう一つの落とし穴は、ServerlessConfig.MemorySizeInMBのサイズを適切に設定しないことです。メモリのプロビジョニングが不十分だと、スロットリングやコンテナのクラッシュを引き起こし、過剰なプロビジョニングはコストを増加させます。マルチモデルエンドポイントの場合、適切なS3オブジェクトのレイアウトとライフサイクル（プレフィックス、モデルマニフェスト）の設定を怠ると、コールドロードが遅くなり、退去ポリシーが複雑になります。

不正検知におけるクラスの不均衡に対処する場合、運用オーバーヘッドを最小限に抑えるために、大規模なサンプリングパイプラインよりもアルゴリズムネイティブの重み付けを優先します。例えば、XGBoost（SageMaker XGBoostコンテナ）はscale_pos_weightハイパーパラメータをサポートしており、これをnegative_examples/positive_examplesとして計算し、CreateTrainingJobコールのhyperparametersマップ経由で渡します。手動でのデプロイゲートには、SageMaker Model Registryを使用します。ModelPackageGroupを作成し、CreateModelPackageを呼び出してモデルパッケージを登録し、モデルパッケージのステータスをPendingManualApprovalに設定します。その後、外部のCodePipelineの手動承認アクションやStep Functions + SNSの手動確認がUpdateModelPackageを呼び出してApprovalStatus = "Approved"に設定してから、CreateModelやCreateEndpointが実行されます。

実践的な問題：ユースケースシナリオ

FraudDetectCoは、S3のトランザクションログとオンプレミスのMySQLの顧客プロファイルテーブルを統合し、XGBoostモデルをトレーニングし、ほぼリアルタイムのレイテンシーでデプロイし、本番リリースに手動承認ゲートを強制し、データセットの異常とモデルのドリフトの両方をオンデマンドで検出する必要があるオンライン不正検知システムを構築しています。

データの集約と前処理：AWS Database Migration Service (DMS) またはAWS GlueのJDBCコネクタを使用して、オンプレミスのMySQLテーブルをS3（parquet）またはAmazon RDS/Athenaが有効なデータレイクに継続的にレプリケートします。AWS Glueでカタログ化し、Amazon SageMaker Feature Storeのオフラインストアに特徴量を登録して、一貫したトレーニングとオンラインサービングのフィーチャールックアップを提供します。これにより、特徴量の系譜が集中管理され、分離のためのS3セキュリティポリシーとLake Formationガバナンスが適用されます。
トレーニングとクラス不均衡への対応：SageMaker XGBoost組み込みコンテナを使用してSageMaker Trainingジョブを実行します。トレーニングラベルの比率を計算し、CreateTrainingJobのHyperParametersマップでXGBoostハイパーパラメータ「scale_pos_weight」を設定して、最小限の前処理でクラスの不均衡に対処します。トレーニングチャネルにはPipeモード（DataSourceにS3DataSourceとS3DataTypeをS3Prefixに設定し、Pipeモードを使用する場合は"RecordWrapperType":"None"を有効にする）を使用して、連続するジョブ間での起動時間とデータダウンロードのレイテンシーを削減します。
モデルレジストリと手動承認：ModelPackageGroup内でCreateModelPackageを呼び出すことにより、トレーニング済みモデルをSageMaker Model Registryに登録します。初期のApprovalStatusをPendingManualApprovalに設定し、AWS Manual Approvalアクションを含むAWS CodePipelineを統合します。手動確認後、UpdateModelPackageをApprovalStatus="Approved"で呼び出してから、CreateModelとCreateEndpointConfigを介してModelPackageを本番環境にプロモートします。
デプロイと推論トポロジー：低レイテンシーのスコアリングのために、プロビジョニングされたリアルタイムエンドポイントにモデルをデプロイします。後で数百のモデルをホストする必要がある場合は、Multi-Model Endpointを評価し、InvokeEndpointのTargetModelパラメータを使用してS3に保存されている特定のモデルを指定します。DataCaptureConfig（EnableCapture=true, InitialSamplingPercentage=100, DestinationS3Uri=s3:///captures, CaptureOptions=['REQUEST','RESPONSE']）を設定して、オンデマンド分析のためにリクエスト/レスポンスのペイロードを収集します。
モニタリングと異常検出：データ品質と特徴量ドリフトのために、CreateMonitoringScheduleでSageMaker Model Monitorのベースラインをスケジュールします。データセットレベルの異常検出と可視化のために、キャプチャされたS3データをAmazon Lookout for Metricsに取り込んで異常を自動検出し、Amazon QuickSightに取り込んでダッシュボードを作成します。オンデマンドでのバイアスとドリフトの評価には、キャプチャされたデータに対してSageMaker Clarify処理ジョブを実行するか、保存されたベースライン制約を適用して比較レポートを生成するアドホックなModel Monitor Processingジョブ（CreateProcessingJob経由）を起動します。

論理的根拠：このアプローチは、再現可能なトレーニングと低レイテンシーのサービングのために特徴量を一元化し、パイプラインの複雑さを最小限に抑えながらクラスの不均衡に対応するためにXGBoostのscale_pos_weightを使用し、CodePipelineと統合されたModel Registryで手動承認を強制し、Pipeモードを使用してトレーニングデータをストリーミングすることでトレーニングの起動レイテンシーを削減し、キャプチャされた推論データを使用して自動異常検出（Lookout for Metrics）とオンデマンドでの公平性/ドリフトチェック（Clarify + Model Monitor）の両方を提供します。

← モデルの評価と選択 · すべてのドメイン · MLOps とモデルのライフサイクル管理 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →