Componentes de uma infraestrutura de webhooks e suas funções

Em um artigo anterior desta série, olhamos para os requisitos de uma infraestrutura de webhooks confiável na perspectiva das partes interessadas. Depois pegamos essa definição do problema e a desdobramos em requisitos operacionais para um sistema de tratamento de webhooks confiável, tolerante a falhas e de alto desempenho. Por fim, propusemos um blueprint arquitetural para a solução.

Este artigo dá continuidade ao anterior olhando de perto cada componente da arquitetura proposta. Definimos o propósito, as opções de implementação, o design e as considerações de escalabilidade de cada componente.

Por fim, introduzimos o tema do desempenho de cada componente e como ele influencia o desempenho geral do sistema.

Revisão do design proposto de infraestrutura de webhooks

Para começar, vamos retomar a nossa solução proposta e então percorrer a arquitetura componente por componente.

Recapitulando, aqui está um resumo do fluxo da solução proposta:

• Os produtores de webhooks disparam requisições de webhook e as enviam para um API gateway.
• O API gateway adiciona as mensagens de webhook a filas de mensagens no message broker.
• O message broker faz o buffer das mensagens de webhook para processá-las de forma assíncrona e as roteia para um pool de consumidores.
• Um rate limiter fica entre o message broker e os consumidores, empurrando as mensagens a um ritmo que eles consigam suportar.
• Quando o processamento falha, dead letter queues coletam as mensagens com falha para serem reprocessadas por um sistema de retry.
• Métricas e logs são coletados em todos os componentes do sistema.
• Métricas e logs são usados para configurar alertas nos casos em que os administradores precisam agir.

Agora que você está em dia com a solução proposta, vamos ao detalhamento. Assim como a análise do artigo anterior, o nosso detalhamento dos componentes também será um processo de descoberta para entender o que funciona e o que não funciona.

Isso significa que o nosso design proposto está sujeito a mudanças conforme surgirem novas informações durante a análise de cada componente do sistema.

O produtor de webhooks

O primeiro componente do sistema é o produtor de webhooks, às vezes chamado de publicador de webhooks. Ele é a origem da requisição de webhook e envia webhooks pelo protocolo HTTP, embora a maioria dos provedores de webhooks de terceiros como GitHub, Okta e Shopify use (e exija) o protocolo seguro HTTPS.

A maioria dos produtores de webhooks usa um estilo de mensageria fire-and-forget. Isso significa que eles não pretendem esperar o processamento do webhook terminar e frequentemente impõem um limite de timeout para o tempo de resposta do consumidor.

A maior parte dos produtores de webhooks são aplicações SaaS de terceiros como GitHub e Shopify. No entanto, você também pode produzir webhooks dentro das suas aplicações customizadas para uso interno ou integração com aplicações externas.

Função dentro do sistema

Os produtores de webhooks iniciam ou disparam a operação de processamento assíncrono. A principal responsabilidade dos produtores é criar mensagens válidas para serem enviadas ao message broker por meio do API gateway.

O termo “válida” neste contexto significa que a mensagem contém todas as informações necessárias para o webhook ser processado e está no formato correto para ser recebida pelo API gateway. Os produtores direcionam as mensagens ao API gateway para que sejam adicionadas ao message broker.

Para lidar de forma eficaz com webhooks de produtores (externos ou internos), certos fatores precisam ser considerados. Esses fatores impactam como o processamento é feito, a taxa de sucesso no processamento de webhooks e a confiabilidade geral do sistema. Veja o nosso artigo “Considerações de implementação para produtores de webhooks em ambientes de produção” para mais informações.

O API gateway

Um API gateway faz a interface entre HTTP e outros protocolos e aplicações. Isso permite que clientes HTTP interajam com outras aplicações sem precisar conhecer outros protocolos.

Função dentro do sistema

A principal função do API gateway nesta arquitetura é servir como conversor de protocolo entre os produtores de webhooks (clientes HTTP) e o message broker. Message brokers como o RabbitMQ usam um protocolo binário e, portanto, não conseguem aceitar requisições HTTP diretamente sem um proxy.

O nosso API gateway vai falar HTTP do lado do produtor de webhooks e o protocolo do message broker do outro lado. Assim, o gateway serve como um relay de mensagens que interpreta requisições HTTP para serem ingeridas pelo broker.

