Aurora Distributed SQL vs Aurora Serverless v2 : analyse pratique des coûts

Commençons par regarder les tarifs publiés par AWS pour voir si une comparaison correcte est possible. Spoiler : elle ne l'est pas.

Aurora DSQL

• Compute : facturé à la Distributed Processing Unit (DPU)

- Tarif : 8 $ par million de DPU

- 100 000 DPU ≈ ~700 000 transactions TPC-C (selon les benchmarks AWS)

https://aws.amazon.com/rds/aurora/dsql/pricing/

• Stockage : 0,33 $ par Go-mois
• Offre gratuite : les 100 000 premières DPU et 1 Go-mois de stockage sont offerts chaque mois

Mais qu'est-ce qu'une DPU, au juste ? On retombe dans le même flou que pour les ACU : difficile de cerner ce que cela représente concrètement, n'est-ce pas ?

Comparons avec Aurora Serverless v2.

• Compute : facturé à l'Aurora Capacity Unit (ACU)

- Tarif : 0,12 $ par ACU-heure

- Évolue de 0,5 à 128 ACU, et descend même à 0 en période d'inactivité

• Stockage : deux options :

- Standard : 0,10 $ par Go-mois + 0,20 $ par million d'I/O

- I/O-Optimized : 0,225 $ par Go-mois, sans frais d'I/O distincts

Premier constat : les modèles de facturation diffèrent entre Aurora Serverless v2 et Aurora DSQL. Hormis le stockage, la comparaison directe est donc impossible. Vous noterez que le stockage est près de 50 % plus cher que la version I/O-Optimized, ce qui signifie qu'un système avec un volume de stockage important et un faible volume transactionnel coûtera toujours davantage sur DSQL — et ce, avant même d'aborder la question : qu'est-ce qu'une DPU au juste ? Voyons cela.

Une DPU est l'unité de facturation du compute d'Aurora DSQL. Chaque DPU reflète les ressources mobilisées pour traiter les requêtes distribuées via le moteur d'exécution hautement parallèle d'Aurora. Elle inclut le temps CPU, la consommation mémoire et le travail nécessaire à la récupération et à la manipulation des données.

Les DPU sont fractionnaires et basées sur l'usage : vous n'êtes facturé que pour les ressources de compute réellement consommées. C'est différent des ACU d'Aurora Serverless v2, provisionnées par incréments d'une demi-unité par seconde. Mais comme pour les ACU, il est quasiment impossible d'anticiper sa consommation : la seule façon d'obtenir des estimations fiables est de tester.

Aurora DSQL inclut une offre gratuite chaque mois :

• 100 000 DPU offertes (soit 0,80 $)
• 1 Go-mois de stockage offert (soit 0,33 $)

Soit un total de 1,13 $ d'économies mensuelles — pas vraiment de quoi changer la donne en production, mais parfait pour des workloads de dev/test gratuits. Et sans savoir ce que couvre une DPU, impossible de dire s'il s'agit d'une goutte d'eau dans l'océan ou si cela suffira à couvrir tout votre workload de production. Essayons donc d'obtenir des métriques concrètes.

Pour ce test, nous utiliserons pgbench afin de mettre la base de données sous pression dans un scénario assez réaliste. J'ai utilisé le benchmark TCP-B standard de pgbench et l'ai exécuté avec 100 000 appels de transactions sur chaque base. J'avais commencé par une exécution sur 60 minutes, mais j'ai vite constaté que le throughput de DSQL était tellement inférieur à celui d'ASv2 qu'un article axé coûts perdait son sens. Je reviendrai brièvement sur la performance à la fin.

Voici la commande pgbench si vous souhaitez lancer vos propres tests pour valider. J'ai dû me limiter à un seul client : en raison du verrouillage optimiste (voir mon précédent article — https://engineering.doit.com/aurora-dsql-uncovered-the-future-of-scalable-databases-f2fabcde672a), de nombreux clients généraient des erreurs sur DSQL à cause des conflits, ce qui rendait le test inéquitable entre les deux moteurs :

pgbench -n -p 60 -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -d "$DB_NAME" -c 1 -j 2 -t "$NUMBER_OF_TRANSACTIONS"

