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
140
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
60以上のプロダクトを持つ組織における開発者体験向上への取り組み - チームAPIとBackstageで構築する組織の可視化基盤 - / sre next 2025 Efforts to Improve Developer Experience in an Organization with Over 60 Products
vtryo
3
980
モニタリング統一への道のり - 分散モニタリングツール統合のためのオブザーバビリティプロジェクト
niftycorp
PRO
1
370
AWS CDKの仕組み / how-aws-cdk-works
gotok365
10
900
ソフトウェアテストのAI活用_ver1.25
fumisuke
1
570
【LT会登壇資料】TROCCO新コネクタ「スマレジ」を活用した直営店データの分析
kazari0425
1
170
CDK Toolkit Libraryにおけるテストの考え方
smt7174
1
460
cdk initで生成されるあのファイル達は何なのか/cdk-init-generated-files
tomoki10
1
550
Sansanのデータプロダクトマネジメントのアプローチ
sansantech
PRO
0
230
クラウド開発の舞台裏とSRE文化の醸成 / SRE NEXT 2025 Lunch Session
kazeburo
1
460
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7.1k
伴走から自律へ: 形式知へと導くSREイネーブリングによる プロダクトチームの信頼性オーナーシップ向上 / SRE NEXT 2025
visional_engineering_and_design
3
230
microCMSではじめるAIライティング
himaratsu
0
120
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
The Pragmatic Product Professional
lauravandoore
35
6.7k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
510
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