Комментарии 12
Не смотрели в сторону лямбды?
Выглядит как хорошее применение для нее: вам хватит минимальных лямбд, цена вроде бы значительно дешевле выйдет(по крайней мере так кажется), автомасштабирование из коробки. Инфраструктура для вашего варианта даже упростится.
Интересное предложение, спасибо. С лямбдами вообще экспериментируем, но к этому сервису не прикладывали.
А Puppeteer на них заведётся? Он довольно требователен к окружению, т.к. поднимает настоящий Headless Chrome.
Я с Puppeteer неработал, поэтому сложно сказать, но в лямбду можно подсунуть свой контейнер, на котором будет все нужное установлено, так что я бы сказал что вряд ли это будет проблемой.
У лямбды есть нюанс с колд стартами, надо проверять если там целый движок хрома может оказаться что будет тратиться много времени на его подъем и окажется что держать поднятый инстанс выйдет дешевле/проще.
Но с другой стороны проверить как работает Puppeteer в лямбде и прикинуть цену можно за пару часов(т.к. вы хорошо представляете сколько запросов сейчас идет, вся остальная инфраструктура неменяется(ELB, cloudwatch, s3). Немалеьникй шанс что цена может упасть очень значительно.
В целом по лямбдам-отличный сервис, но хватает подводных камней которые стоит учитывать при разработке. Самая большая проблема-сесионность, т.е. нюансы со всеми кэшами внутри приложений, проблемы если нужно держать коннекшен с бд, ограничения по времение работы, автомасштабирование при неправильном применении может легко положить бэкенд стоящий за лямбдами. Но когда это ненужно все\решено другими способами, то лямбда -отличный выбор.
Лямбда не всегда запускает новый контейнер на каждый запрос — контейнеры переиспользуются между запусками и остаются поднятыми некоторое время (примерно 10-15 минут)
Контейнер живет ~40 минут если используется.
Но все несколько сложнее-1 контейнер обрабатывает всегда 1 запрос. Поэтому колчиество колд стартов получается очень большое.
Дальше у лямбды есть еще нюанс в виде неявного хранилища-у 128мб лямбд диск выдет значительно меньше иопсов.У нас был сервис на ноде в котором зависимостями был очень много бибилиотек-на 128 мб оперативы локально он поднимался за300-400 мс, в лямбде-5-15с. Оказалось что проблема именно в чтении с диска, пришлось перевести на 1гиговую лямбду и проблема решилась(колд старт 300-400 мс).
При том что тут внутри сидит хром колд старт может быть довольно долгим и из-за нюансов их количество будет довольно большим, несравнимым с VPS.
Это можно посчитать, но надо хотя бы примерно понимать время колд старта и профиль нагрузки.
Puppeteer заведется. Мы используем связку CDK + ECR + Lambda as DockerImage для генерации PDF, единственное, что для больших документов требуется порядка 3 Гб памяти.
На всем, что требовало постоянной работы, лямбды у нас выходили дороже причем кратно.
Спасибо, интересный пост!
На мой взгляд, для нагруженных систем ECS должен быть выгоднее чем Lambda.
А для дальнейшей экономии я бы посмотрел на
ECS on EC2 - при правильно подобранном типе машин может быть выгоднее
CDN для экономии траффика
Спасибо!
У нас была гипотеза, что Fargate за счёт легковесности стоит дороже EC2. Планировали перевести контейнеры на виртуалки EC2. Но, когда посчитали стоимость, оказалось, что Fargate стоит ровно столько же. Один из burstable инстансов (T) выходил чуть дешевле, но мы бы скорее всего упёрлись в CPU credits.
Как мы в Plesk в 2 раза снизили стоимость инфраструктуры AWS для нагруженного сервиса