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

un

gast
1 / ?
terug naar lessen

Knopen, Kanten, Richtingen

Een Aanvraag Als Loop Op Een Grafiek

Elk component dat een aanvraag raakt is een knop: client, DNS oplosser, CDN rand, omgekeerde proxy, achterste replica, database, cache.

Elke verbinding tussen twee knopen is een gerichte kant: aanvragen stromen voorwaarts, reacties stromen terug. De voorwaartse kant vertegenwoordigt een open TCP-verbinding plus de bovenopliggende protocol.

Een enkele aanvraag is een pad door deze grafiek. Het totale werk dat het systeem doet om de aanvraag te beantwoorden, gelijk aan het som van het werk bij elke knop, plus de vertraging van elke kant.

Waarom zorgen? Zodra je de grafiek tekent, komen eigenschappen naar boven die onzichtbaar zijn in de code:

- Sprongen: het aantal kanten in het pad. Elke sprong voegt vertraging toe (netwerkronde + knopenverwerking). Minder sprongen = lager plafond op vertraging.

- In-graad: hoeveel kanten wijzen IN een knop. Hoog in-graad betekent dat de knop aanvragen van veel bronnen ontvangt & zich moet schalen of zichzelf moeten beschermen.

- Uit-graad: hoeveel kanten wijzen UIT een knop. Hoog uit-graad betekent dat de knop afhankelijk is van veel downstreams & veel manieren heeft om te falien.

- Doorsnijdende knop: een enkele knop wiens verwijdering de grafiek ontwricht. Een omgekeerde proxy met geen gelijke is een doorsnijdende knop; het verwijderen ervan verwijdert toegang tot zijn oorsprongen.

Aanvraag als pad door gecoordineerde grafiek: client, proxy, backend, database

Teken (of beschrijf in tekst) de aanvraaggrafiek voor: client browser -> CDN rand -> omgekeerde proxy -> achterste replica -> database. Tel de sprongen. Identificeer de doorsnijdende knopen. Voorspel één operationele gevolg van het hebben van zoveel doorsnijdende knopen op rij.

Waar Verkeer Samenkomt

Fan-In = Concentratie

In-graden van een knoop = het aantal randen dat op het punt naar het toe wijzen. In een aanvraaggraf, in-graden = het aantal upstream bronnen dat verzoeken stuurt.

Fan-in patroon: veel clients -> een CDN; veel CDN randen -> weinig oorspronkelijke proxies; veel proxies -> weinig back-end kopieën; veel back-ends -> enkele database.

Concentratie doet ertoe omdat het hoogste in-graden knooppunt het meeste samengestelde belasting ziet. De DB aan het eind van de keten kan vragen van elke actieve aanvraag in het hele systeem zien, zelfs als geen enkele gebruiker veel genereert.

Fan-Out = Afhankelijkheid

Uit-graden van een knoop = het aantal randen dat uit het punt wijst. Hoog uit-graden betekent veel neerwaarts afhankelijkheden.

Een back-end dat een database, twee caches, drie externe API's en een wachtrij aanroept, heeft uit-graden 7. Zijn succeskans is ongeveer het product van de succeskans van elk neerwaarts (als allemaal nodig zijn voor een succesvolle reactie).

0,999 ^ 7 ongeveer gelijk aan 0,993: een back-end met 7 neerwaarts, elk met een betrouwbaarheid van 99,9%, kan slechts ongeveer 99,3% betrouwbaarheid zelf bereiken, zelfs zonder eigen bugs.

Vermindert uit-graden door: caching van neerwaartse resultaten, maken van niet-kritieke neerwaarts optioneel (zachte daling), paralleliseren van wat parallel kan.

De Asymmetrie

Fan-in concentreert de belasting; fan-out vermenigvuldigt het risico. Een goed gevormde graf minimaliseert beide op het hoogste impact knooppunten.

De database (hoogste fan-in): cache agressief om de belasting te verminderen. Leesreplica's om de fan-in over meerdere knopen te verspreiden.

