Load Balancer ALB, NLB 차이점 알아보기

 

AWS 4종류의 로드 밸런서가 있다. 

ELB는 AWS의 모든 로드 밸런스 종류 전체를 통틀어 칭하는 말이다. 

 

ELB의 역할은 들어오는 트래픽을 여러 가용 영역(AZ)의 애플리케이션에 자동으로 분산하는 것이다. 

 

CLB : Classic Load Balancer (오래된 서비스)

ALB : Application Load Balancer

NLB : Network Load Balancer

GWLB : Gateway Load Balancer

 

	ALB	NLB	CLB
Layer(레이어)	Layer7	Layer 4	Layer 7, Layer 4
Protocol(프로토콜)	HTTP, HTTPS	TCP, UDP, TLS	HTTP, HTTPS, TCP, SSL/TLS
Static IP(고정 IP 주소 부여)	❌	✅	❌
WebSocket 지원	✅	✅	❌
Host/Path-Based의 라우팅, URL의 쿼리 문자열의 라우팅	✅	❌	❌
지연시간	약간 높은 지연 시간	낮은 지연 시간	지연 시간이 중간 정도
주로 사용되는 사례	웹 애플리케이션	고속 트래픽이 요구되는 애플리케이션	오래된 legacy 애플리케이션

 

ELB 특징

• 애플리케이션의 고가용성(High Abailability)과 확장성(Auto Scaling)을 향상시킨다.
  • 고가용성 : ELB는 여러 Availability Zones(AZ)에 걸쳐 배포되어 트래픽을 분산한다.
  • 자동 확장: ELB는 트래픽을 자동으로 확장하고 축소할 수 있다.
• ELB는 EC2뿐만 아니라 ECS, Lambda 등 다양한 서비스와 연계하여 트래픽 부하를 분배할 수 있다. 

 

Health Checks 기능 

애플리케이션 서버 상태를 설정된 시간 간격(예: 2분 마다) 확인하고, 문제가 있을 경우 해당 서버로 전송하지 않는다. 이는 서버에 장애 발생 시 자동으로 트래픽을 다른 정상적인 서버로 전환하는 역할을 한다.

 

Slow Start Configuration 기능 

Slow Start Configuration(느린 시작 구성)은 새로 시작된 인스턴스를 위해 천천히 점진적으로 트래픽을 부하하는 기능이다. 새로운 인스턴스가 처음부터 갑작스러운 트래픽을 받아 overwhelemed되지 않도록 점진적으로 트래픽을 부하한다.

 

Connection Draining 기능

인스턴스가 CLB에서 등록해제되거나, Unhealthy 됐을 때 지정된 시간만큼 연결을 기다려준다.

- 인스턴스에 어떠한 오류가 발생했을 때, 다른 인스턴스에 트래픽을 전환하기 전에 기존 연결을 기다려주는 시간이다.

- 기본(Default)으로 켜져 있다.

- Connection Draining을 200초로 설정하면, 서버에 오류 생긴 후 200초 동안 그나마 기존 연결을 기다려주고, 다른 서버에 트래픽을 이동한다. 

 

 

 

ALB란?

ALB란 애플리케이션 로드밸런서의 약자로, 웹 서비스에 걸리는 부하를 분산해주는 로드 밸런서이다. 최근 몇 년간 다양한 소셜 네트워킹 서비스의 확장 및 여러 요인으로 인해 웹 애플리케이션 접속이 기하 급수적으로 늘어났다. 특히 갑작스러운 트래픽 증가(sudden spike in access)는 웹 서비스의 속도 저하와 에러 발생의 원인이 된다. 

 

ALB 같은 로드 밸런서는 이러한 웹 서비스의 부하를 줄여 안정성과 고가용성을 높인다. 

- 고가용성 지원

- 사용자 인증과 같은 보안 향상

- 다양한 레벨의 부하에 대한 유연한 응답

- 애플리케이션 밀착 모니터링 및 검수 

 

Operation in Layer 7 (애플리케이션 레이어에서의 작동)

과거의 ELB는 4계층 (전송 계층) 및 7계층 (애플리케이션 계층)에서의 로드 밸런서 역할을 해왔다. 4계층에서는 네트워크 패킷의 검사 없이 부하를 분산했고, 7계층에서는 패킷의 HTTP 및 HTTPS 정보에 접근하여 더욱 효율적인 부하분산을 수행해왔다.

 

ALB는 7계층에서만 작동하는 로드밸런서이다. 또한 ELB와는 달리 애플리케이션 계층에서만의 특별한 작동 스타일을 갖췄다.

 

WebSocket 및 HTTP/2 지원 => HTTP/HTTPS 지원

ALB는 WebScoket과 HTTP/2 프로토콜을 지원한다. 표준 프로토콜 지원을 통해 네트워크 트래픽을 줄이고, 접속의 효율을 높이게 된다. 

 

최신 애플리케이션 아키텍처 맞춤형 사용

마이크로 서비스, 컨테이너와 같은 가장 최신 버전의 애플리케이션 아키텍처에 맞도록 ALB를 사용할 수 있다. 보다 나은 요청 라우팅을 지원하기 때문에 자유롭고 유연한 로드밸런서로서의 사용이 가능하다.

