Aurora Distributed SQL vs Aurora Serverless v2: un'analisi pratica dei costi

Partiamo dai prezzi pubblicati da AWS, per capire se è possibile arrivare a un confronto sensato. Spoiler: non lo è.

Aurora DSQL

• Compute: fatturato per Distributed Processing Unit (DPU)

- Tariffa: 8 $ per 1 milione di DPU

- 100K DPU ≈ ~700.000 transazioni TPC-C (in base ai benchmark AWS)

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

• Storage: 0,33 $ per GB-mese
• Free tier: ogni mese sono inclusi gratuitamente i primi 100K DPU e 1 GB-mese di storage

Ma cos'è esattamente una DPU? Siamo di nuovo al problema degli ACU: capire cosa significhi nella pratica è quasi impossibile, no?

Confrontiamola con Aurora Serverless v2.

• Compute: fatturato per Aurora Capacity Unit (ACU)

- Tariffa: 0,12 $ per ACU-ora

- Scala da 0,5 a 128 ACU, e arriva fino a 0 quando è inattivo

• Storage: due opzioni:

- Standard: 0,10 $ per GB-mese + 0,20 $ per 1M di I/O

- I/O-Optimized: 0,225 $ per GB-mese, senza addebiti separati per gli I/O

La prima conclusione è che Aurora Serverless v2 e Aurora DSQL hanno modelli di fatturazione diversi: a parte lo storage, un confronto diretto non è possibile. Si noti che lo storage è quasi il 50% più caro persino della modalità I/O-Optimized: questo significa che, su DSQL, un sistema di storage di grandi dimensioni con un volume di transazioni ridotto costerà sempre di più, ancora prima di chiederci cosa sia esattamente una DPU. Continui a leggere per scoprirlo!

La DPU è la metrica di fatturazione del compute di Aurora DSQL. Ogni DPU rappresenta le risorse impiegate per elaborare query distribuite tramite il motore di esecuzione altamente parallelo di Aurora. Comprende tempo di CPU, utilizzo della memoria e il lavoro necessario per recuperare e manipolare i dati.

Le DPU sono frazionarie e basate sull'utilizzo: si paga solo per le risorse di compute effettivamente consumate. È un modello diverso da quello degli ACU di Aurora Serverless v2, che vengono allocati al secondo in incrementi di mezza unità. Tuttavia, proprio come per gli ACU, è praticamente impossibile prevedere in anticipo quanto si consumerà: l'unico modo per ottenere stime accurate è testare sul campo.

Aurora DSQL include un free tier mensile:

• 100.000 DPU gratuite (per un valore di 0,80 $)
• 1 GB-mese di storage gratuito (per un valore di 0,33 $)

In totale parliamo di 1,13 $ di risparmio mensile: non certo una svolta in produzione, ma perfetto per workloads di sviluppo e test gratuiti. E senza sapere quanto copra una DPU, non possiamo dire se si tratti di una goccia nell'oceano o se basti a coprire l'intero workload di produzione. Proviamo allora a raccogliere qualche metrica reale.

In questo test useremo pgbench per mettere il database sotto pressione in uno scenario abbastanza realistico. Ho utilizzato il benchmark TCP-B standard di pgbench, eseguendolo con 100.000 chiamate di transazione su ciascun database. Inizialmente l'avevo lanciato per 60 minuti, ma mi sono accorta subito che il throughput di DSQL era talmente inferiore a quello di ASv2 da non avere alcun senso ai fini di un'analisi dei costi. Tornerò brevemente sul tema delle prestazioni alla fine.

Questo è il comando pgbench, se desidera eseguire i propri test di verifica. Ho dovuto lanciarlo con un singolo client perché, a causa dell'optimistic locking (vedi il mio blog precedente — https://engineering.doit.com/aurora-dsql-uncovered-the-future-of-scalable-databases-f2fabcde672a), molti client su DSQL andavano in errore per conflitti, rendendo il test poco equo tra i due motori:

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

In alternativa può usare lo script che ho impiegato io ( https://gist.github.com/Katedoit/8b23a1434db9b9c126b37fb2a085fce5). Ecco l'output di pgbench per 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)

E quello per 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)

Questo workload ha consumato 8327 DPU, secondo le metriche di fatturazione di Aurora DSQL, e 0,48 ACU su Aurora Serverless v2. Come dicevo all'inizio, non sono davvero confrontabili!

L'esempio è molto semplice, ma ci permette di estrapolare un costo mensile di massima con qualche calcolo e qualche ipotesi.

Vediamo come si comportano i due servizi sull'arco di un mese. Dovremo introdurre diverse ipotesi, ma il quadro che ne emerge dovrebbe dare un'idea ragionevole delle differenze di costo. Senza dimenticare il nostro free tier (gli incredibili 1,13 $ gratuiti) su DSQL.

• 100.000 query ogni ora (ovvero il workload di test eseguito ogni ora) — 720 ore
• Workload costante, senza picchi né cali
• 10 GB di storage del database

1. Compute (DPU)

• 8327 (rilevate dal test pgbench) × 720 (ore in un mese) = 5.995.440 DPU

- Le prime 100.000 DPU sono gratuite

- DPU fatturabili: 5.895.440

• Costo = 5.895.440/1.000.000 × 8 $ = 47,16 $

2. Storage

• 10 GB totali — 1 GB di free tier × 0,33 $ = 2,97 $

Costo totale DSQL: 47,16 $ + 2,97 $ = 50,13 $

1. Compute (ACU)

• 0,48 (rilevati dal test pgbench) × 720 (ore in un mese) = 345,6 ACU
• Costo = 345,6 × 0,12 $ = 41,47 $

2. Storage (I/O-Optimized)

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

Costo totale ASv2 I/O-Optimized: 41,47 $ + 2,25 $ = 43,72 $

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

Su un confronto il più possibile equivalente in termini di costo per transazione e storage, ASv2 risulta circa il 13% più economico di DSQL.

Ma nella realtà i costi non sono l'unico parametro: c'è sempre un compromesso da fare anche sul fronte delle prestazioni e, purtroppo, nemmeno lì DSQL se la passa bene…

Non mi soffermerò troppo sull'aspetto prestazionale. Sia perché questo è un articolo focalizzato sui costi, sia perché DSQL si comporta in modo così diverso da qualunque altro database che un confronto prestazionale equivalente è davvero difficile da realizzare. Gli strumenti di benchmarking attuali, come pgbench che ho usato, non sono progettati per gestire optimistic locking e retry, e quindi falliscono sotto carico elevato. Detto questo, dai miei test è emerso che DSQL è 4 volte PIÙ LENTO di ASv2.

Guardi i risultati di pgbench in transazioni al secondo (tps):

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

Quindi non solo non è più economico, ma risulta anche notevolmente più lento, perciò…

Scelga Aurora DSQL quando:

• Desidera uno scaling prevedibile con prestazioni lineari
• È disposto a sacrificare un po' di flessibilità in cambio di una forte scalabilità in scrittura
• Le scritture multi-region a bassa latenza rappresentano un punto di svolta per il suo caso d'uso e ne valgono la spesa
• Lavora su scala enorme, con migliaia di transazioni e connessioni al secondo, e Aurora RDS inizia a fare da collo di bottiglia

Scelga Aurora Serverless v2 quando:

• Ha workloads a picchi o intermittenti
• Vuole un'ottimizzazione automatica dei costi grazie allo scaling degli ACU
• Preferisce un modello di deployment più semplice e flessibile

In sintesi: oggi serve un caso d'uso davvero specifico per giustificare l'adozione di DSQL.