로드 밸런싱(Load Balancing)
들어가며
현대의 대부분 웹 서비스는 인터넷을 기반으로 운영되고 있어요. 누구나 접속할 수 있고, 시간과 장소의 제약도 거의 없죠. 이처럼 접근성이 좋아진 덕분에 사용자 수가 폭발적으로 늘었고, 이에 따라 트래픽도 함께 증가했어요.
하지만 아무리 성능이 뛰어난 서버라도 감당할 수 있는 요청량에는 한계가 있어요. 특정 시간대나 이벤트 발생 시, 갑작스러운 트래픽 증가가 발생하면 한 대의 서버로는 감당이 안 되겠죠. 이 경우 서비스 지연이나 장애로 이어질 수 있습니다.
이런 상황을 해결하기 위한 핵심 기술이 바로 로드 밸런싱(load balancing) 이에요.
로드 밸런서란?
로드 밸런서는 말 그대로 서버에 걸리는 부하(Load)를 분산(Balancing) 해주는 장치 또는 기술이에요.
클라이언트와 서버풀(server pool: 여러 대의 서버로 구성된 그룹) 사이에 위치하며, 특정 서버에 트래픽이 몰리지 않도록 요청을 분산시켜요. 이렇게 하면 모든 서버가 효율적으로 작동할 수 있고, 전체 시스템의 안정성과 처리 속도가 개선됩니다.
즉, 로드 밸런서는 사용자 요청을 알아서 잘 나눠주는 트래픽 조율자 역할을 해요.
모든 서비스에 로드 밸런서가 필요한가요?
꼭 그런 것은 아닙니다.
서비스 초창기에는 사용자 수가 많지 않기 때문에, 서버 한 대로도 충분히 대응이 가능해요. 하지만 서비스가 성장하면서 이용자가 많아지고, 트래픽이 증가하게 되면 기존의 한 대 서버로는 감당이 어려워지게 됩니다.
서버 확장의 두 가지 방식
트래픽이 늘어나고 기존 서버가 한계에 도달했을 때, 시스템 확장을 고려해야 해요.
이때 선택지는 크게 두 가지입니다:
- 하나를 더 좋게 만든다 (Scale-up)
- 여러 개로 나눠서 처리한다 (Scale-out)
두 방식 모두 시스템의 처리 능력을 높이기 위한 방법이지만, 접근 방식이 전혀 달라요.
두 번째 방법을 선택할 경우, 각 서버에 트
래픽을 고르게 분산하기 위해 반드시 로드 밸런서가 필요해요.
Scale-up: 서버 자체를 강화하는 방식
“더 좋은 부품을 달아서 서버 한 대를 강화한다.”
서버 한 대의 성능을 극한까지 끌어올리는 방식입니다
- CPU, RAM, 디스크를 업그레이드하거나
- 클라우드에서는 인스턴스 타입을 상위 등급으로 올려요.
- 예시: i3 CPU 서버 → i7 CPU 서버로 업그레이드
장점
- 구조가 단순해요. 서버가 1대니까, 관리도 쉬워요.
- 데이터 일관성 걱정도 거의 없어요. 나눌 게 없으니까요.
- 확장 방식이 직관적이고 비교적 빠릅니다.
- 소규모 서비스에선 빠르고 효과적일 수 있어요.
단점
- 하드웨어 성능 향상에는 한계가 있어요. (더 이상 업그레이드 못할 수도 있음)
- 서버 한 대에 모든 트래픽이 집중되기 때문에 장애 시 전체 서비스가 중단될 수 있어요.
- 비용이 비쌀 수 있습니다. (하이엔드 서버는 가격이 급격히 증가함)
Scale-out: 서버를 여러 대로 나누는 방식
“같은 사양의 서버를 여러 대 두고 나눠서 처리한다.”
같은 역할을 하는 서버를 여러 대 두고, 각각이 요청을 나눠서 처리하는 방식이에요.
- 서버를 추가해서 부하를 분산시키는 방식이에요.
- 클라우드 환경에서는 Auto Scaling으로 트래픽에 따라 서버 수를 자동으로 조절할 수도 있어요.
- 예시: i3 CPU 서버를 여러 대 두고, 트래픽을 나눠 처리
장점
- 유연한 확장성이 있어요. 필요할 때마다 서버를 추가하면 됩니다.
- 서버 하나가 다운되어도 전체 서비스가 멈추지 않아요. → 장애에 강한 구조
- 비용 효율적인 경우가 많습니다. 고성능 서버보다 저사양 서버 여러 대가 저렴할 수 있어요.
단점
- 여러 서버를 다루는 구조이기 때문에, 복잡한 아키텍처 이해가 필요해요.
- 데이터 일관성 문제가 생길 수 있어요. (동시성 문제, 복제 지연 등)
- 서버 간 부하를 고르게 분산하려면 로드 밸런서가 필수입니다.
로드 밸런싱 알고리즘
로드 밸런싱은 단순히 "나눠주는 것"이 아니라, 어떻게 나눌 것인가에 따라 성능과 안정성에 큰 차이가 발생할 수 있어요.
상황에 맞는 분산 전략을 선택하는 것이 매우 중요합니다.
라운드로빈 방식 (Round Robin)
"들어온 순서대로, 돌아가면서 나눠준다."
- 가장 기본적인 로드 밸런싱 방식
- 각 서버에 클라이언트 요청을 순서대로 할당합니다.
- 예: 고객이 10명이고 창구가 3개면, 1번 → 창구 A, 2번 → B, 3번 → C, 4번 → 다시 A…
언제 사용하나요?
- 서버의 성능이 균일하고
- 요청 처리 시간도 큰 차이 없는 서비스
장점
- 구현이 쉽고 빠릅니다.
- 서버 스펙이 균일할 때 효율적으로 작동해요.
단점
- 서버 상태를 고려하지 않기 때문에 과부하가 발생할 수 있어요.
- → 어떤 서버가 바쁘더라도 그냥 돌아가며 보냅니다.
가중 라운드로빈 방식 (Weighted Round Robin)
"스펙 좋은 서버에 더 많은 요청을 보내준다."
- 서버마다 가중치를 부여하고, 가중치에 따라 요청을 분배합니다.
- 예: A 서버(가중치 3), B 서버(가중치 1) → A: 3개, B: 1개 요청 처리
언제 사용하나요?
- 서버마다 사양이 다를 때
- 단순 로직이지만 어느 정도의 서버 분배 조절이 필요한 서비스
장점
- 라운드로빈보다 훨씬 현실적인 분배 가능 → 자원의 효율성 높음
- 비대칭 서버 환경에서 적절하게 분배 가능
단점
- 서버 상태(응답 속도, 연결 수 등)를 동적으로 반영하지 않음
- → “성능 좋은 서버가 현재 과부화 상태”인지 파악 불가
IP 해시 방식 (IP Hash)
"같은 클라이언트는 항상 같은 서버로 연결된다."
- 사용자의 IP 주소를 해시 처리해 특정 서버에 고정 배정 → 매번 같은 서버로 요청이 가기 때문에 세션 유지가 쉬워요.
언제 사용하나요?
- 서버에 세션 데이터를 저장하고 있는 경우
- 세션 클러스터링이 안 되어 있어서, 한 유저는 항상 같은 서버로 가야 하는 경우
장점
- 사용자 경험이 일관됩니다 (예: 로그인 유지 등).
- 간단하게 구현 가능한 세션 고정 효과 낼 수 있음
단점
- 특정 IP 대역에 트래픽이 몰리면 편향 발생
- 사용자 수가 많거나, IP 변경이 자주 일어나는 환경엔 부적합.
최소 연결 방식 (Least Connection)
"현재 연결이 가장 적은 서버에 요청을 보낸다."
- 실시간으로 연결 수를 모니터링해 가장 여유 있는 서버에 요청을 전달합니다.
언제 사용하나요?
- 요청의 처리 시간이 들쭉날쭉한 서비스
- WebSocket, 실시간 스트리밍처럼 연결 유지 시간이 긴 서비스
장점
- 실시간 상황을 고려하니 더 스마트한 분배 가능
- 과부하 서버를 피할 수 있음
단점
- 연결 상태를 추적해야 하므로, 시스템 부담 증가
- 연결 수만 볼 뿐, 응답 속도까지는 고려하지 않음
최소 응답시간 방식 (Least Response Time)
"연결 수도 적고 응답 속도도 빠른 서버에 보내준다."
- 연결 수 + 응답 속도를 모두 고려해서 "제일 여유 있는 서버"를 찾습니다.
언제 사용하나요?
- 사용자 체감 속도가 중요한 서비스 (예: 실시간 서비스, 게임 서버 등)
- 서버별 상태가 계속 달라지는 동적 트래픽 환경
장점
- 사용자에게 빠른 응답을 제공할 수 있어요.
- 리얼타임 상태 기반의 가장 ‘효율적인’ 분배가 가능
단점
- 시스템 리소스를 더 많이 소모함 (모니터링 + 판단)
상황별 로드 밸런싱 추천 요약
- 모든 서버가 비슷하고 요청도 가벼움 → 라운드로빈
- 서버 성능이 다르다면 → 가중 라운드로빈
- 세션 유지가 필요하다면 → IP 해시
- 연결 수가 중요한 실시간 서비스 → 최소 연결 방식
- 응답 속도까지 중요한 경우 → 최소 응답시간 방식
L4 vs L7 로드 밸런싱 – 계층에 따른 전략 차이
트래픽을 서버에 나눠주는 게 로드 밸런싱이지만,
"무엇을 기준으로 나눌까?"에 따라 그 방식은 달라져요.
바로 이 기준이 되는 것이 OSI 7계층 중 어디를 보느냐예요.
실무에선 보통 L4 (전송 계층) 또는 L7 (애플리케이션 계층) 기준으로 트래픽을 분산합니다.
L4 로드 밸런싱 (Transport Layer 기반)
“IP와 포트 정보를 기준으로 트래픽을 분산합니다.”
L4 (Transport Layer) 는 TCP, UDP 같은 전송 계층에서 작동해요.
특징
- 클라이언트 IP, 포트 번호, TCP/UDP 등의 헤더 정보만 보고 분산
- 라운드 로빈, 해시, 최소 연결 등 다양한 전략 사용 가능
- 내용은 보지 않기에 빠르고 단순
언제 사용하나?
- 모든 요청이 유사하게 처리될 때
- 서비스 의미 분석이 불필요할 때
- TCP 기반 서비스, 포트 기반 서버 운영 시 (ex. 8080, 8081 등)
L7 로드 밸런싱 (Application Layer 기반)
“요청 내용을 해석해 트래픽을 분산합니다.”
L7 (Application Layer) 는 HTTP, FTP 등 애플리케이션 계층에서 작동해요.
특징
- URL, 쿠키, 헤더, 토큰 등 요청의 의미까지 파악 가능
- 조건에 따라 요청을 세부적으로 분기 가능
- SSL 종료, 인증 검사 등 고급 기능 수행 가능
→ 말 그대로 “이 사람이 어떤 요청을 했는지” 보고 판단하는 구조입니다.
언제 사용하나?
- 경로 기반 라우팅할 때 (/api, /static)
- 인증 상태나 헤더 정보에 따라 분기해야 할 때
- 보안 검사나 로깅이 필요한 웹 트래픽 처리 시
| 구분 | L4 로드 밸런싱 | L7 로드 밸런싱 |
| 기준 계층 | 전송 계층 (TCP/UDP) | 애플리케이션 계층 (HTTP/HTTPS 등) |
| 분산 기준 | IP 주소, 포트, 프로토콜 | URL, 쿠키, 헤더, 본문, 인증 정보 등 |
| 분석 정보 | 패킷 헤더만 확인 | 요청 내용까지 분석 |
| 분기 조건 설정 | 불가능 (정적인 방식) | 가능 (동적 라우팅, 조건 분기 등) |
| 성능 | 빠르고 가벼움 | 상대적으로 느리지만 정밀함 |
| 사용 예시 | 게임 서버, 내부 TCP 서비스 | 웹 서버, API Gateway, 마이크로서비스 라우팅 |
출처