Dobrý den, jmenuji se Evgeniy. Pracuji ve vyhledávací infrastruktuře Yandex.Market. Chci říct komunitě Habr o vnitřní kuchyni Marketu – a mám toho hodně co říct. Za prvé, jak funguje Market search, procesy a architektura. Jak řešíme nouzové situace: co se stane, když jeden server vypadne? Co když je takových serverů 100?
Dozvíte se také, jak implementujeme nové funkce na spoustu serverů najednou. A jak testujeme komplexní služby přímo ve výrobě, aniž by to uživatelům způsobovalo nějaké nepříjemnosti. Obecně, jak funguje Market search, aby se všichni dobře bavili.
Něco málo o nás: jaký problém řešíme
Když zadáte text, vyhledáte produkt podle parametrů nebo porovnáte ceny v různých obchodech, všechny požadavky se odešlou vyhledávací službě. Vyhledávání je největší službou na trhu.
Zpracováváme všechny požadavky na vyhledávání: ze stránek market.yandex.ru, beru.ru, služba Supercheck, Yandex.Advisor, mobilní aplikace. Nabídky produktů také zahrnujeme do výsledků vyhledávání na yandex.ru.
Vyhledávací službou myslím nejen samotné vyhledávání, ale také databázi se všemi nabídkami na Marketu. Rozsah je následující: denně se zpracuje více než miliarda požadavků na vyhledávání. A vše by mělo fungovat rychle, bez přerušení a vždy přinášet požadovaný výsledek.
Co je co: Architektura trhu
Stručně popíšu současnou architekturu Marketu. Zhruba to lze popsat následujícím diagramem:
Řekněme, že k nám přijde partnerská prodejna. Říká, že chci prodat hračku: tuhle zlou kočku s pískadlem. A další vzteklý kocour bez prcka. A jen kočka. Poté musí obchod připravit nabídky, které Market vyhledává. Obchod vygeneruje speciální xml s nabídkami a sdělí cestu k tomuto xml přes affiliate rozhraní. Indexer pak pravidelně stahuje tento xml, kontroluje chyby a ukládá všechny informace do obrovské databáze.
Takových uložených xml je mnoho. Z této databáze je vytvořen vyhledávací index. Index je uložen v interním formátu. Po vytvoření indexu jej služba Layout nahraje na vyhledávací servery.
Výsledkem je, že se v databázi objeví rozzlobená kočka s pískáním a na serveru se objeví kočičí index.
V části o architektuře vyhledávání vám řeknu, jak hledáme kočku.
Architektura hledání trhu
Žijeme ve světě mikroslužeb: každý příchozí požadavek způsobuje spoustu poddotazů a na jejich zpracování se podílejí desítky služeb. Diagram ukazuje jen několik:
Zjednodušené schéma zpracování požadavků
Každá služba má úžasnou věc - svůj vlastní balancer s jedinečným názvem:
Balancér nám poskytuje větší flexibilitu při správě služby: můžete například vypnout servery, což je často vyžadováno pro aktualizace. Balancér vidí, že server je nedostupný a automaticky přesměruje požadavky na jiné servery nebo datová centra. Při přidávání nebo odebírání serveru se zátěž automaticky přerozděluje mezi servery.
Jedinečný název balanceru nezávisí na datovém centru. Když služba A odešle požadavek na B, pak ve výchozím nastavení balancer B přesměruje požadavek do aktuálního datového centra. Pokud je služba nedostupná nebo v aktuálním datovém centru neexistuje, je požadavek přesměrován do jiných datových center.
Jediný FQDN pro všechna datová centra umožňuje službě A zcela abstrahovat od míst. Jeho požadavek na službu B bude vždy zpracován. Výjimkou je případ, kdy je služba umístěna ve všech datových centrech.
Ale s tímto balancérem není všechno tak růžové: máme další mezisložku. Balancér může být nestabilní a tento problém řeší redundantní servery. Mezi službami A a B je také další zpoždění. V praxi je to však méně než 1 ms a pro většinu služeb to není kritické.
Jak se vypořádat s neočekávaným: Vyvážení a odolnost vyhledávací služby
Představte si, že došlo ke kolapsu: potřebujete najít kočku s pískadlem, ale server se zhroutí. Nebo 100 serverů. Jak se dostat ven? Opravdu necháme uživatele bez kočky?
Situace je děsivá, ale jsme na ni připraveni. Řeknu vám to popořadě.
Vyhledávací infrastruktura se nachází v několika datových centrech:
Při návrhu počítáme s možností odstavení jednoho datového centra. Život je plný překvapení – například bagr dokáže přeříznout podzemní kabel (ano, stalo se). Kapacita ve zbývajících datových centrech by měla být dostatečná, aby vydržela špičkovou zátěž.
Uvažujme o jediném datovém centru. Každé datové centrum má stejné provozní schéma balanceru:
Jeden balancer jsou alespoň tři fyzické servery. Tato redundance je vytvořena pro spolehlivost. Balancery běží na HAProx.
HAProx jsme si vybrali kvůli jeho vysokému výkonu, nízkým nárokům na zdroje a široké funkčnosti. Náš vyhledávací software běží na každém serveru.
Pravděpodobnost selhání jednoho serveru je nízká. Ale pokud máte mnoho serverů, zvyšuje se pravděpodobnost, že alespoň jeden vypadne.
To je to, co se děje ve skutečnosti: servery se zhroutí. Proto je nutné neustále sledovat stav všech serverů. Pokud server přestane reagovat, je automaticky odpojen od provozu. Pro tento účel má HAProxy vestavěnou kontrolu stavu. Jde na všechny servery jednou za sekundu s HTTP požadavkem „/ping“.
Další funkce HAProxy: agent-check vám umožňuje načíst všechny servery rovnoměrně. K tomu se HAProxy připojí ke všem serverům a ty vracejí svou váhu v závislosti na aktuální zátěži od 1 do 100. Váha se počítá na základě počtu požadavků ve frontě na zpracování a zátěže procesoru.
Nyní o hledání kočky. Výsledkem vyhledávání jsou požadavky jako: /hledat?text=rozzlobený+kočka. Aby bylo vyhledávání rychlé, musí se celý index kočky vejít do paměti RAM. Ani čtení z SSD není dostatečně rychlé.
Kdysi byla databáze nabídek malá a RAM jednoho serveru jí stačila. Jak rostla nabídková základna, do této RAM se již vše nevešlo a data byla rozdělena na dvě části: shard 1 a shard 2.
Ale to se děje vždy: každé řešení, i dobré, vyvolává další problémy.
Balancér stále šel na jakýkoli server. Ale na stroji, kam požadavek přišel, byla jen polovina indexu. Zbytek byl na jiných serverech. Server proto musel přejít na nějaký sousední stroj. Po obdržení dat z obou serverů byly výsledky sloučeny a přehodnoceny.
Vzhledem k tomu, že balancer rozděluje požadavky rovnoměrně, všechny servery se zabývaly přehodnocením, nikoli pouze odesíláním dat.
Problém nastal, pokud byl sousední server nedostupný. Řešením bylo specifikovat několik serverů s různými prioritami jako „sousední“ server. Nejprve byl požadavek odeslán na servery v aktuálním racku. Pokud nepřišla žádná odpověď, byl požadavek odeslán všem serverům v tomto datovém centru. A nakonec požadavek šel do dalších datových center.
S rostoucím počtem návrhů byla data rozdělena do čtyř částí. Ale to nebyl limit.
V současné době se používá konfigurace osmi střepů. Pro ještě větší úsporu paměti byl navíc rejstřík rozdělen na vyhledávací část (která slouží k vyhledávání) a úryvkovou část (která se vyhledávání neúčastní).
Jeden server obsahuje informace pouze pro jeden fragment. Chcete-li tedy prohledat celý index, musíte hledat na osmi serverech obsahujících různé fragmenty.
Servery jsou seskupeny do clusterů. Každý cluster obsahuje osm vyhledávačů a jeden snippet server.
Server fragmentů provozuje databázi klíč–hodnota se statickými daty. Jsou potřeba k vydání dokladů, například popisu kočky s pískadlem. Data jsou speciálně přenášena na samostatný server, aby nezatěžovala paměť vyhledávacích serverů.
Protože ID dokumentů jsou jedinečná pouze v rámci jednoho indexu, může nastat situace, kdy ve úryvcích nebudou žádné dokumenty. No, nebo že na jedno ID bude jiný obsah. Proto, aby vyhledávání fungovalo a výsledky se vracely, byla potřeba konzistence napříč celým clusterem. Níže vám řeknu, jak sledujeme konzistenci.
Samotné vyhledávání je strukturováno následovně: požadavek na vyhledávání může přijít na kterýkoli z osmi serverů. Řekněme, že přišel na server 1. Tento server zpracovává všechny argumenty a rozumí tomu, co a jak hledat. V závislosti na příchozím požadavku může server zadávat externím službám další požadavky na potřebné informace. Po jednom požadavku může následovat až deset požadavků na externí služby.
Po shromáždění potřebných informací začne vyhledávání v databázi nabídek. K tomu jsou provedeny poddotazy na všech osm serverů v clusteru.
Po obdržení odpovědí se výsledky spojí. Ke generování výsledků může být nakonec potřeba několik dalších dílčích dotazů na server fragmentů.
Vyhledávací dotazy v rámci clusteru vypadají takto: /shard1?text=rozzlobený+kočka. Kromě toho se mezi všemi servery v clusteru neustále jednou za sekundu provádějí dílčí dotazy formuláře: /postavení.
Dotaz /postavení detekuje situaci, kdy server není dostupný.
Kontroluje také, že verze vyhledávače a verze indexu jsou na všech serverech stejné, jinak budou v clusteru nekonzistentní data.
Navzdory tomu, že jeden snippet server zpracovává požadavky od osmi vyhledávačů, je jeho procesor velmi málo zatížen. Proto nyní převádíme údaje o úryvku do samostatné služby.
Pro přenos dat jsme zavedli univerzální klíče pro dokumenty. Nyní je nemožné pro situaci, kdy je obsah z jiného dokumentu vrácen pomocí jednoho klíče.
Přechod na jinou architekturu ale ještě není dokončen. Nyní se chceme zbavit vyhrazeného úryvkového serveru. A pak se úplně vzdálit od klastrové struktury. To nám umožní pokračovat ve snadném škálování. Bonusem navíc je výrazná úspora železa.
A teď k děsivým příběhům se šťastným koncem. Podívejme se na několik případů nedostupnosti serveru.
Stalo se něco hrozného: jeden server je nedostupný
Řekněme, že jeden server je nedostupný. Poté mohou zbývající servery v clusteru nadále odpovídat, ale výsledky hledání budou neúplné.
Prostřednictvím kontroly stavu /postavení sousední servery chápou, že jeden není dostupný. Proto, aby byla zachována úplnost, všechny servery v clusteru na požadavek /ping začnou odpovídat balanceru, že jsou také nedostupní. Ukázalo se, že všechny servery v clusteru zemřely (což není pravda). To je hlavní nevýhoda našeho klastrového schématu – proto se od něj chceme dostat.
Požadavky, které selžou s chybou, jsou balancérem odeslány znovu na jiné servery.
Balancér také přestane odesílat uživatelský provoz na mrtvé servery, ale nadále kontroluje jejich stav.
Když je server dostupný, začne odpovídat /ping. Jakmile začnou přicházet normální odpovědi na ping z mrtvých serverů, balancéry tam začnou posílat uživatelský provoz. Provoz clusteru je obnoven, hurá.
Ještě horší: mnoho serverů je nedostupných
Významná část serverů v datovém centru je vyřazena. Co dělat, kam utéct? Na pomoc opět přichází balancer. Každý balancer neustále ukládá do paměti aktuální počet živých serverů. Neustále vypočítává maximální objem provozu, který může aktuální datové centrum zpracovat.
Když dojde k výpadku mnoha serverů v datovém centru, balancer si uvědomí, že toto datové centrum nemůže zpracovat veškerý provoz.
Poté se přebytečný provoz začne náhodně distribuovat do dalších datových center. Všechno funguje, všichni jsou spokojeni.
Jak to děláme: vydávání vydání
Nyní si promluvme o tom, jak zveřejňujeme změny provedené ve službě. Zde jsme se vydali cestou zjednodušování procesů: zavádění nové verze je téměř zcela automatizované.
Když se v projektu nashromáždí určitý počet změn, automaticky se vytvoří nové vydání a spustí se jeho sestavování.
Poté je služba spuštěna k testování, kde se kontroluje stabilita provozu.
Zároveň je spuštěno automatické testování výkonu. To řeší speciální služba. Nebudu o tom nyní mluvit - jeho popis si zaslouží samostatný článek.
Pokud je publikace v testování úspěšná, publikace vydání v prestable se automaticky spustí. Prestable je speciální cluster, kam směřuje běžný uživatelský provoz. Pokud vrátí chybu, vyvažovačka znovu požádá o výrobu.
V prestable se měří časy odezvy a porovnávají se s předchozí verzí ve výrobě. Pokud je vše v pořádku, pak se člověk připojí: zkontroluje grafy a výsledky zátěžových testů a pak se začne rozjíždět do výroby.
Vše nejlepší patří uživateli: A/B testování
Není vždy zřejmé, zda změny služby přinesou skutečné výhody. Pro měření užitečnosti změn lidé přišli s A/B testováním. Řeknu vám něco o tom, jak to funguje ve vyhledávání Yandex.Market.
Vše začíná přidáním nového parametru CGI, který umožňuje nové funkce. Nechť je náš parametr: market_new_functionality=1. Pak v kódu povolíme tuto funkci, pokud je přítomen příznak:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Do výroby se zavádí nová funkce.
Pro automatizaci A/B testování existuje specializovaná služba, která poskytuje podrobné informace . Ve službě je vytvořen experiment. Podíl návštěvnosti je stanoven např. 15 %. Procenta nejsou nastavena pro dotazy, ale pro uživatele. Udává se také doba trvání experimentu, například týden.
Několik experimentů může být spuštěno současně. V nastavení můžete určit, zda je možné průnik s jinými experimenty.
V důsledku toho služba automaticky přidá argument market_new_functionality=1 na 15 % uživatelů. Také automaticky vypočítá vybrané metriky. Po dokončení experimentu se analytici podívají na výsledky a vyvodí závěry. Na základě zjištění je učiněno rozhodnutí o zavedení do výroby nebo zdokonalování.
Šikovná ruka trhu: testování ve výrobě
Často se stává, že potřebujete otestovat fungování nové funkcionality ve výrobě, ale nejste si jisti, jak se bude chovat v „bojových“ podmínkách při velkém zatížení.
Existuje řešení: příznaky v CGI parametrech lze použít nejen pro A/B testování, ale také pro testování nových funkcí.
Vytvořili jsme nástroj, který vám umožní okamžitě změnit konfiguraci na tisících serverů, aniž byste službu vystavili rizikům. Říká se tomu „Stop Tap“. Původní myšlenkou bylo umět rychle deaktivovat některé funkce bez rozvržení. Poté se nástroj rozšířil a stal se složitějším.
Schéma toku služeb je uvedeno níže:
Hodnoty příznaků se nastavují přes API. Služba správy ukládá tyto hodnoty do databáze. Všechny servery přejdou do databáze každých deset sekund, vypumpují hodnoty příznaků a použijí tyto hodnoty na každý požadavek.
V klepnutí Stop můžete nastavit dva typy hodnot:
1) Podmíněné výrazy. Použijte, když je jedna z hodnot pravdivá. Například:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Hodnota "3" bude použita při zpracování požadavku v umístění DC1. A hodnota je „4“, když je požadavek zpracován na druhém clusteru pro web beru.ru.
2) Bezpodmínečné hodnoty. Použít ve výchozím nastavení, pokud není splněna žádná z podmínek. Například:
hodnota, hodnota!
Pokud hodnota končí vykřičníkem, má vyšší prioritu.
Analyzátor parametrů CGI analyzuje adresu URL. Poté použije hodnoty z Stop Tap.
Použijí se hodnoty s následujícími prioritami:
- Se zvýšenou prioritou od Stop Tap (vykřičník).
- Hodnota z požadavku.
- Výchozí hodnota z kohoutku Stop.
- Výchozí hodnota v kódu.
Existuje mnoho příznaků, které jsou uvedeny v podmíněných hodnotách - stačí pro všechny nám známé scénáře:
- Datové centrum.
- Prostředí: výroba, testování, stín.
- Místo konání: market, beru.
- Číslo clusteru.
Pomocí tohoto nástroje můžete povolit novou funkcionalitu na určité skupině serverů (například pouze v jednom datovém centru) a vyzkoušet fungování této funkcionality bez jakéhokoli zvláštního rizika pro celou službu. I když jste někde udělali závažnou chybu, vše začalo padat a celé datové centrum spadlo, balancery budou přesměrovávat požadavky do jiných datových center. Koncoví uživatelé si ničeho nevšimnou.
Pokud zaznamenáte problém, můžete okamžitě vrátit příznak na jeho předchozí hodnotu a změny budou vráceny zpět.
Tato služba má i své stinné stránky: vývojáři ji velmi milují a často se snaží všechny změny protlačit do Stop Tap. Snažíme se bojovat proti zneužívání.
Přístup Stop Tap funguje dobře, když již máte stabilní kód připravený k zavedení do produkce. Zároveň máte stále pochybnosti a chcete kód zkontrolovat v „bojových“ podmínkách.
Stop Tap však není vhodný pro testování během vývoje. Existuje samostatný cluster pro vývojáře nazvaný „shluk stínů“.
Tajné testování: Shadow Cluster
Požadavky z jednoho z clusterů jsou duplikovány do stínového clusteru. Ale balancer zcela ignoruje odpovědi z tohoto clusteru. Schéma jeho fungování je uvedeno níže.
Získáme testovací cluster, který je v reálných „bojových“ podmínkách. Jde tam běžný uživatelský provoz. Hardware v obou clusterech je stejný, takže lze porovnávat výkon a chyby.
A protože balancer zcela ignoruje odpovědi, koncoví uživatelé neuvidí odpovědi ze stínového clusteru. Proto není děsivé udělat chybu.
Závěry
Jak jsme tedy vytvořili Market Search?
Aby vše šlo hladce, rozdělujeme funkčnost do samostatných služeb. Tímto způsobem můžeme škálovat pouze ty komponenty, které potřebujeme, a zjednodušit komponenty. Je snadné přiřadit samostatnou komponentu jinému týmu a sdílet odpovědnost za práci na ní. A výrazné úspory železa s tímto přístupem jsou zřejmé plus.
Stínový cluster nám také pomáhá: můžeme vyvíjet služby, testovat je v procesu a nerušit uživatele.
No, testování ve výrobě, samozřejmě. Potřebujete změnit konfiguraci na tisících serverů? Snadno, použijte Stop Tap. Tímto způsobem můžete okamžitě zavést hotové komplexní řešení a v případě problémů se vrátit zpět ke stabilní verzi.
Doufám, že se mi podařilo ukázat, jak děláme trh rychlý a stabilní se stále rostoucí základnou nabídek. Jak řešíme problémy se serverem, řešíme obrovské množství požadavků, zlepšujeme flexibilitu služby a děláme to bez přerušení pracovních procesů.
Zdroj: www.habr.com