DeNA のデータ活用を支える BigQuery データの民主化とガバナンス強化の軌跡 | Google Cloud INSIDE Games & Apps: Online
•
1 gefällt mir•1,811 views
第 11 回 Google Cloud INSIDE Games & Apps にご登壇いただいたスライドです。 株式会社ディー・エヌ・エー データエンジニア / グループマネージャー 岩尾 一優様 データエンジニア 城谷 信一郎様
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie DeNA のデータ活用を支える BigQuery データの民主化とガバナンス強化の軌跡 | Google Cloud INSIDE Games & Apps: Online
Ähnlich wie DeNA のデータ活用を支える BigQuery データの民主化とガバナンス強化の軌跡 | Google Cloud INSIDE Games & Apps: Online (20)
Mehr von Google Cloud Platform - Japan
Mehr von Google Cloud Platform - Japan (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
DeNA のデータ活用を支える BigQuery データの民主化とガバナンス強化の軌跡 | Google Cloud INSIDE Games & Apps: Online
- 1. DeNA のデータ活用を支える BigQuery データの民主化とガバナンス強化の軌跡 株式会社ディー・エヌ・エー データエンジニア / グループマネージャー 岩尾 一優 株式会社ディー・エヌ・エー データエンジニア 城谷 信一郎
- 2. Speaker 2 株式会社ディー・エヌ・エー （2018 年 7 月 〜） • データエンジニア / マネージャー • データエンジニア組織の戦略策定・推進 • BI プラットフォーム Looker の全社導入を推進 （複業）株式会社 Hogetic Lab（2019 年 4 月 〜） • 外部取締役 CTO • データ分析コンサル / 組織コンサル 岩尾 一優 （イワオ カズマサ）
- 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
- 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
- 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