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