AWS NLB 동작 원리: 대상 선택부터 EKS Pod 경로까지

Network Load Balancer(NLB)는 OSI 4계층에서 TCP·UDP·TLS 등의 트래픽을 대상 그룹으로 전달한다. 여기까지는 간단하지만, EKS에서 실제 패킷 경로를 그릴 때는 대상 유형이 instance인지 ip인지를 반드시 나눠 봐야 한다. NAT 횟수나 conntrack 위치를 하나의 공식처럼 말할 수 없는 이유도 여기에 있다.

NLB는 포트만 보고 대상을 고르지 않는다

리스너는 프로토콜과 포트로 연결 요청을 받고, 기본 작업에 연결된 대상 그룹으로 전달한다. 대상 그룹에는 EC2 인스턴스, IP 주소 또는 ALB를 등록할 수 있다.

AWS 문서에 따르면 TCP 트래픽의 대상은 다음 값을 바탕으로 한 흐름 해시로 선택된다.

• 프로토콜
• 출발지 IP와 포트
• 목적지 IP와 포트
• TCP 시퀀스 번호

한 TCP 연결은 연결이 유지되는 동안 같은 대상으로 전달된다. 따라서 “포트가 같으니 항상 같은 서버로 간다”거나 “요청마다 라운드 로빈으로 바뀐다”고 이해하면 안 된다.

EKS instance 대상 유형의 경로

instance 유형에서는 워커 노드의 IP와 NodePort가 대상 그룹에 등록된다.

클라이언트
  → NLB
  → 워커 노드:NodePort
  → kube-proxy가 구성한 Service 전달 규칙
  → Pod

이 경로에서는 노드가 패킷을 처리한다. Service가 다른 노드의 Pod를 고르면 추가 네트워크 이동이 생길 수도 있다. 문제를 조사할 때는 NLB 대상 상태뿐 아니라 NodePort, EndpointSlice, kube-proxy 모드와 노드의 패킷 필터 규칙까지 연결해서 봐야 한다.

EKS ip 대상 유형의 경로

ip 유형에서는 Pod IP가 대상 그룹에 직접 등록된다.

클라이언트
  → NLB
  → Pod IP

AWS EKS 모범 사례는 이 방식이 워커 노드와 Service ClusterIP의 추가 전달 단계를 우회한다고 설명한다. 따라서 ip 유형을 쓰면서 NodePort DNAT가 반드시 발생한다고 분석하면 출발부터 어긋난다.

구분	instance 대상	ip 대상
등록 대상	워커 노드 IP와 NodePort	Pod IP
노드의 Service 전달	필요	해당 추가 경로 우회
로드밸런서 상태 확인 대상	노드 경로를 거친 상태	Pod가 직접 응답하는 상태
조사 범위	NLB + 노드 + Service + Pod	NLB + Pod, CNI 경로

클라이언트 IP 보존은 구성별로 확인한다

NLB라고 해서 모든 프로토콜과 대상 유형에서 같은 주소 변환이 일어나는 것은 아니다. 클라이언트 IP 보존은 대상 유형, 프로토콜, 대상 그룹 속성과 네트워크 조건의 영향을 받는다. AWS도 이 속성의 기본값과 제약을 대상 유형별로 구분해 문서화한다.

그래서 “NLB에서 한 번, 노드에서 한 번, 최소 두 번 NAT”처럼 횟수를 고정하면 안 된다. 패킷 캡처를 해석할 때는 다음을 같이 적어 두는 편이 좋다.

• 대상 그룹의 대상 유형
• 리스너와 대상 그룹 프로토콜
• preserve_client_ip.enabled 값
• 캡처 위치가 Pod, 노드, 클라이언트 중 어디인지
• Service의 externalTrafficPolicy와 CNI 구성

conntrack은 어디에서 확인해야 할까

conntrack은 Linux 커널이 추적하는 연결 상태다. instance 유형처럼 노드가 Service 트래픽을 전달하거나 NAT 규칙을 적용하는 경로에서는 노드의 conntrack 상태가 장애 원인이 될 수 있다. 반면 AWS가 관리하는 NLB 내부 구현을 사용자가 보는 Linux conntrack 테이블과 동일하다고 단정할 수는 없다.

노드를 지나는 것이 확인된 뒤에 다음 값을 살펴본다.

sudo conntrack -S
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

nf_conntrack_max를 바로 늘리는 것은 해결책이 아니다. 엔트리 증가 원인, 타임아웃, 메모리 여유, 비정상 연결 패턴을 먼저 확인해야 한다. 커널 로그의 table full 메시지와 드롭 지표도 함께 본다.

NLB 장애를 좁히는 순서

1. DNS가 반환한 NLB 주소와 활성 Availability Zone을 확인한다.
2. 리스너 프로토콜·포트와 대상 그룹 연결을 확인한다.
3. 대상 유형과 대상 상태, 헬스 체크 포트·경로를 확인한다.
4. 보안 그룹과 네트워크 ACL이 실제 경로를 허용하는지 확인한다.
5. EKS라면 Service, EndpointSlice와 AWS Load Balancer Controller 상태를 확인한다.
6. instance 유형에서만 NodePort와 노드의 kube-proxy·conntrack 경로를 집중 조사한다.

핵심은 NLB를 하나의 검은 상자로 보면서도, 사용자에게 보이는 설정과 워크로드 경로를 섞지 않는 것이다. 대상 유형을 먼저 확인하면 불필요한 NAT·conntrack 추측을 크게 줄일 수 있다.

참고한 공식 문서

• AWS: Network Load Balancer 개요와 흐름 해시
• AWS: NLB 대상 그룹 속성과 클라이언트 IP 보존
• AWS EKS 모범 사례: instance·ip 대상 유형
• Amazon EKS: Network Load Balancing