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