Como a divisão de Agricultura da Hexagon economizou mais de 60% e melhorou significativamente a performance em suas bases de dados no Amazon RDS

Por Tarcísio Mello, Gerente de P&D na divisão de Agricultura da Hexagon
Flávio Ximenes, Analista de Sistemas da Hexagon,
Lígia Harumi Yamamoto, Arquiteta de Soluções na AWS.

A Hexagon é líder global em sensores, software e soluções autônomas. A divisão de Agricultura da Hexagon desenvolve e fornece soluções de tecnologia da informação que desencadeiam todo o potencial da produção agrícola, gerando grandes ganhos de eficiência, produtividade e sustentabilidade. Suas soluções convertem dados em informações inteligentes e acionáveis que permitem o planejamento inteligente, execução eficiente no campo, controle preciso de máquinas e fluxos de trabalho automatizados para otimizar as operações.

Segundo o Gerente de Pesquisa e Desenvolvimento da divisão de Agricultura da Hexagon, Tarcísio Mello, dado a natureza da solução, que trabalha com centenas de GB de dados enviados mensalmente por diversos equipamentos agrícolas monitorados, isso representa um custo crescente de armazenamento para o RDS e também de consumo de recursos da instância de banco de dados, visto que um banco com um alto volume de dados acaba gerando mais consumo de CPU e memória.

“Para se ter uma ideia, a cada 1 minuto, cada equipamento envia um registro com diversas informações, dentre elas um grande número de sensores. Esse registro é recebido e tratado pelo IoT e persistido em nosso RDS Postgres.”, explica Tarcísio.

Em uma busca constante pelo cenário de melhor custo benefício, iniciaram um trabalho para evitar esse aumento contínuo de volume de armazenamento e de custos, ao passo que garantem a qualidade e performance na solução, e mantêm competitividade no mercado. Ainda havia o desafio de não poder contar com um longo período de downtime para execução de qualquer procedimento, além da necessidade de reter o dado histórico por um longo período após a sua geração.

Neste sentido, o time da divisão de Agricultura da Hexagon iniciou um trabalho de otimização em seu banco de dados RDS PostgreSQL, que contou com 7 fases, como explica Flávio Ximenes, DBA da empresa:

Fase 1: Upgrade da versão do banco de dados

O primeiro passo foi migrar a versão do banco de dados do RDS Postgres 9.4 para a versão 11.2 em fases. Primeiramente migrou-se da 9.4 para a 9.5, 9.5 para 9.6, 9.6 para 10.2 e finalmente da 10.2 para a 11.2.

Fase 2: Particionamento das tabelas mais volumosas no RDS Postgres

Com a atualização do banco, ganhou-se o recurso de partições, que na versão 9.4 ainda não era disponível. A divisão de Agricultura da Hexagon particionou todas as tabelas volumosas por mês/ano, devido à forma que elas são consultadas pela aplicação. Em sua base existia uma tabela com dados recebidos de todos os sensores, e essa tabela representava 70% do seu armazenamento total.

“Percebemos, que com a atualização, os recursos de parser e leitura de JSON estavam com a performance muito melhor em relação à versão anterior. Então, remodelamos a aplicação para deixar de usar essa tabela de sensores (usando o JSON direto) e com isso pudemos excluí-la do banco. Com esse drop tivemos uma redução significativa do tamanho do storage, e isso nos trouxe um “problema”: como diminuir o tamanho do banco, sem downtime na aplicação?”, diz Flávio.

Fase 3: Expurgo de dados antigos para S3/Glacier gerando arquivos CSV “enriquecidos”

Após a exclusão da tabela de sensores, a divisão de Agricultura da Hexagon decidiu expurgar da base de dados informações anteriores a 12 meses, e com isso teve uma diminuição ainda maior em seu volume de armazenamento no banco de dados. Este, inicialmente, era de 6,5TB, e após estes processos de redução do volume de armazenamento no banco de dados, passou a ser de 1,5TB, o que representa uma redução de 77% no volume total do banco de dados.

Durante o processo de expurgo desses dados, estes passam por um processo de enriquecimento, no qual informações adicionais referentes a campos dos registros de monitoramento são incorporadas à tabela, como informações sobre equipamentos, operadores e atividade executada no campo. Inicialmente, esse expurgo enriquecido foi feito manualmente, copiado para o S3, e armazenado na categoria Glacier Deep Archive.

Fase 4: Criação de novo RDS (com menor volume de armazenamento)

A divisão de Agricultura da Hexagon criou uma nova instância de banco de dados RDS paralela à sua instância RDS de produção, já com o tamanho final que necessitavam para a migração dos dados. Essa instância RDS foi criada somente com os schemas das bases de dados, sem nenhuma informação inserida em suas tabelas. Foram realizados testes de migração com o AWS DMS, porém como possuem dados complexos em suas tabelas, optaram pela extensão pglogical do PostgreSQL para replicar os dados de forma contínua para o banco de dados de destino. A cópia ocorreu em paralelo à utilização da aplicação, sem ocasionar perda de performance durante o processo.

