CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例

Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved.Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved.
大規模モバイルゲーム
運用における
マスタデータ管理事例
Sep 6, 2019
Hitonishi Masaki
ゲーム・エンターテインメント事業本部
DeNA Co., Ltd.
1

Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved.
自己紹介
 人西聖樹(Hitonishi Masaki)
 ゲーム事業部共通基盤部
⁃ ゲームタイトル横断で使われるライブラリやツールを開発
する部署
 経歴
⁃ Mobage の大規模ゲームタイトルの開発・運用
⁃ 共通基盤部に異動して共通システムの新規開発
 趣味
⁃ インディーゲーム制作

はじめに
近年のモバイルゲーム開発では
⁃ 大規模開発化に伴い作業者の増加
⁃ それに伴うワークフローの複雑化
モバイルゲームでは特にリリース後も継続してアップデート
を続けていく
マスタデータ管理およびワークフロー構築は重要な分野だが、
以外に世に落ちている情報は少ない
3

はじめに
本セッションの内容
⁃ まず弊社のこれまでのマスタデータ管理およびワークフロー構築
の取り組みを述べる
⁃ 今後の展望として、現在開発しているマスタデータ管理システム
について説明する
4

今日話すことのスコープの話
ゲーム開発者
(プランナー)
入力反映
入力からゲームに反映するまでの流れ
ここをどうしようとしているかの話
ゲーム

アジェンダ
 マスタデータとは
 DeNAにおけるこれまでのマスタデータ管理の歴史
⁃ ブラウザゲーム時代
⁃ ガワネイティブ時代
⁃ ネイティブアプリ時代
 マスタデータ管理システム Oyakata について
⁃ システムについて
⁃ 導入してみて
 まとめ
6

マスタデータとは
 本セッションではモバイルゲームの運用において、デプロイ時点で運営側が先に
用意しているアセット群のうち、文字列で表現されるデータ群のことを指す。
 ユーザー起因によって変わらず、運営側によってのみ変更されることがある
ReadOnlyなデータ
 プレイヤーごとに値が変化するデータは含めない
 画像や3Dモデルのようなアセットは含めない
7

 ゲームの動作やバランスを決定するためにあらかじめ設定しておくパラメータ。
 表形式で表せる構造にすることが多い。
 多くのモバイルゲームは、アプリ起動時に最新のマスターデータをダウンロード
し、そのデータを参照しながら動作します。また、サーバー側のプログラムも、
同様にマスターデータを参照する。
 プログラムとマスターデータを分離しておくことで、マスターデータ部分は非プ
ログラマでも容易に変更できる。
 マスターデータの更新だけで済む場合は、アプリのバージョンアップを回避でき
る（アプリのバージョンアップは、Appleの審査を通したりしなければならず時間
がかかる）
8

9
「武器」マスターの skill_id 列に入っているのは「必殺技」マスターの ID。
このように、あるマスタが別のマスタへの参照を持つことは非常に多い。
(本セッションではリレーションと呼ぶ)

マスタデータの一般的なワークフロー
10
①マスタデータを入力する
②ランタイムの形式に変換する
③ゲーム上で手触りを確かめる
⑤本番環境にデプロイ
④マスタデータを修正する

マスタデータの役割
 ユーザのプレイサイクルをデザインする
⁃ ユーザ体験のうち、UIとか画像とか音楽のような目や耳で感じる以外のところ全般
⁃ ステージクリアや、レベルアップのテンポだったり
⁃ アイテムや必殺技、魔法などの種類とか性能だったり
⁃ 敵の強さの調整だったり
⁃ 会話やチュートリアルなどの説明だったり
 モバイルゲームでは特に大事
⁃ 新しいイベントやステージを(アプリ本体の更新なしに)追加したり
⁃ ユーザが挫折しやすいポイントがあれば、それを修正したり
11

DeNA におけるこれまでの
マスタデータ管理の歴史
12

ブラウザゲーム時代
 チーム人数30名程度(うちプランナー10名程度)
 Webアプリケーション
⁃ クライアント側は HTML + CSS + JavaScript
⁃ サーバー側は Linux + Apache + MySQL + Perl(PHP)という構成
 Excel ファイルを共有ファイルサーバーでマスタデータ管理している。
 データの反映・閲覧は、ゲーム毎に独自に存在する管理用Webアプリ
