Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GMOペパボのサービスと研究開発を支えるデータ基盤の裏側 / Inside Story of Data Infrastructure Supporting GMO Pepabo's Services and R&D

Hiroka Zaitsu
September 17, 2021

GMOペパボのサービスと研究開発を支えるデータ基盤の裏側 / Inside Story of Data Infrastructure Supporting GMO Pepabo's Services and R&D

Hiroka Zaitsu

September 17, 2021
Tweet

More Decks by Hiroka Zaitsu

Other Decks in Technology

Transcript

  1. GMOペパボのサービスと
    研究開発を支える
    データ基盤の裏側
    財津大夏 / GMO PEPABO inc.
    2021.09.17 GMO Developer Days 2021
    1

    View full-size slide

  2. ● ペパボのデータ基盤「Bigfoot」の開発運用
    ● ECサイトのユーザー行動を用いた研究
    ● Twitter : @HirokaZaitsu
    #データ基盤 #DataOps #MLOps #Python #SQL
    #統計学 #機械学習
    2
    自己紹介
    CTO室 研究開発チーム / 技術部 データ基盤チーム
    2012年 入社
    財津 大夏 Zaitsu Hiroka

    View full-size slide

  3. 3
    1. GMOペパボについて
    2. ペパボのデータ基盤「Bigfoot」
    3. ワークフローエンジン「Airflow」を使う上での工夫
    4. データ基盤を使った実例
    • ハンドメイドマーケット「minne」でのデータ活用とML Ops
    • 社内の生産性指標の計測
    5. データ基盤の今後
    アジェンダ

    View full-size slide

  4. 1. GMOペパボについて
    4

    View full-size slide

  5. GMOペパボについて
    5
    • 主に個人向けウェブサービスを開発運営している会社
    • ホスティング / EC支援 / ハンドメイド
    • 多数のサービスを事業部制で開発
    • サービスごとにインフラやアーキテクチャが異なる = データソースが多様
    • いくつかの事業部で特に「データ駆動」に注力
    • DX Criteriaの実践とその活用について - ペパボテックブログ
    https://tech.pepabo.com/2020/02/19/dx-criteria/
    GMOペパボ

    View full-size slide

  6. • 日本 CTO 協会が作成したアセスメントツール
    • DX の進捗度を自己診断できる
    • 5 つのテーマのうちの 1 つが「データ駆動」
    GMOペパボについて
    6
    DX Criteria とデータ駆動
    日本CTO協会 DX Criteria ver.201912
    https://github.com/cto-a/dxcriteria/blob/master/asset/image/dxcriteria201912.pdf

    View full-size slide

  7. GMOペパボについて
    • マーケティング自動化
    • データを元にサービスの振る舞いを変える、サービスの動的改善
    • 例)ECサイトのカゴ落ちメール
    • 意思決定の自動化
    • 意思決定に必要な指標を計測可能・明確・非属人的にして自動化を可能にする
    • 例)統計的な判断
    • 意思決定後のシステム挙動の変更も自動化する
    • 例)バンディットアルゴリズム
    ➡ 提供するサービスをデータ駆動によってより良くしていきたい
    7
    データ駆動によって目指すもの

    View full-size slide

  8. 8
    2. ペパボのデータ基盤
    「Bigfoot」

    View full-size slide

  9. • 実現を阻む一般的な課題
    • データを集める仕組みがない
    • 集めたデータを分析する仕組みやスキルがない
    • 分析したデータを活用する仕組みがない
    • いきなりデータ駆動にはなれないので
    ...
    ペパボのデータ基盤「Bigfoot」
    9
    データ駆動になるぞ!!!

    View full-size slide

  10. データ駆動になるための段階を整理する
    • 収集: データが出力され、取りまとめられている段階
    • 分析: 取りまとめたデータを可視化、一元的に分析できる段階
    • 活用: データにより継続的なサービス改善を行える段階
    ペパボのデータ基盤「Bigfoot」
    10
    収集
    分析
    活用
    段階

    View full-size slide

  11. • システム: データ活用の基盤とエコシステム
    • リテラシ: データの解釈と活用のためのリテラシ
    ペパボのデータ基盤「Bigfoot」
    11
    データ駆動の実現に必要なレイヤを整理する
    収集
    分析
    活用
    システム リテラシ
    段階

    View full-size slide

  12. ペパボのデータ基盤「Bigfoot」
    12
    各段階においてシステムとリテラシによるデータ駆動を目指す
    収集
    分析
    活用
    システム リテラシ データ駆動
    DWH
    Logger
    BI / Dashboard
    ワークフロー
    データ連携
    データ集計
    統計知識
    事業価値の理解
    統計的な判断
    機械学習基盤
    適応的改善機構
    情報推薦
    機械学習
    サービスの動的改善
    自動的な意思決定
    + =
    段階

    View full-size slide

  13. • 主にシステムレイヤの各要素を扱いやすくして
    サービスの動的な改善と意思決定の自動化をサポート
    ペパボのデータ基盤「Bigfoot」
    13
    Bigfoot によるエコシステムの提供範囲
    収集
    分析
    活用
    システム リテラシ データ駆動
    DWH
    Logger
    BI / Dashboard
    ワークフロー
    データ連携
    データ集計
    統計知識
    事業価値の理解
    統計的な判断
    機械学習基盤
    適応的改善機構
    情報推薦
    機械学習
    サービスの動的改善
    自動的な意思決定
    + =
    段階

    View full-size slide

  14. ペパボのデータ基盤「Bigfoot」
    14
    • 扱うデータ
    • ウェブサービスのユーザーの行動ログ / データベースの属性情報
    • 広告に関する指標
    • SNS の指標
    • 問い合わせのデータ etc...
    • 2016年に立ち上げ / 2020年に Google Cloud Platform に移設
    • ペパボのログ活用基盤「Bigfoot」を Google Cloud Platform に移設しました - ペパボ研究所ブログ
    https://rand.pepabo.com/article/2020/06/16/bigfoot-migration/
    Bigfoot の概要

    View full-size slide

  15. • Google Cloud Platform
    • Cloud Composer(ワークフローエンジン)
    • BigQuery(データレイク・データウェアハウス・データマート)
    • Cloud Storage(データレイク)
    • Cloud Dataflow / Google Kubernetes Engine(クエリで表現できないデータ加工)
    • AI Platform(機械学習)
    • AWS
    • AWS Batch, AWS Fargate(ELT バッチ実行)
    • 構成や IAM は Terraform でコード化
    • コードは GitHub Enterprise Server で管理 / GitHub Flow で開発
    ペパボのデータ基盤「Bigfoot」の概要
    15
    主なコンポーネントなど

    View full-size slide

  16. ペパボのデータ基盤「Bigfoot」の概要
    16
    Data source
    logs
    metrics
    GitHub issues
    databases
    Collect data
    tbls
    datasets
    BigQuery
    bigfoot/platform
    Cloud Storage
    - Permissions
    - Datasets
    - Buckets
    Data Studio
    bigfoot/cloud-composer
    Cloud Composer
    dags/
    tbls-build
    base tbls.yml
    files
    patch files
    ( *.yml, *.json )
    patched tbls.yml
    files
    tbls-meta
    tbls
    data catalog
    Apply
    metadata
    Generate
    & Commit
    Generate
    schema.json
    & commit
    bigfoot/data-catalog
    Update
    metadata
    & commit
    Spread sheet
    View
    Send analysis results
    Colaboratory

    View full-size slide

  17. • ELT パイプラインの構成, ログ設計は定型化
    • 知識のサイロ化を防いでベストプラクティスを複数のサービスで使い回す
    • DB からの ELT は主に Embulk
    • 広告や問い合わせプラットフォームからの ELT には一部 SaaS を利用
    • データソースが多いので開発と運用の負荷を下げる
    ペパボのデータ基盤「Bigfoot」の概要
    17
    収集の方法と工夫

    View full-size slide

  18. • 数行の設定でサービスアプリケーションの通信内容からユーザーの行動ログを
    取り出す Rack ミドルウェアや PHP ライブラリを用意
    • 各サービスでエンジニアがログ設計や収集を意識しなくても良い
    ペパボのデータ基盤「Bigfoot」の概要
    18
    rack-bigfoot / php-bigfoot
    サービスに寄り添うログ基盤
    https://speakerdeck.com/monochromegane/pepabo-log-infrastructure-bigfoot

    View full-size slide

  19. • データの加工はワークフローエンジンに定義されたコードを通して行う
    • BigQuery のクエリ実行, Dataflow のジョブ実行, GKE の Pod 内の処理などで加工
    • 分析者がデータを使いやすいようにドキュメンテーションの仕組みを用意
    • ドキュメントも Git リポジトリで管理
    • k1LoW/tbls で BigQuery のメタデータと同期
    • https://github.com/k1LoW/tbls
    • ダッシュボードは主に Google Data Studio
    • DWH への SQL クライアントとして redash, metabase を用意
    • エンジニア, 非エンジニア問わず各事業部のパートナーがデータを利用
    ペパボのデータ基盤「Bigfoot」の概要
    19
    分析の方法と工夫

    View full-size slide

  20. • 分析結果を元に仮説を立ててシステム改修を行う
    • 例)ウェブサイトやアプリの画面デザインの変更や遷移の見直し
    • 静的フィードバック
    • データやモデルによってサービスを動的に改善する
    • 例)バンディットアルゴリズム / レコメンデーション
    • 動的フィードバック
    ➡ サービスへの動的フィードバックが増えるほど改善がスケールする
    ➡ 具体例は後のセクションでお話しします!
    ペパボのデータ基盤「Bigfoot」の概要
    20
    活用の方法と工夫

    View full-size slide

  21. 3. ワークフローエンジン
    「Airflow」を使う上での工夫
    21

    View full-size slide

  22. • "Airflow is a platform created by the community to programmatically author,
    schedule and monitor workflows." ( https://airflow.apache.org/ )
    • Python のコードでワークフロー (DAG / 有向非巡回グラフ) を柔軟に表現できる
    • タスクのテンプレート = Operator が豊富
    • GCP / AWS の各サービスを操作する Operator など
    • 既存で Operator が用意されていない場合は Custom Operator を作成可能
    • GCP では Cloud Composer, AWS では Amazon Managed Workflows for Apache
    Airflow (MWAA) として提供されている
    ワークフローエンジン「Airflow」を使う上での工夫
    22
    Airflow とは

    View full-size slide

  23. スケジューリングの工夫
    • Airflow はスケジュールの概念が独特
    • execution_date + interval が実際の実行時刻
    • start_date (初回の execution_date) と interval を指定
    • デプロイ時点で start_date が過去であれば即時実行 / 未来であれば該当時刻に実行
    • 2回目以降は最後の execution_date + interval ごとに実行
    • start_date が過去の DAG やスケジュール外で手動実行した DAG はスケジュールがずれる
    • なので、
    • 実際の初回実行時刻と interval でスケジュール管理可能なクラスを作成
    • start_date が過去の場合デプロイ出来ないように制御
    • スケジュール実行用の DAG と手動実行用の DAG を自動生成
    interval 24h
    ワークフローエンジン「Airflow」を使う上での工夫
    23

    2021/01/01 00:00:00
    "execution_date"

    2021/01/02 00:00:00
    実際の実行時刻

    View full-size slide

  24. ワークフローエンジン「Airflow」を使う上での工夫
    • 基本的な設定の標準化
    • タイムアウト、自動バックフィルの禁止、並列実行の制限、完了時の Slack 通知など
    • 他の DAG を待ち受ける場合は依存先 の execution_date を自動計算する
    • DWH への結果の書き込みを自動的に冪等にする
    • 実際の Cloud Composer 環境と DWH を使って DAG 実行を試せる CI 環境
    ➡ データパイプラインでよくある処理や考慮が必要な部分は基盤側で用意しておく
    ➡ ワークフローを気軽に試せるようにしておく
    24
    社内ユーザーがタスクの中身に集中するための工夫

    View full-size slide

  25. ワークフローエンジン「Airflow」を使う上での工夫
    • ワークフローのデプロイはちょっとだけ面倒
    • 追加 / 更新の場合はストレージにファイルを配置 / 変更する
    • ただしタスクの構造やスケジュールが変わる場合は別の DAG にする
    • 削除の場合はストレージからファイルを削除して DB を更新する
    • デプロイツールを開発
    • Go製(ポータビリティ, 並列可能な処理)
    • 差分検出だけでも利用可能
    • GitHub Actions を活用
    • デプロイ, 環境の作成や更新などを自動化
    • 平日だけテスト環境を作成してコスト節約
    25
    運用の工夫
    trinity で Cloud Composer にワークフローを簡単デプロイ
    https://speakerdeck.com/zaimy/easy-workflow-deployment-to-cloud-composer-with-trinity

    View full-size slide

  26. • 基本的に「最新が最高」なので積極的に上げ続ける
    • とはいえ他の開発運用もあるので現状は「 Cloud Composer のデフォルトに追従」
    • Airflow 2 系が in preview
    • GA を待望しています!
    ワークフローエンジン「Airflow」を使う上での工夫
    26
    Airflow のバージョンアップ戦略 (1) - タイミング
    Cloud Composer version list | Google Cloud
    https://cloud.google.com/composer/docs/concepts/versioning/composer-versions

    View full-size slide

  27. • バージョンアップ用の検証環境でスケジュール実行を含めて機能検証
    • 普段 CI で使っているテスト環境ではスケジュール実行はなし
    • 特定バージョンでスケジュール実行の execution_date が
    数十秒ずつズレる問題にあたったことがある
    • 検証用の環境の立ち上げ, データコピーなど含めて手順はスクリプト化
    ワークフローエンジン「Airflow」を使う上での工夫
    27
    Airflow のバージョンアップ戦略 (2) - 検証

    View full-size slide

  28. • バージョンアップの際は Cloud Composer 環境の再作成が必要
    • inplace upgrade が現在 beta
    • 現行環境を停止して新環境に DAG をデプロイ?
    • 従来はこの方法で素朴にバージョンアップ
    • 切り替え当日に人間がオペレーションするため DAG を実行できない時間が生じる
    • デプロイ前に CI で全 DAG をテスト実行することになる
    • 仮に障害が発生した場合も切り戻しまで時間が掛かる
    • 同一のコードで各バージョンに適合した DAG を生成すると複雑化する
    • 結構大変
    ワークフローエンジン「Airflow」を使う上での工夫
    28
    Airflow のバージョンアップ戦略 (3) - 従来のバージョンアップ方法

    View full-size slide

  29. • 現行バージョンの本番環境と新バージョンの本番環境を用意
    • Git Branch を分けてブランチごとに各環境にデプロイ
    • 新バージョンの本番環境の DAG には切り替え時刻以降の start_date を設定
    • 現行バージョンの本番環境の DAG には切り替え時刻までの end_date を設定
    • 切り戻す場合は現行バージョン用のブランチに修正を加えて実行を再開
    ➡ コードが複雑化しない
    ➡ 事前にデプロイが可能なので切り替え当日の人間のオペレーションが不要
    ➡ DAG を実行できない時間帯が存在しない
    ワークフローエンジン「Airflow」を使う上での工夫
    29
    Airflow のバージョンアップ戦略 (4) - 現在のバージョンアップ手順

    View full-size slide

  30. 4. データ基盤を使った実例
    30

    View full-size slide

  31. データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops
    まずはシンプルな集計
    • Bigfoot にデータを集めることで統一的に集計
    • 統一された KPI 定義によるデータマートとダッシュボード(社内向け)
    • 作品ページのアクセス解析機能(ユーザー向け)
    • オウンドメディアの記事のアクセスランキング(ユーザー向け)
    31
    静的フィードバック
    収集
    分析
    活用
    システム リテラシ データ駆動
    DWH
    Logger
    BI / Dashboard
    ワークフロー
    データ連携
    データ集計
    統計知識
    事業価値の理解
    統計的な判断
    機械学習基盤
    適応的改善機構
    情報推薦
    機械学習
    サービスの動的改善
    自動的な意思決定
    + =
    段階

    View full-size slide

  32. • 行動ログから離脱ユーザーを抽出するワークフローを作成
    • 作品をカートに入れたが買わなかったユーザー
    • 同じ作品を何度も見ているユーザー
    • ワークフローの処理結果を minne のアプリケーションに取り込み
    該当ユーザーに対してプッシュ通知やメールを配信
    • 高い開封率と注文率
    データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops
    32
    離脱ユーザーへのリテンション 動的フィードバック
    収集
    分析
    活用
    システム リテラシ データ駆動
    DWH
    Logger
    BI / Dashboard
    ワークフロー
    データ連携
    データ集計
    統計知識
    事業価値の理解
    統計的な判断
    機械学習基盤
    適応的改善機構
    情報推薦
    機械学習
    サービスの動的改善
    自動的な意思決定
    + =
    段階

    View full-size slide

  33. • 協調フィルタリングをワークフローで行う
    • 似たユーザー行動の人が好む作家をクエリで得点付け
    • 結果を minne のアプリケーションが取り込んでユーザーに提示
    • 提示されたレコメンドリストに対するユーザーの行動が Bigfoot に戻ってくる
    • 比較的シンプルなモデルなので Cloud Composer だけで運用
    データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops
    33
    レコメンデーション 動的フィードバック
    収集
    分析
    活用
    システム リテラシ データ駆動
    DWH
    Logger
    BI / Dashboard
    ワークフロー
    データ連携
    データ集計
    統計知識
    事業価値の理解
    統計的な判断
    機械学習基盤
    適応的改善機構
    情報推薦
    機械学習
    サービスの動的改善
    自動的な意思決定
    + =
    段階

    View full-size slide

  34. • 静的な A/B テストは機会損失が生じる
    • 既存の A パターンより新規の B パターンの性能が悪い可能性
    • 作品検索は売上に与える影響が大きいため機会損失を防ぎながら改善を行いたい
    • Epsilon-Greedy アルゴリズムの例
    • 探索と活用: 確率 ε, (1-ε) でランダムに選択した / 期待値最大のアルゴリズムを使用
    • 行動ログから結果の期待値を更新
    データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops
    34
    バンディットアルゴリズムによる推薦, 作品検索の改善 動的フィードバック
    収集
    分析
    活用
    システム リテラシ データ駆動
    DWH
    Logger
    BI / Dashboard
    ワークフロー
    データ連携
    データ集計
    統計知識
    事業価値の理解
    統計的な判断
    機械学習基盤
    適応的改善機構
    情報推薦
    機械学習
    サービスの動的改善
    自動的な意思決定
    + =
    段階

    View full-size slide

  35. システム リテラシ データ駆動
    DWH
    Logger
    BI / Dashboard
    ワークフロー
    データ連携
    データ集計
    統計知識
    事業価値の理解
    統計的な判断
    機械学習基盤
    適応的改善機構
    情報推薦
    機械学習
    サービスの動的改善
    自動的な意思決定
    • 大量生産品をハンドメイドと偽る出品者が存在
    • ブランドイメージの毀損や信頼性低下に繋がるため作品の削除などが必要
    • 商品名, 商品説明文, 商品画像など従来の属性情報のみから検出することが困難
    • Bigfoot に統合されたデータから古典的機械学習で候補検出
    財津 大夏, 三宅 悠介, 松本 亮介, ハンドメイド作品を対象とした ECサイトにおける大量生産品の検出 ,
    研究報告インターネットと運用技術( IOT), Vol.2018-IOT-41, pp.1-8, May 2018. [論文] [発表資料]
    データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops
    35
    大量生産品の出品者の候補検出 静的フィードバック ML
    収集
    分析
    活用
    + =
    段階

    View full-size slide

  36. • 処理性能を保ちつつ必要最小限のサーバーで運用する
    • 行動ログからアクセス傾向をモデル化して台数を自動制御
    • クラウドサービス利用料金を 2分の1に抑制した
    • モデルは TensorFlow で開発、AI Platform で API 化
    三宅 悠介, 松本 亮介, 力武 健次, 栗林 健太郎, アクセス頻度予測に基づく仮想サーバの計画的オートスケーリング ,
    情報科学技術フォーラム講演論文集 , Vol.17, No.4, pp.7-12, Sep 2018. [論文] [発表資料]
    データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops
    36
    サーバーの計画的オートスケーリング 動的フィードバック ML
    収集
    分析
    活用
    システム リテラシ データ駆動
    DWH
    Logger
    BI / Dashboard
    ワークフロー
    データ連携
    データ集計
    統計知識
    事業価値の理解
    統計的な判断
    機械学習基盤
    適応的改善機構
    情報推薦
    機械学習
    サービスの動的改善
    自動的な意思決定
    + =
    段階

    View full-size slide

  37. • ソフトウェア開発チームのパフォーマンスを示す指標
    • デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
    • 変更のリードタイム - commit から本番環境稼働までの所要時間
    • 変更障害率 - デプロイが原因で本番環境で障害が発生する割合( %)
    • サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
    データ基盤を使った実例 - 社内の生産性指標の計測
    37
    Four Keys
    エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog
    https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

    View full-size slide

  38. • デプロイの頻度 - Heroku のリリース数 / GitHub Enterprise のマージ数
    • 変更のリードタイム - GitHub Enterprise の平均マージ時間
    • 変更障害率 - デプロイとユーザーの行動ログ
    • サービス復元時間 - 障害やインシデント対応の BotOps のログ
    データ基盤を使った実例 - 社内の生産性指標の計測
    38
    Four Keys のデータソース - SUZURI の場合

    View full-size slide

  39. • それぞれ Extract のためのコマンドラインツールを開発
    • GHES は Issue, Comment, User, Label, IssueEvent, Release, Commit に対応
    • Rust 製, ワンバイナリ
    • updated_at で期間指定可能
    • 差分更新に対応
    • CSV だけを出力する
    • Load は Embulk や gsutil, bq に任せる
    データ基盤を使った実例 - 社内の生産性指標の計測
    39
    Four Keys の抽出方法 - Heroku のリリースログ, GitHub Enterprise
    udzura/octx: GitHub query & extracter (Enterprise ready)
    https://github.com/udzura/octx

    View full-size slide

  40. • SUZURI にはサービスアプリケーションの通信内容から行動ログを取り出す
    Rack ミドルウェアを導入済み
    • 失敗したリクエストを集計する
    データ基盤を使った実例 - 社内の生産性指標の計測
    40
    Four Keys の抽出方法 - ユーザーの行動ログ
    サービスに寄り添うログ基盤
    https://speakerdeck.com/monochromegane/pepabo-log-infrastructure-bigfoot

    View full-size slide

  41. • ペパボでは障害やインシデント対応が Slack bot を使って標準化されている
    • 対応内容が bot の DB に記録されている
    • Bigfoot へ ELT して利用
    データ基盤を使った実例 - 社内の生産性指標の計測
    41
    Four Keys の抽出方法 - 障害やインシデント対応の BotOps のログ
    Co3で支えるペパボのセキュリティ対策〜 Communication Completely Continuous〜
    https://tech.pepabo.com/pdf/pepabo-tech-conference-14-security-team-slide.pdf

    View full-size slide

  42. データ基盤を使った実例 - 社内の生産性指標の計測
    • SUZURI, Bigfoot(基盤チーム)の指標を計測可能な状態になっている
    • Google Data Studio で可視化が進行中
    • マージとデプロイ回数の乖離が少なくて良さそう etc...
    • 運用はこれから!
    • 他事業部への展開もやっていく
    42
    Four Keys の可視化・活用

    View full-size slide

  43. 5. データ基盤の今後
    43

    View full-size slide

  44. 44
    データ基盤の今後
    • ロードされたデータのドキュメンテーションは進んでいる
    • 例)RDBMS の個別のテーブル, カラムの意味は Bigfoot で確認可能
    • データ加工のパイプラインの可視化も進んでいる
    • パイプラインによって加工されたデータの意味づけがまだ不足
    • 上流のデータがどこから来たデータなのか?誰が作ったデータなのか?
    • データの作成に失敗した際の影響範囲は?
    • 現状はパイプラインの実装やアーキテクチャを読み解く必要がある
    • ELT など上流のコンポーネントや Airflow の運用障害で一定量の DAG が失敗すると
    影響範囲の特定がとても大変
    ➡ データリネージとデータガバナンスへの取り組み
    データリネージとデータガバナンス

    View full-size slide

  45. 45
    データ基盤の今後
    • 現在は ML に関連するパイプラインが統一されていない
    • 研究所で作られたモデルごとに当時の最適な方法で本番に適用されている
    • 実装が Cloud Composer のパイプライン, AI Platform, Notebook などに分散
    • データとモデルの管理方法もまちまち
    • 実装とデータとモデルを一元的に管理する基盤が必要
    • データガバナンスやデータリネージに当たる部分もある
    • 一方で、パラメータ管理やモデル管理など ML 独特の課題もある
    • Vertex AI Pipelines や Kubeflow Pipelines を検討中
    ➡ 実装とデータとモデルの管理は Bigfoot に任せて課題解決に集中できるように
    ML Ops

    View full-size slide

  46. 46
    Thank You!
    ご静聴ありがとうございました
    資料は https://speakerdeck.com/zaimy/ に公開しています

    View full-size slide