Goバックエンド標準化プロジェクトの取り組み

QualiArtsでは、2019年頃からGoをバックエンドのメインの言語として採用しており、これまでに複数のプロジェクトをGoで開発してきました。その中で、Goにおけるノウハウが溜まり、開発基盤やツールにおいて実装方法が成熟した部分が出てきていました。

一方で、ゲーム開発に限った話ではありませんが、基盤自体に手を入れるのは一定開発が進んだ段階では難しくなります。基盤の修正を行いたくても影響が広いため手を付けづらく、ゲーム自体の機能開発も行う必要があるため、おのずと優先度は下がってしまいます。

また、ゲーム運用のための管理ツールは、マスタデータの更新やユーザーデータの調査等、必要となる機能数も多く、0から作ると最低でも半年（6人月）程度は必要となります。ですが、管理ツールの開発はゲーム自体の開発の合間で行われることが多く、ある程度開発の後半に差し掛かっても、管理ツール機能の追加や改善が必要になる状況も珍しくはありません。

このような状況の中で、「バックエンド標準化プロジェクト」は始動しました。具体的には、新規プロジェクトを立ち上げる際に、テンプレートとすることができるリポジトリを構築する取り組みです。
このプロジェクトはGoで実装され、Goでの複数プロジェクト開発を経て、安定した基盤や管理ツール機能をテンプレートとして提供します。このテンプレートリポジトリは開発基盤や運用管理ツールのみを対象としているため、ゲーム仕様を意識すること無く調整・拡張することが可能です。

Transcript

