DeNAの分析を支える分析基盤

Copyright © DeNA Co.,Ltd. All Rights Reserved.
DeNAの分析を⽀える分析基盤
January 29th, 2016
Kenshin Yamada
General Manager
Analy<cs Development Department
DeNA Co., Ltd.

⾃⼰紹介
n  ⼭⽥憲晋
n  DeNA システム本部分析推進部部⻑
n  略歴
1995年NECに⼊社。VerilogでFPGA上にTCPフルスタック実装する等
ネットワーク関連の研究開発に従事。
2007年DeNAに⼊社。モバゲーの開発インフラ、ゲーム開発チームのマ
ネージメント等を担当する。
ゲーム運営の中で分析の重要性を肌で感じ、2010年分析組織を⽴ち上
げる。
現在は、DeNA全体の分析基盤の構築と活⽤の推進統括をしている。
2

Agenda
n  DeNAの分析体制
n  DeNA分析基盤の歩み
n  アナリスト向け分析基盤
n  データ活⽤の取り組み
n  まとめと今後の分析基盤
3

DeNAの分析体制
4

組織体制
n  サービスを開発・運⽤している部⾨とは別に横断組織として、アナリ
スト、分析基盤エンジニアが属する部⾨が存在
n  アナリストが各サービスの分析を開発部⾨とともに実施している
ゲーム事業その他の事業
サ
ー
ビ
ス

開
発
部
⾨

横
断
部
⾨

アナリスト
分析基盤エンジニア
アナリスト

業務実⾏体制
n  分析業務はサービス感がもっとも重要！
n  アナリストは開発チーム内に座席を置き、そのサービスの開発メンバー
と議論をしながら業務を進めていくスタイルです
プロデューサ
ー
リード
プランナー
プランナープランナー
リード
デザイナー
デザイナー
アナリス
ト
リード
エンジニア
エンジニアエンジニアエンジニアエンジニア
アナリスト

アナリストの役割

具体的な動き⽅① 課題の導出とSolutionの提⽰
n  アナリストが⾏うことは以下の図の①~③の部分を⾏い、各サービスの
改善に寄与していく
①現状把握
②ゴール設定・ギャップの把握
・課題の導出
③解決策の
検討・選択
施策・⼿法
・実装の検討
あるべき姿
Goal / To be
現状
Present condition
/ As is
問題点
Problem
(≒Gap)
課題
Issue
解決策
Solution
具体的な⼿段
Operation

アナリストの具体的な業務
n  サービスを成功に導くために必要な分析業務を実施するために、
KPIの設計、ログの設計、データ集計、KPIの⾒える化、仮説の設定と
検証、改善案の提案などの業務を実⾏する。
9
収集・蓄積
•  KPI設計
•  ログ設計
集計・加⼯
•  データ集計
•  KPI⾒える化
分析
•  仮説の設定と
検証
•  改善案の提案
アナリストの業務
スピード感担保のため上記の全てをアナリストに完結してできるよ
うにしています。

DeNAの分析業務における、仮説検証プロセス
n  成功のパターンを確⽴するため、サービス毎のあるべき姿に応じて
KPIを設定し、現状分析や課題の導出、改善実施を⾏う必要があった
n  サービスを使⽤するユーザーのニーズの変化が早いので、
分析においても、常にサービスの動向を追い続け、サービスの状況に
合わせて、より⾼速な仮説検証プロセスの実施が求められた
10
集計・加⼯
• データ集計
• KPI⾒える化
分析
• 仮説の設定と検証
• 改善案の提案
改善案実施

DeNAのサービス数の拡⼤
n  DeNAの扱うタイトル数・サービス数が広がるにつれ、
アナリスト1⼈がサポートするサービスの数が増加した
⇒1⼈当たりの分析業務の効率化を実施する必要が出てきた
11
アナリストのサポートタイトル数の増加
アナリストアナリストアナリストアナリスト
New
New New

アナリスト業務を効率的に⾏う上で分析基盤に求めるもの
n  収集・蓄積
⁃  ⼤量なデータを安定的に（リアルタイムに⽋損なく）収集・蓄積
n  集計・加⼯
⁃  集計処理⾃体の⾼速可
⁃  利⽤しやすいデータセットの整備とjobの安定的な実⾏
⁃  ⼤量のKPIを可視化するためのレポーティングツール
12
収集・蓄積から集計・加⼯までのフェーズにおいて、可能な限りア
ナリストの⼯数をかけずにすむ状態を構築する事で、アナリストは
分析業務に集中できる

