Upgrade to Pro — share decks privately, control downloads, hide ads and more …

新ゲームサーバ基盤TakashoでのGo言語活用事例の紹介

kyotak
July 18, 2019

 新ゲームサーバ基盤TakashoでのGo言語活用事例の紹介

kyotak

July 18, 2019
Tweet

More Decks by kyotak

Other Decks in Technology

Transcript

  1. 新ゲームサーバ基盤Takashoでの

    Go言語活用事例の紹介

    中島 清貴

    ゲーム・エンターテインメント事業本部ゲーム事業部 

    Publish統括部共通基盤部ゲームデベロッパーサービスグループ 

    株式会社ディー・エヌ・エー 


    View full-size slide

  2. 自己紹介

    中島 清貴


    2016年 DeNA新卒入社


    2016年 - 2017年 キュレーション事業部

    • ライター管理ツールの開発・運用


    2017年 - 2019年 ゲーム事業部

    • ゲームサーバ基盤 Sakashoの開発・運用

    • 3月からTakashoチームにJoin!

    • RubyからGoへ

    2

    View full-size slide

  3. 目次

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

    Takashoとは

    Go言語の活用事例

    1
    3
    今後の展望・まとめ

    4
    2

    View full-size slide

  4. 4
    DeNAの

    ネイティブアプリゲーム

    開発事情


    View full-size slide

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

    • 複数のネイティブアプリゲームをリリース中

    • 多数の新規タイトルが開発中

    • 今後の成長戦略として「大型IP活用に重点を置いた新規タイトルラインナップを形成、グローバル
    での配信も推進」することを掲げている

    • 現在運用中のタイトルの多くはゲームサーバ 基盤Sakashoを利用している

    5

    View full-size slide

  6. Sakashoとは

    • ネイティブアプリゲームに必要なサーバ機能群を提供する共通ゲー
    ムサーバ

    • プレイヤーデータの管理機能

    • 課金系機能

    • ログボ機能...etc

    • 複数タイトルが同一サーバに相乗りする構成

    • 新規タイトル用のサーバ環境構築が容易

    • サーバの開発・運用は共通基盤チームが行う

    • ゲームサーバで必要なことをSakashoが一括で受け持つことで各タイ
    トルチームはクライアント側の実装に集中できる

    • 複数のタイトルを効率的にリリースでき、安定した運用もできている
    ので一定の成功を収めたと言える

    6
    Sakasho

    タイトルA
 タイトルB
 タイトルC

    タイトルD
 タイトルE


    View full-size slide

  7. Sakashoの課題

    • タイトルチーム視点での課題

    • 制約が強く、自由度が小さい

    • 現在のアプリゲーム市場の競争は激しく、勝ち残るには尖ったゲーム性が必要

    • タイトル独自のサーバ機能をSakashoに入れることはハードルが高い

    • 意思決定がチーム内で完結しない

    • 共通基盤チーム視点での課題

    • どんな変更でも直接的に全体に影響を与えうる

    • 常に先手を取って全体最適となるような意思決定が必要

    7
    この課題を解決し今後のゲーム開発を

    支える新ゲームサーバ基盤が必要となった


    View full-size slide

  8. 8
    Takashoとは


    View full-size slide

  9. Takashoとは

    • ステートレスなAPIサーバを開発・運用するためのWebサーバフレームワーク

    • 各ゲームタイトルはTakashoフレームワークを使ってサーバの開発・運用を行う

    • シンプルな1サーバ1クライアントの構成

    • Webサーバフレームワークという形式を採っているためゲーム独自機能の追加が容易


    9

    View full-size slide

  10. 提供しているもの

    • Takasho Framework

    • Webサーバフレームワーク 

    • Takasho SDK

    • Takasho Frameworkで作ったゲームサーバと通信するためのクライアントSDK

    • Opeツール

    • データの登録・更新を行うためのCLIツール

    • データの参照を主とした管理画面

    • インフラ構築・運用ツール

    • TakashoではGCPを利用することを前提としている

    • 1コマンドでGCP上にサーバ構築を行うツールを提供 (terraformを使用)



    10

    View full-size slide

  11. 提供しているもの

    • Common Featureset

    • どのゲームのサーバにも必要であろう汎用機能群

    • プレイヤーデータ管理機能

    • ログボ機能、

    • ガチャ機能...etc

    • シンプルなサーバ機能のみ必要とするタイトルはCommon Featuresetだけ利用し、それ以上
    のサーバ実装を行わないという選択も可能





    11

    View full-size slide

  12. 開発言語

    • クライアント側(Takasho SDK)はC#

    • サーバ側機能は全てGoで実装

    • Goを選定した理由

    • 少ない学習コストで高いパフォーマンスと安定性が得られるため

    • 高負荷がかかるゲームサーバには高いパフォーマンスと安定性が求められる

    • 0から学んだときにできるだけ学習コストがかからないものを選択したい

    • 以上のことを考慮するとGoが最も適していると判断した

    12

    View full-size slide

  13. 構成

    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

    View full-size slide

  14. 14
    Go言語活用事例

    View full-size slide

  15. Takasho Framework

    • ステートレスなAPIを開発するためのWebサーバフレームワーク

    • Go 1.12.3

    • パッケージ管理ツールにはdepを使用 (Go Modulesへの移行作業中)

    • Goパッケージとして提供し、利用者はgo getして使う

    • 提供機能

    • RPCサーバ

    • Cloud Spannerを扱うためのライブラリ

    • logger (stackdriver logging or 標準出力)

    • コード自動生成ツール...etc

    15

    View full-size slide

  16. RPCサーバ

    • サーバ・クライアント間の通信に使う

    • net/httpベースのRPCサーバ

    • protobufをIDLとして採用

    • エンドポイントのインターフェースはprotoスキーマで定義

    • protoスキーマからコードを自動生成

    • protocコマンドをプラグインで拡張して独自の自動生成を実装している

    • 要はgRPCのようなものを独自実装している

    • 本当は純正のgRPCを使いたいが、GAEではgRPCをサポートしていないため使えなかった

    16

    View full-size slide

  17. 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(一部抜粋) 


    View full-size slide

  18. protocのプラグインによる拡張

    • protocコマンドにはプラグインによる拡張機構が提供されている

    • 処理の途中で外部プログラムを呼び出せる

    • protocの解析結果を外部プログラムに渡し、外部プログラムの実行結果を最終的な出力とするという仕
    組み

    18
    protoc

    protoc

    plugin

    message User {

    int32 id = 1;

    string name = 2; 

    string email = 3; 

    }

    plugin generated code 


    View full-size slide

  19. プラグインを使った自動生成

    • 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, 

    }

    }

    自動生成用テンプレート(一部抜粋) 


    View full-size slide

  20. RPCサーバ関連の自動生成物

    • protobufメッセージのシリアライズ/デシリアライズコード(Go, C#)

    • エンドポイントのインターフェースやルーティングなど実際のロジックを除くサーバAPIのコード(Go)

    • APIリクエストを実行するコード(C#)

    • APIドキュメント(html)

     全て同一のprotoスキーマから自動生成される


    20
    できるだけ自動生成することで

    新たな機能を足すときの負担を減らしている


    View full-size slide

  21. 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": ""

    }

    }

    }


    View full-size slide

  22. 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


    View full-size slide

  23. 23
    今後の展望・まとめ

    View full-size slide

  24. Takashoの今後の展望

    • 現在も絶賛開発中

    • GKEへの移行を検討中

    • GAEだとgRPCがサポートされていない(2回目)

    • gRPCを使うためにGKEを検討しているが、GAEに比べると管理することが多くなるのが難点

    • 本番運用に向けた対応

    • ツールの整備

    • ドキュメントの整備

    • 負荷試験...etc

    • その他にもやることがいっぱい 

    24

    View full-size slide

  25. まとめ

    • DeNAのネイティブアプリゲームのサーバ基盤としてSakashoが使われていた

    • 競争の激しいゲーム市場で勝ち残るために新たなゲームサーバ基盤が必要となり、Takashoが誕生し
    た

    • TakashoはWebサーバフレームワークという形式を採ることで、従来の共通サーバ型で難しかったタイト
    ル固有の機能の追加が容易にできるようになった

    • Takasho Frameworkではスキーマファイルを元に様々なコードの自動生成ができ、新たな機能を追加す
    るときの負担を減らしている


    25

    View full-size slide