Merk. overs.: tidlig i august snakket Red Hat offentlig om å løse tilgjengelighetsproblemer som brukere av tjenesten deres hadde møtt i tidligere måneder (det er basert på et register for containerbilder, som selskapet mottok sammen med kjøpet av CoreOS). Uavhengig av din interesse for denne tjenesten som sådan, er veien som selskapets SRE-ingeniører tok for å diagnostisere og eliminere årsakene til ulykken lærerikt.
19. mai, tidlig om morgenen (Eastern Daylight Time, EDT), krasjet tjenesten quay.io. Ulykken rammet både quay.io-forbrukere og Open Source-prosjekter som brukte quay.io som plattform for å bygge og distribuere programvare. Red Hat verdsetter tilliten til begge.
Et team med SRE-ingeniører ble umiddelbart involvert og prøvde å stabilisere Quay-tjenesten så snart som mulig. Men mens de gjorde dette, mistet klienter muligheten til å presse nye bilder, og bare noen ganger var de i stand til å trekke eksisterende. Av en eller annen ukjent grunn ble quay.io-databasen blokkert etter å ha skalert tjenesten til full kapasitet.
«Hva har endret seg?" - dette er det første spørsmålet som vanligvis stilles i slike saker. Vi la merke til at kort tid før problemet begynte OpenShift Dedicated-klyngen (som kjører quay.io) å oppdatere til versjon 4.3.19. Siden quay.io kjører på Red Hat OpenShift Dedicated (OSD), var regelmessige oppdateringer rutine og forårsaket aldri problemer. I løpet av de siste seks månedene har vi dessuten oppgradert Quay-klynger flere ganger uten avbrudd i tjenesten.
Mens vi prøvde å gjenopprette tjenesten, begynte andre ingeniører å forberede en ny OSD-klynge med den forrige versjonen av programvaren, slik at hvis noe skjedde, kunne de distribuere alt på den.
Årsaksanalyse
Hovedsymptomet på feilen var et snøskred av titusenvis av databaseforbindelser, som gjorde MySQL-forekomsten i praksis ubrukelig. Dette gjorde det vanskelig å diagnostisere problemet. Vi har satt en grense for maksimalt antall tilkoblinger fra klienter for å hjelpe SRE-teamet med å evaluere problemet. Vi la ikke merke til noen uvanlig trafikk til databasen: faktisk ble de fleste forespørsler lest, og bare noen få ble skrevet.
Vi prøvde også å identifisere et mønster i databasetrafikken som kunne forårsake dette skredet. Vi kunne imidlertid ikke finne noen mønstre i loggene. Mens vi ventet på at den nye klyngen med OSD 4.3.18 skulle være klar, fortsatte vi å prøve å lansere quay.io pods. Hver gang klyngen nådde full kapasitet, ville databasen fryse. Dette betydde at det var nødvendig å starte RDS-forekomsten på nytt i tillegg til alle quay.io pods.
Om kvelden stabiliserte vi tjenesten i skrivebeskyttet modus og deaktiverte så mange ikke-essensielle funksjoner som mulig (for eksempel søppelinnsamling av navneområder) for å redusere belastningen på databasen. Frysene har stoppet men årsaken ble aldri funnet. Den nye OSD-klyngen var klar, og vi migrerte tjenesten, koblet trafikk og fortsatte overvåking.
Quay.io fungerte stabilt på den nye OSD-klyngen, så vi gikk tilbake til databaseloggene, men kunne ikke finne en korrelasjon som kunne forklare blokkeringene. OpenShift-ingeniører samarbeidet med oss for å forstå om endringer i Red Hat OpenShift 4.3.19 kan forårsake problemer med Quay. Det ble imidlertid ikke funnet noe, og Det var ikke mulig å reprodusere problemet under laboratorieforhold.
Andre fiasko
28. mai, like før middag EDT, krasjet quay.io igjen med det samme symptomet: databasen ble blokkert. Og igjen kastet vi all vår innsats inn i etterforskningen. Først av alt var det nødvendig å gjenopprette tjenesten. derimot denne gangen gjorde det ingenting å starte RDS på nytt og starte quay.io pods på nytt: nok et snøskred av forbindelser har overveldet basen. Men hvorfor?
Quay er skrevet i Python og hver pod fungerer som en enkelt monolittisk beholder. Beholderens kjøretid kjører mange parallelle oppgaver samtidig. Vi bruker biblioteket gevent etter gunicorn å behandle nettforespørsler. Når en forespørsel kommer til Quay (via vår egen API, eller via Dockers API), blir den tildelt en gitt arbeider. Vanligvis bør denne arbeideren kontakte databasen. Etter den første feilen oppdaget vi at gavt arbeidere koblet til databasen ved hjelp av standardinnstillinger.
Gitt det betydelige antallet Quay-poder og tusenvis av innkommende forespørsler per sekund, kan et stort antall databaseforbindelser teoretisk overvelde MySQL-forekomsten. Takket være overvåking var det kjent at Quay behandler gjennomsnittlig 5 tusen forespørsler per sekund. Antall tilkoblinger til databasen var omtrent det samme. 5 tusen tilkoblinger var godt innenfor mulighetene til RDS-forekomsten vår (som ikke kan sies om titusenvis). Av en eller annen grunn var det uventede topper i antall tilkoblinger, men vi la ikke merke til noen sammenheng med innkommende forespørsler.
Denne gangen var vi fast bestemt på å finne og eliminere kilden til problemet, og ikke begrense oss til en omstart. Til Quay-kodebasen endringer ble gjort for å begrense antall tilkoblinger til databasen for hver arbeider gavt. Dette nummeret ble en parameter i konfigurasjonen: det ble mulig å endre det med en gang uten å bygge et nytt containerbilde. For å finne ut hvor mange tilkoblinger som kunne håndteres realistisk, kjørte vi flere tester i et oppsamlingsmiljø, og satte forskjellige verdier for å se hvordan dette ville påvirke scenarier for lasttesting. Som et resultat ble det oppdaget det Quay begynner å kaste 502 feil når antall tilkoblinger overstiger 10 tusen.
Vi implementerte umiddelbart denne nye versjonen til produksjon og begynte å overvåke databasetilkoblingsplanen. Tidligere ble basen låst etter rundt 20 minutter. Etter 30 problemfrie minutter hadde vi håp, og en time senere hadde vi selvtillit. Vi gjenopprettet trafikken til nettstedet og begynte postmortem-analyse.
Etter å ha klart å omgå problemet som førte til blokkering, vi har ikke funnet ut dens virkelige årsaker. Det ble bekreftet at det ikke er relatert til noen endringer i OpenShift 4.3.19, siden det samme skjedde på versjon 4.3.18, som tidligere fungerte med Quay uten problemer.
Det var tydelig noe annet som lurte i klyngen.
Detaljert studie
Quay.io brukte standardinnstillingene for å koble til databasen i seks år uten problemer. Hva endret seg? Det er tydelig at hele denne tiden har trafikken på quay.io vokst jevnt og trutt. I vårt tilfelle så det ut som om en eller annen terskelverdi var nådd, som fungerte som en utløser for et snøskred. Vi fortsatte å studere databaseloggene etter den andre feilen, men fant ingen mønstre eller åpenbare sammenhenger.
I mellomtiden har SRE-teamet jobbet med forbedringer av Quays forespørselsobservabilitet og generelle tjenestehelse. Nye beregninger og instrumentbord har blitt implementert, som viser hvilke deler av Kaien som er mest etterspurt fra kundene.
Quay.io fungerte fint frem til 9. juni. I morges (EDT) så vi igjen en betydelig økning i antall databaseforbindelser. Denne gangen var det ingen nedetid, siden den nye parameteren begrenset antallet og ikke tillot dem å overskride MySQL-gjennomstrømningen. Men i omtrent en halv time bemerket mange brukere treg ytelse av quay.io. Vi samlet raskt inn alle mulige data ved å bruke de ekstra overvåkingsverktøyene. Plutselig dukket det opp et mønster.
Rett før økningen i forbindelsene ble det sendt et stort antall forespørsler til App Registry API. App Registry er en lite kjent funksjon på quay.io. Den lar deg lagre ting som Helm-diagrammer og beholdere med rike metadata. De fleste quay.io-brukere jobber ikke med denne funksjonen, men Red Hat OpenShift bruker den aktivt. OperatorHub som en del av OpenShift lagrer alle operatører i appregisteret. Disse operatørene danner grunnlaget for OpenShifts arbeidsbelastningsøkosystem og partnersentriske driftsmodell (dag 2-operasjoner).
Hver OpenShift 4-klynge bruker operatører fra den innebygde OperatorHub til å publisere en katalog over operatører tilgjengelig for installasjon og gi oppdateringer til de som allerede er installert. Med den økende populariteten til OpenShift 4, har antallet klynger på den rundt om i verden også økt. Hver av disse klyngene laster ned operatørinnhold for å kjøre den innebygde OperatorHub, ved å bruke App Registry inne i quay.io som backend. I vårt søk etter kilden til problemet savnet vi det faktum at etter hvert som OpenShift gradvis vokste i popularitet, økte også belastningen på en av de sjelden brukte quay.io-funksjonene..
Vi gjorde noen analyser av App Registry-forespørselstrafikken og tok en titt på registerkoden. Umiddelbart ble det avdekket mangler, på grunn av hvilke spørringer til databasen ikke ble dannet optimalt. Når belastningen var lav, skapte de ingen problemer, men når belastningen økte, ble de en kilde til problemer. App Registry viste seg å ha to problematiske endepunkter som ikke reagerte godt på økende belastning: det første ga en liste over alle pakkene i depotet, det andre returnerte alle blobs for pakken.
Eliminering av årsaker
I løpet av den neste uken brukte vi å optimalisere koden til selve appregisteret og dets miljø. Klart ineffektive SQL-spørringer ble omarbeidet og unødvendige kommandoanrop ble eliminert tar (den ble kjørt hver gang blobs ble hentet), caching ble lagt til der det var mulig. Vi gjennomførte deretter omfattende ytelsestesting og sammenlignet hastigheten til appregisteret før og etter endringene.
API-forespørsler som tidligere tok opptil et halvt minutt, fullføres nå på millisekunder. Neste uke implementerte vi endringene i produksjonen, og siden den gang har quay.io jobbet stabilt. I løpet av denne tiden var det flere kraftige topper i trafikken på App Registry-endepunktet, men forbedringene forhindret databasebrudd.
Hva har vi lært?
Det er klart at enhver tjeneste prøver å unngå nedetid. I vårt tilfelle tror vi at de siste driftsstansene har bidratt til å gjøre quay.io bedre. Vi har lært noen viktige leksjoner som vi ønsker å dele:
- Data om hvem som bruker tjenesten din og hvordan er aldri overflødig. Fordi Quay «bare fungerte», måtte vi aldri bruke tid på å optimalisere trafikken og administrere belastningen. Alt dette skapte en falsk trygghet som tjenesten kunne skalere i det uendelige.
- Når tjenesten går ned, å få den opp å gå igjen er en topp prioritet.. Fordi Quay fortsatte å lide av en låst database under det første strømbruddet, hadde ikke standardprosedyrene våre den tiltenkte effekten, og vi klarte ikke å gjenopprette tjenesten ved å bruke dem. Dette førte til en situasjon der det måtte brukes tid på å analysere og samle inn data i håp om å finne rotårsaken – i stedet for å fokusere all innsats på å gjenopprette funksjonalitet.
- Evaluer virkningen av hver tjenestefunksjon. Klienter brukte sjelden App Registry, så det var ikke en prioritet for teamet vårt. Når noen produktfunksjoner knapt brukes, vises feilene deres sjelden, og utviklere slutter å overvåke koden. Det er lett å bli offer for misforståelsen om at det er slik det burde være – helt til plutselig den funksjonen befinner seg i sentrum av en stor hendelse.
Hva blir det neste?
Arbeidet med å sikre stabiliteten i tjenesten stopper aldri, og vi forbedrer den hele tiden. Ettersom trafikkvolumet fortsetter å vokse på quay.io, erkjenner vi at vi har et ansvar for å gjøre alt vi kan for å leve opp til kundenes tillit. Derfor jobber vi nå med følgende oppgaver:
- Distribuer skrivebeskyttede databasereplikaer for å hjelpe tjenesten med å håndtere passende trafikk i tilfelle problemer med den primære RDS-forekomsten.
- Oppdaterer en RDS-forekomst. Den nåværende versjonen i seg selv er ikke problemet. Snarere ønsker vi ganske enkelt å fjerne det falske sporet (som vi fulgte under feilen); Å holde programvaren oppdatert vil eliminere en annen faktor i tilfelle fremtidige strømbrudd.
- Ekstra caching over hele klyngen. Vi fortsetter å lete etter områder hvor caching kan redusere belastningen på databasen.
- Legge til en nettapplikasjonsbrannmur (WAF) for å se hvem som kobler til quay.io og hvorfor.
- Fra og med neste utgivelse vil Red Hat OpenShift-klynger forlate App Registry til fordel for operatørkataloger basert på containerbilder tilgjengelig på quay.io.
- En langsiktig erstatning for App Registry kan være støtte for Open Container Initiative (OCI) artefaktspesifikasjoner. Den er for tiden implementert som innebygd Quay-funksjonalitet og vil være tilgjengelig for brukere når selve spesifikasjonen er ferdigstilt.
Alt det ovennevnte er en del av Red Hats pågående investering i quay.io når vi går fra et lite "startup-style" team til en moden SRE-drevet plattform. Vi vet at mange av våre kunder er avhengige av quay.io i sitt daglige arbeid (inkludert Red Hat!), og vi prøver å være så transparente som mulig om nylige avbrudd og pågående forbedringsarbeid.
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «'.
Kilde: www.habr.com