Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Aurora DSQL と楽観的同時実行制御(OCC)
Search
hmatsu47
PRO
December 25, 2024
Technology
0
54
Aurora DSQL と楽観的同時実行制御(OCC)
AWS re:Invent 2024 re:Cap 名古屋 2024/12/26
hmatsu47
PRO
December 25, 2024
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
5
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
13
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
19
ベクトルストア入門
hmatsu47
PRO
0
18
Aurora DSQL について
hmatsu47
PRO
0
14
DynamoDB Global Tables MRSC・pgvector 0.8.0・caching_sha2_password 関連アップデート
hmatsu47
PRO
0
16
10 年(+1 年)の振り返りと 2025 年の活動予定
hmatsu47
PRO
0
32
RDS/Aurora アップデート(2024 年版)
hmatsu47
PRO
0
40
Claude 3.5 で Haiku
hmatsu47
PRO
0
30
Other Decks in Technology
See All in Technology
Would you THINK such a demonstration interesting ?
shumpei3
1
220
Amazon CloudWatch Application Signals ではじめるバーンレートアラーム / Burn rate alarm with Amazon CloudWatch Application Signals
ymotongpoo
5
520
地味にいろいろあった! 2025春のAmazon Bedrockアップデートおさらい
minorun365
PRO
1
190
いつも初心者向けの記事に助けられているので得意分野では初心者向けの記事を書きます
toru_kubota
2
320
AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話
kakehashi
PRO
0
160
AWSで作るセキュアな認証基盤with OAuth mTLS / Secure Authentication Infrastructure with OAuth mTLS on AWS
kaminashi
0
170
アジャイル脅威モデリング#1(脅威モデリングナイト#8)
masakane55
3
200
Стильный код: натуральный поиск редких атрибутов по картинке. Юлия Антохина, Data Scientist, Lamoda Tech
lamodatech
0
730
コスト最適重視でAurora PostgreSQLのログ分析基盤を作ってみた #jawsug_tokyo
non97
0
220
LLM as プロダクト開発のパワードスーツ
layerx
PRO
1
240
新卒エンジニアがCICDをモダナイズしてみた話
akashi_sn
2
240
PagerDuty×ポストモーテムで築く障害対応文化/Building a culture of incident response with PagerDuty and postmortems
aeonpeople
1
180
Featured
See All Featured
Music & Morning Musume
bryan
47
6.5k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
104
19k
Build The Right Thing And Hit Your Dates
maggiecrowley
35
2.6k
Docker and Python
trallard
44
3.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Rails Girls Zürich Keynote
gr2m
94
13k
Navigating Team Friction
lara
184
15k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.1k
Into the Great Unknown - MozCon
thekraken
37
1.7k
Transcript
Aurora DSQL と楽観的同時実行制御(OCC) AWS re:Invent 2024 re:Cap 名古屋 2024/12/26 まつひさ(hmatsu47)
自己紹介 松久裕保(@hmatsu47) • https://qiita.com/hmatsu47 • 名古屋で Web インフラのお守り係をしています • 普段は
JAWS-UG 名古屋(・浜松)で DB ネタを中心 に話しています(主に RDS / Aurora・たまに DynamoDB) • 全国各地の JAWS(& AWSJ)イベントを巡っています ◦ DAYS(東京)→佐賀→金沢(福井開催)→山形→ Summit →ミート(豊橋)→ 岩手(滝沢)→青森(弘前) 2
12/4 に Aurora DSQL(プレビュー)発表 • シングルリージョン/マルチリージョン大規模分散 DB ◦ リレーショナルモデルと SQL
が使用可能 ▪ いわゆる NewSQL の一種 ◦ ワークロードに合わせて自動でスケール(UP / DOWN) ◦ PostgreSQL ワイヤープロトコル互換 ▪ 対応 SQL 文は PostgreSQL のサブセット ◦ アクティブ/アクティブ構成 ▪ マルチ Writer でシャーディングを使わないアーキテクチャ 3
[1] シングルリージョン構成(可用性 99.99%) 4 引用元 : https://aws.amazon.com/jp/blogs/news/introducing-amazon-aurora-dsql/ Transaction log layer
がある
[2] マルチリージョン構成(可用性 99.999%) 5 引用元 : https://aws.amazon.com/jp/blogs/news/introducing-amazon-aurora-dsql/ Witness Region がある
(リージョンクラスター間調停・ 障害リージョンのデータ修復)
Aurora PostgreSQL Limitless Database では? 6 引用元 : https://aws.amazon.com/jp/blogs/news/amazon-aurora-postgresql-limitless-database-is-now-generally-available/ 前段のルーター層でコマンド/
クエリをシャードに振り分ける 各シャードでデータを分割管理 する (テーブルの種類によってデータの 配置は異なる) Limitless Database はシャーディング によってデータと負荷を分散するので テーブル設計が難しい
シャーディングを使わずにスケールするには? • 楽観的同時実行制御(OCC)を採用 ◦ 一般の RDBMS は悲観的同時実行制御(PCC)を採用 ▪ ロック機構を使う ◦
OCC ではロックを使わない ▪ コミット時に他のトランザクションとの更新競合を検知したらアボート ▪ アボート後必要に応じてリトライ処理(アプリケーション側で実装) ◦ ロックしないので他のトランザクションを待たせることがない ▪ ただし更新競合が頻発するとアプリケーションの性能が下がる欠点がある 7
トランザクション A トランザクション B テーブル X の id = 1
の行 (コミット済み) 開始(BEGIN) 10(初期値) 開始(BEGIN) テーブル X の id = 1 の値を +1 →id = 1 の行ロック獲得成功 (11) (別の処理を実行) テーブル X の id = 1 の値を +1 →id = 1 の行ロック獲得待ち コミット(COMMIT)→成功 (↑行ロック獲得待ち) 11 id = 1 の行ロック獲得成功 (12) (別の処理を実行) コミット(COMMIT)→成功 12 例 [1] 通常の RDBMS(PCC / READ COMMITTED) 8
トランザクション 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) →失敗・アボート 例 [2] Aurora DSQL(OCC / SNAPSHOT ISOLATION) 9 必要ならリトライする
OCC は PCC と比べて本当に効率が良いのか? • そもそも更新競合が少ないケースで使うもの ◦ 更新競合が多い処理→別データストアを選択して実装したほうが 良い •
分散 DB ではネットワークの遅延が大きく影響 ◦ 都度ロックする場合、地理的に離れたノード・クラスターにも ロックの伝達が必要 →トランザクションコミット時にまとめて確認したほうが効率が良い 10
OCC の注意点 • 長いトランザクションには向かない ◦ あくまでも更新競合が少ないトランザクション向け ▪ トランザクションが長くなるほど更新競合が発生しやすくなる • リトライはアプリケーションで実装する必要がある
• コミット成功の順序が保証されない ◦ トランザクション A → B → C で B が競合してリトライすると、 コミット成功の順序が A → C → B(リトライ)になることも 11
まとめ • Aurora DSQL は SQL が使える大規模分散 DB ◦ シングルリージョンでもマルチリージョンでも使える
◦ OCC の採用によりシャーディングなしにスケールが可能に • 通常の RDBMS とはトランザクションの流れが異なる ◦ 更新が競合したらアボート ◦ 必要ならアプリケーション側でリトライ処理を実装する 12
宣伝 : PHP カンファレンス名古屋 2025 開催! • PHP 以外の話も(少し)あります!(私は MySQL
の話を…) ◦ https://phpcon.nagoya/2025/ 13