Nginx 완벽 가이드 | 리버스 프록시·로드 밸런싱·SSL·캐싱·성능 최적화

Nginx 완벽 가이드 | 리버스 프록시·로드 밸런싱·SSL·캐싱·성능 최적화

· 9분 읽기 · 수정 중급
Nginx 완벽 가이드 | 리버스 프록시·로드 밸런싱·SSL·캐싱·성능 최적화

이 글의 핵심

Nginx 완벽 가이드에 대해 정리한 개발 블로그 글입니다. Nginx로 고성능 웹 서버를 구축하는 완벽 가이드입니다. 내부 구조(이벤트 루프, 마스터/워커, 설정 상속, 로드 밸런싱 알고리즘, 프로덕션 패턴)를 먼저 짚은 뒤, 설치·리버스 프록시·로드… 개념과 예제 코드를 단계적으로 다루며, 실무·학습에 참고할 수 있도록 구성했습니다. 관련 키워드: Nginx, Web Server,…

이 글의 핵심

Nginx로 고성능 웹 서버를 구축하는 완벽 가이드입니다. 내부 구조(이벤트 루프, 마스터/워커, 설정 상속, 로드 밸런싱 알고리즘, 프로덕션 패턴)를 먼저 짚은 뒤, 설치·리버스 프록시·로드 밸런싱·SSL/TLS·캐싱·성능 최적화를 실전 예제로 정리했습니다.

실무 경험 공유: Apache 기반 서비스를 Nginx로 전환하면서 동시 접속자 처리량을 크게 늘리고 메모리 사용량을 줄인 경험을 바탕으로, 실무에서 자주 마주치는 함정과 함께 정리했습니다.

들어가며: 문서와 운영의 간극

로드 밸런싱은 문서상으로는 upstream 블록 몇 줄만 추가하면 끝나는 것처럼 보입니다. 하지만 실제 운영 환경에서는 “왜 이 노드에서만 장애가 발생하는가”와 같은 문제가 훨씬 자주 발생합니다. 아래 시나리오는 실무 팀에서 반복적으로 관찰되는 대표적인 패턴입니다.

실무에서 자주 마주치는 문제

1. 동시 접속이 많아지면 응답이 느려지는 경우 — Apache는 대략 1,000 동시 접속 근처에서 성능 저하를 겪는 경우가 많은 반면, Nginx는 환경과 워커 설정, TLS 부하에 따라 훨씬 높은 동시 접속까지 안정적으로 처리하는 편입니다.

2. 정적 파일 요청이 애플리케이션 서버를 거치는 경우 — JS, CSS, 이미지 파일까지 Node.js나 Spring 같은 애플리케이션 서버가 직접 처리하면 자원 낭비가 큽니다. Nginx를 앞단에 두어 정적 파일을 직접 서빙하면 체감 성능이 크게 개선됩니다.

3. SSL 인증서 관리가 번거로운 경우 — Let’s Encrypt와 Certbot 조합을 한 번 구성해 두면, 이후에는 자동 갱신만 확인하면 됩니다. 수작업으로 인증서를 교체하던 방식과 비교하면 운영 부담이 크게 줄어듭니다.

1. Nginx란?

핵심 특징

Nginx는 고성능 웹 서버이자 리버스 프록시입니다. 주요 사용 사례

  • 웹 서버: 정적 파일 서빙

  • 리버스 프록시: 백엔드 앞단

  • 로드 밸런서: 트래픽 분산

  • SSL 종료: HTTPS 처리

  • 캐싱: 응답 캐싱 성능

  • 동시 접속: 10,000+ connections

  • 메모리: 2.5MB per worker

2. 내부 구조: 이벤트 루프·워커·설정 상속·로드 밸런싱·프로덕션 패턴

실무에서 Nginx를 “설정만 복사”하는 수준에 머무르면, 튜닝 한계와 장애 대응이 어렵습니다. 이 절에서는 프로세스 모델, 이벤트 기반 I/O, 설정 컨텍스트 상속, 업스트림 알고리즘, 프로덕션 운영 패턴을 한 번에 정리합니다.

이벤트 기반 아키텍처

