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

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

Blue-green deployment — это стратегия релиза, при которой поддерживаются два идентичных production-окружения (blue и green), и трафик переключается между ними с помощью load balancer. Для RAG-системы это особенно важно, так как обновление компонентов (эмбеддер, векторная БД, LLM) не должно прерывать обслуживание пользователей. Ключевой момент — синхронизация состояния (индексов, кэша) между окружениями и постепенное переключение трафика (10% → мониторинг → 100%) с возможностью мгновенного отката.

1. Термины: Blue-Green, Zero Downtime, Load Balancer

Blue-green deployment — техника, при которой два окружения (условно «blue» — текущее, «green» — новое) работают параллельно. Трафик направляется только на одно из них через load balancer (балансировщик нагрузки). Когда новое окружение (green) готово и протестировано, балансировщик переключает трафик с blue на green.

Zero downtime (нулевое время простоя) — цель, при которой пользователи не замечают переключения: все запросы обрабатываются непрерывно, без ошибок 503 или таймаутов.

Load balancer — компонент, распределяющий входящие запросы между серверами. В контексте blue-green он управляет переключением трафика между окружениями (например, NGINX, AWS ALB, Kubernetes Service).

Для RAG-системы zero downtime критичен, потому что:

• Пользователи могут быть в середине диалога (сессии)
• Обновление индексов или модели эмбеддингов не должно «ломать» поиск
• LLM-инференс может быть дорогим, и перезапуск всего стека приведёт к потере запросов

2. Зачем RAG-системе blue-green deployment?

RAG-система состоит из нескольких компонентов, каждый из которых может обновляться независимо:

• Embedding model (модель эмбеддингов) — при смене модели все документы нужно переиндексировать
• Vector database (векторная БД) — обновление схемы, индексов, параметров поиска
• LLM (языковая модель) — смена модели или её версии (например, GPT-4 → GPT-4-turbo)
• Reranker — изменение алгоритма ранжирования
• Application logic — код пайплайна (chunking, prompt template)

Без blue-green deployment любое обновление потребует остановки сервиса, что неприемлемо для production. Blue-green позволяет:

• Подготовить новое окружение (green) с новыми индексами и моделями, не влияя на текущее (blue)
• Протестировать green в изоляции (внутренние запросы, интеграционные тесты)
• Переключить трафик плавно (canary) или мгновенно
• Откатиться на blue за секунды, если что-то пошло не так

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

Типичная архитектура включает:

Важно: векторная БД и эмбеддинги должны быть согласованы. Если меняется модель эмбеддингов, то green должен иметь свой индекс, построенный новой моделью. Blue продолжает использовать старый индекс.

4. Процесс blue-green deployment для RAG (пошагово)

Шаг 1: Подготовка green окружения

• Разворачиваем полный стек RAG на green (новые модели, новый код)
• Переиндексируем все документы новой моделью эмбеддингов (если модель изменилась)
• Запускаем green, но не направляем на него пользовательский трафик

Шаг 2: Внутреннее тестирование green

• Прогоняем автоматические тесты (набор эталонных запросов, сравнение ответов с blue)
• Проверяем метрики качества retrieval (hit rate, MRR) на green
• Проверяем latency (время ответа) — новая модель может быть медленнее

Шаг 3: Canary-переключение (постепенное)

• Настраиваем load balancer на направление 10% трафика на green, 90% на blue
• Мониторим ошибки, latency, метрики качества (faithfulness, answer relevance)
• Если всё стабильно, увеличиваем долю green до 50%, затем до 100%

Шаг 4: Полное переключение на green

• Весь трафик идёт на green
• Blue остаётся в режиме ожидания (standby) для отката

Шаг 5: Мониторинг и финализация

• Наблюдаем за green в течение 24–48 часов
• Если проблем нет — blue можно выключить или использовать для следующего релиза

Откат (rollback)

• Если на green обнаружены проблемы, load balancer мгновенно переключает весь трафик обратно на blue
• Green выключается или помечается как невалидный

