デプロイ

ソフトウェアエンジニアリングでは、コードを本番稼働環境に配置するには、注意が必要です。コードが予期せず動作したり、ユーザーの予期しない動作によってソフトウェアが破損したり、予期しないエッジケースが見つかったりする可能性があるためです。ソフトウェアエンジニアと DevOps エンジニアは通常、ユニットテストとロールバック戦略を使用してこれらのリスクを軽減します。ML では、実際の環境がドリフトすることが予想されるため、モデルを本番環境に配置するにはさらに多くの計画が必要です。多くの場合、モデルは改善しようとしている実際のビジネスメトリクスのプロキシであるメトリクスで検証されます。

このセクションのベストプラクティスに従って、これらの課題に対処してください。

デプロイサイクルを自動化する

ヒューマンエラーを防ぎ、ビルドチェックが一貫して実行されるように、トレーニングとデプロイのプロセスを完全に自動化する必要があります。ユーザーには、本番環境への書き込みアクセス許可を付与しないでください。

Amazon SageMaker AI Pipelines と AWS CodePipeline CI/CD pipelines for ML projects. One of the advantages of using a CI/CDは、データの取り込み、モデルのトレーニング、モニタリングの実行に使用されるすべてのコードは、Git などのツールを使用してバージョン管理できます。場合によっては、同じアルゴリズムとハイパーパラメータを使用してモデルを再トレーニングする必要がありますが、データは異なります。正しいバージョンのアルゴリズムを使用していることを確認する唯一の方法は、ソース管理とタグを使用することです。 SageMaker AI が提供するデフォルトのプロジェクトテンプレートをMLOps練習の開始点として使用できます。

モデルをデプロイする CI/CD パイプラインを作成するときは、ビルドアーティファクトにビルド識別子、コードバージョンまたはコミット、データバージョンをタグ付けしてください。この手法は、デプロイの問題のトラブルシューティングに役立ちます。規制の厳しいフィールドで予測を行うモデルにもタグ付けが必要になる場合があります。ML モデルに関連する正確なデータ、コード、構築、チェック、承認を逆算して特定できるので、ガバナンスを大幅に改善できます。

CI/CD パイプラインのジョブの一部は、構築しているものに対してテストを実行することです。データユニットテストは、データが Feature Store によって取り込まれる前に行われることが予想されますが、パイプラインは引き続き特定のモデルの入力と出力に対してテストを実行し、主要なメトリクスをチェックする責任があります。このようなチェックの一例として、固定検証セットで新しいモデルを検証し、確立されたしきい値を使用してそのパフォーマンスが以前のモデルと類似していることを確認することが挙げられます。パフォーマンスが予想よりも大幅に低い場合、ビルドは失敗し、モデルは本番環境に移行しません。

CI/CD パイプラインの広範な使用はプルリクエストもサポートしているため、人為的ミスを防ぐのに役立ちます。プルリクエストを使用する場合、コードの変更はすべて、本番環境に移行する前に、少なくとも 1 人の他のチームメンバーによってレビューおよび承認される必要があります。プルリクエストは、ビジネスルールに準拠していないコードを特定し、チーム内で知識を広めるのにも役立ちます。

デプロイ戦略を選択する

MLOps デプロイ戦略にはblue/green, canary, shadow, and A/Bテストが含まれます。

Blue/Green

Blue/green deployments are very common in software development. In this mode, two systems are kept running during development: blue is the old environment (in this case, the model that is being replaced) and green is the newly released model that is going to production. Changes can easily be rolled back with minimum downtime, because the old system is kept alive. For more in-depth information about blue/green のコンテキストでの デプロイについては SageMaker、 AWS Machine Learning ブログのブログ記事「 および を使用した Amazon SageMaker AI エンドポイントの安全なデプロイ AWS CodePipeline とモニタリング AWS CodeDeploy」を参照してください。

Canary

Canary デプロイはblue/green deployments in that both keep two models running together. However, in canary deployments, the new model is rolled out to users incrementally, until all traffic eventually shifts over to the new model. As in blue/greenデプロイに似ており、新しい (および潜在的に障害のある) モデルが最初のロールアウト中に注意深くモニタリングされ、問題が発生した場合にロールバックできるため、リスクは軽減されます。 SageMaker AI では、 InitialVariantWeight を使用して初期トラフィック分散を指定できますAPI。

シャドウ

シャドウデプロイを使用して、モデルを本番環境に安全に導入できます。このモードでは、新しいモデルは古いモデルやビジネスプロセスと連動し、決定に影響を与えることなく推論を実行します。このモードは、モデルを本番環境に昇格させる前の最終チェックや忠実度の高い実験に役立ちます。

