O blog da AWS
Implementando as melhores práticas do AWS Well-Architected para o Amazon SQS — Parte 3
Esta é a terceira parte de uma série de postagens de blog em três partes que demonstra as melhores práticas para o Amazon Simple Queue Service (Amazon SQS) usando o AWS Well-Architected Framework.Esta postagem do blog aborda as melhores práticas usando o Pilar de Eficiência de Desempenho, Pilar de Otimização de Custos e Pilar de Sustentabilidade. O exemplo de gerenciamento de inventário apresentado na parte 1 da série continuará a servir como exemplo.
Veja também as outras duas partes da série:
- Implementando as melhores práticas do AWS Well-Architected para o Amazon SQS — Parte 1: Excelência operacional
- Implementando as melhores práticas do AWS Well-Architected para o Amazon SQS — Parte 2: Segurança e confiabilidade
Pilar de eficiência de desempenho
O pilar de eficiência de desempenho inclui a capacidade de usar recursos de computação com eficiência para atender aos requisitos do sistema e manter essa eficiência à medida que a demanda muda e as tecnologias evoluem. Ele recomenda as melhores práticas para usar as vantagens e desvantagens para melhorar o desempenho, como aprender sobre padrões de design e serviços e identificar como as compensações afetam os clientes e a eficiência.
Ao adotar essas melhores práticas, você pode otimizar o desempenho do SQS empregando configurações e técnicas apropriadas e, ao mesmo tempo, considerando as vantagens e desvantagens do caso de uso específico.
Prática recomendada: use o agrupamento de ações (batching) ou o dimensionamento horizontal, ou ambos, para aumentar a produtividade
Para obter alta taxa de transferência no SQS, otimizar o desempenho do processamento de mensagens é crucial. Você pode usar duas técnicas: escalonamento horizontal e agrupamento de ações (action bating).
Ao lidar com um alto volume de mensagens, considere escalar horizontalmente os produtores e consumidores de mensagens aumentando o número de tópicos por cliente, adicionando mais clientes ou ambos. Ao distribuir a carga em vários segmentos ou clientes, você pode lidar com um grande número de mensagens simultaneamente.
O agrupamento de ações (action batch) distribui a latência da ação em lote pelas várias mensagens em uma solicitação em lote, em vez de aceitar toda a latência de uma única mensagem. Como cada viagem de ida e volta gera mais trabalho, as solicitações em lote fazem um uso mais eficiente de segmentos e conexões, melhorando a produtividade. Você pode combinar o processamento em lote com o dimensionamento horizontal para fornecer uma taxa de transferência com menos threads, conexões e solicitações do que solicitações de mensagens individuais.
No exemplo de gerenciamento de inventário que apresentamos na parte 1, esse comportamento de escalabilidade é gerenciado pela AWS para a função AWS Lambda responsável pelo processamento de backend. Quando uma função do Lambda se inscreve em uma fila do SQS, o Lambda consulta a fila enquanto espera que as solicitações de atualizações de inventário cheguem. O Lambda consome mensagens em lotes, começando em cinco lotes simultâneos com cinco funções por vez. Se houver mais mensagens na fila, o Lambda adiciona até 60 funções por minuto, até 1.000 funções, para consumir essas mensagens.
Isso significa que o Lambda pode escalar até 1.000 funções simultâneas do Lambda processando mensagens da fila SQS. O processamento em lotes permite que o sistema de gerenciamento de inventário gerencie com eficiência um alto volume de mensagens de atualização de inventário. Isso garante visibilidade em tempo real dos níveis de estoque e melhora a precisão e a capacidade de resposta das operações de gerenciamento de inventário.
Prática recomendada: compensação entre as filas padrão SQS e First-In-First-Out (FIFO)
O SQS oferece suporte a dois tipos de filas: filas padrão e filas FIFO. Compreender as diferenças entre as filas padrão SQS e FIFO permite que você faça uma escolha informada que se alinhe aos requisitos e prioridades do seu aplicativo. Embora as filas padrão do SQS suportem uma taxa de transferência quase ilimitada, ela sacrifica a ordenação estrita das mensagens e, ocasionalmente, entrega as mensagens em uma ordem diferente daquela em que foram enviadas. Se manter a ordem exata dos eventos não for essencial para seu aplicativo, a utilização de filas padrão do SQS pode oferecer benefícios significativos em termos de produtividade e escalabilidade.
Por outro lado, as filas SQS FIFO garantem a ordenação das mensagens e o processamento exatamente uma vez. Isso os torna adequados para aplicações em que manter a ordem dos eventos é crucial, como transações financeiras ou fluxos de trabalho orientados por eventos. No entanto, as filas FIFO têm uma taxa de transferência menor em comparação com as filas padrão. Eles podem lidar com até 3.000 transações por segundo (TPS) por método de API com processamento em lote e 300 TPS sem agrupamento. Considere usar filas FIFO somente quando a ordem dos eventos for importante para o aplicativo, caso contrário, use filas padrão.
No exemplo de gerenciamento de inventário, como a ordem dos registros de inventário não é crucial, é improvável que a possível entrega de mensagens fora de ordem que pode ocorrer com as filas padrão do SQS afete o processamento do inventário. Isso permite que você aproveite os benefícios fornecidos pelas filas padrão do SQS, incluindo a capacidade de lidar com um grande número de transações por segundo.
Pilar de otimização de custos
O pilar de otimização de custos inclui a capacidade de executar sistemas para agregar valor comercial pelo menor preço. Ele recomenda as melhores práticas para criar e operar cargas de trabalho econômicas que alcancem resultados comerciais, minimizando os custos e permitindo que sua organização maximize o retorno sobre o investimento.
Prática recomendada: configurar etiquetas de alocação de custos para o SQS para organizar e identificar o SQS para alocação de custos
Uma estratégia de marcação bem definida desempenha um papel vital no estabelecimento de modelos precisos de estorno ou showback. Ao atribuir tags apropriadas aos recursos, como filas do SQS, você pode alocar custos com precisão para diferentes equipes ou aplicativos. Esse nível de granularidade garante uma alocação de custos justa e transparente, permitindo uma melhor gestão financeira e prestação de contas.
No exemplo de gerenciamento de inventário, a marcação da fila SQS permite o controle de custos específicos no departamento de inventário, permitindo uma avaliação mais precisa das despesas. O trecho de código a seguir mostra como marcar a fila do SQS usando o AWS Could Development Kit (AWS CDK).
Prática recomendada: use pesquisas longas (long polling)
O SQS oferece dois métodos para receber mensagens de uma fila: pesquisa curta (short polling) e pesquisa longa (long polling). Por padrão, as filas usam pesquisa curtas (short polling), em que a solicitação ReceiveMessage consulta um subconjunto de servidores para identificar as mensagens disponíveis. Mesmo que a consulta não tenha encontrado nenhuma mensagem, o SQS envia a resposta imediatamente.
Por outro lado, uma pesquisa longa (long polling) consulta todos os servidores na infraestrutura do SQS para verificar as mensagens disponíveis. O SQS responde somente após coletar pelo menos uma mensagem, respeitando o máximo especificado. Se nenhuma mensagem estiver imediatamente disponível, a solicitação será mantida aberta até que uma mensagem seja disponibilizada ou o tempo de espera da pesquisa expire. Nesses casos, uma resposta vazia é enviada.
A pesquisa curta fornece respostas imediatas, tornando-a adequada para aplicativos que exigem feedback rápido ou processamento quase em tempo real. Por outro lado, pesquisas longas são ideais quando a eficiência é priorizada em relação ao feedback imediato. Ele reduz as chamadas de API, minimiza o tráfego de rede e melhora a utilização de recursos, resultando em economia de custos.
No exemplo de gerenciamento de inventário, pesquisas longas aumentam a eficiência do processamento de atualizações de inventário. Ele coleta e recupera mensagens de atualização de inventário disponíveis em um lote de 10, reduzindo a frequência das solicitações de API. Essa abordagem de agrupamento em lotes otimiza a utilização de recursos, minimiza o tráfego de rede e reduz o consumo excessivo de API, resultando em economia de custos. Você pode configurar esse comportamento usando o tamanho do lote e a janela do lote:
Prática recomendada: use o tratamento por lotes
O agrupamento de mensagens em lote permite que você envie ou recupere várias mensagens em uma única chamada de API. Isso reduz o número de solicitações de API necessárias para processar ou recuperar mensagens em comparação ao envio ou recuperação de mensagens individualmente. Como o preço do SQS é baseado no número de solicitações de API, reduzir o número de solicitações pode resultar em economia de custos.
Para enviar, receber e excluir mensagens e alterar o tempo limite de visibilidade de várias mensagens com uma única ação, use ações de API em lote do Amazon SQS. Isso também ajuda a transferir menos dados, reduzindo efetivamente os custos de transferência de dados associados, especialmente se você tiver muitas mensagens.
No contexto do exemplo de gerenciamento de inventário, a função Lambda de processamento de CSV agrupa 10 registros de inventário em cada chamada de API, formando um lote. Ao fazer isso, o número de solicitações de API é reduzido em um fator de 10 em comparação com o envio de cada registro separadamente. Essa abordagem otimiza a utilização dos recursos da API, simplifica o processamento de mensagens e, em última análise, contribui para a eficiência de custos. A seguir está o trecho de código da função Lambda de processamento de CSV que mostra o uso de SendMessageBatch para enviar 10 mensagens com uma única ação.
Prática recomendada: use filas temporárias
No caso de mensagens leves e de curta duração com comunicação bidirecional síncrona, você pode usar filas temporárias. A fila temporária facilita a criação e a exclusão de muitos destinos temporários de mensagens sem aumentar sua fatura da AWS. O conceito-chave por trás disso é a fila virtual. As filas virtuais permitem que você multiplique muitas filas de baixo tráfego em uma única fila SQS. A criação de uma fila virtual apenas instancia um buffer local para armazenar mensagens para os consumidores quando elas chegam; não há nenhuma chamada de API para o SQS e não há custos associados à criação de uma fila virtual.
O exemplo de gerenciamento de inventário não usa filas temporárias. No entanto, em casos de uso que envolvem mensagens leves e de curta duração com comunicação bidirecional síncrona, a adoção da melhor prática de usar filas temporárias e filas virtuais pode aumentar a eficiência geral, reduzir custos e simplificar o gerenciamento dos destinos de mensagens.
Pilar de sustentabilidade
O Pilar da Sustentabilidade fornece as melhores práticas para atingir as metas de sustentabilidade para suas cargas de trabalho da AWS. Ele engloba considerações relacionadas à eficiência energética e otimização de recursos.
Prática recomendada: use pesquisas longas
Além dos benefícios de otimização de custos explicados como parte do Pilar de Otimização de Custos, as pesquisas prolongadas também desempenham um papel crucial na melhoria da eficiência de recursos, reduzindo as solicitações de API, minimizando o tráfego de rede e otimizando a utilização de recursos.
Ao coletar e recuperar as mensagens disponíveis em um lote, a sondagem prolongada reduz a frequência das solicitações de API, resultando em melhor utilização de recursos e minimização do tráfego de rede. Ao reduzir o consumo excessivo de API por meio de pesquisas longas, você pode usar os recursos de forma eficaz. Ele coleta e recupera mensagens em lotes, reduzindo o consumo excessivo de API e o tráfego de rede desnecessário.
Ao reduzir as chamadas de API, ele otimiza a transferência de dados e as operações de infraestrutura. Além disso, a abordagem de agrupamento por lotes da pesquisas longa otimiza a alocação de recursos, utilizando os recursos do sistema com mais eficiência e melhorando a eficiência energética. Isso permite que o sistema de gerenciamento de inventário lide com altos volumes de mensagens de forma eficaz enquanto opera de maneira econômica e eficiente em recursos.
Conclusão
Esta postagem do blog explora as melhores práticas para SQS usando o pilar de eficiência de desempenho, o pilar de otimização de custos e o pilar de sustentabilidade do AWS Well-Architected Framework. Abordamos técnicas como processamento em lote, agrupamento de mensagens e considerações de escalonamento. Também discutimos considerações importantes, como utilização de recursos, minimização do desperdício de recursos e redução de custos.
Esta série de publicações em três partes do blog abrange uma ampla variedade de melhores práticas, abrangendo os pilares de excelência operacional, segurança, confiabilidade, eficiência de desempenho, otimização de custos e sustentabilidade do AWS Well-Architected Framework. Seguindo essas diretrizes e aproveitando o poder do AWS Well-Architected Framework, você pode criar sistemas de mensagens robustos, seguros e eficientes usando o SQS.
Para obter mais recursos de aprendizado sem servidor, visite Serverless Land.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre o autor
Chetan Makvana
Hardik Vasa
Tradutor
Daniel Abib é Enterprise Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.