로그인 입점하기
← 가이드 목록
시작하기

로드밸런싱이란? 여러 서버에 사용자 요청을 나눠주는 원리 쉽게 이해하기

로드밸런싱은 요청을 여러 서버에 나눕니다. Round Robin·Sticky·Health Check·L4/L7·리버스 프록시·502·오토스케일까지 초보 기준으로 정리합니다.

로드밸런싱이란? 여러 서버에 사용자 요청을 나눠주는 원리 쉽게 이해하기

로드밸런싱(Load Balancing)은 사용자 요청을 여러 서버에 나눠 한곳에 부하가 몰리지 않게 하는 기술입니다. 앞단에서 분배를 담당하는 장비를 로드밸런서(Load Balancer, LB)라고 합니다.

쉽게 말하면 — 마트 계산대가 여러 대일 때 손님을 한 줄에만 몰지 않고 빈 계산대로 안내하는 것과 같습니다.

사용자 요청이 로드밸런서를 거쳐 서버 A·B·C로 분산되는 흐름
사용자 → 로드밸런서 → 서버 A·B·C

서버 한 대의 한계

방문·주문이 늘면 CPU·메모리·연결 수가 한계에 닿고, 한 대가 멈추면 전체가 멈춥니다. 그래서 동일 역할의 서버를 여러 대 두고, 그 앞에 LB를 두어 요청을 나눕니다. 이름은 「부하를 균형 있게」라는 뜻이지, 한 대 CPU를 더 빠르게 만드는 기술이 아닙니다.

수직 확장(Scale Up)은 한 서버 사양을 키우는 것(요리사 한 명에게 더 큰 주방), 수평 확장(Scale Out)은 서버를 늘리는 것(요리사를 더 두는 것)입니다. LB는 수평 확장의 입구입니다.

분배 알고리즘

  • Round Robin — A→B→C→A… 순번 분배
  • Least Connections — 현재 연결이 가장 적은 서버로
  • Weighted — 사양이 좋은 서버에 더 많은 비중
  • IP Hash — 같은 클라이언트 IP는 같은 서버로(세션 고정에 가깝게)

Sticky Session · 공유 세션

로그인·장바구니처럼 서버 메모리에만 세션이 있으면, 다음 요청이 다른 서버로 가면 풀립니다. Sticky Session은 같은 사용자를 같은 서버에 붙입니다(쿠키·해시 등으로). 그 서버가 죽으면 세션도 함께 위험합니다.

더 견고한 쪽은 Stateless 앱 + Redis 등 공유 세션 저장소입니다. 어느 서버로 가도 같은 세션을 읽습니다.

Health Check · HA · SPOF

LB는 주기적으로 서버 상태를 확인하고(Health Check), 죽은 서버로는 보내지 않습니다. 「지금 살아 있나」와 장기간 상태를 기록하는 서버 모니터링은 목적이 다릅니다. 서버를 여러 대 둬도 LB가 하나뿐이면 LB가 단일 장애점(SPOF)이 됩니다. 그래서 LB 자체를 이중화하고(고가용성, HA), 클라우드에서는 관리형 LB를 쓰는 경우가 많습니다.

리버스 프록시 · CDN · DNS

Nginx는 리버스 프록시이면서 upstream으로 간단 LB도 합니다. 리버스 프록시는 「대신 전달·TLS·경로」, LB는 「여러 서버 중 어디」에 초점이 있습니다. 한 장비가 둘을 겸하기도 합니다. 프록시 일반 개념과 구분해 두면 헷갈림이 줄어듭니다.

CDN은 지역 캐시·정적 배포, LB는 원본(오리진) 서버 풀 분배에 가깝습니다. DNS Round Robin은 IP를 여러 개 돌려 주지만, Health Check·즉시 제외는 전용 LB만큼 세밀하지 않은 경우가 많습니다.

L4와 L7

L4는 IP·포트·연결 단위로 빠르게 나눕니다(택배 상자를 통째로 분류). L7은 HTTP URL·헤더·호스트를 보고 나눕니다(상자 안 주문을 읽고 /api는 A풀, /shop은 B풀). 경로·도메인별 라우팅이 필요하면 L7이 유리합니다.

DB · 파일 · 오토스케일

웹 서버만 늘리고 DB 한 대에 모든 쓰기가 몰리면 DB가 병목입니다. 복제·읽기 분산은 가능하지만 쓰기·일관성은 설계가 필요합니다. 업로드 파일이 서버 로컬에만 있으면 Sticky나 공유 스토리지(S3 등)가 필요합니다.

Auto Scaling은 부하에 따라 서버 수를 자동으로 늘리고 줄입니다. LB+헬스체크와 함께 쓰입니다. 트래픽이 적은 사이트는 LB 없이도 충분한 경우가 많고, 비용·복잡도도 함께 봅니다. 먼저 쿼리·캐시·코드 병목을 줄인 뒤(최적화), 그래도 모자랄 때 수평 확장합니다.

502 · 503 · 504 · HTTPS · SEO

뒤 서버가 죽어 있으면 502, 일시적으로 받을 수 없으면 503, 응답이 너무 늦으면 504가 날 수 있습니다. 앱에는 LB IP만 보이므로 X-Forwarded-For로 실제 사용자를 넘깁니다(HTTP 헤더). HTTPS는 LB에서 TLS를 종료하는 구성이 흔합니다.

LB 자체는 검색 순위 요인이 아닙니다. 공개 URL·상태 코드·콘텐츠가 정상인지가 중요하고, 서버마다 배포 버전이 다르면 사용자·크롤러가 다른 화면을 볼 수 있어 배포를 맞춰야 합니다.


자주 묻는 질문

로드밸런싱이란?

요청을 여러 서버에 나눠 부하와 장애 위험을 줄이는 기술입니다.

리버스 프록시와 같나요?

겹치는 부분이 많지만, LB는 「어느 서버로」에 초점이 있습니다.

작은 사이트도 필요한가요?

필수는 아닙니다. 트래픽·가용성 요구가 커질 때 검토합니다.

Sticky는 필수인가요?

공유 세션이 있으면 필수는 아닙니다. 없으면 Sticky나 세션 재설계가 필요합니다.


정리

로드밸런싱 = 여러 계산대에 손님 나누기 · 사용자 → LB → 서버 A·B·C

알고리즘·세션·헬스체크·L4/L7·DB·파일을 함께 설계해야 「서버만 늘렸다」가 되지 않습니다. 부하가 들쭉날쭉하면 LB 뒤에서 서버 수를 자동으로 맞추는 오토스케일링(Auto Scaling)으로 이어지는 경우가 많습니다.