Kuntotarkistukset, circuit breakerit ja uudelleenyrityslogiikka
Käytä ELB:n kuntotarkistuksia, Route 53:n päätepistetarkistuksia ja sovellustason circuit breakereita vikojen havaitsemiseen ja liikenteen automaattiseen uudelleenreititykseen.
Kuntotarkistukset, circuit breakerit ja uudelleenyrityslogiikka on ilmainen Cloud & IT Cert Prep-oppitunti CoddyKitissä. Tämä on oppitunti 4/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Cloud & IT Cert Prep-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.
Miksi automaattinen vian havaitseminen on tärkeää
Hajautetuissa järjestelmissä komponentteja vikaantuu jatkuvasti: instansseja kaatuu, verkkosegmentointeja tapahtuu ja downstream-palvelut kuormittuvat liikaa. Ilman automaattista vian havaitsemista liikenne jatkaa kulkuaan vikaantuneille komponenteille, mikä aiheuttaa ketjuuntuvia vikoja. AWS tarjoaa useita kuntotarkistusten tasoja: ELB:n kuntotarkistukset havaitsevat vialliset instanssit, Route 53:n kuntotarkistukset havaitsevat vialliset päätepisteet ja Auto Scaling korvaa vikaantuneet instanssit. Sovellustason mallit, kuten circuit breakerit ja uudelleenyritykset, täydentävät vikasietoisuutta.
ELB:n kuntotarkistukset
Elastic Load Balancerin kuntotarkistukset lähettävät rekisteröidyille kohteille säännöllisesti pyyntöjä niiden toimintakunnon määrittämiseksi. Määritätte kuntotarkistuksen polun (esim. /health), protokollan, portin, tarkistusvälin (oletusarvoisesti 30 sekuntia) sekä kunnossa olevan / toimimattoman kohteen kynnysarvon (peräkkäisten onnistumisten tai epäonnistumisten määrä). Kun kohde ei läpäise kuntotarkistuksia, ELB lopettaa liikenteen reitittämisen sille. Kohteen tila arvioidaan jatkuvasti uudelleen, ja se lisätään takaisin, kun se saavuttaa kunnossa olevan kohteen kynnysarvon.
# Configure ALB target group health check
aws elbv2 modify-target-group \
--target-group-arn arn:aws:elasticloadbalancing::123:targetgroup/my-tg/abc \
--health-check-protocol HTTPS \
--health-check-port 443 \
--health-check-path /health \
--health-check-interval-seconds 15 \
--healthy-threshold-count 2 \
--unhealthy-threshold-count 3 \
--matcher HttpCode=200Route 53:n kuntotarkistukset
Route 53:n kuntotarkistukset valvovat päätepisteitä useista sijainneista eri puolilta maailmaa ja toimivat yhdessä DNS:n vikasietoreitityksen kanssa. Kuntotarkistuksia on kolmea tyyppiä: päätepisteiden tarkistukset lähettävät kyselyitä suoraan sovelluksen URL-osoitteeseen. Lasketut tarkistukset yhdistävät useita alitason kuntotarkistuksia AND- tai OR-logiikalla, mikä on hyödyllistä monimutkaisessa valvonnassa. CloudWatch-hälytystarkistukset siirtävät kuntomäärityksen CloudWatchille — tämä on hyödyllistä, kun julkista kuntopäätepistettä ei voi asettaa saataville tai kun kuntopäätösten on perustuttava mittareihin.
# Create endpoint health check
aws route53 create-health-check \
--caller-reference ref-$(date +%s) \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "api.example.com",
"Port": 443,
"ResourcePath": "/health",
"RequestInterval": 10,
"FailureThreshold": 2,
"EnableSNI": true
}'Auto Scalingin kuntotarkistukset
Auto Scaling -ryhmät voivat käyttää kahdenlaisia kuntotarkistuksia: EC2-kuntotarkistukset havaitsevat ilmentymien vikatilanteet hypervisoritasolla (ilmentymän tilatarkistuksen epäonnistuminen). ELB-kuntotarkistukset huomioivat sovelluksen toiminnan paremmin — ilmentymä voi olla käynnissä mutta palauttaa virheitä, minkä ELB-kuntotarkistukset havaitsevat. Voitte määrittää ASG:n käyttämään ELB-kuntotarkistuksia, jolloin myös sovellustason virheet käynnistävät ilmentymän korvaamisen eivätkä ainoastaan taustalla olevat EC2-virheet.
# Configure ASG to use ELB health checks
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--health-check-type ELB \
--health-check-grace-period 300
# Grace period: time after launch before health checks start
# Prevents premature termination during startupCircuit breaker -malli
Circuit breaker on sovellustason malli, joka estää ketjuuntuvia vikoja valvomalla kutsuja taustalla olevaan palveluun ja keskeyttämällä kutsut tilapäisesti, kun virheiden määrä ylittää kynnysarvon. Circuit breakerilla on kolme tilaa: Closed (normaali toiminta), Open (virheiden määrä on ylittänyt kynnysarvon ja kutsut estetään välittömästi) ja Half-Open (aikakatkaisun jälkeen sallitaan pieni määrä testikutsuja sen tarkistamiseksi, onko palvelu palautunut). AWS App Mesh ja Resilience4j:n kaltaiset sovellusten SDK:t toteuttavat tämän mallin.
# Circuit breaker states
# CLOSED: All calls pass through
# failureCount < threshold -> stay CLOSED
# failureCount >= threshold -> open circuit
# OPEN: All calls fail immediately
# After timeout -> enter HALF-OPEN
# HALF-OPEN: Allow limited test calls
# Success -> return to CLOSED
# Failure -> return to OPEN
# Example threshold: 5 failures in 10 seconds -> OPENAWS App Mesh circuit breaker -toiminnossa
AWS App Mesh on service mesh, joka toteuttaa circuit breaker -toiminnon, uudelleenyritykset ja aikakatkaisukäytännöt infrastruktuuritasolla ilman koodimuutoksia. Määritätte circuit breaker -käytännöt virtual node- tai virtual router -määrityksissä. Kun ylävirran palvelu muuttuu toimintakyvyttömäksi, App Meshin Envoy-välityspalvelin avaa circuit breaker -piirin automaattisesti ja palauttaa virheet välittömästi sen sijaan, että se odottaisi aikakatkaisuja. Tämä on erityisen hyödyllistä ECS- tai EKS-ympäristössä toimivissa mikropalveluarkkitehtuureissa.
# App Mesh virtual node with circuit breaker
# (JSON configuration)
{
'spec': {
'listeners': [{
'outlierDetection': {
'consecutiveErrors': 5,
'interval': {'unit': 'ms', 'value': 10000},
'baseEjectionDuration': {'unit': 's', 'value': 30},
'maxEjectionPercent': 50
}
}]
}
}Uudelleenyrityslogiikka ja eksponentiaalinen backoff
Uudelleenyrityslogiikka yrittää epäonnistuneita toimintoja automaattisesti uudelleen, mutta naiivi uudelleenyrityslogiikka (välitön uudelleenyritys tiiviissä silmukassa) voi pahentaa ylikuormitustilanteita. Eksponentiaalinen backoff kasvattaa uudelleenyritysten välistä odotusaikaa eksponentiaalisesti: 1 s, 2 s, 4 s, 8 s... Tämä vähentää kuormitusta ongelmista kärsivässä palvelussa ja antaa sille aikaa palautua. Jitter (uudelleenyritysvälien satunnaistaminen) estää thundering herd -ongelman, jossa kaikki asiakkaat yrittävät uudelleen samanaikaisesti lyhyen käyttökatkon jälkeen. AWS SDK toteuttaa eksponentiaalisen backoffin ja jitterin automaattisesti.
# AWS SDK retries with exponential backoff automatically
# Default retry config for most AWS services:
# Max retries: 3-5 (varies by service)
# Base delay: 100ms
# Max delay: ~20 seconds
# Python boto3 custom retry configuration
import boto3
from botocore.config import Config
config = Config(
retries={'max_attempts': 5, 'mode': 'adaptive'}
)
client = boto3.client('s3', config=config)Idempotenssi turvallisia uudelleenyrityksiä varten
Uudelleenyritykset ovat turvallisia vain, jos toiminnot ovat idempotentteja — saman toiminnon suorittaminen useita kertoja tuottaa saman tuloksen. Esimerkiksi S3-objektin luominen samalla avaimella on idempotenttia (tulos on sama). Tilauksen tekeminen kahdesti kuitenkin luo kaksi tilausta, joten se ei ole idempotenttia. Suunnitelkaa rajapinnat idempotenteiksi käyttämällä asiakkaan toimittamia idempotenssiavaimia: palvelin tallentaa ensimmäisen pyynnön tuloksen ja palauttaa saman tuloksen myöhemmille pyynnöille, joissa käytetään samaa avainta. DynamoDB, SQS ja API Gateway tukevat idempotenssiavainten käyttöön perustuvia malleja.
# SQS message deduplication ID for FIFO queues
aws sqs send-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders.fifo \
--message-body '{"orderId":"ord-123","items":[...]}' \
--message-group-id 'customer-456' \
--message-deduplication-id 'ord-123-attempt-1'
# SQS deduplicates messages with same ID for 5 minutesAikakatkaisujen määritys
Ilman nimenomaisesti määritettyjä aikakatkaisuja hidas taustalla oleva palvelu saa säikeet odottamaan loputtomasti, jolloin yhteyspooli tyhjenee ja ketjuuntuvat viat alkavat. Määrittäkää aikakatkaisut jokaisella tasolla: yhteyden aikakatkaisu (TCP-yhteyden muodostamiseen kuluva aika), lukemisen aikakatkaisu (vastauksen vastaanottamiseen kuluva aika) ja koko pyynnön aikakatkaisu. Määrittäkää AWS:ssä ELB:n käyttämättömän yhteyden aikakatkaisu (oletusarvo 60 s), Lambdan suorituksen aikakatkaisu (enintään 15 min) ja API Gatewayn integraation aikakatkaisu (enintään 29 s). Aikakatkaisut käynnistävät uudelleenyritys- tai circuit breaker -logiikan.
# Lambda: set execution timeout
aws lambda update-function-configuration \
--function-name my-function \
--timeout 30
# ALB: configure idle timeout
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn <ALB-ARN> \
--attributes Key=idle_timeout.timeout_seconds,Value=60
# API Gateway: integration timeout max 29000msKuolleiden kirjainten jonot epäonnistuneelle käsittelylle
Kun viestin käsittely epäonnistuu toistuvasti, Dead Letter Queue (DLQ) kerää viestit, joita ei voitu käsitellä vastaanottoyritysten enimmäismäärän jälkeen. Määrittäkää DLQ:t SQS-jonoille ja Lambdan tapahtumalähdemäärityksille, jotta virheelliset viestit eivät estä jonoa loputtomasti. DLQ:ssa olevat viestit voidaan tarkastaa, käsitellä uudelleen virheen korjaamisen jälkeen tai arkistoida. DLQ:t ovat tapahtumaohjautuvien vikasietoisten arkkitehtuurien keskeinen osa.
# Configure DLQ on SQS queue
aws sqs set-queue-attributes \
--queue-url https://sqs.us-east-1.amazonaws.com/123/main-queue \
--attributes '{
"RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123:dlq\",\"maxReceiveCount\":3}"
}'
# After 3 failed processing attempts, message goes to DLQVirheiden havainnointi CloudWatchilla
Tehokkaat kuntotarkistukset ja circuit breakerit edellyttävät valvontaa, jotta virheiden malleja voidaan ymmärtää. CloudWatch on observability-taso: luokaa hälytykset seuraaville mittareille: ELB UnHealthyHostCount (kuntotarkistuksissa epäonnistuvat ilmentymät), Lambda Errors -määrä, SQS NumberOfMessagesSentToDLQ (DLQ:hun päätyvät viestit) ja kohderyhmän RequestCountPerTarget. Määrittäkää SNS-ilmoitukset, jotta päivystävä tiiminne saa heti hälytyksen, kun automaattiset kuntotarkistukset havaitsevat palvelun toiminnan heikkenemisen.
# CloudWatch alarm for unhealthy hosts
aws cloudwatch put-metric-alarm \
--alarm-name 'ALB-UnhealthyHosts' \
--alarm-description 'Alert when targets fail health checks' \
--metric-name UnHealthyHostCount \
--namespace AWS/ApplicationELB \
--period 60 \
--evaluation-periods 2 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--alarm-actions arn:aws:sns:us-east-1:123:ops-teamPikatesti
Testatkaa, miten hallitsette tämän oppitunnin AWS Solutions Architect (SAA-C03) -käsitteet.
Oppitunnin kertaus
Tässä oppitunnissa opitte, että ELB:n ja Route 53:n kuntotarkistukset automatisoivat vikojen havaitsemisen infrastruktuuritasolla, circuit breakerit estävät ketjuuntuvia vikoja keskeyttämällä kutsut toimintakyvyttömiltä palveluilta ja eksponentiaalinen backoff jitterin kanssa tekee uudelleenyrityksistä turvallisia kuormitustilanteissa. Dead Letter Queue -jonot keräävät epäonnistuneet viestit tarkasteltaviksi. Seuraavaksi tutustumme RTO:hon, RPO:hon ja disaster recovery -tasoihin.
Opi Cloud & IT Cert Prep tekoälytuutorin avulla — ilmaiseksi
Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.
- Kurssit
- 150
- Oppitunnit
- 600
Usein kysytyt kysymykset
Onko oppitunti ”Kuntotarkistukset, circuit breakerit ja uudelleenyrityslogiikka” ilmainen?
Kyllä – oppitunnin ”Kuntotarkistukset, circuit breakerit ja uudelleenyrityslogiikka” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Cloud & IT Cert Prep-kurssin, päivitä CoddyKit PROhon. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.
Mitä opin oppitunnilla ”Kuntotarkistukset, circuit breakerit ja uudelleenyrityslogiikka”?
Käytä ELB:n kuntotarkistuksia, Route 53:n päätepistetarkistuksia ja sovellustason circuit breakereita vikojen havaitsemiseen ja liikenteen automaattiseen uudelleenreititykseen. Harjoittelet Cloud & IT Cert Prep-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.
Tarvitsenko kokemusta aloittaakseni Cloud & IT Cert Prep-opiskelun?
Aiempi kokemus ei ole tarpeen. CoddyKitin Cloud & IT Cert Prep-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 4/4.
Kuinka kauan ”Kuntotarkistukset, circuit breakerit ja uudelleenyrityslogiikka”-oppitunnin suorittaminen kestää?
Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.
Voinko kirjoittaa ja suorittaa koodia tällä Cloud & IT Cert Prep-oppitunnilla?
Kyllä. Jokainen Cloud & IT Cert Prep-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.
Kaikki tämän kurssin oppitunnit
- Korkea käytettävyys ja vikasietoisuus: määritelmät ja kompromissit
- Monen AZ:n mallit tilallisille palveluille
- Monen Regionin active-active ja active-passive
- Kuntotarkistukset, circuit breakerit ja uudelleenyrityslogiikka