왜 로드밸런서가 필요한가
서버 한 대가 처리할 수 있는 요청 수에는 한계가 있다. 트래픽이 늘어나면 서버를 여러 대로 늘려야 하는데, 이때 문제가 생긴다. 클라이언트가 어떤 서버로 요청을 보내야 할지 어떻게 결정하는가. 특정 서버에만 요청이 몰리면 그 서버는 과부하로 다운되고, 나머지 서버는 놀게 된다. 로드밸런서(Load Balancer)는 이 문제를 해결하는 장치다. 들어오는 요청을 여러 서버에 균등하게 분배하여 각 서버의 부하를 적정 수준으로 유지한다.
L4 로드밸런서와 L7 로드밸런서
로드밸런서는 동작하는 네트워크 계층에 따라 L4와 L7로 나뉜다. L4 로드밸런서는 전송 계층(TCP/UDP)에서 동작한다. 패킷의 출발지 IP, 목적지 IP, 포트 번호만 보고 분배 대상 서버를 결정한다. 패킷 내부의 데이터 내용은 검사하지 않으므로 처리 속도가 빠르다. L7 로드밸런서는 애플리케이션 계층(HTTP)에서 동작한다. URL 경로, HTTP 헤더, 쿠키, 호스트 이름 등 요청의 내용을 분석하여 분배 규칙을 세밀하게 설정할 수 있다. 이미지 요청은 이미지 전용 서버로, API 요청은 API 서버로 보내는 식의 콘텐츠 기반 라우팅이 가능하다.
분배 알고리즘
라운드 로빈(Round Robin)은 가장 단순한 방식으로 서버 목록을 순서대로 돌아가며 요청을 배정한다. 모든 서버의 성능이 동일할 때 효과적이다. 가중 라운드 로빈(Weighted Round Robin)은 서버별 성능 차이에 가중치를 부여하여 성능이 높은 서버에 더 많은 요청을 배정한다. 최소 연결(Least Connection) 방식은 현재 활성 연결 수가 가장 적은 서버에 새 요청을 보낸다. 요청 처리 시간이 들쑥날쑥한 환경에서 유리하다. IP 해시(IP Hash) 방식은 클라이언트 IP를 해싱하여 항상 같은 서버로 연결하므로 세션 유지가 필요한 서비스에 적합하다.
헬스체크
로드밸런서의 핵심 기능 중 하나가 헬스체크(Health Check)다. 백엔드 서버들에 주기적으로 상태 확인 요청을 보내 정상 응답이 돌아오는지 확인한다. 응답이 없거나 에러 코드를 반환하는 서버는 분배 대상에서 자동으로 제외하고, 복구되면 다시 포함시킨다. 이 자동 장애 탐지와 제거 기능이 서비스의 가용성을 보장하는 핵심 메커니즘이다.
하드웨어와 소프트웨어 로드밸런서
전통적으로 F5 BIG-IP, Citrix ADC 같은 전용 하드웨어 장비가 대규모 트래픽 환경에서 사용되었다. 높은 성능과 안정성을 제공하지만 가격이 수천만 원에서 수억 원대다. 소프트웨어 로드밸런서로는 Nginx, HAProxy가 대표적이며, 오픈소스로 무료 사용이 가능하다. 클라우드 환경에서는 AWS ALB/NLB, GCP Cloud Load Balancing 같은 매니지드 서비스가 하드웨어 관리 부담 없이 로드밸런싱을 제공한다.
답글 남기기