Система с canary‑релизом автоматически откатывает ML‑модели при ухудшении метрик в продакшене
Развёртывание новой версии ML‑модели нередко превращается в рискованный момент. Офлайн‑метрики могут выглядеть лучше, но после выхода в продакшен начинают расти ошибки, увеличивается задержка или неожиданно меняется поведение предсказаний. В классической схеме новую модель просто ставят вместо предыдущей и сразу отправляют на неё 100% трафика. Если что-то идёт не так, проблема затрагивает всех пользователей, а откат приходится делать вручную и обычно в спешке.
Автор предлагает систему, которая превращает такой релиз в управляемый эксперимент. Вместо полной замены используется canary‑подход. Новой модели передают лишь часть реального трафика, например 20%, тогда как 80% остаются на проверенной версии. Производительность обеих моделей постоянно сравнивается по метрикам вроде частоты ошибок и задержки. Если новая версия начинает проигрывать, система автоматически возвращает трафик к базовой модели ещё до того, как большинство пользователей заметит проблему. Как пишет Towards AI, если canary‑модель ведёт себя стабильно, её долю постепенно увеличивают, сначала до 50%, затем до 100%.
Архитектура сервиса разделена на несколько компонентов. FastAPI принимает запросы на предсказания, TrafficRouter распределяет их между моделями. Доля трафика хранится в Redis, поэтому её можно менять мгновенно без перезапуска и без повторного деплоя. Метрики запросов, ошибок и задержки отправляются в Prometheus. Фоновый HealthChecker запускается каждые 30 секунд и сравнивает показатели двух моделей. События деплоя записываются в PostgreSQL, а артефакты моделей лежат в MinIO.
Ключевая деталь, параметр canary_traffic_pct хранится именно в Redis, а не в конфигурационном файле или переменной окружения. Благодаря этому изменение, например с 20% до 50%, начинает действовать уже со следующего запроса. Автор проверил распределение трафика на 100 000 запросов для каждого значения. При настройке 20% на canary ушло 20.2% запросов, при 50% получилось 49.9%, при 100% на новую модель отправился весь трафик. Если конфигурация отсутствует или повреждена, система по умолчанию направляет запросы к baseline‑модели.
Ключевые факты
В canary‑развертывании новая модель сначала получает около 20% живого трафика, тогда как 80% остаются на базовой версии; при успешных метриках доля постепенно увеличивается до 50% и затем до 100%.
Фоновый HealthChecker запускается каждые 30 секунд и сравнивает показатели двух моделей по данным Prometheus, включая error rate и latency, чтобы принять решение о продолжении или авто‑откате.
Маршрутизация трафика определяется значением canary_traffic_pct в Redis, поэтому изменение доли трафика применяется мгновенно без перезапуска сервиса или redeploy.
Тестирование распределения на 100000 запросах показало, что конфигурация 20% направляет 20.2% трафика на canary, 50%, 49.9%, а 100%, 100%.