갱동구리

Be brave.

[nginx] NGINX Content Caching

업데이트:     Updated:

카테고리:

태그:

NGINX Content Caching

캐싱을 이용하면 프록시된 웹 및 애플리케이션 서버에서 정적 및 동적 콘텐츠를 모두 캐싱하여 클라이언트로의 전달 속도를 높이고 서버의 부하를 줄일 수 있습니다.

NGINX에서 캐싱이 활성화되면 클라이언트 요청에 대한 응답을 디스크 캐시에 저장하고 이를 사용하여 매번 동일한 콘텐츠에 대한 요청을 원 서버에 전달하지 않고도 클라이언트에 응답할 수 있습니다.

ngx_http_proxy_module 모듈을 사용하면 요청을 다른 서버로 전달할 수 있습니다. 즉, NGINX를 proxy 서버로 구성할 수 있습니다.

이후에 나올 대부분의 지시문들은 이 모듈에 포함되어 있습니다.

캐싱 활성화

  • NGINX에서 캐싱을 활성화하려면 최상위 http() 컨텍스트에 proxy_cache_path 지시문을 사용합니다.
  • proxy_cache_path 지시문의 필수 첫 번째 매개변수는 캐시된 콘텐츠가 저장될 로컬 파일시스템 경로입니다.
  • 두 번째 필수 매개변수는 keys_zone으로 캐시된 항목에 대한 메타데이터를 저장하는 데 사용되는 공유 메모리 영역의 이름과 크기를 정의합니다. 
    http {
  # ...
  proxy_cache_path /data/nginx/chche keys_zone=mycache:10m;
}
  • proxy_cache_path를 지정했다면 원 서버 응답을 캐시하려는 server 또는 location 컨텍스트에 proxy_cache 지시문을 포함시킵니다. (이때 ‘mycache’는 proxy_cache_path 지시문의 keys_zone 매개변수로 정의된 이름입니다.) 
    http {
  # ...
  proxy_cache_path /data/nginx/cache keys_zone=mycache:10m;
  server {
      proxy_cache mycache;
      location / {
          proxy_pass http://127.0.0.1:8080;
      }
  }
}

Note: 매개변수로 정의된 keys_zone는 캐시된 응답 데이터의 총량을 제한하지 않습니다. 캐시된 응답 자체는 파일 시스템의 특정 파일에 메타데이터 사본과 함께 저장됩니다. 캐시된 응답 데이터의 양을 제한하려면 proxy_cache_path 지시문에 max_size 매개변수를 포함시켜야합니다. (그러나 캐시된 데이터의 양은 일시적으로 max_size 제한을 초과할 수 있습니다.)

캐싱과 관련된 NGINX 프로세스

캐싱과 관련된 두 가지 추가 NGINX 프로세스가 있습니다.

  • 캐시 관리자는 캐시 상태를 확인하기 위해 주기적으로 활성화됩니다. 캐시 크기가 max_size 매개변수로 설정된 제한을 초과하면 캐시 관리자는 가장 최근에 액세스한 데이터를 제거합니다. 이떄 캐시 관리자 활성화 주기 사이에 캐시 데이터의 양은 일시적으로 max_size 크기를 초과할 수 있습닌다.
  • 캐시 로더는 NGINX가 시작된 직후에 한 번만 실행됩니다. 이전에 캐시된 데이터에 대한 메타데이터를 공유 메모리에 로드할 때 전체 캐시를 한 번에 로드하면 시작 후 처음 몇 분 동안 NGINX 성능을 저하시킬 수 있습니다. 이를 방지하려면 proxy_cache_path 지시문에 다음 매개변수를 포함하여 캐시의 반복 로드를 구성합니다.
    • loader_threshold - 반복 지속시간 (밀리초 기본값은 200)
    • loader_files - 한 반복 동안 로드되는 최대 항목 수 (기본 값 100)
    • loader_sleeps - 반복 사이의 지연 (밀리초 기본값 50)

캐시할 요청 지정

  • 기본적으로 NGINX는 HTTP GET 및 HEAD 요청에 대한 모든 응답을 캐시합니다.
  • 요청에 대한 키로 NGINX는 요청 문자열을 사용합니다. 요청에 캐시된 응답과 동일한 키가 있는 경우 캐시된 응답을 클라이언트에게 보냅니다.
  • http{}, server{}, location{} 컨텍스트에 다양한 지시문을 포함하여 캐시되는 응답을 제어할 수 있습니다.
  • 요청에 대한 매칭 키를 변경하려면 proxy_cache_key 지시문을 사용합니다. 
    proxy_cache_key "$host$request_uri$cookie_user";
  • 응답이 캐시되기 위해 동일한 키를 사용하여 요청한 최소 횟수를 정의하려면 proxy_cache_min_users 지시문을 사용합니다. 
    proxy_cache_min_uses 5;
  • GET 및 HEAD 메서드외의 요청에 대한 응답을 캐시하려면 proxy_cache_methods 지시문을 사용합니다. 
    proxy_cache_methods GET HEAD POST;

캐싱 제한

  • 기본적으로 캐시된 응답은 무기한 남아 있습니다. 캐시가 구성된 최대 크기를 초과하는 경우에만 제거되며 마지막으로 요청된 이후 시간 순서대로 제거됩니다.
  • http{}, server{}, location{} 컨텍스트에 지시문(proxy_cache_valid)을 포함하여 캐시된 응답이 유효한 것으로 간주되는 기간을 설정할 수 있습니다.
  • 특정 상태 코드가 있는 캐시된 응답이 유효한 것으로 간주되는 기간을 제한하려면 proxy_cache_valid 지시문을 사용합니다. 
    proxy_cache_valid 200 302 10m;
proxy_cache_valid 404      1m;
  • 이 예에서 200, 302 상태 코드의 응답은 10분 동안 유효하며, 404 코드 응답은 1분 동안 유효합니다. 만약 모든 상태 코드가 포함된 응답의 유효 시간을 지정하려면 첫 매개변수로 any를 사용합니다. 
    proxy_cache_valid any 5m;

캐시에서 콘텐츠 제거

  • NGINX 에서 오래된 캐시 파일을 제거하기 위해 사용자 지정 HTTP 헤더 또는 PURGE 메서드를 이용할 수 있습니다.

캐시 제거 구성

  • PURGE HTTP 메서드를 사용하는 요청을 식별하고 일치하는 URL에서 cache를 삭제하는 구성을 설정 해보겠습니다
    1. http{} 컨텍스트에서 변수(nginx 환경변수: $request_method)에 따라 달라지는 새 변수($purge_method)를 만듭니다. 
      http {
 # ...
 map $request_method $purge_method {
     PURGE 1;
     default 0;
 }
}
    2. 캐싱이 구성된 location{} 블록에서 캐시 제거 요청에 대한 조건을 지정하는 proxy_cache_purge 지시문을 사용합니다. 
      server {
 listen      80;
 server_name www.example.com;

 location / {
     proxy_pass  http://127.0.0.1:8080;
     proxy_cache mycache;

     proxy_cache_purge $purge_method;
 }
}

Note: proxy_cache_purge Not (0 or “”) - 캐시 제거

참고: http_map_module

  • ngx_http_map_module 모듈은 값이 다른 변수의 값에 따라 달라지는 변수를 생성합니다.
  • default value는 특수한 매개 변수로 소스 값이 지정된 context와 일치하지 않는 경우 기본값을 설정합니다. 만약 default가 지정되지 않았다면 기본값은 빈 문자열입니다.
  • 기본 문법은 아래의 코드를 참고하십시오. 
    map string $variable {
  default value;
  context value;
}

제거 명령 보내기

  • proxy_cache_purge 구성이 완료되면 캐시를 제거하기 위해 특별한 캐시 제거 요청을 보내야 합니다. curl은 다음 예제와 같은 명령을 포함하여 제거 요청을 실행할 수 있습니다. 
    curl -X PURGE -D - "https://www.example.com/*"
  • 그러나 와일드카드로 지정된 캐시 항목은 캐시에서 완전히 제거되지 않을 수 있습니다. 이에 대해서는 NGINX Doc을 참고하시기 바랍니다.

제거 명령에 대한 액세스 제한

  • 캐시 제거 요청을 보낼 수 있는 IP 주소의 수를 제한하는 것이 좋습니다. 
    geo $purge_allowed {
  default         0;  # deny from other
  10.0.0.1        1;  # allow from 10.0.0.1 address
  192.168.0.0/24  1;  # allow from 192.168.0.0/24
}  
map $request_method $purge_method {
  PURGE   $purge_allowed;
  default 0;
}

