NGINX 및 NGINX Plus를 활용한 캐싱 가이드

Faisal Memon소프트웨어 엔지니어

애플리케이션과 웹사이트의 성능이 성공을 좌우하는 핵심 요소라는 사실은 누구나 알고 있습니다. 하지만 애플리케이션이나 웹사이트의 성능을 개선하는 방법이 항상 명확한 것은 아닙니다. 물론 코드 품질과 인프라도 중요하지만, 많은 경우 몇 가지 매우 기본적인 애플리케이션 전송 기법에 집중하는 것만으로도 애플리케이션의 최종 사용자 경험을 크게 개선할 수 있습니다. 애플리케이션 스택에서 캐싱을 구현하고 최적화하는 것이 그 한 가지 예입니다. 이 블로그 게시물에서는 초보 사용자와 고급 사용자 모두가 NGINX 및 NGINX Plus에 포함된 콘텐츠 캐시 기능을 활용하여 성능을 향상하는 데 도움이 되는 기법을 다룹니다.

개요

콘텐츠 캐시는 클라이언트와 ‘오리진 서버’ 사이에 위치하며, 전달되는 모든 콘텐츠의 사본을 저장합니다. 클라이언트가 캐시에 저장된 콘텐츠를 요청하면 오리진 서버에 접속하지 않고 해당 콘텐츠를 바로 반환합니다. 콘텐츠 캐시가 클라이언트와 더 가까운 곳에 있어 성능이 향상되며, 애플리케이션 서버가 매번 페이지를 처음부터 생성할 필요가 없으므로 서버 리소스를 더욱 효율적으로 사용할 수 있습니다.

웹 브라우저와 애플리케이션 서버 사이에는 클라이언트의 브라우저 캐시, 중간 캐시, 콘텐츠 전송 네트워크(CDN), 그리고 애플리케이션 서버 앞에 위치한 로드 밸런서 또는 리버스 프록시 등 여러 캐시가 존재할 수 있습니다. 리버스 프록시나 로드 밸런서 수준에서 캐싱하는 것만으로도 성능을 크게 향상시킬 수 있습니다.

예를 들어, 작년에 로딩 속도가 느린 웹사이트의 성능을 최적화하는 작업을 맡았습니다. 가장 먼저 눈에 띈 점 중 하나는 메인 홈페이지를 생성하는 데 1초 이상 걸린다는 것이었습니다. 디버깅을 진행한 결과, 해당 페이지가 캐시할 수 없도록 설정되어 있어 요청이 들어올 때마다 동적으로 생성되고 있다는 사실을 발견했습니다. 페이지 자체는 자주 변경되지 않았고 개인화된 콘텐츠도 아니었기 때문에 그럴 필요가 없었습니다. 시험 삼아 로드 밸런서가 홈페이지를 5초 동안 캐시하도록 설정했는데, 이것만으로도 눈에 띄는 개선 효과가 나타났습니다. 첫 바이트 수신 시간은 몇 밀리초로 줄었고, 페이지도 확연히 더 빠르게 로드되었습니다.

NGINX는 일반적으로 애플리케이션 스택에서 리버스 프록시 또는 로드 밸런서로 배포되며, 완전한 캐싱 기능 세트를 제공합니다. 다음 섹션에서는 NGINX에서 기본 캐싱을 구성하는 방법을 설명합니다.

기본 캐싱 설정 및 구성 방법

기본 캐싱을 활성화하는 데 필요한 지시어는 두 가지뿐입니다. proxy_cache_path와 proxy_cache입니다. proxy_cache_path 지시어는 캐시의 경로와 구성을 설정하고, proxy_cache 지시어는 캐시를 활성화합니다.

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g                  inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

The parameters to the proxy_cache_path 지시문의 매개변수는 다음 설정을 정의합니다:

