Hoe we de sterke toename van de x10-belasting op afstand hebben overleefd en welke conclusies we hebben getrokken

Hallo, Habr! We leven de afgelopen maanden in een zeer interessante situatie en ik wil graag ons verhaal over de schaalvergroting van de infrastructuur delen. Gedurende deze tijd is SberMarket vier keer gegroeid in bestellingen en heeft de dienst in 4 nieuwe steden gelanceerd. De explosieve groei van de vraag naar boodschappenbezorging vereiste dat we onze infrastructuur moesten opschalen. Lees over de interessantste en nuttigste conclusies onder de rubriek.

Mijn naam is Dima Bobylev, ik ben de technisch directeur van SberMarket. Aangezien dit het eerste bericht op onze blog is, zal ik een paar woorden zeggen over mezelf en het bedrijf. Afgelopen najaar heb ik deelgenomen aan een wedstrijd voor jonge Runet-leiders. Voor de wedstrijd I schreef een kort verhaal over hoe wij bij SberMarket de interne cultuur en aanpak van serviceontwikkeling zien. En hoewel het mij niet lukte om de wedstrijd te winnen, formuleerde ik voor mezelf de basisprincipes voor de ontwikkeling van het IT-ecosysteem.

Bij het aansturen van een team is het belangrijk om te begrijpen en een balans te vinden tussen wat het bedrijf nodig heeft en de behoeften van elke individuele ontwikkelaar. Nu groeit SberMarket 13 keer per jaar, en dit heeft invloed op het product, waardoor het voortdurend het volume en het ontwikkelingstempo moet verhogen. Desondanks besteden we voldoende tijd aan ontwikkelaars voor voorlopige analyses en kwaliteitscodering. De gevormde aanpak helpt niet alleen bij het creëren van een werkend product, maar ook bij de verdere opschaling en ontwikkeling ervan. Door deze groei is SberMarket nu al toonaangevend onder de boodschappenbezorgdiensten: we bezorgen dagelijks zo'n 18 bestellingen per dag, terwijl dat er begin februari nog zo'n 3500 waren.

Op een dag vroeg een klant een koerier van SberMarket om boodschappen contactloos bij hem af te leveren, tot op het balkon

Maar laten we verder gaan met de details. De afgelopen maanden hebben we de infrastructuur van ons bedrijf actief opgeschaald. Deze behoefte werd verklaard door externe en interne factoren. Samen met de uitbreiding van het klantenbestand groeide het aantal aangesloten winkels van 90 begin dit jaar naar ruim 200 medio mei. We waren natuurlijk voorbereid, reserveerden de hoofdinfrastructuur, en we rekenden op de mogelijkheid van verticale en horizontale schaalvergroting van alle virtuele machines die in de Yandex-cloud worden gehost. De praktijk leert echter: “Alles wat fout kan gaan, zal fout gaan.” En vandaag wil ik de meest interessante situaties delen die zich de afgelopen weken hebben voorgedaan. Ik hoop dat onze ervaring nuttig voor u zal zijn.

Slave is volledig gevechtsgereed

Al vóór het begin van de pandemie werden we geconfronteerd met een toename van het aantal verzoeken aan onze backend-servers. De trend om boodschappen te bestellen voor thuisbezorging begon aan kracht te winnen, en met de introductie van de eerste zelfisolatiemaatregelen als gevolg van COVID-19 groeide de werkdruk in de loop van de dag dramatisch. Er was behoefte om de masterservers van de hoofddatabase snel te ontladen en een deel van de leesverzoeken over te dragen naar replicaservers (slave).

We hadden ons van tevoren op deze stap voorbereid en er waren al 2 slave-servers gelanceerd voor een dergelijke manoeuvre. Ze werden voornamelijk gebruikt voor batchtaken voor het genereren van informatiefeeds voor het uitwisselen van gegevens met partners. Deze processen zorgden voor een extra last en werden een paar maanden eerder terecht buiten beschouwing gelaten. 

