🥇Sut wnaethon ni oroesi'r cynnydd sydyn yn y llwyth gwaith x10 wrth weithio o bell a pha gasgliadau wnaethon ni eu tynnu

Helô, Habr! Rydym wedi bod yn byw trwy sefyllfa ddiddorol iawn am y misoedd diwethaf, a hoffwn rannu ein stori graddio seilwaith. Yn ystod yr amser hwn, cynyddodd archebion SberMarket bedair gwaith a lansiwyd y gwasanaeth mewn 17 o ddinasoedd newydd. Roedd y twf ffrwydrol yn y galw am ddosbarthu bwyd yn ei gwneud yn ofynnol i ni raddio ein seilwaith. Darllenwch ymlaen i weld y canfyddiadau mwyaf diddorol a defnyddiol.

Fy enw i yw Dima Bobylev, a fi yw Prif Swyddog Technoleg SberMarket. Gan mai dyma'r post cyntaf ar ein blog, dywedaf ychydig eiriau amdanaf fy hun a'r cwmni. Yr hydref diwethaf, cymerais ran yng nghystadleuaeth Arweinwyr Ifanc RuNet. Ar gyfer y gystadleuaeth, ysgrifennodd stori fer Trafodais sut rydym ni yn SberMarket yn gweld ein diwylliant mewnol a'n dull o ddatblygu gwasanaethau. Er na wnes i ennill y gystadleuaeth, fe wnes i ddatblygu egwyddorion allweddol ar gyfer datblygu'r ecosystem TG.

Wrth reoli tîm, mae'n bwysig deall a chydbwyso anghenion y busnes ag anghenion y datblygwr unigol. Ar hyn o bryd mae SberMarket yn tyfu 13 gwaith flwyddyn ar ôl blwyddyn, ac mae hyn yn effeithio ar y cynnyrch, gan olygu bod angen cynnydd cyson yng nghyfaint a chyflymder y datblygiad. Er gwaethaf hyn, rydym yn neilltuo digon o amser i ddatblygwyr ar gyfer dadansoddiad rhagarweiniol ac ysgrifennu cod o ansawdd uchel. Mae'r dull sefydledig hwn yn helpu nid yn unig i greu cynnyrch gweithredol ond hefyd i'w raddio a'i ddatblygu yn y dyfodol. O ganlyniad i'r twf hwn, mae SberMarket eisoes wedi dod yn arweinydd ymhlith gwasanaethau dosbarthu bwyd: rydym yn dosbarthu tua 18 o archebion bob dydd, i fyny o tua 3500 ddechrau mis Chwefror.

Un diwrnod, gofynnodd cwsmer i negesydd SberMarket ddanfon ei nwyddau bwyd yn ddi-gyswllt—yn syth i'w falconi.

Ond gadewch i ni fynd i lawr i fanylion. Dros yr ychydig fisoedd diwethaf, rydym wedi bod yn weithgar yn graddio seilwaith ein cwmni. Cafodd yr angen hwn ei yrru gan ffactorau allanol a mewnol. Ynghyd â'n sylfaen cleientiaid sy'n ehangu, tyfodd nifer y siopau cysylltiedig o 90 ar ddechrau'r flwyddyn i dros 200 erbyn canol mis Mai. Roeddem, wrth gwrs, wedi paratoi, gan wneud copi wrth gefn o'r seilwaith craidd, a dibynnu ar y gallu i raddio i fyny ac i lawr yr holl beiriannau rhithwir a gynhelir yn y cwmwl Yandex. Fodd bynnag, mae profiad wedi dangos y bydd "unrhyw beth a all fynd o'i le, yn mynd o'i le." Heddiw, hoffwn rannu rhai o'r sefyllfaoedd mwyaf diddorol sydd wedi digwydd dros yr ychydig wythnosau diwethaf. Gobeithio y byddwch yn gweld ein profiad yn ddefnyddiol.

Mae'r caethwas mewn parodrwydd llawn i ymladd

