Nginx 속도 향상: 필수 버퍼, 압축 및 캐싱 팁

Nginx는 기본적으로 빠르지만, 기본 설정은 의도적으로 보수적입니다. 소규모 사이트, 테스트 서버 또는 트래픽이 적은 리버스 프록시에 적합합니다. 대용량 쿠키, 느린 업스트림, 큰 API 응답 또는 시간당 수천 번 다운로드되는 정적 자산을 처리하기 시작하면 항상 최적의 선택은 아닙니다.

유용한 튜닝은 일반적으로 버퍼, 압축 및 캐싱의 세 가지 영역으로 요약됩니다. 버퍼는 Nginx가 요청 및 응답 데이터를 메모리에 보관할지 아니면 임시 파일로 스필할지 결정합니다. 압축은 네트워크를 통해 전송할 텍스트 기반 데이터의 양을 결정합니다. 캐싱은 Nginx와 브라우저가 동일한 작업을 반복하지 않도록 할지 결정합니다. 이러한 설정 중 어느 것도 마법이 아닙니다. 잘못된 캐시 규칙은 개인 콘텐츠를 유출할 수 있으며, 과도하게 큰 버퍼는 메모리를 낭비할 수 있습니다. 목표는 의도적으로 튜닝하고, 실제 트래픽 패턴으로 테스트하며, 다음 사람이 이해할 수 있도록 구성을 읽기 쉽게 유지하는 것입니다.

효율적인 데이터 처리를 위한 Nginx 버퍼 최적화

Nginx는 요청 및 응답 처리 중에 데이터를 임시로 저장하기 위해 다양한 버퍼를 사용합니다. 이러한 버퍼의 크기를 적절하게 조정하는 것은 성능에 매우 중요합니다. 잘못된 크기의 버퍼는 과도한 메모리 소비 또는 빈번한 디스크 쓰기(스풀링)로 이어져 성능을 저하시킬 수 있습니다. 클라이언트 관련 버퍼와 프록시/FastCGI 버퍼를 살펴보겠습니다.

클라이언트 관련 버퍼

이러한 버퍼는 클라이언트에서 Nginx로 들어오는 데이터를 관리합니다.

• client_body_buffer_size: 이 지시문은 클라이언트 요청 본문을 읽기 위한 버퍼 크기를 설정합니다. 요청 본문이 이 크기를 초과하면 디스크의 임시 파일에 기록됩니다. 이는 대용량 업로드 시 메모리 고갈을 방지하지만, 빈번한 디스크 쓰기는 성능을 저하시킬 수 있습니다.

  • 팁: POST 요청을 통해 매우 큰 파일 업로드를 처리하지 않는 일반적인 웹 애플리케이션의 경우 8k 또는 16k면 충분합니다. Nginx를 통해 더 큰 양식이나 작은 파일 업로드를 직접 처리하는 경우 늘리십시오.

  http {
      client_body_buffer_size 16k;
      # ...
  }
  

• client_header_buffer_size: 클라이언트 요청 헤더를 읽기 위한 버퍼 크기를 정의합니다. 각 연결에 대해 단일 버퍼가 할당됩니다.

  • 팁: 1k가 기본값이며 대부분의 헤더에 충분합니다. 종종 많은 쿠키나 복잡한 인증 헤더로 인해 "client sent too large header" 오류가 발생하는 경우에만 늘리십시오.

  http {
      client_header_buffer_size 1k;
      # ...
  }
  

• large_client_header_buffers: 이 지시문은 큰 클라이언트 요청 헤더를 읽는 데 사용되는 버퍼의 최대 개수와 크기를 설정합니다. 헤더가 client_header_buffer_size를 초과하면 Nginx는 이 지시문을 사용하여 버퍼를 할당하려고 시도합니다.

  • 팁: 4 8k (각각 8KB인 4개의 버퍼)가 일반적인 설정입니다. client_header_buffer_size를 늘린 후에도 헤더 오류가 지속적으로 발생하면 조정하십시오.

  http {
      large_client_header_buffers 4 8k;
      # ...
  }
  

프록시 및 FastCGI 버퍼

이러한 버퍼는 Nginx가 리버스 프록시 역할을 하거나 FastCGI 백엔드(PHP-FPM 등)와 통신할 때 데이터를 관리합니다.

Nginx가 요청을 프록시할 때 백엔드 서버로부터 응답을 청크 단위로 수신하여 클라이언트로 보내기 전에 버퍼링합니다. 이를 통해 Nginx는 클라이언트 연결을 차단하지 않고 느린 백엔드 응답을 처리할 수 있습니다.

