NGINX 성능을 위해 최적화하기

NGINX는 세계에서 가장 바쁜 웹사이트의 40% 이상을 지원하는 고성능 로드 밸런서, 캐시, API Gateway, 리버스 프록시 및 웹 서버로 잘 알려져 있습니다. 대부분의 사용 사례에서 기본 NGINX 및 Linux 설정이 잘 작동하지만 최적의 성능을 달성하려면 때때로 약간의 조정이 필요합니다. 이 블로그 포스트에서는 시스템을 조정할 때 고려해야 할 몇 가지 NGINX 및 Linux 설정에 대해 설명합니다.

거의 모든 설정을 최적화할 수 있지만 이 포스트에서는 대부분의 사용자에게 도움이 되는 몇 가지 설정에 집중합니다. NGINX 및 Linux에 대해 깊은 이해도가 있거나 지원 또는 전문 서비스팀의 지시에 따라 변경할 것을 권장하는 설정이 있으며 여기에서는 다루지 않습니다. 전문 서비스팀은 세계에서 가장 바쁜 일부 웹사이트와 협력하여 최상 수준의 성능을 위해 NGINX를 조정했으며 NGINX 또는 NGINX Plus 배포를 최대한 활용하기 위해 귀하와 협력할 수 있습니다.

목차

1. 소개
2. Linux 구성 최적화하기
2-1. Backlog 대기열
2-2. 파일 디스크립터
2-3. 임시 포트
3. NGINX 구성 최적화하기
3-1. Worker 프로세스
3-2. Keepalive 연결
3-3. Access Logging
3-4. Sendfile
3-5. 제한
4. 캐싱 및 압축으로 성능 향상 가능
4-1. Caching
4-2. 압축

1. 소개

NGINX 아키텍처 및 구성 개념에 대한 기본적인 이해가 있다고 가정합니다. 이 포스트는 NGINX 문서를 복제하려는 것이 아니라 다양한 옵션의 개요와 관련 문서로의 링크를 제공합니다.

최적화할 때 따라야 할 좋은 규칙은 한 번에 하나의 설정을 변경해도 성능이 향상되지 않으면 기본값으로 다시 설정하는 것입니다.

일부 운영체제 설정 값에 따라 NGINX 구성을 조정하는 방법이 결정되기 때문에 Linux 조정에 대한 논의부터 시작합니다.

2. Linux 구성 최적화하기

Linux 커널 (2.6+)의 설정은 대부분의 목적에 적합하지만, 일부를 변경하면 도움이 될 수 있습니다. 설정이 너무 낮다는 오류 메시지가 있는지 커널 로그를 확인하고 권장되는 대로 조정하십시오. 여기에서는 일반 워크로드에서 최적화를 통해 가장 큰 이점을 얻을 수 있는 설정만 다룹니다. 이러한 설정 조정에 대한 자세한 내용은 Linux 설명서를 참조하십시오.

2-1. Backlog 대기열

다음 설정은 연결 및 대기 방법과 관련이 있습니다. 들어오는 연결 비율이 높고 성능 수준이 고르지 않은 경우(예: 일부 연결이 정지된 것처럼 보임) 이러한 설정을 변경하면 도움이 될 수 있습니다.

  • net.core.somaxconn – NGINX 에서 승인을 위해 대기할 수 있는 최대 연결 수입니다. 기본값은 종종 매우 낮으며 NGINX가 연결을 매우 빠르게 수락하기 때문에 일반적으로 허용 가능하지만 웹 사이트에서 트래픽이 많은 경우 값을 높일 수 있습니다. 커널 로그의 오류 메시지에 값이 너무 작다고 표시되면 오류가 중지될 때까지 값을 늘립니다.

    참고: 이 값을 512보다 큰 값으로 설정하는 경우 backlog 매개변수를 일치하도록 NGINX listen 지시문으로 변경하십시오.
  • net.core.netdev_max_backlog – 패킷이 CPU로 전달되기 전에 네트워크 카드에 의해 버퍼링 되는 속도입니다. 값을 늘리면 대역폭이 많은 시스템에서 성능이 향상될 수 있습니다. 이 설정과 관련된 오류는 커널 로그를 확인하고 변경에 대한 조언은 네트워크 카드 설명서를 참조하십시오.

2-2. 파일 디스크립터

파일 디스크립터는 무엇보다도 연결 및 열린 파일을 나타내는 데 사용되는 운영체제 리소스입니다. NGINX는 연결당 최대 2개의 파일 디스크립터를 사용할 수 있습니다. 예를 들어 NGINX가 프록시하는 경우 일반적으로 클라이언트 연결에 하나의 파일 디스크립터를 사용하지만, HTTP keepalive를 사용하는 경우 이 비율은 훨씬 낮습니다. 많은 수의 연결을 제공하는 시스템의 경우 다음 설정을 조정해야 할 수 있습니다.

  • sys.fs.file-max – 파일 디스크립터에 대한 시스템 전체 제한
  • nofile – /etc/security/limits.conf 파일에 설정된 사용자 파일 디스크립터 제한

