AWS ELB Apache2 503 서비스를 사용할 수 없음 : 백엔드 서버 용량이 부족

우리는 지금 약 2 년 동안 Amazons AWS 인프라에서 몇 개의 웹 사이트를 운영하고 있으며 약 2 일 전에 웹 서버가 하루에 한두 번 다운되기 시작했습니다.

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

CloudWatch에서 경보 (CPU / 디스크 IO / DB 연결)를 트리거하지 않습니다. ELB를 건너 뛰기 위해 탄력적 IP를 통해 사이트를 방문하여 다음을 얻었습니다.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.

아파치 로그에서 평범하지 않은 것을 보지 못하고 제대로 회전하고 있는지 확인했습니다. SSH를 통해 "작동 중지"된 상태에서 시스템에 액세스하는 데 아무런 문제가 없으며 프로세스 목록을 보면 나에게 정상으로 보이는 151 개의 apache2 프로세스가 표시됩니다. 아파치를 다시 시작하면 일시적으로 문제가 해결됩니다. 이 시스템은 ELB 뒤의 웹 서버처럼 작동합니다. 어떤 제안이라도 대단히 감사하겠습니다.

CPU 사용률 평균 : 7.45 %, 최소 : 0.00 %, 최대 : 25.82 %

메모리 사용률 평균 : 11.04 %, 최소 : 8.76 %, 최대 : 13.84 %

스왑 사용률 평균 : 해당 사항 없음, 최소값 : 해당 사항 없음, 최대 값 : 해당 사항 없음

/ dev / xvda1에 대한 디스크 공간 사용률 / 평균 : 62.18 %, 최소 : 53.39 %, 최대 : 65.49 %

문제가 탄력적 IP에 도달 할 수 없어도이를 배제하고 싶지 않은 ELB가 아니라 개별 EC2 인스턴스에 문제가 있다고 생각합니다. ELB가 실제 EC2 인스턴스에 도달 한 결과를 반환한다고 생각합니다.

업데이트 : 2014-08-26이 업데이트를 더 빨리 업데이트해야하지만 "수정"은 "잘못된"인스턴스의 스냅 샷을 생성하고 결과 AMI를 시작하는 것이 었습니다. 그 이후로는 내려 가지 않았습니다. 여전히 문제가 발생했을 때 상태 확인 curl http://localhost/page.html을보고로드 밸런서에서 용량 문제가 발생하더라도 상태 확인 페이지 ( )를 볼 수있었습니다. 나는 그것이 건강 점검 문제라고 확신하지는 않지만 아마존을 포함한 아무도 더 나은 답변을 제공 할 수 없기 때문에 그것을 답변으로 표시하고 있습니다. 감사합니다.

업데이트 : 2015-05-06 여기로 돌아와서 내가 굳게 믿는 문제의 일부가 건강 검진 설정이라고 생각했습니다. 교체 AMI가 시작된 후 확실히 개선 되었기 때문에 AMI 관련 문제를 배제하고 싶지 않지만로드 밸런서마다 상태 점검이 다르고 가장 문제가 많은 것으로 확인했습니다. 실제로 공격적인 비정상 상태 임계 값 및 응답 시간 초과가있었습니다. 우리의 트래픽은 예기치 않게 급증하는 경향이 있으며 공격적인 상태 확인 설정과 트래픽 급증 사이에는 완벽한 폭풍이라고 생각합니다.

ELB로드 밸런서가 상태 확인을 수행하고 잘못 구성된 구성 (일반적으로 NameVirtual 호스트의 경우)으로 인해 "페이지를 찾을 수 없음"(또는 기타 간단한 오류)을 수신하면 "백엔드 서버 용량이 부족합니다"라는 메시지가 나타납니다.

"ELB-HealthChecker"사용자 에이전트를 사용하여 로그 파일 폴더를 정리하십시오. 예 :

