A Netflix reformulou o pipeline de dados por trás do Service Topology, seu mapa de dependências em tempo real, adotando arquitetura em três estágios e contrapressão reativa para escalar sem perder dados em cenários de alta demanda.
- O pipeline de rede foi reestruturado em três estágios para evitar hotspots em servidores com destinos populares.
- O uso de contrapressão via Apache Pekko Streams evita a perda de métricas cruciais de rede.
- Server-Sent Events (SSE) substituiu o gRPC para comunicação interna de dados devido à eficiência de memória.
- Hash consistente permite rebalancear instâncias que entram e saem de operação de forma automática.
O desafio da escala na descoberta de dependências<\/h2>
O Service Topology da Netflix é uma ferramenta indispensável para a engenharia de confiabilidade do ecossistema de microsserviços da companhia. Ele é utilizado diariamente para investigação de incidentes, análise de raio de ação de falhas, entendimento de dependências e gerenciamento de mudanças em produção.
A plataforma unifica visões de três fontes de dados distintas: fluxos de rede eBPF, métricas de comunicação entre processos (IPC) e rastreamentos distribuídos. No entanto, processar os fluxos de rede brutos apresentava um desafio físico complexo: em vez de conexões diretas entre microsserviços, os dados de rede mostram hops físicos intermediários, como load balancers, gateways de API e proxies. Mapear esses dados sem perdas e em tempo real exigiu uma reengenharia completa do pipeline.
# publicidade
A solução: arquitetura desacoplada de três estágios<\/h2>
Na arquitetura anterior, o trabalho acumulava-se em destinos populares, criando pontos quentes (hotspots) no sistema. Algumas instâncias sofriam com picos de tráfego até 100 vezes maiores do que a média, enquanto executavam tarefas pesadas de I/O para enriquecimento de dados.
Para resolver esse gargalo, a Netflix dividiu o pipeline de ingestão em três fases bem delimitadas. A primeira consome fluxos multi-regionais do Kafka, filtra registros inválidos e agrupa os dados em janelas de cinco minutos. A segunda fase realiza a resolução de intermediários, traduzindo hops físicos em arestas lógicas diretas de aplicação para aplicação. A terceira e última etapa enriquece os nós com metadados de saúde e propriedade, persistindo o grafo final no banco de dados de grafos. Essa divisão permitiu redistribuir uniformemente a carga de trabalho pesado.
Gestão de contrapressão e substituição de gRPC por sse<\/h2>
A integridade dos dados durante picos de carga é garantida por meio do Apache Pekko Streams, que gerencia a contrapressão do sistema. Quando o armazenamento de grafos atinge o limite de sua capacidade de escrita, o sinal de contrapressão viaja upstream pelas fases de processamento até pausar os consumidores do Kafka. Esse mecanismo faz com que a taxa de atualização dos mapas sofra um leve atraso temporário, o que a Netflix considera muito superior a perder dados ou depender de mapas gerados em lote que já estariam obsoletos em um cenário de incidente.
Outra otimização crítica foi a substituição de chamadas gRPC por Server-Sent Events (SSE) para a comunicação interna de alto volume entre as etapas do pipeline. A engenharia descobriu que a serialização, o gerenciamento de pools de conexões e a pressão sobre a memória de streaming sob gRPC geravam custos proibitivos sob extrema escala. O SSE provou ser uma alternativa consideravelmente mais leve e perfeitamente compatível com a contrapressão reativa.
| Mecanismo | Solução Anterior | Solução Atual |
|---|---|---|
| Comunicação Interna | gRPC com alto consumo de memória | Server-Sent Events (SSE) leve |
| Gargalos de Escrita | Perda de dados sob alta carga | Contrapressão reativa até o Kafka via Pekko Streams |
| Estrutura de Pipeline | Processamento monolítico acoplado | Três estágios: Agregação, Resolução e Enriquecimento |
Arraste para o lado para ver toda a tabela.
Perguntas frequentes (faq)<\/h2>
O que é o service topology da netflix?<\/h3>
É uma ferramenta que gera mapas em tempo real das dependências de microsserviços da Netflix, auxiliando na investigação de incidentes e análise de segurança de rede.
Como o pipeline da netflix evita perdas de dados?<\/h3>
Através do uso do Apache Pekko Streams para aplicar contrapressão reativa que desacelera o consumo do Kafka quando o banco de dados de grafos está sobrecarregado.
Por que a netflix preferiu server-sent events (sse) em vez de gRPC internamente?<\/h3>
O SSE provou ser mais leve no consumo de memória e mais eficiente para lidar com grandes volumes de transferências de dados internas com contrapressão reativa integrada.
