Како функционира пребарувањето Yandex.Market и што се случува ако еден од серверите не успее

Здраво, јас се викам Евгениј. Работам во инфраструктурата за пребарување Yandex.Market. Сакам да и кажам на заедницата Хабр за внатрешната кујна на Пазарот - и имам многу да кажам. Најпрво, како функционира пребарувањето на пазарот, процесите и архитектурата. Како се справуваме со итни ситуации: што се случува ако еден сервер се прекине? Што ако има 100 такви сервери?

Ќе научите и како имплементираме нова функционалност на еден куп сервери одеднаш. И како ги тестираме сложените услуги директно во производството, без да им предизвикуваме непријатности на корисниците. Во принцип, како функционира пребарувањето на пазарот за сите да се забавуваат.

Малку за нас: каков проблем решаваме

Кога внесувате текст, пребарувате производ по параметри или споредувате цени во различни продавници, сите барања се испраќаат до услугата за пребарување. Пребарувањето е најголемата услуга на пазарот.

Ги обработуваме сите барања за пребарување: од страниците market.yandex.ru, beru.ru, услугата Supercheck, Yandex.Advisor, мобилните апликации. Ние исто така вклучуваме понуди на производи во резултатите од пребарувањето на yandex.ru.

Под услуга за пребарување не подразбирам само самото пребарување, туку и база на податоци со сите понуди на пазарот. Размерот е вака: повеќе од милијарда барања за пребарување се обработуваат дневно. И сè треба да работи брзо, без прекини и секогаш да го дава посакуваниот резултат.

Што е што: Архитектура на пазарот

Накратко ќе ја опишам моменталната архитектура на Пазарот. Тоа може грубо да се опише со дијаграмот подолу:

Да речеме дека ни доаѓа партнерска продавница. Тој вели дека сакам да продадам играчка: оваа злобна мачка со чкрип. И уште една лута мачка без чкрипче. И само мачка. Потоа продавницата треба да подготви понуди за кои Маркетот пребарува. Продавницата генерира специјален xml со понуди и ја пренесува патеката до овој xml преку партнерскиот интерфејс. Индексаторот потоа периодично го презема овој xml, проверува за грешки и ги зачувува сите информации во огромна база на податоци.

Има многу такви зачувани xml. Од оваа база на податоци е креиран индекс за пребарување. Индексот се чува во внатрешен формат. По креирањето на индексот, услугата Layout го поставува на серверите за пребарување.

Како резултат на тоа, во базата на податоци се појавува лута мачка со чкрипење, а индексот на мачката се појавува на серверот.

Ќе ви кажам како бараме мачка во делот за архитектурата за пребарување.

Архитектура за пребарување на пазарот

Живееме во свет на микроуслуги: секое дојдовно барање market.yandex.ru предизвикува многу подпрашања, а во нивната обработка се вклучени десетици услуги. Дијаграмот покажува само неколку:

Поедноставена шема за обработка на барања

Секоја услуга има прекрасна работа - свој балансер со уникатно име:

Балансерот ни дава поголема флексибилност во управувањето со услугата: можете, на пример, да ги исклучите серверите, што често е потребно за ажурирања. Балансерот гледа дека серверот е недостапен и автоматски ги пренасочува барањата до други сервери или центри за податоци. Кога додавате или отстранувате сервер, товарот автоматски се прераспределува помеѓу серверите.

Единственото име на балансерот не зависи од центарот за податоци. Кога услугата А прави барање до B, тогаш стандардно балансерот Б го пренасочува барањето до тековниот центар за податоци. Ако услугата е недостапна или не постои во тековниот центар за податоци, тогаш барањето се пренасочува во други центри за податоци.

Еден FQDN за сите центри за податоци и овозможува на услугата А целосно да се апстрахира од локациите. Неговото барање до услугата Б секогаш ќе се обработува. Исклучок е случајот кога услугата се наоѓа во сите центри за податоци.

