Как вы делаете blue-green deployment для RAG системы с zero downtime?

Краткий тезис

Blue-green deployment — это стратегия релиза, при которой одновременно работают две идентичные production-среды: Blue (текущая стабильная версия) и Green (новая версия). Трафик постепенно переключается с Blue на Green после успешного прохождения smoke-тестов и мониторинга ключевых метрик. Для RAG-системы это особенно важно, потому что компоненты (векторная БД, модели эмбеддингов, LLM) являются stateful и требуют синхронизации данных без прерывания сервиса. Zero downtime достигается за счёт того, что в любой момент хотя бы одна среда готова обслуживать запросы, а переключение происходит на уровне балансировщика нагрузки.

1. Термины и определения

• Blue-Green Deployment — техника, при которой создаются две отдельные среды (Blue — текущая production, Green — новая версия). Трафик направляется на Blue, пока Green не будет полностью протестирована и признана стабильной. Затем трафик переключается на Green, а Blue остаётся в качестве резерва для быстрого отката.
• Zero Downtime — свойство системы, при котором обновление происходит без прерывания доступности сервиса для пользователей. Все запросы обрабатываются непрерывно.
• Load Balancer — компонент, распределяющий входящий трафик между несколькими экземплярами приложения (например, Nginx, AWS ALB, Kubernetes Service). В blue-green он переключает трафик между средами.
• Health Check — механизм, проверяющий, что экземпляр приложения готов принимать трафик (обычно HTTP endpoint /health). Балансировщик исключает нездоровые экземпляры из ротации.
• Smoke Test — быстрый набор автоматизированных тестов, проверяющих критическую функциональность (например, что RAG возвращает ответ на простой запрос, latency в норме). Выполняется на Green до переключения трафика.
• Rollback — возврат к предыдущей версии (Blue) в случае обнаружения проблем на Green. В blue-green это тривиально: достаточно переключить балансировщик обратно.

2. Почему blue-green deployment важен для RAG?

RAG-система состоит из нескольких слоёв:

• Embedding model — преобразует запросы и документы в векторы.
• Vector database — хранит и индексирует векторы (например, Pinecone, Weaviate, Qdrant).
• LLM — генерирует ответ на основе найденных документов.
• Orchestrator — связывает retrieval и generation (например, LangChain, LlamaIndex).

Обновление любого из этих компонентов (новая модель эмбеддингов, изменение чанков, обновление LLM) может привести к несовместимости данных или временной недоступности. Blue-green позволяет:

• Протестировать новую версию на реальном трафике (сначала малый процент).
• Мгновенно откатиться без потери данных.
• Избежать ситуации, когда часть запросов обрабатывается старой версией, а часть — новой (если это нежелательно).

3. Архитектура blue-green для RAG

                    ┌─────────────┐
                    │  Load       │
                    │  Balancer   │
                    └──────┬──────┘
                           │
              ┌────────────┴────────────┐
              │                         │
         ┌────▼─────┐            ┌─────▼────┐
         │  Blue    │            │  Green   │
         │ (v1.0)   │            │ (v2.0)   │
         └────┬─────┘            └─────┬────┘
              │                        │
         ┌────▼─────┐            ┌─────▼────┐
         │ VectorDB │            │ VectorDB │
         │ (v1 idx) │            │ (v2 idx) │
         └──────────┘            └──────────┘

Каждая среда содержит полный стек: свой экземпляр векторной БД (или отдельный индекс), свой LLM endpoint, свой orchestrator. База данных может быть общей, но тогда нужно обеспечить обратную совместимость схемы. Чаще используют отдельные индексы для каждой версии, чтобы избежать конфликтов.

4. Процесс деплоя шаг за шагом

Шаг 1: Подготовка Green

• Разворачивается полный стек Green (новые версии компонентов).
• Загружаются новые эмбеддинги документов (если изменилась модель или чанкинг).
• Индекс векторной БД строится параллельно, без влияния на Blue.
• Green проходит внутренние smoke-тесты (health check, базовый retrieval).

Шаг 2: Smoke-тесты на Green

• Автоматические тесты: отправка 10–20 типовых запросов, проверка наличия ответа, faithfulness (с помощью LLM-as-judge), latency.
• Если тесты не пройдены — деплой останавливается, Green уничтожается.

Шаг 3: Постепенное переключение трафика

• 10% трафика на Green на 5–10 минут. Мониторинг:
  • Error rate (5xx, 4xx)
  • P50/P95 latency
  • Retrieval recall (сравнение с Blue через A/B тестирование)
  • Faithfulness (автоматическая оценка)
• Если метрики в норме → 50% трафика на Green.
• Если снова OK → 100% трафика на Green.

Шаг 4: Мониторинг стабильности

• Green работает под полной нагрузкой 15–30 минут.
• Сравнение метрик с историческими данными Blue.
• При любом отклонении (latency > 2x baseline, error rate > 0.1%) — автоматический rollback.

Шаг 5: Финализация

• Blue переводится в режим ожидания (hot standby) на случай отката.
• Если через N часов (например, 24) проблем нет — Blue можно выключить или использовать для следующего деплоя.

5. Особенности для RAG-системы

5.1 Stateful компоненты

• Vector database — данные (индексы) могут быть большими (гигабайты). Синхронизация между Blue и Green:
  • Использовать репликацию (например, Qdrant поддерживает multi-node кластер).
  • Или строить индекс Green с нуля из того же источника данных, но с новыми параметрами.
