Upcoming SlideShare
July Tech Festa 2014 大規模エンターテイメントサイトを支える技術
- 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
Be the first to comment