DEV Community: Marcos Belorio

Melhorando a observabilidade da sua aplicação - Logs

Marcos Belorio — Tue, 18 Mar 2025 14:40:06 +0000

Quando falamos de sistemas distribuídos e arquiteturas de microsserviços, a observabilidade é fundamental para o sucesso operacional. Diferente do simples monitoramento tradicional, a observabilidade nos permite não apenas identificar que algo está errado, mas entender por que está acontecendo.

Neste artigo, o primeiro dessa série que pretendo escrever sobre observabilidade, veremos algumas dicas de como melhorar os logs de uma aplicação para entender de maneira mais eficiente e clara o comportamento do seu sistema em produção.

Evite gerar logs excessivos sem filtragem adequada

Deixar sua aplicação gerar um volume excessivo de logs dificulta a equipe a encontrar dados relevantes no meio de tanta informação, além de poder comprometer o custo, considerando que muitos serviços de observabilidade cobram pela quantidade de logs que são ingeridos e armazenados.

Algumas dicas para ajudar:

Não crie logs irrelevantes. Seja crítico e reflita se aquele log trará algum benefício para uma análise futura da aplicação.
Evite gerar logs dentro de estruturas de loops na aplicação.
Filtre logs debug e trace em produção.
Filtre logs de bibliotecas e SDKs com informações irrelevantes.

Obs: Bibliotecas de logs já possuem essa funcionalidade de filtro. Por exemplo, em .NET você pode utilizar a biblioteca Serilog para configurar esses filtros.

Centralize os logs

Se você trabalha com sistemas distribuídos e/ou arquiteturas de microsserviços, centralizar todos os logs desses serviços em um único lugar para consulta e análise é essencial. Sem isso, a sustentação desses serviços será muito difícil.

Centralizar os logs ajudará a realizar consultas mais rápidas por não precisar alternar entre diferentes interfaces para visualizar os logs, assim como analisar e correlacionar diferentes serviços de maneira fácil.

Vale lembrar que não estamos falando somente de logs dos serviços que criamos, mas também de logs de serviços que você utiliza de provedores cloud, por exemplo.

Padronize o formato dos logs

Logs bem estruturados são mais fáceis de ler, filtrar e agrupar. Por isso, a maioria das aplicações utiliza o formato JSON para formatar os logs. Evite misturar diferentes formatos como JSON, texto simples e XML, principalmente se você precisa visualizar logs de diferentes aplicações/serviços.

Depois de adotado um formato padrão para o log (preferencialmente JSON), uma segunda definição importante é estabelecer um template padrão. Diferentes serviços gerando logs em diferentes templates dificultarão a realização de buscas em uma ferramenta centralizada. Por exemplo, em um serviço a propriedade se chama "message" e em outro serviço se chama "mensagem".

Outro ponto que geralmente recebe pouca atenção, mas que frequentemente cria dificuldades ao analisar os logs, é a formatação de datetime ou timestamp e fuso horário. Padronize para que todas as aplicações utilizem a mesma formatação e fuso horário para garantir uma análise consistente (você irá me agradecer no futuro, acredite hehehe).

Forneça contexto

Sempre ao criar um log, forneça o máximo de informações relevantes para ser possível identificar padrões de comportamento na aplicação. Evite mensagens genéricas como "Erro no sistema" ou "cliente cadastrado com sucesso". Existem vários tipos de informações que podem contribuir para um log mais completo, as principais são:

Informações sobre o ambiente: Dados de host, container, IP, configuração (dev/hom/prod), etc.
Informações sobre a aplicação/serviço: nome do serviço, versão de deploy, URL requisitada, nome da classe, nome do método, etc.
Identificadores de correlação: trace ID, request ID, correlation ID, etc.
Informações de contexto: Informações adicionais que fazem sentido para aquele log específico, como parâmetros de entrada, parâmetros de saída, qual ID foi gerado, qual usuário realizou aquela ação, etc.
Em caso de erro: Qual foi o erro, stack trace do erro (fornecerá os métodos e linhas por onde o erro percorreu), etc.

Como fornecer contexto da maneira correta

A maioria das informações exemplificadas acima será configurada para que a aplicação já forneça automaticamente para os logs, exceto as informações de contexto, que são dados que você fornecerá de forma específica para cada log. Tome o cuidado para não fornecer essas informações como string, pois isso dificultará filtros e agrupamentos nas ferramentas de observabilidade. O correto é fornecer esses dados como metadados do log, veja o exemplo abaixo em C#:

Forma incorreta:

log.LogInformation(
  $"Transação #{transactionId} processada: status={transactionStatus}, tipo={transactionType}."
);

Output gerado:

{
  ...
  "Message": "Transação #45892 processada: status=FINALIZADA, tipo=PAGAMENTO"
  ...
}

Forma correta:

log.LogInformation(
  "Transação #{transactionId} processada: status={transactionStatus}, tipo={transactionType}.", 
  transactionId, 
  transactionStatus, 
  transactionType
);

Output gerado:

{
  ...
  "Message": "Transação #45892 processada: status=FINALIZADA, tipo=PAGAMENTO",
  "Metadata":
  {
    "transactionId": 45892,
    "transactionStatus": "FINALIZADA",
    "transactionType": "PAGAMENTO"
  }
  ...
}

Remova dados sensíveis

Criar logs com dados sensíveis pode resultar em problemas jurídicos ou de segurança para sua aplicação. Não forneça dados que possam identificar uma pessoa como CPF, nome completo, email e afins. Dados como tokens e senhas também podem expor riscos de segurança.

Quando um dado sensível precisa realmente estar em um log para trazer contexto e sentido para ele, você pode optar pelo ofuscamento parcial da informação, como por exemplo, fornecer apenas os 5 primeiros números do CPF e ocultar o restante. Existem bibliotecas que podem ajudar com esse ofuscamento, e também as principais ferramentas de observabilidade permitem criar padrões de ofuscamento, geralmente mediante um custo adicional.

Utilize o nível de log correto

Logs não servem apenas para capturar erros; uma estratégia de logging robusta faz uso de todos ou quase todos os diferentes níveis de log. Embora os nomes de cada nível possam variar um pouco entre as linguagens de programação e ferramentas de observabilidade, geralmente são oferecidos seis níveis de log. Para este artigo, utilizarei os nomes dos níveis de log da Microsoft.

Nível	Descrição
Critical	Logs que descrevem um erro catastrófico irrecuperável na aplicação que impede que ela continue funcionando, exigindo atenção imediata.
Error	Logs que destacam quando o fluxo de execução atual é interrompido devido a um erro inesperado. Deve indicar um erro na atividade atual, não um erro em toda a aplicação.
Warning	Indica situações inesperadas ou potencialmente problemáticas mas que não impedem o funcionamento normal. Serve como alerta para possíveis problemas futuros.
Information	Captura eventos operacionais normais e marcos importantes do fluxo da aplicação, útil para rastrear o funcionamento geral do sistema.
Debug	Fornece informações detalhadas úteis para diagnóstico de problemas durante o desenvolvimento ou investigação de problemas; inclui valores de variáveis e fluxo de execução. Não possuem valor a longo prazo.
Trace	Registra o nível mais granular de informações, incluindo entrada/saída de métodos e detalhes de processamento interno; usado principalmente durante debugging intensivo. São desabilitadas por padrão e nunca devem ser habilitadas em ambiente de produção.

Configure um período de retenção de logs

Logs são caros para armazenar devido ao alto volume de dados. Configure um período de retenção adequado para o orçamento destinado à observabilidade.
Se sua aplicação precisa de um período maior de armazenamento de logs, considere transferir esses dados após um determinado período para um armazenamento mais econômico. Em algumas ferramentas de observabilidade, como o Datadog, isso é fácil de configurar.

Sobre retenção de logs, já participei de discussões onde foi defendido que o período de retenção deveria ser extenso (na casa de anos) pois os logs serviam como auditoria da aplicação. Acredito ser um equívoco utilizar os logs como auditoria, pois os dois possuem finalidades distintas (pode até virar tema de outro artigo hehe).

Performance

Por último, mas não menos importante, a aplicação não deve sofrer bloqueio da thread principal para operações de log. Utilize processamentos assíncronos e buffering de logs para melhorar a performance da aplicação.

Conclusão

Implementar boas práticas de logging é importante para construir uma estratégia de observabilidade eficiente. Com logs bem estruturados, padronizados e contextualizados, sua equipe estará melhor equipada para diagnosticar problemas rapidamente e entender o comportamento real do sistema em produção.

Se você possui alguma dica adicional, ou discorda de algum ponto, por favor, deixe um comentário. Será legal trocar experiências sobre o tema.

Cold Start no AWS Lambda: Entendendo seu comportamento e impacto