Но, не е сè толку розово со овој баланс: имаме дополнителна средна компонента. Балансерот може да е нестабилен, а овој проблем го решаваат вишок сервери. Исто така, има дополнително доцнење помеѓу услугите А и Б. Но, во пракса тоа е помалку од 1 ms и за повеќето услуги тоа не е критично.

Справување со неочекуваното: Балансирање и еластичност на услугата за пребарување

Замислете дека има колапс: треба да најдете мачка со крцкалка, но серверот паѓа. Или 100 сервери. Како да излезете? Дали навистина ќе го оставиме корисникот без мачка?

Ситуацијата е страшна, но ние сме подготвени за тоа. Ќе ти кажам по ред.

Инфраструктурата за пребарување се наоѓа во неколку центри за податоци:

При дизајнирање, вклучуваме можност за исклучување на еден центар за податоци. Животот е полн со изненадувања - на пример, багер може да пресече подземен кабел (да, тоа се случи). Капацитетот во преостанатите центри за податоци треба да биде доволен за да го издржат врвното оптоварување.

Да разгледаме единствен центар за податоци. Секој центар за податоци ја има истата шема за работа на балансерот:

Еден балансер е најмалку три физички сервери. Овој вишок е направен заради сигурност. Балансери работат на HAProx.

Го избравме HAProx поради неговите високи перформанси, ниските барања за ресурси и широката функционалност. Нашиот софтвер за пребарување работи во секој сервер.

Веројатноста еден сервер да не успее е мала. Но, ако имате многу сервери, веројатноста барем еден да се спушти се зголемува.

Ова е она што се случува во реалноста: серверите паѓаат. Затоа, неопходно е постојано да се следи статусот на сите сервери. Ако серверот престане да реагира, тој автоматски се исклучува од сообраќајот. За таа цел, HAProxy има вградена здравствена проверка. Се оди на сите сервери еднаш во секунда со барање HTTP „/ping“.

Друга карактеристика на HAProxy: проверка на агент ви овозможува рамномерно да ги вчитате сите сервери. За да го направите ова, HAProxy се поврзува со сите сервери и тие ја враќаат својата тежина во зависност од моменталното оптоварување од 1 до 100. Тежината се пресметува врз основа на бројот на барања во редот за обработка и оптоварувањето на процесорот.

Сега за наоѓање на мачката. Резултатите од пребарувањето се барања како што се: /search?text=angry+cat. За пребарувањето да биде брзо, целиот индекс на мачки мора да се вклопи во RAM меморијата. Дури и читањето од SSD не е доволно брзо.

Некогаш базата на понуди беше мала, а RAM-от на еден сервер беше доволна за тоа. Како што растеше базата на понуди, сè повеќе не се вклопуваше во оваа RAM меморија, а податоците беа поделени на два дела: фрагмент 1 и фрагмент 2.

Но, ова секогаш се случува: секое решение, дури и добро, предизвикува други проблеми.

Балансерот сепак отиде на кој било сервер. Но, на машината каде што дојде барањето, имаше само половина од индексот. Остатокот беше на други сервери. Затоа, серверот мораше да оди на некоја соседна машина. По добивањето на податоците од двата сервери, резултатите беа комбинирани и прерангирани.

Бидејќи балансерот рамномерно ги дистрибуира барањата, сите сервери беа вклучени во повторно рангирање, а не само со испраќање податоци.

Проблемот се појави ако соседниот сервер не беше достапен. Решението беше да се наведат неколку сервери со различни приоритети како „соседен“ сервер. Прво, барањето беше испратено до серверите во тековната решетка. Доколку немаше одговор, барањето беше испратено до сите сервери во овој центар за податоци. И на крај, барањето отиде до други центри за податоци.
Како што растеше бројот на предлози, податоците беа поделени на четири дела. Но, ова не беше граница.

Во моментов, се користи конфигурација од осум парчиња. Дополнително, за да се заштеди уште повеќе меморија, индексот беше поделен на дел за пребарување (кој се користи за пребарување) и фрагмент (кој не е вклучен во пребарувањето).

