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