2021.09.17 GMO Developers Day https://developers.gmo.jp/developersday
https://www.youtube.com/watch?v=Kxlchi9fa3I
GMOペパボのサービスと研究開発を支えるデータ基盤の裏側財津大夏 / GMO PEPABO inc.2021.09.17 GMO Developer Days 20211
View Slide
● ペパボのデータ基盤「Bigfoot」の開発運用● ECサイトのユーザー行動を用いた研究● Twitter : @HirokaZaitsu#データ基盤 #DataOps #MLOps #Python #SQL#統計学 #機械学習2自己紹介CTO室 研究開発チーム / 技術部 データ基盤チーム2012年 入社財津 大夏 Zaitsu Hiroka
31. GMOペパボについて2. ペパボのデータ基盤「Bigfoot」3. ワークフローエンジン「Airflow」を使う上での工夫4. データ基盤を使った実例• ハンドメイドマーケット「minne」でのデータ活用とML Ops• 社内の生産性指標の計測5. データ基盤の今後アジェンダ
1. GMOペパボについて4
GMOペパボについて5• 主に個人向けウェブサービスを開発運営している会社• ホスティング / EC支援 / ハンドメイド• 多数のサービスを事業部制で開発• サービスごとにインフラやアーキテクチャが異なる = データソースが多様• いくつかの事業部で特に「データ駆動」に注力• DX Criteriaの実践とその活用について - ペパボテックブログhttps://tech.pepabo.com/2020/02/19/dx-criteria/GMOペパボ
• 日本 CTO 協会が作成したアセスメントツール• DX の進捗度を自己診断できる• 5 つのテーマのうちの 1 つが「データ駆動」GMOペパボについて6DX Criteria とデータ駆動日本CTO協会 DX Criteria ver.201912https://github.com/cto-a/dxcriteria/blob/master/asset/image/dxcriteria201912.pdf
GMOペパボについて• マーケティング自動化• データを元にサービスの振る舞いを変える、サービスの動的改善• 例）ECサイトのカゴ落ちメール• 意思決定の自動化• 意思決定に必要な指標を計測可能・明確・非属人的にして自動化を可能にする• 例）統計的な判断• 意思決定後のシステム挙動の変更も自動化する• 例）バンディットアルゴリズム➡ 提供するサービスをデータ駆動によってより良くしていきたい7データ駆動によって目指すもの
82. ペパボのデータ基盤「Bigfoot」
• 実現を阻む一般的な課題• データを集める仕組みがない• 集めたデータを分析する仕組みやスキルがない• 分析したデータを活用する仕組みがない• いきなりデータ駆動にはなれないので...ペパボのデータ基盤「Bigfoot」9データ駆動になるぞ！！！
データ駆動になるための段階を整理する• 収集: データが出力され、取りまとめられている段階• 分析: 取りまとめたデータを可視化、一元的に分析できる段階• 活用: データにより継続的なサービス改善を行える段階ペパボのデータ基盤「Bigfoot」10収集分析活用段階
• システム: データ活用の基盤とエコシステム• リテラシ: データの解釈と活用のためのリテラシペパボのデータ基盤「Bigfoot」11データ駆動の実現に必要なレイヤを整理する収集分析活用システム リテラシ段階
ペパボのデータ基盤「Bigfoot」12各段階においてシステムとリテラシによるデータ駆動を目指す収集分析活用システム リテラシ データ駆動DWHLoggerBI / Dashboardワークフローデータ連携データ集計統計知識事業価値の理解統計的な判断機械学習基盤適応的改善機構情報推薦機械学習サービスの動的改善自動的な意思決定＋ ＝段階
• 主にシステムレイヤの各要素を扱いやすくしてサービスの動的な改善と意思決定の自動化をサポートペパボのデータ基盤「Bigfoot」13Bigfoot によるエコシステムの提供範囲収集分析活用システム リテラシ データ駆動DWHLoggerBI / Dashboardワークフローデータ連携データ集計統計知識事業価値の理解統計的な判断機械学習基盤適応的改善機構情報推薦機械学習サービスの動的改善自動的な意思決定＋ ＝段階
ペパボのデータ基盤「Bigfoot」14• 扱うデータ• ウェブサービスのユーザーの行動ログ / データベースの属性情報• 広告に関する指標• SNS の指標• 問い合わせのデータ etc...• 2016年に立ち上げ / 2020年に Google Cloud Platform に移設• ペパボのログ活用基盤「Bigfoot」を Google Cloud Platform に移設しました - ペパボ研究所ブログhttps://rand.pepabo.com/article/2020/06/16/bigfoot-migration/Bigfoot の概要
• 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主なコンポーネントなど
ペパボのデータ基盤「Bigfoot」の概要16Data sourcelogsmetricsGitHub issuesdatabasesCollect datatblsdatasetsBigQuerybigfoot/platformCloud Storage- Permissions- Datasets- BucketsData Studiobigfoot/cloud-composerCloud Composerdags/tbls-buildbase tbls.ymlfilespatch files( *.yml, *.json )patched tbls.ymlfilestbls-metatblsdata catalogApplymetadataGenerate& CommitGenerateschema.json& commitbigfoot/data-catalogUpdatemetadata& commitSpread sheetViewSend analysis resultsColaboratory
• ELT パイプラインの構成, ログ設計は定型化• 知識のサイロ化を防いでベストプラクティスを複数のサービスで使い回す• DB からの ELT は主に Embulk• 広告や問い合わせプラットフォームからの ELT には一部 SaaS を利用• データソースが多いので開発と運用の負荷を下げるペパボのデータ基盤「Bigfoot」の概要17収集の方法と工夫
• 数行の設定でサービスアプリケーションの通信内容からユーザーの行動ログを取り出す Rack ミドルウェアや PHP ライブラリを用意• 各サービスでエンジニアがログ設計や収集を意識しなくても良いペパボのデータ基盤「Bigfoot」の概要18rack-bigfoot / php-bigfootサービスに寄り添うログ基盤https://speakerdeck.com/monochromegane/pepabo-log-infrastructure-bigfoot
• データの加工はワークフローエンジンに定義されたコードを通して行う• BigQuery のクエリ実行, Dataflow のジョブ実行, GKE の Pod 内の処理などで加工• 分析者がデータを使いやすいようにドキュメンテーションの仕組みを用意• ドキュメントも Git リポジトリで管理• k1LoW/tbls で BigQuery のメタデータと同期• https://github.com/k1LoW/tbls• ダッシュボードは主に Google Data Studio• DWH への SQL クライアントとして redash, metabase を用意• エンジニア, 非エンジニア問わず各事業部のパートナーがデータを利用ペパボのデータ基盤「Bigfoot」の概要19分析の方法と工夫
• 分析結果を元に仮説を立ててシステム改修を行う• 例）ウェブサイトやアプリの画面デザインの変更や遷移の見直し• 静的フィードバック• データやモデルによってサービスを動的に改善する• 例）バンディットアルゴリズム / レコメンデーション• 動的フィードバック➡ サービスへの動的フィードバックが増えるほど改善がスケールする➡ 具体例は後のセクションでお話しします！ペパボのデータ基盤「Bigfoot」の概要20活用の方法と工夫
3. ワークフローエンジン「Airflow」を使う上での工夫21
• "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 ApacheAirflow (MWAA) として提供されているワークフローエンジン「Airflow」を使う上での工夫22Airflow とは
スケジューリングの工夫• 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実際の実行時刻
ワークフローエンジン「Airflow」を使う上での工夫• 基本的な設定の標準化• タイムアウト、自動バックフィルの禁止、並列実行の制限、完了時の Slack 通知など• 他の DAG を待ち受ける場合は依存先 の execution_date を自動計算する• DWH への結果の書き込みを自動的に冪等にする• 実際の Cloud Composer 環境と DWH を使って DAG 実行を試せる CI 環境➡ データパイプラインでよくある処理や考慮が必要な部分は基盤側で用意しておく➡ ワークフローを気軽に試せるようにしておく24社内ユーザーがタスクの中身に集中するための工夫
ワークフローエンジン「Airflow」を使う上での工夫• ワークフローのデプロイはちょっとだけ面倒• 追加 / 更新の場合はストレージにファイルを配置 / 変更する• ただしタスクの構造やスケジュールが変わる場合は別の DAG にする• 削除の場合はストレージからファイルを削除して DB を更新する• デプロイツールを開発• Go製（ポータビリティ, 並列可能な処理）• 差分検出だけでも利用可能• GitHub Actions を活用• デプロイ, 環境の作成や更新などを自動化• 平日だけテスト環境を作成してコスト節約25運用の工夫trinity で Cloud Composer にワークフローを簡単デプロイhttps://speakerdeck.com/zaimy/easy-workflow-deployment-to-cloud-composer-with-trinity
• 基本的に「最新が最高」なので積極的に上げ続ける• とはいえ他の開発運用もあるので現状は「 Cloud Composer のデフォルトに追従」• Airflow 2 系が in preview• GA を待望しています！ワークフローエンジン「Airflow」を使う上での工夫26Airflow のバージョンアップ戦略 (1) - タイミングCloud Composer version list | Google Cloudhttps://cloud.google.com/composer/docs/concepts/versioning/composer-versions
• バージョンアップ用の検証環境でスケジュール実行を含めて機能検証• 普段 CI で使っているテスト環境ではスケジュール実行はなし• 特定バージョンでスケジュール実行の execution_date が数十秒ずつズレる問題にあたったことがある• 検証用の環境の立ち上げ, データコピーなど含めて手順はスクリプト化ワークフローエンジン「Airflow」を使う上での工夫27Airflow のバージョンアップ戦略 (2) - 検証
• バージョンアップの際は Cloud Composer 環境の再作成が必要• inplace upgrade が現在 beta• 現行環境を停止して新環境に DAG をデプロイ？• 従来はこの方法で素朴にバージョンアップ• 切り替え当日に人間がオペレーションするため DAG を実行できない時間が生じる• デプロイ前に CI で全 DAG をテスト実行することになる• 仮に障害が発生した場合も切り戻しまで時間が掛かる• 同一のコードで各バージョンに適合した DAG を生成すると複雑化する• 結構大変ワークフローエンジン「Airflow」を使う上での工夫28Airflow のバージョンアップ戦略 (3) - 従来のバージョンアップ方法
• 現行バージョンの本番環境と新バージョンの本番環境を用意• Git Branch を分けてブランチごとに各環境にデプロイ• 新バージョンの本番環境の DAG には切り替え時刻以降の start_date を設定• 現行バージョンの本番環境の DAG には切り替え時刻までの end_date を設定• 切り戻す場合は現行バージョン用のブランチに修正を加えて実行を再開➡ コードが複雑化しない➡ 事前にデプロイが可能なので切り替え当日の人間のオペレーションが不要➡ DAG を実行できない時間帯が存在しないワークフローエンジン「Airflow」を使う上での工夫29Airflow のバージョンアップ戦略 (4) - 現在のバージョンアップ手順
4. データ基盤を使った実例30
データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Opsまずはシンプルな集計• Bigfoot にデータを集めることで統一的に集計• 統一された KPI 定義によるデータマートとダッシュボード（社内向け）• 作品ページのアクセス解析機能（ユーザー向け）• オウンドメディアの記事のアクセスランキング（ユーザー向け）31静的フィードバック収集分析活用システム リテラシ データ駆動DWHLoggerBI / Dashboardワークフローデータ連携データ集計統計知識事業価値の理解統計的な判断機械学習基盤適応的改善機構情報推薦機械学習サービスの動的改善自動的な意思決定＋ ＝段階
• 行動ログから離脱ユーザーを抽出するワークフローを作成• 作品をカートに入れたが買わなかったユーザー• 同じ作品を何度も見ているユーザー• ワークフローの処理結果を minne のアプリケーションに取り込み該当ユーザーに対してプッシュ通知やメールを配信• 高い開封率と注文率データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops32離脱ユーザーへのリテンション 動的フィードバック収集分析活用システム リテラシ データ駆動DWHLoggerBI / Dashboardワークフローデータ連携データ集計統計知識事業価値の理解統計的な判断機械学習基盤適応的改善機構情報推薦機械学習サービスの動的改善自動的な意思決定＋ ＝段階
• 協調フィルタリングをワークフローで行う• 似たユーザー行動の人が好む作家をクエリで得点付け• 結果を minne のアプリケーションが取り込んでユーザーに提示• 提示されたレコメンドリストに対するユーザーの行動が Bigfoot に戻ってくる• 比較的シンプルなモデルなので Cloud Composer だけで運用データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops33レコメンデーション 動的フィードバック収集分析活用システム リテラシ データ駆動DWHLoggerBI / Dashboardワークフローデータ連携データ集計統計知識事業価値の理解統計的な判断機械学習基盤適応的改善機構情報推薦機械学習サービスの動的改善自動的な意思決定＋ ＝段階
• 静的な A/B テストは機会損失が生じる• 既存の A パターンより新規の B パターンの性能が悪い可能性• 作品検索は売上に与える影響が大きいため機会損失を防ぎながら改善を行いたい• Epsilon-Greedy アルゴリズムの例• 探索と活用: 確率 ε, (1-ε) でランダムに選択した / 期待値最大のアルゴリズムを使用• 行動ログから結果の期待値を更新データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops34バンディットアルゴリズムによる推薦, 作品検索の改善 動的フィードバック収集分析活用システム リテラシ データ駆動DWHLoggerBI / Dashboardワークフローデータ連携データ集計統計知識事業価値の理解統計的な判断機械学習基盤適応的改善機構情報推薦機械学習サービスの動的改善自動的な意思決定＋ ＝段階
システム リテラシ データ駆動DWHLoggerBI / Dashboardワークフローデータ連携データ集計統計知識事業価値の理解統計的な判断機械学習基盤適応的改善機構情報推薦機械学習サービスの動的改善自動的な意思決定• 大量生産品をハンドメイドと偽る出品者が存在• ブランドイメージの毀損や信頼性低下に繋がるため作品の削除などが必要• 商品名, 商品説明文, 商品画像など従来の属性情報のみから検出することが困難• Bigfoot に統合されたデータから古典的機械学習で候補検出財津 大夏, 三宅 悠介, 松本 亮介, ハンドメイド作品を対象とした ECサイトにおける大量生産品の検出 ,研究報告インターネットと運用技術（ IOT）, Vol.2018-IOT-41, pp.1-8, May 2018. [論文] [発表資料]データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops35大量生産品の出品者の候補検出 静的フィードバック ML収集分析活用＋ ＝段階
• 処理性能を保ちつつ必要最小限のサーバーで運用する• 行動ログからアクセス傾向をモデル化して台数を自動制御• クラウドサービス利用料金を 2分の1に抑制した• モデルは TensorFlow で開発、AI Platform で API 化三宅 悠介, 松本 亮介, 力武 健次, 栗林 健太郎, アクセス頻度予測に基づく仮想サーバの計画的オートスケーリング ,情報科学技術フォーラム講演論文集 , Vol.17, No.4, pp.7-12, Sep 2018. [論文] [発表資料]データ基盤を使った実例 - ハンドメイドマーケット「minne」でのデータ活用とML Ops36サーバーの計画的オートスケーリング 動的フィードバック ML収集分析活用システム リテラシ データ駆動DWHLoggerBI / Dashboardワークフローデータ連携データ集計統計知識事業価値の理解統計的な判断機械学習基盤適応的改善機構情報推薦機械学習サービスの動的改善自動的な意思決定＋ ＝段階
• ソフトウェア開発チームのパフォーマンスを示す指標• デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度• 変更のリードタイム - commit から本番環境稼働までの所要時間• 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（ %）• サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間データ基盤を使った実例 - 社内の生産性指標の計測37Four Keysエリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Bloghttps://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
• デプロイの頻度 - Heroku のリリース数 / GitHub Enterprise のマージ数• 変更のリードタイム - GitHub Enterprise の平均マージ時間• 変更障害率 - デプロイとユーザーの行動ログ• サービス復元時間 - 障害やインシデント対応の BotOps のログデータ基盤を使った実例 - 社内の生産性指標の計測38Four Keys のデータソース - SUZURI の場合
• それぞれ Extract のためのコマンドラインツールを開発• GHES は Issue, Comment, User, Label, IssueEvent, Release, Commit に対応• Rust 製, ワンバイナリ• updated_at で期間指定可能• 差分更新に対応• CSV だけを出力する• Load は Embulk や gsutil, bq に任せるデータ基盤を使った実例 - 社内の生産性指標の計測39Four Keys の抽出方法 - Heroku のリリースログ, GitHub Enterpriseudzura/octx: GitHub query & extracter (Enterprise ready)https://github.com/udzura/octx
• SUZURI にはサービスアプリケーションの通信内容から行動ログを取り出すRack ミドルウェアを導入済み• 失敗したリクエストを集計するデータ基盤を使った実例 - 社内の生産性指標の計測40Four Keys の抽出方法 - ユーザーの行動ログサービスに寄り添うログ基盤https://speakerdeck.com/monochromegane/pepabo-log-infrastructure-bigfoot
• ペパボでは障害やインシデント対応が Slack bot を使って標準化されている• 対応内容が bot の DB に記録されている• Bigfoot へ ELT して利用データ基盤を使った実例 - 社内の生産性指標の計測41Four Keys の抽出方法 - 障害やインシデント対応の BotOps のログCo3で支えるペパボのセキュリティ対策〜 Communication Completely Continuous〜https://tech.pepabo.com/pdf/pepabo-tech-conference-14-security-team-slide.pdf
データ基盤を使った実例 - 社内の生産性指標の計測• SUZURI, Bigfoot（基盤チーム）の指標を計測可能な状態になっている• Google Data Studio で可視化が進行中• マージとデプロイ回数の乖離が少なくて良さそう etc...• 運用はこれから！• 他事業部への展開もやっていく42Four Keys の可視化・活用
5. データ基盤の今後43
44データ基盤の今後• ロードされたデータのドキュメンテーションは進んでいる• 例）RDBMS の個別のテーブル, カラムの意味は Bigfoot で確認可能• データ加工のパイプラインの可視化も進んでいる• パイプラインによって加工されたデータの意味づけがまだ不足• 上流のデータがどこから来たデータなのか？誰が作ったデータなのか？• データの作成に失敗した際の影響範囲は？• 現状はパイプラインの実装やアーキテクチャを読み解く必要がある• ELT など上流のコンポーネントや Airflow の運用障害で一定量の DAG が失敗すると影響範囲の特定がとても大変➡ データリネージとデータガバナンスへの取り組みデータリネージとデータガバナンス
45データ基盤の今後• 現在は ML に関連するパイプラインが統一されていない• 研究所で作られたモデルごとに当時の最適な方法で本番に適用されている• 実装が Cloud Composer のパイプライン, AI Platform, Notebook などに分散• データとモデルの管理方法もまちまち• 実装とデータとモデルを一元的に管理する基盤が必要• データガバナンスやデータリネージに当たる部分もある• 一方で、パラメータ管理やモデル管理など ML 独特の課題もある• Vertex AI Pipelines や Kubeflow Pipelines を検討中➡ 実装とデータとモデルの管理は Bigfoot に任せて課題解決に集中できるようにML Ops
46Thank You!ご静聴ありがとうございました資料は https://speakerdeck.com/zaimy/ に公開しています
zaimy
kyonmm
riru
.png){kind=icon}
pharma_x_tech
saboyutaka
nagiss
1ftseabass
oracle4engineer
nrryuya
tammyeverts
line_developers
claudioed
eitanlees
shlominoach
danielanewman
paulrobertlloyd
edds
afnizarnur
maltzj
holman
mongodb
ammeep
robhawkes
vanstee