• 캐시가 저장되는 로컬 디스크 디렉터리는 /path/to/cache/입니다.
• levels는 /path/to/cache/ 아래에 2단계 디렉터리 계층 구조를 설정합니다. 하나의 디렉터리에 파일이 너무 많으면 파일 액세스 속도가 느려질 수 있으므로 대부분의 배포 환경에서는 2단계 디렉터리 계층 구조를 사용하는 것이 좋습니다. levels 매개변수를 지정하지 않으면 NGINX는 모든 파일을 동일한 디렉터리에 저장합니다.
• keys_zone은 캐시 키와 사용 타이머 등의 메타데이터를 저장하기 위한 공유 메모리 영역을 설정합니다. 키의 복사본을 메모리에 보관하면 NGINX가 디스크에 액세스하지 않고도 요청이 HIT인지 MISS인지 빠르게 판단할 수 있어 확인 속도가 크게 향상됩니다. 1MB 영역에는 약 8,000개의 키에 대한 데이터를 저장할 수 있으므로, 예제에서 구성한 10MB 영역에는 약 80,000개의 키에 대한 데이터를 저장할 수 있습니다.
• max_size는 캐시 크기의 상한을 설정합니다(이 예에서는 10GB). 이 항목은 선택 사항이며, 값을 지정하지 않으면 사용 가능한 디스크 공간을 모두 사용할 때까지 캐시가 커질 수 있습니다. 캐시 크기가 제한에 도달하면 캐시 관리자라는 프로세스가 가장 오랫동안 사용되지 않은 파일을 제거하여 캐시 크기를 다시 제한 이하로 줄입니다.
• inactive는 항목이 액세스되지 않은 상태로 캐시에 유지될 수 있는 기간을 지정합니다. 이 예에서는 60분 동안 요청되지 않은 파일이 만료 여부와 관계없이 캐시 관리자 프로세스에 의해 캐시에서 자동으로 삭제됩니다. 기본값은 10분입니다(10m). 비활성 콘텐츠는 만료된 콘텐츠와 다릅니다. NGINX는 캐시 제어 헤더에 따라 만료된 콘텐츠를 자동으로 삭제하지 않습니다(예: Cache-Control:max-age=120). 만료된(오래된) 콘텐츠는 inactive에 지정된 기간 동안 액세스되지 않은 경우에만 삭제됩니다. 만료된 콘텐츠에 액세스하면 NGINX는 원본 서버에서 해당 콘텐츠를 새로 가져오고 inactive 타이머를 재설정합니다.
• NGINX는 먼저 캐시에 저장할 파일을 임시 저장 영역에 기록하며, use_temp_path=off 지시어는 해당 파일을 캐시될 디렉터리와 동일한 디렉터리에 기록하도록 NGINX에 지시합니다. 파일 시스템 간에 불필요하게 데이터가 복사되는 것을 방지하려면 이 매개 변수를 off로 설정하는 것이 좋습니다. use_temp_path는 NGINX 버전 1.7.10 및 NGINX Plus R6에서 도입되었습니다.

마지막으로 proxy_cache 지시문은 상위 location 블록의 URL과 일치하는 모든 콘텐츠(이 예에서는 /)의 캐싱을 활성화합니다. 또한 proxy_cache 지시문을 server 블록에 포함할 수도 있습니다. 이 경우 자체 proxy_cache 지시문이 없는 해당 서버의 모든 location 블록에 적용됩니다.

원본 서버가 다운되었을 때 캐시된 콘텐츠 제공

NGINX 콘텐츠 캐싱의 강력한 기능 중 하나는 오리진 서버에서 최신 콘텐츠를 가져올 수 없을 때 캐시의 오래된 콘텐츠를 제공하도록 NGINX를 구성할 수 있다는 것입니다. 캐시된 리소스의 모든 오리진 서버가 다운되었거나 일시적으로 사용량이 많은 경우 이런 상황이 발생할 수 있습니다. NGINX는 오류를 클라이언트에 전달하는 대신 캐시에 저장된 파일의 오래된 버전을 제공합니다. 이를 통해 NGINX가 프록시하는 서버에 추가적인 내결함성을 제공하고, 서버 장애나 트래픽 급증 시에도 가동 시간을 보장할 수 있습니다. 이 기능을 활성화하려면 proxy_cache_use_stale 지시어를 포함합니다:

location / {    # ...
    proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
}

