🥇Hvernig við lifðum af mikla aukningu á vinnuálagi x10 meðan við unnum fjarvinnu og hvaða ályktanir við drógum

Halló, Habr! Við höfum búið við mjög áhugaverðar aðstæður síðustu tvo mánuði og mig langar að deila sögu okkar um stærðarstærð innviða. Á þessum tíma hefur SberMarket vaxið í pöntunum 4 sinnum og hleypt af stokkunum þjónustunni í 17 nýjum borgum. Mikill vöxtur í eftirspurn eftir afhendingu matvöru krafðist þess að við stækkum innviði okkar. Lestu um áhugaverðustu og gagnlegustu niðurstöðurnar undir skurðinum.

Ég heiti Dima Bobylev, ég er tæknistjóri SberMarket. Þar sem þetta er fyrsta færslan á blogginu okkar ætla ég að segja nokkur orð um sjálfan mig og fyrirtækið. Síðasta haust tók ég þátt í keppni fyrir unga Runet leiðtoga. Fyrir keppnina I skrifaði smásögu um hvernig við hjá SberMarket sjáum innri menningu og nálgun á þjónustuþróun. Og þó að mér hafi ekki tekist að vinna keppnina, mótaði ég mér grunnreglurnar fyrir þróun upplýsingatæknivistkerfisins.

Þegar stjórnað er teymi er mikilvægt að skilja og finna jafnvægi á milli þess sem fyrirtækið þarfnast og þarfa hvers þróunaraðila fyrir sig. Nú er SberMarket að vaxa 13 sinnum á milli ára, og þetta hefur áhrif á vöruna, sem krefst þess að hún eykur stöðugt magn og þróunarhraða. Þrátt fyrir þetta úthlutum við forriturum nægum tíma fyrir bráðabirgðagreiningu og gæðakóðun. Mynduð nálgun hjálpar ekki aðeins við að búa til virka vöru heldur einnig við frekari mælikvarða og þróun hennar. Vegna þessa vaxtar hefur SberMarket nú þegar orðið leiðandi meðal dreifingarþjónustu matvöru: við afhendum um 18 þúsund pantanir á dag á hverjum degi, þó þær hafi verið um 3500 í byrjun febrúar.

Dag einn bað viðskiptavinur SberMarket sendiboða um að afhenda sér matvörur snertilaust - beint út á svalir

En við skulum snúa okkur að einstökum atriðum. Undanfarna mánuði höfum við verið virkir að stækka innviði fyrirtækisins okkar. Þessi þörf skýrðist af ytri og innri þáttum. Samhliða stækkun viðskiptavinahópsins fjölgaði tengdum verslunum úr 90 í byrjun árs í meira en 200 um miðjan maí. Við vorum að sjálfsögðu undirbúin, tókum frá okkur helstu innviði, auk þess sem við reiknuðum með möguleikanum á lóðréttri og láréttri mælingu á öllum sýndarvélum sem hýst eru í Yandex skýinu. Hins vegar hefur æfingin sýnt: „Allt sem getur farið úrskeiðis mun fara úrskeiðis.“ Og í dag vil ég deila áhugaverðustu aðstæðum sem hafa gerst á þessum vikum. Ég vona að reynsla okkar muni nýtast þér.

Þræll er í fullum bardagaviðbúnaði

Jafnvel áður en heimsfaraldurinn hófst stóðum við frammi fyrir aukningu á fjölda beiðna til bakendaþjóna okkar. Þróunin að panta matvörur til heimsendingar fór að öðlast skriðþunga og með tilkomu fyrstu sjálfseinangrunaraðgerða vegna COVID-19 jókst vinnuálagið verulega yfir daginn. Það var þörf á að afferma aðalþjóna aðalgagnagrunnsins fljótt og flytja hluta af lestrarbeiðnunum yfir á eftirmyndaþjóna (þræl).

Við undirbjuggum þetta skref fyrirfram og 2 þrælaþjónar voru þegar ræstir fyrir slíka aðgerð. Þeir voru aðallega notaðir til að búa til upplýsingastrauma til að skiptast á gögnum við samstarfsaðila. Þessi ferli sköpuðu aukaálag og voru réttilega tekin út úr jöfnunni nokkrum mánuðum áður.