Omdat replicatie op de Slave plaatsvond, hielden we ons aan het concept dat applicaties er alleen mee konden werken in de alleen-lezen-modus. Het Disaster Recovery Plan ging ervan uit dat we in het geval van een ramp eenvoudigweg de Slave in plaats van de Master konden mounten en alle schrijf- en leesverzoeken naar de Slave konden overzetten. We wilden echter ook replica's gebruiken voor de behoeften van de analyseafdeling, dus de servers werden niet volledig overgeschakeld naar de status Alleen lezen, maar elke host had zijn eigen set gebruikers en sommige hadden schrijfrechten om tussentijdse berekeningsresultaten op te slaan.

Tot een bepaald belastingsniveau hadden we voldoende master voor zowel schrijven als lezen bij het verwerken van http-verzoeken. Half maart, net toen Sbermarket besloot volledig over te schakelen op werken op afstand, begon onze RPS exponentieel te groeien. Steeds meer van onze klanten gingen in zelfisolatie of werkten vanuit huis, wat van invloed was op onze werkdrukindicatoren.

De prestaties van de 'master' waren niet langer voldoende, dus begonnen we enkele van de zwaarste leesverzoeken over te dragen naar de replica. Om schrijfverzoeken transparant naar de master te routeren en leesverzoeken naar de slaaf te sturen, hebben we de robijnrode edelsteen gebruikt "Octopus" We hebben een speciale gebruiker gemaakt met de postfix _readonly zonder schrijfrechten. Maar door een fout in de configuratie van een van de hosts gingen sommige schrijfverzoeken naar de slaveserver namens een gebruiker die over de juiste rechten beschikte.

Het probleem manifesteerde zich niet onmiddellijk, omdat... de toegenomen belasting verhoogde de vertraging van de slaven. De inconsistentie van de gegevens werd 's ochtends ontdekt toen de slaven, na nachtelijke import, de meester niet "inhaalden". We schreven dit toe aan de hoge belasting van de service zelf en de import die gepaard ging met de lancering van nieuwe winkels. Maar het verzenden van gegevens met een vertraging van meerdere uren was onaanvaardbaar, en we schakelden processen over naar de tweede analytische slaaf, omdat deze eenоgrotere bronnen en was niet geladen met leesverzoeken (zo hebben we onszelf het gebrek aan replicatievertraging uitgelegd).

Toen we de redenen voor de ‘verspreiding’ van de hoofdslaaf ontdekten, was de analytische om dezelfde reden al mislukt. Ondanks de aanwezigheid van twee extra servers waarnaar we van plan waren de belasting over te dragen in het geval van een masterstoring, bleek door een ongelukkige fout dat er op het kritieke moment geen beschikbaar was.

Maar omdat we niet alleen de database dumpten (het herstelproces duurde destijds ongeveer 5 uur), maar ook een momentopname van de masterserver, slaagden we erin om de replica binnen 2 uur te lanceren. Toegegeven, hierna werden we geconfronteerd met het feit dat het replicatielogboek lange tijd doorrolde (omdat het proces in single-threaded-modus draait, maar dat is een heel ander verhaal).

Conclusie: Na een dergelijk incident werd het duidelijk dat het nodig was om de praktijk van het beperken van het schrijven voor gebruikers op te geven en de hele server alleen-lezen te verklaren. Met deze aanpak bestaat er geen twijfel over dat replica’s op kritieke momenten beschikbaar zullen zijn.

Het optimaliseren van zelfs één zware query kan de database weer tot leven brengen

Hoewel we de catalogus op de site voortdurend bijwerken, zorgden de verzoeken die we naar de Slave-servers stuurden voor een kleine vertraging van de Master. De tijd waarin we het probleem ontdekten en elimineerden van slaven die “plotseling de afstand verlieten” was meer dan de “psychologische barrière” (gedurende deze tijd hadden de prijzen kunnen worden bijgewerkt en zouden klanten verouderde gegevens hebben gezien), en we werden gedwongen om schakel alle verzoeken over naar de hoofddatabaseserver. Als gevolg hiervan was de site traag... maar hij werkte tenminste. En terwijl Slave herstelde, hadden we geen andere keuze dan optimalisatie. 