이 샘플 구성에서는 NGINX가 오리진 서버로부터 오류, 시간 초과, 또는 지정된 5xx 오류 중 하나를 수신하고 요청된 파일의 만료된 버전이 캐시에 있는 경우, 클라이언트에 오류를 전달하는 대신 만료된 파일을 제공합니다.

캐시 세부 조정 및 성능 개선

NGINX에는 캐시 성능을 세밀하게 조정할 수 있는 다양한 선택적 설정이 있습니다. 다음은 그중 몇 가지를 활성화하는 예입니다:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g                  inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 3;
        proxy_cache_use_stale error timeout updating http_500 http_502
                              http_503 http_504;
        proxy_cache_background_update on;
        proxy_cache_lock on;

        proxy_pass http://my_upstream;
    }
}

이 지시어들은 다음과 같은 동작을 구성합니다:

• proxy_cache_revalidate는 NGINX가 원본 서버의 콘텐츠를 새로 고칠 때 조건부 GET 요청을 사용하도록 지시합니다. 클라이언트가 캐시되어 있지만 캐시 제어 헤더에 정의된 대로 만료된 항목을 요청하면 NGINX는 원본 서버로 보내는 If-Modified-Since 필드를 GET 요청의 헤더에 포함합니다. 이렇게 하면 서버는 NGINX가 해당 파일을 처음 캐시할 때 파일에 첨부된 Last-Modified 헤더에 기록된 시점 이후 파일이 수정된 경우에만 전체 항목을 전송하므로 대역폭을 절약할 수 있습니다.
• proxy_cache_min_uses는 NGINX가 항목을 캐시하기 전에 클라이언트가 해당 항목을 요청해야 하는 횟수를 설정합니다. 가장 자주 액세스되는 항목만 캐시에 추가되도록 하므로 캐시가 계속 가득 차는 경우에 유용합니다. 기본적으로 proxy_cache_min_uses는 1로 설정됩니다.
• The updating 매개변수를 proxy_cache_use_stale 지시문에 지정하고 proxy_cache_background_update 지시문을 활성화하면, 클라이언트가 만료되었거나 원본 서버에서 업데이트 중인 항목을 요청할 때 NGINX가 오래된 콘텐츠를 제공하도록 설정할 수 있습니다. 모든 업데이트는 백그라운드에서 수행됩니다. 업데이트된 파일의 다운로드가 완료될 때까지 모든 요청에 오래된 파일이 반환됩니다.
• With proxy_cache_lock을 사용하도록 설정한 상태에서 여러 클라이언트가 캐시에 최신 상태로 저장되어 있지 않은 파일을 요청하면(MISS), 해당 요청 중 첫 번째 요청만 오리진 서버로 전달됩니다. 나머지 요청은 첫 번째 요청이 처리될 때까지 기다린 후 캐시에서 파일을 가져옵니다. proxy_cache_lock을 사용하도록 설정하지 않으면 캐시 미스가 발생한 모든 요청이 오리진 서버로 바로 전달됩니다.

여러 하드 드라이브에 캐시 분산하기

하드 드라이브가 여러 개 있는 경우 NGINX를 사용하여 캐시를 여러 드라이브에 분산할 수 있습니다. 다음은 요청 URI를 기준으로 클라이언트를 두 개의 하드 드라이브에 균등하게 분산하는 예입니다:

proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m                 max_size=10g inactive=60m use_temp_path=off;
proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m
                 max_size=10g inactive=60m use_temp_path=off;

split_clients $request_uri $my_cache {
              50%          “my_cache_hdd1”;
              50%          “my_cache_hdd2”;
}

server {
    # ...
    location / {
        proxy_cache $my_cache;
        proxy_pass http://my_upstream;
    }
}

두 개의 proxy_cache_path 지시문은 서로 다른 두 하드 드라이브에 두 개의 캐시(my_cache_hdd1 및 my_cache_hdd2)를 정의합니다. split_clients 구성 블록은 요청의 절반(50%)에 대한 결과를 my_cache_hdd1에 캐시하고 나머지 절반은 my_cache_hdd2에 캐시하도록 지정합니다. $request_uri 변수(요청 URI)를 기반으로 한 해시가 각 요청에 사용할 캐시를 결정하므로, 특정 URI에 대한 요청은 항상 동일한 캐시에 저장됩니다.

