Как ускорить работу producer’ов Kafka: параметры конфигурации производителей

Вчера мы рассказывали, от чего зависит скорость работы Apache Kafka и как можно повысить. Сегодня рассмотрим подробнее, как именно конфигурация отправителей (производителей, producers) сообщений влияет на общую производительность этой распределенной Big Data системы потоковой агрегации событий.

Что такое конфигурация производителей Apache Kafka

Напомним, общая производительность Кафка зависит от следующих факторов:

• параметры аппаратного оборудования улов кластера (hardware) – память, ЦП, жесткие диски;
• пропускная способности сети;
• количество производителей и потребителей;
• конфигурация производителей – совокупность настроек (параметров) producer’ов, которые определяют поведение отправителей сообщений.

Таким образом, настройки отправителей сообщений играют далеко не последнюю роль в общей производительности Big Data системы. Вообще официальная документация по Kafka Confluent включает около 60 параметров конфигурации производителей. Из них далеко не все напрямую влияют на скорость работы producer’ов Кафка. Например, около 10 параметров относится к информационной безопасности, в частности, говорит о настройках шифрования SSL и защищенного протокола Kerberos. Значимость каждого из параметров конфигурации производителей характеризуется свойством важности (Importance) [1].

5 основных параметров настройки producer’ов Кафка

Перечислим основные параметры конфигурации производителей, которые влияют на скорость их работы [2]:

• size – размер пакета сообщений, который отправляется от производителя к брокеру Кафка. Чем больше степень сжатия, тем выше пропускная способность. Но, как мы отметили ранее, большой размер пакета увеличивает общую задержку. В документации Kafka Confluent важность этого параметра отмечена средним уровнем (medium).
• ms – временная разница между отправкой предыдущего пакета сообщений до формирования нового. По умолчанию этот параметр равен 0. В документации Kafka Confluent важность этого параметра отмечена средним уровнем (medium).
• Compression.type — алгоритм сжатия сообщений (none, gzip, snappy, lz4 или zstd.), зависит от используемого для сжатия кодека. Например, среди наиболее часто применяемых gzip и snappy, gzip считается более эффективным, позволяя сжимать данные в 5 раз быстрее, чем snappy. Поэтому gzip приводит к меньшему использованию дискового пространства, но увеличивает нагрузку на ЦП. Кодек snappy, наоборот, обеспечивает меньшее сжатие, но и меньше использует вычислительные ресурсы [3]. В документации важность этого параметра отмечена высоким уровнем (high).
• in.flight.requests.per.connection – максимальное количество необработанных запросов, которые могут быть буферизованы на стороне производителя. Этот параметр введен, чтобы минимизировать время ожидания клиентов, позволяя им отправлять запросы, даже если некоторые из предыдущих запросов все еще обрабатываются брокером Кафка [4]. Если значение для этого параметра больше 1 и отправка не удалась, существует риск переупорядочения сообщений из-за повторных попыток. Разрешение повторных попыток без установки max.in.flight.requests.per.connection=1 потенциально изменит порядок записей. По умолчанию значение данного параметра равно 5. На практике пользователи обычно вместо этой конфигурации используют параметр delivery.timeout.ms для управления поведением повторных попыток. В документации важность этого параметра отмечена низким уровнем (low) [1].
• Acks (acknowledges) – количество подтверждений, которые producer ждет от лидера, прежде чем считать сообщение успешно записанным. Этот важный параметр контролирует долговечность отправляемых записей и надежность системы [1]. Однако, как мы отметили ранее, он влияет на сетевую загрузку и общую пропускную способность Big Data системы на базе Кафка. Напомним, параметр acks может принимать значения -1, 0 и 1. В чем разница между ними, мы подробно рассказывали здесь, когда разбирали семантику доставки сообщений exactly once в Apache Kafka.

Справедливости ради стоит отметить, что официальная документация Kafka Confluent также содержит подробное описание всех параметров конфигурации и других компонентов Big Data системы на базе Кафка: брокеров, потребителей, службы Zookeeper, сервера KSQL, потоков данных и т.д. [5]. Оптимизируя отдельные свойства этих компонентов, можно еще незначительно улучшить общую производительность Big Data проекта на основе Apache Kafka. О том, как связаны между собой основные конфигурации продюсеров Kafka и что нужно сделать, чтобы повысить их устойчивость, читайте здесь. А про другие полезные параметры конфигурации мы также рассказываем в этом материале.

В следующей статье мы расскажем, как Кафка используется в промышленном производстве на примере цифровизации отечественного завода ПАО «Северсталь». А как настроить кластер Apache Kafka и повысить реальную эффективность своих распределенных приложений потоковой обработки событий вы узнаете, пройдя обучение Кафка на специализированных практических курсах в «Школе Больших Данных» — лицензированном учебном центре для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

• Apache Kafka для разработчиков
• Администрирование кластера Kafka
• Администрирование Arenadata Streaming Kafka

1. https://docs.confluent.io/current/installation/configuration/producer-configs.html
2. https://habr.com/ru/company/tinkoff/blog/342892/
3. https://docs.microsoft.com/ru-ru/azure/hdinsight/kafka/apache-kafka-performance-tuning
4. https://www.waitingforcode.com/apache-kafka/apache-kafka-max-in-flight-requests-per-connection/read
5. https://docs.confluent.io/current/installation/configuration/index.html