実践Continuous Training - 第6回MLOps勉強会

第6回MLOps勉強会で発表した内容になります。

------
広告配信領域において、TFXとKubeflowによる学習パイプラインを構築した事例についてお話します。
具体的には学習処理を定期実行し、鮮度の高い学習済みモデルを本番にデプロイする構成についてお話します。
出来る限りMLOps周りに焦点をあて、事業ドメインや採用しているモデルに深入りせずお話出来ればと思います。

https://mlops.connpass.com/event/206228/

1. 実践 Continuous Training 2021/4/21 第6回 MLOps 勉強会 株式会社Alpha CTO Hitoshi Tsuyuki@htsh_tsyk
2. 目次 1. はじめに 2. 導入計画 3. 導入期 4. 改善期 5. おわりに
3. 目次 1. はじめに 2. 導入計画 3. 導入期 4. 改善期 5. おわりに
4. 1. はじめに Continuous Trainingとは(1) MLOps Continuous Training Hidden Technical Debt in Machine Learning Systemsより抜粋 MLOps: Continuous delivery and automation pipelines in machine learningより抜粋 GCPのベストプラクティス調査時に発見し、 MLOpsと比較し限定的な意味範囲がイメージしやすいため社内で多用している
5. 学習パイプライン 1. はじめに 学習パイプラインの実行~(間接的な)本番サービスへのデプロイまでの流れを自動化すること Continuous Trainingとは(2) データ 検証 前処理 学習 評価 モデル 検証 CD パフォーマンス監視 トリガー 本番 サービス 2. 実行する 3.呼び出す 4. デプロイする 5. ログを残す 6. 精度低下検知時 呼び出す 1. 実行する 1~6が自動的に周り続けるようにする 1~4までの流れをCTとして今回話す内容とする スケジュール
6. 1. はじめに 最新のデータでモデルを再学習する必要性の ある領域で有用 例) アプリが ML を使用してファッション関連商品をおすすめ している場合 → 最新のトレンドや商品に合わせておすすめ 商品を表示させる必要がある 逆にモデルの更新頻度が少ないような領域、例えば音声 データとか？、を扱っている場合はあまり必要無い？ 向いている領域 導入の利点 Continuous Trainingとは(3) 学習モデルの 鮮度の確保 関係者の 関心の分離 実験の 再現性確保 開発効率の 向上 学習モデルの鮮度が重要な領域では有用で、導入した際は様々な利点がある
7. 目次 1. はじめに 2. 導入計画 3. 導入期 4. 改善期 5. おわりに
8. 2. 導入計画 全体構成 パイプライン データ 抽出 学習 ビルド& push CD トリガー 本番 サービス 2. 実行する 3.呼び出す 4. デプロイする 1. 実行する スケジュール 4. 変更検知する
9. 2. 導入計画 導入時の要件とツールを整理する サーバ機能 推論サービス パイプライン デプロイ 要件(必須) 代表的なツール パイプライン定義 定期実行 推論サービスのデプロイが 出来ればなんでも などなど 要件(任意) リクエストの前処理 複数モデルの管理 複数バージョンの管理 ...など 中間成果物の管理 コンテナ対応 Dagの管理 Notebookからの呼び出し TensorFlow Serving 推論サービスのデプロイ
10. 2. 導入計画 弊社の技術選択 推論サービス パイプライン デプロイ ツール 選択理由 広告事業の特性上、低レイテンシーに応答かつ高負荷な状況でも安 定した性能を出せる必要があった。 また、モデルファイル (saved model)の可搬性、複数モデルの管理、 複数バージョンの管理が便利そうだったため 最後に、識者(shibui-san)に聞いてもおすすめとのことで背中を押されたため パイプライン定義はもちろん、手動・自動実行両対応 、コンポーネント 毎に個別のコンテナを使うことが出来る、アーティファクトを保存する ことが出来る、notebookから呼び出すことが出来る、ことなど 既存サービスがArgoCDによるGitOpsを採用していたため、新規に デプロイフローを確立する必要がないため。 その他の理由をあげるとすれば学習パイプラインの終端を Imageの Pushと出来わかりやすいため TensorFlow Serving
11. 2. 導入計画 学習パイプラインとCDの連携方法について 学習パイプラインのスコープを絞りスモールスタート、既存の CDと連携することで工数削減 パイプライン データ 抽出 学習 Build パイプラインのスコープ 既存のCD(GitOps) 1. Scan 2. Sync 3. Write back 最短で構成を整えるため必須コンポーネントに絞る TFX Pipeline(後述)の導入はスコープ外とする
12. 2. 導入計画 学習パイプラインとCDの連携方法について 学習パイプラインのスコープを絞り、既存の CDと連携することで工数削減 パイプライン データ 抽出 学習 Build & Push パイプラインのスコープ 既存のCD(GitOps) 1. Scan 2. Sync 3. Write back 最短で構成を整えるため必須コンポーネントに絞る TFX Pipeline(後述)の導入はスコープ外とする Push
13. 2. 導入計画 全体構成 パイプライン データ 抽出 学習 Build& push CD トリガー 本番 サービス 2. 実行する 3.呼び出す 4. デプロイする 1. 実行する スケジュール 4. 変更検知する
14. 目次 1. はじめに 2. 導入計画 3. 導入期 4. 改善期 5. おわりに
15. 3. 導入期 計画した構成で実際にCTを導入していく パイプライン データ 抽出 学習 Build& push CD トリガー 本番 サービス 2. 実行する 3.Pushする 4. デプロイする 1. 実行する スケジュール 4. 変更検知する
16. パイプライン 3. 導入期 パイプラインの処理内容 データ 抽出 学習 ビルド DWH 学習データ 学習データ モデルファイル image モデルファイル 処理内容 (イメージ) 処理内容 1. DWHからのデータ抽出/前処理 2. 前処理 3. 学習データへの加工 4. ストレージへの保存 1. 学習データの読み込み 2. 学習の実行 3. モデルファイルの出力 4. ストレージへの保存 1. モデルファイルの読み込み 2. docker imageのbuild 3. コンテナレジストリへの保存 in out in out in out
17. パイプライン 3. 導入期 実験の再現性の確保 データ 抽出 学習 ビルド 学習データ モデルファイル image 成果物 バージョン管理 {time} … WF実行時の時間 {model} … モデル名 成果物管理 gs://bucket/{model}/v{time}/ train.csv gs://bucket/{model}/v{time}/ model/* gcr.io/registry/{model}:v{time} Artifactに保存 Artifactに保存 Artifactに保存
18. 3. 導入期 ビルド方法について補足 パイプライン データ 抽出 学習 ビルド 0. KubeflowのContainerOpで Kanikoイメージを指定 1. モデルファイルの読み込み 2. Dockerから読み込めるパスに配 置 3. KanikoでBuild ステップ 導入当時のDockerfile
19. 3. 導入期 CT導入完了 パイプライン データ 抽出 学習 ビルド CD 本番 サービス 仕上げにトリガーを1回/1日とし、小さいパイプラインではあるが CTが動き始める。 1回/日 実行 ※Kubeflow Pipelineの recurring jobを設定 トリガー 1. 実行する スケジュール
20. 3. 導入期 CT導入後のモデル開発フローの変化について補足 パイプライン データ 抽出 学習 ビルド 開発環境 本番環境 DWH 実験評価 パイプライン データ 抽出 学習 ビルド 手動デプロイ データサインティスト の関心 Ops の関心 CD 本番 サービス パイプライン定義ファイルをコード管理、データサイエンティストと Opsの関心を分離 システム全体像 1 2 3 補足 1 2 3 コード管理する対象が Notebookからパイプライン定義 ファイルとなった データサイエンティストはモデ ルの変更を本番に反映する 場合、パイプライン定義ファイ ルを変更する Opsエンジニアは、パイプライ ン定義ファイルの変更を安全 に本番に反映する
21. 目次 1. はじめに 2. 導入計画 3. 導入期 4. 改善期 5. おわりに
22. 4. 改善期 CTにCDを適用する パイプライン データ 抽出 学習 ビルド 開発環境 本番環境 DWH パイプライン データ 抽出 学習 ビルド CD 本番 サービス CD パイプライン ファイル生成 アップロード 旧パイプライン 定期実行無効化 Github Actions 手動デプロイ 手動デプロイをCDに置き換える
23. 4. 改善期 学習パイプラインを拡充する ~ TFX(1) 1. コンポーネント単位での TFXへの変換がサポートされていない 2. TFXの入出力I/F(Channel)がKubeflowのI/F(PipelineParam)と互 換性が無い TFX Pipelineのコンポーネント群を、自作コンポーネントと組み合わせてパイプラインを構成 KubeFlow pipeline TFX pipeline間の互換性を 吸収するレイヤーを内製し導入完了 自作コンポーネント TFX Pipelineのコンポーネント conflict 問題 ※TFX 0.29.0での状況 Kubeflow自作コンポーネントと TFX Pipelineのコン ポーネントを組みわせることが出来ない 解決策 ※弊社事情でどうしても必要だった 差異を吸収
24. 4. 改善期 学習パイプラインを拡充する ~ TFX(2) TFX Pipelineのコンポーネントを取り入れることで一気にパイプラインが充実する パイプライン データ 抽出 学習 Build & Push 初期 現在 ✅ ✅ ✅ ✅ ✅
25. 4. 改善期 その他取り組み中のこと パイプライン1 アンサンブル A/Bテスト パイプライン2 パイプライン3 パイプラインA パイプラインB 100% mirror 基盤が整ってきたことを受けAdvancedな領域も挑戦中
26. 目次 1. はじめに 2. 導入計画 3. 導入期 4. 改善期 5. おわりに
27. 5. おわりに まとめ 1. CTを導入すると様々な利点がある 2. 導入の際はパイプラインのスコープを絞り小さく始める 3. 小さく導入したあとで、大きく育てる 4. CT導入の際は、TFXとKubeflowはおすすめ出来る
28. 5. おわりに 弊社では同領域に興味のあるML/MLOpsエンジニアを絶賛募集
30. 参考
31. 参考 TensorFlow Servingのモデルファイル(saved model)について モデルファイル 推論サービス 1.出力する 2.読み込み 3.立ち上がる 4.動作確認