Hvernig Yandex.Markaðsleit virkar og hvað gerist ef einn af netþjónunum bilar

Halló, ég heiti Evgeniy. Ég vinn í Yandex.Market leitarinnviðum. Mig langar að segja Habr samfélaginu frá innra eldhúsi Markaðarins - og ég hef frá mörgu að segja. Í fyrsta lagi hvernig Markaðsleitin virkar, ferlar og arkitektúr. Hvernig bregðumst við við neyðartilvikum: hvað gerist ef einn netþjónn fer niður? Hvað ef það eru 100 slíkir netþjónar?

Þú munt líka læra hvernig við innleiðum nýja virkni á fullt af netþjónum í einu. Og hvernig við prófum flókna þjónustu beint í framleiðslu, án þess að valda notendum óþægindum. Almennt hvernig Markaðsleitin virkar þannig að allir skemmti sér vel.

Smá um okkur: hvaða vandamál við leysum

Þegar þú slærð inn texta, leitar að vöru eftir stikum eða ber saman verð í mismunandi verslunum eru allar beiðnir sendar til leitarþjónustunnar. Leit er stærsta þjónustan á markaðnum.

Við vinnum úr öllum leitarbeiðnum: frá síðunum market.yandex.ru, beru.ru, Supercheck þjónustunni, Yandex.Advisor, farsímaforritum. Við erum einnig með vörutilboð í leitarniðurstöðum á yandex.ru.

Með leitarþjónustu á ég ekki bara við leitina sjálfa heldur einnig gagnagrunn með öllum tilboðum á Markaðnum. Umfangið er þetta: meira en milljarður leitarbeiðna er unnin á dag. Og allt ætti að virka hratt, án truflana og alltaf skila tilætluðum árangri.

Hvað er hvað: Markaðsarkitektúr

Ég mun lýsa stuttlega núverandi arkitektúr markaðarins. Það er hægt að lýsa því í grófum dráttum með skýringarmyndinni hér að neðan:

Segjum að samstarfsverslun komi til okkar. Hann segir að ég vilji selja leikfang: þennan vonda kött með tíst. Og annar reiður köttur án tísts. Og bara köttur. Þá þarf verslunin að útbúa tilboð sem Markaðurinn leitar að. Verslunin býr til sérstakt xml með tilboðum og miðlar leiðinni að þessu xml í gegnum tengiliðaviðmótið. Víxlarinn hleður síðan niður þessu xml reglulega, athugar hvort villur séu og vistar allar upplýsingar í risastóran gagnagrunn.

Það eru til mörg slík vistuð xml. Leitarvísitala er búin til úr þessum gagnagrunni. Vísitalan er geymd á innra sniði. Eftir að hafa búið til vísitöluna hleður Layout þjónustan henni upp á leitarþjóna.

Fyrir vikið birtist reiður köttur með squeaker í gagnagrunninum og vísitala kattarins birtist á þjóninum.

Ég skal segja þér hvernig við leitum að kötti í hlutanum um leitararkitektúr.

Markaðsleitararkitektúr

Við lifum í heimi örþjónustu: hverja beiðni sem berast market.yandex.ru veldur miklum undirfyrirspurnum og tugir þjónustu koma að vinnslu þeirra. Myndin sýnir aðeins nokkrar:

Einfaldað kerfi fyrir vinnslu beiðni

Hver þjónusta hefur dásamlega hluti - sína eigin jafnvægisbúnað með einstöku nafni:

Jafnvægisbúnaðurinn gefur okkur meiri sveigjanleika í stjórnun þjónustunnar: þú getur til dæmis slökkt á netþjónum, sem er oft nauðsynlegt fyrir uppfærslur. Jafnvægismaðurinn sér að þjónninn er ekki tiltækur og vísar beiðnum sjálfkrafa til annarra netþjóna eða gagnavera. Þegar miðlari er bætt við eða fjarlægður er álaginu sjálfkrafa dreift á milli netþjónanna.

