Когда дело доходит до доставки журналов в распределенных средах большого объема, многие команды DevOps используют Apache Kafka. Kafka хорошо известна своей масштабируемостью, пропускной способностью и способностью балансировать потоки сообщений между несколькими узлами и потребителями. В LogDNA у нас есть большой опыт использования Kafka для журналов, и хотя изначально это сработало для нас, мы быстро столкнулись с ограничениями производительности и масштабирования при расстановке приоритетов в оперативных данных.
Мы поняли, что для того, чтобы наша операционная группа могла продолжать эффективно масштабироваться, нам нужно будет либо найти, либо создать альтернативное решение.
Ограничения Kafka для ведения журнала
- Без очереди на отсрочку
Как платформа управления журналами, мы часто получаем внезапные всплески и всплески данных журнала, которые ставятся в очередь для обработки. Иногда в очереди появляются сообщения, содержащие неожиданные или сложные структуры данных, из-за чего потребители обрабатывают данные медленнее или даже в некоторых случаях дают сбой. В Kafka эти данные могут привести к серьезному отставанию до тех пор, пока либо потребитель не завершит обработку сообщения, либо брокер не переназначит рабочую нагрузку другому потребителю.
С самым быстрым LiveTail на рынке мы хотим отдавать приоритет живым данным по сравнению со старыми сообщениями, которые могут задерживать или блокировать поток. Чтобы решить эту проблему, мы временно храним эти сообщения в отдельной очереди, известной как очередь отложенных сообщений. Если потребителю не удается обработать сообщение или обработка сообщения занимает слишком много времени, сообщение перемещается в очередь отложенных сообщений, а потребитель переходит к следующему сообщению. Позже, когда кластер бездействует, мы возвращаемся и повторно обрабатываем события в очереди отложенного выполнения. Это позволяет нам решать проблему неверных данных без резервного копирования потока сообщений или потери данных.
2. Ограничения масштабирования потребителей
Kafka разделяет поток сообщений на несколько разделов, каждый из которых назначается определенному набору потребителей. Добавление разделов приводит к увеличению задержки, использования ресурсов и возможной недоступности. Но поскольку каждому разделу назначено фиксированное соотношение n потребителей, добавление разделов требует добавления пропорционального количества потребителей, выделенных только этому разделу.
Кроме того, определенные действия, такие как добавление потребителя или раздела, запускают переназначение (также известное как перебалансировка) разделов для каждого потребителя в группе. Это длительный и дорогостоящий процесс, особенно для больших групп потребителей, во время которого вся обработка по этой теме останавливается. Если вы масштабируетесь для удовлетворения растущего спроса, последнее, что вам нужно, - это внезапное падение пропускной способности.
Вместо того, чтобы применять политику n -consumer-per-partition, нам нужен был способ назначить любое количество потребителей любому количеству разделов, при этом гарантируя, что каждое сообщение будет прочитано только один раз. LogDNA разработала другой способ обеспечить полный порядок по темам и чтобы каждое сообщение читалось только один раз. Это позволяет нам добавлять столько брокеров, потребителей или узлов, сколько необходимо, при гораздо более эффективном масштабировании.
3. Потребители Kafka не подходят для модели контейнеризации
В LogDNA наши операции полагаются на Kubernetes для оркестровки наших сервисов. Однако запустить Kafka в Kubernetes - непросто.
Потребители Kafka отслеживают состояние и несут ответственность за отслеживание своего продвижения через раздел. Когда потребитель заканчивает обработку сообщения, он сообщает брокеру о своем текущем положении в разделе. Помимо хранения информации о положении и доступности каждого потребителя, брокер совершенно не осведомлен о состоянии или прогрессе потребителя. Kafka полагается не только на постоянных потребителей, но и на прямые маршруты между потребителями и брокерами. Кроме того, когда потребитель умирает, Kafka останавливается, чтобы перебалансировать разделы и, при необходимости, выбрать нового лидера.
Наши потребители работают на Kubernetes, что предполагает, что их можно остановить и заменить в любой момент. По умолчанию Kafka не предназначен для работы в виде контейнерной рабочей нагрузки, что может привести к проблемам с производительностью и стабильностью. Вместо того, чтобы вставлять квадратный колышек в круглое отверстие, мы воспользовались возможностью, чтобы спроектировать что-то, что подойдет нам. Вместо модели немых брокеров и умных потребителей Кафки мы выбрали противоположный подход. Потребители опрашивают сообщения, а брокер отслеживает, какие сообщения были успешно доставлены и обработаны. Это позволяет нам добавлять или удалять потребителей по запросу без необходимости координировать группы потребителей или переназначать разделы.
Заключительные примечания
В конечном итоге мы хотели поделиться своими проблемами масштабирования с использованием Kafka в качестве брокера сообщений, поскольку мы знаем, что многие из вас сталкиваются с аналогичными проблемами при масштабировании своего стека ELK. Я хотел бы услышать от вас, как вы изменили Kafka для своих нужд.
И если вам понравилась эта статья, подпишитесь на меня на medium @ muazs786
В LogDNA мы продолжаем расширять возможности управления журналами и решать проблемы масштабирования, чтобы вы могли сосредоточиться на создании отличных продуктов, подписаться на бесплатную 14-дневную пробную версию и начать потоковую передачу журналов в считанные секунды. минут
