Лучшие практики конфигурации Kafka для производственных сред

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

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

Понимание ключевых компонентов Kafka и их конфигурации

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

Брокеры: Серверы Kafka, которые хранят данные и обслуживают запросы клиентов. Конфигурация брокера определяет производительность, использование ресурсов и отказоустойчивость.
Топики: Категории или каналы сообщений, которые публикуются.
Разделы: Топики делятся на один или несколько разделов, что обеспечивает параллелизм в обработке и хранении.
Репликация: Процесс копирования разделов между несколькими брокерами для обеспечения долговечности и доступности данных в случае сбоя брокера.
Группы потребителей: Группа потребителей, которые совместно потребляют сообщения из топика. Kafka гарантирует, что каждое сообщение в топике доставляется не более чем одному потребителю в каждой группе потребителей.

Стратегии топиков и разделов

Эффективная конфигурация топиков и разделов является основой масштабируемости и производительности Kafka.

Количество разделов

Выбор правильного количества разделов является критическим решением. Больше разделов обеспечивает более высокий параллелизм на стороне потребителя, то есть больше экземпляров потребителей могут обрабатывать данные одновременно. Однако слишком много разделов может нагрузить ресурсы брокера (память, дисковый ввод-вывод) и увеличить задержку. Распространенное эмпирическое правило — начинать с количества разделов, которое отражает ожидаемую пиковую пропускную способность потребителя, учитывая, что при необходимости вы можете добавить больше разделов позже.

Соображение: Максимальное количество разделов, которое может обработать брокер, ограничено его памятью. Каждый раздел требует памяти для своих реплик-лидеров и последователей.
Рекомендация: Стремитесь к количеству разделов, которое соответствует вашим потребностям в параллелизме потребителей, но избегайте чрезмерного разделения. Отслеживайте использование ресурсов брокера, чтобы найти оптимальный баланс.

Ключ раздела

При создании сообщений ключ раздела (часто ключ записи) определяет, в какой раздел будет записано сообщение. Согласованное разделение необходимо для упорядоченной обработки в группе потребителей.

partitioner.class: Эта конфигурация продюсера может быть установлена на org.apache.kafka.clients.producer.internals.DefaultPartitioner (по умолчанию, использует хеш ключа) или пользовательский разделитель.
Лучшая практика: Используйте ключ, который равномерно распределяет сообщения по разделам. Если сообщения с одним и тем же ключом должны обрабатываться по порядку, Kafka гарантирует порядок только в пределах раздела.

Репликация и отказоустойчивость

Репликация является основным механизмом Kafka для обеспечения долговечности и доступности данных.

Фактор репликации

Фактор репликации определяет, сколько копий каждого раздела поддерживается в кластере. Для производственных сред настоятельно рекомендуется минимальный коэффициент репликации 3.

Преимущество: С коэффициентом репликации 3 Kafka обычно может выдержать сбой одного брокера, сохраняя при этом другую реплику доступной. Точная доступность зависит от min.insync.replicas, acks продюсера, настроек выбора лидера и того, какие брокеры вышли из строя.
Конфигурация: Это устанавливается на уровне топика, либо во время создания топика, либо с помощью команд kafka-topics.sh.

# Пример: Создание топика с коэффициентом репликации 3
kafka-topics.sh --create --topic my-production-topic --bootstrap-server kafka-broker-1:9092 --replication-factor 3 --partitions 6

`min.insync.replicas`

Этот параметр конфигурации брокера определяет минимальное количество реплик, которые должны подтвердить операцию записи, прежде чем она будет считаться успешной. Для топиков с коэффициентом репликации N установка min.insync.replicas=M (где M < N) гарантирует, что запись будет подтверждена только после того, как M реплик подтвердят ее. Чтобы предотвратить потерю данных, min.insync.replicas обычно следует устанавливать на N-1 или N/2 + 1 в зависимости от ваших компромиссов между доступностью и долговечностью.

Рекомендация: Для критических топиков установите min.insync.replicas на replication_factor - 1. Это гарантирует, что по крайней мере две реплики (в конфигурации с 3 репликами) имеют данные перед подтверждением записи, предотвращая потерю в случае сбоя лидера.
Конфигурация: Это конфигурация уровня брокера, и ее также можно установить для каждого топика.

