로드밸런싱 — L2, L4, L7 완벽 이해

쉽게 말하면, 로드밸런서는 교통 경찰과 같다. 한 도로(서버)에 차가 몰리면 다른 도로로 유도하여 교통 체증(서버 과부하)을 방지한다.

핵심 차이는 "패킷의 어디까지 열어보느냐"다:

• L2 MAC 주소만 보고 분산 (가장 저수준)
• L4 IP + 포트번호까지 보고 분산 (TCP/UDP 레벨)
• L7 HTTP 헤더, URL, 쿠키 등 애플리케이션 내용까지 보고 분산 (가장 고수준)

왜 로드밸런싱이 필요한가?

단일 서버는 처리할 수 있는 요청 수에 한계가 있다. 트래픽이 늘어나면 두 가지 선택지가 있다:

• Scale-Up (수직 확장): 서버의 CPU, 메모리를 업그레이드 — 한계가 명확하고 비용이 급격히 증가
• Scale-Out (수평 확장): 서버를 여러 대 두고 트래픽을 분산 — 로드밸런서가 필수

OSI 계층과의 관계

로드밸런싱의 L2, L4, L7은 OSI 7계층 모델에서 유래한다:

• L2 (Data Link): MAC 주소 기반 — 프레임 단위 처리
• L4 (Transport): TCP/UDP 포트 기반 — 세그먼트 단위 처리
• L7 (Application): HTTP, gRPC 등 — 메시지 단위 처리

계층이 높을수록 더 많은 정보를 볼 수 있지만, 그만큼 처리 비용(오버헤드)이 증가한다.

로드밸런싱 알고리즘

어떤 서버로 보낼지 결정하는 알고리즘도 알아야 한다:

• Round Robin: 순서대로 돌아가며 분배 (가장 단순)
• Weighted Round Robin: 서버 성능에 따라 가중치 부여
• Least Connections: 현재 연결 수가 가장 적은 서버로
• IP Hash: 클라이언트 IP 기반 해시로 항상 같은 서버로 (세션 유지)
• Least Response Time: 응답 시간이 가장 빠른 서버로

L2 L2 로드밸런싱 (Data Link Layer)

MAC 주소를 변경하여 트래픽을 분산한다. 클라이언트가 보낸 프레임의 목적지 MAC 주소를 실제 서버의 MAC으로 교체하여 전달하는 방식이다.

• 동작 원리: 로드밸런서와 서버들이 같은 네트워크(같은 서브넷, 같은 VIP)에 있어야 한다. IP 주소는 변경하지 않고 MAC 주소만 바꾼다.
• 장점: IP 변환이 없어 매우 빠르다. 서버가 클라이언트에게 직접 응답 가능 (DSR — Direct Server Return)
• 단점: 같은 네트워크 세그먼트에서만 동작. 서버가 물리적으로 가까이 있어야 한다.
• 실무 사용: 대규모 트래픽 환경에서 DSR 모드와 함께 사용. 응답 트래픽이 로드밸런서를 거치지 않으므로 병목을 줄인다.

L4 L4 로드밸런싱 (Transport Layer)

TCP/UDP 레벨에서 IP 주소와 포트 번호를 기반으로 트래픽을 분산한다. 패킷의 페이로드(내용)는 보지 않는다.

• 동작 원리: 클라이언트의 TCP SYN 패킷을 받으면 대상 서버를 결정하고, 이후 해당 연결의 모든 패킷을 같은 서버로 전달 (Connection-level affinity)
• NAT 방식: 목적지 IP를 서버 IP로 변환 (DNAT). 응답 시 다시 로드밸런서 IP로 변환 (SNAT)
• 장점: 패킷 내용을 해석하지 않으므로 빠르고 효율적. SSL/TLS 종단이 불필요. 프로토콜에 무관 (HTTP뿐 아니라 DB, SMTP, 게임 서버 등 모두 가능)
• 단점: 요청 내용(URL, 헤더)을 모르므로 세밀한 라우팅 불가. 마이크로서비스별 분기 불가.
• 대표 제품: AWS NLB (Network Load Balancer), HAProxy (TCP mode), LVS (Linux Virtual Server), F5 BIG-IP

L7 L7 로드밸런싱 (Application Layer)

HTTP/HTTPS 요청의 전체 내용을 파싱하여 URL 경로, 호스트 헤더, 쿠키, HTTP 메서드 등을 기반으로 분산한다.

• 동작 원리: 로드밸런서가 TCP 연결을 종료(terminate)하고, HTTP 요청을 파싱한 뒤, 규칙에 따라 적절한 백엔드 서버로 새 연결을 맺어 요청을 전달
• 콘텐츠 기반 라우팅 예시:
  • /api/* → API 서버 클러스터로
  • /static/* → CDN 또는 정적 파일 서버로
  • Host: admin.example.com → 관리자 서버로
  • Cookie: AB_TEST=B → B 테스트 서버로
• SSL Termination: L7 로드밸런서에서 HTTPS를 복호화하고, 백엔드에는 HTTP로 전달. 인증서 관리를 중앙화할 수 있다.
• 장점: 가장 정밀한 라우팅. 요청/응답 변환 가능 (헤더 추가/삭제, URL 재작성). WebSocket, gRPC 등 프로토콜별 최적화. 보안 기능 (WAF, Rate Limiting, Bot 탐지)
• 단점: 패킷 내용 파싱으로 인한 오버헤드. L4 대비 처리량(throughput)이 낮다. SSL 복호화 비용.
• 대표 제품: AWS ALB (Application Load Balancer), Nginx, Envoy Proxy, Traefik, Cloudflare

실무에서의 조합 패턴

실제 프로덕션 환경에서는 L4와 L7을 조합해서 사용하는 경우가 많다:

Client → L4 LB (NLB) → L7 LB (Nginx/ALB) → Backend Servers

• L4 LB가 앞단에서 대규모 트래픽을 빠르게 분산
• L7 LB가 뒷단에서 콘텐츠 기반 정밀 라우팅 수행
• Google, Netflix 등 대규모 서비스가 이 구조를 사용

헬스 체크

로드밸런서는 주기적으로 서버 상태를 확인하여 장애 서버를 자동으로 제외한다:

• L4 헬스 체크: TCP 연결이 되는지 확인 (포트가 열려있는지)
• L7 헬스 체크: HTTP GET /health로 200 응답이 오는지 확인 — 애플리케이션 수준의 정상 여부 판단 가능

위 다이어그램은 L2/L4/L7 로드밸런서가 패킷의 어느 부분까지 읽는지를 시각적으로 보여준다. L2는 MAC만, L4는 IP+Port까지, L7은 HTTP 요청 전체를 파싱한다.