Como medir adequadamente a latência em sete minutos

Para medir a latência de maneira adequada, é preciso ter dados de qualidade. O Global CEO Outlook 2016 da KPMG (link externo a ibm.com) descobriu que 84% dos CEOs estão preocupados com a qualidade dos dados nos quais baseiam suas decisões, e isso ocorre porque os dados muitas vezes podem ser enganosos.

A diferença entre as empresas que se preocupam com seus dados e as que não se importam é enorme. Os pesquisadores do MIT descobriram (link externo a ibm.com) que as empresas que adotaram um projeto baseado em dados têm uma produção de 5% a 6% maior do que o esperado, considerando seus outros investimentos e uso de tecnologia. Este motivo por si só torna a compreensão da latência crítica para o sucesso dos negócios.

Em apenas sete minutos, você aprenderá tudo o que precisa saber sobre medir a latência:

• Como medir a latência
• Por que é importante fazer a medição adequada
• Armadilhas comuns ao analisar seus dados de latência
• A importância do feedback instantâneo
• Por que dados sem amostra são necessários

O Dictionary.com (link externo a ibm.com) define latência como "o período de atraso quando um componente de um sistema de hardware está esperando que uma ação seja executada por outro componente." Em termos mais simples, significa a quantidade de tempo entre a chamada de uma função e sua execução real. A latência é inerente a todos os sistemas; mesmo que tivéssemos um sistema perfeito, que não existe, seria latente o tempo que leva para os elétrons no computador alternarem os transistores de ligados para desligados, ou vice-versa.

A latência em pequenas operações não é um grande problema, mas ao lidar com milhões de operações, há milhões de latências que se somam rapidamente. A latência não é definida por unidades de trabalho e tempo, mas sim como ela se comporta. As ferramentas de monitoramento relatam quanto tempo leva desde o início de uma função até o final da função.

A latência pode ter um grande impacto em sua empresa. Por exemplo (link externo a ibm.com): "Quando se trata de velocidade em dispositivos móveis, cada segundo importa — para cada segundo adicional que uma página móvel leva para carregar, as conversões podem cair em até 20%."

A latência quase nunca segue uma distribuição gaussiana ou de Poisson normal. Mesmo que sua latência siga uma dessas distribuições, devido à forma como observamos a latência, isso torna as médias, as medianas e até mesmo os desvios padrões inúteis. Se, por exemplo, você estiver medindo cargas de páginas, 99,9999999999% dessas cargas podem ser piores do que a sua mediana. Isso é parte do motivo pelo qual a amostragem aleatória de sua latência causa dados imprecisos – mas falaremos mais sobre esse assunto mais tarde.

Neste ponto, você deve estar se perguntando: Se não estamos usando nenhum desvio padrão, como podemos descrever as latências de modo significativo? A resposta é que devemos analisar percentis e máximos. A maioria das pessoas pensar consigo mesmas: "OK, então eu olho para o P95 e entendo o "caso comum". O problema desse método é que o P95 ocultará todas as informações ruins. Como diz Gil Tene, CTO da Azul Systems: “É um 'sistema de marketing'. Alguém está sendo enganado.”

Veja, por exemplo, este gráfico:

Este gráfico mostra claramente por que sua mediana e média não têm significado real — elas não mostram a área do problema. Quando você vê o 95º percentil disparar para a esquerda, pensa que está vendo o cerne do problema. Claro, no entanto, isso não é verdade. Quando você investiga os motivos pelos quais seu programa teve um soluço, você não consegue ver os 5% piores do que aconteceu. Para obter esse tipo de pico, é necessário que os 5% principais dos dados sejam significativamente piores.

Agora olhe para o mesmo gráfico que também mostra o 99,99º percentil:

Essa linha vermelha é o 95º percentil, enquanto a linha verde é o 99,99º percentil. Como você pode ver claramente, o 95º percentil mostra apenas dois de 22 de seus problemas e por que você deve analisar todo o espectro de seus dados.

Muitas pessoas podem achar que os últimos 5% dos dados não têm muito significado. Claro, pode ser apenas uma reinicialização de uma máquina virtual (VM), um soluço no seu sistema ou algo parecido, mas ao ignorá-lo, você está dizendo que isso simplesmente não acontece quando poderia ser uma das coisas mais importantes para você para direcionar.

Gil Tene gosta de fazer a alegação ousada de que “O indicador número um do qual você nunca deve se livrar é o valor máximo. Isso não é ruído, isso é o sinal. O resto é ruído.” Embora o máximo seja, de fato, um grande single em um sistema em grande escala, muitas vezes não é prático buscar apenas o caso máximo. Nenhum sistema é perfeito e soluços ocorrem. Em um sistema prático de grande escala, buscar exclusivamente o caso máximo costuma ser uma boa maneira de esgotar sua equipe de desenvolvimento.