=> Docker 컨테이너화된 애플리케이션과의 통합을 용이하게한다.

고정IP 주소 (Elastic IP) 사용할 수 없다. 

고정 IP주소를 사용할 수 있는 NLB 앞에 놓아 고정 IP주소가 있는 것처럼 사용할 수는 있음. 

 

 

타겟 그룹에 라우팅 가능

ALB는 인스턴스별로 묶어 각기 다른 서버 그룹, 즉 타겟 그룹에 적용할 수 있고, 라우팅을 설정할 수 있다. 

직접 인스턴스화 되는 ELB와는 달리 서비스를 독립적으로 실행할 수 있고, 여러 라우팅 규칙을 정의할 수 있다. 

 

ELB를 ALB로 변경할 때의 이점

- 여러 개의 로드 밸런서를 통합하여 비용을 절감할 수 있다.

- WebSocket / HTTP 2 등으로 성능을 향상시켜 효율을 증대할 수 있다.

- AWS WAF 사용을 통해 보안을 강화할 수 있다.

- 액세스 로그와 같은 정보를 압축형태로 저장하여 람다 함수로 등록할 수 있다.

 

Host(호스트) and Path(경로) Based Rounting 기능 

[호스트(Host) 기반]

클라이언트가 요청한 접속 URL의 FQDN(완전 도메인 이름)에 따라 라우팅 할 수 있는 기능

예를 들어, 클라이언트의 접속 URL 이 "http://www1.example.com"일 경우 웹 서버 1에 접속하게 하고, "http://www2.example.com"일 경우 웹 서버 2에 접속하게 할 수 있다. 

 

[경로(Path) 기반]

경로 기반 라우팅이란, 클라이언트가 요청한 접속 URL의 경로에 따라 라우팅할 수 있는 기능

예를 들어, 클라이언트의 접속 URL 이 "http://www.example.com/web1/"일 경우 웹 서버1에 접속하게 하고, "http://www.example.com/web2/"일 경우  웹 서버 2에 접속하게 할 수 있다. 

 

[URL Query 문자열 기반]

클라이언트가 요청한 접속 URL의 쿼리 문자열에 따라 라우팅할 수 있는 기능. URL 쿼리 문자열은 브라우저가 웹 서버에 전송하는 데이터를 URL에 표현한 것이다.

예를 들어, URL이 "http://www.example.com/web?lang=kr"일 경우 "lang=kr"가 URL 쿼리 문자열에 해당한다.

클라이언트의 접속 URL이 "http://www.example.com/web?lang=kr"일 경우 한국어 사이트로 접속하고, "http://www.example.com/web?lang=en"일 경우 영어 사이트로 접속하게 할 수 있다.

 

[Sticky Session] 기능: 세션 정보가 저장된 쪽으로 지속적 연결

Cookie의 유효시간 동안에 클라이언트가 동일한 백엔드 인스턴스(서버)에 접근할 수 있도록 하는 기능.

이를 통해 클라이언트는 같은 인스턴스에 연결된 상태를 유지하게 되며, 세션 상태를 인스턴스별로 저장해야 하는 애플리케이션에 유용하다.

 

[Listener Rules, 리스너 규칙]

(ALB에서만 사용 가능) Listener Rules는 수신한 요청을 어떻게 처리할지에 대한 규칙을 설정한 기능이다.
위에서 설명한 호스트/경로 기반 라우팅은 Listener Rules을 통해서 라우팅 한다.

• 요청의 경로(Path) 또는 호스트 이름(Host)을 기준으로 규칙/조건을 설정하여, 특정 URL로 들어오는 요청을 다른 타깃 그룹으로 라우팅 할 수 있다.
• 헤더 또는 쿼리 문자열의 내용에 따라 요청을 다르게 처리할 수도 있다.
• HTTP로 들어오는 요청을 HTTPS로 리다이렉트 할 수 있다.

 

 Network Load Balancer (NLB)

• TCP, UDP, TLS를 지원한다. 
• Layer 4에서 동작 (Transport Layer)
• 고성능, 상당히 낮은 Latency(지연)으로 대량 트래픽을 처리할 수 있다.
• Lambda는 NLB와 사용 할 수 없다. ALB는 사용가능 (HTTPS 기반의 트래픽을 처리하기 때문에)
• Sticky Session 사용 불가

 

그럼 어느 경우에는 ALB, NLB를 사용해야하는가? 

HTTP/HTTPS 지원	✅	❌
TCP/UDP 지원	❌	✅
WebSocket 지원	✅	제한적
고정 IP 사용 가능	❌	✅
세부 URL/헤더 기반 라우팅	✅	❌
속도 (TPS, 성능)	보통	매우 빠름
HTTPS 종료 가능	✅	가능하지만 복잡
대규모 실시간 트래픽	❌	✅

 

내가 만약 NLB를 사용해야 한다고 판단하면 TCP기반 프로토콜의 금융 서비스, 실시간 게임 서버, 채팅 서버등에 바로바로 뭔가 빠르게 해야되는 처리가 있으면 사용할 것 같다. 그게 아니라면 대부분의 경우 ALB를 사용할 듯 싶다.