NGINX Plus 를 통한 동적 Content Caching 구현

이 블로그 포스트에서는 NGINX Plus 를 활용한 동적 Content Caching 구현 방법에 대해 알아봅니다.
동적 콘텐츠는 주로 데이터베이스에서 가져와 생성되기 때문에 서버 부하가 증가할 수 있지만, 캐싱을 통해 응답 속도와 성능을 향상시킬 수 있습니다. NGINX Plus는 이러한 동적 콘텐츠를 효율적으로 캐싱하는 기능을 제공하며, 이를 통해 서버 리소스를 절약하고 사용자 경험을 향상시킬 수 있습니다.

해당 포스트에서는 NGINX Plus의 동적 콘텐츠 캐싱 기능을 설정하고 최적화하는 방법을 구체적으로 설명합니다.

목차

1. NGINX Plus 를 통한 동적 Content Caching 의 필요성
 1-1. 동적 콘텐츠와 정적 콘텐츠의 차이점
 1-2. NGINX Plus Content Caching 을 통한 성능 향상 개요
 1-3. NGINX Plus 가 제공하는 Content Caching 의 장점
2. NGINX Plus 동적 Content Caching 설정 방법
 2-1. 기본 Cache 설정 파일 구성
 2-2. Caching 대상 동적 콘텐츠 정의
 2-3. Cache 유효 기간 및 업데이트 설정
3. NGINX Plus 동적 Content Caching 최적화
 3-1. Cache-Control 헤더 설정 방법
 3-2. FastCGI 및 Proxy Cache 활용
4. NGINX Plus Content Caching 성능 모니터링
 4-1. NGINX Plus를 통한 Cache 모니터링

1. NGINX Plus 를 통한 동적 Content Caching 의 필요성

모던 웹 환경에서는 빠르고 안정적인 사용자 경험이 매우 중요합니다.
특히 동적 콘텐츠는 사용자 요청에 따라 실시간으로 생성되며, 데이터베이스 조회나 외부 API와의 상호작용이 빈번하게 발생합니다.
이러한 동적 콘텐츠는 서버 리소스를 많이 소비하고, 요청이 많을 경우 서버에 부하를 증가시켜 응답 속도가 느려질 수 있습니다.

동적 콘텐츠와 정적 콘텐츠의 차이점을 이해하는 것은 중요합니다.
정적 콘텐츠는 HTML, 이미지, CSS, JavaScript 등 미리 생성된 파일들로 구성되어 있고, 이를 캐싱함으로써 매우 빠르게 제공할 수 있습니다. 반면, 동적 콘텐츠는 사용자 요청마다 새롭게 생성되기 때문에, 캐싱이 없다면 매번 동일한 요청에 대해 다시 서버 자원을 소모하게 됩니다.

이때 NGINX Plus를 통한 동적 Content Caching이 매우 유용합니다. NGINX Plus는 정적 콘텐츠뿐만 아니라 동적 콘텐츠도 효과적으로 캐싱할 수 있는 기능을 제공합니다.
이를 통해 동일한 요청에 대한 처리 시간을 줄이고, 서버 부하를 크게 줄일 수 있습니다. 특히, 자주 변경되지 않는 동적 콘텐츠를 캐시하면 웹사이트 성능을 극대화할 수 있습니다.

NGINX Plus가 제공하는 Content Caching 기능은 단순히 성능 향상뿐만 아니라, 사용자 경험을 향상시키고 검색 엔진 최적화(SEO)에도 긍정적인 영향을 미칩니다.
캐시된 페이지가 더 빠르게 로드되면 사용자 이탈률이 줄어들고, 페이지 속도가 빠르면 검색 엔진에서도 더 높은 평가를 받을 수 있기 때문입니다.

결론적으로, NGINX Plus를 통한 동적 Content Caching은 웹사이트 성능을 향상시키고, 사용자와 검색 엔진 모두에게 긍정적인 영향을 미칠 수 있는 중요한 기능입니다.

1-1. 동적 콘텐츠와 정적 콘텐츠의 차이점

웹 콘텐츠는 크게 동적 콘텐츠와 정적 콘텐츠로 나눌 수 있습니다. 이 두 가지 유형의 콘텐츠는 서버에서 처리되는 방식과 사용자에게 전달되는 방식에서 큰 차이를 보입니다.

