Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
SHOWROOMとDeNAで取り組んだ

ライブ配信基盤刷新・

超低遅延ライブ配信の裏側
星野隼人  小井戸寛樹
低遅延な配信への
こだわり
超低遅延のデモ動画
超低遅延
1秒未満の遅延
これまでの遅延
10秒程度
• 星野隼人
• システム本部IT統括部IT基盤部第一グループ
エンタメチーム チームリーダー
自己紹介
• 2013年〜
• 大学院卒業後、DeNA 新卒入社
• アジア圏の国内外のサテライト拠点およびデータセンターのネッ
トワーク設計・構築...
▶ 前半パート(DeNAインフラ 星野・20分)
• これまでの構成とこれからの構成の解説
• Origin Cloud Journey検討ポイントの解説
• 失敗談
 後半パート(SHOWROOM 小井戸・20分)
• Low-Latency...
▶ 前半パート(DeNAインフラ 星野・20分)
• これまでの構成とこれからの構成の解説
• Origin Cloud Journey検討ポイントの解説
• 失敗談
 後半パート(SHOWROOM 小井戸・20分)
• Low-Latency...
配信・視聴
これまでの構成
配信プロトコル
・RTMP (On-Premisesで受付)
視聴プロトコルと遅延
・RTMP : 3〜4秒の遅延
・HLS : 10秒程度の遅延
可用性
・3秒でフェイルオーバー
これまでの構成の特徴
高いスケール性能
・オリジン ー エッジ...
これまでの構成
これまでの構成
Origin

RTMP視聴用
Edge

HLS視聴用

CDN

Origin

Cache

10秒前後遅延

3〜4秒遅延

Recording

配信・視聴
これからの構成
配信プロトコル
・RTMP (クラウドで受付)
視聴プロトコルと遅延
・通常HLS: 10秒程度
・超低遅延HLS: 1秒程度
可用性
・3秒でフェイルオーバー
これからの構成の特徴
高いスケール性能
・オリジン ー エッジ構成
・配信基盤のシ...
これからの構成
Origin

RTMP視聴用
Edge

HLS視聴用

CDN

Origin

Cache

10秒前後遅延

3〜4秒遅延

Recording

これからの構成
Origin

HLS視聴用

CDN

Origin

Cache

10秒前後遅延

3〜4秒遅延

Recording

1秒前後の遅延
Low-Latency HLS視
聴環境

これからの構成
Origin

HLS視聴用

CDN

Origin

Cache

10秒前後遅延

3〜4秒遅延

Recording

1秒前後の遅延
Low-Latency HLS視
聴環境

Public

Cloud

Origi...
これからの構成
Origin

HLS視聴用

CDN

Origin

Cache

10秒前後遅延

3〜4秒遅延

Recording

1秒前後の遅延
Low-Latency HLS視
聴環境

Public

Cloud

Origi...
Origin
Cloud Journey
▶ 前半パート(DeNAインフラ 星野・20分)
• これまでの構成とこれからの構成の解説
• Origin Cloud Journey検討ポイントの解説
• 失敗談
 後半パート(SHOWROOM 小井戸・20分)