De orchestrator service (hoogste fan-out): circuitbreakers per afhankelijkheid, zachte daling, bulkheads.

Een back-end replica roept 4 neerwaarts services aan, elk onafhankelijk met een beschikbaarheid van 99,95%. (1) Wat is de bovengrondse waarborg op de beschikbaarheid van de back-end als alle 4 aanroepen nodig zijn voor een succesvolle reactie? (2) Als 2 van de 4 neerwaarts optioneel worden gemaakt via matige afname (vervangen door gecacheerde fallbacks wanneer onbeschikbaar), wat wordt de grens dan?

Een Ingewijde Knop Koopt Flexibiliteit

Omweg = Toevoegen van een Tussenknop

Zonder proxy is het graf: klant -> backend. De klant moet weten over de achterkant van de adres. Het verplaatsen van de achterkant vereist het bijwerken van de klant (via DNS of configuratie). Dit is een strak binden.

Met een proxy wordt het graf: klant -> proxy -> backend. De klant weet alleen maar over de proxy. Het verplaatsen van de achterkant vereist het bijwerken van de proxy's upstream-configuratie, niet van de klant.

De grafoperatie: voeg een knop toe langs een bestaande rand. De nieuwe rand klant -> proxy is stabiel; de nieuwe rand proxy -> backend is nu het team's om te beheren.

Geometrische lezing: omweg voegt een laag toe die de upstream-verandering losmaakt van de downstream-verandering. Elk laag's randen kunnen onafhankelijk van elkaar herwijken.

Kosten van Omweg

Elke laag voegt toe:

- Eén sprong van vertraging (de rand van klant naar proxy)

- Eén meer snijpunt op het pad (de proxy zelf)

- Eén meer plaats waar misconfiguratie kan gebeuren

De voordelen (herwijken, schalen, beschermen, beëindigen van TLS, distribueren van belasting) wegen vaak op tegen de kosten voor elk niet-triviale systeem. Maar er is een limiet: elke laag van omwegen voegt nog een sprong & een andere SPOF-kandidaat toe.

Het volksgeloof: elk probleem kan worden opgelost door een laag toe te voegen van omwegen (behalve het probleem van te veel lagen van omwegen).

Een team voegt een CDN toe voor een bestaande reverse proxy. De pad gaat van `klant -> proxy -> backend` (2 sprongen) naar `klant -> CDN -> proxy -> backend` (3 sprongen). Noem twee voordelen van de omweg (graf-theoretische termen zijn welkom) & twee kosten.

Lees een Architectuur als Graf

Samenvatting

Je kunt nu een systeemarchitectuur lezen als een graf: tel sprongen, identificeer snijknopen, meet fan-inconcentratie, bereken beschikbaarheidspanten van fan-out & evalueren omweg-handelsvoeten.

Pas alles toe.

Een nieuw service heeft deze architectuur: klanten -> CDN -> omgekeerde proxy (2 replica's) -> achtervoeg (8 replica's) -> { primaire DB, cachecluster (3 knopen), externe API }.

Analyseer: (1) wat is de maximale sprongentelling op een enkele aanvraagpad, (2) welke laag heeft de hoogste fan-in (& wat betekent dit voor schalen), (3) wat is het achterste plafond van beschikbaarheid als de DB is 99,95%, de cache is 99,95%, en de externe API is 99,9%, en (4) welke enkele knop, als hij wordt verwijderd, zou het meeste gebruikers loskoppelen?

Complementaire Notities

Complementaire Notities

Deze meetles omzet de Proxies & Origins hoofdles in een geanalyseerde richtinggrafiek.

De volgende complement in deze cursus, geometry_of_stateless_horizontal_scaling, neemt de replica-wiskunde uit de hoofdscalingsles en trekt de wachtrijcurve, Little's Wet en het 80% benuttingsslijtvlak wiskundig.

Goed gedaan.