캐싱 개요

캐시 가능한 응답은 Cloud CDN이 저장하고 빠르게 검색할 수 있으므로 로드 시간을 더 빠르게 할 수 있는 HTTP 응답입니다. 모든 HTTP 응답을 캐시할 수 있는 것은 아닙니다.

캐시 모드

캐시 모드를 사용하면 Cloud CDN이 콘텐츠를 캐시하는지 여부를 결정하는 요소를 제어할 수 있습니다.

Cloud CDN은 응답이 캐시되는 방식, Cloud CDN이 원본에서 전송한 캐시 지시문을 준수하는지 여부, 캐시 TTL이 적용되는 방식을 정의하는 세 가지 캐시 모드를 제공합니다.

사용 가능한 캐시 모드는 다음 표에 나와 있습니다.

캐시 모드 동작
CACHE_ALL_STATIC no-store 또는 private 지시문이 없는 정적 콘텐츠를 자동으로 캐시합니다. 유효한 캐싱 지시문을 설정하는 원본 응답도 캐시됩니다.

이는 gcloud 명령줄 도구 또는 REST API를 사용하여 생성된 Cloud CDN이 사용 설정된 백엔드의 기본 동작입니다.

USE_ORIGIN_HEADERS 유효한 캐시 지시문 및 캐싱 헤더를 설정하기 위해 원본 응답을 요구합니다. 이러한 지시문이 없는 응답은 원본에서 전달됩니다.
FORCE_CACHE_ALL 원본으로 설정된 캐시 지시문을 무효화하고 성공적인 응답을 무조건적으로 캐시합니다. 백엔드가 동적 HTML 또는 API 응답과 같은 사용자별 비공개 콘텐츠를 제공하는 경우에는 이 모드가 적절하지 않습니다.

설정 안내는 캐시 모드 설정을 참조하세요.

정적 콘텐츠

정적 콘텐츠는 다른 사용자가 액세스하더라도 항상 동일한 콘텐츠입니다. 사이트 스타일을 지정하는 데 사용하는 CSS, 대화형 작업을 제공하는 자바스크립트, 동영상, 이미지 콘텐츠는 일반적으로 지정된 URL(캐시 키)의 사용자에 따라 변경되지 않습니다. 따라서 Cloud CDN의 전역 에지 네트워크에서 캐시함으로써 이점을 얻을 수 있습니다.

캐시 모드를 CACHE_ALL_STATIC으로 설정하면 Cloud CDN은 다음에 대한 응답을 자동으로 캐시합니다.

  • CSS(text/css), 자바스크립트(application/javascript) 및 WOFF2(font/woff2)가 포함된 모든 웹 글꼴을 포함한 웹 애셋
  • JPEG(image/jpg) 및 PNG(image/png)를 포함한 이미지
  • H.264, H.265, MP4(video/mp4)를 포함한 동영상, MP3(image/mpeg) 및 MP4(audio/mp4)를 포함한 오디오 파일
  • PDF(application/pdf)를 포함한 서식이 지정된 문서

다음 표는 요약 정보입니다.

