Como a Pismo otimizou até 82% nos custos de banco de dados com Amazon Aurora Serverless

Por Geovan Borges, Engenheiro de banco de dados na Pismo; Alexandre Magno, Gerente Sênior na Pismo; Thiago Santo, Diretor do Production Team (SRE) na Pismo; Felipe Brito, arquiteto de soluções na AWS e Luiz Moreira, Technical Account Manager da AWS.

Introdução

Eficiência operacional e otimização de custos são dois pilares fundamentais para o sucesso e crescimento de qualquer empresa, no entanto, muitos negócios ainda enfrentam desafios significativos em relação a custos, principalmente quando falamos de bancos de dados relacionais vs. escala.

Tradicionalmente, bancos de dados relacionais possuem como característica o crescimento de infraestrutura acompanhando a quantidade de dados que trafegam dentro de um determinado sistema. Quanto mais dados são trafegados, mais disco será utilizado e mais memória e CPU serão necessárias para interagir com essa camada de dados. Isso, a longo prazo, representa mais gerenciamento e custo, principalmente quando falamos de várias instâncias de banco de dados sendo executadas em uma única organização e, normalmente, sendo operadas por times pequenos.

Este artigo explica como a Pismo otimizou seus custos e operação através da migração de parte de sua frota de Banco de dados para o Amazon Aurora Serverless, melhorando eficiência operacional e custos, enquanto manteve resiliência e escalabilidade em seus bancos de dados.

Quem é Pismo e seus desafios

A Pismo, uma companhia VISA, é uma empresa de tecnologia que fornece uma plataforma de processamento para serviços bancários e de pagamentos para bancos, marketplaces e fintechs, ajudando empresas e seus clientes a se libertarem de limitações da tecnologia bancária tradicional através de uma solução nativa em nuvem.

Dentro de sua plataforma, o uso de banco de dados relacionais é parte crucial de sua infraestrutura, com aplicações financeiras críticas como ledger e autorização de cartões utilizando bancos relacionais em sua camada de dados. No total, 540 instâncias de bancos de dados, espalhadas em 6 regiões, permitem que mais de 78 clientes transacionem, mensalmente, cerca de 10 bilhões de requisições na plataforma da Pismo.

Figura 01 – Requisições por segundo na plataforma da Pismo

Com toda essa escala, novos desafios começaram a aparecer para o time de DBAs da Pismo. O agendamento e execução de janelas de manutenção para redimensionamento e otimização dos bancos se tornou parte do dia-a-dia da equipe de infraestrutura. Eram gastos mensalmente cerca de 40 horas em planejamento, execução e acompanhamento de tarefas relacionadas a essas janelas. Á medida que o número de clientes e instâncias cresceu, percebeu-se que o processo se mostrava cada vez mais inviável. Foi nesse contexto que a Pismo, junto com o time AWS, iniciou uma análise e migração para o Amazon Aurora Serverless, capaz de eliminar boa parte desses entraves e simplificar a operação da empresa.

O Amazon Aurora Serverless

O Amazon Aurora Serverless é uma configuração com escalabilidade automática sob demanda para o Amazon Aurora. Ele inicia, encerra e escala a capacidade automaticamente de acordo com as necessidades de sua aplicação. Você pode executar um banco de dados na nuvem sem gerenciar nenhuma instância de banco de dados.

O serviço oferece, também, escalonamento sob demanda, identificando aumentos de carga sem que você precise prever picos ou abrir solicitações antecipadas. Em períodos de uso regular, a capacidade diminui automaticamente, evitando pagamento por recursos ociosos. Além disso, você conta com transparência de métricas, podendo monitorar CPU, memória e latências em tempo real.

A partir destas vantagens e de testes iniciais em um ambiente de homologação controlado, a Pismo decidiu migrar a maior parte de sua frota para a modalidade Serverless do serviço.

Migração

Para migrar de Amazon Aurora Provisioned para Aurora Serverless, foi adotado o seguinte processo para cada instância:

1.  Ajustar o cluster e selecionar a capacidade mínima e máxima de ACUs (Aurora Capacity Units);
2. Modificar a classe da Instância de “Provisioned”para serverless;
3. Para reduzir o impactado, foi utilizado mais de uma instância por cluster, realizando a mudança individualmente para cada componente.

Importante destacar que o reinício do banco de dados acontece efetivamente no segundo passo descrito acima.

Lições Aprendidas e Boas práticas

Dimensionar a capacidade adequada em um ambiente de Aurora Serverless requer análise e estudos para garantir equilíbrio entre desempenho e custo. Uma boa prática é calcular cuidadosamente a capacidade mínima e máxima de ACUs. Pode ser tentador utilizar a capacidade mínima de 0.5 ACUs para todas as instâncias, mas isso pode ser prejudicial workloads mais sensíveis à latência de resposta.