Einkvæmt nafn jafnvægisbúnaðarins er ekki háð gagnaverinu. Þegar þjónusta A gerir beiðni til B, þá vísar jafnvægisaðili B sjálfgefið beiðninni til núverandi gagnavers. Ef þjónustan er ekki tiltæk eða er ekki til í núverandi gagnaveri er beiðninni vísað til annarra gagnavera.

Eitt FQDN fyrir allar gagnaver gerir þjónustu A kleift að taka algjörlega frá staðsetningum. Beiðni hans til þjónustu B verður ávallt afgreidd. Undantekningin er tilvikið þegar þjónustan er staðsett í öllum gagnaverum.

En ekki er allt svo bjart með þessum jafnvægisbúnaði: við erum með auka millihluta. Jafnvægisbúnaðurinn gæti verið óstöðugur og þetta vandamál er leyst af óþarfa netþjónum. Það er líka viðbótartöf á milli þjónustu A og B. En í reynd er það minna en 1 ms og fyrir flestar þjónustur er þetta ekki mikilvægt.

Að takast á við hið óvænta: Jöfnun leitarþjónustu og seiglu

Ímyndaðu þér að það sé hrun: þú þarft að finna kött með squeaker, en þjónninn hrynur. Eða 100 netþjóna. Hvernig á að komast út? Ætlum við virkilega að skilja notandann eftir án kattar?

Staðan er skelfileg en við erum tilbúin í það. Ég skal segja þér það í röð.

Leitarinnviðir eru staðsettir í nokkrum gagnaverum:

Við hönnun tökum við möguleika á að leggja niður eina gagnaver. Lífið er fullt af óvart - til dæmis getur gröfa skorið jarðstreng (já, það gerðist). Afkastageta í þeim gagnaverum sem eftir eru ætti að vera nægjanleg til að standast hámarksálag.

Við skulum íhuga eina gagnaver. Hvert gagnaver hefur sama rekstrarkerfi jafnvægisbúnaðar:

Einn jafnvægismaður er að minnsta kosti þrír líkamlegir netþjónar. Þessi offramboð er gerð fyrir áreiðanleika. Balancers keyra á HAProx.

Við völdum HAProx vegna mikillar frammistöðu, lítillar auðlindaþarfa og víðtækrar virkni. Leitarhugbúnaðurinn okkar keyrir inni á hverjum netþjóni.

Líkurnar á að einn þjónn bili eru litlar. En ef þú ert með marga netþjóna aukast líkurnar á að að minnsta kosti einn fari niður.

Þetta er það sem gerist í raun og veru: netþjónar hrynja. Þess vegna er nauðsynlegt að fylgjast stöðugt með stöðu allra netþjóna. Ef þjónninn hættir að svara er hann sjálfkrafa aftengdur umferð. Í þessu skyni hefur HAProxy innbyggt heilsufarsskoðun. Það fer á alla netþjóna einu sinni á sekúndu með HTTP beiðni „/ping“.

Annar eiginleiki HAProxy: Agent-check gerir þér kleift að hlaða alla netþjóna jafnt. Til að gera þetta tengist HAProxy öllum netþjónum og þeir skila þyngd sinni eftir núverandi álagi frá 1 til 100. Þyngdin er reiknuð út frá fjölda beiðna í biðröð fyrir vinnslu og álagi á örgjörva.

Nú um að finna köttinn. Leitarniðurstaðan í beiðnum eins og: /leit?text=reiður+köttur. Til að leitin sé hröð verður allt kattavísitalan að passa inn í vinnsluminni. Jafnvel lestur frá SSD er ekki nógu hraður.

Einu sinni var tilboðsgagnagrunnurinn lítill og vinnsluminni eins netþjóns nægði fyrir það. Eftir því sem tilboðsgrunnurinn stækkaði passaði allt ekki lengur inn í þetta vinnsluminni og gögnunum var skipt í tvo hluta: shard 1 og shard 2.

