Soumettre la recherche
Mettre en ligne
分割と整合性と戦う
•
80 j'aime
•
29,203 vues
Yugo Shimizu
Suivre
第二回ゲームサーバ勉強会での発表資料
Lire moins
Lire la suite
Logiciels
Affichage du diaporama
Signaler
Partager
Affichage du diaporama
Signaler
Partager
1 sur 102
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
Cloud runのオートスケールを検証してみる
Cloud runのオートスケールを検証してみる
虎の穴 開発室
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
DeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
DeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
Makoto Haruyama
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)
ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)
Amazon Web Services Japan
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
ゲーム開発を知らない人にも分かるKLabのゲーム開発運営
ゲーム開発を知らない人にも分かるKLabのゲーム開発運営
KLab Inc. / Tech
Recommandé
Cloud runのオートスケールを検証してみる
Cloud runのオートスケールを検証してみる
虎の穴 開発室
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
DeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
DeNAオリジナル ゲーム専用プラットフォーム Sakashoについて
Makoto Haruyama
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)
ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)
Amazon Web Services Japan
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
ゲーム開発を知らない人にも分かるKLabのゲーム開発運営
ゲーム開発を知らない人にも分かるKLabのゲーム開発運営
KLab Inc. / Tech
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
今さら聞けない人のためのCI/CD超入門
今さら聞けない人のためのCI/CD超入門
VirtualTech Japan Inc./Begi.net Inc.
VPCのアウトバウンド通信を制御するためにおさえておきたい設計ポイント
VPCのアウトバウンド通信を制御するためにおさえておきたい設計ポイント
Takuya Takaseki
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
NTT DATA Technology & Innovation
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon Web Services Japan
SpringBootTest入門
SpringBootTest入門
Yahoo!デベロッパーネットワーク
サーバーのおしごと
サーバーのおしごと
Yugo Shimizu
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
Manabu Koga
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Recruit Lifestyle Co., Ltd.
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座
Samir Hammoudi
MagicOnion入門
MagicOnion入門
torisoup
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
Ryuji Tsutsui
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
Satoshi Yamafuji
Imprementation of realtime_networkgame
Imprementation of realtime_networkgame
Satoshi Yamafuji
Contenu connexe
Tendances
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
今さら聞けない人のためのCI/CD超入門
今さら聞けない人のためのCI/CD超入門
VirtualTech Japan Inc./Begi.net Inc.
VPCのアウトバウンド通信を制御するためにおさえておきたい設計ポイント
VPCのアウトバウンド通信を制御するためにおさえておきたい設計ポイント
Takuya Takaseki
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
NTT DATA Technology & Innovation
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon Web Services Japan
SpringBootTest入門
SpringBootTest入門
Yahoo!デベロッパーネットワーク
サーバーのおしごと
サーバーのおしごと
Yugo Shimizu
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
Manabu Koga
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Recruit Lifestyle Co., Ltd.
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座
Samir Hammoudi
MagicOnion入門
MagicOnion入門
torisoup
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
Ryuji Tsutsui
Tendances
(20)
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
今さら聞けない人のためのCI/CD超入門
今さら聞けない人のためのCI/CD超入門
VPCのアウトバウンド通信を制御するためにおさえておきたい設計ポイント
VPCのアウトバウンド通信を制御するためにおさえておきたい設計ポイント
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
トランザクションの設計と進化
トランザクションの設計と進化
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Amazon S3を中心とするデータ分析のベストプラクティス
Amazon S3を中心とするデータ分析のベストプラクティス
SpringBootTest入門
SpringBootTest入門
サーバーのおしごと
サーバーのおしごと
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
分散システムについて語らせてくれ
分散システムについて語らせてくれ
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
ホットペッパービューティーにおけるモバイルアプリ向けAPIのBFF/Backend分割
Mavenの真実とウソ
Mavenの真実とウソ
超実践 Cloud Spanner 設計講座
超実践 Cloud Spanner 設計講座
MagicOnion入門
MagicOnion入門
Python 3.9からの新定番zoneinfoを使いこなそう
Python 3.9からの新定番zoneinfoを使いこなそう
En vedette
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例
Satoshi Yamafuji
Imprementation of realtime_networkgame
Imprementation of realtime_networkgame
Satoshi Yamafuji
負荷がたかいいんだから~♪(仮)
負荷がたかいいんだから~♪(仮)
Yohei Hamada
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
En vedette
(10)
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とデータ分析基盤と
自宅で出来る!ゲームサーバの作り方
自宅で出来る!ゲームサーバの作り方
ゲームサーバ開発現場の考え方
ゲームサーバ開発現場の考え方
Similaire à 分割と整合性と戦う
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
Similaire à 分割と整合性と戦う
(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.
質疑応答
Télécharger maintenant