Распределенный stateless парсер для IoT: гибридное решение с Redis

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

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

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

Хотели переделать на БД, как я писал в посте выше, но поняли, что БД будет плохо от кол-ва UPDATE статусов сообщений, а добавлять еще один инстанс / использовать другую БД, ну можно, но хотелось что-то попроще

Тогда с коллегой пришли к гибридному решению:

- Парсеры отправляют события, что они готовы обработать сообщений
- Сервисы сокетов (в которые приходят сообщения от устройств) получают эти события, смотрят какие контроллеры сейчас не в обработке, отправляет (тоже через событие) сообщения одного из них и лочит в redis (просто SET locked:${controller_id})
- Парсер пока парсит полученное сообщение сообщение делает раз в Х секунд запись в redis с текущей датой (SET message-health-check:${controller__id}), а в конце обработки удаляет лок из redis (DEL locked:${controller_id})
- Сервисы сокетов раз в N секунд проверяют когда были записи с последней датой в redis, если они были раньше чем Y секунд, то значит парсер умер не доработав сообщения и тогда мы разлачиваем контроллер
- Ну и напоследок подписались на удаление лока, чтобы разлачивать локально

Что мы этим получили:

- Парсеры и Сокеты могут как масштабироваться, так и падать в любом кол-ве, потому что теперь они полностью stateless (контроллеры не завязаны на них) и система продолжит работать
- Поскольку Парсеры теперь работают по pull модели, мы можем просто делать rate-limit даже не уровне кода
- Каждый отдельный сокет управляет только своим набором сообщений
- Никакой синхронной коммуникации (все на событиях), что дает сервисам возможность падать и подниматься сколько угодно раз
- Поскольку локи в redis, даже при переключении контроллера между сокетами мы случайно не возьмем его в обработку

Короче, если уж решили "stateless", то и масштабирование надо строить по stateless, то есть, не привязывать что-либо, к чему либо

ужасно на самом деле. столько стейта, который надо контролировать и координировать

В смысле?

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

Про акторы я писал выше, это была первая идея, но с акторами как раз таки и беда в том, что они или будут жить в памяти приложений (а значит, надо писать привязки и ребалансинг, а значит у нас stateful) или же в redis, а значит модель выше +- тоже самое (и мы к таким акторам и придем)

В данной ситуации есть только распределенный лок + health check в редис, да state, но не привязанный к какому-то конкретному инстансу / приложению, а значит каждое по отдельности является stateless

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

Актор должен быть только 1 на все инстансы, иначе это не актор -> Актор нужно четко привязать к какому-то инстансу, чтобы он не дублировался (привязка) -> Если падает инстанс, нужно взять все акторы с него и переназначить другим инстнасам (ребалансинг) -> Если поднимаются новые, нужно распределить акторы между всеми инстансами (ребалансинг)

Мы же говорим не про 1 инстанс приложения, а кубер и много инстансов

Актор должен быть только 1 на все инстансы, иначе это не актор - подробнее плиз. бывает такой актор, который синглтон, но это скорее исключение из правил

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

Если поднимаются новые, нужно распределить акторы между всеми инстансами (ребалансинг) - тоже само

\"подробнее плиз.\" – актор предполагает наличие стейта (в идеале в памяти, но если нет, то во внешнем горячем хранилище, который четко завязан на актора\"), соответственно, 1 экземпляр актора (в нашей случае даджитал твин автомата, который мы называем \"контроллер\") должен быть размещен в 1 инстансе из N кол-ва (потому что инстансов этого приложения будет много)

\"само происходит в зрелых фреймворках\" – мы решили проблему и ускорили систему в 200 строчек кода, 2 очереди на инстанс (вместо N по кол-ву контроллеров) и 2 ключа в редисе, твое предложении втаскивать фреймворк (которого на Node.js + TS, я например вообще не знаю), чтобы решить этуже задачу, но более сложным путем, создав кучу точек отказа (в виде привязок и ребалансироваки, которую даже если берет на себя фреймворк, все равно менеджерить и поддерживать в актуальном состоянии нам)

Я даже сумел описать это решение в 5 пунктах этого поста (там реально больше ничего нет), оно настолько компактное, простое, тестируемое и рабочее

+ если уж говорить про акторы то, если вы умеете в транспорт (NATS, Kafka, RMQ), диискавери (Consul), распределенное хранилище (etcd) и свой язык программирования, то написать акторов самостоятельно более хорошая идея, чем пытаться затащить какую-нибудь Akka, потому что в акторах нет ничего уникального, но при этом нужна самая маскимальная тонкость настройки

Я это все к чему: мы даже пишем акторы на другом проекте, и там вот это все есть, но там и задача совершенно другая, там нет ребалансировки и простая привязка, потому что приложения находятся на удаленных тачках и следят за устройствами находящимися рядом с ними, но при этом нужно много real-time быстрой обработки стейта, соблюдение очередности и realtime health-check

Там акторы прям в точку и они прям простые

Здесь задача была иметь возможность обрабатывать сообщения параллельно между контроллерами и последовательно в рамках 1 контроллера + чтобы не надо было вообще задумываться \"живы ли все 10 подов или только 1\" и система при этом продолжала работать + чтобы была высокая скорость

Мы добились этого суперлакончиным решением (я даже могу написать github gist с кодом)

Про простое решение из моего опыта 😋
Пока редис в режиме single node это схема кажется простым решением, потом это станет паттерн distributed lock, а потом с увеличением rps проблемой распределения партиций. В итоге самое простое будет вертикальное масштабирование такой системы, потому что такова цена самого решения.
Лучше никогда не использовать блокировки в растущем месте, иначе стоимость поддержки этого решения будет геометрически расти.

Да, 100%, если встанет вопрос с тем, что single instance не выдерживает, будем искать другое решение

Но я рассчитал RPS даже при росте нагрузки и мы еще очень долго не столкнемся с проблемами

Я главное хотел подсветить противодействие \"best practice\" и \"вашей конкретной ситуации\" и что если позволяют знания и решение достаточно простое, лучше ориентироваться на него, а не пытаться втащить какой-то гигантский best-practise