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 について
Search
hmatsu47
PRO
January 23, 2025
Technology
0
35
Aurora DSQL について
JAWS-UG 浜松 x Media-JAWS 合同 AWS 勉強会 202501 2025/1/23
hmatsu47
PRO
January 23, 2025
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
9
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
17
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
14
PostgreSQL+pgvector で LlamaIndex の Property Graph Index を試す(序章)
hmatsu47
PRO
0
12
HeatWave on AWS という選択肢を検討してみる
hmatsu47
PRO
0
9
HeatWave on AWS のインバウンドレプリケーションで HeatWave エンジン有効時のレプリケーションラグを確認してみた!
hmatsu47
PRO
0
17
CloudWatch Database Insights 関連アップデート
hmatsu47
PRO
0
37
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
32
ベクトルストア入門
hmatsu47
PRO
0
26
Other Decks in Technology
See All in Technology
Shadow DOMとセキュリティ - 光と影の境界を探る / Shibuya.XSS techtalk #13
masatokinugawa
0
270
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
39k
Ktor + Google Cloud Tasks/PubSub におけるOTel Messaging計装の実践
sansantech
PRO
1
250
QAを早期に巻き込む”って どうやるの? モヤモヤから抜け出す実践知
moritamasami
2
170
P2P通信の標準化 WebRTCを知ろう
faithandbrave
6
2.3k
The Madness of Multiple Gemini CLIs Developing Simultaneously with Jujutsu
gunta
1
2.4k
M365アカウント侵害時の初動対応
lhazy
6
4.5k
QuickBooks®️ Customer®️ USA Contact Numbers: Complete 2025 Support Guide
qbsupportinfo
0
100
Expertise as a Service via MCP
yodakeisuke
1
140
FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜 / Review of the first year of FAST implementation
wooootack
1
120
株式会社島津製作所_研究開発(集団協業と知的生産)の現場を支える、OSS知識基盤システムの導入
akahane92
1
1.1k
地図と生成AI
nakasho
0
680
Featured
See All Featured
Building an army of robots
kneath
306
45k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
How to train your dragon (web standard)
notwaldorf
96
6.1k
Navigating Team Friction
lara
187
15k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Become a Pro
speakerdeck
PRO
29
5.4k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Bash Introduction
62gerente
613
210k
The Cost Of JavaScript in 2023
addyosmani
51
8.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Transcript
Aurora DSQL について JAWS-UG 浜松 x Media-JAWS 合同 AWS 勉強会
202501 2025/1/23 まつひさ(hmatsu47)
自己紹介 松久裕保(@hmatsu47) • https://qiita.com/hmatsu47 • Web インフラのお守り係をしています • 普段は JAWS-UG
名古屋・浜松で DB ネタを中心に 話しています(主に RDS / Aurora・たまに DynamoDB) • 2/1(土)に BuriKaigi2025(富山県立大)でベクターストア 2/22(土)に PHP カンファレンス名古屋 2025(名古屋駅・ウイン クあいち)で MySQL 8.4 以降の話をします 2
12/4 に Aurora DSQL(プレビュー)発表 • シングルリージョン/マルチリージョン分散 DB ◦ リレーショナルモデルと SQL
が使用可能 ◦ ワークロードに合わせて自動でスケール(UP / DOWN) ◦ PostgreSQL ワイヤープロトコル互換 ▪ 対応 SQL 文は PostgreSQL のサブセット ◦ アクティブ/アクティブ構成 ▪ マルチ Writer でシャーディングを使わないアーキテクチャ ◦ Firecracker と Time Sync Service を活用 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 がある
(リージョンクラスター間調停・ 障害リージョンのデータ修復) Google Cloud の Spanner の マルチリージョン構成には、 DSQL と同様に独立したリー ジョンを Witness にする構成 と、デュアルリージョンで各 リージョンの 1 ゾーンに Witness 機能を置く構成があ る。
参考:Aurora PostgreSQL Limitless Database 6 引用元 : https://aws.amazon.com/jp/blogs/news/amazon-aurora-postgresql-limitless-database-is-now-generally-available/ 前段のルーター層でコマンド/ クエリをシャードに振り分ける
各シャードでデータを分割管理 する (テーブルの種類によってデータの 配置は異なる) Limitless Database はシャーディング によってデータと負荷を分散するので テーブル設計が難しい (Spanner も内部はシャーディング構成で データを自動的に分割している)
シャーディングを使わずにスケールする…? • 楽観的同時実行制御(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
おまけ : Aurora DSQL が目指すのは?(想像) • リレーショナル DB 版 DynamoDB
Global Tables ? ◦ オンデマンドの DynamoDB のように手軽に使うもの ▪ 難しいテーブル設計やパフォーマンスチューニングはしない ▪ トランザクション処理は最小限にして更新系はオートコミット中心で • Aurora Limitless Database とは方向性が異なる ◦ Google Cloud の Spanner とも方向性が異なる ▪ (中身は別として)ユーザーから見てシンプルでわかりやすいものを 13