Download as PDF, PPTX
![参考情報のご紹介
[AWS Black Belt Online Seminar]
AWS Media Services で始めるライブ動画配信
Solutions Architect 廣瀬 太郎様
出展
：https://d1.awsstatic.com/webinars/jp/pdf/services/2019111
2_AWS-LiveVideoStreaming.pdf](https://image.slidesharecdn.com/showroom-200318052159/85/SHOWROOM-DeNA-DeNA-TechCon-2020-53-320.jpg)
Uploaded byDeNA
SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】
本セッションでは、以前のアーキテクチャと比較してどう変わったのか、変える上で重要視したポイントは何か、超低遅延配信の詳細、移行時の失敗談等について触れながら、今回のライブ配信基盤の抜本的なアーキテクチャ刷新の取り組みについてご紹介します。 #livestreaming #HLS #LHLS #RTMP #超低遅延 #AWS #IDCF #Wowza #CDN
More Related Content
Similar to SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】
![[AWS Summit 2012] クラウドデザインパターン#5 CDP バッチ処理編](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-cdp-05-121001104857-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[AWS Summit 2012] クラウドデザインパターン#8 CDP アンチパターン編](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-cdp-08-121001111025-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[AWS Summit 2012] クラウドデザインパターン#7 CDP キャンペーンサイト編 (Wordpress)](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-cdp-07-121002233247-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[AWS Summit 2012] クラウドデザインパターン#2 CDP 画像・動画配信編](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-cdp-02-121001104635-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![タクシーxAIを支えるKubernetesとAIデータパイプラインの信頼性の取り組みについて [SRE NEXT 2020]](https://cdn.slidesharecdn.com/ss_thumbnails/202001srenext-200125032719-thumbnail.jpg?width=640&height=640&fit=bounds)
![ドライブレコーダ映像からの3次元空間認識 [MOBILITY:dev]](https://cdn.slidesharecdn.com/ss_thumbnails/20191031mobilitydevmiyazawa-191031085336-thumbnail.jpg?width=640&height=640&fit=bounds)
![DeNAのQCTマネジメント IaaS利用のベストプラクティス [AWS Summit Tokyo 2019]](https://cdn.slidesharecdn.com/ss_thumbnails/aws-summit-tokyo-2019-kei-190617011042-thumbnail.jpg?width=640&height=640&fit=bounds)
![MOVで実践したサーバーAPI実装の超最適化について [MOBILITY:dev]](https://cdn.slidesharecdn.com/ss_thumbnails/20191031mobilitydevera-191031084650-thumbnail.jpg?width=640&height=640&fit=bounds)
![後部座席タブレットにおけるMaaS時代を見据えた半歩先のUX設計」 [MOBILITY:dev]](https://cdn.slidesharecdn.com/ss_thumbnails/20191031mobilitydevyoneyama-191031085554-thumbnail.jpg?width=640&height=640&fit=bounds)
![課題ドリブン、フルスタックAI開発術 [MOBILITY:dev]](https://cdn.slidesharecdn.com/ss_thumbnails/20191031mobilitydevkuzuoka-191031073741-thumbnail.jpg?width=640&height=640&fit=bounds)
SHOWROOMとDeNAで取り組んだライブ配信基盤刷新・超低遅延ライブ配信の裏側【DeNA TechCon 2020 ライブ配信】
- 1.
- 3.
- 4.
- 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のバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 8.
- 9. 配信プロトコル ・RTMP (On-Premisesで受付) 視聴プロトコルと遅延 ・RTMP : 3〜4秒の遅延 ・HLS: 10秒程度の遅延 可用性 ・3秒でフェイルオーバー これまでの構成の特徴 高いスケール性能 ・オリジン ー エッジ構成 ・配信基盤のシャーディング ・数千配信、数百Gbpsにも対応可 アーカイブ ・ffmpeg wrapper デーモンによる アーカイブ生成
- 10.
- 11.
- 12.
- 13. 配信プロトコル ・RTMP (クラウドで受付) 視聴プロトコルと遅延 ・通常HLS: 10秒程度 ・超低遅延HLS: 1秒程度 可用性 ・3秒でフェイルオーバー これからの構成の特徴 高いスケール性能 ・オリジンー エッジ構成 ・配信基盤のシャーディング ・数千配信、数百Gbpsにも対応可 ・Disaster Recoveryを考慮 アーカイブ ・Wowzaプラグインによる録画
- 14.
- 15.
- 16.
- 17.
- 18.
- 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
- 35.
- 36.
- 37.
- 38. ▶ 前半パート（DeNAインフラ 星野・20分） •これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 39.
- 40. HLS視聴用 CDN 10秒前後遅延 3〜4秒遅延 + (DR) 廃止 S3 upload HLSfiles (m3u8, ts) 1秒前後の遅延 Low-Latency HLS視 聴環境
- 41. HLS視聴用 CDN 10秒前後遅延 3〜4秒遅延 + (DR) 廃止 S3 upload HLSfiles (m3u8, ts) 1秒前後の遅延 Low-Latency HLS視 聴環境 ここも廃止しようとし た
- 42.
- 43.
- 44. これまでの構成から変えたこと • Origin環境のOn-Premisesからの移行先にIDCFを採用 • RecordingDaemon廃止 • 必要最小限のコストでのスケール性能確保・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.
- 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のバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 50.
- 51.
- 52. Streaming-APIにGoを選択した理由 1.1.1 実行速度が速い 1.1.2 並列処理に強い 1.1.3拡張性(スケーラビリティ)が高い 1.1.4 クロスプラットフォーム対応 1.1.5 消費リソースが少ない
- 53. 参考情報のご紹介 [AWS Black BeltOnline 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 WOWZAStreaming Engine
- 57.
- 58.
- 59. 前半パート（DeNAインフラ 星野・20分） •これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート（SHOWROOM 小井戸・20分） • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
- 60.
- 61.
- 62. iOSPlayerのバッファリングロジックの仕組み ・lip sync処理 ・音声プレイヤーにサンプルをBuffering ・Chunked Transferencodingで取得 ・最新の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へのconnectionpoolを使用するよ うに変更 CDN : Akamai CDN : Akamai Wowza Streaming Engine
- 66.
- 67.
- 68.
- 69.
- 70.
- 74.