로드 밸런싱 (Load Balancing)

목차

로드 밸런싱이란

로드 밸런싱(Load Balancing) 은 여러 서버나 인스턴스에 트래픽을 분산해 처리량과 가용성을 높이는 방식입니다.

핵심 목적은 다음과 같습니다.

  • 부하 분산: 특정 서버에 요청이 몰리지 않게 함
  • 가용성 향상: 일부 인스턴스가 죽어도 다른 인스턴스로 우회
  • 확장성 확보: 서버 수를 늘렸을 때 트래픽을 자연스럽게 배분
  • 운영 유연성: 배포, 교체, 점검을 백엔드 뒤에서 수행

로드 밸런서는 단순히 요청을 나눠주는 장비가 아니라,
트래픽 입구에서 성능과 장애 대응을 조정하는 제어 지점입니다.

왜 로드 밸런싱이 필요한가

서버가 1대뿐이면 다음 문제가 생깁니다.

  • 서버 하나가 과부하되면 전체 서비스가 느려짐
  • 배포나 점검 중 서비스 중단이 발생하기 쉬움
  • 장애 시 우회 경로가 없음

로드 밸런서를 두면 다음 구조가 가능합니다.

  1. 클라이언트는 하나의 진입점으로 요청
  2. 로드 밸런서가 살아 있는 백엔드로 요청 분산
  3. 트래픽이 늘면 백엔드를 수평 확장
  4. 특정 인스턴스가 비정상이면 자동 제외

그래서 로드 밸런싱은 성능 최적화뿐 아니라 고가용성 설계의 시작점이기도 합니다.
관련 주제는 고가용성 문서와 함께 설명하면 좋습니다.

L4와 L7 로드 밸런싱

로드 밸런서는 어느 계층 정보를 보고 분산하느냐에 따라 보통 L4와 L7으로 나눕니다.

항목 L4 로드 밸런싱 L7 로드 밸런싱
기준 IP, Port, TCP/UDP 수준 HTTP 헤더, 경로, 호스트, 쿠키 수준
장점 단순하고 빠름 정교한 라우팅 가능
단점 애플리케이션 수준 분기 한계 설정과 처리 비용이 더 큼
적합한 경우 단순 TCP 서비스, 낮은 오버헤드 필요 웹/API 서비스, 경로 기반 라우팅 필요

실무에서 자주 나오는 설명 포인트는 다음과 같습니다.

  • L4: 네트워크 수준에서 빠르게 분산
  • L7: /api, /static, Host 헤더, 쿠키 같은 애플리케이션 정보를 활용해 세밀하게 분산

예를 들어:

  • /images 는 정적 콘텐츠 백엔드로
  • /api 는 애플리케이션 서버로
  • 특정 Host 는 관리자 서비스로

이런 분기는 보통 L7에서 처리합니다.

대표 로드 밸런싱 알고리즘

트래픽을 어떻게 나눌지는 알고리즘에 따라 달라집니다.

알고리즘 설명 장점 주의점
Round Robin 순서대로 분배 단순하고 이해하기 쉬움 서버 성능 차이를 반영하기 어려움
Weighted Round Robin 가중치를 두고 분배 성능이 다른 서버를 반영 가능 가중치 관리 필요
Least Connections 연결 수가 적은 서버 우선 장기 연결이 많은 서비스에 유리 연결 수만으로 실제 부하를 완전히 설명하진 못함
Hash 기반 IP, 쿠키, 키 기준 고정 라우팅 세션 일관성 확보 가능 편향된 키 분포에 취약

면접에서는 “무슨 알고리즘을 쓰나요?”보다
왜 이 서비스에서 그 알고리즘이 맞는가를 설명해야 답변이 강합니다.

예를 들면:

  • 일반 웹 트래픽은 Round Robin으로 충분한 경우가 많음
  • WebSocket이나 장기 연결이 많으면 Least Connections가 더 자연스러울 수 있음
  • 캐시 지역성이나 세션 일관성이 필요하면 hash 기반 분산을 검토

알고리즘은 만능이 아니라 트래픽 특성과 상태 저장 방식에 맞춰 선택하는 도구입니다.1

헬스 체크와 장애 우회

로드 밸런서가 백엔드 상태를 모르면, 죽은 서버에도 계속 요청을 보낼 수 있습니다.
그래서 헬스 체크(Health Check) 는 거의 필수입니다.

헬스 체크에서 주로 보는 항목은 다음과 같습니다.

  • 프로토콜: TCP, HTTP, HTTPS, gRPC
  • 경로: /health, /ready
  • 간격과 타임아웃: 얼마나 자주 검사하고 얼마나 빨리 실패로 볼지
  • Healthy / Unhealthy Threshold: 몇 번 연속 성공/실패해야 상태를 바꿀지