Hyd yn oed cyn y pandemig, roeddem yn gweld cynnydd yn nifer y ceisiadau i'n gweinyddion cefndirol. Roedd y duedd o archebu bwyd i'w ddanfon adref yn ennill momentwm, a chyda chyflwyniad y mesurau clo COVID-19 cyntaf, cynyddodd y llwyth yn sylweddol drwy gydol y dydd. Cododd yr angen i leihau'r llwyth ar weinyddion meistr y gronfa ddata sylfaenol yn gyflym a symud rhai ceisiadau darllen i weinyddion replica (caethweision).

Roedden ni wedi bod yn paratoi ar gyfer y cam hwn ymlaen llaw, ac roedd dau weinydd caeth eisoes wedi'u lansio ar gyfer y symudiad hwn. Roedden nhw'n bennaf yn rhedeg tasgau swp yn cynhyrchu porthiant gwybodaeth ar gyfer cyfnewid data gyda phartneriaid. Creodd y prosesau hyn lwyth gwaith diangen ac fe'u rhoddwyd o'r neilltu, yn briodol, ychydig fisoedd ynghynt.

Gan fod dyblygu wedi digwydd ar y Caethwas, fe wnaethom lynu wrth y cysyniad y gallai cymwysiadau weithio gyda nhw mewn modd darllen yn unig. Roedd y Cynllun Adfer ar ôl Trychineb yn tybio, pe bai trychineb, y gallem osod y Caethwas yn lle'r Meistr a newid pob cais darllen ac ysgrifennu i'r Caethwas. Fodd bynnag, roeddem hefyd eisiau defnyddio'r dyblygiadau ar gyfer yr adran ddadansoddeg, felly nid oedd y gweinyddion wedi'u gosod yn llwyr i ddarllen yn unig. Roedd gan bob gwesteiwr ei set ei hun o ddefnyddwyr, rhai â mynediad ysgrifennu i gadw canlyniadau cyfrifiadau canolradd.

Hyd at lefel llwyth benodol, roedd gennym ddigon o adnoddau ar gyfer ysgrifennu a darllen ceisiadau HTTP. Ganol mis Mawrth, wrth i Sbermarket benderfynu mynd yn gwbl o bell, gwelsom gynnydd dramatig yn RPS. Roedd mwy a mwy o'n cleientiaid yn hunanynysu neu'n gweithio o gartref, a effeithiodd ar ein dangosyddion llwyth.

Nid oedd perfformiad y meistr yn ddigonol mwyach, felly dechreuon ni ddadlwytho rhai o'r ceisiadau darllen trymaf i'r replica. Er mwyn llwybro ceisiadau ysgrifennu i'r meistr a cheisiadau darllen i'r caethwas yn dryloyw, fe wnaethon ni ddefnyddio'r gem Ruby "Octopws"Fe wnaethon ni greu defnyddiwr arbennig gyda'r ôl-osodiad _readonly heb ganiatâd ysgrifennu. Fodd bynnag, oherwydd gwall ffurfweddu ar un o'r gwesteiwyr, anfonwyd rhai ceisiadau ysgrifennu at y gweinydd caethweision o dan enw'r defnyddiwr, a oedd â'r caniatâd priodol.

