Перейти к содержанию

Сайзинг кластера Kafka

Общая философия сайзинга Kafka

  1. Это итеративный процесс. Ваши первоначальные расчеты — это обоснованная гипотеза. Реальные цифры вы получите только после нагрузочного тестирования и мониторинга в проде.
  2. Планируйте под пиковую нагрузку, а не среднюю. Кластер должен выдерживать пики трафика (например, в "черную пятницу" или во время маркетинговых кампаний) с запасом.
  3. Учитывайте рост. Заложите в расчеты ожидаемый рост нагрузки на ближайшие 6-12 месяцев.

Шаг 1: Сбор исходных данных (самый важный шаг)

Прежде чем считать CPU/RAM/Disk, вам нужно ответить на следующие вопросы о вашей нагрузке:

  1. Входящий трафик (Throughput In):
    • Средний и пиковый объем данных, который продюсеры будут писать в Kafka (в МБ/сек).
    • Среднее и пиковое количество сообщений в секунду.
  2. Размер сообщений:
    • Средний и максимальный размер одного сообщения (в КБ).
  3. Количество топиков и партиций:
    • Сколько топиков планируется? Сколько партиций будет в каждом топике? Большое количество партиций (~тысячи на брокер) увеличивает нагрузку на RAM и CPU.
  4. Срок хранения данных (Retention Period):
    • Как долго данные должны храниться в Kafka (в днях или часах)? Это напрямую влияет на требования к диску.
  5. Фактор репликации (Replication Factor):
    • Сколько копий каждой партиции вы хотите хранить? Для схемы с 2 ЦОД, replication-factor=3 является хорошим компромиссом между надежностью и затратами. replication-factor=4 (по 2 копии в каждом ЦОД) обеспечит максимальную отказоустойчивость при потере одного ЦОД, но удвоит трафик репликации и требования к диску. Будем считать с RF=4.
  6. Количество консьюмеров:
    • Сколько групп консьюмеров и сколько инстансов будут читать данные? Это влияет на исходящий трафик и нагрузку на сеть/CPU.
  7. Требования к задержке (Latency):
    • Насколько критична задержка от записи до чтения? Это повлияет на выбор дисков (HDD vs SSD).
  8. Использование SSL/TLS:
    • Будет ли шифрование трафика? SSL добавляет заметную нагрузку на CPU.

Шаг 2: Сайзинг Zookeeper (3 ноды в 3 ЦОД)

Zookeeper не требователен к ресурсам, но очень чувствителен к задержкам диска и сети. Схема с 3 нодами в 3 разных ЦОД — классическая и правильная для высокой доступности, но будьте готовы к тому, что меж-ЦОД задержки будут определять производительность ZK.

  • CPU:

    • Zookeeper в основном однопоточный. 2-4 vCPU более чем достаточно для 99% случаев. Нагрузка на CPU возникает только при очень большом количестве клиентов или частых изменениях метаданных (создание/удаление топиков).
    • Рекомендация: 2-4 vCPU.

  • RAM:

    • Основное требование — Zookeeper должен полностью держать свою базу данных в памяти. Для Kafka эта база обычно небольшая.
    • 4 ГБ — безопасный минимум. 8 ГБ — комфортный стандарт, который покроет почти любые нужды.
    • Рекомендация: 8 ГБ RAM.

  • HDD/Disk:

    • Это самый критичный компонент для Zookeeper. Ему нужен диск с очень низкой задержкой записи (low latency).
    • Тип диска: Обязательно SSD. Использование HDD для Zookeeper — прямой путь к нестабильности всего кластера Kafka.
    • Объем: Объем данных минимален. 10-20 ГБ с запасом хватит на годы.
    • Важно: Журнал транзакций Zookeeper (transaction log) должен находиться на отдельном физическом диске от логов ОС или других приложений, чтобы избежать конкуренции за IO.
    • Рекомендация: Быстрый SSD объемом 50-100 ГБ.

  • Сеть:

    • Низкая задержка между нодами Zookeeper критична. Убедитесь, что пинг между вашими тремя ЦОД стабилен и минимален (в идеале < 10-15 мс).

Шаг 3: Сайзинг брокеров Kafka (4 брокера в 2 ЦОД)

Здесь находятся основные ресурсы. Расчеты будем вести на один брокер.

1. Расчет дискового пространства (HDD/SSD)

Это самый простой для расчета компонент.

Формула:

Диск на 1 брокер = (Входящий_трафик_МБ/сек * 3600 * 24 * Дней_хранения * Фактор_репликации) / Количество_брокеров * 1.3

  • 1.3 — это запас в 30% на неравномерное распределение партиций, служебные файлы и чтобы диск не был заполнен на 100%.

Пример:

  • Пиковый входящий трафик: 50 МБ/сек
  • Срок хранения: 7 дней
  • Фактор репликации: 4
  • Количество брокеров: 4

Диск на 1 брокер = (50 * 3600 * 24 * 7 * 4) / 4 * 1.3 = (120,960,000 МБ) / 4 * 1.3 = 29,531 ГБ * 1.3 ≈ 38,39 ГБ ≈ 40 ТБ

HDD vs SSD:

  • HDD: Отлично подходят, если у вас большой срок хранения и основной сценарий — запись и последовательное чтение (типично для ETL). Kafka спроектирован для последовательного I/O, где HDD показывают себя хорошо.
  • SSD: Используйте, если у вас критична низкая задержка (<10-20 мс) или если консьюмеры часто читают "старые" данные, что приводит к случайному чтению.

