MLプロジェクトのリリースフローを考える

Mobility Technologies Co., Ltd.
MLエンジニアリンググループ
鈴木隆史
MLプロジェクトのリリースフローを考える

自己紹介
2
鈴木隆史 | Takashi Suzuki
開発本部 AI技術開発部 MLエンジニアリンググループ
● 2019年DeNA入社
機械学習の実験基盤やパイプラインの設計開発を担当
● 2020年Mobility Technologies転籍

MLプロジェクトのリリースフローの話
● どんな課題があるのか
● 技術コンポーネント例
● 活用方法
今日話すこと
3

MLリリースフローの課題
01
4

プロジェクトごとのドメイン知識が必要
● 複雑な依存関係のためリリース作業が属人化しがち
● 各プロジェクトで独自リリース手順が存在する
● A/Bテストができたりできなかったり
MLプロジェクトのリリースフローの課題
5

● データパイプライン：生データ作成、整形データ作成
● 学習パイプライン：特徴量作成、モデル学習、(統計値作成)（数日おき）
● バッチ推論パイプライン：ML予測値作成（数分おき）
● オンライン推論サーバ：ML予測値作成（リアルタイム）
一般的なMLプロジェクト
6

リリース時に現行推論パイプラインを停止させない
● 学習・推論時でコンテナ、特徴量、モデルが共有されていると、学習パイプラ
インだけ更新したつもりが推論で失敗することがある
● 推論パイプラインは上記データがないと動かない
考慮すべき項目(1/2)
7

リリース時の手動作業をなくす
● 特に特徴量の依存関係が複雑になりやすく手動更新が発生することがある
ため、すべてワークフロー側に処理を寄せる
● 開発者はリリースバージョンを更新してmainブランチにマージすれば、コンテ
ナ、ワークフロー、特徴量、モデルなど全てのリソースが自動更新されるよう
にする
考慮すべき項目(2/2)
8

技術コンポーネント例
02
9

システム構成例
10

リリース環境分離のためGitフローにのせCI/CDで自動化
● 作業ブランチ：feature, ﬁx, などのCI
● developブランチ：開発環境へCD
● mainブランチ：本番環境へCD
リリースフローの自動化(1/2)
11

CDで自動デプロイするコンポーネント
● コンテナイメージ：ワークフロー実行時に利用
● 学習Adhoc Job：学習パイプラインをAdhoc実行
推論に必要な特徴量、モデルを事前作成
● ワークフロー：Job完了後に学習・推論パイプラインを登録
リリースフローの自動化(2/2)
12
学習Adhoc Jobで事前作成

コードの管理
● GitHubとContainer Registryで管理
● 追いやすいようにリリースバージョンはコード側で管理
○ そこからgit tagやreleases、コンテナimage tagを作成
○ 例）gcr.io/project/container_image:version
● CDで自動でビルド、プッシュされる
リソースのバージョン管理(1/6)
13

ワークフローの管理
● ワークフローエンジン側でバージョン管理
○ Kubeflow Pipelinesだとバージョン管理の仕組みがあるので、そこで管
理
○ Airflowだとまだバージョン管理の仕組みがないので、DAG_IDにsuffix追
記して管理
● CDで自動で学習Adhoc Job実行、DAG登録される
● ワークフローが並列実行できるとA/Bテストが実施しやすい
○ 例）パイプライン1をAユーザクラスタ、パイプライン2をBユーザクラスタ
14

ワークフローの管理
● Kubeﬂow Pipelinesの例
15
Pipeline Versions
Recurring Runs

特徴量の管理
● BigQueryなどのデータセットで管理
○ カラム変更が想定される場合は、バージョンごとにデータセットやテーブ
ルを分割して管理
○ カラム変更がない場合は、バージョンカラムをもたせて管理
● 学習Adhoc Job実行で自動で作成される
● 毎バージョンごとに特徴量を作り直すコストがかかる場合は、特徴量独自に
バージョン情報をもたせる
16

学習済みモデルの管理
● Cloud Storageで管理
○ 例）gs://project_bucket/models/version/name.pkl
○ コードは不変だが学習モデルが継続的に更新される場合に有効
● コンテナイメージに内蔵して管理
○ 例）学習用と推論用のコンテナイメージを分離して管理
● 学習Adhoc Job実行で自動で作成される
17

プロダクトに提供する予測データの管理
● バッチ推論の場合
○ ワークフローでBigQueryやCloud Storageにバージョン付き予測データを
出力
● オンライン推論の場合
○ GKEで複数DeploymentとIngress ruleを設定して、バージョンごとに別エ
ンドポイントを提供
● バージョンごとに予測データが分離されているとA/Bテストが実施しやすい
18

システム構成例（再掲）
19

まとめ
03
20

リリースフローの自動化
● 特徴量やモデルなどの依存データ更新を全てワークフロー処理に寄せる
● 開発者はリリースバージョンを更新してmainブランチにマージすれば、CI/CD
でコンテナ、ワークフロー、特徴量、モデルなど全てのリソースを自動更新す
るようにする
● リリース作業の属人化をなくせる
まとめ(1/2)
21

リソースのバージョン管理
● 現行の推論パイプラインを停止させないために、コンテナ、ワークフロー、特
徴量、モデルにバージョン管理を導入
● 並列でパイプラインを提供することで、ブルーグリーンデプロイメントやA/Bテ
ストの導入がしやすくなる
まとめ(2/2)
22

Appendix
04
23

コードバージョンの一元管理
● ライブラリが増えてくるとバージョンが複数ファイルに跨ることがある
● 更新忘れがあるため一元管理、または機能を寄せると良い
Appendix(1/2)
24
pyproject.toml invoke.yaml

コードバージョンの一元管理
● poetry（パッケージ管理）、invoke（タスクランナー）、hydra（パラメータ管理）の例
Appendix(2/2)
25
pyproject.toml
invoke.yaml

confidential
文章·画像等の内容の無断転載及び複製等の行為はご遠慮ください。
26

MLプロジェクトのリリースフローを考える

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a MLプロジェクトのリリースフローを考える

Semelhante a MLプロジェクトのリリースフローを考える (20)

Mais de Takashi Suzuki

Mais de Takashi Suzuki (10)

MLプロジェクトのリリースフローを考える