웹사이트 검색

HAProxy 및 부하 분산 개념 소개

소개

HAProxy는 High Availability Proxy의 약자로 Linux, macOS 및 FreeBSD에서 실행할 수 있는 널리 사용되는 오픈 소스 소프트웨어 TCP/HTTP 로드 밸런서 및 프록시 솔루션입니다. 가장 일반적인 용도는 여러 서버(예: 웹, 애플리케이션, 데이터베이스)에 워크로드를 분산하여 서버 환경의 성능과 안정성을 개선하는 것입니다. GitHub, Imgur, Instagram 및 Twitter를 포함하여 많은 유명 환경에서 사용됩니다.

이 가이드에서는 HAProxy가 무엇인지에 대한 일반적인 개요를 살펴보고 로드 밸런싱 용어를 검토하며 서버 환경의 성능과 안정성을 개선하는 데 HAProxy를 사용할 수 있는 방법에 대한 예를 제공합니다.

HAProxy 용어

로드 밸런싱 및 프록싱을 논의할 때 중요한 용어와 개념이 많이 있습니다. 다음 하위 섹션에서 일반적으로 사용되는 용어를 살펴보겠습니다.

로드 밸런싱의 기본 유형을 시작하기 전에 ACL, 백엔드 및 프런트엔드를 검토해야 합니다.

액세스 제어 목록(ACL)

부하 분산과 관련하여 ACL은 일부 조건을 테스트하고 테스트 결과에 따라 작업(예: 서버 선택 또는 요청 차단)을 수행하는 데 사용됩니다. ACL을 사용하면 예를 들어 패턴 일치 및 백엔드에 대한 연결 수와 같은 다양한 요소를 기반으로 유연한 네트워크 트래픽 전달이 가능합니다.

ACL의 예:

acl url_blog path_beg /blog

이 ACL은 사용자 요청 경로가 /blog로 시작하는 경우 일치합니다. 예를 들어 이것은 http://yourdomain.com/blog/blog-entry-1의 요청과 일치합니다.

ACL 사용에 대한 자세한 안내는 HAProxy 구성 매뉴얼을 확인하십시오.

백엔드

백엔드는 전달된 요청을 수신하는 서버 집합입니다. 백엔드는 HAProxy 구성의 backend 섹션에서 정의됩니다. 가장 기본적인 형태의 백엔드는 다음과 같이 정의할 수 있습니다.

  • 사용할 부하 분산 알고리즘
  • 서버 및 포트 목록

백엔드는 하나 이상의 서버를 포함할 수 있습니다. 일반적으로 백엔드에 더 많은 서버를 추가하면 부하를 여러 서버에 분산시켜 잠재적인 부하 용량이 증가합니다. 일부 백엔드 서버를 사용할 수 없게 되는 경우에도 이러한 방식을 통해 안정성이 향상됩니다.

다음은 포트 80에서 수신하는 각각 두 개의 웹 서버가 있는 web-backend 및 blog-backend의 두 백엔드 구성 예입니다.

backend web-backend
   balance roundrobin
   server web1 web1.yourdomain.com:80 check
   server web2 web2.yourdomain.com:80 check
   
backend blog-backend
   balance roundrobin
   mode http
   server blog1 blog1.yourdomain.com:80 check
   server blog1 blog1.yourdomain.com:80 check

balance roundrobin 줄은 로드 밸런싱 알고리즘 섹션에 자세히 설명된 로드 밸런싱 알고리즘을 지정합니다.

모드 http는 계층 7 프록시가 사용되도록 지정하며 이는 로드 밸런싱 유형 섹션에 설명되어 있습니다.

server 지시문 끝에 있는 check 옵션은 해당 백엔드 서버에서 상태 검사를 수행하도록 지정합니다.

프런트엔드

프런트엔드는 요청을 백엔드로 전달하는 방법을 정의합니다. 프런트엔드는 HAProxy 구성의 frontend 섹션에서 정의됩니다. 해당 정의는 다음 구성 요소로 구성됩니다.

  • IP 주소 및 포트 집합(예: 10.1.1.7:80, *:443 등)
  • ACL
  • use_backend 규칙은 어떤 ACL 조건이 일치하는지에 따라 사용할 백엔드를 정의하고/또는 다른 모든 경우를 처리하는 default_backend 규칙

