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.

剣と魔法のログレスーMmoの継続的な改善と運用

14,036 views

Published on

2016.3.5
GAME CREATORS CONFERENCE'16

Published in: Engineering
  • Dating direct: ♥♥♥ http://bit.ly/2ZDZFYj ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area is here: ❤❤❤ http://bit.ly/2ZDZFYj ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

剣と魔法のログレスーMmoの継続的な改善と運用

  1. 1. 剣と魔法のログレス MMOの継続的な改善と運用 株式会社 Aiming 山藤 智之
  2. 2. 紹介
  3. 3. 本人の説明 • 山藤 智之(やまふじ さとし) • 株式会社 Aiming所属 • 携わった作品 • BladeChronicle • 剣と魔法のログレス • 剣と魔法のログレス – いにしえの女神 – • ゲーム業界入る前はWEB関係
  4. 4. Aiming? •オンラインゲームの会社 •開発から運営業務まで一通り
  5. 5. ログレス? •剣と魔法のログレス – いにしえの女神 – • マーベラス様との共同開発 • Android, iOS でサービス中 • 2013年末より日本でサービス開始 • 2015年10月より台湾でサービス開始 • 国内累計750万DL達成 ©Marvelous Inc.©Aiming inc.
  6. 6. ログレス? •MMORPG •一緒に冒険 / 一緒に会話 / 一緒に共闘 ©Marvelous Inc.©Aiming inc.
  7. 7. どんなゲーム? •MMORPG • 多彩なアバター • ストーリー • 多彩なスキル • 仲間と共闘 • 仲間とチャット •常時接続型 ©Marvelous Inc.©Aiming inc.
  8. 8. • リリース管理 • Gitによるリリース管理 • アーキテクチャ • ゲームサーバ • APIサーバ • 運営に伴う構成変更 • 継続的な改善と運用
  9. 9. リリース管理
  10. 10. •チーム開発を行う以上、必要になるソフトウェア のバージョンは職種(用途)によって異なります •エンドユーザーが遊ぶバージョンも含めて環境を 分け、デプロイされるプログラム管理を行ってい ます。 リリース管理
  11. 11. リリース管理 開発 協力会社 ユーザー
  12. 12. リリース管理 開発 協力会社 日々の開発 開発環境 ユーザー
  13. 13. リリース管理 開発 協力会社 日々の開発 データワーク 開発環境 データワーク環境 ユーザー
  14. 14. リリース管理 開発 協力会社 日々の開発 データワーク 広告や審査 開発環境 データワーク環境 審査環境 ユーザー
  15. 15. リリース管理 ユーザー 開発 協力会社 日々の開発 データワーク 実際に遊ぶ 広告や審査 開発環境 データワーク環境 審査環境 サービス環境
  16. 16. リリース管理 ユーザー 開発 協力会社 日々の開発 データワーク 実際に遊ぶ 広告や審査 開発環境 データワーク環境 審査環境 サービス環境 緊急対応環境 バグFIX
  17. 17. リリース管理 環境 安定度 用途 開発環境 最低 エンジニアの日々の開発 開発しながらのセルフデバッグ データワーク環境 低い 少し落ち着いてデータ設定ができる 同時にデバックも行っている 審査環境 安定 iOS審査、各種媒体への広告 サービス環境 安定 お客様が遊ぶ 緊急対応環境 安定+ サービスVerに問題が起こった時の 検証・デバッグ・テスト *何も問題が無い時はサービス環境と同等
  18. 18. リリース管理 •開発の段階毎に環境がある •段階が進むにつれプログラムの安定度が上がる様 に •サービス環境は社内にミラーが存在する(検証作 業等でサービス環境に影響を与えないため)
  19. 19. Gitによるリリース管理
  20. 20. Gitによるリリース管理 •環境に合わせてデプロイするプログラムを変える為 、これらを適切に切り分けてます • 今現在サービス中の物 • クリティカルバグが修正された物 • 審査に提出した、次回公開予定の物 • 次回審査提出用の物(開発中の物)
  21. 21. Gitによるリリース管理 master release Client_hot_fix
  22. 22. Gitによるリリース管理 Ver 2.0.0 審査提出時にTagを打 つ master release Client_hot_fix
  23. 23. 必要な開発は進む Gitによるリリース管理 A Ver 2.0.0 master release Client_hot_fix
  24. 24. release Client_hot_fix Releaseに急遽必要になったコミット Gitによるリリース管理 B A Ver 2.0.0 公開手前でブランチが作られる master
  25. 25. 必要な物はチェリーピック Gitによるリリース管理 A’B A Ver 2.0.0 master release Client_hot_fix
  26. 26. Gitによるリリース管理 A’B A Ver 2.0.0 完全に新しい物は、使い捨てトピックブランチを作っ てプロトタイプ開発 master release Client_hot_fix
  27. 27. Gitによるリリース管理 A’B A C Ver 2.0.0 バグFIX master release Client_hot_fix
  28. 28. Gitによるリリース管理 A’B A C’ C Ver 2.0.0 バグFIX master release Client_hot_fix
  29. 29. Gitによるリリース管理 A’B A C’ C Ver 2.0.0 D Ver 2.0.1 master release Client_hot_fix バグFIX
  30. 30. Client_hot_fix Gitによるリリース管理 A’B D’A C’ C Ver 2.0.0 D Ver 2.0.1バグFIX master release
  31. 31. Gitによるリリース管理 A’B D’A C’ C Ver 2.0.0 Ver 2.1.0 D Ver 2.0.1 審査提出時にTagを打 つ master release Client_hot_fix
  32. 32. Gitによるリリース管理 A’B D’A C’ B C Ver 2.0.0 Ver 2.1.0 D Ver 2.0.1 公開手前でrebaseして作る コミットA,Cが含まれている状態 master release Client_hot_fix
  33. 33. Gitによるリリース管理 A’B D’A C’ B C Ver 2.0.0 Ver 2.1.0 D Ver 2.0.1 master release Client_hot_fix
  34. 34. Gitによるリリース管理 • 開発は基本 master 一本 • 複数ラインができる程大きなチームでもない • クライアント公開バージョンが決まったタイミングではタグだけ打つ • 公開されるタイミングで releaseブランチが切られる • その際、過去の release ブランチから歴史は継承(rebase される) • トピックブランチは原則使い捨て • 古くなったコードはテキストベースではマージできても、論理的に動かない可能 性がある
  35. 35. アーキテクチャ
  36. 36. ワールド ワールド ワールド アーキテクチャ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  37. 37. ワールド ワールド ワールド アーキテクチャ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  38. 38. ワールド ワールド ワールド アーキテクチャ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  39. 39. ワールド ワールド ワールド アーキテクチャ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  40. 40. ワールド ワールド ワールド アーキテクチャ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  41. 41. ワールド ワールド ワールド アーキテクチャ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  42. 42. ワールド ワールド ワールド アーキテクチャ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  43. 43. ワールド ワールド ワールド アーキテクチャ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  44. 44. アーキテクチャ 種類 言語 通信 用途 ゲームサーバ C++ TCP ゲームの根幹処理 密な同期が必要になる処理 APIサーバ Python HTTP 静的なデータのやり取り 密な同期が不要な処理 ゲームサーバ 制御用 C++ TCP ゲームサーバに特殊な命令を送る (ユーザーの強制退出等) *全ワールド共用 APIサーバ 認証用 Python HTTP アカウント認証サービス *全ワールド共用
  45. 45. アーキテクチャ •ゲームサーバ • ワールド共用で扱う物とワールド毎に扱う物がある • 常駐プロセスのゲームサーバとWEBベースのAPIサーバの2種 類がある •ゲームクライアント • 処理の種類によって通信系統を切替て使う
  46. 46. ゲームサーバ
  47. 47. ワールド ワールド ワールド ゲームサーバ ワールド APIサーバ ステートレス 認証サービス APIサーバ ステートレス ゲームサーバ ステートフル ゲームサーバ ステートフル
  48. 48. プロセス 役割 GAME ゲームの大筋の処理(移動・戦闘・・・etc) ZONE GMSV間をキャラクターが移動する際のデータ転送 MSG (MRS, MSS) 2つ合わせてチャットメッセージサーバ CHANNEL ワールド上の全てのマップ管理 (どのGMSVにどのMAPがある?) CHAT 制御コマンドのBloadcast PARTY パーティを管理 QUEST ワールド中に発令されているクエストを管理 RANK ランキング情報を取り扱う MATCHING PvP用マッチングサーバ MANAGE アカウントの認証、日本版では魔晶石の管理 *全ワールド共用 ゲームサーバ
  49. 49. ゲームサーバ
  50. 50. ゲームサーバ
  51. 51. ゲームサーバ
  52. 52. ゲームサーバ これが一つのワールド
  53. 53. ゲームサーバ ワールドが増えてもココは増えない
  54. 54. ゲームサーバ 必要な時だけ接続 ログインしている間は常時接続
  55. 55. ゲームサーバ ルーム移動の際に張り替える
  56. 56. ゲームサーバ •機能毎にいくつかのプロセスが存在する • クライアントが接続するのはGAMEプロセスのみ • サーバ側でもGAMEプロセスをクライントとしてC/S 構成が作られている •幾つかのプロセスで1つのワールド構成している •全ワールド共通で使われるプロセスがある
  57. 57. APIサーバ
  58. 58. ワールド ワールド ワールド APIサーバ ワールド ゲームサーバ ステートフル APIサーバ ステートレス 認証サービス ゲームサーバ ステートフル APIサーバ ステートレス
  59. 59. HTTPD APIサーバ APIアプリケーション worker worker worker worker mod_wsgi DB •Apache(worker), mod_wsgiを使用
  60. 60. HTTPD APIサーバ APIアプリケーション worker worker worker worker mod_wsgi DB •Apache(worker), mod_wsgiを使用 Deamonとして動作
  61. 61. HTTPD APIサーバ APIアプリケーション worker worker worker worker mod_wsgi DB •Apache(worker), mod_wsgiを使用 APIアプリケーション DB
  62. 62. APIサーバ APIサーバ •問い合わせ先の決定方法 サーバ APIサーバ アイテム:api1.hogefuga/item/ キャラクター:api1.hogefuga/char/ ランキング:api2.hogefuga/ranking/
  63. 63. APIサーバ •問い合わせ先の決定方法 サーバ APIサーバ APIサーバ アイテム
  64. 64. APIサーバ •問い合わせ先の決定方法 サーバ APIサーバ APIサーバ アイテム キャラクター
  65. 65. APIサーバ •問い合わせ先の決定方法 サーバ APIサーバ APIサーバ ランキング アイテム キャラクター
  66. 66. APIサーバの負荷分散 WEB WEB WEB WEB WEB WEB WEB WEB api.hogefuga/* •問い合わせ先の変更と負荷分散
  67. 67. APIサーバの負荷分散 WEB WEB WEB WEB WEB WEB WEB WEB api.hogefuga/* item-api.hogefuga/* •問い合わせ先の変更と負荷分散
  68. 68. APIサーバの負荷分散 WEB WEB WEB WEB WEB WEB WEB WEB api.hogefuga/* item-api.hogefuga/* •問い合わせ先の変更と負荷分散
  69. 69. APIサーバ •memcachedとかは使ってない •必要なデータはAPIアプリケーションのメモリに持 ってしまう物もある •機能毎にURLを設定できる様になっている • ゲームクライアントは起動時に、この設定をサーバから受信す る。
  70. 70. 運営に伴う構成変更
  71. 71. 運営に伴う構成変更 •ワールド数とアクティブユーザー遷移 2013/12 2014/1 2014/2 2014/3 2014/4 2014/5 2014/6 2014/7 2014/8 2014/9 2014/10 2014/11 2014/12 2015/1 2015/2 2015/3 2015/4 2015/5
  72. 72. 運営に伴う構成変更 •ワールド数とアクティブユーザー遷移 2013/12 2014/1 2014/2 2014/3 2014/4 2014/5 2014/6 2014/7 2014/8 2014/9 2014/10 2014/11 2014/12 2015/1 2015/2 2015/3 2015/4 2015/5 TVCM放送開始
  73. 73. 運営に伴う構成変更 •ワールド数とアクティブユーザー遷移 2013/12 2014/1 2014/2 2014/3 2014/4 2014/5 2014/6 2014/7 2014/8 2014/9 2014/10 2014/11 2014/12 2015/1 2015/2 2015/3 2015/4 2015/5 TVCM放送開始
  74. 74. サーバ構成 2013/09 CM
  75. 75. サーバ構成 2013/12 CM
  76. 76. サーバ構成 2014/01 CM
  77. 77. サーバ構成 2014/07 CM
  78. 78. サーバ構成 2014/09 CM
  79. 79. サーバ構成 2014/09 CM
  80. 80. サーバ構成 2014/09 WEB WEB WEB WEB WEB WEB WEB WEB api.hogefuga/* auth.hogefuga/*
  81. 81. サーバ構成 2014/09 WEB WEB WEB WEB WEB WEB WEB WEB api.hogefuga/* auth.hogefuga/*
  82. 82. サーバ構成 2014/09 CM
  83. 83. サーバ構成 2015/01 CM
  84. 84. サーバ構成 現在 CM
  85. 85. サーバ構成 現在 CM
  86. 86. 運営に伴う構成変更 • 1ワールドの同時接続への対応 • GMSV、WEBAPIサーバのスケールアウト • DBの垂直分割 • ワールド追加への対応 • 認証APIの分離 • その他 • Slave-DBの増設(運営ツール用途)
  87. 87. 今の設計・構成の問題点 •ワールド共用部分への負荷が増えてきてる •ワールド内のDBを水平スケールしようとするとコ ストが高い • ゲームサーバがDBを操作している •APIサーバの平均稼働率がやや低い • ハードウェアリソースが余っている
  88. 88. 継続的な改善と運用
  89. 89. 継続的な改善と運用 •エンジニアリング以外の部分でも継続的な改善は 必要 • ゲームバランスは日々変わっていきます • 最初は良いバランスだった物も、時間の経過と共に少 しずつズレが生じてくる
  90. 90. • 時間が経つにつれプレーヤーが資産を貯めていく • ゲーム内マネー • 所有アイテム • 強力な武器/防具 • プレーヤー自身のレベル/能力 • プレーヤーが強くなる事でエネミーが相対的に弱くなる 継続的な改善と運用
  91. 91. 継続的な改善と運用 •時間が経つにつれプレーヤーが集まる場所も変わ っていく • 新しい場所に人が集まる • 美味しい狩場に人が集まる •人が少なくなる事でエネミーが相対的に強くなる
  92. 92. 継続的な改善と運用 •後から始めるプレーヤーにも気持ち良く遊んでも らえるように • 早く強くなれる(追いつける)仕組み • 上級者プレーヤーと後発プレーヤーの交流導線 • クエストの難易度調整
  93. 93. 継続的な改善と運用 •新しいユーザーを獲得する為の施策 • 各種CM •休眠ユーザーに対したイベント • カムバックイベント •ユーザーを獲得するタイミングに合わせたハード ウェアの準備、ソフトウェアのチューニング
  94. 94. 継続的な改善と運用 • まとめ • いくつかの用途に分けた環境の運用 • それらを管理する為のGitの運用 • プロセス特性に合わせたハードウェア構成 • マーケティング施策に合わせた対応 • ゲーム内の状況に合わせた改善
  95. 95. なんと言うか・・・
  96. 96. MMOは・・・
  97. 97. 生き物ですっ!!
  98. 98. 最後に・・・
  99. 99. 仲間募集! •Aimingではエンジニアに限らず、各職種人材を募集 しております! •一緒に面白いゲーム作って盛り上げていきましょう ! •http://aiming-inc.com/
  100. 100. 御清聴ありがとうございました
  101. 101. 質疑応答

×