Как управлять автоматическим масштабированием AWS Elastic Beanstalk на основе среднего времени отклика, если ожидается, что одна конечная точка займет около 60 секунд

Мы автоматически масштабируем наше Java-приложение Elastic Beanstalk на основе среднего времени ответа, превышающего 3 секунды. Когда это происходит, мы добавляем 2 экземпляра в нашу среду. Как только мы вернемся в течение 1,5 секунд среднего времени отклика, мы уменьшим его на 1 экземпляр с помощью политики перезарядки в 300 секунд.

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

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

Какие варианты доступны нам, когда мы вводим долгосрочные запросы?

Должны ли мы смотреть на программно увеличивающееся и уменьшающееся количество экземпляров на основе задержки подмножества запросов, например, в среднем 3 секунды для конечной точки-a и конечной точки-b, но в среднем 70 секунд для конечной точки-C?

Можно предположить, что если 10% пользователей используют 60-секундную конечную точку, а остальные 90% используют 1-2-секундную конечную точку, то мы можем попытаться установить среднее значение выше в качестве компромисса, однако, я боюсь, это означает, что мы не будем наращивать достаточно рано для некоторых конечных точек.

Спасибо,

Роб.