요즘 개발자를 위한 시스템 설계 수업 - 4장 분산 시스템의 기본 요소: DNS, 로드밸런서, 애플리케이션 게이트웨이 - 2

4.3 로드 밸런서

여러 서버로 네트워크를 통한 부하 분산

로드 밸런서 유형	판단 기준	장점 (Pros)	단점 및 리스크 (Cons)	대표 기술
L4 (Transport)	IP 주소, TCP/UDP 포트	암호화 해제 없이 초고속 라우팅, 커널 레벨 처리로 부하 적음	HTTP 경로/헤더 기반의 세밀한 라우팅 불가능	LVS, HAProxy(TCP), AWS NLB
L7 (Application)	HTTP URI, Header, Cookie	URL 기반 마이크로서비스 라우팅, SSL 오프로딩 가능	패킷 파싱으로 인한 지연(Latency) 증가 및 CPU 부하	Nginx, AWS ALB, Envoy

특징

• 부하 분산
• 장애 시 다른 서버로 재전송
• 높은 부하에도 시스템 성능이 점진적으로 저하되어 운동은 가능하도록 유지
• 수평 확장 용이

4.3.1 로드 밸런서 위치

• 각 계층 사이 목적에 따라 배치하여 부하를 분산하고 확정성 확보
• 하위 계층에 문제가 생겨도 트래픽을 우회시켜 시스템 안정성 확보

4.3.2 로드 밸런서의 장점

• 헬스 체크로 서버 동작 확인
• TLS 연결 대신하여 내부 백엔드 서버 부하 감소
• 다양한 요청 분배 알고리즘

4.3.3 전역 로드 밸런싱과 로컬 로드 밸런싱

 

전역 로드 밸런싱 (Global Load Balancing, GSLB)

• 주로 DNS 레벨이나 네트워크 라우팅 레벨
• 리전(혹은 데이터 센터) 간 트래픽 분배
• 보통 직접 트래픽을 중계하는게 아닌 목적지 IP 주소를 반환

로컬 로드 밸런싱 (Local Load Balancing, LLB)

• 보통 리전(혹은 데이터 센터) 내부 레벨
• 실제 노드로 분배
• 클라이언트의 TCP 연결을 직접 수행(SSL), 모든 트래픽이 모이는 지점

 

구분	Global Load Balancing (GSLB)	Local Load Balancing (LLB)
적용 범위	글로벌 (리전 간, 데이터센터 간)	로컬 (단일 리전, 단일 VPC 내)
라우팅 기준	GeoIP, 지연 시간(Ping), 리전의 전체 헬스 상태	서버의 CPU/메모리 부하, 활성 커넥션 수(Least Conn)
동작 메커니즘	DNS 응답(A/AAAA/CNAME 반환) 또는 Anycast	리버스 프록시 (트래픽 패킷을 직접 수신 및 포워딩)
주요 목적	재해 복구(DR), 글로벌 지연 시간 최소화	서버 수평 확장(Scale-out), 마이크로서비스 라우팅
장애 시 영향	특정 리전 다운 시 타 리전으로 거시적 우회	리전 내 특정 서버 다운 시 정상 서버로 미시적 우회

 

4.3.4 DNS와 전역 로드 밸런서

• DNS도 전역 로드 밸런서 역할 수행
• 하나의 DNS 요청에 여러 IP를 반환

한계

• DNS 패킷 크기 512 Byte 한계
  • 최대 13~30개 내외의 IP만 반환. 전체 서버 중 극히 일부만 로드 밸런싱 풀에 참여함
  • 즉, 서버가 100 대 이상인 거대 서비스 회사들은 전체 서버 IP를 반환 못하여 클라이언트는 일부 서버 중 빠른 서버에 접근함
• TTL 캐싱
  • 죽은 서버를 감지 못해, TTL이 남아있는 한 계속 죽은 서버로 보냄
• L7 애플리케이션 레이어 상태 인지 불가

4.3.5 로드 밸런서가 사용하는 알고리즘

• 라운드 로빈
  • 순차 분배
• 가중치 기반 라운드 로빈
  • 일반적으로 사용법 : 서버 성능이 높은 쪽에 더 가중치
    
• 최소 연결 
• 최소 응답 시간
• IP 해시, URL 해시, 일관성 해시 알고리즘
• EWMA (Exponentially Weighted Moving Average)
  • 단순 평균 응답 시간이 아닌 '최근' 응답 시간에 기하급수적 가중치를 주어 찰나의 지연 시간 스파이크(Spike)를 즉각 회피

 