分析基盤エンジニアの役割

分析基盤エンジニアのミッション
DeNAの各サービスがデータを活⽤することで
サービスの成功・成⻑に繋げられる仕組みを作っていくこと
DeNAの全従業員が必要とする分析業務を簡単に実⾏することが
可能な分析環境を提供すること
14

分析基盤エンジニアの役割
15
分散処理基盤
分析環境改善データサービス
分析ツール開発
重要データ集計・
KPIツール提供
分析環境
利⽤者サポート
分析基盤利⽤者が分析環境を
快適に利⽤できるようにする
ためにありとあらゆることを
します。
⼤規模機械学習を活⽤したサービ
ス開発。新たな価値ある体験設計
から分散機械学習アルゴリズムの
設計・実装まで⾏います。
HadoopやVer<ca等の分散処理ミドルウェアを安定運⽤します。

DeNAの分析基盤の歩み
16

Log
Server
モバゲーのHadoop導⼊以前の分析 (before 2010)
n  分析組織発⾜前から、サービスの状態をデータを⽤いて定量的に把握し
て改善活動を⾏う⽂化は存在していた
n  サービス分析
n  企画とエンジニアがペアでサービス企画を開発・評価
n  データ抽出・加⼯はエンジニアがLogやMySQLから直接取得
n  マーケティングチーム⽤に分析専⽤データマートが存在
n  中⻑期的なユーザの利⽤傾向やサービスの利⽤状況など横断的な分
析を実施
17
Local log
DB
(MySQL)
web
web
web
Marke<ng
Datamart
(MySQL)
Batch Server
集計処理
DB
(MySQL)
Local log
Local log
Logの集約(⽇時)、
バックアップ

2010年分析組織の発⾜
n  2010年怪盗ロワイヤルに代表されるモバイルゲームの⼤ヒット
⁃  今までにない踏み込んだ分析ニーズの発⽣
•  やめている⼈と続けている⼈の違いは？
•  いろんな遊び⽅のユーザがいるがみんな満⾜しているのか？
•  お宝の奪いあいはもりあがっている？
•  ⼀番ちょうど良いボスの強さはどれくらいか？
•  次のイベントはどのように仕様を変えていくか？
⁃  ゲーム内部データに踏み込んでユーザ⾏動を分析する必要性
⁃  莫⼤なデータ量を分析する基盤の必要性
⇒ ゲーム事業部⾨内に分析専⾨部署を発⾜
n  ⼤量データを処理可能な分析基盤としてHadoopを本格導⼊・利⽤
18
事業部の分析ニーズから発⾜した分析部⾨なので、
ビジネス課題を解決するための組織という意識が徹底している
DeNAの分析組織の特徴

2010〜2012年の分析基盤の構成
n  全てのデータが集約される箱としてのHadoop
n  Query⾔語 (データ整形、抽出、集計)
⁃  Hive – SQL likeな記法。もっとも習得が容易。企画メンバ含めて広範囲で利⽤が進む
⁃  Pig – 専⽤DSL。事前のテーブル定義が不要。⼀度習得してしまえば簡単に集計Jobが開発で
きる。DeNAでは最初にPigを使い始めたこともあり、定常集計のJobでは主にPigが使われて
いる。
⁃  Java MapReduce - 最も柔軟性が⾼いため、⼤規模機械学習の分散処理は独⾃MapReduce実
装し、モデル実装洗練を何度も回す。ただ記述量が増えるため、アナリスト利⽤には敷居が⾼い。
n  KPI閲覧環境
⁃  内製ツール – 超重要KPIは専⽤ツール。ユーザ数、売り上げ、継続率などを提供。
⁃  Pentaho – アナリストがクイックにKPI Dashboardを作る⼿段として利⽤
19
Log
Collector
BI Tool
Pentaho
Jenkins
(job
scheduler)
Linux
(Batch/Adhoc)
Hue
Event log
DB
(MySQL)
snapshot
web
web
web
DB Snapshot
Loader
Analy<cs DB
(MySQL)
hive
pig

