Какие конфигурации настроить на продюсере для эффективной публикации сообщений в Apache Kafka: упаковка записей в пакеты, взаимодействие с брокерами и метрики мониторинга этих процессов.
Пакетирование сообщений при их публикации в Kafka и мониторинг этого процесса
Хотя Apache Kafka поддерживает потоковую парадигму обработки информации, она активно использует пакетные технологии. В частности, продюсер собирает сообщения в пакет перед тем, как отправить их в Kafka. Размер этого пакета определяется конфигурацией batch.size. Также можно задать задержку отправки данных с помощью параметра linger.ms. Каждое сообщение продюсер сперва добавляет в локальную очередь. Когда размер этой очереди превысит значение batch.size или истечет тайм-аута, заданный в linger.ms, пакет сообщений из локальной очереди отправляется лидеру раздела, расположенного на одном из брокеров кластера Kafka.
Помимо batch.size и linger.ms на пропускную способность потоковой системы с Kafka также влияет конфигурация buffer.memory, которая определяет размер буфера, куда собираются данные, пока продюсер упаковывает записи в пакет. По умолчанию buffer.memory равен 32 мегабайта. Очевидно, что buffer.memory должен быть больше batch.size, иначе возникнут проблемы, поскольку размер пакета будет превышать объем пространства для его временного хранения. Чтобы избежать проблем с пакетированием сообщений, нужно следить за следующими метриками:
- batch-size-avg – средний размер фактического пакета сообщений. В идеальном случае значение этой метрики будет довольно близко к size. Если batch-size-avg постоянно намного ниже установленного batch.size, задержка будет низкой, т.е. значение linger.ms может быть невысоким. Но если linger.ms высок, а пакеты достаточно малы, это искусственно тормозит потоковую передачу.
- records-per-request-avg – среднее количество записей в пакетах на запрос;
- record-size-avg – средний размер записей в пакетах. Если это значение близко или выше size, то продюсер не пакетирует сообщения, а сразу публикует их в Kafka.
- buffer-available-bytes – доступный объем памяти, который еще есть в наличии у продюсера для буферизации сообщений при формировании пакета;
- record-queue-time-avg – среднее время ожидания заполнения пакета перед фактической отправкой записей в Kafka.
Метрики взаимодействия продюсера с брокерами
Каждый продюсер поддерживает сокетные соединения с некоторым количеством брокеров Kafka и отправляет запросы с использованием двоичного протокола по TCP. Это модель «запрос-ответ»:
- продюсеры отправляют запросы брокерам для сохранения данных;
- брокеры отправляют ответ продюсерам с результатом этого запроса.
Поэтому для эффективной публикации данных в Kafka имеет смысл настроить следующие конфигурации:
- request.size – максимальный размер запроса. По умолчанию этот параметр равен около 1 мегабайта. Он напрямую ограничивает количество пакетов, которые можно отправить в запросе. У брокеров также есть ограничение на максимальный размер запроса, который он может получить после сжатия.
- acks – подтверждения успешной записи всех реплик сообщения в кластер Kafka. Данные изначально передаются лидеру раздела – ведущему брокеру, а затем копируются на другие брокеры, содержащие реплики. По сути, параметр acks отвечает на вопрос, сколько синхронизированных реплик данных нужно записать, прежде чем отправить ответ обратно продюсеру. Количество синхронизированных реплик настраивается с помощью конфигурации insync.replicas. По умолчанию она равна 1, но это значение можно увеличить для большей надежности.
- in.flight.requests.per.connection – максимальное количество запросов на соединение. По умолчанию это значение равно 5, т.к. продюсеры поддерживают соединения с таким количеством брокеров, которое необходимо, в зависимости от того, где находятся разделы топиков, куда они публикуют данные. Для каждого из этих подключений нет смысла заполнять очередь запросов на каждом брокере. Эта настройка, вместе с enable.idempotence и transactional.id, обеспечивает идемпотентности и упорядоченность данных, о чем мы писали здесь.
Когда enable.idempotence=true (по умолчанию), acks=all, повторные попытки продюсера включены и max.in.flight.requests.per.connection=5, продюсер может гарантировать, что идемпотентность сохраняется в течение всего срока действия его сеанса. Если нужна идемпотентность между сеансами производителя, нужно использовать транзакции, установив transactional.id. Затем нужно запустить и зафиксировать транзакции в клиентском коде.
Наконец, после отправки запроса брокеру начинает действовать конфигурация request.timeout.ms – максимальное время, которое продюсер будет ждать, прежде чем повторить отправку данных или выдать исключение. По умолчанию это значение установлено на 30 секунд. Сами повторные попытки можно настроить и настроить с помощью delivery.timeout.ms. Значение конфигурации delivery.timeout.ms должно быть больше, чем сумма request.timeout.ms и linger.ms, retries и retry.backoff.ms.
Для предотвращения проблем с запросами продюсера, целесообразно отслеживать следующие метрики:
- request-rate – количество запросов, выполняемых продюсером в секунду;
- requests-in-flight — метрика для каждого продюсера, которая описывает количество запросов, в настоящее время ожидающих выполнения брокерами. Мониторинг этого параметра позволяет увидеть, насколько опаздывают брокеры и делает ли продюсер заданное количество запросов. При эффективно работающих брокерах Kafka это значение должно быть низким.
- request-latency-avg – среднее время задержки ответа брокера на запрос продюсера. После отправки запросов брокеру запускается таймер, который не останавливается, пока продюсер не получит ответ.
Если продюсер сжимает сообщения, что мы разбирали здесь, пакеты сжатых записей группируются вместе по разделу топика и брокеру, для которого они предназначены. После этого эти пакеты отправляются брокеру как часть одного запроса продюсера. Хотя запрос предназначен для одного брокера в кластере, он может содержать данные для нескольких разных разделов топиков на этом брокере.
Научитесь администрированию и эксплуатации Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
