로드 밸런싱(Load Balancing)

 

📌 개요

웹사이트에 트래픽이 갑자기 많이 발생하게 된다면 어떻게 해결해야 할까? 

서비스의 규모가 커지고, 이용자 수가 늘어나게 되면 기존의 서버만으로는 원활한 서비스 동작이 불가능하게 되고, 이에 대처할 수 있는 방법은 크게 두가지 이다. 

1. 기존의 서버 성능을 확장하는 scale-up 방식

2. 기존의 서버와 동일하거나 낮은 성능의 서버를 증설하는 scale-out 방식

하드웨어 향상 비용이 더욱 비싸기도 하고, 서버가 여러대면 무중단 서비스를 제공하는 환경 구성이 용이하므로 Scale-out이 효과적이다.

scale-out 방식을 통해 증가한 트래픽에 대처하기로 했다면, 여러 대의 서버로 트래픽을 균등하게 분산해주는 로드밸런싱이 반드시 필요하다.

---

📌개념

둘 이상의 CPU or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것 

 

Load Balancer를 클라이언트와 서버 사이에 두고, 부하가 일어나지 않도록 여러 서버에 분산시켜주는 방식이다.서비스를 운영하는 사이트의 규모에 따라 웹 서버를 추가로 증설하면서 로드 밸런서로 관리해주면 웹 서버의 부하를 해결할 수 있다.

---

📌로드 밸런싱 종류

로드밸런서는 OSI 7계층을 기준으로 어떻게 부하를 분산하는지에 따라 종류가 나뉜다.

2 계층을 기준으로 부하를 분산한다면 L2, 3 계층을 기준으로 부하를 분산한다면 L3인 방식이다.

상위 계층으로 갈수록 섬세한 부하 분산이 가능하지만 가격이 비싸지고,하위 계층으로 갈수록 간단한 부하 분산이 가능하고 가격이 저렴해진다.

L4, L7은 각각 Layer 4(전송 계층) 프로토콜과 Layer 7(응용 계층) 프로토콜의 헤더를 부하 분산에 이용하기 때문에 붙은 접두사이다.

모든 요청을 L4 혹은 L7 로드 밸런서가 받아 서버들에게 적절히 나누어 준다.

1. L4 로드밸런싱 

L4 로드 밸런서는 네트워크 계층(IP, IPX)이나 전송 계층(TCP, UDP)의 정보(IP주소, 포트번호, MAC주소, 전송 프로토콜)를 바탕으로 로드를 분산한다.

2. L7 로드밸런싱 

L7 로드 밸런서는 애플리케이션 계층(HTTP, FTP, SMTP)에서 로드를 분산하기 때문에 HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다. 쉽게 말해 패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능한 것이다. URL에 따라 부하를 분산시키거나, HTTP 헤더의 쿠키 값에 따라 부하를 분산하는 등 클라이언트의 요청을 보다 세분화해 서버에 전달할 수 있다.

또한 L7 로드 밸런서의 경우 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있으며, DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있어 네트워크 보안 분야에서도 활용되고 있다.

---

📌로드 밸런서의 주요 기능

상태 확인 (Health Check)

로드 밸런서는 서버들에 대한 주기적인 상태 확인을 통해 서버들의 장애 여부를 판단할 수 있다. 이로 인해, 서버에 이상이 생기면 정상적으로 동작하는 서버로 트래픽을 보내 주는 Fail-Over가 가능하며, 또한 TCP/UDP 분석이 가능하기 때문에 방화벽의 역할도 수행할 수 있다.

• L3 체크: ICMP를 이용해 서버의 IP 주소가 통신 가능한 상태인지 확인한다.
• L4 체크: TCP의 3-way handshaking을 통해 각 서버의 포트 상태를 확인한다.
• L7 체크: 애플리케이션 계층에서 체크하는 방법으로 실제 웹 페이지에 통신을 시도해 이상 유무를 파악한다.

Tunneling

터널링은 인터넷 상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념이다. 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.

로드 밸런서의 VIP 주소로 향하는 요구 패킷이 로드 밸런싱 서버로 전달되면 로드 밸런싱 서버에서 패킷의 목적지 주소와 포트를 검사하여 가상 서버 정책과 일치할 경우, 스케줄링에 따라 실제 작업 서버로 전달하게 된다. 이때 패킷을 일반적인 스트림 방식으로 전달하는 것이 아닌 캡슐 형식으로 감싸서 전달하게 된다. 이렇게 전달되면 작업 서버에서는 감싸진 패킷을 다시 풀고 요청을 처리한다.

NAT (Network Address Translation)

IP 주소를 변환해 주는 기능이다. 예를 들어, 내부 네트워크에서 사용하던 사설 IP 주소를 로드 밸런서 외부의 공인 IP 주소로 변경해 주며, 반대 과정도 가능하다. 이렇게 하면 부족한 공인 IP 주소를 효율적으로 사용할 수 있지만, 로드 밸런싱 관점에서는 여러 개의 호스트가 하나의 공인 IP 주소 (VIP)를 통해 접속하는 것이 주 목적이다.

• SNAT (Source Network Address Translation)
  • 내부에서 외부로 트래픽이 나가는 경우, 내부 사설 IP 주소를 외부 공인 IP 주소로 변환하는 방식이다. 집에서 사용하는 공유기가 대표적인 예시이다.
