🥇Com vam sobreviure al fort augment de la càrrega de treball x10 mentre treballàvem a distància i quines conclusions vam treure

Hola Habr! Els darrers mesos hem viscut una situació molt interessant i m'agradaria compartir la nostra història d'escalada d'infraestructures. Durant aquest temps, SberMarket s'ha quadruplicat en comandes i ha llançat el servei a 4 ciutats noves. El creixement explosiu de la demanda de lliurament de queviures ens ha obligat a escalar la nostra infraestructura. Llegeix sobre les conclusions més interessants i útils sota el tall.

Em dic Dima Bobylev, sóc el director tècnic de SberMarket. Com que aquesta és la primera publicació al nostre blog, diré unes paraules sobre mi i l'empresa. La tardor passada vaig participar al concurs de joves líders de Runet. Per al concurs I va escriure una petita història sobre com veiem a SberMarket la cultura interna i l'enfocament del desenvolupament de serveis. I encara que no vaig aconseguir guanyar el concurs, em vaig formular els principis bàsics per al desenvolupament de l'ecosistema informàtic.

A l'hora de gestionar un equip, és important entendre i trobar un equilibri entre les necessitats del negoci i les necessitats de cada desenvolupador individual. Ara SberMarket creix 13 vegades a l'any, i això afecta el producte, que requereix un augment constant del volum i el ritme de desenvolupament. Malgrat això, dediquem prou temps als desenvolupadors per a l'anàlisi preliminar i la codificació d'alta qualitat. L'enfocament format ajuda no només a crear un producte de treball, sinó també a la seva escala i desenvolupament posteriors. Com a resultat d'aquest creixement, SberMarket ja s'ha convertit en líder entre els serveis de lliurament de queviures: entreguem unes 18 comandes al dia, tot i que a principis de febrer n'hi havia unes 3500.

Un dia, un client va demanar a un missatger de SberMarket que li entregués queviures sense contacte, just al balcó.

Però anem als detalls. Durant els últims mesos, hem estat ampliant activament la infraestructura de la nostra empresa. Aquesta necessitat s'explicava per factors externs i interns. Paral·lelament a l'ampliació de la base de clients, el nombre de botigues connectades va créixer de 90 a principis d'any a més de 200 a mitjans de maig. Per descomptat, ens vam preparar, vam reservar la infraestructura principal i vam comptar amb la possibilitat d'escalar vertical i horitzontal de totes les màquines virtuals allotjades al núvol Yandex. Tanmateix, la pràctica ha demostrat: "Tot el que pot sortir malament anirà malament". I avui vull compartir les situacions més curioses que han passat en aquestes setmanes. Espero que la nostra experiència us sigui útil.

Esclau en plena preparació per al combat

Fins i tot abans de l'inici de la pandèmia, ens vam enfrontar a un augment del nombre de sol·licituds als nostres servidors de fons. La tendència a demanar menjar amb lliurament a domicili va començar a agafar força i amb la introducció de les primeres mesures d'autoaïllament en relació amb la COVID-19, la càrrega va créixer espectacularment davant els nostres ulls al llarg del dia. Hi havia una necessitat de descarregar ràpidament els servidors mestres de la base de dades principal i transferir algunes de les sol·licituds de lectura als servidors de rèplica (esclau).

Ens estàvem preparant per a aquest pas amb antelació, i 2 servidors esclaus ja estaven en funcionament per a aquesta maniobra. Van treballar principalment en tasques per lots per generar fonts d'informació per intercanviar dades amb socis. Aquests processos van crear una càrrega addicional i, amb raó, es van treure dels parèntesis un parell de mesos abans.

Com que la replicació es va dur a terme a l'esclau, ens vam adherir al concepte que les aplicacions només poden funcionar amb elles en mode de només lectura. El Pla de Recuperació de Desastres suposava que, en cas de desastre, podríem simplement muntar l'Esclau en lloc del Mestre i canviar totes les sol·licituds d'escriptura i lectura a l'Esclau. Tanmateix, també volíem utilitzar rèpliques per a les necessitats del departament d'anàlisi, de manera que els servidors no estaven completament configurats per a l'estat de només lectura, i cada amfitrió tenia el seu propi conjunt d'usuaris, i alguns tenien permisos d'escriptura per desar resultats de càlcul intermedis.

Fins a un cert nivell de càrrega, teníem prou màster tant per escriure com per llegir en processar les sol·licituds http. A mitjans de març, just quan Sbermarket va decidir canviar completament al treball remot, vam començar a multiplicar el creixement de RPS. Cada cop són més els nostres clients que es van aïllar o treballar des de casa, cosa que es va reflectir en els indicadors de càrrega.