알고리즘 (Algorithm)	최적의 사용 사례 (Best Use Case)	치명적인 단점 (Worst Case)
Round Robin	모든 서버 스펙이 동일하고, 각 요청의 처리 시간(비용)이 비슷할 때	비디오 인코딩처럼 특정 요청만 무거운 경우 부하 불균형 발생
Least Connections	WebSocket이나 대용량 파일 다운로드처럼 '긴 연결(Long-lived)'이 많을 때	신규 서버 투입 시 트래픽이 폭주하는 'Thundering Herd' 위험
IP Hash / URI Hash	인메모리 세션 유지가 필수적이거나 특정 유저/경로의 캐시 히트율을 극대화할 때	트래픽이 많은 특정 유저(Heavy User)가 할당된 서버만 과부하 핫스팟이 됨
Consistent Hashing	Memcached, Redis 등 대규모 분산 캐시 클러스터의 샤딩(Sharding)	서버 간 해시 링(Ring) 배치 간격이 좁을 경우 부하 편중 (가상 노드로 해결)

정적 알고리즘 vs 동적 알고리즘

• 상태를 고려하면 동적, 아니면 정적 알고리즘
• 동적 알고리즘
  • 최소 연결
  • 최소 응답 시간
• 정적 알고리즘
  • 라운드 로빈
  • 가중치 라운드 로빈
  • IP 해시, URL 해시, 일관성 해시 알고리즘

주의점

• Auto Scaling 으로 신규 서버가 추가될 때 로드 밸런서는 Slow Start(Warm-up period)를 해 점진적으로 트래픽을 개방해야 한다. 서버들이 DB 커넥션풀을 맺기도 전에 트래픽이 폭주해 서버가 다운될 수 있다.(Thundering Herd)
• 애플리케이션 서버의 Sticky Session 방식은 로드 밸런서의 선택권을 크게 제약한다. 같은 요청은 항상 같은 서버로 보내야 하기에 IP Hash 같은 알고리즘을 강제
  문제는 서버가 부하가 심할 때도 부하를 분산할 수 없음
  중앙 집중화된 캐시 서버를 두고 애플리케이션 서버는 무상태를 유지해야 극복

아키텍처	장점 (Pros)	단점 및 리스크 (Cons)	로드 밸런서 제약
Sticky Session (서버 로컬 메모리)	구현이 단순함, 외부 저장소(Redis) 인프라 비용 없음	특정 서버에 트래픽 편중(Hotspot), 서버 배포/다운 시 유저 로그아웃 됨	매우 높음 (IP Hash 등 특정 알고리즘 강제, 트래픽 분산 실패)
Redis Session (중앙 집중형)	서버 무중단 배포 가능, 완벽한 트래픽 균등 분산, 동시 접속 제어 용이	Redis 클러스터 구축 비용 및 네트워크 I/O 오버헤드 증가	제약 없음 (Round Robin, Least Conn 등 자유롭게 사용 가능)
JWT (토큰 기반 완전 무상태)	Redis조차 필요 없는 완벽한 Stateless	토큰 탈취 시 강제 로그아웃/만료 처리 어려움 (블랙리스트 관리 필요)	제약 없음

스테이트풀 vs 스테이트리스

• 클라이언트 세션 정보를 유지하면 스테이트풀 아니면 스테이스리스
• 스테이트풀
  • 클라이언트와 백엔드 서버 간에 연결 상태 정보를 저장
  • 모든 로드 밸런서는 저 상태 정보를 공유해야 하므로 시스템이 복잡하고 확장성 한계
•  
• 스테이트리스
  • 상태 정보 저장 안함
  • 일관된 해싱 알고리즘을 사용하여 요청을 서버에 매핑
    • 선택권은 없음, 반드시 일관된 해싱 알고리즘을 사용해야 인프라 변경에 따른 부하 분산을 수용할 수 있
  • 인프라 변경에 강하나 무상태이기에 서버 부하에 따른 적절한 요청 분배는 불가

비교 항목	Stateful Load Balancer	Stateless Load Balancer
상태 저장 위치	로드 밸런서의 메모리 (Conntrack/Socket)	저장하지 않음 (오직 Hash 연산)
처리 성능 (Throughput)	높음 (단, 메모리 한계치 존재)	초고도 (하드웨어/네트워크 카드 한계까지)
LB 장비의 수평 확장	Active-Standby 위주 (상태 동기화 오버헤드)	Active-Active 무한 확장 가능 (ECMP)
백엔드 변경 시 영향	기존 연결은 상태 테이블 유지로 안전함	기존 TCP 연결이 끊어질 위험이 매우 높음 (RST)
L7 심층 검사 (HTTP)	가능 (헤더, 쿠키, URI 검사 및 라우팅)	불가능 (단일 패킷만 보고 L4 이하에서 포워딩)

4.3.6 OSI 모델의 각 계층에서 로드 밸런싱

L4 로드 밸런싱 (Transport Layer)

• 판단 기준: IP 주소 + TCP/UDP 포트 번호.
• 패킷의 내용물(데이터)은 전혀 보지 않고, 서버 A의 80번 포트로 보내자"라는 식의 단순 라우팅을 수행
• 주로 커널 레벨의 NAT 기술로 구현되며 속도가 매우 빠름 (예: AWS NLB, LVS)
• 단순 포워딩을 수행하기 때문에 상세 로깅이 불가

