Не только KIP-500: 15 важных улучшений Apache Kafka 2.8.0

KIP-500, который позволяет наконец-то избавиться от Zookeeper в кластере Apache Kafka, заменив его Quorum Controller – далеко не единственное важное обновление в релизе 2.8.0. Сегодня рассмотрим, какие еще улучшения реализованы в новой версии главной Big Data платформы потоковой обработки событий, выпущенной в апреле 2021 года.

Apache Kafka 2.8.0: новинки главных 18-ти KIP’ов

Замена Zookeeper самоуправляемым кворумом метаданных реализована не только в рамках широко известного KIP-500, но также отражена в следующих предлагаемых улучшениях Kafka (KIP, Kafka Improvement Proposal) [1]:

• KIP-595 – определяет протокол Raft для внутреннего топика @metadata, который содержит метаданные и конфигурации топиков вместо Zookeeper;
• KIP-631 – определяет управляемую событиями модель контроллера, включая новый жизненный цикл брокера и схемы записи метаданных;
• KIP-590 – определяет новый протокол, позволяющий пересылать клиентские запросы от брокеров к контроллеру.

Кроме этих KIP’ов для исключения Zookeeper из кластера Apache Kafka, новый релиз богат на улучшения разных компонентов платформы:

• 6 улучшений для брокеров, продюсеров и потребителей;
• 1 новая фича в Kafka Connect в рамках KIP-661;
• 7 добавлений в Kafka Streams.

Что именно представляет собой каждое из реализованных улучшений, мы рассмотрим далее.

6 KIP для брокеров, продюсеров и потребителей

Ключевые обновления Apache Kafka 2.8.0 включают следующие обновления относительно брокеров, прод.серов и потребителей сообщений [1]:

• KIP-700 – добавление API для описания кластера. Раньше, чтобы получить информацию о кластере, клиент администратора AdminClient Kafka использовал API метаданных брокера, который прежде всего ориентирован на поддержку клиентов (потребителя и производителя). Producer и Connsumer следуют другим шаблонам, чем AdminClient. KIP-700 отделяет AdminClient от API метаданных, позволяя администратору Kafka напрямую запрашивать у брокеров информацию о кластере без ущерба для производителя и потребителя. Подробнее о том, что такое AdminClient, когда его использовать и как, читайте в нашей новой статье. О другом новом API, полезном для администратора кластера, мы рассказываем здесь.
• KIP-684 — поддержка взаимной аутентификации TLS на слушателях SASL_SSL. Исторически Kafka отключала аутентификацию клиента TLS (mutual TLS authentication) для слушателей SASL_SSL, даже при настройке ssl.client.auth для всего брокера. Чаще всего, при использовании аутентификации SASL без необходимости распространения хранилища ключей, принудительная аутентификация клиента TLS для клиентов SASL_SSL нежелательна. Поэтому KIP-684 позволяет комбинировать аутентификацию TLS с идентификацией клиента на основе SASL для каждого слушателя. Это полезно для компаний со строгими правилами корпоративной безопасности, в частности, с обязательной взаимной проверкой подлинности TLS. KIP-684 основан на параметрах конфигурации с префиксом слушателя на базе решений из KIP-103, где предлагается разделение внешнего и внутреннего трафика [2].
• KIP-676 – иерархия ведения журналов. Библиотека логирования Java-программ Log4j использует иерархическую модель для настройки логирующих регистраторов в приложении. Уровни иерархии определяются разделяющими знаками в имени регистратора. Если отдельный регистратор не настроен явно, он наследует конфигурацию вышестоящего. Исторически сложилось так, что API-интерфейсы брокера Kafka для просмотра уровней журнала не соблюдали эту иерархию, сообщая только о конфигурации корневого регистратора для любого ненастроенного индивидуального регистратора. KIP-676 исправляет это, представляя конфигурации регистратора аналогично структуре ведения журнала.
• KIP-673 – создание JSON с новой автоматически сгенерированной схемой. Брокеры Kafka предлагают логи запросов/ответов на уровне отладки вместо полуструктурированных журналов, создаваемых переопределением toString классов запроса/ответа. KIP-673 настраивает логи, структурируя их в формате JSON, чтобы их было легче анализировать и использовать с помощью инструментальных средств ведения журналов.
• KIP-612 – ограничение скорости создания подключений к брокеру, чтобы повысить стабильность Big Data системы и уберечь ее от роста накладных расходов при множестве новых соединений, включая запросы от авторизованных клиентов. KIP-612 позволяет устанавливать ограничение на скорость, с которой брокер принимает новые соединения, как в целом, так и на отдельные IP-адреса.
• KIP-516 – идентификаторы топиков. Теперь в Apache Kafka8.0 топики определяются не только по названию, а на основании уникальных id, которые отличаются друг от друга на протяжении всего их существования. По сравнению с названиями топиков, идентификаторы более эффективны с точки зрения сетевой передачи и хранения в памяти. Клиенты могут получать идентификаторы топиков в ответах на запросы метаданных.

Улучшения Kafka Connect: отображение конфигураций задач в REST API с KIP-661

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

KIP-661 добавляет новую конечную точку API и метод tasksConfig(String connName, Callback<Map<ConnectorTaskId, Map<String, String>>> callback), позволяющий вызывающим абонентам получать фактическую конфигурацию времени выполнения задач соединителя.

Новая конечная точка Connect REST API: / {connector} / tasks-config, доступна через GET-запрос и возвращает конфигурацию всех задач для коннектора. Это полезно для разработчиков в режиме отладки и помогает администраторам Kafka-кластера понять, на что и в каком объеме влияет сбой отдельной задачи [3].

Завтра мы продолжим разбирать важные обновления релиза 2.8.0 и рассмотрим, какие KIP’ы делают Kafka Streams еще удобнее и эффективнее для потоковой обработки событий.

Больше деталей об администрировании кластеров Apache Kafka и разработке распределенных приложений потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

• Apache Kafka для разработчиков
• Администрирование кластера Kafka
• Администрирование кластера Kafka 

1. https://blogs.apache.org/kafka/entry/what-s-new-in-apache5
2. https://cwiki.apache.org/confluence/display/KAFKA/KIP-103%3A+Separation+of+Internal+and+External+traffic
3. https://cwiki.apache.org/confluence/display/KAFKA/KIP-661%3A+Expose+task+configurations+in+Connect+REST+API