전통적인 프로세스/스레드 기반 웹 서버는 요청마다 자원을 할당합니다. 동시 접속이 늘면 컨텍스트 스위칭과 메모리 오버헤드가 커집니다. Nginx 워커는 이벤트 루프 위에서 동작하며, 수많은 커넥션을 소수의 프로세스로 처리합니다.

  • 이벤트 모듈: Linux에서는 epoll, BSD/macOS에서는 kqueue를 사용합니다. 설정의 events { use epoll; }는 이 경로를 명시합니다(플랫폼에 따라 생략 가능).
  • 한 워커, 다수 커넥션: 각 워커는 “준비된 소켓”만 처리합니다. 읽기/쓰기가 블로킹되지 않도록 논블로킹 소켓과 커널 이벤트 알림에 의존합니다.
  • sendfile: 디스크에서 소켓으로 데이터를 옮길 때 사용자 공간 복사를 줄이는 경로로, 정적 파일 서빙에서 CPU와 메모리 대역폭을 절약합니다.
  • worker_connections: 워커당 동시에 처리할 수 있는 커넥션 수 상한입니다. worker_processes × worker_connections가 이론상의 동시 접속 상한에 가깝으며, 실제로는 파일 디스크립터 제한(ulimit -n)과 맞춰야 합니다.

이 구조가 C10K(만 단위 동시 접속) 문제에 대응하기 쉬운 이유입니다. 다만 CPU 집약적인 TLS 핸드셰이크나 큰 본문 처리는 워커에 부하를 집중시키므로, 이 경우 워커 수·하드웨어 스펙·TLS 세션 재개 등을 함께 봐야 합니다.

워커 프로세스 모델

Nginx는 master 프로세스와 worker 프로세스로 나뉩니다.

  • Master: 설정 파일을 읽으며, 워커를 포크합니다. 포트 바인딩·권한 상승(예: 80번 포트)은 보통 마스터가 담당하며, 워커는 연결을 처리합니다.
  • Worker: 실제 HTTP 요청 처리, 리버스 프록시, 캐시 I/O 등이 여기서 수행됩니다. worker_processes auto는 CPU 코어 수에 맞추는 일반적인 선택입니다.
  • 무중단 리로드: nginx -s reload 또는 SIGHUP은 새 설정으로 워커를 순차 교체하는 graceful reload입니다. 진행 중인 요청을 끊지 않도록 설계되어 있으나, 백엔드 연결·타임아웃 설정과 함께 봐야 합니다.
  • 종료: SIGTERM은 graceful shutdown, SIGQUIT도 graceful, SIGKILL은 즉시 종료입니다. 배포 스크립트와 systemd 유닛이 어떤 시그널을 쓰는지 확인하는 것이 좋습니다.

워커는 서로 메모리를 공유하지 않습니다. 공유 캐시가 필요하면 OS 페이지 캐시에 의존하거나, Redis 등 외부 캐시를 쓰는 패턴이 일반적입니다.

설정 상속과 병합

Nginx 설정은 컨텍스트(context) 트리입니다: main → events, http → server → location(또는 upstream 등).

  • 상속: http 블록의 gzip on은 하위 server에 기본 적용됩니다. 하위에서 다시 지정하면 해당 블록에서 덮어씁니다.
  • include: 파일을 분할해 포함합니다. 스니펫을 재사용할 때 실제 병합 결과는 한 덩어리의 설정 트리로 해석됩니다.
  • location 매칭 순서: 정확 일치 = → 가장 긴 접두사 → ^~가 있으면 정규식 생략 → 순서대로 정규식 ~ / ~*. 복잡한 if 남용은 디버깅을 어렵게 하므로, 가능하면 map과 분기 location으로 푸는 편이 안전합니다.
  • default_server: 같은 listen에 여러 server_name이 있을 때 기본으로 택할 가상 호스트를 지정합니다.

이해가 부족하면 “상위에서 켠 옵션이 하위에 어떻게 남는지” 추적이 어려워지므로, 테스트 도구(nginx -t)와 단계적 include가 중요합니다.

사례: 기본 라운드 로빈이 만든 장애

한 팀에서 API 클러스터 세 대를 기본 upstream 설정(라운드 로빈)으로 운영하던 중 발생한 장애 사례입니다. 배포 직후 노드 한 대가 콜드 스타트와 가비지 컬렉션의 영향으로 응답이 느려졌지만, 트래픽은 여전히 세 노드에 균등하게 분배되고 있었습니다. 그 결과 사용자 입장에서는 요청 세 건 중 한 건꼴로 무작위로 느려지는 현상이 나타났습니다. 모니터링 대시보드에는 평균 응답 시간은 정상인데 p95·p99 지표만 이상하게 튀는 형태로만 보였기 때문에, 초기에는 데이터베이스나 네트워크 구간을 먼저 의심하게 되었습니다.