Ni ddaeth y broblem i'r amlwg ar unwaith, gan fod y llwyth cynyddol yn cynyddu'r oedi caethweision. Darganfuwyd yr anghysondeb data yn y bore, pan, ar ôl mewnforion dros nos, methodd y caethweision â "dal i fyny" â'r meistr. Priodolom hyn i'r llwyth uchel ar y gwasanaeth ei hun a'r mewnforio sy'n gysylltiedig â lansio siopau newydd. Fodd bynnag, roedd cyflwyno data gydag oedi o sawl awr yn annerbyniol, felly newidiom brosesau i'r ail gaethwas dadansoddol, gan ei fod wedi...оmwy o adnoddau ac nid oedd wedi'i lwytho â cheisiadau darllen (dyna sut y gwnaethom egluro i ni'n hunain absenoldeb oedi dyblygu).

Erbyn i ni ddarganfod y rhesymau dros "ymlusgo" y prif gaethwas, roedd y gweinydd dadansoddol eisoes wedi methu am yr un rheswm. Er bod gennym ddau weinydd ychwanegol yr oeddem yn bwriadu trosglwyddo'r llwyth iddynt pe bai'r meistr yn methu, golygodd gwall anffodus nad oedd y naill na'r llall ar gael ar yr adeg dyngedfennol.

Ond gan ein bod ni nid yn unig wedi cael gwared ar y gronfa ddata (cymerodd y gwaith adfer tua 5 awr ar y pwynt hwnnw) ond hefyd wedi tynnu ciplun o'r gweinydd meistr, roedden ni'n gallu lansio'r replica o fewn 2 awr. Fodd bynnag, ar ôl hynny, roedden ni'n wynebu croniad log replica hir (oherwydd bod y broses yn un edau, ond mae hynny'n stori hollol wahanol).

Casgliad: Ar ôl y digwyddiad hwn, daeth yn amlwg bod angen i ni roi'r gorau i'r arfer o gyfyngu mynediad ysgrifennu i ddefnyddwyr a datgan bod y gweinydd cyfan yn ddarllen-yn-unig. Mae'r dull hwn yn sicrhau y bydd copïau ar gael ar adegau hollbwysig.

Gall optimeiddio hyd yn oed un ymholiad trwm ddod â chronfa ddata yn ôl yn fyw.

Er ein bod yn diweddaru catalog y wefan yn gyson, roedd yr ymholiadau yr oeddem yn eu hanfon at y gweinyddion caethweision ychydig ar ei hôl hi na'r meistr. Roedd yr amser a gymerodd i ni ganfod a thrwsio'r broblem gyda'r gweinyddion caethweision yn rhoi'r gorau i wasanaeth yn sydyn yn hirach na'r "rhwystr seicolegol" (gallai diweddariadau prisiau fod wedi digwydd yn ystod yr amser hwn, a byddai cleientiaid wedi gweld data hen ffasiwn), ac fe'n gorfodwyd i newid yr holl ymholiadau i'r prif weinydd cronfa ddata. O ganlyniad, roedd y wefan yn rhedeg yn araf... ond o leiaf roedd yn gweithio. A thra bod y gweinydd caethweision yn gwella, nid oedd gennym ddewis ond optimeiddio.

Tra bod y gweinyddion caeth yn adfer, roedd y munudau'n mynd heibio, roedd y gweinydd meistr yn parhau i fod wedi'i orlwytho, ac fe wnaethon ni ganolbwyntio ein holl ymdrechion ar optimeiddio tasgau gweithredol yn ôl Egwyddor Pareto: fe wnaethon ni ddewis yr ymholiadau gorau oedd yn cyfrif am y rhan fwyaf o'r llwyth a dechrau tiwnio. Gwnaed hyn ar unwaith.

Canlyniad diddorol oedd bod enghraifft MySQL wedi'i llwytho'n llawn wedi ymateb i welliannau proses hyd yn oed bach. Dangosodd optimeiddio cwpl o ymholiadau a oedd ond yn cyfrif am 5% o'r cyfanswm llwyth ostyngiad amlwg yn llwyth y CPU. O ganlyniad, roeddem yn gallu sicrhau cronfa adnoddau dderbyniol ar gyfer y gronfa ddata Meistr ac ennill yr amser angenrheidiol i adfer y copïau.

Casgliad: Mae hyd yn oed optimeiddiadau bach yn caniatáu inni oroesi gorlwytho am sawl awr. Roedd hyn yn ddigon i ni adfer ein gweinyddion replica. Gyda llaw, byddwn yn trafod agweddau technegol optimeiddio ymholiadau mewn post yn y dyfodol. Felly tanysgrifiwch i'n blog os ydych chi'n gweld hyn yn ddefnyddiol.

Trefnu monitro perfformiad gwasanaethau partner

Rydym yn prosesu archebion cwsmeriaid, felly mae ein gwasanaethau'n rhyngweithio'n gyson ag APIs trydydd parti—pyrth SMS, llwyfannau talu, systemau llwybro, geocoders, y Gwasanaeth Treth Ffederal, a llawer o systemau eraill. A phan ddechreuodd y llwyth dyfu'n gyflym, dechreuon ni ddod ar draws cyfyngiadau API ein gwasanaethau partner nad oeddem hyd yn oed wedi'u hystyried o'r blaen.

Gall mynd y tu hwnt i gwotâu gwasanaeth partner yn annisgwyl arwain at amser segur i'ch un chi. Mae llawer o APIs yn rhwystro cleientiaid sy'n mynd y tu hwnt i'w terfynau, ac mewn rhai achosion, gall y ceisiadau gormodol orlethu system gynhyrchu'r partner.

Er enghraifft, pan gynyddodd nifer y danfoniadau, ni allai'r gwasanaethau cysylltiedig ymdopi â'r tasgau o'u dosbarthu a phennu llwybrau. O ganlyniad, gosodwyd archebion, ond roedd y gwasanaeth creu llwybrau i lawr. Rhaid dweud bod ein tîm logisteg wedi cyflawni'r bron yn amhosibl o dan yr amodau hyn, a helpodd cyfathrebu clir y tîm i wneud iawn am doriadau gwasanaeth dros dro. Fodd bynnag, mae'n amhosibl prosesu nifer o'r fath o archebion â llaw yn barhaus, ac ar ôl peth amser, byddem wedi wynebu bwlch annerbyniol rhwng archebion a'u cyflawniad.

Gweithredwyd nifer o fesurau sefydliadol, a helpodd gwaith cydlynol y tîm i brynu amser inni wrth i ni drafod telerau newydd ac aros i rai partneriaid uwchraddio eu gwasanaethau. Mae APIs eraill sy'n ymfalchïo mewn gwydnwch rhagorol ac yn cynnig cyfraddau afresymol ar gyfer traffig uchel. Er enghraifft, ar y dechrau, fe wnaethom ddefnyddio API mapio adnabyddus i bennu cyfeiriad y pwynt dosbarthu. Ond erbyn diwedd y mis, cawsom fil sylweddol o bron i 2 filiwn rubles. Ar ôl hynny, fe benderfynon ni ei ddisodli'n gyflym. Ni fyddaf yn hysbysebu, ond byddaf yn dweud bod ein costau wedi gostwng yn sylweddol.

Casgliad: Mae'n hanfodol monitro telerau ac amodau pob gwasanaeth partner a'u cadw mewn cof. Hyd yn oed os ydyn nhw'n ymddangos yn "rhywbeth da" heddiw, nid yw hynny'n golygu na fyddan nhw'n rhwystr i dwf yfory. Ac, wrth gwrs, mae'n well negodi telerau ariannol ar gyfer galw cynyddol am wasanaethau ymlaen llaw.

Weithiau mae'n ymddangos bod "angen mwy o aur"(c) ddim yn helpu

Rydym wedi arfer â thagfeydd yn y brif gronfa ddata neu weinyddion cymwysiadau, ond wrth raddio, gall problemau godi lle rydych chi leiaf yn eu disgwyl. Rydym yn defnyddio'r injan Apache Solr ar gyfer chwilio testun llawn ar ein gwefan. Wrth i'r llwyth gynyddu, gwelsom ostyngiad yn yr amser ymateb, a chyrhaeddodd defnydd CPU y gweinydd 100%. Beth allai fod yn symlach? Rydym yn rhoi mwy o adnoddau i'r cynhwysydd Solr.

Yn lle'r hwb perfformiad disgwyliedig, bu farw'r gweinydd yn syml. Llwythodd ar unwaith ar 100% ac ymatebodd hyd yn oed yn arafach. I ddechrau, roedd gennym ddau graidd a 2 GB o RAM. Penderfynon ni wneud yr hyn sy'n gweithio fel arfer—uwchraddio'r gweinydd i wyth craidd a 32 GB. Aeth pethau'n llawer gwaeth (byddwn yn egluro'n union sut a pham mewn post ar wahân).

O fewn ychydig ddyddiau, fe wnaethon ni ddarganfod cymhlethdodau'r mater hwn a chyflawni perfformiad gorau posibl gydag 8 craidd a 32 GB o gof. Mae'r ffurfweddiad hwn yn caniatáu inni barhau i gynyddu'r llwyth, sy'n hanfodol oherwydd nid yn unig o ran cleientiaid y mae twf ond hefyd yn nifer y siopau cysylltiedig—mae eu nifer wedi dyblu mewn dau fis.

Casgliad: Nid yw dulliau safonol fel "ychwanegu mwy o galedwedd" bob amser yn gweithio. Felly, wrth raddio unrhyw wasanaeth, mae angen i chi ddeall yn drylwyr sut mae'n defnyddio adnoddau a phrofi ei berfformiad o dan amodau newydd ymlaen llaw.

Di-wladwriaeth yw'r allwedd i raddio llorweddol hawdd

Yn gyffredinol, mae ein tîm yn glynu wrth ddull adnabyddus: dylai gwasanaethau fod yn ddi-wladwriaeth ac yn annibynnol ar yr amgylchedd amser rhedeg. Roedd hyn yn caniatáu inni ymdopi â llwyth cynyddol trwy raddio'n llorweddol yn unig. Fodd bynnag, roedd gennym un eithriad: trinwr tasgau cefndir hirhoedlog. Roedd yn trin anfon e-bost ac SMS, prosesu digwyddiadau, cynhyrchu porthiant, mewnforio prisiau a stoc, a phrosesu delweddau. Digwyddodd ei fod yn dibynnu ar storio ffeiliau lleol ac yn un enghraifft.

Pan gynyddodd nifer y tasgau yn y ciw prosesu (a ddigwyddodd yn naturiol gyda'r cynnydd mewn archebion), daeth perfformiad y gwesteiwr a oedd yn cynnal y prosesydd a'r storfa ffeiliau yn gyfyngedig. O ganlyniad, daeth diweddariadau rhestr eiddo a phrisiau, hysbysiadau defnyddwyr, a llawer o swyddogaethau hanfodol eraill i stop oherwydd y gwaith ôl-groniad. Symudodd y tîm gweithrediadau'r storfa ffeiliau yn gyflym i storfa rhwydwaith debyg i S3, gan ganiatáu inni ddefnyddio sawl peiriant pwerus i raddio'r prosesu cefndir.

Casgliad: Rhaid dilyn y rheol Di-wladwriaeth ar gyfer pob cydran heb eithriad, hyd yn oed os yw'n ymddangos nad ydym yn mynd i gyrraedd ein terfyn. Mae'n well treulio ychydig o amser yn cael pob system i weithio'n iawn na rhuthro trwy ailysgrifennu cod a thrwsio gwasanaeth sydd wedi'i orlwytho.

7 Egwyddor ar gyfer Twf Dwys

Er gwaethaf y capasiti ychwanegol sydd ar gael, rydym wedi wynebu sawl her wrth i ni dyfu. Yn ystod y cyfnod hwn, mae nifer yr archebion wedi mwy na phedair gwaith. Ar hyn o bryd rydym yn dosbarthu dros 17,000 o archebion y dydd mewn 62 o ddinasoedd ac yn bwriadu ehangu ein cyrhaeddiad daearyddol ymhellach—rydym yn disgwyl lansio ein gwasanaeth ledled Rwsia yn hanner cyntaf 2020. Er mwyn ymdopi â'r llwyth gwaith cynyddol a'r heriau rydym eisoes wedi'u hwynebu, rydym wedi datblygu saith egwyddor allweddol ar gyfer rheoli ein gweithrediadau yng nghyd-destun twf cyson:

Rheoli digwyddiadauRydym wedi creu bwrdd Jira lle mae pob digwyddiad yn cael ei gofnodi fel tocyn. Bydd hyn yn ein helpu i flaenoriaethu a chwblhau tasgau sy'n gysylltiedig â'r digwyddiad. Wedi'r cyfan, nid yw mewn gwirionedd yn ymwneud â gwneud camgymeriad—mae'n ymwneud â gwneud yr un camgymeriad ddwywaith. Ar gyfer yr achosion hynny lle mae digwyddiadau'n digwydd eto cyn y gellir trwsio'r achos gwreiddiol, mae angen i ni gael camau ymarferol ar waith, oherwydd yn ystod cyfnodau o lwyth gwaith uchel, mae'n hanfodol ymateb yn gyflym.
Monitro Mae hyn yn ofynnol ar gyfer pob elfen seilwaith heb eithriad. Diolch yn union i hyn y llwyddom i ragweld twf llwyth a nodi tagfeydd yn gywir i flaenoriaethu datrysiadau. Mae'n debyg, o dan lwyth uchel, y bydd popeth na feddyliais amdano erioed yn torri neu'n arafu. Felly, mae'n well creu rhybuddion newydd yn syth ar ôl i'r digwyddiadau cyntaf ddigwydd, i'w monitro a'u rhagweld.
Rhybuddion cywir Maen nhw'n hanfodol yn ystod cynnydd sydyn yn y llwyth. Yn gyntaf, dylen nhw nodi'n glir beth sydd wedi torri. Yn ail, ni ddylai fod gormod o rybuddion, oherwydd mae gormod o rai nad ydynt yn hanfodol yn arwain at anwybyddu pob hysbysiad.
Rhaid i geisiadau fod yn ddi-wladwriaeth. Rydym wedi dod yn argyhoeddedig na ddylai fod unrhyw eithriadau i'r rheol hon. Mae annibyniaeth lwyr o'r amgylchedd amser rhedeg yn hanfodol. I gyflawni hyn, gallwch storio data a rennir mewn cronfa ddata neu, er enghraifft, yn uniongyrchol yn S3. Yn well fyth, dilynwch y rheolau. https://12factor.netYn ystod cynnydd sydyn mewn amser, nid oes amser i optimeiddio cod, a rhaid rheoli'r llwyth trwy gynyddu adnoddau cyfrifiadurol yn uniongyrchol a graddio'n llorweddol.
Cwotâu a pherfformiad gwasanaethau allanol. Gyda thwf cyflym, gall problemau godi nid yn unig yn eich seilwaith ond hefyd mewn gwasanaethau allanol. Y peth mwyaf rhwystredig yw pan fydd hyn yn digwydd nid oherwydd methiant, ond oherwydd bod cwotâu neu derfynau'n cael eu cyrraedd. Felly, rhaid i wasanaethau allanol raddio cystal â chi.
Prosesau a chiwiau ar wahân. Mae hyn yn ddefnyddiol iawn pan fydd un o'r pyrth yn profi tagfeydd. Ni fyddem wedi profi oedi wrth drosglwyddo data pe na bai ciwiau SMS llawn wedi ymyrryd â chyfnewid hysbysiadau rhwng systemau gwybodaeth. Ar ben hynny, byddai wedi bod yn haws cynyddu nifer y gweithwyr pe byddent wedi bod yn rhedeg ar wahân.
Realiti ariannol. Pan fydd llifau data yn ffrwydro, does dim amser i boeni am dariffau a thanysgrifiadau. Ond maen nhw'n bwysig i'w cofio, yn enwedig os ydych chi'n gwmni bach. Gall perchennog unrhyw API, yn ogystal â'ch darparwr cynnal, godi bil sylweddol arnoch chi. Felly, darllenwch eich contractau'n ofalus.

Casgliad

Nid heb golledion, ond fe wnaethon ni oroesi'r cam hwn, a heddiw rydym yn ceisio glynu wrth yr holl egwyddorion a ddarganfuom, ac mae gan bob peiriant y gallu i gynyddu cynhyrchiant x4 yn hawdd i ymdopi ag unrhyw ddigwyddiadau annisgwyl.

Mewn postiadau yn y dyfodol, byddwn yn rhannu ein profiad o ymchwilio i ostyngiadau perfformiad yn Apache Solr, yn trafod optimeiddio ymholiadau, ac yn trafod sut mae gweithio gyda'r Gwasanaeth Treth Ffederal yn helpu'r cwmni i arbed arian. Tanysgrifiwch i'n blog i gael y wybodaeth ddiweddaraf, a rhowch wybod i ni yn y sylwadau os ydych chi wedi dod ar draws problemau tebyg yn ystod traffig cynyddol.