Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
デジタルコンテンツの安定配信とコスト削減の両立を実現したシステム刷新
Search
DMM.com
September 20, 2017
Technology
1
2.6k
デジタルコンテンツの安定配信とコスト削減の両立を実現したシステム刷新
2017/09/14開催アプリケーション・パフォーマンス 2017の基調講演にて発表した資料となります。
DMM.com
September 20, 2017
Tweet
Share
More Decks by DMM.com
See All by DMM.com
Neo4j with Spark for Big Data Analysis
dmmlabo
1
530
P3インスタンスではじめるDeep Learningと画像レコメンド
dmmlabo
2
3.3k
DMM.comのサービス開発におけるGitHub Enterprise活用の舞台裏
dmmlabo
2
990
Digdagを導入してみて
dmmlabo
9
4.1k
DMM.comラボにおける Scality Ring 活⽤事例
dmmlabo
0
1.1k
DMM CM AWAEDS におけるフロントエンド技術選定について
dmmlabo
1
1.4k
エンジニアのパフォーマンス・モチベーション管理
dmmlabo
1
1.4k
DMMに於ける技術導入はじめの一歩
dmmlabo
1
1.3k
AWSエンジニアがオンプレミスと対峙するとき
dmmlabo
2
5.6k
Other Decks in Technology
See All in Technology
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
350
経理出身PdMがAIプロダクト開発を_ハンズオンで学んだ話.pdf
shunsukenarita
1
140
RapidPen: AIエージェントによる高度なペネトレーションテスト自動化の研究開発
laysakura
1
390
PdM業務における使い分け
shinshiro
0
590
SAE J1939シミュレーション環境構築
daikiokazaki
0
160
Shadow DOM & Security - Exploring the boundary between light and shadow
masatokinugawa
0
670
分散トレーシングによる コネクティッドカーのデータ処理見える化の試み
thatsdone
0
240
From Live Coding to Vibe Coding with Firebase Studio
firebasethailand
1
160
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
160
20250718_ITSurf_“Bet AI”を支える文化とコストマネジメント
helosshi
1
210
手動からの解放!!Strands Agents で実現する総合テスト自動化
ideaws
2
310
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
170
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1k
How STYLIGHT went responsive
nonsquared
100
5.6k
Done Done
chrislema
184
16k
Site-Speed That Sticks
csswizardry
10
720
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
How to Ace a Technical Interview
jacobian
278
23k
Into the Great Unknown - MozCon
thekraken
40
1.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
282
13k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.2k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Transcript
株式会社DMM.comラボ 渡辺宣彦 デジタルコンテンツの安定配信と コスト削減の両立を実現したシステム刷新 1 アプリケーション・パフォーマンス 2017
Copyright © since 2017 DMM All Rights Reserved. 2 Topics
1. はじめに 2. 初期をふりかえる 3. x86サーバx200 4. マルチデバイス対応とGlusterFS導入の経緯 5. Linuxへの完全移行 6. ストリーミング配信基盤改善 7. 負荷対策方法の確立 8. まとめ
Copyright © since 2017 DMM All Rights Reserved. 3 1.
はじめに
Copyright © since 2017 DMM All Rights Reserved. 4 DMM.comにおける動画配信
DMM.comの動画や電子書籍といった デジタルコンテンツの配信は 古くは2002年から始まっており ロングテール型サービス提供のため コンテンツ数は年々増え続けています 今回は動画配信のサービス開始から 現在に至るまでに行ってきた システムの変遷や改善点について ご説明させていただきたいと思います
Copyright © since 2017 DMM All Rights Reserved. 5 タイトル数30万タイトル超
ロングテール型 さまざまな対応デバイス PC、スマートフォン、VR作品も展開 年間1PBのペースで増え続けるコンテンツ 6TB SATA HDD x 12構成のサーバを使用 動画コンテンツの特徴
Copyright © since 2017 DMM All Rights Reserved. 6 オリジンサーバ
コンテンツファイルが格納されているサーバ エッジキャッシュ エンドユーザーが直接アクセスする リバースプロキシとしての役割を持つ ミドルキャッシュ エッジキャッシュとオリジンサーバの間に位置する オリジンへのアクセス数を限定させる役割を持つ 本書で記載されている用語について
Copyright © since 2017 DMM All Rights Reserved. 7 2.
初期をふりかえる (2002~2007)
Copyright © since 2017 DMM All Rights Reserved. サービス開始当初の特徴 DAS+Windows
Serverの組み合わせ 複数のストレージから運用 ダウンロードはIIS ストリーミングはWindows Media Service 同じコンテンツをダウンロード用、ストリーミング用に それぞれストレージを分けて保持 8
Copyright © since 2017 DMM All Rights Reserved. 9 DASへの増設を週1回のペースで実施しており
運用面の負担が増えてきていた 空き容量、利用状況など管理面でも 負担がかかってきていたため ストレージ環境再構築の検討に入った 当時をふりかえると クラスタストレージの導入へ
Copyright © since 2017 DMM All Rights Reserved. 10 丸一日要していた拡張作業が数時間程度に短縮
RAIDよりも信頼性が向上した 集中管理されるため、管理工数も削減できた ストレージ導入で得られたメリット
Copyright © since 2017 DMM All Rights Reserved. 11 導入後をふりかえると
すべていいことづくめだったわけではなく 想定よりも性能が出ず、解消しないケースもあった ストレージ機能においてバグを引いた際 影響範囲が全体に拡大してしまったため ストレージを分散してリスクヘッジ
Copyright © since 2017 DMM All Rights Reserved. 12 影響範囲を限定できる仕組みが可能か
コンテンツ制作側の作業フローも考慮する必要あり ハードウェアのコスト削減 (アクセスの頻度によっては 全体的にGBあたりのコストが高くなってしまうため) 12 次への検討項目 クラスタストレージのリプレイスを実施
Copyright © since 2017 DMM All Rights Reserved. 13 3.
x86サーバx200台 (2010~2012)
Copyright © since 2017 DMM All Rights Reserved. 14 ストレージで負荷を捌かず前段で吸収する仕組みへ
障害範囲を限定できるような構成 負荷対策もサーバーごとに実施しやすくなる イニシャル/ランニングともにコスト削減効果が得られた 14 目指したところとその理由
Copyright © since 2017 DMM All Rights Reserved. 15 X86サーバへコンテンツの移行を行う
SATA HDDを12本搭載した2Uモデルのサーバを採用 Diskの故障率上昇に備えて12本中2本を HotSpareに設定 15 脱クラスタストレージ
Copyright © since 2017 DMM All Rights Reserved. 16 キャッシュサーバのスケールアップを実施
SATA HDDを12本(オリジンサーバと同様) メモリを128GB積んだサーバを使用 事前にアクセス集中を把握できているものに関しては オリジンサーバへのアクセスを抑えることができた 16 性能面についても考慮 しかし、ここで3つの問題点が浮かび上がってきた
Copyright © since 2017 DMM All Rights Reserved. 17 1.
増え続ける単一障害点 2. 統一されたHWで発生した重大なバグ 3. 1Gbのネットワークがボトルネックに 3つの問題点とは・・・
Copyright © since 2017 DMM All Rights Reserved. 18 コンテンツをサーバで冗長化するには
要するサーバの台数も2倍になってしまうため ファイルアップロードに要する時間も2倍に 運用面でも現実的ではなかった HWの制約によって空きポートがなく チーミング不可能(※増設するPCIの空きもない) ユーザー影響のあるハードウェア起因の障害が増加 ①単一障害点となってしまったこと
Copyright © since 2017 DMM All Rights Reserved. 19 RAIDコントローラのファームウェアで
バグを引き「予期しないシャットダウン」や カーネルパニックが100台以上で周期的に発生 使用するHDDのファームウェアでも バグを引いてしまい、一斉に障害検知されたり リビルドが正常に完了しないことも 改善しないファームウェアのバグと3年近く格闘 ②HWがほぼ統一されたことによる弊害
Copyright © since 2017 DMM All Rights Reserved. 20 リリース時やキャンペーンで集中するアクセス
(ダウンロードは特に接続が長時間滞留する) コンテンツの高精細化が進み 従来よりもファイルサイズが肥大していった 上記によってダウンロード速度遅延の問題も頻発 1Gbpsのネットワークでは限界に到達していた ③スペック不足
Copyright © since 2017 DMM All Rights Reserved. 21 4.
マルチデバイス対応と GlusterFS導入の経緯 (2013~)
Copyright © since 2017 DMM All Rights Reserved. 22 マルチデバイス対応によって
PCとスマホなど複数デバイスへMP4をベースに配信 従来、冗長構成されていないサーバ単体を オリジンストレージとして運用していたため PC向けのストリーミングが加わり トラフィックが急増することに マルチデバイス対応について
Copyright © since 2017 DMM All Rights Reserved. 23 Backendのトラフィックが1Gbpsを超えるため
サーバー単位で冗長構成を担保しつつ スループットにおいてもある程度要求されていた ハードウェア、ソフトウェアそれぞれの 費用対効果を考慮 オリジン強化の必要性
Copyright © since 2017 DMM All Rights Reserved. 24 2012年に初めてGlusterFSを
Striping Volumeの10台構成で試験的に導入 GlusterFSの導入 Striping Volume 性能、使い勝手も良好 Apache+GlusterFS
Copyright © since 2017 DMM All Rights Reserved. 25 クラスタストレージをGlusterFSへ移行
配信サーバにFuseでマウント Distributed Replica構成のGlusterFS GlusterFSの導入 Distributed Replica Volume Backendはすべて10Gbps対応
Copyright © since 2017 DMM All Rights Reserved. 26 GlusterFSは特性上
ディレクトリやファイルのリスト取得を 苦手としているため コンテンツ制作側のファイル操作に難があった 適当なサイジングで ボリュームを作成する必要が出てきた 26 次への検討項目
Copyright © since 2017 DMM All Rights Reserved. 27 5.
Linuxへの完全移行 (2014~2015)
Copyright © since 2017 DMM All Rights Reserved. 28 2015年7月15日(日本時間)
Windows Server 2003と WMDRMのサーバSDKサポート終了に伴い Windows Media Playerでの ライセンス認証も行えなくなることに ・・・これがどのような影響を及ぼしたのか?
Copyright © since 2017 DMM All Rights Reserved. 29 Windows
Server 2003をリプレイスする必要がある →2014年時点で200台まで増えていた Windows Media Player経由のストリーミングが不可に →WMVに変わるストリーミング素材としてMP4を用意 2PBのデータ移動ならびにMP4作成 29 ほぼ、配信基盤全体のリプレイスに匹敵 膨大な影響範囲
Copyright © since 2017 DMM All Rights Reserved. 30 期限がこれ以上ないほど明確なため
コンテンツのコピー移動やエンコード遅延による 延期は許容されない 検証だけにじっくり時間を割くことはできず 次世代の配信サーバを決定しなければならない 30 Windows 2008の選択肢も当然あったものの・・・ OSサポート終了が与えたインパクト
Copyright © since 2017 DMM All Rights Reserved. 31 実績を積んでいたGlusterFSで完全冗長構成に
ハードウェアも過去のナレッジを活かして選定し マルチベンダーでの調達を行った ネットワークの増強も合わせて実施し 全て10Gのネットワークで構成 31 2015年7月に大きなトラブルなく完了 問題点を解消することに全力を注いだ
Copyright © since 2017 DMM All Rights Reserved. 32 ダウンロードサーバをすべてGlusterFSへ移行
IISからApacheへ GlusterFSの導入 Apache+GlusterFS Replica Volume Apache+GlusterFS Replica Volume すべて10Gbpsネットワーク GlusterFS Replica 2
Copyright © since 2017 DMM All Rights Reserved. 33 GlusterFSの導入のメリットとして
複数台からなるオリジンサーバの構成によって 問題なく配信できる結果を得られた GlusterFSの導入 リリース1分後 22.36Gbps
Copyright © since 2017 DMM All Rights Reserved. 34 キャンペーン用負荷対策サーバもGlusterFSで
GlusterFSの導入 名前 用途 備考 PicsMaster 画像マスター Redhat Gluster Storage TV用Gluster ファイルサーバ MP4用Gluster ファイルサーバ 動画CP用負荷対策Gluster DLサーバ スマホDL用Gluster DLサーバ 増設する工数もさらに削減!
Copyright © since 2017 DMM All Rights Reserved. 35 6.
ストリーミング基盤改善 (2016~)
Copyright © since 2017 DMM All Rights Reserved. 36 SATA
HDDをメインで使用していることもあり 1ノードにつき3Gbps程度で限界に到達 2012年から構築を行ってきたGlusterFSは すでに150ボリュームほどに構築数が増えたため 構築時期とバージョンの差により 管理上の問題が起きはじめていた GlusterFSの課題 このあたり解決できるストレージを模索していた
Copyright © since 2017 DMM All Rights Reserved. 37 PB規模のストレージでも
運用上、特に問題となるような事象が起きなかった 台数ごとにおけるデータ利用効率が従来より上がった GlusterFS (1.3PB) vs Scality RING (2PB) ライセンスが容量単位の精度になっていたこと Scality RINGの導入理由 2016年7月より本番投入を開始
Copyright © since 2017 DMM All Rights Reserved. 38 38
ScalityRINGの導入後 現在2PBのボリューム 48ノードで運用中 負荷対策専用の ストレージを用意せず キャンペーンを 乗り切ることが可能に ScalityRINGをマウントした Fuse Connectorを Streaming Serverとして使用 既存のストレージ群と接続し コンテンツ管理を行うため CIFS Connectorを用意
Copyright © since 2017 DMM All Rights Reserved. 39 Scalityの性能
RINGノードからのトラフィックも60Gbpsを 超えており、安定稼働中 66.02Gbps
Copyright © since 2017 DMM All Rights Reserved. 40 7.
負荷対策方法の確立 (2016~)
Copyright © since 2017 DMM All Rights Reserved. 41 オリジンサーバはDisk性能に制約があるものの
コンテンツは増え続けるため 全てをSSD化することは非現実的(コスト的にも) コンテンツの高精細化により ファイルサイズが肥大化しており キャッシュサーバの設計見直しは必須要件だった キャッシュサーバの改善
Copyright © since 2017 DMM All Rights Reserved. 42 キャッシュ効率の向上
大容量SSD導入後 In平均↓ 4.13Gbps 大容量SSD導入前 In平均 9.52Gbps 導入前と比較して キャッシュサーバに 書き込まれる トラフィックが 9.52Gbps→ 4.13Gbps 倍以上の効果
Copyright © since 2017 DMM All Rights Reserved. 43 キャッシュサーバの構成
オリジン エッジキャッシュ ミドルキャッシュ Apache+GlusterFS Replica Volume エッジキャッシュと ミドルキャッシュに 大容量SSDを搭載 HDDと比較して 30TB→85TBまで増量
Copyright © since 2017 DMM All Rights Reserved. 44 細かい
チャンクファイルの I/Oが生じるため SATAのHDDでは 15分程度で 限界に到達 パフォーマンス改善例 HDDの場合 CPU 1.4Gbps CPU iowait timeが50%を超え スループットが低下する トラ フィック
Copyright © since 2017 DMM All Rights Reserved. 45 Iowaitも上がらず
トラフィックも 順調に推移 2.5Gbpsを 計測 パフォーマンス改善例 SSDの場合 2.5Gbps Iowaitもほぼ発生せず 2.5Gbps到達 トラ フィック CPU
Copyright © since 2017 DMM All Rights Reserved. 46 新キャッシュサーバの恩恵
通常時の4倍以上のトラフィックが発生しても キャッシュサーバのみで乗り切ることが可能に 47.58Gbps
Copyright © since 2017 DMM All Rights Reserved. 47 ライブ配信に代表される
配信する日時が決まっているコンテンツは ピークで70Gbps以上到達することもあるが 限られるためCDNがフィットしやすい CDNごとの特徴を把握して 複数から選択できるような構成が理想 CDNとの連携 ある程度柔軟性を持たせる必要がある
Copyright © since 2017 DMM All Rights Reserved. 48 マルチCDN対応
ストリーミング版 オリジン streaming server キャッシュ nginx 各CDNとの連携 ライブ配信や VODにて稼働中
Copyright © since 2017 DMM All Rights Reserved. 49 8.
まとめ
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
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年 アクセス過多による不具合 サーバ故障に起因する不具合 かねてより問題となっていた 単一障害点の解消や ボトルネックとなりえる ハードウェアのリプレイスで 改善の傾向が 顕著に表れている ※あくまでサーバ単体のトラブルとした数字
Copyright © since 2017 DMM All Rights Reserved. 52 まとめ
最適解はあくまでその時期によるもの いずれは変わることを念頭に サービスの安定稼働に例外を持たない CDN、クラウド、オンプレミス問わず 柔軟な構成を担保する意識を強く持つこと
ご清聴ありがとうございました