Формулы планирования ёмкости

Kafka-кластер без capacity planning — это кластер, который упадёт в самый неудобный момент. Под-provisioned кластер даёт data loss, накопленный lag, outages в production. Пере-provisioned кластер — wasteful spend на железо, которое простаивает.

В этом уроке: четыре формулы (диск, партиции, сеть, память) с подробными числовыми примерами и интерактивным калькулятором для ваших конкретных параметров.

Зачем capacity planning

Интерактивный калькулятор

Калькулятор выше позволяет ввести ваши параметры и мгновенно получить расчёт. Ниже — подробное объяснение каждой формулы.

Формула 1: Disk sizing

Расчёт объёма дисков — самый критичный шаг. Ошибка здесь стоит дорого: Kafka не может перераспределить данные за секунду.

Базовая формула ежедневного объёма:

daily_GB = (msg_rate_per_sec × avg_msg_bytes × 86400 × replication_factor) / 1073741824

где 86400 — секунд в сутках, 1073741824 = 1024³.

Пример расчёта:

Параметры системы: 10,000 msg/s, avg msg size 500 bytes, RF=3, retention=7 дней.

daily_GB = (10000 × 500 × 86400 × 3) / 1073741824
         = 1296000000000 / 1073741824
         = 1207 GB ≈ 1.21 TB/день

Суммарный объём за retention:

total_disk_GB = daily_GB × retention_days
              = 1207 × 7
              = 8449 GB ≈ 8.45 TB

Per broker (3 брокера, равномерное распределение):

per_broker_GB = total_disk_GB / broker_count
              = 8449 / 3
              = 2816 GB ≈ 2.82 TB per broker

Учёт сжатия:

Если compression.type=lz4 (ratio ≈ 2.0x):

effective_daily_GB = daily_GB / compression_ratio
                   = 1207 / 2.0
                   = 603 GB/день

Сжатие применяется producer’ом до записи на диск — брокер хранит уже сжатые данные.

Headroom: добавьте 30-40%:

provisioned_disk = per_broker_GB × 1.4
                 = 2816 × 1.4
                 = 3943 GB ≈ 4 TB per broker

При добавлении нового брокера partition reassignment создаёт дополнительную I/O нагрузку. Headroom необходим.

Формула 2: Partition count

Количество партиций определяет параллелизм. Нельзя уменьшить (только пересоздать топик), можно только увеличить.

Throughput-based минимум:

throughput_MB_s = msg_rate_per_sec × avg_msg_bytes / 1048576

min_partitions_throughput = ceil(throughput_MB_s / partition_throughput_MB_s)

partition_throughput_MB_s — пропускная способность одной партиции:

• Spinning disk (HDD): ~10 MB/s
• SSD: ~30 MB/s
• NVMe SSD: ~100 MB/s

Consumer-based минимум:

min_partitions_consumers = max_consumer_count

Один consumer в группе = один поток чтения. Если нужно 8 parallel consumers — нужно минимум 8 партиций.

Финальный минимум:

min_partitions = max(min_partitions_throughput, min_partitions_consumers)

Пример:

Параметры: 50 MB/s target throughput, SSD-диски (30 MB/s per partition), 8 consumers per group.

min_partitions_throughput = ceil(50 / 30) = 2
min_partitions_consumers = 8
min_partitions = max(2, 8) = 8 партиций

С запасом 2x: рекомендуем 12 партиций (кратно числу брокеров = 3 для равномерного распределения).

Практические ограничения partition count:

• Рекомендуемый максимум: 10,000 партиций per broker
• При 200,000+ партиций в кластере: ухудшение производительности контроллера (KRaft)
• Каждая партиция = open file handles (1 на сегмент), индексные файлы, memory для ISR tracking
• Не создавайте 1,000 партиций для топика с одним consumer — waste ресурсов

Формула 3: Network bandwidth

Kafka генерирует три потока сетевого трафика: входящий от producers, inter-broker репликация, исходящий к consumers.

Входящий трафик (от producers):

inbound_MB_s = msg_rate_per_sec × avg_msg_bytes / 1048576

Трафик репликации (inter-broker):

replication_MB_s = inbound_MB_s × (replication_factor - 1)

Каждый входящий байт реплицируется на (RF-1) фолловеров.

Исходящий трафик (к consumers):

outbound_MB_s = inbound_MB_s × consumer_group_count

Каждая consumer group получает полную копию данных.

Per-broker при равномерном распределении:

per_broker_MB_s = (inbound_MB_s + replication_MB_s + outbound_MB_s) / broker_count

Пример:

Параметры: 5 MB/s inbound, RF=3, 3 consumer groups, 3 брокера.

inbound_MB_s     = 5 MB/s
replication_MB_s = 5 × (3-1) = 10 MB/s
outbound_MB_s    = 5 × 3 = 15 MB/s

total_MB_s = 5 + 10 + 15 = 30 MB/s (суммарно по кластеру)

per_broker_MB_s = 30 / 3 = 10 MB/s per broker

NIC limit: 1 Gbps = 125 MB/s. При 10 MB/s: утилизация 10/125 = 8% — безопасно.

Правило 70%: Не нагружайте NIC более чем на 70% от номинала в sustained режиме. Оставшиеся 30% — для burst трафика и partition reassignment.

max_sustained_MB_s = NIC_capacity_MB_s × 0.7

# 1 Gbps NIC: 125 × 0.7 = 87.5 MB/s max sustained
# 10 Gbps NIC: 1250 × 0.7 = 875 MB/s max sustained

Формула 4: Memory (JVM heap + OS page cache)

Kafka — I/O-bound, не heap-bound. Память важна не для JVM, а для OS page cache.

JVM Heap:

# Правило: 6 GB, фиксированный
-Xms6g -Xmx6g

Более 6-8 GB heap = проблемы с GC паузами (Full GC на 16GB heap = стоп мира на несколько секунд). Kafka не использует heap для хранения данных — всё идёт через page cache.

OS Page Cache:

ideal_page_cache_GB = active_segments_count × segment_size_GB

active_segment_per_partition ≈ 1 GB (default log.segment.bytes=1073741824)
active_segments_count = partition_count × replication_factor

Пример расчёта памяти:

100 партиций per broker, segment size = 1 GB, RF=3:

active_segments = 100 × 3 = 300 (учитывая что партиции распределены по брокерам)
ideal_page_cache = 300 GB

С 64 GB RAM: доступный page cache = 64 - 6 (heap) - 2 (OS) = 56 GB
56 / 300 = 18.7% активных сегментов в cache

18.7% — приемлемо для нагруженного production. Идеал — 33%+. Добавление RAM является самой cost-effective оптимизацией Kafka.

Формула 5: Broker count

min_brokers = max(
  disk_requirement,
  network_requirement,
  partition_requirement
)

# Disk: total_disk_GB / disk_per_broker_GB
# Network: total_network_MB_s / (NIC_MB_s × 0.7)
# Partitions: total_partitions × RF / partitions_per_broker_limit

Real-world sizing examples