Google Cloud を使ったデータプラットフォームへの変革と 最新の活用状況について

2020-03-31 の

2020/03/31 に開催された「Google Cloud Data Platform Day #2」での

・システム本部分析推進部データプラットフォームグループ　長谷川 了示
・ゲーム・エンターテインメント事業本部ゲーム事業部 Publish 統括部 分析部 データエンジニアリンググループ　城谷 信一郎

の登壇資料です。

Transcript

1. Google Cloud を使ったデータプラットフォームへの変革と 最新の活用状況について 株式会社ディー・エヌ・エー 長谷川 了示 システム本部分析推進部データプラットフォームグループ 城谷 信一郎 ゲーム・エンターテインメント事業本部ゲーム事業部 Publish 統括部 分析部 データエンジニアリンググループ
2. 長谷川 了示（Ryoji Hasegawa） • 新卒 -> ITコンサルティング • 製品開発@分析系SaaS ベンダ • 2016年9月 DeNA 入社 ◦ 全社データプラットフォームの企画・構築・運用 ◦ 今回のテーマであるデータプラットフォーム刷新を立 ち上げからリード 2 Speakers
3. 3 本日お話する内容 1 2 データ プラットフォームの刷新 なぜGoogle Cloud を選んだのか？ 新データ プラットフォームの全貌 設計思想と実装 3 4 Google Cloud をフル活用した事例 新データ プラットフォームへ効率の良い移行方法
4. Section 1 データ プラットフォームの刷新 なぜGoogle Cloud を選んだのか？
5. このSection でお話すること 5 • 旧データ プラットフォームとその課題 • データ プラットフォーム刷新プロジェクト「ポリモフ」 • なぜGoogle Cloud を選んだのか？
6. DeNA On-Premises • 怪盗ロワイヤルに代表されるモバイルゲームの大ヒットを背景に、大規模データプラット フォームを整備 • 2010年から、Hadoop の運用を開始。 • ちなみに ”Hadoop: The Definitive Guide” (象本)の初版出版が2009年 • 現在の総データ量: 2.5PB+ • 大部分はオンプレミス（ 2015年頃からBigQuery を利用） 6 旧データ プラットフォームの全体像 Service Env Data Platform Service A Hadoop Argus Batch Server BigQuery App Server DB Server app logs snapshot Jenkins Hue batch job management Service B Service C …
7. 7 旧データ プラットフォームの特徴 • 多種多様な利用者 • 高いレベルの自由度 • マルチテナント
8. DeNA グループ全社員の4割強 旧データ プラットフォームの特徴: 多種多様な利用者 8 ゲーム以外の サービス 5 + ゲームタイトル 15 + BIツールの Monthly Active User 1,000 - アナリスト（データ分析担当者）から企画、経営層まで幅広い利用者
9. • SQL クエリ作成 • レポート作成 Argus (内製BI ツール) Jenkins Batch Server • 集計・分析スクリプト作成 • アドホック分析 • ssh でログインして作業 • バッチジョブ設定 • エラー対応 アナリスト等一部の利用者は、GUI を使った分析・レポーティングだけでなく、バッチジョブ管理や、バッチサーバへ ssh でログインした上でのスクリプト作成まで行っている 利用者が行う作業 旧データ プラットフォームの特徴: 高いレベルの自由度 9
10. 同一のクラスタ、サーバを様々なサービスの分析で共用 • 初期の分析対象はMobage とMobage 上のゲーム ◦ 全員が全てのデータにアクセスできる環境であった • 事業の多様化に伴い、サービス毎の権限管理を導入 旧データ プラットフォームの特徴: マルチテナント Hadoop Cluster Service B のログ Service C のログ Vertica Cluster Service A のデータ Service B のデータ Service C のデータ Service A のログ 10 Batch Server Service A のアナリスト Service B のアナリスト Service C のアナリスト … … …
11. 10年の歳月を経てさまざまな課題が顕在化してきた 中でもDeNA 固有の課題は「モノリス化」であると考えている 旧データ プラットフォームの課題: モノリス 11 様々な事業・利用者が一つの環境に同 居し、システムリソースを共有 • 特定の事業に合わせた環境の カスタマイズ が難しい • 影響範囲が広く計画停止するのも一苦労、 ス ピーディーな改善が難しい • ただでさえコンポーネントが多く複雑な システムが、権限管理等の要件により 更に複雑化 On-Premises Service A Service B Service C … … Service A Service B Service C …
12. 課題の背景: 進化・多様化する分析ニーズ 12 新しい技術・ツールへのニーズの盛り上がり • Twitter でソーシャル リスニングを行うために、最新のクライアントライ ブラリを使いたい • 予測モデルを開発するために Jupyter Notebook と最新のpythonライ ブラリを使いたい • ディープ ラーニングを活用したいのでGPU マシンが必要 etc... ただし、技術要件は事業/案件毎に異なる • 目的に応じて最適な技術を取り入れたい！ しかしモノリスでは機敏かつ柔軟に対応できない...
13. モノリス化を解決するために、データプラットフォームの刷新プロジェクト 「polymorph（ポリモフ）」を2018年に始動。 polymorph: 多形 1. 化学の用語で、同じ組成の化学物質に、多くの結晶形が存在すること。 2. 生物学の用語で、同じ種の生物に、多くの形態、形質の個体が存在す ること。 2020年度中にはポリモフへの移行を完了する予定。 データプラットフォームの刷新: モノリスからポリモフへ 13
14. • サービス毎に環境分離 • ワークロード毎にリソース分離 これらを実現するためにはパブリッククラ ウドへの移行が必要であった オンプレの仕組みをクラウド上に再現す るのではなく、ゼロベースで再設計 -> Section 2 にて詳細に解説 ポリモフの設計方針 14 On-Premises Service A Service B Service C … … Service A Service B Service C … … Service A Service B Service C
15. BigQuery は2015年頃から実戦投入し、既存の分散DB 製品に対 する優位性を確認できていた コスト • 既存製品より桁一つ安い スケーラビリティ • 既存製品は独自ノウハウが必要 • BigQuery は Google が スケーラビリティを 担保 チューニングフリー • DeNA は利用者が幅広く、かつ、自由度が高いため、チューニ ングの徹底が困難 • BigQuery は 特別なチューニングなしで一定の性能を発揮 Google Cloud を選んだ理由: BigQuery 15
16. • BigQuery と他のコンポーネントとの連携が容易 • アカウント・権限の一元管理が可能 • コストの一元把握が可能 • システム間連携の認証鍵(サービスアカウントの鍵)を自前 で管理する必要がなくセキュア • クラウドでは鍵の漏洩が即、情報漏洩につながる場合があ る！ BigQuery を使うなら、全てGoogle Cloud に寄せるのが吉 16
17. このSection のまとめ • 早い時期からHadoop 等の技術を取り入れ、大規模データを分析できる環境を 築いていたが、徐々に「モノリス化」していった • モノリス化の課題を解決するために、データ プラットフォーム刷新プロジェクト「 ポ リモフ」を始動した • Google Cloud を選んだ決めてはBigQuery がDeNA のユースケースに最適で あったため 17
18. Section 2 新データ プラットフォーム「ポリモフ」 設計思想と実装
19. このSection でお話すること 19 • ポリモフの全体構成 • ポリモフの設計方針: サービス毎に環境分離 • ポリモフの設計方針: ワークロード毎にリソース分離
20. • サービス毎に環境分離 • ワークロード毎にリソース分離 ポリモフの設計方針（再掲） 20
21. BI Tools ポリモフの全体構成 21 Service A Service Env App Server DB Server Data Platform Service A BigQuery Cloud Storage GKE digdag batch web app Argus app logs snapshot Service B Service C Service B Service C ・・・ ・・・ サービス毎に環境分離 ワークロード毎にリ ソース分離
22. 分析対象サービス毎に異なる Google Cloud プロジェクトを利用している コスト管理上のメリット • プロジェクト別に請求が来る • BigQuery にエクスポートして分析可能 • 「どのサービスで何にいくら使ったか 」が明 確に ポリモフの設計方針: サービス毎に環境分離 権限管理上のメリット • 権限管理（IAM）が プロジェクト毎 = サービス毎 に明確に分離される • 誤って不要な権限を付けてしまう リス クが低い 22 … Service A Service B Service C
23. バッチ処理やWeb アプリをそれぞれ別のコンテナとして GKE (Google Kubernetes Engine) 上で稼働させている ポリモフの設計方針: ワークロード毎にリソース分離 23 GKE web app batch digdag
24. • 事業、案件毎に特化した可視化ツール等 • SQL では書けない処理を python 等、好きな言語で記述 • 大きなリソースを必要とする処理 • digdag から実行 GKE 上で稼働させているワークロード • バッチジョブの管理 • 集計SQL の実行 • batch ワークロードの実行 24 batch, web app のコンテナは、利用者側で作成・実行 利用者側のカスタマイズの影響をコンテナ内に閉じ込めることで、高い自由 度を与えつつ、環境を管理可能に保つことができる digdag web app batch
25. • digdag （それ自体がGKE上で稼働している）が kubernetes のAPIを呼 び出し、batch ワークロードをGKE 上に deploy する • digdag で処理の流れ制御しつつ、実際の処理は個別のコンテナ上で 実行させることが可能 batch ワークロードは digdag から実行している 25 GKE batch digdag apiVersion: batch/v1 kind: Job metadata: name: some-job ... kube- apiserver kubectl apply create
26. • Cloud IAP で社内 G Suite アカウントによる認証を設定 個別のアプリで認証機能を実装する必要がない • Cloud Armor で社外からのアクセスをシャットアウト web app は Cloud IAP、 Cloud Armor でセキュアに 26 Cloud Load Balancing DeNA office Cloud Armor Identity-Aware Proxy GKE 接続元アドレス制限 ユーザ認証 Google Cloud の機能を活用することで、社内システムをセキュアかつ手軽 に構築 web app
27. GKE Node Pool with High Memory 「このbatch ではGPU を使いたい」 様々なリソース要求 GKE の仕組みを活用し様々なリソース要求に効率的に対応 27 Node Pool with GPU 「このweb app は大きめのメモリが必要」 … … ・・・ • ノードプール(同じ構成のノード群)を複数種類用意 • オートスケールにより、必要な時に必要なノードが自動で起動
28. このSection のまとめ 28 • 分析対象のサービス毎に Google Cloud プロジェクトを分離することで、権限とコ ストを明確に管理できる • コンテナ技術を活用し、ワークロード毎にリソースを分離することで、利用者の 自 由度を高めつつ、環境を管理可能に保つ ことができる • Google Cloud の機能を活用することで、更に手軽かつセキュアに様々な要求に 応えることができる
29. 城谷 信一郎（Shinichiro Joya) • 2019年9月 DeNA 入社 • ゲーム事業のデータエンジニアとして従事 ◦ パイプライン開発 ◦ クラウド移行 ◦ データ プラットフォームの最適化 29 Speakers
30. Section 3 新データ プラットフォームへ 効率の良い移行方法
31. • Google Cloud へ移行する際に求められたこと • 求めに対し、どういう工夫をして移行を実施しているか このSection でお話すること 31
32. 32 本題に入る前に分析環境の クラウド移行をおさらい
33. ゲーム以外の サービス 5 + 33 DeNA で移行が必要なサービス ゲームタイトル 15 + 移行候補テーブル数 5000+
34. 34 周辺も同時に移行が必要 データ 保管 データ 収集 データ 分析 データ 加工 内製開発 内製開発 Hadoop Vertica Cloud Storage BigQuery jenkins Embulk vSQL,Java, Pig,etc digdag BQ SQL,Ruby, Python,etc Argus Argus Looker
35. 35 Google Cloud へ移行する際に求められたこと 1. 移行前と移行後のデータの差分を最小限にする • 環境の違うデータを比較するには？ 2. 移行を効率化する仕組みを提供する • アナリストが自ら移行できる仕掛けとは？
36. 36 BigQuery を使ったデータの差分確認環境 サービス環境 オンプレ環境 Google Cloud Platform Cloud Storage Service B LOG DB Service A LOG DB ... 現データ 収集機能 新データ 収集機能 Hadoop Vertica BigQuery RAW Data Mart RAW Data Mart
37. 37 差分確認はSQL で実施 WITH table1 as ( SELECT col1, col2, col3 FROM foo.bar1 ), table2 as ( SELECT col1, col2, col3 FROM foo.bar2 ), except_table as ( SELECT “comp_dist”, * FROM (SELECT * FROM table1 EXCEPT DISTINCT SELECT * FROM table2) UNION ALL SELECT “comp_source”,* FROM (SELECT * FROM table2 EXCEPT DISTINCT SELECT * FROM table1) ) SELECT * FROM except_table 差分が一目瞭然 オンプレテーブル クラウドテーブル
38. 38 自動化することで差分確認の効率を上げる アナリスト BigQuery オンプレ テーブル クラウド テーブル オンプレ テーブル クラウド テーブル 対象TBL (TSV) 対象TBL を更新 git push & merge 自動Deploy 対象TBL のSchema を取得し、 差分確認用SQL を動的生成 bq show --schema --format=prettyjson \ ${project_id}:${dataset}.${table} 日次で差分確認を 自動で実施 差分発生時にAlert 確認対象が増えた時の 対応はコレだけ
39. 39 実際にあった差分 オンプレ 2019-10-24 10:31:44※実態はJST クラウド 2019-10-24 10:31:44 UTC • データソースのTimestamp にtime zone の 指定が無いためBigQuery 側がUTC を付与 データにtime zone を明記させる or String 型で取り込む
40. 40 BigQuery を使ったデータの差分確認環境 サービス環境 オンプレ環境 Google Cloud Platform Cloud Storage Service B LOG DB Service A LOG DB ... 現データ 収集機能 新データ 収集機能 Hadoop Vertica BigQuery RAW Data Mart RAW Data Mart ？ BulkLoad を どう実現する？
41. 41 Medjed という内製のツールでデータの取り込みを支援 Medjed の設定画面 Google Sheets Web 操作し、スケジュール、 トリガーを設定 Google Sheets の URLを登録 取り込みたい テーブル、スキーマを 入力 アナリスト
42. 42 オンプレ / クラウドからのデータ取り込みを効率化 データ 収集機能 Cloud Storage Table A Table B BigQuery 現データ 収集機能 Table A Table B Table C Table A Table B Table C Table A Table B BigQuery Table C Table C Medjed Hadoop Vertica アナリスト
43. 43 データ取り込みを支援するCloud Data Fusion https://cloud.google.com/data-fusion/plugins
44. このSection のまとめ 44 大規模なクラウド移行を実現するために 1. 移行前と移行後のデータの差分を最小限にする • オンプレデータもBigQuery に取り込み 差分を効率良く確認出来る状態に 2. 移行を効率化する仕組みを提供する • 差分の確認を自動化することで効率化 • データの取り込みツールを利用者にて提供する事で効率化
45. Section 4 Google Cloud をフル活用した データ プラットフォームの使い方
46. • Google Cloud Platform をフルに活用した事例の紹介 a. SNS データを使った取り組み b. Cloud AutoML を使ったデジタルマーケティング施策 このSection でお話すること 46
47. • Google Cloud Platform をフルに活用した事例の紹介 a. SNS データを使った取り組み b. Cloud AutoML を使ったデジタルマーケティング施策 47
48. 48 DeNA のSNS データを使ったコミュニティーとの関わり SNS データを活用した施策の検討 • 施策検討 • コンテンツ提供 • 外部発信 ユーザ • サービスに 対する投稿
49. 膨大なTweet に対して分析は相応の時間を要していた 49 SNS データからの高い分類・分析コスト ….... …..... ….... …... ...... ...... ユーザはどう反応 しているのか... ・ ・ ・ ・ ・ ・ Tweet の件数が多すぎて 収集に時間が掛かる...
50. 50 Twitter データとNLP API によるユーザの分析 Tweetデータ BigQuery Cloud Storage Cloud Natural Language API 感情分析データ BigQuery Tweetラベリングデータ BigQuery Twitter API analytics Container Twitter Crawler Container digdag Container WorkFlow 50
51. 51 Looker を使いダッシュボードで可視化 • NLP API を導入することでこれまで人間の目で 判断していたTweet の内容を機械学習の力で効率化
52. 52 Looker を使いダッシュボードで可視化 ポジティブなTweet の 部分をクリック！ 具体的なTweet にドリルダウン
53. 53 効果と今後について 1. 定性的なデータの定量化・可視化が可能に • 自動化によりデータ収集、分析を効率化 • バイアスを排除した分析が可能に 2. 今後はデータの種類と取得先を増やしていく • Twitter 以外のSNS データを取得 • Twitter データを活かしたより高度な分析
54. • Google Cloud Platform をフルに活用した事例の紹介 a. SNS データを使った取り組み b. Cloud AutoML を使ったデジタルマーケティング施策 54
55. LTV の高い事が予想されるユーザに対してゲーム復帰を促す広告施策 55 デジタル マーケティング施策について log DB 学習／予測 Model 広告 再びゲームに 戻ってもらう 広告識別子 高LTV予想 ユーザ LTV：顧客生涯価値（Life Time Value）
56. LTV の高い事が予想されるユーザに対してゲーム復帰を促す広告施策 56 POCの結果 特定のゲームタイトルで効果が出た log DB 学習／予測 Model 広告 再びゲームに 戻ってもらう 広告識別子 高LTV予想 ユーザ LTV：顧客生涯価値（Life Time Value） ・実際の平均LTV の上昇
57. タイトルA 57 システム化し横展開する上での課題 ・ ・ ・ タイトルB タイトルC • 少人数で複数タイトルのパイプラインを開発・維持 • 機械学習の学習モデルのメンテナンス、パラメータチューニ ングの問題 • 広告識別子（IDFA）を扱うのでセキュアに提供する必要
58. 58 AutoMLを使った学習・予測基盤の構築 Source Data BigQuery LTV学習用テーブル BigQuery LTV予測モデル AutoML Tables Kubernetes Engine digdag Container Python Container JupyterLab Container 復帰学習用テーブル BigQuery 復帰予測モデル AutoML Tables 広告配信マスタ BigQuery External Table Input Data Train Data Training bq operator AutoMLAPI で学習の実行 学習パイプライン モデル精度監視 Stackdriver コンテナレジストリ Container Registry 実行時にコンテナ起動
59. 59 AutoMLを使った学習・予測基盤の構築 Source Data BigQuery LTV予測用テーブル BigQuery LTV予測モデル AutoML Tables Kubernetes Engine digdag Container Python Container JupyterLab Container 復帰予測用テーブル BigQuery 復帰予測モデル AutoML Tables Input Data Prediction Data Prediction bq operator 予測パイプライン 予測結果（IDFA+予測値） BigQuery Output Data コンテナレジストリ Container Registry 予測結果への アクセス Authentication 実行時にコンテナ起動 AutoMLAPI で予測の実行 デジマ担当者
60. 60 現在開発中だが期待出来る効果として 1. 開発・メンテナンスの効率向上 • BigQuery , digdag など学習コストを抑える仕組み • Cloud AutoML 側に任せる事でモデル開発・メンテの難易度が低下 • GKE 上の JupyterLab から広告識別子を取得するためセキュアに 2. ML Ops の礎として複数用途に展開可能 • 多用途、多サービス展開が可能なプラットフォームへ
61. このSection のまとめ 61 • Google Cloud Platform をフルに活用した事例の紹介 ◦ NL API やAuto ML などサーバレスの機械学習サービスを利用 ▪ より高度なデータ活用を実現 ◦ WorkFlow, 実行環境は使い慣れたサービスを利用 ▪ 低い学習コストで効率の良い開発
62. まとめ
63. 63 本日話した内容 1 2 3 4 多様化したニーズに対して、 モノリス化したオンプレが足枷 に 適切な分離性を持つ 事で、自由で統制の取れたプラットフォームに BigQuery のフル活用と内製の仕組みを組み合わせ 、効率良く移行 GCP のサービスを組み合わせ 、自由で高度なデータ活用 データプラットフォームの刷新 なぜGoogle Cloud を選んだのか？ 新データ プラットフォーム「ポリモフ」 設計思想と実装 Google Cloud をフル活用した事例 新データプラットフォームへ効率の良い移行方法 Google Cloud を中心としたプラットフォームで課題の解決を図る
64. • BigQuery の利用におけるコスト最適化戦略 • Google Cloud Next '19 in Tokyo で発表済み（2019/08/01） • BigQuery を使い倒せ！DeNA データエンジニアの取り組み事例 • https://cloud.withgoogle.com/next/19/tokyo/sessions?session=D2-2-S09 • DeNA データ プラットフォームにおける運用の詳細 • DeNa TechCon 2020でオンライン配信 • DeNA データ プラットフォームにおける自由と統制のバランス • https://www.youtube.com/watch?v=S3jUEl9pEmM (1:49:55 〜) • DeNA が Looker を採用した経緯 • Looker Game Night で発表予定（時期未定） • https://discover.looker.com/Q1Y2020JPNGameEvent.html 64 本日話さなかった内容
65. 65 今後Google Cloud に期待すること • 安全安心なデータ プラットフォームの提供に期待 ◦ データガバナンス ：データカタログ、データリネージ ◦ セキュリティ ：ゼロトラスト、PII データの検知・削除 • Google の他サービスとの心地よい連携に期待
66. 本日話しきれなかった内容/質問への回答は後日Mediam に投稿予定 DeNA Analytics Blog 66