Amazon Web Services ブログ

Amazon SageMakerを使用したリアルタイム推論モデルのエンドポイントにおけるMLOps デプロイメントのベストプラクティス

構築、トレーニング、評価を完了した機械学習（ML）モデルが、提案されたビジネス上の課題を解決していることを確認した後、ビジネスオペレーションにおいて意思決定を可能にするために、そのモデルをデプロイすることが望まれます。ビジネスに重要な機能を持つモデルは、モデルリリース戦略が導入される本番環境にデプロイされます。MLモデルの特性上、データが常に変化するため、デプロイされたモデルが新しいデータに対しても依然として適切であり、そうでない場合はモデルが更新されることを確認する必要があります。これには、リスクとダウンタイムを最小限に抑えるデプロイ戦略を選択することも含まれます。この最適なデプロイ戦略は、モデルの高可用性を維持し、既に本番環境にデプロイされているモデルよりも劣ったモデルをデプロイすることのビジネスコストを考慮し、以前のモデルバージョンに簡単にロールバックする機能を含める必要があります。これらの推奨事項やデプロイメント パターンの多くは、AWS Well Architected Framework – Machine Learning Lensでもカバーされています。

適切なデプロイメント戦略を選択することに加えて、その戦略はMLOpsの実践を含む信頼性の高いメカニズムを用いて実装する必要があります。MLOpsには、MLプロジェクトの独自の側面を考慮したリリース管理、CI/CD、およびオペレーションにMLワークロードを統合する実践が含まれます。MLOps用Amazon SageMakerは、MLライフサイクル全体にわたるステップの自動化と標準化を実現するための専用ツールを提供しており、高度なデプロイメントパターンを用いて新しいモデルをデプロイおよび管理する機能も備えています。

この記事では、Amazon SageMaker を使用して ML モデルを反復可能かつ自動化された方法でデプロイし、SageMaker のプロダクションバリアントとデプロイガードレール機能を MLOps ソリューションと統合する方法について説明します。 リアルタイムの単一モデルのエンドポイントに焦点を当てて、SageMaker の MLOps ツールを SageMaker モデルのデプロイメント パターンと統合する方法を紹介します。

ソリューションの概要

以下のモデルのテストとガードレールのパターン、およびそれらの SageMaker MLOps ツールとの統合について調査します。

  • モデルのテスト – 現在のモデル バージョンを置き換える前に、本番環境で異なるモデル バージョンを比較します。 この記事では、次のモデルのテスト機能を比較します。
    • A/B テスト – A/B テストでは、モデルバリアント間でエンドポイント トラフィックを分散することにより、本番環境でモデルの異なるバージョンを比較します。 A/B テストは、閉ループによってモデルの出力を下流のビジネス指標に直接結び付けることができるシナリオで使用されます。 このフィードバックは、あるモデルから別のモデルへの変更の統計的有意性を判断するために使用され、本番テストを通じて最適なモデルを選択するのに役立ちます。
    • シャドーテスト – シャドー テストでは、本番モデルと新しいモデルに並行してリクエストを送信することで、本番環境でモデルの新しいバージョンをテストします。 本番モデルからの予測応答データはアプリケーションに提供され、新しいモデルバージョンの予測はテスト用に保存されますが、本番アプリケーションに提供されません。 シャドーテストは、ビジネス指標をモデルの予測にマッピングする閉ループ フィードバックが存在しない状況で使用されます。 このシナリオでは、下流のビジネス指標に影響を与えるのではなく、モデルの品質と運用指標を使用して複数のモデルを比較します。
  • トラフィックのシフト – 新しいバージョンのモデルをテストし、そのパフォーマンスに満足したら、次のステップはトラフィックを現在のモデルから新しいモデルに移行することです。 SageMaker のBlue/Green デプロイ ガードレールを使用すると、運用中の現在のモデル (ブルーフリート) から新しいモデル (グリーンフリート) への切り替えを、制御された方法で簡単に行うことができます。Blue/Green デプロイメントは、インプレースデプロイメント (In-Place Deployment)の場合に発生するようなモデル更新中のダウンタイムを回避することができます。この記事が書かれた時点では、モデルの可用性を最大化するため、SageMakerにおいてBlue/Green デプロイメントがモデルの更新においてデフォルトのオプションになっています。この記事では、以下のトラフィックシフトの方法について説明します。
    • All At Once トラフィックシフト –
      グリーンフリートが利用可能になったら、エンドポイントトラフィックの100%がブルーフリートからグリーンフリートに移行されす。Amazon CloudWatchのアラームを使用して、一定時間（ベーキング期間）グリーンフリートを監視し、アラームがトリガーされなければ、ベーキング期間終了後にSageMakerによってブルーフリートが削除されます。
    • カナリア トラフィックシフト –
      グリーンのフリートにトラフィックの一部を（カナリアリリース）最初に流し、CloudWatchアラームでベーキング期間中に問題がないか確認します。同時に、ブルーフリートはエンドポイントのトラフィックの大部分を受け取り続けます。グリーンフリートが検証された後、すべてのトラフィックを新しいフリートに移行し、SageMakerによってブルーフリートが削除されます。
    • Blue/Greenの線形トラフィックシフト ガードレール –
      ブルーフリートからグリーンフリートへ徐々にトラフィックを移行する段階的なアプローチを取ります。ブルーフリートが完全に置き換えられるまで、各段階でCloudWatchアラームでモデルを監視します。

