AWS - ALB & NLB 통신

안녕하세요.

오늘은 AWS의 대표적인 서비스 ALB와 NLB 차이점에 대해 알아보겠습니다.

 

# ALB의 통신 방식

ALB는 7계층 로드밸런서로 `Reverse Proxy` 방식으로 동작하여 클라이언트와 Target 간에 별도의 TCP 세션을 맺습니다.

리버스 프록시는 클라이언트를 대신해
백엔드 서버로 요청을 전달하고 응답을 받아 되돌려주는 중간 서버입니다.

 

Client와 ALB 간 1개, ALB 백엔드 서버 간 1개 하여 총 2개의 세션이 만들어집니다.

 

• Client ↔ ALB (세션)
• ALB ↔ WEB 서버 (세션)

위 그림과 같이 두 개의 세션이 생성되게 됩니다.

 

1) Client → ALB

Src : Client IP

Dst : ALB IP 

Protocol : Http

 

2) ALB → EC2 백엔드 

Src : ALB IP 

Dst : WEB 서버

Protocol : Http

 

Client → ALB 구간 TCP Dump

 

ALB → WEB 서버 구간 TCP Dump

 

위 덤프를 비교해보면 Sequence Number가 전혀 이어지지 않는 것을 확인할 수 있습니다.
즉, ALB는 클라이언트로부터 받은 요청을 그대로 전달하는 것이 아니라, 자체적으로 새로운 TCP 세션을 생성하여 백엔드 서버와 통신합니다.

이로 인해 Client ↔ ALB 와 ALB ↔ WEB 서버 간의 연결은 완전히 독립적인 세션으로 존재하게 됩니다.

 

# NLB의 통신 방식

NLB는 Layer 4 에서 동작하며, TCP/UDP 트래픽을 그대로 전달하는 패스스루(pass-through) 구조를 가집니다.
즉, 클라이언트와 백엔드(Target) 간의 연결은 단일 TCP 세션으로 유지되며, NLB는 중간에서 패킷을 가공하지 않고 그대로 전달합니다.

NLB는 수신한 패킷의 Destination IP 주소만 백엔드(Target)의 IP로 변경한 뒤,
나머지 TCP 헤더와 페이로드는 수정하지 않고 그대로 전달합니다.

 

결과적으로,

• ALB는 요청을 받고 새로운 TCP 세션과 패킷을 생성하여 총두 개의 TCP 세션을 생성
• NLB는 요청을 받아 목적지 주소만 바꾸고 그대로 전달하여 총하나의 TCP 세션을 생성

1) Client → ALB → WEB 

Src : Client IP

Dst : ALB IP → WEB 

Protocol : Http

 

Client → NLB 구간 TCP Dump

 

NLB → WEB 서버 구간 TCP Dump

 

두 구간의 패킷을 비교해 보면, Sequence Number가 완전히 동일하다는 것을 확인할 수 있습니다.
이는 NLB가 패킷을 받아 새로운 세션을 생성하지 않고, 기존 클라이언트의 TCP 세션을 그대로 백엔드로 전달하고 있음을 의미합니다.

즉, NLB는 ALB처럼 새로운 연결을 만들어내는 프록시가 아니라,
클라이언트와 서버 간의 동일한 TCP 연결을 단순히 중계(pass-through) 하는 구조입니다.

 

# 의문 사항

NLB로 통신 테스트를 진행하던 중 궁굼한 점이 생겼습니다.

백엔드 EC2에서 tcpdump로 패킷을 캡처해보면 destination IP가 Client의 Public IP로 찍히는 것을 확인할 수 있습니다.

여기서 빨간 박스로 표시된 IP(4.230.131.122)는 Client의 Public IP 입니다.

즉, EC2는 “NLB로부터 온 요청”을 보는 것이 아니라
직접 Client와 통신하는 것처럼 보여집니다.

 

Client 쪽에서 동일한 통신을 캡처해보면 다음과 같다:

여기서 빨간 박스로 표시된 3.34.211.117은 NLB의 IP입니다.

Client는 NLB와만 통신하는 것으로 보이고,
EC2의 private IP나 public IP는 어떠한 형태로도 보이지 않습니다. 

 

마치 위 그림과 같이 DSR (Direct Server Return) 통신 되는 것 처럼 보입니다. 

 

결론 부터 말씀드리면 DSR은 아닙니다.

그렇다면 어떻게 통신이 가능한 것일까요? 

정답은 AWS의 Hyperplane으로 인해 위와같은 통신이 가능한 것인데요.

Hyperplane이란?

Hyperplane은 AWS가 직접 운용하는 AZ 단위의 분산 패킷 처리 플랫폼으로
다음과 같은 역할을 수행합니다.

• Connection tracking(연결 상태 추적)
• 대규모 트래픽 분산 처리
• 패킷 헤더 재작성 및 라우팅
• NAT 및 LB 트래픽 처리

사용자(우리)는 Hyperplane을 직접 관리할 수 없으며
NLB, NAT Gateway, EFS, PrivateLink 등 여러 네트워크 서비스가 Hyperplane 위에서 동작합니다.

 

OS 내부에서는 바로 Client IP로 향하는 것으로 보이지만

OS 밖으로 나온 트래픽은 Hyperplane이 모든 세션을 추적하고 트래픽을 적절한 경로로 재전달합니다.

 

그래서 OS 내부에서는 "직접 보낸 것처럼" 보이지만
실제 네트워크 경로에서는 NLB를 통해 정상적으로 왕복 통신이 이루어집니다.

 

끝으로 아래 블로그에서 보다 자세하게 Hyperplane과 NLB 통신에 대해 다루고 있어 한번 확인해보세요.

https://zigispace.net/1197

Amazon VPC 한 번쯤 궁금한 이야기 3 : Hyperplane (하이퍼플레인)

 

---

*참고한 사이트

 

https://repost.aws/questions/QUXCcxeigwQ12Dp_N4mWbIDg/where-are-the-inter-az-data-transfer-charges-for-alb?utm_source=chatgpt.com

Where are the inter AZ data transfer charges for ALB?

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/network/introduction.html

Network Load Balancer란 무엇인가요? - Elastic Load Balancing

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html

Application Load Balancer란 무엇입니까? - Elastic Load Balancing

https://zigispace.net/1197

Amazon VPC 한 번쯤 궁금한 이야기 3 : Hyperplane (하이퍼플레인)

 

감사합니다.