2013 VerGca導⼊
n  「Hadoop(MapReduce)の環境は分析アナリストにとっても本当に快適
な分析環境なのか？」という疑問
n  遅いのを我慢して使ってない？作業効率悪くない？
n  ⾼速な集計環境としてVerticaの導⼊を決定
n  Hive/Pig利⽤ユーザにとっては⼤きな分析環境⾰命！
20
Log
Collector
KPI Tool
Jenkins
(workﬂow)
Linux
(Batch/Adhoc)
Hue
Event log
DB
(MySQL)
snapshot
web
web
web
DB Snapshot
Loader
hive
pig
参考)「何故DeNAはverticaを選んだのか？」
n  http://www.slideshare.net/kenshinyamada5/denavertica

VerGca: 2015年5⽉突然の噴⽕
n  2015年5⽉突然の噴⽕
n  １年間殆ど落ちたことの無かったノードが週数回のペースで落ちるようになる
n  落ちたノードを稼動したままでは復旧できず、クラスタ⽌めてメンテナンス
n  クラスタ規模
n  スキーマ(利⽤サービスグループ)数: 95、テーブル数: 4985、容量: 33TB
n  状況考察
n  Verticaの管理領域(Catalog Data)の増加と共に様々な問題が発⽣
n  ノードダウン時の復旧時間の増⼤、クエリの性能劣化(特にSystem系テーブル)、
バックアップ時間の増⼤
n  Verticaの実⾏Query数の増加にサーバ追加でスケール出来ない状態
n  更新処理が追いつかず Catalog Dataのロックがタイムアウトすること有り
n  Kafka経由でのStreaming Insertは特に⾼負荷の要因だったので⽌めることに
n  ネットワークが過負荷状態になるとノードダウンが発⽣しやすい
n  ノードの死活管理をしているspread daemonのタイムアウトが発⽣
n  最終決断
n  単⼀クラスタ運⽤を諦めてクラスタを２つに分割する
21

VerGcaの今
n  クラスタを分割(ゲームクラスタ、⾮ゲームクラスタ)してからは安定運⽤出来ています。
n  複数クラスタを運⽤すると運⽤状態を⽐較できて⾯⽩いです。
n  次の噴⽕がいつ起きるかは戦々恐々。運⽤クラスタを余り増やしたくはない。
n  反省点: でかいVerticaクラスタ⼀つで何でもやるという構想に無理があった。
n  今後は、Verticaのメリットを最⼤限にいかすためにも、ユーザがリアルタイム応答を実感するレベルで
の品質を担保可能なように、利⽤⽀援・安定運⽤したい。
n  Verticaの擁護
n  DeNAの中では、Verticaをかなりいじめて煩雑に使っています。きちんとしたテーブル設計やク
エリ実⾏管理を運⽤出来る体制であれば、もっと⼤規模での利⽤も可能と考えます。
22
Log
Collector
Event log
DB
(MySQL)
snapshot
web
web
web
DB Snapshot
Loader
ゲームクラスタ
⾮ゲームクラスタ
内製KPI Tool
Argus

2014年10⽉ Hadoop2 Upgrade
n  2010年に導⼊したHadoopクラスタが2014.4時点では4 Peta Byteのクラスタサイ
ズに。
n  Hadoopクラスタ(CDH3)の課題
n  Namenode / JobTrackerのSPOF(Single Point of Failure)
n  古いコードベース。新機能が使えない。
n  Hdfsをothers readableで運⽤しており、サービス毎のセキュリティ確保が難
しい。
n  Hadoop2へのVersion Upを決断
⁃  ClouderaのCDH3からHortonworksのHDP2.1(hadoop-2.4)へ
•  CDHよりも community版との差分が少なく、Upgradeが容易そうだった。
⁃  データ量が4 Peta Byteを超えるため、新クラスタを構築してデータコピーす
るのではなく、既存クラスタをUpgradeする⽅針に
⁃  既存ジョブが正常に動くかどうか多くの利⽤ユーザを巻き込んつつ検証を進め、
2014.10にアップグレードを実施。
23

Hadoop2 Upgrade後
n  Namenode/Resource ManagerのHAを実現し、SPOFが無くなる。
n  HDFS Federation 導⼊
⁃  １つの物理クラスタで複数のNamespaceをサポート
⁃  Namespace1: モバゲー、ゲーム
⁃  Namespace2: 各種サービス
•  サービス毎に hdfsへのアクセス権限を厳密に管理
n  MapReduce以外のframeworkの利⽤が可能に
⁃  Prestoの試⽤開始
⁃  Sparkの導⼊
24