É importante que, antes e depois da mudança, o time responsável pela migração realize um estudo e acompanhamento das métricas do banco. Informações como CPU, memória, quantidade e latência de DMLs, blocos lidos do storage vs cached (cache hit ratio) podem prover informações valiosas.

Na Pismo, a estratégia adotada foi visualizar essas métricas nos momentos usuais e durante os picos de utilização do sistema. Ao conhecer esses valores, foi definido a capacidade mínima de acordo com a carga constante e, em seguida, escolhido uma capacidade máxima que permitia escalabilidade suficiente para absorver picos ocasionais ou inesperados. Foram utilizadas ferramentas como o CloudWatch e o Performance Insights para monitorar e ajustar continuamente a capacidade, sempre equilibrando os benefícios de performance com o controle de custos.

O objetivo da Pismo foi ter um gráfico com linhas retas e picos ocasionais de scaling, evitando que o gráfico tenha muita volatilidade. Monitoramento e revisão são realizados periodicamente, pois o perfil de uso pode mudar com o tempo. Nos gráficos abaixo, você pode perceber que o ACU Avg e Max oscilam bastante quando o MIN ACU está demasiadamente baixo. A ideia de ter um gráfico mais plano é diminuir a pressão de memória na instância. A alocação e desalocação frequente de memória pode resultar em instabilidade e degradação de desempenho.

Indesejado (max)	Indesejado (max)
Desejado (avg)	Desejado (max)

Resultados

Após a migração de 480 instâncias para Aurora Serverless, a Pismo conseguiu visualizar as seguintes otimizações:

1. Redução de Tempo de Gerenciamento: Com o uso de Aurora Serverless, a Pismo reduziu em 90% as atividades relacionadas a operação e redimensionamento de bancos. Atualmente, se algum redimensionamento for necessário, ele acontece online e sem causar indisponibilidade;
2. Melhoria nos indicadores de disponibilidade: O redimensionamento do banco de dados exigia a reinicialização de instância, o que afeta diretamente a disponibilidade, sobretudo na instância de escrita — a mais crítica. Atualmente, com o redimensionamento automático, o time conseguiu manter um SLA de disponibilidade de 99.90% na plataforma;
3. Melhoria na Escalabilidade e Desempenho: Nossos serviços precisam manter alto desempenho mesmo em cenários de pico de carga inesperados. Com o novo ajuste dinâmico, aumentou-se a escalabilidade dos bancos de dados, que se adaptam de forma imediata às variações de demanda sem exigir mudanças manuais ou paradas programadas;
4. Otimização de Custos: Com Aurora Serverless ajustando a capacidade automaticamente, chegou-se em economias de 20% a 30% em instâncias pequenas e até 82% em instâncias maiores, incluindo instâncias reservadas de um ano (sem pagamento antecipado).

Conclusão

Antes da Pismo adotar Aurora Serverless, manutenções programadas para redimensionar os bancos de dados eram comuns, exigindo horas de trabalho e gerando pequenas indisponibilidades. Além disso, em cenários de pico, era necessário superdimensionar instâncias para garantir desempenho, resultando em aumento de custos.

Com a mudança para Serverless, o escalonamento agora ocorre de forma automática e totalmente online, dispensando janelas de manutenção e reduzindo a carga operacional. Além disso, o pagamento é feito apenas pelo que realmente é utilizado, o que trouxe vantagens econômicas de até 82% no ambiente da Pismo. Toda essa otimização mantendo a performance do banco de dados durante aumentos de demanda sem exigir reconfigurações manuais.

Sobre os autores

	Geovan Borges é engenheiro de banco de dados na Pismo, atuando com serviços de nuvem da AWS com foco em performance e escalabilidade. Experiencia de mais de 15 anos em TI, com expertise em otimização, migração e projetos estratégicos.
	Alexandre Magno é Gerente Sênior na Pismo, com 19 anos de experiência em TI, especializado em gerenciamento de ambientes de alta criticidade, com foco em entregar soluções de alto desempenho, escalabilidade e observabilidade.
	Thiago Santo é Diretor do Production Team (SRE) na Pismo. Com mais de 20 anos de atuação em TI, já trabalhou em empresas dos setores de Tecnologia, Finanças, Varejo, entre outras. Sua experiência inclui arquitetura de nuvem, Kubernetes, CI/CD, gestão de operações de produção e segurança.
	Felipe Brito é arquiteto de soluções na AWS e guia clientes nas melhores práticas de arquitetura na nuvem. Possui experiência com projetos de desenvolvimento de software, observabilidade e análise de dados.

Luiz Moreira é Technical Account Manager da AWS auxiliando clientes em sua jornada de nuvem. Possui mais de 18 anos de experiência em tecnologia nas áreas de infraestrutura, como computação, rede e armazenamento e nos últimos 10 anos vem se dedicando na especialização em Segurança.