Налаштування кластера Kafka: реплікація, партиціонування та діагностика

Налаштування кластера Kafka з реплікацією та партиціонуванням

У нашій практиці часто трапляється ситуація: три брокери запущені, топіки створені, додаток пише — але під навантаженням починається: UnderReplicatedPartitions зростає, consumer lag не знижується, leader election відбувається кожні кілька хвилин. Це не апаратна проблема, а неправильно виставлені replication.factor, min.insync.replicas та відсутність rack-aware assignment. Усе це закладається при початковому налаштуванні кластера — переробляти потім дорожче, ніж замовити аудит під ключ. Зв'яжіться з нами — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення. Правильне налаштування кластера знижує операційні витрати на 20–30% за рахунок скорочення простоїв та ефективного використання ресурсів. Типова річна економія — до $5000 для середнього кластера.

Replication factor 3: чому це недостатньо

Replication factor три — необхідна, але недостатня умова. Якщо три брокери стоять в одній стійці та живляться від одного PDU, при відмові живлення ви втрачаєте весь кластер одразу. Kafka підтримує rack-awareness через broker.rack у server.properties — і це потрібно виставити до створення першого топіка, інакше лідери та репліки будуть розподілені без урахування топології.

# broker 1 — server.properties
broker.id=1
broker.rack=rack-a
log.dirs=/data/kafka/logs
num.partitions=6
default.replication.factor=3
min.insync.replicas=2
unclean.leader.election.enable=false

unclean.leader.election.enable=false — ключовий параметр для production. Без нього Kafka може вибрати лідера з out-of-sync репліки, що призведе до втрати повідомлень. Так, кластер на кілька секунд стане недоступним для запису при втраті ISR-кворуму — але це передбачуваний сценарій, який обробляється на стороні producer'а через retry. Втрата даних — ні.

На стороні producer'а:

acks=all retries=3 retry.backoff.ms=500 enable.idempotence=true 

enable.idempotence=true автоматично виставляє acks=all та виключає дублікати при retry. Для більшості production-сценаріїв це дефолт, який потрібно явно увімкнути.

Як визначити оптимальну кількість партицій?

Популярна порада «ставте більше партицій» — працює до певної межі. Кожна партиція — це файловий дескриптор на кожному брокері, плюс метадані в ZooKeeper (або KRaft). При 10 000 партицій на кластері з трьох брокерів controller failover починає займати десятки секунд.

Практичне правило: partitions = max(throughput_mb/s ÷ 10, consumer_count). Для топіка з пропускною здатністю 100 МБ/с та 8 consumer-інстансами — 10 партицій. Не 100.

Партиціонування впливає на паралелізм споживання: один consumer у групі читає одну або кілька партицій, але не менше однієї. Якщо партицій менше, ніж інстансів у consumer group — частина інстансів простоюватиме. Це часта проблема при горизонтальному масштабуванні споживачів без попереднього планування топології.

Правильне партиціонування дозволяє обробляти в 2 рази більше повідомлень при тих же ресурсах. Змінити кількість партицій у існуючого топіка можна:

kafka-topics.sh --bootstrap-server kafka:9092 \ --alter --topic orders \ --partitions 20 

Але порядок ключів при цьому порушиться — якщо у вас key-based partitioning та семантика «всі події одного замовлення в одну партицію», збільшення кількості партицій вимагає міграції або перестворення топіка з ребалансуванням.

Як налаштувати rack-awareness?

Rack-awareness налаштовується параметром broker.rack у server.properties на кожному брокері. Після перезапуску кластера Kafka автоматично розподіляє репліки так, щоб вони потрапляли в різні стійки. Перевірити розподіл можна командою:

kafka-topics.sh --bootstrap-server kafka:9092 --describe --topic orders 

Якщо всі репліки однієї партиції опинилися в одній стійці — значить, rack-awareness не працює. Типова причина: різні значення broker.rack або відсутність параметра в частини брокерів.

kafka-topics.sh --describe --topic orders
kafka-log-dirs.sh --describe --topic orders
kafka-consumer-groups.sh --describe --group my-group

Які метрики Kafka обов'язково моніторити?

kafka-topics.sh --describe — перший інструмент. Показує ISR-список для кожної партиції:

kafka-topics.sh --bootstrap-server kafka:9092 \
  --describe --topic orders
# Topic: orders Partition: 0 Leader: 2 Replicas: 2,1,3 Isr: 2,1
# Partition 0: ISR = [2,1], репліка 3 випала

Якщо ISR менший за replication factor — брокер або лежить, або відстав. kafka-log-dirs.sh покаже розмір та зміщення кожної репліки. kafka-consumer-groups.sh --describe — lag по кожній партиції в consumer group.

JMX-метрики, які потрібно моніторити обов'язково:

RequestHandlerAvgIdlePercent < 0.2 означає, що брокер перевантажений — потрібно або додавати брокери, або знижувати навантаження. Це метрика, яку часто не налаштовують, а потім дивуються зростанню latency при, здавалося б, достатніх ресурсах.

KRaft чи ZooKeeper: що обрати для метаданих?

На поточний момент KRaft (Kafka Raft Metadata mode) — без ZooKeeper — стабільний з Kafka 3.3 та рекомендований для нових кластерів. Основний виграш: controller failover займає секунди замість десятків секунд (у 3-5 разів швидше), спрощене операційне обслуговування. ZooKeeper як залежність піде в Kafka 4.x.

Згідно з документацією Apache Kafka, KRaft забезпечує вищу надійність та простоту.

Для міграції існуючого кластера з ZooKeeper на KRaft — процедура kafka-storage.sh + kafka-metadata-migration — це окреме завдання з вікном простою або rolling-міграцією залежно від версії.

Покроковий план налаштування кластера Kafka для production

1. Встановіть broker.rack для кожного брокера (rack-awareness).
2. Налаштуйте default.replication.factor=3 та min.insync.replicas=2.
3. Вимкніть unclean.leader.election.enable=false.
4. Налаштуйте моніторинг критичних метрик (Prometheus + Grafana).
5. Для нових кластерів використовуйте KRaft замість ZooKeeper.
6. Виберіть кількість партицій за формулою max(throughput_mb/s / 10, consumer_count).

Що входить у роботу

• Детальний аудит конфігурації кластера (broker, producer, consumer).
• Проектування топології топіків та партиціонування.
• Налаштування rack-awareness та параметрів реплікації.
• Налаштування моніторингу (Prometheus + Grafana) з критичними алертами.
• Документація з експлуатації та runbook для аварійних ситуацій.
• Навчання команди (1-2 сесії).
• Підтримка протягом 30 днів після здачі.

Ми працюємо на ринку з 2019 року та виконали понад 40 проєктів з оптимізації Kafka, що підтверджує нашу експертизу. Наші інженери мають сертифікацію Confluent Certified Developer та гарантують якість налаштування. Строки: новий кластер з нуля — 2-3 дні, аудит та переналаштування існуючого production-кластера з мінімальним простоєм — 4-5 днів. Вартість аудиту кластера складає від 1500 до 3000 євро в залежності від складності. Оцінимо ваш проєкт — отримайте консультацію.

Типові помилки при налаштуванні кластера

• min.insync.replicas=1 при replication.factor=3 — втрата даних при відмові єдиної in-sync репліки.
• Відсутність rack-awareness — усі брокери в одній зоні доступності.
• Занадто багато партицій (понад 1000 на брокер) — деградація контролера.
• unclean.leader.election.enable=true — ризик втрати повідомлень.
• Не налаштовано моніторинг RequestHandlerAvgIdlePercent — непомітне перевантаження брокерів.

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