이 접근 방식은 RAID 하드 드라이브 구성을 대체할 수 없다는 점에 유의하세요. 하드 드라이브에 장애가 발생하면 시스템이 예측할 수 없는 방식으로 동작할 수 있으며, 장애가 발생한 하드 드라이브로 전달된 요청에 대해 사용자에게 500 응답 코드가 표시될 수도 있습니다. 적절한 RAID 하드 드라이브 구성은 하드 드라이브 장애에 대응할 수 있습니다.

자주 묻는 질문(FAQ)

이 섹션에서는 NGINX 콘텐츠 캐싱에 관해 자주 묻는 질문에 답변합니다.

NGINX 캐시를 계측할 수 있나요?

예, add_header 지시어를 사용하면 됩니다:

add_header X-Cache-Status $upstream_cache_status;

이 예제에서는 클라이언트에 대한 응답에 X-Cache-Status HTTP 헤더를 추가합니다. $upstream_cache_status에 사용할 수 있는 값은 다음과 같습니다:

• MISS – 응답을 캐시에서 찾을 수 없어 원본 서버에서 가져왔습니다. 이후 응답이 캐시되었을 수 있습니다.
• BYPASS – 요청이 proxy_cache_bypass 지시문과 일치했기 때문에 응답이 캐시에서 제공되지 않고 원본 서버에서 가져와졌습니다(아래의 캐시에 예외를 설정할 수 있나요? 참조). 이후 응답이 캐시되었을 수도 있습니다.
• EXPIRED – 캐시의 항목이 만료되었습니다. 응답에는 원본 서버에서 가져온 최신 콘텐츠가 포함되어 있습니다.
• STALE – 원본 서버가 올바르게 응답하지 않고 proxy_cache_use_stale이 구성되어 있어 콘텐츠가 오래된 상태입니다.
• UPDATING – 이전 요청에 대한 응답으로 현재 항목이 업데이트되고 있어 콘텐츠가 오래된 상태이며, proxy_cache_use_stale updating이 구성되어 있습니다.
• REVALIDATED – proxy_cache_revalidate 지시어가 활성화되어 있었으며, NGINX는 현재 캐시된 콘텐츠가 여전히 유효한지 확인했습니다(If-Modified-Since 또는 If-None-Match).
• HIT – 응답에는 캐시에서 직접 가져온 유효한 최신 콘텐츠가 포함됩니다.

NGINX는 캐시 여부를 어떻게 결정하나요?

NGINX는 오리진 서버가 다음 중 하나를 포함하는 경우에만 응답을 캐시합니다. 즉, Expires 헤더에 미래의 날짜와 시간이 지정되어 있거나, Cache-Control 헤더의 max-age 지시어가 0이 아닌 값으로 설정되어 있어야 합니다.

기본적으로 NGINX는 Cache-Control 헤더의 다른 지시어를 따릅니다. 즉, 헤더에 Private, No-Cache, 또는 No-Store 지시어가 포함된 경우 응답을 캐시하지 않습니다. 또한 Set-Cookie 헤더가 있는 응답도 캐시하지 않습니다. 그뿐만 아니라 GET 및 HEAD 요청에 대한 응답만 캐시합니다. 아래 답변에 설명된 대로 이러한 기본 설정을 재정의할 수 있습니다.

NGINX does not cache responses if proxy_buffering이 off로 설정되어 있으면 NGINX는 응답을 캐시하지 않습니다. 기본값은 on입니다.

Can Cache-Control 헤더를 무시할 수 있나요?

예, proxy_ignore_headers 지시어를 사용하면 됩니다. 예를 들어 다음과 같이 구성할 수 있습니다:

location /images/ {
    proxy_cache my_cache;
    proxy_ignore_headers Cache-Control;
    proxy_cache_valid any 30m;
    # ...
}