원인을 파악한 뒤 least_conn으로 알고리즘을 변경하고, max_fails와 fail_timeout으로 응답이 없는 노드를 자동으로 제외하도록 설정하자 그래프가 정상 궤도로 돌아왔습니다. “기본값이 라운드 로빈이니 그대로 사용해도 된다”는 판단이 장애 대응 시간을 길어지게 만든 핵심 원인이었습니다. (같은 팀에서 ip_hash만 사용해 세션을 각 서버 로컬 메모리에 유지했던 케이스에서도 유사한 문제가 발생한 적이 있습니다. 클라이언트의 공인 IP가 NAT 환경에서 바뀌는 순간 로그인이 풀리는 문의가 몰렸습니다.)

이 사례가 보여주는 결론은 분명합니다. 라운드 로빈만 사용하는 구성은 지양해야 합니다. 라운드 로빈은 “모든 백엔드가 동일하게 건강하고, 요청마다 처리 비용이 비슷하다”는 가정이 성립할 때만 잘 동작합니다. 실제 서비스 환경에서는 이 가정이 깨지는 순간이 반드시 찾아옵니다.

로드 밸런싱 알고리즘 심화

upstream에서 어떤 알고리즘을 선택하느냐는 단순히 트래픽을 나누는 문제가 아니라, 실제 부하를 어떻게 분산할 것인가의 문제입니다. 주요 알고리즘의 특성은 다음과 같습니다.

  • 기본값(라운드 로빈): 요청을 순서대로 돌아가며 분배하는 방식입니다. “균등 분배”가 아니라 “순차 분배”에 가까우며, 백엔드 간 스펙·지연 시간·큐 길이가 다르더라도 느린 노드에 동일한 비중으로 요청을 전달합니다.
  • least_conn: 현재 연결된 커넥션 수가 가장 적은 노드로 요청을 보냅니다. 응답 시간 편차가 크거나 웹소켓·스트리밍처럼 연결이 오래 유지되는 경우 라운드 로빈보다 효과적인 경우가 많습니다. 상태를 갖지 않는(stateless) HTTP API에서도 우선적으로 검토할 만한 알고리즘입니다.
  • ip_hash: 클라이언트 IP를 기준으로 백엔드를 고정합니다. 세션 정보가 애플리케이션 메모리에 저장된 레거시 시스템에서 임시방편으로 사용되는 경우가 많습니다. 모바일 통신사망이나 회사 NAT 환경에서는 클라이언트 IP가 자주 바뀔 수 있으므로, 가능하면 세션을 Redis 등 외부 저장소로 분리하는 편이 더 안정적입니다.
  • hash ... consistent: 특정 키(예: 요청 URI)를 기준으로 샤딩할 때 사용합니다. 캐시 노드 앞단에 배치할 경우, 노드 수가 변경되어도 재배치되는 키의 비율을 최소화할 수 있어 일반 해시보다 유리합니다.
  • random two + least_conn(Nginx 1.15 이상): 무작위로 두 노드를 후보로 선택한 뒤, 그중 연결 수가 적은 쪽으로 요청을 보냅니다. 트래픽이 급격히 변동하는 환경에서 분산 효과가 좋다는 사례가 보고되지만, 실무에서는 least_conn 단독 구성이 더 널리 쓰입니다.

weight, down, backup, max_fails/fail_timeout 등의 옵션은 설정보다는 운영에 가까운 요소입니다. 오픈소스 Nginx만으로는 능동적 헬스 체크(active health check) 기능이 제한적이므로, 이를 보완하기 위해 Nginx Plus나 클라우드 로드 밸런서, 서비스 메시를 함께 도입하는 경우가 많습니다.

upstream api {
    least_conn;
    server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:8080 backup;
}

upstream cache_nodes {
    hash $request_uri consistent;
    server 10.0.0.10:11211;
    server 10.0.0.11:11211;
}