13

 マスタ作成フローの概要
⁃ マスタの種類ごとにエクセルファイルが存在し、ファイルサーバーで管理されている。
⁃ 作業者ごとに確認用のゲームサーバーが割り当てられており、その時点でのリリースバージョ
ンにセットアップされている。
⁃ 作業としてはエクセルファイルを編集した上で保存し、自前のwebアプリを経由して特定環境
のDBに反映する。
14
⁃ ブラウザゲームなので、モバイル端末のブラ
ウザ経由で該当のゲームサーバーにアクセス
して動作確認をする。これを繰り返す。
⁃ 満足したら、mysqldumpでcsv化し、git管理
下に配備する。
⁃ 最終的にcsvをmysqlに突っ込むことでマスタ
データの本番反映を行う。

 マスタの管理
⁃ 運用時に追加するマスタの多くは一時的にしか必要ないものという認識
• ゲームのイベントごとに、DBテーブルを新規してマスタを追加し、イベントが終わればDB
テーブルを削除していた
• 共通テーブルにマスタを追加する時は同時編集に気をつけてマスタを追加していた
⁃ 声かけなどでカバー
⁃ チーム人数が少ないうちはワークしていたが、多くなってくると当然うまく行かなく
なってくる
⁃ 独自の管理画面で、マスタの投入・閲覧
• テーブルを追加するたびに、管理画面も実装しないといけない
• 個別にリレーション先のテーブルも見られるように実装したり
15

 マスタの入力
 データが肥大化すると、エクセルシートをマクロや関数でカスタマイズして「入力が必要な箇
所」をできるだけ減らして、作業内容を単純化することで回避していた。
⁃ そうしたナレッジが人に依存しており、引き継ぎで継承されないことが多い(そして誤ったデータ入力につながる)
 基本的に作業の分業はリリースバージョンごとであり、リリースバージョンごとにシートが分か
れているため、他の人の作業の影響を受けることは少なかった
 ただしリリースのためには、リリースされているブランチから現在のブランチまでをmergeして
おく必要があり、ここでたいてい csv がコンフリクトするので、コンフリクト解消が非常に大変
だった。
 各イベントの担当者とそれぞれコミュニケーションを取って、どちらが正しいのか確認する
 新キャラクター追加などに関しては共通シートの更新が必要だったりする構造になっていたりし
たので、そこに関しては「どの環境にどこまで反映するのか」ということ手作業で実行する必要
があった。
16

 良かった点
 独自の管理システムを用意していたため、エンジニアが拡張性することができた。
 （ネイティブアプリ比較で）データ変更から実機反映のイテレーションは比較的早い
 MySQLのテーブル単位をイベントの単位に紐付けていた部分は比較的管理が容易
 イベントの期間が終わった後は不要なので削除することも容易
 他のイベントのデータとぶつかることもないのでコンフリクトもしない
17

 課題だった点
 複数人で同時にデータを編集できない
 ゲーム共通のマスタをエクセルで管理する方法が難しい
 イベント単位に切られているマスタはそれ毎にブックを作ればいいので比較的容易
 共通のマスタは同時編集できないので、誰かの作業中に他の人が作業できない(アイテムとか)
 あとでmergeするよーって言って「同名のExcel_name01」みたいなものが生成されたりしていた
 コンフリクトした際のマージ作業を手動で行うのが大変
18

ガワネイティブ時代
 ブラウザゲーム時代と同じ構成のブラウザゲームを、webview でネイティブアプ
リ化
 ネイティブアプリ側のOpenGL API を実行できるようにすることで、ブラウザゲー
ムながら高速でリッチなアプリを作れる
 Google Spread Sheet (以下 GSS)でデータ入力をするようになった。これにより複数
人で同時にデータ入力できるようになった
 データの閲覧はGSS
 データの反映は独自CLIツールで、GSSからDLして、csv に変換。
19

 リリースバージョン毎に、ディレクトリ分けて管理