Marcos Belorio — Wed, 26 Feb 2025 16:13:36 +0000

Quem já trabalhou com o AWS Lambda já se deparou com o "temido" cold start hehehe, presente em praticamente toda discussão sobre o serviço e frequentemente citado como uma das principais preocupações ao utilizá-lo. A ideia desse artigo é tentar trazer um pouco mais de clareza sobre esse comportamento da Lambda e se de fato ele impacta negativamente o uso do serviço.

O que é um cold start?

O cold start refere-se ao tempo que uma função AWS Lambda leva para ficar pronta para executar o código implementado, é o seu tempo de inicialização no ambiente de execução. Isso ocorre quando ela é executada pela primeira vez ou após ficar ociosa por um período de tempo.

Como podemos ver na imagem acima, o cold start inclui o tempo de download do código da função e o tempo de inicialização do ambiente de execução.

Uma vez que a Lambda foi inicializada, invocações posteriores não sofrerão o cold start e utilizarão da mesma instância, a menos que, devido às demandas de tráfego, aumente o número de execuções concorrentes, resultando em novas invocações e novos cold starts. Para ajudar na visualização desse comportamento, veja a imagem abaixo:

Para processar execuções concorrentes, foi necessário a inicialização de novas instâncias, causando novos cold starts, porém algumas execuções (execução 6, 7, 8, 10) utilizaram de instâncias já inicializadas e por isso não tiveram o tempo de cold start somados ao tempo total de execução.

Impactos do cold start

O cold start pode adicionar desde alguns milissegundos até alguns segundos no tempo total de execução de uma Lambda, dependendo do tamanho da Lambda e alguns outros fatores, como por exemplo, o uso de VPC.

Outro dado importante é a taxa em que o cold start ocorre perante o total de execuções da Lambda. Isso pode variar muito dependendo do cenário de uso. Lambdas que são muito requisitadas e possuem um padrão de requisição com poucos picos tendem a ter uma taxa muito baixa de cold start, abaixo de 1%. Porém, Lambdas com um padrão de requisição com muitos picos ou Lambdas com pouca requisição tendem a ter taxas maiores de cold start. É muito importante acompanhar essa taxa através de ferramentas de observabilidade. Obs.: A própria AWS menciona que o valor geralmente é abaixo de 1% - Documentação AWS.

E é aqui que a história começa a ficar interessante. Frequentemente participo de discussões sobre Lambdas onde o cold start recebe atenção desproporcional, em muitos casos, vejo equipes descartando prematuramente o uso de Lambdas apenas por causa desse fator.

No entanto, como sempre dizemos na arquitetura de software: tudo depende do contexto (a clássica frase da arquitetura, hahaha). Existem cenários onde esse tempo adicional é aceitável, assim como há situações onde esse atraso torna-se inviável.

Cenários onde o cold start não é um problema

Cenário mais simples - Quando os cold starts são tão rápidos que não representam um problema

Isso geralmente ocorre com funções que utilizam runtimes como C++, Go e Rust e o código da Lambda é enxuto, facilitando a etapa de download. No entanto, você deve seguir as melhores práticas e otimizações em cada runtime para manter um cold start de baixo impacto.

Para conhecer melhor o benchmark de cold start por runtime, confira este Link.

Execução assíncrona

Outro caso simples é quando sua função é executada de forma assíncrona, seja por SQS, SNS, EventBridge, DynamoDB stream, etc. Nesses casos, um segundo adicional geralmente é aceitável e não representa um problema crítico.

Fluxos não críticos

Um tempo adicional de latência de 0,5-1 segundo importa em fluxos não críticos para 1% dos clientes? Provavelmente não, especialmente se for um fluxo interno entre serviços, sem exposição direta ao cliente. Geralmente SLOs de fluxos não críticos observam o percentil p95 ou p97, tolerando o cold start quando a taxa de cold starts se mantém em torno de 1%.

Cenários com impacto maior - Onde realmente é um problema

Quando o desempenho é essencial

Os cold starts prejudicam mais quando lidamos com fluxos voltados para o cliente onde o desempenho é crítico, mesmo para aqueles 1% dos clientes. Por exemplo, se você tem microsserviços dedicados à pagamento online que precisam operar com alta concorrência e concluir a execução em menos de 200 ms, 1% de um tempo adicional de 0,5-1 segundo pode ser inaceitável.

Quando a taxa de cold start é alta

Conforme vimos anteriormente, a taxa de cold start pode aumentar em cenários com muitos picos de requisição, cenários com poucas requisições ou ainda cenários com grandes variações, tornando o comportamento da Lambda imprevisível. Para esses casos sua função pode ter mais cold starts do que o usual, impactando mais do que 1% do total de requisições.

Estratégias para mitigar o cold start

Existem estratégias para tentar mitigar o cold start. Entre elas as principais são:

Configurar Provisioned Concurrency para sua Lambda (porém vai acarretar em um aumento significativo no custo da sua Lambda, que é uma das principais vantagens do serviço).
Aquecer sua função implementando mecanismos próprios onde executa a sua função de tempos em tempos de maneira forçada (Este método é menos eficaz para funções com muitas execuções concorrentes, pois sua execução forçada atingiria apenas uma das Lambdas já instanciadas).
Desenvolvendo funções Lambda em linguagens com menor tempo de cold start (C++, Rust ou Go).
Ajustando a memória da função para otimizar a inicialização.
Otimizando dependências e tamanho do pacote (existem muitos artigos na internet que exploram melhor essas otimizações).
Evitando VPCs sempre que possível! Configurar VPC na sua função requer que a Lambda crie ENIs (elastic network interface) para a VPC alvo, o que facilmente adiciona alguns segundos ao seu cold start.

Conclusão

Os cold starts podem desencorajar as pessoas de usar Serverless, e entendo esse ponto de vista, mas conforme vimos, existem casos e casos, não dá para generalizarmos em relação a esse comportamento. Ao usar o serviço AWS Lambda, é importante monitorar a taxa de cold start através de ferramentas de observabilidade para decisões mais embasadas.

Integrando o Amazon SQS com o AWS Lambda - Entendendo os principais aspectos dessa integração

Marcos Belorio — Tue, 18 Feb 2025 17:49:52 +0000

Neste artigo, a ideia é explorar todos os aspectos que envolvem essa que é uma das principais integrações no mundo serverless: uma Lambda consumindo mensagens do serviço SQS. Apesar de simples de criar, essa integração possui aspectos importantes (alguns desconhecidos pelos desenvolvedores) que impactam diretamente na confiabilidade da sua solução.

Conceitos Fundamentais

O Amazon SQS (Simple Queue Service) integrado ao AWS Lambda implementa um modelo de processamento baseado em polling, através de um mecanismo chamado event source mapping para criar um fluxo de processamento. O event source mapping é responsável por realizar uma chamada GET na API do SQS, agrupar os resultados em lotes e invocar de forma síncrona a Lambda. Conforme podemos ver na imagem abaixo:

Mecanismo de Processamento

A Lambda implementa o seguinte fluxo de processamento:

Polling das Mensagens
Como vimos, a Lambda realiza consultas periódicas à fila SQS e as mensagens são recuperadas em lotes. Cada lote gera uma única invocação da função Lambda.
Ciclo de Visibilidade
A partir daqui entra um aspecto importante da integração, o ciclo de visibilidade das mensagens. As mensagens permanecem na fila durante o processamento da Lambda, porém de forma oculta de acordo com o visibility timeout configurado na fila. Quando definimos um visibility timeout de 30 segundos, por exemplo, as mensagens que estão sendo processadas pela Lambda permanecerão invisíveis por este período, evitando assim que outros consumidores tentem processá-las simultaneamente.
Gerenciamento de Conclusão
Se o processamento for bem sucedido, a Lambda remove automaticamente as mensagens da fila. Caso a Lambda tenha uma falha no processamento, as mensagens retornam à fila após a expiração do visibility timeout.

Configurações de Processamento em Lote

O trigger SQS para a Lambda oferece configurações específicas para otimização do processamento:

Tamanho do Lote: Por padrão, agrupa 10 mensagens em uma única execução, mas pode ser aumentado até 10 mil mensagens para filas standard e 10 para filas FIFO.
Janela de Lote (Batch Window): Permite acumular mensagens por até 5 minutos antes de invocar o processamento da Lambda.

Quando um desses dois critérios é alcançado, dispara a execução da Lambda.

Garantias de Processamento

O mecanismo de event source mapping garante processamento "at least once", que significa que uma mensagem será processada pelo menos uma vez, podendo ocorrer processamentos duplicados. Para gerenciar esta característica, é importante a Lambda possuir mecanismo de idempotência.

