Designa feltolerant och motståndskraftiga applikationer på AWS

Utveckla applikationer på AWS

Ricardo Sueiras

Principal Technologist

Bygga för motståndskraft

Tillfälliga fel

 

• Lär dig de vanliga feltyperna:
• Tillfälliga fel löser sig själva – vanligtvis säkert att försöka igen.

Tidsgränser

 

• Lär dig de vanliga feltyperna:
• Tillfälliga fel löser sig själva – vanligtvis säkert att försöka igen.
• Tidsgränser: en extern tjänst tar för lång tid att svara.

Permanenta fel

 

• Lär dig de vanliga feltyperna:
• Tillfälliga fel löser sig själva – vanligtvis säkert att försöka igen.
• Tidsgränser: en extern tjänst tar för lång tid att svara.
• Permanenta fel: förfrågan är fundamentalt felaktig – att försöka igen hjälper inte.

API-gränser

 

• Lär dig de vanliga feltyperna:
• Tillfälliga fel löser sig själva – vanligtvis säkert att försöka igen.
• Tidsgränser: en extern tjänst tar för lång tid att svara.
• Permanenta fel: förfrågan är fundamentalt felaktig – att försöka igen hjälper inte.
• API-hastighetsgränser: för många förfrågningar, förvänta dig HTTP 429 Too Many Requests.

Återförsöksstrategier

• Fel i distribuerade system är ofta tillfälliga.
• En ny förfrågan lyckas ofta.
• Lägg till återförsökslogik med omdöme – blinda återförsök kan förvärra situationen.
• Exponentiell backoff: öka fördröjningen mellan varje återförsök.
• Jitter: lägg till slumpmässighet för att undvika återförsökstoppar.
• Återförsöksgränser: förhindra oändliga loopar.

 

Inbyggda funktioner i AWS SDK

• AWS SDK:er hanterar återförsökslogik automatiskt.
• Inbyggda återförsök inkluderar exponentiell backoff och jitter.
• Misslyckade eller begränsade förfrågningar återförsöks med ökande fördröjningar.
• Minskar mängden felhanteringskod du behöver skriva.

 

Hantera återförsökslogik

 

• Återförsökslogik är inte alltid rätt lösning.
• HTTP 4xx-fel: servern förstod och avvisade din förfrågan.
• Icke-idempotenta förfrågningar: återförsök kan orsaka dubbletter eller inkonsistenta åtgärder.

Hantera tidsgränser

 

• Obegränsade återförsök kan förstärka problem under hög belastning.
• Kombinera återförsök med tidsgränser.
• En tidsgräns anger den maximala tid du väntar på ett svar.
• Varje anrop till en extern tjänst bör ha en tidsgräns.

Kretsbrytare

• När en tjänst fortsätter att misslyckas räcker inte återförsök ensamt.
• Att fortsätta skicka förfrågningar kan överbelasta den felande tjänsten.
• Kretsbrytarmönstret stoppar tillfälligt förfrågningar till ett problematiskt beroende.
• Stängt läge: förfrågningar flödar normalt.

 

Kretsbrytare

• När felen överstiger ett tröskelvärde öppnas kretsen.
• Efterföljande förfrågningar blockeras.

 

Kretsbrytare

• Efter en nedkylningsperiod övergår kretsen till halvöppet läge för att testa återhämtning.
• Tjänsten svarar utan fel: normal drift återupptas.
• Fortfarande fel: kretsen förblir öppen.
• Implementera kretsbrytare på applikationsnivå.

 

Dead letter queues

 

• Meddelanden som fortsätter att misslyckas kan blockera systemet.
• Flytta dem ur det ordinarie processflödet.
• Misslyckade meddelanden hamnar i en Dead Letter Queue.
• En viktig del av att bygga motståndskraftiga applikationer.
• Tänk dock på avvägningarna.

AWS API-gränser

 

• Du interagerar med AWS-tjänster via API:er.
• Varje tjänst definierar sina egna API-hastighetsgränser.
• Att överskrida gränserna utlöser begränsning (HTTP 429 Too Many Requests).
• Designa din applikation för att hantera begränsning på ett kontrollerat sätt.

Integrering med tredjepartstjänster

• Tredjepartstjänster medför osäkerhet.
• Du har ingen kontroll över deras prestanda eller tillgänglighet.
• Sätt tidsgränser för att undvika långa väntetider.
• Använd återförsök med backoff vid tillfälliga problem.
• Isolera beroenden för att begränsa skadeverkningarna.

 

Integrering med tredjeparter

• Överväg att gå från synkron till asynkron kommunikation.
• Ditt system fortsätter att bearbeta även om den externa tjänsten är försenad.

 

Nu kör vi en övning!

Utveckla applikationer på AWS