Redpanda убирает JVM и ZooKeeper — считаем, чем за это платят

MAATRIX

Каждый, кто хоть раз поднимал Kafka на своём сервере, помнит этот момент: отдельный процесс под ZooKeeper, отдельная настройка heap для JVM, отдельная настройка page cache, чтобы JVM не съела всю память под себя. Redpanda обещает убрать это одним движением — брокер на C++ без JVM и без ZooKeeper, совместимый с Kafka по протоколу на уровне клиентов. Звучит как бесплатный обед, а бесплатных обедов не бывает: разбираем, что вы реально выигрываете в администрировании и ресурсах и чем за это расплачиваетесь в зрелости экосистемы и мониторинга.

Что такое Redpanda на самом деле

Redpanda — не форк Kafka и не обёртка над ней, а брокер сообщений, написанный с нуля на C++ поверх фреймворка Seastar (того же, что лежит в основе ScyllaDB). Ключевая идея — thread-per-core: каждое ядро CPU обслуживает свой шард данных и свою очередь ввода-вывода, без блокировок между потоками и без сборщика мусора, который время от времени останавливает мир у JVM-приложений.

Вместо ZooKeeper для хранения метаданных кластера (топики, партиции, ISR, конфигурация) Redpanda использует встроенный Raft-консенсус — тот же протокол, что реплицирует сами партиции с данными. У кластера один механизм консенсуса на всё, а не два разных (ISR у Kafka для данных и ZAB у ZooKeeper для метаданных). Практически это означает: один бинарник redpanda, один процесс на ноде — и никакого отдельного трёхнодового ZooKeeper-ансамбля, который нужно разворачивать, патчить и мониторить самостоятельно.

Важный нюанс с самого начала: Redpanda совместима с Kafka на уровне wire-протокола — того же, которым говорят клиентские библиотеки (librdkafka, kafka-python, Sarama, клиенты для Java/Go/Node). Она не воспроизводит внутреннее устройство Kafka один в один, поэтому инструменты, завязанные на внутренние детали реализации именно Kafka (JMX-метрики брокера, формат файлов сегментов), могут вести себя иначе или не работать вовсе. Для обычного продюсера и консьюмера разницы почти нет — и это главный аргумент в пользу Redpanda.

Установка и первый запуск на VPS

Redpanda ставится проще, чем Kafka: один пакет, один сервис в systemd, конфиг в человекочитаемом YAML. Официальный способ — через репозиторий пакетов вендора (актуальный скрипт установки — на странице загрузок redpanda.com, он периодически обновляется, поэтому URL здесь не привожу) или через готовый .deb/.rpm пакет. После установки Redpanda сразу регистрируется как systemd-юнит:

systemctl status redpanda

Для one-node инсталляции на VPS достаточно инициализировать конфиг через rpk — родной CLI-инструмент Redpanda, который заменяет собой добрый десяток консольных утилит Kafka (kafka-topics.sh, kafka-console-producer.sh и так далее одной командой с подкомандами):

sudo rpk redpanda config bootstrap --self <ip-сервера> --default
sudo systemctl start redpanda

Основной конфиг лежит в /etc/redpanda/redpanda.yaml и выглядит примерно так для одиночной ноды:

redpanda:
  data_directory: /var/lib/redpanda/data
  node_id: 0
  rpc_server:
    address: 0.0.0.0
    port: 33145
  kafka_api:
    - address: 0.0.0.0
      port: 9092
  admin:
    - address: 0.0.0.0
      port: 9644
  developer_mode: false

Порт 9092 — тот же, что у Kafka: любой Kafka-клиент подключается к Redpanda, просто указав адрес и порт сервера. Порт 9644 — админ-API и заодно endpoint для Prometheus-метрик (/metrics и /public_metrics). Отдельно можно включить HTTP-прокси (Pandaproxy, порт 8082) для REST-доступа к топикам и Schema Registry (порт 8081) — обе фичи встроены в тот же бинарник, а не требуют разворачивать Confluent Schema Registry отдельным Java-процессом.

Проверка, что кластер жив и топики создаются:

rpk cluster info
rpk topic create events --partitions 6 --replicas 1
rpk topic produce events
rpk topic consume events --num 5