• DNAT (Destination Network Address Translation)
  • 외부에서 내부로 트래픽이 들어오는 경우, 외부 공인 IP 주소를 내부의 사설 IP 주소로 변환하는 방식이다.
  •  

DSR (Direct Server Routing)

서버에서 클라이언트로 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음 네트워크 장비나 로드 밸런서를 거치지 않고 바로 클라이언트로 찾아가는 방식이다. 이 경우, 로드 밸런서의 부하를 줄여줄 수 있는 장점이 있다.

---

📌로드 밸런서의 기본 동작 방식

대부분의 로드 밸런서는 아래와 같은 절차로 동작한다.

 

 

1. 클라이언트가 브라우저에서 'www.google.com'이라고 입력하면 PC에 설정된 DNS 서버로 DNS 쿼리를 보내고, 로컬 DNS 서버는 'www.google.com'을 관리하는 DNS 서버로부터 L4의 VIP 주소를 획득한다.
2. 로컬 DNS는 획득한 VIP 주소를 클라이언트에게 전송한다.
3. 클라이언트는 획득한 DNS를 기반으로 L4 VIP로 http(s) 요청을 한다.
4. LB는 최적의 서비스 서버를 내부 알고리즘을 통하여 선별한 후 요청을 전송하고, 서버 작업 결과를 LB에게 전송한다.
5. 전달 받은 결과를 LB를 통해 클라이언트에게 전송한다.

설정한 mode에 따라 다르게 동작할 수 있다. mode에 따라 어떻게 동작하는지 살펴 보자.

Bridge / Transparent Mode

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

추가로 응답할 때 동일한 네트워크 대역이므로 MAC 주소는 변경되지 않는다.

 

Router Mode

• 요청
  • 사용자가 L4의 VIP로 요청을 전송한다.
  • L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT 수행한다.
  • 네트워크 대역이 변경되었으므로, Source와 Destination MAC 주소 모두 변경된다.
• 응답
  • Real Server에서 서비스 응답 시, Destination IP가 다른 대역의 IP이므로 Gateway (L4)로 전송한다.
  • L4에서 Source IP를 VIP로 NAT 수행한다.

L4를 중심으로 상/하단의 IP 대역이 서로 다르게 구성되며, L4는 Server 대역 네트워크의 Gateway 역할을 한다.

 

One Arm Mode

• 요청
  • 사용자가 L4의 VIP로 요청을 전송한다.
  • L4에서 Real Server로 전송 시, Destination IP를 VIP에서 Real Server IP로 NAT 수행한다.
  • Destination으로 전송하기 위해서 Destination MAC 주소도 변경된다.
  • Real Server에서 L4로의 전송을 위해서 Source IP도 L4의 IP Pool의 IP로 NAT 수행한다.

One Arm Mode는 클라이언트의 IP가 Server에 전달되지 않기 때문에 Server가 실제 클라이언트의 IP를 이용해야 할 경우 부적합한 기법이다. 일반적으로 권고되지 않는 구성 방법이다.

 

DSR (Direct Server Return) Mode

방금 위에서 소개한 기법들은 모두 Inbound, Outbound 패킷이 LB를 거치기 때문에 LB에 많은 부하가 발생한다.

대부분의 서비스들의 트래픽은 보통 Inbound보다 Outbound Packet의 양이 많다.

DSR은 Outbound 패킷이 LB를 거치지 않고, 클라이언트에 바로 전달하게 만들어 LB의 부하를 줄일 수 있다.

---

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

 

라운드 로빈(Round Robin)

서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식이다.

클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합하다.

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

각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분한다.

주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식이다.
예를 들어 A라는 서버가 5라는 가중치를 갖고 B라는 서버가 2라는 가중치를 갖는다면, 로드 밸런서는 라운드로빈 방식으로 A 서버에 5개 B 서버에 2개의 요청을 전달한다.

IP 해시 방식(IP Hash Method)

클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식이다.

사용자의 IP를 해싱해(Hashing, 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것, 또는 그러한 함수) 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.

최소 연결 방식(Least Connection Method)

요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽을 배분한다.

자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합한 방식이다.

최소 응답 시간 방식(Least Response Time Method)

서버의 현재 연결 상태와 응답 시간(Response Time, 서버에 요청을 보내고 최초 응답을 받을 때까지 소요되는 시간)을 모두 고려하여 트래픽을 배분한다. 가장 적은 연결 상태와 가장 짧은 응답 시간을 보이는 서버에 우선적으로 로드를 배분하는 방식이다.

---

📌로드 밸런서 장애 대비

갑작스러운 장애에 대비해 로드 밸런서 서버는 아래와 같이 이중화를 기본으로 구성한다.

• 이중화된 Load Balancer들은 서로 Health Check를 한다.
• Main Load Balancer가 동작하지 않으면 가상IP(VIP,Virtual IP)는 여분의 Load BAlancer로 변경된다.
• 여분의 Load Balancer로 운영하게 된다.

---

Reference

https://www.digitalocean.com/community/tutorials/what-is-load-balancing#how-does-the-load-balancer-choose-the-backend-server
https://d2.naver.com/helloworld/284659
https://steady-coding.tistory.com/535