Enviar búsqueda
Cargar
分割と整合性と戦う
•
80 recomendaciones
•
29,203 vistas
Yugo Shimizu
Seguir
第二回ゲームサーバ勉強会での発表資料
Leer menos
Leer más
Software
Denunciar
Compartir
Denunciar
Compartir
1 de 102
Descargar ahora
Descargar para leer sin conexión
Recomendados
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
naoki koyama
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
takezoe
大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~
大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~
infinite_loop
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Spannerに関する技術メモ
Spannerに関する技術メモ
Etsuji Nakai
トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめ
pospome
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
Recomendados
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
新たなgitのブランチモデル「Git Feature Flow」!Git Flow,Git Hub Flow,Git Lab Flowを超えれるか?
naoki koyama
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
takezoe
大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~
大規模ソーシャルゲームを支える技術~PHP+MySQLを使った高負荷対策~
infinite_loop
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Spannerに関する技術メモ
Spannerに関する技術メモ
Etsuji Nakai
トランザクションスクリプトのすすめ
トランザクションスクリプトのすすめ
pospome
ネットワーク ゲームにおけるTCPとUDPの使い分け
ネットワーク ゲームにおけるTCPとUDPの使い分け
モノビット エンジン
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
例外設計における大罪
例外設計における大罪
Takuto Wada
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
Ryuji Tsutsui
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
webエンジニアのためのはじめてのredis
webエンジニアのためのはじめてのredis
nasa9084
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
C#とILとネイティブと
C#とILとネイティブと
信之 岩永
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
NTT DATA Technology & Innovation
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
Satoshi Yamafuji
Imprementation of realtime_networkgame
Imprementation of realtime_networkgame
Satoshi Yamafuji
Más contenido relacionado
La actualidad más candente
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
NTT DATA Technology & Innovation
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
例外設計における大罪
例外設計における大罪
Takuto Wada
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
Ryuji Tsutsui
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
zaki4649
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
webエンジニアのためのはじめてのredis
webエンジニアのためのはじめてのredis
nasa9084
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
C#とILとネイティブと
C#とILとネイティブと
信之 岩永
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
NTT DATA Technology & Innovation
La actualidad más candente
(20)
Twitterのsnowflakeについて
Twitterのsnowflakeについて
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Redisの特徴と活用方法について
Redisの特徴と活用方法について
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
例外設計における大罪
例外設計における大罪
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
DockerとPodmanの比較
DockerとPodmanの比較
とある診断員とSQLインジェクション
とある診断員とSQLインジェクション
テストコードの DRY と DAMP
テストコードの DRY と DAMP
webエンジニアのためのはじめてのredis
webエンジニアのためのはじめてのredis
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Docker Compose 徹底解説
Docker Compose 徹底解説
C#とILとネイティブと
C#とILとネイティブと
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
Destacado
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
Destacado
(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 a 分割と整合性と戦う
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~
じゅん なかざ
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
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
Similar a 分割と整合性と戦う
(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系になって何が変わるのか?
分割と整合性と戦う
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.
質疑応答
Descargar ahora