Как вы спроектируете стратегию балансировки нагрузки и health checks на уровне балансировщика для безопасных релизов (blue-green или canary), чтобы минимизировать влияние неудачного релиза на пользователей?

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

Нет единственно верной стратегии: выбор между blue-green (мгновенное переключение всего трафика между двумя полными окружениями) и canary (постепенное увеличение доли трафика на новую версию) зависит от стоимости содержания второго полного окружения, скорости обнаружения проблем через метрики и допустимого радиуса поражения при неудачном релизе, и требует явного обсуждения с владельцами продукта критериев успешного/неуспешного релиза.

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

Blue-green переключает весь трафик на новую версию сразу после того, как health checks на новом окружении подтвердили готовность, что даёт простой и быстрый откат (просто переключить балансировщик обратно), но не защищает от проблем, которые проявляются только под реальной production-нагрузкой и не отлавливаются health check; canary направляет небольшую, постепенно растущую долю трафика на новую версию, позволяя сравнивать реальные метрики ошибок/задержек старой и новой версии до полного переключения, но требует более сложной настройки балансировщика (weighted routing) и чёткой автоматизации метрик для принятия решения о продолжении или откате canary.

Пример кода

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

Пример canary-стратегии на L7-балансировщике:
1. 5% трафика -> новая версия, мониторинг error rate и p99 latency 10 минут
2. Если error rate новой версии > error rate старой + 1 п.п. -> автоматический откат к 0%
3. Если метрики в норме -> 25% -> 50% -> 100%, с паузами и проверкой на каждом шаге

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

• Практика. комбинируют: health checks на уровне L7 (проверка не просто живости процесса, а реальной функциональности, включая зависимости) используются на обоих окружениях перед началом переключения трафика; для canary определяют заранее конкретные метрики и пороги (error rate, p99 latency) и, по возможности, автоматизируют остановку и откат canary при превышении порогов без ожидания ручного решения; для blue-green обязательно тестируют сам механизм быстрого отката и держат старое окружение готовым к приёму трафика некоторое время после переключения, а не удаляют его сразу.
• Компромисс. Проверка: искусственно задеплоить версию с намеренной деградацией (повышенным error rate) на этапе 5% и убедиться, что автоматика откатывает canary до распространения проблемы на большую долю пользователей, без необходимости ручного вмешательства дежурного инженера.

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

• Риск. считать, что прохождение health check гарантирует отсутствие проблем под реальной нагрузкой; запускать canary без заранее согласованных автоматических критериев остановки, полагаясь на то, что кто-то вручную заметит деградацию по дашборду; не репетировать процедуру отката до момента, когда она реально понадобится в инциденте под давлением времени.