NGINX Plus 및 Microsoft Azure의 Load Balancer 비교

Microsoft Azure 를 사용하는 고객에게는 Load Balancing을 위한 세 가지 옵션이 있습니다. NGINX Plus, Azure Load Balancing 서비스 또는 NGINX Plus와 함께 사용할 수 있습니다. 이 포스트는 결정을 내리는 데 필요한 정보를 충분하게 제공하는 것을 목표로 하며, 또한 NGINX Plus를 Azure Load Balancer와 함께 사용하여 풍부한 Layer 7 기능을 갖춘 고가용성 HTTP Load Balancer를 제공하는 방법을 보여줍니다.

목차

1. Microsoft Azure 개요
2. NGINX Plus와 Azure Load Balancing 서비스 비교
2-1. Load Balancing 방법
 2-2. 세션 지속성
2-3. 헬스 체크(Health Checks)
2-4. SSL/TLS Termination
2-5. 연결 및 속도 제한
2-6. 프로토콜 지원 및 URL Rewriting 및 Redirecting
3. Azure Load Balancing 서비스가 포함된 NGINX Plus
 3-1. Active-Active 고가용성(High Availability)
3-2. Autoscaling NGINX Plus
3-3. Autoscaling Backend 인스턴스
3-4. Azure 트래픽 관리자와 통합
4. Azure Load Balancing 서비스의 추가 기능
5. 요약

1. Microsoft Azure 개요

Microsoft Azure 는 사용자에게 기본 TCP/UDP Load Balancing을 위한 Azure Load Balancer(Layer 4, 네트워크 계층) 및 HTTP/HTTPS Load Balancing을 위한 Azure Application Gateway(Layer 7, 애플리케이션 계층)의 두 가지 Load Balancer 장치를 사용자에게 제공합니다. 이러한 솔루션은 단순한 사용 사례에 적합하지만 NGINX Plus와 함께 표준으로 제공되는 많은 기능을 제공하지 않습니다.

다음은 NGINX Plus와 Azure Load Balancing 제품 간의 일반적인 비교입니다.

FeatureNGINX PlusAzure Load BalancerAzure Application GatewayNGINX Plus & Azure Load Balancer
HTTP 및 HTTPS Load Balancing✅❌✅✅
HTTP/2 Load Balancing✅❌✅✅
WebSocket Load Balancing✅❌✅✅
TCP/UDP Load Balancing✅✅❌✅
Load Balancing 방법고급
(Advanced)		단순
(Simple)		단순
(Simple)		고급
(Advanced)
세션(Session) 지속성고급
(Advanced)		단순
(Simple)		단순
(Simple)		고급
(Advanced)
HTTP 헬스 체크(Health Checks)고급
(Advanced)		단순
(Simple)		단순
(Simple)		고급
(Advanced)
TCP/UDP 헬스 체크(Health Checks)고급
(Advanced)		단순
(Simple)		❌고급
(Advanced)
SSL/TLS 종료✅❌✅✅
속도 및 연결 제한✅❌❌✅
URL rewriting 및 redirecting✅❌✅✅
URL 요청 매핑✅❌✅✅
Active-Active NGINX Plus 클러스터❌❌❌✅

이제 NGINX Plus와 Azure Load Balancing 서비스 간의 몇 가지 차이점, 고유한 기능, NGINX Plus와 Azure Load Balancer가 함께 작동하는 방법에 대해 알아보겠습니다.

2. NGINX Plus와 Azure Load Balancing 서비스 비교

2-1. Load Balancing 방법

NGINX Plus는 기본 라운드 로빈(Round Robin) 방법 외에 여러 가지 Load Balancing 방법을 제공합니다.

  • 최소 연결(Least Connections) – 각 요청은 활성 연결 수가 가장 적은 서버로 전송됩니다.
  • 최소 시간(Least Time) – 각 요청은 평균 대기 시간과 최소 활성 연결 수의 가중 조합으로 계산된 점수가 가장 낮은 서버로 전송됩니다.
  • IP 해시(Hash) – 각 요청은 요청의 Source IP 주소에 의해 결정된 서버로 전송됩니다.
  • 일반 해시(Hash) – 각 요청은 텍스트및 NGINX 변수(예: 원본 IP 주소 및 원본 포트 헤더 필드 변수 또는 URI)의 모든 조합을 포함할 수 있는 사용자 정의 키(Key)에서 결정된 서버로 전송됩니다.
  • 랜덤(Random) – 각 요청은 무작위로 선택된 서버로 전송됩니다. 두 개의 매개변수가 포함된 경우 NGINX Plus는 무작위로 두 개의 서버를 선택한 다음 구성된 대로 최소 연결(Least Connections) 알고리즘(기본값) 또는 최소 시간(Least Time)을 사용하여 선택합니다.

각 Backend 서버에 서로 다른 가중치를 값을 할당하여 모든 방법을 확장할 수 있습니다.