Outra função do API gateway é atuar como acelerador de segurança. Aceleradores de segurança ajudam a receber e descriptografar tráfego HTTPS seguro, traduzindo-o para tráfego HTTP normal.

Às vezes os gateways usam software/hardware especial de descriptografia para decifrar tráfego seguro de forma mais eficiente que o servidor de origem, tirando essa carga do servidor de origem (neste caso, o consumidor de webhooks).

O nosso API gateway também vai adicionar um Trace ID a cada requisição de webhook para fins de logging e rastreamento. O Trace ID é um identificador especial em string que será refletido e pesquisável em todos os logs conforme a requisição atravessa cada componente da arquitetura.

As funções de descriptografia e rastreamento serão executadas antes da conversão de protocolo no API gateway.

Opções de implementação

Um API gateway é simplesmente um servidor proxy para pré-processar e rotear tráfego para um ou mais serviços. Existem vários softwares de servidor e serviços de nuvem que podem ser configurados e implantados para essa finalidade. Entre eles:

• Nginx: um servidor de load balancing e proxy reverso amplamente usado
• A combinação Amazon API Gateway + AWS Lambda

Você também pode usar servidores de aplicação de diversas linguagens de programação para receber, processar e repassar as suas requisições de webhook ao message broker.

Assim como o produtor de webhooks, o API Gateway responsável por transformar e enviar mensagens de webhook a um message broker também tem boas práticas recomendadas para uso em ambiente de produção.

O message broker de webhooks

Um message broker faz o buffer e distribui mensagens de forma assíncrona. Sistemas simples de enfileiramento podem ser construídos com arquivos simples, um componente customizado apoiado em um banco de dados, etc. No entanto, message brokers reúnem todas as funções necessárias para um sistema de processamento assíncrono confiável e completo.

Message brokers também são otimizados para alta concorrência e alto throughput, porque a capacidade de enfileirar mensagens rapidamente é uma das suas responsabilidades centrais.

Esse middleware orientado a mensagens é implantado como uma aplicação independente e escalado de forma independente.

Função dentro do sistema

Este é o coração das funções de processamento assíncrono da arquitetura. É o componente que cuida de aceitar, rotear, persistir e entregar as mensagens de webhook. É também o componente-chave para desacoplar os produtores dos consumidores de webhooks.

Quando o API gateway recebe um webhook de um produtor, ele converte a mensagem para o protocolo do broker (por exemplo, AMQP ou STOMP). O gateway então adiciona a mensagem ao message broker e devolve uma resposta ao produtor assim que recebe do broker a confirmação de que a mensagem foi adicionada.

Enquanto a mensagem está sendo adicionada ao broker, o gateway também inclui a chave de roteamento da mensagem. Essa chave permite que o sistema de roteamento do broker coloque a mensagem na fila (ou tópico) apropriada. Os consumidores inscritos naquela fila podem então pegar as mensagens e processá-las.

Quando mais de um assinante está inscrito em uma fila, o message broker cumpre a função de fazer o balanceamento de carga da tarefa de processamento entre os consumidores inscritos (o que significa que talvez não precisemos de um componente de load balancer separado para os nossos consumidores de webhooks, afinal).

Opções de implementação

Brokers são aplicações de software como bancos de dados e servidores web e normalmente não exigem código customizado; eles são configurados, não customizados.

Message brokers podem ser implantados usando tecnologias open source ou provedores de nuvem. RabbitMQ e Apache Kafka são dois dos softwares de message broker mais populares hoje, e alguns serviços de nuvem oferecem versões hospedadas dessas tecnologias. Eles também estão disponíveis como aplicações em container, o que facilita subi-los em um ambiente cloud-native.

Para usar essas opções open source, você precisa entender bem como a tecnologia funciona. É preciso estar familiarizado com a forma como ela roteia mensagens, trata permissões e escala com o aumento da carga, além das considerações gerais de desempenho.

Outra opção para montar um message broker é via provedor de nuvem. Provedores como Amazon Web Services, Google Cloud Platform e Azure têm diversas ofertas de enfileiramento de mensagens que você pode assinar.

