NGINX Plus 기능: 캐싱

NGINX Plus의 가장 인기 있는 사용 사례 중 하나는 로컬 원본 서버를 가속화하고 콘텐츠 딜리버리 네트워크(CDN)용 엣지 서버를 생성하는 콘텐츠 캐시로 사용하는 것입니다. 콘텐츠의 캐시 가능성과 사용자 트래픽 프로필에 따라 캐싱을 통해 원본 서버의 로드를 대폭 줄일 수 있습니다.

NGINX Plus는 업스트림 HTTP 서버에서 검색된 콘텐츠와 FastCGI, SCGIuwsgi 서비스에서 반환된 응답을 캐시할 수 있습니다.

NGINX Plus는 실시간 활동 모니터링 대시보드캐시 삭제 지원과 캐시 상태에 대한 더 풍부한 시각화를 추가하여 NGINX Open Source의 콘텐츠 캐싱 기능을 확장합니다.

cache-state-R7

콘텐츠 캐싱을 사용하는 이유

콘텐츠 캐싱은 웹 페이지의 로드 시간을 개선하고, 업스트림 서버의 로드를 줄이며, 원본 서버에 오류가 발생한 경우 캐시된 콘텐츠를 백업으로 사용하여 가용성을 향상시킵니다.

  • 사이트 성능 향상 – NGINX Plus는 모든 유형의 캐시된 콘텐츠를 정적 콘텐츠와 동일한 속도로 제공하므로 지연 시간이 줄어들고 웹사이트의 응답성이 향상됩니다.
  • 용량 증가 – NGINX Plus는 원본 서버에서 반복적인 작업을 오프로드하여 더 많은 사용자에게 서비스를 제공하고 더 많은 애플리케이션을 실행할 수 있도록 용량을 확보합니다.
  • 가용성 향상 – NGINX Plus는 원본 서버가 다운되었을 때 캐시된 콘텐츠(오래된 콘텐츠 포함)를 제공하여 심각한 오류로부터 사용자를 보호합니다.

NGINX Plus 및 NGINX는 원본 콘텐츠용 HTTP 서버, FastCGI 및 기타 프로토콜용 애플리케이션 게이트웨이, 업스트림 서버용 HTTP 프록시를 통합하여 웹 인프라를 위한 통합 솔루션을 제공합니다. NGINX Plus는 엔터프라이즈급 애플리케이션 로드 밸런싱을 추가하여 웹 인프라에 프런트엔드 로드 밸런서를 통합합니다.

자세히 알아보기 – NGINX Plus를 사용한 콘텐츠 캐싱

캐시된 콘텐츠는 디스크의 영구 캐시에 저장되며 NGINX Plus 및 NGINX에서 원본 콘텐츠와 똑같은 방식으로 제공합니다.

콘텐츠 캐싱을 활성화하려면 구성에 proxy_cache_pathproxy_cache 지시문을 포함하십시오.

# Define a content cache location on disk
proxy_cache_path /tmp/cache keys_zone=mycache:10m inactive=60m;

server {
    listen 80;
    server_name localhost;
 
    location / {
        proxy_pass http://localhost:8080;
 
       # reference the cache in a location that uses proxy_pass
       proxy_cache mycache;
    }
}

기본적으로 NGINX Plus 및 NGINX는 콘텐츠 캐싱에 대해 안전하고 신중한 접근 방식을 사용합니다. Set-Cookie 응답 없이 GET 또는 HEAD 요청으로 검색된 콘텐츠를 캐시하며, 캐시 시간은 원본 서버 헤더(X-Accel-Expires, Cache-ControlExpires)로 정의됩니다. NGINX Plus는 RFC 5861에 정의된 Cache-Control 확장, stale-while-revalidatestale-if-error를 적용합니다.

다양한 지시문을 사용하여 이러한 각 동작을 확장하고 미세 조정할 수 있습니다. 포괄적인 소개는 NGINX Plus Admin Guide를 참조하십시오.

캐시 계측

NGINX Plus의 실시간 활동 모니터링 API는 콘텐츠 캐시의 활용도와 효율성을 측정하는 데 사용할 수 있는 다양한 통계를 보고합니다.

실시간 활동 모니터링 API의 샘플 JSON 데이터

JSON 데이터에는 캐시 활동에 대한 전체 정보가 포함됩니다.

오래된 콘텐츠 관리

기본적으로 NGINX Plus 및 NGINX는 유효한 기간 동안 캐시된 콘텐츠를 제공합니다. 유효성은 원본 서버가 설정한 Cache-Control 헤더로 구성 가능하거나 제어될 수 있습니다. 유효 기간이 지나면 캐시된 콘텐츠가 오래된 것으로 간주되므로 캐시된 콘텐츠가 원본 서버에서 발견된 콘텐츠와 여전히 동일한지 확인하여 유효성을 다시 검사해야 합니다.

오래된 콘텐츠는 클라이언트가 요청하지 않을 수 있으므로 NGINX Plus 및 NGINX는 클라이언트가 요청할 때만 오래된 콘텐츠의 유효성을 다시 검사합니다. 이 작업은 오래된 콘텐츠를 즉시 제공하는 방식으로 클라이언트 요청을 중단하거나 지연시키지 않고 백그라운드에서 수행할 수 있습니다. 원본 서버를 사용할 수 없을 때도 오래된 콘텐츠가 제공되어 원본 서버의 최대 부하 또는 장기 중단 시간에 고가용성을 제공합니다.

NGINX 및 NGINX Plus가 오래된 콘텐츠를 제공하는 조건은 지시문을 사용하거나 원본 서버의 Cache-Control 헤더, stale-while-revalidatestale-if-error에 있는 값을 적용하여 구성할 수 있습니다.

캐시에서 콘텐츠 삭제

콘텐츠 캐싱의 부작용 중 하나는 원본 서버의 콘텐츠 업데이트가 반드시 캐시에 즉시 전파되는 것은 아니라는 점입니다. 즉, 클라이언트는 일정 기간 동안 이전 콘텐츠를 계속해서 제공받을 수 있습니다. 업데이트 작업으로 인해 여러 리소스가 동시에 변경되는 경우(예: CSS 파일 및 참조 이미지 변경) 클라이언트에 오래된 리소스와 현재 리소스가 혼합되어 제공되어 일관되지 않은 프레젠테이션이 발생할 수 있습니다.

NGINX Plus의 캐시 삭제 기능을 사용하면 이 문제를 쉽게 해결할 수 있습니다. proxy_cache_purge 지시문을 사용하면 NGINX Plus 콘텐츠 캐시에서 구성된 값과 일치하는 항목을 즉시 삭제할 수 있습니다. 이 메서드는 사용자 지정 HTTP 헤더 또는 메서드가 포함된 요청에 의해 가장 쉽게 트리거됩니다.

예를 들어 다음 구성은 PURGE HTTP 메서드를 사용하는 요청을 식별하고 일치하는 URL을 삭제합니다.

proxy_cache_path /tmp/cache keys_zone=mycache:10m levels=1:2 inactive=60s;

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

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

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

        proxy_cache_purge $purge_method;
    }
}

다음 예의 curl 명령과 같은 다양한 도구를 사용하여 삭제 요청을 실행할 수 있습니다.

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

이 예에 표시된 대로 URL에 별표(*) 와일드카드를 추가하여 공통 URL 스템이 있는 전체 리소스 세트를 제거할 수 있습니다.

추가 정보

NGINX Plus는 NGINX의 모든 캐싱 기능을 상속합니다. 자세한 내용은 NGINX Plus Admin Guide참조 문서를 확인하십시오.

다음 단계