Мы автоматически масштабируем наше Java-приложение Elastic Beanstalk на основе среднего времени ответа, превышающего 3 секунды. Когда это происходит, мы добавляем 2 экземпляра в нашу среду. Как только мы вернемся к среднему времени отклика в течение 1,5 секунд, мы уменьшим его на 1 экземпляр с политикой восстановления 300 секунд.
Ожидается, что наша новая конечная точка займет около 60 секунд ответить, что как бы нарушает нашу модель автоматического масштабирования, потому что теперь средние значения будут сильно искажены.
Наша первоначальная цель состояла в том, чтобы обнаружить, когда конечные точки сталкиваются с задержкой (мы вызываем сторонние API и проксируем их результаты - поэтому любые задержки связаны с тем, что третьи стороны выходят из строя или занимают больше времени, чем планировалось). На сегодняшний день автоматическое масштабирование сработало.
Какие варианты доступны нам, когда мы вводим долгосрочные запросы?
Должны ли мы смотреть на программное увеличение и уменьшение количества экземпляров на основе задержки подмножества запросов, например в среднем 3 секунды для конечной точки-a и конечной точки-b, но в среднем 70 секунд для конечной точки-C?
Мы могли бы сделать предположение, что если 10% пользователей используют 60-секундную конечную точку, а остальные 90% используют 1-2-секундную конечную точку, то мы могли бы попытаться установить более высокое среднее значение в качестве компромисса, однако я боюсь это означает, что для некоторых конечных точек мы не будем масштабироваться достаточно рано.
Спасибо,
Роб.
Думали ли вы о создании новой группы автомасштабирования?
Ваш статистический подход / мышление в порядке, но повлияет на определенный процент запросов в исходной группе. Лучше оставить новую группу отдельно.