[편집자 주 – 이 게시물은 2021년 6월 기준 NGINX Plus 및 Azure 부하 분산 서비스에서 지원하는 기능을 반영하도록 업데이트되었습니다. 또한 게시물의 원본 버전에서 언급된 별도의 동적 구성 모듈을 대체하며 더 이상 사용되지 않도록 하는 NGINX Plus API에 대한 내용도 포함되어 있습니다.]
Microsoft Azure를 사용하는 고객에게는 다음과 같은 세 가지 부하 분산 옵션이 있습니다. NGINX Plus, Azure 부하 분산 서비스 또는 NGINX Plus와 Azure 부하 분산 서비스를 함께 사용하는 것입니다. 이 게시물에서는 적절한 옵션을 결정하는 데 필요한 정보를 제공하고, NGINX Plus를 Azure Load Balancer와 함께 사용하여 풍부한 계층 7 기능을 갖춘 고가용성 HTTP 부하 분산 장치를 구현하는 방법도 설명합니다.
개요
Microsoft Azure는 사용자에게 두 가지 부하 분산 장치 옵션을 제공합니다. 기본적인 TCP/UDP 부하 분산(계층 4, 네트워크 계층)을 위한 Azure Load Balancer와 HTTP/HTTPS 부하 분산(계층 7, 애플리케이션 계층)을 위한 Azure Application Gateway입니다. 이러한 솔루션은 간단한 사용 사례에는 적합하지만, NGINX Plus에서 기본으로 제공되는 여러 기능을 지원하지 않습니다.
다음은 NGINX Plus와 Azure 부하 분산 제품을 전반적으로 비교한 내용입니다:
| 기능 | NGINX Plus | Azure Load Balancer | Azure Application Gateway | NGINX Plus 및 Azure Load Balancer |
|---|---|---|---|---|
| HTTP 및 HTTPS 부하 분산 | ✅ | ❌ | ✅ | ✅ |
| HTTP/2 부하 분산 | ✅ | ❌ | ✅ | ✅ |
| WebSocket 부하 분산 | ✅ | ❌ | ✅ | ✅ |
| TCP/UDP 부하 분산 | ✅ | ✅ | ❌ | ✅ |
| 부하 분산 방식 | 고급 | 단순 | 단순 | 고급 |
| 세션 지속성 | 고급 | 단순 | 단순 | 고급 |
| HTTP 상태 확인 | 고급 | 단순 | 단순 | 고급 |
| TCP/UDP 상태 확인 | 고급 | 단순 | ❌ | 고급 |
| SSL/TLS 종료 | ✅ | ❌ | ✅ | ✅ |
| 요청 속도 및 연결 수 제한 | ✅ | ❌ | ❌ | ✅ |
| URL 재작성 및 리디렉션 | ✅ | ❌ | ✅ | ✅ |
| URL 요청 매핑 | ✅ | ❌ | ✅ | ✅ |
| 액티브-액티브 NGINX Plus 클러스터 | ❌ | ❌ | ❌ | ✅ |
이제 NGINX Plus와 Azure 부하 분산 서비스의 몇 가지 차이점과 각각의 고유한 기능, 그리고 NGINX Plus와 Azure 부하 분산 장치를 함께 활용하는 방법을 살펴보겠습니다.
NGINX Plus와 Azure 부하 분산 서비스 비교
부하 분산 방식
NGINX Plus는 기본 라운드 로빈 방식 외에도 여러 가지 부하 분산 방식을 제공합니다:
- 최소 연결 – 각 요청은 활성 연결 수가 가장 적은 서버로 전송됩니다.
- 최소 시간 – 각 요청은 평균 지연 시간과 활성 연결 수를 가중 조합하여 계산한 점수가 가장 낮은 서버로 전송됩니다.
- IP 해시 – 각 요청은 요청의 소스 IP 주소에 따라 결정된 서버로 전송됩니다.
- 일반 해시 – 각 요청은 사용자 정의 키에 따라 결정된 서버로 전송됩니다. 이 키에는 텍스트와 NGINX 변수를 원하는 대로 조합하여 포함할 수 있습니다. 예를 들어
소스IP주소및소스포트헤더 필드나 URI에 해당하는 변수를 사용할 수 있습니다. - 랜덤 – 각 요청은 무작위로 선택된 서버로 전송됩니다.
two매개변수를 포함하면 NGINX Plus는 두 서버를 무작위로 선택한 다음, 구성에 따라 최소 연결 알고리즘(기본값) 또는 최소 시간 알고리즘을 사용하여 둘 중 하나를 선택합니다.
각 메서드는 각 백엔드 서버에 서로 다른 가중치 값을 할당하여 확장할 수 있습니다. 메서드에 대한 자세한 내용은 NGINX Plus 관리자 가이드를 참조하세요.
Azure Load Balancer는 한 가지 부하 분산 방식인 해시를 제공하며, 기본적으로 소스 IP 주소, 소스 포트, 대상 IP 주소, 대상 포트, 프로토콜 헤더 필드를 기반으로 한 키를 사용하여 백엔드 서버를 선택합니다.
Azure Application Gateway는 라운드 로빈 방식만 제공합니다.
세션 지속성
세션 지속성, 또는 고정 세션이나 세션 어피니티라고도 하며, 백엔드 서버 간에 클라이언트 상태가 공유되지 않아 애플리케이션에서 특정 클라이언트의 모든 요청을 동일한 백엔드 서버로 계속 보내야 할 때 필요합니다.
NGINX Plus는 세 가지 고급 세션 지속성 방식을 지원합니다:
- 고정 쿠키 – NGINX Plus는 특정 클라이언트에 대한 업스트림 그룹의 첫 번째 응답에 세션 쿠키를 추가합니다. 이 쿠키는 요청을 처리하는 데 사용된 백엔드 서버를 식별합니다. 클라이언트는 이후 요청에 이 쿠키를 포함하며, NGINX Plus는 이를 사용하여 클라이언트 요청을 동일한 백엔드 서버로 전달합니다.
- Sticky Learn – NGINX Plus는 요청과 응답을 모니터링하여 세션 식별자(일반적으로 쿠키)를 찾고, 이를 사용해 세션의 후속 요청을 처리할 서버를 결정합니다.
- 고정 경로 – 경로 값과 백엔드 서버 간의 매핑을 구성하면 NGINX Plus가 요청에서 경로 값을 모니터링하고 일치하는 백엔드 서버를 선택하도록 할 수 있습니다.
NGINX Plus는 위에서 설명한 부하 분산 방식 중 두 가지로 구현되는 기본적인 세션 지속성 방식 두 가지도 제공합니다:
Azure Load Balancer는 NGINX Plus 해시 방식과 동등한 기능을 지원하지만, 키로 사용할 수 있는 헤더 필드는 특정 조합의 소스 IP 주소, 소스 포트, 대상 IP 주소, 대상 포트 및 프로토콜로 제한됩니다.
Azure Application Gateway는 지원합니다 NGINX Plus 고정 쿠키 방식과 동등한 기능을 제공하지만 다음과 같은 제한 사항이 있습니다. 쿠키 이름, 만료 날짜, 도메인, 경로 또는 HttpOnly나 Secure 쿠키 속성은 구성할 수 없습니다.
참고: Azure Load Balancer, NGINX Plus IP Hash 방식 또는 키에 Source IP Address가 포함된 NGINX Plus Hash 방식을 사용하는 경우, 세션이 유지되는 동안 클라이언트의 IP 주소가 동일하게 유지되어야만 세션 지속성이 올바르게 작동합니다. 예를 들어 모바일 클라이언트가 WiFi 네트워크에서 셀룰러 네트워크로 전환하면 IP 주소가 달라질 수 있습니다. 요청이 계속 동일한 백엔드 서버로 전달되도록 하려면 위에 나열된 고급 세션 지속성 방식 중 하나를 사용하는 것이 좋습니다.
상태 확인
Azure Load Balancer와 Azure Application Gateway는 기본적인 애플리케이션 상태 검사를 지원합니다. 부하 분산 장치가 요청할 URL을 지정할 수 있으며, 예상한 HTTP 200 반환 코드를 수신하면 백 엔드 서버가 정상 상태인 것으로 간주합니다. 상태 검사 빈도와 서버가 비정상 상태로 간주되기까지의 제한 시간을 지정할 수 있습니다. Azure Application Gateway에서는 예상 응답 코드를 사용자 지정하고 응답 본문의 내용과 일치하는지도 확인할 수 있습니다.
NGINX Plus는 이 기능을 고급 상태 확인으로 확장합니다. 사용할 URL을 지정하는 것 외에도 NGINX Plus를 사용하면 요청에 헤더를 삽입하고 다양한 응답 코드를 확인할 수 있으며, 응답의 헤더와 본문을 모두 검사할 수 있습니다.
NGINX Plus에서 이와 관련해 유용한 기능은 슬로우 스타트입니다. NGINX Plus는 신규 서버나 최근에 복구된 서버가 연결로 인해 과부하되지 않도록 부하를 서서히 늘립니다. 이 기능은 백엔드 서버에 일정한 준비 시간이 필요하고, 정상 상태로 확인되자마자 전체 트래픽 할당량이 전달되면 장애가 발생할 수 있는 경우에 유용합니다.
NGINX Plus는 TCP 및 UDP 서버에 대한 상태 확인도 지원하며, 이를 통해 전송할 문자열과 응답에서 확인할 문자열을 지정할 수 있습니다.
Azure Load Balancer는 TCP 상태 확인을 지원하지만 이러한 수준의 모니터링은 제공하지 않습니다.
SSL/TLS 종료
NGINX Plus는 SSL/TLS 종료를 지원하며, Azure Application Gateway도 지원합니다. Azure Load Balancer는 지원하지 않습니다.
연결 및 속도 제한
NGINX Plus에서는 NGINX Plus 인스턴스로 들어오고 나가는 트래픽을 제어하기 위해 여러 제한을 구성할 수 있습니다. 여기에는 인바운드 연결, 백엔드 노드에 대한 연결, 인바운드 요청 속도, 그리고 NGINX Plus에서 클라이언트로의 데이터 전송 속도 제한이 포함됩니다.
Azure Application Gateway와 Azure Load Balancer는 속도 또는 연결 제한을 지원하지 않습니다. 하지만 다른 Azure 서비스를 사용하여 속도 제한을 구성하고 활성화할 수 있습니다.
프로토콜 지원 및 URL 재작성과 리디렉션
NGINX Plus, Azure Application Gateway 및 Azure Load Balancer는 모두 다음을 지원합니다:
- HTTP/2 – NGINX Plus는 2016년부터 클라이언트의 HTTP/2 요청을 수락해 왔습니다. Azure는 이보다 최근에 WebSocket 지원을 추가했습니다.
- WebSocket – NGINX Plus는 2014년부터 클라이언트의 WebSocket 연결을 수락해 왔습니다. Azure는 이보다 최근에 WebSocket 지원을 추가했습니다.
- URL 재작성 및 요청 리디렉션 – 요청이 백엔드 서버로 전달되기 전에 요청의 URL을 변경할 수 있습니다. 즉, 클라이언트에 공개된 URL을 수정하지 않고도 내부적으로 요청 경로와 파일 위치를 변경할 수 있습니다. 예를 들어 HTTP 요청의 스킴을 HTTPS로 변경하여 요청을 리디렉션할 수도 있습니다.
Azure 부하 분산 서비스를 사용하는 NGINX Plus
Azure Load Balancer 및 Azure Traffic Manager와 함께 사용하면 NGINX Plus는 풍부한 계층 7 기능을 갖춘 고가용성 부하 분산 솔루션이 됩니다.
액티브-액티브 고가용성
Azure Load Balancer를 사용하여 가용성 집합의 여러 NGINX Plus 인스턴스에 부하를 분산하면, 한 지역 내에서 고가용성 부하 분산 장치를 구축할 수 있습니다.
NGINX Plus 자동 확장
평균 CPU 사용량을 기준으로 NGINX Plus 인스턴스의 자동 크기 조정을 설정할 수 있습니다. NGINX Plus 인스턴스를 호스팅하는 Azure Cloud Service에서 가용성 집합을 생성하면 됩니다. NGINX Plus 구성 파일이 동기화되도록 별도로 관리해야 합니다.
백엔드 인스턴스 자동 확장
평균 CPU 사용량을 기준으로 백엔드 인스턴스의 자동 확장을 설정할 수도 있습니다. 백엔드 인스턴스를 호스팅하는 Azure Cloud Service에서 가용성 집합을 생성하면 됩니다. NGINX Plus 구성에서 백엔드 인스턴스를 추가하거나 제거하는 작업은 NGINX Plus API를 통해 수행할 수 있으며, 이를 직접 관리해야 합니다.
NGINX Plus 구성 업데이트를 자동화하려면(Availability Sets와 함께 사용하거나 NGINX Plus를 단독으로 사용하는 경우 모두), 서비스 검색 시스템에 DNS 인터페이스가 있다면 NGINX Plus API 또는 DNS를 통해 해당 시스템을 NGINX Plus와 통합할 수 있습니다. 널리 사용되는 서비스 검색 시스템과 NGINX Plus를 함께 사용하는 방법을 다룬 블로그 게시물을 확인해 보세요:
- Consul의 DNS SRV 레코드를 사용한 NGINX Plus 서비스 디스커버리
- Consul API를 사용한 NGINX Plus 서비스 검색
- etcd를 사용한 NGINX Plus 서비스 검색
- ZooKeeper를 사용한 NGINX Plus의 서비스 검색
Azure Traffic Manager와의 통합
전 세계에 분산된 환경에서는 Azure Traffic Manager를 사용하여 여러 지역에 클라이언트 트래픽을 분산할 수 있습니다.
Azure 부하 분산 서비스의 추가 기능
Azure Load Balancer와 Application Gateway는 Azure Cloud에서 관리되며, 둘 다 고가용성 부하 분산 솔루션을 제공합니다.
NGINX Plus에서는 사용할 수 없는 Azure Load Balancer의 기능으로 소스 NAT가 있습니다. 이 기능을 사용하면 백엔드 인스턴스에서 나가는 트래픽의 소스 IP 주소가 부하 분산 장치의 소스 IP 주소와 동일하게 설정됩니다.
Azure Load Balancer는 Azure Cloud의 자동 크기 조정 기능을 사용할 때 자동 재구성을 제공합니다.
요약
로드 밸런싱 요구 사항이 단순하다면 Azure의 로드 밸런싱 제품이 좋은 솔루션이 될 수 있습니다. 요구 사항이 더 복잡해지면 NGINX Plus가 좋은 선택입니다. NGINX Plus 인스턴스의 고가용성을 위해 NGINX Plus를 단독으로 사용하거나 Azure Load Balancer와 함께 사용할 수 있습니다.
Microsoft Azure에서 NGINX Plus를 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.
관련 블로그 게시물
시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.
F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.
진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.
NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.
Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.