정적 콘텐츠는 HTML, CSS, JavaScript 파일, 이미지, 동영상과 같이 미리 생성된 데이터를 말합니다.
이러한 콘텐츠는 서버에 저장된 파일을 그대로 사용자에게 전달하는 방식으로, 변경되지 않기 때문에 요청이 들어올 때마다 다시 생성할 필요가 없습니다.
따라서 정적 콘텐츠는 매우 빠르게 제공될 수 있으며, NGINX와 같은 웹 서버를 통해 쉽게 캐싱하여 더욱 효율적으로 제공할 수 있습니다.

반면, 동적 콘텐츠는 사용자의 요청에 따라 실시간으로 생성되는 데이터입니다.
예를 들어, 사용자 맞춤형 정보나, 데이터베이스에서 가져온 최신 정보, 외부 API와의 상호작용을 통해 생성된 콘텐츠 등이 이에 해당합니다.
동적 콘텐츠는 정적 콘텐츠와 달리 서버에서 요청마다 새롭게 처리되며, 매번 데이터베이스나 외부 소스와의 연동을 거쳐야 하므로 서버 자원을 더 많이 소비합니다.
이러한 처리 과정이 반복되면 서버 부하가 증가하여 응답 속도가 느려질 수 있습니다.

동적 콘텐츠는 맞춤형 사용자 경험을 제공하는 데 매우 유용하지만, 그에 따른 성능 문제를 해결하기 위해서는 동적 Content Caching이 필요합니다. NGINX Plus는 이러한 동적 콘텐츠를 캐싱하여 서버의 처리 부담을 줄이고, 더 빠른 응답을 제공할 수 있게 해줍니다.

결론적으로, 정적 콘텐츠는 미리 생성되어 빠르게 제공될 수 있는 반면, 동적 콘텐츠는 실시간으로 생성되므로 서버 부하가 크지만, 캐싱을 통해 성능을 최적화할 수 있습니다.
두 콘텐츠 유형을 적절히 이해하고 활용하는 것이 웹사이트 성능 최적화의 핵심입니다.

1-2. NGINX Plus Content Caching 을 통한 성능 향상 개요

웹사이트 성능을 최적화하는 데 있어 NGINX Plus의 Content Caching 기능은 매우 중요한 역할을 합니다.
특히 동적 콘텐츠는 서버 자원을 많이 소모하므로, 이를 효율적으로 캐싱하면 서버 부하를 줄이고 응답 속도를 크게 향상시킬 수 있습니다.

NGINX Plus는 동적 콘텐츠 캐싱을 통해 자주 요청되는 데이터나 페이지를 미리 저장해 두고, 같은 요청이 들어올 때 서버에서 다시 생성할 필요 없이 캐시에서 즉시 응답할 수 있습니다.
이 과정은 웹 서버와 데이터베이스의 부하를 줄여주며, 특히 트래픽이 많은 사이트에서는 성능에 큰 차이를 만듭니다.

NGINX Plus의 Content Caching은 다음과 같은 방식으로 성능을 향상시킵니다:

• 첫 번째 요청만 처리: NGINX Plus는 처음 요청을 받을 때만 동적 콘텐츠를 생성하고, 이후 동일한 요청이 들어오면 캐시에 저장된 콘텐츠를 반환합니다. 이를 통해 서버가 같은 작업을 반복하지 않아도 되므로 처리 시간이 단축됩니다.
• 캐시 유효 기간 설정: 자주 변경되지 않는 콘텐츠는 일정 시간 동안 캐시에 저장하여, 해당 기간 동안 서버의 추가 작업 없이 캐시된 데이터를 제공합니다. 이를 통해 서버 자원 소모를 최소화할 수 있습니다.
• 트래픽 급증에 대한 대응: 트래픽이 급증할 경우, NGINX Plus는 캐시된 콘텐츠를 사용하여 빠른 응답을 제공하므로 서버가 과부하되지 않고 안정적인 성능을 유지할 수 있습니다.

또한, Cache-Control 헤더와 같은 HTTP 캐시 규칙을 설정함으로써 NGINX Plus가 어떤 콘텐츠를 캐싱하고, 캐시된 콘텐츠를 언제 갱신할지 세밀하게 조정할 수 있습니다.
이를 통해 사용자는 최신 정보와 빠른 응답 속도를 동시에 경험할 수 있습니다.

결론적으로, NGINX Plus의 Content Caching은 서버 부하를 줄이고 웹사이트 응답 속도를 향상시킴으로써, 트래픽이 많은 상황에서도 안정적인 성능을 유지하게 해주는 강력한 기능입니다.

