July Tech Festa 2014 での発表資料 大規模エンターテイメントサイトを支える技術 〜DMM.comの裏側をお見せします〜

1. 大規模エンターテイメントサイトを
支える技術
〜 DMM.comの裏側を
お見せします 〜
2014/6/22
July Tech Festa 2014 発表資料

2. 自己紹介
本来の専門はソフトウェア工学。プログラマ、SE、ADSLの技術営業、通信
キャリア・ISPを経て、DMM.comラボの前身であるDooGAに入社。他社に
てインフラエンジニアをしていたが、2014年からDMM.comラボに合流。
村田篤紀（むらた あつのり）
DMM.comラボ
リサーチアドミニストレータ
バックボーン・コアネットワーク
担当

3. 本日のアジェンダ
● DMM.comの概要紹介
●
ネットワークインフラ
●
負荷分散
●
動画配信
●
その他の面白そうな技術
●
運用
●
今後のチャレンジ

4. DMM.comの概要紹介

5. DMM Groupについて
株式会社DMM.com
コンテンツバイヤー
販促企画
事業の企画・営業
株式会社DMM.comラボ
システム開発
サーバ構築・インフラ保守、運用
サイトデザイン、サイト運営
マーケティング・PR
カスタマサポート
DMM.com Groupは動画や電子書籍などのダウンロード
販売他、オンラインゲームや通販、オンラインレンタルなどを提供す
るサイト「DMM.com」の構築から運営までを
手がけているグループです。

6. 会社概要１
会社名：株式会社DMM.com
設立：1999年（平成11年11月17日）
従業員：106名 ※2014年度5月現在
本社 〒150−6014 東京都渋谷区恵比寿ガーデンプレイス

7. 会社概要２
会社名：株式会社DMM.comラボ
設立：2000年（平成12年4月3日）
従業員：800名 ※2014年度5月現在
本社 〒150−6014 東京都渋谷区恵比寿ガーデンプレイス
加賀事業所 〒922−0551 石川県加賀市美岬町１−１
金沢事業所 〒920−0853 石川県金沢市本町2-15-1 ポルテ金沢
割出事業所 〒920−0062 石川県金沢市割出町６３１
金沢西事業所 〒921ー8061 石川県金沢市森戸1−139−1DMM.comビル
大手町オフィス

8. DMM.comについて

9. オンラインレンタル オンラインゲーム
みんなで遊べるオンラインゲームが
基本プレイ無料で楽しめる！
タイトル数: 246 (2014年6月現在)
3デバイスにまたがって展開
PC
スマートフォン
フィーチャーフォン

10. コンテンツ配信
電子書籍
動画AKB48
SKE48
PCソフト/ゲーム

11. 通信販売
マーケットプレイス
DVD/Blu-ray
CD
本・コミック
ホビー生活・日用品 家電・パソコン

12. オンラインレンタル
CD/DVDレンタル
コミックレンタル
いろいろレンタル

13. クロスデバイス〜いつでもどこでも
パソコン
テレビ
スマートフォン
タブレット

14. 0
1,000,000
2,000,000
3,000,000
4,000,000
5,000,000
6,000,000
7,000,000
会員数
2009年 2013年
860万人860万人
190万人190万人

15. DMM.com の特徴
●
多種多用なエンターテイメントサービスがどんどん増える
●
ゲームプラットフォーム
●
動画配信
●
オンラインレンタル
● 3Dプリント
●
通販
●
レンタル
●
英会話
●
肉会
…
●
クロスデバイス対応
●
どんどん増える会員
●
ポイントによる決済システムを持っている

16. DMM.com を支えるチーム
制作管理部
（ディレクター）
制作管理部
（ディレクター）
デザイン部デザイン部
マーケティング部マーケティング部ネットワーク部ネットワーク部
システム部システム部
運営部門運営部門
チームワーク
プログラム開発
進行管理
Webデザイン制作
インフラ構築・管理 広告・アフェリエイト
コンテンツ管理・サポート
企画営業企画営業
Webコンテンツバイヤー
管理部門管理部門
組織運営
↑本日話をする所