다음 섹션에서 설명하는 것처럼 프런트엔드는 다양한 유형의 네트워크 트래픽에 맞게 구성할 수 있습니다.

부하 분산 유형

부하 분산에 사용되는 기본 구성 요소를 이해했으므로 이제 기본 유형의 부하 분산으로 이동할 수 있습니다.

로드 밸런싱 없음

로드 밸런싱이 없는 단순한 웹 애플리케이션 환경은 다음과 같습니다.

이 예에서 사용자는 yourdomain.com에서 웹 서버에 직접 연결하며 로드 밸런싱은 없습니다. 단일 웹 서버가 다운되면 사용자는 더 이상 웹 서버에 액세스할 수 없습니다. 또한 많은 사용자가 동시에 서버에 액세스하려고 하고 로드를 처리할 수 없는 경우 경험이 느려지거나 전혀 연결하지 못할 수 있습니다.

레이어 4 로드 밸런싱

네트워크 트래픽을 여러 서버로 부하 분산하는 가장 간단한 방법은 계층 4(전송 계층) 부하 분산을 사용하는 것입니다. 이 방법으로 로드 밸런싱은 IP 범위 및 포트를 기반으로 사용자 트래픽을 전달합니다(즉, http://yourdomain.com/anything에 대한 요청이 들어오면 트래픽은 모든 것을 처리하는 백엔드로 전달됩니다. 포트 80의 yourdomain.com에 대한 요청). 레이어 4에 대한 자세한 내용은 네트워킹 소개의 TCP 하위 섹션을 확인하십시오.

다음은 계층 4 로드 밸런싱의 간단한 예에 대한 다이어그램입니다.

사용자는 백엔드 서버의 web-backend 그룹에 사용자의 요청을 전달하는 로드 밸런서에 액세스합니다. 어떤 백엔드 서버를 선택하든 사용자의 요청에 직접 응답합니다. 일반적으로 웹 백엔드의 모든 서버는 동일한 콘텐츠를 제공해야 합니다. 그렇지 않으면 사용자가 일관성 없는 콘텐츠를 받을 수 있습니다. 두 웹 서버는 동일한 데이터베이스 서버에 연결됩니다.

레이어 7 로드 밸런싱

네트워크 트래픽 부하를 분산하는 또 다른 더 복잡한 방법은 계층 7(애플리케이션 계층) 부하 분산을 사용하는 것입니다. 계층 7을 사용하면 로드 밸런서가 사용자 요청 내용에 따라 다른 백엔드 서버에 요청을 전달할 수 있습니다. 이 로드 밸런싱 모드를 사용하면 동일한 도메인 및 포트에서 여러 웹 응용 프로그램 서버를 실행할 수 있습니다. 계층 7에 대한 자세한 내용은 네트워킹 소개의 HTTP 하위 섹션을 확인하세요.

다음은 계층 7 로드 밸런싱의 간단한 예에 대한 다이어그램입니다.

이 예에서 사용자가 yourdomain.com/blog를 요청하면 블로그 애플리케이션을 실행하는 서버 집합인 blog 백엔드로 전달됩니다. 다른 요청은 다른 애플리케이션을 실행 중일 수 있는 web-backend로 전달됩니다. 이 예에서는 두 백엔드 모두 동일한 데이터베이스 서버를 사용합니다.

예제 프런트엔드 구성의 스니펫은 다음과 같습니다.

frontend http
  bind *:80
  mode http

  acl url_blog path_beg /blog
  use_backend blog-backend if url_blog
 
  default_backend web-backend

이렇게 하면 포트 80에서 들어오는 모든 트래픽을 처리하는 http라는 프런트엔드가 구성됩니다.

acl url_blog path_beg /blog는 사용자 요청의 경로가 /blog로 시작하는 경우 요청과 일치합니다.

use_backend blog-backend if url_blog는 ACL을 사용하여 트래픽을 blog-backend로 프록시합니다.

default_backend web-backend는 다른 모든 트래픽이 web-backend로 전달되도록 지정합니다.

부하 분산 알고리즘

사용되는 로드 밸런싱 알고리즘은 백엔드에서 로드 밸런싱 시 선택될 서버를 결정합니다. HAProxy는 알고리즘에 대한 몇 가지 옵션을 제공합니다. 부하 분산 알고리즘 외에도 서버에 가중치 매개변수를 할당하여 다른 서버와 비교하여 서버가 선택되는 빈도를 조작할 수 있습니다.

일반적으로 사용되는 몇 가지 알고리즘은 다음과 같습니다.

라운드 로빈

라운드 로빈은 서버를 차례로 선택합니다. 이것이 기본 알고리즘입니다.

최소 콘

연결 수가 가장 적은 서버를 선택합니다. 더 긴 세션에 권장됩니다. 동일한 백엔드의 서버도 라운드 로빈 방식으로 순환됩니다.

원천

이것은 사용자가 요청하는 소스 IP 주소의 해시를 기반으로 사용할 서버를 선택합니다. 이 방법을 사용하면 동일한 사용자가 동일한 서버에 연결할 수 있습니다.

고정 세션

일부 애플리케이션에서는 사용자가 동일한 백엔드 서버에 계속 연결해야 합니다. 이는 이를 필요로 하는 백엔드에서 appsession 매개변수를 사용하여 고정 세션을 통해 달성할 수 있습니다.

건강 체크

HAProxy는 상태 확인을 사용하여 요청을 처리하는 데 백엔드 서버를 사용할 수 있는지 확인합니다. 이렇게 하면 사용할 수 없게 된 경우 백엔드에서 서버를 수동으로 제거할 필요가 없습니다. 기본 상태 검사는 서버에 대한 TCP 연결 설정을 시도하는 것입니다.

서버가 상태 확인에 실패하여 요청을 처리할 수 없는 경우 백엔드에서 자동으로 비활성화되며 다시 정상이 될 때까지 트래픽이 전달되지 않습니다. 백엔드의 모든 서버에 장애가 발생하면 해당 백엔드 서버 중 하나 이상이 다시 정상 상태가 될 때까지 서비스를 사용할 수 없게 됩니다.

데이터베이스 서버와 같은 특정 유형의 백엔드의 경우 기본 상태 검사가 반드시 서버가 여전히 건강한지 여부를 확인하는 것은 아닙니다.

Nginx 웹 서버는 독립 실행형 프록시 서버 또는 로드 밸런서로도 사용할 수 있으며 캐싱 및 압축 기능을 위해 HAProxy와 함께 자주 사용됩니다.

고가용성

이 튜토리얼에서 설명하는 레이어 4 및 7 로드 밸런싱 설정은 둘 다 로드 밸런서를 사용하여 많은 백엔드 서버 중 하나로 트래픽을 전달합니다. 그러나 로드 밸런서는 이러한 설정에서 단일 실패 지점입니다. 다운되거나 요청에 압도당하면 서비스에 긴 대기 시간 또는 다운타임이 발생할 수 있습니다.

고가용성(HA) 설정은 단일 장애 지점이 없는 인프라로 광범위하게 정의됩니다. 아키텍처의 모든 계층에 중복성을 추가하여 단일 서버 오류가 다운타임 이벤트가 되는 것을 방지합니다. 로드 밸런서는 백엔드 레이어(웹/앱 서버)의 중복성을 용이하게 하지만 진정한 고가용성 설정을 위해서는 중복 로드 밸런서도 있어야 합니다.

다음은 고가용성 설정의 다이어그램입니다.

이 예에서는 한 서버에서 다른 서버로 다시 매핑할 수 있는 정적 IP 주소 뒤에 여러 로드 밸런서(활성 하나와 수동 하나 이상)가 있습니다. 사용자가 웹 사이트에 액세스하면 요청이 외부 IP 주소를 통해 활성 로드 밸런서로 이동합니다. 로드 밸런서에 장애가 발생하면 장애 조치 메커니즘이 이를 감지하고 IP 주소를 패시브 서버 중 하나에 자동으로 재할당합니다. 능동/수동 HA 설정을 구현하는 방법에는 여러 가지가 있습니다. 자세한 내용은 예약된 IP 사용 방법을 참조하십시오.

결론

이제 로드 밸런싱을 이해하고 HAProxy를 사용하는 방법을 알았으므로 자체 서버 환경의 성능과 안정성을 개선하기 위한 견고한 기반을 갖추었습니다.

나중에 볼 수 있도록 HAProxy의 출력을 저장하는 데 관심이 있는 경우 CentOS 8에서 Rsyslog로 HAProxy 로깅을 구성하는 방법[빠른 시작]을 확인하십시오.

문제를 해결하려는 경우 일반적인 HAProxy 오류를 해결하는 방법을 확인하십시오.