L'actuació del "mestre" ja no era suficient, així que vam començar a transferir algunes de les sol·licituds de lectura més pesades a la rèplica. Per dirigir de manera transparent les sol·licituds d'escriptura al mestre i les sol·licituds de lectura a l'esclau, hem utilitzat la joia rubí "Pop". Hem creat un usuari especial amb _readonly postfix sense permisos d'escriptura. Però a causa d'un error en la configuració d'un dels amfitrions, part de les peticions d'escriptura van anar al servidor esclau en nom d'un usuari que tenia els drets adequats.

El problema no es va manifestar immediatament, perquè. l'augment de la càrrega va augmentar l'endarreriment dels esclaus. La inconsistència de les dades es va descobrir al matí, quan, després de les importacions nocturnes, els esclaus no van "posar-se al dia" amb el mestre. Ho vam atribuir a una càrrega elevada del servei en si i de les importacions associades al llançament de noves botigues. Però era inacceptable donar dades amb un retard de moltes hores, i vam canviar els processos al segon esclau analític, perquè teniaоRecursos més grans i no es carregava amb sol·licituds de lectura (és així com ens vam explicar la manca de retard de replicació).

Quan vam esbrinar les raons de la "propagació" de l'esclau principal, l'analítica ja havia fracassat pel mateix motiu. Malgrat la presència de dos servidors addicionals, als quals teníem previst transferir la càrrega en cas d'un error principal, a causa d'un error desafortunat, va resultar que no n'hi havia cap en un moment crític.

Però com que no només vam bolcar la base de dades (la restauració en aquell moment va ser d'unes 5 hores), sinó també una instantània del servidor mestre, vam aconseguir llançar la rèplica en 2 hores. És cert que després d'això, s'esperava que enrotllem el registre de rèplica durant molt de temps (perquè el procés està en mode d'un sol fil, però aquesta és una història completament diferent).

Conclusió: Després d'aquest incident, va quedar clar que la pràctica de restringir les escriptures per als usuaris s'havia d'abandonar i que tot el servidor s'havia de declarar només de lectura. Amb aquest enfocament, podeu estar segur que les rèpliques estaran disponibles en un moment crític.

Optimitzar fins i tot una consulta pesada pot donar vida a la base de dades

Tot i que actualitzem constantment el catàleg al lloc, les sol·licituds que vam fer als servidors Slave van permetre un lleuger retard respecte al Mestre. El temps durant el qual vam descobrir i eliminar el problema dels esclaus "desviats de sobte" va ser més que la "barrera psicològica" (durant aquest temps, els preus es podien actualitzar i els clients veurien dades obsoletes), i ens vam veure obligats a canviar. totes les consultes al servidor de base de dades principal. Com a resultat, el lloc va ser lent... però almenys va funcionar. I mentre l'Esclau es recuperava, no ens quedava més que optimització.

Mentre els servidors esclaus es recuperaven, els minuts s'arrossegaven lentament, el Mestre es va mantenir sobrecarregat i vam dedicar tots els nostres esforços a optimitzar les tasques actives segons la Regla de Pareto: vam triar les consultes TOP que donen la major part de la càrrega i vam començar a ajustar. Això es va fer sobre la marxa.

Un efecte interessant va ser que MySQL, carregat als globus oculars, respon fins i tot a una lleugera millora dels processos. L'optimització d'un parell de consultes que només donaven el 5% de la càrrega total ja ha mostrat una descàrrega notable de la CPU. Com a resultat, vam poder proporcionar una reserva acceptable de recursos perquè el mestre treballés amb la base de dades i obtingués el temps necessari per restaurar les rèpliques.

Conclusió: Fins i tot una petita optimització us permet "sobreviure" a la sobrecàrrega durant diverses hores. Això ens va bastar per restaurar servidors amb rèpliques. Per cert, parlarem del vessant tècnic de l'optimització de consultes en una de les publicacions següents. Així que subscriu-te al nostre blog si et pot ser útil.

Organitzar el seguiment de la salut dels serveis associats

Processem comandes dels clients i, per tant, els nostres serveis interactuen constantment amb API de tercers: aquestes són passarel·les per enviar SMS, plataformes de pagament, sistemes d'encaminament, un geocodificador, el Servei Federal d'Impostos i molts altres sistemes. I quan la càrrega va començar a créixer ràpidament, vam començar a trobar-nos amb les limitacions de l'API dels nostres serveis associats, que ni tan sols havíem pensat abans.

