Пошук уроків, статей та іншого контенту
Як запити рівномірно розподіляються між кількома серверами — алгоритми та перевірки здоров'я.
Load balancer стоїть перед кількома серверами застосунку (горизонтальне масштабування, попередній урок) і розподіляє вхідні запити між ними — клієнт звертається до єдиної адреси балансувальника, не знаючи й не турбуючись, який саме з кількох реальних серверів обробить конкретний запит.
Клієнти → Load Balancer → Сервер 1
→ Сервер 2
→ Сервер 3Round robin — запити розподіляються по черзі, циклічно між серверами; найпростіший, працює добре, коли всі сервери рівносильні й запити приблизно однакові за вартістю обробки.
Least connections — новий запит іде на сервер із найменшою кількістю активних з'єднань зараз; краще враховує нерівномірну тривалість обробки різних запитів, ніж сліпий round robin.
За вагою (weighted) — потужніші сервери отримують пропорційно більшу частку запитів, ніж слабші, у неоднорідному кластері.
Балансувальник регулярно перевіряє (health check) кожен сервер — легкий запит на кшталт GET /health, що перевіряє, чи сервер живий і готовий приймати трафік. Сервер, що не відповідає (впав, перевантажений, іще запускається) автоматично тимчасово виключається з розподілу трафіку, доки не почне відповідати знову — саме це і робить горизонтальне масштабування ще й механізмом надійності, а не лише пропускної здатності: відмова одного сервера не зупиняє весь застосунок.
Якщо застосунок усе ж зберігає щось у локальній пам'яті конкретного сервера (попри рекомендацію попереднього уроку про statelessness), можна прив'язати конкретного клієнта до конкретного сервера (sticky session) — усі його наступні запити йдуть на той самий сервер. Це рішення-компроміс, а не ідеальне: воно погіршує рівномірність розподілу навантаження й ускладнює обробку відмови саме того сервера, до якого прив'язаний клієнт, — тому справжнє рішення (винести стан у спільне зовнішнє сховище) кращий підхід там, де це можливо.
На практиці балансування навантаження часто відбувається на кількох рівнях одночасно: DNS-балансування між географічно різними дата-центрами, потім балансувальник усередині дата-центру між конкретними серверами — багаторівнева схема, а не одна точка розподілу.
Балансувальник без health checks — трафік продовжує надходити на впалий сервер, і частина запитів користувачів провалюється, доки хтось вручну не помітить і не виключить сервер.
Sticky sessions як типове рішення замість винесення стану в спільне сховище — рішення-милиця, що обмежує рівномірність розподілу навантаження й ускладнює обробку відмов.
Один-єдиний балансувальник без резервування — сам балансувальник стає єдиною точкою відмови (single point of failure) для всієї системи, попри те, що сервери за ним масштабовані й надлишкові.
Load balancer розподіляє вхідні запити між кількома серверами за алгоритмом (round robin, least connections, зважений розподіл) і виключає з розподілу сервери, що не проходять health check — роблячи горизонтальне масштабування водночас механізмом підвищення пропускної здатності й надійності. Sticky sessions — компромісне рішення для застосунків, що ще не повністю stateless, а не ідеальна практика за замовчуванням.