Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Game BaaS Implemented in Ruby

6,194 views

Published on

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

Published in: Engineering
  • Be the first to comment

Game BaaS Implemented in Ruby

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

×