# broker.properties
min.insync.replicas=2

# Конфигурация уровня топика (переопределяет настройку брокера)
# kafka-configs.sh --alter --topic my-critical-topic --bootstrap-server ... --add-config min.insync.replicas=2

Выбор лидера и контроллер

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

controller.quorum.voters: В кластерах на основе KRaft это указывает участников кворума контроллера. Кластеры на основе ZooKeeper используют другую настройку плоскости управления, поэтому не копируйте эту настройку вслепую между архитектурами.
num.io.threads и num.network.threads: Эти настройки брокера контролируют количество потоков, выделенных для обработки запросов ввода-вывода и сети. Настройте в зависимости от рабочей нагрузки и доступного процессора.

Конфигурации продюсера и потребителя

Оптимизация настроек продюсера и потребителя является ключом к достижению высокой пропускной способности и низкой задержки.

Конфигурации продюсера

acks: Управляет количеством подтверждений, требуемых от реплик. Установка acks=all (или -1) обеспечивает самую сильную гарантию долговечности. В сочетании с min.insync.replicas это имеет решающее значение для производства.
retries: Установите высокое значение (например, Integer.MAX_VALUE), чтобы гарантировать, что временные сбои не приведут к потере сообщений. Эффективно используйте max.in.flight.requests.per.connection с повторными попытками.
max.in.flight.requests.per.connection: Управляет максимальным количеством неподтвержденных запросов, которые могут быть отправлены брокеру. Старые клиенты часто использовали 1, чтобы избежать переупорядочивания при повторных попытках. Современные идемпотентные продюсеры могут сохранять порядок с более высокими безопасными пределами, но проверьте версию вашего клиента и настройки.
batch.size и linger.ms: Эти настройки управляют пакетированием сообщений. Большие пакеты могут повысить пропускную способность, но увеличивают задержку. linger.ms добавляет небольшую задержку, чтобы позволить объединить больше сообщений в один пакет.

# producer.properties
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
batch.size=16384
linger.ms=5

Конфигурации потребителя

auto.offset.reset: Для производства часто предпочитают latest, чтобы избежать повторной обработки старых сообщений при перезапуске. earliest можно использовать, если вам нужно повторно обработать сообщения с самого начала.
enable.auto.commit: Установите false для надежной обработки. Ручные фиксации дают вам контроль над тем, когда фиксируются смещения, предотвращая повторную доставку или потерю сообщений. Используйте commitSync() или commitAsync() для явных фиксаций.
max.poll.records: Управляет максимальным количеством записей, возвращаемых в одном вызове poll(). Настройте для управления нагрузкой обработки и предотвращения ребалансировки потребителей.
isolation.level: Установите read_committed при использовании транзакций Kafka, чтобы гарантировать, что потребители читают только зафиксированные сообщения.

# consumer.properties
group.id=my-consumer-group
auto.offset.reset=latest
enable.auto.commit=false
isolation.level=read_committed
max.poll.records=500

Соображения безопасности

Обеспечение безопасности вашего кластера Kafka не подлежит обсуждению в производственных средах.

Аутентификация и авторизация

SSL/TLS: Шифрование связи между клиентами и брокерами, а также между самими брокерами. Это требует генерации и распространения сертификатов.
SASL (Simple Authentication and Security Layer): Используйте механизмы SASL, такие как GSSAPI (Kerberos), PLAIN или SCRAM, для аутентификации клиентов.
Авторизация (ACL): Настройте списки управления доступом (ACL), чтобы определить, какие пользователи или субъекты могут выполнять определенные операции (чтение, запись, создание топика и т.д.) над какими ресурсами (топики, группы потребителей).

Шифрование

ssl.enabled.protocols: Убедитесь, что вы используете безопасные протоколы, такие как TLSv1.2 или TLSv1.3.
ssl.cipher.suites: Настройте надежные наборы шифров.

Пример конфигурации (Продюсер с SASL через TLS)

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="myuser" password="mypassword";
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=password

Настройка производительности и мониторинг

