로드 밸런서 기초

로드 밸런서란?

여러 서버에 네트워크 트래픽을 효율적으로 분산시켜주는 프로세스나 장비.

로드 밸런서의 기본 동작

1. 클라이언트는 DNS 서버에 도메인 주소에 해당하는 서버 IP 를 요청한다.
2. DNS 서버는 실제 서버 IP 주소 대신에 로드 밸런서의 공개 IP 주소를 반환하다.
3. 클라이언트는 로드 밸런서의 공개 IP 로 HTTPS 등과 같은 요청을 보낸다.
4. 클라이언트와 로드 밸런서가 TCP(또는 UDP) 연결을 맺는다.
5. 정해진 라우팅 조건과 알고리즘에 따라서 서버 중에 하나를 선택한다.
6. 선택한 서버와 로드 밸런서가 TCP(또는 UDP) 연결을 맺는다.
7. 요청 패킷의 출발지 IP 주소를 로드 밸런서의 비공개 IP 주소로, 도착지 IP 주소를 서버 IP 주소로 바꾼다.
8. 서버에 요청 패킷을 전달한다.
9. 서버로부터 응답을 받으면, 응답 패킷의 출발지 IP 주소를 로드 밸런서의 공개 IP 주소로, 도착지 IP 주소를 클라이언트 IP 주소로 변경한다.
10. 클라이언트에게 응답 패킷을 전달한다.

리소스 절약을 위해서 로드 밸런서에서 인바운드 트래픽만 처리하고 아웃바운드 트래픽은 서버에서 직접 처리하도록 구성하기도 한다. (참고)

로드 밸런서 종류

로드 밸런서의 종류에는 L4 로드 밸런서와 L7 로드 밸런서가 있다.

L4 로드 밸런서

• 네트워크 OSI 모델의 4계층(전송 계층)에서 동작하는 로드 밸런서.
• TCP, UDP 와 같은 전송 계층 프로토콜 정보를 기반으로 트래픽을 분배한다.
  (전송 계층보다 상위 계층의 프로토콜 정보는 알지 못한다)
• 프로토콜 종류, IP 주소, 포트 번호를 라우팅 조건으로 사용할 수 있다.
• L7 로드 밸런서에 비해 제공하는 기능이 다양하지 않다.
• 하는 일이 단순한 만큼 성능이 뛰어나다.

L7 로드 밸런서

• 네트워크 OSI 모델의 7계층(애플리케이션 계층)에서 동작하는 로드 밸런서.
• 주로 HTTP/HTTPS 프로토콜 정보를 기반으로 트래픽을 분배한다.
• 프로토콜 종류, IP 주소, 포트 번호 뿐만 아니라 호스트 이름, URI 경로, 쿠키, 헤더 등 다양한 정보를 라우팅 조건으로 사용할 수 있다.
• SSL 종료, 리다이렉트, sticky 세션 등 L4 로드 밸런서에 비해 제공하는 기능이 다양하다.
• 하는 일이 복잡한 만큼 성능이 (비교적) 떨어진다.

로드 밸런서 선택 기준

L4 로드 밸런서

• 대규모 트래픽 분배가 필요한 경우.
• 고속 트래픽 분배가 필요한 경우.
• 비 HTTP 서비스(ex. MySQL, Redis) 트래픽 분배가 필요한 경우.

L7 로드 밸런서

• URI 경로, 호스트 이름, 헤더 등을 기반으로 세밀한 라우팅이 필요한 경우.
• SSL 종료, 쿠키 기반 세션 유지 등 HTTP 특화 기능이 필요한 경우.
• 마이크로서비스 아키텍처에서 API Gateway 역할이 필요한 경우.

로드 밸런싱 알고리즘

1. Round Robin (라운드 로빈)

동작 방식

서버 목록을 순회하면서 요청을 순서대로 분배함.

장점

• 각 서버의 성능이 비슷할 때 균등한 트래픽 분배 가능.
• 오버헤드가 거의 없어 빠른 처리 가능.

단점

• 서버 간의 성능 차이가 많이 날 때 비효율적임.
• 요청마다 처리 소요 시간이 다를 때 불균형 발생할 수 있음.
• 서버 별 부하 상태를 실시간으로 반영 못함.

적합한 경우

• 모든 서버의 성능이 동일한 경우
• 요청마다 처리 소요 시간이 비슷한 경우
• 단순하고 빠른 분배가 필요한 경우

2. Weighted Round Robin(가중치 기반 라운드 로빈)

동작 방식

각 서버에 가중치를 부여한 다음에 가중치에 비례하여 요청을 분배함.

장점

• 서버 간의 성능 차이를 고려한 트래픽 분배 가능.
• 오버헤드가 거의 없어 빠른 처리 가능.

단점

• 적절한 가중치 설정이 어려움.
• 요청마다 처리 소요 시간이 다를 때 불균형 발생 가능함.
• 서버 별 부하 상태를 실시간 반영 못함.

적합한 경우

• 서버 간의 성능 차이가 많이 나는 경우
• 특정 서버에 더 많은 트래픽을 보내고 싶은 경우

3. IP Hash (IP 해시)

작동 방식

클라이언트 IP 주소를 해싱하여 특정 서버로 분배함.

장점

• 같은 클라이언트는 항상 같은 서버로 연결되면서 세션 유지가 자동으로 됨.

단점

• 트래픽 분배가 불균등할 수 있음.
• 서버 추가/제거 시 세션 재분배 문제 발생함.
• 서버 성능 차이를 고려하지 못함.
• 특정 서버에 장애 발생시 해당 서버에 연결된 모든 클라이언트에 장애 발생.

적합한 경우

• 세션 유지가 필수인 서비스

4. Least Connection (최소 연결)

동작 방식

현재 활성 연결 수가 가장 적은 서버로 요청을 분배함.

장점

• 실시간 서버 부하 상태 반영 가능.
• 요청마다 처리 소요 시간이 다를 때 효과적임.

단점

• 신규 서버 추가시 활성 연결 수가 0인 신규 서버로 요청이 몰리는 현상이 있을 수 있음.
• 연결 수와 부하 정도가 정비례하지 않을 경우 비효율적일 수 있음.
• 활성 연결 수 추적을 위한 오버헤드 발생.

적합한 경우

• 요청 처리 시간이 다양한 경우
• 장시간 유지되는 연결이 있는 경우
• 실시간 부하 분산이 중요한 경우

5. Least Response Time (최소 응답 시간)

동작 방식

응답 시간과 활성 연결 수를 고려하여 가장 빠른 서버로 분배함.

장점

• 사용자 경험 최적화
• 실제 서버 성능을 실시간 반영
• 네트워크 지연까지 고려 가능함.

단점

• 응답 시간 측정을 위한 오버헤드 발생.

적합한 경우

• 응답 속도가 매우 중요한 서비스
• 지리적으로 분산된 서버 환경