DMMのゲームプラットフォームで利用している技術やシステム構成、レガシーシステムが抱える課題、解決のためのシステムリプレイスの進め方

DMMのゲームプラットフォームで利用
している技術やシステム構成、レガ
シーシステムが抱える課題、解決のた
めのシステムリプレイスの進め方
DMM.com Labo オンライゲーム事業部プラットフォーム開発本部久保田亙
2017/02/07 dots

• 名前：久保田亙
• 会社：DMM.com Labo
• 2015/08 入社
• プログラマー
• 好きなデザインパターン：ゴッドオブジェクト
• 口癖：「テストがないと死ぬ病気にかかっています。」
Copyright © since 1998 DMM All Rights Reserved. 2
自己紹介

本日みなさんへお伝えする内容
DMM GAMES プラットフォームとは？
DMM GAMES プラットフォームの歴史（変遷）
DMM GAMES プラットフォームのシステム構成
DMM GAMES プラットフォームのシステムリプレイス

DMM.comは1999年から続く老舗サービ
スサイトです。時代のニーズに合わせた多
彩なコンテンツを、18年間培った独自プ
ラットフォームで安定的に提供しています。
About DMM.com
40以上の幅広いサービスを展開
サービスについて

ラットフォームで安定的に提供しています。
About DMM.com
DMM
GAMES

DMM GAMESとは
PCをメインにスマートフォン、フィーチャーフォンの３デバイスにまたがって
みんなで遊べるオンライゲームを提供しています。
世界中の大人に興奮を！
人気タイトルあります！様々なデバイスイベント随時開催

DMM GAMES プラットフォームとは
DMM GAMESで様々なゲームを提供するための土台
全てのゲームを
遊びやすいように、たのしめる
ようにする機能群
->
トップページ、ゲーム一覧など
デバイスの違い
同一アカウントで複数デバイス
のゲームの仕組み
裏では
データ解析、ログ基盤、バッチ
処理
ゲームするための共通機能を提供（プロフィール管理、ポイント、課金など）
海外向けプラットフォームやゲームストア、ゲームプレイヤーも

DMM GAMESプラットフォームを支える技術
さまざまなツール類を利用

最初のシステム構成は？（黎明期=5年前）
資料がみつからず伝承を元に表現
OS = Linux
Web = Apache
Application = PHP
DB = MySQL
というオーソドックスなLAMP構成
だったらしい・・・。

その頃のシステム構成は？（黎明期=5年前）
DMM.comのひとつのコンテンツとしてスタート
もともとDMMの持っていた機能を最初から利用できて便利
ゲーム用のサーバー構成も最小限

DMM GAMES 会員推移（拡大期）
52
145
360
460
940
1700
0
200
400
600
800
1000
1200
1400
1600
1800
2011 2012 2013 2014 2015 2016/7
会員数推移（単位/万人）
※DMM.comのではなくDMM GAMESの会員数
ヒットタイトルに恵まれ激増
プラットフォームも対応を迫られる
2017年1末時点では1800万人超

DMM GAMESのサービス増加（拡大期）
多彩なゲームを支えるための機能をどんどん追加
アプリゲーム
ゲームプレイヤー
コミュニティ機能、ミッション機能…その他多数

会員、サービスの増加に対応（サーバー）
サーバー台数を倍々に増やしていく！

会員、サービスの増加に対応（システム）
負荷対策
解析対象データ量の増加
キャッシュ導入・増設
データの持ち方を一部RDBからNoSQLへ
Hadoop導入

そして現在

現行システム構成（構成図）
無理やり簡略化した図
でも、実際は・・・
サーバー台数合計約900台
Web/App 500台
DB 150台
memcached 30台
redis 50台
他いろいろ 170台

ラットフォームで安定的に提供していま
す。
About DMM.com
DMM
GAMES

• 一日を通して負荷がある
この例だと一番低い時で1600アクセス/秒
• イベント時に負荷が跳ね上がる
• ピーク時で10万アクセス/秒
現行システム構成（負荷の特徴）
※↑このグラフはアクセス数のグラフではありません

サービス拡大から現在までの失敗（その１）
ゲームリリース時の負荷に耐えられず、急いでCDN投入
とあるゲームのサービス開始時にそのゲーム用に
準備していたダウンロード用のキャッシュサー
バーとの通信量で40Gbpsが埋まる！

