NGINX Plus

NGINX 콘텐츠 캐싱

NGINX Plus 를 사용하여 Proxy된 웹 및 애플리케이션 서버에서 정적 콘텐츠와 동적 콘텐츠를 모두 캐싱하여 클라이언트로의 전송 속도를 높이고 서버의 부하를 줄입니다.

목차

1. 개요
2. 응답 캐싱 활성화 설정하기
3. 캐싱에 관련된 NGINX Plus 프로세스
4. 캐시할 요청 지정하기
5. 캐싱 제한 또는 비활성화
6. 캐시에서 콘텐츠 삭제
6-1. 캐시 Purge 구성
6-2. Purge 명령 보내기
6-3. Purge 명령에 대한 액세스 제한
6-4. 캐시에서 파일을 완전히 제거하기
6-5. 캐시 Purge 구성 예제
7. Byte 범위 캐싱
8. 결합 구성 예제

1. 개요

캐싱을 사용하도록 설정하면 NGINX Plus 는 디스크 캐시에 응답을 저장하여 매번 동일한 콘텐츠에 대한 요청을 Proxy할 필요 없이 캐시를 사용하여 클라이언트에 응답합니다.

2. 응답 캐싱 활성화 설정하기

캐싱을 사용하려면 최상위 http { } 컨텍스트에 proxy_cache_path 지시문을 포함하세요. 필수 첫 번째 매개변수는 캐시된 콘텐츠의 로컬 파일 시스템 경로이며, 필수 keys_zone 매개변수는 캐시된 항목에 대한 메타데이터를 저장하는 데 사용되는 공유 메모리 Zone의 이름과 크기를 정의합니다.

http {
    # ...
    proxy_cache_path /data/nginx/cache keys_zone=mycache:10m;
}

그런 다음 서버 응답을 캐시할 컨텍스트(프로토콜 유형, 가상 서버 또는 위치)에 proxy_cache 지시문을 포함시키고, proxy_cache_path 지시문에 keys_zone 매개변수로 정의된 Zone 이름(이 경우 mycache)을 지정합니다.

http {
    # ...
    proxy_cache_path /data/nginx/cache keys_zone=mycache:10m;
    server {
        proxy_cache mycache;
        location / {
            proxy_pass http://localhost:8000;
        }
    }
}

keys_zone 매개변수로 정의된 크기가 캐시된 응답 데이터의 최대 용량을 제한하지 않습니다. 캐시된 응답 자체는 메타데이터 사본과 함께 파일 시스템의 특정 파일에 저장됩니다. 캐시된 응답 데이터의 양을 제한하려면 max_size 매개변수를 proxy_cache_path 지시문에 포함하세요. (단, 다음 섹션에서 설명하는 것처럼 캐시된 데이터의 양이 일시적으로 이 제한을 초과할 수 있습니다.)

3. 캐싱에 관련된 NGINX Plus 프로세스

캐싱과 관련된 두 가지 추가 NGINX Plus 프로세스가 있습니다.

  • cache manager는 주기적으로 활성화되어 캐시 상태를 확인합니다. 캐시 크기가 proxy_cache_path 지시문에 max_size 매개변수로 설정한 제한을 초과하는 경우 캐시 관리자는 가장 최근에 액세스한 데이터를 제거합니다. 앞서 언급했듯이 캐시된 데이터의 양은 cache manager가 활성화되는 동안 일시적으로 한도를 초과할 수 있습니다.
  • cache loader는 NGINX가 시작된 직후에 한 번만 실행됩니다. cache loader는 이전에 캐시된 데이터에 대한 메타데이터를 공유 메모리 Zone으로 로드합니다. 전체 캐시를 한 번에 로드하면 시작 후 처음 몇 분 동안 리소스를 많이 소비하여 NGINX 성능이 느려질 수 있습니다. 이를 방지하려면 proxy_cache_path 지시문에 다음 매개 변수를 포함하여 캐시의 반복 로드를 구성합니다.
    • loader_threshold – 반복 기간, ms(기본값은 200)
    • loader_files – 한 번의 반복 중에 로드되는 최대 항목 수(기본값은 100개)
    • loader_sleeps – 반복 간 지연, ms(기본값은 50)

