Dobrý deň, volám sa Evgeniy. Pracujem vo vyhľadávacej infraštruktúre Yandex.Market. Chcem komunite Habr povedať o vnútornej kuchyni Trhu – a mám toho veľa čo povedať. V prvom rade ako funguje Market search, procesy a architektúra. Ako riešime núdzové situácie: čo sa stane, ak jeden server vypadne? Čo ak existuje 100 takýchto serverov?
Dozviete sa tiež, ako implementujeme nové funkcie na veľa serverov naraz. A ako testujeme komplexné služby priamo vo výrobe, bez toho, aby sme spôsobili používateľom nejaké nepríjemnosti. Vo všeobecnosti, ako funguje vyhľadávanie na trhu, aby sa každý dobre bavil.
Trochu o nás: aký problém riešime
Keď zadáte text, vyhľadáte produkt podľa parametrov alebo porovnáte ceny v rôznych obchodoch, všetky požiadavky sa odošlú vyhľadávacej službe. Vyhľadávanie je najväčšia služba na trhu.
Spracovávame všetky žiadosti o vyhľadávanie: zo stránok market.yandex.ru, beru.ru, služba Supercheck, Yandex.Advisor, mobilné aplikácie. Ponuky produktov zahŕňame aj do výsledkov vyhľadávania na yandex.ru.
Vyhľadávacou službou myslím nielen samotné vyhľadávanie, ale aj databázu so všetkými ponukami na Markete. Rozsah je takýto: denne sa spracuje viac ako miliarda žiadostí o vyhľadávanie. A všetko by malo fungovať rýchlo, bez prerušenia a vždy prinášať požadovaný výsledok.
Čo je čo: Architektúra trhu
Stručne popíšem súčasnú architektúru Marketu. Zhruba to možno opísať pomocou nasledujúceho diagramu:
Povedzme, že k nám príde partnerská predajňa. Hovorí, že chcem predať hračku: túto zlú mačku s piskotom. A ďalšia nahnevaná mačka bez piskora. A len mačka. Potom musí obchod pripraviť ponuky, ktoré Market hľadá. Obchod vygeneruje špeciálny xml s ponukami a cez affiliate rozhranie komunikuje cestu k tomuto xml. Indexer potom pravidelne sťahuje tento xml, kontroluje chyby a ukladá všetky informácie do obrovskej databázy.
Takýchto uložených xml je veľa. Z tejto databázy sa vytvorí index vyhľadávania. Index je uložený v internom formáte. Po vytvorení indexu ho služba Layout odovzdá na vyhľadávacie servery.
Výsledkom je, že v databáze sa objaví nahnevaná mačka s pískaním a na serveri sa objaví index mačky.
V časti o architektúre vyhľadávania vám poviem, ako hľadáme mačku.
Architektúra vyhľadávania trhu
Žijeme vo svete mikroslužieb: každá prichádzajúca požiadavka spôsobuje množstvo poddotazov a na ich spracovaní sa podieľajú desiatky služieb. Diagram zobrazuje len niektoré:
Zjednodušená schéma spracovania požiadaviek
Každá služba má skvelú vec - svoj vlastný vyvažovač s jedinečným názvom:
Balancér nám poskytuje väčšiu flexibilitu pri správe služby: môžete napríklad vypnúť servery, čo sa často vyžaduje pri aktualizáciách. Balancér vidí, že server je nedostupný a automaticky presmeruje požiadavky na iné servery alebo dátové centrá. Pri pridávaní alebo odstraňovaní servera sa záťaž automaticky prerozdeľuje medzi servery.
Jedinečný názov balancéra nezávisí od dátového centra. Keď služba A odošle požiadavku na B, potom balancer B štandardne presmeruje požiadavku do aktuálneho dátového centra. Ak je služba nedostupná alebo neexistuje v aktuálnom dátovom centre, požiadavka je presmerovaná do iných dátových centier.
Jediný FQDN pre všetky dátové centrá umožňuje službe A úplne abstrahovať od miest. Jeho žiadosť do služby B bude vždy spracovaná. Výnimkou je prípad, keď sa služba nachádza vo všetkých dátových centrách.
Ale s týmto vyvažovačom nie je všetko také ružové: máme dodatočnú medzizložku. Balancér môže byť nestabilný a tento problém riešia redundantné servery. Medzi službami A a B je tiež dodatočné oneskorenie. V praxi je to však menej ako 1 ms a pre väčšinu služieb to nie je kritické.
Vyrovnanie sa s neočakávaným: Vyváženie a odolnosť vyhľadávacích služieb
Predstavte si, že dôjde ku kolapsu: musíte nájsť mačku s piskotom, ale server sa zrúti. Alebo 100 serverov. Ako sa dostať von? Naozaj necháme používateľa bez mačky?
Situácia je desivá, ale sme na to pripravení. Poviem ti to po poriadku.
Vyhľadávacia infraštruktúra sa nachádza v niekoľkých dátových centrách:
Pri návrhu zahrnieme možnosť odstavenia jedného dátového centra. Život je plný prekvapení – napríklad bager dokáže prerezať podzemný kábel (áno, stalo sa). Kapacita v zostávajúcich dátových centrách by mala byť dostatočná na to, aby vydržala špičkové zaťaženie.
Uvažujme o jednom dátovom centre. Každé dátové centrum má rovnakú prevádzkovú schému balancera:
Jeden balancer sú najmenej tri fyzické servery. Táto redundancia je vytvorená pre spoľahlivosť. Balancery bežia na HAProx.
HAProx sme si vybrali kvôli jeho vysokému výkonu, nízkym nárokom na zdroje a širokej funkčnosti. Náš vyhľadávací softvér beží na každom serveri.
Pravdepodobnosť zlyhania jedného servera je nízka. Ale ak máte veľa serverov, zvyšuje sa pravdepodobnosť, že aspoň jeden vypadne.
To je to, čo sa deje v skutočnosti: servery padajú. Preto je potrebné neustále sledovať stav všetkých serverov. Ak server prestane reagovať, automaticky sa odpojí od prevádzky. Na tento účel má HAProxy zabudovanú kontrolu stavu. Ide na všetky servery raz za sekundu s požiadavkou HTTP „/ping“.
Ďalšia funkcia HAProxy: agent-check vám umožňuje rovnomerne načítať všetky servery. Za týmto účelom sa HAProxy pripojí ku všetkým serverom a tie vrátia svoju váhu v závislosti od aktuálnej záťaže od 1 do 100. Váha sa vypočíta na základe počtu požiadaviek vo fronte na spracovanie a záťaže procesora.
Teraz o hľadaní mačky. Výsledkom vyhľadávania sú požiadavky ako: /search?text=nahnevaný+mačka. Aby bolo vyhľadávanie rýchle, celý index mačiek sa musí zmestiť do pamäte RAM. Ani čítanie z SSD nie je dostatočne rýchle.
Kedysi bola databáza ponúk malá a stačila jej RAM jedného servera. S rastom ponukovej základne sa do tejto RAM už všetko nezmestilo a dáta sa rozdelili na dve časti: shard 1 a shard 2.
Ale to sa stáva vždy: každé riešenie, dokonca aj dobré, vyvoláva ďalšie problémy.
Balancér stále išiel na akýkoľvek server. Ale na stroji, na ktorý prišla požiadavka, bola len polovica indexu. Zvyšok bol na iných serveroch. Server preto musel prejsť na nejaký susedný stroj. Po prijatí údajov z oboch serverov sa výsledky spojili a prehodnotili.
Keďže balancer distribuuje požiadavky rovnomerne, všetky servery sa podieľali na prehodnocovaní, nielen na odosielaní údajov.
Problém nastal, ak susedný server bol nedostupný. Riešením bolo špecifikovať niekoľko serverov s rôznymi prioritami ako „susedný“ server. Najprv bola požiadavka odoslaná na servery v aktuálnom stojane. Ak neprišla žiadna odpoveď, požiadavka bola odoslaná na všetky servery v tomto dátovom centre. A nakoniec, žiadosť smerovala do iných dátových centier.
Keďže počet návrhov rástol, údaje boli rozdelené do štyroch častí. Ale toto nebol limit.
V súčasnosti sa používa konfigurácia ôsmich črepov. Pre ešte väčšiu úsporu pamäte bol navyše index rozdelený na vyhľadávaciu časť (ktorá slúži na vyhľadávanie) a úryvkovú časť (ktorá nie je súčasťou vyhľadávania).
Jeden server obsahuje informácie len pre jeden zlomok. Preto, ak chcete prehľadávať celý index, musíte hľadať na ôsmich serveroch obsahujúcich rôzne fragmenty.
Servery sú zoskupené do klastrov. Každý klaster obsahuje osem vyhľadávacích nástrojov a jeden úryvkový server.
Server úryvkov prevádzkuje databázu párov kľúč – hodnota so statickými údajmi. Sú potrebné na vydanie dokumentov, napríklad popis mačky s piskorom. Údaje sa špeciálne prenášajú na samostatný server, aby nezaťažovali pamäť vyhľadávacích serverov.
Keďže ID dokumentov sú jedinečné iba v rámci jedného indexu, môže nastať situácia, že v úryvkoch nebudú žiadne dokumenty. No alebo že na jedno ID bude iný obsah. Preto, aby vyhľadávanie fungovalo a výsledky sa vracali, bola potrebná konzistentnosť v rámci celého klastra. Nižšie vám poviem, ako monitorujeme konzistenciu.
Samotné vyhľadávanie je štruktúrované nasledovne: požiadavka na vyhľadávanie môže prísť na ktorýkoľvek z ôsmich serverov. Povedzme, že prišiel na server 1. Tento server spracuje všetky argumenty a rozumie, čo a ako hľadať. V závislosti od prichádzajúcej požiadavky môže server dodatočne požiadať externé služby o potrebné informácie. Po jednej požiadavke môže nasledovať až desať požiadaviek na externé služby.
Po zhromaždení potrebných informácií začne vyhľadávanie v databáze ponúk. Na tento účel sa vytvoria poddotazy na všetkých osem serverov v klastri.
Po prijatí odpovedí sa výsledky spoja. Na vygenerovanie výsledkov môže byť nakoniec potrebných niekoľko ďalších poddotazov na server úryvkov.
Vyhľadávacie dotazy v rámci klastra vyzerajú takto: /shard1?text=nahnevaný+mačka. Okrem toho sa medzi všetkými servermi v rámci klastra neustále raz za sekundu vytvárajú poddotazy formulára: /postavenie.
Žiadosť /postavenie detekuje situáciu, keď server nie je dostupný.
Kontroluje tiež, že verzia vyhľadávacieho nástroja a verzia indexu sú rovnaké na všetkých serveroch, inak budú v klastri nekonzistentné údaje.
Napriek tomu, že jeden snippet server spracováva požiadavky z ôsmich vyhľadávačov, jeho procesor je zaťažený veľmi málo. Preto teraz prenášame údaje o úryvkoch do samostatnej služby.
Na prenos dát sme zaviedli univerzálne kľúče pre dokumenty. Teraz je nemožné, aby sa obsah z iného dokumentu vrátil pomocou jedného kľúča.
Prechod na inú architektúru ale ešte nie je dokončený. Teraz sa chceme zbaviť vyhradeného servera úryvkov. A potom sa úplne vzdialiť od klastrovej štruktúry. To nám umožní pokračovať v jednoduchom škálovaní. Bonusom navyše je výrazná úspora železa.
A teraz k strašidelným príbehom so šťastným koncom. Zoberme si niekoľko prípadov nedostupnosti servera.
Stalo sa niečo hrozné: jeden server je nedostupný
Povedzme, že jeden server je nedostupný. Potom môžu zostávajúce servery v klastri naďalej odpovedať, ale výsledky vyhľadávania budú neúplné.
Prostredníctvom kontroly stavu /postavenie susedné servery chápu, že jeden je nedostupný. Preto, aby sa zachovala úplnosť, všetky servery v klastri na požiadavku /ping začnú balancérovi odpovedať, že sú tiež nedostupní. Ukázalo sa, že všetky servery v klastri zomreli (čo nie je pravda). Toto je hlavná nevýhoda našej klastrovej schémy – preto sa jej chceme zbaviť.
Požiadavky, ktoré zlyhajú s chybou, vyvažovač odošle znova na iné servery.
Balancér tiež zastaví odosielanie návštevnosti používateľov na mŕtve servery, ale naďalej kontroluje ich stav.
Keď je server dostupný, začne odpovedať /ping. Hneď ako začnú prichádzať normálne odpovede na ping z mŕtvych serverov, balancery tam začnú posielať užívateľskú návštevnosť. Prevádzka klastra je obnovená, hurá.
Ešte horšie: veľa serverov je nedostupných
Značná časť serverov v dátovom centre je zredukovaná. Čo robiť, kam bežať? Na pomoc opäť prichádza balancer. Každý balancer neustále ukladá do pamäte aktuálny počet živých serverov. Neustále počíta maximálny objem prevádzky, ktorý môže súčasné dátové centrum spracovať.
Keď vypadne veľa serverov v dátovom centre, balancér si uvedomí, že toto dátové centrum nedokáže spracovať všetku prevádzku.
Potom sa nadmerná prevádzka začne náhodne distribuovať do iných dátových centier. Všetko funguje, všetci sú spokojní.
Ako to robíme: publikovanie vydaní
Teraz si povedzme, ako zverejňujeme zmeny vykonané v službe. Tu sme sa vydali cestou zjednodušovania procesov: zavádzanie nového vydania je takmer úplne automatizované.
Keď sa v projekte nahromadí určitý počet zmien, automaticky sa vytvorí nové vydanie a spustí sa jeho zostavovanie.
Potom sa služba spustí na testovanie, kde sa kontroluje stabilita prevádzky.
Zároveň sa spustí automatické testovanie výkonu. Toto rieši špeciálna služba. Teraz o tom nebudem hovoriť - jeho popis si zaslúži samostatný článok.
Ak je publikácia v testovaní úspešná, automaticky sa spustí publikácia vydania v prestable. Prestable je špeciálny klaster, kam smeruje bežná prevádzka používateľov. Ak vráti chybu, vyvažovačka odošle opätovnú požiadavku do výroby.
V predstabilnej verzii sa merajú časy odozvy a porovnávajú sa s predchádzajúcim vydaním vo výrobe. Ak je všetko v poriadku, potom sa človek pripojí: skontroluje grafy a výsledky testovania záťaže a potom sa spustí do výroby.
Všetko najlepšie pre používateľa: A/B testovanie
Nie je vždy zrejmé, či zmeny v službe prinesú skutočné výhody. Na meranie užitočnosti zmien ľudia prišli s A/B testovaním. Poviem vám trochu o tom, ako to funguje pri vyhľadávaní Yandex.Market.
Všetko to začína pridaním nového parametra CGI, ktorý umožňuje novú funkcionalitu. Nech je náš parameter: market_new_functionality=1. Potom v kóde povolíme túto funkciu, ak je prítomný príznak:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Do výroby sa zavádza nová funkcia.
Na automatizáciu A/B testovania existuje špecializovaná služba, ktorá poskytuje podrobnosti . V službe sa vytvorí experiment. Podiel návštevnosti je stanovený napríklad na 15 %. Percentá nie sú nastavené pre dopyty, ale pre používateľov. Uvádza sa aj trvanie experimentu, napríklad týždeň.
Súčasne je možné spustiť niekoľko experimentov. V nastaveniach môžete určiť, či je možný prienik s inými experimentmi.
V dôsledku toho služba automaticky pridá argument market_new_functionality=1 až 15 % používateľov. Automaticky tiež vypočítava vybrané metriky. Po dokončení experimentu sa analytici pozrú na výsledky a vyvodia závery. Na základe zistení sa rozhodne o zavedení do výroby alebo zdokonaľovania.
Šikovná ruka trhu: testovanie vo výrobe
Často sa stáva, že potrebujete otestovať fungovanie novej funkcionality vo výrobe, no neviete, ako sa bude správať v „bojových“ podmienkach pri veľkom zaťažení.
Existuje riešenie: príznaky v parametroch CGI možno použiť nielen na testovanie A/B, ale aj na testovanie novej funkcionality.
Vytvorili sme nástroj, ktorý vám umožní okamžite zmeniť konfiguráciu na tisíckach serverov bez toho, aby ste službu vystavili rizikám. Volá sa Stop Tap. Pôvodnou myšlienkou bola možnosť rýchlo deaktivovať niektoré funkcie bez rozloženia. Potom sa nástroj rozšíril a stal sa zložitejším.
Diagram toku služby je uvedený nižšie:
Hodnoty príznakov sa nastavujú cez API. Služba správy ukladá tieto hodnoty do databázy. Všetky servery idú do databázy raz za desať sekúnd, vypumpujú hodnoty príznakov a použijú tieto hodnoty na každú požiadavku.
V klepnutí Stop môžete nastaviť dva typy hodnôt:
1) Podmienkové výrazy. Použiť, keď je jedna z hodnôt pravdivá. Napríklad:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Hodnota "3" sa použije pri spracovaní požiadavky v umiestnení DC1. A hodnota je „4“, keď je požiadavka spracovaná na druhom klastri pre stránku beru.ru.
2) Bezpodmienečné hodnoty. Použiť predvolene, ak nie je splnená žiadna z podmienok. Napríklad:
hodnota, hodnota!
Ak hodnota končí výkričníkom, má vyššiu prioritu.
Analyzátor parametrov CGI analyzuje adresu URL. Potom použije hodnoty z Stop Tap.
Použijú sa hodnoty s nasledujúcimi prioritami:
- So zvýšenou prioritou od Stop Tap (výkričník).
- Hodnota z požiadavky.
- Predvolená hodnota z klepnutia Stop.
- Predvolená hodnota v kóde.
Existuje veľa príznakov, ktoré sú uvedené v podmienených hodnotách - stačia pre všetky nám známe scenáre:
- Dátové centrum.
- Prostredie: výroba, testovanie, tieň.
- Miesto konania: trh, beru.
- Číslo klastra.
Pomocou tohto nástroja môžete povoliť novú funkcionalitu na určitej skupine serverov (napríklad iba v jednom dátovom centre) a otestovať fungovanie tejto funkcionality bez akéhokoľvek osobitného rizika pre celú službu. Aj keď ste niekde urobili vážnu chybu, všetko začalo padať a celé dátové centrum spadlo, balancery presmerujú požiadavky do iných dátových centier. Koncoví používatelia si nič nevšimnú.
Ak si všimnete problém, môžete okamžite vrátiť príznak na jeho predchádzajúcu hodnotu a zmeny budú vrátené späť.
Táto služba má aj svoje nevýhody: vývojári ju veľmi milujú a často sa snažia všetky zmeny pretlačiť do Stop Tap. Snažíme sa bojovať proti zneužívaniu.
Prístup Stop Tap funguje dobre, keď už máte stabilný kód pripravený na zavedenie do produkcie. Zároveň máte stále pochybnosti a chcete skontrolovať kód v „bojových“ podmienkach.
Stop Tap však nie je vhodný na testovanie počas vývoja. Existuje samostatný klaster pre vývojárov nazývaný „tieňový klaster“.
Tajné testovanie: Shadow Cluster
Požiadavky z jedného z klastrov sa duplikujú do tieňového klastra. Ale balancer úplne ignoruje odpovede z tohto klastra. Schéma jeho činnosti je uvedená nižšie.
Získame testovací klaster, ktorý je v skutočných „bojových“ podmienkach. Ide tam bežná prevádzka používateľov. Hardvér v oboch klastroch je rovnaký, takže je možné porovnávať výkon a chyby.
A keďže balancer úplne ignoruje odpovede, koncoví používatelia neuvidia odpovede z tieňového klastra. Preto nie je strašidelné urobiť chybu.
Závery
Ako sme teda vytvorili vyhľadávanie na trhu?
Aby všetko išlo hladko, rozdeľujeme funkčnosť do samostatných služieb. Takto môžeme škálovať len tie komponenty, ktoré potrebujeme, a zjednodušiť komponenty. Je ľahké priradiť samostatný komponent inému tímu a zdieľať zodpovednosť za prácu na ňom. A výrazné úspory železa s týmto prístupom sú zjavným plusom.
Pomáha nám aj tieňový klaster: môžeme vyvíjať služby, testovať ich v procese a nerušiť používateľa.
Samozrejme, testovanie vo výrobe. Potrebujete zmeniť konfiguráciu na tisíckach serverov? Jednoduché, použite Stop Tap. Takto môžete okamžite zaviesť hotové komplexné riešenie a v prípade problémov sa vrátiť k stabilnej verzii.
Dúfam, že sa mi podarilo ukázať, ako robíme trh rýchlym a stabilným so stále rastúcou základňou ponúk. Ako riešime problémy so servermi, riešime veľké množstvo požiadaviek, zlepšujeme flexibilitu služby a robíme to bez prerušenia pracovných procesov.
Zdroj: hab.com