MLプロジェクトのリリースフローを考える

2022/02に行われた社内 AI技術勉強会の発表資料

Transcript

1. Mobility Technologies Co., Ltd. MLエンジニアリンググループ 鈴木 隆史 MLプロジェクトのリリースフローを考える
2. Mobility Technologies Co., Ltd. 自己紹介 2 鈴木 隆史 | Takashi Suzuki 開発本部 AI技術開発部 MLエンジニアリンググループ • 2019年DeNA入社 機械学習の実験基盤やパイプラインの設計開発を担当 • 2020年Mobility Technologies転籍
3. Mobility Technologies Co., Ltd. MLプロジェクトのリリースフローの話 • どんな課題があるのか • 技術コンポーネント例 • 活用方法 今日話すこと 3
4. Mobility Technologies Co., Ltd. MLリリースフローの課題 01 4
5. Mobility Technologies Co., Ltd. プロジェクトごとのドメイン知識が必要 • 複雑な依存関係のためリリース作業が属人化しがち • 各プロジェクトで独自リリース手順が存在する • A/Bテストができたりできなかったり MLプロジェクトのリリースフローの課題 5
6. Mobility Technologies Co., Ltd. • データパイプライン：生データ作成、整形データ作成 • 学習パイプライン：特徴量作成、モデル学習、(統計値作成)（数日おき） • バッチ推論パイプライン：ML予測値作成（数分おき） • オンライン推論サーバ：ML予測値作成（リアルタイム） 一般的なMLプロジェクト 6
7. Mobility Technologies Co., Ltd. リリース時に現行推論パイプラインを停止させない • 学習・推論時でコンテナ、特徴量、モデルが共有されていると、学習パイプラ インだけ更新したつもりが推論で失敗することがある • 推論パイプラインは上記データがないと動かない 考慮すべき項目(1/2) 7
8. Mobility Technologies Co., Ltd. リリース時の手動作業をなくす • 特に特徴量の依存関係が複雑になりやすく手動更新が発生することがある ため、すべてワークフロー側に処理を寄せる • 開発者はリリースバージョンを更新してmainブランチにマージすれば、コンテ ナ、ワークフロー、特徴量、モデルなど全てのリソースが自動更新されるよう にする 考慮すべき項目(2/2) 8
9. Mobility Technologies Co., Ltd. 技術コンポーネント例 02 9
10. Mobility Technologies Co., Ltd. システム構成例 10
11. Mobility Technologies Co., Ltd. リリース環境分離のためGitフローにのせCI/CDで自動化 • 作業ブランチ：feature, fix, などのCI • developブランチ：開発環境へCD • mainブランチ：本番環境へCD リリースフローの自動化(1/2) 11
12. Mobility Technologies Co., Ltd. CDで自動デプロイするコンポーネント • コンテナイメージ：ワークフロー実行時に利用 • 学習Adhoc Job：学習パイプラインをAdhoc実行 推論に必要な特徴量、モデルを事前作成 • ワークフロー：Job完了後に学習・推論パイプラインを登録 リリースフローの自動化(2/2) 12 学習Adhoc Jobで事前作成
13. Mobility Technologies Co., Ltd. コードの管理 • GitHubとContainer Registryで管理 • 追いやすいようにリリースバージョンはコード側で管理 ◦ そこからgit tagやreleases、コンテナimage tagを作成 ◦ 例）gcr.io/project/container_image:version • CDで自動でビルド、プッシュされる リソースのバージョン管理(1/6) 13
14. Mobility Technologies Co., Ltd. ワークフローの管理 • ワークフローエンジン側でバージョン管理 ◦ Kubeflow Pipelinesだとバージョン管理の仕組みがあるので、そこで管 理 ◦ Airflowだとまだバージョン管理の仕組みがないので、DAG_IDにsuffix追 記して管理 • CDで自動で学習Adhoc Job実行、DAG登録される • ワークフローが並列実行できるとA/Bテストが実施しやすい ◦ 例）パイプライン1をAユーザクラスタ、パイプライン2をBユーザクラスタ リソースのバージョン管理(2/6) 14
15. Mobility Technologies Co., Ltd. ワークフローの管理 • Kubeflow Pipelinesの例 リソースのバージョン管理(3/6) 15 Pipeline Versions Recurring Runs
16. Mobility Technologies Co., Ltd. 特徴量の管理 • BigQueryなどのデータセットで管理 ◦ カラム変更が想定される場合は、バージョンごとにデータセットやテーブ ルを分割して管理 ◦ カラム変更がない場合は、バージョンカラムをもたせて管理 • 学習Adhoc Job実行で自動で作成される • 毎バージョンごとに特徴量を作り直すコストがかかる場合は、特徴量独自に バージョン情報をもたせる リソースのバージョン管理(4/6) 16
17. Mobility Technologies Co., Ltd. 学習済みモデルの管理 • Cloud Storageで管理 ◦ 例）gs://project_bucket/models/version/name.pkl ◦ コードは不変だが学習モデルが継続的に更新される場合に有効 • コンテナイメージに内蔵して管理 ◦ 例）学習用と推論用のコンテナイメージを分離して管理 • 学習Adhoc Job実行で自動で作成される リソースのバージョン管理(5/6) 17
18. Mobility Technologies Co., Ltd. プロダクトに提供する予測データの管理 • バッチ推論の場合 ◦ ワークフローでBigQueryやCloud Storageにバージョン付き予測データを 出力 • オンライン推論の場合 ◦ GKEで複数DeploymentとIngress ruleを設定して、バージョンごとに別エ ンドポイントを提供 • バージョンごとに予測データが分離されているとA/Bテストが実施しやすい リソースのバージョン管理(6/6) 18
19. Mobility Technologies Co., Ltd. システム構成例（再掲） 19
20. Mobility Technologies Co., Ltd. まとめ 03 20
21. Mobility Technologies Co., Ltd. リリースフローの自動化 • 特徴量やモデルなどの依存データ更新を全てワークフロー処理に寄せる • 開発者はリリースバージョンを更新してmainブランチにマージすれば、CI/CD でコンテナ、ワークフロー、特徴量、モデルなど全てのリソースを自動更新す るようにする • リリース作業の属人化をなくせる まとめ(1/2) 21
22. Mobility Technologies Co., Ltd. リソースのバージョン管理 • 現行の推論パイプラインを停止させないために、コンテナ、ワークフロー、特 徴量、モデルにバージョン管理を導入 • 並列でパイプラインを提供することで、ブルーグリーンデプロイメントやA/Bテ ストの導入がしやすくなる まとめ(2/2) 22
23. Mobility Technologies Co., Ltd. Appendix 04 23
24. Mobility Technologies Co., Ltd. コードバージョンの一元管理 • ライブラリが増えてくるとバージョンが複数ファイルに跨ることがある • 更新忘れがあるため一元管理、または機能を寄せると良い Appendix(1/2) 24 pyproject.toml invoke.yaml
25. Mobility Technologies Co., Ltd. コードバージョンの一元管理 • poetry（パッケージ管理）、invoke（タスクランナー）、hydra（パラメータ管理）の例 Appendix(2/2) 25 pyproject.toml invoke.yaml
26. confidential 文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。 Mobility Technologies Co., Ltd. 26