『SHOWROOM』の大規模化に伴う技術課題のソリューション ～演者・視聴者の熱量を支える負荷対策、HTML5対応など～

1. 『SHOWROOM』の大規模化に伴う
技術課題のソリューション
～HTML5対応、演者・視聴者の熱量を支える負荷対策～
SHOWROOM株式会社
池滝 俊太

2. ノベルティーを用意しました！
2
マイクロファイバークロス
サイリウム

3. ブースも用意しました！
3
ゆっくりしていってね

4. 自己紹介
- 池滝 俊太 (26)
• SHOWROOM Tech Studio Head
- 慶應義塾大学環境情報学部卒業
- 2014年 DeNA新卒入社
- 2014年7月～ エンターテインメント事業本部
• 新規事業の企画・プロトタイプ開発に携わる
- 2015年2月～ SHOWROOMに異動 & 8月子会社化
• Androidアプリ、サーバーサイドのリーダーを経て、現在はサービス開
発の部署 SHOWROOM Tech Studio のマネジメントを行っている。
- コンピュータと音楽とエンターテインメントが好き。
4
@Iketaki

5. 仮想ライブ空間「SHOWROOM」

7. 生放送のみ。演者と視聴者が同じ時間を共有する
ことで、高いファンエンゲージメントを生む
アイドルやタレント、アーティストとリアルタイ
ムで話せて、 ギフティングやコメントで応援が
できる 仮想ライブ空間 SHOWROOM
同期性
視聴者の
可視化
ストーリー
創出
視聴者の姿や名前、アクションを可視化して、ユー
ザーのエンゲージメント向上を支える
イベントがリアルドラマを生み、ファンの感情移
入を促す

8. 本日お話しすること
•2013年11月に立ち上げ→サービス開始5年目に突入
- 技術的負債も溜まってくる
- 一方、サービスは成長中
•どのようにチームが戦ってきたのか、実例を交えてご紹介
8

9. 目次
•負荷対策事例紹介＜サービスのグロースと起きる問題＞
•PC版のHTML5化＜最新技術への追従＞
•サービス特徴とシステムの特徴
•今後の取り組み
•まとめ
9

10. 負荷対策事例紹介
＜サービスのグロースと起きる問題＞

11. SHOWROOMのアーキテクチャ
11
•主な登場人物
- [Server]
• MySQL, Memcached
• Web・Batch・Daemon（全てPerl）
• リアルタイムサーバ「bcsvr」（Pub/Sub）
•動画配信サーバー Wowza（Origin/Edge構成）
- [Client]
• iOSアプリ・Andoirdアプリ・PC版Webクライアント

12. SHOWROOMの負荷対策
12
再来週からいまの10倍
のトラフィックくるよー
•2016年6～8月に大きなイベントがあり、その当時の約10倍のト
ラフィックが見込まれた
•そこにターゲットを合わせて、大規模な負荷対策を行った

13. [Server]負荷対策 - 方針
13
•まず何よりもWebを止めない
- 非同期化できる処理は非同期化
• 例）ギフティングアクションのPublish処理
- Job QueueにEnqueueし、DequeueするDaemonにて処理
• QueueにはQ4Mを利用
•APIチューニング
- アクセス数の多い順に1つ1つチューニング
- Apache Benchを使う

14. [Server]負荷対策 - 方針
14
•Batch, DaemonにおいてクリティカルとなるのはほぼMySQLへ
の重いクエリ
- これも1つ1つチューニングしていく、銀の弾丸はなし
- 過剰にselectしていたレコードを絞り、必要数ぶんレコードを
取る
- Order by, 絞り込みをMySQL側でせず、アプリサーバ側で行う
- インデックス

15. [Server]負荷対策 - 方針
15
•動画配信サーバーは、オートスケールが効くようにしてある
•事前に大規模配信がわかっている場合、オートスケールにかかる数分の安定
性を確保するため、事前に手動スケールアウトさせておく
- ビジネスのメンバーを通して依頼がくる、トップコンテンツの場合が多い
- 依頼を受け、Slackを用いたChatOpsでスケールアウトできるようにしてあ
る
- Twitterで反応の大きさを見る
•それでも多い場合は、CDNに流せるようにもしてある
- 遅延が少し大きくなるので、トレードオフ

16. [Server]負荷対策 - 方針
16
•配信サーバーのShardingの様子
•配信ごと（＝ルームごと）に、Shardが割り当てられる

17. [Client]負荷対策 - 方針
17
•OS/機種や画面の向き/通常配信・VRなどのパターンを網羅的に
検証し、問題を洗い出して潰していく

