캐시 세부정보

캐시 저장 가능성

모든 HTTP 응답을 캐시할 수 있는 것은 아닙니다. Cloud CDN은 이 섹션의 모든 요구 사항을 충족하는 응답만을 캐시합니다. 이러한 요구 사항 중 일부는 RFC 7234에 명시되어 있으며, 다른 일부는 Cloud CDN에 지정됩니다.

다음 사항에 모두 해당되는 경우에만 Cloud CDN 캐시에 응답을 저장할 수 있습니다.

  • Cloud CDN을 사용하는 백엔드 서비스 또는 백엔드 버킷에 의해 제공됩니다.
  • GET 요청에 대한 응답입니다.
  • 상태 코드가 200, 203, 206, 300, 301, 302, 307, 410입니다.
  • Cache-Control: public 헤더를 가집니다.
  • Cache-Control: s-maxage, Cache-Control: max-age 또는 Expires 헤더를 가집니다.
  • Content-Length, Content-Range 또는 Transfer-Encoding 헤더를 가집니다.
  • 크기가 최대 크기보다 작거나 같습니다.

백엔드 버킷의 경우 Cloud Storage 객체를 공개적으로 표시하여 이러한 요구 사항을 충족할 수 있습니다. 개별 객체를 공개적으로 표시하는 대신 버킷을 공용으로 만드는 경우 각 객체의 메타데이터에 필요한 Cache-Control 헤더를 추가해야 합니다.

또한 응답 캐시를 차단하는 검사가 있습니다. 다음 중 하나라도 해당되면 응답이 캐시되지 않습니다.

  • Set-Cookie 헤더를 가집니다.
  • 값이 Accept, Accept-Encoding 또는 Origin이 아닌 Vary 헤더를 가집니다.
  • Cache-Control: no-store, no-cache 또는 private 지시문을 가집니다.
  • 해당 요청에 Cache-Control: no-store 지시문이 있습니다.

이러한 요구 사항은 추후에 보다 완화되어 Cloud CDN에서 추가 응답을 캐시할 수 있게 될 수 있습니다. 응답이 캐시되지 않도록 방지하는 방법은 캐싱 방지 섹션을 참조하세요.

최대 크기

Cloud CDN은 원본 서버의 바이트 범위 요청 지원 여부에 따라 다음과 같이 최대 크기를 적용합니다.

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

최대 크기보다 큰 본문에 대한 응답은 캐시되지 않습니다.

캐시 항목

캐시 키

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

  • 프로토콜: 키에서 프로토콜을 생략할 수 있습니다. 프로토콜을 생략하면 https://example.com/images/cat.jpg의 요청이 example.com/images/cat.jpg 캐시 키를 받습니다. 그런 후에 https://example.com/images/cat.jpghttp://example.com/images/cat.jpg의 요청은 모두 해당 캐시 항목에 일치되는 것으로 간주됩니다.
  • 호스트: 키에서 호스트를 생략할 수 있습니다. 호스트를 생략하면 example.comexample2.com의 요청 모두 동일한 캐시 항목과 일치할 수 있습니다. 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 캐시 키를 받으므로 https://example.com/images/cat.jpg?user=user1https://example.com/images/cat.jpg?user=user2 모두 동일한 항목과 일치할 수 있습니다. 쿼리 문자열의 일부를 선택적으로 생략하거나 포함할 수도 있습니다.

전체 쿼리 문자열 포함 또는 생략 이외에 허용 목록과 블랙리스트를 통해 쿼리 문자열의 일부를 사용할 수도 있습니다.

백엔드 버킷의 경우 캐시 키는 쿼리 문자열이 없는 URI로 구성됩니다. 따라서 https://example.com/images/cat.jpg, https://example.com/images/cat.jpg?user=user1, https://example.com/images/cat.jpg?user=user2는 동일합니다.

쿼리 문자열 허용 목록

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 캐시 키를 만듭니다. 이 옵션을 사용하려면 쿼리 문자열을 포함하고 비어 있지 않은 허용 목록을 지정하되 블랙리스트는 지정하지 않아야 합니다.

쿼리 문자열 블랙리스트

클라우드 CDN이 블랙리스트를 통해 무시하는 쿼리 문자열 매개변수를 선택적으로 제어할 수 있습니다. 예를 들어, user 블랙리스트를 만들면 user제외한 모든 쿼리 문자열 매개변수가 캐시 키에서 사용됩니다.

위의 블랙리스트가 구성된 상태에서 https://example.com/images/cat.jpg?user=user1&color=blue가 입력되면 Cloud CDN은 https://example.com/images/cat.jpg?color=blue와 일치하지만 https://example.com/images/cat.jpg?user=user1&color=red와는 일치하지 않는 https://example.com/images/cat.jpg?user=user2&color=blue 캐시 키를 만듭니다. 이 옵션을 사용하려면 쿼리 문자열을 포함하고 비어 있지 않은 블랙리스트를 지정하되 허용 목록은 지정하지 않아야 합니다.

Vary 헤더

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

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

Vary 헤더가 있는 응답은 캐시 저장 가능성에 나열된 값 중 하나가 헤더에 있는 경우에만 캐시됩니다.

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

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

Cloud CDN이 요청을 받으면 해당 캐시 항목을 조회하고 저장 기간을 확인합니다. 캐시 항목이 존재하고 새 항목이면 캐시에서 응답을 제공할 수 있습니다. 그러나 만료 시간이 경과하면 Cloud CDN은 백엔드 중 하나에 먼저 연락하지 않고 응답을 제공할 수 없습니다.

이전에 캐시된 응답에 Last-Modified 또는 ETag 헤더가 있는 경우, Cloud CDN은 해당 헤더의 정보를 사용하여 백엔드가 있는 캐시 항목의 유효성을 검사할 수 있습니다. 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일 동안 액세스되지 않은 캐시 항목은 자동으로 삭제됩니다.

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

바이트 범위 요청 지원

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

  • 상태 코드가 200 OK이거나 206 Partial Content인 경우
  • Accept-Ranges: bytes 헤더가 있는 경우
  • Content-Length 또는 Content-Range 헤더가 있는 경우
  • 강력한 유효성 검사 기능이 있는 ETag 헤더 또는 Last-Modified 헤더가 있는 경우

Google 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은 단일 클라이언트 요청에 대한 응답으로 여러 요청을 원본 서버에 보낼 수 있습니다. 아래 설명과 같이 Cloud CDN은 유효성 검사 요청과 바이트 범위 요청 등 두 가지 유형의 요청을 시작할 수 있습니다.

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

캐시 부적중의 경우 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 CDN 캐시에 캐싱되지 않도록 방지하려면 다음 단계를 따릅니다.

  1. Cloud CDN 캐시에 저장하지 않아야 할 응답에는 Cache-Control: private 헤더를 포함하고, 웹 브라우저의 캐시를 포함한 모든 캐시에 저장하지 않아야 할 응답에는 Cache-Control: no-store 헤더를 포함합니다.
  2. 개인 정보에 대한 액세스를 제공하는 URL에 서명하지 않습니다. 서명된 URL을 사용하여 콘텐츠에 액세스하면 응답의 Cache-Control 지시문에 관계없이 잠재적으로 캐싱할 수 있습니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Cloud CDN 문서