DeNAの大規模ライブ配信基盤を支える技術

DeNAの大規模ライブ配信基盤を支え
る技術
IT基盤部第1グループ
漢祐介

アジェンダ
• DeNAのライブ配信基盤の紹介
• 大規模配信におけるCDN利用について
• 配信基盤のマルチリージョン対応について
• 低遅延配信への対応について
• H.265/HEVC 次世代コーデックの対応について
• まとめ
1

DeNAインフラで動くライブ配信サービス
2

• インターネット上でアイドル、タレントとコミュニ
ケーションを楽しむことができる、仮想ライブ
空間
• 仮想ライブ空間では、アバターの格好になり
応援したいパフォーマーの部屋を訪問しコ
ミュニケーションできる
• パソコン・スマートフォンなどから配信すること
ができる
• VRライブ配信を行うこともできる
(SHOWROOM VR)
SHOWROOM
(ショールーム)
3

• スマートフォンに特化した生配信・実況配信
が出来るコミュニケーションサービス
• スマートフォンの画面をミラーリングしながら
ライブ配信ができる
• 日本国内以外にも韓国などの海外でも配信
が賑わっている
• ゲーム実況やゲーム大会の配信などが人気
Mirrativ
(ミラティブ)
4

• 手軽に気軽にライブ配信ができるサービス
• ヒマなとき、楽しいとき、グチりたいとき、か
まって欲しいとき、どんなときでもライブ配信
できる
• 配信時に美肌フィルターが使える
• 配信も視聴も手軽にできるようになっている
Pococha Live
(ポコチャ)
5

• ライブハンドメイドアプリ
• ライブ配信をしながらモノを作ったりしながら
販売ができるサービス
• 完成品だけでなく制作過程やクリエーターの
作品への思いも込めて表現できる
• 過去に配信された映像は見返す事もできる
• 2018年3月30日サービス提供終了予定
Laffy
(ラッフィー)
6

前書き
一部 TechCon 2017 で
発表した資料と被る部分があります
詳細な構成について記述してあるので、よろしけれ
ば後日確認していただければと思います
7

DeNAのライブ配信基盤について
どういった
インフラ構成になっているのか
8

このスライドに登場する主な登場人物
- 配信者
- 視聴者
- Origin(オリジン)サーバ
- Edge(エッヂ)サーバ
- 配信プロトコル
9

配信者
映像を撮影し配信ソフトやアプリを通じてインターネットに配信する人のこと
配信スタイルはさまざまでスマホのアプリから直接配信をしていたりする
10

視聴者
インターネットで配信されている映像をみる人
視聴方法はパソコンならサイトを通じて、スマホならアプリなどを通じて視聴する
11

Origin(オリジン)サーバ
配信者から映像を受け付けるサーバ
配信される映像データはこのサーバで受け取り、 Edgeサーバを通して視聴者に届けられる
12

Edge(エッヂ)サーバ
視聴者が映像を視聴する際に繋ぎに来るサーバ
Originに配信されている映像データを視聴者に配信するサーバ
13

配信プロトコル
映像を届けるためのプロトコル
プロトコルといっても HLSやDASHはHTTP上での
ルールのようなもの、プロトコルの種類によっていく
つか違いはあるが主に今回登場するのは下記の 3
つ
- RTMP
- 古くからあるリアルタイムメッセージングプロト
コル
- HLS
- HTTP上でライブストリーミングを実現するため
の規格
- DASH
- HLS同様HTTP上でストリーミングを実現する
ための規格
細かなプロトコルの中身は割愛
14

15

DeNAではさまざまなライブ配信サービスがあり、サー
ビスによってライブの特色はバラバラ。
16

ライブ配信サービスのインフラを構築する上で
何を気にしてインフラ構成をとるのか
- 安定した配信ができること
- 大規模な配信にも対応できること
- 低遅延であること
17

18

安定した配信をするため
- 適切なキャパシティプランニング
- 可用性を上げるための工夫
- 影響の極小化
これらをどう見積もりながら、どんな仕組みで構築して
いくかが重要
19

Originサーバのキャパシティは何で決まるか
20

