データサイエンスのフルサイクル開発を実現する機械学習パイプライン

データサイエンスのフルサイクル開発を実現する機械学習パイプライン 2024-09-28 @PyCon 2024 CARTA MARKETING FIRMの事例から学ぶ神谷クリスチャン
1

Copyright © 2024 CARTA MARKETING FIRM Inc. All rights reserved
自己紹介神谷クリスチャン Cristian Kamiya 経歴 • 2020年CARTA HOLDINGS(当時: VOYAGE GROUP)新卒入社 • CARTA MARKETING FIRM 開発局DSP部MLチーム所属 • データサイエンスエンジニア • 2人の子供がいます（長男、次男） • ブラジルと日本のハーフ󰎙󰏦 @xcnkx @x2CnK8x 2

アドテクノロジーとはなにか RTB DSP DSP SSP 　オークションアドテクノロジーユーザメディア広告主 DSP: Demand Side Platform SSP: Supply Side Platform 3

RTB DSP DSP SSP 　ユーザメディア広告主私の担当範囲 DSPの入札ロジックの開発と運用を担当広告主のKPIを満たすためにはいくらで入札をすべきか？ 4

アジェンダ 1. フルサイクルデータサイエンティストとは 2. 課題と理想の機械学習基盤 3. CARTA MARKETING FIRMのデータ分析基盤の歴史 a. Luigiベース基盤 b. SageMakerベース基盤 c. Prefectベース基盤 4. 成果と今後の展望 5

1. フルサイクルデータサイエンティストとは？ 6

1. フルサイクルデータサイエンティストとは？一般的なデータサイエンスプロダクトのライフサイクル計画プロトタイプリリース評価 7

1. フルサイクルデータサイエンティストとは？ CARTA MARKETING FIRMにおける理想 CMF ML Task Cycle Collect data Clean data Explore data Evaluate Model Build and Train Model Continuou s Traning Continuou s Delivery Monitoring A/B testing • プロダクトライフサイクル全体に対して 1人ひとりがオーナーシップを持つ • 価値を届けるすべての過程を 1人で回すことができる 8

1. フルサイクルデータサイエンティストとは？ CARTA MARKETING FIRMにおける理想 CMF ML Task Cycle Collect data Clean data Explore data Evaluate Model Build and Train Model Continuou s Traning Continuou s Delivery Monitoring A/B testing • チームメンバー全員が単独で自律的にサイクルを回せる • 属人性はツールや責務分離で改善していく 9

• 1人が価値を届けるすべての領域を開発 • あくまでも技術領域・開発対象範囲 1. 似ている概念 - フルスタック開発フルスタック開発とは引用元: https://speakerdeck.com/carta_engineering/42tokyo-special-lecture-231106?slide=23 10

フルサイクルフルスタックフルサイクル & フルスタックはスーパーマンしか出来ない CMF ML Task Cycle Collect
data Clean data Explore data Evaluate Model Build and Train Model Continuous Traning Continuous Delivery Monitoring A/B testing 11

フルサイクルフルスタックツール / 責務分離を使うことで “属人性”を廃していくことが理想 CMF ML Task Cycle
Collect data Clean data Explore data Evaluate Model Build and Train Model Continuous Traning Continuous Delivery Monitoring A/B testing 12

1. フルサイクルデータサイエンティストとは？なぜフルサイクル開発なのか？外的要因をできるだけ減らしてデータサイエンティストが最も価値が出せる働き方だから 13

1. フルサイクルデータサイエンティストとは？なぜなら • 一つの施策が当たるとは限らない、多くの施策を試す必要がある • 最速で施策を実装・検証することが重要 • 試行サイクルを効果的に回す上で、担当領域の区分けはただの障壁 • 1人で全工程を担当するのが当然ながら、1番高速 14

2. 課題と理想の機械学習基盤 15

2. フルサイクルデータサイエンティストの課題ロジックとOpsを同時に管理・運用する必要があるロジック施策・改善 Ops層データパイプラインモデル学習モデルサービングロジック層 16

2. フルサイクルデータサイエンティストの課題ロジックとOpsを同時に管理・運用する必要があるロジック施策・改善 Ops層データパイプラインモデル学習モデルサービングロジック層データサイエンティスト 17