この記事では、SageMaker MLOpsの機能を活用したアーキテクチャに焦点を当て、デプロイメント ガードレールとモデリングテスト戦略を使用してモデルの制御されたデプロイメントを行う方法について説明します。これらのパターンに関する一般的な情報は、「Amazon SageMakerのデプロイメントガードレールを利用した高度な展開戦略の活用」と「デプロイメントガードレール」を参照してください。

SageMaker を使用してモデルをデプロイする

SageMakerは、低レイテンシーおよび高スループットから長時間実行する推論ジョブまで、幅広いデプロイメントオプションを提供しています。これらのオプションには、バッチ、リアルタイム、またはほぼリアルタイムの推論を考慮したものが含まれます。各オプションには、単一エンドポイントで複数のモデルを実行できるといった異なる高度な機能があります。ただし、この記事では、MLOpsデプロイメントパターンについて、単一モデルエンドポイントを使用したもののみをカバーしています。リアルタイム推論のためのより高度なSageMakerデプロイメント機能については、「Model hosting patterns in Amazon SageMaker, Part 2: Getting started with deploying real time models on SageMaker」を参照してください。

継続的デリバリー (CD) パイプラインを使用した高度なデプロイメント パターンの実装を理解するために、まずモデルバリアントと呼ばれる SageMaker 内の重要な概念について説明します。

SageMaker のモデルバリアント

モデルバリアントを使用すると、モデルの複数のバージョンを同じエンドポイントにデプロイしてテストできます。モデルバリアントは別々のインスタンスにデプロイされるため、1つが更新されても他のバリアントには影響がありません。SageMakerでは、モデルバリアントはプロダクションバリアントとシャドーバリアントとして実装されています。

プロダクションバリアントを使用すると、複数のモデルバージョンをA/Bテストして性能を比較できます。この場合、すべてのモデルバージョンがモデル要求に対してレスポンスを返します。エンドポイントトラフィックは、トラフィック分散によって、各バリアントに重みを割り当てる場合と、ターゲットバリアントによって、一定のパラメータ（たとえば、リージョンやマーケットなど）がどのモデルを呼び出すかを決定する場合があります。

シャドーバリアントを使用すると、モデルの新しいバージョンのシャドーテストができます。この場合、プロダクションバリアントとシャドーバリアントが同じエンドポイントに並行してデプロイされます。シャドーバリアントは、エンドポイントからフル（またはサンプル）のデータトラフィックを受け取ります。ただし、アプリケーションのユーザーにはプロダクションバリアントの予測結果のみが送信され、シャドーバリアントの予測結果は分析のために記録されます。シャドーバリアントは、プロダクションバリアントとは別のインスタンスで起動されるため、このテストによるプロダクションバリアントのパフォーマンスへの影響はありません。このオプションを使用すると、新しいモデルをテストし、低性能なモデルのリスクを最小限に抑えることができ、同じデータで両方のモデルの性能を比較することができます。

