Көптеген стартаптар мұны бастан өткерді: көптеген жаңа пайдаланушылар күн сайын тіркеледі, ал әзірлеушілер тобы қызметтің жұмысын жалғастыру үшін күреседі.
Бұл жақсы мәселе, бірақ веб-бағдарламаны жоқтан жүздеген мың пайдаланушыларға дейін мұқият масштабтау туралы интернетте анық ақпарат аз. Әдетте өртке қарсы шешімдер немесе тығырықтан шығарылатын шешімдер (және жиі екеуі де) бар. Сондықтан адамдар өздерінің әуесқойлық жобаларын шынымен маңызды нәрсеге айналдыру үшін өте қарапайым әдістерді пайдаланады.
Ақпаратты сүзгіден өткізіп, негізгі формуланы жазып көрейік. Біз Graminsta фотосуреттерін бөлісетін жаңа сайтымызды 1-ден 100 000 пайдаланушыға дейін біртіндеп кеңейтеміз.
Аудитория 10, 100, 1000, 10 000 және 100 000 адамға көбейген кезде қандай нақты әрекеттер жасау керектігін жазып көрейік.
1 пайдаланушы: 1 машина
Әрбір дерлік қолданба, мейлі ол веб-сайт немесе мобильді қосымша болсын, үш негізгі компоненттен тұрады:
- API
- мәліметтер базасы
- клиент (мобильді қосымшаның өзі немесе веб-сайт)
Дерекқор тұрақты деректерді сақтайды. API осы деректерге және айналасындағы сұрауларға қызмет етеді. Клиент деректерді пайдаланушыға жібереді.
Мен архитектуралық тұрғыдан клиент пен API нысандары толығымен бөлінген болса, қолданбаны масштабтау туралы айту әлдеқайда оңай деген қорытындыға келдім.
Қолданбаны құруды бірінші рет бастағанда, барлық үш компонентті бір серверде іске қосуға болады. Кейбір жолдармен бұл біздің әзірлеу ортамызға ұқсас: бір инженер дерекқорды, API және клиентті бір құрылғыда басқарады.
Теориялық тұрғыдан біз оны төменде көрсетілгендей бір DigitalOcean Droplet немесе AWS EC2 данасында бұлтта орналастыра аламыз:
Осыған байланысты, егер сайтта бірнеше пайдаланушы болса, дерекқор қабатын арнау әрқашан дерлік мағынасы бар.
10 пайдаланушы: дерекқорды бөлек деңгейге жылжыту
Дерекқорды Amazon RDS немесе Digital Ocean Managed Database сияқты басқарылатын қызметтерге бөлу бізге ұзақ уақыт бойы жақсы қызмет етеді. Бұл бір компьютерде немесе EC2 данасында өзін-өзі хостингтен сәл қымбатырақ, бірақ бұл қызметтер арқылы сіз болашақта пайдалы болатын қораптан көптеген пайдалы кеңейтімдерді аласыз: көп аймақтық сақтық көшірме, оқу көшірмелері, автоматты сақтық көшірмелер және т.б.
Жүйе қазір осылай көрінеді:
100 пайдаланушы: клиентті бөлек деңгейге жылжыту
Бақытымызға орай, біздің алғашқы пайдаланушыларымызға қолданбамыз қатты ұнады. Трафик тұрақты болып келеді, сондықтан клиентті бөлек деңгейге көшіру уақыты келді. Айта кету керек бөлу нысандар масштабталатын қолданбаны құрудың негізгі аспектісі болып табылады. Жүйенің бір бөлігі көбірек трафик алатындықтан, қызметтің нақты трафик үлгілеріне негізделген масштабтауын басқару үшін оны бөлуге болады.
Сондықтан мен клиентті API интерфейсінен бөлек деп санағым келеді. Бұл бірнеше платформалар үшін әзірлеу туралы ойлауды өте жеңілдетеді: веб, мобильді веб, iOS, Android, жұмыс үстелі қолданбалары, үшінші тарап қызметтері және т.б. Олардың барлығы бірдей API пайдаланатын клиенттер.
Мысалы, қазір біздің қолданушылар мобильді қосымшаны шығаруды жиі сұрайды. Клиент пен API нысандарын бөлсеңіз, бұл оңайырақ болады.
Мұндай жүйе келесідей көрінеді:
1000 пайдаланушы: жүктеме балансын қосыңыз
Істер көтеріліп жатыр. Graminsta пайдаланушылары көбірек фотосуреттерді жүктеп жатыр. Тіркеу саны да артып келеді. Біздің жалғыз API серверіміз барлық трафикті ұстап тұру қиынға соғуда. Көбірек темір керек!
Жүктеме балансы - бұл өте күшті тұжырымдама. Негізгі идея мынада: API алдына жүктеме теңестіруші орнатамыз және ол трафикті жеке қызмет даналарына таратады. Осылайша біз көлденеңінен масштабтаймыз, яғни біз бірдей кодпен көбірек серверлерді қосамыз, өңдей алатын сұраулар санын көбейтеміз.
Біз веб-клиенттің алдына және API алдына бөлек жүктеме теңестірушілерін орналастырамыз. Бұл API кодын және веб-клиент кодын іске қосатын бірнеше даналарды іске қосуға болатындығын білдіреді. Жүктеме теңестіруші сұрауларды аз жүктелген серверге бағыттайды.
Мұнда біз тағы бір маңызды артықшылықты аламыз - артықшылық. Бір данасы сәтсіз болғанда (мүмкін, шамадан тыс жүктелген немесе бұзылған), біз кіріс сұрауларына жауап беруді жалғастыратын басқалармен қаламыз. Егер жұмыс істейтін бір ғана данасы болса, онда сәтсіздікке ұшыраған жағдайда бүкіл жүйе бұзылады.
Жүктеме балансы автоматты масштабтауды қамтамасыз етеді. Біз оны ең жоғары жүктеме алдындағы даналар санын көбейту және барлық пайдаланушылар ұйықтап жатқанда азайту үшін конфигурациялай аламыз.
Жүктеме теңестіргішімен API деңгейін шектеусіз дерлік масштабтауға болады, жай ғана сұраулар саны артқан сайын жаңа даналарды қосады.
Ескерту. Дәл қазір біздің жүйе AWS-тегі Heroku немесе Elastic Beanstalk сияқты PaaS компанияларының қораптан тыс ұсынатынына өте ұқсас (олар соншалықты танымал). Heroku дерекқорды бөлек хостқа орналастырады, автоматты масштабталатын жүктеме балансын басқарады және веб-клиентті API-ден бөлек орналастыруға мүмкіндік береді. Бұл ерте кезеңдегі жобалар немесе стартаптар үшін Heroku пайдаланудың тамаша себебі - сіз барлық негізгі қызметтерді қораптан аласыз.
10 000 пайдаланушы: CDN
Мүмкін, біз мұны әу бастан жасауымыз керек еді. Сұраныстарды өңдеу және жаңа фотосуреттерді қабылдау серверлерімізге тым көп салмақ түсіре бастады.
Бұл кезеңде статикалық мазмұнды - кескіндерді, бейнелерді және т.б. сақтауға арналған бұлттық қызметті пайдалану қажет (AWS S3 немесе Digital Ocean Spaces). Жалпы, біздің API кескіндерге қызмет көрсету және кескіндерді серверге жүктеп салу сияқты нәрселерді өңдеуден аулақ болуы керек.
Бұлтты хостингтің тағы бір артықшылығы - CDN (AWS бұл қондырманы Cloudfront деп атайды, бірақ көптеген бұлтты сақтау провайдерлері оны қораптан тыс ұсынады). CDN бүкіл әлем бойынша әртүрлі деректер орталықтарындағы кескіндерді автоматты түрде кэштейді.
Біздің негізгі деректер орталығымыз Огайо штатында орналасуы мүмкін болса да, егер біреу Жапониядан сурет сұраса, бұлттық провайдер оның көшірмесін жасап, оны жапондық деректер орталығында сақтайды. Жапонияда бұл суретті сұраған келесі адам оны тезірек алады. Бұл фотосуреттер немесе бейнелер сияқты үлкен файлдармен жұмыс істегенде маңызды, олар жүктеп алу және бүкіл планета бойынша тасымалдау үшін көп уақыт алады.
100 000 пайдаланушы: деректер деңгейін масштабтау
CDN көп көмектесті: трафик толық жылдамдықпен өсуде. Әйгілі видеоблогер Мавид Мобрик жаңа ғана бізге тіркеліп, олар айтқандай, өзінің «тарихын» жариялады. Жүктеме теңестіру құралының арқасында API серверлерінде CPU және жадты пайдалану төмен деңгейде сақталады (API он данасы жұмыс істейді), бірақ біз сұраулар бойынша көп күту уақытын ала бастадық... бұл кешігулер қайдан пайда болады?
Көрсеткіштерге аздап үңілсек, дерекқор серверіндегі CPU 80-90% жүктелгенін көреміз. Біз шекке жеттік.
Деректер деңгейін масштабтау теңдеудің ең қиын бөлігі болуы мүмкін. API серверлері азаматтығы жоқ сұрауларға қызмет етеді, сондықтан біз жай ғана қосымша API даналарын қосамыз. Мұрын көпшілік дерекқорлар мұны істей алмайды. Біз танымал реляциялық дерекқорды басқару жүйелері (PostgreSQL, MySQL және т.б.) туралы айтатын боламыз.
кэштеу
Дерекқордың өнімділігін арттырудың ең оңай жолдарының бірі - жаңа компонентті енгізу: кэш қабаты. Ең кең тараған кэштеу әдісі - Redis немесе Memcached сияқты жадтағы кілт-мән жазбалары қоймасы. Көптеген бұлттарда осы қызметтердің басқарылатын нұсқасы бар: AWS жүйесіндегі Elasticache және Google Cloud жүйесіндегі Memorystore.
Кэш қызмет бірдей ақпаратты алу үшін дерекқорға көптеген қайталанатын қоңыраулар жасағанда пайдалы. Негізінде, біз дерекқорға бір рет қол жеткіземіз, ақпаратты кэште сақтаймыз және оны қайта ұстамаймыз.
Мысалы, біздің Graminsta қызметінде біреу Mobrik жұлдызының профиль бетіне өткен сайын, API сервері оның профилінен ақпарат алу үшін дерекқордан сұрайды. Бұл қайта-қайта қайталанады. Mobrik профилінің ақпараты әр сұраумен өзгермейтіндіктен, ол кэштеу үшін тамаша.
Редистегі дерекқордан алынған нәтижелерді кілт арқылы кэштейміз user:id жарамдылық мерзімі 30 секунд. Енді біреу Mobrik профиліне кіргенде, біз алдымен Redis-ті тексереміз, ал егер деректер бар болса, біз оны тікелей Redis-тен тасымалдаймыз. Енді сайттағы ең танымал профильге сұраныстар біздің дерекқорымызды іс жүзінде жүктемейді.
Кэштеу қызметтерінің көпшілігінің тағы бір артықшылығы дерекқор серверлеріне қарағанда оларды масштабтау оңайырақ. Redis-те кірістірілген Redis кластері режимі бар. Жүктеме теңестірушіге ұқсас, ол Redis кэшін бірнеше машиналарға (қажет болса мыңдаған серверлер арқылы) таратуға мүмкіндік береді.
Барлық дерлік ауқымды қолданбалар кэштеуді пайдаланады; бұл жылдам API-нің ажырамас бөлігі болып табылады. Сұрауларды жылдам өңдеу және өнімдірек кодтың бәрі маңызды, бірақ кэшсіз миллиондаған пайдаланушылар үшін қызметті масштабтау мүмкін емес.
Көшірмелерді оқыңыз
Дерекқорға сұраулар саны айтарлықтай өскен кезде, біз жасай алатын тағы бір нәрсе - дерекқорды басқару жүйесіне оқылған көшірмелерді қосу. Жоғарыда сипатталған басқарылатын қызметтермен мұны бір рет басу арқылы жасауға болады. Оқу репликасы негізгі дерекқорда ағымдағы болып қалады және SELECT мәлімдемелері үшін қолжетімді.
Міне, қазір біздің жүйе:
Келесі қадамдар
Қолданба масштабтауды жалғастыруда, біз қызметтерді дербес масштабтау үшін бөлуді жалғастырамыз. Мысалы, егер біз Websockets пайдалануды бастасақ, Websockets өңдеу кодын бөлек қызметке тарту мағынасы бар. Біз оны ашық Websockets қосылымдары негізінде және HTTP сұрауларының санына қарамастан үлкейтетін және кішірейтетін жеке жүктеме теңестіруішіміздің артындағы жаңа даналарға орналастыра аламыз.
Біз сондай-ақ дерекқор деңгейіндегі шектеулермен күресуді жалғастырамыз. Дәл осы кезеңде дерекқорды бөлу және бөлуді зерттеу уақыты келді. Екі тәсіл де қосымша шығындарды талап етеді, бірақ дерекқорды шексіз дерлік масштабтауға мүмкіндік береді.
Біз сондай-ақ New Relic немесе Datadog сияқты мониторинг және талдау қызметін орнатқымыз келеді. Бұл баяу сұрауларды анықтауға және қай жерде жақсарту қажет екенін түсінуге көмектеседі. Біз масштабтау кезінде қиындықтарды табуға және оларды жоюға назар аударғымыз келеді - көбінесе алдыңғы бөлімдердегі кейбір идеяларды пайдаланамыз.
Ақпарат көздері
Бұл жазбаның біреуі шабыттандырады . Мен мақаланы жобалардың бастапқы кезеңдері үшін біршама нақтырақ етіп, оны бір жеткізушіден шешкім келді. Бұл тақырып сізді қызықтырса, міндетті түрде оқыңыз.
Сілтемелер
- Бірнеше даналар бойынша жүктемені бөлу тұрғысынан ұқсас болғанымен, Redis кластерінің негізгі іске асырылуы жүктеме теңестірушіден өте ерекшеленеді.
Ақпарат көзі: www.habr.com