Hej Habr! Dy muajt e fundit kemi jetuar në një situatë shumë interesante dhe do të doja të ndaja historinë tonë të shkallëzimit të infrastrukturës. Gjatë kësaj kohe, SberMarket është katërfishuar në porosi dhe ka nisur shërbimin në 4 qytete të reja. Rritja shpërthyese e kërkesës për shpërndarjen e ushqimeve na ka kërkuar që të zgjerojmë infrastrukturën tonë. Lexoni për përfundimet më interesante dhe më të dobishme nën prerje.
Emri im është Dima Bobylev, unë jam drejtor teknik i SberMarket. Meqenëse ky është postimi i parë në blogun tonë, do të them disa fjalë për veten dhe kompaninë. Vjeshtën e kaluar mora pjesë në konkursin për drejtuesit e rinj të Runet. Për konkursin I se si ne në SberMarket e shohim kulturën e brendshme dhe qasjen ndaj zhvillimit të shërbimit. Dhe megjithëse nuk arrita të fitoja konkursin, formulova për vete parimet bazë për zhvillimin e ekosistemit të IT.
Kur menaxhoni një ekip, është e rëndësishme të kuptoni dhe të gjeni një ekuilibër midis asaj që i nevojitet biznesit dhe nevojave të secilit zhvillues individual. Tani SberMarket po rritet 13 herë në vit, dhe kjo ndikon në produktin, duke kërkuar një rritje të vazhdueshme të vëllimit dhe ritmit të zhvillimit. Pavarësisht kësaj, ne ndajmë kohë të mjaftueshme për zhvilluesit për analiza paraprake dhe kodim me cilësi të lartë. Qasja e formuar ndihmon jo vetëm në krijimin e një produkti funksional, por edhe në shkallëzimin dhe zhvillimin e tij të mëtejshëm. Si rezultat i kësaj rritjeje, SberMarket është bërë tashmë një lider në mesin e shërbimeve të ofrimit të ushqimeve: ne dërgojmë rreth 18 porosi në ditë, megjithëse kishte rreth 3500 në fillim të shkurtit.
Një ditë, një klient i kërkoi një korrieri të SberMarket që t'i dërgonte sende ushqimore pa kontakt - pikërisht në ballkon.
Por le të zbresim në specifikat. Gjatë muajve të fundit, ne kemi qenë aktivisht në shkallëzimin e infrastrukturës së kompanisë sonë. Kjo nevojë shpjegohej nga faktorë të jashtëm dhe të brendshëm. Njëkohësisht me zgjerimin e bazës së klientëve, numri i dyqaneve të lidhura u rrit nga 90 në fillim të vitit në mbi 200 nga mesi i majit. Sigurisht, ne përgatitëm veten, rezervuam infrastrukturën kryesore dhe llogaritëm në mundësinë e shkallëzimit vertikal dhe horizontal të të gjitha makinave virtuale të pritura në renë Yandex. Megjithatë, praktika ka treguar: "Gjithçka që mund të shkojë keq do të shkojë keq". Dhe sot dua të ndaj situatat më kurioze që kanë ndodhur në këto javë. Shpresoj se përvoja jonë do të jetë e dobishme për ju.
Skllav në gatishmëri të plotë luftarake
Edhe para fillimit të pandemisë, ne u përballëm me një rritje të numrit të kërkesave për serverët tanë backend. Tendenca për të porositur ushqime me dërgesë në shtëpi filloi të merrte vrull dhe me futjen e masave të para të izolimit në lidhje me COVID-19, ngarkesa u rrit në mënyrë dramatike para syve tanë gjatë gjithë ditës. Kishte nevojë që të shkarkoheshin shpejt serverët kryesorë të bazës së të dhënave kryesore dhe të transferoheshin disa nga kërkesat e leximit te serverët e kopjeve (skllav).
Ne po përgatiteshim për këtë hap paraprakisht, dhe 2 serverë skllevër tashmë po punonin për një manovër të tillë. Ata kryesisht kanë punuar në detyrat e grupit për gjenerimin e burimeve të informacionit për shkëmbimin e të dhënave me partnerët. Këto procese krijuan një ngarkesë shtesë dhe me të drejtë u hoqën nga kllapat disa muaj më parë.
Meqenëse përsëritja u zhvillua në Slave, ne i përmbaheshim konceptit që aplikacionet mund të punojnë me to vetëm në modalitetin vetëm për lexim. Plani i Rimëkëmbjes nga Fatkeqësitë supozoi se në rast fatkeqësie, ne thjesht mund të montonim Slave-n në vend të Master-it dhe t'i kalonim të gjitha kërkesat për shkrim dhe lexim tek Slave. Megjithatë, ne gjithashtu donim të përdornim kopje për nevojat e departamentit të analitikës, kështu që serverët nuk ishin të vendosur plotësisht për të lexuar vetëm statusin, dhe secili host kishte grupin e vet të përdoruesve, dhe disa kishin leje shkrimi për të ruajtur rezultatet e ndërmjetme të llogaritjes.
Deri në një nivel të caktuar ngarkese, kishim mjaftueshëm master për të shkruar dhe lexuar gjatë përpunimit të kërkesave http. Në mes të marsit, pikërisht kur Sbermarket vendosi të kalonte plotësisht në punë në distancë, ne filluam të shumëfishonim rritjen e RPS. Gjithnjë e më shumë nga klientët tanë kaluan në izolim ose punë nga shtëpia, gjë që u reflektua në treguesit e ngarkesës.
Performanca e "mjeshtrit" nuk mjaftonte më, kështu që filluam të transferonim disa nga kërkesat më të rënda të lexuara në kopje. Për t'i drejtuar në mënyrë transparente kërkesat për shkrim zotërisë dhe për t'i lexuar kërkesat skllavit, ne përdorëm perlë rubin "". Ne kemi krijuar një përdorues të veçantë me _readonly postfix pa leje shkrimi. Por për shkak të një gabimi në konfigurimin e njërit prej hosteve, një pjesë e kërkesave për shkrim shkuan në serverin skllav në emër të një përdoruesi që kishte të drejtat e duhura.
Problemi nuk u shfaq menjëherë, sepse. ngarkesa e shtuar rriti ngarkesën e skllevërve. Mospërputhja e të dhënave u zbulua në mëngjes, kur, pas importeve të natës, skllevërit nuk "e kapën" zotërinë. Ne ia atribuuam këtë ngarkesës së lartë të vetë shërbimit dhe importeve të lidhura me nisjen e dyqaneve të reja. Por ishte e papranueshme dhënia e të dhënave me një vonesë prej disa orësh dhe ne i kaluam proceset në skllavin e dytë analitik, sepse kishteоBurime më të mëdha dhe nuk ishte i ngarkuar me kërkesa për lexim (kështu i shpjeguam vetes mungesën e vonesës së përsëritjes).
Kur kuptuam arsyet e "përhapjes" së skllavit kryesor, ai analitik tashmë kishte dështuar për të njëjtën arsye. Megjithë praninë e dy serverëve shtesë, tek të cilët kishim planifikuar të transferonim ngarkesën në rast të një përplasjeje master, për shkak të një gabimi fatkeq, rezultoi se nuk kishte asnjë në një moment kritik.
Por meqenëse ne nuk hodhëm vetëm bazën e të dhënave (rivendosja në atë kohë ishte rreth 5 orë), por edhe një fotografi e serverit master, arritëm të nisnim kopjen brenda 2 orëve. Vërtetë, pas kësaj, ne pritej të rrotullonim regjistrin e përsëritjes për një kohë të gjatë (sepse procesi është në modalitetin me një fije, por kjo është një histori krejtësisht e ndryshme).
Përfundim: Pas një incidenti të tillë, u bë e qartë se praktika e kufizimit të shkrimeve për përdoruesit duhet të braktiset dhe i gjithë serveri duhet të deklarohet vetëm për lexim. Me këtë qasje, mund të jeni i sigurt se kopjet do të jenë të disponueshme në një moment kritik.
Optimizimi i qoftë edhe një pyetjeje të rëndë mund ta kthejë në jetë bazën e të dhënave
Edhe pse ne përditësojmë vazhdimisht katalogun në sajt, kërkesat që i bëmë serverëve Slave lejuan një vonesë të lehtë pas Masterit. Koha gjatë së cilës zbuluam dhe eliminuam problemin e skllevërve "të dalë papritur" ishte më shumë se "pengesa psikologjike" (gjatë kësaj kohe, çmimet mund të përditësoheshin dhe klientët do të shihnin të dhëna të vjetruara), dhe ne u detyruam të ndërronim të gjitha pyetjet në serverin kryesor të bazës së të dhënave. Si rezultat, faqja ishte e ngadaltë... por të paktën funksionoi. Dhe ndërsa Slave po shërohej, nuk na mbetej gjë tjetër veç optimizmit.
Ndërsa serverët Slave po rikuperoheshin, minutat zvarriteshin ngadalë, Masteri mbeti i mbingarkuar dhe ne hodhëm të gjitha përpjekjet tona në optimizimin e detyrave aktive sipas Rregullit Pareto: zgjodhëm pyetjet TOP që japin pjesën më të madhe të ngarkesës dhe filluam akordimin. Kjo u bë menjëherë në fluturim.
Një efekt interesant ishte se MySQL, e ngarkuar në kokërdhokët e syrit, i përgjigjet edhe një përmirësimi të vogël të proceseve. Optimizimi i disa pyetjeve që dhanë vetëm 5% të ngarkesës totale ka treguar tashmë një shkarkim të dukshëm të CPU. Si rezultat, ne ishim në gjendje të siguronim një rezervë të pranueshme burimesh për Masterin për të punuar me bazën e të dhënave dhe për të marrë kohën e nevojshme për të rivendosur kopjet.
Përfundim: Edhe një optimizim i vogël ju lejon të "mbijetoni" mbingarkesën për disa orë. Kjo ishte e mjaftueshme që ne të rivendosnim serverët me kopje. Nga rruga, ne do të diskutojmë anën teknike të optimizimit të pyetjeve në një nga postimet e mëposhtme. Pra, regjistrohuni në blogun tonë nëse mund të jetë i dobishëm për ju.
Organizimi i monitorimit të shëndetit të shërbimeve partnere
Ne përpunojmë porositë nga klientët, dhe për këtë arsye shërbimet tona ndërveprojnë vazhdimisht me API-të e palëve të treta - këto janë porta për dërgimin e SMS, platformat e pagesave, sistemet e rrugëtimit, një gjeokodues, Shërbimi Federal i Taksave dhe shumë sisteme të tjera. Dhe kur ngarkesa filloi të rritet me shpejtësi, ne filluam të hasim në kufizimet e API të shërbimeve tona partnere, për të cilat as nuk kishim menduar më parë.
Tejkalimi i papritur i kuotave të shërbimit të partnerit mund të rezultojë në kohën tuaj joproduktive. Shumë API bllokojnë klientët që tejkalojnë kufijtë, dhe në disa raste, një tepricë e kërkesave mund të mbingarkojë prodhimin e partnerit.
Për shembull, në kohën e rritjes së numrit të dërgesave, shërbimet shoqëruese nuk mund të përballonin detyrat e shpërndarjes së tyre dhe përcaktimit të rrugës. Si rezultat, rezultoi se porositë ishin bërë, por shërbimi që krijoi itinerarin nuk funksiononte. Duhet të them se logjistikët tanë bënë pothuajse të pamundurën në këto kushte, dhe ndërveprimi i qartë i ekipit ndihmoi në kompensimin e dështimeve të përkohshme të shërbimit. Por është joreale të përpunosh një vëllim të tillë aplikacionesh në mënyrë manuale gjatë gjithë kohës dhe pas një kohe do të hasnim në një hendek të papranueshëm midis porosive dhe ekzekutimit të tyre.
U morën një sërë masash organizative dhe puna e mirëkoordinuar e ekipit ndihmoi në blerjen e kohës ndërkohë që ramë dakord për kushte të reja dhe pritëm për modernizimin e shërbimeve nga disa partnerë. Ka API të tjera që ofrojnë qëndrueshmëri të lartë dhe norma të paperëndishme në rast të trafikut të lartë. Për shembull, në fillim, ne përdorëm një API të njohur të hartës për të përcaktuar adresën e pikës së dorëzimit. Por në fund të muajit, ata morën një faturë të rrumbullakët për gati 2 milion rubla. Pas kësaj, vendosëm ta zëvendësojmë shpejt. Nuk do të merrem me reklama, por do të them që shpenzimet tona janë ulur ndjeshëm.
Përfundim: Është e domosdoshme të monitorohen kushtet e punës së të gjitha shërbimeve partnere dhe t'i mbash parasysh ato. Edhe nëse sot duket se ata janë "me një diferencë të madhe" për ju, kjo nuk do të thotë që nesër ata nuk do të bëhen pengesë për rritjen. Dhe, natyrisht, është më mirë të bini dakord paraprakisht për kushtet financiare të kërkesave të shtuara për shërbimin.
Ndonjëherë rezulton se"(c) nuk ndihmon
Ne jemi mësuar të "gags" në bazën kryesore të të dhënave ose në serverët e aplikacioneve, por gjatë shkallëzimit, problemet mund të shfaqen aty ku nuk priten. Për kërkimin e tekstit të plotë në sajt, ne përdorim motorin Apache Solr. Me rritjen e ngarkesës, ne vumë re një rënie në kohën e përgjigjes dhe ngarkesa e CPU-së së serverit arriti në 100%. Çfarë mund të jetë më e thjeshtë - jepini më shumë burime kontejnerit Solr.
Në vend të rritjes së pritshme të performancës, serveri thjesht "vdiq". Ai u ngarkua menjëherë 100% dhe u përgjigj edhe më ngadalë. Fillimisht, ne kishim 2 bërthama dhe 2 GB RAM. Ne vendosëm të bëjmë atë që zakonisht ndihmon - i dhamë serverit 8 bërthama dhe 32 GB. Gjithçka u bë shumë më keq (ne do t'ju tregojmë saktësisht se si dhe pse në një postim të veçantë).
Në pak ditë, ne kuptuam ndërlikimet e kësaj çështje dhe arritëm performancën optimale me 8 bërthama dhe 32 GB. Ky konfigurim na lejon të vazhdojmë të rrisim ngarkesën sot, gjë që është shumë e rëndësishme, sepse rritja nuk është vetëm në aspektin e klientëve, por edhe në numrin e dyqaneve të lidhura - në 2 muaj numri i tyre është dyfishuar.
Përfundim: Metodat standarde si "shtoni më shumë hekur" nuk funksionojnë gjithmonë. Pra, kur shkallëzoni ndonjë shërbim, duhet të kuptoni mirë se si ai përdor burimet dhe ta testoni atë paraprakisht, punën e tij në kushte të reja.
Pa shtetësi është çelësi i shkallëzimit të thjeshtë horizontal
Në përgjithësi, ekipi ynë i përmbahet një qasjeje të njohur: shërbimet nuk duhet të kenë një gjendje të brendshme (pa shtetësi) dhe duhet të jenë të pavarura nga mjedisi i ekzekutimit. Kjo na lejoi t'i mbijetojmë rritjes së ngarkesës me shkallëzim të thjeshtë horizontal. Por ne kishim një përjashtim shërbimi - një mbajtës për detyra të gjata në sfond. Ai ishte i përfshirë në dërgimin e emaileve dhe sms-ve, përpunimin e ngjarjeve, gjenerimin e burimeve, importimin e çmimeve dhe aksioneve dhe përpunimin e imazheve. Kështu ndodhi që varej nga ruajtja lokale e skedarëve dhe ishte në një kopje të vetme.
Kur numri i detyrave në radhën e procesorit u rrit (dhe kjo ndodhi natyrshëm me një rritje të numrit të porosive), performanca e hostit që priste procesorin dhe ruajtjen e skedarëve u bë një faktor kufizues. Si rezultat, përditësimi i gamës dhe çmimeve, dërgimi i njoftimeve për përdoruesit dhe shumë funksione të tjera kritike të mbërthyera në radhë ndaluan. Ekipi Ops migroi me shpejtësi ruajtjen e skedarëve në ruajtjen e rrjetit të ngjashëm me S3, dhe kjo na lejoi të krijonim disa makina të fuqishme për të shkallëzuar mbajtësin e detyrave në sfond.
Përfundim: Rregulli pa shtetësi duhet të respektohet për të gjithë komponentët pa përjashtim, edhe nëse duket se "ne nuk do të pushojmë patjetër këtu". Është më mirë të shpenzoni pak kohë për organizimin e saktë të punës së të gjitha sistemeve sesa të rishkruani kodin me nxitim dhe të rregulloni një shërbim të mbingarkuar.
7 Parime për rritje intensive
Pavarësisht disponueshmërisë së kapaciteteve shtesë, në procesin e rritjes, ne kemi shkelur disa grabujë. Gjatë kësaj kohe, numri i porosive u rrit me më shumë se 4 herë. Tani ne ofrojmë më shumë se 17 porosi në ditë në 000 qytete dhe planifikojmë të zgjerojmë më tej gjeografinë - në gjysmën e parë të 62, shërbimi pritet të nisë në të gjithë Rusinë. Për të përballuar ngarkesën në rritje të punës, duke marrë parasysh gungat tashmë të mbushura, ne kemi nxjerrë për vete 2020 parime bazë për të punuar në një mjedis me rritje të vazhdueshme:
- Menaxhimi i incidentit. Ne kemi krijuar një bord në Jira, ku çdo incident pasqyrohet në formën e një bilete. Kjo do t'ju ndihmojë në fakt të jepni përparësi dhe të përfundoni detyrat që lidhen me incidentin. Në të vërtetë, në thelb, nuk është e tmerrshme të bësh gabime - është e tmerrshme të bësh gabime dy herë në të njëjtin rast. Për ato raste kur incidentet përsëriten para se të korrigjohet shkaku, duhet të përgatiten udhëzime për veprim, sepse gjatë një ngarkese të rëndë është e rëndësishme të reagohet me shpejtësi rrufeje.
- Monitorimi kërkohet për të gjithë elementët e infrastrukturës pa përjashtim. Ishte falë tij që ne ishim në gjendje të parashikonim rritjen e ngarkesës dhe të zgjidhnim saktë "fryqet e ngushta" për eliminimin me përparësi. Me shumë mundësi, nën një ngarkesë të lartë, gjithçka që as nuk keni menduar do të prishet ose do të fillojë të ngadalësohet. Prandaj, është mirë që të krijohen sinjalizime të reja menjëherë pas fillimit të incidenteve të para për t'i monitoruar dhe parashikuar ato.
- Sinjalizimet e sakta thjesht e nevojshme me një rritje të mprehtë të ngarkesës. Së pari, ata duhet të raportojnë saktësisht se çfarë është prishur. Së dyti, nuk duhet të ketë shumë sinjalizime, sepse bollëku i sinjalizimeve jo kritike çon në injorimin e të gjitha sinjalizimeve në përgjithësi.
- Aplikimet duhet të jenë pa shtetësi. Ne jemi siguruar që të mos ketë përjashtime nga ky rregull. Keni nevojë për pavarësi të plotë nga mjedisi i ekzekutimit. Për ta bërë këtë, mund të ruani të dhënat e përbashkëta në një bazë të dhënash ose, për shembull, direkt në S3. Më mirë akoma, ndiqni rregullat.. Gjatë një rritje të mprehtë të kohës, thjesht nuk ka asnjë mënyrë për të optimizuar kodin dhe do t'ju duhet të përballoni ngarkesën duke rritur drejtpërdrejt burimet llogaritëse dhe shkallëzimin horizontal.
- Kuotat dhe performanca e shërbimeve të jashtme. Me rritjen e shpejtë, problemi mund të lindë jo vetëm në infrastrukturën tuaj, por edhe në një shërbim të jashtëm. Gjëja më e bezdisshme është kur kjo nuk ndodh për shkak të një dështimi, por për shkak të arritjes së kuotave apo kufijve. Pra, shërbimet e jashtme duhet të jenë të shkallës së njëjtë si ju vetë.
- Ndani proceset dhe radhët. Kjo ndihmon shumë kur një prizë ndodh në një nga portat. Nuk do të kishim hasur në vonesa në transmetimin e të dhënave nëse radhët e plota për dërgimin e SMS nuk do të ndërhynin në shkëmbimin e njoftimeve ndërmjet sistemeve të informacionit. Dhe do të ishte më e lehtë të rritet numri i punëtorëve nëse do të punonin veçmas.
- realitetet financiare. Kur ka një rritje shpërthyese në flukset e të dhënave, nuk ka kohë për të menduar për tarifat dhe abonimet. Por ato duhet të mbahen mend, veçanërisht nëse jeni një kompani e vogël. Një faturë e madhe mund të vendoset nga pronari i çdo API, si dhe ofruesi juaj i pritjes. Prandaj lexoni me kujdes kontratat.
Përfundim
Jo pa humbje, por ne i mbijetuam kësaj faze, dhe sot përpiqemi t'u përmbahemi të gjitha parimeve të gjetura, dhe çdo makinë ka aftësinë të rrisë lehtësisht performancën x4 për të përballuar disa surpriza.
Në postimet e mëposhtme, ne do të ndajmë përvojën tonë të hetimit të rënies së performancës në Apache Solr, si dhe do të flasim për optimizimin e pyetjeve dhe se si ndërveprimi me Shërbimin Federal të Taksave e ndihmon kompaninë të kursejë para. Regjistrohuni në blogun tonë në mënyrë që të mos humbisni asgjë dhe na tregoni në komente nëse keni pasur probleme të ngjashme gjatë rritjes së trafikut.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , te lutem
A keni pasur ndonjëherë një ngadalësim/rënie të shërbimit gjatë një rritje të mprehtë të ngarkesës për shkak të:
-
55,6%Pamundësia për të shtuar shpejt burimet kompjuterike10
-
16,7%Kufijtë e infrastrukturës së ofruesit të pritjes3
-
33,3%Kufijtë e API6 të palës së tretë
-
27,8%Shkeljet e parimeve të pashtetësisë aplikimet e tyre5
-
88,9%Kodi jo optimal i shërbimeve të veta16
18 përdorues votuan. 6 përdorues abstenuan.
Burimi: www.habr.com