O blog da AWS

Como processar uma grande carga de consumo e vendas sem precisar manter um servidor

Por Claudio Di Salvo, Gerente de Projetos da Snoop Consulting

A Snoop Consulting ajudou um de seus clientes a implementar soluções da AWS e aumentar a funcionalidade de seu sistema de cobrança.

A empresa é uma multinacional estadunidense produtora de agroquímicos e biotecnologia destinados à agricultura, líder mundial em engenharia genética de sementes e produção de herbicidas. Foi recentemente adquirida por uma empresa químico-farmacêutica alemã, a maior compra já feita por uma empresa daquele país no exterior, e que se tornou um dos três conglomerados que controlam mais de 60% do mercado de sementes e agroquímicos a nível mundial.

O DESAFIO

O sistema de processamento de vendas e consumo do cliente lida com uma enorme carga e simultaneidade de informações. Essas informações são provenientes de outros sistemas e o êxito ou falha deve ser gerenciado para cada transação.

Um dos principais desafios era a necessidade de trabalhar de uma maneira em que o cliente não precise manter um servidor e, portanto, o AWS Lambda começou a ser usado.

Por outro lado, era esperado que o uso de funções Lambda servisse para reduzir mensagens de falha, lidar com a simultaneidade de dados, eliminar a possibilidade de duplicação de dados e também melhorar o desempenho do sistema.

A SOLUÇÃO

O sistema está em produção há mais de um ano, suportando a carga de trabalho sem servidores ou containers auxiliares, usando as funções do Lambda para gerenciar e processar os fluxos de dados centrais do sistema. Somente uma instância EC2 está sendo usada de forma auxiliar para Jenkins.

É um sistema assíncrono composto principalmente por funções Lambda, comunicadas pelas filas SQS (Amazon Simple Queue Service) mais SNS (Amazon Simple Notification Service) se a mensagem tiver mais de uma parte interessada. As funções do AWS Lambda são configuradas sem limitar a simultaneidade a um número específico de instâncias, deixando esse trabalho de forma automática, apenas as funções que acessam o banco de dados foram limitadas.

Também foi implementado um painel na AWS para monitorar as funções Lambda no Amazon CloudWatch Dashboard com alarmes de baixa e alta duração, para alertar se a função tem baixo desempenho ou terminou com tempo limite, e para o monitoramento de erros. Para isso, há um “topic” acompanhando o SNS que logo publica o erro diretamente no Slack, em canal próprio de monitoramento. O AWS X-Ray também é usado para rastrear mensagens com algum tipo de problema.

Atualmente, novos recursos continuam a ser incorporados progressivamente.

TRABALHANDO COM O AWS LAMBDA

Para o desenvolvimento do código de funções Lambda, o Github enterprise é usado em conjunto com o Jenkins para integração e automação contínuas da implantação a partir do Github.

No modelo de solução, a possibilidade de mensagens repetidas que podem gerar dados duplicados deve ser considerada. Para evitar isso, uma biblioteca foi criada para verificar se uma mensagem já havia sido tratada ou não por uma função Lambda, isso foi implementado manipulando um ID de transação exclusivo.

A funcionalidade de repetição de funções Lambda também foi explorada quando elas têm integração com o Amazon SQS, dessa forma foi possível ter menos mensagens de falha em um mesmo processo.

As execuções com falha são realizadas novamente de forma automática por um certo tempo devido à integração SQS-Lambda e, se continuar com falha, terminam em uma “Dead Letter queue” e são notificadas.

Inicialmente, funções Lambdas com 128 MB de memória (seu valor padrão) começaram a ser usadas. Mas, em seguida, ao modificar esse valor e defini-lo com um valor mais alto, o desempenho poderá ser significativamente aprimorado. Agora, pelo menos 512 MB são usados ​​para funções produtivas.

Atualmente, o número de funções Lambda desenvolvidas atinge um total de 160 com um número total estimado de eventos por mês esperados para essas funções de 240.000, em média.

A ORGANIZAÇÃO COMPLETA DA FAMÍLIA INTEGRADA DA AWS

A carga de trabalho é distribuída da seguinte maneira:

  • Amazon API Gateway: como entrada ao sistema, se utiliza grande parte dos endpoints associados a uma função Lambda com express.js;
  • AWS Lambda: para o processamento e persistência dos dados, se utiliza o AWS Lambda em Node.js;
  • Amazon SQS / Amazon Kinesis: como um sistema de fila de mensagens;
  • Amazon SNS: como tópicos de divulgação de mensagens;
  • Amazon RDS: usado com PostgreSql e Amazon Aurora PostgreSql como armazenamentos;
  • Amazon CloudWatch / AWS Xray: usados para alertas e rastreamento
  • Amazon Cloudfront: como um content delivery network (CDN) para as UI’s, armazenadas em Amazon S3.

DIAGRAMAS DE ARQUITETURA