NGINX에서 콘텐츠 캐싱 방법

튜토리얼

NGINX은 콘텐츠 및 애플리케이션 전달 속도를 높이고 보안을 강화하며 확장성을 향상시키는 통합 오픈 소스 고성능 웹 서버입니다. Nginx의 가장 일반적인 사용 사례 중 하나는 웹 사이트 성능을 향상시키는 가장 효과적인 방법인 콘텐츠 캐싱입니다.

추가로 읽기: Linux용 10대 오픈 소스 캐싱 도구

NGINX를 사용하여 로컬 오리진 서버의 가속화를 할 수 있으며, 업스트림 서버로부터 응답을 캐시하도록 구성하고 콘텐츠 전달 네트워크(CDN)용 엣지 서버를 생성할 수도 있습니다. NGINX는 일부 최대 규모의 CDN을 구동합니다.

캐시로 구성된 경우 NGINX는 다음을 수행할 것입니다:

  • 정적 및 동적 콘텐츠를 캐시합니다.
  • 마이크로 캐싱을 사용하여 동적 콘텐츠 성능을 향상시킵니다.
  • 더 나은 성능을 위해 백그라운드에서 재검증하면서 오래된 콘텐츠를 제공합니다.
  • Cache-Control 헤더를 재정의하거나 설정합니다.

이 문서에서는 Linux에서 NGINX를 콘텐츠 캐싱으로 구성하는 방법을 배우고 웹 서버를 최대한 효율적으로 실행할 수 있습니다.

전제 조건:

Linux 서버에 NGINX가 설치되어 있어야 합니다. 그렇지 않은 경우 Nginx를 설치하는 방법은 다음 가이드를 따르십시오:

Nginx에서 정적 콘텐츠 캐시하기

정적 콘텐츠는 웹 사이트의 페이지 간에 동일한 상태로 유지되는 콘텐츠입니다. 정적 콘텐츠의 예로는 이미지, 비디오, 문서 파일, CSS 파일 및 JavaScript 파일 등이 있습니다.

만약 귀하의 웹 사이트가 많은 정적 콘텐츠를 사용한다면, 브라우저가 정적 콘텐츠의 사본을 저장하여 빠른 액세스를 위한 클라이언트 캐싱을 활성화하여 성능을 최적화할 수 있습니다.

다음의 샘플 구성은 좋은 예시이며, 단지 www.example.com을 귀하의 웹 사이트 이름의 URL로 바꾸고 다른 경로를 적절하게 수정하면 됩니다.

server {
    # substitute your web server's URL for www.example.com
    server_name www.example.com;
    root /var/www/example.com/htdocs;
    index index.php;

    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        try_files $uri =404;
        include fastcgi_params;
        # substitute the socket, or address and port, of your WordPress server
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        #fastcgi_pass 127.0.0.1:9000;
 	}   

    location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
                  |jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
                  |midi|wav|bmp|rtf)$ {
        expires max;
        log_not_found off;
        access_log off;
    }
}

Nginx에서 동적 콘텐츠 캐시하기

NGINX는 로컬 파일 시스템의 어딘가에 위치한 영구 디스크 기반 캐시를 사용합니다. 따라서 캐시된 콘텐츠를 저장할 로컬 디스크 디렉토리를 만들어야 합니다.
# mkdir -p /var/cache/nginx

다음으로, 캐시 디렉토리에 적절한 소유권을 설정하세요. 캐시 디렉토리는 다음과 같이 NGINX 사용자 (nginx)와 그룹 (nginx) 소유해야 합니다.

# chown nginx:nginx /var/cache/nginx

이제 Nginx에서 동적 콘텐츠를 활성화하는 방법을 아래 섹션에서 확인하십시오.

NGINX에서 FastCGI 캐시 활성화하기

FastCGI (또는 FCGI)는 PHP와 같은 대화형 응용 프로그램을 NGINX와 같은 웹 서버와 인터페이스하는 데 널리 사용되는 프로토콜입니다. 이는 CGI (공통 게이트웨이 인터페이스)의 확장입니다.

FCGI의 주요 장점은 하나의 프로세스에서 여러 CGI 요청을 관리한다는 것입니다. 그렇지 않으면, 웹 서버는 서비스를 위한 각 클라이언트 요청마다 새 프로세스를 열어야 합니다(제어되어야 하고, 요청을 처리하고, 닫혀야 함).

