2015年2月9日第四回DeNAゲーム開発勉強会資料 ※当日頂いたQ&Aを追加しました（2015/2/10）

1. Game BaaS
Implemented in Ruby
@tohae

2. 自己紹介
• @tohae （とはえ）
• サーバサイドエンジニア(Ruby, Perl, PHP)
• ソーシャルゲームのサーバサイドを横断的に
開発、ヘルプ

3. 今日話すこと
DeNAでのアプリ開発の歴史
最近のアプリ開発の構成
サーバサイドの仕組み

4. DeNAでのゲーム開発の歴史

5. アプリ以前(2009年∼）
• HTML
• Javascript
• Perl(MobaSiF)
参考：【YAPC::Asia 2008】モバゲータウンのフレームワーク
「MobaSiF」公開:
http://codezine.jp/article/detail/2528

6. アプリ時代その1（2012∼)
• Kickmotor
• Perl(MobaSiF or GunyaSiF)
参考: Kickmotor
http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=002421
参考: GunyaSiF
http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=002398

7. アプリ時代その2(2014∼)
• Unity or LiftEngine
• Game BaaS
今日はこのGame BaaSの話をします！
（開発中の画像予定）

8. Game BaaS is 何？

9. ソーシャルゲーム向けの
Backend as a Service。

10. Backend as a Service?
スマートフォン向けのWebアプリケーションが必要とするサーバ側の様々な機能をイン
ターネットを通じてサービスとして提供するクラウドサービスの一種。 提供される機能
はサービスにより様々だが、利用者情報の登録・管理や認証、データの保管、プッシュ
通知、課金・決済、ソーシャルメディアとの連携などが実装されていることが多い。アプ
リケーション開発者はこれらの機能のAPIを呼び出すよう設定することで、自らのアプリ
ケーションの一部として取り込むことができる。
!
http://e-words.jp/w/BaaS.html
+ ソーシャルゲーム向けの機能

11. = Game Backend as a
Service

12. ソーシャルゲーム向けの機能

13. • セーブデータの保存/読み込み
• ガチャ
• ログインボーナス
• フレンド
• ランキング
• ショップ
• 補填
• 友達招待
• チャット
• アセット配信
• マスターデータ配信
• お知らせ
• アチーブメント
• カスタマーサポート
• チート対策
• イベント配信
• 事前登録
• Push通知

14. • セーブデータの保存/読み込み
• ガチャ
• ログインボーナス
• フレンド
• ランキング
• ショップ
• 補填
• 友達招待
• チャット
• アセット配信
• マスターデータ配信
• お知らせ
• アチーブメント
• カスタマーサポート
• チート対策
• イベント配信
• 事前登録
• Push通知
他にもいろいろ
たくさんある

15. Game BaaSの目的
• たくさんのソシャゲ向けの機能を再開発する
のは無駄
• 汎用化してどんなソシャゲにも使える機能を
サービスとして提供しよう

16. 提供しているもの
• Client SDK
• C#, C++, Objective-C, Java
• 管理画面
• 商品、アセットなどゲームで必要な物を登録
• カスタマーサポート向けの運用機能

17. ここがすごいよ
Game BaaS

18. サーバの開発、運用が不要
アラートに怯える日々とおさらば。
インフラのことは考える必要なし。
リリース直後のアクセス急増も安心。

19. ユーザーサポートが統一化
いわゆる管理画面を作らなくていい。
ゲームごとに違う管理画面に悩まされない。

20. ！！！とても便利！！！

21. サーバサイドの仕組み
（ここからが本編?です）

22. サーバ構成イメージ

23. 各種サーバについて
• Proxy Server
• EventMachine
• API Server
• Sinatra
• Management Tool
• Rails
• DB
• MySQL
• Q4M
• Redis

24. Proxy Server
• EventMachine
• マルチプロセス化
• 認証
• 各種APIサーバへの振り分け
• 各種APIでの共通処理
• 垢BAN
• バージョンチェック

