NGINX Performance 테스트, 가상 환경에서의 비교
On-Premises에서 작업을 실행하는 경우, 베어 메탈(Bare metal) 또는 가상(hypervisor) 환경에서 실행할지 선택할 수 있습니다.
성능 및 확장 요건을 충족시키는 최적 및 가장 저렴한 On-Premises 솔루션을 결정하기 위해, 두 가지 환경에서 NGINX Performance 를 비교하는 Sizing Guide를 제공합니다.
이 포스트에서는 Sizing Guide에 게시된 값에 도달하기 위해 NGINX를 테스트한 방법을 설명합니다. 많은 고객이 쿠버네티스(Kubernetes)에서 앱을 배포하기 때문에, Rancher Kubernetes Engine(RKE) 플랫폼에서 NGINX Ingress Controller를 테스트한 결과와 전통적인 On-Premises 아키텍처에서 NGINX를 실행하는 결과를 비교하는 방법에 대해서도 다룹니다.
목차
1. NGINX Performance 테스트 방법론
1-1. On-premises 아키텍처
1-2. Kubernetes 아키텍처
2. NGINX Performance 테스트 통계 수집
3. NGINX Performance 분석
3-1. On-premises 아키텍처
3-2. Kubernetes 아키텍처
4. 결론
1. 테스트 방법론
NGINX의 성능을 다른 환경에서 측정하고 비교하기 위해 두 개의 아키텍처를 사용했습니다.
각 아키텍쳐에 대해 별도의 테스트 세트를 실행하여 요청당 초당(Requests Per Second, RPS) 및 SSL/TLS 트랜잭션당 초당 (Transactions Per Second, TPS) 이라는 두 가지 핵심 지표를 측정했습니다. 자세한 내용은 측정된 메트릭스(Metrics Collected)를 참조하세요. 두 개의 아키텍쳐에서 데이터를 수집하고 분석함으로써, 각 환경에서 최적의 NGINX 배포 크기에 대한 정확하고 포괄적인 가이드를 제공할 수 있었습니다.
1-1. On-premises 아키텍처
NGINX Performance 테스트는 두 가지 조건에서 시스템 구성 요소(SUT)로 사용되었습니다. 첫 번째는 베어 메탈(bare metal)에서 실행되는 것이고, 두 번째는 하이퍼바이저(hypervisor) 환경입니다. 양쪽 조건 모두에서 4개의 Ixia 클라이언트가 요청을 생성하였으며, NGINX는 이를 4개의 Ixia 웹 서버로 load balanced했습니다. 웹 서버는 각 요청에 대해 128바이트 파일을 반환했습니다.

NGINX Performance 테스트에는 다음과 같은 소프트웨어 및 하드웨어를 사용했습니다.
- Ixia 클라이언트와 웹 서버는 Axia Xcellon-Ultra™ XT80v2 애플리케이션 블레이드에서 IxLoad 소프트웨어를 사용하여 배치되었습니다.
- SUT (System Under Test)는 양쪽 조건에서 모두 Intel NIC가 장착된 PowerEdge 서버에 CentOS 7 운영 체제가 사용되었습니다.
- Hypervisor는 VMWare ESXi 버전 7.0.0을 사용했습니다.
NGINX 구성 파일을 다운로드하여 테스트 환경에서 NGINX를 배치하는 데 사용된 파일을 확인할 수 있습니다.
1-2. Kubernetes 아키텍처
SUT는 Rancher Kubernetes Engine(RKE) bare-metal 플랫폼에서 실행되는 NGINX Ingress Controller (NGINX 오픈소스 기반)였습니다. 네 개의 Ixia 클라이언트가 요청을 생성하며 이를 NGINX Ingress Controller가 백엔드 Kubernetes 배포로 전달했고, 해당 배포는 각 요청에 대해 1KB 파일을 반환하는 웹 서버입니다.

