히포

• nginx는 새로 들어오는 모든 요청에 대해 upstream(backend) 서버에 대한 새 연결(incoming request)→ 안전하지만 비효율적
  1. nginx와 upstream(backend) 서버가 연결을 설정하려면 패킷 3개를 교환
  2. nginx와 upstream(backend) 서버가 연결을 종료하려면 패킷 3~4개를 교환

• 트래픽이 많을 경우 모든 요청에 대해 새 연결을 열면 시스템 리소스가 고갈되어 연결을 열지 못 함
• nginx에서 upstream 서버로 연결하는 경우 source address, destination address, and destination port 는 고정되어 있고 source port만 변수
• nginx 연경은 source address, source port, destination address, and destination port 4가지 요소로 구성

• nginx에서 upstream 서버와 연결이 닫히면 linux 소켓은 2분 동안 TIME-WAIT 상태가 됨
  • 트래픽이 많으면 사용 가능한 source port가 소진될 가능성이 높아짐 → nginx는 upstream 서버에 대한 새 연결을 열 수 없는 상태가 됨
  • source port가 고갈되는 것을 막기 위해 요청이 완료되면 연결이 닫히는 대신 추가 요청에 사용할 수 있도록 연결을 열어두는 keep-alive 연결을 nginx와 upstream 간에 활성화

• 각 worker process의 캐시에 보존되는 upstream 서버에 대한 idle keep-alive 연결 수를 설정하려면 upstream{} 블록에 keepalive 지시어 사용
  • keepalive 지시어는 worker process가 열 수 있는 upstream 서버에 대한 총 연결 수(total number of connections)를 제한하지 않음
  • keepalive 지시어는 upstream{} 블록에 나열된 서버 수의 두 배로 설정하는 것이 좋음
  • 두배 설정은 nginx가 upstrem 모든 서버와의 keep-alive 연결을 유지하기에 충분히 크며, upstream 서버에 새로 들어오는 연결도 처리 가능하도록 작음
     
  • upstream{} 블록에서 hash, ip_hash, least_conn, least_time, random 지시어를 사용하여 load‑balancing algorithm 을 지정
  • hash, ip_hash, least_conn, least_time, random 지시어가 keepalive 지시어 위에 표시 필요(필수) 

• 요청을 upstream으로 전달하는 location{} 블록에 proxy_pass 지시어와 함께 아래 지시어를 포함
  • nginx는 upstream 서버에 대한 연결에 HTTP/1.0을 사용 → 서버로 전달되는 요청에 Connection: close 헤더를 추가
  • upstream{} 블록에 keepalive 지시어가 있음에도 불구하고 요청이 완료되면 각 연결이 닫힘
  • proxy_http_version 지시어는 nginx가 HTTP/1.1을 대신 사용하도록 지시 → proxy_set_header Connection "" 헤더를 통해서 close 값을 제거함
    

    proxy_http_version 1.1;
    proxy_set_header Connection "";

     

• proxy_http_version 지시자
  • 프록시 서버를 위한 HTTP 프로토콜 버전을 설정
  • 기본적으로 버전 1.0이 사용
  • keep-alive 연결 및 NTLM 인증과 함께 사용하려면 버전 1.1을 사용하는 것이 좋음
    

    구문 :	proxy_http_version 1.0 | 1.1;
    기본 :	proxy_http_version 1.0;
    문맥 :	http, server, location​

     

• proxy_set_header Connection "" 설정
  
  • nginx서버에서 upstream으로 요청을 프록시할 때 HTTP 버전을 1.0으로, Connection 헤더를 close로 바꿔서 보냄
  • upstream으로 keepalive 커넥션을 사용하기 위해서는 프록시 HTTP 버전을 1.1로 변경해야 한다고 권장
  • 추가적으로 proxy_set_header Connection "" 설정을 통해 Connection 헤더를 없애주는 설정 진행
    
    
  • upstream 서버로 HTTP 버전을 1.0, Connection 헤더를 close으로 전송
    

    

  • upstream 서버로 HTTP 버전을 1.1, Connection 헤더를 초기화하여 전송
    

    

참고 자료 : Avoiding the Top 10 NGINX Configuration Mistakes - NGINX

참고 자료 : https://seungtaek-overflow.tistory.com/10

• error_log off 지시문으로는 로깅을 비활성화 불가 → access_log 지시어와 달리 error_log는 off 매개 변수를 사용하지 않음
• 만약 nginx에 error_log off 지시어를 포함하면 nginx 구성 파일의 기본 디렉토리(/etc/nginx)에 off라는 이름의 에러 로그 파일을 생성됨
   
• error_log 로그는 nginx의 문제를 디버깅할 때 중요한 정보 소스이므로 비활성화하지 않는 것이 좋지 않음
• 만약 스토리지가 너무 제한적이어서 사용 가능한 디스크 공간을 모두 소진할 정도의 경우 오류 로깅을 비활성화하는 것이 좋음
  
  
• main 설정에 error_log 지시어 사용 예시
  

  error_log /dev/null emerg;​

