Полупроприетарное ПО: Когда Open Source не совсем Open Source (проблема Internal)

Вы блять шутите: представьте, очередь с auto-delete, такая же, как 4000 других на этом же RMQ, на которых от 1 до 10 консьюмеров

Но когда именно на ней 4 consumer, все ок, добавляется такойже 5 и она моментально удаляется...

По всем логам и метрикам всех сервисов, железок и узлов все абсолютно ок

Как починили? Перезапустили ноды самого RMQ и оно заработало...

Ну как нахер так...

По какому принципу он может удалять 1 конкуретную очередь пока ты не перезагрузишь сам RMQ?

Это не ошибка кода, потому что (исключая то, что мы максимально прямолинейно с ним общаемся) она бы тогда повторилась и при перезагрузке

Это ошибка в \"battle-tested\" технологии, которая обязана гарантировать 1 свою главную обязанность - доставлять данные от паблишера консьюмеру по объявленным очередям

Вы знаете что о такой ситуации пишут в коммьюнити? Переходите на quorum очереди

А знаете что такое quorum очереди? Это очереди с кластеризованным персистентным хранилищем (Kafka, без лога)

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

Но, во-первых, суть блять взятия RMQ была именно в том, что нас в этих очередях не нужна персистентность, нас интересовала скорость с гарантией последовательности, во-вторых, почему кластеризация должна решать вопрос ошибок в кор механике самой системы не давая ей самостоятельно удалить вашу очередь «просто-потому что»

По факту они предлагают делать латентную версию Kafka, чтобы просто повысить шанс, что RMQ не трахнет вас очередным внутренним багом...

P.S.

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

После удаления очереди эта сука не только НЕ ПРИСЛАЛ ОШИБКУ, так ещё эта гнида ПРОДОЛЖАЛА ДЕРЖАТЬ ОТКРЫТЫЕ КАНАЛЫ на эту очередь

Мы смогли продебажить и увидели, что это не приложение продолжало держать каналы, а сам RMQ

И он воообще ничего нам не сообщил, ни ошибки, ни инфы о смерти очереди

Вот этому нет никакого оправдания

P.P.S.

Я до сих пор в таком шоке, что я надеюсь, что это мы где-то накосепорили и всему этому есть объяснение, потому что ну как тогда вообще можно использовать RMQ, если он может такое вытворять (а используют его многие)

Если ситуация повторится и мы получим больше инфы, я напишу

я чет всю жизнь успешно избегал кролика )

А что юзал Kafka?
Или ты избегал микросервисов?

да, я в микросервисную движуху никогда не вписывался )

очереди только для воркеров, бг джоб и всякого процессинга. Redis + Bull обычно, пробовал на одном проекте SQS Амазоновский

А объясни плиз бг джоб?

Никогда не было интересно или не нужно было на самом деле?

Смотрел Кирилла, который рассказывал что микросервисы это в первую очередь организационное решение вынужденное из-за большого количества команд и сервисов которые лучше разделить просто чтобы было проще мониторить в разных репах, чем 1 монолит.

Хотя с точки зрения инфраструктуры это намного сложнеее

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

Инфраструктурно-технически однозначно сложнее. Однозначно дороже и однозначно трудозатратнее.

Как бы иметь пачку сервисов на других технологиях - потому что так удобнее/оптимальнее. Тут да, сервисы отдельно висят. Даже через sqs вот общались. )

А как те serverless пробовали на проектах?

Приходили легаси решения. Ну такое).
В serverless фреймворке (который вот основной) - все намешано и конфигурация инфры с клаудформейшеном и лямбды и плагины. Потом собираешь эти ямлы. Что конечно вносит свой странный привкус 💩 когда на нем пишешь. ) Хотя в целом все там неплохо. Но скорее на любителя
Ну и если брать конечные косты, то выходит довольно дешево для стартапов, которые проверяют гипотезу и скорее умрут. И как-то не очень дешево если нет.
Опять же есть точечные крутые юзкейсы лямбд, когда, например, нужно что-то внутри авса исполнить и по вебхуку трегерить (сложнее чем пачку cli команд)

Да, согласен, или если нужна пачка функций по генеру доков/отчетов которые если делать на EC2 с круглосуточным пэйментом дофига получится, а сделать пару лямбд супер дешево и достаточно быстро учитывая что это внутренняя корпо штука)

Корпо юзеры могут и подождать🤣

Мы обычно ecs поднимаем c fargate. Там тоже прям копейки выходят. Но тут у лямбд тоже есть ниша, согласен.

Счастливый человек…

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

Сейчас суть была скорее в очереди формата pub/sub

И RMQ это именно оно, но блять…

Кстати продолжение дебагинга показывает что RMQ просто не умеет в нормальный fail-over при разрыве сети

Ещё есть одна причина: вертикальный скейл дороже горизонтального.

Разве? Мне кажется, что вертикальный скейл часто дешевле взятия новой тачки (потому что там всегда есть статическая стоимость за штуку)

У него есть четкие лимиты и он намного дороже в момент, когда вы в эти лимиты уперлись, это да

Это если нагрузка одинаковая. А если есть пики и просадки?

Да, тут полностью согласен

Да, так и есть. Кейс только о потолке, а он отличается, но всегда присутствует.