Еще один вариант генерации превьюшек для изображений с использованием AWS Lambda & golang + nodejs + nginx

[SDKiller]

То есть, если бы генерировали преевьюшки единовременно при заливке картинки, не понадобился бы редис и эта "блокирующая" функция.

[smarteq]

Я не стал уделять внимание в статье этому вопросу. Но видимо стоит это сделать.

Первая версия лямбда-функции была именно так и сделана. Через эвент s3. Там даже была немного драматичная ситуация с рекурсией в облаке о чем написал у себя в фейсбуке. Но я решил отказаться от этой идеи по ряду причин. Не стану бить себя пяткой в грудь что мой вариант лучше чем генерация превьюшек «единовременно». Но решающим аргументом в пользу такого подхода стала управляемость. Если «завтра» мне руководство скажет что у нас изменились требования к размерам превьюшек, я просто в prewmanager поменяю настройки пресетов и удалю кеш на s3. На мой взгляд это достаточно веский аргумент в пользу данного решения. Но в свою очередь Амазон дает возможность сделать и так, как Вы предлагаете.

[gecube]

Соглашусь, что система более гибкая. Более того — можно прикрутить доп.фичи. Например, сделать время жизни для превьюшек. Может пригодиться, если превьюшки нужны вот прям не все и не всегда. Немного сэкономим места взамен на время выполнения лямбды, если превью опять затребуется

[Akuma]

А подскажите деньго-затраты на поддержание такой вот системы именно на AWS? Желательно с указанием ваших объемов картинок и трафика по ним (знаю, что есть калькулятор, но там черт ногу сломит).

Сейчас у самого подобная система, только все на своем сервере. Картинок около 500 Гб, вместе превьюшками. Честно говоря не слишком удобно, т.к. на обычной ФС сложно сделать TTL для файлов превью и приходится хранить все и вся.

А вот система с пресетами очень удобна. Уже лет пять наверное такое использую на своих проектах :)

[smarteq]

На данном этапе у нас такое, «тестирование в продакшене» по этому нагрузки еще невысокие. По этому затраты прям совсем небольшие конкретно на этот участок.

[Akuma]

А в цифрах, если не секрет? :)
Для кого-то небольшие — это пара тыс. долларов в месяц ))

[smarteq]

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

[mgremlin]

Сайд-прожект хостит картинки на AWS S3, около 20Гб.
Трафика — ну, может, несколько гиг в месяц, потому что молотилка живет отдельно в DO, там же агрессивный кэш превьюх. Кстати, это удобный способ сделать TTL для них.

Сумма прописью в амазоне — 89 центов, и больше никогда не было. Бесплатный период уже over.
А что именно непонятно в калькуляторе? Имхо, там все вполне адекватно.

[ixside]

Интересно узнать что вы думаете на счет imgix.com.

[nd0ut]

или uploadcare.com

[smarteq]

Спасибо, буду знать.

[mgremlin]

Cloudinary еще.
Лично я, например, думаю, что это тупо дорого.
Я вот выше привел пример сайд-проекта — там десятки тысяч изображений. если их по паре раз дернуть в месяц — это уже сотня получится. А если не дергать — минимум месячного потребления в $10 играет.
В uploadcare подходящий тариф вообще 125 долларов в месяц стоит.

Кроме того, когда я тестировал, меня не устроило качество и скорость трансформации. Своими силами получилось лучше и дешевле.

[smarteq]

Добавлю к данному комментарию по поводу цены что можно в s3 настроить политиками перемещение «неиспользуемых» изображений в Glacier. Если часто к ним начнут обращаться — вернуть в standart.