DeNA データプラットフォームにおける自由と統制のバランス【DeNA TechCon 2020 ライブ配信】

DeNA データプラットフォームにおける
自由と統制のバランス
岩尾一優大橋宣宏

Speakers
大橋宣宏（オオハシノブヒロ）
• データエンジニア
岩尾一優（イワオカズマサ）
• データエンジニア / マネージャー
• #BQ警察

本日お話すること
• データエンジニアの役割（4 分）
• DeNA のデータプラットフォーム（20 分）
• データプラットフォームの健康診断（14 分）

伝えたいこと
自由を最大化するための
統制の取れたデータプラットフォームとは

• 自由
• DeNA ではデータに基づき意思決定をする文化が根付いている
• データの利用者はスピード感を損なわず「自由」に分析したい
• 統制
• データの利用者が安心して分析できるよう（事故らないよう）
安定したデータプラットフォームを提供する必要がある
• 自由で統制の取れたデータプラットフォーム
の実現に向けた DeNA データエンジニアのアプローチ
伝えたいこと

コメント、質問をお待ちしております
• Twitter / YouTube Live からの投稿お待ちしております！
• #自由と統制のバランス
のハッシュタグで質問ツイートをいただけると
本日回答できなかった場合にも
DeNA Analytics Blog - Medium などで後日回答差し上げます。

• BigQuery の利用におけるコスト削減の取り組み
• Google Cloud Next '19 in Tokyo で発表済み（2019/08/01）
• BigQuery を使い倒せ！DeNA データエンジニアの取り組み事例
• https://cloud.withgoogle.com/next/19/tokyo/sessions?session=D2-2-S09
• オンプレ（Hadoop/Vertica）からクラウド（BigQuery）への移行の詳細
• Google Cloud Data Platform Day #2 で発表予定（2020/03/31）
• Google Cloud を使ったデータプラットフォームへの変革と最新の活用状況について
• https://cloudonair.withgoogle.com/events/jp-data-platform-day
• DeNA が Looker を採用した経緯
• Looker Game Night で発表予定（時期未定）
• https://discover.looker.com/Q1Y2020JPNGameEvent.html
本日お話しないこと

データエンジニアの役割

DeNA の分析組織の成り立ち
• 2011 年
• 全社横断組織としてデータ分析組織が誕生
• 様々な事業の分析を担当
• 2016 年
• ゲーム事業の分析組織が独立
• 他の事業部にもそれぞれ分析担当が所属
• 2019 年
• 全社のデータ活用水準を高めていく目的で分析推進部が発足

ゲーム事業
DeNA のデータエンジニアの位置付け
システム本部（全社横断組織）
分析推進部
データプラットフォーム G
分析部
データエンジニアリング G
その他の事業
※各事業部内のエンジニアが
データエンジニアリングを兼任
連携
サポート
サポート

Our Vision
DeNA におけるデータ活用水準向上のため
データの利用者に寄り添いながら
最適なデータプラットフォームを提供し続ける

注力領域
• DeNA のデータ活用水準の向上
• 利用者のサポート強化
• 新規 BI ツール（Looker）の導入
• データプラットフォームの
健康指標の可視化
• クラウド移行

注力領域
• DeNA のデータ活用水準の向上
• 利用者のサポート強化
• 新規 BI ツール（Looker）の導入
• データプラットフォームの
健康指標の可視化
• クラウド移行
データプラットフォームについて
約 20 分間お話します
データプラットフォームの健康診
断について約 14 分間お話します

DeNA の
データプラットフォーム
〜自由で安全なデータプラットフォームを構築するまで〜

本セクションでお話すること
• 分析環境の「自由と統制」の変化
• 相乗り中央管理から分離へ
• before / after

分析業務の担い手、データアナリスト
アナリストの役割は、
• 事業の KPI を管理、事業計画の策定支援をおこなう
• サービスの機能やキャンペーンなどの施策を評価し、PDCA をまわす
• アドホック分析でデータから示唆を取り出し、意思決定の材料を作る
その手段として、
• 事業責任者やプランナーとの入念なコミュニケーションを経て意思決定
• 深いドメイン知識からの筋の良い仮説構築とデータの解釈
• KPI 可視化およびレポーティングの仕組みの構築
• データの整備による分析の生産性と品質の向上
• 適切な統計手法や機械学習による課題解決

