【ML初心者アドベントカレンダー】MLワークフローのデプロイについて


# この記事の目的

MLワークフローのデプロイについて学ぶ


# デプロイのベストプラクティスとは

モデルのデプロイを安全かつ効率的に進めるため、以下のような観点や手法が存在する。


## 1. モデルのバージョニング

モデルを更新するたび異なるバージョンで管理し、特定のバージョンに戻れる（ロールバックできる）ようにしておく。

Amazon SageMaker Model Registry を使用するとモデルのバージョン管理がおこなえる。

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/model-registry.html


## 2. ロールバック戦略

モデルに何らかの不具合が発生した場合に、以前の安定して稼働していたバージョンへ戻す。

### ブルーグリーンデプロイ

* 新しいモデルを本番とは別の環境(グリーン)にデプロイする
*  グリーン環境でのモデルの動作を確認後、本番環境（ブルー）宛のトラフィックを徐々にグリーン環境へ移行する
*  最中で問題が発生すれば、すぐにブルー環境へ戻す


## 3. 継続的デプロイ

モデルの改善や変更を継続的に反映し、ユーザーが常に最新の状態でシステムを使用できるようにする。

https://ja.wikipedia.org/wiki/%E7%B6%99%E7%B6%9A%E7%9A%84%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4

### カナリアリリース

* 既存トラフィックのごく一部を新しいモデルにルーティングする
* モニタリング後、トラフィックを段階的に増やす
* ブルーグリーンデプロイとの違いは、モデルのモニタリングを行う工程が存在すること

### A/B テスト

* 複数のモデルバージョンを並行してデプロイする
* その中のうち、最もパフォーマンスが優れているモデルを選択して本番環境に適用する


## 4. モニタリングとアラート

本番環境でモデルの動作を監視し、異常があればすぐに対応する。


**CloudWatchで確認できるSageMakerのログ**

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/logging-cloudwatch.html

**CloudWatchで確認できるSageMakerのメトリクス**

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/monitoring-cloudwatch.html

**SageMaker Model Monitor**

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/model-monitor.html


モデルの品質をモニタリングする場合はSageMaker Model Monitorを使用する。
アラームの設定はどちらもできる。

## 5. デプロイの自動化

デプロイを自動化することで、手動作業によるミスやエラーを減らし、安定したデプロイプロセスを実行する。


**AWS CodePipeline**

https://aws.amazon.com/jp/codepipeline/


**AWS CloudFormation**

https://aws.amazon.com/jp/cloudformation/



## 6. セキュリティとコンプライアンス

効率的なデプロイプロセスが安全かつ規制を遵守していることを保証する。

* IAM ロールの使用
  * ユーザーやモデルに最小限の権限を付与する
* セキュアな通信
  * VPC エンドポイント等を使用してリソース同士の接続を保護する
* ログの確認
  * AWS CloudTrail を使用して変更履歴等の証跡を残す


# AWS で利用できるデプロイサービス

AWS で利用できるデプロイサービスは主に以下の通り。

## 1. Amazon SageMaker

言わずと知れた機械学習（ML）モデルのトレーニング、デプロイ、運用を一貫して行えるフルマネージドサービス。機械学習モデルの本番デプロイをするならもうこれだ。

https://aws.amazon.com/jp/sagemaker/




## 2. AWS Elastic Beanstalk

ウェブアプリケーションや API のデプロイを自動化するフルマネージドサービス。
インフラの管理を行うことなく、コードを書くだけでアプリが開発できる。スケーリングも可能。中～大規模なタスク向け。

https://aws.amazon.com/jp/elasticbeanstalk/


## 3. AWS Lambda

イベント発生時にコードを実行するサーバーレスサービス。自分でサーバーの用意をする必要がなく、スケーリングも自動で行える。小規模なタスク向け。

https://aws.amazon.com/jp/lambda/


## 4. AWS App Runner

コンテナ化されたウェブアプリケーションや API をデプロイするマネージドサービス。コンテナイメージまたはコードリポジトリ（Gitとか）を指定するだけで自動デプロイが行える。大規模アプリ向け。

https://aws.amazon.com/jp/apprunner/

https://docs.aws.amazon.com/ja_jp/apprunner/latest/dg/what-is-apprunner.html


## 5. Amazon ECS / EKS

コンテナベースのワークロードをデプロイするためのサービス、ふたつ。

### ECS (Elastic Container Service)

以下三つのオプションが存在する。

* Amazon EC2 instances
  * インスタンスタイプとインスタンス数を選択し、クラスターとしてキャパシティを管理する
* サーバーレス(AWS Fargate)
  * サーバーレスの従量制料金計算エンジン Fargate を使用する
* オンプレミス仮想マシン (VM) またはサーバー
  * Amazon ECS Anywhere を用いて外部のインスタンスを Amazon ECS クラスターに登録する

https://aws.amazon.com/jp/ecs/

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html

### EKS (Elastic Kubernetes Service)

