[レポート] モデルの比較が捗る! SageMaker の Shadow testing 機能についてのセッションレポートです! #reinvent #AIM343

本エントリはAWS re:Invent 2022のセッション「Amazon SageMaker shadow testing: Minimize prod impact of model updates (AIM343)」のレポートです。
2023.01.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんちには。

データアナリティクス事業本部 機械学習チームの中村です。

本記事では「Amazon SageMaker shadow testing: Minimize prod impact of model updates」というセッションについてレポートです。

なお本セッションは現地参加時に時間の都合で聴講できなかったため、オンデマンドで視聴しレポートを書いています。

また本機能については、以下で速報ブログを書いていましたが、この詳細についてデモも交えながら理解できるようなセッションとなっています。

セッションについて

  • タイトル
    • Amazon SageMaker shadow testing: Minimize prod impact of model updates
  • 登壇者
    • Tarun Sairam, Sr. Product Manager, Technical, Amazon Web Services
    • Vivek Govindapillai, Director Software Engineering, HERE Technologies
    • QINGWEI LI, SA, AWS
  • セッション情報
    • 日時: 2022-11-30 (Tue) 17:30-18:30
    • 形式: Breakout Session
    • 番号: AIM343
    • 会場: Mandalay Bay (Level 1 North, South Pacific F, Mandalay Bay)
    • レベル: 300 - Advanced

セッション概要

事前の案内としては以下の通りです。

Releasing new ML models can pose some risk of failure or poor performance because the changes are not put to the real test until they are live in the production environment. In this session, learn how to use Amazon SageMaker shadow testing to validate the performance of new ML models by comparing them against current models in production. Discover how SageMaker automatically deploys the new model, mirrors live traffic, collects metrics, and provides a side-by-side comparison of the metrics to help you spot potential errors and performance issues before they impact end users. Learn how HERE.com evaluates the performance of new ML models by deploying them in SageMaker shadow mode.

(日本語訳)

新しい ML モデルをリリースする場合、本番環境で稼動させるまで、その変更が実際にテストされないため、失敗や性能低下のリスクが生じることがあります。このセッションでは、Amazon SageMaker シャドウテストを使用して、新しい ML モデルのパフォーマンスを本番の現行モデルと比較して検証する方法を学びます。SageMaker がどのように新しいモデルを自動的にデプロイし、ライブトラフィックをミラーリングしてメトリクスを収集し、メトリクスを並べて比較することで、エンドユーザーに影響を与える前に潜在的なエラーやパフォーマンスの問題を発見することができるかをご覧ください。HERE.com が新しい ML モデルを SageMaker のシャドーモードでデプロイしてパフォーマンスを評価する方法をご紹介します。

セッション動画

セッション聴講内容

このセッションの内容は以下となっています。

  • MLライフサイクルの典型的な概要
  • モデルの検証やデプロイの側面にフォーカスし、既存の選択肢を比較
  • それらに対するShadow testingの立ち位置、そしてSageMakerでどのようにShadow testingを実施できるか
  • Shadow testing機能のデモ紹介
  • HERE Technologies社のShadow testingの活用事例

MLの典型的なライフサイクル

  • 機械学習は反復的なプロセスが必要で、上記のようなライフサイクルとなっています。
  • おおまかには、「モデルの構築」「検証とデプロイ」「モデルの監視」の3つのフェースから構成されます。

検証とデプロイの詳細

  • 更に詳しく「検証とデプロイ」を確認すると3つのオプションがあります。
    • Training Validation
    • これはトレーニング時に一般的に行う検証と同じものを指しているようです。
    • この欠点は、使用するデータが実環境と異なる可能性があること(「Data drift」と表現)です。
    • Offline Replays
    • 本番データをキャプチャして新しいモデルに入力して動作を確認することを指しています。
    • これによりデータは本番に近づきますが、レイテンシーなどの運用指標が悪くなる可能性があります。
    • Deployment Guardrails
    • これはSageMakerの推論機能で、モデルの更新を行う際、SageMakerがブルーグリーンデプロイメントを実行するものです。
    • トラフィックを移行させる粒度はコントロールすることが可能です。
    • また自動ロールバックが可能で、プリセットのトリガーを設定してロールバックさせることができるようになっています。
  • ただし、最後のDeployment Guardrailsを使っても、一部の顧客は新しいモデルを使用するために影響がある可能性があります。

  • そこで、Shadow testingが必要となります。
  • Shadow testingは、本番モデルと並行してShadow modelを導入し、トラフィックのコピーをShadow modelで処理してパフォーマンスを比較する手法のことです。
  • これにより顧客への影響を避けられますが、Shadow modelの短所は実装がかなり複雑であることです。

