デジタルコンテンツの安定配信とコスト削減の両立を実現したシステム刷新

株式会社DMM.comラボ渡辺宣彦
デジタルコンテンツの安定配信と
コスト削減の両立を実現したシステム刷新
1
アプリケーション・パフォーマンス
2017

View Slide

Copyright © since 2017 DMM All Rights Reserved. 2
Topics
1. はじめに
2. 初期をふりかえる
3. x86サーバｘ200
4. マルチデバイス対応とGlusterFS導入の経緯
5. Linuxへの完全移行
6. ストリーミング配信基盤改善
7. 負荷対策方法の確立
8. まとめ

View Slide

1. はじめに

View Slide

DMM.comにおける動画配信
DMM.comの動画や電子書籍といった
デジタルコンテンツの配信は
古くは2002年から始まっており
ロングテール型サービス提供のため
コンテンツ数は年々増え続けています
今回は動画配信のサービス開始から
現在に至るまでに行ってきた
システムの変遷や改善点について
ご説明させていただきたいと思います

View Slide

タイトル数３０万タイトル超
ロングテール型
さまざまな対応デバイス
PC、スマートフォン、VR作品も展開
年間1PBのペースで増え続けるコンテンツ
6TB SATA HDD x 12構成のサーバを使用
動画コンテンツの特徴

View Slide

オリジンサーバ
コンテンツファイルが格納されているサーバ
エッジキャッシュ
エンドユーザーが直接アクセスする
リバースプロキシとしての役割を持つ
ミドルキャッシュ
エッジキャッシュとオリジンサーバの間に位置する
オリジンへのアクセス数を限定させる役割を持つ
本書で記載されている用語について

View Slide

2. 初期をふりかえる
(2002～2007)

View Slide

Copyright © since 2017 DMM All Rights Reserved.
サービス開始当初の特徴
DAS＋Windows Serverの組み合わせ
複数のストレージから運用
ダウンロードはIIS
ストリーミングはWindows Media Service
同じコンテンツをダウンロード用、ストリーミング用に
それぞれストレージを分けて保持
8

View Slide

DASへの増設を週1回のペースで実施しており
運用面の負担が増えてきていた
空き容量、利用状況など管理面でも
負担がかかってきていたため
ストレージ環境再構築の検討に入った
当時をふりかえると
クラスタストレージの導入へ

View Slide

丸一日要していた拡張作業が数時間程度に短縮
RAIDよりも信頼性が向上した
集中管理されるため、管理工数も削減できた
ストレージ導入で得られたメリット

View Slide

導入後をふりかえると
すべていいことづくめだったわけではなく
想定よりも性能が出ず、解消しないケースもあった
ストレージ機能においてバグを引いた際
影響範囲が全体に拡大してしまったため
ストレージを分散してリスクヘッジ

View Slide

影響範囲を限定できる仕組みが可能か
コンテンツ制作側の作業フローも考慮する必要あり
ハードウェアのコスト削減
（アクセスの頻度によっては
全体的にGBあたりのコストが高くなってしまうため）
12
次への検討項目
クラスタストレージのリプレイスを実施

View Slide

3. x86サーバｘ200台
(2010～2012)

View Slide

ストレージで負荷を捌かず前段で吸収する仕組みへ
障害範囲を限定できるような構成
負荷対策もサーバーごとに実施しやすくなる
イニシャル／ランニングともにコスト削減効果が得られた
14
目指したところとその理由

View Slide

Copyright © since 2017 DMM All Rights Reserved.
15
X86サーバへコンテンツの移行を行う
SATA HDDを12本搭載した２Uモデルのサーバを採用
Diskの故障率上昇に備えて12本中2本を
HotSpareに設定
15
脱クラスタストレージ

View Slide

キャッシュサーバのスケールアップを実施
SATA HDDを12本（オリジンサーバと同様）
メモリを128GB積んだサーバを使用
事前にアクセス集中を把握できているものに関しては
オリジンサーバへのアクセスを抑えることができた
16
性能面についても考慮
しかし、ここで3つの問題点が浮かび上がってきた

View Slide

1. 増え続ける単一障害点
2. 統一されたHWで発生した重大なバグ
3. 1Gbのネットワークがボトルネックに
3つの問題点とは・・・

View Slide

コンテンツをサーバで冗長化するには
要するサーバの台数も2倍になってしまうため
ファイルアップロードに要する時間も2倍に
運用面でも現実的ではなかった
HWの制約によって空きポートがなく
チーミング不可能（※増設するPCIの空きもない）
ユーザー影響のあるハードウェア起因の障害が増加
①単一障害点となってしまったこと

