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 Bottiglia Identificato Prima che il Traffico Arrivi

Centralità di Betweenness

Per ogni coppia di nodi in un grafo, c'è un percorso più breve tra di loro. Centralità di betweenness di un nodo N = la frazione di tutti i percorsi più brevi che passano attraverso N.

Un nodo con alta centralità di betweenness è su un percorso tra molte altre coppie. Se si rallenta, molti flussi si rallentano. Se fallisce, molti flussi si interrompono.

Lettura architettonica: i nodi con alta centralità di betweenness sono quelli a cui ogni revisione architettonica dovrebbe prestare attenzione in modo particolare. Sono bottiglie, SPOFs e componenti capacità in una. Tendono a essere:

- Il fornitore 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)

Detezione senza misurazione: la topologia del grafo identifica da sola i nodi con alta centralità di betweenness. Non ti serve dati sul traffico; hai bisogno del diagramma dell'architettura. Un nodo che si trova tra molte coppie di altri è criticamente strutturale.

Conseguenza operativa: i nodi con alta centralità di betweenness meritano investimenti sproporzionati in (1) spazio di testa per la capacità, (2) ridondanza, (3) osservabilità e (4) piani di risposta agli incidenti.

Centralità di betweenness: il nodo evidenziato si trova su la maggior parte dei percorsi più brevi

Un sistema ha: 100 clienti esterni -> 1 DNS -> 1 fornitore CDN -> 3 reverse proxy -> 12 replica backend -> {1 DB primario, 2 nodi cache, 5 endpoint API esterni}. Classifica queste classi di nodi per centralità di betweenness (primo più alto) e spiega perché i primi due gradi meritano particolare attenzione.

Il Piccolo Taglio Sconnette la Piccola Fetta

Teorema del Taglio Minimo in Termini Piani

Il taglio minimo tra due nodi in un grafo = il numero minimo di archi (o nodi) che devi rimuovere per disconnetterli.

Lettura operativa: i minimi tagli limitano il raggio d'azione peggiore. Se il minimo taglio tra 'clienti' & 'database' è di un solo edge (una sola proxy), la perdita di quell'edge disconnette tutti i clienti dal database. Se il minimo taglio è di 5, è necessario perdere 5 componenti contemporaneamente per disconnettere completamente; sfortuna, ma limitata.

Progettazione per il raggio d'azione: aumentare il minimo taglio a ogni importante confine. Multipli di proxy; nodi cache multipli; più percorsi di rete tra DC. Ogni aggiunta aumenta il minimo taglio di 1.

Il modello a bulkhead in termini di grafico: suddividere le risorse in sottografi separati che non condividono alcun minimo taglio tra loro. Un fallimento all'interno di un sottografo non può propagarsi agli altri perché le edge non esistono.

Imposta il raggio di distruzione della propagazione dell'errore

Diametro del grafico = la strada più lunga più corta tra qualsiasi due nodi.

Propagazione dell'errore: quando un nodo fallisce & i flussi si ripetono indietro, toccano nodi upstream fino a una distanza di propagazione del diametro. Un sistema a diametro-3 (client -> proxy -> backend -> DB) significa che una fallita DB influisce su 3 strati upstream in una tempesta di ripetizioni.

Implicazione: diametro più corto = contenimento più rapido dell'errore, ma anche più concentrazione di nodi. Ogni design ha il suo trade-off.

Minimo taglio come limite del raggio d'azione; diametro come distanza di propagazione dell'errore

Calcola il Minimo Taglio per una Reale Architettura

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

Calcola (o stima) il minimo taglio a tre confini: (1) tra i clienti esterni e il livello del reverse-proxy; (2) tra il livello del reverse-proxy e il livello back-end; (3) tra il livello back-end e il DB primario. Per ciascuno, nominare cosa fallisce quando quel minimo taglio è superato.

Audit dei modi di fallimento tramite metriche di grafico

Sintesi

Ora puoi identificare i nodi con alto betweenness, calcolare il minimo taglio a ogni confine e stimare la distanza di propagazione dell'errore tramite il diametro.

Applica tutti e tre.

Un sistema: 50 punti di fine cliente -> 1 DNS -> 2 POP CDN -> 4 reverse proxy -> 16 replica backend -> { cluster DB (1 primario + 2 di riserva), cluster Redis (5 nodi), 3 API esterni }.

Audit del sistema: (1) nominare il nodo con il più alto betweenness, (2) calcolare il minimo taglio al confine più preoccupante e (3) proporre due specifiche modifiche architettoniche (ciascuna che aumenta un minimo taglio, ciascuna denominata con il confine che lo rafforza).

Note di accompagnamento

Note di accompagnamento

Questa lezione sulla geometria della rete ripensa la lezione principale Modi di fallimento e Raggio d'azione attraverso metriche di rete (betweenness, min-cut, diametro).

L'ultima compagna, geometry_of_observability_and_capacity, tratta le celle di Voronoi per le aree di cattura dei POP CDN, il pavimento della velocità della luce del triangolo di latenza e la curva della coda rivista al livello del proxy.

Ben fatto.