Как перейти на Apache Kafka без Zookeeper: готовимся к KIP-500 в релизе 2.8.0

Автор Категория ,
Как перейти на Apache Kafka без Zookeeper: готовимся к KIP-500 в релизе 2.8.0

Спустя пару месяцев с выпуска Apache Kafka 2.7.0, Confluent анонсировал новый релиз этой платформы потоковой передачи событий, в котором, наконец, случится долгожданный отказ от Zookeeper. Читайте далее, как это облегчит жизнь администратору Kafka-кластера и разработчику распределенных приложений потоковой аналитики больших данных, а также как подготовить свою Big Data инфраструктуру к таким изменениям.

13 плюсов KIP-500 для администратора и разработчика Big Data

Уже совсем скоро, в марте 2021 года, ожидается новый релиз Apache Kafka 2.8.0 [1], главной фишкой которого будет долгожданный KIP-500 (Kafka Improvement Proposal) по отказу от Zookeeper, как обязательной части Кафка-кластера. Напомним, до сих пор Kafka использует сервис синхронизации распределенных систем Apache ZooKeeper для хранения метаданных, таких как расположение разделов и конфигурация топиков. Вопрос ухода от Зукипер был поднят еще в 2019 году, о чем мы писали здесь.

Удаление Зукипер из Kafka значительно упростит администрирование, благодаря сокращению объема настраиваемых служб и возможности развернуть контроллер и брокер в одной JVM. Кроме того, администратору Big Data кластера больше не придется [2]:

  • тратить время на изучение, конфигурирование, обновление и поддержку еще одной распределенной системы;
  • определять количества серверов для ансамбля Зукипер, чтобы сбалансировать емкость чтения и записи;
  • обеспечивать наличие отдельной конфигурации безопасности для Зукипер, которая отличается от остальной части Kafka-кластера;
  • обеспечивать совместное использование ансамбля Зукипер между приложениями Kafka и сторонними сервисами;
  • настраивать таймауты брокера на Зукипер через конфигурации connection.timeout.ms и zookeeper.session.timeout.ms;
  • изменять конфигурации Зукипер при добавлении новой функциональной возможности, например, для явного разрешения отдельных команд;
  • периодически перезапускать ансамбль Зукипер в рамках управления исправлениями и обновлениями;
  • подбирать оптимальный размер дорогих SSD-дисков для каждого сервера ZooKeeper;
  • настраивать политику для очистки старых данных Зукипер через purgeInterval и autopurge.snapRetainCount;
  • обеспечивать совместное использование путей к каталогам для журнала транзакций ZooKeeper и каталогов моментальных снимков (snapshot’ов).

С точки зрения разработчика Kafka-приложений при отказе новый релиз этой Big Data платформы принесет следующие преимущества [2]:

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

Как отказаться от Zookeeper на практике: план перехода на Apache Kafka 2.8.0

Чтобы использовать все вышеназванные и другие преимущества отказа от Zookeeper в новом релизе Apache Kafka 2.8.0, необходимо подготовиться к переходу на новую версию. Для этого нужно внести следующие изменения, настроив [3]:

  • клиенты, сервисы и инструменты администрирования Kafka, о чем мы поговорим далее;
  • REST Proxy API – перейти с v1 на v2 или v3;
  • получить ID Кафка-кластера, что пригодится администратору в случае мониторинга, аудита, агрегирования журналов и устранения неполадок. Ранее получить идентификатора кластера можно было из Зукипер с помощью команды zookeeper-shell: zookeeper-shell zookeeper:2181 get /cluster/id. Теперь для этого придется использовать файл журнала брокера или файл metadata.properties. При отсутствии доступа к журналам брокера, можно использовать функцию descriptionCluster() в AdminClient или инструменты администрирования Кафка с включенным ведением журнала на уровне TRACE.

Настройка клиентов, сервисов и инструментов администрирование

Здесь идет речь о клиентских приложениях (потребители и продюссеры), приложения Kafka Streams и ksqlDB, сервисы платформs Confluent (Kafka Connect, Confluent Replicator, Confluent REST Proxy, Confluent Schema Registry, Confluent Control Center или Confluent Metrics Reporter), команды CLI-интерфейса. Все они нуждаются в новой конфигурации, которая указывает, как подключиться к кластеру Кафка. В старых версиях Кафка это делалось через соединение ZooKeeper. В более новых версиях появилась возможность подключаться к брокерам вместо Зукипер. Поэтому в production-развертываниях следует проверить наличие старых клиентов или сервисов, которые настроенные для подключения к Зукипер: zookeeper.connect = zookeeper: 2181.

При переходе на Кафка 2.8.0 рекомендуется выполнить аудит всех клиентских приложений и служб, чтобы заменить вышеуказанную конфигурацию для подключения к брокерам Kafka вместо Зукипер: bootstrap.servers = брокер: 9092.

Также потребуется замена в реестре схем (Schema Registry: вместо конфигурации kafkastore.connection.url = zookeeper: 2181 нужно задать kafkastore.bootstrap.servers = broker: 9092.

Аналогично, в инструментах командной строки вместо аргумента –zookeeper с информацией о подключении Зукипер, например,

kafka-themes –zookeeper zookeeper: 2181 –create –topic test1 –partitions 1 –replication-factor 1,

будет

kafka-themes –bootstrap-server broker: 9092 –create –topic test1 –partitions 1 –replication-factor 1 –command-config

В случае защищенных кластеров с использованием SSL или SASL_SSL, инструменты администрирования требуют дополнительных настроек безопасности для подключения к брокерам, в частности, аргумент –command-config, чтобы указать на файл свойств соединения AdminClient.

Краткий перечень мероприятий по отказу от Зукипер показан далее в таблице.

Действие С ZooKeeper Без ZooKeeper
Настройка клиентов и сервисов zookeeper.connect=zookeeper:2181 bootstrap.servers=broker:9092
Конфигурирование Schema Registry kafkastore.connection.url=zookeeper:2181 kafkastore.bootstrap.servers=broker:9092
Настройка инструментов администрирования kafka-topics –zookeeper zookeeper:2181 … kafka-topics –bootstrap-server broker:9092 … –command-config <properties to connect to brokers>
REST Proxy API v1 v2 or v3
Получение идентификатора Кафка-кластера (Kafka cluster ID) zookeeper-shell zookeeper:2181 get /cluster/id kafka-metadata-quorum or view metadata.properties or confluent cluster describe –url http://broker:8090 –output json

 

Дополнительно к вышеотмеченным подготовительным мероприятиям по отказу от Зукипер, при развертывании Apache Kafka 2.8.0 администратору кластера нужно сделать следующее [3]:

  • проверить конфигурации и клиентские инструменты, чтобы определить все параметры и аргументы ZooKeeper;
  • определить возможные зависимости Зукипер в порядке запуска сервиса. Например, при использовании Docker, следует проверить конфигурацию depends_on, чтобы увидеть, где контейнер ZooKeeper является необходимым условием.
  • Найти косвенные зависимости ZooKeeper, такие как модули Runbook, которые используют Зукипер в качестве узла перехода для выполнения команд на другом узле.

Что еще нового вас ожидает в релизе Apache Kafka 2.8.0, читайте в нашей свежей статье.

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

 

 

Источники

  1. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=173081737
  2. https://www.confluent.io/blog/42-ways-zookeeper-removal-improves-kafka/
  3. https://www.confluent.io/blog/how-to-prepare-for-kip-500-kafka-zookeeper-removal-guide/