並行性の問題を防げ！実践トランザクション入門

PHPカンファレンス愛媛 2026 登壇資料

Transcript

1. 並行性の問題を防げ！ 実践トランザクション入門 Shoichi Ochi （@occhi） PHPカンファレンス愛媛2026 2026-10-03
2. 自己紹介 おち しょういち 越智 翔一 SmartBank, Inc. Software Engineer 出身: 愛媛県西条市 趣味: 筋トレ @ochi11181101 @sho-work 2
4. トランザクション 4
5. Introduction 「トランザクション」 複数の読み書きを、 1つの論理的な処理単位と して扱う仕組み。 トランザクション中のすべての読み書きは、 1つ の処理単位として扱われ、オールオアナッシン グの保証を提供してくれる。 つまり、すべて成功するか（ commit）、すべて なかった（rollback）ことにするかしかない。 5
6. Introduction 「トランザクション」 複数の読み書きを、 1つの論理的な処理単位と して扱う仕組み。 トランザクション中のすべての読み書きは、 1つ の処理単位として扱われ、オールオアナッシン グの保証を提供してくれる。 複数のクエリを、 BEGIN ~ COMMITで囲む つまり、すべて成功するか（ commit）、すべて なかった（rollback）ことにするかしかない。 6
7. 今回はそんなトランザクションが、 複数実行された時に起こる問題の話 7
8. では、実際にどんな問題が起こる？🤔 8
9. 簡単な例を見てみよう！💪💪 9
10. Introduction 並行性の問題の簡単な例 カウンタの同一レコード更新をしようとする 2つのトランザクションを考える * https://www.oreilly.co.jp/books/9784873118703/ 10
11. Introduction 並行性の問題の簡単な例 カウンタの同一レコード更新をしようとする 2つのトランザクションを考える BEGIN * https://www.oreilly.co.jp/books/9784873118703/ COMMIT 11
12. Introduction 並行性の問題の簡単な例 カウンタの同一レコード更新をしようとする 2つのトランザクションを考える BEGIN * https://www.oreilly.co.jp/books/9784873118703/ COMMIT 12
13. Introduction 並行性の問題の簡単な例 カウンタの同一レコード更新をしようとする 2つのトランザクションを考える Tx A Tx B * https://www.oreilly.co.jp/books/9784873118703/ 13
14. Introduction 並行性の問題の簡単な例 どちらのユーザーも現在のカウンタ +1したい よって、以下のようになっていて欲しい ・ユーザー 1のCOMMIT直後には 43 ・ユーザー 2のCOMMIT直後には 44 * https://www.oreilly.co.jp/books/9784873118703/ 14
15. Introduction 並行性の問題の簡単な例 1. Tx Aが現在のカウンタを読む（ =42） * https://www.oreilly.co.jp/books/9784873118703/ 15
16. Introduction 並行性の問題の簡単な例 1. Tx Aが現在のカウンタを読む（=42） 2. Tx Bが現在のカウンタを読む（ =42） * https://www.oreilly.co.jp/books/9784873118703/ 16
17. Introduction 並行性の問題の簡単な例 1. Tx Aが現在のカウンタを読む（=42） 3. カウンタを 42+1し、43でUPDATE 2. Tx Bが現在のカウンタを読む（=42） * https://www.oreilly.co.jp/books/9784873118703/ 17
18. Introduction 並行性の問題の簡単な例 1. Tx Aが現在のカウンタを読む（=42） 3. カウンタを42+1し、43でUPDATE 2. Tx Bが現在のカウンタを読む（=42） * https://www.oreilly.co.jp/books/9784873118703/ 4. カウンタを 42+1し、43でUPDATE 18
19. Introduction 並行性の問題の簡単な例 最終結果が 44ではなく、 43になってしまった！ 😭 3. カウンタを42+1し、43でUPDATE 4. カウンタを 42+1し、43でUPDATE * https://www.oreilly.co.jp/books/9784873118703/ 19
20. むむむ・・・🤔 2020
21. どうやって防げばいいんやろか？🤔 2121
22. 今日のトーク 22
23. 今日紹介するトランザクション分離レベルとレース条件 23
24. 今日紹介するトランザクション分離レベルとレース条件 24
25. 今日のトーク 25
26. 1. トランザクション分離レベル 26
27. トランザクション分離レベル
28. トランザクション分離レベル 28
29. 分離レベルは「他のTxの変更が、いつから見えるか」の設定 29
30. 他の Tx の変更が見え始めるタイミングは、分離レベルで違う 30
31. 他の Tx の変更が見え始めるタイミングは、分離レベルで違う 31
32. 他の Tx の変更が見え始めるタイミングは、分離レベルで違う 32
33. トランザクション分離レベル 33
34. Serializableの実現方法は 3 つある 34
35. Serializableの実現方法は 3 つあり、どれも見え方が異なる 35
36. 完全な順次実行：そもそも同時に走らせない 36
37. 完全な順次実行：そもそも同時に走らせない 37
38. Serializableの実現方法は 3 つあり、どれも見え方が異なる 38
39. ロックには、共有ロックと排他ロックがある 39
40. 2PL：ロックを取って、競合する読み書きを待たせる 40
41. 2PL：ロックを取って、競合する読み書きを待たせる 41
42. 2PL：ロックを取って、競合する読み書きを待たせる 42
43. 2PL：ロックを取って、競合する読み書きを待たせる 43
44. 2PL：ロックを取って、競合する読み書きを待たせる 44
45. Serializableの実現方法は 3 つあり、どれも見え方が異なる 45
46. SSI（直列化可能なスナップショット分離）：スナップショットから更新されていたらロールバックさせる 46
47. SSI（直列化可能なスナップショット分離）：スナップショットから更新されていたらロールバックさせる 47
48. SSI（直列化可能なスナップショット分離）：スナップショットから更新されていたらロールバックさせる 48
49. SSI（直列化可能なスナップショット分離）：スナップショットから更新されていたらロールバックさせる 49
50. SSI（直列化可能なスナップショット分離）：スナップショットから更新されていたらロールバックさせる 50
51. 今日のトーク 51
52. 2. 並行性の問題 52
53. 並行性の問題の全体像 53
54. 問題ごとに「どのレベルから防げるか」を表に埋めていく 54
55. 同じ 1 行を、並行して読み書きする場合に起こる問題 55
56. ここからしばらくは、accounts テーブルで考える 56
57. Dirty Write：未コミットの値を、別のTxが上書きしてしまう 57
58. Dirty Write：未コミットの値を、別のTxが上書きしてしまう 58
59. Dirty Write：未コミットの値を、別のTxが上書きしてしまう 59
60. Dirty Write：未コミットの値を、別のTxが上書きしてしまう 60
61. Dirty Write：未コミットの値を、別のTxが上書きしてしまう 61
62. Dirty Write は、どの分離レベルでも防がれる 62
63. Dirty Write の防ぎ方：書き込む行のロックを COMMIT まで持つ 63
64. Dirty Read：未コミットの値を読んでしまう 64
65. Dirty Read：未コミットの値を読んでしまう 65
66. Dirty Read：未コミットの値を読んでしまう 66
67. Dirty Read：未コミットの値を読んでしまう 67
68. Dirty Read：未コミットの値を読んでしまう 68
69. Dirty Read は Read Uncommitted で起き、Read Committed 以上で防げる 69
70. Lost Update：古い値を前提に上書きして、更新が消える 70
71. Lost Update は Snapshot Isolation 以下で起きうる（DB による） https://www.postgresql.org/docs/current/transaction-iso.html 71
72. 複数の行にまたがる整合性が崩れる問題 72
73. Read Skew：1つのTx内で、異なる時点のコミット済みデータを読んでしまう 73
74. Read Skew：1つのTx内で、異なる時点のコミット済みデータを読んでしまう 74
75. Read Skew：1つのTx内で、異なる時点のコミット済みデータを読んでしまう 75
76. Read Skew：1つのTx内で、異なる時点のコミット済みデータを読んでしまう 76
77. Read Skew：1つのTx内で、異なる時点のコミット済みデータを読んでしまう 77
78. Read Skew：1つのTx内で、異なる時点のコミット済みデータを読んでしまう 78
79. Read Skew は Read Committed 以下で起き、Snapshot Isolation 以上で防げる 79 79
80. ここからは budgets テーブルで考える 80
81. 部署の予算：どちらも「あと 20 使える」と判断して、合計が上限を超える 81
82. 部署の予算：どちらも「あと 20 使える」と判断して、合計が上限を超える 82
83. 部署の予算：どちらも「あと 20 使える」と判断して、合計が上限を超える 83
84. 部署の予算：どちらも「あと 20 使える」と判断して、合計が上限を超える 84
85. 部署の予算：どちらも「あと 20 使える」と判断して、合計が上限を超える 85
86. 部署の予算：どちらも「あと 20 使える」と判断して、合計が上限を超える 86
87. 更新は消えていない。壊れたのは「読んだ前提」 87
88. Write Skew は「Observe → Decide → Mutate」の流れで起きる 88
89. Write Skew は「Observe → Decide → Mutate」の流れで起きる 89
90. Write Skew は「Observe → Decide → Mutate」の流れで起きる 90
91. 2 つの Tx が同じ古い前提を観測すると、組み合わせた結果として不変条件が壊れる 91
92. 同じ形の問題は、身近にいくつもある 92
93. 会議室予約は bookings テーブルで考える 93
94. 会議室予約：どちらも「重なる予約は 0 件」を見て、同じ時間に予約を入れる 94
95. 会議室予約：どちらも「重なる予約は 0 件」を見て、同じ時間に予約を入れる 95
96. 会議室予約：どちらも「重なる予約は 0 件」を見て、同じ時間に予約を入れる 96
97. 会議室予約：どちらも「重なる予約は 0 件」を見て、同じ時間に予約を入れる 97
98. 会議室予約：どちらも「重なる予約は 0 件」を見て、同じ時間に予約を入れる 98
99. Write Skew のうち、ロックすべき行がまだ存在しないケース 99
100. Write Skew は Serializable だけが防ぐ 100
101. デフォルトの分離レベルでは、どのような問題が起こる？ 101
102. 今日のトーク 102
103. 3. 並行性の問題を防ぐトランザクション設計手段 103
104. デフォルトの分離レベルで残る問題に、自分で対処する 104
105. Read Skew の対策：一貫したスナップショットで読むか、読む行を変更させない 105
106. Lost Update の対策：アトミックな更新・悲観ロック・楽観ロック 106
107. Write Skew の対策：ロックすべき行があるか、まだないか 107
108. Write Skew の対策：ロックすべき行があるか、まだないか 108
109. Write Skew の対策：ロックすべき行があるか、まだないか 109
110. Write Skew の対策：ロックすべき行があるか、まだないか 110
111. Write Skew の対策：ロックすべき行があるか、まだないか 111
112. 部署の予算は、前提にした行を FOR UPDATE でロックすれば防げる 112
113. 部署の予算は、前提にした行を FOR UPDATE でロックすれば防げる 113
114. 部署の予算は、前提にした行を FOR UPDATE でロックすれば防げる 114
115. 部署の予算は、前提にした行を FOR UPDATE でロックすれば防げる 115
116. 部署の予算は、前提にした行を FOR UPDATE でロックすれば防げる 116
117. Write Skew の対策：ロックすべき行があるか、まだないか 117
118. ユーザー名の登録は users テーブルで考える 118
119. 対策①：制約で書けるなら、DB に任せる（ユーザー名の UNIQUE） 119
120. 対策①：制約で書けるなら、DB に任せる（ユーザー名の UNIQUE） 120
121. 対策①：制約で書けるなら、DB に任せる（ユーザー名の UNIQUE） 121
122. 対策①：制約で書けるなら、DB に任せる（ユーザー名の UNIQUE） 122
123. ロックするテーブルが存在しない例 123
124. ロックするテーブルが存在しない例 124
125. ロックするテーブルが存在しない例 125
126. ロックするテーブルが存在しない例 126
127. ロックするテーブルが存在しない例 127
128. 対策④：「ない」を、ロックできる行に置き換える（競合の実体化） 128
129. 対策④：「ない」を、ロックできる行に置き換える（競合の実体化） 129
130. 対策④：「ない」を、ロックできる行に置き換える（競合の実体化）
131. 対策④：「ない」を、ロックできる行に置き換える（競合の実体化） 131
132. 対策④：「ない」を、ロックできる行に置き換える（競合の実体化） 132
133. 実体化の対象は、例ごとに「必ずある行」を選ぶ 133
134. Write Skew の対策は、悲観ロック → Serializable → 競合の実体化 の順に検討する 134
135. 今日のトーク 135
136. 4. デッドロックとその対策 136
137. デッドロック：お互いが相手のロックを待ち続けて、どちらも進めない 137
138. デッドロックが起きるメカニズム：2 つの Tx が逆の順番で行をロックする 138
139. デッドロックが起きるメカニズム：2 つの Tx が逆の順番で行をロックする 139
140. デッドロックが起きるメカニズム：2 つの Tx が逆の順番で行をロックする 140
141. デッドロックが起きるメカニズム：2 つの Tx が逆の順番で行をロックする 141
142. デッドロックが起きるメカニズム：2 つの Tx が逆の順番で行をロックする 142
143. デッドロックが起きるメカニズム：2 つの Tx が逆の順番で行をロックする 143
144. デッドロックは「起きにくくする」と「回復可能にする」の両方を設計する 144
145. 回避①：ロックを取る順番をそろえる 145
146. 回避①：ロックを取る順番をそろえる 146
147. 回避①：ロックを取る順番をそろえる 147
148. 回避①：ロックを取る順番をそろえる 148
149. 回避①：ロックを取る順番をそろえる 149
150. 回避①：ロックを取る順番をそろえる 150
151. 回避②：Tx を短く保ち、ロックを持つ時間を減らす 151
152. 回避③：インデックスで、ロックする行を絞る 152
153. 余談: その他の回避方法 トランザクション分離レベルを下げるという手段もあるが、最終手段 https://kaigionrails.org/2026/talks/sho-work/ 153
154. 余談: その他の回避方法 トランザクション分離レベルを下げるという手段もあるが、最終手段 後日登壇予定！ https://kaigionrails.org/2026/talks/sho-work/ 154
155. 回復：DB がデッドロックを検出した際の挙動 155
156. 回復：デッドロックによって失敗した際のリトライの設計 156
157. 回復：PHP（PDO）でリトライを書いた例 157
158. まとめ 158
159. 並行性の問題が起こるトランザクションを設計する際の思考順序 159
160. 並行性の問題が起こるトランザクションを設計する際の思考順序 160
161. 並行性の問題が起こるトランザクションを設計する際の思考順序 161
162. 並行性の問題が起こるトランザクションを設計する際の思考順序 162
163. 並行性の問題を防げ！ 実践トランザクション入門 Shoichi Ochi （@occhi） PHPカンファレンス愛媛2026 2026-10-03
164. Appendix - 参考資料 • • • • • • • • • Designing Data-Intensive Applications（Martin Kleppmann, O'Reilly, 2017） ◦ https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/ データ指向アプリケーションデザイン（オライリー・ジャパン , 2019） ◦ https://www.oreilly.co.jp/books/9784873118703/ PostgreSQL: Transaction Isolation ◦ https://www.postgresql.org/docs/current/transaction-iso.html PostgreSQL: Explicit Locking ◦ https://www.postgresql.org/docs/current/explicit-locking.html PostgreSQL: Serialization Failure Handling ◦ https://www.postgresql.org/docs/current/mvcc-serialization-failure-handling.html MySQL 8.4: Transaction Isolation Levels ◦ https://dev.mysql.com/doc/refman/8.4/en/innodb-transaction-isolation-levels.html MySQL 8.4: InnoDB Locking ◦ https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html MySQL 8.4: Locking Reads ◦ https://dev.mysql.com/doc/refman/8.4/en/innodb-locking-reads.html MySQL 8.4: Deadlocks in InnoDB ◦ https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks.html 164