Migrando do RDS PostgreSQL para Aurora Serverless



This content originally appeared on DEV Community and was authored by Rafael Avelar Campos

No cenário dinâmico das fintechs, a escalabilidade e a otimização de custos são desafios constantes. Recentemente, realizamos a migração do nosso banco de dados de um RDS PostgreSQL tradicional para o Aurora Serverless, e os benefícios foram significativos.

O Problema: Escalabilidade e Custos em um Ambiente Imprevisível

Nossa fintech lida com um volume de transações que pode variar drasticamente ao longo do dia. Em determinados momentos, o tráfego aumenta exponencialmente, exigindo mais recursos computacionais. No modelo tradicional do RDS PostgreSQL, enfrentávamos dois grandes desafios:

  1. Capacidade Fixa ou Superdimensionamento: Precisávamos escolher entre manter uma instância com capacidade suficiente para os picos (o que gerava altos custos quando a carga era baixa) ou correr o risco de não suportar momentos de alta demanda.
  2. Escalabilidade Manual: Mesmo com o recurso de escalabilidade do RDS, o ajuste de capacidade não era instantâneo, o que poderia impactar a performance durante os períodos de alta transação.
  3. Alto Uso de CPU e Excesso de Conexões: Durante picos de tráfego, frequentemente atingíamos níveis elevados de uso de CPU, o que causava degradação do banco de dados. Além disso, a aplicação tentava abrir muitas conexões simultâneas para compensar a lentidão, sobrecarregando ainda mais o banco e, em alguns casos, levando-o a cair completamente.

Diante disso, buscamos uma solução que permitisse maior flexibilidade sem comprometer a confiabilidade do sistema.

A Solução: Aurora Serverless

O Aurora Serverless se destacou como a melhor opção por alguns motivos:

  • Escalabilidade Automática: Ele ajusta a capacidade automaticamente conforme a demanda, sem necessidade de intervenção manual.
  • Custo Proporcional ao Uso: Diferente do RDS tradicional, onde pagamos por instâncias ativas independentemente do uso, o Aurora Serverless cobra apenas pelos recursos efetivamente utilizados.
  • Alta Disponibilidade e Performance: Como parte do ecossistema AWS, ele mantém alta disponibilidade e replica automaticamente os dados para garantir resiliência.

O Processo de Migração

A migração envolveu algumas etapas essenciais:

  1. Testes em Homologação: Subimos um banco Aurora Serverless em ambiente de homologação para realização de testes de carga, para entendermos se o problema seria resolvido, após esse teste tivemos a certeza que esse seria o melhor caminho.
  2. Criação da Read Replica no Aurora: Durante o dia, configuramos uma read replica do RDS no Aurora para manter a sincronização contínua com a base original.
  3. Fechamento do Security Group do RDS: Para garantir que não houvesse mais acessos à instância antiga, restringimos as conexões no Security Group do RDS.
  4. Promoção da Read Replica para Master: Elevamos a read replica para a instância principal do banco no Aurora.
  5. Ajuste do Endpoint: Atualizamos o endpoint do banco para apontar para a nova instância.
  6. Provisionamento dos Novos Containers: Rodamos a pipeline para que a mudança fosse feita em todos os containers.

Os Resultados

Após a migração, observamos melhorias significativas:

✅ Redução de Custos: Conseguimos uma economia expressiva de mais de 70% no custo diário do banco de dados, graças ao modelo de cobrança baseado no uso real.
✅ Melhor Resiliência a Picos: A aplicação se tornou mais robusta e responsiva, suportando picos sem necessidade de intervenção manual.
✅ Menos Sobrecarga Operacional: Não precisamos mais ajustar a capacidade manualmente, permitindo que a equipe foque em outras melhorias.
✅ Transição Rápida e Segura: O processo de troca foi concluído em apenas 3 minutos de downtime, minimizando impactos para os usuários.

Conclusão

Para fintechs e outras empresas que lidam com demandas variáveis, o Aurora Serverless provou ser uma excelente escolha. A capacidade de escalar automaticamente e o modelo de custo baseado no uso real fazem toda a diferença em um ambiente onde previsibilidade é um desafio.


This content originally appeared on DEV Community and was authored by Rafael Avelar Campos