Еден сервер содржи информации за само еден дел. Затоа, за да го пребарувате целосниот индекс, треба да пребарувате на осум сервери кои содржат различни делови.

Серверите се групирани во кластери. Секој кластер содржи осум пребарувачи и еден сервер за исечоци.

Серверот за исечоци води база на податоци со клучна вредност со статични податоци. Тие се потребни за издавање документи, на пример, опис на мачка со чкрипење. Податоците се специјално префрлени на посебен сервер за да не се вчита меморијата на серверите за пребарување.

Бидејќи идентификаторите на документите се единствени само во еден индекс, може да се појави ситуација кога нема документи во фрагментите. Па, или дека за една лична карта ќе има различна содржина. Затоа, за да профункционира пребарувањето и да се вратат резултатите, имаше потреба од конзистентност низ целиот кластер. Подолу ќе ви кажам како ја следиме конзистентноста.

Самото пребарување е структурирано на следниов начин: барањето за пребарување може да дојде до кој било од осумте сервери. Да речеме дека дошол на серверот 1. Овој сервер ги обработува сите аргументи и разбира што и како да бара. Во зависност од дојдовното барање, серверот може да поднесе дополнителни барања до надворешни сервиси за потребните информации. Едно барање може да биде проследено со до десет барања до надворешни услуги.

По собирањето на потребните информации, започнува пребарувањето во базата на понуди. За да го направите ова, подпрашања се направени до сите осум сервери во кластерот.

Откако ќе се добијат одговорите, резултатите се комбинираат. На крајот, можеби ќе бидат потребни уште неколку подпрашања до серверот за исечоци за да се генерираат резултатите.

Барањата за пребарување во кластерот изгледаат вака: /shard1?text=лут+мачка. Дополнително, подпрашањата на формуларот постојано се прават помеѓу сите сервери во кластерот еднаш во секунда: /статус.

Барање /статус детектира ситуација кога серверот не е достапен.

Исто така, контролира верзијата на пребарувачот и верзијата на индексот да се исти на сите сервери, во спротивно ќе има неконзистентни податоци во кластерот.

И покрај фактот дека еден сервер за фрагменти обработува барања од осум пребарувачи, неговиот процесор е многу малку натоварен. Затоа, сега ги пренесуваме податоците од фрагментот на посебна услуга.

За пренос на податоци, воведовме универзални клучеви за документи. Сега е невозможно во ситуација кога содржината од друг документ се враќа со користење на еден клуч.

Но, транзицијата кон друга архитектура сè уште не е завршена. Сега сакаме да се ослободиме од посветениот сервер за исечоци. А потоа целосно оддалечете се од структурата на кластерот. Ова ќе ни овозможи да продолжиме лесно да се зголемуваме. Дополнителен бонус е значителна заштеда на железо.

И сега на страшни приказни со среќен крај. Ајде да разгледаме неколку случаи на недостапност на серверот.

Се случи нешто страшно: еден сервер е недостапен

Да речеме дека еден сервер е недостапен. Тогаш преостанатите сервери во кластерот можат да продолжат да одговараат, но резултатите од пребарувањето ќе бидат нецелосни.

Преку проверка на статусот /статус соседните сервери разбираат дека еден е недостапен. Затоа, за да се одржи комплетноста, сите сервери во кластерот по барање /пинг тие почнуваат да му одговараат на балансерот дека и тие се недостапни. Излегува дека сите сервери во кластерот умреле (што не е точно). Ова е главниот недостаток на нашата кластер шема - затоа сакаме да се извлечеме од неа.

Барањата што не успеваат со грешка повторно ги испраќа балансерот на други сервери.
Балансерот исто така престанува да испраќа кориснички сообраќај до мртвите сервери, но продолжува да го проверува нивниот статус.

Кога серверот ќе стане достапен, тој почнува да реагира на /пинг. Штом почнат да пристигнуваат нормални одговори на пинг од мртви сервери, балансерите почнуваат да испраќаат кориснички сообраќај таму. Работата на кластерот е обновена, побргу.

