Почему нельзя просто взять и удалить топик Apache Kafka: что проверить и перенастроить, с помощью каких инструментов и чем можно обойтись вместо непосредственного удаления.
Проблемы удаления топика Apache Kafka и их решения
Когда у вас есть собственный инстанс или даже кластер Apache Kafka с полными правами на все манипуляции с топиками, вопрос о трудностях их создания или удаления даже не стоит. Однако, в корпоративной среде, когда Kafka используется в качестве платформенного решения межсервисной интеграции, такие операции администрирования находятся в области ответственности платформенных инженеров. Эти же специалисты следят за набором и состоянием существующих топиков и удаляют те, которые больше не используются. При этом можно столкнуться со следующими проблемами:
- удаление топиков Kafka по умолчанию не включено. За это отвечает параметр конфигурации брокера topic.enable в файле server.properties. Если этот параметр установлен в значение false, Kafka не будет обрабатывать запросы на удаление. Задав delete.topic.enable=true, надо перезапустить брокер, чтобы изменения вступили в силу.
- «зомби-топики», которые продолжают существовать даже после удаления из-за кэширования на стороне брокера или отложенной очистки метаданных. В этом случае тоже помогает перезагрузка брокера. Если кластер использует ZooKeeper для синхронизации метаданных вместо режима KRaft, придется вручную удалять метаданные топика из ZooKeeper.
- отказано в доступе. Поскольку политика авторизации в Kafka реализуется с помощью ACL-списков, у пользователя, которому необходимо удалить топик, есть разрешения ALTER и DELETE. Если пользователю не предоставлены соответствующие разрешения, это может привести к исключению AuthorizationException. Проверить роль и привилегии можно с помощью утилиты kafka-acls.sh:
kafka-acls.sh --bootstrap-server <broker_host>:<port> --list
- топик используется потребителями. Очевидно, что при удалении нужно учитывать зависимости в нижестоящих системах. Если другие приложения, потоковые задания или ETL-конвейеры потребляют данные из топика, это может привести к каскадной остановке ряда систем. Например, системы обнаружения мошенничества не смогут выявить аномальные паттерны из-за отсутствия событий пользовательского поведения, которые публиковались в удаленный топик. Поэтому перед удалением топика следует сперва остановить всех его потребителей, завершив работу приложений или переназначив их на другой топик. Определить зависимости также можно с помощью таких инструментов, как Confluent Control Center или мониторинг Kafka Connect. Также проверить активные группы потребителей можно с помощью утилиты kafka-consumer-groups.sh:
kafka-consumer-groups.sh --bootstrap-server <broker_host>:<port> --list
- влияние фактора репликации. Если у топика есть реплики на нескольких брокерах, Kafka может не полностью удалить его, пока все метаданные реплики не будут очищены. Проверить сведения о репликации поможет утилита kafka-topics.sh:
kafka-topics.sh --bootstrap-server <broker_host>:<port> --describe --topic <topic_name>
Если в результате этой команды будет показан список все еще существующих реплик, надо убедиться, что все брокеры подтверждают запрос на удаление.
Идентифицировав проблемы, которые могут возникнуть при попытке удаления топика в производственной среде, далее рассмотрим, как их избежать.
Рекомендации по безопасному удалению топика
Чтобы избежать каскадного сбоя нижестоящих приложений и ETL-конвейеров, прежде всего перед удалением топика Kafka нужно убедиться, что он не используется потребителями. Получив список потребителей с помощью ранее указанных инструментов (Confluent Control Center, Kafka Connect, kafka-consumer-groups.sh), необходимо создать новый топик и переназначить на него потребителей, обновив их конфигурации. Соответственно, на стороне приложений-продюсеров надо настроить публикацию данных в новый топик. И только после проверки, что потоковая передача идет без ошибок (продюсеры публикуют сообщения в новый топик, а потребители читают из него), можно безопасно удалить старый.
При использовании Kafka с открытым исходным кодом необходимо очистить конфигурации ZooKeeper (если он используется вместо режима KRaft). В случае Confluent Cloud метаданные очищаются автоматически. Перед удалением топика рекомендуется сделать резервную копию данных, поскольку удаленные сообщения невозможно восстановить.
Поскольку операция удаления выполняется безвозвратно, разрешения на нее должны иметь только уполномоченные администраторы. Для этого надо настроить RBAC-политику контроля доступа на основе ролей с помощью ACL-списков.
Таким образом, с учетом ранее рассмотренных проблем, ручное удаление топиков в производственной среде может быть опасным. Поэтому, как и любую административную задачу, эту операцию лучше автоматизировать. Автоматизация гарантирует, что проверка, резервное копирование и очистка метаданных будут выполнены, снижая риски случайной потери данных или сбоя сервисов.
Автоматизированный процесс удаления топиков Kafka включает следующие задачи:
- проверка отсутствия активных потребителей и зависимостей;
- резервное копирование данных;
- остановка и удаление коннекторов и обновление конфигураций;
- логирование и мониторинг выполненных действий.
Реализовать автоматизацию этого процесса можно с помощью скриптов Bash, Python или Ansible.
Кроме того, вместо полного удаления топика можно перестать его использовать, прекратив публикацию сообщений. А чтобы сократить ресурсы на обслуживание, следует перенастроить политики хранения для автоматического удаления старых сообщений и включить сжатие данных. При геораспределенной репликации топика в нескольких кластерах с помощью MirrorMaker 2.0 или Confluent Replicator, удаление в одном кластере может не удалить его из других. Некоторые кластеры могут иметь более длительный период хранения тем, что приводит к частичной потере сообщений в разных средах. Поэтому сперва надо остановить георепликацию и только потом удалять топик.
Наконец, вместо непосредственного удаления топика можно настроить политику очистки, задав конфигурации retention.size и retention.time, о чем мы говорили здесь и здесь.
Научитесь администрированию и эксплуатации Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
