DeNAゲーム事業におけるデータエンジニアの貢献 [DeNA TechCon 2019]
•
4 likes•4,916 views
DeNAの分析部は、事業における意思決定の質を最大限に高めるための部門です。より高度な分析を低コストで実現するために、BigQueryを中心としたデータ分析基盤を活用しています。 本セッションでは「DeNAのゲーム事業における意思決定を分析部がどのように支えているか」と「データ分析基盤を運用する中でぶつかった課題をどのように乗り越えてきたか」について技術的な側面から、実例を交えてお話します。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DeNAゲーム事業におけるデータエンジニアの貢献 [DeNA TechCon 2019]
Similar to DeNAゲーム事業におけるデータエンジニアの貢献 [DeNA TechCon 2019] (20)
More from DeNA
More from DeNA (20)
Recently uploaded
Recently uploaded (10)
DeNAゲーム事業におけるデータエンジニアの貢献 [DeNA TechCon 2019]
- 1. #denatechcon #denatechcon DeNAゲーム事業における データエンジニアの貢献 #BigQuery #GCP #ML #データ分析基盤 #AdTech #機械学習 1
- 2. #denatechcon アジェンダ - 第1部: LTV予測による事業への貢献（石川） - 第2部: システム運用の改善について（岩尾） - おわりに 2
- 3. #denatechcon 本日のゴール 1. DeNAではエンジニアもビジネス課題の解決に がっつり取り組んでいることを知ってもらう 2. 明日から使えるBigQueryの運用方法を共有する 3. 「分析部 データエンジニアリンググループ」 に興味を持ってもらう 3
- 4. #denatechcon - 役割 - ゲーム事業における意思決定の支援を行うこと 例）ゲーム内施策の振り返り、事業計画立案サポートなど - 構成 - 以下の役割を持ったメンバーが分析部内に所属し互いに連携 - データエンジニア: 分析の省力化・増力化 - データアナリスト: 担当ゲームの意思決定支援 - データサイエンティスト: より高度な分析手法の探求 ゲームサービス事業部 分析部 の紹介 4
- 5. #denatechcon データエンジニアの役割と本日のトピックス 改善系03 ● ML Ops（★第2部） ● 自動化 ● コスト最適化（★第2部） 保守系02 ● リファクタリング ● 運用設計・手順化（★第1部） （属人化排除） 事業系01 ● 意思決定サポート（★第1部） ● 新規技術の獲得 ● クラウド移行（全社戦略） 5
- 7. #denatechcon Isamu Ishikawa（石川 勇） - 2010年DeNAにエンジニアとしてJOIN - MobagePFの開発と分析を担当 - 2012年ごろから分析関連部署へ - データ アナリスト&データ エンジニア - DWH整備から機能開発・ゲーム分析 Speaker わからなかったことは、ぜひQ＆Aで！ 7
- 8. #denatechcon 第1部の要点 8 LTV × 機械学習 × 運用の工夫 → 事業貢献 ポイント 正解がないと言われていた長年のビジネス課題を エンジニアのアプローチで前に進めた事例
- 9. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か？ 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 9
- 10. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か？ 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 10
- 13. #denatechcon なぜLTVが必要か？ マーケティングを中心とした業務/意思決定の基準 → 【 お客様の獲得コスト ＜ LTV 】なら利益が出るため、 どれくらいコストがかけられるか判断できる 13 デジタル マーケティング CM投資判断
- 15. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か？ 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 15
- 17. #denatechcon LTV予測・運用の手順 1/4 最近の実績LTVを算出 LTV 現在8月 CM 予定期間 ①過去に登録したお客様の30日LTV実績 17 3月 4月 5月 6月 登録月 ？ 180日LTVを予測したい
- 18. #denatechcon LTV予測・運用の手順 2/4 30日LTV実績から180日LTV予測を作成 LTV 現在8月 CM 予定期間 ②過去の伸び率をかけたり・累乗近似で伸ばす 18 3月 4月 5月 6月 登録月 ？ 180日LTVを予測したい
- 19. #denatechcon LTV予測・運用の手順 3/4 これを将来のLTVとして、意思決定に利用 LTV 現在8月 CM 予定期間 19 3月 4月 5月 6月 登録月 7月
- 20. #denatechcon LTV予測・運用の手順 4/4 実績LTVの評価/予測ロジックの改善 LTV 現在 CM 予定期間 ③予実の評価 20 LTV実績値 LTV予測値 3月 4月 5月 6月 登録月
- 24. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か？ 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 24
- 25. #denatechcon LTV予測の課題① 予測における恣意性 予測の教師データとしてどの時期を採用するか考慮項目として何を 選ぶか自由度があるとLTVを高く見積もる傾向 25 LTV 現在 CM 予定期間 25 3月 4月 5月 6月 結果的に、高い実 績を予測に利用し がちだった
- 29. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か？ 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 29
- 30. #denatechcon （再掲）課題 30 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定（トレンドと周期） →算出ロジックのMLを導入 モデル更新の運用が手間 「モデルの更新＋推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
- 31. #denatechcon 課題①へのアプローチ 31 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定（トレンドと周期） モデル更新の運用が手間 「モデルの更新＋推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
- 32. #denatechcon 決めたこと① サンプル取得期間の固定 32 LTV 3月 4月 5月 6月 LTV 3月 4月 5月 6月 高い時期も低い時期も、 すべてをサンプルに含む アプローチに変更した 高い時期をサンプルに 選びがち…
- 39. #denatechcon 課題②へのアプローチ 39 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定（トレンドと周期） モデル更新の運用が手間 「モデルの更新＋推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
- 43. #denatechcon MLモデル on VM + Jenkins で定期実行 43 モデルの更新と推論が自動化できた
- 44. #denatechcon 課題③へのアプローチ 44 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定（トレンドと周期） モデル更新の運用が手間 「モデルの更新＋推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
- 51. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か？ 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 51
- 52. #denatechcon 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定（トレンドと周期） モデル更新の運用が手間 「モデルの更新＋推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供 まとめ 52 客観性を担保しつつ、関係者が合意できる予測値を算出して意 思決定をサポートし、事業に貢献することができた
- 54. #denatechcon システム運用の改善について - BigQueryの運用におけるコスト最適化 - ML Opsへの挑戦 第2部 54
- 55. #denatechcon Speaker - Kazumasa Iwao（岩尾 一優） - データエンジニア / アーキテクト - 2018年7月、DeNAにJOIN - 分析部データエンジニアリンググループに所属 - グループリーダーを担当 - 2010年4月 - 2018年6月 - 富士ゼロックスに所属 - ネットプリントのアーキテクト BQ警察はじめました！ 55
- 56. #denatechcon システム運用の改善について - BigQueryの運用におけるコスト最適化 - ML Opsへの挑戦 - ハッシュタグは #BQ警察 でお願いします！ 56
- 62. #denatechcon 何をやったか？ No. 項目 内容 1 現状の可視化 - 請求データ - BigQueryのメタデータ 2 システム的な改善 - ストレージ容量削減 - クエリ検索量削減 - SQLクエリが検索したデータ量 3 運用の改善 - 問題を検知できる仕組みを導入 - 皆で改善するマインドを醸成 62
- 64. #denatechcon まずは現状の可視化のお話 No. 項目 内容 1 現状の可視化 - 請求データ - BigQueryのメタデータ 2 システム的な改善 - ストレージ容量削減 - クエリ検索量削減 - SQLクエリが検索したデータ量 3 運用の改善 - 問題を検知できる仕組みを導入 - 皆で改善するマインドを醸成 64
- 66. #denatechcon 現状の可視化（BigQueryのメタデータ） - Stackdriver Monitoring を利用 - GCPやAWSのリソースとサービスを検出し、 GUIによる簡単な操作でモニタリングをするためのツール 66 BigQueryのメタデータ （ストレージ容量・クエリ検索量） の可視化に利用
- 67. #denatechcon 現状の可視化（BigQueryのメタデータ） - ストレージ容量の内訳を確認 - あるゲームでは、 特定のデータセットがストレージの大部分を占めている 67 - この部分を削減すれば、 ストレージ容量を大幅に削減できそう あるゲームのデータ内訳
- 68. #denatechcon 現状の可視化（BigQueryのメタデータ） - ゲームごとのクエリ検索量を明確化 - 特定のゲームにクエリ検索量が集中している 68 - 利用者（データアナリスト/カスタマーサ ポート）によるスキルのばらつき？ - 中間テーブルの設計がイケてない？ ゲームごとに クエリ検索量を色分け
- 69. #denatechcon 現状の可視化（BigQueryのメタデータ） - クエリ検索量の異常を検知 - 事件が起きたときの例 ！？ 69 - 担当者が意図したクエリなのか、 確認（ヒアリング）することが大切
- 70. #denatechcon 現状の可視化まとめ - 請求データの可視化により、 コストの増加傾向を把握することが可能 - Slackdriver Monitoringを用いると、 BigQueryのメタデータの可視化が容易 → 対策を検討しやすい 70
- 71. #denatechcon ここから5つの改善事例のお話 No. 項目 内容 1 現状の可視化 - 請求データ - BigQueryのメタデータ 2 システム的な改善 - ストレージ容量削減 - クエリ検索量削減 - SQLクエリが検索したデータ量 3 運用の改善 - 問題を検知できる仕組みを導入 - 皆で改善するマインドを醸成 71
- 72. #denatechcon ①データライフサイクルの定義（ストレージ容量削減） - テーブルごとに必要な保存期間は異なる - 「7日」、「30日」、「365日」、「永久」など - サービス開始時点では「永久」を選択しがち - 定期的に棚卸しが必要 - 必要な保存期間に応じて ローテーションさせる仕組みを導入した 72
- 73. #denatechcon ①データライフサイクルの定義（ストレージ容量削減） project A project CAmazon EC2 project B ローテーション対象を設定ファイルで管理。 - プロジェクト - データセット - テーブル - 保存期間 削除指示 設定ファイルの内容に基づき、 ローテーション用のスクリプトを実行 73
- 75. #denatechcon - BigQueryの Clustered Tables（β版） - これまで検索量を絞る方法は分割テーブルのみであった - 他のカラムについても、インデックスを付与することにより ある程度検索範囲を絞り込めるようになった - インデックスは4つまで指定可能 ②Clustered Tables（β版）の導入（クエリ検索量削減） 75
- 76. #denatechcon ②Clustered Tables（β版）の導入（クエリ検索量削減） - Where句で指定するカラムに インデックスを付与するのがおすすめ 76 - WHERE user_id = ‘Mei’ とする場合、user_idにインデックスを 付与しておけば、Mから始まる箇所の周辺 のみ検索対象となる - クエリ検索量 & パフォーマンス改善 例）user_idにインデックスを付与する場合 user_id age Gender ... ... ... Mei 20 F Mika 34 F ... ... ... Sara 23 F ソート
- 78. #denatechcon ③jsonペイロードのparse（クエリ検索量削減） - 巨大なjsonペイロードを 1カラムに入れたまま使わない - よく使うデータは、parseしてカラムに切り出すのが良い - item1の平均所有数を計算したい場 合でも、jsonペイロード全体を検索 対象としてしまう - クエリ検索量の増加につながる user_id key value user1 item_list {"item1": 5, "item2": 0, … "item100": 10} user2 item_list {"item1": 6, "item2": 4, … "item100": 15} user3 item_list {"item1": 3, "item2": 2, … "item100": 3} user4 item_list {"item1": 2, "item2": 1, … "item100": 40} 例）ユーザーごとのアイテムの所有数 78
- 79. #denatechcon ④不要な定期実行機能を停止（クエリ検索量削減） - BIツールの不要な定期実行機能を停止 - 現在利用しているレポート数は2000+ - それぞれに対してcron形式で定期実行を行っていた - レポートの作成者はデータアナリスト 週末の定期実行停止 改善前）30 6 * * * 改善後）30 6 * * 1-5 夜間の定期実行停止 改善前）30 * * * * 改善後）30 9-20 * * * 79
- 81. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） - StackDriver Loggingから監査ログを抽出 - Apps Scriptで閾値を超えるサイズの クエリを検出し、翌日Slackに通知 通知 project A project B project A project B 監査ログ 81 閾値を管理
- 83. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） - 翌朝、以下のようにSlackに通知されます - この日は一撃で6TB（約3500円）のクエリが・・・ 83
- 84. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） - その後、Slack上で議論が始まります - このケースでは、テーブルのサイズを確認せずに、 SELECT * を投げてしまったようです 84
- 86. #denatechcon まとめ - 改善内容（課題と対策）を以下にまとめます 86 課題 対策 ストレージ容量の増加 データライフサイクルの定義 クエリ検索量の増加 Clustered Tables（β版）の導入 jsonペイロードのparse 不要な定期実行機能を停止 問題検知の仕組みがない 巨大クエリ実行時のSlack通知
- 87. #denatechcon - 結果、月260万円 のコストを削減 - コスト（ストレージ）: 40%改善 - コスト（クエリ検索）: 41%改善 まとめ 87 月260万円改善
- 88. #denatechcon まとめ - BigQueryはとても便利なサービスです - ただし、適切に運用しないと 本来不要なコストがかかってしまいます - 皆さんも是非、 ご自身の環境をパトロールしてみてください！ 88
- 90. #denatechcon システム運用の改善について - BigQueryの運用におけるコスト最適化 - ML Opsへの挑戦 90
- 91. #denatechcon 伝えたいこと - MLモデルの実行は 初心者にとってハードルが高い - データサイエンティストが Jupyter Notebook で作成したMLモデルを github 経由でやり取り 91
- 92. #denatechcon 伝えたいこと - 「俺の環境でだけ動かない・・・」 - 「システムに乗せ換えるの面倒・・・」 - 「ゲームごとに環境構築・・・」 という状況をなくしたい！ 92
- 93. #denatechcon - MLモデルの実行は以下のように行っていた - この例のMLモデルは 学習・推論を含んでいます これまでのシステム構成 Amazon EC2BigQuery 93 - MLモデルの設置・実行
- 94. #denatechcon これまでのシステム構成の課題 - 環境構築が面倒 - 今後の移行（AWS → GCP）が困難 Amazon EC2BigQuery 94
- 97. #denatechcon 新しいシステム構成 - EC2上でdockerコンテナを起動する方式を採用 - dockerイメージをContainer Registryに格納 Container Registry ローカル Amazon EC2BigQuery 97
- 98. #denatechcon メリット①: 環境構築が容易 - Container Registry から 必要なdockerイメージを pull して使うだけ Container Registry ローカル Amazon EC2BigQuery dockerイメージは データサイエンティストや データエンジニアが作成 98
- 99. #denatechcon メリット②: 移行が容易 - GCP に移行時も、GCEで docker run するだけ - 別途、認証方式の解決は必要 Container Registry ローカル Amazon EC2BigQuery 99
- 100. #denatechcon - docker イメージ内に クレデンシャル情報を持たせない - GCPの「サービスアカウント」はホスト側に持たせ、 dockerコンテナにマウント 注意点 100
- 101. #denatechcon まとめ - これまでデータ分析におけるMLの導入は 環境構築や移行の手間に悩まされてきました。 - MLモデルをdockerコンテナで起動することで 上記の悩みが解決に向かっています。 - 未解決の部分もあります。（→ 次ページ） 101
- 102. #denatechcon 今後の展開（on going...） - dockerイメージのビルドを自動化 102 Container Registry ローカル Cloud Build dockerfile
- 103. #denatechcon 今後の展開（on going...） - 学習・推論でモジュールを分割 - 「学習は週次や月次、推論はリアルタイム」などの 要求への対応のため - モデルのバージョン管理 - ロギング 103
- 106. #denatechcon データエンジニアの役割 改善系03 ● ML Ops（★第2部） ● 自動化 ● コスト最適化（★第2部） 保守系02 ● リファクタリング ● 運用設計・手順化（★第1部） （属人化排除） 事業系01 ● 意思決定サポート（★第1部） ● 新規技術の獲得 ● クラウド移行（全社戦略） 106