Silav Habr! Di van du mehên dawî de em di rewşek pir balkêş de dijîn û ez dixwazim çîroka xweya pîvana binesaziyê parve bikim. Di vê demê de, SberMarket di fermanan de 4 carî mezin bû û karûbarê li 17 bajarên nû da destpêkirin. Mezinbûna teqîner a daxwazê ji bo radestkirina firotan hewce dike ku em binesaziya xwe mezin bikin. Li ser encamên herî balkêş û bikêr di bin qutkirinê de bixwînin.

Navê min Dima Bobylev e, ez rêveberê teknîkî yê SberMarket im. Ji ber ku ev yekem posta li ser bloga me ye, ez ê çend peyvan li ser xwe û pargîdaniyê bibêjim. Payîza borî ez beşdarî pêşbirkek ji bo serokên ciwan ên Runet bûm. Ji bo pêşbirkê I li ser ka em li SberMarket çawa çanda navxweyî û nêzîkatiya pêşkeftina karûbarê dibînin. Û her çend min nekarî pêşbaziyê bi ser bixim jî, min ji xwe re prensîbên bingehîn ên ji bo pêşkeftina ekosîstema IT-ê formule kir.
Dema ku tîmek birêve dibe, girîng e ku meriv di navbera tiştê ku karsazî hewce dike û hewcedariyên her pêşdebiran de têgihîştin û hevsengiyek bibîne. Naha SberMarket sal bi sal 13 carî mezin dibe, û ev bandorê li hilberê dike, hewce dike ku ew bi domdarî hejmûn û leza pêşkeftinê zêde bike. Digel vê yekê, em ji bo analîza pêşîn û kodkirina kalîteyê demek têra xwe ji pêşdebiran re vediqetînin. Nêzîkatiya çêkirî ne tenê di afirandina hilberek xebatê de, di heman demê de di mezinbûn û pêşkeftina wê de jî dibe alîkar. Di encama vê mezinbûnê de, SberMarket jixwe di nav karûbarên radestkirina firotgehan de bûye pêşeng: em her roj nêzî 18 hezar siparîşan dişînin, her çend di destpêka Sibatê de nêzî 3500 ji wan hebûn.

