[nginx] (2) nginx.conf

nginx

---

1. nginx의 구조

  nginx는 C언어로 개발되었다. 그리고 nginx는 일반적으로 Linux나 Unix계열 OS에 얹어서 사용한다. Win32에서도 사용할 수 있다고 하지만, select()만 사용할 수 있어서 성능적으로 매우 비효율적이며, 앞으로의 확장성도 기대하기 어렵다고 한다.

 

 OS에 따라 다른 설치법을 제공하니 공식문서를 확인하자.

 

 설치를 하고 나면 구성 파일이 기본적으로 세팅되어 있으므로 nginx명령어를 통해 바로 실행시킬 수 있다.

 

sudo nginx

 

 다음과 같이 실행하면 nginx는 구성파일인 nginx.conf를 읽고 구동을 시작한다. 이때 nginx.conf에 없는 필수 정보들은 기본값으로 세팅한다. 실행 후 ps -ef명령어를 통해 프로세스 목록을 확인하면 다음과 같다.

 

ps -ef

 기본적으로 nginx를 설치하면 nginx.conf에서 Worker Process의 수는 auto로 설정되어 있다. auto 옵션은 일반적으로 논리 프로세서의 수로 설정이 된다. 본인 컴퓨터는 12-Core 24-Thread라 1개의 Master Process와 24개의 Worker Process가 생성된 것으로 보인다.

 

 다음으로 nginx를 중지하거나 구성파일을 라이브로 리로드하기 위해서는 nginx -s [option]을 사용한다.

• stop - 빠른 종료
• quit - 우아한(Graceful) 종료 (Worker Process가 현재까지의 요청 처리를 완료할 때까지 프로세스를 대기했다가 종료)
• reload - 구성파일 다시 로드 (기존의 Worker Process들을 유지한 채로 새로운 구성파일을 이용해 Master Process가 새 Worker Process를 시작하고, 모든 과정이 성공적이라면 이전 Worker Process들을 Graceful하게 종료)
• reopen - 로그 파일 다시 열기

 

---

2. nginx.conf의 구조

 nginx는 일반적으로 nginx.conf에 지시된 지시문으로 nginx를 제어한다. 따라서 nginx.conf를 잘 작성하면 nginx를 잘 다룰 수 있다.

 

 nginx의 지시문은 단순 지시문과 블록 지시문으로 구분된다.

• 단순 지시문 - [지시문] [파라미터]; 형태.
• 블록 지시문 - [지시문] [(파라미터)] {중괄호} 형태.

단순 지시문

worker_processes auto;

 

블록 지시문

events {
	worker_connections 512;
}

 

 또 블록 지시문의 중괄호 안에 또 다른 지시문을 가질 수 있는 경우 이를 컨텍스트라고 한다.

 

nginx.conf 안에서 지시문의 가장 큰 단위는 main 컨텍스트이며 그 안에 다양한 트래픽 유형에 따라 지시어를 그룹화하는 몇 개의 컨텍스트가 있다.

 

nginx.conf의 컨텍스트

• main
  • events - 일반적인 연결 처리
  • http - HTTP 트래픽
  • mail - Mail 트래픽
  • stream - TCP/UDP 트래픽

웹 애플리케이션을 구동하는 등의 기초적인 상황에서는 events, https만 있어도 무방하다.

 

 

---

3. nginx.conf 작성하기

 nginx는 오픈소스 버전과 엔터프라이즈를 위한 유료버전인 nginx plus가 있다. 로드 밸런싱의 health check 기능 같은 건 유료버전에서만 지원하니 사용할 때 잘 알아보자.

 

# main : 메인 컨텍스트

# user user [group];
# Worker Process가 어떤 user, group으로 실행되는지에 대한 설정
# user root root;로 할 경우 리눅스 파일 시스템의 모든 권한을 갖게 되므로 일반적으로 user nginx nginx;로 설정
# group을 생략할 경우 user와 같은 이름이 지정됨
# default : nobody
user  nginx nginx;

# worker_processes number | auto;
# Worker Process의 수
# CPU 코어 수, 하드디스크 수 등에 따라 최적의 수는 달라질 수 있으므로 일반적으로 CPU 코어의 수로 설정
# worker_processes auto;로 두는 게 일반적
# default : auto
worker_processes auto;

# worker_priority number(-20 ~ 20);
# Worker Process의 스케줄링 우선순위를 지정
# Linux에서 프로세스가 실행될 때 nice값에 따라 실행 우선순위가 주어짐
# worker_priority는 Worker Process의 이 값을 조정함
# 커널이 -5 정도의 우선순위로 실행되므로 이 값 이하의 값을 설정하는 것은 권장되지 않음
# default : 0
worker_priority -1;

# debug_points abort | stop;
# 디버깅을 위한 설정
# Worker Process 재시작 시 소켓의 리크 등과 같은 내부 오류가 발생했을 때
# abort(파일 생성)로 설정하면 시스템 디버거를 이용해 추가적인 코어 파일 생성
# default : abort
debug_points abort;

