総合格闘技大会BreakingDownの高負荷に耐えるライブ配信システムを、サーバレスの「Cloud Run+TiDB Cloud Serverless」で再構築に成功した話［PR］

株式会社BACKSTAGEは、さまざまなバックボーンをもった格闘家が出場して1分1ラウンドで最強を決める総合格闘技大会「BreakingDown（ブレイキングダウン）」の運営とともに、ライブ配信「BreakingDown LIVE」などを行うスタートアップ企業です。

同社のライブ配信システムは、もともと別の企業から買収したシステムでしたが、あるときライブ配信中にシステム障害が発生。それを機に、同社はライブ配信システムを新たに構築し直すことを決意します。

新たなライブ配信システムで採用するアプリケーションサーバとデータベースの条件は、マネージドサービスとしてライブ配信のような高い負荷でも安定した運用ができること、そして運用コストができるだけ安いこと、など。

そして選ばれたのがGoogle Cloud RunとTiDB Cloud Serverlessでした。

昨年（2024年）9月に行われたイベント「Serverless Days Tokyo 2024」で同社の秋葉祐人氏が行ったセッション「サーバーレスで構築する Breaking Down LIVE」では、同社のライブ配信の基盤としてなぜCloud RunとTiDB Cloud Serverlessが選択されたのか、具体的な検討過程が紹介されました。

そのセッションの内容をダイジェストで紹介しましょう。

ライブ配信中の高負荷で障害が発生

秋葉氏は、再構築前のライブ配信システムは、アプリケーションサーバにAWS Amplify（Amazon S3＋Cloudfront）、データベースにはGoogle Cloud Firestoreが主に採用されていたと説明したうえで、ライブ配信中の障害の原因がこのシステムのFirestoreの使い方にあったと話します。

具体的には、ライブ配信画面におけるコメント表示で表示されるユーザー名の取得にキャッシュなどを使わず、コメントが表示されるごとにFirestoreへクエリが発生していました。

「同時視聴しているユーザーが全部、コメント欄に表示されるユーザー名を一斉に取りに行くという恐ろしい状態になってしまって、おそらくピーク時には推定ですが数百万QPS（Query Per Second）ぐらいには到達していたのではないかと思います」（秋葉氏）。

これによってFirestoreにホットスポットが発生し、そのレイテンシによりライブ配信が止まってしまったようになったと推察されています。

その他にもライブ配信のアプリケーションのコードの見通しが悪いことなどの要因もあり、ライブ配信アプリケーションの再構築によるリレプイスが決断されました。

安定したライブ配信のために再構築によるリプレイスを決断

リプレイスにあたっての最優先事項は、安定したライブ配信を実現することでした。同社はライブ配信の担当エンジニアがフルタイムで2人しかおらず、その2人にはできるだけ運用よりもアプリケーション開発に注力させたいということで、アプリケーションサーバとデータベースにはマネージドサービスを選択することが優先されます。

その上で、運用コストやインフラコストが安価であることも重視されます。

技術上の最大の課題は、ライブ配信システムの負荷予測が困難な点にありました。

Breaking Down LIVEはイベントによってトラフィックが大きく変動するだけでなく、イベント内でもユーザー投票やPPV（ペイパービュー）の購入などのタイミングによって短時間で大量のトラフィックが不定期に集中する、いわゆるスパイクが発生します。

「通常時とスパイク時を比較すると、だいたい50倍くらいリクエスト数が変化するときがあります」（秋葉氏）。

このような条件下で、アプリケーションサーバとデータベースサーバ選びが進められました。

フロントエンドはVercel、バックエンドにはCloud Runを採用

フロントエンドのホスティングは、WebアプリケーションフレームワークのNext.jsが浸透していること、同社がモノレポの構成であることからTurborepoで扱えること、静的コンテンツが自動でキャッシュされるなどの理由で「Vercel」が採用されました。

バックエンドのアプリケーションサーバには、フロントエンド開発と同様にTypeScriptに対応し、高いスケーリング性能やサーバレスのためアクセスがない場合にはほぼコストがかからないこと、そして既存のライブ配信システムの認証で使われているFirebase Authenticationをそのまま引き継ぐ上で相性がよいなどの理由で「Google Cloud Run」が採用されることになりました。

Cloud Runの起動速度に課題、改善を試みる

しかしCloud Runの負荷テスト中に課題が見つかります。アクセスが集中したタイミングでは、API全体のレイテンシが5秒程度発生してしまいます。

原因を調べると、コンテナの起動に時間がかかっていたことが分かりました。

Google Cloudの「Container Startup Latency」メトリクスによると、99パーセンタイルで約9秒かかっており、アクセスが集中して発生するスパイクに対してコンテナの起動が追いついていないようです。

