新ゲームサーバ基盤Takashoでの
 Go言語活用事例の紹介
 中島 清貴
 ゲーム・エンターテインメント事業本部ゲーム事業部 
 Publish統括部共通基盤部ゲームデベロッパーサービスグループ 
 株式会社ディー・エヌ・エー 


自己紹介
 中島 清貴
 
 2016年 DeNA新卒入社
 
 2016年 - 2017年 キュレーション事業部
 • ライター管理ツールの開発・運用
 
 2017年 - 2019年 ゲーム事業部
 • ゲームサーバ基盤 Sakashoの開発・運用
 • 3月からTakashoチームにJoin!
 • RubyからGoへ
 2

目次
 3 DeNAのネイティブアプリゲーム開発事情
 Takashoとは
 Go言語の活用事例
 1 3 今後の展望・まとめ
 4 2

4 DeNAの
 ネイティブアプリゲーム
 開発事情


DeNAのネイティブアプリゲーム開発事情
 • 複数のネイティブアプリゲームをリリース中
 • 多数の新規タイトルが開発中
 • 今後の成長戦略として「大型IP活用に重点を置いた新規タイトルラインナップを形成、グローバル での配信も推進」することを掲げている
 • 現在運用中のタイトルの多くはゲームサーバ 基盤Sakashoを利用している
 5

Sakashoとは
 • ネイティブアプリゲームに必要なサーバ機能群を提供する共通ゲー ムサーバ
 • プレイヤーデータの管理機能
 • 課金系機能
 • ログボ機能...etc
 • 複数タイトルが同一サーバに相乗りする構成
 • 新規タイトル用のサーバ環境構築が容易
 • サーバの開発・運用は共通基盤チームが行う
 • ゲームサーバで必要なことをSakashoが一括で受け持つことで各タイ トルチームはクライアント側の実装に集中できる
 • 複数のタイトルを効率的にリリースでき、安定した運用もできている ので一定の成功を収めたと言える
 6 Sakasho
 タイトルA
 タイトルB
 タイトルC
 タイトルD
 タイトルE


Sakashoの課題
 • タイトルチーム視点での課題
 • 制約が強く、自由度が小さい
 • 現在のアプリゲーム市場の競争は激しく、勝ち残るには尖ったゲーム性が必要
 • タイトル独自のサーバ機能をSakashoに入れることはハードルが高い
 • 意思決定がチーム内で完結しない
 • 共通基盤チーム視点での課題
 • どんな変更でも直接的に全体に影響を与えうる
 • 常に先手を取って全体最適となるような意思決定が必要
 7 この課題を解決し今後のゲーム開発を
 支える新ゲームサーバ基盤が必要となった


8 Takashoとは


Takashoとは
 • ステートレスなAPIサーバを開発・運用するためのWebサーバフレームワーク
 • 各ゲームタイトルはTakashoフレームワークを使ってサーバの開発・運用を行う
 • シンプルな1サーバ1クライアントの構成
 • Webサーバフレームワークという形式を採っているためゲーム独自機能の追加が容易
 
 9

提供しているもの
 • Takasho Framework
 • Webサーバフレームワーク 
 • Takasho SDK
 • Takasho Frameworkで作ったゲームサーバと通信するためのクライアントSDK
 • Opeツール
 • データの登録・更新を行うためのCLIツール
 • データの参照を主とした管理画面
 • インフラ構築・運用ツール
 • TakashoではGCPを利用することを前提としている
 • 1コマンドでGCP上にサーバ構築を行うツールを提供 (terraformを使用)
 
 
 10

提供しているもの
 • Common Featureset
 • どのゲームのサーバにも必要であろう汎用機能群
 • プレイヤーデータ管理機能
 • ログボ機能、
 • ガチャ機能...etc
 • シンプルなサーバ機能のみ必要とするタイトルはCommon Featuresetだけ利用し、それ以上 のサーバ実装を行わないという選択も可能
 
 
 
 
 11

開発言語
 • クライアント側(Takasho SDK)はC#
 • サーバ側機能は全てGoで実装
 • Goを選定した理由
 • 少ない学習コストで高いパフォーマンスと安定性が得られるため
 • 高負荷がかかるゲームサーバには高いパフォーマンスと安定性が求められる
 • 0から学んだときにできるだけ学習コストがかからないものを選択したい
 • 以上のことを考慮するとGoが最も適していると判断した
 12

構成
 13 App Engine Standard Environment API server App Engine Ope Tool App Engine iOS Android Takasho SDK Takasho SDK Storage database Cloud Spanner HTML server App Engine assets Cloud Storage Monitoring Stackdriver Monitoring Logging Error Reporting CDN Operator

14 Go言語活用事例

Takasho Framework
 • ステートレスなAPIを開発するためのWebサーバフレームワーク
 • Go 1.12.3
 • パッケージ管理ツールにはdepを使用 (Go Modulesへの移行作業中)
 • Goパッケージとして提供し、利用者はgo getして使う
 • 提供機能
 • RPCサーバ
 • Cloud Spannerを扱うためのライブラリ
 • logger (stackdriver logging or 標準出力)
 • コード自動生成ツール...etc
 15

RPCサーバ
 • サーバ・クライアント間の通信に使う
 • net/httpベースのRPCサーバ
 • protobufをIDLとして採用
 • エンドポイントのインターフェースはprotoスキーマで定義
 • protoスキーマからコードを自動生成
 • protocコマンドをプラグインで拡張して独自の自動生成を実装している
 • 要はgRPCのようなものを独自実装している
 • 本当は純正のgRPCを使いたいが、GAEではgRPCをサポートしていないため使えなかった
 16

