第 11 回 Google Cloud INSIDE Games & Apps にご登壇いただいたスライドです。 株式会社ディー・エヌ・エー データエンジニア / グループマネージャー 岩尾 一優様 データエンジニア 城谷 信一郎様

1. DeNA のデータ活用を支える BigQuery
データの民主化とガバナンス強化の軌跡
株式会社ディー・エヌ・エー データエンジニア / グループマネージャー 岩尾 一優
株式会社ディー・エヌ・エー データエンジニア 城谷 信一郎

2. Speaker
2
株式会社ディー・エヌ・エー （2018 年 7 月 〜）
• データエンジニア / マネージャー
• データエンジニア組織の戦略策定・推進
• BI プラットフォーム Looker の全社導入を推進
（複業）株式会社 Hogetic Lab（2019 年 4 月 〜）
• 外部取締役 CTO
• データ分析コンサル / 組織コンサル
岩尾 一優
（イワオ カズマサ）

3. 本日お話すること
3
DeNA のデータプラットフォーム
データの民主化を目指して
データプラットフォーム ガバナンス強化の取り組み
1
2
3

4. DeNA のデータプラットフォーム
4

5. 現在のデータプラットフォーム
サービス データプラットフォーム
log
DB
内製 BI ツール
（Argus）
5

6. 現在のデータプラットフォーム - データ収集
サービス データプラットフォーム
log
DB
fluentd / embulk などを
用いてデータ収集
データの保存/加工
内製 BI ツール
（Argus）
データの活用
6

7. 現在のデータプラットフォーム - ワークフロー
サービス データプラットフォーム
log
DB
ワークフローを管
理
ワークフローの
構成管理
digdag の他に batch/web
app などのワークロードを実
行させることが可能。その際、
コンテナ内は利用者の責任範
囲。
内製 BI ツール
（Argus）
7

8. 現在のデータプラットフォーム - セキュリティ
サービス データプラットフォーム
log
DB
IP 制限 認証
内製 BI ツール
（Argus）
8

9. 現在のデータプラットフォーム
サービス毎に環境を分離
• 環境数: 30+
• 環境を分離することで 権限とコストを明確に管理可能
・・・
・・・
9

10. 最近のトピックス
BI プラットフォーム Looker 導入
• 「データの民主化」「データガバナンスの強化」の両立を目指す
• 詳細は「BEACON」
カスタマーサポートにおける 定性データ分析の効率化
• お客様の声をサービスの改善に活かすための取り組み
• Google のソリューションをフル活用
データプラットフォームの健康診断 の実施
• BigQuery のメタデータを活用し利用状況を可視化
• 多数の GCP プロジェクトを一括管理 & 改善
10

11. BI プラットフォーム Looker 導入
• 「データの民主化」「データガバナンスの強化」の両立を目指す
• 詳細は「BEACON」
カスタマーサポートにおける 定性データ分析の効率化
• お客様の声をサービスの改善に活かすための取り組み
• Google のソリューションをフル活用
データプラットフォームの健康診断 の実施
• BigQuery のメタデータを活用し利用状況を可視化
• 多数の GCP プロジェクトを一括管理 & 改善
最近のトピックス
2
3 データプラットフォーム ガバナンス強化の取り組み
データの民主化を目指して
11

12. データの民主化を目指して
- BI プラットフォーム Looker 導入
- カスタマーサポートにおける定性データ分析の効率化
12

13. BI プラットフォーム Looker 導入
13

14. Looker とは
SaaS 型の BI プラットフォーム
• 他の BI ツールにない特徴を多く備えている
代表的な特徴
• LookML というモデリング言語 を利用して指標の定義を行うことにより、
自動的に SQL を生成して DWH からデータを取得する
• LookML であらかじめ定義された指標を利用することにより、
分析結果などデータの一貫性が担保される
• GUI で操作可能なことは API でも操作可能
2020 年 2 月 13 日に Google による Looker の買収が完了
• 参考）Google completes Looker acquisition
• https://cloud.google.com/blog/topics/inside-google-cloud/google-completes-looker-acquisition
14

