Question#28(MLS-C01)
ある EC 企業は、Amazon SageMaker を用いた本番のリアルタイム推薦エンジン API を更新したいと考えています。新しいモデルをリリースしたい一方で、その API に依存するアプリケーション側の変更は行いたくありません。また、新モデルを全ユーザーに完全展開する前に、本番トラフィックで新モデルの性能を評価したいと考えています。最小の運用負荷でこの要件を満たすソリューションはどれですか？
正解：B
最小の運用負荷で、アプリケーション側の変更なしに本番トラフィックで新旧モデルを比較評価したいのであれば、既存エンドポイントに複数のプロダクションバリアントをぶら下げ、重み（VariantWeight）でトラフィックを配分するのが最適です。エンドポイント名はそのままなのでクライアントの接続先やコードを変えずに済み、SageMaker の UpdateEndpointWeightsAndCapacities を使えば段階的に 10%→25%→50%→100% といった重み変更でカナリアリリース／A/B テストを安全に行えます。オートスケーリングやメトリクス（CloudWatch）もエンドポイント管理下で一元化され、追加の運用部品を持たずに評価と切り戻しが容易になります。これが運用負荷のもっとも小さいやり方です。
ALB や NLB を前段に置く案（１ と ４）は、SageMaker のリアルタイム推論 API（InvokeEndpoint）に対して別の負荷分散レイヤーを設けることになり、VPC 連携やヘルスチェック、ルーティング設定などの運用が増えます。さらに、新旧でエンドポイント URL が分かれるため、結局クライアント側のルーティングや接続先を変える手当てが必要になりがちで、「アプリ変更なし」という要件と相性がよくありません。 バッチ変換（３）はオフライン一括推論の仕組みで、リアルタイム API の本番トラフィックを分流して比較する用途には適合しません。オンライン推論のモデル切替・併走評価は、プロダクションバリアントによるトラフィックウェイト調整で行うのが設計上正しいです。
コメント