Kuntotarkistukset ja hallittu heikentyminen
Määritä kuormantasaajan ja Traffic Managerin kuntotarkistukset havaitsemaan häiriöt nopeasti ja suunnittele sovelluskerrokselle sulake- ja hallitun heikentymisen mallit
Kuntotarkistukset ja hallittu heikentyminen 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 kuntotarkistukset ovat välttämättömiä
Kuntotarkistukset ovat mekanismi, jolla kuormantasaajat ja liikenteenhallintapalvelut havaitsevat, pystyykö taustalla oleva instanssi käsittelemään pyyntöjä. Ilman kuntotarkistuksia kuormantasaaja saattaisi jatkaa liikenteen lähettämistä vikaantuneelle tai vastaamattomalle palvelimelle, mikä aiheuttaisi käyttäjille näkyviä virheitä. Oikein määritetyt kuntotarkistukset mahdollistavat liikenteen automaattisen uudelleenreitityksen pois toimimattomilta instansseilta muutaman sekunnin kuluessa vian ilmenemisestä.
Azure Load Balancerin kuntotarkistukset
Azure Load Balancer tukee kahdenlaisia kuntotarkistuksia:
- TCP-tarkistus — tarkistaa, voiko taustapalvelu hyväksyä TCP-yhteyden määritetyssä portissa. Yksinkertainen, mutta ei tarkista sovelluslogiikkaa.
- HTTP/HTTPS-tarkistus — lähettää GET-pyynnön määritettyyn polkuun ja odottaa 200 OK -vastausta. Tarkempi, koska se testaa sovelluksen päätepistettä suoraan.
Taustapalvelu merkitään toimimattomaksi, jos tarkistus epäonnistuu määritettävissä olevan peräkkäisten yritysten määrässä.
# Create an HTTP health probe for an Azure Load Balancer:
az network lb probe create \
--resource-group myRG \
--lb-name myLoadBalancer \
--name httpHealthProbe \
--protocol Http \
--port 80 \
--path /health \
--interval 15 \
--threshold 2Luotettavan kuntopäätepisteen suunnittelu
Hyvin suunniteltu kuntopäätepiste (/health) tekee muutakin kuin palauttaa vastauksen 200 OK – se varmistaa, että sovelluksen kriittiset riippuvuudet ovat tavoitettavissa. Kattava kuntotarkistus voi testata yhteyden tietokantaan, välimuistiin ja mahdollisiin myöhempiin ohjelmointirajapintoihin. Jos jokin riippuvuus ei ole käytettävissä, päätepiste palauttaa 5xx-tilakoodin, joka ilmoittaa kuormantasaajalle, että tämä instanssi on poistettava käytöstä.
# Example health endpoint response (JSON):
# GET /health
# {
# 'status': 'healthy',
# 'checks': {
# 'database': 'ok',
# 'cache': 'ok',
# 'externalApi': 'ok'
# }
# }
# If database check fails, return HTTP 503 instead of 200Traffic Managerin kuntotarkistukset
Azure Traffic Manager käyttää myös kuntotarkistuksia, mutta alueellisella tasolla. Se lähettää säännöllisesti HTTP- tai HTTPS GET -pyyntöjä kunkin alueen määritettyyn päätepisteen URL-osoitteeseen. Jos päätepiste ei vastaa aikakatkaisuikkunan aikana määritettynä peräkkäisten aikavälien määränä, Traffic Manager merkitsee päätepisteen heikentyneeksi ja lopettaa DNS-kyselyiden reitittämisen siihen ohjaten käyttäjät toimivalle alueelle.
# Configure Traffic Manager health probe settings:
az network traffic-manager profile update \
--resource-group myRG \
--name myTMProfile \
--monitor-protocol HTTPS \
--monitor-port 443 \
--monitor-path /health \
--monitor-interval 30 \
--monitor-timeout 10 \
--monitor-tolerated-failures 3Application Gatewayn kuntotarkistukset
Azure Application Gateway tarjoaa kehittyneemmät kuntotarkistusominaisuudet kuin tavallinen Load Balancer. Se tukee mukautettuja kuntotarkistuksia, joissa määritetään isäntäotsake, odotettu tilakoodialue (esimerkiksi 200–399) ja vastaava merkkijono vastausosan sisällöstä. Application Gateway tukee myös polkukohtaista reititystä, joten eri taustapalveluryhmillä voi olla eri kuntotarkistusasetukset eri URL-poluille.
# Create a custom probe for Application Gateway:
az network application-gateway probe create \
--gateway-name myAppGateway \
--resource-group myRG \
--name customProbe \
--protocol Http \
--host-name-from-http-settings true \
--path /api/health \
--interval 20 \
--timeout 10 \
--threshold 3Mitä hallittu heikentäminen tarkoittaa?
Hallittu heikentäminen tarkoittaa sovelluksen kykyä tarjota osittaista toiminnallisuutta edelleen, kun yksi tai useampi sen riippuvuuksista lakkaa toimimasta. Sen sijaan, että sovellus kaatuisi kokonaan, se havaitsee ei-kriittisen palvelun käytöstä poistumisen ja siirtyy heikentyneeseen mutta yhä hyödylliseen tilaan. Jos esimerkiksi suosituspalvelu lakkaa toimimasta, verkkokauppa voi näyttää yleisiä ehdotuksia sen sijaan, että koko tuotesivu kaatuisi.
Circuit Breaker -malli
Circuit breaker -malli estää sovellusta kutsumasta toistuvasti vikaantuvaa downstream-palvelua. Kun palvelu alkaa vikaantua, circuit breaker avautuu ja palauttaa välittömästi virheen tai varavastauksen suorittamatta verkkokutsua. Jäähdytysajan jälkeen se siirtyy puoliavoimeen tilaan ja sallii kokeilupyynnön. Jos pyyntö onnistuu, piiri sulkeutuu ja normaali toiminta jatkuu.
# Circuit breaker states:
# CLOSED: normal operation, calls pass through
# OPEN: service failing, calls immediately return error/fallback
# HALF-OPEN: cool-down expired, try one request:
# success -> CLOSED
# failure -> OPEN (reset timer)
# Libraries: Polly (.NET), Resilience4j (Java), polly-js (JS)Uudelleenyritys eksponentiaalisella viiveellä
Tilapäisiin häiriöihin (lyhytaikaiset verkkohäiriöt, palvelun tilapäinen ylikuormitus) sopii strategia, jossa käytetään uudelleenyritystä eksponentiaalisesti kasvavalla viiveellä. Sovellus yrittää epäonnistunutta kutsua uudelleen viiveen jälkeen ja kaksinkertaistaa viiveen jokaisella yrityskerralla tiettyyn enimmäisarvoon asti. Jitterin (satunnaisen vaihtelun) lisääminen viiveeseen estää kaikkien uudelleenyritysten synkronoitumisen ja palautuvan palvelun ylikuormittumisen.
# Exponential backoff with jitter (pseudocode):
# attempt 1: wait 1s + random(0-500ms)
# attempt 2: wait 2s + random(0-500ms)
# attempt 3: wait 4s + random(0-500ms)
# attempt 4: wait 8s + random(0-500ms)
# max retries: 4
# max wait: 30s (cap)
# After max retries: return error to callerBulkhead-malli
Bulkhead-malli eristää sovelluksen eri osat omiin resurssivarantoihinsa, jotta yhden alueen vika ei kuluta kaikkia resursseja eikä kaada koko järjestelmää. Nimi viittaa laivojen laipioihin, jotka estävät yhden tulvivan osaston upottamasta koko alusta. Azuressa tämä voi tarkoittaa erillisten säievarantojen tai eri palveluille tarkoitettujen erillisten App Service plans -kokoonpanojen käyttämistä vikojen rajaamiseksi.
Varavastaukset ja välimuistissa olevat tiedot
Yleinen hallitun heikentymisen tekniikka on tarjota välimuistissa olevia tai vanhentuneita tietoja, kun reaaliaikainen tietolähde ei ole käytettävissä. Esimerkiksi tuoteluettelosivu voi näyttää Azure Cache for Redis -palveluun tallennetut eiliset hinnat virheen sijaan, jos tietokantaan ei tilapäisesti saada yhteyttä. Käyttäjälle aiheutuu pieni haitta (hieman vanhentuneet hinnat) täydellisen toimintahäiriön sijaan.
Heikentyneen toiminnan valvonta ja hälytykset
Hallitun heikentymisen tulee olla näkyvää ja mitattavaa. Seuratkaa Application Insightsin avulla circuit breakerien avautumisten, varavastausten ja uudelleenyritysten määrää mukautettuina mittareina. Määrittäkää hälytykset, jotka aktivoituvat mittareiden ylittäessä kynnysarvot, jotta päivystystiimi saa ilmoituksen sovelluksen toimimisesta heikentyneessä tilassa, vaikka käyttäjälle näkyvä käyttökokemus vaikuttaisi hyväksyttävältä.
Pikatarkistus
Testatkaa, miten hyvin ymmärrätte tämän oppitunnin Microsoft Azure Fundamentals (AZ-900) -käsitteet.
Oppitunnin yhteenveto
Tässä oppitunnissa opitte, että health probes mahdollistavat kuormantasaajien havaita vikaantuneet taustapalvelut ja ohjata liikenteen automaattisesti uudelleen; hallittu heikentyminen pitää sovellukset osittain toimivina riippuvuuksien vikaantuessa; ja circuit breaker-, uudelleenyritys viiveellä - ja bulkhead-mallit toteuttavat vikasietoisuuden sovellustasolla. Seuraavaksi tutustumme katastrofipalautumisen käsitteisiin: RTO:hon, RPO:hon ja palautustasoihin.
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 ja hallittu heikentyminen” ilmainen?
Kyllä – oppitunnin ”Kuntotarkistukset ja hallittu heikentyminen” 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 ja hallittu heikentyminen”?
Määritä kuormantasaajan ja Traffic Managerin kuntotarkistukset havaitsemaan häiriöt nopeasti ja suunnittele sovelluskerrokselle sulake- ja hallitun heikentymisen mallit 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 ja hallittu heikentyminen”-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
- Azuren SLA:t ja yhdistetyt SLA:t
- Saatavuusjoukot ja saatavuusvyöhykkeet
- Monialueinen aktiivinen–aktiivinen-arkkitehtuuri
- Kuntotarkistukset ja hallittu heikentyminen