Superar inesperadament les quotes de servei dels socis pot provocar el vostre propi temps d'inactivitat. Moltes API bloquegen clients que superen els límits i, en alguns casos, un excés de sol·licituds pot sobrecarregar la producció del soci.

Per exemple, en el moment del creixement del nombre de lliuraments, els serveis d'acompanyament no podien fer front a les tasques de la seva distribució i determinació de la ruta. En conseqüència, va resultar que les comandes estaven fetes, però el servei que va crear la ruta no funcionava. He de dir que els nostres logístics van fer el quasi impossible en aquestes condicions, i la clara interacció de l'equip va ajudar a compensar les falles temporals del servei. Però no és realista processar aquest volum d'aplicacions manualment tot el temps, i després d'un temps ens trobaríem amb una bretxa inacceptable entre les comandes i la seva execució.

Es van prendre diverses mesures organitzatives i el treball ben coordinat de l'equip va ajudar a guanyar temps mentre acordàvem noves condicions i esperàvem la modernització dels serveis d'alguns socis. Hi ha altres API que ofereixen una alta resistència i taxes impies en cas de trànsit elevat. Per exemple, al principi, vam utilitzar una API de mapes coneguda per determinar l'adreça del punt de lliurament. Però a finals de mes, van rebre una factura rodona per gairebé 2 milions de rubles. Després d'això, vam decidir substituir-lo ràpidament. No em dedicaré a la publicitat, però diré que les nostres despeses han disminuït considerablement.

Conclusió: És imprescindible controlar les condicions de treball de tots els serveis associats i tenir-les presents. Encara que avui sembli que estan “amb un gran marge” per a tu, això no vol dir que demà no es converteixin en un obstacle per al creixement. I, per descomptat, és millor acordar amb antelació les condicions financeres de l'augment de les sol·licituds del servei.

De vegades resulta queNecessita més or"(c) no ajuda

Estem acostumats a "gags" a la base de dades principal o als servidors d'aplicacions, però en escalar, poden aparèixer problemes on no s'esperaven. Per a la cerca de text complet al lloc, utilitzem el motor Apache Solr. A mesura que augmentava la càrrega, vam notar una disminució del temps de resposta i la càrrega de la CPU del servidor va arribar al 100%. El que podria ser més senzill: donar més recursos al contenidor Solr.

En lloc de l'augment esperat del rendiment, el servidor simplement "va morir". Immediatament es va carregar al 100% i va respondre encara més lentament. Al principi, teníem 2 nuclis i 2 GB de RAM. Vam decidir fer el que normalment ajuda: vam donar al servidor 8 nuclis i 32 GB. Tot va empitjorar molt (us explicarem exactament com i per què en una publicació a part).

En pocs dies, vam descobrir les complexitats d'aquest problema i vam aconseguir un rendiment òptim amb 8 nuclis i 32 GB. Aquesta configuració ens permet seguir augmentant la càrrega avui, la qual cosa és molt important, perquè el creixement no és només pel que fa als clients, sinó també al nombre de botigues connectades: en 2 mesos el seu nombre s'ha duplicat.

Conclusió: Els mètodes estàndard com "afegir més ferro" no sempre funcionen. Per tant, a l'hora d'escalar qualsevol servei, cal tenir una bona comprensió de com utilitza els recursos i provar-lo amb antelació, el seu funcionament en noves condicions.

Sense estat és la clau per a una escala horitzontal senzilla

En general, el nostre equip s'adhereix a un enfocament conegut: els serveis no han de tenir un estat intern (sense estat) i han de ser independents de l'entorn d'execució. Això ens va permetre sobreviure a l'augment de càrrega mitjançant un simple escalat horitzontal. Però teníem una excepció de servei: un controlador per a tasques llargues en segon pla. Va participar en l'enviament de correus electrònics i sms, el processament d'esdeveniments, la generació de fonts, la importació de preus i accions i el processament d'imatges. Va passar que depenia de l'emmagatzematge de fitxers local i estava en una sola còpia.

Quan el nombre de tasques a la cua del processador va augmentar (i això passava naturalment amb un augment del nombre de comandes), el rendiment de l'amfitrió que allotjava el processador i l'emmagatzematge de fitxers es va convertir en un factor limitant. Com a resultat, es va aturar l'actualització de la gamma i els preus, l'enviament de notificacions als usuaris i moltes altres funcions crítiques encallades a la cua. L'equip d'Ops va migrar ràpidament l'emmagatzematge de fitxers a l'emmagatzematge de xarxa semblant a S3, i això ens va permetre crear diverses màquines potents per escalar el gestor de tasques en segon pla.

