Kafka и потоковая передача событий: что нужно понимать руководителю
Понятное объяснение того, почему компании переходят на событийные потоки данных, что делает Kafka и когда сложность оправдана.
Ещё год назад я объяснял Kafka только техническим директорам и пропускал это в разговорах с остальными. Сейчас ситуация изменилась. Потоковая обработка событий всё чаще появляется в предложениях вендоров, архитектурных ревью и задачах найма. Если ваша команда строит что-то, что перемещает данные между системами в режиме близком к реальному времени - вы рано или поздно услышите про Kafka или её аналоги.
Это не технический туториал. Это система координат для тех, кто принимает решения и хочет задавать правильные вопросы.
Какую проблему решает потоковая обработка
Классическая интеграция данных выглядит примерно так: система A пишет в базу данных, плановое задание читает из этой базы и копирует записи в систему B, система B обрабатывает их при следующем запуске. Это работает. Но данные всегда немного устаревают, системы сильно связаны между собой, а добавление третьего потребителя требует изменений в A или B.
Потоковая обработка переворачивает эту схему. Система A публикует события - «заказ создан», «платёж подтверждён», «уровень запасов изменился» - в общий лог. Любая система, которой нужны эти события, подписывается и читает их в своём темпе. A не знает ни о B, ни о C. Лог - это и есть контракт.
Kafka - самая распространённая система для ведения такого общего лога в промышленных масштабах. Она надёжна, быстра и рассчитана на обработку миллионов событий в секунду при множестве потребителей.
Чем Kafka не является
Kafka - не база данных. Она не заменяет операционные системы или хранилище данных. Это транспорт и буфер на короткий и средний срок, но не система-источник правды.
Kafka также не является очередью сообщений в классическом смысле. Обычная очередь удаляет сообщение после того, как оно прочитано. Kafka хранит лог событий в течение настраиваемого периода - часы, дни, недели - и любой потребитель может перечитать его с любой точки. Именно это делает её полезной для восстановления производных хранилищ данных, отладки ошибок интеграции или подключения новых потребителей без изменений в производителях.
Когда сложность оправдана
Потоковая обработка событий добавляет реальную операционную сложность: управление кластером, эволюция схем, мониторинг отставания потребителей, обработка воспроизведения и гарантий порядка. Ничего из этого не бывает бесплатно. Я видел команды, которые тянулись к Kafka там, где им вполне хватило бы обычного вебхука или общей таблицы в базе данных ещё долгие годы.
Паттерн, который реально оправдывает инвестиции:
- три и более систем нуждаются в одних и тех же данных по мере их изменения;
- задержка критична - минуты слишком долго;
- потребители работают в разном темпе и не должны блокировать друг друга;
- аудиторский след и возможность воспроизведения - это бизнес-требование, а не приятный бонус.
Если из этого списка верны только два пункта - подумайте дважды. Если ни одного - не вводите эту сложность вообще.
Что спросить у команды
Когда архитектор или вендор предлагает Kafka, полезные вопросы такие:
- Сколько потребителей будет читать эти события в первый день, и сколько реалистично через год?
- Какая задержка допустима для нижестоящих систем?
- Кто отвечает за эволюцию схем при изменении событий производителями?
- Что происходит, если потребитель начинает отставать - бизнес отслеживает это отставание?
- Есть ли управляемое облачное предложение или мы берём на себя обязательство самостоятельно эксплуатировать кластер?
Последний вопрос важнее, чем принято думать. Самостоятельная эксплуатация Kafka - это серьёзная операционная ответственность. Управляемые решения - Confluent Cloud, AWS MSK, Aiven - снимают эту нагрузку за деньги. Для большинства компаний среднего размера управляемый путь является правильным.
Практический взгляд
Потоковая обработка событий - это инфраструктура, а не фича. Она меняет то, как команды интегрируются друг с другом, больше, чем то, что делает отдельный сервис. Это значит, что решение принимается на уровне архитектуры, а не в спринтовом беклоге. Если команда предлагает добавить Kafka - попросите схему: кто производит события, кто их потребляет и как устроено управление схемами. Если схема понятна - предложение серьёзное. Если размыта - команда ещё разбирается.