SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】

1. SHOWROOMとDeNAで取り組んだ  ライブ配信基盤刷新・  超低遅延ライブ配信の裏側星野隼人　　小井戸寛樹

2. 低遅延な配信へのこだわり

3. 超低遅延のデモ動画超低遅延 1秒未満の遅延これまでの遅延 10秒程度

4. • 星野隼人 • システム本部IT統括部IT基盤部第一グループエンタメチームチームリーダー自己紹介 • 2013年〜 • 大学院卒業後、DeNA 新卒入社 • アジア圏の国内外のサテライト拠点およびデータセンターのネットワーク設計・構築・運用 • 2016年〜 • エンターテインメント領域のサービスを中心に、20個以上のサービスのインフラを担当するチームをリード • 全社的なクラウドセキュリティに関する調査・検討・導入

5. ▶ 前半パート（DeNAインフラ星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談　後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談本セッションの構成

7. 配信・視聴これまでの構成

8. 配信プロトコル・RTMP　(On-Premisesで受付) 視聴プロトコルと遅延・RTMP : 3〜4秒の遅延・HLS : 10秒程度の遅延可用性・3秒でフェイルオーバーこれまでの構成の特徴高いスケール性能・オリジンーエッジ構成・配信基盤のシャーディング・数千配信、数百Gbpsにも対応可アーカイブ・ffmpeg wrapper デーモンによるアーカイブ生成

9. これまでの構成

10. これまでの構成 Origin  RTMP視聴用 Edge  HLS視聴用  CDN  Origin  Cache  10秒前後遅延  3〜4秒遅延  Recording 

11. 配信・視聴これからの構成

12. 配信プロトコル・RTMP　(クラウドで受付) 視聴プロトコルと遅延・通常HLS: 10秒程度・超低遅延HLS: 1秒程度可用性・3秒でフェイルオーバーこれからの構成の特徴高いスケール性能・オリジンーエッジ構成・配信基盤のシャーディング・数千配信、数百Gbpsにも対応可・Disaster Recoveryを考慮アーカイブ・Wowzaプラグインによる録画

13. これからの構成 Origin  RTMP視聴用 Edge  HLS視聴用  CDN  Origin  Cache  10秒前後遅延  3〜4秒遅延  Recording 

14. これからの構成 Origin  HLS視聴用  CDN  Origin  Cache  10秒前後遅延  3〜4秒遅延  Recording  1秒前後の遅延 Low-Latency HLS視聴環境 

15. これからの構成 Origin  HLS視聴用  CDN  Origin  Cache  10秒前後遅延  3〜4秒遅延  Recording  1秒前後の遅延 Low-Latency HLS視聴環境  Public  Cloud  Origin 

16. これからの構成 Origin  HLS視聴用  CDN  Origin  Cache  10秒前後遅延  3〜4秒遅延  Recording  1秒前後の遅延 Low-Latency HLS視聴環境  Public  Cloud  Origin  Cloud Journey

17. Origin Cloud Journey

19. 主な観点 • 可用性 • スケール性能 • コスト • セキュリティ • 事業継続性 Origin Cloud Journey 検討事項

20. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △ 採用

21. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △

22. • AWS、GCP等 △ • ゾーン分散可能 • Active/Standby 負荷分散方式はロードバランサ標準機能では実現不可 • 自前でソフトウェアロードバランサを用意する事で実現可能 • IDCF ◯ • ゾーン分散可能 • Active/Standby 負荷分散方式はマネージドロードバランサを利用する事で実現可能 • ロードバランサハードウェアアプライアンスをマネージドロードバランサとして利用できるサービスがある Origin Cloud Journey 検討事項 - 可用性

24. • AWS、GCP等 ◯ • 潤沢なリソース、上限はほぼ気にする必要がないレベル • 豊富なAPI • IDCF △ • インスタンス在庫等はAWSやGCPに比べれば少ない • マネージドロードバランサ(MLB)のスループットが上限となる • インフィニットロードバランサ（ILB）を併用して緩和 • 特定の通信はMLBを通さないルーティングにより緩和 • 物理専有アプライアンスのためMLBのAPI提供が難しい • 代替案についてIDCFさんと検討中 Origin Cloud Journey 検討事項 - スケール性能

26. • AWS、GCP等 ☓ • インスタンス • 稼働時間課金 • データ転送 • データ総転送量課金 • IDCF ◎ • インスタンス • 基本、稼働時間課金 • ハードウェア専有機の場合はインスタンス保持時間課金 • データ転送 (クラウドネットワークコネクト※の場合) • データ転送レート課金 • 単価や割引は交渉可能 Origin Cloud Journey 検討事項 - コスト ※IDCFクラウドネットワークコネクト　https://www.idcf.jp/cloud/nw_connect/