アナリスト向け分析基盤
25

分析基盤の全体構成
n  Hadoopクラスタ
n  全体容量: 6.4PetaByte
n  ノード数: 約200台
n  CPU数: 5360
n  データノードサーバスペック (最近購⼊)
n  CPU: Xeon E6-2640v3 2.6GHZ (8Cx2CPU)、MEM: 128GB、
HDD: 300GB 10k SAS HDD x2、8TB 7.2k SATA HDD x 12、
Network: 1Gb x2 bonding LACP(act/act)
26
Log
Collector
内製KPI Tool
Argus
Jenkins
(workﬂow)
Linux
(Batch/Adhoc)
Hue
Event log
DB
(MySQL)
snapshot
web
web
web
DB Snapshot
Loader
hive
pig
50TB
presto
6.4PB

Hadoop Hdfs
DB snapshot loader
Log Collector Ver<ca
Hadoop Hdfs
27
DB
(MySQL)
n  ⽉あたり 50 TeraByte のログを捌くためのログ収集システム
n  Tomcatは 2007年頃から稼働しており、モバゲーの不正投稿審査や連投監視等の
⽤途でも利⽤されている。
n  Cassandraを⼤規模メッセージキューとして利⽤。Hadoopが停⽌しても⼀⽇程度
ログの蓄積が可能。
n  Storm/HBaseを介して、ログ種別単位(5000以上)で hdfsにファイルを格納。
n  他チーム管理のコンポーネントとデータ連携する際は、
kafkaをメッセージキューとして⾮同期受け渡し
n  ログが吐かれてからhdfsに格納するまでは⼤凡15分以内
Hadoop Log CollecGon
Cassandra
Sqoop
web
web
Logging
endpoint
HBase
ka[a
tomcat
webEvent log
Event log
Event log
web
web
web
集約
AWS等
h]ps
ka[a
Special
Purpose
50TB/month
20TB/month

Hadoop HdfsLog Collector
Hadoop Hdfs
28
temp
n  ログ種別単位での分離
n  StormのMapToplogyでログをログ種別(5000種類)毎に分離してHBaseに格納
n  StormのReduceToplogyでログ種別ごとに Hdfsに追記(Append)で保存
n  回収率チェック
n  Tomcatが受け付けたブロック情報とhdfsに格納したブロック情報をElasticSearch上に
保存して、ログの回収率をチェックできるようにする。
n  重要集計はログ回収率100%になるのを待って集計ジョブを開始する。
Hadoop Log CollecGon: ログ種別単位でのhdfs格納と回収率チェック
Cassandra
HBase
tomcat
Session情報
Block情報
target
append
Elas<c Search
MapTopology ReduceTopology
ログ回収率情報は重要集計の起動条
件として利⽤されている。 API
Block化
Data
(ログ単位で分離
して格納)

アプリケーションログ回収＆監視
n  数100台規模で動く多数のアプリケーション(Hadoop, Hbase,
ElasticSearch等)のログを⼀箇所で管理・閲覧出来るようにしたい。
29
ka[a
Elas<cSearch
Nagios
HBase
Storm
Hadoop
Caasandra
Elas<cSearch
applica<on
n  Kibana上で log-level毎の発⽣頻度を
チェックした上で、各アプリケーシ
ョン、ホストに絞り込んで調査可能
n  Storm上でルール定義に従いログレベ
ルを設定可能
n  当初、ﬂuentdで実現していたが、
Storm化によりスケールが容易にな
った。
server.metrics
server.logs
Parser Log-level
Modiﬁer
topics

DeNAの分析の特徴
n  アナリストが全てをやる！！
n  KPI設計・ログ設計、テーブル設計・管理、データ集計、
KPIレポート作成、アドホック分析
n  ⼀⼈で全てをやるメリット
n  複数担当者間での無駄なコミュニケーションを排除し、
迅速に分析業務を回せるようにする
n  分析基盤の仕事: アナリストの全⼒サポート！！
n  分析環境利⽤者、特に、主要ユーザであるアナリストが
分析業務を快適に実現可能な分析環境を提供する
n  内製で作っている⼆つのツールに関して紹介します
30

Argus (内製レポートツール)

KPIレポートツールの内製化 in 2014.4
n  従来、アナリストがKPI Dashboardを作成する環境として市販のBI Toolを利⽤して
いたが、いくつかの問題を抱えていた
⁃  ⼀枚のレポートを作成するのに複数STEPが必要で⼿間がかかる。
•  KPI Dashboard作成ステップ
⁃  STEP1: KPI要件に応じて Hadoop上でpigの集計ジョブを作成＆定期実⾏
し MySQLに書き込む
⁃  STEP2: BI Tool上でデータソースとして登録する
⁃  STEP3: BI Tool上でKPIレポート作成
⁃  レポート数が数1000に達したところ増加性能が⼤きく劣化。まともに操作できない。
⁃  モダンではない使いづらいUI
n  代替BI Toolを探すもDeNAの要件にマッチするものは⾒つからない
⁃  レポート作成者 100⼈程度、レポート閲覧者1000⼈超
⁃  LDAP認証に対応し、サービス単位で編集・閲覧権限を設定できること
⁃  ServerはLinux。ClientはWindowsとMac OS-Xの両⽅のブラウザで動く
⁃  ⽉額100万円以内の格安で

32
Ver<caの⾼速性を最⼤限に活かすためにも⾃作することを決断

内製KPIレポートツール Argus
n  クエリを書いてチャート化してレポートにする事が可能
n  スケジュールを設定して定常更新も出来るし、アドホックに分析を⾏な
う事が可能
n  レポートを複数まとめてダッシュボード化し、サービスの重要な指標を
⾒やすく配置出来る
n  とにかく、簡単にレポートが作成可能！
僕アーガス
くん!

簡単なレポート作成!
1. クエリを書く
2. チャート化の設
定を⾏なう
3. レポートが
出来る！

複数のレポートをまとめてダッシュボードに!
配置も⾃由に出来る！
レポートを
集約！

Argus導⼊効果
n  プラグインを作れば、様々なデータソースや集計エンジンに接続できる
⁃  Vertica, Big Query, Presto etc...
n  レポート作成から公開まではものの数分で可能に。クエリを⾃分で書い
て様々な軸で分析が可能になる。定常更新のレポートだけでなく、アド
ホックな分析ツールとしても利⽤可能になった
n  レポートの閲覧権限/編集権限はGoogle Groupを使って担当者が簡単に
管理出来る様になった
n  従来の Pig + 市販のBIツールの分析環境に⽐べ、⽣産性は2.5倍に⾼まっ
た! (アナリスト調べ)
n  オンプレ環境だけでなくクラウド環境など、サービスやサービスの成⻑
ステージによって、集計環境を選択出来るようになった!
n  社内の他のレポートツールもArgusへリプレイスされ、利⽤者も拡⼤中。
有償レポートツールからのArgusへのリプレイスが進んでいる。

他のVisualizaGonツールに関して
n  Tableau
n  もりあがっていますね。DeNAでは、簡単なKPI視覚化であれば無料で
Argusで実現できてしまうので、Tableauニーズはそんなに強くない。
n  それでも、凝ったKPIダッシュボードの作成やAdhoc分析にはかなり有
⽤なツール
n  6ライセンスほど購⼊してトライアル利⽤中
n  数100〜数1000⼈規模でもっと安く使えればいいのだが・・・
n  とはいえ、ファイル共有してTableau Readerで閲覧という⽅法は取りたくない
n  その他注⽬しているツール
n  re:dash – 2014.4の時点で存在していればArgus開発しなかったかも
n  Amazon QuickSight – 市場破壊する可能性に期待
37

Medjed

Medjedとは
n  複数のデータソース間でバルクデータを転送するバルクロードツール
n  主要な⽤途: アナリストが必要なデータをhdfsからVerticaに持ってくる
ために利⽤
39
Log
Collector
内製KPI Tool
Argus
Jenkins
(workﬂow)
Linux
(Batch/Adhoc)
Hue
Event log
DB
(MySQL)
snapshot
web
web
web
DB Snapshot
Loader
hive
pig
Medjed

Medjedの仕組み
n  内部的にはembulkをラップしたMedjed-bulkを利⽤している
⁃  参考) embulk meetup #2での発表資料
http:www.slideshare.net//GONNakaTaka/embulk5
⁃  Embulkのplugin機構により BigQuery等複数データソースのサポートが容易
n  Web UIから全ての操作を⾏なう事が可能
⁃  テーブル作成
⁃  データ取り込みのスケジュール設定と再取り込み
n  テーブル定義にはSpreadsheetを利⽤する

Spreadsheetを活⽤
Spreadsheet上のテーブル定義をWeb UIか
ら取り込み、メタ情報として扱う
Spreadsheetで定義されたテ
ーブル定義書

Web UIから全ての操作が可能
ボタン⼀つでテーブル
作成/更新
⽇付を指定して
再取り込み実⾏
カレンダーで取り込み
状況を確認出来る
取り込みの詳細情報が
確認出来る。

Medjed導⼊効果
n  Spreadsheetを利⽤する事で、⼤量のテーブル定義も⾏ないやすい
⁃  もともとサービスのログ定義書をSpreadsheetで書く⽂化があり、
その延⻑上の作業として出来る
n  利⽤者が直接コンソールに⼊ってテーブル操作をしなくても、web UI
から定義書にある通りにテーブルのcreate/updateが安全に出来る
n  また、データの再取り込みなど必要な操作が全て web UI で完結可能に
なり、作業⼯数が削減される
n  取り込み失敗などのステータスが通知されるので、すぐに対応出来る様
になる
n  ⼤量のテーブル作成を⾏なう時間の短縮
n  Jenkinsで取り込みjobを作る時間の短縮
n  アナリストが本業の分析業務に時間を使える様になる！

集計バッチのワークフロー管理ツールに関して 1/2
n  2010年からずっとJenkinsを使っています。
n  DeNAでのワークフロー管理ツールへの要件
⁃  ⾮エンジニアが利⽤可能なようにワークフロー作成、実⾏、閲覧等の全操作を
Web UI上から簡単に実⾏できること
⁃  ワークフローの実⾏履歴と詳細な実⾏ログ(stdout/stderr)を閲覧できること
⁃  ワークフローの実⾏状況をモニタリングできること
⁃  スケジュール実⾏ができること
⁃  パラメータを指定してワークフローの実⾏ができること
•  集計ジョブで対象の⽇付を指定
⁃  ワークフロー失敗時に、指定アドレスに監視メールを送信可能なこと
⁃  ワークフロー失敗時に、失敗した箇所から再実⾏が可能なこと
n  Jenkinsで上の要件は⼗分に満たせている
44

集計バッチのワークフロー管理ツールに関して 2/2
n  Jenkins利⽤上の⼯夫
⁃  Dependency Graph Plugin
⁃  Hdfs plugin (⾃作)
•  指定のhdfs pathにデータが存在するかをチェックし、
存在しなければ指定時間待つ。
⁃  ログ回収率チェック plugin(⾃作)
•  前⽇分のシステム全体のログ回収の完了を待ってジョブをスタート
⁃  想定外のログ遅延が発⽣している場合にジョブスタートを遅らせられる
n  Jenkins利⽤の課題
⁃  ワークフローそのものがgithub管理されていない
⁃  リソース制御、依存関係の⾃動抽出、再実⾏の⾃動化など、エンジニアリン
グしづらい
n  今後、脱Jenkinsの可能性含めワークフロー管理をどうすべきか検討していく
45

データ活⽤の取り組み
46

データ活⽤の取り組みに関して
分析環境の２つの利⽤⽤途
アナリスト
分析環境に蓄積されたデータから、事業課題に対する分析及び改善提
案を⾏う
データサービス
機械学習などを活⽤して、ユーザ個別にレコメンデーション等の
特別なサービス体験を提供する
47

モバゲーでの適用例: パーソナルレコメンデーション
各ユーザーに対し興味・サービス横断で親しいユーザを学習・算出
サービスを使えば使うほど内容が洗練されていく
興味のあるゲームに出会う親しい人と一緒に楽しむ
友達を増やし一緒にゲーム・
ココミュニティを楽しむ
（個別の学習、及び、ユーザ状況に応じたアルゴリズム自体の組合せ・選択）
48

モバゲーでの適用例:パーソナルレコメンデーション
興味にあったゲームに出会い楽しめるレコメンド
行動・反応から興味を学習。使えば使うほど推薦内容が洗練されていく
自分の興味にあい楽しみ継続利用する確率が高いゲーム
・各ユーザごとに、各レコメンドに対す
る反応から興味を学習（強化学習）
自分がはまっているゲーム
User Reaction Log
Personalized Data
for Each User
Impression / Click / Install
Game Play Install
user_id, recdata
・ゲームプレイ特徴、ゲームインストー
ル特徴、インストール後継プレイ特徴、
の条件付き確率構造を学習
・各ユーザーごとに、プレイ特徴に応じ
た、各ゲームの継続利用確率を算出
分散処理: 機械学習
Click
Install
プレイ・継続特徴学習、利用継続確率
リアクション学習
Play Continuity
after install
参考) DeNAの⼤規模データマイニング活⽤したサービス開発
h]p://www.slideshare.net/hamadakoichi/dena-46573694

