로드밸런싱(Load Balancing)과 고가용성(HA)

목차

• 로드밸런싱(Load Balancing)의 이점
• 로드밸런서(Load Balancer)
• 로드밸런서의 주요 기능
• 로드밸런서 동작 방식
• 서비스 중단 없이 장애를 대처하는 방법 (HA 클러스터 구성)
• 트래픽을 분산하는 로드밸런싱 주요 알고리즘

---

로드밸런싱 (Load Balancing)의 이점

로드밸런싱이란 병목현상을 방지하기 위해 서버의 부하를 분산하기 위해 N개의 서버에 트래픽을 분배하는 것이다. 트래픽이 높은 서비스를 다룰 때, 서비스의 무결성과 가용성을 유지하기 위해 로드 밸런싱은 필수적이다. From DNS requests to web servers, load balancing can mean the difference between costly downtime and a seamless end user experience.

로드밸런싱의 이점은 다음과 같다.

1. 시스템 관리자가 클라이언트 요청을 쉽게 처리할 수 있게 하고 사용자의 대기 시간을 단축함
2. 사용자들은 빠른 무중단 서비스를 경험할 수 있음. 클라이언트의 요청이 즉시 사용 가능한 서버에 분배되므로 단일 서버가 이전 작업들을 처리할 때 까지 기다릴 필요가 없다.
3. 서비스 제공하는 입장에서 장애로 인한 서비스 중단시간이 적고 처리량이 높다. 모든 서버가 장애가 발생할 지라도 로드밸런서가 정상적인 대기 서버로 라우팅되기 때문에 최종 사용자(End user)에게 영향이 없다.
4. 시스템 관리자는 장애나 부하가 더 적은 구성을 경험한다. 단일 서버가 많은 작업을 수행하는 대신, 로드밸런싱이 여러 서버에 작업을 분산해 적은 양으 작업을 수행하게 한다.

---

로드밸런서 (Load Balancer)

• L4 (Trasnport Layer) : IP, Port, Session 기반으로 로드밸런싱 작업을 한다. 로드밸런서 설정 시 Health Cehck를 통해 장애여부를 판단하며, 보통은 라운드로빈 방식을 채택한다. 

• L7 (Application Layer) : packet payload(관심있는 데이터)를 분석하여 원하는 포트로 전달이 가능하다. (콘텐츠 기반 스위칭)

• NginX

• HAProxy

자세한 내용은 아래 포스팅을 참고한다.

로드밸런서 (L4, L7, NginX, HAProxy)

---

로드밸런서의 주요 기능

• DSR (Driect Server Return)

서버의 응답 결과를 받을 목적지 주소를 L/B과 같은 네트워크 스위치 IP 주소가 아닌, 클라이언트의 IP주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념

예를 들어, L/B가 양방향 프록시라면 모든 웹서버가 받는 트래픽을 L/B가 받게 된다. DSR은 응답 시 L/B를 거치지 않고 출발지 IP로 바로 응답하게 한다. DSR 기능을 통해 L/B는양방향에서 발생하는 모든 트래픽을 받는 게 아닌, 클라이언트에서 발생한 트래픽만 처리하게 된다.

적합한 경우 : 요청 패킷이 적은 케이스 (일반적인 웹 요청, 파일 다운로드)

적합하지 않은 경우 : 요청 패킷이 많은 케이스 (파일업로드, SMTP) - 파일 업로드 시에는 L/B를 거치지 않도록 해야함

• NAT (Network Address Translation)

 사설 IP 주소를 공인 IP 주소로 변경하는 통신망의 주소 변조기

사설 네트워크에 속한 여러개의 호스트가 하나의 공개 IP를 통해 접속하는 것을 목적으로 한다.

• Tunneling

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

---

로드밸런서 동작 방식

로드 밸런서는 네트워크에서 IP 주소와 MAC 주소를 이용해 목적지(destination) IP 주소를 찾아가고 출발지로 되돌아오는 구조로 동작한다.

기본 동작 방식

