Submit Search
Upload
分割と整合性と戦う
•
80 likes
•
29,203 views
Yugo Shimizu
Follow
第二回ゲームサーバ勉強会での発表資料
Read less
Read more
Software
Report
Share
Report
Share
1 of 102
Download now
Download to read offline
Recommended
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
脱RESTful API設計の提案
脱RESTful API設計の提案
樽八 仲川
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
takezoe
MQTTとAMQPと.NET
MQTTとAMQPと.NET
terurou
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
NTT DATA Technology & Innovation
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
Masatoshi Tada
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
NTT DATA Technology & Innovation
Recommended
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
脱RESTful API設計の提案
脱RESTful API設計の提案
樽八 仲川
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
takezoe
MQTTとAMQPと.NET
MQTTとAMQPと.NET
terurou
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
その Pod 突然落ちても大丈夫ですか!?(OCHaCafe5 #5 実験!カオスエンジニアリング 発表資料)
NTT DATA Technology & Innovation
Java ORマッパー選定のポイント #jsug
Java ORマッパー選定のポイント #jsug
Masatoshi Tada
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
NTT DATA Technology & Innovation
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
onozaty
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
NTT DATA Technology & Innovation
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
infinite_loop
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
Hironobu Isoda
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
今こそ知りたいSpring Web(Spring Fest 2020講演資料)
今こそ知りたいSpring Web(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
とにかく分かりづらいTwelve-Factor Appの解説を試みる
とにかく分かりづらいTwelve-Factor Appの解説を試みる
Masatoshi Tada
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
sairoutine
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
オンラインゲームの仕組みと工夫
オンラインゲームの仕組みと工夫
Yuta Imai
30分でわかるマイクロサービスアーキテクチャ 第2版
30分でわかるマイクロサービスアーキテクチャ 第2版
Naoki (Neo) SATO
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
Satoshi Yamafuji
Imprementation of realtime_networkgame
Imprementation of realtime_networkgame
Satoshi Yamafuji
More Related Content
What's hot
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
onozaty
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
NTT DATA Technology & Innovation
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
infinite_loop
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
Hironobu Isoda
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
今こそ知りたいSpring Web(Spring Fest 2020講演資料)
今こそ知りたいSpring Web(Spring Fest 2020講演資料)
NTT DATA Technology & Innovation
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
とにかく分かりづらいTwelve-Factor Appの解説を試みる
とにかく分かりづらいTwelve-Factor Appの解説を試みる
Masatoshi Tada
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
sairoutine
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
オンラインゲームの仕組みと工夫
オンラインゲームの仕組みと工夫
Yuta Imai
30分でわかるマイクロサービスアーキテクチャ 第2版
30分でわかるマイクロサービスアーキテクチャ 第2版
Naoki (Neo) SATO
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
What's hot
(20)
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
LogbackからLog4j 2への移行によるアプリケーションのスループット改善 ( JJUG CCC 2021 Fall )
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
今こそ知りたいSpring Web(Spring Fest 2020講演資料)
今こそ知りたいSpring Web(Spring Fest 2020講演資料)
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
とにかく分かりづらいTwelve-Factor Appの解説を試みる
とにかく分かりづらいTwelve-Factor Appの解説を試みる
イベント・ソーシングを知る
イベント・ソーシングを知る
Docker Compose 徹底解説
Docker Compose 徹底解説
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
分散システムについて語らせてくれ
分散システムについて語らせてくれ
オンラインゲームの仕組みと工夫
オンラインゲームの仕組みと工夫
30分でわかるマイクロサービスアーキテクチャ 第2版
30分でわかるマイクロサービスアーキテクチャ 第2版
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
Viewers also liked
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
Satoshi Yamafuji
Imprementation of realtime_networkgame
Imprementation of realtime_networkgame
Satoshi Yamafuji
負荷がたかいいんだから~♪(仮)
負荷がたかいいんだから~♪(仮)
Yohei Hamada
サーバーのおしごと
サーバーのおしごと
Yugo Shimizu
Fluentd and Embulk Game Server 4
Fluentd and Embulk Game Server 4
N Masahiro
Halo2 におけるHFSM(階層型有限状態マシン) 【ビヘイビアツリー解説】
Halo2 におけるHFSM(階層型有限状態マシン) 【ビヘイビアツリー解説】
Youichiro Miyake
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
Yugo Shimizu
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
johgus johgus
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
Toru Takahashi
自宅で出来る!ゲームサーバの作り方
自宅で出来る!ゲームサーバの作り方
光晶 上原
ゲームサーバ開発現場の考え方
ゲームサーバ開発現場の考え方
Daisaku Mochizuki
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
Manabu Koga
Viewers also liked
(12)
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
Imprementation of realtime_networkgame
Imprementation of realtime_networkgame
負荷がたかいいんだから~♪(仮)
負荷がたかいいんだから~♪(仮)
サーバーのおしごと
サーバーのおしごと
Fluentd and Embulk Game Server 4
Fluentd and Embulk Game Server 4
Halo2 におけるHFSM(階層型有限状態マシン) 【ビヘイビアツリー解説】
Halo2 におけるHFSM(階層型有限状態マシン) 【ビヘイビアツリー解説】
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
リアルタイムサーバー 〜Erlang/OTPで作るPubSubサーバー〜
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
負荷対策しておもったことまとめ~JMeterでSocket.IOもいけるでよ~
EmbulkとDigdagとデータ分析基盤と
EmbulkとDigdagとデータ分析基盤と
自宅で出来る!ゲームサーバの作り方
自宅で出来る!ゲームサーバの作り方
ゲームサーバ開発現場の考え方
ゲームサーバ開発現場の考え方
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
Similar to 分割と整合性と戦う
Lv1から始めるWebサービスのインフラ構築
Lv1から始めるWebサービスのインフラ構築
伊藤 祐策
Java/Androidセキュアコーディング
Java/Androidセキュアコーディング
Masaki Kubo
Inside mobage platform
Inside mobage platform
Toru Yamaguchi
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
infinite_loop
S2dao Seminar in tripodworks
S2dao Seminar in tripodworks
tripodworks
MongoDB Configパラメータ解説
MongoDB Configパラメータ解説
Shoken Fujisaki
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
Insight Technology, Inc.
Asakusa Enterprise Batch Processing Framework for Hadoop
Asakusa Enterprise Batch Processing Framework for Hadoop
Takashi Kambayashi
DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】
DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】
DeNA
My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1
Makoto Haruyama
Groovyで楽にSQLを実行してみよう
Groovyで楽にSQLを実行してみよう
Akira Shimosako
ソーシャルゲームの為のデータベース設計
ソーシャルゲームの為のデータベース設計
kaminashi
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Atsushi Kambara
Edge os(vyos)の基本(入門編)
Edge os(vyos)の基本(入門編)
Akira Kaneda
コンテナ時代にインフラエンジニアは何をするのか
コンテナ時代にインフラエンジニアは何をするのか
gree_tech
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
じゅん なかざ
Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02
hideki hasegawa
最速C# 7.x
最速C# 7.x
Yamamoto Reki
Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?
NTT DATA OSS Professional Services
IDAの脆弱性とBug Bounty by 千田 雅明
IDAの脆弱性とBug Bounty by 千田 雅明
CODE BLUE
Similar to 分割と整合性と戦う
(20)
Lv1から始めるWebサービスのインフラ構築
Lv1から始めるWebサービスのインフラ構築
Java/Androidセキュアコーディング
Java/Androidセキュアコーディング
Inside mobage platform
Inside mobage platform
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
大規模ソーシャルゲーム開発から学んだPHP&MySQL実践テクニック
S2dao Seminar in tripodworks
S2dao Seminar in tripodworks
MongoDB Configパラメータ解説
MongoDB Configパラメータ解説
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
[D33] そのデータベース 5年後大丈夫ですか by Hiromu Goto
Asakusa Enterprise Batch Processing Framework for Hadoop
Asakusa Enterprise Batch Processing Framework for Hadoop
DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】
DeClang 誕生!Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】
My sql casual_in_fukuoka_vol1
My sql casual_in_fukuoka_vol1
Groovyで楽にSQLを実行してみよう
Groovyで楽にSQLを実行してみよう
ソーシャルゲームの為のデータベース設計
ソーシャルゲームの為のデータベース設計
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Edge os(vyos)の基本(入門編)
Edge os(vyos)の基本(入門編)
コンテナ時代にインフラエンジニアは何をするのか
コンテナ時代にインフラエンジニアは何をするのか
既存システムへの新技術活用法 ~fluntd/MongoDB~
既存システムへの新技術活用法 ~fluntd/MongoDB~
Databasedesignforsocialgames 110115195940-phpapp02
Databasedesignforsocialgames 110115195940-phpapp02
最速C# 7.x
最速C# 7.x
Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?
IDAの脆弱性とBug Bounty by 千田 雅明
IDAの脆弱性とBug Bounty by 千田 雅明
分割と整合性と戦う
1.
分割と整合性をがんばる話 ソーシャルゲームの整合性対策
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に移すだけの簡単なお仕事 1機能に負荷が集中すると対処不能 KVSにもじゃんじゃん逃す
12.
機能をまたがる処理 Friend フレンドが増えたので
Player ポイントUP Friend ++ Point +10 save フレンドが増えたのに save rollback ポイントが増えないい… 失敗!
13.
同時に使う機能は分割できない 負荷の多いPlayer/Card/Quest/Itemの分割が難しい たとえ分割しても負荷は変わらないことも
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.
消えるカード
22.
ユーザー「合成したらカードが消えたんですが!
23.
プレイヤーをまたがる処理 Shard1 ID:1
PlayerA Shard2 - ID:1 PlayerC
24.
プレイヤーをまたがる処理 Shard1 ID:1
PlayerA Shard2 ID:1 P la y e r C - 上書き!
25.
分割キーを消してはいけない
26.
機能をまたぐ場合の問題も 残ったまま
27.
ただし負荷は下がった 高負荷状態にならないのでエラーも少ない ログだけ丁寧に仕込んで個別ケース対応
KVSに大事なデータを置かない ゲームに致命的にならない範囲でエラー時はユーザー が得になる方に倒す バグは直す
28.
そして新プロジェクトへ
29.
アジェンダ 2012年前期 負荷対策
2012年中期 トランザクション 2012年後期 デッドロック
30.
不整合と戦う
31.
偉い人「100万人きても大丈夫なようにしといて!」
32.
1から抜本的に見直し 負荷は水平分割で対処する 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だけ更新というパターンは0 ほとんどの場合お金かアイテムかカードが一緒に増える 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()
62.
入れ子のトランザクションを扱えない トランザクションに何を含めるかはモデルにはわか らない
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使用率が張り 付いていた
72.
即JetProfilerを起動 ç
73.
テキスト クリック一つて即Eplain グラフィカル&レーティングしてくれる。
DBにくわしくなくてもいかにもダメそうな感じ
74.
インデックスがなかった 特定クエリが処理時間の9割以上を占めていた 緊急メンテに入りインデックスを追加
インデックスをはったら5%以下に
75.
ほとんど同じ状況で 別パターン
76.
無駄インデックス問題 特定クエリが処理時間の3割以上を占めていた スローではないが一クエリ当たりの時間が多い
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.
ロック状態
92.
何が起きていたか デッドロックによってロック待ちとタイムアウトが 発生
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.
質疑応答
Download now