카테고리 MIME 유형
웹 애셋 text/css text/ecmascript text/javascript application/javascript
글꼴 font/*와 일치하는 모든 Content-Type
이미지 image/*와 일치하는 모든 Content-Type
동영상 video/*와 일치하는 모든 Content-Type
오디오 audio/*와 일치하는 모든 Content-Type
서식이 지정된 문서 유형 application/pdfapplication/postscript

Cloud CDN은 제공되는 콘텐츠의 MIME 유형을 반영하는 Content-Type HTTP 응답 헤더를 검사합니다.

다음에 유의하세요.

  • 원본의 웹 서버 소프트웨어는 응답마다 Content-Type을 설정해야 합니다. 많은 웹 서버가 NGINX, Varnish, Apache를 포함한 Content-Type 헤더를 자동으로 설정합니다.

  • Cloud Storage는 Cloud Console이나 gsutil 도구를 사용하여 콘텐츠를 업로드하면 Content-Type 헤더를 자동으로 업로드하도록 설정합니다.

  • MIME 유형에 따라 응답을 캐시할 수 있지만 private 또는 no-storeCache-Control 응답 헤더나 Set-Cookie 헤더가 있으면(전체 규칙 목록 참조) 응답이 캐시되지 않습니다.

캐시할 수 있는 유효한 많은 응답에서 URL을 반영하지 않으므로 Cloud CDN은 파일 확장자를 사용하여 응답에서 캐시할 수 있는지 여부를 확인하지 않습니다.

text/htmlapplication/json 콘텐츠 유형을 캐시하려면 응답에 명시적 Cache-Control 헤더를 설정해야 합니다. 이때 사용자 데이터 하나를 실수로 캐시하여 모든 사용자에게 제공되지 않도록 주의합니다.

캐시 가능한 콘텐츠

Cloud CDN은 이 섹션의 모든 요구 사항을 충족하는 응답을 캐시합니다. 이러한 요구 사항 중 일부는 RFC 7234에 명시되어 있으며, 다른 일부는 Cloud CDN에만 해당합니다.

Cloud CDN은 콘텐츠를 캐시하는 정확한 조건 집합을 주기적으로 변경할 수 있습니다. Cloud CDN이 콘텐츠를 캐시하지 못하도록 명시적으로 방지하려면 RFC 7234의 가이드라인에 따라 캐시할 수 없는 응답을 지정하는 방법을 결정합니다. 원본 헤더를 기준으로 캐시할 수 없는 콘텐츠 섹션도 참조하세요.

Cloud CDN의 현재 구현에서는 다음 사항이 모두 참인 경우 캐시에 응답을 저장합니다.

속성 요구사항
제공 Cloud CDN이 사용 설정된 백엔드 서비스, 백엔드 버킷 또는 외부 백엔드
다음에 대한 응답 GET 요청
상태 코드

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451, 501.

최신 정보

응답에 max-age 또는 s-maxage 지시문이 있는 Cache-Control 헤더가 있거나 이후 타임스탬프를 포함하는 Expires 헤더가 있습니다.

CACHE_ALL_STATIC 캐시 모드의 경우 최신 상태 지시문이 없으면 정적 콘텐츠 유형을 포함하는 성공한 응답이 계속 캐싱 대상으로 지정됩니다.

FORCE_CACHE_ALL 캐시 모드의 경우 모든 성공한 응답이 캐싱 대상으로 지정됩니다.

음성 캐싱이 사용 설정되고 상태 코드가 음성 캐싱에서 TTL을 지정하는 것과 일치하면 명시적인 최신 상태 지시문이 없어도 응답이 캐싱 대상으로 지정됩니다.

콘텐츠

유효한 Content-Length, Content-Range 또는 Transfer-Encoding: chunked 헤더가 포함됩니다.

예를 들어 Content-Length 헤더는 응답 크기와 정확하게 일치합니다.

크기 최대 크기 이하

크기가 10MB~5TB인 응답의 경우 바이트 범위 요청에 설명된 추가 캐시 저장 가능성 제약조건을 참조하세요.

Cloud Storage 백엔드 버킷의 경우 다음과 같은 여러가지 방법으로 이러한 요구사항을 충족할 수 있습니다.

기본적으로 전체 버킷이 공개되어 있거나 개별 객체가 공개되고 개별 객체가 Cache-Control 메타데이터를 지정하지 않으면 Cloud Storage는 Cache-Control: public, max-age=3600 헤더를 객체에 할당합니다. Cache-Control 메타데이터를 사용하여 다른 값을 설정할 수 있습니다.

백엔드 버킷으로 외부 HTTP(S) 부하 분산기를 구성하는 방법에 대한 예시는 백엔드 버킷으로 Cloud CDN 설정을 참조하세요.

최대 크기

Cloud CDN은 각 응답에 최대 크기를 적용합니다. 최대 크기보다 큰 본문에 대한 응답은 캐시되지 않지만 여전히 클라이언트에게 전송됩니다.

최대 크기는 원본 서버의 바이트 범위 요청 지원 여부에 따라 달라집니다.

원본 서버가 바이트 범위 요청을 지원함 원본 서버가 바이트 범위 요청을 지원하지 않음
5TB(5,497,558,138,880바이트) 10MB(10,485,760바이트)

거의 모든 최신 웹 서버(NGINX, Apache, Varnish 포함)는 바이트 범위 요청을 지원합니다.

원본 헤더를 기준으로 캐시할 수 없는 콘텐츠

응답의 캐싱을 차단하는 검사가 있습니다. Cloud CDN은 콘텐츠를 캐시하는 정확한 조건 집합을 주기적으로 변경할 수 있으므로, Cloud CDN이 콘텐츠를 캐시하지 못하도록 하려면 표준(RFC 7234)의 가이드라인에 따라 캐시할 수 없는 응답을 지정하는 방법을 결정합니다.

Cloud CDN의 현재 구현에서는 캐시 가능한 콘텐츠의 요구사항이 충족되지 않거나 다음 중 하나에 해당하는 경우 응답을 캐시하지 않습니다.

속성 요구사항
제공 Cloud CDN이 사용 설정되지 않은 백엔드 서비스 또는 외부 백엔드
쿠키 Set-Cookie 헤더가 있음
Vary 헤더 Accept, Accept-Encoding 또는 Origin 이외의 값
응답 지시문 응답에 no-store 또는 private 지시문이 있는 Cache-Control 헤더가 있습니다. 이 경우 FORCE_CACHE_ALL 캐시 모드를 사용하지 않으면 Cache-Control 헤더는 무시됩니다.
요청 지시문 요청에 Cache-Control: no-store 지시문이 있음
승인 요청 Cache-Control 응답에 의해 재정의되지 않는 한 요청에 Authorization 헤더가 있습니다.
크기 최대 크기보다 큼

Cache-Control: no-store 또는 private이 있지만 콘텐츠가 여전히 캐시되고 있으면 다음 중 하나가 원인입니다.

  • URL 서명이 구성되었습니다.
  • Cloud CDN 캐시 모드는 모든 응답을 강제 캐시하도록 설정됩니다.

캐싱 방지

개인 정보가 Cloud CDN 캐시에 캐시되지 않도록 방지하려면 다음 단계를 따릅니다.

  1. Cloud CDN 캐시 모드가 모든 성공적인 응답을 무조건 캐시하는 FORCE_CACHE_ALL 모드로 설정되어 있지 않은지 확인합니다.
  2. Cloud CDN 캐시에 저장하지 않아야 할 응답에는 Cache-Control: private 헤더를 포함하고, 웹브라우저의 캐시를 포함한 모든 캐시에 저장하지 않아야 할 응답에는 Cache-Control: no-store 헤더를 포함합니다.
  3. 개인 정보에 대한 액세스를 제공하는 URL에 서명하지 않습니다. 서명된 URL을 사용하여 콘텐츠에 액세스하는 경우 응답의 Cache-Control 지시문에 관계없이 잠재적으로 캐시할 수 있습니다.
  4. Authorization 요청 헤더가 포함된 원본(캐시 채움) 요청의 경우 Cloud CDN은 캐시 모드가 USE_ORIGIN_HEADERS또는 CACHE_ALL_STATIC으로 설정된 경우 public, must-revalidate 또는 s-maxage 캐시 제어 지시문이 포함된 응답만 캐시합니다. 이렇게 하면 사용자별 콘텐츠 또는 인증이 필요한 콘텐츠를 실수로 캐시하는 것을 방지할 수 있습니다. FORCE_CACHE_ALL 캐시 모드에는 이러한 제한이 없습니다.

커스텀 응답 헤더 추가

커스텀 응답 헤더를 사용하면 외부 HTTP(S) 부하 분산기가 프록시 응답에 추가하는 헤더를 지정할 수 있습니다. 커스텀 응답 헤더를 사용하면 클라이언트, 클라이언트 지리 데이터, 고유한 정적 응답 헤더에 캐시 상태를 반영할 수 있습니다.

헤더 목록은 헤더 값에 표시될 수 있는 변수를 참조하세요.

자세한 내용은 커스텀 응답 헤더 작업을 참조하세요.

캐시 키

Cloud CDN 캐시의 각 캐시 항목은 캐시 키로 식별됩니다. 캐시에 요청이 들어오면 캐시가 요청의 URI를 캐시 키로 변환한 후 캐시된 항목의 키와 비교합니다. 일치하는 키가 발견되면 캐시는 해당 키와 연관된 객체를 반환합니다.

백엔드 서비스의 경우 Cloud CDN은 기본적으로 전체 요청 URI를 캐시 키로 사용합니다. 예를 들어 https://example.com/images/cat.jpgcat.jpg 객체의 특정 요청에 대한 전체 URI입니다. 이 문자열은 기본 캐시 키로 사용됩니다. 정확히 이 문자열이 있는 요청만 일치합니다. http://example.com/images/cat.jpg 또는 https://example.com/images/cat.jpg?user=user1에 대한 요청은 일치하지 않습니다.

캐시 키에서 사용되는 URI 부분을 변경할 수 있습니다. 파일 이름과 경로는 항상 키의 일부여야 하지만 캐시 키 맞춤설정 시 프로토콜, 호스트, 쿼리 문자열의 조합을 포함하거나 생략할 수 있습니다. 캐시 키 사용에서는 캐시 키를 맞춤설정하는 방법을 설명합니다.

URI 부분 맞춤설정 캐시 키가 동일한 URL의 예시
프로토콜 캐시 키에서 프로토콜을 생략합니다.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
호스트 캐시 키에서 호스트를 생략합니다.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
쿼리 문자열

캐시 키에서 쿼리 문자열을 생략합니다.

쿼리 문자열의 일부를 선택적으로 생략하거나 포함합니다.

  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

전체 쿼리 문자열을 포함하거나 제외하는 것 외에 포함 목록 및 제외 목록을 사용하여 쿼리 문자열 일부를 사용할 수 있습니다.

백엔드 버킷의 경우 캐시 키는 프로토콜, 호스트, 쿼리 문자열이 없는 URI로 구성됩니다.

따라서 특정 백엔드 버킷의 경우 다음 URI가 동일한 캐시된 객체로 확인됩니다.

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

쿼리 문자열 포함 목록

Cloud CDN이 캐시 키에 포함되는 쿼리 문자열 매개변수를 선택적으로 제어할 수 있습니다. 예를 들어 user의 포함 목록을 만들면 https://example.com/images/cat.jpg?user=user1&color=bluehttps://example.com/images/cat.jpg?user=user1&color=red와 일치하는 https://example.com/images/cat.jpg?user=user1 캐시 키를 만듭니다.

이 옵션을 사용하려면 쿼리 문자열을 포함하고 비어 있지 않은 포함 목록을 지정하고 제외 목록을 지정하면 안 됩니다.

동일한 쿼리 매개변수의 순서가 다른 URL의 경우 캐시 키가 달라집니다. 다음 두 URL은 쿼리 매개변수가 같더라도 캐시 키가 다릅니다.

  • https://example.com/images/cat.jpg?user=user1&color=red
  • https://example.com/images/cat.jpg?color=red&user=user1

쿼리 문자열 제외 목록

제외 목록을 사용하여 Cloud CDN이 무시하는 쿼리 문자열 매개변수를 선택적으로 제어할 수 있습니다. 예를 들어 user 제외 목록을 만들면 user제외한 모든 쿼리 문자열 매개변수가 캐시 키에 사용됩니다.

제외 목록이 구성되고 입력이 https://example.com/images/cat.jpg?user=user1&color=blue이면 Cloud CDN은 https://example.com/images/cat.jpg?user=user2&color=blue와 일치하지만 https://example.com/images/cat.jpg?user=user1&color=red와 일치하지 않는 https://example.com/images/cat.jpg?color=blue의 캐시 키를 만듭니다.

이 옵션을 사용하려면 쿼리 문자열을 포함하고 비어 있지 않은 제외 목록을 지정해야 하며 포함 목록을 지정하면 안 됩니다.

캐시 제어 지시문

HTTP 캐시 제어 지시문은 다음 표에 설명된 대로 Cloud CDN의 동작에 영향을 미칩니다.

해당 사항 없음은 요청이나 응답에 지시문을 적용할 수 없음을 나타냅니다.

지시문 요청 응답
no-store 요청에 있는 경우 Cloud CDN은 이를 받아들여 응답을 캐시에 저장하지 않습니다.

no-store가 포함된 응답은 캐시되지 않습니다.

FORCE_CACHE_ALL 캐시 모드를 사용하여 백엔드별로 재정의할 수 있습니다.

no-cache 클라이언트가 원본에 재검증을 잠재적으로 시작하거나 강제하지 못하게 하기 위해 no-cache 요청 지시문은 무시됩니다.

no-cache인 응답은 캐시되지만 제공하기 전에 원본으로 재검증해야 합니다.

FORCE_CACHE_ALL 캐시 모드를 사용하여 백엔드별로 재정의할 수 있습니다.

public 해당 사항 없음

캐시 가능성에는 이 지시문이 필요하지 않지만 프록시에서 캐시해야 하는 콘텐츠에 포함하는 것이 좋습니다.

private 해당 사항 없음

private 지시문이 있는 응답은 응답이 캐시 가능한 것으로 간주되는 경우에도 Cloud CDN에 의해 캐시되지 않습니다. 클라이언트(예: 브라우저)는 여전히 결과를 캐시할 수 있습니다.

FORCE_CACHE_ALL 캐시 모드를 사용하여 백엔드별로 재정의할 수 있습니다. 모든 응답 캐싱을 방지하려면 no-store를 사용합니다.

max-age=seconds max-age 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다. max-age 지시문이 있는 응답은 정의된 seconds로 캐시됩니다.
s-maxage=seconds 해당 사항 없음

s-maxage 지시문이 있는 응답은 정의된 seconds로 캐시됩니다.

max-ages-maxage이 모두 존재하는 경우 s‑maxage는 Cloud CDN에서 사용됩니다.

이 지시문이 있는 응답은 비활성 상태가 아닙니다.

s-max-age(하이픈 2개)는 캐싱 목적에 유효하지 않습니다.

min-fresh=seconds min-fresh 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다. 해당 사항 없음
max-stale=seconds

max-stale 요청 지시문은 클라이언트가 허용할 최대 비활성 상태를 초 단위로 나타냅니다.

Cloud CDN은 이를 받아들여 응답의 비활성 상태가 max-stale 지시문보다 짧은 경우에만 오래된 캐시된 응답을 반환합니다. 그렇지 않으면 요청을 처리하기 전에 재검증합니다.

해당 사항 없음
stale-while-revalidate=seconds 해당 사항 없음

stale-while-revalidate가 있는 응답은 클라이언트에 최대 seconds까지 제공되고 재검증이 비동기식으로 발생합니다.

이 동작은 백엔드에서 cdnPolicy.serveWhileStale을 설정하여 모든 응답에 사용 설정할 수 있습니다.

stale-if-error=seconds stale-if-error 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다.

이 응답 헤더는 효과가 없습니다.

must-revalidate 해당 사항 없음

must-revalidate가 있는 응답은 만료된 후 원본 서버에서 재검증합니다.

이 지시문이 있는 응답은 비활성 상태가 아닙니다.

proxy-revalidate

proxy-revalidate가 있는 응답은 만료된 후 원본 서버에서 재검증합니다.

이 지시문이 있는 응답은 비활성 상태가 아닙니다.

immutable 해당 사항 없음 효과 없음 이는 응답에서 클라이언트로 전달됩니다.
no-transform 해당 사항 없음 Cloud CDN에는 변환이 적용되지 않습니다.
only-if-cached only-if-cached 요청 지시문은 무시됩니다. 이 헤더가 요청에 포함되지 않은 것처럼 캐시된 응답이 반환됩니다. 해당 사항 없음

가능한 경우 Cloud CDN은 RFC를 준수(HTTP RFC 7234)하려고 노력하지만 캐시 오프로드를 최적화하고 클라이언트가 적중률 또는 전반적인 원본 부하에 미칠 수 있는 영향을 최소화하는 것을 선호합니다.

HTTP/1.1 Expires 헤더를 사용하는 응답의 경우 다음 사항이 적용됩니다.

  • Expires 헤더의 값은 RFC 7231에 정의된 유효한 HTTP 날짜여야 합니다.
  • 과거 날짜 값, 잘못된 날짜 또는 0 값은 콘텐츠가 이미 만료되었고 재검증해야 함을 나타냅니다.
  • 응답에 Cache-Control 헤더가 있으면 Cloud CDN은 Expires 헤더를 무시합니다.

응답에 유효한 향후 Expires 헤더가 있으면 응답이 캐시될 수 있으며 다른 캐시 지시문을 지정할 필요가 없습니다.

HTTP/1.0 Pragma 헤더가 응답에 있는 경우 이 헤더는 무시되며 클라이언트에 그대로 전달됩니다. 이 헤더가 포함된 클라이언트 요청은 원본으로 전달되며 Cloud CDN이 응답을 제공하는 방식에 영향을 미치지 않습니다.

Vary 헤더

Vary 헤더는 클라이언트의 요청 헤더에 따라 응답이 달라짐을 나타냅니다. 요청 URI 외에도 Cloud CDN은 원본 서버가 응답에 포함하는 Vary 헤더를 고려합니다. 예를 들어 응답에서 Vary: Accept를 지정하면 Cloud CDN은 Accept: image/webp,image/*,*/*;q=0.8을 지정하는 캐시 요청에 캐시 항목 하나를 사용하고 Accept: */*를 지정하는 요청에 다른 하나를 사용합니다.

캐시할 수 없는 콘텐츠 섹션의 표에는 콘텐츠가 캐시될 수 있는 Vary 헤더가 나와 있습니다. 다른 Vary 헤더 값은 콘텐츠가 캐시되지 않도록 합니다.

FORCE_CACHE_ALL 캐시 모드는 이 동작을 재정의하지 않습니다. Vary 헤더는 가능한 여러 원본 서버 응답 간의 캐시 악성을 방지하기 위해 중요합니다. FORCE_CACHE_ALL가 이러한 응답을 캐시하도록 하는 것은 위험할 수 있습니다.

Vary 헤더는 간혹 압축된 콘텐츠를 제공하는 경우에 사용됩니다. Cloud CDN은 응답 자체를 압축하거나 압축 해제하지 않지만 원본 서버가 압축한 응답을 제공할 수 있습니다. 원본 서버가 압축 또는 압축되지 않은 콘텐츠를 제공할지 여부를 Accept-Encoding 요청 헤더의 값에 따라 선택하는 경우 응답이 Vary: Accept-Encoding을 지정하는지 확인합니다.

만료 시간 및 유효성 검사 요청

USE_ORIGIN_HEADERS 캐시 모드를 사용하면 Cloud CDN 캐시의 각 캐시 항목에는 RFC 7234에 따라 Cache-Control: s-maxage, Cache-Control: max-age 또는 Expires 헤더에서 정의된 만료 시간이 있습니다. 만료 시간이 두 개 이상 있으면 Cache-Control: s-maxageCache-Control: max-age보다 우선시되고 Cache-Control: max-ageExpires보다 우선시됩니다.

CACHE_ALL_STATIC 캐시 모드를 사용하면 원본 헤더가 기본적으로 참조되어 최신 상태가 결정됩니다. 원본 헤더가 없는 경우 정적 콘텐츠는 모두 새로운 것으로 간주됩니다.

FORCE_CACHE_ALL 캐시 모드를 사용하면 모든 백엔드 응답이 새 응답으로 간주됩니다.

Cloud CDN이 요청을 받으면 해당 캐시 항목을 조회하고 저장 기간을 확인합니다. 캐시 항목이 존재하고 새 항목이면 캐시에서 응답을 제공할 수 있습니다. 그러나 만료 시간이 경과하면 Cloud CDN은 백엔드 중 하나에 연락하여 캐시 항목을 재검증합니다. 이는 검증이 비동기식으로 수행되는 오래된 경우에도 제공을 사용 설정하지 않는 한 응답을 제공하기 전에 수행됩니다.

Cloud CDN은 30일이 지난 캐시된 객체의 유효성을 다시 확인합니다. 이렇게 하면 사용자가 생성한 비활성 캐시 콘텐츠를 자동으로 무효화하고 제거할 수 있습니다. max-age 또는 s-maxage 값이 30일(2,592,000초)을 초과하면 Cloud CDN은 해당 값을 2,592,000초로 보고 처리합니다. 30일을 초과하더라도 다운스트림 클라이언트는 여전히 max-ages-maxage의 정확한 값을 볼 수 있습니다.

Cloud CDN은 캐시된 응답 헤더의 정보를 사용하여 백엔드가 있는 캐시 항목의 유효성을 검사할 수 있습니다. 다음 두 조건이 모두 충족되는 경우에 가능합니다.

  • 이전에 캐시된 응답에 Last-Modified 또는 ETag 헤더가 있습니다.
  • 클라이언트 요청은 If-Modified-Since 또는 If-None-Match 헤더가 없는 GET 요청입니다.

Cloud CDN은 응답이 바이트 범위 요청을 사용하여 캐시되었는지 여부에 따라 이 유효성 검사를 약간 다르게 수행합니다.

  • 응답이 바이트 범위 요청을 사용하여 캐시된 경우 Cloud CDN은 If-Modified-Since 또는 If-None-Match 헤더를 포함하는 별도의 유효성 검사 요청을 시작합니다.
  • 그렇지 않으면 Cloud CDN에서 If-Modified-Since 또는 If-None-Match 헤더를 클라이언트 요청에 추가하고 수정된 요청을 백엔드로 전달합니다.

캐시된 사본이 여전히 최신 상태인 경우 백엔드는 304 Not Modified 응답을 전송하여 기존 캐시 항목의 유효성을 검사할 수 있습니다. 이 경우, 백엔드는 응답 헤더만 전송하고 응답 본문을 전송하지 않습니다. Cloud CDN은 새 응답 헤더를 캐시에 삽입하고 만료 시간을 업데이트하고 새 응답 헤더와 캐시된 응답 본문을 클라이언트에 제공합니다.

이전에 캐시된 응답에 Last-Modified 또는 ETag 헤더가 없으면 Cloud CDN은 만료된 캐시 항목을 무시하고 수정되지 않은 클라이언트 요청을 백엔드로 전달합니다.

캐시 항목의 만료 시간은 캐시 항목이 유효한 기간의 상한입니다. 캐시 항목이 만료될 때까지 캐시에 남아 있다는 보장은 없습니다. 인기가 없는 콘텐츠의 캐시 항목은 새 콘텐츠를 위한 공간 확보를 위해 삭제될 수 있습니다. 지정된 만료 시간과 관계없이 30일 동안 액세스되지 않은 캐시 항목은 자동으로 삭제됩니다.

자세한 내용은 제거 및 만료를 참조하세요.

TTL 설정 및 재정의

Cloud CDN이 콘텐츠를 재검증하기 전에 기다리는 시간과 관련된 Cloud CDN 동작을 미세 조정할 수 있습니다.

자세한 내용은 TTL 설정 및 재정의 사용을 참조하세요.

바이트 범위 요청 지원

다음 기준을 충족하는 응답은 원본 서버가 바이트 범위 요청을 지원함을 나타냅니다.

  • 상태 코드: 200 OK 또는 206 Partial Content
  • 헤더: Accept-Ranges: bytes
  • 헤더: Content-Length 또는 Content-Range
  • 헤더: 강력한 유효성 검사 도구가 있는 ETag
  • 헤더: Last-Modified

Cloud Storage는 대부분의 객체에 대해 바이트 범위 요청을 지원합니다. 그러나 클라이언트 요청에 Accept- Encoding: gzip 헤더가 포함되어 있지 않으면 Cloud Storage는 Content-Encoding: gzip 메타데이터가 있는 객체의 바이트 범위 요청을 지원하지 않습니다. 10MB보다 큰 Cloud Storage 객체가 있는 경우 객체에 Content-Encoding: gzip 메타데이터가 없는지 확인합니다. 객체 메타데이터를 수정하는 방법에 대한 자세한 내용은 객체 메타데이터 보기 및 수정을 참조하세요.

또한 널리 사용되는 웹 서버 소프트웨어도 바이트 범위 요청을 지원합니다. 이 지원을 사용 설정하는 방법에 대해서는 해당 웹 서버 소프트웨어 문서를 참조하세요. 바이트 범위 요청에 대한 자세한 내용은 HTTP 사양을 참조하세요.

원본 서버가 바이트 범위 요청을 지원하면 Cloud CDN 캐시는 다음 이유 중 하나로 처음 요청되었을 때 캐시 가능한 응답 저장을 거부할 수 있습니다.

  • 클라이언트가 콘텐츠의 일부만 요청했으므로, 응답 본문이 완전하지 않은 경우
  • 응답 본문이 1MB(1,048,576바이트)보다 큰 경우

이러한 경우와 응답이 정상적인 캐시 저장 가능성 요구사항을 충족하면 캐시는 원본 서버가 해당 캐시 키의 바이트 범위 요청을 지원하고 원본 서버의 응답을 클라이언트에 전달하는 것을 기록합니다.

캐시 부적중의 경우 캐시는 원본 서버가 바이트 범위 요청을 지원하는 것으로 알려져 있는지 확인합니다. 바이트 범위 요청이 캐시 키를 지원하는 것으로 알려진 경우 캐시는 클라이언트 요청을 외부 HTTP(S) 부하 분산기로 전달하지 않습니다. 대신 누락된 콘텐츠 부분에 대해 자체 바이트 범위 캐시 채움 요청을 시작합니다. 원본 서버가 요청된 바이트 범위를 206 Partial Content 응답으로 반환하면 캐시는 이후 요청을 위해 해당 범위를 저장할 수 있습니다.

캐시가 시작한 바이트 범위 요청에 대한 응답으로 캐시가 수신된 경우에만 캐시는 206 Partial Content 응답을 저장합니다. 캐시는 이전에 원본 서버가 해당 캐시 키의 바이트 범위 요청을 지원한다는 점을 기록한 경우 외에는 바이트 범위 요청을 시작하지 않으므로 두 번째로 콘텐츠에 액세스할 때까지 1MB보다 큰 콘텐츠를 저장하지 않습니다.

분산 특성으로 인해 Cloud CDN은 위치당 두 번 이상 원본에서 최종 청크를 가져오는 경우가 있습니다. 이로 인해 캐시 키당 처음 몇 개의 요청만 영향을 받습니다.

요청 축소(병합)

요청 축소(병합이라고도 함)는 동일한 캐시 키에 대한 여러 사용자 기반 캐시 채움 요청을 에지 노드별 단일 원본 요청으로 축소합니다. 이렇게 하면 원본에서 부하를 적극적으로 줄일 수 있으며 항목 요청(직접 응답을 가져옴) 및 청크 요청 모두에 적용됩니다. 여기서 Cloud CDN은 Range 요청을 사용하여 더 효율적으로 더 큰 객체를 가져옵니다.

요청 축소는 기본적으로 사용 설정됩니다.

축소된 요청은 다음과 같은 방식으로 작동합니다.

  • 축소된 요청은 클라이언트용 요청과 캐시 채우기 요청(축소됨)을 모두 로깅합니다.
  • 축소된 세션의 리더는 원본 채우기 요청을 수행하는 데 사용됩니다.
  • User-Agent 또는 Accept-Encoding 헤더와 같이 캐시 키에 속하지 않는 요청 속성은 축소된 세션의 리더만 반영합니다.
  • 캐시 키가 동일한 요청은 축소될 수 없습니다.

다음 다이어그램은 요청이 병합되는 방식을 보여줍니다.

요청 축소가 사용 설정된 Cloud CDN(확대하려면 클릭)
요청 축소가 사용 설정된 Cloud CDN(확대하려면 클릭)

반면 요청 축소가 사용 중지되었거나 병합될 수 없는 요청의 경우 원본 요청과 응답의 수가 현재 캐시되지 않는 객체를 가져오려고 시도하는 클라이언트 수와 동일할 수 있습니다.

요청 축소가 사용 설정되지 않은 Cloud CDN(확대하려면 클릭)
요청 축소가 사용 설정되지 않은 Cloud CDN(확대하려면 클릭)

모든 유형의 요청에 대해서는 축소가 기본적으로 사용 설정됩니다. 항목 요청 유형의 경우 축소 기능을 사용 중지할 수 있습니다. 이 기능은 원본 부하가 고려되지 않는 광고 게재와 같이 지연 시간에 매우 민감한 시나리오에서 항목 요청을 중지하는 것이 좋습니다.

다음 표는 다양한 요청 유형의 기본 동작과 구성 가능성을 요약합니다.

요청 유형 기본 동작 구성 가능 축소의 이점
청크 요청 사용 설정됨 아니요 원본 대역폭을 상당히 줄일 수 있음
항목 요청 사용 설정됨 원본 요청 볼륨을 줄일 수 있습니다.

Cloud Storage 버킷을 참조하는 백엔드 버킷에 Cloud SDK를 사용하여 항목 요청 축소를 중지하려면 다음 안내를 따르세요.

gcloud

gcloud compute backend-services 또는 backend-buckets 명령어를 사용합니다.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Cloud SDK를 사용하여 백엔드 버킷에서 축소를 사용 설정하려면 다음 안내를 따르세요.

gcloud

gcloud compute backend-buckets 명령어를 사용합니다.

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

VM 그룹 및 외부 백엔드를 비롯한 백엔드 서비스에 Cloud SDK를 사용하여 항목 요청 축소를 사용 설정하려면 다음 안내를 따르세요.

gcloud

gcloud compute backend-services 명령어를 사용합니다.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Cloud CDN에서 시작된 요청

원본 서버가 바이트 범위 요청을 지원하는 경우 Cloud CDN은 단일 클라이언트 요청에 대한 응답으로 여러 요청을 원본 서버에 보낼 수 있습니다. Cloud CDN은 유효성 검사 요청과 바이트 범위 요청, 두 가지 유형의 요청을 시작할 수 있습니다.

원본 서버가 특정 캐시 키의 바이트 범위 요청을 지원한다는 점을 알려주는 응답이 만료된 경우, Cloud CDN은 유효성 검사 요청을 시작하여 콘텐츠가 변경되지 않았고 원본 서버가 콘텐츠의 범위 요청을 여전히 지원하는지 확인합니다. 원본 서버가 304 Not Modified 응답으로 응답하면 Cloud CDN은 바이트 범위를 사용하여 콘텐츠를 제공합니다. 그렇지 않으면 Cloud CDN은 원본 서버의 응답을 클라이언트에 전달합니다. 사용자는 Cache-ControlExpires 응답 헤더를 사용하여 만료 시간을 제어합니다.

캐시 부적중의 경우 Cloud CDN은 클라이언트 요청과 겹치는 바이트 범위 조합의 캐시 채움 요청을 시작합니다. 클라이언트가 요청한 콘텐츠의 일부 범위가 캐시에 있는 경우, Cloud CDN은 캐시에서 가능한 모든 콘텐츠를 제공하고 누락된 범위의 바이트 범위 요청만 원본 서버로 보냅니다.

Cloud CDN에서 시작된 각 바이트 범위 요청은 2,097,136바이트의 배수인 오프셋에서 시작되는 범위를 지정합니다. 최종 범위를 제외하고 각 범위 크기는 2,097,136바이트입니다. 콘텐츠가 해당 크기의 배수가 아니면 최종 범위는 더 작아집니다. 향후에 바이트 범위 요청에 사용되는 크기와 오프셋을 변경할 수 있습니다.

예를 들어 캐시에 없는 콘텐츠의 바이트 1,000,000에서 3,999,999까지에 대한 클라이언트 요청이 있다고 가정합니다. 이 예시에서 Cloud CDN은 GET 요청 두 개를 시작할 수 있습니다. 하나는 콘텐츠의 처음 2,097,136바이트에 대한 요청이고, 다른 하나는 두 번째 2,097,136바이트에 대한 요청입니다. 이에 따라 클라이언트가 3,000,000바이트만 요청한 경우에도 4,194,272바이트의 캐시 채움이 수행됩니다.

Cloud Storage 버킷을 원본으로 사용하는 경우 각 GET 요청은 별도의 클래스 B 작업으로 청구됩니다. Cloud CDN에서 시작된 모든 요청을 포함하여 Cloud Storage에서 처리된 모든 GET 요청에 대해 요금이 청구됩니다. 응답이 Cloud CDN 캐시에서만 제공되는 경우 GET 요청은 Cloud Storage로 전송되지 않고 Cloud Storage 작업에 대한 요금이 청구되지 않습니다.

Cloud CDN은 유효성 검사 요청 또는 바이트 범위 요청을 시작할 때 Cookie 또는 User-Agent 같은 클라이언트 관련 헤더를 포함하지 않습니다.

Cloud Logging httpRequest.userAgent 필드에서 Cloud-CDN-Google은 Cloud CDN이 요청을 시작했음을 의미합니다.

캐시 우회

캐시 우회는 특정 요청 헤더가 포함된 요청이 캐시를 우회하도록 허용합니다. 콘텐츠가 이전에 캐시된 경우에도 마찬가지입니다.

이 섹션에서는 PragmaAuthorization과 같은 HTTP 헤더를 사용하여 캐시를 우회하는 방법을 설명합니다. 이 기능은 사용자 또는 고객이 원본 서버에서 최신 콘텐츠를 항상 가져오도록 하려는 경우 유용합니다. 테스트, 스테이징 디렉터리 설정, 스크립트를 위해 이 작업을 수행하는 것이 좋습니다.

지정된 헤더가 일치하면 모든 캐시 모드 설정에 대해 캐시가 우회됩니다. FORCE_CACHE_ALL도 마찬가지입니다. 지정된 헤더가 많은 요청에서 공통된 경우 캐시 우회가 다수의 캐시 부적중을 유발합니다.

시작하기 전에

  • Cloud CDN이 사용 설정되어 있는지 확인합니다. 자세한 내용은 Cloud CDN 사용을 참조하세요.

  • 필요한 경우 Cloud SDK를 최신 버전으로 업데이트합니다.

    gcloud components update
    

캐시 우회 구성

최대 5개의 HTTP 헤더 이름을 지정할 수 있습니다. 값은 대소문자를 구분하지 않습니다. 헤더 이름은 올바른 HTTP 헤더 필드 토큰이어야 합니다. 헤더 이름은 추가된 헤더 목록에 두 번 이상 나타나지 않아야 합니다. 유효한 헤더 이름에 관한 규칙은 커스텀 헤더 작동 방식을 참조하세요.

콘솔

  1. Google Cloud Console에서 부하 분산 페이지로 이동합니다.

    부하 분산 페이지로 이동

  2. 외부 HTTP(S) 부하 분산기의 이름을 클릭합니다.
  3. 수정 을 클릭합니다.
  4. 백엔드 구성에서 백엔드를 선택하고 수정 을 클릭합니다.
  5. Cloud CDN 사용 설정이 선택되어 있는지 확인합니다.
  6. 창 하단에서 고급 구성을 클릭합니다.
  7. 요청 헤더에서 캐시 우회 아래에서 헤더 추가를 클릭합니다.
  8. Pragma 또는 Authorization과 같은 헤더 이름을 입력합니다.
  9. 업데이트를 클릭합니다.
  10. 업데이트를 다시 클릭합니다.

gcloud

백엔드 버킷의 경우 --bypass-cache-on-request-headers 플래그와 함께 gcloud compute backend-buckets create 또는 gcloud compute backend-buckets update 명령어를 사용합니다.

백엔드 서비스의 경우 --bypass-cache-on-request-headers 플래그와 함께 gcloud compute backend-services create 또는 gcloud compute backend-services update 명령어를 사용합니다.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER
gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

예를 들면 다음과 같습니다.

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

api

백엔드 버킷의 경우 Method: backendBuckets.insert, Method: backendBuckets.update 또는 Method: backendBuckets.patch API 호출을 사용합니다.

백엔드 서비스의 경우 Method: backendServices.insert, Method: backendServices.update 또는 Method: backendServices.patch API 호출을 사용합니다.

예를 들면 다음과 같습니다.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

JSON 요청 본문에 다음 스니펫을 추가합니다.

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

캐시 우회 사용 중지

gcloud

백엔드 버킷의 경우 --no-bypass-cache-on-request-headers 플래그와 함께 gcloud compute backend-buckets create 또는 gcloud compute backend-buckets update 명령어를 사용합니다.

백엔드 서비스의 경우 --no-bypass-cache-on-request-headers 플래그와 함께 gcloud compute backend-services create 또는 gcloud compute backend-services update 명령어를 사용합니다.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

api

백엔드 버킷의 경우 Method: backendBuckets.insert 또는 Method: backendBuckets.update API 호출을 사용합니다.

백엔드 서비스의 경우 Method: backendServices.insert 또는 Method: backendServices.update API 호출을 사용합니다.

다음 API 호출 중 하나를 사용합니다.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

JSON 요청 본문에 다음 스니펫을 추가합니다.

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

다음 단계

  • 캐시 모드가 콘텐츠를 더 쉽게 캐시하는 방법을 알아보려면 캐시 모드 사용을 참조하세요.
  • HTTP(S) 부하 분산 인스턴스 및 스토리지 버킷에 Cloud CDN을 사용 설정하려면 Cloud CDN 사용을 참조하세요.
  • 캐시 무효화에 대한 자세한 내용은 캐시 무효화 개요를 참조하세요.
  • GFE 접속 지점을 찾으려면 캐시 위치를 참조하세요.