NGINX 활용 가이드: 웹서버부터 API Gateway까지

NGINX는 웹 서버, 리버스 프록시, 로드 밸런서, 캐싱 서버, API 게이트웨이 등 다양한 역할을 수행할 수 있는 강력한 오픈소스 솔루션입니다. 특히 각 기능 구현을 위해 별개의 NGINX 서버로 구성이 필요한 것이 아닌, 하나의 NGINX 서버를 통해서 위 기능을 모두 사용할 수 있습니다.
이 포스트에서는 각 시나리오별로 NGINX 활용 방법을 살펴보겠습니다.

목차

1. NGINX 활용 – Web Server
2. NGINX 활용 – Reverse Proxy
3. NGINX 활용 – Load Balancer
4. NGINX 활용 – Caching Server
5. NGINX 활용 – API Gateway
6. 결론

1. NGINX 활용 – Web Server

NGINX는 빠르고 효율적인 정적 웹 서버를 목표로 만들어졌습니다. 다중 연결 처리 성능이 뛰어나고, 메모리 사용률이 낮으며, 파일 시스템에서 직접 정적 파일을 제공하는 데 최적화되어 있습니다.

사용 시나리오

• 고성능 정적 파일 제공이 필요한 경우: HTML, CSS, JavaScript, 이미지 등
• 대량의 동시 연결 처리가 필요한 경우: C10K 문제(동시 접속자 10,000명 처리) 해결
• 메모리 사용량을 최소화해야 하는 환경: 제한된 리소스에서도 효율적 운영

주요 특징

• Gzip 압축, HTTP/2 지원으로 페이지 로딩 속도 개선
• Event-driven 아키텍처로 적은 자원으로 높은 성능 제공
• 비동기 처리 방식으로 수천 개의 연결을 동시에 효율적으로 처리
• sendfile(), TCP_NODELAY, TCP_CORK 등 최적화 기법 기본 내장

구성 예시

server {
    listen 80;
    server_name www.example.com;

    root /var/www/html;
    index index.html index.htm;

    # 정적 파일 캐싱 최적화
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 30d;
        add_header Cache-Control "public, no-transform";
        access_log off;
    }

    # Gzip 압축 활성화
    gzip on;
    gzip_types text/plain text/css application/javascript application/json;
    gzip_min_length 1000;
}

2. NGINX 활용 – Reverse Proxy

Reverse Proxy는 외부 요청을 내부 서비스로 중계하며, 보안, 확장성, 중앙 집중 관리를 제공합니다. NGINX는 가장 널리 쓰이는 리버스 프록시 중 하나로, TLS termination, 요청 헤더 변경, 응답 캐싱까지 가능합니다.

사용 시나리오

• 내부 애플리케이션 서버 보호가 필요한 경우: 직접 노출 방지
• 여러 백엔드 서비스를 단일 진입점으로 통합해야 하는 경우
• TLS/SSL Termination을 중앙화하고 싶은 경우
• 레거시 애플리케이션의 보안 강화가 필요한 경우

주요 특징

• 내부 서버 아키텍처를 외부에 숨겨 보안 강화
• 백엔드 서버 변경 시 클라이언트 영향 최소화
• 요청/응답 헤더 수정 및 필터링 가능
• WebSocket 등 특수 프로토콜 지원

예시 구성

server {
    listen 443 ssl http2;
    server_name api.example.com;

    # SSL 설정
    ssl_certificate     /etc/ssl/certs/cert.pem;
    ssl_certificate_key /etc/ssl/private/key.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    # 백엔드 애플리케이션 서버로 프록시
    location / {
        proxy_pass http://internal-app:8080;
        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_connect_timeout 60s;
        proxy_read_timeout 60s;
    }
    
}

3. NGINX 활용 – Load Balancer

NGINX는 L7 로드 밸런서로도 훌륭한 역할을 수행합니다. 라운드로빈 알고리즘을 기본적으로 사용하며, 접속자 IP, 최소 연결 수 등을 기반으로 트래픽을 분산시킬 수 있습니다.

사용 시나리오

• 서비스의 수평적 확장이 필요한 경우: 여러 서버에 트래픽 분산
• 서버 장애에 대비한 고가용성 구성이 필요한 경우
• 서버 리소스를 효율적으로 활용해야 하는 경우

주요 특징

• 다양한 로드 밸런싱 알고리즘 지원
  • Round Robin: 순차적으로 요청 분배 (기본)
  • Least Connections: 연결이 적은 서버에 우선 분배
  • IP Hash: 클라이언트 IP 기반 일관된 분배 (세션 유지)
• 액티브(NGINX Plus 전용)/패시브 헬스 체크로 장애 서버 자동 감지
• 가중치(weight) 설정으로 서버별 부하 조절 가능

