Налаштування кластера 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 залишається для легасі, але ми не рекомендуємо починати з нього.
| Параметр | KRaft | ZooKeeper |
|---|---|---|
| Компоненти | Тільки Kafka | Kafka + ZooKeeper (3-5 вузлів) |
| Простота | Один бінарник, менше конфігів | Два різні кластери, координація |
| Відновлення | Швидше за рахунок внутрішнього кворуму | Залежить від ZooKeeper |
| Масштабування | Легше, немає зовнішньої залежності | Складніше (ZooKeeper може стати вузьким місцем) |
| Production-ready | Починаючи з версії 3.3 (рекомендуємо актуальну стабільну) | Стабільний, але legacy |
Джерело: офіційна документація 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 вище порогу. Зв'яжіться з нами для впровадження моніторингу та отримання готових дашбордів під ваше навантаження.
Як забезпечити відмовостійкість?
- Створіть тестовий топік з реплікацією 3.
- Вимкніть один брокер і перевірте, що продюсери не втрачають дані (при acks=all та min.insync.replicas=2).
- Увімкніть брокер назад і переконайтеся, що репліки синхронізувалися.
- Перевірте consumer lag — він має повернутися до нуля.
- Повторіть з кожним брокером.
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% для вашого кластера. Замовте розгортання — зв'яжіться з нами для консультації. Отримайте попередню оцінку вартості та термінів.
Процес роботи та терміни
| Етап | Тривалість |
|---|---|
| Аналіз вимог та проєктування архітектури | 1-2 дні |
| Встановлення та налаштування кластера (3 вузли) | 2-3 дні |
| Налаштування TLS та безпеки | 1 день |
| Інтеграція моніторингу (Prometheus + Grafana) | 1 день |
| Тестування відмовостійкості та навантаження | 1-2 дні |
| Документація та навчання команди | 1 день |
Разом: 5-7 робочих днів для базового кластера. Вартість розраховується індивідуально.
Що входить в роботу
- Проєктування архітектури кластера (ролі, партиції, реплікація)
- Встановлення та налаштування Kafka в режимі KRaft
- Налаштування TLS між брокерами та клієнтами
- Впровадження моніторингу (JMX Exporter + Prometheus + Grafana)
- Створення продуктивних топіків з оптимальними параметрами
- Навантажувальне тестування та перевірка відмовостійкості
- Документація (схема кластера, інструкції, runbook)
- Навчання вашої команди (основи адміністрування, робота з CLI)
- Технічна підтримка 2 тижні після запуску
Результати та гарантії
Понад 30 впроваджених кластерів з навантаженням до 1 млн повідомлень на секунду. Середнє зниження витрат на інфраструктуру — 35%. Час окупності — до 6 місяців. Зверніться до наших інженерів — ми допоможемо налаштувати кластер під ваше навантаження.