予約サイトを実装して理解する Aurora DSQL by hmatsu47(まつ)

2024 年の re:Invent で発表され、2025 年 5 月に GA（一般提供開始）となった Aurora DSQL。Google Spanner 対抗（？）のサーバーレス分散 SQL データベースとして注目を集めた割に、（2025 年 10 月中旬時点では）具体的な採用事例の話はほとんど聞きません。その一方で「従来の Aurora PostgreSQL から移行する形で採用しようとして失敗した」というネガティブな話は聞こえてきたりします。

（たぶんそれ、目的・用途に合わせたデータベース選定になっていなかったんじゃないかと…？）

私自身は、これまで「ゲームで体感！Aurora DSQL の OCC」（JAWS ミート 2025）や「攻略！Aurora DSQL の OCC」（JAWS FESTA 2025 in 金沢）などのセッションを通じて、Aurora DSQL のキモである OCC（楽観的同時実行制御）の特性を紹介・説明してきましたが、参加者の反応などから、やはり具体的なアプリケーションの実装例が示されないと理解が難しい印象を受けました。

というわけで、今回は架空の予約サイト（例：宿泊予約）の実装に Aurora DSQL を使い、

• 対象（例：人数・日程・プラン）の選択（仮確定）を先着順に処理する【⭐︎1】
• 対象選択後、必要事項（例：氏名・連絡先など）の入力および決済完了まで一時確保する【⭐︎2】
• 必要事項入力・決済完了後に予約を成立させる
• 一時確保の状態のまま一定時間経過したら予約不成立として在庫に戻す

という一連の流れを、NG 実装例と比較しながら説明していきます。

【⭐︎1】 Aurora DSQL では OCC の特性上、同一キーを持つ行を挿入または更新する処理の実行（成功）が「必ずしもトランザクションの開始順・コミット順にならない」という問題があります。
　→参考 : https://www.docswell.com/s/hmatsu47/ZJQYXX-aurora-occ-jaws-festa-20251011#p36

【⭐︎2】 Aurora DSQL には一般的な RDBMS が持つ行ロックの機構がないので、DBMS レベルでのロックを使わず、かつ一時確保した側が優先されるよう排他制御する必要があります。

■想定する参加者

• データベースが好きな方
• データベースは好きじゃないけれど、アプリケーション開発でデータベース周りの処理の実装から逃れられない方
• Aurora DSQL が気になる方
• 業務案件で Aurora DSQL を扱わないといけなくなりそうな方

一見難しそうですが、実際にはあまり高度な技術は使わない想定です。

（実装言語やフレームワーク・ORM（利用有無を含め）などは検討中です）

■注

• こちら↓の記事で扱っている内容とは全く別物・別趣旨です（ちなみにこの記事の著者の方とは知り合いです）
  • https://blog.serverworks.co.jp/_dsql-reservation