MLS-4.4機械学習ソリューションの展開と運用の実現。

ヒントボタン

Amazon SageMaker Model Monitor が参照するデータ品質ベースラインを差し替える手順は決まっています。Processing ジョブで直近 10 万件の推論入力を S3 から取り込み statistics.json と constraints.json を再生成し、続いて UpdateMonitoringSchedule API で稼働中スケジュールの BaselineConfig を上書きすればエンドポイントは停止せずに継続稼働できます。デプロイやローリング更新も不要なため、ダウンタイムやリクエスト損失を心配する場面がなく、要件 1 の「無停止更新」をそのまま満たせるのがポイントです。

90 日周期でデータ分布が動くなら EventBridge の cron 式ルールで自動トリガを作り、そのタイミングだけ SageMaker Processing ジョブを ml.t3.medium など低料金インスタンスで数分走らせる方法が最もシンプルです。ジョブ 1 回の費用は数十セント程度なので月平均 1 USD を大きく下回ります。対照的に Kinesis Data Firehose や AWS Glue のような常時稼働サービスは待機中でも課金が発生し、コスト上限を超えやすい点に注意しましょう。IAM ロールを正しく設定すれば完全自動で運用者の作業もなくせます。

CloudWatch のアラーム設定を柔軟にして通知自体を減らしても、ベースラインが古いままでは本質的なドリフト検知になりません。またエンドポイントを再作成する方法は切替時間中のサービス停止リスクと追加インスタンス料金を伴います。さらに S3 に新しいベースラインを書き出しても MonitoringSchedule が参照先を更新しなければ効果は出ません。無停止・低コスト・省力化という三つの要求を俯瞰し、どの案が同時に満たせるかを軸に判断してください。

ヒントボタン

SageMaker エンドポイントの Variant ごとに遅延を抑えながらコスト最適化を図るには、AWS CLI で aws application-autoscaling register-scalable-target を実行し、resource-id=sageMakerEndpoint/エンドポイント名/variant/バリアント名 と ScalableDimension=sagem

ヒントボタン

Bring-Your-Own-Container で Amazon SageMaker を使う場合、ENTRYPOINT を「python -m sagemaker_training」にして ENV SAGEMAKER_PROGRAM で train.py を指定すると、SM_CHANNEL_TRAIN や SM_HP_*、SM_MODEL_DIR など SageMaker が自動注入する環境変数と /opt/ml/input/data のチャンネル構成がそのままスクリプトへ渡り、Spot Training の中断再開や将来の分散学習も追加実装なしで利用できるため運用負荷を大きく下げられます。

Python スクリプトを直接呼び出すだけの ENTRYPOINT は見た目はシンプルですが、aws sagemaker create-training-job から渡される hyperparameters が自動マッピングされず、SM_HOSTS や SM_CURRENT_HOST を用いた Horovod や SageMaker Distributed の初期化も自前実装となり、引数追加のたびに argparse 修正やラッパー更新が必要になるため、sagemaker-training-toolkit を経由する形が将来の拡張性を確保します。

コスト削減を図る Spot Training、CLI からの柔軟なハイパーパラメータ指定、そしてチャンネル・環境変数の自動利用という複数要件を総合的に満たすには、AWS ドキュメントが推奨する Toolkit への委譲型 ENTRYPOINT と SAGEMAKER_PROGRAM の組み合わせが最も整合性と保守性に優れるという判断になります。

ヒントボタン

SageMaker のトレーニングジョブは GPU ドライバと nvidia-container-runtime をホスト側で用意している前提で動くため、利用者が Amazon ECR に登録するイメージは CUDA と PyTorch などユーザランドライブラリだけを含めれば十分で、AWS が公開する PyTorch GPU 向け SageMaker Deep Learning Container をベースにして requirements.txt で追加の pip install を行い自社推論ライブラリと学習スクリプトをレイヤーとして重ねる方法が、他の依存関係を意識せず最もスムーズに GPU を利用できます。
イメージ内に nvidia-docker2 や NVIDIA ドライバを詰め込んで ENTRYPOINT で –runtime=nvidia を明示すると一見オンプレと同じ構成に見えますが、SageMaker では containerd がランタイムを管理しホストドライバとのバージョン整合もサービス側の責務となるため、ユーザがそれらを重複管理すると再ビルドや脆弱性対策のたびに大きな保守コストが発生し、検証環境と本番環境の差異によるトラブルシュートも複雑化します。
Kubernetes ベースの Amazon EKS に移行して GPU ノードや nvidia-device-plugin を自前で構成すれば自由度は得られるもののクラスター運用が必要となり Auto Scaling や AMI 更新、Security Hub 連携まで考慮する必要が出てくる一方、SageMaker の Deep Learning Container を活用すれば Framework 更新やセキュリティパッチを AWS が担い Spot Training や Experiments も容易に併用できるため、複数要件を俯瞰すると運用負荷と安定性のバランスが取れた選択肢は自ずと限られてきます。

