DevOps без Dev, с какой стороны подступиться?

Как Kafka это когда после 50K партиций начинаем тормозить, а на 100K (типичный размер для крупного проекта) стоим колом?

Вы таки что-то делаете не так.

Вы таки что-то делаете не так.

Всё так. Кафка криво спроектирована, когда что-то на кластере начинает меняться, то контроллер через синхронных zk начинает менять статусы, это работать не может в принципе. У них, кстати, был KIP на улучшение этого места.

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

Яндекс в какой-то момент выпилил кафку и реализовал свою over YDB. Не спроста наверно.

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

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

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

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

Не пофиг, ему же снапшот надо писать, если на тех же дисках будет жить кто-то еще, то zk будет таймаутится. А если вдруг не повезет и снапшот превысит 100M, то совсем работать плохо будет. На наших тестах было так.

Такая мелочь вообще в кэшах рейда живет.

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

API шлюз расположен по адресу https://приложуха.execute-api.регион.amazonaws.com/ . Если нагрузка слишком большая, то запросы просто отсекаются:
https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html
По лимитам на обычные запросы можно договориться с админами, которые руками подвинут другие сервисы с твоего «балансера».

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

Если у рейда свой кеш с батарейкой, то может быть. У нас не было рейдов с памятью и батарейкой, только обычные софт рейды-1.

Лучше расскажите как эти вещи ведут себя под DDOS. Оно понятно, что динамически можно любую мощь поднять, развернуть и обслуживать миллионы запросов в секунду
Вопрос лишь в том, что при этом станет с кошельком

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

Если у рейда свой кеш с батарейкой, то может быть. У нас не было рейдов с памятью и батарейкой, только обычные софт рейды-1.

P440ar, ессно с батарейкой.

и пользователи получают ответы медленнее

Ну и разве это не значит что сервер не может одновременно обслужить N пользователей?

Ну и разве это не значит что сервер не может одновременно обслужить N пользователей?

По херак-херак канону подразумевается, что максимальное число пользователей — это то, при котором гарантируется отсутствие лавинообразного колапса системы. Зона с пониженной нагрузкой и повышенной скоростью отклика не берется в рассмотрение, зачастую потому, что время отклика само по себе достаточно большое (скрипты+БД).

Еще раз - у меня сервер одновременно может обслужить 10 пользователей. Если придет 11 - он там не влазит в кэш, в хип, в полосу, в пулл коннектов к базе, да куда угодно. По-этому он "подождет". Это и значит что у меня сервер может обслужить только 10 пользователей одновременно. 11 пользователей он тоже может обслужить, но уже не одновременно.

время отклика само по себе достаточно большое (скрипты+БД)

"Достаточно большое" это сколько в цифрах?

Еще раз - у меня сервер одновременно может обслужить 10 пользователей. Если придет 11 - он там не влазит в кэш, в хип, в полосу, в пулл коннектов к базе, да куда угодно. По-этому он «подождет». Это и значит что у меня сервер может обслужить только 10 пользователей одновременно. 11 пользователей он тоже может обслужить, но уже не одновременно

Такая картина может наблюдаться разве что на очень простых сценариях. При малейшем усложнении уже оказывается, что разные запросы занимают разные ресурсы, сервер потенциально может обслужить и 20-30 клиентов, но в самом худшем типовом сценарии — только 10. А злоумышленник может придумать, как через один запрос полностью загрузить сервер.

время отклика само по себе достаточно большое (скрипты+БД)

«Достаточно большое» это сколько в цифрах?

В моем старом проекте время работы скриптов на тяжелых запросах было раз в десять больше, чем БД. Однако, на легких запросах скрипты работали примерно как БД. Вот и придумай мне теперь, сколько одновременно пользователей сервер может обрабатывать. Обычно в херак-херак принято по большому пальцу прикидывать допустимую нагрузку и жестко резать всё что выше. Потом удивляться, что сервер простаивает, поднимать лимит, узнавать что сервер упал, опускать лимит. Чуть более прокачанные сервера могут резать клиентов по свободным ресурсам.

Amazon при этом никуда от проблемы не убежал и ему приходится держать избыточные мощности вместо вас, вытряхивая при этом из вас себестоимость х10-30.

Обычно в херак-херак принято по большому пальцу прикидывать допустимую нагрузку и жестко резать всё что выше.

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

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

На мой старый проект было выделено стопицот ядер. Угадай сколько виртуалок у меня было.

Такая картина может наблюдаться разве что на очень простых сценариях. При малейшем усложнении уже оказывается, что разные запросы занимают разные ресурсы, сервер потенциально может обслужить и 20-30 клиентов, но в самом худшем типовом сценарии — только 10.

Если писать немасштабируемые лапшемонолиты то да.

Обычно разработчики и эксплуатация знает сколько запросов может нормально обслужить их приложение

Сделали минимальную правку на серваке, вплоть до «поменяли цифру в конфиге», потестрировали — вроде нагрузку ту же держит. Запускаете на проде — на пиках сервак валится. Ваш ход.

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

