Elastic Load Balancing이 로드 밸런서 트래픽을 균등하지 않게 라우팅하는 이유는 무엇입니까?

간략한 설명

다음과 같은 경우 ELB가 대상으로 라우팅하는 트래픽이 균등하지 않을 수 있습니다.

• 클라이언트가 TTL이 만료된 DNS 레코드를 사용하여 로드 밸런서 노드의 잘못된 IP 주소로 요청을 라우팅하고 있습니다.
• 로드 밸런서에 대해 고정 세션(세션 선호도)이 활성화되어 있습니다. 고정 세션은 쿠키를 사용하여 클라이언트가 쿠키의 수명 동안 동일한 인스턴스에 대한 연결을 유지할 수 있도록 합니다. 이로 인해 시간이 지나면서 불균형이 발생할 수 있습니다.
• 사용 가능한 정상 인스턴스가 가용 영역에 고르게 분산되지 않았습니다.
• 특정 용량 유형의 인스턴스가 가용 영역에 균등하게 분산되지 않았습니다.
• 클라이언트와 인스턴스 간에 수명이 긴 TCP 연결이 있습니다.
• 연결은 WebSocket을 사용합니다.

해결 방법

트래픽 불균형 확인

ELB 액세스 로그(사용 가능한 경우)를 분석하여 트래픽 불균형을 확인합니다. 명령줄 도구를 사용하여 로드 밸런서가 특정 애플리케이션으로 라우팅하는 요청 수를 찾습니다.

Application Load Balancer의 경우:

awk '{print $5}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r

Classic Load Balancer의 경우:

awk '{print $4}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r

ELB는 각 ELB 노드의 개별 파일을 버킷에 추가합니다. 특정 기간에 대한 액세스 로그 파일의 행 수를 비교할 수 있습니다.

DNS 캐시 플러시

오래된 DNS 항목을 기반으로 라우팅하면 서로 다른 가용 영역에 걸쳐 RequestCount 패턴이 불균형해집니다. 자세한 내용은 Application Load Balancer 지표 또는 Classic Load Balancer 지표를 참조하십시오. 클라이언트의 DNS 캐시를 플러시하여 로드 밸런서 노드에 대한 현재 DNS 레코드가 사용될 수 있도록 합니다.

참고: 교차 영역 로드 밸런싱이 활성화된 경우에도 로드 밸런서는 인스턴스 수준에서 요청을 균등하게 밸런싱할 수 있습니다.

DNS 캐싱에 nscd를 사용하는 Linux 클라이언트의 경우 다음 명령 중 하나를 실행합니다.

sudo /etc/init.d/nscd restart

# service nscd restart

# service nscd reload

DNS 캐싱에 dnsmasq를 사용하는 Linux 클라이언트의 경우 다음 명령 중 하나를 실행합니다.

$ sudo /etc/init.d/dnsmasq restart

# service dnsmasq restart

DNS 캐싱에 BIND를 사용하는 Linux 클라이언트의 경우 다음 명령 중 하나를 실행합니다.

# /etc/init.d/named restart

# rndc restart

# rndc exec

Windows 클라이언트의 경우 다음 명령을 실행합니다.

ipconfig /flushdns

참고: 클라이언트의 DNS 캐시를 지운 후에도 여전히 캐싱 문제가 발생하는 경우 클라이언트 애플리케이션이 DNS 레코드를 캐싱하지 않는지 확인하십시오.

고정 세션의 구성 확인

기간 기반 세션 고정성을 사용하는 경우 특정 사용 사례에 적절한 쿠키 만료 시간을 구성합니다. 자세한 내용은 다음을 참조하세요.

• 고정 세션(Application Load Balancer)
• 기간 기반 세션 고정성(Classic Load Balancer)

개별 애플리케이션에서 세션 고정성을 설정하는 경우 가능하면 영구 쿠키 대신 세션 쿠키를 사용하십시오. 자세한 내용은 애플리케이션 제어 세션 고정성(Classic Load Balancer)을 참조하십시오.

가용 영역 전체의 정상 인스턴스 배포 확인

가용 영역에서 사용 가능한 정상 인스턴스의 수가 동일하지 않고 교차 영역 로드 밸런싱이 비활성화된 경우 ELB는 영향을 받는 가용 영역에서 더 적은 수의 인스턴스에 걸쳐 요청을 밸런싱해야 합니다. 그 보상으로 나머지 정상 인스턴스에서 더 많은 수의 요청을 처리해야 하므로 성능에 부정적인 영향이 발생할 수 있습니다.

