モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み

Copyright 2019 DELiGHTWORKS.
モバイルゲームの「大規模な開発」かつ「高頻度の更新」
を実現するための開発環境整備の取り組み
2020年9月4日
今井守生

Copyright 2020 DELiGHTWORKS Inc. All Rights Reserved.
資料はCEDiLにアップします
このセッションでは
モバイルゲームの開発・運営の経験をもとに
モバイルゲームの開発環境で発生しやすい問題・課題について
サーバエンジニアとして
新規開発プロジェクトで取り組んでいる内容をお話します
開発環境に正解はありませんが、いろいろな取り組みを紹介しますので、
何か1つでも皆さまのヒントになれば幸いです
1
はじめに

このセッションでは以下の意味合いで使用します
開発規模・運営規模
1タイトルの開発・運営に関わる人数
更新頻度
本番環境のサーバ、マスタデータ、クライアントアプリなどを更新する頻度
開発サーバ
本番環境と同じようにゲームを遊べる、アプリケーションサーバ、DBサーバ、
キャッシュサーバなどの1つのセット
2
用語説明

今井守生（Morio IMAI）
略歴
2014 ディライトワークス株式会社に入社
『Fate/Grand Order』のサーバエンジニアとして
設計、実装、ツール開発、データベース負荷対策などを行う
2019 新規プロジェクト向けに新しい共通基盤の開発を開始
過去の講演
2017 定期的な更新、かつ長期的な運営を行っていくための開発手法
https://gamebiz.jp/?p=187946
2019 Fate/Grand Orderにおける大規模なデータベース移行と負荷試験（AWS Summit 2019）
https://www.slideshare.net/MorioImai/fategrand-order
3
自己紹介

社名：ディライトワークス株式会社
設立：2014年1月22日
従業員数：407名（単体・2020年1月時点）
4
会社紹介

Copyright 2020 DELiGHTWORKS Inc. All Rights Reserved. 5
運営型モバイルゲームの開発事情

一般的に、サービス開始までは「これくらいの人員と期間で開発する」がだいたい決まっている
しかしサービス開始後は、ユーザ数と開発規模が比例する傾向がある
どれくらいのユーザに遊んでもらえるかは、サービス開始前に予測しづらい
6
開発規模
100人
150人
50人
？
？
サービス開始
開発規模
サービス開始前に将来の開発規模を予測することは難しい

「誰が何をしているか」の見通しが悪くなる
複数人が並行して作業できるようにする必要がある
「タスクAが終わらないとタスクBができない」という状態を可能な限りなくす
7
開発規模が拡大すると…
マージ
タスクA タスクB タスクC

モバイルゲームはいろいろな名目で更新する
ゲーム内イベントやキャンペーンを開始したり
他メディアとの連動キャンペーンがあったり
緊急で不具合修正があったり
しかし、サービス開始前はどれくらいの頻度で更新するか、厳密には決めていないことが多い
決めていたとしても、変更になることが多い
小規模のキャンペーン（経験値アップやログインキャンペーンなどなど）は特に
8
更新頻度
サービス開始前に将来の更新頻度を予測することが難しい

段階的にリリースできる仕組みが必要になる
複数のアップデートを並行して開発できるようにする必要がある
9
更新頻度が多くなると…
開発
QA
イベントA
機能追加
イベントB
10月9月 11月 12月
QA 開催
開発リリ
ース
QA開発開催
開発 QA 開催
開発 QA 開催
開発 QA 開催
キャンペーンA
キャンペーンB
キャンペーンC
開
発
Q
A
リ
リ不具合修正

開発規模と更新頻度を柔軟に変えられる仕組み
10
モバイルゲームの開発環境に求められるのは
開発環境のスケーラビリティ

1. 使用技術
2. データベーススキーマ管理
3. マスタデータ管理
4. 開発サーバ管理
11
アジェンダ

1. 使用技術
12
アジェンダ

