Налаштування Canary Deployment для ML-моделей

Налаштування Canary Deployment для ML-моделей

Canary deployment – стратегія поступового викочування нової версії моделі: спочатку на малу частку трафіку (5-10%), потім за відсутності проблем – на дедалі більшу аудиторію. Це знижує ризик деградації всім користувачів одночасно і дає можливість швидкого відкату.

Коли canary краще blue-green

Blue-green перемикає весь трафік відразу – підходить для сервісів із високою впевненістю у новій версії. Canary потрібен, коли:

• Модель навчена на нових даних, але реакція користувачів непередбачувана
• змінилася архітектура моделі (інший тип, інші вхідні ознаки)
• Критичний production-сервіс із високою ціною помилки
• Немає повного набору інтеграційних тестів

Реалізація на Kubernetes з KServe

KServe (колишній KFServing) підтримує canary з коробки:

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: fraud-detector
spec:
  predictor:
    canaryTrafficPercent: 10  # 10% на новую версию
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://models/fraud-detector-v2/
    # Предыдущая версия - canary baseline

Переключення трафіку без даунтайму:

# Увеличение с 10% до 50%
kubectl patch inferenceservice fraud-detector \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/predictor/canaryTrafficPercent", "value": 50}]'

# Продвижение канарейки в production (100%)
kubectl patch inferenceservice fraud-detector \
  --type='json' \
  -p='[{"op": "remove", "path": "/spec/predictor/canaryTrafficPercent"}]'

Реалізація на Seldon Core

apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
metadata:
  name: fraud-detector
spec:
  predictors:
    - name: main
      replicas: 3
      traffic: 90
      graph:
        name: fraud-v1
        implementation: SKLEARN_SERVER
        modelUri: s3://models/fraud-v1
    - name: canary
      replicas: 1
      traffic: 10
      graph:
        name: fraud-v2
        implementation: SKLEARN_SERVER
        modelUri: s3://models/fraud-v2

Автоматичне керування трафіком

Прогресивне збільшення трафіку автоматично на основі метрик:

def progressive_canary_rollout(service_name, metrics_client):
    stages = [5, 10, 25, 50, 100]

    for target_traffic in stages:
        set_canary_traffic(service_name, target_traffic)
        time.sleep(300)  # 5 минут стабилизации

        metrics = metrics_client.get_metrics(window='5m')

        # Проверка guardrail метрик
        if metrics['canary_error_rate'] > 0.01:
            rollback_canary(service_name)
            alert(f"Canary rollback: error rate {metrics['canary_error_rate']:.2%}")
            return False

        if metrics['canary_p99_latency_ms'] > 500:
            rollback_canary(service_name)
            alert("Canary rollback: latency SLA violated")
            return False

        if metrics['business_metric_delta'] < -0.02:  # -2% деградация
            rollback_canary(service_name)
            alert("Canary rollback: business metric degraded")
            return False

    return True  # Успешный полный деплой

Метрики для рішення про просування

Інтеграція з Argo Rollouts

Argo Rollouts - Kubernetes-контролер з підтримкою canary та blue-green для будь-яких workload, не тільки ML:

spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: {duration: 5m}
        - setWeight: 25
        - pause: {duration: 10m}
        - setWeight: 50
        - pause: {duration: 10m}
        - analysis:
            templates:
              - templateName: ml-model-metrics

Canary deployment як практика знижує MTTR (mean time to recovery) при деградації моделі: замість повного відкату та реплою достатньо зменшити canary-трафік до нуля.