公開日 2025/02/05更新日 2025/02/05

TVerのデータ基盤アーキテクチャ - 月間再生数4.9億回の視聴ログや、月間ユーザー数4100万人の行動ログを扱う技術

TVerでデータエンジニアをしている山根と申します。
TVerでは「テレビを開放して、もっとワクワクする未来を TVerと新しい世界を、一緒に。」をミッションとして掲げ、民放各局のテレビコンテンツをいつでもどこでも、身近に届けるサービスを提供しています。
その再生回数は年々増加傾向にあり、2024年8月には月間ユーザー数が4100万人を、月間再生数は4.9億回を突破し、同年11月にはTVerアプリの累計ダウンロード数も8000万回を突破しました。
本記事では、TVerのデータを活用したサービス改善を支える基盤の工夫を、アーキテクチャを通して紹介していきます。

TVerにおけるデータ活用とデータ基盤の全体像

TVerは、スマートフォンやタブレット(iOS/Android)、テレビアプリ、パソコンのWebブラウザから民放各局が制作したテレビコンテンツを視聴できるサービスです。会員サービス（TVer ID）への登録やログインをしなくても視聴ができますが、ログインをすることでデバイス間での連携ができる等、より便利にサービスをご利用いただけます。

TVerでは、サービスの機能改善や施策をしていく中で、データからその効果を測定するためにデータ基盤を構築しています。
例えば、ドラマ特集がクリックされたか、そこからどのくらいエピソードの再生につながったか、などをマーケティングのチームと連携することで、次回の特集の内容やデザインなどの改善につなげています。

データはTVer IDを基盤として構成されています。TVer IDでは地上波の放送視聴ログも収集しているので、Webと地上波の視聴データを連携させたデータ分析が可能になっています。
利用するデータ基盤は、大容量のデータを扱えて、サーバーレスで運用が楽かつ機能豊富なBigQueryを採用しています。
TVerで収集しているデータは多岐にわたりますが、今回はデータ基盤を俯瞰的に見るために、代表的に以下の3種類のデータについて紹介します。

TVer上でのユーザー行動ログ
地上波放送視聴ログ
TVer IDの会員マスタ情報

これらを図にすると以下のようになります。

1.TVer、2.地上波を受信するテレビデバイス、3.TVer ID DB から送信された視聴データがBigQueryにデータを蓄積し、Redashから分析するというアーキテクチャとなっています。

1 では、視聴データだけでなく、ページ遷移・いいね・お気に入りクリックなど、あらゆるユーザー行動を収集し、サービス改善に役立てています。
1日あたりのログの量は11億レコード、ログサイズは920GiB、最大の1秒あたりのログ数は21,000にのぼり、これらのデータの量を捌いてBigQueryに保存するシステムをGoogle Cloud上に構築しています。

2 では、TVerアプリでの視聴データとは別に、地上波放送を視聴しているテレビから、データ放送（リモコンのdボタンで設定や管理ができます）を通じて視聴ログを収集しています。
視聴ログはAWS上に構築された視聴ログ APIを通してS3にログが蓄積された後、GCPに転送しています。
1日あたり200万レコード・1~2GiBほどのデータがあり、BigQueryに集約しているので、あわせて分析することもできるようになっています。

3 では、TVer IDに登録している会員のマスタ情報がAmazon DynamoDB上で管理されており、それを分析用にBigQueryに転送しています。
会員のマスタ情報には、ユーザ属性のほか、会員ごとのデータ提供の可否の設定も含まれており、この情報を利用しながら分析や外部へのデータ提供を行なっています。

TVerではこれらのデータを横断してダッシュボードの構築をしたり、分析をするためにRedashを利用しており、Redashでは、各テーブルにアクセスできるサービスアカウントを用意し、分析環境を構築しています。
また、一部個人情報など、取り扱いに注意が必要なデータはサービスアカウントを分けて、社内でも業務で必要な人にのみアクセスできるようにしています。

以下では、1. 2. 3. の各システムについて詳細に紹介します。

TVer行動ログ収集ETLのアーキテクチャ

アーキテクチャの説明

TVerでは、サービス上でのユーザーのあらゆる行動のログを収集するため、WebクライアントやTVerアプリからCloud Load Balancingに向けてデータを送信しています。
Cloud Load Balancingへのアクセスログから、URLに付与されたパラメータをパースして、行動種別に作成されたPub/sub topicにデータが蓄積されるようになっており、その後のCloud RunがCloud Storage・BigQueryに保存するようになっています。
Cloud Storageでは、Hive Partitioning*1レイアウトを用いて視聴ログ・ユーザー行動ログなど種別ごと・年月日ごとに上位のディレクトリを分けています。こうすることで、BigQueryにExternalTableを作成して参照したときに、ファイルの命名規則で読み込みパーティションを分割できるので、直近のデータはログ種別・日付ごとにスキャン量を抑えながらGCSのデータに直接アクセスすることもできます。

技術選定の背景・意図