SageMaker デプロイメントのガードレール

ガードレールはソフトウェア開発に不可欠な部分です。 これらはアプリケーションを保護し、アプリケーションの新しいバージョンのデプロイメントのリスクを最小限に抑えます。 同様に、SageMaker デプロイメント ガードレールを使用すると、制御された方法で、あるモデル バージョンから別のモデル バージョンに切り替えることができます。 2022 年 12 月の時点で、SageMaker ガードレールは、Blue/Green、カナリア、および線型 トラフィック シフティングのデプロイメントオプションを提供しています。 モデルバリアントと組み合わせて使用することで、デプロイメントガードレールは、プロダクションおよびシャドーバリアントの両方に適用でき、選択したオプションに従ってトラフィックのシフトを制御し、新しいバリアントの更新中にダウンタイムが発生しないように保証します。

モデルデプロイメントのための MLOps 基盤

ML モデルの構築とデプロイのワークフローというより広いコンテキストで、ML ワークフロー専用に構築された CI/CD プラクティスを採用したいと考えています。 従来の CI/CD システムと同様に、ソフトウェア テスト、統合テスト、および本番環境のデプロイメントを自動化したいと考えています。 ただし、モデルのトレーニング、モデルの実験、モデルのテスト、モデルのモニタリングなど、従来のソフトウェア開発ライフサイクルには存在しない特定の操作も ML ライフサイクルに含める必要もあります。

これらの ML 固有の機能を実現するために、自動モデル テスト、デプロイ ガードレール、マルチアカウント デプロイ、自動モデル ロールバックなどの MLOps 基盤がモデル デプロイ プロセスに追加されます。 これにより、すでに説明した機能によりモデルのテストが可能になり、モデルの更新プロセス中のダウンタイムが回避されます。 また、本番対応モデルの継続的な改善に必要な信頼性とトレーサビリティも提供します。 さらに、既存のソリューションを再利用可能なテンプレートにまとめて、マルチアカウント設定でモデルをデプロイすることができるような機能により、本記事で議論されたモデルデプロイメントパターンを組織全体の複数のモデルにスケーラブルにデプロイできます。

次の図は、エンドツーエンドのモデル構築とデプロイメントパイプラインを作成するために、SageMakerの機能を接続するための一般的なパターンを示しています。この例では、SageMaker Processing ジョブを使用して、MLアルゴリズムに必要なデータの前処理を行うためのデータ処理コードを実行するために、SageMakerでモデルが開発されます。次に、SageMaker Training ジョブを使用して、処理ジョブで生成されたデータでMLモデルをトレーニングします。トレーニングプロセスの最後のステップとして、モデルアーティファクトと関連するメタデータがSageMaker Model Registryに格納されます。これは、MLのCI/CDを自動化および管理するための目的で構築されたSageMaker Pipelinesによってオーケストレーションされます。

モデルが承認されると、A/B テストまたはシャドー デプロイメントを使用して本番環境でテストを行います。 モデルが本番環境で検証された後、モデル レジストリを使用して、デプロイメントガードレール の一つオプションを利用し、SageMaker エンドポイントへの本番モデルのロールアウトを承認します。

モデルの更新プロセスが完了すると、SageMaker Model Monitor はモデルのパフォーマンスの変動とデータ品質を継続的に監視します。 このプロセスは、リソースを完全に分離し、コスト管理を容易にするために、インフラストラクチャのデプロイメントをマルチアカウントのセットアップにマッピングする SageMaker プロジェクト テンプレートを使用して、複数のユースケースに合わせて自動化されます。

単一モデルのエンドポイントにおけるデプロイパターン