2-3. 임시 포트

NGINX가 프록시 역할을 하는 경우 upstream 서버에 대한 각 연결은 임시 또는 임시 포트를 사용합니다. 이 설정을 변경할 수 있습니다.

  • net.ipv.ip_local_port_range – 포트 값 범위의 시작과 끝입니다. 포트가 부족한 경우 범위를 늘리십시오. 일반적인 설정은 포트 1024 ~ 65000 입니다.

3. NGINX 구성 최적화하기

다음은 성능에 영향을 줄 수 있는 몇 가지 NGINX 지시어입니다. 위에서 언급한 바와 같이, 우리는 스스로 조정하기에 안전한 지시문에 대해서만 논의합니다. NGINX팀의 지시 없이 다른 지시문의 설정을 변경하지 않는 것이 좋습니다.

3-1. Worker 프로세스

NGINX는 각각 많은 수의 동시 연결을 처리할 수 있는 여러 worker 프로세스를 실행할 수 있습니다. worker 프로세스의 수와 다음 지시문을 사용하여 연결을 처리하는 방법을 제어할 수 있습니다.

  • worker_processes – NGINX worker 프로세스의 수입니다(기본값은 1). 대부분의 경우 CPU 코어당 하나의 worker 프로세스를 실행하는 것이 잘 작동하며 이를 달성하려면 이 지시문을 auto로 설정하는 것이 좋습니다. worker 프로세스가 많은 디스크 I/O를 수행해야 하는 경우와 같이 이 수를 늘리려는 경우가 있습니다.
  • worker_connections – 각 worker 프로세스가 동시에 처리할 수 있는 최대 연결 수입니다. 기본값은 512이지만 대부분의 시스템에는 더 많은 수를 지원할 수 있는 충분한 리소스가 있습니다. 적절한 설정은 서버의 크기와 트래픽의 특성에 따라 다르며 테스트를 통해 발견할 수 있습니다.

3-2. Keepalive 연결

Keepalive 연결은 연결을 열고 닫는 데 필요한 CPU 및 네트워크 오버헤드를 줄임으로써 성능에 큰 영향을 미칠 수 있습니다. NGINX는 모든 클라이언트 연결을 종료하고 upstream 서버에 대한 개별적이고 독립적인 연결을 생성합니다. NGINX는 클라이언트와 upstream 서버 모두에 대해 keepalive를 지원합니다. 다음 지시문은 클라이언트 keepalive와 관련이 있습니다.

  • keepalive_requests – 클라이언트가 단일 keepalive 연결을 통해 만들 수 있는 요청 수 입니다. 기본값은 100이지만 훨씬 더 높은 값은 일반적으로 단일 클라이언트에서 많은 수의 요청을 보내는 로드 생성 도구로 테스트하는 데 특히 유용할 수 있습니다.
  • keepalive_requests – keepalive 연결이 열려 있는 기간

다음 지시어는 upstream keepalive와 관련이 있습니다.

  • keepalive – 각 worker 프로세스에 대해 열려있는 upstream 서버에 대한 keepalive 연결 수 입니다. 기본값은 없습니다.

Upstream 서버에 대한 keepalive 연결을 활성화하려면 구성에 다음 지시문도 포함해야 합니다.

proxy_http_version 1.1;
proxy_set_header Connection "";

3-3. Access Logging

모든 요청을 기록하면 CPU와 I/O 주기가 모두 소모되며 영향을 줄이는 한 가지 방법은 access 로그 버퍼링을 활성화 하는 것입니다. NGINX는 각 로그 항목에 대해 별도의 쓰기 작업을 수행하는 대신 버퍼링을 사용하여 일련의 항목을 버퍼링하고 단일 작업에서 함께 파일에 씁니다.

access 로그 버퍼링을 활성화하려면 access_log 지시문에 buffer=size 매개변수를 포함합니다. NGINX는 버퍼가 크기 값에 도달하면 버퍼 내용을 로그에 기록합니다. 지정된 시간이 지난 후 NGINX가 버퍼를 쓰도록 하려면 flush=time 매개변수를 포함합니다. 두 매개변수가 모두 설정되면 NGINX는 다음 로그 항목이 버퍼에 맞지 않거나 버퍼의 항목이 각각 지정된 시간보다 오래된 경우 로그 파일에 항목을 기록합니다. 로그 항목은 worker 프로세스가 로그 파일을 다시 열거나 종료할 때도 기록됩니다. Access Logging을 완전히 비활성화하려면 access_log 지시문에 off 매개변수를 포함니다.

3-4. Sendfile

