Оптимизация Kafka

Производительность Apache Kafka напрямую связана с оптимизацией и использованием системы. Здесь мы собрали лучшие практики для общего случая использования с большим объемом кластеризованных данных.

Помните, что эти рекомендации носят обобщенный характер, и тщательный мониторинг Kafka позволит определить, какая реализация Kafka лучше всего подходит для вашего индивидуального случая использования.

Брокер Kafka

Настройки JAVA

Используйте Java 11. По соображениям безопасности рекомендуется использовать последний патч.

Настройки JVM:

Настройки операционной системы

После определения размера JVM оставьте остальную часть оперативной памяти для кэширования страниц. Kafka нуждается в кэше страниц для записи и чтения.

Kafka работает на любой системе Unix и был протестирован на Linux и Solaris. Мы используем последнюю версию CentOS по причинам, не связанным с Kafka.

Ограничения на файловые дескрипторы: Kafka использует файловые дескрипторы для сегментов журнала и открытых соединений. В качестве отправной точки мы рекомендуем не менее 100 000 разрешенных файловых дескрипторов для процессов брокера.

Максимальный размер буфера сокета: Kafka может увеличивать размер буфера для обеспечения высокопроизводительной передачи данных между центрами обработки данных.

Диски и файловая система

Использование дисков и файловой системы - это то место, где мы видим больше всего ошибок.

Используйте только один диск или RAID-массив для каждого раздела! Если у вас несколько разделов на одном жестком диске, используйте SSD вместо HDD. Не используйте диск (диски), выделенный под раздел, совместно с другими приложениями или операционной системой, так как другие разделы или программы будут нарушать последовательное чтение/запись.

Несколько дисков можно настроить с помощью log.dirs в server.properties. Kafka распределяет разделы по кругу в каталогах log.dirs.

Создавайте оповещения на основе использования диска на каждом из выделенных для Kafka дисков.

Управление очисткой журнала

Используйте настройки очистки по умолчанию, которые полностью отключают fsync приложения.

Выбор файловой системы

Используйте XFS, она имеет наибольшую автонастройку для Kafka.

Zookeeper

• Не размещайте Zookeeper на тех же дисках, что и Kafka.
• Убедитесь, что вы выделили достаточное количество JVM. Мониторинг подскажет вам точное число, но начните с 3 ГБ.
• Используйте метрики JMX для мониторинга экземпляра Zookeeper.
• Используйте Zookeeper, поставляемый с версией Kafka, которую вы используете, а не пакет ОС.
• Используйте кластер Zookeeper только для Kafka.
• Используйте мониторинг, чтобы кластер Zookeeper был как можно меньше и проще.

Выбор топиков/партиций

Партиции определяют параллелизм потребителей. При большем количестве партиций можно добавить большее количество потребителей, что приведет к увеличению пропускной способности. Количество партиций зависит от производительности вашего потребителя и необходимой скорости потребления. Другими словами, если ваш потребитель обрабатывает 1k EPS, а вам нужно потреблять 20k EPS, используйте 20 партиций.

Большее количество партиций может увеличить сквозную задержку в Kafka, определяемую временем публикации сообщения продюсером до момента его чтения консьюмером.

Конфиги брокера Kafka

Установите JVM брокера Kafka, экспортировав KAFKA_HEAP_OPTS.

• log.retention.hours - Эта настройка контролирует, когда старые сообщения в теме будут удалены. Примите во внимание объем дискового пространства и то, как долго сообщения должны быть доступны. Обычно мы выбираем три дня или 72 часа.
• message.max.bytes - Максимальный размер сообщения, которое может получить сервер. Убедитесь, что вы установили значение replica.fetch.max.bytes равным или большим, чем message.max.bytes.
• delete.topic.enable - Позволяет пользователям удалять темы из Kafka. По умолчанию установлено значение false. Функция удаления темы будет работать только начиная с версии Kafka 0.9.
• unclean.leader.election - По умолчанию этот параметр установлен в true. Включив этот параметр, вы предпочтете доступность долговечности.

Продюсер Kafka

Критические настройки

• Batch.size - Количество событий для пакетной обработки перед отправкой в Kafka.
• Linger.ms - Время ожидания перед отправкой в Kafka.
• Compression.type - Snappy - самый высокопроизводительный тип сжатия из трех типов, поставляемых с Kafka.
• Max.in.flight.requests.per.connection - Измените это значение, если порядок получения сообщений не важен.
• Acks - Рекомендуется использовать "acks=all" для надежности.

Замечания по производительности

Поток продюсера, отправляющий данные в один раздел, работает быстрее, чем поток производителя, отправляющий данные в несколько разделов.

Отправляйте данные в пакетном режиме! Рекомендуется проводить тестирование производительности для точной настройки, но, по крайней мере, размер пакета должен составлять 1 кб.

Если пропускная способность продюсера достигает максимума, а на сервере есть свободный процессор и сетевая мощность, добавьте больше процессов продюсера.

Избегайте использования linger.ms в качестве триггера для отправки пакетных сообщений. Небольшие пакеты размером менее 1 кб уничтожат производительность. Попробуйте linger.ms=20 или максимальное значение задержки, которое вы можете выдержать.

Max.in.flight.requests.per.connection > 1 добавляет конвейеризацию и увеличивает пропускную способность; однако это может привести к неупорядоченной доставке при повторных попытках. Превышение максимального количества запросов в полете приведет к снижению пропускной способности.

Консьюмер Kafka (потребитель)

Замечания по производительности

На стороне потребителя, вы увидите наибольший прирост производительности за счет использования лучших библиотек или написания более эффективного кода.

Держите количество потребителей/потоков потребителей на уровне или ниже, чем количество партиций. Потребитель может читать из многих партиций, но одна партиция может быть прочитан только одним потребителем.