Пошук уроків, статей та іншого контенту
Купити потужніший сервер чи додати більше серверів — межі кожного підходу.
Вертикальне масштабування (scale up) — збільшення ресурсів одного сервера: більше оперативної пам'яті, потужніший процесор, швидший диск. Найпростіший спосіб впоратись із ростом навантаження — жодних архітектурних змін, той самий застосунок просто отримує більше ресурсів.
У кожного постачальника серверів є найпотужніша доступна конфігурація — рано чи пізно вертикальне масштабування впирається в фізичну стелю: не існує сервера, потужнішого за найпотужніший наявний на ринку. Крім того, вартість зростає нелінійно — удвічі потужніший сервер зазвичай коштує значно більше, ніж удвічі дорожче.
Горизонтальне масштабування (scale out) — додавання більшої кількості серверів, що працюють паралельно, з розподілом навантаження між ними (детально в наступному уроці про балансування навантаження). Теоретичної стелі кількості серверів немає — саме так побудовані найбільші системи у світі.
Вертикальне: Горизонтальне:
┌──────────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ Потужніший │ │ Сервер │ │ Сервер │ │ Сервер │
│ сервер │ │ 1 │ │ 2 │ │ 3 │
└──────────────┘ └────────┘ └────────┘ └────────┘Щоб запити могли оброблятись будь-яким із кількох серверів взаємозамінно, кожен сервер має бути stateless — не зберігати нічого специфічного для конкретного користувача лише у власній локальній пам'яті між запитами (сесія користувача в оперативній пам'яті конкретного процесу, локальний файловий кеш). Дані сесії потрібно винести в спільне зовнішнє сховище (база даних, Redis), доступне з будь-якого сервера однаково — інакше запит, оброблений іншим сервером за наступний раз, «не знатиме» про стан, збережений попереднім.
Контейнеризація (курс Docker) природно узгоджується з горизонтальним масштабуванням: однаковий, відтворюваний образ дозволяє легко запустити довільну кількість ідентичних контейнерів застосунку — але сам факт запуску кількох контейнерів не робить застосунок stateless автоматично, якщо код усередині все ще покладається на локальну пам'ять процесу для даних, які мають бути спільними.
Вертикальне масштабування — простіше (жодних змін архітектури), підходить для помірного росту й ранніх стадій проєкту, коли складність горизонтального підходу ще не виправдана.
Горизонтальне масштабування — складніше (вимагає statelessness, балансування навантаження), але теоретично необмежене й типово дешевше за одиницю пропускної здатності на великому масштабі.
Реальні системи зазвичай комбінують обидва — вертикально масштабують окремий сервер до розумної межі, і горизонтально додають більше таких серверів понад це.
Горизонтально масштабувати застосунок, що зберігає стан користувача в локальній пам'яті процесу, — різні запити того самого користувача, оброблені різними серверами, бачитимуть несумісні, розбіжні дані.
Нескінченно вертикально масштабувати замість переходу на горизонтальне масштабування, коли зростання навантаження явно продовжиться, — впирається у фізичну й економічну стелю, яку горизонтальний підхід не має.
Вважати горизонтальне масштабування «завжди кращим» — для помірного, передбачуваного навантаження додаткова складність горизontального підходу не завжди виправдана порівняно з простим вертикальним.
Вертикальне масштабування (потужніший сервер) просте, але має фізичну й економічну стелю; горизонтальне масштабування (більше серверів) теоретично необмежене, але вимагає, щоб застосунок був stateless — жодних даних, специфічних для користувача, у локальній пам'яті окремого сервера. Реальні системи зазвичай комбінують обидва підходи, а не обирають один назавжди.