Недавно мы провели вебинар» Я полностью обосрался.
Сбои Apache Kafka На нем спикер Всеволод Севостьянов, технический менеджер HelloFresh, поделился неудачами из личной практики, а также рассказал, как умело ходить по тонкому льду Кафки и проапгрейдить свой бэкенд. Для тех, кто пропустил или предпочитает читать, а не смотреть, мы подготовили текстовую версию.
Ошибка №0: Кафка сложнее, чем кажется
Apache Kafka представлен как сверхпростой инструмент, поэтому многие эксперты не до конца понимают, как он работает. Например, существует заблуждение, что Kafka очень легко настраивается, поэтому проблем с ним быть не должно.На самом деле, под капотом у него много компьютерных наук.
Есть темы — что-то вроде контейнеров, в которых хранятся сообщения, объединенные по теме или формату.
Для масштабирования внутри Kafka темы разделены на перегородки — блоки хранения сообщений.
И часто проблема возникает из-за того, что сообщения разбиваются случайным образом: некоторые попадают в Partition1, некоторые в Partition2, некоторые в Partition3 и т. д. В результате сервисы, привязанные к Kafka, начинают читать данные из топиков в неправильном порядке.
Разделение — это нормально для Кафки.
Но я часто видел команды, которые очень старались обойти темы, делали только один раздел и все неправильно настраивали.
Хотя здесь можно пойти простым путем: создать ключ раздела, который позволит вам хранить зависящие друг от друга сообщения в том порядке, в котором вы хотите их передавать.
Ошибка №1: мы создавали 150 тем, но нужно было заменить Кафку на Кролика
Я работаю в компании, которая предоставляет Meal Kits, службу доставки кулинарных рецептов.И у нас есть инструмент для создания рецептов.
В нем создаются рецепты, данные записываются в Kafka и потом куда-то отправляются.
Инструмент не должен знать, кто потребляет эти данные.
Проблема :Кафка слушает Планировщика, который составляет меню на неделю, Хранилища Данных, отвечающего за обработку данных, Предсказателя, который оценивает, сколько продуктов нам понадобится на этой неделе и сколько нужно заказать на следующую, и куча других услуг.
Всем сервисам нужны разные данные.
Например, планировщик меню показывает только готовые рецепты, а Предиктор показывает рецепты, которые были заказаны хотя бы один раз.
Изначально мы пытались решить проблему, сделав множество разных тем для каждого потребителя.
И это, естественно, привело к тому, что Кафка стал ставкой.
Кафка не способен понять из содержания темы, куда и какому потребителю ее следует доставить.
Все это работает по модели подписки, когда вы говорите: «Я хочу получать газету каждый день».
И каждый день вы получаете газету со всеми новостями, а не только теми новостями, которые вас интересуют. Итак, на каждую тему у нас был ровно один потребитель.
А логика, которая должна выполняться на стороне потребителя (он фильтрует то, что ему интересно), выполнялась на стороне Recipe Dev. Это было полный обкафкинг , потому что перед нами не разделенная система, а система, которая просто знает о существовании всех своих компонентов и обменивается сообщениями между ними, используя Kafka в качестве шины данных или механизма персистентности.
Это достаточно дорого и неэффективно.
Решение : Мы заменили Kafka на RabbitMQ, который может по ключу определить, в какой канал отправить конкретное сообщение и кто должен его получить.
Также с помощью этого ключа потребители могут подписаться на обновления.
У нас было давление со стороны инфраструктуры — система была многократно реплицирована, имела мультирегиональное развёртывание и около 30-40 инстансов.
В этом масштабе RabbitMQ был дешевле Kafka.
Ошибка № 2: Лидер недоступен
Проблема : есть потребитель, который потребляет данные.Вы с радостью отправляете данные в Kafka, но затем замечаете, что потребитель ничего не потребляет. Кафка работает, потребитель работает, но ничего не происходит. Одной из наиболее распространенных причин, почему это происходит, является ребалансировка потребителей.
В Kafka есть механизм, о котором мы уже говорили выше: темы делятся на разделы.
Предположим, вы добавили первого потребителя.
У вас есть понятие «лидер группы».
В этом случае он прослушивает и последовательно добавляет в потребитель все разделы определенной темы: 
Если для этой темы добавить второго потребителя, то к нему будут привязаны P3 и P4: 
Этот процесс занимает некоторое время, так как второй потребитель должен сообщить лидеру группы, что он доступен.
Затем лидер группы обрабатывает эту информацию и возвращает ответ, какие разделы должен использовать потребитель.
А дело в том, что если ваше ПО написано неправильно, или у вас под капотом, например, Java, или Spring Boot, который долго запускается, то такая ребалансировка будет происходить регулярно.
Что у нас было : первый потребитель подключился и начал слушать тему.
Затем запустился второй и третий потребители, подали сигналы о ребалансировке и подключились.
Но в какой-то момент третий потребитель сказал, что он отваливается.
Причём, он только так сказал — на самом деле он никуда не свалился и продолжал работать.
Это казалось мистикой, пока мы не открыли для себя удивительный мир параметров max.poll.interval и Session timeout. Дело в том, что Кафка — это система пассивного чтения; он сам ничего никому не отправляет. И чтобы обеспечить равномерное распределение сообщений секционирования по потребителю, ей необходимо знать, сколько всего потребителей.
Для этого выбирается Consumer Leader, который слушает сердцебиение — сообщения потребителя о том, что он существует и готов получать данные.
Heartbeats отправляются всеми потребителями в Kafka, и интервал между двумя пульсами не должен превышать max.poll.interval. Совершенно очевидно, что нам не следует превышать таймаут сеанса.
Но совершенно не очевидно, что потребитель считается мертвым не только тогда, когда он превышает этот интервал, но и когда он принял сообщение, начал его обрабатывать и не смог обработать в течение max.poll.interval. Нужно уметь оперировать значениями max.poll.interval и Session timeout. По умолчанию они настроены на не очень большой интервал — около 2 секунд для таймаута сеанса и 500 миллисекунд для max.poll.interval. Если ваш тайм-аут сеанса составляет 5 или 10 секунд, Кафка скажет: «Если у вас нет времени, отключитесь».
То же самое и с обработкой сообщений: если вы не успеваете обработать сообщение за отведенный интервал, возникает проблема.
Решение : мы увеличили max.poll.interval до двух часов и время ожидания сеанса до 5 часов.
И мы придумали следующую схему — подъехал потребитель, загрузил в себя данные и висел с ними около двух часов.
В результате темы были заблокированы, и получить от них ничего нельзя было.
Мы решили снизить max.pool.interval и оставить таймаут сеанса как есть.
Для этого нам понадобился group.instance.id, который позволял Kafka в случае сбоя первого потребителя дождаться Session Timeout Миллисекунды, когда второй потребитель поднимется и заберет разделы себе.
group.instance.id — классная штука, но пользоваться ею нужно аккуратно, иначе может возникнуть ситуация, когда потребитель находится в таймауте три часа, никто на него не реагирует, и одна из тем простаивает, а все остальные шевелятся вперед.
Ошибка №3: TTL
Проблема : у нас второй потребитель отвалился.Оно висело какое-то время, а потом начало брать данные из темы.
И в результате мы обнаружили, что некоторых рецептов не хватает. Причина: произошел TTL. Хотя Kafka можно использовать в качестве базы данных, это не база данных.
Kafka — это журнал, в который сообщения добавляются одно за другим и откуда они извлекаются в одной и той же последовательности.
Kafka рассчитан на высокую пропускную способность и создает резервные копии своих сообщений на диске.
Время от времени он выполняет операцию уплотнения — берет и отсекает часть сообщений.
По умолчанию TTL Kafka составляет одну неделю.
Но люди часто об этом забывают, а потом обнаруживают, что в журнале нет данных старше 7 дней.
Решение : вам нужно использовать max.poll.interval, установить разумный таймаут сеанса и следить за здоровьем потребителя.
Желательно провести мониторинг.
Несколько заключительных слов о Кафке
Основная проблема в том, что Kafka неправильно воспринимается и настраивается.Казалось бы, все очень просто (тот же Rabbit MQ в разы сложнее), но внутри огромное количество разных «наворотов».
И очень важно научиться правильно ими пользоваться.
Не воспринимайте эту статью как рекомендацию не работать с Кафкой.
Напротив, Kafka — отличный инструмент. Но здесь мы постарались дать честный обзор и рассказать о трудностях, с которыми вы можете столкнуться.
Для тех, кто хочет научиться работать с Кафкой и избежать неудач У нас есть видеокурс» Apache Kafka для разработчиков «Она быстро выведет вас на новый уровень владения инструментом и поможет:
- сократить время, затрачиваемое на рабочие задачи с помощью Kafka;
- упростить работу с микросервисами;
- понимать типичные шаблоны проектирования;
- сделать приложение более отказоустойчивым;
- Получите опыт разработки приложений с использованием Kafka.
Она всесторонне освещает Kafka и дает понимание ее места в жизни организации.
Теги: #программирование #ИТ-инфраструктура #Системное администрирование #kafka #rabbitmq #Apache #apache kafka #разделение #partition #partitions
-
Реклю, Элиза
19 Oct, 24 -
Миссии Наса В Ближайшие Годы
19 Oct, 24 -
Как Еще Можно Классифицировать Музыку?
19 Oct, 24 -
Для Любителей Марихуаны И Алкоголя
19 Oct, 24
