Semana passada postei sobre um trabalho para uma startup aqui de São José dos Campos numa base RDS da AWS, ou seja, um Database as a Service (DBaaS). A imagem abaixo era para ser auto explicativa.
Acontece que a postagem gerou uma certa polêmica no Facebook, então gostaria de esclarecer alguns pontos.
O cliente
- Em horário comercial o consumo de CPU batia 100% com muita frequência e os clientes estavam reclamando constantemente de lentidão no sistema;
- O Cliente em questão é uma startup. A base já está em produção, mas é pequena ainda;
- A equipe de desenvolvimento é composta em sua maioria por desenvolvedores com pouca experiência. Eles tem feito um bom trabalho, mas não possuem experiência com SQL;
- Se você conhece o universo de startups, deve saber que projetos que começam pequenos devem ter custos baixos para serem viáveis. Então nesse caso não seria possível iniciar o projeto um custo fixo alto. Começar com o time dos sonhos significa não ter time nenhum;
- O cliente hoje gasta cerca de USD 300/mês com a instância RDS de produção. Não é pouca coisa, mas, ao mesmo tempo, não um custo tão alto que justifique trocar facilmente o RDS por uma VM com um DBA para cuidar do banco de dados.
O que foi feito?
O cliente não tinha orçamento para fazer um Health Check completo, mas fizemos uma avaliação de algumas coisas importantes:
- Avaliação da carga no servidor olhando o monitoramento do RDS;
- Parametrização do banco de dados, instalação do pg_stat_statements;
- Migração para o PostgreSQL 11;
- Avaliação das conexões, idle_in_transaction, etc;
- Avaliação do autovacuum e estatísticas dos objetos;
- Avaliação das piores consultas no pg_stat_statements;
- Geração de planos de execução para as piores consultas;
- Criação de índices para as piores consultas.
Após esse trabalho, o uso de CPU caiu de 100% para menos de 40%. Sim, a criação dos índices foi a parte que gerou a maior impacto para o cliente e fez a carga diminuir drasticamente. No entanto, até chegar lá, é preciso ver o servidor como um todo.
Preciso mesmo de um DBA?
Depende.
Sempre depende.
- Se você tem um serviço gerenciado como um RDS, você não precisa de um DBA para fazer o backup, para instalar ou replicar o banco de dados;
- Se você tem uma equipe de alto nível com muita experiência, essa equipe poderá analisar as consultas da aplicação e criar índices sem a ajuda de um DBA;
- Se a sua base é pequena ou tem poucos usuários, você pode não ter problemas de performance ou pode escalar por hardware, mas uma hora a conta vai chegar. Um DBA pode lhe ajudar a lidar com momentos de pico, alta concorrência, gargalos, locks, erros, etc. Um desenvolvedor muito experiente ou um administrador, DevOps, ou sysadmin experiente (como queira chamar) pode fazer esse papel eventualmente.
- Existem um sem número de situações onde um bom DBA pode agregar numa equipe:
- Parametrização do banco
- Parametrização de objetos
- Modelagem
- Escolha de tipos de dados correta
- Escolha de arquitetura correta
- Monitoramento
- Automatização de deploy em bancos de dados
- Recuperação de desastres
Enfim, conheço startups com 2 ou 3 funcionários que contratam os serviços de DBA remoto. E conheço equipes grandes sem nenhum DBA. Quando você deve incorporar os serviços de um DBA na sua equipe? Bom, cada equipe tem suas dores. Se você acha que está tudo bem com o banco de dados, dificilmente você irá investir nisso. Ou pode acontecer de você apenas achar que está tudo bem…
E você, acha que DBaaS não precisa de DBA???
