Hei Habr!
I 2017, under Black Friday, økte belastningen med nesten en og en halv gang, og serverne våre var på grensen. I løpet av året har antallet kunder vokst betydelig, og det ble klart at uten nøye foreløpig forberedelse, kan plattformen rett og slett ikke tåle belastningen i 2018.
Vi satte oss et mest mulig ambisiøst mål: vi ønsket å være fullt forberedt på enhver, selv de kraftigste, aktivitetsbølger og begynte å lansere ny kapasitet på forhånd gjennom året.
Vår CTO Andrey Chizh () forteller hvordan vi forberedte oss til Black Friday 2018, hvilke tiltak vi tok for å unngå fall, og selvfølgelig resultatene av en slik nøye forberedelse.
I dag vil jeg snakke om forberedelsene til Black Friday 2018. Hvorfor nå, når de fleste store salgene ligger bak oss? Vi begynte å forberede oss rundt et år før store arrangementer, og gjennom prøving og feiling fant vi den optimale løsningen. Vi anbefaler at du tar vare på de varme årstidene på forhånd og forhindrer svindel som kan dukke opp i det mest uleilige øyeblikket.
Materialet vil være nyttig for alle som ønsker å presse maksimal fortjeneste fra slike aksjer, fordi Den tekniske siden av saken er ikke dårligere enn markedsføringssiden her.
Funksjoner av trafikk ved store salg
I motsetning til hva mange tror, er Black Friday ikke bare én dag i året, men nesten en hel uke: De første rabatttilbudene kommer 7-8 dager før salget. Nettstedstrafikken begynner å vokse jevnt gjennom uken, når sitt høydepunkt på fredag og synker ganske kraftig på lørdag til butikkens vanlige nivåer.
Dette er viktig å ta i betraktning: nettbutikker blir spesielt følsomme for eventuelle "nedganger" i systemet. I tillegg opplevde vår nyhetsbrevlinje på e-post også en betydelig økning i antall innsendinger.
Det er strategisk viktig for oss å gå gjennom Black Friday uten krasj, fordi... Den viktigste funksjonaliteten til nettsider og butikknyhetsbrev avhenger av driften av plattformen, nemlig:
- Sporing og utstedelse av produktanbefalinger,
- Utstedelse av relatert materiale (for eksempel bilder av utformingen av anbefalingsblokker, som piler, logoer, ikoner og andre visuelle elementer),
- Tilveiebringer produktbilder av den nødvendige størrelsen (for disse formålene har vi "ImageResizer" - et undersystem som laster ned et bilde fra butikkserveren, komprimerer det til ønsket størrelse og, gjennom caching-servere, produserer bilder av den nødvendige størrelsen for hvert produkt i hver anbefalingsblokk).
Faktisk, under Black Friday 2019, økte belastningen på tjenesten med 40 %, dvs. antall hendelser som Retail Rocket-systemet sporer og behandler på nettbutikksider har økt fra 5 til 8 tusen forespørsler per sekund. På grunn av det faktum at vi forberedte oss på mer alvorlige belastninger, overlevde vi en slik bølge lett.
Generell opplæring
Black Friday er en travel tid for all detaljhandel og e-handel spesielt. Antall brukere og deres aktivitet på dette tidspunktet vokser betydelig, så vi, som alltid, forberedte oss grundig på denne travle tiden. La oss legge til det faktum at vi har mange nettbutikker koblet ikke bare i Russland, men også i Europa, hvor spenningen er mye høyere, og vi får et nivå av lidenskap som er verre enn den brasilianske serien. Hva må gjøres for å være fullt forberedt på økt belastning?
Jobber med servere
Først var det nødvendig å finne ut nøyaktig hva vi trengte for å øke serverkraften. Allerede i august begynte vi å bestille nye servere spesifikt for Black Friday – totalt la vi til 10 ekstra maskiner. I november var de fullt ut i kamp.
Samtidig ble noen av byggemaskinene reinstallert for bruk som applikasjonsservere. Vi forberedte dem umiddelbart til å bruke forskjellige funksjoner: både for å gi anbefalinger og for ImageResizer-tjenesten, slik at, avhengig av type belastning, hver av dem kunne brukes til en av disse rollene. I normal modus har Application- og ImageResizer-serverne klart definerte funksjoner: førstnevnte gir anbefalinger, sistnevnte gir bilder for bokstaver og anbefalingsblokker på nettbutikknettsteder. Som forberedelse til Black Friday ble det besluttet å lage alle dual-purpose servere for å balansere trafikken mellom dem avhengig av typen nedlasting.
Så la vi til to store servere for Kafka (Apache Kafka) og fikk en klynge med 5 kraftige maskiner. Dessverre gikk ikke alt så knirkefritt som vi skulle ønske: under datasynkroniseringsprosessen okkuperte to nye maskiner hele bredden av nettverkskanalen, og vi måtte raskt finne ut hvordan vi skulle utføre tilleggsprosessen raskt og sikkert for hele infrastrukturen. For å løse dette problemet måtte administratorene våre tappert ofre helgene sine.
Arbeid med data
I tillegg til servere bestemte vi oss for å optimalisere filer for å lette belastningen, og et stort skritt for oss var oversettelsen av statiske filer. Alle statiske filer som tidligere var vert på servere ble flyttet til S3 + Cloudfront. Dette har vi ønsket å gjøre lenge siden belastningen på serveren var nær grenseverdiene, og nå har en stor mulighet dukket opp.
En uke før Black Friday økte vi hurtigbufringstiden for bilder til 3 dager, slik at hvis ImageResizer krasjet, ville tidligere hurtigbufrede bilder hentes fra cdn. Det reduserte også belastningen på serverne våre, siden jo lenger bildet lagres, desto sjeldnere trenger vi å bruke ressurser på å endre størrelse.
Og sist, men ikke minst: 5 dager før Black Friday ble det kunngjort et moratorium for utplassering av ny funksjonalitet, samt på alt arbeid med infrastrukturen - all oppmerksomhet er rettet mot å takle økte belastninger.
Planer for å reagere på vanskelige situasjoner
Uansett hvor høy kvalitet preparatet er, er fakaps alltid mulig. Og vi har utviklet 3 responsplaner for mulige kritiske situasjoner:
- belastningsreduksjon,
- deaktivering av enkelte tjenester,
- fullstendig nedleggelse av tjenesten.
Plan A: Reduser belastningen. Skulle vært aktivert hvis serverne våre gikk utover akseptable responstider på grunn av en økning i belastningen. I dette tilfellet har vi forberedt mekanismer for gradvis å redusere belastningen ved å bytte deler av trafikken til Amazon-servere, som ganske enkelt vil svare på alle forespørsler med "200 OK" og gi et tomt svar. Vi forsto at dette var en forringelse av kvaliteten på tjenesten, men valget mellom at tjenesten ikke fungerer i det hele tatt eller ikke viser anbefalinger for cirka 10 % av trafikken er åpenbart.
Plan B: Deaktiver tjenester. Underforstått delvis forringelse av tjenesten. For eksempel å redusere hastigheten på å beregne personlige anbefalinger for å laste ut noen databaser og kommunikasjonskanaler. I normal modus beregnes anbefalingene i sanntid, og skaper en annen versjon av nettbutikken for hver besøkende, men under forhold med økt belastning lar reduksjon av hastigheten andre kjernetjenester fortsette å fungere.
Plan C: i tilfelle av Armageddon. Hvis det er en fullstendig systemfeil, har vi utarbeidet en plan som gjør at vi trygt kan kobles fra kundene våre. Butikkkjøpere vil rett og slett slutte å se anbefalinger; ytelsen til nettbutikken vil ikke lide på noen måte. For å gjøre dette, må vi tilbakestille integrasjonsfilen vår slik at nye brukere slutter å samhandle med tjenesten. Det vil si at vi deaktiverer hovedsporingskoden vår, tjenesten vil slutte å samle inn data og beregne anbefalinger, og brukeren vil ganske enkelt se en side uten anbefalingsblokker. For alle de som tidligere har mottatt en integrasjonsfil, har vi gitt muligheten til å bytte DNS-posten til Amazon og 200 OK-stubben.
Resultater av
Vi håndterte hele lasten selv uten å måtte bruke ekstra byggemaskiner. Og takket være forhåndsforberedelser trengte vi ingen av de utarbeidede responsplanene. Men alt arbeidet som er gjort er uvurderlig erfaring som vil hjelpe oss å takle de mest uventede og enorme tilstrømningene av trafikk.
Som i 2017 økte belastningen på tjenesten med 40 %, og antall brukere i nettbutikker økte med 60 % på Black Friday. Alle vanskeligheter og feil oppstod under forberedelsesperioden, noe som reddet oss og våre klienter fra uforutsette situasjoner.
Hvordan takler du Black Friday? Hvordan forbereder du deg på kritiske belastninger?
Kilde: www.habr.com