KRaft

KRaft — это протокол управления кластером (консенсусный протокол), используемый в распределённой системе Apache Kafka. Он предназначен для замены Apache ZooKeeper в качестве службы координации и хранения метаданных кластера Kafka. KRaft обеспечивает единый механизм управления состоянием кластера, включая выбор лидера, хранение конфигураций и отслеживание членства брокеров, без необходимости в отдельной внешней системе.

История

Протокол KRaft был разработан командой Apache Kafka как ответ на ограничения, связанные с зависимостью от ZooKeeper. ZooKeeper, будучи зрелой распределённой системой, создавал дополнительные сложности в эксплуатации: требовал отдельного развёртывания, настройки и мониторинга. Кроме того, архитектура с двумя системами (Kafka и ZooKeeper) увеличивала задержки при операциях с метаданными и усложняла процесс восстановления после сбоев.

Разработка KRaft началась в 2020 году в рамках проекта KIP-500 (Kafka Improvement Proposal 500). Первая экспериментальная версия протокола была включена в релиз Apache Kafka 2.8 (апрель 2021 года). В последующих версиях (3.0, 3.1, 3.2) функциональность KRaft постепенно стабилизировалась. Начиная с Apache Kafka 3.3 (октябрь 2022 года), KRaft получил статус «production-ready» (готов к промышленному использованию) для новых кластеров. В версии Apache Kafka 3.5 (май 2023 года) была добавлена поддержка миграции существующих кластеров, работающих с ZooKeeper, на KRaft без остановки системы.

Архитектура и принцип работы

KRaft основан на модифицированной версии алгоритма консенсуса Raft. В отличие от классического Raft, в KRaft используется понятие «контроллеров» (controllers), которые образуют кворум (quorum) для принятия решений. Каждый контроллер хранит полную копию лога метаданных — последовательности записей, описывающих состояние кластера (топики, разделы, конфигурации, членство брокеров).

Компоненты

• Контроллеры (controllers): узлы, отвечающие за управление кластером. Один из контроллеров является активным лидером, остальные — пассивными последователями. Лидер обрабатывает все запросы на изменение метаданных (создание/удаление топиков, изменение конфигураций, назначение лидеров разделов) и реплицирует изменения на последователей.
• Брокеры (brokers): узлы, хранящие данные (сообщения) и обслуживающие запросы клиентов (продюсеров и консюмеров). Брокеры взаимодействуют с контроллерами для получения актуальной информации о метаданных.
• Лог метаданных (metadata log): упорядоченная последовательность записей, каждая из которых представляет собой атомарное изменение состояния кластера. Лог реплицируется между контроллерами и обеспечивает согласованное состояние.
• Кворум (quorum): минимальное количество контроллеров, необходимое для принятия решения (обычно большинство — N/2+1). Если лидер выходит из строя, последователи проводят выборы нового лидера.

Процесс управления

1. Выбор лидера: при запуске или потере лидера контроллеры проводят выборы с использованием механизма тайм-аутов и голосования. Выбранный лидер получает эксклюзивное право на запись в лог метаданных.
2. Обработка запросов: все изменения метаданных (например, создание топика) направляются лидеру контроллера. Лидер записывает изменение в свой локальный лог и реплицирует его на последователей. После подтверждения от кворума изменение считается зафиксированным.
3. Распространение метаданных: лидер контроллера периодически отправляет брокерам снимок (snapshot) текущего состояния метаданных или инкрементальные обновления. Брокеры используют эти данные для маршрутизации запросов клиентов.

Преимущества перед ZooKeeper

• Упрощение архитектуры: устранение необходимости в отдельном кластере ZooKeeper снижает сложность развёртывания и эксплуатации. Для работы кластера Kafka теперь требуется только один набор узлов.
• Снижение задержек: операции с метаданными выполняются быстрее, так как не требуется взаимодействие между двумя распределёнными системами. Время создания топика или переключения лидера раздела сокращается.
• Масштабируемость: KRaft способен обрабатывать большее количество изменений метаданных в секунду, что важно для крупных кластеров с тысячами топиков и разделов.
• Улучшенное восстановление: при сбое контроллера выборы нового лидера происходят быстрее и с меньшим риском потери данных, так как все контроллеры хранят полную копию лога метаданных.
• Безопасность: KRaft поддерживает шифрование и аутентификацию для внутреннего трафика между контроллерами, что повышает защиту метаданных.

Недостатки и ограничения

• Зрелость: хотя KRaft объявлен production-ready, многие крупные организации продолжают использовать ZooKeeper из-за его многолетней проверки в эксплуатации. Возможны скрытые проблемы, проявляющиеся только при специфических нагрузках.
• Сложность миграции: для существующих кластеров переход с ZooKeeper на KRaft требует тщательного планирования и может быть сопряжён с рисками. Инструменты миграции появились только в версии 3.5.
• Требования к ресурсам: контроллеры KRaft потребляют больше ресурсов (память, CPU) по сравнению с ZooKeeper, так как хранят полный лог метаданных и участвуют в консенсусе.
• Ограниченная поддержка старых версий: для использования KRaft требуется Apache Kafka версии не ниже 2.8, что может быть проблемой для организаций, использующих устаревшие дистрибутивы.

Применение

KRaft рекомендуется для новых развёртываний Apache Kafka, особенно в средах, где важна простота управления и высокая скорость операций с метаданными. Он также подходит для сценариев, где требуется быстрое масштабирование кластера или автоматическое восстановление после сбоев. Крупные компании, такие как Confluent (разработчик коммерческой версии Kafka), активно продвигают KRaft как стандартный способ управления кластерами в своих облачных сервисах.

Версии и совместимость

• Apache Kafka 2.8 – 3.1: экспериментальная поддержка KRaft (только для тестовых кластеров).
• Apache Kafka 3.2 – 3.3: улучшение стабильности, добавление поддержки сжатия лога метаданных.
• Apache Kafka 3.3 – 3.4: статус production-ready для новых кластеров (без миграции).
• Apache Kafka 3.5 и выше: поддержка миграции с ZooKeeper на KRaft, улучшение производительности и мониторинга.

Критика и перспективы

Основная критика KRaft связана с тем, что он не решает всех проблем, присущих ZooKeeper, а лишь заменяет одну распределённую систему на другую. Некоторые эксперты отмечают, что консенсусный протокол Raft, на котором основан KRaft, может быть избыточным для управления метаданными в небольших кластерах. Однако сообщество Apache Kafka считает, что унификация архитектуры и снижение зависимости от внешних систем оправдывают переход.

В будущем ожидается полное удаление поддержки ZooKeeper из Apache Kafka. В версии 4.0 (планируется на 2024–2025 годы) ZooKeeper будет объявлен устаревшим, а KRaft станет единственным способом управления кластером. Это позволит упростить код Kafka и ускорить внедрение новых функций.

Источники

• KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum (Apache Kafka Wiki)
• Apache Kafka Documentation: KRaft (Apache Software Foundation)
• «Kafka: The Definitive Guide» (2nd edition), Neha Narkhede, Gwen Shapira, Todd Palino (O'Reilly Media, 2021)
• «Apache Kafka 3.3 Release Notes» (Apache Kafka Project)
• «Migrating from ZooKeeper to KRaft» (Confluent Documentation)