NGINX 및 NGINX Plus 성능 테스트

2004년, 최초의 NGINX 오픈소스 버전이 공개된 이후로, NGINX는 고성능 웹사이트의 대명사였습니다.
전 세계의 웹 서버 중 NGINX를 사용하는 사이트가 가장 많으며, 전 세계적으로 3.5억 개 이상의 사이트가 NGINX를 기반으로 운영되고 있습니다. 하지만 NGINX는 실제로 어떻게 성능이 나오는지, 합리적인 가격대에서 어떤 하드웨어 구성이 최상의 성능을 발휘할까요?

NGINX STORE에서는 NGINX Plus Sizing에 대한 가이드를 제공 하고 있습니다.

이러한 자료를 게시한 이후로, NGINX가 얼마나 성능이 우수한지에 대한 정보 요청이 많아졌습니다.
이 포스트에서는 실제 HTTP 및 HTTPS 연결의 Requests Per Second (RPS, 초당 요청 수) 및 Connections Per Second(CPS, 초당 연결 수)와 50개의 전용 채널에서 HTTP 처리량에 대한 자세한 성능 숫자를 제공합니다. 이 결과는 NGINX 오픈소스와 NGINX Plus 둘 다에 적용됩니다. (테스트는 NGINX Plus 전용 기능을 사용하지 않습니다).

해당 포스트의 목표는 이 정보가 예산 및 성능 요구 사항 고려하여 웹 애플리케이션의 현재와 미래의 트래픽을 처리하기 위해 필요한 하드웨어 사양을 결정하는데 도움이 되도록 하는 것입니다.

목차

1. NIGNX 성능 테스트 개요
2. 테스트에 사용된 하드웨어
3. 테스트에 사용된 소프트웨어
4. NGINX 성능 지표 및 분석
 4-1. 초당 요청
 4-2. HTTP 요청에 대한 RPS
 4-3. HTTPS 요청에 대한 RPS
5. 초당 연결
 5-1. HTTPS 요청용 CPS
 5-2. HTTPS 요청용 CPS
6. NGINX 처리량
7. 기타 참고 사항
8. 결론

1. NGINX 성능 테스트 개요

모든 테스트는 간단한 평면 Layer 2 네트워크에서 듀얼(Dual) 40-GbE 링크로 연결된 두 개의 별도 머신을 사용하여 수행되었습니다.

테스트에서 CPU 수를 다양하게 시뮬레이션하기 위해, 우리는 NGINX Worker 프로세스의 수를 변화시켰습니다. 기본적으로, NGINX Worker 프로세스의 실행 수는 NGINX가 실행되는 머신의 사용 가능한 CPU 수와 동일합니다. worker_processes 지시어의 값을 변경하고 NGINX 서비스를 재시작하여 실행되는 NGINX Worker 프로세스의 수를 변경할 수 있습니다. /etc/nginx/nginx.conf 파일에서 이 작업을 수행할 수 있습니다.

클라이언트 트래픽이 HTTPS로 보호되는 테스트의 경우 다음 암호화 매개변수를 사용했습니다.

• ECDHE-RSA-AES256-GCM-SHA384 암호
• 완벽한 순방향 비밀(암호 이름에 ECDHE로 표시됨)
• OpenSSL 1.0.1f

2. 테스트에 사용된 하드웨어

클라이언트와 웹 서버 시스템 모두에서 테스트를 위해 다음 하드웨어를 사용했습니다.

• CPU: 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 36 실제(또는 72 HT) 코어
• 네트워크: 2x Intel XL710 40GbE QSFP+(rev 01)
• 메모리: 16GB

3. 테스트에 사용된 소프트웨어

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

• 클라이언트 머신에서 생성된 트래픽을 NGINX가 프록시한 것입니다. 클라이언트 머신에서 실행되는 wrk의 버전은 4.0.0이며, 이를 설치하기 위해 이 지침을 따랐습니다.
• 웹 서버 머신에서는 NGINX 오픈소스가 사용되었습니다. NGINX STORE의 NGINX 오픈소스 설치 문서를 참고할 수 있습니다.
• 클라이언트 및 웹 서버 머신 모두에는 Ubuntu Linux 14.04.1 이 설치되어 있었습니다.

4. NGINX 웹 서버 성능 지표 및 분석

다음은 테스트에서 얻은 성능 수치입니다. 사용된 명령어는 NGINX STORE의 NGINX Plus Sizing 가이드를 참조하십시오.