1. 최종 사용자가 특정 작업을 수행한다.
2. 프론트엔드 서버는 요청을 받고 전달할 곳을 결정한다. (프론트엔드 서버에서 로드밸런싱을 한다고 가정)
3. 백엔드 서버는 요청을 처리하고 응답 결과를 생성한다. 한편 백엔드 서버는 로드밸런서에 주기적으로 현재 상태를 보고한다.
4. 백엔드 서버는 프론트엔드 서버에 응답을 반환하고, 프론트엔드 서버는 사용자에게 응답결과를 전달한다.

 

4가지의 동작 모드를 통해 로드밸런서를 이해해보자.

1. Bridge/Transparent Mode

사용자가 서비스를 요청하면 L4로 전달된 목적지 IP주소를 실서버 IP 주소로 변조하고 MAC 주소를 변조해서 목적지를 찾아가는 방식

- 요청 전달 시 변조

사용자 > L4 > NAT (IP/MAC 주소 변조) > 실서버

사용자가 L4를 호출하면 NAT가 목적지 IP주소를 실서버의 IP주소와 MAC주소 변조

- 응답 전달 시 변조

실서버 > NAT > L4 > 사용자

실서버에서 L4를 거치면서 출발지 IP주소를 L4 가상IP 주소로 변조. 동일 네트워크 대역이므로 MAC주소는 변조하지 않음

2. Router Mode

Bridge/Transparent Mode와 유사하지만 출발지의 MAC 주소도 변조함

3. One Arm Mode

사용자가 실서버에 접근할 때 목적지 IP는 L4 스위치 IP를 바라봄. L4에 도달하면 L4가 클라이언트에게 받은 목적지 IP주소를 L4 IP주소에서 -> 실서버 IP와 실서버 MAC 주소로 변조함. 되돌아가는 IP는 L4의 IP pool의 IP주소로 변조함.

4. DSR (Direct Server Return) Mode

사용자가 실서버에 접근할 때 출발지와 목적지의 IP주소를 변조하지 않고, L4에서 관리하는 실서버의 MAC 주소 테이블을 확인해서 MAC 주소만 변조함

---

장애를 대비하는 방법은? 고가용성 클러스터 (High-availability cluster)

장애 발생 시, 서비스 운영 중단 시간을 최소한으로 하기 위해 대기 서버를 둔다. (이중화, 평소에는 트래픽 분배 X)

Acitve 중인 로드밸런서와 Standby 상태의 로드밸런서가 heartbeat를 주고 받으며 서로 정상적으로 동작하는 지 health check를 한다.

Ative L/B에 장애가 발생했을 경우 Standby L/B가 작업을 이어받을 수 있게 페일오버(Failover) 해서 서비스가 중단되지 않도록 HA cluster를 구성한다. Standby L/B가 Active 상태로 변경되면서 장애가 발생한 L/B의 가상 IP주소를 가져오기 때문에 서비스가 무정지 상태를 유지한다. 다만 1초 정도의 순단 현상은 발생할 수 있다.

---

로드밸런싱 알고리즘

