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
150
Kubernetes超入門
t24kc
0
140
AI予約サービスのMLOps事例紹介
t24kc
0
24
GOの機械学習システムを支えるMLOps事例紹介
t24kc
0
120
Optuna on Kubeflow Pipeline 分散ハイパラチューニング
t24kc
0
37
GOの実験環境について
t24kc
0
19
MOVの機械学習システムを支えるMLOps実践
t24kc
0
24
タクシー×AIを支えるKubernetesとAIデータパイプラインの信頼性の取り組みについて
t24kc
0
41
MOV お客さま探索ナビの GCP ML開発フローについて
t24kc
0
16
Other Decks in Technology
See All in Technology
dbt開発 with Claude Codeのためのガードレール設計
10xinc
2
1.1k
Automating Web Accessibility Testing with AI Agents
maminami373
0
1.2k
MCPで変わる Amebaデザインシステム「Spindle」の開発
spindle
PRO
3
3.2k
品質視点から考える組織デザイン/Organizational Design from Quality
mii3king
0
200
Function Body Macros で、SwiftUI の View に Accessibility Identifier を自動付与する/Function Body Macros: Autogenerate accessibility identifiers for SwiftUI Views
miichan
2
180
20250903_1つのAWSアカウントに複数システムがある環境におけるアクセス制御をABACで実現.pdf
yhana
3
540
なぜスクラムはこうなったのか?歴史が教えてくれたこと/Shall we explore the roots of Scrum
sanogemaru
5
1.6k
「何となくテストする」を卒業するためにプロダクトが動く仕組みを理解しよう
kawabeaver
0
380
roppongirb_20250911
igaiga
1
210
allow_retry と Arel.sql / allow_retry and Arel.sql
euglena1215
1
160
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
270
5年目から始める Vue3 サイト改善 #frontendo
tacck
PRO
3
220
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.8k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
580
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
It's Worth the Effort
3n
187
28k
How to Ace a Technical Interview
jacobian
279
23k
The Invisible Side of Design
smashingmag
301
51k
RailsConf 2023
tenderlove
30
1.2k
Navigating Team Friction
lara
189
15k
The Cult of Friendly URLs
andyhume
79
6.6k
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
Into the Great Unknown - MozCon
thekraken
40
2k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
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