Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to ゲームサーバ開発現場の考え方
Similar to ゲームサーバ開発現場の考え方 (20)
ゲームサーバ開発現場の考え方
- 5. プロジェクト開始
- 11. 通信システム リアルタイム通信が不要であればHTTP 送受信（POST）するデータ形式は？ XML, JSON, MessagePack, Google Protocol Buffers, 独自シリアライズ 通信の頻度とデータ量、デシリアライズ処理の重 さ、開発＆デバッグのやりやすさなどから検討（慣 れないうちはJSONオススメ） 11
- 12. 想定負荷 例）DAU(Daily Active Users) 10万 10万 x 20 Login/日= 200万 Login/日 = 23 Login/秒 3倍して 23 x 3 ≒ 70 Login/秒 これが日々のピーク Webサーバ1台で12程度さばけると仮定すると、Webサーバ6台 となる。（この時点はざっくり） 基本的にログインが最も重い（多くのデータを読み込み、送信 する必要がある）ので、まずはログインの負荷を目安に考える。 12
- 13. システム構成案 Web サーバ6台 DB(Master)1台、DB(Slave)2台 KVS 1台 Webサーバからのコネクション数は、DB(Master):30, DB(Slave):50, KVS:100とする 要求を満たす最もシンプルな構成を心がける 無駄に複雑な構成にして失敗するケースは多い 13
- 16. 基盤開発 16
- 18. 通信処理基盤 MVC形式 or チャンク形式 MVC形式：1つの通信に1つの機能 チャンク形式：1つの通信に複数の機能 どちらもメリット・デメリット存在す る。（個人的にはチャンク形式を採用） 18
- 24. ソースコード自動生成ツー ル 定型文的なソースは、極力ソースコードを生成するツールを自作し たい 特にサーバ・クライアント間で共有するソース（通信のクラス、 define、enum、マスターデータ） 自動生成の元データ形式は例えば以下 通信のクラス：JSON define, enum：Excel or CSV マスターデータ（後述）：Excel 24
- 25. ソースコード自動生成ツー ル “login” : { “request” : { “id” : “string”, “password” : “string” }, “response” : { “result” : “int” } } 通信データ定義JSON public class LoginRequest { public String id; public String password; } public class LoginResponse { public int result; } public class LoginProcess { private LoginRequest request; private LoginResponse response; public void exec() { // サーバのログイン処理を記述 } } 出力ソースコード 25
- 26. ソースコード自動生成ツー ル MONEY_MAX int 999999 MONEY string Gem SWORD enum(WeaponType) 1 GUN enum(WeaponType) 2 ROD enum(WeaponType) 3 define, enum定義CSV public class Definition { public static final int MONEY_MAX = 999999; public static final String MONEY = “Gem”; } public enum WeaponType { SWORD = 1, GUN = 2, ROD = 3, } 出力ソースコード 26
- 28. マスターデータ用ツール id name attack 1 スライム 3 2 ゴブリン 15 3 ドラゴン 750 モンスター定義Excel “Monster” : {[ {“id” : 1, “name” : ”スライム”, “attack” : 3}, {“id” : 2, “name” : ”ゴブリン”, “attack” : 15}, {“id” : 3, “name” : ”ドラゴン”, “attack” : 750}, ]} モンスターデータJSON public class MonsterData { public final int id; public final string name; public final int attack; } モンスターデータ ソースコード 28
- 31. 機能実装 31
- 34. サーバ・クライアント 同一人物開発 注意点 サーバ技術者 = クライアント開発 リソース（画像、音声など）管理に注意。省メモリを意識し、使い 終わったら解放する。 画面を常に動かす。固まらせない。 クライアント技術者 = サーバ開発 DBの勉強期間は十分に取る。最初は触らせないぐらいでも良い。 危険なコード（デッドロック、無限ループ）に注意する。 34
- 35. 実装時の注意点
- 42. 本番サーバ選定 各ミドルウェアで必要なパラメータを決める catalina.sh Javaヒープサイズ 8GB server.xml 最大スレッド数 2000 Webサーバ （Tomcat） DB接続数 Master : 30 Slave : 50 KVS接続数 100 max_connections 300 innodb_buffer_pool_size 8GB context.xml DBサーバ （MySQL） my.cnf 事前に決めておかないと、後でメモリ使用量などの計算 が合わなくなる 42
- 45. サービスイン後 サーバの負荷状況を監視（同時接続数、DAUと合わせて）し、 しきい値を越える or 異常検知でアラートメール 監視ツール：hobbit, Zabbix, Xymon 障害発生時、サーバによって放置度合いが異なる。 一定期間放置可能：冗長化されたWebサーバ 早めに復旧させたい：管理用サーバ、バックアップサーバ 即時対応必須：DBサーバ 45