スライド

Content Espresso を用いた
ライブ配信を可能にする
高速な分散保存方式
佐野岳史†，安藤大佑†，寺岡文男‡，金子晋丈‡
†慶應義塾大学大学院理工学研究科
‡慶應義塾大学理工学部
1
本研究の概要
大容量の
ファイル共有
場所によらない
高速なファイル取得
低ストレージコスト
広域分散ストレージシステム
Content Espresso
非圧縮 Full HD 24fps (1.2Gbps)の
オンデマンド配信を実現
ライブ配信の実現を目指す
本研究室で提案&開発
UDP を利用した書き込み
しかし現状の遅い書き込みでは
実現できない
書き込みの設計と実装をし
ライブ配信を実現する
ライブ配信を実現し，TCP と比較した評価により
Content Espresso に適している書き込みが実装できたわかった
2
Content Espresso 開発の背景
•  大容量コンテンツを利用する産業が増加
–  デジタルシネマプロダクション
–  デジタルライブラリサービス
•  数 MB 以上のファイルが数多く存在
•  大容量ファイル利用に対する2つの要求
–  高速なコンテンツ共有
•  世界中のユーザ間で大容量コンテンツをシェアしたい
•  データ取得時間を予測したい
–  低コストなコンテンツ保存
•  大容量ファイルはただでさえストレージコストがかかる
•  なるべく低い冗長率で保存したい
高速共有と低コスト保存はトレードオフの関係にある
分散ストレージシステム Content Espresso の提案
3
Content Espresso の概要
•  動作
1. 
2. 
3. 
4. 
5. 
元のファイルに誤り訂正符号（FEC）を付加
元ファイルとFECをチャンクに分割
チャンクを複数のチャンクサーバに保存
チャンクをUDPで受信（パケットが落ちる可能性あり）
FECによる落としたパケットの回復
書き込みフェイズ
読み込みフェイズ
4
3
元のファイル 1
+
2
ファイルと FECを分割
UDPによる転送 Client
分散保存 5 ファイルの
FEC を付加 回復 Chunk Generator
(アップロードサーバ)
Chunk Server
(ストレージサーバ)
回復した ファイル •  アプローチ
–  UDP によるデータ取得
–  FEC によるデータ回復
–  チャンク分割 + 分散保存
4
Content Espresso を利用した
ライブ配信システム
映像を
キャプチャー
書き込み
UDP +
ファイルと FECを分割
FEC 付加 分散保存 Write
Client
Read
Client
ファイルの
回復 TCP 映像ファイル
Chunk Generator
読み込み
Chunk Server
回復した
ファイル
•  ライブ配信を実現するためには読み込みと書き込みが必要
–  現時点でできていること：予め保存されている映像の配信（読み込みのみ）
•  ライブ配信実現のための要求事項
–  安定した高いスループット
•  間断なく生成される映像ファイルを
映像のビットレート以上のスループットで書き込み続ける必要
•  e.g.) 非圧 Full HD 24fps: 1.2Gbps
–  低遅延なファイル転送
•  生成された映像ファイルが即座にユーザに届けられる必要
•  e.g.) ニコニコ生放送 (2 - 3秒)
5
書込要求
③ 冗長データ生成＋分割 ④ Chunk Server の数だけ
recvAgent
スレッドを生起
⑤ TCP
ファイルデータ
① スレッド生起
冗長データ
Client
② TCP
Thread
ファイル
・
・
・
Chunk Generator
•  リクエスト毎に Chunk Server 数分スレッド生起
–  Chunk Server 数の増加 => 負荷増大による遅延発生
•  TCP による各チャンクサーバへのデータ配送
–  Chunk Server までの距離大 => スループット低下
–  ネットワーク状況の変化 => 不安定な転送時間
Chunk Server の場所(RTT)・台数
によらずに要求を実現する必要
6
Chunk Servers
Chunk Generator の実装の問題点
設計指針
•  Chunk Server 数による
負荷増大が発生しない実装 (変更1)
•  TCP ではなく UDP を利用すること（変更2）
– 
– 
RTT によらないスループット
ネットワーク状況によらない転送時間
7
変更１：Chunk Server 数への対応
recvAgent
ファイルデータ
Client
② TCP
冗長データ
Thread
Thread
ファイル
Chunk Generator
ラウンドロビン
アルゴリズム
①スレッド生起
④ 確立されている
TCP コネクションを
利用しデータ配送
•  事前に Chunk Server と TCP コネクションを確立し
スレッド間で共有
–  ラウンドロビンアルゴリズムを用いて配送
•  書き込み要求ごとにスレッドは1つのみ生起
8
Chunk Servers
事前に
コネクションを確立
③ 冗長データ生成＋分割
書込要求
変更２：UDP の利用
③ 冗長データ生成＋分割
書込要求
ファイルデータ
Client
② TCP
冗長データ
Thread
Thread
ファイル
UDP
ラウンドロビン
アルゴリズム
①スレッド生起
レートの
コントロール
Chunk Servers
recvAgent
Chunk Generator
•  UDP によるデータ配送
–  各スレッド毎に転送レートをコントロール
–  パケットロスが発生しても再送をしない
9
評価概要
•  設計・実装した UDP の書き込みが有用であるか評価する
•  評価1：UDP による分散保存の性能 (変更2)
•  評価2：TCP による分散保存の性能（変更1）
•  評価3：UDP と TCP の比較
–  評価1，2の性能が良いパラメータのものを用いる
10
測定環境
RTT: 5msec
10Gbps
パケットロス 0%
1Gbps
10Gbps
1クラスタ
(12台)
…
慶應義塾大学
矢上キャンパス
…
Chunk
NetEmマシン
Generator
(CG)
チャンクサーバ(CS)
慶應義塾大学 DMC
•  CG ‒ CS 間
–  RTT：5msec
–  パケットロス率：0%
•  NetEm マシン
–  ネットワーク状況をエミュレート
–  ネットワークのパケットロス率を0.01%
に設定[1]
マシン
Chunk Generator
全6クラスタ (72台)
CPU
RAM
OS
Core i7-­‐3770 @ 3.4GHz
8GB
CentOS 6.3
NetEm マシン Core i7-­‐3770 @ 3.4GHz 8GB
CentOS 6.3
チャンクサー
バ(72台)
PenIum G640 16GB
@ 2.8GHz
CentOS 6.3
[1] IIJ SLA Packet Loss Rate Value: 0.01% 未満より
11
測定内容
非圧縮 Full HD 画像：6.22MB
•  測定方法
–  CG から CS へ非圧縮 Full HD 画像を100枚転送
•  合計転送時間と1ファイルの転送ごとにかかる時間を計測
•  UDP と TCP のそれぞれにて測定
–  UDP の場合 CS でのパケットロス率も計測
…
…
Chunk
NetEmマシン
Generator
(CG)
1クラスタ
(12台)
チャンクサーバ(CS)
全6クラスタ (72台)
•  事前設定
–  CG のメモリにはファイルデータと冗長データを事前に載せておく
•  ファイルの冗長率は20%
12
最大値
¾値
評価1: UDP による分散保存
中央値
¼値
最小値
平均スループットと転送時間のばらつき
0.8
0.7
5000
0.6
4500
4000
0.5
3500
0.4
3000
0.3
2500
0.2
2000
1500
0.1
1000
0
rate100M/100th
rate200M/50th
rate250M/40th
rate500M/20th
rate1G/10th
rate2G/5th
rate2.5G/4th
rate5G/2th
要求したレートが
全く出ていないため使用できない
rate10G/1th
すべてのファイルが0.1秒以内に送れている
スループットも 5Gbps 近く出ている
パケットロス率は0.5%未満
5500
throughput (Mbps)
–  Chunk Generator の限界が10Gbps
–  rate: チャンク送信レート
–  th: スレッド数
6000
0.9
throughput
send time
sendTime (sec)
•  チャンク送信レート スレッド数
= 10Gbps となるように設定
6500
18
チャンク送信レートを2.5Gbps
同時送信ファイル数を4 10
に設定すると高い性能が出る
1Gbps
total loss data (%)
高いスループットがでているが 16
14
パケットロス率が高いため
12
使用できない
パケットロスの割合のばらつき
10
8
6
4
2
0
13
評価2: TCP による分散保存
•  TCP 転送の同時送信ファイル数の変化による
平均スループットと転送時間のばらつき
同時送信ファイル数が増えると
平均スループットも高くなる
throughput (Mbps)
同時送信ファイル数 30-70 の時
転送時間は安定しない
6500
throughput
send time
1
0.8
6000
5500
0.6
5000
0.4
4500
4000
0.2
3500
同時送信ファイル数が少ないと
転送時間も短い
3000
0
20
40
60
0
100
80
nThread
平均スループットと転送時間のばらつき
転送時間を短くしたい場合同時送信ファイル数を20にする
帯域を活用したい場合同時送信ファイル数を増やす
14
sendTime (sec)
7000
同時送信ファイル数が
多いと転送時間は長い
評価3: UDP と TCP の比較
7000
•  UDP と TCP 転送の RTT の変化による平均スループットの比較
–  UDP は性能が良かったスレッド数10, 5, 4 を使用
–  TCP は性能が良かったスレッド数100, 20 を使用
6000
7000
広域分散を想定している
Content Espresso においては
UDP による書き込みが良い
6000
5000
4000
3000
2000
1000
0
0
10
put (Mbps)
throughput (Mbps)
RTT が 7msec までは TCP が優位
それ以降は UDP が優位
TCP nThread: 20
TCP nThread: 100
UDP sendRate:1000 nThread:10
UDP sendRate:2000 nThread:5
UDP sendRate:2500 nThread:4
20
30
5000
4000
40
5000
4000
50
RTT (ms)
7
60
70
10
80
90
15
100
ライブ配信の実現
•  非圧縮 Full HD 24fps (1.2Gbps) のライブ配信
16
まとめ
•  背景
–  Content Espresso の書き込み性能がわるくライブ配信の実現不可
–  書き込み部分を設計・実装
•  アプローチ
–  再送をしない UDP 伝送の利用
•  結論
–  Content Espresso において UDP による書き込み方式は有用
–  Full HD 24fps のライブ配信を実現
•  今後の課題
–  チャンクサーバの台数、ファイルサイズを変化させた計測
–  書き込みと読み込みが同時に発生する場合の評価
17