프로덕션 Nginx 패턴

  • TLS 종료 + 업스트림 keepalive: 클라이언트와는 HTTPS, 내부는 HTTP로 두되 업스트림 커넥션 풀(proxy_http_version 1.1, proxy_set_header Connection "", keepalive 지시문 in upstream)으로 백엔드의 TCP/TLS 부담을 줄입니다.
  • proxy_next_upstream: 특정 오류·타임아웃 시 다른 업스트림으로 재시도할지 정합니다. 중복 전송이 위험한 메서드(비멱등 POST 등)는 non_idempotent와 함께 신중히 설정합니다.
  • 레이트 리밋: limit_req_zone / limit_req로 API 남용을 막으며, limit_conn으로 동일 IP·키의 동시 커넥션을 제한합니다.
  • 관측 가능성: stub_status on(모듈 포함 빌드 시) 또는 exporter, 구조화된 액세스 로그(log_format json 등)로 지연·캐시 히트율을 추적합니다.
  • 배포: nginx -t로 문법 검증 후 reload. 설정 드리프트를 막으려면 Git으로 관리하고 IaC와 연동하는 것이 좋습니다.

아래 실습 절(로드 밸런싱, SSL, 캐싱)의 예제는 이 절의 개념을 구체 설정으로 옮긴 것으로 보면 됩니다.

3. 설치

Ubuntu

sudo apt update
sudo apt install nginx
# 시작
sudo systemctl start nginx
# 부팅 시 자동 시작
sudo systemctl enable nginx
# 상태 확인
sudo systemctl status nginx

Docker

docker run -d -p 80:80 nginx:latest

4. 기본 설정

nginx.conf

