Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
新ゲームサーバ基盤TakashoでのGo言語活用事例の紹介
kyotak
July 18, 2019
Technology
3
3.3k
新ゲームサーバ基盤TakashoでのGo言語活用事例の紹介
kyotak
July 18, 2019
Tweet
Share
More Decks by kyotak
See All by kyotak
Learning Domain-Driven Design輪読会 #19
kyotak
0
4
Learning Domain-Driven Design輪読会#16
kyotak
0
20
Learning Domain-Driven Design輪読会#12
kyotak
2
50
Learning Domain-Driven Design輪読会#7
kyotak
0
49
Learning Domain-Driven Design輪読会#5
kyotak
1
150
Learning Domain-Driven Design輪読会#2
kyotak
1
420
Other Decks in Technology
See All in Technology
re:Invent2022 前後の Amazon EventBridge のアップデートを踏まえつつ、情シスの仕事をより楽しくしたい話。 / EventBridge for Information Systems Department
_kensh
0
200
API連携に伴う規制と対応 / Regulations and responses to API linkage
moneyforward
0
140
Virtual Thread - 導入の背景と、効果的な使い方 -
skrb
3
260
USB PD で迎える AC アダプター大統一時代
puhitaku
2
1.8k
OpenShift.Run2023_create-aro-with-terraform
ishiitaiki20fixer
1
180
OCIコンテナサービス関連の技術詳細 /oke-ocir-details
oracle4engineer
PRO
0
760
re:Inventで発表があったIoT事例の紹介と考察
kizawa2020
0
170
Hatena Engineer Seminar #23 「チームとプロダクトを育てる Mackerel 開発合宿」
arthur1
0
110
SmartHRからOktaへのSCIM連携で作り出すHRドリブンのアカウント管理
jousysmiler
1
110
GraphQLスキーマ設計の勘所
yukukotani
26
6.1k
LINE iOSエンジニアの日々 / LINE iOS Engineer Days
line_developers
PRO
1
140
Dev Containers ことはじめ - 失敗から学ぶ開発環境運用法
streamwest1629
0
310
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
65
7.8k
Side Projects
sachag
451
37k
How to name files
jennybc
47
73k
Web Components: a chance to create the future
zenorocha
304
40k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
239
19k
4 Signs Your Business is Dying
shpigford
171
20k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
22
1.7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
224
50k
Building an army of robots
kneath
301
40k
Fashionably flexible responsive web design (full day workshop)
malarkey
396
63k
Three Pipe Problems
jasonvnalue
89
8.9k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
101
6.2k
Transcript
新ゲームサーバ基盤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