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
9
DynamoDB Global Tables MRSC・pgvector 0.8.0・caching_sha2_password 関連アップデート
hmatsu47
PRO
0
10
10 年(+1 年)の振り返りと 2025 年の活動予定
hmatsu47
PRO
0
24
RDS/Aurora アップデート(2024 年版)
hmatsu47
PRO
0
30
Claude 3.5 で Haiku
hmatsu47
PRO
0
26
HeatWave on AWS の PrivateLink インバウンドレプリケーションで Aurora フェイルオーバーに追従する
hmatsu47
PRO
0
23
大吉祥寺.pm の LT で ChatGPT の力を借りて Next.js App Router ベースの投句箱を作って、 Lambda Web Adapter を使って公開した話
hmatsu47
PRO
0
27
Other Decks in Technology
See All in Technology
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
2
450
DevinでAI AWSエンジニア製造計画 序章 〜CDKを添えて〜/devin-load-to-aws-engineer
tomoki10
0
180
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
280
Oracle Database Technology Night #87-1 : Exadata Database Service on Exascale Infrastructure(ExaDB-XS)サービス詳細
oracle4engineer
PRO
1
190
AIエージェント入門
minorun365
PRO
32
19k
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
440
ExaDB-XSで利用されているExadata Exascaleについて
oracle4engineer
PRO
3
270
AI自体のOps 〜LLMアプリの運用、AWSサービスとOSSの使い分け〜
minorun365
PRO
7
480
2/18 Making Security Scale: メルカリが考えるセキュリティ戦略 - Coincheck x LayerX x Mercari
jsonf
0
230
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
2
1.5k
生成AI “再”入門 2025年春@WIRED TUESDAY EDITOR'S LOUNGE
kajikent
0
140
OCI Success Journey OCIの何が評価されてる?疑問に答える事例セミナー(2025年2月実施)
oracle4engineer
PRO
2
170
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
GitHub's CSS Performance
jonrohan
1030
460k
Documentation Writing (for coders)
carmenintech
67
4.6k
Building Adaptive Systems
keathley
40
2.4k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
How to train your dragon (web standard)
notwaldorf
91
5.9k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
Automating Front-end Workflow
addyosmani
1368
200k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
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