Pinterest troca sua coleção de profilers pelo gProfiler de código aberto da Intel

Quando você tem cinco serviços escritos em uma mesma linguagem, um único comando resolve o profiling. Quando são centenas de milhares de instâncias e cinco linguagens, o profiling se torna um desafio de engenharia por si só. Foi esse o problema que o Pinterest enfrentou, e a solução é interessante: em vez de criar um sistema interno proprietário, a empresa adotou o gProfiler de código aberto da Intel e começou a aprimorá-lo.

O problema: muitas linguagens, muitas ferramentas

Os números dão uma ideia da escala: 640 milhões de usuários ativos por mês e centenas de milhares de instâncias computacionais. Os serviços são escritos em Java, Python, C++, Go e Node.js. Para cada linguagem, os engenheiros tinham uma ferramenta conhecida: perf para código nativo, async-profiler para a JVM e py-spy para Python.

Isoladamente, todas funcionam bem. Juntas, viram uma confusão. Os formatos de dados são diferentes, as formas de execução também, e montar uma visão completa de uma cadeia como “gateway em Node.js, backend em Java, biblioteca em C++” exige trabalho manual. Comparar o perfil de um serviço em máquinas diferentes ou em dias distintos também é difícil quando as capturas são feitas com ferramentas diferentes.

Para a equipe de infraestrutura, esse não é um problema meramente acadêmico. Os perfis servem para entender para onde vai o dinheiro gasto com hardware e detectar regressões após uma nova versão. Quando os dados estão fragmentados, responder a essas perguntas leva mais tempo e traz menos confiança.

O que mudou no gProfiler

O gProfiler é um profiler contínuo de código aberto. Ele roda como um agente na máquina, coleta perfis de várias linguagens e apresenta os resultados em gráficos de chama. O Pinterest trabalhou com a Intel para ampliar seus recursos e contribuiu com as alterações para o projeto de código aberto. Entre as melhorias:

• Profiling dinâmico. É possível ativar e configurar o profiling durante a execução, sem precisar mantê-lo ligado o tempo todo em todas as máquinas.
• Coleta de telemetria no nível do hardware. O profiler registra tanto onde o código gasta tempo quanto os dados dos contadores do processador.
• Profiling wall-time. Mostra onde uma thread passa tempo esperando, além de onde ela usa o processador.
• Gráficos de chama baseados em contadores de desempenho. Permitem representar eventos de hardware no lugar do eixo habitual de “tempo de CPU”.

Um exemplo ajuda a entender a diferença entre tempo de CPU e tempo decorrido. Suponha que um endpoint responda em 300 ms, mas o perfil de CPU mostre apenas 40 ms de atividade do processador. Para onde foram os outros 260 ms? Provavelmente, a thread estava esperando uma resposta do banco de dados, da rede ou a liberação de um bloqueio. O perfil de CPU não mostrará essa parte; o perfil wall-time a revelará de imediato.

Os contadores de desempenho permitem investigar mais a fundo. Duas funções podem levar o mesmo tempo, mas uma delas pode sofrer falhas de cache do processador constantemente. Um perfil convencional não permite distinguir as duas; um perfil baseado em eventos de hardware permite.

O que importa aqui e o que ainda não sabemos

O anúncio original não informa quanto foi economizado em recursos computacionais, quanto mais rápido as regressões são encontradas nem quantas instâncias já foram migradas. Portanto, ainda é cedo para falar em impacto mensurável. Trata-se mais de uma declaração de direção arquitetural do que de um relatório de resultados.

Ainda assim, a escolha é reveladora. Uma empresa desse porte poderia ter criado sua própria plataforma, mas preferiu um projeto aberto e contribuiu com suas melhorias. Isso beneficia os demais: os avanços no profiling dinâmico e wall-time ficarão disponíveis para todos que usam o gProfiler.

O que fazer na prática

1. Faça um inventário das suas ferramentas. Se você tem mais de duas linguagens em produção e mais de dois profilers diferentes, enfrenta o mesmo problema, só que em menor escala.
2. Experimente o gProfiler em um ambiente de testes. É um projeto de código aberto criado justamente para fazer profiling contínuo sem alterar o código dos serviços.
3. Inclua o profiling wall-time na rotina. Se um serviço “está lento, mas a CPU está livre”, é disso que você precisa.
4. Acompanhe o projeto original. As melhorias do Pinterest e da Intel devem chegar ao repositório principal, e vale conferir quais já estão disponíveis nas versões lançadas.

A principal conclusão é simples: em grande escala, um profiler unificado importa mais do que a ferramenta perfeita para cada linguagem. Dados comparáveis de todo o parque de máquinas entregam mais valor do que a melhor precisão possível em um único serviço.