分析業務の担い手、データアナリスト
アナリストの役割は、
• 事業の KPI を管理、事業計画の策定支援をおこなう
• サービスの機能やキャンペーンなどの施策を評価し、PDCA をまわす
• アドホック分析でデータから示唆を取り出し、意思決定の材料を作る
その手段として、
• 事業責任者やプランナーとの入念なコミュニケーションを経て意思決定
• 深いドメイン知識からの筋の良い仮説構築とデータの解釈
• KPI 可視化およびレポーティングの仕組みの構築
• データの整備による分析の生産性と品質の向上
• 適切な統計手法や機械学習による課題解決
データエンジニアリングで支援している領域

データアナリストと分析工程
データ設計収集/保存加工活用
データの選定、収集
ログ設計
マスターデータ
トランザクションデータ
外部調査データ
DWH へのデータ取り込み
テーブルスキーマの管理
定期取り込み
Fluentd / Enbulk
Medjed (内製 ETL ツール)
BigQuery/Hadoop
中間集計、前処理
ワークフローの管理
計算リソースの管理
Jenkins / Digdag
SQL / Python
レポーティング、分析
KPI ダッシュボード
Adhoc 分析
事業指標予測
Looker / Argus (内製 BI)
スプレッドシート
Jupyter
Python / R
業務支援ツールの内製

ログ設計
定期取り込み
Fluentd / Enbulk
BigQuery/Hadoop
Jenkins / Digdag
SQL / Python
Adhoc 分析
事業指標予測
Jupyter
Python / R
データエンジニアリングで支援している領域

分析環境における「自由と統制」のコンセプト
自由
早く、ストレスなく、アナリストの判断で分析業務に関わる工程を遂行できる環境
統制
データ漏洩などのリスクを下げつつ、適切なコストで業務を遂行させる環境

分析環境における「自由と統制」(before)
自由
収集/保存/加工/活用においてアナリストが自由にスクリプトを書き、デプロイできる環境
GUI で直感的にジョブを定義登録できるワークフローツール(Jenkins)
統制
分析環境(物理サーバ)へログインするための踏み台、ネットワーク経路の制御
Hadoop サーバコストを HDFS のディレクトリ単位で集計しストレージ容量で事業に按分

🤔
オンプレなので...

オンプレからクラウドへ分析環境移行過渡期
2010 年に内製 Hadoop クラスタを構築し
2011 年からアナリストという役割が存在
2015 年ころから
Hadoop と BigQuery
オンプレとクラウドの併用が始まり
現在はクラウド移行過渡期の終盤
オンプレ時代の反省を踏まえつつ、
クラウド環境にマッチした分析環境を構築

スクリプトやワークフローの管理
ログ設計
定期取り込み
Fluentd / Enbulk
BigQuery/Hadoop
Jenkins / Digdag
SQL / Python
Adhoc 分析
事業指標予測
Jupyter
Python / R
オンプレ環境で問題が顕在化

分析環境における「自由と統制」(before)
自由
収集/保存/加工/活用においてアナリストが自由にスクリプトを書き、デプロイできる環境
GUI で直感的にジョブを定義登録できるワークフローツール (Jenkins)
統制

Service B
Service A
DeNA のオンプレ分析環境について (before)
App
Server
LOG
DB
...
Log
Collector
DB
Snapshot
Hadoop
Medjed(内製)
Vertica
Argus(内製)
Batch
Jenkins
サービス環境オンプレ環境クラウド環境
gateway
ssh
https
アクセス
制限
多数のサービス
で相乗り

Batch サーバーの利用状況について
• Linux がセットアップされたサーバー
• 利用者が個人アカウントで ssh でログイン
• スクリプトの作成や実行を自由に実施可能
• 結果、膨大な量の個人ディレクトリが作成されることに！
各 Batch サーバーの
個人ディレクトリ数

Jenkins サーバーの利用状況について
• 自由にワークフローを作成した結果
Jenkins の Dependency Graph が大変なことに！
触りたくない