サービス拡大から現在までの失敗（その１）
ゲームリリース時の負荷に耐えられず、急いでCDN投入
急いでそのゲームだけCDNに切り替えてしのいだ
結果としてはCDN側で125Gbpsとなった！

サービス拡大から現在までの失敗（その２）
応答性能の限界・・・
DB設計の問題等あり、MySQLへクエリを発行していた
のでは遅すぎる状況
よし、NoSQLだ！

データ構造や保守性、可用性などを考慮し
Redisを選択
さらにRedis Cluster組めばスケール
アウトもしやすいぞ！

PHPが古すぎてRedisのドライバー（phpredis)
がRedis Clusterに対応していない…
twemproxyってのを使えばRedis
をCluster構成でつかえるっぽい！

本番でtwemproxyが詰まる
twemproxyのサーバーをむっちゃ
増やしてしのぐ
負荷試験が足りてなかった・・・

これまでの苦労・失敗を振り返ってみると
お気づきでしょうか？
• 色々、試行錯誤し創意工夫はしたつもりだが…
• 直近の問題に対応することを優先してきた
• 部署として意識が機能拡充に寄っていた
• 結果的にはサーバー台数を増やして物理で殴るみたい
な方向が多い…

現行システム構成（課題-その１）
システム構成の根本はそのままにスケールアップ・スケールアウトしてきた
大規模に適したアーキテクチャか？
人気タイトルの影響を他タイトルも受けてしまう

現行システム構成（課題-その２）
DMM本体との密結合のデメリットが顕著になってきた
DMM本体と影響を与え合ってしまう
変更時の影響範囲が見えづらい

現行システム構成（課題-その３）
技術的負債がたまりつつある
たぶん使ってないんだよなーっという処理（でも怖くて消せない）
依存関係を整理して分割したい巨大処理（でも怖くて出来ない）

DMM GAMES
プラットフォーム
リプレイス開始！

ところでリプレイスするって勇気必要ですよね？
壊して作り直しはソフトウェアエンジニアの悪弊とも言われる
既に、動いているものをリスクを取って作り直す判断に何故至ったか？

なぜリプレイスするのか？
上記から課題解決の手段として移行（リプレイス）が最適だった
密結合な状態から脱しないと、新しいチャレンジがしづらい状況
現行システムに手を加えるコストとリプレイスのコストの比較検討の結果
既存の課題の原因を分析していくと・・・
DMM.com本体との密結合な状態が根本の問題

リプレイスに踏み込めた背景
やるべき事をやり始めるまでに時間をかけすぎない文化
とりあえずやってみるが(ある程度)許容される文化
プレゼン、稟議、承認などの手続きの繰り返しの間に機会を逃す方がリスク
調査・検証の間にプロダクトも変わっていく
時間をかけすぎるより、やってみて知見を得て改善する方を選択！

リプレイス範囲は？
Front
Application
Backend/Data

リプレイス方針
システムを止めずに移行する
マイクロサービス化
ゲーム・ユーザーに影響を与えない！
現構成の反省を踏まえ疎結合な形へ

システムを止めずにリプレイスする工夫
機能単位でサブドメイン化
画面単位、ゲームタイトル単位で少しづつ移行
• トップ
• コミュ
ニティ
機能
• 実行ページ
• ゲーム一覧
画面
• 艦これ
• 刀剣
ゲーム
サーバー構成もサブドメイン単位としデプロイ範囲を限定

リプレイスに際してのアーキテクチャ等
DDDの思想を取り入れたアプリケーション設計
各種環境の最新化
Agile / Scrumの積極的な導入
エンジニアがそれぞれで開発し設計思想がバラバラだった反省を踏まえ、筋の通った
設計思想で統一を図る必要があった
セキュリティ面や性能等様々理由でもともと最新化したかった
すでに部分的に導入しているチームあったがより大々的に
機能単位でリプレイスして早いサイクルでものを作るという進め方に合っていた

リプレイスに際してのアーキテクチャ等
キャッシュミドルウェアの変更（memcached -> redis）
ユニットテスト
デプロイシステム刷新
プルリク、レビュー
スケールアウトや可用性、既に導入済みの運用面などから総合的に判断
変更時の影響範囲確認や変更スピード、モダンな開発スタイルへ
「ぜんぜんわからない俺たちは雰囲気でレビューをやっている」
独自デプロイシステムからJenkinsへ（融通がきかなかった）

