lottie
Seungjun's blog
blog
궁금해서 알아본 로드밸런싱


  블로그를 만들며 프론트 배포, 서버 배포, 데이터 베이스, S3 등을 한 싸이클을 경험해보니 로드 밸런서는 어떻게 서버의 업무를 분배하고 부하를 줄이는지 원리가 궁금해졌다. 간단하게 원리가 어떤지 살펴보자


로드 밸런싱이란?

  로드 밸런싱은 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법이다.

예를 들어설명하자면,

 여러 서버를 둔다면 해당 서비스에 접근하기 위해서는 서버마다 존재하는 다른 IP가 필요하다.

 서버마다 다른 공인 IP를 부여한다면 사용자들마다 각각 다른 IP로 접속할 것이고, 개발자가 원하는 방식대로 부하를 분산하기 어려워진다.

 100명의 사용자가 존재하고 2대의 서버가 있다면 99명의 사용자가 서버 1에 접속하고 1명의 사용자가 서버 2에 접속할 수도 있다.

 이를 방지하기 위해 여러대의 컴퓨터 자원에 작업을 나누는 것을 로드밸런싱(load balancing)이라고 하고 작업을 담당하는 장비를 로드밸런서(load balancer)라고 부른다.


로드밸런서의 종류

  로드밸런서는 OSI 7계층을 기준으로 어떻게 부하를 분산하는지에 따라 종류가 나뉩니다. 2계층을 기준으로 부하를 분산한다면 L2, 3 계층을 기준으로 부하를 분산한다면 L3인 방식입니다. 상위 계층으로 갈수록 섬세한 부하 분산이 가능하지만 가격이 비싸집니다. 하위 계층으로 갈수록 간단한 부하 분산이 가능하고 가격이 저렴해집니다.


계층

기능

예시

L2

Data link 계층을 사용, Mac주소 기반 부하 분산


L3

Network 계층을 사용, IP주소 기반 부하 분산


L4

Transport 계층을 사용, Port 기반 부하 분산

port 기반

L7

Application 계층을 사용, 요청(URL) 기반 부하 분산

URL 기반


로드밸런서의 주요 기능

 로드밸런서는 3가지의 주요 기능을 통해 로드밸런싱을 진행합니다.


Network Address Translation(NAT)

Private IP를 Public IP로 바꿈


Tunneling

데이터를 캡슐화하여 연결된 노드만 캡슐을 해제할 수 있게 만듦


Dynamic Source Routing protocol(DSR)

요청에 대한 응답을 할 때 로드밸런서가 아닌 클라이언트의 IP로 응답


로드밸런서가 동작하는 방법

  기초적인 방법인 Bridge/Transparent Mode에서는 사용자가 서버에 서비스를 요청할 때 중간에서 로드밸런서가 NAT를 통해 IP/MAC주소를 변조합니다. 즉 요청과 응답이 모두 Load Balancer를 경유합니다.


요청 과정

  1. 클라이언트가 서비스를 요청한다.

  2. 서버에 요청이 들어가기 이전 프록시로 로드밸런서가 요청을 받는다.

  3. 로드밸런서는 NAT를 적용하여 IP/MAC 주소를 변조하여 서버로 트래픽을 요청한다

응답 과정

  1. 서버가 로드밸런서로부터 받은 요청에 대한 응답을 로드밸런서로 전달한다.

  2. 로드밸런서는 NAT를 적용하여 출발지 IP주소를 로드밸런서의 가상 IP주소로 변조하여 유저에게 전달한다.


로드밸런서가 서버를 선택하는 방법

Round Robin

 요청이 들어오는 대로 서버마다 균등하게 요청을 분배합니다. 가장 단순한 분배 방식입니다.


Weighted Round Robin Scheduling

 Round Robin방식으로 분배하지만 서버의 가중치에 따라 요청을 더 분배하기도, 덜 분배하기도 합니다. 서버 가중치는 사용자가 지정할 수 있고 동적으로 조정되기도 합니다.


Least Connection

 서버마다 연결된 커넥션이 몇개인지 체크하여 커넥션이 가장 적은 서버로 요청을 분배하는 방식입니다.


Weighted Least Connections

 Least Connection방식으로 분배하지만 서버 가중치에 따라 요청을 더 분배하기도, 덜 분배하기도 합니다. 서버 가중치는 사용자가 지정할 수 있고 동적으로 조정되기도 합니다. 서버 풀에 존재하는 서버들의 사양이 일관적이지 않고 다양한 경우 이 방법이 효과적입니다.


Fastest Response Time

 서버가 요청에 대해 응답하는 시간을 체크하여 가장 빠른 서버로 요청을 분배하는 방식입니다.


Source Hash Scheduling

 사용자의 IP를 해싱한 후 그 결과에 따라 서버로 요청을 분배합니다. 사용자의 IP는 고정되어 있기 때문에 항상 같은 서버로 연결된다는 보장을 받을 수 있습니다.