27. Origin Cloud Journey 検討事項 - コスト月額コストトラフィックパターン

29. • AWS、GCP等 ◎ • DeNAの自動監査システムを導入可 • その他大きな懸念はなし • IDCF ◯ • DeNAの自動監査システムを導入不可 • その他大きな懸念はなし Origin Cloud Journey 検討事項 - セキュリティ

31. 主にDisaster Recoveryについて • AWS、GCP等 ◯ • どのリージョンでも基本的に同じように利用可能 • IDCF △ • 国内に複数リージョンあるが、どのリージョンでも同じ構成・キャパシティを確保するためには別途調整が必要 • IDCFの別リージョンで同じ構成を取ることがすぐには困難 • DR先での構成は別途検討する必要がある Origin Cloud Journey 検討事項 - 事業継続性

32. ソフトウェアロードバランサによるMLBと同等のActive/Standby負荷分散方式の検証を行いました • Nginx • Vanilla • ngx_healthcheck_module + ngx_dynamic_upstream_module • OpenResty • LVS + Keepalived • HAProxy Origin Cloud Journey 検討事項 - 事業継続性

33. AWS + HAProxy を採用 HAProxyを採用した主な理由 • 機能要件を満たしている • 設定 / 導入が単純 • プロダクトとして成熟している Origin Cloud Journey 検討事項 - 事業継続性 HAProxy Wowza

34. Origin Cloud Journey の話の整理

35. HLS視聴用  CDN  10秒前後遅延  3〜4秒遅延  1秒前後の遅延 Low-Latency HLS視聴環境  + (DR)

36. HLS視聴用  CDN  10秒前後遅延  3〜4秒遅延  1秒前後の遅延 Low-Latency HLS視聴環境  + (DR) 廃止 MLB ILB

38. Push Publish の失敗

39. HLS視聴用  CDN  10秒前後遅延  3〜4秒遅延  + (DR) 廃止 S3 upload HLS ﬁles (m3u8, ts) 1秒前後の遅延 Low-Latency HLS視聴環境 

40. HLS視聴用  CDN  10秒前後遅延  3〜4秒遅延  + (DR) 廃止 S3 upload HLS ﬁles (m3u8, ts) 1秒前後の遅延 Low-Latency HLS視聴環境  ここも廃止しようとした

41. ダメだった

42. HLS視聴用  CDN  10秒前後遅延  3〜4秒遅延  + (DR) 廃止 1秒前後の遅延 Low-Latency HLS視聴環境 

43. これまでの構成から変えたこと • Origin環境のOn-Premisesからの移行先にIDCFを採用 • Recording Daemon廃止 • 必要最小限のコストでのスケール性能確保・DRの実現 • IDCFのMLBとILBを併用 • 特定の通信はMLBを通らないようにルーティング • DR先はAWS • その他 • Wowza version up 前半パートまとめ (1/2)

44. これまでの構成から変えていないこと • Originサーバの可用性 • IDCF環境でもDR先環境でもフェイルオーバーは3秒以内 • Shardingによる配信スケールアウト • CDNによる視聴スケールアウト失敗談 • Push Publish 前半パートまとめ (2/2)

45. 　前半パート（DeNAインフラ星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談本セッションの構成

46. Low-Latency HLS

47. 自己紹介  ・Hiroki Koido / 小井戸寛樹    ・プロダクト本部プラットフォーム開発G Tech Lead  　・動画Playerとライブ配信基盤の両者において  　　開発全般をTechLeadとしてリード    ・経歴  　・06年〜 SIer入社。  　　・Mobile向け/スマホ向け動画/音楽Playerアプリを開発  　・11年〜 Web会社に入社  　　・ソーシャルwebゲームのサーバー開発Webエンジニアを経験  　・16年〜サイバーエージェントに入社  　　・動画サービスWebサーバーと動画配信基盤の開発を担当  　・19年〜 DeNA / SHOWROOMに入社  　　・SHOWROOMのライブ配信基盤のリニューアルプロジェクトの立ち上げ 

49. アーキテクチャ  CDN : Akamai CDN : Akamai Wowza Streaming Engine

50. アーキテクチャ  Low-Latency HLS環境 Wowza Streaming Engine CDN : Akamai CDN : Akamai

51. Streaming-APIにGoを選択した理由 1.1.1 実行速度が速い 1.1.2 並列処理に強い 1.1.3 拡張性(スケーラビリティ)が高い 1.1.4 クロスプラットフォーム対応 1.1.5 消費リソースが少ない