SageMakerのShadow testing機能について

  • そこで本日発表された機能では、SageMakerがShadow testingをネイティブにサポートする機能となっています。
  • Shadow testing機能の説明前に、SageMakerのエンドポイントの下に何があるのかについて説明がありました。
    • SageMakerのエンドポイントには、Production Variantと呼ばれる構成がある。
    • Production VariantはMLモデル、コンテナ、インスタンスの3つから構成される。
    • コンテナは独自のコンテナも持ち込むことが可能。
    • インスタンスについては、CPU、GPU、その他のacceleratedなインスタンスから選択が可能。
  • またオートスケーリングは、Production Variantの粒度でのスケーリング設定が可能です。
  • Shadow testing機能は、Production Variantとよく似たShadow Variantで実施されます。
  • 3つの構成物はProduction Variantと同じで、一部のみを入れ替えることが可能となっています。
    • つまりMLモデルのみを入れ替えたり、インスタンスのみを変えることが可能。
  • またSageMakerは、トラフィックの一部をシャドウバリアントにミラーリングすることが可能です。
  • トラフィックの量は0%から100%までを設定可能となっています。
  • Shadow Variantのレスポンスは破棄もできますし、Shadow VariantからS3バケットへのリクエストとレスポンスをログに記録することも可能です。

  • またこのShadow testing機能とともに、Shadow testingをエンドツーエンドで管理するためのツールも導入されています。
  • これにより、AWSコンソールからシャドーテストの作成、作成、監視、結果に対するアクションをすべて行うことが可能となっています。
  • その中でクールな機能として、あらかじめ定義された期間のみShadow testingを実施するような設定が可能となる機能を紹介されていました。
  • これにより、Shadow Variantを消し忘れたりすることを回避することができます。
  • また、画面上ではテストの進行中または完了後で、ライブダッシュボードで運用パフォーマンスを監視することが可能です。
  • パフォーマンスの比較の結果、先ほど述べたDeployment Guardrails機能によるによるデプロイメントのトリガーも可能となっています。

  • 費用については、インスタンスやストレージなどのインフラについて支払いが発生するようです。

デモ

ここからは画面で操作をしながらのデモが行われました。

大まかな設定として、既存のEndpointに追加するパターンと、EndpointとともにShadow testingを作成するパターンが選択できるようです。

今回はEndpointから作成されていました。

その下で、Variantsを追加することが可能になっています。ここでProduction VariantとShadow Variantを作成することが可能なようです。

以下が追加後の画面となっています。インスタンスタイプなどの変更は追加後に「Edit」から行えるようでした。

以下が先ほども言及されていたShadow testing期間を設定する項目のようです。

デフォルトでは7日間ですが、1時間から30日の間で変更することができます。

最後の設定は、予測リクエストとレスポンスをキャプチャするかどうかの設定で、デモではオフのまま進められました。

作成後、稼働中のShadow testingは以下のようなメトリクスが確認できるようになっています。

メトリクスで選択可能なものは以下のようです。

いわゆる機械学習のテストとしては、その精度や正解率など準備されているメトリクス以外の部分も監視する必要があるため、 それらを実現する場合は、予測リクエストとレスポンスをキャプチャして、自身で対応する必要がありそうです。

Analysisではこれらの詳細なグラフを確認可能です。

このデモでは、本番環境でのレイテンシーがシャドウ環境よりも大幅に高いため、Shadow Variantを本番環境としてデプロイするシナリオで説明されました。

Shadow Variantをデプロイするには、Deployment shadow variant ボタンをクリックする必要があります。

ここでVariantの設定を選択できますが、推奨はShadow Variantの設定をそのまま使用する設定です。

そしてデプロイすると、Shadow testingの期間中でもProduction Variant側は削除され、Shadow testingは完了というあつかいとなるようです。

HERE Technologiesの事例紹介

ここからはHERE Technologiesの紹介と、Shadow testingの活用事例について説明がありました。

HERE Technologeis社は、デジタルで世界の地図を作る企業の1つで、以下のようなことをやっているようです。

  • 道路を走る1億7千万台以上の車の認識を補助
  • 交通量やETSを予測することでお客様を支援
  • お客様の中の独自のデータ(位置情報)を活用して物流用のプライベートマップを作成することを可能に

HERE Technologies社では機械学習が多く活用され、例えば混雑状況の予測やそれに基づくルーティングなど、救急車や消防車、警察など、実世界の重要なサービスで使用されています。

そのため、モデルをロールアウトする際、そのパフォーマンスがすでに稼働しているものと同等かそれ以上であることを確認することは、非常に重要となっています。

HERE Technologies社が提供するワークスペースには、元々位置情報を中心とした問題を解決するためのツール群が提供されており、ここにSageMakerが統合されたようです。

ワークスペースには、ローコードで拡張可能なワークフローエディタなども含まれているようです。

実際に、SageMakerとShadow testingの機能を使った具体的な事例が紹介されました。

事例としては、交通事故のリアルタイムフィードをから、特定の道路セグメントで発生する遅延コストを予測するようなものとなっています。

実際これらのアーキテクチャには、Shadow testingは出てきません。

その理由としてはShadow testingはSageMaker内で制御されるため、使用する側としてはShadow testingの実施を意識する必要がないためです。

そのため、独立してMLモデルをテストすることが可能となっています。

まとめ

いかがでしたでしょうか。

こちらのセッションでShadow testingについて詳細を理解することができました。 エンドポイントを複数構成しなくても、複数のMLモデルのテストができるようになったのは便利そうですね。

いわゆる機械学習のテストとしては、その精度や正解率など準備されているメトリクス以外の部分も監視する必要があるため、 それらを実現する場合は、予測リクエストとレスポンスをキャプチャして、自身で対応する必要がありそうです。

Shado testingで制御してくれること、開発者側で対応すべきことが明確になったため良いセッションだったかなと思います。

Shadow testingについて詳細を知りたい方は、オンデマンド動画の方も是非視聴ください!