以下の通り分類
1. 構成管理ができていない
• 管理されていないスクリプトやワークフローの散在
1. 実行環境の分離ができていない
• 一つの環境に多数サービスのスクリプトやワークフローが混在
オンプレ環境の課題

以下の通り分類
1. 構成管理ができていない
• 管理されていないスクリプトやワークフローの散在
1. 実行環境の分離ができていない
• 一つの環境に複数サービスのスクリプトやワークフローが混在
オンプレ環境の課題について
こちらの具体例を紹介

目的や作成者が不明なワークフロー
構成管理ができていない
16 個 untracked file
「構成管理」が出来ていないことで、
データの消失やリソースの無駄な消費が発生

実行環境の分離ができていない問題
「実行環境の分離」ができておらず、
誰かの変更が他の誰かに影響を与えやすい状況となっていた。
• 1 台の Jenkins サーバーで 38 サービス 814 個のジョブが稼働
• 影響範囲の把握ができずメンテや設定変更が困難に
• 環境変数や設定の変更による他サービスの障害の誘引
• gcloud config set project 実行による予期せぬ動作

ここまでのまとめ
課題対応する問題
構成管理ができていない
コードの消失
無駄なリソースの消費
実行環境の分離ができていない
メンテナンスや設定変更が困難に
他サービスの障害の誘引

オンプレ環境の運用に関するまとめ
オンプレ環境の統制は相乗り環境のため、容量監視によるシステ
ムの障害防止やデータセキュリティなどに向けられていた。
環境の利用方法に統制を設けないまま、自由に業務をした結果。
• 他サービスの自由を奪う
• 必要な構成変更ができない
など、自由を奪う結果に！

• 分析環境の「自由と統制」の変化
• 中央管理から分離へ
• before / after

構成検討
クラウド移行に伴う対応方針を検討
課題対応方針
構成管理ができていないスクリプトとワークフローの git 管理
サービス毎の分析環境の分離
コンテナを境界とした責務の分離

DeNA オンプレ
クラウド移行後のシステム構成
Cloud Load
Balancing
Identity-Aware
Proxy
Cloud
Armor
Kubernetes cluster
Kubernete
s
Engine
pod
Cloud
SQL
Cloud
NAT
Cloud
StorageGithub
Enterprise
タスク
ログ
ssh
https
BigQuery
ソース
IP 制限
認証

コードとワークフローの git 管理
課題対応方針
構成管理ができてないスクリプトとワークフローの git 管理
実行環境の分離が出来ていない
サービス毎の分析環境の分離

digdag（新環境で採用）
ワークフローを
コード（.dig ファイル）として定義
Jenkins（旧環境）
ワークフローの作成、変更が
web で完結しコード管理不可
ワークフローに digdag を採用

スクリプトとワークフローの git 管理
ワークフローやスクリプトが
自然に github で管理されるような運用フローを整備。
Kubernetes cluster
Kubernete
s
Engine
pod
DeNA オンプレ
Github
Enterprise
git clone & digdag push
するワークフロー
を実行
ワークフローや
スクリプトを同期

補足 − github との同期
git clone & digdag push を実施するワークフロー
（データエンジニアが各環境に配布）
git clone と
digdag pushを実施

課題対応方針
構成管理ができていないスクリプトとワークフローの git 管理
サービス毎に分析環境を分離

サービス毎に分析環境を分離
サービス毎に GCP プロジェクトを分離。
影響範囲をサービス単位に絞り込める。
今後も構築する環境は増加予定。
環境構築は Terraform を利用して簡略化。
サービスA
サービスB
サービスC
サービスD

Terraform での環境構築の工夫
Terraform のモジュール機能を利用し、
新しい環境構築時は変数の設定のみで済むようにした。
個別の環境向けの変
数をファイルで設定

• 基本的なワークフローは digdag コンテナ内で実行可能
• ML などの複雑な分析を行うための独自コンテナも実行可能
コンテナ
イメージを作成
& アップロード
Container
Registry
Kubernetes cluster
Kubernete
s
Engine
pod
コンテナを実行する
ワークフローを起動
自由に
ツールを導入
起動
複数GCPで
共有も可能

