Kaixo, nire izena Evgeniy da. Yandex.Market bilaketa azpiegituran lan egiten dut. Habr komunitateari Merkatuaren barruko sukaldea kontatu nahi diot, eta asko daukat kontatzeko. Lehenik eta behin, Merkatu bilaketak nola funtzionatzen duen, prozesuak eta arkitektura. Nola aurre egiten diegu larrialdi egoerei: zer gertatzen da zerbitzari bat jaisten bada? Eta halako 100 zerbitzari baldin badaude?
Zerbitzari mordo batean funtzionalitate berriak nola ezartzen ditugun aldi berean ikasiko duzu. Eta nola probatzen ditugun zerbitzu konplexuak zuzenean ekoizpenean, erabiltzaileei inolako eragozpenik sortu gabe. Oro har, nola funtzionatzen duen Merkatuaren bilaketak, denek ondo pasa dezaten.
Gutaz apur bat: zer arazo konpontzen dugun
Testua sartzen duzunean, produktu bat parametroen arabera bilatzen duzunean edo denda ezberdinetako prezioak konparatzen dituzunean, eskaera guztiak bilaketa-zerbitzura bidaltzen dira. Bilaketa Merkatuko zerbitzurik handiena da.
Bilaketa-eskaera guztiak prozesatzen ditugu: market.yandex.ru, beru.ru, Supercheck zerbitzutik, Yandex.Advisor, mugikorreko aplikazioetatik. Produktuen eskaintzak ere sartzen ditugu yandex.ru-ko bilaketa-emaitzetan.
Bilaketa-zerbitzuarekin bilaketa bera ez ezik, Merkatuko eskaintza guztiekin datu-base bat ere esan nahi dut. Eskala hau da: mila milioi bilaketa eskaera baino gehiago prozesatzen dira egunean. Eta dena azkar funtzionatu behar du, etenik gabe eta beti nahi den emaitza eman.
Zer da: Merkatuaren arkitektura
Merkatuaren egungo arkitektura labur deskribatuko dut. Gutxi gorabehera beheko diagraman deskriba daiteke:
Demagun bazkide denda bat etortzen zaigula. Jostailu bat saldu nahi dudala dio: katu gaizto hau kirrinkari batekin. Eta beste katu haserre bat txirrindu gabe. Eta katu bat besterik ez. Ondoren, dendak Merkatuak bilatzen dituen eskaintzak prestatu behar ditu. Dendak xml berezi bat sortzen du eskaintzarekin eta xml honetarako bidea komunikatzen du afiliatuen interfazearen bidez. Ondoren, indexatzaileak xml hau deskargatzen du aldian-aldian, akatsak egiaztatzen ditu eta informazio guztia datu-base handi batean gordetzen du.
Horrelako xml asko daude gordeta. Datu-base honetatik bilaketa-indize bat sortzen da. Indizea barne formatuan gordetzen da. Indizea sortu ondoren, Diseinu zerbitzuak bilaketa-zerbitzarietara kargatzen du.
Ondorioz, katu haserre bat kirrin batekin agertzen da datu-basean, eta katuaren indizea zerbitzarian agertzen da.
Bilaketa arkitekturari buruzko atalean katu bat nola bilatzen dugun kontatuko dizuet.
Merkatu bilaketa-arkitektura
Mikrozerbitzuen munduan bizi gara: sarrerako eskaera guztietan azpikontsulta asko eragiten ditu, eta dozenaka zerbitzuk parte hartzen dute haien prozesamenduan. Diagramak batzuk bakarrik erakusten ditu:
Eskaerak prozesatzeko eskema sinplifikatua
Zerbitzu bakoitzak gauza zoragarri bat du: bere orekatzailea izen bakarra duena:
Balantzaileak malgutasun handiagoa ematen digu zerbitzua kudeatzeko: zerbitzariak desaktibatu ditzakezu, adibidez, eguneratzeetarako beharrezkoa dena. Balantzaileak zerbitzaria ez dagoela erabilgarri ikusten du eta automatikoki birbideratzen ditu eskaerak beste zerbitzari edo datu-zentro batzuetara. Zerbitzari bat gehitzean edo kentzean, karga automatikoki birbanatzen da zerbitzarien artean.
Balantzailearen izen bakarra ez dago datu-zentroaren araberakoa. A zerbitzuak B-ri eskaera bat egiten dionean, B orekatzaileak lehenespenez eskaera uneko datu-zentrora birbideratzen du. Zerbitzua erabilgarri ez badago edo uneko datu-zentroan ez badago, eskaera beste datu-zentro batzuetara birbideratzen da.
Datu-zentro guztietarako FQDN bakarrak A zerbitzua kokapenetatik erabat abstraitzea ahalbidetzen du. B zerbitzura egindako eskaera beti bideratuko da. Salbuespena da zerbitzua datu-zentro guztietan dagoenean.
Baina dena ez da hain arrosa orekatzaile honekin: tarteko osagai gehigarri bat dugu. Baliteke orekatzailea ezegonkorra izatea, eta arazo hau zerbitzari erredundanteek konpontzen dute. A eta B zerbitzuen artean atzerapen gehigarri bat ere badago. Baina praktikan 1 ms baino txikiagoa da eta zerbitzu gehienetarako hori ez da kritikoa.
Ezustekoari aurre egitea: bilaketa-zerbitzuen oreka eta erresilientzia
Imajinatu kolapso bat dagoela: katu bat aurkitu behar duzu squeaker batekin, baina zerbitzaria huts egiten du. Edo 100 zerbitzari. Nola atera? Benetan utziko al dugu erabiltzailea katurik gabe?
Egoera beldurgarria da, baina prest gaude horretarako. Ordenan esango dizut.
Bilaketa-azpiegitura hainbat datu-zentrotan dago:
Diseinatzerakoan, datu-zentro bat ixteko aukera sartzen dugu. Bizitza sorpresaz beteta dago; adibidez, hondeamakin batek lurpeko kable bat moztu dezake (bai, hori gertatu da). Gainerako datu-zentroen edukiera nahikoa izan behar da karga gailurra jasateko.
Har dezagun datu-zentro bakar bat. Datu-zentro bakoitzak orekatzeko eragiketa-eskema bera du:
Balantzatzaile bat gutxienez hiru zerbitzari fisiko dira. Erredundantzia hori fidagarritasunerako egina dago. Balancers HAProx-en exekutatzen dira.
HAProx errendimendu handiagatik, baliabide eskakizun baxuengatik eta funtzionaltasun zabalagatik aukeratu dugu. Gure bilaketa-softwarea zerbitzari bakoitzaren barruan exekutatzen da.
Zerbitzari batek huts egiteko probabilitatea txikia da. Baina zerbitzari asko badituzu, gutxienez bat jaisteko probabilitatea handitzen da.
Hau da errealitatean gertatzen dena: zerbitzariak huts egiten du. Hori dela eta, beharrezkoa da zerbitzari guztien egoera etengabe kontrolatzea. Zerbitzariak erantzutea uzten badu, automatikoki deskonektatuko da trafikotik. Horretarako, HAProxy-k osasun-kontrol bat dauka. Segundoan behin zerbitzari guztietara doa "/ping" HTTP eskaera batekin.
HAProxy-ren beste ezaugarri bat: agent-check-ek zerbitzari guztiak berdin kargatzeko aukera ematen du. Horretarako, HAProxy zerbitzari guztietara konektatzen da, eta egungo kargaren arabera itzultzen dute 1etik 100era. Pisua prozesatzeko ilaran dauden eskaera kopuruaren eta prozesadorearen kargaren arabera kalkulatzen da.
Orain katua aurkitzeari buruz. Bilaketak honelako eskaerak sortzen ditu: /bilatu?text=haserre+katua. Bilaketa azkarra izan dadin, katu indize osoa RAM-an sartu behar da. SSDtik irakurtzea ere ez da nahikoa azkarra.
Garai batean, eskaintzaren datu-basea txikia zen, eta zerbitzari baten RAM nahikoa zen horretarako. Eskaintza oinarria hazi ahala, dena jada ez zen RAM honetan sartzen, eta datuak bi zatitan banatu ziren: zatia 1 eta zatia 2.
Baina hori beti gertatzen da: edozein irtenbide, onek ere, beste arazo batzuk sortzen ditu.
Balantzailea edozein zerbitzaritara joan zen oraindik. Baina eskaera etorri zen makinan, indizearen erdia besterik ez zegoen. Gainerakoa beste zerbitzarietan zegoen. Hori dela eta, zerbitzariak aldameneko makina batera joan behar izan zuen. Bi zerbitzarietatik datuak jaso ondoren, emaitzak konbinatu eta berriro sailkatu ziren.
Balantzaileak eskaerak uniformeki banatzen dituenez, zerbitzari guztiak birrankingean aritu ziren, eta ez datuak bidaltzen soilik.
Arazoa gertatu da aldameneko zerbitzari bat erabilgarri ez bazegoen. Irtenbidea lehentasun ezberdineko hainbat zerbitzari zehaztea izan zen "alboko" zerbitzari gisa. Lehenik eta behin, eskaera egungo rack-eko zerbitzarietara bidali zen. Erantzunik ez bazegoen, eskaera datu-zentro honetako zerbitzari guztietara bidali zen. Eta azkenik, eskaera beste datu zentro batzuetara joan zen.
Proposamen kopurua hazi ahala, datuak lau zatitan banatu ziren. Baina hori ez zen muga.
Gaur egun, zortzi zatiko konfigurazioa erabiltzen da. Gainera, are memoria gehiago gordetzeko, aurkibidea bilaketa-zati batean (bilaketa egiteko erabiltzen dena) eta zatitxo batean (bilaketan parte hartzen ez duena) banatu zen.
Zerbitzari batek zati bakarreko informazioa dauka. Horregatik, indize osoa bilatzeko, zati desberdinak dituzten zortzi zerbitzarietan bilatu behar duzu.
Zerbitzariak multzotan biltzen dira. Kluster bakoitzak zortzi bilatzaile eta snippet zerbitzari bat ditu.
Mozkinen zerbitzariak gako-balioen datu-base bat exekutatzen du datu estatikoekin. Dokumentuak igortzeko behar dira, adibidez, katu baten deskribapena squeaker batekin. Datuak aparteko zerbitzari batera transferitzen dira, bilaketa-zerbitzarien memoria ez kargatzeko.
Dokumentuen IDak indize bakarrean bakarrak direnez, zatietan dokumenturik ez dagoenean egoera bat sor liteke. Beno, edo ID bakarrerako eduki desberdinak egongo direla. Horregatik, bilaketak funtzionatzeko eta emaitzak itzultzeko, koherentzia behar zen kluster osoan. Jarraian esango dizut nola kontrolatzen dugun koherentzia.
Bilaketa bera honela egituratuta dago: bilaketa-eskaera bat zortzi zerbitzarietako edozeinetara iritsi daiteke. Demagun 1. zerbitzarira iritsi zela. Zerbitzari honek argumentu guztiak prozesatzen ditu eta zer eta nola bilatu behar duen ulertzen du. Jasotzen den eskaeraren arabera, zerbitzariak eskaera osagarriak egin ditzake kanpoko zerbitzuei beharrezko informazioa lortzeko. Eskaera baten ondoren, gehienez hamar eskaera egin daitezke kanpoko zerbitzuetara.
Beharrezko informazioa bildu ondoren, bilaketa bat hasten da eskaintzaren datu-basean. Horretarako, klusterreko zortzi zerbitzariei azpikontsultak egiten zaizkie.
Erantzunak jaso ondoren, emaitzak batzen dira. Azkenean, baliteke zatien zerbitzariari hainbat azpikontsulta behar izatea emaitzak sortzeko.
Bilaketa-kontsultek klusterrean itxura dute: /shard1?text=haserre+katua. Horrez gain, inprimakiaren azpikontsultak etengabe egiten dira klusterreko zerbitzari guztien artean segundoan behin: /egoera.
kontsulta /egoera zerbitzaria erabilgarri ez dagoen egoera bat detektatzen du.
Era berean, bilaketa-motorearen bertsioa eta indizearen bertsioa zerbitzari guztietan berdinak direla kontrolatzen du, bestela kluster barruan datu koherenteak egongo dira.
Snippet zerbitzari batek zortzi bilatzaileren eskaerak prozesatzen dituen arren, bere prozesadorea oso arin kargatzen da. Hori dela eta, orain zatien datuak beste zerbitzu batera transferitzen ari gara.
Datuak transferitzeko, dokumentuetarako gako unibertsalak sartu ditugu. Orain ezinezkoa da beste dokumentu bateko edukia gako bakarra erabiliz itzultzea.
Baina beste arkitektura baterako trantsizioa ez da amaitu oraindik. Orain zati dedikatu zerbitzaria kendu nahi dugu. Eta gero urrundu kluster egituratik guztiz. Horrek erraz eskalatzen jarraitzeko aukera emango digu. Hobari gehigarri bat burdina aurrezte garrantzitsua da.
Eta orain amaiera zoriontsua duten istorio beldurgarrietara. Azter ditzagun zerbitzariaren erabilgarritasunik ezaren hainbat kasu.
Zerbait izugarria gertatu da: zerbitzari bat ez dago erabilgarri
Demagun zerbitzari bat ez dagoela erabilgarri. Orduan, klusterreko gainerako zerbitzariek erantzuten jarrai dezakete, baina bilaketaren emaitzak osatu gabe egongo dira.
Egoera egiaztatzeko bidez /egoera inguruko zerbitzariek ulertzen dute bat ez dagoela erabilgarri. Hori dela eta, osotasuna mantentzeko, klusterreko zerbitzari guztiak eskaera bakoitzeko /ping orekariari ere ez daudela erantzuten hasten dira. Gertatzen da klusterreko zerbitzari guztiak hil zirela (ez da egia). Hau da gure kluster eskemaren eragozpen nagusia; horregatik alde egin nahi dugu.
Errore batekin huts egiten duten eskaerak orekatzaileak beste zerbitzari batzuetara bidaltzen ditu.
Balantzaileak hildako zerbitzarietara erabiltzaileen trafikoa bidaltzeari uzten dio, baina haien egoera egiaztatzen jarraitzen du.
Zerbitzaria erabilgarri dagoenean, erantzuten hasten da /ping. Hildako zerbitzarien pingen erantzun normalak iristen hasi bezain pronto, orekatzaileak hara erabiltzailearen trafikoa bidaltzen hasten dira. Klusterraren funtzionamendua berrezarri da, tira.
Are okerrago: zerbitzari asko ez daude erabilgarri
Datu-zentroko zerbitzarien zati garrantzitsu bat moztu egiten da. Zer egin, nora korrika egin? Balantzailea berriro salbatzera dator. Balantzaile bakoitzak etengabe gordetzen du memorian zuzeneko zerbitzarien kopurua. Etengabe kalkulatzen du egungo datu-zentroak prozesatu dezakeen gehienezko trafikoa.
Datu-zentro bateko zerbitzari asko jaisten direnean, balantzailea konturatzen da datu-zentro honek ezin duela trafiko guztia prozesatu.
Orduan, gehiegizko trafikoa beste datu-zentroetara ausaz banatzen hasten da. Dena funtzionatzen du, denak pozik daude.
Nola egiten dugu: argitalpenak argitaratzea
Orain hitz egin dezagun zerbitzuan egindako aldaketak nola argitaratzen ditugun. Hemen prozesuak sinplifikatzeko bidea hartu dugu: bertsio berri bat zabaltzea ia erabat automatizatuta dago.
Proiektuan aldaketa kopuru jakin bat metatzen denean, bertsio berri bat automatikoki sortzen da eta bere eraikuntza hasten da.
Ondoren, zerbitzua probara zabaltzen da, non funtzionamenduaren egonkortasuna egiaztatzen den.
Aldi berean, errendimendu-proba automatikoak abiarazten dira. Zerbitzu berezi batek kudeatzen du. Ez dut horri buruz hitz egingo orain - bere deskribapena aparteko artikulu bat merezi du.
Testing-en argitaratzea arrakastatsua bada, bertsioaren argitalpena prestable-n automatikoki hasiko da. Prestable kluster berezi bat da, non erabiltzaileen trafiko normala bideratzen den. Errore bat itzultzen badu, orekatzaileak berriro eskaera bat egiten dio ekoizpenari.
Prestablean, erantzun denborak neurtzen dira eta aurreko bertsioarekin alderatzen dira ekoizpenean. Dena ondo badago, pertsona bat konektatzen da: karga proben grafikoak eta emaitzak egiaztatzen ditu eta, ondoren, produkziora zabaltzen hasten da.
Onena erabiltzailearentzako da: A/B probak
Ez da beti begi-bistakoa zerbitzu baten aldaketak benetako onurak ekarriko dituen ala ez. Aldaketen erabilgarritasuna neurtzeko, jendeak A/B probak egin zituen. Yandex.Market bilaketan nola funtzionatzen duen pixka bat kontatuko dizut.
Guztia funtzionalitate berriak ahalbidetzen dituen CGI parametro berri bat gehitzen hasten da. Izan bedi gure parametroa: market_new_functionality=1. Ondoren, kodean funtzionalitate hau gaituko dugu bandera badago:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Funtzionalitate berriak produkziora zabaltzen ari dira.
A/B probak automatizatzeko, informazio zehatza eskaintzen duen zerbitzu dedikatu bat dago . Esperimentu bat sortzen da zerbitzuan. Trafiko kuota ezarrita dago, adibidez, %15. Ehunekoak ez dira kontsultetarako ezartzen, erabiltzaileentzat baizik. Esperimentuaren iraupena ere adierazten da, adibidez, aste bat.
Hainbat esperimentu aldi berean egin daitezke. Ezarpenetan, beste esperimentu batzuekin elkartzea posible den zehaztu dezakezu.
Ondorioz, zerbitzuak automatikoki argumentu bat gehitzen du market_new_functionality=1 erabiltzaileen %15era. Era berean, automatikoki kalkulatzen ditu hautatutako neurketak. Esperimentua amaitu ondoren, analistek emaitzak aztertu eta ondorioak ateratzen dituzte. Aurkikuntzen arabera, ekoizpenera edo finketara zabaltzeko erabakia hartzen da.
Merkatuaren esku trebea: probak ekoizpenean
Askotan gertatzen da ekoizpenean funtzionalitate berri baten funtzionamendua probatu behar duzula, baina ez dakizu ziur nola jokatuko duen "borroka" baldintzetan karga astunean.
Bada irtenbide bat: CGI parametroetako banderak A/B probak egiteko ez ezik, funtzionalitate berriak probatzeko ere erabil daitezke.
Milaka zerbitzarietan konfigurazioa berehala aldatzeko aukera ematen duen tresna bat egin dugu, zerbitzua arriskurik jarri gabe. "Stop Tap" deitzen da. Jatorrizko ideia diseinurik gabe funtzionalitate batzuk azkar desgaitu ahal izatea zen. Orduan tresna zabaldu eta konplexuagoa bihurtu zen.
Zerbitzuaren fluxu-diagrama jarraian aurkezten da:
Bandaren balioak APIaren bidez ezartzen dira. Kudeaketa zerbitzuak datu-basean gordetzen ditu balio horiek. Zerbitzari guztiak hamar segundoan behin doaz datu-basera, banderaren balioak atera eta balio hauek aplikatzen dizkiote eskaera bakoitzari.
Gelditu ukituan bi balio mota ezar ditzakezu:
1) Baldintza esapideak. Aplikatu balioetako bat egiazkoa denean. Adibidez:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}"3" balioa aplikatuko da eskaera DC1 kokapenean prozesatzen denean. Eta balioa "4" da eskaera beru.ru guneko bigarren klusterean prozesatzen denean.
2) Baldintzarik gabeko balioak. Aplikatu lehenespenez baldintzaren bat betetzen ez bada. Adibidez:
balioa, balioa!
Balio bat harridura puntu batekin amaitzen bada, lehentasun handiagoa ematen zaio.
CGI parametro analizatzaileak URLa analizatzen du. Ondoren, Stop Tap-eko balioak aplikatzen ditu.
Lehentasun hauek dituzten balioak aplikatzen dira:
- Stop Tap-en lehentasun handiagoarekin (harridura ikurra).
- Eskaeraren balioa.
- Gelditu ukipenaren balio lehenetsia.
- Balio lehenetsia kodean.
Baldintzazko balioetan adierazten diren bandera asko daude - nahikoak dira ezagutzen ditugun eszenatoki guztietarako:
- Datu zentroa.
- Ingurunea: ekoizpena, probak, itzala.
- Lekua: azoka, beru.
- Kluster zenbakia.
Tresna honekin, zerbitzari talde jakin batean funtzionalitate berriak gaitu ditzakezu (adibidez, datu-zentro bakarrean) eta funtzionalitate horren funtzionamendua probatu dezakezu zerbitzu osorako arrisku berezirik gabe. Nonbait akats larri bat egin bazenuen ere, dena erortzen hasi zen eta datu-zentro osoa behera egin zuen, orekatzaileek eskaerak beste datu-zentro batzuetara birbideratuko dituzte. Azken erabiltzaileek ez dute ezer nabarituko.
Arazoren bat nabaritzen baduzu, berehala itzul dezakezu bandera aurreko baliora eta aldaketak atzera egingo dira.
Zerbitzu honek bere alde txarrak ere baditu: garatzaileek asko maite dute eta askotan saiatzen dira aldaketa guztiak Stop Tap-era bultzatzen. Erabilera okerraren aurka borrokatzen saiatzen ari gara.
Stop Tap ikuspegiak ondo funtzionatzen du dagoeneko kode egonkorra produkziora zabaltzeko prest duzunean. Aldi berean, zalantzak dituzu oraindik, eta kodea egiaztatu nahi duzu "borroka" baldintzetan.
Hala ere, Stop Tap ez da egokia garapenean probatzeko. Garatzaileentzako kluster bereizi bat dago "itzal-kluster" izenekoa.
Proba sekretua: Itzal Cluster
Klusterretako baten eskaerak itzaleko klusterera bikoizten dira. Baina orekatzaileak guztiz baztertzen ditu kluster honen erantzunak. Bere funtzionamenduaren diagrama behean aurkezten da.
Benetako "borroka" baldintzetan dagoen proba-kluster bat lortzen dugu. Erabiltzaileen trafiko normala bertara doa. Bi klusterren hardwarea berdina da, beraz, errendimendua eta erroreak alderatu daitezke.
Eta orekatzaileak erantzunak guztiz baztertzen dituenez, azken erabiltzaileek ez dituzte itzal-klusterren erantzunak ikusiko. Horregatik, ez da beldurgarria akats bat egitea.
Findings
Beraz, nola sortu dugu Merkatuaren bilaketa?
Dena ondo joan dadin, funtzionalitatea zerbitzu bereizietan bereizten dugu. Horrela behar ditugun osagaiak soilik eskalatu ditzakegu eta osagaiak erraztu. Erraza da beste talde bati osagai bereizi bat esleitzea eta lan egiteko ardurak partekatzea. Eta ikuspegi honekin burdina aurrezten den nabarmena abantaila nabaria da.
Itzal-klusterrak ere laguntzen digu: zerbitzuak garatu ditzakegu, prozesuan probatu eta erabiltzailea ez molestatu.
Tira, ekoizpenean probak, noski. Milaka zerbitzarietan konfigurazioa aldatu behar duzu? Erraza, erabili Stop Tap. Horrela, berehala atera dezakezu prest egindako irtenbide konplexu bat eta bertsio egonkor batera itzuli, arazoak sortzen badira.
Espero dut merkatua azkar eta egonkorra nola egiten dugun erakusteko gai izan nintzela gero eta hazten ari den eskaintza oinarri batekin. Zerbitzariaren arazoak nola konpontzen ditugun, eskaera ugariri aurre egiten, zerbitzuaren malgutasuna hobetzen dugu eta lan-prozesuak eten gabe egiten ditugu.
Iturria: www.habr.com