for Data Service
Hadoop Hdfs
DB snapshot loader
Log Collector
HBase
Hadoop Hdfs
50
DB
(MySQL)
n  DeNAの各種サービスで利⽤しているデータが既にhdfs上に集約されている
n  アナリストが分析⽤に設計・検証した品質の⾼いログデータを利⽤可能
n  Data Service⽤には、リアルタイムでユーザ興味等のデータ反映を⾏えるように、
必要なデータをLog Collector内のStormから抽出して、リアルタイム処理でData
Service⽤の Cassandra、HBaseに格納する。
n  Hadoop基盤上に構築されており⼤規模データの分散処理実装が容易
データサービス向け分析基盤構成
Cassandra
Sqoop
web
web
Logging
endpoint
HBase
tomcat
webEvent log
Event log
Event log
web
web
web
集約
AWS等
h]ps
Cassandra API
ka[a Spark
Streaming

リアルタイム興味反映・レコメンド
ひとりひとりのユーザ・アクションごとにリアルタイム興味反映
興味にあうものを提供する
Storm
Update
MapReduce
Batch
Update User
Streaming
Update
Update Rec
Update HBase
Update
Bolt
Bolt
Bolt
Log
Spout
Calc Pattern
Rec Request
Spout
HBase
Action
Impression
click
Item
Rec Request
Recommend
API
Log Collector
Update
HBase
Cassandra
User Preference
Pattern
Recommend
History
Recommend
Action
Impression
click
Item
Online Storage
Update
Update
Read
Stream
Notation
Kafka

パーソナライズ・レコメンデーション
×
⾃然⾔語処理

ユーザーの興味、同じ興味を持つ⼈の⾏動パターンを利⽤したレコメンデーション
News1
News2
News3
News4
パーソナル興味
興味→⾏動確率パターン
NEWS A 閲覧 ✔
三国志
興味1
興味ワード・概念記事の閲覧
⾏動興味ワード・概念
怪盗ロワイヤル
プレイ ▶
七つの⼤罪
インストール⇓
三国志ロワイヤル
プレイ ▶
キングダム
インストール⇓
興味2
興味1
NEWS B お気に⼊り☆
提⽰
反応
興味
クリックC
表⽰A
インストール D
表⽰B
表⽰C
表⽰D
クリックD
反応強化学習
興味2
三国志
参考) DeNAにおける⾃然⾔語処理活⽤ h]p://www.slideshare.net/KazukiFujikawa/dena-53192270

