Apache Kafka можно бесплатно скачать, развернуть и подключить к приложениям. При небольшом проекте этого может быть достаточно: создали несколько топиков, настроили потребителей — и обмен сообщениями работает.
Но по мере роста инфраструктуры Kafka перестает быть просто брокером. От нее начинают зависеть функциональность микросервисов, интеграции, тестовые стенды, CI/CD-процессы и рабочие системы. Вместе с нагрузкой растет и список вопросов: как обновлять кластеры, отслеживать очереди, устранять уязвимости и восстанавливать работу после отказа.
Меня зовут Илья Виссарионов, я директор департамента «Аппаратно-системная платформа» компании «Диасофт», и в этой статье расскажу, как мы используем Kafka в DevOps-инфраструктуре «Диасофта», какие проблемы обнаружили при эксплуатации под высокой нагрузкой и почему в итоге стали рассматривать брокер сообщений не как отдельный open-source-компонент, а как полноценную инфраструктурную платформу.
Скачать Kafka проще, чем ее эксплуатировать
В базовой конфигурации Kafka решает понятную задачу: принимает сообщения от одних систем и передает их другим.
Сложности начинаются позже.
Нужно выбрать способ установки, настроить отказоустойчивость, подключить мониторинг, определить порядок обновлений и подготовить сценарии восстановления. Затем появляются требования информационной безопасности, совместимости с операционными системами и внутренними процессами сопровождения.
По сути, базовая Kafka дает технологическое ядро. Но все, что связано с промышленной эксплуатацией, компания строит вокруг него самостоятельно или поручает интегратору.
Если в компании есть сильная инфраструктурная команда, собственная система мониторинга и отлаженные процессы сопровождения open source, такая модель может работать.
Но за бесплатной лицензией все равно остаются затраты на специалистов для поддержки работоспособности, тестирования, обновления и устранения сбоев.
Именно поэтому при создании Digital Q.MessageBroker мы сосредоточились не только на Kafka как таковой. В дистрибутив вошли установщики, преднастройки и средства мониторинга. Мы также тестируем обновления, закрываем обнаруженные уязвимости и адаптируем решение под российские операционные системы, включая Astra Linux и РЕД ОС.
Как Kafka встроена в наш DevOps-процесс
Мы используем наш брокер сообщений Digital Q.MessageBroker, реализованный на базе Apache Kafka, в собственной инфраструктуре разработки как универсальный инструмент обмена между продуктами.
После коммита автоматически запускается сборка продукта. Затем она проходит через заданную цепочку тестовых стендов. Если проверки завершились успешно, продукт разворачивается в рабочей среде.
Kafka используется на разных этапах этого процесса. Через нее взаимодействуют микросервисы, отдельные стенды и рабочие среды. Некоторые среды связаны между собой через отдельные установки Kafka и механизмы репликации.
Ежедневно через инфраструктуру проходит от 2 000 до 3 000 сборок. Каждая сборка состоит из нескольких шагов и пайплайнов, между которыми идет асинхронный обмен сообщениями.
Таким образом, мы сами стали первым и, пожалуй, самым требовательным заказчиком Digital Q.MessageBroker.
Продукт работает в той же инфраструктуре, где ежедневно разрабатываются, собираются и тестируются другие решения. Это позволяет находить проблемы не только во время отдельных нагрузочных испытаний, но и в ходе постоянной эксплуатации.
Во внутренней инфраструктуре используются несколько установок брокера с десятками тысяч топиков и сотен тысяч партиций в них. Отдельный канал обмена может автоматически создаваться для конкретного действия или взаимодействия между продуктами. Через брокеры проходит миллионы сообщений в сутки.
Для большинства заказчиков такая нагрузка избыточна. Организация может создать несколько топиков вручную и годами использовать их для обмена данными. У нас количество каналов обмена значительно выше, поэтому Kafka работает в более тяжелых условиях.
Фактически внутренняя инфраструктура стала постоянным испытательным полигоном.
Что меняется при росте нагрузки
Когда говорят о Kafka, чаще всего обсуждают производительность: сколько сообщений в секунду способен обработать кластер.
На практике скорость — только одно из требований. Для бизнес-систем не менее важны гарантированная доставка, правильная последовательность сообщений, отказоустойчивость и возможность быстро обнаружить проблему.
Рассмотрим типовой сценарий.
Один из микросервисов временно перестает отвечать и больше не читает сообщения. Продюсеры продолжают публиковать данные, поэтому очередь растет.
Если сообщения связаны между собой, следующее нельзя обработать раньше предыдущего. Из-за остановки одного сервиса может замедлиться или полностью остановиться вся цепочка бизнес-операций.
При этом проблему важно обнаружить до того, как на нее пожалуется пользователь.
Мониторинг должен показать, что очередь начала расти, время обработки увеличилось, а конкретный потребитель перестал успевать за потоком.
В этот момент брокер становится частью системы управления надежностью с помощью мониторинга.
Гарантированная доставка и порядок сообщений
Для части интеграционных сценариев важно не просто доставить данные, но и не потерять их при временной недоступности системы-получателя.
Потерянное сообщение может означать пропущенную операцию, расхождение между системами или необходимость вручную восстанавливать состояние бизнес-процесса.
Не менее важен порядок сообщений.
Представим, что одна система передает другой сначала информацию о создании операции, а затем — подтверждение ее выполнения. Получатель не должен обработать подтверждение раньше самой операции.
Если первое сообщение задержалось, следующие должны дождаться его обработки. Это одна из причин, по которой состояние очередей нужно постоянно контролировать.
При этом сама Kafka не устраняет все риски автоматически. Надежность зависит не только от брокера, но и от конфигурации кластера, поведения продюсеров и потребителей, а также логики приложений.
Поэтому промышленная эксплуатация требует не одной «правильной настройки», а согласованной работы всей цепочки.
Что происходит при отказе узла
Для критичных систем Kafka обычно разворачивают в кластерной конфигурации.
Количество установок зависит от требуемой производительности и уровня отказоустойчивости. Кластер может находиться в одной серверной или быть распределен между несколькими площадками.
При отказе отдельного элемента оставшиеся узлы должны продолжить работу. Пользователь не должен потерять сообщения или заметить значительное падение производительности.
Чем выше требования к доступности, тем сложнее становится архитектура. Нужно учитывать не только отказ одного процесса, но и потерю узла, сетевого сегмента или целой площадки.
При этом увеличение числа узлов само по себе не решает задачу. Необходимы мониторинг, отработанные процедуры переключения и регулярные проверки того, что кластер действительно выдерживает предусмотренные архитектурой отказы.
Зачем нужен мониторинг вокруг Kafka
Администратору нужно видеть состояние кластеров, очередей и потребителей. Важно понимать, с какой скоростью публикуются сообщения, успевают ли потребители их обрабатывать и где возникает задержка.
Без этого формально работающий кластер может уже создавать проблемы для бизнес-систем.
Например, брокеры доступны, сообщения принимаются, но один из потребителей отстает. Очередь постепенно растет, а пользователи пока ничего не замечают. Через некоторое время задержка становится критичной и влияет на связанный процесс.
Система наблюдения должна обнаружить такое отклонение заранее. Именно поэтому инструменты мониторинга стали одной из частей промышленного дистрибутива. Их задача — не только показать, что Kafka работает, но и помочь понять, насколько стабильно работает вся цепочка обмена.
Что мы добавили вокруг базовой Kafka
Главное отличие промышленного дистрибутива Digital Q.MessageBroker от базовой Kafka — не новое ядро, а модель эксплуатации.
В случае с open source организация самостоятельно строит систему установки, мониторинга, обновлений и поддержки. Она выбирает вспомогательные инструменты, разрабатывает автоматизацию и определяет внутренние регламенты.
В готовом дистрибутиве значительная часть этих задач уже сведена в единый продукт и, при необходимости, можно получить необходимые консультации от вендора, а не от сообщества.
1. Единый способ установки и настройки
Когда каждая команда разворачивает Kafka по-своему, инфраструктура постепенно становится неоднородной.
На одном проекте используется одна версия, на другом — другая. Различаются параметры, инструменты наблюдения и процедуры обновления. В результате одинаковая проблема может решаться несколько раз разными способами.
Стандартизация позволяет использовать общие конфигурации и распространять исправления между проектами. Если проблема обнаружена в одном контуре, ее решение можно применить и в других.
2. Контролируемые обновления
При самостоятельной эксплуатации команда должна оценивать новые версии, проверять совместимость со всеми компонентами и определять, какие исправления нужно переносить в рабочую среду.
Это особенно важно для инфраструктурного компонента, от которого зависят десятки или сотни систем. Даже небольшое изменение может потребовать повторного тестирования всей цепочки интеграций.
Вендорский дистрибутив переносит часть этой работы на разработчика продукта.
3. Ответственность за сопровождение
Open-source-сообщество может помочь найти решение, но не обязано реагировать в определенный срок.
Вендор берет на себя поддержку и выпуск исправлений. Если в ходе внутренней эксплуатации или клиентского проекта обнаруживается уязвимость, ее можно закрыть настройками или переходом на исправленную версию.
Поэтому выбор между базовой Kafka и готовым дистрибутивом — это не только сравнение функций. Это выбор модели ответственности.
Почему компании не спешат менять работающий open source
Даже при наличии отечественного дистрибутива бизнес не всегда готов сразу отказаться от уже развернутой Kafka.
Причина понятна: если система работает и не требует лицензионных платежей, миграция не дает быстрой экономии.
При этом замена инфраструктурного компонента требует проверить совместимость, провести нагрузочные испытания и выполнить оценку соответствия требованиям информационной безопасности. Затем нужно адаптировать автоматизированные процедуры и передать решение внутренней службе сопровождения.
Поэтому переход на российское инфраструктурное ПО обычно связан не столько со снижением расходов, сколько с управлением рисками.
Организация должна понимать, кто подключится при критическом сбое, как быстро будет выпущено исправление и можно ли рассчитывать на поддержку продукта через несколько лет.
Если компания уже построила зрелую эксплуатационную платформу вокруг open source и готова самостоятельно отвечать за ее работу, срочная миграция может быть не нужна.
Вендорский дистрибутив становится интересен там, где важны единая поддерживаемая конфигурация, предсказуемые обновления, совместимость с российским технологическим стеком и наличие ответственного поставщика.
Безопасность передачи сообщений
Брокер связывает между собой критичные бизнес-системы, поэтому безопасность нельзя ограничивать только прикладным уровнем.
В дистрибутиве предусмотрены инструменты и преднастройки для возможности шифрования сообщений. Они защищают данные при передаче между системой-отправителем и системой-получателем.
Конкретная конфигурация зависит от архитектуры проекта, характера данных и внутренних требований организации.
При этом шифрование трафика — только часть защиты. Также важны управление доступом, обновление компонентов и своевременное устранение уязвимостей.
Вместо заключения
1. Бесплатная лицензия не означает бесплатную эксплуатацию.
Компании все равно нужны специалисты, мониторинг, процессы обновления и сценарии восстановления. Чем больше систем зависит от Kafka, тем выше стоимость ошибки в этих процессах.
2. При росте масштаба брокер превращается в инфраструктурную платформу.
От него начинают зависеть не только отдельные интеграции, но и корректное взаимодействие микросервисов, тестовые среды и DevOps-процессы.
3. Постоянная внутренняя эксплуатация полезнее единичного нагрузочного теста.
Через нашу инфраструктуру ежедневно проходит от 2 000 до 3 000 сборок. Множество стендов и большое количество топиков, используемых при этом, позволяют регулярно проверять систему в разных режимах.
4. Выбор между базовой Kafka и промышленным дистрибутивом — это выбор того, кто будет отвечать за всю систему вокруг брокера.
Можно построить ее самостоятельно: подобрать инструменты, разработать автоматизацию и сформировать команду сопровождения. Другой вариант — использовать готовую платформу, в которой установка, мониторинг, обновления и поддержка объединены в одном продукте.
Для крупной компании важно не только то, что Kafka можно скачать бесплатно. Важнее, кто обеспечит ее работу в момент, когда от доставки одного сообщения зависит непрерывность бизнес-процесса.
ссылка на оригинал статьи https://habr.com/ru/articles/1071268/