Как мы починили зависания Apache Kafka® и помогли сообществу Apache

Расскажем, как команда Yandex Cloud выявила в Apache Kafka ошибки и предложила решение по их исправлению, вошедшее в новую версию продукта.

18 мая 2022 г.
12

Сегодня мы расскажем про необычное расследование инцидента, которое позволило выявить ошибки Apache Kafka® и упростило сообществу работу с брокером.

Проблема с перезагрузкой брокера Kafka

В конце 2021 года дежурный инженер команды Managed Service for Apache Kafka® обнаружил в мониторинге, что брокер Kafka, на котором возникла проблема доступности к ZooKeeper, не может завершить работу уже несколько минут. В обычной ситуации после перезагрузки брокер Kafka подключался заново к ZooKeeper, и работоспособность кластера восстанавливалась. Но в данном случае процесс не завершался, и зависшая нода не участвовала в работе кластера. Дежурный собрал необходимую для анализа информацию (стек-дамп и копию логов), перезапустил брокер с помощью kill -9 и совместно с командой VPC начал искать причину зависания.

В процессе разбора инцидента ситуация стала проясняться. Оказалось, что во время сервисных работ на сетевой инфраструктуре произошла кратковременная недоступность. Если брокер теряет сетевую связность с кластером ZooKeeper, то он должен закрыться от нагрузки, так как уже не может быть лидером партиций и не должен отдавать неконсистентные данные. Так он и поступил, и, когда истек таймаут подключения к ZooKeeper, решил перезапуститься, но процесс не завершился.

Это было очень похоже на баг в самой Apache Kafka. Совместными усилиями команда сервиса провела сопоставление исходного кода и stacktrace-потоков выполнения, и была выявлена строка, на которой «повис» основной поток выполнения. Ситуация напоминала взаимную блокировку (deadlock) — проблему многопоточных программ, когда два потока выполнения ждут освобождения одного ресурса.

Примечание

Стоит отметить, что когда появляются проблемы со связностью с кластером ZooKeeper, то возникает исключение, которое должно приводить к перезапуску брокера. Исключение инициализирует завершение работы всего брокера (основного потока) и всех дочерних потоков, в том числе и клиента ZooKeeper.

Для проверки гипотезы мы собрали свою версию Apache Kafka с более подробным логированием и воспроизвели ситуацию с сетевой недоступностью. Это помогло выявить взаимную блокировку: поток ZooKeeper клиента ждет завершения основного потока, который, в свою очередь, ждет завершения ZooKeeper клиента.

Мы собрали версию Apache Kafka, в которой могли по необходимости бросать нужное исключение для надежного воспроизведения проблемы и, проверив что все работает, зарегистрировали баг.

Проблема с потерей контроллера в кластере kafka

Но, к сожалению, на этом наши проблемы не закончились. После перезапуска брокера кластер не всегда приходил в норму: иногда он считал, что в нем нет топиков или брокеров. Проверив метаданные в ZooKeeper, дежурный понял, что ошибка кроется в процессе их получения.

Снова собрав свою версию Apache Kafka и воспроизведя ситуацию с сетевой недоступностью на тестовом окружении, мы нашли другой баг, который также вызывался нарушением связности с ZooKeeper.

Проблема заключалась в следующем: после того как был выбран в качестве контроллера один из брокеров, временно потерялась связанность этого брокера с ZooKeeper и произошла ошибка аутентификации. Запускался процесс переинициализации контроллера внутри кластера, но из-за текущей недоступности событие о снятии полномочий и об инициации процесса выбора нового контроллера не было получено ZooKeeper, и он сохранил информацию о том, что ранее выбранный брокер является контроллером. В итоге брокер, который должен был выполнять функции контроллера, не начал выполнять их, и kafka-кластер оставался без активного контроллера и перестал работать.

По этому поводу мы тоже сделали баг-репорт.

Преимущества managed-решений Yandex Cloud

Благодаря тому, что у каждого управляемого сервиса платформы Yandex Cloud есть команда разработки и поддержки, которая 24/7 следит за работоспособностью кластеров, обеспечивается стабильная работа решений пользователей. Мы изучаем инциденты и сами исправляем ошибки, в том числе если находим их в решениях open source.

В итоге, на основании баг-репорта, все ошибки Apache Kafka были исправлены разработчиками Kafka в последних версиях продукта.

author
Команда Yandex Cloud
Как мы починили зависания Apache Kafka® и помогли сообществу Apache
18 мая 2022 г.
12