Deep Neural Network 活用例
スタイル・テイストが似ている商品にたくさん出会える
ファッションを楽しむ自由度を上げる
・距離算出に適した空間を構成できる、Deep Neural Networkの構築・学習
・商品に関係しない領域に引きづられず、スタイル・テイストが似ている商品を算出
商品スタイル・テイスト類似商品
身につけている・商品単体に限らず、類似商品算出
商品スタイル・テイスト類似商品
ファッションのスタイル・テイストが似ているものを算出

まとめと今後の分析基盤
55

まとめ
DeNAの分析体制
n  アナリストがログ設計、テーブル運⽤、KPI集計、KPI⾒える化、ア
ドホック分析の全てを実施。スピード感のある分析を実現している
n  分析基盤エンジニアはアナリストが分析しやすい環境の提供にコミット
n  最⾼の集計環境を追い求める
n  必要なものは作る: Argus, Medjed
データサービス活⽤
n  ⼤規模機械学習を活⽤し複数サービスで、体験提供から分散学習アル
ゴリズムの設計・実装までを実施。コンテンツ・ユーザの興味・状況
を学習した各種データサービスを提供している
n  Storm, HBase, Cassandraを活⽤して、⼤規模リアルタイムでの分
散処理基盤を構築・利⽤している
n  Deep LearningやAI技術関連の挑戦も⾏っている
56

