Not. werger.: di destpêka Tebaxê de, Red Hat bi gelemperî li ser çareserkirina pirsgirêkên gihîştinê yên ku bikarhênerên karûbarê wê di mehên berê de pê re rû bi rû mane axivî. (ew li ser bingeha qeydek ji bo wêneyên konteynerê, ku pargîdanî digel kirîna CoreOS-ê wergirtiye, ye). Tevî eleqeya we ya ji bo vê karûbarê bi vî rengî, riya ku endezyarên SRE yên pargîdanî ji bo teşhîskirin û rakirina sedemên qezayê girtin hînker e.
Di 19ê Gulanê de, serê sibê (Saeta Rojê ya Rojhilat, EDT), karûbarê quay.io qeza kir. Qeza hem bandor li ser xerîdarên quay.io û hem jî projeyên Çavkaniya Vekirî kir ku quay.io wekî platformek ji bo çêkirin û belavkirina nermalavê bikar tînin. Red Hat pêbaweriya herduyan nirx dike.
Tîmek endezyarên SRE tavilê tevli bûn û hewl dan ku di demek zû de karûbarê Quay aram bikin. Lêbelê, dema ku wan wiya dikir, xerîdar kapasîteya ku wêneyên nû bişopînin winda kirin, û tenê carinan wan dikaribû yên heyî bikişîne. Ji ber hin sedemên nenas, databasa quay.io piştî ku karûbar bi tevahî kapasîteya xwe vekir hate asteng kirin.
«Whati guhertin?"- ev pirsa yekem e ku bi gelemperî di rewşên weha de tê pirsîn. Me dît ku demek berî pirsgirêkê, koma OpenShift Dedicated (ku quay.io dimeşîne) dest bi nûvekirina guhertoya 4.3.19 kir. Ji ber ku quay.io li ser Red Hat OpenShift Dedicated (OSD) dimeşe, nûvekirinên birêkûpêk rûtîn bûn û qet pirsgirêk derneketin. Digel vê yekê, di şeş mehên borî de, me komên Quay çend caran bê navber di karûbarê de nûve kirin.
Dema ku me hewl dida ku karûbarê sererast bikin, endezyarên din bi guhertoya berê ya nermalavê re dest bi amadekirina komek nû ya OSD kirin, da ku heke tiştek çêbibe, ew dikarin her tiştî li ser wê bicîh bikin.
Analyza Sedema Root
Nîşaneya sereke ya têkçûnê avalançeyek bi deh hezaran girêdanên databasê bû, ku mînaka MySQL bi bandor nexebitî. Vê yekê teşhîskirina pirsgirêkê dijwar kir. Me li ser hejmara herî zêde girêdanên ji xerîdaran sînorek destnîşan kiriye da ku ji tîmê SRE re bibe alîkar ku pirsgirêkê binirxîne. Me tu seyrûseferek neasayî ya databasê nedît: bi rastî, pir daxwaz hatin xwendin, û tenê çend kes hatin nivîsandin.
Di heman demê de me hewl da ku di seyrûsefera databasê de nimûneyek ku dikare bibe sedema vê avalancheyê nas bikin. Lêbelê, me nekarî di qeydan de tu qalib peyda bikin. Dema ku li benda amadebûna koma nû ya bi OSD 4.3.18 bûn, me hewildana destpêkirina quay.io pods berdewam kir. Her gava ku kom digihîje kapasîteya tevahî, databas dicemidîne. Ev tê vê wateyê ku pêdivî bû ku ji bilî hemî quay.io pods, mînaka RDS ji nû ve were destpêkirin.
Heya êvarê, me karûbar di moda tenê-xwendinê de stabîl kir û bi qasî ku gengaz be gelek fonksiyonên ne-bingehîn asteng kir (mînak, berhevkirina çopê cîhê navan) da ku barê databasê kêm bike. Qeşa rawestiyaye lê sedem qet nehat dîtin. Koma nû ya OSD amade bû, û me karûbar koç kir, seyrûseferê girêda û çavdêrî dom kir.
Quay.io li ser koma nû ya OSD-ê bi îstîqrar xebitî, ji ber vê yekê em vegeriyan têketinên databasê, lê nekarin têkiliyek ku dê astengiyan rave bike bibînin. Endezyarên OpenShift bi me re xebitîn ku fêm bikin ka gelo guhertinên di Red Hat OpenShift 4.3.19 de dikarin bi Quay re bibin sedema pirsgirêkan. Lêbelê, tiştek nehat dîtin, û Di şert û mercên laboratîfê de ne gengaz bû ku pirsgirêk ji nû ve were hilberandin.
Têkçûna duyemîn
Di 28ê Gulanê de, demek berî nîvro EDT, quay.io dîsa bi heman nîşanê ket: databas hate asteng kirin. Û dîsa me hemû hewldanên xwe avêtin lêpirsînê. Berî her tiştî, pêdivî bû ku karûbarê nûve bikin. Lebê vê carê ji nû ve destpêkirina RDS-ê û ji nû ve destpêkirina podên quay.io rê neda tiştek: berfek din a pêwendiyan li binkeyê xistiye. Lê çima?
Quay di Python-ê de hatî nivîsandin û her pod wekî konteynirek monolîtîk yekane dixebite. Dema xebitandina konteynerê gelek karên paralel bi hevdemî dimeşîne. Em pirtûkxaneyê bikar tînin gevent bin gunicorn ji bo pêkanîna daxwazên webê. Dema ku daxwazek tê Quay (bi navgîniya API-ya meya xwe, an bi navgîniya API-ya Docker), jê re xebatkarek gevent tê destnîşankirin. Bi gelemperî divê ev xebatkar bi databasê re têkilî daynin. Piştî têkçûna yekem, me kifş kir ku xebatkarên gevent bi karanîna mîhengên xwerû bi databasê ve girêdidin.
Ji ber ku hejmareke girîng a Quay pods û bi hezaran daxwazên gihîştî di çirkeyê de, hejmareke mezin ji girêdanên databasê dikarin bi teorîkî mînaka MySQL bişkînin. Bi saya çavdêriyê, hat zanîn ku Quay di çirkeyê de bi navînî 5 hezar daxwazan pêvajoyê dike. Hejmara girêdanên bi databasê re hema hema yek bû. 5 hezar girêdan di nav kapasîteyên mînaka me ya RDS de baş bûn (ku bi deh hezaran nayê gotin). Ji ber hin sedeman di hejmara pêwendiyan de pêlên neçaverêkirî hebûn, lebê, me ti têkiliyek bi daxwazên hatinî re nedît.
Vê carê me bi biryar bû ku em çavkaniya pirsgirêkê bibînin û ji holê rakin, û xwe bi ji nû ve dest pêkirinê sînordar nekin. Ber bi bingeha koda Quay guherandin hatin kirin da ku ji bo her karkerek hejmara girêdanên bi databasê re sînordar bikin gevent. Ev hejmar di veavakirinê de bû parameterek: bêyî avakirina wêneyek konteynerek nû guheztina wê di firînê de mimkun bû. Ji bo ku em zanibin ka çend girêdan dikarin bi rastî werin rêve kirin, me di hawîrdorek qonaxek de gelek ceribandin meşandin, nirxên cihêreng danîn da ku bibînin ka ev ê çawa bandorê li senaryoyên ceribandina barkirinê bike. Di encamê de hat dîtin ku Dema ku hejmara pêwendiyan ji 502 hezarî derbas dibe, Quay dest bi avêtina 10 xeletiyan dike.
Me tavilê ev guhertoya nû li hilberînê da û dest bi şopandina nexşeya girêdana databasê kir. Berê, bingeh piştî 20 hûrdeman hate girtin. Piştî 30 hûrdeman bê pirsgirêk hêviya me hebû, û saetek şûnda jî baweriya me hebû. Me seyrûsefera malperê sererast kir û dest bi analîza postmortem kir.
Piştî ku karîbû pirsgirêka ku ber bi astengkirinê ve diçe derbas bike, me sedemên wê yên rastî derneket. Hat pejirandin ku ew bi tu guhertinên di OpenShift 4.3.19 de ne têkildar e, ji ber ku heman tişt li ser guhertoya 4.3.18-ê ku berê bi Quay re bêyî pirsgirêk xebitî bû.
Eşkere bû ku tiştek din di nav komê de veşartî bû.
Lêkolîna Berfireh
Quay.io mîhengên xwerû bikar anî da ku şeş sal bêyî pirsgirêk bi databasê ve girêbide. Çi guherî? Eşkere ye ku tevahiya vê demê seyrûsefera li ser quay.io bi domdarî mezin dibe. Di doza me de, wusa dixuye ku hindek nirxek bend gihîştiye, ku ji bo alavek pêwendiyan wekî tetikek xizmet kir. Me lêkolîna têketinên databasê piştî têkçûna duyemîn domand, lê tu qalib û têkiliyên eşkere nedîtin.
Di vê navberê de, tîmê SRE li ser çêtirkirina çavdêriya daxwaza Quay û tenduristiya giştî ya karûbarê xebitî. Metrîk û tabloyên nû hatine bicihkirin, nîşan dide ku kîjan beşên Quay ji mişteriyan pir daxwaz in.
Quay.io heta 9-ê Hezîranê baş xebitî. Vê sibehê (EDT) me dîsa di hejmara girêdanên databasê de zêdebûnek girîng dît. Vê carê dema daketinê tune bû, ji ber ku pîvana nû jimara wan sînordar kir û nehişt ku ew ji guheztina MySQL derbas bibin. Lêbelê, bi qasî nîv saetê, gelek bikarhêneran performansa hêdî ya quay.io destnîşan kirin. Me bi karanîna amûrên çavdêriyê yên zêdekirî zû hemî daneyên gengaz berhev kir. Ji nişka ve nimûneyek derket holê.
Hema berî zêdebûna pêwendiyan, hejmareke mezin daxwaz ji API-ya Registry App-ê re hatin kirin. Registry App taybetmendiyek hindik-naskirî ya quay.io ye. Ew dihêle hûn tiştên mîna nexşeyên Helm û konteynerên bi metadata dewlemend hilînin. Piraniya bikarhênerên quay.io bi vê taybetmendiyê re naxebitin, lê Red Hat OpenShift bi çalak wê bikar tîne. OperatorHub wekî beşek OpenShift hemî operatoran di Tomara Appê de hilîne. Van operatoran bingehê ji bo ekosîstema xebata OpenShift û modela xebitandinê-navendî ya hevpar (Operasyonên Roja 2) pêk tînin.
Her komek OpenShift 4 operatorên ji OperatorHub-ya çêkirî bikar tîne da ku katalogek operatorên ku ji bo sazkirinê peyda dibin biweşîne û nûvekirinan ji yên ku berê hatine saz kirin peyda bike. Bi mezinbûna populerbûna OpenShift 4 re, hejmara komên li ser wê li çaraliyê cîhanê jî zêde bûye. Her yek ji van koman naveroka operatorê dadixe da ku OperatorHub-ya çêkirî bimeşîne, bi karanîna Tomara Appê ya hundurê quay.io wekî paşverû. Di lêgerîna me ya ji bo çavkaniya pirsgirêkê de, me ji vê rastiyê winda kir ku her ku OpenShift hêdî hêdî populerbûna xwe zêde kir, barkirina yek ji fonksiyonên quay.io-ya ku kêm têne bikar anîn jî zêde bû..
Me hin analîzek li ser seyrûsefera daxwaznameya App Registry kir û li koda qeydê nihêrî. Di cih de, kêmasî derketin holê, ji ber vê yekê pirsên ji databasê re bi rengek çêtirîn çênebûn. Dema ku bar kêm bû, tu pirsgirêk derneketibûn, lê dema ku bar zêde dibûn, dibûn cihê pirsgirêkan. Registry Appê derket ku du xalên dawîn ên pirsgirêk hene ku baş bersiv nedan zêdekirina barkirinê: ya yekem navnîşek hemî pakêtên di depoyê de peyda kir, ya duyemîn hemî blobên pakêtê vegerand.
Rakirina sedeman
Di hefteya pêş de me xweşbînkirina koda Qeyda Appê bixwe û hawîrdora wê derbas kir. Eşkere pirsên SQL yên bêbandor ji nû ve hatin xebitandin û bangên fermanê yên nehewce hatin rakirin. tar (her gava ku blob dihatin vegerandin ew diçû), li ku derê gengaz bû caching hate zêdekirin. Dûv re me ceribandinek performansê ya berfireh kir û leza Qeyda Appê berî û piştî guheztinê dan ber hev.
Daxwazên API-ê yên ku berê nîv hûrdem dikişand, naha di milî çirkeyan de têne qedandin. Hefteya pêş me guheztinên hilberînê bi cih kir, û ji hingê ve quay.io bi îstîqrar dixebite. Di vê demê de, li ser xala dawiya App Registry di seyrûseferê de gelek tîrêjên tûj hebûn, lê çêtirkirinên ku hatine çêkirin rê li ber qutbûna databasê girtin.
Em çi fêr bûne?
Eşkere ye ku her karûbar hewl dide ku ji demdirêjiyê dûr bixe. Di doza me de, em bawer dikin ku qutkirinên vê dawîyê alîkariya çêtirkirina quay.io kirine. Em hînî çend dersên sereke bûne ku em dixwazin parve bikin:
- Daneyên di derbarê kî karûbarê we û çawa bikar tîne qet ne zêde ye. Ji ber ku Quay "tenê xebitî", me tu carî neçar ma ku wextê xweştirkirina seyrûseferê û birêvebirina barkirinê derbas bikin. Hemî vê yekê hestek ewlehiyê ya derewîn çêkir ku karûbar dikare bêdawî bipîve.
- Dema ku xizmet dadikeve, vegerandina wê û meşandina wê pêşînek sereke ye.. Ji ber ku Quay di dema qutbûna yekem de êşa databasek kilîtkirî berdewam kir, prosedurên me yên standard bandora mebesta me tune û me nekarî karûbarê bi karanîna wan vegerînin. Vê yekê rê da rewşek ku pêdivî bû ku dem bi analîzkirin û berhevkirina daneyan bi hêviya dîtina sedema bingehîn - li şûna ku hemî hewildan li ser vegerandina fonksiyonê bisekine.
- Bandora her taybetmendiya karûbarê binirxînin. Xerîdar kêm kêm Registry App bikar anîn, ji ber vê yekê ew ji bo tîmê me ne pêşînek bû. Gava ku hin taybetmendiyên hilberê bi zor têne bikar anîn, xeletiyên wan kêm kêm xuya dibin, û pêşdebiran çavdêriya kodê rawestînin. Hêsan e ku meriv bikeve nêçîra têgihîştina xelet ku bi vî rengî ye - heya ku ji nişka ve ew fonksiyon xwe di navenda bûyerek mezin de dibîne.
Çi ye?
Xebata ji bo dabînkirina aramiya karûbarê qet naraweste û em bi berdewamî wê baştir dikin. Gava ku hêjmara seyrûseferê li ser quay.io zêde dibe, em pê dizanin ku berpirsiyariya me heye ku em her tiştî bikin da ku em pêbaweriya xerîdarên xwe bijîn. Ji ber vê yekê, em niha li ser karên jêrîn dixebitin:
- Bersivên databasê yên tenê-xwendewar bicîh bikin da ku ji karûbar re bibin alîkar ku di bûyera pirsgirêkên bi mînaka RDS-a bingehîn de seyrûsefera guncan bi rê ve bibe.
- Nûvekirina mînakek RDS. Guhertoya heyî bixwe ne pirsgirêk e. Belê, em tenê dixwazin şopa derewîn (ya ku me di dema têkçûnê de şopand); Nûvekirina nermalavê dê di bûyera qutbûna pêşerojê de faktorek din ji holê rake.
- Veşartina pêvek li seranserê tevahiya komê. Em berdewam dikin ku li deverên ku caching dikare barkirina li ser databasê kêm bike digerin.
- Zêdekirina firewallek serîlêdana webê (WAF) da ku bibînin ka kî bi quay.io ve girêdide û çima.
- Bi serbestberdana din re dest pê dike, komên Red Hat OpenShift dê ji Katalogên Operatorê yên li ser bingeha wêneyên konteynerê yên ku li quay.io-yê peyda dibin dev ji Registry Appê berdin.
- Veguheztinek demdirêj a ji bo Tomara Appê dibe ku piştgirî ji bo taybetmendiyên hunerî yên Înîsiyatîfa Konteynirê Vekirî (OCI) be. Ew naha wekî fonksiyona xwemalî ya Quay tête bicîh kirin û dema ku taybetmendî bixwe bi dawî bibe dê ji bikarhêneran re peyda bibe.
Hemî yên li jor beşek in ji veberhênana domdar a Red Hat ya li quay.io ji ber ku em ji tîmek piçûk "destpêk-şêwe" berbi platformek gihîştî ya SRE-a ajoker ve diçin. Em dizanin ku gelek xerîdarên me di xebata xwe ya rojane de xwe dispêrin quay.io (di nav de Red Hat!) û em hewl didin ku di derbarê qutkirinên vê dawîyê û hewildanên domdar ên ji bo çêtirkirinê de bi qasî ku gengaz be zelal bin.
PS ji wergêr
Li ser bloga me jî bixwînin:
- «»;
- «»;
- «".
Source: www.habr.com