다음 예제에서는 반복이 300ms 동안 또는 200개의 항목이 로드될 때까지 지속됩니다.

proxy_cache_path /data/nginx/cache keys_zone=mycache:10m loader_threshold=300 loader_files=200;

4. 캐시할 요청 지정하기

기본적으로 NGINX Plus 는 Proxy된 서버에서 해당 응답을 처음 수신할 때 HTTP GET 및 HEAD 메서드로 이루어진 요청에 대한 모든 응답을 캐시합니다. 요청의 Key(식별자)로 NGINX Plus 는 요청 문자열을 사용합니다. 요청에 캐시된 응답과 동일한 Key가 있는 경우 NGINX Plus 는 캐시된 응답을 클라이언트로 보냅니다. http { }, server { } 또는 location { } 컨텍스트에 다양한 지시문을 포함시켜 캐시되는 응답을 제어할 수 있습니다.

Key를 계산하는 데 사용되는 요청 특성을 변경하려면 proxy_cache_key 지시문을 추가합니다.

proxy_cache_key "$host$request_uri$cookie_user";

응답이 캐시되기 전에 동일한 key를 가진 요청이 수행되어야 하는 최소 횟수를 정의하려면 proxy_cache_min_uses 지시문을 추가합니다.

proxy_cache_min_uses 5;

GET 및 HEAD 이외의 메서드를 사용하는 요청에 대한 응답을 캐시하려면 해당 메서드를 GET 및 HEAD와 함께 proxy_cache_methods 지시문의 매개변수로 지정합니다.

proxy_cache_methods GET HEAD POST;

5. 캐싱 제한 또는 비활성화

기본적으로 응답은 캐시에 무기한 남아 있습니다. 캐시가 구성된 최대 크기를 초과하는 경우에만 마지막으로 요청된 이후 시간 순으로 제거됩니다. http { }, server { } 또는 location { } 컨텍스트에 지시문을 포함하여 캐시된 응답이 유효한 것으로 간주되는 지속 시간 또는 응답이 전혀 사용되지 않는지를 설정할 수 있습니다:

특정 상태 코드가 있는 캐시된 응답을 유효한 것으로 간주하는 기간을 제한하려면 proxy_cache_valid 지시문을 추가하세요.

proxy_cache_valid 200 302 10m;
proxy_cache_valid 404      1m;

이 예에서 코드가 200 또는 302인 응답은 10분 동안 유효하고 코드가 404인 응답은 1분 동안 유효한 것으로 간주합니다. 모든 상태 코드를 가진 응답의 유효 시간을 정의하려면 첫 번째 매개 변수로 아무거나 지정합니다.

proxy_cache_valid any 5m;

NGINX Plus 가 캐시된 응답을 클라이언트에 보내지 않는 조건을 정의하려면 proxy_cache_bypass 지시문을 추가하세요. 각 매개변수는 조건을 정의하며 여러 변수로 구성됩니다. 하나 이상의 매개 변수가 비어 있지 않고 “0“(0)과 같지 않은 경우 NGINX Plus 는 캐시에서 응답을 조회하지 않고 대신 요청을 즉시 Backend 서버로 전달합니다.

proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;

응답을 전혀 캐시하지 않는 조건을 정의하려면 proxy_cache_bypass 지시문과 같은 방식으로 매개변수를 정의하는 proxy_no_cache 지시문을 추가하세요.

proxy_no_cache $http_pragma $http_authorization;

6. 캐시에서 콘텐츠 삭제

