Nginx Configuration (2/2)

Nginx Configuration

 

Try Files & Named Locations

 

try_files

try_files file ... uri;

 try_files 지시문은 정적 파일을 제공하는 웹 서버에서 파일을 찾는 방법을 지정하는 데 사용된다. 파일 검색의 순서를 정의하고, 해당 파일이나 경로를 찾지 못한 경우 어떤 동작을 수행할지 지정할 수 있다. try_files 지시문의 구문은 위와 같다.

• file ...: 파일 검색의 순서를 정의한다. 여기에 나열된 파일이나 경로들은 차례대로 검색된다. 파일 경로는 절대 경로나 상대 경로 모두 가능하다. 파일이나 경로를 찾을 수 없다면 다음으로 넘어간다.
• uri: 파일이나 경로를 찾지 못한 경우 어떤 URI로 요청을 전달할지 지정한다.

 

Named Locations

Nginx에서 Named Location은 특정 위치 블록의 이름을 정의하는 방법이다. 다음과 같은 상황에 자주 사용된다.

• 재사용 가능한 설정: 동일한 설정 블록을 여러 곳에서 사용하려는 경우, 똑같은 설정을 반복해서 작성하지 않고 네임드 위치를 정의하여 필요한 곳에서 참조할 수 있다.
• 복잡한 설정: 복잡한 로직이나 규칙을 가진 위치 블록을 구성할 때, 해당 블록을 명명하여 가독성을 향상시킬 수 있다.
• 에러 페이지: 에러 페이지 처리를 위해 사용될 수 있으며, 특히 사용자 지정 에러 페이지를 정의하는 데 유용하다.

 

Try Files & Named Locations 사용해보기

먼저, try_files $uri /cat.png /greet @friendly_404에 대해서 살펴보자. $uri는 먼저 현재 요청된 URI와 일치하는 파일이나 디렉터리를 검색한다. 첫 번째 시도에서 파일을 찾을 수 없는 경우, /cat.png 라는 파일을 제공하려고 시도한다. /cat.png에서 파일을 찾을 수 없는 경우, /greet가 root에 존재하는지 확인한다. 마지막 시도에서도 처리할 수 있는 결과가 없는 경우 @friendly_404라는 네임드 위치를 참조하여 요청을 처리한다.

두 번째 location 블록의 @friendly_404는 Named Location이며, 파일이나 디렉터리를 찾을 수 없을 때 404 오류 페이지를 제공한다. 이 네임드 위치는 try_files 지시문에서 참조될 수 있으며, 또는 다른 location 블록에서도 참조할 수 있다. 이렇게 함으로써 특정 동작을 중복해서 작성하지 않고도 재사용할 수 있다.

 

결과

 

Logging

로깅은 웹 서버 활동 및 클라이언트 요청에 대한 정보를 기록하고 추적하는 중요한 기능이다. 웹 서버 운영 및 문제 해결을 위해 필수적이며, Nginx는 다양한 로깅 옵션을 제공한다. 위에서 소스코드로 빌드하여 설치할 때 준 옵션에 따라 /var/log/nginx에 error.log와 access.log 파일이 저장되어 있는 것을 확인할 수 있다. 만약에 파일 사이즈가 빈 파일이 아닌 경우에는 echo '' > error.log, echo > '' > access.log 명령어로 파일을 빈 파일로 만들 수 있다.

https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ 해당 공식문서 사이트에서도 자세한 설명을 확인할 수 있다.

 

Log Files

로그 파일은 Nginx 서버 활동 정보를 저장하는 파일로 주요 로그 파일은 다음과 같다.

• Access Logs: 클라이언트 요청에 대한 정보를 포함하며 일반적으로 access.log 파일에 저장된다.
• Error Logs: 서버 오류와 관련된 정보를 포함하며, 일반적으로 error.log 파일에 저장된다.

 

Log File 살펴보기

 

/index.html로 요청을 보내면 다음과 같이 GET /index.html과 GET /style.css 파일을 요청하는 것을 확인할 수 있다.

 

404 페이지 요청

클라이언트가 요청한 페이지를 반환할 수 없는 404 페이지인 경우에는 access.log와 error.log 파일 모두 로그에 기록이 남는 것을 확인할 수 있다.

 

nginx.conf 설정 오류

root 지시자에 오류를 발생시키면 error.log에 root 지시자에 적절하지 않은 argument의 개수가 있다는 것을 알려주는 메시지가 남는 것을 확인할 수 있다.

 

access_log

access_log는 웹 서버에서 클라이언트 요청에 대한 로그를 기록하는데 사용할 수 있는 지시문으로  /secure 경로로 요청이 들어오면 access_log 지시문을 사용하여 로그를 기록하고, 요청에 대한 응답으로 "Welcome to secure area." 메시지를 반환한다. 그리고 secure.access.log 파일이 없는 경우에는 위처럼 생성한 후 로그 기록이 남는 것을 확인할 수 있다.

 

php processing

sudo apt install php-fpm

