Использовался ли Nginx для балансировки нагрузки

Что проверяют

Настраивали ли вы Nginx как балансировщик своими руками и понимаете ли, что происходит, когда один из бэкендов падает. Следом обычно спрашивают про проверки здоровья, липкие сессии и повторы запросов.

Как отвечать

Стройте ответ на своём опыте: какой сервис, сколько бэкендов, какой трафик, какую проблему решали и что пришлось донастроить. Цифры нужны ваши собственные. Технический каркас при этом такой:

• upstream: список серверов, по умолчанию round-robin. Альтернативы least_conn, ip_hash, hash $key consistent и random, у серверов задаётся weight, а backup включается, когда основные недоступны;
• пассивные проверки: max_fails и fail_timeout (по умолчанию 1 и 10 секунд) выводят сервер из ротации после ошибок. Активный health_check есть только в коммерческом NGINX Plus, в open source его заменяют внешним мониторингом;
• повторы: proxy_next_upstream по умолчанию переотправляет запрос на следующий сервер при error и timeout, но неидемпотентный POST, уже ушедший на бэкенд, не повторяется;
• соединения: keepalive в upstream вместе с proxy_http_version 1.1 и пустым заголовком Connection экономит установку TCP-соединений;
• липкость: директива sticky тоже только в Plus, в open source используют ip_hash или hash по куке;
• L4: модуль stream балансирует TCP и UDP, например для базы или DNS.

Если с Nginx в роли балансировщика вы не работали, скажите об этом и расскажите, что использовали вместо него: HAProxy, облачный балансировщик или Ingress в Kubernetes. Принципы переносятся между инструментами, и это стоит показать.

Где спотыкаются

Утверждают, что Nginx «сам отключает упавшие серверы по мониторингу». В open source он узнаёт об отказе только по ошибкам на реальных запросах.

Забывают про заголовки X-Forwarded-For и X-Forwarded-Proto: приложение видит IP балансировщика и считает HTTPS-запрос обычным HTTP.

Включают ip_hash за другим прокси или NAT. Все клиенты приходят с одного адреса, и нагрузка ложится на один бэкенд.