🥇Kuidas me talusime äkilist koormuse kasvu x10 kaugtööl ja milliseid järeldusi tegime

Tere, Habr! Viimase paariku jooksul oleme olnud väga huvitavas olukorras ja soovin jagada meie infrastruktuuri skaleerimise lugu. Selle aja jooksul kasvas SberMarket tellimustes neljakordselt ja käivitas teenuse 17 uues linnas. Toiduainete kohaletoimetamise nõudluse plahvatuslik kasv nõudis meie infrastruktuuri skaleerimist. Kõigi kõige huvitavamate ja kasulikumate järelduste lugemiseks vaata edasi.

Mina olen Dima Bobylev, SberMarketi tehniline direktor. Kuna see on meie blogi esimene postitus, siis ütlen paar sõna enda ja ettevõtte kohta. Eelmisel sügisel osalesin noorte liidrite konkursil Runetis. Selle konkursi jaoks kirjutasin väikese loo kuidas me SberMarketis näeme sisemist kultuuri ja lähenemist teenuse arendamisele. Kuigi konkursil võitmiseks ei õnnestunud, suutsin siiski välja mõelda peamised põhimõtted IT-ökosüsteemi arendamiseks.

Meeskonna juhtimisel on oluline mõista ja leida tasakaal selle vahel, mis on vajalik äri jaoks, ja iga konkreetse arendaja vajaduste vahel. Praegu kasvab SberMarket 13 korda aastas ja see mõjutab toodet, nõudes pidevat mahu ja arendustempo suurendamist. Vaatamata sellele eraldame arendajatele piisavalt aega eelanalüüsiks ja kvaliteetse koodi kirjutamiseks. Moodustatud lähenemine aitab mitte ainult töötava toote loomisel, vaid ka selle edasises skaleerimises ja arendamises. Selle kasvu tulemusena on SberMarket juba saanud toidukullerite teenuste liidriks: me toimetame iga päev umbes 18 tuhat tellimust, kuigi veel veebruari alguses oli neid umbes 3500.

Üks kord palus klient SberMarketi kulleril toimetada tooted talle kontaktivabalt — otse rõdule.

Aga liigume konkreetsemate asjade juurde. Viimased paar kuud oleme aktiivselt tegelenud meie ettevõtte infrastruktuuri suurendamisega. Selle vajadus sai seletatud nii välistest kui ka sisemistest teguritest. Samal ajal, kui kliendibaas laienes, kasvas ühendatud kaupluste arv algusaasta 90-st kuni rohkem kui 200-ni mai keskpaigaks. Loomulikult olime ette valmistunud, reserveerides põh infrastruktuuri, pluss lootes vertikaalse ja horisontaalse skaleerimise võimalusele kõigis Yandexi pilves asuvates virtuaalmasinates. Kuid praktika näitas: "Kõik, mis võib valesti minna, läheb ka valesti". Ja täna tahan jagada kõige huvitavamaid olukordi, mis on nendel nädalatel aset leidnud. Loodan, et meie kogemus osutub teile kasulikuks.

Slave on täielikus sõjalises valmiduses

Juba enne pandeemia algust kohtasime tõusu meie backend serverite päringutes. Tooted koju tellimise trend hakkas kiiresti kasvama ning COVID-19 esimeste eneseisolatsiooni meetmete sisseviimisega kasvas koormus dramaatiliselt päeva jooksul. Tekkis vajadus kiiresti vabastada master-serverid põhiteabe andmebaasist ja suunata osa lugemispäringutest replikaserveritele (slave).

Oli juba ette valmistatud sellele sammale, ja sellise manöövri jaoks olid juba käivitatud 2 slave-serverit. Nendel töötasid peamiselt andmevahetuse infovood partneritega genereerimise batch-ülesanded. Need protsessid genereerisid liigset koormust ja olid täiesti õigustatult paar kuud varem "kõrvadest välja viidud".

Kuna Slave'is toimus replikatsioon, järgnesime põhimõttele, et rakendused võivad nendega töötada ainult read only režiimis. Hädaolukorra taastamise plaan eeldas, et tõsise probleemi korral saame lihtsalt monteerida Slave Masteri kohale ja suunata kõik kirjutamis- ja lugemispäringud Slave'ile. Kuid soovisime kasutada replikaid ka analüüsi osakonna vajadusteks, seetõttu ei olnud serverid täielikult viidud read only staatusele ning igal hostil oli oma kasutajatute komplekt ja mõnedel olid kirjutamisõigused vahepealsete arvutuste tulemuste salvestamiseks.