Уште полошо: многу сервери се недостапни

Значителен дел од серверите во центарот за податоци се прекинати. Што да правам, каде да трчам? Балансерот повторно доаѓа на помош. Секој балансер постојано го складира во меморијата тековниот број на живи сервери. Постојано го пресметува максималниот износ на сообраќај што тековниот центар за податоци може да го обработи.

Кога многу сервери во центарот за податоци се намалуваат, балансерот сфаќа дека овој центар за податоци не може да го обработи целиот сообраќај.

Тогаш вишокот сообраќај почнува случајно да се дистрибуира до други центри за податоци. Сè работи, сите се среќни.

Како го правиме тоа: објавување изданија

Сега да разговараме за тоа како ги објавуваме промените направени на услугата. Овде тргнавме на патот на поедноставување на процесите: објавувањето на ново издание е речиси целосно автоматизирано.
Кога ќе се акумулираат одреден број промени во проектот, автоматски се креира ново издание и започнува неговото градење.

Потоа услугата се префрла на тестирање, каде што се проверува стабилноста на работа.

Во исто време, се активира автоматско тестирање на перформансите. Со ова се справува специјална служба. Нема да зборувам за тоа сега - неговиот опис е достоен за посебна статија.

Ако објавувањето во тестирањето е успешно, објавувањето на изданието во престабл автоматски се започнува. Prestable е посебен кластер каде што е насочен нормалниот кориснички сообраќај. Ако врати грешка, балансерот прави повторно барање до производството.

Во престабилот, времето на одговор се мери и споредува со претходното издание во производството. Ако сè е во ред, тогаш едно лице се поврзува: ги проверува графиконите и резултатите од тестирањето на оптоварувањето, а потоа почнува да се исфрла во производство.

Се најдобро оди кај корисникот: A/B тестирање

Не е секогаш очигледно дали промените на услугата ќе донесат реални придобивки. За да ја измерат корисноста на промените, луѓето смислија A/B тестирање. Ќе ви кажам малку за тоа како функционира во пребарувањето на Yandex.Market.

Сè започнува со додавање на нов CGI параметар кој овозможува нова функционалност. Нека нашиот параметар биде: пазар_нова_функционалност=1. Потоа во кодот ја овозможуваме оваа функционалност ако е присутно знамето:

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

Новата функционалност е воведена во производство.

За да се автоматизира A/B тестирањето, постои посветен сервис кој детално ги прикажува опишано овде. Се создава експеримент во услугата. Уделот на сообраќајот е поставен, на пример, 15%. Процентите се поставени не за прашања, туку за корисници. Времетраењето на експериментот е исто така индицирано, на пример, една недела.

Може да се извршат неколку експерименти истовремено. Во поставките можете да одредите дали е можно вкрстување со други експерименти.

Како резултат на тоа, услугата автоматски додава аргумент пазар_нова_функционалност=1 до 15% од корисниците. Исто така, автоматски ги пресметува избраните метрики. По завршувањето на експериментот, аналитичарите ги разгледуваат резултатите и извлекуваат заклучоци. Врз основа на наодите, се донесува одлука да се префрли на производство или рафинирање.

Вешта рака на пазарот: тестирање во производството

Често се случува да треба да ја тестирате работата на нова функционалност во производството, но не сте сигурни како таа ќе се однесува во „борбени“ услови под тежок товар.

Постои решение: знаменцата во параметрите CGI може да се користат не само за A/B тестирање, туку и за тестирање на нова функционалност.

Направивме алатка која ви овозможува веднаш да ја промените конфигурацијата на илјадници сервери без да ја изложувате услугата на ризици. Се вика Стоп допир. Првичната идеја беше да може брзо да се оневозможи некоја функционалност без распоред. Тогаш алатката се прошири и стана посложена.

Дијаграмот за проток на услуги е претставен подолу:

Вредностите на знамето се поставуваат преку API. Услугата за управување ги складира овие вредности во базата на податоци. Сите сервери одат во базата на податоци еднаш на секои десет секунди, ги испумпуваат вредностите на знамето и ги применуваат овие вредности на секое барање.