⁃ それぞれのディレクトリの中にそのバージョンで追加変更するマスターデータのGSSがある。
⁃ GSSに入力するマスターデータの内容は差分のみ。
⁃ 特定のバージョンまでのマスターデータをゲームに反映したい場合、過去のバージョンのマ
スタデータを独自CLIで統合する
⁃ これにより擬似的にバージョン管理を実現
 GSS上でマスタを入力
 Jenkins から独自CLIで自分の担当のリリースバージョンをゲームデータに変換する
 実機での動作確認をし、問題があれば直して再度jenkinsを実行する。
 満足したら、mysqldumpでcsv化し、git管理下に配備する。
 最終的にcsvをmysqlに突っ込むことでマスターデータの本番反映を行う。
20

リリース単位の
SpreadSheetにデータを作
る
Jenkinsの
ジョブを叩く
企画
SpreadSheet からDL
Jenkins
企画
マージ
リポジトリ
pullreq 生成
csv に変換
開発環境(DB)に反映
企画
企画がゲーム上で確認
Jenkinsの
ジョブを叩く
Jenkins
SpreadSheet からDL
分割されたシートのマー
ジ
csv に変換
差分チェック

 マスターデータが肥大化して作業しづらくなる問題の対処
⁃ GSSの VLOOKUP や入力規則を利用し、編集箇所から自動でマスタデータが生成される仕組みを
作り解決した。
 リリースバージョン別でのシートが独立しているので、他のリリースバージョンの影響を一定切
り分けられている。
⁃ ただし、それまでのバージョンのマスターデータを統合するため、以前のバージョンのマス
ターデータを誰かが編集中でエラーが混じっていた場合、それ以降のバージョンはすべてエ
ラーを含むマスタデータになってしまう。
⁃ また同じリリースバージョン内での複数人での作業は、作業の影響範囲を切り分けられてな
いため、編集中のデータで実機確認してしまって、エラーになることがあった。
⁃ それを防ぐため、さらに別途でマイグレーションの対象にならない個人作業用のディレクト
リを切ってマスタデータを編集していた。
 Jenkins によって作業を自動化し、マスタ入力作業以外の作業を Jenkins に任せることができた
22

 良かった点
 GSSを関数や入力規則で拡張することで、データ入力を
 特定環境にデータを突っ込むとか、PRを送るとかでかなり自動化
が進んでいる
 テストをスクリプトで行うようになり、機械的にマスタの誤りや
不整合をチェックできるようになった
23

 課題だった点
 GSSのデータ量増加と関数によって、シートを開いたり編集したりが重くなる
 複数の運用開発が並行する際に、マスタデータの変更の影響を完全に切り分け
られない
 独自CLIで特定のリリースバージョンのデータを反映すると、そのリリース
バージョンまでのマスタを統合するが、そのマスタがまだ編集中の場合があ
る
 データ増大に伴うマスタデータのビルド時間の長期化
⁃ 運営が長くなってくるとマスタデータ自体が多い
⁃ GSS の API のレスポンス速度や、通信速度がボトルネックになってくる
⁃ かつ作業者が増えてくると、jenkins の実行待ち時間も増えてくる
24

3. ネイティブアプリ時代(現在)
Unity 製
マスタデータの管理は Google Spread Sheet
Jenkins 上で SpreadSheet -> ゲームデータ(json)に変換
バージョン管理は git 及び Github
 ビルド時間の長期化を、キャッシングの仕組みを導入することで、削減すること
に成功した。
 しかし、相変わらず複数の運用開発が並行した際の影響切り分けはできていない。
またネイティブアプリ化に伴い、アセットデータのクライアント配信の概念が生
まれた。これにより後述する課題が新たに発生した。
25

ネイティブアプリ時代
 ディレクトリによってリリースバージョンとその前後関係を表現している。
⁃ バージョンを表現するディレクトリ内に作業者毎のディレクトリが存在している。
⁃ それぞれのディレクトリの中にそのバージョンで追加変更するマスターデータのGSSがある。
⁃ ex. 以下のような感じ。
 マスターを追加変更する場合は対応する名前空間にシートを作成し、マスターデータを書き込む。
 変更後にマスターデータを作業者のローカルに落としてくることで、変更データを加えたものの動作確認を行う。
 満足行くまでこれを繰り返す。
 データが完成したら「追加変更したデータを差分として吐き出すようなPullRequestをそのブランチに対して投げる」というJenkinsのjobを走