• Low-Latency...
主な観点
• 可用性
• スケール性能
• コスト
• セキュリティ
• 事業継続性
Origin Cloud Journey 検討事項
Origin Cloud Journey 検討事項 - 結果
AWSやGCP IDCF
可用性 △ ◯
スケール性能 ◯ △
コスト ☓ ◎
セキュリティ ◎ ◯
事業継続性 ◯ △
採用
Origin Cloud Journey 検討事項 - 結果
AWSやGCP IDCF
可用性 △ ◯
スケール性能 ◯ △
コスト ☓ ◎
セキュリティ ◎ ◯
事業継続性 ◯ △
• AWS、GCP等 △
• ゾーン分散可能
• Active/Standby 負荷分散方式はロードバランサ標準機能では
実現不可
• 自前でソフトウェアロードバランサを用意する事で実現可能
• IDCF ◯
• ゾーン分散可能
• Activ...
Origin Cloud Journey 検討事項 - 結果
AWSやGCP IDCF
可用性 △ ◯
スケール性能 ◯ △
コスト ☓ ◎
セキュリティ ◎ ◯
事業継続性 ◯ △
• AWS、GCP等 ◯
• 潤沢なリソース、上限はほぼ気にする必要がないレベル
• 豊富なAPI
• IDCF △
• インスタンス在庫等はAWSやGCPに比べれば少ない
• マネージドロードバランサ(MLB)のスループットが上限となる
• ...
Origin Cloud Journey 検討事項 - 結果
AWSやGCP IDCF
可用性 △ ◯
スケール性能 ◯ △
コスト ☓ ◎
セキュリティ ◎ ◯
事業継続性 ◯ △
• AWS、GCP等 ☓
• インスタンス
• 稼働時間課金
• データ転送
• データ総転送量課金
• IDCF ◎
• インスタンス
• 基本、稼働時間課金
• ハードウェア専有機の場合はインスタンス保持時間課金
• データ転送 (クラウド...
Origin Cloud Journey 検討事項 - コスト
月
額
コ
ス
ト
トラフィックパターン
Origin Cloud Journey 検討事項 - 結果
AWSやGCP IDCF
可用性 △ ◯
スケール性能 ◯ △
コスト ☓ ◎
セキュリティ ◎ ◯
事業継続性 ◯ △
• AWS、GCP等 ◎
• DeNAの自動監査システムを導入可
• その他大きな懸念はなし
• IDCF ◯
• DeNAの自動監査システムを導入不可
• その他大きな懸念はなし
Origin Cloud Journey 検討事項 - セキュ...
Origin Cloud Journey 検討事項 - 結果
AWSやGCP IDCF
可用性 △ ◯
スケール性能 ◯ △
コスト ☓ ◎
セキュリティ ◎ ◯
事業継続性 ◯ △
主にDisaster Recoveryについて
• AWS、GCP等 ◯
• どのリージョンでも基本的に同じように利用可能
• IDCF △
• 国内に複数リージョンあるが、どのリージョンでも同じ構成・キャ
パシティを確保するためには別途調整が...
ソフトウェアロードバランサによるMLBと同等のActive/Standby負荷
分散方式の検証を行いました
• Nginx
• Vanilla
• ngx_healthcheck_module + ngx_dynamic_upstream_mo...
AWS + HAProxy を採用
HAProxyを採用した主な理由
• 機能要件を満たしている
• 設定 / 導入が単純
• プロダクトとして成熟している
Origin Cloud Journey 検討事項 - 事業継続性
HAProxy
W...
Origin
Cloud Journey
の話の整理
HLS視聴用

CDN

10秒前後遅延

3〜4秒遅延

1秒前後の遅延
Low-Latency HLS視
聴環境

+ (DR)
HLS視聴用

CDN

10秒前後遅延

3〜4秒遅延

1秒前後の遅延
Low-Latency HLS視
聴環境

+ (DR)
廃止
MLB
ILB
▶ 前半パート(DeNAインフラ 星野・20分)
• これまでの構成とこれからの構成の解説
• Origin Cloud Journey検討ポイントの解説
• 失敗談
 後半パート(SHOWROOM 小井戸・20分)
• Low-Latency...
Push Publish の失敗
HLS視聴用

CDN

10秒前後遅延

3〜4秒遅延

+ (DR)
廃止
S3
upload HLS files (m3u8, ts)
1秒前後の遅延
Low-Latency HLS視
聴環境

HLS視聴用

CDN

10秒前後遅延

3〜4秒遅延

+ (DR)
廃止
S3
upload HLS files (m3u8, ts)
1秒前後の遅延
Low-Latency HLS視
聴環境

ここも廃止しようとし
た
ダメだった
HLS視聴用

CDN

10秒前後遅延

3〜4秒遅延

+ (DR)
廃止
1秒前後の遅延
Low-Latency HLS視
聴環境

これまでの構成から変えたこと
• Origin環境のOn-Premisesからの移行先にIDCFを採用
• Recording Daemon廃止
• 必要最小限のコストでのスケール性能確保・DRの実現
• IDCFのMLBとILBを併用
• 特...
これまでの構成から変えていないこと
• Originサーバの可用性
• IDCF環境でもDR先環境でもフェイルオーバーは3秒以内
• Shardingによる配信スケールアウト
• CDNによる視聴スケールアウト
失敗談
• Push Publi...
  前半パート(DeNAインフラ 星野・20分)
• これまでの構成とこれからの構成の解説
• Origin Cloud Journey検討ポイントの解説
• 失敗談
▶ 後半パート(SHOWROOM 小井戸・20分)
• Low-Latenc...
Low-Latency HLS
自己紹介

・Hiroki Koido / 小井戸 寛樹



・プロダクト本部 プラットフォーム開発G Tech Lead

 ・動画Playerとライブ配信基盤の両者において

  開発全般をTechLeadとしてリード



・経歴

 ...
  前半パート(DeNAインフラ 星野・20分)
• これまでの構成とこれからの構成の解説
• Origin Cloud Journey検討ポイントの解説
• 失敗談
▶ 後半パート(SHOWROOM 小井戸・20分)
• Low-Latenc...
アーキテクチャ

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

Low-Latency HLS環境
Wowza
Streaming
Engine
CDN :
Akamai
CDN :
Akamai
Streaming-APIにGoを選択した理由
1.1.1 実行速度が速い
1.1.2 並列処理に強い
1.1.3 拡張性(スケーラビリティ)が高い
1.1.4 クロスプラットフォーム対応
1.1.5 消費リソースが少ない
参考情報のご紹介

[AWS Black Belt Online Seminar]

AWS Media Services で始めるライブ動画配信



Solutions Architect 廣瀬 太郎様

出展
:https://d1.aw...
遅延の内訳

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

Low-Latency HLSサーバーの仕組み

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

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-MEDIA-SEQUENCE:30193
#EXT-X-TARGETDURATION:3
#EXT-SR-LHLS
#EXTINF...
Low-Latency HLSサーバーのfailoverの仕組み

failoverまで:2〜3秒
  前半パート(DeNAインフラ 星野・20分)
• これまでの構成とこれからの構成の解説
• Origin Cloud Journey検討ポイントの解説
• 失敗談
▶ 後半パート(SHOWROOM 小井戸・20分)
• Low-Latenc...
Playerのバッファリングロジックの仕組み

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

iOSPlayerのバッファリングロジックの仕組み

・lip sync処理
・音声プレイヤーにサンプルをBuffering
・Chunked Transfer encodingで取得
・最新のmpeg2-tsの最新のaudioフレームと
 タ...
  前半パート(DeNAインフラ 星野・20分)
• これまでの構成とこれからの構成の解説
• Origin Cloud Journey検討ポイントの解説
• 失敗談
▶ 後半パート(SHOWROOM 小井戸・20分)
• Low-Latenc...
失敗談 その1

・worker_rlimit_nofile (nginxのulimit) = 65535
(too many open filesにかからないようにする)
・worker_connection = 8192
(nginxへの同...
失敗談 その2

・ulimit、ip_local_port_range、
net.core.somaxconnを上昇

・database/sql -> sqlxに変更

・DBへのconnection poolを使用するよ
うに変更

CD...
失敗談 その3

・s3へのコネクションが貼れない。

・wowzaが瞬間的に停止

・youngGCのオーバーヘッドがでかく、ア
プリケーションが頻繁に停止

・s3へのtransfer managerを使い回さず、1conecxtず
つ、オ...
失敗談 その4

・大量のGCが発生

・wowzaが瞬間的に停止

・master playlistが生成されず

streamが再生不可

Wowza
Streaming
Engine
CDN :
Akamai
CDN :
Akamai
失敗談 その4

・s3を参照せずに、ライブはoriginを向ける

・前段にwebのキャッシュサーバーを配置
Wowza
Streaming
Engine
CDN :
Akamai
CDN :
Akamai
現在の開発状況

・開発は、完了済み。
・現在、システム安定化のために最終調整中。
・影響を極小にするため、ゆっくり導入中。
・近日中に、リリース完了予定!
今後のSHOWROOM株式会社の事業戦略
・SHOWROOM
・新機能の導入で、絶賛ライブ配信盛り上げ中。
・新プロダクト
・新動画メディア開発で縦型動画の新たな世界を開拓
・新音声メディア開発で耳で聴ける新たな世界を開拓
・SHOWSTAGE...
今後のDeNAとSHOWROOM
今後も "エンターテインメント×テクノロジー" を本気で追求
し、世界に喜びと驚きを与えられるようにチャレンジしていき
ます。

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

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

721 views

Published on

本セッションでは、以前のアーキテクチャと比較してどう変わったのか、変える上で重要視したポイントは何か、超低遅延配信の詳細、移行時の失敗談等について触れながら、今回のライブ配信基盤の抜本的なアーキテクチャ刷新の取り組みについてご紹介します。
#livestreaming #HLS #LHLS #RTMP #超低遅延 #AWS #IDCF #Wowza #CDN

Published in: Technology
  • Be the first to comment

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

  1. 1. SHOWROOMとDeNAで取り組んだ
 ライブ配信基盤刷新・
 超低遅延ライブ配信の裏側 星野隼人  小井戸寛樹
  2. 2. 低遅延な配信への こだわり
  3. 3. 超低遅延のデモ動画 超低遅延 1秒未満の遅延 これまでの遅延 10秒程度
  4. 4. • 星野隼人 • システム本部IT統括部IT基盤部第一グループ エンタメチーム チームリーダー 自己紹介 • 2013年〜 • 大学院卒業後、DeNA 新卒入社 • アジア圏の国内外のサテライト拠点およびデータセンターのネッ トワーク設計・構築・運用 • 2016年〜 • エンターテインメント領域のサービスを中心に、20個以上の サービスのインフラを担当するチームをリード • 全社的なクラウドセキュリティに関する調査・検討・導入
  5. 5. ▶ 前半パート(DeNAインフラ 星野・20分) • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談  後半パート(SHOWROOM 小井戸・20分) • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
  6. 6. ▶ 前半パート(DeNAインフラ 星野・20分) • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談  後半パート(SHOWROOM 小井戸・20分) • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
  7. 7. 配信・視聴 これまでの構成
  8. 8. 配信プロトコル ・RTMP (On-Premisesで受付) 視聴プロトコルと遅延 ・RTMP : 3〜4秒の遅延 ・HLS : 10秒程度の遅延 可用性 ・3秒でフェイルオーバー これまでの構成の特徴 高いスケール性能 ・オリジン ー エッジ構成 ・配信基盤のシャーディング ・数千配信、数百Gbpsにも対応可 アーカイブ ・ffmpeg wrapper デーモンによる アーカイブ生成
  9. 9. これまでの構成
  10. 10. これまでの構成 Origin
 RTMP視聴用 Edge
 HLS視聴用
 CDN
 Origin
 Cache
 10秒前後遅延
 3〜4秒遅延
 Recording

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

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

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

  16. 16. これからの構成 Origin
 HLS視聴用
 CDN
 Origin
 Cache
 10秒前後遅延
 3〜4秒遅延
 Recording
 1秒前後の遅延 Low-Latency HLS視 聴環境
 Public
 Cloud
 Origin
 Cloud Journey
  17. 17. Origin Cloud Journey
  18. 18. ▶ 前半パート(DeNAインフラ 星野・20分) • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談  後半パート(SHOWROOM 小井戸・20分) • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
  19. 19. 主な観点 • 可用性 • スケール性能 • コスト • セキュリティ • 事業継続性 Origin Cloud Journey 検討事項
  20. 20. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △ 採用
  21. 21. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
  22. 22. • AWS、GCP等 △ • ゾーン分散可能 • Active/Standby 負荷分散方式はロードバランサ標準機能では 実現不可 • 自前でソフトウェアロードバランサを用意する事で実現可能 • IDCF ◯ • ゾーン分散可能 • Active/Standby 負荷分散方式はマネージドロードバランサを 利用する事で実現可能 • ロードバランサハードウェアアプライアンスをマネージドロー ドバランサとして利用できるサービスがある Origin Cloud Journey 検討事項 - 可用性
  23. 23. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
  24. 24. • AWS、GCP等 ◯ • 潤沢なリソース、上限はほぼ気にする必要がないレベル • 豊富なAPI • IDCF △ • インスタンス在庫等はAWSやGCPに比べれば少ない • マネージドロードバランサ(MLB)のスループットが上限となる • インフィニットロードバランサ(ILB)を併用して緩和 • 特定の通信はMLBを通さないルーティングにより緩和 • 物理専有アプライアンスのためMLBのAPI提供が難しい • 代替案についてIDCFさんと検討中 Origin Cloud Journey 検討事項 - スケール性能
  25. 25. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
  26. 26. • AWS、GCP等 ☓ • インスタンス • 稼働時間課金 • データ転送 • データ総転送量課金 • IDCF ◎ • インスタンス • 基本、稼働時間課金 • ハードウェア専有機の場合はインスタンス保持時間課金 • データ転送 (クラウドネットワークコネクト※の場合) • データ転送レート課金 • 単価や割引は交渉可能 Origin Cloud Journey 検討事項 - コスト ※IDCFクラウドネットワークコネクト https://www.idcf.jp/cloud/nw_connect/
  27. 27. Origin Cloud Journey 検討事項 - コスト 月 額 コ ス ト トラフィックパターン
  28. 28. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
  29. 29. • AWS、GCP等 ◎ • DeNAの自動監査システムを導入可 • その他大きな懸念はなし • IDCF ◯ • DeNAの自動監査システムを導入不可 • その他大きな懸念はなし Origin Cloud Journey 検討事項 - セキュリティ
  30. 30. Origin Cloud Journey 検討事項 - 結果 AWSやGCP IDCF 可用性 △ ◯ スケール性能 ◯ △ コスト ☓ ◎ セキュリティ ◎ ◯ 事業継続性 ◯ △
  31. 31. 主にDisaster Recoveryについて • AWS、GCP等 ◯ • どのリージョンでも基本的に同じように利用可能 • IDCF △ • 国内に複数リージョンあるが、どのリージョンでも同じ構成・キャ パシティを確保するためには別途調整が必要 • IDCFの別リージョンで同じ構成を取ることがすぐには困難 • DR先での構成は別途検討する必要がある Origin Cloud Journey 検討事項 - 事業継続性
  32. 32. ソフトウェアロードバランサによるMLBと同等のActive/Standby負荷 分散方式の検証を行いました • Nginx • Vanilla • ngx_healthcheck_module + ngx_dynamic_upstream_module • OpenResty • LVS + Keepalived • HAProxy Origin Cloud Journey 検討事項 - 事業継続性
  33. 33. AWS + HAProxy を採用 HAProxyを採用した主な理由 • 機能要件を満たしている • 設定 / 導入が単純 • プロダクトとして成熟している Origin Cloud Journey 検討事項 - 事業継続性 HAProxy Wowza
  34. 34. Origin Cloud Journey の話の整理
  35. 35. HLS視聴用
 CDN
 10秒前後遅延
 3〜4秒遅延
 1秒前後の遅延 Low-Latency HLS視 聴環境
 + (DR)
  36. 36. HLS視聴用
 CDN
 10秒前後遅延
 3〜4秒遅延
 1秒前後の遅延 Low-Latency HLS視 聴環境
 + (DR) 廃止 MLB ILB
  37. 37. ▶ 前半パート(DeNAインフラ 星野・20分) • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談  後半パート(SHOWROOM 小井戸・20分) • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
  38. 38. Push Publish の失敗
  39. 39. HLS視聴用
 CDN
 10秒前後遅延
 3〜4秒遅延
 + (DR) 廃止 S3 upload HLS files (m3u8, ts) 1秒前後の遅延 Low-Latency HLS視 聴環境

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

  43. 43. これまでの構成から変えたこと • Origin環境のOn-Premisesからの移行先にIDCFを採用 • Recording Daemon廃止 • 必要最小限のコストでのスケール性能確保・DRの実現 • IDCFのMLBとILBを併用 • 特定の通信はMLBを通らないようにルーティング • DR先はAWS • その他 • Wowza version up 前半パートまとめ (1/2)
  44. 44. これまでの構成から変えていないこと • Originサーバの可用性 • IDCF環境でもDR先環境でもフェイルオーバーは3秒以内 • Shardingによる配信スケールアウト • CDNによる視聴スケールアウト 失敗談 • Push Publish 前半パートまとめ (2/2)
  45. 45.   前半パート(DeNAインフラ 星野・20分) • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート(SHOWROOM 小井戸・20分) • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
  46. 46. Low-Latency HLS
  47. 47. 自己紹介
 ・Hiroki Koido / 小井戸 寛樹
 
 ・プロダクト本部 プラットフォーム開発G Tech Lead
  ・動画Playerとライブ配信基盤の両者において
   開発全般をTechLeadとしてリード
 
 ・経歴
  ・06年〜 SIer入社。
   ・Mobile向け/スマホ向け動画/音楽Playerアプリを開発
  ・11年〜 Web会社に入社
   ・ソーシャルwebゲームのサーバー開発Webエンジニアを経験
  ・16年〜 サイバーエージェントに入社
   ・動画サービスWebサーバーと動画配信基盤の開発を担当
  ・19年〜 DeNA / SHOWROOMに入社
   ・SHOWROOMのライブ配信基盤のリニューアルプロジェクトの立ち上げ

  48. 48.   前半パート(DeNAインフラ 星野・20分) • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート(SHOWROOM 小井戸・20分) • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
  49. 49. アーキテクチャ
 CDN : Akamai CDN : Akamai Wowza Streaming Engine
  50. 50. アーキテクチャ
 Low-Latency HLS環境 Wowza Streaming Engine CDN : Akamai CDN : Akamai
  51. 51. Streaming-APIにGoを選択した理由 1.1.1 実行速度が速い 1.1.2 並列処理に強い 1.1.3 拡張性(スケーラビリティ)が高い 1.1.4 クロスプラットフォーム対応 1.1.5 消費リソースが少ない
  52. 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. 53. 遅延の内訳

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

  55. 55. Low-Latency HLSサーバーの仕組み
 Transcode Group WOWZA Streaming Engine
  56. 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. 57. Low-Latency HLSサーバーのfailoverの仕組み
 failoverまで:2〜3秒
  58. 58.   前半パート(DeNAインフラ 星野・20分) • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート(SHOWROOM 小井戸・20分) • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
  59. 59. Playerのバッファリングロジックの仕組み

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

  61. 61. iOSPlayerのバッファリングロジックの仕組み
 ・lip sync処理 ・音声プレイヤーにサンプルをBuffering ・Chunked Transfer encodingで取得 ・最新のmpeg2-tsの最新のaudioフレームと  タイムスタンプが一致するvideoフレームを  ディスプレイに表示 ・audioを基準にして、videoを合わせる理由  ・audio playback以外のtimerにaudioを同期させるのは困難  ・audioのplaybackにはbufferingが必須  ・videoよりもaudioのがstreamが途切れると、目立つ
  62. 62.   前半パート(DeNAインフラ 星野・20分) • これまでの構成とこれからの構成の解説 • Origin Cloud Journey検討ポイントの解説 • 失敗談 ▶ 後半パート(SHOWROOM 小井戸・20分) • Low-Latency HLSサーバの仕組み • Playerのバッファリングロジックの仕組み • 失敗談 本セッションの構成
  63. 63. 失敗談 その1
 ・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. 64. 失敗談 その2
 ・ulimit、ip_local_port_range、 net.core.somaxconnを上昇
 ・database/sql -> sqlxに変更
 ・DBへのconnection poolを使用するよ うに変更
 CDN : Akamai CDN : Akamai Wowza Streaming Engine
  65. 65. 失敗談 その3
 ・s3へのコネクションが貼れない。
 ・wowzaが瞬間的に停止
 ・youngGCのオーバーヘッドがでかく、ア プリケーションが頻繁に停止
 ・s3へのtransfer managerを使い回さず、1conecxtず つ、オブジェクト化してキューで制御するように変 更。
 ・HeapのEDEN領域を18GBくらいまで下げ、 youngGCのオーバーヘッドを下げた
 CDN : Akamai CDN : Akamai Wowza Streaming Engine
  66. 66. 失敗談 その4
 ・大量のGCが発生
 ・wowzaが瞬間的に停止
 ・master playlistが生成されず
 streamが再生不可
 Wowza Streaming Engine CDN : Akamai CDN : Akamai
  67. 67. 失敗談 その4
 ・s3を参照せずに、ライブはoriginを向ける
 ・前段にwebのキャッシュサーバーを配置
Wowza Streaming Engine CDN : Akamai CDN : Akamai
  68. 68. 現在の開発状況
 ・開発は、完了済み。 ・現在、システム安定化のために最終調整中。 ・影響を極小にするため、ゆっくり導入中。 ・近日中に、リリース完了予定!
  69. 69. 今後のSHOWROOM株式会社の事業戦略 ・SHOWROOM ・新機能の導入で、絶賛ライブ配信盛り上げ中。 ・新プロダクト ・新動画メディア開発で縦型動画の新たな世界を開拓 ・新音声メディア開発で耳で聴ける新たな世界を開拓 ・SHOWSTAGE ・超現実ライブをはじめ、ライブ3.0の新世界を開発 既存のSHOWROOMを活性化し、新たな シナジー効果を生み出すプロダクトを開発中。
  70. 70. 今後のDeNAとSHOWROOM 今後も "エンターテインメント×テクノロジー" を本気で追求 し、世界に喜びと驚きを与えられるようにチャレンジしていき ます。


×