---
title: ゲームで体感！Aurora DSQL の OCC（楽観的同時実行制御）
tags:  #aws #jaws-ug #aurora #dsql  
author: [hmatsu47(まつ)](https://www.docswell.com/user/hmatsu47)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/Y76LP16ZJV.jpg?width=480
description: JAWS ミート 2025 2025/7/5
published: July 05, 25
canonical: https://www.docswell.com/s/hmatsu47/ZJ977V-dsql-game-jawsmt
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/Y76LP16ZJV.jpg)

ゲームで体感！
Aurora DSQL の OCC
（楽観的同時実行制御）
JAWS ミート 2025
2025/7/5
まつひさ（hmatsu47）


# Page. 2

![Page Image](https://bcdn.docswell.com/page/G751K469E4.jpg)

自己紹介
松久裕保（@hmatsu47）
●
https://qiita.com/hmatsu47
● 現在：
○ 名古屋で Web インフラのお守り係をしています
○ SRE チームに所属しつつ技術検証の支援をしています
○ 普段カンファレンス・勉強会では DB の話しかしていません
（ほぼ）
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/9J21WVM57R.jpg)

本日の内容
● Aurora DSQL おさらい
○ 今年の 5/27 に GA
■
東京・大阪でシングルリージョン構成をリリース
● OCC（楽観的同時実行制御）おさらい
○ 通常の RDBMS（PCC）との違い
● ゲームで確かめよう！
● 答え合わせ
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/DEYZL3X67M.jpg)

Aurora DSQL
おさらい
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/VJN34V51J8.jpg)

サーバーレス分散 SQL データベース
● PostgreSQL ワイヤープロトコル互換
○ psql コマンドが使える
● シングルリージョン構成とマルチリージョン構成がある
○ マルチリージョン構成は US 3 リージョン／欧州 3 リージョン／
東京＋大阪＋ソウルの組み合わせでサポート
■
エンドポイントは 2 リージョン、残り 1 つは Witness リージョンで構成
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/YE99Q6YYE3.jpg)

国内のみでつくるならシングルリージョン構成
引用元 : https://aws.amazon.com/jp/blogs/news/introducing-amazon-aurora-dsql/
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GE89GZ6K7D.jpg)

それぞれの階層で負荷等に合わせて水平スケール
AWS Summit Japan 2025
AWS-43 資料より
引用元 : https://aws.amazon.com/jp/blogs/news/introducing-amazon-aurora-dsql/
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LELWGD9PJR.jpg)

OCC
おさらい
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/4JM9QPZ2EW.jpg)

シャーディングを使わずにスケールする…？
● 楽観的同時実行制御（OCC）を採用
○ 一般の RDBMS は悲観的同時実行制御（PCC）を採用
■
ロック機構を使う
○ OCC ではロックを使わない
■
コミット時に他のトランザクションとの更新競合を検知したらアボート
■
アボート後必要に応じてリトライ処理（アプリケーション側で実装）
○ ロックしないので他のトランザクションを待たせることがない
■
ただし更新競合が頻発するとアプリケーションの性能が下がる欠点がある
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PJRG8165E9.jpg)

例 [1] 通常の RDBMS（PCC / READ COMMITTED）
トランザクション A
トランザクション B
開始（BEGIN）
テーブル X の id = 1 の行
（コミット済み）
10（初期値）
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行ロック獲得成功 (11)
（別の処理を実行）
テーブル X の id = 1 の値を +1
→id = 1 の行ロック獲得待ち
コミット（COMMIT）→成功
（↑行ロック獲得待ち）
11
id = 1 の行ロック獲得成功 (12)
（別の処理を実行）
コミット（COMMIT）→成功
12
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/PEXX8YMXEX.jpg)

例 [2] Aurora DSQL（OCC / SNAPSHOT ISOLATION）
トランザクション A
トランザクション B
テーブル X の id = 1 の行
（コミット済み）
開始（BEGIN）
10（初期値）
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
（別の処理を実行）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
コミット（COMMIT）→成功
（別の処理を実行）
11
コミット（COMMIT）
→失敗・アボート
必要ならリトライする
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/3EKWK3G9ED.jpg)

さて問題です
トランザクション A
トランザクション B
テーブル X の id = 1 の行
（コミット済み）
開始（BEGIN）
10（初期値）
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
（別の処理を実行）
どちらかの
タイミングで
11 に
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
コミット（COMMIT）→？？
コミット（COMMIT）→？？
？？
？？
成功するのはどっち？
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/L731ZGN9J5.jpg)

