Сәлем, менің атым Евгений. Мен Yandex.Market іздеу инфрақұрылымында жұмыс істеймін. Мен Хабр қауымдастығына Базардың ішкі асханасы туралы айтқым келеді - және менің айтарым көп. Ең алдымен, нарықты іздеу қалай жұмыс істейді, процестер және архитектура. Төтенше жағдайлармен қалай күресеміз: бір сервер істен шыққан жағдайда не болады? Осындай 100 сервер болса ше?
Сондай-ақ, сіз бірден бірнеше серверлерде жаңа функцияларды қалай жүзеге асыратынымызды білесіз. Және біз қолданушыларға қолайсыздық тудырмай, күрделі қызметтерді тікелей өндірісте қалай сынаймыз. Тұтастай алғанда, барлығына уақытты жақсы өткізу үшін нарықты іздеу қалай жұмыс істейді.
Біз туралы аз: біз қандай мәселені шешеміз
Мәтінді енгізгенде, өнімді параметрлер бойынша іздегенде немесе әртүрлі дүкендердегі бағаларды салыстырғанда, барлық сұраулар іздеу қызметіне жіберіледі. Іздеу - бұл нарықтағы ең үлкен қызмет.
Біз барлық іздеу сұрауларын өңдейміз: market.yandex.ru, beru.ru сайттарынан, Supercheck қызметі, Yandex.Advisor, мобильді қосымшалар. Біз сондай-ақ yandex.ru сайтындағы іздеу нәтижелеріне өнім ұсыныстарын қосамыз.
Іздеу қызметі арқылы мен іздеудің өзін ғана емес, сонымен қатар Нарықтағы барлық ұсыныстары бар мәліметтер базасын айтамын. Масштаб мынада: күніне миллиардтан астам іздеу сұраулары өңделеді. Және бәрі тез, үзіліссіз жұмыс істеуі және әрқашан қажетті нәтиже беруі керек.
Бұл не: Нарық архитектурасы
Мен нарықтың қазіргі архитектурасын қысқаша сипаттаймын. Оны төмендегі диаграмма арқылы шамамен сипаттауға болады:
Бізге серіктес дүкен келді делік. Ол менің ойыншық сатқым келеді дейді: мынау зұлым мысық. Ал тағы бір ашушаң мысық. Және жай мысық. Содан кейін дүкен нарық іздейтін ұсыныстарды дайындауы керек. Дүкен ұсыныстары бар арнайы xml жасайды және серіктестік интерфейсі арқылы осы xml жолын хабарлайды. Содан кейін индексатор осы xml файлын мезгіл-мезгіл жүктеп алады, қателерді тексереді және барлық ақпаратты үлкен дерекқорға сақтайды.
Мұндай сақталған xml файлдары көп. Бұл дерекқордан іздеу индексі жасалады. Индекс ішкі форматта сақталады. Индексті жасағаннан кейін Layout қызметі оны іздеу серверлеріне жүктейді.
Нәтижесінде дерекқорда ашулы мысық пайда болады, ал серверде мысықтың индексі пайда болады.
Мен сізге іздеу архитектурасы бөлігінде мысықты қалай іздейтінімізді айтамын.
Нарықты іздеу архитектурасы
Біз микросервис әлемінде өмір сүреміз: әрбір кіріс сұрау көптеген ішкі сұрауларды тудырады және оларды өңдеуге ондаған қызметтер қатысады. Диаграммада тек кейбіреулер көрсетілген:
Сұраныстарды өңдеудің жеңілдетілген схемасы
Әрбір қызметтің керемет нәрсесі бар - бірегей атауы бар өз балансизаторы:
Баланстауыш бізге қызметті басқаруда үлкен икемділік береді: сіз, мысалы, жаңартулар үшін жиі қажет болатын серверлерді өшіре аласыз. Баланстауыш сервердің қолжетімсіз екенін көреді және сұрауларды басқа серверлерге немесе деректер орталықтарына автоматты түрде қайта бағыттайды. Серверді қосқанда немесе жою кезінде жүктеме серверлер арасында автоматты түрде қайта бөлінеді.
Баланстауыштың бірегей атауы деректер орталығына байланысты емес. А қызметі В қызметіне сұраныс жасағанда, әдепкі бойынша теңгергіш B сұрауды ағымдағы деректер орталығына қайта бағыттайды. Егер қызмет қолжетімсіз болса немесе ағымдағы деректер орталығында жоқ болса, сұрау басқа деректер орталықтарына қайта бағытталады.
Барлық деректер орталықтарына арналған жалғыз FQDN A қызметіне орындардан толығымен абстракциялауға мүмкіндік береді. Оның В қызметіне сұрауы әрқашан өңделеді. Ерекшелік - бұл қызмет барлық деректер орталықтарында орналасқан жағдай.
Бірақ бұл теңдестіргішпен бәрі қызғылт емес: бізде қосымша аралық компонент бар. Теңгерім тұрақсыз болуы мүмкін және бұл мәселе артық серверлер арқылы шешіледі. Сондай-ақ A және B қызметтері арасында қосымша кідіріс бар. Бірақ іс жүзінде бұл 1 мс-тен аз және көптеген қызметтер үшін бұл маңызды емес.
Күтпеген жағдаймен күресу: іздеу қызметінің теңгерімі мен тұрақтылығы
Елестетіп көріңізші, коллапс бар: сіз мылжыңы бар мысықты табуыңыз керек, бірақ сервер бұзылады. Немесе 100 сервер. Қалай шығуға болады? Біз шынымен пайдаланушыны мысықсыз қалдырамыз ба?
Жағдай қорқынышты, бірақ біз оған дайынбыз. Мен сізге ретімен айтамын.
Іздеу инфрақұрылымы бірнеше деректер орталықтарында орналасқан:
Жобалау кезінде біз бір деректер орталығын өшіру мүмкіндігін қосамыз. Өмір тосын сыйларға толы - мысалы, экскаватор жер асты кабелін кесіп тастауы мүмкін (иә, солай болды). Қалған деректер орталықтарындағы сыйымдылық ең жоғары жүктемеге төтеп беруге жеткілікті болуы керек.
Бірыңғай деректер орталығын қарастырайық. Әрбір деректер орталығында теңдестіргіштің жұмыс схемасы бірдей:
Бір баланстауыш кем дегенде үш физикалық сервер болып табылады. Бұл артықшылық сенімділік үшін жасалған. Балансерлер HAProx жүйесінде жұмыс істейді.
Біз HAProx-ті оның жоғары өнімділігі, ресурсқа төмен талаптары және кең функционалдығы арқасында таңдадық. Біздің іздеу бағдарламалық құралымыз әрбір серверде жұмыс істейді.
Бір сервердің істен шығу ықтималдығы төмен. Бірақ егер сізде көптеген серверлер болса, кем дегенде біреуі төмендеу ықтималдығы артады.
Бұл шын мәнінде болады: серверлер бұзылады. Сондықтан барлық серверлердің күйін үнемі бақылау қажет. Сервер жауап беруді тоқтатса, ол трафиктен автоматты түрде ажыратылады. Осы мақсатта HAProxy жүйесінде денсаулықты тексеру бар. Ол барлық серверлерге секундына бір рет HTTP сұрауы «/ping» арқылы өтеді.
HAProxy тағы бір мүмкіндігі: агент-тексеру барлық серверлерді біркелкі жүктеуге мүмкіндік береді. Ол үшін HAProxy барлық серверлерге қосылады және олар ағымдағы жүктемеге байланысты 1-ден 100-ге дейін салмағын қайтарады. Салмақ өңдеуге арналған кезектегі сұраулар саны мен процессорға жүктелген жүктеме негізінде есептеледі.
Енді мысықты табу туралы. Іздеу нәтижелері келесідей сұрауларда: /search?text=ашулы+мысық. Іздеу жылдам болуы үшін барлық мысық индексі жедел жадқа сәйкес келуі керек. Тіпті SSD-ден оқу жеткілікті жылдам емес.
Бір кездері ұсыныс деректер базасы шағын болды және оған бір сервердің жедел жады жеткілікті болды. Ұсыныс базасы ұлғайған сайын, бәрі енді бұл ЖЖҚ-ға сәйкес келмейді және деректер екі бөлікке бөлінді: 1-ші бөлік және 2-ші бөлік.
Бірақ бұл әрқашан болады: кез келген шешім, тіпті жақсы шешім басқа проблемаларды тудырады.
Балансатор кез келген серверге барды. Бірақ сұраныс келген машинада көрсеткіштің жартысы ғана болды. Қалғаны басқа серверлерде болды. Сондықтан сервер кейбір көрші компьютерге баруға мәжбүр болды. Екі серверден де деректерді алғаннан кейін нәтижелер біріктіріліп, қайта сұрыпталды.
Теңгерім сұрауларды біркелкі тарататындықтан, барлық серверлер деректерді жіберіп қана қоймай, қайта рейтингпен айналысты.
Мәселе көрші сервер қолжетімсіз болғанда орын алды. Шешім әртүрлі басымдықтары бар бірнеше серверлерді «көрші» сервер ретінде көрсету болды. Біріншіден, сұраныс ағымдағы сөредегі серверлерге жіберілді. Жауап болмаса, сұрау осы деректер орталығындағы барлық серверлерге жіберілді. Соңында сұрау басқа дата орталықтарына жіберілді.
Ұсыныстар саны өскен сайын деректер төрт бөлікке бөлінді. Бірақ бұл шек емес еді.
Қазіргі уақытта сегіз үзіндінің конфигурациясы пайдаланылады. Сонымен қатар, жадты көбірек сақтау үшін индекс іздеу бөлігіне (іздеу үшін пайдаланылады) және үзінді бөлігіне (іздеуге қатыспайтын) бөлінді.
Бір сервер тек бір бөлікке арналған ақпаратты қамтиды. Сондықтан толық индексті іздеу үшін әртүрлі үзінділері бар сегіз серверде іздеу керек.
Серверлер кластерлерге топтастырылған. Әрбір кластерде сегіз іздеу жүйесі және бір үзінді сервері бар.
Үзінді сервері статикалық деректері бар кілт-мән дерекқорын іске қосады. Олар құжаттарды беру үшін қажет, мысалы, мылжыңы бар мысықтың сипаттамасы. Іздеу серверлерінің жадын жүктемеу үшін деректер бөлек серверге арнайы тасымалданады.
Құжат идентификаторлары тек бір индекс ішінде бірегей болғандықтан, үзінділерде құжаттар болмаған жағдай туындауы мүмкін. Немесе бір идентификатор үшін әртүрлі мазмұн болады. Сондықтан, іздеу жұмыс істеуі және нәтижелер қайтарылуы үшін бүкіл кластер бойынша жүйелілік қажет болды. Төменде мен дәйектілікті қалай бақылайтынымызды айтып беремін.
Іздеудің өзі келесідей құрылымдалған: іздеу сұрауы сегіз сервердің кез келгеніне келуі мүмкін. Ол 1-серверге келді делік. Бұл сервер барлық аргументтерді өңдейді және нені және қалай іздеу керектігін түсінеді. Кіріс сұрауына байланысты сервер қажетті ақпарат үшін сыртқы қызметтерге қосымша сұраныстар жасай алады. Бір сұраудан кейін сыртқы қызметтерге онға дейін сұрау салуға болады.
Қажетті ақпаратты жинағаннан кейін ұсыныс базасында іздеу басталады. Бұл әрекетті орындау үшін кластердегі барлық сегіз серверге ішкі сұраулар жасалады.
Жауаптар алынғаннан кейін нәтижелер біріктіріледі. Соңында нәтижелерді жасау үшін үзінді серверіне тағы бірнеше ішкі сұраулар қажет болуы мүмкін.
Кластердегі іздеу сұраулары келесідей: /shard1?text=ашулы+мысық. Сонымен қатар, пішіннің ішкі сұраулары секундына бір рет кластердегі барлық серверлер арасында үнемі жасалады: /күй.
Сұрау /күй сервер қолжетімді емес жағдайды анықтайды.
Ол сонымен қатар іздеу жүйесінің нұсқасы мен индекс нұсқасының барлық серверлерде бірдей болуын басқарады, әйтпесе кластер ішінде сәйкес келмейтін деректер болады.
Бір үзінді сервер сегіз іздеу жүйесінен сұрауларды өңдейтініне қарамастан, оның процессоры өте жеңіл жүктеледі. Сондықтан біз қазір үзінді деректерін бөлек қызметке тасымалдаймыз.
Деректерді тасымалдау үшін біз құжаттарға арналған әмбебап кілттерді енгіздік. Енді бір кілт арқылы басқа құжаттың мазмұны қайтарылатын жағдай мүмкін емес.
Бірақ басқа архитектураға көшу әлі аяқталған жоқ. Енді біз арнайы үзінді серверден құтылғымыз келеді. Содан кейін кластер құрылымынан мүлдем алыстаңыз. Бұл бізге оңай масштабтауға мүмкіндік береді. Қосымша бонус - темірді айтарлықтай үнемдеу.
Ал енді бақытты аяқталатын қорқынышты оқиғаларға. Сервердің қолжетімсіздігінің бірнеше жағдайын қарастырайық.
Қорқынышты бірдеңе болды: бір сервер қолжетімсіз
Бір сервер қолжетімсіз делік. Содан кейін кластердегі қалған серверлер жауап беруді жалғастыра алады, бірақ іздеу нәтижелері толық емес болады.
Күйді тексеру арқылы /күй көрші серверлер біреуі қолжетімсіз екенін түсінеді. Сондықтан, толықтықты сақтау үшін кластердегі барлық серверлер сұрау бойынша /ping олар теңгерушіге олар да қолжетімсіз деп жауап бере бастайды. Кластердегі барлық серверлер қайтыс болды (бұл дұрыс емес). Бұл біздің кластерлік схемамыздың басты кемшілігі - сондықтан біз одан аулақ болғымыз келеді.
Қатемен орындалмаған сұрауларды теңгеруші басқа серверлерде қайта жібереді.
Теңгерім де өлі серверлерге пайдаланушы трафигін жіберуді тоқтатады, бірақ олардың күйін тексеруді жалғастырады.
Сервер қол жетімді болғанда, ол жауап бере бастайды /ping. Өлі серверлерден пингтерге қалыпты жауаптар келе бастағанда, теңгергіштер сол жерге пайдаланушы трафигін жібере бастайды. Кластер жұмысы қалпына келтірілді.
Одан да сорақысы: көптеген серверлер қолжетімсіз
Деректер орталығындағы серверлердің едәуір бөлігі қысқартылды. Не істеу керек, қайда жүгіру керек? Теңгерімші тағы да көмекке келеді. Әрбір баланстаушы тұрақты серверлердің ағымдағы санын жадта сақтайды. Ол ағымдағы деректер орталығы өңдей алатын трафиктің максималды көлемін үнемі есептеп отырады.
Деректер орталығындағы көптеген серверлер істен шыққанда, теңгеруші бұл деректер орталығының барлық трафикті өңдей алмайтынын түсінеді.
Содан кейін артық трафик басқа деректер орталықтарына кездейсоқ таратыла бастайды. Барлығы жұмыс істейді, бәрі бақытты.
Біз мұны қалай істейміз: шығарылымдарды жариялау
Енді қызметке енгізілген өзгерістерді қалай жариялайтынымыз туралы сөйлесейік. Мұнда біз процестерді жеңілдету жолын таңдадық: жаңа шығарылымды шығару толығымен дерлік автоматтандырылған.
Жобада өзгерістердің белгілі бір саны жинақталғанда, жаңа шығарылым автоматты түрде жасалады және оны құрастыру басталады.
Содан кейін қызмет жұмыс тұрақтылығы тексерілетін тестілеуге шығарылады.
Бұл ретте өнімділікті автоматты түрде тексеру іске қосылады. Бұл арнайы қызметпен айналысады. Мен бұл туралы қазір айтпаймын - оның сипаттамасы бөлек мақалаға лайық.
Тестілеуде жариялау сәтті болса, шығарылымды алдын ала тұрақты күйде жариялау автоматты түрде басталады. 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 тестілеу үшін ғана емес, сонымен қатар жаңа функционалдылықты тексеру үшін де қолдануға болады.
Біз мыңдаған серверлердегі конфигурацияны қызметке қауіп төндірмей бірден өзгертуге мүмкіндік беретін құрал жасадық. Ол Stop Tap деп аталады. Бастапқы идея кейбір функцияларды орналасусыз жылдам өшіру болды. Содан кейін құрал кеңейіп, күрделене түсті.
Қызмет көрсету ағынының диаграммасы төменде көрсетілген:
Жалауша мәндері API арқылы орнатылады. Басқару қызметі бұл мәндерді дерекқорда сақтайды. Барлық серверлер дерекқорға әр он секунд сайын кіріп, жалауша мәндерін шығарып, осы мәндерді әрбір сұрауға қолданады.
Тоқтату түртуінде мәндердің екі түрін орнатуға болады:
1) Шартты өрнектер. Мәндердің бірі ақиқат болғанда қолданыңыз. Мысалы:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Сұраныс DC3 орнында өңделген кезде "1" мәні қолданылады. Сұраныс beru.ru сайтының екінші кластерінде өңделген кезде мән «4».
2) Шартсыз мәндер. Шарттардың ешқайсысы орындалмаса, әдепкі бойынша қолданыңыз. Мысалы:
құндылық, құндылық!
Егер мән леп белгісімен аяқталса, оған жоғары басымдық беріледі.
CGI параметрінің талдаушысы URL мекенжайын талдайды. Содан кейін Stop Tap түймешігіндегі мәндерді қолданады.
Келесі басымдықтары бар мәндер қолданылады:
- Stop Tap (леп белгісі) арқылы жоғарылатылған басымдықпен.
- Сұраныс бойынша мән.
- Тоқтату түрту жолындағы әдепкі мән.
- Кодтағы әдепкі мән.
Шартты мәндерде көрсетілген көптеген жалаулар бар - олар бізге белгілі барлық сценарийлер үшін жеткілікті:
- Деректер орталығы.
- Қоршаған орта: өндіріс, сынақ, көлеңке.
- Өтетін орны: базар, беру.
- Кластер нөмірі.
Бұл құралдың көмегімен белгілі бір серверлер тобында (мысалы, тек бір деректер орталығында) жаңа функцияларды қосуға және бүкіл қызметке ешқандай қауіп төндірмей, осы функцияның жұмысын тексеруге болады. Бір жерде елеулі қателік жасасаңыз да, бәрі құлдырай бастады және бүкіл деректер орталығы жұмыс істемейді, теңгергіштер сұрауларды басқа деректер орталықтарына қайта бағыттайды. Соңғы пайдаланушылар ештеңе байқамайды.
Ақаулықты байқасаңыз, жалаушаны бұрынғы мәніне дереу қайтаруға болады және өзгертулер кері қайтарылады.
Бұл қызметтің кемшіліктері де бар: әзірлеушілер оны өте жақсы көреді және жиі барлық өзгерістерді Stop Tap батырмасына енгізуге тырысады. Біз теріс пайдаланумен күресуге тырысамыз.
Stop Tap тәсілі өндіріске шығаруға дайын тұрақты кодыңыз болған кезде жақсы жұмыс істейді. Сонымен қатар, сізде әлі де күмән бар және сіз кодты «жауынгерлік» жағдайда тексергіңіз келеді.
Дегенмен, Stop Tap қолданбасы әзірлеу кезінде тестілеуге жарамайды. Әзірлеушілер үшін «көлеңкелі кластер» деп аталатын жеке кластер бар.
Құпия сынақ: Көлеңке кластері
Кластерлердің бірінің сұраулары көлеңкелі кластерге көшіріледі. Бірақ баланстауыш осы кластердің жауаптарын толығымен елемейді. Оның жұмысының диаграммасы төменде берілген.
Біз нақты «жауынгерлік» жағдайда болатын сынақ кластерін аламыз. Қалыпты пайдаланушы трафигі сонда жүреді. Екі кластердегі аппараттық құрал бірдей, сондықтан өнімділік пен қателерді салыстыруға болады.
Балансатор жауаптарды толығымен елемейтіндіктен, соңғы пайдаланушылар көлеңкелі кластерден жауаптарды көрмейді. Сондықтан қателесу қорқынышты емес.
қорытындылар
Сонымен, біз нарықтық іздеуді қалай құрдық?
Барлығы біркелкі болуы үшін біз функционалдылықты бөлек қызметтерге бөлеміз. Осылайша біз қажетті құрамдастарды ғана масштабтай аламыз және құрамдастарды қарапайым ете аламыз. Басқа командаға бөлек компонентті тағайындау және онымен жұмыс істеу жауапкершілігін бөлісу оңай. Бұл тәсілмен темірді айтарлықтай үнемдеу - бұл айқын плюс.
Көлеңкелі кластер бізге де көмектеседі: біз қызметтерді дамыта аламыз, оларды процесте сынай аламыз және пайдаланушыны алаңдатпаймыз.
Әрине, өндірісте сынау. Мыңдаған серверлердегі конфигурацияны өзгерту керек пе? Оңай, Stop Tap түймесін пайдаланыңыз. Осылайша сіз дереу дайын кешенді шешімді шығарып, ақаулар туындаған жағдайда тұрақты нұсқаға орала аласыз.
Мен үнемі өсіп келе жатқан ұсыныстар базасымен нарықты қалай тез және тұрақты ететінімізді көрсете алдым деп үміттенемін. Біз сервер мәселелерін қалай шешеміз, көптеген сұраныстармен жұмыс істейміз, қызметтің икемділігін жақсартамыз және мұны жұмыс процестерін тоқтатпай жасаймыз.
Ақпарат көзі: www.habr.com