Ohar. itzul.: abuztuaren hasieran, Red Hat-ek publikoki hitz egin zuen bere zerbitzuko erabiltzaileek aurreko hilabeteetan izan zituzten irisgarritasun arazoak konpontzeaz. (Kontenedoreen irudien erregistro batean oinarritzen da, enpresak CoreOS erostearekin batera jaso zuena). Zerbitzu honen inguruan duzun interesa edozein dela ere, istripuaren arrazoiak diagnostikatzeko eta ezabatzeko enpresako SRE ingeniariek egin zuten bidea argigarria da.
Maiatzaren 19an, goizean goiz (Ekialdeko Eguneko Ordua, EDT), quay.io zerbitzuak huts egin zuen. Istripuak quay.io kontsumitzaileei zein Open Source proiektuei eragin die quay.io softwarea eraiki eta banatzeko plataforma gisa erabiltzen zuten. Red Hat-ek bien konfiantza baloratzen du.
SRE ingeniari talde bat berehala sartu zen eta Kaiko zerbitzua ahalik eta azkarren egonkortzen saiatu zen. Hala ere, hori egiten ari ziren bitartean, bezeroek irudi berriak bultzatzeko gaitasuna galdu zuten, eta noizean behin baino ez zuten lortu lehendik zeudenak ateratzeko. Arrazoi ezezagun batengatik, quay.io datu-basea blokeatu egin zen zerbitzua edukiera osora eskalatu ondoren.
Β«Zer aldatu da?"- Hau da horrelako kasuetan egin ohi den lehen galdera. Konturatu ginen arazoa baino pixka bat lehenago, OpenShift Dedicated clusterra (quay.io exekutatzen duena) 4.3.19 bertsiora eguneratzen hasi zela. Quay.io Red Hat OpenShift Dedicated (OSD) exekutatzen denez, ohiko eguneratzeak ohikoak ziren eta ez zuten inoiz arazorik sortzen. Gainera, aurreko sei hilabeteetan, Quay klusterrak hainbat aldiz berritu ditugu zerbitzua etenik gabe.
Zerbitzua leheneratzen saiatzen ari ginen bitartean, beste ingeniari batzuk OSD kluster berri bat prestatzen hasi ziren softwarearen aurreko bertsioarekin, zerbait gertatuz gero, bertan dena zabaldu ahal izateko.
Erroko Kausen Analisia
Hutsegitearen sintoma nagusia hamarka mila datu-baseko konexioen elur-jausi bat izan zen, eta horrek MySQL instantzia eraginkortasunez funtzionatzen ez zuen. Horrek zaildu egin zuen arazoa diagnostikatzea. Bezeroen gehienezko konexio kopuruari muga bat ezarri diogu SRE taldeari arazoa ebaluatzen laguntzeko. Ez dugu datu-basean ezohiko trafikorik nabaritu: izan ere, eskaera gehienak irakurtzen ziren, eta gutxi batzuk bakarrik idatzi ziren.
Datu-basearen trafikoan ere elur-jausi hori eragin dezakeen eredu bat identifikatzen saiatu gara. Hala ere, ezin izan dugu eredurik aurkitu erregistroetan. OSD 4.3.18-ko kluster berria prest egotearen zain egon ginen, quay.io pods abiarazten saiatzen jarraitu genuen. Klusterrak gaitasun osoa lortzen zuen bakoitzean, datu-basea izoztu egiten zen. Horrek esan nahi du RDS instantzia berrabiarazi behar zela quay.io pod guztiez gain.
Arratsalderako, zerbitzua irakurtzeko soilik moduan egonkortu dugu eta ezinbestekoak ez diren funtzio gehien desgaitu ditugu (adibidez, izen-eremuaren zabor bilketa) datu-basearen karga murrizteko. Izozteak gelditu dira baina arrazoia ez zen inoiz aurkitu. OSD kluster berria prest zegoen, eta zerbitzua migratu dugu, trafikoa konektatu eta jarraipena jarraitu dugu.
Quay.io-k egonkor lan egin zuen OSD kluster berrian, beraz, datu-basearen erregistroetara itzuli ginen, baina ezin izan genuen blokeoak azalduko zituen korrelaziorik aurkitu. OpenShift-eko ingeniariek gurekin lan egin zuten Red Hat OpenShift 4.3.19-ko aldaketek Quay-n arazoak sor ditzaketen ala ez ulertzeko. Hala ere, ez zen ezer aurkitu, eta Ezin izan zen arazoa laborategiko baldintzetan erreproduzitu.
Bigarren porrota
Maiatzaren 28an, EDT eguerdia baino pixka bat lehenago, quay.io berriro erori zen sintoma berarekin: datu-basea blokeatuta zegoen. Eta berriro ere gure ahalegin guztiak ikerketara bota genituen. Lehenik eta behin, zerbitzua berreskuratu beharra zegoen. Hala ere oraingoan RDS berrabiarazi eta quay.io pods berrabiarazteak ez du ezer egin: beste konexio-jausi batek gainezka egin du oinarria. Baina zergatik?
Quay Python-en idatzita dago eta pod bakoitzak edukiontzi monolitiko bakar gisa funtzionatzen du. Edukiontziaren exekuzio-denborak zeregin paralelo asko exekutatzen ditu aldi berean. Liburutegia erabiltzen dugu gevent beherako gunicorn web eskaerak prozesatzeko. Eskaera bat Quay-ra heltzen denean (gure APIaren bidez edo Dockerren APIaren bidez), gevent langile bat esleitzen zaio. Normalean langile honek datu-basearekin harremanetan jarri behar du. Lehenengo hutsegitearen ondoren, gevent langileak datu-basera konektatzen ari zirela deskubritu genuen ezarpen lehenetsiak erabiliz.
Quay-ko ontzi kopuru handia eta segundoko sarrerako milaka eskaera kontuan hartuta, datu-baseen konexio kopuru handi batek teorikoki gainezka dezake MySQL instantzia. Jarraipenari esker, jakin zen Quayk 5 mila eskaera prozesatzen dituela batez beste segundoko. Datu-baserako konexio kopurua gutxi gorabehera berdina zen. 5 mila konexio gure RDS instantziaren gaitasunen barruan zeuden (ezin da hamar mila buruz esan). Arrazoiren batengatik ustekabeko igoerak izan ziren konexio kopuruan, hala ere, ez dugu inolako korrelaziorik nabaritu sarrerako eskaerekin.
Oraingoan arazoaren iturria aurkitu eta kentzeko erabakia hartu genuen, eta ez berrabiaratzera mugatu. Quay kode-basera aldaketak egin ziren langile bakoitzaren datu-baserako konexio kopurua mugatzeko gevent. Zenbaki hori parametro bihurtu zen konfigurazioan: hegan aldatzea posible izan zen edukiontzi-irudi berri bat eraiki gabe. Zenbat konexio modu errealistan kudeatu litezkeen jakiteko, hainbat proba egin genituen eszenatze-ingurune batean, balio desberdinak ezarriz horrek karga-probaren eszenatokietan nola eragingo lukeen ikusteko. Ondorioz, hori deskubritu zen Quay-k 502 errore ematen hasten da konexio kopurua 10 mila gainditzen duenean.
Berehala bertsio berri hau ekoizpenera zabaldu genuen eta datu-basearen konexioaren ordutegia kontrolatzen hasi ginen. Iraganean, basea blokeatuta zegoen 20 minutu ingururen buruan. Arazorik gabeko 30 minuturen ostean itxaropena genuen, eta ordubete geroago konfiantza genuen. Gunerako trafikoa leheneratu genuen eta autopsia aztertzen hasi ginen.
Blokeatzerako arazoa saihestea lortu ondoren, ez ditugu bere benetako arrazoiak aurkitu. Berretsi zen ez dagoela OpenShift 4.3.19-ko aldaketekin zerikusirik, 4.3.18 bertsioan ere gauza bera gertatu baitzen, lehenago Quay-rekin arazorik gabe funtzionatzen baitzuen.
Argi eta garbi, klusterrean beste zerbait zebilela.
Xehetasun Azterketa
Quay.io-k ezarpen lehenetsiak erabili zituen datu-basera sei urtez arazorik gabe konektatzeko. Zer aldatu da? Argi dago denbora guzti honetan quay.io-ko trafikoa etengabe hazten ari dela. Gure kasuan, atalase-balioren bat iritsi zela ematen zuen, konexio-jausi baten abiarazle gisa balio zuena. Bigarren hutsegitearen ostean datu-basearen erregistroak aztertzen jarraitu genuen, baina ez genuen eredurik edo erlazio nabaririk aurkitu.
Bitartean, SRE taldea Quay-ren eskaeraren behagarritasuna eta zerbitzuaren osasun orokorra hobetzen aritu da. Neurri eta aginte-panel berriak zabaldu dira, Kaiaren zein zati diren bezeroen eskaera gehien erakusten duena.
Quay.io ondo funtzionatu zuen ekainaren 9ra arte. Gaur goizean (EDT) datu-baseen konexioen kopurua nabarmen handitu dela ikusi dugu berriro. Oraingoan ez zen geldialdirik izan, parametro berriak haien kopurua mugatzen zuelako eta ez zien MySQL-ren abiadura gainditzen uzten. Hala ere, ordu erdi inguruz, erabiltzaile askok quay.io-ren errendimendu motela adierazi zuten. Azkar bildu genituen datu posible guztiak gehitutako monitorizazio tresnak erabiliz. Bat-batean eredu bat sortu zen.
Konexioak areagotu baino lehen, eskaera ugari egin ziren App Registry APIra. Aplikazioen Erregistroa quay.io-ren ezaugarri gutxi ezagutzen da. Helm diagramak eta edukiontziak bezalako gauzak metadatu aberatsekin gordetzeko aukera ematen du. Quay.io-ko erabiltzaile gehienek ez dute funtzio honekin funtzionatzen, baina Red Hat OpenShift-ek aktiboki erabiltzen du. OpenShift-en parte den OperatorHub-ek operadore guztiak gordetzen ditu Aplikazioen Erregistroan. Operadore hauek OpenShift lan-kargaren ekosistemaren eta bazkideengan oinarritutako eredu eragilearen oinarria dira (2. eguneko eragiketak).
OpenShift 4 kluster bakoitzak integratutako OperatorHub-eko operadoreak erabiltzen ditu instalatzeko dauden operadoreen katalogoa argitaratzeko eta dagoeneko instalatuta daudenei eguneraketak emateko. OpenShift 4-ren ospea gero eta handiagoa denez, munduan bertan dauden kluster kopurua ere handitu egin da. Kluster horietako bakoitzak operadorearen edukia deskargatzen du integratutako OperatorHub exekutatzeko, quay.io barruko Aplikazioen Erregistroa atzealde gisa erabiliz. Arazoaren iturriaren bilaketan, galdu egin dugu OpenShift-ek pixkanaka ospea hazi ahala, gutxitan erabiltzen den quay.io funtzioetako baten karga ere handitu zela..
App Registry-ren eskaera-trafikoaren azterketa egin dugu eta erregistro-kodeari begiratu bat eman diogu. Berehala, gabeziak agerian geratu ziren, eta ondorioz datu-baserako kontsultak ez ziren modu egokian osatu. Karga baxua zenean, ez zuten arazorik sortzen, baina karga handitzean, arazo iturri bihurtzen ziren. Aplikazioen Erregistroak bi amaiera-puntu problematiko zituen, karga handitzeari ondo erantzuten ez ziotenak: lehenak biltegiko pakete guztien zerrenda ematen zuen, bigarrenak paketearen blob guztiak itzuli zituen.
Kausak ezabatzea
Hurrengo astean Aplikazioen Erregistroaren kodea eta bere ingurunea optimizatzen aritu ginen. Argi eta garbi, eraginkortasunik gabeko SQL kontsultak berritu egin ziren eta beharrezkoak ez ziren komando-deiak ezabatu ziren tar (Blobak berreskuratzen ziren bakoitzean exekutatzen zen), ahal zen guztietan cachea gehitu zen. Ondoren, errendimendu proba zabalak egin genituen eta aldaketak egin aurretik eta ondoren aplikazioen erregistroaren abiadura alderatu genuen.
Lehen minutu erdi behar zuten API eskaerak milisegundotan betetzen dira. Hurrengo astean ekoizpenean aldaketak zabaldu genituen, eta harrezkero quay.io egonkor dabil lanean. Denbora horretan, trafikoaren gorakada nabarmenak izan ziren Aplikazioen Erregistroaren amaierako puntuan, baina egindako hobekuntzek datu-basearen etenaldiak saihestu zituzten.
Zer ikasi dugu?
Argi dago edozein zerbitzu geldialdiak saihesten saiatzen dela. Gure kasuan, azken etenaldiek quay.io hobetzen lagundu dutela uste dugu. Partekatu nahiko genituzkeen zenbait ikasgai gako ikasi ditugu:
- Zure zerbitzua nork eta nola erabiltzen duenari buruzko datuak ez dira inoiz soberan geratzen. Quay-k "funtzionatu besterik ez zuenez" ez genuen inoiz denborarik eman behar trafikoa optimizatzen eta karga kudeatzen. Horrek guztiak segurtasun sentsazio faltsua sortu zuen, zerbitzua mugagabe eskalatu zezakeena.
- Zerbitzua jaisten denean, berriro martxan jartzea lehentasun nagusia da.. Quay-k lehen etenaldian blokeatutako datu-base bat jasaten jarraitu zuenez, gure prozedura estandarrek ez zuten aurreikusitako ondorioa izan eta ezin izan genuen zerbitzua berreskuratu haiek erabiliz. Honek egoera bat ekarri zuen non denbora eman behar izan zen datuak aztertzen eta biltzen, arrazoia aurkitzeko itxaropenarekin, ahalegin guztiak funtzionaltasuna berreskuratzera bideratu beharrean.
- Ebaluatu zerbitzu-eginbide bakoitzaren eragina. Bezeroek oso gutxitan erabiltzen zuten App Registry, beraz, ez zen gure taldearen lehentasuna. Produktuaren ezaugarri batzuk ia erabiltzen direnean, haien akatsak oso gutxitan agertzen dira eta garatzaileek kodea kontrolatzeari uzten diote. Erraza da horrela izan behar den uste okerra erortzea, harik eta bat-batean funtzio hori gertakari handi baten erdian aurkitzen den arte.
Zer da hurrengoa?
Zerbitzuaren egonkortasuna bermatzeko lana ez da inoiz gelditzen eta etengabe hobetzen ari gara. Quay.io-n trafiko-bolumenak hazten jarraitzen duen heinean, onartzen dugu gure bezeroen konfiantza izateko ahal dugun guztia egiteko ardura dugula. Hori dela eta, gaur egun honako zeregin hauetan ari gara lanean:
- Inplementatu irakurtzeko soilik datu-baseen erreplikak zerbitzuak trafiko egokia kudeatzen laguntzeko, RDS instantzia nagusiarekin arazoak izanez gero.
- RDS instantzia bat eguneratzen. Oraingo bertsioa bera ez da arazoa. Baizik eta, besterik gabe, arrasto faltsua kendu nahi dugu (porrotean jarraitu genuena); Softwarea eguneratuta mantentzeak beste faktore bat ezabatuko du etorkizuneko etenaldietan.
- Cache gehigarria kluster osoan zehar. Cacheak datu-basearen karga murrizteko eremuak bilatzen jarraitzen dugu.
- Web aplikazioen suebaki bat gehitzea quay.io-ra nor eta zergatik konektatzen den ikusteko.
- Hurrengo bertsiotik hasita, Red Hat OpenShift klusterrak Aplikazioen Erregistroa alde batera utziko du Quay.io-n eskuragarri dauden edukiontzien irudietan oinarritutako Operadoreen Katalogoen alde.
- Aplikazioen Erregistroaren epe luzerako ordezko bat Open Container Initiative (OCI) artefaktuen zehaztapenetarako laguntza izan liteke. Gaur egun Quay-ren jatorrizko funtzionalitate gisa inplementatuta dago eta erabiltzaileen eskura egongo da zehaztapena bera amaitzen denean.
Goiko guztiak Red Hat-ek quay.io-n egiten duen etengabeko inbertsioaren parte dira, "startup-estilo" talde txiki batetik SRE-k bultzatutako plataforma heldu batera pasatzen garen heinean. Badakigu gure bezero asko quay.io-n oinarritzen direla euren eguneroko lanean (Red Hat barne!) eta saiatzen gara ahalik eta gardenen izaten azken etenaldiei eta hobetzeko egiten ari diren ahaleginei buruz.
PS itzultzailetik
Irakurri ere gure blogean:
- «»;
- «»;
- Β«'.
Iturria: www.habr.com