Quando un incidente scoppia alle 3 di notte, una mappa delle dipendenze vecchia di un’ora è archeologia, non observability. Da questa premessa parte il racconto con cui il team di Netflix descrive come ha costruito il suo sistema di service topology: una vista unificata e quasi in tempo reale delle connessioni tra servizi, pensata per capire il blast radius di un guasto e velocizzare il troubleshooting.
La scelta architetturale di fondo è streaming-first. Invece dei classici batch orari o giornalieri, Netflix ingerisce di continuo i flow record da Kafka multi-region (4 region) e le metriche IPC come Server-Sent Events, aggiornando la topologia tipicamente nell’arco di qualche decina di minuti. A reggere il carico è il backpressure delle reactive streams: quando lo stage a valle non scrive abbastanza in fretta sul graph database, la pressione risale fino a mettere in pausa il consumer Kafka, e i dati aspettano nella coda invece di essere persi.
Tre stage per domare gli hot node
Il cuore dell’ingestione di rete è una pipeline distribuita in tre stage. I flow log mostrano solo i singoli hop (App A → load balancer → App B), mentre agli ingegneri serve la dipendenza logica App A → App B. Lo Stage 2 raggruppa i flussi per intermediario e li risolve in edge diretti; lo Stage 1 aggrega localmente in finestre da 5 minuti, lo Stage 3 arricchisce e persiste.
La versione a due stage funzionava nei test ma crollava in produzione: i servizi più popolari generavano hot node con fino a 100 volte il traffico degli altri, e la garbage collection consumava più CPU della logica applicativa. La ridistribuzione graduale su tre stage ha spalmato il carico; il passaggio da gRPC a SSE ha ridotto il consumo di risorse. Sull’hotpath, Netflix ha persino abbandonato l’immutabilità cara a Scala: strutture mutabili hanno tagliato l’allocazione di heap di oltre il 50% e ridotto le pause GC da centinaia a decine di millisecondi.
C’è anche il time travel: aggregatori con finestra temporale più mutation tracking a livello di proprietà permettono di ricostruire la topologia “com’era” durante un incidente, senza replay dei log. Il sistema oggi serve query con latenza sub-secondo su dati multi-region.
La lezione ricorrente è pragmatica: a questa scala le best practice sono punti di partenza, non dogmi. Si ottimizza un collo di bottiglia alla volta — prima il lag di Kafka, poi gli hot node, poi la GC — misurando a ogni passo.
In sintesi
- Architettura streaming-first con backpressure: freschezza in decine di minuti invece di ore, senza perdere dati.
- Pipeline a tre stage per risolvere gli intermediari e spalmare il carico degli hot node (fino a 100x).
- Scelte contro-intuitive (SSE al posto di gRPC, strutture mutabili) giustificate dalla misura, non dalla moda.
Fonte: Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned — https://netflixtechblog.com/building-service-topology-at-scale-architecture-challenges-and-lessons-learned-f4b792f3f0d8?source=rss—-2615bd06b42e—4
Hai qualcosa da aggiungere? Unisciti alla discussione.