GKE 上で複数スペックのノードプールを作成。
• digdag は default ノードとして必要最低限のスペックで準備。
• その他に ML なども実行できる高スペックなノードも準備。
目的別のコンテナ実行環境について
defaultの
ノード
特別用途のノ
ード
digdag が稼働

高いスペックを要求すると
スペックが高いノードで起動
GPU を要求すると
GPU つきのノードで起動
コンテナの実行環境は設定ファイルに記載した要求リソースで
自動的に選択される。
コンテナ実行環境の選択
~~ 省略 ~~
resources:
requests:
memory: "4Gi"
cpu: "3"
~~ 省略 ~~
~~ 省略 ~~
resources:
limits:
nvidia.com/gpu: 1
~~ 省略 ~~

補足 − digdag からコンテナの実行
以下の様なジョブでマニフェストで指定したコンテナを実行。

分析環境における「自由と統制」(after)
自由
属人化に強く、人の入れ替わりに耐える管理されたスクリプトとワークフロー
統制
サービスごとに GCP プロジェクトをわけ GKE で環境を分離し、digdag でワークフロー管理

データ設計加工活用
ログ設計
Jenkins / Digdag
SQL / Python
Adhoc 分析
事業指標予測
Jupyter
Python / R
収集/保存
定期取り込み
Fluentd / Enbulk
BigQuery/Hadoop
GKE で取り組み加速

「活用」への自由の伝播
実行環境の分離を実施した結果。
• サービス毎に分析環境を分離
• サービス毎に環境のカスタマイズが実行可能に。
• コンテナを境界とした責務の分離
• 利用者の目的に合わせた独自コンテナを実行可能に。
分析環境のカスタマイズと独自コンテナを組み合わせることで、
既存環境には無い拡張性が生まれた。
「活用」の部分にまで自由を伝播。

新しい拡張性の具体例
以下は環境のカスタマイズ（LB + Cloud Armor + Cloud IAP 追加）
と独自コンテナの組み合わせを利用した具体例。
• Web サーバーの利用による新しいレポーティングの実行
• JupyterLab 環境の提供

GKE はバッチ処理の実行だけでなく、
永続的に稼働するアプリケーションの実行も可能。
レポーティング用の web アプリケーションは利用者が作成
（責務の分離）。
Web サーバーの利用による新しいレポーティングの実行
Cloud Load
Balancing
Cloud
Armor
コンテナ
イメージを作成
& アップロード
Container
Registry
Kubernetes cluster
Kubernete
s
Engine
pod
web アプリケー
ションを作成
Identity-Aware
Proxy
デプロイCloud
Armor

digdag の構成を流用して、 web アプリケーションの
コンテナイメージを IP 制限と認証付きで起動できる。
Web サーバーの利用による新しいレポーティングの実行
Cloud Load
Balancing
Cloud
Armor
Kubernetes cluster
Kubernete
s
Engine
pod
Identity-Aware
Proxy
HTTPS
Cloud
Armor

自由
分析由来のサービス支援ツールの開発を加速する環境
統制
サービスごとに GCP プロジェクトをわけ、GKE で環境を分離し、digdag でワークフロー管
理

Service B
Service A
DeNA のオンプレ分析環境について (before)
App
Server
LOG
DB
...
Log
Collector
DB
Snapshot
Hadoop
Medjed(内製)
Vertica
Argus(内製)
Batch
Jenkins
サービス環境オンプレ環境クラウド環境
gateway
ssh
https

DeNA オンプレ
DeNA のクラウド分析環境について (after)
Cloud Load
Balancing
Identity-Aware
Proxy
Cloud
Armor
Kubernetes cluster
Kubernete
s
Engine
pod
Cloud
SQL
Cloud
NAT
Cloud
StorageGithub
Enterprise
タスク
ログ
ssh
https
BigQuery
ソース
IP 制限
認証

自由
分析由来のサービス支援ツールの開発を加速する環境
統制
サービスごとに GCP プロジェクトをわけ、GKE で環境を分離し、digdag でワークフロー管
理
コストだけなく、データの利用状況を診断し改善する仕組み... ( 詳細は後半で )

