NGINX에서 콘텐츠를 캐시하는 방법
NGINX는 콘텐츠 및 애플리케이션 제공 속도를 높이고 보안을 강화하며 확장성을 향상시키는 통합 오픈 소스 고성능 웹 서버입니다. Nginx의 가장 일반적인 사용 사례 중 하나는 웹사이트 성능을 향상시키는 가장 효과적인 방법인 콘텐츠 캐싱입니다.
추가 읽기: Linux용 최고의 오픈 소스 캐싱 도구 10가지
NGINX를 사용하면 업스트림 서버의 응답을 캐시하고 콘텐츠 전송 네트워크(CDN)용 에지 서버를 생성하도록 구성하여 로컬 원본 서버를 가속화할 수 있습니다. NGINX는 가장 큰 CDN 중 일부를 지원합니다.
캐시로 구성되면 NGINX는 다음을 수행합니다.
- 정적 및 동적 콘텐츠를 캐시합니다.
- 마이크로 캐싱으로 동적 콘텐츠 성능을 향상시킵니다.
- 더 나은 성능을 위해 백그라운드에서 재검증하는 동안 오래된 콘텐츠를 제공합니다.
- Cache-Control 헤더 등을 재정의하거나 설정합니다.
이 문서에서는 웹 서버를 최대한 효율적으로 실행하기 위해 Linux에서 NGINX를 콘텐츠 캐싱으로 구성하는 방법을 알아봅니다.
전제 조건:
Linux 서버에 NGINX가 설치되어 있어야 합니다. 그렇지 않은 경우 다음 가이드에 따라 Nginx를 설치하세요.
- CentOS 8에 Nginx를 설치하는 방법
- CentOS 7에 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 요청을 관리한다는 것입니다. 이것이 없으면 웹서버는 서비스에 대한 모든 클라이언트 요청에 대해 새로운 프로세스(제어하고, 요청을 처리하고, 닫아야 함)를 열어야 합니다.
LEMP 스택 배포에서 PHP 스크립트를 처리하기 위해 NGINX는 FPM(FastCGI 프로세스 관리자) 또는 을 사용합니다. PHP-FPM은 널리 사용되는 대체 PHP FastCGI 구현입니다. PHP-FPM 프로세스가 실행되면 NGINX는 처리를 위해 요청을 프록시하도록 구성됩니다. 따라서 NGINX는 PHP-FPM 백엔드 애플리케이션 서버의 응답을 캐시하도록 구성할 수도 있습니다.
NGINX에서 FastCGI 콘텐츠 캐시는 최상위 http{}의 fastcgi_cache_path라는 지시어를 사용하여 선언됩니다. NGINX 구성 구조 내의 컨텍스트. 캐싱용 키(요청 식별자)를 정의하는 fastcgi_cache_key를 추가할 수도 있습니다.
게다가 업스트림 캐시 상태를 읽으려면 http{} 컨텍스트 내에 add_header X-Cache-Status 지시문을 추가하세요. 이는 디버깅 목적에 유용합니다.
사이트의 서버 블록 구성 파일이 /etc/nginx/conf.d/testapp.conf 또는 /etc/nginx/sites-available/testapp.conf에 있다고 가정합니다( Ubuntu 및 그 파생 버전에서) 편집 파일을 열고 파일 상단에 다음 줄을 추가합니다.
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;
fastcgi_cache_path 지시문은 다음과 같은 매개변수 수를 지정합니다.
- /var/cache/nginx – 캐시의 로컬 디스크 디렉터리 경로입니다.
- 수준 – 캐시의 계층 구조 수준을 정의하며 /var/cache/nginx 아래에 2단계 디렉터리 계층 구조를 설정합니다.
- keys_zone(이름:크기) – 모든 활성 키와 데이터(메타)에 대한 정보가 저장되는 공유 메모리 영역을 생성할 수 있습니다. 키를 메모리에 저장하면 디스크 상태를 확인하지 않고도 NGINX가 MISS 또는 HIT인지 여부를 더 쉽게 결정할 수 있으므로 확인 프로세스 속도가 빨라집니다.
- 비활성 – 지정된 시간 동안 액세스되지 않은 캐시된 데이터가 최신 상태에 관계없이 캐시에서 삭제되기까지의 시간을 지정합니다. 예시 구성에서 60m 값은 60 이후에 액세스되지 않은 파일이 캐시에서 제거된다는 의미입니다.
- max_size – 캐시의 최대 크기를 지정합니다. 여기서 사용할 수 있는 더 많은 매개변수가 있습니다(자세한 내용은 NGINX 설명서를 참조하세요).
fastcgi_cache_key 지시문의 변수는 아래에 설명되어 있습니다.
NGINX는 요청의 키(식별자)를 계산하는 데 이를 사용합니다. 중요한 점은 캐시된 응답을 클라이언트에 보내려면 요청에 캐시된 응답과 동일한 키가 있어야 한다는 것입니다.
- $scheme – 요청 체계, HTTP 또는 HTTPS입니다.
- $request_method – 요청 방법, 일반적으로 "GET " 또는 "POST ".
- $host – 우선 순위에 따라 요청 라인의 호스트 이름, “Host” 요청 헤더 필드의 호스트 이름, 요청과 일치하는 서버 이름일 수 있습니다. .
- $request_uri – 전체 원본 요청 URI(인수 포함)를 의미합니다.
또한 add_header X-Cache-Status 지시문의 $upstream_cache_status 변수는 MISS인지 여부에 관계없이 NGINX가 응답하는 각 요청에 대해 계산됩니다. >(캐시에서 찾을 수 없고 애플리케이션 서버에서 가져온 응답) 또는 HIT(캐시에서 제공되는 응답) 또는 기타 지원되는 값입니다.
다음으로, PHP 요청을 PHP-FPM에 전달하는 location 지시문 내에서 fastcgi_cache 지시문을 사용하여 위에서 정의한 캐시를 활성화합니다.
또한 표시된 대로 fastcgi_cache_valid 지시어를 사용하여 다양한 응답에 대한 캐싱 시간을 설정합니다.
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 60m;
우리의 경우처럼 캐싱 시간만 지정한 경우 200, 301, 302 응답만 캐시됩니다. 그러나 응답을 명시적으로 지정하거나 응답 코드에 대해 any를 사용할 수도 있습니다.
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 캐싱 성능 미세 조정
응답이 캐시되기 전에 동일한 키를 가진 요청이 이루어져야 하는 최소 횟수를 설정하려면 http{} 또는 에 또는 fastcgi_cache_min_uses 지시어를 포함하세요. >서버{}위치{} 컨텍스트.
fastcgi_cache_min_uses 3
"If-Modified-Since" 및 "If-None-Match" 헤더 필드가 있는 조건부 요청을 사용하여 만료된 캐시 항목의 재검증을 활성화하려면 fastcgi_cache_revalidate 지시어, http{}, server{} 또는 location{} 컨텍스트 내.
fastcgi_cache_revalidate on;
위치 지시어 내에서 proxy_cache_use_stale 지시어를 사용하여 원본 서버나 FCGI 서버가 다운되었을 때 캐시된 콘텐츠를 전달하도록 NGINX에 지시할 수도 있습니다.
이 샘플 구성은 NGINX가 업스트림 서버로부터 오류, 시간 초과 및 지정된 오류를 수신하고 캐시된 콘텐츠에 요청된 파일의 오래된 버전이 있는 경우 오래된 파일을 전달한다는 것을 의미합니다.
proxy_cache_use_stale error timeout http_500;
FCGI 캐싱 성능을 미세 조정하는 또 다른 유용한 지시문은 proxy_cache_use_stale 지시문과 함께 작동하는 fastcgi_cache_Background_update입니다. on으로 설정하면 클라이언트가 만료되었거나 업스트림 서버에서 업데이트 중인 파일을 요청할 때 오래된 콘텐츠를 제공하도록 NGINX에 지시합니다.
fastcgi_cache_background_update on;
fastcgi_cache_lock은 여러 클라이언트가 캐시에 없는 동일한 콘텐츠를 요청하는 경우 캐시 성능을 미세 조정하는 데도 유용합니다. NGINX는 첫 번째 요청만 업스트림 서버로 전달하고, 그런 다음 응답은 캐시에서 다른 클라이언트 요청을 처리합니다.
fastcgi_cache_lock on;
NGINX 구성 파일에서 위의 내용을 모두 변경한 후 저장하고 닫습니다. 그런 다음 NGINX 서비스를 다시 시작하기 전에 구문 오류가 있는지 구성 구조를 확인하세요.
nginx -t
systemctl restart nginx
그런 다음, 캐시가 제대로 작동하는지 테스트하고, 다음 컬 명령을 사용하여 웹 애플리케이션이나 사이트에 액세스해 보세요. 처음에는 MISS를 나타내야 하지만 후속 요청에서는 HIT를 나타내야 합니다. 스크린샷에 표시된 대로).
curl -I http://testapp.linux-console.net
다음은 오래된 데이터를 제공하는 NGINX를 보여주는 또 다른 스크린샷입니다.
캐시 우회에 예외 추가
fastcgi_cache_bypass 지시문을 사용하여 NGINX가 캐시된 응답을 클라이언트에 보내지 않아야 하는 조건을 설정할 수 있습니다. 그리고 NGINX가 업스트림 서버의 응답을 전혀 캐시하지 않도록 지시하려면 fastcgi_no_cache를 사용하세요.
예를 들어 POST 요청과 쿼리 문자열이 포함된 URL이 항상 PHP로 이동하도록 하려는 경우입니다. 먼저 조건을 설정하는 if 문을 다음과 같이 선언합니다.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
그런 다음 fastcgi_cache_bypass 및 fastcgi_no_cachePHP-FPM에 전달하는 location 지시문에서 위 예외를 활성화합니다. > 지시문.
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에서 프록시 캐시 활성화
NGINX는 다른 프록시 서버(proxy_pass 지시어로 정의됨)의 응답 캐싱도 지원합니다. 이 테스트 사례에서는 NGINX를 Node.js 웹 애플리케이션의 역방향 프록시로 사용하므로 NGINX를 Node.js 애플리케이션의 캐시로 활성화하겠습니다. 여기에 사용된 모든 구성 지시어는 이전 섹션의 FastCGI 지시어와 의미가 유사하므로 다시 설명하지 않습니다.
프록시 서버의 응답 캐싱을 활성화하려면 최상위 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 성능 향상을 위한 팁.