들어가며
AWS에서 로드밸런서를 선택할 때 ALB(Application Load Balancer)와 NLB(Network Load Balancer) 중 어떤 것을 선택해야 할까요? 단순히 L7과 L4의 차이로만 이해하고 있다면, 실제 운영에서 예상치 못한 문제를 만날 수 있습니다. 이 글에서는 두 로드밸런서의 근본적인 차이와 실제 사용 사례를 깊이 있게 다루겠습니다.
핵심 차이점: 아키텍처 관점
NLB: 패킷 포워딩 머신
NLB는 OSI 4계층(Transport Layer)에서 작동하는 고성능 패킷 포워더입니다. 패킷의 내용을 해석하지 않고 헤더 정보만으로 라우팅하기 때문에 극도로 빠른 성능을 보장합니다.
# NLB 동작 원리
Client Packet → NLB → Target Server
(패킷 헤더만 수정)
지연시간: ~100 마이크로초
처리량: 초당 수백만 패킷ALB: HTTP 전문 처리기
ALB는 OSI 7계층(Application Layer)에서 동작하며, HTTP/HTTPS 트래픽을 완전히 해석하고 처리합니다. Connection Termination을 수행하여 클라이언트와 서버 간 연결을 분리합니다.
# ALB 동작 원리
Client → ALB → Target Server
연결1 종료 새 연결 생성
지연시간: ~10 밀리초 (NLB의 100배)
처리량: 초당 수천~수만 요청기술적 특징 상세 분석
1. IP 주소 관리
NLB: 고정 IP 지원
# 각 AZ마다 고정 Network Interface 생성
AZ-1: 10.0.1.100 (Elastic IP 할당 가능)
AZ-2: 10.0.2.100 (Elastic IP 할당 가능)
# 방화벽 규칙 설정 용이
firewall-rule --allow-from 10.0.1.100ALB: 동적 IP만 지원
# DNS 이름으로만 접근
myalb-123456.elb.amazonaws.com
# IP는 자동 스케일링에 따라 수시로 변경2. Connection 처리 방식
NLB: Connection Tracking
# 5-tuple 해시 기반 라우팅
connection_table = {
(src_ip, src_port, dst_ip, dst_port, protocol): target_server
}
# TCP 연결 유지 시간
- Active: 350초 (기본값, 최대 86400초)
- UDP Flow: 120초
- Connection Draining: 300초ALB: Request 단위 라우팅
// 라우팅 규칙 예시
if (path.startsWith("/api")) {
route_to("api-target-group");
} else if (host === "admin.example.com") {
route_to("admin-target-group");
} else if (header["X-Mobile-App"] === "true") {
route_to("mobile-backend");
}3. 프로토콜 지원
NLB 지원 프로토콜:
- TCP, UDP, TLS
- 모든 포트 (1-65535)
- 비HTTP 프로토콜 (게임, DB, MQTT 등)
ALB 지원 프로토콜:
- HTTP/1.1, HTTP/2, WebSocket
- 포트 제한 (80, 443 등 특정 포트)
- gRPC (HTTP/2 기반)
성능과 비용 비교
성능 벤치마크
테스트 환경: c5.large 인스턴스 10대, 1KB 페이로드
NLB 결과:
- Latency P50: 0.1ms
- Latency P99: 0.5ms
- Throughput: 3,000,000 req/sec
- CPU Usage: 5%
ALB 결과:
- Latency P50: 10ms
- Latency P99: 50ms
- Throughput: 50,000 req/sec
- CPU Usage: 25%비용 구조
NLB 비용 (us-east-1):
- 시간당: $0.0225
- NLCU당: $0.006
- Cross-AZ 트래픽: 선택적 (비활성화 가능)
ALB 비용 (us-east-1):
- 시간당: $0.0225
- LCU당: $0.008
- 평가 기준: 새 연결, 활성 연결, 처리량, 규칙 평가실전 사용 사례
사례 1: 게임 서비스 아키텍처
# 실시간 게임 서버
Game Client → NLB (Port 3000) → Game Server
이유:
- TCP 소켓 연결 유지 필수
- 초저지연 요구 (10ms 이하)
- Source IP 보존으로 핵 탐지
# 게임 API 서버
Mobile App → ALB → REST API
이유:
- Path 기반 라우팅 (/v1/*, /v2/*)
- HTTP/2로 다중 요청 처리
- 점진적 배포 (Canary)사례 2: 금융 서비스 아키텍처
# 거래 시스템
Trading System → NLB → FIX Gateway
이유:
- 고정 IP 필수 (규제 요구사항)
- Ultra-low latency (< 1ms)
- Non-HTTP 프로토콜 (FIX)
# 뱅킹 웹/앱
Customer → ALB → Banking API
이유:
- Host 기반 멀티 테넌시
- WAF 통합 보안
- 상세한 액세스 로그사례 3: 하이브리드 패턴
# ALB + NLB 조합
External → NLB (고정 IP) → ALB (L7 라우팅) → Services
장점:
- 고정 IP 요구사항 충족
- L7 라우팅 기능 활용
- 단계별 트래픽 제어
구현:
aws elbv2 create-target-group \
--target-type alb \
--targets Id=arn:aws:elasticloadbalancing:...Target 장애 시 동작 차이
NLB의 Connection Persistence
def handle_unhealthy_target():
"""
NLB는 기존 연결을 유지하려 함
"""
if existing_connection:
# Health Check 실패해도 기존 연결은 유지
continue_routing_to_unhealthy_target()
# Client가 RST 받고 재연결 시도해야 함
else:
# 새 연결만 건강한 타겟으로
route_to_healthy_target()ALB의 즉각적 재라우팅
def handle_unhealthy_target():
"""
ALB는 즉시 다른 타겟으로 전환
"""
# 모든 새 요청을 건강한 타겟으로
healthy_targets = get_healthy_targets()
route_to(random.choice(healthy_targets))모니터링과 디버깅
NLB 모니터링 포인트
주요 메트릭:
- ActiveFlowCount: 활성 연결 수
- NewFlowCount: 초당 새 연결
- ProcessedBytes: 처리된 데이터량
- TargetTLSNegotiationErrors: TLS 핸드셰이크 실패
로깅:
- Flow Logs만 지원 (Connection 레벨)
- 패킷 내용은 볼 수 없음ALB 모니터링 포인트
주요 메트릭:
- RequestCount: HTTP 요청 수
- TargetResponseTime: 응답 시간
- HTTPCode_Target_4XX_Count: 4xx 에러
- HTTPCode_Target_5XX_Count: 5xx 에러
로깅:
- Access Logs (상세한 HTTP 정보)
- 모든 헤더, 경로, 응답 코드 기록선택 가이드라인
NLB를 선택해야 할 때
- 초저지연이 필수인 경우 (< 1ms)
- 고정 IP가 필요한 경우
- Non-HTTP 프로토콜 사용
- 극한의 처리량 필요 (millions/sec)
- Source IP 보존 필요
ALB를 선택해야 할 때
- HTTP/HTTPS 트래픽 전용
- Path/Host 기반 라우팅 필요
- WebSocket, HTTP/2 지원 필요
- WAF 통합 필요
- 상세한 모니터링/로깅 필요
마무리
ALB와 NLB는 각각의 강점이 명확한 서비스입니다. 단순히 L7과 L4의 차이로 이해하기보다는, 실제 워크로드의 특성과 요구사항을 정확히 파악하여 선택해야 합니다.
특히 최근에는 마이크로서비스 아키텍처에서 ALB를, 컨테이너 서비스 메시에서 NLB를 조합하여 사용하는 하이브리드 패턴이 늘어나고 있습니다. 각 로드밸런서의 특성을 정확히 이해하고 있다면, 더 효율적이고 안정적인 아키텍처를 설계할 수 있을 것입니다.
기록하고 공유하려고 노력하는 DevOps 엔지니어