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
42
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
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
11
ベクトルストア入門
hmatsu47
PRO
0
10
Aurora DSQL について
hmatsu47
PRO
0
8
DynamoDB Global Tables MRSC・pgvector 0.8.0・caching_sha2_password 関連アップデート
hmatsu47
PRO
0
9
10 年(+1 年)の振り返りと 2025 年の活動予定
hmatsu47
PRO
0
23
RDS/Aurora アップデート(2024 年版)
hmatsu47
PRO
0
27
Claude 3.5 で Haiku
hmatsu47
PRO
0
25
HeatWave on AWS の PrivateLink インバウンドレプリケーションで Aurora フェイルオーバーに追従する
hmatsu47
PRO
0
22
大吉祥寺.pm の LT で ChatGPT の力を借りて Next.js App Router ベースの投句箱を作って、 Lambda Web Adapter を使って公開した話
hmatsu47
PRO
0
27
Other Decks in Technology
See All in Technology
ABWG2024採択者が語るエンジニアとしての自分自身の見つけ方〜発信して、つながって、世界を広げていく〜
maimyyym
1
120
手を動かしてレベルアップしよう!
maruto
0
200
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
7
660
4th place solution Eedi - Mining Misconceptions in Mathematics
rist
0
140
生成AI×財務経理:PoCで挑むSlack AI Bot開発と現場巻き込みのリアル
pohdccoe
1
620
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
150
Two Blades, One Journey: Engineering While Managing
ohbarye
4
1.9k
AWS Well-Architected Frameworkで学ぶAmazon ECSのセキュリティ対策
umekou
2
140
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
120
Active Directory攻防
cryptopeg
PRO
8
5.4k
短縮URLをお手軽に導入しよう
nakasho
0
140
RayでPHPのデバッグをちょっと快適にする
muno92
PRO
0
190
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Statistics for Hackers
jakevdp
797
220k
Optimizing for Happiness
mojombo
376
70k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
Why Our Code Smells
bkeepers
PRO
336
57k
Scaling GitHub
holman
459
140k
How STYLIGHT went responsive
nonsquared
98
5.4k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Gamification - CAS2011
davidbonilla
80
5.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Unsuck your backbone
ammeep
669
57k
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