NGINX Plus 규모 산정 가이드: 테스트 방법

NGINX | 2016년 11월 29일

올해 초 NGINX Plus의 성능을 벤치마킹하고 베어 메탈 서버에 배포하기 위한 사이징 가이드를 작성했습니다. NGINX Open Source와 NGINX Plus는 계층 7 부하 분산(다른 이름으로 애플리케이션 부하 분산)에 널리 사용됩니다.

[편집자 – NGINX Plus의 기능과 하드웨어 비용 및 성능 변화를 반영하기 위해 용량 산정 가이드를 정기적으로 업데이트합니다. 위 링크는 항상 최신 가이드를 가리킵니다.

웹 서버로서 NGINX 및 NGINX Plus의 성능에 대한 자세한 내용은 NGINX 및 NGINX Plus 웹 서버 성능 테스트.]를 참조하세요.

사이징 가이드에서는 다양한 서버 크기에서 NGINX Plus를 실행할 때 기대할 수 있는 성능과 예상 하드웨어 비용을 설명합니다. 이 가이드를 활용하면 NGINX Plus 배포에 적합한 사양을 산정하고, 즉각적인 비용 낭비를 초래하는 과도한 프로비저닝이나 성능 문제를 일으켜 장기적으로 비용 부담을 가중할 수 있는 부족한 프로비저닝을 최대한 방지할 수 있습니다.

고객을 비롯해 당사의 결과를 재현하는 데 관심이 있는 많은 분들이 사이징 가이드에 큰 관심을 보였으며, 당사가 사용한 방법론에 대해서도 여러 질문을 주셨습니다. 이 블로그 게시물에서는 사이징 가이드에 제시된 결과를 얻기 위해 수행한 테스트를 개괄적으로 설명합니다. 여기에는 사용한 토폴로지와 수행한 테스트, 그리고 사이징 가이드에 기재된 가격을 산정한 방법이 포함됩니다.

참고: 용량 산정 가이드는 NGINX Plus용으로 특별히 개발했지만, 누구나 NGINX Plus 구독 없이 테스트를 재현할 수 있도록 테스트에는 NGINX Open Source를 사용했습니다. 이 테스트에서는 NGINX Plus의 향상된 기능을 사용하지 않으므로 NGINX Open Source와 NGINX Plus의 결과는 동일합니다. NGINX Open Source 버전 1.9.7은 대략적으로 대응합니다 NGINX Plus 릴리스 7에.

하지만 테스트 토폴로지에서 리버스 프록시와 백엔드 웹 서버를 더 명확하게 구분하기 위해 전자는 NGINX Plus, 후자는 NGINX(Open Source)라고 지칭합니다.

토폴로지

모든 테스트는 단순한 플랫 레이어 2 네트워크에서 이중 40 GbE 링크로 서로 연결된 세 대의 개별 머신을 사용하여 수행했습니다.

NGINX Plus 성능 테스트에는 표준 백투백투백 토폴로지가 사용되었습니다

클라이언트 머신에서 트래픽을 생성하기 위해 wrk라는 ab(ApacheBench)와 유사한 성능 테스트 도구를 사용했습니다. 다이어그램에 표시된 것처럼 모든 트래픽은 NGINX Plus 리버스 프록시로 전달되었으며, 이 프록시는 연결을 NGINX Open Source 웹 서버 백엔드로 전달했습니다.

사용된 하드웨어

테스트에는 다음 하드웨어를 사용했습니다.

머신 CPU 네트워크 메모리클라이언트 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 물리 코어 36개(또는 HT 코어 72개) 2x Intel XL710 40GbE QSFP+ (rev 01) 16 GB리버스 프록시 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 물리 코어 36개(또는 HT 코어 72개) 4x Intel XL710 40GbE QSFP+ (rev 01) 16 GB웹 서버 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 물리 코어 36개(또는 HT 코어 72개) 2x Intel XL710 40GbE QSFP+ (rev 01) 16 GB

사용된 소프트웨어

테스트에는 다음 소프트웨어를 사용했습니다:

  • 클라이언트 머신에서 실행되는 wrk 버전 4.0.0을 사용하여 NGINX가 프록시할 트래픽을 생성했습니다. 설치 시에는 다음 지침을 따랐습니다.
  • NGINX Open Source 버전 1.9.7은 리버스 프록시 및 웹 서버 머신에서 실행되었습니다. 다음 nginx.org 공식 리포지토리의 지침에 따라 설치했습니다.
  • Ubuntu Linux 14.04.1은 세 대의 머신 모두에서 실행되었습니다.

테스트 방법론

