Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
MLプロジェクトのリリースフローを考える
Search
Takashi Suzuki
February 01, 2022
Technology
0
13
MLプロジェクトのリリースフローを考える
2022/02に行われた社内 AI技術勉強会の発表資料
Takashi Suzuki
February 01, 2022
Tweet
Share
More Decks by Takashi Suzuki
See All by Takashi Suzuki
到着予想時間サービスの特徴量のニアリアルタイム化
t24kc
0
130
Kubernetes超入門
t24kc
0
130
AI予約サービスのMLOps事例紹介
t24kc
0
23
GOの機械学習システムを支えるMLOps事例紹介
t24kc
0
110
Optuna on Kubeflow Pipeline 分散ハイパラチューニング
t24kc
0
33
GOの実験環境について
t24kc
0
19
MOVの機械学習システムを支えるMLOps実践
t24kc
0
20
タクシー×AIを支えるKubernetesとAIデータパイプラインの信頼性の取り組みについて
t24kc
0
39
MOV お客さま探索ナビの GCP ML開発フローについて
t24kc
0
15
Other Decks in Technology
See All in Technology
AWS CDK 入門ガイド これだけは知っておきたいヒント集
anank
3
310
AWS CDKの仕組み / how-aws-cdk-works
gotok365
8
380
開発生産性を測る前にやるべきこと - 組織改善の実践 / Before Measuring Dev Productivity
kaonavi
14
6.6k
ポストコロナ時代の SaaS におけるコスト削減の意義
izzii
1
120
What’s new in Android development tools
yanzm
0
470
CDKコード品質UP!ナイスな自作コンストラクタを作るための便利インターフェース
harukasakihara
2
140
freeeのアクセシビリティの現在地 / freee's Current Position on Accessibility
ymrl
2
240
cdk initで生成されるあのファイル達は何なのか/cdk-init-generated-files
tomoki10
0
200
[SRE NEXT] ARR150億円_エンジニア140名_27チーム_17プロダクトから始めるSLO.pdf
satos
2
800
Sansanのデータプロダクトマネジメントのアプローチ
sansantech
PRO
0
200
SRE不在の開発チームが障害対応と 向き合った100日間 / 100 days dealing with issues without SREs
shin1988
1
440
ビジネス職が分析も担う事業部制組織でのデータ活用の仕組みづくり / Enabling Data Analytics in Business-Led Divisional Organizations
zaimy
1
220
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
54
13k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Bash Introduction
62gerente
613
210k
Scaling GitHub
holman
460
140k
Designing for Performance
lara
610
69k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Into the Great Unknown - MozCon
thekraken
40
1.9k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Optimizing for Happiness
mojombo
379
70k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Transcript
Mobility Technologies Co., Ltd. MLエンジニアリンググループ 鈴木 隆史 MLプロジェクトのリリースフローを考える
Mobility Technologies Co., Ltd. 自己紹介 2 鈴木 隆史 | Takashi
Suzuki 開発本部 AI技術開発部 MLエンジニアリンググループ • 2019年DeNA入社 機械学習の実験基盤やパイプラインの設計開発を担当 • 2020年Mobility Technologies転籍
Mobility Technologies Co., Ltd. MLプロジェクトのリリースフローの話 • どんな課題があるのか • 技術コンポーネント例 •
活用方法 今日話すこと 3
Mobility Technologies Co., Ltd. MLリリースフローの課題 01 4
Mobility Technologies Co., Ltd. プロジェクトごとのドメイン知識が必要 • 複雑な依存関係のためリリース作業が属人化しがち • 各プロジェクトで独自リリース手順が存在する •
A/Bテストができたりできなかったり MLプロジェクトのリリースフローの課題 5
Mobility Technologies Co., Ltd. • データパイプライン:生データ作成、整形データ作成 • 学習パイプライン:特徴量作成、モデル学習、(統計値作成)(数日おき) • バッチ推論パイプライン:ML予測値作成(数分おき)
• オンライン推論サーバ:ML予測値作成(リアルタイム) 一般的なMLプロジェクト 6
Mobility Technologies Co., Ltd. リリース時に現行推論パイプラインを停止させない • 学習・推論時でコンテナ、特徴量、モデルが共有されていると、学習パイプラ インだけ更新したつもりが推論で失敗することがある • 推論パイプラインは上記データがないと動かない
考慮すべき項目(1/2) 7
Mobility Technologies Co., Ltd. リリース時の手動作業をなくす • 特に特徴量の依存関係が複雑になりやすく手動更新が発生することがある ため、すべてワークフロー側に処理を寄せる • 開発者はリリースバージョンを更新してmainブランチにマージすれば、コンテ
ナ、ワークフロー、特徴量、モデルなど全てのリソースが自動更新されるよう にする 考慮すべき項目(2/2) 8
Mobility Technologies Co., Ltd. 技術コンポーネント例 02 9
Mobility Technologies Co., Ltd. システム構成例 10
Mobility Technologies Co., Ltd. リリース環境分離のためGitフローにのせCI/CDで自動化 • 作業ブランチ:feature, fix, などのCI •
developブランチ:開発環境へCD • mainブランチ:本番環境へCD リリースフローの自動化(1/2) 11
Mobility Technologies Co., Ltd. CDで自動デプロイするコンポーネント • コンテナイメージ:ワークフロー実行時に利用 • 学習Adhoc Job:学習パイプラインをAdhoc実行
推論に必要な特徴量、モデルを事前作成 • ワークフロー:Job完了後に学習・推論パイプラインを登録 リリースフローの自動化(2/2) 12 学習Adhoc Jobで事前作成
Mobility Technologies Co., Ltd. コードの管理 • GitHubとContainer Registryで管理 • 追いやすいようにリリースバージョンはコード側で管理
◦ そこからgit tagやreleases、コンテナimage tagを作成 ◦ 例)gcr.io/project/container_image:version • CDで自動でビルド、プッシュされる リソースのバージョン管理(1/6) 13
Mobility Technologies Co., Ltd. ワークフローの管理 • ワークフローエンジン側でバージョン管理 ◦ Kubeflow Pipelinesだとバージョン管理の仕組みがあるので、そこで管
理 ◦ Airflowだとまだバージョン管理の仕組みがないので、DAG_IDにsuffix追 記して管理 • CDで自動で学習Adhoc Job実行、DAG登録される • ワークフローが並列実行できるとA/Bテストが実施しやすい ◦ 例)パイプライン1をAユーザクラスタ、パイプライン2をBユーザクラスタ リソースのバージョン管理(2/6) 14
Mobility Technologies Co., Ltd. ワークフローの管理 • Kubeflow Pipelinesの例 リソースのバージョン管理(3/6) 15
Pipeline Versions Recurring Runs
Mobility Technologies Co., Ltd. 特徴量の管理 • BigQueryなどのデータセットで管理 ◦ カラム変更が想定される場合は、バージョンごとにデータセットやテーブ ルを分割して管理
◦ カラム変更がない場合は、バージョンカラムをもたせて管理 • 学習Adhoc Job実行で自動で作成される • 毎バージョンごとに特徴量を作り直すコストがかかる場合は、特徴量独自に バージョン情報をもたせる リソースのバージョン管理(4/6) 16
Mobility Technologies Co., Ltd. 学習済みモデルの管理 • Cloud Storageで管理 ◦ 例)gs://project_bucket/models/version/name.pkl
◦ コードは不変だが学習モデルが継続的に更新される場合に有効 • コンテナイメージに内蔵して管理 ◦ 例)学習用と推論用のコンテナイメージを分離して管理 • 学習Adhoc Job実行で自動で作成される リソースのバージョン管理(5/6) 17
Mobility Technologies Co., Ltd. プロダクトに提供する予測データの管理 • バッチ推論の場合 ◦ ワークフローでBigQueryやCloud Storageにバージョン付き予測データを
出力 • オンライン推論の場合 ◦ GKEで複数DeploymentとIngress ruleを設定して、バージョンごとに別エ ンドポイントを提供 • バージョンごとに予測データが分離されているとA/Bテストが実施しやすい リソースのバージョン管理(6/6) 18
Mobility Technologies Co., Ltd. システム構成例(再掲) 19
Mobility Technologies Co., Ltd. まとめ 03 20
Mobility Technologies Co., Ltd. リリースフローの自動化 • 特徴量やモデルなどの依存データ更新を全てワークフロー処理に寄せる • 開発者はリリースバージョンを更新してmainブランチにマージすれば、CI/CD でコンテナ、ワークフロー、特徴量、モデルなど全てのリソースを自動更新す
るようにする • リリース作業の属人化をなくせる まとめ(1/2) 21
Mobility Technologies Co., Ltd. リソースのバージョン管理 • 現行の推論パイプラインを停止させないために、コンテナ、ワークフロー、特 徴量、モデルにバージョン管理を導入 • 並列でパイプラインを提供することで、ブルーグリーンデプロイメントやA/Bテ
ストの導入がしやすくなる まとめ(2/2) 22
Mobility Technologies Co., Ltd. Appendix 04 23
Mobility Technologies Co., Ltd. コードバージョンの一元管理 • ライブラリが増えてくるとバージョンが複数ファイルに跨ることがある • 更新忘れがあるため一元管理、または機能を寄せると良い Appendix(1/2)
24 pyproject.toml invoke.yaml
Mobility Technologies Co., Ltd. コードバージョンの一元管理 • poetry(パッケージ管理)、invoke(タスクランナー)、hydra(パラメータ管理)の例 Appendix(2/2) 25 pyproject.toml
invoke.yaml
confidential 文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。 Mobility Technologies Co., Ltd. 26