17. WEB+DB PRESS vol.78
今日はネットワークインフラに
絞って話をします。
開発についての話は、
WEB+DB PRESSに載ってま
すので、こちらも読んでみてく
ださいませ。

18. 1年ほど前、
DMMの中の人はどこにいる
のかわからない、ツチノコか
よ、
と言われたので、ブログを始めま
した。
http://tsuchinoko.dmmlabs.com/

19. DMM.comのネットワークインフラ
〜 ネットワーク、サーバの構成等 〜

20. インターネットとの接続
データセンターは
東京に3拠点、九州に1拠点
対外接続、合計180Gbps
毎日のピークトラフィックは
100Gbps超
ダークファイバーによりデータセ
ンター間接続
目的によりデータセンターを使い
わけている

21. ネットワーク基本構成図
コアルータ、コアファブリック、
エッジファブリック以下に個々の
システムを接続
ネットワーク機器レベルで
冗長構成を取っている
インスタンス数は4500台〜
ロードバランサは50台〜
HyperVisorは混在
VMWare、KVM、Xen、
Hyper-V

22. ネットワークコア部分物理配線
コアルータ
コアファブリック
エッジファブリック

23. Juniper QFabric
コアファブリックに採用
複数の筐体を1台のスイッチのようにオペレーションできる
システムの物理配置の自由度が向上
導入時にちょっと不具合もあったけど今は無事に動いている
←
概念説明図
(Juniperのサイトから引用)
大きい丸の周辺にあるオレンジ
色の小さい点が個々のネット
ワーク機器のイメージ

24. エッジファブリック
ネットワーク用途によりエッジファブリックも導入している。
ウェブポータル→Juniper Virtual Chassis
共有ストレージ→Brocade VCS Fabric
管理ネットワーク→OpenFlow対応スイッチ

25. 最近オープンした
とあるシステムノード
筐体はブレードサーバ
すべて仮想インスタンス
HyperVisorはVMWare
共有ストレージはHP 3PAR
データベース部分はLVSを持ちい
たフルアクティブ冗長構成
プロビジョニングツールはAnsible
を採用
都度都度、格好良い技術を取りい
れながら作ってます。

26. パブリッククラウド、CDNの利用
データセンターインフラだけでサービスできない部分は、外部の
システムも使っています。
オンプレミスのシステムのほうが低コストだけど、ゲーム開発会
社(SAP)さんが慣れた環境で開発を進めたほうがスピードアッ
プできることも多い。
コストよりスピード優先！！
10年ぐらい前にどこかで、DMMではCDNは使いません、と言っ
たことがあるのですが、今は使ってます。

27. ネットワークインフラのポイント
●
複数拠点を使ってのサービス配信
● ピーク100Gbps超の大容量トラフィック
● 4500台〜のサーバインスタンス (外部は含まず)
●
新しい技術の積極的な採用
●
自社設備にこだらないことでスピードアップ

28. 負荷分散
〜 大容量トラフィックのさばき方 〜

29. 負荷分散技術の使いわけ
適用するネットワーク領域によって、
GSLB、SNAT、L2DSRを使いわけている

30. ウェブサイトの負荷分散(SNAT)
通常のウェブサイトはSNATに
よりバランシング
一部URLマッチによるL7によ
る振り分けも行なっている。
SSLは基本はサーバでかけて
いるが、一部バランサで行なっ
ているものもある。

31. 内部負荷分散（DSR)
グローバルIPアドレスを持た
ない、内部的な負荷分散は、
だいたいL2DSRを使ってい
る。
L3DSRは今は使っていないが
検討は行なっている
アプライアンスを使っている
ケースと、LVSを使っている
ケースがある。

32. GSLBによる負荷分散
トラフィック容量が多いサービ
ス、複数のデータセンターに跨
またがるサービスに利用して
いる。
コンテンツキャッシュ、画像専
用サーバ等

33. CDNの利用
スパイクトラフィックに合わせて回線トラフィックを仕入れるより
も、CDNを使ったほうが低コストとなるため。
とある日のとあるコンテンツのCDNトラフィック
急激なアクセス増に対応するためCDNへのオフロード
ピーク15Gbps

