新しい視聴率の作り方 〜20,000台のセンサ × 15,000倍の音声データ処理 × AWSサービス〜 #CUS-04 #AWSSummit

本記事は、AWS Summit Japan 2021のセッション動画「新しい視聴率の作り方 ～20000 台のセンサ × 15000 倍の処理量×クラウドマイグレーション～ (CUS-04)」のレポート記事です。

カッコ書きのこれ、どこかで一度は見たことありませんか?

(ビデオリサーチ調べ)

テレビの視聴率や広告の統計調査などでよく見かける、あのビデオリサーチさんがAWS Summitにご登壇です！視聴率特有のシステム要件を、どのようにAWS上で実現していったのかを解説したセッションとなっております。

概要

"10%のために15000倍の処理をする？オンプレ＆メインフレームの老舗企業が、新しい視聴率を作るために取り組んだこと" リアルタイム、タイムシフト、個人視聴率といった2020年4月開始の「新しい視聴率」を提供するため、ゼロから始めたクラウドマイグレーション。20,000台のセンサから届き続ける視聴データを、これまでの15,000倍の処理をしつつ視聴率にする仕組みをご紹介。SavingsPlansやRIの全社共有も、Amazon Athenaを使った分析によって適正管理を実現しました。メインフレームのクラウド化やAWS Fargateを用いたコンテナ化、 ARMアーキテクチャ採用など、今後の取り組みについてもお伝えします。

スピーカー

• 豊島 潤一 氏
  • 株式会社ビデオリサーチ IT/技術推進局 システム開発・運用部 シニアフェロー
  • 視聴率関連のPM/PL、アーキテクトを担当

内容

• ビデオリサーチと視聴率について
• 視聴率システムについて
• 視聴判定の仕組み
• AWSでのシステム構成
• クラウド化してみて
• 顕在化した課題への対応
• 今後の取り組み

ビデオリサーチと視聴率について

• ビデオリサーチについて
  • 1962年設立
  • 社員数436名
    • 内、クラウドに関わる部門は全体で１割程度
  • 半世紀以上続く老舗のメジャメント企業
• 視聴率調査の変遷
  • 最初の視聴率調査は、都内23区から始まる
  • 2020年4月の「新しい視聴率」（新視聴率）
  • → 形を変え、範囲を広げ、現在では全国32地区の視聴率を測定
• 視聴率以外の調査やデータも提供
  • VR FACEによる、IDへのプロフィール付与
    • 個人情報なしに、IDに対して属性情報を付与できる
  • タレントイメージ調査
• → テレビ関係以外でもたくさんのデータを持つレア企業

※出典: 自社ユーザーのプロフィールが分からない... 「VR FACE」による調査データを用いたプロフィールエンリッチメント | マーケット | VR Digest plus　データでイマを読み解く

視聴率システムについて

• 視聴率について
  • 全国32地区、10,000世帯20,000台以上のテレビを常時測定
    • 24時間365日、センサがデータを届き続ける
    • 協力いただける世帯の家にセンサを設置して、測定を実施
  • リアルタイムとタイムシフトの視聴率を測定
    • リアルタイム視聴率: 放送中の視聴から算出する視聴率
    • タイムシフト視聴率: 放送後、7日以内の視聴から算出する視聴率
  • 結果を契約社様へ提供
• 新しい視聴率とは
  • データ量、処理量の増加
    • 調査対象である世帯（パネル）の増加
    • 調査内容の増加
    • タイムシフト視聴率による劇的な増加
• → より正確かつ多様なデータの提供が可能になった

※出典: 連載特別企画第一弾　新視聴率のスタートで変わること～来年4月全地区同一仕様に～ | テレビ | VR Digest plus　データでイマを読み解く

視聴判定の仕組み

• 視聴率が作られる処理の流れ
  • パネル宅
    • テレビが見られる
    • センサがその音声からフィンガープリントを作る
  • AWS
    • インターネットを経由して集める（収集）
    • 集めたデータで視聴判定処理をする（マッチング）
  • メインフレーム
    • 視聴判定結果を集計して視聴率にする
  • オンプレ
    • 契約者様へ提供する
