禍つヴァールハイトを支えるデータ更新作業について

禍つヴァールハイト
を支える
データ更新作業について
2019-06-05 作田政幸

自己紹介
名前：作田　政幸（さくた　まさゆき）
本来は違うPJにいるサーバーエンジニア(東京勤務)
運用について考えるのが好き
福岡では去年のCEDEC+KYUSHU2018で全く別の内容で講演
している

とある日のこと・・・
プロデューサー：
「データ更新について考えないと
いけないけど、
仕組み的にまだ十分に
考えられていない」

とある日のこと・・・
私：「(　ﾟдﾟ)ﾎﾟｶｰﾝ」

その後
PJ掛け持ちで
データ更新フローの
改善に向けて
作業を始めました

今回のテーマ：
今回はリリース(4/23)までに
データ更新作業を改善した
話をします

ここでいうデータとは
● ゲーム内のデータ（マスタデータ）のことを表します
● アップデートの度にゲーム内データ更新を入れています
● ここ最近ですと、５章追加(5/10)、シロちゃんコラボ(5/29)のた
めに大きくデータの更新を入れました

改善前の話
● シナリオ、バトルなどそれぞれの画面において対応するスプ
レッドシートが存在しておりプランナーさんが入力

改善前の話
● そのスプレッドシートを各サーバー環境(2環境あります)に開
発者用のwebツールを使ってアップロードしていく
● シート自体はバトル、シナリオ(章ごと)などで分かれているの
で全部で100枚近くある
開発用サーバー
　本番用サーバー

改善前の話
● 各サーバーにつながるandroid, iOSバイナリを作ることでゲー
ムが遊べる
開発用サーバー　本番用サーバー

改善前の話
● 私がPJ(まがつ)に来てこの運用方法には気になるところがあ
りました
● ここで私が気になったことは３つありました

改善前の話
１．データの保全が
されていない

データの保全性
● ゲーム内のデータ全体を表す状態が各サーバーにしかない
○ これではデータを切り戻すのが難しい
■ 急遽シートを元の状態に戻す事態も起こり得る
○ また、ある時点で本番に出たデータを見たいときもある
（ユーザーサポートなど）

改善前の話
２．時期に応じた
データの切り分けが出来ない

時期に応じたデータの切り分けが出来ない
● シートでデータを管理しているが中には全ての行アップロード
してはいけないシートもある
● 例：メインクエストの章一覧シート

● 本番でリリースしているのが1-4章とした場合、
○ 本番では1-4章のデータにしたいが、テストのために5章の
データも入れて確認したいときもあるので都度シート編集
が必要になる

改善前の話
３．サーバー環境が少ない

サーバー環境が少ない
● デバッグ用として他にもサーバーがあったがそれらのサー
バーにはサーバープログラムしか更新できず、ゲーム内デー
タは更新できなかった
開発用サーバー ○　更新出来る
開発用サーバー２
開発用サーバー３
☓　更新出来ない

● 先程の、1-4章のデータの環境、5章も入っているデータの環
境、というように様々なデータの状態でテストするためには多く
の環境が必要である
開発用サーバー ○　更新出来る
開発用サーバー３

問題点
● この３つの問題点があるまま実際の運用に入るとどうなるで
しょうか？
データの保全がされていない

問題点
● 開発チーム内では複数のリリース日でのテストを同時並行で
実施しています
○ １週間後
○ ２週間後
○ １ケ月後
● 本番用サーバーは実際のプレイヤーが遊んでいるデータと同
じにしているので環境が足りなくなります

問題点
● また、データを入れ替えようとしてもシートを１枚１枚アップ
デートして変える方式なので、急遽
「１ケ月先のテストをしていたけど、直近のテストをしたい」
● となってもデータを入れ替えるのが大変です（データだけでなく
プログラムの変更もあるかもしれません）

問題点
● 簡単に入れ替えやすくなるとするとシートが増殖します
明日出す
シナリオデータ
来週出す
再来週出す

問題点
● すると管理には限界があるので結果として本番で事故しやすく
なります
本番用サーバー
どれをアップロードす
ればいいか？

問題点
● 以下問題点を解消する方法を考えました
データの保全がされていない

改善した話
● まずは環境を増やしました
開発用サーバー１３

改善した話
● ただ先ほど話があったように更新先が限定されている
○　更新出来る

改善した話
● また、保全されていない問題もあったので・・・
○　更新出来る

改善した話
● Gitを使ってデータを置くことにしました(更新はJenkins)

改善した話
● また、データの切り分けについては、リリース日を表すデータ
を入れることで解消出来るようにしました
● (md-yyyymmdd という書式でgitへの出力時にリリース日を指
定する)

改善した話
● Gitのブランチに関しては、シートで出力したデータをリリース
日ごとに管理　
yyyy年mm月dd日用ブランチ
yyyy年mm月ee日用ブランチ
yyyy年nn月ff日用ブランチ

改善した話
● またシートのデータ出力する際ブランチを該当リリースからブ
ランチを切るところまではJobでするのでPRも簡単に提出出来
る
yyyy年mm月dd日用ブランチ
Jenkinsで作ったブランチ
Pull Request

改善した話
● また、各サーバーに展開したデータについてはgitのリビジョン
(コミットID)で残すようにした(Jenkinsでの展開時に自動で記
録する仕組み)

こうして
● データ周りを整備して禍つヴァールハイトが無事にリリース出
来ました!

まとめ
● データの保全がされていない
○ → Gitを使ったマスタデータ管理
● 時期に応じたデータの切り分けが出来ない
○ → 過去のデータ更新履歴を残す仕組み
● サーバー環境が少ない
○ → Jenkinsを使ったデータ更新作業

Recomendados