Active-Active и Active-Passive топологии

Выбор топологии Multi-DC — один из самых важных архитектурных решений при проектировании отказоустойчивой системы на Kafka. Два принципиально разных подхода решают разные задачи: Active-Passive ставит простоту failover выше всего, Active-Active минимизирует задержку за счёт операционной сложности.

Не существует “правильной” топологии. Существует топология, соответствующая вашим требованиям по RPO, RTO, пропускной способности и операционной зрелости команды.

Active-Passive: надёжность через простоту

В Active-Passive топологии один кластер (Primary) обслуживает 100% трафика. Второй кластер (DR Standby) получает реплицированные данные, но в нормальном режиме не обслуживает ни продюсеров, ни consumer’ов.

Процедура failover в Active-Passive

Failover — это последовательность шагов, каждый из которых влияет на RPO или RTO. Понимание порядка критично:

1. Обнаружение сбоя. Мониторинг heartbeat-топика (heartbeats) на DC-2. Если heartbeat_age превышает порог (обычно 30-60 секунд), DC-1 считается недоступным. Также: потеря TCP-соединений от продюсеров.

2. Остановка продюсеров на DC-1. Это предотвращает запись данных в DC-1, которые не успеют реплицироваться. Application-level circuit breaker или внешний оркестратор отключает продюсеров.

3. Ожидание дренирования MM2. После остановки продюсеров MM2 продолжает реплицировать оставшиеся записи. Ожидание: tasks.max * replication_task_poll_interval. Если DC-1 полностью недоступен, этот шаг пропускается, принимая RPO = текущий lag.

4. Трансляция offset’ов consumer groups. При sync.group.offsets.enabled=true — автоматически. Иначе — вручную через RemoteClusterUtils.translateOffsets(). Подробно в уроке 03.

5. Переключение DNS/Load Balancer. Bootstrap servers продюсеров и consumer’ов перенаправляются на DC-2. TTL DNS влияет на скорость распространения изменения.

6. Перезапуск consumer’ов и продюсеров на DC-2. Consumer’ы подключаются к DC-2, находят committed offset’ы (автоматически транслированные) и возобновляют чтение из dc1.orders.

7. Верификация потока данных. Проверка через consumer lag мониторинг: records-lag-max для всех consumer groups должен снижаться.

Active-Active: двунаправленная репликация

В Active-Active оба кластера одновременно обслуживают продюсеров и consumer’ов. MM2 реплицирует данные в обоих направлениях. Цель: каждый регион обслуживает локальных пользователей с минимальной задержкой, при этом оба кластера содержат (почти) полный набор данных.

IdentityReplicationPolicy: обязательное требование

Для Active-Active обязательно использовать IdentityReplicationPolicy. Без неё:

• DefaultReplicationPolicy: DC-1 реплицирует orders -> DC-2 как dc1.orders. DC-2 реплицирует orders -> DC-1 как dc2.orders.
• Результат: на DC-1 существуют два разных топика: orders (локальный) и dc2.orders (реплика). Consumer’ы на DC-2 читают dc2.orders, а не orders. Логика приложения разрушена.

С IdentityReplicationPolicy: и DC-1, и DC-2 имеют топик orders с одинаковым именем. Consumer’ы используют одну и ту же конфигурацию независимо от того, к какому кластеру они подключены.

# Active-Active конфигурация mm2.properties
clusters = dc1, dc2

dc1.bootstrap.servers = dc1-broker1:9092,dc1-broker2:9092
dc2.bootstrap.servers = dc2-broker1:9092,dc2-broker2:9092

# Двунаправленная репликация
dc1->dc2.enabled = true
dc1->dc2.topics = .*
dc2->dc1.enabled = true
dc2->dc1.topics = .*

# Исключить внутренние топики MM2 из репликации (критично!)
dc1->dc2.topics.exclude = .*\.internal, heartbeats, .*\.replica
dc2->dc1.topics.exclude = .*\.internal, heartbeats, .*\.replica

