English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

ospite
1 / ?
torna alle lezioni

Il Nodo Collo di Bottiglia Identificato Prima dell'Arrivo del Traffico

Centralità di Interposizione

Per ogni coppia di nodi in un grafo, esiste un percorso più breve tra di essi. La centralità di interposizione di un nodo N = la frazione di tutti i percorsi più brevi che passano attraverso N.

Un nodo con alta centralità di interposizione si trova sul percorso tra molte altre coppie. Se rallenta, molti flussi rallentano. Se si guasta, molti flussi si interrompono.

Lettura architetturale: i nodi con alta centralità di interposizione sono quelli a cui ogni revisione architetturale dovrebbe prestare particolare attenzione. Sono colli di bottiglia, SPOF e componenti critici per la capacità, tutto in uno. Tendono a essere:

- Il provider DNS (tra ogni client e ogni servizio)

- Il proxy di ingresso (tra ogni client e ogni backend)

- Il database primario (tra ogni backend e ogni lettura)

- Il servizio di autenticazione (tra ogni utente e ogni azione autorizzata)

Rilevamento senza misurazione: la sola topologia del grafo identifica i nodi con alta centralità di intermediazione. Non servono dati sul traffico; serve il diagramma dell'architettura. Un nodo che si trova tra molte coppie di altri nodi è strutturalmente critico.

Conseguenza operativa: i nodi con alta centralità di intermediazione meritano un investimento sproporzionato in (1) margine di capacità, (2) ridondanza, (3) osservabilità e (4) playbook per la risposta agli incidenti.

Centralità di intermediazione: il nodo evidenziato si trova sulla maggior parte dei cammini più brevi

Un sistema ha: 100 client esterni -> 1 DNS -> 1 vendor CDN -> 3 proxy inversi -> 12 repliche backend -> {1 DB primario, 2 nodi cache, 5 endpoint API esterni}. Classifica queste classi di nodi per centralità di intermediazione (dal più alto al più basso) e spiega perché le prime due posizioni meritano un'attenzione particolare.

Il taglio minimo disconnette la porzione minima

Teorema del Min-Cut in termini semplici

Il min-cut tra due nodi in un grafo = il numero minimo di archi (o nodi) che devono essere rimossi per disconnetterli.

Interpretazione operativa: il min-cut pone un limite al raggio d'azione (blast radius) peggiore nel caso limite. Se il min-cut tra 'clients' e 'database' è 1 arco (un singolo proxy), la perdita di quell'arco disconnette tutti i client dal database. Se il min-cut è 5, è necessario perdere 5 componenti simultaneamente per disconnettere completamente; sfortuna, ma limitata.

Progettazione per il raggio d'azione: aumentare il min-cut a ogni confine importante. Multipli proxy; multipli nodi di cache; multipli percorsi di rete tra i DC. Ogni aggiunta aumenta il min-cut di 1.

Il pattern bulkhead in termini di grafo: partizionare le risorse in sotto-grafi separati che non condividono alcun min-cut tra loro. Un guasto all'interno di un sotto-grafo non può propagarsi agli altri perché gli archi non esistono.

Il diametro definisce la distanza di propagazione del guasto

Diametro del grafo = il più lungo tra i cammini minimi tra due nodi qualsiasi.

Propagazione del guasto: quando un nodo fallisce e i retry fluiscono all'indietro, toccano i nodi upstream fino alla distanza del diametro. Un sistema con diametro 3 (client -> proxy -> backend -> DB) significa che un guasto del DB influisce su 3 livelli upstream in una tempesta di retry.

Implicazione: diametro più corto = contenimento del guasto più rapido ma anche maggiore concentrazione dei nodi. Ogni progettazione ha i suoi compromessi.

Min-cut as bound on blast radius; diameter as propagation distance

Calcolo del Min-Cut per un'architettura reale

Un'architettura: 1 DNS, 1 CDN, 3 reverse proxy, 12 repliche backend, 1 DB primario.

Calcola (o stima) il min-cut a tre confini: (1) tra i client esterni e il livello di reverse proxy; (2) tra il livello di reverse proxy e il livello backend; (3) tra il livello backend e il DB primario. Per ciascuno, indica cosa fallisce quando quel min-cut viene superato.

Audit dei modi di guasto tramite metriche di grafo

Sintesi

Ora puoi identificare i nodi con alta betweenness, calcolare il min-cut a ogni confine e stimare la distanza di propagazione dei guasti tramite il diametro.

Applica tutti e tre.

Un sistema: 50 endpoint client -> 1 DNS -> 2 POP CDN -> 4 proxy inversi -> 16 repliche backend -> { cluster DB (1 primario + 2 standby), cluster Redis (5 nodi), 3 API esterne }.

Esegui l'audit del sistema: (1) indica il nodo con la più alta betweenness, (2) calcola il min-cut al confine più critico e (3) proponi due modifiche architetturali specifiche (ciascuna deve aumentare un min-cut e deve essere indicata specificando il confine che rafforza).

Note di accompagnamento

Note di accompagnamento

Questa lezione sulla geometria ricalca la lezione principale Modalità di Guasto e Raggio d'Impatto attraverso metriche grafo (centralità di intermediazione, taglio minimo, diametro).

L'ultima nota di accompagnamento, geometry_of_observability_and_capacity, tratta le celle di Voronoi per le aree di copertura dei PoP CDN, il limite inferiore della velocità della luce del triangolo di latenza e la curva di code riconsiderata al livello proxy.

Ben fatto.