『SHOWROOM』の大規模化に伴う 技術課題のソリューション ～HTML5対応、演者・視聴者の熱量を支える負荷対策～ SHOWROOM株式会社 池滝 俊太
ノベルティーを用意しました！ 2 マイクロファイバークロス サイリウム
ブースも用意しました！ 3 ゆっくりしていってね
自己紹介 - 池滝 俊太 (26) • SHOWROOM Tech Studio Head - 慶應義塾大学環境情報学部卒業 - 2014年 DeNA新卒入社 - 2014年7月～ エンターテインメント事業本部 • 新規事業の企画・プロトタイプ...
仮想ライブ空間「SHOWROOM」
生放送のみ。演者と視聴者が同じ時間を共有する ことで、高いファンエンゲージメントを生む アイドルやタレント、アーティストとリアルタイ ムで話せて、 ギフティングやコメントで応援が できる 仮想ライブ空間 SHOWROOM 同期性 視聴者の 可視...
本日お話しすること •2013年11月に立ち上げ→サービス開始5年目に突入 - 技術的負債も溜まってくる - 一方、サービスは成長中 •どのようにチームが戦ってきたのか、実例を交えてご紹介 8
目次 •負荷対策事例紹介＜サービスのグロースと起きる問題＞ •PC版のHTML5化＜最新技術への追従＞ •サービス特徴とシステムの特徴 •今後の取り組み •まとめ 9
負荷対策事例紹介 ＜サービスのグロースと起きる問題＞
SHOWROOMのアーキテクチャ 11 •主な登場人物 - [Server] • MySQL, Memcached • Web・Batch・Daemon（全てPerl） • リアルタイムサーバ「bcsvr」（Pub/Sub） •動画配信サーバー...
SHOWROOMの負荷対策 12 再来週からいまの10倍 のトラフィックくるよー •2016年6～8月に大きなイベントがあり、その当時の約10倍のト ラフィックが見込まれた •そこにターゲットを合わせて、大規模な負荷対策を行った
[Server]負荷対策 - 方針 13 •まず何よりもWebを止めない - 非同期化できる処理は非同期化 • 例）ギフティングアクションのPublish処理 - Job QueueにEnqueueし、DequeueするDaemonにて処理 •...
[Server]負荷対策 - 方針 14 •Batch, DaemonにおいてクリティカルとなるのはほぼMySQLへ の重いクエリ - これも1つ1つチューニングしていく、銀の弾丸はなし - 過剰にselectしていたレコードを絞り、必要数ぶん...
[Server]負荷対策 - 方針 15 •動画配信サーバーは、オートスケールが効くようにしてある •事前に大規模配信がわかっている場合、オートスケールにかかる数分の安定 性を確保するため、事前に手動スケールアウトさせておく - ビジネスのメン...
[Server]負荷対策 - 方針 16 •配信サーバーのShardingの様子 •配信ごと（＝ルームごと）に、Shardが割り当てられる
[Client]負荷対策 - 方針 17 •OS/機種や画面の向き/通常配信・VRなどのパターンを網羅的に 検証し、問題を洗い出して潰していく
[Client]負荷対策 - 方針 18 •1ルームに大量の視聴者がいる高負荷状況をシミュレーション •高負荷状況を保ちながら各種ユーザー操作、長時間のスムーズな視聴がで きるかも検証していく - CPU負荷のモニタリング（Android St...
[Client]負荷対策 - 方針 19
高負荷シミュレーション 20 • •下記の動作をするプロセスを多数作成するスクリプト - コメント - ギフティング - テロップ - 支援ゲージ - アバターの並び順更新 •大量のユーザーが大量のアクションをするルームができる •勢いも数パタ...
高負荷シミュレーション 21 •この高負荷シミュレーションの仕組みは、日常的にQAに用いてい る •ルーム内の実装を大幅に変更したときなどの再検証に役に立つ
コメントについて 22 •コメントの総量多すぎた場合、クライアントの負荷を下げるため に間引いている場合もある - 間引くロジックは都度変更している • ギフトやコメント量によって表示の優先順位は高くしている（アバターの 表示順と同じ仕組みなの...
順風満帆 半年～1年ほど経ち、障害いろいろ これらを施し、うまくいった
一定時間Webが応答しない障害 24 •2017年2月、トップコンテンツによる大規模なユーザー流入 •DBの負荷が高まることによって引き起こされた •原因は、イベント機能におけるポイント集計のクエリが重く、他 を引きずってWebが詰まった
Webの改修後、一定の時刻にWebの負荷が高まる 25 •PC版の処理を改修したが、1日ごとに連続で高負荷アラート •該当付近で多くコールされているAPIを調査 •Apache Benchで検証したところ、性能劣化しやすいAPIがあっ た •ネ...
なぜ起きたのか 26 •イベントの盛り上がりにより、関連データ量が著しく増加した •まとまった負荷対策PJ後にも機能改修は継続される - 継続的にやっていくしかない
負荷対策勉強会をやった - 社内ドキュメントだけでなく、しっかりチーム全員で振り返る - クライアントサイドの人にとっても学びがある 27 APIコールをできるだけ減らそう タイミングをずらせるように工夫しよう
PC版のHTML5化 ＜最新技術への追従＞
PC版 29
＿人人人人人人人人人人人＿ ＞　Adobe Flash Player　＜ ‾Y^Y^Y^Y^Y^Y^Y^Y^Y^Y‾
Adobe Flash Player •2013年11月のリリース時からPC版にて使用 - アバター・ギフトなどの複雑なアニメーション - Socket通信によるPub-Subサーバとのやりとり 31 -RTMPプロトコルによる動画配信／視聴
（ところで）動画ストリーミングのプロトコルについて •いくつかあるが、多クライアントに配信するものでは下記の3つが 主流 - RTMP - HLS - MPEG-DASH • HTTPベース 32
HLS, MPEG-DASH 33 •HLS - Apple - HTTPベース（≒リクエスト単位で映像を受信） - 現在広く使われている •MPEG-DASH - ISO標準規格 - HTTPベース - 最近盛り上がってきている
RTMP 34 •Real-Time Message Protocol - リアルタイムに音声や動画などをやりとりするためのストリーミングプロ トコル •Adobe社が開発 •RTMPS／RTMFPなどの変種がある -TCPの上に実装されている...
Adobe Flash Player 35 •2013年11月のリリース時からPC版にて使用 - アバター・ギフトなどの複雑なアニメーション - Socket通信によるPub-Subサーバとのやりとり • コメント・ギフトの通知、ストリーミング...
アバター・ギフトの描画 36 •PixiJSを用いている - “the fastest, most flexible 2D WebGL renderer. http://www.pixijs.com/ - チューニングを行った結 果、パフォーマン...
Pub/Subサーバとのやりとり 37 •コメントやギフトのリアルタイムPub/Subの機能にはbcsvrとい うプロダクトを使っている - DeNA製のプロダクト。TCPの上で、テキストベースのプロトコ ルでPub/Subを実現する •bcs...
Javascript動画プレーヤーの実装 • をつかって実装 •https://github.com/video-dev/hls.js •JavaScript HLS client using Media Source Extension 38
が、問題もある •遅延が短くなりきらない問題 - クライアント（hls.jsのチューニング）／配信サーバー • バッファリングの最適化 • チャンクの最適化 - チャンク: 細切れになった映像データ - 現在開発・検証中です 39
サービスの特徴、システムの特徴
サービスの特徴 •視聴者・演者のエンゲージメントが高い - 単位時間にかける熱量が高い •企業ミッション「努力がフェア(公正)に報われる社会を創る」 - 一時的にサービスがダウンしたとしても、ある演者、視聴者に とっては致命的かもしれない 41
サービスの特徴からシステムの特徴が見えてくる •何よりも動画の視聴が大事、演者と視聴者のエンゲージメントを 保つ •さらに、映像、コメントなどを遅延させないことが大事 - インタラクティブ性が落ちることで、エンゲージメントが落ち てしまう - ...
サービスの特徴からシステムの特徴が見えてくる •演者と視聴者のエンゲージメントを最大化する、システム上の「思 いやり」を大事にしたい - 負荷対策をしっかりし、できるだけサービスを落とさない • とはいえ、落ちるものは落ちる • そうなったら、...
溜まっていく技術的負債 •データ量増加によるクエリチューニングの問題 •技術のレガシー化 44
でもサービスは成長 •技術的負債の対策をしながらユーザー体験を向上させる - けど着実に視聴者・演者のエンゲージメントを支えたい - コードの歴史に敬意をこめて、更新していく •まだまだシステムの安定性、機能による価値も増したい - 新技術、新...
おまけ: AI監視について
スケールにおける問題: コンテンツの監視 - UGC（User Generated Contents）を生むサービスにおいて は、配信・投稿されたコンテンツがポリシー違反していないか の監視が重要 - SHOWROOMではリアルタイムで監視すべ...
AIによる違反画像判定システムを導入 - 画像の違反度判定 - ライブ中の全動画を定期的にキャプチャして、ニューラルネッ トベースの判定器APIにかけるバッチ 48 Base64 で入力 キャプチャした画像 (128x128px) 違反度判定器...
AIによる違反画像判定システムを導入 - AIシステム部と協力して開発（判定器: AIシステム サービス導入: SR） - Yahooが作成した open-nsfw がベースになっている • https://github.com/yahoo/o...
まとめ
大事なこと - サービスの特性、システムの特性をチーム全員が理解すること - サービスを作るのは楽しい 51
関連するトーク - Casual Talk 16:10-16:20～ • SHOWROOMのイノベーションを加速させるためのマイクロサービスの 取り組み（志水 理哉） - BLUE Stage 16:30～17:10 • DeNAの大規模ライブ...
SHOWROOMの技術的取り組みについては - Tech Blog、はじめました • http://tech.showroom.co.jp/ - まだ始めたばかりで記事数が少ないので、これから充実させて いきます! 53
ありがとうございました！ ブースも見ていってね
『SHOWROOM』の大規模化に伴う技術課題のソリューション ～演者・視聴者の熱量を支える負荷対策、HTML5対応など～

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

