DeNAのゲーム開発を支える Game Backend as a Service

Copyright © DeNA Co.,Ltd. All Rights Reserved.
January 29, 2016
Takehiko YOKOTA
Makoto HARUYAMA
DeNA Co., Ltd.
のゲーム開発を支える
Game Backend as a Service

少し自己紹介
2
● 2008年 DeNA入社(みんなのウェディング)
● 2010年エンジニアになる
● 2011年 DeNA退社 -> 福岡へ
● 2013年 DeNAに出戻り
● 2016年ゲーム事業本部
Makoto HARUYAMA
● GitHub https://github.com/SpringMT
● Twitter https://twitter.com/Spring_MT
春山誠

を支える技術

なにを支えているのか？
4
DeNAのゲーム事業の裏側

どうやって支えているか？
ネイティブアプリ用プラットフォーム
Sakasho

今日お話すること
1. Sakashoとは
2. Sakashoの構成について
3. Rubyを使った開発について
4. その他の技術
5. Sakashoチームの体制について
6. まとめ
6

7
Sakashoとは

Sakashoとは
ネイティブアプリゲーム開発に
必要とされるサーバー機能を
提供するゲームプラットフォーム
ゲーム開発におけるサーバー機能を
Sakashoが一括で受け持つ
ことで開発・運用コストを削減
運用のしやすさも見据えたゲームの
作り方のルールもある程度強いる
8

ゲーム開発・運用に必要なAPIの提供
● ユーザー情報API
● マスターデータ配信API
● ログインボーナスAPI など
9
Sakashoが提供している機能

SDK
● 課金やPush通知など、OSに依存している機能について
簡単に使えるインターフェースの提供
● Unity、C++のゲームエンジンに対応
10

WebView用インターフェースの提供
● お知らせの配信
● 掲示板
● 利用規約など
11

ゲーム専用サーバーとの連携機能
● ゲーム専用サーバーからSakashoにアクセスできる
Web APIを提供
● ゲーム専用サーバーを介しての
ユーザー情報の取得などに対応
12

Sakashoの機能一覧(一部抜粋)
● マスターデータ配信
● アセット配信
● プレイヤー管理
● お知らせ管理
● アイテム管理
● ログインボーナス
● お問合せ機能
● 課金
● ログ管理
13
● ランキング
● 掲示板
● 補填機能
● メンテナンス
● Push通知
● プレイヤー検索機能
● ギルド
● アプリのバージョン管理
● CS運用ツール

主なリリースタイトル
14

Sakashoの構成について

マイクロサービス？
役割毎に10の独立したAPIコード群がある
○ メリット
■ 他のAPIへの影響を考えずにデプロイできる
■ リソースを細かく調整できる
○ デメリット
■ 運用工数がかかる(gemの更新とか)
■ 結局サービス毎に人を専用にアサインとかしなかったので、全員
全部見る状態
コード量も少ない(API全部ファイル数が700程度、行数3万行)のでこの規模
だと管理工数のほうが大きい

18

○ MySQLのMaster/Slave構成 + sharding
○ MHAでMasterの高可用性
○ MySQLへの接続は都度接続
○ DNSサーバーはMyDNSを使って、DeNA独自の拡張も入っている
DB周りは、基本インフラチームの指針にそっており、DeNAのオーソドックス
な構成になっています
DBに関して

Rubyを使った開発

Rubyを書ける人が多いチーム
○ Rubyで開発、運用 > Perlでの開発・運用
○ 何かあってもフォローできる人材がいる
採用面
○ Rubyでサービス開発を経験している人材の増加
Rubyの選択
21
PerlからRubyへの移行対応も責任をもって進めた

● Rubyの導入期
● Rubyを使った開発期
● Rubyで書かれたアプリケーションの運用期
Rubyを使った開発と運用
22

Rubyの導入期