Ao olhar para o 99,99º percentil, você está vendo o que acontece com a grande maioria de seus clientes, e quaisquer picos que você vê lá você sabe que são problemas reais, enquanto qualquer picos em seu máximo pode ser apenas um soluço em seu sistema. Quando suas equipes de DevOps concentram seus esforços nesses pequenos soluços, elas estão fazendo isso com um grande custo de oportunidade, pois não podem trabalhar em questões mais importantes.

É importante observar que, se seu 99,99º percentil e seu máximo estiverem muito próximos um do outro (e ambos estiverem com picos), então é um ótimo sinal de que é um problema no qual sua equipe deve trabalhar. Dessa forma, Gil está certo de que o máximo é um ótimo sinal, mas errado ao dizer que o restante de seus dados é apenas ruído. Como você pode ver neste gráfico, nosso 99,99º percentil e máximo do nosso exemplo anterior correspondem exatamente. É um ótimo sinal de que você está vendo um bug real e não apenas um soluço:

Uma armadilha ainda pior em que as pessoas caem do que apenas olhar para o 95º percentil é não reconhecer que seus percentis são calculados pela média. Calcular a média de percentis é estatisticamente incorreto; isso remove todo o significado do que você está olhando. Já mostramos como as médias não são boas ao analisar a latência e, se você estiver analisando os percentis médios, simplesmente voltará à estaca zero. Muitos programas de software fazem a média de seus percentis. Veja, por exemplo, este gráfico de Grafana:

Quer você tenha percebido ou não antes, todos os percentis neste gráfico são médios. Está bem no livro-razão do eixo x. Quase todos os serviços de monitoramento calculam a média dos seus percentis. É uma realidade devido à pré-computação. Quando seu serviço de monitoramento coleta seus dados, ele computa o percentil dos dados para aquele minuto.

Então, quando você olha para o seu 95º percentil, ele mostra uma média de todos os seus percentis. Esse atalho para o “seu bem” para tornar seu serviço mais rápido está, na realidade, removendo toda a significância estatística de seus dados.

Quer você saiba ou não, ao utilizar ferramentas de monitoramento que participam da amostragem de dados, elas estão produzindo dados médios. Quase todas as ferramentas de monitoramento coletam amostras de seus dados. Veja, por exemplo, a Datadog – ela tem grandes perdas de dados. Se você enviar 3 milhões de pontos em um minuto, ele não aceitará todos. Em vez disso, ele fará amostras aleatoriamente dos pontos e os agregará em 1 ponto por minuto.

Você deve ter dados sem amostra para entender sua latência. É inerente que, com dados de amostra, você não possa acessar a distribuição completa. Seu máximo não é seu máximo verdadeiro, nem seu percentil global é uma representação precisa do que está acontecendo.

Quando você coleta amostras de dados, está omitindo dados. Digamos, por exemplo, que você tenha 10.000 operações acontecendo em um minuto, enviando dois pontos de dados cada para seu sistema de monitoramento. Digamos que você tenha um bug em seu sistema e um desses pontos de dados mostre esse bug por 10.000 operações. Seu sistema de monitoramento tem apenas 1/20.000 de chance de escolher esse bug como o ponto de dados que ele mostra como máximo.

Se você executar por tempo suficiente, o ponto de dados acabará aparecendo, mas, como resultado, parecerá um caso de edge, mesmo que esteja acontecendo com um de seus clientes a cada minuto. Quando você não coleta amostras de dados e tem um desses picos, eles aparecerão claramente no seu 99,99º percentil, e seu máximo aparecerá próximo a ele, sinalizando que há um bug no seu programa. No entanto, quando você faz amostras de seus dados, elas não aparecem com tanta frequência, o que significa que você não as vê como um bug, mas sim como um soluço. Esse resultado significa que sua equipe de engenharia não conseguirá perceber o significado disso.

Não deixe que sua ferramenta de monitoramento o engane, fazendo-o pensar que sabe o que está acontecendo com sua latência. Uma das características principais do software IBM Instana é sua capacidade de medir a latência com eficiência. O software IBM Instana utiliza análises avançadas e aprendizado de máquina (ML) para detectar automaticamente problemas de latência em tempo real, permitindo que desenvolvedores e equipes de TI identifiquem rapidamente a causa raiz de qualquer problema de desempenho e tomem medidas corretivas antes que eles afetem os usuários.

Escolha uma ferramenta que não forneça dados de amostra. Escolha uma ferramenta que não calcule a média de seus percentis globais.