Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
More from Hiraku Nakano
Recently uploaded
Recently uploaded (9)
こわくない同時実行制御
- 3. 自己紹介 • @Hiraku (中野 拓) • PHP歴5年+ • 使ったことのあるフレームワーク • Zend Framework1 • Symfony • Yaf • BEAR.Sunday • XMLとJSONの相互変換ライブラリ作ってます • https://github.com/hirak/php-XML_Builder
- 4. 目次 • 同時実行制御とは • 考慮するべき不具合 • 解決手法
- 8. 同時実行制御は応用範囲が広い • 並列プログラミング • DBトランザクション • バージョン管理システム • 逆に、同時実行制御さえ理解しておけば、上記３つのシステム が理解しやすくなる • イモヅル式！
- 9. 教科書 • 先述の3つの分野では必ず同時実行制御が必要になる • どこから勉強しても行き着く • わたしはSQLから攻めました。 いいのがあったら教えてください • http://www.amazon.co.jp/dp/4798128023 • 資格試験の教科書なんかでも登場するかも…？
- 12. 制御しないと問題が起きる • 具体的な問題って何？ • SQLモデルによる定義があります • http://research.microsoft.com/apps/pubs/default.aspx?id=69541 • 5つに分類 • P0 ダーティライト • P1 ダーティーリード • P2 ノンリピータブルリード（ファジーリード） • P3 ファントム • P4 ロストアップデート
- 14. P0 ダーティライト • Tx中に他のTxが書き込め ちゃう状態 • 正しい値が何だったのか わからなくなる Tx1 Tx2 UPDATE x=1 UPDATE x=2 Data x=0 x=1 x=2 rollback x=??
- 15. P1 ダーティリード • Tx中の変更が他のTx から読めちゃう状態 Tx1 Tx2 X=1 y = x + 1 (2) Data X=0, y=0 x=1 y=0 x=1 y=2 rollback x=0 y=?? SELECT x
- 16. P2 ノンリピータブルリード • 他のTxによって データが勝手に 書き換わってい ること Tx1 Tx2 SELECT x x=1 Data x=0 x=0 x=1 SELECT x x=1 x=0 x=1 SELECTに再現性がない
- 17. P3 ファントム • 他のTxの操作によっ て謎のデータが突如 出現すること • ノンリピータブル リードと対 Tx1 Tx2 SELECT x FROM Data INSERT Data (x=0) (x=0) (x=0) (x=1) SELECT x FROM Data (x=0) (x=1) 1件hit 2件hit SELECTに再現性がない
- 18. P4 ロストアップデート • 同時更新のうち、 早かった方の更新 が失われてしまう • インクリメントの 制御など Tx1 Tx2 SELECT x SELECT x Data x=0 x=0 x=1x = x + 1 x=1 手動インクリメントの ロスト x=0 x=0 x = x + 1
- 19. SQLの場合 • トランザクション分離レベルで制御できます 分離レベル P0 ダーティライト P1 ダーティリード P2 アンリピータブ ルリード P3 ファントム READ UNCOMMITTED 起きない 発生する 発生する 発生する READ COMMITTED 起きない 起きない 発生する 発生する REPEATABLE READ 起きない 起きない 起きない 発生する SERIALIZABLE 起きない 起きない 起きない 起きない ※MySQL InnoDBのデフォルトはREPEATABLE READ
- 20. 対処方法 色々やり方があります
- 21. 基本方針 • 競合が起きる条件を崩せば、問題は発生しない • 更新がある • 複数トランザクションが同時に同じデータを更新する • この２つの条件をいかにして崩すか。
- 22. 対処方法0 書き込まない • 読み込みのみであれば、問題は一切発生しない • 何も考えなくてよい。同時に読み込んでOK • 書き込みはバッチ処理に任せるケースも • もちろん、適用できるケースは限られる
- 23. 対処方法1 同時実行しない • 同時実行を一切しなければ、これらの問題は絶対に起きない • 直列化 (Serialization) とも言う • いったんキューに貯めて、リソースが空くのを待つ
- 24. 直列化の問題 • パフォーマンスが落ちる • スケーラビリティ皆無 • 実質ひとつのプロセッサが全作業を行うのと同じ • これでは実用にならないケースも多い…
- 26. 対処方法2-a ロック(Locking) • 悲観的同時実行制御とも呼ばれる • リソースに鍵をかけて、一度に一人しか触れないようにする • 部分的に直列化 • ロックされていたら、ロックが解除されるまで待つ • 直列化は全リソースをまとめてロックするのと同じ • 適切に使えば問題を完璧に防げる
- 28. ロックの粒度 • テーブルロック • (清掃中につきトイレ全体立ち入り禁止) • 行ロック • (個室の使用中・空きの制御) • 読み込みだけなら許可するロック • 読み込みも書き込みも許可しないロック • 大きくロックした方が安全だけど、 その分パフォーマンスが劣化する
- 29. ロックの問題 • 使いこなすのがむちゃくちゃ難しい • ロックのかけすぎでパフォーマンスが出ない • アンロック忘れにより破滅 • ロックの順番 • デッドロック • 再利用性の低下
- 31. デッドロック • ロックの順番を統一していな いと発生 • 永久にロックが取れない • 第2回 トランザクションを知ればデータベー スがわかる―「データ復旧」「同時実行制御」 を行う“不完全な”しくみ（3）：DBアタマアカ デミー｜gihyo.jp … 技術評論社 • http://gihyo.jp/dev/serial/01/db- academy/000203
- 32. ロックは地獄だぜー • ロックは難しい • 細かく書いていくとたぶん本ができあがる • 扱うにしても、なるべく先人たちの実装を再利用しましょう • DBなら組み込みのトランザクションを使う • ファイルならgitを使う • 参考： できる！並列・並行プログラミング http://www.slideshare.net/pfi/ss-9780450
- 33. 対処方法2-b バージョン管理 • 楽観的同時実行制御とも呼ばれる • データにリビジョン番号を振り、改竄を検出できるようにする • データ改竄を検出したらやり直すかマージする • ロックより簡単 • 競合が多いとパフォーマンスが落ちる • リトライしまくるので、ロックより劣化する
- 34. • 競合が発覚したら • リトライ • マージ リソース (1) バージョンを取得しておく (2) バージョンを取得しておく (3) ver1をベースにして、 データを更新するよー (4)ver1をベースにして、 データを更新するよー Ver 1 Ver 2 元にしたデータが 古いよ！ 受け入れません
- 35. バージョンの粒度 • テーブル全体のバージョン • 行のバージョン • ロックの粒度と対比
- 36. STM (Software Transactional Memory) • バージョン管理方式を使った並行プログラミングの手法 • 更新が競合する場合は1からやり直す • 割と単純なモデル
- 37. Git, svn方式 • マージの概念をプラス • マージもうまくできない場合、最初からやり直す
- 39. なるべくなら自分で実装しない • DBのトランザクションが使えるなら素直にそれを使う • 自前実装はイバラの道 • やるならバージョン管理方式の方がお手軽で楽
- 40. 扱うデータの種類を見極める • 例) PHPのセッション • 同時に同じセッションデータを読み書きすることはほとんどない • 同時実行が起きないので制御を考えなくていい • MemcachedとかのKVSで十分 • データの種類にあった同時実行制御を行えば、パフォーマンス が向上する • トランザクション分離レベルを操るところからでも
- 41. RESTとトランザクション • WebAPI作ってますか • WebAPIで同時実行制御のことを考えていますか • せっかくMySQLを使っているのに、オレオレWebAPI化によっ て同時実行制御が破綻しているケースをよく見かける • 条件付き更新に対応しておけば大丈夫
- 42. まとめ • 同時実行制御は難しいですが、色々な分野で登場します • わかると意外と役に立つかも • 我々凡人はなるべく先人たちの実装を使いましょう • Git • DBのトランザクション • 自前実装する場合は気を付けましょう
- 43. 同時実行制御 こわくないよ！！