DeNAで運用するための要件を満たすためのモ
ジュール
Rubyの導入期
ResolverMyDNS
○ MyDNSにアクセウし名前解決をするためのモジュール
○ DNSキャッシュもしている
○ DNSサーバーにDeNA用に拡張したMyDNSを使っており、それに即
した作りになっている。

Rack::PerformanceLog
○ DeNA専用のパフォーマンス調査用のログを出すrackミドルウェア。
○ 一行追加すればOK
DeNAで運用するための要件を満たすためのモ
ジュール
Rubyの導入期

社内rubygemsサーバーの構築
社内専用gemの管理・配布のため
○ Gem in a Boxを使っている
Rubyの導入期

小さいサービスで実績を作る
○ 社内サービスをリリース
■ 社内用アプリ配信ツール(Rails) iota
実績とテスト
27
Rubyの導入期

Rubyを使った開発期

1. API サーバー : Sinatra + Sequel + Jbuilder
a. 省メモリ・ハイパフォーマンス
b. JSONしか返さない
2. 管理ツール : Ruby on Rails
a. アクセス数は限られている
b. Web UIを簡単に作れる
c. 多少パフォーマンスが犠牲にしても、開発スピードを上げる
フレームワーク選定
29

高速化
○ capistrano-bundle_rsync
○ デプロイサーバでアプリを git clone して bundle install したものを
rsyncするためのgem
daemontoolsとの連携
○ インフラチーム
http://d.hatena.ne.jp/limitusus/20131225/1387993119
http://blog.livedoor.jp/sonots/archives/40248661.html
Deploy
30

ridgepole
https://github.com/winebarrel/ridgepole
● ファイルの内容を実際のスキーマとの差分があればそれを自動的に
検知し、DDLを発行してくれる
● 1テーブル1ファイルで表現
● shardingにも対応したスクリプトを用意
スキーマ管理
31

Sakashoの共通ロジックをgemにする
○ API毎のリクエスト・レスポンスの共通処理の切り出し
○ モデルの共通化
DBのコネクション管理
○ APIではコネクション管理用の軽いラッパーを用意
■ コードの中で明示的にMaster or Slaveなのかを書く
○ 管理ツール(Rails)ではSwitchPointを使用
その他
32

Rubyを使った
アプリケーションの運用期

パフォーマンス向上
○ picojson_ruby
監視
○ stackprof
○ rack-server_status
運用ツール
○ unicorn-timeout_backtracer
○ unicorn-configurator_from_env
○ unicorn-log_error_one_liner
運用時
34
Rubyを使ったアプリケーションの運用期

PicojsonRuby
○ rubyの標準ライブラリを使ってJSONをparseすると元のJSONの大き
さの約10倍くらいのメモリを消費する
○ Proxyサーバーで共通のkey valueを1つだけ追加したいだけ
○ C++でかかれたpicojsonをrubyから呼び出せるようにして、JSONの
操作をC++で行うようにした
パフォーマンス向上
35

Stackprof
○ https://github.com/tmm1/stackprof
○ SakashoのAPIサーバーに下記のようなコードを仕込んでいる
Rubyのプロファイリング
36

Rack::ServerStatus
○ workerの状況を返すエンドポイントを追加する
rackミドルウェア
○ workerが枯渇して大障害になった経緯から作成
枯渇するとアラートが飛んでくるようになっている
Workerの状態監視
37
2016-01-25 19:23:15.643716
[host名 sakasho.test.example] BusyWorkers: 3, IdleWorkers: 0
pid status remote_addr host method uri protocol ss
22286 A 127.0.0.1 sakasho.test.example GET /server-status?json HTTP/1.0 0
22289 A 127.0.0.1 sakasho.test.example POST /v1foo HTTP/1.0 0
22292 A 127.0.0.1 sakasho.test.example GET /v1/bar HTTP/1.0 0

