Комментарии 11
Отличная статья! Спасибо :)
Отличная статься, хабр тот!
Неочевидная штука - по возможности нужно выносить все длительные инициализации из хендлера лямбды в статическую часть - эта часть кода выполняется во время инициализации контейнера без учета настроек по памяти/цпу (намного быстрее), плюс эти объекты сохраняются между вызовами, если их обслуживает тот же контейнер. Например - соединения с БД или клиенты для вызова других сервисов AWS.
Еще внутри функций есть эфемерный диск /tmp по-умолчанию 512MB, но за деньги можно до 10GB и он тоже сохраняется между вызовами того же контейнера, тч можно скачать и что-то там закешировать, если нужно. С этим нужно быть аккуратным в multi-tenant системах.
Чтобы уж совсем полирнуть можно добавить про RDS Proxy, CDK и SAM и тогда будет совсем исчерпывающе.
Совсем забыл добавить про глобальные переменные, которые сохраняются между вызовами, спасибо за дополнение!
Про CDK, SAM и Amplify - если в вашем приложении планируется хоть чуть-чуть сложный бэк, старайтесь избегать этих слов и использовать Terraform/Terragrunt, даже с учётом высокого TtM в начале.
CDK построен над CloudFormation и вроде удобная штука, но невозможно кастомизировать имена ресурсов так, как тебе хочется или было бы удобно искать + долгий деплой.
SAM - Упрощение CDK и CloudFormation.
Amplify - Упрощение CDK и помощь с CI/CD. Можно расширять через CDK, но только на TS. Очень плохая документация и трейс ошибок, много скрытого поведения и генерации лишних ресурсов. Использует CloudFormation Templates, что приводит к проблемам со сборкой проекта локально, когда у вас ARM, а в шаблоне x86, а вам надо засунуть либу с шифрованием. К тому же тут используется всего один Stack с кучей NestedStack. И очень, очень непонятная и раздражающая CLI для управления проектом...
Деплоим на CDK дофига сложного софта в AWS, все нормально. Кастомизировать имена ресурсов - вообще плохая практика, тк можно ограсти при редеплое (он не сможет создать новый ресурс и затем удалить старый, тк оно уже занято).
У SAM есть полезные вещи, типа локальной отладки лямбд, но я не использую, тк CDK уделывает его во всем остальном на голову.
Раз уж статья упоминает про оптимизацию расходов то хотелось бы понять за счет чего.
Лямбда на ARM64 стоит 13.3334 mkD за GBs
При 512 мб один лямбда-месяц будет стоить 17$ + стоимость вызовов.
ec2 t4g.nano с 512мб стоит 3$.
Итого в 5 раз больше, на тысячи инстансов будет существенно. ec2 так же скалируется через инстанс группы, хоть 1 инстанс хоть 1000.
Лямбда не будет работать круглые сутки(да и не должна), а лишь отработает на запрос в течении нескольких секунд(макс). Идеально для CRUD, CRON или любых других EventDriven задач, но при этом не надо думать о настройке ec2, групп или политик.
Лямбда не будет работать круглые сутки(да и не должна), а лишь отработает на запрос в течении нескольких секунд(макс).
Если мы говорим не про пет-проект то запросов будет больше одного в час. Вот в посте упоминается про 1000 лямбд одновременно. Точно так же группа инстансов задаунскейлится под количество запросов. И без приседаний с cold start и резервированием.
А если это задачка посчитать раз в день по крону то и обсуждать будет это 3 доллара в месяц или полтора - бессмысленно.
Так в чем именно тут профит?
при этом не надо думать о настройке ec2, групп или политик.
Ну хорошо, экономия на работе девопса. Но прямо в посте как раз наоборот в этом разубеждают:
К сожалению, это все отнимает огромное время. Хоть терраформ(HCL) имеет хорошую документацию и тернарные операторы, в нем все равно очень много вещей требуют большого погружения и больших ресурсов. Например, деплоймент приватного API Gateway с 1 лямбда интеграцией занимает где-то 200 строк кода.
Если уж говорится про экономию то хотелось бы узнать предметнее из чего эта экономия состоит. Например сравнением трудозатрат на деплой того же самого сервиса в автоскейлинг группу.
Сами лямбды деплояться относительно просто, сложность заключается в связывание ресурсов. Такая же проблема будет в любых микросервисах: в кубере, в EC2 и тд.
У лямбд есть преимущество в логике скалирования: они скалируются по длительности выполнения: если ивенты к лямбдам начинают собираться в очередь, то запускаются еще лямбды. У ec2 и k8s, если мне не изменяет память, такой логики нет.
Скорость скалирования и дескалирования у лямбд намного выше почти любого ec2 и k8s
Лямбды в основном для EDA используются вместе с другими serverless сервисами. Если нужна обработка дольше 15 минут или дофига памяти - тут уже надо смотреть на контейнеры и ec2
Большое спасибо за статью!
Бекенд на AWS Lambda за 60 минут