Чем стратегия blue/green отличается от canary-развёртывания при обновлении версии приложения за балансировщиком нагрузки, и какие компромиссы есть у каждой?

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

Blue/green разворачивает полностью новую копию окружения параллельно со старой и переключает весь трафик разом после проверки, обеспечивая быстрый откат переключением обратно; canary постепенно направляет небольшую, растущую долю трафика на новую версию, позволяя обнаружить проблему на ограниченной части пользователей.

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

при blue/green обе версии полностью развёрнуты одновременно, а переключение происходит на уровне балансировщика/DNS практически мгновенно для всех пользователей сразу; при canary балансировщик направляет, например, 5% трафика на новую версию, постепенно увеличивая долю при отсутствии ошибок.

Пример кода

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

Blue/Green:
  LB -> target-group-blue (v1, 100%)
  переключение -> target-group-green (v2, 100%)
Canary:
  LB -> target-group-v1 (95%) + target-group-v2 (5%)
  при отсутствии роста ошибок -> v2 (25%) -> v2 (50%) -> v2 (100%)

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

• Рекомендация. blue/green проще реализовать и даёт быстрый полный откат, но не защищает от проблем, проявляющихся только под полной нагрузкой; canary лучше обнаруживает проблемы, зависящие от реальной продовой нагрузки, но требует более сложной маршрутизации по процентам и метрик для автоматического решения.
• Проверка. при обнаружении роста 5xx-ошибок в canary-группе маршрутизация должна быть немедленно возвращена на v1 для затронутого процента трафика без влияния на оставшихся пользователей.

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

• Риск. считать blue/green «безопасным по умолчанию» и не проверять поведение green-версии под реальной нагрузкой перед переключением
• Риск. делать canary без чётких автоматических критериев остановки (error rate, latency)
• Риск. не учитывать, что оба подхода требуют совместимости схемы БД между старой и новой версией, если они работают одновременно.