サーバ
.NET Core (C#)
GCP
Google Kubernetes Engine
Cloud Spanner
Memorystore for Redis
など
クライアント
Unity (C#)
※このセッションは（一部を除き）使用技術に依らない内容です
13
新規開発プロジェクトでの使用技術

1. 使用技術
14
アジェンダ

マスタテーブル
ゲーム内で不変のデータを保存
例）どのようなクエストがあって、
どの敵が出現するか
15
テーブルの種類
ユーザテーブル
ゲーム内で可変のデータを保存
例）クエストをどこまで進めたか、
どのアイテムをいくつ持っているか
これらのテーブル構造を定義するのがデータベーススキーマ（以下、DBスキーマ）

DBスキーマにまつわる情報は、意外なほど多い
O/Rマッピング用クラス、DBアクセス用クラスなどなど
開発環境のスケーラビリティを実現するために
開発規模を意識して
DBスキーマを一元管理し、情報を散在させない
更新頻度を意識して
DBスキーマ変更にかかるコストを最小限にする
16
DBスキーマ管理のポイント
DBスキーマにまつわる情報の自動生成を徹底

O/Rマッピング用クラスとDDLを自動生成
▼データベース設計書
CREATE TABLE user (
user_id STRING(36),
name STRING(MAX),
updated_at INT64,
created_at INT64,
) PRIMARY KEY (user_id);
/// <summary>
/// アカウント情報を保存するテーブル
/// </summary>
public partial class UserRecord : BaseRecord
{
/// <summary>
/// ユーザを一意に識別するID（GUIDv4）
/// </summary>
public Guid UserId { get; set; }
/// <summary>
/// ユーザ名
/// </summary>
public string Name { get; set; }
/// <summary>
/// 更新日時
/// </summary>
public DateTime UpdatedAt { get; set; }
/// <summary>
/// 作成日時
/// </summary>
public DateTime CreatedAt { get; set; }
}
◀コメントも出力
自動生成

DBアクセス用クラスも自動生成
▼手動更新ファイル（最初の1回のみ生成）
/// <summary>
/// </summary>
public partial class UserModel : UserDataModel
{
/// <summary>
/// 1レコードをINSERTする
/// </summary>
/// <param name="valueRecord">INSERTするレコード</param>
/// <returns></returns>
public Task<UserRecord> InsertAsync(UserRecord valueRecord)
{
return InsertAsync<UserRecord>(valueRecord);
}
/// <summary>
/// 1レコードをUPDATEする
/// </summary>
/// <param name="valueRecord">UPDATEする値を設定したオブジェクト</param>
/// <returns></returns>
public Task<UserRecord> UpdateAsync(UserRecord valueRecord)
{
return UpdateAsync<UserRecord>(valueRecord);
}
......
......
}
/// <summary>
/// </summary>
public partial class UserModel
{
}
▼自動更新ファイル（毎回生成）

マスタテーブルも自動生成
CREATE TABLE mst_item (
id INT64,
name STRING(MAX),
) PRIMARY KEY (id);
/// <summary>
/// アイテムを定義するマスタテーブル
/// </summary>
public partial class MstItemRecord : BaseRecord
{
/// <summary>
/// アイテム ID
/// </summary>
public int Id { get; set; }
/// <summary>
/// アイテム名
/// </summary>
}
自動生成

定数も自動生成
/// <summary>
/// アイテムの種類
/// </summary>
public enum ItemType : int
{
/// <summary>
/// 経験値アイテム
/// </summary>
[Description("経験値アイテム")]
EXP = 1,
/// <summary>
/// イベントアイテム
/// </summary>
[Description("イベントアイテム")]
EVENT_ITEM = 2,
}
/// <summary>
/// </summary>
{
/// <summary>
/// アイテム ID
/// </summary>
/// <summary>
/// アイテム名
/// </summary>
/// <summary>
/// </summary>
public ItemType Type { get; set; }
}
▲Description属性はデバッグ機能の
選択肢表示などで使用
（定数の意味を一元管理）
▼定数定義

ALTER TABLEも自動生成（Rollback用も）
ALTER TABLE mst_item ADD COLUMN event_id INT64;
ALTER TABLE mst_item DROP COLUMN event_id;
1.0.0-1599195600.sql
rollback¥1.0.0-1599195600.sql
差分を取って出力
▼前回出力した設計書 ▼今回出力する設計書

ALTER TABLEのファイル名にはアプリバージョンとtimestampを使用
22
DDLのバージョン管理
1.0.0-1599195600.sql
【アプリバージョン】
アプリをバージョンアップするタイミン
グでスキーマ変更することが多いため
「あるバージョンのアプリをリリースす
る時に、どのスキーマを適用するか」が
わかりやすい
【timestamp】
複数人が別々の開発ブランチで並行
してスキーマ変更できるように
ブランチA ブランチB
1.0.0-1599195600.sql 1.0.0-1599800400.sql
マージ
ALTER TABLE mst_item ADD COLUMN event_id INT64; ALTER TABLE mst_quest ADD COLUMN event_id INT64;

各開発環境ごとに「どのALTER TABLEファイルを反映済みか」を保存
開発サーバデプロイ時に、未反映のSQLファイルを内製のマイグレートツールで自動反映
23
開発環境でのDDL管理
edition
1.0.0-1599195600
database_edition
edition
1.0.0-1599195600
1.0.0-1599800400
database_edition
デプロイ
+
スキーマ
マイグレート

yamlのスキーマ定義も自動生成
mst_item:
primary_key: [id, ]
foreign_key:
event_id: mst_event
range:
regular_expression:
columns:
- name: id
type: decimal
type_detail:
- name: name
type: string
type_detail:
- name: type
type: decimal
type_detail: ItemType
- name: event_id
type: decimal
type_detail:
マスタデータ周りのツールで使用（後ほど解説）
ItemType:
mapping:
EXP: 1
EVENT_ITEM: 2
▼type.yaml
▼schema.yaml
▼定数定義

クライアント側のファイルも自動生成
/// <summary>
/// </summary>
{
/// <summary>
/// アイテム ID
/// </summary>
/// <summary>
/// アイテム名
/// </summary>
/// <summary>
/// </summary>
public ItemType Type { get; set; }
}
サーバ
GitHub
クライアント
GitHub
自動生成 PR作成
データベース設計書
クライアント側でも使用するマスタデータ、ユーザデータ用のクラス

DBスキーマに関するファイルは自動生成を徹底
DBスキーマ変更作業の属人化を防止
並行作業にも対応
突発的なスキーマ変更でも抜け漏れなく対応可能
開発サーバのDBスキーマの状態を厳密に管理
サーバプログラムとDBスキーマが一致するように自動更新
26
ここまでのまとめ

1. 使用技術
27
アジェンダ

事例は増えつつあるものの、いまだに最適解がない分野
28
マスタデータ管理とは

2013/10/14 ソーシャルゲームのマスタデータ管理
http://hachi.hatenablog.com/entry/20131014/1381734842
2015/08/24 FINAL FANTASY Record Keeperのマスターデータを支える技術
https://www.slideshare.net/dena_study/final-fantasy-record-keeper
2015/12/18 モバイルゲームにおけるマスターデータ運用事例
https://labs.gree.jp/blog/2015/12/15368/
2017/08/30 ユーザを飽きさせない高頻度の更新を可能にする開発運用ノウハウ～ハイスピードな開発、リリースを実現するために～
https://speakerdeck.com/cygames/yuzawobao-kisasenaigao-pin-du-falsegeng-xin-woke-neng-nisurukai-fa-yun-yong-falseuhau-haisupidonakai-fa-ririsuwoshi-xian-
surutameni
2017/08/31 本格スマホRPG『アナザーエデン』開発の裏側を包み隠さずお話します～コード資産も無く、チームとしての経験も豊富ではない中
エンジニアはどう挑んだのか～
https://cedil.cesa.or.jp/cedil_sessions/view/1725
2017/12/07 わがままボディを目指すマスターデータをなんとかしたい
https://tech.drecom.co.jp/selfish_body_master_data/
2017/12/09 マスターデータ管理を優しくExcelから解き放つ
http://narazaka.blog109.fc2.com/blog-entry-247.html
2018/11/21 モバイルゲーム運用におけるマスターデータ管理の話あれこれ
https://qiita.com/sugaret/items/712c8fc487f7dbc4afdc
29
運営型ゲームのマスタデータ運用事例（1/2）

2019/04/12 モバイルゲーム開発・運用におけるマスターデータ関連のワークフロー改善事例
https://qiita.com/tshimomura/items/5e1c11bc0e02d9c1b24d
2019/09/06 CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
https://www.slideshare.net/sairoutine/cedec2019
2019/09/06 FFXIVコンテンツ製作を支える表データ管理システム -NEX-
https://cedil.cesa.or.jp/cedil_sessions/view/2059
2019/12/08 マスタデータ実装の考察
http://honeplus.blog50.fc2.com/blog-entry-209.html
2019/12/12 DeNAの最新のマスタデータ管理システム Oyakata の全容
https://www.slideshare.net/sairoutine/dena-oyakata?ref=https://note.com/piro234/n/n17aaf147125a
2019/12/12 ゲームのマスタデータ特有の3つの困難と、カヤックでの解決方法
https://speakerdeck.com/mackee/how-to-solve-three-problems-when-handling-the-master-data-of-mobile-games
2019/12/12 モンスターストライクのマスターデータのローカライズ運用について
https://speakerdeck.com/tmkoikee/operation-of-monster-strike-master-data-localization
2019/12/18 新マスタデータ管理システムakashicの開発
https://techblog.kayac.com/akashic-a-new-master-data-management-system
2020/01/21 マスターデータにおけるパラメーター検証のためのMasterMemory v2
https://tech.cygames.co.jp/archives/3367/
30
運営型ゲームのマスタデータ運用事例（2/2）
すべてが同じフローの事例はなし
（私が知る限り）2020年8月時点で書籍もなし

ゲームの仕様によるため
実際に運用してみてから気づく「使いづらさ」があるため
マスタデータ入力を始める段階で仕組みを導入できている必要があるため
開発後半で抜本的に仕組みを変えるのは、なかなか難しい
開発者の好みにもよるため
31
なぜ最適解がないのか

マスタデータ作成を並行作業できるようにする
可能な限り自動化する
リリースタイミングを可視化する
マスタデータの段階的なリリースのハードルを下げる
32
マスタデータ管理のポイント

検討すべきことの例
入力出力保存反映
どうやって入力するか
Excel ?
Google Spread Sheet ?
内製ツール ?
複数人での並行作業をどう
するか
どんなフォーマットに
CSV ?
JSON ?
YAML ?
どうやって出力するか
VBA ?
Google Apps Script ?
内製コンバータ ?
複数アップデートの並行開
発をどう管理するか
どこに保存するか
GitHub ?
SVN ?
ファイルサーバ ?
どうやってサーバ/クライアントに
反映するか
データベース ?
アセット ?

弊社事例
Excel
複数人での並行作業をどう
するか
後ほど解説
どんなフォーマットに
CSV
内製コンバータ
複数アップデートの並行開
発をどうするか
後ほど解説
GitHub & SVN
どうやってサーバ/クライアントに
反映するか
データベース

マスタデータ入力について

（本当は）入力ツールの内製が一番
ゲーム特有の機能を持たせられる
クエストや敵のデータを楽に作れたり
開発ツールと連携してイテレーションを早くできたり
データチェック機能を持たせたり
しかし…
以下を理由に、まだ手を出せないと判断
中途半端なものを導入したら逆効果
ゲーム特有の機能を持たせると、仕様変更や機能追加にかかるメンテナンスコストが多い
（将来的にはぜひ導入したい）
36

入力はExcelにしました
表データ作成ツールとして必要十分である
使い慣れている開発者が多い
Google Spread Sheetと比べると一長一短
どちらも事例はあるので、最終的には好み
37
その結果…

マスタデータの種類ごとにブックを分割
A1セルをテーブル名と解釈し、複数のシートを結合して出力
シート名は関係なし
38
複数人での並行作業をどうするか
"id","name","type"
"1001","経験値アップ","EXP"
"2001","イベントアイテム","EVENT_ITEM"
item.xlsm
item_event2020.xlsm
item.csv

マスタデータ出力について

ExcelからCSVに変換
40
Excel ①コンバータ CSV ②グルアー
③バリデータ
マスタデータから別の
マスタデータを生成
マスタデータの
正当性チェック
コンバータ、グルアー（整形・加工）、バリデータをそれぞれ開発
ツールの役割を明確に分けて疎結合にし、改修しやすいように
言語を統一したいのでどれもC#（.NET Core）

Excel上のタグごとにフォルダ出力
「このアップデートではこのフォルダを使えば良い」をわかりやすくするため
アップデートごとの差分をわかりやすくするため
41
コンバータの特徴
item.xlsm
"id","name","type"
"1001","経験値アップ","EXP“
"id","name","type"
"1001","経験値アップ","EXP"
"2001","イベントアイテム","EVENT_ITEM"
item.csv
item.csv

「何がいつリリースされるか」が一目でわかる
42
タグ情報を別ファイルで管理
コンバート時に
一緒に出力
リリースが取り止めに
なったらコメント
リリース順が入れ替わった場合、
行の順番を変更するのみでOK
master_tag: tag#20200904_update
start_at: 2020/09/04 18:00:00

DBスキーマを基準に出力
mst_item:
～中略～
columns:
- name: id
type: decimal
type_detail:
- name: name
type: string
type_detail:
- name: type
type: decimal
type_detail: ItemType
- name: value
type: decimal
type_detail:
"id","name","type“,”value”
“2001”,“イベントアイテム",“EVENT_IETM","0"
"1001","経験値アップ1","EXP","100"
“1002","経験値アップ2","EXP","200"
シート間のばらつきを
コンバータが吸収
コンバータ
schema.yaml
Excel上の列は順不同
メモがあっても問題なし
Excel上にカラムが不足していたらデフォルト値で出力
・「プランナーがExcelに列を追加した後でないと、エンジニアが
マスタテーブルにカラムを追加できない」を避けたかったため
・すべてのシートにカラムを追加するのが大変なため

マスタデータから別のマスタデータを生成
いわゆるViewテーブルに近い
データを集めるだけではなく、必要に応じて整形
メリットは以下の通り
マスタデータの入力ミスを減らせる
本番データの更新履歴がテキストで残るため差分確認できる
44
グルアーの特徴
グルアー
"id","name",”enemy_group_id”
“101”,“クエスト",“1"
"id","name",“hp“
“1001”,“敵1",“100"
“1002”,“敵2","200"
mst_quest.csv
mst_enemy.csv
"id",”enemy_id”
“1”,“1001"
“1“,“1002"
mst_enemy_group.csv
“quest_id",”enemy_id”,"name",”hp”
“101”,”1001”,“敵1",“100“
“101”,”1002”,“敵2",“200“
mst_quest_enemy.csv
例）クエストに出現する敵情報をまとめたマスタデータを作る場合

CSVのフォルダごとにグルアーを実行
Excel ①コンバータ
CSV
（tag#20200904_update）
②グルアー
③バリデータ
②グルアー
CSV
③バリデータ
SVNにコミットした後は
すべてCIで自動実行

バリデータの特徴
汎用チェックと専用チェックがある

汎用チェック
PKの重複チェック
外部参照のチェック
例）event_idがmst_eventに定義されているか
参照先は必ず id
数値の範囲チェック
例）valueが0から100になっているか
例）unlock_lvが1以上になっているか
正規表現チェック
例）数値4桁になっているか
mst_item:
primary_key: [id, ]
foreign_key:
event_id: mst_event
range:
value: [0, 100]
unlock_lv: [1, null]
regular_expression:
id: [0-9]{4}
columns:
- name: id
type: decimal
type_detail:
- name: name
type: string
type_detail:
- name: value
type: string
type_detail:
- name: unlock_lv
type: decimal
type_detail:
- name: event_id
type: decimal
type_detail:
▼schema.yaml

専用チェック
汎用化しづらいチェックはプログラマが都度実装
例）敵の出現ルールを満たしているか

エラーログ通知
とにかくわかりやすいエラー内容をSlackに通知
1つエラーがあっても実行を止めず、すべてのエラーをまとめて出力
まとめてエラーを直したいため
【Error】 [mst_item]マスタの[event_id]カラムの[1]行目に定義されている値:[10001]が、参照先の[mst_event]の[id]カラムに定義されていませんでした。
【Warn】 [mst_quest]マスタの[1]行目に定義されたクエストに開放条件が設定されていません。
【Error】 [mst_enemy_group]マスタの[1]行目に定義された値:[id: 1, group: 1]に敵が設定されていません。

マスタデータ保存について

Excel
SVNに保存
編集時にロックできるため
GitHubはバイナリとの相性が悪いため
– git pullに時間がかかる…
Git LFSよりも導入が楽なため
CSV
GitHubに保存
履歴・差分が見やすいため
51

Excel ①コンバータ
CSV
②グルアー
③バリデータ
②グルアー
CSV
③バリデータ
SVN GitHub
SVNにコミットした後は
すべてCIで自動実行

マスタデータ反映について

マスタデータ開放日時を自動登録
version master_tag start_at
1 tag#20200904_update 2020/09/04 18:00:00
version id name type value
1 1001 経験値アップ1 1 100
mst_item
data_version
start_at: 2020/09/04 18:00:00
"1001","経験値アップ1","EXP","100"
反映ツール
登録
▲開放日時
▲versionは自動採番
▼tag#20200904_update
54

何回分でも登録可能
version master_tag start_at
1 tag#20200904_update 2020/09/04 18:00:00
2 tag#20200911_update 2020/09/11 18:00:00
version id name type value
1 1001 経験値アップ1 1 100
2 1001 経験値アップ1 1 100
2 1002 経験値アップ2 1 200
mst_item
data_version
反映ツール
登録
"1001","経験値アップ1","EXP","100"
“1002","経験値アップ2","EXP","200"
▼tag#20200911_update
start_at: 2020/09/11 18:00:00
▲開放日時
▲versionは自動採番
55

クライアントアプリがマスタデータを「ダウンロード」して「展開」する時間を短縮したい
56
差分ダウンロード（開発中）
version update_type id name type value
1 UPDATE 1001 経験値アップ1 1 100
mst_item
反映ツールが直前のversionと
比較して自動的に登録
NONE: 変更無し
UPDATE: 追加/変更
DELETE: 削除
"1001","経験値アップ1","EXP","100"
“1002","経験値アップ2","EXP","200“
“1003","経験値アップ3","EXP",“300"
"1001","経験値アップ1","EXP","100"
“1002","経験値アップ2","EXP","250“
mst_item.csv
mst_item.csv
反映ツール
反映ツール
2 NONE 1001 経験値アップ1 1 100
2 DELETE 1003 経験値アップ3 1 300

クライアントアプリが持っているマスタデータのversionによって返却すべきレコードを判定
57
差分ダウンロード（開発中）
クライアントのversionが1なら
この2レコードのみを返却
2 NONE 1001 経験値アップ1 1 100
2 DELETE 1003 経験値アップ3 1 300
mst_item
クライアントのversionが0なら
この2レコードを返却
（初回ダウンロード）

複数人が並行作業できる仕組みを整備
厳密なスキーマによって、入力データのばらつきをコンバータが吸収
グルアーによるマスタデータの自動生成
バリデータによる徹底したチェック
段階的にリリースできる仕組みを整備
マスタデータをタグで管理し、開放日時で自動的に切り替え
マスタデータ更新時間を短くするための差分ダウンロード
58

1. 使用技術
59
アジェンダ

開発サーバを100セット作っても管理コストが増えないようにする
– 実際にそんなに作るかはさておき
複数のアップデートを並行開発しても管理コストが増えないようにする
よくあるモバイルゲームの開発フローを辿っていくと、
この実現が難しいことが多い
60
開発サーバ管理のポイント

開発初期はクライアントアプリのみのことが多い
プロジェクトの良し悪しを判断するにはクライアント側が重要なため
61
よくあるモバイルゲーム開発の流れ
プロトタイプ
アルファ
ベータ
QA
サービス開始クライアントアプリのみ

ある程度できてきたらサーバと繋ぎこむ
開発サーバ（dev01環境）の登場
会社によって呼び方は様々
62
プロトタイプ
アルファ
ベータ
QA
サーバと繋ぎこみ
dev01
サービス開始

開発が進むと「通信周りの作り込みをしたい」などの要件が出てくる
dev01の邪魔をしないように、とりあえずdev02環境を追加
この時点では「dev02環境使います」という声掛けで、まだなんとかなる
そろそろ手軽にサーバ更新したくなってくる
CIツール（Jenkinsなど）の登場
63
dev01 dev02

開発後半になると、いろいろな要件で開発サーバが増える
社内レビューがあるので一定期間更新しないようにしたい
アップデート分の開発を進めたい
マスタデータを変更しつつ、いろいろなパターンでテストしたい
64
dev01 dev02 dev03 dev04 qa01
......

「どのサーバがどうなっているか」を管理したくなる
開発サーバWikiの登場
65
環境名ビルド用途
dev01 xxxxxxxxxx 主に使う
dev02 xxxxxxxxxx 通信周りの検証用
dev03 xxxxxxxxxx 社内レビュー用
dev04 xxxxxxxxxx アップデート開発用
qa01 xxxxxxxxxx テスト用

しかし、実際の開発サーバとWikiがずれると悲惨
そこで、CIツールの設定を自動的にWikiに反映
これで概ね解決
こんな感じの運用は多いと思います
66

CIツールのジョブが増えていきがちで、設定に手間がかかる
開発サーバが1セット増えるごとにCIツールのジョブが増えていったり
Jenkins職人の誕生
開発サーバの設定を変更できるのは基本的にエンジニアのみ
大規模開発では、いろいろな人から設定変更依頼がくる
例）「××サーバを〇〇アップデートの状態にしてください」など
コミュニケーションコストが増えがち
そこで......
67
改善したいこと

環境名
マスタサーバその他
タグ開放日時定時更新ドメインブランチ自動デプロイ管理ツール主な利用者備考設定
dev01 tag#20200904_update 2020/09/04 18:00:00 true dev01.hogehoge.net v1.0.0 true http://dev01-admin.hogehoge.net 全員みんなが使う
dev02 tag#20200904_update 2020/09/04 18:00:00 false dev02.hogehoge.net v1.0.0 false http://dev02-admin.hogehoge.net Aさん通信周りの検証用
dev03 tag#20200904_update 2020/09/04 18:00:00 false dev03.hogehoge.net v1.0.0 false http://dev03-admin.hogehoge.net Bさん社内レビュー用
dev04 tag#20200911_update 2020/09/11 18:00:00 true dev04.hogehoge.net v1.1.0 false http://dev04-admin.hogehoge.net Cさんアップデート開発用
qa01
tag#20200904_update
tag#20200911_update
2020/09/04 18:00:00
2020/09/11 18:00:00
true qa01.hogehoge.net v1.1.0 true http://qa01-admin.hogehoge.net Dさんテスト用
68
専用のWebアプリケーション（開発管理画面）を開発
開発サーバのすべての情報を1ヶ所に集約し、設定変更を可能に
各環境の設定は専用のDBで管理
反映されているマスタデータ
（複数登録可能）
先述のmaster_tag_info.yamlを
参照して表示
最新マスタを毎日定時更新するかどうか
（固定したい場合はfalse）
ゲームサーバのドメイン
デプロイされているブランチと、
自動デプロイするかどうか
管理ツールのURL
開発サーバを専有したい場合は
空いてるところを使う
変更
変更
変更
変更
変更
設定変更ボタン

ワークフローを比較
CIツール
開発者用
Wiki
dev01
dev02
Before
dev03
設定反映
設定
閲覧
設定依頼
自動更新
手動更新
エンジニア
プランナー
QA
CIツール dev01
dev02
After
dev03
情報取得
更新/
情報取得
閲覧/
設定
自動更新
エンジニア
プランナー
QA
開発管理
画面
✔常にDBを正とするので情報の流れがわかりやすい
✔エンジニア以外の開発メンバーが設定を変更できる
手動更新
DB

単独更新
設定されているブランチでビルドされたイメージを一覧表示し、
どれをデプロイするか選択
一括更新
選択したブランチが設定されている開発サーバを一括更新
70
ゲームサーバの手動更新

単独更新
好きなマスタタグで好きな開発サーバを更新
一括更新
好きなマスタタグが設定されている開発サーバを一括更新
71
マスタデータの手動更新

検証用アプリから接続できる開発サーバのリストを取得
新しいサーバが増えるたびに、検証用アプリに新しい接続先を追加
しなくて済むように
72
接続可能サーバ取得API
{
"devservers" : [
{
"name" : "dev01",
"server" : {
"branch" : "v1.0.0/dev",
"domain" : "dev01.hogehoge.net"
}
}, {
"name" : "dev02",
"server" : {
}
}, {
"name" : "dev03",
"server" : {
}
},
]
}

すべての開発サーバは、サーバの種類ごとに相乗り
DBサーバ
開発サーバごとに1つのデータベース
ゲームサーバ
開発サーバごとにKubernetesのnamespaceで分割
キャッシュサーバ
開発サーバごとにKeyにPrefixを付与
開発サーバを増やすたびに新しいインスタンスを立てる必要がない
手間の削減
費用の削減
予算管理
73
開発サーバの構成
namespace:
dev01
ゲームサーバ
（1クラスタ）
DBサーバ
（1インスタンス）
キャッシュサーバ
（1インスタンス）
database:
dev01
database:
dev02
database:
dev03
namespace:
dev02
namespace:
dev03
prefix:
dev01_
prefix:
dev02_
prefix:
dev03_

開発サーバを一元管理するWebアプリケーションを開発
開発サーバの状態が一目でわかる
大規模開発やリモートワークに向いている
開発サーバの設定を直感的に更新できる
開発サーバが何台に増えても管理コストが爆発的に増えない
エンジニアが開発サーバのお守りから解放される
開発サーバを追加するコストを徹底的に削減
開発規模の拡大にも柔軟に対応できるようになった
74

開発環境やワークフローは、プロジェクトが進むにつれて徐々にでき上がって
いくことが多い
しかし、開発の流れに身を任せていると最終的には歪になる
そして、プロジェクト規模が拡大するにつれて管理コストが上がる
さらに、一度できてしまったワークフローを後から変更するのはすごく大変
75
全体のまとめ
開発初期からスケーラブルな開発環境を設計し、
「開発規模の拡大」と「更新頻度の増加」に
柔軟に対応できる仕組みの整備が重要

モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み

Ähnlich wie モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み (20)

モバイルゲームの「大規模な開発」かつ「高頻度の更新」を実現するための開発環境整備の取り組み