• proxy_buffer_size: 프록시된 서버로부터 수신된 응답의 첫 번째 부분에 대한 버퍼 크기입니다. 일반적으로 응답 헤더를 포함합니다.

• proxy_buffers: 프록시된 서버로부터 응답을 읽는 데 사용되는 버퍼의 개수와 크기를 정의합니다.

• proxy_busy_buffers_size: 한 번에 활성화(사용 중)될 수 있는 버퍼의 최대 크기를 설정합니다. 이는 클라이언트로 데이터를 보내거나 백엔드에서 읽는 중일 수 있습니다. 이는 Nginx가 버퍼를 너무 오래 보유하여 과도한 메모리를 소비하는 것을 방지합니다.

  • 프록시 패스 예시: 일반적인 웹 애플리케이션의 경우 proxy_buffer_size는 예상 헤더 크기와 일치할 수 있으며, proxy_buffers는 디스크에 쓰지 않고 평균 콘텐츠 크기를 처리하도록 설정할 수 있습니다.

  http {
      proxy_buffer_size          128k;
      proxy_buffers              4 256k; # 4개의 버퍼, 각각 256KB
      proxy_busy_buffers_size    256k;
      # ...
  }
  

• fastcgi_buffer_size, fastcgi_buffers, fastcgi_busy_buffers_size: 이러한 지시문은 proxy_ 대응 항목과 동일하게 기능하지만 FastCGI 서버의 응답에 특별히 적용됩니다.

  • FastCGI 예시: 유사한 논리가 적용되며, PHP/FastCGI 애플리케이션의 응답 크기에 맞게 조정하십시오.

  http {
      fastcgi_buffer_size        128k;
      fastcgi_buffers            4 256k;
      fastcgi_busy_buffers_size  256k;
      # ...
  }
  

경고: 버퍼를 너무 크게 설정하면 연결당 더 많은 RAM을 소비하여 사용량이 많은 서버에서 메모리가 빠르게 고갈될 수 있습니다. 너무 작게 설정하면 Nginx가 임시 파일을 디스크에 쓰게 되어 I/O 오버헤드가 발생합니다. 최적의 균형을 찾으려면 서버의 메모리와 디스크 I/O를 모니터링하십시오.

Gzip을 사용한 효과적인 압축 활성화

주로 Gzip을 사용하는 콘텐츠 압축은 전송되는 데이터의 크기를 크게 줄여 페이지 로드 속도를 높이고 대역폭 소비를 줄일 수 있습니다. Nginx의 gzip 모듈은 매우 구성 가능합니다.

필수 Gzip 지시문

이러한 지시문을 http 블록 또는 특정 server 또는 location 블록 내에 추가하십시오.

• gzip on;: Gzip 압축을 활성화합니다.