1-3. NGINX Plus 가 제공하는 Content Caching 의 장점

NGINX Plus의 Content Caching 기능은 웹사이트 성능을 향상시키고 서버 리소스를 최적화하는 데 매우 유용한 도구입니다. 특히 동적 콘텐츠 캐싱을 통해 서버의 부담을 줄이고 사용자에게 더 빠른 응답을 제공할 수 있습니다. NGINX Plus가 제공하는 Content Caching의 주요 장점은 다음과 같습니다.

1. 서버 부하 감소: NGINX Plus는 자주 요청되는 동적 콘텐츠를 캐시함으로써 서버가 매번 동일한 콘텐츠를 생성하지 않도록 합니다. 이를 통해 웹 서버와 데이터베이스의 부하를 크게 줄일 수 있습니다. 서버 자원이 효율적으로 사용되면, 더 많은 트래픽을 처리할 수 있으며, 서버가 과부하 상태에 빠지는 것을 방지할 수 있습니다.
2. 응답 시간 단축: 캐시된 콘텐츠는 서버에서 처리 과정을 거치지 않고 즉시 클라이언트에 전달되므로, 페이지 로딩 속도가 크게 향상됩니다. 특히 자주 업데이트되지 않는 콘텐츠에 대해서는 캐싱을 통해 빠른 응답을 제공할 수 있어 사용자 경험을 개선할 수 있습니다.
3. 트래픽 급증 대응: 트래픽이 급증할 때 NGINX Plus의 캐싱 기능은 매우 효과적입니다. 서버가 모든 요청을 실시간으로 처리하지 않고, 캐시된 콘텐츠를 제공함으로써 서버 성능을 안정적으로 유지할 수 있습니다. 특히 대규모 이벤트나 마케팅 캠페인 등으로 인한 트래픽 폭증 상황에서도 안정적인 웹사이트 운영이 가능합니다.
4. 캐시 관리의 유연성: NGINX Plus는 Cache-Control, Expires와 같은 HTTP 헤더를 사용하여 캐시 정책을 세밀하게 설정할 수 있습니다. 이를 통해 어떤 콘텐츠를 캐시하고, 캐시된 콘텐츠를 언제 갱신할지 등 캐시 동작을 세부적으로 제어할 수 있습니다. 이를 통해 사용자에게 최신 정보와 빠른 응답 속도를 동시에 제공할 수 있습니다.
5. SEO 최적화: 빠른 페이지 로딩 속도는 검색 엔진 최적화(SEO)에도 긍정적인 영향을 미칩니다. NGINX Plus의 Content Caching을 통해 페이지 로딩 시간을 단축하면, 검색 엔진에서 더 높은 평가를 받아 검색 순위가 상승할 수 있습니다. 또한, 사용자 이탈률이 낮아져 웹사이트의 전반적인 성과가 개선됩니다.

결론적으로, NGINX Plus의 Content Caching은 서버 성능 향상, 사용자 경험 개선, 트래픽 급증에 대한 대응, SEO 최적화 등 여러 면에서 큰 장점을 제공합니다. 이를 통해 보다 안정적이고 효율적인 웹사이트 운영이 가능합니다.

2. NGINX Plus 동적 Content Caching 설정 방법

2-1. 기본 Cache 설정 파일 구성

NGINX Plus Caching 구성 파일은 다음과 같습니다.

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

proxy_cache_path /usr/share/nginx/cache/data levels=1:2 keys_zone=data_cache:10m inactive=60m max_size=1g;

server {
...

    location /data {
        proxy_cache data_cache;
        proxy_cache_valid 200 302 60m;  # 200 또는 302 응답을 60분간 캐싱
        proxy_cache_valid 404 1m;       # 404 응답을 1분간 캐싱
        proxy_cache_bypass $http_cache_control;
        proxy_no_cache $http_cache_control;
        proxy_cache_purge $purge_method;

        proxy_pass http://example.com$request_uri;
        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;
    }

...
}

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

이 NGINX map 지시문은 요청 메서드에 따라 $purge_method 변수를 설정하는 역할을 합니다.

PURGE 요청일 경우 $purge_method가 1로 설정되고, 다른 모든 요청에는 $purge_method가 0으로 설정됩니다. 이를 통해 캐시 삭제 로직에서 $purge_method 변수를 활용할 수 있게 됩니다.

PURGE 요청을 통해 NGINX Plus에 캐시된 콘텐츠를 삭제할 수 있습니다.