15. 背景 - DeNA データプラットフォームの変遷
data
platform
ポイント
20142010 最近
集中管理
品質維持
オンプレ撤廃
データの民主化
ガバナンス強化
内製 BI ツール作成
データの民主化
Hadoop
mobage platform
mobage platform
KPIツール
Hadoop
内製 BI ツール
（Argus）
Vertica
mobage
platform
App / Game
Server
15
mobage
platform
Service
内製 BI ツール
（Argus）
Hadoop
App /
Game
Server

16. BI プラットフォームの Looker に期待していたこと
PoC（投資判断のための検証）期間を経て
2019 年 12 月より正式採用 / 利用開始
データの民主化
● SQL を書けなくてもデータ活用可能であること
● 利用者がデータの意味を理解し適切に使えること
データガバナンスの強化
● データの信頼性と正確さが担保できること
● 内製 BI ツールではSQL スキルが必須
● 新規事業など専任のデータアナリストが不在で
あってもデータ活用ができる状態としたかった
● 内製 BI ツールに数千のSQL クエリが存在
（SQL クエリは数百行におよぶこともある）
● SQL クエリのコピペ& 亜種 & 闇落ち
● SQL クエリの変更の意図が不明
16

17. DeNA での特徴的な使い方
Looker の API を利用し Viewer ツールを開発
開発の目的
• 内製 BI ツールに慣れたユーザーの体験を
維持し Looker への業務移行を行う
• 柔軟なアクセス管理を行う
特徴的な機能
• 左ペインでダッシュボードやレポートの一覧を
ツリー表示
• Space（という独自概念）でアクセス管理を実施
（分析用 Space、CS 用 Space...）
• 各 Space に Google Group を紐付ける
ことで、Google Group に所属するユーザー
が閲覧可能な状態になる
17

18. 導入の効果と課題
効果
• 変更管理（git リポジトリと連携）による データガバナンスの強化
• データの定義を LookML というモデリング言語で定義することによる 保守性の向上
• DB のスキーマが変更となった際、 SQLファイル群から変更箇所を
全て洗い出して修正するなどの対応が不要となった
• Looker Action Hub によるビジネスサイドからのデータ提供
• Dashboard を日次で mail/slack に送る
• 表データを毎月 1 日の AM 10:00 に Google Sheets に同期する
課題
• LookML を複雑にし過ぎるとデータガバナンス / 保守性の面で懸念あり
• DeNA でのベストプラクティスが定義する必要がありそう
• 既存の内製 BI ツールから全ての業務を移行するには
全社へのノウハウ伝播 / レクチャーの仕組みを整えていく必要がある
18

19. 詳細は BEACON Tokyo で！
「Looker 導入の経緯」や「活用事例」を詳細に解説します
https://ja.looker.com/events/beacon/japan
19

20. カスタマーサポートにおける
定性データ分析の効率化
20

21. 課題と解決に向けたアプローチ
課題
解決に向けた
アプローチ
● お客様の声（ご意見、お問い合わせ、各種 SNS データなどの定性
データ）をサービスの改善に活かすためのレポーティング業務に 膨大
な時間（1 サービス 数十時間）がかかっていた
● 全ての内容に目を通しポジネガを判定するなど手作業が多かった
協力体制の構築
カスタマーサポート
×
データエンジニア
サービスのアップデート時など大量
の反響が入っても、すぐに重要な
VOC をピックアップしサービスを改
善可能な状態を目指す！
Google のソリューションをフル活用
しデータパイプラインを構築
● BigQuery
● GKE
● Cloud Natural Language API
● Looker
など
21

22. アーキテクチャ概要
定性データ データプラットフォーム
ご意見
お問い合わせ
各種 SNS データ
ポジネガ判定に
Cloud Natural Language API
を利用
各種 API や Embulk
などを利用
Looker で可視化
22

23. Cloud Natural Language API によるポジネガ判定
ポジネガ判定には analyzeSentiment メソッドを利用
• 文字列
• Google Cloud Storage に存在するファイル
のポジネガ判定が可能
from google.cloud import language_v1
from google.cloud.language_v1 import enums
def main():
client = language_v1.LanguageServiceClient()
type_ = enums.Document.Type.PLAIN_TEXT
text_content = "I am so happy and joyful."
language = "en"
document = {"content": text_content, "type": type_, "language": language}
encoding_type = enums.EncodingType.UTF8
response = client.analyze_sentiment(document, encoding_type=encoding_type)
print(response)
if __name__ == "__main__":
main()
document_sentiment {
magnitude: 0.8999999761581421
score: 0.8999999761581421
}
language: "en"
sentences {
text {
content: "I am so happy and joyful."
}
sentiment {
magnitude: 0.8999999761581421
score: 0.8999999761581421
}
}
23
score: -1.0（ネガティブ）～1.0（ポジティブ）のスコア
magnitude: 指定したテキストの全体的な感情の強度

