Aurora Distributed SQL vs. Aurora Serverless v2: uma análise prática de custos

Vamos começar olhando os preços publicados pela AWS para ver se dá para fazer uma comparação decente entre eles. Spoiler: não dá.

Aurora DSQL

• Compute: cobrado por Distributed Processing Unit (DPU)

- Tarifa: US$ 8 por 1 milhão de DPUs

- 100 mil DPUs ≈ ~700.000 transações TPC-C (com base nos benchmarks da AWS)

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

• Armazenamento: US$ 0,33 por GB-mês
• Camada gratuita: os primeiros 100 mil DPUs e 1 GB-mês de armazenamento são gratuitos todo mês

E afinal, o que é um DPU? É a história das ACUs se repetindo: praticamente impossível entender o que isso significa na prática, né?

Vamos comparar com o Aurora Serverless v2.

• Compute: cobrado por Aurora Capacity Unit (ACU)

- Tarifa: US$ 0,12 por ACU-hora

- Escala entre 0,5 e 128 ACUs, podendo chegar a 0 quando ocioso

• Armazenamento: duas opções:

- Standard: US$ 0,10 por GB-mês + US$ 0,20 por 1 milhão de I/Os

- I/O-Optimized: US$ 0,225 por GB-mês, sem cobrança separada de I/O

A primeira conclusão é que os modelos de cobrança do Aurora Serverless v2 e do Aurora DSQL são diferentes — então, tirando o armazenamento, não dá para comparar diretamente. Repare que o armazenamento sai quase 50% mais caro até do que o I/O-Optimized, ou seja, um sistema com muito armazenamento e poucas transações sempre vai custar mais no DSQL — antes mesmo de chegarmos à pergunta: o que é exatamente um DPU? Continue lendo!

O DPU é a métrica de cobrança de compute do Aurora DSQL. Cada DPU representa os recursos usados para processar consultas distribuídas no engine de execução altamente paralelo do Aurora. Inclui tempo de CPU, uso de memória e o trabalho necessário para recuperar e manipular os dados.

Os DPUs são fracionários e baseados em uso, ou seja, você só paga pelos recursos de compute que de fato consome. Diferente das ACUs do Aurora Serverless v2, que são provisionadas em incrementos de meia unidade por segundo. Mas, assim como nas ACUs, é quase impossível saber de antemão quanto você vai usar — então a única forma de ter uma estimativa precisa é testando.

O Aurora DSQL inclui uma camada gratuita todo mês:

• 100.000 DPUs grátis (equivalente a US$ 0,80)
• 1 GB-mês de armazenamento grátis (equivalente a US$ 0,33)

No total, são US$ 1,13 de economia por mês — não é exatamente um divisor de águas em produção, mas cai como uma luva para workloads gratuitos de dev/test. E, sem saber quanto cada DPU cobre, é impossível dizer se isso é uma gota no oceano ou se cobre todo o seu workload de produção. Bora atrás de algumas métricas reais, então.

Neste teste, vamos usar o pgbench para colocar o banco sob pressão em um cenário razoavelmente realista. Usei o benchmarking padrão TCP-B do pgbench e rodei com 100.000 chamadas de transação para cada banco. Comecei rodando por 60 minutos, mas logo percebi que o throughput do DSQL era tão menor que o do ASv2 que não fazia sentido para um blog focado em custos. Volto rapidamente à parte de performance no final.

Este é o comando do pgbench, caso você queira fazer seus próprios testes de validação. Tive que rodar com um único cliente porque, por causa do optimistic locking (veja meu blog anterior — https://engineering.doit.com/aurora-dsql-uncovered-the-future-of-scalable-databases-f2fabcde672a), muitos clientes davam erro no DSQL por conta de conflitos, e o teste não ficava justo entre os dois engines:

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

Ou, se preferir, dá para usar o script que eu rodei ( https://gist.github.com/Katedoit/8b23a1434db9b9c126b37fb2a085fce5). Esta é a saída do pgbench para o 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 para o 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)

Esse workload consumiu 8327 DPU, medidos pelos billing insights do Aurora DSQL, e 0,48 ACU no Aurora Serverless v2. Como falei lá no começo, eles realmente não são comparáveis!

Foi um exemplo bem simples, mas dá para extrapolar custos mensais aproximados com algumas contas e premissas básicas.

Vamos ver como ficaria isso ao longo de um mês. Vai ser preciso assumir várias coisas, mas dá para ter uma noção razoável das diferenças de custo entre os dois. E não esqueça da nossa camada gratuita (aqueles maravilhosos US$ 1,13) no DSQL.

• 100.000 consultas por hora (ou seja, o teste de workload que rodamos seria executado a cada hora) — 720 horas
• Workload constante, sem picos nem vales
• 10 GB de armazenamento de banco

1. Compute (DPUs)

• 8327 (do teste de pgbench) × 720 (horas no mês) = 5.995.440 DPUs

- Os primeiros 100.000 DPUs são gratuitos

- DPUs faturáveis: 5.895.440

• Custo = 5.895.440/1.000.000 × US$ 8 = US$ 47,16

2. Armazenamento

• 10 GB no total — 1 GB da camada gratuita × US$ 0,33 = US$ 2,97

Custo total do DSQL: US$ 47,16 + US$ 2,97 = US$ 50,13

1. Compute (ACUs)

• 0,48 (do teste de pgbench) × 720 (horas no mês) = 345,6 ACU
• Custo = 345,6 × US$ 0,12 = US$ 41,47

2. Armazenamento (I/O-Optimized)

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

Custo total do ASv2 I/O-Optimized: US$ 41,47 + US$ 2,25 = US$ 43,72

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

O ASv2 sai cerca de 13% mais barato que o DSQL em uma comparação aproximada, considerando só custo por transação e armazenamento.

Mas, na prática, ninguém olha só para custo. Tem que haver um trade-off de performance também — e, infelizmente, a história não é boa para o DSQL nesse quesito também…

Não vou me alongar muito na parte de performance. Primeiro porque este é um blog focado em custos; segundo porque o DSQL se comporta de forma tão diferente de qualquer outro banco que você possa cogitar usar que fica difícil fazer um teste equivalente. As ferramentas atuais de benchmark, como o pgbench que usei, não foram pensadas para optimistic locking e retries, então quebram sob carga alta. Ainda assim, meus testes mostraram que o DSQL ficou 4 vezes MAIS LENTO que o ASv2.

Veja os resultados de transações por segundo (tps) no pgbench:

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

Ou seja, não é mais barato e ainda parece ser bem mais lento, então…

Use o Aurora DSQL quando:

• Você quer escalonamento previsível com performance linear
• Está disposto a abrir mão de alguma flexibilidade em troca de forte escalabilidade de escrita
• Escritas multirregionais com baixa latência são um divisor de águas para o seu caso e valem o investimento
• Você tem escala massiva, com milhares de transações e conexões por segundo, e o Aurora RDS está começando a virar gargalo

Use o Aurora Serverless v2 quando:

• Você tem workloads intermitentes ou com picos
• Quer otimização automática de custos com escalonamento de ACUs
• Prefere um modelo de deploy mais simples e flexível

Ou, resumindo: você vai precisar de um caso de uso bem específico para justificar o uso do DSQL no momento.