curl -X PURGE -D – "localhost/data" -v
*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> PURGE /data HTTP/1.1
> Host: localhost
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 204 No Content
< Server: nginx/1.25.5
< Date: Wed, 25 Sep 2024 07:34:33 GMT
< Connection: keep-alive
< 
* Connection #0 to host localhost left intact

proxy_cache_path /usr/share/nginx/cache/data levels=1:2 keys_zone=data_cache:10m inactive=60m max_size=1g;

각 부분을 해석하면 다음과 같습니다:

캐시 디렉토리의 최대 크기를 설정합니다. 여기서는 캐시의 최대 크기가 1GB로 설정되어 있습니다. 이 크기를 초과하면 오래된 항목부터 자동으로 삭제됩니다.
이 NGINX 지시문은 proxy_cache 기능을 활성화하여 프록시 서버가 받은 응답을 캐시하는 설정을 정의하는 것입니다.

proxy_cache_path /usr/share/nginx/cache/data:

캐시 데이터를 저장할 디렉토리 경로를 지정합니다. 여기서는 /usr/share/nginx/cache/data 디렉토리에 캐시가 저장됩니다.

levels=1:2:

캐시 데이터를 저장할 디렉토리 구조의 깊이를 설정합니다. 여기서 levels=1:2는 캐시 파일이 2계층의 서브디렉토리에 저장된다는 뜻입니다. 첫 번째 레벨에서는 1개의 하위 디렉토리, 두 번째 레벨에서는 2개의 하위 디렉토리가 생성됩니다. 이 구조는 파일 시스템에서 많은 캐시 파일을 저장할 때 성능을 향상시키는 데 도움이 됩니다.

keys_zone=data_cache:10m:

캐시 영역의 이름과 메타데이터(캐시 키, 경로 등)를 저장할 메모리 크기를 설정합니다. 여기서 data_cache는 캐시 영역의 이름이고, 10m는 메타데이터를 저장할 메모리 공간을 10MB로 지정하는 것입니다.

inactive=60m:

이 옵션은 캐시된 항목이 얼마나 오랫동안 요청되지 않으면 캐시에서 제거될지를 설정합니다. 여기서는 60분 동안 요청되지 않은 캐시 항목이 자동으로 삭제됩니다.

max_size=1g:

2-2. Caching 대상 동적 콘텐츠 정의

    location /data {
        proxy_cache data_cache;
        ...

        proxy_pass http://example.com$request_uri;
    }

요청을 Caching 할 동적 콘텐츠 대상을 정의합니다. NGINX의 “/data” 경로로 요청이 발생할 경우 proxy_cache 지시문을 통해 상위에서 지정한 proxy_cache_path의 Cache Zone으로 요청을 캐싱합니다.

proxy_cache_path /usr/share/nginx/cache/data levels=1:2 keys_zone=data_cache:10m inactive=60m max_size=1g;

proxy_pass는 Caching 될 동적인 콘텐츠가 존재하는 백엔드 서버로서, 해당 포스트에서 백엔드 서버는
MySQL Database 테이블을 쿼리하여 웹에 표시하는 NodeJS 서버입니다.

NGINX Plus의 Cache 구성을 완료한 뒤 cURL 명령을 통해 Caching 전/후 응답 속도를 비교합니다.

// Caching 이전 응답 속도 (단위: 초)
$ curl -o /dev/null -s -w 'Time: %{time_total}\n' http://localhost/data

Time: 3.995705

// 1회 요청 이후 Caching된 응답 속도 (단위: 초)
$ curl -o /dev/null -s -w 'Time: %{time_total}\n' http://localhost/data

Time: 0.001160

Caching 이후 응답 속도가 약 3400배 가량 개선된 것을 확인할 수 있습니다.

2-3. Cache 유효 기간 및 업데이트 설정

proxy_cache_path 지시문의 inactive 파라미터를 통해 Cache 유효 기간을 설정할 수 있습니다.

inactive 지시문에서 설정하는 단위는 기본적으로 시간 단위를 지정하지 않으면 초 단위로 처리되므로, 명확하게 분이나 시간을 설정하려면 m(분), h(시간) 등의 단위를 명시해야 합니다. NGINX에서 사용할 수 있는 시간 단위는 다음과 같습니다:

• s: 초 (seconds)
• m: 분 (minutes)
• h: 시간 (hours)
• d: 일 (days)

예를 들어, 캐시된 항목이 30초 동안 요청되지 않으면 제거되도록 설정하려면 다음과 같이 설정할 수 있습니다.

