Tere Habr!
2017. aastal, musta reede ajal, kasvas koormus ligi poolteist korda ja meie serverid olid oma piiri peal. Aastaga on klientide arv oluliselt kasvanud ning selgus, et ilma hoolika eelettevalmistuseta ei pruugi platvorm 2018. aasta koormustele lihtsalt vastu pidada.
Seadsime võimalikult ambitsioonikama eesmärgi: tahtsime olla täielikult valmis igasugusteks, isegi kõige võimsamateks aktiivsushoogudeks ja hakkasime aasta jooksul uusi võimsusi ette käivitama.
Meie tehnoloogiajuht Andrei Chizh () räägib sellest, kuidas me 2018. aasta mustaks reedeks valmistusime, milliseid meetmeid kukkumiste vältimiseks võtsime ja loomulikult ka sellise hoolika ettevalmistuse tulemused.
Täna tahan rääkida ettevalmistustest mustaks reedeks 2018. Miks just nüüd, kui suurem osa suurematest müükidest on seljataga? Hakkasime valmistuma umbes aasta enne suuremahulisi üritusi ning katse-eksituse meetodil leidsime optimaalse lahenduse. Soovitame kuumade aastaaegade eest juba varakult hoolt kanda ja ennetada pettusi, mis võivad esile kerkida kõige ebasobivamal hetkel.
Materjal on kasulik kõigile, kes soovivad sellistest aktsiatest maksimaalset kasumit pigistada, sest Probleemi tehniline pool ei jää siin turunduslikule poolele alla.
Liikluse omadused suurte müükide korral
Vastupidiselt levinud arvamusele ei ole must reede mitte ainult üks päev aastas, vaid peaaegu terve nädal: esimesed sooduspakkumised saabuvad 7-8 päeva enne müüki. Veebisaidi liiklus hakkab sujuvalt kasvama kogu nädala jooksul, saavutab haripunkti reedel ja langeb laupäeval üsna järsult poe tavapärasele tasemele.
Seda on oluline arvestada: veebipoed muutuvad süsteemi mis tahes „aeglustumise” suhtes eriti tundlikuks. Lisaks suurenes oluliselt ka meie e-posti uudiskirjade saadete arv.
Meie jaoks on strateegiliselt oluline läbida must reede ilma krahhideta, sest... Veebilehtede ja kaupluste uudiskirjade kõige olulisem funktsionaalsus sõltub platvormi toimimisest, nimelt:
- tootesoovituste jälgimine ja väljastamine,
- Seotud materjalide (näiteks soovitusplokkide kujunduse kujutised, nagu nooled, logod, ikoonid ja muud visuaalsed elemendid) väljastamine,
- Vajaliku suurusega tootepiltide pakkumine (selleks on meil “ImageResizer” – alamsüsteem, mis laadib poe serverist pildi alla, tihendab selle vajaliku suuruseni ja toodab vahemällu salvestavate serverite kaudu iga toote jaoks vajalikus suuruses pildid. iga soovitusplokk).
Tegelikult kasvas 2019. aasta musta reede ajal teenuse koormus 40%, s.o. sündmuste arv, mida Retail Rocket süsteem veebipoodide saitidel jälgib ja töötleb, on kasvanud 5-lt 8 tuhandele päringule sekundis. Tänu sellele, et valmistusime tõsisemateks koormusteks, elasime sellise tõusu kergesti üle.
Üldtreening
Must reede on kogu jaekaubanduse ja eriti e-kaubanduse jaoks kiire aeg. Kasutajate arv ja nende aktiivsus praegusel ajal kasvab märkimisväärselt, seega valmistusime, nagu alati, selleks kiireks ajaks põhjalikult. Olgu siinkohal lisatud tõsiasi, et meil on palju võrgupoode ühendatud mitte ainult Venemaal, vaid ka Euroopas, kus põnevus on palju suurem ja kirg on Brasiilia sarjast kehvem. Mida tuleb teha, et olla suurenenud koormusteks täielikult valmis?
Töötamine serveritega
Kõigepealt oli vaja välja selgitada, mida me täpselt vajame serveri võimsuse suurendamiseks. Juba augustis alustasime spetsiaalselt musta reede jaoks uute serverite tellimist – kokku lisasime 10 masinat. Novembriks olid nad täielikult lahingus.
Samal ajal installiti osa ehitusmasinaid uuesti rakendusserveritena kasutamiseks. Valmistasime nad kohe ette erinevate funktsioonide kasutamiseks: nii soovituste väljastamiseks kui ka teenuse ImageResizer jaoks, et olenevalt koormuse tüübist saaks igaüht neist kasutada ühes neist rollidest. Tavarežiimis on rakendus- ja ImageResizer-serveritel selgelt määratletud funktsioonid: esimesed annavad soovitusi, teised pakuvad veebipoodide veebisaitidel tähtede ja soovitusplokkide jaoks pilte. Mustaks reedeks valmistudes otsustati teha kõik kaheotstarbelised serverid, et tasakaalustada nende vahelist liiklust olenevalt allalaadimise tüübist.
Seejärel lisasime kaks suurt serverit Kafka jaoks (Apache Kafka) ja saime 5 võimsa masina klastri. Kahjuks ei läinud kõik nii libedalt, kui sooviksime: andmete sünkroonimise käigus hõivasid kaks uut masinat kogu võrgukanali laiuse ja tuli kiiresti välja mõelda, kuidas lisamisprotsess kiiresti ja turvaliselt läbi viia. kogu infrastruktuur. Selle probleemi lahendamiseks pidid meie administraatorid oma nädalavahetused vapralt ohverdama.
Töö andmetega
Lisaks serveritele otsustasime koormuse vähendamiseks optimeerida faile ja meie jaoks oli suur samm staatiliste failide tõlkimine. Kõik staatilised failid, mida varem serverites majutati, teisaldati teenusesse S3 + Cloudfront. Oleme seda juba ammu tahtnud teha, kuna serveri koormus oli piirväärtuste lähedal ja nüüd avanes suurepärane võimalus.
Nädal enne musta reedet suurendasime piltide vahemällu salvestamise aega 3 päevani, et ImageResizeri kokkujooksmise korral saaks varem vahemällu salvestatud pildid cdn-st kätte. See vähendas ka meie serverite koormust, sest mida kauem pilti salvestatakse, seda harvemini peame kulutama ressursse suuruse muutmisele.
Ja viimane, kuid mitte vähemtähtis: 5 päeva enne musta reedet kuulutati välja moratoorium mis tahes uute funktsioonide kasutuselevõtule, samuti mis tahes töödele infrastruktuuriga – kogu tähelepanu on suunatud suurenenud koormustega toimetulemisele.
Plaanid keerulistele olukordadele reageerimiseks
Ükskõik kui kvaliteetne ettevalmistus ka poleks, on fakapid alati võimalikud. Ja oleme välja töötanud 3 reageerimisplaani võimalike kriitiliste olukordade jaoks:
- koormuse vähendamine,
- mõne teenuse keelamine,
- teenuse täielik sulgemine.
Plaan A: vähendage koormust. Oleks pidanud aktiveerima, kui meie serverid ületasid koormuse suurenemise tõttu vastuvõetavat reageerimisaega. Sel juhul oleme ette valmistanud mehhanismid koormuse järkjärguliseks vähendamiseks, suunates osa liiklusest Amazoni serveritele, mis lihtsalt vastaksid kõigile päringutele “200 OK” ja annaksid tühja vastuse. Saime aru, et tegemist on teenuse kvaliteedi halvenemisega, kuid valik selle vahel, et teenus ei tööta üldse või ei näita soovitusi ligikaudu 10% liiklusest, on ilmne.
Plaan B: Keela teenused. Teenuse kaudne osaline halvenemine. Näiteks isiklike soovituste arvutamise kiiruse vähendamine, et tühjendada mõned andmebaasid ja sidekanalid. Tavarežiimis arvutatakse soovitusi reaalajas, luues iga külastaja jaoks veebipoest erineva versiooni, kuid suurenenud koormuse tingimustes võimaldab kiiruse vähendamine teistel põhiteenustel tööd jätkata.
Plaan C: Armageddoni puhul. Kui tekib täielik süsteemitõrge, oleme koostanud plaani, mis võimaldab meid klientidega turvaliselt lahti ühendada. Poe ostjad lihtsalt ei näe enam soovitusi, veebipoe toimivus ei kannata see kuidagi. Selleks peaksime oma integratsioonifaili lähtestama, et uued kasutajad lõpetaksid teenusega suhtlemise. See tähendab, et me keelaksime oma peamise jälgimiskoodi, teenus lõpetaks andmete kogumise ja soovituste arvutamise ning kasutaja näeks lihtsalt ilma soovitusplokkideta lehte. Kõigile neile, kes on varem integratsioonifaili saanud, oleme andnud võimaluse lülitada DNS-kirje Amazonile ja 200 OK tünnile.
Tulemused
Saime kogu koormaga hakkama isegi ilma täiendavate ehitusmasinate kasutamiseta. Ja tänu eelnevale ettevalmistusele ei vajanud me ühtegi väljatöötatud reageerimisplaani. Kuid kogu tehtud töö on hindamatu kogemus, mis aitab meil toime tulla kõige ootamatumate ja tohutumate liiklusvoogudega.
Sarnaselt 2017. aastaga kasvas teenuse koormus mustal reedel 40% ja kasutajate arv veebipoodides 60%. Kõik raskused ja vead tekkisid ettevalmistusperioodil, mis päästsid meid ja meie kliente ettenägematutest olukordadest.
Kuidas musta reedega toime tulete? Kuidas valmistute kriitilisteks koormusteks?
Allikas: www.habr.com