Halo, jina langu ni Evgeniy. Ninafanya kazi katika miundombinu ya utafutaji ya Yandex.Market. Ninataka kuiambia jumuiya ya Habr kuhusu jikoni la ndani la Soko - na nina mengi ya kuwaambia. Kwanza kabisa, jinsi Utafutaji wa Soko unavyofanya kazi, michakato na usanifu. Je, tunakabiliana vipi na hali za dharura: nini kinatokea ikiwa seva moja itashuka? Je, ikiwa kuna seva 100 kama hizo?
Pia utajifunza jinsi tunavyotekeleza utendakazi mpya kwenye rundo la seva mara moja. Na jinsi tunavyojaribu huduma changamano moja kwa moja katika uzalishaji, bila kusababisha usumbufu wowote kwa watumiaji. Kwa ujumla, jinsi Utafutaji wa Soko unavyofanya kazi ili kila mtu awe na wakati mzuri.
Kidogo kuhusu sisi: ni shida gani tunatatua
Unapoingiza maandishi, tafuta bidhaa kwa vigezo, au kulinganisha bei katika maduka tofauti, maombi yote yanatumwa kwa huduma ya utafutaji. Utafutaji ni huduma kubwa zaidi katika Soko.
Tunashughulikia maombi yote ya utafutaji: kutoka kwa tovuti market.yandex.ru, beru.ru, huduma ya Supercheck, Yandex.Advisor, maombi ya simu. Pia tunajumuisha matoleo ya bidhaa katika matokeo ya utafutaji kwenye yandex.ru.
Kwa huduma ya utafutaji simaanishi tu utafutaji yenyewe, lakini pia hifadhidata yenye matoleo yote kwenye Soko. Kiwango ni hiki: zaidi ya maombi bilioni ya utafutaji huchakatwa kwa siku. Na kila kitu kinapaswa kufanya kazi haraka, bila usumbufu na daima kutoa matokeo yaliyohitajika.
Je! ni nini: Usanifu wa soko
Nitaelezea kwa ufupi usanifu wa sasa wa Soko. Inaweza kuelezewa takriban na mchoro hapa chini:
Wacha tuseme duka la washirika linakuja kwetu. Anasema nataka kuuza toy: paka hii mbaya na squeaker. Na paka mwingine mwenye hasira bila squeaker. Na paka tu. Kisha duka linahitaji kuandaa matoleo ambayo Soko hutafuta. Duka hutengeneza xml maalum yenye matoleo na huwasilisha njia ya xml hii kupitia kiolesura cha washirika. Kisha faharasa hupakua xml hii mara kwa mara, hukagua makosa na huhifadhi taarifa zote kwenye hifadhidata kubwa.
Kuna xm nyingi kama hizi zilizohifadhiwa. Faharasa ya utafutaji imeundwa kutoka kwa hifadhidata hii. Faharasa imehifadhiwa katika umbizo la ndani. Baada ya kuunda faharisi, huduma ya Mpangilio huipakia kwenye seva za utafutaji.
Kama matokeo, paka yenye hasira na squeaker inaonekana kwenye hifadhidata, na index ya paka inaonekana kwenye seva.
Nitakuambia jinsi tunavyotafuta paka katika sehemu kuhusu usanifu wa utafutaji.
Usanifu wa utafutaji wa soko
Tunaishi katika ulimwengu wa huduma ndogo: kila ombi linaloingia husababisha subqueries nyingi, na huduma kadhaa zinahusika katika usindikaji wao. Mchoro unaonyesha chache tu:
Mpango rahisi wa kuchakata ombi
Kila huduma ina jambo la ajabu - usawa wake mwenyewe na jina la kipekee:
Sawazisha inatupa kubadilika zaidi katika kudhibiti huduma: unaweza, kwa mfano, kuzima seva, ambayo mara nyingi inahitajika kwa sasisho. Msawazishaji huona kuwa seva haipatikani na huelekeza maombi upya kiotomatiki kwa seva zingine au vituo vya data. Wakati wa kuongeza au kuondoa seva, mzigo unasambazwa kiotomatiki kati ya seva.
Jina la kipekee la kusawazisha halitegemei kituo cha data. Huduma A inapotuma ombi kwa B, basi kwa kiweka usawazishaji chaguo-msingi B huelekeza ombi kwenye kituo cha sasa cha data. Ikiwa huduma haipatikani au haipo katika kituo cha data cha sasa, basi ombi linaelekezwa kwenye vituo vingine vya data.
FQDN moja ya vituo vyote vya data huruhusu huduma A kujitolea kabisa kutoka kwa maeneo. Ombi lake la huduma B litashughulikiwa kila wakati. Isipokuwa ni kesi wakati huduma iko katika vituo vyote vya data.
Lakini sio kila kitu kinafaa sana na usawazishaji huu: tunayo sehemu ya ziada ya kati. Kisawazisha kinaweza kutokuwa thabiti, na shida hii inatatuliwa na seva zisizo na kazi. Pia kuna ucheleweshaji wa ziada kati ya huduma A na B. Lakini katika mazoezi ni chini ya 1 ms na kwa huduma nyingi hii sio muhimu.
Kushughulika na Yasiyotarajiwa: Usawazishaji wa Huduma ya Utafutaji na Uthabiti
Fikiria kuwa kuna kuanguka: unahitaji kupata paka na squeaker, lakini seva huanguka. Au seva 100. Jinsi ya kutoka? Kweli tutamwacha mtumiaji bila paka?
Hali inatisha, lakini tuko tayari kwa hilo. Nitakuambia kwa utaratibu.
Miundombinu ya utafutaji iko katika vituo kadhaa vya data:
Wakati wa kuunda, tunajumuisha uwezekano wa kuzima kituo kimoja cha data. Maisha ni kamili ya mshangao - kwa mfano, mchimbaji anaweza kukata cable chini ya ardhi (ndiyo, hiyo ilitokea). Uwezo katika vituo vya data vilivyobaki unapaswa kutosha kuhimili mzigo mkubwa.
Hebu fikiria kituo kimoja cha data. Kila kituo cha data kina mpango sawa wa uendeshaji wa mizani:
Sawazisha moja ni angalau seva tatu za kimwili. Upungufu huu unafanywa kwa kuaminika. Visawazishaji huendesha kwenye HAProx.
Tulichagua HAProx kutokana na utendaji wake wa juu, mahitaji ya chini ya rasilimali na utendakazi mpana. Programu yetu ya utafutaji inaendesha ndani ya kila seva.
Uwezekano wa seva moja kushindwa ni mdogo. Lakini ikiwa una seva nyingi, uwezekano kwamba angalau moja itashuka huongezeka.
Hiki ndicho kinachotokea katika hali halisi: seva huanguka. Kwa hiyo, ni muhimu kufuatilia daima hali ya seva zote. Seva ikiacha kujibu, itakatwa kiotomatiki kutoka kwa trafiki. Kwa kusudi hili, HAProxy ina ukaguzi wa afya uliojumuishwa. Inaenda kwa seva zote mara moja kwa sekunde na ombi la HTTP "/ping".
Kipengele kingine cha HAProxy: ukaguzi wa wakala hukuruhusu kupakia seva zote kwa usawa. Kwa kufanya hivyo, HAProxy inaunganisha kwa seva zote, na zinarudi uzito wao kulingana na mzigo wa sasa kutoka 1 hadi 100. Uzito huhesabiwa kulingana na idadi ya maombi katika foleni ya usindikaji na mzigo kwenye processor.
Sasa kuhusu kutafuta paka. Matokeo ya utafutaji katika maombi kama vile: /search?text=hasira+paka. Ili utafutaji uwe wa haraka, faharasa nzima ya paka lazima ilingane na RAM. Hata kusoma kutoka kwa SSD sio haraka vya kutosha.
Mara moja kwa wakati, hifadhidata ya toleo ilikuwa ndogo, na RAM ya seva moja ilikuwa ya kutosha kwake. Kadiri msingi wa ofa ulivyokua, kila kitu hakiingii tena kwenye RAM hii, na data iligawanywa katika sehemu mbili: shard 1 na shard 2.
Lakini hii hufanyika kila wakati: suluhisho lolote, hata nzuri, husababisha shida zingine.
Msawazishaji bado alienda kwa seva yoyote. Lakini kwenye mashine ambapo ombi lilikuja, kulikuwa na nusu tu ya index. Zingine zilikuwa kwenye seva zingine. Kwa hivyo, seva ililazimika kwenda kwa mashine ya jirani. Baada ya kupokea data kutoka kwa seva zote mbili, matokeo yaliunganishwa na kubadilishwa tena.
Kwa kuwa msawazishaji husambaza maombi kwa usawa, seva zote zilihusika katika kupanga upya, na sio kutuma data tu.
Tatizo lilitokea ikiwa seva ya jirani haikupatikana. Suluhisho lilikuwa kutaja seva kadhaa zilizo na vipaumbele tofauti kama seva ya "jirani". Kwanza, ombi lilitumwa kwa seva kwenye rack ya sasa. Ikiwa hakukuwa na jibu, ombi lilitumwa kwa seva zote katika kituo hiki cha data. Na mwishowe, ombi lilienda kwa vituo vingine vya data.
Kadiri idadi ya mapendekezo inavyoongezeka, data iligawanywa katika sehemu nne. Lakini hii haikuwa kikomo.
Hivi sasa, usanidi wa shards nane hutumiwa. Kwa kuongeza, ili kuhifadhi kumbukumbu zaidi, index iligawanywa katika sehemu ya utafutaji (ambayo hutumiwa kutafuta) na sehemu ya snippet (ambayo haishiriki katika utafutaji).
Seva moja ina habari kwa shard moja tu. Kwa hiyo, ili kutafuta index kamili, unahitaji kutafuta kwenye seva nane zilizo na shards tofauti.
Seva zimepangwa katika makundi. Kila kundi lina injini nane za utafutaji na seva moja ya vijisehemu.
Seva ya vijisehemu huendesha hifadhidata ya thamani-msingi iliyo na data tuli. Wanahitajika kutoa hati, kwa mfano, maelezo ya paka na squeaker. Data huhamishiwa maalum kwa seva tofauti ili usipakie kumbukumbu ya seva za utafutaji.
Kwa kuwa vitambulisho vya hati ni vya kipekee ndani ya faharasa moja pekee, hali inaweza kutokea ambapo hakuna hati katika vijisehemu. Naam, au kwamba kwa ID moja kutakuwa na maudhui tofauti. Kwa hivyo, ili utafutaji ufanye kazi na matokeo kurejeshwa, kulikuwa na haja ya uthabiti katika nguzo nzima. Nitakuambia hapa chini jinsi tunavyofuatilia uthabiti.
Utafutaji wenyewe umeundwa kama ifuatavyo: ombi la utafutaji linaweza kuja kwa seva yoyote kati ya nane. Wacha tuseme alikuja kwa seva 1. Seva hii inashughulikia hoja zote na inaelewa nini na jinsi ya kutafuta. Kulingana na ombi linaloingia, seva inaweza kufanya maombi ya ziada kwa huduma za nje kwa habari muhimu. Ombi moja linaweza kufuatiwa na hadi maombi kumi kwa huduma za nje.
Baada ya kukusanya taarifa muhimu, utafutaji huanza kwenye hifadhidata ya toleo. Ili kufanya hivyo, subqueries hufanywa kwa seva zote nane kwenye nguzo.
Mara tu majibu yamepokelewa, matokeo yanajumuishwa. Mwishowe, maswali machache zaidi kwa seva ya vijisehemu yanaweza kuhitajika ili kutoa matokeo.
Maswali ya utafutaji ndani ya nguzo yanaonekana kama: /shard1?text=hasira+paka. Kwa kuongezea, maswali madogo ya fomu hufanywa kila mara kati ya seva zote ndani ya nguzo mara moja kwa sekunde: /hali.
Omba /hali hutambua hali ambapo seva haipatikani.
Pia hudhibiti kwamba toleo la injini ya utafutaji na toleo la faharasa ni sawa kwenye seva zote, vinginevyo kutakuwa na data isiyolingana ndani ya nguzo.
Licha ya ukweli kwamba seva moja ya vijisehemu huchakata maombi kutoka kwa injini nane za utaftaji, kichakataji chake kimejaa kidogo sana. Kwa hivyo, sasa tunahamisha data ya kijisehemu kwa huduma tofauti.
Ili kuhamisha data, tulianzisha funguo zima za hati. Sasa haiwezekani kwa hali ambapo maudhui kutoka kwa hati nyingine yanarejeshwa kwa kutumia ufunguo mmoja.
Lakini mpito kwa usanifu mwingine bado haujakamilika. Sasa tunataka kuondoa seva iliyojitolea ya kijisehemu. Na kisha uondoke kutoka kwa muundo wa nguzo kabisa. Hii itaturuhusu kuendelea kuongeza kiwango kwa urahisi. Bonasi ya ziada ni akiba kubwa ya chuma.
Na sasa kwa hadithi za kutisha na miisho ya furaha. Hebu tuchunguze matukio kadhaa ya kutopatikana kwa seva.
Kitu kibaya kilitokea: seva moja haipatikani
Hebu tuseme seva moja haipatikani. Kisha seva zilizosalia kwenye kundi zinaweza kuendelea kujibu, lakini matokeo ya utafutaji yatakuwa hayajakamilika.
Kupitia kuangalia hali /hali seva za jirani zinaelewa kuwa moja haipatikani. Kwa hivyo, ili kudumisha ukamilifu, seva zote kwenye nguzo kwa ombi /ping wanaanza kumjibu msawazishaji kuwa nao hawapatikani. Inabadilika kuwa seva zote kwenye nguzo zilikufa (ambayo sio kweli). Hili ndilo tatizo kuu la mpango wetu wa nguzo - ndiyo sababu tunataka kujiepusha nayo.
Maombi ambayo hayakufaulu kwa hitilafu hutumwa tena na msawazishaji kwenye seva zingine.
Msawazishaji pia huacha kutuma trafiki ya watumiaji kwa seva zilizokufa, lakini inaendelea kuangalia hali yao.
Wakati seva inapatikana, inaanza kujibu /ping. Mara tu majibu ya kawaida kwa pings kutoka kwa seva zilizokufa huanza kuwasili, wasawazishaji huanza kutuma trafiki ya watumiaji huko. Operesheni ya nguzo imerejeshwa, haraka.
Mbaya zaidi: seva nyingi hazipatikani
Sehemu kubwa ya seva katika kituo cha data hukatwa. Nini cha kufanya, wapi kukimbia? Msawazishaji anakuja kuwaokoa tena. Kila salio huhifadhi kila wakati kwenye kumbukumbu nambari ya sasa ya seva za moja kwa moja. Inahesabu mara kwa mara kiwango cha juu cha trafiki ambacho kituo cha data cha sasa kinaweza kusindika.
Wakati seva nyingi katika kituo cha data zinashuka, msawazishaji anatambua kuwa kituo hiki cha data hakiwezi kuchakata trafiki yote.
Kisha trafiki ya ziada huanza kusambazwa kwa nasibu kwa vituo vingine vya data. Kila kitu kinafanya kazi, kila mtu anafurahi.
Jinsi tunavyofanya: uchapishaji wa matoleo
Sasa hebu tuzungumze kuhusu jinsi tunavyochapisha mabadiliko yaliyofanywa kwenye huduma. Hapa tumechukua njia ya kurahisisha michakato: uchapishaji wa toleo jipya karibu umejiendesha kiotomatiki.
Wakati idadi fulani ya mabadiliko yanakusanywa katika mradi, toleo jipya linaundwa kiotomatiki na muundo wake huanza.
Kisha huduma inatolewa kwa kupima, ambapo utulivu wa operesheni huangaliwa.
Wakati huo huo, upimaji wa utendaji wa moja kwa moja unazinduliwa. Hii inashughulikiwa na huduma maalum. Sitazungumza juu yake sasa - maelezo yake yanastahili nakala tofauti.
Iwapo uchapishaji katika majaribio utafaulu, uchapishaji wa toleo katika muundo unaotegemewa utaanza kiotomatiki. Prestable ni nguzo maalum ambapo trafiki ya kawaida ya mtumiaji inaelekezwa. Ikirudisha hitilafu, msawazishaji atatoa ombi tena kwa uzalishaji.
Katika inayoweza kubadilika, nyakati za majibu hupimwa na kulinganishwa na toleo la awali katika toleo la umma. Ikiwa kila kitu ni sawa, basi mtu huunganisha: huangalia grafu na matokeo ya kupima mzigo na kisha kuanza kusambaza kwa uzalishaji.
Kila la heri huenda kwa mtumiaji: Jaribio la A/B
Sio wazi kila wakati ikiwa mabadiliko kwenye huduma yataleta manufaa halisi. Ili kupima manufaa ya mabadiliko, watu walikuja na majaribio ya A/B. Nitakuambia kidogo jinsi inavyofanya kazi katika utafutaji wa Yandex.Market.
Yote huanza kwa kuongeza kigezo kipya cha CGI kinachowezesha utendakazi mpya. Hebu parameter yetu iwe: soko_utendaji_mpya=1. Kisha katika msimbo tunawezesha utendakazi huu ikiwa bendera iko:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Utendaji mpya unatolewa kwa uzalishaji.
Ili kufanya majaribio ya A/B kiotomatiki, kuna huduma maalum ambayo hutoa maelezo ya kina . Jaribio linaundwa katika huduma. Sehemu ya trafiki imewekwa, kwa mfano, 15%. Asilimia hazijawekwa kwa maswali, lakini kwa watumiaji. Muda wa jaribio pia unaonyeshwa, kwa mfano, wiki.
Majaribio kadhaa yanaweza kuendeshwa kwa wakati mmoja. Katika mipangilio unaweza kubainisha ikiwa makutano na majaribio mengine yanawezekana.
Matokeo yake, huduma huongeza moja kwa moja hoja soko_utendaji_mpya=1 hadi 15% ya watumiaji. Pia hukokotoa kiotomatiki vipimo vilivyochaguliwa. Baada ya jaribio kukamilika, wachambuzi wanaangalia matokeo na kufikia hitimisho. Kulingana na matokeo, uamuzi unafanywa ili kusambaza uzalishaji au uboreshaji.
Mkono wa deft wa Soko: upimaji katika uzalishaji
Mara nyingi hutokea kwamba unahitaji kupima uendeshaji wa utendaji mpya katika uzalishaji, lakini huna uhakika jinsi itakavyofanya katika hali ya "kupambana" chini ya mzigo mkubwa.
Kuna suluhisho: bendera katika vigezo vya CGI zinaweza kutumika sio tu kwa upimaji wa A / B, lakini pia kupima utendaji mpya.
Tumeunda zana inayokuruhusu kubadilisha usanidi papo hapo kwenye maelfu ya seva bila kuangazia huduma kwenye hatari. Inaitwa Stop Tap. Wazo la asili lilikuwa kuweza kuzima utendakazi kwa haraka bila mpangilio. Kisha chombo kilipanuka na kuwa ngumu zaidi.
Mchoro wa mtiririko wa huduma umewasilishwa hapa chini:
Maadili ya alama huwekwa kupitia API. Huduma ya usimamizi huhifadhi maadili haya kwenye hifadhidata. Seva zote huenda kwenye hifadhidata mara moja kila sekunde kumi, pampu maadili ya bendera na utumie maadili haya kwa kila ombi.
Katika bomba la Acha unaweza kuweka aina mbili za maadili:
1) Maneno ya masharti. Tumia wakati moja ya maadili ni kweli. Kwa mfano:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Thamani "3" itatumika wakati ombi litachakatwa katika eneo la DC1. Na thamani ni "4" wakati ombi linashughulikiwa kwenye nguzo ya pili kwa tovuti ya beru.ru.
2) Maadili yasiyo na masharti. Tuma ombi kwa chaguo-msingi ikiwa hakuna masharti yoyote yanayotimizwa. Kwa mfano:
thamani, thamani!
Ikiwa thamani itaisha kwa alama ya mshangao, inapewa kipaumbele cha juu.
Kichanganuzi cha kigezo cha CGI huchanganua URL. Kisha tumia maadili kutoka kwa Kibomba cha Acha.
Maadili yaliyo na vipaumbele vifuatavyo hutumika:
- Kwa kipaumbele kilichoongezeka kutoka kwa Stop Gonga (alama ya mshangao).
- Thamani kutoka kwa ombi.
- Thamani chaguo-msingi kutoka kwa Stop bomba.
- Thamani chaguomsingi katika msimbo.
Kuna bendera nyingi ambazo zimeonyeshwa kwa maadili ya masharti - zinatosha kwa hali zote zinazojulikana kwetu:
- Kituo cha data.
- Mazingira: uzalishaji, upimaji, kivuli.
- Mahali: soko, beru.
- Nambari ya nguzo.
Kwa chombo hiki, unaweza kuwezesha utendaji mpya kwenye kundi fulani la seva (kwa mfano, katika kituo kimoja tu cha data) na kupima uendeshaji wa utendaji huu bila hatari yoyote kwa huduma nzima. Hata kama ulifanya makosa makubwa mahali fulani, kila kitu kilianza kuanguka na kituo kizima cha data kilipungua, wasawazishaji wataelekeza maombi kwenye vituo vingine vya data. Watumiaji wa mwisho hawatagundua chochote.
Ukiona tatizo, unaweza kurudisha bendera mara moja kwa thamani yake ya awali na mabadiliko yatarejeshwa.
Huduma hii pia ina hasara zake: watengenezaji wanaipenda sana na mara nyingi hujaribu kusukuma mabadiliko yote kwenye Kibomba cha Kuacha. Tunajaribu kupambana na matumizi mabaya.
Mbinu ya Stop Tap hufanya kazi vizuri wakati tayari una msimbo thabiti tayari kuonyeshwa kwa toleo la umma. Wakati huo huo, bado una mashaka, na unataka kuangalia msimbo katika hali ya "kupambana".
Hata hivyo, Stop Tap haifai kwa majaribio wakati wa usanidi. Kuna kikundi tofauti cha watengenezaji kinachoitwa "nguzo ya kivuli".
Upimaji wa Siri: Nguzo ya Kivuli
Maombi kutoka kwa mojawapo ya makundi yanarudiwa kwenye nguzo ya kivuli. Lakini msawazishaji hupuuza kabisa majibu kutoka kwa nguzo hii. Mchoro wa uendeshaji wake umewasilishwa hapa chini.
Tunapata kikundi cha majaribio ambacho kiko katika hali halisi ya "mapambano". Trafiki ya kawaida ya watumiaji huenda huko. Vifaa katika makundi yote mawili ni sawa, hivyo utendaji na makosa yanaweza kulinganishwa.
Na kwa kuwa msawazishaji hupuuza kabisa majibu, watumiaji wa mwisho hawataona majibu kutoka kwa nguzo ya kivuli. Kwa hiyo, sio kutisha kufanya makosa.
Matokeo
Kwa hivyo, tulijengaje utafutaji wa Soko?
Ili kufanya kila kitu kiende sawa, tunatenganisha utendaji katika huduma tofauti. Kwa njia hii tunaweza kuongeza vipengele tu ambavyo tunahitaji na kufanya vipengele rahisi zaidi. Ni rahisi kugawa sehemu tofauti kwa timu nyingine na kushiriki majukumu ya kuifanyia kazi. Na akiba kubwa katika chuma na mbinu hii ni pamoja na dhahiri.
Nguzo ya kivuli pia hutusaidia: tunaweza kuendeleza huduma, kuzijaribu katika mchakato na si kumsumbua mtumiaji.
Naam, kupima katika uzalishaji, bila shaka. Je, unahitaji kubadilisha usanidi kwenye maelfu ya seva? Rahisi, tumia Stop Gonga. Kwa njia hii unaweza kusambaza mara moja suluhisho ngumu iliyotengenezwa tayari na kurudi kwenye toleo thabiti ikiwa shida zitatokea.
Natumai niliweza kuonyesha jinsi tunavyofanya Soko kuwa haraka na dhabiti kwa msingi unaokua wa ofa. Jinsi tunavyotatua shida za seva, kushughulikia idadi kubwa ya maombi, kuboresha ubadilikaji wa huduma na kufanya hivi bila kukatiza michakato ya kazi.
Chanzo: mapenzi.com