헬스 체크 설계에서 중요한 점은 다음과 같습니다.

  • 너무 얕으면: 프로세스만 살아 있고 실제 서비스는 죽었는데 통과할 수 있습니다.
  • 너무 깊으면: DB나 외부 API까지 모두 확인하다가 정상 서버도 쉽게 제외될 수 있습니다.
  • 타임아웃이 너무 짧으면: 일시적 지연에도 서버가 과하게 제외될 수 있습니다.

클라우드 환경에서도 헬스 체크는 로드 밸런싱의 핵심 구성 요소입니다.2

또한 장애 우회는 단순히 인스턴스를 빼는 문제로 끝나지 않습니다.

  • 연결 드레이닝(Connection Draining): 이미 처리 중인 요청을 갑자기 끊지 않기
  • 오토스케일과 연동: 새 인스턴스가 준비되기 전에는 트래픽을 받지 않기
  • 다중 리전 우회: 리전 단위 장애 시 다른 리전으로 트래픽 전환3

세션 관리와 고정 세션

상태를 서버 메모리에 저장하는 구조에서는 사용자가 매번 다른 서버로 가면 문제가 생길 수 있습니다.

이때 자주 나오는 개념이 고정 세션(Sticky Session) 입니다.

  • 장점: 같은 사용자를 같은 서버로 보내 세션 일관성을 쉽게 유지
  • 단점: 특정 서버에 사용자가 몰릴 수 있고, 서버 장애 시 세션이 깨질 수 있음

그래서 가능하면 다음 구조를 더 선호합니다.

  • 무상태 (Stateless) 애플리케이션
  • 세션 저장소 분리: Redis, 데이터베이스, 외부 세션 저장소
  • 토큰 기반 인증: 서버 메모리 의존도 축소

즉, sticky session은 쓸 수는 있지만,
보통은 상태를 애플리케이션 인스턴스 밖으로 빼는 방향이 더 확장에 유리합니다.

로드 밸런서와 주변 컴포넌트의 역할 차이

면접에서는 로드 밸런서, 리버스 프록시, CDN, API Gateway를 구분해서 설명하는 편이 좋습니다.

구성 요소 주 역할 대표 질문
로드 밸런서 트래픽 분산, 헬스 체크, 장애 우회 어떤 백엔드로 보낼 것인가
리버스 프록시 요청 중계, TLS 종료, 캐시, 라우팅 앞단에서 무엇을 대리 처리할 것인가
CDN 정적 콘텐츠를 사용자와 가까운 곳에서 제공 지연 시간을 어떻게 줄일 것인가
API Gateway 인증, 라우팅, 레이트 리밋, 정책 집행 여러 API를 어떻게 통합 진입시킬 것인가

현실에서는 한 제품이 여러 역할을 같이 할 수 있습니다.
그래도 면접에서는 핵심 책임 기준으로 구분해서 설명하는 편이 깔끔합니다.

로드 밸런싱의 트레이드오프

  • 장점: 확장성과 가용성을 높이고, 배포와 점검을 유연하게 할 수 있습니다.
  • 단점: 추가 홉이 생기고, 설정 복잡도와 운영 포인트가 늘어납니다.
  • 주의점: 로드 밸런서 자체가 SPOF가 되지 않도록 이중화와 관리형 구성을 함께 고려해야 합니다.

또한 모든 문제를 로드 밸런서로 해결할 수는 없습니다.

  • 백엔드가 느리면 트래픽 분산만으로는 해결되지 않습니다.
  • 상태 저장 구조가 잘못되면 분산 후에도 불균형이 생깁니다.
  • 데이터 계층이 병목이면 애플리케이션 서버만 늘려도 효과가 제한적입니다.

즉, 로드 밸런싱은 중요한 출발점이지만 전체 시스템 병목 중 하나만 해결하는 수단일 뿐입니다.

면접 포인트

  • 로드 밸런싱의 목적은 단순 분산이 아니라 확장성과 가용성 확보입니다.
  • L4와 L7은 속도 대 정교한 라우팅이라는 차이로 설명하면 좋습니다.
  • 헬스 체크 없이 분산만 하는 구조는 장애 대응이 약합니다.
  • sticky session은 쉬운 해법이지만, 장기적으로는 무상태 구조와 외부 세션 저장소가 더 유리합니다.
  • 로드 밸런서는 성능 장치이면서 장애 격리와 배포 유연성을 만드는 운영 장치이기도 합니다.

참고 자료

  1. Google Cloud Docs, “Advanced load balancing optimizations” ↩

  2. Google Cloud Docs, “Use health checks” ↩

  3. Amazon Route 53 Docs, “Creating Amazon Route 53 health checks” ↩