Непрерывный мониторинг и настройка необходимы для поддержания оптимальной производительности.

Настройка брокера

num.partitions: Хотя это настройка уровня топика, брокер должен обрабатывать общее количество разделов. Отслеживайте загрузку процессора, памяти и дисковый ввод-вывод.
log.segment.bytes и log.roll.hours: Управляют размером и частотой смены сегментов журнала. Меньшие сегменты могут привести к большему количеству открытых файловых дескрипторов и увеличению накладных расходов. Более крупные сегменты могут потреблять больше дискового пространства на сегмент, но снижают накладные расходы.
message.max.bytes: Максимальный размер сообщения в байтах. Убедитесь, что он достаточно велик для вашего случая использования, но не чрезмерно.
replica.fetch.max.bytes: Управляет максимальным количеством байтов на один запрос выборки репликой-последователем. Настройте для баланса эффективности выборки и использования памяти.

Настройка JVM

Размер кучи: Выделите достаточный объем памяти кучи для JVM, на которой работает Kafka. Отслеживайте использование кучи и активность сборщика мусора.
Сборщик мусора: Выберите подходящий алгоритм сборки мусора (например, G1GC часто рекомендуется для Kafka).

Мониторинг

Внедрите комплексный мониторинг с помощью таких инструментов, как Prometheus/Grafana, Datadog или специализированных решений для мониторинга Kafka.

Ключевые метрики: Отслеживайте работоспособность брокера, пропускную способность топиков, отставание потребителей, статус репликации, задержку запросов и использование ресурсов (ЦП, память, диск, сеть).
Оповещения: Настройте оповещения о критических состояниях, таких как большое отставание потребителей, отсутствие ответа от брокера или исчерпание дискового пространства.

Ребалансировка групп потребителей

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

session.timeout.ms: Как долго брокер ждет, пока потребитель отправит heartbeat, прежде чем считать его мертвым. Более низкие значения означают более быстрое обнаружение, но могут привести к преждевременной ребалансировке из-за сетевых сбоев.
heartbeat.interval.ms: Как часто потребители отправляют heartbeats. Должно быть значительно меньше, чем session.timeout.ms.
max.poll.interval.ms: Максимальное время между вызовами poll от потребителя. Если потребитель тратит больше времени на обработку сообщений и повторный вызов poll, он будет считаться мертвым, что вызовет ребалансировку. Убедитесь, что ваши потребители могут обрабатывать сообщения в течение этого интервала.
Совет: Оптимизируйте логику обработки потребителя, чтобы завершить работу в течение max.poll.interval.ms и избежать ненужной ребалансировки из-за медленных потребителей.

Производственные значения по умолчанию, которые я бы решил явно

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

Для критических потоков событий используйте коэффициент репликации 3 или более, если в кластере достаточно брокеров и стоек для его поддержки. Сочетайте это с acks=all у продюсеров и min.insync.replicas=2 для топика с тремя репликами. Эта комбинация означает, что запись подтверждается только тогда, когда лидер и по крайней мере один синхронизированный последователь имеют ее. Если слишком много реплик выходят из синхронизации, продюсеры получают ошибки вместо того, чтобы молча принимать более слабую долговечность.

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

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

Количество разделов: выбирайте для пропускной способности и операций

Количество разделов контролирует параллелизм, но большее количество разделов не бесплатно. Каждый раздел добавляет метаданные, файловые дескрипторы, работу по репликации, работу по выбору лидера и накладные расходы на восстановление. Это также влияет на поведение группы потребителей. Топик с 200 разделами может поддерживать больший параллелизм потребителей, чем топик с 12, но он также создает больше движущихся частей во время перезапусков брокеров и ребалансировок.

Начните с оценки параллелизма потребителей и пропускной способности. Если потребляющий сервис будет работать максимум с 12 экземплярами, 48 разделов может быть достаточно. Если вы ожидаете сотни независимых потоков обработки, вам может понадобиться больше. Оставьте место для роста, потому что увеличение количества разделов позже может изменить распределение ключей и поведение упорядочивания для сообщений с ключами.