25. EventMachineのマルチプロ
セス化
EventMachineはマルチコアを使い切れない。
そのためUnicornのように、EventMachineのマス
タープロセスからEventMachineのワーカープロセス
を作るようにしている。
Graceful Restartにも対応。

26. API Server
• Sinatra + Sequel + Unicorn
• 機能毎にAPI Serverを分割
• REST風API
• APIサーバ間で共通の処理はgem化
• APIサーバ間ではほぼ通信していない

27. APIサーバ間で通信しない
セーブデータ保存APIと購入APIを用意していたが、ゲーム開発者からするとセーブデー
タの保存と購入処理を1トランザクションで安全にやりたいという要望があった。
そのためにそれらを同時に行えるAPIを用意しているが、その内部処理で購入APIから
セーブデータ保存APIをHTTPで呼び出さず、セーブデータ保存APIのロジックを共有
(gem化)してSQLを発行している。
これはHTTPでの呼び出しのパフォーマンスの懸念もあるが、それよりもHTTPで失敗し
た場合のロールバックの煩雑さを回避するため。

28. Management Tool
• いわゆる管理画面を作成
• Rails + Unicorn
• 複数DB対応はActiveRecord::Baseを継承した
クラス
• 最近はSwitchPointで書き換え中

29. DB
• MySQL 5.6.x
• 機能毎にDBを複数
• Gameの設定、Player関連データ、ログ、ランキングなどなど
• 全ゲームのデータが同居
• スキーマレス
• セーブデータなどはゲームごとにスキーマが異なるので、
JSONをテーブルに圧縮してぶっこんでる

30. Sharding
• プレイヤーごと(一部ゲームごと)に水平分割
• プレイヤー作成時にDBを決定
• DBは重み管理テーブルによって決める
shard id weight
1 20
2 20
3 60
player id shard id
1 1
2 1
3 3
shard重み管理テーブル
DB接続先管理テーブル

31. Sharding(2)
• DBの接続先管理はアプリでがんばる
• リクエストごとにDB接続先を決定

32. その他DB案件
http://www.slideshare.net/sonots/mobage-ruby-db

33. なぜRubyを選んだのか？

34. Perlが書けなかったから！！！
（個人的な理由です）

35. その他、後付の理由
• テストが書きやすい
• 管理画面を作成するにはRailsが便利
• 便利gem多いので開発速度速い

36. しかしすんなりRubyが採用される
わけもなく、いろんな質問をされ
ました…。

37. DeNAのインフラ要件を満た
すライブラリは？
ログ、デプロイ、監視、DNSの名前解決、Master-
Slave, Sharding, コネクションなどなど…。
これらは既存のgemを使ったり、新しくgemを
作ったりして解決。

38. パフォーマンスは大丈夫なの？
計測した感じではそこまで悪くなかった。
またAPIサーバを機能毎に小さく分割しているので、パ
フォーマンスが悪いAPIサーバだけを増やせば良い。
最悪の場合はそこだけ別の言語で作りなおせるように
小さく分割している。

39. LL(Perl)からLL(Ruby)なのは
なぜ？GolangとかScalaは？
チャレンジしたかったけど、経験者がいなかっ
たし、スケジュール的に厳しかった。
将来書き換えられると良いな…。

40. 他にもいろいろありましたが、
最後は泣いてお願いしました

41. まとめ

42. まとめ
• サーバサイドはBaaSを作って、ゲームはそれ
を使って開発効率を上げている
• 最近はサーバサイドにRubyを使っている
• DeNAではBaaSの開発に興味のあるRubyエン
ジニアを募集しています。

43. ご清聴
ありがとうございました

44. Q & A

45. Q: 1サーバが死ぬと、全ゲー
ムが死ぬんですか？
A: 死にます…。

46. Q: APIのバージョニングはど
うしてますか？
A: URLにAPIのバージョニングを含め、古い
バージョンもメンテナンスをしています。
SDKのバージョンアップでURLを変更してい
ます。

47. Q: AWSでやってるんですか？
A: オンプレです。

48. Q: ResqueやSidekiqは使っ
てる？
A: Q4Mから取得するデーモンを自前で作成
しています。