キャパシティは複数の項目から決定
21
CPUを使い切る前に、トラフィックでサ
チってしまったり、大量のEdgeがぶら下
がるとメモリが枯渇してしまったりする。
項目
・配信数
・トラフィック
・CPU使用率
・メモリ使用率
Originサーバは配信をずっと受け続ける
ため、キャパシティに余裕をもたせたい
→ これらの項目の数値を元にキャパシ
ティを決定

Edgeサーバのキャパシティは何で決まるか
22

キャパシティは掛け算で決まる
23
接続数が多いとCPUを食うし、トラフィッ
クも出る、高画質(高解像度)な配信の場
合接続数が少なくてもトラフィックがサ
チってしまう
項目
・接続数
・トラフィック
・CPU使用率
・メモリ使用率
後述するオートスケールの仕組みは、こ
の項目を元に計算式を作ってスケール
アウト・スケールインが自動で行われて
いる

Origin <-> Edge 間は接続が束ねられる(offload)
24

Origin <-> Edge 間の接続はオフロー
ディングされるため、Originは視聴数に
比例することはないが、Edgeは視聴数
に比例して増やす必要があるので、何
台までぶら下げれるかも重要
25

Originサーバの可用性を高めるため Active/Standby 方式のLBで振り分けている
26

EdgeサーバはOriginのActive側とStandby側どちらにも接続している
27

キャパシティが決まれば、スケールできるように設計をする
分割できる単位を決めshardingしている(Orign + Edgeがセットで1 shard)
28

Origin/EdgeのセットでShard単位にして
Origin/Edgeの組み合わせはスケール出来
るが、EdgeそのものもShard内でスケール
できるように構築しておく
29

30

大規模な配信にも対応できるようにするため
- 柔軟なトラフィックコントロールシステム
- edge だけではなく origin もコントロール
- オートスケーリングシステム
- 構築の自動化(= 高速なスケールアウト)
- サービスイン・アウトの自動化
- 複数のクラウドでも動く
- 緻密なモニタリング
- 何かあった時に気付けるように
31

トラフィックコントロール(Edge)
32

トラフィックコントロール(Origin)
33

トラフィックコントロール
Edgeだけトラフィックをコントロールできても、
いざOriginに配信をしようと思った時に問題が起こらないよう、
Originのトラフィックをコントロールできるように実装してある。
この仕組があることで安全にサービスイン・アウトも出来るた
め、メンテナンス性も向上している
34

トラフィックコントロール
トラフィックをコントロールするためのシステムはアプリケーショ
ンの実装と密に関わっているため、開発陣とのコミュニケーショ
ンが大切。
また逆に開発陣も仕組みを理解してくれるため、柔軟にトラ
フィックのコントロールするための仕組みを実現。
突発的なトラフィックが起きた場合もこのシステムを組み合わせ
ることでコントロール可能になっている。
35

オートスケーリング
36
キャパシティを決める際に、負荷試
験を実施。
そこから得られた数値を元にオート
スケールを実装している。
また、自動化してある為、高速に
サービスインまで持っていくことがで
きる

オートスケーリング(マルチクラウド)
37
何らかの理由でクラウドサービ
スが利用できなくなったとしても
(リミットに達した等)
複数のクラウドサービスでそれ
ぞれオートスケーリングできる
ように設計している
複数のクラウドサービスが混在
してもダウンタイム無く、サービ
スを継続させれるように実装さ
れている

38

遅延をなるべく最小限にするために、Origin<->Edgeの間はシンプルな構成を取って
いる
39

遅延の少ないプロトコルを選択できるように、またモバイル回線になった場合もシー
ムレスに切り替えができるように複数のプロトコルで通信ができる
HLSなどのHTTPを利用するものはチャンク最適化をしている
40

大規模配信におけるCDNの利用について
いかに遅延を減らし
高品質な映像を届けているのかについて
41

従来からCDNの利用はなるべく避けてきていた
- 遅延が少ないプロトコルが利用できない
- CDNを経由させることによる遅延がでていた
しかしながら利用することによるメリットはある
- CDNならではの高品質ネットワーク
- 配信のオフロード
2017年から一部サービスからCDNでの配信を開始
(もの自体は2016年後半からは存在していた)
42