データプラットフォームの
健康診断
〜データ活用の改善に向けて〜

• データプラットフォームの健康診断とは
• データプラットフォームの健康指標
• メタデータと AUDIT LOGS の効果的な活用方法

本セクションで伝えたいこと
• BigQuery は使い勝手がよく
スケーラビリティに優れた DWH
• 管理する GCP プロジェクトが多くなればなるほど
ガバナンスが効きにくくなる
• データの利用者に対してシステム的な制限をかけずに
データ活用を改善するアプローチ

DeNA における BigQuery の活用規模
DeNA における
BigQuery の活用規模をご紹介します

DeNA における BigQuery の活用規模（2020 年 2 月時点）
GCP プロジェクト
30 +
ストレージ
3PB +
クエリ検索
10PB/月 +

昨年度の取り組み - BQ 警察によるコスト削減

680 万円 / 月
（2018 年 9 月時点）
370 万円 / 月
（2019 年 3 月時点）
DeNA ゲーム事業における
BigQuery の利用料を半年間で 46% 削減

（主にコスト面で）目立った問題に対して以下の対策を行った。
BigQuery の利用料を削減するための取り組み
課題対策
クエリ検索量の増加
Clustered Tables の導入
JSON ペイロードの parse による
新規データマートの作成
BI ツールの不要な定期実行を停止
ストレージ容量の増加各テーブルのデータライフサイクルの見直し
巨大クエリ実行時の問題検知の仕組みがない巨大クエリ実行時の Slack 通知機能の開発

新たな課題
• 目立った問題は解消してきたものの
30 以上あるそれぞれの GCP プロジェクトが
適切に運用されているかわからない
• 運用の「適切さ」をどう判断するかの基準がない

新たな課題 - 例
• 依頼をもとに作成したデータマートが
実は 1 年前から使われていなかった
• データマートを作ればよいのに
raw データを高頻度で検索していた

データプラットフォームの健康診断とは
データプラットフォームが
適切に運用されているか確認できる状態にすること
Not BQ 警察 but BQ ドクター！

データプラットフォームの健康指標は何か？

データプラットフォームの健康指標（KPI）の例
A. GCP（主に BigQuery）のコスト
• 他のサービスに対してコストがかかりすぎていないか
• サービスの売上に対してコストの比率が高すぎないか
A. データの利用状況
• 作成したデータマートが使われているか
• raw データが高頻度で使われていないか
• 誰も使っていない巨大テーブルがないか
などなど

データプラットフォームの健康指標（KPI）
• 請求データを使えば、簡単に可視化することが可能
• 可視化するには工夫が必要

データプラットフォームの健康指標（KPI）
• 請求データを使えば、簡単に可視化することが可能
• 可視化するには工夫が必要
この点について
解説します

「データの利用状況」をどうやって可視化するのか
1. BigQuery に保存されている全てのデータの可視化
1-1. データセットのメタデータ
1-2. メタテーブル（__TABLES__）
1. 「誰が」「いつ」「どこで」「何を」行ったかの可視化
2-1. AUDIT LOGS

各 GCP プロジェクトから
2-1. AUDIT LOGS
を収集。
システム構成
プロジェクト A
プロジェクト N
AUDIT LOGS を
BigQuery にシンク
「データセットのメタデータ」
「メタテーブル（__TABLES__）」
を実体化
プロジェクト（監視用）

• INFORMATION_SCHEMA.SCHEMATA を用いる
• 各 GCP プロジェクトに対して bq query コマンドを用いて
以下の SQL クエリを発行し、テーブルとして保存
SELECT
* EXCEPT(schema_owner)
FROM
INFORMATION_SCHEMA.SCHEMATA
プロジェクト名
データセット名

• テーブルのレコード数やデータ容量を取得するには
メタテーブル（__TABLES__）を用いる
• 前頁と同様 bq query コマンドを用いてテーブルとして保存
SELECT
*
FROM
${DATASET}.__TABLES__
作成日時
最終更新日時
レコード数
データ容量