Terwijl de Slave-servers zich herstelden, gingen de minuten langzaam voorbij, de Master bleef overbelast en we hebben al onze inspanningen gestoken in het optimaliseren van actieve taken volgens de “Pareto-regel”: we selecteerden de TOP-verzoeken die het grootste deel van de belasting genereren en begonnen met het afstemmen . Dit werd ter plekke gedaan.

Een interessant effect was dat MySQL, als het vol zat, reageerde op zelfs een kleine verbetering van de processen. Het optimaliseren van een aantal zoekopdrachten die slechts 5% van de totale belasting opleverden, heeft al een merkbare CPU-belasting laten zien. Als gevolg hiervan konden we de Master een acceptabel aanbod van middelen bieden om met de database te werken en de nodige tijd verkrijgen om replica's te herstellen. 

Conclusie: Zelfs met een kleine optimalisatie kunt u enkele uren onder overbelasting ‘overleven’. Dit was voor ons net genoeg om de servers met replica’s te herstellen. Overigens zullen we de technische kant van query-optimalisatie bespreken in een van de volgende berichten. Abonneer u dus op onze blog als u dit nuttig vindt.

Organiseer monitoring van de prestaties van partnerdiensten

We verwerken bestellingen van klanten en daarom communiceren onze diensten voortdurend met API's van derden - dit zijn gateways voor het verzenden van sms-berichten, betalingsplatforms, routeringssystemen, geocoder, federale belastingdienst en vele andere systemen. En toen de belasting snel begon te groeien, liepen we tegen API-beperkingen van onze partnerdiensten aan, waar we nog niet eens aan hadden gedacht.

Het onverwacht overschrijden van de quota's van partnerservices kan leiden tot eigen downtime. Veel API's blokkeren clients die de limieten overschrijden, en in sommige gevallen kunnen te veel verzoeken de productie van een partner overbelasten. 

Toen het aantal leveringen bijvoorbeeld groeide, konden de begeleidende diensten de taken van de distributie ervan en het bepalen van routes niet aan. Als gevolg hiervan bleek dat er bestellingen waren gedaan, maar de service die de route maakte, werkte niet. Het moet gezegd worden dat onze logistieke medewerkers onder deze omstandigheden het bijna onmogelijke deden, en de duidelijke interactie van het team hielp bij het compenseren van tijdelijke servicestoringen. Maar het is onrealistisch om een ​​dergelijk volume aan orders voortdurend handmatig te verwerken, en na enige tijd zouden we te maken krijgen met een onaanvaardbare kloof tussen orders en de uitvoering ervan. 

Er werden een aantal organisatorische maatregelen genomen en het goed gecoördineerde werk van het team hielp tijd te winnen terwijl we nieuwe voorwaarden overeenkwamen en wachtten op de modernisering van de diensten van sommige partners. Er zijn andere API's die beschikken over een hoog uithoudingsvermogen en buitensporige tarieven bij veel verkeer. Zo gebruikten we in het begin één bekende mapping API om het adres van het afleverpunt te bepalen. Maar aan het einde van de maand ontvingen we een nette rekening van bijna 2 miljoen roebel. Daarna besloten ze om het snel te vervangen. Ik ga niet adverteren, maar ik wil wel zeggen dat onze uitgaven aanzienlijk zijn gedaald.

Conclusie: Het is absoluut noodzakelijk om de bedrijfsomstandigheden van alle partnerdiensten te controleren en in gedachten te houden. Ook al lijkt het er vandaag op dat ze “met een grote marge” voor je zijn, dit betekent niet dat ze morgen geen obstakel voor de groei zullen worden. En het is natuurlijk beter om vooraf overeenstemming te bereiken over de financiële voorwaarden van verhoogde aanvragen voor de dienst. 

Soms blijkt dat "Meer goud nodig"(c) helpt niet

We zijn gewend aan 'grags' in de hoofddatabase of op applicatieservers, maar bij het schalen kunnen er problemen optreden waar ze niet werden verwacht. Voor zoeken in de volledige tekst op de site gebruiken we de Apache Solr-engine. Naarmate de belasting toenam, merkten we een afname van de responstijd en bereikte de belasting van de serverprocessor al 100%. Wat is er eenvoudiger: laten we de container met Solr meer middelen geven.