• RR(Round Robin) : 가장 일반적으로 구현되는 알고리즘이다. L/B는 각 서버의 가중치에 따라 순차적으로 서버를 사용하며, 서버의 처리 시간이 균등하게 분산된다. 동적 알고리즘으로서 RR(Round Robin)은 서버 가중치를 실행 중에도 조정이 가능하다. 다만, RR은 연결 중인 세션을 고려하지 않는다.
• Static-RR (Static Round Robin) : RR과 유사한 알고리즘으로, 각 서버에 부여된 가중치에 따러서 분배한다. RR과 비교하여 static-RR은 실행 중에 서버의 가중치를 즉시 변경할 수 없다. 하지만 서버 수에 대한 설계의 제약은 없다. When a server goes up, it will always be immediately reintroduced into the farm once the full map is recomputed.
• Least Connections : 접속 수가 가장 적은 서버로 분배한다. RR과 같이 동적 알고리즘이다. LDAP, SQL, TSE와 같이 긴 세션이 필요할 경우에 사용하면 좋으며, HTTP와 같은 짧은 세션을 사용하는 프로토콜에는 적합하지 않다.
• Source : 클라이언트 IP를 해싱(hashing)하여 운영 중인 서버의 가중치로 나누어 분배한다. 서버의 수가 변경되지 않는 이상 동일한 클라리언트 IP는 항상 동일한 서버로 도달한다. 이 알고리즘은 일반적으로 cookie를 사용할 수 없는 TCP 모드에서 사용된다. 단, 클라리언트가 동적 IP를 사용한다면 같은 서버로 세션을 연결하기 어렵다.
• URI : 접속하는 URI의 왼쪽 부분 혹은 전체를 해싱URI의 길이 또는 depth로 해싱)해서 운영 중인 서버의 가중치를 나눠서 분배한다. 정적 알고리즘으로 서버의 수가 변경되지 않는 한 동일한 서버로 지정되며, Source 알고리즘과 동일한 방식으로 작동한다. 이 알고리즘은 캐싱 서버의 부하를 분산할 때 주로 사용된다. 범용성이 낮아 특정 상황에만 사용된다.
• URL_Parameter : HTTP GET의 파라미터를 확인 후 조건에 맞는 서버로 분배한다. 조건이 없는 경우에는 RR로 처리된다. 발견된 파라미터 뒤에 기호와 값이 같으면 값은 해시되고 실행 중인 서버의 가중치로 나뉜다. 오직 HTTP 모드에서만 작동한다.
• HRD : HTTP Header에서 hdr(<name>)으로 지정된 조건이 있는 경우에 대해서만 분배하며, 조건이 없는 경우 RR로 처리한다. 이 알고리즘은 브라우저 유형, 쿼리 주소 등을 기준으로 사용자를 서버에 분배해야하는 경우 유용하다. 범용성은 낮아 특정 상황에서만 사용된다.
• rdp-cookie : TCP 요청에 대한 RDP 쿠키에 따른 분배한다. Frontend의 ACL 'req_rdp_cookie()'에 해당한다. 이 알고리즘은 쿠키 식별을 통해 동일한 사용자를 특정 서버에 연결하는 것이 목적이다. 특정 쿠키와 세션을 특정 서버에 연결하는데 적합하며, 클라이언트가 쿠키를 사용하지 않는다면 알고리즘은 RR으로 작동한다.

보통 HTTP 트래픽 분산을 위해서는 "RR(Round Robin)" 알고리즘을, 데이터베이스를 위해서는 "Least Connections" 알고리즘이 많이 사용된다. 그 외 알고리즘은 상황에 따라 사용된다.

만약 여러 개의 캐시 서버가 있다면 "URI" 알고리즘이 적합하며, 요청을 특정 서버에 연결하려면 "Source" 알고리즘과 "rdp-cookie" 알고리즘이 적합하다.

쿼리 속성에 따라 분배하려면 "HDR" 알고리즘과 "URL parameter" 알고리즘이 적합하다.

---

내 업무에 적용해서 생각해보기

서버 구성은 아래와 같다. (로드밸런서 한 대, 노드 서버 두 대)

L/B -> Server 1

     -> Server 2

조만간 각 노드 서버에 캐시를 적용할 예정이다.

ex) 호출 예시

https://my_server_api.com?id=1234567890

캐시는 LRU로, 요청받은 URL의 결과값을 저장해둘 것이다. 

만약 로드밸런스를 L4, 그리고 라운드로빈 방식을 채택한다면 동일한 데이터가 각각 Server1, Server2 캐시 메모리에 저장될 수 있다.

L/B에 캐싱을 할 수도 있지만 부하가 생길 수 있다.

현재 나의 업무 서버는 L/B를 이중화 하지 않고 한 대로 운용중이기 때문에 각 노드 서버에 캐시를 적용하고, 로드밸런서는 L7, Url_based 알고리즘을 채택하는 게 어떨까 싶다. 

N개의 분산된 서버에 캐시를 적용할 경우, 어디에 캐시를 할지, 캐시에 따라 로드밸런싱은 어떻게 할 것인지 등 고려사항이 생긴다.

아직은 서버 구성과 운영함에 있어서 어떤 것을 고려해야하는 지 조차 알 지 못하니까, 섣불리 이것저것 하지말고 주위 동료들과 차근차근 업무에 적용해봐야겠다.

---

참고문서

로드밸런서란?(L4, L7)

L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy - 네이버 기술블로그

최신 네트워크 로드 밸런싱 및 프록시 소개

Load Balancing with HAProxy

HAProxy load balancer. Part 2: Backend section and the algorithms

What is Load Balancing?