• говно aws Представим простую задачу. Итак, задача — написать сервис, который будет принимать запрос, брать из него пару полей, загружать из базы данных несколько URL-ов, ассоциированных с этими полями — и, наконец, совершать HTTP-запросы на все найденные в базе URL-ы. Простейшая задача. Назовём её демультиплексер вебхуков. Это и впрямь будет некий ретранслятор, размножитель. Из одного вебхука делает десяток.

    Как бы такую задачу решил нормальный разработчик?

    Да элементарно. Развернул бы какой-нибудь Express, написал бы эндпоинт соответствующий, в нём бы сделал выборку из базы, дальше — цикл, в цикле отправлял бы запросы.

    И тут начинается интересное.

    Нигде не сказано, сколько URL-ов предполагается найти в базе. Чаще всего 0, часто 1, может быть и 10, и 300, и 10000 (но редко).

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

    Не хотелось бы платить за простои серверных мощностей, но и хотелось бы держать пиковую нагрузку. Значит, что у нас будет? Ага, AWS Lambda, она, родимая.

    А с лямбдой шутки плохи, она любит отработать по-быстрому, и свалить в закат. Как бы нам в ней организовать цикл, делающий запросы? Упадёт ведь через 30 секунд.

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

    И тут возникает соблазн забить на лямбды, и переписать всё обратно под Express.

    И начинаем мысленно городить конструкции с пулом воркеров, ручным контролем конкуррентности, ретрай-полиси, очередями итд. Потому что и память может закончиться, и всё на свете.

    А потом останавливаем себя и вспоминаем, что есть AWS StepFunctions, где всё это уже придумано за нас как раз для такого класса задач, и где упор сделан как раз на умное управление ресурсами, надёжость и высокую доступность.

    Единственный минус — для этого не нужно быть программистом, мозги атрофируются. Все сложные решения надёжно скрыты под капотом механизма оркестрации, а программисту предлагается только написать код для элементарных единичных действий, каждое из которых будет выполняться в отдельной функции. Ну и ещё, пожалуй, огромный минус такого "супермаркетного" подхода — в жирнющем vendor lock. Писать "под AWS" становится трендом, и уже плодится армия программистов, по-другому не умеющих. И бизнес это устраивает.

    Налицо узкая специализация труда с выходом на рынок разрабов-прикладников. Раньше были одинэсники, а теперь вот — авээсники.
    ♡ recommended by @entoni

Replies (4)

  • @janPona, Просто сделай несколько разных лямбд. Одна достает из базы url-ы и складывает в SQS, другие выгребают эти запросы из очереди и теребонькают. Все тогда нормально скалируется под любое кол-во запросов

    @janPona
  • @Anonymous, так это под капотом одно и то же. Только StepFunctions лучше, потому что:

    — очереди инкапсулированы, и о них не нужно думать как об очередях
    — как результат, невозможно сделать случайно очередь линейной, например, так, что вебхук, порождающий 5 вторичных вебхуков, будет ждать, пока отработает предыдущий вебхук, породивший 10000 вторичных вебхуков
    — SF может легко сделать саммари, сколько каких запросов в рассылаемой пачке в итоге упало
  • @Anonymous, ощущение что вы пытаетесь переизобрести RabbitMQ — вообще, это достаточно стандартная задача, должна решаться на уровне сисадмина, по-моему
  • @janPona, первый интересный тред за последний месяц