Налаштування кластера Apache Kafka для веб-додатку

Налаштування кластера Apache Kafka для веб-додатку

Уявіть: ваш веб-додаток обробляє тисячі замовлень на хвилину. Кожна подія — надсилання email, оновлення пошукового індексу, синхронізація даних — виконується синхронно. Сервери задихаються, latency зростає, а при збої губляться дані. Apache Kafka вирішує ці проблеми, але неправильне налаштування кластера (наприклад, один брокер з реплікацією factor=1) призводить до катастрофи. Один із наших клієнтів — e-commerce платформа з 500 000 подій на секунду — перейшов на Kafka після того, як RabbitMQ перестав справлятися з піками.

Kafka — розподілений лог з гарантіями впорядкованості та реплікації. Він розв'язує сервіси, забезпечує аудит-лог та real-time аналітику. Продакшен-кластер вимагає ретельного налаштування: вибір режиму, конфігурація брокерів, безпека та моніторинг. Наша команда запустила понад 30 кластерів для highload проєктів — від фінтеху до e-commerce. Правильна конфігурація знижує витрати на інфраструктуру до 40% порівняно з альтернативами, а час окупності не перевищує півроку.

Як налаштувати кластер Apache Kafka: вибір режиму KRaft чи ZooKeeper?

Для нових проєктів використовуйте лише KRaft (без ZooKeeper). З версії, де KRaft production-ready, він спрощує архітектуру, зменшує кількість точок відмови та прискорює відновлення. ZooKeeper залишається для легасі, але ми не рекомендуємо починати з нього.

Джерело: офіційна документація Kafka

Встановлення та конфігурація на Ubuntu

Встановлюємо останню стабільну версію, налаштовуємо системний сервіс та ініціалізуємо сховище:

apt install -y openjdk-21-jdk-headless
KAFKA_VERSION=3.7.0
SCALA_VERSION=2.13
wget https://downloads.apache.org/kafka/${KAFKA_VERSION}/kafka_${SCALA_VERSION}-${KAFKA_VERSION}.tgz
tar -xzf kafka_${SCALA_VERSION}-${KAFKA_VERSION}.tgz -C /opt/
ln -s /opt/kafka_${SCALA_VERSION}-${KAFKA_VERSION} /opt/kafka
useradd -r -s /bin/false kafka
chown -R kafka:kafka /opt/kafka
mkdir -p /var/log/kafka /data/kafka
chown kafka:kafka /var/log/kafka /data/kafka
cat > /etc/systemd/system/kafka.service << 'EOF'
[Unit]
Description=Apache Kafka
After=network.target
[Service]
Type=simple
User=kafka
Environment="KAFKA_HEAP_OPTS=-Xmx4g -Xms4g"
Environment="KAFKA_JVM_PERFORMANCE_OPTS=-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true"
ExecStart=/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/kraft/server.properties
ExecStop=/opt/kafka/bin/kafka-server-stop.sh
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
EOF
CLUSTER_UUID=$(kafka-storage.sh random-uuid)
kafka-storage.sh format -t $CLUSTER_UUID -c /opt/kafka/config/kraft/server.properties

Для підготовки конфігурації під ваш проєкт зв'яжіться з нами.

Конфігурація KRaft на кожному вузлі (приклад для вузла 1; для вузлів 2 та 3 змініть node.id та advertised.listeners):

node.id=1
process.roles=broker,controller
controller.quorum.voters=1@kafka-1:9093,2@kafka-2:9093,3@kafka-3:9093
listeners=PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093
advertised.listeners=PLAINTEXT://kafka-1.internal:9092
inter.broker.listener.name=PLAINTEXT
controller.listener.names=CONTROLLER
listener.security.protocol.map=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT
log.dirs=/data/kafka
num.recovery.threads.per.data.dir=4
num.io.threads=16
num.network.threads=8
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
socket.request.max.bytes=104857600
default.replication.factor=3
min.insync.replicas=2
num.partitions=6
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=2
log.retention.hours=168
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
compression.type=lz4

Налаштування TLS між брокерами

Без TLS трафік передається у відкритому вигляді. Для захисту використовуйте власний CA та сертифікати для кожного брокера. Детальні інструкції з генерації сертифікатів надамо в рамках проєкту.

Додайте в server.properties на кожному брокері:

listeners=PLAINTEXT://0.0.0.0:9092,SSL://0.0.0.0:9094,CONTROLLER://0.0.0.0:9093
ssl.keystore.location=/etc/kafka/ssl/kafka-1.keystore.jks
ssl.keystore.password=changeit
ssl.key.password=changeit
ssl.truststore.location=/etc/kafka/ssl/kafka.truststore.jks
ssl.truststore.password=changeit
ssl.client.auth=required
ssl.enabled.protocols=TLSv1.3,TLSv1.2

Моніторинг: ключові метрики та алерти

Відстежуйте under-replicated partitions, активність контролера, p99 затримки продюсера/консьюмера, consumer lag. Для збору використовуйте JMX Exporter + Prometheus, для візуалізації — Grafana. Приклад конфігурації JMX Exporter:

startDelaySeconds: 0
hostPort: 127.0.0.1:9999
lowercaseOutputName: true
rules:
  - pattern: kafka.server<type=BrokerTopicMetrics, name=MessagesInPerSec><>OneMinuteRate
    name: kafka_server_broker_topic_messages_in_per_sec
  - pattern: kafka.server<type=ReplicaManager, name=UnderReplicatedPartitions><>Value
    name: kafka_server_under_replicated_partitions
  - pattern: kafka.controller<type=KafkaController, name=ActiveControllerCount><>Value
    name: kafka_controller_active_count
  - pattern: kafka.network<type=RequestMetrics, name=TotalTimeMs, request=Produce><>99thPercentile
    name: kafka_network_produce_total_time_ms_p99

Ключові алерти: kafka_server_under_replicated_partitions > 0, kafka_controller_active_count != 1, consumer lag вище порогу. Зв'яжіться з нами для впровадження моніторингу та отримання готових дашбордів під ваше навантаження.

Як забезпечити відмовостійкість?

1. Створіть тестовий топік з реплікацією 3.
2. Вимкніть один брокер і перевірте, що продюсери не втрачають дані (при acks=all та min.insync.replicas=2).
3. Увімкніть брокер назад і переконайтеся, що репліки синхронізувалися.
4. Перевірте consumer lag — він має повернутися до нуля.
5. Повторіть з кожним брокером.

kafka-topics.sh --bootstrap-server kafka-1:9092 --create --topic test-topic --partitions 6 --replication-factor 3
kafka-producer-perf-test.sh --topic test-topic --num-records 1000000 --record-size 1024 --throughput -1 --producer-props bootstrap.servers=kafka-1:9092,kafka-2:9092,kafka-3:9092 acks=all compression.type=lz4
kafka-consumer-perf-test.sh --bootstrap-server kafka-1:9092 --topic test-topic --messages 1000000 --group perf-test-group

Гарантуємо SLA 99.99% для вашого кластера. Замовте розгортання — зв'яжіться з нами для консультації. Отримайте попередню оцінку вартості та термінів.

Процес роботи та терміни

Разом: 5-7 робочих днів для базового кластера. Вартість розраховується індивідуально.

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

• Проєктування архітектури кластера (ролі, партиції, реплікація)
• Встановлення та налаштування Kafka в режимі KRaft
• Налаштування TLS між брокерами та клієнтами
• Впровадження моніторингу (JMX Exporter + Prometheus + Grafana)
• Створення продуктивних топіків з оптимальними параметрами
• Навантажувальне тестування та перевірка відмовостійкості
• Документація (схема кластера, інструкції, runbook)
• Навчання вашої команди (основи адміністрування, робота з CLI)
• Технічна підтримка 2 тижні після запуску

Результати та гарантії

Понад 30 впроваджених кластерів з навантаженням до 1 млн повідомлень на секунду. Середнє зниження витрат на інфраструктуру — 35%. Час окупності — до 6 місяців. Зверніться до наших інженерів — ми допоможемо налаштувати кластер під ваше навантаження.

Послуги бекенд-розробки: 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% без втрати продуктивності.