• Кэш эмбеддингов — если используется кэш для частых запросов, его нужно сбросить или перестроить для Green.

5.2 Длительные запросы (draining)

• Некоторые запросы к LLM могут выполняться десятки секунд. При переключении балансировщика нужно:
  • Дать завершиться текущим запросам на Blue (graceful shutdown).
  • Не прерывать соединения насильно.
• Решение: настроить connection draining на балансировщике (например, AWS ALB позволяет задать таймаут).

5.3 Совместимость форматов

• Если меняется модель эмбеддингов, векторы в Green будут другой размерности. Нужно убедиться, что orchestrator Green ожидает именно такие векторы.
• Если меняется prompt template, ответы могут отличаться по стилю — это нормально, но нужно предупредить пользователей.

6. Инструменты и пример конфигурации

Kubernetes + Nginx Ingress

# Blue deployment (v1)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rag-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rag
      version: blue
  template:
    metadata:
      labels:
        app: rag
        version: blue
    spec:
      containers:
      - name: rag
        image: myregistry/rag:v1
        ports:
        - containerPort: 8000
---

# Green deployment (v2)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: rag-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rag
      version: green
  template:
    metadata:
      labels:
        app: rag
        version: green
    spec:
      containers:
      - name: rag
        image: myregistry/rag:v2
        ports:
        - containerPort: 8000
---

# Service (load balancer)
apiVersion: v1
kind: Service
metadata:
  name: rag-service
spec:
  selector:
    app: rag
    version: blue  # изначально blue
  ports:
  - port: 80
    targetPort: 8000

При переключении меняем selector на version: green. Можно автоматизировать через скрипт или ArgoCD.

Smoke-тест (Python)

import requests
import time

def smoke_test(url, test_queries):
    for query in test_queries:
        resp = requests.post(f"{url}/query", json={"question": query})
        assert resp.status_code == 200
        assert len(resp.json()["answer"]) > 0
        # дополнительно проверить latency
        assert resp.elapsed.total_seconds() < 5.0
    print("Smoke tests passed")

smoke_test("http://green-rag.internal", ["Что такое RAG?", "Как работает attention?"])

7. Мониторинг и алертинг

Ключевые метрики для RAG при blue-green:

Настройка алертов в Prometheus + Alertmanager. При срабатывании — автоматический rollback (переключение балансировщика обратно на Blue).

8. Проблемы и подводные камни

• Стоимость: две полные production-среды требуют двойных ресурсов (GPU для LLM, storage для векторной БД). Можно использовать меньшие инстансы для Green на время тестирования, но это увеличивает latency.
• Время прогрева: LLM и embedding модели могут требовать загрузки в GPU (30–60 секунд). Green должен быть полностью готов до начала переключения.
• Синхронизация данных: если документы обновляются часто, нужно решить, как синхронизировать индексы между Blue и Green. Вариант: общий источник данных (S3) и перестроение индекса при каждом деплое.
• Совместимость схемы: новая версия может изменить формат ответа (например, добавить поля). Клиенты должны быть готовы к этому, или нужно использовать versioned API.

9. Альтернативы blue-green

Blue-green — самый безопасный для stateful систем, но дорогой.

10. Практические рекомендации

• Автоматизируйте всё: деплой, smoke-тесты, переключение, откат. Используйте CI/CD (GitLab CI, GitHub Actions) и GitOps (ArgoCD).
• Документируйте runbook: что делать при ошибке, как вручную переключить, как проверить health.
• Используйте feature flags: если изменения касаются только логики (не данных), можно включать новую функциональность без переключения всей среды.
• Тестируйте откат: регулярно проводите «game days», чтобы убедиться, что rollback работает за секунды.

Пет-проект для закрепления

Задача: Развернуть простую RAG-систему (FastAPI + Chroma + OpenAI API) и реализовать blue-green деплой с zero downtime на локальной машине с помощью Docker Compose и Nginx.

Инструменты:

• Docker, Docker Compose
• Nginx (как load balancer)
• Python, FastAPI, LangChain, ChromaDB
• curl, siege (для нагрузочного теста)

Шаги:

1. Напишите RAG-приложение с эндпоинтом /query и /health.
2. Соберите два Docker-образа: rag:v1 (старая версия) и rag:v2 (новая, например, с другим prompt).
3. Создайте docker-compose.yml с тремя сервисами:
   • rag-blue (v1)
   • rag-green (v2)
   • nginx (балансировщик, проксирующий на blue)
4. Настройте Nginx: upstream blue и green, активный backend — blue.
5. Напишите скрипт switch.sh, который меняет конфигурацию Nginx (переключает upstream) и перезагружает его без даунтайма (nginx -s reload).
6. Запустите siege или простой цикл curl во время переключения, чтобы убедиться, что запросы не падают.
7. Добавьте smoke-тест (curl /health на green перед переключением).

Ожидаемый результат:

• Во время переключения (с blue на green) все запросы успешно обрабатываются (HTTP 200).
• latency не возрастает более чем на 10%.
• После переключения green отвечает на запросы, blue остаётся в standby.

Связь с другими вопросами

Навигация

• Предыдущий: 409
• Следующий: 411
• Индекс: 00. Индекс разборов