Kafka как интеграционная платформа: от источников данных к потребителям и в хранилище (часть 2) / Comments / Habr

e11it Sep 26 2022 at 12:48

Сами данные в Кафке мы не бекапим, полагаемся на те возможности и гарантии, которые предоставляет сама Кафка. Топики по умолчанию создаются с фактором репликации 3 (и min.insync.replicas=2).

Ноду или кластер мы всегда можем легко восстановить за 10 минут прогнав ansible плейбук в AWX(мы делаем все через ansible: от разметки дисков, до конфигурирования кластера и управления доступом).

Мы зависим от следующий сервисов, чтобы восстановиться:

платформа виртуализации
DNS
AWX
Gitlab (тут лежит inventory для awx, ansible роли, ACL для кластера Kafka и Kafka REST)
Vault (сертификаты, пароли)

Кластерами пользуются большое количество систем. Сервис Kafka, как интеграционная платформа, находится по середине между ИС и является буфером обмена между системами, который развязывает их SLA. Наличие процедуры бекапа данных подразумевает создание периодической процедуры тестирования восстановления. На практике это довольно сложно выполонимо, так как потребуется реализация соответствующей логики для тестирования на стороне систем, использующих Kafka . Плюс, не всем информационным системам это нужно. Поэтому, продолжая аналогию "глупый брокер, умный клиент", мы используем подход "глупый кластер, умная ИС" =). Т.е. это все переносится на уровень дизайна интеграций конкретных информационных систем.

И там уже, если это необходимо, можно:

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