Bilješka. transl.: početkom avgusta Red Hat je javno progovorio o rješavanju problema pristupačnosti s kojima su se korisnici njegovog servisa susretali prethodnih mjeseci (zasnovan je na registru za slike kontejnera, koji je kompanija dobila uz kupovinu CoreOS-a). Bez obzira na vaše interesovanje za ovu uslugu kao takvu, put kojim su SRE inženjeri kompanije krenuli da dijagnostikuju i otklone uzroke nesreće je poučan.
Dana 19. maja, rano ujutro (Eastern Daylight Time, EDT), servis quay.io je pao. Nesreća je uticala i na quay.io potrošače i na projekte otvorenog koda koji koriste quay.io kao platformu za izgradnju i distribuciju softvera. Red Hat cijeni povjerenje i jednog i drugog.
Tim inženjera SRE-a se odmah uključio i pokušao što prije stabilizirati Quay servis. Međutim, dok su to radili, klijenti su izgubili mogućnost guranja novih slika, a tek povremeno su mogli povući postojeće. Iz nekog nepoznatog razloga, baza podataka quay.io je blokirana nakon skaliranja usluge do punog kapaciteta.
«Šta se promenilo?“ – ovo je prvo pitanje koje se obično postavlja u ovakvim slučajevima. Primijetili smo da je neposredno prije problema, OpenShift Dedicated klaster (koji pokreće quay.io) počeo da se ažurira na verziju 4.3.19. Pošto quay.io radi na Red Hat OpenShift Dedicated (OSD), redovna ažuriranja su bila rutinska i nikada nisu izazivala probleme. Štaviše, u prethodnih šest mjeseci, nekoliko puta smo nadogradili Quay klastere bez ikakvih prekida u radu.
Dok smo pokušavali da restauriramo servis, drugi inženjeri su počeli da pripremaju novi OSD klaster sa prethodnom verzijom softvera, kako bi, ako se nešto desi, mogli sve da rasporede na njemu.
Analiza korijenskog uzroka
Glavni simptom kvara bila je lavina desetina hiljada veza sa bazom podataka, što je MySQL instancu učinilo neoperativnom. To je otežalo dijagnosticiranje problema. Postavili smo ograničenje na maksimalan broj konekcija klijenata kako bismo pomogli SRE timu da procijeni problem. Nismo primijetili nikakav neobičan promet u bazi podataka: zapravo, većina zahtjeva je pročitana, a samo nekoliko napisano.
Također smo pokušali identificirati obrazac u prometu baze podataka koji bi mogao uzrokovati ovu lavinu. Međutim, nismo mogli pronaći nikakve obrasce u zapisnicima. Dok smo čekali da novi klaster sa OSD 4.3.18 bude spreman, nastavili smo sa pokušajima da pokrenemo quay.io podove. Svaki put kada bi klaster dostigao puni kapacitet, baza podataka bi se zamrznula. To je značilo da je bilo potrebno ponovo pokrenuti RDS instancu pored svih quay.io podova.
Do večeri smo stabilizirali uslugu u režimu samo za čitanje i onemogućili što je moguće više nebitnih funkcija (na primjer, sakupljanje smeća prostora imena) kako bismo smanjili opterećenje baze podataka. Zamrzavanja su prestala ali razlog nikada nije pronađen. Novi OSD klaster je bio spreman, a mi smo migrirali uslugu, povezali saobraćaj i nastavili praćenje.
Quay.io je radio stabilno na novom OSD klasteru, pa smo se vratili na logove baze podataka, ali nismo mogli pronaći korelaciju koja bi objasnila blokade. OpenShift inženjeri su radili s nama kako bi shvatili da li promjene u Red Hat OpenShift 4.3.19 mogu uzrokovati probleme s Quayem. Međutim, ništa nije pronađeno, i Nije bilo moguće reproducirati problem u laboratorijskim uvjetima.
Drugi neuspjeh
28. maja, nešto prije podne EDT, quay.io se ponovo srušio sa istim simptomom: baza podataka je bila blokirana. I opet smo sve napore uložili u istragu. Prije svega, bilo je potrebno vratiti uslugu. kako god ovog puta ponovno pokretanje RDS-a i ponovno pokretanje quay.io podova nisu učinili ništa: još jedna lavina veza zatrpala bazu. Ali zašto?
Quay je napisan u Pythonu i svaki pod radi kao jedan monolitni kontejner. Vrijeme izvođenja kontejnera istovremeno izvodi mnoge paralelne zadatke. Koristimo biblioteku gevent ispod gunicorn za obradu web zahtjeva. Kada zahtjev dođe u Quay (preko našeg vlastitog API-ja, ili preko Dockerovog API-ja), dodjeljuje mu se gevent radnik. Obično ovaj radnik treba da kontaktira bazu podataka. Nakon prvog kvara, otkrili smo da se gevent radnici povezuju na bazu podataka koristeći zadane postavke.
S obzirom na značajan broj Quay podova i hiljade dolaznih zahtjeva u sekundi, veliki broj konekcija baze podataka bi teoretski mogao preplaviti MySQL instancu. Zahvaljujući monitoringu, poznato je da Quay obrađuje u prosjeku 5 hiljada zahtjeva u sekundi. Broj konekcija na bazu podataka bio je približno isti. 5 hiljada veza je bilo u granicama mogućnosti naše RDS instance (što se ne može reći za desetine hiljada). Iz nekog razloga došlo je do neočekivanih skokova u broju priključaka, međutim, nismo uočili nikakvu korelaciju sa pristiglim zahtjevima.
Ovaj put smo bili odlučni da pronađemo i eliminišemo izvor problema, a ne da se ograničimo na ponovno pokretanje. U bazu koda Quay napravljene su promjene kako bi se ograničio broj konekcija na bazu podataka za svakog radnika gevent. Ovaj broj je postao parametar u konfiguraciji: postalo je moguće promijeniti ga u hodu bez izgradnje novog imidža kontejnera. Da bismo saznali s koliko veza se realno može rukovati, izveli smo nekoliko testova u scenskom okruženju, postavljajući različite vrijednosti da vidimo kako će to utjecati na scenarije testiranja opterećenja. Kao rezultat toga, otkriveno je da Quay počinje da pušta 502 greške kada broj konekcija pređe 10 hiljada.
Odmah smo implementirali ovu novu verziju u proizvodnju i počeli pratiti raspored povezivanja baze podataka. U prošlosti je baza bila zaključana nakon 20-ak minuta. Nakon 30 minuta bez problema imali smo nadu, a sat kasnije samopouzdanje. Vratili smo promet na stranicu i počeli postmortem analizu.
Nakon što je uspio zaobići problem koji je doveo do blokiranja, nismo saznali njegove prave razloge. Potvrđeno je da to nije povezano sa bilo kakvim promjenama u OpenShift 4.3.19, jer se isto dogodilo i na verziji 4.3.18, koja je ranije radila sa Quayem bez ikakvih problema.
Očigledno je nešto drugo vrebalo u grozdu.
Detaljna studija
Quay.io je koristio zadane postavke za povezivanje na bazu podataka šest godina bez ikakvih problema. Šta se promijenilo? Jasno je da je sve ovo vrijeme promet na quay.io stabilno rastao. U našem slučaju, izgledalo je kao da je dostignuta neka granična vrijednost koja je poslužila kao okidač za lavinu veza. Nastavili smo proučavati dnevnike baze podataka nakon drugog kvara, ali nismo pronašli nikakve obrasce ili očigledne odnose.
U međuvremenu, SRE tim je radio na poboljšanju uočljivosti zahteva Quaya i opšteg zdravlja usluge. Uvedene su nove metrike i kontrolne table, koji pokazuje koji dijelovi Keja su najtraženiji od strane kupaca.
Quay.io je dobro radio do 9. juna. Jutros (EDT) ponovo smo vidjeli značajno povećanje broja veza sa bazom podataka. Ovaj put nije bilo zastoja, budući da je novi parametar ograničio njihov broj i nije im dozvolio da premaše MySQL propusnost. Međutim, oko pola sata, mnogi korisnici su primijetili spore performanse quay.io. Brzo smo prikupili sve moguće podatke koristeći dodane alate za praćenje. Odjednom se pojavio obrazac.
Neposredno prije porasta broja veza, veliki broj zahtjeva upućen je API-ju registra aplikacija. App Registry je malo poznata karakteristika quay.io. Omogućava vam pohranjivanje stvari kao što su Helm karte i kontejneri s bogatim metapodacima. Većina korisnika quay.io ne radi s ovom funkcijom, ali Red Hat OpenShift je aktivno koristi. OperatorHub kao dio OpenShift-a pohranjuje sve operatere u App Registry. Ovi operateri čine osnovu za OpenShift ekosistem radnog opterećenja i operativni model usmjeren na partnere (operacije 2. dana).
Svaki OpenShift 4 klaster koristi operatore iz ugrađenog OperatorHub-a za objavljivanje kataloga operatora dostupnih za instalaciju i pružanje ažuriranja za one koji su već instalirani. Sa rastućom popularnošću OpenShift 4, povećao se i broj klastera na njemu širom svijeta. Svaki od ovih klastera preuzima sadržaj operatera za pokretanje ugrađenog OperatorHub-a, koristeći App Registry unutar quay.io kao pozadinu. U našoj potrazi za izvorom problema, propustili smo činjenicu da kako je OpenShift postupno rastao u popularnosti, raste i opterećenje jedne od rijetko korištenih funkcija quay.io..
Uradili smo analizu prometa zahtjeva App Registry i pogledali šifru registra. Odmah su uočeni nedostaci zbog kojih upiti prema bazi podataka nisu optimalno formirani. Kada je opterećenje bilo malo, nisu stvarale probleme, ali kada se opterećenje povećalo, postale su izvor problema. Ispostavilo se da App Registry ima dvije problematične krajnje tačke koje nisu dobro reagovale na povećanje opterećenja: prva je dala listu svih paketa u spremištu, druga je vratila sve blobove za paket.
Otklanjanje uzroka
Sljedeću sedmicu smo proveli optimizirajući kod samog App Registry-a i njegovog okruženja. Jasno neefikasni SQL upiti su prerađeni i nepotrebni pozivi komandi su eliminisani tar (pokrenuto je svaki put kada su blobovi preuzeti), keširanje je dodano gdje god je to moguće. Zatim smo sproveli opsežno testiranje performansi i uporedili brzinu registra aplikacija prije i nakon promjena.
API zahtjevi koji su ranije trajali do pola minute sada se dovršavaju u milisekundama. Sljedeće sedmice smo implementirali promjene u proizvodnju i od tada quay.io radi stabilno. Tokom tog vremena, bilo je nekoliko oštrih skokova u prometu na krajnjoj tački registra aplikacija, ali poboljšanja su spriječila prekide u bazi podataka.
Šta smo naučili?
Jasno je da svaka usluga pokušava izbjeći zastoje. U našem slučaju, vjerujemo da su nedavni prekidi pomogli da quay.io bude bolji. Naučili smo nekoliko ključnih lekcija koje bismo željeli podijeliti:
- Podaci o tome ko i kako koristi vašu uslugu nikada nisu suvišni. Budući da je Quay „samo radio“, nikada nismo morali trošiti vrijeme na optimizaciju saobraćaja i upravljanje opterećenjem. Sve je to stvorilo lažni osjećaj sigurnosti da se usluga može neograničeno povećavati.
- Kada usluga padne, njegovo ponovno pokretanje i rad je glavni prioritet.. Pošto je Quay nastavio da pati od zaključane baze podataka tokom prvog prekida, naše standardne procedure nisu imale željeni efekat i nismo bili u mogućnosti da vratimo uslugu koristeći ih. To je dovelo do situacije u kojoj je vrijeme trebalo potrošiti na analizu i prikupljanje podataka u nadi da će se pronaći osnovni uzrok - umjesto da se svi napori usmjere na vraćanje funkcionalnosti.
- Procijenite uticaj svake funkcije usluge. Klijenti su rijetko koristili App Registry, tako da to nije bio prioritet za naš tim. Kada se neke karakteristike proizvoda jedva koriste, njihove greške se rijetko pojavljuju, a programeri prestaju pratiti kod. Lako je postati žrtvom zablude da je to onako kako bi trebalo biti - sve dok se odjednom ta funkcija ne nađe u središtu velikog incidenta.
Što je sljedeće?
Rad na osiguravanju stabilnosti usluge nikada ne prestaje i stalno ga poboljšavamo. Kako obim saobraćaja nastavlja da raste na quay.io, shvatamo da imamo odgovornost da učinimo sve što je u našoj moći da opravdamo poverenje naših klijenata. Stoga trenutno radimo na sljedećim zadacima:
- Postavite replike baze podataka samo za čitanje kako biste pomogli usluzi da upravlja odgovarajućim prometom u slučaju problema s primarnom RDS instancom.
- Ažuriranje RDS instance. Trenutna verzija sama po sebi nije problem. Umjesto toga, jednostavno želimo ukloniti lažni trag (koji smo slijedili tokom neuspjeha); Održavanje softvera ažurnim će eliminisati još jedan faktor u slučaju budućih prekida rada.
- Dodatno keširanje u cijelom klasteru. Nastavljamo da tražimo područja u kojima keširanje može smanjiti opterećenje baze podataka.
- Dodavanje zaštitnog zida za web aplikacije (WAF) da vidite ko se povezuje na quay.io i zašto.
- Počevši od sljedećeg izdanja, Red Hat OpenShift klasteri će napustiti App Registry u korist Kataloga operatera na osnovu slika kontejnera dostupnih na quay.io.
- Dugoročna zamjena za App Registry mogla bi biti podrška za specifikacije artefakata Open Container Initiative (OCI). Trenutno je implementirana kao izvorna Quay funkcionalnost i bit će dostupna korisnicima kada se sama specifikacija finalizira.
Sve gore navedeno je dio Red Hat-ovog tekućeg ulaganja u quay.io dok se krećemo od malog tima u "startup stilu" na zrelu platformu vođenu SRE. Znamo da se mnogi naši klijenti oslanjaju na quay.io u svom svakodnevnom radu (uključujući Red Hat!) i trudimo se da budemo što je moguće transparentniji u vezi s nedavnim prekidima rada i tekućim naporima da se poboljšamo.
PS od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «".
izvor: www.habr.com