2. フルサイクルデータサイエンティストの課題ロジックの施策・改善に向き合う時間を確保できない特徴抽出コアロジック以外データ品質管理データ収集特徴抽出サービングインフラ CI／CD モニタリング A/Bテスト基盤コアロジック特徴抽出 18

2. 課題と理想の状態私達が目指すべき理想の状態 • データサイエンティストが見るべき・管理すべき範囲が狭い • データサイエンティストがロジック開発やデータ分析に集中できる • データサイエンティストが持つスキルセットでフルサイクルに開発ができる 19

ロジック施策・改善 Ops層データパイプラインモデル学習モデルサービングロジック層 2. 走り続けて見つけた理想状態データサイエンティストの仕事の領域が限定されてよりロジック施策・改善に対して高速にサイクルを回せる状態データ基盤サービング基盤学習基盤データサイエンティスト 20

• シンプル • マネージドサービス • カスタマイズ可能 • Pythonic 2. 理想の状態を支える基盤の技術要件 21

• シンプル ◦ 理解しやすく、使いやすいそして捨てやすい • マネージドサービス ◦ サーバーレス、ハードウェア管理不要 ◦ スケーラビリティの自動化 • カスタマイズ可能 ◦ 基本機能は簡単に利用可能 ◦ 高度なニーズにも対応可能 • Pythonic ◦ データサイエンティストに馴染みのある言語 ◦ 豊富なライブラリとエコシステム 2. 理想の状態を支える基盤の技術要件 22

3. CARTA MARKETING FIRMのデータ分析基盤の歴史 23

3. CARTA MARKETING FIRMのデータ分析基盤の歴史 2015 2022 2023 Luigiベース基盤 AWS Sagemakerベース基盤 Prefectベース基盤 24

Luigi時代 2015 2022 2023 Luigiベース基盤 AWS Sagemakerベース基盤 Prefectベース基盤 25

Luigi時代 - 導入背景 • 機械学習モデルをプロダクトに初めて導入 ◦ 最小の実装で進めたかった • 学習コストが低い ◦ チームがすでにデータパイプラインとしてLuigiの使用に慣れていた • 柔軟性 ◦ ETLと機械学習タスクの両方をカバーできる汎用性 26

Luigi時代 - チーム状況 • チームメンバー構成 ◦ 󰭉シニアデータサイエンティスト（元SE）1人 ◦ 󰞵ソフトウェアエンジニア 1人 • 担当業務 ◦ データパイプラインの構築・運用 ◦ 機械学習モデルの開発・導入・運用 ◦ DSがフルスタックに開発 27

Luigi時代 - チーム状況 • チームメンバー構成 ◦ 󰭉シニアデータサイエンティスト（元SE）1人 ◦ 󰞵ソフトウェアエンジニア 1人 • 担当業務 ◦ データパイプラインの構築・運用 ◦ 機械学習モデルの開発・導入・運用 ◦ DSがフルスタックに開発基盤完成後に私が入社 28

Luigi時代 - アーキテクチャ図 29

Luigi時代 - アーキテクチャ図このときはデータパイプライン・機械学習パイプラインを同じ基盤で処理していた 30

Luigi時代 - アーキテクチャ図データパイプライン 31

Luigi時代 - アーキテクチャ図モデル学習 32

Luigi時代 - 具体的な課題 • データサイエンティストの対象領域が広い • A/Bテスト時のオペレーションが複雑 • 開発体験の問題 33

Luigi時代 - 具体的な課題データサイエンティストの対象領域が広い ◦ データパイプラインと機械学習パイプラインの両方を担当 ◦ ロジック開発・施策の効果検証も実施結果としてやることが多く、スーパーマン以外は価値を出すことが難しかった 34

A/Bテスト時のオペレーションが複雑 ◦ 本番環境でのコードの追加・削除が必要 ▪ 使ってるかわからないコードが発生 ◦ 既存コードへの深い理解が必要 ▪ 本番環境をいじるので何がどう影響するのか心理的安全性が低い Luigi時代 - 具体的な課題 35

Luigi時代 - 具体的な課題開発体験の問題 ◦ ローカル環境で動作せず、EC2を立ち上げて開発が必要 ◦ ステージング環境がない ▪ パイプラインのテスト本番環境でしかテストできない 36