PHP 스크립트를 처리하기 위해 LEMP 스택 배포에서, NGINX는 FPM (FastCGI 프로세스 관리자) 또는 PHP-FPM을 사용합니다. 이렇게 하면 PHP-FPM 프로세스가 실행된 후, 처리를 위해 요청을 프록시하는 것으로 NGINX가 구성됩니다. 따라서 NGINX는 또한 PHP-FPM 백엔드 응용 프로그램에서 응답을 캐시하는 방식으로 구성될 수 있습니다.

NGINX에서 FastCGI 콘텐츠 캐시는 NGINX 구성 구조 내의 최상위 http{} 컨텍스트에서 fastcgi_cache_path라는 지시문을 사용하여 선언됩니다. 또한 캐싱을 위한 키(요청 식별자)를 정의하는 fastcgi_cache_key를 추가할 수 있습니다.

게다가 상류 캐시 상태를 읽으려면 add_header X-Cache-Status 지시문을 http{} 컨텍스트 내에 추가하십시오. -이는 디버깅 목적으로 유용합니다.

귀하의 사이트 서버 블록 구성 파일이 /etc/nginx/conf.d/testapp.conf 또는 /etc/nginx/sites-available/testapp.conf에 위치한 경우 (우분투 및 해당 파생품 하에), 편집 파일을 열고 파일 맨 위에 다음 줄을 추가하십시오.

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHEZONE:10m; inactive=60m max_size=40m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache $upstream_cache_status;
Enable FastCGI Cache in NGINX

fastcgi_cache_path 지시문은 다음 매개변수를 지정합니다:

  • /var/cache/nginx – 캐시용 로컬 디스크 디렉터리 경로입니다.
  • levels – 캐시의 계층 수준을 정의하며, /var/cache/nginx 아래 두 수준의 디렉터리 계층을 설정합니다.
  • keys_zone (name:size) – 모든 활성 키와 데이터 정보 (메타)를 저장하는 공유 메모리 영역 생성을 활성화합니다. 키를 메모리에 저장하면 NGINX가 디스크의 상태를 확인하지 않고 MISS 또는 HIT인지를 더 쉽게 결정할 수 있으므로 확인 프로세스가 빨라집니다.
  • inactive
  • max_size – 캐시의 최대 크기를 지정합니다. 여기에 사용할 수 있는 더 많은 매개변수가 있습니다(자세한 정보는 NGINX 문서를 참조하십시오).

fastcgi_cache_key 지시문의 변수는 아래와 같이 설명됩니다.

NGINX는 이들을 요청의 키(식별자)를 계산할 때 사용합니다. 중요한 것은 캐시된 응답을 클라이언트에 보내려면 요청이 캐시된 응답과 동일한 키를 가져야 합니다.

  • $scheme – 요청 스키마, HTTP 또는 HTTPS입니다.
  • $request_method – 요청 메서드, 일반적으로 “GET” 또는 “POST”입니다.
  • $host – 요청 라인에서 호스트 이름이거나 “Host” 요청 헤더 필드에서 호스트 이름이거나 요청과 일치하는 서버 이름을 우선 순위 순으로 사용합니다.
  • $request_uri – 전체 원본 요청 URI(인수와 함께)를 의미합니다.

또한, $upstream_cache_status 변수는 NGINX가 응답하는 각 요청에 대해 계산됩니다. 캐시에서 찾을 수 없는 경우 “MISS” (응답이 응용 프로그램 서버에서 가져옴) 또는 “HIT” (캐시에서 제공된 응답) 또는 기타 지원되는 값 중 하나입니다.

다음으로, PHP 요청을 PHP-FPM으로 전달하는 location 지시문 내에서는 방금 정의한 캐시를 활성화하기 위해 fastcgi_cache 지시문을 사용합니다.

또한 아래와 같이 fastcgi_cache_valid 지시문을 사용하여 다른 응답에 대한 캐싱 시간을 설정합니다.

fastcgi_cache CACHEZONE;
fastcgi_cache_valid  60m;
Define Caching Zone and Time

만약 우리의 경우와 같이 캐싱 시간만 지정된다면, 200, 301, 그리고 302 응답만 캐시됩니다. 하지만 명시적으로 응답을 지정하거나 모든 응답 코드를 사용할 수도 있습니다:

fastcgi_cache CACHEZONE;
fastcgi_cache_valid 200  301 203 60m;
fastcgi_cache_valid 404 10m;
OR
fastcgi_cache CACHEZONE;
fastcgi_cache_valid  any 10m;

