Opomba. prevod: Red Hat je v začetku avgusta javno spregovoril o reševanju težav z dostopnostjo, s katerimi so se uporabniki njegove storitve srečevali v prejšnjih mesecih (temelji na registru za vsebniške slike, ki ga je podjetje prejelo skupaj z nakupom CoreOS). Ne glede na vaše zanimanje za to storitev kot tako, je pot, ki so jo ubrali SRE inženirji podjetja, da bi diagnosticirali in odpravili vzroke nesreče, poučna.
19. maja zgodaj zjutraj (vzhodni poletni čas, EDT) se je storitev quay.io zrušila. Nesreča je prizadela tako potrošnike quay.io kot odprtokodne projekte, ki uporabljajo quay.io kot platformo za izdelavo in distribucijo programske opreme. Red Hat ceni zaupanje obeh.
Takoj se je vključila ekipa inženirjev SRE in poskušala čim prej stabilizirati storitev Quay. Toda medtem, ko so to počeli, so stranke izgubile možnost potiskanja novih slik in le občasno so lahko povlekle obstoječe. Iz neznanega razloga je bila baza podatkov quay.io blokirana po povečanju storitve na polno zmogljivost.
«Kaj se je spremenilo?« - to je prvo vprašanje, ki se običajno postavi v takih primerih. Opazili smo, da se je tik pred težavo namenska gruča OpenShift (ki izvaja quay.io) začela posodabljati na različico 4.3.19. Ker quay.io deluje na Red Hat OpenShift Dedicated (OSD), so bile redne posodobitve rutinske in nikoli niso povzročale težav. Poleg tega smo v zadnjih šestih mesecih večkrat nadgradili Quay grozde brez kakršne koli prekinitve storitve.
Medtem ko smo poskušali obnoviti storitev, so drugi inženirji začeli pripravljati novo gručo OSD s prejšnjo različico programske opreme, tako da so lahko, če se kaj zgodi, namestili vse na njej.
Analiza temeljnega vzroka
Glavni simptom okvare je bil plaz več deset tisoč povezav baze podatkov, zaradi česar je bila instanca MySQL dejansko neuporabna. Zaradi tega je bilo težko diagnosticirati težavo. Postavili smo omejitev največjega števila povezav strank, da bi ekipi SRE pomagali oceniti težavo. Nismo opazili nenavadnega prometa v zbirki podatkov: pravzaprav je bila večina zahtev prebranih in le nekaj pisanih.
Poskušali smo tudi identificirati vzorec v prometu baze podatkov, ki bi lahko povzročil ta plaz. Vendar v dnevnikih nismo našli nobenih vzorcev. Medtem ko smo čakali, da bo nova gruča z OSD 4.3.18 pripravljena, smo nadaljevali s poskusi zagona quay.io pods. Vsakič, ko je gruča dosegla polno zmogljivost, bi baza podatkov zamrznila. To je pomenilo, da je bilo treba znova zagnati primerek RDS poleg vseh podov quay.io.
Do večera smo storitev stabilizirali v načinu samo za branje in onemogočili čim več nebistvenih funkcij (na primer zbiranje smeti imenskega prostora), da zmanjšamo obremenitev baze podatkov. Zamrzovanja so prenehala vendar razloga nikoli niso našli. Nova gruča OSD je bila pripravljena, migrirali smo storitev, povezali promet in nadaljevali s spremljanjem.
Quay.io je na novi gruči OSD deloval stabilno, zato smo se vrnili k dnevnikom baze podatkov, vendar nismo mogli najti korelacije, ki bi pojasnila blokade. Inženirji OpenShift so sodelovali z nami, da bi razumeli, ali lahko spremembe v Red Hat OpenShift 4.3.19 povzročijo težave s Quay. Vendar ni bilo nič najdenega in Težave ni bilo mogoče reproducirati v laboratorijskih pogojih.
Drugi neuspeh
28. maja, malo pred poldnevom EDT, se je quay.io znova zrušil z enakim simptomom: baza podatkov je bila blokirana. In spet smo vse svoje napore vložili v preiskavo. Najprej je bilo treba obnoviti storitev. Vendar tokrat ponovni zagon RDS in ponovni zagon podov quay.io nista naredila nič: še en plaz povezav je zasul bazo. Ampak zakaj?
Quay je napisan v Pythonu in vsak pod deluje kot en sam monolitni vsebnik. Izvajalno okolje vsebnika izvaja številne vzporedne naloge hkrati. Uporabljamo knjižnico gevent pod gunicorn za obdelavo spletnih zahtev. Ko pride zahteva v Quay (prek našega lastnega API-ja ali prek Dockerjevega API-ja), ji je dodeljen gevent worker. Običajno mora ta delavec stopiti v stik z bazo podatkov. Po prvi napaki smo odkrili, da se delavci gevent povezujejo z bazo podatkov s privzetimi nastavitvami.
Glede na veliko število podov Quay in na tisoče dohodnih zahtev na sekundo bi lahko veliko število povezav baze podatkov teoretično preobremenilo primerek MySQL. Zahvaljujoč spremljanju je bilo znano, da Quay obdela povprečno 5 tisoč zahtevkov na sekundo. Število povezav z bazo je bilo približno enako. 5 tisoč povezav je bilo povsem v okviru zmožnosti naše instance RDS (česar ne moremo reči za desettisoče). Iz neznanega razloga je prišlo do nepričakovanih skokov v številu povezav, vendar nismo opazili nobene korelacije z dohodnimi zahtevami.
Tokrat smo bili odločeni najti in odpraviti vir težave in se ne omejiti na ponovni zagon. V kodno zbirko Quay narejene so bile spremembe za omejitev števila povezav z bazo podatkov za vsakega delavca gevent. Ta številka je postala parameter v konfiguraciji: postalo jo je mogoče spreminjati sproti, ne da bi zgradili novo sliko vsebnika. Da bi ugotovili, koliko povezav bi lahko realno obravnavali, smo izvedli več testov v uprizoritvenem okolju in nastavili različne vrednosti, da bi videli, kako bi to vplivalo na scenarije testiranja obremenitve. Posledično je bilo ugotovljeno, da Quay začne pošiljati napake 502, ko število povezav preseže 10 tisoč.
To novo različico smo takoj uvedli v produkcijo in začeli spremljati razpored povezav z bazo podatkov. V preteklosti so bazo zaklenili po približno 20 minutah. Po 30 minutah brez težav smo imeli upanje, uro kasneje pa zaupanje. Obnovili smo promet na mestu in začeli posmrtno analizo.
Ko je uspelo zaobiti težavo, ki vodi do blokade, njenih pravih razlogov nismo odkrili. Potrjeno je bilo, da ni povezano z nobenimi spremembami v OpenShift 4.3.19, saj se je isto zgodilo pri različici 4.3.18, ki je prej delovala s Quay brez težav.
Očitno se je v gruči skrivalo še nekaj.
Podrobna študija
Quay.io je šest let brez težav uporabljal privzete nastavitve za povezavo z bazo podatkov. Kaj se je spremenilo? Jasno je, da ves ta čas promet na quay.io vztrajno raste. V našem primeru je bilo videti, kot da je bila dosežena neka mejna vrednost, ki je služila kot sprožilec plazu povezav. Po drugi napaki smo nadaljevali s preučevanjem dnevnikov baze podatkov, vendar nismo našli nobenih vzorcev ali očitnih povezav.
Medtem je skupina SRE delala na izboljšavah Quayjeve opazljivosti zahtev in splošnega stanja storitve. Uvedene so bile nove meritve in nadzorne plošče, ki prikazuje, po katerih delih nabrežja kupci najbolj povprašujejo.
Quay.io je dobro deloval do 9. junija. Danes zjutraj (EDT) smo spet opazili znatno povečanje števila povezav z bazo podatkov. Tokrat ni bilo zastoja, saj je nov parameter omejil njihovo število in jim ni dovolil preseči prepustnosti MySQL. Vendar pa je približno pol ure veliko uporabnikov opazilo počasno delovanje quay.io. Z dodanimi orodji za spremljanje smo hitro zbrali vse možne podatke. Nenadoma se je pojavil vzorec.
Tik pred porastom povezav je bilo v API registra aplikacij poslanih veliko število zahtev. Register aplikacij je malo znana funkcija quay.io. Omogoča vam shranjevanje stvari, kot so grafikoni Helm in vsebniki z bogatimi metapodatki. Večina uporabnikov quay.io ne deluje s to funkcijo, vendar jo Red Hat OpenShift aktivno uporablja. OperatorHub kot del OpenShift shrani vse operaterje v registru aplikacij. Ti operaterji tvorijo osnovo za ekosistem delovne obremenitve OpenShift in operacijski model, osredotočen na partnerje (operacije 2. dan).
Vsaka gruča OpenShift 4 uporablja operaterje iz vgrajenega OperatorHub za objavo kataloga operaterjev, ki so na voljo za namestitev, in zagotavljanje posodobitev za tiste, ki so že nameščeni. Z naraščajočo priljubljenostjo OpenShift 4 se je povečalo tudi število gruč na njem po vsem svetu. Vsaka od teh gruč prenese vsebino operaterja za zagon vgrajenega OperatorHub, pri čemer kot zaledje uporablja register aplikacij znotraj quay.io. Pri našem iskanju vira težave smo spregledali dejstvo, da se je s postopnim naraščanjem priljubljenosti OpenShift povečala tudi obremenitev ene od redko uporabljenih funkcij quay.io..
Opravili smo nekaj analiz prometa zahtev registra aplikacij in si ogledali kodo registra. Takoj so se pokazale pomanjkljivosti, zaradi katerih poizvedbe v bazi podatkov niso bile optimalno oblikovane. Ko je bila obremenitev majhna, niso povzročali težav, ko pa se je obremenitev povečala, so postali vir težav. Izkazalo se je, da ima register aplikacij dve problematični končni točki, ki se nista dobro odzvali na naraščajočo obremenitev: prva je zagotovila seznam vseh paketov v skladišču, druga je vrnila vse blob-ove za paket.
Odprava vzrokov
V naslednjem tednu smo optimizirali kodo samega registra aplikacij in njegovega okolja. Očitno neučinkovite poizvedbe SQL so bile predelane in odpravljeni so bili nepotrebni klici ukazov tar (izveden je bil vsakič, ko so bili pridobljeni blobi), predpomnjenje je bilo dodano, kjer koli je bilo mogoče. Nato smo izvedli obsežno testiranje zmogljivosti in primerjali hitrost registra aplikacij pred in po spremembah.
Zahteve API-ja, ki so prej trajale do pol minute, so zdaj dokončane v milisekundah. Naslednji teden smo spremembe uvedli v produkcijo in od takrat quay.io deluje stabilno. V tem času je prišlo do več ostrih skokov v prometu na končni točki App Registry, vendar so izvedene izboljšave preprečile izpade baze podatkov.
Kaj smo se naučili?
Jasno je, da se vsaka storitev poskuša izogniti izpadom. V našem primeru verjamemo, da so nedavni izpadi pomagali izboljšati quay.io. Naučili smo se nekaj ključnih lekcij, ki bi jih radi delili:
- Podatki o tem, kdo in kako uporablja vašo storitev, niso nikoli odveč. Ker je Quay »pravkar deloval«, nam nikoli ni bilo treba porabiti časa za optimizacijo prometa in upravljanje obremenitve. Vse to je ustvarilo lažen občutek varnosti, ki bi ga lahko storitev širila v nedogled.
- Ko storitev preneha delovati, njegova ponovna vzpostavitev in delovanje je glavna prednostna naloga.. Ker je Quay med prvim izpadom še naprej trpel zaradi zaklenjene baze podatkov, naši standardni postopki niso imeli želenega učinka in z njihovo pomočjo nismo mogli obnoviti storitve. To je privedlo do situacije, ko je bilo treba porabiti čas za analiziranje in zbiranje podatkov v upanju, da bi našli glavni vzrok - namesto da bi se vsa prizadevanja usmerila v ponovno vzpostavitev funkcionalnosti.
- Ocenite vpliv vsake funkcije storitve. Stranke so redko uporabljale App Registry, zato to ni bila prednostna naloga naše ekipe. Ko se nekatere funkcije izdelka komaj uporabljajo, se njihove napake redko pojavijo in razvijalci prenehajo spremljati kodo. Zlahka postanemo žrtev napačnega prepričanja, da bi tako moralo biti – dokler se nenadoma ta funkcija ne znajde v središču velikega incidenta.
Kaj sledi?
Delo za zagotavljanje stabilnosti storitve se nikoli ne konča in jo nenehno izboljšujemo. Ker obseg prometa na quay.io še naprej narašča, se zavedamo, da imamo odgovornost storiti vse, kar je v naši moči, da upravičimo zaupanje naših strank. Zato trenutno delamo na naslednjih nalogah:
- Razmestite replike baz podatkov samo za branje, da storitvi pomagate obravnavati ustrezen promet v primeru težav s primarnim primerkom RDS.
- Posodabljanje primerka RDS. Trenutna različica sama po sebi ni problem. Namesto tega preprosto želimo odstraniti lažno sled (ki smo ji sledili med neuspehom); Posodabljanje programske opreme bo odpravilo še en dejavnik v primeru prihodnjih izpadov.
- Dodatno predpomnjenje v celotni gruči. Še naprej iščemo področja, kjer lahko predpomnjenje zmanjša obremenitev baze podatkov.
- Dodajanje požarnega zidu spletne aplikacije (WAF), da vidite, kdo se povezuje s quay.io in zakaj.
- Od naslednje izdaje bodo gruče Red Hat OpenShift opustile register aplikacij v korist katalogov operaterjev, ki temeljijo na slikah vsebnikov, ki so na voljo na quay.io.
- Dolgoročna zamenjava za App Registry bi lahko bila podpora za specifikacije artefaktov Open Container Initiative (OCI). Trenutno se izvaja kot izvorna funkcionalnost Quay in bo na voljo uporabnikom, ko bo sama specifikacija dokončana.
Vse našteto je del stalnih naložb Red Hat v quay.io, ko se premikamo od majhne ekipe v slogu zagonskih podjetij do zrele platforme, ki jo poganja SRE. Vemo, da se veliko naših strank pri vsakodnevnem delu zanaša na quay.io (vključno z Red Hat!), zato poskušamo biti čim bolj pregledni glede nedavnih izpadov in nenehnih prizadevanj za izboljšave.
PS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «".
Vir: www.habr.com