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

un

invité
1 / ?
retour aux leçons

Le nœud goulot d'étranglement identifié avant l'arrivée du trafic

Centralité d'intermédiation

Pour chaque paire de nœuds dans un graphe, il existe un chemin le plus court entre eux. La centralité d'intermédiation d'un nœud N = la fraction de tous les chemins les plus courts qui passent par N.

Un nœud avec une forte centralité d'intermédiation est sur le chemin entre de nombreuses autres paires. S'il ralentit, de nombreux flux ralentissent. S'il tombe en panne, de nombreux flux sont rompus.

Lecture architecturale : les nœuds à forte centralité d'intermédiation sont ceux à qui chaque revue d'architecture doit accorder une attention particulière. Ils sont des goulots d'étranglement, des points de défaillance unique (SPOF) & des composants critiques en capacité en un seul. Ils ont tendance à être :

- Le fournisseur DNS (entre chaque client & chaque service)

- Le proxy d'entrée (entre chaque client & chaque backend)

- La base de données principale (entre chaque backend & chaque lecture)

- Le service d'authentification (entre chaque utilisateur & chaque action autorisée)

Détection sans mesure : la topologie du graphe à elle seule identifie les nœuds à forte intermédiarité. Vous n'avez pas besoin de données de trafic ; vous avez besoin du diagramme d'architecture. Un nœud qui se situe entre de nombreuses paires d'autres nœuds est structurellement critique.

Conséquence opérationnelle : les nœuds à forte intermédiarité méritent un investissement disproportionné en (1) marge de capacité, (2) redondance, (3) observabilité, & (4) plans de réponse aux incidents.

Centralité d'intermédiarité : le nœud mis en évidence se trouve sur la plupart des plus courts chemins

Un système possède : 100 clients externes -> 1 DNS -> 1 fournisseur CDN -> 3 reverse proxies -> 12 répliques backend -> {1 base de données principale, 2 nœuds de cache, 5 points d'entrée API externes}. Classez ces classes de nœuds par centralité d'intermédiarité (de la plus haute à la plus basse), & expliquez pourquoi les deux premiers rangs méritent une attention particulière.

La plus petite coupe déconnecte la plus petite portion

Théorème de la coupe minimale en termes simples

Le min-cut (coupe minimale) entre deux nœuds dans un graphe = le plus petit nombre d'arêtes (ou de nœuds) qu'il faut supprimer pour les déconnecter.

Interprétation opérationnelle : le min-cut borne le rayon d'impact maximal (worst-case blast radius). Si le min-cut entre 'clients' et 'database' est de 1 arête (un simple proxy), alors la perte de cette arête déconnecte tous les clients de la base de données. Si le min-cut est de 5, il faut perdre 5 composants simultanément pour déconnecter complètement ; c'est un coup de malchance, mais le risque est borné.

Conception pour le rayon d'impact : augmenter le min-cut à chaque frontière importante. Plusieurs proxies ; plusieurs nœuds de cache ; plusieurs chemins réseau entre les centres de données. Chaque ajout augmente le min-cut de 1.

Le motif « bulkhead » en termes de graphe : partitionner les ressources en sous-graphes distincts qui ne partagent aucun min-cut entre eux. Une défaillance au sein d'un sous-graphe ne peut pas se propager aux autres, car les arêtes n'existent pas.

Le diamètre détermine la distance de propagation des pannes

Diamètre du graphe = le plus long des plus courts chemins entre deux nœuds quelconques.

Propagation des pannes : lorsqu'un nœud tombe en panne et que les nouvelles tentatives (retries) rebondissent, elles touchent les nœuds en amont jusqu'à la distance du diamètre. Un système de diamètre 3 (client -> proxy -> backend -> DB) signifie qu'une panne de la base de données affecte 3 couches en amont lors d'une tempête de nouvelles tentatives.

Implication : un diamètre plus court = un confinement des pannes plus rapide, mais aussi une plus grande concentration des nœuds. Chaque conception implique un compromis.

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

Calculer le min-cut pour une architecture réelle

Une architecture : 1 DNS, 1 CDN, 3 reverse proxies, 12 répliques backend, 1 base de données primaire.

Calculez (ou estimez) le min-cut aux trois frontières suivantes : (1) entre les clients externes et la couche de reverse proxy ; (2) entre la couche de reverse proxy et la couche backend ; (3) entre la couche backend et la base de données primaire. Pour chacune, indiquez ce qui échoue lorsque ce min-cut est dépassé.

Audit des modes de défaillance via des métriques de graphe

Synthèse

Vous pouvez désormais identifier les nœuds à haute intermédiarité, calculer la coupe minimale à chaque frontière et estimer la distance de propagation des pannes via le diamètre.

Appliquez les trois.

Un système : 50 points d'accès client -> 1 DNS -> 2 POPs CDN -> 4 reverse proxies -> 16 répliques backend -> { cluster de BDD (1 primaire + 2 standby), cluster Redis (5 nœuds), 3 API externes }.

Auditez le système : (1) nommez le nœud à la plus haute intermédiarité, (2) calculez la coupe minimale à la frontière la plus préoccupante, et (3) proposez deux modifications architecturales spécifiques (chacune augmentant une coupe minimale, chacune nommée avec la frontière qu'elle renforce).

Notes de compagnonnage

Notes de compagnonnage

Cette leçon de géométrie reformule la leçon principale Modes de défaillance & Rayon d'explosion à travers des métriques de graphe (centralité d'intermédiarité, coupe minimale, diamètre).

Le compagnon final, geometry_of_observability_and_capacity, traite des cellules de Voronoï pour les zones de captage des PoP CDN, du plancher de la vitesse de la lumière du triangle de latence, & de la courbe de mise en file réexaminée au niveau du proxy.

Bien joué.