「オルタンシア・サーガ」開発の裏側
•
3 likes•4,502 views
f4samuraiが開発する「オルタンシア・サーガ－蒼の騎士団－」について、方式設計における幅広いノウハウの紹介。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 「オルタンシア・サーガ」開発の裏側
Similar to 「オルタンシア・サーガ」開発の裏側 (14)
「オルタンシア・サーガ」開発の裏側
- 2. f4samuraiってこんな会社 • 2010年1月に設立 • モバイル向けゲーム・アプリケーションの開発・運営 • 2012年 株式会社セガゲームス社と業務提携 • 企画・開発・運用は弊社 • 宣伝プロモーションはセガゲームス社 2
- 3. f4samurai TOP SALES 3 72013.7.29 2014.7.11 3 62015.12.10
- 4. f4samurai オフィスの変遷 0 5 10 15 20 25 30 35 40 45 50 第1期(2010/12) 第2期(2011/12) 第3期(2012/12) 第4期※(2013/3) 第5期(2014/3) 第6期(2015/3) 第7期(2016/3予) 社員数 4
- 5. オルタンシア・サーガ –蒼の騎士団- • 2015年4月リリース • 300万ダウンロード • 特長 • クエストの新しいゲーム性 • ギルド vs. ギルド • 50万文字を超えるストーリー • 2015年 Googleベストゲーム 5
- 6. オルタンシア・サーガ 開発体制 • プランナー 6名 • サーバエンジニア 5名 • クライアントエンジニア 4名 • フロントエンジニア 4名 • デザイナー 4名 • シナリオライター 3名 ・イラスト、サウンド、テストなどは一部外部に依頼 6
- 7. オルタンシア・サーガ リリースまでのスケジュール ▲2013/12 プロジェクト開始 ▲2014/4 プロトタイプ完成 ▲2014/8 αバージョン完成 ▲2014/9 βバージョン完成 2014/11当初リリース予定→作り直し ▲ 2015/1リリース予定→作り直し ▲ 2015/4リリース ▲ 7
- 9. 技術選定のポイント • 技術的に派手なこと、新しいことはやっていない • 枯れている、メンバーのスキルセットにあった技術を選定 • 基本に忠実に作る • 5つの「新」によるリスク • 新業界 • 新顧客 • 新技術 • 新PM • 新パートナー 9
- 11. 方式設計 • システム要件 • 性能目標 (DAU、スループット、レスポンスタイム) • 使用するプロトコル • システム拡張方式 • 想定外の負荷が発生したときにどのようにシステムを拡張するか • スケールアップ、スケールアウト • 負荷分散方式 • データ保持方式 • どのような形式でデータを持つか • どこにデータを持つか（分割するか） 11
- 12. 方式設計(2) • アプリケーション処理方式 • 認証 • トランザクション • 流量制御 • チート対策 • キャッシュ方式 • セキュリティ方式 12
- 13. 方式設計(3) • 運用方式 • 通常運用 (リリース、メンテナンス、バックアップ、ログ保持、 問い合わせ調査、KPI) • 障害時運用 (縮退運転、リカバリ) • 監視方式 • 死活監視、リソース監視 • 障害通知 • 性能監視 • 開発方式、テスト方式 • できるだけ短いサイクルで開発者が確認できるような仕組み • テスト環境と本番環境の使い分け 13
- 14. 方式設計(4) • ネットワーク設計 • ハードウェア選定 • ソフトウェア選定 • パラメタ設計 14
- 16. オルタンシア・サーガ 方式設計 (1) • システム要件 • ゲームの仕様上、HTTPとWebSocketを併用 • システム拡張方式 • Web, WebApp, Socket, Cacheはスケールアウト可能 • DBはスレーブのみスケールアウト可能 • マスタDBはスケールアップ or データ分散 • 負荷分散方式 • 入り口はロードバランサ • Web → WebApp は mod_proxy のロードバランス機能 • WebSocket はホスト名による負荷分散 16
- 17. WebSocketサーバの分散 • ギルド vs. ギルドのバトル中、 対戦しているギルド（チーム）同士は 同じSocketサーバに接続したい • サーバのホスト名を分けて、負荷を分散する • Socketサーバ障害発生時の動作を考慮する 17
- 18. WebSocketサーバの分散(2) Client WebApp Socket1 DB BattleID ServerID 10001 1 10002 2 … … ServerName=socket2 Socket2 ws://socket2.jp/… http://web.jp/… 18 Batch 監視
- 19. WebSocketサーバの分散 (障害発生時) Client WebApp Socket1 DB BattleID ServerID 10001 1 10002 1 … … ServerName=socket1 Socket2 ws://socket1.jp/… http://web.jp/… 19 Batch 監視
- 20. オルタンシア・サーガ 方式設計(2) • データ保持方式 • 大事なデータはサーバ側で持つ • マスタデータは垂直分散 • 認証方式 • トークン方式を採用し、同一ユーザ複数端末からの アクセスを制御 20
- 22. トークンによる制御 • アプリ起動時にトークンを発行 22 Client-A WebApp DB Client-B UserID Token User1 tokenAAA tokenAAA
- 23. トークンによる制御 (2) • 別端末でアプリを起動した時にトークンを上書き 23 Client-A WebApp DB Client-B UserID Token User1 tokenBBB tokenAAA tokenBBB
- 24. トークンによる制御 (3) • 端末から送信されたトークンと、サーバで保持している トークンが違うので認証エラー 24 Client-A WebApp DB Client-B UserID Token User1 tokenBBB tokenAAA tokenBBB
- 25. オルタンシア・サーガ 方式設計(3) • キャッシュ方式 • マスタデータはWebAppサーバ上に保持 • ユーザデータ（の一部）はCacheサーバ上に保持 • フロントは backbone.js を使って必要なアセットの先読み 25
- 26. マスタデータキャッシュ • マスタデータはほぼ更新されないので WebAppサーバでキャッシュしたい • iBATISのキャッシュは、高負荷時にスループットが 低下するバグがある • WebAppサーバ起動時にマスタデータをDBから取得して、 WebAppサーバ上にキャッシュする仕組みを実装 26
- 27. backbone.js • JavascriptでMVCを実現するフレームワーク • 必要なアセットを最初に読み込むことで、 ページ遷移をするときのもたつき感を減らす • 1イベントごと、など機能単位での採用 （イベント外のページに出ると再読込が必要） 27
- 29. SmartBeat • iOS/Androidでクラッシュが発生した場合に、 クラッシュ時のログ・端末情報などを収集する • アプリのバージョンアップ時は頻繁にチェック • ユーザIDによる検索も可能 29
- 30. オルタンシア・サーガ 方式設計(5) • 障害時の動き • Web, WebApp, Cache, SlaveDB サーバは落ちても対策しない （落ちてもシステム全体は耐えられるよう多めにサーバを用意） • Batch/AdminはWebAppと同じ構成なので、 落ちたら他サーバを転用する • Socket サーバは前述の通り • MasterDBはMHAによる監視 30
- 31. MHA for MySQL • Master High Availability Manager and tools for MySQL • MySQLサーバの監視 • 障害発生時にはスレーブをマスタに自動昇格させる 31
- 32. MHA(2) DB Master MHA 監視 db01-master DB Slave1 WebApp DB Slave2 db01-slave Name IP db01-master 192.168.10.1 db01-slave 192.168.10.2 db01-slave 192.168.10.3 32 MHA db01-slave
- 33. MHA(マスタサーバ障害) DB Master MHA 監視 db01-master DB Master WebApp DB Slave db01-slave Name IP db01-master 192.168.10.2 db01-slave 192.168.10.2 db01-slave 192.168.10.3 33 MHA
- 35. f4samuraiの今後 • 新規タイトルを2本開発中 • 1本はアニメ原作のIPタイトル • 1本は3Dグラフィクスを使ったオリジナルタイトル • 今まで以上のテクニカルスキルが必要なので、 引き続きチャレンジャーとして頑張ります 35
- 36. ありがとうございました