• error_log 지시어
  • 여러 개의 로그를 지정 가능 
  • main configuration 수준에서 로그를 쓰는 것이 명시적으로 정의되어 있지 않으면 기본 파일이 사용
    

    구문 :	error_log file [level];
    기본 :	error_log logs/error.log error;
    문맥 :	main, http, mail, stream, server, location​

     

• error_log 지시어의 매개변수
  1. error_log 첫 번째 매개변수
     • 로그를 저장할 파일을 정의
     • stderr 특수 값은 표준 오류 파일(standard error file)을 선택 
     • "syslog:" 접두사를 지정하여 syslog에 로깅하도록 구성 가능 
     • "memory: size" 접두사와 버퍼 크기를 지정하여 순환 메모리 버퍼에 로깅 구성 가능. 일반적으로 디버깅에 사용
        
  2. erorr_log 두 번째 매개변수
     • 로깅 수준을 결정
     • debug, info, notice, warn, error, crit, alert 중 하나가 될 수 있음
     • 로그 수준(Log levels)은 심각도가 높아지는 순서대로 나열
     • 특정 로그 수준(certain log level)을 설정하면 지정된 로그 수준보다 더 심각한 로그 수준의 모든 메시지가 기록됨 → 예시) 오류 로그(error log)는  error, crit 및 alert  메시지가 기록됨
     • error_log 매개 변수를 생략하면 error가 사용

• error_log 지시어는 nginx가 구성을 읽고 유효성을 검사할 때까지 적용되지 않는다는 점에 유의
• nginx가 시작하거나 구성이 다시 로드될 때마다 구성의 유효성이 검사 → 기본 error log(/var/log/nginx/error.log) 로깅
• 로그 디렉터리를 변경하려면 nginx 명령에 -e <error_log_location> 파라미터를 포함

참고 자료 : Avoiding the Top 10 NGINX Configuration Mistakes - NGINX

• worker_connections 지시어는 nginx의 worker process가 열 수 있는 최대 동시 연결 수를 설정(기본값은 512). 
• 클라이언트 연결뿐만 아니라 모든 유형의 연결(프록시 서버와의 연결)이 최대 연결 수에 포함 → proxy_pass도 포함
• worker당 동시 연결 수에는 다른 제한이 있음 → 각 프로세스에 할당된 File Descriptors(파일 설명자)의 최대 수에 대한 OS 제한 
• 최신 UNIX 배포판에서  File Descriptors(파일 설명자)의 최대 수에 대한 기본 제한은 1024개
• 가장 작은 규모의 nginx 배포를 제외한 모든 배포에서 worker당 512개의 연결 제한은 너무 작을 수 있음 
• 이 문제를 해결하려면 기본 구성 컨텍스트에서 worker_rlimit_nofile 지시어를 사용하여 설정

• worker_rlimit_nofile 지시자
  • worker process의 최대 파일 열기 수 제한(RLIMIT_NOFILE)을 변경 
  • Main Process를 다시 시작하지 않고 제한을 늘리는 데 사용
    

    구문 :	worker_rlimit_nofile number;
    기본 :	—
    문맥 :	main​

• 더 많은 File Descriptors(파일 설명자)가 필요한 이유
  • nginx worker process에서 클라이언트 또는 업스트림 서버로의 각 연결은 File Descriptors를 소비 
  • nginx가 웹 서버로 작동하는 경우, 클라이언트 연결에 하나의 File Descriptors를 사용하고 제공되는 파일당 하나의 File Descriptors를 사용하여 클라이언트당 최소 2개의 File Descriptors를 사용
  • 프록시 서버로 작동하는 경우, nginx는 클라이언트 및 업스트림 서버 연결에 각각 하나의 File Descriptors 사용(2개 사용)하고, 서버의 응답을 임시로 저장하는 데 사용되는 파일에 세 번째 File Descriptors를 사용
  • nginx가 캐싱 서버로 작동하는 경우, 캐시된 응답에 대해서는 웹 서버처럼 작동하고 캐시가 비어 있거나 만료된 경우에는 프록시 서버처럼 작동
  • nginx는 로그 파일당 File Descriptors를 사용하고 Master 프로세스와 통신하기 위해 몇 개의 File Descriptors를 사용 → 일반적으로 몇 개의 File Descriptors 숫자는 연결 및 파일에 사용되는 File Descriptors의 수에 비해 작음

