AWS MLOps Demonstrated 受験レビュー
ひと目で分かる概要
この試験はモデルを学習させることでは終わらない。デプロイ、カスタム推論、データ準備、ファインチューニング・登録、バッチ推論、観測・スケーリング、CDNまでMLOpsパイプラインを一周することが核心である。サービス名だけを暗記しても不十分で、S3 URI、エンドポイント、ロールARN、Lambda名のようにラボで与えられる値を正確に使う能力が得点を分ける。
形式はコンソールとStudio、S3パスを同時に扱う実務型ラボであり、使用するサービスの範囲はAmazon SageMaker(JumpStart、Training、Endpoint、Batch Transform、Model Registry)、Amazon S3、Amazon ECRとAWS CodeBuild、AWS LambdaとAmazon API Gateway、Amazon EC2 Auto Scaling、Amazon CloudFront、IAM/VPCである。サービスのカタログを暗記するよりも、どの段階でどんな成果物(URI、ARN、エンドポイント名)が出てくるかを頭の中で地図として描いておく方がはるかに有利である。
この試験は何を見ているのか
試験が求める目標は大きく7段階に分かれる。JumpStart Foundation Modelをデプロイする段階(体感難易度:中)、Custom Inference Containerを修正する段階(体感難易度:上)、Training Dataを準備する段階(体感難易度:中)、Fine-Tune後にModel Registryへ登録する段階(体感難易度:上)、プロンプトベースのBatch Inferenceを実行する段階(体感難易度:中上)、ObservabilityとScalingを構成する段階(体感難易度:中上)、そしてAmazon CloudFrontを構成する段階(体感難易度:中)である。
全体の流れをまとめると、SageMaker Studioを開きJumpStartで基礎モデルをデプロイした後、推論コンテナに問題があればECRリポジトリを基準にイメージを直す。学習用CSVと前処理スクリプトはすでにS3にアップロードされており、それを読み込んでTraining Jobを回す。ファインチューニングが終わればModel Package Groupに登録し、バッチ推論でプロンプトを処理する。最後にData Capture、スケーリング、CloudFrontまでまとめて運用可能な状態を作る。
時間が逼迫しがちな区間は、ほぼ常にカスタムコンテナの修正とファインチューニングおよびレジストリ登録だった。逆にJumpStartデプロイやCloudFront URLの確認は相対的に早く終わる方だった。そのため前半で時間を節約し、難易度の高い中盤区間に余裕を残す戦略が有効である。
段階別の経験談
JumpStart Foundation Modelのデプロイ
JumpStartで指定されたFoundation Modelを選択しエンドポイントとしてデプロイする段階である。テキスト生成用エンドポイント名のように試験環境で事前に決められた名前があれば、その名前をそのまま使わなければならない。勝手に名前を変えると、その後のLambda、API、検証スクリプトが失敗するケースが多い。デプロイが終わった後はエンドポイントの状態がInServiceであるかを必ず確認する必要がある。デプロイボタンを押しただけの状態と、実際に呼び出し可能な状態は異なる。
Custom Inference Containerの修正
体感難易度が最も高い区間の一つである。ECRリポジトリに上がっている推論イメージを基準に、壊れたコード、依存関係、エントリーポイントを直し再ビルド・プッシュする。CodeBuildを使う構成であれば、ビルドログを最後まで読む習慣が必要だ。ローカルで完璧に直したと感じても、ECRに新しいイメージが実際にプッシュされたかを確認しなければならない。SageMakerエンドポイントはイメージタグやダイジェストを参照するため、古いイメージを参照し続けていると修正内容が反映されない。分類用と生成用のエンドポイントが分かれている場合、どのコンテナがどのエンドポイントに紐づいているかを混同しないようにする。
Training Dataの準備
元のCSVと前処理スクリプトがS3にあらかじめ準備されているケースが多い。データを新しく作ることよりも、与えられたURIを正確にパイプラインに接続することが核心である。S3パスを手で入力する際、training-data、training-script、inference-samplesのようなプレフィックスを混ぜて使わないよう注意する必要がある。一文字間違えるだけでTraining Jobが静かに失敗する。
Fine-Tune後のModel Registry登録
Hugging Face系のTraining DLCイメージとソースディレクトリ(sourcedir.tar.gz)を利用してFine-tuning Jobを回し、成功したモデルをModel Package Groupに登録する。Job名、ロールARN、イメージURIが事前に決まっていれば、その値をそのまま使うのが安全である。Training Jobが失敗したら、まずCloudWatchやStudioのログでデータパス、ロール権限、イメージのpull状況を確認する必要がある。モデルが学習だけされてRegistryに登録されないまま次の段階に進むと、バッチ推論やデプロイの検証で詰まる。Model Package Groupのプレフィックス(例:anycompany-models)を覚えておくと、登録画面で迷う時間を減らせる。
Batch Inferenceの実行
リアルタイムエンドポイントではなく、S3にあるプロンプトやサンプルを読み込みバッチで推論する段階である。入出力のプレフィックスが決まっていれば、そのパスをJob設定に正確に入力する必要がある。バッチJobが成功していても出力ファイルが空だったり形式が間違っている場合があるため、S3の結果オブジェクトを直接開いて検証する習慣が必要だ。
ObservabilityとScalingの構成
Data Captureで推論のリクエスト・レスポンスをS3に残し、Auto Scalingで負荷に対応する。監視をオンにしたという宣言よりも、Data Capture Prefixに実際にデータが蓄積されているか、スケーリングポリシーがエンドポイントに実際に接続されているかが重要である。観測性の設定は最後にまとめて行うと時間が足りなくなるため、エンドポイントが生きている時点でCaptureをオンにしておき、サンプル呼び出しを1、2回投げてパスを事前に確認しておくのがよい。
Amazon CloudFrontの構成
アプリケーションURLがCloudFrontドメインで提供される構成である。最終的にブラウザでアプリが開くか、API(Gateway/Lambda)との接続が切れていないかを確認する。CloudFrontはキャッシュのため修正内容がすぐに反映されないことがあるので、配信/無効化(invalidation)の状態を確認し、必要であればクエリ文字列やシークレットヘッダーでキャッシュを回避して検証する必要がある。
試験前に覚えておくと良い値の種類
実際のラボではアカウントやリージョンごとに値は異なるが、値の種類はほぼ固定されている。試験開始直後にキーバリュー表が見えたら、次の項目からメモしておくのがよい。アプリケーションURL(CloudFront)は最終検証とデモの入口となり、分類/生成エンドポイント名はLambdaと呼び出しコードが参照する値である。分類/生成Lambda名はAPI連携と権限確認に必要で、ラボのS3バケットと各種プレフィックスは学習・推論・Data Captureのパスに使われる。ECRリポジトリ名はカスタムコンテナをプッシュする対象で、SageMaker実行ロールARNはTrainingとEndpointの権限に関連する。Model Package Groupのプレフィックスはモデル登録に必要で、Training Job名とDLCイメージはファインチューニングの設定に、Studio URLは作業の本拠地となる。値をおおよそ似た名前で記憶すると、ほぼ間違いなく失敗するため、コピーして貼り付け、もう一度目で確認する習慣が最も安い保険である。
時間がかかった区間
体感で最も時間がかかった区間はCustom Inference Containerの修正とFine-Tune後のModel Registry登録だった。逆にJumpStartのデプロイやCloudFrontの構成は相対的に早く進めることができた。Training Dataの準備はURI接続のミスにさえ気をつければ難しくなく、Batch InferenceとObservability/Scalingは成果物を直接確認する習慣があれば大きな問題はなかった。
受験前に準備しておくと良いこと
試験が始まったらコンソールをすぐに触るよりも、5分ほど投資して全体の流れをスケッチしておくのがよい。S3のデータとスクリプトがSageMaker Training/JumpStartにつながり、これがModel Registryを経てEndpoint(分類/テキスト生成)に接続され、再びLambdaとAPI Gatewayを経てCloudFrontにつながる。ここにECRとCodeBuildがカスタム推論イメージを供給し、Data CaptureがS3にデータを送り、Auto ScalingがEndpointに接続される。この絵を事前に描いておくと、今パイプラインのどの地点を修正しているのかを把握しやすくなる。
時間配分は中盤に重きを置くのがよい。序盤(JumpStart、データURIの確認)は速く正確に処理し、中盤(コンテナ修正、Fine-tune、Registry登録)に最も多くの時間を割り当て、終盤(バッチ推論、Capture、Scaling、CloudFront)は検証中心に進める。中盤で詰まると、ログを見ずに設定だけを変え続ける悪循環に陥りやすいので、一度失敗したらログの一行から原因の候補を絞り込む方式に切り替える必要がある。
ミスの上位はほぼ常に似ている。誤ったS3 URIやバケットプレフィックス、SageMaker実行ロールの権限不足、古いECRイメージや古いエンドポイント設定を参照し続けるケースだ。モデルコード自体が間違っている場合よりも、インフラの接続が間違っている場合の方がはるかに多い。
各段階が終わるたびに成果物をチェックリストで確認する習慣も役立つ。エンドポイントがInService状態か、ECRに最新イメージがあるか、Training JobがCompleted状態か、Model Packageの登録が完了しているか、バッチ出力がS3に結果ファイルとして存在するか、Data Capture Prefixにオブジェクトが生成されているか、CloudFront URLでアプリに接続できるかを確認する。「やったつもり」と「成果物が実際に見える」を区別することが合格に近づく道である。
ラボのリソース(Studio、バケット、ECR、エンドポイント)は通常一つのリージョンに紐づいているため、コンソール右上のリージョンを試験中に絶対に変えてはならない。リージョンが変わるとリソースが見えない現象が始まる。
カスタムコンテナを美しくリファクタリングする必要はない。試験は動作するパイプラインを求めるので、最小限の修正でビルドが通りエンドポイントが応答すればすぐに次の段階へ進む方がよい。
提出直前の最後の10分は検証専用として残しておくのがよい。CloudFront URLでアプリを開き、分類・生成のフローを一度ずつ呼び出してみて、Data Captureやバッチ出力も可能であればS3で直接目視確認する。この10分が思いのほか多くの減点を防いでくれる。
試験前に以下の項目を一度手を動かしてやってみると体感難易度が大きく下がる。SageMaker JumpStartでモデルをデプロイしエンドポイントを呼び出してみること、カスタム推論コンテナをECRにプッシュしエンドポイントに接続すること、Hugging Face Training DLCで簡単なFine-tuning Jobを実行すること、Model Registryにモデルパッケージを登録すること、Batch TransformでS3の入出力を確認すること、Data Captureをオンにしキャプチャファイルの位置を確認すること、API GatewayとLambda、CloudFrontで簡単な推論APIを公開してみることである。
こんな人におすすめ・非おすすめ
SageMakerをコンソールだけでも触ったことがある人、Dockerイメージをビルド・プッシュしたことがある人、S3パスとIAM Roleの関係を理解している人におすすめする。逆にモデル学習だけを試したことがありデプロイ・レジストリ・CDNは初めての人、コンテナログをほとんど読んだことがない人、リソース名を適当につける習慣がある人は事前の補強が必要である。この試験では適当につけたリソース名が致命的なミスにつながりやすい。
終わりに
この試験の本質はGenAIモデルを格好良く使うことではなく、AWS上でモデルをデプロイし、直し、学習・登録し、バッチで回し、観察・拡張しながらユーザーの手前まで接続するMLOps感覚を検証することにある。
準備するときはサービス一覧を暗記するよりも「この値が次の段階の入力である」というつながりを練習するのがよい。試験本番では与えられたキーバリューを正確に使い、中盤の難易度が高い区間に時間を残し、最後に成果物を目で直接確認すればよい。
ログを恐れない姿勢が重要だ。そのログこそが答案そのものである。