NGINX MSA 디지털 트레이닝 - 8강 : Basics and Best Practices

강의 동영상 : https://www.youtube.com/watch?v=rQa2HrXXTJA
원본 동영상 : https://www.youtube.com/watch?v=pkHQCPXaimU

8강은 7강과 거의 동일한 내용을 설명하고 있다. 대부분의 내용이 7강 : NGINX Kick Starter 과 중복되어 있지만, 예시 위주로 다시한 번 정리했다.

Simple Virtual Server

server {
        listen    80 default_server;
        server_name  [www.example.com](http://www.example.com);

        return    200;
}

• server : virtual server context를 정의하는 Block
• listen : 수신할 IP, Port Number를 정의. IP을 명시하지 않을 경우는 System이 가진 모든 IP에 Binding한다.
• server_name : Virtual Server가 수신하는 hostname
• return : request에 대한 response 정의

Basic Web Server Configuration

server {
        listen    80 default_server;
        server_name [www.example.com](http://www.example.com);

        location  /i/  {
                root    /usr/share/nginx/html;
                # alias /usr/share/nginx/html;
                index    index.html index.htm;
        }
}

• root : NGINX가 설치된 서버의 파일시스템에서 파일이 저장된 위치를 지정.
• alias : root directive와 비슷하지만 location에 정의된 URL을 사용하지 않고 alias로 지정된 그 Path만을 사용.
• index : 기본적으로 사용할 index file을 지정
• 실제 사용할 때의 예.
  • index : www.example.com -> /usr/share/nginx/html/index.html
  • root : www.example.com/i/file.txt -> /usr/share/nginx/html/i/file.txt
  • alias : ww.example.com/i/file.txt -> /usr/share/nginx/html/file.txt

Basic Load Balancing Configuration

upstream my_upstream {
        server    server1.example.com;
        server    server2.example.com;
        least_time;
}
server {
        location / {
                proxy_set_header    Host    $host;
                proxy_pass    [http://my\_upstream](http://my_upstream);
        }
}

• upstream : Load Balancer에 포함될 모든 Backend Pool을 정의하는 Directive.
• Load Balancing Algorithm
  • default. : 별다른 설정이 없을 경우에는 Round Robin 방식으로 사용
  • least_conn : Active Connection이 적은 서버로 Request가 전달됨
  • least_time : NGINX Plus에서만 가능하며, least_conn + 응답 속도를 기준으로 Request가 전달됨
• proxy_pass : 들어오는 Request를 다른 곳으로 전달. 위에서는 Load Balancing을 위해 정의한 Backend Pool로 이동.
• Remark
  • NGINX는 기본적으로 Host 값을 proxy server의 값으로 치환하기 떄문에, proxy_set_header directive를 통해 원래의 Client Host Header로 변경해야 한다.
  • $host ; NGINX 가 수신한 Client Host 값을 가진 변수이다.

Basic Reverse Proxy Configuration

server {
        location ~ ^(.+\.php)(.*)$ {
                fastcgi_split_path_info ^(.+\.php)(.*)$;

                # fastcgi_pass 127.0.0.1:9000;
                fastcgi_pass    unix:/var/run/php7.0-fpm.sock;

                fastcgi_index    index.php
                include    fastcgi_params;
        }
}

• Remark : Apache HTTPD의 경우 static content와 하나의 Dynamic Content를 직접 제공하는데 비해, NGINX는 Dynamic Contents는 Application Server를 통해 제공
• fastcgi_pass : proxy_pass와 유사. IP+Port로 Network Layer에서 Routing 하거나 Unix Socket을 사용하는 방식으로 Routing 할 수 있다.

Caching Configuration

proxy_cache_path /path/to/cache. levels=1:2 
                                keys_zone=my_cache:10m max_size=10g
                                inactive=60m use_temp_path=off;

server {
       location / {
               proxy_cache my_cache;
               proxy_set_header Host $host;
               proxy_pass http://my_upstream;
       }
}

• proxy_cache_path : cache를 위한 모든 parameter를 설정. 제일 먼저 Cache Data가 저장할 Path를 지정
  • levels : file path의 depth를 몇 단계로 할지와 cache key를 몇 글자 사용할 지를 지정
  • key_zone : cache key를 저장할 Memory Size. 1MB인 경우 약 8000개의 Cache Key 저장
  • max_size : 최대 Cache 크기
  • inactive : Cache내 저장된 객체가 Access되지 않은 채로 최대한 머무를 수 있는 시간.
  • use_temp_path : Caching시 임시 파일을 저장할 공간 사용여부. 사용할 경우 저장할 Path를 지정해야 한다.
• proxy_cache : 여러개의 cache context중 하나를 지정

Basic SSL Configuration

server {
        listen       80 default_server;
        server_name  [www.example.com](http://www.example.com);
        return 301 [https://$server\_name$request\_uri](https://$server_name$request_uri);
}
server {
        listen  443 ssl default_server;
        server_name    [www.example.com](http://www.example.com);
        ssl_certificate        cert,crt;
        ssl_certificate_key    cert.key;

        location / {
                root     /usr/share/nginx/html;
                index    index.html  index.htm;
        }
}

• 위의 예에서는 모든 Non-Secure Traffic이 Secure Traffic으로 전달되게 설정.
• public/private key를 사용하기 위해 ssl_certificate와 ssl_certificate_key directive가 사용된다.
• 참조 : nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx

Basic HTTP/2 Configuration

server {
        listen 443 ssl http2 default_server;
        server_name   [www.example.com](http://www.example.com);

        ssl_certificate          cert.crt;
        ssl_certificate_key      cert.key;
}

• HTTP/2 지원을 위해서 listen directive에 http2 directive만 추가하면 가능
  • HTTP/2는 SSL 위에서만 동작하기 때문에 ssl directive도 명시해야함
• HTTP/2는 Client Side에만 적용, Server Side는 HTTP 1이나 1.1이다.
• Remark : HTTP/2는 OpenSSL 1.0.2 이상에서 동작. 즉 Ubntu 16.04 나 RedHat 7.4 이후 버젼에서 적용 가능

Multiplexing Multiple Sites on One IP

server {
        listen 80 default_server; 
        server_name www.example.com; 
        # ... 
}
server {
        listen 80; 
        server_name www.example2.com; 
        # ... 
}
server {
        listen 80; 
        server_name www.example3.com; 
        # ... 
}

• 위의 예는 같은 IP+Port의 조합이라도 다른 server_name을 설정해서, 하나의 서버의 다수의 가상 서버를 설정하는 예이다.
  • www.example.com, www.example2.com, www.example3.com 3개의 가상 서버 설정
• default_server : host name이 없을 경우를 대비해 default_server directive를 통해 기본 가상 서버를 설정하는 것을 권장.
• 참고 : 다수의 가상 서버를 찾아가는 순서는 이전 블로그인 'NGINX MSA 디지털 트레이닝 - 7강 : NGINX Kick Starter' 참조

Layer 7 Request Routing

server {
        # ...
        location /service1 {
                proxy_pass    [http://upstream1](http://upstream1);
        }
        location /service2 {
                proxy_pass    [http://upstream2](http://upstream2);
        }
        location /service3 {
                proxy_pass    [http://upstream3](http://upstream3);
        }
}

• location 하나의 가상 서버가 URL에 따라 다르게 Routing 될 수 있게 설정
• 위의 예에서는 upstream1~3의 3개의 서비스가 있고, /service1, /service2, /service/3 이라는 URL에 따라 각각 다른 서비스로 연결된다.

Advanced - nginx.conf 수정

user  nginx;
wrok_processes auto;
...
http {
        ...
        keepalive_timeout   300s;
        keepalive_requests  100000;
}

• work_process
  • auto ; 시스템의 코어당 하나 이상의 프로세스를 생성(대부분의 경우에 권장되는 사항)
• keepalive
  • keepalive_timeout : idle 상태의 connection을 얼마나 유지하느냐를 설정. 기본값은 75초
  • keepalive_requests : 단일 Connection에서 처리할 수 있는 최대 request양. 설정값 이상의 request를 받았을 때 Connection을 끊는다.
  • keepalive_*로 시작하는 설정값은 가상서버에서 따로 재정의 할 수 있다.

HTTP/1.1 Keepalive to upstreams

upstream my_upstream {
        server server1.example.com;
        keepalive 32;
}
server {
         location /service1 {
                proxy_set_header    Host    $host;
                proxy_http_version  1.1;
                proxy_set_header    Connection "";

                proxy_pass    http://my_upstream;
        }
}

• keepalive : TCP connection cache를 활성화함
  • 기본적으로 NGINX는 HTTP/1.0을 사용 (Connection: Close)
• proxy_http_version : 사용하려는 HTTP Version을 설정
• proxy_set_header : 기본값으로 Connection: Close를 사용하기 떄문에 HTTP Header의 Connection 값을 ""으로 재설정

SSL Session Caching

server {
        listen  443    ssl default_server;
        server_name    www.example.com;

        ssl_certificate    cert.crt;
        ssl_certificate_key    cert.key;

        ssl_session_cache       shared:SSL:10m;
        ssl_session_timeout     10m;
}

• SSL Session Cache를 사용하면 SSL/TLS 성능이 향상. Idle 상태에 있던 Client가 재접속할 때 계산비용이 많이 드는데 이런 문제를 방지할 수 있다.
• 1MB의 Cache는 약 4,000개의 Session을 저장
• Cache는 모든 worker들이 공유.

Advanced Caching Configuration

proxy_cache_path /path/to/cache  levels=1:2
                keys_zone=my_cache:10m max_size=10g
                inactive=60m  use_temp_path=off;

server {
        location / {
                proxy_cache    my_cache;
                proxy_cache_lock    on;
                proxy_cache_revalidate    on;
                proxy_cache_use_stale    error
                             timeout  updating 
                             http_500
                             http_502
                             http_503 
                             http_504;
                proxy_cache_background_update    on;

                proxy_set_header    Host    $host;
                proxy_pass    http://my_upstream;
        }
}

• proxy_cache_use_steal ; Error 대신 오래된 contents를 제공
• proxy_cache_background_update : NGINX의 cache가 background에서 update 할수 있게 설정. proxy_cache_use_steal과 함께 사용.
• proxy_cache_lock : 한 번에 단 하나의 요청만 upstream server로 전달하게 함
• proxy_cache_revalidate : "If-Modified-Since" 또는 If-None-Match"헤더 필드와 함께 만료 된 캐시 항목의 유효성을 다시 검사

gRPC Proxing

server {
        listen 443 ssl http2;
        ssl_certificate           server.crt;
        ssl_certificate_key       server.key;
        location / {
                grpc_pass    grpc://localhost:50051;
        }

• gRPC를 위해서는 HTTP/2가 설정되야함. (SSL 설정은 Optional)
• grpc_pass : grpc routing을 위해 사용하는 directive

Active Health Checks

upstrem. my_upstream {
        zone  my_upstresm 64k;
        server  server1.example.com  slow_start=30s;
}
server {
        #...
        location /health {
                internal;
                health_check   interval=5s uri=/test.php match=statusok;
                proxy_set_header    HOST  www.example.com;
                proxy_pass    http://my_upstream;
        }
match statusok {
        # used for /test.php healh check
        status 200;
        header Content-Type = text/html;
        body ~ "Server[0-9]+ is alive";
}

• NGINX 는 기본적으로 passive health check 만 지원. Active Health check는 NGINX Plus에서만 지원
• health_check : 백엔드 서버의 healch check를 위한 directive
  • interval : probe packet 전송 간격
  • uri : health check를 위한 target uri
  • match : health check 응답 결과 Check를 위한 match block 지정
• match block : health check 결과 검증
  • 예에서는 status code, response header, response body를 지정하고 있으며 이 조건을 만족하지 못하는 경우 실패 처리.

Sticky Cookie Session Persistence

upstrem  my_upstream { 
        server    server1.example.com'
        server    server2.example.com;

        sticky  cookie  name expires=1h domain=.example.com  path=/;
}

• NGINX Plus 에서만 제공
• Client가 특정 서버와 응답을 지속할 수 있게 기능 지원. Client가 쿠키값을 사용하게 하며, 해당 쿠키값을 이용해 최초 연결된 서버로 Routing 하는 방법으로 기능 제공
• sticky cookie : sticky cookie 기능 Enable
  • expires : cookie 유효 시간
  • domain : cookie 값이 유효한 domain 명시. 없을 경우 cookie 값에서 domain filed가 공백으로 남게됨.
  • path : cookie 값이 설정된 path. 없을 경우 cookie 에서 path field가 공백으로 남게됨.

Logging and Monitoring

NGINX Stub Status Module

server {
        location /basic_status {
                stub_status;
        }
}

$ curl  http://www.example.com/basic_status
Active connections: 1
server accepts handled requests
 7 7 7
 Reading:0 Writing:1 Waiting: 0

• NGINX에 기본으로 내장된 기능으로 NGINX 상태 정보를 확인할 수 있다.
• stub_status : location block으로 활성화 시키면 해당 URL로 접근시 7개의 상태정보를 확인할 수 있다.

NGINX Plus Extended Status

server {
        listen 8080;
        location /api {
                api write=on;
                ...
                # Limit access to the API
                allow 10.0.0.0/8;
                deny all;
        }
        location = /dashboard.html {
            root  /usr/share/nginx/html;
        }

• NGINX plus에서는 약 40개 이상의 상태 정보를 제공할 수 있음
• NGINX에서 제공하는 통계 정보를 사용하기 위해 /api location 블록을 지정하고, 'api write=on' directive를 사용해야함.
• 통계정보는 /usr/share/nginx/html/dashboard.html로 제공됨.
• Example : demo.nginx.com

NGINX Access Logs

• NGINX 는 기본적으로 Logging 기능이 켜져 있음
  • 사용하지 않을 경우 "access_log off" directive를 사용하면 됨.
  • 기본적으로는 client IP, date, request, referrer, user agenct 정보가 포함됨
    • 각종 logging 변수는 nginx.org/en/docs/varindex.html 을 참조
  • log_format : Log 형식을 지정하는 directive
  • Remark : Logging 작업은 성능 저하를 가져올 수 있기 때문에, 실제 서비스에서는 비활성화 시킬 수도 있음.