事業に寄り添う データ基盤の育てかた 株式会社リブセンス　田中 祥太郎 2018-02-15 @ Developers Summit 2018

No content

内容について リブセンスにおいて、データ分析・機械学習のようなデータ活用を支える基盤をつくる中 で考えたことをまとめています。 それぞれの話には、当たり前で聞かなくてもわかるようなことが多いかもしれません。 それらを改めて整理することで、今後データ基盤にかかわる人の役に立つものがあれ ば嬉しいです。

自己紹介 名前 / ID 田中 祥太郎 / @yubessy 所属 株式会社リブセンス テクノロジカルマーケティング部 データプラットフォームグループ 仕事 データエンジニア 機械学習エンジニア

リブセンスのデータ基盤 マッハバイト・転職会議などの複数サービスで利用される共通基盤を開発・運用 分析基盤 Livesense Analytics 機械学習基盤 Livesense Brain

Livesense Analytics 各サービスのデータを Amazon Redshift に集約 ● アプリケーションデータ ● Web・アプリ・メール等の行動ログ 全社共通のデータウェアハウス (DWH) として提供 ● KPIモニタリング・施策効果分析 ● 機械学習システムのデータソース リブセンスのデータ分析基盤の全貌

Livesense Brain 各サービスの機械学習システムを Google Kubernetes Engine に集約(開発中) ● 求人レコメンドエンジン ● 求人効果予測モデル 複数システムから使えるよう機能モジュールを共通化 ● レコメンドアルゴリズム・モニタリング ● ABテスト・バンディット Kubernetes を利用したコンテナベース機械学習基盤の構築

いま改めて考えたいこと なぜデータ基盤が必要なのか？ なぜデータ基盤を自分たちで作るのか？ どうやってデータ基盤を育てていくか？

なぜデータ基盤が必要なのか？

そもそもデータ基盤ってなんだろう？ ざっくり言うと・・・サービスのデータ活用を支えるインフラやモジュール リブセンスでのデータ活用： データに基づく意思決定 ● 日々のKPIのモニタリング ● 施策立案・効果分析 データからのユーザ価値創出 ● 求人レコメンド ● 検索順位の最適化

基盤があればデータ活用がうまくいく？ 基盤があるだけで サービスが便利になる → NO 〃 事業が成長する 　 → NO 〃 人の生産性が上がる → NO データ基盤を作る前にデータ活用の風土・文化づくりが必要 営業さんまで、社員全員がSQLを使う越境型組織ができるまでの3+1のポイント 基盤に求めることは組織によって異なる ただ、ある程度の考え方は共通する（と思っています）

なぜサービスとデータ基盤を分けるの？ 理由１ 専門性をスケールさせる ● 事業組織：サービス専属のデータエンジニア・MLエンジニアがほしい ● 横断組織：そこまでのリソースはない → 基盤を介してメンバーの専門性を複数の場で活かせるようにする Livesense Analytics Livesense Brain

理由２ サービスレベルを分離する ● 開発：自由に分析・効果検証・試験投入をしたい ● 運用：安定性の低いシステムによるサービスへの影響を局所化したい → サービスと基盤を疎結合化することで、安全に試行錯誤を許容する なぜサービスとデータ基盤を分けるの？ API データ転送 重い 分析クエリ 試験的な アルゴリズム Livesense Analytics Livesense Brain

なぜデータ基盤を自分たちで作るのか？

OSSやXaaSを使うべき？ BigQuery, Redshift, TreasureData, …. 良いものは積極的に使うべき → YES あれば何も作らなくてよい → NO 既存のものを使うだけでは上手くいかない場合： ● 事業ニーズを満たすOSSやXaaSが存在しない ● 周辺システムやグルー処理に高度なエンジニアリングが必要

事例 求人レコメンド リブセンスの事業におけるレコメンド ● 求人・不動産：（広告等に比べ）CV単価高・データ件数少 ● 多少スケールしにくくても精度の高いアルゴリズムが有効 一般的なライブラリ・PaaS ● Matrix Factorization のような一般的なアルゴリズム ● スケーラビリティやレスポンスタイムを求められるがゆえの制約 事業ニーズを満たせない → アルゴリズムを論文から実装してモジュール化 BPMF(Bayesian Probabilistic Matrix Factorization)によるレコメンド

事例 個人情報マスキング 本番DB → DWH のデータ投入時にカラム単位で個人情報等をマスキング 要件： ● 処理前後でのスキーマの二重管理を避けたい ○ カラムの削除ではなく値の上書きにしたい ● データ同期の遅れを最小化したい ○ カラム単位でのUPDATEを並列化したい システム間をつなぐ高度なグルー処理が必要 → CLIツールを開発 https://github.com/livesense-inc/split_mysql

作る・使うの境界はどうする？ 作るか使うかは常に悩ましい・データ技術は移り変わりが激しい → 判断の「見直し」と「先送り」を選択肢に 判断の見直し ● 作るか使うか・何を使うかを、必要なら後で変更する ● 最初から作るより「使う → 作る」のほうが実装方針を固めやすい 判断の先送り ● 良い選択肢がなければ無理にいま決めない ● 捨てやすい簡易実装にとどめて良いOSSやXaaSの成熟を待つ

