Kafka — распределенная стриминговая платформа, которая стала де-факто стандартом для обработки событий в реальном времени. Она обеспечивает надежную доставку сообщений, масштабируемость и низкую задержку. Однако чтобы кластер Kafka работал стабильно под высокой нагрузкой, мало просто «поднять брокеры» — критично правильно настроить параметры конфигурации. От них напрямую зависят пропускная способность, время отклика, устойчивость к сбоям и эффективность использования ресурсов.

На связи снова Александр Гришин, руководитель по развитию продуктов хранения данных Selectel. В этой статье я разберу доступные параметры конфигурации Kafka-кластеров в облачных базах данных: от настроек репликации и ретеншена до лимитов на продюсеров и потребителей. Мы посмотрим, как каждый параметр влияет на производительность и надежность, приведем практические рекомендации для разных сценариев — от высокочастотных событий до больших архивных потоков.

Материал будет полезен инженерам, которые проектируют архитектуру обмена данными, DevOps-специалистам, отвечающим за эксплуатацию, и разработчикам, которым важно предсказуемое поведение стриминга на продакшене. Погнали!

Основы конфигурации Kafka в DBaaS Selectel

Selectel позволяет управлять кластерами Kafka через панель управления, Terraform и API, а часть ключевых параметров можно тонко настраивать в UI. Ниже — список всех доступных параметров и пояснение, как они работают в контексте DBaaS.

Сжатие (Compression)

compression.type

Тип сжатия сообщений в Kafka. Поддерживаются следующие значения:

• none — сжатие не используется;

• gzip, snappy, lz4, zstd — разные алгоритмы сжатия;

• producer (по умолчанию) — Kafka использует значение, указанное продюсером.

Это может быть полезным при логировании приложений и телеметрии. Например, в IoT-устройствах каждый датчик может непрерывно генерировать десятки сообщений. Если таких устройств тысячи, поток данных в Kafka разрастется и по нему будут проходить сотни тысяч сообщений каждую секунду.

Когда менять?

Если у вас большие объемы сообщений и важна экономия дискового пространства и сетевого трафика, можно задать compression.type = lz4 или zstd. Это полезно при логировании, телеметрии или событиях IoT.

Надежность записи (Flush)

В Kafka лог (log) — это физическое представление сообщений (записей) внутри партиции топика. Он хранится как последовательность сегментированных файлов на диске, куда брокер последовательно добавляет новые записи. Эти логи — данные топика и сообщения пользователей, а не технические логи Kafka (broker logs). В тексте ниже мы будем говорить про «размер сегмента лога» или «удержание логов», но речь идет именно о хранении сообщений, а не о логировании работы кластера.

log.flush.interval.messages

Количество сообщений, после которого Kafka сбрасывает данные на диск. Установка больших значений снижает нагрузку на I/O, но увеличивает риск потери данных при сбое.

log.flush.interval.ms

Аналогично, но по времени: сколько миллисекунд должно пройти до сброса.

Когда менять?

Если вам нужна низкая задержка доставки и высокая гарантия записи, ставьте небольшие значения. Если важна производительность — оставьте значения по умолчанию (в DBaaS Selectel они большие, что соответствует нашей стратегии «максимальная производительность»).

Время хранения (Retention)

log.retention.bytes

Максимальный размер логов в байтах для одного топика. Если он достигнут, старые сегменты удаляются. Значение по умолчанию -1 означает, что нужно «игнорировать размер, ограничивать только временем».

log.retention.hours, log.retention.minutes, log.retention.ms

Период хранения сообщений в логах. Вы можете настроить в удобных единицах времени. Работает по принципу «приоритет выше у меньших единиц» (если задан log.retention.ms, то log.retention.hours игнорируется).

offsets.retention.minutes

Период хранения offset-ов (смещений) для consumer group после того, как потребитель перестал читать. Значение по умолчанию — семь дней (10 080 минут).

Когда менять?

Если вы разрабатываете систему с коротким временем жизни данных (например, мониторинг или потоковое видео), можно сократить хранение до часов. А вот для финансовых или пользовательских событий — лучше увеличивать период.

Сегментация и предварительное выделение

log.segment.bytes

Размер сегмента лога. Когда он превышается — Kafka начинает новый сегмент. Маленькие значения увеличивают количество файлов и нагрузку на GC, большие — повышают латентность.

log.preallocate

Если включено, Kafka сразу резервирует место под каждый новый сегмент. Это уменьшает фрагментацию, но увеличивает задержки при создании файлов.

Когда менять?

В высоконагруженных продакшен-системах лучше включать log.preallocate и использовать сегменты 512 МБ – 1 ГБ. Для тестов можно отключить.

Буферы

socket.receive.buffer.bytes и socket.send.buffer.bytes

Размер буферов для сетевых операций (приема и отправки). Влияет на пропускную способность и стабильность соединения. Значения по умолчанию — 102 400 байт (100 КБ).

Когда менять?

Если вы видите, что соединения часто обрываются при больших нагрузках, увеличьте эти буферы. Например, до 512 КБ или 1 МБ.

Размер сообщений и партиций

max.message.bytes

Максимальный размер одного сообщения. Важно, если вы передаете большие JSON, бинарные данные или медиаконтент. Значение по умолчанию — около 1 МБ.

num.partitions

