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

2017/09/14開催アプリケーション・パフォーマンス 2017の基調講演にて発表した資料となります。

Transcript

1. 株式会社DMM.comラボ 渡辺宣彦 デジタルコンテンツの安定配信と コスト削減の両立を実現したシステム刷新 1 アプリケーション・パフォーマンス 2017
2. Copyright © since 2017 DMM All Rights Reserved. 2 Topics 1. はじめに 2. 初期をふりかえる 3. x86サーバｘ200 4. マルチデバイス対応とGlusterFS導入の経緯 5. Linuxへの完全移行 6. ストリーミング配信基盤改善 7. 負荷対策方法の確立 8. まとめ
3. Copyright © since 2017 DMM All Rights Reserved. 3 1. はじめに
4. Copyright © since 2017 DMM All Rights Reserved. 4 DMM.comにおける動画配信 DMM.comの動画や電子書籍といった デジタルコンテンツの配信は 古くは2002年から始まっており ロングテール型サービス提供のため コンテンツ数は年々増え続けています 今回は動画配信のサービス開始から 現在に至るまでに行ってきた システムの変遷や改善点について ご説明させていただきたいと思います
5. Copyright © since 2017 DMM All Rights Reserved. 5 タイトル数３０万タイトル超 ロングテール型 さまざまな対応デバイス PC、スマートフォン、VR作品も展開 年間1PBのペースで増え続けるコンテンツ 6TB SATA HDD x 12構成のサーバを使用 動画コンテンツの特徴
6. Copyright © since 2017 DMM All Rights Reserved. 6 オリジンサーバ コンテンツファイルが格納されているサーバ エッジキャッシュ エンドユーザーが直接アクセスする リバースプロキシとしての役割を持つ ミドルキャッシュ エッジキャッシュとオリジンサーバの間に位置する オリジンへのアクセス数を限定させる役割を持つ 本書で記載されている用語について
7. Copyright © since 2017 DMM All Rights Reserved. 7 2. 初期をふりかえる (2002～2007)
8. Copyright © since 2017 DMM All Rights Reserved. サービス開始当初の特徴 DAS＋Windows Serverの組み合わせ 複数のストレージから運用 ダウンロードはIIS ストリーミングはWindows Media Service 同じコンテンツをダウンロード用、ストリーミング用に それぞれストレージを分けて保持 8
9. Copyright © since 2017 DMM All Rights Reserved. 9 DASへの増設を週1回のペースで実施しており 運用面の負担が増えてきていた 空き容量、利用状況など管理面でも 負担がかかってきていたため ストレージ環境再構築の検討に入った 当時をふりかえると クラスタストレージの導入へ
10. Copyright © since 2017 DMM All Rights Reserved. 10 丸一日要していた拡張作業が数時間程度に短縮 RAIDよりも信頼性が向上した 集中管理されるため、管理工数も削減できた ストレージ導入で得られたメリット
11. Copyright © since 2017 DMM All Rights Reserved. 11 導入後をふりかえると すべていいことづくめだったわけではなく 想定よりも性能が出ず、解消しないケースもあった ストレージ機能においてバグを引いた際 影響範囲が全体に拡大してしまったため ストレージを分散してリスクヘッジ
12. Copyright © since 2017 DMM All Rights Reserved. 12 影響範囲を限定できる仕組みが可能か コンテンツ制作側の作業フローも考慮する必要あり ハードウェアのコスト削減 （アクセスの頻度によっては 全体的にGBあたりのコストが高くなってしまうため） 12 次への検討項目 クラスタストレージのリプレイスを実施
13. Copyright © since 2017 DMM All Rights Reserved. 13 3. x86サーバｘ200台 (2010～2012)
14. Copyright © since 2017 DMM All Rights Reserved. 14 ストレージで負荷を捌かず前段で吸収する仕組みへ 障害範囲を限定できるような構成 負荷対策もサーバーごとに実施しやすくなる イニシャル／ランニングともにコスト削減効果が得られた 14 目指したところとその理由
15. Copyright © since 2017 DMM All Rights Reserved. 15 X86サーバへコンテンツの移行を行う SATA HDDを12本搭載した２Uモデルのサーバを採用 Diskの故障率上昇に備えて12本中2本を HotSpareに設定 15 脱クラスタストレージ
16. Copyright © since 2017 DMM All Rights Reserved. 16 キャッシュサーバのスケールアップを実施 SATA HDDを12本（オリジンサーバと同様） メモリを128GB積んだサーバを使用 事前にアクセス集中を把握できているものに関しては オリジンサーバへのアクセスを抑えることができた 16 性能面についても考慮 しかし、ここで3つの問題点が浮かび上がってきた
17. Copyright © since 2017 DMM All Rights Reserved. 17 1. 増え続ける単一障害点 2. 統一されたHWで発生した重大なバグ 3. 1Gbのネットワークがボトルネックに 3つの問題点とは・・・
18. Copyright © since 2017 DMM All Rights Reserved. 18 コンテンツをサーバで冗長化するには 要するサーバの台数も2倍になってしまうため ファイルアップロードに要する時間も2倍に 運用面でも現実的ではなかった HWの制約によって空きポートがなく チーミング不可能（※増設するPCIの空きもない） ユーザー影響のあるハードウェア起因の障害が増加 ①単一障害点となってしまったこと
19. Copyright © since 2017 DMM All Rights Reserved. 19 RAIDコントローラのファームウェアで バグを引き「予期しないシャットダウン」や カーネルパニックが100台以上で周期的に発生 使用するHDDのファームウェアでも バグを引いてしまい、一斉に障害検知されたり リビルドが正常に完了しないことも 改善しないファームウェアのバグと3年近く格闘 ②HWがほぼ統一されたことによる弊害
20. Copyright © since 2017 DMM All Rights Reserved. 20 リリース時やキャンペーンで集中するアクセス （ダウンロードは特に接続が長時間滞留する） コンテンツの高精細化が進み 従来よりもファイルサイズが肥大していった 上記によってダウンロード速度遅延の問題も頻発 1Gbpsのネットワークでは限界に到達していた ③スペック不足
21. Copyright © since 2017 DMM All Rights Reserved. 21 4. マルチデバイス対応と GlusterFS導入の経緯 (2013～)
22. Copyright © since 2017 DMM All Rights Reserved. 22 マルチデバイス対応によって PCとスマホなど複数デバイスへMP4をベースに配信 従来、冗長構成されていないサーバ単体を オリジンストレージとして運用していたため PC向けのストリーミングが加わり トラフィックが急増することに マルチデバイス対応について
23. Copyright © since 2017 DMM All Rights Reserved. 23 Backendのトラフィックが1Gbpsを超えるため サーバー単位で冗長構成を担保しつつ スループットにおいてもある程度要求されていた ハードウェア、ソフトウェアそれぞれの 費用対効果を考慮 オリジン強化の必要性
24. Copyright © since 2017 DMM All Rights Reserved. 24 2012年に初めてGlusterFSを Striping Volumeの10台構成で試験的に導入 GlusterFSの導入 Striping Volume 性能、使い勝手も良好 Apache+GlusterFS
25. Copyright © since 2017 DMM All Rights Reserved. 25 クラスタストレージをGlusterFSへ移行 配信サーバにFuseでマウント Distributed Replica構成のGlusterFS GlusterFSの導入 Distributed Replica Volume Backendはすべて10Gbps対応
26. Copyright © since 2017 DMM All Rights Reserved. 26 GlusterFSは特性上 ディレクトリやファイルのリスト取得を 苦手としているため コンテンツ制作側のファイル操作に難があった 適当なサイジングで ボリュームを作成する必要が出てきた 26 次への検討項目
27. Copyright © since 2017 DMM All Rights Reserved. 27 5. Linuxへの完全移行 (2014～2015)
28. Copyright © since 2017 DMM All Rights Reserved. 28 2015年7月15日(日本時間) Windows Server 2003と WMDRMのサーバSDKサポート終了に伴い Windows Media Playerでの ライセンス認証も行えなくなることに ・・・これがどのような影響を及ぼしたのか？
29. Copyright © since 2017 DMM All Rights Reserved. 29 Windows Server 2003をリプレイスする必要がある →2014年時点で200台まで増えていた Windows Media Player経由のストリーミングが不可に →WMVに変わるストリーミング素材としてMP4を用意 2PBのデータ移動ならびにMP4作成 29 ほぼ、配信基盤全体のリプレイスに匹敵 膨大な影響範囲
30. Copyright © since 2017 DMM All Rights Reserved. 30 期限がこれ以上ないほど明確なため コンテンツのコピー移動やエンコード遅延による 延期は許容されない 検証だけにじっくり時間を割くことはできず 次世代の配信サーバを決定しなければならない 30 Windows 2008の選択肢も当然あったものの・・・ OSサポート終了が与えたインパクト
31. Copyright © since 2017 DMM All Rights Reserved. 31 実績を積んでいたGlusterFSで完全冗長構成に ハードウェアも過去のナレッジを活かして選定し マルチベンダーでの調達を行った ネットワークの増強も合わせて実施し 全て10Gのネットワークで構成 31 2015年7月に大きなトラブルなく完了 問題点を解消することに全力を注いだ
32. Copyright © since 2017 DMM All Rights Reserved. 32 ダウンロードサーバをすべてGlusterFSへ移行 IISからApacheへ GlusterFSの導入 Apache+GlusterFS Replica Volume Apache+GlusterFS Replica Volume すべて10Gbpsネットワーク GlusterFS Replica 2
33. Copyright © since 2017 DMM All Rights Reserved. 33 GlusterFSの導入のメリットとして 複数台からなるオリジンサーバの構成によって 問題なく配信できる結果を得られた GlusterFSの導入 リリース1分後 22.36Gbps
34. Copyright © since 2017 DMM All Rights Reserved. 34 キャンペーン用負荷対策サーバもGlusterFSで GlusterFSの導入 名前 用途 備考 PicsMaster 画像マスター Redhat Gluster Storage TV用Gluster ファイルサーバ MP4用Gluster ファイルサーバ 動画CP用負荷対策Gluster DLサーバ スマホDL用Gluster DLサーバ 増設する工数もさらに削減！
35. Copyright © since 2017 DMM All Rights Reserved. 35 6. ストリーミング基盤改善 (2016～)
36. Copyright © since 2017 DMM All Rights Reserved. 36 SATA HDDをメインで使用していることもあり 1ノードにつき3Gbps程度で限界に到達 2012年から構築を行ってきたGlusterFSは すでに150ボリュームほどに構築数が増えたため 構築時期とバージョンの差により 管理上の問題が起きはじめていた GlusterFSの課題 このあたり解決できるストレージを模索していた
37. Copyright © since 2017 DMM All Rights Reserved. 37 PB規模のストレージでも 運用上、特に問題となるような事象が起きなかった 台数ごとにおけるデータ利用効率が従来より上がった GlusterFS (1.3PB) vs Scality RING (2PB) ライセンスが容量単位の精度になっていたこと Scality RINGの導入理由 2016年7月より本番投入を開始
38. Copyright © since 2017 DMM All Rights Reserved. 38 38 ScalityRINGの導入後 現在2PBのボリューム 48ノードで運用中 負荷対策専用の ストレージを用意せず キャンペーンを 乗り切ることが可能に ScalityRINGをマウントした Fuse Connectorを Streaming Serverとして使用 既存のストレージ群と接続し コンテンツ管理を行うため CIFS Connectorを用意
39. Copyright © since 2017 DMM All Rights Reserved. 39 Scalityの性能 RINGノードからのトラフィックも60Gbpsを 超えており、安定稼働中 66.02Gbps
40. Copyright © since 2017 DMM All Rights Reserved. 40 7. 負荷対策方法の確立 (2016～)
41. Copyright © since 2017 DMM All Rights Reserved. 41 オリジンサーバはDisk性能に制約があるものの コンテンツは増え続けるため 全てをSSD化することは非現実的(コスト的にも) コンテンツの高精細化により ファイルサイズが肥大化しており キャッシュサーバの設計見直しは必須要件だった キャッシュサーバの改善
42. Copyright © since 2017 DMM All Rights Reserved. 42 キャッシュ効率の向上 大容量SSD導入後 In平均↓ 4.13Gbps 大容量SSD導入前 In平均 9.52Gbps 導入前と比較して キャッシュサーバに 書き込まれる トラフィックが 9.52Gbps→ 4.13Gbps 倍以上の効果
43. Copyright © since 2017 DMM All Rights Reserved. 43 キャッシュサーバの構成 オリジン エッジキャッシュ ミドルキャッシュ Apache+GlusterFS Replica Volume エッジキャッシュと ミドルキャッシュに 大容量SSDを搭載 HDDと比較して 30TB→85TBまで増量
44. Copyright © since 2017 DMM All Rights Reserved. 44 細かい チャンクファイルの I/Oが生じるため SATAのHDDでは 15分程度で 限界に到達 パフォーマンス改善例 HDDの場合 CPU 1.4Gbps CPU iowait timeが50%を超え スループットが低下する トラ フィック
45. Copyright © since 2017 DMM All Rights Reserved. 45 Iowaitも上がらず トラフィックも 順調に推移 2.5Gbpsを 計測 パフォーマンス改善例 SSDの場合 2.5Gbps Iowaitもほぼ発生せず 2.5Gbps到達 トラ フィック CPU
46. Copyright © since 2017 DMM All Rights Reserved. 46 新キャッシュサーバの恩恵 通常時の4倍以上のトラフィックが発生しても キャッシュサーバのみで乗り切ることが可能に 47.58Gbps
47. Copyright © since 2017 DMM All Rights Reserved. 47 ライブ配信に代表される 配信する日時が決まっているコンテンツは ピークで70Gbps以上到達することもあるが 限られるためCDNがフィットしやすい CDNごとの特徴を把握して 複数から選択できるような構成が理想 CDNとの連携 ある程度柔軟性を持たせる必要がある
48. Copyright © since 2017 DMM All Rights Reserved. 48 マルチCDN対応 ストリーミング版 オリジン streaming server キャッシュ nginx 各CDNとの連携 ライブ配信や VODにて稼働中
49. Copyright © since 2017 DMM All Rights Reserved. 49 8. まとめ
50. Copyright © since 2017 DMM All Rights Reserved. 50 トラフィックの推移 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
51. Copyright © since 2017 DMM All Rights Reserved. 51 不具合解消の推移 18 6 1 0 4 3 1 1 0 2 4 6 8 10 12 14 16 18 20 2013年 2014年 2015年 2016年 アクセス過多による不具合 サーバ故障に起因する不具合 かねてより問題となっていた 単一障害点の解消や ボトルネックとなりえる ハードウェアのリプレイスで 改善の傾向が 顕著に表れている ※あくまでサーバ単体のトラブルとした数字
52. Copyright © since 2017 DMM All Rights Reserved. 52 まとめ 最適解はあくまでその時期によるもの いずれは変わることを念頭に サービスの安定稼働に例外を持たない CDN、クラウド、オンプレミス問わず 柔軟な構成を担保する意識を強く持つこと
53. ご清聴ありがとうございました