Load Balancing 이란?

 

 

LB (Load Balancing)

기본 네트워크 흐름은 클라이언트와 하나의 서버가 다이렉트로 연결되어 있는 구조이다.

 

하지만 해당 애플리케이션이 인기가 많아져 트래픽이 많이 발생하면 서버를 분산시킨다.

이렇게 분산된 서버에 클라이언트를 적절히 분배시켜주는 것이 LB이다.

ex) web - LB - was2 - DB : 여러 was 사용 시 LB를 통해 하나의 was에 클라이언트가 몰리지 않게 해줌

 

AWS에서 제공하는 ELB (Elastic Load Balancing)는 세가지 유형으로 나뉜다.

Application Load Balancer (ALB): HTTP 및 HTTPS 트래픽을 위해 최적화되었으며, 고급 라우팅 기능을 제공하여 요청을 특정 리소스에 전달
Network Load Balancer (NLB): TCP, UDP, TLS 트래픽에 최적화되어 있으며, 초저지연 및 매우 높은 처리량을 제공
Classic Load Balancer (CLB): 이전 버전의 ELB로, 간단한 로드 밸런싱 기능을 제공(CLB는 점점 ALB와 NLB로 대체되고 있음)

 

 

로드 밸런서의 역할

• 네트워크 트래픽 또는 클라이언트의 요청을 여러 서버에 적절하게 분배한다. (특정 서버의 부하를 덜어줌)
• Active한 서버에게만 요청을 전송한다. (서버가 다운되면 리다이렉션 -> 높은 가용성과 신뢰성을 보장)
• 서비스 중단없이 서버를 추가하거나 뺄 수 있게 해준다. (유연성 제공)

 

 

 

LB 작동 원리

해싱을 사용하여 분배시킴

h() : 해싱
rm: m의 숫자를 가진 request (r4)
m% n: 해싱 알고리즘 (n은 서버 개수)
server: 매칭 되는 서버

ex) 서버 4대, r10의 요청

해당 요청을 해싱하면 10 % 4  = 2의 값이 나온다. 그렇기 때문에 해당 요청은 server2로 매칭 될 것이다.

 

만약 서버의 개수가 늘어나면 어떻게 될까?

기존의 request ID가 매칭 되는 서버는 변경될 것이고 이건 큰 문제를 이야기한다.

 

왜냐하면 기존에 특정 requestID와 특정 Server가 매칭 된다면 우리는 해당 서버에 Cache 하여 Cache데이터를 사용할 수 있다.

만약 Request ID와 요청되는 Server가 변해 버린다면 이건 다 무용지물이 될 것이고 해당 Cache는 Dummy데이터가 되어 버릴 것이다.

 

 

 

해결책

Consistent Hashing 을 사용하는 것

일관된 해싱 (Consistent Hashing) 
웹서버의 개수가 변동하는 가운데 요청을 분산하는 방법

해시테이블의 크기가 변할 때, 평균적으로 K/n의 키만 재매핑되면 된다.

즉, 노드나 슬롯의 개수가 바뀔 때 & 노드의 추가나 삭제를 할 때 오직 K/n의 아이템만 다시 섞이면 되는 것이다.

(n은 전체 노드의 개수, K는 item의 개수)

 

 

 

---

 

 

 

로드 밸런싱 알고리즘

라운드 로빈 (Round Robin)

• 클라이언트의 요청을 여러 대의 서버에 순차적으로 분배하는 방식
• 추가적인 계산작업이 없이, 들어온 요청을 빠르게 서버에 분산해 전송하는 1차원적인 주기능에 focus를 맞춘 방식이기 때문에, 가장 많이 사용되는 로드밸런싱 기법
• 모든 서버의 스펙이 동일하거나 비슷한 경우에 사용
  
  

가중 라운드 로빈 (Weighted Round Robin)

• 각 서버에 처리량(가중치)를 지정한 후, 가중치가 높은 서버에 클라이언트 요청을 우선적으로 전달하는 방식
• 주로 서버의 트래픽 처리 용량이 다를 경우, 즉 특정 서버의 스펙(사양)이 더 좋을 경우 사용
  예를 들어, A 서버(가중치 3)와 B 서버(가중치 1)가 있고 로드 밸런서가 클라로부터 총 8개의 요청을 받았다면, A와 B 서버에 각 6개와 2개의 요청이 전달된다.
  
  

IP 해시 (IP Hash)

• 클라이언트의 IP 주소가 어떤 서버로 클라의 요청이 전달될지를 결정하는 방식
• 클라의 IP 주소가 바뀌지 않으면 동일한 서버로 요청이 보내지는 것을 보장
• RR 방식과 달리, 서버에 Session clustering이 구성되어 있지 않은 경우에 주로 사용
  
  

최소 연결 (Least Connection)

• 요청이 들어온 시점에 가장 적게 연결돼있는 서버에 요청을 전송하는 방식
• 서버에 분배된 트래픽이 일정하지 않을 경우에 주로 사용
  
  

최소 응답 시간 (Least Response Time)

• 서버의 현재 연결 상태와 응답 시간을 모두 고려하여 가장 적은 연결 수와 가장 짧은 응답 시간을 가지는 서버에 우선적으로 요청을 보내는 방식

 

 

 

---

 

 

로드밸런서의 종류

로드 밸런서의 종류로는 L2, L3, L4, L7가 있음 (L4 로드 밸런서와 L7 로드 밸런서가 가장 많이 사용됨)

 

L4 로드밸런서

• L4 로드 밸런서부터 포트 번호를 바탕으로 로드(부하)를 분산하는 것이 가능
• L4 로드 밸런서는 4 Layer 이하의 모든 계층의 정보를 가지기 때문에 IP 주소와 포트 번호 등을 로드 밸런싱에 활용
• 한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드 밸런서 이상을 사용해야만 함

L7 로드밸런서

• L7 로드 밸런서는 HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가
  (패킷의 내용을 확인해서 그 내용에 따라 트래픽을 특정 서버에 전송하는 것이 가능한 것)
• URL에 따라 부하를 분산시키거나, HTTP 헤더의 쿠키값에 따라 부하를 분산하는 등 클라이언트의 요청을 보다 세분화해 서버에 전달할 수 있음
• 서버들로부터 필요한 정보를 응답 받아 클라의 요청을 전달하기 전에 서버의 상태를 파악한 후 로드밸런싱을 진행할 수 있음 (서버의 응답을 알고 분석할 수 있음)

 

 

 

 

 

 

---

참고사이트

[Load Balancing] LB란 무엇인가?

[Network] 로드 밸런서(LB) - 정의, 역할, 로드밸런싱 알고리즘, 종류