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.

分割と整合性と戦う

24,109 views

Published on

第二回ゲームサーバ勉強会での発表資料

Published in: Software
  • Be the first to comment

分割と整合性と戦う

  1. 1. 分割と整合性をがんばる話 ソーシャルゲームの整合性対策
  2. 2. 自己紹介 清水 佑吾 @yamionp 株式会社 gumi 勤務 Python歴約2年半 サーバーさわりはじめて約10年 前職はISP
  3. 3. 水平分割がやりたくて転職
  4. 4. 関わったもの HTML + FlashLite Cocos2d-x
  5. 5. 使用環境 Python 2.7 Django MySQL 5.5/5.6 (RDS) Redis RabbitMQ
  6. 6. アジェンダ 2012年前期 負荷対策 2012年中期 トランザクション 2012年後期 デッドロック
  7. 7. 負荷対策期
  8. 8. サービスがヒット 更新処理が限界に 当時最強のインスタンスを用意 もう大丈夫! ・・・が、ダメっっ!
  9. 9. というわけで
  10. 10. Player RDB Master Trade Guild Friend KVS Memcache TokyoTryant
  11. 11. 垂直分割 機能単位で格納先DBを変える 性能問題に突き当たる度に分割対象を選定 外部キーを外して別DBに移すだけの簡単なお仕事 1機能に負荷が集中すると対処不能 KVSにもじゃんじゃん逃す
  12. 12. 機能をまたがる処理 Friend フレンドが増えたので Player ポイントUP Friend ++ Point +10 save フレンドが増えたのに save rollback ポイントが増えないい… 失敗!
  13. 13. 同時に使う機能は分割できない 負荷の多いPlayer/Card/Quest/Itemの分割が難しい たとえ分割しても負荷は変わらないことも
  14. 14. そこで
  15. 15. Player RDB Master Guild Trade Friend KVS Memcache Redis カード等のCache 体力等
  16. 16. 性能問題には一定の解決をみた
  17. 17. が…
  18. 18. 多発する不整合 消えた更新 なぜか消えるカード なぜか増えるカード
  19. 19. 増えるカード
  20. 20. プレイヤーをまたがる処理 Player A Player B Trade Card Delete Card Add save save 失敗! rollback こちらは残ったまま
  21. 21. 消えるカード
  22. 22. ユーザー「合成したらカードが消えたんですが!
  23. 23. プレイヤーをまたがる処理 Shard1 ID:1 PlayerA Shard2 - ID:1 PlayerC
  24. 24. プレイヤーをまたがる処理 Shard1 ID:1 PlayerA Shard2 ID:1 P la y e r C - 上書き!
  25. 25. 分割キーを消してはいけない
  26. 26. 機能をまたぐ場合の問題も 残ったまま
  27. 27. ただし負荷は下がった 高負荷状態にならないのでエラーも少ない ログだけ丁寧に仕込んで個別ケース対応 KVSに大事なデータを置かない ゲームに致命的にならない範囲でエラー時はユーザー が得になる方に倒す バグは直す
  28. 28. そして新プロジェクトへ
  29. 29. アジェンダ 2012年前期 負荷対策 2012年中期 トランザクション 2012年後期 デッドロック
  30. 30. 不整合と戦う
  31. 31. 偉い人「100万人きても大丈夫なようにしといて!」
  32. 32. 1から抜本的に見直し 負荷は水平分割で対処する XA Transactionによる一貫性担保 ロックによる排他制御
  33. 33. 水平分割を前提とした構成
  34. 34. 全部DBにいれる Guild RDB Player
  35. 35. マスターデータはjson化 変更がないのでデプロイ時にAppサーバーに配布 メモリ上に展開するので非常に高速 ますますキャッシュレスに
  36. 36. DBのみで実装する プレイヤーに紐づくデータはすべてDBに 自動回復系ステータス(体力、BPなど)もDB トランザクションに収められる! 正規化を徹底
  37. 37. 自動回復系ステータス
  38. 38. RDB いままではKVSに格納 Master Guild Player Trade Friend KVS Memcache Redis
  39. 39. よくおきる不整合 お金追加 体力減算 失敗! begin commit rollback
  40. 40. 自動回復系ステータス
  41. 41. 今まではKVSに格納していた DBだけ更新、KVSだけ更新がおきていた ユーザーに得になる場合は裏技として2chで祭り ユーザーの損になる場合はCSが爆発する KVSだけ更新というパターンは0 ほとんどの場合お金かアイテムかカードが一緒に増える KVSに居るメリットが実は無い
  42. 42. 実装 現在値、最大値、最終更新時刻を持つ 最終更新時間と現在値から自動回復済の値を計算し て使う 減算時のみUPDATE
  43. 43. 正規化
  44. 44. 正規化 意味の重複する値を保存しない レベルの値は無く、合計経験値のみ保存 参照時に経験値からレベルを計算 レベルからパラメータを計算。
  45. 45. Before id int card_id int hp int attack int defense int magic_attack int magic_defense int exp int level int
  46. 46. After id int 驚きのダイエット card_id int 効果! exp int
  47. 47. XAトランザクション
  48. 48. 普通のトランザクション begin; SELECT…; INSERT INTO…; commit; 反映
  49. 49. XAトランザクション DB1 DB2 xa begin SELECT…; INSERT INTO…; xa end 反映 xa prepare xa commit xa begin SELECT…; INSERT INTO…; xa end xa prepare xa commit commit 成功を保証
  50. 50. prepare prepare prepare prepare prepare prepare App
  51. 51. commit commit commit prepare prepare prepare App commit commit commit
  52. 52. もし途中でエラーになったら
  53. 53. prepare prepare prepare prepare App prepare 失敗! rollback
  54. 54. rollback rollback rollback prepare App prepare rollback
  55. 55. 無事に処理前の状態に!
  56. 56. 複数のDBを跨ったtrxが可能 XAに参加するいずれかの段階でエラーが起これば ロールバックが可能 複数DBの状態が 処理成功 or 処理なし のいずれかの みを保証できるようになった 中途半端な状態がなくなる 体力のみ減る、カードだけ増えるなどがなくなる
  57. 57. が、 DjangoはXA Transactionに非対応 水平分割にも非対応 自社開発!
  58. 58. これらを簡単に使うために エラーハンドリングを毎回書くのは無駄 スキル的にもきびしい トランザクションに何を含めるかだけ書けるように
  59. 59. エンジニアが書くべきこと トランザクションに何を含めるか 範囲はモデルの機能ではなくリクエストごとに決 まる 最適なロック順番は個別の処理ごとに異なる ロック・トランザクションを要求する
  60. 60. # player1とplayer2のDBにトランザクション開始 with commit_on_success([player1_id, player2_id]): # ロック付きで取得 player1 = Player.get_for_update(player1_id) player2 = Player.get_for_update(player2_id) # 減算を実行 player1.decrement_ap(5) player1.increment_money(10) player2.decrement_money(10)
  61. 61. def increment_ap(self, quantity): # 自身がロック済みであることを要求 self.require_for_update() # 減算 self.ap -= quantity # UPDATE self.save()
  62. 62. 入れ子のトランザクションを扱えない トランザクションに何を含めるかはモデルにはわか らない
  63. 63. ちなみに
  64. 64. commit途中で死んだら?
  65. 65. commit commit commit prepare prepare prepare App commit 突然の死!! commit
  66. 66. commit commit commit XA Recover pcorempmariet cron
  67. 67. 処理を完遂!
  68. 68. というのが理想 innodbのxaは切断時にpreparedだと勝手にrollbackし てしまう 2005年ぐらいから指摘されていて、patchも送られた が、patchの取り込みに失敗 どうしようもない
  69. 69. ログベースの個別対応orz
  70. 70. ある日の夜 イベントリリース! しばらくは問題なく動作していたが… ページが開けない!と苦情が
  71. 71. CloudWatch AppサーバーCPU使用 率もリクエスト数も問 題ないが... DBのCPU使用率が張り 付いていた
  72. 72. 即JetProfilerを起動 ç
  73. 73. テキスト クリック一つて即Eplain グラフィカル&レーティングしてくれる。 DBにくわしくなくてもいかにもダメそうな感じ
  74. 74. インデックスがなかった 特定クエリが処理時間の9割以上を占めていた 緊急メンテに入りインデックスを追加 インデックスをはったら5%以下に
  75. 75. ほとんど同じ状況で 別パターン
  76. 76. 無駄インデックス問題 特定クエリが処理時間の3割以上を占めていた スローではないが一クエリ当たりの時間が多い Explainしたら index merge インデックスを削除したら100倍高速化
  77. 77. アジェンダ 2012年前期 負荷対策 2012年中期 トランザクション 2012年後期 デッドロック
  78. 78. 排他制御 ロック CAS
  79. 79. CASの話はしません
  80. 80. ロック innodbはレコードロックが可能 ロックの実現にはインデックスが使われる 存在するインデックスより狭い範囲のロックはでき ない
  81. 81. ロック範囲 PrimaryKey Index ID player_id value 1 401 A 2 401 B 3 402 B 4 403 C
  82. 82. SELECT * FROM player WHERE player_id = 401 FOR UPDATE
  83. 83. ロック範囲 PrimaryKey Index ID player_id value 1 401 A ロック範囲 2 401 B 3 402 B 4 403 C
  84. 84. SELECT * FROM player WHERE value = “B” FOR UPDATE
  85. 85. ロック範囲 PrimaryKey Index ID player_id value 1 401 A 2 401 B 期実待際すのるロロッックク範範囲囲 3 402 B 4 403 C
  86. 86. 実際のロック範囲はオプティマイザーの気分次第 必要なインデックスが無いと不必要に大きな範囲の ロックをとってしまう インデックスが無駄にあると意図しないインデック スを使われてロックをとられてしまう
  87. 87. 何が起きるか
  88. 88. ある日 ゲームが重い 画面が開けない レイドボスを攻撃したのに重くて叩けなかった イベントが動かない!
  89. 89. 生涯発生中に自分がプレイしても得に問題なかった だがエラー報告が大量発生 サーバー負荷は大したことなかった CPU/RAM/Disk/Networkすべて低レベル ロードバランサーのレスポンスタイムがどんどん劣化
  90. 90. JetProfiler
  91. 91. ロック状態
  92. 92. 何が起きていたか デッドロックによってロック待ちとタイムアウトが 発生
  93. 93. ロック ID player_id value 1 401 A 2 401 B 3 402 B 4 403 C App 1 2
  94. 94. デッドロック ID player_id value 1 401 A 2 401 B 3 402 B 4 403 C App 1 デッドロック App 2
  95. 95. MySQLさんは親切 同じDB内のデッドロックは検知して解除してくれる 分割しているとMySQLは検知できない XAでトランザクションをまとめているので複数DBに またがって止まる
  96. 96. 回避するには ロック順番を統一する ロックする前にソート(id, Player_id,) DBをソート テーブルをソート レコードをソート 大きくロックを取る player単位、レイドボス単位
  97. 97. 参照処理に更新を混ぜない
  98. 98. 負荷も跳ね上がる。更新にはほとんどの場合ロック が必要 参照がロックをとる ロック機会の圧倒的増大 デッドロック祭り 止まってしまうサービス まってくれない終電
  99. 99. MySQL「XAはSERIALIZABLE」 どのみち更新に必要なデータはFOR UPDATEで取得 する必要がある じつはいらなくね・・・? REPEATABLE READにしたら速度もあがって問題なく なりました
  100. 100. まとめ 単にKVSに移すのは問題の先延ばしにしかならない きちんと使えばRDBだけで十分さばける マスターオンリー障害対策用のSlaveはいるがクエリは裁かない デッドロック対策の前に適切なインデックスを インデックスショットガン。だめ、絶対。 NewRelicとJetProfilerは神超オススメです
  101. 101. ご清聴ありがとうございました
  102. 102. 質疑応答

×