View Slide

RAIDコントローラのファームウェアで
バグを引き「予期しないシャットダウン」や
カーネルパニックが100台以上で周期的に発生
使用するHDDのファームウェアでも
バグを引いてしまい、一斉に障害検知されたり
リビルドが正常に完了しないことも
改善しないファームウェアのバグと3年近く格闘
②HWがほぼ統一されたことによる弊害

View Slide

リリース時やキャンペーンで集中するアクセス
（ダウンロードは特に接続が長時間滞留する）
コンテンツの高精細化が進み
従来よりもファイルサイズが肥大していった
上記によってダウンロード速度遅延の問題も頻発
1Gbpsのネットワークでは限界に到達していた
③スペック不足

View Slide

4. マルチデバイス対応と
GlusterFS導入の経緯
(2013～)

View Slide

マルチデバイス対応によって
PCとスマホなど複数デバイスへMP4をベースに配信
従来、冗長構成されていないサーバ単体を
オリジンストレージとして運用していたため
PC向けのストリーミングが加わり
トラフィックが急増することに
マルチデバイス対応について

View Slide

Backendのトラフィックが1Gbpsを超えるため
サーバー単位で冗長構成を担保しつつ
スループットにおいてもある程度要求されていた
ハードウェア、ソフトウェアそれぞれの
費用対効果を考慮
オリジン強化の必要性

View Slide

2012年に初めてGlusterFSを
Striping Volumeの10台構成で試験的に導入
GlusterFSの導入
Striping Volume
性能、使い勝手も良好
Apache+GlusterFS

View Slide

クラスタストレージをGlusterFSへ移行
配信サーバにFuseでマウント
Distributed Replica構成のGlusterFS
GlusterFSの導入
Distributed Replica Volume
Backendはすべて10Gbps対応

View Slide

GlusterFSは特性上
ディレクトリやファイルのリスト取得を
苦手としているため
コンテンツ制作側のファイル操作に難があった
適当なサイジングで
ボリュームを作成する必要が出てきた
26
次への検討項目

View Slide

5. Linuxへの完全移行
(2014～2015)

View Slide

2015年7月15日(日本時間)
Windows Server 2003と
WMDRMのサーバSDKサポート終了に伴い
Windows Media Playerでの
ライセンス認証も行えなくなることに
・・・これがどのような影響を及ぼしたのか？

View Slide

Windows Server 2003をリプレイスする必要がある
→2014年時点で200台まで増えていた
Windows Media Player経由のストリーミングが不可に
→WMVに変わるストリーミング素材としてMP4を用意
2PBのデータ移動ならびにMP4作成
29
ほぼ、配信基盤全体のリプレイスに匹敵
膨大な影響範囲

View Slide

期限がこれ以上ないほど明確なため
コンテンツのコピー移動やエンコード遅延による
延期は許容されない
検証だけにじっくり時間を割くことはできず
次世代の配信サーバを決定しなければならない
30
Windows 2008の選択肢も当然あったものの・・・
OSサポート終了が与えたインパクト

View Slide

実績を積んでいたGlusterFSで完全冗長構成に
ハードウェアも過去のナレッジを活かして選定し
マルチベンダーでの調達を行った
ネットワークの増強も合わせて実施し
全て10Gのネットワークで構成
31
2015年7月に大きなトラブルなく完了
問題点を解消することに全力を注いだ

View Slide

ダウンロードサーバをすべてGlusterFSへ移行
IISからApacheへ
GlusterFSの導入
Apache+GlusterFS
Replica
Volume
Apache+GlusterFS
Replica
Volume
すべて10Gbpsネットワーク
GlusterFS Replica 2

View Slide

GlusterFSの導入のメリットとして
複数台からなるオリジンサーバの構成によって
問題なく配信できる結果を得られた
GlusterFSの導入
リリース1分後
22.36Gbps

View Slide

キャンペーン用負荷対策サーバもGlusterFSで
GlusterFSの導入
名前用途備考
PicsMaster 画像マスター Redhat Gluster Storage
TV用Gluster ファイルサーバ
MP4用Gluster ファイルサーバ
動画CP用負荷対策Gluster DLサーバ
スマホDL用Gluster DLサーバ
増設する工数もさらに削減！

View Slide

6. ストリーミング基盤改善
(2016～)

View Slide