En þetta gerist alltaf: hvaða lausn, jafnvel góð, veldur öðrum vandamálum.

Balansarinn fór samt á hvaða netþjón sem er. En á vélinni sem beiðnin kom var aðeins helmingur vísitölunnar. Restin var á öðrum netþjónum. Þess vegna þurfti þjónninn að fara í einhverja nálæga vél. Eftir að hafa fengið gögn frá báðum netþjónum voru niðurstöðurnar sameinaðar og endurraðaðar.

Þar sem jafnvægisbúnaðurinn dreifir beiðnum jafnt, tóku allir netþjónar þátt í endurröðun, en ekki bara að senda gögn.

Vandamálið kom upp ef aðliggjandi netþjónn var ekki tiltækur. Lausnin var að tilgreina nokkra netþjóna með mismunandi forgangsröðun sem „nágranna“ netþjón. Fyrst var beiðnin send til netþjónanna í núverandi rekki. Ef ekki var svarað var beiðnin send á alla netþjóna í þessari gagnaver. Og að lokum fór beiðnin til annarra gagnavera.
Eftir því sem tillögum fjölgaði var gögnunum skipt í fjóra hluta. En þetta voru ekki takmörkin.

Eins og er, er uppsetning átta brota notuð. Auk þess, til að spara enn meira minni, var vísitölunni skipt í leitarhluta (sem er notaður til að leita) og brotahluta (sem tekur ekki þátt í leitinni).

Einn netþjónn inniheldur upplýsingar fyrir aðeins eitt brot. Þess vegna, til að leita í heildarvísitölunni, þarftu að leita á átta netþjónum sem innihalda mismunandi brot.

Servers eru flokkaðir í klasa. Hver þyrping inniheldur átta leitarvélar og einn skjalaþjón.

Bútaþjónninn keyrir lykilgilda gagnagrunn með kyrrstæðum gögnum. Þeir eru nauðsynlegir til að gefa út skjöl, til dæmis lýsingu á kötti með tíst. Gögnin eru sérstaklega flutt á sérstakan netþjón til að hlaða ekki minni leitarþjóna.

Þar sem auðkenni skjala eru aðeins einstök innan einni vísitölu gæti komið upp sú staða að engin skjöl eru í bútunum. Jæja, eða að fyrir eitt auðkenni verður annað efni. Til þess að leitin virkaði og niðurstöður skiluðust var því þörf á samræmi yfir allan klasann. Ég skal segja þér hér að neðan hvernig við fylgjumst með samræmi.

Leitin sjálf er byggð upp á eftirfarandi hátt: leitarbeiðni getur komið til hvers kyns af átta netþjónum. Segjum að hann hafi komið á server 1. Þessi server vinnur úr öllum rökum og skilur hvað og hvernig á að leita að. Miðlarinn getur lagt fram viðbótarbeiðnir til ytri þjónustu um nauðsynlegar upplýsingar, allt eftir beiðninni sem berast. Einni beiðni geta fylgt eftir með allt að tíu beiðnum til ytri þjónustu.

Eftir söfnun nauðsynlegra upplýsinga hefst leit í tilboðsgagnagrunninum. Til að gera þetta eru undirfyrirspurnir gerðar á alla átta netþjóna í klasanum.

Þegar svörin hafa borist eru niðurstöðurnar sameinaðar. Að lokum gæti verið þörf á nokkrum fleiri undirfyrirspurnum til blaðaþjónsins til að búa til niðurstöðurnar.

Leitarfyrirspurnir innan klasans líta svona út: /shard1?text=reiður+köttur. Að auki eru undirfyrirspurnir eyðublaðsins stöðugt gerðar á milli allra netþjóna innan klasans einu sinni á sekúndu: /staða.

Beiðni /staða skynjar aðstæður þar sem þjónninn er ekki tiltækur.