24. 利用した Looker の機能
ドリルダウン
• 集計データの気になる箇所をクリックするとその詳細を表示するよう設計
• 業務に沿ったダッシュボードの設計 が可能
フィルター
• ゲーム内イベントの期間内での集計
• 特定キーワードが含まれる投稿のみの集計
24
（実際のデータはお見せできないが）
どのような投稿がなされているのか詳細を確認することができる

25. まとめと今後の展望
• カスタマーサポートにおけるレポーティング業務について
Google のソリューションをフル活用し効率化に取り組んだ
• 今回特定サービスの業務改善に取り組んだが、今後は様々なサービスに展開していく
• 各処理は docker コンテナとして動作させている ため短期間で横展開可能
25

26. この section のまとめ
この section では「データの民主化」を目指した取り組みとして以下を紹介した
• BI プラットフォーム Looker 導入
• カスタマーサポートにおける定性データ分析の効率化
BigQuery や Looker の活用により社内のデータ活用水準が向上
データの利用部門のメンバーとの協力体制は重要
26

27. データプラットフォーム
ガバナンス強化の取り組み
27

28. Speakers
株式会社ディー・エヌ・エー （2019 年 9 月 〜）
• データエンジニア
• ゲーム事業におけるデータパイプラインの開発・運用
• BQ ドクター活動の陣頭指揮・推進
城谷 信一郎
（ジョウヤ シンイチロウ）
28

29. この section で話すこと
● DeNA のデータプラットフォームで発生した課題
● 課題に対するガバナンス強化の取り組み
29

30. 現在のデータプラットフォーム
サービス毎に分析環境を分離
• 環境数: 30+
• 環境を分離することで 権限とコストを明確に管理可能
・・・
・・・
再掲
30

31. 現在のデータプラットフォーム
サービス毎に分析環境を分離
• 環境数: 30+
• 環境を分離することで 権限とコストを明確に管理可能
・・・
・・・
Tables
600k +
Projects
100 +
Scan
1PB/day
再掲
31

32. • 不必要に嵩むコスト
• 使われず放置されたテーブルと動き続けるパイプライン
• 高コストなクエリスキャン
• データ利用の生産性低下
• 複雑になったデータパイプラインの保守・運用コスト
• RAW データへのクエリスキャン
• セキュリティリスク
• IAM アカウントの監査・適切な権限管理
• PII （個人情報）データの監視
DeNA データプラットフォームの課題
32

33. ● BQ 警察として活動
● 主な対応としては
• 不要テーブルの削除
• クエリの見直し
• テーブル設計の見直し
• 中間集計の実装
● BigQuery の利用料を 46% 削減
BQ 警察活動によるガバナンス維持
Google Cloud Next ’19 in Tokyo
https://www.youtube.com/watch?v=k1CpRz0C6B8
33

34. プロジェクトにおけるコストの多寡で調査対象が決まる
• 問題が有ったとしても コストとして見えなければ放置 されがち
e.g. 依頼に基づきパイプラインを作成したが既に利用されていない
e.g. raw データへの非効率なクエリスキャン
問題が発見されてからの対処にとどまる
• 常にすべてのプロジェクトが 最適な状態になっているか分からない
• 最適な状態の定義が出来ていない
BQ 警察の課題
34

35. BQ ドクター活動による継続的な改善
問題の検知
是正・対処
振返り・横展開
診断・調査
ヒアリング
是正・対処
振返り・横展開
BQ 警察 BQ ドクター
進化
35

36. BQ ドクターのアウトライン
1. 可視化の統合・通知の自動化
2. 最適な状態の定義と運用の設計
3. BigQuery コスト最適化のための挑戦
36

