{"id":92073,"date":"2020-08-22T19:41:56","date_gmt":"2020-08-22T17:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io"},"modified":"2020-08-22T19:41:56","modified_gmt":"2020-08-22T17:41:56","slug":"post-mortem-po-nedostupnosti-quay-io","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Quay.io katkestamise postmortem","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

M\u00e4rk. t\u00f5lge.<\/b>: augusti alguses teatas Red Hat avalikult probleemide lahendamisest, mis olid tekkinud viimastel kuudel nende teenuse kasutajatele. Quay.io<\/a><\/noindex> (millest suur osa on konteinerite piltide register, mis ettev\u00f5ttele tuli koos CoreOS'i ostmisega). \u00dcksk\u00f5ik kui huvitav see teenus teile ka poleks, on \u00f5petlik j\u00e4lgida, milliseid samme astusid ettev\u00f5tte SRE insenerid probleemi diagnoosimiseks ja lahendamiseks.<\/i><\/p>\n

\"Quay.io
\n
\n19. mai hommikul (p\u00f5hjapoolkera suveaja idas, EDT) langes quay.io teenus. Intsident m\u00f5jutas nii quay.io tarbijaid kui ka avatud l\u00e4htekoodiga projekte, mis kasutasid quay.io tarkvara kogumise ja levitamise platvormina. Red Hat hindab nii \u00fcksikute tarbijate kui ka projektide usaldust.<\/p>\n

SRE inseneride meeskond asus kohe t\u00f6\u00f6le ja p\u00fc\u00fcdis v\u00f5imalikult kiiresti Quay teenuse stabiilsust taastada. Kuid samal ajal, kui nad sellega tegelesid, kaotasid kliendid v\u00f5imaluse uusi pilte push'ida ning suudsid vaid aeg-ajalt olemasolevaid pull'ida. M\u00fcstiliselt lukustus quay.io andmebaas teenuse t\u00e4isv\u00f5imsusele skaleerimise j\u00e4rel.<\/a><\/noindex><\/p>\n

\u00abMida on muutunud?<\/b>\u00bb \u2014 see on esimene k\u00fcsimus, mida sellistes olukordades tavaliselt esitatakse. Oleme m\u00e4rganud, et just enne probleemi algust algas OpenShift Dedicated klastril (millel quay.io t\u00f6\u00f6tab) uuendamine versioonile 4.3.19. Kuna quay.io t\u00f6\u00f6tab Red Hat OpenShift Dedicated (OSD) platvormil, olid regulaarne uuendamine tavap\u00e4rane tegevus ning need ei ole kunagi probleeme p\u00f5hjustanud. Veelgi enam, viimase kuue kuu jooksul oleme mitu korda Qay klastreid uuendanud ilma igasuguste teeninduspause.<\/p>\n

Kuni p\u00fc\u00fcdsime teenuse t\u00f6\u00f6le saada, hakkasid teised insenerid ette valmistama uut OSD klastrit varasema tarkvaraversiooniga, et vajadusel saaksime k\u00f5ik selle peale v\u00e4ljastada.<\/p>\n

P\u00f5hjuse anal\u00fc\u00fcs<\/h2>\n

\nPeamine rikke s\u00fcmptom oli k\u00fcmnete tuhandete andmebaasi \u00fchenduste laviin, mis tegi MySQL instantsi praktiliselt kasutusk\u00f5lbmatuks. Seet\u00f5ttu oli probleemi diagnoosimine keerukas. Seadsime kliendi\u00fchenduste maksimaalse arvu piirangu, et aidata SRE meeskonnal probleemi hinnata. Andmebaasi liiklus ei olnud ebatavaline: tegelikult olid enamus p\u00e4ringud lugemiseks, vaid m\u00f5ned kirjutamiseks.<\/p>\n

Me \u00fcritasime samuti tuvastada mustrit andmebaasi liikluses, mis oleks v\u00f5inud selle laviini p\u00f5hjustada. Siiski ei \u00f5nnestunud logidest mingeid seadusp\u00e4rasusi leida. Oodates uue klastriga OSD 4.3.18 valmimist, j\u00e4tkasime katseid quay.io pod'e k\u00e4ivitada. Iga kord, kui klaster j\u00f5udis oma t\u00e4isv\u00f5imsusele, hangus andmebaas. See t\u00e4hendas, et oli vajalik RDS eksemplari uuesti k\u00e4ivitamine koos k\u00f5igi quay.io pod'idega.<\/p>\n

\u00d5htuks stabiliseerisime teenuse read-only re\u017eiimis ja l\u00f5ikasime v\u00e4lja enamiku mitteolulisi funktsioone (nt pr\u00fcgikoristus nimeruumis), et v\u00e4hendada andmebaasi koormust. Hangumised l\u00f5ppesid, kuid p\u00f5hjust ei suudetud leida<\/b>. Uus OSD klaster oli valmis, ja me kolisime teenuse, suunates liikluse ning j\u00e4tkates j\u00e4lgimist.<\/p>\n

Quay.io t\u00f6\u00f6tas uuel OSD-klastril stabiilselt, seet\u00f5ttu p\u00f6\u00f6rdusime tagasi andmebaasi logide juurde, kuid ei suutnud siiski avastada korrelatsiooni, mis seletaks blokeeringuid. OpenShift'i insenerid tegid koost\u00f6\u00f6d meiega, pidades silmas, kas Red Hat OpenShift 4.3.19 muudatused v\u00f5iksid Quayga probleeme tekitada. Siiski ei leitud mingeid tulemusi, katse edastada probleemi laboritingimustes ei \u00f5nnestunud<\/b>.<\/p>\n

Teine t\u00f5rge<\/h2>\n

\n28. mai, vahetult enne keskp\u00e4eva EDT, kukkus quay.io taas sama s\u00fcmptomi t\u00f5ttu: andmebaasi toimimine seiskus. Ja taas panime k\u00f5ik j\u00f5ud uurimisele. Esiteks tuli taastada teenuse toimimine. Kuid seekord RDS-i taask\u00e4ivitamine ja quay.io pod'ide uuesti k\u00e4ivitamine ei andnud tulemusi<\/b>: veel \u00fcks \u00fchenduste laviin uputas andmebaasi. Kuid miks?<\/p>\n

Quay on kirjutatud Pythonis, ja iga pod t\u00f6\u00f6tab \u00fche monoliitse konteinerina. Kogumise ajal t\u00e4idetakse konteineris mitmeid paralleelseid \u00fclesandeid. Kasutame teeki gevent<\/code> all gunicorn<\/code> veebip\u00e4ringute t\u00f6\u00f6tlemiseks. Kui Quay-le saabub p\u00e4ring (kas meie enda API kaudu v\u00f5i Docker'i API kaudu), m\u00e4\u00e4ratakse sellele gevent worker. Tavaliselt peab see worker andmebaasiga \u00fchendust v\u00f5tma. P\u00e4rast esimest t\u00f5rget avastasime, et gevent worker'id \u00fchendasid andmebaasiga, kasutades vaikeseadeid.<\/p>\n

Arvestades Quay suuri pod’e ja tuhandeid sekundis saabuvat p\u00e4ringut, oleks suur andmebaasi \u00fchenduste arv teoreetiliselt v\u00f5inud meie MySQL eksemplari \u00fcle koormata. J\u00e4lgimise kaudu selgus, et Quay t\u00f6\u00f6tleb keskmiselt 5000 p\u00e4ringut sekundis. Andmebaasi \u00fchenduste arv oli ligikaudu sama. 5000 \u00fchendust mahtus meie RDS eksemplari v\u00f5imetesse (mida ei saa \u00f6elda k\u00fcmnete tuhandete kohta). Mingil p\u00f5hjusel toimusid ootamatud \u00fchenduste arvu \u00e4kilised t\u00f5usud<\/b>, kuid me ei m\u00e4rganud mingit seost sissetulevate p\u00e4ringutega.<\/p>\n

Seekord olime kindlad, et peame leidma ja k\u00f5rvaldama probleemi allika, mitte piirduma lihtsalt taask\u00e4ivitamisega. Quay koodibaasi tehti muudatused, mis piirasid andmebaasi \u00fchenduste arvu iga worker’i jaoks.<\/b> gevent. See number on muutunud konfigureerimise parameetriks: n\u00fc\u00fcd on v\u00f5imalik seda muuta \u201eotse\u201d, ilma konteineri uut versiooni koostamata. Selleks, et teada saada, kui palju \u00fchendusi t\u00f5eliselt t\u00f6\u00f6deldakse, viidi l\u00e4bi mitu testi staging-keskkonnas, kus m\u00e4\u00e4rati erinevaid v\u00e4\u00e4rtusi, et n\u00e4ha, kuidas see m\u00f5jutab koormustestimise stsenaariume. L\u00f5ppkokkuv\u00f5ttes selgus, et Quay hakkab andma 502 vigu, kui \u00fchenduste arv \u00fcletab 10 tuhat.<\/b><\/p>\n

Me rakendasime kohe selle uue versiooni tootmisesse ja hakkasime j\u00e4lgima andmebaasi \u00fchenduste graafikut. Varem blokeerus andmebaas umbes 20 minuti p\u00e4rast. P\u00e4rast 30 probleemivaba minuti m\u00f6\u00f6dumist tekkis meile lootus ja tunni m\u00f6\u00f6dudes \u2014 kindel usk. Me taastastasime kirjutust liikluse veebisaidil ja asusime postmortem-anal\u00fc\u00fcsile.<\/p>\n

Olles probleemist m\u00f6\u00f6da hiilinud, me ei selgitanud selle t\u00f5elisi p\u00f5hjuseid<\/b>. Kinnitatud, et see ei olnud seotud mistahes muudatustega OpenShift 4.3.19, kuna sama asi juhtus ka versioonis 4.3.18, mis t\u00f6\u00f6tas varem Quayga ilma probleemideta.<\/p>\n

Klastris peitis t\u00f5epoolest midagi muud.<\/p>\n

\u00dcksikasjalik uurimine<\/h2>\n

\nQuay.io on kuus aastat kasutanud vaikeseadeid andmebaasi \u00fchendamiseks probleemideta. Mis on muutunud? Selge on, et kogu selle aja jooksul on liiklus quay.io pidevalt kasvanud. Meie puhul n\u00e4is, et saavutati mingi l\u00e4vend, mis k\u00e4ivitas \u00fchenduste laviini. J\u00e4tkasime andmebaasi logide uurimist p\u00e4rast teist riknemist, kuid ei leidnud mingeid mustreid ega ilmselgeid seoseid.<\/p>\n

Samas tegeles SRE meeskond Quay p\u00e4ringute j\u00e4lgimise ja teenuse \u00fcldise heaolu parendamisega. K\u00e4ivitati uusi m\u00f5\u00f5dikuid ja j\u00e4lgimislaudu<\/b>, mis n\u00e4itavad, millised Quay osad on klientide seas k\u00f5ige n\u00f5utumad.<\/p>\n

Quay.io t\u00f6\u00f6tas normaalselt kuni 9. juunini. Hommikul (EDT) olime taas tunnistajaks oluliselt suurenenud andmebaasi \u00fchendustele. Seekord katkestust ei toimunud<\/b>, kuna uus parameeter piiras nende arvu ja ei lubanud \u00fcletada MySQLi l\u00e4bilaskev\u00f5imet. Kuid umbes poole tunni p\u00e4rast m\u00e4rkisid paljud kasutajad quay.io aeglast t\u00f6\u00f6tamist. Me kogusime kiiresti k\u00f5ik v\u00f5imalikud andmed, kasutades lisatud j\u00e4lgimist\u00f6\u00f6riistu. \u00c4kitselt ilmus muster.<\/p>\n

Otse enne \u00fchenduste arvu j\u00e4rsku t\u00f5usu saabus App Registry API-le suur hulk p\u00e4ringuid.<\/b>. App Registry on quay.io v\u00e4he tuntud funktsioon. See v\u00f5imaldab 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\u00f5ik operaatorid App Registry's. Need operaatorid moodustavad aluse OpenShifti t\u00f6\u00f6koormuste \u00f6kos\u00fcsteemile ja partneritele suunatud operatsioonimudeli (teise p\u00e4eva operatsioonide raames, Day 2).<\/p>\n

Iga OpenShift 4 klaster kasutab sisseehitatud OperatorHub'ist operaatorite avaldamiseks operaatorite katalooge, mis on saadaval installimiseks, ja pakub uuendusi juba installitud operaatoritele. OpenShift 4 populaarsuse kasvu t\u00f5ttu on kasvanud ka klastrite arv \u00fcle kogu maailma. Iga klaster laadib operaatorite sisu, et k\u00e4ivitada sisseehitatud OperatorHub, kasutades quay.io-s App Registry't tagaplaanina. Probleemi allika otsimisel j\u00e4tsime t\u00e4helepanuta, et OpenShift'i j\u00e4rkj\u00e4rguline populaarsuse kasv t\u00f5i kaasa ka koormuse \u00fchele harva kasutatavale funktsioonile quay.io-s.<\/b>.<\/p>\n

Me tegime teatud anal\u00fc\u00fcsi App Registry p\u00e4ringute liiklusest ja vaatasime registri koodi. Koheselt ilmusid v\u00e4lja puudused, mis p\u00f5hjustasid, et p\u00e4ringud andmebaasi moodustusid mitteoptimaalselt. Madala koormuse korral ei tekkinud neist probleeme, kuid koormuse suurenedes muutusid need probleemide allikaks. App Registry-l oli kaks probleemset l\u00f5pp-punkti, mis ei reageerinud h\u00e4sti koormuse suurenemisele: esimene v\u00e4ljastas k\u00f5ik paketid repos, teine tagastas k\u00f5ik blob'id paketi jaoks.<\/p>\n

Probleemide k\u00f5rvaldamine<\/h2>\n

\nKogu j\u00e4rgmisel n\u00e4dalal tegelesime App Registry koodi ja selle keskkonna optimeerimisega. \u00dchtlasi t\u00f6\u00f6tati \u00fcmber selgelt ebat\u00f5husad SQL-p\u00e4ringud ja k\u00f5rvaldi pidurite kutsumised, tar<\/code> (mis k\u00e4ivitati iga blob'i v\u00e4ljav\u00f5tte korral), lisati vahem\u00e4lu k\u00f5igis v\u00f5imalikes kohtades. Seej\u00e4rel viidi l\u00e4bi ulatuslik j\u00f5udlustestimine ja v\u00f5rreldi App Registry t\u00f6\u00f6kiirus enne ja p\u00e4rast muudatusi.<\/p>\n

API-p\u00e4ringud, mis varem kestisid pool minutit, t\u00e4ideti n\u00fc\u00fcd millisekundite jooksul.<\/b>J\u00e4rgmise n\u00e4dala jooksul juurutati muudatused tootmisse ja alates sellest ajast on quay.io t\u00f6\u00f6tanud stabiilselt. Selle aja jooksul on m\u00e4rgatud mitmeid teravaid liikluse t\u00f5use App Registry l\u00f5pp-punktis, kuid tehtud t\u00e4iustused on \u00e4ra hoidnud andmebaasi katkestusi.<\/p>\n

Mida me \u00f5ppisime?<\/h2>\n

\nSelge on see, et iga teenus p\u00fc\u00fcab v\u00e4ltida katkestusi. Meie puhul usume, et hiljutised t\u00f5rked aitasid muuta quay.io paremaks. Oleme v\u00e4lja toonud m\u00f5ned olulised \u00f5ppetunnid, mida soovime jagada:<\/p>\n

    \n
  1. Andmed selle kohta, kes ja kuidas teie teenust kasutab, ei ole kunagi \u00fcleliigsed.<\/b>. Kuna Quay \u201elihtsalt t\u00f6\u00f6tas\u201d, ei olnud meil kunagi vajadust aega kulutada liikluse optimeerimisele ja koormuse haldamisele. See k\u00f5ik l\u00f5i vale turvatunde, et teenus suudab skaleeruda l\u00f5putult.<\/li>\n
  2. Kui teenus kokku kukub, on selle taastamine peamine prioriteet<\/b>. Kuna Quay kannatas esmakordsel t\u00f5rkep\u00e4eval 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\u00fc\u00fcsimisele ja andmete kogumisele, lootes leida algp\u00f5hjus \u2014 selle asemel, et suunata k\u00f5ik j\u00f5ud teenuse taastamisele.<\/li>\n
  3. Hinnake iga teenuse funktsiooni m\u00f5ju<\/b>. Klientide seas ei olnud App Registry harva kasutatav ning see ei olnud meie meeskonna prioriteet. Kui toote m\u00f5ned funktsioonid on peaaegu kasutamata, siis nende t\u00f5rkeid ei ilmne sageli ning arendajad l\u00f5petavad koodi j\u00e4lgimise. On lihtne langeda vale arusaama okka, et see on normaalne \u2014 kuni j\u00e4rsku see funktsioon satub suure s\u00fcndmuse keskmesse.<\/li>\n<\/ol>\n

    <\/p>\n

    Mis edasi?<\/h2>\n

    \nTeenuse stabiilsuse tagamine ei l\u00f5ppe kunagi ning me parendame seda pidevalt. T\u00f5husate liiklusmahtude suurenemine quay.io-l j\u00e4tkub ning me m\u00f5istame, et peame tegema k\u00f5ik endast oleneva, et \u00f5igustada klientide usaldust. Seet\u00f5ttu t\u00f6\u00f6tame hetkel j\u00e4rgmiste \u00fclesannete kallal:<\/p>\n

      \n
    1. Lugevuse replikate juurutamine andmebaasides, et aidata teenusel t\u00f6\u00f6delda vastavat liiklust juhul, kui peamise RDS instantsi vahendusel tekivad probleemid.<\/li>\n
    2. RDS instantsi v\u00e4rskendamine. Praegune versioon ei ole probleem iseenesest. Pigem soovime lihtsalt k\u00f5rvaldada vale j\u00e4lje (millele me l\u00e4ksime p\u00e4rast riket); tarkvara ajakohane hoidmine aitab v\u00e4ltida veel \u00fcht tegurit tulevaste katkestuste korral.<\/li>\n
    3. T\u00e4psem vahem\u00e4lu kogu klastris. J\u00e4tkame valdkondade otsimist, kus vahem\u00e4lu aitab v\u00e4hendada andmebaasi koormust.<\/li>\n
    4. Veebirakenduste tulem\u00fc\u00fcri (WAF) lisamine, et n\u00e4ha, kes ja miks \u00fchendub quay.io.<\/li>\n
    5. Alates j\u00e4rgmisest v\u00e4ljaandest loobuvad Red Hat OpenShift'i klastrid App Registry kasutamisest ja liikuvad konteineripiltide p\u00f5histe operaatorikataloogide (Operator Catalogs) poole, mis on saadaval quay.io.<\/li>\n
    6. Pikaajaline asendaja App Registry'le v\u00f5ib olla Open Container Initiative (OCI) artefaktide spetsifikatsioonide toimetamine. Praegu toimub see Quay natiivfunktsionaalsusena ning see on kasutajatele saadaval, kui spetsifikatsioon l\u00f5plikult heaks kiidetakse.<\/li>\n<\/ol>\n

      \nK\u00f5ik \u00fclaltoodud on osa Red Hati j\u00e4tkuvatest investeeringutest quay.io-sse, kui liikume v\u00e4ikese \u201estart-up\u201d vaimu oma platvormi poole, mida haldab SRE. Teame, et paljud meie kliendid s\u00f5ltuvad quay.io-st igap\u00e4evases t\u00f6\u00f6protsessis (sealhulgas Red Hat!) ja p\u00fc\u00fcame olla v\u00f5imalikult avatud viimaste h\u00e4irete ning j\u00e4tkuvate pingutuste osas paremaks muutumisel.<\/p>\n

      P.S. t\u00f5lkija m\u00e4rkused<\/h2>\n

      \nLugege ka meie blogist:<\/p>\n