こんばんは。こんにちは！
バックエンドエンジニアのうつみです。 この記事はTVerメンバーによるアドベントカレンダーの22日目の記事です。
TVerにおけるサーバー負荷について
今回の記事は配信部分ではなく、アプリを構成するために必要なAPIサーバーの運用について書いていきたいと思います。（配信系期待されていたらごめんなさい 🙏
TVerではお陰様で毎日たくさんのユーザーの方が利用してくださっているので、サーバーへのアクセスもそこそこの規模になってきます。
地上波の見逃し配信やリアルタイム配信などといったサービス特性上、コンテンツの切り替わり時間などはアクセススパイクが日常的に発生しています。
そういった緩急の激しいアクセスパターンを安定して処理するためにAPIサーバーを適切にスケールアウト、スケールアップをする必要が出てきます。
この記事ではそういった日々の運用について書いていきます。
普段のアクセスパターン
これは先週のとある一日のALBのリクエスト数のグラフになります。
この日は特別番組や、イベントなどのなかったごくありふれた日常的なパターンです。
GP帯と言われる19時ごろからどんどんアクセスが増え、そこから正時などのコンテンツの切り替わり時間になると比較的軽度なスパイクが発生します。
これらのスパイクはリアルタイム配信などで視聴目的のコンテンツの配信が開始、終了することにより一斉にユーザーがプレイヤー画面へ遷移したり離脱したりするため発生します。
現在TVerではキー5局のリアルタイム配信をさせていただいておりますが、GP帯での番組枠の時間はほぼどこの放送局でも一定になっています。
そのためユーザーアクションがどうしても集中してしまいます。
またそういった切り替わり時間に加わり特別番組やイベントなどが重なるともっと大きなスパイクとなっていきます。
定常時以外のアクセスパターン
これは注目を集めているコンテンツのリアルタイム配信タイミングのグラフです。先程のグラフよりも拡大したものになります。
諸々の都合上時間や数値をぼかしているのですが、スパイクが発生している箇所は正時でのコンテンツ切り替わりに加え注目コンテンツによるアクセスユーザーの増加が発生しているタイミングになります。
定常時だと前時間帯の150%のピークになることが多いのですが、この例では400%を超えるスパイクが発生しています。
これくらいの規模のスパイクになると、定常時のサーバー台数ではレイテンシの悪化や、サーバーダウンが発生しかねません。
そうならないように、適切なスケーリングを実施するため普段からチーム間でのアクセス予測などのすり合わせを行っています。
スパイク予測における変数
インフラの運用を担務としている我々では精度の高い注目コンテンツの予測などはなかなか難しく…
- 話題の演者さん
- 人気監督の作品
- スポーツリーグなどの順位争い
など、実際のコンテンツにおける注目度を算出するために必要な変数は様々です。
配信している番組はたくさんありますし、我々インフラ運用の担当者がすべてキャッチアップするのには限界があります。
そのため普段からコンテンツの配信設定や、プロモーションなどを担当しているメンバーと一緒に、1週間以内に配信される予定のコンテンツの注目度の高いものを洗い出しスケーリングの必要有無を確認しています。
スパイク発生の要因
先にも書いたように注目度の高いコンテンツなどはもちろんスパイクを発生させますがそれ以外にもスパイクが発生する要因がいくつかあります。
などなど、細かいものも合わせるといろいろあります。
3に関しては突発的かつ、予測不可能なため今回は触れません。
地上波放送時間終了によるTVerへの誘導
スポーツ番組をイメージしていただくとわかりやすいのですが、地上波では19:00~21:54まで放送があり21:54までに試合が終了せず、TVerで配信している場合などに発生します。
この場合、地上波では解説者やアナウンサーなどから 「試合の続きはTVerで」というようなアナウンスを入れてくださいます。
試合の展開にも大きく左右されるのですが、野球9回2アウト的な感じだとより大きなスパイクを発生させることになります。
こちらに関しては試合展開ももちろんですが、そもそも地上波放送終了時に試合が予定どおり終わっていることもあったりするため不確定要素が多量にあります。
そのため余裕を持ったスケーリングを施し、一斉流入に備えます。
地上波連動企画などによるTVerへの誘導
こちらはバラエティの特別番組などに多いのですが、地上波では音楽番組を放送し、TVerではその舞台裏を生配信する。といったような企画もあります。
この場合、地上波のMCの方がTVerで舞台裏配信していることを告知してくださるので、そのタイミングでアクセスが発生します。
こちらはおおよその告知の時間や、担当者の情報などをいただいていることがほとんどなので過去実績などをベースに精度の高いスケーリングの値を算出していきます。
スケーリングテンプレート
TVerでは様々なパターンのアクセスがあることをご紹介いたしました。
その中で毎回精度の高いスケーリングを目指してしまうと、算出するための情報取得コストや、熟練の業になってしまうリスクが節約できるサーバーコストを超えてしまうと判断しました。
まだまだ少人数の小さな組織なのでできる限り運用負荷を減らしていかないといけません。
8ヶ月ほど運用してきた実績と、メトリクスなどを見ながらおおよそ5パターンにスケーリングテンプレートを用意しました。
- 定常時の朝〜夕方
- 定常時のGP帯
- 定常時の深夜帯
- 注目度の高いコンテンツ
- 超大型案件
といった具合でわけています。
もともとが少ないECS FargateのTask数で運用していることもあり、これ以上細かく調整してもAvailabilityZoneの偏りなど、逆に考慮しなければならない点もあったためざっくりとした分け方になっています。
もちろん過去実績にないような更に大きな案件がきた場合や、特殊なイベントの場合などは手動で微調整したりもします。
日々の運用
TVerでは毎日たくさんの新しいコンテンツが配信開始されていきます。
そういった中で今まで書いてきたようなスケーリングを番組ごとにやっていては我々の運用チームが死んでしまいます。
TVerでは土日、深夜も安心してプライベートを満喫できるようにGoogle Calendarと連携させて、スケジュールスケーリングを実現しています。
こちらがGoogle Calendarに設定されたTVerのAPIサーバーの自動スケーリングの設定になります。
実際はGoogle Calendarをトリガーにして、APIを実行しています。
TVerにはたくさんのサーバースタックを素早くスケーリングや作成できるOmniscientという管理ツールがあります。この話はきっと誰かがどこかでやってくれるかと...
毎日の深夜帯と、注目のコンテンツなどのタイミングで設定しています。
カレンダーでスケーリングが可視化されていると、今週の夜は騒がしそうだな。とか、土日はわくわくするな。とかが瞬時に見て取れるのでとても助かっています。
また、テンプレートを用意したことによりカレンダーとの連携においての入力が格段にシンプルになり熟知したメンバー以外でも容易に設定が可能になりました。
さいごに
TVerのAPIサーバーバックエンドチームは、日々の予測難易度の高いアクセスパターンに対応すべく、自動化はもちろんチューニングも日々の業務で取り組んでいます 💪
アクセスが集中するということは、それだけコンテンツを楽しみにしてくださっているユーザーがいるということ。
そのわくわくをそのまま楽しんでいただけるようAPIサーバーの安定稼働を一緒に支えてくれるエンジニアを募集しております。
カジュアルにお話からでも結構です。気になったら是非お声がけください。