モデルを最初に本番環境にデプロイする時は、比較する実行中のモデルがないため、デプロイされたモデルがビジネスアプリケーションで使用されることになります。モデルが本番環境でデプロイされ、監視を始めた後に、もし新しいデータが利用可能になったり、またはモデルの性能問題が検出された場合には、モデルを定期的にまたは必要に応じて更新する必要があります。既存のモデルを更新する場合、新しいモデルが現在のモデルよりも優れた性能を発揮し、ビジネスアプリケーションからの予測リクエストトラフィックを処理できることを確認する必要があります。この検証期間中、アプリケーションのダウンタイムのリスクを最小限に抑えるために、ロールバックの可能性に対して現在のモデルを引き続き使用できるようにする必要があります。

より広範囲なモデル開発の観点から見ると、モデルは通常、データサイエンスの開発アカウントでトレーニングされます。これには、モデル開発でよく使用される実験ワークフロー、および本番用のパイプラインで使用される再トレーニングワークフローが含まれます。これらの実験のすべてのメタデータは、開発中にAmazon SageMaker Experimentsを使用して追跡できます。ワークフローが本番用のパイプラインに組み込まれた後は、メタデータが自動的にSageMaker Pipelinesを通じて追跡されます。モデルのパフォーマンスメトリック（適合率、再現率など）が本番用に適したレベルにまで実験が進んだら、SageMaker Pipelinesの条件ステップでモデルをモデルレジストリに登録して、1つの場所で実用的な本番モデルを追跡することができます。

モデル レジストリを使用すると、手動または自動の承認プロセスでこのモデルのデプロイメントをトリガーできます。 このデプロイは ML テスト アカウントで行われ、統合テスト、単体テスト、モデルのレイテンシ、追加のモデル検証などの本番テストを新しいモデル バージョンに対して実行できます。 A/B テストとシャドー テストは、ML テスト アカウントではなく、ML 本番アカウントで実行されることに注意してください。

テストアカウントですべての検証をパスすると、モデルは本番環境にデプロイする準備ができています。新しい承認プロセスがこのデプロイメントをトリガーし、SageMakerデプロイメントガードレールにより、トラフィックシフトモードに応じた制御されたリリースと透明なモデル更新プロセスが可能となります。

次の図は、このソリューション アーキテクチャを示しています。

All At Once トラフィックシフト

All At Once トラフィックシフトモードでは、トラフィックの 100% を現在のモデル (ブルー フリート) から新しいモデルに完全に移行することで、新しいモデル バージョン (グリーン フリート) を更新できます。 このオプションを使用すると、モデルの両方のバージョンがまだ実行されているベイク期間を構成でき、新しいモデルが期待どおりに動作しない場合は、現在のバージョンに迅速かつ自動的にロールバックできます。 このオプションの欠点は、すべてのデータ トラフィックが一度に影響を受けるため、モデルのデプロイメントに問題がある場合、デプロイメント プロセス中にアプリケーションを使用しているすべてのユーザーが影響を受けることです。 次のアーキテクチャは、All At Once トラフィックシフトオプションがモデルの更新をどのように処理するかを示しています。

All At Once トラフィックシフトは、BlueGreenUpdatePolicyが　ALL_AT_ONCEに設定されたエンドポイントデプロイメント構成を定義することによって、MLOpsツールに組み込むことができます。MLOpsパイプラインにおいて、新しいモデルがMLプロダクションアカウントにデプロイされることが承認された後、SageMakerはモデルのエンドポイントがすでに存在するかどうかをチェックします。存在する場合、ALL_AT_ONCE構成がアーキテクチャに従ってエンドポイントの更新をトリガーします。エンドポイントのロールバックは、エンドポイントAutoRollbackConfigurationで定義された　CloudWatchアラームに基づいて制御されます。アラームがトリガーされると、自動的に現在のモデルバージョンにロールバックが開始されます。

カナリア トラフィックシフト

カナリア トラフィック シフト モードを使用すると、実行中のモデル (ブルー フリート) を新しいバージョンに更新するか、または新しいバージョンをロールバックする前に、データ トラフィックのごく一部を使用して新しいモデル (グリーン フリート) をテストすることができます。 新しいモデルのテストに使用されるトラフィックの部分はカナリアと呼ばれます。このオプションは、更新時間を最小限に抑えながら、新しいモデルに問題がある場合に、そのリスクがカナリア トラフィックによって最小限に抑えられます。

