nginx.conf 설정

DevOps

nginx.conf 설정

jungmin.park 2024. 1. 9. 11:59

NGINX 모듈 기본 구조

Nginx는 크게 핵심 모듈(Core Module), 이벤트 모듈(Event Module), 구성 모듈(Configuration Module), HTTP 모듈로 구성되어있다.

nginx.conf 파일에는 접속자수, 동작 프로세스수등 퍼포먼스에 기본적인 설정 항목을 담고 있다.

핵심모듈(Core Module) : Nginx의 프로세스 관리, 보안, 필수 기능 등등 설정하는 부분이다.
이벤트 모듈(Event Module) : Nginx가 네트워크 동작방법에 설정하는 부분이다.
구성 모듈(Configuration Module) : Nginx에서 구조 include를 통해 외부 파일을 포함시키는 부분이다.
HTTP 모듈 : Nginx에서 웹사이트를 설정하는 부분이다.

Nginx 프로세스 구조

nginx의 실행이 막 시작된 순간에는 마스터 프로세스(Master Process)라 부르는 특별한 프로세스 한 개만 존재한다.

마스터 프로세스 자신은 어떤 클라이언트 요청도 처리하지 않으며 단지 그 일을 대신 수행할 작업자 프로세스를 낳아서 증식(invoke) 하는데, 이때 작업자 프로세스의 사용자/그룹은 바뀐다. 환경설정에서 작업 프로세스 수, 작업자 프로세스당 최대 접속 수 등을 설정 가능하다.

핵심모듈(Core Module)

NGINX의 프로세스 관리, 보안, 필수 기능 등등 설정하는 부분이다.

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
worker_rlimit_nofile 204800;
worker_rlimit_sigpending 10000;
keepalive_timeout 15s;
error_log  /webserver/nginx/logs/error.log warn;
master_process on;

nginx.conf 파일을 보면 가장 상단에 보이는 구간이다.

user : nginx 프로세스가 실행되는 권한
- www-data : 보안과 관련이 있어 해당 권한이 탈취 당하더라도 ssh를 비롯한 접속 및 파일 액세스가 불가능하기 때문에 위처럼 설정되어있다.
worker_processes : nginx 프로세스 실행가능한 수
- 코어 개수 알아내기 : grep processor /proc/cpuinfo | wc -l
- auto : auto로 실행 할 경우 자동으로 CPU 코어 개수에 알맞게 프로세스를 생성해준다.
- 물리적인 CPU 코어 개수만큼 worker_process 를 할당하는 것이 가장 이상적
- 각 코어는 서로 프로세스를 공유하지 않기 때문에, 모든 코어당 1개의 worker process를 사용하면 전체 서버의 리소스를 최대로 사용하는 것이다.
- 그런데 때로는 10~20% 정도는 CPU코어는 운영체제를 위해 남겨두는 방법도 좋다.
  - 예) 20core CPU를 구성했다면, Nginx에 대해 사용할 코어수를 16~18개 정도로 할당하고, 나머지 2~4는 OS용으로 남겨두는것도 좋다.
pid : nginx 마스터 프로세스 ID 정보가 저장 (default = logs/nginx.pid)
worker_rlimit_nofile : 작업자 프로세스가 동시에 사용할 수 있는 파일의 수를 정의
worker_rlimit_sigpending : 사용자(호출 프로세스의 사용자 ID)당 대기할 수 있는 시그널 수를 정의
- 대기열(queue)이 꽉 차면 이 한계치를 넘은 시그널은 무시된다.
keeplive_timeout : 접속시 커넥션을 몇초동안 유지할지에 대한 설정값, 이 값이 높으면 불필요한 커넥션(접속)을 유지하기 때문에 낮은값 또는 0을 권장한다.(default = 10)
error_log : 로그파일 경로와 남기고자 하는 심각도 레벨. (default = logs/error.log) 레벨은 다음 값 중 하나이다.(심각도 오름차순) 으로 (defalut = error) 가장 상세한 로그 레벨 debug, info, notice, warn, error, crit, alert, or emerg, 애플리케이션, HTTP 서버, 가상 호스트, 가상 호스트 디렉토리 각각에 대해 다른 레벨로 에러로그를 설정할 수 있다.
master_process : on으로 설정하면 nginx는 다수의 프로세스, 즉 하나의 메인 프로세스(마스터 프로세스)와 여러개의 작업 프로세스를 시작할 수 있다. off로 설정하면 nginx는 단일 프로세스만으로 작동

이벤트 모듈(Event Module)

nginx는 비동기 이벤트 방식의 처리 방식을 가지고 있는데 event block은 그 처리에 관련된 네트워크 동작방법을 설정하는 부분이다.