참고: http_geo_moudle

  • ngx_http_geo_module 모듈은 클라이언트 IP 주소에 따라 값이 있는 변수를 생성합니다.
  • default value는 특수한 매개변수로 클라이언트 주소가 context에 지정한 주소와 일치하지 않는 경우 기본값을 설정합니다. CIDR 표기법으로 주소를 지정하는 경우 “0.0.0.0/0”, “::/0”을 대신 사용할 수 있습니다. 만약 default가 지정되지 않았다면 default 기본값은 빈 문자열입니다.
  • 기본 문법은 아래의 코드를 참고하십시오. 
    geo [$address] $variable {
  default value;
  context value;
}

캐시 제거 구성 예

http {
    # ...
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=mycache:10m purger=on;
    #purger=on이 궁금하다면 https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/ 해당링크를 참고하세요.

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

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

        location / {
            proxy_pass        https://localhost:8002;
            proxy_cache       mycache;
            proxy_cache_purge $purge_method;
        }
    }

    geo $purge_allowed {
       default         0;
       10.0.0.1        1;
       192.168.0.0/24  1;
    }

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

캐시 상태 확인

  • add_header 지시문을 통해 NGINX 에서 응답 캐시에 액세스한 상태를 확인하여 응답할 수 있습니다. 
    add_header X-Cache-Status $upstream_cache_status;
  • 다음은 $upstream_cache_status 에서 가질 수 있는 값을 나열합니다.
    • MISS - 캐시에서 응답을 찾을 수 없으므로 원본 서버에서 가져왔습니다. 그후 응답이 캐시되었을 수 있습니다.
    • BYPASSproxy_cache_bypass - 요청이 bypass 지시문과 일치하기 때문에 캐시에서 제공되는 대신 원본 서버에서 응답을 가져왔습니다. 그후 응답이 캐시되었을 수 있습니다.
    • EXPIRED - 캐시의 항목이 만료되었습니다. 응답에는 원본 서버의 새로운 콘텐츠가 포함되어 있습니다.
    • STALE - 원본 서버가 올바르게 응답하지 않고 proxy_cache_use_stale 구성되어 콘텐츠가 오래되었습니다.
    • UPDATING - 이전 요청에 대한 응답으로 항목이 현재 업데이트 중이고 proxy_cache_use_stale update가 구성되어 있으므로 콘텐츠가 오래되었습니다.
    • REVALIDATED - proxy_cache_revalidate 지시문이 활성화되었고 NGINX가 현재 캐시된 콘텐츠가 여전히 유효한지 확인했습니다.
    • HIT - 응답에는 캐시에서 직접 가져온 유효한 최신 콘텐츠가 포함되어 있습니다.

proxy_cahce_bypass

  • NGINX가 클라이언트에게 캐시된 응답을 보내지 않는 조건을 정의하려면 proxy_cache_bypass 지시문을 포함합니다.
  • 각 매개변수는 조건을 정의하고 여러 변수로 구성됩니다.
  • 하나 이상의 매개변수가 정의되어 있다면 NGINX는 캐시에서 응답을 조회하지 않고 대신 원 서버에 요청을 즉시 전달합니다. 
    proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;
  • 동일한 지시어로 proxy_no_cache 가 있다.

proxy_cache_use_stale

  • 원 서버와 통신하는 동안 오래된 캐시 응답을 사용할 수 있는 경우를 결정합니다.
  • error 매개변수를 설정하여 요청을 처리할 원 서버가 처리할 수 없는 상태일 경우 오래된 캐시 응답을 사용하도록 허용합니다.
  • updating 매개변수는 현재 업데이트 중인 오래된 캐시 응답의 사용을 허용합니다. 이를 통해 캐시된 데이터를 업데이트할 때 원서버에 대한 액세스 수를 최소화할 수 있습니다.
  • 기본 값은 proxy_cache_use_stale off 입니다. 
    proxy_cache_use_stale error | timeout | invalid_header | updating | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | off ...

proxy_cache_revalidate

  • “If-Modified-Since” 및 “If-None-Match” 헤더 필드가 있는 조건부 요청을 사용하여 만료된 캐시 항목의 재검증을 활성화합니다.
  • 기본 값은 proxy_cache_revalidate off 입니다. 
    proxy_cache_revalidate on | off;

모듈 변수 참고

ngx_http_core_module 임베디드 변수

$arg_name - 요청 줄의 인수 $cookie_name - 쿠키 이름 $request_method - 요청 메서드

📌출처

NGINX Docs

👍 개인 공부 기록용 블로그입니다. 오류나 조언이 있으시면 언제든지 댓글 혹은 메일로 남겨주시면 감사하겠습니다! 😄

맨 위로 이동하기

Nginx 카테고리 내 다른 글 보러가기

댓글남기기

최근 글 10 개 :)