1. Goバックエンド 標準化プロジェクトの 取り組み 株式会社QualiArts 島田 裕司
2. 島田 裕司 / Shimada Yuji - 2013年 株式会社サイバーエージェント入社 - 現在はQualiArtsにてスマートフォン向けゲーム 開発を担当 - Go歴は5年程度 - 社内のGoコミュニティ「SGE.go」を運営 The Go gopher was designed by Renée French.
3. ゲーム・エンターテイメント事業部（SGE） 子会社制をとっており、 ゲーム・エンターテイメント事業に 携わる9社の子会社が 所属しています。 ゲーム・エンターテイメント事業部（SGE）
4. Contents 1. バックエンド標準化プロジェクトとは 2. 標準化プロジェクトにおけるADRの活用 3. まとめ
5. 1 バックエンド標準化 プロジェクトとは
6. QualiArtsにおける状況 ✔ 複数プロジェクトの開発を経てGoでの基盤・ツール開発が安定 ・Goにおけるノウハウが一定蓄積された ・基盤やツールの実装方法が成熟 ✔ 開発が進むと基盤に手を入れるのが難しい ・影響範囲が大きくなる ・機能開発と比較して優先度が下がってしまう ✔ 運用管理ツール開発には時間がかかる ・0から作ると半年以上かかる ・ある程度開発が進んだ段階でも、管理ツールの改善が必要になるケースもある
7. バックエンド標準化プロジェクトとは？ ✔ 新規プロジェクト用のテンプレートリポジトリを構築する取り組み ✔ 実装が安定した開発基盤や運用管理ツールをテンプレート化 ✔ ゲーム仕様を意識すること無く実装することが可能
8. テンプレートリポジトリの提供機能 • 認証 • 管理操作ログ • ダッシュボード • 開発環境管理 • マスターデータCRUD • スプレッドシート インポート/エクスポート • マスターデータ同期 • マスターデータタグ • トランザクションデータ CRUD • ユーザーデータ • ユーザー検索 • IAMロール • マスターバリデーション • Webviewエディタ • テーブル定義 / Enum定義 / API定義 参照 • アセットマネージャー • 課金残高履歴参照 • クライアントマスター参照 • サーバーマスター参照 • ユーザースナップショットマネージャー • APIテスター 運用管理ツール
9. テンプレートリポジトリの提供機能 共通基盤 • エラー • トレース・メトリクス • ロギング • コンテキスト • CORSミドルウェア • ファイルサーバー • バリデーションインターセプター • アクセスログインターセプター • 認証トークンキャッシュ • ランキング • ロック • 報酬 / 消費 • 条件 API基盤 • マスタ取得 • 認証 • ユーザー作成 • ユーザーログイン デバッグ基盤 • コマンド一覧 • コマンド実行
10. テンプレートリポジトリによる恩恵 ✔ QualiArts新規プロジェクトもテンプレートリポジトリをベースに開発 ✔ およそ6人月程度の工数削減を実現 ✔ 利用者からFBを収集し、テンプレートリポジトリの機能や運用を改善
11. なぜライブラリ/FWではないのか ✔ 過去には多くの共通ライブラリ/FWを輩出 ✔ 同時にその衰退も経験 ・プロジェクト固有仕様に対応する無理な拡張 ・技術トレンドの変化 ・メイン開発者の不在 ✔ メンテナンスのコストが肥大化 ✔ ゲーム開発の大規模化 ✔ 開発期間は2,3年以上、開発人数も100人を超える ✔ 並行して複数プロジェクトを進める機会が減少
12. なぜライブラリ/FWではないのか ✔ 過去には多くの共通ライブラリ/FWを輩出 ✔ 同時にその衰退も経験 ・プロジェクト固有仕様に対応する無理な拡張 ・技術トレンドの変化 ・メイン開発者の不在 ✔ メンテナンスのコストが肥大化 ✔ ゲーム開発の大規模化 ✔ 開発期間は2,3年以上、開発人数も100人を超える ✔ 並行して複数プロジェクトを進める機会が減少 → 共通ライブラリ/FWに縛られるより、良い部分をテンプレートに入れて次に活かす
13. テンプレートリポジトリの運用 ADR（Architecture Decision Record）をもとに週に一度議論を行う 決定事項の反映やその他必要機能の拡充
14. 2 標準化プロジェクトに おけるADRの活用
15. Architecture Decision Record（ADR） ✔ ソフトウェアアーキテクチャにおける重要な意思決定を記録する文書 ✔ コンテキスト、決定内容、理由を明記し、透明性と将来の参考に役立つ ✔ プロジェクトの全体像を明確にし、チーム内で共有するために使用される
16. Architecture Decision Record（ADR） ✔ ソフトウェアアーキテクチャにおける重要な意思決定を記録する文書 ✔ コンテキスト、決定内容、理由を明記し、透明性と将来の参考に役立つ ✔ プロジェクトの全体像を明確にし、チーム内で共有するために使用される → 標準化プロジェクトではADRを用いて方針の議論、決定を行っている ADRの管理にはGitHub Discussionsを利用
17. 標準化プロジェクトにおけるADRの一例 ✔ 技術選定 ・通信フレームワークにconnect-goを使用する ・DIツールにuber-go/fxを使用する ・定義とコードジェネレーターにProtocol Buffersを使用する ✔ パッケージ構成・コーディング規約 ・パッケージ名は標準パッケージと被らない名前にする ・ユースケース層のファイル配置を /usecase/xxx/usecase.go とする ・パッケージ名・ディレクトリ名はスネークケースにする ✔ テンプレートリポジトリの運用 ・技術選定時には過去プロジェクトの資産も考慮に入れる ・GitHub Issuesには明確にやることのみを起票する ・IssueとPRをReferencesで紐づける
18. ADR事例. テストコードの記述フォーマット
19. 背景1. Go経験が浅くテスト実装が手探り ✔ はじめてのGoプロジェクトでGo経験が浅く各メンバーが手探りで記述 ✔ テストケースごとにテスト関数を分割 or テーブルドリブンテスト（TDT） ✔ TDTで記述する場合も何をテーブルに含めるがバラバラ ✔ テスト対象関数/メソッド戻り値のチェック粒度が異なる
20. 背景1. Go経験が浅くテスト実装が手探り ✔ はじめてのGoプロジェクトでGo経験が浅く各メンバーが手探りで記述 ✔ テストケースごとにテスト関数を分割 ✔ テスト対象関数/メソッド戻り値のチェック粒度が異なる ✔ テーブルドリブンテスト（TDT）で記述する場合も書き方がバラバラ → ✔ TDTで記述を統一する機運が高まる ✔ 最低限のフォーマットも合わせる
21. 背景2. TDTと相性が良くないテスト ✔ ゲームのコアロジック ✔ 1ケースのモック呼び出しで数百行に及ぶ ✔ モックの制御を含めたTDTの記述が難しい ✔ ケース毎に処理の分岐を行うテストが爆誕 ✔ util関数等のシンプルな処理 ✔ 1テストケースが1行で済むのでTDTで記述するまでもない
22. 背景2. TDTと相性が良くないテスト ✔ ゲームのコアロジック ✔ 1ケースのモック呼び出しで数百行に及ぶ ✔ モックの制御を含めたTDTの記述が難しい ✔ ケース毎に処理の分岐を行うテストが爆誕 ✔ util関数等のシンプルな処理 ✔ 1テストケースが1行で済むのでTDTで記述するまでもない → ✔ 無理にTDTとしない ✔ モック呼び出しが複雑な場合、テスト関数内で複数サブテストを羅列 ✔ 処理がシンプルな場合、サブテストを使わず各ケースを羅列
23. func TestUsecase_Login(t *testing.T) { t.Parallel() // モック呼び出しが複雑な場合、テスト関数内で複数サブテストを羅列 t.Run("新規ユーザー", func(t *testing.T) { t.Parallel() ... assert.Equal(t, want, got) }) t.Run("既存ユーザー", func(t *testing.T) { t.Parallel() ... assert.Equal(t, want, got) }) } テスト関数内で複数サブテストを羅列
24. func TestSplitComma(t *testing.T) { t.Parallel() // 処理がシンプルな場合、サブテストを使わず各ケースを羅列 assert.Equal(t, []string{"a"}, SplitComma("a")) assert.Equal(t, []string{"a", "b", "c"}, SplitComma("a,b,c")) assert.Equal(t, []string{}, SplitComma("")) } サブテストを使わず各ケースを羅列
25. 背景3. 複数のテスト記述方法が混在 ✔ 新たに参画したメンバーがどのテストを参考にすれば良いか分からない ✔ 既存の機能の改修を行う際にテスト記述を解読する必要がある
26. 背景3. 複数のテスト記述方法が混在 ✔ 新たに参画したメンバーがどのテストを参考にすれば良いか分からない ✔ 既存の機能の改修を行う際にテスト記述を解読する必要がある → プロジェクトの初期からテストコードの記述フォーマットを統一したい
27. テストのフォーマット統一 課題/目的 ✔ 対象 テストコード ✔ 課題・理想状態 ・書き手に依るテストコードのブレがなく、フォーマットが統一されている状態 ・コーディング/リーディング の負担を抑える ・新規メンバーがどのテストを参考にするか迷わないようにする ✔ 目的 ・テストコード記述方式の統一 ・TDテストによるデータと処理の分離、処理の共通化
28. テストのフォーマット統一 1. 1つの関数・メソッドに関するテストは1つのテスト関数に集約 ・基本はTDTを用いる ・複雑なモック制御等、非TDTの方が可読性が高い場合、サブテストを羅列する ・util関数等のごく簡単なテストであれば、サブテストを用いずに記述しても良い
29. テストのフォーマット統一 2. 各テスト関数にて次のフィールドを持つtestCase構造体を定義する ・Name: テスト名 ・Args: 引数（引数がない場合も空で定義） ・Prepare: モック呼び出しを記述する関数 ・Returns: 戻り値（戻り値がない場合も空で定義） ・（Updated: 引数の更新後の値）※省略可、破壊的な変更を行う場合に利用
30. // Case テストケースの構造体 type Case[args, mocks, returns any] struct { Name string Args args Prepare func(args args, mocks *mocks) Returns returns } // Cases テストケース群の構造体 type Cases[args, mocks, returns any] []Case[args, mocks, returns] テストケースのジェネリクス定義 testutil.go
31. // mocks モックの一覧 type mocks struct { cardService *card.MockService consumptionService *consumption.MockService rwTx *database.MockRWTx } // newWithMocks テスト対象と各種モックを生成 func newWithMocks(t *testing.T) (Usecase, *mocks) { m := &mocks{ cardService: card.NewMockService(t), consumptionService: consumption.NewMockService(t), rwTx: database.NewMockRWTx(t), } return NewUsecase(m.cardService, m.consumptionService), m } テスト対象と各種モックの生成
32. 引数と戻り値の定義 func TestUsecase_LevelUp(t *testing.T) { t.Parallel() type args struct { ctx context.Context userID string cardID string level int } type returns struct { err error } // テストケースの記述とテスト実行 ... }
33. cases := testutil.Cases[args, mocks, returns]{ { Name: "正常", Args: args{ ctx: context.Background(), userID: "userID", cardID: "cardID", level: 10, }, Prepare: func(args args, m *mocks) { m.cardService.EXPECT(). LevelUp(args.ctx, m.rwTx, args.userID, args.cardID, args.level).Return(dto.Resources{}, nil).Times(1) m.consumptionService.EXPECT(). Consume(args.ctx, m.rwTx, args.userID, dto.Resources{}).Return(nil, nil).Times(1) }, Returns: returns{}, }, } テストケースの記述
34. for _, tc := range cases { t.Run(tc.Name, func(t *testing.T) { t.Parallel() u, m := newWithMocks(t) tc.Prepare(tc.Args, m) err := u.LevelUp(tc.Args.ctx, tc.Args.userID, tc.Args.cardID, tc.Args.level) testutil.EqualError(t, tc.Returns.err, err) // 戻り値があればアサーション e.g. assert.Equal(t, tc.Returns.xxx, xxx) }) } テストの実行
35. ADRによる恩恵 ✔ プロジェクトとしての方針を明示し認識を統一できる ✔ PRレビューにおいて参照リンクとして利用できる ✔ 新メンバーへのオンボーディングに活用できる
36. ADRのデメリット ✔ ADRの記述コストが掛かる ✔ ADRでの決定に縛られる可能性がある
37. ADRのデメリット ✔ ADRの記述コストが掛かる → 方針やその経緯を都度調べるのもコストは掛かる 　 それらを一元管理できるADRは資産 ✔ ADRでの決定に縛られる可能性がある → 既存のADRを必ずしも正とはしない 　 状況に応じて柔軟に変更していく
38. 3 まとめ
39. まとめ • 新規プロジェクト用のテンプレートリポジトリを構築している • 運用管理ツールや開発基盤の標準化により開発の効率化を図っている • ADRを活用して方針の議論・記録を行っている
40. ありがとうございました