Azure Load Balancer는 기본적으로 Source IP 주소, Source Port, Destination IP 주소, Destination Port 및 프로토콜 헤더 필드를 기반으로 하는 키(Key)를 사용하여 Backend 서버를 선택하는 하나의 Load Balancing 방법인 해시(Hash)를 제공합니다.

Azure Application Gateway는 라운드 로빈(Round Robin) 방식만 제공합니다.

2-2. 세션 지속성

세션 지속성(Sticky Session 또는 Session Affinity라고도 합니다.)은 클라이언트 상태가 Backend 서버 간에 공유되지 않기 때문에 특정 클라이언트의 모든 요청을 동일한 Backend 서버로 계속 보내야 하는 애플리케이션에 필요합니다.

NGINX Plus는 세 가지 고급 세션 지속성 방법을 지원합니다.

  • Sticky Cookie – NGINX Plus는 지정된 클라이언트에 대한 Upstream 그룹의 첫 번째 응답에 세션 쿠키(Cookie)를 추가합니다. 이 쿠키는 요청을 처리하는 데 사용된 Backend 서버를 식별합니다. 클라이언트는 후속 요청에 이 쿠키를 포함하며 NGINX Plus는 이를 사용하여 클라이언트 요청을 동일한 Backend 서버로 보냅니다.
  • Sticky Learn – NGINX Plus는 요청과 응답을 모니터링하여 세션 식별자(일반적으로 쿠키)를 찾고 이를 사용하여 세션의 후속 요청에 대한 서버를 결정합니다.
  • Sticky Route – NGINX Plus가 Route 값에 대한 요청을 모니터링하고 일치하는 Backend 서버를 선택하도록 경로 값과 Backend 서버 간의 매핑을 구성할 수 있습니다.

또한 NGINX Plus는 위에서 설명한 Load Balancing 방법으로 구현된 두 가지 기본 세션 지속 방법을 제공합니다.

  • IP Hash – Backend 서버는 요청 IP 주소로 결정됩니다.
  • Hash – Backend 서버는 Source IP 주소 및 Source Port와 같은 사용자 정의 Key 또는 URI에서 결정됩니다.

Azure Load Balancer는 키(Key)가 Source IP 주소, Source Port, Destination IP 주소, Destination Port 및 프로토콜 헤더 필드의 특정 조합으로 제한되지만 NGINX Plus Hash Method와 동등한 기능을 지원합니다.

Azure Application Gateway는 쿠키 이름, 만료 날짜, 도메인, 경로 또는 HttpOnly 또는 보안 쿠키 특성을 구성할 수 없다는 제한 사항이 있는 NGINX Plus Sticky Cookie 방법과 동등한 기능을 지원합니다.

Note: Azure Load Balancer, NGINX Plus IP Hash 방식 또는 Source IP 주소가 키(Key)에 포함된 NGINX Plus Hash 방식을 사용하는 경우 클라이언트의 IP 주소가 세션 전체에 걸쳐 동일하게 유지되는 경우에만 세션 지속성이 올바르게 작동합니다. 예를 들어 모바일 클라이언트가 WiFi 네트워크에서 셀룰러(LTE) 네트워크로 전환하는 경우와 같이 항상 그런 것은 아닙니다. 요청이 계속해서 동일한 Backend 서버에 도달하도록 하려면 위에 나열된 고급 세션 지속성 방법 중 하나를 사용하는 것이 좋습니다.

2-3. 헬스 체크(Health Checks)

Azure Load Balancer 및 Azure Application Gateway는 기본 애플리케이션 헬스 체크(Health Check)를 지원합니다. Load Balancer가 요청하는 URL을 지정할 수 있으며, 예상되는 HTTP 200 반환 코드를 수신하면 Backend 서버가 정상인 것으로 간주합니다. 서버가 비정상으로 간주되기 전에 헬스 체크 빈도와 제한 시간을 지정할 수 있습니다. Azure Application Gateway를 사용하면 예상 응답 코드를 사용자 정의하고 응답 본문의 콘텐츠와 일치시킬 수도 있습니다.

NGINX Plus는 고급 헬스 체크로 이 기능을 확장합니다. 사용할 URL을 지정하는 것 외에도 NGINX Plus를 사용하면 요청에 헤더를 삽입하고 다른 응답 코드를 찾고 응답의 헤더와 본문을 모두 검사할 수 있습니다.

NGINX Plus의 유용한 관련 기능은 Slow Start입니다. NGINX Plus는 새 서버 또는 최근에 복구된 서버로 Load를 천천히 증가시킵니다.이 기능은 Backend 서버에 준비 시간을 제공하 정상으로 표시되는 즉시 전체 트래픽 공유가 제공됩니다.

NGINX Plus는 또한 TCP 및 UDP 서버에 대한 헬스 체크를 지원하므로 보낼 문자열과 응답에서 찾을 문자열을 지정할 수 있습니다.

Azure Load Balancer는 TCP 헬스 체크를 지원하지만 이 수준의 모니터링은 제공하지 않습니다.

2-4. SSL/TLS Termination

