Модуль 13

Балансування навантаження

Ось повноцінний урок у стилі CS50, створений спеціально для тебе.

🎓 CS50: Тема — Балансування навантаження (Load Balancing)

Привіт, друзі! Мене звати [Твоє Ім'я], і це... ну, ви зрозуміли. Сьогодні ми поговоримо про те, що робить інтернет масштабованим.

1. 🔥 Вступ: Коли один сервер вже не тягне

Уявіть собі ранок понеділка. Ви заходите в улюблену кав’ярню біля метро. Там працює один бариста. Він майстер своєї справи, робить каву за 30 секунд. Але в черзі стоїть 50 людей.

Що станеться? Останній у черзі отримає свою каву через 25 хвилин. Він запізниться на роботу, розізлиться і більше ніколи не прийде.

А тепер уявіть, що ви запустили стартап. Ваш сайт став вірусним у TikTok. Тисячі користувачів одночасно намагаються зайти на нього. Ваш єдиний сервер — це той самий бідний бариста. Він "закипає", сайт падає, ви втрачаєте гроші.

Риторичне питання: Чи допоможе нам, якщо ми наймемо "супер-баристу", який працює вдвічі швидше? Можливо, трохи. Але якщо людей стане 1000? Жодна людина (і жоден "залізний" сервер) не має безмежної потужності.

Рішення? Поставити поруч другого баристу. Третього. Десятого. Але хто вирішує, до якого баристи підійде наступний клієнт, щоб не було тисняви? Правильно — адміністратор на вході.

У світі IT цей адміністратор називається Load Balancer (Балансувальник навантаження). Без нього Google, Facebook чи Netflix просто не змогли б існувати.

2. 🧠 Теоретична база: Як це працює "під капотом"

Давайте розберемо це без складної математики, але з розумінням інженерії.

Що таке Load Balancer (LB)?

Це пристрій (або програма), який стоїть між клієнтами (користувачами) і групою ваших серверів (які ми називаємо "пулом серверів" або "фермою").

Він діє як регулювальник дорожнього руху. Запит приходить до нього, а він каже: "Ти — йди на Сервер А, а ти, наступний, — на Сервер Б".

Три речі, які треба запам'ятати (обов'язково):

  1. Горизонтальне масштабування: Це коли ми додаємо більше серверів (машин), а не покращуємо один старий. Це дешевше і надійніше. LB дозволяє це робити.
  2. Health Checks (Перевірка здоров'я): Балансувальник постійно запитує сервери: "Ти живий?". Якщо сервер не відповідає (згорів, завис), LB просто перестає посилати туди людей. Користувачі навіть не помічають аварії!
  3. Алгоритми розподілу: Як саме LB вирішує, куди послати запит?

Алгоритми (інтуїтивно):

  • Round Robin (Карусель): По черзі. Перший — першому, другий — другому, третій — першому... Найпростіший варіант.
  • Least Connections (Найменше з’єднань): LB дивиться, хто з серверів зараз "відпочиває" (має найменше активних задач), і відправляє роботу туди. Розумний підхід.
  • IP Hash (Липучка): Якщо я прийшов з певної IP-адреси, я завжди потрапляю на один і той самий сервер. Це важливо, якщо сервер пам’ятає мої дані (наприклад, кошик покупок).

3. 🧪 Приклади: Від простого до реального

Давайте подивимося на конфігурацію найпопулярнішого балансувальника у світі — Nginx.

Приклад 1: Проста "Карусель" (Round Robin)

Уявіть, у нас є три сервери: srv1, srv2, srv3.

upstream my_app {
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

server {
    listen 80;
    location / {
        proxy_pass http://my_app;
    }
}

Питання до вас: Якщо прийде 4 запити, куди потрапить четвертий? Пауза для роздумів... Відповідь: Знову на srv1. Цикл повторюється: 1, 2, 3, 1...

Приклад 2: "Нерівні сили" (Weighted Round Robin)

Уявіть, що srv1 — це потужний сучасний сервер, а srv2 — старенький ноутбук. Чи чесно давати їм порівну роботи? Ні. Старий загнеться.

Ми додаємо вагу (weight):

upstream my_app {
    server srv1.example.com weight=3; # Цей силач бере 3 запити
    server srv2.example.com weight=1; # Цей слабак бере 1
}

Що очікуємо: З 4-х запитів три підуть на перший сервер, і лише один — на другий. Ефективність!

Приклад 3: Проблема "Зниклого кошика"

Ви заходите в інтернет-магазин, кладете товар у кошик. Оновлюєте сторінку... Кошик порожній! 😱

Чому так сталось? 1. Перший запит ("покласти в кошик") потрапив на Сервер А. Він зберіг кошик у своїй пам’яті. 2. Ви оновили сторінку. Балансувальник подумав: "О, черга Сервера Б!" і відправив вас на Сервер Б. 3. Сервер Б нічого не знає про ваш кошик на Сервері А.

Рішення: ip_hash.

upstream my_app {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
}

Тепер LB гарантує: поки ви не зміните IP, ви будете спілкуватися тільки з Сервером А.

4. 🛠 Практична частина

Час "забруднити руки". Уявіть, що ви архітектор системи.

Завдання 1: Розрахунок У вас є 5 серверів. Кожен може витримати 100 запитів на секунду. Ваш LB налаштований як Round Robin. Скільки запитів на секунду витримає вся ваша система? (Це просто, але це база).

Завдання 2: Health Check У конфігурації з трьох серверів (Round Robin) другий сервер (srv2) раптово вимкнувся (згорів). Балансувальник ще не зрозумів, що він мертвий (налаштування: перевірка кожні 10 секунд). Приходить 6 запитів. Що побачать користувачі? (Підказка: деякі побачать помилку "502 Bad Gateway". Скільки їх буде?)

Завдання 3: Кейс "Чорна п'ятниця" Ви продаєте квитки на концерт Океану Ельзи. На старті продажів: * 90% людей просто дивляться ціну (швидкі легкі запити). * 10% людей оформлюють оплату (важкі довгі запити). Який алгоритм ви оберете: Round Robin чи Least Connections? Чому?

Завдання 4: Міні-архітектура У вас є сервер в Києві і сервер в Нью-Йорку. Як налаштувати балансування так, щоб українці потрапляли на київський сервер, а американці — на нью-йоркський, щоб сайт працював швидше? (Підказка: це називається Geo-DNS або Geo-Location balancing).

5. 💡 Мислення як у розробника

Ось де ми відрізняємо новачків ("кодерів") від інженерів.

Помилка новачка: Думати, що Load Balancer вирішить проблему повільного коду. Реальність: Якщо ваш код працює повільно, ви просто отримаєте 10 повільних серверів замість одного. Балансувальник — це про кількість користувачів, а не про швидкість обробки одного запиту.

Як думає Senior Engineer: 1. "Shared Nothing" архітектура. Сервери не повинні зберігати важливі дані (як кошик) у себе в локальній пам'яті (пам'ятаєте приклад 3?). Дані мають бути в спільній базі даних або в Redis. Тоді будь-який сервер може обслужити будь-якого клієнта, і нам не потрібен ip_hash. 2. Точка відмови (Single Point of Failure). Ми поставили 10 серверів, супер. Але у нас лише один балансувальник на вході. Що буде, якщо згорить він? * Рішення: Ставимо два балансувальники (один головний, один запасний).

6. 🧩 Підсумок

Отже, що ми сьогодні зробили? Ми взяли одну перевантажену касу в супермаркеті і перетворили її на величезний гіпермаркет з десятками кас і розумним адміністратором, який керує чергою.

Тепер ви знаєте: * Що таке Load Balancer і навіщо він потрібен (масштабування + надійність). * Чим Round Robin відрізняється від Least Connections. * Чому не можна зберігати сесії локально, якщо хочеш масштабуватися.

Тизер наступного уроку: Ми навчилися масштабувати веб-сервери (додавати більше кас). Але всі ці каси звертаються до одного складу (Бази Даних). Що станеться, коли склад перестане справлятися? Наступного разу ми поговоримо про Реплікацію та Шардінг Баз Даних.

А поки що — це був CS50. Щасти!

← До списку уроків Наступний урок →