events {
        worker_connections 1024;
        multi_accept on; #기본값:off;
        use epoll;
}

worker_connections : 하나의 프로세스가 처리할 수 있는 커넥션의 수로 최대 연결 수
- client와의 연결만 포함시키는 것이 아닌 모든 connection을 포함한다.
- (주의) worker_rlimit_nofile 값을 초과해서 세팅하면 worker_rlimit_nofile 값이 우선시 된다.(defalut = 512)
- worker_processes * worker_connections = 최대 접속자 수
- 최대 한계 커넥션 수 계산 : ulimit -n 으로 CPU 코어의 커넥션 허용수를 확인해본다.
multi_accept : 작업자 프로세스는 한 번에 하나의 새 연결을 승인한다. 활성화된 경우 작업자 프로세스는 한 번에 모든 새 연결을 수락한다.
accept_mutex : LISTEN 소켓을 오픈하기 위한 accept 뮤텍스의 사용/해제를 설정
accept_mutex_delay : 자원의 획득을 다시 시도하기 전에 작업 프로세스가 기다려야 하는 시간의 양을 정의한다. accept_mutex 지시어가 off로 설정되어있으면 이 값은 사용되지 않는다.
use epoll

non-blocking I/O를 사용하는 Single Thread 방식의 nginx에서는 자신에게 연결되어 있는 socket에 읽을 데이터가 있는지 계속 확인하는데 자원을 낭비할 수 있다.

epoll 방식은 nginx의 모든 소켓 파일을 찾아보는것이 아닌 현재 활성화 된 소켓만 확인해서 연결을 설정해준다.

epoll은 linux 소켓을 관리하는 방법중 하나인데 이외에도 poll, select 방식이 있다. 모든 소켓파일을 확인하는 poll 방식에 비해서 업그레이드 된 버전

이 중 poll과 select는 해당 프로세스에 연결된 모든 connection file을 스캔하지만, epoll은 수천개의 file descriptor을 처리할 수 있도록 보다 효율적인 알고리즘을 사용하고 있어 대량 요청이 발생하는 시스템에 적합하다고 한다.

HTTP모듈(HTTP Module)

http 블록은 nginx로 들어오는 웹 트래픽에 대한 처리 방법과 방향을 설정해주는 블록으로 http 모듈을 3개의 블록으로 구성된다.

HTTP 블록 : nginx 구성 파일의 최상위에 삽입되며 , SERVER, LOCATION의 상위 블록이다. 설정된 값은 하위블록에 상속
SERVER 블록 : 웹사이트를 추가하는 1개를 선언하는데 사용되며, SERVER 블록을 여러개 만들어서 동시에 여러 사이트 운영이 가능하다.
LOCATION 블록 : SERVER 블록 안에 특정 위치 디렉토리 URL조작을 처리하는데 사용

http {

        upstream spring-server{
                #least_conn;
                server [ip 주소];
                server [ip 주소];
                keepalive 100; //keepalive 갯수
                keepalive_timeout 30; // keeplive의 생존 시간 (초)
        }

Keepalive

keepalive 설정을 해주면 불필요한 handshake 과정을 줄일 수 있다.
keepalive는 클라이언트의 연결 요청을 처리한 후 바로 연결을 끊는 것이 아니라, 연결을 끊지 않고 일정시간 대기하는 시간
keepalive_timeout : 서버 접속시 클라이언트와 커넥션을 열린채로 유지하는 시간(0으로 잡으면 keepalive 비활성)

Reverse Proxy 설정

nginx을 리버스 프록시로도 활용을 할 수 있다. 리버스 프록시는 외부 클라이언트에서 서버로 접근 시, 중간에 중개자 역할을 하여 내부 서버로 접근할 수있도록 도와주는 서버이다. 리버스 프록시를 활용했을 때 얻을 수 있는 장점은 보안, 로드밸런싱이 있다.

보안 : 외부 사용자로부터 내부망에 있는 서버의 존재를 숨길 수 있다. 모든 요청은 리버스 프록시 서버에서 받으며, 매핑되는 내부 서버로 요청을 전달한다. 또는 nginx는 SSL 설정도 가능하다.
로드밸런싱 : 리버스 프록시 서버가 내부에 대한 정보를 알고 있으므로, 각 서버의 상태에 따라 부하를 분산시키며 요청을 전달할 수 있다.
리버스 프록시 구성은 다음과 같이 location / {} 안에 구성해준다.

 server {
                #listen 80;
                server_name yetiyt.shop;

                include /etc/nginx/default.d/*.conf;

                location / {
                		listen 80;
                        ...
                        proxy_pass http://spring-server;
                        ...
                }

Reference

https://icarus8050.tistory.com/57

https://secjong.tistory.com/19

https://extrememanual.net/9976#google_vignette