Það stjórnar líka að leitarvélaútgáfan og vísitöluútgáfan séu eins á öllum netþjónum, annars verða ósamræmileg gögn innan klasans.

Þrátt fyrir þá staðreynd að einn brotaþjónn vinni beiðnir frá átta leitarvélum er örgjörvi hans mjög létthlaðinn. Þess vegna erum við nú að flytja brotagögnin í sérstaka þjónustu.

Til að flytja gögn kynntum við alhliða lykla fyrir skjöl. Nú er ómögulegt fyrir aðstæður þar sem efni úr öðru skjali er skilað með einum lykli.

En umskipti yfir í annan arkitektúr er ekki lokið ennþá. Núna viljum við losna við sérstaka blaðaþjóninn. Og færa þig svo alveg frá klasabyggingunni. Þetta gerir okkur kleift að halda áfram að stækka auðveldlega. Viðbótarbónus er verulegur járnsparnaður.

Og nú að skelfilegum sögum með hamingjusömum endi. Við skulum íhuga nokkur tilvik þar sem netþjónn er ekki tiltækur.

Eitthvað hræðilegt gerðist: einn þjónn er ekki tiltækur

Segjum að einn þjónn sé ekki tiltækur. Þá geta þeir netþjónar sem eftir eru í þyrpingunni haldið áfram að svara, en leitarniðurstöður verða ófullnægjandi.

Með stöðuathugun /staða nærliggjandi netþjónar skilja að einn er ekki tiltækur. Þess vegna, til að viðhalda heilleika, allir netþjónar í þyrpingunni á beiðni /ping þeir byrja að svara jafnvægismanninum að þeir séu líka ófáanlegir. Það kemur í ljós að allir serverarnir í þyrpingunni dóu (sem er ekki satt). Þetta er helsti galli klasakerfisins okkar - þess vegna viljum við komast í burtu frá því.

Beiðnir sem mistakast með villu eru sendar aftur af jafnvægismanni á öðrum netþjónum.
Jafnvægisbúnaðurinn hættir einnig að senda notendaumferð á dauða netþjóna, en heldur áfram að athuga stöðu þeirra.

Þegar þjónninn verður tiltækur byrjar hann að bregðast við /ping. Um leið og eðlileg svör við pingum frá dauðum netþjónum byrja að berast byrja jafnvægismenn að senda notendaumferð þangað. Klasarekstur er endurreistur, húrra.

Jafnvel verra: margir netþjónar eru ekki tiltækir

Verulegur hluti netþjóna í gagnaverinu er skorinn niður. Hvað á að gera, hvert á að hlaupa? Jafnvægismaðurinn kemur aftur til bjargar. Hver jafnvægismaður geymir stöðugt í minni núverandi fjölda netþjóna í beinni. Það reiknar stöðugt út hámarks umferð sem núverandi gagnaver getur unnið úr.

Þegar margir netþjónar í gagnaveri fara niður, gerir jafnvægismaður sér grein fyrir því að þessi gagnaver getur ekki unnið úr allri umferð.

Þá byrjar umframumferðin að dreifast af handahófi til annarra gagnavera. Allt virkar, allir eru ánægðir.

Hvernig við gerum það: að gefa út útgáfur

Nú skulum við tala um hvernig við birtum breytingar á þjónustunni. Hér höfum við farið leiðina til að einfalda ferla: útgáfa nýrrar útgáfu er nánast algjörlega sjálfvirk.
Þegar ákveðinn fjöldi breytinga safnast saman í verkefninu er ný útgáfa sjálfkrafa búin til og smíði hennar hefst.

Síðan er þjónustan sett í prófun, þar sem stöðugleiki rekstrarins er kannaður.

Á sama tíma er sjálfvirk árangurspróf sett af stað. Sérstök þjónusta sér um þetta. Ég mun ekki tala um það núna - lýsing þess er verðug sérstakrar greinar.