4-1. 초당 요청

초당 요청(RPS)은 HTTP 요청을 처리하는 능력을 측정합니다. 각 요청은 클라이언트 기기에서 NGINX로 보내집니다. 이러한 테스트는 암호화되지 않은 HTTP와 암호화된 HTTPS 트래픽 모두에 대해 수행되었습니다.

성능 테스트에서 일반적으로 따르는 규칙에 따라, 해당 포스트에는 4개의 표준 파일 크기를 사용했습니다.

• 0 KB는 상반된 데이터가 없는 ‘빈(empty)’ HTTP 요청 또는 응답을 나타냅니다. 예를 들어 302 오류 코드와 같은 것입니다.
• 1 KB는 작은 CSS 또는 JavaScript 파일 또는 매우 작은 이미지 (예: 작은 아이콘)와 같은 크기입니다.
• 10 KB는 대형 코드 파일, 대형 아이콘 및 작은 이미지 파일과 같은 것을 대략적으로 나타냅니다.
• 100 KB는 대형 코드 파일 및 기타 대형 파일을 나타냅니다.

작은 HTTP 요청을 보내면 더 많은 요청 처리율을 얻을 수 있지만 총 처리량은 적습니다. 반면 큰 HTTP 요청을 보내면 초당 요청 수는 줄어들지만, 대용량 파일 전송을 시작하는 단일 요청이며 완료에 상당한 시간이 걸리므로 더 많은 처리량이 발생합니다.

4-2. HTTP 요청에 대한 RPS

아래 표와 그래프는 CPU의 수와 요청 크기(킬로바이트(KB))에 따른 HTTP 요청 수를 보여줍니다.

대용량 HTTP 요청(테스트에서의 10 KB 및 100 KB 크기)은 조각화되고 처리하는 데 더 많은 시간이 걸립니다. 따라서, 큰 요청의 그래프 라인은 더 평평한 기울기를 가지게 됩니다.

예산과 성능의 균형을 맞출 때, 주목할 만한 것 중 하나는 선의 기울기가 16개 이상의 CPU를 지나면 변경된다는 것입니다. 1 KB와 10 KB 요청 크기에 대해 32개의 CPU를 가진 서버가 36개의 CPU를 가진 서버보다 성능이 같거나 더 좋은 결과를 보였습니다. 리소스 경합은 더 많은 CPU를 추가하는 긍정적인 효과를 점차 무효화시키기 때문입니다. 이러한 결과는 HTTP 트래픽에 대한 일반적인 서버 구성에서 4에서 8 코어의 CPU를 사용하는 것이 총 16개의 CPU까지 추가하는 것으로 큰 이점을 얻을 수 있다는 것을 시사합니다. 그 이후로는 32개의 CPU를 사용하여 이점을 더 이상 얻을 수 없으며, 36개의 CPU로 가더라도 더 이상 성능이 향상되지 않습니다. 하지만 테스트의 결과는 항상 상황에 따라 다를 수 있습니다.

4-3. HTTPS 요청에 대한 RPS

HTTPS는 동일한 하드웨어에서 HTTP에 비해 처리 가능한 초당 요청 수(RPS)가 낮습니다. 이는 기계 간 전송되는 데이터를 보호하기 위해 필요한 데이터 암호화 및 복호화가 계산적으로 많은 비용을 발생시키기 때문입니다.

하지만 인텔 아키텍처의 지속적인 발전은 더 빠른 프로세서와 더 나은 메모리 관리를 갖춘 서버로 이어져, CPU‑bound 암호화 작업에 대한 소프트웨어의 성능이 전용 하드웨어 암호화 장치와 비교하여 지속적으로 개선되고 있습니다.

16개의 CPU에서 HTTPS의 RPS가 HTTP의 RPS보다 약 1/4 낮습니다. 그러나 보통 사용되는 파일 크기에 대해서는 추가 CPU를 사용하는 것이 HTTP보다 더 효과적이며, 최대 36개의 CPU까지 전부 해당됩니다.

5. 초당 연결

초당 연결 (CPS)는 NGINX 가 새로운 TCP 연결을 생성하는 능력을 측정합니다. 클라이언트는 새로운 연결에서 HTTP 또는 HTTPS 요청을 보내며, NGINX는 요청을 구문 분석하고 각 요청에 대해 0바이트 응답을 보냅니다. 요청이 처리된 후 연결이 닫힙니다.

