본문 바로가기
Web/Infra

로드밸런서의 종류와 동작방식

by EricJeong 2020. 3. 23.

로드밸런싱이 왜 필요할까?

서버가 단 하나만 존재할 때 수천만명의 사람들이 서버에 동시 접속하면 어떻게 될까요? 하나의 서버는 부하를 감당하지 못할 수도 있을 것입니다. 이를 해결하는 방식에는 장비를 업그레이드하는 Scale-up방식과 장비를 여러개 두는 Scale-out방식이 있습니다.

 

Scale-out 방식으로 여러 서버를 둔다면 해당 서비스에 접근하기 위해서는 서버마다 존재하는 다른 IP가 필요할 것입니다. 서버마다 다른 공인 IP를 부여한다면 사용자들마다 각각 다른 IP로 접속할 것이고, 개발자가 원하는 방식대로 부하를 분산하기 어려워집니다. 예를 들어 100명의 사용자가 존재하고 2대의 서버가 있다면 99명의 사용자가 서버 1에 접속하고 1명의 사용자가 서버 2에 접속할 수도 있는 것이니까요.

 

로드밸런서 없이 서버를 Scale-out했을 때 발생가능한 이슈

 

 

이를 방지하기 위해 서버를 분산하고 가해지는 부하를 적절하게 분산하는 작업이 필요합니다. 개발자가 의도한 대로 부하가 서버마다 골고루 분산되어야 각 서버가 적절하게 부하를 담당할 수 있을 것입니다. 이렇게 두 개 이상의 컴퓨터 자원에 작업을 나누는 것을 로드밸런싱(load balancing)이라고 하고 작업을 담당하는 장비를 로드밸런서(load balancer)라고 부릅니다.

 

 

간략하게 그린 로드밸런서의 동작 방법

 

 

 

로드밸런서의 종류

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

 

L2 Data link 계층을 사용, Mac주소 기반 부하 분산  
L3 Network 계층을 사용, IP주소 기반 부하 분산  
L4 Transport 계층을 사용, Port 기반 부하 분산 TCP, UDP
L7 Application 계층을 사용, 요청(URL) 기반 부하 분산 HTTP, HTTPS 등

 

L4와 L7 로드밸런싱

로드밸런서의 주요 기능

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

 

Network Address Translation(NAT)

Private IP를 Public IP로 바꿈

 

Tunneling

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

 

Dynamic Source Routing protocol(DSR)

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

 

 

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

 

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

 

 

 

 

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

Round Robin

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

 

Weighted Round Robin Scheduling

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

 

Least Connection

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

 

Weighted Least Connections

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

 

Fastest Response Time

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

 

Source Hash Scheduling

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

 

 

References

https://d2.naver.com/helloworld/284659

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/load_balancer_administration/index

 

댓글