L7 로드 밸런싱 (Application Layer)

• 판단 기준: HTTP 헤더, URL 경로(URI), 쿠키, 페이로드 데이터.
• 클라이언트의 네트워크 패킷을 끝까지 조립하여 내용물을 모두 읽음
•  "/api/users" 경로는 유저 서비스로, "/api/orders"는 주문 서비스로 분기하는 마이크로서비스 아키텍처(MSA)의 필수 요소
• 암호화된 트래픽(HTTPS)을 복호화하는 역할도 병행 (예: AWS ALB, Nginx, Envoy)

• 참고로 DNS는 L7 로드 밸런싱에 속함
• 트래픽이 많은 거대 기업은 부하가 적은 L4 로드 밸런서을 가장 외부에 두고, 내부에는 L7 로드 밸런서로 정밀하게 제어하는 2 Tier 구조를 사용함

계층 (Layer)	데이터 식별자	성능 / 대역폭	암호화 트래픽 (TLS)	헬스 체크 정밀도	라우팅 유연성
L3 (Network)	IP 주소	최고 (하드웨어 ASIC 수준)	내용물 확인 불가	불가능에 가깝음 (ICMP 핑)	리전/데이터센터 분산
L4 (Transport)	IP + Port (TCP/UDP)	높음 (커널 NAT)	통과시킴 (Pass-through)	낮음 (TCP 포트 오픈 여부)	단순 포트 포워딩
L7 (Application)	HTTP URL, Header, Cookie	상대적 낮음 (CPU 병목)	LB 단에서 복호화 (Termination)	매우 높음 (HTTP 200 응답 확인)	마이크로서비스 경로 분산

DSR((Direct Server Return))

• 클라이언트 요청을 로드 밸런서가 받지만 응답은 백엔드 서버가 클라이언트로 직접한다.
• 이로 인해 로드 밸런서는 수십 배 더 처리량이 늘어나게 된다.
• 일반적인 로드 밸런서는 들어오는 요청과 나가는 응답을 자신이 처리하지만 웹 트래픽은 극도로 비대칭적인 트래픽 흐름을 가지고 있다. 유튜브의 경우 사용자는 단순 요청만 하지만 응답은 수백 수천배 이상의 차이가 난다. 
• DSR은 이 문제를 해결한다

• L4 로드 밸런서에만 적용가능, 단순 패킷 포워딩만 하기 때문
• 스트리밍 서비스나 CDN 오리진 서버에서 DSR은 선택이 아닌 필수

아키텍처 비교	일반 L4 LB (NAT 방식)	DSR (Direct Server Return 방식)
트래픽 흐름	Client ↔ LB ↔ Backend Server	Client ➔ LB ➔ Backend Server ➔ Client
LB 대역폭 소모	Inbound / Outbound 모두 소모	Inbound만 소모 (거의 0에 수렴)
패킷 변조 방식	IP 주소 변환 (DNAT / SNAT)	MAC 주소 변환 (L3 IP는 보존됨)
백엔드 서버 설정	별도 설정 불필요	VIP를 Loopback 인터페이스에 등록 & ARP 억제 필수
인프라 제약 사항	제약 없음 (서로 다른 대역망 가능)	L2 DSR은 동일 서브넷(Broadcast Domain) 내에 존재해야 함

4.3.7 로드 밸런서의 배치

• DNS 로 분배
• 특수 라우터로 분배
• L4 분배
• L7 분배

 

4.3.8 로드 밸런서의 구현

구분	하드웨어 로드 밸런서 (HLB)	소프트웨어 로드 밸런서 (SLB)	클라우드 로드 밸런서 (CLB)
도입 형태	물리적 네트워크 어플라이언스	리눅스 서버 + 설치형 SW	완전 관리형 서비스 (SaaS/PaaS)
비용 구조	높은 CapEx (초기 장비 구매)	장비/VM 렌탈 + 오픈소스 (저비용)	완전한 OpEx (트래픽/시간당 종량제)
확장성 (Scaling)	스케일 업 위주 (장비 교체 필요)	스케일 아웃 가능 (직접 노드 증설)	무한 자동 스케일 아웃 (CSP 담당)
관측/통제권	벤더 종속적 펌웨어	최상 (OS 커널 단위 튜닝 가능)	낮음 (블랙박스, 제공되는 메트릭만 확인)
대표 제품	F5 BIG-IP, Citrix ADC	HAProxy, Nginx, Envoy	AWS ALB/NLB, Google CLB

• 속도는 당연히 하드웨어 로드 밸런서가 가장 빠르지만, 최근 소프트 웨어 로드 밸런서도 많이 빨라짐
• DPDK / eBPF: 범용 리눅스 서버에서 소프트웨어 로드 밸런서(SLB)가 커널의 무거운 네트워크 스택을 우회하여(Kernel Bypass), 하드웨어에 필적하는 패킷 처리 속도를 내게 해주는 최신 리눅스 기술.