inactive=30s;

또는 2시간으로 설정하려면:

inactive=2h;

3. NGINX Plus 동적 Content Caching 최적화

3-1. Cache-Control 헤더 설정 방법

Cache-Control 헤더는 클라이언트와 프록시 서버가 콘텐츠를 어떻게 캐싱할지를 결정하는 중요한 역할을 합니다.

NGINX Plus에서 동적 콘텐츠 캐싱을 최적화하기 위해, 이 헤더를 적절하게 설정하는 것이 중요합니다. 예를 들어, public, private, no-cache, max-age 등 다양한 옵션을 통해 캐시된 콘텐츠의 유효 기간을 제어할 수 있습니다.

이를 통해 자주 변경되는 콘텐츠는 짧은 시간만 캐싱하고, 자주 변경되지 않는 콘텐츠는 더 긴 시간 동안 캐싱할 수 있습니다. 이를 통해 캐시 활용도를 극대화할 수 있습니다.

1. public

• 의미: 이 옵션을 설정하면, 콘텐츠가 클라이언트뿐만 아니라 중간 프록시 서버에서도 캐싱될 수 있습니다.
• 사용 예시: 자주 변경되지 않는 콘텐츠(예: 이미지, CSS 파일 등)를 클라이언트와 프록시 서버 모두에 캐싱하도록 허용할 때 사용됩니다.

NGINX 설정 예시:

location /data {
    expires 30d;  # 30일 동안 캐싱
    add_header Cache-Control "public";
}

2. private

• 의미: 이 옵션은 콘텐츠를 오직 클라이언트 측에만 캐싱하도록 제한합니다. 프록시 서버에서는 캐싱하지 않습니다.
• 사용 예시: 사용자 개인 정보나 세션 정보와 같이 다른 사용자와 공유되어서는 안 되는 데이터를 캐싱할 때 사용됩니다.

NGINX 설정 예시:

location /data {
    expires 10m;  # 10분 동안 캐싱
    add_header Cache-Control "private";
}

3. no-cache

• 의미: 콘텐츠를 캐싱할 수 있지만, 클라이언트는 반드시 서버와 재검증을 해야 합니다. 캐시된 콘텐츠가 최신인지 확인하기 위한 재검증을 요구하는 옵션입니다.
• 사용 예시: 자주 업데이트되지만 서버에서 제공하는 콘텐츠를 캐시할 수는 있지만, 항상 최신 상태로 유지해야 할 때 사용됩니다.

NGINX 설정 예시:

location /data {
    add_header Cache-Control "no-cache";
}

4. max-age

• 의미: 캐시된 콘텐츠가 유효한 시간을 초(second) 단위로 지정합니다. 해당 시간이 지나면 콘텐츠는 만료되고, 서버에서 새로운 콘텐츠를 요청해야 합니다.
• 사용 예시: 일정 시간이 지나면 콘텐츠를 갱신해야 할 때 유효 기간을 설정하는 데 사용됩니다.

NGINX 설정 예시:

location /data {
    expires 1h;  # 1시간 동안 캐싱
    add_header Cache-Control "public, max-age=3600";  # 3600초(1시간) 동안 캐싱
}

5. no-store

• 의미: 캐시 자체를 금지합니다. 클라이언트와 프록시 서버 모두 캐싱하지 않고 매번 서버에서 새로운 콘텐츠를 받아옵니다.
• 사용 예시: 보안이 필요한 데이터나 민감한 정보를 서버에서 요청할 때 사용됩니다.

NGINX 설정 예시:

location /data {
    add_header Cache-Control "no-store";
}

6. must-revalidate

• 의미: 캐시가 만료되면 반드시 서버와 재검증을 해야 하는 옵션입니다. 만료된 캐시가 사용되지 않도록 보장하는 역할을 합니다.
• 사용 예시: 캐시된 콘텐츠의 정확성과 최신성을 보장하고자 할 때 사용됩니다.

NGINX 설정 예시:

location /data {
    expires 24h;  # 24시간 동안 캐싱
    add_header Cache-Control "public, max-age=86400, must-revalidate";
}

3-2. FastCGI 활용

NGINX Plus는 FastCGI 캐시를 통해 동적 콘텐츠를 효율적으로 캐싱할 수 있는 기능을 제공합니다. 두 캐싱 메커니즘은 백엔드 서버로부터 가져온 동적 콘텐츠를 캐싱하여, 동일한 요청에 대해 서버의 재처리를 최소화하고 응답 속도를 크게 향상시킬 수 있습니다.