NGINX는 Cache-Control 헤더를 /images/ 아래의 모든 항목에 대해 무시합니다. proxy_cache_valid 지시어는 캐시된 데이터의 만료 시간을 강제로 설정하며, Cache-Control 헤더를 무시하려면 반드시 필요합니다. NGINX는 만료 시간이 없는 파일을 캐시하지 않습니다.

NGINX는 헤더에 Set-Cookie가 있는 콘텐츠를 캐시할 수 있나요?

예, 이전 답변에서 설명한 것처럼 proxy_ignore_headers 지시어를 사용하면 됩니다.

NGINX가 POST 요청을 캐시할 수 있나요?

예, proxy_cache_methods 지시어를 사용하면 됩니다:

proxy_cache_methods GET HEAD POST;

이 예제에서는 POST 요청의 캐싱을 활성화합니다.

NGINX는 동적 콘텐츠를 캐시할 수 있나요?

예, Cache-Control 헤더에서 허용하는 경우 가능합니다. 동적 콘텐츠를 짧은 시간이라도 캐싱하면 원본 서버와 데이터베이스의 부하를 줄일 수 있습니다. 각 요청마다 페이지를 다시 생성할 필요가 없으므로 첫 바이트까지의 시간도 단축됩니다.

캐시를 우회할 수 있나요?

예, proxy_cache_bypass 지시어를 사용하면 됩니다:

location / {
    proxy_cache_bypass $cookie_nocache $arg_nocache;
    # ...
}