Nginx에서 FastCGI 캐싱 성능을 세밀하게 조정하기

동일한 키를 가진 요청이 응답이 캐시되기 전에 발생해야 하는 최소 횟수를 설정하려면 fastcgi_cache_min_uses 지시문을 http{} 또는 server{} 또는 location{} 컨텍스트에 포함시킵니다.

fastcgi_cache_min_uses  3
Set Minimum Cache Usage

만료된 캐시 항목을 조건부 요청을 사용하여 다시 유효성을 검사하려면 “If-Modified-Since” 및 “If-None-Match” 헤더 필드와 함께 fastcgi_cache_revalidate 지시문을 http{} 또는 server{} 또는 location{} 컨텍스트에 추가합니다.

fastcgi_cache_revalidate on;
Set Cache Re-validation

NGINX가 원본 서버 또는 FCGI 서버가 다운되었을 때 캐시된 콘텐츠를 전달하도록 지시하기 위해 location 지시문 내에 proxy_cache_use_stale 지시문을 사용할 수도 있습니다.

이 샘플 구성은 NGINX가 오류, 시간 초과 및 상위 서버로부터 지정된 오류 중 하나를 수신하고 요청된 파일의 캐시된 내용에 오래된 버전이 있을 때, 오래된 파일을 전달합니다.

proxy_cache_use_stale error timeout http_500;
Enable Serving of Stale Data

다른 유용한 지시문은 fastcgi_cache_background_update를 세밀하게 조정하는 것이며, 이는 proxy_cache_use_stale 지시문과 함께 작동합니다. 이를 on으로 설정하면, NGINX에게 만료된 파일이나 상위 서버에서 업데이트 중인 파일을 요청하는 클라이언트에게 오래된 콘텐츠를 제공하도록 지시합니다.

fastcgi_cache_background_update on;
Enable Cache Background Update

fastcgi_cache_lock도 유용합니다. 캐시 성능을 세밀하게 조정하는 데 도움이 됩니다. 캐시에 없는 동일한 콘텐츠를 여러 클라이언트가 요청하는 경우, NGINX는 상위 서버로의 요청을 첫 번째 요청만 전달하고, 응답을 캐시한 후 다른 클라이언트 요청을 캐시에서 제공합니다.

fastcgi_cache_lock on;
Enable Cache Lock

위의 모든 변경 사항을 NGINX 구성 파일에 적용한 후, 저장하고 닫습니다. 그런 다음 NGINX 서비스를 다시 시작하기 전에 구성 구조를 구문 오류를 확인합니다.

# nginx -t
# systemctl restart nginx
Check and Start Nginx Service

다음으로, 캐시가 올바르게 작동하는지 테스트하려면, 다음 curl 명령어를 사용하여 웹 애플리케이션이나 사이트에 액세스해보세요 (첫 번째 요청은 MISS를 나타내어야 하지만, 이후 요청은 스크린샷에 표시된 HIT을 나타내어야 합니다).

# curl -I http://testapp.tecmint.com
Test FastCGI Cache

NGINX가 오래된 데이터를 제공하는 다른 스크린샷이 여기 있습니다.

Test Nginx Serving Stale Data

캐시 우회를 위한 예외 추가

NGINX는 fastcgi_cache_bypass 지시문을 사용하여 캐시된 응답을 클라이언트에 보내지 않을 조건을 설정하는 것이 가능합니다. 그리고 fastcgi_no_cache를 사용하여 업스트림 서버에서의 응답을 전혀 캐시하지 않도록 NGINX에 지시할 수 있습니다.

예를 들어, POST 요청 및 쿼리 문자열이 있는 URL이 항상 PHP로 전송되도록 하려면, 다음과 같이 조건을 설정하는 if 문을 먼저 선언하세요.

set $skip_cache 0; 
if ($request_method = POST) { 
	set $skip_cache 1; 
}

그런 다음 location 지시문에서 fastcgi_cache_bypass 및 fastcgi_no_cache 지시문을 사용하여 PHP 요청을 PHP-FPM으로 전달할 때 위의 예외를 활성화하세요.

 
fastcgi_cache_bypass $skip_cache; 
fastcgi_no_cache $skip_cache;

콘텐츠 캐싱을 활성화하고 싶지 않은 사이트의 다른 부분도 많을 수 있습니다. 다음은 nginx.com 블로그에서 제공하는 WordPress 사이트의 성능을 향상시키기 위한 NGINX 구성 예제입니다.

