Pontos Principais
- O rastreamento distribuído está sendo visto, cada vez mais, como um componente essencial para a observação de sistemas distribuídos e aplicações de microservices. Existem vários modelos de código aberto e frameworks populares, como o OpenTracing API e o OpenZipkin.
- A ideia básica por trás do rastreamento distribuído é direta - os pontos de inflexão de uma solicitação específica devem ser identificados e adaptados dentro de um sistema. Todos os dados de rastreio devem ser coordenados e agrupados para fornecer uma visão geral do pedido.
- O rastreamento de uma solicitação é semelhante ao conceito de Gerenciamento de Desempenho de Aplicativos (APM); um desafio emergente em ambos os ecossistemas é o processamento do volume de dados gerados a partir de sistemas cada vez maiores.
O rastreamento distribuído está cada vez mais popular como um componente essencial para a análise de sistemas distribuídos e aplicações de microservices. Este artigo fornece uma introdução e uma visão geral desta técnica, começando pela exploração do documento de solicitação de rastreamento do Google Dapper - o que, por sua vez, levou à criação dos projetos Zipkin e OpenTracing - e terminou com uma discussão sobre o futuro do rastreamento com Ben Sigelman, criador da nova plataforma de rastreamento LigthStep [x]PM.
Conforme apontado no documento original do Dapper, os serviços modernos de Internet são muitas vezes implementados como sistemas distribuídos complexos e em larga escala, por exemplo: usando o estilo arquitetônico popular de microservice. Essas aplicações são montadas a partir de coleções de serviços que são desenvolvidas por diferentes equipes, possivelmente usando diferentes linguagens de programação. Na escala do Google, esses aplicativos abrangem milhares de máquinas em múltiplas instalações, mas mesmo para casos de uso de computação em nuvem relativamente pequenos, é recomendada a prática de executar várias versões de um serviço espalhados geograficamente por "zonas de disponibilidade" e "regiões". As ferramentas que ajudam na compreensão do comportamento do sistema também ajudam com a depuração e permitem que o raciocínio sobre problemas de desempenho sejam inestimáveis em sistemas e ambientes tão complexos.
A ideia básica por trás da solicitação de rastreamento é relativamente direta: pontos específicos de inflexão são identificados dentro de um sistema, aplicativo, rede ou middleware - ou mesmo em qualquer ponto no caminho de uma solicitação (tipicamente iniciada pelo usuário) - e são adaptados. Esses pontos são de particular interesse, pois geralmente representam desvios no fluxo de execução, como: a paralelização do processamento usando várias threads, uma computação feita de maneira assíncrona, ou uma chamada de rede fora do processo. Todos os dados de rastreamento gerados de forma independente devem ser coletados, coordenados e agrupados para fornecer uma visão significativa do fluxo de uma solicitação por meio do sistema. Cindy Sridharan forneceu um guia muito útil que explora os fundamentos do rastreamento de pedidos e também coloca essa técnica no contexto de outros dois pilares do monitoramento moderno e da "observabilidade": registro e coleta de métricas.
Descompactando um rastreamento
Como definido no projeto OpenTracing API da Cloud Native Computing Foundation (CNCF), um rastreamento informa o histórico de uma transação ou um fluxo de trabalho a medida que se propaga pelo sistema. No OpenTracing e no Dapper, um rastreio é um grafo acíclico direcionado (DAG) de "spans", que também são chamados de segmentos em algumas ferramentas, como no AWS X-Ray. Os spans são nomeados e cronometrados nas operações que representam o segmento contínuo de trabalho no rastreamento. Anotações adicionais (metadados ou "baggage") podem ser uma extensão de um componente que está sendo orquestrado - por exemplo, um desenvolvedor de aplicativos pode usar um SDK de rastreamento para adicionar itens de chave-valor arbitrários a uma extensão atual. Nota-se que a adição de dados de anotação é intrusiva: o componente que faz as anotações deve estar ciente da presença de uma estrutura de rastreamento.
Os dados de rastreio normalmente são coletados "fora do conjunto" puxando arquivos de dados escritos localmente (gerados por meio de um agent ou deamon) por meio de um processo de rede separado para finsde armazenamento centralizado, da mesma forma que ocorre com a coleta de logs e métricas. Os dados de rastreamento não são adicionados ao pedido, pois isso permite que o tamanho e a semântica da solicitação permaneçam inalterados, e os dados armazenados localmente podem ser puxados quando é conveniente.
Quando um pedido é iniciado, um "parent" span é gerado, o que, por sua vez, pode estar relacionado com relacionamentos causais e temporais com "child" spams. A Figura 1, retirada da documentação do OpenTracing, mostra a visualização comum de uma série de extensões e sua relação em um fluxo de solicitação. Este tipo de visualização adiciona o contexto de tempo, a hierarquia dos serviços envolvidos e a execução, em série ou paralela, do processo/ tarefa. Esta visão ajuda a destacar o caminho crítico do sistema e pode fornecer um ponto de partida para identificar gargalos ou áreas para melhoria. Muitos sistemas de rastreamento distribuído também fornecem uma API ou interface de usuário para permitir um maior "detalhamento" de cada intervalo.
Figura 1. Visualizando um rastreamento básico com uma série de intervalos ao longo da vida útil de uma solicitação (imagem tirada da documentação do OpenTracing)
Os desafios da implementação do rastreamento distribuído
Historicamente tem sido um grande desafio implementar a solicitação de rastreamento em um sistema heterogêneo distribuído. Por exemplo, uma arquitetura de microservices implementada usando múltiplas linguagens de programação pode não compartilhar um ponto comum de operações. Tanto o Google quanto o Twitter conseguiram implementar o rastreamento criando o Dapper e o Zipkin (respectivamente) com relativa facilidade, pois a maioria de suas comunicações entre processos (inter-serviços) ocorre por meio de uma estrutura RPC homogênea; o Google criou o Stubby (uma variante do que foi lançado como código aberto do gRPC) e o Twitter criou o Finagle.
A documentação do Dapper deixa claro que o serviço de rastreamento só é realizado por meio de (1) implantação ubíqua, nenhuma parte do sistema sob observação não está instrumentada ou "obscura", e (2) monitoramento contínuo, o sistema deve monitorar constantemente, pois eventos incomuns são, muitas vezes, difíceis de reproduzir.
O aumento da popularidade dos proxies de rede na "malha de serviços" como Envoy, Linkerd, e Conduit (e os planos de controle associados, como Istio) pode facilitar a adoção do rastreamento em sistemas heterogêneos distribuídos, pois podem fornecer o ponto comum de instrumentação faltante. Sridharan discute este conceito mais adiante em seu artigo no Medium que fala sobre a observabilidade:
"A Lyft obteve o suporte de rastreamento para todas as suas aplicações sem alterar uma única linha de código, adotando o padrão da malha de serviço [usando seu Envoy proxy]. As malhas de serviço ajudam com o Drying de observabilidade implementando coleções de rastreamento e estatísticas no nível da malha, o que permite tratar os serviços individuais como blackboxes, mas ainda assim, obter uma incrível observabilidade da malha como um todo."
The Need For Speed: Rastreamento de solicitação e APM
A velocidade de carregamento de uma página Web pode afetar dramaticamente o comportamento e a aceitação do usuário. O Google gerou um experimento de latência usando seu mecanismo de pesquisa e descobriu que, ao adicionar um atraso de 100 a 400 ms para a exibição da página de resultados, gerou um impacto mensurável sobre o número de buscas executadas por um usuário. Em 2006, Greg Linden comentou que os experimentos realizados pela Amazon.com demonstraram uma queda significativa na receita, experimentada quando foram adicionados 100 ms de atraso no carregamento da página. Embora a compreensão do fluxo de uma solicitação da web por meio de um sistema possa ser desafiadora, pode haver ganhos comerciais significativos se os pontos de estrangulamento do desempenho forem identificados e eliminados.
A solicitação de rastreamento é semelhante ao conceito de Gerenciamento de Desempenho de Aplicativos (APM); ambos estão relacionados ao monitoramento e gerenciamento de desempenho e disponibilidade de aplicativos de software. A APM visa detectar e diagnosticar problemas complexos de desempenho de aplicativos para manter um Acordo de Nível de Serviço (SLA) esperado. A medida que as arquiteturas de software modernas se tornam mais distribuídas, a ferramenta APM se adapta para monitorar (e visualizar) isso. A Figura 2 mostra uma visualização da ferramenta de código aberto Pinpoing APM, e visualizações semelhantes podem ser encontradas em ferramentas comerciais como Dynatrace APM e o New Relic APM.
Figura 2. Solicitação de rastreamento na ferramenta APM (imagem retirada do repositório Pinpoint APM GitHub)
Um desafio emergente dentro do espaço de solicitação de rastreamento e de APM é o processamento do volume de dados gerados a partir de sistemas cada vez maiores. Conforme afirmado por Adrian Cockcroft, vice-presidente de Cloud Architecture Strategy da AWS, a nuvem pública pode ter acesso democratizado a infra-estrutura e serviços poderosos e escaláveis, mas os sistemas de monitoramento devem estar mais disponíveis (e mais escaláveis) do que os sistemas que estão monitorando. O Google superou este problema ao implementar o Dapper por meio de rastros de amostragem, tipicamente 1 em 1000, e ainda descobriu uma visão significativa que poderia ser gerada com essa taxa. Muitos engenheiros e líderes que trabalham dentro do espaço - incluindo Charity Majors, CEO da Honeycomb, uma plataforma de observabilidade - acreditam que a amostragem de dados de monitoramento é essencial:
Isso é simples: se não pode provar, não pode escalar. Se pensa que isso é mesmo uma afirmação controversa, então nunca abordou a observabilidade em escala ou a fez de forma ineficaz.
O InfoQ recentemente participou do CNCF CloudNativeCon em Austin, EUA, e conversou com Ben Sigelman, um dos autores da documentação de Dapper, CEO e co-fundador da LightStep, que anunciou recentemente uma nova plataforma de rastreamento comercial, "LightStep [x]PM". Sigelman comentou que a arquitetura não convencional da LightStep (que utiliza técnicas de aprendizado de máquina dentro de agentes instalados localmente) permite a análise de 100% dos dados de uma transação em vez de 0,01% como foi implementado com o Dapper:
"O que construímos foi (e ainda é) essencial para análise de desempenho a longo prazo, mas para lidar com a escalabilidade dos sistemas que estão sendo monitorados, o Dapper gravou apenas 0,01% nos dados de desempenho; Isso significava que era desafiante aplicar-lo a certos casos de uso, como a resposta de incidentes em tempo real."
A LightStep trabalhou com diversos clientes nos últimos 18 meses - incluindo a Lyft (utilizando o Envoy proxy como ponto de integração), Twilio, GitHub e DigitalOcean - e demonstraram que sua solução é capaz de lidar com altos volumes de dados:
"A Lyft nos remete uma grande quantidade de dados - LightStep analisa 100.000.000.000 de visitas ao microservice todos os dias. A primeira vista, esses dados são todos desordenados e sem nenhum sentido: inconstantes e não correlacionados. No entanto, ao considerar a totalidade disso, o LightStep pode medir o desempenho que afeta os diferentes aspectos do negócio da Lyft, e depois explicar problemas e anomalias usando traços de ponta a ponta que se estendem de seus aplicativos móveis para o fundo de sua pilha de microservices."
O LightStep [x]PM está disponível atualmente como uma plataforma SaaS, e Singelman estava interessado em destacar que, embora 100% dos pedidos possam ser analisados, nem todos esses dados são filtrados para a plataforma centralizada pelos agentes instalados localmente. Singelman vê esse produto como uma ferramenta da "nova era APM", que proporcionará valores aos clientes que procuram monitoramento de desempenho e análise automatizada de causas em aplicações complexas distribuídas.
Conclusão
A latência da resposta dos sistemas distribuídos pode ter um impacto comercial significativo, mas a compreensão do fluxo de um pedido por meio de um sistema complexo e a identificação de estrangulamentos podem ser desafiadores. O uso do rastreamento distribuído - em combinação com outras técnicas como o registro e monitoramento de métricas - pode fornecer informações sobre aplicações distribuídas, como as criadas usando o padrão de arquitetura de microservices. Estão surgindo padrões abertos e ferramentas no espaço de rastreamento distribuído - como a API OpenTracing e o OpenZipnik - e algumas ferramentas comerciais também, o que potencialmente concorre com as ofertas APM existentes. Existem vários desafios com a implementação de rastreamento distribuído para serviços modernos de Internet, como o processamento do alto volume de dados de rastreamento e a geração de uma visão significativa, mas o ecossistema de código aberto e os fornecedores estão topando o desafio.
Sobre o Autor
Daniel Bryant lidera mudanças dentro de organizações e tecnologias. Seu trabalho atual inclui desenvolver agilidade dentro das organizações, introduzindo melhores técnicas de planejamento e de coleta de requisitos, com foco na relevância da arquitetura no desenvolvimento ágil e facilitando a integração/entrega contínua. Sua experiência técnica atual se concentra em ferramentas de 'DevOps', plataformas de cloud/container e implementações de microservices. Também é líder na Comunidade Java de Londres (LJC); contribui para vários projetos de código aberto; escreve para sites técnicos bem conhecidos, como InfoQ, DZone e Voxxed; e regularmente palestra em conferências internacionais como QCon, JavaOne e Devoxx.