波乱 37

この時、データサイエンス領域をリードしていたシニアデータサイエンティストの退職が決定 Luigi時代 - 波乱 38

Luigi時代 - 波乱 • 既にいた新卒3名の育成 • 中途採用が難航 39

Luigi時代 - 波乱個人の力に頼らずチームで価値を生み出しやすい新たな機械学習基盤が必要に 40

Sagemaker時代 2015 2022 2023 Luigiベース基盤 AWS Sagemakerベース基盤 Prefectベース基盤 41

Sagemaker時代 - チーム状況データエンジニアがチームにJoin データ基盤の管理を全て任せることができた 42

Sagemaker時代 - チーム状況その結果、機械学習基盤の改善にやっと時間を費すことができる状態に 43

Sagemaker時代 - チーム状況 • チームメンバー構成 ▪ 󰞲ジュニアデータサイエンティスト：2名 ▪ 󰞵新たにデータエンジニア：1名が加入 44 • 役割分担の再編成 ◦ 󰞲データサイエンティスト ▪ 施策提案、ロジック開発、機械学習パイプラインの担当 ◦ 󰞵データエンジニア ▪ データパイプラインの開発・運用を担当

次の基盤に求める技術要件 • 既存システムとの親和性が高い • 学習コストが低い • サポートが手厚い 45

次の基盤に求める技術要件既存システムとの親和性が高い ◦ BQからSnowflakeに移行したデータウェアハウスと AWSにある配信サーバとの連携が容易 46

次の基盤に求める技術要件学習コストが低い ◦ 新しいツールの導入による負担を軽減 ◦ ジュニアメンバー主体のチームでも実装可能 47

次の基盤に求める技術要件サポートの手厚い ◦ プロトタイピングの容易さ ◦ ドキュメントの量 48

選ばれたのがAWS SageMaker 49

選ばれたのがAWS SageMaker • 既存システムとの親和性 ◦ 既存システムがAWS上で稼働しているため、連携が容易 ◦ DWHがBigQueryから Snowflakeへの移行しGoogle依存が減少 • プロトタイピングプログラムの活用 ◦ AWSのプロトタイピングエンジニアの支援を受けられたこと ◦ ジュニアメンバー主体のチームでも実装可能 • 学習コストの削減 ◦ 新しいツールの導入による負担を軽減 50

SageMakerベース基盤のアーキテクチャ図 51

SageMakerベース基盤のアーキテクチャ図 • CDKによる一括インフラ管理 • モデルごとにTrain Stackを作成 52

SageMakerベース基盤のアーキテクチャ図 • PythonスクリプトをSageMakerでコンテナ化しProcessing Jobで実行 • 本番環境と開発環境の差分がない状態に • オーケストレーションツールは Step Functions 53

3. CARTA MARKETING FIRMのデータ分析基盤の歴史 2022 2023 AWS Sagemakerベース基盤 Prefectベース基盤 2015 Luigiベース基盤 54

Prefect時代 - 導入背景 1. インフラ構築の複雑さ ◦ 当初は慣れの問題と考えていたが、A/Bテストのような一時的な実装にも高いコストがかかり、データサイエンティストの負担が増大 2. ワークフローの柔軟性不足 ◦ Step Functionsでのタスク間のデータ受け渡しや新規DAGの追加が簡単ではない ◦ すべてCDK上で書く必要があった 55 SageMaker基盤で見えてきた新たな課題

Prefect時代 - 導入背景 3. ログ監視の困難さ ◦ Lambda、SageMaker Processing Jobs、Step Functionsなど、複数のサービスにまたがるログの確認が必要 ◦ 障害時などの認知負荷が高い 4. オーバースペック ◦ 私達のシステムに対して機能やスケーラビリティが過剰で、運用負荷が大きい ◦ もっとシンプルなワークフローで十分 56

Prefect時代 - 次の基盤に求める技術要件 • インフラ構築の簡素化 ◦ データサイエンティストが容易に扱えるシンプルなインフラ管理 • ワークフローの柔軟性と拡張性 ◦ 直感的なワークフロー定義が可能 • ログ監視とデバッグの効率化 ◦ ログの一元管理で効率的な監視が可能 • シンプル ◦ 理解しやすく、使いやすい 57