Ef útgáfa í prófun heppnast er sjálfkrafa hafin útgáfa útgáfunnar í prestable. Prestable er sérstakur klasi þar sem venjulegri notendaumferð er beint. Ef það skilar villu sendir jafnvægismaðurinn aftur beiðni til framleiðslu.

Í prestable eru viðbragðstímar mældir og bornir saman við fyrri útgáfu í framleiðslu. Ef allt er í lagi, þá tengir maður: skoðar línurit og niðurstöður álagsprófa og byrjar síðan að rúlla út í framleiðslu.

Allt það besta fer til notandans: A/B prófun

Það er ekki alltaf augljóst hvort breytingar á þjónustu skila raunverulegum ávinningi. Til að mæla gagnsemi breytinga kom fólk með A/B próf. Ég skal segja þér aðeins frá því hvernig það virkar í Yandex.Markaðsleit.

Þetta byrjar allt með því að bæta við nýrri CGI breytu sem gerir nýja virkni kleift. Látum færibreytuna okkar vera: market_new_functionality=1. Síðan virkjum við þessa virkni í kóðanum ef fáninn er til staðar:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

Nýr virkni er tekinn út í framleiðslu.

Til að gera sjálfvirkan A/B prófun er sérstök þjónusta sem veitir nákvæmar upplýsingar lýst hér. Tilraun er búin til í þjónustunni. Umferðarhlutdeild er til dæmis sett 15%. Prósentur eru ekki stilltar fyrir fyrirspurnir heldur notendur. Lengd tilraunarinnar er einnig tilgreind, til dæmis viku.

Hægt er að keyra nokkrar tilraunir samtímis. Í stillingunum er hægt að tilgreina hvort gatnamót við aðrar tilraunir séu mögulegar.

Fyrir vikið bætir þjónustan sjálfkrafa við rökum market_new_functionality=1 til 15% notenda. Það reiknar einnig sjálfkrafa út valda mælikvarða. Eftir að tilrauninni er lokið skoða sérfræðingar niðurstöðurnar og draga ályktanir. Byggt á niðurstöðunum er tekin ákvörðun um að fara í framleiðslu eða hreinsun.

Fín hönd markaðarins: prófun í framleiðslu

Það gerist oft að þú þarft að prófa virkni nýrrar virkni í framleiðslu, en þú ert ekki viss um hvernig hann mun haga sér við „bardaga“ aðstæður undir miklu álagi.

Það er lausn: fána í CGI breytum er ekki aðeins hægt að nota fyrir A/B próf, heldur einnig til að prófa nýja virkni.

Við gerðum tól sem gerir þér kleift að breyta stillingum samstundis á þúsundum netþjóna án þess að útsetja þjónustuna fyrir áhættu. Það heitir Stop Tap. Upprunalega hugmyndin var að geta slökkt fljótt á einhverri virkni án útlits. Þá stækkaði tólið og varð flóknara.

Þjónustuflæðismyndin er sýnd hér að neðan:

Fánagildi eru stillt í gegnum API. Stjórnunarþjónustan geymir þessi gildi í gagnagrunninum. Allir netþjónar fara í gagnagrunninn einu sinni á tíu sekúndna fresti, dæla út fánagildum og nota þessi gildi á hverja beiðni.

Í Stöðva krananum geturðu stillt tvenns konar gildi:

1) Skilyrt orðatiltæki. Notaðu þegar eitt af gildunum er satt. Til dæmis:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

Gildið "3" verður notað þegar beiðnin er afgreidd á stað DC1. Og gildið er „4“ þegar beiðnin er unnin á öðrum þyrpingunni fyrir beru.ru síðuna.

2) Skilyrðislaus gildi. Sæktu sjálfgefið ef ekkert af skilyrðunum er uppfyllt. Til dæmis:

gildi, gildi!

Ef gildi endar með upphrópunarmerki fær það meiri forgang.

CGI færibreytuþáttarinn greinir vefslóðina. Notar síðan gildin frá Stop Tap.

