Tere, Habr! Oleme viimased paar kuud elanud väga huvitavas olukorras ja tahaksin jagada meie infrastruktuuri skaleerimise lugu. Selle aja jooksul on SberMarket tellimuste arv kasvanud 4 korda ja käivitanud teenuse 17 uues linnas. Toidukaupade kohaletoimetamise nõudluse plahvatuslik kasv nõudis meilt oma infrastruktuuri laiendamist. Lugege lõike alt kõige huvitavamate ja kasulikumate järelduste kohta.
Minu nimi on Dima Bobylev, olen SberMarketi tehniline direktor. Kuna see on esimene postitus meie blogis, siis ütlen paar sõna enda ja ettevõtte kohta. Eelmisel sügisel osalesin noorte Runeti juhtide konkursil. Võistluse jaoks I selle kohta, kuidas me SberMarketis näeme sisemist kultuuri ja lähenemist teenuste arendamisele. Ja kuigi mul ei õnnestunud konkurssi võita, sõnastasin enda jaoks IT-ökosüsteemi arendamise aluspõhimõtted.
Meeskonna juhtimisel on oluline mõista ja leida tasakaal ettevõtte vajaduste ja iga üksiku arendaja vajaduste vahel. Nüüd kasvab SberMarket aasta-aastalt 13 korda ja see mõjutab toodet, mis nõuab pidevat arengumahtu ja -tempo suurendamist. Vaatamata sellele eraldame arendajatele piisavalt aega eelanalüüsiks ja kvaliteedikodeerimiseks. Väljakujunenud lähenemine aitab mitte ainult toimiva toote loomisel, vaid ka selle edasisel skaleerimisel ja arendamisel. Selle kasvu tulemusena on SberMarket juba tõusnud liidriks toidukaupade kohaletoimetamise teenuste hulgas: tarnime iga päev umbes 18 tuhat tellimust, kuigi veebruari alguses oli neid umbes 3500.
Ühel päeval palus klient SberMarketi kulleril toidukaubad talle kontaktivabalt toimetada – otse rõdule.
Aga läheme edasi konkreetsete asjade juurde. Viimase paari kuu jooksul oleme oma ettevõtte infrastruktuuri aktiivselt skaleerinud. Seda vajadust seletati väliste ja sisemiste teguritega. Koos kliendibaasi laienemisega kasvas ühendatud kaupluste arv aasta alguse 90-lt mai keskpaigaks enam kui 200-le. Muidugi olime ette valmistatud, reserveerisime põhitaristu, lisaks arvestasime kõigi Yandexi pilves hostitud virtuaalmasinate vertikaalse ja horisontaalse skaleerimise võimalusega. Praktika on aga näidanud: "Kõik, mis võib valesti minna, läheb valesti." Ja täna tahan jagada kõige huvitavamaid olukordi, mis nende nädalate jooksul juhtunud on. Loodan, et meie kogemus on teile kasulik.
Slave on täielikus lahinguvalmiduses
Juba enne pandeemia algust seisime silmitsi meie taustaserveritele saadetavate päringute arvu suurenemisega. Toidukaupade kojutoomiseks tellimise trend hakkas hoogu saama ning esimeste COVID-19-st tingitud isoleerimismeetmete kasutuselevõtuga kasvas töökoormus kogu päeva jooksul hüppeliselt. Tekkis vajadus põhiandmebaasi peaserverid kiiresti maha laadida ja osa lugemispäringuid replikaserveritele (slave) üle kanda.
Valmistusime selleks sammuks ette ja selliseks manöövriks käivitati juba 2 orjaserverit. Neid kasutati peamiselt pakettülesanneteks, genereerides teabevooge partneritega andmete vahetamiseks. Need protsessid tekitasid lisakoormuse ja võeti paar kuud varem võrrandist täiesti õigustatult välja.
Kuna replikatsioon toimus Slave'is, järgisime põhimõtet, et rakendused saavad nendega töötada ainult kirjutuskaitstud režiimis. Katastroofi taastamise plaan eeldas, et katastroofi korral võime lihtsalt paigaldada Slave'i Masteri asemele ja lülitada kõik kirjutamis- ja lugemistaotlused alamseadmele. Kuid soovisime kasutada ka analüütikaosakonna vajadusteks koopiaid, nii et servereid ei lülitatud täielikult kirjutuskaitstud olekusse, vaid igal hostil oli oma kasutajate komplekt ja mõnel oli kirjutamisõigus, et salvestada vahepealseid arvutustulemusi.
Kuni teatud koormustasemeni oli meil http-päringute töötlemisel piisavalt meistrit nii kirjutamiseks kui lugemiseks. Märtsi keskel, just siis, kui Sbermarket otsustas täielikult kaugtööle üle minna, hakkas meie RPS plahvatuslikult kasvama. Üha enam meie kliente läks isolatsiooni või töötas kodus, mis mõjutas meie töökoormuse näitajaid.
"Master" jõudlus ei olnud enam piisav, nii et hakkasime mõnda raskeimat lugemistaotlust koopiasse üle kandma. Kirjutamispäringute läbipaistvaks suunamiseks ülemseadmele ja taotluste lugemiseks alamseadmele kasutasime rubiinkivi "" Lõime spetsiaalse kasutaja, millel on _readonly postfix ilma kirjutamisõigusteta. Kuid ühe hosti konfiguratsiooni tõrke tõttu läks osa kirjutamistaotlusi vastavate õigustega kasutaja nimel orjaserverisse.
Probleem ei ilmnenud kohe, sest... suurenenud koormus suurendas orjade mahajäämust. Andmete ebakõla avastati hommikul, kui pärast igaõhtust importi ei jõudnud orjad peremehele järele. Selgitasime seda teenuse enda suure koormuse ja uute kaupluste avamisega seotud impordiga. Kuid andmete saatmine mitmetunnise viivitusega oli vastuvõetamatu ja me lülitasime protsessid teisele analüütilisele alamale, kuna sellel oliоsuuremad ressursid ja seda ei laaditud lugemistaotlustega (sellega selgitasime endale replikatsiooni viivituse puudumist).
Kui selgitasime välja põhiorja “levitamise” põhjused, oli analüütiline juba samal põhjusel läbi kukkunud. Vaatamata kahe lisaserveri olemasolule, kuhu plaanisime master-tõrke korral koormuse üle kanda, selgus kahetsusväärse vea tõttu, et kriitilisel hetkel polnud ühtegi saadaval.
Aga kuna me ei tühjendanud mitte ainult andmebaasi (sel ajal võttis taastamine umbes 5 tundi), vaid ka põhiserveri hetktõmmist, õnnestus meil replika käivitada 2 tunni jooksul. Tõsi, pärast seda seisime silmitsi replikatsioonilogi rullumisega pikka aega (kuna protsess töötab ühe lõimega režiimis, kuid see on täiesti erinev lugu).
Järeldus: Pärast sellist juhtumit sai selgeks, et tuleb loobuda tavast piirata kasutajate kirjutamist ja kuulutada kogu server kirjutuskaitstuks. Selle lähenemisviisi korral pole kahtlust, et koopiad on kriitilistel aegadel saadaval.
Isegi ühe raske päringu optimeerimine võib andmebaasi uuesti ellu äratada
Ehkki värskendame saidil pidevalt kataloogi, võimaldasid Slave-serveritele saadetud päringud Masterilt väikese viivituse. Aeg, mille jooksul avastasime ja kõrvaldasime orjade "äkitselt distantsist lahkumise" probleemi, oli rohkem kui "psühholoogiline barjäär" (selle aja jooksul oleks võinud hindu uuendada ja kliendid oleksid näinud aegunud andmeid) ja olime sunnitud lülitage kõik päringud põhiandmebaasiserverisse. Selle tulemusena oli sait aeglane... aga vähemalt töötas. Ja kuni Slave taastus, ei jäänud meil muud üle kui optimeerida.
Slave-serverite taastumise ajal möödusid minutid aeglaselt, Master jäi ülekoormatuks ja me tegime kõik oma jõupingutused aktiivsete ülesannete optimeerimiseks "Pareto reegli" järgi: valisime TOP-päringud, mis genereerivad suurema osa koormusest, ja alustasime häälestamist. . Seda tehti kohe lennult.
Huvitav efekt oli see, et võimsuseni laetud MySQL reageeris isegi vähesele protsesside paranemisele. Paari päringu optimeerimine, mis andsid vaid 5% kogukoormusest, on juba näidanud märgatavat protsessori koormust. Selle tulemusel suutsime anda Masterile andmebaasiga töötamiseks vastuvõetava hulga ressursse ja hankida koopiate taastamiseks vajalikku aega.
Järeldus: Isegi väike optimeerimine võimaldab teil ülekoormuse all mitu tundi "ellu jääda". Sellest piisas meile serverite taastamiseks koopiatega. Muide, päringu optimeerimise tehnilist poolt käsitleme ühes järgmistest postitustest. Seega tellige meie ajaveebi, kui leiate, et see on kasulik.
Korraldada partnerteenuste toimimise jälgimist
Töötleme klientide tellimusi ja seetõttu suhtlevad meie teenused pidevalt kolmandate osapoolte API-dega - need on SMS-ide saatmise lüüsid, makseplatvormid, marsruutimissüsteemid, geokooder, föderaalne maksuteenistus ja paljud muud süsteemid. Ja kui koormus hakkas kiiresti kasvama, hakkasime meie partnerteenuste API-piirangutega kokku puutuma, millele me varem isegi ei mõelnud.
Partnerteenuste kvootide ootamatu ületamine võib põhjustada teie enda seisakuid. Paljud API-d blokeerivad kliente, mis ületavad limiite, ja mõnel juhul võib liiga palju taotlusi partneri tootmist üle koormata.
Näiteks tarnete arvu kasvades ei tulnud saateteenistused toime nende jaotamise ja marsruutide määramisega. Selle tulemusena selgus, et tellimusi tehti, kuid marsruudi loonud teenus ei töötanud. Peab ütlema, et meie logistikud tegid nendes tingimustes peaaegu võimatut ning meeskonna selge suhtlus aitas kompenseerida ajutisi teenindushäireid. Kuid sellist tellimuste mahtu pidevalt käsitsi töödelda on ebareaalne ja mõne aja pärast seisaksime silmitsi lubamatu vahega tellimuste ja nende täitmise vahel.
Võeti kasutusele mitmeid korralduslikke meetmeid ning meeskonna hästi koordineeritud töö aitas aega võita, samal ajal kui leppisime kokku uutes tingimustes ja ootasime mõnelt partnerilt teenuste kaasajastamist. On ka teisi API-sid, millel on suur vastupidavus ja ennekuulmatu kiirus suure liikluse korral. Näiteks alguses kasutasime tarnepunkti aadressi määramiseks üht tuntud kaardistamise API-d. Kuid kuu lõpus saime korraliku arve ligi 2 miljoni rubla eest. Pärast seda otsustasid nad selle kiiresti välja vahetada. Ma ei hakka reklaamiga tegelema, kuid ütlen, et meie kulud on oluliselt vähenenud.
Järeldus: Kõigi partnerteenuste töötingimusi tuleb kindlasti jälgida ja neid silmas pidada. Isegi kui täna tundub, et need on teie jaoks "suure marginaaliga", ei tähenda see, et homme ei saaks neist kasvu takistuseks. Ja loomulikult on parem teenuse suurenenud taotluste rahalised tingimused eelnevalt kokku leppida.
Mõnikord selgub, et ""(c) ei aita
Oleme harjunud põhiandmebaasis või rakendusserverites “gagidega”, kuid skaleerimisel võivad tõrked ilmneda seal, kus neid oodata ei osatud.Täistekstiotsinguks saidil kasutame Apache Solr mootorit. Koormuse kasvades märkasime reageerimisaja lühenemist ja serveriprotsessori koormus jõudis juba 100% -ni. Mis saab olla lihtsam - anname Solriga konteinerile rohkem ressursse.
Oodatud jõudluse kasvu asemel server lihtsalt "suri". See laaditi kohe 100% ja reageeris veelgi aeglasemalt. Algselt oli meil 2 tuuma ja 2 GB muutmälu. Otsustasime teha seda, mis tavaliselt aitab – andsime serverile 8 tuuma ja 32 GB. Kõik läks palju hullemaks (räägime teile, kuidas ja miks täpselt, eraldi postituses).
Mõne päeva jooksul saime aru selle probleemi keerukusest ja saavutasime 8 tuuma ja 32 GB optimaalse jõudluse. Selline konfiguratsioon võimaldab meil täna jätkata koormuse suurendamist, mis on väga oluline, sest kasv pole mitte ainult klientide, vaid ka ühendatud kaupluste arvus – 2 kuuga on nende arv kahekordistunud.
Järeldus: Tavalised meetodid, nagu "lisa rohkem rauda", ei tööta alati. Nii et mis tahes teenuse skaleerimisel peab teil olema hea arusaam sellest, kuidas see ressursse kasutab, ja eelnevalt katsetada selle toimimist uutes tingimustes.
Kodakondsuseta on lihtsa horisontaalse skaleerimise võti
Üldiselt järgib meie meeskond üldtuntud lähenemisviisi: teenustel ei tohiks olla sisemist olekut (kodakondsuseta) ja need peaksid olema täitmiskeskkonnast sõltumatud. See võimaldas meil koormuse kasvuga toime tulla lihtsalt horisontaalse skaleerimisega. Kuid meil oli üks erandteenus – pikkade taustaülesannete käsitleja. Ta tegeles meilide ja SMS-ide saatmise, sündmuste töötlemise, voogude genereerimise, hindade ja laoseisude importimise ning piltide töötlemisega. Juhtus nii, et see sõltus kohalikust failisalvestusest ja oli ühes eksemplaris.
Kui protsessorijärjekorras olevate ülesannete arv suurenes (ja see juhtus loomulikult tellimuste arvu suurenemisega), sai piiravaks teguriks selle hosti jõudlus, millel protsessor ja failimälu asusid. Selle tulemusena lakkasid sortimendi ja hindade uuendamine, kasutajatele teadete saatmine ja paljud muud järjekorda kinni jäänud kriitilised funktsioonid. Opsi meeskond viis failimälu kiiresti üle S3-laadsele võrgusalvestusele ja see võimaldas meil tõsta mitu võimsat masinat, et skaleerida taustaülesannete protsessorit.
Järeldus: Kodakondsuseta reeglit tuleb järgida eranditult kõigi komponentide puhul, isegi kui tundub, et "me ei saa siin kindlasti vastu panna". Parem on kulutada veidi aega kõigi süsteemide töö õigeks korraldamiseks, kui kiirustades koodi ümber kirjutada ja ülekoormatud teenust parandada.
7 põhimõtet intensiivseks kasvuks
Vaatamata lisavõimsuse olemasolule oleme kasvuprotsessis astunud mitmele veale. Selle aja jooksul kasvas tellimuste arv enam kui 4 korda. Nüüd tarnime juba rohkem kui 17 000 tellimust päevas 62 linnas ja plaanime geograafiat veelgi laiendada – 2020. aasta esimesel poolel loodetakse teenus käivitada kogu Venemaal. Kasvava töökoormusega toimetulekuks oleme niigi täis koonuseid arvestades välja töötanud 7 põhiprintsiipi pideva kasvu tingimustes töötamiseks:
- Juhtumijuhtimine. Tegime Jirasse tahvli, kus iga juhtum kajastub pileti kujul. See aitab tegelikult tähtsuse järjekorda seada ja juhtumitega seotud ülesandeid täita. Lõppude lõpuks pole sisuliselt hirmutav teha vigu, kuid hirmutav on teha vigu samal korral kaks korda. Juhtudeks, kus intsidendid korduvad enne, kui põhjust on jõutud kõrvaldada, peaksid olema valmis tegutsemisjuhised, sest suure koormuse ajal on oluline reageerida välkkiirelt.
- Jälgimine nõutav eranditult kõigi infrastruktuuri elementide jaoks. Just tänu temale suutsime prognoosida koormuse kasvu ja õigesti valida "pudelikaelad" kõrvaldamise prioriseerimiseks. Tõenäoliselt puruneb suure koormuse korral või hakkab aeglustuma kõik, millele te pole kunagi mõelnud. Seetõttu on kõige parem luua uued hoiatused kohe pärast esimeste intsidentide ilmnemist, et neid jälgida ja ennetada.
- Õiged hoiatused lihtsalt vajalik, kui koormus järsult suureneb. Esiteks peavad nad teatama, mis täpselt on katki. Teiseks ei tohiks hoiatusi palju olla, sest mittekriitiliste hoiatuste rohkus viib kõigi hoiatuste täieliku ignoreerimiseni.
- Taotlused peavad olema kodakondsuseta. Oleme veendunud, et sellest reeglist ei tohiks teha erandeid. Vajame täielikku sõltumatust käituskeskkonnast. Selleks saab ühiskasutuses olevaid andmeid salvestada andmebaasi või näiteks otse S3-sse. Veelgi parem, järgige reegleid.. Aja järsu pikenemise ajal pole lihtsalt võimalust koodi optimeerida ja peate koormusega toime tulema, suurendades otseselt arvutusressursse ja horisontaalset skaleerimist.
- Kvoodid ja välisteenuste osutamine. Kiire kasvu korral võib probleem tekkida mitte ainult teie infrastruktuuris, vaid ka välisteenuses. Kõige tüütum on see, kui see juhtub mitte ebaõnnestumise, vaid kvootide või piirangute saavutamise tõttu. Nii et välisteenused peaksid laienema sama hästi kui teie.
- Eraldi protsessid ja järjekorrad. See aitab palju, kui mõnes lüüsis on ummistus. Meil ei tekiks andmeedastuse viivitusi, kui täistekstid SMS-ide saatmise järjekorrad ei segaks infosüsteemide vahelist teadete vahetamist. Ja tööliste arvu oleks lihtsam suurendada, kui nad töötaksid eraldi.
- Finantsreaalsus. Andmevoogude plahvatusliku kasvu korral pole aega tariifidele ja liitumislepingutele mõelda. Kuid peate neid meeles pidama, eriti kui olete väike ettevõte. Mis tahes API omanik ja ka teie hostiteenuse pakkuja võivad saada suure arve. Seetõttu peate lepingud hoolikalt läbi lugema.
Järeldus
Mitte ilma kaotusteta, kuid elasime selle etapi üle ja täna püüame järgida kõiki leitud põhimõtteid ning igal masinal on võimalus lihtsalt x4 jõudlust suurendada, et tulla toime mõne ootamatu sündmusega.
Järgmistes postitustes jagame oma kogemusi Apache Solri jõudluse halvenemise uurimisel ning räägime ka päringu optimeerimisest ja sellest, kuidas suhtlemine föderaalse maksuteenistusega aitab ettevõttel raha säästa. Liituge meie ajaveebiga, et te millestki ilma ei jääks, ja andke meile kommentaarides teada, kas teil oli liikluse kasvu ajal sarnaseid probleeme.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Kas olete kunagi kogenud teeninduse aeglustumist/langust koormuse järsu suurenemise tõttu järgmistel põhjustel:
-
55,6%Suutmatus kiiresti arvutiressursse lisada10
-
16,7%Majutusteenuse pakkuja infrastruktuuri piirangud3
-
33,3%Kolmanda osapoole API-de piirangud6
-
27,8%Nende rakenduste kodakondsuseta põhimõtete rikkumine5
-
88,9%Omateenuste mitteoptimaalne kood16
18 kasutajat hääletas. 6 kasutajat jäi erapooletuks.
Allikas: www.habr.com