Þar sem afritun átti sér stað á þrælnum, héldum við okkur við þá hugmynd að forrit gætu aðeins unnið með þau í skrifvarandi ham. Hamfarabataáætlunin gerði ráð fyrir að ef hamfarir yrðu, gætum við einfaldlega sett þrælinn í stað meistarans og skipt öllum skrif- og lesbeiðnum yfir á þrælinn. Hins vegar vildum við líka nota eftirlíkingar fyrir þarfir greiningardeildarinnar, þannig að þjónarnir voru ekki alveg skipt yfir í skrifvarinn stöðu heldur var hver gestgjafi með sitt eigið notendasett og sumir höfðu skrifrétt til að vista milliútreikningsniðurstöður.

Upp að ákveðnu álagsstigi höfðum við nægan meistara til bæði að skrifa og lesa þegar unnið var úr http beiðnum. Um miðjan mars, rétt þegar Sbermarket ákvað að skipta algjörlega yfir í fjarvinnu, byrjaði RPS okkar að vaxa veldishraða. Sífellt fleiri viðskiptavinir okkar fóru í einangrun eða unnu heima, sem hafði áhrif á vinnuálagsvísana okkar.

Frammistaða „meistarans“ var ekki lengur nægjanleg, svo við byrjuðum að flytja nokkrar af þyngstu lestrarbeiðnunum yfir á eftirmyndina. Til að beina skrifbeiðnum á gagnsæjan hátt til húsbóndans og lesa beiðnir til þrælsins, notuðum við rúbínsteininn "Octopus" Við bjuggum til sérstakan notanda með _readonly postfix án skrifaréttar. En vegna villu í uppsetningu eins vélarinnar fóru sumar skrifbeiðnirnar til þrælaþjónsins fyrir hönd notanda sem hafði viðeigandi réttindi.

Vandamálið kom ekki strax, því... aukið álag jók töf þrælanna. Ósamræmi gagnanna kom í ljós að morgni þegar þrælarnir „náðu“ húsbóndann eftir innflutning á nóttunni. Við rekjum þetta til mikils álags á þjónustuna sjálfa og innflutnings í tengslum við opnun nýrra verslana. En það var óásættanlegt að senda gögn með margra klukkustunda töf og við skiptum yfir í annan greiningarþrælinn vegna þess að hann hafðiоstærri auðlindir og var ekki hlaðið af lestrarbeiðnum (sem er hvernig við útskýrðum fyrir okkur skortinn á afritunartöf).

Þegar við komumst að ástæðunum fyrir „dreifingu“ aðalþrælsins hafði greiningardeildin þegar mistekist af sömu ástæðu. Þrátt fyrir að tveir netþjónar til viðbótar væru til staðar sem við ætluðum að flytja álagið á ef aðalbilun yrði, kom í ljós vegna óheppilegrar villu að engir voru tiltækir á mikilvægu augnablikinu.

En þar sem við dumpuðum ekki aðeins gagnagrunninum (endurnýjunin á þeim tíma tók um 5 klukkustundir), heldur einnig skyndimynd af aðalþjóninum, tókst okkur að ræsa eftirmyndina innan 2 klukkustunda. Að vísu stóðum við frammi fyrir því að afritunarskráin fór yfir í langan tíma (vegna þess að ferlið keyrir í stakþráða ham, en það er allt önnur saga).

Ályktun: Eftir slíkt atvik varð ljóst að nauðsynlegt var að hætta við að takmarka skrif fyrir notendur og lýsa yfir allan netþjóninn sem skrifvarinn. Með þessari nálgun er enginn vafi á því að eftirlíkingar verða tiltækar á mikilvægum tímum.

Með því að fínstilla jafnvel eina þunga fyrirspurn getur gagnagrunnurinn lífgað við aftur

Þó að við uppfærum vörulistann stöðugt á síðunni, leyfðu beiðnirnar sem við sendum til þrælaþjónanna smá töf frá meistaranum. Tíminn sem við uppgötvuðum og útrýmdum vandamálinu með því að þrælar „hverfa skyndilega yfirgefa fjarlægðina“ var meira en „sálfræðilega hindrunin“ (á þessum tíma hefði verið hægt að uppfæra verð og viðskiptavinir hefðu séð úrelt gögn), og við neyddumst til að skiptu öllum beiðnum yfir á aðalgagnagrunnsþjóninn. Fyrir vikið var síða hæg... en hún virkaði allavega. Og á meðan Slave var að ná sér, áttum við ekkert val en hagræðingu.

