Многу стартапи поминаа низ ова: мноштво нови корисници се регистрираат секој ден, а тимот за развој се бори да ја одржи услугата да работи.

Убав проблем е да се има, но има малку јасни информации на интернет за тоа како внимателно да се зголеми веб-апликацијата од ништо на стотици илјади корисници. Обично постојат или решенија за пожар или решенија за тесно грло (и често и двете). Затоа, луѓето користат прилично клишени техники за да го размерат нивниот аматерски проект во нешто навистина сериозно.

Ајде да се обидеме да ги филтрираме информациите и да ја запишеме основната формула. Ќе ја зголемиме нашата нова страница за споделување фотографии Граминста чекор по чекор од 1 на 100 корисници.

Ајде да запишеме кои конкретни активности треба да се преземат кога публиката ќе се зголеми на 10, 100, 1000, 10 и 000 луѓе.

1 корисник: 1 машина

Речиси секоја апликација, било да е тоа веб-локација или мобилна апликација, има три клучни компоненти:

• API
• база на податоци
• клиент (самата мобилна апликација или веб-страница)

Базата на податоци складира постојани податоци. API опслужува барања до и околу овие податоци. Клиентот ги пренесува податоците на корисникот.

Дојдов до заклучок дека е многу полесно да се зборува за скалирање на апликација ако, од архитектонска гледна точка, ентитетите на клиентот и API се целосно одвоени.

Кога првпат почнуваме да градиме апликација, сите три компоненти може да се извршуваат на истиот сервер. На некој начин, ова е слично на нашата развојна околина: еден инженер ја води базата на податоци, API и клиентот на истата машина.

Во теорија, би можеле да го распоредиме во облакот на еден примерок DigitalOcean Droplet или AWS EC2, како што е прикажано подолу:

Со тоа, ако ќе има повеќе од еден корисник на страницата, речиси секогаш има смисла да се посвети слој на база на податоци.

10 корисници: преместување на базата на податоци на посебно ниво

Поделбата на базата на податоци на управувани услуги како Amazon RDS или Дигитална база на податоци управувана од океанот ќе ни служи добро долго време. Тоа е малку поскапо од само-хостирање на една машина или примерок EC2, но со овие услуги добивате многу корисни екстензии надвор од кутијата што ќе ви бидат корисни во иднина: резервна копија од повеќе региони, читање реплики, автоматски резервни копии и многу повеќе.

Еве како изгледа системот сега:

100 корисници: преместување на клиентот на посебно ниво

За среќа, на нашите први корисници навистина им се допадна нашата апликација. Сообраќајот станува постабилен, па време е клиентот да се премести на посебно ниво. Треба да се напомене дека разделба ентитетите е клучен аспект за градење на скалабилна апликација. Бидејќи еден дел од системот добива повеќе сообраќај, можеме да го поделиме за да контролираме како се скалира услугата врз основа на специфични сообраќајни обрасци.

Ова е причината зошто сакам да мислам на клиентот како одделен од API. Ова го прави многу лесно да се размислува за развој за повеќе платформи: веб, мобилен веб, iOS, Android, десктоп апликации, услуги од трети страни итн. Сите тие се само клиенти кои користат ист API.

На пример, сега нашите корисници најчесто бараат да пуштат мобилна апликација. Ако ги одделите клиентот и ентитетите на API, ова станува полесно.

Вака изгледа таков систем:

1000 корисници: додадете балансер на оптоварување

Работите се гледаат нагоре. Корисниците на Граминста прикачуваат се повеќе фотографии. Расте и бројот на регистрации. Нашиот осамен API сервер тешко го следи целиот сообраќај. Треба повеќе железо!

Балансерот на оптоварување е многу моќен концепт. Клучната идеја е да ставиме балансирач на оптоварување пред API, и тој го дистрибуира сообраќајот до поединечни примероци на услуги. Ова е начинот на кој се скалираме хоризонтално, што значи дека додаваме повеќе сервери со истиот код, зголемувајќи го бројот на барања што можеме да ги обработиме.

Ќе поставиме посебни балансери на оптоварување пред веб-клиентот и пред API. Ова значи дека можете да извршите повеќе примероци со API код и код на веб-клиент. Балансерот на оптоварување ќе ги насочува барањата до серверот што е помалку вчитан.

Овде добиваме уште една важна предност - вишок. Кога еден пример не успее (можеби преоптоварен или паднат), остануваме со други кои продолжуваат да одговараат на дојдовните барања. Ако работеше само еден пример, тогаш во случај на неуспех целиот систем ќе се сруши.

Балансерот на оптоварување обезбедува и автоматско скалирање. Можеме да го конфигурираме да го зголемува бројот на примероци пред максимално оптоварување и да го намалиме кога сите корисници спијат.

Со балансерот на оптоварување, нивото на API може да се скалира речиси на неодредено време, едноставно додавајќи нови примероци како што се зголемува бројот на барања.

Забелешка. Во моментов, нашиот систем е многу сличен на она што го нудат компаниите PaaS како Heroku или Elastic Beanstalk на AWS надвор од кутијата (поради што тие се толку популарни). Heroku ја става базата на податоци на посебен хост, управува со балансирачот на оптоварување со автоматско скалирање и ви овозможува да го хостирате веб-клиентот одделно од API. Ова е одлична причина да го користите Heroku за проекти во рана фаза или стартапи - ги добивате сите основни услуги надвор од кутијата.

10 корисници: CDN

Можеби требаше да го направиме ова од самиот почеток. Обработката на барањата и прифаќањето нови фотографии почнува премногу да ги оптоварува нашите сервери.

