3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

今年勉強会などで Aurora DSQL に関して話したことの振り返り

3
Last updated at Posted at 2025-12-07

これは PostgreSQL Advent Calendar 2025 シリーズ 1・8 日目のエントリです。

昨日(7 日目)は yaju さんでした。


ひとりアドベントカレンダーで今年の登壇+αを振り返っているので(ひっそりと書いているのでカレンダーは探さないでください)、こちらでは Aurora DSQL に関する勉強会などでの登壇をまとめて振り返ることにします。

Aurora DSQL とは

AWS 公式ユーザーガイドには、

Amazon Aurora DSQL は、トランザクションワークロード用に最適化されたサーバーレスの分散リレーショナルデータベースサービスです。Aurora DSQL は実質的に無制限のスケールを提供し、インフラストラクチャを管理する必要はありません。アクティブ/アクティブ高可用性アーキテクチャは、99.99% の単一リージョンと 99.999% のマルチリージョンの可用性を提供します。

と書かれています。

PostgreSQL とはどんな関係があるの?

こちらもAWS 公式ユーザーガイドに、

Aurora DSQL は、トランザクションワークロード用に設計された PostgreSQL 互換の分散リレーショナルデータベースです。Aurora DSQL は、パーサ、プランナー、オプティマイザー、型システムなどの主要な PostgreSQL コンポーネントを使用します。

Aurora DSQL 設計により、サポートされているすべての PostgreSQL 構文によって互換性のある動作が提供されるため、同一のクエリ結果が得られます。例えば、Aurora DSQL は PostgreSQL と同様の型変換、算術演算、数値の精度とスケールを提供します。偏差は文書化されます。

(ちょっと機械翻訳が変ですが、「偏差は文書化されます」ではなくて「差異は文書化されています」ですね)

なんで Aurora DSQL をネタに?

まあただの興味本位であって実務で使う予定も何もなかったのですが。

先ほどの AWS 公式ユーザーガイドの続きに、「アーキテクチャ上の主な相違点」というセクションがあり、

オプティミスティック同時実行制御 (OCC)
Aurora DSQL は、オプティミスティック同時実行制御モデルを使用します。このロックフリーアプローチにより、トランザクションが互いにブロックされるのを防ぎ、デッドロックを排除し、高スループットの並列実行を可能にします。これらの機能により、Aurora DSQL は大規模で一貫したパフォーマンスを必要とするアプリケーションに特に役立ちます。その他の例については、「Aurora DSQL での同時実行制御」を参照してください。

とあるとおり、 OCC(楽観的同時実行制御)を採用していたこと が大きなポイントでした。

(「とりあえずコミット失敗したらリトライしとけば良いんでしょ?」で罠にハマるのが目に見えている)

なので、発表・登壇はすべて OCC 絡みの話となります。

発表・登壇振り返り

JAWS-UG 浜松 x Media-JAWS 合同 AWS 勉強会 202501(1/23)

まだプレビューのときの話です。実は昨年末に名古屋の reCap で 2 回ほど話した内容を概ねそのまま持ってきました。

(なので細かい話はパスで)

JAWS ミート 2025(7/5)

LT 枠に直前キャンセルが出て、その穴埋めのために即興でゲームを作りました。

というのは半分嘘で、ほとんど Amazon Q CLI に作ってもらいました。

そしてそのゲームで Aurora DSQL の OCC を参加者の皆さんに体感していただきました。

image.png
image.png
image.png
image.png
image.png

少しトラブルがありつつもゲームは好評でした。

image.png
image.png
image.png
image.png
image.png
image.png

しかし、勝者すら「なぜ自分が勝てたのか」がわかっていませんでしたw

というわけで「次」に続きます。

俺の勉強会 #3(8/4)

JAWS ミート 2025 の後、結果の考察を Qiita 記事として書きました。

この記事についての解説…だったのですが、資料に必要なページを入れ忘れるという失態を犯し、5 分の LT のところ 4 分未満で終わってしまいました。

image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png

2 ページ入れ忘れたのならその分ゆっくり話せば良かったのですが、普通に「ライトニング」トークしたので時間を余らせてしまいました。

JAWS FESTA 2025 in Kanazawa の CfP に応募

岩手に出かけていて、昼ごはんまでの待ち時間にプロポーザルを書いて提出しました。

早めに出したことが良かったのか、後日、無事採択されました。

(内容は後ほど)

【オンライン】佐賀の中心で AWS を叫ぶ(8/11)

こちらは資料なしの飛び入り登壇でした(登壇予定の方が体調不良で欠席されて時間が余ったため)。

ここで「俺の勉強会 #3」のリベンジとして、Qiita 記事を参照しながら内容の説明を行いました。

(内容としては「俺の勉強会 #3」とほぼ同じなのでパスします)

クラウド LT 大会 vol.14 フリーテーマ!(8/21)

先の「結果ログから考察」を 2 回話してみて、「やはり図がないと理解が難しそうだな」と感じたので、「どのトランザクションが成功してどのトランザクションが失敗するのか」がわかりやすいように図示しました。

image.png

資料には図のページの次に SQL 文の実行結果を示すページを入れていますが、ここでは省略します。以降同様。

image.png
image.png

このあたりはどのトランザクションが成功するのかわかりづらいかもしれません。

image.png

RDBMS によっては「更新(書き込み)トランザクションの始点はBEGINではなくUPDATEINSERTなど」のケースもあるので間違いそうですね。

image.png
image.png

落ち着いて考えればわかるのですがいきなり聞かれてもどれが成功してどれが失敗するのか即答できないかもしれません。

image.png

ちょっと例題がわかりづらい?

image.png
image.png
image.png

図示は良かったものの、少し詰め込みすぎました。

image.png

JAWS FESTA 2025 in Kanazawa(10/11)

「クラウド LT 大会 vol.14 フリーテーマ!」の資料を再構成・加筆する形で資料を作成しました。

前登壇者からの入れ替わり時間を含めて 20 分枠、最初から全てのページを話しきれない想定で臨みましたが、やはり話が中途半端になってしまいました。

image.png
image.png

「クラウド LT 大会 vol.14 フリーテーマ!」と同様のページは省略します。

image.png

オートコミットも「単一の SQL 文だけを実行するトランザクション」なんですよね。当然競合します。

image.png
image.png

「代用」の話、普通はやらないのですがたまにこれを実装してしまう人が…?

image.png
image.png
image.png

「3,000 行の制限」はあまり知られていないかもしれません。

image.png
image.png

「実行順」の話、意外と大事。

この後

BuriKaigi 2026 にも Aurora DSQL ネタのプロポーザルを出しましたが落ちました。

というわけで、私の「Aurora DSQL ネタの 1 年」はここで終わりました。

おつかれさまでした。


明日(9 日目)は jri_narita さんです。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?