これからの分析基盤
n  社外動向
n  Deep Learning、AI等、機械学習界隈の盛り上がり
n  脱MapReduce、MPP(Massive Parallel Processing) on Hadoop全盛
n  Presto、Spark等が利⽤が広がっている
n  Cloud上での分析基盤の利⽤の拡⼤、完成度の向上
n  BigQuery, Treasure Data, Amazon EMR (Presto, Spark)
⇒ 技術動向をしっかりキャッチアップしつつ、最適なソリューションを
選択していく必要あり
n  社内動向
n  分析利⽤サービスの多様化
n  モバゲーを中⼼とした分析プラットフォームから、多種多様なサービスを収容
するプラットフォームへ
n  サービスに対する分析ニーズや、携わるメンバーの分析基盤利⽤スキルも様々
⇒ 利⽤ニーズに応じてコスト効果の⾼い分析基盤の提供が必要 57

現状のDeNA分析基盤の構成と課題
n  データ集計・抽出環境
n  DataLakeとしてのHadoop とリアルタイム集計環境としてのVertica
n  HadoopとVerticaの使い分けはやはり⾯倒。
n  アナリストは⾼速集計環境をメインに使いたい
n  Verticaの利⽤拡⼤と共に分析基盤コストと Verticaの安定運⽤が課題に
n  Presto (MPP on Hadoop)試⽤中
n  ⼤規模利⽤での運⽤負荷、安定性に懸念があることから、Verticaを置き換え
る意思決定はできていない。
58
Log
Collector
内製KPI Tool
Argus
Jenkins
(workﬂow)
Linux
(Batch/Adhoc)
Hue
Event log
DB
(MySQL)
snapshot
web
web
web
DB Snapshot
Loader
hive
pig
presto