らせる。
 作業者、または承認者が内容を確認の上、mergeする。
 それぞれのバージョンはリリースされるまで、ブランチ上で別々の差分ファイルとして管理されており、データを読むタイミングでマイグ
レーションしたデータを作成する。
⁃ リリースすると「リリース後データ」という枠で一緒くたに管理される。
 実機確認をする際は、特定ブランチのgit管理下にあるものをmBaaSに突っ込んで読み込めるようにする。
26

 GSSでの複雑化しない工夫はガワネイティブ時代と同様に行われていた。
 同時作業に関しても同様だが、同じバージョンで分業できるところが異なる。
⁃ 差分で表現することのリスクとして「別ファイルで同じ行を変更している場合にどうするのか」というような点があるが、そのあた
りは運用でカバーしていた。
⁃ 運用でカバーされているという前提にしても、検知する仕組みぐらいあっても良かったように思う。
 マイグレーションのフローがガワネイティブから改善されている。
⁃ GSS上でマイグレーションするわけでなく、それぞれのバージョンのgit管理下においてるものをマイグレーションするため、きちんと
検証が済んでいるものを取り込むことができる。
⁃ プログラムコードと共に取り込まれるために、マスターデータとプログラムコードが乖離することもない。
 （厳密にはマスターデータの話ではないが）確認に時間がかかることがある。
⁃ マスターデータ自体はmBaaSに上げて確認するというフローだったのでそれほど時間はかからない。
⁃ マスターデータと合わせてその他のリソースも調整する必要があることが多々あった。
⁃ Unityゲームだったため、それらはアセットバンドルとして配信するため、アセットバンドルのビルドをする必要があったが、それに
時間がかかる。

27

（作業フロー）1
 イベント用の環境（mBaaSサーバ + そこに向いたビルド/UnityEditor）を用意
 Excelで特定verのデータを作る
 作ったデータをGSSに入れる
 特定verのGSSに入力してあるデータをDLして、必要なアセットをいい感じに作
成（jenkinsのjobでまとまっている）
 GSSのDLに独自CLIを使用している
 なぜ特定verだけでいいかというと、その直前verまではgitのrepoに入っている前提になって
いるから
 [これまでのデータ群] + [今回ブランチでの追加分のデータ群]というかんじ
28

（作業フロー）2
 ビルド／UnityEditorを使用して動作確認
 動作確認で問題なくなったらブランチに対してPRを送る->取り込み
 リリース後に[今回ブランチでの追加分のデータ群]は[これまでのデータ群]に取
り込まれる
 なので、リリース前にA,B,Cの順にブランチを切って並行開発した場合、ブランチCでは以下
のようになる。
 [これまでのデータ群] + [ブランチAでの追加分のデータ群] + [ブランチBでの追加分のデータ群] +
[ブランチCでの追加分のデータ群]
 過去差分に対しての変更／削除もパッチによって行われるので、[これまでのデー
タ群]を直接編集することはない
29

共通のSpreadSheetにデー
タを作る
Jenkinsのジョブを叩く
企画
gitリポジトリの更新
Jenkins
SpreadSheetからDL
リリースされてる分と
マージ
ランタイム向けにデータ
加工
マスタデータをスクリプ
トでチェック
Asset 化
コミットしてPullRequest
エンジニア
マージ
リポジトリ
エラーがあればJenkinsの
Viewで確認し修正
差分チェック

 良かった点
 GSSから直接統合するわけではないので、ガワネイティブ時代の課題が解消されている
 gitのrepositoryに入っている[これまでのデータ郡]のデータさえ正しくあればあとは自分の
ブランチだけが責任範囲になる
 悪かった点
 ビルドが完了するまでマスタデータの変更をゲーム上で確認できない
 jenkinsのjobの時間の肥大化により、イテレーションが遅くなってしまう
 マスタを追加したことによって追加しなければならないアセットの用意、テストなどに時間がかかる
模様
 あるブランチに於いて「特定のテーブルを表現するシート」は1枚なので、作業途中で放置す
るとそのテーブルを別件でいじりたい他の人がエラーになる
31

