Aurora Distributed SQL vs. Aurora Serverless v2: un análisis práctico de costos

Empecemos por revisar los precios publicados por AWS para ver si se puede hacer una comparación decente con ellos. Spoiler: no se puede.

Aurora DSQL

• Cómputo: se cobra por Distributed Processing Unit (DPU)

- Precio: $8 por cada millón de DPUs

- 100K DPUs ≈ ~700,000 transacciones TPC-C (según los benchmarks de AWS)

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

• Almacenamiento: $0.33 por GB-mes
• Capa gratuita: los primeros 100K DPUs y 1 GB-mes de almacenamiento son gratis cada mes

Entonces, ¿qué es exactamente un DPU? Es como volver a vivir el lío de los ACUs: resulta casi imposible saber qué significa en la práctica, ¿no?

Comparémoslo con Aurora Serverless v2.

• Cómputo: se cobra por Aurora Capacity Unit (ACU)

- Precio: $0.12 por ACU-hora

- Escala entre 0.5 y 128 ACUs, e incluso baja a 0 cuando está inactivo

• Almacenamiento: dos opciones:

- Estándar: $0.10 por GB-mes + $0.20 por cada millón de I/Os

- I/O-Optimized: $0.225 por GB-mes, sin cargos adicionales por I/O

La primera conclusión es que las unidades de facturación de Aurora Serverless v2 y Aurora DSQL son distintas, así que, salvo por el almacenamiento, no se pueden comparar directamente. Verás que el almacenamiento en DSQL es casi un 50% más caro que incluso el I/O Optimized, lo que significa que un sistema con mucho almacenamiento y bajo volumen de transacciones siempre va a salir más caro en DSQL, incluso antes de meternos en el tema de qué es exactamente un DPU. ¡Sigue leyendo!

Un DPU es la métrica de facturación de cómputo de Aurora DSQL. Cada DPU refleja los recursos que se usan para procesar consultas distribuidas a través del motor de ejecución altamente paralelo de Aurora. Incluye el tiempo de CPU, el uso de memoria y el trabajo necesario para recuperar y manipular los datos.

Los DPUs son fraccionales y se cobran por uso, es decir, solo pagas por los recursos de cómputo que realmente consumes. A diferencia de los ACUs de Aurora Serverless v2, que se asignan en incrementos de medio ACU por segundo. De todos modos, igual que con los ACUs, es casi imposible saber de antemano cuánto vas a usar, así que la única forma de obtener estimaciones precisas es probarlo.

Aurora DSQL incluye una capa gratuita mensual:

• 100,000 DPUs gratis (equivalentes a $0.80)
• 1 GB-mes de almacenamiento gratis (equivalente a $0.33)

En total, son $1.13 de ahorro mensual: nada que mueva la aguja en producción, pero perfecto para workloads de dev/test gratuitos. Y como no sabemos qué cubre realmente un DPU, no podemos saber si esto es una gota en el océano o si alcanza para todo tu workload de producción. Vamos a buscar entonces algunos datos del mundo real.

En esta prueba vamos a usar pgbench para someter la base de datos a presión en un escenario bastante realista. Usé el benchmark estándar TCP-B de pgbench y lo ejecuté con 100,000 llamadas de transacción para cada base de datos. Empecé corriéndolo durante 60 minutos, pero rápidamente me di cuenta de que el throughput de DSQL era tan inferior al de ASv2 que no tenía sentido para un blog enfocado en costos. Al final retomaré brevemente el tema del rendimiento.

Este es el comando de pgbench, por si quieres correr tus propias pruebas para validar. Tuve que ejecutarlo con un solo cliente, ya que por el optimistic locking (consulta mi blog anterior — https://engineering.doit.com/aurora-dsql-uncovered-the-future-of-scalable-databases-f2fabcde672a) muchos de los clientes daban error en DSQL por conflictos, así que la prueba no resultaba justa entre ambos motores:

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

O, si prefieres, puedes usar el script que utilicé yo ( https://gist.github.com/Katedoit/8b23a1434db9b9c126b37fb2a085fce5). Este es el resultado de pgbench para 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)

Y para 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)

Este workload consumió 8327 DPU, medidos a través de los billing insights de Aurora DSQL, y 0.48 ACU en Aurora Serverless v2. Como dije al principio, ¡realmente no son comparables!

Fue un ejemplo muy sencillo, pero podemos extrapolar costos mensuales aproximados con algunos cálculos y supuestos simples.

Veamos cómo se vería todo a lo largo de un mes. Hay que asumir varias cosas, pero esto debería darnos una idea razonable de las diferencias de costo entre ambos. Y no olvidemos la capa gratuita (esos increíbles $1.13 gratis) de DSQL.

• 100,000 queries cada hora (es decir, la prueba de carga que ejecutamos correría cada hora) — 720 horas
• Workload constante, sin picos ni valles
• 10 GB de almacenamiento de base de datos

1. Cómputo (DPUs)

• 8327 (tomado de la prueba con pgbench) × 720 (horas en un mes) = 5,995,440 DPUs

- Los primeros 100,000 DPUs son gratis

- DPUs facturables: 5,895,440

• Costo = 5,895,440/1,000,000 × $8 = $ 47.16

2. Almacenamiento

• 10 GB en total — 1 GB de la capa gratuita × $0.33 = $2.97

Costo total de DSQL: $47.16 + $2.97 = $50.13

1. Cómputo (ACUs)

• 0.48 (tomado de la prueba con pgbench) × 720 (horas en un mes) = 345.6 ACU
• Costo = 345.6 × $0.12 = $41.47

2. Almacenamiento (I/O-Optimized)

• 10 GB × $0.225 = $2.25

Costo total de ASv2 I/O-Optimized: $41.47 + $2.25 = $43.72

• DSQL — $50.13
• ASv2 — $43.72

ASv2 resulta aproximadamente un 13% más barato que DSQL en una comparación lo más pareja posible, considerando solo el costo por transacción y por almacenamiento.

Pero en la práctica, el costo no es lo único que importa. También tiene que haber un trade-off en el rendimiento, y lamentablemente para DSQL ese frente tampoco pinta bien…

No voy a detenerme mucho en el rendimiento. Sobre todo porque este blog se enfoca en costos, pero también porque DSQL se comporta de forma tan distinta a cualquier otra base de datos que puedas considerar, que es difícil hacer una prueba de rendimiento equivalente. Las herramientas actuales de benchmarking, como pgbench que utilicé, no están diseñadas para optimistic locking ni reintentos, por lo que fallan bajo carga alta. Aun así, mis pruebas mostraron que DSQL fue 4 veces MÁS LENTO que ASv2.

Mira los resultados de pgbench en transacciones por segundo (tps):

• DSQL –50.760523
• ASv2 — 206.831172

Así que no es más barato y, además, parece ser bastante más lento, así que…

Usa Aurora DSQL cuando:

• Buscas un escalado predecible con rendimiento lineal
• Estás dispuesto a sacrificar algo de flexibilidad a cambio de una fuerte escalabilidad de escritura
• Las escrituras multi-región con baja latencia marcan una diferencia clave para ti y vale la pena pagar por ellas
• Manejas una escala enorme con miles de transacciones y conexiones por segundo, y Aurora RDS empieza a quedarse corto

Usa Aurora Serverless v2 cuando:

• Tienes workloads intermitentes o con picos
• Buscas optimización automática de costos con escalado por ACU
• Prefieres un modelo de despliegue más simple y flexible

O dicho de manera más simple: hoy por hoy necesitas un caso de uso muy específico para justificar el uso de DSQL.