NGINX는 고성능 로드 밸런서 , 캐시 및 웹 서버로 잘 알려져 있으며 , 세계에서 가장 바쁜 웹사이트의 40% 이상을 구동합니다. 대부분의 사용 사례에서 기본 NGINX 및 Linux 설정은 잘 작동하지만 최적의 성능을 달성하려면 때때로 약간의 튜닝이 필요합니다. 이 블로그 게시물에서는 시스템을 튜닝할 때 고려해야 할 NGINX 및 Linux 설정 중 일부를 설명합니다.
거의 모든 설정을 조정할 수 있지만, 이 게시물은 조정이 가장 많은 사용자에게 도움이 되는 몇 가지 설정에 집중합니다. NGINX와 Linux에 대한 깊은 이해가 있거나 지원 또는 전문 서비스 팀의 지시에 따라 변경하는 것이 권장되는 설정이 있으며, 여기서는 다루지 않습니다. 전문 서비스 팀은 세계에서 가장 바쁜 웹사이트 중 일부와 협력하여 최대 수준의 성능을 위해 NGINX를 조정했으며, NGINX 또는 NGINX Plus 배포를 최대한 활용하기 위해 귀하와 협력할 수 있습니다.
소개
NGINX 아키텍처 및 구성 개념에 대한 기본적인 이해가 전제되어 있습니다.
이 게시물은 NGINX 설명서를 복제하려고 하지 않지만 다양한 옵션과 관련 설명서에 대한 링크를 개요로 제공합니다.
튜닝할 때 따라야 할 좋은 규칙은 한 번에 하나의 설정을 변경하고, 변경해도 성능이 향상되지 않으면 기본값으로 다시 설정하는 것입니다.
NGINX 구성을 튜닝하는 방법은 일부 운영 체제 설정 값에 따라 결정되므로 Linux 튜닝에 대한 논의부터 시작해 보겠습니다.
Linux 구성 조정
최신 Linux 커널(2.6+)의 설정은 대부분 목적에 적합하지만, 일부 설정을 변경하면 유익할 수 있습니다. 설정이 너무 낮다는 오류 메시지가 있는지 커널 로그를 확인하고, 조언에 따라 조정합니다. 여기서는 일반적인 작업 부하에서 튜닝을 통해 가장 큰 이점을 얻을 수 있는 설정만 다룹니다. 이러한 설정을 조정하는 방법에 대한 자세한 내용은 Linux 설명서를 참조하십시오.
백로그 큐
다음 설정은 연결 및 연결 대기 방식과 관련이 있습니다. 들어오는 연결 비율이 높고 성능 수준이 고르지 않은 경우(예: 일부 연결이 중단되는 것처럼 보임) 이러한 설정을 변경하면 도움이 될 수 있습니다.
net.core.somaxconn– NGINX에서 수락을 위해 대기할 수 있는 최대 연결 수. 기본값은 종종 매우 낮고 NGINX가 연결을 매우 빠르게 수락하기 때문에 일반적으로 허용되지만 웹사이트에 트래픽이 많으면 늘리는 것이 가치가 있을 수 있습니다. 커널 로그의 오류 메시지가 값이 너무 작다고 표시하면 오류가 멈출 때까지 늘리십시오.
참고: 이 값을 512보다 큰 값으로 설정하는 경우 매개변수를 일치하도록 backlogNGINX 명령어로 변경하세요.listen
- net.core.netdev_max_backlog– 패킷이 CPU로 전달되기 전에 네트워크 카드에서 버퍼링되는 속도입니다. 값을 늘리면 대역폭이 많은 머신에서 성능이 향상될 수 있습니다. 이 설정과 관련된 오류에 대한 커널 로그를 확인하고 네트워크 카드 설명서를 참조하여 변경에 대한 조언을 받으십시오.
파일 설명자
파일 설명자는 연결과 열린 파일 등을 나타내는 데 사용되는 운영 체제 리소스입니다. NGINX는 연결당 최대 두 개의 파일 설명자를 사용할 수 있습니다. 예를 들어, NGINX가 프록싱하는 경우 일반적으로 클라이언트 연결에 하나의 파일 설명자를 사용하고 프록시된 서버에 대한 연결에 다른 파일 설명자를 사용하지만 HTTP keepalives를 사용하는 경우 이 비율은 훨씬 낮습니다. 많은 수의 연결을 제공하는 시스템의 경우 다음 설정을 조정해야 할 수 있습니다.
- sys.fs.file-max– 파일 기술자에 대한 시스템 전체 제한
- nofile– /etc/security/limits.conf 파일 에 설정된 사용자 파일 설명자 제한
임시 포트
NGINX가 프록시 역할을 할 때 업스트림 서버에 대한 각 연결은 임시 또는 임시 포트를 사용합니다. 이 설정을 변경할 수 있습니다.
- net.ipv4.ip_local_port_range– 포트 값 범위의 시작과 끝. 포트가 부족하다고 생각되면 범위를 늘리세요. 일반적인 설정은 포트 1024~65000입니다.
NGINX 구성 튜닝
다음은 성능에 영향을 줄 수 있는 NGINX 지침입니다. 위에서 언급했듯이, 회원님이 직접 조정해도 안전한 가이드라인에 대해서만 논의합니다. NGINX 팀의 지시 없이 다른 지침의 설정을 변경하지 않는 것이 좋습니다.
작업자 프로세스
NGINX는 여러 개의 워커 프로세스를 실행할 수 있으며, 각각은 많은 수의 동시 연결을 처리할 수 있습니다. 다음 지시문을 사용하여 워커 프로세스의 수와 연결을 처리하는 방법을 제어할 수 있습니다.
- worker_processes– NGINX 워커 프로세스 수(기본값은 1). 대부분의 경우 CPU 코어당 워커 프로세스 하나를 실행하는 것이 효과적이며, auto이를 달성하기 위해 이 지시문을 로 설정하는 것이 좋습니다. 워커 프로세스가 많은 디스크 I/O를 수행해야 하는 경우와 같이 이 수를 늘리고 싶을 때가 있습니다.
- worker_connections– 각 작업자 프로세스가 동시에 처리할 수 있는 최대 연결 수. 기본값은 512이지만 대부분의 시스템은 더 많은 수를 지원할 만큼 충분한 리소스를 가지고 있습니다. 적절한 설정은 서버 크기와 트래픽의 특성에 따라 달라지며 테스트를 통해 발견할 수 있습니다.
Keepalive 연결
Keepalive 연결은 연결을 열고 닫는 데 필요한 CPU 및 네트워크 오버헤드를 줄여 성능에 큰 영향을 미칠 수 있습니다. NGINX는 모든 클라이언트 연결을 종료하고 업스트림 서버에 대한 별도 및 독립적인 연결을 만듭니다. NGINX는 클라이언트와 업스트림 서버 모두에 대해 keepalive를 지원합니다. 다음 지시문은 클라이언트 keepalive와 관련이 있습니다.
- keepalive_requests– 클라이언트가 단일 keepalive 연결을 통해 만들 수 있는 요청 수. 기본값은 100이지만, 훨씬 더 높은 값은 일반적으로 단일 클라이언트에서 많은 수의 요청을 보내는 부하 생성 도구로 테스트하는 데 특히 유용할 수 있습니다.
- keepalive_timeout– 유휴 Keepalive 연결이 열려 있는 기간입니다.
다음 지침은 업스트림 keepalives와 관련이 있습니다.
- keepalive– 각 작업자 프로세스에 대해 열려 있는 업스트림 서버에 대한 유휴 keepalive 연결 수. 기본값은 없습니다.
업스트림 서버에 대한 keepalive 연결을 활성화하려면 구성에 다음 지침도 포함해야 합니다.
proxy_http_version 1.1;proxy_set_header Connection "";
액세스 로깅
모든 요청을 로깅하면 CPU와 I/O 사이클이 모두 소모되고, 영향을 줄이는 한 가지 방법은 액세스 로그 버퍼링을 활성화하는 것입니다. 버퍼링을 사용하면 각 로그 항목에 대해 별도의 쓰기 작업을 수행하는 대신 NGINX는 일련의 항목을 버퍼링하고 단일 작업으로 파일에 함께 씁니다.
액세스 로그 버퍼링을 활성화하려면 지시문 에 매개변수를 포함합니다 . NGINX는 버퍼가 값에 도달하면 버퍼 내용을 로그에 씁니다 . NGINX가 지정된 시간 후에 버퍼를 쓰게 하려면 매개변수를 포함합니다. 두 매개변수가 모두 설정된 경우 NGINX는 다음 로그 항목이 버퍼에 맞지 않거나 버퍼의 항목이 지정된 시간보다 오래되었을 때 각각 로그 파일에 항목을 씁니다. 작업자 프로세스가 로그 파일을 다시 열거나 종료할 때도 로그 항목이 기록됩니다. 액세스 로깅을 완전히 비활성화하려면 지시문 에 매개변수를 포함합니다 .buffer=sizeaccess_logsizeflush=timeoffaccess_log
보내기파일
운영 체제의 sendfile()시스템 호출은 한 파일 설명자에서 다른 파일 설명자로 데이터를 복사하여 종종 제로 복사를 수행하여 TCP 데이터 전송 속도를 높일 수 있습니다.NGINX에서 이를 사용할 수 있도록 하려면 컨텍스트 또는 또는 컨텍스트 sendfile에 지시문을 포함합니다 .그러면 NGINX는 사용자 공간으로 컨텍스트를 전환하지 않고도 캐시되거나 디스크에 있는 콘텐츠를 소켓에 쓸 수 있으므로 쓰기 속도가 매우 빨라지고 CPU 주기를 덜 소모합니다.그러나 사용자 공간을 우회하여 복사된 데이터는 일반 NGINX 처리 체인 및 콘텐츠를 변경하는 필터(예: )의 영향을 받지 않습니다 .구성 컨텍스트에 지시문과 콘텐츠 변경 필터를 활성화하는 지시문이 모두 포함된 경우 NGINX는 해당 컨텍스트를 자동으로 비활성화합니다.httpserverlocationsendfile()gzipsendfilesendfile
제한
클라이언트가 너무 많은 리소스를 소비하는 것을 방지하는 데 도움이 되는 다양한 제한을 설정할 수 있으며, 이는 시스템 성능과 보안 및 사용자 경험에 부정적인 영향을 미칠 수 있습니다. 다음은 관련 지침 중 일부입니다.
- limit_conn그리고 limit_conn_zone– NGINX가 허용하는 클라이언트 연결 수를 제한합니다(예: 단일 IP 주소에서). 이를 설정하면 개별 클라이언트가 너무 많은 연결을 열고 리소스의 몫 이상을 소비하는 것을 방지하는 데 도움이 될 수 있습니다.
- limit_rate– 연결당 클라이언트에 응답이 전송되는 속도를 제한합니다(따라서 여러 연결을 여는 클라이언트는 각 연결에 대해 이 양의 대역폭을 사용할 수 있음). 제한을 설정하면 시스템이 특정 클라이언트에 의해 과부하되는 것을 방지하여 모든 클라이언트에 대해 보다 균일한 서비스 품질을 보장할 수 있습니다.
- limit_req그리고 limit_req_zone– NGINX에서 처리되는 요청 속도를 제한합니다. 이는 .을 설정하는 것과 동일한 이점이 있습니다 limit_rate. 또한 특히 로그인 페이지의 보안을 개선할 수 있으며, 요청 속도를 인간 사용자에게는 합리적인 값으로 제한하지만 요청으로 애플리케이션을 압도하려는 프로그램(예: DDoS 공격 의 봇 )에게는 너무 느립니다.
- max_connsserver구성 블록 의 지시문 에 대한 매개변수 upstream– 업스트림 그룹의 서버가 허용하는 최대 동시 연결 수를 설정합니다. 제한을 부과하면 업스트림 서버가 과부하되는 것을 방지하는 데 도움이 될 수 있습니다. 값을 0(기본값인 0)으로 설정하면 제한이 없음을 의미합니다.
- queue(NGINX Plus) – 업스트림 그룹의 모든 사용 가능한 서버가 한계에 도달했을 때 요청이 배치되는 대기열을 만듭니다 max_conns. 이 지시문은 대기열의 최대 요청 수와 선택적으로 오류가 반환되기 전에 대기하는 최대 시간(기본값 60초)을 설정합니다. 이 지시문을 생략하면 요청이 대기열에 추가되지 않습니다.
캐싱 및 압축으로 성능 향상 가능
웹 애플리케이션의 성능을 높이는 데 사용할 수 있는 NGINX의 추가 기능 중 일부는 실제로 튜닝이라는 제목에 속하지 않지만, 그 영향이 상당할 수 있기 때문에 언급할 가치가 있습니다. 여기에는 캐싱과 압축이 포함됩니다.
캐싱
웹 또는 애플리케이션 서버 집합을 로드 밸런싱하는 NGINX 인스턴스에서 캐싱을 활성화하면 클라이언트에 대한 응답 시간을 획기적으로 개선하는 동시에 백엔드 서버의 부하를 획기적으로 줄일 수 있습니다. 캐싱은 그 자체로 주제이므로 여기서는 다루지 않습니다. NGINX Plus 관리자 가이드를 참조하세요 .
압축
클라이언트에 전송된 응답을 압축하면 크기를 크게 줄일 수 있으므로 네트워크 대역폭을 덜 사용합니다. 그러나 데이터를 압축하면 CPU 리소스가 소모되므로 대역폭 사용량을 줄이는 것이 정말 가치 있는 경우에 가장 유용합니다. JPEG 파일과 같이 이미 압축된 객체에 대해 압축을 활성화해서는 안 된다는 점에 유의하는 것이 중요합니다. 자세한 내용은 NGINX Plus 관리자 가이드를 참조하세요 .
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요.
전문가에게 상담받기
NGINX는 고성능 로드 밸런서 , 캐시 및 웹 서버로 잘 알려져 있으며 , 세계에서 가장 바쁜 웹사이트의 40% 이상을 구동합니다. 대부분의 사용 사례에서 기본 NGINX 및 Linux 설정은 잘 작동하지만 최적의 성능을 달성하려면 때때로 약간의 튜닝이 필요합니다. 이 블로그 게시물에서는 시스템을 튜닝할 때 고려해야 할 NGINX 및 Linux 설정 중 일부를 설명합니다.
거의 모든 설정을 조정할 수 있지만, 이 게시물은 조정이 가장 많은 사용자에게 도움이 되는 몇 가지 설정에 집중합니다. NGINX와 Linux에 대한 깊은 이해가 있거나 지원 또는 전문 서비스 팀의 지시에 따라 변경하는 것이 권장되는 설정이 있으며, 여기서는 다루지 않습니다. 전문 서비스 팀은 세계에서 가장 바쁜 웹사이트 중 일부와 협력하여 최대 수준의 성능을 위해 NGINX를 조정했으며, NGINX 또는 NGINX Plus 배포를 최대한 활용하기 위해 귀하와 협력할 수 있습니다.
소개
NGINX 아키텍처 및 구성 개념에 대한 기본적인 이해가 전제되어 있습니다.
이 게시물은 NGINX 설명서를 복제하려고 하지 않지만 다양한 옵션과 관련 설명서에 대한 링크를 개요로 제공합니다.
튜닝할 때 따라야 할 좋은 규칙은 한 번에 하나의 설정을 변경하고, 변경해도 성능이 향상되지 않으면 기본값으로 다시 설정하는 것입니다.
NGINX 구성을 튜닝하는 방법은 일부 운영 체제 설정 값에 따라 결정되므로 Linux 튜닝에 대한 논의부터 시작해 보겠습니다.
Linux 구성 조정
최신 Linux 커널(2.6+)의 설정은 대부분 목적에 적합하지만, 일부 설정을 변경하면 유익할 수 있습니다. 설정이 너무 낮다는 오류 메시지가 있는지 커널 로그를 확인하고, 조언에 따라 조정합니다. 여기서는 일반적인 작업 부하에서 튜닝을 통해 가장 큰 이점을 얻을 수 있는 설정만 다룹니다. 이러한 설정을 조정하는 방법에 대한 자세한 내용은 Linux 설명서를 참조하십시오.
백로그 큐
다음 설정은 연결 및 연결 대기 방식과 관련이 있습니다. 들어오는 연결 비율이 높고 성능 수준이 고르지 않은 경우(예: 일부 연결이 중단되는 것처럼 보임) 이러한 설정을 변경하면 도움이 될 수 있습니다.
net.core.somaxconn– NGINX에서 수락을 위해 대기할 수 있는 최대 연결 수. 기본값은 종종 매우 낮고 NGINX가 연결을 매우 빠르게 수락하기 때문에 일반적으로 허용되지만 웹사이트에 트래픽이 많으면 늘리는 것이 가치가 있을 수 있습니다. 커널 로그의 오류 메시지가 값이 너무 작다고 표시하면 오류가 멈출 때까지 늘리십시오.
참고: 이 값을 512보다 큰 값으로 설정하는 경우 매개변수를 일치하도록 backlogNGINX 명령어로 변경하세요.listen
파일 설명자
파일 설명자는 연결과 열린 파일 등을 나타내는 데 사용되는 운영 체제 리소스입니다. NGINX는 연결당 최대 두 개의 파일 설명자를 사용할 수 있습니다. 예를 들어, NGINX가 프록싱하는 경우 일반적으로 클라이언트 연결에 하나의 파일 설명자를 사용하고 프록시된 서버에 대한 연결에 다른 파일 설명자를 사용하지만 HTTP keepalives를 사용하는 경우 이 비율은 훨씬 낮습니다. 많은 수의 연결을 제공하는 시스템의 경우 다음 설정을 조정해야 할 수 있습니다.
임시 포트
NGINX가 프록시 역할을 할 때 업스트림 서버에 대한 각 연결은 임시 또는 임시 포트를 사용합니다. 이 설정을 변경할 수 있습니다.
NGINX 구성 튜닝
다음은 성능에 영향을 줄 수 있는 NGINX 지침입니다. 위에서 언급했듯이, 회원님이 직접 조정해도 안전한 가이드라인에 대해서만 논의합니다. NGINX 팀의 지시 없이 다른 지침의 설정을 변경하지 않는 것이 좋습니다.
작업자 프로세스
NGINX는 여러 개의 워커 프로세스를 실행할 수 있으며, 각각은 많은 수의 동시 연결을 처리할 수 있습니다. 다음 지시문을 사용하여 워커 프로세스의 수와 연결을 처리하는 방법을 제어할 수 있습니다.
Keepalive 연결
Keepalive 연결은 연결을 열고 닫는 데 필요한 CPU 및 네트워크 오버헤드를 줄여 성능에 큰 영향을 미칠 수 있습니다. NGINX는 모든 클라이언트 연결을 종료하고 업스트림 서버에 대한 별도 및 독립적인 연결을 만듭니다. NGINX는 클라이언트와 업스트림 서버 모두에 대해 keepalive를 지원합니다. 다음 지시문은 클라이언트 keepalive와 관련이 있습니다.
다음 지침은 업스트림 keepalives와 관련이 있습니다.
업스트림 서버에 대한 keepalive 연결을 활성화하려면 구성에 다음 지침도 포함해야 합니다.
proxy_http_version 1.1;proxy_set_header Connection "";
액세스 로깅
모든 요청을 로깅하면 CPU와 I/O 사이클이 모두 소모되고, 영향을 줄이는 한 가지 방법은 액세스 로그 버퍼링을 활성화하는 것입니다. 버퍼링을 사용하면 각 로그 항목에 대해 별도의 쓰기 작업을 수행하는 대신 NGINX는 일련의 항목을 버퍼링하고 단일 작업으로 파일에 함께 씁니다.
액세스 로그 버퍼링을 활성화하려면 지시문 에 매개변수를 포함합니다 . NGINX는 버퍼가 값에 도달하면 버퍼 내용을 로그에 씁니다 . NGINX가 지정된 시간 후에 버퍼를 쓰게 하려면 매개변수를 포함합니다. 두 매개변수가 모두 설정된 경우 NGINX는 다음 로그 항목이 버퍼에 맞지 않거나 버퍼의 항목이 지정된 시간보다 오래되었을 때 각각 로그 파일에 항목을 씁니다. 작업자 프로세스가 로그 파일을 다시 열거나 종료할 때도 로그 항목이 기록됩니다. 액세스 로깅을 완전히 비활성화하려면 지시문 에 매개변수를 포함합니다 .buffer=sizeaccess_logsizeflush=timeoffaccess_log
보내기파일
운영 체제의 sendfile()시스템 호출은 한 파일 설명자에서 다른 파일 설명자로 데이터를 복사하여 종종 제로 복사를 수행하여 TCP 데이터 전송 속도를 높일 수 있습니다.NGINX에서 이를 사용할 수 있도록 하려면 컨텍스트 또는 또는 컨텍스트 sendfile에 지시문을 포함합니다 .그러면 NGINX는 사용자 공간으로 컨텍스트를 전환하지 않고도 캐시되거나 디스크에 있는 콘텐츠를 소켓에 쓸 수 있으므로 쓰기 속도가 매우 빨라지고 CPU 주기를 덜 소모합니다.그러나 사용자 공간을 우회하여 복사된 데이터는 일반 NGINX 처리 체인 및 콘텐츠를 변경하는 필터(예: )의 영향을 받지 않습니다 .구성 컨텍스트에 지시문과 콘텐츠 변경 필터를 활성화하는 지시문이 모두 포함된 경우 NGINX는 해당 컨텍스트를 자동으로 비활성화합니다.httpserverlocationsendfile()gzipsendfilesendfile
제한
클라이언트가 너무 많은 리소스를 소비하는 것을 방지하는 데 도움이 되는 다양한 제한을 설정할 수 있으며, 이는 시스템 성능과 보안 및 사용자 경험에 부정적인 영향을 미칠 수 있습니다. 다음은 관련 지침 중 일부입니다.
캐싱 및 압축으로 성능 향상 가능
웹 애플리케이션의 성능을 높이는 데 사용할 수 있는 NGINX의 추가 기능 중 일부는 실제로 튜닝이라는 제목에 속하지 않지만, 그 영향이 상당할 수 있기 때문에 언급할 가치가 있습니다. 여기에는 캐싱과 압축이 포함됩니다.
캐싱
웹 또는 애플리케이션 서버 집합을 로드 밸런싱하는 NGINX 인스턴스에서 캐싱을 활성화하면 클라이언트에 대한 응답 시간을 획기적으로 개선하는 동시에 백엔드 서버의 부하를 획기적으로 줄일 수 있습니다. 캐싱은 그 자체로 주제이므로 여기서는 다루지 않습니다. NGINX Plus 관리자 가이드를 참조하세요 .
압축
클라이언트에 전송된 응답을 압축하면 크기를 크게 줄일 수 있으므로 네트워크 대역폭을 덜 사용합니다. 그러나 데이터를 압축하면 CPU 리소스가 소모되므로 대역폭 사용량을 줄이는 것이 정말 가치 있는 경우에 가장 유용합니다. JPEG 파일과 같이 이미 압축된 객체에 대해 압축을 활성화해서는 안 된다는 점에 유의하는 것이 중요합니다. 자세한 내용은 NGINX Plus 관리자 가이드를 참조하세요 .
위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요.
전문가에게 상담받기