Никакого отдельного шага «сначала подними ZooKeeper, потом брокер, потом проверь, что они друг друга видят» — кластер метаданных живёт внутри тех же процессов Redpanda, которые обслуживают данные.

Совместимость с Kafka API: что действительно работает

Практика показывает: для большинства типовых сценариев — продюсеры и консьюмеры на стандартных клиентских библиотеках, consumer groups, exactly-once на уровне протокола, партиционирование, compaction топиков — Redpanda подменяет Kafka прозрачно. Приложение на kafka-python, confluent-kafka (обёртка над librdkafka) или клиенте для Spring/Go просто переключает адрес брокера и работает.

Там, где начинаются нюансы:

• Kafka Connect. Redpanda поддерживает Kafka Connect как внешний компонент (сам Connect-воркер — отдельный Java-процесс, который умеет говорить с любым Kafka-совместимым брокером), так что готовые коннекторы в основном заводятся. Но часть коннекторов из экосистемы Confluent написана с оглядкой на специфичное поведение именно Kafka-брокера и не тестировалась вендорами против Redpanda — состояние конкретного коннектора стоит проверять отдельно, а не считать гарантированным.
• ksqlDB и Kafka Streams. Формально работают поверх Kafka-протокола и в целом совместимы, но это не первостепенный сценарий для Redpanda, и глубоких проверок на специфичных для Streams паттернах (state stores, интерактивные запросы) меньше, чем на классической Kafka.
• Внутренние админ-инструменты. Утилиты, которые лезут напрямую в ZooKeeper или парсят бинарный формат сегментов Kafka, с Redpanda не работают — у неё свой формат хранения на диске.
• JMX-метрики. Kafka экспортирует метрики через JMX, и вокруг него выстроена гигантская экосистема готовых Grafana-дашбордов, Datadog- и New Relic-интеграций. У Redpanda JMX нет по определению — метрики отдаются в формате Prometheus нативно, без JVM-прослойки, но под старые Kafka-дашборды они не подходят один в один.

Для новых проектов, где вы сами пишете и продюсеров, и консьюмеров, несовместимость почти не ощущается. Для миграции существующего Kafka-хозяйства с обвязкой из Connect-коннекторов и готовых дашбордов стоит закладывать время на тестовый прогон каждого компонента отдельно.

Ресурсы: где реальная экономия, а где маркетинг

Главный источник экономии — не в том, что Redpanda «магически быстрее» перемалывает байты, а в том, что она убирает удвоение памяти, характерное для JVM-стека. У классической Kafka память делится на heap JVM (структуры брокера — метаданные партиций, буферы, кэши) и page cache операционной системы, куда Linux кэширует файлы сегментов лога. Это две разные, слабо пересекающиеся области, и настройка heap — отдельная тонкая работа: маленький heap — паузы GC под нагрузкой, слишком большой — меньше остаётся для page cache. Подробно эта арифметика разобрана в статье про то, сколько RAM нужно для Kafka.

У Redpanda такого раздвоения нет: единственный процесс сам управляет памятью под данные и под кэш, без отдельного heap и без сборщика мусора, который может внезапно поставить брокер на паузу под нагрузкой. Вторая статья экономии — отсутствие ZooKeeper-ансамбля: production-инсталляция Kafka с ZooKeeper обычно означает 3-5 дополнительных нод, которые тоже едят RAM, диск под снапшоты и требуют отдельного мониторинга кворума. У Redpanda этого компонента нет физически.

Цифры вида «Redpanda быстрее Kafka на X%» из маркетинговых материалов переносить на свой случай не стоит — выигрыш сильно зависит от профиля нагрузки, числа партиций, размера сообщений и железа. Надёжный способ понять цифры для своей задачи — прогнать нагрузочный тест (стандартные утилиты вроде kafka-producer-perf-test работают через Kafka-протокол и годятся для Redpanda тоже) на копии продовой нагрузки на тестовом VPS, а не верить чужим графикам.

Практический ориентир: там, где для кластера Kafka+ZooKeeper вы закладывали бы отдельные ресурсы под JVM-heap брокера и под ZooKeeper-ноды, для Redpanda того же уровня нагрузки хватает одного процесса без бюджета под второй компонент — но точные цифры RAM и CPU под конкретный объём сообщений стоит проверять нагрузочным тестом, а не брать по аналогии.

