Налаштування топіків та партицій Kafka: гайд з конфігурації

Налаштування топіків та партицій Kafka: гайд з конфігурації

Уявіть: ви запускаєте прод, а consumer lag зростає, партиції перекошені, один брокер перевантажений. Типова ситуація при неправильній конфігурації топіків Kafka. Ми розберемо, як спроектувати схему топіків, щоб уникнути таких проблем.

Кількість партицій та фактор реплікації — два параметри, які не можна легко змінити після створення топіка. Зменшити кількість партицій неможливо без повного перестворення топіка. Тому правильне налаштування при створенні важливе. Ми гарантуємо, що при грамотному проектуванні ви не зіткнетеся з гарячими вузлами та зайвими затримками.

Чому важлива правильна конфігурація партицій?

Кожна партиція — одиниця паралелізму. Один консьюмер у групі обробляє одну партицію. Якщо топік має 6 партицій, максимум 6 консьюмерів у групі можуть читати паралельно. Зайві консьюмери простоюють. Плюс запис у партицію строго впорядкований. Глобальний порядок по топіку не гарантується — тільки всередині партиції. Це критично для подій, які повинні оброблятися послідовно (наприклад, всі дії одного користувача).

Приклад: топік user-events з 6 партиціями. Події одного користувача (user:101) можуть потрапити в різні партиції (0 і 1), що порушує порядок обробки. Ключ повідомлення вирішує проблему: hash(user_id) % num_partitions завжди дає одну партицію.

Як створювати та налаштовувати топіки?

Через kafka-topics.sh

# Базовый топик для событий пользователей
kafka-topics.sh --bootstrap-server kafka-1:9092 \
    --create \
    --topic user-events \
    --partitions 12 \
    --replication-factor 3 \
    --config retention.ms=604800000 \
    --config retention.bytes=10737418240 \
    --config compression.type=lz4 \
    --config min.insync.replicas=2 \
    --config message.max.bytes=1048576

# Компактный топик — для хранения последнего состояния по ключу
kafka-topics.sh --bootstrap-server kafka-1:9092 \
    --create \
    --topic user-profiles \
    --partitions 24 \
    --replication-factor 3 \
    --config cleanup.policy=compact \
    --config min.cleanable.dirty.ratio=0.1 \
    --config segment.ms=3600000 \
    --config delete.retention.ms=86400000

# Высокоприоритетная очередь с коротким retention
kafka-topics.sh --bootstrap-server kafka-1:9092 \
    --create \
    --topic order-processing-priority \
    --partitions 6 \
    --replication-factor 3 \
    --config retention.ms=3600000 \
    --config max.message.bytes=102400

Програмне управління через Admin API (Java/Kotlin)

Створення топіків програмно — правильно для додатків, які створюють топіки динамічно:

Properties props = new Properties();
props.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-1:9092,kafka-2:9092,kafka-3:9092");
props.put(AdminClientConfig.REQUEST_TIMEOUT_MS_CONFIG, 5000);
props.put(AdminClientConfig.DEFAULT_API_TIMEOUT_MS_CONFIG, 10000);

try (AdminClient admin = AdminClient.create(props)) {
    NewTopic userEvents = new NewTopic("user-events", 12, (short) 3);
    userEvents.configs(Map.of(
        "retention.ms", "604800000",
        "compression.type", "lz4",
        "min.insync.replicas", "2"
    ));

    NewTopic deadLetter = new NewTopic("user-events-dlq", 3, (short) 3);
    deadLetter.configs(Map.of(
        "retention.ms", "2592000000", // 30 дней
        "retention.bytes", "-1"
    ));

    CreateTopicsResult result = admin.createTopics(List.of(userEvents, deadLetter));
    result.all().get(30, TimeUnit.SECONDS);
}

Зміна конфігурації існуючого топіка

# Увеличиваем retention
kafka-configs.sh --bootstrap-server kafka-1:9092 \
    --alter \
    --entity-type topics \
    --entity-name user-events \
    --add-config retention.ms=1209600000

# Добавляем партиции (только увеличение!)
kafka-topics.sh --bootstrap-server kafka-1:9092 \
    --alter \
    --topic user-events \
    --partitions 24

# Внимание: добавление партиций нарушает порядок для ключевых сообщений.
# Существующие ключи пойдут в те же партиции (hash % 12),
# новые ключи будут распределяться по 24 партициям.

# Просмотр конфигурации топика
kafka-configs.sh --bootstrap-server kafka-1:9092 \
    --describe \
    --entity-type topics \
    --entity-name user-events

Управління лідерами та боротьба з перекосом

Нерівномірний розподіл лідерів між брокерами призводить до гарячих вузлів:

# Проверяем распределение лидеров
kafka-topics.sh --bootstrap-server kafka-1:9092 \
    --describe --topic user-events

# Предпочтительные реплики — перебалансировка лидеров
kafka-leader-election.sh --bootstrap-server kafka-1:9092 \
    --election-type preferred \
    --all-topic-partitions

# Или для конкретного топика через JSON
cat > election.json << 'EOF'
{
  "partitions": [
    {"topic": "user-events", "partition": 0},
    {"topic": "user-events", "partition": 1}
  ]
}
EOF

kafka-leader-election.sh --bootstrap-server kafka-1:9092 \
    --election-type preferred \
    --path-to-json-file election.json

Якщо consumer lag по одних партиціях більший, ніж по інших, перевірте ключі: погана хеш-функція дає перекос. Рішення — збільшити кількість партицій та використовувати UniformStickyPartitioner (доступний в Kafka 2.4+). Альтернатива — перейти на RoundRobinPartitioner для логування. Моніторинг партицій за допомогою kafka-consumer-groups.sh:

# Consumer lag — отставание группы
kafka-consumer-groups.sh --bootstrap-server kafka-1:9092 \
    --describe --group my-consumer-group

# Суммарный lag > 10000 для критичных топиков — повод для алерта

Типові конфігурації за типом даних

Порівняння: Kafka vs RabbitMQ для потоків даних

Apache Kafka краще RabbitMQ в 3-5× за пропускною здатністю при високому навантаженні (сотні MB/s). RabbitMQ виграє в гнучкій маршрутизації (exchanges) та підтримці черг з різними пріоритетами. Для event sourcing та CDC Kafka — стандарт де-факто; для мікросервісів зі складною маршрутизацією RabbitMQ може бути зручнішим.

Процес налаштування та таймлайн

За 5 років роботи ми провели більше 50 успішних впроваджень Kafka. Наш підхід:

• Аналіз вимог: оцінюємо throughput, кількість консьюмерів, вимоги до впорядкованості, retention. Проектуємо схему топіків. Термін — 1 день.
• Створення топіків: налаштовуємо партиції, реплікацію, compaction. Налаштовуємо ACL, якщо потрібна аутентифікація. Термін — 1–2 дні.
• Моніторинг: налаштовуємо consumer lag, алерти, документуємо схему для команди. Термін — 1 день.

Ми пропонуємо налаштування під ключ: від проектування до документації. Оцінимо ваш проект за 1 день — напишіть нам.

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

• Архітектурна документація: схема топіків, ключі, retention.
• Конфігурація брокерів та топіків.
• Налаштування моніторингу та алертів.
• Навчання команди (2–4 години).
• Підтримка протягом місяця після запуску.

Таймлайн

Правильна конфігурація партицій знижує затримки на 30% у порівнянні з неоптимальною (за нашими даними). Отримайте консультацію щодо вашого проекту — зв'яжіться з нами.

Докладніше про Apache Kafka.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.