본문 바로가기

Compute/ELB

AWS ELB Backend Connection Errors

오픈 준비중인 서비스에서 ELB에서 Backend Connection Errors 및 Surge Queue Length 발생.

Request가 없으나 Backend Connection Errors가 일정하게 발생되며, Surge Queue Length가 쌓이기 시작.

 

Surge Queue Length는 ELB의 Backend EC2에서 처리하지 못한 Request가 버퍼에 쌓이는 것, Backend Connection Errors는 Backend EC2와 세션 과정에서 문제가 발생되는 것을 의미.

 

주로 Backend 가용성 문제로 인해 발생되는 메트릭으로 준비중인 서비스에서 발생되는게 이상함..

업무는 아니지만.. 확인해봄

 

Application, EC2 OS, log 상에서도 특이점은 확인되지 않음. 또한 ELB의 설정에서도 문제는 보이지 않음.

tcp 레벨에서 확인.

 

tcp dump

 

8081 포트에서 RST 패킷 발생. 8초에 하나씩으로 분당 7~8개, ELB가 두 대니까... 14~15개.

ELB 리스너는 ELB 80 -> EC2 8081 포트포워딩 설정되어 있음.

OK... Backend Connection Errors는 Backend EC2의 TCP RESET 패킷이 원인으로 예상.

 

개발자님 8081 포트는 무슨 용도? ELB 리스너에 등록되어 있던데? -> 그거 안 쓰는데 잘못 넣었음.

OK.. 그럼 일단 ELB 리스터 포트포워딩에서 해당 포트 제거하겠음. -> ㅇㅇ...미안..

 

그 결과 Backend Connection Errors와 Surge Queue Length는 사라짐.

여기서 의문이 실제 Request가 없었으나 왜 ELB가 backend ec2 instance에 TCP syn을 보냈는가?

 

case open-답변 ELB는 기본적으로 Health Check를 제외하고, Client 요청을 포워딩 해줌. 요청 없으면 ELB에서 백단으로 요청 보내지 않음.

그래...???... 그럼 안 쓰는 포트 추가로 리스너에 넣어보고 테스트 해봄. 

 

실제 808x에 대한 요청이 없음에도 ELB에서 syn 패킷이 backend로 날라옴. 

 

하 뭐지 다시 ELB Document를 찾아봄.

 

Elastic Load Balancing 작동 방식 - Elastic Load Balancing

Elastic Load Balancing 작동 방식 로드 밸런서는 클라이언트에서 오는 트래픽을 허용하고, 하나 이상의 가용 영역에서 등록된 대상(예: EC2 인스턴스)으로 요청을 라우팅합니다. 또한, 로드 밸런서는 등록된 대상의 상태를 모니터링하고 정상 대상으로만 트래픽이 라우팅되도록 합니다. 로드 밸런서가 비정상 대상을 감지하면, 해당 대상으로 트래픽 라우팅을 중단합니다. 그런 다음 대상이 다시 정상으로 감지되면 트래픽을 해당 대상으로 다시 라우팅합니다

docs.aws.amazon.com

 

사전 개방 연결? 영어 번역 pre-open? pre-open이 뭐지.....? ALB에서는 사용되지 않는다네.

일단 ALB로 테스트... ALB의 경우 ELB<->EC2 간의 RST는 발견되지 않음.

 

그렇다면 pre-open이 미리 tcp 세션을 열어둔다는 것인가...

 

elb pre-open 구글링

 

AWS ELB pre-open Connection Exposé, Part 1

Exposé of AWS’s ELB “pre-open” Optimization, part 1 or “what are all these ..reading.. connections in Apache when I use an AWS ELB?” A colleague of mine reported a pro…

cloudavail.com

이미 2014년에 누군가가 같은 의심을 했었음. 증상도 동일. 

실제 요청보다 Apache에서 tcp 세션이 더 많이 생긴다 이상하다. 

위는 request가 없는 elb-ec2의 패킷 덤프, 아래는 일반적인 http 요청

 

elb는 임의로 tcp 세션을 맺은 후, http 요청은 보내지 않음. 미리 tcp 세션만 생성. client 요청이 있다면 그 세션을 재사용. 

 

개인적인 테스트였으므로 공식적인 확인을 위해서 다시 Case Open 진행

Classic ELB의 pre-open이 뭐임... 아래 답변이 옴. 

By pre-open connections, it means that Classic Load Balancers can establish a session with backend instance even before a client establishes a connection with LB. This behavior helps to reduce the time required to process a new requests by already having a connection open between Classic Load Balancer and backend instances.

 

이전 케이스 답변은 ELB는 백앤드 EC2와 요청없이 먼저 세션을 맺지 않는다고 했었는데, 이제와서 저렇게 답변을 받음. 

 

결과적으로 ELB(classic)에서는 리스너 포트로 미리 tcp syn을 backend로 날리고 http 요청 시 해당 소켓을 재사용함. 따라서 tcp 재사용으로 latency에 이점은 생기나, 필요 이상의 tcp 세션 사용으로 백앤드 서버에 미약?하게라도 부담이 생길수도 있을듯.

 

 

AWS ELB pre-open Connection Exposé, Part 1

Exposé of AWS’s ELB “pre-open” Optimization, part 1 or “what are all these ..reading.. connections in Apache when I use an AWS ELB?” A colleague of mine reported a pro…

cloudavail.com

에도 언급되지만 도큐먼트에 pre-open이 무엇인지 풀어서 설명된 내용은 없다. 답변 온 저 세 줄을 도큐먼트에 추가해주면 좋겠다.  2년 넘게 AWS를 사용하면서 몰랐던 내용....

 

마지막 서포트팀 답변... 

Apologies for the incorrect information provided earlier and the inconvenience that might have caused. I verified your Load Balancer again and confirmed it is indeed a Classic Load Balancer(CLB) and not ALB. With that said, my previous comment about LB not sending any request to backend instance, before receiving any request from client is not true in your case i.e. CLB as Classic Load Balancers does use pre-open connections.