(レポート) DeNAの大規模ライブ配信基盤を支える技術 #denatechcon

DeNA TECH CONFERENCE 2018

#レポート

#イベントレポート

佐々木大輔

2018.02.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本ブログは2018年2月7日(水)に開催されたDeNA TECH CONFERENCE 2018のセッション、「DeNAの大規模ライブ配信基盤を支える技術」のレポートです。

スピーカーは株式会社DeNAの漢祐介さん。

レポート

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

SHOWROOM ... 仮想ライブ空間サービス。アーティストやアイドルとコミュニケーションが取れる。
Mirrativ ... スマートフォンに特化したライブ配信サービス。スマートフォンの画面を共有できる。
Pococha Live ... 手軽にライブ配信可能。セルフィ型ライブ配信。
Laffy ... ライブハンドメイドアプリ。モノ作りをライブ配信。2018年3月にサービス終了予定。

DeNAのライブ配信基盤について

インフラ構成
　配信者 ... スマホ、PC、スタジオ等。
　視聴者 ... 配信アプリ(スマホ)、配信サイト(PC)。
　Originサーバ ... 配信者から映像を受けるサーバ。
　Edgeサーバ ... 視聴者が接続するサーバ。
　配信プロトコル ... RTMP、HLS、DASH。
　配信者→Origin→Edge→視聴者、の流れ。
ライブ配信サービス毎にライブの特色がバラバラ。
何を気にしてインフラ構成を取るか。
　安定した配信。
　大規模配信対応。
　低遅延。

安定した配信

Originサーバのキャパシティ。
　キャパシティは複数の項目で設定。
　　配信数、トラフィック、CPU使用率、メモリ使用率。
　　Originサーバが安定して配信するためのスペックや台数を決定。
Edgeサーバのキャパシティ。
　接続数が多いとCPUを食うし、高画質だと接続数が少なくてもサチる。
　複数の項目で設定。
　　接続数、トラフィック、CPU使用率、メモリ使用率。
　　オートスケールを活用して安定した配信を行っている。
Originサーバ-Edgeサーバ間の接続はオフロードされる。
　Edgeサーバは視聴者吸数に比例して増やす。
Originサーバの可用性向上。
　ロードバランサを使ったActive/Standby構成。
　EdgeサーバはActive/Standby両方に接続。
　　Activeが落ちてもすぐにStandbyから映像を受信。
OriginサーバとEdgeサーバのセットでSharding。
　Shardingされた中でEdgeサーバをオートスケール。

大規模な配信

柔軟なトラフィックコントロール。
　トラフィックコントロール用のテーブルを保持(Edge管理テーブル)
　　Edgeサーバへの振り分けは重み付けラウンドロビン。
　　　重み付けを見て、最も空いてるサーバに振り分ける。
　Originサーバもトラフィックコントロールをしている(Origin管理テーブル)
　　特定のLive IDはShardを専有できるようにテーブルで調整。
　トラフィックコントロールによって柔軟に運用可能。
　トラフィックコントロールはアプリ側の実装も重要。
　　開発陣と密に連携。
オートスケール。
　Edgeサーバのキャパシティを決める時に負荷試験を実施しボトルネックを判断。
　負荷試験結果から決めた数値を元にオートスケール。
　マルチクラウドによるオートスケール。
　　リミット等で特定のクラウドが利用できなくなっても違うクラウドでサービス継続可能。
緻密なモニタリング。
　例えば、Edgeサーバに障害が発生したらすぐに切り離せるように。

低遅延

配信者とのコミュニケーションが円滑になる。
遅延を最小限にするために...
　Edgeサーバが複数のOriginサーバを参照しないことを徹底。
　リレーサーバを置かず、EdgeサーバとOriginサーバ間はシンプルな構成に。
複数のプロトコル対応。

CDNの利用について

これまでなるべくEdgeサーバから直接配信していた。
　遅延が少ないプロトコルが利用できない。
　CDNを使うことで遅延が発生する。
CDNを使うメリット。
　高品質ネットワーク。
　配信のオフロード。
2017年から一部でCDNの利用を開始。
　VR配信のオフローディング用途として検討。
　　VRには2K解像度に匹敵する解像度が必要。
　　高ビットレート映像が必要。
　通常のEdgeサーバ経由でも配信可能だがCDN経由でも配信できるように。
　CDNを設置→遅延問題が解消しない。
　　CDNをEdgeの後段に配置することで大きな遅延に。
CDNがEdgeを介さず直接Originから動画を取得するように(Origin Fetcher)
　Origin FetcherはOriginサーバの近くに配置。
　視聴者にはEdgeサーバ経由と同等程度の遅延で配信できるように。
　配信前のプレビュー画面をCDN経由に切り替え。

マルチリージョン対応について

国外のユーザーは日本のEdgeサーバに繋ぐともっさりする。
現在のインフラ構成をそのまま海外に構築しマルチリージョン対応。
海外のどこにインフラを構築すべきか。
　国外の利用者が多いところ。
　日本よりも利用者に近いところ。
　シンガポールを選択。
視聴者がどうやって国外インフラに接続するか。
　IP Geolocationベースの振り分け。
　シンガポール版のEdge管理テーブルを作成。
　　視聴者が海外のIPアドレスであればシンガポールのEdgeサーバを返す。
今後の多拠点展開も視野にインフラ構築を自動化。
国外リージョンもマルチクラウド対応。

低遅延配信への対応

Low-Latency HLS(LHLS)
　HLSの遅延→Originサーバに原因がありそう。
　Originサーバ→画質毎に変換→Edgeサーバに提供。
　Edgeサーバから視聴者に届けるまでにも複数のバッファリングが動作。
チャンク最小化の取り組みを実施中。

H.265/HEVC 次世代コーデックの対応について

配信規模が増えるに伴って配信トラフィックも増加の一途。
　低画質向けもしているがそもそもパケ死ユーザー向け。
H.265/HEVC 次世代コーデックについて。
　H.254/AVCの後継コーデック。
　同じビットレートならH265のほうが綺麗。
　データサイズの圧縮率も高い。
ただし圧縮時のCPU負荷が高い→Originサーバに負荷がかかる。
課題事項がたくさんあるため構成を検討中。