Gildi með eftirfarandi forgangsröðun eru notuð:

1. Með auknum forgangi frá Stop Tap (upphrópunarmerki).
2. Gildið frá beiðninni.
3. Sjálfgefið gildi frá Stop tap.
4. Sjálfgefið gildi í kóða.

Það eru margir fánar sem eru sýndir í skilyrtum gildum - þeir eru nóg fyrir allar aðstæður sem við vitum:

• Gagnaver.
• Umhverfi: framleiðsla, prófun, skuggi.
• Staður: markaður, beru.
• Klasanúmer.

Með þessu tóli geturðu virkjað nýja virkni á ákveðnum hópi netþjóna (til dæmis í aðeins einni gagnaveri) og prófað virkni þessarar virkni án sérstakrar áhættu fyrir alla þjónustuna. Jafnvel þótt þú hafir gert alvarleg mistök einhvers staðar byrjaði allt að falla og allt gagnaverið fór niður, jafnvægismenn munu beina beiðnum til annarra gagnavera. Endir notendur munu ekki taka eftir neinu.

Ef þú tekur eftir vandamáli geturðu strax skilað fánanum í fyrra gildi og breytingarnar verða afturkallaðar.

Þessi þjónusta hefur líka sína galla: verktaki elska hana mjög mikið og reyna oft að ýta öllum breytingum inn í Stop Tap. Við erum að reyna að berjast gegn misnotkun.

Stop Tap nálgunin virkar vel þegar þú ert nú þegar með stöðugan kóða tilbúinn til að fara í framleiðslu. Á sama tíma hefurðu enn efasemdir og þú vilt athuga kóðann við „bardaga“ aðstæður.

Hins vegar er Stop Tap ekki hentugur til að prófa meðan á þróun stendur. Það er sérstakur þyrping fyrir þróunaraðila sem kallast „skuggaþyrping“.

Leyndarpróf: Shadow Cluster

Beiðnir frá einum af þyrpingunum eru afritaðar í skuggaþyrpinguna. En jafnvægismaðurinn hunsar algjörlega svörin frá þessum klasa. Skýringarmyndin af rekstri þess er sýnd hér að neðan.

Við fáum prufuþyrping sem er við raunverulegar „bardaga“ aðstæður. Venjuleg notendaumferð fer þangað. Vélbúnaðurinn í báðum klösunum er sá sami, þannig að hægt er að bera saman árangur og villur.

Og þar sem jafnvægisbúnaðurinn hunsar algjörlega svör munu endanotendur ekki sjá svör frá skuggaþyrpingunni. Þess vegna er ekki skelfilegt að gera mistök.

Niðurstöður

Svo, hvernig byggðum við upp markaðsleitina?

Til að allt gangi snurðulaust fyrir sig, aðskiljum við virkni í aðskilda þjónustu. Þannig getum við skalað aðeins þá íhluti sem við þurfum og gert íhlutina einfaldari. Það er auðvelt að úthluta öðrum teymi sérstakan íhlut og deila ábyrgðinni á því að vinna í honum. Og verulegur sparnaður í járnum með þessari nálgun er augljós plús.

Skuggaþyrpingin hjálpar okkur líka: við getum þróað þjónustu, prófað hana í ferlinu og ekki truflað notandann.

Jæja, próf í framleiðslu, auðvitað. Þarftu að breyta stillingum á þúsundum netþjóna? Auðvelt, notaðu Stop Tap. Þannig er strax hægt að rúlla út tilbúinni flókinni lausn og rúlla aftur í stöðuga útgáfu ef vandamál koma upp.

Ég vona að mér hafi tekist að sýna hvernig við gerum Markaðinn hraðan og stöðugan með sívaxandi grunni tilboða. Hvernig við leysum netþjónavandamál, tökum á gífurlegum fjölda beiðna, bætum sveigjanleika þjónustunnar og gerum þetta án þess að trufla vinnuferla.

Heimild: www.habr.com