HAProxy 및 로드 밸런싱 개념: 기본

소개

High Availability Proxy (HAProxy)는 대중적인 오픈 소스 프록시 및 TCP/HTTP 로드 밸런서 솔루션으로, Solaris, FreeBSD, 그리고 Linux에서 실행할 수 있습니다. 이는 여러 서버에 걸쳐 워크로드를 균형 있게 분산함으로써 서버 환경의 신뢰성과 성능을 향상시키는 데 가장 일반적으로 사용됩니다. 이러한 유형의 도구는 Instagram, GitHub, Twitter, Imgur와 같이 많은 유명 환경에서 사용됩니다.

이 가이드는 HAProxy를 소개하고, 로드 밸런싱 용어를 익히도록 도우며, 서버 환경의 성능과 신뢰성을 모두 강화하기 위해 이를 활용하는 방법에 대한 예시를 제공합니다.

필수 HAProxy 용어

자세한 내용을 알아보기 전에, 로드 밸런싱 및 프록시에 대한 몇 가지 중요한 용어와 개념을 익혀두는 것이 좋습니다. 다음 섹션에서 이러한 개념들을 먼저 살펴보겠습니다.

ACL (Access Control List)

로드 밸런싱에서 ACL은 특정 조건을 테스트하고 그 결과에 따라 작업을 수행하는 데 사용됩니다. 이를 통해 백엔드 연결 및 패턴 매칭을 비롯한 다양한 요소를 기반으로 트래픽을 최적으로 전달할 수 있는 기능을 제공합니다. 다음은 사용 중인 ACL의 예입니다:

이 경우, 사용자가 요청한 경로가 /blog로 시작하면 ACL이 일치합니다. 예를 들어, 이 일치 요청은 다음을 가리킵니다: http://yourdomain.com/blog/blog-entry-1. HAProxy 구성 매뉴얼에는 ACL 사용에 대한 자세한 가이드가 포함되어 있습니다.

백엔드

전달된 요청은 백엔드라고 하는 서버 집합에 의해 수신됩니다. 요청은 HAProxy 구성의 backend 섹션에 정의됩니다. 가장 기본적인 용어로, 백엔드는 사용할 로드 밸런싱 알고리즘과 포트 및 서버 목록으로 정의할 수 있습니다. 백엔드는 단일 서버 또는 여러 서버로 구성될 수 있습니다. 백엔드에 더 많은 서버가 추가될수록 잠재적인 부하 용량이 증가하며, 처리가 여러 서버에 분산됩니다. 일부 백엔드 서버가 오프라인 상태가 되면 다른 서버가 요청 처리를 처리하기 위한 백업 역할을 합니다.

두 개의 백엔드 구성 예시를 살펴보겠습니다. 이 경우 blog-backend와 web-backend입니다. 각각 포트 80에서 수신 대기하는 두 개의 웹 서버를 가지고 있습니다:

balance roundrobin 라인은 로드 밸런싱 알고리즘을 지정하기 위한 것입니다. 자세한 내용은 다음에 나오는 로드 밸런싱 알고리즘 섹션에서 확인할 수 있으며, mode http는 레이어 7 프록시 사용을 설정합니다. 이에 대해서는 로드 밸런싱 유형 섹션에서 설명하겠습니다. 또한, 서버 지시어 뒤의 check 옵션은 해당 특정 백엔드 서버에서 헬스 체크(상태 확인)가 트리거됨을 나타냅니다.

프론트엔드

요청이 백엔드로 전달되는 방식을 정의하는 것을 프론트엔드라고 합니다. 요청은 HAProxy 구성의 frontend 섹션에 정의됩니다. 이는 ACL, 포트, IP 주소 집합, 그리고 어떤 ACL 조건이 충족되었는지에 따라 사용할 백엔드를 정의하는 use_backend 규칙으로 구성됩니다. 또한, 다른 모든 경우를 처리하기 위해 default_backend 규칙도 존재합니다. 다음 섹션에서는 다양한 네트워크 트래픽 유형에 맞게 프론트엔드를 구성하는 방법을 설명합니다.

로드 밸런싱 유형

로드 밸런싱에 사용되는 기본 구성 요소가 설정되었으므로, 이제 로드 밸런싱의 기본 유형으로 넘어갈 수 있습니다.

로드 밸런싱 없음

가장 기본적인 형태에서, 로드 밸런싱이 없는 상태는 다음과 같이 설명할 수 있습니다.