もともとCDNの利用はVR配信のオフローディング用途として構
想していた
- 2K解像度に匹敵する解像度が必要であること
- それに伴う高ビットレート映像
これらサイズを既存のEdgeからトラフィックを流した場合に、
キャパシティが足りなくなる事が想定されたため、オフローディ
ングできるよう構想
43

44
VR専用の配信系統なども準備していた
またDASH(MPEG-DASH)も利用できるようになった

ただ、CDNを設置する事による映像の遅延問題は解消していなかった。
というのも、当初CDNはEdgeの後段に置く予定だった
45

Edgeの後段に置く理由は、
Edge自体にOriginの冗長化構成を考慮した設計が入っているため、その後段にいる
ことでその恩恵を受けれるようになっていたり、
オートスケールがShard単位で行われるため、Edge群を向けておけばオフローディ
ング先を分散できるため
が、遅延が大きく、利用には向いていなかった
46

遅延はどこで発生しているのかを調査したところ
各ポイントでのバッファリングとチャンクデータを CDNから参照する際に最適化されておらず
再取得が増えていたことが原因としてありそうだった
47

そこで、Originから直接映像を取り出して CDNから読み出せるように再構成
さらに、CDNから取得したチャンクデータを再取得が少ない形式に変換することとで、キャッシュヒット率を高
めると共に遅延を少なくさせている
48

これらを経て、30秒近く遅延していた映像が数秒の遅延に抑えつつCDNの利用が出
来るようになっている
また、当初の想定とは別にオフローディング用途としての利用があり、現在では配信
を見る前のプレビュー画面などで利用されている
49

配信基盤のマルチリージョン対応について
ライブ配信基盤の海外展開について
50

国外のユーザは日本のEdgeに繋ぎに来るよりも、現地のネット
ワークで繋いだほうが遅延が少ない
また、CDNの遅延もある程度の抑える事ができたが、従来の低
遅延も利用したい
既存のインフラ構成はそのままに、海外のリージョンに対応して
いる
2017年から一部サービスから利用を開始している
51

海外のどこにインフラを構築するべきか
- 国外の利用者が多いところ
- 日本よりも利用者にとって近いところ
- そもそもインフラ構築ができるところ
=> シンガポールに既存のインフラ構成のまま構築
52

53

インフラは構築できた
視聴者が使うEdge先はどうやって変更するか
=> IP Geolocationベースに向き先を決定している
また、既存の設計そのままに横展開した設計し、フェイルバック
が出来るように設計(現在は日本がフェイルバック先)
54

55

オートスケールの設計自体がマルチクラウドも視野に設計して
いるので、大きく手を加えること無く
複数リージョンでもオートスケーリングされるように構築してい
る。
また、今後の多拠点展開も視野に構築自体も自動化
・社内ツール連携の廃止
・最新のOSやVMへの対応強化
56

57

58

59

60
従来どおり
マルチクラウドも
利用できるように
なっている

低遅延配信への対応について
Low-latency HLS
(LHLSと呼んでいる)
61

LHLSってなに？
- 自分が勝手にそう呼称しているだけ
- 最小限の遅延でHLSを配信したかった
- ブラウザでRTMPが利用できなくなりつつある
- HLS(HTTP経由)である利点があるから
- CDNでの利用ができるから
62

なんでHLSが遅延するのか
=> 僕らの使っているOriginに原因がありそうだ
63

Originが配信を受けるまで(イメージ)
64

OriginからEdgeに届くまでやっていること
65

Originは色々やっている(イメージ)
66

Originは色々やっている(イメージ)
67

Edgeから視聴者に届くまでも色々多い
68

映像を低遅延化させるためには、OriginやEdgeで行っている
バッファを如何に短くするかが鍵となってくる
(CDN対応のところでやっている)
また、チャンクの秒数を短くすることでEdgeに届くパケットを早く
送出することができる
69

チャンク最小化
2秒の映像データを3個保持している場合、これは6秒の映像ということ
7-8秒目の映像が配信されるまで2秒の遅延が発生
70

