![[レポート] ML Ops on AWS #AWSSummit](https://devio2023-media.developers.io/wp-content/uploads/2018/04/400x400.png)
[レポート] ML Ops on AWS #AWSSummit
本日 5/30 から 6/1 まで、東京・品川で開催されています AWS Summit Tokyo 2018。こちらで講演されたセッション「ML Ops on AWS」を聴講しましたのでレポートします。
今回のAWS Summitでは全セッションで撮影が禁止されているため、文字だけでお届けします。
概要
機械学習を実システム上で運用してビジネス上の成果を出すためには、単に精度の良い機械学習モデルを学習させるよりもはるかに多くの点を考慮する必要があ ります。例えば、プロダクション環境にいれたモデルの精度評価を行い、継続的にモデル自体を改善していくことが求められたり、また複数のチームが協調して 作業をする必要もあります。このセッションでは、AWS 上で機械学習システムを構築・運用する際のベストプラクティスについてご説明します。
スピーカー
- アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
- 志村 誠
（※敬称略）
レポート
Key Take Away
- MLは継続的な改善サイクル
- 新しいデータ、新しいアルゴリズム、新しいパラメーターを試し続ける必要がある
- 自動化、自動化、自動化！
- 人の手による暖かい運用を排除。AWSにはそのための道具が揃っている
- 全ての要素を集計して管理
- モデルの結果を集計し、かつさまざまなコンポーネントを管理
アジェンダ
- MLシステムを取り巻く改善サイクル
- MLシステムの内側の改善サイクル
- 改善サイクルを回すための考え方とツール
- MLシステムのアーキテクチャ
MLシステムを取り巻く改善サイクル
MLをシステムに組み込もうとすると、素直に考えると、次のようなフローとなる。
- ビジネス課題
- データ収集
- データの加工整形
- データの分析・可視化
- ML
- アプリケーションシステム
MLを本番で動かす前に知っておくべきこと
- まずは解決したいビジネス課題から出発する
- MLのモデルを構築するためには、良質のデータがすでに準備されている必要がある
- MLモデルは一度作って終わりでは決してない
- 新しい施策を行うことにより、既存のモデルではカバーできない部分が出てくる
- 市場の状況が変化することにより、同じモデルの精度も徐々に低下していく
- 新しいビジネス課題が出てきたときに、新しいサイクルを高速に行えるようにしていく必要がある
それらを踏まえると、MLシステムのサイクルは一方向ではなく、アプリケーションシステム（6）からデータ収集（2）や加工整形（3）、あるいはアプリケーションシステムとML（6）を繰り返す必要がある。
いかに早く安定してループを回せるか、データレイクと環境整備が必須。でないと予測結果が正しいかすら不明。
MLシステムの内側の改善サイクル
MLにスポットを当てる。ここは次のようなフローが考えられる。
- 開発
- 学習
- 推論
開発
- 開発したいMLモデルにより、異なる開発環境が必要。またフレームワークのアップデートなどに伴い、開発環境自体の更新や作り直しも頻発に発生
- そのため、開発環境の構築プロセスを自動化できる必要がある
- また、構築済みのデータレイクから必要なデータを抜き出して加工し、学習用のデータセットを作る必要もある
学習
- ひとつのモデルだけではなく、複数のモデルを学習させて、精度を比較する。また同じモデルでも、ハイパーパラメータだけ変えて回し直し、最適な値を探索する
- またモデルは変えなくても、新しいデータが追加された際に再学習を行うこともよくある
- こうした繰り返しの学習プロセスを、最小限の時間コスト、開発コストで効率よく行える必要がある
推論と再学習
- 学習した結果をデプロイして、結果をモニタリング、基本的にはABテストを行って、精度が上がっていなければロールバックすることも
- 同じモデルでも、データの追加に伴ってデプロイし直すことがよくあるので、デプロイプロセスも自動化
- 結果が悪ければモデルの再学習や、新しい手法を試すために開発環境の再構築に戻ることも
以上からMLのフローは、学習（2）を繰り返し行う、または推論（3）から開発（1）や学習（2）に戻ることになる。
改善サイクルを回すための考え方とツール
- MLのサイクルにおける典型的な悩み
- 開発環境と本番環境でライブラリが違う
- 開発環境と本番環境で実行環境自体がまるで違う
- 新しいモデルを作ってもすぐにデプロイできない
- あるサービスのモデルのデプロイが他サービスに影響
- 一度学習したモデルを再現できない
- 新しいモデルをデプロイしたら悲惨な予測を返すように
DevOpsにおけるキーとなる考え方とMLサイクル
- Infrastructure as Code
- 自動化、バージョン管理、テスト、継続的インテグレーションなどをシステム管理に応用するアプローチ。すべてが管理下にあるので、immutableな状態にシステムを保つことが可能
- MLで使うライブラリは複雑な依存関係を保ちやすい。開発と本番で同じ環境を保たないと、モデルが想定通りに動作しない。またライブラリのバージョンが頻繁に変わるので、毎回新しい環境を構築する方が確実
- Microservices
- アーキテクチャスタイルのひとつであり、小さなサービスの組み合わせにより単一のシステムを開発するアプローチ
- アプリケ0ション全体の中で、MLモデルの部分は他コンポーネントとプロダクトの更新サイクルや必要とされる言語・環境なども異なることが多い
- Continuous Delivery
- 自動化されたリソースプロセスを通じて、新しいバージョンの仕組みをデプロイでき、ビジネス上の価値を提供する
- 新しいモデルが実際に良い成果を上げるかどうかは、実際に本番環境にいれてみないとわからない。想定外の結果になることもままある
通常のDevOpsとML Opsで異なる点
- 開発環境において、複数のモデルおよびパラメーターを並列で回して比較を行う、というプロセスの存在
- バージョン管理をする際に、コードや環境だけではなく、学習データも合わせて管理をする必要がある。さらにいうなら学習データを他のモデルでも再利用したい
- データ整備、モデル構築、アプリ開発・運用、そしてビジネスと複数チームが協働する形になることが多い
- 本番環境で複数モデルのABテストを実施するのが一般的なやり方で、複数モデルを一度にデプロイできる必要がある
ML Opsにおけるアプローチ
- Infrastructure as Code
- MLモデルのコードや学習ジョブ実行時のパラメーター、実行環境の構成などは全てバージョン管理。実行した学習ジョブ自体も管理。またデータもDWHなどから取得するクエリや、データ自体もタグをつけて統一的に管理
- Amazon ECR、AWS CodeBuild、AWS CodeCommitを利用
- Microservices
- MLの推論処理をマイクロサービスとして独立させる。ML部分のチームとアプリケーションのチームを別にし、各々が好きなタイミングでリリース
- Amazon SageMaker、Amazon ECSを利用
- Continuous Delivery
- 常に成果を集計する仕組みにしておき、ABテストを常に走らせる形で少しずつ変更していく。ビジネスに問題が起こったらすぐ切り戻し
- Amazon SageMaker、AWS Step Functions、AWS Greengrassを利用
Amazon SageMakerを利用することで、データサイエンティストやMLエンジニアが、機械学習のサイクルを高速に回すことができる。
MLシステムのアーキテクチャ
- サーバーサイドのリアルタイム推論
- ユーザーの属性や行動履歴に応じた、リアルタイムのコンテンツ推薦
- Firehose、SageMaker、Glue、Athena、QuickSightなどを利用
- エッジサイドのリアルタイム推論
- 工場の生産ラインにカメラを設置し、撮影した画像から不良品を判定
- Greengrass、IoT、SageMaker、Glue、Athena、QuickSightなどを利用
MLサイクルのオートメーション
- Step FunctionsによるMLモデル更新の自動化
- Step Functionsを中心に、CodeBuild、SageMaker、Greengrass、SMSなどを組み合わせる
- データ加工部分も含めてStep Functionsで管理
- RDSやS#、RedshiftなどのデータをGlueで加工
- 複数のMLモデル学習時の精度評価
- SageMaker、CloudWatch Logs、Lambdaなどを連携させ、QuickSightで比較
- 本番環境でのABテストと効果測定
- SageMakerで作ったモデルを使い、アウトプットをKinesisに流し、Elasticsearch Serviceでリアルタイム可視化
- 同様にS3にも保存し、AthenaとQuickSightで長期的なトレンドを集計して可視化
- クラウド／オンプレのハイブリッド
- SageMakerで作ったモデルをDirect Connectでオンプレ環境へ。アウトプットも同様にDirect ConnectでS3に保存、SageMakerで再学習
まとめ
- MLは継続的な改善サイクル
- 新しいデータ、新しいアルゴリズム、新しいパラメーターを試し続ける必要がある
- 自動化、自動化、自動化！
- 人の手による暖かい運用を排除。AWSにはそのための道具が揃っている
- 全ての要素を集計して管理
- モデルの結果を集計し、かつさまざまなコンポーネントを管理
最後に
いかがだったでしょうか。DevOpsの考えは、セキュリティも取り込んだDevSecOps、MLにも適用したML Opsと幅広く応用されてきています。AWSのサービスを組み合わせることで、少ない手間で高度な環境を構築することができることがわかりました。私自身はMLを使い込んでいませんが、いざ取り組む際にはこういった考え方をしっかりと持っていきたいと思います。
現場からは以上です。