5. Особенности для RAG: синхронизация состояния

RAG-система — stateful (сохраняет состояние): индексы, кэш, сессии пользователей. Это усложняет blue-green.

Проблема 1: Индексы векторной БД

• Если меняется модель эмбеддингов, green должен иметь свой индекс
• Решение: переиндексация в фоне до переключения трафика
• Инструменты: параллельное построение индекса (например, с помощью bulk API в Pinecone/Weaviate)

Проблема 2: Кэш (например, Redis)

• Если кэш общий, то после переключения на green кэш blue становится неактуальным (другие эмбеддинги)
• Решение: использовать отдельный кэш для каждого окружения или инвалидировать кэш после переключения

Проблема 3: Сессии пользователей

• Если пользователь начал диалог на blue, а трафик переключился на green, история может потеряться
• Решение: хранить сессии во внешней БД (PostgreSQL, Redis), доступной обоим окружениям; green читает историю из общего хранилища

Проблема 4: LLM-кэш (KV-cache)

• Для LLM с длинным контекстом (например, GPT-4) кэш ключ-значение ускоряет инференс
• При переключении кэш теряется, но это допустимо — первый запрос будет медленнее

6. Инструменты для blue-green deployment RAG

Пример конфигурации Kubernetes Service для blue-green:

apiVersion: v1
kind: Service
metadata:
  name: rag-service
spec:
  selector:
    app: rag
    environment: blue  # меняется на green при переключении
  ports:
  - port: 80
    targetPort: 8080

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

8. Пример: blue-green для RAG на Kubernetes с Helm

Структура Helm-чарта:

rag-chart/
├── templates/
│   ├── deployment-blue.yaml
│   ├── deployment-green.yaml
│   ├── service.yaml
│   └── configmap.yaml
└── values.yaml

values.yaml:

active:
  environment: blue  # или green

blue:
  image: rag-app:1.0
  embeddingModel: text-embedding-ada-002
  vectorIndex: idx-ada-002

green:
  image: rag-app:2.0
  embeddingModel: text-embedding-3-small
  vectorIndex: idx-3-small

service.yaml динамически выбирает active окружение через {{ .Values.active.environment }}.

Процесс деплоя:

1. Меняем values.yaml: active.environment: green
2. helm upgrade — Kubernetes Service переключает селектор
3. Traefik/NGINX ingress начинает направлять трафик на green pods

9. Мониторинг и алертинг при blue-green

Ключевые метрики для отслеживания во время переключения:

Инструменты: Prometheus + Grafana, ELK для логов, RAGAS для онлайн-оценки.

10. Альтернативы blue-green для RAG

Blue-green — лучший выбор для RAG, так как он гарантирует zero downtime и мгновенный откат, что критично для production.

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

Задача Развернуть мини-RAG систему (FAISS + Hugging Face embeddings + простой LLM через Ollama) с blue-green deployment на локальном Kubernetes (minikube).

Инструменты

• Minikube (локальный Kubernetes)
• Docker (сборка образов)
• Python (FastAPI для RAG API)
• FAISS (векторная БД)
• Hugging Face sentence-transformers (эмбеддинги)
• Ollama (локальный LLM, например, llama3.2)
• Helm (управление чартами)

Шаги:

1. Создать два Docker-образа: rag-app:v1 (старая модель эмбеддингов) и rag-app:v2 (новая модель)
2. Написать Helm-чарт с двумя Deployment (blue, green) и Service с переключаемым селектором
3. Развернуть v1 как blue, протестировать API
4. Собрать v2, развернуть как green (без трафика)
5. Переключить Service на green, проверить zero downtime (непрерывные запросы во время переключения)
6. Реализовать откат обратно на blue

Ожидаемый результат При переключении с blue на green ни один HTTP-запрос не завершится ошибкой, а ответы будут от новой модели эмбеддингов.

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

Навигация

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