カナリアデプロイメントを使用すると、新しいモデル バージョンを少数のユーザー グループに公開して、一定期間の有効性を監視することで、新しいモデル バージョンを実装するリスクを最小限に抑えることができます。 デメリットは、パフォーマンスの影響を判断するのに十分な意味のあるパフォーマンスメトリックを収集するために一定期間にわたって複数のバージョンを管理する必要があることです。利点は、リスクを一部のユーザーに限定できることです。

BlueGreenUpdatePolicy を CANARY に設定してエンドポイント デプロイメント構成を定義し、新しいモデル バージョンにリダイレクトするエンドポイント トラフィックの量を決定する CanarySize を定義することで、カナリア トラフィックのシフトを MLOps ツールに組み込むことができます。 All At Onceオプションと同様に、MLOps パイプラインでは、新しいモデルの ML 本番アカウントへのデプロイが承認された後、SageMaker はモデルのエンドポイントがすでに存在するかどうかを確認します。 その場合、CANARY 構成は、次の図に概要が示されているアーキテクチャに従ってエンドポイントの更新をトリガーします。 エンドポイントのロールバックは、エンドポイントの AutoRollbackConfiguration によって定義された CloudWatch アラームに基づいて制御され、トリガーされると現在のモデル バージョンへのモデルのロールバックが自動的に開始されます。 ここでデプロイするのに役立つアラーム タイプは、500 ステータス コードとモデル レイテンシです。 ただし、これらのアラーム設定は、特定のビジネス ユースケースと ML テクノロジーに合わせてカスタマイズする必要があります。

線形トラフィックシフト

線形トラフィックシフトモデルでは、新しいモデルに送信されるデータ トラフィックを段階的に増やすことによって、トラフィックを現在のモデル (ブルーフ リート) から新しいモデル バージョン (グリーン フリート) に徐々に変更します。 このようにして、新しいモデル バージョンのテストに使用されるトラフィックの割合がステップごとに徐々に増加し、各ステップのベイク時間により、モデルが新しいトラフィックでも引き続き動作することが保証されます。 このオプションを使用すると、パフォーマンスの低いモデルをデプロイするリスクを最小限に抑え、新しいモデルを徐々により多くのデータ トラフィックにさらすことができます。 このアプローチの欠点は、更新時間が長くなり、両方のモデルを並行して実行するコストが増加することです。

線形トラフィック シフトを MLOps ツールに組み込むには、BlueGreenUpdatePolicy を LINEAR に設定してエンドポイント デプロイメント構成を定義し、LinearStepSize を定義して各ステップで新しいモデルにリダイレクトされるトラフィックの量を決定します。All At Onceオプションと同様に、MLOps パイプラインでは、新しいモデルの ML 本番アカウントへのデプロイが承認された後、SageMaker はモデルのエンドポイントがすでに存在するかどうかを確認します。 その場合、LINEAR 構成は、次の図に示されているアーキテクチャに従ってエンドポイントの更新をトリガーします。 エンドポイントのロールバックは、エンドポイントの AutoRollbackConfiguration によって定義された CloudWatch アラームに基づいて制御され、トリガーされると現在のモデル バージョンへのモデルのロールバックが自動的に開始されます。

モデルのプロダクション バリアントを使用したデプロイメントパターン

アプリケーションのデプロイメントパターンにかかわらず、エンドポイントの更新前にモデルのパフォーマンスを検証したり、シャドーデプロイメントのような追加のデプロイメントパターンを実装したりするために、プロダクション バリアントを利用することもできます。この場合、エンドポイントを更新する前に、最適なモデルを選択するための手動または自動プロセスを追加する必要があります。次のアーキテクチャは、シャドーデプロイメント シナリオにおけるエンドポイントのトラフィックとレスポンスの振る舞いを示しています。このシナリオでは、各予測リクエストは新しいモデルとデプロイされたモデルの両方に送信されます。ただし、現在デプロイされているモデルだけがビジネス アプリケーションに対して予測レスポンスを提供し、新しいモデルからの予測は、現在デプロイされているモデルとのパフォーマンスの比較の分析のためだけに保持されます。モデルのパフォーマンスが評価されると、新しいモデルバージョンをビジネスアプリケーションの予測レスポンストラフィックに提供するためにデプロイすることができます。

