видел по 65 миллиардов IO в месяц (но там много было инсертов и апдейтов)

потом соптимизировали до 15 примерно

проблема в том что сейчас все на ДО и никакого мониторинга постгри внешнего нет. я даже посмотреть не могу ничего. в ДО очень скудная инфа (там как сервис выкуплено)

🔸🔷🔴CloudSecDocs - very cool website about AWS, GCP, Azure and Container Security

For this moment:
- Access Management
- Infrastructure Security
- Logging & Monitoring
- Compute
- Storage
- Dev
- Offensive / Pentest
- Devops

cloudsecdocs.com

#aws #azure #gcp

внезапно спасибо 🙂

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

Приветы. Вопрос есть для знатоков AWS.

Есть задача, хочу спросить как лучше организовать её решение.

1. Юзер заливает видео файлы (от несокльких мин до нескольких часов). Заливает сразу в S3.
2. Мне надо как можно быстрей но не критично быстро обработать все файлы и результат сложить туда же в S3.
3. Есть Docker образ в котором может быть выполнена задача, нужно исползовать его. В образе сидит celery-worker который подключается к брокеру очереди и получает задания. Инстанс работает пока не закончатся задания по файлам. То есть это не запуск инстанса под одну команду а воркер на всё время выполнения задач.
4. Всё происходит автоматически без ручного вмешательства.

Любой бекэнд по управлению через API я могу написать, нужен совет именно о том как организовать это на стороне AWS.

Я не так давно начал разбираться в имеющихся сервисах. На данный момент я нашел несколько вариантов.
Самый удобный это через CloudFormation создать кластер и масштабировать его от 1 до N в зависимости от нагрузки. Либо под каждую задачу запускать свой кластер (если нет каких-либо ограничений по их количеству). Но тут узнал что CloudFormation уже не актуален.
Lambda и Batch не подходит так как нужен именно воркер а не выполнение одного задания.

Как бы вы организовали данный процесс?
Спасибо.

Если хочется и есть возможность все переписать по lambda возможна вполне:
1. S3 объект генерирует CloudWatch событие
2. Lambda функция выполняется по событию из п.1. если в процессе выполнения произошла ошибка, то событие может быть отправлено в SQS dead letter queue.

Все вполне хорошо описывается в CloudFormation - он далеко не мертв. Более свежая технология - CDK, но он тоже в конечном счёте генерирует CloudFormation шаблоны.

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

Lambda может быть запущена на моём Docker контейнере? Я так понял что это вызов функции, или на python или может на чем-то еще.

Переписывать не получится, так как очередь на celery легко переносится на другие архитектурные решения, например на локальную рендер-ферму. Поэтому хочу оставить такой подход

да, фаргейт же

да, пробовал, он тоже поднимается через тот же кластер. Если его использовать то стоимость инстансов такая же?

нет, здесь pay as you go модель, аля “serverless" для докер контейнеров

а я гдето слышал что дороже выходит и имено за сервис. МОжет устарела инфа

Оба правы. Там 2 способа запуска контейнеров есть

может быть и дороже, все зависит от ситуации

На своих машинах и без выделения машин

А вообще задача типичная, не сложная, если переписывать все нет необходимости - гуглить celery on aws. Есть много статей где это все работает, в т.ч. с Docker

Но это уже не true cloud :D

Вот у меня щас два варианта решения

1. Создаю кластер с 1 инстансом который крутится всегда и всегда готов начать выполнение задач сразу. Как только прилетает задача, этот одиночный инстанс начинает её считать и кластер масштабируется до 10+ инстансов. Они подключатся и начинают помогать.

2. Кластаров в ожидании нет. Как только прилетает задача, я создаю новый кластер и жду когда он поднимется и начнет считать. Если прилетает другая задача то под неё поднимается новый кластер. По завершению задачи этот конкретный кластер удаляется из системы с удалением инстансов.