Høy tilgjengelighet kontra feiltoleranse: Definisjoner og avveininger

High Availability (HA) og Fault Tolerance (FT) er to ulike mål for pålitelighet som arkitekter ofte forveksler. Høy tilgjengelighet betyr at et system har minimalt med nedetid — det kan tåle feil, men kan ha korte avbrudd under gjenoppretting. Feiltoleranse betyr at et system fortsetter å fungere uten avbrudd selv når komponenter svikter, fordi det har fullstendig redundante baner som overtar umiddelbart.

Tilgjengelighet måles som en prosentandel oppetid i løpet av et år. 99,9 % tilgjengelighet (tre niere) betyr omtrent 8,7 timer nedetid per år, mens 99,99 % (fire niere) tillater bare 52,6 minutter. 99,999 % (fem niere) tillater bare 5,26 minutter. Hver ekstra nier krever vanligvis mer redundans, automatisering og kostnader. SAA-C03-eksamen spør ofte hvilken arkitektur som oppfyller et gitt mål for tilgjengelighet.

En arkitektur med høy tilgjengelighet tåler at én komponent svikter, ved automatisk å oppdage feilen og bytte til en fungerende erstatning i løpet av sekunder eller minutter. Eksempler er RDS Multi-AZ (automatisk failover til en standby-instans i en annen AZ), Auto Scaling Groups som erstatter avsluttede instanser, og Elastic Load Balancers som ruter trafikken bort fra usunne mål. Det oppstår et kort avbrudd, men systemet gjenopprettes uten manuell inngripen.

En feiltolerant arkitektur har aktiv redundans — flere identiske komponenter som håndterer forespørsler samtidig, slik at de andre umiddelbart tar over belastningen når én svikter, uten nedetid. Eksempler er aktiv-aktiv ELB med flere EC2-instanser, DynamoDB Global Tables som håndterer lesing og skriving samtidig i flere regioner, og Aurora med flere lesereplikater. Feiltoleranse krever at flere ressurser kjører til enhver tid.

Feiltoleranse er betydelig dyrere enn høy tilgjengelighet fordi den krever fullt klargjort redundant kapasitet til enhver tid. En tilgjengelig RDS Multi-AZ-instans dobler databasekostnaden for en standby-instans som bare aktiveres ved feil. En feiltolerant aktiv-aktiv Aurora-distribusjon i flere regioner kan koste fire ganger så mye, men eliminerer all nedetid ved regionale feil. Arkitekter må veie kostnaden ved redundans opp mot virksomhetens kostnad ved nedetid.

Recovery Time Objective (RTO) er den maksimale tiden et system kan være utilgjengelig. Arkitekturer med høy tilgjengelighet tar sikte på lav RTO — vanligvis minutter — gjennom automatisk failover. Feiltolerante arkitekturer tar sikte på tilnærmet null RTO. Når De utformer en HA-løsning, må De velge tjenester og konfigurasjoner som garanterer gjenoppretting innenfor RTO-rammen. RDS Multi-AZ gir for eksempel en RTO på omtrent 60–120 sekunder, noe som passer for mange HA-krav.

Et Single Point of Failure (SPOF) er enhver komponent som får hele systemet til å svikte hvis den feiler. Vanlige SPOF-er omfatter én EC2-instans uten ASG, én RDS-database i én AZ, én NAT-gateway eller én tilgjengelighetssone. Å eliminere SPOF-er er det første steget mot både HA og FT. SAA-C03-eksamen tester ofte evnen Deres til å identifisere og eliminere SPOF-er i gitte arkitekturdiagrammer.

Det er langt enklere å oppnå HA eller FT for tilstandsløse tjenester (som webservere eller Lambda-funksjoner), fordi enhver instans kan håndtere enhver forespørsel. Tilstandsfulle tjenester (databaser, cacher og filsystemer) er vanskeligere — De må synkronisere tilstanden mellom replikaer, håndtere replikaforsinkelse og sikre konsistens under failover. AWS-tjenester som EFS (delt filsystem), ElastiCache with replication groups og Aurora (delt lagring) er utviklet for å gjøre tilstandsfull HA enklere.

Vanlige HA-mønstre på AWS omfatter: 1) Multi-AZ-belastningsfordeling — distribuer EC2-instanser på tvers av AZ-er bak en ALB. 2) Lesereplikaer — avlast lesetrafikk og promoter dem ved DR. 3) S3 for tilstandsløse ressurser — S3 har innebygd HA med 11 niere holdbarhet. 4) Global Accelerator — statiske Anycast-IP-adresser som ruter til friske endepunkter på tvers av regioner. Hvert mønster bytter kostnad mot et bestemt tilgjengelighetsnivå.

Feiltolerante mønstre krever aktiv redundans overalt. Viktige FT-mønstre er: DynamoDB er feiltolerant som standard — tjenesten replikerer data på tvers av tre AZ-er uten behov for failover. S3 har innebygd FT. Aurora Multi-Master (nå Aurora Serverless v2 multi-writer) tillater skriving til flere AZ-er samtidig. Kinesis lagrer data på tvers av flere AZ-er som standard. Å velge administrerte tjenester med innebygd FT er den mest kostnadseffektive veien til arkitekturer uten nedetid.

Utforming for HA eller FT er bare så god som testingen Deres. AWS anbefaler å bruke AWS Fault Injection Simulator (FIS) til å kjøre kontrollerte eksperimenter som avslutter instanser, begrenser API-er eller injiserer nettverksfeil. De bør kontrollere at failover faktisk fullføres innenfor RTO-en, at data ikke går tapt utover RPO-en, og at alarmene utløses riktig. Regelmessige «game days» og øvelser i kaosteknikk avdekker svakheter i antakelsene om robusthet før produksjonshendelser gjør det.

I denne leksjonen har De lært at høy tilgjengelighet minimerer nedetid gjennom automatisk gjenoppretting (RTO på minutter), at feiltoleranse eliminerer nedetid gjennom aktiv redundans (RTO på null), og at kostnadene øker betydelig med hvert nivå av robusthet. Eliminering av Single Points of Failure er grunnlaget for begge tilnærmingene. Neste tema er Multi-AZ-mønstre for tilstandsfulle tjenester.