Упорядочивание гарантируется только в пределах раздела. Если все события для customer_id=123 должны обрабатываться по порядку, используйте стабильный ключ на основе этого идентификатора клиента. Не ожидайте упорядочивания по всему топику. Также следите за горячими ключами. Если один клиент, арендатор или устройство создает большую долю трафика, разделение на основе ключа может перегрузить один раздел, в то время как другие будут простаивать.

Для мультитенантных систем рассмотрите, что проще в эксплуатации: один общий топик или много топиков для арендаторов. Множество крошечных топиков могут создать накладные расходы на метаданные. Один огромный общий топик может усложнить хранение, контроль доступа и реагирование на инциденты. Лучший выбор зависит от требований к изоляции и характера трафика.

Хранение — это продуктовое решение, а не просто настройка брокера

Хранение в Kafka определяет, как долго данные остаются доступными для повторного воспроизведения. Короткое хранение экономит диск, но ограничивает восстановление. Длительное хранение обеспечивает обратную засыпку и аудит, но увеличивает стоимость хранения и время восстановления.

Устанавливайте хранение для каждого топика в зависимости от того, как используются данные. Командный топик может нуждаться только в коротком окне. Топик истории событий может нуждаться в днях или неделях. Уплотненный топик, представляющий последнее состояние, использует другую модель: Kafka сохраняет самое последнее значение для каждого ключа после уплотнения, плюс tombstone для удалений до очистки.

Общие настройки включают:

retention.ms=604800000
retention.bytes=-1
cleanup.policy=delete

Для уплотненных топиков:

cleanup.policy=compact
min.cleanable.dirty.ratio=0.5
delete.retention.ms=86400000

Будьте осторожны с большими сообщениями. Kafka может обрабатывать большие записи при последовательной настройке, но увеличение message.max.bytes означает проверку max.request.size продюсера, fetch.max.bytes потребителя, настроек выборки реплик брокера и влияния на память. Во многих системах хранение больших полезных нагрузок в объектном хранилище и отправка ссылки через Kafka проще и надежнее.

Настройки продюсера, которые избавляют от боли

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

Пример базовой конфигурации продюсера:

acks=all
enable.idempotence=true
retries=2147483647
delivery.timeout.ms=120000
request.timeout.ms=30000
linger.ms=5
batch.size=32768
compression.type=zstd

Выбор сжатия зависит от бюджета процессора и версии Kafka. zstd часто обеспечивает сильное сжатие, в то время как lz4 и snappy являются распространенными вариантами с низкой задержкой. Тестируйте с вашими полезными нагрузками. JSON-логи, записи Avro, сообщения protobuf и уже сжатые двоичные данные ведут себя по-разному.

Пакетирование — это еще один компромисс. Небольшой linger.ms дает продюсеру короткое окно для группировки записей, что может улучшить пропускную способность и сжатие. Установка слишком высокого значения добавляет задержку. Для пользовательских путей запросов учитывайте бюджеты задержки. Для фоновой загрузки может быть приемлемо немного больше времени ожидания.

Не игнорируйте ошибки продюсера. Если acks=all и min.insync.replicas отклоняют запись во время проблем с брокером, это полезное противодавление. Приложение должно решить, повторить попытку, буферизовать, отклонить запрос или направить его в запасной вариант. Регистрация ошибки и отбрасывание события — это не стратегия долговечности.

Настройки потребителя, соответствующие семантике обработки

Фиксации смещений потребителя определяют, что означает "обработано". При enable.auto.commit=true клиент может фиксировать смещения до того, как ваше приложение безопасно завершит работу. Это может быть приемлемо для одноразовой аналитики, но рискованно для платежей, заказов, развертываний или всего, где пропуск события наносит ущерб.

Для надежной обработки отключите автоматическую фиксацию и фиксируйте после завершения работы:

enable.auto.commit=false
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=15000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

Стратегия фиксации зависит от приложения. commitSync() проще и дает четкое поведение при сбое, но может добавить задержку. commitAsync() может повысить пропускную способность, но вам нужно тщательно обрабатывать ошибки обратного вызова. Многие сервисы периодически фиксируют после успешных пакетов и делают нижестоящие записи идемпотентными, чтобы повторное воспроизведение было безопасным.