Vous pouvez aussi utiliser le script que j'ai exécuté ( https://gist.github.com/Katedoit/8b23a1434db9b9c126b37fb2a085fce5). Voici la sortie pgbench pour ASv2 :

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 100000
number of transactions actually processed: 100000/100000
latency average = 4.835 ms
initial connection time = 16.942 ms
tps = 206.831172 (without initial connection time)

Et pour DSQL :

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 100000
number of transactions actually processed: 100000/100000
latency average = 19.700 ms
initial connection time = 243.453 ms
tps = 50.760523 (without initial connection time)

Ce workload a consommé 8327 DPU selon les insights de facturation d'Aurora DSQL, et 0,48 ACU sur Aurora Serverless v2. Comme indiqué en début d'article, les deux ne sont vraiment pas comparables !

L'exemple est très simple, mais il permet d'extrapoler des coûts mensuels approximatifs à partir de quelques calculs et hypothèses.

Voyons ce que cela donne sur un mois. Il faudra poser de nombreuses hypothèses, mais cela donnera une idée raisonnable des écarts de coûts entre les deux. Sans oublier notre fameuse offre gratuite (les fameux 1,13 $) sur DSQL.

• 100 000 requêtes par heure (autrement dit, le test exécuté chaque heure) — 720 heures
• Workload constant, sans pics ni creux
• 10 Go de stockage de base de données

1. Compute (DPU)

• 8327 (issu du test pgbench) × 720 (heures dans un mois) = 5 995 440 DPU

- Les 100 000 premières DPU sont offertes

- DPU facturables : 5 895 440

• Coût = 5 895 440 / 1 000 000 × 8 $ = 47,16 $

2. Stockage

• 10 Go au total — 1 Go offert × 0,33 $ = 2,97 $

Coût total DSQL : 47,16 $ + 2,97 $ = 50,13 $

1. Compute (ACU)

• 0,48 (issu du test pgbench) × 720 (heures dans un mois) = 345,6 ACU
• Coût = 345,6 × 0,12 $ = 41,47 $

2. Stockage (I/O-Optimized)

• 10 Go × 0,225 $ = 2,25 $

Coût total ASv2 I/O-Optimized : 41,47 $ + 2,25 $ = 43,72 $

• DSQL — 50,13 $
• ASv2 — 43,72 $

ASv2 revient environ 13 % moins cher que DSQL, à périmètre quasi équivalent sur le coût par transaction et le stockage seuls.

Mais en réalité, le coût n'est pas le seul critère. Il faut aussi tenir compte de la performance, et de ce côté-là, DSQL ne s'en sort pas mieux non plus…

Je ne m'attarderai pas trop sur la performance. D'abord parce que cet article est centré sur les coûts, mais aussi parce que DSQL fonctionne tellement différemment de toute autre base de données envisageable qu'un test de performance équivalent est difficile à mener. Les outils de benchmark actuels, comme pgbench que j'ai utilisé, ne sont pas conçus pour le verrouillage optimiste ni les retries, et finissent par échouer sous forte charge. Cela dit, mes tests ont montré que DSQL était 4 fois PLUS LENT qu'ASv2.

Voici les résultats pgbench en transactions par seconde (tps) :

• DSQL –50,760523
• ASv2 — 206,831172

Bilan : ce n'est pas moins cher, et c'est apparemment bien plus lent. Alors…

Optez pour Aurora DSQL si :

• Vous recherchez une scalabilité prévisible avec une performance linéaire
• Vous êtes prêt à sacrifier un peu de flexibilité pour une forte scalabilité en écriture
• Les écritures multi-régions à faible latence sont déterminantes pour vous et valent leur coût
• Vous opérez à très grande échelle, avec des milliers de transactions et de connexions par seconde, et Aurora RDS commence à atteindre ses limites

Optez pour Aurora Serverless v2 si :

• Vos workloads sont en pics ou intermittents
• Vous voulez une optimisation automatique des coûts grâce au scaling des ACU
• Vous préférez un modèle de déploiement plus simple et plus flexible

En résumé : il vous faudra un cas d'usage très spécifique pour justifier le recours à DSQL à l'heure actuelle.