TVer の月間ユニークブラウザ数 2700 万のサービスを支える統合ログ基盤の開発

by TVer Inc.

Slide 1

Slide 1 text

TVer の月間ユニークブラウザ数 2700 万のサービスを支える統合ログ基盤の開発黒瀬祐平株式会社TVer サービス事業本部プロダクトタスク

Slide 2

Slide 2 text

スピーカー自己紹介 ● 株式会社TVer (2021/4 ~) ○ 2020/3 ~ 2021/3は株式会社TVer Technologiesに所属 ● データシステムの開発・運用を担当 ● 検索基盤も開発・運用を担当 ● 趣味は語学とダンス ● 好きなGoogle Cloudのサービス: Cloud Logging のLog Analytics 黒瀬祐平株式会社TVer プロダクトタスク

Slide 3

Slide 3 text

TVerについて

Slide 4

Slide 4 text

● 民放テレビ局のコンテンツを配信する民放公式テレビ配信サービス ● 毎週約650番組を無料でPC・スマートフォン・タブレット・TVに配信 TVerについて

Slide 5

Slide 5 text

TVerについて

Slide 6

Slide 6 text

TVerについて

Slide 7

Slide 7 text

TVerリニューアルと TVer ID ● TVer IDに登録しログインすることで、デバイス間のマイリスト連携などの機能が利用可能に

Slide 8

Slide 8 text

統合ログ基盤開発の背景

Slide 9

Slide 9 text

背景 ● 今後のサービス改善のため、サービスの利用状況やニーズを複数の観点から分析したい意思決定情報収集分析サービス展開

Slide 10

Slide 10 text

● BigQueryにデータを集約して分析 ● 収集目的ごとに複数のログ収集サービスを利用従来のデータ分析環境 PC Mobile BigQuery TV 行動ログ収集サービス視聴ログ収集サービス

Slide 11

Slide 11 text

● 異なるログのテーブルの仕様を個別に理解する必要があり、分析のオーバヘッドが増大する ● テーブル同士をIDで突合するためのベンダ調整の手間がかかる ○ 異なるカラム名でも実は同じID体系だったりする... 課題①: 突合の手間がかかる PC Mobile BigQuery TV 行動ログ収集サービス視聴ログ収集サービス

Slide 12

Slide 12 text

● 収集できるログはサービスの仕様で決まってしまう課題②: ログに拡張性がない PC Mobile BigQuery TV 行動ログ収集サービス視聴ログ収集サービス仕様外のログ収集は不可

Slide 13

Slide 13 text

● ログ収集サービスごとに利用料を支払う必要があり、コストがかさむ ○ 請求書も増えてお金かかっている箇所の深掘りに限界がある課題③: 費用がかかる $ $ PC Mobile BigQuery TV 行動ログ収集サービス視聴ログ収集サービス

Slide 14

Slide 14 text

● サービス戦略に合わせて自在にログを収集・集約できるログ基盤=TVerTagの開発実現したいもの PC Mobile BigQuery TV TVerTag

Slide 15

Slide 15 text

TVerTagの開発

Slide 16

Slide 16 text

● ユーザの行動やコンテンツの視聴状況といった大まかなデータ＝ログ種別ごとに集計をしたい ● ログを集計対象などで適宜スキャン範囲を制限することでクエリのコストを抑えられるようにしたいログ要件

Slide 17

Slide 17 text

複数の種別のログを統一的に収集・集約できること ① ③ ② ログおよびシステムに拡張性があることリソースの維持費やストレージコスト・クエリコストが小さいこと目指したシステム

Slide 18

Slide 18 text

TVerTag 収集集約 Client 大まかな仕組み

Slide 19

Slide 19 text

ログ収集の方針 ● クライアントはログ種別や各フィールドの値を載せてTVerTagへリクエストを送信する ● TVerTagのエンドポイントはpixelデータを返却し、LBのアクセスログを収集する https://cloud.google.com/blog/products/gcp/how-to-do-serverless-pixel-tracking-with-gcp

Slide 20

Slide 20 text

● ストレージが安価なGCSにログを集約し、ログ種別ごとのexternal tableとして BigQueryに見せるログ集約の方針 Cloud Logging Cloud Storage ETL BigQuery Bucket A -> Table A Bucket B -> Table B Bucket C -> Table C

Slide 21

Slide 21 text

● BigQueryのexternal tableとしてGCSを参照したときに、所定の形式でGCSのパスを切っておくことで指定範囲だけをスキャンさせることができる ○ dayだけを指定すればyear/monthを指定しなくてもよい形式に工夫した GCS Hive Partitioning gs://tableA/year=2023/month=202303 /day=20230304/* gs://tableA/year=2023/month=20230 4/day=20230305/* スキャンスキャン SELECT * FROM tableA WHERE day="20230304" SELECT * FROM tableA WHERE day="20230305"

Slide 22

Slide 22 text

● Cloud Loggingでログ種別ごとにRouter経由でPub/Subへ流す ○ ログ種別を後から追加できる ● Cloud Run ServiceがPub/SubからログをPullしてGCSへ格納 ETL処理 (行動ログ) (視聴ログ) (イベントログ) (行動ログ) (視聴ログ) (イベントログ) Cloud Logging Cloud Run

