Nginx의 기본 구성, Configuration file 분석, 정적 컨텐츠 처리

지난 포스트에서 AWS EC2 인스턴스에 Nginx를 설치하고, 브라우저에서 Public IP 주소로 접속하여 Default 웹 페이지가 띄워지는 것을 확인하였다. 이제 단기 목표는 우리가 준비한 정적 컨텐츠(static contents)를 웹 서버를 통해 유저에게 제공하는 작업을 구현하고 이해하는 것이다.

Nginx가 동작하는 기본적인 원리에 대해서 이해하면 좋을 것 같다. 더 넓고 엄밀한 의미에서 웹 서버가 어떻게 동작하는지에 대해 알기 위해서는 Nginx의 코드를 뜯어보고 이해해야 하겠지만, 우선은 정성적으로 configuration file의 구성요소들을 이해함으로써 더 얕은 수준의 이해를 추구할 것이다.

※ 포스트의 내용은 글이 쓰여진 일자(2016년 3월 14일) 기준으로 가장 최신의 NGINX 버전인 1.9.12 버전을 기준으로 작성되었다.

1) Nginx 의 기본 원리 이해

참고 링크

• Nginx 공식 홈페이지의 리소스 문서
  

Nginx는 하나의 master process와 하나 이상의 worker process로 구성되어 있다. 

• master process : configuration file을 읽고 실행하며, worker process 들을 관리한다.
• worker process : 유저가 요청한 request에 대한 실제 작업을 수행한다.

Nginx를 이용해서 웹 서버를 관리하는 작업은, configuration file 을 작성하고 수정함으로써 간접적으로 이뤄진다. master process가 configuration file을 읽고 실행하기 때문이다. 그러므로 웹 서버의 동작을 설정하기 위해서는 configuration file을 수정하면 된다. 

수정된 configuration file의 내역을 반영시키기 위해서는 Nginx 를 stop 하고 다시 start 하면 된다. master process에 "nginx -s signal" 커맨드로 signal을 보내거나 Unix가 제공하는 kill 유틸리티를 사용하는 방법도 가능하다. 이를 위해서는 master process를 지칭하는 process ID 값이 필요한데, /usr/local/nginx/logs 혹은 /var/run 디렉토리에 있는 nginx.pid 파일에서 확인할 수 있다.

2) Configuration File 분석

참고 링크:

• NGINX.ORG 홈페이지 Documentation
• 어느 외국인 블로거의 포스트
  

Nginx는 module로 구성된다. module은 configuration file에 적힌 directive로 제어한다. directive에는 두 가지 종류가 있다. simple directive와 block directive가 그것이다.

- simple directive : name 과 parameter 가 space 로 구분되고 semicolon(;) 으로 끝난다.

- block directive : semicolon 대신에 { } 로 둘러쌓인 additional arguments 으로 끝난다. 

block directive 들 중에서 { } 안에 다른 directives 들이 들어간 경우는 context라고 한다. 대표적인 예로 events, http, server, location directives 가 있다. 어떤 context 에도 속하지 않고, 바깥에 나와있는 directive 들은 main context에 속해있는 것으로 간주한다. 

배경지식을 갖췄으니, Nginx 1.9.12 버전의 default configuration file 을 분석해보자. /etc/nginx 디렉토리에 위치한 nginx.conf 파일을 분석할 것이다.

아래는 웹 서버의 기본적인 동작을 정의하는 core directive 부분이다.

user    nginx;

worker_processes    1;

error_log    /var/log/nginx/error.log warn;

pid    /var/run/nginx.pid;

user : Linux 시스템의 어느 user가 Nginx 서버를 소유하고 동작시킬지를 기술한다.

worker_processes : 몇개의 thread 가 사용될지 정의한다. CPU 코어수에 맞추는것이 권장된다.

error_log : 에러 로그를 어느 위치의 어느 파일에 기록할지를 정의한다. 기록하는 모드도 정할 수 있다. 위에서는 warn 모드로 설정했다. debug 모드도 가능하다.

pid : 앞서 언급한 부분이다. process ID를 어느 위치의 어느 파일에 기록할지 선언한다.

그 다음으로 context 들을 살펴보자. 우선 events 블록이다.

events {

worker_connections    1024;

}

worker_connections : worker process 하나당 몇개의 connection 을 처리할지 뜻한다. 여기에 worker_processes 값을 곱하면 최대 몇개의 connection을 동시에 처리할 수 있는지 나온다.

다음은 http 블록이다. HTTP 웹 트래픽 처리 전반에 대해 기술하므로 universal directive 라고도 부른다.

http {

include    /etc/nginx/mime.types;

default_type    application/octet-stream;

log_format    main    (복잡해서 생략.....)

access_log    /var/log/nginx/access.log    main;

sendfile    on;

#tcp_nopush    on;

keepalive_timeout    65;

#gzip    on;

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

}

(일부 directives 들에 대해서만 분석하고, 나머지는 스킵할 것이다)

include : 외부 문서에 적힌 configuration 내용을 참조할 때 쓰인다. 위의 경우는 /etc/nginx 디렉토리의 mime.types 문서와, /etc/nginx/conf.d 디렉토리의 .conf 확장자를 가진 모든 문서들에 적힌 directives 들이 http directives 내부에 포함되어 있는 것으로 처리된다는 뜻이다. 실제로 /etc/nginx/conf.d/default.conf 문서를 확인해보면 server directive 가 적혀있다. 덕분에 이전 포스트에서 public IP로 접속을 시도했을 때 Nginx 기본 웹페이지를 서비스 해준 것이다.

access_log : NGINX 웹 서버로 접속한 내역들을 어느 문서에 적을지 정의한다.

3) 정적 컨텐츠 처리

/etc/nginx/conf.d 디렉토리의 default.conf 문서에 적힌 server directive 가 default server 역할을 정의하고 있었다. 그러므로 해당 include directive 앞에 #를 붙여서 주석처리한다. 그 뒤에 직접 server directive 를 기술해보면서, server 와 location directive에 대해서 알아보겠다. 아래와 같이 간단하게 구성해보았다.

http {

(...)

server {

location / {

root    /data/www;

}

}

}

server directive의 본질에 대해서는 아직 파악하지 못했다. 다만 정적 컨텐츠를 처리하는 웹 서버를 하나 만들기 위해서는 server directive 한 덩어리를 만들어야 한다고 이해했다.

어떻게 정적 컨텐츠를 처리하게 할 수 있을지 생각해보자. 간단하게 생각하면, 서버에서 브라우저로 보내줄 정적 컨텐츠들을 작성하고, 특정 디렉토리에 위치 시키고, 서버 컴퓨터의 파일 시스템 디렉토리와 유저들이 요청할 URL을 적절히 매핑(mapping) 시키면 될 것이다. 이를 기술한 것이 location directive 라고 볼 수 있다.

location 뒤에 붙는 인자가 호스트 네임(host name) 뒤에 붙는 URL 패턴이 들어가는 자리이다. 위의 경우는 '/'이므로 호스트 네임 뒤에 붙는 임의의 패턴을 처리하겠다는 의미이다. 하위의 root directive의 뒤에 붙는 인자가 대응되는 파일 시스템 디렉토리의 기준점을 뜻한다. 예를 들어 http://52.79.132.69/index.html의 URL이 요청되면 /data/www/index.html 파일을 서비스해준다. 직접 확인해보면 아래와 같이 저장해놓은 index.html 문서를 띄우는 걸 확인할 수 있다. 엄밀히는 52.79.132.69/index.html의 URL을 요청해야겠지만, default로 디렉토리 내의 index.html 파일을 띄우나보다.