[レポート] TVer におけるインターネット配信の視聴体験とパフォーマンス安定化への取り組み #interbee

大前諒祐

2022.11.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大前です。

本エントリは、2022/11/16 - 11/18 に幕張メッセ + オンラインにて開催されている、Inter BEE 2022 のセッション「TVerにおけるインターネット配信の視聴体験とパフォーマンス安定化への取り組み」についてのレポートブログです。

セッションはユーザー登録を行うことで、オンラインでも視聴可能です。

セッション概要

テレビ番組はインターネット配信が進み、どこでもいつでもどの端末でも見られ、SNSでの共有など今までにない楽しみ方ができるようになりました。それに伴い、テレビ同様、またはそれ以上の視聴体験が求められています。TVer様をゲストにお迎えし、最近の視聴方法の傾向やそれに伴うインフラ運用の変化、そして視聴体験を安定させるための工夫や対策を、具体例を交えながらお話し頂きます。

セッションリンクはこちら（登録が必要です）

スピーカー

古垣智裕氏
- New Relic株式会社技術統括コンサルティング部ソリューションコンサルタント
加我貴志氏
- 株式会社TVer サービス事業本部技術開発部リードエンジニア

レポート

メディア業界におけるオブザーバビリティとは
- 動画の視聴体験とパフォーマンス全体を可視化
TVer について
- TVer は民放のテレビ番組を配信するサービス
- 月刊動画再生回数が2億5千万回を突破
成長の背景について
- ライフスタイルの変化
  - 余暇時間の多くを占めるテレビ
  - 最近は余暇時間の奪い合い
    - スマホやインターネットの普及

地上波とインターネット配信の技術的な違い

技術的な違い
- 放送の仕組み
  - 従来は電波に乗せて各家庭のアンテナにブロードキャストする 1対多
  - インターネットはサーバーとユーザーが 1対1 で接続するものが多数
- 配信設備
  - 地上波では電波を配信するための設備が必要（スカイツリーなど）
  - インターネット配信においては配信サーバーが必要（CDN、ロードバランサー、ストリーミングサーバー、など）
    - 配信サーバーの管理
      - オンプレミス ... 自分たちでサーバーを購入、運用
      - パブリッククラウド ... ベンダーが構築したインフラを利用、必要な時に必要な分だけ利用が可能（TVerはこちら）
        
        TVer はピークを境にリクエストの増減がある
        
        リクエストのピークに合わせてサーバを用意するとコストが無駄に発生してしまう
        
        一方で、ピークを捌くためのサーバは必要
        
        クラウドを利用し、動的にサーバー台数を管理し、最適化
- 視聴体験
  - 地上波ではテレビという視聴専用機があるため、体験としてはほぼ固定
    - 長い歴史に支えられた信頼性
    - 見れないケース
      - 視聴者側の問題（機器の故障）
      - 放送事業者側の問題
      - 自然災害・停電
  - インターネット配信では多様な視聴環境が存在（PC、スマホ、タブレット、コネクテッドTV）
    - 信頼性を担保する箇所も変化
      - ハードウェアからソフトウェア
    - 見れないケース
      - 視聴者側の問題（ネット回線、端末の問題、アプリの問題）
      - 事業者側の問題（ネット回線、クラウド側の障害、サーバの過負荷）
    - 配信が見れない時を検知する仕組みが必要
      - 視聴者側のトラブル / 事業者側のトラブルをそれぞれ検知する仕組みが必要
      - NewRelic を利用して実現している

リアルタイム配信の技術的な難しさ

負荷対策
- 負荷予測
  - GP タイムに向けて増加、ピークを境に減少
  - リクエスト数とサーバー台数を見積もる指標
    - 番組へのいいね、お気に入り登録数
    - 出演者情報など
  - 負荷予測の難しさ
    - silent というドラマ
      - 見逃し配信で圧倒的な再生数
      - リアルタイム配信でも前週を超えるリクエスト
      - 1話時点では通常のサーバー台数で問題なし
      - 2話では 1話を超えるリクエストが発生
      - 3話になるとさらにリクエストが発生し、一時的に視聴しにくい状況に
      - 4話は日本シリーズの延長が発生、それでも従来よりも多くのリクエストが発生
    - 注目度の高い番組への対応が求められる
      - 前週のリクエストを上回り続ける
      - SNS でバズるとリクエスト数がはねる
  - 負荷予測への備え
    - 視聴体験の可視化に New Relic を活用
    - 日々のリクエスト数と負荷状況をチェック
    - 日々の負荷状況を配信運用チームにも共有
- スパイクアクセスへの即時対応
  - スパイクアクセス = 瞬間的に大量のアクセスが来ること
    - SNS によるバズ
    - スポーツ番組等からの「続きは TVer で」など（地上波から TVer への誘導）
      - 視聴者が一気に TVer にアクセス
      - 一気に 10倍のリクエストが来たことも
  - ピークのリクエストを全て捌く必要がある
    - ピークの予測
    - ピークは番組によって変化
    - スポーツなどでは試合展開にも影響される
  - どれだけサーバーを用意すれば良いのか悩まされる
  - 視聴体験への可視化に New Relic を活用
    - 日々のリクエスト数と負荷状況をチェック
  - クラウドであってもスケールには時間を要する
- 予期せぬトラフィックへの備え
  - 予期せぬトラフィック = 通常のパターンとは異なる大量のアクセス
    - 番組が SNS でバズった
    - スポーツ番組の放送枠切れ
    - 人気タレントの登場
  - サービス提供への影響がある可能性
    - サーバーの処理能力を超えてしまう可能性
      - サイトのスローダウン
      - 動画の再生エラー
      - 一時的なサーバーダウン
  - 予期せぬトラフィックへの心構え
    - 異常に気づく
      - New Relic アラート
        
        特定条件でアラートが発生
        
        Slack への通知で異変に気づく
        
        影響度によっては電話で連絡
    - 正体を確認する
      - New Relic ダッシュボード
      - New Relic ログ分析、アプリケーション分析
    - 異常への対策を行う
      - 短期的な対策
        
        サーバの増強など
      - 中長期的な対策
        
        いいね、お気に入り等の属性を分析
        
        インプット情報として番組の SNS を把握