事例 データ処理のワークフローエンジン選定 Livesense Analytics 2016頃から Apache Airflow を採用 Livesense Brain 2017秋から開発、2016頃と状況が変化 ● digdagなどの新たなOSSの台頭 ● Kubernetesを採用 ○ 各タスクを別コンテナや別Podで動かしたい ○ ジョブのキックはCronJobでOK → タスクの依存管理に集中したい → 標準の選定は先送りし、Luigi + CronJob による簡易実装にとどめる 個人的には argoproj / argo に期待してます

どうやってデータ基盤を育てていくか？

再掲 基盤があればデータ活用がうまくいく？ 基盤があるだけで サービスが便利になる → NO 〃 事業が成長する 　 → NO 〃 人の生産性が上がる → NO データ基盤が成果を挙げるには・・・ ● 開発開始前：データ活用の風土・文化を育てる ● 開発開始後：事業組織と一緒に成功パターンを見出していく

需要が多い機能を優先する？ 基盤が使われ始めると様々な機能要求が出てくる 全てに対応するのが難しくなってきたら？ → 複数の「あったら使うかも」より１つの「ほしい・絶対使う」を優先する 理由： ● 複数の似たような要求が実は異なることも ● １つのケースでうまくいけば「こっちでも使いたい」という声は出てくる

事例 Redshift サマリテーブル マッハバイトでの Livesense Analytics 活用 ● １PV単位での生ログを Redshift に保存 ● 頑張れば応募経路の分析もできる ● 百行以上のSQLを操るディレクターさん → マッハバイト専用にサマリテーブルを先行実装 ● １応募単位でのPV数や滞在時間・流入経路 ● アトリビューションモデルによる広告効果分析 後に他事業部にも展開 WITH ss AS ( SELECT TO_NUMBER(REGEXP_SUBSTR(s.landing_url,'\\d+'),'000000') AS client_id, TO_CHAR(s.start_time,'YYYY-MM-DD') AS date, s.session_id, s.total_entry, s.total_hit, s.stay_time, CASE WHEN s.device = 'smartphone' THEN 'sp' ELSE 'pc' END AS device FROM js.sessions AS s WHERE s.start_time >= '2016-07-01' AND s.channel_type = 'organic' AND s.source != 'Indeed' AND s.landing_page_type = 'detail' AND s.device IN ('pc', 'smartphone') ) SELECT ss.date, ss.device, COUNT(ss.session_id) AS sessions, SUM(ss.total_entry) AS entries, 1.0 * SUM(ss.total_entry) / COUNT(ss.session_id) AS entry_rate, 1.0 * SUM(CASE WHEN ss.total_hit = 1 THEN 1 ELSE 0 END) / COUNT(ss.session_id) AS bounce_rate, AVG(ss.stay_time) AS avg_stay_time FROM ss LEFT JOIN ( SELECT TRUNC(ca.ddate) AS date, ca.id, ca.plan FROM jsen_archive.client_archives AS ca WHERE ca.ddate >= '2016-07-01') AS ca_plan ON ca_plan.id = ss.client_id AND ca_plan.date = ss.date GROUP BY

検証効率と品質のどっちを取る？ データ活用は実環境検証ができないと進めにくい ● 機械学習：ユーザに出さないと真の意味での精度がわからない ● 分散処理：同スキーマでも値の分布によって処理効率が低下 ただし、品質の低いシステムが本運用に乗るのは避けたい（苦い記憶） → フェーズ毎に目的に応じたサービスレベルを明示

Livesense Brain で稼働するシステムのフェーズ分類（策定中） ※SLO (サービスレベル目標) = 可用性や復旧時間などの目標 どのシステムがどのフェーズに属するかを事前に決めることで 関係者の間のサービスレベルの認識の不一致を防ぐ 事例 機械学習システムのフェーズ定義 フェーズ 目的 SLO 基盤エンジニアの役割 コンセプト検証 実現性の調査・検討 なし リソース提供・セキュリティ上の確認のみ 技術検証 最適な手段の模索 なし 技術的な助言・実環境検証の補助 本運用 継続的な価値提供 あり 安定性・メンテナンス性のレビューと承認

どうやって使ってもらう？ 社内基盤はPaaS/SaaSに比べて「生」な形態になりがち 基盤をどう使えばよいかわからない・ノウハウが部署に閉じやすい ● Redshift のどのテーブルにどんなデータがある？ ● DBクライアントやBIダッシュボードはどれがよい？ → ユーザ同士でノウハウを共有できる機会をつくる

Livesense Analytics (LA) の活用事例を紹介してもらう懇親会を開催 ライトユーザだけでなく基盤エンジニアにとっても有用な知見が得られた 事例 LA Night

改めて なぜデータ基盤が必要なのか？ なぜデータ基盤を自分たちで作るのか？ どうやってデータ基盤を育てていくか？

さいごに （当たり前ですが）データ基盤は作るだけでなくどう育てるかが重要です リブセンスでも方向性は見えてきましたが、まだまだ試行錯誤の段階です 他にない類のエンジニアリングが要求される面白い技術分野だと思います 興味を持ってもらえたら・・・ LIVESENSE Data Analytics Blog