Nginx와 php-fpm은 웹 서버와 웹 애플리케이션 서버가 협력하여 동적 웹 페이지를 제공하는 데 사용되는 두 가지 중요한 소프트웨어 컴포넌트이다. php-fpm의 특징은 다음과 같다.

• php-fpm은 php 언어로 작성된 동적 웹 애플리케이션을 처리하는 데 사용되는 FastCGI 기반의 php 프로세스 관리자이다.
• php는 주로 동적 웹 페이지 생성, 데이터베이스 연동, 사용자 인증 등과 같은 서버 측 로직을 처리하는 데 사용된다.
• php-fpm은 여러 php 프로세스를 관리하고, 요청이 들어올 때마다 php 스크립트를 처리하는 역할을 한다. 이를 통해 php 애플리케이션의 성능을 최적화하고, 여러 요청을 동시에 처리할 수 있다.
• php-fpmdms Nginx와 연동하여 동적 콘텐츠를 제공할 때 사용되며, 이러한 조합은 많은 웹 애플리케이션 서버 환경에서 널리 사용된다.

list-units는 현재 시스템에서 활성화된 모든 systemd 유닛을 나열한다. 이 명령을 사용하면 현재 시스템에서 실행 중인 서비스, 소켓, 장치 등을 확인할 수 있다. grep php로 php라는 문자열을 포함하는 행만 필터링하면 위와 같은 결과를 확인할 수 있다.

 

• index index.php index.html: 이 지시문은 웹 서버가 인덱스 파일로 사용할 파일 이름을 정의한다.
• location / { ... }: 해당 location 블록은 루트 경로(/)에 대한 요청을 처리한다. try_files 지시문을 통해 파일이나 디렉터리를 찾지 못한 경우 404 오류를 반환하도록 설정했다.
• location ~\.php$ { ... }: 해당 location 블록은 .php 확장자를 가진 파일에 대한 요청을 처리한다. php 파일은 php-fpm에 전달되며, fastcgi_pass 지시문을 통해 php-fpm 소켓에 연결된다.

이 설정 파일은 Nginx 웹 서버가 정적 파일을 처리하고 php 파일을 php-fpm으로 전달하여 동적 콘텐츠를 처리하는 기본적인 구성을 나타낸다.

 

/sites/demo/info.php 파일을 생성하고 (ip)/info.php를 브라우저에서 요청해보자.

 

오류 로그와 프로세스 목록을 보면 Nginx와 php-fpm 사이의 연결 문제가 있는 것을 확인할 수 있다. nginx에서 워커 프로세스가 nobody 사용자로 실행되는 것을 확인할 수 있다. 웹 서버는 클라이언트 요청을 처리하고 정적 파일을 서빙하는 역할을 하며, 이러한 작업을 최소 원칙으로 갖게 된다. 따라서 www-data 사용자로 수정할 필요가 있다. www-data는 웹 페이지 및 웹 애플리케이션을 제공하는 동안 파일 및 디렉터리에 액세스할 수 있는 권한을 가진다.

 

권한이 수정된 것을 확인할 수 있다.

 

권한으로 인한 오류도 해결했다.

 

index.php까지 완성!

 

Work Processes

위에서 워커 프로세스의 권한을 수정하여 오류를 해결할 수 있었다. 그러면 워커 프로세스가 무엇일까? Nginx는 마스터와 워커 프로세스로 나누고 워커 프로세스가 실질적인 웹 서버 역할을 수행한다. 즉, 워커 프로세스는 실제 HTTP 요청을 처리하고 클라이언트로부터 받은 요청을 웹 서버의 설정에 따라 정적 파일 서비스, 리버스 프록시, 로드 밸런싱 등과 같은 작업을 수행하고, 각 워커 프로세스는 독립적으로 동작하며, 여러 개의 동시 요청을 처리할 수 있다.

 

워커 프로세스의 수는 nginx.conf 설정 파일에서 조정할 수 있다. 이를 통해 시스템 자원 및 하드웨어 성능에 따라 최적의 처리 능력을 얻을 수 있다. 또한, 워커 프로세스 간에 정보를 공유하는데 사용되는 공유 메모리 영역을 사용하여 각 워커 프로세스가 동일한 설정 및 상태를 공유할 수 있다.

Nginx의 워커 프로세스는 비동기 이벤트 드리븐 아키텍처를 사용하여 효율적으로 동작한다. 많은 동시 연결과 요청을 처리하는 데 특히 유용하며, 블로킹 작업을 최소화하여 높은 성능을 제공할 수 있다.

 

동작 과정

1. 마스터 프로세스가 시작되면 설정 파일을 읽고 구문 분석하여 필요한 정보를 준비한다.
2. 마스터 프로세스는 설정 정보를 기반으로 워커 프로세스를 생성하고 관리한다. 각 워커 프로세스는 별도의 CPU 코어에서 병렬로 실행된다.
3. 클라이언트 요청이 들어오면 마스터 프로세스는 이를 받아들이고 하나의 워커 프로세스에 요청을 전달한다.
4. 워커 프로세스는 비동기적으로 요청을 처리하고, 필요한 경우 업스트림 서버(= Application Server)로 요청을 전달한다.
5. 워커 프로세스는 응답을 생성하고 클라이언트에게 반환한다.

 