이 지시어는 NGINX가 먼저 캐시에서 콘텐츠를 찾는 대신 원본 서버에 즉시 콘텐츠를 요청할 요청 유형을 정의합니다. 이를 캐시에 “구멍을 뚫는 것”이라고도 합니다. 이 예시에서 NGINX는 nocache 쿠키나 인수가 있는 요청(예: http://www.example.com/?nocache=true)에 대해 이 작업을 수행합니다. NGINX는 우회되지 않는 향후 요청을 위해 결과 응답을 계속 캐시할 수 있습니다.

NGINX는 어떤 캐시 키를 사용하나요?

NGINX가 생성하는 키의 기본 형식은 다음 NGINX 변수: $scheme$proxy_host$request_uri를 MD5로 해시한 것과 유사하지만, 실제로 사용되는 알고리즘은 이보다 약간 더 복잡합니다.

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g                 inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

이 샘플 구성에서 http://www.example.org/my_image.jpg의 캐시 키는 md5(“http://my_upstream:80/my_image.jpg”)로 계산됩니다.

해시 값에는 실제 호스트 이름($proxy_host) 대신 www.example.com 변수가 사용된다는 점에 유의하세요. $proxy_host는 proxy_pass 지시문에 지정된 프록시 서버의 이름과 포트로 정의됩니다.

키의 기준으로 사용되는 변수(또는 기타 항목)를 변경하려면 proxy_cache_key 지시어를 사용하세요(다음 질문도 참조).

쿠키를 캐시 키의 일부로 사용할 수 있나요?

예. 캐시 키는 임의의 값으로 구성할 수 있습니다. 예를 들면 다음과 같습니다:

proxy_cache_key $proxy_host$request_uri$cookie_jessionid;

이 예에서는 JSESSIONID 쿠키 값을 캐시 키에 포함합니다. URI는 같지만 JSESSIONID 값이 다른 항목은 각각 고유한 항목으로 별도 캐시됩니다.

NGINX는 ETag 헤더를 사용하나요?

NGINX 1.7.3 및 NGINX Plus R5 이상에서는 ETag 헤더가 If-None-Match와 함께 완전히 지원됩니다.

NGINX는 바이트 범위 요청을 어떻게 처리하나요?

캐시에 있는 파일이 최신 상태이면 NGINX는 바이트 범위 요청을 처리하여 해당 항목에서 지정된 바이트만 클라이언트에 제공합니다. 파일이 캐시되어 있지 않거나 오래된 경우 NGINX는 원본 서버에서 전체 파일을 다운로드합니다. 단일 바이트 범위에 대한 요청인 경우 NGINX는 다운로드 스트림에서 해당 범위에 도달하는 즉시 클라이언트로 전송합니다. 요청에서 동일한 파일 내의 여러 바이트 범위를 지정한 경우 NGINX는 다운로드가 완료되면 전체 파일을 클라이언트에 전송합니다.

다운로드가 완료되면 NGINX는 전체 리소스를 캐시로 이동합니다. 따라서 이후의 모든 바이트 범위 요청은 단일 범위든 여러 범위든 캐시에서 즉시 처리됩니다.

NGINX가 해당 upstream 서버에 대한 바이트 범위 요청을 처리하려면 upstream 서버가 바이트 범위 요청을 지원해야 합니다.

NGINX는 캐시 삭제를 지원하나요?

NGINX Plus는 캐시된 파일을 선택적으로 제거하는 기능을 지원합니다. 이 기능은 원본 서버에서 파일이 업데이트되었지만 NGINX Plus 캐시에서는 여전히 유효한 경우(즉, Cache-Control:max-age가 아직 유효하고 inactive 매개변수로 proxy_cache_path 지시문에 설정된 제한 시간이 만료되지 않은 경우)에 유용합니다. NGINX Plus의 캐시 제거 기능을 사용하면 이 파일을 쉽게 삭제할 수 있습니다. 자세한 내용은 캐시에서 콘텐츠 제거를 참조하세요.

NGINX는 Pragma 헤더를 어떻게 처리하나요?

클라이언트는 요청한 콘텐츠를 가져올 때 모든 중간 캐시를 우회하고 원본 서버로 바로 연결하기 위해 Pragma:no-cache 헤더를 추가합니다. NGINX는 기본적으로 Pragma 헤더를 따르지 않지만, 다음 proxy_cache_bypass 지시어를 사용하여 이 기능을 구성할 수 있습니다:

location /images/ {
    proxy_cache my_cache;
    proxy_cache_bypass $http_pragma;
    # ...
}

NGINX는 stale-while-revalidate 및 stale-if-error Cache-Control 헤더 확장을 지원하나요?

예, NGINX Plus R12 및 NGINX 1.11.10 이상에서 지원됩니다. 이러한 확장 기능의 역할은 다음과 같습니다:

• The stale-while-revalidate 확장이 적용된 Cache-Control HTTP 헤더를 사용하면 현재 업데이트 중인 경우 오래된 캐시 응답을 사용할 수 있습니다.
• The stale-if-error는 Cache-Control HTTP 헤더의 확장 지시어로, 오류가 발생한 경우 오래된 캐시 응답을 사용할 수 있도록 합니다.

이 헤더들은 위에서 설명한 proxy_cache_use_stale 지시어보다 우선순위가 낮습니다.

NGINX는 Vary 헤더를 지원하나요?

예, NGINX Plus R5 및 NGINX 1.7.7 이상에서 지원됩니다. 다음은 good overview of the Vary 헤더에 대한 유용한 개요입니다.

추가 자료

NGINX 캐싱을 사용자 지정하고 조정하는 방법은 이 외에도 다양합니다. NGINX 캐싱에 대해 더 자세히 알아보려면 다음 자료를 참조하세요:

• 콘텐츠 캐싱을 위한 모든 구성 옵션은 ngx_http_proxy_module 참조 문서에서 확인할 수 있습니다.
• 두 개의 웨비나를 온디맨드로 시청할 수 있으며, 이 블로그 게시물에서 다룬 내용 대부분을 단계별로 설명합니다: NGINX Plus를 활용한 콘텐츠 캐싱 및 NGINX를 활용한 고가용성 콘텐츠 캐싱.
• The NGINX Plus 관리자 가이드에는 더 많은 구성 예제와 NGINX 캐시 튜닝에 관한 정보가 있습니다.
• The NGINX Plus 캐싱 제품 페이지에서는 NGINX Plus로 캐시 제거를 구성하는 방법에 대한 개요와 그 밖의 캐시 사용자 지정 예시를 제공합니다.
• The NGINX 및 NGINX Plus를 활용한 고성능 캐싱 eBook에서는 NGINX 콘텐츠 캐싱을 심층적으로 자세히 다룹니다.

작성자 소개

Faisal Memon소프트웨어 엔지니어

Faisal Memon의 다른 블로그 게시물