Á meðan þrælaþjónarnir voru að jafna sig liðu mínúturnar hægt og rólega, meistarinn var ofhlaðinn og við lögðum alla okkar krafta í að fínstilla virk verkefni í samræmi við „Pareto regluna“: við völdum TOP beiðnirnar sem mynda meirihluta álagsins og byrjuðum að stilla . Þetta var gert á flugi.

Áhugaverð áhrif voru þau að MySQL, hlaðið að getu, brást jafnvel við smávægilegum framförum í ferlum. Hagræðing á nokkrum fyrirspurnum sem framleiddu aðeins 5% af heildarálagi hefur þegar sýnt áberandi CPU álag. Fyrir vikið gátum við útvegað viðunandi framboð af auðlindum fyrir meistarann til að vinna með gagnagrunninn og fá nauðsynlegan tíma til að endurheimta eftirmyndir.

Ályktun: Jafnvel lítil hagræðing gerir þér kleift að „lifa af“ undir ofhleðslu í nokkrar klukkustundir. Þetta var bara nóg fyrir okkur til að endurheimta netþjónana með eftirmyndum. Við the vegur, við munum ræða tæknilega hlið fyrirspurna fínstillingu í einni af eftirfarandi færslum. Svo vinsamlegast gerist áskrifandi að blogginu okkar ef þér finnst það gagnlegt.

Skipuleggja eftirlit með frammistöðu þjónustu samstarfsaðila

Við vinnum pantanir frá viðskiptavinum og þar af leiðandi hefur þjónusta okkar stöðug samskipti við API frá þriðja aðila - þetta eru gáttir til að senda SMS, greiðslukerfi, leiðarkerfi, landkóða, alríkisskattaþjónustu og mörg önnur kerfi. Og þegar álagið fór að vaxa hratt fórum við að lenda í API takmörkunum á þjónustu samstarfsaðila okkar, sem við höfðum ekki einu sinni hugsað um áður.

Að fara óvænt yfir kvóta þjónustu samstarfsaðila getur leitt til niður í miðbæ. Mörg API hindra viðskiptavini sem fara yfir mörk, og í sumum tilfellum geta of margar beiðnir ofhleðsla framleiðslu samstarfsaðila.

Sem dæmi má nefna að þegar sendingum fjölgaði réðu meðfylgjandi þjónustur ekki við verkefni við að dreifa þeim og ákveða leiðir. Í kjölfarið kom í ljós að pantanir voru gerðar en þjónustan sem bjó til leiðina virkaði ekki. Það verður að segjast eins og er að flutningsmenn okkar gerðu hið nánast ómögulega við þessar aðstæður og skýr samskipti teymisins hjálpuðu til við að bæta upp tímabundin þjónustubrest. En það er óraunhæft að afgreiða slíkt magn pantana handvirkt allan tímann og eftir nokkurn tíma myndum við standa frammi fyrir óviðunandi bili milli pantana og framkvæmd þeirra.

Nokkrar skipulagsráðstafanir voru gerðar og vel samræmd vinna liðsins hjálpaði til við að vinna tíma á meðan við sömdum um ný skilyrði og biðum eftir nútímavæðingu þjónustu frá nokkrum samstarfsaðilum. Það eru önnur API sem státa af miklu þreki og svívirðilegum hlutföllum ef um er að ræða mikla umferð. Til dæmis notuðum við í upphafi eitt vel þekkt kortlagningar-API til að ákvarða heimilisfang afhendingarstaðarins. En í lok mánaðarins fengum við snyrtilegan reikning upp á tæpar 2 milljónir rúblur. Eftir það ákváðu þeir að skipta um það fljótt. Ég mun ekki taka þátt í auglýsingum, en ég mun segja að útgjöld okkar hafa lækkað verulega.