테스트에는 다음과 같은 소프트웨어 및 하드웨어를 사용했습니다.
- Axia Xcellon-Ultra XT80v2 애플리케이션 블레이드와 IxLoad 소프트웨어를 사용하여 배포된 Ixia 클라이언트가 요청을 생성했습니다. Kubernetes 환경에서 Workload를 테스트하였기 때문에, Ixia 웹 서버는 필요하지 않았습니다.
- SUT와 백엔드 애플리케이션을 호스팅하는 노드 모두 CentOS 7 운영 체제를 사용하였습니다. SUT와 백엔드 플리케이션은 인텔 네트워크 인터페이스를 탑재한 두 개의 별도 PowerEdge 서버 노드에서 실행되었습니다.
- NGINX Ingress Controller 버전은 1.11.0입니다.
NGINX Ingress Controller를 Baremetal RKE에 배포하기 위해 적용된 YAML 파일을 다운로드해주세요.
2. NGINX Performance 테스트 통계 수집
두 가지 성능의 통계를 수집하기 위해 테스트를 진행합니다.
- Requests Per Second (RPS), 초당 요청 수 – 고정 기간 동안 평균화된 시간 당 NGINX가 처리할 수 있는 요청 수입니다. 이 경우 Ixia 클라이언트에서 사용된 요청은 http scheme을 사용합니다.
- SSL/TLS Transactions Per Second (TPS), 초당 SSL/TLS 트랜잭션 수 – NGINX가 초당 설정 및 제공할 수 있는 새 HTTPS 연결 수입니다. 이 경우 Ixia 클라이언트에서 사용된 요청은 https scheme을 사용합니다. 우리는 RSA 2048비트 키 크기와 Perfect Forward Secrecy를 사용했습니다.
Ixia 클라이언트는 새 연결마다 일련의 HTTPS 요청을 보냈습니다. Ixia 클라이언트와 NGINX는 안전한 연결을 설정하기 위해 TLS 핸드쉐이크를 수행한 후, NGINX는 요청을 백엔드로 프록시합니다. 요청이 처리된 후 연결이 닫힙니다.
3. NGINX Performance 분석
다음 섹션의 표는 NGINX에서 사용 가능한 다른 CPU 수에 대해 전통적인 및 쿠버네티스 아키텍처에서 달성한 RPS와 SSL TPS 수를 보고합니다.
3-1. On-premises 아키텍처
NGINX의 Baremetal 성능은 가능한 CPU 수가 8개에 다다를 때까지 선형적으로 증가합니다.
8개 이상의 코어가 있을 때, lxia 클라이언트가 충분한 요청을 생성하지 못해 SUT( 시스템 집중 테스트)을 포화시켜 (100% CPU 사용률을 도달함) 테스트를 할 수 없었습니다.
가상화는 Baremetal 대비 약간의 성능 저하를 유발함을 발견했습니다. Hypervisor에서의 CPU 명령어는 Baremetal상에서와 비교하여 더 많은 Clock 주기를 요구하며, 이는 추가적인 Overhead를 유발합니다.
하드웨어 비용 | CPU 코어 | RPS – Baremetal | RPS – Hypervisor | SSL TPS – Baremetal | SSL TPS – Hypervisor |
---|---|---|---|---|---|
$750 | 1 | 48,000 | 40,000 | 800 | 750 |
$750 | 2 | 94,000 | 75,000 | 1,600 | 1,450 |
$1,300 | 4 | 192,000 | 132,000 | 3,200 | 2,900 |
$2,200 | 8 | 300,000 | 280,000 | 5,200 | 5,100 |
3-2. Kubernetes 아키텍처
Kubernetes의 NGINX Ingress Controller 성능은 코어 수를 8개로 확장함에 따라 선형적으로 증가합니다.
표준 아키텍처와 비교한 다음 표의 결과를 보면, Kubernetes에서 NGINX (NGINX Ingress Controller로 실행)를 실행하면 서비스 요청(RPS로 측정)과 같은 네트워크‑바운드 작업에 대한 성능이 크게 저하됩니다. 이는 기타 서비스와의 연결에 사용되는 컨테이너 네트워킹 스택의 기본 구조 때문입니다.
반면에 SSL/TLS 핸드셰이크 (TPS로 측정)와 같은 CPU‑집약 작업에서는 전통적인 환경과 Kubernetes 환경 사이에 성능 차이가 없습니다. 사실 TPS는 Kubernetes에서 조금 더 나은 결과를 보입니다.
게다가, HyperThreading (HT)을 활성화하면 대략 10% 정도의 TPS 증가 효과를 볼 수 있습니다.
Core | RPS | SSL TPS(RSA) | 하이퍼 스레딩을 사용하는 SSL TPS RSA | 하드웨어 비용 |
---|---|---|---|---|
1 | 24,000 | 900 | 1,000 | $750 |
2 | 48,000 | 1,750 | 1,950 | $750 |
4 | 95,000 | 3,500 | 3,870 | $1,300 |
8 | 190,000 | 7,000 | 7,800 | $2,200 |
4. NGINX Performance 테스트 결론
다음은 Workload가 가장 잘 실행되는 환경과 선택한 환경에 대한 성능 영향을 이해하는 데 도움이 되는 주요 내용입니다.
- 네트워크 기반 작업을 수행하는 경우(RPS로 측정), 표준 Bare-metal 환경에서 NGINX를 실행하는 것이 성능에 가장 좋습니다. Kubernetes에서 NGINX Ingress Controller를 실행하는 경우, 환경에서 사용되는 백그라운드 컨테이너 네트워킹 스택 때문에 네트워크 기반 작업에서 가장 많은 성능 비용이 발생합니다.
- Hypervisor를 사용하는 경우, 네트워크 및 CPU-바운드 작업에서 약간의 성능 비용이 발생합니다(RPS는 bare-metal 값의 약 80%).
- CPU 기반 작업(TPS로 측정)을 수행하는 경우, 전통적인 환경과 Kubernetes 환경 간에 거의 성능 차이가 없습니다.
- NGINX의 실험에서는 하이퍼 스레딩이 암호화와 같은 병렬 CPU 기반 작업에서 성능을 대략 10% 향상시켰습니다.
테스트를 복제하거나 환경에서 NGINX 및 NGINX Ingress Controller를 사용해 보고 싶습니까?
NGINX STORE에 문의하여 상담을 받아보십시오.
아레 뉴스레터를 구독하여 NGINX의 최신 소식들을 발 빠르게 받아보세요.
댓글을 달려면 로그인해야 합니다.