In plaats van de verwachte prestatieverbetering, stierf de server eenvoudigweg. Het laadde onmiddellijk op 100% en reageerde nog langzamer. Aanvankelijk hadden we 2 cores en 2 GB RAM. We besloten te doen wat gewoonlijk helpt: we gaven de server 8 cores en 32 GB. Alles werd nog veel erger (we zullen je precies vertellen hoe en waarom in een aparte post). 

In de loop van een paar dagen hebben we de fijne kneepjes van dit probleem ontdekt en optimale prestaties bereikt met 8 cores en 32 GB. Met deze configuratie kunnen we de belasting vandaag de dag blijven verhogen, wat erg belangrijk is, omdat de groei niet alleen in klanten zit, maar ook in het aantal aangesloten winkels - in 2 maanden tijd is hun aantal verdubbeld. 

Conclusie: Standaardmethoden zoals ‘meer ijzer toevoegen’ werken niet altijd. Wanneer u een dienst opschaalt, moet u dus goed begrijpen hoe deze resources gebruikt en de werking ervan vooraf in nieuwe omstandigheden testen. 

Staatloos is de sleutel tot gemakkelijke horizontale schaalvergroting

Over het algemeen volgt ons team een ​​bekende aanpak: services mogen geen interne status (stateless) hebben en moeten onafhankelijk zijn van de uitvoeringsomgeving. Hierdoor konden we de groei van de belasting opvangen door simpelweg horizontaal te schalen. Maar we hadden één uitzonderingsservice: een handler voor lange achtergrondtaken. Hij hield zich bezig met het versturen van e-mail en sms, het verwerken van events, het genereren van feeds, het importeren van prijzen en voorraden, en het verwerken van beelden. Het gebeurde zo dat het afhankelijk was van lokale bestandsopslag en zich in één enkele kopie bevond. 

Toen het aantal taken in de wachtrij van de processor toenam (en dit gebeurde uiteraard met een toename van het aantal bestellingen), werden de prestaties van de host waarop de processor en de bestandsopslag zich bevonden een beperkende factor. Als gevolg hiervan stopten het bijwerken van het assortiment en de prijzen, het verzenden van meldingen naar gebruikers en vele andere kritische functies die vastzaten in de wachtrij. Het Ops-team migreerde snel de bestandsopslag naar S3-achtige netwerkopslag, en dit stelde ons in staat verschillende krachtige machines op te zetten om de achtergrondtaakprocessor te schalen.

Conclusie: De staatloze regel moet zonder uitzondering voor alle componenten worden nageleefd, ook al lijkt het erop dat “we hier absoluut geen weerstand kunnen bieden.” Het is beter om wat tijd te besteden aan het goed organiseren van de werking van alle systemen dan om haastig de code te herschrijven en een overbelaste service te repareren.

7 principes voor intensieve groei

Ondanks de beschikbaarheid van extra capaciteit zijn we in het groeiproces op verschillende fouten gestapt. Gedurende deze tijd is het aantal bestellingen meer dan vier keer toegenomen. Nu bezorgen we al meer dan 4 bestellingen per dag in 17 steden en zijn we van plan de geografische regio nog verder uit te breiden - in de eerste helft van 000 zal de dienst naar verwachting in heel Rusland worden gelanceerd. Om de groeiende werkdruk het hoofd te bieden, rekening houdend met onze toch al volle kegels, hebben we 62 basisprincipes ontwikkeld voor het werken in omstandigheden van constante groei:

1. Probleembehandeling. We hebben in Jira een bord gemaakt, waarop elk incident wordt weergegeven in de vorm van een ticket. Dit zal helpen bij het daadwerkelijk prioriteren en uitvoeren van incidentgerelateerde taken. In wezen is het immers niet eng om fouten te maken, maar wel om twee keer bij dezelfde gelegenheid fouten te maken. Voor die gevallen waarin incidenten zich herhalen voordat de oorzaak kan worden verholpen, moeten er handelingsinstructies klaar liggen, want in tijden van zware belasting is het belangrijk om bliksemsnel te reageren.
2. controle zonder uitzondering vereist voor alle infrastructuurelementen. Dankzij hem konden we de groei van de last voorspellen en de ‘knelpunten’ correct selecteren om prioriteit te geven aan de eliminatie. Hoogstwaarschijnlijk zal onder hoge belasting alles waar je nog nooit aan hebt gedacht, kapot gaan of beginnen te vertragen. Daarom kunt u het beste direct na de eerste incidenten nieuwe waarschuwingen aanmaken, zodat u deze kunt monitoren en erop kunt anticiperen.
3. Correcte waarschuwingen eenvoudigweg nodig als de belasting sterk toeneemt. Eerst moeten ze melden wat er precies kapot is. Ten tweede mogen er niet veel waarschuwingen zijn, omdat de overvloed aan niet-kritieke waarschuwingen ertoe leidt dat alle waarschuwingen geheel worden genegeerd.
4. Aanvragen moeten staatloos zijn. Wij zijn ervan overtuigd dat er geen uitzonderingen op deze regel mogen bestaan. We hebben volledige onafhankelijkheid van de runtime-omgeving nodig. Hiervoor kunt u gedeelde gegevens opslaan in een database of bijvoorbeeld direct in S3. Beter nog: volg de regels. https://12factor.net. Tijdens een sterke toename van de tijd is er eenvoudigweg geen manier om de code te optimaliseren, en je zult de belasting moeten opvangen door de computerbronnen en horizontale schaalvergroting direct te vergroten.
5. Quota en prestaties van externe services. Bij snelle groei kan er niet alleen een probleem ontstaan ​​in uw infrastructuur, maar ook in een externe dienst. Het meest vervelende is wanneer dit niet gebeurt vanwege een mislukking, maar vanwege het bereiken van quota of limieten. Externe diensten moeten dus net zo goed schalen als u. 
6. Afzonderlijke processen en wachtrijen. Dit helpt enorm als er een blokkade is bij een van de gateways. We zouden geen vertragingen in de gegevensoverdracht hebben ondervonden als de volledige wachtrijen voor het verzenden van sms-berichten de uitwisseling van meldingen tussen informatiesystemen niet hadden verstoord. En het zou gemakkelijker zijn om het aantal werknemers uit te breiden als ze afzonderlijk zouden werken.
7. Financiële realiteit. Bij een explosieve groei van datastromen is er geen tijd om na te denken over tarieven en abonnementen. Maar u moet ze onthouden, vooral als u een klein bedrijf bent. Zowel de eigenaar van een API als uw hostingprovider kunnen een hoge rekening krijgen. Daarom moet u contracten zorgvuldig lezen.

Conclusie

Niet zonder verliezen, maar we hebben deze fase overleefd, en vandaag proberen we ons aan alle gevonden principes te houden, en elke machine heeft de mogelijkheid om de x4-prestaties gemakkelijk te verhogen om met enkele onverwachte gebeurtenissen om te gaan. 

In de volgende berichten zullen we onze ervaringen delen met het onderzoeken van prestatieverslechtering in Apache Solr, en ook praten over het optimaliseren van zoekopdrachten en hoe interactie met de federale belastingdienst het bedrijf helpt geld te besparen. Abonneer u op onze blog, zodat u niets mist, en vertel ons in de reacties of u soortgelijke problemen heeft gehad tijdens de groei van het verkeer.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Heeft u ooit een vertraging/afname van de service ervaren als gevolg van een sterke toename van de belasting als gevolg van:

• 55,6%Onvermogen om snel computerbronnen toe te voegen10

• 16,7%Infrastructuurlimieten van hostingproviders3

• 33,3%Limieten van API's van derden6

• 27,8%Schendingen van de staatloze beginselen van hun aanvragen5

• 88,9%Niet-optimale code van eigen diensten16

18 gebruikers hebben gestemd. 6 gebruikers onthielden zich van stemming.

Bron: www.habr.com