Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

2020-03-31 の

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

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

の登壇資料です。

DeNA_Tech

March 15, 2023
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. 長谷川 了示(Ryoji Hasegawa) • 新卒 -> ITコンサルティング • 製品開発@分析系SaaS ベンダ

    • 2016年9月 DeNA 入社 ◦ 全社データプラットフォームの企画・構築・運用 ◦ 今回のテーマであるデータプラットフォーム刷新を立 ち上げからリード 2 Speakers
  2. 3 本日お話する内容 1 2 データ プラットフォームの刷新 なぜGoogle Cloud を選んだのか? 新データ

    プラットフォームの全貌 設計思想と実装 3 4 Google Cloud をフル活用した事例 新データ プラットフォームへ効率の良い移行方法
  3. 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 …
  4. DeNA グループ全社員の4割強 旧データ プラットフォームの特徴: 多種多様な利用者 8 ゲーム以外の サービス 5 +

    ゲームタイトル 15 + BIツールの Monthly Active User 1,000 - アナリスト(データ分析担当者)から企画、経営層まで幅広い利用者
  5. • SQL クエリ作成 • レポート作成 Argus (内製BI ツール) Jenkins Batch

    Server • 集計・分析スクリプト作成 • アドホック分析 • ssh でログインして作業 • バッチジョブ設定 • エラー対応 アナリスト等一部の利用者は、GUI を使った分析・レポーティングだけでなく、バッチジョブ管理や、バッチサーバへ ssh でログインした上でのスクリプト作成まで行っている 利用者が行う作業 旧データ プラットフォームの特徴: 高いレベルの自由度 9
  6. 同一のクラスタ、サーバを様々なサービスの分析で共用 • 初期の分析対象は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 のアナリスト … … …
  7. 10年の歳月を経てさまざまな課題が顕在化してきた 中でもDeNA 固有の課題は「モノリス化」であると考えている 旧データ プラットフォームの課題: モノリス 11 様々な事業・利用者が一つの環境に同 居し、システムリソースを共有 •

    特定の事業に合わせた環境の カスタマイズ が難しい • 影響範囲が広く計画停止するのも一苦労、 ス ピーディーな改善が難しい • ただでさえコンポーネントが多く複雑な システムが、権限管理等の要件により 更に複雑化 On-Premises Service A Service B Service C … … Service A Service B Service C …
  8. 課題の背景: 進化・多様化する分析ニーズ 12 新しい技術・ツールへのニーズの盛り上がり • Twitter でソーシャル リスニングを行うために、最新のクライアントライ ブラリを使いたい •

    予測モデルを開発するために Jupyter Notebook と最新のpythonライ ブラリを使いたい • ディープ ラーニングを活用したいのでGPU マシンが必要 etc... ただし、技術要件は事業/案件毎に異なる • 目的に応じて最適な技術を取り入れたい! しかしモノリスでは機敏かつ柔軟に対応できない...
  9. BigQuery は2015年頃から実戦投入し、既存の分散DB 製品に対 する優位性を確認できていた コスト • 既存製品より桁一つ安い スケーラビリティ • 既存製品は独自ノウハウが必要

    • BigQuery は Google が スケーラビリティを 担保 チューニングフリー • DeNA は利用者が幅広く、かつ、自由度が高いため、チューニ ングの徹底が困難 • BigQuery は 特別なチューニングなしで一定の性能を発揮 Google Cloud を選んだ理由: BigQuery 15
  10. 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 ・・・ ・・・ サービス毎に環境分離 ワークロード毎にリ ソース分離
  11. 分析対象サービス毎に異なる Google Cloud プロジェクトを利用している コスト管理上のメリット • プロジェクト別に請求が来る • BigQuery にエクスポートして分析可能

    • 「どのサービスで何にいくら使ったか 」が明 確に ポリモフの設計方針: サービス毎に環境分離 権限管理上のメリット • 権限管理(IAM)が プロジェクト毎 = サービス毎 に明確に分離される • 誤って不要な権限を付けてしまう リス クが低い 22 … Service A Service B Service C
  12. • 事業、案件毎に特化した可視化ツール等 • SQL では書けない処理を python 等、好きな言語で記述 • 大きなリソースを必要とする処理 •

    digdag から実行 GKE 上で稼働させているワークロード • バッチジョブの管理 • 集計SQL の実行 • batch ワークロードの実行 24 batch, web app のコンテナは、利用者側で作成・実行 利用者側のカスタマイズの影響をコンテナ内に閉じ込めることで、高い自由 度を与えつつ、環境を管理可能に保つことができる digdag web app batch
  13. • 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
  14. • 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
  15. GKE Node Pool with High Memory 「このbatch ではGPU を使いたい」 様々なリソース要求

    GKE の仕組みを活用し様々なリソース要求に効率的に対応 27 Node Pool with GPU 「このweb app は大きめのメモリが必要」 … … ・・・ • ノードプール(同じ構成のノード群)を複数種類用意 • オートスケールにより、必要な時に必要なノードが自動で起動
  16. このSection のまとめ 28 • 分析対象のサービス毎に Google Cloud プロジェクトを分離することで、権限とコ ストを明確に管理できる •

    コンテナ技術を活用し、ワークロード毎にリソースを分離することで、利用者の 自 由度を高めつつ、環境を管理可能に保つ ことができる • Google Cloud の機能を活用することで、更に手軽かつセキュアに様々な要求に 応えることができる
  17. 城谷 信一郎(Shinichiro Joya) • 2019年9月 DeNA 入社 • ゲーム事業のデータエンジニアとして従事 ◦

    パイプライン開発 ◦ クラウド移行 ◦ データ プラットフォームの最適化 29 Speakers
  18. 34 周辺も同時に移行が必要 データ 保管 データ 収集 データ 分析 データ 加工

    内製開発 内製開発 Hadoop Vertica Cloud Storage BigQuery jenkins Embulk vSQL,Java, Pig,etc digdag BQ SQL,Ruby, Python,etc Argus Argus Looker
  19. 36 BigQuery を使ったデータの差分確認環境 サービス環境 オンプレ環境 Google Cloud Platform Cloud Storage

    Service B LOG DB Service A LOG DB ... 現データ 収集機能 新データ 収集機能 Hadoop Vertica BigQuery RAW Data Mart RAW Data Mart
  20. 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 差分が一目瞭然 オンプレテーブル クラウドテーブル
  21. 38 自動化することで差分確認の効率を上げる アナリスト BigQuery オンプレ テーブル クラウド テーブル オンプレ テーブル

    クラウド テーブル 対象TBL (TSV) 対象TBL を更新 git push & merge 自動Deploy 対象TBL のSchema を取得し、 差分確認用SQL を動的生成 bq show --schema --format=prettyjson \ ${project_id}:${dataset}.${table} 日次で差分確認を 自動で実施 差分発生時にAlert 確認対象が増えた時の 対応はコレだけ
  22. 39 実際にあった差分 オンプレ 2019-10-24 10:31:44※実態はJST クラウド 2019-10-24 10:31:44 UTC •

    データソースのTimestamp にtime zone の 指定が無いためBigQuery 側がUTC を付与 データにtime zone を明記させる or String 型で取り込む
  23. 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 を どう実現する?
  24. 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 アナリスト
  25. このSection のまとめ 44 大規模なクラウド移行を実現するために 1. 移行前と移行後のデータの差分を最小限にする • オンプレデータもBigQuery に取り込み 差分を効率良く確認出来る状態に

    2. 移行を効率化する仕組みを提供する • 差分の確認を自動化することで効率化 • データの取り込みツールを利用者にて提供する事で効率化
  26. • Google Cloud Platform をフルに活用した事例の紹介 a. SNS データを使った取り組み b. Cloud

    AutoML を使ったデジタルマーケティング施策 このSection でお話すること 46
  27. 膨大なTweet に対して分析は相応の時間を要していた 49 SNS データからの高い分類・分析コスト ….... …..... ….... …... ......

    ...... ユーザはどう反応 しているのか... ・ ・ ・ ・ ・ ・ Tweet の件数が多すぎて 収集に時間が掛かる...
  28. 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
  29. LTV の高い事が予想されるユーザに対してゲーム復帰を促す広告施策 55 デジタル マーケティング施策について log DB 学習/予測 Model 広告

    再びゲームに 戻ってもらう 広告識別子 高LTV予想 ユーザ LTV:顧客生涯価値(Life Time Value)
  30. LTV の高い事が予想されるユーザに対してゲーム復帰を促す広告施策 56 POCの結果 特定のゲームタイトルで効果が出た log DB 学習/予測 Model 広告

    再びゲームに 戻ってもらう 広告識別子 高LTV予想 ユーザ LTV:顧客生涯価値(Life Time Value) ・実際の平均LTV の上昇
  31. タイトルA 57 システム化し横展開する上での課題 ・ ・ ・ タイトルB タイトルC • 少人数で複数タイトルのパイプラインを開発・維持

    • 機械学習の学習モデルのメンテナンス、パラメータチューニ ングの問題 • 広告識別子(IDFA)を扱うのでセキュアに提供する必要
  32. 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 実行時にコンテナ起動
  33. 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 で予測の実行 デジマ担当者
  34. 60 現在開発中だが期待出来る効果として 1. 開発・メンテナンスの効率向上 • BigQuery , digdag など学習コストを抑える仕組み •

    Cloud AutoML 側に任せる事でモデル開発・メンテの難易度が低下 • GKE 上の JupyterLab から広告識別子を取得するためセキュアに 2. ML Ops の礎として複数用途に展開可能 • 多用途、多サービス展開が可能なプラットフォームへ
  35. このSection のまとめ 61 • Google Cloud Platform をフルに活用した事例の紹介 ◦ NL

    API やAuto ML などサーバレスの機械学習サービスを利用 ▪ より高度なデータ活用を実現 ◦ WorkFlow, 実行環境は使い慣れたサービスを利用 ▪ 低い学習コストで効率の良い開発
  36. 63 本日話した内容 1 2 3 4 多様化したニーズに対して、 モノリス化したオンプレが足枷 に 適切な分離性を持つ

    事で、自由で統制の取れたプラットフォームに BigQuery のフル活用と内製の仕組みを組み合わせ 、効率良く移行 GCP のサービスを組み合わせ 、自由で高度なデータ活用 データプラットフォームの刷新 なぜGoogle Cloud を選んだのか? 新データ プラットフォーム「ポリモフ」 設計思想と実装 Google Cloud をフル活用した事例 新データプラットフォームへ効率の良い移行方法 Google Cloud を中心としたプラットフォームで課題の解決を図る
  37. • 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 本日話さなかった内容
  38. 65 今後Google Cloud に期待すること • 安全安心なデータ プラットフォームの提供に期待 ◦ データガバナンス :データカタログ、データリネージ

    ◦ セキュリティ :ゼロトラスト、PII データの検知・削除 • Google の他サービスとの心地よい連携に期待