Helsesjekker, kretsbrytere og logikk for nye forsøk

I distribuerte systemer svikter komponenter kontinuerlig – instanser krasjer, nettverkspartisjoner oppstår, og nedstrømstjenester blir overbelastet. Uten automatisert feildeteksjon fortsetter trafikken å strømme til komponenter som har sviktet, noe som forårsaker kaskaderende feil. AWS tilbyr flere lag med helsekontroller: ELB-helsekontroller oppdager ustabile instanser, Route 53-helsekontroller oppdager ustabile endepunkter, og Auto Scaling erstatter instanser som har sviktet. Mønstre på applikasjonsnivå, som circuit breakers og retries, fullfører bildet av robusthet.

Helsesjekker for Elastic Load Balancer sender med jevne mellomrom forespørsler til registrerte mål for å avgjøre om de er friske. De konfigurerer sti for helsesjekk (for eksempel /health), protokoll, port, intervall (standard er 30 sekunder) og terskel for frisk eller usunn (antall sammenhengende vellykkede eller mislykkede sjekker). Når et mål ikke består helsesjekkene, slutter ELB å dirigere trafikk til det. Målet evalueres kontinuerlig på nytt og legges til igjen når det har nådd terskelen for friske mål.

Helsesjekker i Route 53 overvåker endepunkter fra flere steder globalt og fungerer sammen med DNS-ruting for failover. Det finnes tre typer: Endepunktsjekker sender forespørsler direkte til URL-en til applikasjonen. Beregnede helsesjekker kombinerer flere underordnede helsesjekker med AND/OR-logikk (nyttig for kompleks overvåking). CloudWatch-alarmsjekker overlater helsevurderingen til CloudWatch – nyttig når De ikke kan eksponere et offentlig helsendepunkt, eller trenger helsevurderinger basert på måleverdier.

Auto Scaling-grupper kan bruke to typer helsesjekker: EC2-helsesjekker oppdager feil i instanser på hypervisornivå (feil i statussjekken for instansen). ELB-helsesjekker tar i større grad hensyn til applikasjonen – en instans kan være i drift, men likevel levere feil, og dette oppdages av ELB-helsesjekker. De kan konfigurere ASG til å bruke ELB-helsesjekker, slik at feil på applikasjonsnivå også utløser utskifting av instansen, og ikke bare underliggende EC2-feil.

En circuit breaker er et mønster på applikasjonsnivå som hindrer kaskaderende feil ved å overvåke kall til en nedstrøms tjeneste og midlertidig stoppe kall når antallet feil overskrider en terskel. Circuit breakeren har tre tilstander: Closed (normal drift), Open (terskelen for feil er overskredet, og kall blokkeres umiddelbart) og Half-Open (etter en tidsavbruddsperiode tillates et lite antall testkall for å kontrollere om tjenesten er gjenopprettet). AWS App Mesh og SDK-er for applikasjoner, som Resilience4j, implementerer dette mønsteret.

AWS App Mesh er et tjenestenett som implementerer circuit breaking, retries og tidsavbruddspolicyer på infrastrukturnivå uten kodeendringer. De definerer circuit breaker-policyer i konfigurasjonen for den virtuelle noden eller den virtuelle ruteren. Når en oppstrøms tjeneste blir usunn, åpner Envoy-proxyen i App Mesh automatisk circuit breakeren og returnerer feil umiddelbart i stedet for å vente på tidsavbrudd. Dette er spesielt verdifullt i mikrotjenestearkitekturer som kjører på ECS eller EKS.

Retry-logikk forsøker automatisk å utføre mislykkede operasjoner på nytt, men naiv retry-logikk (umiddelbar retry i en tett løkke) kan forverre situasjoner med overbelastning. Eksponentiell backoff øker ventetiden mellom forsøk eksponentielt: 1s, 2s, 4s, 8s ... Dette reduserer belastningen på en tjeneste som sliter, og gir den tid til å gjenopprette seg. Jitter (tilfeldig variasjon i retry-intervallene) hindrer problemet med en flokk som stormer til, der alle klienter prøver på nytt samtidig etter et kort avbrudd. AWS SDK implementerer automatisk eksponentiell backoff med jitter.

Retries er bare trygge hvis operasjonene er idempotente – det gir samme resultat å utføre den samme operasjonen flere ganger. Det er for eksempel idempotent å opprette et S3-objekt med samme nøkkel (samme resultat). Å legge inn en bestilling to ganger oppretter derimot to bestillinger – det er ikke idempotent. Utform API-er idempotent ved å bruke idempotensnøkler levert av klienten: Serveren lagrer resultatet av den første forespørselen og returnerer det samme resultatet for senere forespørsler med samme nøkkel. DynamoDB, SQS og API Gateway støtter mønstre med idempotensnøkler.

Uten eksplisitte tidsavbrudd kan en treg nedstrøms tjeneste føre til at tråder blokkeres på ubestemt tid, slik at tilkoblingspoolen tømmes og kaskaderende feil oppstår. Angi tidsavbrudd på hvert lag: tilkoblingstidsavbrudd (tiden det tar å opprette en TCP-tilkobling), lesetidsavbrudd (tiden det tar å motta et svar) og samlet tidsavbrudd for forespørselen. I AWS konfigurerer De inaktivitetstidsavbruddet for ELB (standard 60 s), kjøringstidsavbruddet for Lambda (maks. 15 min) og integrasjonstidsavbruddet for API Gateway (maks. 29 s). Tidsavbrudd utløser retry- eller circuit-breaker-logikken.

Når meldingsbehandlingen mislykkes gjentatte ganger, fanger en Dead Letter Queue (DLQ) opp meldinger som ikke kunne behandles etter det maksimale antallet mottaksforsøk. Konfigurer DLQ-er for SQS-køer og Lambda-tilordninger for hendelseskilder for å hindre at ugyldige meldinger blokkerer køen på ubestemt tid. Meldinger i DLQ-en kan inspiseres, spilles av på nytt etter at feilen er rettet, eller arkiveres. DLQ-er er en kritisk komponent i robuste hendelsesdrevne arkitekturer.

Effektive helsesjekker og circuit breakere krever overvåking for å forstå feilmønstre. CloudWatch er laget for observability: opprett alarmer for ELB UnHealthyHostCount (instanser som ikke består helsesjekkene), frekvensen for Lambda Errors, SQS NumberOfMessagesSentToDLQ (meldinger som havner i DLQ) og Target group RequestCountPerTarget. Sett opp SNS-varsler slik at vaktteamet umiddelbart blir varslet når automatiske helsesjekker oppdager forringet tilstand.

I denne leksjonen har De lært at ELB- og Route 53-helsesjekker automatiserer feildeteksjon på infrastrukturnivå, at circuit breakere hindrer kaskaderende feil ved å stoppe kall til usunne tjenester, og at eksponentiell backoff med jitter gjør retries trygge under belastning. Dead Letter Queues fanger opp mislykkede meldinger for inspeksjon. Neste tema er RTO, RPO og nivåer for katastrofegjenoppretting.