Оптимизация разделов Kafka для масштабируемости и пропускной способности

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

Не существует универсального лучшего числа. Тема платежей, тема кликов и компактная тема состояния клиента имеют разные потребности в упорядочивании, размеры сообщений, настройки хранения и поведение потребителей. Полезный вопрос не в том: «Сколько разделов лучше?» Он в том: «Сколько разделов нам нужно для пропускной способности, упорядочивания и роста этой темы без создания излишних накладных расходов на брокера?»

Понимание разделов Kafka

По своей сути тема Kafka разделена на один или несколько разделов. Каждый раздел представляет собой упорядоченный журнал только для добавления. Разделы являются единицей параллелизма в Kafka:

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

Ключевые характеристики разделов:

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

Факторы, влияющие на количество разделов

При принятии решения о количестве разделов для темы Kafka следует оценить несколько критических факторов:

1. Требования к пропускной способности (производители и потребители)

Пропускная способность производителя: Больше разделов может распределить записи между брокерами, но только если лидеры сбалансированы и производители хорошо распределяют записи. Тема с ключом и одним горячим ключом все еще может перегрузить один раздел.
Пропускная способность потребителя: Если один потребитель может обрабатывать 2000 сообщений в секунду, а пик темы составляет 20 000 сообщений в секунду, вам нужно достаточно разделов, чтобы запустить достаточное количество потребителей в группе. Точное число зависит от измеренной скорости потребителя, а не от догадок.

2. Цели масштабируемости

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

3. Ресурсы брокера

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

4. Требования к упорядочиванию сообщений

Упорядочивание на основе ключа: Если упорядочивание критично и вы используете ключ сообщения, записи с одинаковым ключом обычно попадают в один раздел. Это дает порядок для каждого ключа, а не порядок для всей темы. Горячий ключ все равно попадает в один раздел и может стать узким местом для одного потребителя.
Без строгого упорядочивания: Если строгое упорядочивание сообщений не требуется, вы можете более свободно распределять сообщения между разделами, отдавая приоритет пропускной способности и параллелизму.

5. Масштабируемость группы потребителей

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

Практический способ выбора количества разделов

Вот практические стратегии, которые помогут вам определить оптимальное количество разделов:

1. Начните с базового уровня и мониторьте

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

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

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

2. Рассчитайте на основе ожидаемой пропускной способности

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

Формула: Количество разделов = (Общая ожидаемая пропускная способность / Пропускная способность одного экземпляра потребителя) * Буфер
- Общая ожидаемая пропускная способность: Используйте пиковую скорость производства, а не среднесуточную.
- Пропускная способность одного экземпляра потребителя: Измерьте вашего реального потребителя с реальными размерами сообщений и последующими вызовами.
- Буфер: Добавьте запас для всплесков и роста. Не притворяйтесь, что расчет точен.

Пример:

Пиковая ожидаемая пропускная способность: 50 000 сообщений в секунду
Пропускная способность одного экземпляра потребителя: 5 000 сообщений в секунду
Буфер: 1.5x
(50 000 / 5 000) * 1.5 = 15

В этом случае 16 разделов — это разумная круглая отправная точка. Если упорядочивание, емкость брокера или распределение ключей противоречат этому числу, скорректируйте его.

3. Учитывайте возможности и ограничения брокера

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

Вместо того чтобы рассматривать «100 разделов на брокера» или «1000 разделов на брокера» как универсальную истину, отслеживайте метрики брокера: задержку запросов, ввод-вывод диска, состояние контроллера, недореплицированные разделы, давление на кэш страниц и продолжительность ребалансировки. Используйте проверенные лимиты вашей платформы, если они есть в вашей организации.

4. Распределение ключей и горячие разделы

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

Решение: Если вы предвидите горячие разделы, рассмотрите такие стратегии, как:
- Используйте менее асимметричный ключ, если бизнес-упорядочивание позволяет.
- Используйте составной ключ, например customer_id:event_type, если это сохраняет необходимое упорядочивание.
- Разделите один горячий рабочий процесс в отдельную тему.
- Намеренно шардируйте горячий ключ, затем обрабатывайте упорядочивание в более узкой области.

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

Создание и изменение тем с разделами

При создании новой темы вы указываете количество разделов.

Создание темы с определенным количеством разделов

Используя скрипт kafka-topics.sh:

kafka-topics.sh --create --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092,kafka-broker-2:9092 \
  --partitions 16 \
  --replication-factor 3

--partitions 16: Устанавливает для темы 16 разделов.
--replication-factor 3: Каждый раздел будет иметь 3 реплики на разных брокерах для отказоустойчивости.

Увеличение количества разделов в существующей теме

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

Используя скрипт kafka-topics.sh:

kafka-topics.sh --alter --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092 \
  --partitions 24

--partitions 24: Увеличивает количество разделов для my-high-throughput-topic до 24.

Важные соображения при изменении разделов:

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

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

Метрики, которые говорят, что количество разделов неверно

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

Ищите эти паттерны:

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

Для групп потребителей:

kafka-consumer-groups.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --group my-consumer-group

Для макета темы:

kafka-topics.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --topic my-high-throughput-topic

Если отстает только один раздел, добавление потребителей не поможет, если только работа не может быть распределена по большему количеству разделов.

Лучшие практики и подводные камни

Делайте:

Начинайте с измеренных потребностей: Используйте ожидаемое количество потребителей, тесты пропускной способности и емкость брокера.
Согласуйте с параллелизмом потребителей: Убедитесь, что у вас достаточно разделов для эффективного масштабирования экземпляров потребителей.
Оставляйте пространство для роста: Добавление разделов позже возможно, но не без последствий.
Понимайте распределение ключей: Если используете ключи, анализируйте их распределение, чтобы избежать горячих разделов.
Используйте инструменты мониторинга Kafka: Используйте инструменты для отслеживания метрик темы/раздела, отставания потребителей и нагрузки брокера.

Не делайте:

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

Разумный процесс принятия решений

Для новой темы я обычно работаю в таком порядке:

Определите требование к упорядочиванию. Для каждого клиента? Для каждой учетной записи? Без строгого порядка?
Измерьте или оцените пиковую пропускную способность производителя и размер сообщения.
Протестируйте один экземпляр потребителя с реалистичными зависимостями ниже по потоку.
Выберите разделы на основе необходимого параллелизма потребителей плюс запас для роста.
Проверьте общее влияние на кластер после учета коэффициента репликации.
Мониторьте отставание на раздел и нагрузку брокера после запуска.

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