# error_log filePath [level];
# 로깅 구성
# 첫번째 파라미터 filePath에 로그의 위치를 지정할 수 있음
# 두번째 파라미터 level은 레벨에 따라 debug, info, notice, warn, error, crit, alert, emerg중에 선택
# 선택한 레벨 이상 수준의 로그만 기록됨
# main 컨텍스트뿐만 아니라 하위 어느 컨텍스트에도 재정의할 수 있음
# 하지만 재정의 했을 때 level를 적지 않으면 아예 로깅을 제외한다는 뜻이 되므로 주의
# 참고 : https://nginx.org/en/docs/ngx_core_module.html#error_log
# default : logs/error.log error
error_log logs/error.log error;

# load_module file;
# 다이나믹 모듈을 로드함
# nginx의 확장 기능이 필요한 경우, 서드파티 모듈을 추가할 수 있음
# 추가적으로 nginx -V 명령어에서 --with커맨드 부분을 확인하면 모듈을 확인할 수 있음
#load_module xxx;

# worker_rlimit_core number;
# Worker Process 당 코어 파일의 크기
worker_rlimit_core 100m;

# worker_rlimit_nofile number;
# Worker Process가 동시에 사용할 수 있는 파일의 최대 개수
worker_rlimit_nofile 2048;


# event : Connection 처리에 영향을 주는 지시문을 지정하는 컨텍스트
events {
	# worker_connections number;
	# 하나의 Worker Process에서 열 수 있는 최대 동시 연결 수
	# 이 숫자는 클라이언트와의 연결 뿐만 아니라 프록시 서버와의 연결을 포함한 모든 연결의 숫자임
	# 그리고 당연히 이 숫자는 worker_rlimit_nofile에 정의된 숫자를 넘을 수 없음
	# main 컨텍스트의 worker_processes가 4, 현재 worker_connections가 1024라면
	# worker_processes * worker_connections = 4096, 즉 최대 동시 접속이 4096 언저리까지 가능
	# default : 512
	worker_connections 1024;

	# use [method];
	# 연결 처리에 어떤 메서드를 사용할 것인지 결정
		# select - File Descriptor를 배열로 관리하며 배열을 순회하면서(O(n)) 이벤트가 발생했는지 체크하고 전체 File Descriptor가 매번 전달. OS 이식성 좋음
		# poll - select와 비슷하나 장단점이 있음. 접속량이 많아지면 오히려 select보다 성능 떨어짐. OS 이식성 나쁨
		# epoll - 리눅스에서 select의 단점을 보완한 방식.
		# kqueue - BSD계열에서의 epoll 방식
	# ※ nginx는 기본적으로 가장 효율적인 방법을 사용하기 때문에 굳이 적어줄 필요는 없다.
	use epoll;
}

# http : HTTP 서버에 대한 지시문을 지정하는 컨텍스트
http {
	# include file | mask;
	# 다른 file이나 mask와 매칭되는 파일들을 구성 파일로 임포트
	# 어느 컨텍스트에도 추가할 수 있음
	# 일반적으로 중복된 부분은 nginx.conf에 남기고
	# 상황 별로 다른 설정들은 upstream.conf, header.conf 등으로 분리한 뒤 임포트해서 씀
	include mime.types; # nginx내에서 처리할 MIME 타입 모음 임포트. nginx.conf와 동일 디렉토리에 mime.types 참고

	upstream backend_tomcat_server {
		server b1.churnobyl.com weight=5;
		server 127.0.0.1:8081 max_fails=3 fail_timeout=30s;

		server backup1.churnobyl.com backup;
	}

	# server : 가상 서버 (Virtual Server)에 대한 지시문을 지정하는 컨텍스트
	server {
		# server_name name ...;
		# 가상 서버의 이름을 설정
		# 정규표현식(Regex), *(asterisk)도 사용가능
		# default ""
		server_name churnobyl.com *.churnobyl.com;

		listen 80;

		# location [ = | ~ | ~* | ^~ ] uri { . . . } or location @name uri { . . . }
		# uri 혹은 name 두 방식을 사용할 수 있음
		#
		location ~* / {
			proxy_pass https://backend_tomcat_server;

			health_check;
		}
	}
}

 

 main컨텍스트와 events, http 컨텍스트만 포함하는 간단한 예제이며, 더 자세한 내용은 공식 문서의 핵심 기능, 알파벳 순 지시문을 살펴보자. 추가적으로 위의 코드는 개념을 위해 nginx.conf에 다 몰아 적었지만, 실제 사용할 때는 중복되는 내용만 nginx.conf에 적고 나머지는 용도에 따라 http.conf, stream.conf, http_dev.conf등으로 다른 파일로 뺀 뒤 import해서 사용한다.