Google BigQueryという⿊船
n  価格破壊
n  格納するだけならAWS s3(standard)より安い
n  利⽤サービス(BigQueryプロジェクト)単位でコスト管理が可能
n  利⽤サービス単位でいつでもやめられる。
n  DeNA内でもUS拠点での⼗分な利⽤実績
n  本格利⽤するか絶賛評価中
n  オンプレHadoopを置き換えるだけではコスト低減にならないので
Verticaの利⽤をどこまで抑制できるかが鍵
59
内製KPI Tool
Argus
Jenkins
(workﬂow)
Linux
(Batch/Adhoc)
Hue
hive
pig
50TB
presto
sql

アナリスト向け分析環境をどうしていくか？
最⾼の集計環境を追い求める旅は続く
n  アナリストが裏の仕組みを気にせず、単⼀種類のSQLで、⽣ロ
グから整形データ等全てに⾃由にアクセスできる単⼀環境が欲しい
⁃  Hive、Presto、DHW(vertica/redshift)を適材適所で使い分けたく
ない。データ管理⾯倒。
⁃  Hadoopの⽤に⼤規模にJSON等の⾮構造化データが⼊れられて、
⁃  Data Warehouseのように柔軟かつ無茶なクエリがかけて、
⁃  コストパフォーマンスも重要
現実は難しいので使い分け
n  今後のブレイクスルーを⾒据えて技術ウォッチ＆評価
n  当⾯は、特定の技術にロックインしない
n  データサービス（機械学習実⾏）基盤のあるべき像も⼀緒に考えていく
60

最後に
今後も分析基盤技術の進化は⽌まらない
n  進化スピードの早い分析基盤技術の変化にしっかり追従する
n  分析基盤利⽤者のニーズが多様化しており、ニーズに応じてコスト
効果の⾼いソリューションを提供していく
n  オンプレ技術もクラウド技術も追い続ける
61

ご清聴ありがとうございました
62
⼀緒に⽇本の分析業界を
盛り上げていきましょう！

DeNAの分析を支える分析基盤

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to DeNAの分析を支える分析基盤

Similar to DeNAの分析を支える分析基盤 (20)

Recently uploaded

Recently uploaded (9)

DeNAの分析を支える分析基盤