3,746 views

Published on

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

Published in: Technology
no profile picture user

  • Login to see the comments

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

  1. 1. 『SHOWROOM』の大規模化に伴う 技術課題のソリューション ～HTML5対応、演者・視聴者の熱量を支える負荷対策～ SHOWROOM株式会社 池滝 俊太
  2. 2. ノベルティーを用意しました！ 2 マイクロファイバークロス サイリウム
  3. 3. ブースも用意しました！ 3 ゆっくりしていってね
  4. 4. 自己紹介 - 池滝 俊太 (26) • SHOWROOM Tech Studio Head - 慶應義塾大学環境情報学部卒業 - 2014年 DeNA新卒入社 - 2014年7月～ エンターテインメント事業本部 • 新規事業の企画・プロトタイプ開発に携わる - 2015年2月～ SHOWROOMに異動 & 8月子会社化 • Androidアプリ、サーバーサイドのリーダーを経て、現在はサービス開 発の部署 SHOWROOM Tech Studio のマネジメントを行っている。 - コンピュータと音楽とエンターテインメントが好き。 4 @Iketaki
  5. 5. 仮想ライブ空間「SHOWROOM」
  6. 6. 生放送のみ。演者と視聴者が同じ時間を共有する ことで、高いファンエンゲージメントを生む アイドルやタレント、アーティストとリアルタイ ムで話せて、 ギフティングやコメントで応援が できる 仮想ライブ空間 SHOWROOM 同期性 視聴者の 可視化 ストーリー 創出 視聴者の姿や名前、アクションを可視化して、ユー ザーのエンゲージメント向上を支える イベントがリアルドラマを生み、ファンの感情移 入を促す
  7. 7. 本日お話しすること •2013年11月に立ち上げ→サービス開始5年目に突入 - 技術的負債も溜まってくる - 一方、サービスは成長中 •どのようにチームが戦ってきたのか、実例を交えてご紹介 8
  8. 8. 目次 •負荷対策事例紹介＜サービスのグロースと起きる問題＞ •PC版のHTML5化＜最新技術への追従＞ •サービス特徴とシステムの特徴 •今後の取り組み •まとめ 9
  9. 9. 負荷対策事例紹介 ＜サービスのグロースと起きる問題＞
  10. 10. SHOWROOMのアーキテクチャ 11 •主な登場人物 - [Server] • MySQL, Memcached • Web・Batch・Daemon（全てPerl） • リアルタイムサーバ「bcsvr」（Pub/Sub） •動画配信サーバー Wowza（Origin/Edge構成） - [Client] • iOSアプリ・Andoirdアプリ・PC版Webクライアント
  11. 11. SHOWROOMの負荷対策 12 再来週からいまの10倍 のトラフィックくるよー •2016年6～8月に大きなイベントがあり、その当時の約10倍のト ラフィックが見込まれた •そこにターゲットを合わせて、大規模な負荷対策を行った
  12. 12. [Server]負荷対策 - 方針 13 •まず何よりもWebを止めない - 非同期化できる処理は非同期化 • 例）ギフティングアクションのPublish処理 - Job QueueにEnqueueし、DequeueするDaemonにて処理 • QueueにはQ4Mを利用 •APIチューニング - アクセス数の多い順に1つ1つチューニング - Apache Benchを使う
  13. 13. [Server]負荷対策 - 方針 14 •Batch, DaemonにおいてクリティカルとなるのはほぼMySQLへ の重いクエリ - これも1つ1つチューニングしていく、銀の弾丸はなし - 過剰にselectしていたレコードを絞り、必要数ぶんレコードを 取る - Order by, 絞り込みをMySQL側でせず、アプリサーバ側で行う - インデックス
  14. 14. [Server]負荷対策 - 方針 15 •動画配信サーバーは、オートスケールが効くようにしてある •事前に大規模配信がわかっている場合、オートスケールにかかる数分の安定 性を確保するため、事前に手動スケールアウトさせておく - ビジネスのメンバーを通して依頼がくる、トップコンテンツの場合が多い - 依頼を受け、Slackを用いたChatOpsでスケールアウトできるようにしてあ る - Twitterで反応の大きさを見る •それでも多い場合は、CDNに流せるようにもしてある - 遅延が少し大きくなるので、トレードオフ
  15. 15. [Server]負荷対策 - 方針 16 •配信サーバーのShardingの様子 •配信ごと（＝ルームごと）に、Shardが割り当てられる
  16. 16. [Client]負荷対策 - 方針 17 •OS/機種や画面の向き/通常配信・VRなどのパターンを網羅的に 検証し、問題を洗い出して潰していく
  17. 17. [Client]負荷対策 - 方針 18 •1ルームに大量の視聴者がいる高負荷状況をシミュレーション •高負荷状況を保ちながら各種ユーザー操作、長時間のスムーズな視聴がで きるかも検証していく - CPU負荷のモニタリング（Android Studio, Xcode） • ギフト、コメントの通知が多すぎてさばききれない、など - GPU負荷のモニタリング（Xcode） • SHOWROOMでは大量のアバター・ギフトの描画をOpenGLレイヤーで行ってい る - 動画を再生し続け、止まったりカクついたりしないことを検証
  18. 18. [Client]負荷対策 - 方針 19
  19. 19. 高負荷シミュレーション 20 • •下記の動作をするプロセスを多数作成するスクリプト - コメント - ギフティング - テロップ - 支援ゲージ - アバターの並び順更新 •大量のユーザーが大量のアクションをするルームができる •勢いも数パターン用意する - 徐々に or 突発的 $ srsys_perl live_load_test.pl [ROOM_ID] コメント ギフト ギフト コメント 支援ゲージ アバターの並び順 テロップ
  20. 20. 高負荷シミュレーション 21 •この高負荷シミュレーションの仕組みは、日常的にQAに用いてい る •ルーム内の実装を大幅に変更したときなどの再検証に役に立つ
  21. 21. コメントについて 22 •コメントの総量多すぎた場合、クライアントの負荷を下げるため に間引いている場合もある - 間引くロジックは都度変更している • ギフトやコメント量によって表示の優先順位は高くしている（アバターの 表示順と同じ仕組みなので、アバターからコメントが吹き出しで見えるよ うに）
  22. 22. 順風満帆 半年～1年ほど経ち、障害いろいろ これらを施し、うまくいった
  23. 23. 一定時間Webが応答しない障害 24 •2017年2月、トップコンテンツによる大規模なユーザー流入 •DBの負荷が高まることによって引き起こされた •原因は、イベント機能におけるポイント集計のクエリが重く、他 を引きずってWebが詰まった
  24. 24. Webの改修後、一定の時刻にWebの負荷が高まる 25 •PC版の処理を改修したが、1日ごとに連続で高負荷アラート •該当付近で多くコールされているAPIを調査 •Apache Benchで検証したところ、性能劣化しやすいAPIがあっ た •ネガティブキャッシュが効いておらず、毎回DBアクセスをしてい る箇所が - ネガティブキャッシュ…DBにデータが存在しないことをキャッ シュするしくみ
  25. 25. なぜ起きたのか 26 •イベントの盛り上がりにより、関連データ量が著しく増加した •まとまった負荷対策PJ後にも機能改修は継続される - 継続的にやっていくしかない
  26. 26. 負荷対策勉強会をやった - 社内ドキュメントだけでなく、しっかりチーム全員で振り返る - クライアントサイドの人にとっても学びがある 27 APIコールをできるだけ減らそう タイミングをずらせるように工夫しよう
  27. 27. PC版のHTML5化 ＜最新技術への追従＞
  28. 28. PC版 29
  29. 29. ＿人人人人人人人人人人人＿ ＞　Adobe Flash Player　＜ ‾Y^Y^Y^Y^Y^Y^Y^Y^Y^Y‾
  30. 30. Adobe Flash Player •2013年11月のリリース時からPC版にて使用 - アバター・ギフトなどの複雑なアニメーション - Socket通信によるPub-Subサーバとのやりとり 31 -RTMPプロトコルによる動画配信／視聴
  31. 31. （ところで）動画ストリーミングのプロトコルについて •いくつかあるが、多クライアントに配信するものでは下記の3つが 主流 - RTMP - HLS - MPEG-DASH • HTTPベース 32
  32. 32. HLS, MPEG-DASH 33 •HLS - Apple - HTTPベース（≒リクエスト単位で映像を受信） - 現在広く使われている •MPEG-DASH - ISO標準規格 - HTTPベース - 最近盛り上がってきている
  33. 33. RTMP 34 •Real-Time Message Protocol - リアルタイムに音声や動画などをやりとりするためのストリーミングプロ トコル •Adobe社が開発 •RTMPS／RTMFPなどの変種がある -TCPの上に実装されている -遅延が少ない •Flash Playerでカメラ・マイクを扱うことで、ブラウザ上で配信側もできる
  34. 34. Adobe Flash Player 35 •2013年11月のリリース時からPC版にて使用 - アバター・ギフトなどの複雑なアニメーション - Socket通信によるPub-Subサーバとのやりとり • コメント・ギフトの通知、ストリーミングURLの変更通知な ど、様々な用途に利用 • RTMPプロトコルによる動画配信／視聴 •良いソリューションではあったものの、Web標準の流れ、 セキュリティ的な懸念もあるので、HTML5に移行を行う
  35. 35. アバター・ギフトの描画 36 •PixiJSを用いている - “the fastest, most flexible 2D WebGL renderer. http://www.pixijs.com/ - チューニングを行った結 果、パフォーマンスを出し つつも、よりなめらかなア ニメーションも実現できた
  36. 36. Pub/Subサーバとのやりとり 37 •コメントやギフトのリアルタイムPub/Subの機能にはbcsvrとい うプロダクトを使っている - DeNA製のプロダクト。TCPの上で、テキストベースのプロトコ ルでPub/Subを実現する •bcsvrは、生のTCPの他にWebSocketをしゃべることができるの で、WebSocketで実装して解決
  37. 37. Javascript動画プレーヤーの実装 • をつかって実装 •https://github.com/video-dev/hls.js •JavaScript HLS client using Media Source Extension 38
  38. 38. が、問題もある •遅延が短くなりきらない問題 - クライアント（hls.jsのチューニング）／配信サーバー • バッファリングの最適化 • チャンクの最適化 - チャンク: 細切れになった映像データ - 現在開発・検証中です 39
  39. 39. サービスの特徴、システムの特徴
  40. 40. サービスの特徴 •視聴者・演者のエンゲージメントが高い - 単位時間にかける熱量が高い •企業ミッション「努力がフェア(公正)に報われる社会を創る」 - 一時的にサービスがダウンしたとしても、ある演者、視聴者に とっては致命的かもしれない 41
  41. 41. サービスの特徴からシステムの特徴が見えてくる •何よりも動画の視聴が大事、演者と視聴者のエンゲージメントを 保つ •さらに、映像、コメントなどを遅延させないことが大事 - インタラクティブ性が落ちることで、エンゲージメントが落ち てしまう - 映像カクつくだけで、意識が演者からシステムの方に向いてし まう •配信者きっかけで急に負荷が増大する 42
  42. 42. サービスの特徴からシステムの特徴が見えてくる •演者と視聴者のエンゲージメントを最大化する、システム上の「思 いやり」を大事にしたい - 負荷対策をしっかりし、できるだけサービスを落とさない • とはいえ、落ちるものは落ちる • そうなったら、エンゲージメントを壊さないところから潰していく - 映像は守りたい - RTMP→HLS移行における遅延の問題 43
  43. 43. 溜まっていく技術的負債 •データ量増加によるクエリチューニングの問題 •技術のレガシー化 44
  44. 44. でもサービスは成長 •技術的負債の対策をしながらユーザー体験を向上させる - けど着実に視聴者・演者のエンゲージメントを支えたい - コードの歴史に敬意をこめて、更新していく •まだまだシステムの安定性、機能による価値も増したい - 新技術、新アーキテクチャによる機能も鋭意開発中 - 力強いプロダクトマネジメント 45
  45. 45. おまけ: AI監視について
  46. 46. スケールにおける問題: コンテンツの監視 - UGC（User Generated Contents）を生むサービスにおいて は、配信・投稿されたコンテンツがポリシー違反していないか の監視が重要 - SHOWROOMではリアルタイムで監視すべきものが多い • 【配信者】配信動画の内容 • 【視聴者】リアルタイムコメント など - 特に配信数が増え、配信動画内容の監視工数問題が深刻に • CSが24時間365日監視しているため 47
  47. 47. AIによる違反画像判定システムを導入 - 画像の違反度判定 - ライブ中の全動画を定期的にキャプチャして、ニューラルネッ トベースの判定器APIにかけるバッチ 48 Base64 で入力 キャプチャした画像 (128x128px) 違反度判定器API Slackに通知HLSストリーム 画像の抽出 + リサイズ(FFmpeg) Fetch
  48. 48. AIによる違反画像判定システムを導入 - AIシステム部と協力して開発（判定器: AIシステム サービス導入: SR） - Yahooが作成した open-nsfw がベースになっている • https://github.com/yahoo/open_nsfw -「疑わしきはアラート」の方針 • ポリシーとして、「人間が見落とすことへのサポートをする」に徹する • 通知された画像は、人の目によって再度判定され、適切なサービス対処をする - 現在は精度の検証をしている段階 - 今後、CSの監視フローに組み込んだり、サービスの管理画面に導入する などしていきたい
  49. 49. まとめ
  50. 50. 大事なこと - サービスの特性、システムの特性をチーム全員が理解すること - サービスを作るのは楽しい 51
  51. 51. 関連するトーク - Casual Talk 16:10-16:20～ • SHOWROOMのイノベーションを加速させるためのマイクロサービスの 取り組み（志水 理哉） - BLUE Stage 16:30～17:10 • DeNAの大規模ライブ配信基盤を支える技術（漢 祐介） 52
  52. 52. SHOWROOMの技術的取り組みについては - Tech Blog、はじめました • http://tech.showroom.co.jp/ - まだ始めたばかりで記事数が少ないので、これから充実させて いきます! 53
  53. 53. ありがとうございました！ ブースも見ていってね
Save this presentation