В одной из прошлых статей о NestJS + GraphQL + Lambda я получил очень интересный комментарий. Поэтому и решил поделится своими мыслями и опытом о том, когда все-таки стоит использовать Lambda функцию, а когда - нет.
Я буду говорить про AWS Lambda, потому что имею с AWS больше всего опыта. Для начала давайте рассмотрим основные свойства лямбда - функции:
вы платите только за время выполнения и за трафик между лямбда и другими AWS сервисами
бесплатный уровень использования 1 млн вызовов и 400 000 ГБ-секунд вычислений в месяц
очень хорошо интегрируется с другими сервисами AWS
горизонтальное авто масштабирование
Итак из первого свойства мы видим, что AWS не запускает ваш код просто так, а только когда это необходимо. Из этого следует один минус - время холодного старта. Это время с начала вызова лямбда функции и до момента когда приложение поднимется и начнет выполнять что-то полезное.
И тут есть всем известный лайф-хак.
AWS держит ваше приложение запущенным 15 мин с момента последнего вызова. И при этом вы оплачиваете только время выполнения. Поэтому появилось такое понятие как прогрев лямбда-функции. Для этого можно использовать другую лямбда функцию, которая раз в 12 минут (например) будет вызывать health метод во всех лямбда функциях, которые необходимо прогреть. Но все равно это затратно.
Мой топ использования лямбда функций:
Бесплатный хостинг
Если объединить “оплата только за время выполнения” и “бесплатный уровень использования” можно получить отличный бесплатный хостинг для не нагруженных проектов. Для которых не особо важно время холодного старта. Также еще можно добавить бесплатную MongoDB в том же AWS регионе при помощи этого сервиса mongodb.com и получим полноценный backend. Пример использования описан в этой статье
Обработка файлов
Я очень часто использую S3 для хранения файлов. А лямбда умеет хорошо интегрироваться с сервисом S3. Поэтому можно настроить вызов лямбды при добавление нового файла в S3. Что это дает? Можно например нарезать thumb с одной большой картинки во всех форматах и класть опять же в S3. ( более подробно в этой статье).
Либо вот пример готового стека, его можно развернуть в течение 5 минут в своем AWS акаунте. В этом примере лямбда вызывается по запросу пользователя в CloudFront и если видео еще не преобразовано, то запускается нарезка видео на кусочки hls потока. При следующем запуске видео уже берется напрямую из S3. Кроме этого уже существует огромное количество готовых решений
Обработка очереди
Лямбда функцию можно использовать как обработчик в очереди AWS SQS. Но тут нужно понимать выгодно ли это. Если большая нагрузка, то чаще всего выгодней поднимать свой обработчик на отдельном сервере.
Ограничения
Нужно не забывать об ограниченях, с которыми сталкиваешься при разработке:
максимальное время исполнения - 900 секунд (15 мин). Если у вас задача, для которой надо больше времени, то лямбда это не лучшее решение.
время холодного старта (подробнее описал выше)
максимальный размер архива лямбды 50 МБ, а распакованный размер всего кода лямбды с модулями не должен превышать 250 МБ. И тут очень важно использовать правильные модули для своих приложений. Так как, бывают такие, которые в себе содержат бинарники с достаточно большим размером.
максимальный размер всех лямбда функций, загруженных в этот аккаунт, со всеми версиями этих функций и слоями не должны превышать 75 ГБ. Это очень важное ограничение. (может быть увеличено по запросу)
максимальное количество паралельно запущенных лямб - 1000. (может быть увеличено по запросу)
для работы с файлами выделяется конкретная папка /tmp, масимальный размер которой не должен превышать 500 МБ
Выводы: использование лямбд очень хорошо ложится в начале пути проекта. А также в местах, не часто вызывающихся. Она удобно и быстро разворачивается, но как только мы приближаемся к статусу High Load - нужно срочно переосмысливать архитектуру проекта и переходить на собственную инфраструктуру, например на kubernetes.io
