NGINX 설정

Here is a digital illustration that visually represents the concept of a network server setup, including elements like NGINX, SSL, load balancers, and web caching. The image features a server rack with various labeled cables in a modern and minimalistic style

 

NGINX의 nginx.conf 파일은 서버의 모든 주요 설정을 포함하고 있으며, 이 파일을 통해 NGINX의 동작을 제어합니다. 아래에서는 NGINX의 기본 구성 파일 구조와 주요 섹션에 대해 자세히 설명하겠습니다.

NGINX 설정 파일의 기본 구조

nginx.conf 파일은 몇 가지 주요 블록으로 구성되어 있습니다:

1. Global Block: 이 부분에는 전역 설정이 포함되며, NGINX 서버 전체에 적용됩니다.
2. Events Block: 연결 처리에 관련된 설정을 포함합니다.
3. HTTP Block: HTTP 서비스에 관련된 설정을 포함하며, 여러 개의 server 블록을 포함할 수 있습니다.
4. Server Block: 특정 도메인에 대한 설정을 담당하며, 하나의 http 블록 안에 여러 개가 있을 수 있습니다.
5. Location Block: 특정 요청 URI에 대한 설정을 포함합니다. server 블록 내에 위치합니다.

주요 설정 예시

# 사용자와 워커 프로세스 설정
user nginx;
worker_processes auto;

# 에러 로그와 PID 파일 경로 설정
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

# 이벤트 모듈 설정
events {
    worker_connections 1024;
    use epoll; # Linux 기반 시스템에 적합한 이벤트 처리 모델
}

# HTTP 서버 설정
http {
    # 기본 MIME 타입 설정
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # 로그 포맷 설정
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    # 접근 로그와 에러 로그 설정
    access_log /var/log/nginx/access.log main;
    error_log /var/log/nginx/error.log notice;

    # 파일 전송 최적화 설정
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Keep-alive 설정
    keepalive_timeout 65;

    # Gzip 압축 설정
    gzip on;
    gzip_disable "msie6";

    # 서버 블록 설정
    server {
        listen 80 default_server;
        server_name _;
        root /usr/share/nginx/html;

        # 기본 페이지 설정
        index index.html index.htm;

        # 404 페이지 설정
        error_page 404 /404.html;
        location = /40x.html {
            root /usr/share/nginx/html;
        }

        # 50x 페이지 설정
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root /usr/share/nginx/html;
        }

        # 애플리케이션 프록싱 예시
        location /app {
            proxy_pass http://localhost:3000;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }

        # 정적 파일 캐싱 설정
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            expires 30d;
        }
    }
}

설정 파일의 주의사항 및 가이드라인

1. 문법 확인: 설정을 변경한 후에는 항상 nginx -t 명령을 사용하여 문법 오류를 확인해야 합니다.
2. 경로와 권한: 설정 파일에서 지정한 경로에 파일이 존재하는지, 그리고 NGINX 사용자가 해당 파일에 접근할 수 있는 권한을 가지고 있는지 확인해야 합니다.
3. 보안 고려사항: 외부에서 접근할 수 있는 설정(server, location)에서는 실행 가능한 스크립트나 애플리케이션에 대한 접근 제어를 엄격히 관리해야 합니다.
4. 성능 최적화: sendfile, tcp_nopush, tcp_nodelay 등의 설정을 활용하여 파일 전송과 네트워크 성능을 최적화할 수 있습니다.

아래에서는 각 주요 블록과 그 기능에 대해 자세히 설명하겠습니다.

1. Global Block

• 위치: 설정 파일의 맨 위
• 목적: NGINX 서버 전체에 영향을 미치는 전역 설정을 정의합니다.
• 주요 지시어:
  • user: NGINX 서버 프로세스를 실행할 시스템 사용자와 그룹을 지정합니다.
  • worker_processes: 사용할 워커 프로세스의 수를 설정합니다. 이는 일반적으로 사용 가능한 CPU 코어 수와 일치시킵니다.
  • error_log: 에러 로그의 경로와 로그 레벨을 설정합니다.
  • pid: NGINX 마스터 프로세스의 PID 파일 경로를 지정합니다.