환경에 있는 내용(도메인, 경로, 파일 이름 등)을 반영하도록 변경하여 사용하세요.

fastcgi_cache_path /var/run/NGINX-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m; 
fastcgi_cache_key "$scheme$request_method$host$request_uri"; 
server { 
	server_name example.com www.example.com; 
	root /var/www/example.com; 
	index index.php; 
	access_log /var/log/NGINX/example.com.access.log; 
	error_log /var/log/NGINX/example.com.error.log; 
	set $skip_cache 0; 
	# POST requests and URLs with a query string should always go to PHP 	
	if ($request_method = POST) { 
		set $skip_cache 1; 
	} 
	if ($query_string != "") {
		set $skip_cache 1; 
	} 
	# Don't cache URIs containing the following segments 
	if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php |sitemap(_index)?.xml") { 
		set $skip_cache 1; 
	} 
	# Don't use the cache for logged-in users or recent commenters 
	if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass |wordpress_no_cache|wordpress_logged_in") {
		set $skip_cache 1; 
	} 
	location / { 
		try_files $uri $uri/ /index.php?$args; 
	} 
	location ~ .php$ { 
		try_files $uri /index.php; 
		include fastcgi_params; 
		fastcgi_pass unix:/var/run/php5-fpm.sock; 
		fastcgi_cache_bypass $skip_cache; 
		fastcgi_no_cache $skip_cache; 
		fastcgi_cache WORDPRESS; 
		fastcgi_cache_valid 60m; 
	} 
	location ~ /purge(/.*) {
		fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1"; 
	} 
	location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg |gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi |wav|bmp|rtf)$ { 
		access_log off; 
		log_not_found off; 
		expires max; 
	} 
	location = /robots.txt { 
		access_log off; 
		log_not_found off; 
	}
	location ~ /. { 
		deny all; 
		access_log off; 
		log_not_found off; 
	} 
}

NGINX에서 Proxy Cache 활성화하기

NGINX는 또한 proxy_pass 지시문에 정의된 다른 프록시 서버로부터의 응답을 캐싱하는 것을 지원합니다. 이 테스트 케이스에서는 NGINX를 Node.js 웹 애플리케이션의 리버스 프록시로 사용하므로, Node.js 애플리케이션을 위한 NGINX 캐시를 활성화할 것입니다. 여기에서 사용된 모든 구성 지시문은 이전 섹션의 FastCGI 지시문과 유사한 의미를 가지고 있으므로 다시 설명하지는 않겠습니다.

proxied 서버에서의 응답 캐싱을 활성화하려면 최상위 http{} 컨텍스트에 proxy_cache_path 지시문을 포함하십시오. 요청이 어떻게 캐시되는지 지정하려면 다음과 같이 proxy_cache_key 지시문도 추가할 수 있습니다.

proxy_cache_path /var/cache/nginx app1 keys_zone=PROXYCACHE:100m inactive=60m max_size=500m;
proxy_cache_key  "$scheme$request_method$host$request_uri";
add_header X-Cache-Status $upstream_cache_status;
proxy_cache_min_uses 3;

다음으로 위치 지시문에서 캐시를 활성화하십시오.

location / {
	proxy_pass http://127.0.0.1:3000;
	proxy_cache        PROXYCACHE;
	proxy_cache_valid 200 302 10m;
	proxy_cache_valid 404      1m;
}

NGINX가 캐시된 콘텐츠를 보내지 않고 상위 서버에서 응답을 전혀 캐시하지 않는 조건을 정의하려면 proxy_cache_bypass와 proxy_no_cache를 포함하십시오.

 
proxy_cache_bypass  $cookie_nocache $arg_nocache$arg_comment;
proxy_no_cache        $http_pragma $http_authorization;

프록시 캐시 성능을 세부 조정하기

다음 지시문들은 프록시 캐시의 성능을 세부 조정하는 데 유용합니다. 또한 FastCGI 지시문들과 같은 의미를 갖습니다.

proxy_cache_min_uses 3;
proxy_cache_revalidate on;
proxy_cache_use_stale error timeout updating http_500;
proxy_cache_background_update on;
proxy_cache_lock on;

더 많은 정보 및 캐싱 구성 지시문에 대해서는 두 가지 주요 모듈 ngx_http_fastcgi_module와 ngx_http_proxy_module의 문서를 참조하십시오.

추가 자료: NGINX 콘텐츠 캐싱 및 WordPress 성능 향상 팁.

Source:
https://www.tecmint.com/cache-content-with-nginx/