A AWS tem o Amazon Simple Queue Service (SQS), o GCP tem o Cloud Pub/Sub e o Azure tem uma suíte de serviços de mensageria.

Uma vantagem de deixar as operações de enfileiramento por conta de provedores de nuvem é a configuração mais rápida. Além disso, a curva de aprendizado é menos íngreme, e eles costumam cuidar de todas as suas necessidades de escalabilidade, desempenho e monitoramento (muitas vezes a um preço).

O sistema de retry de webhooks

Falhas transitórias são comuns nas arquiteturas de nuvem atuais. Elas incluem a perda momentânea de conectividade de rede com componentes e serviços, timeouts causados por serviços sobrecarregados ou a indisponibilidade temporária de um serviço.

Como essas falhas são temporárias, o sistema precisa ser projetado para lidar com elas e se recuperar sozinho dos seus efeitos. Um sistema de retry é um dos recursos que podem ser embutidos na sua arquitetura em pontos propensos a falha, para garantir que qualquer operação que falhe seja repetida.

Função dentro do sistema

O sistema de retry da nossa arquitetura fica entre os consumidores de webhooks e o message broker. Quando o consumidor lança uma exceção ao processar um webhook, o sistema de retry recebe o erro e determina se e como a requisição será repetida.

Se a falha for transitória, o sistema de retry ajuda a reenfileirar a requisição no message broker ou adicioná-la à dead letter queue do broker, dependendo do tipo de erro. As mensagens de webhook podem então ser repetidas após um atraso, com a suposição de que o problema que causou a falha já terá sido resolvido.

Se necessário, esse processo se repete, e o período de espera aumenta a cada tentativa até que um número máximo de requisições tenha sido tentado. Os valores de espera podem crescer conforme a natureza da falha e a probabilidade de corrigi-la durante o período de espera. Esse aumento pode ser incremental ou exponencial.

Opções de implementação

Diferentemente dos outros componentes discutidos até aqui, um sistema de retry não é um componente de prateleira. Embora message brokers tenham recursos que suportam repetir operações que falharam durante o consumo de mensagens, você provavelmente vai ter que construir um sistema de retry customizado conforme as suas necessidades. Por exemplo, neste artigo, a Uber aproveita as dead letter queues do Kafka para desenvolver um sistema de retry confiável.

Provedores de nuvem também oferecem serviços que ajudam a configurar retries de requisições aos seus serviços. Por exemplo, o Google Cloud Spanner permite configurar timeouts e retries usando um arquivo especial de configuração JSON.

Cada SDK da AWS também implementa lógica automática de retry (inclusive o SDK do Amazon Simple Queue Service) e permite configurar os parâmetros de retry. A configuração da lógica de retry é um requisito de qualquer sistema de retry padrão.

O rate limiter de webhooks

Todo componente de uma arquitetura de nuvem tem capacidade limitada, incluindo o servidor em que ele roda. Exceder essa capacidade faz a aplicação ficar sem recursos e, portanto, sair do ar. Essa queda pode ser custosa para as operações do negócio e frequentemente propaga falhas em cascata para outros serviços upstream. É por isso que a maioria dos serviços de nuvem é limitada por um rate limit fixo de API que os consumidores não devem exceder.

O rate limiting ajuda a reduzir o tráfego e potencialmente melhora o throughput ao reduzir o número de requisições/registros enviados a um serviço em um dado período.

Função dentro do sistema

Na nossa arquitetura, um rate limiter é usado para controlar o consumo de mensagens do broker pelo pool de consumidores de webhooks. Isso garante que a capacidade dos consumidores não seja excedida, reduzindo bastante a probabilidade de algum deles sair do ar.

O rate limiter lê registros do message broker a um ritmo controlado, dentro da capacidade do consumidor (o número de webhooks concorrentes que um consumidor consegue processar em um dado período).

Uma das formas pelas quais o rate limiter evita sobrecarregar os consumidores é enviando pequenas quantidades de requisições com frequência em vez de grandes volumes de uma vez. Por exemplo, se o consumidor consegue processar 100 webhooks por segundo, o nosso rate limiter pode nivelar a carga enviando 20 webhooks a cada 200 milissegundos.

Opções de implementação

