Розробка системи canary-деплою AI-агентів
Уявіть: ви оновили промпт або модель для AI-агента, і він почав генерувати некоректні відповіді з галюцинаціями. Якщо rollout іде одразу на всіх користувачів — наслідки катастрофічні: втрата довіри, витік даних, SLA-штрафи. Ми використовуємо canary deployment для безпечного оновлення агентів — поступовий rollout з автоматичним відкатом при найменшій деградації метрик. Такий підхід знижує час rollback з годин до 40 секунд і запобігає масовим інцидентам. В одному з проєктів canary-деплой зекономив суттєву суму, запобігши 3 інцидентам з деградацією сервісу.
Як працює canary-деплой AI-агентів?
Canary pipeline — це послідовність етапів, на кожному з яких частка трафіку на нову версію збільшується. Між етапами — період спостереження, протягом якого порівнюються метрики стабільної та canary-версії. Якщо будь-яка метрика виходить за поріг — відбувається автоматичний rollback.
v1.3.1 (100% трафіку) ↓ деплой v1.3.2 v1.3.1 (95%) + v1.3.2 (5%) — спостереження 30 хв ↓ все ОК v1.3.1 (75%) + v1.3.2 (25%) — спостереження 1 год ↓ все ОК v1.3.1 (50%) + v1.3.2 (50%) — спостереження 2 год ↓ все ОК v1.3.2 (100%) — повний rollout ↓ при будь-якому етапі деградація автоматичний rollback на v1.3.1 Як реалізований canary controller?
@dataclass class CanaryDeployment: deployment_id: str agent_name: str stable_version: str canary_version: str stages: list[CanaryStage] # [(5%, 30min), (25%, 60min), (50%, 120min), (100%, 0)] current_stage_index: int = 0 status: str = "in_progress" @dataclass class CanaryStage: canary_traffic_pct: float observation_minutes: int started_at: datetime | None = None class CanaryController: def __init__(self, router: ExperimentRouter, analyzer: MetricsAnalyzer): self.router = router self.analyzer = analyzer async def advance_canary(self, deployment: CanaryDeployment): """Викликається за розкладом для перевірки та просування canary.""" current_stage = deployment.stages[deployment.current_stage_index] # Перевіряємо що спостереження завершено if not current_stage.started_at: current_stage.started_at = datetime.utcnow() return elapsed = (datetime.utcnow() - current_stage.started_at).total_seconds() / 60 if elapsed < current_stage.observation_minutes: return # ще спостерігаємо # Аналіз метрик за період спостереження health = await self.analyzer.compare_versions( deployment.agent_name, deployment.stable_version, deployment.canary_version, since=current_stage.started_at ) if health.canary_is_unhealthy: await self.rollback(deployment, reason=health.degradation_reason) return # Переходимо до наступної стадії next_index = deployment.current_stage_index + 1 if next_index >= len(deployment.stages): await self.complete_rollout(deployment) else: deployment.current_stage_index = next_index next_stage = deployment.stages[next_index] await self.router.update_traffic_split( deployment.agent_name, stable_pct=100 - next_stage.canary_traffic_pct, canary_pct=next_stage.canary_traffic_pct, canary_version=deployment.canary_version ) logger.info(f"Canary advanced to {next_stage.canary_traffic_pct}% for {deployment.agent_name}") async def rollback(self, deployment: CanaryDeployment, reason: str): await self.router.update_traffic_split( deployment.agent_name, stable_pct=100, canary_pct=0, canary_version=deployment.canary_version ) deployment.status = "rolled_back" await notify_team(f"Canary rollback for {deployment.agent_name}: {reason}") logger.error(f"Canary rolled back: {deployment.agent_name} v{deployment.canary_version} → v{deployment.stable_version}") Ми реалізували canary-контролер на Python з інтеграцією в Kubernetes через Flagger. Контролер підтримує кастомні роутери (gRPC, REST) і стандартний Ingress. Для кожного агента налаштовуються індивідуальні пороги метрик, що дозволяє тонко керувати якістю rollout.
Чому автоматичний відкат критичний?
Без автоматики rollback може зайняти години — поки черговий побачить алерт, розбереться і спрацює вручну. За цей час дефектна версія встигає зіпсувати дані або підірвати довіру. Наш canary-контролер відкочує версію за секунди — як тільки метрики виходять за поріг. Наприклад, при зростанні p99 latency з 200 мс до 800 мс (в 4 рази) відкат відбувається за 10 секунд, запобігаючи впливу на 95% користувачів.
Які метрики перевіряє canary health check?
class CanaryHealthChecker: THRESHOLDS = { "error_rate": {"max_absolute": 0.05, "max_relative_increase": 2.0}, "p99_latency_ms": {"max_relative_increase": 1.5}, "task_success_rate": {"min_absolute": 0.90, "max_relative_decrease": 0.1}, "quality_score": {"max_relative_decrease": 0.05}, } def is_healthy(self, stable_metrics: dict, canary_metrics: dict) -> HealthCheckResult: issues = [] for metric, thresholds in self.THRESHOLDS.items(): stable_val = stable_metrics.get(metric, 0) canary_val = canary_metrics.get(metric, 0) if "max_absolute" in thresholds and canary_val > thresholds["max_absolute"]: issues.append(f"{metric} too high: {canary_val:.3f} > {thresholds['max_absolute']}") if stable_val > 0 and "max_relative_increase" in thresholds: relative = canary_val / stable_val if relative > thresholds["max_relative_increase"]: issues.append(f"{metric} increased {relative:.1f}x vs stable") return HealthCheckResult(is_healthy=len(issues) == 0, issues=issues) | Метрика | Абсолютний поріг | Відносний поріг |
|---|---|---|
| error rate | < 5% | ≤ 2x від стабільної |
| p99 latency | < 5000 ms | ≤ 1.5x від стабільної |
| success rate | > 90% | ≥ 0.9x від стабільної |
| quality score | > 0.95 | ≥ 0.95x від стабільної |
Ключові метрики: error rate, p99 latency, success rate та quality score. Для LLM-агентів особливо важливий quality score — він виявляє галюцинації та небезпечний контент.
Порівняння методів деплою AI-агентів
| Метод | Час rollout | Ризик | Складність | Коли використовувати |
|---|---|---|---|---|
| Canary | 1-4 год | Низький | Середня | Критичні агенти, LLM з частими оновленнями |
| Blue-green | 5-10 хв | Середній | Висока | Швидкі релізи без довгих сесій |
| Rolling update | 10-30 хв | Високий | Низька | Некритичні мікросервіси |
Canary в 2-3 рази безпечніший за rolling update за ймовірністю масового інциденту. При довгих сесіях canary в 2 рази надійніший за blue-green, оскільки не вимагає повного перемикання середовища.
Інтеграція з Kubernetes
# Flagger (progressive delivery controller) для K8s apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: vllm-agent namespace: ai-serving spec: targetRef: apiVersion: apps/v1 kind: Deployment name: vllm-agent progressDeadlineSeconds: 3600 service: port: 8000 analysis: interval: 5m threshold: 5 # max failures before rollback maxWeight: 100 stepWeight: 10 # +10% кожні 5 хвилин metrics: - name: request-success-rate thresholdRange: min: 99 interval: 1m - name: request-duration thresholdRange: max: 5000 interval: 1m Наша команда має досвід в MLOps і успішно впровадила canary-деплой для більш ніж 20 проєктів, включаючи NLP та Computer Vision. Ми гарантуємо стабільність сервісу на кожному етапі rollout — з автоматичним моніторингом p99 latency та error rate кожні 5 секунд.
Референсна архітектура canary-пайплайну
1. Деплой canary-версії на 5% трафіку. 2. Збір метрик протягом 30 хвилин. 3. Порівняння з baseline — якщо відхилення в межах порогів, збільшення частки. 4. При перевищенні порогів — негайний rollback. 5. Повний rollout на 100% після успішного проходження всіх стадій.Процес роботи
- Аналітика: вивчаємо архітектуру агента, метрики та SLA.
- Проєктування: визначаємо етапи canary, пороги та тригери відкату.
- Реалізація: пишемо контролер на Python, інтегруємо з роутером трафіку.
- Тестування: симулюємо деградацію та перевіряємо rollback.
- Деплой: розгортаємо в Kubernetes через Flagger або власний оператор.
Що входить в роботу
- Розробка canary-контролера під вашу інфраструктуру.
- Налаштування моніторингу: метрики, алерти, дашборди Grafana.
- Документація по запуску та обслуговуванню.
- Навчання команди роботі з canary-пайплайном.
- Підтримка на етапі перших rollout.
Типові помилки при canary-деплої AI-агентів
Часта помилка — занадто коротке вікно спостереження: 5 хвилин замість 30 не дають статистично значущих даних. Ігнорування quality score небезпечне: LLM може відповідати швидко, але неправильно. Також важливий моніторинг на стороні користувача — метрики можуть бути хороші, але клієнти скаржаться. І нарешті, не варто використовувати однакові пороги для різних типів агентів: для чат-ботів latency критичніше, для аналізаторів — quality score.
Оцінимо ваш проєкт і запропонуємо оптимальне рішення. Зв'яжіться з нами для консультації. Замовте впровадження canary-деплою — і ваші AI-агенти оновлюватимуться без ризику.
Посилання: Flagger на GitHub — progressive delivery для Kubernetes. Canary deployment на Wikipedia.