Kubernetes ワークロードを AWS 上で管理、実行、スケールするためのサービス。コンテナ化された ML モデルやアプリケーションのデプロイなどに利用できる。

> Inferentia を含む最新の Amazon Elastic Compute Cloud (EC2) の GPU 搭載インスタンスを使用して分散トレーニングジョブを効率的に実行し、Kubeflow を使用してトレーニングと推論をデプロイします。

https://aws.amazon.com/jp/eks/

## 6. AWS CloudFormation

インフラをコードとして管理し、アプリケーションデプロイを自動化するサービス。スタックを使用して複数リソースを一括で管理できる。開発、テスト、本番など各環境で一貫性のあるデプロイをしたい場合や、複雑なインフラの管理をする場合などにおすすめ。


## 7. Amazon API Gateway

RESTful API や WebSocket API を作成、公開、モニタリングするフルマネージドサービス。

https://aws.amazon.com/jp/api-gateway/



## 8. AWS CodeDeploy

アプリケーションデプロイの自動化をサポートするサービス。CodePipeline と連携して CI/CD パイプラインの一部として利用できる。ブルーグリーンデプロイ等もサポートしているため、継続的デプロイの自動化に最適。

https://aws.amazon.com/jp/codedeploy/


## まとめ

* SageMaker
  * 機械学習といえばこれ。モデルのデプロイとモニタリングをしたい場合
* Elastic Beanstalk
  * インフラなど面倒なことは考えずアプリケーションを迅速にデプロイしたい場合
* Lambda
  * サーバーレスかつ軽量なデプロイが必要な場合
* ECS/EKS
  * **コンテナベース**のアプリケーションをデプロイする場合
* API Gateway
  * モデル推論用の API を構築する場合とか


実際どうやって使うのか？については以下のブログが大変参考になりました。

https://aws.amazon.com/jp/blogs/news/deploying-machine-learning-models-as-serverless-apis/


# SageMaker のエンドポイントについて

デプロイをするにあたり、エンドポイントの選定も大切な役割を持っています。
以下に SageMaker のエンドポイントとその要件についてまとめます。


## サーバーレスエンドポイント

オンデマンドで自動的にスケールする推論エンドポイント。プロビジョニングやスケーリングを管理する必要がなく、リクエストに応じてリソースが自動的に割り当てられ、コスト効率が良い。

> 他の SageMaker リアルタイムエンドポイントとは異なり、Serverless Inference はコンピューティングリソースを管理するため、複雑さが軽減されるため、インフラストラクチャの管理ではなく ML モデルに集中できます。次のガイドでは、エンドポイントの作成、呼び出し、更新、説明、または削除の方法といった、サーバーレスエンドポイントの主な機能について説明します。 SageMaker コンソール、 AWS SDKs、Amazon SageMaker Python SDK、または を使用して AWS CLI 、サーバーレスエンドポイントを管理できます。

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/serverless-endpoints-create-invoke-update-delete.html

## リアルタイムエンドポイント

リアルタイムかつ低レイテンシーの要件がある際に使用できるエンドポイント。

> リアルタイム推論は、リアルタイム、インタラクティブ、低レイテンシーの要件がある推論ワークロードに最適です。モデルを SageMaker ホスティングサービスにデプロイし、推論に使用できるエンドポイントを取得できます。これらのエンドポイントはフルマネージドで、オートスケーリングをサポートします

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/realtime-endpoints.html

## 非同期エンドポイント

リクエストを受け取ってから結果を非同期で返すエンドポイント。別にリアルタイムじゃなくて良いよ～というときに最適。大規模なデータを処理するときにも向いている。

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

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/async-inference.html

## バッチ推論

リアルタイムとは対照的に、ある程度のまとまったデータを用意してからそれを処理する。大量のデータや、一日に二回だけ動かすとか、定期的な推論に最適。

> バッチ推論はオフライン推論とも呼ばれ、複数の観測値に基づいてモデル予測を生成します。バッチ推論は、データセットが大きい場合や、モデル予測のリクエストにすぐに応答する必要がない場合に適しています。

https://docs.aws.amazon.com/ja_jp/sagemaker/latest/dg/autopilot-deploy-models-batch.html

## まとめ

| エンドポイントタイプ | 概要	|ユースケース |
|---|---|---|
|サーバーレスエンドポイント|トラフィックに応じて自動スケーリング。オンデマンドで実行。比較的低コスト|トラフィックが莫大ではないリアルタイム推論|
|リアルタイムエンドポイント|低レイテンシで推論結果を即時返す。ずっと稼働状態なので高コストになりがち|チャットボットなど|
|非同期エンドポイント|リクエストを受け付け、後で結果を返す、時間がかかることが予想される推論や、リアルタイムじゃなくても良い場合|大量の画像セットなど大規模データの処理|
|バッチ推論|大量データをまとめてスケジューリングしたタイミングで一括処理する|大規模なデータセットに対する推論|