초보도 이해하는 L4 분산 방식: 라운드 로빈(RR), 해시(Hash), 스티키(sticky) 핵심 정리

왜 로드밸런서(Load Balancer)가 필요할까?

서비스 이용자가 늘어나면 한 대의 서버로는 속도와 안정성을 지키기 어렵습니다. 로드밸런서(LB)는 들어오는 요청을 여러 서버에 나눠 보내 전체 처리량을 올리고, 장애가 발생해도 서비스가 멈추지 않도록 해주는 “교통 정리” 역할을 합니다.

L4와 L7은 무엇이 다를까?

- L4 로드밸런서(Layer 4 Load Balancer): IP, 포트, 프로토콜(TCP/UDP) 같은 전송계층 정보를 기준으로 분산합니다. 요청 본문은 보지 않아 가볍고 빠릅니다.
- L7 로드밸런서(Layer 7 Load Balancer): URL, 헤더(Header), 쿠키(Cookie) 등 애플리케이션 정보를 보고 더 정교하게 분산합니다. 세밀하지만 상대적으로 무겁습니다.
현실에서는 L4로 기본 분산을 하고, 꼭 필요한 일부 경로만 L7로 미세 조정하는 조합이 흔합니다.

 

트래픽은 어떤 방식으로 나눌까?

- 라운드 로빈(Round Robin, RR)
서버에 1번, 2번, 3번… 순서대로 차례차례 배정합니다. 설정이 단순하고 동작이 예측 가능해 가장 널리 쓰이는 기본값입니다.

- 가중치 라운드 로빈(Weighted Round Robin, WRR)
성능이 좋은 서버에 가중치(Weight)를 줘 더 많은 요청을 보냅니다. 예: 2배 스펙 서버에 2배 비율로 분배.

- 최소 연결(Least Connections, LC)
현재 활성 연결(Active Connections)이 가장 적은 서버를 고릅니다. 세션 길이 편차가 클 때 유리하지만, 장시간 연결(WebSocket)이나 무거운 작업이 섞이면 “연결 수 = 부하”가 항상 성립하진 않습니다.

- 해시 기반(Hash-Based, 일관 해시 Consistent Hashing 포함)
소스 IP(Source IP) 또는 5-튜플(5-Tuple: 소스/목적지 IP·포트, 프로토콜)을 해시(Hash)로 계산해 특정 서버에 일관되게 매핑합니다. 같은 사용자나 플로우가 같은 서버로 가므로 캐시 적중률이 좋아집니다.
예시(간단): 전화번호 끝자리로 담당 창구를 정해 두면, 다음에 전화해도 같은 창구로 연결되는 느낌입니다.

 

응답 경로는 어떻게 구성할까?

- 풀 프록시(Full Proxy)
클라이언트↔LB와 LB↔서버 연결을 분리합니다. 세밀한 제어·보안 연계·관측에 유리합니다.

- DSR(Direct Server Return)
요청은 LB를 거치고, 응답은 서버가 클라이언트로 직접 보냅니다. 대역폭 효율이 좋지만 구성 난도가 있습니다.

- SNAT/DNAT(Source/Destination NAT)
주소 변환으로 서버 IP를 숨기고 경로를 단순화하는 일반적인 방식입니다.

왜 대부분 라운드 로빈(RR)을 기본으로 쓸까?

- 단순하고 빠르다: 계산이 가벼워 고성능 환경에서도 안정적입니다.
- 예측 가능하다: 설정·운영·트러블슈팅이 쉽고, 증설/장애 복구 시 분배 패턴이 급격히 흔들리지 않습니다.
- 실제로 충분한 경우가 많다: 짧은 요청, HTTP/2/Keep-Alive 환경에서는 활성 연결 불균형이 체감될 정도로 크지 않은 경우가 많습니다.
운영에서는 RR을 기본으로 두고, 특정 워크로드에서만 LC나 해시를 선택적으로 적용하는 전략이 리스크를 낮춥니다.

스티키(sticky, 세션 지속성)는 무엇일까?

스티키는 “같은 사용자는 같은 서버로” 보내는 규칙입니다. 로그인 상태, 장바구니, 결제처럼 “이어지는 흐름”이 중요한 서비스에서 끊김 없이 경험을 유지하게 합니다.
예시(짧게): 장바구니를 서버 A에 저장했는데 다음 요청이 서버 B로 가면 비어 보일 수 있습니다. 스티키는 계속 서버 A로 보내 이 문제를 막습니다.

스티키니스 옵션(Sticky Options)은 어떻게 고를까?

- 소스 IP 기반(Source IP Sticky)
같은 인터넷 주소에서 오는 요청을 같은 서버로 보냅니다. 간단하지만 공용 IP(회사·카페)에서는 특정 서버로 쏠림이 생길 수 있습니다.

- 세션(연결) 기반(Session/Connection Sticky)
한 번 맺은 연결이 끝날 때까지 같은 서버로 유지합니다. HTTP/2, gRPC 같이 한 연결에 여러 요청이 오가는 환경에 기본적이고 안전합니다.

- 해시 기반 스티키(Hash/Consistent Hash Sticky)
사용자나 플로우 속성으로 해시해 항상 같은 서버에 매핑합니다. 캐시 적중률↑, 서버 증감에도 일관성 유지가 용이합니다.

- 시간 제한(Time-based Sticky Timeout)
지속 시간을 둬 특정 서버에 무기한 묶이지 않게 하고 쏠림을 완화합니다. 예: 30분.

라운드 로빈과 스티키, 어떻게 함께 쓰면 좋을까?

- 기본 분산은 라운드 로빈(RR)으로 단순하고 넓게 적용
- 로그인·장바구니·결제 등 꼭 필요한 경로에만 스티키(sticky) 선택 적용
- 서버 성능 차이는 가중치(WRR)로 보정
- 서버 증감이 잦다면 일관 해시(Consistent Hashing)와 슬로우 스타트(Slow Start)로 안정화
- 타임아웃과 헬스 체크(Health Check)로 과도한 묶임과 비정상 서버 문제를 예방

언제 어떤 방식을 쓰면 좋을까?

- 조회 위주·짧은 요청, 서버 성능 유사: RR 기본, 필요 시 WRR
- 세션 길이 편차 큼: LC/WLC
- 캐시·일관성 중요(게임 로비, 실시간 매칭, 일부 API): 해시 기반(Consistent Hash)
- 대용량 다운로드/단방향 응답 큼: DSR 고려
- 로그인/장바구니/결제: 스티키 + 적절한 타임아웃

한 줄 정리
기본은 단순하고 예측 가능한 라운드 로빈(RR). “이어지는 경험”은 스티키(sticky)로 지키고, 필요한 구간만 LC/해시/타임아웃/슬로우 스타트로 다듬으면 안정성과 효율을 함께 잡을 수 있습니다.

 

♥읽어주셔서 감사합니다♥
티스토리 댓글과 공감♥은 로그인이 필요 없습니다.
로그인하시면 구독 가능합니다.