protobufの自動生成
 protocコマンドを使うと各言語用のシリアライズ/デシリアライズコードがprotoス キーマから自動生成できる
 17 syntax = 'proto3';
 option optimize_for = LITE_RUNTIME; 
 
 message User {
 int32 id = 1;
 string name = 2; 
 string email = 3; 
 }
 package api
 import ...
 
 type SampleGetUserV1 struct { 
 XXX_NoUnkeyedLiteral struct{} `json:"-"` 
 XXX_unrecognized []byte `json:"-"` 
 XXX_sizecache int32 `json:"-"` 
 }
 
 func (m *SampleGetUserV1) XXX_Unmarshal(b []byte) error { 
 }
 
 func (m *SampleGetUserV1) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) { 
 }
 sample.proto
 sample.pb.go(一部抜粋) 


protocのプラグインによる拡張
 • protocコマンドにはプラグインによる拡張機構が提供されている
 • 処理の途中で外部プログラムを呼び出せる
 • protocの解析結果を外部プログラムに渡し、外部プログラムの実行結果を最終的な出力とするという仕 組み
 18 protoc
 protoc
 plugin
 message User {
 int32 id = 1;
 string name = 2; 
 string email = 3; 
 }
 plugin generated code 


プラグインを使った自動生成
 • protocプラグインを作り、protoスキーマから色々なコードを自動生成している
 • go templateでコードテンプレートを作り、protobufのメッセージ情報を埋め込む
 19 package {{ afterLastSlash $.File.TakaRpcGoPackage }} 
 import (
 {{ range $_, $method := $.Methods }} 
 {{ $method.Desc.GetName }}_req_pb "{{ $method.Req.File.Desc.GetOptions.GetGoPackage }}" 
 {{ end }}
 )
 func new_{{ $.Desc.GetName }}_{{ $method.Desc.GetName }}_Endpoint (delegateFactory func() {{ $delegate }}) *rpc.Endpoint { 
 return &rpc.Endpoint{ 
 Id: "{{ $method.GetEndpointId }}", 
 Name: "{{ $.File.TakaRpcGoPackage }}:{{ $.Desc.GetName }}.{{ $method.Desc.GetName }}", 
 CallFunc: func(ctx context.Context, req *rpc.EndpointRequest) *rpc.EndpointResponse { 
 delegate := delegateFactory() 
 resPb, errorResponse := delegate.Call(ctx, reqPb, req.Time, req.ClientInfo) 
 if errorResponse != nil { 
 return &rpc.EndpointResponse{ 
 Payload: nil,
 ErrorResponse: errorResponse, 
 }
 }
 自動生成用テンプレート(一部抜粋) 


RPCサーバ関連の自動生成物
 • protobufメッセージのシリアライズ/デシリアライズコード(Go, C#)
 • エンドポイントのインターフェースやルーティングなど実際のロジックを除くサーバAPIのコード(Go)
 • APIリクエストを実行するコード(C#)
 • APIドキュメント(html)
 　全て同一のprotoスキーマから自動生成される
 
 20 できるだけ自動生成することで
 新たな機能を足すときの負担を減らしている


DBのテーブル作成&モデル自動生成
 • テーブルはjsonで定義
 • jsonを元にSpannerへのテーブル作成などを 行う
 • jsonから各テーブルに対する薄めのORマッ パーの自動生成も行う
 • 自動生成コードのテストコードも自動生成
 21 {
 "name": “Item",
 "columns": [
 {
 "name": "ItemId",
 "type": {
 "dataType": "STRING",
 "size": "36",
 "arrayElement": null
 },
 "pk": true,
 "null": false,
 "options": ""
 },
 {
 "name": "name",
 "type": {
 "dataType": "STRING",
 "size": "36",
 "arrayElement": null
 },
 "pk": false,
 "null": false,
 "options": ""
 }
 }
 }
 


Featuresetを組み合わせる
 • Featureset
 • Takasho Frameworkをベースにして作った機能群
 • Common FeaturesetもTakasho Frameworkをベースに作られている
 • 複数のFeaturesetは組み合わせて使うことができる
 • TakashoのRPCサーバのエンドポイントは単純な関数の配列
 • Featuresetを組み合わせるときは各Featuresetの関数の配列を マージして登録するだけ
 • 組み合わせたいFeaturesetをjsonで定義しておくと自動生成時 に関数の配列をマージする
 
 22 { "dependence": [ "Takasho/common_featureset", "Takasho/gacha_featureset" ] } Game Featureset
 Common Featureset
 Gacha
 Featureset


23 今後の展望・まとめ

Takashoの今後の展望
 • 現在も絶賛開発中
 • GKEへの移行を検討中
 • GAEだとgRPCがサポートされていない(2回目)
 • gRPCを使うためにGKEを検討しているが、GAEに比べると管理することが多くなるのが難点
 • 本番運用に向けた対応
 • ツールの整備
 • ドキュメントの整備
 • 負荷試験...etc
 • その他にもやることがいっぱい 
 24

まとめ
 • DeNAのネイティブアプリゲームのサーバ基盤としてSakashoが使われていた
 • 競争の激しいゲーム市場で勝ち残るために新たなゲームサーバ基盤が必要となり、Takashoが誕生し た
 • TakashoはWebサーバフレームワークという形式を採ることで、従来の共通サーバ型で難しかったタイト ル固有の機能の追加が容易にできるようになった
 • Takasho Frameworkではスキーマファイルを元に様々なコードの自動生成ができ、新たな機能を追加す るときの負担を減らしている
 
 25