Assim como o sistema de retry, um sistema de rate limiting não é um componente de prateleira que possa ser baixado e instalado. Rate limiters são componentes customizados que podem ser implementados com algoritmos diferentes, cada um com prós e contras. Rate limiters também podem suportar conjuntos distintos de regras de throttling; por exemplo, podem limitar por número de requisições, tamanho de pacote, IP, etc.

Também podem ser implementados como um serviço separado (middleware de rate limiter) ou no código da aplicação. Veja neste blog como o Hookdeck conseguiu implementar um rate limiter escalável e altamente confiável para webhooks.

Se você não tem o conhecimento ou os recursos de engenharia para implementar um rate limiter, sempre pode assinar o API gateway de um provedor de nuvem que ofereça recursos de rate limiting.

Por exemplo, o Amazon API Gateway oferece recursos de rate limiting que podem ser configurados para as necessidades da sua infraestrutura.

O sistema de logging e monitoramento de webhooks

Para construir um pipeline de processamento de webhooks confiável e tolerante a falhas, precisamos de visibilidade total sobre todo o ciclo de vida de cada webhook. Logging e monitoramento nos ajudam a alcançar isso.

Ao acompanhar processos e erros pela coleta de logs e métricas de cada componente, os administradores conseguem investigar falhas de forma rápida e eficaz e conhecer o sistema para aprimorá-lo e ajustar o seu desempenho.

Também vamos adotar mecanismos de tracing que nos permitam ver todos os passos envolvidos no pipeline de processamento de webhooks.

Função dentro do sistema

A nossa arquitetura usa um agregador central de logs e um coletor de métricas. Esses dois puxam, respectivamente, logs e métricas de cada componente da infraestrutura de webhooks.

O agregador de logs coleta informações como metadados do webhook, sucesso ou falha das operações, horário das operações, dados de erro, motivos das falhas, o status de uma mensagem de webhook dentro de um componente e muito mais.

Já o nosso coletor de métricas reúne dados de uso de cada componente da infraestrutura. Informações como uso de memória, uso de CPU, disponibilidade do sistema, taxa de falhas, volume de tráfego de rede, número de requisições concorrentes e mais podem ser coletadas para entender e otimizar melhor o sistema.

Os coletores de logs e métricas também são integrados a sistemas de notificação que ajudam a comunicar informações úteis sobre os componentes e os webhooks aos administradores. Por exemplo, se um webhook falha várias vezes e excede o número máximo de retries, um administrador pode ser alertado para analisar o problema e reconciliar o webhook dentro do sistema.

O sistema de alertas também é usado para disparar processos automatizados, como retries.

Opções de implementação

Sistemas de logging e monitoramento podem ser implementados com tecnologias open source como o ELK Stack (Elasticsearch, Logstash e Kibana) para logging agregado ou o Prometheus para coleta de métricas. Também existem agregadores de logs pagos como o Splunk, que simplificam o processo de coleta.

Essas ferramentas já vêm com capacidades de alerta que permitem configurar eventos que enviam notificações aos administradores.

Elas também vêm com recursos de visualização que podem ser usados para construir dashboards e relatórios para um monitoramento eficaz. Você também pode combinar as suas ferramentas de monitoramento com ferramentas de visualização mais avançadas como o Grafana.

Provedores de nuvem também oferecem os seus próprios conjuntos de ferramentas de monitoramento e logging. A AWS oferece o CloudWatch, uma ferramenta completa de monitoramento de infraestrutura que pode ser usada para monitorar os seus recursos AWS e aplicações na AWS e on-premises.

O Azure também tem o Azure Monitor, que ajuda a aumentar o desempenho e a disponibilidade da sua infraestrutura de nuvem ao coletar, analisar e agir sobre telemetria dos seus ambientes de nuvem e on-premises.

O consumidor de webhooks

Consumidores são aplicações web que executam o processamento efetivo dos webhooks. A principal responsabilidade deles é traduzir a mensagem de um webhook em trabalho realizado dentro do sistema. Consumidores frequentemente expõem um endpoint de API que recebe webhooks de aplicações externas ou usam o protocolo do broker para ler mensagens do message broker.

Função dentro do sistema