52. 参考情報のご紹介  [AWS Black Belt Online Seminar]  AWS Media Services で始めるライブ動画配信    Solutions Architect 廣瀬太郎様  出展：https://d1.awsstatic.com/webinars/jp/pdf/services/2019111 2_AWS-LiveVideoStreaming.pdf

53. 遅延の内訳 

54. エンコードのラグを低減する仕組み 

55. Low-Latency HLSサーバーの仕組み  Transcode Group WOWZA Streaming Engine

56. Low-Latency HLSサーバーの仕組み  #EXTM3U #EXT-X-VERSION:6 #EXT-X-MEDIA-SEQUENCE:30193 #EXT-X-TARGETDURATION:3 #EXT-SR-LHLS #EXTINF:2.002, /media/v30193.ts #EXTINF:2.002, /media/v30194.ts #EXTINF:2.002, /media/v30195.ts #EXTINF:2.002, /media/v30196.ts #EXTINF:2.002, /media/v30197.ts ・mpeg2-tsのpayloadのchunkを16KB ずつに分割・transfer encoding : chunkedを使って、分割したチャンクを送信

57. Low-Latency HLSサーバーのfailoverの仕組み  failoverまで：２〜３秒

59. Playerのバッファリングロジックの仕組み 

60. Playerのバッファリングロジックの仕組み 

61. iOSPlayerのバッファリングロジックの仕組み  ・lip sync処理・音声プレイヤーにサンプルをBuffering ・Chunked Transfer encodingで取得・最新のmpeg2-tsの最新のaudioフレームと　タイムスタンプが一致するvideoフレームを　ディスプレイに表示・audioを基準にして、videoを合わせる理由　・audio playback以外のtimerにaudioを同期させるのは困難　・audioのplaybackにはbufferingが必須　・videoよりもaudioのがstreamが途切れると、目立つ

63. 失敗談　その１  ・worker_rlimit_nofile (nginxのulimit) = 65535 (too many open filesにかからないようにする) ・worker_connection = 8192 (nginxへの同時接続数を増やすため、限界まで増加) ・multi_accept on (リクエストを並列で同時に処理するようにする) ・nginxのmax connectionを1台：100,000同時接続可能 Wowza Streaming Engine CDN : Akamai CDN : Akamai

64. 失敗談　その２  ・ulimit、ip_local_port_range、 net.core.somaxconnを上昇  ・database/sql -> sqlxに変更  ・DBへのconnection poolを使用するように変更  CDN : Akamai CDN : Akamai Wowza Streaming Engine

65. 失敗談　その３  ・s3へのコネクションが貼れない。  ・wowzaが瞬間的に停止  ・youngGCのオーバーヘッドがでかく、アプリケーションが頻繁に停止  ・s3へのtransfer managerを使い回さず、1conecxtずつ、オブジェクト化してキューで制御するように変更。  ・HeapのEDEN領域を18GBくらいまで下げ、 youngGCのオーバーヘッドを下げた  CDN : Akamai CDN : Akamai Wowza Streaming Engine

66. 失敗談　その4  ・大量のGCが発生  ・wowzaが瞬間的に停止  ・master playlistが生成されず  streamが再生不可  Wowza Streaming Engine CDN : Akamai CDN : Akamai

67. 失敗談　その4  ・s3を参照せずに、ライブはoriginを向ける  ・前段にwebのキャッシュサーバーを配置 Wowza Streaming Engine CDN : Akamai CDN : Akamai

68. 現在の開発状況  ・開発は、完了済み。・現在、システム安定化のために最終調整中。・影響を極小にするため、ゆっくり導入中。・近日中に、リリース完了予定！

69. 今後のSHOWROOM株式会社の事業戦略・SHOWROOM ・新機能の導入で、絶賛ライブ配信盛り上げ中。・新プロダクト・新動画メディア開発で縦型動画の新たな世界を開拓・新音声メディア開発で耳で聴ける新たな世界を開拓・SHOWSTAGE ・超現実ライブをはじめ、ライブ3.0の新世界を開発既存のSHOWROOMを活性化し、新たなシナジー効果を生み出すプロダクトを開発中。

70. 今後のDeNAとSHOWROOM 今後も "エンターテインメント×テクノロジー" を本気で追求し、世界に喜びと驚きを与えられるようにチャレンジしていきます。 

SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】

You are reading a preview.

Check these out next

SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】

More Related Content

Slideshows for you (20)

Similar to SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】 (20)

More from DeNA (20)

Recently uploaded (20)