Monitoramento de performance, ajuste de escalabilidade e estimativa de recursos da infraestrutura de webhooks

O verdadeiro teste de confiabilidade de qualquer solução que lida com webhooks é a capacidade de manter altos níveis de performance independentemente do volume processado. À medida que o seu sistema é submetido à pressão de uma carga crescente de webhooks, o tráfego de rede e o volume de dados a processar aumentam, o que consome recursos mais rapidamente. Em seguida vem a degradação da performance e, muitas vezes, a queda do sistema.

Sem uma instrumentação adequada de monitoramento no seu sistema de processamento de webhooks, pode ser muito difícil investigar gargalos de performance, o que por sua vez atrapalha o processo de remediação.

Neste artigo, vamos usar a solução de webhooks proposta na nossa série para demonstrar como configurar o monitoramento de performance. Depois vamos mostrar como definir indicadores-chave de performance (KPIs) para a sua solução de webhooks, o que ajuda a estimar os recursos necessários para atingir as suas metas.

Entendendo como monitorar a performance da nossa solução de webhooks

Para determinar se a performance da nossa solução de webhooks é boa ou ruim, primeiro precisamos entender bem em que nível o sistema deveria ser capaz de operar.

A solução de webhooks é composta por vários componentes, e a performance geral depende da performance de cada um deles. Quando um componente falha, a performance do sistema provavelmente cai. Conseguir detectar essa queda ajuda a tomar medidas para resolver o problema e medidas mais proativas para evitá-lo no futuro.

A performance de cada componente da solução, e do sistema como um todo, depende de uma série de fatores que costumam ser medidos por indicadores-chave de performance (KPIs). Esses KPIs podem ser medições diretas de uma métrica específica de um componente ou um valor derivado de um grupo de métricas. Exemplos incluem o número de webhooks concorrentes processados por um consumidor, o volume de tráfego de rede até o API gateway, o tempo médio de processamento de webhooks pelos consumidores etc.

As capacidades de cada componente estão ligadas a essas métricas, e entender os limites de cada um ajuda a definir os patamares dentro dos quais ele opera de forma ideal. Por exemplo, um consumidor de webhooks tem um limite de quantos webhooks consegue processar simultaneamente com base nos seus recursos (memória, I/O etc.). Se esse limite for ultrapassado, o consumidor fica sobrecarregado e sofre uma queda de performance (aumento de latência, aumento do tempo de resposta dos webhooks etc.) que pode levar a uma queda total quando os recursos do sistema se esgotarem. Monitorar essas métricas de perto ajuda a evitar esse tipo de degradação e de cenário de falha.

Quando ocorre uma queda de performance (por exemplo, por causa de um aumento de latência nos webhooks que chegam ao API gateway), um administrador precisa conseguir investigar o problema até os detalhes mais básicos. Isso inclui ver onde está o gargalo, o que o causou, a que horas começou, qual componente é a origem real e como o problema está afetando a performance geral do sistema.

Quais são os requisitos para monitorar a performance?

Medir performance exige observar o sistema em funcionamento sob uma carga típica de produção e capturar dados de cada KPI ao longo de um período. Rodar o sistema sob essa carga simulada em um ambiente de teste ajuda os engenheiros a coletar dados adequados antes de colocar a solução em produção.

Métricas de alto nível

Para examinar a performance da solução de webhooks, é importante capturar os seguintes tipos de métricas de alto nível para cada componente e/ou para o sistema como um todo:

• A taxa de resposta após receber um webhook.
• O número de webhooks concorrentes sendo processados.
• O volume de tráfego de rede até um componente.
• A taxa com que um componente conclui o seu trabalho (throughput).
• O tempo médio de processamento de cada webhook.

Também é vantajoso usar ferramentas de monitoramento que ajudem os administradores a identificar relações entre as métricas coletadas. Por exemplo:

• A correlação entre o número de webhooks concorrentes e a latência dos webhooks (quanto tempo leva para começar a processar um webhook depois que ele é recebido).
• A correlação entre o número de webhooks concorrentes e o tempo médio de resposta (quanto tempo o consumidor leva para concluir o processamento de um webhook).
• A correlação entre o volume de requisições de webhook e o número de erros de processamento etc.