Mecanismos de Tratamento de Erros

A Lambda implementa automaticamente um mecanismo de tratamento de erros que reduz gradualmente a escalabilidade (Lambdas executando em paralelo) durante o consumo de mensagens da fila SQS, prevenindo assim que erros ocorram em larga escala na sua aplicação.

Em casos de throttling (quando a Lambda retorna erro 429 too many requests), a Lambda tenta reprocessar a mesma mensagem até que o visibility timeout na fila expire. Após esse período, caso o processamento não tenha sido bem sucedido, a mensagem é descartada. 😱😱😱

Respostas Parciais de Lote

Por padrão, quando sua função Lambda encontra um erro durante o processamento de um lote, todas as mensagens daquele lote voltam a ficar visíveis na fila, incluindo as que foram processadas com sucesso. Isso pode resultar em dois problemas:

Se a sua Lambda não tratar idempotência, você pode gerar dados duplicados.
Mesmo se a Lambda tratar idempotência, haverá um reprocessamento desnecessário de mensagens que já foram processadas com sucesso anteriormente.

Para resolver esse problema podemos implementar as respostas parciais de lote, onde a Lambda executa com sucesso, porém parcial. Na prática, a Lambda remove da fila as mensagens que foram processadas com sucesso e as que foram processadas com erro permanecem na fila para serem reprocessadas.

Para implementar o sucesso parcial é necessário alterar para true o valor da propriedade Report batch item failures no trigger SQS da Lambda e também alterar o retorno da Lambda informando os ids de mensagens que foram processadas com erro, igual este exemplo:

{ 
  "batchItemFailures": [ 
        {
            "itemIdentifier": "id2"
        },
        {
            "itemIdentifier": "id4"
        }
    ]
}

Obs.: Para algumas linguagens existem bibliotecas da AWS que implementam essa classe de retorno para facilitar o desenvolvimento.

Pontos importantes sobre respostas parciais:

Anteriormente foi mencionado o mecanismo de tratamento de erro da Lambda que evita que erros ocorram em larga escala na sua aplicação, pois bem, com o Report batch item failures ativado, a Lambda não utiliza mais esse mecanismo visto que as execuções serão sempre com sucesso (mesmo que parcial).
Se sua Lambda lançar uma exceção não tratada, o lote inteiro é considerado como falha completa.
Para filas FIFO, sua Lambda deve interromper o processamento após a primeira falha e retornar na resposta todas as mensagens que falharam ou não foram processadas, para preservar a ordenação das mensagens.

Entendendo como o event source mapping escala as Lambdas

Filas Standard (Padrão)

Ao iniciar o consumo de uma fila SQS standard, o event source mapping instância 5 Lambdas em paralelo, cada uma consumindo um lote de mensagens, se a fila continua com mensagens disponíveis, a Lambda continua escalando até 300 novas instâncias por minuto. O número máximo de lotes sendo processados simultaneamente é de 1000.

Filas FIFO

Nas filas FIFO, a Lambda processa as mensagens na ordem em que as recebe. Ao enviar uma mensagem para uma fila FIFO, você especifica um MessageGroupId. O Amazon SQS garante que as mensagens do mesmo grupo sejam entregues a Lambda em ordem. Quando o event source mapping agrupa as mensagens em lotes, cada lote pode conter mensagens de diferentes grupos, mas sempre mantendo a ordem das mensagens de mesmo MessageGroupId. Se sua função retornar um erro, todas as tentativas de reprocessamento das mensagens afetadas são realizadas antes que a Lambda receba mensagens adicionais do mesmo grupo, por isso erros em filas FIFO podem comprometer consideravelmente o escalonamento das Lambdas.

Configuração da Concorrência Máxima

Existem dois motivos que podem fazer você considerar controlar o quanto a Lambda pode escalar ao consumir uma fila SQS:

Esgotar o limite de instâncias de Lambda executando em paralelo na região, podendo afetar outras Lambdas que também estão executando na sua conta AWS. Isso porque por padrão uma conta AWS possui o limite de 1000 instâncias de Lambda sendo executadas simultaneamente por região (esse limite é aplicado sobre todas as Lambdas da região, e não para cada uma).
Sua Lambda pode requisitar alguma API, banco ou qualquer outro serviço que talvez não suporte altos picos de utilização.

Para isso a trigger SQS da Lambda possui a propriedade Maximum concurrency onde você pode limitar o teto de escalonamento da Lambda.

Alguns pontos importantes sobre essa configuração:

Maximum concurrency e Reserve concurrency são configurações distintas.
Maximum concurrency não deve ser superior à Reserve concurrency da Lambda.
Caso a Lambda tenha múltiplos triggers SQS, a configuração de Reserve concurrency deve ser maior ou igual à soma do Maximum concurrency de todas as triggers.
Caso algum desses pontos acima não seja respeitado, a execução da Lambda pode resultar em throttling.

Em filas FIFO, as execuções simultâneas são limitadas pelo menor valor entre:

O número de IDs de grupo de mensagens (messageGroupId).
A configuração de concorrência máxima (Maximum concurrency).

Por exemplo, com seis IDs de grupo de mensagens e concorrência máxima configurada para 10, sua função terá no máximo seis execuções simultâneas.

Considerações Finais

Entender os aspectos dessa integração é fundamental para implementar uma Lambda robusta, garantindo um processamento confiável das mensagens e um sono tranquilo nas suas noites hehehehe.

Se você estiver começando a usar o serviço Amazon SQS, recomendo a leitura deste artigo sobre os erros mais comuns ao utilizar o SQS.

Todos os pontos abordados nesse artigo estão contidos na documentação oficial da AWS que você pode encontrar nos links de referência logo abaixo.

Referências

Using Lambda with Amazon SQS
Configuring scaling behavior for SQS event source mappings
Handling errors for an SQS event source in Lambda

Construindo Integrações Serverless Sem Código na AWS

Marcos Belorio — Tue, 11 Feb 2025 14:47:47 +0000

Olá, pessoal! Nesse artigo eu pretendo mostrar uma forma interessante de se trabalhar com integrações serverless na AWS. Vamos modificar uma integração tradicionalmente utilizada na AWS utilizando Lambda para uma integração sem código.

O Cenário Inicial: A Arquitetura Clássica

Quando iniciamos no mundo serverless na AWS fazemos uma arquitetura típica usando Lambda, como por exemplo o fluxo abaixo:

Uma requisição chega no API Gateway
O API Gateway aciona uma função Lambda
A Lambda processa e envia para uma fila SQS

Parece familiar, não é? É aquela arquitetura que vemos em praticamente todos os tutoriais serverless por aí.

A Descoberta: Integrações Nativas

Mas aí veio aquele momento "aha!" que todo desenvolvedor adora. Durante uma palestra no AWS Summit São Paulo 2023 que eu participei, foi apresentado como o API Gateway da AWS pode se integrar com outros serviços diretamente sem a necessidade de processamento computacional, como por exemplo, uma Lambda. Isso significa que podemos fazer nossa API se comunicar diretamente com o SQS, sem precisar de código!

Vantagens e Desvantagens Dessa Solução

Vantagens

Simplicidade e Menos Código: Reduz a quantidade de serviços e a manutenção de código, já que não existe código hehehe.
Baixa Latência: Como a integração é direta, a latência da requisição é menor em comparação com uma requisição API → Lambda → SQS. (Não vai mais precisar se preocupar com o cold start da Lambda).
Custo: Sem custos de processamento computacional, você paga apenas pelo API Gateway e pelo SQS. (Aqui existe um disclaimer, o API Gateway deve ser do tipo API REST para essa integração direta com o SQS poder ocorrer, esse tipo de API Gateway é mais caro porém provê outros recursos adicionais. Se os demais recursos não fizerem sentido para a sua solução, usar a combinação API Gateway tipo API HTTP → Lambda → SQS possa ficar mais barato hehehe).

Desvantagens

Sem Processamento ou Validação: Não é possível validar, processar, modificar ou enriquecer os dados antes de enviá-los.
Limitação no tamanho do payload: O SQS suporta mensagens de até 256 kb.

Como Configurar

Se você ficou interessado pela solução e quer testar ela, este vídeo da própria AWS ensina como criar e configurar um api gateway com SQS no console da cloud.

Considerações Finais: Quando Usar?

Eu particularmente gosto de utilizar essa solução em cenários onde a API deve retornar o status code 202 (Accepted), ou seja, quando a requisição é recebida com sucesso, mas o processamento será feito de forma assíncrona. E você? enxerga algum outro cenário onde essa solução se aplica bem?

Ficou com alguma dúvida? Quer compartilhar suas experiências com integrações serverless? Deixe nos comentários - adoraria saber sua opinião!