Rojekê, xerîdarek ji kuryevanek SberMarket xwest ku bêtemasî jê re fêkiyan bişîne - rastê li balkonê
Lê em biçin ser taybetmendiyan. Di van çend mehên borî de, me bi awayekî çalak binesaziya pargîdaniya xwe mezin kir. Ev hewcedarî ji hêla faktorên derve û hundur ve hate ravekirin. Ligel berfirehbûna bingeha xerîdar, hejmara firotgehên girêdayî ji 90 di destpêka salê de gihîştiye zêdetirî 200 di nîvê Gulanê de. Em, bê guman, amade bûn, binesaziya sereke veqetandin, ji bilî vê yekê me li ser îhtîmala pîvandina vertîkal û horizontî ya hemî makîneyên virtual yên ku di ewrê Yandex de têne mêvandar kirin hesibandin. Lêbelê, pratîkê destnîşan kir: "Her tiştê ku dikare xelet bibe, dê xelet bibe." Û îro ez dixwazim rewşên herî balkêş ên ku di van hefteyan de qewimîne parve bikim. Ez hêvî dikim ku ezmûna me dê ji we re bikêr be.
Slav di amadebaşiya şer de ye
Tewra berî destpêkirina pandemiyê, em bi zêdebûna hejmara daxwazên serverên meya paşîn re rû bi rû man. Meyla fermankirina firotgehên ji bo radestkirina malê dest pê kir ku dest pê kir, û bi danasîna yekem tedbîrên xwe-izolkirinê yên ji ber COVID-19, bargiraniya kar di nav rojê de pir zêde mezin bû. Pêdivî bû ku bi lez serverên sereke yên databasa sereke werin dakêşandin û hin daxwazên xwendinê veguherînin pêşkêşkerên replica (xulam).
Me ji bo vê gavê pêşwext amade kir, û 2 serverên xulam berê ji bo manevrayek wusa hatibûn destpêkirin. Wan bi giranî peywirên berhevokê bikar anîn da ku ji bo danûstandina daneyan bi hevalbendan re fêkiyên agahdariyê çêbikin. Van pêvajoyan barek zêde afirand û bi rastî çend meh berê ji hevkêşeyê hatin derxistin.
Ji ber ku dubarekirin li ser Slave pêk hat, me girêda vê têgînê ku serîlêdan tenê di moda tenê xwendinê de dikarin bi wan re bixebitin. Plana Vegerandina Karesatê texmîn dikir ku di bûyera karesatekê de, em dikarin bi tenê Slave li şûna Master siwar bikin û hemî daxwazên nivîsandin û xwendinê ji Slave re biguhezînin. Lêbelê, me di heman demê de xwest ku ji bo hewcedariyên beşa analîtîk kopiyan jî bikar bînin, ji ber vê yekê server bi tevahî nehatin veguheztin ku tenê statûyê bixwînin, lê her mêvandar komek bikarhênerên xwe hebûn, û hinan jî xwediyê mafên nivîsandinê bûn ku encamên hesabkirina navîn hilînin.
Heya astek bargiraniyê, dema ku em daxwazên http hildiberînin hem ji bo nivîsandinê hem jî ji bo xwendinê têra me master hebû. Di nîvê Adarê de, tam dema ku Sbermarket biryar da ku bi tevahî veguhezîne xebata dûr, RPS-ya me dest pê kir ku bi rengek berbiçav mezin bibe. Zêdetir û bêtir xerîdarên me ketin nav xwe-îzolasyonê an ji malê xebitîn, ku ev yek bandor li ser nîşaneyên xebata me kir.
Performansa "master" êdî têr nedikir, ji ber vê yekê me dest bi veguheztina hin daxwazên xwendinê yên herî giran li replica kir. Ji bo ku bi zelalî rêgezên nivîsandina daxwaznameyên ji axayê re û xwendina daxwazên ji xulam re bişopînin, me gemara yaqût bikar anî." Me bikarhênerek taybetî bi postfix _readonly bêyî mafên nivîsandinê çêkir. Lê ji ber xeletiyek di veavakirina yek ji mêvandaran de, hin daxwazên nivîsandinê li ser navê bikarhênerek ku xwediyê mafên guncan bû çûn servera xulamê.
Pirsgirêk di cih de xwe diyar nekir, ji ber ku ... barkirina zêde derengiya koleyan zêde kir. Nakokiya daneyan di sibehê de dema ku, piştî îthalata bi şev, koleyan bi axayê xwe re "negirin" hat kifş kirin. Me ev yek bi bargiraniya zêde ya li ser karûbarê bixwe û îthalata ku bi destpêkirina firotgehên nû ve girêdayî ye ve girê da. Lê şandina daneyan bi derengiya pir-saetan re nedihat qebûlkirin, û me pêvajoyan veguherand xulamê analîtîk yê duyemîn, ji ber ku ew xwedîоçavkaniyên mezintir û bi daxwazên xwendinê nehat barkirin (ku bi vî rengî me ji xwe re kêmbûna derengiya dubarekirinê rave kir).
Dema ku me sedemên “belavbûna” koleyê sereke zanî, ya analîtîk jî ji ber heman sedemê têk çûbû. Tevî hebûna du serverên din ên ku me plan kir ku di bûyera têkçûnek masterê de barkirinê veguhezînin, ji ber xeletiyek bêbext derket holê ku di dema krîtîk de tunebûn.
Lê ji ber ku me ne tenê databasê avêt (restorasyonê wê demê bi qasî 5 demjimêran girt), lê di heman demê de wêneyek servera masterê jî, me karî ku di nav 2 demjimêran de replica dest pê bikin. Rast e, piştî vê yekê em bi qeydkirina dubarekirinê re rû bi rû man ku ji bo demek dirêj ve diherike (ji ber ku pêvajo di moda yek-têkilî de dimeşe, lê ew çîrokek bi tevahî cûda ye).
Encam: Piştî bûyerek weha, eşkere bû ku pêdivî ye ku dev ji pratîka sînorkirina nivîsandinê ji bo bikarhêneran berde û tevahiya serverê tenê xwendinê were ragihandin. Bi vê nêzîkatiyê re, guman tune ku dê di demên krîtîk de kopiyan peyda bibin.
Optimîzekirina yek pirsek giran jî dikare databasê vegerîne jiyanê
Her çend em bi domdarî kataloga li ser malperê nûve bikin jî, daxwazên ku me ji serverên Slave re şandibûn destûrek hindik ji Master da. Dema ku me pirsgirêka koleyan "ji nişka ve ji dûr ve hiştin" vedît û ji holê rakir, ji "astengiya psîkolojîk" wêdetir bû (di vê demê de dikaribû biha bihata nûve kirin, û xerîdar dê daneyên kevnar bidîta), û em neçar bûn ku hemî daxwazan biguherînin ser servera databasa sereke. Wekî encamek, malper hêdî bû ... lê bi kêmanî ew xebitî. Û dema ku Slave baş dibû, ji bilî xweşbîniyê bijarek me tune.
Dema ku pêşkêşkerên Slave vedigerin, hûrdeman hêdî hêdî derbas bûn, Master zêde barkirî ma, û me hemî hewildanên xwe avêt ser xweşbînkirina karên çalak li gorî "Qanûna Pareto": me daxwazên TOP yên ku piraniya barkirinê çêdikin hilbijart û dest pê kir . Ev li ser firînê hate kirin.
Bandorek balkêş ev bû ku MySQL, ku bi kapasîteyê ve hatî barkirin, bersiv da ku di pêvajoyan de jî başbûnek piçûktir be. Optimîzekirina çend pirsên ku tenê 5% ji barkirina giştî hilberandine, jixwe barkirina CPU-ya berbiçav nîşan daye. Wekî encamek, me karî dabînek pejirandî ya çavkaniyên ji bo Master peyda bikin da ku bi databasê re bixebite û wextê pêwîst ji bo vegerandina kopiyan werbigire.
Encam: Tewra xweşbîniyek piçûk dihêle hûn çend demjimêran di bin bargiraniyê de "bijîn". Ev ji bo me bes bû ku em serveran bi replikayan vegerînin. Bi awayê, em ê di yek ji postên jêrîn de aliyên teknîkî yên xweşbîniya pirsê nîqaş bikin. Ji ber vê yekê ji kerema xwe heke hûn wiya kêrhatî dibînin bibin aboneya bloga me.
Çavdêriya performansa karûbarên hevkariyê organîze bikin
Em fermanên xerîdar dişoxilînin, û ji ber vê yekê karûbarên me bi domdarî bi API-yên partiya sêyemîn re têkildar in - ev dergeh in ji bo şandina SMS, platformên dravdanê, pergalên rêvekirinê, geokoder, Karûbarê Bacê ya Federal û gelek pergalên din. Û gava ku bar bi lez dest pê kir, me dest pê kir ku di nav sînorên API-ê yên karûbarên hevkarê xwe de, yên ku me berê jî li ser wan nefikirîbû, dimeşin.
Zêdebûna neçaverêkirî ya kotayên karûbarên hevkar dikare bibe sedema demajoya we ya xwerû. Pir API xerîdarên ku ji sînoran derbas dibin asteng dikin, û di hin rewşan de, pir daxwaz dikarin hilberîna hevalbendek zêde bikin.
Mînakî, dema ku jimara radestkirinê mezin bû, karûbarên pê re nikarîbûn bi erkên belavkirina wan û destnîşankirina rêgezan rabin. Di encamê de derket holê ku ferman hatine kirin, lê servîsa ku rê çêkiriye nexebite. Pêdivî ye ku were gotin ku lojîstîstên me di bin van şert û mercan de hema hema ne mumkin kir, û danûstendina zelal a tîmê alîkariya tezmînata têkçûnên karûbarê demkî kir. Lê nerealîst e ku em qasek wusa fermanan her dem bi destan bişopînin, û piştî demekê em ê di navbera ferman û cîbicîkirina wan de bi ferqek ku nayê qebûlkirin re rû bi rû bimînin.
Çend tedbîrên rêxistinî hatin girtin û bi xebata hevrêzî ya tîmê alîkarî da ku dem bidest bixin dema ku me li ser şert û mercên nû li hev kir û li benda nûjenkirina xizmetguzariyan ji hin hevkaran bû. API-yên din hene ku di bûyera seyrûsefera zêde de bi bîhnfirehiya bilind û rêjeyên xerîb pesnê xwe didin. Mînakî, di destpêkê de me yek API-ya nexşeyê ya naskirî bikar anî da ku navnîşana xala radestkirinê diyar bike. Lê di dawiya mehê de me hema hema 2 mîlyon rûbil fatûreyek paqij wergirt. Piştî vê yekê, wan biryar da ku ew bi lez veguherînin. Ez ê bi reklamê re mijûl nebim, lê ez ê bibêjim ku lêçûnên me pir kêm bûne.