TVerはコンテンツの公開直後などにアクセススパイクがあること・サービスの成長に伴って、収集するログを拡張しやすいことを考慮して設計しています。
これらを解決するために、クライアントからCloud Load Balancingに向けてアクセスさせ、そのログを収集するというアーキテクチャに決定しました。
Cloud Load Balancingは、100万rps以上をサポートしており、リアルタイム配信開始の急激なアクセススパイクにも特別な運用なく対応することができています。
また、アクセスログのURLのパラメータをパースする形でログを収集するので、ログの拡張の実装もしやすいような設計になっています。

地上波放送視聴ログETLのアーキテクチャ

アーキテクチャの説明

テレビデバイスからAWS上のサーバーに送信された地上波視聴データは、Google Cloud上のETLが処理できる形に整形されS3に保存された後、Storage Transfer Serviceによって、Cloud Storageに転送されます。
転送されたデータは、主に一次加工としてログ種別を識別するCloud Run 、二次加工として15秒ほどの間隔で送られてきているビーコンの視聴データを視聴開始・終了に圧縮しRedashから利用可能なDWHに転送するCloud Runという2つのデータ加工を通して集約されます。
Storage Transfer Serviceによる転送と、2つのCloud RunによるETLの実行というアーキテクチャで構成されており、各ステップの実行状況はCloud Datastore上で管理されています。
各ステップは1時間単位で冪等に処理できるようになっており、Cloud Datastoreで各ETLの進行状況を管理するという仕組みを取り入れることで、転送が未完了のファイル群のみ自動的にETLがリトライされる仕組みになっています。

技術選定の背景・意図

リアルタイムの地上波の視聴からおおよそ1時間後に、視聴データが集計できること・自動的にETLがリトライされることを目標に設計しています。
各家庭のインターネットやテレビデバイスの事情により、1時間以上遅れてデータが到着することもありますが、ファイルの書き込みイベントでCloud Datastoreのステータスを未処理に更新することにより、遅れてきたデータも都度読み込むことができています。
また、あえてBigQueryのストリーミングインサート機能は使用せず、1時間単位のCloud Runでのバルクインサートを採用することで、BigQueryへのInsert費用を抑えながら、1時間程度の遅延で視聴データを分析することができています。

会員マスタ情報ETLのアーキテクチャ

アーキテクチャの説明

TVerの会員情報には、その会員の属性とデータ提供の可否フラグが含まれており、これらを利用して分析基盤を構築しています。
会員情報はAWS DynamoDB上で管理しており、これをDynamoDB streamsでMySQLにレプリケートし、さらにこれをDatastreamでBigQueryに連携させることで分析基盤で活用できるようにしています。
BigQueryでは、カラムごとにアクセス権を付与できるので、社内でも限られた人物やシステムにだけメールアドレスなど取り扱いに注意が必要なデータを参照することができています。
サービス拡張に伴って、会員マスタ情報が拡張されるときも、分析用MySQLに反映させる実装は必要ですが、DatastreamがMySQLのデータ構造を読み取ってくれる機能があるため、手軽にスキーマ変更を対応させることができるようになっています。

技術選定の背景・意図

会員DBにはユーザーのデータ提供許諾可否情報が含まれており、できるだけ早くデータ基盤に反映させるようにしています。
DynamoDB streamsおよびGoogle Cloud DatastreamはリアルタイムでDBの変更差分をキャプチャし送信するので、ほぼ最新のユーザー情報を用いて分析することができています。
また、Google Cloud Datastreamでは、data freshnessというRDS(MySQL)からBigQueryへの同期がどれくらい遅延しているかをあらわすメトリクスが提供されており、データの遅れを検知することができています。

現在の課題

TVerのデータ基盤は、TVer上のユーザーの行動ログから地上波ログなど多岐に渡り、各放送局などステークホルダーとのデータ連携も多岐に渡ります。
その中で、データ利用をする枠組みが整備しきれていないところがあり、一部手動で権限をつけたり、都度提供用のViewを作成してしまっている箇所もあります。
今後は、社内外へのデータ連携をより安全に・利用しやすく提供するため、terraform、 Dataformなどでコード化されたデータマートの構築を進めていきたいと思っています。
特に今後活用が広がっていくにつれ、権限付与のフロー・アラート・障害時の対応などデータ利用の安定性・安全性を高めていくことが求められていくと思うので、Analytics Hub / Dataform などを検討して安全にデータ利用ができる仕組みを整えていきたいと思っています。

データ活用の今後の展望

TVerでは、TVer上のユーザー行動ログ・地上波放送視聴ログが、TVer IDという会員基盤を通して、ユーザーの属性に紐づく形で整備されており、その量・種類共に膨大なものとなっています。
今後は特に、地上波放送視聴ログとTVerのユーザー行動ログを紐付けて活用できるようにしていくデータマート基盤を整えつつ、放送局や社内外のステークホルダと連携しながら、よりテレビコンテンツを身近なもの・価値あるものにして届けるということに挑戦していきたいと思っています。