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

Хубаво е да имате проблем, но в мрежата има малко ясна информация за това как внимателно да мащабирате уеб приложение от нищо до стотици хиляди потребители. Обикновено има или противопожарни решения, или решения за тесни места (а често и двете). Затова хората използват доста клиширани техники, за да превърнат аматьорския си проект в нещо наистина сериозно.

Нека се опитаме да филтрираме информацията и да запишем основната формула. Ние ще увеличим нашия нов сайт за споделяне на снимки 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 може да се мащабира почти безкрайно, като просто се добавят нови екземпляри с увеличаване на броя на заявките.

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

10 000 потребители: CDN

Може би трябваше да направим това от самото начало. Обработката на заявки и приемането на нови снимки започва да натоварва твърде много нашите сървъри.

На този етап трябва да използвате облачна услуга за съхранение на статично съдържание – изображения, видео и много други (AWS S3 или Digital Ocean Spaces). Като цяло нашият API трябва да избягва работа с неща като обслужване на изображения и качване на изображения на сървъра.

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

Въпреки че основният ни център за данни може да се намира в Охайо, ако някой поиска изображение от Япония, облачният доставчик ще направи копие и ще го съхрани в своя японски център за данни. Следващият човек, който поиска това изображение в Япония, ще го получи много по-бързо. Това е важно, когато работим с големи файлове, като снимки или видеоклипове, които отнемат много време за изтегляне и предаване по цялата планета.

100 000 потребители: мащабиране на слоя данни

CDN помогна много: трафикът расте с пълна скорост. Известният видео блогър Мавид Мобрик току-що се регистрира при нас и публикува своята „история“, както се казва. Благодарение на инструмента за балансиране на натоварването, използването на процесора и паметта на API сървърите се поддържа ниско (десет работещи екземпляра на API), но започваме да получаваме много изчаквания на заявки... откъде идват тези забавяния?

Задълбавайки се малко в метриките, виждаме, че процесорът на сървъра на базата данни е натоварен на 80-90%. Ние сме на предела.

Мащабирането на слоя данни е може би най-трудната част от уравнението. API сървърите обслужват заявки без състояние, така че ние просто добавяме още API екземпляри. нос мнозинството базите данни не могат да направят това. Ще говорим за популярни системи за управление на релационни бази данни (PostgreSQL, MySQL и др.).

Кеширане

Един от най-лесните начини за увеличаване на производителността на нашата база данни е въвеждането на нов компонент: кеш слоя. Най-разпространеният метод за кеширане е съхраняване на запис на ключ-стойност в паметта, като Redis или Memcached. Повечето облаци имат управлявана версия на тези услуги: Elasticache в AWS и Memorystore в Google Cloud.

Кешът е полезен, когато услуга прави много повтарящи се извиквания към базата данни, за да извлече една и съща информация. По същество ние осъществяваме достъп до базата данни само веднъж, съхраняваме информацията в кеша и не я докосваме отново.

Например, в нашата услуга Graminsta, всеки път, когато някой отиде на страницата на профила на звездата Mobrik, API сървърът отправя запитване към базата данни за информация от неговия профил. Това се случва отново и отново. Тъй като информацията за профила на Mobrik не се променя с всяка заявка, той е отличен за кеширане.

Ще кешираме резултатите от базата данни в Redis по ключ user:id със срок на валидност 30 секунди. Сега, когато някой отиде в профила на Mobrik, първо проверяваме Redis и ако данните са там, просто ги прехвърляме директно от Redis. Сега заявките към най-популярния профил на сайта практически не зареждат нашата база данни.

Друго предимство на повечето услуги за кеширане е, че те са по-лесни за мащабиране от сървърите на бази данни. Redis има вграден режим Redis Cluster. Подобно на балансьор на натоварването1, то ви позволява да разпределите вашия Redis кеш между множество машини (между хиляди сървъри, ако е необходимо).

Почти всички мащабни приложения използват кеширане; това е абсолютно неразделна част от бърз API. По-бързата обработка на заявките и по-продуктивният код са важни, но без кеш е почти невъзможно услугата да бъде мащабирана за милиони потребители.

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

Когато броят на заявките към базата данни се увеличи значително, още едно нещо, което можем да направим, е да добавим реплики за четене в системата за управление на базата данни. С управляваните услуги, описани по-горе, това може да стане с едно кликване. Репликата за четене ще остане актуална в главната база данни и е достъпна за изрази SELECT.

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

Следващи стъпки

Тъй като приложението продължава да се мащабира, ние ще продължим да разделяме услугите, за да ги мащабираме независимо. Например, ако започнем да използваме Websockets, тогава има смисъл да изтеглим кода за обработка на Websockets в отделна услуга. Можем да го поставим на нови екземпляри зад нашия собствен балансьор на натоварването, който може да мащабира нагоре и надолу въз основа на отворени Websockets връзки и независимо от броя на HTTP заявките.

Също така ще продължим да се борим с ограниченията на ниво база данни. Точно на този етап е време да проучим разделянето и шардинга на базата данни. И двата подхода изискват допълнителни разходи, но ви позволяват да мащабирате базата данни почти неограничено.

Също така искаме да инсталираме услуга за мониторинг и анализ като New Relic или Datadog. Това ще ви помогне да идентифицирате бавните заявки и да разберете къде е необходимо подобрение. Докато мащабираме, искаме да се съсредоточим върху намирането на тесни места и премахването им – често използвайки някои от идеите от предишни раздели.

източници

Тази публикация е вдъхновена от един от любимите ми публикации за висока мащабируемост. Исках да направя статията малко по-специфична за началните етапи на проектите и да я развържа от един доставчик. Не пропускайте да прочетете, ако се интересувате от тази тема.

Бележки под линия

1. Въпреки че е сходно по отношение на разпределението на натоварването в множество екземпляри, основната реализация на Redis клъстер е много различна от балансиращото натоварване. [връщане]

Източник: www.habr.com