34. BGPによるトラフィックコントロール
一部の上流回線の流量が
大きくなったり、遅延が増
加するような場合は、トラ
フィックを別の上流回線に
移動させる。
トラフィック移動

35. 負荷分散のポイント
●
様々な技術で負荷分散とトラフィックコント
ロールを行なっている。
● SNAT
● DSR
● GSLB
● CDN
● BGP
● ロードバランサアプライアンスはA10とF5
の使い分け(50台以上)
● LVSも利用
Wikimedia: Dani Daniel Balance auf Rollen

36. 動画配信
〜 大規模動画配信のための仕組み 〜

37. 動画配信のどこが難しいのか？
ファイルサイズが大きい
→大容量ストレージが必要
マルチデバイスに対応しなけ
ればいけない
→エンコーディングの種類が多い
負荷予測が難しい
→ロングテールなので予測不能
Wikimedia:Domenico-Fetti Archimedes

38. 大容量分散ファイルシステム
GlusterFS
以前はIsilon Storageを使っ
ていたが、容量増加への対
応とコスト削減のた
め、GlusterFSに切り替え
た。
汎用2Uのサーバに大容量
ハードディスクを積んでクラ
スタ化。
大容量、拡張性、対障害性、
低コストを実現。
lsが遅い等、苦手なこともあ
るが、ちゃんと動いてます。
毎日2TBずつ増えてます。

39. 対応すべきデバイス、規格
多種多様な組み合わせがある。
エンコーディングシステムを自社
開発。
300台のサーバが並列で24時間
エンコーディング作業を行なって
いる。
対応デバイス
PC(Window Media Player)
PC(Sliverlight Player)
スマートフォン
TV
携帯電話
コンテナ
asf
ismv
MPEG2-TS
3gp
映像コーデック
VC-1
H.264
H.264 ARIB
MPEG-4
音声コーデック
VC-1
H.264
H.264 ARIB
MPEG-4
配信サーバ
IIS
Apache
Microsoft Media Server
Adobe Media Server
Wowza Media Server

40. コンテンツアクセス制御
ウェブページに埋めこむURLを変更
することでユーザの接続先をコント
ロールする。
新しいコンテンツはキャッシュサーバ
経由でアクセスさせることで速度アッ
プ
ある特定のコンテンツのアクセスが
増加し、サーバの負荷が上昇した時
には、そのコンテンツを別のサーバ
に移動させて、サーバ負荷を平準化
させる。

41. CDN、クラウドの利用
キャンペーンや、アイドルグループの中継など、トラフィック予測がしにくいトラ
フィックについては、CDNを柔軟に使うことで対応している。
CDNで対応できない場合に備えて、パブリッククラウド経由で配信できるような
仕組みも作っている。
ユーザにコンテンツを届けるためには、何でも使う。
とある日のとあるコンテンツのCDNトラフィック（再掲)
急激なアクセス増に対応するためCDNへのオフロード
ピーク15Gbps

42. その他の面白そうな技術
〜 DMM.comで使われているユニークな技術 〜

43. NANDフラッシュメモリの利用
MySQLサーバは基本的には
NANDフラッシュメモリを使う。
画像専用サーバ等、高iopsが必要
なサービスでも利用している。
Fusion-io、Huawei、Virident、など
複数ベンダ製品を利用。
SSDドライブも積極的に利用して
いる。
Wikimedia: Gille in the Snow

44. 画像専用サーバ（第1世代)
NFS共有ストレージと
大量のサーバ群
NFS共有ストレージ
大量のサーバ群

45. 画像専用サーバ（第2世代)
CDNキャッシュによる高速化
サーバの台数は大幅に削減
高トラフィックにも対応
ただしコストは増えた
CDNキャッシュ

46. NANDフラッシュメモリ採用。
CDNからデータセンターに回
帰した上で、サーバ台数の減
少に成功。
万が一のためCDNも利用でき
るようにもしている。
低コストと速さの両立。
画像専用サーバ（第3世代)
NANDフラッシュメモ
リ

47. ログ収集と解析
fluentd + elasticsearch + kibana
fluentd により各サーバからログを収集
elasticsearch がデータを、JSON形式で出力
kibana がブラウザ上でelasticsearchから取得したデータをビ
ジュアライゼーション