37. 可視化の統合・通知の自動化
BQ 警察
可視化
通知
BQ ドクター
Cloud Monitoring
(Action Hub)
Digdag workflow
Apps Script
内製 BI ツール
(Argus)
ソース
データ
Cloud Logging
(Audit Log)
BigQuery
(INFORMATION_SCHEMA)
BigQuery
(Billing Report)
BigQuery
(Billing Report)
37

38. 可視化の統合・通知の自動化
Kubernetes Engine
BigQuery
Container RegistryDigdag workflow
Project A
BigQuery
Project B
BigQuery の JOB 監査ログ
Dataset,Table のメタデータ
Management ProjectBigQuery のメタデータ
・INFORMATION_SCHEMA
・{DATASET}.__TABLES__
BigQuery のメタデータ
・INFORMATION_SCHEMA
・{DATASET}.__TABLES__
kubectl
apply
Container
Deploy
Python Program
● 100 プロジェクト程度のメタデータを収集
● Multiprocessing で並列処理
BigQuery
38

39. BigQuery の JOB 監査ログ
Dataset,Table のメタデータ
Management
Project
Dashboard
Action Hub
Slack
Google Sheet
全プロジェクトで定期診断
利用者へ通知
可視化の統合・通知の自動化
短期的な問題は定期 診断を
待たず
緊急オペを実施する
39

40. 可視化の統合・通知の自動化
可視化
の範囲
得られる
情報
得られる
示唆
BQ 警察 BQ ドクター
・Audit Log Sink の
範囲で統合
※コストは統合
・データプラットフォーム
で統合
・GCP コスト
・BigQuery の監査情報
・GCP コスト
・BigQuery の監査情報
・BigQuery の状態
・GCP コストの多寡
・スキャン量の多いクエリ
・GCP コストの多寡
・スキャン量の多いクエリ
・非効率なクエリ
・無駄なテーブル 40

41. 無駄なリソースの見直しを行い を高められている状態
最適な状態の定義と運用の設計
今回の取り組みでは以下 3 つの達成が最適な状態 として定義
BigQuery 状態の健全性
利用見直しを行い を高められている状態
無駄な利用を減らして を下げられている状態
41
GCP コスト ($)
BigQuery 利用の健全性

42. 最適な状態の定義と運用の設計
最適な状態を KGI とし KPI を定義し可視化・診断 に利用
GCP コスト($)
BigQuery 利用の健全性
BigQuery 状態の健全性
BigQuery クエリコスト ($)
BigQuery ストレージ
コスト ($)
BigQuery クエリの
Slot 利用状況
BigQuery クエリの
実行時間状況
現在不要な
BigQuery テーブル
将来不要な
BigQuery テーブル
これらを具体的に
可視化し診断に利用
KGI KPI
プロダクト毎のコスト ($)
42

43. 最適な状態の定義と運用の設計
四半期に 1 度程度のサイクルで全プロジェクトの診断を実施
1. プロジェクト選定
2. 事前調査
3. 調査報告書作成
4. 是正・ヒアリング方針を
決定
診断・調査
1. 利用者ヒアリング
2. 是正方法の検討
3. 是正対応の実施
4. 効果測定
ヒアリング・是正
1. プロジェクト毎に対応結
果を共有
2. 振り返り・見直し
3. 横展開の検討
振り返り・横展開
43

44. 最適な状態の定義と運用の設計
参照がされていないのに存在するテーブルは金額
を提示した上で、要る/ 要らない。必要期間をヒア
リング
クエリスキャン量については、個人/ レポートレベル
で調査し、ヒアリング
※ 数値やヒアリング内容は仮のもの
不要なテーブルヒアリングの例
BigQuery 利用状態のヒアリングの例
44

45. 最適な状態の定義と運用の設計
現在の成果
1. 非効率なクエリの発見と改善
• RAW テーブルへの頻繁参照されるクエリを発見
• 中間集計の開発中
2. 巨大な参照されていないテーブルの探索と是正
• オンプレからの移行に伴い取得されていたテーブル
• 合計すると数百 TB のテーブルであったため是正対応
• 不要テーブルは削除
• 必要な場合も time_partitioning_expiration を適切に設定
• 1 つのプロジェクトで年間約 200 万程度の削減
45

