캐싱: NGINX Plus로 효과적인 콘텐츠 딜리버리
NGINX Plus 의 가장 인기 있는 사용 사례 중 하나는 local origin 서버를 가속하고 content delivery networks(CDN)를 위한 엣지 서버를 생성하는 콘텐츠 캐시입니다. 캐싱 은 콘텐츠의 캐시 가능 여부와 사용자 트래픽 프로필에 따라 Origin 서버의 부하를 크게 줄일 수 있습니다.
NGINX Plus는 업스트림 HTTP 서버에서 검색된 콘텐츠와 FastCGI, SCGI, uwsgi 서비스에서 반환된 응답을 캐시할 수 있습니다.
NGINX Plus는 cache purging에 대한 지원과 실시간 활동 모니터링 대시보드에서 캐시 상태를 더욱 풍부하게 시각화할 수 있는 기능을 추가하여 NGINX 오픈 소스의 콘텐츠 캐싱 기능을 확장합니다.
목차
1. 콘텐츠 캐싱 을 사용하는 이유
2. 자세히 알아보기 – NGINX Plus를 사용한 콘텐츠 캐싱
3. 캐시 계측
4. 오래된 콘텐츠 관리
5. 캐시에서 콘텐츠 삭제
6. 추가 정보
1. 콘텐츠 캐싱 을 사용하는 이유
콘텐츠 캐싱 은 웹 페이지의 로드 시간을 개선하고, 업스트림 서버의 부하를 줄이며, Origin 서버에 장애가 발생한 경우 캐시된 콘텐츠를 백업으로 사용하여 가용성을 향상시킵니다:
- 사이트 성능 향상 – NGINX Plus는 모든 유형의 캐시 콘텐츠를 정적 콘텐츠와 동일한 속도로 제공하므로 지연 시간이 단축되고 웹사이트 응답성이 향상됩니다.
- 용량 증가 – NGINX Plus는 Origin 서버에서 반복적인 작업을 offload하여 더 많은 사용자에게 서비스를 제공하고 더 많은 애플리케이션을 실행할 수 있는 용량을 확보합니다.
- 가용성 향상 – Origin 서버가 다운되었을 때 캐시된 콘텐츠(오래된 콘텐츠일지라도)를 제공하여 사용자가 치명적인 오류를 격지 않도록 보호합니다.
NGINX Plus와 NGINX는 웹 인프라를 위한 통합 솔루션을 제공하여 Origin 콘텐츠를 위한 HTTP 서버, FastCGI 및 기타 프로토콜을 위한 애플리케이션 Gateway, 업스트림 서버를 위한 HTTP 프록시를 함께 제공합니다. NGINX Plus는 엔터프라이즈급 애플리케이션 로드 밸런싱을 추가하여 웹 인프라의 프론트엔드 로드 밸런서를 통합합니다.
2. 자세히 알아보기 – NGINX Plus를 사용한 콘텐츠 캐싱
캐시된 콘텐츠는 디스크의 영구 캐시에 저장되며, 원본 콘텐츠와 똑같은 방식으로 NGINX Plus 및 NGINX에서 제공됩니다.
콘텐츠 캐싱 을 사용하려면 구성에 proxy_cache_path 및 proxy_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 요청에 의해 검색된 콘텐츠를 캐시하며, 캐시 기간은 Origin 서버 헤더(X-Accel-Expires, Cache-Control 및 Expires)에 의해 정의됩니다. NGINX Plus는 RFC 5861에 정의된 Cache-Control 확장 기능인 stale-while-revalidate 및 stale-if-error를 준수합니다.
이러한 각 동작은 다양한 지시문을 사용하여 확장하고 미세 조정할 수 있습니다. 종합적인 소개는 NGINX Plus 관리자 가이드를 참조하세요.
3. 캐시 계측
NGINX Plus의 실시간 활동 모니터링 API는 콘텐츠 캐시의 활용도와 효과를 측정하는 데 사용할 수 있는 다양한 통계를 보고합니다:
Live activity monitoring API의 JSON 데이터 샘플
JSON 데이터에는 캐시 활동에 대한 전체 정보가 포함되어 있습니다.
4. 오래된 콘텐츠 관리
기본적으로 NGINX Plus와 NGINX는 캐시된 콘텐츠가 유효한 기간 동안 제공합니다. 유효 기간은 구성하거나 Origin 서버에서 설정한 Cache-Control 헤더로 제어할 수 있습니다. 유효 기간이 지나면 캐시된 콘텐츠는 오래된 것으로 간주되며, 캐시된 콘텐츠가 Origin 서버에서 찾은 콘텐츠와 동일한지 확인하여 다시 유효성을 검사해야 합니다.
오래된 콘텐츠는 클라이언트가 요청하지 않을 수 있으므로 NGINX Plus와 NGINX는 클라이언트가 요청할 때만 오래된 콘텐츠의 유효성을 재검증합니다. 이 작업은 오래된 콘텐츠를 즉시 제공함으로써 클라이언트 요청을 중단하거나 지연시키지 않고 백그라운드에서 수행될 수 있습니다. 또한 Origin 서버를 사용할 수 없을 때에도 오래된 콘텐츠가 제공되므로 부하가 폭주하거나 원본 서버가 장기간 중단되는 경우에도 고가용성을 제공합니다.
NGINX 및 NGINX Plus가 오래된 콘텐츠를 제공하는 조건은 지시문을 사용하여 구성하거나 Origin 서버의 Cache-Control 헤더, stale-while-revalidate 및 stale-if-error에서 찾은 값을 적용하여 구성할 수 있습니다.
5. 캐시에서 콘텐츠 삭제
콘텐츠 캐싱 의 부작용 중 하나는 Origin 서버의 콘텐츠 업데이트가 캐시로 즉시 전파되지 않아 클라이언트에 일정 기간 동안 이전 콘텐츠가 계속 제공될 수 있다는 것입니다. 업데이트 작업으로 여러 리소스가 동시에 변경되는 경우(예: CSS 파일 및 참조 이미지 변경), 클라이언트에 오래된 리소스와 최신 리소스가 혼합되어 일관성 없는 프레젠테이션이 제공될 수 있습니다.
NGINX Plus의 캐시 Cache Purging 기능을 사용하면 이 문제를 쉽게 해결할 수 있습니다. 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 stem을 가진 전체 리소스 집합을 제거할 수 있습니다.
6. 추가 정보
NGINX Plus는 NGINX의 모든 캐싱 기능을 상속합니다. 자세한 내용은 NGINX Plus 관리자 가이드 및 참조 문서를 참조하세요
NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 논의하십시오.
댓글을 달려면 로그인해야 합니다.