HAProxy를 이용한 로드 밸런싱 구축하기 #1 : 로드밸런싱이란

로드밸런싱이란 무엇인가요?

로드밸런싱이란 하나의 서비스에 대한 부하를 여러 서버로 분산하는것을 로드밸런싱이라고 합니다.

왜 로드밸런서가 필요할까요?

일반적인 개인 서버의 구조

위 사진처럼 클라이언트가 한두명 일경우 서버는 여유롭게 응답할수 있습니다.
그러나, 클라이언트가 수천명~기하급수적으로 증가한다면 어떻게 될까요?

미국의 Black Friday날 쇼핑몰의 모습

서버는 클라이언트의 요청에 대한 응답을 마저 하지 못한상태로 뻗어버립니다.


서버는 이러한 문제를 해결하기 위해 어떤 방법이 있을까요?

2가지 방법이 있습니다. 하나는 Scale-up 이라는 방법과 나머지 하나는 Scale-out 이라는 방법입니다.

Scale-up 의 경우 서버가 클라이언트의 응답을 더 빠르고 한꺼번에 많이 처리하기 위해 서버의 사양을 높이는 경우를 말합니다.
Scale-out 의 경우 클라이언트의 요청을 한 서버가 아닌, 여러 서버에게 분산하는 경우를 말합니다.

이 글에서는 Scale-out 이라는 방법을 다룰 예정입니다.


왜?

  • 하나의 서비스에 대해 여러 서버가 가동되므로서, 서버 failure에 대한 안전성을 확보하기 위함 (failover 라고 부릅니다)
  • 부하분산을 통해 서비스를 더 안정적이고, 원활하게 유지하기 위함
  • 무엇보다, 이 글의 주제인 HAProxy를 다루기 위해서.

로드밸런서의 주요 기능은 어떤게 있을까요?

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

종류는 어떤게 있을까요?

L2: 맥 주소를 기반으로 로드밸런싱합니다.

L3: IP주소를 기반으로 로드밸런싱합니다.

L4: Transport Layer(IP와 Port) Level에서 Load Balancing을 합니다.
TCP, UDP

L7: Application Layer(사용자의 Request) Level에서 Load Balancing을 합니다.
HTTP, HTTPS, FTP

로드밸런서는 어떤 기준으로 서버를 고를까요?

HAProxy에서의 로드밸런싱 알고리즘은 다음과 같습니다.

  • Round Robin: 가장 기본적인 알고리즘입니다. 이 알고리즘은 서버의 가중치에 따라 서버들에게 차례로 요청을 넘겨줍니다. 서버의 처리 시간이 가장 균등하게 분배되기에 가장 부드럽고 공정한 알고리즘입니다.
  • Least Connections: 이 알고리즘을 사용하면 연결 수가 가장 적은 서버가 연결을받습니다.
    이 유형의 알고리즘은 세션의 시간이 매우 길때 권장됩니다. 그러나 HTTP와 같은 짧은 세션을 사용하는 프로토콜에는 적합하지 않습니다. 이 알고리즘은 Round Robin과 같이 동적으로 작동합니다.
  • source: 이 알고리즘은 서버가 다운되거나 중지되지 않는한, 동일한 클라이언트 IP는 항상 동일한 서버에게 연결됩니다.
    소스 IP를 해시하고 실행중인 서버의 가중치에 따라 연결됩니다. 실행중인 서버 수가 변경되어 해시 결과가 변경되면 클라이언트는 다른 서버로 연결됩니다. 이 알고리즘은 정적으로 작동합니다.
  • URI: 이 알고리즘은 서버가 다운되거나 중지되지 않는한, 동일한 URI는 항상 같은 서버로 보내집니다. 
    URI의 왼쪽 부분 또는 전체 URI를 해시하고 해시 값을 실행중인 서버의 총 가중치를 기준으로 요청을 넘겨줍니다. 또한 정적 알고리즘이며 소스 알고리즘과 동일한 방식으로 작동합니다.
  • URI Parameter: 이 알고리즘은 요청한 파라미터에 따라 서버가 다르게 연결됩니다.
    지정된 URL 매개 변수는 각 HTTP GET 요청의 쿼리 문자열에서 조회됩니다. 찾은 매개 변수 뒤에 숫자 및 값이 오는 경우 이 값이 해시되고 실행중인 서버의 총 가중치를 기반으로 요청을 넘겨줍니다.

그러면, 로드밸런서 자체의 장애에 대하선 어떻게 대처하나요?

간단합니다. 로드밸런서도 이중화하여 장애를 대비 할 수있습니다.

장애가 났을때의 시나리오

  1. 이중화된 로드밸런서들은 서로 HC (Health Check) 를 합니다.
  2. Primary 로드밸런서가 장애가 됬을경우 가상 IP (Virtual IP, VIP)는 Secondary 로드밸런서로 넘어갑니다.
  3. Secondary 로드밸런서가 서비스를 계속 유지합니다.


다음시간에는 HAProxy설치와 DHCP서버 구축에 대해서 다루도록 하겠습니다.
수고하셨습니다!

Reference

댓글이 닫혀있습니다.