Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Вертикальне проти горизонтального масштабування». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Вертикальне масштабування** посилює один сервер (більше CPU/RAM, `cluster` на всі ядра); **горизонтальне** додає нові сервери під балансувальником. **Ключове:** у продакшені зазвичай комбінують обидва - `cluster` всередині кожної машини, балансувальник (Nginx, Kubernetes) - між машинами.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення## 1. Що таке масштабування **Масштабування (scaling)** - це процес збільшення обчислювальних ресурсів, щоб застосунок міг обробляти **більшу кількість запитів**, **користувачів** чи **даних** без деградації продуктивності. Є два основні підходи: - **Вертикальне масштабування (Vertical Scaling)** - **Горизонтальне масштабування (Horizontal Scaling)** ## 2. Вертикальне масштабування (scale-up) > Вертикальне масштабування = **збільшити потужність одного сервера**. Простіше кажучи: > ми **покращуємо залізо**: додаємо більше CPU, RAM, SSD чи прискорюємо мережу на одній машині. ### Приклад: | Було | Стало | |---|---| | 2 ядра CPU | 8 ядер CPU | | 4 GB RAM | 32 GB RAM | | HDD | NVMe SSD | Тепер той самий сервер може обробляти **у 4-8 разів більше** запитів, але все ще лишається **одним** сервером і **одним процесом** застосунку. ### Приклад у Node.js: - Був один процес, що обробляв 1000 запитів/сек. - Додали більше CPU й RAM. - Тепер цей процес обробляє 5000 запитів/сек. - Або запустили **кластер через** `cluster`, щоб використати всі ядра CPU. Це все - **вертикальне масштабування**, бо воно використовує **одну машину**. ### Плюси вертикального масштабування | Перевага | Опис | |---|---| | Простота | Не потрібно міняти архітектуру чи код | | Менше інфраструктури | Один сервер, менше точок відмови | | Швидке впровадження | Просто оновити план хостингу чи залізо | | Корисно для баз даних | Прості сценарії (Postgres, Mongo) добре масштабуються "вгору" | ### Мінуси вертикального масштабування | Недолік | Опис | |---|---| | Фізична межа | У будь-якого сервера є ліміт по ядрах і пам'яті | | Дорого | Потужніші машини ростуть у ціні **не лінійно** | | Точка відмови | Один сервер = одна точка збою | | Не можна масштабувати "нескінченно" | Після стелі ресурсів доведеться переходити на горизонтальний підхід | ## 3. Горизонтальне масштабування (scale-out) > Горизонтальне масштабування = **додати більше серверів**. Простіше кажучи: > замість того щоб посилювати один сервер, > ми **запускаємо кілька однакових копій застосунку** й **розподіляємо навантаження між ними**. ### Приклад: | Було | Стало | |---|---| | 1 сервер | 5 серверів | | Обробка 1000 req/s | Обробка 5000 req/s | | Один instance | 5 instances під балансувальником | Тепер якщо прийде 5000 користувачів - балансувальник (наприклад, **NGINX**, **AWS ELB**, **Kubernetes**) розподілить запити по всіх вузлах. ### Приклад у Node.js: - У тебе застосунок `app.js`, що слухає порт `3000`. - Ти запускаєш **5 копій** на різних серверах чи контейнерах. - Перед ними стоїть **NGINX** чи **load balancer**, який роздає запити по черзі. Це - **горизонтальне масштабування**, тому що ти додаєш **нові вузли**, а не посилюєш один. ### Плюси горизонтального масштабування | Перевага | Опис | |---|---| | Масштабується майже безмежно | Просто додавай нові вузли | | Відмовостійкість | Якщо один сервер впаде - решта продовжують працювати | | Гнучкість | Можна масштабувати по зонах, регіонах, контейнерах | | Економічність | Кілька простих машин дешевші за одного "монстра" | | Підходить для хмар | AWS, GCP, Azure, Kubernetes - усе для цього заточено | ### Мінуси горизонтального масштабування | Недолік | Опис | |---|---| | Складність архітектури | Потрібно впроваджувати балансувальники, синхронізацію, логування | | Проблеми зі станом | Сесії користувачів і кеш потрібно зберігати централізовано (Redis, БД) | | Міжсерверна комунікація | З'являються мережеві затримки й складніше налагодження | | Потрібні DevOps-навички | Без контейнеризації й CI/CD буде важко | ## 4. Порівняння: вертикальне vs горизонтальне | Критерій | Вертикальне (scale-up) | Горизонтальне (scale-out) | |---|---|---| | Основна ідея | Посилити один сервер | Додати більше серверів | | Простота реалізації | Просте | Складніше (потрібен балансувальник) | | Зміни в коді | Мінімальні | Часто потрібні | | Ліміт росту | Є (залізо обмежене) | Майже необмежений | | Відмовостійкість | Один сервер = SPOF | Висока (кілька інстансів) | | Вартість | Дорого при великих потужностях | Масштабовано й передбачувано | | Приклад у Node.js | `cluster` (1 сервер, усі ядра CPU) | Nginx + кілька серверів / контейнерів | | Тип масштабування | "вгору" | "вшир" | ## 5. Часто обидва підходи комбінують На практиці використовують **гібрид**: 1. **Вертикально** - максимум з однієї машини (CPU, RAM, `cluster`). 2. **Горизонтально** - додати ще машин, контейнерів чи подів (через Docker/Kubernetes/PM2 cluster mode). Приклад архітектури: ```javascript Load Balancer (NGINX) │ ┌────┴────┬────┬────┐ │ Server1 │ Server2 │ Server3 │ │ (Cluster з 8 воркерів кожен) │ ``` → Кожна машина використовує **всі ядра** (вертикальне), а навантаження розподіляється **по серверах** (горизонтальне). ## Підсумок | Параметр | Вертикальне | Горизонтальне | |---|---|---| | Масштабування | Збільшення потужності сервера | Додавання нових серверів | | Простота | Легше | Складніше | | Продуктивність | Росте до межі CPU/RAM | Росте лінійно з додаванням вузлів | | Відмовостійкість | Низька | Висока | | Застосування | Малі/середні навантаження, бази даних | Високонавантажені системи, API | | Приклад у Node.js | `cluster` | Кілька інстансів під балансувальником | **Висновок:** > **Вертикальне масштабування** посилює **один сервер** (більше ресурсів). > **Горизонтальне масштабування** додає **нові сервери**, що працюють паралельно. > > У продакшені зазвичай комбінують обидва підходи: > `cluster` - щоб використати всі ядра CPU, > і балансувальник (NGINX, Kubernetes, PM2) - щоб розподіляти навантаження між кількома вузлами.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.