O destino final dos webhooks na infraestrutura é o consumidor. Os consumidores puxam e processam mensagens do message broker. Para distribuir a carga, implantamos múltiplos consumidores em um pool de workers de processamento de webhooks. Todos eles são inscritos na fila do broker, e o volume de webhooks é distribuído de forma equilibrada entre eles.

Os consumidores também ajudam a reportar erros que ocorrem durante o processamento, gerando logs que podem ser usados para disparar ações corretivas e mitigar o erro. Por exemplo, se a verificação de health status de um consumidor indica que ele está fora do ar, podemos disparar o deploy de uma nova instância ou reiniciar o servidor que caiu.

Opções/considerações de implementação

Os consumidores podem ser implementados em diferentes tecnologias de linguagem de aplicação e mantidos de forma independente dos outros componentes.

É melhor isolar os consumidores de webhooks em um conjunto separado de servidores, para que a escalabilidade deles não dependa da escalabilidade dos outros componentes. Quanto mais independentes e encapsulados os workers, menor o impacto e a dependência em relação ao resto do sistema.

Outro princípio importante é que as máquinas de queue workers devem ser stateless, assim como servidores de aplicação web e máquinas de serviços web. Mantendo os queue workers stateless e isolados em um conjunto separado de máquinas, você consegue escalá-los horizontalmente simplesmente adicionando mais servidores.

Para mais sobre consumidores de webhooks e como eles trabalham com um message broker para produzir em níveis ideais, veja o nosso artigo "Filas de mensagens: um mergulho profundo." Você também deve considerar implementar idempotência nos seus consumidores para evitar processamento duplicado.

Conclusão

Neste artigo, conseguimos percorrer cada componente: o que ele faz, o seu propósito dentro da infraestrutura de webhooks e as diferentes opções de implementação. Ter um bom entendimento de cada componente ajuda a implantá-lo de forma a contribuir para o sucesso geral do sistema.

O próximo passo é entender como extrair o máximo deles.

Se construir e manter esses componentes por conta própria soa como um investimento significativo de engenharia, você está certo — é mesmo. Muitos times escolhem uma infraestrutura de webhooks gerenciada em vez de montar essas peças do zero. O Hookdeck Event Gateway consolida todos esses componentes — API gateway, fila de mensagens, sistema de retry, rate limiter, logging, monitoramento e gestão de consumidores — em um único serviço gerenciado, com mais de 160 fontes de webhooks pré-configuradas e observabilidade profunda. Para avaliar as suas opções de enfileiramento, veja o nosso guia sobre como escolher uma solução para enfileirar os seus webhooks, ou leia o nosso guia de build vs buy para avaliar os trade-offs.

Prévia das métricas de desempenho

Como mencionado na seção de logging e monitoramento, é importante acompanhar a forma como o sistema está sendo usado, como os recursos estão sendo utilizados e, de modo geral, monitorar a saúde e o desempenho do sistema.

Desempenho é medido principalmente em termos de disponibilidade do sistema, throughput operacional e tempo de resposta. No entanto, para determinar de verdade quão bem o nosso sistema está performando ou deveria performar, precisamos definir certos alvos de desempenho com base nas necessidades do negócio.

Uma forma recomendada de fazer isso é desdobrar os alvos de desempenho em um conjunto de indicadores-chave de desempenho (KPIs). Por exemplo, ao medir o desempenho dos nossos consumidores de webhooks, podemos ter os seguintes KPIs:

• O número de webhooks processados por segundo
• A latência por webhook
• O tempo de resposta por webhook
• A taxa com que os consumidores geram exceções, etc.

As medições de desempenho também devem incluir explicitamente um volume-alvo de webhooks. Isso nos ajuda a estabelecer um benchmark para as suposições que faremos sobre a carga de webhooks esperada no ambiente de produção.

Medir o desempenho do nosso sistema ajuda a entendê-lo melhor e fornece informações úteis para ajustá-lo em busca de maior eficiência.

No próximo título da série, vamos mergulhar nas medições de desempenho de cada componente da nossa infraestrutura de webhooks. Vamos definir alvos de desempenho para o sistema e coletar métricas que nos informem sobre ajustes que podem ser feitos para garantir que estamos obtendo o desempenho ideal de toda a infraestrutura de webhooks.