チャンク最小化
そこで2秒だった映像を1秒区切りに再変換させることで遅延時間を減らせるのでは
ないか？また保持するチャンクを減らすなどで配信されるのを減らせないか
71

Originからリアルタムに映像を
取り出すようにし、この中で
mpegtsに詰め直しをリアルタ
イムに行う(1秒単位に切り詰
め)
詰め直したmpegtsをHLSとし
て配信できるようにした
HTTP(LHLS Origin)を用意
72

チャンク最小化 - 結果
雑な実装ながら原理的にはこういったことの積み重ねで低遅延
は作れそう
- ただしプロダクションには使えないほどバグが多い
(TechConに間に合わなかった)
- RTMPは遅延が少なくすごいというのを再確認できた
今後も調査していく
74

H.265/HEVC 次世代コーデックの対応について
次世代コーデックへの対応について
現在の行っている取り組み
75

配信規模が増えるに従い、配信トラフィックが増加の
一途
- 低画質向けのトランスコードはしているがターゲット
はパケ死対策でメインの利用ではない
- そもそも高画質の配信をしているからトランスコード
はできない
76

H.265/HEVCとは
- H.264/AVCの後継コーデック
- H.264と比べブロックノイズが少なく、同じビットレートなら
H.265の方が綺麗
- H.264よりも圧縮率が高く40%ほどサイズが小さい
- 比較的最新のスマホで利用できるようになってきた
- 8Kに対応(H.264は4Kまで)
※以降紛らわしいのでH.265は HEVC と表記しています
いくつかコーデックと画質の比較してみました 77

画質比較 - 元画像
78
比較対象
ProRes422
1920x1080p30
130Mbps

画質比較 - 400Kbps
79
H.264
baseline 4.0
1920x1080p30
400Kbps
一番画質が悪い。
木の質感ものっぺり
と潰れていてブロッ
クノイズも出ている。

80
H.264
main 4.0
1920x1080p30
400Kbps
ぼやけた感じが大分
減っているが、木の
木目などは潰れてい
る状態。

81
HEVC
1920x1080p30
400Kbps
比較対象のProRes
とまではいかないが
パット見るだけでは
分からないレベル

同じ箇所を横に並べてみました
元画像
82
H.264 main 400KbpsH.264 baseline 400Kbps
HEVC 400Kbps

同じ箇所を横に並べてみました
元画像
83
H.264 main 400KbpsH.264 baseline 400Kbps
HEVC 400Kbps
ブロックノイズが
見える
木の質感が失わ
れている

H.264を倍のビットレートにしても同画質にはならず
84
H.264
main 4.0
800Kbps
HEVC
400Kbps
400Kbpsから
800Kbpsに上
げたものの
まだ質感が足
りない...。

H.264 800Kbps と
HEVC 400Kbps の画質がほぼ同等と思えるくらい H.265/HEVC は綺麗
また、データサイズが
89,710 バイト(90 KB) あったものが
41,618 バイト(45 KB) まで減るため、
トラフィックの削減にも効果がありそう
85

H.265/HEVCはとても有用そう、ただし圧縮時のCPU負荷が高騰する。
ものによるが概ね120%-180%ほどCPU使用率が上がることが分かっている
現在はOrigin内でトランスコードしているが、安定した品質で届けられる仕組みを検
討
86

課題事項が沢山あるので一つ一つ検証を進めている。
fMP4 対応も視野にしつつ構成を検討中。
87

まとめ
2017年を振り返る
88

まとめ
- 大規模配信の対策いろいろ
- 遅延少なくCDNの利用が出来るようになった
- マルチリージョン対応しているようになった
- 新しい低遅延化への取組み中
- H.265/HEVC も検証中
89

ご清聴ありがとうございました

DeNAの大規模ライブ配信基盤を支える技術

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a DeNAの大規模ライブ配信基盤を支える技術

Semelhante a DeNAの大規模ライブ配信基盤を支える技術 (9)

Mais de DeNA

Mais de DeNA (20)

Último

Último (12)

DeNAの大規模ライブ配信基盤を支える技術