Përshëndetje, emri im është Evgeniy. Unë punoj në infrastrukturën e kërkimit Yandex.Market. Unë dua t'i tregoj komunitetit Habr për kuzhinën e brendshme të Tregut - dhe kam shumë për të treguar. Para së gjithash, si funksionon, proceset dhe arkitektura e kërkimit të tregut. Si i trajtojmë situatat e urgjencës: çfarë ndodh nëse një server prishet? Po sikur të ketë 100 serverë të tillë?
Do të mësoni gjithashtu se si ne implementojmë funksionalitete të reja në një grup serverësh menjëherë. Dhe si testojmë shërbimet komplekse drejtpërdrejt në prodhim, pa shkaktuar asnjë shqetësim për përdoruesit. Në përgjithësi, si funksionon kërkimi i tregut në mënyrë që të gjithë të kalojnë mirë.
Pak për ne: çfarë problemi zgjidhim
Kur futni tekst, kërkoni për një produkt sipas parametrave ose krahasoni çmimet në dyqane të ndryshme, të gjitha kërkesat dërgohen në shërbimin e kërkimit. Kërkimi është shërbimi më i madh në treg.
Ne përpunojmë të gjitha kërkesat e kërkimit: nga faqet market.yandex.ru, beru.ru, shërbimi Supercheck, Yandex.Advisor, aplikacionet celulare. Ne gjithashtu përfshijmë ofertat e produkteve në rezultatet e kërkimit në yandex.ru.
Me shërbimin e kërkimit nënkuptoj jo vetëm kërkimin në vetvete, por edhe një bazë të dhënash me të gjitha ofertat në Treg. Shkalla është kjo: më shumë se një miliard kërkesa kërkimi përpunohen në ditë. Dhe gjithçka duhet të funksionojë shpejt, pa ndërprerje dhe gjithmonë të prodhojë rezultatin e dëshiruar.
Çfarë është çfarë: Arkitektura e tregut
Do të përshkruaj shkurtimisht arkitekturën aktuale të Tregut. Mund të përshkruhet përafërsisht nga diagrami i mëposhtëm:
Le të themi se na vjen një dyqan partner. Ai thotë se dua të shes një lodër: këtë mace të keqe me një kërthizë. Dhe një mace tjetër e inatosur pa një kërcitëse. Dhe vetëm një mace. Pastaj dyqani duhet të përgatisë oferta për të cilat kërkon Tregu. Dyqani gjeneron një xml special me oferta dhe komunikon rrugën drejt këtij xml përmes ndërfaqes së filialit. Më pas, indeksuesi shkarkon periodikisht këtë xml, kontrollon për gabime dhe ruan të gjithë informacionin në një bazë të dhënash të madhe.
Ka shumë xml të tilla të ruajtura. Një indeks kërkimi krijohet nga kjo bazë të dhënash. Indeksi ruhet në format të brendshëm. Pas krijimit të indeksit, shërbimi Layout e ngarkon atë në serverët e kërkimit.
Si rezultat, një mace e zemëruar me një kërcitëse shfaqet në bazën e të dhënave dhe indeksi i maceve shfaqet në server.
Unë do t'ju tregoj se si ne kërkojmë për një mace në pjesën për arkitekturën e kërkimit.
Arkitektura e kërkimit të tregut
Ne jetojmë në një botë të mikroshërbimeve: çdo kërkesë hyrëse shkakton shumë nënpyetje dhe dhjetëra shërbime janë të përfshira në përpunimin e tyre. Diagrami tregon vetëm disa:
Skema e thjeshtuar e përpunimit të kërkesave
Çdo shërbim ka një gjë të mrekullueshme - balancuesin e vet me një emër unik:
Balancuesi na jep fleksibilitet më të madh në menaxhimin e shërbimit: ju, për shembull, mund të fikni serverët, gjë që shpesh kërkohet për përditësime. Balancuesi sheh që serveri nuk është i disponueshëm dhe ridrejton automatikisht kërkesat në serverë të tjerë ose qendra të dhënash. Kur shtoni ose hiqni një server, ngarkesa rishpërndahet automatikisht midis serverëve.
Emri unik i balancuesit nuk varet nga qendra e të dhënave. Kur shërbimi A i bën një kërkesë B, atëherë si parazgjedhje balancuesi B e ridrejton kërkesën në qendrën aktuale të të dhënave. Nëse shërbimi nuk është i disponueshëm ose nuk ekziston në qendrën aktuale të të dhënave, atëherë kërkesa ridrejtohet në qendrat e tjera të të dhënave.
Një FQDN e vetme për të gjitha qendrat e të dhënave lejon shërbimin A të abstragojë plotësisht nga vendndodhjet. Kërkesa e tij për shërbimin B do të trajtohet gjithmonë. Përjashtim është rasti kur shërbimi ndodhet në të gjitha qendrat e të dhënave.
Por jo gjithçka është aq rozë me këtë balancues: ne kemi një komponent shtesë të ndërmjetëm. Balancuesi mund të jetë i paqëndrueshëm dhe ky problem zgjidhet nga serverë të tepërt. Ka gjithashtu një vonesë shtesë midis shërbimeve A dhe B. Por në praktikë është më pak se 1 ms dhe për shumicën e shërbimeve kjo nuk është kritike.
Ballafaqimi me të papriturën: Balancimi dhe elasticiteti i shërbimit të kërkimit
Imagjinoni që ka një kolaps: ju duhet të gjeni një mace me një kërcitëse, por serveri rrëzohet. Ose 100 serverë. Si të dilni jashtë? A do ta lëmë vërtet përdoruesin pa mace?
Situata është e frikshme, por ne jemi gati për të. Unë do t'ju them me radhë.
Infrastruktura e kërkimit është e vendosur në disa qendra të dhënash:
Gjatë projektimit, ne përfshijmë mundësinë e mbylljes së një qendre të dhënash. Jeta është plot surpriza - për shembull, një ekskavator mund të presë një kabllo nëntokësore (po, kjo ndodhi). Kapaciteti në qendrat e mbetura të të dhënave duhet të jetë i mjaftueshëm për të përballuar ngarkesën maksimale.
Le të shqyrtojmë një qendër të vetme të dhënash. Çdo qendër e të dhënave ka të njëjtën skemë funksionimi të balancuesit:
Një balancues është të paktën tre serverë fizikë. Ky tepricë është bërë për besueshmëri. Balancuesit funksionojnë në HAProx.
Ne zgjodhëm HAProx për shkak të performancës së tij të lartë, kërkesave të ulëta për burime dhe funksionalitetit të gjerë. Softueri ynë i kërkimit funksionon brenda çdo serveri.
Mundësia e dështimit të një serveri është e ulët. Por nëse keni shumë serverë, gjasat që të paktën një të shkojë poshtë rritet.
Kjo është ajo që ndodh në realitet: serverët rrëzohen. Prandaj, është e nevojshme të monitorohet vazhdimisht statusi i të gjithë serverëve. Nëse serveri nuk përgjigjet, ai shkëputet automatikisht nga trafiku. Për këtë qëllim, HAProxy ka një kontroll të integruar shëndetësor. Shkon në të gjithë serverët një herë në sekondë me një kërkesë HTTP "/ping".
Një veçori tjetër e HAProxy: kontrolli i agjentit ju lejon të ngarkoni të gjithë serverët në mënyrë të barabartë. Për ta bërë këtë, HAProxy lidhet me të gjithë serverët, dhe ata e kthejnë peshën e tyre në varësi të ngarkesës aktuale nga 1 në 100. Pesha llogaritet në bazë të numrit të kërkesave në radhë për përpunim dhe ngarkesës në procesor.
Tani për të gjetur macen. Kërkimi rezulton në kërkesa si: /search?text=zemer+mace. Që kërkimi të jetë i shpejtë, i gjithë indeksi i maceve duhet të futet në RAM. Edhe leximi nga SSD nuk është mjaft i shpejtë.
Njëherë e një kohë, baza e të dhënave të ofertave ishte e vogël dhe RAM-i i një serveri mjaftonte për të. Ndërsa baza e ofertës u rrit, gjithçka nuk përshtatej më në këtë RAM dhe të dhënat u ndanë në dy pjesë: copëza 1 dhe copëza 2.
Por kjo ndodh gjithmonë: çdo zgjidhje, qoftë edhe e mirë, sjell probleme të tjera.
Balancuesi ende shkoi në çdo server. Por në makinën ku erdhi kërkesa, kishte vetëm gjysmën e indeksit. Pjesa tjetër ishte në serverë të tjerë. Prandaj, serveri duhej të shkonte në një makinë fqinje. Pas marrjes së të dhënave nga të dy serverët, rezultatet u kombinuan dhe u rirenditën.
Meqenëse balancuesi shpërndan kërkesat në mënyrë të barabartë, të gjithë serverët u angazhuan në rirenditje, dhe jo vetëm në dërgimin e të dhënave.
Problemi ndodhi nëse një server fqinj nuk ishte i disponueshëm. Zgjidhja ishte të specifikoheshin disa serverë me prioritete të ndryshme si server "fqinj". Së pari, kërkesa u dërgua te serverët në raftin aktual. Nëse nuk kishte përgjigje, kërkesa u dërgohej të gjithë serverëve në këtë qendër të dhënash. Dhe së fundi, kërkesa shkoi në qendrat e tjera të të dhënave.
Me rritjen e numrit të propozimeve, të dhënat u ndanë në katër pjesë. Por ky nuk ishte kufiri.
Aktualisht, përdoret një konfigurim prej tetë copëzash. Përveç kësaj, për të kursyer edhe më shumë memorie, indeksi u nda në një pjesë kërkimi (që përdoret për kërkim) dhe një pjesë të fragmentit (që nuk përfshihet në kërkim).
Një server përmban informacion vetëm për një copëz. Prandaj, për të kërkuar indeksin e plotë, duhet të kërkoni në tetë serverë që përmbajnë copëza të ndryshme.
Serverët janë të grupuar në grupe. Çdo grup përmban tetë motorë kërkimi dhe një server të fragmenteve.
Serveri i fragmenteve drejton një bazë të dhënash me vlerë kyçe me të dhëna statike. Ato nevojiten për të lëshuar dokumente, për shembull, një përshkrim të një mace me një kërcitëse. Të dhënat transferohen posaçërisht në një server të veçantë në mënyrë që të mos ngarkohet memoria e serverëve të kërkimit.
Meqenëse ID-të e dokumenteve janë unike vetëm brenda një indeksi, mund të lindë një situatë kur nuk ka dokumente në copa. Epo, ose se për një ID do të ketë përmbajtje të ndryshme. Prandaj, në mënyrë që kërkimi të funksionojë dhe të kthehen rezultatet, ka pasur nevojë për konsistencë në të gjithë grupin. Unë do t'ju tregoj më poshtë se si ne monitorojmë qëndrueshmërinë.
Kërkimi në vetvete është i strukturuar si më poshtë: një kërkesë kërkimi mund të vijë në cilindo nga tetë serverët. Le të themi se ai erdhi në serverin 1. Ky server përpunon të gjitha argumentet dhe kupton se çfarë dhe si të kërkojë. Në varësi të kërkesës në hyrje, serveri mund të bëjë kërkesa shtesë për shërbimet e jashtme për informacionin e nevojshëm. Një kërkesë mund të pasohet nga deri në dhjetë kërkesa për shërbime të jashtme.
Pas mbledhjes së informacionit të nevojshëm, fillon një kërkim në bazën e të dhënave të ofertave. Për ta bërë këtë, nënpyetjet bëhen në të tetë serverët në grup.
Pasi të merren përgjigjet, rezultatet kombinohen. Në fund, disa pyetje të tjera në serverin e fragmenteve mund të nevojiten për të gjeneruar rezultatet.
Pyetjet e kërkimit brenda grupit duken si: /shard1?text=zemëruar+mace. Për më tepër, nënpyetjet e formularit bëhen vazhdimisht midis të gjithë serverëve brenda grupit një herë në sekondë: /statusi.
hetim /statusi zbulon një situatë ku serveri nuk është i disponueshëm.
Ai gjithashtu kontrollon që versioni i motorit të kërkimit dhe versioni i indeksit të jenë të njëjtë në të gjithë serverët, përndryshe do të ketë të dhëna jokonsistente brenda grupit.
Përkundër faktit se një server i fragmenteve përpunon kërkesa nga tetë motorë kërkimi, procesori i tij është shumë pak i ngarkuar. Prandaj, ne tani po transferojmë të dhënat e fragmentit në një shërbim të veçantë.
Për të transferuar të dhëna, ne prezantuam çelësat universalë për dokumentet. Tani është e pamundur për një situatë ku përmbajtja nga një dokument tjetër kthehet duke përdorur një çelës.
Por kalimi në një arkitekturë tjetër nuk ka përfunduar ende. Tani duam të heqim qafe serverin e dedikuar të fragmenteve. Dhe më pas largohuni krejtësisht nga struktura e grupimit. Kjo do të na lejojë të vazhdojmë të shkallëzojmë lehtësisht. Një bonus shtesë është kursimi i konsiderueshëm i hekurit.
Dhe tani tek historitë e frikshme me fund të lumtur. Le të shqyrtojmë disa raste të mosdisponueshmërisë së serverit.
Ndodhi diçka e tmerrshme: një server nuk është i disponueshëm
Le të themi se një server nuk është i disponueshëm. Pastaj serverët e mbetur në grup mund të vazhdojnë të përgjigjen, por rezultatet e kërkimit do të jenë të paplota.
Përmes kontrollit të statusit /statusi serverët fqinjë e kuptojnë se një nuk është i disponueshëm. Prandaj, për të ruajtur plotësinë, të gjithë serverët në grup për kërkesë /ping ata fillojnë t'i përgjigjen balancuesit se nuk janë gjithashtu të disponueshëm. Rezulton se të gjithë serverët në grup vdiqën (gjë që nuk është e vërtetë). Ky është pengesa kryesore e skemës sonë të grupimeve - kjo është arsyeja pse ne duam të largohemi prej saj.
Kërkesat që dështojnë me një gabim dërgohen përsëri nga balancuesi në serverë të tjerë.
Balancuesi gjithashtu ndalon dërgimin e trafikut të përdoruesve te serverët e vdekur, por vazhdon të kontrollojë statusin e tyre.
Kur serveri bëhet i disponueshëm, ai fillon t'i përgjigjet /ping. Sapo përgjigjet normale ndaj ping nga serverët e vdekur fillojnë të mbërrijnë, balancuesit fillojnë të dërgojnë trafikun e përdoruesve atje. Funksionimi i grupit është restauruar, shpejt.
Edhe më keq: shumë serverë nuk janë të disponueshëm
Një pjesë e konsiderueshme e serverëve në qendrën e të dhënave janë ndërprerë. Çfarë të bëni, ku të vraponi? Balancuesi vjen përsëri në shpëtim. Çdo balancues ruan vazhdimisht në memorie numrin aktual të serverëve të drejtpërdrejtë. Ai llogarit vazhdimisht sasinë maksimale të trafikut që qendra aktuale e të dhënave mund të përpunojë.
Kur shumë serverë në një qendër të dhënash shkojnë poshtë, balancuesi kupton se kjo qendër e të dhënave nuk mund të përpunojë të gjithë trafikun.
Pastaj trafiku i tepërt fillon të shpërndahet rastësisht në qendrat e tjera të të dhënave. Gjithçka funksionon, të gjithë janë të lumtur.
Si e bëjmë atë: botimi i botimeve
Tani le të flasim se si i publikojmë ndryshimet e bëra në shërbim. Këtu kemi marrë rrugën e thjeshtimit të proceseve: nxjerrja e një versioni të ri është pothuajse plotësisht i automatizuar.
Kur një numër i caktuar ndryshimesh grumbullohen në projekt, krijohet automatikisht një version i ri dhe fillon ndërtimi i tij.
Më pas shërbimi kalon në testim, ku kontrollohet qëndrueshmëria e funksionimit.
Në të njëjtën kohë, fillon testimi automatik i performancës. Kjo trajtohet nga një shërbim special. Unë nuk do të flas për të tani - përshkrimi i tij është i denjë për një artikull të veçantë.
Nëse publikimi në testim është i suksesshëm, publikimi i publikimit në prestable fillon automatikisht. Prestable është një grup i veçantë ku drejtohet trafiku normal i përdoruesve. Nëse kthen një gabim, balancuesi bën një rikërkesë në prodhim.
Në prestable, koha e përgjigjes matet dhe krahasohet me lëshimin e mëparshëm në prodhim. Nëse gjithçka është në rregull, atëherë një person lidhet: kontrollon grafikët dhe rezultatet e testimit të ngarkesës dhe më pas fillon të dalë në prodhim.
Gjithë të mirat i shkojnë përdoruesit: testimi A/B
Nuk është gjithmonë e qartë nëse ndryshimet në një shërbim do të sjellin përfitime reale. Për të matur dobinë e ndryshimeve, njerëzit dolën me testimin A/B. Unë do t'ju tregoj pak se si funksionon në kërkimin Yandex.Market.
Gjithçka fillon me shtimin e një parametri të ri CGI që mundëson funksionalitet të ri. Le të jetë parametri ynë: tregu_i ri_funksionaliteti=1. Pastaj në kod aktivizojmë këtë funksion nëse flamuri është i pranishëm:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Funksionaliteti i ri është duke u futur në prodhim.
Për të automatizuar testimin A/B, ekziston një shërbim i dedikuar që ofron informacion të detajuar . Një eksperiment është krijuar në shërbim. Pjesa e trafikut është vendosur, për shembull, 15%. Përqindjet janë vendosur jo për pyetje, por për përdoruesit. Kohëzgjatja e eksperimentit tregohet gjithashtu, për shembull, një javë.
Mund të kryhen disa eksperimente njëkohësisht. Në cilësimet mund të specifikoni nëse kryqëzimi me eksperimente të tjera është i mundur.
Si rezultat, shërbimi automatikisht shton një argument tregu_i ri_funksionaliteti=1 deri në 15% të përdoruesve. Ai gjithashtu llogarit automatikisht matjet e zgjedhura. Pas përfundimit të eksperimentit, analistët shikojnë rezultatet dhe nxjerrin përfundime. Bazuar në gjetjet, merret një vendim për t'u futur në prodhim ose përsosje.
Dora e shkathët e tregut: testimi në prodhim
Shpesh ndodh që ju duhet të provoni funksionimin e një funksionaliteti të ri në prodhim, por nuk jeni të sigurt se si do të sillet në kushte "luftarake" nën ngarkesë të rëndë.
Ekziston një zgjidhje: flamujt në parametrat CGI mund të përdoren jo vetëm për testimin A/B, por edhe për të testuar funksionalitetin e ri.
Ne krijuam një mjet që ju lejon të ndryshoni menjëherë konfigurimin në mijëra serverë pa e ekspozuar shërbimin ndaj rreziqeve. Quhet "Stop Tap". Ideja fillestare ishte që të mund të çaktivizonin shpejt disa funksione pa një plan urbanistik. Pastaj mjeti u zgjerua dhe u bë më kompleks.
Diagrami i rrjedhës së shërbimit është paraqitur më poshtë:
Vlerat e flamurit vendosen përmes API-së. Shërbimi i menaxhimit i ruan këto vlera në bazën e të dhënave. Të gjithë serverët shkojnë në bazën e të dhënave një herë në dhjetë sekonda, nxjerrin vlerat e flamurit dhe aplikojnë këto vlera për secilën kërkesë.
Në prekjen Stop mund të vendosni dy lloje vlerash:
1) Shprehjet e kushtëzuara. Aplikoni kur një nga vlerat është e vërtetë. Për shembull:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Vlera "3" do të zbatohet kur kërkesa të përpunohet në vendndodhjen DC1. Dhe vlera është "4" kur kërkesa përpunohet në grupin e dytë për sitin beru.ru.
2) Vlerat e pakushtëzuara. Aplikoni si parazgjedhje nëse asnjë nga kushtet nuk plotësohet. Për shembull:
vlerë, vlerë!
Nëse një vlerë përfundon me një pikëçuditëse, asaj i jepet përparësi më e lartë.
Analizuesi i parametrave CGI analizon URL-në. Më pas aplikohen vlerat nga Stop Tap.
Zbatohen vlerat me prioritetet e mëposhtme:
- Me përparësi të shtuar nga Stop Tap (pikëçuditëse).
- Vlera nga kërkesa.
- Vlera e parazgjedhur nga Ndalo prekjen.
- Vlera e parazgjedhur në kod.
Ka shumë flamuj që tregohen në vlera të kushtëzuara - ato janë të mjaftueshme për të gjithë skenarët e njohur për ne:
- Qendra e të dhënave.
- Mjedisi: prodhimi, testimi, hije.
- Vendi: market, beru.
- Numri i grupit.
Me këtë mjet, mund të aktivizoni funksione të reja në një grup të caktuar serverësh (për shembull, në vetëm një qendër të dhënash) dhe të testoni funksionimin e këtij funksioni pa ndonjë rrezik të veçantë për të gjithë shërbimin. Edhe nëse keni bërë një gabim serioz diku, gjithçka filloi të binte dhe e gjithë qendra e të dhënave u rrëzua, balancuesit do t'i ridrejtojnë kërkesat në qendrat e tjera të të dhënave. Përdoruesit përfundimtarë nuk do të vënë re asgjë.
Nëse vëreni një problem, mund ta ktheni menjëherë flamurin në vlerën e mëparshme dhe ndryshimet do të rikthehen.
Ky shërbim ka edhe anët e tij negative: zhvilluesit e duan shumë dhe shpesh përpiqen të shtyjnë të gjitha ndryshimet në Stop Tap. Ne po përpiqemi të luftojmë keqpërdorimin.
Qasja Stop Tap funksionon mirë kur tashmë keni kod të qëndrueshëm gati për t'u nxjerrë në prodhim. Në të njëjtën kohë, ju ende keni dyshime dhe dëshironi të kontrolloni kodin në kushte "luftarake".
Megjithatë, Stop Tap nuk është i përshtatshëm për testim gjatë zhvillimit. Ekziston një grup i veçantë për zhvilluesit që quhet "grup hije".
Testimi Sekret: Shadow Cluster
Kërkesat nga një nga grupimet dublikohen në grupin hije. Por balancuesi i injoron plotësisht përgjigjet nga ky grup. Diagrami i funksionimit të tij është paraqitur më poshtë.
Ne marrim një grup testimi që është në kushte reale "luftarake". Trafiku normal i përdoruesve shkon atje. Hardueri në të dy grupet është i njëjtë, kështu që performanca dhe gabimet mund të krahasohen.
Dhe meqenëse balancuesi i injoron plotësisht përgjigjet, përdoruesit përfundimtarë nuk do të shohin përgjigje nga grupi i hijes. Prandaj, nuk është e frikshme të bësh një gabim.
Gjetjet
Pra, si e ndërtuam kërkimin e tregut?
Për të bërë gjithçka të shkojë pa probleme, ne e ndajmë funksionalitetin në shërbime të veçanta. Në këtë mënyrë ne mund të shkallëzojmë vetëm ato komponentë që na duhen dhe t'i bëjmë komponentët më të thjeshtë. Është e lehtë t'i caktoni një komponent të veçantë një ekipi tjetër dhe të ndani përgjegjësitë për të punuar në të. Dhe kursimet e konsiderueshme në hekur me këtë qasje janë një plus i dukshëm.
Grupi i hijes gjithashtu na ndihmon: ne mund të zhvillojmë shërbime, t'i testojmë ato në proces dhe të mos shqetësojmë përdoruesin.
Epo, testimi në prodhim, natyrisht. Keni nevojë të ndryshoni konfigurimin në mijëra serverë? Lehtë, përdorni Stop Tap. Në këtë mënyrë ju mund të hapni menjëherë një zgjidhje komplekse të gatshme dhe të ktheheni në një version të qëndrueshëm nëse shfaqen probleme.
Shpresoj se kam qenë në gjendje të tregoj se si e bëjmë Tregun të shpejtë dhe të qëndrueshëm me një bazë ofertash gjithnjë në rritje. Si i zgjidhim problemet e serverit, trajtojmë një numër të madh kërkesash, përmirësojmë fleksibilitetin e shërbimit dhe e bëjmë këtë pa ndërprerë proceset e punës.
Burimi: www.habr.com