Hola, em dic Evgeniy. Treballo a la infraestructura de cerca Yandex.Market. Vull explicar a la comunitat Habr la cuina interior del Mercat, i tinc moltes coses a explicar. En primer lloc, com funciona la cerca de mercat, processos i arquitectura. Com tractem les situacions d'emergència: què passa si un servidor falla? Què passa si hi ha 100 servidors d'aquest tipus?
També aprendràs com implementem noves funcionalitats en un munt de servidors alhora. I com provem serveis complexos directament en producció, sense causar cap molèstia als usuaris. En general, com funciona la cerca de mercat perquè tothom s'ho passi bé.
Una mica de nosaltres: quin problema resolem
Quan introduïu text, cerqueu un producte per paràmetres o compareu preus en diferents botigues, totes les sol·licituds s'envien al servei de cerca. La cerca és el servei més gran del mercat.
Processem totes les sol·licituds de cerca: des dels llocs market.yandex.ru, beru.ru, el servei Supercheck, Yandex.Advisor, aplicacions mòbils. També incloem ofertes de productes als resultats de cerca a yandex.ru.
Per servei de cerca entenc no només la recerca en si, sinó també una base de dades amb totes les ofertes del Mercat. L'escala és aquesta: es processen més de mil milions de sol·licituds de cerca al dia. I tot ha de funcionar ràpidament, sense interrupcions i sempre produir el resultat desitjat.
Què és què: Arquitectura de mercat
Descriuré breument l'arquitectura actual del Mercat. Es pot descriure aproximadament amb el diagrama següent:
Suposem que ens ve una botiga associada. Diu que vull vendre una joguina: aquest gat malvat amb un xisclero. I un altre gat enfadat sense xiscleros. I només un gat. Aleshores, la botiga ha de preparar ofertes per a les quals cerqui el Mercat. La botiga genera un xml especial amb ofertes i comunica el camí a aquest xml a través de la interfície d'afiliats. Aleshores, l'indexador baixa periòdicament aquest xml, comprova si hi ha errors i desa tota la informació en una base de dades enorme.
Hi ha molts xmls guardats. A partir d'aquesta base de dades es crea un índex de cerca. L'índex s'emmagatzema en format intern. Després de crear l'índex, el servei Layout el carrega als servidors de cerca.
Com a resultat, un gat enfadat amb un xisclet apareix a la base de dades i l'índex del gat apareix al servidor.
Us explicaré com busquem un gat a la part sobre arquitectura de cerca.
Arquitectura de recerca de mercat
Vivim en un món de microserveis: cada sol·licitud entrant provoca moltes subconsultes i desenes de serveis participen en el seu processament. El diagrama en mostra només alguns:
Esquema simplificat de processament de sol·licituds
Cada servei té una cosa meravellosa: el seu propi equilibrador amb un nom únic:
L'equilibrador ens ofereix una major flexibilitat a l'hora de gestionar el servei: podeu, per exemple, apagar els servidors, que sovint es requereix per a les actualitzacions. L'equilibrador veu que el servidor no està disponible i redirigeix automàticament les sol·licituds a altres servidors o centres de dades. Quan s'afegeix o s'elimina un servidor, la càrrega es redistribueix automàticament entre els servidors.
El nom únic de l'equilibrador no depèn del centre de dades. Quan el servei A fa una sol·licitud a B, per defecte l'equilibrador B redirigeix la sol·licitud al centre de dades actual. Si el servei no està disponible o no existeix al centre de dades actual, la sol·licitud es redirigeix a altres centres de dades.
Un únic FQDN per a tots els centres de dades permet que el servei A s'abstracti completament de les ubicacions. La seva sol·licitud al servei B sempre es tramitarà. L'excepció és el cas quan el servei es troba a tots els centres de dades.
Però no tot és tan rosat amb aquest equilibrador: tenim un component intermedi addicional. L'equilibrador pot ser inestable i aquest problema es resol amb servidors redundants. També hi ha un retard addicional entre els serveis A i B. Però a la pràctica és inferior a 1 ms i per a la majoria de serveis això no és crític.
Fer front a l'inesperat: equilibri i resiliència del servei de cerca
Imagineu-vos que hi ha un col·lapse: heu de trobar un gat amb un grinyol, però el servidor es bloqueja. O 100 servidors. Com sortir? De veritat deixarem l'usuari sense gat?
La situació fa por, però estem preparats per a això. T'ho diré per ordre.
La infraestructura de cerca es troba en diversos centres de dades:
A l'hora de dissenyar, incloem la possibilitat de tancar un centre de dades. La vida està plena de sorpreses: per exemple, una excavadora pot tallar un cable subterrani (sí, això va passar). La capacitat dels centres de dades restants hauria de ser suficient per suportar la càrrega màxima.
Considerem un únic centre de dades. Cada centre de dades té el mateix esquema de funcionament de l'equilibrador:
Un equilibrador són almenys tres servidors físics. Aquesta redundància està feta per a la fiabilitat. Els equilibradors funcionen amb HAProx.
Hem escollit HAProx pel seu alt rendiment, els baixos requisits de recursos i la seva àmplia funcionalitat. El nostre programari de cerca s'executa dins de cada servidor.
La probabilitat que un servidor falli és baixa. Però si teniu molts servidors, augmenta la probabilitat que almenys un caigui.
Això és el que passa en realitat: els servidors s'estavellen. Per tant, cal controlar constantment l'estat de tots els servidors. Si el servidor deixa de respondre, es desconnecta automàticament del trànsit. Amb aquest propòsit, HAProxy té un control de salut integrat. Va a tots els servidors una vegada per segon amb una sol·licitud HTTP "/ping".
Una altra característica d'HAProxy: agent-check us permet carregar tots els servidors de manera uniforme. Per fer-ho, HAProxy es connecta a tots els servidors, i aquests retornen el seu pes en funció de la càrrega actual d'1 a 100. El pes es calcula en funció del nombre de peticions a la cua de processament i de la càrrega del processador.
Ara per trobar el gat. La cerca dóna com a resultat sol·licituds com: /search?text=angry+cat. Perquè la cerca sigui ràpida, tot l'índex del gat ha d'encaixar a la memòria RAM. Fins i tot llegir des de l'SSD no és prou ràpid.
Hi havia una vegada, la base de dades d'ofertes era petita i la memòria RAM d'un servidor n'hi havia prou. A mesura que la base d'oferta va créixer, tot ja no encaixava en aquesta memòria RAM i les dades es van dividir en dues parts: fragment 1 i fragment 2.
Però això passa sempre: qualsevol solució, encara que sigui bona, dóna lloc a altres problemes.
L'equilibrador encara va anar a qualsevol servidor. Però a la màquina on va arribar la sol·licitud, només hi havia la meitat de l'índex. La resta era en altres servidors. Per tant, el servidor havia d'anar a alguna màquina veïna. Després de rebre dades dels dos servidors, els resultats es van combinar i es van tornar a classificar.
Com que l'equilibrador distribueix les sol·licituds de manera uniforme, tots els servidors es van dedicar a reclassificar i no només enviant dades.
El problema s'ha produït si un servidor veí no estava disponible. La solució va ser especificar diversos servidors amb diferents prioritats com a servidor "veí". Primer, la sol·licitud es va enviar als servidors del bastidor actual. Si no hi havia resposta, la sol·licitud es va enviar a tots els servidors d'aquest centre de dades. I, finalment, la petició va anar a altres centres de dades.
A mesura que augmentava el nombre de propostes, les dades es van dividir en quatre parts. Però aquest no era el límit.
Actualment, s'utilitza una configuració de vuit fragments. A més, per estalviar encara més memòria, l'índex es va dividir en una part de cerca (que s'utilitza per a la cerca) i una part de fragments (que no participa en la cerca).
Un servidor conté informació només per a un fragment. Per tant, per cercar l'índex complet, cal cercar en vuit servidors que contenen fragments diferents.
Els servidors s'agrupen en clústers. Cada clúster conté vuit motors de cerca i un servidor de fragments.
El servidor de fragments executa una base de dades de clau-valor amb dades estàtiques. Són necessaris per emetre documents, per exemple, una descripció d'un gat amb un xirridor. Les dades es transfereixen especialment a un servidor separat per no carregar la memòria dels servidors de cerca.
Com que els identificadors dels documents només són únics dins d'un índex, es podria produir una situació en què no hi hagi documents als fragments. Bé, o que per a un identificador hi haurà contingut diferent. Per tant, perquè la cerca funcionés i es retornessin resultats, calia coherència a tot el clúster. A continuació us explicaré com controlem la coherència.
La cerca en si s'estructura de la següent manera: una sol·licitud de cerca pot arribar a qualsevol dels vuit servidors. Suposem que va arribar al servidor 1. Aquest servidor processa tots els arguments i entén què i com buscar. En funció de la sol·licitud entrant, el servidor pot fer peticions addicionals a serveis externs per obtenir la informació necessària. Una sol·licitud pot anar seguida de fins a deu peticions a serveis externs.
Després de recollir la informació necessària, s'inicia una cerca a la base de dades d'ofertes. Per fer-ho, es fan subconsultes als vuit servidors del clúster.
Un cop rebudes les respostes, es combinen els resultats. Al final, poden ser necessàries diverses subconsultes més al servidor de fragments per generar els resultats.
Les consultes de cerca dins del clúster semblen: /shard1?text=angry+cat. A més, les subconsultes del formulari es fan constantment entre tots els servidors del clúster una vegada per segon: /estat.
Sol·licitud /estat detecta una situació en què el servidor no està disponible.
També controla que la versió del motor de cerca i la versió de l'índex siguin iguals a tots els servidors, en cas contrari, hi haurà dades inconsistents dins del clúster.
Malgrat que un servidor de fragments processa les sol·licituds de vuit motors de cerca, el seu processador es carrega molt lleugerament. Per tant, ara estem transferint les dades del fragment a un servei independent.
Per transferir dades, hem introduït claus universals per als documents. Ara és impossible una situació en què el contingut d'un altre document es retorna amb una clau.
Però la transició a una altra arquitectura encara no s'ha acabat. Ara volem desfer-nos del servidor de fragments dedicat. I després allunyar-se de l'estructura del clúster. Això ens permetrà continuar escalant fàcilment. Un avantatge addicional és un estalvi important de ferro.
I ara a històries de por amb final feliç. Considerem diversos casos de no disponibilitat del servidor.
Va passar una cosa terrible: un servidor no està disponible
Suposem que un servidor no està disponible. Aleshores, els servidors restants del clúster poden continuar responent, però els resultats de la cerca seran incomplets.
Mitjançant la comprovació d'estat /estat els servidors veïns entenen que un no està disponible. Per tant, per mantenir la integritat, tots els servidors del clúster per sol·licitud /ping comencen a respondre a l'equilibrador que tampoc no estan disponibles. Resulta que tots els servidors del clúster van morir (que no és cert). Aquest és el principal inconvenient del nostre esquema de clústers; per això en volem allunyar-nos.
Les sol·licituds que fallen amb un error són reenviades pel equilibrador a altres servidors.
L'equilibrador també deixa d'enviar trànsit d'usuaris als servidors morts, però continua comprovant el seu estat.
Quan el servidor està disponible, comença a respondre /ping. Tan bon punt comencen a arribar les respostes normals als pings dels servidors morts, els equilibradors comencen a enviar trànsit d'usuaris allà. S'ha restablert el funcionament del clúster, hurra.
Encara pitjor: molts servidors no estan disponibles
Una part important dels servidors del centre de dades es redueixen. Què fer, on córrer? L'equilibrador torna al rescat. Cada equilibrador emmagatzema constantment a la memòria el nombre actual de servidors en directe. Calcula constantment la quantitat màxima de trànsit que pot processar el centre de dades actual.
Quan molts servidors d'un centre de dades cauen, l'equilibrador s'adona que aquest centre de dades no pot processar tot el trànsit.
Aleshores, l'excés de trànsit comença a distribuir-se aleatòriament a altres centres de dades. Tot funciona, tothom està content.
Com ho fem: publicació de comunicats
Ara parlem de com publiquem els canvis fets al servei. Aquí hem pres el camí de la simplificació dels processos: el llançament d'una nova versió està gairebé completament automatitzat.
Quan s'acumulen un nombre determinat de canvis al projecte, es crea automàticament una nova versió i s'inicia la seva compilació.
A continuació, el servei es desplega fins a proves, on es comprova l'estabilitat del funcionament.
Al mateix temps, s'inicien les proves automàtiques de rendiment. Això s'encarrega d'un servei especial. No en parlaré ara: la seva descripció mereix un article a part.
Si la publicació en proves té èxit, la publicació de la versió en prestable s'inicia automàticament. Prestable és un clúster especial on es dirigeix el trànsit normal dels usuaris. Si retorna un error, l'equilibrador fa una nova sol·licitud a producció.
En prestable, els temps de resposta es mesuren i es comparen amb la versió anterior en producció. Si tot està bé, llavors una persona es connecta: comprova els gràfics i els resultats de les proves de càrrega i després comença a llançar-se a la producció.
Tot el millor va per a l'usuari: proves A/B
No sempre és obvi si els canvis en un servei aportaran beneficis reals. Per mesurar la utilitat dels canvis, la gent va fer proves A/B. Us explicaré una mica com funciona a Yandex.Market Search.
Tot comença amb l'addició d'un nou paràmetre CGI que permet una nova funcionalitat. Sigui el nostre paràmetre: market_new_functionality=1. Aleshores, al codi habilitem aquesta funcionalitat si la bandera està present:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}S'està implementant una nova funcionalitat a la producció.
Per automatitzar les proves A/B, hi ha un servei dedicat que detalla . Es crea un experiment al servei. La quota de trànsit s'estableix, per exemple, en un 15%. Els percentatges no s'estableixen per a consultes, sinó per als usuaris. També s'indica la durada de l'experiment, per exemple, una setmana.
Es poden fer diversos experiments simultàniament. A la configuració podeu especificar si la intersecció amb altres experiments és possible.
Com a resultat, el servei afegeix automàticament un argument market_new_functionality=1 al 15% dels usuaris. També calcula automàticament les mètriques seleccionades. Un cop finalitzat l'experiment, els analistes miren els resultats i treuen conclusions. A partir de les conclusions, es pren la decisió de llançar-se a producció o perfeccionament.
La mà hàbil del mercat: proves en producció
Sovint passa que necessiteu provar el funcionament d'una nova funcionalitat en producció, però no esteu segur de com es comportarà en condicions de "combat" amb una càrrega pesada.
Hi ha una solució: els indicadors dels paràmetres CGI es poden utilitzar no només per a proves A/B, sinó també per provar noves funcionalitats.
Hem creat una eina que us permet canviar instantàniament la configuració de milers de servidors sense exposar el servei a riscos. Es diu Stop Tap. La idea original era poder desactivar ràpidament algunes funcionalitats sense disseny. Aleshores, l'eina es va expandir i es va fer més complexa.
El diagrama de flux del servei es presenta a continuació:
Els valors dels senyaladors s'estableixen mitjançant l'API. El servei de gestió emmagatzema aquests valors a la base de dades. Tots els servidors van a la base de dades una vegada cada deu segons, extreuen els valors de la bandera i apliquen aquests valors a cada sol·licitud.
Al toc Atura podeu establir dos tipus de valors:
1) Expressions condicionals. Aplicar quan un dels valors és cert. Per exemple:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}El valor "3" s'aplicarà quan la sol·licitud es processi a la ubicació DC1. I el valor és "4" quan la sol·licitud es processa al segon clúster del lloc beru.ru.
2) Valors incondicionals. Aplica de manera predeterminada si no es compleix cap de les condicions. Per exemple:
valor, valor!
Si un valor acaba amb un signe d'exclamació, se li dóna una prioritat més alta.
L'analitzador de paràmetres CGI analitza l'URL. A continuació, aplica els valors de Stop Tap.
S'apliquen valors amb les prioritats següents:
- Amb una prioritat augmentada de Stop Tap (signe d'exclamació).
- El valor de la sol·licitud.
- Valor per defecte de Atura el toc.
- Valor predeterminat al codi.
Hi ha moltes banderes que s'indiquen en valors condicionals: són suficients per a tots els escenaris que coneixem:
- Centre de dades.
- Entorn: producció, proves, ombra.
- Lloc: mercat, beru.
- Número de clúster.
Amb aquesta eina, podeu habilitar noves funcionalitats en un determinat grup de servidors (per exemple, en un sol centre de dades) i provar el funcionament d'aquesta funcionalitat sense cap risc particular per a tot el servei. Fins i tot si vau cometre un error greu en algun lloc, tot va començar a caure i tot el centre de dades va caure, els equilibradors redirigiran les sol·licituds a altres centres de dades. Els usuaris finals no notaran res.
Si observeu un problema, podeu tornar immediatament el senyalador al seu valor anterior i els canvis es revertiran.
Aquest servei també té els seus inconvenients: els desenvolupadors l'estimen molt i sovint intenten empènyer tots els canvis a Stop Tap. Estem intentant combatre el mal ús.
L'enfocament Stop Tap funciona bé quan ja teniu un codi estable a punt per ser llançat a producció. Al mateix temps, encara teniu dubtes i voleu comprovar el codi en condicions de "combat".
Tanmateix, Stop Tap no és adequat per a proves durant el desenvolupament. Hi ha un clúster separat per als desenvolupadors anomenat "clúster d'ombra".
Prova secreta: Shadow Cluster
Les sol·licituds d'un dels clústers es dupliquen al clúster ombra. Però l'equilibrador ignora completament les respostes d'aquest clúster. A continuació es presenta el diagrama del seu funcionament.
Obtenim un clúster de prova que es troba en condicions reals de "combat". El trànsit normal d'usuaris hi va. El maquinari dels dos clústers és el mateix, de manera que es poden comparar el rendiment i els errors.
I com que l'equilibrador ignora completament les respostes, els usuaris finals no veuran les respostes del clúster d'ombra. Per tant, no fa por cometre un error.
Troballes
Aleshores, com hem creat la cerca de mercat?
Perquè tot vagi bé, separem la funcionalitat en serveis separats. D'aquesta manera només podem escalar els components que necessitem i fer-los més senzills. És fàcil assignar un component independent a un altre equip i compartir les responsabilitats per treballar-hi. I un estalvi important en ferro amb aquest enfocament és un avantatge evident.
El clúster d'ombra també ens ajuda: podem desenvolupar serveis, provar-los en el procés i no molestar l'usuari.
Bé, proves en producció, és clar. Necessites canviar la configuració de milers de servidors? Fàcil, utilitzeu Stop Tap. D'aquesta manera, podeu llançar immediatament una solució complexa ja feta i tornar a una versió estable si sorgeixen problemes.
Espero haver pogut mostrar com fem que el Mercat sigui ràpid i estable amb una base d'ofertes en constant creixement. Com resolem problemes del servidor, tractem un gran nombre de peticions, millorem la flexibilitat del servei i ho fem sense interrompre els processos de treball.
Font: www.habr.com