Pozdravljeni, ime mi je Evgeniy. Delam v iskalni infrastrukturi Yandex.Market. Skupnost Habr želim povedati o notranji kuhinji Marketa - in imam veliko za povedati. Najprej o tem, kako deluje, procesi in arhitektura storitve Market Search. Kako ravnamo v izrednih razmerah: kaj se zgodi, če en strežnik odpove? Kaj pa, če je takih strežnikov 100?
Izvedeli boste tudi, kako implementiramo nove funkcionalnosti na kup strežnikov hkrati. In kako preizkušamo kompleksne storitve neposredno v proizvodnji, ne da bi uporabnikom povzročali nevšečnosti. Na splošno, kako deluje iskanje po trgu, da se imajo vsi dobro.
Malo o nas: kakšen problem rešujemo
Ko vnesete besedilo, iščete izdelek po parametrih ali primerjate cene v različnih trgovinah, se vse zahteve pošljejo iskalni storitvi. Iskanje je največja storitev na trgu.
Obdelujemo vse iskalne zahteve: s spletnih mest market.yandex.ru, beru.ru, storitev Supercheck, Yandex.Advisor, mobilne aplikacije. Ponudbe izdelkov vključimo tudi v rezultate iskanja na yandex.ru.
Z iskalno storitvijo ne mislim le na samo iskanje, ampak tudi na bazo z vso ponudbo na trgu. Lestvica je naslednja: na dan se obdela več kot milijarda iskalnih zahtev. In vse bi moralo delovati hitro, brez prekinitev in vedno dati želeni rezultat.
Kaj je kaj: Tržna arhitektura
Na kratko bom opisal trenutno arhitekturo trga. V grobem ga je mogoče opisati s spodnjim diagramom:
Recimo, da k nam pride partnerska trgovina. Pravi, da želim prodati igračo: tega zlobnega mačka s piskačem. In še en jezen maček brez piskra. In samo mačka. Nato mora trgovina pripraviti ponudbe, ki jih Market išče. Trgovina generira poseben xml s ponudbami in prek affiliate vmesnika sporoči pot do tega xml-ja. Indeksator nato občasno prenese ta xml, preveri napake in shrani vse informacije v ogromno bazo podatkov.
Takih shranjenih xml-jev je veliko. Iz te baze podatkov se ustvari iskalni indeks. Indeks je shranjen v interni obliki. Po izdelavi indeksa ga storitev Layout naloži v iskalne strežnike.
Posledično se v bazi podatkov pojavi jezna mačka s piskačem, na strežniku pa se pojavi mačji indeks.
Kako iščemo mačko, vam bom povedal v delu o iskalni arhitekturi.
Arhitektura iskanja trga
Živimo v svetu mikrostoritev: vsaka dohodna zahteva povzroča veliko podpoizvedb, v njihovo obdelavo pa je vključenih na desetine storitev. Diagram prikazuje le nekaj:
Poenostavljena shema obdelave zahtev
Vsaka storitev ima čudovito stvar - svoj balanser z edinstvenim imenom:
Balancer nam daje večjo prilagodljivost pri upravljanju storitve: lahko na primer izklopite strežnike, kar je pogosto potrebno za posodobitve. Balancer vidi, da strežnik ni na voljo, in samodejno preusmeri zahteve na druge strežnike ali podatkovne centre. Pri dodajanju ali odstranjevanju strežnika se obremenitev samodejno prerazporedi med strežnike.
Edinstveno ime izravnalnika ni odvisno od podatkovnega centra. Ko storitev A pošlje zahtevo B-ju, potem privzeto izravnalnik B preusmeri zahtevo na trenutni podatkovni center. Če storitev ni na voljo ali ne obstaja v trenutnem podatkovnem centru, se zahteva preusmeri v druge podatkovne centre.
En sam FQDN za vse podatkovne centre omogoča storitvi A popolno abstrahiranje od lokacij. Njegova zahteva za storitev B bo vedno obdelana. Izjema je primer, ko se storitev nahaja v vseh podatkovnih centrih.
A s tem balanserjem ni vse tako rožnato: imamo dodatno vmesno komponento. Balansir je lahko nestabilen in to težavo rešijo redundantni strežniki. Obstaja tudi dodatna zakasnitev med storitvama A in B. Toda v praksi je manjša od 1 ms in za večino storitev to ni kritično.
Spopadanje z nepričakovanim: Uravnoteženje storitev iskanja in odpornost
Predstavljajte si, da pride do kolapsa: najti morate mačko s piskačem, vendar se strežnik zruši. Ali 100 strežnikov. Kako priti ven? Bomo uporabnika res pustili brez mačke?
Situacija je grozljiva, vendar smo nanjo pripravljeni. Povedal vam bom po vrsti.
Iskalna infrastruktura se nahaja v več podatkovnih centrih:
Pri projektiranju vključimo možnost zaustavitve enega podatkovnega centra. Življenje je polno presenečenj - na primer, bager lahko prereže podzemni kabel (ja, to se je zgodilo). Zmogljivosti v preostalih podatkovnih centrih naj bi zadostovale za konične obremenitve.
Vzemimo en sam podatkovni center. Vsak podatkovni center ima enako shemo delovanja izravnalnika:
En izravnalnik so vsaj trije fizični strežniki. Ta redundanca je narejena zaradi zanesljivosti. Balancerji delujejo na HAProx.
HAProx smo izbrali zaradi njegove visoke zmogljivosti, nizkih zahtev po virih in široke funkcionalnosti. Naša programska oprema za iskanje deluje znotraj vsakega strežnika.
Verjetnost, da en strežnik odpove, je majhna. Če pa imate veliko strežnikov, se poveča verjetnost, da bo vsaj eden odpovedal.
To se zgodi v resnici: strežniki se zrušijo. Zato je potrebno nenehno spremljati stanje vseh strežnikov. Če se strežnik preneha odzivati, se samodejno izključi iz prometa. V ta namen ima HAProxy vgrajen pregled zdravja. Enkrat na sekundo gre do vseh strežnikov z zahtevo HTTP »/ping«.
Druga lastnost HAProxy: agent-check vam omogoča enakomerno obremenitev vseh strežnikov. Za to se HAProxy poveže z vsemi strežniki in ti vrnejo svojo težo glede na trenutno obremenitev od 1 do 100. Teža se izračuna glede na število zahtev v čakalni vrsti za obdelavo in obremenitev procesorja.
Zdaj o iskanju mačke. Rezultat iskanja so zahteve, kot so: /search?text=angry+cat. Da bi bilo iskanje hitro, se mora celoten mačji indeks prilegati v RAM. Tudi branje s SSD diska ni dovolj hitro.
Nekoč je bila baza ponudb majhna in je zanjo zadostoval RAM enega strežnika. Ko se je baza ponudb povečala, vse ni več sodilo v ta RAM in podatki so bili razdeljeni na dva dela: shard 1 in shard 2.
A to se vedno zgodi: vsaka rešitev, tudi dobra, povzroči druge težave.
Balancer je še vedno šel na kateri koli strežnik. Toda na stroju, kjer je prišla zahteva, je bila samo polovica indeksa. Ostalo je bilo na drugih strežnikih. Zato je moral strežnik iti na sosednji stroj. Po prejemu podatkov iz obeh strežnikov so bili rezultati združeni in ponovno razvrščeni.
Ker uravnoteženje enakomerno porazdeli zahteve, so se vsi strežniki ukvarjali s prerazvrščanjem in ne samo s pošiljanjem podatkov.
Težava se je pojavila, če sosednji strežnik ni bil na voljo. Rešitev je bila določiti več strežnikov z različnimi prioritetami kot »sosednji« strežnik. Najprej je bila zahteva poslana strežnikom v trenutni omarici. Če ni bilo odgovora, je bila zahteva poslana vsem strežnikom v tem podatkovnem centru. In nazadnje, zahteva je šla v druge podatkovne centre.
Ker je število predlogov naraščalo, so bili podatki razdeljeni na štiri dele. Vendar to ni bila meja.
Trenutno se uporablja konfiguracija osmih drobcev. Poleg tega je bil indeks razdeljen na iskalni del (ki se uporablja za iskanje) in snippet del (ki ni vključen v iskanje), da bi prihranili še več pomnilnika.
En strežnik vsebuje informacije samo za en delček. Zato morate za iskanje po celotnem indeksu iskati na osmih strežnikih, ki vsebujejo različne drobce.
Strežniki so združeni v grozde. Vsaka gruča vsebuje osem iskalnikov in en strežnik za izrezke.
Strežnik izrezkov izvaja bazo podatkov ključ-vrednost s statičnimi podatki. Potrebni so za izdajo dokumentov, na primer opis mačke s piskačem. Podatki se posebej prenesejo na ločen strežnik, da ne obremenjujejo pomnilnika iskalnih strežnikov.
Ker so ID-ji dokumentov edinstveni samo znotraj enega indeksa, lahko pride do situacije, ko v izrezkih ni dokumentov. No, ali da bo za en ID drugačna vsebina. Da bi torej iskanje delovalo in se rezultati vrnili, je bila potrebna doslednost v celotni gruči. Spodaj vam bom povedal, kako spremljamo doslednost.
Samo iskanje je strukturirano na naslednji način: iskalna zahteva lahko pride na katerega koli od osmih strežnikov. Recimo, da je prišel na strežnik 1. Ta strežnik obdela vse argumente in razume, kaj in kako iskati. Odvisno od dohodne zahteve lahko strežnik dodatno zahteva zunanje storitve za potrebne informacije. Eni zahtevi lahko sledi do deset zahtev do zunanjih storitev.
Po zbiranju potrebnih podatkov se začne iskanje po bazi ponudb. Da bi to naredili, se izvedejo podpoizvedbe za vseh osem strežnikov v gruči.
Ko so odgovori prejeti, se rezultati združijo. Na koncu bo morda potrebnih še več podpoizvedb do strežnika izrezkov za generiranje rezultatov.
Iskalne poizvedbe znotraj gruče izgledajo takole: /shard1?text=angry+cat. Poleg tega se podpoizvedbe obrazca nenehno izvajajo med vsemi strežniki znotraj gruče enkrat na sekundo: /stanje.
Zahteva /stanje zazna situacijo, ko strežnik ni na voljo.
Prav tako nadzira, da sta različica iskalnika in različica indeksa enaki na vseh strežnikih, sicer bodo v gruči nedosledni podatki.
Kljub temu, da en snippet strežnik obdeluje zahteve iz osmih iskalnikov, je njegov procesor zelo malo obremenjen. Zato podatke izrezkov zdaj prenašamo v ločeno storitev.
Za prenos podatkov smo uvedli univerzalne ključe za dokumente. Zdaj je nemogoče, da se vsebina iz drugega dokumenta vrne z enim ključem.
Toda prehod na drugo arhitekturo še ni končan. Zdaj se želimo znebiti namenskega strežnika za izrezke. In potem se popolnoma oddaljite od strukture grozda. To nam bo omogočilo, da bomo lahko še naprej enostavno merili. Dodaten bonus je velik prihranek železa.
In zdaj k grozljivim zgodbam s srečnim koncem. Razmislimo o več primerih nedosegljivosti strežnika.
Zgodilo se je nekaj groznega: en strežnik je nedosegljiv
Recimo, da en strežnik ni na voljo. Nato se lahko preostali strežniki v gruči še naprej odzivajo, vendar bodo rezultati iskanja nepopolni.
Prek preverjanja stanja /stanje sosednji strežniki razumejo, da eden ni na voljo. Zato za ohranitev popolnosti vsi strežniki v gruči na zahtevo /ping začnejo odgovarjati balanserju, da so tudi nedosegljivi. Izkazalo se je, da so vsi strežniki v gruči umrli (kar ni res). To je glavna pomanjkljivost naše sheme grozdov - zato se želimo od tega oddaljiti.
Zahteve, ki so neuspešne z napako, uravnoteženje znova pošlje na druge strežnike.
Uravnoteževalec tudi preneha pošiljati uporabniški promet mrtvim strežnikom, vendar še naprej preverja njihov status.
Ko strežnik postane na voljo, se začne odzivati na /ping. Takoj, ko začnejo prihajati običajni odzivi na pinge z mrtvih strežnikov, začnejo balanserji tja pošiljati uporabniški promet. Delovanje gruče je obnovljeno, hura.
Še huje: veliko strežnikov je nedosegljivih
Precejšen del strežnikov v podatkovnem centru je izključen. Kaj storiti, kam teči? Balancer spet priskoči na pomoč. Vsak balanser stalno shranjuje v pomnilnik trenutno število živih strežnikov. Nenehno izračunava največjo količino prometa, ki ga trenutni podatkovni center lahko obdela.
Ko veliko strežnikov v podatkovnem centru odpove, izravnalnik ugotovi, da ta podatkovni center ne more obdelati vsega prometa.
Nato se presežek prometa začne naključno razporejati v druge podatkovne centre. Vse deluje, vsi so zadovoljni.
Kako to počnemo: objavljanje izdaj
Zdaj pa se pogovorimo o tem, kako objavimo spremembe storitve. Tukaj smo ubrali pot poenostavitve postopkov: uvajanje nove izdaje je skoraj popolnoma avtomatizirano.
Ko se v projektu nabere določeno število sprememb, se samodejno ustvari nova izdaja in začne se njena gradnja.
Nato se storitev uvede v testiranje, kjer se preveri stabilnost delovanja.
Hkrati se zažene samodejno testiranje zmogljivosti. Za to se ukvarja posebna služba. O tem zdaj ne bom govoril - njegov opis je vreden ločenega članka.
Če je objava v testiranju uspešna, se samodejno začne objava izdaje v prestable. Prestable je posebna gruča, kamor je usmerjen običajni uporabniški promet. Če vrne napako, izravnalnik ponovno zahteva proizvodnjo.
V prestable se odzivni časi merijo in primerjajo s prejšnjo izdajo v proizvodnji. Če je vse v redu, se oseba poveže: preveri grafe in rezultate obremenitvenega testiranja in nato začne uvajati v proizvodnjo.
Vse najboljše gre uporabniku: A/B testiranje
Ni vedno očitno, ali bodo spremembe storitve prinesle resnične koristi. Za merjenje uporabnosti sprememb so si ljudje omislili A/B testiranje. Povedal vam bom nekaj o tem, kako deluje v iskanju Yandex.Market.
Vse se začne z dodajanjem novega parametra CGI, ki omogoča novo funkcionalnost. Naj bo naš parameter: market_new_functionality=1. Nato v kodi omogočimo to funkcionalnost, če je prisotna zastavica:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Nova funkcionalnost se uvaja v produkcijo.
Za avtomatizacijo testiranja A/B je na voljo posebna storitev, ki zagotavlja podrobne informacije . V storitvi je ustvarjen poskus. Delež prometa je določen na primer 15 %. Odstotki niso nastavljeni za poizvedbe, ampak za uporabnike. Navedeno je tudi trajanje poskusa, na primer teden dni.
Hkrati je mogoče izvajati več poskusov. V nastavitvah lahko določite, ali je možno presečišče z drugimi poskusi.
Posledično storitev samodejno doda argument market_new_functionality=1 na 15 % uporabnikov. Prav tako samodejno izračuna izbrane meritve. Ko je poskus končan, analitiki pregledajo rezultate in naredijo zaključke. Na podlagi ugotovitev se sprejme odločitev o uvedbi v proizvodnjo ali izpopolnjevanje.
Tržna spretna roka: testiranje v proizvodnji
Pogosto se zgodi, da morate preizkusiti delovanje nove funkcionalnosti v produkciji, pa niste prepričani, kako se bo obnašala v “bojnih” pogojih pod velikimi obremenitvami.
Obstaja rešitev: zastavice v parametrih CGI se lahko uporabljajo ne samo za testiranje A/B, ampak tudi za testiranje novih funkcionalnosti.
Izdelali smo orodje, ki vam omogoča takojšnjo spremembo konfiguracije na tisočih strežnikih, ne da bi storitev izpostavili tveganjem. Imenuje se Stop Tap. Prvotna ideja je bila, da bi lahko hitro onemogočili nekatere funkcije brez postavitve. Nato se je orodje razširilo in postalo kompleksnejše.
Diagram poteka storitve je predstavljen spodaj:
Vrednosti zastavic se nastavijo prek API-ja. Storitev upravljanja shrani te vrednosti v bazo podatkov. Vsi strežniki gredo v bazo podatkov vsakih deset sekund, izčrpajo vrednosti zastavic in te vrednosti uporabijo za vsako zahtevo.
V tapu Ustavi lahko nastavite dve vrsti vrednosti:
1) Pogojni izrazi. Uporabi, ko je ena od vrednosti resnična. Na primer:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Vrednost "3" bo uporabljena, ko bo zahteva obdelana na lokaciji DC1. In vrednost je »4«, ko je zahteva obdelana v drugi gruči za spletno mesto beru.ru.
2) Brezpogojne vrednosti. Uporabi privzeto, če ni izpolnjen nobeden od pogojev. Na primer:
vrednost, vrednost!
Če se vrednost konča s klicajem, ima višjo prednost.
Razčlenjevalnik parametrov CGI razčleni URL. Nato uporabi vrednosti iz Stop Tap.
Uporabljene so vrednosti z naslednjimi prioritetami:
- S povečano prednostjo od Stop Tap (klicaj).
- Vrednost iz zahteve.
- Privzeta vrednost iz pipe Stop.
- Privzeta vrednost v kodi.
Obstaja veliko zastavic, ki so navedene v pogojnih vrednostih - dovolj so za vse scenarije, ki so nam znani:
- Podatkovno središče.
- Okolje: proizvodnja, testiranje, senca.
- Prizorišče: tržnica, beru.
- Številka grozda.
S tem orodjem lahko omogočite novo funkcionalnost na določeni skupini strežnikov (na primer samo v enem podatkovnem centru) in preizkusite delovanje te funkcionalnosti brez posebnega tveganja za celotno storitev. Tudi če ste nekje naredili resno napako, je vse začelo padati in je šel celoten podatkovni center, bodo balanserji preusmerili zahteve v druge podatkovne centre. Končni uporabniki ne bodo opazili ničesar.
Če opazite težavo, lahko zastavico takoj vrnete na prejšnjo vrednost in spremembe bodo razveljavljene.
Ta storitev ima tudi svoje slabosti: razvijalci jo imajo zelo radi in pogosto poskušajo potisniti vse spremembe v Stop Tap. Poskušamo se boriti proti zlorabi.
Pristop Stop Tap deluje dobro, ko že imate stabilno kodo, pripravljeno za uvedbo v produkcijo. Hkrati imate še vedno dvome in želite preveriti kodo v "bojnih" pogojih.
Vendar Stop Tap ni primeren za testiranje med razvojem. Za razvijalce obstaja ločena gruča, imenovana »senčna gruča«.
Skrivno testiranje: senčna gruča
Zahteve iz ene od gruč se podvojijo v senčno gručo. Toda balanser popolnoma ignorira odzive iz tega grozda. Diagram njegovega delovanja je predstavljen spodaj.
Dobimo testno gručo, ki je v realnih "bojnih" pogojih. Tja gre običajen uporabniški promet. Strojna oprema v obeh gručih je enaka, zato je mogoče primerjati zmogljivost in napake.
In ker izravnalnik popolnoma ignorira odgovore, končni uporabniki ne bodo videli odgovorov iz senčne gruče. Zato ni strašljivo narediti napake.
Ugotovitve
Torej, kako smo zgradili iskanje po trgu?
Da bi vse potekalo gladko, funkcionalnosti ločimo v ločene storitve. Tako lahko skaliramo samo tiste komponente, ki jih potrebujemo, in komponente poenostavimo. Enostavno je dodeliti ločeno komponento drugi ekipi in si deliti odgovornosti za delo na njej. In znaten prihranek v železu s tem pristopom je očiten plus.
Pomaga nam tudi senčna gruča: lahko razvijamo storitve, jih pri tem testiramo in ne motimo uporabnika.
No, testiranje v proizvodnji, seveda. Morate spremeniti konfiguracijo na tisočih strežnikih? Preprosto, uporabite Stop Tap. Tako lahko takoj uvedete že pripravljeno kompleksno rešitev in se vrnete na stabilno različico, če se pojavijo težave.
Upam, da sem lahko pokazal, kako naredimo trg hiter in stabilen z vedno večjo bazo ponudb. Kako rešujemo težave s strežniki, obravnavamo ogromno število zahtev, izboljšamo fleksibilnost storitve in to brez prekinitev delovnih procesov.
Vir: www.habr.com