Salom, Xabr! So'nggi bir necha oy davomida biz juda qiziqarli vaziyatni boshdan kechirdik va men infratuzilmani kengaytirish haqidagi hikoyamiz bilan o'rtoqlashmoqchiman. Bu vaqt ichida SberMarket buyurtmalari to'rt baravarga oshdi va biz ushbu xizmatni 17 ta yangi shaharda ishga tushirdik. Oziq-ovqat yetkazib berishga talabning keskin o'sishi bizdan infratuzilmani kengaytirishni talab qildi. Eng qiziqarli va foydali topilmalar uchun o'qing.
Mening ismim Dima Bobilev va men SberMarketning texnik direktoriman. Bu bizning blogimizdagi birinchi post bo'lgani uchun, men o'zim va kompaniya haqida bir necha so'z aytaman. O'tgan kuzda men Yosh RuNet yetakchilari tanlovida ishtirok etdim. Tanlov uchun men Men SberMarketda bizning ichki madaniyatimiz va xizmatlarni rivojlantirishga yondashuvimizga qanday qarashimizni muhokama qildim. Garchi men tanlovda g'olib chiqmagan bo'lsam ham, IT ekotizimini rivojlantirishning asosiy tamoyillarini ishlab chiqdim.
Jamoani boshqarishda biznes ehtiyojlarini individual ishlab chiquvchining ehtiyojlari bilan tushunish va muvozanatlash muhimdir. SberMarket hozirda yildan-yilga 13 baravar o'sib bormoqda va bu mahsulotga ta'sir qiladi, bu esa ishlab chiqish hajmi va sur'atini doimiy ravishda oshirishni talab qiladi. Shunga qaramay, biz ishlab chiquvchilarga dastlabki tahlil va yuqori sifatli kod yozish uchun yetarli vaqt ajratamiz. Ushbu o'rnatilgan yondashuv nafaqat ishlaydigan mahsulotni yaratishda, balki uning kelajakdagi miqyosi va rivojlanishida ham yordam beradi. Ushbu o'sish natijasida SberMarket allaqachon oziq-ovqat yetkazib berish xizmatlari orasida yetakchiga aylandi: biz har kuni taxminan 18 000 buyurtmani yetkazib beramiz, bu fevral oyining boshidagi 3500 ga yaqin buyurtmadan ko'p.
Bir kuni mijoz SberMarket kuryeridan oziq-ovqat mahsulotlarini kontaktsiz — to'g'ridan-to'g'ri balkoniga yetkazib berishni so'radi.
Lekin keling, aniqliklarga to'xtalib o'tamiz. So'nggi bir necha oy ichida biz kompaniyamiz infratuzilmasini faol ravishda kengaytirdik. Bu ehtiyoj ham tashqi, ham ichki omillar ta'sirida yuzaga keldi. Mijozlar bazasining kengayishi bilan bir qatorda, ulangan do'konlar soni yil boshidagi 90 tadan may oyining o'rtalariga kelib 200 dan oshdi. Albatta, biz asosiy infratuzilmani zaxiralab, Yandex bulutida joylashgan barcha virtual mashinalarni kattalashtirish va kamaytirish imkoniyatiga umid qilgan edik. Biroq, tajriba shuni ko'rsatadiki, "noto'g'ri ketishi mumkin bo'lgan har qanday narsa noto'g'ri ketadi". Bugun men so'nggi bir necha hafta ichida sodir bo'lgan eng qiziqarli vaziyatlardan ba'zilari bilan o'rtoqlashmoqchiman. Umid qilamanki, bizning tajribamiz siz uchun foydali bo'ladi.
Qul to'liq jangovar tayyorgarlikda
Pandemiyadan oldin ham biz orqa serverlarimizga so'rovlar ko'payib borayotganini kuzatdik. Uyga yetkazib berish uchun oziq-ovqat mahsulotlariga buyurtma berish tendentsiyasi tobora kuchayib bordi va birinchi COVID-19 karantin choralari joriy etilishi bilan kun davomida yuk sezilarli darajada oshdi. Birlamchi ma'lumotlar bazasining asosiy serverlariga yukni tezda kamaytirish va ba'zi o'qish so'rovlarini replika serverlariga (qullarga) ko'chirish zarurati paydo bo'ldi.
Biz bu bosqichga oldindan tayyorgarlik ko'rgan edik va bu manevr uchun ikkita qul server allaqachon ishga tushirilgan edi. Ular asosan hamkorlar bilan ma'lumotlar almashish uchun axborot oqimlarini yaratish bo'yicha ommaviy vazifalarni bajarardi. Bu jarayonlar keraksiz ish yukini yaratdi va bir necha oy oldin haqli ravishda chetga surildi.
Replikatsiya Slave’da sodir bo‘lganligi sababli, biz ilovalar ular bilan faqat o‘qish rejimida ishlashi mumkin degan konsepsiyaga amal qildik. Tabiiy ofatlardan keyin tiklanish rejasi falokat yuz bergan taqdirda, biz shunchaki Slave’ni Master’ning o‘rniga o‘rnatishimiz va barcha o‘qish va yozish so‘rovlarini Slave’ga o‘tkazishimiz mumkinligini taxmin qilgan edi. Biroq, biz tahlil bo‘limi uchun ham replikalardan foydalanishni xohladik, shuning uchun serverlar to‘liq faqat o‘qish rejimiga o‘rnatilmagan edi. Har bir xostning o‘z foydalanuvchilari to‘plami bor edi, ba’zilari oraliq hisoblash natijalarini saqlash uchun yozish huquqiga ega edilar.
Muayyan yuklanish darajasiga qadar bizda HTTP so'rovlarini yozish va o'qish uchun yetarli resurslar bor edi. Mart oyining o'rtalarida, Sbermarket butunlay masofaviy ishlashga qaror qilganida, biz RPSning keskin o'sishini kuzatdik. Mijozlarimizning tobora ko'proq qismi o'zini izolyatsiya qilish yoki uydan ishlashni boshladi, bu esa bizning yuklanish ko'rsatkichlarimizga ta'sir qildi.
Masterning ishlashi endi yetarli emas edi, shuning uchun biz eng og'ir o'qish so'rovlarining bir qismini replikaga yuklay boshladik. Yozish so'rovlarini masterga va o'qish so'rovlarini tobega shaffof ravishda yo'naltirish uchun biz Ruby gemidan foydalandik."Biz yozish ruxsatisiz _readonly postfiksiga ega maxsus foydalanuvchi yaratdik. Biroq, xostlardan birida konfiguratsiya xatosi tufayli ba'zi yozish so'rovlari tegishli ruxsatlarga ega bo'lgan foydalanuvchi nomi ostida qul serveriga yuborildi.
Muammo darhol o'zini namoyon qilmadi, chunki ortib borayotgan yuklama qullik kechikishini oshirdi. Ma'lumotlar nomuvofiqligi ertalab aniqlandi, o'shanda bir kechada import qilinganidan so'ng, qullar asosiyga "yetib ololmagan". Biz buni xizmatning o'ziga yuklangan yuqori yuklama va yangi do'konlarning ishga tushirilishi bilan bog'liq import bilan bog'ladik. Biroq, ma'lumotlarni bir necha soatlik kechikish bilan yetkazib berish qabul qilinishi mumkin emas edi, shuning uchun biz jarayonlarni ikkinchi analitik qulga o'tkazdik, chunki u shunday ediоko'proq resurslarga ega edi va o'qish so'rovlari bilan to'ldirilmagan edi (biz replikatsiya kechikishining yo'qligini o'zimizga shunday tushuntirdik).
Asosiy serverning "sirpanishi" sabablarini aniqlaganimizda, analitik server allaqachon xuddi shu sababga ko'ra ishlamay qolgan edi. Asosiy server ishlamay qolgan taqdirda yukni o'tkazishni rejalashtirgan ikkita qo'shimcha serverimiz bo'lishiga qaramay, noxush xatolik tufayli muhim paytda ikkalasi ham mavjud emas edi.
Lekin biz nafaqat ma'lumotlar bazasini tashlab yuborganimiz (o'sha paytda tiklash taxminan 5 soat davom etgan), balki asosiy serverning suratini ham olganimiz sababli, replikani 2 soat ichida ishga tushira oldik. Biroq, shundan so'ng, biz uzoq vaqt davomida replikatsiya jurnalini yaratishga duch keldik (chunki jarayon bitta oqimli, ammo bu butunlay boshqa hikoya).
xulosa: Ushbu voqeadan so'ng, foydalanuvchilar uchun yozishga kirishni cheklash amaliyotidan voz kechishimiz va butun serverni faqat o'qish uchun deb e'lon qilishimiz kerakligi ma'lum bo'ldi. Ushbu yondashuv replikalarning muhim daqiqalarda mavjud bo'lishini ta'minlaydi.
Hatto bitta og'ir so'rovni ham optimallashtirish ma'lumotlar bazasini qayta jonlantirishi mumkin.
Veb-sayt katalogini doimiy ravishda yangilab tursak-da, biz qul serverlariga yuborayotgan so'rovlar asosiy serverlardan biroz orqada qolardi. Qul serverlarining to'satdan xizmat ko'rsatishdan chiqib ketishi bilan bog'liq muammoni aniqlash va hal qilish uchun ketgan vaqt "psixologik to'siq"dan uzoqroq edi (bu vaqt ichida narxlar yangilanishi mumkin edi va mijozlar eskirgan ma'lumotlarni ko'rishlari mumkin edi) va biz barcha so'rovlarni asosiy ma'lumotlar bazasi serveriga o'tkazishga majbur bo'ldik. Natijada, veb-sayt sekin ishlayotgan edi... lekin hech bo'lmaganda ishlayotgan edi. Va qul serveri tiklanayotgan bir paytda, bizda optimallashtirishdan boshqa choramiz yo'q edi.
Qul serverlari tiklanayotgan bir paytda, daqiqalar cho'zilib, asosiy server ortiqcha yuklangan holda qoldi va biz barcha kuchimizni Pareto printsipiga muvofiq faol vazifalarni optimallashtirishga qaratdik: yukning katta qismini tashkil etuvchi eng yaxshi so'rovlarni tanladik va sozlashni boshladik. Bu tezkorlik bilan amalga oshirildi.
Qiziqarli natija shundaki, to'liq yuklangan MySQL nusxasi hatto kichik jarayonlar yaxshilanishlariga ham javob berdi. Umumiy yuklanishning atigi 5% ni tashkil etgan bir nechta so'rovlarni optimallashtirish protsessor yuklanishida sezilarli kamayishni ko'rsatdi. Natijada, biz Master ma'lumotlar bazasi uchun maqbul resurs zaxirasini ta'minlay oldik va replikalarni tiklash uchun zarur vaqtni qo'lga kiritdik.
xulosa: Hatto kichik optimallashtirishlar ham bizga bir necha soat davomida ortiqcha yuklanishdan omon qolish imkonini beradi. Bu bizning replika serverlarimizni tiklash uchun yetarli edi. Aytgancha, biz keyingi postda so'rovlarni optimallashtirishning texnik jihatlarini muhokama qilamiz. Agar bu sizga foydali bo'lsa, bizning blogimizga obuna bo'ling.
Hamkor xizmatlarning ishlashini monitoring qilishni tashkil qilish
Biz mijozlar buyurtmalarini qayta ishlaymiz, shuning uchun bizning xizmatlarimiz doimiy ravishda uchinchi tomon API-lari — SMS shlyuzlari, to'lov platformalari, marshrutizatsiya tizimlari, geokoderlar, Federal Soliq xizmati va boshqa ko'plab tizimlar bilan o'zaro aloqada bo'ladi. Va yuk tez o'sishni boshlaganda, biz ilgari ko'rib chiqmagan hamkor xizmatlarimizning API cheklovlariga duch kela boshladik.
Kutilmaganda sheriklik xizmati kvotalaridan oshib ketish sizning xizmatingizning ishlamay qolishiga olib kelishi mumkin. Ko'pgina APIlar o'z chegaralaridan oshib ketgan mijozlarni bloklaydi va ba'zi hollarda ortiqcha so'rovlar sherikning ishlab chiqarish tizimini ishdan chiqarishi mumkin.
Masalan, yetkazib berish hajmi oshganda, hamrohlik qiluvchi xizmatlar ularni tarqatish va marshrutlarni aniqlash vazifalarini bajara olmadilar. Natijada, buyurtmalar berildi, ammo marshrut yaratish xizmati ishlamay qoldi. Shuni aytish kerakki, bizning logistika guruhimiz bunday sharoitlarda deyarli imkonsiz narsani amalga oshirdi va jamoaning aniq aloqasi vaqtinchalik xizmat uzilishlarini qoplashga yordam berdi. Biroq, bunday hajmdagi buyurtmalarni qo'lda doimiy ravishda qayta ishlashning iloji yo'q va bir muncha vaqt o'tgach, biz buyurtmalar va ularni bajarish o'rtasida qabul qilib bo'lmaydigan tafovutga duch kelamiz.
Bir qator tashkiliy choralar amalga oshirildi va jamoaning muvofiqlashtirilgan ishi bizga yangi shartlar bo'yicha muzokaralar olib borish va ba'zi hamkorlarning xizmatlarini yangilashini kutish vaqtida vaqtni tejashga yordam berdi. Ajoyib chidamlilikka ega va yuqori trafik uchun juda yuqori narxlarni taklif qiladigan boshqa APIlar ham mavjud. Masalan, boshida biz yetkazib berish nuqtasi manzilini aniqlash uchun taniqli xaritalash API-sidan foydalanganmiz. Ammo oy oxiriga kelib, biz deyarli 2 million rubl miqdorida katta miqdordagi to'lovni oldik. Shundan so'ng, biz uni tezda almashtirishga qaror qildik. Men reklama qilmayman, lekin xarajatlarimiz sezilarli darajada kamayganini aytaman.
xulosa: Barcha hamkor xizmatlarning shartlari va qoidalarini kuzatib borish va ularni yodda tutish juda muhimdir. Agar ular bugun "narxi yetarli" bo'lib tuyulsa ham, bu ular ertaga o'sishga to'sqinlik qilmaydi degani emas. Va, albatta, xizmatga talabning ortishi uchun moliyaviy shartlarni oldindan kelishib olish yaxshiroqdir.
Ba'zan shunday bo'lib chiqadi ""(c) yordam bermaydi
Biz asosiy ma'lumotlar bazasi yoki dastur serverlaridagi to'siqlarga o'rganib qolganmiz, ammo masshtablashda muammolar siz kutmagan joyda paydo bo'lishi mumkin. Biz veb-saytimizda to'liq matnli qidiruv uchun Apache Solr dvigatelidan foydalanamiz. Yuklanish oshgani sayin, biz javob berish vaqtining kamayganini va server protsessoridan foydalanish 100% ga yetganini sezdik. Bundan oddiyroq nima bo'lishi mumkin? Biz shunchaki Solr konteyneriga ko'proq resurslar beramiz.
Kutilganidek ishlashni oshirish o'rniga, server shunchaki ishlamay qoldi. U darhol 100% yuklandi va yanada sekinroq javob berdi. Dastlab bizda ikkita yadro va 2 Gb tezkor xotira bor edi. Biz odatda ishlaydigan ishni qilishga qaror qildik - serverni sakkiz yadro va 32 Gb ga yangiladik. Vaziyat ancha yomonlashdi (aniq qanday va nima uchun ekanligini alohida postda tushuntirib beramiz).
Bir necha kun ichida biz ushbu muammoning murakkabliklarini aniqladik va 8 yadro va 32 Gb xotira bilan optimal ishlashga erishdik. Ushbu konfiguratsiya bizga yuklamani oshirishda davom etish imkonini beradi, bu juda muhim, chunki o'sish nafaqat mijozlar nuqtai nazaridan, balki ulangan do'konlar sonida ham kuzatilmoqda - ularning soni ikki oy ichida ikki baravar oshdi.
xulosa: "Qo'shimcha apparat qo'shish" kabi standart usullar har doim ham ish bermaydi. Shunday qilib, har qanday xizmatni masshtablashda siz uning resurslardan qanday foydalanishini chuqur tushunishingiz va yangi sharoitlarda uning ishlashini oldindan sinab ko'rishingiz kerak.
Statsiz - bu gorizontal masshtablashni osonlashtirishning kaliti
Bizning jamoamiz odatda taniqli yondashuvga amal qiladi: xizmatlar holatsiz va ish vaqti muhitidan mustaqil bo'lishi kerak. Bu bizga shunchaki gorizontal masshtablash orqali ortib borayotgan yuklamani engish imkonini berdi. Biroq, bizda bitta istisno bor edi: uzoq vaqt ishlaydigan fon vazifalarini qayta ishlovchi. U elektron pochta va SMS yuborish, hodisalarni qayta ishlash, tasmalar yaratish, narxlar va aksiyalarni import qilish hamda tasvirlarni qayta ishlashni boshqarardi. Shunday qilib, u mahalliy fayllarni saqlashga bog'liq edi va bitta misol edi.
Qayta ishlash navbatidagi vazifalar soni ko'payganida (bu buyurtmalarning ko'payishi bilan tabiiy ravishda sodir bo'lgan), protsessor va fayllarni saqlash joyini joylashtirgan xostning ishlashi cheklanib qoldi. Natijada, inventarizatsiya va narxlarni yangilash, foydalanuvchi bildirishnomalari va boshqa ko'plab muhim funksiyalar orqada qolgan ishlar tufayli to'xtab qoldi. Operatsiyalar guruhi fayllarni saqlash joyini tezda S3 ga o'xshash tarmoq saqlash joyiga ko'chirdi, bu bizga fonda ishlov berishni kengaytirish uchun bir nechta kuchli mashinalarni joylashtirish imkonini berdi.
xulosa: Statsiz qoidasi barcha komponentlar uchun istisnosiz bajarilishi kerak, hatto biz shunchaki chegaramizga yetib bormayotgandek tuyulsa ham. Kodni qayta yozish va ortiqcha yuklangan xizmatni tuzatishga shoshilishdan ko'ra, barcha tizimlarning to'g'ri ishlashi uchun ozgina vaqt sarflagan ma'qul.
Intensiv o'sishning 7 tamoyillari
Qo'shimcha quvvatlarning mavjudligiga qaramay, biz o'sish jarayonida bir qator qiyinchiliklarga duch keldik. Bu vaqt ichida buyurtmalar soni to'rt baravardan ko'proqqa oshdi. Hozirda biz 62 ta shaharda kuniga 17 000 dan ortiq buyurtmalarni yetkazib bermoqdamiz va geografik qamrovimizni yanada kengaytirishni rejalashtirmoqdamiz — biz 2020 yilning birinchi yarmida Rossiya bo'ylab xizmatimizni ishga tushirishni rejalashtirmoqdamiz. O'sib borayotgan ish hajmi va biz duch kelgan qiyinchiliklarga dosh berish uchun biz doimiy o'sish sharoitida operatsiyalarimizni boshqarishning yettita asosiy tamoyilini ishlab chiqdik:
- Hodisalarni boshqarishBiz har bir hodisa chipta sifatida qayd etiladigan Jira doskasini yaratdik. Bu bizga hodisa bilan bog'liq vazifalarni ustuvorlashtirish va bajarishga yordam beradi. Axir, gap aslida xato qilishda emas, balki bir xil xatoni ikki marta qilishda. Hodisalar asosiy sabab tuzatilishidan oldin takrorlanadigan holatlar uchun biz amaliy choralarni ko'rishimiz kerak, chunki ish hajmi yuqori bo'lgan paytlarda tezda javob berish juda muhimdir.
- Monitoring Bu barcha infratuzilma elementlari uchun istisnosiz talab qilinadi. Aynan shu tufayli biz yuk o'sishini bashorat qila oldik va muammolarni hal qilishga ustuvor ahamiyat berish uchun to'siqlarni to'g'ri aniqlay oldik. Yuqori yuk ostida siz hech qachon o'ylamagan hamma narsa buzilib ketishi yoki sekinlashishi ehtimoli bor. Shuning uchun, birinchi hodisalar sodir bo'lgandan so'ng darhol ularni kuzatib borish va oldindan bilish uchun yangi ogohlantirishlarni yaratish yaxshidir.
- To'g'ri ogohlantirishlar Ular yukning to'satdan oshishi paytida juda muhimdir. Birinchidan, ular nima buzilganligini aniq ko'rsatishi kerak. Ikkinchidan, juda ko'p ogohlantirishlar bo'lmasligi kerak, chunki juda ko'p muhim bo'lmagan ogohlantirishlar barcha bildirishnomalarning e'tiborsiz qolishiga olib keladi.
- Arizalar fuqaroligi bo'lmagan bo'lishi kerak. Biz ushbu qoidadan istisnolar bo'lmasligi kerakligiga amin bo'ldik. Ish vaqti muhitidan to'liq mustaqillik juda muhim. Bunga erishish uchun siz umumiy ma'lumotlarni ma'lumotlar bazasida yoki, masalan, to'g'ridan-to'g'ri S3 da saqlashingiz mumkin. Bundan ham yaxshisi, qoidalarga amal qiling.Vaqtning to'satdan o'sishi paytida kodni optimallashtirish uchun shunchaki vaqt qolmaydi va yukni hisoblash resurslarini to'g'ridan-to'g'ri oshirish va gorizontal ravishda masshtablash orqali boshqarish kerak.
- Tashqi xizmatlarning kvotalari va ishlashi. Tez o'sish bilan nafaqat infratuzilmangizda, balki tashqi xizmatlarda ham muammolar paydo bo'lishi mumkin. Eng achinarlisi shundaki, bu muvaffaqiyatsizlik tufayli emas, balki kvotalar yoki cheklovlarga erishilganligi sababli sodir bo'ladi. Shuning uchun tashqi xizmatlar siz kabi miqyoslanishi kerak.
- Jarayonlar va navbatlarni alohida ajrating. Bu shlyuzlardan birida muammo yuzaga kelganda juda foydali. Agar to'liq SMS navbatlari axborot tizimlari o'rtasida bildirishnomalar almashinuviga xalaqit bermaganida, biz ma'lumotlar uzatishda kechikishlarga duch kelmas edik. Bundan tashqari, agar ular alohida ishlayotgan bo'lsa, ishchilar sonini ko'paytirish osonroq bo'lar edi.
- Moliyaviy voqeliklar. Ma'lumotlar oqimi keskin o'sib borayotgan paytda, tariflar va obunalar haqida tashvishlanishga vaqt yo'q. Lekin ularni yodda tutish muhimdir, ayniqsa siz kichik kompaniya bo'lsangiz. Har qanday API egasi, shuningdek, sizning xosting provayderingiz sizdan katta miqdorda to'lov undirishi mumkin. Shuning uchun, shartnomalaringizni diqqat bilan o'qing.
xulosa
Yo'qotishlarsiz emas, lekin biz bu bosqichdan omon qoldik va bugun biz kashf etgan barcha tamoyillarga rioya qilishga harakat qilamiz va har bir mashina kutilmagan hodisalarga dosh berish uchun unumdorlikni x4 marta osongina oshirish imkoniyatiga ega.
Kelgusi postlarda biz Apache Solr’da ishlash samaradorligining pasayishini tekshirish bo‘yicha tajribamiz bilan o‘rtoqlashamiz, so‘rovlarni optimallashtirishni muhokama qilamiz va Federal Soliq xizmati bilan ishlash kompaniyaga pulni tejashga qanday yordam berishini muhokama qilamiz. Yangiliklardan xabardor bo‘lish uchun blogimizga obuna bo‘ling va agar siz trafikning ko‘payishi paytida shunga o‘xshash muammolarga duch kelgan bo‘lsangiz, izohlarda bizga xabar bering.
So'rovda faqat ro'yxatdan o'tgan foydalanuvchilar ishtirok etishlari mumkin. iltimos.
Quyidagi sabablarga ko'ra yukning to'satdan oshishi tufayli xizmat ko'rsatishning sekinlashishi/pasayishini hech qachon boshdan kechirganmisiz:
55,6%Hisoblash resurslarini tezda qo'sha olmaslik10
16,7%Xosting provayderi infratuzilmasi cheklovlari3
33,3%Uchinchi tomon API cheklovlari6
27,8%Fuqaroligi yo'qlik tamoyillarining ularning arizalarida buzilishi5
88,9%O'z xizmatlari kodining optimal emasligi16
18 foydalanuvchi ovoz berdi. 6 nafar foydalanuvchi betaraf qolgan.
Manba: www.habr.com