Ályktun: Nauðsynlegt er að fylgjast með rekstrarskilyrðum allrar þjónustu samstarfsaðila og hafa þær í huga. Jafnvel þótt í dag virðist sem þeir séu „með mikilli framlegð“ fyrir þig, þá þýðir það ekki að á morgun verði þau ekki hindrun fyrir vexti. Og auðvitað er betra að semja um fjárhagsleg skilmála aukinna beiðna um þjónustuna fyrirfram.

Stundum kemur í ljós að "Vantar meira gull„(c) hjálpar ekki

Við erum vön því að „gags“ í aðalgagnagrunninum eða á forritaþjónum, en við skala geta komið upp vandræði þar sem ekki var búist við. Til að leita í fullri texta á síðunni notum við Apache Solr vélina. Eftir því sem álagið jókst tókum við eftir lækkun á viðbragðstíma og álag á örgjörva miðlara náði þegar 100%. Hvað gæti verið einfaldara - gefum gámnum með Solr meira fjármagn.

Í stað væntanlegrar frammistöðuaukningar „dó þjónninn einfaldlega“. Það hleðst strax á 100% og svaraði enn hægar. Upphaflega vorum við með 2 kjarna og 2 GB af vinnsluminni. Við ákváðum að gera það sem venjulega hjálpar - við gáfum þjóninum 8 kjarna og 32 GB. Allt varð miklu verra (við munum segja þér nákvæmlega hvernig og hvers vegna í sérstakri færslu).

Á nokkrum dögum komumst við að flóknum þessu máli og náðum bestu frammistöðu með 8 kjarna og 32 GB. Þessi uppsetning gerir okkur kleift að halda áfram að auka álagið í dag, sem er mjög mikilvægt, vegna þess að vöxturinn er ekki aðeins hjá viðskiptavinum, heldur einnig í fjölda tengdra verslana - á 2 mánuðum hefur fjöldi þeirra tvöfaldast.

Ályktun: Staðlaðar aðferðir eins og „bæta við meira járni“ virka ekki alltaf. Svo þegar þú skalar hvaða þjónustu sem er þarftu að hafa góðan skilning á því hvernig hún notar auðlindir og prófa virkni hennar við nýjar aðstæður fyrirfram.

Stateless er lykillinn að auðveldri láréttri mælingu

Almennt séð fylgir teymi okkar vel þekktri nálgun: þjónusta ætti ekki að hafa innra ástand (ríkislaust) og ætti að vera óháð framkvæmdaumhverfinu. Þetta gerði okkur kleift að takast á við álagsvöxt með einfaldlega láréttri mælingu. En við vorum með eina undantekningarþjónustu - umsjónarmann fyrir langvarandi bakgrunnsverkefni. Hann tók þátt í að senda tölvupóst og sms, vinna viðburði, búa til strauma, flytja inn verð og birgðir og vinna myndir. Það gerðist svo að það var háð staðbundinni skráageymslu og var í einu eintaki.

Þegar verkefnum í örgjörva biðröðinni fjölgaði (og það gerðist náttúrulega með fjölgun pantana) varð afköst hýsilsins sem örgjörvinn og skráageymslan var á takmarkandi þáttur. Þess vegna stöðvaðist uppfærsla á úrvali og verðum, sendingu tilkynninga til notenda og margar aðrar mikilvægar aðgerðir sem voru fastar í biðröðinni. Ops teymið flutti fljótt skráargeymslu yfir í S3-lík netgeymslu og þetta gerði okkur kleift að hækka nokkrar öflugar vélar til að stækka bakgrunnsverkgjörvann.

Ályktun: Fylgja verður ríkisfangslausu reglunni fyrir alla íhluti án undantekninga, jafnvel þótt svo virðist sem „við munum örugglega ekki geta staðist hér. Það er betra að eyða smá tíma í að skipuleggja rekstur allra kerfa á réttan hátt en að endurskrifa kóðann í flýti og laga ofhlaðna þjónustu.

7 meginreglur fyrir mikinn vöxt

Þrátt fyrir tiltæka viðbótargetu höfum við stigið á nokkur mistök í vaxtarferlinu. Á þessum tíma fjölgaði pöntunum meira en 4 sinnum. Nú þegar afhendum við meira en 17 pantanir á dag í 000 borgum og ætlum að stækka landafræðina enn frekar - á fyrri hluta ársins 62 er gert ráð fyrir að þjónustan verði opnuð um allt Rússland. Til að takast á við vaxandi vinnuálag, að teknu tilliti til þegar fullar keilur okkar, höfum við þróað 2020 grundvallarreglur til að vinna við stöðugan vöxt:

Atvikastjórnun. Við bjuggum til töflu í Jira, þar sem hvert atvik endurspeglast í formi miða. Þetta mun hjálpa til við að forgangsraða og framkvæma atvikstengd verkefni. Þegar öllu er á botninn hvolft er það í rauninni ekki skelfilegt að gera mistök, en það er skelfilegt að gera mistök tvisvar við sama tækifæri. Í þeim tilfellum þar sem atvik endurtaka sig áður en hægt er að leiðrétta orsökina ættu leiðbeiningar um aðgerðir að vera tilbúnar, því á tímum mikils álags er mikilvægt að bregðast við með leifturhraða.
Eftirlit krafist fyrir alla innviðaþætti án undantekninga. Það var honum að þakka að við gátum spáð fyrir um vöxt álagsins og valið „flöskuhálsana“ rétt til að forgangsraða brotthvarfi. Líklegast, undir miklu álagi, mun allt sem þú hefur aldrei hugsað um brotna eða byrja að hægja á sér. Þess vegna er best að búa til nýjar viðvaranir strax eftir að fyrstu atvikin eiga sér stað til að fylgjast með og sjá fyrir þau.
Réttar viðvaranir einfaldlega nauðsynlegt þegar álagið eykst mikið. Fyrst verða þeir að tilkynna hvað nákvæmlega er bilað. Í öðru lagi ættu viðvaranir ekki að vera margar, vegna þess að gnægð af viðvörunum sem ekki eru mikilvægar leiðir til þess að hunsa allar viðvaranir með öllu.
Umsóknir skulu vera ríkisfangslausar. Við erum sannfærð um að engar undantekningar ættu að vera frá þessari reglu. Við þurfum algjört sjálfstæði frá keyrsluumhverfinu. Til þess er hægt að geyma sameiginleg gögn í gagnagrunni eða til dæmis beint í S3. Enn betra, fylgdu reglunum. https://12factor.net. Með mikilli aukningu í tíma er einfaldlega engin leið til að fínstilla kóðann og þú verður að takast á við álagið með því að auka beint tölvuauðlindir og lárétta mælikvarða.
Kvótar og afkoma ytri þjónustu. Með örum vexti getur vandamál komið upp ekki aðeins í innviðum þínum heldur einnig í ytri þjónustu. Það sem er mest pirrandi er þegar þetta gerist ekki vegna bilunar heldur vegna þess að kvóta eða takmörkum er náð. Þannig að ytri þjónusta ætti að stækka eins vel og þú.
Aðskilið ferli og biðraðir. Þetta hjálpar mikið þegar það er stífla við eina af gáttunum. Við hefðum ekki orðið fyrir töfum á gagnaflutningi ef fullar SMS-sendingarraðir hefðu ekki truflað tilkynningaskipti milli upplýsingakerfa. Og það væri auðveldara að fjölga starfsmönnum ef þeir ynnu sitt í hvoru lagi.
Fjárhagslegur veruleiki. Þegar mikill vöxtur er í gagnaflæði gefst enginn tími til að hugsa um gjaldskrár og áskriftir. En þú þarft að muna eftir þeim, sérstaklega ef þú ert lítið fyrirtæki. Eigandi hvaða API sem er, sem og hýsingaraðili þinn, getur orðið fyrir stórum reikningi. Svo þú þarft að lesa samninga vandlega.

Ályktun

Ekki án taps, en við lifðum þetta stig af, og í dag reynum við að fylgja öllum meginreglunum sem fundust, og hver vél hefur getu til að auka auðveldlega x4 afköst til að takast á við óvænta atburði.

Í eftirfarandi færslum munum við deila reynslu okkar af því að rannsaka frammistöðurýrnun í Apache Solr, og einnig tala um hagræðingu fyrirspurna og hvernig samskipti við alríkisskattaþjónustuna hjálpa fyrirtækinu að spara peninga. Gerast áskrifandi að blogginu okkar svo þú missir ekki af neinu og segðu okkur í athugasemdunum hvort þú hafir átt í svipuðum vandræðum meðan á umferð stendur.