🥇Quay.io katkestamise analüüs

Märkus tõlke kohta.: augusti alguses teatas Red Hat avalikult, et on lahendanud probleemid kättesaadavusega, mis olid tekkinud selle teenuse kasutajatele eelnevatel kuudel Quay.io (selle aluseks on konteinerite piltide register, mis tuli ettevõttele koos CoreOSi ostmisega). Olenemata teie huvist selle teenuse vastu, on õpetlik jälgida, millist teed läbisid ettevõtte SRE-insenerid, et diagnostika ja rikke põhjused kõrvaldada.

19. mail, varahommikul (suvisel Põhja-Ameerika idaosas, EDT), langes quay.io teenus. Rike mõjutas nii quay.io kliente kui ka avatud lähtekoodiga projekte, mis kasutasid quay.io platvormina tarkvara koostamiseks ja levitamiseks. Red Hat hindab usaldust nii ühe kui teise seas.

SRE-inseneride meeskond hakkas kohe tööle ja püüdis Quay teenuse tööd võimalikult kiiresti stabiliseerida. Siiski, samal ajal, kui nad sellega tegelesid, kaotasid kliendid võimaluse uusi pilte üles laadida ja nad suudsid vaid perioodiliselt olemasolevaid tõmmata. Tundmatu põhjusel blokeerus quay.io andmebaas teenuse täielikul võimsusel skaleerimise ajal.

«Mis muutus?» — see on esimene küsimus, mida sellistes olukordades tavaliselt küsitakse. Me märkisime, et vahetult enne probleemi hakkas OpenShift Dedicated klaster (millel quay.io töötab) uuendama versioonile 4.3.19. Kuna quay.io töötab Red Hat OpenShift Dedicated (OSD) peal, olid regulaarne uuendamine igapäevane toiming ja need ei ole kunagi probleeme tekitanud. Veelgi enam, eelneva kuue kuu jooksul uuendasime me mitmel korral Quay klaustreid ilma teeninduskatkestuseta.

Samas, kui me püüdsime teenuse tööd taastada, hakkasid teised insenerid ette valmistama uut OSD klastrit varasema tarkvaraversiooniga, et hädaolukorras kõik selle peale välja panna.

Põhjuslik analüüs

Peamine rikke sümptom oli kümnete tuhandete andmebaasi ühenduste laviin, mis muutis MySQL eksemplari praktiliselt funktsionaalseteks. Sellega seoses oli probleemi diagnoosimine keeruline. Panime paika kliendi ühenduste maksimaalse arvu piirangu, et aidata SRE meeskonnal probleemi hinnata. Andmebaasi ei täheldatud erakordset liiklust: tegelikult olid enamus päringutest lugemise päringud, samas kui vaid vähesed olid kirjutamise päringud.

Me üritasime samuti tuvastada andmebaasi liiklusmustrit, mis oleks võinud selle laviini põhjustada. Siiski ei õnnestunud logidest mingeid seaduspärasusi leida. Oodates uut klastrit OSD versiooniga 4.3.18, jätkasime katseid quay.io pod'ide käivitamiseks. Iga kord, kui klaster jõudis täisvõimsusele, seisis andmebaas. See tähendas, et oli vajalik RDS instantsi taaskäivitamine koos kõigi quay.io pod'idega.

Kell õhtul stabiliseerisime teenuse read-only režiimis ja keelasime maksimaalselt ebaolulised funktsioonid (nt prügistamise nimel ruumis), et vähendada andmebaasi koormust. Seisakud lõppesid, kuid põhjust ei leitud. Uus OSD klaster oli valmis, ning me üle kandsime teenuse, ühendasime liikluse ja jätkasime jälgimist.

Quay.io töötas uue OSD klastril stabiilselt, seetõttu naasime andmebaasi logide juurde, kuid ei suutnud tuvastada korrelatsiooni, mis seletaks blokeeringuid. OpenShift'i insenerid töötasid koos meiega, püüdes mõista, kas Red Hat OpenShift 4.3.19 muudatused võisid põhjustada Quay probleemid. Siiski ei leitud midagi, ja probleemi laboritingimustes ei õnnestunud paljundada.

Teine rike

28. mail, enne keskpäeva EDT, kukkus quay.io uuesti sama sümptomi tõttu: andmebaasi töö blokeerus. Ja jälle suunasin kõik jõud uurimisele. Esiteks pidi teenuse töö taastama. Kuid seekord RDS taaskäivitamine ja quay.io pod'ide uuesti käivitamine ei aidanud: andmebaasi haaras jälle ühenduste laviin. Aga miks?

Quay on kirjutatud Pythonis, ning iga pod töötab nagu ühtne monoliitne konteiner. Konteinerikeskkonnas toimub samaaegselt palju paralleelseid ülesandeid. Kasutame raamatukogu gevent alla gunicorn veebipäringute töötlemiseks. Kui Quay saab päringu (kas meie enda API kaudu või Docker API kaudu), määratakse sellele gevent worker. Tavaliselt peab see worker ühendust võtma andmebaasiga. Pärast esimest tõrget märkasime, et gevent worker'id ühendasid andmebaasiga vaikeseadetega.

