Система 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, GATEWAY_TIMEOUT
  • 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
1
задан 26 April 2019 в 08:54
1 ответ

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

Теория

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

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

История ELB

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

Ссылки

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

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

2
ответ дан 3 December 2019 в 20:08

Теги

Похожие вопросы