Як масштабувати веб-додаток: від одного сервера до розподіленої системи

Більшість веб-додатків починають з одного сервера. Це просто, дешево і цілком достатньо для старту. Але що відбувається коли трафік зростає? Сервер починає повільніше відповідати, потім зависати, потім падати під навантаженням. Саме в цей момент починається розмова про масштабування — і виявляється що це значно ширша тема ніж просто "купити більший сервер".

Вертикальне і горизонтальне масштабування

Існують два фундаментально різні підходи до масштабування.

Вертикальне масштабування — це збільшення ресурсів одного сервера: більше CPU, більше RAM, швидші диски. Простий і зрозумілий підхід з мінімальними змінами в архітектурі. Але має жорстку межу — існує максимально потужний сервер який можна купити. Крім того єдиний сервер це єдина точка відмови.

Горизонтальне масштабування — це додавання нових серверів і розподіл навантаження між ними. Теоретично не має верхньої межі і забезпечує відмовостійкість. Але вимагає значно складнішої архітектури: додаток повинен бути спроектований для роботи в кількох екземплярах одночасно.

Load Balancer

Load balancer — перший крок до горизонтального масштабування. Це компонент який приймає вхідні запити і розподіляє їх між кількома серверами. Nginx, HAProxy, AWS Application Load Balancer — популярні варіанти.

Але load balancer створює нову проблему: якщо користувач робить запит до одного сервера а наступний запит потрапляє на інший — де зберігається його сесія? Відповідь: сесії не повинні зберігатися на серверах додатку. Замість цього використовується спільне сховище — Redis або Memcached — яке доступне всім екземплярам додатку.

Кешування

Кешування — один з найефективніших інструментів масштабування. Якщо результат дорогого запиту до бази даних можна зберегти і повторно використати — навантаження на базу даних значно знижується.

Redis — найпоширеніший інструмент для кешування. Він зберігає дані в пам'яті що забезпечує мікросекундний час відповіді. Кешувати можна результати SQL запитів, відповіді зовнішніх API, сесії користувачів, обчислені результати.

CDN — Content Delivery Network — кешує статичні ресурси на серверах розподілених по всьому світу. Коли користувач з Європи запитує зображення з вашого сайту — CDN віддає його з найближчого європейського вузла замість вашого основного сервера в Україні. Cloudflare, AWS CloudFront, Fastly — популярні CDN провайдери.

База даних як вузьке місце

Найчастіше при масштабуванні першою "падає" база даних. Додаток можна легко запустити в десяти екземплярах але всі вони звертаються до однієї бази даних.

Read replicas — репліки бази даних тільки для читання. Більшість запитів до бази даних в типовому додатку це читання а не запис. Розподіливши запити на читання між репліками можна значно знизити навантаження на основний сервер.

Database sharding — розподіл даних між кількома базами даних. Наприклад користувачі з ID від одного до мільйона зберігаються в одній базі, від мільйона до двох мільйонів в іншій. Ефективно але значно ускладнює архітектуру.

Асинхронна обробка і черги

Не всі операції потрібно виконувати синхронно. Відправка email, генерація PDF, обробка зображень, складні обчислення — все це можна виконувати асинхронно через черги завдань.

RabbitMQ, Redis Queue, AWS SQS — популярні системи черг. Користувач відправляє запит, сервер кладе завдання в чергу і одразу відповідає що завдання прийнято. Окремі воркери обробляють завдання з черги в фоновому режимі. Це знижує час відповіді і дозволяє масштабувати обробку незалежно від основного додатку.

Мікросервіси

При дуже великому масштабі монолітний додаток стає обмеженням. Мікросервісна архітектура розбиває його на незалежні сервіси кожен з яких можна масштабувати окремо. Якщо навантаження зростає тільки на модуль пошуку — масштабується тільки він без необхідності додавати ресурси для всіх інших модулів.

Але мікросервіси додають значну операційну складність і виправдані тільки при дійсно великому масштабі і достатньо великій команді.

Масштабування — це не одноразове рішення а постійний процес адаптації архітектури до зростаючих вимог. Починати з простого і масштабувати поступово у відповідь на реальні проблеми — значно розумніша стратегія ніж будувати надскладну архітектуру для навантаження яке може ніколи не наступити.