Здраво, моје име је Евгениј. Радим у инфраструктури за претрагу Иандек.Маркета. Желим да кажем Хабр заједници о унутрашњој кухињи Пијаца - и имам много тога да кажем. Пре свега, како функционише претрага тржишта, процеси и архитектура. Како се носимо са хитним ситуацијама: шта се дешава ако се један сервер поквари? Шта ако има 100 таквих сервера?
Такође ћете научити како имплементирамо нове функционалности на гомилу сервера одједном. И како тестирамо сложене услуге директно у производњи, без изазивања непријатности корисницима. Уопште, како функционише претрага тржишта тако да се сви добро проведу.
Мало о нама: који проблем решавамо
Када унесете текст, тражите производ по параметрима или упоредите цене у различитим продавницама, сви захтеви се шаљу сервису претраге. Претрага је највећа услуга на тржишту.
Обрађујемо све захтеве за претрагу: са сајтова маркет.иандек.ру, беру.ру, услуге Суперцхецк, Иандек.Адвисор, мобилних апликација. Такође укључујемо понуде производа у резултате претраге на иандек.ру.
Под сервисом претраге мислим не само на саму претрагу, већ и на базу података са свим понудама на тржишту. Скала је следећа: више од милијарду захтева за претрагу се обради дневно. И све би требало да ради брзо, без прекида и увек даје жељени резултат.
Шта је шта: Тржишна архитектура
Укратко ћу описати тренутну архитектуру Тржишта. Може се грубо описати дијаграмом испод:
Рецимо да нам дође партнерска продавница. Каже да хоћу да продам играчку: ову злу мачку са шкрипом. И још једна љута мачка без пискала. И само мачка. Затим продавница треба да припреми понуде за којима Тржиште тражи. Продавница генерише посебан кмл са понудама и саопштава путању до овог кмл-а преко придруженог интерфејса. Индексер затим периодично преузима овај кмл, проверава да ли постоје грешке и чува све информације у огромној бази података.
Постоји много таквих сачуваних кмл-ова. Индекс претраге се креира из ове базе података. Индекс се чува у интерном формату. Након креирања индекса, Лаиоут сервис га отпрема на сервере за претрагу.
Као резултат тога, у бази података појављује се љута мачка са писком, а индекс мачке се појављује на серверу.
Рећи ћу вам како тражимо мачку у делу о архитектури претраге.
Архитектура претраживања тржишта
Живимо у свету микроуслуга: сваки долазни захтев изазива много подупита, а десетине услуга су укључене у њихову обраду. Дијаграм приказује само неколико:
Поједностављена шема обраде захтева
Свака услуга има дивну ствар - свој балансер са јединственим именом:
Балансер нам даје већу флексибилност у управљању услугом: можете, на пример, да искључите сервере, што је често потребно за ажурирања. Балансер види да је сервер недоступан и аутоматски преусмерава захтеве на друге сервере или центре података. Приликом додавања или уклањања сервера, оптерећење се аутоматски редистрибуира између сервера.
Јединствено име балансера не зависи од центра података. Када услуга А упути захтев Б, онда подразумевано балансер Б преусмерава захтев на тренутни центар података. Ако је услуга недоступна или не постоји у тренутном дата центру, онда се захтев преусмерава на друге центре података.
Јединствени ФКДН за све центре података омогућава сервису А да се потпуно апстрахује од локација. Његов захтев за услугу Б увек ће бити обрађен. Изузетак је случај када се сервис налази у свим дата центрима.
Али није све тако ружичасто са овим балансером: имамо додатну средњу компоненту. Балансер је можда нестабилан, а овај проблем решавају редундантни сервери. Такође постоји додатно кашњење између услуга А и Б. Али у пракси је мање од 1 мс и за већину услуга то није критично.
Суочавање са неочекиваним: балансирање и отпорност услуге претраге
Замислите да је дошло до колапса: потребно је да нађете мачку са шкрипом, али сервер се руши. Или 100 сервера. Како изаћи? Хоћемо ли заиста оставити корисника без мачке?
Ситуација је застрашујућа, али ми смо спремни за то. Рећи ћу ти редом.
Инфраструктура за претрагу се налази у неколико дата центара:
Приликом пројектовања укључујемо могућност гашења једног дата центра. Живот је пун изненађења - на пример, багер може да пресече подземни кабл (да, то се десило). Капацитет у преосталим центрима података треба да буде довољан да издржи вршно оптерећење.
Хајде да размотримо један центар података. Сваки центар података има исту шему рада балансера:
Један балансер су најмање три физичка сервера. Овај вишак је направљен ради поузданости. Балансери раде на ХАПрок-у.
Изабрали смо ХАПрок због његових високих перформанси, ниских захтева за ресурсима и широке функционалности. Наш софтвер за претрагу ради унутар сваког сервера.
Вероватноћа квара једног сервера је мала. Али ако имате много сервера, повећава се вероватноћа да ће се барем један покварити.
Ово се дешава у стварности: сервери падају. Због тога је неопходно стално пратити статус свих сервера. Ако сервер престане да реагује, аутоматски се искључује из саобраћаја. У ту сврху, ХАПроки има уграђену проверу здравља. Иде на све сервере једном у секунди са ХТТП захтевом „/пинг“.
Још једна карактеристика ХАПроки-а: провера агента вам омогућава да равномерно учитате све сервере. Да би то урадио, ХАПроки се повезује са свим серверима и они враћају своју тежину у зависности од тренутног оптерећења од 1 до 100. Тежина се израчунава на основу броја захтева у реду за обраду и оптерећења процесора.
Сада о проналажењу мачке. Резултати претраге у захтевима као што су: /сеарцх?тект=љута+мачка. Да би претрага била брза, цео индекс мачке мора да стане у РАМ. Чак и читање са ССД-а није довољно брзо.
Некада је база понуда била мала, а за њу је била довољна РАМ меморија једног сервера. Како је база понуде расла, све се више није уклапало у овај РАМ, а подаци су подељени на два дела: део 1 и део 2.
Али ово се увек дешава: свако решење, чак и добро, доводи до других проблема.
Балансер је и даље отишао на било који сервер. Али на машини где је стигао захтев, била је само половина индекса. Остало је било на другим серверима. Стога је сервер морао да иде на неку суседну машину. Након пријема података са оба сервера, резултати су комбиновани и поново рангирани.
Пошто балансер равномерно распоређује захтеве, сви сервери су били ангажовани на поновном рангирању, а не само на слању података.
Проблем је настао ако је суседни сервер био недоступан. Решење је било да се наведе неколико сервера са различитим приоритетима као „суседни“ сервер. Прво, захтев је послат серверима у тренутном сталку. Уколико није било одговора, захтев је послат свим серверима у овом дата центру. И на крају, захтев је отишао у друге центре података.
Како је број предлога растао, подаци су подељени на четири дела. Али ово није била граница.
Тренутно се користи конфигурација од осам комада. Поред тога, да би се уштедело још више меморије, индекс је подељен на део за претрагу (који се користи за претрагу) и део исечка (који није укључен у претрагу).
Један сервер садржи информације само за један шард. Стога, да бисте претражили цео индекс, потребно је да претражујете на осам сервера који садрже различите делове.
Сервери су груписани у кластере. Сваки кластер садржи осам претраживача и један сниппет сервер.
Сервер исечака покреће базу података кључ/вредност са статичким подацима. Они су потребни за издавање докумената, на пример, опис мачке са пискаром. Подаци се посебно преносе на посебан сервер како се не би учитавала меморија сервера за претрагу.
Пошто су ИД-ови докумената јединствени само у оквиру једног индекса, може доћи до ситуације да у исечцима нема докумената. Па, или да ће за један ИД бити различит садржај. Стога, да би претрага функционисала и да би се резултати вратили, постојала је потреба за доследношћу у целом кластеру. У наставку ћу вам рећи како пратимо доследност.
Сама претрага је структурирана на следећи начин: захтев за претрагу може доћи на било који од осам сервера. Рецимо да је дошао на сервер 1. Овај сервер обрађује све аргументе и разуме шта и како да тражи. У зависности од долазног захтева, сервер може да упути додатне захтеве спољним сервисима за потребне информације. Један захтев може бити праћен до десет захтева екстерним сервисима.
Након прикупљања потребних информација, почиње претрага у бази понуде. Да би се то урадило, подупити се праве за свих осам сервера у кластеру.
Када се добију одговори, резултати се комбинују. На крају ће можда бити потребно још неколико подупита серверу исечака да би се генерисали резултати.
Упити за претрагу унутар кластера изгледају овако: /схард1?тект=љута+мачка. Поред тога, потупити обрасца се стално праве између свих сервера унутар кластера једном у секунди: /статус.
Захтев /статус детектује ситуацију у којој сервер није доступан.
Такође контролише да су верзија претраживача и верзија индекса исте на свим серверима, иначе ће бити недоследних података унутар кластера.
Упркос чињеници да један сниппет сервер обрађује захтеве од осам претраживача, његов процесор је веома слабо оптерећен. Због тога сада преносимо податке фрагмента у засебну услугу.
За пренос података увели смо универзалне кључеве за документе. Сада је немогућа ситуација да се садржај из другог документа враћа помоћу једног кључа.
Али прелазак на другу архитектуру још није завршен. Сада желимо да се решимо наменског сервера исечака. А онда се потпуно удаљите од структуре кластера. Ово ће нам омогућити да наставимо са лакоћом скалирања. Додатни бонус је значајна уштеда гвожђа.
А сада страшне приче са срећним завршетком. Хајде да размотримо неколико случајева недоступности сервера.
Десило се нешто страшно: један сервер је недоступан
Рецимо да је један сервер недоступан. Тада преостали сервери у кластеру могу да наставе да одговарају, али резултати претраге ће бити непотпуни.
Путем провере статуса /статус суседни сервери разумеју да је један недоступан. Стога, да би се одржала комплетност, сви сервери у кластеру по захтеву /пинг почињу да одговарају балансеру да су и они недоступни. Испоставило се да су сви сервери у кластеру умрли (што није тачно). Ово је главни недостатак наше шеме кластера - зато желимо да побегнемо од тога.
Захтеве који не успеју са грешком балансер поново шаље на друге сервере.
Балансер такође престаје да шаље кориснички саобраћај мртвим серверима, али наставља да проверава њихов статус.
Када сервер постане доступан, почиње да одговара на /пинг. Чим почну да стижу нормални одговори на пингове са мртвих сервера, балансери почињу да шаљу кориснички саобраћај тамо. Рад кластера је обновљен, ура.
Још горе: многи сервери су недоступни
Значајан део сервера у дата центру је прекинут. Шта да радим, где да бежим? Балансер поново долази у помоћ. Сваки балансер стално складишти у меморији тренутни број живих сервера. Стално израчунава максималну количину саобраћаја коју тренутни дата центар може да обради.
Када се многи сервери у дата центру покваре, балансер схвата да овај центар података не може да обради сав саобраћај.
Тада вишак саобраћаја почиње да се насумично распоређује на друге центре података. Све ради, сви су срећни.
Како то радимо: објављивање издања
Хајде сада да причамо о томе како објављујемо промене направљене на услузи. Овде смо кренули путем поједностављивања процеса: увођење новог издања је скоро потпуно аутоматизовано.
Када се акумулира одређени број измена у пројекту, аутоматски се креира ново издање и почиње његова израда.
Затим се сервис покреће на тестирање, где се проверава стабилност рада.
Истовремено се покреће аутоматско тестирање перформанси. Овим се бави посебна служба. Нећу сада о томе - његов опис је вредан посебног чланка.
Ако је објављивање у тестирању успешно, аутоматски се покреће објављивање издања у престабилу. Престабле је посебан кластер у који се усмерава нормалан кориснички саобраћај. Ако врати грешку, балансер шаље поновни захтев производњи.
У престабилном, време одзива се мери и пореди са претходним издањем у производњи. Ако је све у реду, онда се особа повезује: проверава графиконе и резултате тестирања оптерећења, а затим креће у производњу.
Све најбоље иде кориснику: А/Б тестирање
Није увек очигледно да ли ће промене услуге донети стварне користи. Да би измерили корисност промена, људи су смислили А/Б тестирање. Рећи ћу вам мало о томе како то функционише у Иандек.Маркет претрази.
Све почиње додавањем новог ЦГИ параметра који омогућава нову функционалност. Нека наш параметар буде: маркет_нев_фунцтионалити=1. Затим у коду омогућавамо ову функционалност ако је заставица присутна:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Нова функционалност се уводи у производњу.
Да бисте аутоматизовали А/Б тестирање, постоји наменска услуга која пружа детаљне информације . У сервису се прави експеримент. Удео саобраћаја је постављен, на пример, 15%. Проценти се не постављају за упите, већ за кориснике. Трајање експеримента је такође назначено, на пример, недељу дана.
Неколико експеримената се може изводити истовремено. У подешавањима можете одредити да ли је могуће укрштање са другим експериментима.
Као резултат тога, услуга аутоматски додаје аргумент маркет_нев_фунцтионалити=1 до 15% корисника. Такође аутоматски израчунава изабране метрике. Након што је експеримент завршен, аналитичари гледају резултате и доносе закључке. На основу налаза, доноси се одлука о пуштању у производњу или дораду.
Спретна рука тржишта: тестирање у производњи
Често се дешава да морате да тестирате рад нове функционалности у продукцији, али нисте сигурни како ће се она понашати у „борбеним“ условима под великим оптерећењем.
Постоји решење: заставице у ЦГИ параметрима се могу користити не само за А/Б тестирање, већ и за тестирање нове функционалности.
Направили смо алат који вам омогућава да тренутно промените конфигурацију на хиљадама сервера без излагања услуге ризицима. Зове се Стоп Тап. Првобитна идеја је била да се може брзо онемогућити нека функционалност без распореда. Затим се алат проширио и постао сложенији.
Дијаграм тока услуге је представљен у наставку:
Вредности заставице се постављају преко АПИ-ја. Услуга управљања чува ове вредности у бази података. Сви сервери иду у базу података сваких десет секунди, испумпавају вредности заставице и примењују ове вредности на сваки захтев.
У додиру Стоп можете поставити две врсте вредности:
1) Условни изрази. Примени када је једна од вредности тачна. На пример:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Вредност "3" ће бити примењена када се захтев обради на локацији ДЦ1. А вредност је „4“ када се захтев обради на другом кластеру за сајт беру.ру.
2) Безусловне вредности. Подразумевано примените ако ниједан од услова није испуњен. На пример:
вредност, вредност!
Ако се вредност завршава знаком узвика, даје јој се већи приоритет.
Парсер ЦГИ параметара анализира УРЛ. Затим примењује вредности из Стоп Тап.
Примењују се вредности са следећим приоритетима:
- Са повећаним приоритетом од Стоп Тап (знак узвика).
- Вредност из захтева.
- Подразумевана вредност од Стоп тап.
- Подразумевана вредност у коду.
Постоји много застава које су назначене у условним вредностима - оне су довољне за све нама познате сценарије:
- Центар за податке.
- Окружење: производња, тестирање, сенка.
- Место одржавања: пијаца, беру.
- Број кластера.
Помоћу овог алата можете омогућити нову функционалност на одређеној групи сервера (на пример, само у једном дата центру) и тестирати рад ове функционалности без икаквог посебног ризика за цео сервис. Чак и ако сте негде направили озбиљну грешку, све је почело да пада и цео дата центар се срушио, балансери ће преусмерити захтеве на друге центре података. Крајњи корисници неће ништа приметити.
Ако приметите проблем, можете одмах вратити заставицу на претходну вредност и промене ће бити враћене.
Ова услуга такође има своје недостатке: програмери је веома воле и често покушавају да све промене унесу у Стоп Тап. Покушавамо да се боримо против злоупотребе.
Приступ Стоп Тап добро функционише када већ имате стабилан код спреман за увођење у производњу. У исто време, још увек имате сумње и желите да проверите код у „борбеним“ условима.
Међутим, Стоп Тап није погодан за тестирање током развоја. Постоји посебан кластер за програмере који се зове „кластер сенки“.
Тајно тестирање: кластер сенки
Захтеви из једног од кластера се дуплирају у кластер у сенци. Али балансер потпуно игнорише одговоре из овог кластера. Дијаграм његовог рада је представљен у наставку.
Добијамо тест кластер који је у стварним „борбеним“ условима. Тамо иде нормалан кориснички саобраћај. Хардвер у оба кластера је исти, тако да се перформансе и грешке могу поредити.
А пошто балансер потпуно игнорише одговоре, крајњи корисници неће видети одговоре из кластера сенки. Стога, није страшно погрешити.
Налази
Дакле, како смо изградили претрагу тржишта?
Да би све протекло глатко, одвајамо функционалност у засебне услуге. На овај начин можемо скалирати само оне компоненте које су нам потребне и учинити компоненте једноставнијим. Лако је доделити засебну компоненту другом тиму и поделити одговорности за рад на њој. А значајна уштеда гвожђа са овим приступом је очигледан плус.
Помаже нам и кластер сенки: можемо да развијамо сервисе, да их тестирамо у процесу и да не ометамо корисника.
Па, тестирање у производњи, наравно. Требате да промените конфигурацију на хиљадама сервера? Лако, користите Стоп Тап. На овај начин можете одмах покренути готово сложено решење и вратити се на стабилну верзију ако се појаве проблеми.
Надам се да сам успео да покажем како чинимо Маркет брзим и стабилним са стално растућом базом понуда. Како решавамо проблеме сервера, решавамо велики број захтева, побољшавамо флексибилност сервиса и то радимо без прекидања процеса рада.
Извор: ввв.хабр.цом