로드 밸런싱이란 무엇인가?
웹사이트나 온라인 서비스의 이용자가 많아지면 하나의 서버만으로 모든 요청을 처리하기 어려워질 수 있습니다.
예를 들어 쇼핑몰에 갑자기 많은 사용자가 접속하면 하나의 서버에 요청이 집중되면서 웹페이지 응답이 느려지거나 서버가 과부하 상태에 빠질 수 있습니다.
이러한 문제를 해결하기 위해 여러 대의 서버를 준비하고 사용자 요청을 적절하게 나누어 전달하는 기술이 로드 밸런싱(Load Balancing)입니다.
로드 밸런싱은 말 그대로 서버에 발생하는 부하(Load)를 여러 서버에 분산(Balancing)하는 기술입니다.
이때 사용자 요청을 받아 여러 서버로 분배하는 장치를 로드 밸런서(Load Balancer)라고 합니다.
기본적인 구조는 다음과 같습니다.
사용자
↓
로드 밸런서
↓
┌──────┬──────┬──────┐
↓ ↓ ↓
서버 1 서버 2 서버 3사용자가 접속하면 로드 밸런서가 요청을 적절한 서버로 전달합니다.
로드 밸런싱이 필요한 이유
하나의 서버만 사용하는 환경에서는 모든 사용자의 요청이 해당 서버에 집중됩니다.
사용자가 적을 때는 큰 문제가 없지만 서비스 규모가 커지면 서버에 부하가 증가합니다.
예를 들어 다음과 같은 상황을 생각해 볼 수 있습니다.
사용자 1 ─┐
사용자 2 ─┤
사용자 3 ─┤
사용자 4 ─┼→ 서버 1
사용자 5 ─┤
사용자 6 ─┘많은 요청이 하나의 서버에 집중되면 CPU와 메모리, 네트워크 등의 자원이 빠르게 사용될 수 있습니다.
반면 여러 서버를 사용하면 요청을 나누어 처리할 수 있습니다.
로드 밸런서
↓
┌────────┼────────┐
↓ ↓ ↓
서버 1 서버 2 서버 3이렇게 하면 특정 서버에 부하가 집중되는 것을 줄일 수 있습니다.
로드 밸런서는 어떤 역할을 할까?
로드 밸런서는 사용자와 서버 사이에서 동작합니다.
사용자가 웹사이트에 접속하면 요청이 먼저 로드 밸런서로 전달됩니다.
로드 밸런서는 현재 서버의 상태나 설정된 분배 정책 등을 기준으로 어떤 서버에 요청을 전달할지 결정합니다.
사용자 요청
↓
로드 밸런서
↓
서버 상태 및 분배 정책 확인
↓
적절한 서버 선택
↓
서버 2서버에서 응답이 돌아오면 로드 밸런서를 거쳐 사용자에게 전달됩니다.
로드 밸런싱의 대표적인 방식
로드 밸런서는 여러 가지 방법으로 트래픽을 분산할 수 있습니다.
대표적으로 다음과 같은 방식이 있습니다.
- 라운드 로빈
- 가중치 기반 분배
- 최소 연결 방식
- IP 해시 방식
각 방식은 서버 환경과 서비스 특성에 따라 다르게 사용할 수 있습니다.
라운드 로빈 방식이란?
라운드 로빈(Round Robin)은 가장 기본적인 로드 밸런싱 방식 중 하나입니다.
서버에 요청을 순서대로 전달하는 방식입니다.
예를 들어 서버가 3대 있다면 다음과 같이 요청을 분배할 수 있습니다.
요청 1 → 서버 1
요청 2 → 서버 2
요청 3 → 서버 3
요청 4 → 서버 1
요청 5 → 서버 2
요청 6 → 서버 3각 서버에 순서대로 요청을 전달하기 때문에 구현이 비교적 단순합니다.
다만 서버마다 처리 능력이 다르거나 요청마다 필요한 자원이 크게 다르면 단순한 라운드 로빈 방식만으로는 효율적인 분산이 어려울 수 있습니다.
가중치 기반 로드 밸런싱
서버마다 성능이 다른 경우에는 가중치(Weight)를 설정할 수 있습니다.
예를 들어 서버 1의 성능이 다른 서버보다 두 배 정도 높다면 더 많은 요청을 처리하도록 설정할 수 있습니다.
서버 1 → 가중치 2
서버 2 → 가중치 1
서버 3 → 가중치 1이 경우 서버 1에 상대적으로 많은 요청을 전달할 수 있습니다.
서버의 CPU, 메모리, 네트워크 성능 등이 서로 다른 환경에서 활용할 수 있는 방식입니다.
최소 연결 방식이란?
최소 연결(Least Connections) 방식은 현재 연결된 사용자 수가 가장 적은 서버에 새로운 요청을 전달하는 방식입니다.
예를 들어 현재 연결 상태가 다음과 같다고 가정해 보겠습니다.
서버 1 → 연결 50개
서버 2 → 연결 20개
서버 3 → 연결 35개새로운 사용자가 접속하면 연결 수가 가장 적은 서버 2로 요청을 전달할 수 있습니다.
이 방식은 각 요청이 서버에 유지되는 시간이 서로 다를 때 유용할 수 있습니다.
IP 해시 방식이란?
IP Hash 방식은 사용자의 IP 주소 등을 기준으로 특정 서버를 선택하는 방식입니다.
예를 들어 특정 사용자의 IP 주소를 기준으로 계산한 결과에 따라 항상 같은 서버로 연결되도록 구성할 수 있습니다.
사용자 A → 서버 1
사용자 B → 서버 2
사용자 C → 서버 3이 방식은 특정 사용자의 요청을 가능한 한 동일한 서버로 연결해야 하는 환경에서 활용할 수 있습니다.
다만 서버 장애나 구성 변경이 발생하면 연결 대상이 달라질 수 있습니다.
헬스 체크란 무엇인가?
로드 밸런싱에서 중요한 기능 중 하나가 헬스 체크(Health Check)입니다.
로드 밸런서는 서버가 정상적으로 동작하고 있는지 확인할 필요가 있습니다.
예를 들어 서버 3에 장애가 발생했다고 가정해 보겠습니다.
서버 1 → 정상
서버 2 → 정상
서버 3 → 장애로드 밸런서가 서버 상태를 확인하지 않는다면 장애가 발생한 서버에도 계속 요청을 전달할 수 있습니다.
반면 헬스 체크를 사용하면 서버 3의 장애를 확인한 후 해당 서버로 새로운 요청을 전달하지 않도록 설정할 수 있습니다.
로드 밸런서
↓
┌────────┼────────┐
↓ ↓ ↓
서버 1 서버 2 서버 3
정상 정상 장애
↑ ↑
요청 요청이 기능은 서비스의 안정성을 높이는 데 중요한 역할을 합니다.
로드 밸런싱과 서버 확장
로드 밸런싱은 서버를 여러 대로 늘리는 구조와 함께 사용되는 경우가 많습니다.
사용자가 증가하면 서버를 추가하여 처리 능력을 높일 수 있습니다.
이를 수평적 확장(Scale Out)이라고 합니다.
기존
로드 밸런서
↓
서버 1
서버 추가
로드 밸런서
↓
┌────┼────┐
↓ ↓ ↓
서버 1 서버 2 서버 3이처럼 서버를 추가하고 로드 밸런서가 트래픽을 분산하면 증가한 사용자 요청에 대응할 수 있습니다.
스케일 업과 스케일 아웃의 차이
서버의 처리 능력을 높이는 방법은 크게 두 가지로 생각할 수 있습니다.
스케일 업(Scale Up)은 하나의 서버 성능을 높이는 방식입니다.
예를 들어 CPU나 메모리를 더 높은 사양으로 교체할 수 있습니다.
반면 스케일 아웃(Scale Out)은 서버의 개수를 늘리는 방식입니다.
스케일 업
서버 1
↓
더 높은 CPU와 메모리
↓
서버 성능 증가
스케일 아웃
서버 1 ─┐
서버 2 ─┼→ 처리 능력 증가
서버 3 ─┘로드 밸런싱은 특히 스케일 아웃 환경에서 중요한 역할을 합니다.
로드 밸런싱과 고가용성
로드 밸런싱은 고가용성(High Availability)을 구성하는 데도 활용됩니다.
서버 한 대에 장애가 발생하더라도 다른 서버가 정상적으로 동작하고 있다면 서비스 요청을 계속 처리할 수 있기 때문입니다.
예를 들어 서버 3에 장애가 발생하더라도 서버 1과 서버 2가 정상적으로 동작한다면 로드 밸런서는 정상 서버로 요청을 전달할 수 있습니다.
사용자
↓
로드 밸런서
↓
┌──────┬──────┬──────┐
↓ ↓ ↓
정상 정상 장애
서버 1 서버 2 서버 3따라서 로드 밸런싱은 단순한 트래픽 분산뿐만 아니라 서비스의 안정성을 높이는 데도 활용됩니다.
L4 로드 밸런싱이란?
로드 밸런서는 네트워크의 어느 계층에서 트래픽을 처리하느냐에 따라 구분할 수 있습니다.
대표적으로 L4 로드 밸런싱과 L7 로드 밸런싱이 있습니다.
L4 로드 밸런싱은 OSI 7계층 기준으로 전송 계층 정보를 기반으로 트래픽을 분산합니다.
대표적으로 TCP와 UDP의 IP 주소 및 포트 번호 등의 정보를 활용할 수 있습니다.
IP 주소
포트 번호
TCP / UDPL4 로드 밸런싱은 비교적 빠르게 트래픽을 처리할 수 있다는 장점이 있습니다.
L7 로드 밸런싱이란?
L7 로드 밸런싱은 애플리케이션 계층의 정보를 이용해 트래픽을 분산합니다.
예를 들어 HTTP 요청의 URL이나 HTTP 헤더 등의 정보를 기준으로 서버를 선택할 수 있습니다.
사용자
↓
L7 로드 밸런서
↓
/api → API 서버
/images → 이미지 서버
/web → 웹 서버따라서 L7 로드 밸런싱은 요청의 내용을 더 세밀하게 확인하여 트래픽을 분산할 수 있습니다.
L4와 L7 로드 밸런싱의 차이
두 방식을 간단하게 비교하면 다음과 같습니다.
L4
→ IP 주소, 포트, TCP/UDP 등을 기준으로 분산
L7
→ HTTP URL, 헤더 등 애플리케이션 정보를 기준으로 분산L4는 네트워크와 전송 계층 수준에서 빠르게 트래픽을 처리하는 데 적합하고, L7은 요청 내용을 기준으로 보다 세밀한 분산 정책을 적용할 수 있습니다.
실제 서비스에서는 환경과 요구사항에 따라 적절한 방식을 선택합니다.
로드 밸런싱의 장점
로드 밸런싱을 사용하면 여러 가지 장점이 있습니다.
첫째, 여러 서버에 트래픽을 분산하여 특정 서버의 과부하를 줄일 수 있습니다.
둘째, 서버를 추가하여 서비스 처리 능력을 확장하기 쉽습니다.
셋째, 일부 서버에 장애가 발생하더라도 정상적인 서버로 요청을 전달할 수 있습니다.
넷째, 대규모 사용자가 접속하는 서비스의 안정적인 운영에 도움이 됩니다.
다섯째, 서버의 상태를 확인하면서 트래픽을 적절하게 분배할 수 있습니다.
로드 밸런싱의 단점
로드 밸런싱에도 고려해야 할 부분이 있습니다.
먼저 로드 밸런서 자체에 장애가 발생하면 여러 서버가 정상적으로 동작하고 있어도 서비스에 문제가 발생할 수 있습니다.
따라서 중요한 서비스에서는 로드 밸런서 자체도 이중화하는 구성을 고려할 수 있습니다.
또한 서버가 여러 대로 늘어나면서 네트워크 구조와 운영 환경이 복잡해질 수 있습니다.
세션 관리나 데이터 동기화 같은 문제도 함께 고려해야 합니다.
로드 밸런싱과 세션 문제
웹 서비스에서 로드 밸런싱을 사용할 때 자주 고려하는 것이 세션(Session)입니다.
사용자가 로그인한 상태에서 여러 서버를 사용한다면 로그인 정보를 어느 서버에서 관리할 것인지 문제가 발생할 수 있습니다.
예를 들어 다음과 같은 상황을 생각해 볼 수 있습니다.
첫 번째 요청 → 서버 1
로그인 정보 → 서버 1
두 번째 요청 → 서버 2
로그인 정보 확인 필요서버 1에만 세션 정보가 저장되어 있다면 서버 2에서는 사용자의 로그인 상태를 확인하지 못할 수 있습니다.
이 문제를 해결하기 위해 세션을 외부 저장소에 저장하거나 별도의 세션 관리 방식을 사용하는 등 다양한 방법을 적용할 수 있습니다.
로드 밸런싱을 쉽게 이해하는 방법
로드 밸런싱은 식당의 안내 직원과 비슷하게 생각하면 쉽습니다.
손님이 한꺼번에 몰렸는데 계산대가 하나뿐이라면 대기 줄이 길어질 수 있습니다.
하지만 계산대를 여러 개 만들고 안내 직원이 손님을 적절하게 나누어 준다면 전체적인 처리 속도를 높일 수 있습니다.
네트워크에서도 비슷한 구조가 만들어집니다.
로드 밸런서
↓
┌────────┼────────┐
↓ ↓ ↓
서버 1 서버 2 서버 3로드 밸런서는 들어오는 요청을 확인하고 여러 서버에 적절하게 나누어 전달하는 역할을 합니다.
결론
로드 밸런싱(Load Balancing)은 네트워크 트래픽을 여러 서버에 분산하여 특정 서버에 부하가 집중되는 것을 줄이는 기술입니다.
사용자가 증가하면 하나의 서버만으로 모든 요청을 처리하기 어려워질 수 있기 때문에 여러 서버를 구성하고 로드 밸런서를 통해 요청을 적절하게 분산할 수 있습니다.
로드 밸런싱 방식에는 라운드 로빈, 가중치 기반 분배, 최소 연결, IP 해시 등이 있으며 서비스의 특성에 따라 적절한 방식을 선택할 수 있습니다.
또한 헬스 체크를 이용하면 장애가 발생한 서버를 확인하고 정상적인 서버로 요청을 전달할 수 있습니다.
로드 밸런싱은 서버를 여러 대로 확장하는 스케일 아웃 환경과 함께 사용되는 경우가 많으며, 대규모 웹 서비스의 성능과 안정성을 높이는 데 중요한 역할을 합니다.
결국 로드 밸런싱은 많은 사용자의 요청을 여러 서버에 효율적으로 나누어 서비스의 성능과 안정성을 유지하는 핵심 네트워크 기술이라고 정리할 수 있습니다.