Op. prev.: v začetku avgusta je Red Hat javno sporočil o rešitvi težav z dostopnostjo, ki so se v preteklih mesecih pojavljale uporabnikom njihove storitve. (v osnovi gre za register za slike kontejnerjev, ki ga je podjetje pridobilo s prevzemom CoreOS). Ne glede na vašo zainteresiranost za to storitev kot tako, je poučen sam pot, po katerem so šli SRE-inženirji podjetja, da bi diagnosticirali in odpravili vzroke za okvaro.
19. maja, zgodaj zjutraj (po poletnem vzhodnoameriškem času, EDT), je storitev quay.io propadla. Okvara je prizadela tako uporabnike quay.io, kot tudi projekte odprte kode, ki uporabljajo quay.io kot platformo za zbiranje in distribucijo programske opreme. Red Hat ceni zaupanje tako uporabnikov kot tudi skupnosti.
Ekipa SRE-inženirjev se je takoj vključila v delo in poskušala čim prej stabilizirati delovanje storitve Quay. Vendar pa so med tem, ko so to počeli, stranke izgubile možnost nalaganja novih slik, in le občasno so lahko prenašale obstoječe. Iz neznanega razloga se je baza podatkov quay.io blokirala po razširitvi storitve na polno zmogljivost.
«Kaj se je spremenilo?» — to je prvo vprašanje, ki ga navadno postavimo v takih primerih. Opazili smo, da je kmalu pred težavami klaster OpenShift Dedicated (na katerem deluje quay.io) začel posodabljati na različico 4.3.19. Ker quay.io deluje na Red Hat OpenShift Dedicated (OSD), so redne posodobitve predstavljale običajno operacijo in nikoli niso povzročale težav. Poleg tega smo v zadnjih šestih mesecih večkrat posodobili klastre Quay brez prekinitev v servisiranju.
Medtem ko smo poskušali obnoviti delovanje storitve, so drugi inženirji začeli pripravljati nov klaster OSD s prejšnjo različico programske opreme, da bi v primeru težav lahko vse vzpostavili nanj.
Analiza osnovnih vzrokov
Glavni simptom okvare je bila plaz iz desetih tisoč povezav na BDP, zaradi česar je bil primer MySQL dejansko nefunkcionalen. Zaradi tega je bilo težko diagnosticirati problem. Uvedli smo omejitev na največje število povezav od strank, da smo ekipi SRE pomagali oceniti težavo. Nobenega nenavadnega prometa na bazo podatkov nismo opazili: v resnici so bili večinoma vsi poizvedbe za branje, le redki so bili za pisanje.
Poskusili smo identificirati vzorec v prometu baze podatkov, ki bi lahko povzročil to poplavo. Kljub temu nismo uspeli odkriti nobenih vzorcev v dnevnikih. Medtem ko smo čakali na dokončanje novega klasterja z OSD 4.3.18, smo nadaljevali s poskusi za zagon podov quay.io. Vsakič, ko je klaster dosegel polno zmogljivost, je baza podatkov zastala. To je pomenilo, da je bilo potrebno znova zagnati primer RDS poleg vseh podov quay.io.
Do večera smo stabilizirali storitev v načinu le za branje in onemogočili čim več nepomembnih funkcij (na primer čiščenje prostorov imen), da bi zmanjšali obremenitev baze podatkov. Zastoji so prenehali, a vzrok ni bil nikoli ugotovljen. Nov klaster OSD je bil pripravljen, prenesli smo storitev, povezali promet in nadaljevali s spremljanjem.
Quay.io je stabilno deloval na novem OSD klastru, zato smo se vrnili k dnevnikom baze podatkov, vendar nismo uspeli odkriti korelacije, ki bi razložila zaklepe. Inženirji OpenShift so sodelovali z nami, da bi poskušali razumeti, ali so lahko spremembe v Red Hat OpenShift 4.3.19 povzročile težave s Quay. Vendar nič ni bilo odkrita, in ni bilo mogoče reproducirati problema v laboratorijskih razmerah.
Druga napaka
28. maja, kmalu pred poldnevom po EDT, se je quay.io znova zrušil s istimi simptomi: delovanje baze podatkov je bilo zaklenjeno. In ponovno smo usmerili vse sile v raziskovanje. Najprej je bilo treba obnoviti delovanje storitve. Vendar tokrat ponovni zagon RDS in ponovni zagon podov quay.io nista obrodila sadov: nova poplava povezav je preplavila bazo. Ampak zakaj?
Quay je napisan v Pythonu, in vsak pod deluje kot enoten monolitni kontejner. V okolju kontejnerja se hkrati izvaja več vzporednih nalog. Uporabljamo knjižnico gevent pod gunicorn za obdelavo spletnih poizvedb. Ko v Quay prispe poizvedba (prek našega lastnega API-ja ali prek API-ja Dockerja), se dodeli gevent delavcu. Običajno se ta delavec poveže z bazo podatkov. Po prvem zastoju smo ugotovili, da so se gevent delavci povezovali z bazo podatkov z uporabo privzetih nastavitev.
Glede na znatno število podov Quay in tisoče prihajajočih zahtevkov na sekundo, je visok števil povezanih baz podatkov teoretično lahko obremenil instanco MySQL. Z nadzorom smo ugotovili, da Quay povprečno obdeluje 5 tisoč zahtevkov na sekundo. Število povezav z bazo podatkov je bilo približno enako. 5 tisoč povezav je še sprejemljivo v okviru zmogljivosti naše instance RDS (kar ne moremo reči za desetine tisočev). Iz nekega razloga so se dogajali nepričakovani skoki v številu povezav, vendar nismo opazili nobene korelacije s prihajajočimi zahtevki.
Tokrat smo se odločili, da najdemo in odpravimo vir problema, namesto da se zadovoljimo zgolj s ponovnim zagonom. V kodo Quay so bile vnesene spremembe, ki omejujejo število povezav z DB za vsakega delavca gevent. To število je postalo parameter v konfiguraciji: bilo je mogoče spreminjati ga 'v teku', brez potrebe po ponovnem sestavljanju slike kontejnerja. Da bi ugotovili, koliko povezav lahko dejansko obdelamo, smo izvedli več testiranj v staging okolju, kjer smo nastavljali različne vrednosti in opazovali, kako se odraža na scenarijih obremenitvenega testiranja. Na koncu se je izkazalo, da Quay začne izdajati napake 502, ko število povezav preseže 10 tisoč.
Takoj smo razporedili to novo različico v produkcijo in začeli spremljati graf povezav z bazo podatkov. V preteklosti se je baza blokirala približno po 20 minutah. Po 30 minutah brez težav smo imeli upanje, po eni uri pa prepričanje. Obnovili smo pisno prometa na strani in se lotili postmortem analize.
Uspešno smo obšli problem, ki je vodil do blokade, nismo pa odkrili njegovih pravih vzrokov.Potrdilo se je, da ni povezan s kakršnimi koli spremembami v OpenShift 4.3.19, saj se je enako zgodilo tudi v različici 4.3.18, ki je prej delala s Quay brez kakršnih koli težav.
V grozdu se je očitno skrivala še kaj drugega.
Podrobna preiskava
Quay.io je šest let používal výchozí nastavení pro připojení k databázi bez jakýchkoli problémů. Co se změnilo? Je jasné, že po celou tuto dobu neustále rostl provoz na quay.io. V našem případě to vypadalo, jako by bylo dosaženo určité prahové hodnoty, která spustila lavinu připojení. Pokračovali jsme ve zkoumání logů databáze po druhém výpadku, ale žádné vzorce nebo zřejmé souvislosti jsme nenalezli.
Mezitím se tým SRE věnoval zlepšování oblasti sledovatelnosti dotazů na Quay a celkové zdraví služby. Byly nasazeny nové metriky a monitoringové panely, které ukazují, které části Quay jsou ze strany zákazníků nejvíce poptávány.
Quay.io fungoval normálně až do 9. června. Ráno (podle EDT) jsme opět byli svědky významného nárůstu počtu připojení k databázi. Tentokrát nedošlo k žádnému výpadku, protože nový parametr omezoval jejich počet a neumožňoval překročit kapacitu MySQL. Přibližně po dobu půl hodiny mnoho uživatelů zaznamenalo pomalý výkon quay.io. Rychle jsme shromáždili všechny dostupné údaje za použití přidaných monitorovacích nástrojů. Náhle se objevila vzorce.
Před samotným skokem v počtu připojení došlo k mnoha dotazům na App Registry API. App Registry je málo známá funkce quay.io. Umožňuje uchovávat věci jako Helm chart a kontejnery s bohatými metadaty. Většina uživatelů quay.io s touto funkcí nepracuje, ale je aktivně využívána Red Hat OpenShift. OperatorHub v rámci OpenShift uchovává všechny operátory v App Registry. Tito operátoři tvoří základ pro ekosystém pracovních zátěží OpenShift a operační model (v rámci operací "druhého dne", Day 2), orientovaný na partnery.
Každý OpenShift 4 cluster používá operátory z vestavěného OperatorHub pro publikaci katalogu dostupných operátorů k instalaci a poskytování aktualizací pro již nainstalované. S rostoucí popularitou OpenShift 4 vzrostl i počet clusterů na něm po celém světě. Každý z těchto clusterů načítá obsah operátorů, aby spustil vestavěný OperatorHub, s využitím App Registry uvnitř quay.io jako backend. Pri iskanju izvora težave smo spregledali, da se je z naraščanjem priljubljenosti OpenShifta povečalo tudi obremenitev ene redko uporabljene funkcije quay.io..
Izvedli smo analizo prometa zahtevkov za App Registry in pregledali kodo registra. Takoj so se razkrili pomanjkljivosti, zaradi katerih so se zahteve za bazo podatkov oblikovale suboptimalno. Pri nizki obremenitvi niso povzročale težav, vendar so ob povečanju obremenitve postale vir težav. App Registry je imel dva problematična endpointa, ki slabo reagirata na povečanje obremenitve: prvi je vračal seznam vseh paketov v repozitoriju, drugi pa vse blob-e za paket.
Odprava vzrokov
Vso naslednjo tednu smo se ukvarjali z optimizacijo kode samega App Registry in njene okolice. Preoblikovali smo očitno neučinkovite SQL-naročila, odpravili odvečne klice ukaza (ki se je izvajal pri vsakem izvleku blob-ov), dodali predpomnjenje povsod, kjer je to bilo mogoče. Nato je bilo izvedeno obsežno testiranje zmogljivosti in primerjana hitrost delovanja App Registry pred in po spremembah. tar API zahtevki, ki so prej trajali do pol minute, so sedaj izvršeni v milisekundah.
. Naslednji teden smo uvedli spremembe v produkcijo in od takrat quay.io deluje stabilno. V tem času smo opazili več ostrih vrhov prometa na endpointu App Registry, vendar so izboljšave preprečile motnje v delovanju baze podatkov.Česa smo se naučili?
Jasno je, da si vsak servis prizadeva preprečiti izpade. V našem primeru verjamemo, da so nedavni izpadi pripomogli k izboljšanju quay.io. Izpostavili smo nekaj ključnih lekcij, ki jih želimo deliti:
Podatki o tem, kdo in kako uporablja vaš servis, nikoli niso odveč.
- Ker je Quay ''preprosto deloval'', nismo nikoli imeli potrebe nameniti časa optimizaciji prometa in upravljanju obremenitve. Vse to je ustvarilo lažen občutek varnosti, da se servis lahko neskončno širi.Ko servis odpove,
- je obnova njegovega delovanja glavni prioritet. obnovitev njegovega delovanja je glavni prioritet. Ker Quay še vedno trpi zaradi blokirane baze podatkov med prvim incidentom, naši standardni postopki niso imeli pričakovanega učinka in v njihovih okvirih nismo mogli obnoviti delovanja storitve. To je pripeljalo do situacije, ko smo porabili čas za analizo in zbiranje podatkov v upanju, da ugotovimo prvotni vzrok — namesto da bi vse sile usmerili v obnovitev delovanja.
- Ocenjujte vpliv posameznih funkcij storitve. Stranke redko uporabljajo App Registry, zato za našo ekipo ni bila prioritetna. Ko se nekatere funkcije izdelka skoraj nikoli ne uporabljajo, se njihovi hrošči redko pojavijo in razvijalci prenehajo spremljati kodo. Enostavno je postati žrtev zablode, da tako pač mora biti — dokler ta funkcija nenadoma ne pride v središče obsežnega incidenta.
Kaj zdaj?
Delo na zagotavljanju stabilnosti storitve nikoli ne miruje in nenehno jo izboljšujemo. Obseg prometa na quay.io še naprej narašča in zavedamo se, da smo dolžni storiti vse, kar je v naši moči, da upravičimo zaupanje strank. Zato trenutno delamo na naslednjih nalogah:
- Implementacija replik baz podatkov samo za branje, da bi pomagala storitvi obvladovati ustrezen promet v primeru težav z glavnim primerkom RDS.
- Posodobitev primerka RDS. Trenutna različica sama po sebi ni težava. Raje želimo le odpraviti lažni sledi (po katerih smo šli med okvaro); vzdrževanje programske opreme posodobljene bo odpravilo še en dejavnik v primeru prihodnjih izpadov.
- Dodatno predpomnjenje po celotnem grozdu. Še naprej iščemo področja, kjer bi predpomnjenje lahko zmanjšalo obremenitev baze podatkov.
- Dodajanje požarnega zidu za spletne aplikacije (WAF), da vidimo, kdo in zakaj se povezuje na quay.io.
- Z naslednjo različico bosta grozdi Red Hat OpenShift opustila App Registry v prid katalogom operaterjev (Operator Catalogs), ki temeljijo na slikah kontejnerjev, dostopnih na quay.io.
- Dolgoročna zamenjava za App Registry lahko postane podpora specifikacijam artefaktov Open Container Initiative (OCI). Ta se trenutno izvaja kot domača funkcionalnost Quay in bo na voljo uporabnikom, ko bo sama specifikacija dokončno potrjena.
Vse zgoraj navedeno je del naših stalnih naložb Red Hat v quay.io, ko prehajamo od majhne ekipe v duhu zagonskega podjetja k zreli platformi, ki jo upravlja SRE. Zavedamo se, da se mnogi naši odjemalci zanašajo na quay.io v svojem vsakdanjem delu (vključno z Red Hat!) in si prizadevamo biti kar se da odprti glede nedavnih motenj in stalnih prizadevanj, da postanemo boljši.
P.S. od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «».
Izvor: habr.com
