BLOG
요약:
요점: 사전 개방형 연결은 클라이언트 요청이 있을 때 ELB와 EC2 인스턴스 사이의 tcp 핸드셰이크 시간을 제거하기 위한 최적화로 제공되는 Amazon ELB입니다. – 저는 이 동작을 Amazon ELB 엔지니어링 팀의 구성원으로 확인했습니다. 참고: 사전 개방형 최적화를 사용하지 않으려는 경우 AWS 지원을 통해 최적화를 비활성화할 수 있습니다. 자세한 내용에 관심이 있으시다면 AWS와 논의하기 전에 이 글은 Amazon 사전 개방형 최적화의 목적을 어떻게 발견했는지 설명하겠습니다.
조사:
처음부터 “사전 개방” 동작은 AWS ELB가 EC2 백엔드에 “warming” 연결된 결과인 것으로 추측했습니다. ELB의 소스 IP로 요청의 소스를 식별함으로써, tcp 연결 “사전 개방” 흐름은 다음과 같은 결과를 초래했다는 것을 알게 되었습니다.
- 설정 중인 tcp 연결: SYN(LB) -> SYN,ACK(EC2) -> SYN,ACK(LB)
- 1초 후에 두 번째 ACK를 전송하는 EC2 인스턴스
- 20초 후에 연결하는 설정된 tcp 스트림을 닫는 EC2 인스턴스(참고: 스트림이 닫힐 때까지 기다리는 시간은 Apache 구성에 의해 설정됩니다.)
아래 이미지는 캡처된 “…reading…” 연결의 스크린샷입니다.
저는 이러한 행동이 사실 “사전 개방” 최적화라는 것을 확인하고, 연결이 열린 윈도우에 요청이 있을 경우 ELB가 이러한 연결을 사용할 것이라는 저의 의심을 확인하고 싶었습니다. 이를 테스트하기 위해, 많은 요청으로 ELB를 프라이밍하기 위해 계획하고, 몇 초(예: 5초)를 기다린 후 특정 고유 URL의 추가 요청을 생성했습니다. 이 테스트 결과를 통해 ELB에 의해 사전 개방 연결이 생성된 것으로 확인되었다가 5초 후에 HTTP 요청이 이미 설정된 연결 위에 배치됩니다.테스트에서 “대기” 번호를 변경하여 연결이 열린 후 추가 데이터가 전송될 기간을 효과적으로 제어할 수 있었습니다. 예를 들어, ELB를 트래픽으로 준비시키고 향후 http 요청을 보내기 전에 5초동안 기다렸다면, http 요청을 전송하기 전에 5초 동안 대기한 tcp 연결을 볼 수 있습니다. ELB를 트래픽으로 준비시키고 향후 http 요청을 전송하기 전에 18초 동안 기다렸다면, http 요청을 전송하기 전에 18초 동안 대기한 tcp 연결을 볼 수 있습니다.
마지막 생각:
- “사전 개방” 최적화에 대한 문서가 없습니다. 이건 좋지 않습니다.
- 대부분의 경우 ELB “사전 개방” 최적화는 성능에 긍정적인 영향을 미치지만 서비스 가용성에 부정적인 영향을 미치지 않습니다.
- 고정 세션을 사용하지 않는 ELB에 대한 “사전 개방” 최적화를 끄도록 Amazon 지원을 설득할 수 있습니다.
원문 URL: https://cloudavail.com/2014/01/27/aws-elb-pre-open-connection-expose-part-2/?fbclid=IwAR0dUifpFk97Pdm_ZiKz0t5j-K_fh2t6RERFawJBVSI0MTouzdU1LY6BOB0
** 메가존클라우드 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.