O processo de replicação dos dados levou 72 horas, devido ao alto volume de dados, e após este período, apenas o que era inserido ou alterado era replicado ao banco de dados de destino. Mantiveram a replicação contínua por alguns dias, e após a aprovação para a troca do banco de dados antigo para o novo, o fizeram com o mínimo de downtime.

Fase 5: Troca, no ambiente de produção, da instância de banco de dados RDS antiga para a nova

Com o término da cópia dos dados, solicitaram uma pausa programada para os clientes da aplicação para que fosse realizada a troca do banco de dados de produção. Pararam todos os serviços conectados ao banco de dados e executaram esta troca: renomear o banco atual (com maior volume de armazenamento) para outro nome, e renomear o novo banco de dados com o nome anteriormente associado ao banco de dados de produção. Após a renomeação, a divisão de Agricultura da Hexagon reiniciou os serviços e todos os clientes já se conectaram ao novo banco de dados. O downtime foi mínimo e a mudança não trouxe prejuízos à aplicação.

Fase 6: Deleção da instância de banco de dados RDS antiga (com maior volume de armazenamento)

Com a troca das instâncias de banco de dados RDS PostgreSQL, não era mais necessário manter a instância RDS antiga em execução. Dessa forma, a divisão de Agricultura da Hexagon realizou um backup dessa instância RDS, como precaução, e o arquivou no S3 Glacier Deep Archive, finalmente o excluindo a instância RDS antiga.

Fase 7: Automação do processo de expurgo mensal de dados no banco de dados RDS PostgreSQL

Após todas essas etapas, a divisão de Agricultura da Hexagon automatizou o processo de enriquecimento e expurgo dos dados. Mensalmente, executam um processo que conecta no banco de dados de produção, e identifica as tabelas a serem expurgadas. Após esta etapa, executam as consultas para geração dos arquivos em formato CSV, e os copiam para o S3, apagando posteriormente a tabela do banco de dados de produção. “Com essa ação, temos conseguido manter o banco de dados com um tamanho estável, sem um crescimento muito grande”, relata Flávio.

Resultados

“Após estes procedimentos, conseguimos otimizar nosso ambiente de banco de dados em mais de 60%, considerando custos de armazenamento e tamanho de instâncias RDS, nos ambientes de desenvolvimento, testes, homologação e produção. Além da redução de custos, ainda conseguimos uma melhora significativa de performance nas aplicações e na execução de rotinas automatizadas, como de consolidação de dados, geração de métricas e alertas.”, explica Tarcísio Mello.

Você também pode otimizar custos em seu banco de dados, a partir de sua análise sob diversos aspectos.

Seguem cinco recomendações que vão ajudá-lo a obter maior custo-benefício na utilização de seu banco de dados:

1. Pause suas instâncias RDS a partir da funcionalidade de “Stop and Start”:esta funcionalidade, indicada principalmente para ambientes de desenvolvimento e testes, que não requerem o acesso 24×7 ao banco de dados, permite que você reduza custos associados à sua instância de banco de dados. Enquanto a sua instância estiver pausada,  você é cobrado pelo armazenamento de banco de dados e armazenamento de backups, mas não pelas horas da instância de banco de dados.

A partir desta funcionalidade, a sua instância de banco de dados pode ser pausada por até 7 dias – isso para garantir que a manutenção necessária seja realizada em seus bancos de dados. Porém, é possível realizar a automatização do procedimento de “Stop and Start” de forma agendada, utilizando funções Lambda que são invocadas a partir de eventos agendados.

Para facilitar o gerenciamento de sua instância de banco de dados RDS, quando esta é iniciada, são mantidas as configurações do momento em que foi pausada, como configuração de endpoint, grupos de segurança e parameter groups de banco de dados. Para verificar mais detalhes e começar a utilizar a funcionalidade de “Stop and Start”, leia este outro Blogpost.

2. Utilize Instâncias RDS Reservadas:este modelo é indicado para cenários em que há previsibilidade na utilização de instâncias. Um exemplo deste cenário é o de um e-commerce, cujas instâncias de banco de dados precisam estar ligadas o tempo todo, para serem consultadas pela aplicação web, que também precisa operar 24×7.

É possível realizar a reserva de uma instância de banco de dados RDS, com comprometimento de utilização de 1 ou 3 anos, e receber descontos que podem chegar a mais de 60% em relação ao modelo on-demand. As instâncias reservadas estão disponíveis para Aurora, MySQL, MariaDB, PostgreSQL, Oracle e SQL Server. Para mais informações, acesse nossa documentação sobre Instâncias Reservadas do Amazon RDS.