auto

worker_processes auto;

현재 시스템에서 사용 가능한 core의 개수가 4개인 것을 확인할 수 있다. 따라서 core 개수에 따라 워커 프로세스 개수를 auto로 설정하면 자동으로 CPU 코어 수 기반으로 설정된 것을 확인할 수 있다.

 

worker_connections

ulimit -n 명령어는 리눅스 기반 시스템에서 사용자 프로세스가 열 수 있는 파일 디스크립터(file descriptor)의 제한을 표시한다.

events 블록은 Nginx의 이벤트 처리 관련 설정을 포함하는 블록으로 다양한 이벤트 처리 관련 지시문을 정의할 수 있다. 그 안의 내용을 보면 worker_connections 1024;로 설정된 것을 알 수 있다. 이 설정은 동시에 열 수 있는 클라이언트 연결의 최대 수를 나타낸다. worker_connections 지시문은 Nginx 워커 프로세스가 처리할 수 있는 동시 클라이언트 연결 수를 제한한다. 여기서는 ulimit -n으로 확인한 값으로 설정했으므로 각 워커 프로세스가 1024개의 클라이언트 연결을 처리할 수 있다. 이 값은 시스템 자원과 웹 서버의 예상 트래픽에 따라 조정해야 한다.

 

pid /var/run/new_nginx.pid;는 Nginx 마스터 프로세스의 PID 파일 경로를 /var/run/new_nginx.pid로 지정하는 지시문이다. pid 파일은 다음과 같은 목적으로 사용된다.

• 프로세스 관리: pid 파일은 Nginx 마스터 프로세스의 프로세스 id를 포함하고 있으므로, 해당 프로세스를 식별하고 관리하는 데 사용된다.
• 재시작 및 종료: Nginx를 다시 시작하거나 종료할 때, 관리 명령을 수행하기 위해 pid 파일을 사용한다. 이를 통해 정확한 프로세스를 중지하거나 재시작할 수 있다.
• 상태 확인: pid 파일을 사용하여 Nginx의 상태를 확인하고, 정상적으로 실행 중인지 확인할 수 있다.

 

Buffers & Timeouts

Nginx의 버퍼는 데이터를 일실적으로 저장하고 처리하는 데 사용되는 메모리 영역이다. 클라이언트 요청을 받아서 업스트림 서버로 전달하거나, 업스트림 서버로부터 받은 응답을 클라이언트로 전송할 때 버퍼를 사용한다. 버퍼는 요청 및 응답 데이터를 일시적으로 저장하여 더 효율적인 I/O 작업을 가능한다. 따라서 적절한 버퍼 설정은 성능 향상과 웹 서버의 안전성을 보장하는 데 중요하다.

Nginx의 타임아웃은 클라이언트와 서버 간의 연결 데이터 전송 시간 제한을 나타낸다. 타임아웃 설정은 네트워크 연결이나 클라이언트 요청을 처리하는 데 소요되는 시간을 제한하고, 웹 서버의 응답 속도를 관리하는 데 사용된다. 이러한 타임아웃 설정을 적절하게 조절하지 않으면 클라이언트 연결이 무한정 대기하거나, 서버 부하가 높아질 수 있으므로 주의가 필요하다.

 

• client_body_buffer_size: 클라이언트 요청의 본문(body) 데이터를 버퍼링하는 크기를 설정한다. 클라이언트로부터 수신된 본문 데이터는 이 버퍼에 일시적으로 저장된다. 10KB의 버퍼를 사용하도록 설정되어 있다.
• client_max_body_size: 클라이언트가 전송할 수 있는 최대 요청 본문 크기를 제한한다. 여기서는 8MB로 설정되어 있으므로, 클라이언트가 8MB를 초과하는 요청을 보내면 Nginx는 해당 요청을 거부한다.
• client_header_buffer_size: 클라이언트 요청 헤더를 버퍼링하는 크기를 설정한다. 1KB의 버퍼를 사용하도록 설정되었다.
• client_body_timeout, client_header_timeout: 클라이언트로부터 요청 헤더와 본문 데이터를 받을 때의 타임아웃 값을 설정한다. 여기서는 각각 12초로 설정되어 있으므로, 클라이언트가 이 시간 내에 요청 헤더 또는 본문 데이터를 보내지 않으면 연결이 종료된다.
• keepalive_timeout: Keep-Alive 연결을 유지하는 시간을 설정한다. 여기서는 15초로 설정되어 있으므로 클라이언트와 서버 간의 Keep-Alive 연결이 15초 동안 유지된다.
• send_timeout: sendfile 시스템 콜을 사용하여 정적 파일을 보낼 때 사용한다. 이를 활성화하면 파일 송신의 효율성과 성능을 향상시킬 수 있다.
• tcp_nopush: 가능한 한 큰 TCP 패킷을 사용하여 데이터를 보내는 데 도움을 줄 수 있으며, 성능을 최적화하는 데 사용된다.

 

출처

NGINX Fundamentals: High Performances Servers from Scratch