по сути его уже можно считать хайлоад проектом, хотя он ещё в тестовом периоде, так как уже в секунду приходит до 4 реквестов, да ещё каких🙄, с кучей вычислений, анализа и обработки данных
То есть если перевести в сутки , то это почти 350 000 обращений
Я и моя команда вообще никогда не работала с хайлоадом и мы сейчас пытаемся понять насколько у нас «прямое» приложение, так как сейчас ec2 t3.2xlarge оперативка (32гб) загружена на 40-50%, а проц (8vcpu) бывают пики и до 70%, база данных на rds t3.xlarge
Это норм или мы криворукие что при такой нагрузке такое потребление ресурсов?
Просто до этого за свои 15 лет айтишки максимум проекты на 2000 уников в день приходилось делать и я привык что даже 4гб это прям с головой
Пока справляется и бюджет ок - ок. Но. Бы вам посоветовал добавить лоад тесты в SDLC чтобы ловить изменения кода которые значительно замедляют вашу систему, иначе один неудачный деплой и все умерло на неопределенное время. И делать учения на случай если какой то компонент ушел в оффлайн, могут быть неожиданные зависимости и каскадные отказы. И ещё добавьте тесты на масштабирование, чтобы понимать на каком объеме система умрет
Спасибо за совет! Уже готовимся переключиться на написание полноценных тестов когда закончим базовый функционал весь, а то как всегда сроки горят и клиенту надо показывать кастомерам картинку уже) А после этого обязательно будем внедрять то о чем вы сказали! Но а в целом это типа норм? При такой нагрузке такие ресурсы Просто реально никогда не сталкивался и хотеться понимать правильным ли путём идём...
Ресурсы сами по себе ничего не значат. Это вопрос бюджета, ок или не ок. Одно и тоже время разработчиков можно потратить на оптимизацию, а можно на новые фичи, и это бизнес решает. Хотя вот ещё совет, смотрите в сторону горизонтального масштабирования, не вертикального. В долгосрочной перспективе это выгоднее значительно
поставьте cloudwatch alarm на CPU Credits - у вас burstable instances - если упадет до нуля - все встанет колом. до тех пор пока это количество не начнет постояннло сокращаться - это ок
А за это отдельное спасибо!
Горизонтальное это добавлять новые инстансы и пустить все через лоадбалансер? Сорри за нубские вопросы порой Я вообще типа директор компании, а не девопс)) Но за неимением оного(мы достаточно меленькие пока что и пока не тяну на постоянку взять) и моим интересом ко всем этим делам - взял эту функцию на себя)
На почасовку взять, он и нарисует что как
Да, так или иначе раскидывать нагрузки на несколько инстансов. Может быть лоад балансер, очереди, днс и ещё куча опций. Таким образом можно делать деплои без даунтайма, масштабировать на ходу и много ещё чего
Уже предварительно договорился об этом с одним из здешних Гуру!) Пока коплю деньжат на его помощь, надо все равно как-то поддерживать работоспособность и развивать сервис, поэтому и тяну сам Слава Богу что проект в долгой бете и пока вопрос с правильной aws-архитектурой не сильно критичен, но вроде как с НГ запускаемся
Обсуждают сегодня