Мониторинг и наблюдаемость: что теряете по сравнению с Kafka

Здесь начинается та часть, за которую действительно платите. У Kafka за годы эксплуатации собралась огромная библиотека готовых Grafana-дашбордов, отработанных алертов на конкретные JMX-метрики (UnderReplicatedPartitions, RequestQueueSize, лаг consumer-групп через Burrow) и статей, разбирающих буквально любую аномалию — от «брокер завис на ребалансе» до «диск раздулся, потому что сегменты не удаляются вовремя» (реальный кейс с таким разбором есть в статье о том, как Kafka не удаляла сегменты и забила диск за выходные).

У Redpanda метрики Prometheus-native и проще для сбора — не нужен JMX-exporter как промежуточный слой, только curl http://localhost:9644/metrics. Вендор поставляет официальные Grafana-дашборды и Redpanda Console — встроенную веб-панель для просмотра топиков, консьюмеров и здоровья кластера без сторонних инструментов вроде Kafdrop. Но готовых community-дашбордов, разборов конкретных инцидентов и накопленного коллективного опыта на порядок меньше — Redpanda моложе, и community вокруг неё меньше. Если возникнет нетипичная проблема, есть неплохой шанс, что вы окажетесь одним из первых, кто её описывает, а не найдёте готовый ответ за пять минут поиска.

Практический совет: если переходите на Redpanda в проде, закладывайте время на настройку алертов под собственные метрики Redpanda (redpanda_kafka_*, under-replicated партиции, RPC-задержки — готовых универсальных алертов меньше) и на прогон типовых сценариев отказа (падение ноды, отставание консьюмера, заполнение диска) на тестовом стенде заранее — не полагайтесь, что найдёте готовый runbook в момент инцидента, как это часто получается с Kafka.

Экосистема, коннекторы и лицензия: где Kafka всё ещё сильнее

Apache Kafka существует больше десяти лет, распространяется под полностью открытой лицензией Apache 2.0 и оброс экосистемой, которую физически невозможно повторить за пару лет: сотни готовых коннекторов Kafka Connect для баз данных, очередей, облачных хранилищ и SaaS-сервисов; зрелые клиентские библиотеки, обкатанные на огромных нагрузках; Kafka Streams и ksqlDB для потоковой обработки прямо поверх брокера; коммерческая поддержка от нескольких независимых вендоров, а не одного.

Redpanda сознательно делает ставку на совместимость с протоколом, чтобы наследовать часть экосистемы бесплатно — и во многом это работает. Но часть инструментов и практик, завязанных именно на Kafka как реализацию, придётся либо заменять аналогами из мира Redpanda, либо проверять руками перед тем, как полагаться на них в проде.

Отдельный момент — лицензия. Apache Kafka распространяется под Apache License 2.0 без ограничений на коммерческое использование. Redpanda распространяет ядро под source-available лицензией собственного производства (не Apache 2.0), которая ограничивает, в частности, предложение Redpanda как управляемого облачного сервиса конкурентами. Для самостоятельного хостинга на своём VPS это практически не создаёт проблем, но если у компании есть юридические требования именно к permissive open source лицензиям, условия стоит перечитать на сайте вендора перед принятием решения — формулировки и пороги применения периодически меняются.

Соседняя категория инструментов, которую легко перепутать с Kafka/Redpanda: если нужна не история событий с повторным чтением, а классическая очередь задач с гарантированной доставкой и гибкой маршрутизацией — присмотритесь к RabbitMQ. Это другой класс инструмента (брокер очередей «доставлено и удалено» против распределённого журнала событий), а не альтернатива в том же сравнении.

Когда брать Redpanda, а когда остаться на Kafka

Если сомневаетесь — разверните оба варианта на тестовых VPS и прогоните свою реальную нагрузку хотя бы неделю. Установка Kafka с нуля описана в статье как установить и настроить Kafka на VPS — вместе с материалом про сравнение NATS и Kafka это даёт полную картину альтернатив, если Redpanda в итоге не подойдёт по совместимости.

Частые вопросы