ゲームで
確かめよう！
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/87DXR1W8EG.jpg)

「最後にコミットした人が勝ち！」ゲーム
● https://dsql.hmatsu47.nagoya/ または
● https://bit.ly/4nxEYrw
● 1. 最初に名前を登録
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/VJPPWQ9WJ8.jpg)

「最後にコミットした人が勝ち！」ゲーム
● https://dsql.hmatsu47.nagoya/ または
● https://bit.ly/4nxEYrw
● 2. ゲームが始まったら制限時間内に攻撃ボタンを押す
○ 押すと DSQL 上のテーブル行を UPDATE → 1 秒待つ→ COMMIT
○ 同時に複数の人が攻撃した場合、COMMIT が成功した人が勝ち
■
勝つと UPDATE → COMMIT の待ち時間が 1 秒増える（最大 5 秒まで）
■
負けると 1 秒にリセット
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/2EV285M9EQ.jpg)

「最後にコミットした人が勝ち！」ゲーム
● https://dsql.hmatsu47.nagoya/ または
● https://bit.ly/4nxEYrw
● 3. 攻撃ボタンは時間内に何度押しても OK
● 4. 制限時間内で一番最後に COMMIT した人が優勝！
○ ボタンを押した後の COMMIT が制限時間外なら攻撃失敗
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/57GR56G4EL.jpg)

答え合わせ
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4EQVZ4XRJP.jpg)

もうお分かりですね？
トランザクション A
トランザクション B
テーブル X の id = 1 の行
（コミット済み）
開始（BEGIN）
10（初期値）
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
（別の処理を実行）
どちらかの
タイミングで
11 に
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
コミット（COMMIT）→？？
コミット（COMMIT）→？？
？？
？？
成功するのはどっち？
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/KJ4M3Q6QE1.jpg)

答え
トランザクション A
トランザクション B
開始（BEGIN）
テーブル X の id = 1 の行
（コミット済み）
10（初期値）
こちらの
タイミングで
11 に
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
（別の処理を実行）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
コミット（COMMIT）→成功
11
コミット（COMMIT）→失敗
成功するのは B！（コミットまでの所要時間が長いトランザクションが不利）
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/LE181PVL7G.jpg)

答え
トランザクション A
トランザクション B
開始（BEGIN）
10（初期値）
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
（別の処理を実行）
テーブル X の id = 1 の行
（コミット済み）
BEGINから
コミットまで
の所要時間の
長さ
こちらの
タイミングで
11 に
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
コミット（COMMIT）→成功
11
コミット（COMMIT）→失敗
成功するのは B！（コミットまでの所要時間が長いトランザクションが不利）
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/GEWZ82LQE2.jpg)

ロックしないので
トランザクション A
トランザクション B
開始（BEGIN）
テーブル X の id = 1 の行
（コミット済み）
10（初期値）
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
（別の処理を実行）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
コミット（COMMIT）→成功
11
コミット（COMMIT）→失敗
「BEGIN / UPDATE が A のほうが先だから」という理由で A を優先するのであれば、
B はここで失敗することになる（A のコミットを待たずに B を失敗させるしかない）
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/47Z18DM3J3.jpg)

ところが
トランザクション A
トランザクション B
開始（BEGIN）
テーブル X の id = 1 の行
（コミット済み）
10（初期値）
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
（別の処理を実行）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
コミット（COMMIT）→成功
11
コミット（COMMIT）→失敗
A のコミットを待たないのに B が失敗するのであれば、後でコミットした A が
何らかの理由で失敗した場合、結果的に A も B も失敗することになる→ TPS 低下
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/YJ6LP1NZEV.jpg)

一方で、トランザクションの一貫性を保つには
トランザクション A
トランザクション B
開始（BEGIN）
テーブル X の id = 1 の行
（コミット済み）
10（初期値）
開始（BEGIN）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
（別の処理を実行）
テーブル X の id = 1 の値を +1
→id = 1 の行 : 11
コミット（COMMIT）→成功
11
コミット（COMMIT）→失敗
B も A も成功なら最終的に値が 12 になる必要があるがそうならない
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/GJ51K45974.jpg)

つまり
● 先に COMMIT した者勝ち！
○ 先に BEGIN しても INSERT / UPDATE しても関係なし
○ 結果として無用な待ち時間が発生せず、一貫性も保たれる
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/9E21WVN5JR.jpg)

Aurora DSQL は
特性を理解して
正しく使いましょう！
25