Transcript

• 1. Game BaaS Implemented by 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. ご清聴 ありがとうございました