Если обработка одного сообщения может занять много времени, уменьшите max.poll.records, увеличьте max.poll.interval.ms или переместите медленную работу во внутреннюю очередь, пока цикл poll продолжается ответственно. Потребитель, который перестает опрашивать слишком долго, вызывает ребалансировку, а повторяющиеся ребалансировки делают всю группу нестабильной.

Используйте статическое членство для потребителей, которые часто перезапускаются, но возвращаются со стабильными идентификаторами. Это может уменьшить ненужную ребалансировку во время поэтапных развертываний. Кооперативная ребалансировка также может уменьшить сбои по сравнению с нетерпеливой ребалансировкой, в зависимости от поддержки клиента.

Безопасность, с которой могут работать команды

Производственная Kafka должна использовать шифрование при передаче, когда трафик проходит через ненадежные сети или содержит конфиденциальные данные. Большинство организаций должны использовать TLS для связи клиент-брокер и межброкерской связи. Аутентификация может быть взаимной TLS, SASL/SCRAM, Kerberos, OAuth или другим поддерживаемым механизмом в зависимости от среды.

ACL должны быть достаточно конкретными, чтобы предотвратить случайный ущерб. Продюсеру для orders.created не нужно разрешение на запись в каждый топик. Группе потребителей для биллинга не нужно разрешение на изменение конфигураций брокера. Используйте соглашения об именах, которые делают ACL читаемыми, и привязывайте сервисные субъекты к приложениям, а не к отдельным людям.

Секреты нуждаются в ротации. Если учетные данные SASL или хранилища ключей копируются вручную на серверы, ротация становится болезненной и в конечном итоге прекращается. По возможности используйте менеджер секретов вашей платформы. Тестируйте ротацию в staging, включая поэтапные перезапуски клиентов.

Также решите, кто может создавать топики. Автоматическое создание топиков удобно в разработке и опасно в производстве. Опечатка в имени топика может создать новый топик с разделами по умолчанию, репликацией по умолчанию и хранением по умолчанию. Многие производственные кластеры отключают автоматическое создание топиков и управляют топиками через инфраструктурный код или утвержденный рабочий процесс.

Проверки брокера и хранилища

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

Отделите журналы Kafka от посторонних шумных рабочих нагрузок. Избегайте размещения данных Kafka на общих дисках, где другой процесс может внезапно потреблять ввод-вывод. В облачных средах понимайте ограничения пропускной способности томов, кредиты burst и поведение при восстановлении. Диск, который хорошо показывает себя в течение минуты, может все равно испытывать трудности при устойчивой репликации и уплотнении.

Осведомленность о стойках имеет значение, когда у вас есть несколько зон доступности или стоек. Настройте идентификаторы стоек брокеров и размещение топиков, чтобы реплики не находились в одной зоне отказа. Коэффициент репликации 3 менее полезен, если все три реплики исчезают из-за проблемы с одной стойкой или зоной.

Мониторинг и оповещения, которые выявляют реальные сбои

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

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

Отставание потребителей требует контекста. Отставание в 100 записей может быть нормальным для топика, который получает миллионы в час. Отставание в 100 может быть серьезным для низкообъемного командного топика. По возможности предупреждайте о возрасте отставания или времени до наверстывания, а не просто о количестве записей.

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

Проверка готовности к производству

Прежде чем назвать кластер Kafka готовым к производству, я бы проверил следующие пункты:

Критические топики имеют явные разделы, коэффициент репликации, хранение, политику очистки и min.insync.replicas.
Продюсеры для критических топиков используют acks=all, идемпотентность (где поддерживается), повторные попытки и четкую обработку ошибок.
Потребители фиксируют смещения только после того, как приложение достигло своей предполагаемой точки обработки.
TLS, аутентификация и ACL включены и протестированы.
Автоматическое создание топиков отключено или строго контролируется.
Мониторинг охватывает работоспособность брокера, ошибки клиентов, отставание потребителей, диск и репликацию.
Ожидания по резервному копированию или повторному воспроизведению задокументированы. Хранение Kafka не заменяет все потребности в резервном копировании.
Процедуры перезапуска брокера, развертывания клиента и ротации учетных данных протестированы.

Практический вывод

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