18. [Client]負荷対策 - 方針
18
•1ルームに大量の視聴者がいる高負荷状況をシミュレーション
•高負荷状況を保ちながら各種ユーザー操作、長時間のスムーズな視聴がで
きるかも検証していく
- CPU負荷のモニタリング（Android Studio, Xcode）
• ギフト、コメントの通知が多すぎてさばききれない、など
- GPU負荷のモニタリング（Xcode）
• SHOWROOMでは大量のアバター・ギフトの描画をOpenGLレイヤーで行ってい
る
- 動画を再生し続け、止まったりカクついたりしないことを検証

19. [Client]負荷対策 - 方針
19

20. 高負荷シミュレーション
20
•
•下記の動作をするプロセスを多数作成するスクリプト
- コメント
- ギフティング
- テロップ
- 支援ゲージ
- アバターの並び順更新
•大量のユーザーが大量のアクションをするルームができる
•勢いも数パターン用意する
- 徐々に or 突発的
$ srsys_perl live_load_test.pl [ROOM_ID]
コメント
ギフト
ギフト
コメント
支援ゲージ
アバターの並び順
テロップ

21. 高負荷シミュレーション
21
•この高負荷シミュレーションの仕組みは、日常的にQAに用いてい
る
•ルーム内の実装を大幅に変更したときなどの再検証に役に立つ

22. コメントについて
22
•コメントの総量多すぎた場合、クライアントの負荷を下げるため
に間引いている場合もある
- 間引くロジックは都度変更している
• ギフトやコメント量によって表示の優先順位は高くしている（アバターの
表示順と同じ仕組みなので、アバターからコメントが吹き出しで見えるよ
うに）

23. 順風満帆
半年～1年ほど経ち、障害いろいろ
これらを施し、うまくいった

24. 一定時間Webが応答しない障害
24
•2017年2月、トップコンテンツによる大規模なユーザー流入
•DBの負荷が高まることによって引き起こされた
•原因は、イベント機能におけるポイント集計のクエリが重く、他
を引きずってWebが詰まった

25. Webの改修後、一定の時刻にWebの負荷が高まる
25
•PC版の処理を改修したが、1日ごとに連続で高負荷アラート
•該当付近で多くコールされているAPIを調査
•Apache Benchで検証したところ、性能劣化しやすいAPIがあっ
た
•ネガティブキャッシュが効いておらず、毎回DBアクセスをしてい
る箇所が
- ネガティブキャッシュ…DBにデータが存在しないことをキャッ
シュするしくみ

26. なぜ起きたのか
26
•イベントの盛り上がりにより、関連データ量が著しく増加した
•まとまった負荷対策PJ後にも機能改修は継続される
- 継続的にやっていくしかない

27. 負荷対策勉強会をやった
- 社内ドキュメントだけでなく、しっかりチーム全員で振り返る
- クライアントサイドの人にとっても学びがある
27
APIコールをできるだけ減らそう
タイミングをずらせるように工夫しよう

28. PC版のHTML5化
＜最新技術への追従＞

29. PC版
29

30. ＿人人人人人人人人人人人＿
＞ Adobe Flash Player ＜
‾Y^Y^Y^Y^Y^Y^Y^Y^Y^Y‾

31. Adobe Flash Player
•2013年11月のリリース時からPC版にて使用
- アバター・ギフトなどの複雑なアニメーション
- Socket通信によるPub-Subサーバとのやりとり
31
-RTMPプロトコルによる動画配信／視聴

32. （ところで）動画ストリーミングのプロトコルについて
•いくつかあるが、多クライアントに配信するものでは下記の3つが
主流
- RTMP
- HLS
- MPEG-DASH
• HTTPベース
32

33. HLS, MPEG-DASH
33
•HLS
- Apple
- HTTPベース（≒リクエスト単位で映像を受信）
- 現在広く使われている
•MPEG-DASH
- ISO標準規格
- HTTPベース
- 最近盛り上がってきている

34. RTMP
34
•Real-Time Message Protocol
- リアルタイムに音声や動画などをやりとりするためのストリーミングプロ
トコル
•Adobe社が開発
•RTMPS／RTMFPなどの変種がある
-TCPの上に実装されている
-遅延が少ない
•Flash Playerでカメラ・マイクを扱うことで、ブラウザ上で配信側もできる

35. Adobe Flash Player
35
•2013年11月のリリース時からPC版にて使用
- アバター・ギフトなどの複雑なアニメーション
- Socket通信によるPub-Subサーバとのやりとり
• コメント・ギフトの通知、ストリーミングURLの変更通知な
ど、様々な用途に利用
• RTMPプロトコルによる動画配信／視聴
•良いソリューションではあったものの、Web標準の流れ、
セキュリティ的な懸念もあるので、HTML5に移行を行う

36. アバター・ギフトの描画
36
•PixiJSを用いている
- “the fastest, most flexible 2D WebGL renderer.
http://www.pixijs.com/
- チューニングを行った結
果、パフォーマンスを出し
つつも、よりなめらかなア
ニメーションも実現できた

