Как вы делаете multi-region failover с RTO <5 минут?

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

Для достижения RTO (Recovery Time Objective) менее 5 минут при отказе целого региона в Agentic RAG-системе применяется архитектура active-passive с warm standby. Ключевые элементы: синхронная репликация векторной базы данных между регионами, DNS-балансировка с автоматическим переключением на основе health checks, а также оркестрация через Kubernetes multi-cluster и service mesh. Регулярные тесты failover и Chaos Engineering гарантируют, что целевое время восстановления соблюдается.

1. Термины RTO и RPO

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

RPO (Recovery Point Objective) — максимально допустимая потеря данных (время между последней успешной репликацией и сбоем). Для синхронной репликации RPO стремится к нулю, для асинхронной — может составлять секунды или минуты. При RTO <5 минут обычно выбирают синхронную репликацию или очень быструю асинхронную с RPO <1 секунды.

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

2. Архитектура active-passive vs active-active

Для RTO <5 минут чаще выбирают active-passive с warm standby. Резервный регион держит полную копию данных и готов принять трафик мгновенно. Active-active применяется, когда нужна глобальная низкая задержка для пользователей, но тогда RTO может быть выше из-за необходимости разрешения конфликтов.

3. DNS failover и health checks

DNS failover — механизм, при котором DNS-сервер (например, AWS Route53, Cloudflare, Azure DNS) автоматически меняет A/AAAA-записи или CNAME при обнаружении недоступности основного региона.

Health checks — периодические HTTP/HTTPS/TCP запросы к эндпоинту приложения (например, /healthz). Если несколько последовательных проверок (обычно 2–3) завершаются ошибкой, DNS-провайдер помечает регион как нездоровый и начинает возвращать IP резервного региона.

TTL (Time To Live) DNS-записей должен быть низким (10–30 секунд), чтобы клиенты быстро получили новый IP. Однако слишком низкий TTL увеличивает нагрузку на DNS-серверы. Компромисс: TTL = 60 секунд, а для критических систем — 10 секунд.

Пример настройки AWS Route53

• Создаётся Failover routing policy с двумя записями: primary (основной регион) и secondary (резервный).
• К каждой записи привязан health check (например, проверка ALB в регионе).
• При падении health check primary, Route53 автоматически возвращает IP secondary.

4. Репликация векторной базы данных

Векторная БД (например, Qdrant, Pinecone, Weaviate, Milvus) — центральное хранилище эмбеддингов. Для failover необходима репликация данных между регионами.

Синхронная репликация

• Каждая запись (insert/update) подтверждается только после записи в оба региона.
• RPO = 0 (нет потери данных).
• Latency увеличивается на время передачи между регионами (обычно 10–50 мс).
• Подходит для active-passive, так как резервный регион всегда имеет актуальные данные.

Асинхронная репликация

• Запись подтверждается сразу в основном регионе, затем асинхронно отправляется в резервный.
• RPO > 0 (возможна потеря последних изменений).
• Latency не увеличивается.
• При RTO <5 минут асинхронная репликация допустима, если RPO не критичен (например, потеря нескольких секунд данных).

Практические реализации

• Qdrant: поддерживает multi-node cluster с Raft consensus внутри региона, а между регионами — streaming replication (синхронная или асинхронная) через gRPC.
• Weaviate: multi-region replication через async replication с eventual consistency.
• Pinecone: управляемый сервис с автоматической репликацией между регионами (настраивается через API).

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

5. Оркестрация и service mesh

Kubernetes multi-cluster позволяет развернуть приложение в двух регионах с одинаковыми манифестами. Для failover используются:

• Cluster API или Kubefed для управления несколькими кластерами.
• Service mesh (Istio, Linkerd, Consul Connect) для маршрутизации трафика между регионами и автоматического переключения при отказе.

Пример с Istio

• В каждом регионе развёрнут Istio ingress gateway.
• Глобальный VirtualService направляет трафик на основной регион.
• DestinationRule с trafficPolicy (connectionPool, outlierDetection) позволяет обнаруживать сбои и перенаправлять запросы в резервный регион.
• Health checks на уровне pod'ов и сервисов.

Service mesh также обеспечивает retry и timeout для запросов между регионами, что критично при синхронной репликации.

6. Мониторинг и детекция сбоев

Для RTO <5 минут необходимо быстрое обнаружение отказа. Используются:

• External health checks от DNS-провайдера (каждые 10–30 секунд).
• Internal health checks от service mesh (каждые 1–5 секунд).
• Synthetic monitoring (например, Datadog, Grafana Synthetic Monitoring) — имитация пользовательских запросов из разных точек мира.
• Alerting на основе метрик: latency > порога, error rate > 1%, недоступность эндпоинта.

Пороги

• Если 3 последовательных health check'а не прошли → регион считается отказавшим.
• Если latency превышает 2 секунды в течение 1 минуты → возможно частичное отключение.

Инструменты

• Prometheus + Alertmanager для сбора метрик и отправки уведомлений.
• PagerDuty / Opsgenie для эскалации.

7. Процедура failover

1. Обнаружение отказа — health check'и фиксируют недоступность основного региона.
2. Автоматическое переключение DNS — Route53 меняет запись на резервный регион (обычно в течение 30–60 секунд с учётом TTL).
3. Перенаправление трафика — все новые запросы идут в резервный регион.
4. Проверка целостности — резервный регион должен иметь актуальные данные (синхронная репликация гарантирует это).
5. Уведомление команды — автоматический алерт о failover.
6. Failback (после восстановления основного региона) — ручной или автоматический (с переключением обратно после стабилизации health check'ов).

RTO <5 минут достигается, если:

• DNS TTL ≤ 60 секунд (лучше 10–30).
• Health check интервал ≤ 10 секунд.
• Резервный регион полностью прогрет (warm) — все сервисы запущены, данные синхронизированы.

8. Тестирование и Chaos Engineering

Регулярные тесты failover обязательны. Подходы:

• GameDays — запланированные учения, где симулируется отказ региона.
• Chaos Engineering — инструменты (Chaos Mesh, Litmus, Gremlin) вносят сбои в production-подобную среду: отключают сеть, убивают pod'ы, задерживают трафик.
• Automated failover tests — скрипты, которые отключают основной регион и проверяют, что RTO <5 минут.

Метрики тестирования

• Время обнаружения сбоя.
• Время переключения DNS.
• Время первого успешного запроса в резервном регионе.
• Процент потерянных запросов (должен быть <1%).

9. Проблемы и компромиссы

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

• Active-active с CRDT (Conflict-free Replicated Data Types) — для векторных БД, поддерживающих eventual consistency (например, Cassandra-like). RTO может быть ниже, но RPO не гарантирован.
• Global load balancer с anycast (например, Cloudflare, AWS Global Accelerator) — трафик автоматически направляется в ближайший здоровый регион, failover происходит на уровне сети (BGP), RTO <1 минуты.
• Multi-region с read replicas — основной регион принимает записи, резервные только читают. При отказе основного региона резервный переключается на запись (требуется ручное вмешательство или автоматизация).

Для Agentic RAG (где агенты могут писать в векторную БД результаты своих действий) синхронная репликация и active-passive — наиболее надёжный вариант.

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

Задача Развернуть минимальную multi-region RAG-систему с RTO <5 минут в локальной среде (Docker).

Инструменты

• Docker Compose (два кластера: region-a, region-b)
• Qdrant (векторная БД, синхронная репликация между регионами через gRPC)
• Nginx (как reverse proxy с health check и failover)
• Python (FastAPI для RAG-приложения)
• Скрипт для эмуляции отказа региона

Шаги:

1. Создать два docker-compose файла для каждого региона: Qdrant (single node), FastAPI-приложение, Nginx.
2. Настроить Qdrant: включить replication между регионами (синхронную) через --grpc-port и указать peers.
3. Настроить Nginx: upstream с двумя серверами (region-a и region-b), health_check на /health, fail_timeout=5s.
4. Написать FastAPI-приложение с эндпоинтом /query (поиск по Qdrant) и /health.
5. Запустить оба региона. Проверить, что запросы идут в region-a.
6. Остановить region-a (docker stop). Убедиться, что Nginx автоматически перенаправляет запросы в region-b в течение <5 секунд.
7. Измерить RTO с помощью скрипта, который шлёт запросы каждую секунду и фиксирует время простоя.

Ожидаемый результат При отказе основного региона система переключается на резервный за <5 секунд (локально). Данные, записанные до отказа, доступны в резервном регионе (синхронная репликация).

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

Навигация

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