예시 구성

# 백엔드 서버 그룹 정의
upstream backend_servers {
    # 최소 연결 알고리즘 사용
    least_conn;
    
    # 서버 목록과 가중치, 실패 조건 정의
    server app1.internal:8080 weight=3 max_fails=3 fail_timeout=30s;
    server app2.internal:8080 weight=2;
    server backup.internal:8080 backup;  # 백업 서버
    
    # 연결 유지 시간 설정
    keepalive 32;
}

server {
    listen 80;
    server_name app.example.com;
    
    location / {
        proxy_pass http://backend_servers;
        proxy_set_header Connection "";  # HTTP/1.1 연결 재사용
        proxy_http_version 1.1;
        
        # 헬스 체크 실패 시 다음 서버로 재시도
        proxy_next_upstream error timeout http_500;
    }
}

4. NGINX 활용 – Caching Server

동일한 콘텐츠를 여러 번 전달하는 경우, 캐시 기능을 통해 응답 속도 향상과 백엔드 서버의 부하 감소 효과를 누릴 수 있습니다. NGINX는 강력한 프록시 캐시 기능을 제공합니다.

사용 시나리오

• 자주 요청되는 동일한 콘텐츠가 많은 경우
• 데이터베이스나 API 서버의 부하를 줄여야 하는 경우
• 사용자 응답 시간을 개선해야 하는 경우

주요 특징

• 메모리와 디스크 기반 캐싱 옵션 제공
• 세밀한 캐시 제어 가능 (TTL, 캐시 키, 조건부 캐싱)
• 스태일(stale) 콘텐츠 활용으로 백엔드 장애 시에도 서비스 유지
• 캐시 퍼지(purge) 기능으로 콘텐츠 갱신 관리(NGINX Plus 전용)

예시 구성

# 캐시 저장소 정의
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=content_cache:10m inactive=60m max_size=1g;

server {
    listen 80;
    server_name cache.example.com;
    
    # API 응답 캐싱
    location /api/ {
        proxy_pass http://backend-api;
        proxy_cache content_cache;
        
        # 상태 코드별 캐시 유효 시간
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404     1m;
        
        # 캐시 키 설정 (URL + 쿼리 파라미터)
        proxy_cache_key $scheme$host$request_uri;
        
        # 백엔드 서버 접속 불가 시 캐시된 응답 사용
        proxy_cache_use_stale error timeout updating;
        
        # 캐시 상태 헤더 추가
        add_header X-Cache-Status $upstream_cache_status;
        
        # 동일 URL 동시 요청 시 하나만 처리
        proxy_cache_lock on;
    }
    
    # 정적 파일 캐싱
    location /static/ {
        proxy_pass http://static-server;
        proxy_cache content_cache;
        proxy_cache_valid 200 30d;
        proxy_ignore_headers Cache-Control;
        proxy_cache_min_uses 2;  # 최소 2번 요청되어야 캐싱
    }
}

5. NGINX 활용 – API Gateway

최근 마이크로서비스 환경에서는 서비스 간 API 호출이 증가하며, 인증, 라우팅, 로깅, 속도 제한 등 다양한 기능을 처리하는 API Gateway가 필수 요소가 되었습니다. NGINX 는 이러한 기능을 활용 하여 API Gateway로 사용할 수 있습니다.

사용 시나리오

• 여러 마이크로서비스 API를 단일 진입점으로 통합해야 하는 경우
• API 인증과 접근 제어가 필요한 경우
• 요청 속도 제한(Rate Limiting)이 필요한 경우
• API 모니터링과 로깅을 중앙화하고 싶은 경우

장점

• URI 기반 라우팅으로 다양한 백엔드 서비스 연결
• JWT 검증(NGINX Plus 전용), API 키 인증 등 보안 기능 구현 가능
• IP, 사용자, 서비스별 요청 제한 설정
• 요청/응답 변환 및 재정의
• 상세한 API 액세스 로깅과 모니터링

예시 구성

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/ssl/certs/cert.pem;
    ssl_certificate_key /etc/ssl/private/key.pem;

    location /v1/users/ {
        limit_req zone=api_limit burst=10 nodelay;
        proxy_pass http://user-service;
    }

    location /v1/products/ {
        proxy_pass http://product-service;
    }

}

6. 결론

NGINX는 하나의 서버로 위와 같은 다양한 기능을 수행할 수 있기 때문에, 현재 환경에서 어떤 기능이 필요한지 먼저 정의한 후 해당 목적에 맞는 기능을 활성화하는 것이 가장 중요합니다.

NGINX의 상업용 구독 버전을 체험해 보고 싶으시다면 NGINX STORE를 통해 문의해 무료로 NGINX One trial을 체험해 보세요.