🥇Quay.io teenuse katkestuse Post Mortem

Märk. tõlge.: augusti alguses teatas Red Hat avalikult probleemide lahendamisest, mis olid tekkinud viimastel kuudel nende teenuse kasutajatele. Quay.io (millest suur osa on konteinerite piltide register, mis ettevõttele tuli koos CoreOS'i ostmisega). Ükskõik kui huvitav see teenus teile ka poleks, on õpetlik jälgida, milliseid samme astusid ettevõtte SRE insenerid probleemi diagnoosimiseks ja lahendamiseks.

19. mai hommikul (põhjapoolkera suveaja idas, EDT) langes quay.io teenus. Intsident mõjutas nii quay.io tarbijaid kui ka avatud lähtekoodiga projekte, mis kasutasid quay.io tarkvara kogumise ja levitamise platvormina. Red Hat hindab nii üksikute tarbijate kui ka projektide usaldust.

SRE inseneride meeskond asus kohe tööle ja püüdis võimalikult kiiresti Quay teenuse stabiilsust taastada. Kuid samal ajal, kui nad sellega tegelesid, kaotasid kliendid võimaluse uusi pilte push'ida ning suudsid vaid aeg-ajalt olemasolevaid pull'ida. Müstiliselt lukustus quay.io andmebaas teenuse täisvõimsusele skaleerimise järel.

«Mida on muutunud?» — see on esimene küsimus, mida sellistes olukordades tavaliselt esitatakse. Oleme märganud, et just enne probleemi algust algas OpenShift Dedicated klastril (millel quay.io töötab) uuendamine versioonile 4.3.19. Kuna quay.io töötab Red Hat OpenShift Dedicated (OSD) platvormil, olid regulaarne uuendamine tavapärane tegevus ning need ei ole kunagi probleeme põhjustanud. Veelgi enam, viimase kuue kuu jooksul oleme mitu korda Qay klastreid uuendanud ilma igasuguste teeninduspause.

Kuni püüdsime teenuse tööle saada, hakkasid teised insenerid ette valmistama uut OSD klastrit varasema tarkvaraversiooniga, et vajadusel saaksime kõik selle peale väljastada.

Põhjuse analüüs

Peamine rikke sümptom oli kümnete tuhandete andmebaasi ühenduste laviin, mis tegi MySQL instantsi praktiliselt kasutuskõlbmatuks. Seetõttu oli probleemi diagnoosimine keerukas. Seadsime kliendiühenduste maksimaalse arvu piirangu, et aidata SRE meeskonnal probleemi hinnata. Andmebaasi liiklus ei olnud ebatavaline: tegelikult olid enamus päringud lugemiseks, vaid mõned kirjutamiseks.

Püüdsime samuti tuvastada andmebaasi liikluses mustreid, mis oleksid võinud selle laviini põhjustada. Kuid logidest ei õnnestunud mingeid seaduspärasusi leida. Oodates uue klastriga OSD 4.3.18 valmimist, jätkasime katseid quay.io pod'ide käivitamiseks. Igal korral, kui klaster jõudis täisvõimsusele, andmebaas seisis. See tähendas, et tuli uuesti käivitada RDS eksemplar koos kõigi quay.io pod'idega.

Õhtuks stabiliseerisime teenuse read-only režiimis ja lõikasime välja enamiku mitteolulisi funktsioone (nt prügikoristus nimeruumis), et vähendada andmebaasi koormust. Hangumised lõppesid, kuid põhjust ei suudetud leida. Uus OSD klaster oli valmis, ja me kolisime teenuse, suunates liikluse ning jätkates jälgimist.

Quay.io töötas uuel OSD-klastril stabiilselt, seetõttu pöördusime tagasi andmebaasi logide juurde, kuid ei suutnud siiski avastada korrelatsiooni, mis seletaks blokeeringuid. OpenShift'i insenerid tegid koostööd meiega, pidades silmas, kas Red Hat OpenShift 4.3.19 muudatused võiksid Quayga probleeme tekitada. Siiski ei leitud mingeid tulemusi, katse edastada probleemi laboritingimustes ei õnnestunud.

Teine tõrge

28. mai, vahetult enne keskpäeva EDT, kukkus quay.io taas sama sümptomi tõttu: andmebaasi toimimine seiskus. Ja taas panime kõik jõud uurimisele. Esiteks tuli taastada teenuse toimimine. Kuid seekord RDS-i taaskäivitamine ja quay.io pod'ide uuesti käivitamine ei andnud tulemusi: veel üks ühenduste laviin uputas andmebaasi. Kuid miks?

Quay on kirjutatud Pythonis, ja iga pod töötab ühe monoliitse konteinerina. Kogumise ajal täidetakse konteineris mitmeid paralleelseid ülesandeid. Kasutame teeki gevent all gunicorn webipäringute töötlemiseks. Kui Quay saab päringu (kas meie enda API kaudu või Docker API kaudu), määratakse sellele gevent worker. Üldjuhul peab see worker ühendust võtma andmebaasiga. Pärast esimest tõrget avastasime, et gevent worker'id kasutasid andmebaasiga ühendamiseks vaikeasetusi.

Arvestades Quay suure hulga pod'ide ja tuhandeid sekundi kohta saabunud päringute hulka, oleks andmebaasiga ühenduste arv teoreetiliselt võinud MySQL eksemplari üle koormata. Monitooringu kaudu oli teada, et Quay keskmiselt töötleb 5 tuhat päringut sekundis. Umbes sama oli ka andmebaasi ühenduste arv. 5 tuhat ühendust jäi meie RDS eksemplari võimaluste piiresse (mida ei saa öelda kümnete tuhandete kohta). Mingil põhjusel toimusid ootamatud ühenduste arvu äkilised tõusud, kuid me ei märganud mingit seost sissetulevate päringutega.

Seekord olime kindlad, et peame leidma ja kõrvaldama probleemi allika, mitte piirduma lihtsalt taaskäivitamisega. Quay koodibaasi tehti muudatused, et piirata iga worker’i jaoks andmebaasi ühenduste arvu gevent. See number on muutunud konfigureerimise parameetriks: nüüd on võimalik seda muuta „otse”, ilma konteineri uut versiooni koostamata. Selleks, et teada saada, kui palju ühendusi tõeliselt töödeldakse, viidi läbi mitu testi staging-keskkonnas, kus määrati erinevaid väärtusi, et näha, kuidas see mõjutab koormustestimise stsenaariume. Lõppkokkuvõttes selgus, et Quay hakkab andma 502 vigu, kui ühenduste arv ületab 10 tuhat.

Me rakendasime kohe selle uue versiooni tootmisesse ja hakkasime jälgima andmebaasi ühenduste graafikut. Varem blokeerus andmebaas umbes 20 minuti pärast. Pärast 30 probleemivaba minuti möödumist tekkis meile lootus ja tunni möödudes — kindel usk. Me taastastasime kirjutust liikluse veebisaidil ja asusime postmortem-analüüsile.

Olles probleemist mööda hiilinud, me ei selgitanud selle tõelisi põhjuseid. Kinnitatud, et see ei olnud seotud mistahes muudatustega OpenShift 4.3.19, kuna sama asi juhtus ka versioonis 4.3.18, mis töötas varem Quayga ilma probleemideta.

Klastris peitis tõepoolest midagi muud.

Üksikasjalik uurimine

Quay.io on kuus aastat kasutanud vaikeseadeid andmebaasi ühendamiseks probleemideta. Mis on muutunud? Selge on, et kogu selle aja jooksul on liiklus quay.io pidevalt kasvanud. Meie puhul näis, et saavutati mingi lävend, mis käivitas ühenduste laviini. Jätkasime andmebaasi logide uurimist pärast teist riknemist, kuid ei leidnud mingeid mustreid ega ilmselgeid seoseid.

Samas tegeles SRE meeskond Quay päringute jälgimise ja teenuse üldise heaolu parendamisega. Käivitati uusi mõõdikuid ja jälgimislaudu, mis näitavad, millised Quay osad on klientide seas kõige nõutumad.

Quay.io töötas normaalselt kuni 9. juunini. Hommikul (EDT) olime taas tunnistajaks oluliselt suurenenud andmebaasi ühendustele. Seekord katkestust ei toimunud, kuna uus parameeter piiras nende arvu ja ei lubanud ületada MySQLi läbilaskevõimet. Kuid umbes poole tunni pärast märkisid paljud kasutajad quay.io aeglast töötamist. Me kogusime kiiresti kõik võimalikud andmed, kasutades lisatud jälgimistööriistu. Äkitselt ilmus muster.

Otse enne ühenduste arvu järsku tõusu saabus App Registry API-le suur hulk päringuid.. App Registry on quay.io vähe tuntud funktsioon. See võimaldab talletada selliseid asju nagu Helm chart'id ja rikkalike (rich) metaandmetega konteinerid. Enamik quay.io kasutajatest ei kasuta seda funktsiooni, kuid seda kasutavad aktiivselt Red Hat OpenShift. OpenShifti osa olev OperatorHub salvestab kõik operaatorid App Registry's. Need operaatorid moodustavad aluse OpenShifti töökoormuste ökosüsteemile ja partneritele suunatud operatsioonimudeli (teise päeva operatsioonide raames, Day 2).

Iga OpenShift 4 klaster kasutab sisseehitatud OperatorHub’ist operaatorite haldureid, et avaldada installimiseks saadaval olevate operaatorite katalooge ja pakkuda juba installitud operaatoritele uuendusi. OpenShift 4 populaarsuse kasvades on maailma kõikjal suurenenud ka klastrite arv. Igaüks neist klastritest laadib operaatorite sisu, et käivitada sisseehitatud OperatorHub, kasutades quay.io sees App Registry’d tagaplaanina. Probleemi allika otsimisel jätsime tähelepanuta, et OpenShift'i järkjärguline populaarsuse kasv tõi kaasa ka koormuse ühele harva kasutatavale funktsioonile quay.io-s..

Me oleme teinud App Registry liikluse päringute analüüsi ja uurinud registri koodi. Koheselt ilmusid välja puudujäägid, mille tõttu andmebaasi päringud vormusid ebaoptimaalselt. Madala koormuse korral ei tekitanud need probleeme, kuid koormuse suurenedes sai neist probleemi allikas. App Registry-l oli kaks probleemset endpoint’i, mis ei reageerinud koormuse suurenemisele hästi: esimene andis välja kõigi pakettide loendi hoidlas, teine — tagastas kõik blob'id paketi jaoks.

Probleemide kõrvaldamine

Kogu järgmisel nädalal tegelesime App Registry koodi ja selle keskkonna optimeerimisega. Ühtlasi töötati ümber selgelt ebatõhusad SQL-päringud ja kõrvaldi pidurite kutsumised, tar (see käivitati iga blob'i väljatoomise korral), on lisatud vahemälu kõikjal, kus võimalik. Seejärel viidi läbi ulatuslik jõudluse testimine ja võrreldi App Registry töökiirus muutuste eel ja järel.

API-päringud, mis varem kestisid pool minutit, täideti nüüd millisekundite jooksul.. Järgmisel nädalal juurutati muudatused tootmisse ja sellest ajast alates töötab quay.io stabiilselt. Selle aja jooksul on esinenud mitu järsku liiklusplahvatust App Registry endpoint’il, kuid tehtud täiustused on takistanud andmebaasi töökatkestusi.

Mida me õppisime?

Selge on see, et iga teenus püüab vältida katkestusi. Meie puhul usume, et hiljutised tõrked aitasid muuta quay.io paremaks. Oleme välja toonud mõned olulised õppetunnid, mida soovime jagada:

Andmed selle kohta, kes ja kuidas teie teenust kasutab, ei ole kunagi üleliigsed.. Kuna Quay „lihtsalt töötas”, ei olnud meil kunagi vajadust aega kulutada liikluse optimeerimisele ja koormuse haldamisele. See kõik lõi vale turvatunde, et teenus suudab skaleeruda lõputult.
Kui teenus kokku kukub, on selle taastamine peamine prioriteet. Kuna Quay kannatas esmakordsel tõrkepäeval blokeeritud andmebaasi all, ei toonud meie standardsed protseduurid soovitud efekti ning me ei suutnud teenuse taastamiseks neid kasutada. See viis olukorrani, kus tuli aega kulutada analüüsimisele ja andmete kogumisele, lootes leida algpõhjus — selle asemel, et suunata kõik jõud teenuse taastamisele.
Hinnake iga teenuse funktsiooni mõju. Klientide seas ei olnud App Registry harva kasutatav ning see ei olnud meie meeskonna prioriteet. Kui toote mõned funktsioonid on peaaegu kasutamata, siis nende tõrkeid ei ilmne sageli ning arendajad lõpetavad koodi jälgimise. On lihtne langeda vale arusaama okka, et see on normaalne — kuni järsku see funktsioon satub suure sündmuse keskmesse.

Mis edasi?

Teenuse stabiilsuse tagamine ei lõppe kunagi ning me parendame seda pidevalt. Tõhusate liiklusmahtude suurenemine quay.io-l jätkub ning me mõistame, et peame tegema kõik endast oleneva, et õigustada klientide usaldust. Seetõttu töötame hetkel järgmiste ülesannete kallal:

Lugevuse replikate juurutamine andmebaasides, et aidata teenusel töödelda vastavat liiklust juhul, kui peamise RDS instantsi vahendusel tekivad probleemid.
RDS instantsi värskendamine. Praegune versioon ei ole probleem iseenesest. Pigem soovime lihtsalt kõrvaldada vale jälje (millele me läksime pärast riket); tarkvara ajakohane hoidmine aitab vältida veel üht tegurit tulevaste katkestuste korral.
Täpsem vahemälu kogu klastris. Jätkame valdkondade otsimist, kus vahemälu aitab vähendada andmebaasi koormust.
Veebirakenduste tulemüüri (WAF) lisamine, et näha, kes ja miks ühendub quay.io.
Alates järgmisest väljaandest loobuvad Red Hat OpenShift'i klastrid App Registry kasutamisest ja liikuvad konteineripiltide põhiste operaatorikataloogide (Operator Catalogs) poole, mis on saadaval quay.io.
Pikaajaline asendaja App Registry'le võib olla Open Container Initiative (OCI) artefaktide spetsifikatsioonide toimetamine. Praegu toimub see Quay natiivfunktsionaalsusena ning see on kasutajatele saadaval, kui spetsifikatsioon lõplikult heaks kiidetakse.

Kõik ülaltoodud on osa Red Hati jätkuvatest investeeringutest quay.io-sse, kui liikume väikese „start-up” vaimu oma platvormi poole, mida haldab SRE. Teame, et paljud meie kliendid sõltuvad quay.io-st igapäevases tööprotsessis (sealhulgas Red Hat!) ja püüame olla võimalikult avatud viimaste häirete ning jätkuvate pingutuste osas paremaks muutumisel.