Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
What to Upload to SlideShare
Loading in …3
×
1 of 108

DeNAゲーム事業におけるデータエンジニアの貢献 [DeNA TechCon 2019]

3

Share

Download to read offline

DeNAの分析部は、事業における意思決定の質を最大限に高めるための部門です。より高度な分析を低コストで実現するために、BigQueryを中心としたデータ分析基盤を活用しています。
本セッションでは「DeNAのゲーム事業における意思決定を分析部がどのように支えているか」と「データ分析基盤を運用する中でぶつかった課題をどのように乗り越えてきたか」について技術的な側面から、実例を交えてお話します。

More Related Content

You Might Also Like

Related Books

Free with a 30 day trial from Scribd

See all

DeNAゲーム事業におけるデータエンジニアの貢献 [DeNA TechCon 2019]

  1. 1. #denatechcon #denatechcon DeNAゲーム事業における データエンジニアの貢献 #BigQuery #GCP #ML #データ分析基盤 #AdTech #機械学習 1
  2. 2. #denatechcon アジェンダ - 第1部: LTV予測による事業への貢献(石川) - 第2部: システム運用の改善について(岩尾) - おわりに 2
  3. 3. #denatechcon 本日のゴール 1. DeNAではエンジニアもビジネス課題の解決に がっつり取り組んでいることを知ってもらう 2. 明日から使えるBigQueryの運用方法を共有する 3. 「分析部 データエンジニアリンググループ」 に興味を持ってもらう 3
  4. 4. #denatechcon - 役割 - ゲーム事業における意思決定の支援を行うこと 例)ゲーム内施策の振り返り、事業計画立案サポートなど - 構成 - 以下の役割を持ったメンバーが分析部内に所属し互いに連携 - データエンジニア: 分析の省力化・増力化 - データアナリスト: 担当ゲームの意思決定支援 - データサイエンティスト: より高度な分析手法の探求 ゲームサービス事業部 分析部 の紹介 4
  5. 5. #denatechcon データエンジニアの役割と本日のトピックス 改善系03 ● ML Ops(★第2部) ● 自動化 ● コスト最適化(★第2部) 保守系02 ● リファクタリング ● 運用設計・手順化(★第1部) (属人化排除) 事業系01 ● 意思決定サポート(★第1部) ● 新規技術の獲得 ● クラウド移行(全社戦略) 5
  6. 6. #denatechcon LTV予測による事業への貢献 ~エンジニアによるビジネス意思決定サポート事例~ 石川 勇 ゲーム・エンターテインメント事業本部 ゲームサービス事業部 分析部データエンジニアリンググループ 第1部 6
  7. 7. #denatechcon Isamu Ishikawa(石川 勇) - 2010年DeNAにエンジニアとしてJOIN - MobagePFの開発と分析を担当 - 2012年ごろから分析関連部署へ - データ アナリスト&データ エンジニア - DWH整備から機能開発・ゲーム分析 Speaker わからなかったことは、ぜひQ&Aで! 7
  8. 8. #denatechcon 第1部の要点 8 LTV × 機械学習 × 運用の工夫 → 事業貢献 ポイント  正解がないと言われていた長年のビジネス課題を  エンジニアのアプローチで前に進めた事例
  9. 9. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か? 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 9
  10. 10. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か? 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 10
  11. 11. #denatechcon LTV(Life Time Value)とは何か? マーケティング用語 一般的定義:顧客生涯価値 お客様がサービスにもたらす価値総和 (価値=売上や利益など)
  12. 12. #denatechcon ゲーム事業でのLTVの特性 DeNAのゲーム事業では 「ゲームごとに、ひとりのお客様が支払う累積額」と定義 ゲームのお客様や商品の特徴: ・無料でもずっと遊び続けられる ・様々な購入頻度の商品(月額購入、都度課金ガチャ)が混在 ・商品構成や売り方、お客様の傾向も変わる 12
  13. 13. #denatechcon なぜLTVが必要か? マーケティングを中心とした業務/意思決定の基準 → 【 お客様の獲得コスト < LTV 】なら利益が出るため、   どれくらいコストがかけられるか判断できる 13 デジタル マーケティング CM投資判断
  14. 14. #denatechcon プラス3億円 LTV予測 20万人 集客見込 3億円の CM投資 6億円 売上見込 3000円と予測 マイナス1億円 LTV実績 20万人 集客実績 3億円の CM費用 2億円 売上実績 1000円だった LTVを用いたCMの投資判断・効果測定例 2017年9月 効果試算 2018年7月 実績を元に効果測定 2018年1月 CM放映
  15. 15. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か? 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 15
  16. 16. #denatechcon 前提:マーケティングでのLTV集計粒度は期間 特定の期間にゲームをインストールしたお客様が その後支払った総額の平均で集計する 例)1月中にCMを放映。CMにより20万人がインストールし、   その後180日間で20億円を支払った場合   →1月CMでインストールしたお客様の180日LTVは1,000円
  17. 17. #denatechcon LTV予測・運用の手順 1/4 最近の実績LTVを算出 LTV 現在8月 CM 予定期間 ①過去に登録したお客様の30日LTV実績 17 3月 4月 5月 6月 登録月 ? 180日LTVを予測したい
  18. 18. #denatechcon LTV予測・運用の手順 2/4 30日LTV実績から180日LTV予測を作成 LTV 現在8月 CM 予定期間 ②過去の伸び率をかけたり・累乗近似で伸ばす 18 3月 4月 5月 6月 登録月 ? 180日LTVを予測したい
  19. 19. #denatechcon LTV予測・運用の手順 3/4 これを将来のLTVとして、意思決定に利用 LTV 現在8月 CM 予定期間 19 3月 4月 5月 6月 登録月 7月
  20. 20. #denatechcon LTV予測・運用の手順 4/4 実績LTVの評価/予測ロジックの改善 LTV 現在 CM 予定期間 ③予実の評価 20 LTV実績値 LTV予測値 3月 4月 5月 6月 登録月
  21. 21. #denatechcon LTV予測の難しさ①  21 時系列によってお客様の傾向が変化する ・ゲームへの熱量はサービス初期(過去)ほど高い ・後からテレビCMで入ってくるお客様はライト寄り ・その他の要因もあり切り分け困難
  22. 22. #denatechcon LTV予測の難しさ②  22 ゲーム内施策が未確定、あとから変更されることもある ・売り物の変化(月額購入) ・売り方の変化(フェス等) ・これらの施策がどれだけ影響するかも  精緻には読みづらい…
  23. 23. #denatechcon 考慮項目を定性的に選定していた 定義できない考慮項目 ・前述のお客様の傾向 ・ゲーム内施策 定義できそうな考慮項目 ・週次トレンド ・月次トレンド ・全体トレンド をエクセルや旧来の手法では分離できなかった 23 ビジネス的には「正解のないタイプの案件」と分類
  24. 24. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か? 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 24
  25. 25. #denatechcon LTV予測の課題① 予測における恣意性 予測の教師データとしてどの時期を採用するか考慮項目として何を 選ぶか自由度があるとLTVを高く見積もる傾向 25 LTV 現在 CM 予定期間 25 3月 4月 5月 6月 結果的に、高い実 績を予測に利用し がちだった
  26. 26. #denatechcon プラス3億円 LTV予測 20万人 集客見込 3億円の CM投資 6億円 売上見込 3000円と予測 マイナス1億円 LTV実績 20万人 集客実績 3億円の CM費用 2億円 売上実績 1000円だった (再掲)予測が事業に与える影響例 2017年9月 効果試算 2018年7月 実績を元に効果測定 2018年1月 CM放映
  27. 27. #denatechcon LTV予測の課題② 予測モデル更新の負荷  27 累乗近似法の予測が用いられた 予測モデルの再開発・再フィッティングが手動で負担 半年後 最初は合うが 予測 実績 だんだん実情に合わなくなる 予測 実績 再フィッテング
  28. 28. #denatechcon LTV予測の課題③ 予実評価の難しさ 予測手順があとでわからなくなる ・恣意性(予測の考慮項目を定性的に選定) ・予測モデルの更新 予測LTVは担当者に依頼しないと手に入らなかったり、 実績が出るのは半年~1年後だったりするので、 実績が出たときに予測担当者が退職していたり… 28
  29. 29. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か? 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 29
  30. 30. #denatechcon (再掲)課題 30 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定(トレンドと周期) →算出ロジックのMLを導入 モデル更新の運用が手間 「モデルの更新+推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
  31. 31. #denatechcon 課題①へのアプローチ 31 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定(トレンドと周期) モデル更新の運用が手間 「モデルの更新+推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
  32. 32. #denatechcon 決めたこと① サンプル取得期間の固定 32 LTV 3月 4月 5月 6月 LTV 3月 4月 5月 6月 高い時期も低い時期も、 すべてをサンプルに含む アプローチに変更した 高い時期をサンプルに 選びがち…
  33. 33. #denatechcon 決めたこと② 考慮する項目の固定 33 考慮できない項目 ・前述のお客様の傾向 ・ゲーム内施策 考慮できそうな項目 ・週次トレンド ・月次トレンド ・全体トレンド をエクセルや旧来の手法では分離できなかった
  34. 34. #denatechcon やったこと① 予測改善プロジェクトを立ち上げる 決めたこと:全期間のデータを使う。変数は固定。 ・1ヵ月で予測モデルを選定、検証、解釈   →時系列予測がよさそう ・Prophetというpythonライブラリで予測評価することに ・さらに1ヵ月で実装し、運用 34
  35. 35. #denatechcon Prophetとは? python3のお手軽時系列予測ライブラリ LTV 現在 CM 予定期間 ①過去の実績を 入力 35
  36. 36. #denatechcon 簡単なので、おススメ! LTV 現在 CM 予定期間 ①過去の実績を取得 ②未来の値を出力 LTV予測値 36 時系列予測モデルを作ってくれる
  37. 37. #denatechcon 実際のコード 50行足らず 37 モデルの学習は1行 学習したモデルによる算出も1行
  38. 38. #denatechcon 実際の予測例(実際のあるゲームのある切り口を加工) 38 経過月 LTV ±33% (RMPSE) 0%に近づく ほど当たって る 精度改善は最優先でないが、一例 恣意性の入らない予測が完成
  39. 39. #denatechcon 課題②へのアプローチ 39 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定(トレンドと周期) モデル更新の運用が手間 「モデルの更新+推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
  40. 40. #denatechcon 予測モデルにまつわる3つのタスク ①予測モデルの開発   Prophetというモデルを選定・検証・解釈する ②予測モデルの更新   Prophetのモデルを学習する/しなおす ③予測モデルの適用(推論)   学習済みモデルで実際の予測をする 40
  41. 41. #denatechcon 予測モデル更新の負荷とは ①予測モデルの開発   Prophetというモデルを選定・検証・解釈する ②予測モデルの更新 ← 累乗近似だとここが面倒   Prophetのモデルを学習する/しなおす ③予測モデルの適用(推論)   学習済みモデルで実際の予測をする 41 人が手作業でフィッティングを確認するのに最低数時間かかる
  42. 42. #denatechcon 時系列予測に置き換えたメリット ①予測モデルの開発   Prophetというモデルを選定・検証・解釈する ②予測モデルの更新   Prophetのモデルを学習する/しなおす ③予測モデルの適用(推論)   学習済みモデルで実際の予測をする 42 Prophetだと、ここまでだいたい1分 毎朝、最新の予測を算出できる
  43. 43. #denatechcon MLモデル on VM + Jenkins で定期実行 43 モデルの更新と推論が自動化できた
  44. 44. #denatechcon 課題③へのアプローチ 44 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定(トレンドと周期) モデル更新の運用が手間 「モデルの更新+推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
  45. 45. #denatechcon やったこと③ 実際の社内BIツールのスクリーンショット
  46. 46. #denatechcon 予測LTV利用者 予測を社内BIツールで提供 今朝計算した、来月の予測LTVは? 2019/02/06 2019/02/06
  47. 47. #denatechcon 予測LTV利用者 予測LTVが表示される 2019/02/06 2019/02/06 最新の予測LTVは●●●●円だな
  48. 48. #denatechcon CMの効果測定担当者 過去のCMの投資対効果が良くなかった
  49. 49. #denatechcon CMの効果測定担当者 試算と評価を社内BIツールで提供 やはり高めに予測していたせいだ 当時の予測LTV 実績LTV
  50. 50. #denatechcon 実際に過去のモデルを入れてみた ※以下は特定ゲームのある切り口での予測精度例(RMPSE) 今回開発したProphetモデル  ver1.0 新予測法:±33% 代表的な累乗近似モデル  ver0.1 旧予測法:±77% 50
  51. 51. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か? 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 51
  52. 52. #denatechcon 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定(トレンドと周期) モデル更新の運用が手間 「モデルの更新+推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供 まとめ 52 客観性を担保しつつ、関係者が合意できる予測値を算出して意 思決定をサポートし、事業に貢献することができた
  53. 53. #denatechcon 今後の展開 全社的なクラウド移行  →モデルもクラウド移行 versionごとのモデルを運用する必要  →複数モデルの並行運用のアーキテクチャ設計 LTV以外の意思決定サポート  →必要に応じて機械学習を導入中 53 エンジニア目線で事業をどんどん変えていける インパクトの大きい業務をやりたい人はぜひご一緒に!
  54. 54. #denatechcon システム運用の改善について - BigQueryの運用におけるコスト最適化 - ML Opsへの挑戦 第2部 54
  55. 55. #denatechcon Speaker - Kazumasa Iwao(岩尾 一優) - データエンジニア / アーキテクト - 2018年7月、DeNAにJOIN - 分析部データエンジニアリンググループに所属 - グループリーダーを担当 - 2010年4月 - 2018年6月 - 富士ゼロックスに所属 - ネットプリントのアーキテクト BQ警察はじめました! 55
  56. 56. #denatechcon システム運用の改善について - BigQueryの運用におけるコスト最適化 - ML Opsへの挑戦 - ハッシュタグは #BQ警察 でお願いします! 56
  57. 57. #denatechcon はじめに 早速ですが、DeNAゲーム事業における データ分析基盤の規模を見ていきましょう 57
  58. 58. #denatechcon はじめに BigQueryのストレージ容量 2PB+ 58
  59. 59. #denatechcon はじめに BigQueryのコスト(2018年9月時点) 680万円/月 59
  60. 60. #denatechcon はじめに BigQueryのコスト(2018年12月時点) 420万円/月 60
  61. 61. #denatechcon はじめに 3ヶ月間で 680 → 420 (万円/月) 何をやったのかをお話します。 61
  62. 62. #denatechcon 何をやったか? No. 項目 内容 1 現状の可視化 - 請求データ - BigQueryのメタデータ 2 システム的な改善 - ストレージ容量削減 - クエリ検索量削減 - SQLクエリが検索したデータ量 3 運用の改善 - 問題を検知できる仕組みを導入 - 皆で改善するマインドを醸成 62
  63. 63. #denatechcon 採用している主な技術 Stackdriver Monitoring BigQuery Stackdriver Logging 63
  64. 64. #denatechcon まずは現状の可視化のお話 No. 項目 内容 1 現状の可視化 - 請求データ - BigQueryのメタデータ 2 システム的な改善 - ストレージ容量削減 - クエリ検索量削減 - SQLクエリが検索したデータ量 3 運用の改善 - 問題を検知できる仕組みを導入 - 皆で改善するマインドを醸成 64
  65. 65. #denatechcon 現状の可視化(請求データ) - ストレージ、クエリ検索ともコスト増加傾向 65 - 3ヶ月ごとに 月額 +100万円
  66. 66. #denatechcon 現状の可視化(BigQueryのメタデータ) - Stackdriver Monitoring を利用 - GCPやAWSのリソースとサービスを検出し、 GUIによる簡単な操作でモニタリングをするためのツール 66 BigQueryのメタデータ (ストレージ容量・クエリ検索量) の可視化に利用
  67. 67. #denatechcon 現状の可視化(BigQueryのメタデータ) - ストレージ容量の内訳を確認 - あるゲームでは、 特定のデータセットがストレージの大部分を占めている 67 - この部分を削減すれば、 ストレージ容量を大幅に削減できそう あるゲームのデータ内訳
  68. 68. #denatechcon 現状の可視化(BigQueryのメタデータ) - ゲームごとのクエリ検索量を明確化 - 特定のゲームにクエリ検索量が集中している 68 - 利用者(データアナリスト/カスタマーサ ポート)によるスキルのばらつき? - 中間テーブルの設計がイケてない? ゲームごとに クエリ検索量を色分け
  69. 69. #denatechcon 現状の可視化(BigQueryのメタデータ) - クエリ検索量の異常を検知 - 事件が起きたときの例 !? 69 - 担当者が意図したクエリなのか、 確認(ヒアリング)することが大切
  70. 70. #denatechcon 現状の可視化まとめ - 請求データの可視化により、 コストの増加傾向を把握することが可能 - Slackdriver Monitoringを用いると、 BigQueryのメタデータの可視化が容易 → 対策を検討しやすい 70
  71. 71. #denatechcon ここから5つの改善事例のお話 No. 項目 内容 1 現状の可視化 - 請求データ - BigQueryのメタデータ 2 システム的な改善 - ストレージ容量削減 - クエリ検索量削減 - SQLクエリが検索したデータ量 3 運用の改善 - 問題を検知できる仕組みを導入 - 皆で改善するマインドを醸成 71
  72. 72. #denatechcon ①データライフサイクルの定義(ストレージ容量削減) - テーブルごとに必要な保存期間は異なる - 「7日」、「30日」、「365日」、「永久」など - サービス開始時点では「永久」を選択しがち - 定期的に棚卸しが必要 - 必要な保存期間に応じて ローテーションさせる仕組みを導入した 72
  73. 73. #denatechcon ①データライフサイクルの定義(ストレージ容量削減) project A project CAmazon EC2 project B ローテーション対象を設定ファイルで管理。 - プロジェクト - データセット - テーブル - 保存期間 削除指示 設定ファイルの内容に基づき、 ローテーション用のスクリプトを実行 73
  74. 74. #denatechcon ①データライフサイクルの定義(ストレージ容量削減) - あるゲームでは、 約60%のストレージ容量を削減 削減 74
  75. 75. #denatechcon - BigQueryの Clustered Tables(β版) - これまで検索量を絞る方法は分割テーブルのみであった - 他のカラムについても、インデックスを付与することにより ある程度検索範囲を絞り込めるようになった - インデックスは4つまで指定可能 ②Clustered Tables(β版)の導入(クエリ検索量削減) 75
  76. 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 ソート
  77. 77. #denatechcon ②Clustered Tables(β版)の導入(クエリ検索量削減) - 新規テーブルを作成し、既存テーブルから レコードをコピーすることで移行可能 77
  78. 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. 79. #denatechcon ④不要な定期実行機能を停止(クエリ検索量削減) - BIツールの不要な定期実行機能を停止 - 現在利用しているレポート数は2000+ - それぞれに対してcron形式で定期実行を行っていた - レポートの作成者はデータアナリスト 週末の定期実行停止 改善前)30 6 * * * 改善後)30 6 * * 1-5 夜間の定期実行停止 改善前)30 * * * * 改善後)30 9-20 * * * 79
  80. 80. #denatechcon ⑤巨大クエリ実行時のSlack通知(システム/運用の改善) - 巨大クエリを意図せず発行してしまった場合に 気付くことのできる仕組みが必要 - システム的にガードをかけるのではなく、 メンバーを信頼した上でのアプローチ 80
  81. 81. #denatechcon ⑤巨大クエリ実行時のSlack通知(システム/運用の改善) - StackDriver Loggingから監査ログを抽出 - Apps Scriptで閾値を超えるサイズの クエリを検出し、翌日Slackに通知 通知 project A project B project A project B 監査ログ 81 閾値を管理
  82. 82. #denatechcon ⑤巨大クエリ実行時のSlack通知(システム/運用の改善) 例えば、 閾値を超えるクエリを投げてしまうと・・・ 82
  83. 83. #denatechcon ⑤巨大クエリ実行時のSlack通知(システム/運用の改善) - 翌朝、以下のようにSlackに通知されます - この日は一撃で6TB(約3500円)のクエリが・・・ 83
  84. 84. #denatechcon ⑤巨大クエリ実行時のSlack通知(システム/運用の改善) - その後、Slack上で議論が始まります - このケースでは、テーブルのサイズを確認せずに、 SELECT * を投げてしまったようです 84
  85. 85. #denatechcon ⑤巨大クエリ実行時のSlack通知(システム/運用の改善) - 当月の累積課金額も日次で通知 85
  86. 86. #denatechcon まとめ - 改善内容(課題と対策)を以下にまとめます 86 課題 対策 ストレージ容量の増加 データライフサイクルの定義 クエリ検索量の増加 Clustered Tables(β版)の導入 jsonペイロードのparse 不要な定期実行機能を停止 問題検知の仕組みがない 巨大クエリ実行時のSlack通知
  87. 87. #denatechcon - 結果、月260万円 のコストを削減 - コスト(ストレージ): 40%改善 - コスト(クエリ検索): 41%改善 まとめ 87 月260万円改善
  88. 88. #denatechcon まとめ - BigQueryはとても便利なサービスです - ただし、適切に運用しないと 本来不要なコストがかかってしまいます - 皆さんも是非、 ご自身の環境をパトロールしてみてください! 88
  89. 89. #denatechcon まとめ すでに運用上の工夫をされている方は、 ハッシュタグ #BQ警察 までお願いします! 89
  90. 90. #denatechcon システム運用の改善について - BigQueryの運用におけるコスト最適化 - ML Opsへの挑戦 90
  91. 91. #denatechcon 伝えたいこと - MLモデルの実行は 初心者にとってハードルが高い - データサイエンティストが Jupyter Notebook で作成したMLモデルを github 経由でやり取り 91
  92. 92. #denatechcon 伝えたいこと - 「俺の環境でだけ動かない・・・」 - 「システムに乗せ換えるの面倒・・・」 - 「ゲームごとに環境構築・・・」 という状況をなくしたい! 92
  93. 93. #denatechcon - MLモデルの実行は以下のように行っていた - この例のMLモデルは 学習・推論を含んでいます これまでのシステム構成 Amazon EC2BigQuery 93 - MLモデルの設置・実行
  94. 94. #denatechcon これまでのシステム構成の課題 - 環境構築が面倒 - 今後の移行(AWS → GCP)が困難 Amazon EC2BigQuery 94
  95. 95. #denatechcon 何をやったか? - MLモデルをdockerコンテナで 起動するよう変更した 95
  96. 96. #denatechcon 採用している主な技術 Container Registry BigQuery 96
  97. 97. #denatechcon 新しいシステム構成 - EC2上でdockerコンテナを起動する方式を採用 - dockerイメージをContainer Registryに格納 Container Registry ローカル Amazon EC2BigQuery 97
  98. 98. #denatechcon メリット①: 環境構築が容易 - Container Registry から 必要なdockerイメージを pull して使うだけ Container Registry ローカル Amazon EC2BigQuery dockerイメージは データサイエンティストや データエンジニアが作成 98
  99. 99. #denatechcon メリット②: 移行が容易 - GCP に移行時も、GCEで docker run するだけ - 別途、認証方式の解決は必要 Container Registry ローカル Amazon EC2BigQuery 99
  100. 100. #denatechcon - docker イメージ内に クレデンシャル情報を持たせない - GCPの「サービスアカウント」はホスト側に持たせ、 dockerコンテナにマウント 注意点 100
  101. 101. #denatechcon まとめ - これまでデータ分析におけるMLの導入は 環境構築や移行の手間に悩まされてきました。 - MLモデルをdockerコンテナで起動することで 上記の悩みが解決に向かっています。 - 未解決の部分もあります。(→ 次ページ) 101
  102. 102. #denatechcon 今後の展開(on going...) - dockerイメージのビルドを自動化 102 Container Registry ローカル Cloud Build dockerfile
  103. 103. #denatechcon 今後の展開(on going...) - 学習・推論でモジュールを分割 - 「学習は週次や月次、推論はリアルタイム」などの 要求への対応のため - モデルのバージョン管理 - ロギング 103
  104. 104. #denatechcon おわりに 104
  105. 105. #denatechcon データエンジニアリンググループ 2019年2月、分析部内に 「データエンジニアリンググループ」 が発足しました 105
  106. 106. #denatechcon データエンジニアの役割 改善系03 ● ML Ops(★第2部) ● 自動化 ● コスト最適化(★第2部) 保守系02 ● リファクタリング ● 運用設計・手順化(★第1部) (属人化排除) 事業系01 ● 意思決定サポート(★第1部) ● 新規技術の獲得 ● クラウド移行(全社戦略) 106
  107. 107. #denatechcon Join us! 現在グループの立ち上げ期! 我こそは!というデータエンジニアの方 一緒に盛り上げていきましょう! 107
  108. 108. #denatechcon #denatechcon 108

×