로드밸런서 (L4 vs L7)
트래픽을 여러 서버에 분산시켜 가용성과 성능을 높이는 장치
왜 필요한가?
[로드밸런서 없이]
Client ──→ Server (과부하! 다운!)
[로드밸런서 있을 때]
┌→ Server A
Client → LB ├→ Server B
└→ Server C
L4 vs L7 비교
| 계층 | 이름 | 로드밸런서 |
|---|
| L7 | 응용 (HTTP, HTTPS) | L7 LB 가 여기서 동작한다 |
| L6 | 표현 | |
| L5 | 세션 | |
| L4 | 전송 (TCP, UDP) | L4 LB 가 여기서 동작한다 |
| L3 | 네트워크 | |
| L2 | 데이터링크 | |
| 구분 | L4 (전송 계층) | L7 (응용 계층) |
|---|
| 판단 기준 | IP, Port | URL, 헤더, 쿠키 |
| 속도 | 빠름 | 상대적 느림 |
| 기능 | 단순 분산 | 콘텐츠 기반 라우팅 |
| SSL 처리 | 불가 | SSL Termination |
| 예시 | AWS NLB | AWS ALB, Nginx |
| 비용 | 저렴 | 상대적 비쌈 |
L4 로드밸런서
Client → [L4 LB]
IP: 10.0.0.1, Port: 443
→ Server A (10.0.0.2:443)
패킷의 IP/Port만 보고 분산
내용(HTTP 경로 등)은 확인 불가
적합한 경우:
- 단순 TCP/UDP 트래픽 분산
- 게임 서버, DB 연결
- 최대 처리량이 중요할 때
L7 로드밸런서
Client → [L7 LB]
GET /api/users → API Server
GET /images/* → Static Server
Host: m.app.com → Mobile Server
HTTP 내용을 분석하여 라우팅
적합한 경우:
- 마이크로서비스 (경로별 라우팅)
- A/B 테스트 (헤더/쿠키 기반)
- SSL Termination (인증서 관리)
- 웹소켓 처리
분산 알고리즘
| 알고리즘 | 설명 | 적합한 경우 |
|---|
| Round Robin | 순서대로 분배 | 서버 성능 동일 |
| Weighted RR | 가중치 기반 | 서버 성능 다름 |
| Least Connections | 연결 적은 서버 | 요청 처리 시간 다양 |
| IP Hash | IP 기반 고정 | 세션 유지 필요 |
| URL Hash | URL 기반 고정 | 캐시 효율성 |
실무 아키텍처
| 경로 | 앞단 | 뒤로 보내는 곳 |
|---|
| /api/* | L7 LB (ALB 또는 Nginx) | L4 LB 를 거쳐 API 서버들 |
| /ws/* | L7 LB | WebSocket 서버들 |
| 나머지 | L7 LB | CDN 을 거쳐 정적 파일 |
Health Check
LB → Server A (정상)
LB → Server B (응답 없음)
LB → Server C (정상)
→ Server B 제외, A와 C로만 분산
→ Server B 복구되면 다시 포함
Q.L4와 L7 로드밸런서의 차이를 설명해주세요.
어느 계층까지 들여다보는지가 다릅니다.
| 항목 | L4 | L7 |
|---|
| 보는 것 | IP 와 포트 | 경로, 헤더, 쿠키, 호스트 |
| 처리 | 패킷을 그대로 전달 | 연결을 끊고 새로 맺는다 |
| 속도 | 빠르다 | 상대적으로 느리다 |
| 할 수 있는 일 | 단순 분배 | 경로 기반 라우팅, 헤더 조작, 캐싱, 압축 |
| TLS | 그대로 통과시킬 수 있다 | 여기서 종료하는 것이 일반적 |
L7 이 내용을 보려면 암호를 풀어야 하므로 TLS 종료가 따라옵니다. 그래서 인증서 관리가 로드밸런서로 모입니다.
/api/* -> API 서버들 경로로 나눈다. L7 만 가능
/ws/* -> WebSocket 서버
그 외 -> 정적 파일
흔한 실수: L4 가 항상 빠르니 낫다고 답하는 것. 경로 기반 라우팅, 헤더로 카나리 배포, 응답 캐싱은 L7 에서만 됩니다. 필요한 기능이 있으면 속도를 조금 내주고 L7 을 씁니다.
Q.로드밸런싱 알고리즘에는 어떤 것들이 있나요?
| 알고리즘 | 방식 | 잘 맞는 상황 |
|---|
| 라운드 로빈 | 차례대로 | 서버 사양이 같고 요청 비용이 비슷하다 |
| 가중 라운드 로빈 | 사양에 따라 비율을 다르게 | 서버 사양이 다르다 |
| 최소 연결 | 열린 연결이 가장 적은 곳으로 | 요청 처리 시간이 제각각이다 |
| 최소 응답 시간 | 응답이 빠른 곳으로 | 서버 상태가 수시로 변한다 |
| 해시 | 클라이언트 IP 나 키로 고정 | 세션 유지나 캐시 적중률이 필요하다 |
요청 비용이 균일하지 않은 서비스에서는 라운드 로빈이 불균형을 만듭니다. 무거운 요청이 한 서버에 몰리면 그 서버만 느려집니다. 그때는 최소 연결이 낫습니다.
어떤 알고리즘이든 헬스 체크가 함께 가야 합니다. 죽은 서버를 목록에서 빼지 않으면 분배가 소용없습니다.
흔한 실수: IP 해시로 세션 유지를 해결하려는 것. 회사나 통신사 공용 IP 뒤의 사용자가 한 서버로 몰리고, 클라이언트 IP 가 바뀌면 세션이 끊깁니다.
Q.Sticky Session이 필요한 이유와 대안은?
서버가 세션을 자기 메모리에 갖고 있어서, 같은 사용자를 같은 서버로 보내야 하기 때문입니다.
| 방식 | 문제 |
|---|
| 고정 세션 | 그 서버가 죽으면 세션이 사라진다 |
| 배포할 때마다 사용자가 로그아웃된다 |
| 부하가 고르지 않게 쏠린다 |
| 오토스케일링과 맞지 않는다 |
대안은 상태를 서버 밖으로 빼는 것입니다.
| 대안 | 내용 |
|---|
| 외부 세션 저장소 | Redis 같은 공용 저장소. 가장 흔하다 |
| 무상태 토큰 | 서버가 저장하지 않는다. 즉시 무효화가 어려워진다 |
| 클라이언트 저장 | 서명한 쿠키에 최소 정보만 |
흔한 실수: 고정 세션을 켜서 문제를 덮는 것. 당장은 동작하지만 배포와 확장에서 계속 비용을 냅니다. WebSocket 처럼 연결이 서버에 묶이는 경우는 고정이 불가피하고, 그때는 서버 간 발행 구독으로 메시지를 중계합니다.
Q.SSL Termination이란 무엇이고 왜 L7에서 하나요?
로드밸런서에서 TLS 를 풀고 뒤 구간은 평문으로 보내는 구성입니다. L7 이 내용을 봐야 하므로 여기서 종료합니다.
| 얻는 것 | 잃는 것 |
|---|
| 인증서를 한곳에서 관리 | 뒤 구간이 평문이 된다 |
| 애플리케이션 서버의 암복호 부담이 없다 | 클라이언트 IP 와 프로토콜을 헤더로 전달해야 한다 |
| 경로 라우팅, 캐싱, 압축이 가능 | 신뢰 경계가 로드밸런서로 옮겨진다 |
내부 구간 처리는 상황에 따라 다릅니다.
| 상황 | 내부 구간 처리 |
|---|
| 같은 VPC 이고 규제가 없다 | 평문 허용 |
| 민감 정보나 규제 대상 | 내부도 다시 TLS 로 감싼다 |
| 전 구간 무결성이 필요 | 복호화하지 않고 그대로 전달한다 (L4) |
마지막 방식은 안전하지만 경로 라우팅과 캐싱을 포기해야 합니다.
흔한 실수: 종료 후 애플리케이션이 클라이언트 IP 를 잘못 읽는 것. 모든 요청이 로드밸런서 IP 로 보여 접근 제어와 로그가 무의미해집니다. 전달 헤더를 읽되 신뢰할 수 있는 프록시가 붙인 부분만 신뢰해야 합니다.
Q.Health Check는 왜 필요하고 어떻게 설정하나요?
로드밸런서는 뒤에 있는 서버가 살아 있는지 스스로 알 수 없습니다. 확인하지 않으면 죽은 서버에도 계속 요청을 보냅니다.
| 방식 | 확인하는 것 |
|---|
| TCP 연결 | 포트가 열려 있는지. 프로세스가 살아 있는지만 안다 |
| HTTP 경로 | 응답 코드. 애플리케이션이 실제로 동작하는지 |
| 심층 검사 | DB 와 캐시 연결까지 확인한다 |
설정에서 갈리는 지점입니다.
| 항목 | 판단 |
|---|
| 간격 | 짧으면 빨리 감지하고 부하가 는다. 보통 5초에서 10초 |
| 실패 임계 | 1회 실패로 빼면 일시적 지연에도 서버가 빠진다. 보통 2회에서 3회 연속 |
| 복귀 임계 | 한 번 성공에 바로 넣으면 불안정한 서버가 오간다 |
| 타임아웃 | 간격보다 짧아야 한다 |
심층 검사는 주의가 필요합니다. DB 를 확인하는 경로를 쓰면 DB 장애 시 모든 서버가 동시에 빠져 서비스가 완전히 멈춥니다. 자기 상태만 보는 얕은 검사와, 의존성을 보는 준비 상태 검사를 분리하는 편이 안전합니다.
흔한 실수: 검사 경로를 루트로 두는 것. 무거운 렌더링이나 DB 조회가 걸려 있으면 검사 자체가 부하가 되고, 응답이 느려 정상 서버가 빠집니다.
먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.
읽었으면 문제로 확인해보세요
네트워크 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.