NGINX Plus는 Azure Application Gateway와 마찬가지로 SSL/TLS Termination를 지원합니다. Azure Load Balancer는 그렇지 않습니다.

2-5. 연결 및 속도 제한

NGINX Plus를 사용하면 NGINX Plus 인스턴스로 들어오고 나가는 트래픽을 제어하기 위해 여러 제한을 구성할 수 있습니다. 여기에는 인바운드(Inbound) 연결 제한, Backend 노드에 대한 연결, 인바운드 요청 속도 및 NGINX Plus에서 클라이언트로의 데이터 전송 속도가 포함됩니다.

Azure Application Gateway 및 Azure Load Balancer는 속도 또는 연결 제한을 지원하지 않습니다. 그러나 다른 Azure 서비스를 사용하여 속도 제한(Rate Limit)을 구성하고 활성화할 수 있습니다.

2-6. 프로토콜 지원 및 URL Rewriting 및 Redirecting

NGINX Plus, Azure Application Gateway 및 Azure Load Balancer는 모두 다음을 지원합니다.

  • HTTP/2 – NGINX Plus는 2016년부터 클라이언트의 HTTP/2 요청을 수락했습니다.
  • WebSocket – NGINX Plus는 2014년부터 클라이언트의 WebSocket 연결을 허용했습니다. Azure는 최근에 WebSocket 지원을 추가했습니다.
  • URL Rewriting 및 Redirect 요청 – 요청이 Backend 서버로 전달되기 전에 요청의 URL을 변경할 수 있습니다. 즉, 클라이언트에 보급되는 URL을 수정하지 않고 내부적으로 요청 경로와 파일 위치를 변경할 수 있습니다. 예를 들어 HTTP 요청 체계를 HTTPS로 변경하여 요청을 Redirect할 수도 있습니다.

3. Azure Load Balancing 서비스가 포함된 NGINX Plus

NGINX Plus를 Azure Load Balancer 및 Azure Traffic Manager와 함께 사용하면 풍부한 Layer 7 기능을 갖춘 고가용성(High Availability) Load Balancer 솔루션이 됩니다.

3-1. Active-Active 고가용성(High Availability)

Azure Load Balancer를 사용하여 가용성 집합(Availability Set)의 NGINX Plus 인스턴스 간에 Load Balancing을 수행하면 지역 내에서 고가용성 Load Balancer를 생성 수 있습니다.

3-2. Autoscaling NGINX Plus

평균 CPU 사용량을 기준으로 NGINX Plus 인스턴스의 Autoscaling을 설정할 수 있습니다. 이는 NGINX Plus 인스턴스를 호스팅하는 Azure Cloud Service에서 가용성 집합(Availability Set)을 생성하여 가능합니다. NGINX Plus 구성 파일의 동기화를 관리 합니다.

3-3. Autoscaling Backend 인스턴스

평균 CPU 사용량을 기준으로 Backend 인스턴스의 Autoscaling을 설정할 수도 있습니다. 이는 Backend 인스턴스를 호스팅하는 Azure Cloud Service에서 가용성 집합(Availability Set)을 생성하여 가능합니다. NGINX Plus API를 사용 가능한 NGINX Plus 구성에서 Backend 인스턴스를 추가하거나 제거하는 데 주의를 기울여야 합니다.

NGINX Plus 구성에 대한 업데이트를 자동화하려면(가용성 집합(Availability Set)과 함께 또는 NGINX Plus를 자체적으로 사용하는 경우) 시스템에 DNS 인터페이스가 있는 경우 NGINX Plus API 또는 DNS를 통해 서비스 검색 시스템을 NGINX Plus와 통합할 수 있습니다.

3-4. Azure 트래픽 관리자와 통합

전역으로 분산된 환경을 원할 경우 Azure Traffic Manager를 사용하여 클라이언트의 트래픽을 여러 지역에 분산할 수 있습니다.

4. Azure Load Balancing 서비스의 추가 기능

Azure Load Balancer 및 Application Gateway는 Azure Cloud에서 관리하며 둘 다 고가용성 Load Balancer 솔루션을 제공합니다.

NGINX Plus에서 사용할 수 없는 Azure Load Balancer의 기능은 Backend 인스턴스에서 아웃바운드(Outbound) 트래픽이 Load Balancer 장치와 동일한 Source IP 주소를 갖는 Source NAT입니다.

Azure Load Balancer는 Azure Cloud의 Autoscaling 기능을 사용할 때 자동 재구성(Automatlc Reconfiguration)을 제공합니다.

5. 요약

Load Balancing 요구 사항이 단순한 경우 Azure Load Balancing 제품이 좋은 솔루션을 제공할 수 있습니다. 요구 사항이 더 복잡해지면 NGINX Plus를 선택하는 것이 좋습니다. NGINX Plus 인스턴스의 고가용성을 위해 NGINX Plus를 단독으로 사용하거나 Azure Load Balancer와 함께 사용할 수 있습니다.

Microsoft Azure 에서 사용되는 솔루션 개요를 확인하고 NGINX Plus 성능을 직접 테스트 및 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.