NGINX Plus 를 사용하면 캐시에서 오래된 캐시 파일을 제거할 수 있습니다. 이는 오래된 캐시된 콘텐츠를 제거하여 이전 버전과 새 버전의 웹 페이지를 동시에 제공하는 것을 방지하는 데 필요합니다. 캐시는 사용자 정의 HTTP 헤더가 포함된 특정 “purge” 요청 또는 HTTP PURGE 메서드를 수신하면 제거됩니다.

6-1. 캐시 Purge 구성

HTTP PURGE 메서드를 사용하는 요청을 식별하고 일치하는 URL을 삭제하는 구성을 설정해 보겠습니다.

1. http { } 컨텍스트에서 $request_method 변수에 종속되는 새 변수(예: $purge_method)를 생성합니다.

http {
    # ...
    map $request_method $purge_method {
        PURGE 1;
        default 0;
    }
}

2. 캐싱이 구성된 location { } 블록에 proxy_cache_purge 지시문을 포함시켜 캐시 제거 요청에 대한 조건을 지정합니다. 이 예제에서는 이전 단계에서 구성한 $purge_method입니다.

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

    location / {
        proxy_pass  https://localhost:8002;
        proxy_cache mycache;

        proxy_cache_purge $purge_method;
    }
}

6-2. Purge 명령 보내기

proxy_cache_purge 지시문이 구성된 경우 캐시를 제거하려면 특정 캐시 Purge 요청을 보내야 합니다. 이 예제에서와 같이 curl 명령을 비롯한 다양한 도구를 사용하여 Purge 요청을 실행할 수 있습니다.

$ curl -X PURGE -D – "https://www.example.com/*"
HTTP/1.1 204 No Content
Server: nginx/1.15.0
Date: Sat, 19 May 2018 16:33:04 GMT
Connection: keep-alive

이 예제에서는 별표 와일드카드로 지정된 공통 URL 부분을 가진 리소스가 제거됩니다. 그러나 이러한 캐시 항목은 캐시에서 완전히 제거되는 것이 아니라 비활성 상태(proxy_cache_path 지시문의 inactive 매개변수에 의해 결정됨)이거나 캐시 Purger(proxy_cache_path의 purger 매개변수로 활성화됨)로 인해 삭제되거나 클라이언트가 액세스를 시도할 때까지 디스크에 남아 있습니다.

6-3. Purge 명령에 대한 액세스 제한

캐시 Purge 요청을 보낼 수 있는 IP 주소의 수를 제한하는 것이 좋습니다.

geo $purge_allowed {
   default         0;  # deny from other
   10.0.0.1        1;  # allow from 10.0.0.1 address
   192.168.0.0/24  1;  # allow from 192.168.0.0/24
}

map $request_method $purge_method {
   PURGE   $purge_allowed;
   default 0;
}

이 예제에서 NGINX Plus 는 요청에 PURGE 메서드가 사용되었는지 확인하고, 사용되었다면 클라이언트 IP 주소를 분석합니다. IP 주소가 화이트리스트에 있는 경우 $purge_method가 $purge_allowed로 설정됩니다. 1은 제거를 허용하고 0은 제거를 거부합니다.

6-4. 캐시에서 파일을 완전히 제거하기

별표와 일치하는 캐시 파일을 완전히 제거하려면 모든 캐시 항목을 영구적으로 반복하고 와일드카드 Key와 일치하는 항목을 삭제하는 특정 cache purger 프로세스를 활성화합니다. http { } 컨텍스트에서 proxy_cache_path 지시문에 purger 매개변수를 추가합니다.

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=mycache:10m purger=on;

6-5. 캐시 Purge 구성 예제

http {
    # ...
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=mycache:10m purger=on;

    map $request_method $purge_method {
        PURGE 1;
        default 0;
    }

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

        location / {
            proxy_pass        https://localhost:8002;
            proxy_cache       mycache;
            proxy_cache_purge $purge_method;
        }
    }

    geo $purge_allowed {
       default         0;
       10.0.0.1        1;
       192.168.0.0/24  1;
    }

    map $request_method $purge_method {
       PURGE   $purge_allowed;
       default 0;
    }
}

