Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか

2025/9/3に開催されたDevelopersIO 2025の登壇資料です。
https://classmethod.connpass.com/event/361520/

発表時間の都合上当日は削った内容も追記したバージョンの資料をUPしています。

Transcript

1. Aurora DSQLは サーバーレスアーキテクチャの 常識を変えるのか？ 岩⽥ 智哉 リテールアプリ共創部
2. 注意事項 2 スライドは後ほど ブログで共有します
3. ⾃⼰紹介 3 • 2018年 ⼊社 ◦ サーバーレス開発部 ◦ Lambda × DynamoDB案件 • 2019年 ◦ 初のVPC Lambda × RDS案件 • 2020年 ◦ Fargate × RDS案件など • 2025年 ◦ オフショア開発のアーキテクト • 部署 ◦ リテールアプリ共創部 • 名前 ◦ 岩⽥ 智哉 • 好きなAWSサービス ◦ Lambda
4. 前提条件 4 本セッションでは、コンピューティングレイヤに AWS Lambdaを採⽤するアーキテクチャを 「サーバーレスアーキテクチャ」 と呼ぶこととします
5. サーバーレスアーキテクチャにおける データストアの選定
6. 代表的なデータストア 6 Amazon DynamoDB Amazon Aurora RDS Data API RDS Proxy Aurora Serverless Limitless Database
7. Amazon DynamoDB 7 • サーバーレスにおけるファーストチョイス • VPC不要 • オンデマンドモードで⾃動スケール • クエリでできることが限定的 ◦ JOINできない、集計できない ◦ 必要に応じてCQRSなど検討
8. Amazon Aurora 8 • データストアとしての汎⽤性は抜群 • VPCが必要 • ステートレスなLambdaとの相性問題 • 接続の管理が⾯倒 • 書き込みのスケールアウトに課題
9. Amazon Aurora × Data API 9 • DBドライバ無しでAWS SDKだけでクエリが可能 • トランザクションは⾃分で管理 ◦ BeginTransactionで発⾏されたトランザクションID を指定して後続処理を実⾏ • レスポンスは最⼤1,000⾏まで • ORMの互換性に難あり
10. Amazon Aurora × RDS Proxy 10 • コスト増 • ピン留めへの考慮が必要 ◦ 拡張クエリプロトコルがピン留め対象外となり、⼤き く改善された • LambdaとRDSの相性問題を「緩和」するが「解消」は しない
11. Amazon Aurora Serverless 11 • オートスケール ◦ v2になってスケールの速度も改善 • コスト削減を期待したのに逆にコスト増になることも ◦ ACU 0にも対応したが、⼀時停⽌→再接続に15秒以上 かかることも
12. Amazon Aurora PostgreSQL Limitless Database 12 • ⾃動シャーディングで書き込みがスケールする • ⼤規模環境向け ◦ 気軽に検証できる料⾦ではない https://dev.classmethod.jp/articles/calculateamazon-aurora-limitless-database-costs
13. メリット/デメリット⾊々 万能の選択肢はない 13
14. Aurora DSQL
15. re:Invent 2024 Keynoteにて発表 15 PostgreSQL互換のサーバーレス分散 SQL データベース
16. Mark Brooker⽒が開発に関わる 16 Lambdaユーザーの要望に応えるデータベースとしてDSQLを開発 https://youtu.be/-oHHwuFDKwE?si=yU1X6GSPPINYMHlN
17. インフラの意識は不要！！ 17 • 良くも悪くも設定項⽬が少ない ◦ パラメータグループも無いので、パラメータチューニ ングに悩むことは無い • クラスタは⼀瞬で起動 • メンテナンスウィンドウやバージョンアップグレードと いった概念も存在しない
18. Aurora DSQLは従来のAuroraを 置き換えるのか？
19. 制限事項は多い 19 単純にAurora PostgreSQLをDSQLに置き換えると動かない 処理がたくさん出てくる 「PostgreSQLと互換性がある」 ...PostgreSQLのワイヤプロトコルが利⽤できると捉えるの が良さそう
20. 制限事項の具体例(主に開発⽬線) 20 • PostgreSQLのExtension利⽤不可 • 外部キー利⽤不可 • シーケンス利⽤不可 • ロックを取得しない(楽観的同時実⾏制御) • トランザクションの上限 ◦ 最⼤5分 ◦ 変更可能なデータは最⼤3,000レコード、10MiB https://dev.classmethod.jp/articles/aurora-dsql-non-support/ https://docs.aws.amazon.com/ja_jp/aurora-dsql/latest/userguide/CHAP_quotas.html
21. 接続(コネクション)関連
22. DSQLの制限事項 22 • 接続にはパスワードではなく⼀時トークンを利⽤ • クラスターあたりの最⼤接続レート 100 接続/秒 ◦ クラスターあたりの最⼤接続バーストキャパシティ 1,000接続 ◦ 接続のリフィルレート 100接続/秒 • クラスターあたりの最⼤接続数 10,000 接続 • 最⼤接続時間 60分
23. Lambdaの⼤量起動&接続に耐えられるのか？ 23 https://dev.classmethod.jp/articles/connect-dsql-from-many-concurrency-lambda/ Lambdaの同時実⾏数7,000、25万リクエストの約6%でエラー
24. • Lambdaの上限緩和申請を⾏っていない環境では問題なし • 接続レートもバーストしてくれるので、相当スパイクしない限り はエラーになることは無い DSQLのスパイク耐性 24
25. Lambdaの実装例 25
26. NG例 26 //...略 const client = new Client({ //...略 }); await client.connect(); export const handler = async (event, context) => { // クエリを発行する処理 }; 60分後に接続が切れる
27. パフォーマンス最適でない例 27 export const handler = async (event, context) => { const token = await signer.getDbConnectAuthToken(); await client.connect(); await client.query("SELECT now()"); await client.end(); }; • スパイク耐性が低い • 毎回接続のオーバーヘッドが発⽣する
28. オススメ 28 const getToken = async () => { return ...略 } const pool = new Pool({ password: getToken, maxLifetimeSeconds: 60 * 50, //略 }); export const handler = async (event, context) => { await pool.query("SELECT ...略"); }; • コネクションプールを活⽤ • 接続が切れたらor 切れる前に再接続
29. トランザクション関連の 考慮事項
30. トランザクション関連の制限事項 30 トランザクションブロックで変更できるテーブル行とイ ンデックス行の最大数 3,000 行/トランザクション 書き込みトランザクションで変更されたすべてのデー タの最大サイズ 10 MiB クエリオペレーションで使用できるメモリの基本最大 量 128 MiB 最大トランザクション時間 5分 https://docs.aws.amazon.com/ja_jp/aurora-dsql/latest/userguide/CHAP_quotas.html
31. ロックが無い 31 ロックが使える通常のAuroraの場合 BEGIN; SELECT 在庫... FOR UPDATE; ...ロック待ち ...ロック待ち ...ロック待ち ...ロック待ち INSERT INTO 受注...; INSERT INTO 受注明細...; UPDATE 在庫...; COMMIT; BEGIN; SELECT 在庫... FOR UPDATE; INSERT INTO 受注...; INSERT INTO 受注明細...; UPDATE 在庫...; COMMIT;
32. ロックが無い 32 DSQLの場合 BEGIN; SELECT 在庫... FOR UPDATE; INSERT INTO 受注...; INSERT INTO 受注明細...; UPDATE 在庫...; COMMIT → エラー ERROR: change conflicts with another transaction, please retry: (OC000) BEGIN; SELECT 在庫... FOR UPDATE; INSERT INTO 受注...; INSERT INTO 受注明細...; UPDATE 在庫...; COMMIT;
33. 後はコミットするだけ...でもエラー 33 BEGIN; INSERT INTO...; UPDATE ...; UPDATE ... SET 外部API処理済み = 1; -- 外部API呼び出し COMMIT; ERROR: change conflicts with another transaction, please retry: (OC000)
34. 楽観的同時実⾏制御を意識した実装が必要 34 • コミット時にエラーになる ◦ コミット時のエラーハンドリング必須 ◦ 適宜リトライを⼊れる ◦ どの操作が競合したか判断できない
35. コストはどうなる？
36. • DPU：$10.00/100万ユニット • ストレージ：$0.40/GB-⽉ ※DynamoDB Standardは$0.285/GB-⽉ • データ転送料⾦: EC2データ転送料⾦ • バックアップ:$0.12/GB-⽉ or $0.036/GB-⽉ • リストア: $0.024/GB or $0.0036/GB DSQLの料⾦体系 36 ※東京リージョンの場合  ※バックアップ、リストアはWarm or Coldで料⾦が異なる
37. • 作業量を表す論理的な指標 • クエリを実⾏するためのコンピューティングリソース、 ストレージのIOを含む • DynamoDBのWRU/RRUのように試算できるものではない DPUとは？？ 37
38. 10万レコードをスキャンして最⼤値取得 38 SELECT MAX(abalance) from pgbench_accounts;
39. 10万レコードのクラスターインデックスから最⼤値を取得 39 SELECT MAX(aid) from pgbench_accounts; アクセスパスが効率的ならDPU消費も減る
40. CTEで100万レコード⽣成して最⼤値取得 40 10万レコードのクラスターインデックスから最⼤値を取得 WITH RECURSIVE v1 (n) AS ( SELECT 1 UNION ALL SELECT n + 1 FROM v1 WHERE n < 1000000 ) SELECT max(n) FROM v1
41. CROSS JOINで100万レコード⽣成して最⼤値取得 41 10万レコードのクラスターインデックスから最⼤値を取得 SELECT MAX(aid) FROM (SELECT * FROM pgbench_accounts LIMIT 100) a CROSS JOIN (SELECT * FROM pgbench_accounts LIMIT 100) b CROSS JOIN (SELECT * FROM pgbench_accounts LIMIT 100) c
42. pgbenchのテーブルリストア時のDPU消費 42 • pgbench_accounts 10万件 • pgbench_branches 1件 • pgbench_history 0件 • pgbench_tellers 10件 ※COPYが使えないのでINSERT⽂を10万11回実⾏ 合計するとこちら
43. その他気になるところ
44. • PostgreSQL on Dockerだと⾮互換の部分も多い • DynamoDB Localのようなツールは存在せず • インターネット経由でDSQLをそのまま利⽤するのが良さそう ◦ 良くも悪くも従量課⾦なことには注意 開発時の考慮事項 44
45. • DSQLに対応したツールはあるのか？？ マイグレーションはどうする？ 45 https://dev.classmethod.jp/articles/reinvent-dsql-drizzle-lambda-migration/ https://github.com/drizzle-team/drizzle-orm/issues/1267
46. まとめ
47. https://docs.aws.amazon.com/ja_jp/aurora-dsql/latest/userguide/what-is-aurora-dsql.html 公式ドキュメントより 47
48. • DSQLは他のデータストアの上位互換ではない • 良いサービスであることに間違いは無いが、あくまで 選択肢の1つ • 制限事項について良く理解した上で採⽤しよう まとめ 48