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

2021.09.17 GMO Developers Day
https://developers.gmo.jp/developersday

https://www.youtube.com/watch?v=Kxlchi9fa3I

Transcript

1. GMOペパボのサービスと 研究開発を支える データ基盤の裏側 財津大夏 / GMO PEPABO inc. 2021.09.17 GMO Developer Days 2021 1
2. • ペパボのデータ基盤「Bigfoot」の開発運用 • ECサイトのユーザー行動を用いた研究 • Twitter : @HirokaZaitsu #データ基盤 #DataOps #MLOps #Python #SQL #統計学 #機械学習 2 自己紹介 CTO室 研究開発チーム / 技術部 データ基盤チーム 2012年 入社 財津 大夏 Zaitsu Hiroka
3. 3 1. GMOペパボについて 2. ペパボのデータ基盤「Bigfoot」 3. ワークフローエンジン「Airflow」を使う上での工夫 4. データ基盤を使った実例 • ハンドメイドマーケット「minne」でのデータ活用とML Ops • 社内の生産性指標の計測 5. データ基盤の今後 アジェンダ
4. 1. GMOペパボについて 4
5. GMOペパボについて 5 • 主に個人向けウェブサービスを開発運営している会社 • ホスティング / EC支援 / ハンドメイド • 多数のサービスを事業部制で開発 • サービスごとにインフラやアーキテクチャが異なる = データソースが多様 • いくつかの事業部で特に「データ駆動」に注力 • DX Criteriaの実践とその活用について - ペパボテックブログ https://tech.pepabo.com/2020/02/19/dx-criteria/ GMOペパボ
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
7. GMOペパボについて • マーケティング自動化 • データを元にサービスの振る舞いを変える、サービスの動的改善 • 例）ECサイトのカゴ落ちメール • 意思決定の自動化 • 意思決定に必要な指標を計測可能・明確・非属人的にして自動化を可能にする • 例）統計的な判断 • 意思決定後のシステム挙動の変更も自動化する • 例）バンディットアルゴリズム ➡ 提供するサービスをデータ駆動によってより良くしていきたい 7 データ駆動によって目指すもの
8. 8 2. ペパボのデータ基盤 「Bigfoot」
9. • 実現を阻む一般的な課題 • データを集める仕組みがない • 集めたデータを分析する仕組みやスキルがない • 分析したデータを活用する仕組みがない • いきなりデータ駆動にはなれないので ... ペパボのデータ基盤「Bigfoot」 9 データ駆動になるぞ！！！
10. データ駆動になるための段階を整理する • 収集: データが出力され、取りまとめられている段階 • 分析: 取りまとめたデータを可視化、一元的に分析できる段階 • 活用: データにより継続的なサービス改善を行える段階 ペパボのデータ基盤「Bigfoot」 10 収集 分析 活用 段階
11. • システム: データ活用の基盤とエコシステム • リテラシ: データの解釈と活用のためのリテラシ ペパボのデータ基盤「Bigfoot」 11 データ駆動の実現に必要なレイヤを整理する 収集 分析 活用 システム リテラシ 段階
12. ペパボのデータ基盤「Bigfoot」 12 各段階においてシステムとリテラシによるデータ駆動を目指す 収集 分析 活用 システム リテラシ データ駆動 DWH Logger BI / Dashboard ワークフロー データ連携 データ集計 統計知識 事業価値の理解 統計的な判断 機械学習基盤 適応的改善機構 情報推薦 機械学習 サービスの動的改善 自動的な意思決定 ＋ ＝ 段階
13. • 主にシステムレイヤの各要素を扱いやすくして サービスの動的な改善と意思決定の自動化をサポート ペパボのデータ基盤「Bigfoot」 13 Bigfoot によるエコシステムの提供範囲 収集 分析 活用 システム リテラシ データ駆動 DWH Logger BI / Dashboard ワークフロー データ連携 データ集計 統計知識 事業価値の理解 統計的な判断 機械学習基盤 適応的改善機構 情報推薦 機械学習 サービスの動的改善 自動的な意思決定 ＋ ＝ 段階
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 の概要
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 主なコンポーネントなど
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
17. • ELT パイプラインの構成, ログ設計は定型化 • 知識のサイロ化を防いでベストプラクティスを複数のサービスで使い回す • DB からの ELT は主に Embulk • 広告や問い合わせプラットフォームからの ELT には一部 SaaS を利用 • データソースが多いので開発と運用の負荷を下げる ペパボのデータ基盤「Bigfoot」の概要 17 収集の方法と工夫
18. • 数行の設定でサービスアプリケーションの通信内容からユーザーの行動ログを 取り出す Rack ミドルウェアや PHP ライブラリを用意 • 各サービスでエンジニアがログ設計や収集を意識しなくても良い ペパボのデータ基盤「Bigfoot」の概要 18 rack-bigfoot / php-bigfoot サービスに寄り添うログ基盤 https://speakerdeck.com/monochromegane/pepabo-log-infrastructure-bigfoot
19. • データの加工はワークフローエンジンに定義されたコードを通して行う • BigQuery のクエリ実行, Dataflow のジョブ実行, GKE の Pod 内の処理などで加工 • 分析者がデータを使いやすいようにドキュメンテーションの仕組みを用意 • ドキュメントも Git リポジトリで管理 • k1LoW/tbls で BigQuery のメタデータと同期 • https://github.com/k1LoW/tbls • ダッシュボードは主に Google Data Studio • DWH への SQL クライアントとして redash, metabase を用意 • エンジニア, 非エンジニア問わず各事業部のパートナーがデータを利用 ペパボのデータ基盤「Bigfoot」の概要 19 分析の方法と工夫
20. • 分析結果を元に仮説を立ててシステム改修を行う • 例）ウェブサイトやアプリの画面デザインの変更や遷移の見直し • 静的フィードバック • データやモデルによってサービスを動的に改善する • 例）バンディットアルゴリズム / レコメンデーション • 動的フィードバック ➡ サービスへの動的フィードバックが増えるほど改善がスケールする ➡ 具体例は後のセクションでお話しします！ ペパボのデータ基盤「Bigfoot」の概要 20 活用の方法と工夫
21. 3. ワークフローエンジン 「Airflow」を使う上での工夫 21
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 とは
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 実際の実行時刻
24. ワークフローエンジン「Airflow」を使う上での工夫 • 基本的な設定の標準化 • タイムアウト、自動バックフィルの禁止、並列実行の制限、完了時の Slack 通知など • 他の DAG を待ち受ける場合は依存先 の execution_date を自動計算する • DWH への結果の書き込みを自動的に冪等にする • 実際の Cloud Composer 環境と DWH を使って DAG 実行を試せる CI 環境 ➡ データパイプラインでよくある処理や考慮が必要な部分は基盤側で用意しておく ➡ ワークフローを気軽に試せるようにしておく 24 社内ユーザーがタスクの中身に集中するための工夫
25. ワークフローエンジン「Airflow」を使う上での工夫 • ワークフローのデプロイはちょっとだけ面倒 • 追加 / 更新の場合はストレージにファイルを配置 / 変更する • ただしタスクの構造やスケジュールが変わる場合は別の DAG にする • 削除の場合はストレージからファイルを削除して DB を更新する • デプロイツールを開発 • Go製（ポータビリティ, 並列可能な処理） • 差分検出だけでも利用可能 • GitHub Actions を活用 • デプロイ, 環境の作成や更新などを自動化 • 平日だけテスト環境を作成してコスト節約 25 運用の工夫 trinity で Cloud Composer にワークフローを簡単デプロイ https://speakerdeck.com/zaimy/easy-workflow-deployment-to-cloud-composer-with-trinity
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
27. • バージョンアップ用の検証環境でスケジュール実行を含めて機能検証 • 普段 CI で使っているテスト環境ではスケジュール実行はなし • 特定バージョンでスケジュール実行の execution_date が 数十秒ずつズレる問題にあたったことがある • 検証用の環境の立ち上げ, データコピーなど含めて手順はスクリプト化 ワークフローエンジン「Airflow」を使う上での工夫 27 Airflow のバージョンアップ戦略 (2) - 検証
28. • バージョンアップの際は Cloud Composer 環境の再作成が必要 • inplace upgrade が現在 beta • 現行環境を停止して新環境に DAG をデプロイ？ • 従来はこの方法で素朴にバージョンアップ • 切り替え当日に人間がオペレーションするため DAG を実行できない時間が生じる • デプロイ前に CI で全 DAG をテスト実行することになる • 仮に障害が発生した場合も切り戻しまで時間が掛かる • 同一のコードで各バージョンに適合した DAG を生成すると複雑化する • 結構大変 ワークフローエンジン「Airflow」を使う上での工夫 28 Airflow のバージョンアップ戦略 (3) - 従来のバージョンアップ方法
29. • 現行バージョンの本番環境と新バージョンの本番環境を用意 • Git Branch を分けてブランチごとに各環境にデプロイ • 新バージョンの本番環境の DAG には切り替え時刻以降の start_date を設定 • 現行バージョンの本番環境の DAG には切り替え時刻までの end_date を設定 • 切り戻す場合は現行バージョン用のブランチに修正を加えて実行を再開 ➡ コードが複雑化しない ➡ 事前にデプロイが可能なので切り替え当日の人間のオペレーションが不要 ➡ DAG を実行できない時間帯が存在しない ワークフローエンジン「Airflow」を使う上での工夫 29 Airflow のバージョンアップ戦略 (4) - 現在のバージョンアップ手順
30. 4. データ基盤を使った実例 30
31. データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops まずはシンプルな集計 • Bigfoot にデータを集めることで統一的に集計 • 統一された KPI 定義によるデータマートとダッシュボード（社内向け） • 作品ページのアクセス解析機能（ユーザー向け） • オウンドメディアの記事のアクセスランキング（ユーザー向け） 31 静的フィードバック 収集 分析 活用 システム リテラシ データ駆動 DWH Logger BI / Dashboard ワークフロー データ連携 データ集計 統計知識 事業価値の理解 統計的な判断 機械学習基盤 適応的改善機構 情報推薦 機械学習 サービスの動的改善 自動的な意思決定 ＋ ＝ 段階
32. • 行動ログから離脱ユーザーを抽出するワークフローを作成 • 作品をカートに入れたが買わなかったユーザー • 同じ作品を何度も見ているユーザー • ワークフローの処理結果を minne のアプリケーションに取り込み 該当ユーザーに対してプッシュ通知やメールを配信 • 高い開封率と注文率 データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops 32 離脱ユーザーへのリテンション 動的フィードバック 収集 分析 活用 システム リテラシ データ駆動 DWH Logger BI / Dashboard ワークフロー データ連携 データ集計 統計知識 事業価値の理解 統計的な判断 機械学習基盤 適応的改善機構 情報推薦 機械学習 サービスの動的改善 自動的な意思決定 ＋ ＝ 段階
33. • 協調フィルタリングをワークフローで行う • 似たユーザー行動の人が好む作家をクエリで得点付け • 結果を minne のアプリケーションが取り込んでユーザーに提示 • 提示されたレコメンドリストに対するユーザーの行動が Bigfoot に戻ってくる • 比較的シンプルなモデルなので Cloud Composer だけで運用 データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops 33 レコメンデーション 動的フィードバック 収集 分析 活用 システム リテラシ データ駆動 DWH Logger BI / Dashboard ワークフロー データ連携 データ集計 統計知識 事業価値の理解 統計的な判断 機械学習基盤 適応的改善機構 情報推薦 機械学習 サービスの動的改善 自動的な意思決定 ＋ ＝ 段階
34. • 静的な A/B テストは機会損失が生じる • 既存の A パターンより新規の B パターンの性能が悪い可能性 • 作品検索は売上に与える影響が大きいため機会損失を防ぎながら改善を行いたい • Epsilon-Greedy アルゴリズムの例 • 探索と活用: 確率 ε, (1-ε) でランダムに選択した / 期待値最大のアルゴリズムを使用 • 行動ログから結果の期待値を更新 データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops 34 バンディットアルゴリズムによる推薦, 作品検索の改善 動的フィードバック 収集 分析 活用 システム リテラシ データ駆動 DWH Logger BI / Dashboard ワークフロー データ連携 データ集計 統計知識 事業価値の理解 統計的な判断 機械学習基盤 適応的改善機構 情報推薦 機械学習 サービスの動的改善 自動的な意思決定 ＋ ＝ 段階
35. システム リテラシ データ駆動 DWH Logger BI / Dashboard ワークフロー データ連携 データ集計 統計知識 事業価値の理解 統計的な判断 機械学習基盤 適応的改善機構 情報推薦 機械学習 サービスの動的改善 自動的な意思決定 • 大量生産品をハンドメイドと偽る出品者が存在 • ブランドイメージの毀損や信頼性低下に繋がるため作品の削除などが必要 • 商品名, 商品説明文, 商品画像など従来の属性情報のみから検出することが困難 • Bigfoot に統合されたデータから古典的機械学習で候補検出 財津 大夏, 三宅 悠介, 松本 亮介, ハンドメイド作品を対象とした ECサイトにおける大量生産品の検出 , 研究報告インターネットと運用技術（ IOT）, Vol.2018-IOT-41, pp.1-8, May 2018. [論文] [発表資料] データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops 35 大量生産品の出品者の候補検出 静的フィードバック ML 収集 分析 活用 ＋ ＝ 段階
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 ワークフロー データ連携 データ集計 統計知識 事業価値の理解 統計的な判断 機械学習基盤 適応的改善機構 情報推薦 機械学習 サービスの動的改善 自動的な意思決定 ＋ ＝ 段階
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
38. • デプロイの頻度 - Heroku のリリース数 / GitHub Enterprise のマージ数 • 変更のリードタイム - GitHub Enterprise の平均マージ時間 • 変更障害率 - デプロイとユーザーの行動ログ • サービス復元時間 - 障害やインシデント対応の BotOps のログ データ基盤を使った実例 - 社内の生産性指標の計測 38 Four Keys のデータソース - SUZURI の場合
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
40. • SUZURI にはサービスアプリケーションの通信内容から行動ログを取り出す Rack ミドルウェアを導入済み • 失敗したリクエストを集計する データ基盤を使った実例 - 社内の生産性指標の計測 40 Four Keys の抽出方法 - ユーザーの行動ログ サービスに寄り添うログ基盤 https://speakerdeck.com/monochromegane/pepabo-log-infrastructure-bigfoot
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
42. データ基盤を使った実例 - 社内の生産性指標の計測 • SUZURI, Bigfoot（基盤チーム）の指標を計測可能な状態になっている • Google Data Studio で可視化が進行中 • マージとデプロイ回数の乖離が少なくて良さそう etc... • 運用はこれから！ • 他事業部への展開もやっていく 42 Four Keys の可視化・活用
43. 5. データ基盤の今後 43
44. 44 データ基盤の今後 • ロードされたデータのドキュメンテーションは進んでいる • 例）RDBMS の個別のテーブル, カラムの意味は Bigfoot で確認可能 • データ加工のパイプラインの可視化も進んでいる • パイプラインによって加工されたデータの意味づけがまだ不足 • 上流のデータがどこから来たデータなのか？誰が作ったデータなのか？ • データの作成に失敗した際の影響範囲は？ • 現状はパイプラインの実装やアーキテクチャを読み解く必要がある • ELT など上流のコンポーネントや Airflow の運用障害で一定量の DAG が失敗すると 影響範囲の特定がとても大変 ➡ データリネージとデータガバナンスへの取り組み データリネージとデータガバナンス
45. 45 データ基盤の今後 • 現在は ML に関連するパイプラインが統一されていない • 研究所で作られたモデルごとに当時の最適な方法で本番に適用されている • 実装が Cloud Composer のパイプライン, AI Platform, Notebook などに分散 • データとモデルの管理方法もまちまち • 実装とデータとモデルを一元的に管理する基盤が必要 • データガバナンスやデータリネージに当たる部分もある • 一方で、パラメータ管理やモデル管理など ML 独特の課題もある • Vertex AI Pipelines や Kubeflow Pipelines を検討中 ➡ 実装とデータとモデルの管理は Bigfoot に任せて課題解決に集中できるように ML Ops
46. 46 Thank You! ご静聴ありがとうございました 資料は https://speakerdeck.com/zaimy/ に公開しています