Märge. tõlge: augusti alguses rääkis Red Hat avalikult ligipääsetavusprobleemide lahendamisest, millega tema teenuse kasutajad olid eelnevatel kuudel kokku puutunud (see põhineb konteinerpiltide registril, mille ettevõte sai koos CoreOS-i ostmisega). Olenemata teie huvist selle teenuse kui sellise vastu, on ettevõtte SRE inseneride teekond õnnetuse põhjuste diagnoosimiseks ja kõrvaldamiseks õpetlik.
19. mail varahommikul (Eastern Daylight Time, EDT) kukkus teenus quay.io alla. Õnnetus puudutas nii quay.io tarbijaid kui ka avatud lähtekoodiga projekte, mis kasutasid quay.io-d tarkvara koostamise ja levitamise platvormina. Red Hat hindab mõlema usaldust.
SRE inseneride meeskond sekkus kohe ja üritas Quay teenust võimalikult kiiresti stabiliseerida. Kuid selle tegemise ajal kaotasid kliendid võimaluse uusi pilte lükata ja ainult aeg-ajalt said nad olemasolevaid pilte tõmmata. Mingil teadmata põhjusel blokeeriti andmebaas quay.io pärast teenuse täisvõimsusele skaleerimist.
«Mis on muutunud?“ – see on esimene küsimus, mida sellistel puhkudel tavaliselt küsitakse. Märkasime, et vahetult enne probleemi alustati OpenShift Dedicated klastri (mis käitab quay.io) värskendamist versioonile 4.3.19. Kuna quay.io töötab Red Hat OpenShift Dedicatedil (OSD), olid regulaarsed värskendused rutiinsed ega põhjustanud kunagi probleeme. Lisaks oleme viimase kuue kuu jooksul Quay klastreid mitu korda uuendanud ilma teenust katkestamata.
Sel ajal, kui proovisime teenust taastada, hakkasid teised insenerid tarkvara eelmise versiooniga ette valmistama uut OSD-klastrit, et kui midagi peaks juhtuma, saaksid nad kõik sellesse installida.
Algpõhjuse analüüs
Rikke peamiseks sümptomiks oli kümnete tuhandete andmebaasiühenduste laviin, mis muutis MySQL-i eksemplari tõhusalt töövõimetuks. See muutis probleemi diagnoosimise keeruliseks. Oleme seadnud piirangu klientide maksimaalsele ühenduste arvule, et aidata SRE meeskonnal probleemi hinnata. Me ei märganud ebatavalist liiklust andmebaasis: tegelikult loeti enamik päringuid läbi ja ainult mõned kirjutati.
Samuti proovisime tuvastada andmebaasi liikluses mustrit, mis võib selle laviini põhjustada. Samas ei leidnud me palkidest ühtegi mustrit. Uue OSD 4.3.18-ga klastri valmimist oodates jätkasime quay.io podide käivitamist. Iga kord, kui klaster saavutas täisvõimsuse, andmebaas hangus. See tähendas, et lisaks kõikidele quay.io kaustadele oli vaja taaskäivitada ka RDS-i eksemplar.
Õhtuks stabiliseerisime teenuse kirjutuskaitstud režiimis ja keelasime andmebaasi koormuse vähendamiseks võimalikult paljud ebaolulised funktsioonid (näiteks nimeruumi prügikoristus). Külmumised on peatunud kuid põhjust ei leitud kunagi. Uus OSD-klaster oli valmis ja me migreerisime teenuse, ühendasime liikluse ja jätkasime jälgimist.
Quay.io töötas uuel OSD-klastril stabiilselt, nii et pöördusime tagasi andmebaasi logide juurde, kuid ei leidnud korrelatsiooni, mis ummistusi seletaks. OpenShifti insenerid tegid meiega koostööd, et mõista, kas Red Hat OpenShift 4.3.19 muudatused võivad Quayga probleeme põhjustada. Midagi aga ei leitud ja Laboratoorsetes tingimustes ei olnud võimalik probleemi taastoota.
Teine ebaõnnestumine
28. mail, veidi enne keskpäeva EDT, kukkus quay.io uuesti kokku sama sümptomiga: andmebaas oli blokeeritud. Ja jälle andsime kõik oma jõupingutused uurimisele. Kõigepealt oli vaja teenus taastada. Kuid seekord RDS-i taaskäivitamine ja quay.io kaustade taaskäivitamine ei teinud midagi: järjekordne seoste laviin on baasi üle ujutanud. Aga miks?
Quay on kirjutatud Pythonis ja iga pod toimib ühe monoliitse konteinerina. Konteiner käitab korraga palju paralleelseid ülesandeid. Kasutame raamatukogu gevent alla gunicorn veebipäringute töötlemiseks. Kui taotlus jõuab Quaysse (meie oma API või Dockeri API kaudu), määratakse sellele gevent-töötaja. Tavaliselt peaks see töötaja andmebaasiga ühendust võtma. Pärast esimest tõrget avastasime, et gevent-töötajad loovad andmebaasiga ühenduse vaikeseadeid kasutades.
Arvestades Quay kaustade märkimisväärset arvu ja tuhandeid sissetulevaid päringuid sekundis, võib suur hulk andmebaasiühendusi teoreetiliselt ületada MySQL-i eksemplari. Tänu monitooringule oli teada, et Quay töötleb keskmiselt 5 tuhat päringut sekundis. Ühenduste arv andmebaasiga oli ligikaudu sama. 5 tuhat ühendust jäi meie RDS-i eksemplari võimaluste piiresse (mida ei saa öelda kümnete tuhandete kohta). Millegipärast tekkis ühenduste arvus ootamatuid hüppeidaga me ei märganud mingit seost sissetulevate päringutega.
Seekord otsustasime leida ja kõrvaldada probleemi allika ning mitte piirduda taaskäivitusega. Quay koodibaasi tehti muudatusi, et piirata iga töötaja jaoks andmebaasiga ühenduste arvu gevent. Sellest numbrist sai konfiguratsioonis parameeter: seda sai võimalikuks muuta käigu pealt ilma uut konteineripilti ehitamata. Et teada saada, kui palju ühendusi saaks reaalselt hallata, viisime läbi mitu testimist etapikeskkonnas, määrates erinevad väärtused, et näha, kuidas see koormustestimise stsenaariume mõjutab. Selle tulemusena avastati, et Kai hakkab viskama 502 viga, kui ühenduste arv ületab 10 tuhande piiri.
Võtsime selle uue versiooni kohe tootmisse ja hakkasime jälgima andmebaasi ühenduse ajakava. Varem lukustati alus umbes 20 minuti pärast. Pärast 30 probleemivaba minutit oli meil lootus ja tund hiljem oli meil enesekindlus. Taastasime saidi liikluse ja alustasime surmajärgset analüüsi.
Olles suutnud blokeerimiseni viinud probleemist mööda minna, me ei ole välja selgitanud selle tegelikke põhjuseid. Kinnitati, et see ei ole seotud OpenShift 4.3.19 muudatustega, kuna sama juhtus versiooniga 4.3.18, mis varem töötas Quayga probleemideta.
Klastris varitses selgelt midagi muud.
Üksikasjalik uuring
Quay.io kasutas vaikesätteid andmebaasiga ühenduse loomiseks kuus aastat probleemideta. Mis muutus? On selge, et kogu selle aja on quay.io liiklus pidevalt kasvanud. Meie puhul näis, et mingi läviväärtus oli saavutatud, mis oli ühenduste laviini käivitajaks. Jätkasime pärast teist ebaõnnestumist andmebaasi logide uurimist, kuid ei leidnud mustreid ega ilmseid seoseid.
Vahepeal on SRE meeskond töötanud Quay taotluse vaadeldavuse ja üldise teenuse tervise parandamise nimel. Kasutusele on võetud uued mõõdikud ja armatuurlauad, mis näitab, millised kai osad on klientide poolt kõige nõudlikumad.
Quay.io töötas hästi kuni 9. juunini. Täna hommikul (EDT) nägime taas oluliselt andmebaasiühenduste arvu kasvu. Seekord seisakuid ei olnud, kuna uus parameeter piiras nende arvu ega võimaldanud ületada MySQL-i läbilaskevõimet. Kuid umbes poole tunni jooksul märkisid paljud kasutajad quay.io aeglast jõudlust. Lisatud jälgimistööriistade abil kogusime kiiresti kõik võimalikud andmed. Järsku tekkis muster.
Vahetult enne ühenduste suurenemist tehti rakenduste registri API-le palju taotlusi. Rakenduste register on quay.io vähetuntud funktsioon. See võimaldab salvestada selliseid asju nagu Helmi diagrammid ja rikkalike metaandmetega konteinerid. Enamik quay.io kasutajaid selle funktsiooniga ei tööta, kuid Red Hat OpenShift kasutab seda aktiivselt. OperatorHub OpenShifti osana salvestab kõik operaatorid rakenduste registrisse. Need operaatorid moodustavad OpenShifti töökoormuse ökosüsteemi ja partnerikeskse töömudeli aluse (2. päeva toimingud).
Iga OpenShift 4 klaster kasutab sisseehitatud OperatorHubi operaatoreid, et avaldada installimiseks saadaolevate operaatorite kataloog ja pakkuda värskendusi juba installitud operaatoritele. OpenShift 4 populaarsuse kasvuga on kasvanud ka sellel olevate klastrite arv kogu maailmas. Kõik need klastrid laadivad alla operaatori sisu, et käitada sisseehitatud OperatorHubi, kasutades taustaprogrammina quay.io sees olevat rakenduste registrit. Probleemi allikat otsides jätsime kahe silma vahele asjaolu, et OpenShifti populaarsuse järkjärgulise kasvamisega suurenes ka ühe harva kasutatava quay.io funktsiooni koormus..
Analüüsisime rakenduste registri päringu liiklust ja vaatasime registrikoodi. Kohe ilmnesid puudused, mille tõttu ei moodustatud andmebaasi päringuid optimaalselt. Kui koormus oli väike, ei tekitanud need häda, aga koormuse kasvades muutusid need probleemide allikaks. Rakenduste registril osutus kaks probleemset lõpp-punkti, mis ei reageerinud kasvavale koormusele hästi: esimene andis kõigi hoidlas olevate pakettide loendi, teine tagastas kõik paketi plekid.
Põhjuste kõrvaldamine
Järgmise nädala jooksul optimeerisime rakenduste registri koodi ja selle keskkonda. Ilmselgelt ebaefektiivsed SQL-päringud töötati ümber ja tarbetud käsukutsed kõrvaldati tar (seda käitati iga kord, kui plekid laaditi), lisati vahemälu, kus võimalik. Seejärel viisime läbi ulatuslikud jõudlustestid ja võrdlesime rakenduste registri kiirust enne ja pärast muudatusi.
API päringud, mis varem kestsid kuni pool minutit, täidetakse nüüd millisekunditega. Järgmisel nädalal juurutasime muudatused tootmisse ja sellest ajast on quay.io töötanud stabiilselt. Selle aja jooksul oli rakenduste registri lõpp-punkti liikluses mitu järsku hüpet, kuid tehtud täiustused hoidsid ära andmebaasi katkestused.
Mida me õppisime?
On selge, et iga teenus püüab seisakuid vältida. Meie puhul usume, et hiljutised katkestused on aidanud quay.io paremaks muuta. Oleme saanud mõned olulised õppetunnid, mida tahaksime jagada:
- Andmed selle kohta, kes ja kuidas teie teenust kasutavad, ei ole kunagi üleliigsed. Kuna Quay lihtsalt töötas, ei pidanud me kunagi kulutama aega liikluse optimeerimisele ja koormuse haldamisele. Kõik see tekitas vale turvatunde, mida teenus võis lõputult laiendada.
- Kui teenus katkeb, selle taaskäivitamine on esmatähtis.. Kuna Quay kannatas esimese katkestuse ajal jätkuvalt lukustatud andmebaasi all, ei andnud meie standardprotseduurid soovitud tulemust ja me ei saanud nende abil teenust taastada. See tõi kaasa olukorra, kus algpõhjus leidmise lootuses tuli kulutada aega andmete analüüsimisele ja kogumisele – selle asemel, et koondada kõik jõupingutused funktsionaalsuse taastamisele.
- Hinnake iga teenusefunktsiooni mõju. Kliendid kasutasid rakenduste registrit harva, seega polnud see meie meeskonna jaoks prioriteet. Kui mõnda toote funktsiooni vaevu kasutatakse, ilmnevad nende vead harva ja arendajad lõpetavad koodi jälgimise. Lihtne on langeda väärarusaama ohvriks, et see peabki nii olema – kuni äkki satub see funktsioon mõne suure intsidendi keskmesse.
Mis edasi?
Töö teenuse stabiilsuse tagamiseks ei peatu kunagi ja täiustame seda pidevalt. Kuna liiklusmahud saidil quay.io kasvavad jätkuvalt, mõistame, et oleme kohustatud tegema kõik endast oleneva, et täita oma klientide usaldust. Seetõttu tegeleme praegu järgmiste ülesannetega:
- Juurutage kirjutuskaitstud andmebaasi koopiad, et aidata teenusel käsitleda sobivat liiklust esmase RDS-i eksemplari probleemide korral.
- RDS-i eksemplari värskendamine. Praegune versioon iseenesest pole probleem. Pigem tahame lihtsalt eemaldada valejälje (mida me ebaõnnestumise ajal järgisime); Tarkvara ajakohasena hoidmine välistab tulevaste katkestuste korral veel ühe teguri.
- Täiendav vahemälu kogu klastri ulatuses. Jätkame piirkondade otsimist, kus vahemällu salvestamine võib andmebaasi koormust vähendada.
- Veebirakenduse tulemüüri (WAF) lisamine, et näha, kes ja miks ühenduse loovad saidiga quay.io.
- Alates järgmisest väljalasest loobuvad Red Hat OpenShifti klastrid rakenduste registrist operaatorikataloogide kasuks, mis põhinevad saidil quay.io saadaolevatel konteineripiltidel.
- Rakenduste registri pikaajaline asendus võib toetada Open Container Initiative (OCI) artefakti spetsifikatsioone. Seda rakendatakse praegu Quay natiivse funktsioonina ja see on kasutajatele saadaval, kui spetsifikatsioon ise on lõplikult vormistatud.
Kõik ülaltoodu on osa Red Hati käimasolevatest investeeringutest quay.io-sse, kuna liigume väikesest "startup-stiilis" meeskonnast küpsele SRE-põhisele platvormile. Teame, et paljud meie kliendid toetuvad oma igapäevatöös quay.io-le (sh Red Hat!) ja püüame olla võimalikult läbipaistvad viimaste katkestuste ja käimasolevate täiustamispüüdluste osas.
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «'.
Allikas: www.habr.com