Nginx 기본 캐싱: 응답 시간 개선

Nginx 기본 캐싱은 업스트림 응답의 복사본을 저장하고 매번 애플리케이션에 요청하지 않고 다시 제공하여 응답 시간을 개선할 수 있습니다. 신중하게 사용하면 캐싱은 백엔드 부하를 줄이고 트래픽 급증을 완화하며 반복 요청을 더 빠르게 만듭니다.

캐싱은 대규모 사이트에만 해당되지 않습니다. 페이지, API 응답 또는 정적 파일이 자주 요청되고 매초 변경되지 않는 경우 작은 앱도 혜택을 볼 수 있습니다.

Nginx가 캐시할 수 있는 것

Nginx는 리버스 프록시 역할을 할 때 업스트림 서버의 응답을 캐시할 수 있습니다. 이는 일반적인 브라우저 캐싱과 다릅니다. 브라우저 캐싱은 사용자 기기에 파일을 저장합니다. Nginx 프록시 캐싱은 서버에 응답을 저장하여 많은 사용자가 동일한 캐시된 복사본을 활용할 수 있도록 합니다.

간단한 프록시 캐시 설정은 두 부분으로 구성됩니다. 먼저 http 블록에서 캐시 영역을 정의합니다:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
    max_size=1g inactive=60m use_temp_path=off;

그런 다음 server 또는 location 블록에서 해당 캐시를 활성화합니다:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_cache app_cache;
    proxy_cache_valid 200 10m;
    proxy_cache_valid 404 1m;
    add_header X-Cache-Status $upstream_cache_status;
}

proxy_cache_path 지시문은 캐시 저장 영역을 생성합니다. keys_zone은 캐시 키와 메타데이터를 위한 공유 메모리를 정의합니다. max_size는 디스크 사용량을 제한합니다. inactive는 일정 시간 동안 액세스되지 않은 항목을 제거합니다.

proxy_cache_valid 지시문은 특정 응답 코드가 캐시에 유지되는 기간을 결정합니다. 예제에서 성공적인 응답은 10분 동안 캐시되고 404 응답은 1분 동안 캐시됩니다.

X-Cache-Status 헤더는 테스트 중에 유용합니다. 상황에 따라 MISS, HIT, BYPASS 또는 EXPIRED와 같은 값을 표시할 수 있습니다.

Nginx를 리버스 프록시로 사용하는 사이트의 경우 이는 리버스 프록시 설정과 자연스럽게 연결됩니다.

캐시할 내용 결정

Nginx 캐싱의 가장 어려운 부분은 지시문을 작성하는 것이 아닙니다. 재사용해도 안전한 콘텐츠를 결정하는 것입니다.

좋은 캐싱 후보는 다음과 같습니다:

• 공개 마케팅 페이지.
• 공개 문서 페이지.
• 예측 가능한 일정으로 업데이트되는 제품 목록 페이지.
• 익명 API 응답.
• 많은 사용자에게 동일한 값비싼 업스트림 응답.

좋지 않은 캐싱 후보는 다음과 같습니다:

• 계정 페이지.
• 쇼핑 카트.
• 관리자 화면.
• 개인 사용자 데이터를 포함하는 응답.
• 쿠키 또는 인증 헤더에 따라 변경되는 페이지.

응답이 사용자마다 다른 경우 매우 명확한 캐시 키 전략이 없으면 캐시하지 마십시오. 실수로 한 사용자의 개인 응답을 다른 사용자에게 제공하는 것은 심각한 버그입니다.

요청에 세션 또는 인증 데이터가 포함된 경우 캐싱을 우회할 수 있습니다:

proxy_cache_bypass $http_authorization;
proxy_no_cache $http_authorization;

쿠키 기반 세션의 경우 유사한 패턴을 사용할 수 있습니다:

proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;

정확한 쿠키 이름은 애플리케이션에 따라 다릅니다. 앱이 세션을 처리하는 방식을 확인하지 않고 맹목적으로 복사하지 마십시오.

실용적인 시나리오: 공개 블로그 홈페이지가 애플리케이션에 의해 생성되고 바쁜 날 300밀리초가 걸립니다. 해당 페이지를 5분 동안 캐시하면 대부분의 방문자가 캐시된 복사본을 빠르게 받고 앱은 가끔씩만 다시 생성합니다. 홈페이지는 공개적이고 사용자별로 다르지 않기 때문에 강력한 사용 사례입니다.