Количество партиций, создаваемое по умолчанию при создании топика. Чем больше партиций, тем выше масштабируемость по потребителям, но и выше накладные расходы.

Когда менять?

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

Облачные базы данных

Создайте готовую базу данных в облаке за 5 минут. Поддерживаем PostgreSQL, MySQL, Redis и не только.

Подробнее →

Готовые шаблоны конфигураций для типовых кейсов

В реальной работе чаще всего приходится решать несколько повторяющихся задач: от дешевого долговременного хранения сообщений до низколатентного стриминга и приема телеметрии с тысяч устройств.

Чтобы не тратить часы на подбор конфигурации с нуля, мы собрали проверенные шаблоны настроек для типовых сценариев. Для каждого кейса указаны рекомендуемые параметры Kafka, объем и тип ресурсов, а также логика выбора — почему именно такая комбинация CPU, RAM и дисков даст оптимальный результат в конкретных условиях.

Кейc 1: архив логов (низкая стоимость хранения)

Цель: экономия ресурсов, долгий retention, минимум нагрузки.

• compression.type=zstd

• log.retention.hours=168  # 7 дней

• log.segment.bytes=1073741824  # 1 ГБ

• log.preallocate=true

• max.message.bytes=1048576

• num.partitions=1

Рекомендуемые ресурсы:

• CPU: 2-4 vCPU

• RAM: 4-8 ГБ

• Storage: 100-500 ГБ

• Диск: сетевой, с тройной репликацией (надежность важнее скорости)

Кейс 2: Стриминг в реальном времени с низкой задержкой

Цель: минимальная задержка, стабильность при высокой нагрузке.

• compression.type=producer

• log.retention.hours=1

• log.segment.bytes=67108864  # 64 МБ

• log.preallocate=false

• max.message.bytes=2097152  # до 2 МБ

• num.partitions=2

Рекомендуемые ресурсы:

• CPU: 4-8 vCPU

• RAM: 16-32 ГБ

• Storage: 100-500 ГБ

• Диск: локальный NVMe (максимальная пропускная способность и IOPS)

Кейс 3: Тестовое окружение

Цель: гибкость и минимум ограничений.

• compression.type=lz4

• log.retention.hours=6

• log.segment.bytes=67108864  # 64 МБ

• log.preallocate=false

• socket.send.buffer.bytes=524288

• num.partitions=6

Рекомендуемые ресурсы:

• CPU: 2 vCPU,

• RAM: 8 ГБ

• Storage: 32-100 ГБ

• Диск: сетевой с тройной репликацией (для простоты и надежности)

Кейс 4: ETL / Пайплайн обработки данных

Цель: надежная и равномерная передача больших объемов сообщений с умеренной задержкой.

• compression.type=zstd

• log.retention.hours=168  # 7 дней

• log.segment.bytes=134217728  # 128 МБ

• log.preallocate=true

• num.partitions=3

Рекомендуемые ресурсы:

• CPU: 2-4 vCPU

• RAM: 8-16 ГБ

• Storage: 50-300 ГБ

• Диск: сетевой с тройной репликацией (баланс между скоростью и надежностью)

Кейс 5: IoT / Телеметрия

Цель: прием большого количества мелких сообщений с низкой задержкой и быстрой доставкой.

• compression.type=zstd

• log.retention.hours=168  # 7 дней

• log.segment.bytes=134217728  # 128 МБ

• log.preallocate=true

• num.partitions=3

Рекомендуемые ресурсы:

• CPU: 4-8 vCPU,

• RAM: 8-16 ГБ,

• Storage: 100-1 000 ГБ,

• Диск: локальный NVMe (важна скорость и низкая задержка).

Кейс 6: Логирование / Аудит

Цель: централизованный сбор логов с гарантией доставки и возможностью анализа постфактум.

• compression.type=zstd

• log.retention.hours=168  # 7 дней

• log.segment.bytes=134217728  # 128 МБ

• log.preallocate=true

• num.partitions=3

Рекомендуемые ресурсы:

• CPU: 2 vCPU

• RAM: 4 ГБ

• Storage: 300 – 10 000 ГБ

• Диск: сетевой с тройной репликацией (важна надежность хранения).

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

Заключение

Все рассмотренные нами выше настройки для Kafka предоставляются в DBaaS от Selectel прямо из панели управления. 

Чтобы было нагляднее, я собрал все рассмотренные выше параметры Kafka в одну таблицу и категоризировал их:

Настройка Kafka — это ключевой этап для обеспечения стабильной работы и максимальной производительности стриминговых систем в DBaaS от Selectel. Правильно подобранные параметры конфигурации позволяют добиться баланса между скоростью обработки сообщений, надежностью хранения и эффективным использованием ресурсов.

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

Важно помнить, что оптимальная конфигурация всегда зависит от специфики вашей нагрузки и бизнес-целей. Поэтому не стоит ограничиваться первоначальной настройкой. По аналогии с PostgreSQL, рекомендую регулярно анализировать метрики, проводить мониторинг и при необходимости корректировать параметры. DBaaS Selectel предоставляет все необходимые инструменты для гибкой и удобной настройки, что позволяет сфокусироваться на развитии приложений, а не на рутинном администрировании.

Если вы хотите развернуть кластер в Selectel, команда поддержки всегда готова помочь. Используйте возможности нашей платформы, чтобы построить надежные и масштабируемые стриминговые решения на базе Apache Kafka.