Erros comuns ao usar o Amazon SQS

Marcos Belorio — Mon, 12 Aug 2024 13:48:03 +0000

O Amazon Simple Queue Service (SQS) é um serviço de mensageria totalmente gerenciado e serverless, muito popular por ser simples, altamente escalável e robusto. A proposta desse artigo é trazer alguns erros comuns que devemos nos atentar ao utilizar o serviço.

Configurar o visibility timeout muito baixo

O visibility timeout determina por quanto tempo uma mensagem permanece indisponível após ser consumida. Se o consumidor não deletar a mensagem antes do término desse período, a mensagem retorna à fila para ser processada novamente.

Um erro comum é configurar o visibility timeout com um valor que não permita tempo suficiente para o consumidor processar a mensagem. Isso pode resultar em problemas como o processamento duplicado da mesma mensagem, já que o consumidor pode concluir o processamento, mas não conseguir deletar a mensagem antes que ela volte para a fila.

Solução

A AWS recomenda configurar o visibility timeout para ser seis vezes maior que o tempo estimado de processamento da mensagem. Isso ajuda a cobrir cenários de exceção, como eventuais lentidões no processamento.

Configurar o retention period muito baixo

O retention period é usado para determinar o tempo de vida de uma mensagem na fila, uma vez expirado esse tempo, a mensagem é apagada, mesmo não tendo sido consumida.

Configurar o retention period de forma errada pode causar perda de mensagens na sua aplicação.

Solução

Defina um valor generoso para o retention period, lembrando que a AWS não cobra pelo armazenamento das mensagens no SQS. Além disso, é recomendável configurar o retention period máximo de 14 dias para filas DLQ (Dead-Letter Queues). Isso dá ao time de suporte tempo suficiente para identificar e resolver problemas relacionados a essas mensagens, permitindo o reprocessamento adequado.

Esperar que as mensagens sejam consumidas na mesma ordem que foram enviadas

O serviço SQS possui dois tipos de filas, o tipo standard e o tipo FIFO, o tipo standard possui um throughput maior mas não garante a ordem das mensagens, somente o tipo FIFO.

Solução

Se você precisa garantir a ordem do consumo das mensagens, então você deve utilizar a fila do tipo FIFO. Quando você envia uma mensagem para uma fila FIFO, você precisa fornecer um MessageGroupId, esse atributo garante a ordenação entre as mensagens de mesmo id. Lembrando que a fila FIFO não garante ordenação entre mensagens que possuem MessageGroupId diferentes.

Enviar/Consumir mensagens individualmente

O envio ou consumo de mensagens de forma individual pode impactar tanto a performance quanto o custo da aplicação, visto que a AWS cobra pela quantidade de requisições ao serviço do SQS.

Solução

A API do SQS permite o envio e o consumo de mensagens em batch, reduzindo o número de requisições ao serviço e, consequentemente, diminuindo os custos. Do ponto de vista de performance, realizar menos requisições com mais dados em cada uma delas tende a ser mais eficiente, pois reduz o número de viagens de ida e volta na rede.

Enviar mensagens em batch sem conhecer os limites da action SendMessageBatchCommand

Quando começamos a enviar mensagens em batch pro serviço do SQS, é importante considerar os limites da action SendMessageBatchCommand. Esta action limita o batch a 10 mensagens e o tamanho total da requisição a 256KB, note que o limite de tamanho se aplica à requisição total, não a cada mensagem individualmente. Se uma requisição exceder um desses limites, o batch inteiro de mensagens é recusado, gerando erro na sua aplicação.

Solução

Implemente uma lógica na sua aplicação ou utilize alguma lib que garanta o envio de até 10 mensagens e até 256kb por requisição.

Não tratar o sucesso parcial da action SendMessageBatchCommand

Outro ponto que traz um pouco mais de complexidade ao usar o envio de mensagens em batch é o fato de que a requisição pode retornar um sucesso parcial. Isso significa que, dentro de uma única requisição, algumas mensagens podem ser enviadas com sucesso, enquanto outras podem falhar. Se esse cenário não for tratado na aplicação, pode resultar em perda de mensagens.

Solução

Ao usar a action SendMessageBatchCommand, sua aplicação deve sempre verificar a resposta recebida. Se houver mensagens que não foram enviadas com sucesso, esse cenário deve ser tratado de maneira apropriada, como, por exemplo, tentando reenviar as mensagens falhas.

Lançar erros durante o consumo de mensagens em batch

Mais um cenário comum que pode resultar em perda de mensagens ou processamento duplicado é a falta de tratamento durante o consumo de mensagens em batch. Normalmente, o consumo de mensagens em batch é realizado dentro de um loop na aplicação, onde cada mensagem é processada individualmente. Como cada processamento pode lançar erros, é necessário que a aplicação esteja preparada para lidar com essas exceções, para não afetar o lote inteiro.

Solução

Em filas do tipo Standard onde a ordenação das mensagens não é relevante, se o processamento de uma mensagem resultar em erro, a aplicação deve permitir que as demais mensagens continuem sendo processadas. As mensagens não processadas devem ser devolvidas à fila para tentativas futuras de processamento. No entanto, para filas do tipo FIFO, onde a ordem das mensagens é importante, se uma mensagem falhar no processamento, a aplicação deve interromper o processamento imediatamente. Todas as mensagens não processadas devem ser devolvidas à fila para tentativas futuras de processamento, ou o lote inteiro pode ser devolvido caso a aplicação esteja preparada para lidar com o consumo duplicado de mensagens.

Não tratar duplicidade de mensagens

Por último, aplicações que utilizam mensageria devem estar preparados para um possível cenário de mensagens duplicadas, podendo causar inconsistência de dados.

Solução

Aplicar estratégias de idempotência durante o consumo de mensagens, seja diretamente na fila ou no momento da persistência dos dados. Aqui no meu blog eu escrevi como tratar Idempotência em filas do serviço AWS SQS.

Referências

SendMessageBatchCommand
What happens if SQS messages partially fail in SendMessageBatch?

Idempotência em filas do serviço AWS SQS

Marcos Belorio — Mon, 12 Jun 2023 21:22:46 +0000

Problema

Quando trabalhamos com aplicações que consomem mensagens de uma fila, um cenário que pode ocorrer é a fila possuir mensagens duplicadas em um fluxo funcional onde isso não poderia acontecer, causando uma inconsistência de dados em nossa aplicação. Esse problema pode ocorrer geralmente por dois motivos:

Houve um problema de rede que impediu que o publicador da mensagem recebesse o status da requisição feita ao SQS, fazendo com que seja requisitado novamente.
Por falta de validações prévias ou algum bug, funcionalmente o publicador acabou enviando a mesma mensagem para a fila.

Solução

Existem algumas formas de se resolver esse problema, uma delas é utilizando filas do tipo FIFO no serviço AWS SQS. As filas FIFO possuem uma propriedade chamada MessageDeduplicationId. Se uma mensagem for enviada com um MessageDeduplicationId específico, todas as mensagens enviadas com o mesmo MessageDeduplicationId serão aceitas pela fila, porém NÃO serão entregues durante o intervalo de 5 minutos.

Formas de trabalhar com a propriedade MessageDeduplicationId

Existem duas formas de se trabalhar com essa propriedade:

A primeira é deixando a cargo do próprio SQS gerar o identificador ativando o "Content-based deduplication" nas configurações do SQS. Ao ativar essa configuração, é gerado um identificador único baseado no conteúdo do corpo da mensagem (não se aplica aos atributos da mensagem).
A segunda forma de se trabalhar com o MessageDeduplicationId é passando manualmente um valor ao publicar uma mensagem na fila.

Cenários recomendados para trabalhar manualmente com o MessageDeduplicationId

O publicador adiciona alguma informação no corpo da mensagem que sempre faz com que o conteúdo seja diferente.
Mensagens com informações nos atributos que também deveriam ser levados em consideração para determinar se a mensagem é duplicada.

Executando Tasks em paralelo em aplicações .Net com o SemaphoreSlim

Marcos Belorio — Fri, 11 Mar 2022 12:54:56 +0000

Introdução

Neste artigo vamos entender como executar tasks de forma paralela, visualizar possíveis problemas que poderemos causar em nossas aplicações e aprender a utilizar a classe SemaphoreSlim para nos ajudar a gerenciar a execução das tasks.

Cenário

Imagine uma aplicação onde será necessário de tempos em tempos processar uma massa de dados relativamente grande (entre 1 mil à 10 mil registros) e para cada registro processado, enviá-lo em uma requisição http. Para essa massa de dados poder ser executada em um tempo aceitável será necessário efetuar processamentos em paralelo.

Exemplificando o cenário

Vamos criar um trecho de código simples onde iremos simular o processamento de 10 mil registros de forma paralela:

