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
札幌IT石狩鍋_1.pdf
Search
Nakagawa Shota
February 19, 2025
0
290
札幌IT石狩鍋_1.pdf
Nakagawa Shota
February 19, 2025
Tweet
Share
More Decks by Nakagawa Shota
See All by Nakagawa Shota
AWSで始める負荷テスト入門
snakagawax227
2
4.3k
これから始める脆弱性診断
snakagawax227
0
1.4k
迅速にAWS移行をすすめるベストプラクティス
snakagawax227
0
1.6k
これから始めるAWS移行のベストプラクティス
snakagawax227
0
2.9k
AWSコスト最適化のポイントのご紹介
snakagawax227
0
7.8k
テレワーク化を進めるミツイワ様でAmazon WorkSpacesの支援をした事例紹介
snakagawax227
1
1.7k
AKIBA.AWS#14_AWS_Config_Update
snakagawax227
0
1.1k
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Designing for Performance
lara
604
68k
Adopting Sorbet at Scale
ufuk
74
9.2k
GitHub's CSS Performance
jonrohan
1030
460k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Rails Girls Zürich Keynote
gr2m
94
13k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Transcript
2025/02/18 札幌IT⽯狩鍋#1 中川翔太 Amazon Aurora DSQL の勘所
⾃⼰紹介 中川 翔太(Shota Nakagawa) クラスメソッド株式会社 クラウド事業本部コンサルティング部 ソリューションアーキテクト 仕事:AWS全般のお悩み相談 略歴:N/W製品ヘルプデスク→AWS運⽤→現職 趣味:道の駅巡り、ダーツ
アジェンダ • Amazon Aurora DSQL とは • Amazon Aurora DSQL
の考慮事項 • まとめ
Amazon Aurora DSQL とは
昨年末にAWSのイベントで発表されました 内容を⼊⼒してください
Amazon Aurora DSQL とは • PostgreSQL 互換の分散 SQL DB(いわゆる NewSQL)
• インフラストラクチャの管理なし • 事実上無制限にスケール ◦ クエリ処理, コミット, ストレージの各層で独⽴してスケールする • マルチリージョンで Active/Active 可能で99.999%の⾼可⽤性 ◦ 単⼀リージョンも可能 • 楽観的同時実⾏制御を採⽤ • ユースケース ◦ 規模の⼤⼩関係なく様々なワークロードから使⽤可能 ◦ VPCを必要としないのでLambdaなどサーバレス利⽤と相性いい • 2025年2⽉17⽇時点でプレビュー • プレビュー期間中は無料で利⽤可能
アーキテクチャ https://aws.amazon.com/jp/blogs/database/introducing-amazon-aurora-dsql/
楽観的同時実⾏制御 楽観的同時実⾏制御(OCC)を採⽤して⾼い書き込みスループットを実現 • OCCはトランザクションがデータをロックせずに処理を⾏い、コミット時に 競合をチェックする⽅法 • 競合があった場合はコミットせずにアボート(中断)する • 他のトランザクションと競合する可能性は低いという前提 •
多くのRDBで採⽤されている悲観的同時実⾏制御はロックすることで常に⼀ 貫性が保証されている。⼀⽅でスループットや並列性が低下します
他社DBと⽐較して4倍⾼速
Amazon Aurora DSQL の考慮事項
ケース1. 在庫管理システムで購⼊処理が競合 ECサイトでスニーカーの在庫が1点のとき、2⼈の購⼊者が同時に購⼊しようとした 競合エラー発⽣
ケース1. 在庫管理システムで購⼊処理が競合 • 何が起きた? ◦ 購⼊者A, Bのトランザクションが同時に在庫データを読み取り、Bが先に UPDATEをコミットすることで在庫を0に更新 ◦ 購⼊者Aのトランザクションが更新を試みた際、⾃⾝が読み取った時点
のデータが変更されていることを検知し、OCC例外が発⽣ • どうするべきか? ◦ 書き込みトランザクションは失敗する可能性がある前提に設計 ▪ リトライできるように ▪ 多い場合は間隔をランダムに(Exponential Backoff and Jitter) ▪ 最⼤クエリ時間を考慮したタイムアウトを実装 ◦ データモデリングを⾒直す ▪ 競合が起きやすい箇所(ホットスポット)を避ける設計 ▪ 例)購⼊記録を追加するDB、在庫管理は集計する
ケース2:病院の当直管理でシフトのキャンセルが重なった 最低必要⼈数を下回った 病院の当直シフト管理システムで、最低2名以上の当直医が必要なところ、3名の当 直予定者から2名が同時にキャンセルを申請した
ケース2:病院の当直管理でシフトのキャンセルが重なった FOR UPDATE FOR UPDATE • 医師A, Bが同時に当直医師数を確認し、異 なるシフトレコードを更新した結果、個々 の更新は成功するものの、意図せず最低必
要⼈数を下回ってしまう状態となった(ラ イトスキュー)。 • 参照時点で関連データ全体をロック (SELECT FOR UPDATE)することで、2つ ⽬のトランザクションを早期に失敗させ、 意図しない更新を防ぐ。
他に気をつけること • 主キーを分散した設計にする ◦ UUIDのようにランダム性のある値を使⽤する ◦ パーティショニングやスケーリングで使⽤されるためパフォーマンスに 影響する • 事前に制約を確認する
◦ PostgreSQL互換とはいえ制約は多い ◦ 例)外部キー制約が現状サポートされていない ▪ 関連データを⾮同期で更新するようにする
まとめ
まとめ • Amazon Aurora DSQLはサーバレスな分散SQLデータベース • 楽観的同時実⾏制御を採⽤して⾼い書き込みスループットを実現 • その代わり、トランザクションの競合を避けるリトライ処理やホットスポッ トを避ける設計が必要
• プレビュー期間中は無料で試せますので是⾮お試しください!
参考
参考URL • Amazon Aurora DSQL • Concurrency control in Amazon
Aurora DSQL • Introducing Amazon Aurora DSQL • DSQL Vignette: Transactions and Durability • AWS re:Invent ふりかえり勉強会「クラスメソッド re:Growth 2024 東京」 で Aurora DSQL を話してきました! • Aurora DSQLの楽観同時実⾏制御を⼿を動かして学ぶ • Amazon Aurora DSQLの主キーで気をつけるべきこと • NewSQLなんも分からん⼈がゼロからAmazon Aurora DSQLを理解する(前 編) • NewSQLなんも分からん⼈がゼロからAmazon Aurora DSQLを理解する(後 編)
None