ヒントボタン

CI/CD と脆弱性管理を最小工数で統合するなら、CodePipeline と CodeBuild で Docker をビルドし、そのまま Amazon ECR Image Scanning を走らせる流れが自然です。レジストリが同一リージョン内に完結しスキャンもマネージドで可視化されるため、別途 Clair や Trivy をセルフホストする構成より IAM 設計・ネットワーク設定・ログ集約が大幅に簡素化でき、「最小運用負荷」の要件に沿いやすくなります。

無停止の Blue/Green と即時ロールバックを考えると、SageMaker UpdateEndpoint の Traffic-shifting ポリシーに CloudWatch アラームを組み合わせる方式が鍵です。ヘルスチェック失敗時に自動で旧バージョンへ戻るため、Amazon EKS や Argo CD を用いて ALB ルールや Replica 数を手動調整するケースと比べて手順が少なく、監視と復旧をサービス側に任せられます。これにより運用者はモデル品質の確認に専念できます。

10 MB 以下の画像を暗号化転送するには S3 presigned URL と HTTPS が適しており、推論コードを組み込める SageMaker リアルタイムエンドポイントなら Auto Scaling で 2 000 req/min と P95 150 ms の指標も達成可能です。CI/CD、脆弱性スキャン、Blue/Green、暗号化転送という複数要件を一気通貫でフルマネージドに満たせるかを総合的に評価して最適な設計を選びましょう。

ヒントボタン

SageMaker エンドポイントは推論呼び出しごとに p95 などの InvocationLatency メトリクスを自動で CloudWatch に発行します。5 分平均で 200ms を超えた瞬間に通知したい場合、CloudWatch Alarms で統計 period を 5 分に設定し、SNS で Slack Webhook へ送るのが最短経路です。Lambda や常時起動の EC2 を介在させると遅延要因と保守対象が増えるため、要件の「即時アラート」「運用負荷最小化」というキーワードと整合するかを見比べてみましょう。

UpdateEndpoint や UpdateEndpointConfig はコントロールプレーンの API 呼び出しなので必ず CloudTrail の管理イベントに記録されます。EventBridge ルールで eventName フィルタを使えばリアルタイムに抽出でき、同じ SNS トピックへルーティングすれば Slack 通知までの経路が一本化できます。AWS Config は評価間隔が最短 1 時間ですし、Athena クエリや Datadog 転送のように中間バッチ処理を挟むと「10 分以内通知」の制約を満たしにくい点を思い出してください。

メトリクス監視は CloudWatch、API 操作検知は CloudTrail＋EventBridge、通知は SNS で統一すると、すべてフルマネージドで EC2 や長時間稼働の Lambda を持たずに済みます。5 分平均遅延の即時検知、10 分以内の構成変更アラート、運用コスト抑制という三つの要件を同時に達成できる構成かどうかを俯瞰して判断しましょう。

ヒントボタン

Amazon SageMaker のリアルタイムエンドポイントは ModelLatency p95 や InvocationsPerInstance、4XXError、5XXError、GPUUtilization などの CloudWatch メトリクスを標準で出力するため、それらを CloudWatch ダッシュボードに並べれば 95 パーセンタイル 80ms や 1 秒 1500 リクエストの SLA を単一画面で可視化でき、外部監視基盤を用意する手間を省けます。
レイテンシ 80ms や GPUUtilization 90% といった閾値を CloudWatch Alarm に設定し、そのアクションに Application Auto Scaling のターゲット追跡ポリシーと SNS 連携の PagerDuty Webhook を同時に結び付ければ、負荷に応じた自動スケールアウトと 4XX/5XX 0.5% 超過時の即時通知を無停止で実現できます。
SageMaker Model Monitor の Model Quality ジョブを有効化して精度ドリフトを測定し、その結果を CloudWatch メトリクスとしてダッシュボードへ統合すれば、レイテンシ・スループット・GPU 負荷・エラー率・精度を一元監視でき、可視化と制御を一つのマネージドサービス群で完結させるという複数要件を俯瞰した総合判断につながります。