- A Netflix dividiu o pipeline do Service Topology em três estágios para evitar gargalos em destinos populares de tráfego.
- O uso de Apache Pekko Streams garante contrapressão de ponta a ponta, pausando os consumidores do Kafka em vez de descartar dados.
- O protocolo SSE (Server-Sent Events) substituiu o gRPC internamente por ser mais leve e amigável ao fluxo de dados reativo.
- A reconstrução do histórico de dependências é feita de forma eficiente por meio de snapshots de aggregators e mutações de propriedades.
O desafio da resolução de dependências em larga escala
O Service Topology da Netflix é uma ferramenta indispensável para resposta a incidentes, análise de raio de ação (blast radius) e gerenciamento de mudanças de produção. Ele cruza dados de diferentes fontes para fornecer insights holísticos. No entanto, processar esses dados na escala da Netflix impõe desafios severos de engenharia.
O fluxo bruto de rede mostra saltos de rede físicos e intermediários de infraestrutura em vez de dependências lógicas de aplicação. Para traduzir isso em conexões diretas, a Netflix precisa agregar e mapear os fluxos. O design anterior concentrava o trabalho de resolução de rotas perto de destinos populares, gerando pontos quentes (hotspots) que processavam até 100 vezes o tráfego normal, culminando em lentidão extrema sob estresse.
A solução: arquitetura ingestora em três estágios
Para resolver o desequilíbrio de carga e otimizar o processamento de entrada, a equipe de engenharia da Netflix dividiu o pipeline de ingestão de tráfego de rede eBPF em três partes independentes. Essa separação física distribuiu o trabalho de forma mais uniforme pela frota.
# publicidade
Ao isolar a consolidação inicial dos nós da resolução lógica e do enriquecimento com metadados complexos, o sistema passou a escalar horizontalmente sem sofrer com lentidões locais causadas por destinos de rede altamente populares.
- Estágio 1 (Consumação e Agregação): Consome fluxos multi-regionais do Kafka, descarta registros inválidos, agrupa dados em janelas de 5 minutos e cria agregadores iniciais.
- Estágio 2 (Resolução de Intermediários): Traduz os saltos físicos (LBs, proxies, gateways) em arestas diretas de aplicação para aplicação, redistribuindo os resultados.
- Estágio 3 (Enriquecimento e Persistência): Incrementa os nós com metadados adicionais de saúde, dono e tags antes de realizar a gravação no banco de dados de grafos.
Gerenciamento de contrapressão com Apache pekko streams
No design legado, o estresse no armazenamento do grafo causava descarte de dados e mapas de topologia desatualizados. A solução foi a adoção do Apache Pekko Streams para implementar um sistema robusto de contrapressão (backpressure).
Sempre que a escrita no banco de dados de grafos sofre lentidão, os sinais de contrapressão trafegam no sentido oposto das etapas de processamento. A pressão sobe até os consumidores do Kafka, que pausam temporariamente a ingestão de novas mensagens até que o armazenamento se recupere. O resultado é um atraso gerenciável na atualização da topologia, o que a Netflix prefere em relação à perda definitiva de dados históricos ou visualizações incorretas.
Substituição do gRPC por server-sent events (sse)
Uma mudança de infraestrutura muito relevante foi a substituição de conexões gRPC por Server-Sent Events (SSE) para a comunicação interna de grande volume entre as fases do pipeline.
Em escalas massivas, as chamadas gRPC geravam sobrecarga alta de processamento devido à serialização constante, além de exigir um gerenciamento complexo de pools de conexões e causar pressão de memória nas respostas em streaming. O uso do SSE se provou uma alternativa significativamente mais leve e perfeitamente compatível com o controle reativo de fluxo do pipeline.
Consistência hash e reconstrução histórica
À medida que a frota de processamento aumenta ou diminui dinamicamente de acordo com a demanda de tráfego, as instâncias utilizam hashing consistente contra o registro de serviços. Quando um nó entra ou sai do pool, apenas as partições afetadas mudam de dono, dispensando processos lentos de rebalanceamento centralizado.
Para viabilizar auditorias pós-incidentes sem o custo proibitivo de salvar snapshots inteiros do banco de dados, o Service Topology retém snapshots dos aggregadores fatiados no tempo e logs de mutação em nível de propriedades. Dessa forma, os engenheiros conseguem reconstruir virtualmente a árvore de dependências exata de qualquer momento no passado.
| Característica | Arquitetura Antiga | Nova Arquitetura (Escalada) |
|---|---|---|
| Estrutura do Pipeline | Estágio único concentrado | Três estágios desacoplados (Agregação, Resolução, Enriquecimento) |
| Transporte Interno | gRPC | Server-Sent Events (SSE) |
| Gestão de Carga | Descarte de dados sob estresse | Contrapressão reativa via Pekko Streams até o Kafka |
| Reconstrução Histórica | Snapshots de grafo pesado | Snapshots por janela de tempo e histórico de mutações |
Arraste para o lado para ver toda a tabela.
