NGINX Management (NGINX CA, F5N1) 학습 가이드

이번 포스트에서는 NGINX Management 영역(F5N1)에 해당하는 필수 주제를 체계적으로 살펴보고 실무 환경에서의 활용법을 깊이 있게 이해합니다. NGINX는 단순한 웹 서버를 넘어 Reverse Proxy, Load Balancer, API Gateway 등 다양한 시나리오에서 강력한 성능과 안정성을 제공합니다.

목차

1. NGINX Management: 시나리오 정리
 1-1. Web Server
 1-2. Reverse Proxy
 1-3. Load Balancer
 1-4. API Gateway
 1-5. Content Cache
2. NGINX Management: 설정 파일 및 디렉토리 구조
 2-1. nginx.conf
 2-2. conf.d 디렉토리
 2-3. sites-available과 sites-enabled
 2-4. 기타 중요 디렉토리
3. NGINX Management: 사용자 및 권한 관리
 3-1. user 디렉티브
 3-2. 프로세스 권한 모델
 3-3. 파일 및 디렉토리 권한
 3-4. SELinux 컨텍스트
 3-5. 권한 관련 문제 해결
4. NGINX Management: Shared memory zone의 원리 및 설정
 4-1. NGINX Management: 공유 메모리 존의 작동 원리
 4-2. NGINX Management: Cache 주요 사용 사례
  4-2-1. 세션 캐싱
  4-2-2. 콘텐츠 캐싱
  4-2-3. 속도 제한
  4-2-4. 업스트림 서버 상태 공유
 4-3. 공유 메모리 존 크기 최적화
 4-4. 공유 메모리 존 용량 초과 시 동작
 4-5. NGINX Management: 고급 공유 메모리 설정
5. NGINX Management: 문제풀이 가이드

1. NGINX Management 시나리오 정리

NGINX는 현대 웹 인프라에서 다양한 역할을 수행하는 강력한 소프트웨어입니다. 단순한 웹 서버를 넘어 다양한 사용 사례에 적용할 수 있는 유연성을 제공합니다.

1-1. Web Server

NGINX는 정적 콘텐츠를 매우 효율적으로 제공할 수 있는 고성능 웹 서버입니다. 전통적인 Apache와 달리 이벤트 기반 비동기 아키텍처를 사용하여 적은 메모리로 수천 개의 동시 연결을 처리할 수 있습니다. 이러한 특성은 특히 정적 파일(HTML, CSS, JavaScript, 이미지 등)을 서빙할 때 두드러집니다.

NGINX의 웹 서버 구성은 간단하면서도 강력합니다. location 블록을 통해 URI 패턴별로 다양한 처리 로직을 적용할 수 있으며, try_files 디렉티브를 활용하여 파일 존재 여부에 따른 대체 경로 설정이 가능합니다. 또한 gzip 압축, 브라우저 캐싱, 접근 제어 등 다양한 기능을 통해 성능과 보안을 최적화할 수 있습니다.

server {
    listen 80;
    server_name example.com;
    root /var/www/html;
    
    location / {
        try_files $uri $uri/ /index.html;
    }
    
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }
}

1-2. Reverse Proxy

NGINX Management 의 가장 강력한 기능 중 하나는 리버스 프록시로서의 역할입니다. 클라이언트와 백엔드 서버 사이에서 중개자 역할을 수행하여 요청을 백엔드로 전달하고 응답을 다시 클라이언트에게 반환합니다. 이를 통해 다음과 같은 여러 이점을 제공합니다:

  1. 보안 강화: 백엔드 서버를 직접 인터넷에 노출시키지 않고 NGINX가 모든 트래픽을 필터링
  2. SSL Termination: HTTPS 연결 처리를 NGINX에서 담당하여 백엔드 서버의 부하 감소
  3. 부하 분산: 여러 백엔드 서버로 트래픽 분산
  4. 콘텐츠 압축: 응답 데이터 압축을 통한 대역폭 절약
  5. URL 재작성: 내부 URL 구조를 외부에 노출시키지 않고 깔끔한 URL 제공
server {
    listen 80;
    server_name api.example.com;
    
    location /api/ {
        proxy_pass http://backend_servers/;
        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;
        
        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
        proxy_busy_buffers_size 256k;
    }
}

이 설정에서 /api/ 경로로 들어오는 모든 요청은 backend_servers 업스트림 그룹으로 전달됩니다. proxy_set_header 디렉티브를 통해 원본 클라이언트 정보를 백엔드 서버에 전달하고, 버퍼 관련 설정으로 성능을 최적화합니다.

1-3. Load Balancer

NGINX Management 의 기능 중 하나인 소프트웨어 로드 밸런서는 여러 서버 간에 트래픽을 효율적으로 분산시킬 수 있습니다. HTTP, HTTPS, TCP, UDP 프로토콜을 지원하며, 다양한 로드 밸런싱 알고리즘을 제공합니다:

  1. Round Robin: 순차적으로 각 서버에 요청 분배 (기본 알고리즘)
  2. Least Connections: 현재 연결 수가 가장 적은 서버로 요청 전달
  3. IP Hash: 클라이언트 IP 주소를 해싱하여 항상 동일한 서버로 라우팅 (세션 유지)
  4. Least Time (NGINX Plus): 응답 시간과 연결 수를 고려하여 서버 선택

또한 Health Checks 기능을 통해 장애가 발생한 서버를 자동으로 감지하고 트래픽에서 제외할 수 있습니다.

upstream backend {
    least_conn;
    server backend1.example.com weight=3;
    server backend2.example.com weight=2;
    server backup1.example.com backup;
    
    keepalive 16;
}

server {
    listen 80;
    
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}
upstream backend {
    least_conn;
    server backend1.example.com weight=3;
    server backend2.example.com weight=2;
    server backup1.example.com backup;
    
    keepalive 16;
}

