Aurora Distributed SQL vs. Aurora Serverless v2: Die Kosten im Praxistest

Werfen wir zunächst einen Blick auf die offiziellen AWS-Preise und prüfen, ob sich daraus ein belastbarer Vergleich ableiten lässt. Spoiler: Lässt er sich nicht.

Aurora DSQL

• Compute: Abrechnung pro Distributed Processing Unit (DPU)

- Preis: 8 $ pro 1 Million DPUs

- 100.000 DPUs ≈ ca. 700.000 TPC-C-Transaktionen (laut AWS-Benchmarks)

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

• Storage: 0,33 $ pro GB-Monat
• Free Tier: Die ersten 100.000 DPUs und 1 GB-Monat Storage sind pro Monat kostenlos

Aber was genau ist eigentlich eine DPU? Wie schon bei den ACUs lässt sich kaum greifen, was das in der Praxis bedeutet, oder?

Vergleichen wir das also mit Aurora Serverless v2.

• Compute: Abrechnung pro Aurora Capacity Unit (ACU)

- Preis: 0,12 $ pro ACU-Stunde

- Skaliert zwischen 0,5 und 128 ACUs, im Leerlauf sogar bis auf 0

• Storage: Zwei Optionen:

- Standard: 0,10 $ pro GB-Monat + 0,20 $ pro 1 Mio. I/Os

- I/O-Optimized: 0,225 $ pro GB-Monat, keine separaten I/O-Kosten

Erste Erkenntnis: Die Abrechnungsmodelle von Aurora Serverless v2 und Aurora DSQL unterscheiden sich grundlegend – außer beim Storage lässt sich also nichts direkt vergleichen. Auffällig: Der Storage bei DSQL ist sogar fast 50 % teurer als der I/O-Optimized-Tarif. Heißt: Ein großes Storage-System mit niedrigem Transaktionsvolumen kostet auf DSQL immer mehr – und das, bevor wir uns überhaupt mit der Frage beschäftigen, was eine DPU eigentlich ist. Dazu kommen wir jetzt!

Eine DPU ist die Compute-Abrechnungseinheit von Aurora DSQL. Jede DPU steht für die Ressourcen, die zur Verarbeitung verteilter Queries über Auroras hochgradig parallele Query-Engine benötigt werden. Dazu zählen CPU-Zeit, Speichernutzung sowie der Aufwand fürs Abrufen und Verarbeiten der Daten.

DPUs werden nutzungsbasiert und in Bruchteilen abgerechnet – Sie zahlen also nur für die Compute-Ressourcen, die Sie tatsächlich verbrauchen. Das ist anders als bei den ACUs in Aurora Serverless v2, die in Halbeinheiten pro Sekunde bereitgestellt werden. Doch genau wie bei ACUs lässt sich im Voraus kaum abschätzen, wie viel am Ende verbraucht wird. Verlässliche Werte erhalten Sie nur durch praktische Tests.

Aurora DSQL bietet jeden Monat einen Free Tier:

• 100.000 DPUs kostenlos (Wert: 0,80 $)
• 1 GB-Monat Storage kostenlos (Wert: 0,33 $)

Macht zusammen 1,13 $ Ersparnis pro Monat – kein echter Gamechanger für den Produktivbetrieb, aber ideal für kostenlose Dev-/Test-Workloads. Und solange unklar ist, wie viel eine DPU tatsächlich abdeckt, lässt sich nicht sagen, ob das ein Tropfen auf den heißen Stein ist oder schon Ihren gesamten Produktiv-Workload abdeckt. Holen wir uns also ein paar belastbare Praxiswerte.

Für diesen Test setzen wir die Datenbank mit pgbench in einem realitätsnahen Szenario unter Druck. Genutzt habe ich das Standard-pgbench-TCP-B-Benchmarking mit jeweils 100.000 Transaktionsaufrufen pro Datenbank. Ursprünglich wollte ich es 60 Minuten lang laufen lassen, doch schnell wurde klar: Der Durchsatz von DSQL lag so deutlich unter dem von ASv2, dass das für einen Kostenanalyse-Blog wenig Sinn ergab. Auf den Performance-Aspekt komme ich am Ende noch kurz zurück.

