저는 AWS의 로드 밸런서 뒤에서 2개의 ec2.small을 실행하는 사이트를 운영하는 개발 운영 웹 개발자입니다.
최근에는 초당 3~4개의 요청이 클라이언트 사이트를 다운시키는 것을 확인했습니다.
최근에 변경 사항이 푸시되지 않았음에도 불구하고 여러 번 서버를 재부팅하고 문제를 일으킬 수 있는 스크립트에 대한 오류 로그 검색을 수행한 후에는 사이트가 다운되었으며 다시 돌아오지 않았습니다.
로드 밸런서 로깅을 켠 후 단일 페이지에 대한 1000개의 요청이 하나의 IP 주소에서 오는 것을 확인했습니다.
X-forwarded-for를 사용하여 로드 밸런서의 요청을 요청을 처리하는 서버로 전달하고 .htaccess 규칙을 사용하여 IP를 차단했습니다.
클라이언트 IT와 통신하는 동안 요청 폭증의 원인이 된 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) 서버 측 애플리케이션에 동시성에 문제가 있는 것 같습니다. 병목 현상이 발생한 것이 애플리케이션 서버인지, DB와 같은 업스트림인지, 아파치 구성이 스레드를 충분히 빠르게 플러시하지 않아 애플리케이션 서버에 메모리가 부족했는지 살펴볼 가치가 있습니다. 애플리케이션 서버인 경우 약간의 튜닝을 수행할 가치가 있을 수 있습니다. ELB 외부에서 동일한 머신을 가동하고 JMeter를 사용하여 병목 현상을 파악하기 위해 약간의 로드를 가하는 것입니다.
데이터베이스인 경우 memcache/elasticache(특정 객체를 검색하는 것처럼 보이므로)를 사용하여 실제 쿼리를 캐시할 수 있습니다. 이렇게 하면 db 연결이 빠르게 응답하고 Apache가 빠르게 응답하고 애플리케이션 시스템의 메모리 풀을 채우는 대신 스레드를 종료할 수 있습니다.
실제로 취약하다고 생각되면 Varnish 업스트림을 배치하여 1~5초 TTL로 요청을 캐시하여 주요 요청 폭주를 방지할 수 있습니다. 하지만 VCL은 가혹하고 심각한 문제와 어려움(캐시 중독/누출)을 초래할 수 있으므로 주의하세요.
2) "주제" 기계 자체에 관해서. 분명히 손상되었을 수 있습니다. 반드시 조사해야 합니다. IT 담당자가 정직한지 아닌지는 여러분이 결정하도록 하겠습니다. 이는 서버 결함의 영역을 벗어납니다.
손상되지 않았다고 가정하면 잘못된 자바스크립트 코드일 수 있습니다. 폴링 새로 고침을 수행하고 어떻게든 타이밍 매개변수가 수정된 경우 초당 많은 요청을 보내기 시작할 수 있습니다. 마찬가지로 JS는 훌륭하게 행동했지만 그 사람은 25개의 탭을 열어두고 저녁에 집에 갔을 수 있습니다. 각각이 5초당 1개의 요청을 보내는 경우 이는 초당 5req입니다.