Métricas de alto nível são ótimas e dão uma visão rápida do problema e do seu efeito no sistema. No entanto, quando se trata de investigar problemas, as métricas de baixo nível obtidas da utilização de recursos no nível do componente são a chave para resolvê-los.

Métricas de baixo nível

Junto com as informações funcionais de alto nível, os administradores precisam ter informações detalhadas sobre a performance de cada componente do sistema. Esse tipo de informação vem principalmente de métricas de baixo nível, como:

• Tempo de processamento de CPU
• Número de threads em uso
• Uso de memória
• Taxas e erros de I/O de escrita em disco
• Taxas e erros de I/O de rede
• Tamanho da fila de mensagens

Note que esta é apenas uma lista breve dos tipos de métrica que deveríamos capturar. Mais adiante no artigo vamos focar nas métricas de cada componente da nossa infraestrutura de webhooks.

Visualização das métricas

Um dashboard de visualização intuitivo também é um requisito muito importante para monitorar com eficácia a performance da nossa solução de webhooks. Essa visualização ajuda os administradores a dar sentido aos dados e a relacioná-los.

Todas as visualizações também devem permitir que o administrador selecione um período para a consulta. Os dados exibidos podem dar tanto um retrato do estado atual da performance do sistema quanto uma visão histórica.

Os operadores também devem conseguir configurar alertas com base em medidas de performance de qualquer métrica (direta ou derivada) dentro de um intervalo de tempo especificado.

Como capturar métricas de performance

As métricas de performance podem ser coletadas com ferramentas de monitoramento como o Prometheus. Os coletores de métricas costumam ser implantados como processos em segundo plano que reúnem informações de uso enquanto o sistema roda.

Por exemplo, o Prometheus tem bibliotecas cliente para Node.js, Ruby, Python e mais. Essas bibliotecas ajudam a adicionar instrumentação ao seu código e podem ser configuradas para coletar os tipos de métrica críticos para as suas necessidades de monitoramento.

Você também pode adicionar instruções de trace, junto com informações de tempo, em pontos-chave do código de componentes como o rate limiter e os consumidores de webhooks. É por isso que adicionamos um Trace ID a cada webhook no API gateway, para poder rastreá-lo.

O Trace ID pode ser usado em lógica de rastreamento que captura falhas, exceções e avisos, correlacionando-os com os webhooks ou eventos que os causaram.

Outra boa prática de monitoramento de performance é capturar dados de performance de qualquer sistema externo usado na solução de webhooks. Por exemplo, se usarmos um serviço externo como o Amazon API Gateway para provisionar o componente de gateway de webhooks, podemos puxar métricas de performance dos endpoints de métricas fornecidos pelo serviço.

Se o serviço externo não expõe nenhum endpoint para coletar métricas, podemos registrar informações como o horário de início e de término de cada requisição feita a ele. Também podemos capturar a taxa de falha ou sucesso das operações desse serviço.

Como analisar os dados de performance

Analisar performance envolve agregar dados brutos e usar fórmulas matemáticas e estatísticas para transformá-los em informação que apresente um retrato preciso do estado do sistema.

Boa parte do trabalho de análise consiste em consultar os dados relevantes, relacioná-los e traduzi-los em informações que revelem insights de performance como:

• Throughput operacional
• Anomalias na utilização de recursos
• Taxa de erros entre chamadas de rede (e outras operações de I/O), processamento de webhooks etc.

Essas informações podem ser capturadas no nível do componente ou para o sistema todo. Para tornar o resultado da análise intuitivo, os pontos de dados do teste são apresentados em visualizações como tabelas, gráficos ou percentis numéricos. Isso permite que os administradores extraiam insights úteis com facilidade.

Toda forma de análise de performance começa por submeter a sua infraestrutura de webhooks a uma carga esperada por meio de testes de carga. Enquanto você faz o teste, coleta dados de performance e os passa por fórmulas analíticas que produzem valores indicando a performance da sua infraestrutura.

Existem diferentes tipos de resultado que você pode produzir para indicar a performance do seu sistema. Com base nas boas práticas, no entanto, os seguintes são fundamentais:

• Médias: as médias são obtidas somando todos os valores de um conjunto de dados e dividindo pelo total de valores. Elas podem ser usadas para analisar métricas como o tempo médio de resposta de cada webhook. Uma das desvantagens de usar médias é que elas frequentemente escondem alguns outliers dentro do conjunto, então tenha cuidado ao usá-las para julgar a performance.
• Desvio padrão: é uma medida de quanto os valores de um conjunto variam em relação à média, ou seja, o quão distantes estão entre si. Suponha que você esteja obtendo um tempo médio de resposta de 3 segundos por webhook, abaixo de um limite de timeout de 5 segundos, e por isso acha que está tudo bem. Mesmo assim, você continua recebendo erros de timeout. Ao checar o cálculo do tempo de resposta, você vê que a média é composta pelos valores 1, 1 e 7. Isso mostra que o último valor está muito longe da média, o que explica o erro.
• Percentis: um percentil indica o valor abaixo do qual se encontra uma porcentagem da amostra. Por exemplo, o percentil 90 (P90) indica que 90% do conjunto de dados está abaixo de um limite fixo, enquanto o restante (os outros 10%) está acima. Percentis são um indicador melhor de quão bem o seu sistema se comporta sob uma determinada carga, e é possível calcular percentis para diferentes tamanhos de amostra. Por exemplo, P95 e P99 mostram a performance de uma métrica considerando 95% e 99% do conjunto de dados, respectivamente.

Exemplo

Vamos ver um exemplo de como a performance pode ser analisada usando algumas das métricas que podem ser coletadas na nossa infraestrutura de webhooks. Neste exemplo, vamos analisar a performance da nossa ingestão de webhooks, ou seja, a operação do message broker.

Dois tipos de métrica que podem ser coletados do broker são:

• Mensagens publicadas em uma fila
• Mensagens publicadas para fora de uma fila

Ambas são medidas como uma taxa (por segundo). Então submetemos a nossa infraestrutura de webhooks a uma carga específica e medimos essas métricas até que todos os webhooks sejam processados. Em seguida, plotamos os valores em um gráfico ao longo do tempo em que o teste rodou e obtemos o resultado abaixo:

Como se vê no diagrama, as mensagens de entrada aumentam e atingem um pico antes de cair a zero no fim do teste. As mensagens de saída, porém, tentaram acompanhar no começo, atingiram o pico cedo e o throughput simplesmente degradou com o tempo, com mensagens ainda sendo consumidas depois que o teste de carga terminou.

Um processo de ingestão com performance “perfeita” resultaria em um gráfico com as duas linhas alinhadas. A performance ideal mantém o desvio entre as duas linhas em um mínimo razoável. Uma das formas de conseguir isso é introduzir mais paralelismo no processamento das mensagens.

Uma anomalia em que a linha azul fica acima da vermelha enquanto as mensagens ainda entram na fila em alta taxa indica que uma quantidade substancial de mensagens está indo para a dead letter queue. Isso mostra uma possível taxa alta de erros no consumo. Esses erros podem vir da exaustão de CPU ou memória, de durações insuficientes de lock das mensagens etc.

KPIs e estimativa de recursos

Como dito antes, para determinar se um sistema está com performance ideal ou ruim, você primeiro precisa definir metas de performance. Essas metas devem se basear nas operações do negócio, com mais foco nas tarefas voltadas ao cliente.

Na prática padrão, essas metas são apresentadas na forma de indicadores-chave de performance (KPIs). Exemplos de KPIs incluem, mas não se limitam a:

• Latência ou tempo de resposta de requisições específicas (por exemplo, o tempo de resposta de cada webhook publicado por um produtor, que deve ficar abaixo do limite de timeout definido por ele).
• O número de requisições processadas por segundo (você quer processar 10 mil, 100 mil ou um milhão de webhooks por segundo?).
• A taxa com que o sistema gera erros (por exemplo, menos de 4% de erros por milhão de webhooks).

Com esses indicadores, você consegue julgar adequadamente, por meio de testes, se o seu sistema está com performance ideal ou não.

Tenha em mente que toda meta de performance precisa incluir explicitamente uma carga alvo. Por exemplo, ao tentar operar abaixo de uma taxa de erro de 4%, esse valor precisa estar atrelado a um volume específico de webhooks processados (por exemplo, 25 mil por segundo).

É por isso que é importante ter Service Level Objectives (SLOs) que definam metas de performance atreladas à carga de trabalho, por exemplo:

As requisições de webhook terão tempo de resposta abaixo de 350ms no P90 para cargas de até 50 mil requisições por segundo.

A frase acima é um critério claramente definido de performance ideal em relação ao tempo de resposta dos webhooks e inclui o tamanho da amostra a que se aplica.

O que é estimativa de recursos para a infraestrutura de webhooks?

Um dos principais objetivos dos testes de performance é conseguir estimar a quantidade de recursos necessária para operar dentro das metas de performance definidas.

O processo de estimar os recursos necessários pode ser resumido assim:

• Implemente uma versão simples (tipo MVP) da sua infraestrutura.
• Faça testes de carga com o volume de produção que o seu sistema vai precisar suportar.
• Colete métricas e analise os dados.
• Ataque um gargalo de cada vez. Teste uma solução aumentando recursos e/ou ajustando configurações.
• Descubra mais gargalos acima e abaixo na cadeia e repita o ciclo.
• No ponto em que você atingir as suas metas de performance, terá chegado aos recursos necessários.

Exemplo de estimativa de recursos para a infraestrutura de webhooks

Para entender melhor o processo, vamos percorrer uma estimativa de exemplo para a nossa infraestrutura de webhooks. Digamos que comecemos com esta tabela de estimativa (note que não se trata de uma análise detalhada, mas de um exemplo para entender o processo):

Em seguida, fazemos um teste de carga na nossa infraestrutura com um volume de webhooks em nível de produção e percebemos uma abundância de erros de timeout entre o produtor e o API gateway.

Após investigar, percebemos que precisamos escalar horizontalmente o serviço de gateway, então adicionamos mais instâncias e chegamos a uma nova estimativa:

Testamos de novo e notamos que o nosso broker fica caindo e reiniciando. Não estamos perdendo mensagens porque declaramos as filas como duráveis e persistentes, mas as quedas do broker afetam negativamente a performance, com um tempo alto de processamento dos webhooks.

Investigamos mais uma vez e notamos que a memória do broker se esgota rapidamente. Para resolver, introduzimos um cluster com 3 brokers para distribuir a carga e chegamos a uma nova estimativa:

Testamos novamente e notamos que apenas 70% dos nossos webhooks ficam dentro do nosso SLO de tempo de processamento. Enquanto isso, o SLO diz que 95% dos webhooks devem ser processados em até 150ms. Isso indica uma degradação de performance ao longo do tempo.

Investigamos e notamos que o nosso broker está ingerindo mensagens mais rápido do que a taxa em que elas são consumidas (semelhante ao problema mostrado no gráfico de teste de performance do broker acima).

Sabendo disso, decidimos introduzir mais paralelismo no processamento escalando os consumidores horizontalmente. Isso nos leva a uma nova estimativa:

Depois de implementar isso, vemos uma melhora, mas só para 85%, não para 95%. Investigamos mais a fundo e rastreamos o problema até a velocidade de processamento da CPU do nosso consumidor.

Aumentar a capacidade de CPU melhora o tempo de processamento e nos ajuda a atingir a marca de 95% definida no SLO.

Às vezes, o resultado da sua investigação sobre gargalos de performance pode levar à introdução de novos componentes na infraestrutura. Por exemplo, você pode precisar de um sistema de cache para acelerar a performance ou guardar dados temporários. Em outras ocasiões, pode ser necessário quebrar componentes ainda mais (fazendo sharding do banco de dados, por exemplo).

Conclusão

O monitoramento de performance é crítico para qualquer infraestrutura de webhooks que pretenda processá-los de forma confiável à medida que o volume cresce.

Neste artigo, descrevemos como montar a instrumentação para medir performance, como analisar os dados e como usar o resultado no provisionamento da infraestrutura.

O aumento gradual do volume de tráfego e os picos inesperados são inevitáveis para negócios online em crescimento rápido. Ter uma configuração padrão de monitoramento de performance ajuda a evitar problemas que prejudicam a experiência do usuário e geram prejuízo. Para uma visão completa sobre como construir a sua infraestrutura de webhooks, veja o nosso guia sobre construir ou comprar a sua infraestrutura de webhooks. Para transformar as métricas descritas aqui em uma configuração funcional — dashboards, rastreamento de eventos, workflows de replay e limites de alerta —, veja Arquitetura de observabilidade de webhooks para sistemas em produção.