37. Pub/Subサーバとのやりとり
37
•コメントやギフトのリアルタイムPub/Subの機能にはbcsvrとい
うプロダクトを使っている
- DeNA製のプロダクト。TCPの上で、テキストベースのプロトコ
ルでPub/Subを実現する
•bcsvrは、生のTCPの他にWebSocketをしゃべることができるの
で、WebSocketで実装して解決

38. Javascript動画プレーヤーの実装
• をつかって実装
•https://github.com/video-dev/hls.js
•JavaScript HLS client using Media Source Extension
38

39. が、問題もある
•遅延が短くなりきらない問題
- クライアント（hls.jsのチューニング）／配信サーバー
• バッファリングの最適化
• チャンクの最適化
- チャンク: 細切れになった映像データ
- 現在開発・検証中です
39

40. サービスの特徴、システムの特徴

41. サービスの特徴
•視聴者・演者のエンゲージメントが高い
- 単位時間にかける熱量が高い
•企業ミッション「努力がフェア(公正)に報われる社会を創る」
- 一時的にサービスがダウンしたとしても、ある演者、視聴者に
とっては致命的かもしれない
41

42. サービスの特徴からシステムの特徴が見えてくる
•何よりも動画の視聴が大事、演者と視聴者のエンゲージメントを
保つ
•さらに、映像、コメントなどを遅延させないことが大事
- インタラクティブ性が落ちることで、エンゲージメントが落ち
てしまう
- 映像カクつくだけで、意識が演者からシステムの方に向いてし
まう
•配信者きっかけで急に負荷が増大する
42

43. サービスの特徴からシステムの特徴が見えてくる
•演者と視聴者のエンゲージメントを最大化する、システム上の「思
いやり」を大事にしたい
- 負荷対策をしっかりし、できるだけサービスを落とさない
• とはいえ、落ちるものは落ちる
• そうなったら、エンゲージメントを壊さないところから潰していく
- 映像は守りたい
- RTMP→HLS移行における遅延の問題
43

44. 溜まっていく技術的負債
•データ量増加によるクエリチューニングの問題
•技術のレガシー化
44

45. でもサービスは成長
•技術的負債の対策をしながらユーザー体験を向上させる
- けど着実に視聴者・演者のエンゲージメントを支えたい
- コードの歴史に敬意をこめて、更新していく
•まだまだシステムの安定性、機能による価値も増したい
- 新技術、新アーキテクチャによる機能も鋭意開発中
- 力強いプロダクトマネジメント
45

46. おまけ: AI監視について

47. スケールにおける問題: コンテンツの監視
- UGC（User Generated Contents）を生むサービスにおいて
は、配信・投稿されたコンテンツがポリシー違反していないか
の監視が重要
- SHOWROOMではリアルタイムで監視すべきものが多い
• 【配信者】配信動画の内容
• 【視聴者】リアルタイムコメント など
- 特に配信数が増え、配信動画内容の監視工数問題が深刻に
• CSが24時間365日監視しているため
47

48. AIによる違反画像判定システムを導入
- 画像の違反度判定
- ライブ中の全動画を定期的にキャプチャして、ニューラルネッ
トベースの判定器APIにかけるバッチ
48
Base64
で入力
キャプチャした画像
(128x128px)
違反度判定器API Slackに通知HLSストリーム 画像の抽出
+ リサイズ(FFmpeg)
Fetch

49. AIによる違反画像判定システムを導入
- AIシステム部と協力して開発（判定器: AIシステム サービス導入: SR）
- Yahooが作成した open-nsfw がベースになっている
• https://github.com/yahoo/open_nsfw
-「疑わしきはアラート」の方針
• ポリシーとして、「人間が見落とすことへのサポートをする」に徹する
• 通知された画像は、人の目によって再度判定され、適切なサービス対処をする
- 現在は精度の検証をしている段階
- 今後、CSの監視フローに組み込んだり、サービスの管理画面に導入する
などしていきたい

50. まとめ

51. 大事なこと
- サービスの特性、システムの特性をチーム全員が理解すること
- サービスを作るのは楽しい
51

52. 関連するトーク
- Casual Talk 16:10-16:20～
• SHOWROOMのイノベーションを加速させるためのマイクロサービスの
取り組み（志水 理哉）
- BLUE Stage 16:30～17:10
• DeNAの大規模ライブ配信基盤を支える技術（漢 祐介）
52

53. SHOWROOMの技術的取り組みについては
- Tech Blog、はじめました
• http://tech.showroom.co.jp/
- まだ始めたばかりで記事数が少ないので、これから充実させて
いきます!
53

54. ありがとうございました！
ブースも見ていってね