Nginx와 함께 Node.js를 사용하여 고부하 network_node.js 구현
- WBOY원래의
- 2016-05-16 15:52:321316검색
처리량이 높은 웹 애플리케이션을 구축할 때 NginX와 Node.js는 자연스럽게 어울립니다. 모두 이벤트 중심 모델을 기반으로 설계되었으며 Apache와 같은 기존 웹 서버의 C10K 병목 현상을 쉽게 극복할 수 있습니다. 기본 구성은 이미 높은 동시성을 달성할 수 있지만 저렴한 하드웨어에서 초당 수천 개 이상의 요청을 달성하려는 경우 아직 수행해야 할 작업이 있습니다.
이 기사에서는 독자가 NginX의 HttpProxyModule을 사용하여 업스트림 node.js 서버의 역방향 프록시 역할을 한다고 가정합니다. Ubuntu 10.04 이상 시스템의 sysctl 조정과 node.js 애플리케이션 및 NginX 조정을 소개합니다. 물론 데비안 시스템을 사용하는 경우에도 동일한 목표를 달성할 수 있지만 튜닝 방법이 다릅니다.
네트워크 튜닝
Nginx와 Node.js의 기본 전송 메커니즘을 먼저 이해하고 타겟 최적화를 수행하지 않으면 두 가지의 최적화를 아무리 자세하게 수행해도 헛될 수 있습니다. 일반적으로 Nginx는 TCP 소켓을 통해 클라이언트와 업스트림 애플리케이션을 연결합니다.
우리 시스템에는 커널 매개변수를 통해 설정되는 TCP에 대한 많은 임계값과 제한 사항이 있습니다. 이러한 매개변수의 기본값은 일반적인 목적으로 설정되는 경우가 많으며 웹 서버의 높은 트래픽 및 짧은 수명 요구 사항을 충족할 수 없습니다.
다음은 TCP 조정을 위한 후보인 몇 가지 매개변수입니다. 이를 효과적으로 적용하려면 /etc/sysctl.conf 파일에 넣거나 /etc/sysctl.d/99-tuning.conf와 같은 새 구성 파일에 넣은 다음 sysctl -p를 실행하여 커널이 로드하도록 하세요. 우리는 이러한 물리적 작업을 수행하기 위해 sysctl-cookbook을 사용합니다.
여기에 나열된 값은 사용해도 안전하지만 부하, 하드웨어 및 사용량에 따라 보다 적절한 값을 선택하려면 각 매개변수의 의미를 연구하는 것이 좋습니다.
net.ipv4.tcp_tw_reuse='1'
net.ipv4.tcp_fin_timeout='15'
net.core.netdev_max_backlog='4096'
net.core.rmem_max='16777216'
net.core.somaxconn='4096'
net.core.wmem_max='16777216'
net.ipv4.tcp_max_syn_backlog='20480'
net.ipv4.tcp_max_tw_buckets='400000'
net.ipv4.tcp_no_metrics_save='1'
net.ipv4.tcp_rmem='4096 87380 16777216'
net.ipv4.tcp_syn_retries='2'
net.ipv4.tcp_synack_retries='2'
net.ipv4.tcp_wmem='4096 65536 16777216'
vm.min_free_kbytes='65536'
몇 가지 중요한 사항을 강조표시합니다.
업스트림 애플리케이션을 위한 다운스트림 클라이언트를 제공하기 위해 NginX는 두 개의 TCP 연결(클라이언트에 대해 하나, 애플리케이션에 대해 하나)을 열어야 합니다. 서버가 많은 연결을 수신하면 시스템의 사용 가능한 포트가 빠르게 고갈됩니다. net.ipv4.ip_local_port_range 매개변수를 수정하면 사용 가능한 포트 범위를 늘릴 수 있습니다. /var/log/syslog에 "possible SYN Flooding on port 80. Sending Cookies"라는 오류가 발견되면 시스템이 사용 가능한 포트를 찾을 수 없다는 의미입니다. net.ipv4.ip_local_port_range 매개변수를 늘리면 이 오류를 줄일 수 있습니다.
서버가 다수의 TCP 연결 사이를 전환해야 하는 경우 TIME_WAIT 상태의 연결이 다수 생성됩니다. TIME_WAIT는 연결 자체는 닫혔지만 리소스는 해제되지 않았음을 의미합니다. net_ipv4_tcp_tw_reuse를 1로 설정하면 커널이 안전할 때 연결을 재활용하려고 시도할 수 있으며 이는 새 연결을 다시 설정하는 것보다 훨씬 저렴합니다.
이것은 TIME_WAIT 상태의 연결이 재활용되기 전에 기다려야 하는 최소 시간입니다. 더 작게 만들면 재활용 속도가 빨라질 수 있습니다.
연결 상태 확인 방법
netstat 사용:
또는 ss를 사용하세요:
NginX
웹 서버의 부하가 점차 증가함에 따라 NginX의 이상한 한계에 직면하게 됩니다. 연결이 끊어지고 커널이 계속 SYN 플러드를 보고합니다. 현재로서는 로드 평균과 CPU 사용량이 매우 적고 서버가 분명히 더 많은 연결을 처리할 수 있기 때문에 정말 실망스럽습니다.
조사 결과 TIME_WAIT 상태의 연결이 많은 것으로 확인되었습니다. 다음은 서버 중 하나의 출력입니다.
총계: 388(커널 541)
TCP: 47461(estab 311, 폐쇄 47135, 고아 4, synrecv 0, timewait 47135/0), 포트 33938
총 IP IPv6 전송
* 541 - - -
RAW 0 0 0 0
UDP 13 10 3
TCP 326 325 1
INET 339 335 4
프래그 0 0 0 0
47135 TIME_WAIT 연결이 있습니다! 게다가 ss를 보면 모두 닫힌 연결임을 알 수 있습니다. 이는 서버가 사용 가능한 포트의 대부분을 소비했음을 나타내며 서버가 각 연결에 대해 새 포트를 할당하고 있음을 의미합니다. 네트워크를 조정하면 문제가 약간 해결되었지만 여전히 포트가 충분하지 않았습니다.
추가 조사 끝에 업링크 keepalive 명령에 대한 문서를 찾았습니다.
- 업스트림 서버에 대한 유휴 연결 유지 연결의 최대 수를 설정합니다. 이러한 연결은 작업자 프로세스의 캐시에 유지됩니다.
흥미롭네요. 이론적으로 이 설정은 캐시된 연결을 통해 요청을 전달하여 낭비되는 연결을 최소화합니다. 문서에는 또한 proxy_http_version을 "1.1"로 설정하고 "Connection" 헤더를 지워야 한다고 언급되어 있습니다. 더 자세히 조사한 결과 HTTP/1.1은 HTTP1.0에 비해 TCP 연결 사용을 크게 최적화하고 Nginx는 기본적으로 HTTP/1.0을 사용하기 때문에 이것이 좋은 아이디어라는 것을 알았습니다.
문서에 제안된 대로 수정하면 업링크 구성 파일은 다음과 같습니다.
서버 nodejs-3:5016 max_fails=0 failure_timeout=10s;
서버 nodejs-4:5016 max_fails=0 failure_timeout=10s;
서버 nodejs-5:5016 max_fails=0 failure_timeout=10s;
서버 nodejs-6:5016 max_fails=0 failure_timeout=10s;
연결 유지 512;
}
제안대로 서버 섹션의 프록시 설정도 수정했습니다. 동시에 실패한 서버를 건너뛰기 위해 Proxy_next_upstream이 추가되었고 클라이언트의 keepalive_timeout이 조정되었으며 액세스 로그가 꺼졌습니다. 구성은 다음과 같습니다.
80; 들어보세요
server_name fast.gosquared.com;
client_max_body_size 16M;
keepalive_timeout 10;
위치 / {
Proxy_next_upstream 오류 시간 초과 http_500 http_502 http_503 http_504;
Proxy_set_header 연결 "";
Proxy_http_version 1.1;
Proxy_pass http://backend_nodejs;
}
접속_로그오프;
error_log /dev/null crit;
}
새로운 구성을 적용한 후 서버가 차지하는 소켓이 90% 감소한 것을 확인했습니다. 이제 훨씬 적은 수의 연결을 사용하여 요청을 전송할 수 있습니다. 새로운 출력은 다음과 같습니다:
총계: 558(커널 604)
TCP: 4675(estab 485, 폐쇄 4183, 고아 0, synrecv 0, timewait 4183/0), 포트 2768
총 IP IPv6 전송
* 604 - - -
RAW 0 0 0 0
UDP 13 10 3
TCP 492 491 1
INET 505 501 4
Node.js
I/O를 비동기식으로 처리하는 이벤트 중심 설계 덕분에 Node.js는 즉시 많은 수의 연결과 요청을 처리할 수 있습니다. 다른 조정 방법이 있지만 이 기사에서는 주로 node.js의 프로세스 측면에 중점을 둘 것입니다.
노드는 단일 스레드이며 다중 코어를 자동으로 사용하지 않습니다. 즉, 응용 프로그램은 서버의 전체 기능을 자동으로 얻을 수 없습니다.
노드 프로세스 클러스터링 달성
여러 스레드를 포크하고 동일한 포트에서 데이터를 수신하여 로드가 여러 코어에 걸쳐 실행되도록 애플리케이션을 수정할 수 있습니다. Node에는 이 목표를 달성하는 데 필요한 모든 도구를 제공하는 클러스터 모듈이 있지만 이를 애플리케이션에 추가하려면 많은 수작업이 필요합니다. express를 사용하는 경우 eBay에 cluster2라는 모듈이 있습니다.
컨텍스트 전환 방지
여러 프로세스를 실행할 때는 각 CPU 코어가 한 번에 하나의 프로세스에만 사용되는지 확인해야 합니다. 일반적으로 CPU에 N개의 코어가 있으면 N-1개의 애플리케이션 프로세스를 생성해야 합니다. 이렇게 하면 각 프로세스가 합리적인 시간 조각을 확보하여 커널 스케줄러가 다른 작업을 실행할 수 있도록 하나의 코어를 확보할 수 있습니다. 또한 CPU 경합을 방지하기 위해 기본적으로 Node.js 이외의 다른 작업이 서버에서 실행되지 않도록 해야 합니다.
한 번은 실수를 해서 두 개의 node.js 애플리케이션을 서버에 배포한 후 각 애플리케이션이 N-1 프로세스를 열었습니다. 결과적으로 CPU를 놓고 서로 경쟁하게 되어 시스템 부하가 급격히 증가하게 됩니다. 우리 서버는 모두 8코어 머신이지만 컨텍스트 전환으로 인한 성능 오버헤드는 여전히 뚜렷하게 느껴집니다. 컨텍스트 스위칭(Context Switching)은 CPU가 다른 작업을 수행하기 위해 현재 작업을 일시 중단하는 현상을 말합니다. 전환할 때 커널은 현재 프로세스의 모든 상태를 일시 중지한 다음 다른 프로세스를 로드하고 실행해야 합니다. 이 문제를 해결하기 위해 각 애플리케이션이 시작하는 프로세스 수를 줄여 CPU를 공정하게 공유할 수 있게 했으며, 그 결과 시스템 부하가 감소했습니다.
시스템 로드(파란색 선)가 CPU 코어 수(빨간색 선) 아래로 어떻게 떨어지는지 확인하려면 위 그림을 주의 깊게 살펴보시기 바랍니다. 다른 서버에서도 같은 현상이 나타났습니다. 전체 작업량은 동일하므로 위 그래프의 성능 향상은 컨텍스트 전환의 감소에 따른 것일 수밖에 없습니다.