# IdentityReplicationPolicy: топики сохраняют оригинальное имя
replication.policy.class = org.apache.kafka.connect.mirror.IdentityReplicationPolicy

# Heartbeat и checkpoint для обоих направлений
dc1->dc2.emit.heartbeats.enabled = true
dc2->dc1.emit.heartbeats.enabled = true
dc1->dc2.emit.checkpoints.enabled = true
dc2->dc1.emit.checkpoints.enabled = true

Предотвращение циклической репликации

Главная техническая проблема Active-Active: если DC-1 реплицирует запись на DC-2, а DC-2 реплицирует её обратно на DC-1, возникает бесконечный цикл.

MM2 решает это через заголовки. К каждой реплицированной записи добавляется заголовок __mm2.record.header.source.cluster.alias=dc1. Когда MirrorSourceConnector на DC-2 читает эту запись при репликации dc2->dc1, он проверяет заголовок: если source == “dc1” (текущий target), запись пропускается.

Дополнительная защита — явное исключение внутренних топиков через topics.exclude. Топики heartbeats, *.checkpoints.internal, *.internal не должны реплицироваться обратно.

Разрешение конфликтов в Active-Active

Kafka не имеет встроенного разрешения конфликтов для Active-Active записи. Если два продюсера в DC-1 и DC-2 одновременно записывают разные данные по одному ключу, порядок записей в обоих кластерах будет определяться задержкой репликации и порядком прибытия.

Практические стратегии:

Partition Affinity (рекомендованное решение). Каждый DC “владеет” своим диапазоном ключей. Например: DC-1 обслуживает пользователей с ID A-M, DC-2 обслуживает N-Z. Ни один ключ никогда не записывается одновременно из двух DC. Конфликтов нет по определению.

Application-level idempotency. Consumer’ы хранят версию каждой записи. При получении дублирующей записи проверяется версия: если входящая версия не выше уже обработанной, запись игнорируется. Требует хранилища версий (Redis, PostgreSQL).

CRDT-based merging. Конфликтующие значения merge’атся через структуры данных без конфликтов (Conflict-free Replicated Data Types). Применимо только для специфических типов данных (счётчики, наборы, timestamps).

Hub-and-Spoke и Fan-Out топологии

Помимо двух основных топологий, MM2 поддерживает более сложные паттерны для специфических архитектур.

Hub-and-Spoke: агрегация из множества источников

Применение Hub-and-Spoke: IoT-платформы (сотни edge-устройств -> центральная аналитика), многорегиональный CDC (несколько PostgreSQL баз -> центральный Kafka для стриминга в Data Warehouse), мультиарендные системы (каждый tenant = отдельный кластер, Hub = master).

Fan-Out: распределение из центра

Fan-Out — инверсия Hub-and-Spoke. Центральный кластер является источником данных (например, глобальный каталог товаров, конфигурация), а edge-кластеры получают реплики для локальных consumer’ов.

Применение Fan-Out: Глобальные справочники (каталог товаров, таблицы тарифов, конфигурация сервисов), централизованная авторизация (права доступа распределяются в регионы), событийные уведомления от центрального оркестратора в региональные сервисы.

Сравнительная таблица топологий

Ключевые выводы

1. Active-Passive — стандарт для Disaster Recovery. Простая конфигурация, предсказуемый failover, RTO 5-20 минут, RPO в секунды. DefaultReplicationPolicy добавляет prefix к топикам.
2. Active-Active — для геораспределённых систем с требованием низкой задержки. Обязателен IdentityReplicationPolicy. Требует явной стратегии разрешения конфликтов (partition affinity — самый безопасный выбор).
3. Циклическая репликация в Active-Active предотвращается заголовком __mm2.record.header.source.cluster.alias и явным исключением служебных топиков через topics.exclude.
4. Hub-and-Spoke и Fan-Out — специализированные топологии для IoT и распределения конфигурации соответственно.