static void Main(string[] args)
{        
    var timer = new Stopwatch();
    Console.WriteLine($"Início da execução");

    timer.Start();
    ProcessarMassaDeDados();
    timer.Stop();

    Console.WriteLine($"Tempo: {timer.Elapsed:m\\:ss\\.fff}");
    Console.ReadKey();
}

static void ProcessarMassaDeDados()
{
    var listOfTasks = new List<Task>();
    for (int i = 0; i < 10000; i++)
    {
        listOfTasks.Add(ProcessarRegistro());
    }
    Task.WaitAll(listOfTasks.ToArray());
}

static async Task ProcessarRegistro()
{
    var _httpClient = HttpClientFactory.Create();
    await _httpClient.GetAsync("http://httpstat.us/200?sleep=1000");
}

Como podemos ver no código acima, primeiro criamos uma lista de tasks e adicionamos a task ProcessarRegistro 10 mil vezes dentro dessa lista, após isso executamos todas elas em paralelo através do comando Task.WaitAll, esse comando aguarda a conclusão de todas as tasks para poder seguir. Dentro do método ProcessarRegistro estamos fazendo uma requisição http que demora um segundo para ser executado.

Rodando esse trecho de código temos o seguinte resultado no meu computador:

Início da execução
Tempo: 1:37.821

Se não executássemos essas tasks em paralelo, iria levar pelo menos 10 mil segundos (166 minutos) para executar tudo, já que cada requisição dura um segundo.

Olhando esses números o código acima parece nos atender bem, porém esse código só executou bem porque estamos testando em um ambiente local, sem concorrência significativa pelos recursos do sistema. Em um ambiente de produção, onde o sistema pode estar processando centenas de outras requisições simultaneamente, a execução desse código pode não ser tão eficiente. Problemas como esgotamento de recursos (estouro de memória, limite de rede, sobrecarga no banco de dados, etc) pode causar lentidões e até mesmo quebrar a aplicação. Portanto, é crucial considerar esses fatores e implementar mecanismos de controle para evitar a sobrecarga do sistema ao processar tarefas em paralelo.

Conhecendo a classe SemaphoreSlim

O .Net possui uma classe chamada SemaphoreSlim que limita o número de tarefas que podem ser executadas simultaneamente.

Vamos modificar o nosso código e adicionar essa classe para gerenciar as execuções em paralelo:

static void Main(string[] args)
{        
    var timer = new Stopwatch();
    Console.WriteLine($"Início da execução");

    timer.Start();
    ProcessarMassaDeDadosComSemaforo();
    timer.Stop();

    Console.WriteLine($"Tempo: {timer.Elapsed:m\\:ss\\.fff}");
    Console.ReadKey();
}

static void ProcessarMassaDeDadosComSemaforo()
{
    var semaphoreSlim = new SemaphoreSlim(100, 100);
    var listOfTasks = new List<Task>();
    for (int i = 0; i < 10000; i++)
    {
        listOfTasks.Add(ProcessarRegistro(semaphoreSlim));
    }
    Task.WaitAll(listOfTasks.ToArray());
}

static async Task ProcessarRegistro(SemaphoreSlim semaphoreSlim)
{
    await semaphoreSlim.WaitAsync();

    var _httpClient = HttpClientFactory.Create();
    await _httpClient.GetAsync("http://httpstat.us/200?sleep=1000");

    semaphoreSlim.Release();
}

Como podemos ver, instanciamos a classe SemaphoreSlim e no seu construtor passamos respectivamente o número inicial de solicitações que podem ser executadas simultaneamente e o número máximo de solicitações que podem ser executadas simultaneamente.

Isso significa que após 100 tasks estarem sendo executadas em paralelo, a próxima só será executada quando uma dessas 100 terminarem, limitando sempre a no máximo 100 tasks em paralelo.
Obs: No código acima foi usado a quantidade de 100 execuções em paralelo somente como forma de exemplo, o ideal é você calibrar esse número de acordo com o seu cenário e ambiente.

Dentro do método ProcessarRegistro usamos o método semaphoreSlim.WaitAsync() e semaphoreSlim.Release(), eles que são os responsáveis respectivamente por fazer a execução aguardar e para liberar uma posição no semáforo.

Rodando o código com as modificações temos o seguinte resultado no meu computador:

Início da execução
Tempo: 2:23.149

Podemos perceber que o processamento demora um pouco mais porém os recursos do ambiente são utilizados de maneira controlada.

Conclusão

Quando criamos uma aplicação devemos sempre considerar que o ambiente em execução possui recursos limitados. A classe SemaphoreSlim pode ser uma boa solução para utilizar esses recursos de maneira controlada.

Referências

SemaphoreSlim Class - Microsoft Documentation
Using SemaphoreSlim to Make Parallel HTTP Requests in .NET Core
Understanding Semaphore in .NET Core

Criando dados fake para testes em .Net

Marcos Belorio — Wed, 12 May 2021 11:24:29 +0000

Olá, hoje vou apresentar uma biblioteca muito interessante capaz de gerar dados aleatórios muito precisos na nossa língua portuguesa (e outras línguas também) chamada Bogus.

Problema a ser solucionado

Frequentemente nos vemos diante de um teste ou criação de uma POC (proof of concept) onde necessitamos de uma massa de dados para validar nosso código, esses dados necessitam ser o mais parecido possível com o que esperamos para não deixarmos passar nenhum detalhe em nossas validações. Muitas vezes optamos por criar esses dados na mão, mas dependendo da quantidade necessária levamos muito tempo criando, as vezes até duplicando dados.

Nesse contexto a biblioteca Bogus nos auxilia muito, ela é capaz de gerar uma massa de dados do tamanho que você necessita, de forma rápida sem repetir nenhum registro, com suporte a diferentes línguas e muitas opções de dados para que o teste fique o mais real possível.

Demonstração

Para demonstrar o uso da biblioteca, iremos criar um projeto console em .Net e adicionar a biblioteca através do gerenciador de pacotes nuget ou da execução do comando:

dotnet add package Bogus

Vamos também criar nossa classe Pessoa (mais clássico impossível hahahaha), que será utilizada para gerar nossa massa de dados.

public class Pessoa
{
    public int Id { get; set; }
    public string Nome { get; set; }
    public string Email { get; set; }
    public DateTime DataNascimento { get; set; }
    public string Telefone { get; set; }
}

Pronto, vamos agora começar a usar a biblioteca para gerar alguns dados. Dentro da classe Program da nossa aplicação console iremos configurar para ser gerado um objeto Pessoa.

Pessoa pessoa = new Faker<Pessoa>("pt_BR")
    .RuleFor(x => x.Id, f => f.Random.Int(1))
    .RuleFor(x => x.Nome, f => f.Name.FullName())
    .RuleFor(x => x.Email, (f, u) => f.Internet.Email(u.Nome))
    .RuleFor(x => x.DataNascimento, f => f.Date.Past(50))
    .RuleFor(x => x.Telefone, f => f.Phone.PhoneNumberFormat())
    .Generate();

Console.WriteLine(JsonConvert.SerializeObject(pessoa, Formatting.Indented));

Se você já utilizou a biblioteca FluentValidation deve estar reconhecendo a forma de configurar, é praticamente igual.

Olhando o código podemos ver que estamos instanciando a classe Faker passando Pessoa como tipo genérico e setando a língua para português do Brasil, isso ajuda muito a termos dados mais precisos.

A partir dai criamos uma regra para cada propriedade da classe Pessoa.

.RuleFor(x => x.Id, f => f.Random.Int(1))

Setando para a propriedade Id um valor aleatório inteiro sendo o valor mínimo 1.

.RuleFor(x => x.Nome, f => f.Name.FullName())

Setando para a propriedade Nome um nome completo aleatório.

Veja no exemplo abaixo que a biblioteca é tão legal que podemos até especificar se queremos um nome do sexo masculino ou feminino.

.RuleFor(x => x.Nome, f => f.Name.FullName(Bogus.DataSets.Name.Gender.Male))

.RuleFor(x => x.Email, (f, u) => f.Internet.Email(u.Nome))

Setando para a propriedade Email um email aleatório baseado no nome gerado anteriormente.

.RuleFor(x => x.DataNascimento, f => f.Date.Past(50))

Setando para a propriedade DataNascimento uma data baseada nos últimos 50 anos.

.RuleFor(x => x.Telefone, f => f.Phone.PhoneNumberFormat())

Setando para a propriedade Telefone um número já formatado no padrão utilizado aqui no Brasil.

Rodando a aplicação teremos no console o resultado:

Como podemos ver nos exemplos acima são muitas opções de customização para os dados fazendo com que o resultado seja muito próximo de um dado real.

