はじめに
アドテク業界のインフラエンジニアとして、機械学習基盤をお世話をしている中で、アーキテクチャ改善を提案したので、せっかくなのでその内容を紹介したいと思います。
アーキテクチャ
まずは改善前後のアーキテクチャの紹介です。
旧アーキテクチャと問題点
-
商用環境
- 学習: パラメータ・結果の一元管理ができていなかった (Argoのログで結果を確認する必要があった)
- 評価: MLPipelineに含まれておらず、ローカル上にて手動実行していた
- コードの更新: 手動でImageのビルドを実行＆bitbucketに保存する必要があった
-
実験環境
- 実験環境がなく、ローカル上にて手動実行していた
- パラメータ・結果の管理の一元管理ができていなかった
旧アーキテクチャは、評価のプロセスが手動であることなどから、Googleが出しているMLOps成熟度モデルの下記3レベルの内、レベル0の状態でした。（今回は推論のプロセスは省き、学習・評価のみを対象をしています）
レベル0：MLモデルのビルドとデプロイのプロセスが完全に手動
レベル1：MLパイプラインを自動化することにより、モデルの継続的トレーニングを実行する
レベル2：自動CI/CDシステムにより、本番環境でパイプラインを迅速かつ確実に更新する
また、パラメータ・結果の管理が属人化してしまっていました。それにより、モデル開発を気軽にできる環境がなかった、また組織としてのモデル開発が難しい状況でした。
パラメータ・結果の管理が属人化している(=自動化できていない、徹底できていない)ことは、モデルの開発のみならず商用運用にも影響を受けてしまうことが想定されます。
例えば、納得のいくモデル開発はできたが実験記録が適切に行えておらず、異なる環境でエラーが発生して動作しない、また想定していた精度が出ないといった再現性が失われることが考えられます。そのため、MLOpsにおいて、「実験管理」もまた重要なテーマになっています。
(「Amazon SageMakerによる実験管理について解説する動画を公開しました！」参照)
新アーキテクチャと改善点
- 商用環境
- 学習: EMR＆Argo→ Sagemakerに移行、SagemakerExperimentによるパラメータ・結果の一元管理ができるように
- 評価: 学習同様、Sagemakerを使ったPipelineを追加
- コードの更新: Bitbucketへのpushをトリガーとして、Imageのビルドを自動実行
- 実行結果の通知: Slackでモデルの精度・feature importanceを毎日通知
- 実験環境
- Sagemakerで学習・評価の実験をし、SagemakerExperimentによるパラメータ・結果の一元管理ができるように
結果として、MLPipelineの自動化も実現し、Googleが出しているMLOps成熟度モデルの下記3レベルの内、レベル0→1に上げることができました。
レベル0：MLモデルのビルドとデプロイのプロセスが完全に手動
レベル1：MLパイプラインを自動化することにより、モデルの継続的トレーニングを実行する
レベル2：自動CI/CDシステムにより、本番環境でパイプラインを迅速かつ確実に更新する
また、パラメータ・結果の管理を自動化したことで、組織としてのモデル開発を気軽に行えるようになりました。
他にも、細々とした部分の運用改善ができたかなと思います。
次回は、下記ポイントも改善できたらいいなと思っています。
- 推論のプロセスも含んだMLPipeline
- モデルのA/Bテスト
- 複数のモデルを比較し、より精度のたかい方を商用デプロイし、推論
- モデルのバージョン管理
- SagemakerModelRegistryの導入
- モデルのデプロイ・予測のパフォーマンスの監視
- SageMaker Model Monitor・SageMaker Clarifyなどの導入
おわりに
第二回では、MLPipeline構築におけるリソースについて、概要や使い方、APIまわりなどをまとめていこうと思います。