読者です 読者をやめる 読者になる 読者になる

べにやまぶろぐ

技術寄りの話を書くつもり

JTF2014「大規模エンターテイメントサイトを支える技術 ― DMM.comの裏側をお見せします」の聴講メモ #techfesta

JTF2014 最後の講演は DMM.com さんのインフラのお話。会社名義で公の場でお話されるのは実に10年ぶりくらいということでかなり赤裸裸な感じの話だと感じました。DC の場所、勘違いでなければ講演時はもうちょい詳しかった気がしますが発表資料ではマイルドな?表現になっています。

個人的に響いたこと
  • 大手町オフィスもツチノコで場所を明示していない
  • 肉会も DMM.com さんのサービスだった
  • インフラ知識もっと必要(わからない言葉多かった)
  • コストよりスピード優先、オンプレの方がコスト安いけど (SAP さんに) 慣れた環境で作ってもらった方が開発スピードは速い
  • 日報を翌日の朝会に書く、というのはもしかしたら良いかもしれない
  • リース切れ時にリース更新をしてたら負け
  • エンコーディングだけで300台のサーバーフル稼働
  • いずれ自社クラウドを持つため、開発・検証中
講演メモ
  • DMM.com Group = DMM.com (106名) + DMM.com Lab (800名)
    • 大手町オフィスは場所を明示していない
    • 3Dプリント他、太陽発電や英会話、肉会などもやっている
    • オンラインゲーム : ユーザーは PC が圧倒的に多い、過半数以上。タイトルは 246本
    • コンテンツ配信が主戦力
    • 多種多様なエンタメサービスがどんどん増えている
      • 会員はどんどん増えているしポイントによる決済システムも持っている
  • ツチノコブログは tagomoris さんに言われて始めたサイト
  • 対外接続 180Gbpsで、ピークトラフィックは 80Gps超
    • データセンター4拠点ごとに目的が違う
    • データセンター間はダークファイバーでつないでいる
  • 物理 2,500台〜、仮想 2,000 台 (4,500 台〜のサーバインスタンス)
    • HiperVisor/VMWare/Xen など目的に応じて使い分け
  • Junioer QFabric をコアファブリックに採用していて、複数の筐体を1台のスイッチのようにオペレーションできる
  • システムの物理配置の自由度が向上
  • ネットワーク用途によりエッジファブリックも導入している
  • 最近出したサービス
  • パブリッククラウド、CDN も利用
    • SAP が望めば
    • コストよりスピード優先、オンプレの方がコスト安いけど慣れた環境で作ってもらった方が開発スピードは速い
  • 負荷分散 : L2DSR-SNAT-GSLB
    • SNAT : ウェブのバランシング、一部 URL マッチによる L7 振り分けもしている
    • DSR : グローバルを持たない内部的負荷分散は L2DSR を使用。L3DSR は検討中
    • GSLB : トラフィック要領が多いサービス、複数のデータセンターにまたがるサービス、コンテンツキャッシュなどに使っている
    • CDN : アイドルグループの中継やキャンペーンなどトラフィック予測がしにくいものに使用。ユーザーのためなら何でも使う
    • BGP によるトラフィックコントロール : 一部の上流回線の流量が増えたりした場合は別の線に
  • 動画配信
    • ファイルサイズが大きいのでストレージが必要
      • isilon storage を GlusterFS に切り替え
      • ls が遅いがちゃんと動いている
      • 2TB/日ずつ増えてる
      • レプリカ3で運用
    • マルチでバイス対応のためにエンコーディングの種類、配信サーバーの選択など
      • デバイス、コンテナ、サーバ、コーデックなど
      • 300 台のサーバが 24時間延々とエンコーディングしている
      • アクセス状況を監視しながらキャッシュヒットしなかったものを別サーバに手動で移動させたりしている
    • 負荷予測が難しい(ロングテールのため)
  • サービス間連携
    • 認証 API などシステム間粗結合のための仕組みを用意している
    • 3D プリントのように一般向けに公開している API もある
    • システム連携によりイベントでスパイクがくる
      • コアな部分はしっかり作っておく
      • スケールアウトする仕組みを確保しておく
  • MySQL サーバには基本的に NAND フラッシュメモリを使用
    • Fusion-io, Huawei, Virident など複数ベンダ商品を使用
    • 4TB SSD も検証予定
  • 画像専用サーバーは第二世代で CDN キャッシュを使用、第3世代で NAND フラッシュメモリ採用
    • CDN から DC に会期した上でサーバ台数の減少に成功
    • 低コストと速さの両立に成功
  • ログ収集と解析
    • fluentd + elasticsearch + kibana
    • kibana はビジュアライゼーションツール
    • Web や MySQL のログ解析も可能
  • 24時間365日シフトを訓で監視を行っている
    • 何かあればフローに従った多応、対応できない場合は適切にエスカレーション
    • サポートチームと密に連携
    • Nagios/Munin/Zabbix/Icinga/MRTG/Cacti/SmokePing など
  • 始業
    • 全体朝礼 : 全社的連絡
    • 日報記入 : 前日の勤務内容記入
    • 在庫確認 : 特にスイッチがすぐなくなる
    • アラートの確認・対応状況の判断
    • 進行役・議事録担当は持ち回り
    • 朝会の議事録テンプレートはボタン一つで簡単作成
    • 報告事項は各人があらかじめ書いておく
  • ツール
    • racktables による構成管理
    • チケット (JIRA) によるタスク管理
    • Confuluence による情報管理
  • 設備増強
    • 必要なものは買う、即決稟議
    • 必要な機材の納期後れが事業の足をひっぱると結果的にコスト増になる
    • リース切れ時にリース更新をしてたら負け
      • 古い機材は積極的に刷新
      • メーカーは統一してないがスイッチのバッファサイズや最低限のスペック基準は決めている
  • 勉強会の実施
    • 技術の進化に人も対応していかなければならない(毎週火曜日)
  • 今後のチャレンジ
    • 自社クラウドシステム構築
      • ツチノコクラウド : CloudStack とか OpenCloud などで 10分以内にサーバを提供できる環境を作っている
    • ピアリングの推進 AS23620
      • 障害時でもエンドユーザにサービスを届けたい、エンドユーザまでのホップ数を減らしたい
    • データセンターの継続的見直し
      • ラック数が多くなると古い DC の冷房環境や電気効率など気になるのでかえていきたい
      • 引っ越しコストもばかにならないので3〜4年に一回見直して5年に一回くらい引っ越し
    • 外部への情報発信
      • 今回、DMM としては10年ぶり
      • 恵比寿の 21F にオープンスペースができたのでそこで勉強会を開催したりできる
    • 経営の速度がはんぱないのでどんどん事業が増える
      • 支えるために現場もがんばる、ナレッジの共有や体制の整備、人員の増強など
  • DMM のミッション
    • サイトを通じて新しい事業を想像し続けること