Teatud koormuse tasemeni piisavalt, et meistril oli piisavalt nii kirjutamiseks kui ka lugemiseks http-päringute töötlemisel. Märtsi keskpaiku, just kui SberMarket otsustas täielikult üle minna kaugtööle, algas meil RPS-i järsk kasv. Üha rohkem meie kliente läks isolatsiooni või töötama kodust, mis kajastus koormuse näitajates.

Meistri tootlikkus lõpetas piisavuse, seega hakkasime osa raskemaid lugemisepäringuid viisama replikale. Kirjutamisekspäringute suunamiseks meistrisse ja lugemiseks orja, kasutasime ruby gem "Octopus". Loomasime spetsiaalse kasutaja postfixiga _readonly, kellel ei olnud kirjutamisõigust. Kuid ühe hosti konfiguratsiooni vea tõttu läks osa kirjutamisepäringutest orjaserverile kasutaja nimel, kellel olid vastavad õigused.

Probleem ei ilmunud kohe välja, kuna suurenenud koormus tõi endaga kaasa orjade viibimise. Andmete järjepidevuse probleem ilmnes hommikul, kui öiste importide järel ei olnud orjad meistrile järele jõudnud. Kandsime selle kõrge koormuse ja teenuse enda ühitamise arvele, mis oli seotud uute kaupluste avamisega. Kuid andmete edastamine mitme tunni viivitusega ei olnud aktsepteeritav ning suunatud protsessid teisele analüütilise orjale, kuna sellel olid bilotkasuuremad ressursid ja see ei olnud lugemisepäringutega koormatud (mida me ka ise seletamiseks kasutasime, et replikatsiooni lag'i puudumine).

Kui olime välja uurinud peamise orja "lagunemise" põhjused, oli analüütiline juba sama põhjuse tõttu töölt väljas. Vaatamata kahe täiendava serveri olemasolule, kuhu plaanisime koormuse viia meistri rikke korral, selgus, et kriitilisel hetkel ei olnud ühtegi.

Kuid kuna me tegime mitte ainult andmebaasi dump'i (taastamine tooks tollal umbes 5 tundi), vaid ka meistri serveri snapshot'i, õnnestus replika käivitada kahe tunni jooksul. Tõsi, pärast seda ootas meid replikatsiooni logi pealekandmine pika aja jooksul (sest protsess toimub ühe lõime režiimis, kuid see on juba hoopis teine lugu).

Kokkuvõte: Pärast sellist intsidenti sai selgeks, et tuleb loobuda kasutajate kirjutamise piirangute rakendamisest ja kuulutada server täielikult ainult lugemiseks. Sellise lähenemisega võib olla kindel, et koopiad on kriitilisel hetkel kergesti kättesaadavad.

Isegi ühe raske päringu optimeerimine võib andmebaasi "elule tagasi tuua".

Kuigi me uuendame kodulehe katalooge pidevalt, olid päringud, mida viisime üle Slave-serveritele, veidi järel Master-serverist. Aeg, mille jooksul avastasime ja kõrvaldasime "äkitselt eemaldunud" slave-serverite probleemi, oli pikem kui "psühholoogiline barjäär" (sel ajal võisid hinnad muutuda ning kliendid näeksid aegunud andmeid), ja me olime sunnitud suunama kõik päringud peamise andmebaasi serveri peale. Tulemuseks töötas veebisait aeglaselt… kuid vähemalt töötas. Ja seni, kuni Slave taastustöid tegime, polnud meil muud teha, kui optimeerida.

Kuni Slave-serverid taastusid, venisid minutid aeglaselt, Master oli ülekoormatud ja suunasin oma jõud aktiivsete ülesannete optimeerimisele "Pareto reegli" kohaselt: valisime kõrgeima koormuse andvad TOP-päringud ja alustasime häälestamist. See toimus otse "lennul".

Huvi pakkus see, et ülevoolav MySQL reageerib isegi väikesele protsesside paranemisele. Paar päringu optimeerimist, mis andis vaid 5% kogukoormusest, näitas juba selget CPU koormuse vähenemist. Tulemuseks suutsime tagada piisava ressursivarustuse Masteri andmebaasi tööks ja saada vajalik aeg koopiate taastamiseks.

Kokkuvõte: Isegi väike optimeerimine võimaldab "ellujäämist" ülekoormuse korral mitme tunni vältel. Meil oli selleks just piisavalt aega serverite taastamiseks, kus olid koopiad. Muide, arutame päringute optimeerimise tehnilist külge ühes järgmises postituses. Niisiis, tellige meie blogi, kui see võib teile kasulik olla.

Korraldage partnerite teenuste töömonitoring.

Käsitleme klientide tellimusi ning meie teenused suhtlevad pidevalt kolmandate osapoolte API-dega — need on SMS-i saatmise väravad, makseplatvormid, marsruutimise süsteemid, geokodeerija, FNS-i teenus ja paljusid teisi süsteeme. Ja kui koormus hakkas kiiresti suurenema, hakkasime me jõudma meie partnerite teenuste API-de piiranguteni, millest me varem isegi mitte ei mõelnud.

Ootamatu partnerite teenuste kvotide ületamine võib viia teie enda teenuse töökatkestuseni. Paljud API-d blokeerivad kliente, kes ületavad limiite, ja mõnel juhul võib liigne päringute arv partneri tootmist üle koormata.

Näiteks, kui kohaletehtud pakke hakkas kiiresti suurenema, ei suutnud saatmise teenused ülesandeid jaotada ning marsruute kindlaks määrata. Tulemuseks oli see, et tellimused olid esitatud, kuid marsruudi genereerimise teenus ei töötanud. Tuleb märkida, et meie logistika meeskond tegi sellistes oludes praktiliselt võimatut ning meeskonna selge koostöö aitas kompenseerida ajutisi teenuse katkemisi. Kuid sellist tellimuste hulka ei ole pidevalt võimalik käsitsi hallata ja mõne aja pärast oleksime silmitsi vastuvõetamatute viivitustega tellimuste ja nende täitmise vahel.

Võeti vastu mitmeid organisatsioonilisi meetmeid ja ühtne meeskonna töö aitas kokku hoida aega, kuni me lepime uute tingimuste üle ja ootame mõnede partnerite teenuste moderniseerimist. On ka teisi API-sid, mis pakuvad suurepäraseid vastupidavuse tasemeid ja palju soodsaid tariife suurte liiklustasemetega. Näiteks alguses kasutasime üht tuntud kaardistamise API-d, et määrata kohaletoimetamise aadress. Kuid kuu lõpuks saime peaaegu 2 miljoni rubla suuruse arve. Pärast seda otsustasime selle kiiresti asendada. Ei hakka reklaamima, aga ütleksin, et meie kulud vähenesid märkimisväärselt.

Kokkuvõte: Oluline on jälgida võimaluste töötingimusi kõigi partnerite teenuste osas ja arvesse võtta neid. Isegi kui täna tundub, et need on teile 'suure varuga', ei tähenda see, et need ei takistaks teid kasvu hommikul. Ja loomulikult on parem eelnevalt kokku leppida teenusele suurenenud päringute finants tingimustes.

Mõnikord selgub, et „on rohkem kulda” (c) ei aita

Me oleme harjunud „ummikutega“ peamises andmebaasis või rakenduste serverites, kuid skaleerimise korral võivad probleemid ilmneda seal, kus neid ei oodata. Täisteksti otsimiseks veebilehel kasutame Apache Solr mootorit. Koormuse kasvu tõttu oleme märganud reageerimise aja vähenemist ning serveri protsessori koormus jõudis juba 100%ni. Mis võiks olla lihtsam - anname Solr konteinerile rohkem ressursse.

Oodatud jõudluse kasvu asemel tõmmati server lihtsalt „kinnijäämisele“. See laadis kohe 100% ja vastas veel aeglasemalt. Alguses oli meil 2 südamikku ja 2 GB RAM-i. Otsustasime teha seda, mis tavaliselt aitab - andsime serverile 8 südamikku ja 32 GB. Kõik muutus palju halvemaks (kuidas täpselt ja miks - sellest räägime eraldi postituses).

Mõne päeva jooksul saime selle küsimuse nüanssidest aru ning saavutasime optimaalse jõudluse 8 südamiku ja 32 GB juures. See konfiguratsioon võimaldab meil ka täna koormust suurendada, mis on väga oluline, kuna kasv ei toimu mitte ainult klientide arvu, vaid ka ühendatud poodide arvu osas - kahe kuu jooksul on nende arv kahekordistunud.

Kokkuvõte: Tavalised meetodid nagu „lihtsalt lisa rohkem rauda“ ei tööta alati. Niisiis tuleb igasuguste teenuste skaleerimise juures hästi mõista, kuidas need ressursse kasutavad ja eelnevalt testida nende tööd uutes tingimustes.

Stateless - võti lihtsaks horisontaalseks skaleerimiseks.

Üldiselt järgib meie meeskond tuntud lähenemist: teenustel ei peaks olema sisemist seisundit (stateless) ja nad peaksid olema sõltumatud töötamisest. See võimaldas meil taluda koormuse kasvu lihtsa horisontaalse skaleerimise abil. Kuid meil oli üks teenus-erand - pikaajaliste taustategevuste töötleja. See tegeles e-kirjade ja SMS-ide saatmise, sündmuste töötlemise, feedide genereerimise, hindade ja varude importimise ning piltide töötlemisega. Nii kujunes, et see sõltus kohalikust failide salvestamisest ja oli ainus eksemplar.

Kui järjekorras olevate ülesannete arv kasvas (ja see juhtus loomulikult koos tellimuste arvu kasvuga), muutus host, millel töötasid töötleja ja failide salvestamine, piiravaks teguriks. Tulemusena peatus tootevaliku ja hindade värskendamine, kasutajatele teavituste saatmine ja palju muid kriitilisi funktsioone, mis jäid järjekorda kinni. Ops meeskond migreeris kiiresti failide salvestamise S3-taolisse võrgu salvestusse, mis võimaldas meil tõsta mitu võimsat masinat, et skaleerida taustatöötlajat.

Kokkuvõte: Reeglit Stateless tuleb järgida kõigi komponentide puhul, isegi kui tundub, et "siin me kindlasti ei komista". Paremini on kulutada natuke aega kõigi süsteemide töö korraldamiseks, kui hiljem kiirustades koodi ümber kirjutada ja teenust, mis kogeb ülemäärast koormust, parandada.

7 põhimõtet intensiivseks kasvuks

Hoolimata täiendavate võimsuste kättesaadavusest, puutusime kasvamise käigus mitmete probleemide otsa. Selle aja jooksul on tellimuste arv kasvanud rohkem kui 4 korda. Praegu toimetame juba üle 17 000 tellimuse päevas 62 linnas ja kavatseme geograafiat veelgi laiendada – 2020. aasta esimeses pooles on oodata teenuse käivitamist kogu Venemaa ulatuses. Kuidas toime tulla kasvava koormusega, arvestades juba saadud õpetusi, oleme välja töötanud 7 põhise põhimõtte, kuidas pideva kasvu tingimustes töötada:

Incidendi juhtimine. Oleme loonud Jira-s tahvli, kus iga juhtum kajastub piletina. See aitab tegelikult prioriseerida ja täita juhtumiga seotud ülesandeid. Lõppude lõpuks ei ole viga teha viga - hirmutav on teha sama viga kaks korda. Juhtudel, kui juhtumid korduvad enne, kui suudame põhjuse kõrvaldada, peab olema valmis tegevusjuhend, sest suure koormuse ajal on oluline reageerida kiiresti.
Jälgimine see all elements of infrastructure without exception. It is precisely thanks to this that we were able to predict the increase in load and correctly identify "bottlenecks" for prioritization of resolution. Most likely, under high load, everything you didn't think would fail or start to lag behind. Therefore, it is best to create new alerts immediately after the first incidents occur to monitor and anticipate them.
Correct alerts are simply essential with a sharp increase in load. Firstly, they must accurately report what exactly has broken. Secondly, there shouldn't be too many alerts, as an abundance of non-critical alerts leads to all notifications being ignored.
Applications must be stateless. We have confirmed that there should be no exceptions to this rule. Complete independence from the runtime environment is necessary. For this, you can store shared data in a database or, for example, directly in S3. Even better, follow the rules https://12factor.net. During a sharp increase in time, optimizing code is simply not an option, and handling the load will have to be done by directly increasing computational resources and horizontal scaling.
Quotas and performance of external services. With rapid growth, problems can arise not only in your infrastructure but also in external services. The most frustrating thing is when this happens not due to a failure but because of reaching quotas or limits. Therefore, external services must scale as well as you do.
Separate processes and queues. This greatly helps when there is a bottleneck on one of the gateways. We wouldn't have encountered delays in data transmission if the filled SMS sending queues hadn’t interfered with the exchange of notifications between information systems. Moreover, increasing the number of workers would have been easier if they operated separately.
Financial realities. When there is an explosive growth in data streams, there’s no time to think about tariffs and subscriptions. However, one must remember them, especially if you are a small company. A hefty bill can be issued by any API owner as well as your hosting provider. So, it is important to read agreements carefully.

Kokkuvõte

Kaotiliste kaotustega, kuid me oleme selle etapi üle saanud ja täna püüame järgida kõiki leidunud põhimõtteid, samas kui iga masin omab võimalust kergelt tõsta jõudlust kuni 4 korda, et toime tulla ootamatustega.

Järgmistes postitustes jagame oma kogemusi Apache Solr'i jõudluse vähenemise uurimisel ning räägime päringute optimeerimisest ja sellest, kuidas suhtlemine FNS-iga aitab ettevõttel raha säästa. Tellige meie blogi, et mitte midagi vahele jätta, ning rääkige kommentaarides, kas olete sarnaseid ebameeldivusi kogenud liikluse kasvu ajal.