Napomena za prijevod.: početkom kolovoza Red Hat je javno objavio rješenje za probleme dostupnosti koji su se pojavili tijekom prethodnih mjeseci kod korisnika njihove usluge (temeljen na registru za slike kontejnera, koji je tvrtka dobila s kupnjom CoreOS-a). Neovisno o vašem interesu za ovu uslugu kao takvu, poučan je put koji su prošli SRE inženjeri tvrtke kako bi dijagnosticirali i uklonili uzroke incidenta.
19. svibnja, rano ujutro (prema ljetnom sjevernoameričkom istočnom vremenu, EDT), usluga quay.io je pala. Incident je utjecao na potrošače quay.io, kao i na open source projekte koji koriste quay.io kao platformu za izgradnju i distribuciju softvera. Red Hat cijeni povjerenje i jednih i drugih.
Tim SRE inženjera odmah se uključio u rad i nastojao što prije stabilizirati rad usluge Quay. Međutim, dok su radili na tome, klijenti su izgubili mogućnost slanja novih slika, a samo su povremeno mogli povući postojeće. Iz nepoznatih razloga, baza podataka quay.io je bila blokirana nakon skaliranja usluge na punu snagu.
«Što se promijenilo?— to je prvo pitanje koje se postavlja u sličnim slučajevima. Primijetili smo da je nedugo prije problema klaster OpenShift Dedicated (na kojem radi quay.io) počeo s ažuriranjem na verziju 4.3.19. Budući da quay.io radi na Red Hat OpenShift Dedicated (OSD), redovita ažuriranja su bila uobičajena operacija i nikada nisu uzrokovala probleme. Štoviše, u proteklih šest mjeseci nekoliko smo puta ažurirali klastere Quay bez ikakvih prekida u radu.
Dok smo pokušavali ponovno pokrenuti uslugu, drugi inženjeri su počeli pripremati novi OSD klaster s prethodnom verzijom softvera, kako bi sve u slučaju nužde mogli implementirati na njemu.
Analiza uzroka
Glavni simptom kvara bila je lavina od desetaka tisuća veza na bazu podataka, zbog čega je instanca MySQL-a postala praktički neupotrebljiva. Zbog toga je bilo teško dijagnosticirati problem. Postavili smo ograničenje na maksimalni broj veza od klijenata kako bismo pomogli SRE timu da procijeni problem. Nismo primijetili neuobičajen promet prema bazi podataka: zapravo, većina zahtjeva bila je za čitanje, dok su samo neki bili za pisanje.
Također smo pokušali otkriti uzorak u prometu baze podataka koji bi mogao izazvati ovu lavinu. Međutim, nismo uspjeli pronaći nikakve obrasce u logovima. Dok smo čekali zaključenje novog klastera s OSD 4.3.18, nastavili smo pokušavati pokrenuti podove quay.io. Svaki put kada je klaster postigao punu snagu, baza podataka se zamrzavala. To je značilo da je bilo potrebno ponovo pokrenuti RDS instancu uz sve podove quay.io.
Do večeri smo stabilizirali uslugu u read-only režimu i isključili maksimalni broj nebitnih funkcija (na primjer, sakupljanje smeća u prostoru imena) kako bismo smanjili opterećenje na bazi podataka. Zaleđivanja su prestala, ali uzrok nije pronađen. Novi OSD klaster je bio spreman, i prebacili smo uslugu, povezali promet i nastavili s praćenjem.
Quay.io je stabilno radio na novom OSD klasteru, stoga smo se vratili logovima baze podataka, no nismo uspjeli otkriti korelaciju koja bi objasnila blokade. Inženjeri OpenShifta radili su zajedno s nama, pokušavajući razumjeti mogu li promjene u Red Hat OpenShift 4.3.19 uzrokovati probleme s Quay. Međutim, ništa nije otkriveno, a nije uspjelo reproducirati problem u laboratorijskim uvjetima.
Drugi kvar
28. svibnja, nedugo prije podneva po EDT-u, quay.io se ponovno srušio s istim simptomima: funkcionalnost baze podataka bila je blokirana. I ponovo smo mobilizirali sve snage za istragu. Prvo što je trebalo učiniti bilo je ponovno pokrenuti uslugu. Međutim, ovog puta ponovno pokretanje RDS-a i ponovo pokretanje podova quay.io nisu doveli do ničega: nova lavina konekcija preplavila je bazu. No zašto?Quay je napisan na Pythonu, a svaki pod radi kao jedinstveni monolitni kontejner. U radnom okruženju kontejnera izvršava se mnogo paralelnih zadataka. Koristimo biblioteku
gevent za obradu web zahtjeva. Kada Quay primi zahtjev (putem našeg API-ja ili preko Dockerovog API-ja), dodijeljuje se gevent radnik. Obično taj radnik treba uspostaviti vezu s bazom podataka. Nakon prvog kvara otkrili smo da su se gevent radnici koristili podacima o vezi prema zadanim postavkama. pod gunicorn za obradu web zahtjeva. Kada Quay primi zahtjev (putem našeg API-ja ili preko Dockerovog API-ja), dodijeljuje se gevent radnik. Obično taj radnik treba uspostaviti vezu s bazom podataka. Nakon prvog kvara otkrili smo da su se gevent radnici povezivali s bazom podataka koristeći zadane postavke.
S obzirom na značajan broj podova Quay i tisuće dolaznih zahtjeva u sekundi, veliki broj veza na bazu podataka teoretski je mogao opteretiti MySQL instancu. Zahvaljujući praćenju, bilo je poznato da Quay u prosjeku obrađuje 5 tisuća zahtjeva u sekundi. Otprilike toliko je bilo i veza na bazu podataka. 5 tisuća veza s rezervom stalo je unutar mogućnosti naše RDS instance (što se ne može reći za desetke tisuća). Iz nekog razloga događali su se neočekivani skokovi u broju veza., međutim, nismo primijetili nikakvu korelaciju s dolaznim zahtjevima.
Ovaj put čvrsto smo odlučili pronaći i otkloniti izvor problema, a ne ograničiti se na ponovno pokretanje. U kodnoj bazi Quay nanešene su izmjene koje ograničavaju broj veza na DB za svakog worker-a gevent. Taj broj postao je parametar u konfiguraciji: bilo je moguće mijenjati ga 'u hodu', bez potrebe za ponovno sastavljanjem novog kontejnerskog identiteta. Kako bismo saznali koji broj veza se zapravo može obraditi, provedeni su brojne probe sa staging okruženjem, u kojima su postavljene različite vrijednosti kako bi se vidjelo kako će to utjecati na scenarije testiranja opterećenja. Na kraju je otkriveno da Quay počinje isporučivati greške 502 kada broj veza premaši 10 tisuća.
Odmah smo implementirali ovu novu verziju u produkciji i počeli pratiti grafikon veza na bazu podataka. U prošlosti se baza zaključavala otprilike nakon 20 minuta. Nakon 30 minuta bez problema stekli smo nadu, a nakon sat vremena — sigurnost. Vratili smo promet za pisanje na stranici i započeli postmortem analizu.
Uspijevši zaobići problem koji je vodio do zaključavanja, nismo otkrili njene prave uzroke. Potvrđeno je da to nije povezano s bilo kakvim promjenama u OpenShift-u 4.3.19, budući da se isto dogodilo i na verziji 4.3.18, koja je ranije radila s Quay bez ikakvih problema.
U klasteru se očito skrivala nešto drugo.
Detaljna ispitivanja
Quay.io šest godina koristio je zadane postavke za povezivanje s bazom podataka bez problema. Što se promijenilo? Jasno je da je u međuvremenu promet na quay.io neprekidno rastao. U našem slučaju čini se kao da je postignuta određena prag vrijednost koja je poslužila kao okidač za lavinu veza. Nastavili smo proučavati logove baze podataka nakon drugog kvara, ali nismo pronašli nikakvih obrazaca ili očitih povezanosti.
U međuvremenu, SRE tim radio je na poboljšanju vidljivosti zahtjeva u Quayu i općem zdravlju usluge. Postavljene su nove metrike i nadzorne ploče, pokazujući koji dijelovi Quaya imaju najveći promet među korisnicima.
Quay.io normalno je radio do 9. lipnja. Ujutro (po EDT-u) ponovno smo svjedočili značajnom porastu broja veza s bazom podataka. Ovaj put došlo je do zastoja, jer je nova postavka ograničila njihov broj i onemogućila prekoračenje propusnosti MySQL-a. Međutim, tijekom otprilike pola sata mnogi korisnici su primijetili usporen rad quay.io. Brzo smo prikupili sve dostupne podatke, koristeći dodane alate za nadzor. Iznenada se pokazala povezanost.
Prije samog skoka u broju veza, veliki broj zahtjeva stigao je na App Registry API. App Registry je malo poznata funkcija quay.io. Omogućuje pohranu stvari poput Helm dijagrama i kontejnera s bogatim metapodacima. Većina korisnika quay.io ne koristi ovu funkciju, međutim, aktivno je koristi Red Hat OpenShift. OperatorHub unutar OpenShifta pohranjuje sve operatore u App Registry. Ti operatori čine osnovu ekosustava radnih opterećenja OpenShifta i operativnog modela (u okviru operacija 'drugog dana', Day 2) orijentiranog na partnere.
Svaki OpenShift 4 klaster koristi operatore iz ugrađenog OperatorHub-a za objavljivanje kataloga dostupnih operatora za instalaciju i pružanje ažuriranja za već instalirane. S povećanjem popularnosti OpenShift 4 porastao je i broj klastera na njemu diljem svijeta. Svaki od tih klastera učitava sadržaj operatora kako bi pokrenuo ugrađeni OperatorHub, koristeći App Registry unutar quay.io kao pozadinu. U potrazi za izvorom problema, propustili smo da primijetimo da je s postepenim porastom popularnosti OpenShift povećan i pritisak na jednu od rijetko korištenih funkcija quay.io..
Proveli smo analizu prometa zahtjeva App Registry i zavirili u kod registra. Odmah su se otkrili nedostaci koji su uzrokovali neoptimizirano formiranje zahtjeva prema bazi podataka. Pri malom opterećenju nisu predstavljali nikakve probleme, ali su s povećanjem opterećenja postajali izvor problema. App Registry je imao dva problematična endpointa, koja slabo reagiraju na porast opterećenja: prvi je izdavao popis svih paketa u repozitoriju, a drugi je vraćao sve blobove za paket.
Uklanjanje uzroka
Cijeli sljedeći tjedan posvetili smo optimizaciji koda App Registry i njegovog okruženja. Preinačeni su očigledno neučinkoviti SQL upiti, uklonjeni su suvišni pozivi komandi (koji su se pokretali pri svakom vađenju blobova), i dodano je keširanje gdje god je to bilo moguće. Nakon toga provedeno je opsežno testiranje performansi i uspoređena je brzina rada App Registry prije i nakon promjena. tar API zahtjevi koji su ranije trajali do pola minute sada su se izvršavali u milisekundama.
. Sljedećeg tjedna implementirali smo promjene u produkciju, i od tada quay.io radi stabilno. U to vrijeme zabilježeni su nekoliko naglih porasta prometa na endpointu App Registry, ali učinjene nadogradnje spriječile su prekide u radu baze podataka.Što smo naučili?
Jasno je da svaka usluga nastoji izbjeći zastoje. U našem slučaju, vjerujemo da su nedavni problemi pomogli da quay.io postane bolji. Za sebe smo izvukli nekoliko ključnih lekcija koje želimo podijeliti:
Podaci o tome tko i kako koristi vašu uslugu nikada nisu suvišni.
- Kako je Quay «samo radio», nikada nismo imali potrebu trošiti vrijeme na optimizaciju prometa i upravljanje opterećenjem. Sve to stvorilo je lažni osjećaj sigurnosti da se usluga može skalirati neograničeno.Kada usluga padne,
- obnova njenog rada je glavni prioritet. восстановление его работы — главный приоритет. Budući da je Quay nastavio trpjeti od blokirane baze podataka tijekom prvog kvara, naši standardni postupci nisu imali planirani učinak i nismo uspjeli obnoviti rad usluge njihovom pomoći. To je dovelo do situacije u kojoj je bilo potrebno provesti vrijeme analizirajući i prikupljajući podatke u nadi da ćemo pronaći uzrok — umjesto da usmjerimo sve napore na obnavljanje funkcionalnosti.
- Procijenite utjecaj svake funkcije usluge. Klijenti rijetko koriste App Registry, stoga nije bio prioritet za naš tim. Kada se neke funkcije proizvoda gotovo uopće ne koriste, njihovi bugovi se rjeđe 'otkrivaju', a programeri prestaju pratiti kod. Lako je postati žrtva zablude da to tako treba biti — dok iznenada ta funkcija ne postane u središtu velikog incidenta.
Što dalje?
Rad na osiguranju stabilnosti usluge nikada ne prestaje i stalno je poboljšavamo. Obujmi prometa na quay.io i dalje rastu, a mi smo svjesni da moramo učiniti sve što je moguće kako bismo opravdali povjerenje klijenata. Stoga trenutno radimo na sljedećim zadacima:
- Implementacija replikacija baza podataka samo za čitanje, kako bi se pomoglo usluzi da obradi odgovarajući promet u slučaju problema s glavnim primjerkom RDS-a.
- Ažuriranje primjerka RDS-a. Trenutna verzija sama po sebi nije problem. Umjesto toga, jednostavno želimo ukloniti lažni trag (koji smo slijedili tijekom kvara); održavanje softvera ažurnim omogućit će uklanjanje još jednog faktora za buduća isključenja.
- Dodatno cacheiranje u cijelom klasteru. Nastavljamo tražiti područja u kojima cacheiranje može smanjiti opterećenje na bazi podataka.
- Dodavanje vatrozida aplikacija (WAF), kako bismo vidjeli tko i zašto pristupa quay.io.
- Počevši od sljedeće verzije, klasteri Red Hat OpenShift odustaju od App Registry u korist kataloga operatora (Operator Catalogs), koji se temelje na slikama kontejnera dostupnim na quay.io.
- Dugoročna zamjena za App Registry mogla bi biti podrška specifikacijama artefakata Open Container Initiative (OCI). Trenutno je implementirana kao izvorna funkcionalnost Quay i bit će dostupna korisnicima kada se sama specifikacija konačno usuglasi.
Sve navedeno dio je kontinuiranih ulaganja Red Hata u quay.io dok prelazimo iz male "startupa" ekipe u zrelu platformu koju upravlja SRE. Svjesni smo da mnogi naši klijenti ovise o quay.io u svom svakodnevnom radu (uključujući i Red Hat!) i trudimo se biti što otvoreniji u vezi s nedavnim neuspjesima i stalnim naporima da postanemo bolji.
P.S. od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «».
Izvor: habr.com
