После каждого деплоя часть запросов к сервису завершается ошибкой соединения, хотя health check на новых инстансах проходит успешно. Какой механизм балансировщика, вероятно, настроен неправильно?

Короткий ответ

Вероятнее всего не настроена или слишком короткая задержка deregistration delay (connection draining) — время, в течение которого балансировщик продолжает дожидаться завершения уже начатых запросов на инстансе перед его исключением из ротации при остановке/замене инстанса во время деплоя.

Как это работает подробнее

при остановке/замене инстанса балансировщик должен сначала перестать направлять на него новые запросы, но дать время доработать уже установленные соединения; если deregistration delay равен нулю или слишком мал, а приложение не обрабатывает сигнал graceful shutdown, соединения обрываются посередине обработки.

Пример кода

example.txtКопировать

Target Group: deregistration delay = 0s (слишком мало для данной нагрузки)
Приложение: среднее время обработки запроса ~3-5 секунд, SIGTERM не перехватывается

Что использовать на практике

• Рекомендация. настраивают deregistration delay чуть больше максимального ожидаемого времени обработки запроса приложением, а само приложение подписывают на сигнал остановки (SIGTERM), чтобы прекратить принимать новые соединения, но довести до конца уже начатые.
• Проверка. после установки deregistration delay, например, в 30 секунд и добавления обработки SIGTERM с graceful shutdown частота ошибок соединения во время деплоев должна упасть практически до нуля.

Подводные камни

• Риск. полагаться только на health check при деплое и не настраивать отдельно connection draining
• Риск. останавливать контейнер/инстанс сразу по истечении таймаута оркестратора, который короче, чем deregistration delay балансировщика
• Риск. не обрабатывать SIGTERM в приложении, из-за чего «грациозная» остановка на уровне балансировщика не спасает уже установленные соединения.