운영체제의 sendfile() 시스템 호출은 한 파일 설명자에서 다른 파일 설명자로 데이터를 복사하며 종종 제로 복사를 달성하여 TCP 데이터 전송 속도를 높일 수 있습니다. NGINX에서 사용할 수 있도록 하려면 http 컨텍스트나 server 또는 location 컨텍스트에 sendfile 지시문을 포함합니다. 그런 다음 NGINX는 컨텍스트를 사용자 공간으로 전환하지 않고 캐시된 콘텐츠 또는 디스크 상의 콘텐츠를 소켓에 쓸 수 있으므로 쓰기 속도가 매우 빨라지고 CPU 주기를 더 적게 사용합니다. 그러나 sendfile()로 복사된 데이터는 사용자 공간을 우회하기 때문에 일반 NGINX processing chain 및 gzip과 같이 콘텐츠를 변경하는 필터의 영향을 받지 않습니다. 구성 컨텍스트에 sendfile 지시문과 내용 변경 필터를 활성화하는 지시문이 모두 포함되어 있으면 NGINX는 해당 컨텍스트에 대해 sendfile을 자동으로 비활성화합니다.

3-5. 제한

클라이언트가 너무 많은 리소스를 소비하는 것을 방지하는 데 도움이 되는 다양한 제한을 설정할 수 있습니다. 이로 인해 시스템 성능은 물론 보안 및 사용자 경험이 저하될 수 있습니다. 다음은 관련 지침 중 일부입니다.

  • limit_conn 및 limit_conn_zone – 예를 들어 단일 IP 주소에서 NGINX가 허용하는 클라이언트 연결 수를 제한합니다. 이를 설정하면 개별 클라이언트가 너무 많은 연결을 열고 리소스 공유보다 더 많이 소비하는 것을 방지할 수 있습니다.
  • limit_rate – 연결당 응답이 클라이언트로 전송되는 속도를 제한합니다(여러 연결을 여는 클라이언트가 각 연결에 대해 이 양의 대역폭을 사용할 수 있음). 제한을 설정하면 특정 클라이언트에 의해 시스템이 과부하 되는 것을 방지하여 모든 클라이언트에 대해 보다 균일한 서비스 품질을 보장할 수 있습니다.
  • limit_req 및 limit_req_zone – NGINX에서 처리하는 요청 속도를 제한합니다. 이는 limit_rate를 설정하는 것과 동일한 이점이 있습니다. 또한 요청 속도를 인간 사용자에게는 합리적인 값으로 제한하지만 요청으로 애플리케이션을 압도하려는 프로그램(예: DDoS 공격의 봇)에는 너무 느린 값으로 제한하여 특히 로그인 페이지의 보안을 향상시킬 수 있습니다.
  • Upstream 구성 블록의 server 지시문에 대한 max_conns 매개변수 – Upstream 그룹의 서버에서 허용하는 최대 동시 연결 수를 설정합니다. 제한을 부과하면 upstream 서버가 과부하 되는 것을 방지할 수 있습니다. 값을 0(0, 기본값)으로 설정하면 제한이 없음을 의미합니다.
  • 대기열(NGINX Plus) – upstream 그룹의 모든 사용 가능한 서버가 max_conns 제한에 도달했을 때 요청이 배치되는 대기열을 생성합니다. 이 지시문은 대기열의 최대 요청 수와 선택적으로 오류가 반환(return) 되기 전에 대기하는 최대 시간(기본적으로 60초)을 설정합니다. 이 지시문을 생략하면 요청이 대기하지 않습니다.

4. 캐싱 및 압축으로 성능 향상 가능

웹 애플리케이션의 성능을 높이는 데 사용할 수 있는 NGINX의 일부 추가 기능은 실제로 튜닝이라는 제목에 포함되지는 않지만 그 영향이 상당할 수 있으므로 언급할 가치가 있습니다. 여기에는 캐싱 및 압축이 포함됩니다.

4-1. Caching

웹 또는 애플리케이션 서버 세트의 로드 밸런싱을 수행하는 NGINX 인스턴스에서 캐싱을 활성화하면 클라이언트에 대한 응답 시간을 크게 개선하는 동시에 백엔드 서버의 로드를 크게 줄일 수 있습니다. 캐싱은 그 자체로 주제이며 여기에서 다루지 않겠습니다. NGINX Plus 관리자 가이드를 참조하세요.

4-2. 압축

클라이언트에 보낸 응답을 압축하면 크기를 크게 줄일 수 있으므로 네트워크 대역폭을 덜 사용합니다. 그러나 데이터 압축은 CPU 리소스를 소비하기 때문에 대역폭 사용을 줄이는 것이 정말 가치가 있을 때 가장 유용합니다. JPEG 파일과 같이 이미 압축된 개체에 대해 압축을 활성화해서는 안 된다는 점에 유의해야 합니다. 자세한 내용은 NGINX Plus 관리자 가이드를 참조하세요.

자세한 내용은 다음을 참조하세요.

NGINX Plus를 사용해 보려면 지금 무료 30일 평가판을 시작하거나 데모를 위해 당사에 문의하십시오.

사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.