2. Events Block

• 위치: nginx.conf 파일 내의 events 컨텍스트
• 목적: 연결 처리에 관련된 기본 이벤트 설정을 관리합니다.
• 주요 지시어:
  • worker_connections: 단일 워커 프로세스가 동시에 처리할 수 있는 최대 연결 수를 지정합니다.
  • multi_accept: 한 워커 프로세스가 여러 네트워크 연결을 동시에 수락할지 여부를 결정합니다.
  • use: 특정 이벤트 모델을 사용하도록 NGINX에 지시합니다.

3. HTTP Block

• 위치: nginx.conf 파일 내의 http 컨텍스트
• 목적: HTTP 서버와 관련된 설정을 정의합니다. 이 블록은 여러 server 블록을 포함할 수 있습니다.
• 주요 지시어:
  • include: 다른 설정 파일이나 특정 패턴의 파일을 포함시킵니다.
  • default_type: 지정되지 않은 파일의 MIME 타입을 설정합니다.
  • access_log 및 error_log: 접근 및 에러 로그의 경로와 포맷을 정의합니다.
  • sendfile, tcp_nopush, tcp_nodelay: 파일 전송 성능을 최적화하는 설정입니다.
  • keepalive_timeout: 연결을 유지하는 시간을 설정합니다.
  • server_tokens: 서버 토큰을 숨기거나 보여주는 설정입니다.
  • ssl_certificate 및 ssl_certificate_key: SSL 연결을 위한 인증서 및 키 파일 경로를 지정합니다.

4. Server Block

• 위치: http 컨텍스트 내부
• 목적: 특정 도메인 또는 IP 주소에 대한 서버 설정을 정의합니다.
• 주요 지시어:
  • listen: 서버가 연결을 수락할 포트와 IP를 지정합니다.
  • server_name: 서버가 응답할 도메인 이름을 설정합니다.
  • root: 요청 URI의 루트 경로를 지정합니다.
  • index: 디렉토리 요청에 대한 기본 파일을 설정합니다.
  • location: 특정 URI 패턴에 대한 상세 설정을 정의합니다.

5. Location Block

• 위치: server 컨텍스트 내부
• 목적: URI 요청에 따른 상세 처리 규칙을 정의합니다.
• 주요 지시어:
  • proxy_pass: 요청을 다른 서버로 전달합니다.
  • try_files: 파일이나 디렉토리의 존재를 확인하고, 없을 경우 다른 URI로 요청을 전달합니다.
  • deny 및 allow: 특정 IP 주소의 접근을 허용하거나 거부합니다.

이러한 블록들을 통해 NGINX의 동작을 세밀하게 제어하고, 특정 요구사항에 맞추어 서버를 구성할 수 있습니다. 설정 변경 후에는 항상 문법 검사를 수행하고, 오류가 없을 경우 NGINX를 재시작하거나 설정을 리로드해야 합니다.

NGINX 웹 서버 설정

다음 예제는 정적 웹 컨텐츠 제공, 애플리케이션 프록싱, 보안 향상 및 성능 최적화 기능을 포함하고 있습니다.

NGINX 웹 서버 설정 예시

# 사용자와 워커 프로세스 설정
user nginx;
worker_processes auto;

# 에러 로그와 PID 파일 경로 설정
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

# 이벤트 모듈 설정
events {
    worker_connections 1024;
    use epoll; # Linux 기반 시스템에 적합한 이벤트 처리 모델
}

# HTTP 서버 설정
http {
    # 기본 MIME 타입 설정
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # 로그 포맷 설정
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    # 접근 로그와 에러 로그 설정
    access_log /var/log/nginx/access.log main;
    error_log /var/log/nginx/error.log notice;

    # 파일 전송 최적화 설정
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Keep-alive 설정
    keepalive_timeout 65;

    # Gzip 압축 설정
    gzip on;
    gzip_disable "msie6";

    # 서버 블록 설정
    server {
        listen 80 default_server;
        server_name _;
        root /usr/share/nginx/html;

        # 기본 페이지 설정
        index index.html index.htm;

        # 404 페이지 설정
        error_page 404 /404.html;
        location = /40x.html {
            root /usr/share/nginx/html;
        }

        # 50x 페이지 설정
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root /usr/share/nginx/html;
        }

        # 애플리케이션 프록싱 예시
        location /app {
            proxy_pass http://localhost:3000;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }

        # 정적 파일 캐싱 설정
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            expires 30d;
        }
    }
}

설명

1. 기본 설정: NGINX 워커 프로세스 수, 로그 설정, PID 파일 위치를 설정합니다.
2. 이벤트 처리: 최대 연결 수 및 사용할 이벤트 모델(epoll)을 설정합니다.
3. HTTP 설정: MIME 타입, 로그 포맷, 압축, Keep-alive 등의 HTTP 관련 설정을 합니다.
4. 서버 설정:
   • listen 80 default_server: 80 포트에서 요청을 받고, 기본 서버로 설정합니다.
   • server_name _;: 모든 도메인에 대해 응답합니다.
   • root /usr/share/nginx/html;: 웹 문서의 루트 디렉토리를 지정합니다.
   • 에러 페이지: 사용자 정의 에러 페이지를 설정합니다.
   • 애플리케이션 프록싱: 특정 경로(/app)에서 다른 애플리케이션(예: Node.js 앱)으로 요청을 전달합니다.
   • 정적 파일 캐싱: 이미지, CSS, JavaScript 파일의 캐싱을 설정하여 성능을 향상시킵니다.

이 설정 예제는 웹 서버를 구성하고 기본적인 성능 최적화와 보안 기능을 포함하여 NGINX를 효과적으로 운영할 수 있도록 도와줍니다. 설정을 적용한 후에는 nginx -t로 설정을 검증하고, systemctl restart nginx 또는 nginx -s reload로 NGINX를 재시작해야 합니다.

 

몇 가지 중요한 설정

1. 성능 최적화

캐싱

• 콘텐츠 캐싱은 웹 서버의 응답 시간을 단축하고 백엔드 로드를 줄이는 데 매우 효과적입니다. NGINX에서 캐싱을 설정하려면, 캐시를 저장할 경로와 캐시의 유효기간 등을 지정해야 합니다.

http {
    proxy_cache_path /data/nginx/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_pass http://backend-server;
            proxy_cache_valid 200 302 60m;
            proxy_cache_valid 404 10m;
        }
    }
}

압축

• Gzip 압축을 사용하여 HTML, CSS, JavaScript 파일 등을 압축함으로써 대역폭을 절약하고 페이지 로드 시간을 줄일 수 있습니다.

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}

2. 보안 설정

HTTP Strict Transport Security (HSTS)

• HSTS 헤더를 사용하여 브라우저가 해당 사이트에 대한 모든 통신을 HTTPS를 통해서만 수행하도록 강제할 수 있습니다.