• UNIX는 프로세스당 File Descriptors 수를 설정하는 몇 가지 방법을 제공
  1. nginx를 시작하는 경우 ulimit 명령어
     • ulimit 명령어는 프로세스가 사용하는 자원에 대한 제어 및 관리할 수 있게 해줌
     • ulimit 명령어는 하나의 유저(쉘,프로세스)에 대해서 할당할 자원량의 한계를 정하는 것으로서 리눅스 시스템에서 과부하를 막아주는 방패가 되어 주는 유용한 설정
     • ulimit는 일시적 설정
       

       $ ulimit -n 65536

        
     • soft와 hard 두 가지 타입
       • soft → 새로운 프로그램을 생성하면 기본으로 적용되는 한도
       • hard → soft 한도에서 최대로 늘릴 수 있는 한도
          
  2. nginx를 서비스로 시작하는 경우 init 스크립트 또는 systemd 서비스 manifest 변수 사용
     

     $ vi /etc/systemd/system/nginx.service
     [Unit]
     Description=The NGINX HTTP and reverse proxy server
     After=syslog.target network.target remote-fs.target nss-lookup.target
     
     [Service]
     Type=forking
     PIDFile=/run/nginx.pid
     ExecStartPre=/usr/local/nginx/sbin/nginx -t
     ExecStart=/usr/local/nginx/sbin/nginx
     ExecReload=/usr/local/nginx/sbin/nginx -s reload
     ExecStop=/bin/kill -s QUIT $MAINPID
     PrivateTmp=true
     LimitNOFILE=65535
     LimitNOFILESoft=65535
     
     [Install]
     WantedBy=multi-user.target​​

      
  3. /etc/security/limits.conf 파일 → 유저의 프로세스별 file open을 설정
     • /etc/security/limits.conf 파일은 유저의 프로세스별 사용하는 자원에 대한 제어 및 관리할 수 있게 해줌
     • 할당할 자원량의 한계를 정함으로 리눅스 시스템에서 과부하를 막아줌
       
       
     • /etc/security/limits.conf 파일은 영구적 설정
       

       $ vi /etc/security/limits.conf
       
       ## nginx 사용자 계정에 수치를 지정
       nginx   soft  nofile  1048576
       nginx   hard  nofile  1048576
       nginx   soft  nproc   1048576
       nginx   hard  nproc   1048576
       
       ## *를 사용하여 모든 계정에 수치를 지정
       *   soft  nofile  1048576
       *   hard  nofile  1048576
       *   soft  nproc   1048576
       *   hard  nproc   1048576​

      
  4. sysctl.conf 의 file open 확인 및 커널 설정
     • sysctl.conf에서 시스템 전체에 대한 file open 개수를 설정
       

       $ cat /proc/sys/fs/file-nr
       3072    0       300000
       |         |       |
       |         |       |
       |         |       최대 오픈 파일 디스크립터 수(fs.file-max)
       |        할당되지 않은 파일 디스크립터 수 (2.6 커널에서는 항상 0으로 표기되며 이는 에러 아님)
       할당된 파일 디스크립터 수

        
     • 커널의 fs.file-max 파라미터는 시스템 전체에서 최대로 열 수 있는 파일 개수
     • 커널의 fs.file-max 파라미터는 시스템의 메모리를 KB로 표현한 값의 10%가 적당
     • 커널의 fs.nr_open 파라미터는 하나의 프로세스가 열 수 있는 최대 파일 개수
     • 커널의 fs.nr_open 파라미터는 기본값은 1024*1024 (1048576) → 대부분의 머신에서 충분(Actual limit depends on RLIMIT_NOFILE resource limit.)
        
     • 커널의 fs.file-max 파라미터와 fs.nr_open 파라미터 설정 확인 및 변경
       

       ## 기존 설정값 확인
       $ sysctl -a | grep fs.file-max
       fs.file-max = 300000
       
       $ cat /proc/sys/fs/file-max
       300000
       
       ## 기존 파라미터 값 수정
       $ vim /etc/sysctl.conf
       fs.file-max = 1048576
       
       ## 설정 값 적용
       $ sysctl -p
       
       
       ## 변경 설정값 확인
       $ sysctl -a | grep fs.file-max
       fs.file-max = 300000
       
       $ cat /proc/sys/fs/file-max
       300000
       
       $ cat /proc/sys/fs/file-nr
       3008    0       1048576

• 시스템 전체에 File Descriptors 수에 대한 제한이 있으며, OS의 sysctl fs.file-max 명령으로 설정 가능
• nginx를 시작하는 방법에 따라 다르지만, worker_rlimit_nofile은 nginx를 시작하는 방법에 작동
• 모든 nginx worker process가 사용할 수 있는 최대 파일 설명자 수(worker_rlimit_nofile * worker_processes)가 fs.file-max보다 훨씬 적은지 확인 필요
• nginx가 사용 가능한 모든 File Descriptors를 사용하는 경우(예: DoS 공격), 문제를 해결하기 위해 컴퓨터에 로그인하는 것조차 불가능해짐

※ File Descriptor(파일 디스크립터)

• 리눅스 혹은 유닉스 계열의 시스템에서 프로세스(process)가 파일(file)을 다룰 때 사용하는 개념
• 프로세스에서 특정 파일에 접근할 때 사용하는 추상적인 값
• File Descriptor(파일 디스크럽터)는 일반적으로 0이 아닌 정수값을 갖음

참고 자료 : 가장 많이 실수하는 NGINX 설정 에러 10가지 - NGINX STORE

참고 자료 : file open 확인 및 커널 설정 : 네이버 블로그 (naver.com)