コンテナの起動速度を改善するためにまずチェックされたのは、Cloud Runの設定にある「起動時のCPUブースト」です。しかしすでに設定済みでした。

Dockerイメージのサイズ削減は、ビルドやデプロイの速度は向上するとしても、Google Cloudの説明によると起動速度のボトルネックにはならないとのことでした。

最も効果があったのは、Node.jsのモジュールとして入れていたOpen Telemetryによる自動計測を外したことでした。

「おそらく本来不要なものも多く含まれてしまっていたのが原因なのかなと思ってます」（秋葉氏）。

これによりContainer Startup Latencyの値は約4秒にまで改善。まだ完全にスパイクに耐えられる状態ではないものの、配信開始前に最低インスタンス数を設定しておくことで対策しているとのことです。

性能と価格に見合うデータベースがなかなか見つからない

続いてデータベースの選択について。

まずGoogle Cloud SQLなどのマネージドデータベースを用いて、予測されるトラフィックのピークに対してある程度バッファを持たせたスペックを用意することで対処することが検討されました。

しかしこの方法ではピーク以外の時間はずっとオーバースペックとなり、コスト増が懸念されることとなります。

ピークに対処するための負荷分散処理としては、レプリケーションやシャーディングなどの手段もあります。

レプリケーションは多数のリードレプリカを作成することでリードの負荷を分散させることはできますが、本システムのスパイクではライト処理も多いため、レプリケーションでは対処できそうにありません。

データベースを分割して負荷分散させるシャーディングは、自分たちで実装するとシステムが複雑になってしまいがちで、実装コストの増加の懸念があります。また、スパイクに対応するためには、あらかじめ多数に分割したデータベースを用意しておく必要があるため、やはりコスト面での懸念が残ります。

Google Cloud SQL、Spanner、Amazon Auroraなどのマネージドデータベースも検討されましたが、ストレージのみのオートスケールであったり、コストを抑えるために使用していないときには停止させる手間がかかったり、日本国内のリージョンで提供されていないためにレイテンシが大きかったりと、なかなか性能面やコスト面での要望に見合うデータベースが見つかりません。

NewSQLのTiDB Cloud Serverlessを採用へ

「そんな中でTiDB Cloud Serverlessというデータベースサービスを見つけまして、結論から言ってしまうと今回このTiDB Cloud Serverlessを採用しました」（秋葉氏）。

TiDB Cloud ServerlessはMySQLとプロトコル互換の分散型SQLデータベースであり、負荷に応じて自動でスケールする従量課金制となっています。

「なぜTiDB Cloud Serverlessを選んだかというと、スケールに関してはストレージだけでなくコンピューティングリソースのスケールも可能な点。十分なスケーラビリティを持ち、データベース容量もテラバイトまで想定していると伺いました。

サーバレスの従量課金制なので未使用期間は自動的にインスタンスが停止してストレージ費用のみで済む点や、レイテンシに関してもCloud Runからは約数十ミリ秒以内と許容範囲なところ、MySQLとプロトコル互換なので使い慣れたSQLをそのまま使えるため追加の学習コストが低く済みそう、などの点から導入を決めました」（秋葉氏）。

一部の懸念点として、外部キー制約のサポートが実験的実装の段階であったこと、Google Cloudでは接続がパブリック接続であること、トリガーなどMySQLの機能の一部が使えないこと、などがありましたが、いずれも導入を妨げるほど大きな問題ではなかったとしました。

リプレイスに成功し、スケーラブルでコストも安く

すでにTiDB Cloud Serverlessはリプレイスされたライブ配信システムのバックエンドデータベースとして使われ始めています。リプレイスの成功について、秋葉氏は次のようにまとめています。

「リプレイスしてから8回ぐらいイベントのライブ配信を行っていますが、大きなトラブル発生することなく運用できてます。

特にTiDB Cloud ServerlessはMySQLとほぼ変わらない扱いでアプリケーションを実装できつつ、負荷に応じたスペック調整を自分たちで行う必要もなく、非常に楽に開発運用ができているなと感じています。

Cloud Runのコンテナ起動速度の問題に関しては改善がまだ必要ですが、Cloud Run＋TiDB Cloud Serverlessの構成ですと利用していない、あるいは利用が非常に少ない時期にはほぼ費用がかからずに運用できていて、ライブ配信時でも負荷に応じてスケールするのでオーバースペックになるタイミングは非常に少なくなっていると思います。

また、ライブ配信中のアクセスの多いタイミングでも、リプレイス以前よりもコストを大幅に下げることができており、全体的に今回のリプレイスは自分たちのユースケースに合致した構成で構築できたと考えています」（秋葉氏）。

≫TiDB Cloud Serverless | MySQL互換の分散型データベース | PingCAP株式会社

（本記事はPingCAP Japan提供のタイアップ記事です）