캐시 키, 헤더 및 제거

Nginx는 캐시 키를 사용하여 두 요청이 동일한 캐시된 응답을 공유해야 하는지 결정합니다. 기본 캐시 키는 일반적으로 스키마, 메서드, 호스트 및 URI를 기반으로 합니다. 많은 사이트에서 충분합니다.

쿼리 문자열이 응답을 변경하는 경우 키의 일부인지 확인하십시오. 쿼리 문자열이 추적 매개변수에 불과한 경우 모든 utm_source가 별도의 캐시 항목을 생성하도록 두지 말고 애플리케이션 또는 CDN 계층에서 정규화하는 것이 좋습니다.

업스트림 캐시 헤더도 중요합니다. 앱은 다음과 같은 헤더를 보낼 수 있습니다:

Cache-Control: public, max-age=600

또는:

Cache-Control: private, no-store

Nginx는 이러한 헤더를 존중하거나 재정의하도록 구성할 수 있지만 하나의 명확한 정책을 선택해야 합니다. 앱 개발자가 Cache-Control: no-store가 캐싱을 방지할 것으로 예상하는 경우 Nginx에서 해당 동작을 재정의하면 혼란스럽고 위험한 결과를 초래할 수 있습니다.

제거는 또 다른 운영 문제입니다. 오픈 소스 Nginx에는 일부 상용 또는 타사 모듈과 같은 방식으로 간단한 내장 캐시 제거 엔드포인트가 포함되어 있지 않습니다. 많은 팀이 짧은 캐시 기간, 버전이 지정된 URL 또는 제어된 릴리스 중에 캐시 디렉토리를 지우는 배포 스크립트를 사용하여 이를 처리합니다.

짧은 TTL은 종종 충분합니다. 사용량이 많은 엔드포인트에서 60초 캐시는 콘텐츠를 적절히 신선하게 유지하면서 백엔드 트래픽을 크게 줄일 수 있습니다.

캐시 동작 테스트

캐싱을 활성화한 후 동일한 URL을 여러 번 요청하고 응답 헤더를 검사합니다:

curl -I https://example.com/

X-Cache-Status를 추가한 경우 첫 번째 요청은 MISS를 표시하고 이후 요청은 HIT를 표시해야 합니다. 모든 요청이 MISS인 경우 응답 헤더, 캐시 우회 규칙, 요청 쿠키 및 캐시 디렉토리가 Nginx 작업자 프로세스에 의해 쓰기 가능한지 확인하십시오.

또한 로그인 및 로그아웃 동작을 테스트하십시오. 여기서 많은 캐싱 실수가 나타납니다. 개인 브라우저 창을 열고 테스트 사용자로 로그인하여 개인 페이지가 공개적으로 캐시되지 않는지 확인하십시오.

디스크 사용량도 모니터링하십시오. 실질적인 제한이 없는 캐시는 파일 시스템을 가득 채울 수 있습니다. max_size를 사용하고, 가능하면 캐시 저장소를 중요한 시스템 파티션과 분리하고, 디스크 압력에 대해 경고하십시오.

도움이 필요할 때

캐시된 콘텐츠가 잘못된 사용자에게 표시되거나, 조정 후 캐시 적중률이 낮게 유지되거나, 캐시 파일이 예기치 않게 디스크를 가득 채우는 경우 숙련된 Nginx 또는 플랫폼 엔지니어의 도움을 받으십시오. 캐싱 문제는 애플리케이션별 동작을 숨기면서 단순해 보일 수 있습니다.

또한 인증된 API, 다중 테넌트 대시보드 또는 결제 관련 흐름을 캐시하기 전에 도움을 받아야 합니다. 이러한 영역은 신중한 설계가 필요합니다.

Nginx 기본 캐싱은 공개적이고 반복 가능한 응답과 짧은 캐시 기간으로 시작할 때 가장 잘 작동합니다. 테스트 중에 가시적인 캐시 상태 헤더를 추가하고, 개인 콘텐츠 경계를 존중하며, 응답 시간과 백엔드 부하를 모두 측정하십시오. 제대로 수행되면 캐싱은 사용자에게 더 빠른 페이지를 제공하면서 애플리케이션에 숨 쉴 공간을 제공합니다.