Я веб-разработчик Dev-Ops, у меня есть сайт, на котором запущены два ec2.smalls за балансировщиком нагрузки на AWS.
Недавно мы наблюдали, как 3-4 запроса в секунду приводили к сбою сайта наших клиентов.
Сайт был недоступен и не восстановился после многочисленных перезагрузок сервера и сканирования журнала ошибок на предмет наличия скриптов, которые могли вызывать проблему, хотя в последнее время никаких изменений не вносилось.
После включения ведения журнала балансировщика нагрузки я увидел, что тысячи запросов к одной странице приходят с одного IP-адреса.
Мы переслали запрос с балансировщика нагрузки на сервер, обрабатывающий запрос, с помощью X-forwarded-for и заблокировали IP-адрес с помощью правила .htaccess.
Во время общения с ИТ-отделом клиента им сообщили, что IP-адрес, ответственный за поток запросов, на самом деле принадлежит одному из внутренних компьютеров их компании.
Ответственная машина была удаленно перезагружена, и все запросы прекратились. Сайт снова заработал.
Официальным объяснением этого было: «компьютер сошел с ума».
Может ли веб-браузер или компьютер с ОС Windows выполнить 3-4 запроса в секунду к веб-странице с балансировкой нагрузки и вывести ее из строя на 5+ часов?
Вот как выглядели запросы:
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2
решение1
Конечно, это возможно, хотя это зависит от ряда факторов:
1) Похоже, что у приложения на стороне сервера проблемы с параллелизмом. Возможно, стоит проверить, были ли узким местом серверы приложений или же это было вышестоящее звено, например, БД, и серверам приложений не хватило памяти из-за того, что конфигурация Apache недостаточно быстро сбрасывала потоки. Если это были серверы приложений, возможно, стоит провести некоторую настройку — развернуть идентичную машину за пределами ELB и использовать JMeter, чтобы нагрузить ее и выявить узкие места.
Если бы это была база данных, вы могли бы использовать memcache/elasticache (так как это выглядит так, как будто вы извлекаете определенный объект) для кэширования реальных запросов. Таким образом, соединения с базой данных реагируют быстро, Apache может быстро реагировать и убивать потоки, а не заполнять пул памяти машины приложения.
Если вы действительно чувствуете себя уязвимым, вы можете разместить Varnish в верхнем потоке для кэширования запросов с TTL 1-5 с, чтобы предотвратить большой поток запросов. Но будьте осторожны, так как VCL не прощает ошибок и может привести к серьезным проблемам и боли (отравление/утечка кэша).
2) Что касается самой "субъектной" машины. Очевидно, что она могла быть скомпрометирована - это определенно должно быть исследовано. Я позволю вам решить, честен ли IT-шник или нет - это выходит за рамки serverfault.
Если предположить, что он не был скомпрометирован, это мог быть какой-то плохой код javascript - если вы делаете обновления опроса и каким-то образом был изменен параметр синхронизации, он вполне мог начать отправлять много запросов в секунду. Аналогично, JS мог вести себя хорошо, но человек мог открыть 25 вкладок и уйти домой на вечер - если каждая отправляет 1 запрос в 5 секунд, это 5req/сек.