課題のまとめ
32

並行での開発に対応しきれてない
⁃ 複数のイベントを並行で開発する必要があると
き、イベント間で、編集の影響範囲が切り分け
られていない
⁃ ある前段のイベント開発でシートを編集中だと、
後続のイベントも編集の影響を受けてしまう
⁃ 前段のイベントがエラーになるような値を入力
してると、後続も影響を受けてエラーになる

3月1週目にリリースするイベント
3月2週目にリリースするイベント
ボスパラメータを編集中
別のパラメータを編集中
ボスパラメータが編
集中なのでゲームが
動かない

実機確認までに時間がかかる
⁃ マスタデータのゲームデータへの変換が
jenkins 頼み
⁃ jenkins のビルドを長時間待たないと、入
力したマスタをゲーム実機で確認できない

マスタをゲームデータに
変換するために Jenkins
ジョブ実行
ゲームに反映→
編集
実機確認するために待ちが発生する
編集
編集
Jenkins で順番待ちが発生
ゲーム

差分が見にくい
⁃ マスタデータの変更のレビュー時、差分の
確認が視認しづらい
⁃ ゲームデータ変換後のデータを github 上で
の差分の確認することになる
⁃ json とか csv のテキスト差分は人間の目に
非常に優しくない
⁃ 誤った編集の見落としなどにつながる

マスタデータ管理の共通基盤システム Oyakata
42

 マスタデータ管理システム
 以下の機能を備える
⁃ バージョン管理機能
⁃ 変更データのレビュー機能
⁃ CIを経由しないゲームデータへの変換機能
⁃ 入力されたデータの検証機能
43
Oyakata について

Oyakata とは
 モバイルゲームの運用に特化したマスターデータ管理用ツール。
 ゲーム内のマスタデータを一元管理したり、ゲームデータへの変換やデー
タチェックする機能がある。
 大きな特徴として、バージョン管理機能を備えており、ブランチ機能やコ
ミット機能を通して、細かいバージョン管理ができる。(git と同レベル)
 DeNA のこれまでの内製タイトル・協業タイトルの運用時期に発生したマス
タデータ管理の課題を、未然に防ぐための機能を備えている。

共通基盤システム開発という意思決定をした理由
 上述の課題から、以下の要件の仕組みがほしかった。
⁃ 1. 複数verの同時並行で作業する時に他案件に影響を受けない構造にしたい
⁃ 作業者が50名を超えると、声かけやワークフローの運用での影響範囲の切り分けが難しくな
る→システムでのサポートが必要
⁃ 2. 同じverでの複数人作業もできるようにしたい
⁃ 3. コンフリクトの解消はしたくない
⁃ 4. プランナーのデータ入力->ゲームでの確認のイテレーションは出来る限り早くしておきたい
 これらは既存のソフトウェアの組み合わせでは実現できなかったため、1から内製
のマスタデータ管理システムを開発することとなった。
45

Oyakata が提供するワークフローの説明
 1. 独自システム上でマスタ作成
 2. 作業者のローカルPC上でゲームデータに変換(CIを通さない)
 3. ゲームデータを用いてゲームをUnity Editor や実機で確認
 4. 1-3を満足するまで繰り返す
 5. 独自システム上でPRを送る
 6. 独自システム上で mergeされて開発ブランチに含まれる
 7. ゲームデータを定期的に git に登録する
46

Oyakata Editor
ストレージとしての機能
Excel での編集
Oyakata Editor
Web上での編集
その他ツールで
の編集
Oyakata Downloader
ゲームサーバー
Oyakata Converter
ゲーム実機
Unity Editor
ゲーム実機
プランナー
マスタの種類や目的
に
合わせて適切な
編集ツールで入力
Oyakata
デプロイ
配信
保存
開発時のゲーム上での確認
リリース・QA時の
ゲームへの反映
推奨するワークフロー

Oyakata を使うメリット
 Oyakata を利用することで、マスタデータを入力するた
めのワークフローを簡単に構築することができます。
 運用が始まってからの並行開発に対応しており、複数ラ
インの開発が並行で走っても、現場が混乱することのな
いワークフローを構築できます。
 マスタデータを入力してから実機確認までの時間を短縮
