Sveiki, Habr!
2017 m. per Juodąjį penktadienį apkrova išaugo beveik pusantro karto, o mūsų serveriai buvo ties savo riba. Per metus klientų skaičius gerokai išaugo ir tapo aišku, kad be kruopštaus išankstinio pasiruošimo platforma gali tiesiog neatlaikyti 2018 metų apkrovų.
Išsikėlėme kuo ambicingiausią tikslą: norėjome būti visiškai pasiruošę bet kokiam, net ir galingiausiam, veiklos antplūdžiui ir visus metus iš anksto pradėjome diegti naujus pajėgumus.
Mūsų CTO Andrejus Čižas () pasakoja, kaip ruošėmės 2018 m. Juodajam penktadieniui, kokių priemonių ėmėmės, kad išvengtume kritimų, ir, žinoma, tokio kruopštaus pasiruošimo rezultatai.
Šiandien noriu pakalbėti apie pasiruošimą 2018 m. Juodajam penktadieniui. Kodėl dabar, kai dauguma pagrindinių išpardavimų jau atsiliko? Pradėjome ruoštis likus maždaug metams iki didelio masto renginių ir per bandymus ir klaidas radome optimalų sprendimą. Rekomenduojame iš anksto pasirūpinti karštaisiais sezonais ir užkirsti kelią sukčiai, kurios gali iškilti pačiu netinkamiausiu momentu.
Medžiaga bus naudinga visiems, kurie nori iš tokių akcijų išgauti maksimalų pelną, nes Techninė problemos pusė nėra prastesnė už rinkodaros pusę.
Eismo ypatybės didelių išpardavimų metu
Priešingai populiariems įsitikinimams, juodasis penktadienis yra ne tik viena diena per metus, o beveik visa savaitė: pirmieji nuolaidų pasiūlymai sulaukia likus 7-8 dienoms iki išpardavimo. Tinklalapių lankomumas pradeda sklandžiai augti visą savaitę, piką pasiekia penktadienį, o šeštadienį gana smarkiai nukrenta iki įprastinio parduotuvės lygio.
Tai svarbu atsižvelgti: internetinės parduotuvės tampa ypač jautrios bet kokiam sistemos „sulėtėjimui“. Be to, mūsų el. pašto naujienlaiškių eilutėje taip pat labai išaugo pateiktų pranešimų skaičius.
Mums strategiškai svarbu juodąjį penktadienį išgyventi be avarijų, nes... Svarbiausias svetainių ir parduotuvių naujienlaiškių funkcionalumas priklauso nuo platformos veikimo, būtent:
- Stebėti ir teikti produktų rekomendacijas,
- Susijusios medžiagos (pavyzdžiui, rekomendacijų blokų dizaino vaizdų, tokių kaip rodyklės, logotipai, piktogramos ir kiti vaizdiniai elementai) išleidimas,
- Reikalingo dydžio produktų vaizdų pateikimas (tam tikslui turime „ImageResizer“ – posistemį, kuris atsisiunčia vaizdą iš parduotuvės serverio, suglaudina jį iki reikiamo dydžio ir per talpyklos serverius sukuria reikiamo dydžio vaizdus kiekvienam produktui. kiekvieną rekomendacijų bloką).
Iš tiesų per 2019 metų Juodąjį penktadienį paslaugos apkrovimas išaugo 40 proc., t.y. įvykių, kuriuos „Retail Rocket“ sistema seka ir apdoroja internetinių parduotuvių svetainėse, skaičius išaugo nuo 5 iki 8 tūkstančių užklausų per sekundę. Dėl to, kad ruošėmės rimtesniems krūviams, tokį antplūdį išgyvenome nesunkiai.
Bendras mokymas
Juodasis penktadienis yra įtemptas metas visai mažmeninei prekybai ir ypač elektroninei prekybai. Vartotojų skaičius ir jų aktyvumas šiuo metu ženkliai auga, todėl kaip visada kruopščiai ruošėmės šiam užimtam laikui. Pridėkime dar faktą, kad turime daugybę internetinių parduotuvių ne tik Rusijoje, bet ir Europoje, kur jaudulys daug didesnis, o aistros lygis yra prastesnis nei Brazilijos serialas. Ką reikia padaryti norint pilnai pasiruošti padidėjusioms apkrovoms?
Darbas su serveriais
Pirmiausia reikėjo išsiaiškinti, ko tiksliai mums reikia norint padidinti serverio galią. Jau rugpjūčio mėnesį pradėjome užsakyti naujus serverius specialiai juodajam penktadieniui – iš viso pridėjome 10 papildomų mašinų. Lapkričio mėnesį jie visiškai kovojo.
Tuo pačiu metu kai kurios kūrimo mašinos buvo iš naujo įdiegtos, kad būtų naudojamos kaip taikomųjų programų serveriai. Iš karto paruošėme jas naudoti įvairias funkcijas: tiek rekomendacijų išdavimui, tiek ImageResizer paslaugai, kad, priklausomai nuo apkrovos tipo, kiekviena iš jų galėtų būti naudojama vienam iš šių vaidmenų. Įprastu režimu „Application“ ir „ImageResizer“ serveriai turi aiškiai apibrėžtas funkcijas: pirmieji teikia rekomendacijas, o antrieji pateikia laiškų atvaizdus ir rekomendacijų blokus internetinės prekybos svetainėse. Ruošiantis juodajam penktadieniui, buvo nuspręsta visus serverius padaryti dvigubos paskirties, kad būtų subalansuotas srautas tarp jų, atsižvelgiant į atsisiuntimo tipą.
Tada pridėjome du didelius „Kafka“ („Apache Kafka“) serverius ir gavome 5 galingų mašinų grupę. Deja, ne viskas klostėsi taip sklandžiai, kaip norėtume: duomenų sinchronizavimo proceso metu du nauji įrenginiai užėmė visą tinklo kanalo plotį, todėl teko skubiai sugalvoti, kaip greitai ir saugiai atlikti papildymo procesą. visa infrastruktūra. Norėdami išspręsti šią problemą, mūsų administratoriai turėjo drąsiai paaukoti savo savaitgalius.
Darbas su duomenimis
Be serverių, nusprendėme optimizuoti failus, kad sumažintume apkrovą, o didelis žingsnis mums buvo statinių failų vertimas. Visi statiniai failai, kurie anksčiau buvo talpinami serveriuose, buvo perkelti į S3 + Cloudfront. Jau seniai norėjome tai padaryti, nes serverio apkrova buvo artima ribinėms vertėms, o dabar atsirado puiki galimybė.
Likus savaitei iki juodojo penktadienio, padidinome vaizdų saugojimo talpykloje laiką iki 3 dienų, kad jei „ImageResizer“ užstrigtų, anksčiau talpykloje saugomi vaizdai būtų gauti iš kompaktinio disko. Tai taip pat sumažino mūsų serverių apkrovą, nes kuo ilgiau vaizdas saugomas, tuo rečiau turime eikvoti išteklių dydžiui keisti.
Ir paskutinis, bet ne mažiau svarbus dalykas: likus 5 dienoms iki juodojo penktadienio, buvo paskelbtas moratoriumas bet kokio naujo funkcionalumo diegimui, taip pat bet kokiems darbams su infrastruktūra – visas dėmesys nukreiptas į padidėjusį krūvį.
Reagavimo į sudėtingas situacijas planai
Kad ir koks kokybiškas būtų paruošimas, fakapai visada galimi. Ir mes sukūrėme 3 reagavimo planus galimoms kritinėms situacijoms:
- apkrovos sumažinimas,
- kai kurių paslaugų išjungimas,
- visiškas paslaugos išjungimas.
Planas A: Sumažinkite apkrovą. Turėjo būti suaktyvinta, jei dėl padidėjusios apkrovos mūsų serveriai viršijo priimtiną atsakymo laiką. Šiuo atveju esame paruošę mechanizmus, kaip palaipsniui mažinti apkrovą, dalį srauto perjungiant į Amazon serverius, kurie į visas užklausas tiesiog atsakytų „200 OK“ ir duotų tuščią atsakymą. Supratome, kad tai buvo paslaugos kokybės pablogėjimas, tačiau pasirinkimas tarp to, kad paslauga visai neveikia arba nerodo rekomendacijų maždaug 10% srauto, yra akivaizdus.
Planas B: išjungti paslaugas. Numanomas dalinis paslaugos pablogėjimas. Pavyzdžiui, sumažinti asmeninių rekomendacijų skaičiavimo greitį, norint iškrauti kai kurias duomenų bazes ir ryšio kanalus. Įprastu režimu rekomendacijos skaičiuojamos realiu laiku, kiekvienam lankytojui sukuriant skirtingą internetinės parduotuvės versiją, tačiau padidintos apkrovos sąlygomis greičio sumažinimas leidžia toliau dirbti kitoms pagrindinėms paslaugoms.
Planas C: Armagedono atveju. Jei įvyktų visiškas sistemos gedimas, parengėme planą, kuris leis saugiai atsijungti nuo klientų. Parduotuvės pirkėjai tiesiog nustos matyti rekomendacijas, internetinės parduotuvės veikla niekaip nenukentės. Norėdami tai padaryti, turėtume iš naujo nustatyti integravimo failą, kad nauji vartotojai nustotų bendrauti su paslauga. Tai yra, mes išjungtume savo pagrindinį stebėjimo kodą, paslauga nustotų rinkti duomenis ir skaičiuoti rekomendacijas, o vartotojas tiesiog pamatytų puslapį be rekomendacijų blokų. Visiems, kurie anksčiau gavo integravimo failą, suteikėme galimybę pakeisti DNS įrašą į „Amazon“ ir 200 OK stubą.
rezultatai
Visą krovinį tvarkėme net ir nenaudodami papildomų konstravimo mašinų. Ir dėl išankstinio pasiruošimo mums neprireikė nė vieno iš parengtų reagavimo planų. Tačiau visas atliktas darbas yra neįkainojama patirtis, kuri padės mums susidoroti su netikėčiausiais ir didžiuliais srautų antplūdžiais.
Kaip ir 2017 metais, juodąjį penktadienį paslaugos apkrovimas išaugo 40 proc., o vartotojų skaičius internetinėse parduotuvėse išaugo 60 proc. Visi sunkumai ir klaidos atsirado pasiruošimo laikotarpiu, o tai išgelbėjo mus ir mūsų klientus nuo nenumatytų situacijų.
Kaip jums sekasi juodasis penktadienis? Kaip ruošiatės kritiniams krūviams?
Šaltinis: www.habr.com