Arvestades Quay suure arvu pod’ide ja tuhandeid sisenevaid päringuid sekundis, võis suur hulk andmebaasi ühendusi teoreetiliselt koormata MySQL eksemplari. Jälgimise kaudu oli teada, et Quay töötleb keskmiselt 5000 päringut sekundis. Umbes sama oli ka andmebaasi ühenduste arv. 5000 ühendust mahtus mugavalt meie RDS eksemplari võimalustesse (mida ei saa öelda kümnete tuhande ühenduste kohta). Mingil põhjusel toimusid ootamatud ühenduste arvu plahvatused., kuid me ei märganud mingit seost sisenevate päringutega.

Seekord otsustasime kindlalt leida ja kõrvaldada probleemi allika, mitte piirduda lihtsalt taaskäivitamisega. Quay koodibaasi tehti muudatused, mis piiravad iga worker’i andmebaasi ühenduste arvu gevent. See arv sai konfiguratsiooni parameetriks: seda oli võimalik muuta "režiimis", ilma uue konteineri pildi keeramiseta. Selleks, et teada saada, kui palju ühendusi on tegelikult võimalik käsitleda, viidi läbi mitu katset staging-keskkonnas, kus määrati erinevaid väärtusi, et näha, kuidas see mõjutab koormustestide stsenaariume. Lõpuks selgus, et Quay hakkab andma 502 vigu, kui ühenduste arv ületab 10 000.

Me paigaldasime selle uue versiooni kohe tootmisse ja hakkasime jälgima andmebaasi ühenduste graafikut. Eelmine kord blokeerus andmebaas umbes 20 minuti pärast. 30 probleemivaba minuti pärast tekkis meil lootus, ja tunni pärast – kindel tunne. Taastasime kirjutustrafiku saidil ja asusime postmortem-analüüsi juurde.

Olles probleemist mööda pääsenud, ei selgitanud me selle tegelikke põhjuseid. Selgus, et see ei olnud seotud ühegi muudatusega OpenShift 4.3.19, kuna sama oli juhtunud ka versioonis 4.3.18, mis töötas Quay’ga varem probleemideta.

Klastris peitus ilmselt veel midagi.

Detailne uurimine

Quay.io on kuue aasta jooksul kasutanud vaike seadistusi andmebaasi ühendamiseks ilma probleemideta. Mis muutus? Selge on, et selle aja jooksul on quay.io liiklus pidevalt kasvanud. Meie puhul näis, et saavutati mingisugune lävendi väärtus, mis käivitas ühenduste laviini. Jätkasime andmebaasi logide uurimist pärast teist riket, kuid ei leidnud mustreid ega ilmselgeid seoseid.

Samal ajal töötas SRE meeskond Quay päringute jälgimise ja teenuse üldise tervise parandamise kallal. Käivitatud on uusi mõõdikuid ja jälgimispaneele, mis näitavad, millised Quay osad saavad klientide seas kõige rohkem nõudlust.

Quay.io töötas normaalselt 9. juunini. Hommikul (EDT ajal) nägime jälle märkimisväärset andmebaasi ühenduste arvu suurenemist. Seekord ei toimunud seisakut, kuna uus parameeter piiras nende arvu ja ei lubanud ületada MySQL-i läbilaskevõimet. Kuid umbes poole tunni jooksul märkisid paljud kasutajad quay.io aeglast toimimist. Kogusime kiiresti kõik võimalikud andmed, kasutades lisatud jälgimisvahendeid. Äkitselt ilmnes muster.

Enne ühenduste arvu hüpet tuli suur hulk päringuid App Registry API-le. App Registry on quay.io vähemtuntud funktsioon. See võimaldab salvestada selliseid asju nagu Helm’i graafikud ja rikkalike (rich) metaandmetega konteinerid. Enamik quay.io kasutajatest ei kasuta seda funktsiooni, kuid Red Hat OpenShift kasutab seda aktiivselt. OpenShifti osa OperatorHub salvestab kõik operaatorid App Registry-s. Need operaatorid moodustavad aluse OpenShifti töökoormuste ökosüsteemile ja partneritele suunatud operatsioonide (teise päeva operatsioonid, Day 2) mudelile.

Iga OpenShift 4 klaster kasutab sisseehitatud OperatorHub’i operaatorite avaldamiseks ning paigaldamiseks saadaval olevate operaatorite katalooge ja uuenduste pakkumiseks juba paigaldatud operaatoritele. OpenShift 4 populaarsuse suurenemisega on kasvanud ka sellel põhinevate klastrite arv kogu maailmas. Igaüks neist klastritest laadib operaatorite sisu, et käivitada sisseehitatud OperatorHub, kasutades quay.io App Registry't tagapõhjana. Probleemi allika otsimisel jätsime tähelepanuta, et koos OpenShift'i kasvava populaarsusega kasvas ka koormus ühele harva kasutatud funktsioonile quay.io..

