Shënim. përkth.: në fillim të gushtit, Red Hat foli publikisht për zgjidhjen e problemeve të aksesueshmërisë që përdoruesit e shërbimit të saj kishin hasur në muajt e kaluar (bazohet në një regjistër për imazhet e kontejnerëve, të cilat kompania i mori së bashku me blerjen e CoreOS). Pavarësisht nga interesimi juaj për këtë shërbim si i tillë, rruga që kanë marrë inxhinierët SRE të kompanisë për të diagnostikuar dhe eliminuar shkaqet e aksidentit është udhëzuese.
Më 19 maj, herët në mëngjes (Eastern Daylight Time, EDT), shërbimi quay.io u rrëzua. Aksidenti preku si konsumatorët e quay.io ashtu edhe projektet me kod të hapur duke përdorur quay.io si një platformë për ndërtimin dhe shpërndarjen e softuerit. Red Hat vlerëson besimin e të dyve.
Një ekip inxhinierësh të SRE u përfshi menjëherë dhe u përpoq të stabilizonte shërbimin e Quay sa më shpejt të ishte e mundur. Megjithatë, ndërsa ata po e bënin këtë, klientët humbën aftësinë për të shtyrë imazhe të reja dhe vetëm herë pas here ata ishin në gjendje të tërheqin ato ekzistuese. Për një arsye të panjohur, baza e të dhënave quay.io u bllokua pas shkallëzimit të shërbimit në kapacitet të plotë.
«Whatfarë ka ndryshuar?“- kjo është pyetja e parë që bëhet zakonisht në raste të tilla. Ne vumë re se pak para këtij problemi, grupi i Dedikuar OpenShift (i cili drejton quay.io) filloi të përditësohej në versionin 4.3.19. Meqenëse quay.io funksionon në Red Hat OpenShift Dedicated (OSD), përditësimet e rregullta ishin rutinë dhe nuk shkaktuan kurrë probleme. Për më tepër, gjatë gjashtë muajve të kaluar, ne kemi përmirësuar disa herë grupet e Quay pa asnjë ndërprerje në shërbim.
Ndërsa po përpiqeshim të rivendosnim shërbimin, inxhinierë të tjerë filluan të përgatisnin një grup të ri OSD me versionin e mëparshëm të softuerit, në mënyrë që nëse ndodh diçka, ata të mund të vendosnin gjithçka në të.
Analiza e shkakut rrënjësor
Simptoma kryesore e dështimit ishte një ortek prej dhjetëra mijëra lidhjesh të bazës së të dhënave, të cilat e bënë shembullin MySQL efektivisht të pafunksionueshëm. Kjo e bëri të vështirë diagnostikimin e problemit. Ne kemi vendosur një kufi në numrin maksimal të lidhjeve nga klientët për të ndihmuar ekipin SRE të vlerësojë çështjen. Ne nuk vumë re ndonjë trafik të pazakontë në bazën e të dhënave: në fakt, shumica e kërkesave u lexuan dhe vetëm disa u shkruan.
Ne gjithashtu u përpoqëm të identifikonim një model në trafikun e bazës së të dhënave që mund të shkaktonte këtë ortek. Megjithatë, nuk mundëm të gjenim asnjë model në regjistrat. Ndërsa prisnim që grupi i ri me OSD 4.3.18 të ishte gati, ne vazhduam të përpiqeshim të lëshonim pods quay.io. Sa herë që grupi arrinte kapacitetin e plotë, baza e të dhënave ngrinte. Kjo do të thoshte se ishte e nevojshme të rifillohej shembulli RDS përveç të gjitha pod-ve quay.io.
Deri në mbrëmje, e stabilizuam shërbimin në modalitetin vetëm për lexim dhe çaktivizuam sa më shumë funksione jo thelbësore (për shembull, grumbullimi i mbeturinave të hapësirës së emrave) për të zvogëluar ngarkesën në bazën e të dhënave. Ngrirjet janë ndalur por arsyeja nuk u gjet kurrë. Grupi i ri OSD ishte gati dhe ne migruam shërbimin, lidhëm trafikun dhe vazhduam monitorimin.
Quay.io punoi në mënyrë të qëndrueshme në grupin e ri OSD, kështu që u kthyem te regjistrat e bazës së të dhënave, por nuk gjetëm një korrelacion që do të shpjegonte bllokimet. Inxhinierët e OpenShift punuan me ne për të kuptuar nëse ndryshimet në Red Hat OpenShift 4.3.19 mund të shkaktojnë probleme me Quay. Megjithatë, asgjë nuk u gjet, dhe Nuk ishte e mundur të riprodhohej problemi në kushte laboratorike.
Dështimi i dytë
Më 28 maj, pak para mesditës EDT, quay.io u rrëzua përsëri me të njëjtën simptomë: baza e të dhënave u bllokua. Dhe përsëri ne hodhëm të gjitha përpjekjet tona në hetim. Para së gjithash, ishte e nevojshme të rivendosej shërbimi. Megjithatë këtë herë rindezja e RDS dhe rinisja e pods quay.io nuk bëri asgjë: një tjetër ortek lidhjesh ka pushtuar bazën. Por pse?
Quay është shkruar në Python dhe çdo pod funksionon si një enë e vetme monolit. Koha e funksionimit të kontejnerit kryen shumë detyra paralele në të njëjtën kohë. Ne përdorim bibliotekën gevent nën gunicorn për të përpunuar kërkesat në ueb. Kur një kërkesë vjen në Quay (nëpërmjet API-së sonë, ose nëpërmjet API-së së Docker), asaj i caktohet një punëtor gevent. Zakonisht ky punonjës duhet të kontaktojë bazën e të dhënave. Pas dështimit të parë, ne zbuluam se punëtorët e gevent po lidheshin me bazën e të dhënave duke përdorur cilësimet e paracaktuara.
Duke pasur parasysh numrin e konsiderueshëm të pods Quay dhe mijëra kërkesave hyrëse në sekondë, një numër i madh i lidhjeve të bazës së të dhënave teorikisht mund të mposhtin shembullin MySQL. Falë monitorimit u bë e ditur se Quay përpunon mesatarisht 5 mijë kërkesa në sekondë. Numri i lidhjeve me bazën e të dhënave ishte afërsisht i njëjtë. 5 mijë lidhje ishin brenda mundësive të shembullit tonë RDS (që nuk mund të thuhet për dhjetëra mijëra). Për disa arsye pati rritje të papritura në numrin e lidhjeve, megjithatë, ne nuk kemi vërejtur ndonjë korrelacion me kërkesat e ardhura.
Këtë herë ne ishim të vendosur të gjenim dhe eliminonim burimin e problemit dhe të mos kufizoheshim në një rindezje. Në bazën e kodeve Quay u bënë ndryshime për të kufizuar numrin e lidhjeve me bazën e të dhënave për çdo punonjës gevent. Ky numër u bë një parametër në konfigurim: u bë e mundur ta ndryshoni atë në fluturim pa ndërtuar një imazh të ri të kontejnerit. Për të zbuluar se sa lidhje mund të trajtoheshin në mënyrë reale, ne kryem disa teste në një mjedis vendosjeje, duke vendosur vlera të ndryshme për të parë se si kjo do të ndikonte në skenarët e testimit të ngarkesës. Si rezultat, u zbulua se Quay fillon të hedhë 502 gabime kur numri i lidhjeve kalon 10 mijë.
Ne e vendosëm menjëherë këtë version të ri në prodhim dhe filluam monitorimin e orarit të lidhjes së bazës së të dhënave. Në të kaluarën, baza u mbyll pas rreth 20 minutash. Pas 30 minutash pa probleme kishim shpresë dhe një orë më vonë kishim besim. Ne rivendosëm trafikun në vend dhe filluam analizën pas vdekjes.
Duke arritur të anashkalojë problemin që çon në bllokim, nuk i kemi zbuluar arsyet e vërteta. U konfirmua se nuk ka të bëjë me ndonjë ndryshim në OpenShift 4.3.19, pasi e njëjta gjë ka ndodhur në versionin 4.3.18, i cili më parë ka punuar me Quay pa asnjë problem.
Ishte e qartë se diçka tjetër fshihej në grup.
Studim i detajuar
Quay.io përdori cilësimet e paracaktuara për t'u lidhur me bazën e të dhënave për gjashtë vjet pa asnjë problem. Çfarë ndryshoi? Është e qartë se gjatë gjithë kësaj kohe trafiku në quay.io është rritur në mënyrë të qëndrueshme. Në rastin tonë, dukej sikur ishte arritur një vlerë pragu, e cila shërbeu si shkas për një ortek lidhjesh. Ne vazhduam të studionim regjistrat e bazës së të dhënave pas dështimit të dytë, por nuk gjetëm ndonjë model ose marrëdhënie të dukshme.
Ndërkohë, ekipi i SRE-së ka punuar për përmirësimin e vëzhgimit të kërkesave të Quay dhe shëndetin e përgjithshëm të shërbimit. Janë vendosur metrika dhe tabela të reja, duke treguar se cilat pjesë të Kalasë janë më të kërkuara nga klientët.
Quay.io funksionoi mirë deri më 9 qershor. Këtë mëngjes (EDT) përsëri pamë një rritje të ndjeshme në numrin e lidhjeve të bazës së të dhënave. Këtë herë nuk kishte kohë joproduktive, meqenëse parametri i ri kufizoi numrin e tyre dhe nuk i lejonte të kalonin xhiron e MySQL. Sidoqoftë, për rreth gjysmë ore, shumë përdorues vunë re performancë të ngadaltë të quay.io. Ne mblodhëm shpejt të gjitha të dhënat e mundshme duke përdorur mjetet e shtuara të monitorimit. Papritur u shfaq një model.
Pak para rritjes së lidhjeve, një numër i madh kërkesash u bënë në API të Regjistrit të Aplikacioneve. Regjistri i aplikacioneve është një veçori pak e njohur e quay.io. Kjo ju lejon të ruani gjëra të tilla si diagramet Helm dhe kontejnerët me meta të dhëna të pasura. Shumica e përdoruesve të quay.io nuk punojnë me këtë veçori, por Red Hat OpenShift e përdor atë në mënyrë aktive. OperatorHub si pjesë e OpenShift ruan të gjithë operatorët në Regjistrin e aplikacioneve. Këta operatorë formojnë bazën për ekosistemin e ngarkesës së punës OpenShift dhe modelin e funksionimit me në qendër partnerin (operacionet e ditës 2).
Çdo grup OpenShift 4 përdor operatorë nga OperatorHub i integruar për të publikuar një katalog të operatorëve të disponueshëm për instalim dhe për të ofruar përditësime për ata të instaluar tashmë. Me popullaritetin në rritje të OpenShift 4, numri i grupimeve në të në të gjithë botën është rritur gjithashtu. Secili prej këtyre grupeve shkarkon përmbajtjen e operatorit për të ekzekutuar OperatorHub-in e integruar, duke përdorur Regjistrin e aplikacioneve brenda quay.io si bazë. Në kërkimin tonë për burimin e problemit, ne humbëm faktin se ndërsa OpenShift u rrit gradualisht në popullaritet, ngarkesa në një nga funksionet e quay.io të përdorura rrallë u rrit gjithashtu..
Ne bëmë disa analiza të trafikut të kërkesave të Regjistrit të aplikacioneve dhe hodhëm një vështrim në kodin e regjistrit. Menjëherë u zbuluan mangësi, për shkak të të cilave pyetjet në bazën e të dhënave nuk u formuan në mënyrë optimale. Kur ngarkesa ishte e ulët, ata nuk shkaktonin probleme, por kur ngarkesa rritej, ato bëheshin burim problemesh. Regjistri i aplikacioneve doli të kishte dy pika fundore problematike që nuk iu përgjigjën mirë ngarkesës në rritje: e para ofronte një listë të të gjitha paketave në depo, e dyta kthente të gjitha pikat për paketën.
Eliminimi i shkaqeve
Gjatë javës së ardhshme ne kaluam duke optimizuar kodin e vetë Regjistrit të aplikacioneve dhe mjedisin e tij. Qartësisht pyetjet joefektive SQL u ripunuan dhe thirrjet e panevojshme komanduese u eliminuan tar (u ekzekutua sa herë që merreshin blobs), memoria e memories shtohej kudo që ishte e mundur. Më pas kryem testime të gjera të performancës dhe krahasuam shpejtësinë e Regjistrit të aplikacioneve para dhe pas ndryshimeve.
Kërkesat API që më parë kërkonin deri në gjysmë minutë, tani plotësohen në milisekonda. Javën e ardhshme ne vendosëm ndryshimet në prodhim, dhe që atëherë quay.io ka punuar në mënyrë të qëndrueshme. Gjatë kësaj kohe, pati disa rritje të mprehta në trafik në pikën përfundimtare të Regjistrit të aplikacioneve, por përmirësimet e bëra parandaluan ndërprerjet e bazës së të dhënave.
Çfarë kemi mësuar?
Është e qartë se çdo shërbim përpiqet të shmangë kohën e ndërprerjes. Në rastin tonë, ne besojmë se ndërprerjet e fundit kanë ndihmuar në përmirësimin e quay.io. Ne kemi mësuar disa mësime kryesore që do të donim t'i ndajnim:
- Të dhënat se kush e përdor shërbimin tuaj dhe si nuk janë kurrë të tepërta. Për shkak se Quay "sapo funksionoi", nuk na u desh kurrë të shpenzonim kohë duke optimizuar trafikun dhe menaxhuar ngarkesën. E gjithë kjo krijoi një ndjenjë të rreme sigurie që shërbimi mund të zgjerohej pafundësisht.
- Kur shërbimi ulet, rivendosja dhe funksionimi i tij është një përparësi kryesore.. Për shkak se Quay vazhdoi të vuante nga një bazë të dhënash e bllokuar gjatë ndërprerjes së parë, procedurat tona standarde nuk patën efektin e synuar dhe ne nuk ishim në gjendje të rivendosnim shërbimin duke përdorur ato. Kjo çoi në një situatë ku duhej shpenzuar kohë për të analizuar dhe mbledhur të dhëna me shpresën për të gjetur shkakun rrënjësor - në vend që të përqendroheshin të gjitha përpjekjet në rivendosjen e funksionalitetit.
- Vlerësoni ndikimin e secilës veçori të shërbimit. Klientët e përdornin rrallë Regjistrin e aplikacioneve, kështu që nuk ishte një prioritet për ekipin tonë. Kur disa veçori të produktit përdoren mezi, gabimet e tyre shfaqen rrallë dhe zhvilluesit ndalojnë monitorimin e kodit. Është e lehtë të biesh pre e keqkuptimit se kështu duhet të jetë – derisa papritmas ky funksion të gjendet në qendër të një incidenti madhor.
Çka më tej?
Puna për të siguruar stabilitetin e shërbimit nuk ndalet kurrë dhe ne jemi duke e përmirësuar vazhdimisht. Ndërsa vëllimet e trafikut vazhdojnë të rriten në quay.io, ne e kuptojmë se kemi përgjegjësinë të bëjmë gjithçka që mundemi për të përmbushur besimin e klientëve tanë. Prandaj, ne aktualisht jemi duke punuar në detyrat e mëposhtme:
- Vendosni kopje të bazës së të dhënave vetëm për lexim për të ndihmuar shërbimin të trajtojë trafikun e duhur në rast të problemeve me shembullin primar RDS.
- Përditësimi i një shembulli RDS. Vetë versioni aktual nuk është problemi. Përkundrazi, ne thjesht duam të heqim gjurmën e rreme (të cilën e ndoqëm gjatë dështimit); Mbajtja e softuerit të përditësuar do të eliminojë një faktor tjetër në rast të ndërprerjeve të ardhshme.
- Memorie shtesë në të gjithë grupimin. Ne vazhdojmë të kërkojmë zona ku memoria e fshehtë mund të zvogëlojë ngarkesën në bazën e të dhënave.
- Shtimi i një muri zjarri të aplikacionit në ueb (WAF) për të parë se kush po lidhet me quay.io dhe pse.
- Duke filluar me lëshimin e ardhshëm, grupet e Red Hat OpenShift do të braktisin Regjistrin e aplikacioneve në favor të Katalogëve të Operatorit bazuar në imazhet e kontejnerëve të disponueshëm në quay.io.
- Një zëvendësim afatgjatë për Regjistrin e aplikacioneve mund të jetë mbështetja për specifikimet e artefakteve të Iniciativës së Kontejnerëve të Hapur (OCI). Aktualisht është zbatuar si funksionalitet vendas Quay dhe do të jetë i disponueshëm për përdoruesit kur të finalizohet vetë specifikimi.
Të gjitha sa më sipër janë pjesë e investimit të vazhdueshëm të Red Hat në quay.io ndërsa kalojmë nga një ekip i vogël "stili fillestar" në një platformë të pjekur të drejtuar nga SRE. Ne e dimë se shumë nga klientët tanë mbështeten te quay.io në punën e tyre të përditshme (përfshirë Red Hat!) dhe ne përpiqemi të jemi sa më transparentë për ndërprerjet e fundit dhe përpjekjet e vazhdueshme për t'u përmirësuar.
PS nga përkthyesi
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «'.
Burimi: www.habr.com