ゲームで体感！Aurora DSQL の OCC（楽観的同時実行制御）

>100 Views

July 04, 25

#aws #jaws-ug #aurora #dsql

スライド概要

JAWS ミート 2025
2025/7/5

profile-image
スライド一覧

Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book https://speakerdeck.com/hmatsu47

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

slide-thumbnail

MySQL 8.0への移行を考える
mysql 移行 バージョンアップ 中国地方db勉強会
user-img hmatsu47(まつ) 71.1K
slide-thumbnail

JavaのレガシーなWebアプリをECS Fargateを使って段階的に作り直し／マイグレーションする話
java tomcat aws jaws-ug ecs fargate マイグレーション 移行 バージョンアップ
user-img hmatsu47(まつ) 50.1K
slide-thumbnail

Amplify Flutterを使おうとしたけど微妙な結果に終わった話
aws amplify flutter jaws-ug mapbox supabase
user-img hmatsu47(まつ) 37K
slide-thumbnail

さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
mysql アップグレード 移行 リリースモデル
user-img hmatsu47(まつ) 35.9K
slide-thumbnail

EFSへの書き込み速度を上げる（小ネタ）
aws efs jaws-ug
user-img hmatsu47(まつ) 31.5K
slide-thumbnail

Aurora MySQL v1 → v3 移行で気を付けたほうが良いこと（7 つ + α）
aws aurora 移行 バージョンアップ mysql
user-img hmatsu47(まつ) 30.5K
各ページのテキスト
1.

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

2.

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

3.

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

4.

Aurora DSQL おさらい 4

5.

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

6.

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

7.

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

8.

OCC おさらい 8

9.

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

10.

例 [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

11.

例 [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

12.

さて問題です トランザクション 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

13.

ゲームで 確かめよう！ 13