SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】
•
9 gefällt mir•30,461 views
本セッションでは、以前のアーキテクチャと比較してどう変わったのか、変える上で重要視したポイントは何か、超低遅延配信の詳細、移行時の失敗談等について触れながら、今回のライブ配信基盤の抜本的なアーキテクチャ刷新の取り組みについてご紹介します。 #livestreaming #HLS #LHLS #RTMP #超低遅延 #AWS #IDCF #Wowza #CDN
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】
Ähnlich wie SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】 (20)
Mehr von DeNA
Mehr von DeNA (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (12)
SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】
- 5. • 星野隼人 • システム本部IT統括部IT基盤部第一グループ エンタメチーム チームリーダー 自己紹介 • 2013年〜 • 大学院卒業後、DeNA 新卒入社 • アジア圏の国内外のサテライト拠点およびデータセンターのネッ トワーク設計・構築・運用 • 2016年〜 • エンターテインメント領域のサービスを中心に、20個以上の サービスのインフラを担当するチームをリード • 全社的なクラウドセキュリティに関する調査・検討・導入
- 6. ▶ 前半パート（DeNAインフラ 星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 7. ▶ 前半パート（DeNAインフラ 星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 9. 配信プロトコル ・RTMP (On-Premisesで受付) 視聴プロトコルと遅延 ・RTMP : 3〜4秒の遅延 ・HLS : 10秒程度の遅延 可用性 ・3秒でフェイルオーバー これまでの構成の特徴 高いスケール性能 ・オリジン ー エッジ構成 ・配信基盤のシャーディング ・数千配信、数百Gbpsにも対応可 アーカイブ ・ffmpeg wrapper デーモンによる アーカイブ生成
- 10. これまでの構成
- 12. 配信・視聴 これからの構成
- 13. 配信プロトコル ・RTMP (クラウドで受付) 視聴プロトコルと遅延 ・通常HLS: 10秒程度 ・超低遅延HLS: 1秒程度 可用性 ・3秒でフェイルオーバー これからの構成の特徴 高いスケール性能 ・オリジン ー エッジ構成 ・配信基盤のシャーディング ・数千配信、数百Gbpsにも対応可 ・Disaster Recoveryを考慮 アーカイブ ・Wowzaプラグインによる録画
- 19. ▶ 前半パート（DeNAインフラ 星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 20. 主な観点 • 可用性 • スケール性能 • コスト • セキュリティ • 事業継続性 Origin Cloud Journey 検討事項
- 21. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △ 採用
- 22. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
- 23. • AWS、GCP等 △ • ゾーン分散可能 • Active/Standby 負荷分散方式はロードバランサ標準機能では 実現不可 • 自前でソフトウェアロードバランサを用意する事で実現可能 • IDCF ◯ • ゾーン分散可能 • Active/Standby 負荷分散方式はマネージドロードバランサを 利用する事で実現可能 • ロードバランサハードウェアアプライアンスをマネージドロー ドバランサとして利用できるサービスがある Origin Cloud Journey 検討事項 - 可用性
- 24. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
- 25. • AWS、GCP等 ◯ • 潤沢なリソース、上限はほぼ気にする必要がないレベル • 豊富なAPI • IDCF △ • インスタンス在庫等はAWSやGCPに比べれば少ない • マネージドロードバランサ(MLB)のスループットが上限となる • インフィニットロードバランサ（ILB）を併用して緩和 • 特定の通信はMLBを通さないルーティングにより緩和 • 物理専有アプライアンスのためMLBのAPI提供が難しい • 代替案についてIDCFさんと検討中 Origin Cloud Journey 検討事項 - スケール性能
- 26. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
- 27. • AWS、GCP等 ☓ • インスタンス • 稼働時間課金 • データ転送 • データ総転送量課金 • IDCF ◎ • インスタンス • 基本、稼働時間課金 • ハードウェア専有機の場合はインスタンス保持時間課金 • データ転送 (クラウドネットワークコネクト※の場合) • データ転送レート課金 • 単価や割引は交渉可能 Origin Cloud Journey 検討事項 - コスト ※IDCFクラウドネットワークコネクト https://www.idcf.jp/cloud/nw_connect/
- 28. Origin Cloud Journey 検討事項 - コスト 月 額 コ ス ト トラフィックパターン
- 29. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
- 30. • AWS、GCP等 ◎ • DeNAの自動監査システムを導入可 • その他大きな懸念はなし • IDCF ◯ • DeNAの自動監査システムを導入不可 • その他大きな懸念はなし Origin Cloud Journey 検討事項 - セキュリティ
- 31. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
- 32. 主にDisaster Recoveryについて • AWS、GCP等 ◯ • どのリージョンでも基本的に同じように利用可能 • IDCF △ • 国内に複数リージョンあるが、どのリージョンでも同じ構成・キャ パシティを確保するためには別途調整が必要 • IDCFの別リージョンで同じ構成を取ることがすぐには困難 • DR先での構成は別途検討する必要がある Origin Cloud Journey 検討事項 - 事業継続性
- 33. ソフトウェアロードバランサによるMLBと同等のActive/Standby負荷 分散方式の検証を行いました • Nginx • Vanilla • ngx_healthcheck_module + ngx_dynamic_upstream_module • OpenResty • LVS + Keepalived • HAProxy Origin Cloud Journey 検討事項 - 事業継続性
- 34. AWS + HAProxy を採用 HAProxyを採用した主な理由 • 機能要件を満たしている • 設定 / 導入が単純 • プロダクトとして成熟している Origin Cloud Journey 検討事項 - 事業継続性 HAProxy Wowza
- 38. ▶ 前半パート（DeNAインフラ 星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 39. Push Publish の失敗
- 40. HLS視聴用 CDN 10秒前後遅延 3〜4秒遅延 + (DR) 廃止 S3 upload HLS files (m3u8, ts) 1秒前後の遅延 Low-Latency HLS視 聴環境
- 41. HLS視聴用 CDN 10秒前後遅延 3〜4秒遅延 + (DR) 廃止 S3 upload HLS files (m3u8, ts) 1秒前後の遅延 Low-Latency HLS視 聴環境 ここも廃止しようとし た
- 42. ダメだった
- 44. これまでの構成から変えたこと • Origin環境のOn-Premisesからの移行先にIDCFを採用 • Recording Daemon廃止 • 必要最小限のコストでのスケール性能確保・DRの実現 • IDCFのMLBとILBを併用 • 特定の通信はMLBを通らないようにルーティング • DR先はAWS • その他 • Wowza version up 前半パートまとめ (1/2)
- 45. これまでの構成から変えていないこと • Originサーバの可用性 • IDCF環境でもDR先環境でもフェイルオーバーは3秒以内 • Shardingによる配信スケールアウト • CDNによる視聴スケールアウト 失敗談 • Push Publish 前半パートまとめ (2/2)
- 46. 前半パート（DeNAインフラ 星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 47. Low-Latency HLS
- 48. 自己紹介 ・Hiroki Koido / 小井戸 寛樹 ・プロダクト本部 プラットフォーム開発G Tech Lead ・動画Playerとライブ配信基盤の両者において 開発全般をTechLeadとしてリード ・経歴 ・06年〜 SIer入社。 ・Mobile向け/スマホ向け動画/音楽Playerアプリを開発 ・11年〜 Web会社に入社 ・ソーシャルwebゲームのサーバー開発Webエンジニアを経験 ・16年〜 サイバーエージェントに入社 ・動画サービスWebサーバーと動画配信基盤の開発を担当 ・19年〜 DeNA / SHOWROOMに入社 ・SHOWROOMのライブ配信基盤のリニューアルプロジェクトの立ち上げ
- 49. 前半パート（DeNAインフラ 星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 52. Streaming-APIにGoを選択した理由 1.1.1 実行速度が速い 1.1.2 並列処理に強い 1.1.3 拡張性(スケーラビリティ)が高い 1.1.4 クロスプラットフォーム対応 1.1.5 消費リソースが少ない
- 53. 参考情報のご紹介 [AWS Black Belt Online Seminar] AWS Media Services で始めるライブ動画配信 Solutions Architect 廣瀬 太郎様 出展 ：https://d1.awsstatic.com/webinars/jp/pdf/services/2019111 2_AWS-LiveVideoStreaming.pdf
- 54. 遅延の内訳
- 55. エンコードのラグを低減する仕組み
- 56. Low-Latency HLSサーバーの仕組み Transcode Group WOWZA Streaming Engine
- 59. 前半パート（DeNAインフラ 星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 62. iOSPlayerのバッファリングロジックの仕組み ・lip sync処理 ・音声プレイヤーにサンプルをBuffering ・Chunked Transfer encodingで取得 ・最新のmpeg2-tsの最新のaudioフレームと タイムスタンプが一致するvideoフレームを ディスプレイに表示 ・audioを基準にして、videoを合わせる理由 ・audio playback以外のtimerにaudioを同期させるのは困難 ・audioのplaybackにはbufferingが必須 ・videoよりもaudioのがstreamが途切れると、目立つ
- 63. 前半パート（DeNAインフラ 星野・20分） • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 64. 失敗談 その１ ・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
- 65. 失敗談 その２ ・ulimit、ip_local_port_range、 net.core.somaxconnを上昇 ・database/sql -> sqlxに変更 ・DBへのconnection poolを使用するよ うに変更 CDN : Akamai CDN : Akamai Wowza Streaming Engine
- 66. 失敗談 その３ ・s3へのコネクションが貼れない。 ・wowzaが瞬間的に停止 ・youngGCのオーバーヘッドがでかく、ア プリケーションが頻繁に停止 ・s3へのtransfer managerを使い回さず、1conecxtず つ、オブジェクト化してキューで制御するように変 更。 ・HeapのEDEN領域を18GBくらいまで下げ、 youngGCのオーバーヘッドを下げた CDN : Akamai CDN : Akamai Wowza Streaming Engine