Друзья, а можно прям Мега важный вопрос?

Сейчас разрабатываем сервис iiot, по сути его уже можно считать хайлоад проектом, хотя он ещё в тестовом периоде, так как уже в секунду приходит до 4 реквестов, да ещё каких🙄, с кучей вычислений, анализа и обработки данных
То есть если перевести в сутки , то это почти 350 000 обращений
Я и моя команда вообще никогда не работала с хайлоадом и мы сейчас пытаемся понять насколько у нас «прямое» приложение, так как сейчас ec2 t3.2xlarge оперативка (32гб) загружена на 40-50%, а проц (8vcpu) бывают пики и до 70%, база данных на rds t3.xlarge

Это норм или мы криворукие что при такой нагрузке такое потребление ресурсов?

Просто до этого за свои 15 лет айтишки максимум проекты на 2000 уников в день приходилось делать и я привык что даже 4гб это прям с головой

а еще вопрос как вы меряете загрузку оперативки ?

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

думал использовать, а потом как глянул что там надо версии проставлять

Зачем?

Добавил агента на ec2 который пушит метрики в клаудватч

Пока справляется и бюджет ок - ок. Но. Бы вам посоветовал добавить лоад тесты в SDLC чтобы ловить изменения кода которые значительно замедляют  вашу систему, иначе один неудачный деплой и все умерло на неопределенное время. И делать учения на случай если какой то компонент ушел в оффлайн, могут быть неожиданные зависимости и каскадные отказы. И ещё добавьте тесты на масштабирование, чтобы понимать на каком объеме система умрет

а метрику какую смотрите - mem_free?

Cwagent, ставится просто, память и подобное смотрит из коробки

Спасибо за совет!
Уже готовимся переключиться на написание полноценных тестов когда закончим базовый функционал весь, а то как всегда сроки горят и клиенту надо показывать кастомерам картинку уже)
А после этого обязательно будем внедрять то о чем вы сказали!

Но а в целом это типа норм?
При такой нагрузке такие ресурсы
Просто реально никогда не сталкивался и хотеться понимать правильным ли путём идём...

Спасибо за совет!
Уже готовимся переключиться на написание полноценных тестов когда закончим базовый функционал весь, а то как всегда сроки горят и клиенту надо показывать кастомерам картинку уже)
А после этого обязательно будем внедрять то о чем вы сказали!

Но а в целом это типа норм?
При такой нагрузке такие ресурсы
Просто реально никогда не сталкивался и хотеться понимать правильным ли путём идём...

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html

An integer that specifies the version of the parameter to use. You must specify the exact version. You cannot currently specify that AWS CloudFormation use the latest version of a parameter

ну с другой стороны версия позволяет делать ролбеки если что-то пошло не так

поставьте cloudwatch alarm на CPU Credits - у вас burstable instances - если упадет до нуля - все встанет колом. до тех пор пока это количество не начнет постояннло сокращаться - это ок

Ресурсы сами по себе ничего не значат. Это вопрос бюджета, ок или не ок. Одно и тоже время разработчиков можно потратить на оптимизацию, а можно на новые фичи, и это бизнес решает. Хотя вот ещё совет, смотрите в сторону горизонтального масштабирования, не вертикального. В долгосрочной перспективе это выгоднее значительно

Горизонтальное это добавлять новые инстансы и пустить все через лоадбалансер?

Сорри за нубские вопросы порой
Я вообще типа директор компании, а не девопс))
Но за неимением оного(мы достаточно меленькие пока что и пока не тяну на постоянку взять) и моим интересом ко всем этим делам - взял эту функцию на себя)

Горизонтальное это добавлять новые инстансы и пустить все через лоадбалансер?

Сорри за нубские вопросы порой
Я вообще типа директор компании, а не девопс))
Но за неимением оного(мы достаточно меленькие пока что и пока не тяну на постоянку взять) и моим интересом ко всем этим делам - взял эту функцию на себя)