NGINX 플러스 사이징 가이드: 테스트 방법

올해 초에 우리는 NGINX Plus의 성능을 벤치마킹하고 

베어 메탈 서버에 배포하기 위한 사이징 가이드 를 만들었습니다. 

NGINX 오픈 소스와 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(오픈 소스)를 참조합니다.

토폴로지

모든 테스트는 간단한 평면 2계층 네트워크에서 듀얼 40GbE 링크로 연결된 세 대의 별도 장비를 사용하여 수행되었습니다.

NGINX Plus 성능을 테스트하기 위해 표준 백투백투백 토폴로지가 사용되었습니다.

클라이언트 머신에서 트래픽을 생성하기 위해 (ApacheBench) wrk와 유사한 성능 테스트 도구인 를 사용했습니다 ab. 

다이어그램에서 볼 수 있듯이 모든 트래픽은 NGINX Plus Reverse Proxy 로 전달되었고 , 

여기서 NGINX Open Source Web Server 백엔드로 연결이 전달되었습니다.

사용된 하드웨어

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

사용된 소프트웨어

우리는 테스트를 위해 다음 소프트웨어를 사용했습니다.

• wrk클라이언트 머신에서 실행되는 버전 4.0.0은 NGINX가 프록시한 트래픽을 생성했습니다. 
• 우리는 이 지침 에 따라 설치했습니다 .
• NGINX 오픈 소스 버전 1.9.7은 역방향 프록시 및 웹 서버 머신에서 실행되었습니다. 
• 우리는 이 지침 에 따라 nginx.org 의 공식 저장소에서 설치했습니다 .
• 세 대의 기계 모두에서 Ubuntu Linux 14.04.1이 실행되었습니다.

테스트 방법론

우리는 다양한 수의 CPU로 NGINX Plus 역방향 프록시 서버의 성능을 테스트했습니다. 

하나의 NGINX Plus worker프로세스는 단일 CPU를 사용하므로 다양한 수의 CPU의 성능을 측정하기 위해 

프로세스 수를 변경하여 두 프로세스, 네 프로세스, 여덟 프로세스 등 worker으로 테스트를 반복했습니다 .

 NGINX 아키텍처 개요는 블로그를 참조하세요 .worker

참고 : 프로세스 수를 worker수동으로 설정하려면 지시어를 사용합니다 

worker_processes. 기본값은 이며 auto, NGINX Plus가 CPU 수를 감지하고 workerCPU당 하나의 프로세스를 실행하도록 지시합니다.

성과 지표

우리는 다음과 같은 측정 항목을 측정했습니다.

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

테스트 실행

모든 클라이언트 트래픽을 생성하려면 wrk다음 옵션을 사용했습니다.

• 이 -c옵션은 생성할 TCP 연결 수를 지정합니다. 테스트를 위해 50개의 연결로 설정했습니다.
• 이 -d옵션은 트래픽을 생성하는 데 걸리는 시간을 지정합니다. 우리는 각각 3분 동안 테스트를 실행했습니다.
• 이 -t옵션은 생성할 스레드 수를 지정합니다. 우리는 단일 스레드를 지정했습니다.

taskset각 CPU를 완전히 활용하기 위해 단일 wrk프로세스를 CPU에 고정할 수 있는 를 사용했습니다. 

이 방법은 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 연결 처리에 초점을 맞추었기 때문에 두 가지 중요한 면에서 다릅니다.

• 클라이언트는 각 요청에 대해 연결을 열고 닫습니다(옵션 은 HTTP 헤더를 -H설정합니다 Connection: close).
• 요청하신 파일의 크기가 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

첫 번째 테스트와의 유일한 차이점은 1MB의 더 큰 파일 크기입니다. 

우리는 더 큰 파일 크기(10MB)를 사용해도 전체 처리량이 증가하지 않는다는 것을 발견했습니다.

여러 네트워크 카드

테스트에서 우리는 여러 네트워크 카드를 사용했습니다. 다음의 약간 수정된 스크립트는 트래픽이 두 카드 간에 고르게 분산되도록 보장했습니다.

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 구성이 있습니다 .

HW

Dell 하드웨어 구성

크기 가이드의 가격은 다음 Dell 하드웨어 구성에 적용됩니다.

참고 : 표시된 사양과 가격의 서버 모델은 테스트를 실행할 당시에는 구입 가능했으나, 향후 변경될 수 있습니다.

NGINX Plus 역방향 프록시 구성

다음 구성은 NGINX Plus Reverse Proxy 에서 사용되었습니다 . 

두 세트의 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를 직접 사용해보려면 저희에게 연락해 사용 사례에 대해 논의해 보세요 .