Criando uma grande quantidade de dados

Olhando novamente o exemplo anterior, quem faz de fato o objeto ser criado é o método Generate(), sendo assim se você precisar de 500 registros, basta você setar Generate(500) que ele irá gerar 500 registros sendo nenhum deles repetido, segue um exemplo.

List<Pessoa> pessoaLista = new Faker<Pessoa>("pt_BR")
    .RuleFor(x => x.Id, f => f.Random.Int(1,100))
    .RuleFor(x => x.Nome, f => f.Name.FullName())
    .RuleFor(x => x.Email, (f, u) => f.Internet.Email(u.Nome))
    .RuleFor(x => x.DataNascimento, f => f.Date.Between(Convert.ToDateTime("01/01/1990"), Convert.ToDateTime("01/01/2000")))
    .RuleFor(x => x.Telefone, f => f.Phone.PhoneNumberFormat())
    .Generate(500);

Projeto de exemplo

Caso tenha ficado ainda alguma dúvida no código, você pode ver o exemplo que eu criei nesse repositório do Github.

Se gostou utilize os botões do lado esquerdo para que eu possa saber. Caso tenha alguma dúvida, sugestão ou crítica, deixe um comentário logo abaixo.

Muito obrigado!

Design Pattern - Strategy

Marcos Belorio — Wed, 28 Apr 2021 11:36:38 +0000

Vamos falar hoje de um pattern bem interessante quando trabalhamos com programação orientada a objetos, que pode ser aplicado em muitos casos do nosso dia a dia. Durante esse artigo vamos conhecer a definição do pattern, ver um exemplo de código que frequentemente nos deparamos no dia a dia e como podemos melhorá-lo aplicando o pattern.

Os exemplos desse artigo serão em C# porém o pattern é facilmente aplicado em outras linguagens.

Definição

Segundo Erich Gamma em seu livro sobre Design Patterns, a definição para o pattern strategy é:

Definir uma família de algoritmos, encapsular cada uma delas e torná-las intercambiáveis. Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam.

Implementando um exemplo para pagamentos

No nosso exemplo iremos criar um código para efetuar pagamento, seja ele por cartão de crédito, débito e outras modalidades. Para isso então vamos criar suas interfaces.

public interface IPagamentoCartaoCreditoService
{
    string EfetuarPagamento(decimal valor);
}

public interface IPagamentoCartaoDebitoService
{
    string EfetuarPagamento(decimal valor);
}

Criamos uma interface para cada forma de pagamento que possui declarado o método EfetuarPagamento.

Vamos agora implementar as classes concretas das interfaces.

public class PagamentoCartaoCreditoService 
    : IPagamentoCartaoCreditoService
{
    public string EfetuarPagamento(decimal valor) 
        => $"Pagamento efetuado com o cartão de crédito no valor de R${valor}";
}

public class PagamentoCartaoDebitoService 
    : IPagamentoCartaoDebitoService
{
    public string EfetuarPagamento(decimal valor) 
        => $"Pagamento efetuado com o cartão de débito no valor de R${valor}";
}

E por fim vamos implementar nossa regra de pagamento.

public class PagamentoService
{
    private readonly IPagamentoCartaoCreditoService _cartaoCreditoService;
    private readonly IPagamentoCartaoDebitoService _cartaoDebitoService;

    public PagamentoService(IPagamentoCartaoCreditoService cartaoCreditoService,
        IPagamentoCartaoDebitoService cartaoDebitoService)
    {
        _cartaoCreditoService = cartaoCreditoService;
        _cartaoDebitoService = cartaoDebitoService;
    }

    public string EfetuarPagamento(FormaPagamentoEnum formaPagamento, decimal valor)
    {
        if (formaPagamento == FormaPagamentoEnum.CartaoCredito)
            return _cartaoCreditoService.EfetuarPagamento(valor);
        else if (formaPagamento == FormaPagamentoEnum.CartaoDebito)
            return _cartaoDebitoService.EfetuarPagamento(valor);
        else
            throw new Exception("Forma de pagamento não encontrada.");
    }
}

Implementamos um método para efetuar o pagamento e dependendo do valor passado pelo enum ele efetua o pagamento por cartão de crédito ou por cartão de débito. Acredito que você já tenha visto um código similar a esse, note que não tem nada de errado nesse código, mas agora vamos ver o que precisamos para implementar uma nova forma de pagamento.

Implementar a nova forma de pagamento (interface e classe concreta)
Modificar o construtor da classe PagamentoService passando a interface da nova forma de pagamento.
Criar uma nova condição if para poder ser utilizado essa nova forma de pagamento.

Se atualizarmos esse código com dez novas formas de pagamento (o que não é difícil hoje em dia com tantas opções de pagamento hehehe) teremos um código cada vez maior, complexo e aberto constantemente a modificações (o que vai contra a letra 'O' dos princípios do SOLID).

Então vamos aplicar algumas melhorias nesse código com o nosso pattern strategy.

Implementando o pattern strategy

Vamos começar criando apenas uma interface de pagamento de forma genérica.

public interface IPagamentoService
{
    FormaPagamentoEnum formaPagamento { get; }
    string EfetuarPagamento(decimal valor);
}

Perceba que agora definimos o enum dentro da interface também. As classes concretas são implementadas à partir desta interface.

public class PagamentoCartaoCreditoService 
    : IPagamentoService
{
    public FormaPagamentoEnum formaPagamento 
        => FormaPagamentoEnum.CartaoCredito;

    public string EfetuarPagamento(decimal valor) 
        => $"Pagamento efetuado com o cartão de crédito no valor de R${valor}";
}

public class PagamentoCartaoDebitoService 
    : IPagamentoService
{
    public FormaPagamentoEnum formaPagamento 
        => FormaPagamentoEnum.CartaoDebito;

    public string EfetuarPagamento(decimal valor) 
        => $"Pagamento efetuado com o cartão de débito no valor de R${valor}";
}

E agora vem a parte mais interessante que é a implementação do pattern.

public class PagamentoStrategyService 
    : IPagamentoStrategyService
{
    private readonly IEnumerable<IPagamentoService> _services;

    public PagamentoStrategyService(IEnumerable<IPagamentoService> services)
    {
        _services = services;
    }

    public string EfetuarPagamento(FormaPagamentoEnum formaPagamento, decimal valor)
    {
        return _services.FirstOrDefault(x => x.formaPagamento == formaPagamento)?
            .EfetuarPagamento(valor) ?? 
            throw new ArgumentNullException(nameof(formaPagamento));
    }
}

Como temos duas classes que implementam a mesma interface IPagamentoService, recebemos no construtor um IEnumerable contendo as duas implementações. No método de efetuar pagamento criamos uma expressão lambda filtrando qual implementação da interface IPagamentoService iremos utilizar à partir do valor do enum.

Muito simples não? Você não vai mais precisar de vários if else, a classe estará pronta para receber quantas formas de pagamento forem necessárias sem precisar modificá-la. Toda vez que precisarmos implementar uma nova forma de pagamento o único passo será:

Implementar a nova forma de pagamento (classe concreta utilizando a interface IPagamentoService)

Projeto de exemplo

Caso tenha ficado ainda alguma dúvida no código, você pode ver o exemplo que eu criei nesse repositório do Github.

Se gostou utilize os botões do lado esquerdo para que eu possa saber. Caso tenha alguma dúvida, sugestão ou crítica, deixe um comentário logo abaixo.

Muito obrigado!

Referências:
What You Need To Know About The Helpful Strategy Pattern
WestDiscGolf/StrategyPatternExample

Resiliência em aplicações .Net com Polly

Marcos Belorio — Mon, 12 Apr 2021 15:41:52 +0000

Neste artigo vou abordar o uso da lib Polly para criarmos políticas de retry e circuit breaker em requisições http dentro de nossa aplicação.

Problema a ser solucionado

Frequentemente precisamos lidar com requisições http dentro de nossas aplicações para consumir dados fornecidos por aplicações externas, as famosas requisições para apis, nesse contexto a lib Polly ajuda a criar comportamentos através da criação de políticas que tornam a nossa aplicação mais resiliente a possíveis falhas dessas requisições.

Política de retry

Essa política serve para lidarmos principalmente com indisponibilidades momentâneas, vamos imaginar que realizamos uma requisição a uma api e por algum motivo ela está sendo muito requisitada e está apresentando lentidões para responder, nesse cenário estamos propícios a talvez receber um erro 408 de timeout da api, mas esse cenário pode ser momentâneo, talvez tentando mais uma vez ou depois de algum tempo, pode ser que a api esteja respondendo normalmente. Nesse cenário a política de retry se encaixa muito bem, podemos definir uma quantidade de tentativas em um espaço de tempo para que seja possível obter um retorno de sucesso da requisição.

