Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,969 views

Published on

「複雑・大規模webサービスを支える技術勉強会」の発表資料。
・イベントページURL
https://eventdots.jp/event/610781

Published in: Engineering
  • Be the first to comment

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

  1. 1. DMMのゲームプラットフォームで利用 している技術やシステム構成、レガ シーシステムが抱える課題、解決のた めのシステムリプレイスの進め方 DMM.com Labo オンライゲーム事業部プラットフォーム開発本部 久保田亙 2017/02/07 dots
  2. 2. • 名前:久保田亙 • 会社:DMM.com Labo • 2015/08 入社 • プログラマー • 好きなデザインパターン:ゴッドオブジェクト • 口癖:「テストがないと死ぬ病気にかかっています。」 Copyright © since 1998 DMM All Rights Reserved. 2 自己紹介
  3. 3. Copyright © since 1998 DMM All Rights Reserved. 3 本日みなさんへお伝えする内容 DMM GAMES プラットフォームとは? DMM GAMES プラットフォームの歴史(変遷) DMM GAMES プラットフォームのシステム構成 DMM GAMES プラットフォームのシステムリプレイス
  4. 4. Copyright © since 1998 DMM All Rights Reserved. 4 DMM.comは1999年から続く老舗サービ スサイトです。時代のニーズに合わせた多 彩なコンテンツを、18年間培った独自プ ラットフォームで安定的に提供しています。 About DMM.com 40以上の幅広いサービスを展開 サービスについて
  5. 5. Copyright © since 1998 DMM All Rights Reserved. 5 DMM.comは1999年から続く老舗サービ スサイトです。時代のニーズに合わせた多 彩なコンテンツを、18年間培った独自プ ラットフォームで安定的に提供しています。 About DMM.com 40以上の幅広いサービスを展開 サービスについて DMM GAMES
  6. 6. DMM GAMESとは PCをメインにスマートフォン、フィーチャーフォンの3デバイスにまたがって みんなで遊べるオンライゲームを提供しています。 Copyright © since 1998 DMM All Rights Reserved. 6 世界中の大人に興奮を! 人気タイトルあります! 様々なデバイス イベント随時開催
  7. 7. DMM GAMES プラットフォームとは DMM GAMESで様々なゲームを提供するための土台 Copyright © since 1998 DMM All Rights Reserved. 7 全てのゲームを 遊びやすいように、たのしめる ようにする機能群 -> トップページ、ゲーム一覧など デバイスの違い 同一アカウントで複数デバイス のゲームの仕組み 裏では データ解析、ログ基盤、バッチ 処理 ゲームするための共通機能を提供(プロフィール管理、ポイント、課金など) 海外向けプラットフォームやゲームストア、ゲームプレイヤーも
  8. 8. Copyright © since 1998 DMM All Rights Reserved. 8 DMM GAMESプラットフォームを支える技術 さまざまなツール類を利用
  9. 9. Copyright © since 1998 DMM All Rights Reserved. 9 最初のシステム構成は?(黎明期=5年前) 資料がみつからず伝承を元に表現 OS = Linux Web = Apache Application = PHP DB = MySQL というオーソドックスなLAMP構成 だったらしい・・・。
  10. 10. Copyright © since 1998 DMM All Rights Reserved. 10 その頃のシステム構成は?(黎明期=5年前) DMM.comのひとつのコンテンツとしてスタート もともとDMMの持っていた機能を最初から利用できて便利 ゲーム用のサーバー構成も最小限
  11. 11. Copyright © since 1998 DMM All Rights Reserved. 11 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万人超
  12. 12. Copyright © since 1998 DMM All Rights Reserved. 12 DMM GAMESのサービス増加(拡大期) 多彩なゲームを支えるための機能をどんどん追加 アプリゲーム ゲームプレイヤー コミュニティ機能、ミッション機能…その他多数
  13. 13. Copyright © since 1998 DMM All Rights Reserved. 13 会員、サービスの増加に対応(サーバー) サーバー台数を倍々に増やしていく!
  14. 14. Copyright © since 1998 DMM All Rights Reserved. 14 会員、サービスの増加に対応(システム) 負荷対策 解析対象データ量の増加 キャッシュ導入・増設 データの持ち方を一部RDBからNoSQLへ Hadoop導入
  15. 15. そして現在 Copyright © since 1998 DMM All Rights Reserved. 15
  16. 16. Copyright © since 1998 DMM All Rights Reserved. 16 現行システム構成 (構成図) 無理やり簡略化した図 でも、実際は・・・ サーバー台数合計約900台 Web/App 500台 DB 150台 memcached 30台 redis 50台 他いろいろ 170台
  17. 17. Copyright © since 1998 DMM All Rights Reserved. 17 DMM.comは1999年から続く老舗サービ スサイトです。時代のニーズに合わせた多 彩なコンテンツを、18年間培った独自プ ラットフォームで安定的に提供していま す。 About DMM.com 40以上の幅広いサービスを展開 サービスについて DMM GAMES
  18. 18. • 一日を通して負荷がある この例だと一番低い時で1600アクセス/秒 • イベント時に負荷が跳ね上がる • ピーク時で10万アクセス/秒 Copyright © since 1998 DMM All Rights Reserved. 18 現行システム構成(負荷の特徴) ※↑このグラフはアクセス数のグラフではありません
  19. 19. Copyright © since 1998 DMM All Rights Reserved. 19 サービス拡大から現在までの失敗(その1) ゲームリリース時の負荷に耐えられず、急いでCDN投入 とあるゲームのサービス開始時にそのゲーム用に 準備していたダウンロード用のキャッシュサー バーとの通信量で40Gbpsが埋まる!
  20. 20. Copyright © since 1998 DMM All Rights Reserved. 20 サービス拡大から現在までの失敗(その1) ゲームリリース時の負荷に耐えられず、急いでCDN投入 急いでそのゲームだけCDNに切り替えてしのいだ 結果としてはCDN側で125Gbpsとなった!
  21. 21. Copyright © since 1998 DMM All Rights Reserved. 21 サービス拡大から現在までの失敗(その2) 応答性能の限界・・・ DB設計の問題等あり、MySQLへクエリを発行していた のでは遅すぎる状況 よし、NoSQLだ!
  22. 22. Copyright © since 1998 DMM All Rights Reserved. 22 サービス拡大から現在までの失敗(その2) 応答性能の限界・・・ データ構造や保守性、可用性などを考慮し Redisを選択 さらにRedis Cluster組めばスケール アウトもしやすいぞ!
  23. 23. Copyright © since 1998 DMM All Rights Reserved. 23 サービス拡大から現在までの失敗(その2) 応答性能の限界・・・ PHPが古すぎてRedisのドライバー(phpredis) がRedis Clusterに対応していない… twemproxyってのを使えばRedis をCluster構成でつかえるっぽい!
  24. 24. Copyright © since 1998 DMM All Rights Reserved. 24 サービス拡大から現在までの失敗(その2) 応答性能の限界・・・ 本番でtwemproxyが詰まる twemproxyのサーバーをむっちゃ 増やしてしのぐ 負荷試験が足りてなかった・・・
  25. 25. Copyright © since 1998 DMM All Rights Reserved. 25 これまでの苦労・失敗を振り返ってみると お気づきでしょうか? • 色々、試行錯誤し創意工夫はしたつもりだが… • 直近の問題に対応することを優先してきた • 部署として意識が機能拡充に寄っていた • 結果的にはサーバー台数を増やして物理で殴るみたい な方向が多い…
  26. 26. Copyright © since 1998 DMM All Rights Reserved. 26 現行システム構成(課題-その1) システム構成の根本はそのままにスケールアップ・スケールアウトしてきた 大規模に適したアーキテクチャか? 人気タイトルの影響を他タイトルも受けてしまう
  27. 27. Copyright © since 1998 DMM All Rights Reserved. 27 現行システム構成(課題-その2) DMM本体との密結合のデメリットが顕著になってきた DMM本体と影響を与え合ってしまう 変更時の影響範囲が見えづらい
  28. 28. Copyright © since 1998 DMM All Rights Reserved. 28 現行システム構成(課題-その3) 技術的負債がたまりつつある たぶん使ってないんだよなーっという処理(でも怖くて消せない) 依存関係を整理して分割したい巨大処理(でも怖くて出来ない)
  29. 29. DMM GAMES プラットフォーム リプレイス開始! Copyright © since 1998 DMM All Rights Reserved. 29
  30. 30. Copyright © since 1998 DMM All Rights Reserved. 30 ところでリプレイスするって勇気必要ですよね? 壊して作り直しはソフトウェアエンジニアの悪弊とも言われる 既に、動いているものをリスクを取って作り直す判断に何故至ったか?
  31. 31. Copyright © since 1998 DMM All Rights Reserved. 31 なぜリプレイスするのか? 上記から課題解決の手段として移行(リプレイス)が最適だった 密結合な状態から脱しないと、新しいチャレンジがしづらい状況 現行システムに手を加えるコストとリプレイスのコストの比較検討の結果 既存の課題の原因を分析していくと・・・ DMM.com本体との密結合な状態が根本の問題
  32. 32. Copyright © since 1998 DMM All Rights Reserved. 32 リプレイスに踏み込めた背景 やるべき事をやり始めるまでに時間をかけすぎない文化 とりあえずやってみるが(ある程度)許容される文化 プレゼン、稟議、承認などの手続きの繰り返しの間に機会を逃す方がリスク 調査・検証の間にプロダクトも変わっていく 時間をかけすぎるより、やってみて知見を得て改善する方を選択!
  33. 33. Copyright © since 1998 DMM All Rights Reserved. 33 リプレイス範囲は? Front Application Backend/Data
  34. 34. Copyright © since 1998 DMM All Rights Reserved. 34 リプレイス方針 システムを止めずに移行する マイクロサービス化 ゲーム・ユーザーに影響を与えない! 現構成の反省を踏まえ疎結合な形へ
  35. 35. Copyright © since 1998 DMM All Rights Reserved. 35 システムを止めずにリプレイスする工夫 機能単位でサブドメイン化 画面単位、ゲームタイトル単位で少しづつ移行 • トップ • コミュ ニティ 機能 • 実行ページ • ゲーム一覧 画面 • 艦これ • 刀剣 ゲーム サーバー構成もサブドメイン単位としデプロイ範囲を限定
  36. 36. Copyright © since 1998 DMM All Rights Reserved. 36 リプレイスに際してのアーキテクチャ等 DDDの思想を取り入れたアプリケーション設計 各種環境の最新化 Agile / Scrumの積極的な導入 エンジニアがそれぞれで開発し設計思想がバラバラだった反省を踏まえ、筋の通った 設計思想で統一を図る必要があった セキュリティ面や性能等様々理由でもともと最新化したかった すでに部分的に導入しているチームあったがより大々的に 機能単位でリプレイスして早いサイクルでものを作るという進め方に合っていた
  37. 37. Copyright © since 1998 DMM All Rights Reserved. 37 リプレイスに際してのアーキテクチャ等 キャッシュミドルウェアの変更(memcached -> redis) ユニットテスト デプロイシステム刷新 プルリク、レビュー スケールアウトや可用性、既に導入済みの運用面などから総合的に判断 変更時の影響範囲確認や変更スピード、モダンな開発スタイルへ 「ぜんぜんわからない 俺たちは雰囲気でレビューをやっている」 独自デプロイシステムからJenkinsへ(融通がきかなかった)
  38. 38. Copyright © since 1998 DMM All Rights Reserved. 38 DDDを取り入れた設計 我々に合った形でとりいれてみた • ドメインのあり方…
  39. 39. Copyright © since 1998 DMM All Rights Reserved. 39 DDDを取り入れた設計 外部システムとの差異吸収 • データの持ち方 • エラーハンドリング
  40. 40. Copyright © since 1998 DMM All Rights Reserved. 40 DDDを取り入れた設計 データアクセス部分 • 今後のバックエンドリプレイスを考慮
  41. 41. Copyright © since 1998 DMM All Rights Reserved. 41 リプレイス後(アプリケーション構成)
  42. 42. Copyright © since 1998 DMM All Rights Reserved. 42 システム構成(リプレイス前)
  43. 43. Copyright © since 1998 DMM All Rights Reserved. 43 システム構成(リプレイス中=現在)
  44. 44. Copyright © since 1998 DMM All Rights Reserved. 44 システム構成(リプレイス後)
  45. 45. Copyright © since 1998 DMM All Rights Reserved. 45 リプレイス開発で巻き起こる宗教戦争 ORマッパー派、反ORマッパー派 Joinの数はどこまでOKか? Query Builder というちょっとORMなもので落ち着く(必要に応じて生SQLもOK) 理由:DBを変えずに現行クエリを移植しているがORMに合わないクエリも多いため 4テーブル以上は要相談という形へ 理由:master,master,関連テーブルの形が多いため
  46. 46. Copyright © since 1998 DMM All Rights Reserved. 46 リプレイス開発で巻き起こる宗教戦争 IDE派、エディタ派 大クラス主義、小クラス主義 お好みで(Vim, Atom, Eclipse, NetBeans, PhpStormが乱立、戦国時代へ) 理由:何で作ろうと本人が生産性高いやり方でやればOKということに 基本的には小クラス主義で 理由:テスト、レビューを考慮するとスコープが広い形では回らないので
  47. 47. Copyright © since 1998 DMM All Rights Reserved. 47 リプレイスの苦労話 既存仕様の確認が大変 テストが大変 コードが仕様書な状態、既存コードを読み解くのは苦痛 1画面と思って軽く考えていたら思わぬ機能がモリモリ 密結合だった機能をテストできる形へ移植する作業 そもそも、テストが無かったのでどうテストする?という意識合わせが大変
  48. 48. Copyright © since 1998 DMM All Rights Reserved. 48 リプレイスの苦労話もっと色々 新、旧両方の環境へ機能追加が必要 開発環境の構築が大変 開発中の機能追加は新旧両方にしなければならない 新旧の連動があるため、両方の環境を整えた
  49. 49. Copyright © since 1998 DMM All Rights Reserved. 49 見えてきたメリット 品質を担保する仕組みを新たに導入できた 仕様、システムの見える化が進んだ ライブラリ等のバージョンアップが容易になった 新しいチャレンジがしやすくなった! レビュー、テストというプロセスが定着 リプレイス時に否が応でも棚卸しが必要だったため 疎結合になったため 変更のコストや数々のしがらみから、かなり自由になった
  50. 50. Copyright © since 1998 DMM All Rights Reserved. 50 見えてきたメリット 品質を担保する仕組みを新たに導入できた 仕様、システムの見える化が進んだ ライブラリ等のバージョンアップが容易になった 新しいチャレンジがしやすくなった! レビュー、テストというプロセスが定着 リプレイス時に否が応でも棚卸しが必要だったため 疎結合になったため 変更のコストや数々のしがらみから、かなり自由になった リプレイスはまだまだ進行中!
  51. 51. Copyright © since 1998 DMM All Rights Reserved. 51 リプレイスして良かったこと(個人的) テストテストテストテスト ユニットテストが無かった頃 ユニットテストが増えてきた
  52. 52. Copyright © since 1998 DMM All Rights Reserved. 52 本日お話できなかったこと Laravelで組んでいての困った所やtipsなど システムを構成する各ツールの細かい所(MySQL,Redis,Nginx, .etc) 続きは懇親会で! PHPUnitでごりごりテスト書いてるけどうちではこうやってるよという話
  53. 53. Copyright © since 1998 DMM All Rights Reserved. 53 まとめ 「事業が拡大している時こそ先を見据えるべき」という 教訓をリプレイスという機会に生かして、新しい事にど んどんチャレンジできると私はワクワクしています!
  54. 54. Copyright © since 1998 DMM All Rights Reserved. 54 余談 /:∪::─ニjjニ─ヾ ガクガクブルブル… /:::li|.:( ○)三 (○)\ (:::||!.:∪::::: (__人__)):::: i| ____ )::::::::::::: |r┬-| li::::/ | | /::::::::::::::: `ー ‘ ::::::ヽ | | 艦これイベント開始-メンテ明け時の我々の様子 このドキドキを共有してくれる仲間を募集してます!
  55. 55. ご清聴ありがとうございました。 M( _ _ )M

×