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
8
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
さいきんの MySQL との付き合い方 〜 MySQL 8.0 より後の世界へようこそ 〜
hmatsu47
PRO
0
11
ベクトルストア入門
hmatsu47
PRO
0
10
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
Aurora DSQL と楽観的同時実行制御(OCC)
hmatsu47
PRO
0
42
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
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
270
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
210
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
2
540
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
82k
AWSではじめる Web APIテスト実践ガイド / A practical guide to testing Web APIs on AWS
yokawasa
7
660
【内製開発Summit 2025】イオンスマートテクノロジーの内製化組織の作り方/In-house-development-summit-AST
aeonpeople
2
610
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
190
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
260
30→150人のエンジニア組織拡大に伴うアジャイル文化を醸成する役割と取り組みの変化
nagata03
0
140
Iceberg Meetup Japan #1 : Iceberg and Databricks
databricksjapan
0
330
Pwned Labsのすゝめ
ken5scal
1
400
分解して理解する Aspire
nenonaninu
2
1k
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
229
18k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Designing for Performance
lara
604
68k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Gamification - CAS2011
davidbonilla
80
5.2k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.4k
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