Лучшие практики масштабирования рабочих нагрузок на основе Kafka

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

Перед началомиспользования Кафки в ваших проектах давайте понимать, когда использовать Кафку:

• Потоки событий высокого объема. Когда ваше приложение/сервис генерирует непрерывный поток событий, таких как события активности пользователя, события кликов по веб-сайту, события данных датчиков, события ведения журнала или обновления рынка акций, способность Кафки обрабатывать большие объемы с низкой задержкой очень полезна.
• Аналитика в реальном времени. Кафка особенно полезна в построении конвейеров обработки данных в реальном времени, где данные должны обрабатываться сразу по поступлении. Она позволяет передавать данные в аналитические движки, такие как потоки Кафки, Апач Спарк или Флинк, для мгновенной аналитики/инсайтов и поточной или пакетной обработки.
• Разделение приложений. Действуя как центральный хаб сообщений, она может разграничивать различные части приложения, обеспечивая независимую разработку и масштабирование служб, а также поощряя принцип ответственного разделения.
• Интеграция данных между системами.При интеграции распределенных систем Kafka может эффективно передавать данные между различными приложениями в рамках команд/проектов, выступая в качестве надежного брокера данных.

Ключевые отличия от других систем очередей

Ниже приведены отличия Apache Kafka от таких систем, как ActiveMQ, ZeroMQ и VerneMQ:

Постоянное хранилище

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

Партиционирование

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

Группы потребителей

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

• Активность пользователей, потребляемая командами ML для обнаружения подозрительной активности
• Команда рекомендаций для создания рекомендаций
• Команда рекламы для создания релевантной рекламы

Лучшие практики продюсера Kafka

Размер пакета и время простоя

Настройкой параметров batch.size и linger.ms вы можете увеличить пропускную способность вашего продюсера Kafka. batch.size – это максимальный размер пакета в байтах. Kafka попытается объединить данные в пакет перед отправкой их продюсерам.

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

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

Сжатие

Еще один способ увеличить пропускную способность – включить сжатие через конфигурацию compression.type. Производитель может сжимать данные с помощью gzip, snappy или lz4 перед отправкой их на брокеров. Для больших объемов данных эта конфигурация помогает уменьшить накладные расходы на сжатие с эффективностью сети. Это также экономит пропускную способность и увеличивает пропускную способность системы. Кроме того, установив соответствующий сериализатор и сериализатор ключей, мы можем гарантировать, что данные сериализуются в формате, совместимом с вашими потребителями.

Повторы и идемпотентность

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

Подтверждения

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

• 0 – самый быстрый, но без гарантии доставки сообщения.
• 1 – сообщение подтверждается после записи на брокера-лидера, обеспечивая базовую надежность.
• все – сообщение считается доставленным только после того, как все реплики его подтвердили, обеспечивая высокую надежность.

Настройка конфигурации в зависимости от рабочей нагрузки

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

Лучшие практики для потребителей Kafka

Группы потребителей

Каждый потребитель Kafka должен принадлежать к группе потребителей; группа потребителей может содержать одного или нескольких потребителей. Создавая больше потребителей в группе, вы можете масштабироваться для чтения из всех разделов, что позволит вам обрабатывать огромный объем данных. Конфигурация group.id помогает идентифицировать группу потребителей, к которой принадлежит потребитель, позволяя балансировать нагрузку между несколькими потребителями, потребляющими из одной и той же темы. Лучшей практикой является использование значимых идентификаторов групп для легкой идентификации групп потребителей в вашем приложении. 

Коммит смещений

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

• auto.offset.reset – определяет, что делать, когда потребитель начинает потреблять тему без фиксированных смещений (например, новая тема или потребитель присоединяется к группе впервые). Варианты включают earliest (читать с начала), latest (читать с конца) или none (выдать ошибку). Выберите “earliest” для большинства случаев использования, чтобы избежать потери данных, когда новый потребитель присоединяется к группе.Управляет тем, как потребитель начинает потреблять данные, обеспечивая правильное поведение при перезапуске потребителя или добавлении к группе.
• enable.auto.commit – помогает настроить автоматическое периодическое фиксирование смещений. Обычно мы устанавливаем значение false для большинства производственных сценариев, где нам не нужна высокая надежность, и вручную фиксируем смещения в логике вашего приложения, чтобы гарантировать обработку в точности один раз.Обеспечивает управление фиксацией смещений, обеспечивая более точный контроль обработки данных.
• auto.commit.interval.ms – интервал в миллисекундах, через который смещения автоматически фиксируются, если enable.auto.commit установлен в true. Измените на основе времени обработки вашего приложения, чтобы избежать потери данных из-за неожиданного сбоя. 

Fetch Size и Max Poll Records

Эта конфигурация помогает контролировать количество записей, извлекаемых в каждом запросе, настроить fetch.min.bytes и max.poll.records. Увеличение этого значения может помочь улучшить пропускную способность ваших приложений, снизить использование ЦП и уменьшить количество вызовов к брокерам.

• fetch.min.bytes – минимальное количество байтов для извлечения из брокера в одном запросе. Установите небольшое значение, чтобы избежать ненужных сетевых вызовов, но не слишком маленькое, чтобы избежать чрезмерного sondinga. Это помогает оптимизировать эффективность сети, предотвращая маленькие, частые запросы.
• fetch.max.bytes – максимальное количество байтов для извлечения от брокера в одном запросе. Настройте в зависимости от доступной памяти, чтобы избежать перегрузки потребителей. Это уменьшает объем данных, получаемых за один запрос, что позволяет избежать проблем с памятью.
• max.poll.interval.ms – максимальное время ожидания возврата данных от запроса poll перед таймаутом. Установите хороший таймаут, чтобы избежать зависаний/задержек потребителя, если данные недоступны. Это помогает предотвратить застревание потребителей в ожидании сообщений слишком долго. (Иногда pod’ы k8s могут перезапускаться, если проверки жизнеспособности повреждены).

Назначение партиций

Это стратегия, используемая для назначения партиций (partition.assignment.strategy) потребителям внутри группы (например, range, roundrobin). Используйте range в большинстве сценариев для равномерного распределения партиций среди потребителей. Это обеспечивает балансировку нагрузки между потребителями в группе.

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

• Сложность. Внедрение Kafka требует более глубокого понимания концепций распределенных систем, таких как разделение и управление смещением из-за его продвинутых функций и конфигураций.
• Мониторинг и управление. Внедрение мониторинга и управления кластером Kafka важно для обеспечения высокой доступности и производительности.
• Безопасность. Внедрение надежных практик безопасности для защиты чувствительных данных, передаваемых через темы Kafka, также важно.

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