grep ELB-HealthChecker  /var/log/httpd/*

이것은 일반적으로 쉽게 수정되는 4x 또는 5x 오류를 제공합니다. 예를 들어, Flooding, MaxClients 등은 문제에 너무 많은 신용을주고 있습니다.

참고 아마존 : 요청에서 반환 된 응답을 보여주지 않겠습니까? 상태 코드조차도 도움이 될 것입니다.

방금이 문제에 부딪 쳤습니다. 정상적인 인스턴스가 없으면 Amazon ELB가이 오류를 반환합니다. 사이트가 잘못 구성되어 ELB 상태 확인이 실패하여 ELB가 두 서버를 교체하지 못했습니다. 상태가 양호하지 않은 사이트에서 ELB는 503 서비스를 사용할 수 없음을 반환했습니다. 백엔드 서버 용량이 부족합니다.

[질문을 더 잘 이해 한 후에 편집] ELB에 대한 경험이 없어도 Apache가 Tomcat을 정면으로 연결하고 연결을 범할 때 발생할 수있는 503 오류와 같은 것으로 생각됩니다.

그 결과 Apache가 백엔드에서 처리 할 수있는 것보다 많은 연결 요청을 전달하면 더 이상 연결을 수락 할 수 없을 때까지 백엔드 입력 큐가 채워집니다. 이 경우 Apache의 해당 출력 큐가 채워지기 시작합니다. 대기열이 가득 차면 Apache가 503을 처리합니다. Apache가 백엔드이고 프런트 엔드가 대기열을 채우는 속도로 전달할 때 동일한 상황이 발생할 수 있습니다.

(가설적인) 솔루션은 백엔드의 입력 커넥터와 프런트 엔드의 출력 커넥터 크기를 조정하는 것입니다. 이는 예상되는 플러딩 수준과 관련 컴퓨터의 사용 가능한 RAM간에 균형을 유지합니다.

이 경우 maxclients 설정을 확인하고 Apache (mod_status.)에서 바쁜 작업자를 모니터링하십시오. Tomcats 커넥터 백 로그, maxthreads 등에 해당하는 ELB에 관계없이 가능하면 동일하게 수행하십시오. 간단히 말해 Apache의 입력 큐와 ELB의 출력 큐에 관한 모든 것을보십시오.

직접 적용 할 수는 없지만이 링크에는 Apache 커넥터의 크기 조정 안내서가 포함되어 있습니다. 해당 ELB 대기열 기술을 연구 한 다음 수학을 수행해야합니다. http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- full-gc /

아래 설명에서 알 수 있듯이 Apache 커넥터를 압도하기 위해 트래픽 급증이 유일한 가능성은 아닙니다. 일부 요청이 다른 요청보다 느리게 제공되면 요청 비율이 높을수록 커넥터 대기열이 채워질 수 있습니다. 제 경우에는 이것이 사실이었습니다.

또한,이 일이 일어 났을 때 나는 다시 503 : s를 제공받지 않기 위해 Apache 서비스를 다시 시작해야한다고 당황했습니다. 커넥터 플러딩을 기다리는 것만으로는 충분하지 않습니다. 나는 그 사실을 알지 못했지만 Apache에서 캐시에서 제공하는 것을 추측 할 수 있습니까?

작업자 수와 해당 pre-fork maxclients 설정을 늘리면 (이것은 올바르게 기억하면 대기열에 대한 다른 지시문이있는 Windows의 다중 스레드 Apache) 503 문제가 사라졌습니다. 실제로 수학을하지는 않았지만 대기열 리소스의 최대 소비량에 대해 큰 마진을 볼 수있을 때까지 값을 조정했습니다. 나는 그것을 내버려 두었다.

이것이 도움이 되었기를 바랍니다.

느리게 응답하는 단일 서버가 엘브에서 서버를 가져 오지 않기 때문에 엘브 상태 검사기의 값을 올릴 수 있습니다. 모든 사용자가 사이트를 다운시키는 것보다 몇 명의 사용자가 서비스를 사용할 수 없게하는 것이 좋습니다.

편집 : 우리는 상태 확인 시간 초과를 25 초까지 올림으로써 사전 예열 캐시없이 벗어날 수 있습니다 ... 1 ~ 2 분 후 ... 사이트는 지옥처럼 반응합니다

편집 : : 주문형을 많이 시작하고 모니터링 도구에 관리 속도가 얼마나 빠르면 RI 아마존을 선불로 지불하십시오.

편집 : 가능합니다. 단일 백엔드 엘브 등록 인스턴스로는 충분하지 않습니다. 몇 가지를 더 시작하고 elb에 등록하면 문제를 좁힐 수 있습니다.

몇 년 늦었지만 희망적으로 이것이 누군가를 도울 수 있기를 바랍니다.

ELB 뒤의 인스턴스에 적절한 퍼블릭 IP가 할당되지 않은 경우이 오류가 발생했습니다. ELB가 거의 즉각적으로 픽업 한 시점부터 탄력적 IP를 수동으로 생성하여 인스턴스와 연결해야했습니다.