참고: 인스턴스 또는 가용 영역의 트래픽 로드 불균형이 반드시 리소스 사용률도 불균형하다는 의미는 아닙니다. 예를 들어 불균형은 로드 밸런서 뒤에 있는 하나 이상의 인스턴스가 다른 인스턴스보다 빠르게 요청을 처리할 때 발생할 수 있습니다.

활성화된 각 가용 영역에서 동일한 수의 인스턴스를 유지합니다. 더 많은 인스턴스를 로드 밸런서 대상으로 추가하려면 다음을 참조하십시오.

• 대상 그룹에 대상 등록(Application Load Balancer)
• 대상 등록 또는 등록 취소(Network Load Balancer)
• Classic Load Balancer에 EC2 인스턴스 등록 또는 등록 취소

Classic Load Balancer 및 Network Load Balancer의 경우 교차 영역 로드 밸런싱을 활성화하여 가용 영역 수준 대신 인스턴스 수준에서 요청을 분산하는 것이 좋습니다. 자세한 내용은 교차 영역 로드 밸런싱(Network Load Balancer) 또는 Classic Load Balancer에 대한 교차 영역 로드 밸런싱 구성을 참조하십시오. 교차 영역 로드 밸런싱은 Application Load Balancer에 대해 항상 활성화됩니다.

인스턴스 유형 배포 확인

HTTP 또는 HTTPS 수신기가 있는 Classic Load Balancer는 더 많은 트래픽을 더 큰 용량의 인스턴스 유형으로 라우팅할 수 있습니다. 이 배포는 저용량 인스턴스 유형에 처리되지 않은 상태의 요청이 너무 많아지는 상황을 방지하는 것을 목표로 합니다. 자세한 내용은 인스턴스 유형을 참조하십시오. 유사한 인스턴스 유형 및 구성을 사용하여 용량 격차와 트래픽 불균형의 가능성을 줄이는 것이 모범 사례입니다.

서로 다른 Amazon Machine Image(AMI)에서 유사한 용량의 인스턴스를 실행하는 경우에도 트래픽 불균형이 발생할 수 있습니다. 이 시나리오에서 대용량 인스턴스 유형에서 발생하는 트래픽 불균형은 바람직한 현상입니다.

수명이 긴 TCP 연결 확인

Elastic Load Balancing은 라운드 로빈 알고리즘을 사용하여 TCP 트래픽을 라우팅합니다. 클라이언트와 인스턴스 간의 수명이 긴 TCP 연결은 설계상 균등하지 않은 트래픽 로드 분산을 야기합니다. 따라서 새 인스턴스의 경우 연결 균형에 도달하는 데 시간이 더 오래 걸립니다. 지표를 확인하여 문제를 일으킬 수 있는 수명이 긴 TCP 연결이 있는지 확인하십시오. 또한 TCP 리스너를 사용하는 경우 로드 밸런서는 연결 수준에서만 트래픽을 분산합니다. 예를 들어 여러 HTTP 요청을 전송 및 수신하기 위해 연결을 자주 재사용하는 클라이언트의 경우 인스턴스 수준에서 불균형한 트래픽을 생성할 수 있습니다. 애플리케이션이 HTTP, HTTPS, WebSocket 또는 HTTP2와 같은 상위 계층 네트워크 프로토콜을 지원하는 경우 계층 7 로드 밸런서로 이동하는 것이 좋습니다.

로드 밸런서의 RequestCount 패턴 및 기타 관련 지표를 확인합니다. 자세한 내용은 다음을 참조하세요.

• Application Load Balancer 지표
• Network Load Balancer에 대한 CloudWatch 지표
• Classic Load Balancer 지표

WebSocket 연결 확인

WebSocket 연결과 함께 로드 밸런서를 사용하는 클라이언트는 클라이언트와 대상 간에 1:1 연결을 사용합니다. 이 연결은 WebSocket 연결 기간 동안 대상에 계속 고정되어 트래픽이 서로 다르게 분배됩니다. Application Load Balancer는 WebSocket에 대한 기본 지원을 제공합니다. WebSocket으로 업그레이드된 새 HTTP 요청만 새 대상으로 이동합니다. WebSocket은 계층 4 리스너가 있는 Classic Load Balancer 및 Network Load Balancer와 함께 작동합니다.

자세한 내용은 리스너 구성을 참조하십시오.

---