ちょっと話題の記事

(レポート) 『SHOWROOM』の大規模化に伴う技術課題のソリューション #denatechcon

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

はじめに

本ブログは2018年2月7日(水)に開催されたDeNA TECH CONFERENCE 2018のセッション、「『SHOWROOM』の大規模化に伴う技術課題のソリューション ~演者・視聴者の熱量を支える負荷対策、HTML5対応など~」のレポートです。

スピーカーは株式会社SHOWROOMの池滝 俊太さん。

レポート

自己紹介

SHOWROOM tech studio head
2014年新卒入社、エンターテイメント事業本部配属→SHOWROOMに異動(出向)

仮想ライブ空間「SHOWROOM

アイドルやタレント、アーティストとリアルタイムにコミュニケーション
同期性(生放送)
視聴者の可視化(視聴者にアバターを設定)
常時100から150イベントを開催
 同時に開催されているイベントの中でファン数などでバトルする

2013年11月に立ち上げ、サービス開始5年目

技術的な負債も溜まってきている
技術メンバーがどう対応しているのかをご紹介

SHOWROOMのアーキテクチャ

サーバ
 MySQL、memcached、Perl製のWeb/Batch/Daemon、bcsvr(pub/sub)、動画配信サーバWowza
 出来るだけ租結合に設計
クライアント
 iOS、Android、PC版Webクライアント

SHOWROOMの負荷対策

2016年に大規模イベントがあり、その対策として実施
Webサーバを止めない
 可能なものは非同期化(Pub/Sub活用)
 QueueにはQ4Mを利用
APIチューニング
 アクセス数の多い順にAPIをチューニング
 改修前と改修後のパフォーマンスはApache Benchで計測
Server負荷対策
 クリティカルなのはMySQLへのクエリ
 1つずつチューニング、銀の弾丸は本当にない
 Order byはMySQLではなくアプリサーバ側で実施
 動画配信サーバはオートスケール
 事前に高負荷がわかる場合は手動スケール
  トップコンテンツ(たくさんのファンを持っている人)の場合は配信前に依頼がくる
  依頼を受けたらSlack経由で手動スケールアウト
  Twitterで反応を見ながら調整
  配信のルームごとにサーバをSharding
   大規模配信の場合はShardを占有させてEdgeサーバをスケーリング
Clieht負荷対策
 OSや機種を網羅的に検証
 1ルームに大量の視聴者がいる高負荷状況をシミュレーション
 CPUのモニタリング、動画のカクつきをチェック
 高負荷シミュレーション用のスクリプトを用意
  大量のユーザーが大量のアクションを実行
  コメントなどの勢いも数パターン実施可能
  ルーム内の実装を変更した場合の検証など、日常的に利用
 コメントの総量が多すぎる場合、一定のコメントを間引いている
  間引くロジックは都度変更
  アバターの表示順に従って間引く優先順位を決めている

発生した障害

一定時間Webが応答しない障害が発生
 2017年2月、新たなトップコンテンツが追加
 DB高負荷により障害発生
 他のトップコンテンツの配信が止まった
Web改修後、一定の時刻にWebの高負荷が発生
 Apache Benchで検証し、性能劣化するAPIを特定
 ネガティブキャッシュを使っていなかった

負荷対策勉強会を実施

チーム全体で振り返りを実施
サーバ側の障害であったが、クライアント側のエンジニアにも学びがあった

PC版のHTML5化

2013年11月のリリース時からAdobe Flash Playerを利用
アバターのような複雑なアニメーションやソケット通信など
Web標準の流れからHTML5化を検討
PixiJSを利用
 アバターを置き換え
bcsvrによるPub/SubをWebSocketに置き換え
JavaScript動画プレイヤーの実装
 hls.jsを使って実装
 遅延が短くなりきらない問題
  クライアントと配信サーバの両方をチューニング
  バッファリングとチャンクの最適化

サービスの特徴

視聴者と演者のエンゲージメントが高い
 一時的にサービスが断すると致命的
エンゲージメントを保つために動画の視聴が何よりも大事
 映像やコメントを遅延させないことも大事
 映像がカクついたりコメントが遅延するだけでエンゲージメントが落ちる
エンゲージメントの最大化のために負荷対策をする
 とはいえ、落ちるものは落ちる
 エンゲージメントを壊さないものから守る
 一番重要なのは動画配信

サービスの成長

技術的負債の対策をしながらエンゲージメントを高める
技術的なチャレンジも鋭意継続中

サービススケールに伴う問題→コンテンツの監視

配信動画やコメントの適切/不適切の監視が必要
AIによる違反画像判定システムを導入
 Yahooが開発したopen nsfwがベース
 疑わしきはアラート
  ポリシーは「人間の見落としをサポートする」こと
 現在は精度を調整している段階

大事なこと

サービスの特性とシステムの特性を全員が理解すること
サービスを作るのは楽しい

さいごに

サービスに対する想いがしっかりと伝わるセッションでした。特にHTML5での様々なチャレンジは勉強になりました。