У вас там авось не AWS, чтобы иметь всегда излишек и добавлять по необходимости программно.

На мой старый проект было выделено стопицот ядер. Угадай сколько виртуалок у меня было

Какое это отношение имеет к обсуждению?

Если писать немасштабируемые лапшемонолиты то да

Расскажи мне истории про то, как у замечательных сервисов нет проблем «один сервис стоит, у второго миллион запросов в очереди».

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

4.2 в промышленных средах иногда ВНЕЗАПНО находят баги в Arista’вских свичах. Не далее чем два месяца назад это дало нам замечательную возможно провести выходные с перекидыванием приложений между серваками. Бондинг не спасет, при пропадании соседа вечером пятницы (период максимальной нагрузки) второй свич просто ляжет, когда на него пойдет весь трафик (а там еще как раз ретраи наложатся, и уровня ОС, и от приложений). А если там еще хранилка подключена для виртуалок - вообще шикарно будет.

выделенные DL360Gen9

и шо, не задалбывает вентиляторы менять?

и шо, не задалбывает вентиляторы менять?

Они на гарантии, хэпэшники сами бегают по ДЦ и меняют. Мониторинг настроен, тикеты в джире сам генерит на замену.

промышленных средах иногда ВНЕЗАПНО находят баги в Arista’вских свичах

Находят, но у нас 24/7, пятница от непятницы отличается только тем, что в случае аврала люди чинят все в непятницу. Но свитчи не ложатся от трафика, ибо опять же, спроектировано все так, чтобы на одном свитче работать могло.

Яндекс в какой-то момент выпилил кафку и реализовал свою over YDB. Не спроста наверно.

Я слушал как-то подкаст с руководителем проекта ydb. Он так и не смог внятно объяснить, зачем они написали свой аналог и где минусы кафки, которые они не могли решить хотя бы форком.

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

Возможны варианты. Потому что один сервер тоже может выжимать достаточно много. Например, обслуживание порядка 80 гигабит трафика.

Я слушал как-то подкаст с руководителем проекта ydb. Он так и не смог внятно объяснить, зачем они написали свой аналог и где минусы кафки, которые они не могли решить хотя бы форком.

Я выше рассказал о минусах. Кафка плохо масштабируется, не надежна, теряет данные, её надо использовать исключительно на рейдах с батарейками. Форком эти проблемы решить невозможно.

Кстати что за подкаст был? Я знаю руководителя ydb, он в состоянии рассказать о минусах кафки.

Кстати что за подкаст был? Я знаю руководителя ydb, он в состоянии рассказать о минусах кафки.

devzen. не помню имени

Спасибо, глянул. Это он, подтверждаю :) Я прослушал только первые 30 секунд, не знаю что он там наговорил про кафку, но могу в защиту сказать, что Андрей – ооочень занятой человек и мог и забыть в деталях почему и каким образом выпиливали кафку в 2016-2017 годах и делали аналог over ydb.

Я выше рассказал о минусах. Кафка плохо масштабируется, не надежна, теряет данные, её надо использовать исключительно на рейдах с батарейками. Форком эти проблемы решить невозможно.

Многое зависит от цели использования. Да, мы тоже не смогли посадить на нее большой поток (порядка 1,5kk eps), но как замена сислогу с большим уровнем гарантией, чем udp :) вполне живо на потоках до 100k eps. И сделано без рейдов на чистых sata hdd.

Проблемы zk - они везде проблемы zk. Везде, где он есть - они очень однотипны. Например, кликхауз.

мог и забыть в деталях почему и каким образом выпиливали кафку в 2016-2017 годах и делали аналог over ydb

Вполне возможно, что в 16 году с кафкой все было много хуже. Сейчас она более зрелый продукт, но все равно конечно с косяками.

Там не только в zk дело. Кафка каждую партицию пишет в отдельный файл, что выливается в тормоза если писать с синком, а если писать без синка, то будем терять данные при выключении кластера по питанию. Более того, при таких аварийных завершениях там дело не только в потерях данных, партиции становятся рассогласованными. Например, на одна машина лидерует по одним партициям, а другая по другим. На это дело в фетчере фолловера есть проверка, которая гасит ноду. Из-за чего, кластер после аварийного завершения без ручных действий поднять невозможно, более того, нет никаких штатных утилит для его поднятия.

Можно конечно забить на все и включить настройки типа allowTruncate (или как оно там называлось, забыл уже) и т.п. Но это годится только если данные не важны.

Потом кафка очень плохо переживает выключение дисков. Точнее совсем не переживает, просто падает и всё, а дальше, как говорится, трахайтесь как хотите.

выпиливали кафку в 2016-2017

Кафка с тех пор мягко говоря изменилась. Еще бы вспомнили, что было при царе Горохе…

Уверен, что основные вещи, например партиция==файл и протокол репликации остались.