이 테스트의 HTTPS 변형은 SSL 트랜잭션(SSL TPS) 테스트라고도 불립니다.

5-1. HTTP 요청에 대한 CPS

표와 그래프는 다른 수의 CPU에서 HTTP 요청에 대한 CPS를 보여줍니다.

그래프는 x가 CPU 수인 f(x) = √x와 비슷한 형태를 띠고 있습니다. RPS와 마찬가지로 CPS의 증가율은 CPU 수가 약 16개 정도에서 점차 완만해지며, 32개에서 36개로 CPU 수를 늘리면 약간의 성능 저하가 있습니다.

5-2. HTTPS 요청에 대한 CPS

측정한 HTTPS 요청의 CPS를 보여주는 표와 그래프입니다. 시간 제한 때문에 32개의 CPU로 테스트를 실행하지 않았습니다.

CPU 개수가 많아질수록 CPS 증가율이 높아지는 것을 관찰할 수 있습니다. 그래프 라인은 24개의 CPU에서 평평해집니다. SSL의 경우, 하드웨어를 추가하는 것이 문제를 해결하는 데 효과적입니다.

6. NGINX 처리량

이러한 테스트는 NGINX가 180초 동안 유지할 수있는 HTTP 요청의 처리량 (Gbps)을 측정합니다.

이러한 테스트는 NGINX가 180초 동안 유지할 수있는 HTTP 요청의 처리량(Gbps)을 측정합니다. 처리량은 클라이언트 머신에서 발생하는 HTTP 요청의 크기에 비례합니다. 더 큰 파일 크기로 요청을 보낼수록 NGINX는 더 높은 처리량을 얻게됩니다. 그러나 성능은 대략 8개의 CPU에서 피크에 도달하며 처리량 중심 작업에서 더 많은 CPU가 반드시 이점이 되는 것은 아닙니다.

7. NGINX 성능 테스트에 관한 기타 참고 사항

테스트 및 결과에 대한 몇 가지 참고 사항입니다.

• 테스트한 CPU에는 Hyper Threading이 가능했습니다.
  이는 추가적인 NGINX Worker 프로세스가 Hyper Threading CPU의 전체 용량을 활용할 수 있음을 의미합니다.
  여기서 보고된 테스트에서는 Hyper Threading을 활성화하지 않았지만, 별도의 테스트에서 Hyper Threading으로 인한 성능 향상을 확인했습니다. 특히 Hyper Threading은 SSL TPS를 약 50% 향상시켰습니다.
• 여기서 제시한 수치는 OpenSSL 1.0.1을 사용한 것입니다. 우리는 또한 OpenSSL 1.0.2에서도 테스트를 진행하였으며, 약 2배의 성능 향상을 확인했습니다. OpenSSL 1.0.1은 여전히 널리 사용되고 있지만, 보안 및 성능 개선을 위해 OpenSSL 1.0.2로 이전하는 것이 좋습니다.
• NGINX팀은 또한 타원 곡선 암호(ECC, Elliptic Curve Cryptography)도 테스트했지만, 여기서는 RSA를 사용한 결과를 제시하였습니다. 암호화에 있어 RSA는 여전히 ECC보다 널리 사용되고 있으며, ECC는 전력 소비 효율성이 필요한 모바일에 자주 배포됩니다.
  NGINX팀은 표준 RSA 인증서 대비 ECC를 사용했을 때 2배에서 3배의 성능 향상을 확인했으며, ECC 도입을 고려해보시기를 권장합니다.

OpenSSL 1.0.2로 이전하고 ECC로 전환하는 것이 매우 강력한 성능 향상을 가져올 수 있습니다.
또한, NGINX팀의 결과는 현재 4-CPU 또는 8-CPU 서버를 사용하고 있다면, 16개 CPU 또는 심지어 SSL의 경우 32개 CPU로 전환하는 것이 극적인 개선을 가져올 수 있다는 것을 시사합니다.

8. 결론

HTTP 및 HTTPS 연결에서 RPS 및 CPS에 대한 성능 테스트 결과와 50개의 전용 채널에서 HTTP 처리량을 분석했습니다. NGINX STORE에서 발행된 포스트의 정보를 사용하여 주어진 예산 및 성능 요구 사항에 따라 사이트에서 현재 및 미래의 트래픽을 처리하는 데 필요한 하드웨어 사양을 결정하는 데 도움을 받으십시오.

프로덕션급, 엔터프라이즈급 NGINX Plus를 사용하여 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.