48. ログ収集と解析
複数のキャッシュサーバのウェブアクセスログをまとめて解析
ウェブだけでなく、MySQL等のログ解析も

49. 運用
〜 24時間365日眠らない運用 〜

50. 24時間365日監視体制
24時間365日、シフトを組んで
監視を行なっている。
監視ツールからのアラート等、
なにかあったら、フローに従っ
た対応を行なう。
監視担当者では対応できない
場合は適切にエスカレーショ
ン。
ユーザサポートチームとも連
携。
Wikimedia: Simplex Time Recorder

51. 監視ツール
様々な監視ツールを併用
Nagios
Munin
Zabbix →これが良さげ？
Icinga →これも良さげ？
MRTG
Cacti （引退予定)
SmokePing
SNMPベースのツールより、エー
ジェント型のツールのほうが良い
かと思っている。

52. 朝会による情報共有
進行表↓(これを1時間以内でやる)
全体朝礼(全社的連絡、勤怠の確認)
日報記入(前日作業の記録)
全体共有事項報告
全体に影響がある作業の連絡
在庫状況報告
システムチームとの連絡表確認
朝まで発生したアラートの確認
その他(質問等)
全体議事録確認
各チーム部会
進行役、議事録担当、は持ち回り
朝会の議事録テンプレートはボタン1つで簡単作成
報告事項は、各人が議事録に事前に記入しておく
Wikimedia: Group of cats circle around catfood

53. 情報共有のためのツール
チャットの積極的な利用
racktablesによる構成管理
チケット(JIRA)によるタスク管理
Confluenceによる情報管理
その他のツールも必要に応じて利用↓
メール
Google Drive、
グループウェア
Wiki
等

54. 設備増強
必要なものは買う！！
即決稟議！！
↑10Gbpsインターフェイスが埋まって焦ったときのグラフ
必要な機材の納期遅れが事業の足をひっぱると
結果としてコスト増になってしまうので
増強のタイミングをはかるため、リソース監視を行なっている。

55. 設備刷新
新しい機材のほうが性能が良い。
古い機材は積極的に刷新している。
リース切れ時に、リース更新をしたら負け！！
メーカーは統一しない。都度選定。
スイッチのバッファサイズ等、最低限のスペック基準は決めている。
東京に移転するときに導入された記念すべき初号機

56. 勉強会の実施
技術の進化に人も対応し
ていかなければいけな
い。
毎週火曜日に部内勉強
会を開催。
内容は様々。

57. 今後のチャレンジ
〜 進化し続ける DMM.com のインフラ 〜

58. 自社クラウドシステム構築
10分以内にサーバを提供で
きる環境を作る。
CloudStackとかOpenStack
とかいろいろお試し中。

59. ピアリングの推進 AS23620
どんどんピアリング先を増やして
いきます。
目的↓
インターネットの大規模障害時にも
エンドユーザにサービスに届けた
い。
エンドユーザまでのホップ数を減らし
たい。
ピアリングポリシー↓
「友達になってください」
→ http://tsuchinoko.dmmlabs.com/?p=1262
facebook、twitter、携帯電話等で繋がれ
ばOKです。

60. データセンターの継続的見直し
システムの刷新と合わせて継
続的に見直しを行なっていく。
どう変化するかはその時々で、
柔軟に考える。
？？？？？？

61. 外部への情報発信
今回は登壇の機会をいただきあ
りがとうございました。
今後もDMMで使われている技術
情報を積極的に発信していきま
す。
他のイベントへも積極的に参加し
ていきます。
勉強会の場所も提供できます。
恵比寿の21Fにオープンスペー
スができました。
もちろんブログも書き続けます！

62. 事業拡大に向けての対応
経営の速度がハンパない。どんどん増えるサービス。
支えるために現場も頑張る。
●
ナレッジのさらなる蓄積と共有
●
体制の整備
●
人員の増強

63. 私たちのミッション
サイトを通じて新しい事業を
創造しつづけること

64. ありがとうございました
murata-atsu@dmm.com
ピアリングリクエストはこちら：friend@dmm.com
AS23620