Во оваа фаза, треба да користите облак услуга за складирање статична содржина - слики, видеа и многу повеќе (AWS S3 или Digital Ocean Spaces). Општо земено, нашиот API треба да избегнува да ракува со работи како што се сервисирање слики и поставување слики на серверот.

Друга предност на облак хостинг е CDN (AWS го нарекува овој додаток Cloudfront, но многу провајдери за складирање облак го нудат надвор од кутијата). CDN автоматски ги кешира нашите слики во различни центри за податоци низ светот.

Иако нашиот главен центар за податоци може да се наоѓа во Охајо, доколку некој побара слика од Јапонија, давателот на облак ќе направи копија и ќе ја складира во нивниот јапонски центар за податоци. Следниот човек кој ќе ја побара оваа слика во Јапонија ќе ја добие многу побрзо. Ова е важно кога работиме со големи датотеки, како фотографии или видеа, на кои им треба долго време за преземање и пренесување низ целата планета.

100 корисници: скалирање на податочниот слој

CDN помогна многу: сообраќајот расте со полна брзина. Познатиот видео блогер Мавид Мобрик штотуку се регистрираше кај нас и ја објави својата „приказна“, како што велат. Благодарение на балансерот на оптоварување, употребата на процесорот и меморијата на серверите на API се одржува на ниско ниво (десет примероци на API работат), но почнуваме да добиваме многу тајмаути на барањата... од каде доаѓаат овие одложувања?

Копајќи малку во метриката, гледаме дека процесорот на серверот на базата на податоци е вчитан 80-90%. На граница сме.

Скалирањето на податочниот слој е веројатно најтешкиот дел од равенката. API серверите опслужуваат барања без државјанство, па едноставно додаваме повеќе примероци на API. Носот мнозинството базите на податоци не можат да го направат тоа. Ќе зборуваме за популарни системи за управување со релациони бази на податоци (PostgreSQL, MySQL, итн.).

кеширање

Еден од најлесните начини за зголемување на перформансите на нашата база на податоци е да се воведе нова компонента: слојот на кешот. Најчестиот метод за кеширање е складиште за евиденција со вредност на клучот во меморијата, како што се Redis или Memcached. Повеќето облаци имаат управувана верзија на овие услуги: Elasticache на AWS и Memorystore на Google Cloud.

Кешот е корисен кога услугата прави многу повторени повици до базата на податоци за да ги врати истите информации. Во суштина, пристапуваме до базата на податоци само еднаш, ги складираме информациите во кешот и не ги допираме повторно.

На пример, во нашата услуга Граминста, секогаш кога некој ќе оди на страницата на профилот на ѕвездата Мобрик, серверот API ја бара базата на податоци за информации од неговиот профил. Ова се случува повторно и повторно. Бидејќи информациите за профилот на Mobrik не се менуваат со секое барање, тие се одлични за кеширање.

Ќе ги кешираме резултатите од базата на податоци во Редис по клуч user:id со рок на важност од 30 секунди. Сега, кога некој ќе отиде на профилот на Мобрик, ние прво го проверуваме Редис, а ако ги има податоците, едноставно ги пренесуваме директно од Редис. Сега барањата до најпопуларниот профил на страницата практично не ја вчитуваат нашата база на податоци.

Друга предност на повеќето услуги за кеширање е тоа што тие се полесни за скалирање од серверите за бази на податоци. Redis има вграден режим Redis Cluster. Слично на балансерот на оптоварување1, ви овозможува да го дистрибуирате вашиот Redis кеш низ повеќе машини (по потреба низ илјадници сервери).

Речиси сите големи апликации користат кеширање; тоа е апсолутно составен дел на брз API. Побрзата обработка на барањата и попродуктивниот код се сите важни, но без кеш е речиси невозможно да се зголеми услугата за милиони корисници.

Прочитајте реплики

Кога бројот на прашања во базата е значително зголемен, уште една работа што можеме да направиме е да додадеме читани реплики во системот за управување со базата на податоци. Со управуваните услуги опишани погоре, ова може да се направи со еден клик. Читаната реплика ќе остане актуелна во главната база на податоци и е достапна за SELECT изјави.

Еве го нашиот систем сега:

Следни чекори

Како што апликацијата продолжува да се скалира, ние ќе продолжиме да ги одвојуваме услугите за да ги скалираме независно. На пример, ако почнеме да користиме Websockets, тогаш има смисла да го повлечеме кодот за обработка на Websockets во посебна услуга. Можеме да го поставиме на нови примероци зад нашиот сопствен балансирач на оптоварување, кој може да се зголемува нагоре и надолу врз основа на отворените врски на Websockets и без оглед на бројот на барања за HTTP.

Ние, исто така, ќе продолжиме да се бориме со ограничувањата на ниво на базата на податоци. Во оваа фаза е време да се проучи партиционирањето и делењето на базата на податоци. И двата пристапа бараат дополнителни трошоци, но ви дозволуваат да ја размерите базата на податоци речиси на неодредено време.

Исто така, сакаме да инсталираме услуга за следење и анализа како New Relic или Datadog. Ова ќе ви помогне да идентификувате бавни прашања и да разберете каде е потребно подобрување. Како што скалираме, сакаме да се фокусираме на наоѓање тесни грла и нивно елиминирање - често користејќи некои од идеите од претходните делови.

Извори

Овој пост е инспириран од еден од моите омилени објави за висока приспособливост. Сакав да ја направам статијата малку поконкретна за почетните фази на проектите и да ја одврзам од еден продавач. Задолжително прочитајте доколку ве интересира оваа тема.

Фусноти

1. Иако е слична во однос на дистрибуцијата на оптоварување низ повеќе примероци, основната имплементација на кластерот Redis е многу различна од балансерот на оптоварување. [враќање]

Извор: www.habr.com