できるワークフローにできます。
 マスタデータの差分表示・レビュー機能を備えており、
意図しない変更や誤った変更に気づける仕組みを構築で
きます。

競合ソリューションとの比較
 Excel ファイル + 共有ファイルサーバー
⁃ 複数人で Excel を編集できない
 csv ファイル + git
⁃ 編集差分の表示が目視しづらい
⁃ 関数機能などを保存することができない
 Google SpreadSheet
⁃ ゲームデータへの変換ツールを実装する必要がある
⁃ バージョン管理の仕組みを用意する必要がある

Oyakata 機能説明
 エディター(editor)
 コンバーター(converter)
 バリデーター(validator)
大きく3つのコンポーネントを提供します。

エディター
 マスタデータを一覧で表示できる機能
⁃ webアプリケーション
⁃ 特徴としてレコード数の多いテーブルを複数に分割して管理できる
 編集履歴の表示機能
⁃ git like なコミット単位でのバージョン管理
⁃ 編集差分を表示できる
⁃ ブランチの差分も表示可能

エディター
 マスタデータを編集する機能
⁃ マスタデータのスキーマを Oyakata 上で作成・変更・削除できる
⁃ マスタデータのレコードを Web 上／Excel アプリケーション上で作
成・変更・削除できる
⁃ 編集したデータはゲーム上のデータに変換できる
 レビュー申請／レビュー機能
⁃ 編集したマスタデータをレビューする機能
⁃ いわゆる Github の Pull Request
⁃ 変更内容を、レビューしやすい見た目の差分表示ができる

コンバーター
 Oyakata で管理しているマスタデータをゲーム用のデータに変換する機能
⁃ CLI(Command Line Interface) ツール
⁃ JSON 形式と CSV 形式の出力対応
⁃ マルチプラットフォーム対応しており、プランナーの Windows や Mac 上でも実行できるので、
マスタデータの実機確認を、jenkins 介さず行うことが可能

バリデーター
 マスタデータが正しいかをチェックしてくれる機能
⁃ CLI ツール
⁃ マスタ間のリレーションチェックや、数値の範囲チェックなどができる。
⁃ DSLによって、そのゲーム特有のパラメータチェックもテーブル毎に設定できる。

これまでの仕組みと何が違うの？
 ブランチ管理をサポートしている
⁃ 他の人の作業の影響を受けなくなる
⁃ エンジニアが git で当たり前のように受けている恩恵をプランナーにも
 ゲームデータへの変換をローカルPC上でできる
⁃ Jenkins 待たずに実機確認可能
 マスタデータ形式に特化した差分表示ができる
⁃ 表形式には表形式の見やすい表示の仕方がある
⁃ json や csv をテキスト差分確認するのはやめよう

Oyakata の導入について
新規開発プロジェクトで導入して利用中
⁃ エンジニアが機能開発に必要なマスタを入力
⁃ プランナーが複数人で、マスタデータのパラメータ
の追加・調整
60

・新しく発生した課題
 運用ではなく新規開発時に適したワークフローになっていなかった。
⁃ 量産の考慮
⁃ 正しいデータを入力するより、大量のデータを効率よく入力できることが大切なフェーズ
 エディタの考慮
⁃ マスタデータによってはエクセルが最善の入力とは限らない
⁃ キャラのパラメータとかスライダーで入力できるようにしたい
⁃ マップはマップエディタを作ってやりたい
⁃ ゲームの大規模化に伴って、量産するために必要になってきた要素
61

まとめ
 弊社はこれまで Google Spread Sheet や Jenkins でマスタデータ
管理の仕組みを構築してきた
 そしたら以下のような課題が出てきた
⁃ SpreadSheet では並行開発の影響範囲切り分けしづらい
⁃ Jenkins に依存しきってしまって管理や順番待ちが発生した
⁃ csv や json の目視確認はただ辛い
 それらを解決するマスタデータ管理の共通基盤システムを作っ
ている
⁃ ブランチ管理によって、各個人の作業の影響切り分けが完全にできた
⁃ 一方でゲームの新規開発時の課題対処はこれから

CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例

More Related Content

What's hot

Similar to CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例

More from sairoutine

CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例