3. Escolha o tipo e o tamanho certo para sua instância de banco de dados: existem diversas famílias de instâncias RDS, que estão distribuídas entre famílias de propósito geral e otimizadas para memória. Além disso, é possível escolher entre diferentes combinações de CPU, memória, armazenamento e capacidade de rede, para definir o conjunto de recursos ideal para o seu banco de dados.

Realizar o Right Sizing envolve analisar continuamente a performance e as necessidades e padrões de utilização da sua instância. Como as necessidades dos recursos estão sempre mudando, o Right Sizing deve se tornar um processo frequente, para que você possa continuamente alcançar a otimização de custos.

Mais especificamente sobre o RDS, as seguintes métricas são recomendadas para determinar se a utilização real é menor do que a capacidade da sua instância:

• Utilização média de CPU;
• Utilização máxima de CPU;
• Mínima memória RAM disponível;
• Quantidade média de bytes lidos do disco por segundo;
• Quantidade média de bytes escritos no disco por segundo;

Baseando-se em tais métricas, você pode ajustar a memória e o poder computacional da sua instância, de forma a alocar apenas os recursos necessários, conforme os requisitos de performance e capacidade mudam ao longo do tempo. Para saber mais sobre Right Sizing de instâncias, acesse nossas Dicas para Right Sizing em nossa documentação da AWS.

Adicionalmente, ao fazer o upgrade de sua instância RDS para uma geração mais nova, como, por exemplo, da geração M4 para a M5, é possível também obter maior performance e menor custo por hora da sua instância de banco de dados. Visite nossa documentação sobre tipos de instâncias RDS para conhecer as diversas famílias e gerações disponíveis para as instâncias de bancos de dados RDS.

4. Considere a utilização do Aurora Serverless para ambientes de desenvolvimento e testes, e cenários de demanda altamente variável: disponível para MySQL e PostgreSQL, o Aurora Serverless é cobrado apenas pelo armazenamento do banco de dados e pela capacidade de E/S consumidas pelo banco de dados enquanto está ativo.

Desta forma, em ambientes em que o banco de dados é utilizado apenas durante alguns horários do dia – como ambientes de desenvolvimento e testes, ou até mesmo ambientes de demanda altamente variável – em que pode haver um longo período de não-utilização do banco de dados, o Aurora Serverless pode apresentar um alto custo-benefício. Para saber mais sobre o Aurora Serverless, acesse nossa documentação sobre o serviço.

5. Gerencie o ciclo de vida de seus dados: para dados que não são mais acessados com frequência – assim como no caso da divisão de Agricultura da Hexagon, que realizou a movimentação de dados cuja criação fora anterior a 12 meses – a adoção de uma estratégia de ciclo de vida de seus dados pode contribuir para a redução de custos com o armazenamento de seu banco de dados.

Tal gerenciamento de ciclo de vida dos dados é possível por meio de tarefas automatizadas, que realizam a movimentação de dados menos acessados do banco de dados, como dados históricos, por exemplo, para um serviço de armazenamento mais econômico, como o Amazon S3 ou o Amazon Glacier. Para saber mais sobre o arquivamento de dados de bancos de dados relacionais para o Glacier, leia este Blogpost, que mostra passo a passo como pode ser executado este procedimento.

Uma vez armazenados no S3, é possível configurar ciclos de vida para estes dados no próprio bucket. Caso estes dados sejam necessários apenas por um determinado período de tempo, é possível configurar no ciclo de vida a expiração dos mesmos após determinado período. Porém, caso estes dados continuem pouco utilizados após certo tempo, mas seja necessário guardá-los por um determinado período por motivos de auditoria e/ou compliance, é possível configurar no ciclo de vida a transição destes dados para diferentes classes do Amazon S3, como o S3 Infrequent Access ou o Glacier, que oferecem um maior custo benefício para dados menos frequentemente acessados.

Conclusão

Utilizando estratégias de otimização em seu banco de dados RDS, a divisão de Agricultura da Hexagon conseguiu economizar 60% em custos, e obteve uma significativa melhoria de performance. Verifique seu ambiente conforme orientado para também obter melhorias e redução de custos no seu Amazon RDS. Para ainda mais otimização em seus ambientes, inclusive em relação a custos e performance, acesse também a nossa página sobre o AWS Well-Architected Framework, que ajuda arquitetos de nuvem a criar infraestruturas seguras, resilientes, eficientes e de alta performance para aplicações e cargas de trabalho.

Sobre os autores

Tarcísio Mello é Product Owner e Scrum Master certificado pela Scrum.org e atua como Gerente de P&D na divisão de Agricultura da Hexagon.

Flávio Ximenes é Analista de Sistemas com especialização em Banco de Dados e atua como DBA na divisão de Agricultura da Hexagon.

Lígia Harumi Yamamoto é arquiteta de soluções na AWS, apoiando clientes de diversas localidades e segmentos em suas jornadas de inovação e transformação digital na nuvem.