FastCGI 캐시 설정 예시:

http {
    fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=FASTCGI_CACHE:10m inactive=60m;
    
    server {
        location ~ \.php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_cache FASTCGI_CACHE;  # FastCGI 캐시 활성화
            fastcgi_cache_valid 200 302 10m;  # 200, 302 응답은 10분 동안 캐싱
            fastcgi_cache_valid 404 1m;  # 404 응답은 1분 동안 캐싱
            fastcgi_cache_use_stale error timeout updating;
            include fastcgi_params;
        }
    }
}

이 설정에서는 PHP 파일에 대한 요청을 처리할 때 NGINX Plus가 FastCGI 캐시를 사용하도록 하며, 200, 302 응답은 10분 동안 캐싱하고 404 응답은 1분 동안 캐싱하게 됩니다. 캐시된 응답이 유효하지 않으면 새로운 요청을 FastCGI 서버로 전달하고, 그렇지 않으면 캐시된 콘텐츠를 빠르게 제공합니다.

4. NGINX Plus Content Caching 성능 모니터링

NGINX Plus는 웹 기반 Dashboard를 통해 캐시 사용 상태를 시각적으로 모니터링할 수 있는 기능을 제공합니다.

캐시된 콘텐츠의 적중률, 캐시된 항목의 사이즈, 캐시 만료 및 제거된 항목 등을 한눈에 확인할 수 있습니다. 대시보드는 성능 추적을 쉽게 할 수 있도록 시각적으로 데이터를 제공하며, 이를 통해 캐시의 효율성을 빠르게 평가할 수 있습니다.

NGINX Plus 웹 기반 Dashboard 구현은 NGINX STORE의 NGINX Plus: Live Activity Monitoring 문서를 참고하세요.

4-1. NGINX Plus를 통한 Cache 모니터링

NGINX Plus의 Caches 탭에서 Cache Zone에 대한 정보를 확인할 수 있습니다.

요청이 Cache 되기 이전에는 Cache Zone의 State가 “Cold”로 표시됩니다.

요청이 캐싱되면 Cache Zone의 State가 “Warm”으로 변경되고, Traffic 탭에서 받은 데이터와 캐시된 데이터, Bypassed된 데이터의 크기를 확인할 수 있습니다.

• cold: 캐시가 cold 상태인 경우, 캐시가 충분히 채워지지 않았거나 갱신된 후 아직 많은 데이터를 저장하지 못한 상태를 의미합니다.
• warm: 캐시가 warm 상태라면, 캐시에 충분한 데이터가 축적되어 활발하게 사용되고 있는 상태를 의미합니다. 캐시가 많은 요청을 처리하며, 적중률이 높아지면 캐시는 warm 상태가 됩니다.

• served: 캐시에서 served된 응답은 캐시가 적중(hit)하여 클라이언트에 제공된 콘텐츠를 의미합니다. 캐시에 저장된 콘텐츠가 유효하고, 서버에서 처리 없이 캐시된 콘텐츠를 클라이언트에 반환할 때 이 항목이 증가합니다.
• written: 캐시가 적중(hit)하지 않아 서버에서 새롭게 생성된 응답이 캐시에 저장된 경우를 의미합니다. 즉, 캐시에 콘텐츠를 작성(written)할 때 증가합니다.
• bypassed:특정 요청이 캐시를 건너뛰어 백엔드 서버로 직접 전달된 경우를 의미합니다. 캐시가 특정 이유로 우회되었을 때, 예를 들어 캐시에서 제공하지 않아야 할 데이터이거나 캐시 정책에 따라 우회 설정이 되어 있을 경우, 이 필드가 증가합니다.
  이는 캐시를 사용하지 않고 서버가 직접 응답했음을 나타냅니다.

NGINX Plus의 Demo Dashboard는 하기 링크에서 확인할 수 있습니다.

demo.nginx.com/dashboard.html

NGINX Plus를 통한 동적 Content Caching 이외에도 SSL/TLS Termination, JWT 인증, API Gateway 구축에 대해 관심이 있으신가요?

NGINX STORE의 NGINX 카테고리, 혹은 Docs를 참고하거나 NGINX STORE에 직접 문의하여 사용 사례에 대해 상담 받아보세요.

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

* indicates required

Email Address *

핸드폰 번호

이름

문의내용

당신이 인간이라면 이 필드를 비워두세요: