[Network] Load Balancing (로드 밸런싱)의 개념과 이해

처음 서버를 개발하고, 이를 운영하는 데까지 많은 학습 시간이 필요했습니다. 서버 개발을 위해 Servlet, JSP, Spring을 배우게 되었고, 나아가서는 더 나은 프레임워크 및 차이를 알아보기 위해 Flask, Django, Nest.js 등 다양한 프레임워크를 사용했었죠. 그러나 서버 공부는 이것이 끝이 아니었습니다.

우리는 이러한 서버를 인터넷에 서비스하기 위해 많은 것을 고민해야 했습니다. 서버에서 10, 100명만 접속해서 끝날 일이라면 그냥 서버를 개발하고, 배포하는 것만으로 끝날 일이지만, 만약 수십만 명의 사용자들이 내 서버에 접속해야 한다면 어떤 일이 벌어질까요?

만약, 서버가 멀티 스레드를 사용하고, 각 사용자가 접속할 때마다 스레드를 생성하는 형태를 가지고 있다면, 1만 명 아니 그 이하의 사용자가 접속하는 순간 서버에서 오류를 발생할 것입니다. 왜냐구요? 보통 운영체제에서 스레드를 생성할 수 있는 갯수가 제한되어 있기 때문이죠.. 만약 내가 128 코어 프로세서에 512GB 메모리를 지닌 덩치 큰 서버를 가지고 있다고 하더라도 서버의 리소스를 다 쓰지도 못한 채 사용자가 접속하지 못하는 어이 없는 상황을 불러오게 됩니다.

개인화 서비스(블로그, 홈페이지, Git)를 개발하고, 운영하면서 이러한 문제가 발생 하는 경우는 거의 없었습니다. 왜냐하면 잘 구축되어 있는 클라우드(PaaS)를 이용하면 이를 알아서 처리해주기 때문이죠 (사실 개별적으로 로드 밸런싱을 해야할 만큼 서비스를 하는 것도 아니지만요 ㅠ)

 

 

What is Load Balancing ?

로드 밸런싱이란, 인터넷 서비스에서 발생하는 대량의 트래픽을 분산 처리해주는 기술입니다. 실제로 처음에는 L7 스위치라는 하드웨어 네트워크 장비에서 지원해주던 레벨의 기술이었지만 최근에는 소프트웨어적인 방식으로도 로드 밸런싱을 사용할 수 있어, 대부분의 회사에서 이 기술을 사용하여 서비스를 운영하고 있습니다.

원리는 이렇습니다. 사용자가 인터넷에서 어느 서비스에 접속하게 되면, 앞단에 네트워크 장비가 이 이벤트를 받고, 트래픽의 상황에 따라 1번 서버에 접속을 시킬지, 2번 서버에 접속을 시킬지를 판단하여, 그 서비스에게 요청을 보내고 응답시키도록 하는 것입니다. 

로드 밸런싱은 아래의 3가지 네트워크 기술을 사용합니다.

• NAT(Network Address Translation) : 사설 IP 주소를 공인 IP 주소로 변경하는 데 사용하는 기술
• DSR(Dynamic Source Routing Control) : 로드 밸런서 사용시 서버에서 클라이언트로 되돌아가는 경우 목적지의 주소를 스위치 IP 주소가 아닌 클라이언트의 IP 주소로 전달해 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아개는 개념
• Tunneling : 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있도록 하는 개념, 데이터를 캡슐화하여 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화 해제 가능

 

 

Operating for Load Balancing

로드 밸런싱의 동작을 간단히 설명한다면, 네트워크에서 IP 주소와 MAC 주소를 이용해 목적지 IP 주소를 찾아가고 출발지(Source)로 되돌아오는 구조입니다. 이들 방식에는 아래의 4가지 방식이 있습니다.

• Bridge/Transparent Mode
  사용자가 서비스를 요청하면, L4로 전달된 목적지 IP 주소를 Real Server IP 주소로 변환하고 MAC 주소 또한 변환해 목적지로 찾아가는 방식
  
  1. 요청 전달 시 변환: 사용자 -> L4 -> NAT(IP/MAC 변환) -> Real Server =: 사용자가 L4 호출시 중간에 NAT에 의해 주소 변환됨
  2. 응답 전달시 변환: Real Server -> NAT -> L4 -> 사용자 =: Real Server에서 L4를 거치면서 출발지(Source) IP 주소를 L4 사설 IP 주소로 변환하 되, MAC 주소는 변환하지 않음 (동일 네트워크 대역이기 때문)
  
  
• Router Mode
  Bridge/Transparent Mode와 방식은 비슷하지만 출발지(Source)의 MAC 주소도 변환되는 방식
  
  
• One Arm Mode
  사용자가 Real Server에 접속할 때, 목적지(Destination) IP는 L4 스위치의 IP를 바라보게 되는데, L4에 도달하면 L4는 클라이언트에게 받은 목적지 IP 주소를 L4 IP 주소에서 Real Server IP와 MAC 주소로 변환하고, 되돌아가는 IP는 L4의 IP Pool의 IP 주소로 변환
  
  
• DSR (Direct Server Return) Mode
  사용자가 Real Server에 접속할 떄, 출발지(Source), 목적지(Destination) IP 주소를 변환하지 않고, L4에서 관리하는 MAC 주소 테이블을 확인해 MAC 주소만을 변환하는 방식 (여기서 ARP 프로토콜을 사용)

 

 

Scheduling Algorithm

로드 밸런싱에도 트래픽을 분산하는 알고리즘이 있습니다. 무작정 사용자가 들어옴에 따라 균등하게 분산처리하면 베스트라고 보실 수도 있겠지만, 만약 두 서버가 다른 스펙을 가지고 있다거나, 환경이 다른 경우에는 이러한 알고리즘이 오히려 악효과를 부를 수도 있습니다. 따라서 로드 밸런싱에는 여러 알고리즘이 존재합니다.

• RR(Round-Robin) : 네트워크에 연결되어 있는 서버를 처음부터 차례대로 선택하는 방식의 알고리즘
• WRR(Weighted Round-Robin) : RR에 가중치(Weight)를 추가한 알고리즘으로, 가중치를 이용해 분산하는 알고리즘 가중치는 운영자가 선택할 수 있으며, 가중치가 클 수록 빈번하게 선택된다.
• LC(Least-Connection) : 접속 수가 가장 적은 서버를 선택하는 알고리즘
• WLC(Weighted Least-Connection) : LC에 가중치(Weight)를 추가한 알고리즘으로, (Connection + 1) / Weight가 최소가 되는 서버를 우선으로 접속시킨다. 
• SED(Shortest Expected Delay) : 가장 응답 속도가 빠른 서버를 선택하는 알고리즘으로, 서버에 ESTABLISHED Connection이 가장 적은 서버를 선택한다.

사실 쉽고, 편하게 쓸 수 있는 알고리즘은 LC 알고리즘입니다. 접속 수가 가장 적은 서버를 선택하게 되면, 사용자가 가능한 깨끗한 환경을 사용할 수 있기 때문이죠. 그러나 항상 Best가 될 수는 없습니다.

 

 

마치며...

로드 밸런싱에 대한 간단한 이야기를 해봤습니다. 마지막 포스트가 IP Masquerade였는데, 로드 밸런싱 이전에 멀티 프로세스, 멀티 스레드 방식의 서버 개발 이야기를 해보려다 먼저 로드 밸런싱 포스트를 하게 되었습니다.

차후 다른 카테고리에서 이 로드 밸런싱을 어떻게 사용할 수 있는지에 대해 적어보고자 합니다.

 

 

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