Как организовать multi-region active-passive для LLM API?

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

Multi-region active-passive — это архитектура, при которой один регион (активный) обрабатывает 100% трафика, а второй (пассивный) находится в готовности, но не отвечает на запросы. Для LLM API критично обеспечить синхронную репликацию кэша (чтобы не терять закэшированные ответы) и асинхронную репликацию векторной базы данных (чтобы документы были доступны после переключения). Failover происходит при трёх подряд неудачных health check'ах: DNS-запись обновляется на пассивный регион. Целевой RTO (Recovery Time Objective) — менее 5 минут, RPO (Recovery Point Objective) — менее 1 минуты (допустимы потери только кэша, не данных).

1. Термины: active-passive, холодный и горячий резерв

Active-Passive (активно-пассивный) — режим работы, в котором один узел (регион) обслуживает запросы, а второй находится в резерве. Пассивный регион может быть:

• Холодный резерв (cold standby): инфраструктура есть, но сервисы не запущены. Время запуска — минуты или часы.
• Тёплый резерв (warm standby): сервисы запущены, загружена модель (model weights в памяти GPU), но трафик не принимается. Кэш и векторная БД могут быть частично синхронизированы.
• Горячий резерв (hot standby): пассивный регион полностью готов принимать трафик, но без балансировки нагрузки (обычно используется для active-active).

Для LLM API типичен warm standby, так как загрузка большой модели (например, 70B параметров) занимает несколько минут, а cold standby не укладывается в RTO.

RTO (Recovery Time Objective) — максимальное время, за которое система должна быть восстановлена после сбоя. Для LLM API обычно < 5 минут.

RPO (Recovery Point Objective) — максимальное количество потерянных данных (времени). Для кэша возможно потерять до 1 минуты данных (если кэш не успел реплицироваться). Векторная БД теряет меньше за счёт асинхронной репликации.

2. Архитектура multi-region active-passive для LLM API

2.1 Компоненты

Термин: CRDB (Conflict-Free Replicated Data Type) — структура данных, которая позволяет реплицировать кэш без конфликтов. Redis Enterprise CRDB обеспечивает синхронную репликацию с гарантией только однажды записанные данные будут прочитаны (strong consistency на уровне кэша).

2.2 Типичная схема

пользователи
   |
   v
DNS (us-east A-запись)
   |
   v
API Gateway (us-east)
   |
   +---> LLM Inference (GPU)
   |       |
   |       +---> Redis Cache (Primary)
   |       +---> Vector DB (Primary)
   |       +---> Postgres (Primary)
   |
   +---> (passive) -> eu-west (не используется, пока health check OK)

3. Репликация данных: кэш, векторная БД, модель

3.1 Кэш LLM-ответов (Redis)

Кэш хранит сгенерированные ответы для повторяющихся запросов. Потеря кэша не фатальна, но увеличивает latency. Для multi-region active-passive используется Redis Enterprise CRDB с синхронной репликацией. Почему синхронная? Потому что если активный регион упадёт, пассивный должен иметь актуальный кэш (иначе пользователи увидят «холодный старт»). Синхронная репликация увеличивает latency записи на время round-trip между регионами (например, us-east <-> eu-west ~ 60-100 мс), но это приемлемо для кэша.

Альтернатива Redis Sentinel + асинхронная репликация — дешевле, но возможна потеря до нескольких секунд кэша.

3.2 Векторная БД

Векторная БД (индекс эмбеддингов документов) реплицируется асинхронно:

• Запись происходит только в активном регионе.
• Изменения передаются в пассивный регион с задержкой (обычно < 1 минута).
• Во время failover пассивный регион может иметь не все последние документы (RPO ~ 1 минута).

Почему не синхронно Векторные БД имеют высокую нагрузку на запись (индексирование, перестроение HNSW-графа). Синхронная репликация через Атлантику сделала бы запись неприемлемо медленной.

3.3 Модель (LLM weights)

Веса модели хранятся в S3 / GCS с cross-region репликацией (например, S3 Cross-Region Replication). В пассивном регионе GPU-серверы уже загрузили модель из локального S3-бакета (или EBS-снапшота). Это обеспечивает время переключения < 1 минуты (сама модель уже в памяти).

4. Health checks и failover

4.1 Health check endpoint

Каждый регион предоставляет endpoint /health:

• Проверяет доступность LLM инференса (здоров ли GPU, не перегружен ли).
• Проверяет работу Redis, векторной БД, PostgreSQL.
• Возвращает HTTP 200 или 503.

Пример проверки (Python + asyncio):

async def health_check():
    try:
        await check_llm_inference()
        await check_redis()
        await check_vector_db()
        return {"status": "healthy"}, 200
    except Exception:
        return {"status": "unhealthy"}, 503

4.2 Механизм failover

Используется DNS-основанный failover (например, Route53 health checks):

1. Активный регион имеет A-запись с TTL = 60 секунд (или меньше).
2. Health check каждые 10 секунд опрашивает endpoint.
3. Если 3 последовательные проверки провалены (30 секунд) → регион помечается как unhealthy.
4. Route53 автоматически изменяет A-запись на пассивный регион (pre-existing запись с тем же именем).
5. DNS-обновление распространяется с учётом кэширования (обычно < 2 минут).

Дополнительно можно использовать anycast (например, Cloudflare) для быстрого переключения трафика на уровне сети, минуя DNS-кэш.

4.3 Время восстановления (RTO)

5. RPO и компромиссы

RPO < 1 минута означает, что после failover может быть потеряно:

• До 1 минуты кэшированных ответов (но они могут быть перегенерированы → дороже, но не катастрофично).
• До 1 минуты изменений в векторной БД (новые документы не проиндексированы → пользователь не найдёт).
• Никаких потерь в PostgreSQL (используется синхронная репликация с synchronous_commit = on).

Компромисс синхронная репликация Redis увеличивает latency записи. Если это неприемлемо, можно перейти на асинхронную, но тогда RPO для кэша составит секунды, а не 0.

6. Мониторинг и observability

Для multi-region active-passive критично:

• Метрики: latency p99, error rate, процент успешных health check'ов, время последней синхронизации реплик.
• Алерты при трёх подряд неудачных health check'ах, при рассинхронизации Redis CRDB, при падении региона.
• Дашборд (Grafana): карта регионов, статус каждого компонента, трафик.

Пример Prometheus метрик

# health check status
mcs_region_health{region="us-east"} 1
mcs_region_health{region="eu-west"} 0

# replication lag vector db (seconds)
mcs_vector_db_replication_lag{region="eu-west"} 35

# cache sync status
mcs_redis_sync_status{region="eu-west"} 1

7. Тестирование failover

Регулярно проводить Chaos Engineering Game Days:

• Выключить активный регион (убить процесс LLM или отключить сеть).
• Измерить RTO и RPO в автоматическом режиме.
• Проверить, что DNS переключился, кэш не потерян (синхронная репликация), модель перезагружается корректно.

Инструменты Chaos Mesh (Kubernetes), Gremlin, Litmus.

Ожидаемый результат сервис продолжает отвечать, latency временно возрастает (на время переключения), ошибок 5xx нет.

8. Альтернативы: active-active и multi-primary

Active-Active — оба региона обрабатывают трафик, нагрузка балансируется. Для LLM API это сложнее:

• Нужна синхронизация кэша (CRDB) и векторной БД (multi-master сложен).
• LLM инференс может давать разные ответы на одинаковые запросы из-за недетерминизма (temperature > 0). Это создаёт семантическую неконсистентность.
• Требует глобальной балансировки (Anycast, GSLB).

Когда лучше active-passive

• Высокие требования к консистентности (одинаковые ответы для одинаковых запросов).
• Низкая стоимость (не нужно держать оба региона под полной нагрузкой).
• Стабильный trafic pattern.

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

Задача Развернуть mini multi-region active-passive для имитации LLM API.

Инструменты

• Docker Compose (два «региона» localhost:8080 и localhost:8081).
• Nginx как reverse proxy и health checker.
• Redis с CRDB (Local Redis Enterprise или open-source KeyDB с репликацией).
• PostgreSQL с потоковой репликацией.
• Простой Python-сервер, эмулирующий LLM (возвращает задержку 200 мс + счётчик запросов).

Шаги:

1. Настроить два инстанса LLM-имитации (активный на порту 8081, пассивный на 8082).
2. Настроить Redis: master в активном регионе, slave в пассивном (с синхронной репликацией).
3. Настроить PostgreSQL: primary активный, standby пассивный (асинхронная репликация).
4. Написать health check endpoint /health для каждого региона.
5. Настроить Nginx: upstream active, резервный upstream. При health check failure (3 таймаута) переключать трафик.
6. Запустить скрипт, который отправляет запросы, потом убивает активный регион (docker stop).
7. Измерить время переключения и количество ошибок.

Ожидаемый результат после остановки активного региона через несколько секунд запросы начинают обрабатываться пассивным. RTO < 30 секунд (без DNS, только Nginx). В логах видно, что Redis-кэш не потерян.

Дополнительно добавить векторную БД (например, Qdrant) с асинхронной репликацией.

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

11. Навигация

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

Навигация

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