GREE Tech Conference 2023で発表された資料です。 https://techcon.gree.jp/2023/session/TrackA-5
「REALITY」・「DADAN」におけるデータ分析基盤の運用事例グリー株式会社データエンジニア熱田 慶人
View Slide
自己紹介● 名前○ 熱田 慶人 (Yoshito Atsuta)● 所属○ 開発本部■ データテクノロジー部● データエンジニアリングチーム● 略歴○ 2022年4月新卒入社● 担当業務○ データ分析基盤開発・運用○ 機械学習基盤開発2
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ3
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ4
REALITY5スマホひとつでアバター作成、ライブ配信による交流やゲームまで楽しめるスマホ向けメタバースですアバター ライブ配信コミュニケーション ルームワールド
DADAN6幅広いジャンルの漫画・コミックを掲載している総合マンガプラットフォームです
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ7
背景● 元々、AWS上にEMRをベースとした分析基盤を運用していた● GCPで開発されるREALITY向けにGCP上で分析基盤を構築することにした○ ログのリアルタイム性、コストの面の要件を満たすために GCPで構築● その後DADANの分析業務でも必要になり同様の構成で構築した○ データ分析する側も同様の使い方が可能○ システム構築のイニシャルコスト削減8分析基盤 on AWSREALITY向け分析基盤 on GCPDADAN向け分析基盤 &レコメンドシステム on GCP2016~ 2018~ 2022~GCP上で分析システム構築する初めての試みエンジニアグループ アナリシスグループ
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ9
クライアント共通課金基盤分析システム本番サーバー1. 共通課金基盤からのログ、サーバーログをPub/Subに送信2. DataflowでPub/SubのメッセージをBigQueryへ格納できる形に整形し格納3. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納4. 中間テーブルの作成やAPI経由でのログ取り込み5. Looker Studioでは、Cloud SQLからデータを参照REALITY:分析システム構成10FirebaseBigQueryPub/Sub DataflowCloud Run Cloud SQLCloud BatchLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage1 25AWS上のサーバー外部サービス43
クライアント共通課金基盤分析システム本番サーバー1. 共通課金基盤からのログ、サーバーログをPub/Subに送信2. DataflowでPub/SubのメッセージをBigQueryへ格納できる形に整形し格納3. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納4. 中間テーブルの作成やAPI経由でのログ取り込み5. Looker Studioでは、Cloud SQLからデータを参照REALITY:分析システム構成（ログ形式）11FirebaseBigQueryPub/Sub DataflowCloud Run Cloud SQLCloud BatchLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage1 25AWS上のサーバー外部サービス43
REALITY:分析システム構成（ログ形式）● PubSubとは○ リアルタイムデータおよびイベントストリーム処理を行うサービス○ 同様のサービスとして AWSのKinesisやApache Kafkaがある● 出力フォーマットはjson○ 宛先テーブルとテーブルに格納する値を jsonとしてPub/Subにpush○ ログ定義は、分析担当のアナリシスチームが行う● 共通課金基盤からのFluentdでCloud Loggingに出力○ 共通課金基盤はAWS上に構築されているため○ ログルーターで対象ログを Pub/Subにpush12
クライアント共通課金基盤分析システム本番サーバー1. 共通課金基盤からのログ、サーバーログをPub/Subに送信2. DataflowでPub/SubのメッセージをBigQueryへ格納できる形に整形し格納3. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納4. 中間テーブルの作成やAPI経由でのログ取り込み5. Looker Studioでは、Cloud SQLからデータを参照REALITY:分析システム構成（Dataflow）13FirebaseBigQueryPub/Sub DataflowCloud Run Cloud SQLCloud BatchLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage1 25AWS上のサーバー外部サービス43
REALITY:分析システム構成（Dataflow）● Dataflowとは○ ストリーミングデータおよびバッチデータの処理を効率的に行うための GCPのマネージドなETLサービス● Dataflow選定理由○ GCEより高くなるが、Streaming Engineを使うことでスケールしやすい形にできる○ Dynamic Destinationsクラスを使うことで、動的に宛先テーブルを変更できる■ プロダクト側が自由にテーブルを増やしても、ログの宛先テーブル情報をもとに挿入先のテーブルが決定されるので、 Dataflow側の修正が不要● 使用言語○ Java■ 使える機能、ドキュメントが豊富だったため選択14
クライアント共通課金基盤分析システム本番サーバー1. 共通課金基盤からのログ、サーバーログをPub/Subに送信2. DataflowでPub/SubのメッセージをBigQueryへ格納できる形に整形し格納3. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納4. 中間テーブルの作成やAPI経由でのログ取り込み5. Looker Studioでは、Cloud SQLからデータを参照REALITY:分析システム構成（集計処理）15FirebaseBigQueryPub/Sub DataflowCloud Run Cloud SQLCloud BatchLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage1 25AWS上のサーバー外部サービス43
REALITY:分析システム構成（集計処理）● Cloud Run とは○ コンテナベースのアプリケーションをサーバーレスでスケーラブルに実行するマネージドサービス● Cloud Batch とは○ バッチ処理ワークロードを実行するフルマネージドサービス○ 一時的にGCEインスタンスを建てて処理を実行できる● 選定理由○ コンテナイメージを使い回せる○ 実行時間が長いものと短いもので使い分けができる● 使用言語○ Typescript■ 他のプロジェクトでも使用されているため16
REALITY:分析システム構成（集計処理）● Cloud RunとCloud Batchの使い分け○ Cloud Runでは、5~10分程度で終わる処理を行う○ Cloud Batchでは、実行時間がかかるクエリ実行等を行う● クエリはアナリシスチームが作成○ key, valueの形で出力できるクエリを作成して、 GCSに置くだけで集計される■ システムがブロッカーにならず柔軟に指標の修正、追加を行える● バッチ処理のスケジュールはCloud Schedulerで管理17Cloud SQLBigQueryCloud RunCloud Batch集計クエリCloud Storage
クライアント共通課金基盤分析システム本番サーバー1. 共通課金基盤からのログ、サーバーログをPub/Subに送信2. DataflowでPub/SubのメッセージをBigQueryへ格納できる形に整形し格納3. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納4. 中間テーブルの作成やAPI経由でのログ取り込み5. Looker Studioでは、Cloud SQLからデータを参照REALITY:分析システム構成（集計処理）18FirebaseBigQueryPub/Sub DataflowCloud Run Cloud SQLCloud BatchLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage1 25AWS上のサーバー外部サービス43
REALITY:分析システム構成（集計処理）● 中間テーブル作成クエリもCloud Runで処理○ 複数の指標で用いるデータなどは費用削減の目的で中間テーブルを参照する● 広告指標などの外部サービスのログもCloud Runで処理○ API経由で取得した後、GCSに生データを保存して、 BigQueryに格納19外部サービスCloud StorageCloud Run Eventarc Cloud Run BigQueryAPI経由でデータ取得 GCSに置かれたタイミングをトリガーにBigQueryへ格納Cloud Run BigQueryBigQuery中間テーブル作成用クエリを処理
クライアント共通課金基盤分析システム本番サーバー1. 共通課金基盤からのログ、サーバーログをPub/Subに送信2. DataflowでPub/SubのメッセージをBigQueryへ格納できる形に整形し格納3. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納4. 中間テーブルの作成やAPI経由でのログ取り込み5. Looker Studioでは、Cloud SQLからデータを参照REALITY:分析システム構成（データ可視化）20FirebaseBigQueryPub/Sub DataflowCloud Run Cloud SQLCloud BatchLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage1 25AWS上のサーバー外部サービス43
REALITY:分析システム構成（データ可視化）● Looker StudioのCloud SQL連携でダッシュボードに可視化○ 他のプロジェクトでも利用経験があったので採用○ ストリーミングバッファにデータが含まれる場合は、キャッシュが利用できないので、 Cloud SQLを可視化の間に挟んでいる● ダッシュボードに表示している一部の値はSlackにも毎日通知○ Slack通知させたい値をCloud SQLから抽出するクエリを GCSに配置して、Cloud Run上で実行しSlackに通知○ 通知内容をアナリシスチームが自由に変更可能21クエリCloud StorageCloud SQL Cloud Run Slack
REALITY:分析システム構成（CI/CD/CM）22● CI/CD周りはCloud Buildを採用○ イメージのプッシュと Cloud Runへのデプロイまで行う○ Cloud Batchはプッシュされたイメージを使う● データ取り込みの障害検知はCloud Monitoring○ 影響範囲が大きいDataflowのエラーはPager Duty○ 集計処理など、再実行すれば正しくなるものは、 slack通知Cloud RunCloud BatchContainerRegistryCloud BuildGitHubPush Build image & Push DeployPull
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ23
REALITY:運用中に解決した課題1● 課題○ Cloud Runを使う前は、Cloud Functionsで集計処理を行っていた○ 長時間の処理や高負荷の集計が必要な場面で、Cloud Functionsの実行時間制限が制約になった■ 集計する指標や外部サービスからのログ取得の実行時間がサービス成長と共に増加した● 解決策○ 長時間実行と実行スケジュールの増加へのスケーリングの要件を満たすためにCloud FunctionsからCloud Runへの移行で解決■ コンテナベースの実行環境なため、さらに長時間の実行が必要になった場合、制限時間やリソースの制限が緩いCloud Run JobやCloud Batch等のサービスに移行しやすくなった○ 複数のトリガーを設定できるため、同じコードを2つデプロイする必要がなくなった24
REALITY:運用中に解決した課題2● 課題○ 新しい指標の追加における過去データの再集計がエンジニアにしかできない状況だった■ 長期間の再集計となると Cloud FunctionsやCloud Runでの実行時間制限を超えてしまうので、手元で実行する必要があった■ 実行環境をエンジニアしか用意できていなかった● 解決策○ コードをパッケージ化、認証や Cloud SQL Proxyを設定する部分はスクリプト化して、エンジニア以外がコードをCloud shellなどで実行できるようにした■ 実行したいクエリが入っているディレクトリと再集計する期間を指定するだけで再集計できるようになった■ GCEに再集計環境を用意したが、複数人で利用する際に問題があった25
REALITY:運用中に解決した課題3● 課題○ インフラ構成がIaC化できていなかった■ 引き継ぎコストが高かった■ 少人数運用のため、設定の変更等の操作確認作業がしにくかった● 解決策○ Terraformで既存のインフラ構成をすべて IaC化■ GoogleのTerraform使用におけるベストプラクティスに従って IaC化○ 設定の変更等のコストがコードレビューのみに削減できた■ バッチスケジュールの追加も Cronを書き足すだけの状態にして、すべてのスケジュールで同じ設定が適用されるようにした■ サービスアカウントの権限周りの管理コストも削減26
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ27
クライアント共通課金基盤分析システム本番DB1. SpannerのデータをBigQueryに同期2. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納3. Looker Studioでは、Cloud SQL、BigQueryからデータを参照DADAN:分析システム構成28FirebaseBigQuery Cloud Run Cloud SQLLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage23Cloud Spanner1AWS上のサーバー
クライアント共通課金基盤分析システム本番DB1. SpannerのデータをBigQueryに同期2. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納3. Looker Studioでは、Cloud SQL、BigQueryからデータを参照DADAN:分析システム構成（データ同期）29FirebaseBigQuery Cloud Run Cloud SQLLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage23Cloud Spanner1AWS上のサーバー
DADAN:分析システム構成（データ同期）● Spannerのデータを毎日BigQueryに同期○ 分析頻度の高さを考慮して、外部連携ではなくスナップショットを BigQueryに同期するようにした○ DataflowでSpannerからGCSにエクスポートして、 BigQueryにロードしている● 共通課金基盤からのログはCloud Loggingから直接BigQueryに格納30Cloud Spanner Dataflow Cloud Storage BigQueryLoadExport
クライアント共通課金基盤分析システム本番DB1. SpannerのデータをBigQueryに同期2. BigQueryのデータを定時バッチ処理で集計し、KVSの形でCloud SQLに格納3. Looker Studioでは、Cloud SQL、BigQueryからデータを参照DADAN:分析システム構成（データ可視化）31FirebaseBigQuery Cloud Run Cloud SQLLooker StudioCloud Loggingios/androidfluentd集計クエリCloud Storage23Cloud Spanner1AWS上のサーバー
DADAN:分析システム構成（データ可視化）● 一部指標はBigQueryのテーブルを直接参照○ 作品ごとの指標はBigQueryにテーブルを作成して、そのテーブルを参照している■ 作品ごとの指標は毎日数万件貯まっていくので、 DWHを利用32BigQueryCloud SQLLooker Studioタイトルごとに計算する指標基本KPI
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ33
Recommend System1. BigQuery、Spannerにある読了データ等を抽出、レコメンド対象ユーザーの決定2. モデルの学習とレコメンドリストの生成3. 生成したレコメンドリストを本番DBに書き込みDADAN:レコメンドシステム34FirebaseWorkflowデータ抽出 レコメンドデータ生成レコメンドデータ書き込み過去データ削除Cloud Spanner ClientBigQuery1 2 3
Recommend System1. BigQuery、Spannerにある読了データ等を抽出、レコメンド対象ユーザーの決定2. モデルの学習とレコメンドリストの生成3. 生成したレコメンドリストを本番DBに書き込みDADAN:レコメンドシステム（データ抽出）35FirebaseWorkflowデータ抽出 レコメンドデータ生成レコメンドデータ書き込み過去データ削除Cloud Spanner ClientBigQuery1 2 3
DADAN:レコメンドシステム（データ抽出）● BigQueryのFirebaseログ、Spannerのデータを利用してデータを抽出○ BigQueryにデータは同期されているが、最新のデータを参照したい場合があるので Spannerからも抽出している○ インプレションログや読了データの抽出、レコメンドデータ生成対象のユーザーの決定を行う36生データ休眠ユーザーの除外タイトルの概要一覧取得ユーザーの行動履歴データ取得学習データデータ抽出 データ生成
Recommend System1. BigQuery、Spannerにある読了データ等を抽出、レコメンド対象ユーザーの決定2. モデルの学習とレコメンドリストの生成3. 生成したレコメンドリストを本番DBに書き込みDADAN:レコメンドシステム（データ生成）37FirebaseWorkflowデータ抽出 レコメンドデータ生成レコメンドデータ書き込み過去データ削除Cloud Spanner ClientBigQuery1 2 3
DADAN:レコメンドシステム（データ生成）● 事前学習モデルや協調フィルタリング等を活用してモデルを学習○ ユーザーの行動履歴やインプレッションデータをもとに協調フィルタリングを適用し、ユーザーごとにレコメンドリストを生成○ Word2Vecの事前学習モデルを用いて作品同士の類似度を計算し、各作品の近い作品のリストを生成38学習データ データ生成 データ書き込み作品ごとのレコメンドリストユーザーごとのレコメンドリストを生成
Recommend System1. BigQuery、Spannerにある読了データ、インプレッションデータを抽出、レコメンド対象ユーザーの決定2. モデルの学習とレコメンドリストの生成3. 生成したレコメンドリストを本番DBに書き込みDADAN:レコメンドシステム（データ書き込み）39FirebaseWorkflowデータ抽出 レコメンドデータ生成レコメンドデータ書き込み過去データ削除Cloud Spanner ClientBigQuery1 2 3
DADAN:レコメンドシステム（データ書き込み）● GCEインスタンスから直接Spannerに書き込み○ ミューテーションの制限があるため時間がかかる○ GCSにデータを書き出して、 Dataflowのテンプレートを使った書き込みも試したが、 GCEインスタンスから書き込む方法に落ち着いた■ ミューテーションの制限があるため、書き込み時間に大差がなかった40Cloud Spannerデータ書き込みPriorityをLowに指定して10000行づつ書き込みデータ削除データ書き込みが終わったら過去データ削除
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ41
DADAN:運用中に解決した課題1● 課題○ Looker Studioのデータ抽出機能の制限■ 表示速度高速化のために Looker Studioのデータ抽出機能を利用していたが、作品ごとの指標を抽出することができなくなった● 解決策○ 作品ごとの指標は、BigQueryに作成したテーブルを参照するようにして解決■ 作品ごとに計算する指標が複数あり、今後の作品数増加を考慮すると DWHに保存していく方がスケーラブルに対応できるため42
DADAN:運用中に解決した課題2● 課題○ レコメンドリストの書き込み時間がかかりすぎていた■ 作品数、ユーザー数が増えていくにつれ、レコメンドリストのサイズも大きくなるが、 Spanner側のミューテーションの制限は変わらないため● 解決策○ 休眠ユーザーの除外やレコメンドリストに含める作品数を制限することで対応■ 1日の平均読了数や継続率等を参考に制限するラインを決定○ Spanner側の制限があるため、書き込み時間の改善は難しかったが、ユーザー、タイトル数が増えた場合も一定の書き込み速度になった43
データ分析基盤運用から得た所感● システムのテンプレートのようなものがあると、プロジェクトが増えたときにも迅速にシステムを提供できること○ 事業自体が異なる場合は、こちらの方が細かい部分を柔軟に対応できる○ IaC化もしっかりやっておくとイニシャルコストが削減できる○ 1つのシステムの知識で他のシステムも対応することができる● マネージドサービスでなるべく構成すること○ スケール面の対応がサービスの代替やオートスケールで解決できる○ ランニングコストが削減できる44
アジェンダ● REALITYとDADANの紹介● 分析基盤構築背景● REALITYの分析基盤○ 分析システム構成○ 運用中に解決した課題● DADANの分析基盤○ 分析システム構成○ レコメンドシステム構成○ 運用中に解決した課題● まとめ45
まとめ● REALITYの分析基盤○ Dataflowを利用したストリーミング型のデータ分析基盤○ リアルタイムにサーバーログの分析することが可能● DADANの分析基盤○ REALITYの基盤をベースにした分析基盤○ ベースが同じなため低コストで運用可能● レコメンドシステム○ WorkflowsとCloud Batchを利用したバッチ型のレコメンドシステム46
47
gree_tech
ymotongpoo
tamaiyutaro
glaforge
caddi_eng
yoshiakiyamasaki
patkua
tamago3keran
suzuki
yokawasa
rstankov
sakusakumura
tokibito
eileencodes
addyosmani
schacon
tanoku
dotmariusz
shlominoach
maggiecrowley
mojombo
destraynor
maltzj