이 시나리오에서는 사용자가 yourdomain.com의 웹 서버에 직접 연결합니다. 로드 밸런싱이 존재하지 않습니다. 데이터베이스 서버가 하나만 있기 때문에, 이 서버가 오프라인 상태가 되면 해당 서버의 정보에 대한 액세스가 완전히 차단됩니다. 많은 사용자가 동시에 단일 웹 서버에 연결하려고 시도하고 웹 서버가 그 부하를 처리할 수 없는 경우, 모든 연결이 느려지거나 연결에 완전히 실패하게 됩니다.

로드 밸런싱 (계층 4)

여러 서버로 네트워크 트래픽을 분산하는 가장 간단하고 실용적인 방법 중 하나는 전송 계층 또는 계층 4 분산 방법을 사용하는 것입니다. 이러한 방식의 로드 밸런싱은 연결하는 사용자의 IP 주소가 속한 IP 범위와 포트를 기반으로 사용자를 안내합니다. 즉, 만약 http://yourdomain.com/anything 에서 요청이 들어오면, 이러한 요청을 처리하도록 정의된 백엔드가 궁극적으로 이를 처리하게 됩니다. 이 백엔드는 80번 포트의 yourdomain.com에 대한 요청을 전달합니다.

계층 4 로드 밸런싱의 기본 구성은 다음과 같습니다.

사용자가 로드 밸런서에 액세스하면, 해당 요청은 웹 백엔드 서버 그룹으로 전달됩니다. 구성된 백엔드 서버가 사용자의 요청에 직접 응답합니다. 사용자가 일관되지 않은 데이터를 접하는 것을 방지하기 위해, 모든 웹 백엔드 서버는 동일한 콘텐츠를 제공해야 합니다. 위의 다이어그램에 나와 있듯이, 두 웹 서버 모두 궁극적으로 동일한 데이터베이스 서버로 연결됩니다.

로드 밸런싱 (계층 7)

네트워크 트래픽을 로드 밸런싱하는 또 다른 더 복잡한 방법이 있습니다. 바로 계층 7, 즉 애플리케이션 계층 로드 밸런싱을 사용하는 것입니다. 이 접근 방식은 사용자 요청의 콘텐츠에 따라 사용자 요청을 서로 다른 백엔드 서버로 전달할 수 있도록 합니다. 이 방법을 사용하면 동일한 포트와 도메인을 통해 여러 웹 애플리케이션 서버에서 로드 밸런싱이 수행될 수 있습니다. 이 계층에 대한 자세한 내용은 당사 자습서의 HTTP 하위 섹션인 네트워킹의 핵심: 용어, 인터페이스 및 프로토콜에 대해 알아보기 자습서를 참조하십시오.

다음 다이어그램은 계층 7 로드 밸런싱을 보여줍니다.

이 경우, 사용자가 yourdomain.com/blog를 요청하면 해당 요청이 블로그 백엔드로 전달됩니다. 이는 블로그 애플리케이션을 실행하기 위해 특별히 할당된 백엔드 서버 세트입니다. 한편, 다른 요청은 웹 백엔드로 전달됩니다. 그러나 두 백엔드 모두 결국 동일한 데이터베이스 서버에 액세스하게 됩니다.

계층 7 로드 밸런싱을 위한 프론트엔드 구성의 작은 예는 다음과 같은 명령과 같습니다. 이 명령은 80번 포트를 통해 들어오는 트래픽을 처리하도록 http 프론트엔드를 구성합니다.

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

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

defaut_backen web_backend 은 다른 모든 트래픽 전달을 web-backend로 안내합니다.

로드 밸런싱 알고리즘

로드 밸런싱이 수행될 때, 이 목적으로 어떤 백엔드 서버가 선택될지를 정의하는 것은 로드 밸런싱 알고리즘입니다. HAProxy가 제공하는 여러 알고리즘 옵션이 있습니다. 또한 다른 서버와 대조하여 특정 서버가 얼마나 자주 선택되는지 조절하기 위해 서버에 가중치(weight) 매개변수를 할당하는 것도 가능합니다. 사용 가능한 알고리즘이 너무 많아서 모두 설명할 수는 없습니다. 따라서 이 가이드는 가장 일반적인 알고리즘에만 초점을 맞출 것입니다. 전체 목록을 보려면 HAProxy Documentation Converter를 참조하여 전체 목록을 확인할 수 있습니다. 가장 일반적으로 사용되는 알고리즘은 다음과 같습니다:

• roundrobin: 서버를 차례대로 선택하는 기본 알고리즘입니다.
• leastconn: 연결 수가 가장 적은 서버가 자동으로 선택됩니다. 하지만 동일한 백엔드 내의 해당 서버들은 라운드 로빈 방식으로 순환되어야 합니다.
• source: 사용자 요청의 소스가 되는 IP 주소를 기반으로 서버를 선택하는 알고리즘입니다. 이는 사용자가 항상 동일한 서버에 연결되도록 보장하는 방법입니다.

Sticky Sessions

일부 애플리케이션의 경우, 연결하는 사용자가 항상 동일한 서버에 연결되어야 하는 요구사항이 있습니다. ‘스티키 세션(sticky sessions)’과 이를 필요로 하는 백엔드에서 appsession 매개변수를 사용함으로써 이러한 지속성을 달성할 수 있습니다.

Processing Health Checks

HAProxy는 백엔드 서버의 요청 처리 능력을 확인할 수 있는 방법이 필요합니다. 이는 서버가 오프라인 상태가 될 때 백엔드에서 해당 서버를 제거하는 역할을 합니다. TCP 연결을 시도하는 기본 ‘헬스 체크(health check)’가 실행됩니다. 이는 구성된 IP 주소와 포트에서 수신 대기함으로써 수행됩니다.

서버에 대한 헬스 체크가 통과하지 못하면, 해당 서버는 전송된 요청을 처리할 수 없습니다. 그 시점에서 서버는 백엔드에서 자동으로 비활성화되며, 다시 정상적으로 작동(정상 상태)할 때까지 트래픽이 더 이상 전달되지 않습니다. 그러나 특정 상황에서는 기본 헬스 체크를 통해 서버의 상태를 확인하는 것만으로는 불충분할 수 있습니다.

Alternate Solutions

HAProxy는 귀하의 특정 요구사항에 비해 너무 복잡할 수 있습니다. 이 경우, 더 효율적일 수 있는 몇 가지 좋은 대안이 있습니다:

• Nginx: 이는 로드 밸런싱 및 프록시 목적으로 활용할 수 있는 안정적이고 빠른 웹 서버입니다. 실제로 Nginx는 압축 및 캐싱 기능을 활용하는 HAProxy와 함께 자주 사용됩니다.
• Linux Virtual Servers (LVS): 이는 많은 Linux 시스템에 포함되어 있는 간단한 레이어 4 로드 밸런서입니다.

High Availability

지금까지 레이어 4 및 레이어 7 로드 밸런싱에 대해 이야기했습니다. 두 가지 모두 로드 밸런서를 사용하여 여러 백엔드 서버 중 어느 서버가 사용자의 요청에 응답할지 결정합니다. 하지만 로드 밸런서의 한계를 염두에 두는 것이 중요합니다. 즉, 단일 장애점(single point of failure)이 될 수 있다는 점입니다. 이는 로드 밸런서가 다운되거나 사용자 요청으로 과부하가 걸리면 각각 다운타임이나 요청 처리 지연이 발생함을 의미합니다. 그러나 HA(고가용성) 구성은 단일 장애점이 없는 인프라를 제공합니다. 이는 시스템 아키텍처의 모든 수준에서 이중화를 도입하여 서버 장애로 인한 다운타임 발생을 방지합니다. 로드 밸런서가 백엔드의 이중화를 촉진하는 데 도움이 되지만, 로드 밸런서 자체도 이중화를 구현해야 합니다.

다음 다이어그램은 고가용성 구성의 기본 형태를 보여줍니다:

이 인프라에는 고정 IP 주소에 연결된 여러 로드 밸런서(하나는 활성(active), 나머지는 대기(passive))가 있습니다. 상황에 따라 이 IP 주소를 다른 서버로 다시 매핑할 수 있습니다. 사용자 요청은 외부 IP 주소를 통해 현재 활성화된 로드 밸런서로 전달됩니다. 해당 로드 밸런서가 오프라인 상태인 경우, 페일세이프(failsafe) 메커니즘이 상태를 감지하여 대기 서버에 IP 주소를 재할당합니다.

Conclusion

로드 밸런싱에 대한 기본적인 이해와 HAProxy가 시스템의 로드 밸런싱 요구 사항을 충족할 수 있는 몇 가지 방법에 대한 지식은 현재 서버 환경의 신뢰성과 성능을 최적화하는 데 있어 탄탄한 기반을 제공할 것입니다. 또한 저희 튜토리얼인 Nginx HTTP 프록시, 로드 밸런싱, 버퍼링 및 캐싱: 개요 을 통해 Nginx의 로드 밸런싱 특성에 대해 자세히 알아보실 수 있습니다.

즐거운 컴퓨팅 되세요!