7. Byte 범위 캐싱

초기 캐시 채우기 작업은 특히 대용량 파일의 경우 꽤 오랜 시간이 걸리는 경우가 있습니다. 예를 들어, 파일 일부에 대한 초기 요청을 처리하기 위해 비디오 파일 다운로드가 시작되면 후속 요청은 전체 파일이 다운로드되어 캐시에 저장될 때까지 기다려야 합니다.

NGINX Plus 는 이러한 범위 요청을 캐시하고 파일을 더 작은 “slices”으로 나누는 Cache Slice 모듈로 캐시를 점진적으로 채울 수 있습니다. 각 범위 요청은 요청된 범위를 커버하는 특정 슬라이스를 선택하고, 이 범위가 여전히 캐시되지 않은 경우 캐시에 넣습니다. 이러한 슬라이스에 대한 다른 모든 요청은 캐시에서 데이터를 가져옵니다.

Byte 범위 캐싱을 활성화하려면.

1. Cache Slice 모듈과 함께 NGINX가 컴파일되었는지 확인합니다.

2. slice 지시문을 사용하여 슬라이스의 크기를 지정합니다.

location / {
    slice  1m;
}

슬라이스를 빠르게 다운로드할 수 있는 슬라이스 크기를 선택합니다. 크기가 너무 작으면 메모리 사용량이 과도하게 증가하여 요청을 처리하는 동안 많은 수의 파일 설명자가 열리고, 크기가 지나치게 크면 지연이 발생할 수 있습니다.

3. $slice_range 변수를 캐시 Key에 추가합니다.

proxy_cache_key $uri$is_args$args$slice_range;

4. 206 상태 코드가 포함된 응답 캐싱을 사용하도록 설정합니다.

proxy_cache_valid 200 206 1h;

5. Range 헤더 필드에 $slice_range 변수를 설정하여 Proxy된 서버로 Range 요청을 전달할 수 있도록 설정합니다.

proxy_set_header  Range $slice_range;

전체 구성은 다음과 같습니다.

location / {
    slice             1m;
    proxy_cache       cache;
    proxy_cache_key   $uri$is_args$args$slice_range;
    proxy_set_header  Range $slice_range;
    proxy_cache_valid 200 206 1h;
    proxy_pass        http://localhost:8000;
}

Note: 슬라이스 캐싱이 켜져 있는 경우 초기 파일을 변경해서는 안 됩니다.

8. 결합 구성 예제

다음 샘플 구성은 위에서 설명한 캐싱 옵션 중 일부를 결합한 것입니다.

http {
    # ...
    proxy_cache_path /data/nginx/cache keys_zone=mycache:10m loader_threshold=300
                     loader_files=200 max_size=200m;

    server {
        listen 8080;
        proxy_cache mycache;

        location / {
            proxy_pass http://backend1;
        }

        location /some/path {
            proxy_pass http://backend2;
            proxy_cache_valid any 1m;
            proxy_cache_min_uses 3;
            proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
        }
    }
}

이 예제에서는 두 위치에서 동일한 캐시를 사용하지만 다른 방식으로 사용합니다.

backend1의 응답은 거의 변경되지 않으므로 cache-control 지시문이 포함되지 않습니다. 응답은 요청이 처음 이루어질 때 캐시되며 무기한 유효합니다.

반면, backend2에서 제공하는 요청에 대한 응답은 자주 변경되므로 1분 동안만 유효한 것으로 간주되며 동일한 요청이 3번 이루어질 때까지 캐시에 저장되지 않습니다. 또한 요청이 proxy_cache_bypass 지시문에 정의된 조건과 일치하는 경우 NGINX Plus 는 캐시에서 해당 응답을 찾지 않고 즉시 요청을 backend2로 전달합니다.