2-1. AUDIT LOGS
• データの使われ方を明らかにするには AUDIT LOGS を用いる
• 例 1）発行された SQL クエリや検索したデータ量
• 例 2）SQL クエリの発行先のテーブル名
• AUDIT LOGS を BigQuery にシンクするには
• Stackdriver Logging のコンソールでシンクを作成
• gcloud コマンドでシンクを作成
AUDIT LOGS を
BigQuery にシンク

補足 - gcloud コマンドを用いたシンクの作成
• AUDIT LOGS を BigQuery にシンクするための
gcloud コマンド（gcloud alpha logging sinks create）
※現状は alpha 機能
もうちょい良い感じに書く
GCP コンソール？
コマンド？
gcloud alpha logging sinks create ¥
--project=${PROJECT_ID} ¥
--use-partitioned-tables AUDIT_LOGS_V2¥
bigquery.googleapis.com/projects/${PROJECT_ID}/datasets/AUDIT_LOGS_V2¥
--log-filter "resource.type=bigquery_project"

補足 - INFORMATION_SCHEMA.JOBS_BY_*
• INFORMATION_SCHEMA.JOBS_BY_* ビューが β に！
• BigQuery ジョブ（現在 + 過去 180 日間）
に関するメタデータを取得可能
• BigQuery ジョブの可視化については
AUDIT LOGS から代替可能

ここまでのまとめ
データの利用状況の可視化についてのまとめ
No. 可視化したい内容手順利用するデータ
1-1 BigQuery に保存さ
れている全てのデ
ータの可視化
データセット一覧と
メタデータを取得する
INFORMATION_SCHEMA.SCHEMATA
1-2 テーブル一覧と取得する
メタデータを取得する
${DATASET}.__TABLES__
2-1 「誰が」「いつ」
「どこで」「何
を」行ったかの可
視化
- AUDIT LOGS
※一部は
INFORMATION_SCHEMA.JOBS_BY_* でも
代替可

プロジェクト（監視用）
各 GCP プロジェクトから
収集した以下のデータを
looker でダッシュボード化
① データセットのメタデータ
② メタテーブル（__TABLES__）
③ AUDIT LOGS
システム構成
プロジェクト A
プロジェクト N

ダッシュボードの例 - データの利用状況
ある GCP プロジェクトのデータセット内で
過去 30 日に利用されているテーブルの割合(%)
データセット内のテーブルの
過去 30 日間の利用頻度（回）

ダッシュボードの例 - データの利用状況
ある GCP プロジェクトにおいて 1 度も使われていない10GB 以上のテーブル

ダッシュボードの例 - コスト

BQ ドクターの業務イメージ
• 各サービスの担当者と定期的に面談（健康診断）
• データプラットフォームの健康指標に基づいた
データ活用の改善方法を提案
• 現在はいくつかのサービスで仮運用中

本セクションのまとめ
• メタデータと AUDIT LOGS をフル活用し
データプラットフォームの健康状況を可視化
• データの利用者と対話しながら
BQ ドクター業務を日々アップデート中

本日のセッション
全体の振り返り

本日話したこと
• データエンジニアの役割
• ビジョンや注力領域
• 自由で統制の取れたデータプラットフォーム
の実現に向けた 2 つのアプローチ
データプラットフォームの健康診断
メタデータや AUDIT LOGS をフル活用し
データの利用状況を可視化
DeNA のデータプラットフォーム
「実行環境の分離」や「構成管理」などの
統制による利用者の自由の最大化

Our Vision（再掲）
DeNA におけるデータ活用水準向上のため
データの利用者に寄り添いながら
最適なデータプラットフォームを提供し続ける

気になる点などあれば気軽に投稿してください！
#自由と統制のバランス

DeNA データプラットフォームにおける自由と統制のバランス【DeNA TechCon 2020 ライブ配信】

DeNA データプラットフォームにおける 自由と統制のバランス【DeNA TechCon 2020 ライブ配信】

More Related Content

What's hot

Similar to DeNA データプラットフォームにおける 自由と統制のバランス【DeNA TechCon 2020 ライブ配信】

More from DeNA

Recently uploaded