• システム構築の前提条件
  • コストよりも安心、安全を最重視
  • 視聴率システムの根幹となるアプリはプロプライエタリなものが多い
    • 移行に際し広範な改修と、長期の検証が必要
  • まずはリフト、シフトやリアーキテクトは後から
    • ハードや物理資産を持たないクラウドだからこそ可能
    • リフト期間に人材も育つ
  • 基本パワーでねじ伏せる！
    • 処理量の多い処理については、高コストのハイスペックインスタンスを多数稼動
    • 安全性を重視し、ロジックの変更による改善は後回し
• 視聴率調査特有のシビアさ
  • データは絶対取りこぼせない
    • 個人の行動は様々なため、行動を推定してデータを補完することはできない
    • → 集める、測定する、計算する、いずれのプロセスでも問題を発生させてはいけない
    • サンプル数が限られるからこそ、取りこぼしは許されない
    • → 設置機器の仕様と併せ、その発生を極力なくすシステム設計が必要
  • 視聴量（負荷量）の予測が難しい
    • 速報や放送内容によって、視聴行動は大きく変わる
  • テレビは、テレビ放送を見るだけのデバイスではない
    • 放送中？タイムシフト？BD？ゲーム？インターネット動画？たくさんの可能性がある
    • → 基本的に、テレビ放送視聴の可能性を想定して処理
    • → テレビ視聴ではないデータの判定処理がシステムにとっては最も高負荷
  • 処理の遅延は致命的
    • テレビの1日の区切りは、4:59 ~ 5:00と特殊
    • → 深夜0時までのデータを提供するのではなく、早朝5時までのデータを、朝9時に提供しなければならない
  • → 過去に安定稼働してきたシステムとの差違は、絶対に発生させたくない
  • → 発生した場合は全て解消または原因を究明できるよう、長期の平行期間が必要

AWSでのシステム構成

• 設計方針
  • まずは負荷のピークに合わせて、準備するリソースを決定
  • ロードバランサやマルチAZ、ホットスタンバイ等々の「よくある組み合わせ」を採用
• システム構成
  • ①パネル宅でテレビが視聴されると、視聴FP（Finger Print）がNLB経由でデータ収集サーバー（Collect）に送信
  • ②Collectが視聴FPをAmazon Auroraに格納
  • ③視聴判定処理サーバー（Matching）が、視聴FPを取り出して判定を行う
  • ④視聴判定結果をAWS LambdaでS3に吐き出す
  • ⑤S3上の視聴判定結果をメインフレームが取得し、視聴率を作成する

• 視聴率の判定方法
  • ローカルマッチ → 今後全廃予定
    • エッジ（宅内に設置した機器）で視聴chを判定し、結果だけをシステムに送信する
    • 設置機器コスト: 大
    • サーバコスト: 小
    • タイムシフト測定: 不可
  • センターマッチ
    • テレビの音声をフィンガープリント化し、システム（主にAWS）へ送信、判定はサーバ上のアプリで行う
    • 設置機器コスト: 小
    • サーバコスト: 大
    • タイムシフト測定: 可
• db.r5.24xlargeが4台、c5.largeが1200台の理由
  • → タイムシフト測定を実現するために、センターマッチを採用したから
• センターマッチの詳細
  • テレビの音声から、フィンガープリント（FP）を作成してサーバーに送信
  • 放送波からマスタとなるフィンガープリント（FP）を全ch分作成
  • テレビ音声のFPとマスタのFPを比較し、その類似度で視聴判定する
    • 例） テレビから「6時のニュースです…」というFPが送信された時、その音声と一番類似する音声のchが視聴チャンネルと判定される
  • → 20,000台のセンサから、24H365D届き続けるデータを、200ch以上の放送と比較し続ける処理量
  • → タイムシフト場合はさらに、過去8日間691,200秒と比較している。リアルタイムとの差は46,080倍
  • → 処理ロジックを効率化しても、15,000倍の負荷はかかってしまう

クラウド化してみて

• コストへの考え方
  • 安定のためならコスト増はやむを得ない
  • Savings PlansやReserved Instancesを活用してのコスト削減
    • このコスト削減は、リアーキテクトや内部ロジック変更の必要がない点が良い
    • 特にCompute Savings Plansは、将来のリアーキテクトにも対応できる柔軟なプラン
  • Migration Acceleration Program (MAP)の適用によるクレジット付与を受ける
  • 迷ってオンデマンドで課金されるくらいなら、買う!
  • 新サービスのキャッチアップは重要
    • 例） Amazon EBSをgp2から同性能のgp3にするだけでも、コスト削減が可能
  • VRも新サービスや新たな取り組みなどにより、利用は見込み以上に増えている状況
