Bemærk. overs.: i begyndelsen af august talte Red Hat offentligt om løsning af tilgængelighedsproblemer, som brugere af deres tjeneste var stødt på i de foregående måneder (det er baseret på et register til containerbilleder, som virksomheden modtog sammen med købet af CoreOS). Uanset din interesse for denne service som sådan, er den vej, som virksomhedens SRE-ingeniører gik for at diagnosticere og eliminere årsagerne til ulykken, lærerig.
Den 19. maj, tidligt om morgenen (Eastern Daylight Time, EDT), styrtede quay.io-tjenesten ned. Ulykken ramte både quay.io-forbrugere og Open Source-projekter, der brugte quay.io som platform til at bygge og distribuere software. Red Hat værdsætter begges tillid.
Et team af SRE-ingeniører blev straks involveret og forsøgte at stabilisere kajen så hurtigt som muligt. Men mens de gjorde dette, mistede klienter evnen til at skubbe nye billeder, og kun lejlighedsvis var de i stand til at trække eksisterende. Af en eller anden ukendt årsag blev quay.io-databasen blokeret efter at have skaleret tjenesten til fuld kapacitet.
«Hvad har ændret sig?" - det er det første spørgsmål, der normalt stilles i sådanne tilfælde. Vi bemærkede, at kort før problemet begyndte OpenShift Dedicated cluster (som kører quay.io) at opdatere til version 4.3.19. Da quay.io kører på Red Hat OpenShift Dedicated (OSD), var regelmæssige opdateringer rutine og forårsagede aldrig problemer. Desuden har vi i løbet af de foregående seks måneder opgraderet Quay-klynger flere gange uden nogen afbrydelse i servicen.
Mens vi forsøgte at gendanne tjenesten, begyndte andre ingeniører at forberede en ny OSD-klynge med den tidligere version af softwaren, så hvis der skete noget, kunne de implementere alt på den.
Grundårsagsanalyse
Hovedsymptomet på fejlen var en lavine af titusindvis af databaseforbindelser, som gjorde MySQL-instansen reelt ubrugelig. Dette gjorde det vanskeligt at diagnosticere problemet. Vi har sat en grænse for det maksimale antal forbindelser fra klienter for at hjælpe SRE-teamet med at evaluere problemet. Vi bemærkede ikke nogen usædvanlig trafik til databasen: faktisk blev de fleste anmodninger læst, og kun få blev skrevet.
Vi forsøgte også at identificere et mønster i databasetrafikken, der kunne forårsage denne lavine. Vi kunne dog ikke finde nogen mønstre i loggene. Mens vi ventede på, at den nye klynge med OSD 4.3.18 var klar, fortsatte vi med at forsøge at starte quay.io pods. Hver gang klyngen nåede fuld kapacitet, ville databasen fryse. Dette betød, at det var nødvendigt at genstarte RDS-instansen ud over alle quay.io pods.
Om aftenen stabiliserede vi tjenesten i skrivebeskyttet tilstand og deaktiverede så mange ikke-essentielle funktioner som muligt (f.eks. affaldsopsamling af navneområder) for at reducere belastningen på databasen. Frysninger er stoppet men årsagen blev aldrig fundet. Den nye OSD-klynge var klar, og vi migrerede tjenesten, tilsluttede trafik og fortsatte overvågning.
Quay.io arbejdede stabilt på den nye OSD-klynge, så vi gik tilbage til databaselogfilerne, men kunne ikke finde en sammenhæng, der kunne forklare blokeringerne. OpenShift-ingeniører arbejdede sammen med os for at forstå, om ændringer i Red Hat OpenShift 4.3.19 kunne forårsage problemer med Quay. Der blev dog ikke fundet noget, og Det var ikke muligt at reproducere problemet under laboratorieforhold.
Anden fiasko
Den 28. maj, kort før middag EDT, styrtede quay.io ned igen med det samme symptom: databasen blev blokeret. Og igen kastede vi alle vores kræfter ind i efterforskningen. Først og fremmest var det nødvendigt at genoprette tjenesten. Imidlertid denne gang gjorde genstart af RDS og genstart af quay.io pods ingenting: endnu en lavine af forbindelser har overvældet basen. Men hvorfor?
Quay er skrevet i Python, og hver pod fungerer som en enkelt monolitisk beholder. Container runtime kører mange parallelle opgaver samtidigt. Vi bruger biblioteket gevent under gunicorn at behandle web-anmodninger. Når en forespørgsel kommer til Quay (via vores egen API, eller via Dockers API), tildeles den en givet arbejder. Typisk skal denne medarbejder kontakte databasen. Efter den første fejl opdagede vi, at gavt-arbejdere oprettede forbindelse til databasen ved hjælp af standardindstillinger.
I betragtning af det betydelige antal Quay-pods og tusindvis af indkommende anmodninger pr. sekund, kan et stort antal databaseforbindelser teoretisk overvælde MySQL-instansen. Takket være overvågning var det kendt, at Quay i gennemsnit behandler 5 tusinde anmodninger i sekundet. Antallet af forbindelser til databasen var omtrent det samme. 5 tusinde forbindelser var godt inden for vores RDS-instans (hvilket ikke kan siges om titusinder). Af en eller anden grund var der uventede stigninger i antallet af forbindelser, men vi bemærkede ikke nogen sammenhæng med indgående anmodninger.
Denne gang var vi fast besluttet på at finde og eliminere kilden til problemet og ikke begrænse os til en genstart. Til Quay-kodebasen ændringer blev foretaget for at begrænse antallet af forbindelser til databasen for hver arbejder gavt. Dette nummer blev en parameter i konfigurationen: det blev muligt at ændre det på farten uden at bygge et nyt containerbillede. For at finde ud af, hvor mange forbindelser der kunne håndteres realistisk, kørte vi adskillige tests i et iscenesættelsesmiljø, hvor vi satte forskellige værdier for at se, hvordan dette ville påvirke belastningstestscenarier. Som et resultat blev det opdaget, at Quay begynder at smide 502 fejl, når antallet af forbindelser overstiger 10 tusinde.
Vi implementerede straks denne nye version til produktion og begyndte at overvåge databaseforbindelsesplanen. Tidligere var basen låst ned efter cirka 20 minutter. Efter 30 problemfri minutter havde vi håb, og en time senere havde vi tillid. Vi genoprettede trafikken til webstedet og begyndte at analysere efter døden.
Efter at have formået at omgå problemet, der førte til blokering, vi har ikke fundet ud af dets egentlige årsager. Det blev bekræftet, at det ikke er relateret til ændringer i OpenShift 4.3.19, da det samme skete på version 4.3.18, som tidligere fungerede med Quay uden problemer.
Der var tydeligvis noget andet, der lurede i klyngen.
Detaljeret undersøgelse
Quay.io brugte standardindstillingerne til at oprette forbindelse til databasen i seks år uden problemer. Hvad ændrede sig? Det er tydeligt, at trafikken på quay.io hele tiden er vokset støt. I vores tilfælde så det ud, som om der var nået en eller anden tærskelværdi, som fungerede som en udløser for en lavine af forbindelser. Vi fortsatte med at studere databaselogfilerne efter den anden fejl, men fandt ingen mønstre eller åbenlyse sammenhænge.
I mellemtiden har SRE-teamet arbejdet på forbedringer af Quays anmodningsobservabilitet og overordnede servicesundhed. Nye metrics og dashboards er blevet implementeret, der viser hvilke dele af Kajen, der er mest efterspurgt fra kunderne.
Quay.io fungerede fint indtil 9. juni. Her til morgen (EDT) så vi igen en markant stigning i antallet af databaseforbindelser. Denne gang var der ingen nedetid, da den nye parameter begrænsede deres antal og ikke tillod dem at overskride MySQL-gennemløbet. Men i omkring en halv time bemærkede mange brugere langsom ydeevne af quay.io. Vi indsamlede hurtigt alle mulige data ved hjælp af de tilføjede overvågningsværktøjer. Pludselig dukkede et mønster op.
Lige før stigningen i forbindelser blev der sendt et stort antal anmodninger til App Registry API. App Registry er en lidet kendt funktion af quay.io. Det giver dig mulighed for at gemme ting som Helm-diagrammer og containere med rige metadata. De fleste quay.io-brugere arbejder ikke med denne funktion, men Red Hat OpenShift bruger den aktivt. OperatorHub som en del af OpenShift gemmer alle operatører i App Registry. Disse operatører danner grundlaget for OpenShifts arbejdsbelastningsøkosystem og partnercentrerede driftsmodel (dag 2 operationer).
Hver OpenShift 4-klynge bruger operatører fra den indbyggede OperatorHub til at udgive et katalog over operatører, der er tilgængelige for installation, og levere opdateringer til dem, der allerede er installeret. Med den voksende popularitet af OpenShift 4 er antallet af klynger på den rundt om i verden også steget. Hver af disse klynger downloader operatørindhold for at køre den indbyggede OperatorHub ved at bruge App Registry inde i quay.io som backend. I vores søgen efter kilden til problemet savnede vi det faktum, at efterhånden som OpenShift gradvist voksede i popularitet, steg belastningen på en af de sjældent brugte quay.io-funktioner også..
Vi foretog nogle analyser af App Registry-anmodningstrafik og tog et kig på registreringsdatabasen. Umiddelbart blev der afsløret mangler, hvorfor forespørgsler til databasen ikke blev dannet optimalt. Når belastningen var lav, voldte de ingen problemer, men når belastningen steg, blev de en kilde til problemer. App Registry viste sig at have to problematiske endepunkter, der ikke reagerede godt på stigende belastning: det første gav en liste over alle pakker i depotet, det andet returnerede alle blobs for pakken.
Eliminering af årsager
I løbet af den næste uge brugte vi på at optimere koden til selve appregistret og dets miljø. Klart ineffektive SQL-forespørgsler blev omarbejdet, og unødvendige kommandokald blev elimineret tar (den blev kørt hver gang der blev hentet blobs), blev caching tilføjet hvor det var muligt. Vi gennemførte derefter omfattende præstationstest og sammenlignede hastigheden af App Registry før og efter ændringerne.
API-anmodninger, der tidligere tog op til et halvt minut, afsluttes nu på millisekunder. Den næste uge implementerede vi ændringerne i produktionen, og siden da har quay.io fungeret stabilt. I løbet af denne tid var der adskillige skarpe stigninger i trafikken på App Registry-slutpunktet, men de foretagne forbedringer forhindrede databaseudfald.
Hvad har vi lært?
Det er klart, at enhver service forsøger at undgå nedetid. I vores tilfælde mener vi, at de seneste udfald har været med til at gøre quay.io bedre. Vi har lært et par vigtige lektioner, som vi gerne vil dele:
- Data om, hvem der bruger din tjeneste og hvordan, er aldrig overflødig. Fordi Quay "bare fungerede", behøvede vi aldrig at bruge tid på at optimere trafik og administrere belastning. Alt dette skabte en falsk følelse af sikkerhed, som tjenesten kunne skalere i det uendelige.
- Når tjenesten går ned, at få det op at køre igen er en topprioritet.. Fordi Quay fortsatte med at lide af en låst database under det første udfald, havde vores standardprocedurer ikke den tilsigtede effekt, og vi var ikke i stand til at gendanne tjenesten ved hjælp af dem. Det førte til en situation, hvor der skulle bruges tid på at analysere og indsamle data i håbet om at finde årsagen – i stedet for at fokusere alle kræfter på at genoprette funktionaliteten.
- Evaluer virkningen af hver tjenestefunktion. Kunder brugte sjældent App Registry, så det var ikke en prioritet for vores team. Når nogle produktfunktioner næsten ikke bruges, opstår deres fejl sjældent, og udviklere holder op med at overvåge koden. Det er let at blive ofre for den misforståelse, at det er sådan, det burde være - indtil den funktion pludselig befinder sig i centrum af en større hændelse.
Hvad er det næste?
Arbejdet med at sikre stabiliteten i tjenesten stopper aldrig, og vi forbedrer den konstant. Da trafikmængderne fortsætter med at vokse på quay.io, erkender vi, at vi har et ansvar for at gøre alt, hvad vi kan for at leve op til vores kunders tillid. Derfor arbejder vi i øjeblikket med følgende opgaver:
- Implementer skrivebeskyttede databasereplikaer for at hjælpe tjenesten med at håndtere passende trafik i tilfælde af problemer med den primære RDS-instans.
- Opdatering af en RDS-instans. Den nuværende version i sig selv er ikke problemet. I stedet ønsker vi blot at fjerne det falske spor (som vi fulgte under fiaskoen); At holde softwaren opdateret vil eliminere en anden faktor i tilfælde af fremtidige udfald.
- Yderligere caching på tværs af hele klyngen. Vi fortsætter med at lede efter områder, hvor caching kan reducere belastningen på databasen.
- Tilføjelse af en webapplikationsfirewall (WAF) for at se, hvem der opretter forbindelse til quay.io og hvorfor.
- Fra den næste udgivelse vil Red Hat OpenShift-klynger opgive App Registry til fordel for operatørkataloger baseret på containerbilleder tilgængelige på quay.io.
- En langsigtet erstatning for App Registry kunne være support til Open Container Initiative (OCI) artefaktspecifikationer. Den er i øjeblikket implementeret som native Quay-funktionalitet og vil være tilgængelig for brugerne, når selve specifikationen er færdiggjort.
Alt ovenstående er en del af Red Hats løbende investering i quay.io, da vi bevæger os fra et lille "startup-stil" team til en moden SRE-drevet platform. Vi ved, at mange af vores kunder er afhængige af quay.io i deres daglige arbejde (inklusive Red Hat!), og vi forsøger at være så gennemsigtige som muligt omkring de seneste afbrydelser og igangværende bestræbelser på at forbedre.
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «'.
Kilde: www.habr.com