SATA HDDをメインで使用していることもあり
1ノードにつき3Gbps程度で限界に到達
2012年から構築を行ってきたGlusterFSは
すでに150ボリュームほどに構築数が増えたため
構築時期とバージョンの差により
管理上の問題が起きはじめていた
GlusterFSの課題
このあたり解決できるストレージを模索していた

View Slide

PB規模のストレージでも
運用上、特に問題となるような事象が起きなかった
台数ごとにおけるデータ利用効率が従来より上がった
GlusterFS (1.3PB) vs Scality RING (2PB)
ライセンスが容量単位の精度になっていたこと
Scality RINGの導入理由
2016年7月より本番投入を開始

View Slide

38
ScalityRINGの導入後
現在2PBのボリューム
48ノードで運用中
負荷対策専用の
ストレージを用意せず
キャンペーンを
乗り切ることが可能に
ScalityRINGをマウントした
Fuse Connectorを
Streaming Serverとして使用
既存のストレージ群と接続し
コンテンツ管理を行うため
CIFS Connectorを用意

View Slide

Scalityの性能
RINGノードからのトラフィックも60Gbpsを
超えており、安定稼働中
66.02Gbps

View Slide

7. 負荷対策方法の確立
(2016～)

View Slide

オリジンサーバはDisk性能に制約があるものの
コンテンツは増え続けるため
全てをSSD化することは非現実的(コスト的にも)
コンテンツの高精細化により
ファイルサイズが肥大化しており
キャッシュサーバの設計見直しは必須要件だった
キャッシュサーバの改善

View Slide

キャッシュ効率の向上
大容量SSD導入後
In平均↓ 4.13Gbps
大容量SSD導入前
In平均 9.52Gbps
導入前と比較して
キャッシュサーバに
書き込まれる
トラフィックが
9.52Gbps→
4.13Gbps
倍以上の効果

View Slide

キャッシュサーバの構成
オリジン
エッジキャッシュ
ミドルキャッシュ
Apache+GlusterFS
Replica
Volume
エッジキャッシュと
ミドルキャッシュに
大容量SSDを搭載
HDDと比較して
30TB→85TBまで増量

View Slide

細かい
チャンクファイルの
I/Oが生じるため
SATAのHDDでは
15分程度で
限界に到達
パフォーマンス改善例 HDDの場合
CPU
1.4Gbps
CPU iowait timeが50%を超え
スループットが低下する
トラ
フィック

View Slide

Iowaitも上がらず
トラフィックも
順調に推移
2.5Gbpsを
計測
パフォーマンス改善例 SSDの場合
2.5Gbps
Iowaitもほぼ発生せず
2.5Gbps到達
トラ
フィック
CPU

View Slide

新キャッシュサーバの恩恵
通常時の4倍以上のトラフィックが発生しても
キャッシュサーバのみで乗り切ることが可能に
47.58Gbps

View Slide

ライブ配信に代表される
配信する日時が決まっているコンテンツは
ピークで70Gbps以上到達することもあるが
限られるためCDNがフィットしやすい
CDNごとの特徴を把握して
複数から選択できるような構成が理想
CDNとの連携
ある程度柔軟性を持たせる必要がある

View Slide

マルチCDN対応ストリーミング版
オリジン
streaming server
キャッシュ
nginx
各CDNとの連携
ライブ配信や
VODにて稼働中

View Slide

8. まとめ

View Slide

トラフィックの推移
103.1
121.65
151.3
197.35
215.14
0
50
100
150
200
250
2013年 2014年 2015年 2016年 2017年
配信インフラ基盤の変遷
2013/ GlusterFS導入
2014/ 10G化推進
2015/ オリジンリプレイス
2016/ Scality RING導入
単位 Gbps

View Slide

不具合解消の推移
18
6
1
0
4
3
1 1
0
2
4
6
8
10
12
14
16
18
20
2013年 2014年 2015年 2016年
アクセス過多による不具合
サーバ故障に起因する不具合
かねてより問題となっていた
単一障害点の解消や
ボトルネックとなりえる
ハードウェアのリプレイスで
改善の傾向が
顕著に表れている
※あくまでサーバ単体のトラブルとした数字

View Slide

まとめ
最適解はあくまでその時期によるもの
いずれは変わることを念頭に
サービスの安定稼働に例外を持たない
CDN、クラウド、オンプレミス問わず
柔軟な構成を担保する意識を強く持つこと

View Slide

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

View Slide

デジタルコンテンツの安定配信とコスト削減の両立を実現したシステム刷新

デジタルコンテンツの安定配信とコスト削減の両立を実現したシステム刷新

DMM.com

More Decks by DMM.com

Other Decks in Technology

Featured

Transcript