サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
•
263 likes•103,034 views
2014/2/8に行ったゲームサーバ勉強会でのスライドです。 サーバー未経験者がソーシャルゲームを通して知ったサーバーの事。 失敗経験を元に何故今がこうなっているかというのを詰め込みました。 初心者〜中級者向け勉強会だったので、なるべく非エンジニアでもイメージで伝わるようにちょっとだけ心がけてます。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
Similar to サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
Similar to サーバー未経験者がソーシャルゲームを通して知ったサーバーの事 (20)
Recently uploaded
Recently uploaded (7)
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
- 2. 自己紹介 古閑 学/@_mamehiko_ 株式会社gumi 東京オフィス エンジニア 2013/12で3年目。 肩書きは（名ばかり）スペシャリスト 最近はcocos2d-xでクライアントエンジニア 以前はコンシューマーでプログラマを８年程 2児の娘のパパ 会社外で話すのは初めて 自己紹介
- 3. gumiって？ 自己紹介
- 10. 初めてのソーシャルゲーム
- 17. データの選定
- 21. うまくいった
- 22. ようにみえたが。。。
- 23. 例えばこんなコード 2011∼ # この中はトランザクション内という仮定 try: # プレイヤーの体⼒力力を消費 player.consume_̲vitality() # プレイヤーの経験値アップ player.add_̲experience() except: # エラー起きたらDBをロールバック transaction.rollback() else: # 問題なければDB更更新。経験値が増える。 transaction.commit() 体力→KVS 経験値→DB ※実際のコードとは異なります
- 24. 例えばこんなコード 2011∼ # この中はトランザクション内という仮定 try: # プレイヤーの体⼒力力を消費 player.consume_̲vitality() # プレイヤーの経験値アップ player.add_̲experience() except: ←ここでエラー # エラー起きたらDBをロールバック transaction.rollback() else: # 問題なければDB更更新。経験値が増える。 transaction.commit() 体力→KVS 経験値→DB
- 25. どうなるか
- 26. どうなる？ # この中はトランザクション内という仮定 try: # プレイヤーの体⼒力力を消費 player.consume_̲vitality() # プレイヤーの経験値アップ player.add_̲experience() except: # エラー起きたらDBをロールバック transaction.rollback() else: # 問題なければDB更更新。経験値が増える。 transaction.commit() 2011∼ 体力は消費される 経験値付与でエラーが起きる
- 27. どうなる？ # この中はトランザクション内という仮定 try: # プレイヤーの体⼒力力を消費 player.consume_̲vitality() 2011∼ 体力は消費される 経験値付与でエラーが起きる # プレイヤーの経験値アップ player.add_̲experience() except: # エラー起きたらDBをロールバック transaction.rollback() else: # 問題なければDB更更新。経験値が増える。 transaction.commit() 体力だけが消費される ユーザーの不利益となる
- 30. 回避策
- 31. 順番を変える 2011∼ # この中はトランザクション内という仮定 try: # プレイヤーの体⼒力力を消費 # player.consume_̲vitality() # プレイヤーの経験値アップ player.add_̲experience() except: # エラー起きたらDBをロールバック transaction.rollback() else: # 問題なければDB更更新。経験値が増える。 transaction.commit() # プレイヤーの体⼒力力を最後に消費 player.consume_̲vitality() DB更新後に移動
- 36. さらにクエリを減らす
- 41. 回避策
- 42. 更新箇所ではDBから取得 # プレイヤーデータをDBから取得 2011∼ player = player.objects.get(player_̲id=”111”)
- 43. 更新箇所ではDBから取得 2011∼ # プレイヤーデータをDBから取得 player = player.objects.get(player_̲id=”111”) DBで不整合を起こす率は減った ただ、キャッシュから取得している所では タイミング次第で表示ずれが起きる
- 47. ユーザーが順調に増えてきた
- 53. 問題はRDS
- 56. どれくらいかがわからない。。
- 57. 負荷対策を考える 2012∼ スケールアップ サーバーそのものを増強。CPUとかメモリとか。 増強する性能に限界がある スケールアウト 採用 サーバーの台数を増やす事で処理性能をあげる 規模不明だし
- 60. スケールアウト(水平) 2012∼ マスターデータ ギルド プレイヤー１ プレイヤー２ プレイヤー３ プレイヤー４ イベント
- 62. シャードの決定 2012∼ # プレイヤーIDはユニークである事が前提 player_̲id = “hamspamegg” # 適当なハッシュ関数などで数値にし、シャードの分割数で余りを求める # 16 = playerのDBの総シャード数 # 0〜～15の値が取得出来る player_̲db_̲number = _̲hash(player_̲id) % 16 ※実際のコードとは異なります
- 63. うまくいった
- 64. ようにみえたが。。。
- 66. 原因 2012 ある処理だけ分割が効いていなかった 初期化に入れていた空文字が 特定のシャードを指していた # プレイヤーIDはユニークである事が前提 player_̲id = “” if 何かの条件: player_̲id = getHoge() else: # 偽の処理理.... player_̲idが””のまま ... player_̲db_̲number = _̲hash(player_̲id) % 16
- 71. 引き続き分割（おまけ）
- 72. ユーザー数の減少。。 2012∼
- 77. 逆を言えば
- 81. ここまでが主なトライアル＆エラー
- 83. 集大成
- 88. 改善
- 91. マスターデータ マスタデータ Appサーバー マスターデータ ③ ロードバランサ ① ② memcached ① Appサーバーのメモリにアクセス ② キャッシュにアクセス ③ DBにアクセス
- 92. というのが2012まで
- 98. というわけで
- 101. 今まで通りにやると。。。
- 104. さらに、ギルドバトルだと
- 106. 見るからにきつい
- 108. 対応策
- 112. マッチング バトル ギルド # マッチングIDの発⾏行行 matching_̲id = uuid4() バッチサーバー プレイヤー 対戦の組み合わせごとに マッチングID(UUID)を発行する
- 115. うまくいった
- 116. が
- 118. レースコンディション mame バトル hiko 体力100 体力100 mameとhikoのデータを取得 mameとhikoのデータを取得 hikoに攻撃 mameに攻撃 save() save()
- 122. 対応策
- 128. うまくいった
- 129. 本当に！
- 130. これで全てが終わったかに見えた
- 134. 改善 マッチング ギルド # ギルドIDの対戦リスト guild_̲ids = ([1, 2],[3,4],[5,6]) バッチサーバー Redis プレイヤー Redisに 対戦ギルドの組み合わせのIDのみのリスト を入れる
- 138. マッチング時間が5分の１に 俺が泣いた
- 145. ご清聴ありがとうございました