Política de circuit breaker

Você já deve ter utilizado algum aplicativo que estava apresentando lentidões para carregar os dados e você efetuou o comando de atualizar os dados (geralmente é o movimento de arrastar para baixo) e o aplicativo respondeu instantaneamente que não foi possível atualizar. Provavelmente o aplicativo estava com a política de circuit breaker ativada. Essa política auxilia em evitar tentativas desnecessárias, para que não seja sobrecarregado ainda mais uma aplicação já sobrecarregada. O desenvolvedor define uma quantidade limite de erros em sequência para ativar o circuit breaker, uma vez ativado, ele fica com o circuito aberto e não realiza novas requisições até que o circuito seja fechado novamente, esse tempo em que o circuito fica aberto é também configurado na política.

Demonstração

O exemplo que eu irei mostrar a seguir também está publicado no GitHub.

Vamos criar um novo projeto web api e criar uma controller com um endpoint para podermos realizar os nossos testes.

namespace HttpClientPollyExample.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class HttpBinController : ControllerBase
    {
        private readonly IHttpBinService _service;

        public HttpBinController(IHttpBinService service)
        {
            _service = service;
        }

        [HttpGet("{code:int}")]
        public async Task<IActionResult> Get([FromRoute] int code)
        {
            await _service.Get(code);
            return Ok();
        }
    }
}

Vamos agora criar a classe service e sua interface que está sendo passada via injeção de dependência no construtor da controller.

namespace HttpClientPollyExample.Interfaces
{
    public interface IHttpBinService
    {
        Task Get(int code);
    }
}

namespace HttpClientPollyExample.Services
{    
    public class HttpBinService : IHttpBinService
    {
        private readonly HttpClient _httpClient;
        public HttpBinService(HttpClient httpClient)
        {
            _httpClient = httpClient;
        }

        public async Task Get(int code)
        {
            var response = await _httpClient.GetAsync($"http://httpbin.org/status/{code}");
            Console.WriteLine(response.IsSuccessStatusCode);
        }
    }
}

Como podemos ver no código da classe service, estamos fazendo uma requisição http para a api httpbin (uma ótima api disponível para realizar testes) e passando o parâmetro code na rota, esse endpoint irá forçar o status code do retorno conforme o code que passarmos na rota, exemplo, se passarmos o valor 200 o endpoint irá retornar status code 200, se passarmos 500, irá retornar status code 500. Isso irá nos ajudar a simular os casos de uso das políticas do polly.

Agora vem a parte mais importante, iremos configurar o Polly em nossa aplicação. Primeiro vamos adicionar os pacotes necessários.

dotnet add package Polly
dotnet add package Polly.Extensions.Http
dotnet add package Microsoft.Extensions.Http.Polly

Vamos agora criar as duas configurações das políticas de retry e circuit breaker. Por ser apenas uma demo eu adicionei na Startup.cs pois será lá que iremos utilizá-las.

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy(int retryCount)
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .WaitAndRetryAsync(retryCount, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));
}

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy(int exceptionsAllowedBeforeBreaking, 
    int durationOfBreakInSeconds)
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .CircuitBreakerAsync(exceptionsAllowedBeforeBreaking, TimeSpan.FromSeconds(durationOfBreakInSeconds));
}

Vamos analisar as configurações, as duas políticas foram setadas com o handler HandleTransientHttpError(), se lermos a descrição dele vamos ver que a configuração irá valer para os seguintes erros:

Falhas de rede (System.Net.Http.HttpRequestException)
HTTP 5XX status codes (server errors)
HTTP 408 status code (request timeout)

Na política de retry passamos a quantidade de tentativas que serão realizadas e o intervalo de tempo entre elas, para isso setamos o valor TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)) que irá dobrar o tempo entre cada tentativa começando por 2 segundos.

Na política de circuit breaker passamos a quantidade de exceções em sequência que serão aceitas antes de ativar o circuit breaker e o tempo que o circuito ficará aberto caso ele tenha sido ativado.

Por último vamos aplicar as duas políticas a nossa service que criamos utilizando AddHttpClient() e a extensão AddPolicyHandler().

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddHttpClient<IHttpBinService, HttpBinService>()
        .AddPolicyHandler(GetRetryPolicy(retryCount: 3))
        .AddPolicyHandler(GetCircuitBreakerPolicy(exceptionsAllowedBeforeBreaking: 5, durationOfBreakInSeconds: 30));
}

Setamos para a política de retry 3 tentativas e para a política de circuit breaker 5 erros em sequência para ativá-lo e 30 segundos para o circuito fechar após aberto, vamos testar agora.

Execute a aplicação e chame o endpoint passando o valor 500 para o parâmetro code [GET]http://localhost:5000/httpbin/500 e veja o resultado no console.

O endpoint da api httpbin está retornando erro status code 500 e por isso foi tentado mais três vezes, conforme destacado na print, com isso conseguimos testar nossa política de retry.

Agora execute mais uma vez o endpoint passando o code 500 e veja o resultado novamente no console.

Como já tínhamos recebidos 4 erros em sequência no teste anterior, executamos a quinta requisição com erro e o circuit breaker foi ativado retornando uma exceção para a sexta chamada. Você pode tratar a exceção Polly.CircuitBreaker.BrokenCircuitException para ter um comportamento mais amigável na aplicação.

Conhecendo o Azure Functions

Marcos Belorio — Thu, 01 Apr 2021 19:52:32 +0000

Nesse artigo vamos conhecer o Azure Functions, o serviço de computação em nuvem serverless da Azure. Além de explicar o que é o Azure Functions, vamos ver suas vantagens e desvantagens, suas diferentes formas de executar e exemplos de como implementar. Mais artigos sobre o assunto serão postados em breve por possuir bastante recursos para explorarmos.

O que é Azure Functions?

Azure Functions é um serviço computacional capaz de executar pedaços de código sem a necessidade de construir uma infraestrutura para isso, por isso é chamado de serverless.

As Azure Functions são disparadas/executadas a partir de um evento, os principais eventos utilizados são:

HTTP Request - Executado quando requisitado via http (igual uma api).
Timer - Executado de tempos em tempos ou em uma data específica.
Service Bus - Executado quando uma nova mensagem chega na fila ou tópico.

Existem outros eventos que podem disparar uma Azure Function e a cada atualização é adicionado novos triggers, você pode checar todos os triggers disponíveis clicando aqui.

Vantagens e desvantagens

Principais vantagens ao utilizar Azure Functions:

Sem infraestrutura para dar manutenção - Por possuir a infraestrutura totalmente abstraída dentro do serviço, não é necessário se preocupar em administrar ou dar manutenção na infraestrutura, tudo isso é feito pela Azure.
Não é cobrado quando não executado - No plano de consumo as funções são cobradas por execuções realizadas, então mesmo o serviço estando disponível 24 horas por dia, você não é cobrado pela disponibilidade do serviço, diferente de uma VM ou o App Service. Isto não se aplica no plano "App Service Plan".
Escalável automaticamente - o serviço auto gerencia as execuções das funções e sempre garante disponibilidade escalando automaticamente recursos caso necessário, tudo isso invisível para nós.
Redução da complexidade do sistema - Com uma plataforma serverless podemos escrever e executar trechos de código sem se preocupar com complexidades de implantação como sistema operacional, hardware ou servidores.

Principais desvantagens:

Ficar preso ao fornecedor - Desenvolver uma aplicação utilizando Azure Functions acaba te prendendo ao fornecedor, neste caso a Azure, isso pode dificultar uma possível mudança de plataforma.
Dificuldade em debugar - É possível debugar as Azure Functions, mas nem sempre é uma tarefa simples recriar o cenário desejado, principalmente quando o número de funções é muito grande.

Bindings de entrada e saída

Uma das facilidades em utilizar o Azure Functions são os bindings de entrada e saída. Você pode criar uma função onde ela se comunica com recursos externos de uma forma automática e transparente, sem você se preocupar em codificar para isso. Os bindings podem te ajudar tanto a receber um dado de algum recurso como também enviar um dado para algum recurso.

Vamos ver o exemplo abaixo:

public static IActionResult Run([HttpTrigger("POST")] HttpRequest request, 
    [Blob("content/settings.json")] string json)

Podemos ver que usamos um HttpTrigger que além de ser nossa trigger que irá disparar a função ela também recebe os dados da requisição http na variável request, e do lado temos um binding do tipo Blob onde recebe na variável json o conteúdo do arquivo settings.json que está armazenado em um serviço de Blob Storage na Azure. Você pode checar todas as possibilidades de binding clicando aqui.

Vamos fazer um exemplo para vermos na prática o uso de trigger e os bindings.

