Как вы проектируете multi-region active-active для LLM API?

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

Multi-region active-active для LLM API — это архитектура, при которой несколько географически распределённых регионов одновременно обслуживают запросы, обеспечивая высокую доступность и низкую задержку для пользователей по всему миру. Ключевые компоненты: глобальный балансировщик с region affinity (привязкой к региону), независимые LLM-кластеры и векторные БД в каждом регионе, асинхронная синхронизация кэша через PubSub (например, Redis Enterprise CRDB) для eventual consistency. При отказе региона трафик перенаправляется в другой регион с возможным cache miss, но данные остаются доступны за счёт полной репликации векторной БД.

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

Multi-region active-active — архитектура, в которой два или более географических региона одновременно обрабатывают запросы. В отличие от active-passive (один регион активен, другой — холодный резерв), здесь все регионы активны и могут обслуживать трафик.

Global load balancer — балансировщик, распределяющий трафик между регионами на основе геолокации пользователя, загрузки региона или других политик. Примеры: Cloudflare, Global Accelerator|AWS Global Accelerator, Azure Traffic Manager.

Region affinity — стратегия маршрутизации, при которой запросы от одного пользователя (или сессии) направляются в один и тот же регион, чтобы минимизировать cache miss и использовать локальные данные.

Eventual consistency — модель согласованности, при которой данные в разных регионах могут быть временно несинхронизированы, но в конечном итоге (обычно через несколько секунд) становятся одинаковыми. Это компромисс между доступностью и согласованностью (теорема CAP).

CRDB (Conflict-free Replicated Data Type Database) — база данных, использующая CRDT (Conflict-free Replicated Data Types) для автоматического разрешения конфликтов при асинхронной репликации. Redis Enterprise CRDB — пример такой системы.

Cache miss — ситуация, когда запрошенные данные отсутствуют в локальном кэше региона, и их нужно загружать из основной БД (или другого региона), что увеличивает задержку.

Failover — процесс автоматического переключения трафика с отказавшего региона на работающий.

2. Ключевые компоненты архитектуры

Архитектура multi-region active-active для LLM API включает следующие слои:

3. Глобальная балансировка нагрузки и region affinity

Global load balancer получает запрос пользователя, определяет его географию (по IP) и направляет в ближайший регион. Для обеспечения region affinity используется один из подходов:

• Sticky sessions — балансировщик запоминает регион для данного пользователя (по cookie или заголовку) и направляет все последующие запросы в тот же регион.
• Хэширование по user_id — вычисляется хэш от идентификатора пользователя, и по нему выбирается регион. Это гарантирует, что один пользователь всегда попадает в один регион (если количество регионов не меняется).

Пример настройки AWS Global Accelerator:

# Конфигурация endpoint group для двух регионов
accelerator:
  name: llm-api-accelerator
  listeners:
    - port: 443
      protocol: TCP
  endpoint_groups:
    - region: us-east-1
      endpoints:
        - endpoint_id: nlb-us-east-1
          weight: 100
    - region: eu-west-1
      endpoints:
        - endpoint_id: nlb-eu-west-1
          weight: 100
  traffic_dial_percentage: 100

Важно при отказе региона балансировщик автоматически перенаправляет трафик на здоровые регионы (с учётом affinity — если регион пользователя упал, он попадёт в другой, но без гарантии stickyness).

4. Синхронизация кэша и данных

В multi-region active-active каждый регион имеет свой экземпляр LLM и векторной БД. Векторная БД обычно реплицируется полностью (каждый регион хранит все документы), чтобы при failover не было потери данных. Однако кэш ответов LLM (например, для частых вопросов) может быть синхронизирован асинхронно.

Синхронизация кэша через PubSub (Redis Enterprise CRDB):

1. Когда в регионе A получен ответ от LLM, он сохраняется в локальный кэш Redis.
2. Redis Enterprise CRDB автоматически реплицирует запись в другие регионы через CRDT (Conflict-free Replicated Data Types), что позволяет избежать конфликтов при одновременных записях.
3. В регионе B при запросе сначала проверяется локальный кэш. Если там данных нет (cache miss), запрос уходит в LLM, и ответ кэшируется локально.

Eventual consistency означает, что запись из региона A может появиться в регионе B с задержкой (обычно 1–5 секунд). Это приемлемо для кэша, так как устаревший ответ не критичен (LLM может сгенерировать новый).

Альтернатива использование Kafka с кросс-региональной репликацией (MirrorMaker) для синхронизации событий инвалидации кэша.

5. Обработка отказов и failover

При отказе региона (например, сбой в дата-центре или недоступность LLM) происходит следующее:

1. Global load balancer обнаруживает недоступность endpoint'ов региона (по health check) и прекращает направлять туда трафик.
2. Трафик пользователей, которые были привязаны к отказавшему региону, перенаправляется в ближайший здоровый регион.
3. В новом регионе может возникнуть cache miss (кэш пуст для этого пользователя), но векторная БД содержит все данные, поэтому retrieval работает корректно.
4. LLM в здоровом регионе обрабатывает запрос, ответ кэшируется локально.
5. После восстановления отказавшего региона трафик постепенно возвращается (с учётом affinity).

Время переключения зависит от настроек health check (обычно 10–30 секунд). Для критичных систем используют active-active с двумя регионами, каждый из которых может выдержать 100% нагрузки (over-provisioning).

Пример конфигурации health check для AWS NLB:

health_check:
  protocol: HTTPS
  path: /health
  interval_seconds: 10
  timeout_seconds: 5
  healthy_threshold: 2
  unhealthy_threshold: 3

6. Компромиссы и ограничения

7. Альтернативные подходы

Active-passive (hot-standby): один регион активен, второй — в режиме ожидания. При отказе трафик переключается на пассивный регион, который поднимает LLM и БД. Это дешевле, но время переключения больше (минуты), и нет снижения latency для удалённых пользователей.

Multi-primary с синхронной репликацией все регионы активны, но данные синхронизируются синхронно (например, через Spanner или Cosmos DB). Это даёт сильную согласованность, но увеличивает latency записи и ограничивает географию (из-за скорости света).

Гибридный подход active-active для кэша (с eventual consistency) + active-passive для векторной БД (полная репликация, но только один регион пишет). Это снижает сложность синхронизации БД.

8. Пример реализации на стеке технологий

Предположим, мы строим multi-region active-active для LLM API на AWS.

Компоненты

• Global Accelerator — глобальный балансировщик с привязкой по IP.
• ECS Fargate / EKS — оркестрация LLM-сервисов (vLLM с моделью Llama 3).
• Pinecone — векторная БД с поддержкой multi-region (каждый регион имеет свою копию индекса, синхронизация через Pinecone's pod-based replication).
• Redis Enterprise CRDB — кэш ответов, реплицируемый между регионами через CRDT.
• Route53 — DNS-балансировка для fallback (если Global Accelerator недоступен).

Схема потока запроса

Пользователь (Европа) → Global Accelerator (eu-west-1)
  → NLB eu-west-1 → ECS (LLM) → проверка кэша Redis CRDB
    → если cache hit → ответ
    → если cache miss → LLM inference → запись в кэш → ответ
  → параллельно: Redis CRDB реплицирует запись в us-east-1

Failover при отказе eu-west-1, Global Accelerator направляет трафик в us-east-1. Пользователь может получить cache miss, но retrieval из Pinecone работает (данные есть в обоих регионах).

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

Задача Спроектировать и развернуть прототип multi-region active-active системы для LLM API (чат-бот с RAG) с двумя регионами.

Инструменты

• AWS (свободный аккаунт) или локально через Docker + Terraform
• Redis Stack (с поддержкой CRDT через Redis Enterprise, можно использовать Redis Cluster с Active-Active в Docker)
• LLM: Ollama (локально) или API OpenAI (для упрощения)
• Векторная БД: Qdrant (можно запустить в двух инстансах)
• Балансировщик: nginx с geo-модулем (для имитации global load balancer)

Шаги:

1. Настройка двух регионов — создайте две виртуальные машины (или Docker-контейнеры) в разных сетях (например, us-east и eu-west).
2. Разверните LLM — на каждой ВМ запустите Ollama с моделью (например, llama3.2:1b).
3. Разверните векторную БД — Qdrant на каждой ВМ, загрузите одинаковый набор документов.
4. Настройте Redis CRDB — используйте Redis Enterprise Docker image для создания active-active кластера между двумя ВМ.
5. Напишите API-сервис (FastAPI), который принимает запрос, проверяет кэш Redis, при miss вызывает LLM, сохраняет ответ в кэш.
6. Настройте nginx как глобальный балансировщик: по IP-адресу клиента направляйте в ближайший регион (можно использовать карту geoip).
7. Тестирование failover — остановите LLM в одном регионе, убедитесь, что запросы перенаправляются в другой регион, и ответы возвращаются (с возможным cache miss).

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

• Запросы от клиентов из США идут в us-east, из Европы — в eu-west.
• При отказе одного региона трафик переключается на другой, время ответа увеличивается не более чем на 30%.
• Кэш синхронизируется между регионами с задержкой < 5 секунд.

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

Навигация

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