#amazon-web-services #amazon-ec2 #cloud #amazon-ecs
#amazon-веб-сервисы #amazon-ec2 #облако #amazon-ecs
Вопрос:
В AWS у меня есть кластер ECS, который содержит службу, имеющую 2 экземпляра EC2. Я отправил 3 отдельных запроса API в эту службу, каждый из которых должен занять около часа, чтобы работать на 100% мощности. Я отправлял запросы с интервалом в пару минут. Все они обратились к одному и тому же экземпляру и оставили другой открытым. Вот график загрузки процессора
Вот изображение загрузки процессора моей службы. Он не использует всю свою пропускную способность: 
чего мне не хватает? Почему запросы не отправляются во второй экземпляр EC2
Комментарии:
1. Вам необходимо предоставить дополнительную информацию. Находятся ли они за балансировщиком нагрузки?
2. @MarkB я не думаю, что у меня есть балансировщик нагрузки, я просто подумал, что он будет балансировать сам, если один из них будет CPU 100%? Я также только что понял, что API немедленно возвращает 200, а затем продолжает работать асинхронно, так что, возможно, в этом проблема?
3. В этом нет ничего такого, что могло бы «уравновесить само себя». У вас просто запущено 2 контейнера Docker, и похоже, что вы отправляете все запросы непосредственно в один, даже не используя другой каким-либо образом. Балансировщик нагрузки, возможно, и помог некоторым, но он не сохранил бы баланс на 100%. Я бы посоветовал вам рассмотреть возможность постановки запросов в очередь в SQS вместо того, чтобы отправлять их непосредственно в ваши экземпляры.
Ответ №1:
An ALB не будет идеально циклически перебираться между двумя экземплярами. Если вы отправляли 100 запросы 100 несколько раз, то в среднем каждый экземпляр будет получать 50 запросы каждый, но в большинстве случаев это будет не 50 точно для каждого бэкэнда.
Для длительно выполняющейся задачи, подобной этой, предпочтительнее использовать что-то другое, например SQS , при котором каждый контейнер будет обрабатывать только x сообщения одновременно (большую часть времени, которое вы хотели x=1 бы). Затем каждый экземпляр может провести опрос SQS для выполнения работы и не потребует дополнительной работы, пока он занят.
Вы также получите другие преимущества, такие как возможность видеть, сколько времени требуется для завершения сообщения, и возможности обработки ошибок для учета тайм-аутов или сбоев сервера во время выполнения работы.