• gzip_types: 압축해야 하는 MIME 유형을 지정합니다. 특정 텍스트 기반 유형만 압축으로부터 큰 이점을 얻습니다.

  • 모범 사례: 일반적인 웹 유형을 포함하지만 이미지(image/*), 비디오(video/*) 및 이미 압축된 파일(.zip, .rar, .gz)은 압축하지 마십시오. 이는 이득 없이 CPU 주기를 낭비하기 때문입니다.

  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;
  

• gzip_proxied: 응답 및 요청 조건에 따라 프록시된 요청에 대한 압축을 활성화합니다. Nginx가 애플리케이션 서버 또는 다른 프록시 앞에 있을 때 주로 유용합니다.

  • any: 그렇지 않으면 자격이 되는 프록시된 응답을 압축합니다.
  • no-cache, no-store, private, expired, auth: 응답 또는 요청이 해당 조건과 일치하는 경우에만 압축합니다. 이러한 토큰은 "압축하지 않음" 플래그가 아닙니다. 이는 프록시된 응답에 대한 압축을 허용하는 조건입니다.

  gzip_proxied any;
  

• gzip_min_length: Nginx가 압축할 응답 본문의 최소 길이를 설정합니다. 작은 파일은 압축으로부터 큰 이점을 얻지 못하며 압축 오버헤드로 인해 오히려 커질 수 있습니다.

  • 팁: 1000바이트(1KB) 또는 256바이트와 같은 값이 좋은 시작점입니다.

  gzip_min_length 1000;
  

• gzip_comp_level: 압축 수준(1-9)을 설정합니다. 높은 수준은 더 나은 압축을 제공하지만 더 많은 CPU 리소스를 소비합니다. 낮은 수준은 더 빠르지만 압축 효율성이 떨어집니다.

  • 팁: 대부분의 서버에서 압축률과 CPU 사용량 사이의 좋은 균형은 4-6입니다.

  gzip_comp_level 5;
  

• gzip_vary on;: 클라이언트가 보낸 Accept-Encoding 헤더에 따라 프록시가 압축된 버전과 압축되지 않은 버전의 파일을 모두 캐시하도록 지시합니다. 이는 적절한 캐싱 및 전달에 중요합니다.

  gzip_vary on;
  

• gzip_disable: Gzip에 문제가 있을 수 있는 특정 브라우저 또는 사용자 에이전트에 대한 압축을 비활성화합니다.

  gzip_disable "MSIE [1-6]\."; # 예: 오래된 Internet Explorer에 대해 비활성화
  

고려 사항: Gzip은 매우 유용하지만 압축은 CPU 주기를 소비합니다. 디스크에서 직접 제공되는 정적 파일(예: 사전 압축된 .gz 파일)의 경우 Nginx는 재압축 없이 직접 제공할 수 있어 훨씬 더 효율적입니다. 동적 콘텐츠의 경우 Gzip은 일반적으로 순이득입니다.

스마트 캐싱 전략 구현

캐싱은 콘텐츠를 재생성하거나 다시 가져올 필요성을 줄여 웹 서버 성능을 향상시키는 가장 효과적인 방법입니다. Nginx는 브라우저 측(클라이언트 측) 및 서버 측(프록시) 캐싱을 모두 지원합니다.

브라우저 캐싱(HTTP 헤더)

브라우저 캐싱은 HTTP 헤더를 사용하여 클라이언트 브라우저에 정적 자산을 저장할 기간을 지시합니다. 이는 이미지, CSS 및 JavaScript 파일과 같이 변경되지 않는 리소스의 반복적인 다운로드를 방지합니다.

• expires: Expires 및 Cache-Control: max-age 헤더를 설정하는 간단한 지시문입니다.

  location ~* \.(jpg|jpeg|gif|png|webp|ico|css|js|woff|woff2|ttf|otf|eot)$ {
      expires 365d; # 1년 동안 캐시
      add_header Cache-Control "public, no-transform";
      # 선택 사항: 정적 파일에 대한 로그 비활성화
      access_log off;
      log_not_found off;
  }
  

• add_header Cache-Control: 캐싱 정책을 보다 세밀하게 제어할 수 있습니다. 일반적인 값은 다음과 같습니다.

  • public: 모든 캐시(브라우저, 프록시)에서 캐시 가능합니다.
  • private: 클라이언트의 개인 캐시(예: 브라우저)에서만 캐시 가능합니다.
  • no-cache: 사용하기 전에 서버에서 재검증해야 하지만 복사본을 저장할 수 있습니다.
  • no-store: 전혀 캐시하지 마십시오.
  • max-age=<seconds>: 리소스가 최신 상태로 간주되는 기간을 지정합니다.

• 조건부 요청(Etag 및 If-Modified-Since): Nginx는 정적 파일에 대해 Etag 및 Last-Modified 헤더를 자동으로 처리하여 브라우저가 조건부 요청(If-None-Match 또는 If-Modified-Since)을 보낼 수 있도록 합니다. 콘텐츠가 변경되지 않은 경우 Nginx는 304 Not Modified로 응답하여 대역폭을 절약합니다.

Nginx 프록시 캐싱

Nginx는 강력한 캐싱 리버스 프록시 역할을 할 수 있습니다. 활성화되면 Nginx는 백엔드 서버의 응답 복사본을 저장하고 클라이언트에 직접 제공하여 백엔드의 부하를 크게 줄입니다.

1. 캐시 영역 정의

이는 http 블록에서 수행해야 합니다. proxy_cache_path는 캐시 디렉토리, 메모리 영역 매개변수 및 기타 설정을 정의합니다.

http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;
    # levels=1:2: 캐시 파일에 대한 2단계 디렉토리 계층 구조를 생성합니다(예: /var/cache/nginx/c/29/...). 파일을 분산하는 데 도움이 됩니다.
    # keys_zone=my_cache:10m: 캐시 키와 메타데이터를 저장하기 위해 'my_cache'라는 10MB 공유 메모리 영역을 정의합니다. 이는 빠른 조회에 중요합니다.
    # inactive=60m: 60분 동안 액세스되지 않은 캐시 항목은 디스크에서 제거됩니다.
    # max_size=1g: 디스크의 캐시 최대 크기를 설정합니다. 초과하면 Nginx는 가장 최근에 사용되지 않은 데이터를 제거합니다.
    # ...
}

2. 위치에 대한 캐싱 활성화

server 또는 location 블록 내에서 캐시를 활성화하고 동작을 정의합니다.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_upstream; # 또는 http://127.0.0.1:8000;
        proxy_cache my_cache; # 위에서 정의한 캐시 영역 사용
        proxy_cache_valid 200 302 10m; # 성공적인 응답(200, 302)을 10분 동안 캐시
        proxy_cache_valid 404 1m;      # 404 응답을 1분 동안 캐시
        proxy_cache_revalidate on;     # 재검증을 위해 If-Modified-Since 및 If-None-Match 헤더 사용
        proxy_cache_min_uses 1;       # 항목이 한 번 이상 요청된 경우에만 캐시
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
                                       # 백엔드가 다운되었거나 업데이트 중인 경우 오래된 콘텐츠 제공

        # 응답이 캐시되었는지 확인하는 헤더 추가
        add_header X-Cache-Status $upstream_cache_status;

        # 선택 사항: 특정 조건에 대해 캐시 우회
        # proxy_cache_bypass $http_pragma $http_authorization;
        # proxy_no_cache $http_pragma $http_authorization;
    }
}

중요한 캐시 지시문

• proxy_cache_valid: HTTP 상태 코드 및 기간에 따라 캐싱 규칙을 정의합니다. 여러 규칙을 지정할 수 있습니다.

• proxy_cache_revalidate on;: Nginx가 캐시된 콘텐츠가 여전히 최신 상태인지 확인할 때 If-Modified-Since 및 If-None-Match 헤더를 사용할 수 있도록 합니다. 이는 단순히 캐시를 만료시키는 것보다 더 효율적입니다.

• proxy_cache_use_stale: 백엔드를 사용할 수 없거나 느린 경우 Nginx가 캐시에서 오래된(만료된) 콘텐츠를 제공하도록 지시하는 강력한 지시문입니다. 이는 백엔드 문제 발생 시 사용자 경험을 크게 향상시킵니다.

• proxy_cache_bypass / proxy_no_cache: 이를 사용하여 캐시를 우회해야 하는 조건(예: 인증된 요청 또는 특정 쿼리 매개변수)을 정의합니다.

  # 특정 쿼리 매개변수 또는 쿠키가 있는 요청을 캐시하지 않는 예
  # if ($request_uri ~* "(\?|&)nocache") { set $no_cache 1; }
  # if ($http_cookie ~* "SESSIONID") { set $no_cache 1; }
  # proxy_cache_bypass $no_cache;
  # proxy_no_cache $no_cache;
  

캐시 지우기

Nginx 캐시를 수동으로 지우려면 proxy_cache_path 디렉토리의 파일을 간단히 삭제하면 됩니다. 보다 통제된 무효화를 위해 ngx_cache_purge와 같은 모듈을 사용하거나 캐시 무효화 요청을 처리하도록 특정 location을 구성하는 것을 고려하십시오.

경고: 잘못 구성된 프록시 캐싱은 사용자가 오래된 콘텐츠를 보게 될 수 있습니다. 프로덕션에 배포하기 전에 항상 스테이징 환경에서 캐싱 전략을 철저히 테스트하십시오. 자주 변경되거나 사용자별로 다른 동적 콘텐츠가 적극적으로 캐시되지 않도록 하십시오.

실용적인 롤아웃 계획

Nginx를 튜닝하는 가장 안전한 방법은 한 번에 하나의 레이어를 변경하는 것입니다. 헤더와 정적 자산부터 시작하십시오. 위험이 낮고 이점을 쉽게 확인할 수 있기 때문입니다. 버전이 지정된 파일(예: /app.8f3a2c.js 또는 /styles.2025-11-02.css)에 대해서만 긴 브라우저 캐시 수명을 추가하십시오. 파일이 변경될 때 자산 이름이 변경되지 않으면 1년 동안 캐시하지 마십시오. 더 짧은 expires 값을 사용하거나 먼저 빌드 파이프라인을 수정하십시오.

다음으로 텍스트 형식에 대해 Gzip을 활성화하고 제대로 작동하는지 확인하십시오.

curl -I -H 'Accept-Encoding: gzip' https://example.com/app.js

압축 가능한 응답에 대해 Content-Encoding: gzip이 표시되고 Vary: Accept-Encoding이 표시되어야 합니다. 이미지 또는 ZIP 파일이 압축된 것으로 표시되면 gzip_types를 강화하십시오. 해당 형식은 이미 압축되어 있으며 일반적으로 CPU를 낭비합니다.

그런 다음 버퍼링을 살펴보십시오. 업스트림 응답이 임시 파일로 버퍼링되고 있다는 메시지가 오류 로그에 있는지 확인하십시오. 이러한 메시지가 자동으로 재앙인 것은 아니지만 Nginx가 응답 데이터를 디스크에 쓰고 있음을 알려줍니다. 정상적인 페이지 로드 또는 API 응답 중에 발생하는 경우 프록시 버퍼가 워크로드에 비해 너무 작을 수 있습니다. 대용량 내보내기 또는 다운로드에 대해서만 발생하는 경우 모든 요청 경로에 대해 큰 버퍼를 할당하는 것보다 디스크 스풀링을 수용하는 것이 더 나을 수 있습니다.

프록시 캐싱은 마지막에 와야 합니다. 가장 큰 장점과 가장 쉬운 실패 모드가 있습니다. 명백히 안전한 콘텐츠(공개 문서 페이지, 익명 제품 카탈로그 페이지, 이미지 변환 응답, 패키지 메타데이터 또는 모든 방문자에게 동일한 API 응답)부터 시작하십시오. 애플리케이션이 명시적으로 설계되지 않은 한 세션 쿠키, Authorization 헤더, 장바구니, 사용자 대시보드, 관리자 페이지 또는 개인화된 추천과 관련된 모든 것을 캐시하지 마십시오.

다음은 자주 볼 수 있는 짧은 예보다 더 신중한 캐시 우회 패턴입니다.

map $http_authorization $skip_cache_auth {
    default 1;
    ""      0;
}

map $http_cookie $skip_cache_cookie {
    default 0;
    ~*"(session|sid|auth|token)" 1;
}

server {
    location / {
        proxy_pass http://backend_upstream;
        proxy_cache my_cache;
        proxy_cache_valid 200 10m;
        proxy_cache_bypass $skip_cache_auth $skip_cache_cookie;
        proxy_no_cache $skip_cache_auth $skip_cache_cookie;
        add_header X-Cache-Status $upstream_cache_status always;
    }
}

그래도 애플리케이션과 일치해야 하지만 중요한 아이디어를 명확하게 합니다. 인증된 요청 및 세션처럼 보이는 요청은 공유 캐시에 자동으로 들어가지 않아야 합니다.

변경 후 확인할 사항

단일 벤치마크로만 Nginx 튜닝을 판단하지 마십시오. 몇 번의 정상적인 트래픽 주기 동안 서버를 관찰하십시오. 유용한 신호로는 /var/lib/nginx 또는 /var/cache/nginx 아래의 디스크 쓰기, 업스트림 응답 시간, 캐시 적중률, 압축 활성화 후 CPU 사용량, 499/502/504 오류 및 작업자당 메모리 사용량이 있습니다. Gzip 후 CPU가 증가했지만 대역폭이 거의 변하지 않은 경우 gzip_comp_level을 낮추거나 MIME 유형을 제한하십시오. 캐시 적중률이 낮은 경우 쿠키, 쿼리 문자열 또는 애플리케이션의 응답 헤더로 인해 캐시가 우회될 수 있습니다.

또한 장애 동작을 테스트하십시오. 스테이징에서 업스트림을 중지하거나 느리게 하고 proxy_cache_use_stale이 예상대로 작동하는지 확인하십시오. 짧은 백엔드 중단 중에 오래된 공개 페이지는 괜찮을 수 있습니다. 오래된 계정 잔액, 송장 또는 관리자 페이지는 그렇지 않습니다.

최종 참고 사항

좋은 Nginx 성능 작업은 대부분 신중한 하우스키핑입니다. 불필요한 디스크 I/O를 피할 수 있을 만큼 충분히 크지만 모든 사용량이 많은 작업자가 비싸지지 않을 만큼 크지 않은 버퍼를 사용하십시오. 이미 압축된 자산이 아닌 텍스트를 압축하십시오. 먼저 공개적이고 반복 가능한 응답을 캐시하고 개인 콘텐츠가 명확하게 옵트아웃되도록 하십시오. 그런 다음 계속 측정하십시오. 소규모 PHP 앱, 정적 문서 사이트 및 사용량이 많은 API 게이트웨이에 대한 올바른 설정은 동일하지 않기 때문입니다.