Как мы починили зависания Apache Kafka® и помогли сообществу Apache
Расскажем, как команда Yandex Cloud выявила в Apache Kafka ошибки и предложила решение по их исправлению, вошедшее в новую версию продукта.
Сегодня мы расскажем про необычное расследование инцидента, которое позволило выявить ошибки 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 в последних версиях продукта.