Me tegime mõned analüüsid App Registry päringute liiklusest ja vaatasime registri koodi. Kohe selgusid puudujäägid, mis viisid andmebaasi päringute ebaefektiivse koostamiseni. Madala koormuse korral ei tekkinud probleeme, kuid selle suurenedes muutusid need probleemide allikaks. App Registry'l oli kaks probleemset lõpp-punkti, mis reageerisid halvasti koormuse suurenemisele: esimene andis välja kõigi pakettide loendi hoidlast, teine tagastas kõik blob’id paketi jaoks.

Probleemide likvideerimine

Järgneva nädala jooksul tegelesime App Registry koodi ja selle keskkonna optimeerimisega. Üksikasjalikult ebaefektiivsed SQL-päringud viidi üle ning eemaldati tarbetud käsu kutsed (need käivitati iga blob’i väljavõtte ajal), kanti sisse vahemälu kõikjal, kus see on võimalik. Seejärel viidi läbi ulatuslik jõudlustestimine ja võrreldi App Registry töö kiirus muutuste eel ja järel. tar API päringud, mis varem võtsid kuni pool minutit, täideti nüüd millisekundite jooksul.

. Järgmisel nädalal võtsime muudatused kasutusele tootmises ja pärast seda on quay.io töötanud stabiilselt. Selle aja jooksul täheldati mitmeid järske liikluspiike App Registry lõpp-punktis, kuid teostatud täiustused vältisid andmebaasi katkemisi.Mida me õppisime?

Selge on, et iga teenus püüab vältida seisakuid. Meie puhul usume, et hiljutised katkestused aitasid teha quay.io paremaks. Meie jaoks tõime välja mitmed peamised õppetunnid, mida soovime jagada:

Teave selle kohta, kes ja kuidas teie teenust kasutab, ei ole kunagi üleliigne.

Kuna Quay „lihtsalt töötas”, ei olnud meil kunagi vajadust kulutada aega liikluse optimeerimisele ja koormuse haldamisele. See tekitas vale turvatunde, et teenus suudab skaleeruda lõputult.Kui teenus kukub,
siis selle töökorda tagasi toomine on peamine prioriteet. tema töö taastamine on peamine prioriteet. Kuna Quay jätkas blokeeritud andmebaasist kannatamist esimese rikkumise ajal, ei avaldanud meie standardsed protseduurid oodatud mõju ja me ei suutnud teenuse toimimist nende abil taastada. See viis olukorrani, kus pidime veetma aega analüüsimiseks ja andmete kogumiseks lootuses leida põhjus — selle asemel, et suunata kõik jõupingutused teenuse taastamiseks.
Hinnake iga teenuse funktsiooni mõju. Klientide seas oli App Registry harva kasutusel, seetõttu polnud see meie meeskonnale prioriteet. Kui mõned toote funktsioonid on peaaegu kasutamata, siis ilmuvad nende vead harva ning arendajad lõpetavad koodi jälgimise. On lihtne langeda valearusaama küüsi, et nii peabki olema — kuni see funktsioon ühtäkki satub suurema kohaliku intsidenti keskmesse.

Mis edasi?

Teenuse stabiilsuse tagamise töö ei peatu kunagi ja me täiustame seda pidevalt. Liiklus quay.io-l jätkab kasvu, ja me oleme teadlikud, et peame tegema kõik endast oleneva, et õigustada klientide usaldust. Seetõttu töötame praegu järgmiste probleemide kallal:

Lugemisega andmebaasi koopiate juurutamine, et aidata teenusel probleemide korral vastavat liiklust töödelda peamise RDS-instantsi puhul.
RDS-instantsi värskendamine. Praegune versioon iseenesest pole probleem. Pigem tahame lihtsalt kõrvaldada valejälje (millele me esimese rikkumise ajal jäime); tarkvara ajakohasena hoidmine väldib veel ühe teguri, mis võiks tulevaste katkestuste korral muret tekitada.
Lisaküsimine kogu klastris. Jätkame piirkondade otsimist, kus küsimise abil saab andmebaasi koormust vähendada.
Veebirakenduste tulemüüri (WAF) lisamine, et näha, kes ja miks ühendab quay.io-le.
Alates järgmisest versioonist loobuvad Red Hat OpenShift'i klastrid App Registry'st, eelistades konteinerite põhiseid operaatorikatalooge (Operator Catalogs), mis on saadaval quay.io-l.
Pikaajaline asendaja App Registry jaoks võib olla Open Container Initiative'i (OCI) artefaktide spetsifikatsioonide tugi. See on praegu ellu viidud Quay natiivse funktsioonina ja on kasutajatele saadaval, kui spetsifikatsioon lõpuks kooskõlastatakse.

Kõik eespool loetletud on osa Red Hati jätkuvatest investeeringutest quay.io, kui liikume edasi väikesest "start-up"-stiilis meeskonnast küpsesse platvormi, mida haldab SRE. Me teame, et paljud meie kliendid usaldavad quay.io oma igapäevaelus (sealhulgas Red Hat!) ja püüame olla nii avatud kui võimalik viimaste tõrgete ja jätkuvate pingutuste osas, et paremaks saada.