Hier der pgbench-Befehl, falls Sie eigene Tests zur Validierung durchführen möchten. Ich musste mit nur einem Client arbeiten, denn aufgrund des optimistischen Lockings (siehe meinen vorherigen Blogbeitrag – https://engineering.doit.com/aurora-dsql-uncovered-the-future-of-scalable-databases-f2fabcde672a) liefen viele Clients bei DSQL in Konflikte – ein fairer Vergleich beider Engines wäre so nicht möglich gewesen:

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

Alternativ können Sie auch das Skript verwenden, das ich genutzt habe (https://gist.github.com/Katedoit/8b23a1434db9b9c126b37fb2a085fce5). Hier die pgbench-Ausgabe für 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)

Und für 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)

Dieser Workload verbrauchte laut den Billing Insights von Aurora DSQL 8327 DPU und auf Aurora Serverless v2 0,48 ACU. Wie eingangs gesagt: Die beiden sind schlicht nicht vergleichbar!

Das Beispiel ist sehr einfach gehalten, aber damit lassen sich die monatlichen Kosten mit ein paar simplen Rechnungen und Annahmen grob hochrechnen.

Schauen wir uns also an, wie das Ganze über einen Monat hinweg aussieht. Ein paar Annahmen sind dabei nötig, doch das Ergebnis vermittelt einen brauchbaren Eindruck der Kostenunterschiede zwischen beiden Optionen. Und vergessen wir nicht den Free Tier (die fantastischen 1,13 $ kostenlos) bei DSQL.

• 100.000 Queries pro Stunde (d. h. unser Test-Workload läuft jede Stunde) – 720 Stunden
• Konstanter Workload ohne Spitzen und Täler
• 10 GB Datenbank-Storage

1. Compute (DPUs)

• 8327 (aus dem pgbench-Test) × 720 (Stunden pro Monat) = 5.995.440 DPUs

- Die ersten 100.000 DPUs sind kostenlos

- Abrechenbare DPUs: 5.895.440

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

2. Storage

• 10 GB gesamt – 1 GB Free Tier × 0,33 $ = 2,97 $

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

1. Compute (ACUs)

• 0,48 (aus dem pgbench-Test) × 720 (Stunden pro Monat) = 345,6 ACU
• Kosten = 345,6 × 0,12 $ = 41,47 $

2. Storage (I/O-Optimized)

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

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

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

Bei vergleichbaren Kosten pro Transaktion und Storage ist ASv2 rund 13 % günstiger als DSQL.

In der Praxis zählen aber nicht nur die Kosten. Auch bei der Performance gibt es einen Trade-off – und der sieht für DSQL leider ebenfalls nicht gerade rosig aus …

Beim Thema Performance halte ich mich kurz. Zum einen liegt der Fokus dieses Beitrags auf den Kosten, zum anderen unterscheidet sich DSQL so stark von anderen Datenbanken, dass ein wirklich vergleichbarer Performance-Test schwierig ist. Aktuelle Benchmarking-Tools wie das von mir genutzte pgbench sind nicht für optimistisches Locking und Retries ausgelegt und scheitern unter hoher Last. Mein Test zeigt aber klar: DSQL war 4-mal LANGSAMER als ASv2.

Sehen Sie sich die pgbench-Ergebnisse für Transaktionen pro Sekunde (tps) an:

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

Es ist also weder günstiger noch schneller, sondern deutlich langsamer – und damit zur Kernfrage …

Aurora DSQL eignet sich, wenn:

• Sie vorhersehbare Skalierung mit linearer Performance brauchen
• Sie bereit sind, etwas Flexibilität für starke Schreib-Skalierbarkeit zu opfern
• Niedrige Latenz und Multi-Region-Schreibvorgänge für Sie ein echter Gamechanger sind und der Aufpreis sich lohnt
• Sie eine massive Skalierung mit Tausenden Transaktionen und Verbindungen pro Sekunde fahren und Aurora RDS langsam an seine Grenzen stößt

Aurora Serverless v2 eignet sich, wenn:

• Sie schwankende oder unregelmäßige Workloads haben
• Sie auf automatische Kostenoptimierung per ACU-Skalierung setzen wollen
• Sie ein einfacheres und flexibleres Deployment-Modell bevorzugen

Oder einfacher gesagt: Aktuell braucht es einen sehr spezifischen Anwendungsfall, um den Einsatz von DSQL zu rechtfertigen.