Во допирот Стоп можете да поставите два типа вредности:

1) Условни изрази. Примени кога една од вредностите е вистинита. На пример:

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

Вредноста „3“ ќе се примени кога барањето се обработува во локацијата DC1. И вредноста е „4“ кога барањето се обработува на вториот кластер за страницата beru.ru.

2) Безусловни вредности. Аплицирајте стандардно ако не е исполнет ниту еден од условите. На пример:

вредност, вредност!

Ако вредноста завршува со извичник, ѝ се дава поголем приоритет.

Парсерот на параметрите CGI ја анализира URL-адресата. Потоа се применуваат вредностите од Stop Tap.

Се применуваат вредности со следниве приоритети:

1. Со зголемен приоритет од Стоп допрете (извичник).
2. Вредноста од барањето.
3. Стандардна вредност од Стоп допрете.
4. Стандардна вредност во кодот.

Има многу знамиња што се означени во условни вредности - тие се доволни за сите сценарија што ни се познати:

• На Центарот за податоци.
• Животна средина: производство, тестирање, сенка.
• Место: пазар, беру.
• Кластер број.

Со оваа алатка, можете да овозможите нова функционалност на одредена група сервери (на пример, само во еден центар за податоци) и да ја тестирате работата на оваа функционалност без посебен ризик за целата услуга. Дури и ако некаде сте направиле сериозна грешка, сè почна да паѓа и целиот центар за податоци падна, балансерите ќе ги пренасочат барањата до други центри за податоци. Крајните корисници нема да забележат ништо.

Ако забележите проблем, можете веднаш да го вратите знамето на неговата претходна вредност и промените ќе се вратат назад.

Оваа услуга има и свои негативни страни: програмерите многу ја сакаат и често се обидуваат да ги турнат сите промени во Stop Tap. Се обидуваме да се бориме против злоупотребата.

Пристапот „Стоп допир“ работи добро кога веќе имате стабилен код подготвен за пуштање во производство. Во исто време, сè уште се сомневате и сакате да го проверите кодот во „борбени“ услови.

Сепак, Stopcock не е погоден за тестирање за време на развојот. Постои посебен кластер за програмери, наречен „кластер во сенки“.

Тајно тестирање: Кластер на сенки

Барањата од еден од кластерите се дуплираат во кластерот во сенка. Но, балансерот целосно ги игнорира одговорите од овој кластер. Дијаграмот на неговата работа е претставен подолу.

Добиваме тест кластер кој е во реални „борбени“ услови. Нормалниот кориснички сообраќај оди таму. Хардверот во двата кластери е ист, така што може да се споредат перформансите и грешките.

И бидејќи балансерот целосно ги игнорира одговорите, крајните корисници нема да гледаат одговори од кластерот со сенки. Затоа, не е страшно да се направи грешка.

Наоди

Значи, како го изградивме пребарувањето на пазарот?

За сè да оди непречено, ја делиме функционалноста на посебни услуги. На овој начин можеме да ги зголемиме само оние компоненти што ни се потребни и да ги направиме компонентите поедноставни. Лесно е да се додели посебна компонента на друг тим и да се споделат одговорностите за работа на неа. И значителните заштеди во железо со овој пристап е очигледен плус.

Кластерот со сенки исто така ни помага: можеме да развиеме услуги, да ги тестираме во процесот и да не го вознемируваме корисникот.

Па, тестирање во производството, се разбира. Треба да ја смените конфигурацијата на илјадници сервери? Лесно, користете го Стоп допрете. На овој начин можете веднаш да испорачате готово комплексно решение и да се вратите на стабилна верзија доколку се појават проблеми.

Се надевам дека успеав да покажам како го правиме пазарот брз и стабилен со постојано растечка база на понуди. Како ги решаваме проблемите со серверот, се справуваме со огромен број барања, ја подобруваме флексибилноста на услугата и го правиме тоа без да ги прекинуваме работните процеси.

Извор: www.habr.com