46. BigQuery コスト最適化のための挑戦
さらなる最適化のために BigQuery Reservations の活用を検討
• BigQuery Reservations では分単位での Flex Slots の割当が可能
• ワークロード毎、プロジェクト毎に 割り当てる Slots を柔軟にコントロール
• 100 Slots / hour あたり 4$ (2020/9 現在）
46
BigQuery
(分析データ）
Project A
バッチ実行
BI ツール
Adhoc
BigQuery
(分析データ）
Project B
バッチ実行
BI ツール
Adhoc
Assignment
1500 Slot
BQ Reservations
management project
Assignment
500 Slot
Capacity
Commitment
2000 Slot
46

47. 最適な BigQuery Reservations 適用を検討
• ワークロード問わず実行プロジェクトが同一なため、 必要な Slots に波がある
• Slots の Capacity 適用によるデータ提供時間の遅延も最小限に
• 時間帯毎に最適な Slots の適用が、データ提供時間とコストメリットを両立させる
BigQuery コスト最適化のための挑戦
バッチ時間帯 バッチ時間業務時間帯( BI / Adhoc )

48. オンデマンドより BigQuery Reservations のコストメリットのある時間を可視化
• BigQuery の監査情報から時間を調査
• オンデマンドクエリコスト（5$ * 実際のスキャンTB ) - Reservation コスト( 時間当たりのFlex Slots コスト $ * 実際の slots 消費量)
BigQuery コスト最適化のための挑戦
このプロジェクトでは、BigQuery Reservations のコストメリットが高い
時間帯が固定的＝ つまりバッチ時間の可能性が高い
48

49. BigQuery コスト最適化のための挑戦
Slots の購入
（commitment)
Reservation の作成
Project を Reservation
へ割当
Create BigQuery
Reservations
Reservation から Project
の割当を削除
Reservation の削除
Slots commitment の
削除
Management Project
Delete BigQuery
Reservations
Management Project
Assignment Project
FlatRate Query
Reservation を削除する際に、 create時
に生成された名前を利用するため、 GCS
に管理情報として保管する
BigQuery Reservations 検証環境
時刻起動
時刻起動
49

50. BigQuery コスト最適化のための挑戦
BigQuery Reservations 利用の現在と今後について
• 現在は、環境構築および開発が完了しており、本番環境で検証を実施中
• 本格適用に向けての検討も行っている
• Project 毎の Reservation 適用有無、 割当 Slot 、 スケジュールの管理方法
• Adhoc に大量のスキャンが想定される場合のインタフェースの提供
ゆくゆくは
• Slot 消費量、スキャン量のログから ML モデルを作成し自律的な適用へ
50

51. BQドクターの現在と今後の展望
可視化・
診断項目の設計
統合環境の
構築
運用設計・
開発
評価 今後
・必要に応じデータ収集
・運用プロセスの磨き込み
・運用の自動化機能の開発
・BigQuery Reservations の本格適用
・生産性 / セキュリティに
関する情報・示唆を得るための開発
・zetaSQL , Data lineage
・IAM Recommender
・約 100 プロジェクトの
統合環境の構築が完了
・コストおよび BigQuery の
使われ方、状態を可視化・診断
・定期的な調査 / 診断 / 是正のス
キーム確立
51

52. この section のまとめ
● DeNA のデータプラットフォームで発生した課題
○ 分析環境を分離することで柔軟になったが、 非効率な利用に気づき辛く なった
● 課題に対するガバナンス強化の取り組み
○ BQ ドクター活動にて、最適を定義し横断でモニタリング・是正を行う 環境・
枠組みを作る事ができた
○ 生産性 / セキュリティを高めるための最適の定義と、可視化・診断のための 活動は
引き続き行う
○ BigQuery Reservations の適用に向けて、検討・開発を引き続き行う
52

53. まとめ
53

54. 本日お話したこと
54
DeNA のデータプラットフォーム
データの民主化を目指して
データプラットフォーム ガバナンス強化の取り組み
1
2
3
サービス毎に分離した GCP プロジェクトの設計、データプラットフォームの提供
データプラットフォームに Looker を導入しデータの民主化を促進
これまでデータ活用が進まなかった部署へデータ活用を推進
BQ ドクター にてデータプラットフォームを常に最適な状態に近づける活動の紹介

55. DeNA Tech の Twitter アカウントでは、
DeNA のエンジニアリングに関する
登壇資料やブログを紹介しています！
ぜひ Twitter をフォローしてみてください！
55