Comments 58
Весьма интересная статья, спасибо!
Разработчик счастлив, он не должен думать про kafka.
Админ счастлив, разработчики не ломают kafka.
Зачем тогда использовать kafka?
Потому что мы все еще хотим предоставлять шину данных с гарантиями at least once. И она все еще должна уметь хорошо горизонтально масштабироваться, для того, чтобы быть общим ресурсом для огромного количества сервисов. И, конечно, поддерживать возможность горизонтального масштабирования самих сервисов.
Основной профит в том, что скрыта технология под капотом. Сегодня кафка, завтра может быть редпанда, послезавтра - федерация кластеров. А для клиентов точки входа и апи не меняются
это они еще до реализации consumer'а не дошли. Как дойдут до реализации нужного счастливому разработчику функционала, то они поймут, что никакой абстракции не получилось и просто сделали проксирование вызовов поверх grpc.
мне прям интересно как они будут делать консесус при распределении партиций между консьюмерами (подами), с ребалансом, событиями и т.д.
но итог понянет - получим прокси кафка-библиотеки поверх grpc и все те же клиентские обертки и все также счастливому разработчику нужно будет думать про кафку (потому что абстракция протекла).
либо будет очень примитивный функционал, который можно будет использовать в каких-то простых сценариях, а счастливому разработчику все также держать под рукой все те же кафочные библиотеки.
Консьюмеров мы конечно уже реализовали, в статье об этом написано.
Как и задумывалось, api предоставляет сильно упрощённый функционал, его для большинства сценариев хватает.
Абстракция, разумеется, не идеальная — если сделать клиентов-консьюмеров больше чем партиций, то лишние будут простаивать. Это сделано намеренно, чтобы не усложнять реализацию.
Нагрузка немаленькая.
А сколько реплик топиков используется и в каком режиме происходит продьюсинг (acks=0, acks=1, acks=all)?
Все тесты проводились на acks=all с rf=3.
У вас похожая система работает через websockets, если я не ошибаюсь. Не думаете ли вы перейти на gRPC после прочтения данной статьи? Или вы считаете, что на производительность это не сильно окажет влияния. Хочется услышать ваше мнение.
Да, похожая, хотя нагрузка меньше.
Нет, пока не думаем менять, потому что основное время тратится на взаимодействие с самой кафкой, а в ней в свою очередь - на дисковые и процессорные операции.
Использование grpc даст (но не для всех клиентов) экономию процессорного времени и немного сети, что однако не является для нас узким местом.
Хм, но статья про эту систему уже была на хабре полгодика назад. Правда было поменьше технички. Повторяетесь? :)
Как известно, нет таких проблем в программировании, которые нельзя решить повышением уровня абстракции ? В голову приходит идея: что, если большую часть логики реализовать на стороне сервера, полностью изолировать от потребителей работу с Kafka, а клиентский протокол упростить до неприличия? Тогда мы могли бы снова сделать наши библиотеки простыми, обновлять их редко, а клиенты бы получали новые фичи практически без доработок с их стороны. Да и уметь переезжать с одного кластера на другой было бы очень кстати.
Протокол кафки достаточно давно стабилизирован, лет 5 уже точно. Вы не смогли централизовать обновление/использование стандартных библиотек, написали свою, по пути еще и создав хайлоад-сервис, который стал точкой отказа. И все равно клиенты должны будут обновлять библиотеки так или иначе.
Мне кажется, или в этом "решении" технари победили менеджеров? :)
Кстати про 75 брокеров кафки - а зачем их 75? У вас какая-то стандартизация брокеров? Просто в моем случае поток примерно в 1.5 млн входящих держало 3 брокера (но у вас конечно сообщения гораздо жирнее судя по трафику плюс большое число партиций).
Одна из ключевых целей, которую мы преследуем — это снижение сложности клиентских библиотек.
Библиотеки для работы через grpc гораздо проще чем библиотеки для работы с kafka, у нас более-менее активно используется 4 языка и на каждом свои либы с кучей подводных граблей, поддержка платформенных адаптеров вокруг них весьма болезненна.
По поводу конфигурации кластера не подскажу, возможно смогут ответить коллеги.
По количеству брокеров. Во-первых, у нас нагрузка на которую рассчитан кластер в rps не полтора миллиона, а на порядок больше. По трафику так же нужно смотреть — как правило пишут большими батчами, а не по одному сообщению. Это наша общая рекомендация для сервисов. Размеры батчей до 50Мб доходят. Во-вторых, у нас все рассчитано на падения одного из трех ДЦ, в которых расположена Кафка. Третий момент — нужно смотреть конфигурацию, например у нас довольно много ресурсов заложено на TLS, на работу внутренних экспортеров. Ну и последний момент, число 75 условное.
Про повторы. Вероятно, вы путаете нашу статью с аналогичной от Авито. У них похожий подход и они пишут о нем периодически, например, тут
https://habr.com/ru/companies/avito/articles/655553/
Не скрою, мы вдохновлялись этими материалами, прежде чем разрабатывать свою систему.
Спасибо за ответ :)
Точно, извиняюсь, вот та статья https://habr.com/ru/companies/avito/articles/726564/
Названия у басов одинаковые, спутал :)
Третий момент — нужно смотреть конфигурацию, например у нас довольно много ресурсов заложено на TLS, на работу внутренних экспортеров
А, вот оно что. Никогда не использовал у себя, слишком уж расточительно. Было бы интересно почитать статью, насколько большое потребление процессора в случае кафки. Но кажется, что не должно быть очень уж большим, самая ресурсоемкая операция же происходит в момент хендшейка, дальше все гораздо проще. А у кафки соединения постоянные и таких хендшейков должно быть довольно мало.
Вы упоминаете в при паблише сообщения клиент на каждое сообщение получает акк о его успешной записи. При этом есть параметр ProducerLinger который накапливает какое-то количество сообщений до публикации. Получается что акк клиенту приходит до того как мы записали батч в кафку? Что будет происходить если сервис умрет в этот момент?
Клиент получит свой ack только после того как батч будет записан на брокеры.
ProducerLinger влияет на время накопления сообщений перед тем как они будут записаны, всё это время клиент ждёт подтверждения.
Если же клиент умрёт и сообщение в этот момент будет записано, то он просто запишет его ещё раз после рестарта — дублирование сообщений допустимо при at least once.
А откуда в Ozon появляется такое количество сообщений?
Насколько я понимаю, нагрузка на сайте там единицы тысяч rps, да и то на чтение и в пике. Откуда появляются миллионы сообщений в кафке?
Нагрузка на гейтвее скорее ближе к сотне тысяч rps, а дальше микросервисная архитектура делает своё дело — у нас сейчас около 4 тысяч сервисов.
А откуда на apigw сотня тысяч rps? Или каждая страница превращается в сотни rps?
Да и это про чтение же, а чтение не должно приводить к сообщениям в кафке?
А действий - ещё на порядки меньше.
Т.е. все равно не понятно, как сотня (даже меньше) покупок в секунду приводит к к полутора миллионам новых сообщений в кафке в секунду.
Вы оперируете интересными числами неизвестного происхождения в своих предположениях :)
Не думаю, что я смогу комплексно ответить на ваш вопрос за пределами уже сказанного.
Хм. Меньше сотни платежей в секунду - это данные из квартального отчета Озона за первый квартал 2023 года (там 180млн. платежей за квартал указано, что примерно 50 в секунду)
1.5 миллиона сообщений - из приведенного в данной статье графика.
Понятно, что не только платежи приводят к трафику - но все равно интересно, откуда такой объем сообщений в кафке. Я бы сказал, порядка на три-четыре больше ожидаемого.
Как известно, нет таких задач в программировании, в которых нет ничего, что можно было бы положить в кафку.
Почему чтение не должно приводить к генерации сообщений в message bus? А как же аналитика, маркетинговые программы, и прочие штуки, следящие за каждым вашим чихом на сайте?
Ну, можно, конечно, каждое движение мышкой отправлять в kafka, но это довольно странная идея, там проще (и правильнее) отправлять сразу пачку данных по сессии. Т.е. вряд ли именно эти данные дают такое количество сообщений.
Судя по всему тут переборщили с микро-микро-сервисами, в результате один запрос от пользователя порождает тысячи сообщений между микросервисами. Так иногда бывает.
То есть круто, что так оптимизировали Кафку, но вот остальная архитектура вызывает вопросы.
Ну, 5000 микросервисов - это точно перебор, тут даже нет сомнений.
Но все равно не понятно, зачем внутри все взаимодействие через kafka, хотя скорее всего никакого смысла в асинхронности нет.
А почему вы считаете, что 5000 перебор? А сколько надо по вашему и почему? Вы же не знаете какие там подсистемы, бизнес-логика, компромиссы, на которые когда-то пошли при каких-то обстоятельствах и пр. Да и вроде бы речь не идет про то, что Кафка только про обработку событий на сайте от клиентов. Наверняка там какие-то синхронизации данных между подсистемами, попутные подсчеты счетчиков и пр. и пр.
И даже если представить, что есть какая-то часть неоптимальностей с микросервисами, то вы же не будете сейчас рекомендовать ребятам переписать все микросервисы, перестроить процессы и пр. Это тоже денег стоит, да и статья же конкретная и про другое вообще, а вы уводите в то, что как вам кажется, все это вообще не нужно и вы бы не так там с самого начала делали.
Они не кафку, они самодельные прокладки для общения с ней допиливали. Кафка и без них миллионы может делать, правда очень маленьких сообщений.
Так Ozon это же не только покупки и показ товаров, а куча ещё всего, например логистика, тревел, финтех... Наверное, не обращали внимания =)
Поищите сайт OzonTech или Youtube канал, там много интересного
Посмотрел крупнейших потребителей - в топе рекламная сеть, аналитика и система защиты от ботов.
Спасибо. Все равно не понятно, откуда там столько событий. Неужели каждый показ рекламы отправляют в кафку? А уж какие события формирует аналитика - я вообще не представляю. Или там 1000 шагов ETL и все обмениваются через kafka?
Для подобных систем в целом валидно отправлять каждое событие в кафку, другое дело, что эти отправки стоит батчить, чтобы не создавать чрезмерную нагрузку на брокеры.
Потребность управлять поведением клиентов - как раз одна из основных причин создания data-bus, там зачастую что-то нездоровое происходит.
Похоже, что ребята купили начальство вау-фактором. Миллионы! Это же много! При этом вопрос "зачем" просто не обсуждался. Хотя можно предположить, что в качестве оправдания будет предложено что-то про расширение бизнеса. На сколько тысяч процентов они закладываются при таком расширении, история умалчивает.
Хе-хе, в понедельник я анонсировал (внутри конторы) GA своего сервиса-прокси кафки с грпц стримингом и протобафом, а сейчас эта статья.
Только у меня консьюмеры забирают сообщения из промежуточного батча в прокси, и коммитит оффсеты она же.
Тогда возможно вам будет интересно ознакомиться с проектом https://github.com/mailgun/kafka-pixy, хоть он и не имеет полноценной поддержки (последний релиз был в 2019), но как минимум из него можно черпать вдохновение :)
Интересно, не было ли проблем с GC GO у вас? Или вы пулы объектов используете, на горячем пути практически ничего не аллоцируете?
И традиционный вопрос в подобных постах — при дизайне системы не думали о том, чтобы взять язык без GC (C++/Rust)?
Я в процессе отладки не раз подозревал GC, но ни разу он не был виновен - трейсинг хорошо позволяет отслеживать такое. На горячем пути в grpc и franz-go действительно в основном пулы объектов под капотом.
Идея про С++/Rust расcматривалась скорее в полушуточном режиме, поскольку мы не упирались в язык, а в команде экспертизы по Go заметно больше :)
А не легче было поменять Kafka на NATS ?
производительность выросла бы в 2-3 раза ничего не делая :-)
NATS к сожалению обеспечивает лишь гарантии at most once в безброкерном режиме, а с брокером смысл его использования теряется. Кроме того задача переезда на него гораздо тяжелее чем задача переезда на grpc-прокси перед kafka без переезда данных.
Ну и проблемы с библиотеками от этого никуда не деваются :)
Интересно, откуда такое безапелляционное утверждение?
Мы у себя рассматривали NATS как альтернативу другим брокерам и производительность у него оказалась не фонтан. Вдобавок, некоторые вещи у него конфигурируются только при старте (реврайты для JetStream в частности). Плюс нашли пару багов, которые зарепортили и их подтвердили.
В итоге NATS видится неплохим решением для небольших компаний и не очень больших нагрузок. Да, он минималистичен и прост, поддерживает много всего, но лично для нас это не было целевыми показателями, а по ключевым он не вывез(
Самый простой из доступных вариантов — это TCP. Однако он достаточно низкоуровневый, в частности heartbeat нам придётся реализовывать самостоятельно
В TCP есть такая штука, как keepalive. Настраивается параметрами сокета TCP_KEEP*, либо через sysctl.
Опять эти мифические RPS для измерения нагрузки...
5 млн RPS с обслуживанием в 10 микросекунд на запрос и те же 5 млн RPS с обслуживанием по минуте на запрос - это совершенно разная нагрузка, отличающаяся на порядки.
Нагрузку мерят либо в часозанятиях, либо в эрлангах.
Безусловно вы правы.
Выбор оптимизируемой метрики определяется целью — в нашем случае нужно было держать нагрузку на продовый кластер без чрезмерного оверхеда.
Поскольку кафка занимается в основном перекладыванием байтиков, то и оптимизировали мы именно его :)
Был у меня опыт работы с одной системой. Она в синхронном режиме обслуживала HTTP-запросы. Так вот, наступает час X. По трафику всё в норме, по CPU всё в норме, количество запросов тоже не так чтобы большое. Растёт только количество потоков в пуле jetty, но они, при этом, ничем особо не заняты. А система встаёт колом.
Логичный вопрос от руководства: "как так?" ОК, садишься, поднимаешь логи, пишешь скрипт, который интегрирует время обслуживания каждого запроса по HTTP с заданным интервалом (например, 5 минут). Строишь график и наблюдаешь, как значения на полученных временных интервалах растут по экспоненте начиная с определённого количества запросов в минуту.
А причина, как выясняется позже, вполне банальная: jetty-пул обслуживает не только внешние запросы, но и внутренние RPC-запросы, из-за чего возникает так называемый "лавинный эффект", когда внешний запрос триггерит цепочку RPC-запросов и, в итоге, эта цепочка заворачивается в кольцо.
Учитывая то, что jetty-пул потоков не бесконечный, система встаёт в ожидание освобождения потока, а все потоки в пуле при этом находятся в ожидании ответа по RPC, т.е. возникает своеобразный логический дедлок по ограниченному ресурсу - потокам.
Ошибка в проектировании и реализации? Однозначно. Но обнаружить такое с обычным мониторингом RPS невозможно.
Так что пока вы не имеете хотя бы приближённого числа в часозанятиях, есть риск вот так же наколоться.
Все очень круто расписано, респект автору!
Заголовок конечно классный спору нету, 5 млн рас все дела, но камон 5млн рпс на 30к партиций серьезно? Выглядит, как залив системы ресурсами до нужных показателей
Систему делали для того, чтобы поставить её перед текущим боевым кластером, соответственно нагрузка на него определяла требования к прослойке.
Те самые миллионы rps - это нагрузка от тысяч различных потребителей по методам кафки produce и fetch (не единичные сообщения!). Мы постоянно работаем над оптимизацией потребителей через убеждение и тюнинг платформенных библиотек, но текущая ситуация именно такая.
Остался не раскрытым главный вопрос: зачем же нужна дополнительная прослойка перед Кафкой? Её API и механизм функционирования понятен и известен многим, многие имеют опыт работы с ней. Кроме того, есть комьюнити и StackOverflow где можно найти ответ на любой вопрос. Ваш сервис же не только отгрызает производительность и уменьшает надёжность, но и увеличивает объём знаний, которых надо освоить для полноценной работы.
Кроме того есть подозрение, что не все фичи Кафки поддерживаются. Как у вас обстоят дела с транзакционностью, ручным коммитами, слушателями ребалансировки? Вы поддерживаете реактивный API?
Прекрасный вопрос!
Главный ответ такой: в большой компании людям не очень интересно разбираться с тонкостями настройки kafka. Это хорошо , согласуется с опытом Avito.
В итоге мы реализовали упрощающий pub-sub интерфейс, позволяющий не думать об этом.
А вы их спрашивали? По-моему, разбираться в тонкостях вашего сервиса людям хочется ещё меньше. Кафку они хотя бы они знают и умеют с ней работать. И этот опыт трансферится в другие компании. Никаких больших сложностей в настройке я не замечал, внутренне Кафка - достаточно простая штука. Даже не понимаю о каких "сложностях" вы пишете.
В спринг буте, например, обычно всё сводится к добавлению аннотации и прописыванию брокеров и топика. Если вы используете какую-то экзотику то сами с себе злобные буратины
Как построить систему, способную выдерживать нагрузку в 5 млн rps