Conclusió: La regla sense estat s'ha d'observar per a tots els components sense excepció, encara que sembli "que definitivament no descansarem aquí". És millor dedicar una mica de temps a l'organització correcta del treball de tots els sistemes que reescriure el codi amb pressa i arreglar un servei sobrecarregat.

7 principis per al creixement intensiu

Malgrat la disponibilitat de capacitat addicional, en el procés de creixement, vam trepitjar uns quants rastells. Durant aquest temps, el nombre de comandes va augmentar més de 4 vegades. Ara ja entreguem més de 17 comandes al dia a 000 ciutats i tenim previst ampliar encara més la geografia: durant el primer semestre del 62, s'espera que el servei es llançarà a tota Rússia. Per fer front a la creixent càrrega de treball, tenint en compte els cops ja plens, ens hem derivat 2020 principis bàsics per treballar en un entorn de creixement constant:

Gestió d'incidències. Hem creat un tauler a Jira, on cada incident es reflecteix en forma de bitllet. Això us ajudarà a prioritzar i completar les tasques relacionades amb incidents. De fet, en essència, no és terrible cometre errors; és terrible cometre errors dues vegades en la mateixa ocasió. Per a aquells casos en què els incidents es repeteixen abans que es pugui corregir la causa, s'han de preparar instruccions d'actuació, ja que durant una càrrega pesada és important reaccionar amb la velocitat del llamp.
Seguiment necessaris per a tots els elements de la infraestructura sense excepció. Va ser gràcies a ell que vam poder predir el creixement de la càrrega i escollir correctament els "colls d'ampolla" per prioritzar l'eliminació. El més probable és que, sota una càrrega elevada, tot allò que ni tan sols pensaves es trencarà o començarà a frenar. Per tant, el millor és crear noves alertes immediatament després de l'aparició de les primeres incidències per tal de controlar-les i anticipar-les.
Alertes correctes només cal amb un fort augment de càrrega. En primer lloc, han d'informar exactament què està trencat. En segon lloc, no hi hauria d'haver moltes alertes, ja que l'abundància d'alertes no crítiques porta a ignorar totes les alertes en general.
Les sol·licituds han de ser sense estat. Ens hem assegurat que no hi hauria d'haver excepcions a aquesta regla. Necessiteu una independència total de l'entorn d'execució. Per fer-ho, podeu emmagatzemar dades compartides en una base de dades o, per exemple, directament a S3. Millor encara, seguiu les regles. https://12factor.net. Durant un fort augment del temps, simplement no hi ha manera d'optimitzar el codi i haureu de fer front a la càrrega augmentant directament els recursos informàtics i l'escala horitzontal.
Quotes i rendiment dels serveis externs. Amb un creixement ràpid, el problema pot sorgir no només en la vostra infraestructura, sinó també en un servei extern. El més molest és quan això passa no per un fracàs, sinó per assolir quotes o límits. Per tant, els serveis externs haurien d'escalar tan bé com tu mateix.
Processos i cues separades. Això ajuda molt quan es produeix un endoll a una de les passarel·les. No hauríem trobat retards en la transmissió de dades si les cues completes d'enviament d'SMS no interferís en l'intercanvi de notificacions entre sistemes d'informació. I seria més fàcil augmentar el nombre de treballadors si treballessin per separat.
realitats financeres. Quan hi ha un creixement explosiu dels fluxos de dades, no hi ha temps per pensar en les tarifes i les subscripcions. Però cal recordar-los, sobretot si sou una empresa petita. El propietari de qualsevol API, així com el vostre proveïdor d'allotjament, pot establir una factura gran. Així que llegiu atentament els contractes.

Conclusió

No sense pèrdues, però hem sobreviscut a aquesta etapa, i avui intentem complir amb tots els principis trobats, i cada màquina té la capacitat d'augmentar fàcilment el rendiment x4 per fer front a algunes sorpreses.

En les publicacions següents, compartirem la nostra experiència d'investigar la caiguda del rendiment a Apache Solr, així com parlarem sobre l'optimització de consultes i com la interacció amb el Servei Federal d'Impostos ajuda a l'empresa a estalviar diners. Subscriu-te al nostre blog per no perdre't res, i digues-nos als comentaris si has tingut problemes similars durant el creixement del trànsit.