# /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
    worker_connections 1024;
}
http {
    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"';
    access_log /var/log/nginx/access.log main;
    sendfile on;
    tcp_nopush on;
    keepalive_timeout 65;
    gzip on;
    include /etc/nginx/conf.d/*.conf;
}

5. 정적 파일 서빙

# /etc/nginx/conf.d/default.conf
server {
    listen 80;
    server_name example.com;
    root /var/www/html;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

6. 리버스 프록시

기본 설정

server {
    listen 80;
    server_name api.example.com;
    location / {
        proxy_pass http://localhost:8000;
        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;
    }
}

WebSocket

location /ws {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

7. 로드 밸런싱

앞선 2절에서 라운드 로빈만 사용하는 구성이 왜 위험한지 실제 장애 사례로 살펴보았습니다. 이번 절에서는 각 방식의 설정 문법을 정리합니다. 설정을 복사해 사용할 때 upstream의 기본값이 라운드 로빈이라는 점을 잊지 말고, 최소한 max_fails와 fail_timeout은 함께 설정하는 것을 권장합니다. 설정을 반영하기 전에는 반드시 nginx -t로 문법을 검증해야 합니다.

Round Robin (기본값)

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}
server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

Least Connections

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

IP Hash (세션 유지)

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

가중치

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

일관성 해시 (hash + consistent)

노드가 늘거나 줄어도 키 재배치를 상대적으로 줄이고 싶을 때(캐시 샤딩 등) 사용합니다.

upstream shard {
    hash $request_uri consistent;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

random two (Open Source 1.15+)

무작위로 두 백엔드를 고른 뒤, 그중 부하가 적은 쪽으로 보내는 방식입니다.

upstream backend {
    random two least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

8. SSL/TLS

Let’s Encrypt

# Certbot 설치
sudo apt install certbot python3-certbot-nginx
# 인증서 발급
sudo certbot --nginx -d example.com -d www.example.com
# 자동 갱신
sudo certbot renew --dry-run

SSL 설정

server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    location / {
        proxy_pass http://localhost:8000;
    }
}
# HTTP → HTTPS 리다이렉트
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

9. 캐싱

Proxy Cache

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;
server {
    location / {
        proxy_cache my_cache;
        proxy_cache_valid 200 60m;
        proxy_cache_valid 404 1m;
        proxy_cache_bypass $http_cache_control;
        add_header X-Cache-Status $upstream_cache_status;
        proxy_pass http://backend;
    }
}

10. 성능 최적화

Gzip 압축

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml text/javascript 
           application/json application/javascript application/xml+rss;

연결 최적화

# Worker 프로세스 수
worker_processes auto;
# 연결 수
events {
    worker_connections 2048;
    use epoll;
}
# Keepalive
keepalive_timeout 65;
keepalive_requests 100;

업스트림 Keepalive (백엔드 커넥션 풀)

리버스 프록시에서 백엔드로 매 요청마다 새 TCP 연결을 열면 지연과 포트 고갈이 커집니다. HTTP/1.1 업스트림 풀을 쓰려면 upstream에 keepalive를 두며, proxy 쪽에서 Connection 헤더를 비웁니다.

upstream api {
    server 127.0.0.1:8080;
    keepalive 64;
}
server {
    location / {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://api;
    }
}

버퍼 크기

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;

11. 실전 예제: 풀스택 앱

React 프론트엔드와 여러 대의 백엔드 인스턴스를 함께 운영하는 실제 서비스 구성 예제입니다. HTTP 요청을 HTTPS로 강제 리다이렉트하고, 경로별로 프론트엔드·API·정적 파일을 각각 다른 업스트림과 위치로 라우팅합니다.

# /etc/nginx/conf.d/app.conf
upstream frontend {
    server localhost:3000;
}
upstream backend {
    server localhost:8000;
    server localhost:8001;
    server localhost:8002;
}
# HTTP → HTTPS
server {
    listen 80;
    server_name myapp.com www.myapp.com;
    return 301 https://$server_name$request_uri;
}
# HTTPS
server {
    listen 443 ssl http2;
    server_name myapp.com www.myapp.com;
    ssl_certificate /etc/letsencrypt/live/myapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.com/privkey.pem;
    # Frontend (React)
    location / {
        proxy_pass http://frontend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
    # Backend API
    location /api {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        
        # CORS
        add_header Access-Control-Allow-Origin *;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
    }
    # 정적 파일
    location /static {
        alias /var/www/static;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

취업·면접과 연결하기

리버스 프록시·SSL·캐싱을 운영 경험으로 말로 풀 수 있게 정리해 두면 인프라·백엔드 면접에서 유리합니다. 기술 면접 완벽 대비 가이드의 CS·시스템 질문 흐름과, 이력서에 어떻게 쓸지는 개발자 이력서·서류·면접 가이드를 참고하세요.

정리 및 체크리스트

핵심 요약

  • Nginx: 고성능 웹 서버
  • 리버스 프록시: 백엔드 앞단
  • 로드 밸런싱: 트래픽 분산
  • SSL/TLS: HTTPS 지원
  • 캐싱: 응답 캐싱
  • 성능: 10,000+ 동시 접속

프로덕션 체크리스트

  • Nginx 설치
  • 리버스 프록시 설정
  • 로드 밸런싱 구성
  • SSL 인증서 발급
  • 캐싱 설정
  • 성능 최적화
  • 모니터링 설정

같이 보면 좋은 글

이 글에서 다루는 키워드

Nginx, Web Server, Reverse Proxy, Load Balancing, SSL, Performance, DevOps

자주 묻는 질문 (FAQ)

Q. upstream 기본값이 라운드 로빈인데, 그대로 두어도 되나요?

A. 동작은 하지만 권장하지 않습니다. 모든 백엔드가 동일하게 건강하다는 보장이 없는 이상, 기본값은 느려진 노드에도 다른 노드와 동일한 비중으로 요청을 전달합니다. 그 결과 일부 사용자만 무작위로 느린 응답을 받는 상황이 발생할 수 있습니다. least_conn, weight, max_fails와 같은 옵션을 함께 검토하는 것이 안전합니다.

Q. Nginx vs Apache, 어떤 게 나은가요?

A. Nginx가 더 빠르고 메모리 효율적입니다. 대부분의 경우 Nginx를 권장합니다.

Q. 동적 콘텐츠도 처리할 수 있나요?

A. Nginx는 정적 파일에 최적화되어 있습니다. 동적 콘텐츠는 백엔드 서버로 프록시하세요.

Q. 무료인가요?

A. 네, Nginx는 오픈소스이며 무료입니다. Nginx Plus는 유료 엔터프라이즈 버전입니다.

Q. 프로덕션에서 사용해도 되나요?

A. 네, Netflix, Airbnb, NASA 등 많은 기업에서 사용합니다.

Q. Nginx가 이벤트 기반이라는 말은 무슨 뜻인가요?

A. 워커가 요청마다 스레드를 붙이기보다, epoll/kqueue로 “준비된 소켓”만 처리하는 이벤트 루프 모델을 쓴다는 뜻입니다. 동시 접속이 많을 때 컨텍스트 스위칭과 메모리 부담을 줄이는 데 유리합니다.

Q. reload 전에 nginx -t를 쓰는 이유는?

A. 설정 문법 오류를 적용 전에 검사합니다. 잘못된 설정을 올리면 워커 기동 실패나 예상치 못한 기본값 적용으로 장애로 이어질 수 있으므로, 테스트 후 배포하는 습관이 중요합니다.