シャドウモードは、ユーザーの推論フィードバックを必要としない場合に便利です。エラー分析を実行し、新しいモデルを古いモデルと比較することで、予測の品質を評価できます。また、出力分布をモニタリングして、期待どおりに動作することを確認できます。 SageMaker AI でシャドウデプロイを行う方法については、 AWS Machine Learning ブログのブログ記事「Amazon SageMaker AI でシャドウ ML モデルをデプロイする」を参照してください。

A/B テスト

ML 実務者が環境でモデルを開発する場合、最適化するメトリクスは、重要なビジネスメトリクスのプロキシであることがよくあります。これにより、新しいモデルが収益やクリックスルー率などのビジネス成果を実際に改善するかどうかを判別し、ユーザーからの苦情の数を減らすことが難しくなります。

ビジネス目標ができるだけ多くの製品を販売することである e コマースウェブサイトの場合を考えてみましょう。レビューチームは、売上と顧客満足度が情報に基づいた正確なレビューと直接相関していることを知っています。チームメンバーは、売上を向上させるために新しいレビューランキングアルゴリズムを提案する場合があります。A/B テストを使用すると、古いアルゴリズムと新しいアルゴリズムを異なる類似するユーザーグループにロールアウトし、結果をモニタリングして、新しいモデルから予測を受け取ったユーザーが購入する可能性が高くなります。

A/B テストは、モデルの古さとドリフトによるビジネスへの影響を測定するのにも役立ちます。チームは、新しいモデルをある程度の繰り返しで本番環境に投入し、各モデルで A/B テストを実行し、経過時間とパフォーマンスのグラフを作成できます。これにより、チームは本番稼働用データのデータドリフトの変動を把握できます。

SageMaker AI で A/B テストを実行する方法の詳細については、 AWS Machine Learning ブログのブログ記事「Amazon SageMaker AI を使用して本番環境で ML モデルをテストする」を参照してください。

推論要件を検討する

SageMaker AI を使用すると、基盤となるインフラストラクチャを選択して、さまざまな方法でモデルをデプロイできます。これらの推論呼び出し機能は、さまざまなユースケースとコストプロファイルをサポートします。以下のセクションで説明するように、オプションにはリアルタイム推論、非同期推論、バッチ変換が含まれます。

リアルタイム推論

リアルタイム推論は、リアルタイム、インタラクティブ、低レイテンシーの要件がある推論ワークロードに最適です。AI SageMaker ホスティングサービスにモデルをデプロイし、推論に使用できるエンドポイントを取得できます。これらのエンドポイントはフルマネージド型で、自動スケーリングをサポートしており (「Amazon SageMaker AI モデルの自動スケーリング」を参照）、複数のアベイラビリティーゾーンにデプロイできます。

Apache MXNet、 PyTorch、または で構築された深層学習モデルがある場合は TensorFlow、Amazon SageMaker AI Elastic Inference (EI) を使用することもできます。EI を使用すると、任意の SageMaker AI インスタンスGPUsに小数をアタッチして推論を高速化できます。クライアントインスタンスを選択してアプリケーションを実行し、EI アクセラレーターをアタッチして、推論ニーズに適切なGPU加速度を使用できます。

もう 1 つのオプションは、マルチモデルエンドポイントを使用することです。これは、多数のモデルをデプロイするためのスケーラブルで費用対効果の高いソリューションを提供します。これらのエンドポイントは、複数のモデルをホストするために有効になっている共有サービングコンテナを使用します。マルチモデルエンドポイントは、単一モデルエンドポイントの使用と比較してエンドポイントの使用率を向上させることで、ホスティングコストを削減します。また、 SageMaker AI がメモリへのモデルのロードとトラフィックパターンに基づくスケーリングを管理するため、デプロイのオーバーヘッドも削減されます。

AI に ML モデルをデプロイするためのその他のベストプラクティスについては、 SageMaker AI ドキュメントの「デプロイのベストプラクティス SageMaker 」を参照してください。

非同期推論

Amazon SageMaker AI 非同期推論は、受信リクエストをキューに入れ、非同期的に処理する SageMaker AI の機能です。このオプションは、最大 1 GB の大きなペイロードサイズ、長い処理時間、ほぼリアルタイムのレイテンシー要件を持つリクエストに最適です。非同期推論を使用すると、処理するリクエストがない場合にインスタンス数を自動的にゼロにスケーリングすることでコストを節約できるため、エンドポイントがリクエストを処理している場合にのみ料金が発生します。

バッチ変換

以下を実行する場合は、バッチ変換を使用します。

• データセットを前処理して、トレーニングや推論を妨げるノイズやバイアスをデータセットから取り除く場合。

• 大規模なデータセットから推論を取得する場合。

• 永続的なエンドポイントが不要なときに推論を実行する場合。

• 入力レコードを推論に関連付けて結果の解釈に役立てる場合。