Рекомендация: Начните с нескольких дисков JBOD (не RAID). RAID не дает Kafka преимуществ в производительности и усложняет восстановление.

2. Расчет RAM

Память в Kafka используется для двух основных целей:

  1. JVM Heap: для внутренних объектов Kafka.
  2. OS Page Cache: (самое важное!) для кеширования логов. Kafka отдает чтение данных консьюмерам прямо из page cache, минуя диски, если данные там есть. Чем больше Page Cache, тем быстрее чтение.

JVM Heap:

  • Стандартная отправная точка — 6-8 ГБ.
  • Слишком большой heap (>16 ГБ) может приводить к долгим паузам GC (Garbage Collection). Лучше отдать больше памяти под Page Cache.
  • Нагрузка на heap растет с количеством партиций на брокере.

Page Cache:

  • Это вся оставшаяся память. Общая RAM - JVM Heap - Память для ОС.
  • Хорошее правило: Page Cache должен вмещать "горячий" набор данных. Например, если ваши консьюмеры в основном читают данные за последний час, посчитайте, какой это объем.

Пример (продолжение):

  • Трафик: 50 МБ/сек
  • "Горячие" данные: за последний час.
  • Объем горячих данных = 50 МБ/сек * 3600 сек = 180,000 МБ ≈ 176 ГБ.
  • Этот объем распределится по 4 брокерам, т.е. ~44 ГБ на брокер.
  • Чтобы вместить это в Page Cache, вам понадобится сервер с 44 ГБ (Page Cache) + 8 ГБ (JVM Heap) + 4 ГБ (OS) ≈ 56 ГБ.
  • Рекомендация: Серверы с 64 ГБ или 128 ГБ RAM — это хороший стандарт для умеренно нагруженных кластеров.

3. Расчет CPU

CPU в Kafka используется для: * Обработки сетевых запросов (I/O threads). * Обработки запросов к дискам (request handler threads). * Репликации данных между брокерами. * SSL/TLS шифрования (очень ресурсоемко). * Компрессии (если она включена на брокере, но обычно это делают клиенты).

Подход к расчету: * Baseline: Начните с 8-12 vCPU. Этого хватит для трафика до ~100-200 МБ/сек без SSL. * С SSL: Если вы используете SSL, нагрузка на CPU может вырасти в 2-3 раза. Планируйте 16-24 vCPU или больше. Современные процессоры с поддержкой инструкций AES-NI сильно помогают. * Связь с сетью: Один современный CPU core может "прокачать" примерно 2-3 Гбит/с трафика. Посчитайте ваш пиковый сетевой трафик (входящий + исходящий + репликация) и оцените, сколько ядер нужно только для сети.

4. Расчет Сети (Network)

Часто становится узким местом.

Формула пиковой нагрузки на сеть брокера: Сеть = Входящий_трафик + Исходящий_трафик_консьюмерам + Трафик_репликации

  • Трафик репликации примерно равен входящему трафику, умноженному на (фактор_репликации - 1).

Пример (продолжение):

  • Входящий трафик: 50 МБ/сек
  • Фактор репликации: 4
  • Исходящий трафик: предположим, равен входящему (50 МБ/сек)
  • Пиковая нагрузка на сеть кластера = 50 МБ/с (продюсеры) + 50 МБ/с (консьюмеры) + 50 МБ/с * (4-1) (репликация) = 250 МБ/с
  • 250 МБ/с * 8 = 2000 Мбит/с = 2 Гбит/с.
  • Эта нагрузка распределится по 4 брокерам.

Рекомендация:

  • 10 GbE — это де-факто стандарт для любого серьезного кластера Kafka. Сеть 1 GbE очень быстро станет узким местом.
  • Для схемы с 2 ЦОД канал между ЦОД должен быть достаточно широким, чтобы выдержать трафик репликации.

Итоговая таблица-рекомендация (стартовая точка)

Компонент Ресурс Рекомендация для Zookeeper (на 1 ноду) Рекомендация для Kafka Broker (на 1 брокер)
CPU vCPU 2 - 4 8 - 16 (16 - 32+ с SSL)
RAM ГБ 8 64 - 128 (8 ГБ JVM Heap, остальное - Page Cache)
Диск (Тип) SSD (обязательно) HDD (для долгого хранения) или SSD (для низкой задержки)
Диск (Объем) ТБ 0.1 Рассчитывается по формуле. В расчетах
выше это ~40 ТБ.
Сеть 1 GbE (низкая задержка между ЦОД) 10 GbE (минимум). Широкий канал между ЦОД.

Заключительные шаги

  1. Нагрузочное тестирование: После развертывания кластера с расчетными параметрами, используйте инструменты (например, kafka-producer-perf-test, kafka-consumer-perf-test или более продвинутые как k6, JMeter) для симуляции вашей пиковой нагрузки.
  2. Мониторинг: Настройте детальный мониторинг (Prometheus + Grafana — отличный выбор) для ключевых метрик:
    • Брокеры: CPU Load, Network I/O, Disk I/O, JVM Heap Usage, GC pauses, Request Latency, Under-replicated partitions.
    • Zookeeper: Request Latency (особенно fsync time), Outstanding requests.
  3. Корректировка: На основе данных мониторинга скорректируйте ресурсы. Возможно, вам нужно добавить диски, увеличить RAM или перейти на более мощные CPU.

Что дальше?

  1. Нашли эту статью полезной? Поделитесь ею и помогите распространить знания!
  2. Нашли ошибку или есть идеи 💡 о том, что и как я могу улучшить? Напишите мне в Telegram.
  3. Хотите узнать обо мне больше? Читайте здесь.