Demonstração

O Azure Functions permite que você escreva seu código em diversas linguagens como C#, Javascript e Python, esse exemplo será usando C#. Para o nosso exemplo iremos utilizar o Azure Storage Table, um banco NoSQL bem simples e barato da Azure.

Então vamos começar logando no portal da Azure (https://portal.azure.com/) e vamos criar uma nova storage account para conseguirmos utilizar o banco Azure Storage Table.

Após o portal terminar de criar o recurso, vamos entrar na storage account e clicar em access keys no menu lateral e copiar a connectionstring do recurso (pode ser qualquer uma das duas).

Agora vamos pro Visual Studio e criar um novo projeto escolhendo Azure Functions.

Vamos criar uma nova função utilizando a trigger Http trigger.

Projeto criado, vamos adicionar o pacote nuget via Visual Studio ou comando:

dotnet add package Microsoft.Azure.WebJobs.Extensions.Storage

Com este pacote conseguiremos usar a nossa storage account na Azure.

Próximo passo é setarmos a connectionstring da storage account, para isso edite o arquivo local.settings.json

{
  "Values": {
    "AzureWebJobsStorage": "<sua-connectionstring>",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet"
  }
}

Pronto, agora o projeto está preparado para fazermos nossa Azure Function.

using Microsoft.Azure.WebJobs;
using System;

namespace AzureFunctionsExemplo
{
    public class FunctionUsuarioSalvar
    {
        [FunctionName("UsuarioSalvar")]
        [return: Table("Usuario")]
        public Usuario UsuarioSalvar([HttpTrigger("POST")] dynamic request)
        {
            return new Usuario
            {
                PartitionKey = "Http",
                RowKey = Guid.NewGuid().ToString(),
                Login = request.Login
            };
        }
    }

    public class Usuario
    {
        public string PartitionKey { get; set; }
        public string RowKey { get; set; }
        public string Login { get; set; }
    }    
}

Pronto, com apenas esse código fizemos uma function que recebe dados à partir de uma requisição http e salva o mesmo em um banco NoSql, não precisa ser feito mais nada. Apesar de ser só um exemplo de demonstração, podemos ver como é muito simples trabalharmos com as Azure Functions. Vamos analisar o código:

[FunctionName("UsuarioSalvar")] - Com esse annotation declaramos o nome da função que será usado pelo Azure.
[return: Table("Usuario")] - Esse annotation é um binding de saída de dados, estamos utilizando o binding do Azure Storage Table e dizendo que iremos salvar na tabela Usuario.
public Usuario UsuarioSalvar([HttpTrigger("POST")] dynamic request) - Note que aqui estamos retornando a classe Usuario o que irá ser feito o binding de saída e também temos declarado a nossa trigger HttpTrigger com o verbo POST recebendo um objeto dynamic.
E por fim retornarmos o objeto Usuario contendo o Login que foi passado via requisição http e as duas propriedades obrigatórias do Azure Storage Table que são o PartitionKey e o RowKey. A PartitionKey serve para criarmos separações entre os documentos presentes na tabela e o RowKey é um identificador único para cada documento.

Execute a aplicação e veja que no console foi disponibilizado um endpoint devido termos usado uma function http trigger, agora é só utilizar o endpoint que iremos ver a requisição sendo salva no banco. No caso aqui eu uso o aplicativo Postman para fazer a chamada do endpoint e o aplicativo Microsoft Azure Storage Explorer para visualizar os dados no banco.

Sua function agora está pronta para ser publicada na Azure. Após terminar os testes não se esqueça de excluir o Resource Group utilizado no portal da Azure.

Referência:
Serverless computing pros and cons: 5 benefits and 3 drawbacks

Cancelando Tasks assíncronas em C#

Marcos Belorio — Fri, 12 Mar 2021 13:33:37 +0000

Uma das boas práticas ao trabalhar com Tasks assíncronas em C# é utilizar o CancellationToken, possibilitando que a execução pare quando solicitada.

Se você ainda não está familiarizado com o uso de Tasks Assíncronas e as palavras chaves async e await, recomendo ler este outro post antes:
Trabalhando com Tasks assíncronas em C#

Executando requisições sem a possibilidade de cancelamento

Vamos criar um exemplo mostrando como é a execução de uma requisição sem a possibilidade de cancelamento, para isso iremos criar o seguinte endpoint em uma aplicação web api:

[HttpGet]
public async Task<IActionResult> Get()
{
    Console.WriteLine("Iniciando");

    //simulando um processamento de 10 segundos
    await Task.Delay(10000);

    Console.WriteLine("Finalizando após 10 segundos");

    return Ok("Finalizado");
}

Executando no navegador esse endpoint e aguardando o retorno com a mensagem "Finalizado", podemos ver o console da aplicação desse jeito:

Iniciando
Finalizando após 10 segundos

Agora execute novamente no navegador o endpoint, mas antes da requisição terminar aperte f5 (atualizar) duas vezes, o console irá ficar assim:

Iniciando
Iniciando
Iniciando
Finalizando após 10 segundos
Finalizando após 10 segundos
Finalizando após 10 segundos

Concluímos que mesmo atualizando a página no navegador, todas as requisições foram totalmente processadas, mesmo as que não tiveram tempo de retornar no navegador o response por ter sido atualizado antes. Esse comportamento pode ser esperado caso a requisição efetue alguma persistência em banco por exemplo, mas também pode ser um desperdício de processamento caso a requisição não mude nenhum estado da aplicação.

Usando o CancellationToken

CancellationToken é um objeto leve capaz de notificar caso a requisição tenha sido cancelada. Passar um CancellationToken como parâmetro para um método que retorne uma Task é uma boa prática, dando a possibilidade para o chamador do método desistir do resultado.

Vamos refazer o exemplo acima utilizando o CancellationToken:

[HttpGet]
public async Task<IActionResult> Get(CancellationToken ct)
{
    Console.WriteLine("Iniciando");

    //simulando um processamento de 10 segundos
    await Task.Delay(10000, ct); 

    Console.WriteLine("Finalizando após 10 segundos");

    return Ok("Finalizado");
}

Note que foi passado um CancellationToken como parâmetro para o método Task.Delay(). Agora execute novamente no navegador o endpoint, e atualize a página antes da requisição terminar, o console irá ficar assim:

Iniciando
fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
      An unhandled exception has occurred while executing the request.
System.Threading.Tasks.TaskCanceledException: A task was canceled.    
//toda stack do erro
Iniciando
Finalizando após 10 segundos

Diferente do outro exemplo onde a primeira requisição foi totalmente processada, dessa vez ela retornou uma exceção avisando que a Task foi cancelada e não chegou a ser totalmente processada.

Caso seja necessário você pode tratar essa exceção, como por exemplo retornar um erro amigável, através das exceptions TaskCanceledException ou OperationCanceledException.

Manipulando CancellationToken em seu código

Ao criar um método que retorne uma Task, você pode verificar o CancellationToken para impedir que a execução do código continue. Podemos fazer assim:

private async Task DoSomething(CancellationToken token)
{
    token.ThrowIfCancellationRequested();

    //Algum comportamento aqui
}

No exemplo acima o método retorna uma exceção caso a requisição tenha sido cancelada.
Você também pode criar seu próprio comportamento quando a requisição for cancelada, ao invés de retornar uma exceção, veja o exemplo abaixo:

if (token.IsCancellationRequested)
{
    //Algum comportamento aqui
}

Outra forma de se trabalhar com o CancellationToken é definir um timeout para ele ser cancelado, ou seja, se a execução passar do tempo definido no token, o token será cancelado. Vamos ver um exemplo:

[HttpGet]
public async Task<IActionResult> Get()
{
    Console.WriteLine("Iniciando");

    //Criando um CancellationTokenSource com timeout de 5 segundos
    CancellationTokenSource cts = new CancellationTokenSource(5000);
    CancellationToken ct = cts.Token;

    //simulando um processamento de 10 segundos
    await Task.Delay(10000, ct);

    Console.WriteLine("Finalizando após 10 segundos");

    return Ok("Finalizado");
}

Podemos ver que criamos um CancellationToken onde será automaticamente cancelado após 5 segundos, como nosso código simula um processamento de 10 segundos, o método será cancelado antes de ser totalmente executado.

Por último, caso você precise utilizar um método que obrigue você passar um CancellationToken mas por algum motivo você espera que aquele código sempre seja executado independente se a requisição foi cancelada ou não, passe o token dessa forma:

await DoSomething(CancellationToken.None);

Dessa forma você está passando um token vazio, então ele não terá nenhum comportamento.

Referências:
Using CancellationTokens in ASP.NET Core MVC controllers
Cancel asynchronous operations in C#