[참고][AWS] ALB, NLB idle timeout, keepalive 차이점, 문제상황 및 해결방법!!

 

 

ALB, NLB 차이점

---

ALB는 http header까지 모두 확인하여 트래픽을 전달하고, NLB는 4계층 까지의 정보만 확인 후 전달한다. 이때 ALB에서는 이러한 트래픽을 Proxying 하게 되는데, 때문에 서버에서 tcpdump 시 반대쪽 IP가 alb의 IP로 찍히게 된다.(EC2에서 client로 전달되는 패킷은 DSR 방식으로 처리된다.)

NLB에서는 client의 ip가 그대로 전달되며 proxying하지 않고 패킷 포워더와 같이 작동한다.

client → NLB(80 listening) → ec2(8080 listening)일 때, NLB는 트래픽의 포트만을 변경하여 패킷을 ec2로 전송한다. 이때문에 NLB 활용을 위해선 EC2 측에서 인바운드 8080포트 트래픽을 허용하여야한다.

ALB idle timeout, HTTP keepalive

---

기본적으로 ALB에서는 60초의 조정 가능한 idle timeout을 두는데, idle timeout에 정의된 시간 동안 연결에서 트래픽이 감지되지 않으면 ALB에서 연결을 종료한다. 때문에 요청 처리 시간이 긴 어플리케이션의 경우, nginx와 같은 웹서버에서 keep-alive 옵션을 활성화하여 패킷이 지속적으로 지나가도록 구성해주어야 한다.

또한 ALB에서는 idle timeout 경과 시 clienet → ALB(이하 프론트 연결)을 종료시키는데(server와 client에 FIN 패킷을 전달한다), 이때 만약 EC2에서 alb의 idle timeout보다 낮은 idle timeout 지정으로 인한 비정상적인 TCP 연결 종료 발생 시 alb에서 백엔드 연결의 종료 여부를 파악하지 못하고 프론트 요청을 전달하려 할 수 있으며 이때 ALB는 502 Bad Gateway를 전달하게되므로 EC2에서의 idle timeout을 ALB의 idle timeout보다 높게 지정해주어야한다.

NLB idle timeout, TCP keepalive

---

NLB에서는 ALB와 달리 조정할 수 없는 idle timeout 360s를 제공하며 idle timeout 만료 이후 TCP 연결을 조용히 종료시킨다. 때문에 어플리케이션이 timeout을 인지하지 못하고 같은 소켓으로 요청을 전달할 수 있으며 그러한 상황에선 NLB에서 어플리케이션에 RST 패킷을 전달한다. 이러한 사실을 활용하여 추후 RST 패킷이 비정상적으로 많이 탐지될 경우 위 상황으로 예측할 수 있다.

만약 위와 같은 상황 발생 시 linux kernel의 tcp keepalive 파라미터를 수정하여 idle timeout을 방지할 수 있으며, tcp keepalive의 경우 다음 내용을 참조하면된다.
TIMEWAIT-소켓과-keepalive

$ sudo sysctl -a | grep net.ipv4.tcp_keepalive
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 1
net.ipv4.tcp_keepalive_time = 120

(참고로 기본 tcp keepalive tme은 7200(2시간)이며, 기본 설정을 통해 nlb 360과 결합 시 이러한 문제가 발생할 수 있다.)

 

 

 

출처 : ALB, NLB idle timeout, keepalive 차이점, 문제상황 및 해결방법 (velog.io)