Upcoming SlideShare
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
- 6. #denatechcon LTV予測による事業への貢献 ～エンジニアによるビジネス意思決定サポート事例～ 石川 勇 ゲーム・エンターテインメント事業本部 ゲームサービス事業部 分析部データエンジニアリンググループ 第１部 6
- 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
- 11. #denatechcon LTV(Life Time Value)とは何か？ マーケティング用語 一般的定義：顧客生涯価値 お客様がサービスにもたらす価値総和 （価値＝売上や利益など）
- 12. #denatechcon ゲーム事業でのLTVの特性 DeNAのゲーム事業では 「ゲームごとに、ひとりのお客様が支払う累積額」と定義 ゲームのお客様や商品の特徴： ・無料でもずっと遊び続けられる ・様々な購入頻度の商品（月額購入、都度課金ガチャ）が混在 ・商品構成や売り方、お客様の傾向も変わる 12
- 13. #denatechcon なぜLTVが必要か？ マーケティングを中心とした業務/意思決定の基準 → 【 お客様の獲得コスト ＜ LTV 】なら利益が出るため、 どれくらいコストがかけられるか判断できる 13 デジタル マーケティング CM投資判断
- 14. #denatechcon プラス3億円 LTV予測 20万人 集客見込 3億円の ＣＭ投資 6億円 売上見込 3000円と予測 マイナス1億円 LTV実績 20万人 集客実績 3億円の ＣＭ費用 2億円 売上実績 1000円だった LTVを用いたCMの投資判断・効果測定例 2017年9月 効果試算 2018年7月 実績を元に効果測定 2018年1月 CM放映
- 15. #denatechcon 第1部 アジェンダ 1. LTVはなぜ重要か？ 2. LTV予測の課題 2.1. LTV予測ロジックの課題 2.2. 運用の課題 3. 課題の解決 4. まとめと今後の展開 15
- 16. #denatechcon 前提：マーケティングでのLTV集計粒度は期間 特定の期間にゲームをインストールしたお客様が その後支払った総額の平均で集計する 例）1月中にCMを放映。CMにより20万人がインストールし、 その後180日間で20億円を支払った場合 →1月CMでインストールしたお客様の180日LTVは1,000円
- 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月 登録月
- 21. #denatechcon LTV予測の難しさ① 21 時系列によってお客様の傾向が変化する ・ゲームへの熱量はサービス初期（過去）ほど高い ・後からテレビCMで入ってくるお客様はライト寄り ・その他の要因もあり切り分け困難
- 22. #denatechcon LTV予測の難しさ② 22 ゲーム内施策が未確定、あとから変更されることもある ・売り物の変化（月額購入） ・売り方の変化（フェス等） ・これらの施策がどれだけ影響するかも 精緻には読みづらい…
- 23. #denatechcon 考慮項目を定性的に選定していた 定義できない考慮項目 ・前述のお客様の傾向 ・ゲーム内施策 定義できそうな考慮項目 ・週次トレンド ・月次トレンド ・全体トレンド をエクセルや旧来の手法では分離できなかった 23 ビジネス的には「正解のないタイプの案件」と分類
- 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月 結果的に、高い実 績を予測に利用し がちだった
- 26. #denatechcon プラス3億円 LTV予測 20万人 集客見込 3億円の ＣＭ投資 6億円 売上見込 3000円と予測 マイナス1億円 LTV実績 20万人 集客実績 3億円の ＣＭ費用 2億円 売上実績 1000円だった （再掲）予測が事業に与える影響例 2017年9月 効果試算 2018年7月 実績を元に効果測定 2018年1月 CM放映
- 27. #denatechcon LTV予測の課題② 予測モデル更新の負荷 27 累乗近似法の予測が用いられた 予測モデルの再開発・再フィッティングが手動で負担 半年後 最初は合うが 予測 実績 だんだん実情に合わなくなる 予測 実績 再フィッテング
- 28. #denatechcon LTV予測の課題③ 予実評価の難しさ 予測手順があとでわからなくなる ・恣意性（予測の考慮項目を定性的に選定） ・予測モデルの更新 予測LTVは担当者に依頼しないと手に入らなかったり、 実績が出るのは半年～1年後だったりするので、 実績が出たときに予測担当者が退職していたり… 28
- 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月 高い時期も低い時期も、 すべてをサンプルに含む アプローチに変更した 高い時期をサンプルに 選びがち…
- 33. #denatechcon 決めたこと② 考慮する項目の固定 33 考慮できない項目 ・前述のお客様の傾向 ・ゲーム内施策 考慮できそうな項目 ・週次トレンド ・月次トレンド ・全体トレンド をエクセルや旧来の手法では分離できなかった
- 34. #denatechcon やったこと① 予測改善プロジェクトを立ち上げる 決めたこと：全期間のデータを使う。変数は固定。 ・1ヵ月で予測モデルを選定、検証、解釈 →時系列予測がよさそう ・Prophetというpythonライブラリで予測評価することに ・さらに1ヵ月で実装し、運用 34
- 35. #denatechcon Prophetとは？ python3のお手軽時系列予測ライブラリ LTV 現在 CM 予定期間 ①過去の実績を 入力 35
- 36. #denatechcon 簡単なので、おススメ！ LTV 現在 CM 予定期間 ①過去の実績を取得 ②未来の値を出力 LTV予測値 36 時系列予測モデルを作ってくれる
- 37. #denatechcon 実際のコード 50行足らず 37 モデルの学習は1行 学習したモデルによる算出も1行
- 38. #denatechcon 実際の予測例（実際のあるゲームのある切り口を加工） 38 経過月 LTV ±33% (RMPSE) 0%に近づく ほど当たって る 精度改善は最優先でないが、一例 恣意性の入らない予測が完成
- 39. #denatechcon 課題②へのアプローチ 39 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定（トレンドと周期） モデル更新の運用が手間 「モデルの更新＋推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
- 40. #denatechcon 予測モデルにまつわる３つのタスク ①予測モデルの開発 Prophetというモデルを選定・検証・解釈する ②予測モデルの更新 Prophetのモデルを学習する/しなおす ③予測モデルの適用（推論） 学習済みモデルで実際の予測をする 40
- 41. #denatechcon 予測モデル更新の負荷とは ①予測モデルの開発 Prophetというモデルを選定・検証・解釈する ②予測モデルの更新 ← 累乗近似だとここが面倒 Prophetのモデルを学習する/しなおす ③予測モデルの適用（推論） 学習済みモデルで実際の予測をする 41 人が手作業でフィッティングを確認するのに最低数時間かかる
- 42. #denatechcon 時系列予測に置き換えたメリット ①予測モデルの開発 Prophetというモデルを選定・検証・解釈する ②予測モデルの更新 Prophetのモデルを学習する/しなおす ③予測モデルの適用（推論） 学習済みモデルで実際の予測をする 42 Prophetだと、ここまでだいたい1分 毎朝、最新の予測を算出できる
- 43. #denatechcon MLモデル on VM + Jenkins で定期実行 43 モデルの更新と推論が自動化できた
- 44. #denatechcon 課題③へのアプローチ 44 課題 対策 予測LTVの作成に恣意性が入り 得る サンプリング期間を固定 考慮項目を固定（トレンドと周期） モデル更新の運用が手間 「モデルの更新＋推論」を自動化した →MLモデル on VM + Jenkins で定期実行 予測LTV提供に時間がかかる 予測と実績の評価ができない BIツールで最新の予測結果を提供 過去の予測と実績も一括で提供
- 45. #denatechcon やったこと③ 実際の社内BIツールのスクリーンショット
- 46. #denatechcon 予測LTV利用者 予測を社内BIツールで提供 今朝計算した、来月の予測LTVは？ 2019/02/06 2019/02/06
- 47. #denatechcon 予測LTV利用者 予測LTVが表示される 2019/02/06 2019/02/06 最新の予測LTVは●●●●円だな
- 48. #denatechcon CMの効果測定担当者 過去のCMの投資対効果が良くなかった
- 49. #denatechcon CMの効果測定担当者 試算と評価を社内BIツールで提供 やはり高めに予測していたせいだ 当時の予測LTV 実績LTV
- 50. #denatechcon 実際に過去のモデルを入れてみた ※以下は特定ゲームのある切り口での予測精度例（RMPSE） 今回開発したProphetモデル ver1.0 新予測法:±33% 代表的な累乗近似モデル ver0.1 旧予測法：±77% 50
- 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 客観性を担保しつつ、関係者が合意できる予測値を算出して意 思決定をサポートし、事業に貢献することができた
- 53. #denatechcon 今後の展開 全社的なクラウド移行 →モデルもクラウド移行 versionごとのモデルを運用する必要 →複数モデルの並行運用のアーキテクチャ設計 LTV以外の意思決定サポート →必要に応じて機械学習を導入中 53 エンジニア目線で事業をどんどん変えていける インパクトの大きい業務をやりたい人はぜひご一緒に！
- 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
- 57. #denatechcon はじめに 早速ですが、DeNAゲーム事業における データ分析基盤の規模を見ていきましょう 57
- 58. #denatechcon はじめに BigQueryのストレージ容量 2PB+ 58
- 59. #denatechcon はじめに BigQueryのコスト（2018年9月時点） 680万円/月 59
- 60. #denatechcon はじめに BigQueryのコスト（2018年12月時点） 420万円/月 60
- 61. #denatechcon はじめに 3ヶ月間で 680 → 420 （万円/月） 何をやったのかをお話します。 61
- 62. #denatechcon 何をやったか？ No. 項目 内容 1 現状の可視化 - 請求データ - BigQueryのメタデータ 2 システム的な改善 - ストレージ容量削減 - クエリ検索量削減 - SQLクエリが検索したデータ量 3 運用の改善 - 問題を検知できる仕組みを導入 - 皆で改善するマインドを醸成 62
- 63. #denatechcon 採用している主な技術 Stackdriver Monitoring BigQuery Stackdriver Logging 63
- 64. #denatechcon まずは現状の可視化のお話 No. 項目 内容 1 現状の可視化 - 請求データ - BigQueryのメタデータ 2 システム的な改善 - ストレージ容量削減 - クエリ検索量削減 - SQLクエリが検索したデータ量 3 運用の改善 - 問題を検知できる仕組みを導入 - 皆で改善するマインドを醸成 64
- 65. #denatechcon 現状の可視化（請求データ） - ストレージ、クエリ検索ともコスト増加傾向 65 - 3ヶ月ごとに 月額 +100万円
- 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
- 74. #denatechcon ①データライフサイクルの定義（ストレージ容量削減） - あるゲームでは、 約60%のストレージ容量を削減 削減 74
- 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 ソート
- 77. #denatechcon ②Clustered Tables（β版）の導入（クエリ検索量削減） - 新規テーブルを作成し、既存テーブルから レコードをコピーすることで移行可能 77
- 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
- 80. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） - 巨大クエリを意図せず発行してしまった場合に 気付くことのできる仕組みが必要 - システム的にガードをかけるのではなく、 メンバーを信頼した上でのアプローチ 80
- 81. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） - StackDriver Loggingから監査ログを抽出 - Apps Scriptで閾値を超えるサイズの クエリを検出し、翌日Slackに通知 通知 project A project B project A project B 監査ログ 81 閾値を管理
- 82. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） 例えば、 閾値を超えるクエリを投げてしまうと・・・ 82
- 83. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） - 翌朝、以下のようにSlackに通知されます - この日は一撃で6TB（約3500円）のクエリが・・・ 83
- 84. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） - その後、Slack上で議論が始まります - このケースでは、テーブルのサイズを確認せずに、 SELECT * を投げてしまったようです 84
- 85. #denatechcon ⑤巨大クエリ実行時のSlack通知（システム/運用の改善） - 当月の累積課金額も日次で通知 85
- 86. #denatechcon まとめ - 改善内容（課題と対策）を以下にまとめます 86 課題 対策 ストレージ容量の増加 データライフサイクルの定義 クエリ検索量の増加 Clustered Tables（β版）の導入 jsonペイロードのparse 不要な定期実行機能を停止 問題検知の仕組みがない 巨大クエリ実行時のSlack通知
- 87. #denatechcon - 結果、月260万円 のコストを削減 - コスト（ストレージ）: 40%改善 - コスト（クエリ検索）: 41%改善 まとめ 87 月260万円改善
- 88. #denatechcon まとめ - BigQueryはとても便利なサービスです - ただし、適切に運用しないと 本来不要なコストがかかってしまいます - 皆さんも是非、 ご自身の環境をパトロールしてみてください！ 88
- 89. #denatechcon まとめ すでに運用上の工夫をされている方は、 ハッシュタグ #BQ警察 までお願いします！ 89
- 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
- 95. #denatechcon 何をやったか？ - MLモデルをdockerコンテナで 起動するよう変更した 95
- 96. #denatechcon 採用している主な技術 Container Registry BigQuery 96
- 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
- 104. #denatechcon おわりに 104
- 105. #denatechcon データエンジニアリンググループ 2019年2月、分析部内に 「データエンジニアリンググループ」 が発足しました 105
- 106. #denatechcon データエンジニアの役割 改善系03 ● ML Ops（★第2部） ● 自動化 ● コスト最適化（★第2部） 保守系02 ● リファクタリング ● 運用設計・手順化（★第1部） （属人化排除） 事業系01 ● 意思決定サポート（★第1部） ● 新規技術の獲得 ● クラウド移行（全社戦略） 106
- 107. #denatechcon Join us! 現在グループの立ち上げ期！ 我こそは！というデータエンジニアの方 一緒に盛り上げていきましょう！ 107
- 108. #denatechcon #denatechcon 108
Be the first to comment