Hei, Habr! Olemme eläneet erittäin mielenkiintoisessa tilanteessa viimeiset pari kuukautta ja haluaisin jakaa infrastruktuurimme skaalaustarinamme. Tänä aikana SberMarket on kasvanut tilausten määrä 4-kertaiseksi ja lanseerannut palvelun 17 uudessa kaupungissa. Päivittäistavaratoimitusten kysynnän räjähdysmäinen kasvu vaati meitä skaalaamaan infrastruktuurimme. Lue mielenkiintoisimmista ja hyödyllisimmistä johtopäätöksistä leikkauksen alla.
Nimeni on Dima Bobylev, olen SberMarketin tekninen johtaja. Koska tämä on ensimmäinen postaus blogissamme, sanon muutaman sanan itsestäni ja yrityksestä. Viime syksynä osallistuin nuorten Runet-johtajien kilpailuun. Kilpailuun I siitä, miten me SberMarketilla näemme sisäisen kulttuurin ja lähestymistavan palvelukehitykseen. Ja vaikka en onnistunut voittamaan kilpailua, muotoilin itselleni IT-ekosysteemin kehittämisen perusperiaatteet.
Tiimiä johtaessa on tärkeää ymmärtää ja löytää tasapaino liiketoiminnan tarpeiden ja kunkin yksittäisen kehittäjän tarpeiden välillä. Nyt SberMarket kasvaa 13 kertaa vuodessa, ja tämä vaikuttaa tuotteeseen vaatien sen jatkuvasti lisäämään volyymia ja kehitysvauhtia. Tästä huolimatta varaamme kehittäjille riittävästi aikaa alustavaan analysointiin ja laatukoodaukseen. Muodostunut lähestymistapa auttaa paitsi toimivan tuotteen luomisessa myös sen skaalaamisessa ja kehittämisessä. Kasvun myötä SberMarketista on jo noussut johtaja päivittäistavaratoimitusten joukossa: toimitamme päivittäin noin 18 tuhatta tilausta, vaikka helmikuun alussa niitä oli noin 3500 XNUMX.
Eräänä päivänä asiakas pyysi SberMarket-kuriiria toimittamaan elintarvikkeita hänelle ilman kontaktia - suoraan parvekkeelle
Mutta siirrytään yksityiskohtiin. Olemme viime kuukausien aikana skaalaneet aktiivisesti yrityksemme infrastruktuuria. Tämä tarve selittyy ulkoisilla ja sisäisillä tekijöillä. Asiakaskunnan laajentumisen myötä verkkokauppojen määrä kasvoi vuoden alun 90:stä toukokuun puoliväliin mennessä yli 200:aan. Tietysti olimme valmistautuneita, varasimme pääinfrastruktuurin ja luotimme mahdollisuuteen skaalata kaikki Yandex-pilvessä isännöidyt virtuaalikoneet pysty- ja vaakasuunnassa. Käytäntö on kuitenkin osoittanut: "Kaikki mikä voi mennä pieleen, menee pieleen." Ja tänään haluan jakaa mielenkiintoisimmat tilanteet, joita on tapahtunut näiden viikkojen aikana. Toivon, että kokemuksemme on hyödyllinen sinulle.
Slave on täydessä taisteluvalmiudessa
Jo ennen pandemian alkamista kohtasimme taustapalvelimiimme lähetettyjen pyyntöjen määrän kasvun. Elintarvikkeiden kotiinkuljetustrendi alkoi vahvistua, ja ensimmäisten COVID-19:n aiheuttamien eristystoimenpiteiden käyttöönoton myötä työmäärä kasvoi dramaattisesti päivän aikana. Päätietokannan pääpalvelimet piti nopeasti purkaa ja osa lukupyynnöistä siirtää replikapalvelimille (slave).
Valmistauduimme tähän vaiheeseen etukäteen, ja 2 orjapalvelinta käynnistettiin jo tällaista toimenpidettä varten. Niitä käytettiin pääasiassa erätehtäviin tietosyötteiden tuottamiseksi tietojen vaihtoa varten kumppaneiden kanssa. Nämä prosessit loivat ylimääräistä taakkaa, ja ne poistettiin aivan oikeutetusti yhtälöstä pari kuukautta aikaisemmin.
Koska replikointi tapahtui Slave-laitteessa, noudatimme periaatetta, jonka mukaan sovellukset voivat toimia niiden kanssa vain luku -tilassa. Disaster Recovery Plan oletti, että katastrofin sattuessa voisimme yksinkertaisesti asentaa Slaven isäntälaitteen tilalle ja siirtää kaikki kirjoitus- ja lukupyynnöt orjalle. Halusimme kuitenkin käyttää replikoita myös analytiikkaosaston tarpeisiin, joten palvelimia ei siirretty kokonaan vain luku -tilaan, vaan jokaisella isännillä oli oma käyttäjäjoukkonsa ja osalla oli kirjoitusoikeudet välilaskennan tulosten tallentamiseen.
Tiettyyn kuormitustasoon asti meillä oli tarpeeksi isäntä sekä kirjoittamiseen että lukemiseen http-pyyntöjen käsittelyssä. Maaliskuun puolivälissä, juuri kun Sbermarket päätti siirtyä kokonaan etätyöhön, RPS:mme alkoi kasvaa eksponentiaalisesti. Yhä useammat asiakkaistamme joutuivat eristäytymään tai työskentelemään kotoa käsin, mikä vaikutti työmäärämittareihimme.
"Masterin" suorituskyky ei enää riittänyt, joten aloimme siirtää joitain raskaimpia lukupyyntöjä replikaan. Kirjoituspyyntöjen reitittämiseksi läpinäkyvästi isännälle ja pyyntöjen lukemiseen orjalle käytimme rubiinikiviä "" Loimme erityisen käyttäjän, jolla on _readonly postfix ilman kirjoitusoikeuksia. Mutta johtuen virheestä yhden isäntäkoneen kokoonpanossa, osa kirjoituspyynnöistä meni orjapalvelimelle sellaisen käyttäjän puolesta, jolla oli asianmukaiset oikeudet.
Ongelma ei ilmennyt heti, koska... lisääntynyt kuormitus lisäsi orjien viivettä. Tietojen epäjohdonmukaisuus havaittiin aamulla, kun iltaisten tuontien jälkeen orjat eivät "saaneet kiinni" isäntään. Syyksimme tämän itse palveluun kohdistuvan suuren kuormituksen ja uusien myymälöiden avaamiseen liittyvän tuonnin. Mutta tietojen lähettämistä usean tunnin viiveellä ei voida hyväksyä, ja vaihdoimme prosessit toiseen analyyttiseen orjaan, koska sillä oliоsuurempia resursseja eikä siihen ladattu lukupyyntöjä (näin selitimme itsellemme replikointiviiveen puutteen).
Kun selvitimme pääorjan ”leviämisen” syyt, analyyttinen oli jo epäonnistunut samasta syystä. Huolimatta kahden lisäpalvelimen olemassaolosta, joille suunnittelimme siirtävän kuorman master-vian sattuessa, valitettavan virheen vuoksi kävi ilmi, että niitä ei ollut kriittisellä hetkellä käytettävissä.
Mutta koska emme vain tyhjentäneet tietokantaa (restorative kesti tuolloin noin 5 tuntia), vaan myös tilannekuvan pääpalvelimesta, onnistuimme käynnistämään replikan 2 tunnin sisällä. Totta, tämän jälkeen kohtasimme replikointilokin pyörimisen pitkään (koska prosessi toimii yksisäikeisessä tilassa, mutta se on täysin eri tarina).
Johtopäätös: Tällaisen tapauksen jälkeen kävi selväksi, että oli välttämätöntä luopua käytännöstä rajoittaa käyttäjien kirjoittamista ja ilmoittaa koko palvelin vain luku -tilassa. Tämän lähestymistavan avulla ei ole epäilystäkään siitä, että jäljennökset ovat saatavilla kriittisinä aikoina.
Jopa yhden raskaan kyselyn optimointi voi herättää tietokannan eloon
Vaikka päivitämme jatkuvasti sivuston luetteloa, orjapalvelimille lähettämämme pyynnöt sallivat pienen viiveen isännästä. Aika, jonka aikana havaitsimme ja poistimme orjien "äkillisesti poistuvan etäisyyden" ongelman, oli enemmän kuin "psykologinen este" (sinä aikana hinnat olisi voitu päivittää ja asiakkaat olisivat nähneet vanhentuneita tietoja), ja meidän oli pakko siirrä kaikki pyynnöt päätietokantapalvelimeen. Tämän seurauksena sivusto oli hidas... mutta ainakin se toimi. Ja kun Slave toipui, meillä ei ollut muuta vaihtoehtoa kuin optimointi.
Slave-palvelimien toipuessa minuutit kuluivat hitaasti, Master pysyi ylikuormitettuna, ja panostimme kaikki voimamme optimoidaksemme aktiiviset tehtävät "Pareto-säännön" mukaisesti: valitsimme TOP-pyynnöt, jotka tuottavat suurimman osan kuormituksesta ja aloitimme virityksen. . Tämä tehtiin heti lennossa.
Mielenkiintoinen vaikutus oli, että kapasiteettiin ladattu MySQL vastasi pieneenkin prosessien parantumiseen. Parin kyselyn optimointi, jotka tuottivat vain 5 % kokonaiskuormituksesta, on jo osoittanut huomattavan suorittimen kuormituksen. Tämän seurauksena pystyimme tarjoamaan riittävän määrän resursseja, jotta päällikkö voi työskennellä tietokannan kanssa ja hankkia tarvittavan ajan replikoiden palauttamiseen.
Johtopäätös: Pienelläkin optimoinnilla voit "selviytyä" ylikuormituksesta useita tunteja. Tämä riitti meille juuri palvelimen palauttamiseen replikoilla. Muuten, keskustelemme kyselyn optimoinnin teknisestä puolesta yhdessä seuraavista viesteistä. Joten tilaa blogimme, jos pidät siitä hyödyllistä.
Järjestä kumppanipalveluiden toimivuuden seuranta
Käsittelemme asiakkaiden tilauksia, ja siksi palvelumme ovat jatkuvasti vuorovaikutuksessa kolmansien osapuolien sovellusliittymien kanssa - nämä ovat yhdyskäytäviä tekstiviestien lähettämiseen, maksualustoja, reititysjärjestelmiä, geokooderia, liittovaltion veropalvelua ja monia muita järjestelmiä. Ja kun kuormitus alkoi kasvaa nopeasti, aloimme törmätä kumppanipalveluidemme API-rajoituksiin, joita emme olleet aiemmin edes ajatelleet.
Kumppanipalveluiden kiintiöiden yllättävä ylittäminen voi johtaa omaan seisokkiin. Monet sovellusliittymät estävät asiakkaita, jotka ylittävät rajat, ja joissakin tapauksissa liian monet pyynnöt voivat ylikuormittaa kumppanin tuotantoa.
Esimerkiksi toimitusten määrän kasvaessa oheispalvelut eivät pystyneet selviytymään niiden jakelusta ja reittien määrittämisestä. Tuloksena kävi ilmi, että tilauksia tehtiin, mutta reitin luonut palvelu ei toiminut. On sanottava, että logistiikkamme teki näissä olosuhteissa lähes mahdotonta ja tiimin selkeä vuorovaikutus auttoi kompensoimaan tilapäisiä palveluhäiriöitä. Mutta on epärealistista käsitellä tällaista määrää tilauksia manuaalisesti koko ajan, ja jonkin ajan kuluttua kohtaamme kestämättömän aukon tilausten ja niiden toteuttamisen välillä.
Useita organisatorisia toimenpiteitä tehtiin ja tiimin hyvin koordinoitu työ auttoi saamaan aikaa samalla kun sovimme uusista ehdoista ja odotimme palvelujen modernisointia joiltakin yhteistyökumppaneilta. On muitakin sovellusliittymiä, joilla on suuri kestävyys ja järjettömät hinnat suuren liikenteen tapauksessa. Esimerkiksi aluksi käytimme yhtä tunnettua kartoitussovellusliittymää toimituspisteen osoitteen määrittämiseen. Mutta kuun lopussa saimme siistin laskun lähes 2 miljoonalla ruplalla. Sen jälkeen he päättivät vaihtaa sen nopeasti. En ryhdy mainontaan, mutta sanon, että kulumme ovat laskeneet merkittävästi.
Johtopäätös: Kaikkien kumppanipalveluiden toimintaolosuhteita on ehdottomasti seurattava ja pidettävä mielessä. Vaikka tänään näyttää siltä, että heillä on "suuri marginaali" sinulle, tämä ei tarkoita, että huomenna niistä ei tulisi estettä kasvulle. Ja tietysti on parempi sopia palvelun lisääntyneiden pyyntöjen taloudellisista ehdoista etukäteen.
Joskus käy ilmi, että""(c) ei auta
Olemme tottuneet "gagiin" päätietokannassa tai sovelluspalvelimilla, mutta skaalattaessa vikoja voi ilmaantua sinne, missä niitä ei odotettu.. Sivuston kokotekstihakuun käytämme Apache Solr -moottoria. Kuorman kasvaessa havaitsimme vasteajan lyhenevän ja palvelinprosessorin kuormitus saavutti jo 100%. Mikä voisi olla yksinkertaisempaa - annetaan Solrin säiliölle enemmän resursseja.
Odotetun suorituskyvyn kasvun sijaan palvelin yksinkertaisesti "kuoli". Se latautui heti 100 % ja vastasi vielä hitaammin. Aluksi meillä oli 2 ydintä ja 2 Gt RAM-muistia. Päätimme tehdä sen, mikä yleensä auttaa - annoimme palvelimelle 8 ydintä ja 32 Gt. Kaikki paheni paljon (kerromme sinulle tarkalleen kuinka ja miksi erillisessä viestissä).
Muutaman päivän aikana selvitimme tämän ongelman monimutkaisuudet ja saavutimme optimaalisen suorituskyvyn 8 ytimen ja 32 Gt:n avulla. Tällä kokoonpanolla voimme jatkaa kuormituksen lisäämistä tänään, mikä on erittäin tärkeää, koska kasvu ei ole vain asiakkaissa, vaan myös yhdistettyjen myymälöiden määrässä - 2 kuukaudessa niiden määrä on kaksinkertaistunut.
Johtopäätös: Vakiomenetelmät, kuten "lisää enemmän rautaa", eivät aina toimi. Joten kun skaalaat mitä tahansa palvelua, sinulla on oltava hyvä käsitys siitä, miten se käyttää resursseja, ja testattava sen toimintaa uusissa olosuhteissa etukäteen.
Valtioton on avain helppoon vaakasuoraan skaalaukseen
Yleisesti ottaen tiimimme noudattaa hyvin tunnettua lähestymistapaa: palveluilla ei saa olla sisäistä tilaa (valtiottomia) ja niiden tulee olla riippumattomia suoritusympäristöstä. Tämän ansiosta pystyimme selviytymään kuormituksen kasvusta yksinkertaisesti vaakasuoralla skaalauksella. Mutta meillä oli yksi poikkeuspalvelu - käsittelijä pitkiin taustatehtäviin. Hän osallistui sähköpostin ja tekstiviestien lähettämiseen, tapahtumien käsittelyyn, syötteiden luomiseen, hintojen ja varastojen maahantuontiin sekä kuvien käsittelyyn. Sattui niin, että se riippui paikallisesta tiedostovarastosta ja oli yhdessä kopiossa.
Kun suorittimen jonossa olevien tehtävien määrä kasvoi (ja tämä luonnollisesti tapahtui tilausten määrän lisääntyessä), sen isäntäkoneen suorituskyky, jolla prosessori ja tiedostotallennus sijaitsi, tuli rajoittavaksi tekijäksi. Tämän seurauksena valikoiman ja hintojen päivittäminen, ilmoitusten lähettäminen käyttäjille ja monet muut jonoon juuttuneet tärkeät toiminnot pysähtyivät. Ops-tiimi siirsi nopeasti tiedostotallennustilan S3:n kaltaiseen verkkotallennustilaan, ja tämän ansiosta pystyimme nostamaan useita tehokkaita koneita skaalaamaan taustatehtäväprosessorin.
Johtopäätös: Valtiottomuuden sääntöä on noudatettava kaikissa komponenteissa poikkeuksetta, vaikka näyttäisi siltä, että "emme varmasti pysty vastustamaan täällä". On parempi viettää vähän aikaa kaikkien järjestelmien toiminnan asianmukaiseen organisointiin kuin kirjoittaa koodia hätäisesti uudelleen ja korjata ylikuormitettu palvelu.
7 intensiivisen kasvun periaatetta
Lisäkapasiteetin saatavuudesta huolimatta olemme astuneet useisiin virheisiin kasvuprosessissa. Tänä aikana tilausten määrä kasvoi yli 4-kertaiseksi. Nyt toimitamme jo yli 17 000 tilausta päivässä 62 kaupunkiin ja aiomme laajentaa maantieteellistä aluetta entisestään - vuoden 2020 ensimmäisellä puoliskolla palvelun odotetaan käynnistyvän koko Venäjällä. Selviytyäksemme kasvavasta työmäärästä olemme jo valmiiksi täynnä olevat kartiomme huomioon ottaen kehittäneet 7 perusperiaatetta jatkuvan kasvun olosuhteissa työskentelemiseen:
- Tapahtuman hallinta. Loimme Jiraan taulun, jossa jokainen tapaus näkyy lipun muodossa. Tämä auttaa itse asiassa priorisoimaan ja suorittamaan tapahtumiin liittyviä tehtäviä. Loppujen lopuksi virheiden tekeminen ei ole pelottavaa, mutta on pelottavaa tehdä virheitä kahdesti samaan aikaan. Niille tapauksille, joissa tapahtumat toistuvat ennen kuin syy on korjattavissa, toimintaohjeet tulee olla valmiina, koska raskaan kuormituksen aikana on tärkeää reagoida salamannopeasti.
- seuranta vaaditaan poikkeuksetta kaikille infrastruktuurin osille. Hänen ansiosta pystyimme ennustamaan kuorman kasvun ja valitsemaan oikein "pullonkaulat" eliminoinnin priorisoinnille. Todennäköisesti suurella kuormituksella kaikki, mitä et koskaan ajatellut, rikkoutuu tai alkaa hidastua. Siksi on parasta luoda uudet hälytykset heti ensimmäisten tapahtumien jälkeen, jotta niitä voidaan seurata ja ennakoida.
- Oikeat hälytykset yksinkertaisesti tarpeen, kun kuormitus kasvaa jyrkästi. Ensin heidän on raportoitava, mikä tarkalleen on rikki. Toiseksi hälytyksiä ei pitäisi olla paljon, koska ei-kriittisten hälytysten runsaus johtaa siihen, että kaikki hälytykset jätetään huomiotta.
- Hakemusten on oltava valtiottomia. Olemme vakuuttuneita siitä, että tästä säännöstä ei pitäisi tehdä poikkeuksia. Tarvitsemme täydellisen riippumattomuuden ajonaikaisesta ympäristöstä. Tätä varten voit tallentaa jaetut tiedot tietokantaan tai esimerkiksi suoraan S3:een. Vielä parempi, noudata sääntöjä.. Ajan jyrkän pidentymisen aikana koodia ei yksinkertaisesti ole mahdollista optimoida, ja joudut selviytymään kuormituksesta lisäämällä suoraan laskentaresursseja ja vaakasuuntaista skaalausta.
- Kiintiöt ja ulkopuolisten palvelujen suoritus. Nopean kasvun myötä ongelma voi syntyä paitsi infrastruktuurissasi, myös ulkoisessa palvelussa. Ärsyttävintä on, kun tämä ei tapahdu epäonnistumisen vuoksi, vaan kiintiöiden tai rajojen saavuttamisen vuoksi. Ulkoisten palvelujen pitäisi siis skaalata yhtä hyvin kuin sinäkin.
- Erilliset prosessit ja jonot. Tämä auttaa paljon, kun jossakin yhdyskäytävässä on tukos. Emme olisi havainneet tiedonsiirrossa viiveitä, elleivät täydet tekstiviestien lähetysjonot olisi häirinneet tietojärjestelmien välistä ilmoitusten vaihtoa. Ja työntekijöiden määrää olisi helpompi lisätä, jos he työskentelevät erikseen.
- Taloudelliset realiteetit. Kun tietovirrat kasvavat räjähdysmäisesti, ei ole aikaa ajatella tariffeja ja liittymiä. Mutta sinun on muistettava ne, varsinkin jos olet pieni yritys. Minkä tahansa API:n omistaja sekä isännöintipalveluntarjoajasi voivat aiheuttaa suuren laskun. Joten sinun on luettava sopimukset huolellisesti.
Johtopäätös
Ei ilman tappioita, mutta selvisimme tästä vaiheesta, ja tänään yritämme noudattaa kaikkia löydettyjä periaatteita, ja jokaisella koneella on kyky helposti lisätä x4-suorituskykyä selviytyäkseen odottamattomista tapahtumista.
Seuraavissa viesteissä jaamme kokemuksemme Apache Solrin suorituskyvyn heikkenemisen tutkimisesta ja puhumme myös kyselyn optimoinnista ja siitä, kuinka vuorovaikutus Federal Tax Servicen kanssa auttaa yritystä säästämään rahaa. Tilaa blogimme, jotta et jää paitsi mistään, ja kerro meille kommenteissa, jos sinulla oli vastaavia ongelmia liikenteen kasvun aikana.
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Oletko koskaan kokenut palvelun hidastumista/laskua jyrkän kuormituksen lisääntymisen vuoksi:
-
55,6%Kyvyttömyys lisätä nopeasti laskentaresursseja10
-
16,7%Hosting-palveluntarjoajan infrastruktuurin rajoitukset3
-
33,3%Kolmannen osapuolen sovellusliittymien rajoitukset6
-
27,8%Niiden hakemusten kansalaisuudettomien periaatteiden loukkaukset5
-
88,9%Omien palveluiden ei-optimaalinen koodi16
18 käyttäjää äänesti. 6 käyttäjää pidättyi äänestämästä.
Lähde: will.com