Zdravo, moje ime je Evgeniy. Radim u infrastrukturi za pretraživanje Yandex.Marketa. Želim da ispričam Habr zajednici o unutrašnjoj kuhinji Marketa - i imam mnogo toga za reći. Prije svega, kako funkcionira pretraživanje tržišta, procesi i arhitektura. Kako se nosimo sa hitnim situacijama: šta se dešava ako se jedan server pokvari? Šta ako ima 100 takvih servera?
Također ćete naučiti kako implementiramo nove funkcionalnosti na gomilu servera odjednom. I kako testiramo složene usluge direktno u proizvodnji, bez izazivanja neugodnosti korisnicima. Općenito, kako funkcionira pretraga tržišta tako da se svi dobro provedu.
Malo o nama: koji problem rješavamo
Kada unesete tekst, tražite proizvod po parametrima ili uporedite cijene u različitim trgovinama, svi zahtjevi se šalju servisu pretraživanja. Pretraga je najveća usluga na tržištu.
Obrađujemo sve zahtjeve za pretraživanje: sa web lokacija market.yandex.ru, beru.ru, usluge Supercheck, Yandex.Advisor, mobilnih aplikacija. Također uključujemo ponude proizvoda u rezultate pretraživanja na yandex.ru.
Pod servisom pretrage ne mislim samo na samu pretragu, već i na bazu podataka sa svim ponudama na Tržištu. Razmjer je sljedeći: dnevno se obradi više od milijardu zahtjeva za pretraživanje. I sve bi trebalo raditi brzo, bez prekida i uvijek proizvoditi željeni rezultat.
Šta je šta: Tržišna arhitektura
Ukratko ću opisati trenutnu arhitekturu tržišta. Može se grubo opisati dijagramom ispod:
Recimo da nam dođe partnerska prodavnica. Kaže da želim da prodam igračku: ovu zlu mačku sa škripom. I još jedna ljuta mačka bez piskala. I samo mačka. Zatim prodavnica treba da pripremi ponude za kojima Tržište traži. Prodavnica generiše poseban xml sa ponudama i saopštava putanju do ovog xml-a kroz partnersko sučelje. Indekser zatim povremeno preuzima ovaj xml, provjerava greške i sprema sve informacije u ogromnu bazu podataka.
Postoji mnogo takvih sačuvanih xml-ova. Iz ove baze podataka kreira se indeks pretraživanja. Indeks se pohranjuje u internom formatu. Nakon kreiranja indeksa, Layout servis ga učitava na servere za pretraživanje.
Kao rezultat toga, u bazi podataka pojavljuje se ljuta mačka sa piscem, a na serveru se pojavljuje indeks mačke.
Reći ću vam kako tražimo mačku u dijelu o arhitekturi pretraživanja.
Arhitektura pretraživanja tržišta
Živimo u svijetu mikrousluga: svaki dolazni zahtjev uzrokuje mnogo podupita, a desetine servisa su uključene u njihovu obradu. Dijagram prikazuje samo nekoliko:
Pojednostavljena šema obrade zahtjeva
Svaka usluga ima divnu stvar - svoj balanser sa jedinstvenim imenom:
Balanser nam daje veću fleksibilnost u upravljanju uslugom: možete, na primjer, isključiti servere, što je često potrebno za ažuriranja. Balanser vidi da je server nedostupan i automatski preusmjerava zahtjeve na druge servere ili centre podataka. Prilikom dodavanja ili uklanjanja servera, opterećenje se automatski redistribuira između servera.
Jedinstveni naziv balansera ne zavisi od data centra. Kada usluga A uputi zahtjev B, tada po defaultu balanser B preusmjerava zahtjev na trenutni centar podataka. Ako je usluga nedostupna ili ne postoji u trenutnom podatkovnom centru, tada se zahtjev preusmjerava na druge podatkovne centre.
Jedinstveni FQDN za sve centre podataka omogućava servisu A da se potpuno apstrahuje od lokacija. Njegov zahtjev za uslugu B uvijek će biti obrađen. Izuzetak je slučaj kada se servis nalazi u svim data centrima.
Ali nije sve tako ružičasto s ovim balanserom: imamo dodatnu međukomponentu. Balanser može biti nestabilan, a ovaj problem rješavaju redundantni serveri. Postoji i dodatno kašnjenje između usluga A i B. Ali u praksi je manje od 1 ms i za većinu usluga to nije kritično.
Suočavanje s neočekivanim: balansiranje i otpornost usluge pretraživanja
Zamislite da je došlo do kolapsa: trebate pronaći mačku sa škripom, ali server se ruši. Ili 100 servera. Kako izaći? Hoćemo li zaista ostaviti korisnika bez mačke?
Situacija je zastrašujuća, ali mi smo spremni za to. Reći ću ti redom.
Infrastruktura pretraživanja nalazi se u nekoliko data centara:
Prilikom projektovanja uključujemo mogućnost gašenja jednog data centra. Život je pun iznenađenja - na primjer, bager može preseći podzemni kabl (da, to se dogodilo). Kapacitet u preostalim podatkovnim centrima trebao bi biti dovoljan da izdrži vršno opterećenje.
Razmotrimo jedan centar podataka. Svaki data centar ima istu šemu rada balansera:
Jedan balanser je najmanje tri fizička servera. Ova redundantnost je napravljena radi pouzdanosti. Balanseri rade na HAProx-u.
Odabrali smo HAProx zbog njegovih visokih performansi, niskih zahtjeva za resursima i široke funkcionalnosti. Naš softver za pretraživanje radi unutar svakog servera.
Vjerovatnoća da će jedan server otkazati je mala. Ali ako imate mnogo servera, povećava se vjerovatnoća da će se barem jedan pokvariti.
Ovo se dešava u stvarnosti: serveri se ruše. Stoga je potrebno stalno pratiti status svih servera. Ako server prestane da reaguje, automatski se isključuje iz saobraćaja. U tu svrhu, HAProxy ima ugrađenu provjeru zdravlja. Ide na sve servere jednom u sekundi sa HTTP zahtjevom “/ping”.
Još jedna karakteristika HAProxy: provjera agenta omogućava vam da ravnomjerno učitate sve servere. Da bi to uradio, HAProxy se povezuje sa svim serverima, a oni vraćaju svoju težinu u zavisnosti od trenutnog opterećenja od 1 do 100. Težina se izračunava na osnovu broja zahteva u redu za obradu i opterećenja procesora.
Sada o pronalaženju mačke. Rezultati pretrage u zahtjevima kao što su: /search?text=ljuti+mačka. Da bi pretraga bila brza, cijeli cat indeks mora stati u RAM. Čak ni čitanje sa SSD-a nije dovoljno brzo.
Nekada je baza ponuda bila mala, a za nju je bila dovoljna RAM memorija jednog servera. Kako je baza ponude rasla, sve više nije stajalo u ovoj RAM memoriji, a podaci su podijeljeni na dva dijela: dio 1 i dio 2.
Ali to se uvijek događa: svako rješenje, čak i ono dobro, dovodi do drugih problema.
Balanser je i dalje otišao na bilo koji server. Ali na mašini gde je stigao zahtev, bila je samo polovina indeksa. Ostalo je bilo na drugim serverima. Stoga je server morao ići na neku susjednu mašinu. Nakon prijema podataka sa oba servera, rezultati su kombinovani i ponovo rangirani.
Budući da balanser ravnomjerno raspoređuje zahtjeve, svi serveri su se bavili ponovnim rangiranjem, a ne samo slanjem podataka.
Problem je nastao ako je susjedni server bio nedostupan. Rješenje je bilo odrediti nekoliko servera sa različitim prioritetima kao „susjedni“ server. Prvo, zahtjev je poslan serverima u trenutnom rack-u. Ako nije bilo odgovora, zahtjev je poslan svim serverima u ovom data centru. I na kraju, zahtjev je otišao u druge centre podataka.
Kako je broj prijedloga rastao, podaci su podijeljeni u četiri dijela. Ali to nije bila granica.
Trenutno se koristi konfiguracija od osam dijelova. Osim toga, radi uštede još više memorije, indeks je podijeljen na dio za pretraživanje (koji se koristi za pretraživanje) i dio s isječkom (koji nije uključen u pretragu).
Jedan server sadrži informacije samo za jedan šard. Stoga, da biste pretražili cijeli indeks, trebate pretražiti na osam servera koji sadrže različite dijelove.
Serveri su grupirani u klastere. Svaki klaster sadrži osam pretraživača i jedan snippet server.
Server isječaka pokreće bazu podataka ključ/vrijednost sa statičkim podacima. Potrebni su za izdavanje dokumenata, na primjer, opis mačke sa škripom. Podaci se posebno prenose na poseban server kako se ne bi učitavala memorija pretraživača.
Budući da su ID-ovi dokumenata jedinstveni samo unutar jednog indeksa, može doći do situacije u kojoj nema dokumenata u isječcima. Pa, ili da će za jedan ID biti različit sadržaj. Stoga, da bi pretraga funkcionirala i da bi se rezultati vratili, postojala je potreba za dosljednošću u cijelom klasteru. U nastavku ću vam reći kako pratimo dosljednost.
Sama pretraga je strukturirana na sljedeći način: zahtjev za pretraživanje može doći na bilo koji od osam servera. Recimo da je došao na server 1. Ovaj server obrađuje sve argumente i razumije šta i kako treba tražiti. U zavisnosti od dolaznog zahtjeva, server može uputiti dodatne zahtjeve vanjskim servisima za potrebne informacije. Jedan zahtjev može biti praćen do deset zahtjeva eksternim servisima.
Nakon prikupljanja potrebnih informacija, počinje pretraga u bazi ponude. Da bi se to uradilo, podupiti se prave za svih osam servera u klasteru.
Kada se dobiju odgovori, rezultati se kombinuju. Na kraju, možda će biti potrebno još nekoliko potupita serveru isječaka za generiranje rezultata.
Upiti za pretraživanje unutar klastera izgledaju ovako: /shard1?text=ljuti+mačka. Osim toga, podupiti obrasca se stalno prave između svih servera unutar klastera jednom u sekundi: /status.
Zahtjev /status detektuje situaciju u kojoj server nije dostupan.
Također kontrolira da su verzija tražilice i verzija indeksa iste na svim serverima, inače će biti nedosljednih podataka unutar klastera.
Unatoč činjenici da jedan snippet server obrađuje zahtjeve od osam pretraživača, njegov procesor je vrlo malo opterećen. Stoga sada prenosimo podatke isječka na zasebnu uslugu.
Za prijenos podataka uveli smo univerzalne ključeve za dokumente. Sada je nemoguća situacija da se sadržaj iz drugog dokumenta vraća pomoću jednog ključa.
Ali prijelaz na drugu arhitekturu još nije završen. Sada želimo da se riješimo namjenskog servera isječaka. I onda se potpuno udaljite od strukture klastera. To će nam omogućiti da nastavimo s lakoćom skaliranja. Dodatni bonus je značajna ušteda gvožđa.
A sada strašne priče sa srećnim završetkom. Razmotrimo nekoliko slučajeva nedostupnosti servera.
Desilo se nešto strašno: jedan server je nedostupan
Recimo da je jedan server nedostupan. Tada preostali serveri u klasteru mogu nastaviti da odgovaraju, ali rezultati pretrage neće biti potpuni.
Putem provjere statusa /status susjedni serveri razumiju da je jedan nedostupan. Stoga, za održavanje kompletnosti, svi serveri u klasteru po zahtjevu /ping počinju da odgovaraju balanseru da su i oni nedostupni. Ispostavilo se da su svi serveri u klasteru umrli (što nije tačno). Ovo je glavni nedostatak naše šeme klastera - zato želimo da se maknemo od nje.
Zahtjeve koji ne uspiju s greškom balanser ponovo šalje na druge servere.
Balanser takođe prestaje da šalje korisnički saobraćaj mrtvim serverima, ali nastavlja da proverava njihov status.
Kada server postane dostupan, počinje da odgovara na /ping. Čim počnu da stižu normalni odgovori na pingove sa mrtvih servera, balanseri tamo počinju da šalju korisnički saobraćaj. Rad klastera je obnovljen, ura.
Još gore: mnogi serveri su nedostupni
Značajan dio servera u data centru je prekinut. Šta raditi, kuda bježati? Balanser ponovo dolazi u pomoć. Svaki balanser stalno pohranjuje u memoriju trenutni broj živih servera. Stalno izračunava maksimalnu količinu saobraćaja koju trenutni data centar može obraditi.
Kada se mnogi serveri u data centru pokvare, balanser shvata da ovaj data centar ne može obraditi sav saobraćaj.
Tada višak saobraćaja počinje da se nasumično raspoređuje na druge centre podataka. Sve radi, svi su zadovoljni.
Kako to radimo: objavljivanje izdanja
Sada razgovarajmo o tome kako objavljujemo promjene napravljene na usluzi. Ovdje smo krenuli putem pojednostavljivanja procesa: uvođenje novog izdanja gotovo je potpuno automatizirano.
Kada se u projektu akumulira određeni broj izmjena, automatski se kreira novo izdanje i počinje njegova izrada.
Zatim se servis pokreće na testiranje, gdje se provjerava stabilnost rada.
Istovremeno se pokreće automatsko testiranje performansi. Ovim se bavi posebna služba. Neću sada o tome - njegov opis je vrijedan posebnog članka.
Ako je objavljivanje u testiranju uspješno, automatski se pokreće objavljivanje izdanja u prestabilu. Prestable je poseban klaster u koji se usmjerava normalan korisnički promet. Ako vrati grešku, balanser šalje ponovni zahtjev proizvodnji.
U prestabilnom, vrijeme odziva se mjeri i poredi sa prethodnim izdanjem u proizvodnji. Ako je sve u redu, onda se osoba povezuje: provjerava grafikone i rezultate testiranja opterećenja i zatim kreće u proizvodnju.
Sve najbolje ide korisniku: A/B testiranje
Nije uvijek očigledno da li će promjene usluge donijeti stvarne koristi. Kako bi izmjerili korisnost promjena, ljudi su smislili A/B testiranje. Reći ću vam malo o tome kako to funkcionira u Yandex.Market pretrazi.
Sve počinje dodavanjem novog CGI parametra koji omogućava novu funkcionalnost. Neka naš parametar bude: market_new_functionality=1. Zatim u kodu omogućavamo ovu funkcionalnost ako je zastavica prisutna:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Nova funkcionalnost se uvodi u proizvodnju.
Za automatizaciju A/B testiranja postoji posebna usluga koja pruža detaljne informacije . U servisu se kreira eksperiment. Udio prometa je postavljen, na primjer, 15%. Procenti se ne postavljaju za upite, već za korisnike. Trajanje eksperimenta je također naznačeno, na primjer, tjedan dana.
Nekoliko eksperimenata se može izvoditi istovremeno. U postavkama možete odrediti da li je moguće ukrštanje sa drugim eksperimentima.
Kao rezultat toga, usluga automatski dodaje argument market_new_functionality=1 do 15% korisnika. Također automatski izračunava odabrane metrike. Nakon što je eksperiment završen, analitičari gledaju rezultate i donose zaključke. Na osnovu nalaza donosi se odluka o puštanju u proizvodnju ili doradu.
Spretna ruka tržišta: testiranje u proizvodnji
Često se dešava da morate testirati rad nove funkcionalnosti u produkciji, ali niste sigurni kako će se ona ponašati u „borbenim“ uslovima pod velikim opterećenjem.
Postoji rješenje: zastavice u CGI parametrima mogu se koristiti ne samo za A/B testiranje, već i za testiranje nove funkcionalnosti.
Napravili smo alat koji vam omogućava trenutnu promjenu konfiguracije na hiljadama servera bez izlaganja usluge rizicima. Zove se "Stop Tap". Prvobitna ideja je bila da se može brzo onemogućiti neka funkcionalnost bez izgleda. Zatim se alat proširio i postao složeniji.
Dijagram toka usluge je predstavljen u nastavku:
Vrijednosti zastavice se postavljaju preko API-ja. Usluga upravljanja pohranjuje ove vrijednosti u bazu podataka. Svi serveri idu u bazu podataka svakih deset sekundi, ispumpavaju vrijednosti zastavice i primjenjuju ove vrijednosti na svaki zahtjev.
U Stop tapu možete postaviti dvije vrste vrijednosti:
1) Uslovni izrazi. Primijeniti kada je jedna od vrijednosti istinita. Na primjer:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Vrijednost "3" će se primijeniti kada se zahtjev obradi na lokaciji DC1. A vrijednost je "4" kada se zahtjev obradi na drugom klasteru za web lokaciju beru.ru.
2) Bezuslovne vrijednosti. Podrazumevano primenite ako nijedan od uslova nije ispunjen. Na primjer:
vrijednost, vrijednost!
Ako se vrijednost završava uskličnikom, daje joj se veći prioritet.
Parser CGI parametara analizira URL. Zatim primjenjuje vrijednosti iz Stop Tap-a.
Primjenjuju se vrijednosti sa sljedećim prioritetima:
- Sa povećanim prioritetom od Stop Tap (znak uzvika).
- Vrijednost iz zahtjeva.
- Zadana vrijednost od Stop tap.
- Zadana vrijednost u kodu.
Postoji mnogo zastava koje su naznačene u uslovnim vrijednostima - one su dovoljne za sve nama poznate scenarije:
- Data centar.
- Okruženje: proizvodnja, testiranje, sjena.
- Mesto održavanja: pijaca, beru.
- Broj klastera.
Pomoću ovog alata možete omogućiti novu funkcionalnost na određenoj grupi servera (na primjer, u samo jednom podatkovnom centru) i testirati rad ove funkcionalnosti bez ikakvog posebnog rizika za cijeli servis. Čak i ako ste negde napravili ozbiljnu grešku, sve je počelo da pada i ceo data centar se pokvario, balanseri će preusmeriti zahteve na druge data centre. Krajnji korisnici neće ništa primijetiti.
Ako primijetite problem, možete odmah vratiti zastavicu na prethodnu vrijednost i promjene će biti vraćene.
Ova usluga takođe ima svoje nedostatke: programeri je veoma vole i često pokušavaju da sve promene unesu u Stop Tap. Pokušavamo da se borimo protiv zloupotrebe.
Pristup Stop Tap dobro funkcionira kada već imate stabilan kod spreman za uvođenje u proizvodnju. U isto vrijeme i dalje sumnjate i želite provjeriti kod u "borbenim" uslovima.
Međutim, Stop Tap nije pogodan za testiranje tokom razvoja. Postoji zaseban klaster za programere koji se zove "klaster sjena".
Tajno testiranje: klaster senki
Zahtjevi iz jednog od klastera se dupliraju u klaster u sjeni. Ali balanser potpuno ignoriše odgovore iz ovog klastera. U nastavku je prikazan dijagram njegovog rada.
Dobijamo testni klaster koji je u pravim “borbenim” uslovima. Tamo ide normalan korisnički promet. Hardver u oba klastera je isti, tako da se performanse i greške mogu porediti.
A budući da balanser potpuno zanemaruje odgovore, krajnji korisnici neće vidjeti odgovore iz klastera sjena. Stoga nije strašno pogriješiti.
nalazi
Dakle, kako smo izgradili pretragu tržišta?
Kako bi sve proteklo glatko, odvajamo funkcionalnost u zasebne usluge. Na ovaj način možemo skalirati samo one komponente koje su nam potrebne i učiniti komponente jednostavnijim. Lako je dodijeliti zasebnu komponentu drugom timu i podijeliti odgovornosti za rad na njoj. A značajna ušteda u gvožđu ovim pristupom je očigledan plus.
Pomaže nam i klaster sjena: možemo razviti usluge, testirati ih u procesu i ne ometati korisnika.
Pa, naravno testiranje u proizvodnji. Trebate promijeniti konfiguraciju na hiljadama servera? Lako, koristite Stop Tap. Na ovaj način možete odmah pokrenuti gotovo složeno rješenje i vratiti se na stabilnu verziju ako se pojave problemi.
Nadam se da sam uspeo da pokažem kako činimo Market brzim i stabilnim sa stalno rastućom bazom ponuda. Kako rješavamo probleme servera, rješavamo ogroman broj zahtjeva, poboljšavamo fleksibilnost servisa i to radimo bez prekidanja radnih procesa.
izvor: www.habr.com