Apache Kafka - давно уже стала стандартом для распределенного лога, буфера для потоков данных. Можно сказать, что технология прочно вошла в разряд "скучных". Множество статей на Хабре, медиуме, видео на ютубе, обширное сообщество в телеграме. Подводные камни известны, специалистов много, уровень зрелости дошел до такой стадии, что начали принимать достаточно сложные KIP типа отказа от Apache Zookeeper и т. п.

Но мы же айтишники, зуд улучшательства и непрерывного повышения качества (чтобы ни скрывалось под этой фразой) у нас в крови. И вот она - Redpanda, которая обещает нам полную совместимость с протоколом kafka, и еще кучу бонусов сверху.

Привет, меня зовут Стас, последние 5 лет я работаю на позиции data platform engineer. Из них Apache Kafka была одной из составляющих эту самую data platform около 3 лет. Эта статья будет итогом более чем полугода эксплуатации в продуктиве кластера redpanda. Спойлер: вчера я поднял из гита удаленные плейбуки для кафки и вернул ее в продакшн обратно, прощай мечта...

Введение

В нашей компании space307 очень любят потоки данных в реальном времени, новые технологии и mysql. Платформа данных устроена достаточно стандартно - хранение и обработка в связке hadoop + vertica + clickhouse. И если для вертики организовать работу с потоками данных достаточно "просто" (например, у нас написан свой cdc сервис для mysql, который проигрывает binlog в вертику), то с hdfs уже появляются проблемки.

Дано: большие шардированные часто обновляемые таблицы в mysql с неудобными для извлечения индексами.

Хочется: ежедневный снимок T-1 для таких таблиц в hadoop, и совсем хорошо если дополнительно появится полная историчность для таблиц с операциями delete+update.

Решение: Debezium, работающий в Kafka Connect кластере, в котором источником является mysql коннектор, промежуточным буфером для потока данных Apache Kafka, конечным получателем HDFS.

Описанная выше связка сервисов работает уже больше полутора лет достаточно стабильно на общих объемах данных порядка 1 млрд строк и порядка 500 обновлений в секунду.

А что не так с текущим решением

Какие недостатки можно нацедить из своего опыта работы с кафкой, чтобы решиться на внедрение нового не очень популярного сервиса на замену:

• java стек – тут и невероятный размер окружения и самых jar, и гуляние во время работы нагрузки по цпу, и вообще все самые привычные java-хейтерам причины :)

• Apache Zookeeper как необходимая часть деплоя – 21 век на дворе, свою реализацию рафта вшивают уже в каждый утюг :)

• восстановление и балансировка кластеров - это отдельная боль, которая при неудачном стечение обстоятельств и знаний может доставить множество неприятностей

• очень разношерстный тулинг сервиса – набор приложения для работы из консоли поражает воображение количеством и разнообразием параметров

• количество потребляемой памяти – вопрос спорный, но при небольших нагрузках гигабайты тратить зря не хочется

• мониторинг и отсутствие экспортера из коробки – вот вам jmx экспортер, вот вам несколько видом prometheus экспортеров на гитхабе, у каждого из которых свой уникальный набор метрик и уникальная стабильность

• управляемость кластера – это рядом с вопросами к тулингу, и сверху все любят поставить какой-нибудь веб интерфейс

• если вам нужна schema registry – поднимайте и администрируйте отдельно где хотите и как хотите (а нам нужна)

• если вам нужна http proxy – повторить пункт выше

• сервис и технология скууууучные :)

Как можно заметить, основная часть претензий связана с администрированием, к непосредственной работе и эффективности самого сервиса претензий нет вообще. Тем не менее для команды с ограниченными ресурсами (как человеческими, так и вычислительными) - некий резон для поиска альтернатив есть.

Появление красной панды

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

Что же нам обещают?

• никакой java – сервис написан на c++ с тулингом на go. На выходе у нас 2 бинарных файла и всё

• полная совместимость с протоколом Apache Kafka. Ни надо ничего переписывать на стороне клиентов, подмены транспорта никто не заметит

• своя реализация raft протокола – не нужны никакие сторонние сервисы

• очень эффективное использование ресурсов – это общий тренд такого рода инструментов-заместителей (привет scylla и другие)

• одно из главных достижений, про которое везде пишут – снижение хвостовых таймингов. Кто перебрасывал через кафку много данных в курсе 99 перцентиля latency и хочется плакать от таких цифр

• самостоятельное лечение кластера при потерях брокеров

• встроенная schema registry и http proxy

