【レポート】「アサルトリリィ Last Bullet」開発・運営を円滑にするDBスキーマとマスターデータの自動化 #CEDEC2021 #classmethod_game

CEDEC2021

#ゲーム開発・運用

takehisa okamoto

2021.09.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは！ゲームソリューション部の岡本です。

2021年08月24日から08月26日の間に開催されているCEDEC2021に参加していました。

参加したセッション「アサルトリリィ Last Bullet」開発・運営を円滑にするDBスキーマとマスターデータの自動化についてレポートします。

セッション概要

スピーカー
- 原田大志氏　株式会社ポケラボゲーム事業本部エンジニア
資料
- CEDiLにて配布

オンラインゲームアプリの開発をする上で、複数のバージョンが平行で開発される、もしくは開発用、QAチェック用など、さまざまな環境を同時に運用する必要がでてきます。

ここで環境というのは、デプロイされているサーバのソースコード、DBに適用されているスキーマ構造、インポートされているマスターデータのおよそ三つに分けることができますが、問題になりやすいのが、どの環境にそれぞれ何が適用されているのか、を環境が多くなればなるほど把握しづらくなってしまうことです。

そこで、「アサルトリリィ Last Bullet」ではコードのデプロイからDBスキーマのマイグレーション、マスターデータのバリデーション〜インポートまでを1プロセスとして自動化することで

適用忘れ、不適切なマスターデータの適用によるダウンタイムを減らして開発作業を止めない

テストの巻き戻りを防ぐ

適用作業に人員を割かない

適用プロセスの属人化を防ぐ

これらの問題を解決しました。

本セッションでは、使用したツールやカスタマイズポイントなどを、実際に使用しているコードを交えながら紹介します。

セッション詳細

自己紹介

自動化の目的

自動化そのものが目的ではない
- 自動化はあくまで目的達成のための道具
自動化により...
- 一貫性を保証する
  - 誰がやっても同じ結果を得られるようにする
- 作業の属人化を防ぐ
  - 設定項目を極力減らし、誰でも理解出来るようにする
- 作業リードタイムを減らす
  - ワンプロセスの中で、全ての作業が終わるのが理想

目標(目指すべき姿)
- JenkinsのJOB画面を環境とバージョンを指定し、ボタンを押すだけにする

DBテーブル構造の更新

単純に考える場合
- ①現在のテーブル構造
- ②変更に必要なSQLを構築
- ③対象のDBに実装
複数環境を運用している場合、考えるべきこと
- 元のテーブルがそのバージョンでの最新になっているか
  - それまでの変更が全て適用されているか
- その変更はその環境のバージョンに対し、必要な変更か
- 正しい実行順序が守られているか
- 同時に実装されるべき変更とプログラムは全て揃っているか
- その変更はその環境において未実施か
考えるべきこと、をDBマイグレーションツールを使って実現
- それまでのバージョンで必要なファイルだけを実行可能
- 必要なバージョンブランチに対して必要なファイルだけコミット
使用ツール
- phpmig(https://github.com/davedevelopment/phpmig)
カスタマイズポイント
- SQLをパースして、実行するDBを自動判別する。
- シャーディングされたDBに対応

マスターデータの更新

Microsoft Excel
- マスターデータの入力に使用。プランナーが担当
Excelから直接DBに直接移行は難しいため、インポートツールを自作し、CSV→DBへ

重要なこと
- リポジトリの中を常に動作可能な状態を維持する
- マスターデータの更新が入り込むフローを限定、リポジトリに登録される前に必ずテストを通す
エクスポータ
- Excel及び、Excelマクロを利用
インポータ
- phpで作成
- エクスポータで出力されたcsvを対象に1行づつ挿入/更新を行うSQLを組み立てたシンプルなもの

最終的な結果

全てをワンプロセスで完了出来るように
- デプロイされているソースコードの更新
- DBマイグレーションによるテーブル構造の更新
- マスターデータ更新
改善点
- マスターデータの設定ミスは完全に防ぎきれてはいない
- 今回の仕組みのバリデータに関しては対応しきれていないものがある
- 更なるバリデータのルール追加
- フロー改善を行っていく