server {
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

SSL/TLS 최적화

• SSL 설정을 통해 연결 보안을 강화할 수 있습니다. 다음은 보안을 강화한 SSL 설정 예입니다.

server {
    listen 443 ssl;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
}

3. 로그 관리

• 로그 관리는 서버의 문제를 진단하고 사용자의 요청 패턴을 이해하는 데 중요합니다. NGINX에서는 다양한 로그 포맷을 설정하여 필요한 정보만을 로깅할 수 있습니다.

http {
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';
    access_log /var/log/nginx/access.log main;
}

4. 동적 모듈 사용

• NGINX는 여러 동적 모듈을 지원하여, 기능을 확장할 수 있습니다. 예를 들어, 이미지 필터 모듈을 사용하여 서버에서 이미지의 크기를 조정할 수 있습니다.

load_module modules/ngx_http_image_filter_module.so;

server {
    location /images/ {
        image_filter resize 300 300;
    }
}

이러한 고급 설정을 통해 NGINX 웹 서버의 성능과 보안을 크게 향상시킬 수 있으며, 서버 관리의 효율성을 높일 수 있습니다. 설정 변경 후에는 반드시 nginx -t 명령으로 구성을 검증하고, 변경사항을 적용하기 위해 NGINX를 재시작하거나 리로드해야 합니다.

NGINX 리버스 프록시 

NGINX를 리버스 프록시로 설정하는 것은 웹 애플리케이션의 성능을 향상시키고, 보안을 강화하며, 복잡한 트래픽 라우팅을 단순화하는 데 도움을 줍니다. 다음은 실제 사용 가능한 수준에서 리버스 프록시를 설정하는 예시코드입니다.

NGINX 리버스 프록시 설정 예시

이 예제에서는 NGINX를 사용하여 특정 요청을 내부 애플리케이션 서버로 전달하고, SSL을 구성하여 보안을 강화하는 방법을 보여줍니다.

# NGINX의 HTTP 서버 설정
http {
    # SSL 설정을 위한 인증서와 키 파일 경로
    ssl_certificate /etc/nginx/ssl/mydomain.com.crt;
    ssl_certificate_key /etc/nginx/ssl/mydomain.com.key;

    # 리스닝 포트와 SSL 활성화
    server {
        listen 443 ssl;
        server_name mydomain.com;

        # 클라이언트 요청에 대한 SSL 설정
        ssl_protocols TLSv1.2 TLSv1.3;  # TLS 프로토콜 버전 지정
        ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';  # 강력한 암호화 알고리즘 사용
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;

        # HTTP 요청을 HTTPS로 강제 리다이렉트
        location / {
            proxy_pass http://localhost:8080;  # 내부 애플리케이션 서버로 프록시
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;  # 웹소켓 지원을 위해 필요
            proxy_set_header Connection 'upgrade';  # 웹소켓 지원을 위해 필요
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;  # 실제 클라이언트 IP 주소 전달
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;  # 프로토콜 (http, https) 전달
            proxy_redirect off;
        }
    }
}

설명

• SSL/TLS 설정: ssl_certificate와 ssl_certificate_key를 사용하여 SSL 인증서와 키를 지정합니다. ssl_protocols와 ssl_ciphers를 통해 사용할 프로토콜과 암호화 알고리즘을 세부적으로 설정하여 통신을 보안합니다.
• Proxy 설정: proxy_pass 지시어를 사용하여 모든 요청을 내부 서버 http://localhost:8080으로 전달합니다. 이는 NGINX가 클라이언트와 서버 간의 중개자 역할을 하게 하며, 보안, 로드 밸런싱, 캐싱 등 다양한 기능을 제공할 수 있습니다.
• 헤더 설정: proxy_set_header를 사용하여 요청 헤더를 조정합니다. 이를 통해 내부 서버가 클라이언트 정보를 정확히 파악하고, 올바르게 응답할 수 있도록 합니다.
• 웹소켓 지원: Upgrade와 Connection 헤더를 설정하여 NGINX가 웹소켓 연결을 적절히 처리할 수 있도록 합니다.

이 설정을 통해 NGINX는 안전하고 효율적인 리버스 프록시 서버로서의 역할을 수행할 수 있습니다. 설정을 변경한 후에는 반드시 NGINX 구성을 검증(nginx -t)하고, 변경사항을 적용하기 위해 NGINX를 재시작하거나 리로드합니다(nginx -s reload).

 

몇 가지 리버스 프록시 설정 기법에 대해 자세히 설명하겠습니다.

1. 로드 밸런싱과 서버 선택 알고리즘

리버스 프록시를 사용하여 로드 밸런싱을 구성할 때, 서버 선택 알고리즘을 사용하여 트래픽을 적절히 분산시킬 수 있습니다.

http {
    upstream myapp {
        least_conn;  # 연결 수가 가장 적은 서버에 요청을 할당
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com max_fails=3 fail_timeout=30s;  # 서버 실패 관리
    }

    server {
        location / {
            proxy_pass http://myapp;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

2. 캐싱 전략

고급 리버스 프록시 설정에서는 효율적인 캐싱 전략을 통해 백엔드 서버의 로드를 줄이고 사용자 경험을 향상시킬 수 있습니다.

proxy_cache_path /data/nginx/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_valid 200 1d;  # 200 상태 코드 응답을 1일 동안 캐시
        proxy_cache_valid 404 1m;  # 404 에러는 1분간만 캐시
        proxy_pass http://myapp;
        proxy_cache_revalidate on;  # 캐시된 응답의 유효성 재검사
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;  # 오류 시 스테일 캐시 사용
        proxy_cache_lock on;  # 동시 요청에 대해 캐시 미스가 발생할 경우, 한 요청만 백엔드로 전달
    }
}

3. SSL/TLS 종단 처리

리버스 프록시를 통한 SSL/TLS 종단 처리는 보안을 강화하고, 내부 네트워크 트래픽을 관리할 수 있게 합니다.

server {
    listen 443 ssl;
    server_name mydomain.com;

    ssl_certificate /etc/ssl/certs/mydomain.pem;
    ssl_certificate_key /etc/ssl/private/mydomain.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://myapp;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-SSL-Cipher $ssl_cipher;
        proxy_set_header X-SSL-Protocol $ssl_protocol;
    }
}

4. 웹소켓 지원

웹 애플리케이션에서 웹소켓을 사용하는 경우, 리버스 프록시 설정에서 웹소켓 연결을 제대로 처리할 수 있어야 합니다.

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    location /websocket {
        proxy_pass http://websocket_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

NGINX 로드 밸런싱

NGINX를 로드 밸런서로 사용하기 위한 설정은 주로 http 블록 안에 upstream 디렉티브를 통해 구현됩니다. 이 예제에서는 두 개의 백엔드 서버를 사용하여 로드 밸런싱을 설정하는 방법을 보여 드리겠습니다.

NGINX 로드 밸런싱 설정 예시

1. Upstream 설정: 이 설정은 NGINX가 트래픽을 분산시킬 백엔드 서버 그룹을 정의합니다.

http {
    upstream myapp {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80; # NGINX 서버가 클라이언트 요청을 받을 포트

        location / {
            proxy_pass http://myapp; # Upstream 그룹에 정의된 서버로 트래픽을 전달
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

설명

• upstream myapp: 로드 밸런싱을 위한 서버 그룹 myapp을 정의합니다. 여기서 backend1.example.com과 backend2.example.com은 로드 밸런싱 대상 서버의 호스트명 또는 IP 주소입니다.
• server: 클라이언트의 요청을 받을 서버를 설정합니다. 여기서 listen 80은 NGINX가 80 포트에서 요청을 받을 것임을 의미합니다.
• location /: 모든 요청을 처리할 위치 블록을 정의합니다. proxy_pass http://myapp;는 요청을 upstream 그룹 myapp으로 전달하라는 지시를 나타냅니다.
• proxy_set_header: 실제 클라이언트 정보를 백엔드 서버로 전달하기 위해 헤더를 설정합니다.

로드 밸런싱 방법

NGINX는 기본적으로 라운드 로빈 방식을 사용하여 요청을 각 서버에 균등하게 분산합니다. 추가적인 로드 밸런싱 메소드로는 다음과 같은 옵션이 있습니다:

• least_conn: 동시 연결 수가 가장 적은 서버에 요청을 보내는 방식입니다.
• ip_hash: 클라이언트의 IP 주소를 해싱하여 특정 서버에 요청을 지속적으로 보내는 방식입니다. 이는 세션 지속성을 보장할 필요가 있을 때 유용합니다.

예를 들어, least_conn 메소드를 사용하려면, upstream 블록에서 다음과 같이 설정할 수 있습니다:

upstream myapp {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

이 설정을 통해 NGINX는 로드 밸런싱을 수행하면서 백엔드 서버 간에 연결을 효율적으로 분산시킬 수 있습니다. 설정 후에는 NGINX를 다시 로드하여 변경사항을 적용해야 합니다(sudo nginx -s reload).

로드 밸런싱 방식

NGINX는 로드 밸런싱과 부하 분산에 탁월한 성능을 제공하는 웹 서버이자 리버스 프록시입니다. 고성능 부하분산을 위한 설정은 다양한 로드 밸런싱 방식과 성능 최적화 기술을 포함합니다. 다음은 NGINX에서 고성능 부하분산을 설정하는 방법을 상세히 설명합니다.

 

NGINX는 여러 가지 로드 밸런싱 방식을 지원합니다. 각 방식은 특정 시나리오에서 더 효율적일 수 있습니다.

라운드 로빈 (Round Robin)

기본적인 로드 밸런싱 방식으로, 요청을 순서대로 각 서버에 균등하게 분배합니다. 설정은 간단합니다:

http {
    upstream myapp {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        location / {
            proxy_pass http://myapp;
        }
    }
}

가중치 기반 (Weighted Round Robin)

각 서버에 가중치를 할당하여, 특정 서버에 더 많거나 적은 트래픽을 할당할 수 있습니다. 서버의 성능이 서로 다를 때 유용합니다:

http {
    upstream myapp {
        server backend1.example.com weight=3;
        server backend2.example.com weight=2;
        server backend3.example.com weight=1;
    }
}

최소 연결 (Least Connections)

현재 활성 연결 수가 가장 적은 서버를 우선적으로 선택합니다. 동적 콘텐츠나 긴 세션을 다룰 때 효과적입니다:

http {
    upstream myapp {
        least_conn;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }
}

해시 기반 (Hash) 

해시 기반 부하 분산은 클라이언트의 IP 주소, 헤더, URI 등을 기반으로 일관된 해싱 알고리즘을 사용하여 트래픽을 서버에 분산시킵니다. 이 방식은 세션 지속성을 유지할 필요가 있는 애플리케이션에 유용하며, 사용자의 요청을 동일한 서버로 지속적으로 라우팅할 수 있습니다.

http {
    upstream myapp {
        hash $remote_addr consistent;  # 클라이언트 IP를 기반으로 해시 계산
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        location / {
            proxy_pass http://myapp;
        }
    }
}

랜덤 (Random) 방식

랜덤 방식은 요청을 처리할 서버를 무작위로 선택합니다. 이 방식은 트래픽이 비교적 일정하고 세션 지속성이 크게 중요하지 않은 환경에서 유용할 수 있습니다. NGINX Plus에서는 random 지시어를 사용하여 구성할 수 있으며, 오픈 소스 버전에서는 별도의 모듈이나 스크립트를 사용해야 할 수도 있습니다.

http {
    upstream myapp {
        random two;  # 두 개의 서버 중 하나를 무작위로 선택
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        location / {
            proxy_pass http://myapp;
        }
    }
}

IP 해시 (IP Hash)

클라이언트의 IP 주소를 기반으로 서버를 선택하는 방식입니다. 일관된 세션 지속성을 제공합니다.

http {
    upstream myapp {
        ip_hash;
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        location / {
            proxy_pass http://myapp;
        }
    }
}

가중치와 최소 연결의 조합

서버의 가중치를 고려하면서 동시에 연결 수가 가장 적은 서버를 우선적으로 선택합니다.

http {
    upstream myapp {
        least_conn;
        server backend1.example.com weight=3;
        server backend2.example.com weight=1;
    }

    server {
        location / {
            proxy_pass http://myapp;
        }
    }
}

이러한 부하 분산 기법을 통해 서버의 부하를 균등하게 분산시키고, 특정 서버에 과부하가 걸리는 것을 방지할 수 있습니다. 각 기법은 서버 환경과 애플리케이션의 요구에 따라 적절히 선택하여 사용하면, 시스템의 안정성과 성능을 최적화할 수 있습니다. 설정 변경 후에는 항상 NGINX 구성을 검증하고 변경사항을 적용하기 위해 NGINX를 재시작하거나 리로드해야 합니다.

성능 최적화 기법

NGINX를 사용하여 웹 캐시를 설정하는 것은 웹 서버의 성능을 크게 향상시키고, 콘텐츠 전달을 가속화하며, 백엔드 서버의 부하를 줄일 수 있는 효과적인 방법입니다. 다음은 실제 사용할 수 있는 수준의 NGINX 웹 캐시 설정 예시코드입니다.

Keepalive 연결

백엔드 서버와의 연결을 유지하여, 연결 설정 및 해제에 따른 오버헤드를 줄일 수 있습니다. 이는 서버 간의 빠른 통신을 가능하게 하여 성능을 개선합니다:

http {
    upstream myapp {
        server backend1.example.com;
        server backend2.example.com;

        keepalive 32;  # 각 워커 프로세스 당 유지할 연결 수
    }

    server {
        location / {
            proxy_pass http://myapp;
            proxy_set_header Connection "";
            proxy_http_version 1.1;
        }
    }
}

캐싱

동적 콘텐츠조차도 캐싱 전략을 적용하여 응답 시간을 단축하고, 백엔드 서버의 부하를 줄일 수 있습니다. 응답을 캐시하여 반복 요청에 대해 빠르게 응답할 수 있습니다:

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

server {
    location / {
        proxy_pass http://myapp;
        proxy_cache my_cache;
        proxy_cache_valid 200 10m;
        proxy_cache_methods GET HEAD;
    }
}

 

NGINX 웹 캐시 설정 

이 설정은 NGINX에서 정적 파일 캐싱을 구현하는 방법을 보여줍니다. 설정에는 캐시 저장 경로, 캐시 키, 유효 기간 등의 세부 사항이 포함됩니다.

# 캐시 저장소를 설정합니다.
http {
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=STATIC:10m inactive=24h max_size=1g;

    server {
        listen 80;
        server_name example.com;

        # 정적 파일에 대한 위치 블록
        location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
            root /usr/share/nginx/html;
            access_log off;  # 정적 파일에 대한 접근 로그를 비활성화
            expires 30d;  # 브라우저 캐시 유효기간을 30일로 설정
            add_header Pragma public;
            add_header Cache-Control "public";
        }

        # 애플리케이션 콘텐츠에 대한 프록시 캐시 설정
        location / {
            proxy_pass http://backend-server;
            proxy_cache STATIC;  # 캐시 존 이름
            proxy_cache_valid 200 302 10m;  # 200 및 302 응답에 대한 캐시 유효 기간
            proxy_cache_valid 404 1m;  # 404 응답에 대한 캐시 유효 기간
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;  # 오류 응답 시 스테일 캐시 사용
            proxy_cache_revalidate on;  # 유효성 검사가 필요할 때 캐시를 다시 검증
            proxy_cache_min_uses 3;  # 최소 3회 요청 시 캐시 항목 저장
            proxy_cache_lock on;  # 요청 중복을 방지하기 위해 캐시 잠금 활성화
        }
    }
}

설명

• proxy_cache_path: 캐시 데이터를 저장할 경로와 캐시의 세부 설정을 정의합니다. keys_zone은 캐시 키와 메모리 크기를 설정합니다.
• location ~* .(jpg|jpeg|png|gif|ico|css|js)$: 정적 자원에 대한 캐싱 규칙을 정의합니다. 정적 파일 접근 로그를 비활성화하고, 캐시 만료 시간을 30일로 설정합니다.
• location /: 동적 콘텐츠에 대한 프록시 설정을 구성합니다. proxy_pass 지시어는 요청을 백엔드 서버로 전달합니다. proxy_cache와 관련된 다양한 지시어를 통해 캐시 동작을 세밀하게 제어합니다.

이 설정을 통해 웹 캐시를 효과적으로 활용하여 웹 사이트의 로딩 속도를 개선하고, 서버 부하를 줄이며, 전반적인 사용자 경험을 향상시킬 수 있습니다. 

 

이어서 캐시 기능과 설정 방법에 대해 자세히 설명하겠습니다.

1. 캐시 키 사용자 정의

기본적으로 NGINX는 요청의 전체 URL을 캐시 키로 사용합니다. 하지만 특정 요청 헤더나 쿼리 매개변수를 기반으로 캐시 키를 사용자 정의할 수 있어, 더욱 세밀한 캐시 제어가 가능합니다.

proxy_cache_key "$host$request_uri $cookie_user";

이 설정은 요청 도메인과 URI에 사용자별 쿠키를 추가하여 캐시 키를 구성합니다. 이 방법은 사용자별 세션 데이터를 캐시할 때 유용합니다.

2. 캐시 바이패스

특정 조건에서 캐시를 바이패스하고 항상 최신 콘텐츠를 백엔드 서버에서 직접 가져오게 설정할 수 있습니다. 이는 로그인 상태 또는 특정 쿼리 매개변수가 있는 요청에 유용할 수 있습니다.

proxy_cache_bypass $http_authorization $arg_nocache;

이 예제에서는 HTTP Authorization 헤더가 있거나 URL에 nocache 쿼리 매개변수가 포함된 경우 캐시를 사용하지 않고 요청을 백엔드 서버로 직접 전달합니다.

3. 캐시 정리 및 무효화

캐시 무효화는 콘텐츠 업데이트가 있을 때 기존 캐시된 데이터를 즉시 무효화하는 기능입니다. NGINX Plus에서는 API를 통해 캐시된 항목을 제거할 수 있지만, 무료 버전에서는 다른 접근 방법을 사용해야 합니다.

location /purge {
    allow 192.168.0.1;  # 관리자 IP
    deny all;
    proxy_cache_purge STATIC "$host$request_uri";
}

위 설정은 /purge 엔드포인트를 통해 특정 URL의 캐시를 제거할 수 있게 합니다. 이는 보안을 위해 특정 IP에서만 접근이 가능하도록 제한합니다.

4. 캐시 성능 최적화

NGINX의 캐시 시스템을 최적화하기 위해 캐시 파일의 저장 방법, 메모리 사용, 그리고 캐시 지속 시간을 세밀하게 조정할 수 있습니다.

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=STATIC:10m inactive=60m use_temp_path=off;

이 설정은 캐시 데이터를 저장할 경로, 디렉토리 구조, 캐시 메모리 영역, 캐시 유지 시간 및 임시 경로 사용 여부를 정의합니다.

5. 동적 콘텐츠의 캐시

동적 콘텐츠를 캐싱하는 것은 설정이 더 복잡하지만, 응답 시간을 크게 단축시키고 서버 부하를 줄일 수 있습니다.

location ~ \.php$ {
    proxy_pass http://backend;
    proxy_cache STATIC;
    proxy_cache_valid 200 1h;  # 성공 응답은 1시간 동안 캐시
    proxy_cache_use_stale updating error timeout invalid_header http_500 http_502 http_503 http_504;
}

이 설정은 PHP 파일에 대한 요청을 캐시하고, 오류 응답이 있을 경우 스테일 콘텐츠를 사용자에게 제공합니다.

이러한 고급 설정은 NGINX 웹 캐시의 효율을 최대화하고, 다양한 웹 애플리케이션 시나리오에서의 요구를 충족시킬 수 있습니다. 설정을 변경한 후에는 반드시 nginx -t 명령으로 구성을 검증하고, nginx -s reload로 변경사항을 적용해야 합니다.