game baas implemented in ruby
TRANSCRIPT
Game BaaS Implemented in Ruby
@tohae
自己紹介• @tohae （とはえ）
• サーバサイドエンジニア(Ruby, Perl, PHP)
• ソーシャルゲームのサーバサイドを横断的に開発、ヘルプ
今日話すこと
DeNAでのアプリ開発の歴史 最近のアプリ開発の構成 サーバサイドの仕組み
DeNAでのゲーム開発の歴史
アプリ以前(2009年～）• HTML
• Javascript
• Perl(MobaSiF)
参考：【YAPC::Asia 2008】モバゲータウンのフレームワーク
「MobaSiF」公開:
http://codezine.jp/article/detail/2528
アプリ時代その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
アプリ時代その2(2014～)
• Unity or LiftEngine
• Game BaaS
今日はこのGame BaaSの話をします！
（開発中の画像予定）
Game BaaS is 何？
ソーシャルゲーム向けの Backend as a Service。
Backend as a Service?
スマートフォン向けのWebアプリケーションが必要とするサーバ側の様々な機能をインターネットを通じてサービスとして提供するクラウドサービスの一種。 提供される機能はサービスにより様々だが、利用者情報の登録・管理や認証、データの保管、プッシュ通知、課金・決済、ソーシャルメディアとの連携などが実装されていることが多い。アプリケーション開発者はこれらの機能のAPIを呼び出すよう設定することで、自らのアプリケーションの一部として取り込むことができる。!
http://e-words.jp/w/BaaS.html
+ ソーシャルゲーム向けの機能
= Game Backend as a Service
ソーシャルゲーム向けの機能
• セーブデータの保存/読み込み
• ガチャ
• ログインボーナス
• フレンド
• ランキング
• ショップ
• 補填
• 友達招待
• チャット
• アセット配信
• マスターデータ配信
• お知らせ
• アチーブメント
• カスタマーサポート
• チート対策
• イベント配信
• 事前登録
• Push通知
• セーブデータの保存/読み込み
• ガチャ
• ログインボーナス
• フレンド
• ランキング
• ショップ
• 補填
• 友達招待
• チャット
• アセット配信
• マスターデータ配信
• お知らせ
• アチーブメント
• カスタマーサポート
• チート対策
• イベント配信
• 事前登録
• Push通知
他にもいろいろ たくさんある
Game BaaSの目的• たくさんのソシャゲ向けの機能を再開発するのは無駄
• 汎用化してどんなソシャゲにも使える機能をサービスとして提供しよう
提供しているもの• Client SDK
• C#, C++, Objective-C, Java
• 管理画面
• 商品、アセットなどゲームで必要な物を登録
• カスタマーサポート向けの運用機能
ここがすごいよ Game BaaS
サーバの開発、運用が不要
アラートに怯える日々とおさらば。 インフラのことは考える必要なし。 リリース直後のアクセス急増も安心。
ユーザーサポートが統一化
いわゆる管理画面を作らなくていい。 ゲームごとに違う管理画面に悩まされない。
！！！とても便利！！！
サーバサイドの仕組み（ここからが本編?です）
サーバ構成イメージ
各種サーバについて• Proxy Server
• EventMachine
• API Server
• Sinatra
• Management Tool
• Rails
• DB
• MySQL
• Q4M
• Redis
Proxy Server• EventMachine
• マルチプロセス化
• 認証
• 各種APIサーバへの振り分け
• 各種APIでの共通処理
• 垢BAN
• バージョンチェック
EventMachineのマルチプロセス化EventMachineはマルチコアを使い切れない。
そのためUnicornのように、EventMachineのマスタープロセスからEventMachineのワーカープロセスを作るようにしている。 Graceful Restartにも対応。
API Server• Sinatra + Sequel + Unicorn
• 機能毎にAPI Serverを分割
• REST風API
• APIサーバ間で共通の処理はgem化
• APIサーバ間ではほぼ通信していない
APIサーバ間で通信しない
セーブデータ保存APIと購入APIを用意していたが、ゲーム開発者からするとセーブデータの保存と購入処理を1トランザクションで安全にやりたいという要望があった。
そのためにそれらを同時に行えるAPIを用意しているが、その内部処理で購入APIからセーブデータ保存APIをHTTPで呼び出さず、セーブデータ保存APIのロジックを共有(gem化)してSQLを発行している。
これはHTTPでの呼び出しのパフォーマンスの懸念もあるが、それよりもHTTPで失敗した場合のロールバックの煩雑さを回避するため。
Management Tool• いわゆる管理画面を作成
• Rails + Unicorn
• 複数DB対応はActiveRecord::Baseを継承したクラス
• 最近はSwitchPointで書き換え中
DB• MySQL 5.6.x
• 機能毎にDBを複数
• Gameの設定、Player関連データ、ログ、ランキングなどなど
• 全ゲームのデータが同居
• スキーマレス
• セーブデータなどはゲームごとにスキーマが異なるので、JSONをテーブルに圧縮してぶっこんでる
Sharding• プレイヤーごと(一部ゲームごと)に水平分割
• プレイヤー作成時にDBを決定
• DBは重み管理テーブルによって決めるshard id weight
1 20
2 20
3 60
player id shard id
1 1
2 1
3 3
shard重み管理テーブル DB接続先管理テーブル
Sharding(2)
• DBの接続先管理はアプリでがんばる
• リクエストごとにDB接続先を決定
その他DB案件
http://www.slideshare.net/sonots/mobage-ruby-db
なぜRubyを選んだのか？
Perlが書けなかったから！！！ （個人的な理由です）
その他、後付の理由• テストが書きやすい
• 管理画面を作成するにはRailsが便利
• 便利gem多いので開発速度速い
しかしすんなりRubyが採用されるわけもなく、いろんな質問をされ
ました…。
DeNAのインフラ要件を満たすライブラリは？ログ、デプロイ、監視、DNSの名前解決、Master-
Slave, Sharding, コネクションなどなど…。
これらは既存のgemを使ったり、新しくgemを作ったりして解決。
パフォーマンスは大丈夫なの？
計測した感じではそこまで悪くなかった。 またAPIサーバを機能毎に小さく分割しているので、パフォーマンスが悪いAPIサーバだけを増やせば良い。 最悪の場合はそこだけ別の言語で作りなおせるように小さく分割している。
LL(Perl)からLL(Ruby)なのはなぜ？GolangとかScalaは？チャレンジしたかったけど、経験者がいなかったし、スケジュール的に厳しかった。 将来書き換えられると良いな…。
他にもいろいろありましたが、
最後は泣いてお願いしました
まとめ
まとめ• サーバサイドはBaaSを作って、ゲームはそれを使って開発効率を上げている
• 最近はサーバサイドにRubyを使っている
• DeNAではBaaSの開発に興味のあるRubyエンジニアを募集しています。
ご清聴 ありがとうございました
Q & A
Q: 1サーバが死ぬと、全ゲームが死ぬんですか？A: 死にます…。
Q: APIのバージョニングはどうしてますか？A: URLにAPIのバージョニングを含め、古いバージョンもメンテナンスをしています。 SDKのバージョンアップでURLを変更しています。
Q: AWSでやってるんですか？
A: オンプレです。
Q: ResqueやSidekiqは使ってる？A: Q4Mから取得するデーモンを自前で作成しています。