DevOps 지식 허브
DevOps 지식 허브

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

버퍼 최적화, Gzip 압축 및 스마트 캐싱 전략에 대한 필수 가이드를 통해 최고의 Nginx 성능을 잠금 해제하세요. 효율적인 데이터 처리를 위한 클라이언트 및 프록시 버퍼 구성 방법, 대역폭 절감을 위한 강력한 콘텐츠 압축 구현 방법, 그리고 번개처럼 빠른 응답 시간을 위한 브라우저 및 Nginx 프록시 캐싱 활용 방법을 알아보세요. 실제적인 Nginx 구성 예제와 모범 사례로 가득 찬 이 문서는 웹 서버의 속도와 효율성을 크게 향상시킬 수 있는 실행 가능한 통찰력을 제공합니다.

34 조회수

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

Nginx는 웹 서버 및 리버스 프록시로서 성능과 효율성으로 유명합니다. 하지만 잠재력을 최대한 발휘하려면 세심한 튜닝과 최적화가 필수적입니다. 기본적인 설정으로 시작할 수는 있지만, 버퍼 관리, 콘텐츠 압축 및 지능적인 캐싱 전략과 관련된 고급 기술은 서버 응답 시간을 극적으로 개선하고, 대역폭 사용량을 줄이며, 사용자에게 더 빠른 경험을 제공할 수 있습니다.

이 문서는 이러한 중요한 성능 최적화 영역을 깊이 파고듭니다. Nginx 버퍼를 효과적으로 구성하여 클라이언트 요청 및 백엔드 응답을 처리하는 방법, 콘텐츠를 더 빠르게 제공하기 위해 강력한 Gzip 압축을 구현하는 방법, 그리고 불필요한 데이터 전송 및 처리를 최소화하기 위해 브라우저 측 및 Nginx 측 캐싱을 활용하는 방법을 살펴보겠습니다. 이 글을 마치면 Nginx 서버의 속도와 효율성을 크게 향상시킬 수 있는 실행 가능한 통찰력과 실용적인 구성을 얻게 될 것입니다.

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

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

클라이언트 관련 버퍼

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

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

    • 팁: POST 요청을 통해 매우 큰 파일 업로드를 처리하지 않는 일반적인 웹 애플리케이션의 경우 8k 또는 16k로도 충분한 경우가 많습니다. Nginx를 통해 더 큰 폼이나 소규모 파일 업로드를 처리하는 경우 크기를 늘리십시오.

    nginx http { client_body_buffer_size 16k; # ... }

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

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

    nginx http { client_header_buffer_size 1k; # ... }

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

    • 팁: 4 8k(각각 8KB 크기의 버퍼 4개)는 일반적인 설정입니다. client_header_buffer_size를 늘린 후에도 계속해서 헤더 오류가 발생하는 경우 조정하십시오.

    nginx 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는 디스크에 쓰지 않고도 평균 콘텐츠 크기를 처리하도록 설정할 수 있습니다.

    nginx 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 애플리케이션의 응답 크기에 맞게 조정하십시오.

    nginx 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 유형을 지정합니다. 특정 텍스트 기반 유형만이 압축으로 인해 상당한 이점을 얻습니다.

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

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

  • gzip_proxied: Via 헤더를 기반으로 프록시된 요청에 대한 압축을 활성화합니다. 백엔드 서버에서 오는 응답이라도 Nginx가 압축하도록 지시합니다.

    • any: 모든 프록시된 요청에 대해 압축합니다.
    • no-cache, no-store, private: 일반적으로 Nginx가 캐시할 수 없도록 이미 표시된 응답을 압축하지 않도록 방지하는 데 사용됩니다.

    nginx gzip_proxied any;

  • gzip_min_length: Nginx가 압축할 응답 본문의 최소 길이를 설정합니다. 작은 파일은 압축으로 인한 이점이 거의 없으며 압축 오버헤드로 인해 파일 크기가 더 커질 수도 있습니다.

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

    nginx gzip_min_length 1000;

  • gzip_comp_level: 압축 수준(1-9)을 설정합니다. 수준이 높을수록 압축률은 좋지만 CPU 리소스를 더 많이 소비합니다. 수준이 낮으면 빠르지만 압축률이 떨어집니다.

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

    nginx gzip_comp_level 5;

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

    nginx gzip_vary on;

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

    nginx gzip_disable "MSIE [1-6]\."; # 예: 구형 Internet Explorer 비활성화

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

스마트 캐싱 전략 구현

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

브라우저 캐싱(HTTP 헤더)

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

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

    nginx 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: 인증된 요청이나 특정 쿼리 매개변수와 같은 조건에서 캐시를 우회해야 하는 경우 사용합니다.

    ```nginx

    특정 쿼리 매개변수나 쿠키가 포함된 요청은 캐시하지 않는 예시

    if ($request_uri ~* "(\?|&)nocache")

    if ($http_cookie ~* "SESSIONID")

    proxy_cache_bypass $no_cache;

    proxy_no_cache $no_cache;

    ```

캐시 지우기

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

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

결론

Nginx 성능 최적화에는 리소스 관리 및 콘텐츠 전달에 대한 전략적 접근 방식이 포함됩니다. 버퍼 크기를 신중하게 조정함으로써 Nginx가 불필요한 디스크 I/O나 메모리 오버헤드 없이 데이터 흐름을 효율적으로 처리하도록 보장합니다. 강력한 Gzip 압축을 구현하면 특히 텍스트 기반 자산의 대역폭을 크게 줄이고 콘텐츠 전송 속도를 높일 수 있습니다.

마지막으로, 브라우저 수준과 Nginx가 리버스 프록시 캐시 역할을 하는 두 가지 수준의 지능적인 캐싱은 백엔드 부하를 줄이고 최소한의 지연 시간으로 콘텐츠를 제공하는 데 매우 중요합니다. 이러한 기술들을 각각 신중하게 적용하면 사용자에게 더 반응성이 높고, 효율적이며, 확장 가능한 웹 서버 경험을 제공하는 데 기여합니다. 서버의 성능 메트릭을 지속적으로 모니터링하고 트래픽 패턴 및 애플리케이션 요구 사항이 발전함에 따라 이러한 설정을 조정하십시오.