翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# デプロイ
ソフトウェアエンジニアリングでは、コードが予期せず動作したり、予期しないユーザーの動作によってソフトウェアが破損したり、予期しないエッジケースが見つかったりする可能性があるため、コードを本番環境に配置するにはデューデリジェンスが必要です。ソフトウェアエンジニアと DevOps エンジニアは通常、ユニットテストとロールバック戦略を使用して、これらのリスクを軽減します。ML では、実際の環境がドリフトすることが予想されるため、モデルを本番環境に配置するにはさらに計画が必要です。多くの場合、モデルは改善しようとしている実際のビジネスメトリクスのプロキシであるメトリクスで検証されます。
これらの課題に対処するには、このセクションのベストプラクティスに従ってください。
**Topics**
+ [デプロイサイクルを自動化する](#automation)
+ [デプロイ戦略を選択する](#deployment-strategy)
+ [推論要件を検討する](#inference)
## デプロイサイクルを自動化する
ヒューマンエラーを防ぎ、ビルドチェックが一貫して実行されるように、トレーニングとデプロイのプロセスを完全に自動化する必要があります。ユーザーには、本番環境への書き込みアクセス許可があってはなりません。
[Amazon SageMaker AI Pipelines](https://aws.amazon.com/sagemaker/pipelines/) と は、ML プロジェクトの CI/CD パイプラインの作成[AWS CodePipeline](https://aws.amazon.com/codepipeline/)に役立ちます。CI/CD パイプラインを使用する利点の 1 つは、データの取り込み、モデルのトレーニング、モニタリングの実行に使用されるすべてのコードが、[Git](https://git-scm.com/) などのツールを使用してバージョン管理できることです。場合によっては、同じアルゴリズムとハイパーパラメータを使用してモデルを再トレーニングする必要がありますが、データは異なります。正しいバージョンのアルゴリズムを使用していることを確認する唯一の方法は、ソースコントロールとタグを使用することです。SageMaker AI が提供する[デフォルトのプロジェクトテンプレート](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-projects-templates-sm.html)を MLOps プラクティスの開始点として使用できます。
モデルをデプロイする CI/CD パイプラインを作成するときは、ビルドアーティファクトにビルド識別子、コードバージョンまたはコミット、データバージョンをタグ付けしてください。この手法は、デプロイの問題のトラブルシューティングに役立ちます。また、規制の厳しいフィールドで予測を行うモデルにもタグ付けが必要になることがあります。ML モデルに関連する正確なデータ、コード、ビルド、チェック、承認を逆算して特定できるので、ガバナンスを大幅に改善できます。
CI/CD パイプラインのジョブの一部は、構築しているものに対してテストを実行することです。データユニットテストは、データが特徴量ストアによって取り込まれる前に行われることが予想されますが、パイプラインは引き続き特定のモデルの入力と出力に対してテストを実行し、主要なメトリクスをチェックする責任があります。このようなチェックの一例としては、固定検証セットで新しいモデルを検証し、確立されたしきい値を使用してそのパフォーマンスが以前のモデルと類似していることを確認することがあります。パフォーマンスが予想よりも大幅に低い場合、ビルドは失敗し、モデルは本番環境に移行しません。
CI/CD パイプラインの広範な使用はプルリクエストもサポートしているため、人為的ミスを防ぐのに役立ちます。プルリクエストを使用する場合、コードの変更はすべて、本番環境に移行する前に、少なくとも 1 人の他のチームメンバーによってレビューおよび承認される必要があります。プルリクエストは、ビジネスルールに準拠していないコードを特定し、チーム内で知識を広めるのにも役立ちます。
## デプロイ戦略を選択する
MLOps デプロイ戦略には、ブルー/グリーン、カナリア、シャドウ、A/B テストが含まれます。
### Blue/Green
ブルー/グリーンデプロイは、ソフトウェア開発で非常に一般的です。このモードでは、開発中も 2 つのシステムが実行され続けます。ブルーは古い環境 (この場合は置き換えられるモデル) で、グリーンは本番環境に向かう新しくリリースされたモデルです。古いシステムは稼働状態であるため、変更は最小限のダウンタイムで簡単にロールバックできます。SageMaker のコンテキストにおける Blue/Green デプロイの詳細については、 AWS Machine Learning ブログのブログ記事「 [AWS CodePipeline と を使用して Amazon SageMaker AI エンドポイントを安全にデプロイおよびモニタリング AWS CodeDeploy](https://aws.amazon.com/blogs/machine-learning/safely-deploying-and-monitoring-amazon-sagemaker-endpoints-with-aws-codepipeline-and-aws-codedeploy/)する」を参照してください。
### Canary
Canary デプロイは、2 つのモデルを一緒に実行し続けるという点で Blue/Green デプロイに似ています。ただし、Canary デプロイでは、すべてのトラフィックが最終的に新しいモデルに移行するまで、新しいモデルがユーザーに段階的にロールアウトされます。ブルー/グリーンデプロイと同様に、新しい (および潜在的に障害のある) モデルは最初のロールアウト中に注意深くモニタリングされ、問題が発生した場合にロールバックできるため、リスクは軽減されます。SageMaker AI では、[InitialVariantWeight](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sagemaker-endpointconfig-productionvariant.html) API を使用して初期トラフィック分散を指定できます。
### シャドウ
シャドウデプロイを使用して、モデルを本番環境に安全に導入できます。このモードでは、新しいモデルは古いモデルやビジネスプロセスと連携して動作し、決定に影響を与えることなく推論を実行します。このモードは、モデルを本番環境に昇格させる前の最終チェックやより高い忠実度実験に役立ちます。
シャドウモードは、ユーザーの推論フィードバックを必要としない場合に便利です。エラー分析を実行し、新しいモデルを古いモデルと比較することで予測の品質を評価できます。また、出力分布をモニタリングして、期待どおりに動作することを確認できます。SageMaker AI でシャドウデプロイを行う方法については、 AWS Machine Learning ブログのブログ記事「[Deploy shadow ML models in Amazon SageMaker AI](https://aws.amazon.com/blogs/machine-learning/deploy-shadow-ml-models-in-amazon-sagemaker/)」を参照してください。
### A/B テスト
ML 実務者が環境でモデルを開発する場合、最適化するメトリクスは、重要なビジネスメトリクスのプロキシであることがよくあります。これにより、新しいモデルが収益やクリックスルー率などのビジネス成果を実際に向上させ、ユーザーからの苦情の数を減らすかどうかを判断するのが困難になります。
ビジネス目標ができるだけ多くの製品を販売することである e コマースウェブサイトの場合を考えてみましょう。レビューチームは、売上と顧客満足度が情報に基づいた正確なレビューと直接相関していることを知っています。チームメンバーは、売上を改善するために新しいレビューランキングアルゴリズムを提案する場合があります。A/B テストを使用すると、古いアルゴリズムと新しいアルゴリズムを異なる類似しているユーザーグループにロールアウトし、結果をモニタリングして、新しいモデルから予測を受け取ったユーザーが購入する可能性が高くなります。
A/B テストは、モデルの古さとドリフトによるビジネスへの影響を測定するのにも役立ちます。チームは、新しいモデルをある程度の繰り返しで本番環境に投入し、各モデルで A/B テストを実行し、経過時間とパフォーマンスのグラフを作成できます。これにより、チームは本番稼働用データのデータドリフトの変動を把握できます。
SageMaker AI で A/B テストを実行する方法の詳細については、 AWS Machine Learning ブログのブログ記事[Amazon SageMaker AI を使用して本番環境で ML モデルをテスト](https://aws.amazon.com/blogs/machine-learning/a-b-testing-ml-models-in-production-using-amazon-sagemaker/)する」を参照してください。
## 推論要件を検討する
SageMaker AI を使用すると、基盤となるインフラストラクチャを選択して、さまざまな方法でモデルをデプロイできます。これらの推論呼び出し機能は、さまざまなユースケースとコストプロファイルをサポートします。オプションには、次のセクションで説明するように、リアルタイム推論、非同期推論、バッチ変換が含まれます。
### リアルタイム推論
[リアルタイム推論](https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints.html)は、リアルタイム、インタラクティブ、低レイテンシーの要件がある推論ワークロードに最適です。SageMaker AI ホスティングサービスにモデルをデプロイし、推論に使用できるエンドポイントを取得できます。これらのエンドポイントはフルマネージド型で、自動スケーリングをサポートしており ([Amazon SageMaker AI モデルを自動的にスケーリング](https://docs.aws.amazon.com/sagemaker/latest/dg/endpoint-auto-scaling.html)する[」を参照）、複数のアベイラビリティーゾーン](https://docs.aws.amazon.com/sagemaker/latest/dg/instance-types-az.html)にデプロイできます。
Apache MXNet、PyTorch、または TensorFlow で構築された深層学習モデルがある場合は、[Amazon SageMaker AI Elastic Inference (EI)](https://docs.aws.amazon.com/sagemaker/latest/dg/ei.html) を使用することもできます。EI を使用すると、任意の SageMaker AI インスタンスに小数 GPUs をアタッチして推論を高速化できます。クライアントインスタンスを選択してアプリケーションを実行し、EI アクセラレーターをアタッチして、推論のニーズに合わせて適切な量の GPU アクセラレーションを使用できます。
もう 1 つのオプションは、多数のモデルをデプロイするためのスケーラブルで費用対効果の高いソリューションを提供する[マルチモデルエンドポイント](https://docs.aws.amazon.com/sagemaker/latest/dg/multi-model-endpoints.html)を使用することです。これらのエンドポイントは、複数のモデルをホストするために有効になっている共有サービングコンテナを使用します。マルチモデルエンドポイントは、単一モデルエンドポイントの使用と比較してエンドポイントの使用率を向上させることで、ホスティングコストを削減します。また、SageMaker AI がメモリへのモデルのロードとトラフィックパターンに基づくスケーリングを管理するため、デプロイのオーバーヘッドも削減されます。
SageMaker AI に ML モデルをデプロイするためのその他のベストプラクティスについては、SageMaker AI ドキュメントの[「デプロイのベストプラクティス](https://docs.aws.amazon.com/sagemaker/latest/dg/best-practices.html)」を参照してください。
### 非同期推論
[Amazon SageMaker AI 非同期推論](https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference.html)は、受信リクエストをキューに入れ、非同期的に処理する SageMaker AI の機能です。このオプションは、最大 1 GB の大きなペイロードサイズ、長い処理時間、ほぼリアルタイムのレイテンシー要件を持つリクエストに最適です。非同期推論を使用すると、処理するリクエストがない場合にインスタンス数を自動的にゼロにスケーリングすることでコストを節約できるため、エンドポイントがリクエストを処理している場合にのみ料金が発生します。
### バッチ変換
以下を実行する場合は、[バッチ変換](https://docs.aws.amazon.com/sagemaker/latest/dg/batch-transform.html)を使用します。
+ データセットを前処理して、トレーニングや推論を妨げるノイズやバイアスをデータセットから取り除く場合。
+ 大規模なデータセットから推論を取得する場合。
+ 永続的なエンドポイントが不要なときに推論を実行する場合。
+ 入力レコードを推論に関連付けて結果の解釈に役立てる場合。