ロールバック

モデルのデプロイメント戦略に関係なく、新しいモデルの性能が現在のモデルの性能よりも低い場合に前のモデルバージョンに戻る必要がある場合があります。アプリケーションのダウンタイムを最小限に抑えながらこれを行うために、新しいモデルが現在のモデルよりも優れていると確信するまで、現在のモデルを新しいモデルと並行して実行する必要があります。

SageMakerデプロイメントガードレールにより、モデル検証期間中にアラームを設定して、自動的に以前のモデルバージョンに戻すことができます。検証期間が終了し、モデルの更新が完了した後に新しい問題が発見された場合に、以前のモデルバージョンに戻す必要があり、その場合に、SageMakerモデルレジストリを利用してモデルの承認および拒否を行い、ロールバックプロセスをトリガーすることができます。

結論

この記事では、SageMakerエンドポイントモデルバリアントとデプロイメントガードレールをMLOps機能と組み合わせて、モデル開発のエンドツーエンドのパターンを作成する方法について述べました。またSageMaker Pipelinesとモデルレジストリを介して、カナリアおよび線形シフト デプロイメントガードレールの実装例を紹介しました。次のステップとして、組織のデプロイ戦略を実装するために、以下のテンプレートを試してみてください。

参考文献

著者について

​

Maira Ladeira Tanke は、AWSのML Specialist Solutions Architectです。データサイエンスのバックグラウンドを持ち、9年間にわたり様々な業界の顧客と共にMLアプリケーションの設計や構築に携わってきました。テクニカルリードとして、新興技術や革新的なソリューションを活用し、顧客のビジネス価値の実現を加速する手助けをしています。プライベートでは、旅行や家族と温かい場所で過ごすことを楽しんでいます。
Clay Elmoreは、AWSのAI/ML Specialist Solutions Architectです。材料研究室で多くの時間を費やした後、彼は化学工学のバックグラウンドを早く捨てて、機械学習への興味を追求しました。彼はエネルギー取引からホスピタリティマーケティングまで、さまざまな業界でMLアプリケーションに取り組んできました。Clayは、MLにソフトウェア開発のプラクティスを取り入れ、これらの原則を使用して繰り返し可能でスケーラブルなソリューションに向けて顧客を導くことに特に関心があります。趣味は、スキー、ルービックキューブの解決、読書、料理です。
Shelbee Eigenbrodeは、AWSの主任AIおよび機械学習スペシャリストソリューションアーキテクトです。彼女は24年間にわたり、複数の業界、技術、および役割でテクノロジーに従事してきました。現在は、DevOpsとMLのバックグラウンドを組み合わせて、MLOpsの領域に注力し、顧客がスケールできるMLワークロードを提供および管理できるよう支援しています。彼女は、様々な技術領域で35以上の特許を取得しており、データを活用してビジネス成果を推進することに情熱を持っています。Shelbeeは、Courseraの「実践的データサイエンス」専門化の共同作成者および講師でもあります。また、Women In Big Data（WiBD）のデンバー支部の共同ディレクターでもあります。彼女は自由時間には、家族や友人、そして活発な犬たちと過ごすことが好きです。
Qiyun ZhaoはAmazon SageMaker Inference Platformチームのシニアソフトウェア開発エンジニアです。彼はデプロイメントガードレールとシャドウデプロイメントのリード開発者であり、顧客が高可用性を持つスケールでMLワークロードとデプロイメントを管理するのを支援することに焦点を当てています。また、高速で安全なMLジョブのデプロイメントと、MLオンライン実験の簡単な実行のためのプラットフォームアーキテクチャの進化にも取り組んでいます。彼の趣味は読書、ゲーム、旅行です。

翻訳はPrototype Engagement ManagerのWen(文連子)が担当しました。原文はこちらです。