2024年3月16日と17日にKアリーナ横浜にて弊社が主催する 加藤純一 presents「第二回 配信者ハイパーゲーム大会」 (https://lp.openrec.tv/hyper-game-event2/) が開催され、当大会のライブ配信がOPENREC.tv (https://www.openrec.tv/) にて行われました。当大会はお陰様で2日間で4万人近くの方にご来場いただき大盛況となりました。また、ライブ配信でもOPENREC.tvの過去最高となる同時接続数約30万人の方に視聴いただき、大きなシステムトラブルもなく終えることができました。

当記事では同時接続数30万のライブ配信に備えるために、弊社の技術組織が行った取り組みについてお話をいたします。
取り組みの中で重視したこととして、一点目は同時接続数30万に耐える負荷対策となります。そして二点目は前回大会の配信よりもインフラコストを低く抑えることです。同時接続数が20万となった前回大会 (加藤純一presents 配信者ハイパーゲーム大会: https://lp.openrec.tv/hyper-game-event/) におけるライブ配信では大きなシステムトラブルこそなかったものの、負荷対策のためのシステムの増強に伴い、過剰にインフラコストをかけてしまったことが反省点としてありました。今回のライブ配信では、同時接続数が20万だった前回大会のライブ配信よりも、さらに多い同時接続数30万の負荷に耐えつつも、インフラコストを前回大会よりも安価に抑えることをKPIとして取り組みを行いました。

■OPENREC.tvの負荷の特性
同時接続30万のライブ配信への取り組みについてお話をする前に、まずはOPENREC.tvの負荷の特性についてお話します。
OPENREC.tvで一番負荷が集中する画面はライブ配信を視聴する画面 (以下、再生画面) となります。この再生画面からアクセスされるシステムのコンポーネントをUI毎に分割すると、以下の画像のようになります。

1つ目は映像配信用のCDNで、HTTP Live Streaming (以下、HLS) 形式で配信された映像関連のファイル群にアクセスするために使用しています。2つ目は投稿されたチャットをWebSocket接続でリアルタイムに視聴者に表示するためのチャットサーバーです。そして3つ目は再生画面の表示に必要なライブ配信関連の情報や視聴者固有の情報などを取得するAPIサーバーならびにAPI用のCDNとなります。
システムの構成を簡単に図にすると以下の様になります。

負荷対策を進めるにあたり、上図で記したどのコンポーネントに負荷が発生するか、そして過負荷になった場合にどのようなリスクが生じるかを想定し、どのような負荷対策を講じるかを考える必要があります。
また、負荷対策のために考慮すべき点についてライブ配信の一連の時系列においてどのタイミングで負荷が高まるかも考える必要があります。
OPENREC.tvのライブ配信において負荷が高まるポイントは、再生画面へのユーザーの出入りが多く発生するタイミングとなり、それはライブ配信の開始時と終了時となります。これらのタイミングで負荷が増大するコンポーネントを特定し、負荷対策を講じていく必要があります。


■負荷対策の進め方
次に当大会のライブ配信に向けた負荷対策の進め方についてお話します。
負荷対策を進めるにあたり、まず初めに想定されるリスクの洗い出しを行いました。リスクの洗い出しでは以下の項目に沿って洗い出しを行い、それらの結果をもとに負荷対策案を策定し、負荷試験や負荷対策案の実施を進めていきました。

1. 負荷に伴うリスクが顕在化するケース
2. 対象のコンポーネント
3. リスクが顕在化した場合に発生する事象
4. リスクを未然に防ぐための対策やリスクが顕在化した場合の対応

また、当大会ではKPIとして前回大会よりもインフラコストを安価に抑えることを定めていたため、インフラコストを抑えるための対策についても重点的に取り組みました。冒頭で述べたように、前回大会のライブ配信では、負荷対策のためのシステムの増強に伴い、過剰にインフラコストをかけてしまったことが反省点としてありました。そのため、今回は適切なキャパシティプランニングを行うことを重視しました。そのための準備として、前回大会のライブ配信を行った月と大規模な配信がない月とでAWSのサービス毎にインフラコストを比較し、コストの差分が大きいAWSのサービスから優先的にコスト削減策を考えていきました。また、前回大会時のCPU使用率などのメトリクスの実績値とその時のサーバー台数から、過剰にシステムを増強していたと判断したコンポーネントについて、増強内容の適正値を暫定的に定めました。そしてその適正値を元に、今回想定されるアクセス数からサーバー台数などを計算し、想定する負荷に耐えられるかを負荷試験で実際に確認することで必要なサーバー台数などを最終的に決定する流れで取り組みました。

これら一連の負荷対策の中で、例えばライブ配信中にこの機能を利用するとシステムリソースを大幅に増強する必要性からインフラコストを圧迫する要因となるようなものは、番組の企画チームと調整してその機能を利用しないように調整するケースもありました。また、番組の企画チームから配信中にこの機能を利用したいなどの要望があったら、その機能を利用した場合の想定リスクの洗い出しと負荷対策案の作成、そして負荷試験などを実施するケースもありました。おおよそ下図のようにして負荷対策をしていった形となり、エンジニアチームだけで負荷対策を完結させずに、適宜ビジネスサイドのチームを巻き込みながら対策を進めていきました。


■予測されるスパイクアクセスにおける負荷対策
ここからは実際に行った各種負荷対策についてお話していきます。
前回大会やその他の過去のライブ配信におけるアクセスの傾向を分析した結果、スパイクアクセスが発生する主なタイミングはライブ配信の開始時と終了時であることが分かりました。そのため、ライブ配信の開始時と終了時に実行されるAPIの負荷対策に重点的に取り組みました。
それらのタイミングにおけるAPIサーバーへの負荷を軽減するための対策として重視したことが、クライアントからのAPI実行数を減らすことでした。そのために行った事として、再生画面を開いた際と閉じた際、そしてライブ配信の開始・終了時に呼び出されるAPIをWebブラウザ、アプリそれぞれで洗い出しました。その結果、同じAPIを不必要に複数回実行していたり、CDNでキャッシュ対象となるAPIでもキャッシュキーに指定している値が、キャッシュ効率が悪い指定方法となっているものなどが見つかりました。改善の対象となる箇所が十数個見つかり、クライアントチームと連携して改善項目について優先順位をつけて対応を進めました。また、スパイクアクセスが予想されるAPIについては負荷試験を行い、パフォーマンスの改善にも取り組みました。ボトルネックの特定には分散トレーシングとして導入しているAWS X-RayやAuroraのPerformance Insightsが非常に有効な手段となりました。

サーバーのキャパシティプランニングにおいては、前回大会や過去のアクセスが多かった配信で実行されていたAPIのリクエスト数を正確に分析するため、ロードバランサーとして使用しているApplication Load Balancer (以下、ALB) やCDNとして使用しているCloudFrontのアクセスログをS3に出力し、Athenaで秒単位のリクエスト数をAPI毎に集計することで、瞬間的に発生するリクエスト数を把握し、それらの数値を今回想定する同時接続数から導き出した想定リクエスト数を定めました。そしてそれらの想定リクエスト数の余剰分、たとえば1.5倍のリクエスト数に耐えられるようにキャパシティプランニングを行いました。
また、キャパシティの見積もりでは、Amazon Web Services (以下、AWS) の各サービスのクォータの制限値を超えることがないかも確認し、必要に応じてクォータの上限緩和申請を行いました。特に映像配信用のCDNとして使用しているCloudFrontは、理論上リクエスト数が30万rps、データ転送量が1.5Tbpsに達する可能性があり、クォータで設定されているリクエスト数25万rps、データ転送量150Gbpsを超えます。特にデータ転送量についてはクォータの値を大きく超えることになります。そのため、ライブ配信当日の数ヶ月前にできるだけ早くAWSの方に情報を共有し、クォータの引き上げについて調整を行いました。

サーバーのスケールアウトの戦略においては、ライブ配信時と終了時に発生するスパイクアクセスに耐えうるように各種コンポーネントを常にスケールアウトさせておくのではなく、スパイクアクセスが発生すると予想されるタイミングに合わせてサーバーのスケールアウトを行い、アクセスが落ち着いたタイミングでスケールインを行うことで、インフラコストを抑えるようにしました。一方で想定外のスパイクアクセスが発生する可能性も想定し、後述するレートリミットの機構や入場制限機能の導入を行いました。

■本番を想定したシミュレーション
キャパシティプランニングの結果、ライブ配信時のサーバーの台数が決まりましたが、実際にその台数に各コンポーネントをスケールアウトした際に想定外の問題が起こらないとも限りません。そのため、実際に各コンポーネントを本番想定の台数までスケールアウトさせた上で、本番想定の負荷を流し、想定外のボトルネックなどが生じないかなどを確認しました。
こうした本番想定のシミュレーションではモニタリングツールとして使用しているPrometheusのリソースは十分か、APIサーバーが稼働しているAmazon Elastic Kubernetes Service (以下、EKS) クラスターで名前解決を行っているCoreDNSやnode-local-dnsのリソースは十分か、などを確認していきました。また、EKSのワーカーノードにアタッチしているサブネットのIPアドレス数が不足しないかについても気を払いました。IPアドレス数が不足するとEKSで稼働しているアプリケーションがスケールアウトできなくなるためです。キャパシティプランニングの際に、使用されるIPアドレス数を事前に算出してはいましたが、本番想定の台数にスケールアウトをして実際のIPアドレスの使用数を確認しました。その結果、想定する最大の台数までPodがスケールアウトした際にIPアドレスが不足する可能性が懸念されたため、Pod数が多くなることが想定されたアプリケーションについて、Node.jsのClusterモジュールを使用して1Podで4コア使う構成へと変更することで1Podあたりの処理性能を引き上げ、そのアプリケーションのPodにおけるIPアドレスの使用数を約1/4に減らす対応を行いました。また、それでもライブ配信中に想定以上にスケールアウトしてIPアドレスが不足する可能性も想定した時のプランも考え、新たにサブネットを作成し、万が一の際は新規にそのサブネットをアタッチしたワーカーノードにもPodを配置するようにaffinityの設定変更をするように準備を行いました。

■チャット機能における負荷対策
OPENREC.tvの負荷対策として重点的に考えるべき要素としてチャット機能における負荷対策があります。
OPENREC.tvではチャット投稿をすると、チャット投稿用のAPIを実行し、データベースにチャットのメッセージを永続化した後、Amazon ElastiCache for Redis (以下、Redis) のPub/Subの機能によって冗長化されたチャットサーバーにチャットのメッセージを伝達します。クライアントは再生画面を開いた際にチャットサーバーへ接続したWebSocketによって、チャットのメッセージを受信する構成となっています。

チャット投稿量が増えれば当然ですがチャット投稿APIがあるAPIサーバーやチャットメッセージを永続化しているデータベース、そしてRedisに負荷が集中することになります。このAPIサーバーとデータベースは、チャット投稿以外のメインのワークロードでも利用しており、これらのコンポーネントが過負荷になるとサービス全体に影響が波及する可能性があります。また、チャット投稿量が増えることでWebSocketでチャットを受信しているクライアントの負荷も増大し、クライアント側の処理量が多くなり、ユーザー体験に影響が出かねません。
同時接続数が数十万規模のライブ配信では、瞬間的に投稿されるチャット投稿量が事前に想定されたチャット投稿量を大きく超える可能性も考えられるのと、チャット投稿量はライブ配信の内容に依存するため、瞬間的に投稿されるチャット投稿量を事前に予測することが難しい点を考慮すると、予測できない全てのチャット投稿を処理するためにシステムを過剰に増強しておくことはインフラコストを圧迫する要因となります。
そのための対策として、瞬間的なチャット投稿量が一定数を超えると自動的にシステム全体が受け付けるチャット投稿量を制限する、いわゆるレートリミットの機構を実装しました。チャットサーバーの負荷試験や過去のメトリクスの実績値、そして許容できるインフラコストなどから、レートリミットの閾値を決定しました。想定範囲のチャット投稿量であればその閾値に達することはないため、ユーザー体験に影響がない状態を維持することができつつ、想定外のチャット投稿量に達した場合のみこの機構が発動し、システムを負荷から守ることができるようになりました。

■映像視聴用CDNのインフラコストを抑えるための取り組み
前述したような対策は、いわばサーバーへの負荷軽減ならびにインフラコストの削減策であり、対策の結果、前回の大会よりも大幅にインフラコストの削減を達成することができました。一方で、これらの対策とは別の観点でインフラコストを削減するために考えなければならないコンポーネントが、映像視聴用のCDNとなります。映像視聴用のCDNはCloudFrontを利用しており、AWSのフルマネージドなサービスとなるため、前述したものは別の観点でのインフラコストの削減策を考える必要があります。
映像視聴用のCDNのインフラコストは、CDNのリクエスト数とデータ転送量に応じて課金が発生するため、視聴数と視聴している映像のビットレートに比例して増加します。以下の図は当大会2日間の映像視聴用CDNのデータ転送量のメトリクスとなりますが、ライブ配信中は常に映像視聴用CDNへのリクエストが常に発生し、継続的にCDNの料金がかかる状態となります。そのため、CDNのデータ転送量をいかに抑えるか、ということがインフラコスト削減の要となってきます。

CDNのインフラコストを抑えるための対策として、一つは配信時のビットレートを必要以上に高くしないようにしました。配信するビットレートの決定においては、現地にて映像配信を行うチームや企画を行うビジネスチームと連携し、快適に視聴できるレベルのビットレートを探り決定しました。
もう一点行った対策として、ユーザーが映像を視聴しておらず音声のみを再生できていればよいような状況、例えばWebブラウザのタブが別タブにあるような状況においては、再生するレンディションを低画質のものに自動で切り替える制御を行うようにしました。この対応によりCloudFrontのコストを一定数削減することができました。

■想定外のアクセス量に対する防御策としての入場制限機構の導入
これまで行ってきたような負荷対策を行ってきたとしても、想定以上のアクセス量となった場合にはシステムが過負荷になり大多数のユーザーに影響が発生する可能性も考えられます。そのような想定外の過負荷に対する防御策として入場制限機能を導入しました。
入場制限は特定のAPIや特定のWebページにアクセスした際に固定のレスポンスを返却するようにすることで実現しています。この機構により、入場制限前に再生画面を開いて視聴しているユーザーには視聴体験への影響を与えることなく、入場制限への切替後に再生画面に流入するユーザーにのみアクセスを制限でき、システムへの負荷を一定に抑えることができます。
この入場制限機能自体は2023年の前回大会時に既に導入してはおりましたが、入場制限への切り替えのための手順の煩雑さが課題となっておりました。OPENREC.tvのWebサーバーとAPIサーバーはEKS上で稼働しており、それらのAPIサーバーにアクセスするためのALBの制御にAWS Load Balancer Controller (https://github.com/kubernetes-sigs/aws-load-balancer-controller) を利用しております。入場制限へ切り替えるためには、クライアントから直接アクセスされるIntenet facingなALB用のIngressの定義を変更したマニフェストファイルをEKSに適用する必要があります。ライブ配信の開始前に入場制限用のマニフェストファイルを事前に作成しておき、そのGithubのPull RequestをマージしてArgoCDからSyncして適用もしくは手動にてマニフェストファイルを変更することで入場制限への切り替えを行っておりました。しかしながら、入場制限への切り替えは、システムへの過負荷を防ぐために行うため、必要なときに迅速に入場制限への切り替えを行わなくてはなりません。また、入場制限を解除する際にもユーザー影響を減らすために迅速に行えることが理想です。入場制限へのオン・オフの切り替えを行うためには、前述の手順では迅速に行うことが難しい状況となっておりました。
この課題を解決するためにKubernetesのカスタムコントローラーとしてDynamic Ingress Operator (Github: https://github.com/toro-ponz/dynamic-ingress-operator) を開発しました。Dynamic Ingress Operatorによって複数のIngressの変更を一つの設定値を変更するだけで動的に行うことができ、簡潔かつ即座に入場制限の切り替えを行うことができるようになりました。

■ライブ配信を終えて
ここまでお話したような対策を行い、ライブ配信当日を迎えたわけですが、前述した想定外の事象への備えとなるチャット投稿のレートリミットや入場制限の機構を発動させるような状況には幸いにも至らず、大きな事故もなく配信を終えることができました。
また、前回大会よりもインフラコストを低く抑えるというKPIについても達成することができました。特にAPIサーバーが稼働しているEKSのワーカーノードであるEC2の料金については、前回大会ではインフラコストが大きな割合を占めていましたが、今回は前回大会時と比較して1/3のコストに抑えることができました。 一方で、インフラコストの中でも映像視聴用CDNのインフラコストが未だ高い割合を占めているため、再生するデバイスの解像度や、映像再生の表示領域に応じて再生するレンディションの上限値を自動で制御することで、さらなるCDNのコスト削減を実現できるように対応を行っていく予定です。
同時接続数が数十万規模のライブ配信の負荷対策を重ねるたびに、システムをより堅牢にかつインフラコストを効果的に抑えるためのノウハウが蓄積されていっていることを実感しています。今後も同規模あるいはそれ以上の規模のライブ配信であっても、ユーザーの皆様に安心してOPENREC.tvをお楽しみいただけるよう、引き続きシステムの改善に努めていきたいと思います。

著者
齋藤 仁  開発本部 SREチーム 部長
OPENREC.tvの黎明期から開発に携わり、iOSアプリ開発、サーバーサイド開発を経てSREチームに所属。クライアントからバックエンドを通した開発経験を活かし、クライアント・バックエンドまで一気通貫の信頼性担保の仕組みづくりを推進。