一般団法人電子情報技術産業協会（JEITA）は、「InterBEE」を、2022年11月16～18日にかけて開催。今回は幕張メッセでのリアルイベントとオンラインイベントを並行しての開催となった。本記事では「INTER BEE FORUM」のオンラインセッション「TVerにおけるインターネット配信の視聴体験とパフォーマンス安定化への取り組み」の模様をレポートする。

本セッションではNew Relic株式会社 技術統括 コンサルティング部 ソリューションコンサルタント 古垣智裕氏による案内のもと、株式会社TVer サービス事業本部 技術開発部 リードエンジニア 加我貴志氏が登壇し、TVerにおける最近の視聴方法の傾向をふまえながら、アクセスが集中した実際の事例を紹介。具体的な対策とともに、リアルタイム監視システム「New Relic」を活用した視聴体験安定化の取り組みが紹介された。

お気に入り・いいね数を指標に視聴ピークを把握、クラウドで柔軟にサーバー台数を調整

TVerでは、視聴者側・事業者側それぞれを起因として発生するアクセス障害をモニタリング・検知する仕組みとして、New Relic社の開発するリアルタイム監視システム「New Relic（ニューレリック）」を導入。

視聴者側においてはアプリケーションエラーやネットワーク疎通のトラブルを収集・可視化して分析しているほか、事業者側においてはサーバー負荷の状況やリクエスト数、エラーを可視化。安定した視聴体験を維持する体制作りに役立てている。

TVerにおける1日のアクセス数はGP帯に向けて上昇し、その後ピークを迎えて減少するというパターンがメイン。TVerがプラットフォームとして利用するAWS（Amazon Web Services）・GCP（Google Cloud Platform）では動的にサーバー台数を増減できるため、想定されるアクセス数に合わせて、動的にサーバー台数を調整するアプローチが取られている。

リクエスト数、サーバー台数の見積もりには、「番組へのお気に入り登録数、個別のエピソードに対する『いいね』の数、出演者情報」（加我氏）を指標として用いているという。

ちなみに、先述のクラウド環境では特定条件をトリガーに自動でサーバーの増減を行う「オートスケーリング」機能が搭載されているが、トリガー検知からサーバーの起動が完了するまでタイムラグがあることから、TVerでは独自の仕組みを構築しているという。

予測不可能なアクセス集中への対応（１） SNSのバズで加速度的に視聴者が殺到した例

しかし時には、番組の人気から予想を超えてアクセスが集中するケースも。加我氏は、TVerの見逃し配信数歴代トップを記録した（2022年11月現在）ドラマ『silent』（フジテレビ系）の例をあげて解説する。

2022年10月6日の第1話放送時は負荷が想定の範囲内に収まり、とくに問題なく対応できたが、この回がSNSで大きな反響となり、10月13日の第2話、10月20日の第3話放送時にはいずれも前週を上回るアクセスが殺到。リアルタイム配信が一時的に視聴しにくい状況となったほか、放送終了後の見逃し配信にもリクエストが集中した。

そして10月27日の第4話放送時にはさらにアクセスが増加。この日はプロ野球日本シリーズの中継が延長し放送時間が変更されたが、もともとの放送時間にリアルタイム配信へのアクセスが集中。さらに変更後の放送時間、見逃し配信開始時間と、3度にわたってアクセスが殺到する事態となった。

このように普段のアクセス傾向を外れた突発的なアクセス集中は「なかなか難しい」（加我氏）というが、可能な限り負荷を予測する備えとしてTVerでは「New Relic」を活用してユーザー側の視聴体験を可視化。日々のリクエスト数と負荷情報を細かく可視化し、想定パターンを見出すことでサーバー台数をあらかじめ調整するほか、バックエンドサーバーのパフォーマンス分析を通じ、APIの応答速度や稼働数の改善につなげているという。

予測不可能なアクセス集中への対応（２） 加熱したスポーツ中継からのTVer誘導

このほか「地上波のスポーツ中継をTVerのSpecial Live配信でリレー中継する場合、注目された番組のエンディングに『もう一度見たい方はTVerで』と見逃し配信案内があった場合にも、瞬間的なアクセス集中（スパイクアクセス）が起こりやすい」と加我氏。

実際に、ある日のスポーツ番組では、終了間際にSpecial Live配信案内がされた瞬間、瞬間的にリクエストが通常の約10倍に跳ね上がったという。

「ピーク時のリクエストを全部さばくため、アクセス数の山（最大値）がどれくらいの高さで来るかを予測する必要があるが、このピークは番組によって変化するため完全な予測は難しい」と加我氏。「スポーツ中継の場合、得点争いが拮抗するなど試合展開によってピークが大きく上振れする」といい、「そのうえでTVerでのリレー中継を実施した際など、さらに上振れしたアクセスが来る場合もあり、サーバー台数の予測が難しい」と語る。

場当たり的なサーバー増強ではなく、パターン化による「傾向と対策」を重視

“予測不可能”なアクセス集中への対策について、「（場当たり的に）サーバー台数を増強するより、それに対する備えを（あらかじめ）行う」と加我氏。「異常が起きたときにその正体を把握し、将来に対して対策を行う」といい、毎週のトラフィック（通信量）パターンを常に分析、前週との差分をチェックしていると語る。

負荷の状況については「New Relic」のダッシュボード機能を使い、グラフ形式でデータを一覧表示。アプリケーションの稼働状況などサーバーサイドのログを監視することでパフォーマンスの低下箇所をいちはやく把握し、異常発生時に過去の類似ケースと関連付けて迅速な調査が行えるようにしているという。

このほか「New Relic」のアラート機能を活用し、異常発生時はそのレベルに応じて「条件別アラート」を設定。通知手段は通常の業務にも使用するチャットツール「Slack」を基本としながら、「重大な異変については自動で電話がかかってくる」と述べた。

「シェアしたがるか、“じっくり派”か」番組ごとの視聴者行動を把握し負荷制御に活用

今後も安定した視聴体験を提供するための中長期的な対策として、加我氏は「SNSでのバズを起因とするアクセス集中への対応を進める」と説明。番組への「いいね」やお気に入り登録したユーザーの属性を分析するという。

「（お気に入りの番組を）SNSにシェアしたがる特性を持つユーザー層なのか、（とくにシェアせずひとりで）じっくり見るだけのユーザー層なのかを分析する」と加我氏。「負荷の調査や備えのための“インプット情報”としてこれらの情報や、番組関連のSNSつぶやき情報を活用し、負荷の分析、把握につなげる」と語った。