DDDを取り入れた設計
我々に合った形でとりいれてみた
• ドメインのあり方…

外部システムとの差異吸収
• データの持ち方
• エラーハンドリング

データアクセス部分
• 今後のバックエンドリプレイスを考慮

リプレイス後（アプリケーション構成）

システム構成（リプレイス前）

システム構成（リプレイス中=現在）

システム構成（リプレイス後）

リプレイス開発で巻き起こる宗教戦争
ORマッパー派、反ORマッパー派
Joinの数はどこまでOKか？
Query Builder というちょっとORMなもので落ち着く（必要に応じて生SQLもOK）
理由：DBを変えずに現行クエリを移植しているがORMに合わないクエリも多いため
４テーブル以上は要相談という形へ
理由：master,master,関連テーブルの形が多いため

リプレイス開発で巻き起こる宗教戦争
IDE派、エディタ派
大クラス主義、小クラス主義
お好みで（Vim, Atom, Eclipse, NetBeans, PhpStormが乱立、戦国時代へ）
理由：何で作ろうと本人が生産性高いやり方でやればOKということに
基本的には小クラス主義で
理由：テスト、レビューを考慮するとスコープが広い形では回らないので

リプレイスの苦労話
既存仕様の確認が大変
テストが大変
コードが仕様書な状態、既存コードを読み解くのは苦痛
１画面と思って軽く考えていたら思わぬ機能がモリモリ
密結合だった機能をテストできる形へ移植する作業
そもそも、テストが無かったのでどうテストする？という意識合わせが大変

リプレイスの苦労話もっと色々
新、旧両方の環境へ機能追加が必要
開発環境の構築が大変
開発中の機能追加は新旧両方にしなければならない
新旧の連動があるため、両方の環境を整えた

見えてきたメリット
品質を担保する仕組みを新たに導入できた
仕様、システムの見える化が進んだ
ライブラリ等のバージョンアップが容易になった
新しいチャレンジがしやすくなった！
レビュー、テストというプロセスが定着
リプレイス時に否が応でも棚卸しが必要だったため
疎結合になったため
変更のコストや数々のしがらみから、かなり自由になった

見えてきたメリット
品質を担保する仕組みを新たに導入できた
仕様、システムの見える化が進んだ
ライブラリ等のバージョンアップが容易になった
新しいチャレンジがしやすくなった！
レビュー、テストというプロセスが定着
リプレイス時に否が応でも棚卸しが必要だったため
疎結合になったため
変更のコストや数々のしがらみから、かなり自由になった
リプレイスはまだまだ進行中！

リプレイスして良かったこと（個人的）
テストテストテストテスト
ユニットテストが無かった頃ユニットテストが増えてきた

本日お話できなかったこと
Laravelで組んでいての困った所やtipsなど
システムを構成する各ツールの細かい所（MySQL,Redis,Nginx, .etc)
続きは懇親会で！
PHPUnitでごりごりテスト書いてるけどうちではこうやってるよという話

まとめ
「事業が拡大している時こそ先を見据えるべき」という
教訓をリプレイスという機会に生かして、新しい事にど
んどんチャレンジできると私はワクワクしています！

余談
／:∪::─ﾆjjﾆ─ヾガクガクブルブル…
／:::li|.:（ ○）三（○）＼
（:::||!.:∪::::: （__人__）):::: i| ＿＿＿＿
）::::::::::::: |r┬-| li::::/ | |
／::::::::::::::: `ー ‘ ::::::ヽ | |
艦これイベント開始-メンテ明け時の我々の様子
このドキドキを共有してくれる仲間を募集してます！

ご清聴ありがとうございました。
M( _ _ )M

DMMのゲームプラットフォームで利用している技術やシステム構成、レガシーシステムが抱える課題、解決のためのシステムリプレイスの進め方

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a DMMのゲームプラットフォームで利用している技術やシステム構成、レガシーシステムが抱える課題、解決のためのシステムリプレイスの進め方

Semelhante a DMMのゲームプラットフォームで利用している技術やシステム構成、レガシーシステムが抱える課題、解決のためのシステムリプレイスの進め方 (20)

DMMのゲームプラットフォームで利用している技術やシステム構成、レガシーシステムが抱える課題、解決のためのシステムリプレイスの進め方