Архитектура/стек для telegram — бота, где не прав? Aws. +Метрики. Логи?

Question

[Никита]

Хочу сделать в рамках хобби-проекта кое-какого бота для telegram, хотелось бы чтобы потыкали палочками в предложенную архитектуру.

Типичный флоу :
Юзер пишет боту -> получает ответ. Ответ может быть как простым, так и стартом других "под-команд", есть "тяжёлые" операции (работа с загруженной графикой через бота).

Приоритеты:
- недорого (до ~100$ в месяц) при n юзеров (допустим 500 в месяц, каждый по 100 сообщений в месяц)
- несложное масштабирование в случае резкой возросшей нагрузки (подразумевается возможность резкого вирусного эффекта, но это не точно :) )
- время ответа пользователю не критично (до 10s)

Как я вижу архитектуру :
1) Amazon api gateway получает запрос с вебхука телеги.
2) Перекидывает его в amazon Lambda
3) Та делает минимальное логирование/метрики и прокидывает дальше в очередь Amazon SQS
4) Дальше очередь разбирается n бекендами (для начала той же Lambda), если это "быстрый" ответ - отвечает юзеру в телегу, если "сложный" - кладёт в SQS и уже это сообщение подбирается другим специальным отдельным EC2 инстансом.
бд : Amazon DynamoDB для удешевления и скорости.

В случае перерасхода средств пути для удешевления :
Пункты 1 и 2 перекидываются на EC2 или инстанс digital ocean'а, допустим, как и бекенды обрабатывающие очередь. Что хотелось бы сохранить на aws - очередь как ключевой узел с точки зрения отказоустойчивости системы, главное иметь возможность её разгрести в случае завала, всё остальное вторично (наверное кроме стабильного api gateway перед очередью).

Нерешённые вопросы :
1) Имею небольшой опыт работы с prometheus и grafana, хотелось бы и тут их использовать. Подскажите как нынче проще всего интегрировать их? Им нужна своя бд? Проще ли и дешевле ли будет это всё хостить на DO или же сносно будет и на AWS?
2) Что можно использовать для сбора логов сегодня из разряда дёшево и сердито?

Comments

[ayazer]

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

2) в случае стабильной нагрузки лямбды стоят дороже (хоть маркетологи часто иное расказывают). лямбды идеальны когда есть быстрая (! помним что время жизни лямбды всего пару минут) операция которая выполняется редко. В какой-то момент становится дешевле переехать на ес2/ецс/екс.

3) с прометеусом и графаной проблем не должно быть. становится с полпинка на ес2 инстансе, куча коннекторов чтоб туда с кода слать метрики. своя бд это прометеус уже, можно вместо него и что-то другое использовать.

4) встроеный клаудвотч = дорого и неудобно. Лучше уже смотреть на сумолоджик/датадог/етц. Это дорого но хоть удобно. Либо разворачивать какое-то опенсорсное решение (коих тоже куча).

Answer 1

[Иван Шумов]

Как я вижу архитектуру :
1) Amazon api gateway получает запрос с вебхука телеги.
2) Перекидывает его в amazon Lambda
3) Та делает минимальное логирование/метрики и прокидывает дальше в очередь Amazon SQS
4) Дальше очередь разбирается n бекендами (для начала той же Lambda), если это "быстрый" овтет - отвечает юзеру в телегу, если "сложный" - кладёт в SQS и уже это сообщение подбирается другим специальным отдельным EC2 инстансом.
бд : Amazon DynamoDB для удешевления и скорости.

Да, абсолютно нормальней подход

В случае перерасхода средств пути для удешевления :
Пункты 1 и 2 перекидываются на EC2 или инстанс digital ocean'а,

Или AWS ECS + Fargate с scale to 0. В нагрузку получим бонусом работу с контейнерами. И еще придется же все-равно делать троттлинг по скорости отправки. Сколько там сегодня - все те же 30 сообщений в секунду?

1) Имею небольшой опыт работы с prometheus и grafana, хотелось бы и тут их использовать. Подскажите как нынче проще всего интегрировать их? Им нужна своя бд? Проще ли и дешевле ли будет это всё хостить на DO или же сносно будет и на AWS?

дорого, долго настраивать и почти бесполезно в AWS

Что можно использовать для сбора логов сегодня из разряда дёшево и сердито?

В идеологии AWS - ничего кроме CloudWatch. Вне AWS используйте что знаете - все-равно самостоятельно разворачивать.

Comments

[Никита]

Иван Шумов , спасибо за ответ.

Или AWS ECS + Fargate с scale to 0.

Спасибо, почитаю, слышал лишь вскользь о ecs и fargate

Сколько там сегодня - все те же 30 сообщений в секунду?

да, верно. спс за хайлайт

дорого, долго настраивать и почти бесполезно в AWS

слышал, что настраивается вроде как наоборот довольно быстро, а по поводу стоимости тут конечно вопрос, не очень хочется отдельный EC2 держать с практической точки зрения, но чисто для опыта хочется попробовать.
А почему бесполезно? Не очень хочется влезать в cloudWatch, хочется всё же бОльшего контроля и гибкости тут в плане дашбордов/алертов и тд (понимаю, что это будет отражаться на стоимости).

[Иван Шумов]

Никита,

слышал, что настраивается вроде как наоборот довольно быстро

на заборе тоже много что написано

,а по поводу стоимости тут конечно вопрос, не очень хочется отдельный EC2 держать с практической точки зрения

разумно

чисто для опыта хочется попробовать.

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

А почему бесполезно?

Скажу так что serverless мерять не cloud-native инструментариями удорожает раза в 2-3 эту инфраструктуру по тому что надо будет отсылать метрики в сторонний сервис. Не говоря уже о том что упадет производительность

Не очень хочется влезать в cloudWatch, хочется всё же бОльшего контроля и гибкости тут в плане дашбордов/алертов и тд (понимаю, что это будет отражаться на стоимости).

Cloudwatch это мощнейший инструмент и его надо просто научиться правильно готовить. Такое я слышу только от 2х категорий людей: кто только начинает и ничего еще не узнал на самом деле и матерых специалистов, работающих не в облачных окружениях. Ну и стоит заметить что метрики, хоть и важны - не панацея. Следить за всем - невозможно и надо внедрять эти инструменты по мере необходимости. Cloudwatch из коробки даст без каких либо настроек базовую видимость того что происходит, а там уже можно будет потюнить немного

[Никита]

Иван Шумов, вашу позицию понял, спасибо. Придётся еще покурить и расставить приоритеты

Answer 2

[mayton2019]

Непонятно зачем автору здесь grafana и prometheus. Выглядит ненужным обвесом. Кроме того требует полноценного и дорогого EC2 на фоне всего остального которое почти serverless.

Comments

[Иван Шумов]

Классическое «ну я же умею и люблю».

[Никита]

Не исключаю, что "на коленке" и клаудВотч подойдёт, тут скорее хочется опыта немного набрать в этой части.

Answer 3

[Евгений Хлебников]

Плюсану к Иван Шумов, с небольшими добавками.
Если пет проект - телеграм бот с описанной вами архитектурой, то не стоит городить еще один пет-проект "прометеус мониторинг" рядом. Клаудвотч для вас предоставит достаточный уровень логирования\мониторинга для бота, причем в дальнейшем его можно расширять так же сервисами AWS
Крутить prometheus рядом, конечно, можно, но, как и упоминал Иван, это приведет к удорожанию проекта: вам необходимо будет забирать метрики исполнения функций из CloudWatch (что довольно таки дорого) и\или слать метрики\логи из лямбд напрямую в ваш прометей, что увеличит стоимость выполнения лямбды
Я бы возложил хранение метрик и логов на cloudwatch, и решал проблемы мониторинга-логирования когда они возникнут (если вы действительно что-то не сможете клаудвотчем сделать)

Comments

[Никита]

Звучит здраво, спасибо