Encam: Pêdivî ye ku meriv şert û mercên xebatê yên hemî karûbarên hevkar bişopîne û wan di hişê xwe de bigire. Her çend îro wisa xuya bike ku ew ji bo we "bi marjînalek mezin" in, ev nayê vê wateyê ku sibê ew ê nebin asteng li ber mezinbûnê. Û, bê guman, çêtir e ku meriv berê li ser şertên darayî yên zêdekirina daxwazên karûbarê li hev bikin.
Carinan derdikeve ku ""(c) alîkarî nake
Em bi "gags" di databasa bingehîn an li ser serverên serîlêdanê de aciz in, lê dema ku pîvandinê, pirsgirêk dikarin li cîhê ku ne li bendê bûn xuya bibin Ji bo lêgerîna tevahî-text li ser malperê, em motora Apache Solr bikar tînin. Her ku bar zêde bû, me kêmbûnek di dema bersivdayînê de destnîşan kir, û barkirina pêvajoya serverê jixwe gihîştiye 100%. Ya ku dibe ku hêsantir be - bila em konteynerê bi Solr re bêtir çavkaniyan bidin.
Li şûna zêdebûna performansa hêvîkirî, server bi tenê "mir". Ew tavilê 100% bar kir û hê hêdîtir bersiv da. Di destpêkê de me 2 core û 2 GB RAM hebûn. Me biryar da ku em tiştê ku bi gelemperî dibe alîkar bikin - me 8 core û 32 GB da serverê. Her tişt pir xirabtir bû (em ê di postek cûda de tam çawa û çima ji we re vebêjin).
Di nav çend rojan de, me hûrguliyên vê pirsgirêkê fêhm kir û bi 8 core û 32 GB performansa çêtirîn bi dest xist. Ev veavakirin dihêle ku em îro zêdekirina barkirinê bidomînin, ku ev pir girîng e, ji ber ku mezinbûn ne tenê di xerîdaran de ye, lê di heman demê de di hejmara firotgehên girêdayî de jî heye - di 2 mehan de hejmara wan ducar bûye.
Encam: Rêbazên standard ên wekî "zêdetir hesin zêde bikin" her gav naxebitin. Ji ber vê yekê dema ku hûn karûbarek pîvandinê dikin, hûn hewce ne ku hûn baş têgihiştinek ka ew çawa çavkaniyan bikar tîne û xebata xwe di şert û mercên nû de di pêş de ceribandin.
Bêdewlet mifteya pîvandina asan a horizontal e
Bi gelemperî, tîmê me nêzîkatiyek naskirî dişopîne: xizmet divê ne xwediyê dewletek navxweyî (bêdewlet) be û ji hawîrdora darvekirinê serbixwe be. Vê yekê hişt ku em bi mezinbûna bargiraniyê bi pîvandina horizontî ya hêsan re mijûl bibin. Lê me karûbarê îstîsnayek hebû - hilberek ji bo karên paşerojê yên dirêj. Ew di şandina e-name û sms-an de, pêvajoyên bûyeran, hilberîna fêkiyan, îtxalkirina biha û stokan, û hilberandina wêneyan de beşdar bû. Wusa çêbû ku ew bi hilanîna pelê herêmî ve girêdayî bû û di kopiyek yekane de bû.
Gava ku hejmara peywiran di rêza pêvajoyê de zêde bû (û ev bi xwezayî bi zêdebûna hejmara fermanan re çêbû), performansa mêvandarê ku pêvajo û hilanîna pelê li ser bû bû faktorek sînordar. Wekî encamek, nûvekirina cûrbecûr û bihayan, şandina agahdariyan ji bikarhêneran re, û gelek fonksiyonên din ên krîtîk ên ku di dorê de asê mabûn rawestiyan. Tîma Ops zû hilanîna pelan koçî hilanîna torê ya mîna S3 kir, û vê yekê hişt ku em çend makîneyên hêzdar raber bikin da ku pêvajoya peywira paşîn mezin bikin.
Encam: Divê rêgeza bêdewletbûnê ji bo hemû pêkhateyan bê îstîsna were şopandin, her çend xuya be jî "em ê teqez nikaribin li vir li ber xwe bidin." Çêtir e ku meriv hinekî dem li ser birêkûpêk organîzekirina xebata hemî pergalan derbas bike ji ber ku hûn bi lez kodê ji nû ve binivîsin û karûbarek barkirî rast bikin.
7 prensîbên ji bo mezinbûna zirav
Tevî hebûna kapasîteya zêde, me di pêvajoya mezinbûnê de gav avêtiye ser gelek xeletiyan. Di vê demê de hejmara fermanan 4 qat zêde bû. Naha em rojane zêdetirî 17 fermanan li 000 bajaran radigihînin û plan dikin ku erdnîgariyê hîn bêtir berfireh bikin - di nîvê yekem a 62-an de tê çaverê kirin ku karûbar li seranserê Rûsyayê were destpêkirin. Ji bo ku em bi bargiraniya xebata mezinbûnê re rû bi rû bimînin, li ber çavan konên me yên jixwe tijî digirin, me 2020 prensîbên bingehîn ji bo xebata di şert û mercên mezinbûna domdar de pêşve xistine:
- Rêveberiya bûyerê. Me li Jîra tabloyek çêkir, ku her bûyerek di forma bilêtê de tê xuyang kirin. Ev ê di rastiyê de pêşîgirtin û pêkanîna karên têkildarî bûyerê bibe alîkar. Beriya her tiştî, di eslê xwe de, ne tirsnak e ku meriv xeletiyan bike, lê tirsnak e ku meriv di heman bûyerê de du caran xelet bike. Ji bo wan rewşên ku bûyer dubare dibin berî ku sedem were rast kirin, divê rêwerzên çalakiyê amade bin, ji ber ku di demên bargiraniya giran de girîng e ku meriv bi leza birûskê reaksiyonê bike.
- Ingopandin ji bo hemî hêmanên binesaziyê bêyî îstîsna pêwîst e. Bi saya wî bû ku me karî pêşbîniya mezinbûna bargiraniyê bikin û ji bo pêşîgirtina ji holê rakirinê bi rast "kêşan" hilbijêrin. Bi îhtîmalek mezin, di bin barek zêde de, her tiştê ku we qet li ser nefikirî dê bişkîne an dest bi hêdîbûnê bike. Ji ber vê yekê, çêtirîn e ku meriv hişyariyên nû tavilê piştî ku bûyerên yekem diqewimin ji bo çavdêrîkirin û pêşbîniya wan çêbikin.
- Alerts rast dema ku bar bi tundî zêde dibe bi tenê pêdivî ye. Pêşîn, divê ew rapor bikin ka çi bi rastî şikestiye. Ya duyemîn, divê gelek hişyarî nebin, ji ber ku pirbûna hişyariyên ne-krîtîk dibe sedema paşguhkirina hemî hişyariyan bi tevahî.
- Divê serîlêdan bê dewlet bin. Em di wê baweriyê de ne ku divê tu îstîsnayên vê qaîdeyê nebin. Pêdiviya me bi serxwebûna tam ji hawîrdora xebitandinê heye. Ji bo kirina vê yekê, hûn dikarin daneyên hevbeş di databasek de an, wek nimûne, rasterast di S3 de hilînin. Hîn çêtir e, qaîdeyan bişopînin.. Di dema zêdebûnek hişk a demê de, bi hêsanî rêyek ji bo xweşbînkirina kodê tune, û hûn neçar in ku bi rasterast zêdekirina çavkaniyên hesabkirinê û pîvana horizontî bi barkirinê re rû bi rû bimînin.
- Kota û performansa karûbarên derveyî. Bi mezinbûna bilez re, dibe ku pirsgirêk ne tenê di binesaziya we de, lê di karûbarek derveyî de jî derkeve. Tiştê herî acizker ew e ku ev ne ji ber têkçûnekê, lê ji ber gihîştina kotayan an jî sînoran çêdibe. Ji ber vê yekê divê karûbarên derveyî wekî ku hûn bikin pîvan.
- Pêvajo û rêzan ji hev veqetînin. Dema ku li yek ji dergehan astengiyek hebe ev pir arîkar dike. Ger rêzikên tevahî yên şandina SMS-ê di pevguherîna agahdariya di navbera pergalên agahdariyê de asteng nebin, em ê di veguheztina daneyê de dereng rû nedin. Û eger ew ji hev cuda bixebitin dê hêsantir hejmara karkeran zêde bibe.
- Rastiyên darayî. Dema ku di herikîna daneyan de mezinbûnek teqemenî hebe, wext tune ku meriv li ser tarîf û aboneyan bifikire. Lê hûn hewce ne ku wan bîr bînin, nemaze heke hûn pargîdaniyek piçûk in. Xwediyê her API, û her weha pêşkêşvanê mêvandariya we, dikare fatûreyek mezin derxe. Ji ber vê yekê hûn hewce ne ku peymanan bi baldarî bixwînin.
encamê
Ne bê windahî, lê em ji vê qonaxê xilas bûn, û îro em hewl didin ku bi hemî prensîbên hatine dîtin re tevbigerin, û her makîneyek jêhatî ye ku bi hêsanî hilberîna x4 zêde bike da ku bi hin bûyerên nediyar re rû bi rû bimîne.
Di postên jêrîn de, em ê ezmûna xwe di lêkolîna kêmbûna performansê de li Apache Solr parve bikin, û di heman demê de li ser xweşbînkirina pirsê û çawa danûstendina bi Karûbarê Baca Federal re ji pargîdanî re dibe alîkar ku drav bide hev biaxivin. Ji bo ku hûn tiştek ji bîr nekin, bibin aboneya bloga me, û di şîroveyan de ji me re bibêjin ka we di dema mezinbûna trafîkê de pirsgirêkên weyên bi vî rengî hebûn.

Tenê bikarhênerên qeydkirî dikarin beşdarî anketê bibin. ji kerema xwe.
Ma we carî ji ber zêdebûna giran a barkirinê ji ber kêmbûnek / kêmbûna karûbarê ji ber:
-
55,6%Nekarîna zû lê zêdekirina çavkaniyên komputerê10
-
16,7%Sînorên binesaziya pêşkêşvanê mêvandariyê3
-
33,3%Sînorên API-yên partiya sêyemîn6
-
27,8%Binpêkirina prensîbên bêdewlet ên serîlêdanên wan5
-
88,9%Koda ne-optimal ya karûbarên xwe16
18 bikarhêneran deng dan. 6 bikarhêner jî betal bûn.
Source: www.habr.com
