MLAMLソリューションの監視、メンテナンス、セキュリティ
eコマース企業のMLエンジニアは、リアルタイム推奨エンジンのSageMakerエンドポイントが本番で予期しない遅延スパイクを経験していることに気づきました。エンドポイントは複数のインスタンスにオートスケーリング設定されています。調査のために監視すべきCloudWatchメトリクスと対応アクションの組み合わせとして最も適切なものはどれですか？
A「ModelLatency」と「OverheadLatency」でボトルネックを特定し、CPUUtilizationが80%超ならスケールポリシーの閾値を下げ、ModelLatencyが高い場合は量子化・プルーニング等のモデル最適化を検討する
✓ 正解
ModelLatencyとOverheadLatencyを分離して確認することで、ボトルネックを正確に特定できます。CPUUtilization高時はスケール設定を見直し、ModelLatency高時はモデル最適化（量子化・プルーニング）を検討するという段階的なアプローチが効果的です。
B「InvocationErrors」メトリクスのみを監視し、エラー率が5%を超えたらエンドポイントを自動再起動するLambda関数をCloudWatch Alarmにフックして暫定的に対処する
InvocationErrorsメトリクスのみで監視し、エラー時にエンドポイントを単純に再起動するのは根本的な解決にはなりません。遅延の原因特定ができていません。
CSageMaker Debuggerのプロファイリング機能だけで遅延の原因を特定でき、CloudWatchメトリクスは推論エンドポイントのパフォーマンス監視には対応していないため確認不要
SageMaker Debuggerのプロファイリング機能だけでなく、CloudWatchメトリクスはエンドポイントに適用されます。むしろCloudWatchメトリクスの確認は必須の監視です。
D「Invocations」メトリクスで総リクエスト数のピークを確認し、トラフィック急増時にはエンドポイントを一度削除して再作成することで設定をリフレッシュして遅延を解消する
エンドポイントを削除して再作成することは、サービス中断を招き、遅延の根本原因を解決せずに一時的なリセットに過ぎません。非推奨の対応です。
解説
SageMakerエンドポイントのCloudWatchメトリクスでは、ModelLatency（モデル推論にかかる時間）とOverheadLatency（SageMakerのオーバーヘッド）を分離して確認することでボトルネックを正確に特定できる。CPUUtilizationが高ければリソース不足なのでスケール設定を見直し、ModelLatencyが高ければモデル側の最適化が有効。
選択肢Bはエラー発生時の単純な再起動で根本原因を解決しておらず、遅延スパイクの原因特定にはなりません。
選択肢CはCloudWatchメトリクスがSageMakerエンドポイントに適用されないという記述が誤りです。ModelLatencyやCPUUtilizationなどのメトリクスは標準で利用可能です。
選択肢Dはエンドポイントを削除して再作成するアプローチはサービス停止を伴い、スケール調整やモデル最適化と比べて非推奨です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでMLAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →