Система AWS не справляется с запросом HEAD, но не выполняет запросы GET при стресс-тесте

Я провожу стресс-тест с Locust на:

c4.xlarge (у атакующего c4.4xlarge)
1 экземпляр
amazonlinux 2017.03

Балансировщик нагрузки:

классический тип
выход в Интернет
липкость отключена для 80 и 443
80 перенаправляется на 80
443 перенаправляется на 80
тайм-аут простоя составляет 60 с
межзонная балансировка нагрузки включена
доступ к журналам отключен
слив соединения включен с таймаутом 300 секунд
проверка работоспособности настроена как:
- Цель проверки связи: HTTP: 80 / status.html
- Тайм-аут: 5 секунд
- Интервал: 30 секунд

Я делаю просто HEAD и GET запросы к /status.html конечная точка с одинаковыми номерами распределения 25000 пользователей с 1000 порожденными в секунду. По головным запросам я получаю много таких ошибок:

ОШИБКА 504 ВРЕМЯ ОТВЕТА СЕРВЕРА ИСТЕКЛО
408, REQUEST_TIMEOUT
503, служба недоступна: внутренний сервер загружен

Частота ошибок составляет около 10%. Но как ни странно для GET запрос я почти не получаю ошибок. Это даже не 1%.

Почему так могло случиться?

Если вам нужна дополнительная информация о настройке, я могу ее предоставить. К сожалению, я новичок в AWS, поэтому не знаю, что предоставить. Сожалею!

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

здесь 504:

2019-04-26T02:41:20.330496Z XXX xxx.xxx.xxx.xxx:63054 xxx.xxx.xxx.xxx:80 0.000101 31.01214 0.00002 200 200 166 160 "POST https://my.endpoint.com/some_script HTTP/1.1" "Java/1.6.0_26" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:40.594005Z XXX xxx.xxx.xxx.xxx:50071 xxx.xxx.xxx.xxx:80 0.00006 10.751718 0.000021 200 200 0 159 "GET https://my.endpoint.com/some_script HTTP/1.1" "GuzzleHttp/6.3.3 curl/7.40.0 PHP/5.5.25" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:20.446229Z XXX xxx.xxx.xxx.xxx:63063 xxx.xxx.xxx.xxx:80 0.000065 30.900277 0.00002 200 200 0 161 "GET https://my.endpoint.com/some_script HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:20.517259Z XXX xxx.xxx.xxx.xxx:56506 xxx.xxx.xxx.xxx:80 0.000053 30.829553 0.000018 200 200 0 161 "GET https://my.endpoint.com/some_script HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:42.652118Z XXX xxx.xxx.xxx.xxx:50120 xxx.xxx.xxx.xxx:80 0.000069 8.69724 0.000024 401 401 60 48 "POST https://my.endpoint.com/some_script HTTP/1.1" "go-resty/1.10.2 (https://github.com/go-resty/resty)" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:51.360268Z XXX xxx.xxx.xxx.xxx:45201 - -1 -1 -1 504 0 146 0 "POST https://my.endpoint.com/some_script HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:51.361199Z XXX xxx.xxx.xxx.xxx:50120 - -1 -1 -1 504 0 146 0 "POST https://my.endpoint.com/some_script HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2

и позже 503:

2019-04-26T02:41:44.490135Z XXX xxx.xxx.xxx.xxx:50044 xxx.xxx.xxx.xxx:80 0.000062 28.220316 0.000019 200 200 0 320 "GET https://my.endpoint.com/some_script HTTP/1.1" "restify/4.3.1 (x64-linux; v8/5.1.281.111; OpenSSL/1.0.2n) node/6.12.3" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:32.082311Z XXX xxx.xxx.xxx.xxx:32882 xxx.xxx.xxx.xxx:80 0.000031 40.62881 0.000022 200 200 117 160 "POST https://my.endpoint.com/some_script HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:43.859743Z XXX xxx.xxx.xxx.xxx:32781 xxx.xxx.xxx.xxx:80 0.000077 28.851417 0.000015 200 200 184 78 "POST https://my.endpoint.com/some_script HTTP/1.1" "GuzzleHttp/6.2.1 curl/7.53.1 PHP/5.6.38" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:51.532781Z XXX xxx.xxx.xxx.xxx:51094 xxx.xxx.xxx.xxx:80 0.000027 21.178497 0.000014 200 200 0 159 "GET https://my.endpoint.com/some_script HTTP/1.1" "GuzzleHttp/6.3.3 curl/7.40.0 PHP/5.5.25" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:51.568865Z XXX xxx.xxx.xxx.xxx:45267 xxx.xxx.xxx.xxx:80 0.000026 21.142531 0.00002 200 200 0 159 "GET https://my.endpoint.com/some_script HTTP/1.1" "GuzzleHttp/6.3.3 curl/7.40.0 PHP/5.5.25" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:46.195626Z XXX xxx.xxx.xxx.xxx:55182 xxx.xxx.xxx.xxx:80 0.000084 26.516262 0.000017 200 200 269 160 "POST https://my.endpoint.com/some_script HTTP/1.1" "Apache-HttpClient/4.0.3 (java 1.5)" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:41:42.982043Z XXX xxx.xxx.xxx.xxx:56428 xxx.xxx.xxx.xxx:80 0.000114 29.747779 0.000019 200 200 107 305 "POST https://my.endpoint.com/some_script HTTP/1.1" "Apache-HttpClient/4.0.3 (java 1.5)" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:42:13.543180Z XXX xxx.xxx.xxx.xxx:47351 - -1 -1 -1 503 0 0 0 "POST https://my.endpoint.com/some_script HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
2019-04-26T02:42:13.587978Z XXX xxx.xxx.xxx.xxx:47351 - -1 -1 -1 503 0 0 0 "POST https://my.endpoint.com/some_script HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2

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

Теория

Я подозреваю, что вы отправляете большой объем запросов на балансировщик нагрузки, не нагревая его. У вас есть два варианта:

Предварительно прогрейте балансировщик нагрузки чтобы он мог масштабироваться, связавшись с AWS и сообщив им ожидаемую нагрузку
Увеличивайте нагрузку постепенно, чтобы у балансировщика нагрузки была возможность масштабироваться. Это может занять больше времени, чем вы ожидаете, поэтому я предлагаю сначала увеличить количество запросов как минимум за несколько часов.

Фон ELB

Первоначально балансировщиком нагрузки может быть один небольшой виртуальный сервер в каждой зоне доступности, распределяющий нагрузку. По мере увеличения вашей нагрузки AWS за кулисами добавляет дополнительные или более крупные серверы для вашей нагрузки, поэтому DNS может регулярно меняться. Если вы создадите огромную нагрузку на эти небольшие серверы, они выйдут из строя, вероятно, приоритет будет отдан трафику, а запрос GET обычно более важен, чем запрос HEAD.

Ссылки

Eсть соответствующая ветка на форумах AWS, что, кажется, подтверждает мою теорию.

Вам также следует посмотреть на Страница нагрузки сети AWS чтобы убедиться, что вы не создаете DDOS.