nginx 의 설정은 nginx 를 구성하는 핵심으로 nginx 는 설정파일만 갖고 동작을 결정한다고 해도 과언이 아니다.


보통 nginx 의 환경설정을 구성하는 파일은 /usr/local/nginx/conf 폴더 하위에 위치하며 nginx.conf 파일을 수정함으로써 환경설정을 정의할 수 있다.


환경설정은 document 를 보는 것보다 예제로 파악하는게 좋아보이므로 예제를 중심으로 기술한다.



http {
### Load balancing ###
upstream {
### Target Proxy Host ###
server server01;
server server02;
}
### Main server configuration ###
server {
listen 80;
server_name nginx.sample.com;
client_header_timeout 10;
client_body_timeout 10;
charset UTF-8;
root /home/my-doc;
######### log #######
access_log logs/access.log main;
error_log logs/error.log;
#####################
############## internal location ############################
location /monitor {
allow 127.0.0.1;
deny all;

proxy_pass http://monitor.proxy:8080;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
############## main location ############################
location / {
proxy_pass http://localhost:8080;
}
}
}


nginx 설정은 계층적 구조를 이루며 하위 블록에서의 선언은 상위 블록에서의 선언을 덮어쓴다.


http 블록은 nginx 설정의 루트 블록이라고 할 수 있다. 기본적으로 여러개 정의할 수는 있으나 관리상의 이유로 보통 하나의 블록 안에서 해결한다.


server 블록은 Host 의 개념으로 웹서버의 메인 설정이라 할 수 있다.


upstream 블록은 로드밸런싱을 하는데 사용되며 nginx 를 로드밸런서로 사용할 경우 기술된 서버로 해당 요청을 중계해준다.


옵션값으로 default(선언하지 않을 경우 라운드로빈), least_conn (연결이 가장 적은 서버로 중계), ip_hash(ip값을 이용한 해시주소로 요청 분배) 등 분산 알고리즘의 설정이 가능하다.


log 항목은 nginx 의 중요 기능 중 하나로 nginx 를 거치는 모든 로그 및 에러 로그를 기록하는 데 사용된다.


location 블록은 서버 내에서 요청을 다르게 라우팅하고 싶을 경우 사용한다. nginx 로 프록시 서버를 구성할 때 해당 경로로 proxy pass 를 지정함으로써 라우팅을 처리할 수 있다.


nginx 의 설정 반영은 서버를 재시작해야 적용되므로 설정 후에는 OS 에 맞게 서비스를 재시작 해주도록 하자.




Software 를 다루는데 있어서 Proxy 는 흔히 접할 수 있는 단어이다.

많은 IT에 대해 잘 알지 못하는 사람들도 "우회" 를 목적으로 운영되는 프록시 서버에 대해 알고 있으며, Software 공학에 있어서 Proxy 는 상식처럼 알아두어야할 개념 중 하나이다. 

크게 많이 사용되는 Proxy 용어의 의미는 Proxy 서버, Proxy Design Pattern 등 다양하지만, 본 포스팅에서는 프록시 서버에 대해 다룬다.


Proxy 란 대리 혹은 중계 Agent 로써의 의미를 지니며 프록시 서버란 대리자 역할을 하는 서버를 말한다.


즉, 웹브라우저에서 Request를 보냈을 때 내 IP가 아닌 Proxy 서버의 IP로 웹서버에 접근하여 요청과 응답을 처리한 후 Proxy 서버에서 나에게 응답을 해주게 된다.


이렇게 프록시 서버를 사용하는 목적은 3가지 정도가 있다.


목적에 따른 분류


(1) 익명성과 우회접근


 : 서비스형태로 제공하는 Proxy 가 주로 이 범주에 속하며, IP를 숨기는 것이 주 목적이다. 요청을 대신 수행해주는 프록시 서버를 통해 우회하여 서버에 접근이 가능하다. 

IP 를 숨긴 채 모든 사용자가 접근가능하도록 허용하는 Open Proxy 형태가 있다.



(2) 서버의 부하를 줄여주기 위한 Filter 이자 Cache


 : Proxy 를 도구로써 사용하는 가장 대표적인 예시이다. 프록시 서버가 서비스 서버에 작업하는 위치와 네트워크 구성에 따라서 Forward Proxy / Reverse Proxy 로 구분된다.


 - Forward Proxy : 일반적인 프록시 서버를 말하며, 요청하는 Client 와 Service Server 사이에 위치하여 중간에서 요청을 중계한다. 가령 서버에 요청이 들어왔을 때, 요청은 Proxy를 거쳐 서버에 전달되며 이 과정에서 별도 작업을 처리해서 Service Server로 전달하거나, Cache 로써의 역할을 한다.


 - Reverse Proxy : 마찬가지로 Client 의 요청이 실제 Service Server의 도메인으로 이루어지는 것이 아닌 프록시 서버로 이동한다. 

Forward Proxy 와는 다르게, Service Server 들이 대게 내부망으로 구성되며 프록시에서만 연결을 허용하게 만들어 서비스를 위한 보안 채널을 구축하는 역할을 한다. 

이런 경우 Client 가 Service Server 에 직접 접근이 불가능하므로 Reverse Proxy 에서 요청을 좀 더 적극적으로 중계하는 Load Balancing 의 역할을 수행하기도 한다.


 : 이렇게 서버 측에 위치한 Cache 를 위한 Proxy 외에도 클라이언트 네트워크 쪽에서 프록시와 캐싱을 함께 수행하는 서버가 따로 존재한다. (Squid와 같은 서버가 예이다.) 

 : 이 때 캐싱 시에는 HTTP 헤더에 Cache-control : no-cache 옵션이 주로 작용하며 주로 포털 사이트에서 해당 헤더를 사용하는 경우를 볼 수 있다.

(Cache-control 옵션에 대해 얘기하자면, no-cache로 지정할 경우 캐싱을 사용하지 않고 실 서버까지 도달한다. 

그렇기 때문에 사용하려면 max-age=3600, must-revalidate 와 같이 지정해야 한다.)



(3) 서버 접근 작업 자체를 담당하는 서버


 : 다소 특수한 케이스로 주로 모니터링 및 데이터 분석을 위해 요청 자체를 기록하고 다루는 형태의 서버 엔진이 있다. 보안, ACL(Access Control List), Log / Audit 등을 위해 사용된다.



웹서비스를 구현하는 데 있어서 보통 사용되는 프록시 서버의 형태는 (1)번과 (2)번으로 Reverse Cache 의 형태가 가장 보편적이라고 할 수 있다.



+ Recent posts