Как лучше организовать микросевисы основанных на Docker написанных на node.js?

Question

[Sergey Romanov]

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

Каждый созданный пользователем проект будет запускать контейнер докера с ноуд на нем, который будет опрашивать устройства. Например пользователь создал устройства и установил частоту опроса в 2000 миллисекунд. Мы получим что то типа

setInterval(function(){
    // опрасить устройство
    // сохранить данные в базе
}, 2000);

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

Таким образом между сервером АПИ и контейнером проекта не будет прямой связи, и контейнер проекта будет полностью изолирован и все порты на вход будут закрыты.

К слову база данных это служба AWS RDS так что доступ к ней всегда будет внутри VPC.

Вопросы

1. Я на правильном пути?
2. Какие есть инструменты или скажем пакеты npm что бы запускать небольшие циклические задача, и останавливать а так же следить за их состоянием. Просто не знаю какие ключевые слова тут использовать что бы начать поиск.
3. Проект может содержать 100 устройств а каждое устройство от 1 до 100 каналов опроса. Это значит до (а может и больше) 1000 маленьких процессов опроса типа как пример я привел. Правильно ли запускать контейнер на проект или лучше запустить контейнер на устройство? Я вижу преимущество в контейнере на устройство в том, что если будет проблема с опросом устройства это не отразиться на других устройствах. И будет просто включить выключить, просто запустить или остановить контейнер. Но вижу недостаток в том, что будет очень много контейнеров в кластере и переживаю, что много ресурсов будут съедать сами контейнеры.

Comments

[Иван Шумов]

А устройства, конечно, сами отправлять информацию не могут? И по каким протоколам опрашиваются устройства?

[Иван Шумов]

Если это просто health-check по http то у меня есть пара интересных идей)

[Sergey Romanov]

Иван Шумов, Modbus TCP. Будут и те что сами отправляют по MQTT но это бедующее пока нужно обеспечить работу так.

[Sergey Romanov]

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

[Иван Шумов]

Sergey Romanov, я до поздна занят) Сейчас напишу решение

Answer 1

[Иван Шумов]

по контейнеру на одну таску может быть дорого даже при Fargate. Я бы перестал заниматься фигней и взял AWS StepFunctions c Wait:


Создаем StepFunctions джобу с параметрами и инвокаем из нее Lambda в цикле. Все, никаких проблем не будет. Надо только учитывать что у решения лимит исполнения - 1 год, вроде. Дальше - пересоздавать.

Надо считать во-сколько это встанет, конечно. На Step Functions одна такая Джоба в месяц около 20$ может встать (10$ на SF и 10$ на Lambda), без необходимости дополнительного управления. Сохранять можно куда охота - хоть в CloudWatch, хоть куда потребуется.

Для сравнения - в минимуме на ECS + Fargate это выйдет в 10$ (если ресурсов хватит), но надо контролировать где-то дополнительно что все работает, инфраструктуру и вообще. Я бы переплатил за первый вариант

Comments

[Sergey Romanov]

Интересно. Я думал о лямбдах. Они у меня будут следить за базой и трегерится, но делать опросы я на них не хотел чисто из за экономических соображении. На ECS я смогу легко контролировать если контейнер выпал, просто его пересоздаю и все. Лямбда там наверно придется к стати. Но я не хотел серверлес решения. На сервисах все можно замутить, можно было и GatewayAPI и для статики CloudFront и т.д. Может потом это и будет не дорого, но сейчас на старте хочется минимизировать расходы тоже и сразу сделать архитектуру с заделом на миллиарды запросов в день. А других способов чем ECS я просто не вижу.

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

[Иван Шумов]

Sergey Romanov, Ну, я не склоняю на эту сторону. Это как делал бы я) У ECS полно своих минусов с необходимостью контролировать сеть - один неверный чих и все контейнеры потеряли сеть или еще что. Тут также проблема в правильной утилизации ресурсов. Как распределять таски по задачам? 10$ на одну таску может быть нереально дорого (хотя я и предложил еще дороже)