Document

Content Espresso を用いた
ライブ映像配信を可能にする高速な分散保存方式
佐野岳史 †
†
安藤大佑 †
寺岡文男 ††
金子晋丈 ††
慶應義塾大学大学院理工学研究科
††
慶應義塾大学理工学部
概要
ネットワーク技術の進歩やディスプレイ技術の発達により，インターネットを介した高解像度映像コンテンツの視聴やライブ配信の
需要が高まっているが，大容量映像コンテンツを配信するためには広帯域ネットワークが必要となり，ライブ配信をするために高速
な保存機能が必要となる．筆者らは大容量コンテンツを対象として広域分散ストレージサーバに分散保存し，高速かつ低ストレージ
コストでインターネット規模のコンテンツ共有と可用性・信頼性のあるコンテンツ保存を実現する Content Espresso の設計と実装
をしている．本稿では Content Espresso の保存部分に着目し，ライブ配信を可能とする高速な保存方式を提案する．本方式は UDP
と誤り訂正符号を用いることで再送をしない高スループット・低遅延な保存方式である．実際に本方式を 72 台のサーバへ分割保存す
ることで評価し，同時に複数のファイルを送りつつも低遅延で高スループットを維持できることを確認した．
キーワード大容量ファイル転送，UDP，分散保存，ライブ配信
1
はじめに
当研究室では大容量映像を配信するために広域分散スト
レージシステムである Content Espresso [4] の提案と実装を
近年，ネットワーク技術の進歩やディスプレイの発達によ
している．Content Espresso は場所によらない高速なファ
り，ネットワークを介した高解像度の映像コンテンツ視聴や
イル取得と低ストレージコストの両立を目標にしている．そ
ライブ配信がより一般的になってきている．例えば 4K(解
のためのアプローチとして 1)UDP によるデータ取得，2) 前
像度 3840×2160)，8K(解像度 7680×4320) といった超高解
方誤り訂正 (FEC) を利用した消失データ回復，3) 大規模分
像度映像コンテンツの配信が期待されており，インターネッ散保存の 3 つの要素を組み合わせている．図 1 に Content
ト上の有名な映像配信サービスである YouTube [1] でも Espresso の概要を示す．ファイルを保存ときは，ファイル
4K 画質の映像配信が始まっている．また，Full HD(解像度と FEC 符号を用いられて作成された冗長データを分割し，
1920×1080) 映像をライブ配信可能な Ustream[2] やスマー世界中に設置されたストレージサーバ（チャンクサーバ）に
トフォンから手軽にライブ配信可能な TwitCasting[3] など保存する．ファイルを取得するときは，データが保存され
のライブ配信サービスある．
ているチャンクサーバすべてに取得要求を出し，UDP を利
高解像度映像コンテンツは非常に大容量となっており，配用して取得する．信頼性のない UDP によるチャンク取得
信するためには広帯域ネットワークが必要となる．例えば，なので，パケットロスによりチャンクが失われる可能性が
非圧縮 Full HD 24fps の映像であると約 1.2Gbps，非圧縮あるが，保存のさいに作成した冗長データによりある程度
4K 30fps の映像であると約 6Gbps のネットワーク帯域が
のパケットロスまでならば再送すること無く回復すること
必要となり，非常に広帯域であることがわかる．
ができる．
ライブ配信は視聴者は事前に保存されている映像を見る
Content Espresso を利用した高精細映像のオンデマンド
のではなく，撮影されてすぐの映像を見るため，配信動作
配信をすでに実現しているが，Content Espresso は読み出
だけでなく保存動作も高速な必要がある．映像が撮影され
し速度を高めることに注力し，書き込み速度が考慮された設
てから視聴者に届くまでの時間が短いほど良いライブ配信
計にはなっていないため，安定した高い書き込みスループッ
サービスであるといえる．また，ライブ配信をしている間
トが要求されるライブ配信に応用することは難しい．そこ
は常に映像が生成されていくため，アップロードのスルー
で，本稿では Content Espresso の書き込み部分に着目し，
プットが低下すると保存するべき映像ファイルが増加して
ライブ配信を可能とする高速な分散保存方式を提案する．
いってしまう．このような理由からライブ配信には安定し
たスループットが必要であることが分かる．
1
元のファイル
1
5
FECコードを付加
回復した ファイル
ファイルの
回復
+
3
4
2
UDPによる転送 Client
分散保存
ファイル分割
FECをチャンク内に挿入
図 1: Content Espresso の概要
成用行列を準備することでさまざまな冗長率の冗長データ
を生成することができる．冗長データを生成した後，Chunk
Client
Generator はファイルデータおよび冗長データを 1024byte
単位のチャンクに分割し，それぞれのチャンクにシーケン
ファイルデータ
TCP
ス番号を順番に付与しながらラウンドロビンアルゴリズム
ファイル
でチャンクサーバに保存する．ラウンドロビンアルゴリズ
ムを使用することでチャンクを全てのチャンクサーバへ均
等に分散することができるので，LDGM 符号の回復性能を
Chunk
Generator
冗長データ
高めることができる．この時，Chunk Generator はチャン
クサーバの数だけスレッドを生起し，TCP を利用して並列
に保存処理をする．ファイルデータ，冗長データのすべて
TCP
TCP
TCP
を保存し終えると保存終了通知を Client へ送信し，すべて
TCP
のファイル保存処理が終了する．また，Chunk Generator
は Client から書き込みの要求が来るたびに上記の処理を
する．
保存方式の設計
3
チャンクサーバ
本章では，ライブ配信の書き込みにおける要求事項をま
図 2: Content Espresso のファイル保存方式
とめる．また，Content Espresso の書き込みにおいての検
討すべき点を列挙し，保存方式の設計について述べる．
2
Content Espresso の保存方式
3.1
Content Espresso におけるファイル保存方式の詳細を図
ライブ配信の要求事項
2 に示す．Client がファイルを保存する際，まず Client に
ライブ配信の書き込みにおける要求事項は以下のとおり
近い位置にある Chunk Generator と呼ばれるアップロードである．
サーバへファイルを TCP を利用してアップロードする．
Chunk Generator はファイルを Client から受信した後， 1. 映像のビットレートよりも広いネットワーク帯域
映像は時間軸を持っているコンテンツであり，単位
ファイルデータを 1MB ごとのブロックに分割をし，その
時間ごとの映像のデータ量をビットレートで表すこと
ブロック毎に FEC 符号を利用して冗長データを生成する．
ができる．映像配信をする際に映像のビットレートよ
Content Espresso では FEC 符号として LDPC 符号の一種
である LDGM 符号を利用しており [5]，あらかじめ符号生
りも広いネットワーク帯域が必要である．
2
2. 安定して高いスループット
ライブ配信の場合，映像はアップロードしている際
Client
ファイルデータ
も絶えず生成されている．そのため，アップロードの
スループットが低下すると Client 側にアップロードす
TCP
る映像ファイルが増加していくので，安定して高いス
ファイル
ループットが必要である．
冗長データ
3. 低遅延での映像保存
ライブ配信はリアルタイムの映像を視聴者に届ける
ことを目的にしているため，映像が撮影されてから視
Chunk
Generator
TCP
TCP
聴者に届くまでの時間が短ければ短いほどよい．書き
UDP
込みに着目した場合，映像ファイルが撮影されてから
UDP
保存されるまでの時間を低遅延にすることが求められ
ている．
UDP を用いたチャンク転送
3.2
チャンクサーバ
前節で述べた要求事項を満たすために UDP を用いたチャ
ンク転送を使用する．UDP はネットワーク状態に関係なく
図 3: 保存方式
一定速度でファイルを送信することができる．そのため低遅
延で安定して高いスループットを出すことができる．TCP
をチューニングして使用することも考えられるが，チュー
3. チャンクサーバ数
Chunk Generator は全てのチャンクサーバへファイ
ニングのコストや再送の発生を考慮して UDP を使用する
こととする．
ルを分割分散保存をする．そのためチャンクサーバの
台数が増加した場合でも書き込みの性能がスケールす
る必要がある．
既存の Content Espresso の検討すべき点
3.3
UDP を用いたチャンク転送を Content Espresso の書
き込み部に設計するうえで検討すべき点は以下のとおりで
3.4
ある．
ライブ配信における保存方式の設計
ライブ配信を Content Espresso で実現する上で，UDP
1. RTT
を用いた保存方式と TCP のみを用いた保存方式を図 3 に示
Content Espresso は場所によらない高速なファイル
し，その設計について述べる．Chunk Generator は Client
転送を目標にしているため，Chunk Generator とチャと距離の近いものが選択されるため，従来とおり Chunk
ンクサーバ間の RTT は様々な値になる．TCP のス
ループットは，RTT に反比例し，パケットロス率が小
Generator とチャンクサーバ間は TCP を利用したファイ
ル転送とする．Chunk Generator はチャンクサーバの台数
さい時はパケットロス率の平方根に反比例することが
が増加した場合でも書き込みのスループットが低下しない
知られている [6]. そのため Chunk Generator とチャン
ようにするため，書き込み要求ごとの処理をチャンクサー
クサーバ間の RTT が小さい場合は信頼性の低い UDP
バの台数にスケールする実装が必要である．
を用いずに TCP のみで 3.1 節の要求を満たすことが
できると考えられる．
3.4.1 UDP を用いた保存方式の設計
2. 同時送信ファイル数
Chunk Generator とチャンクサーバ間の RTT が大きい
Chunk Generator は Client から書き込みの要求が
時は Chunk Generator とチャンクサーバ間の通信に UDP
来るたびに分割分散保存の処理をする．しかし，ネッ
を用いる．UDP で送信されるデータはチャンクサーバに保
トワーク帯域の上限が決まっているため，要求が来た
存する段階でパケットロスが発生する可能性が考えられる
ものを全て並列化して送信するよりも，一度に並列化
が，チャンクサーバはパケットロスが発生しても受け取った
できる数の上限を定めた方が性能が良くなる可能性が
パケットをそのまま保存する．パケットロスが発生し，不
考えられる．
3
完全なファイルの状態でも，読み込みの段階である程度の
Cluster
パケットロスならば回復することができる．
拠点B
NetEmマシン
同義
実際に利用できるか読み込むまでわからないファイルを
10Gbps
保持することはファイルシステムとして問題である．ファイ
1Gbps
ル転送時間を予測できないという点でライブ配信途中に再
…
送処理はできないが，ライブ配信終了後にパケットロスが
Chunk
Generator
10Gbps
チャンクサーバ
12台
発生しているファイルを完全なファイルとして保存し直す
必要がある．そのため Chunk Generator はファイル保存の
際にチャンクサーバからパケットロスの発生の有無を送信
拠点A
ps
Gb
ps
10
ps
Cluster
バへアップロードし，完全なものとする．また，ライブ配
10Gbps
配信終了後に保存しておいたファイルを再度チャンクサー
ps
Gb
ルを保存しておく必要がある．Chunk Generator はライブ
10
Gb
10
s
bp
G
10
10Gb
してもらい，パケットロスが発生した場合には一度ファイ
Cluster
Cluster
信以外の保存時間に制約がない場合は TCP を利用し完全
Cluster
にファイルを保存できるようにする．
Cluster
Cluster
チャンクサーバ 72台
3.4.2
TCP のみを用いた保存方式の設計
図 4: 評価環境
Chunk Generator とチャンクサーバ間の RTT が小さい
時は Chunk Generator とチャンクサーバ間の通信に TCP
を用いる．Chunk Generator はチャンクサーバと TCP コ
表 1: 評価環境における各マシン性能一覧
ネクションを予め確立しておく．
3.5
実装
マシン
CPU
Memory
OS
Chunk Generator
Netem マシン
Core i7-3770 @ 3.4GHz
Core i7-3770 @ 3.4GHz
8GB
8GB
CentOS 6.3
CentOS 6.3
チャンクサーバ (72 台)
Pentium G640 @ 2.8GHz
16GB
CentOS 6.3
Chunk Generator を以下のように実装した．
4.1
1. チャンクサーバの台数が増加した場合でも書き込みの
スループットが低下しないように Client からの書き
評価環境
本評価では Chunk Generator，72 台のチャンクサーバ，
込み要求ごとにスレッドを 1 つのみ生起する．またス
ネットワーク状況をエミュレートするためのネットワーク
レッド数を管理することで同時送信ファイル数を制御
エミュレートマシン（NetEm マシン）の 3 つのモジュール
することができる．
を使用する．チャンクサーバを慶應義塾大学デジタルメディ
2. UDP は相手の状態を確認せずに送信するため，送信
ア統合研究センター（拠点 A）に設置し，Chunk Generator
の速度が速すぎると受信側のバッファがいっぱいにな
と NetEm マシンを慶應義塾大学矢上キャンパス（拠点 B）
り，パケットロスの判定になる．そのため UDP を利
に設置する．評価環境を図 4 に示し，各マシンの性能を表 1
用したチャンク転送では，転送レートを指定できるよ
に示す．今回の評価環境では Chunk Generator から各チャ
うにする．
ンクサーバまでの RTT は 5msec であり，ネットワークの
パケットロス率は 0%である．しかし，インターネット環境
3. TCP を用いたチャンク転送をする場合，チャンクサー
を想定した計測をするために NetEm マシンにおいて tc コ
バと確立した TCP コネクションをスレッド間で共有
マンドを用いてネットワークのパケットロス率を 0.01%[7]
して使用する．
に設定する．
4
評価
4.2
本章では，3 章で述べた書き込み方式の設計について評
測定方法
3 章で述べた設計での実装でのスループットと保存するま
でにかかる時間を測定し，TCP と UDP を切り分ける際の
従来方式と特に変更がないため，Chunk Generator とチャ
RTT の目安，同時送信ファイル数の適切な値について評価
ンクサーバ間のデータ転送についてのみ評価していく．
価する．提案方式では，Client と Chunk Generator 間は
4
する．Chunk Generator から 72 台のチャンクサーバへ非圧
6500
6000
縮 Full HD(解像度 1920×1080) の画像ファイル（6.22MB）
5500
を 100 回転送し終わるまでの合計時間とそれぞれの転送時
0.9
throughput
send time
0.8
間を測定し，平均スループットと 1 ファイル転送するのに
かかる時間のばらつき，UDP の場合のチャンクサーバでの
パケットロス率を見る．その際のパラメータとして，同時
送信ファイル数，RTT を変化させる．
0.6
4500
4000
0.5
3500
0.4
3000
0.3
2500
0.2
2000
ファイルの冗長率は Content Espresso を利用した映像配
0.1
1500
信でよく利用されている 20%で固定する．Client からファ
1000
0
rate100M/100th
rate200M/50th
rate250M/40th
rate500M/20th
rate1G/10th
4.3.1
rate2G/5th
Generator のメモリに載せておく．
rate2.5G/4th
想定するため，ファイルデータと冗長データは予め Chunk
rate5G/2th
rate10G/1th
イルデータが届き，冗長データを作り終わった後の状況を
4.3
sendTime (sec)
throughput (Mbps)
0.7
5000
図 5: チャンクサーバ 72 台の時の UDP 転送による平均
性能測定
スループットと 1 ファイル転送するのにかかる時間のばら
つき
UDP を利用した分散保存
NetEm マシンにおいて Chunk Generator とチャンクサー
バ間に遅延を設定しない場合（5msec）， Chunk Generator
るが，平均スループットが他の値に比べて高い値になって
の平均スループットと 1 ファイル転送時間を UDP を利用
いる．
した方式で 100 回連続計測した．UDP には輻輳制御機能が
計測時のチャンクサーバにおいて，全体のファイルサイ
ないため，UDP を利用した方式ではチャンク送信レートを
ズの何%のパケットがロスしているかを図 6 に示す．これ
指定する必要がある．今回の計測では，各スレッドごとの
よりチャンク送信レートが 100Mbps の時だけが 25% 以上
チャンク送信レートを 10Gbps，5Gbps，2.5Gbps，2Gbps，の割合で 11% 以上のデータがロスしている．このことよ
1Gbps，500Mbps，250Mbps，200Mbps，100Mbps とし，り送信レートを下げて同時送信ファイル数を増やしたとし
スレッド数をチャンク送信レート × スレッド数が 10Gbps ても，パケットロスが多く発生してしまうため，同時送信
ファイル数は制限すべきである．
になるように設定した．
図 6 のチャンク送信レート 100Mbps を取り除いたもの
この時の平均スループット (Mbps) 及び転送時間 (sec) の
ばらつきを図 5 に示す．平均スループットは赤十字でプロッを図 7 に示す．この図より全ての項目でパケットロスの割
トし，転送時間のばらつきを青の箱ひげ図で示した．x 軸に合が 0.5% より低いことがわかり，冗長率を 20% としてい
各 UDP のチャンク送信レートとスレッド数の項目を示し
る今回では，クライアント側で合計 10 ％ほどのパケット
た．箱ひげ図は箱の下辺が第 1 四分位点で，箱の上辺が第
ロスならば，十分に損失パケットを回復する事ができるた
3 四分位点，箱の中に辺が中央値である．図 5 よりチャンクめ，今回の項目では送信レートが 100Mbps 以外のものは
送信レートが 10Gbps の時と 5Gbps の時は要求したレート有向である．
今回の環境下において UDP を利用した分割分散保存す
に対して平均スループットが全く出ていない．これは高い
送信レートを設定した時に送信レートの制御がされていな
る際はチャンク送信レートを 2.5Gbps から 1Gbps の間に
かったことが原因である．つまり，チャンク送信レートを高
設定し，同時送信するファイル数を 10 以下にするのが最
く設定しすぎても送信レートの制御はされずスループット
も良い．
が低くなることが言える．チャンク送信レートが 2.5Gbps，
2Gbps，1Gbps の時では，平均スループットは 5Gbps 程
4.3.2
度出ており，この値は非圧縮 Full HD 画質のライブ配信が
TCP を利用した分散保存時間
約 4 チャネル同時できる値である．また 1 ファイル送るの
TCP の場合も UDP と同じく，Chunk Generator とチャ
にかかる時間のばらつきも 0.1sec 以下で収まっている．こ
ンクサーバ間の RTT を NetEm マシンで何も変更しない
れより，チャンク送信レートを 2.5Gbps から 1Gbps の間
時 (5msec) の各スレッド数ごとの Chunk Generator の平
に設定し，スレッド数を 4 から 10 の間に設定すれば，遅
均スループットと 1 ファイル転送するのにかかった時間の
延時間を小さくすることができる．チャンク送信レートが
100 回のばらつき結果を図 8 に示す．これよりスレッド数
20 ぐらいのところまでは 1 ファイル送るのにかかる時間
100Mbps の場合，1 ファイル送信する時間は長くなってい
5
18
7000
16
6500
throughput
send time
1
10
8
6
4
2
5500
0.6
5000
0.4
4500
sendTime (sec)
0.8
6000
12
throughput (Mbps)
total loss data (%)
14
4000
0
rate100M/100th
rate200M/50th
rate250M/40th
rate500M/20th
rate1G/10th
rate2G/5th
rate2.5G/4th
rate5G/2th
rate10G/1th
0.2
3500
3000
0
20
40
60
80
0
100
nThread
図 6: チャンクサーバ 72 台の時の UDP 転送によるファイ
図 8: チャンクサーバ 72 台の時の TCP 転送による平均ス
ル全体に対してのパケットロスの割合のばらつき
ループットと 1 ファイル転送するのにかかる時間のばらつき
0.5
4.3.3
total loss data (%)
0.4
UDP と TCP の比較
UDP と TCP のそれぞれを用いた書き込みの平均スルー
プットが高くなるパラメータと遅延時間が短くなるパラメー
0.3
タがわかったので，両者を比較してみる．UDP と TCP
0.2
のそれぞれの方式についての平均スループットを Chunk
0.1
Generator とチャンクサーバの RTT を NetEm マシンを
用いて変化させた時の結果を図 9 に示す．この時 UDP は
4.3.1 項で性能が良かった要求レート 2.5Gbps の 4 スレッ
0
rate200M/50th
rate250M/40th
rate500M/20th
rate1G/10th
rate2G/5th
rate2.5G/4th
rate5G/2th
rate10G/1th
ド，2Gbps の 5 スレッド，1Gbps の 10 スレッドを，TCP
は 4.3.2 項で性能が良かった 20 スレッドと 100 スレッド
の 5 つ項目を比較した．図を見ると RTT が 7msec の時に
UDP と TCP のスループットの差は逆転し UDP の方が速
図 7: チャンクサーバ 72 台の時の UDP 転送によるファイ
くなる．それ以降の RTT の時は UDP の方がスループット
ル全体に対してのパケットロスの割合のばらつき 2
が高くなっている．以上のことから今回の様なネットワー
クのパケットロス率が低く安定している環境下の場合 RTT
のばらつきはあまりなく，すべて 0.2sec 以内となっている．
スレッド数が 20 以上ではばらつきが大きくなり，スレッド
が 7msec 未満の時は TCP を，RTT が 7msec 以上の時は
UDP を利用して分散保存するべきであると言える．
数が約 80 になると，1 ファイル送るのにかかる時間は大
きな値に収束する．一方で平均スループットは，スレッド
5
数を増やせば増やすほど高くなる傾向にある．これは TCP
おわりに
が複数の要求に対してうまく制御をできるプロトコルだか
本稿では，Content Espresso の保存部分に着目し，ライ
らである．スレッド数を 100 にした時にスループットは約
ブ配信を可能とする高速な分散保存手法について述べた．今
6.5Gbps 出ていて，この値は非圧縮 Full HD 画質のライブ回の環境下においては Chunk Generator とチャンクサーバ
配信が約 5 チャネル同時にできる値である．以上のことか間の RTT が 7msec 未満の時は TCP を用いて同時に 20
ら今回の環境下において TCP を用いて分割分散保存するファイルの書き込みまで，7msec 以上の時は UDP を用いて
際は，遅延時間を短くしたい場合にはスレッド数を 20 程
要求レートが 2.5Gbps から 1Gbps 同時に 4 から 10 ファイ
度に止め，使用可能帯域を十分に使用する場合には一度に
ルの分散保存が平均スループットが高くなり分散保存が完
可能な数のファイルを送信したほうが効率がよいと言える．了するまでにかかる遅延時間を 0.1msec 以下になるという
ことを示した．広域分散を想定している Content Espresso
6
7000
6000
throughput (Mbps)
SIGCOMM ’98, pages 303–314, New York, NY, USA,
1998. ACM.
TCP nThread: 20
TCP nThread: 100
UDP sendRate:1000 nThread:10
UDP sendRate:2000 nThread:5
UDP sendRate:2500 nThread:4
[7] Iij packetloss sla. http://www.iij.ad.jp/svcsol/
sla/packetloss/.
5000
4000
3000
2000
1000
0
0
10
20
30
40
50
60
70
80
90
100
RTT (ms)
図 9: チャンクサーバ 72 台の時の RTT による UDP と
TCP 平均スループット
では UDP を用いたチャンク転送方式は有用であったとい
える．
今後の課題としてチャンクサーバの台数やファイルサイ
ズが変化した時の評価，書き込みと読み込みが同時に発生
する場合の評価を予定している．
参考文献
[1] Youtube. http://www.youtube.com.
[2] Ustream. http://www.ustream.tv.
[3] Twitcasting. http://twitcasting.tv.
[4] D. Ando, M. Kitamura, F. Teraoka, and K. Kaneko.
Content espresso: A system for large file sharing using
globally dispersed storage. In Proceedings of IEEE 5th
International Conference on Cloud Computing Technology and Science (CloudCom), volume 2, pages 337–
340, Dec 2013.
[5] M Kitamura, D Shirai, Y Tonomura, and T Fujii. A
study on the parallelized encoding of ldgm for the robust streamings of super high definition videos. IEICE
Technical Report. Communication Systems, pages 37–
42, sep 2007.
[6] J. Padhye, V Firoiu, D Towsley, and J Kurose. Modeling tcp throughput: A simple model and its empirical validation. In Proceedings of the ACM SIGCOMM
’98 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication,
7

Download Report