Slide 1

Slide 1 text

2025/02/18 札幌IT⽯狩鍋#1 中川翔太 Amazon Aurora DSQL の勘所

Slide 2

Slide 2 text

⾃⼰紹介 中川 翔太(Shota Nakagawa) クラスメソッド株式会社 クラウド事業本部コンサルティング部 ソリューションアーキテクト 仕事:AWS全般のお悩み相談 略歴:N/W製品ヘルプデスク→AWS運⽤→現職 趣味:道の駅巡り、ダーツ

Slide 3

Slide 3 text

アジェンダ ● Amazon Aurora DSQL とは ● Amazon Aurora DSQL の考慮事項 ● まとめ

Slide 4

Slide 4 text

Amazon Aurora DSQL とは

Slide 5

Slide 5 text

昨年末にAWSのイベントで発表されました 内容を⼊⼒してください

Slide 6

Slide 6 text

Amazon Aurora DSQL とは ● PostgreSQL 互換の分散 SQL DB(いわゆる NewSQL) ● インフラストラクチャの管理なし ● 事実上無制限にスケール ○ クエリ処理, コミット, ストレージの各層で独⽴してスケールする ● マルチリージョンで Active/Active 可能で99.999%の⾼可⽤性 ○ 単⼀リージョンも可能 ● 楽観的同時実⾏制御を採⽤ ● ユースケース ○ 規模の⼤⼩関係なく様々なワークロードから使⽤可能 ○ VPCを必要としないのでLambdaなどサーバレス利⽤と相性いい ● 2025年2⽉17⽇時点でプレビュー ● プレビュー期間中は無料で利⽤可能

Slide 7

Slide 7 text

アーキテクチャ https://aws.amazon.com/jp/blogs/database/introducing-amazon-aurora-dsql/

Slide 8

Slide 8 text

楽観的同時実⾏制御 楽観的同時実⾏制御(OCC)を採⽤して⾼い書き込みスループットを実現 ● OCCはトランザクションがデータをロックせずに処理を⾏い、コミット時に 競合をチェックする⽅法 ● 競合があった場合はコミットせずにアボート(中断)する ● 他のトランザクションと競合する可能性は低いという前提 ● 多くのRDBで採⽤されている悲観的同時実⾏制御はロックすることで常に⼀ 貫性が保証されている。⼀⽅でスループットや並列性が低下します

Slide 9

Slide 9 text

他社DBと⽐較して4倍⾼速

Slide 10

Slide 10 text

Amazon Aurora DSQL の考慮事項

Slide 11

Slide 11 text

ケース1. 在庫管理システムで購⼊処理が競合 ECサイトでスニーカーの在庫が1点のとき、2⼈の購⼊者が同時に購⼊しようとした 競合エラー発⽣

Slide 12

Slide 12 text

ケース1. 在庫管理システムで購⼊処理が競合 ● 何が起きた? ○ 購⼊者A, Bのトランザクションが同時に在庫データを読み取り、Bが先に UPDATEをコミットすることで在庫を0に更新 ○ 購⼊者Aのトランザクションが更新を試みた際、⾃⾝が読み取った時点 のデータが変更されていることを検知し、OCC例外が発⽣ ● どうするべきか? ○ 書き込みトランザクションは失敗する可能性がある前提に設計 ■ リトライできるように ■ 多い場合は間隔をランダムに(Exponential Backoff and Jitter) ■ 最⼤クエリ時間を考慮したタイムアウトを実装 ○ データモデリングを⾒直す ■ 競合が起きやすい箇所(ホットスポット)を避ける設計 ■ 例)購⼊記録を追加するDB、在庫管理は集計する

Slide 13

Slide 13 text

ケース2:病院の当直管理でシフトのキャンセルが重なった 最低必要⼈数を下回った 病院の当直シフト管理システムで、最低2名以上の当直医が必要なところ、3名の当 直予定者から2名が同時にキャンセルを申請した

Slide 14

Slide 14 text

ケース2:病院の当直管理でシフトのキャンセルが重なった FOR UPDATE FOR UPDATE ● 医師A, Bが同時に当直医師数を確認し、異 なるシフトレコードを更新した結果、個々 の更新は成功するものの、意図せず最低必 要⼈数を下回ってしまう状態となった(ラ イトスキュー)。 ● 参照時点で関連データ全体をロック (SELECT FOR UPDATE)することで、2つ ⽬のトランザクションを早期に失敗させ、 意図しない更新を防ぐ。

Slide 15

Slide 15 text

他に気をつけること ● 主キーを分散した設計にする ○ UUIDのようにランダム性のある値を使⽤する ○ パーティショニングやスケーリングで使⽤されるためパフォーマンスに 影響する ● 事前に制約を確認する ○ PostgreSQL互換とはいえ制約は多い ○ 例)外部キー制約が現状サポートされていない ■ 関連データを⾮同期で更新するようにする

Slide 16

Slide 16 text

まとめ

Slide 17

Slide 17 text

まとめ ● Amazon Aurora DSQLはサーバレスな分散SQLデータベース ● 楽観的同時実⾏制御を採⽤して⾼い書き込みスループットを実現 ● その代わり、トランザクションの競合を避けるリトライ処理やホットスポッ トを避ける設計が必要 ● プレビュー期間中は無料で試せますので是⾮お試しください!

Slide 18

Slide 18 text

参考

Slide 19

Slide 19 text

参考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を理解する(後 編)

Slide 20

Slide 20 text

No content