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
48
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
今年の FESTA で初当日スタッフ+登壇してきました
hmatsu47
PRO
0
6
攻略!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
4
PostgreSQL でもできる!GraphRAG
hmatsu47
PRO
0
2
Aurora DSQL のトランザクション(スナップショット分離と OCC)
hmatsu47
PRO
0
8
いろんなところに居る Amazon Q(Developer)を使い分けてみた
hmatsu47
PRO
0
25
「ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)」の結果ログから Aurora DSQL の動作を考察する
hmatsu47
PRO
0
2
ゲームで体感!Aurora DSQL の OCC(楽観的同時実行制御)
hmatsu47
PRO
0
33
PostgreSQL+pgvector で GraphRAG に挑戦 & pgvectorscale 0.7.x アップデート
hmatsu47
PRO
0
47
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
hmatsu47
PRO
0
17
Other Decks in Technology
See All in Technology
Introdução a Service Mesh usando o Istio
aeciopires
1
230
コンテキストエンジニアリング入門〜AI Coding Agent作りで学ぶ文脈設計〜
kworkdev
PRO
3
2k
Zephyr(RTOS)にEdge AIを組み込んでみた話
iotengineer22
0
200
難しいセキュリティ用語をわかりやすくしてみた
yuta3110
0
330
Building a cloud native business on open source
lizrice
0
110
衛星画像超解像化によって実現する2D, 3D空間情報の即時生成と“AI as a Service”/ Real-time generation spatial data enabled_by satellite image super-resolution
lehupa
0
190
Introduction to Sansan Meishi Maker Development Engineer
sansan33
PRO
0
310
私のMCPの使い方
tsubakimoto_s
0
110
「れきちず」のこれまでとこれから - 誰にでもわかりやすい歴史地図を目指して / FOSS4G 2025 Japan
hjmkth
1
330
[VPoE Global Summit] サービスレベル目標による信頼性への投資最適化
satos
0
140
Geospatialの世界最前線を探る [2025年版]
dayjournal
1
260
WEBサービスを成り立たせるAWSサービス
takano0131
1
180
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Done Done
chrislema
185
16k
YesSQL, Process and Tooling at Scale
rocio
173
14k
We Have a Design System, Now What?
morganepeng
53
7.8k
Faster Mobile Websites
deanohume
310
31k
How to Think Like a Performance Engineer
csswizardry
27
2.1k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Building an army of robots
kneath
306
46k
Embracing the Ebb and Flow
colly
88
4.9k
Visualization
eitanlees
149
16k
It's Worth the Effort
3n
187
28k
Practical Orchestrator
shlominoach
190
11k
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