Unicorn::ConfiguratorFromEnv
○ Unicornのworker数を環境変数で設定できる
○ アプリケーションのコードを修正せずに
インフラチームだけで対応できる
require するだけでOK
worker数をすぐに調整できるようにする
38

Unicornがタイムアウトしたときの調査
Unicorn::TimeoutBackTracer
○ Unicornのworkerがタイムアウトしたときに、プロセスをkillする前に、
gdbrubyを使用してバックトレースを取得する
○ requireするだけでOK
$ cat /tmp/test-timeout-16768.log
command:
gdb -silent -nw /sake/.rbenv/versions/2.1.3/bin/ruby 16603
environ:
ruby_version:
c_backtrace:
#0 0x00007ff11bd1c2f3 in select () from /lib64/libc.so.6
#1 0x00007ff11ceba8f6 in rb_fd_select (max=13, read=0x7fff469285f0, write=0x0, except=0x0, timeout=0x7fff46928340) at
thread.c:3336

AWS

AWSも活用しています
○ S3
■ 履歴等のデータの保存
■ ファイル配信
○ SNS
■ push通知
■ 全ユーザーに配信が簡単にできる
AWS
41
その他の技術

Sakashoチーム

チーム
○ 8人から12人くらい
■ ブラウザタイトルからアプリタイトルへ移行する際にsakashoの運
用を経験することが多い
リリースサイクル
○ 2週間に一度のペースでリリース
○ 2週間でできることやる
Sakasho専任チーム
43
Sakashoチーム

リリースサイクル

● 要望確確認会: リリースに含める
フィーチャーを検討
● Sakasho定例: リリースに含める予
定のフィーチャーをチームにシェア
● QA Kickoff: リリースに予定の
フィーチャーをQAに伝え、リリース
するフィーチャーとリリース日を決
める
● リリース告知: ゲームデベロッパに
アナウンスする。
リリースサイクルを細かく
45
● 仕様書コンプリート
● 開発開始
● SDKのスケルトン提出
● フィーチャーコンプリート
● QA開始
● サインオフ（QA完了）
● リリース
● QA確認
● ゲームデベロッパにリリースした旨をア
ナウンス
● Sakasho定例: フェーズの振り返り
Sakashoチーム

他部署との連携
46
ゲームの開発・運用には色々な部署が関わっています
○ インフラ
○ CS
○ QA(Sakasho自体のQAとゲームのQA)
○ マーケティング(特にプロモーション関連)
○ バックオフィス関連
■ 法務
■ 経理
○ 各ゲーム開発を調整するチーム
Sakashoチーム

他部署との連携
47
色々な人達との調整も含めてSakashoが引き受けます
○ CS向けやマーケティング向けのツールも提供
■ レポーティング機能
■ お問合せ対応ツール
■ HadoopログAPIの提供
○ わからないことがあったら
■ 基本社内にユーザーがいるので、聞きに行く！
Sakashoチーム

Sakasho以外にも

ゲーム開発を支えるサービス
49
iota
○ アプリ配信ツール
○ iOSアプリでは社内用の証明書にリザインする
○ 30 GB / day くらいの転送量が発生している一大社内サービス
(ゲーム以外も利用)
TwitterDM送信ツール
○ スケジュール配信可能
Sakasho以外のサービス

まとめ
ゲーム開発を支えるプラットフォームSakasho
○ Sakashoがサーバー側の運用を一括で受け持つことで
各ゲームタイトルはゲーム開発に集中できる
Sakashoのサーバーサイドの開発はRubyを使っている
○ 大規模なアプリケーションの開発・運用に
必要な仕組みを整備しました

DeNAのゲーム開発を支える Game Backend as a Service

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to DeNAのゲーム開発を支える Game Backend as a Service

Similar to DeNAのゲーム開発を支える Game Backend as a Service (20)

More from Makoto Haruyama

More from Makoto Haruyama (11)

DeNAのゲーム開発を支える Game Backend as a Service