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과 결합 시 이러한 문제가 발생할 수 있다.)
