民放公式テレビ配信サービス「TVer」は、視聴データ基盤をGoogle Cloudのデータベース「Spanner」に統合した。レコメンドの応答速度は120秒から164ミリ秒に短縮され、対話形式で番組を探せる「AIコンシェルジュ」のベータ版もリリースされた。
月間4470万ユーザーが利用するTVerは、常時約1000番組を配信し、再生数は月間6.5億回に上る。見逃し配信は期間が限られ、1週間程度で視聴できなくなる作品も多い。配信期間が終われば、ユーザーと作品の接点は失われてしまう。限られた時間の中で、視聴者と作品（商品）をいかに出会わせるか。ECをはじめ多くの事業に共通する課題だ。
データ基盤をSpannerに統合
TVerの小柳正暢氏（サービスプロダクト本部バックエンド開発部 エンジニア）は「推薦と検索という2つの柱の質が、視聴機会を左右する」と述べる。探さなくても最適な作品が届く推薦と、探したときに確実に見つかる検索。実現したいことは3つある。類似コンテンツ推薦（番組内容の近さを基にして推薦する）、ユーザー行動ベース推薦（「この番組を見た人はこちらも」という形に推薦する）、検索精度の改善と基盤の統合（既存の検索機能を作り替える）だ。
従来のシステム構成には2つの問題があった。1つ目は「データ規模」だ。メインのデータベースは米Amazon Web Services（AWS）のクラウド上で稼働する「Amazon Aurora MySQL」を利用していた。日々の視聴行動から生まれるデータは数億行の規模に膨らみ、書き込み先を1箇所に集約する構成では、処理量の増加に対応できないという懸念があった。
2つ目は「システム構成」である。コンテンツの検索は検索エンジン「OpenSearch」、推薦結果の保管は高速データベース「Redis」、ユーザーデータは「Amazon Aurora」といったように、主要なシステムが3つに分散していた。これらを常に同期させ、障害に対処し、データの構造を1箇所でも変えたら3つすべてを直す必要がある。その運用コストは積み重なり、データの更新経路の把握や同期タイミングの制御も難しくなっていた。
推薦も検索も、同じデータを基に処理している。1つのデータベースに集約すれば、これらの問題はまとめて解決に向かう——そう考えたTVerが選んだのが、米Googleが「Google Cloud」で提供するデータベース「Spanner」だ。意味の近さで似た番組を探す「ベクトル検索」、ユーザーと番組のつながりをたどる「グラフ探索」、キーワードで探す「全文検索」という3つの探し方をSpannerだけで扱う。サーバを足せば、書き込み性能を拡張することも可能だ。
AWSとGoogle Cloudを連携、データ設計の解
移行の流れはこうだ。Amazon Auroraに蓄積したデータの変更内容を、データ連携サービス「Datastream」でデータ分析基盤「BigQuery」に送り、データ変換処理が可能な「Dataform」でデータを加工して、Spannerへ書き出す。部品は多いが、いずれもGoogle Cloudの標準機能で、処理の指定はSQL（構造化問い合わせ言語）で組む。「専用のインフラや、データを運ぶ仕組みを別途管理する必要がなく、シンプルに保っている」と小柳氏は説明する。
類似コンテンツ推薦に使うデータも、番組のタイトルや説明文を「Gemini Enterprise Agent Platform」のモデルで変換し、前述の仕組み内で生成している。
一方、スキーマ（データの持ちさせ方）の設計思想はAmazon Aurora時代から変える必要があった。Spannerはデータを自動で分割して複数のサーバに分散させるため、ユーザーIDやコンテンツIDなど「どのIDを軸にするのか」を誤ると特定のサーバに負荷が集中してしまう。TVerはユーザーIDなどを軸に据え直し、同時に読み込むことが多い視聴履歴を、近い場所に配置した。
難しいのは、この設計を後から変えられない点だ。変更にはデータの全件移し替えが伴う。「設計初期の段階で、どこにどうアクセスが来るかを分析し、決めておく必要がある」と小柳氏は述べる。
推薦にかかる時間「120秒→164ミリ秒」に短縮できた工夫の数々
新システム開発の難所は、ユーザー行動ベース推薦の性能だった。Aさんが見た作品を基に、同じ作品を見た別のユーザーを経由し、その人たちが見ている作品をAさんに推薦する。この探索を専用の問い合わせ言語で書くこと自体は容易だったが、応答が遅すぎた。
初期段階では、絞り込みのない状態で全データをスキャンした。120秒経っても結果が出てこない状態だったという。1つの番組を見た人を絞り出すための絞り込みを追加したところ推薦に成功したが、複数番組を条件にすると全データのスキャンに戻ってしまった。第2段階では、絞り込みをユーザーデータと同じ場所に置いた。離れた場所にある絞り込みを突き合わせずに済み、読み取る行数は11.4億行から340万行へと減少。それでも応答時間は19〜48秒かかっていた。好みが似ているユーザーを全件探す処理が残っており、高い速応性が求められる用途には使えない。
第3段階のサンプリングでは、数千万人に上ることもある視聴傾向の似たユーザー全件を追わず、先頭の1000人の探索で打ち切ることにした。その結果、読み取る行数は2万3000行、応答時間は164ミリ秒まで下がった。推薦の精度も、全件を探した場合と比べて上位30件の並びはほぼ変わらない。
絞り込みの追加、配置の見直し、サンプリングの3段階を経て、応答速度の問題が解決し、数億行規模の探索がようやくオンラインで使える水準に収まった。問題はまだある。次に現れたのは結果の偏りだ。好みが共通するユーザー数だけで作品をランキングにすると、人気のドラマやバラエティーが誰に対しても同じように並んでしまいます。小柳氏は「パーソナルな推薦になっていなかった」と振り返る。
そこで順位付けを、単純な視聴人数から、好みの似たユーザーの間でどれだけ見られているかという指標に変更した。速度、精度、スコアリングの方式の3つがそろって初めて、パーソナルな推薦ができるようになった。
新データ基盤のおかげで「AIコンシェルジュ」リリース可能に
運用面では問題も残る。一つは反映の遅れだ。新しい番組が登録されてから推薦結果に現れるまで数時間かかる。原因はAmazon AuroraからBigQuery、Spannerへとデータが渡る流れ全体にあり、配信期間の短いTVerには悩ましい問題だ。
もう一つは絞り込みの手入れだ。検証段階では、データが1件もない状態で絞り込みを作ったために設定が最小のまま固定され、毎回全データを走査していた。データ量に合う設定で作り直すと、CPU使用率は56%減り、探し漏れもほぼなかった。全件を検索した場合と比べて97%一致したという。ここから、データが増えるたびに手を入れる必要があると分かった。
懸念していたコストは、移行済みの処理が限定的で単純比較はできないとしつつ、既存の3システム分と同等の規模に収まっているという。「推薦も検索も同じ粒度のデータで動くようになり、整合性の管理も1つに収まった」と小柳氏は総括する。現在、類似コンテンツ推薦はA/Bテスト段階にある。ベクトル検索の仕組みが整ったことで、対話形式で番組を探せる「AIコンシェルジュ」のベータ版をリリースできた。全文検索によるOpenSearchのリプレースも性能検証が進んでいる。
データ量とシステム構成に起因する問題によって、多くの作品を抱えながらも生かされていなかったTVer。新システムによって諸問題を改善できた今、TVerの視聴体験は次の段階に入ろうとしている。