server {
    listen 80;
    
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

이 예시에서는 least_conn 알고리즘을 사용하여 연결 수가 가장 적은 서버로 요청을 분배하며, weight 매개변수를 통해 서버 간 용량 차이를 반영합니다. backup 서버는 주 서버가 모두 실패할 경우에만 사용됩니다.

1-4. API Gateway

마이크로서비스 아키텍처에서 NGINX는 API Gateway 역할을 수행할 수 있습니다. 모든 API 요청의 진입점으로 작동하면서 다음과 같은 핵심 기능을 제공합니다:

  1. 요청 라우팅: URI 패턴, HTTP 메서드, 헤더 등에 따라 적절한 마이크로서비스로 요청 전달
  2. 인증 및 인가: JWT 검증, OAuth 통합 등을 통한 접근 제어
  3. 속도 제한: 클라이언트별, 엔드포인트별 요청 제한으로 서비스 보호
  4. 요청/응답 변환: 헤더 추가/제거, 본문 변환, 프로토콜 변환 등
  5. API 버전 관리: URI 경로, 헤더, 쿼리 파라미터 등을 통한 버전 라우팅
  6. 모니터링 및 로깅: 중앙화된 API 트래픽 모니터링 및 디버깅

NGINX Plus를 사용하면 API 키 관리, JWT 검증, 고급 모니터링 등 추가 기능을 활용할 수 있습니다.

1-5. Content Cache

NGINX는 강력한 콘텐츠 캐싱 기능을 제공하여 백엔드 서버의 부하를 줄이고 응답 시간을 단축시킬 수 있습니다. 정적 콘텐츠뿐만 아니라 동적 콘텐츠의 결과도 캐싱할 수 있어 다양한 상황에서 활용 가능합니다.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=PROXY:10m inactive=24h max_size=1g;

server {
    listen 80;
    
    location / {
        proxy_cache PROXY;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_lock on;
        proxy_cache_background_update on;
        
        proxy_pass http://backend;
    }
}

이 설정은 성공 응답(200, 302)은 10분, 404 응답은 1분 동안 캐싱합니다. proxy_cache_use_stale 디렉티브는 백엔드 서버에 오류가 발생하거나 응답이 지연될 경우 오래된 캐시 콘텐츠를 제공하여 가용성을 향상시킵니다. proxy_cache_lock은 동일한 리소스에 대한 중복 요청을 방지하고, proxy_cache_background_update는 캐시 갱신을 백그라운드에서 수행하여 사용자 경험을 개선합니다.

2. NGINX Management: 설정 파일 및 디렉토리 구조

NGINX의 설정은 계층적이고 모듈화된 구조를 가지고 있어 복잡한 환경에서도 관리하기 쉽습니다. 주요 설정 파일과 디렉토리 구조를 이해하는 것은 NGINX를 효과적으로 관리하기 위한 기본입니다

2-1. nginx.conf

nginx.conf는 NGINX의 메인 설정 파일로, 일반적으로 /etc/nginx/nginx.conf에 위치합니다. 이 파일은 전역 설정과 주요 컨텍스트를 정의하며, 다음과 같은 구조를 가집니다.

user nginx;                # 워커 프로세스 실행 사용자
worker_processes auto;     # 워커 프로세스 수 (auto는 CPU 코어 수에 맞춤)
pid /var/run/nginx.pid;    # 마스터 프로세스 PID 파일 경로
error_log /var/log/nginx/error.log warn;  # 오류 로그 설정

# 이벤트 처리 방식 설정
events {
    worker_connections 1024;  # 워커당 최대 연결 수
    multi_accept on;          # 한 번에 여러 연결 수락
    use epoll;                # 리눅스에서 권장되는 이벤트 처리 방식
}

# HTTP 서버 설정
http {
    include /etc/nginx/mime.types;  # MIME 타입 정의
    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;
    
    # 성능 최적화 설정
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    
    # GZIP 압축 설정
    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;
    
    # 가상 호스트 설정 포함
    include /etc/nginx/conf.d/*.conf;
}

# MAIL 프록시 설정 (선택적)
mail {
    # 메일 서버 설정
}

# STREAM 프록시 설정 (TCP/UDP, 선택적)
stream {
    # TCP/UDP 로드 밸런싱 설정
}

이 기본 구조에서 가장 중요한 컨텍스트는 다음과 같습니다.

  1. Main Context: 파일 최상위 레벨로, 전역 설정을 정의합니다.
  2. events: 네트워크 이벤트 처리와 관련된 설정을 포함합니다.
  3. http: HTTP/HTTPS 트래픽 처리를 위한 설정을 포함합니다.
  4. server: 가상 호스트 설정으로, http 컨텍스트 내에 위치합니다.
  5. location: URI 패턴별 처리 로직으로, server 컨텍스트 내에 위치합니다.
  6. mail: 메일 프록시 관련 설정입니다 (POP3/IMAP/SMTP).
  7. stream: TCP/UDP 트래픽 처리를 위한 설정입니다.

2-2. conf.d 디렉토리

conf.d 디렉토리는 일반적으로 개별 가상 호스트(Virtual Host)나 특정 기능에 대한 설정을 저장하는 데 사용됩니다. nginx.conf에서 include conf.d/*.conf; 디렉티브를 통해 이 디렉토리의 모든 .conf 파일을 포함시킵니다.

이러한 모듈화된 접근 방식은 여러 가지 이점을 제공합니다:

  • 설정의 논리적 분리로 유지보수성 향상
  • 특정 사이트나 기능만 활성화/비활성화 가능
  • 설정 파일의 가독성 향상
  • 여러 관리자가 독립적으로 작업 가능

일반적인 가상 호스트 설정 파일 예시 (conf.d/example.com.conf)

server {
    listen 80;
    server_name example.com www.example.com;
    
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;
    
    root /var/www/example.com;
    index index.html index.htm;
    
    location / {
        try_files $uri $uri/ =404;
    }
    
    # PHP 처리 설정
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
    
    # 정적 파일 캐싱 설정
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 30d;
    }
}

2-3. sites-available과 sites-enabled

Debian/Ubuntu 계열 리눅스 배포판에서는 conf.d 대신 sites-available과 sites-enabled 디렉토리를 사용하는 방식이 일반적입니다:

  • sites-available: 사용 가능한 모든 가상 호스트 설정을 저장
  • sites-enabled: 실제로 활성화된 가상 호스트의 심볼릭 링크를 저장

이 구조를 사용하면 a2ensite/a2dissite와 유사한 nginx-ensite/nginx-dissite 명령이나 심볼릭 링크를 직접 관리하여 특정 사이트를 쉽게 활성화/비활성화할 수 있습니다.

# 사이트 활성화
ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/

# 사이트 비활성화
rm /etc/nginx/sites-enabled/example.com.conf

이 경우 nginx.conf의 http 컨텍스트에는 다음과 같은 include 문이 있습니다:

include /etc/nginx/sites-enabled/*.conf;
  • modules-available/modules-enabled: 동적 모듈 관리를 위한 디렉토리로, 사이트와 유사한 방식으로 동작합니다.
  • /var/log/nginx/: 기본 로그 파일 디렉토리로, access.log와 error.log가 저장됩니다.
  • /var/cache/nginx/: 캐시 데이터가 저장되는 기본 디렉토리입니다.
  • /var/www/html/: 기본 문서 루트 디렉토리입니다.

2-4. 기타 중요 디렉토리

  • modules-available/modules-enabled: 동적 모듈 관리를 위한 디렉토리로, 사이트와 유사한 방식으로 동작합니다.
  • snippets: 여러 설정 파일에서 공통으로 사용되는 설정 조각을 저장합니다.
  • /var/log/nginx/: 기본 로그 파일 디렉토리로, access.log와 error.log가 저장됩니다.
  • /var/cache/nginx/: 캐시 데이터가 저장되는 기본 디렉토리입니다.
  • /var/www/html/: 기본 문서 루트 디렉토리입니다.

3. NGINX Management: 사용자 및 권한 관리

NGINX의 보안 모델은 마스터 프로세스와 워커 프로세스의 권한 분리를 기반으로 합니다. 적절한 사용자 권한 설정은 보안을 강화하고 잠재적인 취약점을 줄이는 데 중요합니다.

3-1. user 디렉티브

NGINX는 기본적으로 root로 시작된 후 설정된 사용자 계정(예: nginx, www-data)의 권한으로 worker 프로세스를 실행합니다. 이로써 보안을 강화하고 권한 문제로 인한 보안 리스크를 최소화할 수 있습니다.

nginx.conf의 메인 컨텍스트에 위치한 user 디렉티브는 워커 프로세스가 실행될 사용자와 그룹을 지정합니다.

user nginx;         # nginx 사용자로 워커 프로세스 실행
# 또는
user nginx nginx;   # 사용자와 그룹을 모두 지정

NGINX는 일반적으로 다음과 같은 사용자로 실행됩니다:

  • Debian/Ubuntu: www-data
  • CentOS/RHEL: nginx
  • Alpine: nginx

보안 관점에서 워커 프로세스는 가능한 한 제한된 권한을 가진 전용 사용자로 실행하는 것이 좋습니다. 절대로 root 사용자로 워커 프로세스를 실행해서는 안 됩니다.

3-2. 프로세스 권한 모델

NGINX는 두 종류의 프로세스를 실행합니다:

  1. 마스터 프로세스: root 권한으로 실행되어 80, 443과 같은 특권 포트를 바인딩하고 워커 프로세스를 관리합니다.
  2. 워커 프로세스: user 디렉티브에 지정된 권한으로 실행되어 실제 클라이언트 요청을 처리합니다.

이 이중 프로세스 모델은 최소 권한 원칙을 따르면서도 특권 포트에 바인딩할 수 있게 해줍니다. 마스터 프로세스는 포트를 열고 워커 프로세스를 시작한 후 대부분의 작업을 워커 프로세스에 위임합니다.

3-3. 파일 및 디렉토리 권한

NGINX가 적절히 동작하려면 다음 리소스에 대한 올바른 권한이 필요합니다:

  1. 설정 파일: 일반적으로 root만 읽고 쓸 수 있어야 합니다 (644 또는 640).
  2. 로그 디렉토리: NGINX 사용자가 쓰기 권한을 가져야 합니다.
  3. 콘텐츠 디렉토리: NGINX 사용자는 읽기 권한이 필요하며, 업로드 기능이 있는 디렉토리는 쓰기 권한도 필요합니다.
  4. SSL 인증서: 보안상의 이유로 엄격한 권한(600 또는 400)이 필요합니다.
  5. 캐시 디렉토리: NGINX 사용자는 읽기/쓰기 권한이 필요합니다.

일반적인 권한 설정 예시:

# 설정 파일 및 디렉토리
chown -R root:root /etc/nginx
chmod -R 644 /etc/nginx
find /etc/nginx -type d -exec chmod 755 {} \;

# 로그 디렉토리
chown -R nginx:nginx /var/log/nginx
chmod -R 755 /var/log/nginx

# 웹 콘텐츠
chown -R root:root /var/www/html
chmod -R 755 /var/www/html

# SSL 인증서
chown -R root:root /etc/nginx/ssl
chmod -R 600 /etc/nginx/ssl

3-4. SELinux 컨텍스트

SELinux가 활성화된 환경(CentOS/RHEL)에서는 적절한 보안 컨텍스트 설정도 필요합니다.

# 웹 콘텐츠에 httpd_sys_content_t 컨텍스트 적용
semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
restorecon -Rv /var/www/html

# 로그 파일에 httpd_log_t 컨텍스트 적용
semanage fcontext -a -t httpd_log_t "/var/log/nginx(/.*)?"
restorecon -Rv /var/log/nginx

# 업로드 디렉토리에 httpd_sys_rw_content_t 컨텍스트 적용
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html/uploads(/.*)?"
restorecon -Rv /var/www/html/uploads

또한, NGINX가 프록시로 작동하는 경우 네트워크 연결을 허용하는 SELinux boolean 설정이 필요합니다:

setsebool -P httpd_can_network_connect on

3-5. 권한 관련 문제 해결

NGINX에서 가장 흔한 권한 관련 오류는 403 Forbidden 응답이나 로그 파일에 액세스할 수 없는 문제입니다. 이러한 문제를 해결하는 단계는 다음과 같습니다:

  1. 오류 로그 확인: /var/log/nginx/error.log
  2. 파일 소유권 및 권한 확인: ls -la /path/to/resource
  3. SELinux 컨텍스트 확인: ls -Z /path/to/resource
  4. SELinux 감사 로그 확인: ausearch -m avc -ts recent
  5. 필요한 경우 권한 또는 컨텍스트 조정

4. NGINX Management: Shared memory zone의 원리 및 설정

NGINX의 shared memory zone(공유 메모리 영역)은 여러 워커 프로세스 간에 데이터를 공유하기 위한 메커니즘입니다. 이는 세션 데이터, 캐시 키, 속도 제한 상태 등을 저장하는 데 사용되며, 워커 프로세스가 일관된 상태 정보를 유지할 수 있게 해줍니다.

4-1. NGINX Management: 공유 메모리 존의 작동 원리

NGINX의 shared memory zone(공유 메모리 영역)은 여러 워커 프로세스 간에 데이터를 공유하기 위한 메커니즘입니다. 이는 세션 데이터, 캐시 키, 속도 제한 상태 등을 저장하는 데 사용되며, 워커 프로세스가 일관된 상태 정보를 유지할 수 있게 해줍니다.

NGINX는 이벤트 기반 다중 프로세스 아키텍처를 사용합니다. 마스터 프로세스는 여러 워커 프로세스를 생성하고, 각 워커 프로세스는 독립적으로 클라이언트 요청을 처리합니다. 이 모델은 CPU 코어를 효율적으로 활용할 수 있지만, 프로세스 간 데이터 공유가 필요한 상황이 발생합니다.

공유 메모리 존은 시스템 RAM의 일부를 여러 프로세스가 접근할 수 있는 공유 영역으로 할당합니다. 이를 통해 워커 프로세스는 동일한 메모리 공간에서 데이터를 읽고 쓸 수 있습니다. 각 존은 이름과 크기를 가지며, 특정 용도로 사용됩니다.

공유 메모리 존은 다음과 같은 특징을 가집니다:

  1. 지속성: NGINX 재시작 시 메모리 내용이 초기화됩니다.
  2. 동시성 제어: 여러 프로세스가 동시에 접근할 때 데이터 일관성 보장
  3. 고성능: 디스크 I/O보다 훨씬 빠른 메모리 기반 작업
  4. 크기 제한: 설정 시 지정된 크기를 초과할 수 없음

4-2. NGINX Management: Cache 주요 사용 사례

4-2-1. 세션 캐싱

SSL/TLS 세션 정보를 캐싱하여 재사용함으로써 핸드셰이크 오버헤드를 줄입니다.

http {
    ssl_session_cache shared:SSL:10m;  # 10MB 크기의 SSL 세션 캐시
    ssl_session_timeout 10m;           # 세션 타임아웃
}

이 설정은 약 40,000개의 세션을 저장할 수 있습니다(세션당 약 4KB 가정).

4-2-2. 콘텐츠 캐싱

프록시 응답, FastCGI 응답 등을 캐싱하여 백엔드 서버 부하를 줄입니다:

http {
    proxy_cache_path /path/to/cache levels=1:2 keys_zone=PROXY_CACHE:10m inactive=60m max_size=1g;
    
    server {
        location / {
            proxy_cache PROXY_CACHE;
            proxy_cache_valid 200 302 10m;
            proxy_pass http://backend;
        }
    }
}

여기서 keys_zone=PROXY_CACHE:10m은 캐시 키와 메타데이터를 저장하기 위한 10MB 크기의 공유 메모리 존을 생성합니다. 실제 캐시된 콘텐츠는 디스크에 저장되지만, 키와 메타데이터는 빠른 접근을 위해 메모리에 유지됩니다.

4-2-3. 속도 제한

특정 클라이언트나 요청에 대한 속도 제한을 설정하여 시스템을 보호합니다:

http {
    # 클라이언트 IP당 초당 10개 요청으로 제한
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    
    # 클라이언트 IP당 최대 5개 동시 연결로 제한
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    
    server {
        location / {
            limit_req zone=req_limit burst=20 nodelay;
            limit_conn conn_limit 5;
        }
    }
}

여기서는 두 개의 공유 메모리 존을 생성합니다:

  • req_limit: 요청 속도 상태를 저장하는 10MB 크기의 존
  • conn_limit: 연결 수 상태를 저장하는 10MB 크기의 존

$binary_remote_addr 변수는 클라이언트 IP 주소의 바이너리 형태로, 일반 텍스트 IP보다 메모리를 적게 사용합니다(IPv4 주소당 4바이트). 10MB 존은 약 160,000개의 IP 주소 상태를 저장할 수 있습니다.

4-2-4. 업스트림 서버 상태 공유

upstream 블록에서 여러 워커 프로세스 간에 서버 상태 정보를 공유합니다:

http {
    upstream backend {
        zone backend 64k;  # 64KB 크기의 공유 메모리 존
        server backend1.example.com;
        server backend2.example.com;
        
        least_conn;  # 최소 연결 알고리즘
        keepalive 32;  # 백엔드 서버당 유지할 최대 유휴 keepalive 연결 수
    }
}

이 설정에서 zone 디렉티브는 업스트림 서버 그룹의 상태(활성/비활성, 현재 연결 수, 실패 횟수 등)를 저장하기 위한 64KB 크기의 공유 메모리 존을 생성합니다. 이를 통해 모든 워커 프로세스가 동일한 업스트림 상태 정보에 접근할 수 있습니다.

4-3. 공유 메모리 Zone 크기 최적화

공유 메모리 Zone의 적절한 크기를 결정하는 것은 NGINX 성능 최적화의 중요한 부분입니다. 크기가 너무 작으면 상태 정보가 유실되고, 너무 크면 불필요한 메모리가 낭비됩니다.

일반적인 가이드라인:

  1. 캐시 존 크기: 캐시할 항목 수에 따라 결정
    • SSL 세션: 세션당 약 4KB (10MB = 약 40,000개 세션)
    • 프록시 캐시 키: 항목당 약 64바이트 (10MB = 약 160,000개 항목)
  2. 속도 제한 Zone 크기: 추적할 클라이언트 수에 따라 결정
    • IPv4 주소: 주소당 약 64바이트 (10MB = 약 160,000개 IP)
    • 더 복잡한 키: 키 크기에 따라 다름
  3. 모니터링 및 조정:
    • zone_memory_stats와 같은 고급 모니터링 도구를 사용하여 사용량 추적 (NGINX Plus)
    • 포화 상태가 감지되면 크기 증가
    • 사용률이 낮으면 크기 감소 고려

4-4. 공유 메모리 Zone 용량 초과 시 동작

공유 메모리 Zone이 용량을 초과하면 NGINX의 동작은 존의 용도에 따라 달라집니다:

  1. 캐시 Zone:
    • 가장 오래 사용되지 않은(LRU) 항목을 제거하여 새 항목을 위한 공간 확보
    • 캐시 효율성 감소 (캐시 미스 증가)
    • 오류는 발생하지 않지만 성능이 저하될 수 있음
  2. 속도 제한 Zone:
    • 새로운 클라이언트의 요청을 추적할 수 없음
    • 기존 클라이언트는 계속 추적
    • 오류 로그에 “limit_req_zone … usage near limit” 같은 경고 메시지 표시
    • 보호 메커니즘의 효과 감소
  3. 연결 제한 Zone:
    • 새로운 클라이언트의 연결 상태를 추적할 수 없음
    • 연결 제한 정책이 일부 클라이언트에 적용되지 않을 수 있음
  4. 업스트림 Zone:
    • 워커 프로세스 간 서버 상태 공유가 불완전해질 수 있음
    • 부하 분산 결정의 효율성 감소

용량 초과 문제를 방지하기 위해 적절한 모니터링과 크기 조정이 중요합니다.

4-5. NGINX Management: 고급 공유 메모리 설정

worker_processes와의 관계

worker_processes 설정은 실행되는 워커 프로세스 수를 결정하며, 이는 공유 메모리 존 크기에 영향을 미칩니다. 워커 수가 많을수록 동시에 존에 접근하는 프로세스가 많아지므로, 동시성 제어 오버헤드가 증가할 수 있습니다.

worker_processes auto;  # CPU 코어 수에 맞춰 자동 설정

accept_mutex와 공유 메모리

accept_mutex 디렉티브는 워커 프로세스 간의 “thundering herd” 문제를 방지하기 위해 연결 수락을 조정하는 역할을 합니다. 이 기능도 내부적으로 공유 메모리를 사용합니다.

Zone Sync (NGINX Plus)

NGINX Plus는 여러 NGINX 인스턴스 간에 공유 메모리 존 데이터를 동기화하는 Zone Sync 기능을 제공합니다. 이를 통해 여러 서버에 분산된 환경에서도 일관된 상태를 유지할 수 있습니다.

http {
    zone_sync {
        server 192.168.1.2:9000;
        server 192.168.1.3:9000;
        zone sessions 1m;  # sessions 존을 동기화
    }
}

NGINX CA에 대한 다양한 학습가이드는 아래에서 확인할 수 있습니다.

1. NGINX Management (NGINX CA, F5N1) 학습 가이드
2. NGINX Configuration: Knowledge (NGINX CA, F5N2) 학습 가이드
3. NGINX Configuration: Demonstrate (NGINX CA, F5N3) 학습 가이드
4. NGINX Troubleshoot (NGINX CA, F5N4) 학습 가이드

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

* indicates required