• クラウド化してよかったこと
  • クラウドのスケーラビリティを生かし、長い新旧システムの並走期間、助走期間を確保できた
    • → クラウド特有のリスク炙り出しや、サーバ構成を決定するうえでの十分な性能検証も行えた
    • 並行稼働期間中に登場した新しいインスタンスも選べる
  • 視聴量やパネルと測定対象テレビの増減に対し、柔軟にサーバ構成を変動させて負荷に対応できている
  • たまに、AWSサービスの単純値下げや性能アップの恩恵にも預かれる
  • 割引や契約の共有（請求の一本化）は出来ている
    • → リソース削減が達成できれば、その恩恵（Savings Plansの余剰分）を他部署で活用できる
    • 全社的なインフラの共有に関してはこれから
  • 本番環境と同等の構築が容易になったため、運用ツールの内製化や人材育成も容易に
  • IAMポリシーやセキュリティグループの設定変更するだけで、リモートワークにも高速対応
  • サーバレスアーキテクチャを採用することで、開発範囲や運用保守の肥大化を阻止

→ 力こそパワー!で乗り切ったけど、後からリソースを減らしたり、RIやSPを全社でシェアできるクラウドだからこそできた判断

顕在化した課題への対応

• 複数アカウントのコスト按分問題
  • 当社では80以上のAWSアカウントを請求アカウントにぶら下げている
    • コスト最適化のため、Savings PlansやReserved Instancesは請求アカウントで購入し、全アカウントで共有
  • → それらが余って無駄になることは発生しづらくなるが、アカウントごとの正確なコストの算出が困難
    • どのRIやSPが、どのアカウントで使われたかを特定しづらい
    • 特に、エンタープライズサポート費用の算出はややこしい
  • → 急速に増えるクラウド利用料の管理は大変だった
• Amazon Athenaでコスト分析して解決
  • アカウントごとのAWS利用料を算出
  • アカウントごとのRI、SPの割引額を算出
  • AWS利用料 - 割引額を計算し、アカウントごとの実コストを可視化
  • 料金テーブルがAPIで取得でき、かつ構造化されていて非常に容易
  • エンタープライズサポート料も、オンデマンドの実請求額の比率に応じて按分し、公平な負担を実現

• Auroraが高負荷だけど、すでに最上位のインスタンスを使用している（db.r5.24xlarge）
  • Performance InsightsやSlow Queryなどで、非効率な実行計画や重たいクエリをつぶす
  • AZ跨ぎが発生していないか確認
• Out of Capacityでリソースが立たない
  • AZに依存しない設計にして、フレキシブルに切り替えるところまで自動化
• リージョン障害によるシステム影響
  • 大阪リージョン登場を機に、マルチリージョン化しよう
• メンバーが足りない
  • AWSのプログラムや研修を活用してのスキルアップを実施
  • 環境をフレキシブルに構築できるため、内製やハンズオンも推進
  • AWS認定の取得、Solution Architect Professional 2名、AWS Solution Architect Associate 5名
• コスト高騰（インフラ、運用両面）
  • オンプレの考え方でシステム設計、運用設計すれば高くつく
  • 常にスケーリングを意識した設計、運用でコスト管理をしていく
  • エンタープライズ契約によるTAMのサポートや、AWS Cost Anomaly Detectionを積極的に活用
• 利用ガイドラインの整備不足で散らかる
  • 既存の社内ガイドラインをベースに、CCoEの立ち上げを始めよう!
  • 結果的にセキュリティ向上やコスト削減にもつながる

今後の取り組み

• EMRによるメインフレーム機能の代替を検証中、クラウド化もスコープに
• 視聴判定へのARMアーキテクチャの活用
  • c6g系インスタンスで4割程度のコスト低減が可能？
• DynamoDBやElastiCacheの採用
  • データや処理、業務の特性に応じた、RDBMS以外のデータベースも視野に
• 運用作業や障害復旧、リリース、テストなどの自動化
• 大阪リージョンの活用
• 起動の高速なAWS Fargateを利用したコンテナ化
  • 視聴状況や過去の情報を元にした視聴量予測を、柔軟かつ効率的にスケーリングして実現する