Health checks, connection draining и slow start

У backend заполняется диск. Он продолжает принимать TCP-соединения, но каждый HTTP-запрос возвращает 500. Health check L4 (TCP SYN-проба) говорит, что backend здоров. Запросы продолжают маршрутизироваться к нему и завершаться ошибками. Это именно тот пробел, который закрывает пассивный health check.

Активные health checks

LB отправляет пробные запросы к каждому backend с фиксированным интервалом, независимо от реального клиентского трафика.

Типы проб:

• HTTP GET /healthz — наиболее распространённый; ожидает 200 OK. Обнаруживает отказы на уровне приложения (заполнен диск, база данных недоступна).
• TCP SYN — лёгкий; просто пытается установить TCP. Обнаруживает полный сетевой или процессный отказ, но пропускает ошибки приложения.
• gRPC health check — стандарт для gRPC-сервисов (grpc.health.v1.Health/Check).
• Кастомные UDP-пробы — для не-TCP-сервисов.

Пороги:

• Помечать unhealthy после 2–3 последовательных отказов.
• Помечать healthy после 2–3 последовательных успехов.
• Интервал: 10–30 секунд.

Пробел тихого отказа. Backend, упавший жёстко (процесс убит), обнаруживается TCP SYN. Backend, зависший (thread pool исчерпан, возвращает 500), принимает TCP, но HTTP-запросы завершаются ошибкой — TCP SYN-проба это полностью пропускает. HTTP GET-пробы обнаруживают это, но только если URL пробы упражняет реальную логику приложения, а не тривиальную заглушку, всегда возвращающую 200.

Пассивные health checks и обнаружение выбросов

Вместо отправки проб LB наблюдает реальный трафик. Если backend возвращает повторные 5xx-ошибки или повторные таймауты, он является выбросом.

Обнаружение выбросов Envoy (конфиг по умолчанию):

• Исключить backend после 5 последовательных 5xx-ответов.
• Продолжительность исключения начинается с 30 секунд, удваивается при каждом повторном исключении: 30 с → 60 с → 120 с → до ~300 с.
• LB прекращает маршрутизировать новые запросы к исключённому backend на этот период.

Пассивный vs активный — что каждый обнаруживает:

• Активный обнаруживает: упавший процесс, сетевой раздел, неправильно маршрутизированный порт.
• Пассивный обнаруживает: зависания на уровне приложения, исчерпание пула БД, 500-бури из-за GC.
• Ни один отдельно не достаточен. Используйте оба для эшелонированной защиты.

Флаппинг health checks

Сетевой сбой вызывает 2–3 последовательных отказа активной проверки → backend исключён. Сеть восстанавливается → 2–3 успеха → backend добавлен обратно. Снова сбой → исключён. Это циклирование — флаппинг — вызывает быстрые колебания трафика, когда backend переключается между healthy и unhealthy.

Решение: Увеличить пороги отказа/успеха (требовать 5 последовательных отказов перед исключением). Добавить джиттер к времени проверок, чтобы проверки от нескольких реплик LB не синхронизировались. Экспоненциальный откат исключения Envoy (30 с → 60 с → 120 с) естественно стабилизирует флаппирующий backend: окно исключения расширяется, пока не станет длиннее продолжительности флапа.

Connection draining

При удалении backend (деплой, масштабирование вниз, обслуживание) нельзя резко обрывать активные соединения. Connection draining:

1. Прекратить маршрутизировать новые запросы на backend.
2. Позволить запросам в полёте завершиться в пределах таймаута drain.
3. После таймаута принудительно закрыть оставшиеся соединения.

Таймауты drain:

• Короткие HTTP-запросы: 5–30 с.
• Долгоживущие WebSocket / SSE-соединения: 300+ с.
• AWS ALB по умолчанию: 300 с (настраивается 0–3 600 с).
• GCP: настраивается 0–3 600 с.

Сторона приложения. При SIGTERM backend должен:

1. Вызвать close(listening_socket) — прекратить принимать новые соединения.
2. Завершить все запросы в полёте.
3. Выйти чисто.

Без draining LB удаляет backend посреди запроса: клиент получает connection reset и вынужден делать retry. С draining запрос завершается нормально и backend тихо выходит.

Slow start / прогрев

Когда backend возвращается в пул после восстановления или первого деплоя, он холодный:

• Кэши в процессе пусты.
• Пулы соединений к БД нужно прогреть.
• Кэши TLS-сессий холодные.

Немедленная отправка 100% трафика вызывает отставание backend под нагрузкой всплеска, что потенциально запускает каскадный отказ.

Решение: Постепенно наращивать трафик — 10% → 50% → 100% в течение 1–5 минут. Envoy поддерживает это через slow_start_window и slow_start_duration. AWS ALB поддерживает через взвешенную target group: новый backend начинает с весом 1 и инкрементируется со временем.