Опыт работы с Apache Kafka: интервью с inDriver
DevOps-инженеры компании inDriver Радик Сейфуллин и Александр Плотников распилили старое монолитное приложение и создают новое, в котором понадобилось знание Kafka. Евгений Бутырин, технический редактор Слёрма, пообщался с ребятами об опыте с Kafka, проблемах, решениях и обучении.
О компании
inDriver — международный сервис пассажирских, грузовых и междугородних перевозок, услуг по курьерской доставке, решению бытовых и бизнес-задач. Ключевое отличие от других компаний — peer-to-peer модель. Цены на поездки и другие услуги устанавливаются в ходе экспресс-торгов между заказчиком и исполнителем. Не используются непрозрачные, закрытые алгоритмы, подверженные ценовым манипуляциям.
Какие задачи решает команда и зачем им Kafka
Мы разрабатываем проект новой микросервисной платформы, в которой учли недостатки текущей инфраструктуры. Поэтому девопсы разделились на две команды: те, кто поддерживает текущую сервисную платформу и те, кто разрабатывает новую.
Kafka мы начали использовать с середины прошлого года. Сейчас делаем это все активнее. Через нее обрабатываем задачи обмена сообщениями, пересылки данных, миграций данных, стриминга.
У нас две среды: тест и прод. Kafka позволяет сделать в обеих одинаковую конфигурацию: чтобы для разработчиков все было прозрачно. Ещё мы прикрутили авторизацию по SSL-сертификатам в связке с Key Secrets store Vault. Мы по API выдергиваем его и выпускаем сертификат для новых клиентов Kafka. Получается автоматизация + безопасность.
Сейчас мы не супер активно используем Kafka, у нас на проекте несколько тысяч RPS, с переходом на новую платформу мы предполагаем, что этот показатель вырастет в 10-20 раз. Планируем рост в связи с тем, что компания пересматривает подход к написанию ПО. С переходом на микросервисную архитектуру все больше и больше функций будет вытаскиваться в микросервисы, между которыми мы как раз будем использовать Kafka. По мере роста и новых сервисов будет расти нагрузка.
К чему быть готовым, когда работаешь с Kafka
Следить за сертификатами и скейлить. Вот за сертификатами мы пока не следим, тестово выпускаем на год сертификат для клиента. Пока год не прошел, мы к этому вопросу не возвращаемся, но в голове держим, что нужно мониторить сертификаты и вовремя их обновлять.
Скейлить надо заранее, готовясь к росту нагрузки. Консьюмеры при увеличении потока могут не справиться: допустим, в обычном состоянии два консьюмера, а прилетит миллион сообщений. Конечно они не справятся, поэтому мы хотим сделать HPA по Consumer Lag. Если Consumer Lag увеличивается, он увеличивает НРА и количество pods и тем самым консюмер-клиенты будут автоматически скейлиться до определенного состояния.
Проблемы с Kafka
Самая большая проблема с Kafka на проекте — понять, как автоматизировать выдачу прав на топик, ведь Kafka защищена ssl-сертификатом. Решили это с помощью скриптов: у нас автоматически дергается API сервиса, который парсит конфиг приложения, создает по нему топики и вывешивает права.
Еще одна проблема — вылетают брокеры по Heap Out of Space. Решение нигде не описано, пришлось разбираться своими силами, пробуя разные настройки и проверяя гипотезы. Оказалось, эта проблема связана с некорректно созданным топиком. Когда происходит запись новых файлов, на нулевой партиции происходит out of space. Ситуация довольно странно, но удалось решить ее с помощью нового топика, на который направили потоки.
Часто бывают проблемы, связанные с инструментами. Допустим, мы используем Debezium-коннекторы, чтобы перекачивать данные из одной базы в другую через Kafka. Эти коннекторы легко ломаются и сложно восстанавливаются. Вот допустим, у меня сломалась реплика, нужно на другую перенастроить. Это вызывает ряд сложностей, потому что они не очень user friendly, требуют много мелких настроек. Это, скорее, рутина.
В остальном мы очень довольны Kafka, прекрасно работает, и думаем, что у этого решения большое будущее.
Обновления Kafka
Apache Kafka теперь доступна без ZooKeeper
В релизе Apache Kafka 2.8 ZooKeper заменили на сервис кворума. Подробнее об этом можно почитать в нашем блоге в статье про Kafka без Zookeper.
Отказ от ZooKeeper круто. Не потому что это не подходящий инструмент, просто хотим подождать, когда он будет более зрелым решением, когда шишки будут набиты, баги выявлены и пофиксены. Мы, конечно, перейдем на него, не хотим, чтобы у нас оставалась старая версия Kafka, но переходить будем, когда уже разовьется версия.
В версси 2.8 можно определять топики по айдишникам, но мы пока не пользуемся — нам достаточно освоить тех функций, которые сейчас есть.
Как учились Kafka
Пошли вдвоем на курс «Слёрма», чтобы если кто-то один уйдет, экспертиза Kafka в компании не закончилась.
Мы сейчас должны понимать спектр возможностей, которые предоставляет нам Kafka. Лучше понимать и настраивать его, чтобы он помогал растущему бизнесу. В «Слёрм» пошли, потому что уже проходили курс по Kubernetes там и он понравился, появилось внутренняя расположенность к «Слёрму». Да и репутация у него хорошая.
Выбрали проходить курс, а не просто смотреть ютуб и читать материалы, потому что подача материала в курсе грамотная. Если просто послушать теорию, почитать статью, без практики знания улетучатся и ценности будет мало. Сначала — видеоуроки, где подробно рассказывают основы и практическое применение особенностей Kafka. Потом закрепляют знания тестами. Самое важное, что выделяют виртуальные стенды, на которых можно это сделать on hands.
Было очень полезно увидеть на курсе подробно, как внутренне устроена Kafka. Какие там происходят процессы. Узнать на будущее концепты построения геораспределенных систем.
У создателей курса можно узнать неочевидные для тех, у кого мало опыта, вещи. Они понимают, какие метрики имеет смысл брать в мониторинг, без опыта это сложно увидеть.
Курс прекрасно подойдет для тех, кто начинает только с Kafka работать. Kafka – это полезно, Kafka – это используется во многих компаниях, и будет в еще больших количествах использоваться. За неделю курса ученик может довольно уверенно рассказывать про Kafka на собеседованиях.
Итоговый проект на курсе дает понимание, в каком направлении двигаться, чтобы предлагать рабочие решения в работе Kafka. Хороший опыт для новичка — развернуть свой кластер.
18 октября стартует группа по Apache Kafka от Слёрма. Уже к 22 ноября можно научиться работать с Kafka и защитить итоговую работу.
Узнать больше и записаться на курс: https://slurm.club/3tN6wOb
Планы на будущее
Идеальное будущее — несколько геораспределенных кластеров, которые будут зеркалиться. Мы — международная компания, без распределенных кластеров нам быть неправильно.
У нас есть монолит и мы взаимодействуем с Kafka, но это не то, как бы хотелось строить работу. И вот мы будем это приводить к лучшему виду, исправлять недочеты и делать больше нагрузку на нее.
What does consumer LAG mean in Consumer Group
I’m observing that Kafka Consumer is inconsistently not able to receive the messages when Producer trying to send it. When i checked kafka consumer , there are LAG values seen :
docker run --net=host --rm kafka-consumer-groups --zookeeper localhost:2181 --describe --group mgmt_testing GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG OWNER mgmt_testing mgmt_testing 0 44 44 0 mgmt_testing_aws-us-east-1-mr3-10-10-8-218-1561090200381-21858516-0 mgmt_testing mgmt_testing 1 35 35 0 mgmt_testing_aws-us-east-1-mr3-10-10-8-218-1561090200381-21858516-0 mgmt_testing mgmt_testing 2 39 39 0 mgmt_testing_aws-us-east-1-mr3-10-10-8-218-1561090200381-21858516-0 mgmt_testing mgmt_testing 3 37 37 0 mgmt_testing_aws-us-east-1-mr3-10-10-8-218-1561090200381-21858516-0 mgmt_testing mgmt_testing 4 25 38 13 mgmt_testing_aws-us-east-1-mr3-10-10-8-218-1561090200381-21858516-0 mgmt_testing mgmt_testing 5 458 666 208 mgmt_testing_aws-us-east-1-mr3-10-10-8-218-1561090200381-21858516-0 mgmt_testing mgmt_testing 6 808167 808181 14 mgmt_testing_aws-us-east-1-mr3-10-10-8-218-1561090200381-21858516-0 mgmt_testing mgmt_testing 7 434028 434041 13 mgmt_testing_aws-us-east-1-mr3-10-10-8-218-1561090200381-21858516-0
What does LAG mean here ? And will this be the reason that consumer is not able to receive the messages?
- apache-kafka
- kafka-consumer-api
Understanding the Lag in Your Kafka Cluster
At Acceldata we spend a lot of time working with enterprises to optimize high throughput, low latency data streaming applications using Apache Kafka.
Some of our customers include ad networks with over 100 billion events a day on their Kafka infrastructure. Amongst various metrics that Kafka monitoring includes consumer lag is nearly the most important of them all.
In this blog we will explore potential reasons for Kafka consumer lag and what you could do when you experience lag.
Kafka – Past and Present
Apache Kafka is no longer used just by the Internet hyperscalers. Apache Kafka is used in the enterprise to deal with exploding streaming data. It powers compelling consumer experiences such as real-time personalization, recommendation and next best action.
Kafka allows low latency ingestion of large amounts of data into data lakes or data warehouses. Kafka allows businesses to get real-time intelligence into their business operations that allows them to react in real -time to changing business conditions.
Mission critical business processes are plagued by consumer lags, and experienced practitioners agree that preventing consumer lag is the biggest challenge in Kafka.
How does Kafka Work?
Kafka is a distributed, partitioned, replicated commit log service. Kafka is run as a cluster of multiple servers or containers.The cluster stores streams of records in categories called topics with each record consisting of a key, value and a timestamp.
Kafka Producers are processes that publish data into Kafka topics, while Consumers are processes that read messages off a Kafka topic.Topics are divided into partitions which contain messages in an append-only sequence. Each message in a partition is assigned and identified by its unique offset.
Partitions can hold multiple partition logs allowing consumers to read from in parallel.These partitions are replicated across multiple Kafka clusters for resilience. A variety of applications could produce data and send them towards the Kafka broker.
Consumers are applications that read messages from such Kafka brokers. Consumers read messages from a specific offset and are allowed to read from any offset point they choose. Consumer groups include a set of consumer processes subscribing to a given topic.Each consumer group is assigned a set of partitions to consume from.
They will receive messages from a different subset of the partitions in the topic. Kafka guarantees that the message is only read by a single consumer in the group. This philosophy is called exactly once delivery.
What is Kafka Consumer Lag?
Consumer lag indicates the lag between Kafka producers and consumers. If the rate of production of data far exceeds the rate at which it is getting consumed, consumer groups will exhibit lag.
It can be understood very succinctly as the gap between the difference between the latest offset and consumer offset. In general, enterprises talk about Kafka but they are referring to the physical Kafka brokers — a server either physical or container that runs Kafka. Brokers are the physical repositories of logs that store and serve Kafka messages.
Data storage inside a Kafka broker is done through topics. Topics are divided into partitions and brokers write data into specific partitions. As the broker writes data — it keeps track of the last offset and records it as the log end offset.
Kafka Consumers
Consumers on the other end may have complex application logic embedded inside the consumer processes. If there are way too many producers writing data to the same topic when there are a limited number of consumers then then the reading processes will always be slow. The real time objectives are lost.
So just like multiple producers which can write to the same topic, multiple consumers can read from the same topic, by getting data from one of the partitions inside the topic. It is common for consumer groups to have equal numbers of consumers as partitions, since they are doing low-latency operations. Good design includes the creation of a large number of partitions and is a fundamental way of scaling.
Just like Brokers keep track of their write position in each Partition, each Consumer keeps track of “read position” in each partition whose data it is consuming. It is the only way to keep track of the data that it has read, this is periodically persisted to Zookeeper or a Kafka Topic itself.
It’s possible that some consumer groups exhibit more lag than others, because they may have more complex logic. It can also occur because of stuck consumers, slow message processing, incrementally more messages produced than consumed.
Rebalance events can also be unpleasant contributors to consumer lag. In real time conditions, new addition of new consumers to the consumer group causes partition ownership to change — this is helpful if it’s done to increase parallelism.
However, such changes are undesirable when triggered due to a consumer process crashing down. During this event, consumers can’t consume messages, and hence consumer lag occurs. Also, when partitions are moved from one consumer to another, the consumer loses its current state including caches.
Monitoring Tools
There are several Kafka monitoring tools both in the open-source community and commercially. We’ve provided end-to-end visibility into Kafka and allow enterprises to scale technology adoption without worrying about operational blindness.
Что такое потребительские группы в Kafka и для чего они нужны
В прошлый раз мы говорили об основах работы с Kafka-топиками, включая основные операции с ними. Сегодня поговорим про потребительские Kafka, благодаря которым брокер Kafka имеет возможность повышения эффективности распределенной работы при обработке массивов Big Data.
Как работают потребительские группы в Apache Kafka: основы параллельного обращения к топикам
Потребительская группа — это объединение потребителей для многопоточного (многопользовательского) использования топиков Kafka. Потребительские группы в Kafka имеют следующие особенности [1]:
- id — номер группы, который присваивается ей при создании для возможности подключения потребителей, использующих в качестве параметра соединения этот идентификатор (id). Следовательно, для параллельного использования группы, потребители используют один и тот же group.id;
- брокер Kafka назначает разделы топика потребителю в группе таким образом, что каждый раздел потребляется ровно одним потребителем в группе;
- потребители видят сообщение в том порядке, в котором они были сохранены в журнале, независимо от того, в какой момент времени они подключились к группе;
- максимальный параллелизм группы достигается лишь тогда, когда в топике нет разделов.
Особенности работы с потребительскими группами в Kafka: несколько практических примеров
Для работы с потребительскими группами в Kafka используется утилита kafka-consumer-groups.sh. Для того, чтобы вывести список созданных групп, используется параметр —list . Следующая команда отвечает за вывод списка всех групп на сервере [1]:
kafka-consumer-groups.sh --zookeeper zoo1.example.com:2181/kafka-cluster --list
Для того, чтобы добавить описания групп, необходимо заменить параметр —list на —describe и добавить параметр —group , который отвечает за действия над указанной группой [1]:
kafka-consumer-groups.sh --zookeeper zoo1.example.com:2181/kafka-cluster --describe --group testgroup
В описании выводится таблица, которая содержит следующие элементы группы:
- GROUP — название группы потребителей;
- TOPIC — название читаемого топика;
- PARTITITON — идентификатор читаемого раздела;
- CURRENT-OFFSET — последнее смещение, зафиксированное группой потребителей для данного раздела топика. Представляет собой позицию, которую занимает потребитель в разделе;
- LONG-END-OFFSET — текущее максимальное смещение для данного раздела топика из имеющихся в брокере;
- LAG — разница между CURRENT-OFFSET потребителя и LONG-END-OFFSET брокера для данного раздела топика;
- OWNER — член группы потребителей, который в настоящий момент выполняет потребление данного раздела топика. Представляет собой произвольный идентификатор, задаваемый самим членом группы [1].
Для удаления группы используется команда —delete совместно с командой —group, которая в качестве параметра принимает название удаляемой группы:
kafka-consumer-groups.sh --zookeeper zoo1.example.com:2181/kafka-cluster --delete --group testgroup
Таким образом, благодаря поддержке механизма потребительских групп, Kafka имеет возможность повышения эффективности параллельной работы с массивами Big Data. Это делает Apache Kafka универсальным и надежным средством для хранения и обмена большими потоками данных, что позволяет активно использовать этот брокер сообщений в задачах Data Science и разработке распределенных приложений.