Ko'pgina startaplar buni boshdan kechirdilar: ko'plab yangi foydalanuvchilar har kuni ro'yxatdan o'tishadi va ishlab chiqish guruhi xizmatni davom ettirish uchun kurashadi.
Bu juda yaxshi muammo, lekin veb-ilovani qanday qilib ehtiyotkorlik bilan yo'qdan yuz minglab foydalanuvchilarga o'lchash haqida Internetda aniq ma'lumot yo'q. Odatda yong'inga qarshi echimlar yoki darboΔaz echimlari (va ko'pincha ikkalasi) mavjud. Shuning uchun, odamlar o'zlarining havaskor loyihalarini haqiqatan ham jiddiy narsaga aylantirish uchun juda oddiy usullardan foydalanadilar.
Keling, ma'lumotni filtrlash va asosiy formulani yozishga harakat qilaylik. Biz yangi Graminsta fotosuratlar almashish saytimizni bosqichma-bosqich 1 dan 100 000 foydalanuvchigacha kengaytirmoqchimiz.
Keling, tomoshabinlar 10, 100, 1000, 10 000 va 100 000 kishiga ko'payganda qanday aniq harakatlar qilish kerakligini yozamiz.
1 foydalanuvchi: 1 ta mashina
Deyarli har bir ilova, xoh u veb-sayt, xoh mobil ilova, uchta asosiy komponentga ega:
- API
- malumotlar bazasi
- mijoz (mobil ilovaning o'zi yoki veb-sayt)
Ma'lumotlar bazasi doimiy ma'lumotlarni saqlaydi. API ushbu ma'lumotlarga va uning atrofida so'rovlarga xizmat qiladi. Mijoz ma'lumotlarni foydalanuvchiga uzatadi.
Agar arxitektura nuqtai nazaridan mijoz va API ob'ektlari butunlay ajratilgan bo'lsa, dasturni masshtablash haqida gapirish ancha oson degan xulosaga keldim.
Ilovani birinchi marta yaratishni boshlaganimizda, barcha uchta komponent bir xil serverda ishlashi mumkin. Qaysidir ma'noda, bu bizning ishlab chiqish muhitimizga o'xshaydi: bitta muhandis ma'lumotlar bazasi, API va mijozni bitta mashinada boshqaradi.
Nazariy jihatdan, biz uni bulutda bitta DigitalOcean Droplet yoki AWS EC2 misolida joylashtirishimiz mumkin, quyida ko'rsatilganidek:
Shu bilan birga, agar saytda bir nechta foydalanuvchi bo'lsa, ma'lumotlar bazasi qatlamini ajratish deyarli har doim mantiqiy bo'ladi.
10 foydalanuvchi: ma'lumotlar bazasini alohida darajaga ko'chirish
Ma'lumotlar bazasini Amazon RDS yoki Digital Ocean Managed Database kabi boshqariladigan xizmatlarga bo'lish bizga uzoq vaqt xizmat qiladi. Bu bitta kompyuterda yoki EC2 nusxasida o'z-o'zini xostingdan ko'ra biroz qimmatroq, ammo bu xizmatlar yordamida siz kelajakda foydali bo'ladigan juda ko'p foydali kengaytmalarga ega bo'lasiz: ko'p mintaqaviy zaxira, o'qish replikalari, avtomatik zaxira nusxalari va boshqalar.
Endi tizim shunday ko'rinadi:
100 foydalanuvchi: mijozni alohida darajaga ko'chirish
Yaxshiyamki, bizning birinchi foydalanuvchilarga ilovamiz juda yoqdi. Trafik barqaror bo'lib bormoqda, shuning uchun mijozni alohida darajaga o'tkazish vaqti keldi. Shuni ta'kidlash kerak ajratish ob'ektlar kengaytiriladigan dasturni yaratishning asosiy jihati hisoblanadi. Tizimning bir qismi ko'proq trafikni qabul qilganligi sababli, biz ma'lum trafik naqshlari asosida xizmat ko'lamini boshqarish uchun uni qismlarga ajratishimiz mumkin.
Shuning uchun men mijozni API dan alohida deb o'ylashni yaxshi ko'raman. Bu bir nechta platformalar uchun ishlab chiqish haqida o'ylashni juda osonlashtiradi: veb, mobil veb, iOS, Android, ish stoli ilovalari, uchinchi tomon xizmatlari va boshqalar. Ularning barchasi bir xil APIdan foydalanadigan mijozlardir.
Misol uchun, endi bizning foydalanuvchilarimiz ko'pincha mobil ilovani chiqarishni so'rashadi. Agar siz mijoz va API ob'ektlarini ajratsangiz, bu osonroq bo'ladi.
Bunday tizim shunday ko'rinadi:
1000 foydalanuvchi: yuk balansini qo'shing
Ishlar yuqoriga qarab ketmoqda. Graminsta foydalanuvchilari tobora ko'proq fotosuratlar yuklamoqda. Roβyxatga olinganlar soni ham ortib bormoqda. Bizning yagona API serverimiz barcha trafikni ushlab turishda qiynalmoqda. Ko'proq temir kerak!
Yuk balanslagichi juda kuchli tushunchadir. Asosiy g'oya shundan iboratki, biz API oldiga yuk balanslagichini qo'yamiz va u trafikni alohida xizmat ko'rsatish misollariga taqsimlaydi. Shunday qilib, biz gorizontal ravishda o'lchaymiz, ya'ni biz bir xil kodga ega bo'lgan ko'proq serverlarni qo'shamiz va qayta ishlashimiz mumkin bo'lgan so'rovlar sonini ko'paytiramiz.
Biz veb-mijoz va API oldida alohida yuk balanslagichlarini joylashtirmoqchimiz. Bu API kodi va veb-mijoz kodi bilan ishlaydigan bir nechta misollarni ishga tushirishingiz mumkinligini anglatadi. Yuk balanslagichi so'rovlarni kamroq yuklangan serverga yo'naltiradi.
Bu erda biz yana bir muhim afzalliklarga ega bo'lamiz - ortiqcha. Bitta nusxa ishlamay qolganda (ehtimol haddan tashqari yuklangan yoki ishdan chiqqan), biz kiruvchi so'rovlarga javob berishda davom etadigan boshqalar bilan qolamiz. Agar faqat bitta misol ishlayotgan bo'lsa, unda ishlamay qolganda butun tizim ishdan chiqadi.
Yuk balanslagichi avtomatik o'lchovni ham ta'minlaydi. Biz uni eng yuqori yuklanishgacha bo'lgan holatlar sonini ko'paytirish va barcha foydalanuvchilar uxlayotganda kamaytirish uchun sozlashimiz mumkin.
Yuk balanslagichi yordamida API darajasi deyarli cheksiz ravishda kengaytirilishi mumkin, shunchaki so'rovlar soni ortishi bilan yangi misollar qo'shiladi.
Eslatma. Hozirda bizning tizimimiz AWS-dagi Heroku yoki Elastic Beanstalk kabi PaaS kompaniyalari taklif qiladigan narsalarga juda o'xshaydi (shuning uchun ular juda mashhur). Heroku ma'lumotlar bazasini alohida xostga joylashtiradi, avtomatik o'lchamdagi yuk balansini boshqaradi va veb-mijozni API'dan alohida joylashtirish imkonini beradi. Bu Heroku-dan dastlabki loyihalar yoki startaplar uchun foydalanish uchun ajoyib sababdir - siz barcha asosiy xizmatlarni qutidan olasiz.
10 000 foydalanuvchi: CDN
Ehtimol, biz buni boshidanoq qilishimiz kerak edi. So'rovlarni qayta ishlash va yangi fotosuratlarni qabul qilish bizning serverlarimizga juda ko'p yuklarni keltirib chiqarmoqda.
Ushbu bosqichda siz statik tarkibni saqlash uchun bulut xizmatidan foydalanishingiz kerak - tasvirlar, videolar va boshqa ko'p narsalar (AWS S3 yoki Digital Ocean Spaces). Umuman olganda, bizning API rasmlarga xizmat ko'rsatish va rasmlarni serverga yuklash kabi ishlarni bajarishdan qochishi kerak.
Bulutli xostingning yana bir afzalligi - bu CDN (AWS ushbu plaginni Cloudfront deb ataydi, lekin ko'plab bulutli saqlash provayderlari uni qutidan tashqarida taklif qilishadi). CDN butun dunyo bo'ylab turli ma'lumotlar markazlarida bizning rasmlarimizni avtomatik ravishda keshlaydi.
Bizning asosiy ma'lumotlar markazimiz Ogayo shtatida joylashgan bo'lishi mumkin bo'lsa-da, agar kimdir Yaponiyadan rasm so'rasa, bulut provayderi uning nusxasini yaratadi va uning yapon ma'lumotlar markazida saqlaydi. Yaponiyada ushbu rasmni so'ragan keyingi odam uni tezroq oladi. Bu biz sayyora bo'ylab yuklab olish va uzatish uchun uzoq vaqt talab qiladigan fotosuratlar yoki videolar kabi katta fayllar bilan ishlaganimizda muhim ahamiyatga ega.
100 000 foydalanuvchi: ma'lumotlar qatlamini masshtablash
CDN ko'p yordam berdi: trafik to'liq tezlikda o'sib bormoqda. Mashhur videobloger Mavid Mobrik bizda ro'yxatdan o'tdi va ular aytganidek, o'zining "hikoyasini" joylashtirdi. Yuk balanslagichi tufayli API serverlarida protsessor va xotiradan foydalanish past darajada saqlanadi (o'nta API misoli ishlamoqda), lekin biz so'rovlar bo'yicha ko'p vaqt autlarini olishni boshlaymiz... bu kechikishlar qayerdan kelib chiqadi?
Ko'rsatkichlarni biroz qazib olsak, ma'lumotlar bazasi serveridagi CPU 80-90% yuklanganligini ko'ramiz. Biz chegaradamiz.
Ma'lumotlar qatlamini masshtablash, ehtimol, tenglamaning eng qiyin qismidir. API serverlari fuqaroligi bo'lmagan so'rovlarga xizmat qiladi, shuning uchun biz ko'proq API misollarini qo'shamiz. Burun ko'pchilik ma'lumotlar bazalari buni qila olmaydi. Biz mashhur relyatsion ma'lumotlar bazasini boshqarish tizimlari (PostgreSQL, MySQL va boshqalar) haqida gapiramiz.
keshlash
Ma'lumotlar bazasining ishlashini oshirishning eng oson usullaridan biri bu yangi komponentni joriy qilishdir: kesh qatlami. Eng keng tarqalgan keshlash usuli - bu Redis yoki Memcached kabi xotiradagi kalit-qiymat yozuvlari do'koni. Aksariyat bulutlarda ushbu xizmatlarning boshqariladigan versiyasi mavjud: AWS-da Elasticache va Google Cloud-da Memorystore.
Xizmat bir xil ma'lumotni olish uchun ma'lumotlar bazasiga ko'p takroriy qo'ng'iroqlarni amalga oshirganda kesh foydali bo'ladi. Aslida, biz ma'lumotlar bazasiga faqat bir marta kiramiz, ma'lumotlarni keshda saqlaymiz va unga boshqa tegmaymiz.
Misol uchun, bizning Graminsta xizmatimizda kimdir Mobrik yulduzining profil sahifasiga har safar kirganida, API serveri uning profilidan ma'lumot olish uchun ma'lumotlar bazasini so'raydi. Bu yana va yana sodir bo'ladi. Mobrikning profil ma'lumotlari har bir so'rov bilan o'zgarmasligi sababli, u keshlash uchun juda yaxshi.
Biz Redis-dagi ma'lumotlar bazasidan olingan natijalarni kalit bo'yicha keshlaymiz user:id 30 soniya amal qilish muddati bilan. Endi, kimdir Mobrikning profiliga kirsa, biz avval Redisni tekshiramiz va agar ma'lumotlar mavjud bo'lsa, biz uni to'g'ridan-to'g'ri Redisdan o'tkazamiz. Endi saytdagi eng mashhur profilga so'rovlar bizning ma'lumotlar bazasini deyarli yuklamaydi.
Ko'pgina keshlash xizmatlarining yana bir afzalligi shundaki, ular ma'lumotlar bazasi serverlariga qaraganda osonroq. Redis o'rnatilgan Redis Cluster rejimiga ega. Yuk balanslagichiga o'xshaydi, u sizga Redis keshingizni bir nechta mashinalarda (kerak bo'lsa, minglab serverlar bo'ylab) tarqatish imkonini beradi.
Deyarli barcha keng ko'lamli ilovalar keshlashdan foydalanadi; bu tezkor API ning mutlaqo ajralmas qismidir. So'rovlarni tezroq qayta ishlash va yanada samarali kod - bularning barchasi muhim, ammo keshsiz xizmatni millionlab foydalanuvchilarga kengaytirish deyarli mumkin emas.
Replikalarni o'qing
Ma'lumotlar bazasiga so'rovlar soni sezilarli darajada oshganda, biz qila oladigan yana bir narsa ma'lumotlar bazasini boshqarish tizimiga o'qilgan replikalarni qo'shishdir. Yuqorida tavsiflangan boshqariladigan xizmatlar bilan buni bir marta bosish orqali amalga oshirish mumkin. O'qilgan replika asosiy ma'lumotlar bazasida joriy bo'lib qoladi va SELECT iboralari uchun mavjud.
Mana endi bizning tizimimiz:
Keyingi qadamlar
Ilova kengayishda davom etar ekan, biz xizmatlarni mustaqil ravishda kengaytirish uchun ajratishda davom etamiz. Misol uchun, agar biz Websockets-dan foydalanishni boshlasak, Websockets ishlov berish kodini alohida xizmatga jalb qilish mantiqan to'g'ri keladi. Biz uni o'z yuk balanslagichimiz orqasidagi yangi nusxalarga joylashtirishimiz mumkin, ular ochiq Websockets ulanishlari asosida va HTTP so'rovlari sonidan qat'iy nazar, kattalashtirish va pasaytirish mumkin.
Shuningdek, biz ma'lumotlar bazasi darajasidagi cheklovlarga qarshi kurashni davom ettiramiz. Aynan shu bosqichda ma'lumotlar bazasini bo'lish va parchalashni o'rganish vaqti keldi. Ikkala yondashuv ham qo'shimcha xarajatlarni talab qiladi, ammo ma'lumotlar bazasini deyarli cheksiz ravishda o'lchash imkonini beradi.
Shuningdek, biz New Relic yoki Datadog kabi monitoring va tahlil xizmatini oΚ»rnatmoqchimiz. Bu sekin so'rovlarni aniqlashga va qayerda yaxshilash kerakligini tushunishga yordam beradi. Masshtabni kengaytirganda, biz to'siqlarni topishga va ularni yo'q qilishga e'tibor qaratmoqchimiz - ko'pincha oldingi bo'limlardagi ba'zi g'oyalardan foydalanamiz.
Axborot manbalari
Ushbu post ulardan biri tomonidan ilhomlantirilgan . Men maqolani loyihalarning dastlabki bosqichlari uchun biroz aniqroq qilishni va uni bitta sotuvchidan ajratib olishni xohladim. Agar siz ushbu mavzuga qiziqsangiz, albatta o'qing.
Izohlar
- Bir nechta misollar bo'yicha yuk taqsimoti jihatidan o'xshash bo'lsa-da, Redis klasterining asosiy amalga oshirilishi yuk balanslagichidan juda farq qiladi.
Manba: www.habr.com