DSQL in Action

- [Amazon Aurora DSQL Day Tokyo](https://aws-experience.com/apj/smb/event/04342c63-337e-495b-94af-579a610383f7)
-[Aurora DSQL の現状 2026 \(Rails の場合\) \| diary\.sorah](https://diary.sorah.jp/2026/09/03/dsql-in-action)

1. 実践 Aurora DSQL + Rails Sorah Fukumori sorah@ivry.jp https://sorah.jp/ @ Amazon Aurora DSQL Day Tokyo 2026-09-14
2. Who am I • Sorah Fukumori (そらは) https://sorah.jp • IVRy Inc. Principal Software Engineer • Ex: Cookpad Inc. (~ - ) • 最近はプロダクトで利 する customer-facing な IAM 基盤を担当 • 好きなAWSサービス: AWS IAM, STS, Step Functions 3 0 5 用 2 0 2 • その他: RubyKaigi organizer, Ruby committer
3. Agenda • Ruby on Rails で実際に DSQL を利 したシステムを開発する中で、 DSQL 特有の課題や解決策を紹介します • DSQLへの接続 • 実践OCC • スキーマ定義 • ローカル開発 • CI/テスト 用 行 • データ移
4. Agenda • 本トークの内容は事前にブログである程度公開 • スライドも公開予定 • https://diary.sorah.jp/ / / /dsql-in-action • Rails と いながら Rails なコードはあまり出しません 見 3 0 9 0 6 2 0 2 見 言 • 実際のコードを たければブログを併せて てください
5. Recap: Amazon Aurora DSQL の特徴 • 本 のイベントで既に話されている内容もあるので軽く • OCC (Optimistic Concurrency Control) による競合チェックであ り、ロックが存在しないデータベースエンジン • トランザクションは待ちではなく失敗になる事が通常の PostgreSQL より多い 日 • DynamoDBのようにサーバーレスなデータベースサービス
6. DSQL への接続
7. DSQL への接続 • DSQL 認証を理解する • DSQL がサポートしていない SQL 機能や構 、プロトコルがある 文 • DSQL のセッションに課されている特性を理解する
8. DSQL の認証 • IAM 認証しかサポートしていない • Aurora PostgreSQL や RDS for PostgreSQL とセマンティクスは 緒 • DSQLは別サービスなので? SDK では token generator が異なるので 注意 • AWS SDK for Ruby だと, 一 Aws::RDS::AuthTokenGenerator とAws::DSQL::AuthTokenGenerator
9. DSQL がサポートしていない構文や機能がある • Web Framework や ORM を利 する場合に注意が必要 • たとえば Ruby の pg や Rails の ActiveRecord の場合: • SET client_min_messages, standard_conforming_strings • advisory_locks 用 • transaction DDLs
10. • , max connections per cluster • new connections per second per cluster • minutes max connection time • これについてはコネクションプールで明確に max age の設定 をオススメ • 参考: https://aws.amazon.com/blogs/database/connection- 0 0 0 0 0 0 pooling-strategies-in-amazon-aurora-dsql/ 0 1 1 6 DSQL 接続セッションの制限を理解する
11. 公式サンプルを確認しよう • aws-samples/aurora-dsql-samples に多数の事例あり! • これに従っておけば基本的にはOKのはず • Rails の場合、Rails 体へのパッチもいくつかあって Rails . には 取り込まれていないので、モンキーパッチとして先 のをオススメ して取り込む 1 8 行 自 • 先に紹介したブログからリンクされてます
12. 実践 OCC
13. OCC を意識しつつ楽にコードを書く • Rails の場合 ApplicationRecord.transaction { … } ブロックでトラン ザクションを利 するのが 般的 • 素直に書くと COMMIT 時の OCC エラーを吸収できない • → 拡張として .retryable_transaction メソッドを定義して、OCC エ ラー時は backo しつつ 動リトライするように • 通常の .transaction は custom lint rule で禁 止 一 自 用 ff 自 (リトライしたくない場合は .non_idempotent_transaction とい う同じく 前定義のエイリアスを呼び出してもらう)
14. • このようにトランザクション単体で 動リトライする際は、たとえ ば HTTP リクエスト全体をリトライする訳ではない点に注意 • OCCエラーが起きる → 副作 がある処理なので全体をリトライす るのはそもそも難しい • この場合トランザクション外で SELECT したデータをそのまま再利 しないように注意が必要 • そもそもトランザクション内で SELECT しなければ OCC も効かな 自 い 用 用 OCC と自動リトライ
15. 競合をそもそも避ける • ユーザー操作によって更新される users.last_activity_at のようなカ ラムがあった • 平 して発 する HTTP API 呼び出しで書き込み競合が発 • 対応: • 書き込みを 同期ジョブに移す • データの解像度を落とす (1分以内に更新されてたら無視) 生 非 生 行 • テーブルもある程度分割するのが良さそう
16. • OCC の競合判定は BEGIN 〜 COMMIT 間の実時間中に起きた変更へ われる • 従ってトランザクションの実時間は短ければ短いほど競合する可能性が低くなる • DSQL はトランザクションサイズにも制約があるので さければ さいほうが 良いとも える • atomic に反映させる必要があるなかで最 の単位で分割する • その場合、中途半端に処理が終了する可能性もあり、冪等ならそれが望ましい • あと時間のかかる計算をトランザクション内で実 しないみたいな 夫 • 工 行 小 小 行 行 小 でクエリしたデータに依存する処理なら内で実 する必要がある 言 方 一 トランザクションを短時間にする
17. • Rails ではモデル内やサービスクラス内でも必要に応じて transaction ブロックを利 • するのが 般的(のはず) 動で savepoint などを利 した nested transaction になる • DSQL は SAVEPOINT 未実装のため、雑に transaction で囲めない • 基本的には controller (API endpoint) で transaction を開きそれ以 下では避けるようにコードを書いている • サービスクラスが開きたくなる場合もあり、その場合は呼び出し元 用 一 ではtransactionを使わないという契約にして調整 用 自 Nested transaction (SAVEPOINT) がない
18. スキーマ定義
19. • ここ半年ほどの機能拡張で 戻りが難しい DSQL の制限は減った • つい最近まで DROP COLUMN も DEFAULT の変更もできなかった • 今は NOT NULL の変更、NOT NULL カラムの追加、データ型変更が きな制約 • 実際は Nullable でないけど not null はついてません、という事は してしまいやすい 手 較的発 生 比 大 後から修正が難しいポイントを理解する
20. • 前述の制約や OCC の兼ね合いで、1つのテーブルはある程度 さく したほうが柔軟に動きやすい • ORM が全カラムを SELECT するというのもあり、 分はDSQLに よらずなるべく • さめに寄せがちではある cluster あたり max table は 1,000 なので注意 • json, jsonb カラムが出たこと、expression index もあること、とい 小 かもしれない 自 手 うのでそのへんを組み合わせるのもいい 小 1 テーブルを小さくしておく
21. 部分インデックスはない • PostgreSQL でたびたび使われる partial index のサポートはない • NULLS NOT DISTINCT は登場した • Expression index で workaround はできるかも? 目 小 • Index size を さくするという 的ではつかえないけど
22. Schema Migration (1) • PostgreSQL の拡張ポイントを適切に利 していることによる混乱 や、CREATE INDEX ASYNC という独 法による苦しみがあります • Index アクセスメソッドが using index_btree • Primary key が clustered index になる • DDL は 1 transaction つまで • できれば知らずに済ませたかったAurora DSQL 互換集 - ArkEdge Space Blog 用 文 4 / 自 4 7 / 4 6 非 1 8 / 2 0 1 5 2 0 2 1 https://blog.arkedge.space/entry/
23. Schema Migration with psqldef • 当社でDSQLを採 したシステムでは sqldef を利 • わたしの PR # で CREATE INDEX ASYNC 法をサポート (.sql 定義として読めるようにしたけど、concurrently と同じく con g で 動変換でも良かったかも……) 用 文 用 3 用 0 9 自 fi • transactionを利 しないように設定する必要あり
24. 非adminがpublicスキーマに CREATE TABLE できない • PostgreSQL からのCVE- - 対応と同じ仕様と推察 8 5 0 1 8 方 1 0 2 用 5 1 • public schema は利 しない 向で対応した
25. DDL による OCC エラー • DDL 体も OCC エラーを発 させます • CREATE INDEX ASYNC のジョブ完了時も発 します • sqldef のようなツールも OCC エラーが起きたらリトライするよう にしておく必要がある 生 1 0 0 0 0 0 自 や OC 朴な実装をした があったらリトライしてみる、という素 生 • ログに OC
26. CREATE INDEX ASYNC を待つ • ASYNC の 字が すように 同期で実 される • Unique index の作成も 同期なので、アプリケーションプロセスの 更新はしっかり作成が完了するのを待ち合わせた が安全 • sys.wait_for_job() 関数が 意されているが、psqldef から job id を 取り出すのが 倒なこと、複数の index 作成が同時に るため、 pg_index テーブルや sys.jobs テーブルをポーリングしている 走 方 行 非 用 非 示 面 文 文 • (SQL はブログを参照のこと)
27. ローカル開発
28. DSQL Local は存在しない • DynamoDB で うところの DSQL Local は存在しない • きっといつか DSQL Local が出ると信じて、 旦本物の DSQL を ローカル開発にも利 するを選択した • 主な違いはカラムに使えないデータ型や OCC になりそう • そもそも他の AWS サービスを利 するコードもある • 開発者ロールは sorah/mairu で AWS SSO からのロールを付与、 一 用 用 言 Coding agent にも与える
29. • Git clone してきて setup を実 すると、開発 DSQL クラスタを検 出してスキーマ作成 設定を保存するようになっている • cluster あたりの schema 数制限があるため、複数 用 用 用 行 • Devin 等は CI と同じ(後述) 仕組みを利 ・ 1 各ユーザーの schema を準備 意
30. 自動テストとCI
31. テストでも OCC 競合は発生する • DDL が OCC 競合を発 させるため • クラスタを共有しているため別 schema での変更で発 すること がある • CI akiness に繋がらないよう、RSpec の around hook で 動検 自 れている 生 入 リトライされるような実装を 生 fl ・ 知
32. SAVEPOINTがなくて辛い • Rails は use_transactional_ xtures がデフォルトで、COMMIT しな い transaction を利 してユニットテストごとのデータ分離をして いる • これは nested transaction を前提にしてしまっている • → アプリ実装側で transaction が使えなくなってしまう fi 用 • 諦めて無効化し、都度 DELETE するように。なおTRUNCATEはない
33. • ORMモデルのテストなど実装側に transaction が らない場合は利 する • RSpec の example group に :batch_transactions アノテーションを れると勝 に transaction が作られるような仕組みを れている • use_transactional_ xtures はテストスイート全体で有効にする 入 入 fi かしか決められないため 手 入 用 とは言え使えるところでは使う
34. タイムトラベルに注意 • IAM 認証というか SigV といったリクエスト署名は現在時刻に依存 している • 現在時刻を操作するようなテストではそれによって DSQL への接続 に失敗することがある • Rails標準の TimeHelper ではなく Timecop というライブラリへ変 更した 4 一 • TimeHelper は 時的に影響を除外することができなかったため
35. CI も本物の DSQL を利用 • ローカル開発と同様の理由で本物の DSQL を利 • CI は GitHub Actions で GitHub-hosted Runner 用 米 • GitHub-hosted runner は Azure の北 リージョンにある
36. AWS region の自動選択 • SQLのRTTが ければ いほどCIが遅くなるため、近いDSQLクラス タを使いたい • → Route Latency Based Routing で AWS region 基準で近いレ コードを返せる • SRVレコードでActions runnerから た近いクラスタの 覧を返 一 見 長 長 3 5 している
37. Azure Regions (北米)
38. + DSQL Regions (ざっくり)
39. AWS regions は Azure regions より少ない • DSQL があるリージョンに限るともっと少ない • 実測ベースで実際にさまざまな Azure リージョンが使われているこ とを確認している • Azure eastus → AWS us-east- の RTT ms 程度に対して westcentralus → us-west- の 42ms まで幅がある 6 1 2 • ペアごとの平均をとるとだいたい 20ms 前後
40. テスト時間計測の標準化 • Nested Transaction が使えないことを含め本物の DSQL を CI に利 するとそれなりに遅い • 仕 ないとは え気合で乗り切る • GitHub Actions の matrix でテストを分割し並列実 • ファイルごとの実 時間を保存してそれぞれのジョブが同じくらい の速度で終わるように調整するライブラリがある • DSQLまでのRTTでブレてしまうため、SELECT NOW(); の RTT を計測 用 っている 行 入 行 言 方 して normalise する実装が
41. • 実はDDLもそれなりに遅い • tables, indices 程度で psqldef の実 に 1 分半かかる • そのうち50秒は CREATE INDEX ASYNC ジョブの待ち • US リージョンに cluster と schema を 量に作成しておくことに • GitHub Actions と DSQL 内のスキーマ管理 テーブルで管理 • *.sql ファイルが更新されたら 動で全schemaを更新 用 行 大 自 6 5 • 壊れたりCIが終わったら DROP SCHEMA して再作成 2 3 スキーマを事前に作成しておく
44. データ移行
45. データ移行 (1) • 今回 DSQL を利 して開発したシステムは既存のモノリスからの データ移 が必要だった。Aurora PostgreSQL からデータを継続的 に書き込む必要がある • AWS DMS + KDS + Lambda を採 • 前職で採 実績 • DMS を利 した継続的なデータ変更検知 - クックパッド開発者ブログ 5 / 0 6 1 / 0 1 6 / 1 0 1 用 4 2 0 2 用 行 用 用 https://techlife.cookpad.com/entry/
46. データ移行 (2) • システム移 期間中はデータを書き戻さなければいけないシーンが 若 ある • なるべく必要ないようにする 向で取り組んでいるが… • Writeback が必要になった場合、DSQL で最近 GA になった CDC が KDS に流せるのでそうすることになるだろう 方 行 干 • ループにならないように気をつける必要がある
47. まとめ
48. まとめ • OCC や SAVEPOINT がないといったポイントがやはりハマりどころ • 現状はローカル開発や CI で 倒が発 しがち。レイテンシは い • ここ半年でデータ型の拡張や機能拡張がたくさん っている。 今後に期待 • production に出す前に JSON 型が間に合ってよかった • IVRy はプロダクトを IAM や課 から開発者体験まで える Platform Engineer を積極採 中 辛 支 用 入 生 金 面 方 用 • Product/Corporate 両 で Security Engineer も採 中!