Что такое балансировщик нагрузки (load balancer) и зачем он нужен?

Э, слушай, смотри, что за зверь такой — балансировщик нагрузки. Представь себе толпу голодных клиентов, которые ломятся на твой сайт, а навстречу им — здоровенный вышибала, который их не тупо всех в одну дверь пихает, а грамотно раскидывает по разным залам, где официанты (это наши сервера) готовы их обслужить. Этот вышибала и есть Load Balancer, ёпта. Железка такая или софтина, которая не дает одному серверу сдохнуть под халявщиками, а распределяет нагрузку по всем пацанам в пуле.

Чем он, бля, занимается, этот красавчик:

• Round Robin (по кругу): Как в детском саду — первому клиенту — первый сервер, второму — второй, и так по новой. Честно, но туповато, если у кого-то заказ на овердохуища пиццы, а у кого-то — стакан воды.
• Least Connections (кому легче): Умная штука. Смотрит, у какого сервера меньше всего народу на шее висит, и нового клиента — к нему. Чтобы все были при деле, но не надрывались.
• IP Hash (чтоб не метаться): Запоминает, откуда пришёл клиент, и всегда гонит его на один и тот же сервер. Чтобы, если он корзину в интернет-магазине набил, её не потерять. Для сессий — самое то.

Вот, смотри, как это выглядит в деле, на примере Nginx, который тут у нас главный по кухне:

http {
    upstream php_backend { # Это наша банда, пул серверов
        least_conn; # Алгоритм: отдаём тому, у кого меньше всего работы
        server 10.0.1.10:9000; # Первый работяга PHP-FPM
        server 10.0.1.11:9000; # Второй такой же
        server 10.0.1.12:9000 backup; # Третий — резервный, сидит курит, пока основные пашут
    }

    server {
        listen 80;
        location ~ .php$ {
            fastcgi_pass php_backend; # Вся динамика улетает в нашу банду upstream
            # ... ну и дальше всякие технические прибамбасы
        }
    }
}

А теперь, блядь, главное — нахуя это всё? Преимущества-то какие, кроме того что просто красиво?

1. Масштабируемость — ебать мои старые костыли! Трафик подскочил? Ну и хуй с ним. Добавляешь в конфиг ещё один server 10.0.1.13:9000;, и вот тебе — новый официант в зале. Без остановки всего этого цирка.
2. Отказоустойчивость — доверия ебать ноль к железу. Балансировщик не дурак, он тыкается в сервера палочкой (health checks). Если какой-то вдруг накрылся медным тазом и не отвечает, он его просто выкидывает из ротации. Пользователи даже не заметят, что один ушёл в запой.
3. SSL/TLS Termination — разгружает по-страшному. Вся эта криптографическая хуйня с шифрованием — очень затратная для процессора. Так вот, балансировщик может принимать весь этот зашифрованный трафик на себя, расшифровывать его, а на внутренние сервера гнать уже простой, понятный HTTP. Те живут спокойно и только логикой приложения думают.
4. Единая точка входа — красота, бля. Снаружи у тебя один красивый адрес для всех. А что там у тебя внутри — три сервера или триста — всем похуй. И в DNS тоже один раз прописал — и забыл.

Ну и в облаках, типа AWS или GCP, это вообще сказка. Там тебе не надо свой Nginx настраивать. Берёшь управляемый балансировщик (ALB там какой-нибудь), нажимаешь кнопочки, говоришь «следи за вот этой пачкой виртуальных машин», и он сам, хитрая жопа, масштабируется, сам здоровье проверяет — красота. Сидишь, кофе пьёшь, пока он за тебя всё делает.