다양한 CPU 수에서 NGINX Plus 리버스 프록시 서버의 성능을 테스트했습니다. NGINX Plus의 worker 프로세스 하나는 CPU 하나를 사용하므로, 다양한 CPU 수에서의 성능을 측정하기 위해 worker 프로세스 수를 변경하면서 worker 프로세스를 2개, 4개, 8개 등으로 늘려 테스트를 반복했습니다. NGINX 아키텍처에 대한 개요는 블로그를 참조하세요.

참고: worker 프로세스 수를 수동으로 설정하려면 worker_processes 지시어를 사용합니다. 기본값은 auto이며, 이 값을 사용하면 NGINX Plus가 CPU 수를 감지하여 CPU당 하나의 worker 프로세스를 실행합니다.

성능 메트릭

다음 지표를 측정했습니다:

  • 초당 요청 수(RPS) – HTTP 요청 처리 능력을 측정합니다. 테스트에서는 각 클라이언트가 연결 유지(keepalive) 연결을 통해 1KB 파일을 요청합니다. 리버스 프록시는 각 요청을 처리한 후 또 다른 연결 유지(keepalive) 연결을 통해 웹 서버로 전달합니다.
  • 초당 SSL/TLS 트랜잭션 수(TPS) – 새로운 SSL/TLS 연결을 처리하는 능력을 측정합니다. 테스트에서는 각 클라이언트가 일련의 HTTPS 요청을 전송하며, 각 요청마다 새 연결을 사용합니다. 리버스 프록시는 요청을 구문 분석한 후 설정된 연결 유지(keepalive) 연결을 통해 웹 서버로 전달합니다. 웹 서버는 각 요청에 대해 0바이트 응답을 반환합니다.
  • 처리량 – NGINX Plus가 HTTP를 통해 1 MB 파일을 제공할 때 유지할 수 있는 처리량을 측정합니다.

테스트 실행

모든 클라이언트 트래픽을 생성하기 위해 wrk를 다음 옵션과 함께 사용했습니다:

  • The -c 옵션은 생성할 TCP 연결 수를 지정합니다. 테스트에서는 이 값을 50개 연결로 설정했습니다.
  • The -d 옵션은 트래픽을 생성할 시간을 지정합니다. 각 테스트는 3분 동안 실행했습니다.
  • The -t 옵션은 생성할 스레드 수를 지정합니다. 여기서는 단일 스레드를 지정했습니다.

각 CPU를 최대한 활용하기 위해 단일 taskset 프로세스를 특정 CPU에 고정할 수 있는 wrk을 사용했습니다. 이 방법은 wrk 스레드 수를 늘리는 것보다 더 일관된 결과를 제공합니다.

초당 요청 수

초당 요청 수(RPS)를 측정하기 위해 다음 스크립트를 실행했습니다:

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1kb.bin &
done

이 테스트에서는 CPU당 wrk 인스턴스 하나씩, 클라이언트 머신에서 총 36개를 실행했습니다. 각 인스턴스는 50개의 TCP 연결을 생성하고, 이를 통해 3분(180초) 동안 1KB 파일을 지속적으로 요청했습니다.

초당 SSL/TLS 트랜잭션 수

초당 SSL/TLS 트랜잭션 수(TPS)를 측정하기 위해 다음 스크립트를 실행했습니다:

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://Reverse-Proxy-Server-IP-address/0kb.bin &
done

이 테스트에서는 이전 테스트와 동일한 값을 -c, -d, -t에 사용하지만, SSL/TLS 연결 처리에 중점을 두기 때문에 두 가지 중요한 차이점이 있습니다:

  • 클라이언트는 각 요청마다 연결을 열고 닫습니다(-H 옵션은 Connection: close HTTP 헤더를 설정합니다).
  • 요청된 파일의 크기는 1KB가 아니라 0(제로)바이트입니다.

처리량

처리량을 측정하기 위해 다음 스크립트를 실행했습니다:

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1mb.bin &
done

첫 번째 테스트와의 유일한 차이점은 파일 크기가 1 MB로 더 크다는 것입니다. 이보다 더 큰 파일 크기(10 MB)를 사용해도 전체 처리량은 증가하지 않는 것으로 나타났습니다.

다중 네트워크 카드

테스트에서는 여러 개의 네트워크 카드를 사용했습니다. 다음과 같이 약간 수정한 스크립트를 사용하여 트래픽이 두 카드에 고르게 분산되도록 했습니다:

for i in `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; do    n=`echo $(($i+number-of-CPUs/2))`;
    taskset -c $i ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-1/1kb.bin &
    taskset -c $n ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-2/1kb.bin &
done

요금

코어 수별 성능 수치를 확보한 후 마지막 단계는 해당 사양을 갖춘 서버의 비용을 산정하는 것이었습니다. 테스트에 사용한 Intel 하드웨어와 유사한 사양의 Dell PowerEdge 서버 가격을 기준으로 삼았습니다. 아래 부록에는 각 서버의 전체 자재 명세와 함께 리버스 프록시 및 웹 서버용 NGINX 전체 구성이 수록되어 있습니다.

부록

Dell 하드웨어 구성

사이징 가이드의 가격은 다음 Dell 하드웨어 구성을 기준으로 합니다.

참고: 표시된 사양과 가격의 서버 모델은 테스트 당시 구매할 수 있었으나, 향후 변경될 수 있습니다.

서버 모델 사양 가격Dell PowerEdge R230 CPU: 2코어 Intel Core I3 6100 3.7GHz, 2C/4T
RAM: 4GB
HDD: 500GB
NIC: Intel X710 2×10 Gbe $1,200CPU: Intel® Xeon® E3‑1220 v5 3.0GHz, 4C/8T
RAM: 4GB
HDD: 500GB
NIC: Intel XL710 2×40 Gbe $1,400Dell PowerEdge R430 CPU: Intel® Xeon® E5‑2630 v3 2.4GHz, 8C/16T
RAM: 4GB
HDD: 500GB
NIC: Intel XL710 2×40 Gbe $2,200CPU: Intel® Xeon® E5‑2630 v3 2.4GHz 2개, 8C/16T
RAM: 8GB
HDD: 500GB
NIC: Intel XL710 2×40 Gbe $3,000Dell PowerEdge R630 CPU: Intel® Xeon® E5‑2697A v4 2.6GHz 2개, 16C/32T
RAM: 8GB
HDD: 500GB
NIC: Intel XL710 2×40 Gbe $8,000CPU: Intel® Xeon® E5‑2699 v3 2.3GHz 2개, 18C/36T
RAM: 8GB
HDD: 500GB
NIC: Intel XL710 2×40 Gbe $11,000

NGINX Plus 리버스 프록시 구성

NGINX Plus에서 다음 구성을 사용했습니다. 리버스 프록시에 사용된 keepalive_timeout 및 keepalive_requests 지시어가 각각 두 세트씩 있다는 점에 유의하세요:

  • SSL/TLS TPS 테스트에서는 NGINX Plus가 초당 처리할 수 있는 SSL/TLS 연결 수를 측정하는 것이 목적이므로, 연결이 단 하나의 요청에 대해서만 열린 상태로 유지되도록 두 지시문의 값을 설정했습니다. SSL/TLS 세션 캐싱도 비활성화했습니다.
  • RPS 테스트에서는 연결이 최대한 오래 유지되도록 지시문을 조정했습니다.

그 외에는 상당히 표준적인 리버스 프록시 서버 구성으로, NGINX Plus가 proxy_pass 지시어를 사용하여 웹 서버로 프록시합니다.

user                 nginx;worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log    off;
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
                    '"$ssl_protocol" ';

    sendfile on;

    # RPS tests
    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    # SSL/TLS TPS tests
    #keepalive_timeout  0;  
    #keepalive_requests 1; 
  
    upstream webserver {
        server Web-Server-IP-address;
    }

    server {
        listen 80;
        listen 443 ssl backlog=102400 reuseport;

        ssl_certificate     /etc/nginx/ssl/rsa-cert.crt;
        ssl_certificate_key /etc/nginx/ssl/rsa-key.key;
        ssl_session_tickets off;
        ssl_session_cache   off;

        root /var/www/html;
            location / {
                proxy_pass http://webserver;
            }
        }
    }
}

NGINX 웹 서버 구성

아래 구성은 NGINX 웹 서버에서 사용되었습니다. 이 서버는 /var/www/html/에서 정적 파일을 제공하며, 이는 root 지시문으로 설정됩니다. 정적 파일은 dd를 사용하여 생성되었습니다. 다음 예에서는 0으로 채워진 1KB 파일을 생성합니다:

dd if=/dev/zero of=1kb.bin bs=1KB count=1

구성:

user                 nginx;
worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log   off;
    include      /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
                    '"$ssl_protocol" ';

    sendfile on;

    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    server {
        listen 80;
        root /var/www/html;
    }
}

NGINX Plus를 직접 사용해 보려면 지금 30일 무료 평가판을 시작하거나, 사용 사례에 대해 논의하려면 문의해 주세요.


공유

작성자 소개

관련 블로그 게시물

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
NGINX | 2023. 11. 30.

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric

이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
NGINX | 2023. 03. 23.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법

앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
NGINX | 2021. 09. 27.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션

개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX | 2021. 07. 06.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법

NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX | 2021. 06. 30.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리

NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
NGINX | 2015. 03. 25.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유

Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.