Multi-region архитектура LLM-сервиса: failover без утечки данных и потери state

Multi-region начинается не с DNS

LLM-приложение состоит из gateway, модели, prompt registry, RAG, памяти, workflow engine, tools, secrets и наблюдаемости. Если вторичная модель отвечает, но не видит нужный индекс или tool API, пользовательский результат всё равно недоступен. Поэтому единица восстановления — полный workflow.

Когда multi-region действительно нужен

Несколько availability zones обычно закрывают многие инфраструктурные сбои дешевле. Multi-region оправдан, когда disaster model включает потерю региона, требуется предсказуемый RTO, пользователи географически распределены или данные обязаны обрабатываться в конкретной юрисдикции. Решение фиксируется threat/risk analysis и стоимостью простоя.

RTO, RPO и quality recovery objective

RTO — допустимое время восстановления. RPO — допустимая потеря состояния. Для ИИ добавьте quality recovery objective: какие модель, знания и tools допустимы после failover. Быстрый ответ слабой несовместимой модели не является восстановлением критичного сервиса.

Четыре стратегии DR

Региональная матрица возможностей

Не все модели, версии, quotas, embeddings, batch, fine-tuning и safety controls доступны одинаково. Создайте machine-readable catalog: provider, region, model alias, capabilities, context, tool support, data terms, quota и eval status. Router выбирает только прошедший policy и compatibility gate backend.

Data residency до routing

Регион пользователя не всегда равен разрешённому региону данных. Trusted tenant policy определяет, где могут находиться prompts, files, cache, logs, RAG, backups и support access. Географический fallback за пределы разрешённого набора должен завершиться безопасным отказом, а не «временным» нарушением.

Active-passive inference

Primary обрабатывает запросы, secondary прогревается и проверяется synthetic probes. Failover запускается по нескольким сигналам и с hysteresis, чтобы не флапать между регионами. Secondary имеет заранее выданную quota, проверенные model aliases, prompts и keys — создание доступа во время аварии увеличивает RTO.

Active-active и региональная привязка

Для stateless chat route может идти по latency. Для разговоров и workflows нужна affinity к home region, иначе состояние будет постоянно пересекать границы и конфликтовать. Перемещение session — отдельное событие с checkpoint, version и причиной, а не случайный выбор каждого запроса.

Workflow state и single-writer

Multi-master запись сложна для approvals, budgets и side effects. Практичная схема назначает один регион владельцем workflow, второй читает реплику и забирает ownership через fencing token при failover. Старый owner после восстановления не может продолжить запись со старым lease.

Идемпотентность во время разделения сети

Оба региона могут считать другой недоступным. Глобальный business key и authoritative store предотвращают двойное письмо или платёж. Если strong coordination недоступна, критичные write operations останавливаются; availability read-only функций не оправдывает split-brain side effects.

RAG: копировать файлы недостаточно

Secondary требует source objects, ACL, parser/chunker versions, embedding model, vector index и freshness manifests. Реплицируйте оригиналы и детерминированный manifest, чтобы индекс можно было проверить или перестроить. Сравнивайте document count, version coverage, orphan chunks, ACL checksum и retrieval eval между регионами.

Модель и embedding должны быть совместимы

Fallback embedding другой размерности или семантики нельзя писать в тот же индекс. Model alias содержит точную версию и eval report. Если secondary использует другую генеративную модель, прогоните одинаковый task set, tool calls, structured outputs и critical safety cases.

Tools должны существовать в регионе

Агент бесполезен без CRM, search, browser и internal APIs. Для каждого tool определите endpoint, auth, data route, timeout, idempotency и degraded behavior в каждом регионе. Private networking, DNS и certificates входят в failover drill. Не выводите tool в публичную сеть только ради DR.

Secrets, keys и policies

Vault/KMS, signing keys, policy bundles и workload identity должны иметь поддерживаемую региональную стратегию. Репликация секрета не означает одинаковые права: secondary role заранее ограничена тем же scope. Audit фиксирует, какой регион и key ID выполнили действие.

Глобальный gateway и health

Health endpoint модели недостаточен. Synthetic transaction проверяет auth, prompt registry, inference, retrieval и безопасный read-only tool. Router учитывает circuit breaker, quota saturation и data policy. Control plane outage не должен уничтожать последнюю проверенную routing config в data plane.

Failover runbook

1. Подтвердить влияние и scope.
2. Заморозить опасные writes или fencing primary.
3. Проверить replication lag и secondary readiness.
4. Передать ownership workflows.
5. Переключить ограниченный canary traffic.
6. Проверить quality, tools и data policy.
7. Расширить route с наблюдением.
8. Сверить unknown side effects.
9. Сообщить пользователям уровень деградации.

Failback опаснее, чем кажется

Возврат в primary требует определить источник истины, догнать данные, сверить side effects и погасить старые leases. Выполните reverse replication, consistency checks и canary. Не переключайте трафик сразу после зелёного health: причина аварии и backlog могут ещё существовать.

Chaos и регулярные DR drills

Tabletop не доказывает RTO. В безопасном окне отключайте route к primary, замедляйте replication, убирайте model quota и ломайте один tool. Измеряйте time to detect, decision, fencing, first successful result, full capacity и failback. Findings превращаются в backlog с owner и сроком.

Метрики и стоимость

Dashboard показывает traffic, error, latency, quality sample, quota, replication lag, index freshness, active workflow owners и tool health по региону. Отдельно считайте standby cost и cost per recovered transaction. Active-active без проверяемого business benefit часто дороже хорошо отрепетированного warm standby.

План внедрения

1. Определить disaster scenarios, RTO/RPO и residency.
2. Нарисовать все зависимости workflow.
3. Выбрать DR tier по use case.
4. Создать региональный capability catalog.
5. Реплицировать state и manifests.
6. Ввести ownership и fencing.
7. Проверить models, RAG и tools.
8. Настроить synthetic end-to-end probe.
9. Провести failover и failback drill.
10. Сравнить фактические RTO/RPO с целями.

← Все статьи блога