Кроме того, в платной версии есть очень интересные фишки типа бесконечного хранения данных в сервисе путем вытеснения холодных данных в облачные объектные хранилища типа Amazon S3 и другие.

Как по мне все плюшки звучат очень круто и внедрять стоит. Блог тоже очень интересный всякими бенчмарками и прочим.

На что стоит обратить внимание до начала работ

Стоит внимательно отнестись к архитектуре сервиса. Вот такая цитата ждет нас на сайте:

Redpanda was engineered from scratch and written in C++ to extract the best performance out of every core, disk, memory chip, and network byte. It uses a patent-pending thread-per-core architecture to ensure the highest throughput, with the lowest possible latency, no matter where it’s deployed: global multi-region cloud clusters, on-prem bare metal hardware, private cloud containers, or at the edge!

Добавим еще заявление:

Redpanda is designed to exploit advances in modern hardware, from the network down to the disks. Network bandwidth has increased considerably, especially in object storage, and spinning disks have been replaced by SSD devices that deliver better I/O performance. CPUs are faster too, but this is largely due to the increased core counts as opposed to the increase in single-core speeds.

Как можно для себя вынести, эти ребята выжимают все из железа, и железо это должно быть современным.

Мы были вместе 9 месяцев

Команда у нас маленькая и очень решительная. После небольшого бенчмарка кластер redpanda был развернут на 5 серверах, после чего на него переключили продуктовые потоки и он встал в работу.

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

В итоге сервис поселился на серверах по соседству с сервисами хадупа - hdfs и yarn, ресурсов там спокойно хватало на кафку как по ЦПУ, так и по дискам, так что и новому зверьку должно было быть хорошо.

Немного слов о типовой нагрузке - порядка 20-30 топиков, чуть более 400 партиций, средняя нагрузка около 500 eps и до 50 000 eps в пике, чтение в основном батчами через Spark SS.

Некритичные минусы, которые были во время эксплуатации:

• установка через ansible довольно специфична – после просмотра примеров на сайте сервиса хочется их выкинуть и написать нормально (например, с нормальным текстовым конфигом, а не запуская утилиту конфигурации и скармливая ей через stdin параметры), но оказалось, что всему есть причина...

• дополнительное неудобство вылезло с реализацией в роли определение начального мастера при старте кластера с нуля – необходимо запустить первую в кластере ноду и далее прописать в остальных ее как сида

• возвращать брокера с потерянными на диске данными тоже оказалось не очень просто

• дашборд для графаны очень насыщен метриками, но чтобы узнать о проблемах с кластером - надо знать куда смотреть и что искать

За нашу совместную жизнь вместе с пандой мы пережили обновление одной мажорной версии (22->23), которое прошло очень гладко и красиво.

И в принципе все обещанное исполнилось. Тайминги на одинаковой нагрузке были меньше примерно в 2-3 раза, ресурсов по процессору кушалось ровно заданное количество. Читать сообщения из консоли, изменять параметры топиков, обслуживать было очень удобно.

Пора прекратить этот разврат

Две последних недели ровно в 9:32 утра приходил алерт об пропаже сообщений от коннектора дебезиума к бд. А две недели до этого такие алерты приходили дважды в день, второй раз в 4:56. А еще до этого алерты приходили раз-два-три в неделю на протяжении месяцев. Никакого автоматического восстановления потока, не смотря на написанное в документации к дебезиуму не происходило и надо было руками перезапускать коннектор.

Причина алертов была в недоступности на запись redpanda - шел выбор лидеров партиций. Выборы могли идти в районе 5-15 минут, заканчивались успехом, но для клиентов все было плохо.

Какие меры мы приняли для исправления ситуации:

• тюнинг кластера и настроек реализации raft в частности

• обновление кластера до последней версии

• мониторинг нагрузки на серверах с брокерами и ее снижение в случае перегрузки

Ничего из этого не помогло. Да, ноды данных хадупа - не лучшее место для размещения подобных сервисов, но с кафкой на них мы не испытывали проблем, запас по ЦПУ был достаточный, памяти хватало, дисковая подсистема не становилась в стопор при ежедневной работе.

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

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

Послесловие с небольшими выводами

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

Дополнить это удобным администрированием, минимальными задержками и получается отличный сервис. Не грех его развернуть на выделенных серверах с подключенными nvme ssd или вообще использовать в облаке.

Но когда все эти возможности вам не нужны и плюсом вы ограничены в вычислительных ресурсах рациональностью их применения - стоит ли овчинка выделки? Старые скучные технологии позволяют вам спать по ночам и даже иногда играться с новыми технологиями...