Embed Size (px)
DESCRIPTION
July Tech Festa 2014 での発表資料 大規模エンターテイメントサイトを支える技術 〜DMM.comの裏側をお見せします〜
Citation preview
大規模エンターテイメントサイトを支える技術
〜 DMM.comの裏側をお見せします 〜
2014/6/22July Tech Festa 2014 発表資料
自己紹介
本来の専門はソフトウェア工学。プログラマ、SE、ADSLの技術営業、通信キャリア・ISPを経て、DMM.comラボの前身であるDooGAに入社。他社にてインフラエンジニアをしていたが、2014年からDMM.comラボに合流。
村田篤紀（むらた あつのり）
DMM.comラボリサーチアドミニストレータ
バックボーン・コアネットワーク担当
本日のアジェンダ● DMM.comの概要紹介
● ネットワークインフラ● 負荷分散● 動画配信● その他の面白そうな技術● 運用● 今後のチャレンジ
DMM.comの概要紹介
DMM Groupについて
株式会社DMM.com
コンテンツバイヤー販促企画事業の企画・営業
株式会社DMM.comラボ
システム開発サーバ構築・インフラ保守、運用サイトデザイン、サイト運営マーケティング・PRカスタマサポート
DMM.com Groupは動画や電子書籍などのダウンロード販売他、オンラインゲームや通販、オンラインレンタルなどを提供するサイト「DMM.com」の構築から運営までを手がけているグループです。
会社概要１
会社名：株式会社DMM.com
設立：1999年（平成11年11月17日）
従業員：106名 ※2014年度5月現在
本社 〒150−6014 東京都渋谷区恵比寿ガーデンプレイス
会社概要２
会社名：株式会社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ビル
大手町オフィス
DMM.comについて
オンラインレンタル オンラインゲーム
みんなで遊べるオンラインゲームが
基本プレイ無料で楽しめる！
タイトル数: 246 (2014年6月現在)
3デバイスにまたがって展開PCスマートフォンフィーチャーフォン
コンテンツ配信
電子書籍
動画AKB48
SKE48
PCソフト/ゲーム
通信販売
マーケットプレイス
DVD/Blu-ray
CD
本・コミック
ホビー生活・日用品 家電・パソコン
オンラインレンタルCD/DVDレンタル
コミックレンタル
いろいろレンタル
クロスデバイス〜いつでもどこでも
パソコン
テレビ
スマートフォン
タブレット
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万人
DMM.com の特徴
● 多種多用なエンターテイメントサービスがどんどん増える● ゲームプラットフォーム● 動画配信● オンラインレンタル● 3Dプリント● 通販● レンタル● 英会話● 肉会
…● クロスデバイス対応● どんどん増える会員● ポイントによる決済システムを持っている
DMM.com を支えるチーム
制作管理部（ディレクター）制作管理部（ディレクター）
デザイン部デザイン部
マーケティング部マーケティング部ネットワーク部ネットワーク部
システム部システム部
運営部門運営部門
チームワーク
プログラム開発
進行管理
Webデザイン制作
インフラ構築・管理 広告・アフェリエイト
コンテンツ管理・サポート
企画営業企画営業
Webコンテンツバイヤー
管理部門管理部門
組織運営
↑本日話をする所
WEB+DB PRESS vol.78
今日はネットワークインフラに絞って話をします。
開発についての話は、WEB+DB PRESSに載ってますので、こちらも読んでみてくださいませ。
1年ほど前、
DMMの中の人はどこにいるのかわからない、ツチノコかよ、
と言われたので、ブログを始めました。
http://tsuchinoko.dmmlabs.com/
DMM.comのネットワークインフラ
〜 ネットワーク、サーバの構成等 〜
インターネットとの接続
データセンターは東京に3拠点、九州に1拠点
対外接続、合計180Gbps
毎日のピークトラフィックは100Gbps超
ダークファイバーによりデータセンター間接続
目的によりデータセンターを使いわけている
ネットワーク基本構成図
コアルータ、コアファブリック、エッジファブリック以下に個々のシステムを接続
ネットワーク機器レベルで冗長構成を取っている
インスタンス数は4500台〜
ロードバランサは50台〜
HyperVisorは混在VMWare、KVM、Xen、Hyper-V
ネットワークコア部分物理配線コアルータ
コアファブリック
エッジファブリック
Juniper QFabric
コアファブリックに採用
複数の筐体を1台のスイッチのようにオペレーションできる
システムの物理配置の自由度が向上
導入時にちょっと不具合もあったけど今は無事に動いている
←概念説明図(Juniperのサイトから引用)
大きい丸の周辺にあるオレンジ色の小さい点が個々のネットワーク機器のイメージ
エッジファブリック
ネットワーク用途によりエッジファブリックも導入している。
ウェブポータル→Juniper Virtual Chassis
共有ストレージ→Brocade VCS Fabric
管理ネットワーク→OpenFlow対応スイッチ
最近オープンしたとあるシステムノード
筐体はブレードサーバ
すべて仮想インスタンス
HyperVisorはVMWare
共有ストレージはHP 3PAR
データベース部分はLVSを持ちいたフルアクティブ冗長構成
プロビジョニングツールはAnsibleを採用
都度都度、格好良い技術を取りいれながら作ってます。
パブリッククラウド、CDNの利用
データセンターインフラだけでサービスできない部分は、外部のシステムも使っています。
オンプレミスのシステムのほうが低コストだけど、ゲーム開発会社(SAP)さんが慣れた環境で開発を進めたほうがスピードアップできることも多い。
コストよりスピード優先！！
10年ぐらい前にどこかで、DMMではCDNは使いません、と言ったことがあるのですが、今は使ってます。
ネットワークインフラのポイント
● 複数拠点を使ってのサービス配信
● ピーク100Gbps超の大容量トラフィック
● 4500台〜のサーバインスタンス (外部は含まず)
● 新しい技術の積極的な採用
● 自社設備にこだらないことでスピードアップ
負荷分散
〜 大容量トラフィックのさばき方 〜
負荷分散技術の使いわけ
適用するネットワーク領域によって、GSLB、SNAT、L2DSRを使いわけている
ウェブサイトの負荷分散(SNAT)
通常のウェブサイトはSNATによりバランシング
一部URLマッチによるL7による振り分けも行なっている。
SSLは基本はサーバでかけているが、一部バランサで行なっているものもある。
内部負荷分散（DSR)
グローバルIPアドレスを持たない、内部的な負荷分散は、だいたいL2DSRを使っている。
L3DSRは今は使っていないが検討は行なっている
アプライアンスを使っているケースと、LVSを使っているケースがある。
GSLBによる負荷分散
トラフィック容量が多いサービス、複数のデータセンターに跨またがるサービスに利用している。
コンテンツキャッシュ、画像専用サーバ等
CDNの利用
スパイクトラフィックに合わせて回線トラフィックを仕入れるよりも、CDNを使ったほうが低コストとなるため。
とある日のとあるコンテンツのCDNトラフィック
急激なアクセス増に対応するためCDNへのオフロードピーク15Gbps
BGPによるトラフィックコントロール
一部の上流回線の流量が
大きくなったり、遅延が増
加するような場合は、トラ
フィックを別の上流回線に
移動させる。
トラフィック移動
負荷分散のポイント● 様々な技術で負荷分散とトラフィックコント
ロールを行なっている。
● SNAT● DSR● GSLB● CDN● BGP
● ロードバランサアプライアンスはA10とF5の使い分け(50台以上)
● LVSも利用
Wikimedia: Dani Daniel Balance auf Rollen
動画配信
〜 大規模動画配信のための仕組み 〜
動画配信のどこが難しいのか？
ファイルサイズが大きい
→大容量ストレージが必要
マルチデバイスに対応しなけ
ればいけない
→エンコーディングの種類が多い
負荷予測が難しい
→ロングテールなので予測不能
Wikimedia:Domenico-Fetti Archimedes
大容量分散ファイルシステムGlusterFS
以前はIsilon Storageを使っていたが、容量増加への対応とコスト削減のため、GlusterFSに切り替えた。汎用2Uのサーバに大容量ハードディスクを積んでクラスタ化。大容量、拡張性、対障害性、低コストを実現。
lsが遅い等、苦手なこともあるが、ちゃんと動いてます。
毎日2TBずつ増えてます。
対応すべきデバイス、規格
多種多様な組み合わせがある。
エンコーディングシステムを自社開発。300台のサーバが並列で24時間エンコーディング作業を行なっている。
対応デバイス
PC(Window Media Player)PC(Sliverlight Player)スマートフォンTV携帯電話
コンテナ
asfismvMPEG2-TS3gp
映像コーデック
VC-1H.264H.264 ARIBMPEG-4
音声コーデック
VC-1H.264H.264 ARIBMPEG-4
配信サーバ
IISApacheMicrosoft Media ServerAdobe Media ServerWowza Media Server
コンテンツアクセス制御
ウェブページに埋めこむURLを変更することでユーザの接続先をコントロールする。
新しいコンテンツはキャッシュサーバ経由でアクセスさせることで速度アップ
ある特定のコンテンツのアクセスが増加し、サーバの負荷が上昇した時には、そのコンテンツを別のサーバに移動させて、サーバ負荷を平準化させる。
CDN、クラウドの利用
キャンペーンや、アイドルグループの中継など、トラフィック予測がしにくいトラフィックについては、CDNを柔軟に使うことで対応している。
CDNで対応できない場合に備えて、パブリッククラウド経由で配信できるような仕組みも作っている。
ユーザにコンテンツを届けるためには、何でも使う。
とある日のとあるコンテンツのCDNトラフィック（再掲)
急激なアクセス増に対応するためCDNへのオフロードピーク15Gbps
その他の面白そうな技術
〜 DMM.comで使われているユニークな技術 〜
NANDフラッシュメモリの利用MySQLサーバは基本的にはNANDフラッシュメモリを使う。
画像専用サーバ等、高iopsが必要なサービスでも利用している。
Fusion-io、Huawei、Virident、など複数ベンダ製品を利用。
SSDドライブも積極的に利用している。
Wikimedia: Gille in the Snow
画像専用サーバ（第1世代)
NFS共有ストレージと大量のサーバ群
NFS共有ストレージ
大量のサーバ群
画像専用サーバ（第2世代)
CDNキャッシュによる高速化
サーバの台数は大幅に削減
高トラフィックにも対応
ただしコストは増えた
CDNキャッシュ
NANDフラッシュメモリ採用。CDNからデータセンターに回帰した上で、サーバ台数の減少に成功。
万が一のためCDNも利用できるようにもしている。
低コストと速さの両立。
画像専用サーバ（第3世代)
NANDフラッシュメモリ
ログ収集と解析fluentd + elasticsearch + kibana
fluentd により各サーバからログを収集elasticsearch がデータを、JSON形式で出力kibana がブラウザ上でelasticsearchから取得したデータをビジュアライゼーション
ログ収集と解析
複数のキャッシュサーバのウェブアクセスログをまとめて解析
ウェブだけでなく、MySQL等のログ解析も
運用
〜 24時間365日眠らない運用 〜
24時間365日監視体制
24時間365日、シフトを組んで監視を行なっている。
監視ツールからのアラート等、なにかあったら、フローに従った対応を行なう。
監視担当者では対応できない場合は適切にエスカレーション。
ユーザサポートチームとも連携。
Wikimedia: Simplex Time Recorder
監視ツール
様々な監視ツールを併用
NagiosMuninZabbix →これが良さげ？Icinga →これも良さげ？MRTGCacti （引退予定)SmokePing
SNMPベースのツールより、エージェント型のツールのほうが良いかと思っている。
朝会による情報共有進行表↓(これを1時間以内でやる)
全体朝礼(全社的連絡、勤怠の確認)日報記入(前日作業の記録)全体共有事項報告全体に影響がある作業の連絡在庫状況報告システムチームとの連絡表確認朝まで発生したアラートの確認その他(質問等)全体議事録確認各チーム部会
進行役、議事録担当、は持ち回り
朝会の議事録テンプレートはボタン1つで簡単作成
報告事項は、各人が議事録に事前に記入しておく
Wikimedia: Group of cats circle around catfood
情報共有のためのツール
チャットの積極的な利用racktablesによる構成管理チケット(JIRA)によるタスク管理Confluenceによる情報管理
その他のツールも必要に応じて利用↓メールGoogle Drive、グループウェアWiki等
設備増強
必要なものは買う！！即決稟議！！
↑10Gbpsインターフェイスが埋まって焦ったときのグラフ
必要な機材の納期遅れが事業の足をひっぱると結果としてコスト増になってしまうので
増強のタイミングをはかるため、リソース監視を行なっている。
設備刷新新しい機材のほうが性能が良い。古い機材は積極的に刷新している。
リース切れ時に、リース更新をしたら負け！！
メーカーは統一しない。都度選定。スイッチのバッファサイズ等、最低限のスペック基準は決めている。
東京に移転するときに導入された記念すべき初号機
勉強会の実施技術の進化に人も対応していかなければいけない。
毎週火曜日に部内勉強会を開催。
内容は様々。
今後のチャレンジ
〜 進化し続ける DMM.com のインフラ 〜
自社クラウドシステム構築
10分以内にサーバを提供できる環境を作る。
CloudStackとかOpenStackとかいろいろお試し中。
ピアリングの推進 AS23620どんどんピアリング先を増やしていきます。
目的↓インターネットの大規模障害時にもエンドユーザにサービスに届けたい。エンドユーザまでのホップ数を減らしたい。
ピアリングポリシー↓「友達になってください」→ http://tsuchinoko.dmmlabs.com/?p=1262
facebook、twitter、携帯電話等で繋がればOKです。
データセンターの継続的見直し
システムの刷新と合わせて継続的に見直しを行なっていく。
どう変化するかはその時々で、柔軟に考える。
？？？？？？
外部への情報発信
今回は登壇の機会をいただきありがとうございました。今後もDMMで使われている技術情報を積極的に発信していきます。
他のイベントへも積極的に参加していきます。
勉強会の場所も提供できます。恵比寿の21Fにオープンスペースができました。
もちろんブログも書き続けます！
事業拡大に向けての対応
経営の速度がハンパない。どんどん増えるサービス。
支えるために現場も頑張る。
● ナレッジのさらなる蓄積と共有● 体制の整備● 人員の増強
私たちのミッション
サイトを通じて新しい事業を創造しつづけること