Slide 23

Slide 23 text

TVerTag 集約収集全体構成(初版) Client

Slide 24

Slide 24 text

● external tableの参照先GCSにもアクセス権を付与する必要があり、管理コスト増加につながる external tableの問題(1) gs://tableA tableA クエリ実行参照読み取り権限読み取り権限

Slide 25

Slide 25 text

● BigLake ○ オブジェクトストレージに実データを置いているexternal tableをnative tableと同じUXで利用できる機能 ○ '22 7月にGA external tableの問題(1)の解決方法 https://cloud.google.com/bigquery/docs/biglake-intro

Slide 26

Slide 26 text

● BigLakeにより、権限管理をGCSから BigQueryに移譲することで、 BigQueryと同じ体系で権限管理が可能 external tableの問題(1)へのアプローチ gs://tableA tableA クエリ実行参照読み取り権限 BigLake経由で読み取り

Slide 27

Slide 27 text

gs://tableA/year=2022/month=202204/... gs://tableA/year=2022/month=202205/... gs://tableA/year=2022/month=202206/... ... ● GCSのファイル数が多くなってくるとクエリ性能が劣化 ○ 運用開始当初1分以内に返る集計クエリが2か月後には20分以上かかるように external tableの問題(2) クエリ実行集計結果 < 1分 → 20+分

Slide 28

Slide 28 text

● BigQueryのnative tableに順次投入していくバッチを追加 ○ ただしユースケースの都合でexternal tableも現状は存続 external tableの問題(2)へのアプローチ gs://tableA/year=2022/month=202204/... gs://tableA/year=2022/month=202205/... gs://tableA/year=2022/month=202206/... ... tableA_20220401 ... tableA_20220501 ... tableA_20220601 ETL

Slide 29

Slide 29 text

TVerTag 全体構成(2版) 集約収集追加 Client

Slide 30

Slide 30 text

億 1日あたりのログ数 GiB 1日あたりのログサイズアクセス 1日のピークにおける秒間同時接続数 920 21,000 11 ● Google Cloudを活用することで、リリース以後1年以上の期間においてTVerTagの安定稼働を実現 TVerTag運用状況件ログ欠損発生件数 0

Slide 31

Slide 31 text

さらなる改善に向けて

Slide 32

Slide 32 text

● 必ずしもGCSを経由しなくてもよくなったため、Cloud LoggingからBigQueryへの集約を簡略化を検討中 ○ コスト削減・運用負荷軽減がねらい集約の簡略化 TVerTag 集約収集初版から追加 Client

Slide 33

Slide 33 text

方式検討 Log Router Cloud Logging Log Storage Cloud Logging Cloud Pub/Sub Dataset BigQuery Linked Dataset BigQuery Table BigQuery 参照用Table BigQuery ①BigQuery Subscriptionsを利用する方法 ②Log RouterのSinkにBigQueryを指定する方法 ③Log Analytics('23 1月GA)のLinked Datasetを利用する方法

Slide 34

Slide 34 text

● Cloud LoggingのログをBigQueryのSQLで集計できるようにする ○ '22 9月にサービスPreview, '23 1月 GA ● Log Analyticsを有効化したLog BucketをLog RouterのSinkに指定することで利用可能 ● Log BucketのRetentionが30日以内であれば課金されない Log Analytics https://cloud.google.com/blog/products/data-analytics/moving-to-log-analytics-for-bigquery-export-users

Slide 35

Slide 35 text

● Cloud Loggingのログをそのまま参照できる Viewを指定Dataset配下に作成する機能 ● メリット ○ Log Bucketに入ってくるログをリアルタイムで参照できる ○ BigQueryには実データを保持しない ○ Viewではtimestampフィールドでpartitioning されているためスキャン量を制限可能 Log AnalyticsのLinked Dataset https://cloud.google.com/blog/products/data-analytics/moving-to-log-analytics-for-bigquery-export-users

Slide 36

Slide 36 text

新しい構成 Log Router Cloud Logging Log Bucket Cloud Logging Linked Dataset BigQuery Speed Layer BigQuery TVerTag 収集集約 Batch Layer ETL Batch Layer BigQuery 集計用View BigQuery ※開発中

Slide 37

Slide 37 text

● 結果的にPub/SubやCloud Run・GCSなどをショートカットする想定集約の簡略化 TVerTag 集約収集削除 Client 永続化処理

Slide 38

Slide 38 text

結論

Slide 39

Slide 39 text

結論 ● TVerのサービス戦略に合わせて統一的に拡張性高くログを収集・集約できるログ基盤をGoogle Cloudのサービスや機能を活用して構築した ○ ①突合の手間がかかる ■ →複数のログ種別を一つのログ基盤で統一的に収集・集約が可能 ○ ②ログ種別を後から追加可能 ■ →ログおよびシステムの拡張性を実現 ○ ③Google Cloudのサービスでコストを抑えたデータ基盤を開発 ■ →コストを最小限に抑えた構成で実現

Slide 40

Slide 40 text

データマート今後の展望 ● 体系化されたデータマートの構築 ● さらなるサービスや機能を利用した構成改善 TVerTag Client ユースケース用テーブルユースケース用テーブル

Slide 41

Slide 41 text

Thank you.