選ばれたのがPrefect • Pythonエコシステムの統一性 ◦ 全工程をPythonで一貫して記述可能 ◦ 異なる技術スタックを扱う必要がない ◦ インフラからバッチ処理までPythonで完結 • 直感的なワークフロー構築 ◦ タスク間のパラメータ設定が容易 ◦ 既存のPython関数にデコレータを追加するだけでタスク定義 58

Prefectベース基盤のアーキテクチャ図 59

Prefectベース基盤のアーキテクチャ図 • ECS ServiceでPrefect Workerを起動 • WorkerがPrefect CloudにタスクをpollしてECSタスクを起動 • ECSタスク内でTaskを実行 • Prefect CloudにDeploymentをdeployするだけ 60

TaskとFlowの定義例 61 タスクの依存関係を Prefectで記述

ECSタスクとしてデプロイする例 62 TerraformやCDKで書いていたものを Pythonで記述可能にデプロイコード

Prefect Cloud UI 63

ロジック施策・改善 Ops層データパイプラインモデル学習モデルサービングロジック層 Prefect基盤による成果データサイエンティストの仕事の領域が限定されてよりロジック施策・改善に対して高速にサイクルを回せるようにデータサイエンティスト 64

ロジック施策・改善 Ops層データパイプラインモデル学習モデルサービングロジック層 Prefect基盤による成果データサイエンティストの仕事の領域が限定されてよりロジック施策・改善に対して高速にサイクルを回せるようにデータサイエンティストデータ基盤 65

各パイプラインのまとめ Luigiベース基盤 Sagemakerベース基盤 Prefectベース基盤 DSの責務範囲の狭さ ❌ ⭕ ⭕ A/Bテストの容易さ ❌ ⭕ ⭕ 開発体験 ❌ ⭕ ⭕ 実装コスト ⭕ 🔺 IaCの認知負荷が高い ⭕ ワークフローの柔軟性 ⭕ 🔺 StepFunctionでの記述が困難 ⭕ ログ監視 ⭕ 🔺 リソース別の CloudWatch logsを見る必要がある ⭕ 費用 ⭕ ⭕ 🔺 ユーザー課金のため 66

データサイエンティストの対象領域 - Luigiベース基盤 Ops ロジック 67

データサイエンティストの対象領域 - SageMakerベース基盤 Ops 68 ロジック

データサイエンティストの対象領域 - Prefectベース基盤 Ops 69 ロジック

4. 成果と今後の展望 70

4. 得られた成果データサイエンティストの本質的な価値を生む時間の増加 • 現在のPrefectベース基盤により本質的な部分以外のOpsが減少 • データサイエンティストがより価値を出せる本質的な部分に集中することができるように ML code Algorithm Core logic 本質的な部分減少非本質的な部分解決された部分 71

4. 現在のチーム構成現在はML opsエンジニアも採用できより本質的な価値に向き合える体制に ML ops エンジニアロジック施策・改善 Ops層データパイプラインモデル学習モデルサービングロジック層データサイエンティストデータ基盤 72

4. 成果と今後の展望 • 機械学習モデルのバージョン管理の最適化 • 機械学習モデルのサービング基盤の改善 • 機械学習モデルのE2Eテスト、リグレッションテストの強化 • データ品質管理とモニタリングシステムの改善 • モデルの説明可能性と透明性の向上 • etc.. 73

ブースにて参加受付中！ノベルティも！ 74

実は登壇内容をブログ化しています https://techblog.cartaholdings.co.jp/entry/2024/09/03/144226 75

ご清聴ありがとうございました🙇 76

参考資料 • スペシャリスト？フルスタック？whichではないフルサイクル開発者という生き方 / 42TOKYO-SPECIAL-LECTURE-231106 - Speaker Deck • Full Cycle Data Science (FCDS): Key to Scaling Data-Driven Organizations | dmarcous • Hidden Technical Debt in Machine Learning Systems • 8年間の進化！CARTA MARKETING FIRMが機械学習基盤を刷新した理由とその成果 77

データサイエンスのフルサイクル開発を実現する機械学習パイプライン

データサイエンスのフルサイクル開発を実現する機械学習パイプライン

Other Decks in Programming

Featured

Transcript