캐싱 동작 구성

Media CDN은 Google의 글로벌 에지 캐싱 인프라를 사용하여 콘텐츠를 캐시하고 원본 인프라의 부하를 줄여 사용자에게 최대한 가까운 콘텐츠를 제공합니다.

각 경로에 대해 콘텐츠가 캐시되는 방식을 제어할 수 있습니다. 이렇게 하면 콘텐츠 유형, 클라이언트 요청 속성, 최신 상태 요구사항에 따라 동작을 최적화할 수 있습니다.

캐시 저장 가능성

다음 섹션에서는 Media CDN이 캐시하는 응답과 캐시 오프로드를 개선하는 방법을 설명합니다.

기본 캐싱 동작

기본적으로 다음 캐시 관련 설정이 각 에지 캐시 서비스에 적용됩니다.

• CACHE_ALL_STATIC의 기본 캐시 모드:

  • Cache-Control 또는 Expires와 같은 원본 캐시 지시문을 구성 가능한 최대 TTL까지 적용합니다.
  • 원본 캐시 지시문이 없는 경우 기본 TTL이 3600초인 정적 미디어 유형을 자동으로 캐시합니다.
  • HTTP 200 및 206 상태 코드를 캐시합니다(음성 캐싱이 사용 설정되지 않음).

• no-store 또는 private 캐시 관리 지시문이 있거나 캐시할 수 없는 응답은 캐시하지 않습니다.

정적 콘텐츠가 아니거나 유효한 캐시 지시문이 없는 응답은 캐싱이 명시적으로 구성되지 않는 한 캐시되지 않습니다. 기본 동작을 재정의하는 방법을 알아보려면 캐시 모드 문서를 참조하세요.

기본 동작은 다음 cdnPolicy와 동일합니다. 명시적 cdnPolicy가 구성되지 않은 경로는 다음 구성을 사용하는 것처럼 동작합니다.

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

캐시 가능한 응답

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

원본이 응답에서 캐시 관리 지시문을 설정하지 않은 경우에도 각 경로의 캐시 모드를 구성하여 이 동작을 재정의할 수 있습니다(예: CACHE_ALL_STATIC 캐시 모드를 사용하여 일반적인 미디어 유형 캐시).

캐시 불가능한 응답에 정의된 기준을 충족하는 요청과 응답은 캐시 저장 가능성을 대체합니다.

다음 표에서는 특정 HTTP 응답을 캐시하기 위한 요구사항을 설명합니다. GET 응답과 HEAD 응답 모두 이러한 요구사항을 준수해야 합니다.

HTTP Age 헤더는 Media CDN이 응답을 처음 캐시한 시점을 기준으로 설정되며 일반적으로 객체가 원본 보호 위치에 캐시된 이후의 시간(초)을 나타냅니다. 원본이 Age 응답 헤더를 생성하는 경우 Age가 캐시 TTL을 초과하면 FORCE_CACHE_ALL 캐시 모드를 사용하여 재검증을 방지합니다.

Media CDN이 HTTP 캐싱 지시문을 해석하는 방법에 대한 자세한 내용은 캐시 관리 지시문을 참조하세요.

원본 요구사항

Media CDN이 1MiB보다 큰 원본 응답을 캐시하도록 허용하려면 달리 지정되지 않는 한 원본은 HEAD 요청과 GET 요청 모두의 응답 헤더에 다음을 포함해야 합니다.

• Last-Modified 또는 ETag HTTP 응답 헤더(검사기)
• 유효한 HTTP Date 헤더
• 유효한 Content-Length 헤더
• Range GET 요청에 대한 응답의 Content-Range 응답 헤더. Content-Range 헤더에는 bytes x-y/z 형식의 유효한 값이 있어야 합니다(여기서 z는 객체 크기).

기본 원본 프로토콜은 HTTP/2입니다. 원본이 HTTP/1.1만 지원하는 경우 각 원본에 대해 프로토콜 필드를 명시적으로 설정할 수 있습니다.

캐시 불가능한 응답

다음 표에서는 응답이 캐시되지 않도록 하는 요청 및 응답 속성을 자세히 설명합니다. 캐시할 수 있지만 '캐시 불가능' 기준과 일치하는 응답은 캐시되지 않습니다.

구성된 캐시 모드에 추가로 다음 규칙이 적용됩니다. 구체적으로는 다음과 같습니다.

• CACHE_ALL_STATIC 캐시 모드가 구성되면 정적 콘텐츠로 간주되는 응답 또는 응답 헤더에 유효한 캐시 지시문이 있는 응답만 캐시됩니다. 다른 응답은 있는 그대로 프록시됩니다.
• FORCE_CACHE_ALL 캐시 모드는 앞에서 설명한 캐시 저장 불가능성 요구사항에 따라 모든 응답을 무조건적으로 캐시합니다.
• USE_ORIGIN_HEADERS 캐시 모드에서는 캐시 가능한 상태 코드 외에 응답 헤더에 유효한 캐시 지시문을 설정할 응답이 필요합니다.

참고:

• 캐시되지 않은 응답은 캐시 관리 지시문이나 기타 헤더가 변경되지 않고 있는 그대로 프록시됩니다.
• 응답은 Cache-Control 및 Expires 헤더를 단일 Cache-Control 필드로 축소할 수 있습니다. 예를 들어 별도의 행에 Cache-Control: public 및 Cache-Control: max-age=100이 포함된 응답은 Cache-Control: public,max-age=100으로 축소됩니다.
• 캐시 불가능한 응답(캐시되지 않는 응답)은 결제 관점에서 Cache Egress로 집계되지 않습니다.

캐시 모드 사용

캐시 모드를 사용하면 Media CDN이 원본 캐시 지시문을 적용하고 정적 미디어 유형을 캐시하며 설정된 지시문에 관계없이 원본의 모든 응답을 캐시해야 하는 시기를 구성할 수 있습니다.

캐시 모드는 경로 수준에서 구성되며 TTL 재정의와 결합되어 호스트, 경로, 쿼리 매개변수, 헤더(일치 가능한 모든 요청 매개변수)별로 캐시 동작을 구성할 수 있습니다.

• 기본적으로 Media CDN은 1시간(3,600초) 동안 일반 정적 미디어 유형을 자동으로 캐시하는 동시에 캐시 가능한 응답에 대해 원본에서 지정한 캐시 지시문을 우선적으로 사용하도록 지정하는 CACHE_ALL_STATIC 캐시 모드를 사용합니다.
• 경로에 cdnPolicy.defaultTtl 필드를 설정하여 명시적 캐시 TTL(max-age 또는 s-maxage 지시문)이 설정되지 않는 응답에 적용되는 캐시 TTL을 늘리거나 줄일 수 있습니다.
• 비성공 응답을 의도한 것보다 오래 캐시하지 않도록 2xx가 아닌(비성공) 상태 코드는 Content-Type(MIME 유형)에 따라 캐시되지 않으며 기본 TTL이 적용되지 않습니다.

각 경로의 cdnPolicy.cacheMode에 설정된 사용 가능한 캐시 모드는 다음 표에 나와 있습니다.

정적 콘텐츠 MIME 유형

CACHE_ALL_STATIC 캐시 모드를 사용하면 Media CDN이 Content-Type HTTP 응답 헤더에서 반환된 MIME 유형을 기반으로 동영상, 오디오, 이미지, 일반 웹 애셋과 같은 일반 정적 콘텐츠를 자동으로 캐시할 수 있습니다. 그러나 미디어 유형에 관계없이 Media CDN은 원본 응답에서 명시적 Cache-Control 또는 Expires 헤더를 우선적으로 사용하도록 지정합니다.

다음 표에는 CACHE_ALL_STATIC 캐시 모드로 자동으로 캐시할 수 있는 MIME 유형이 나와 있습니다.

다음 값과 일치하는 값을 가진 Content-Type 응답 헤더가 없는 경우 응답이 자동으로 캐시되지 않습니다. 응답이 유효한 캐시 지시문을 설정했는지 확인하거나 FORCE_CACHE_ALL 캐시 모드를 사용하여 응답을 무조건적으로 캐시해야 합니다.

다음에 유의하세요.

• 원본의 웹 서버 소프트웨어는 응답마다 Content-Type을 설정해야 합니다. 많은 웹 서버가 NGINX, Varnish, Apache를 포함한 Content-Type 헤더를 자동으로 설정합니다.
• Cloud Storage는 Google Cloud 콘솔이나 gcloud CLI를 사용하여 콘텐츠를 업로드하면 업로드 시 자동으로 Content-Type 헤더를 설정합니다.
• Cloud Storage는 항상 미디어 CDN에 Cache-Control 헤더를 제공합니다. 값을 명시적으로 선택하지 않으면 기본값이 전송됩니다. 따라서 Cloud Storage의 객체에 대한 캐시 제어 메타데이터를 명시적으로 조정하거나 FORCE_CACHE_ALL 모드를 사용하여 Cloud Storage에서 전송한 값을 재정의하지 않는 한 성공적인 모든 Cloud Storage 응답은 Cloud Storage 기본값에 따라 캐시됩니다.

MIME 유형에 따라 응답을 캐시할 수 있지만 private, no-store 또는 Set-Cookie 헤더의 Cache-Control 응답 지시문이 있으면 응답이 캐시되지 않습니다.

HTML (text/html) 및 JSON(application/json)과 같은 다른 미디어 유형은 기본적으로 캐시되지 않습니다. 이러한 유형의 응답은 일반적으로 동적(사용자별) 응답이며 Media CDN 아키텍처에는 적합하지 않습니다. 웹 애셋 제공 및 API 응답 캐시에 Cloud CDN을 사용하는 것이 좋습니다.

캐시 TTL 구성

TTL (수명) 재정의를 사용하면 캐시된 콘텐츠의 기본 TTL 값을 설정하고 원본으로 설정된 max-age 및 s-maxage 캐시 관리 지시문(또는 Expires 헤더)에 설정된 TTL 값을 재정의할 수 있습니다.

재정의로 설정되었는지 또는 캐시 지시문을 사용하여 설정되었는지 여부에 관계없이 TTL은 낙관적입니다. 액세스 빈도가 낮거나 인기가 없는 콘텐츠는 TTL에 도달하기 전에 캐시에서 제거될 수 있습니다.

다음 표에는 세 가지 TTL 설정이 나와 있습니다.

TTL 값을 제로(0초)로 설정하면 응답이 제공되기 전에 모든 요청이 원본으로 재검증되며 너무 광범위하게 설정된 경우 원본에 대한 부하가 증가합니다.

캐시 모드가 Use Origin Headers로 설정되면 Media CDN이 원본을 사용하여 동작을 구동하므로 TTL 설정을 구성할 수 없습니다.

참고:

• 최대 TTL 값은 항상 기본 TTL 값보다 크거나 같아야 합니다.
• 클라이언트 TTL 값은 항상 최대 TTL 값보다 작거나 같아야 합니다.
• Media CDN이 원본 TTL 값을 재정의하면 클라이언트에 대한 Cache-Control 헤더에도 해당 값이 반영됩니다.
• 원본이 Expires 헤더를 설정하고 Media CDN이 타임스탬프를 기준으로 유효한 TTL을 재정의하는 경우 클라이언트에 대한 다운스트림 응답에서 Expires 헤더가 Cache-Control 헤더로 변경됩니다.

음성 캐싱

음성 캐싱은 Media CDN에 의해 비성공 HTTP 상태 코드(2xx 이외의 상태 코드)가 캐시되는 방식을 정의합니다.

이를 통해 리디렉션(HTTP 301 및 308) 및 찾을 수 없음(HTTP 404) 응답과 같은 오류 응답을 사용자에게 더 가까이 캐시할 수 있고, 응답이 변경될 가능성이 낮고 캐시될 수 있는 경우 원본 부하를 더 광범위하게 줄일 수 있습니다.

기본적으로 음성 캐싱은 사용 중지되어 있습니다. 다음 표에는 음성 캐싱이 사용 설정되고 negativeCachingPolicy가 사용되지 않는 경우 각 상태 코드의 기본값이 나와 있습니다.

기본 음성 캐싱 코드 집합은 HTTP RFC 9110에 설명된 대로 휴리스틱 방식으로 캐시 가능한 상태 코드와 일치하지만 다음과 같은 예외가 있습니다.

• HTTP 코드 414(URI가 너무 김)는 캐시 포이즈닝을 방지하기 위해 캐싱에 지원되지 않습니다.
• HTTP 코드 451(법적 사유로 사용할 수 없음)은 HTTP RFC 7725에 설명된 대로 캐싱에 지원됩니다.

자체 상태 코드별 TTL을 구성하고 기본 동작을 재정의해야 하는 경우 cdnPolicy.negativeCachingPolicy를 구성할 수 있습니다. 이렇게 하면 Media CDN에서 허용하는 상태 코드(300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503, 504)의 TTL을 설정할 수 있습니다.

예를 들어 HTTP 404(찾을 수 없음) 응답에 짧은 5초 TTL을 설정하고 HTTP 405(허용되지 않는 메서드) 응답에 10초 TTL을 설정하려면 각 해당 경로에 다음 YAML 정의를 사용합니다.

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

캐시 포이즈닝을 방지하려면 상태 코드 400(잘못된 요청) 또는 403(금지됨)에 대해 캐싱을 사용 설정하지 않는 것이 좋습니다. 캐시 키에 포함된 요청의 구성요소만 검사한 결과 원본 서버가 두 코드 중 하나를 반환하는지 확인합니다. 예를 들어 올바른 Authorization 헤더가 없는 경우 원본 서버가 403 오류 응답으로 응답하면 캐시 포이즈닝이 발생할 수 있습니다. 이 경우 403 오류 응답을 캐시하면 요청에 올바른 Authorization 헤더가 있더라도 TTL이 만료될 때까지 Media CDN이 모든 후속 요청에 403 오류 응답을 제공합니다.

음성 캐싱을 사용 중지하려면 다음 안내를 따르세요.

• 기본 음성 캐싱 동작을 사용 중지하려면 경로에 cdnPolicy.negativeCaching: false를 설정합니다. 유효한 캐시 지시문 및 캐시 가능한 상태 코드가 있는 원본 응답은 계속 캐시됩니다.
• 특정 상태 코드에 대한 음성 캐싱을 방지하지만 원본 캐시 지시문을 계속 적용하려면 negativeCachingPolicy 정의에서 상태 코드(cdnPolicy.negativeCachingPolicy[].code)를 생략합니다.
• 특정 상태 코드의 원본 캐시 지시문을 명시적으로 무시하려면 해당 상태 코드에서 cdnPolicy.negativeCachingPolicy[].ttl을 0(제로)으로 설정합니다.

참고:

• 경로에 negativeCaching가 사용 설정되어 있고 응답에 유효한 캐시 지시문이 정의되어 있으면 응답의 캐시 지시문이 우선 적용됩니다.
• 명시적 negativeCachingPolicy를 구성하는 경우 지정된 상태 코드에 정의된 TTL이 있으면 정책에 정의된 TTL이 항상 사용됩니다.
• negativeCachingPolicy로 설정된 TTL의 최댓값은 1,800초(30분)이지만 TTL이 더 높은 원본 캐시 지시문이 적용됩니다.
• 캐시 모드가 FORCE_CACHE_ALL로 구성되면 원본 지시문은 모든 경우에 무시됩니다.

캐시 관리 지시문

Cache-Control 지시문과 관련된 Media CDN의 동작이 여기에 정의되어 있습니다.

only-if-cached(클라이언트 전용 지시문)와 같이 요청 또는 응답에 지시문을 적용할 수 없는 경우 해당 열에 '해당 사항 없음'이 표시됩니다.

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

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

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

HTTP/1.0 Pragma 헤더가 응답에 있는 경우 이 헤더는 무시되며 클라이언트에 그대로 전달됩니다.

캐시 키

요청을 고유하게 식별하는 항목을 고려하고 요청 간에 자주 변경될 수 있는 구성요소를 삭제하여 Media CDN이 원본에 연결해야 하는 횟수를 줄일 수 있습니다. 요청 구성요소 집합을 '캐시 키'라고도 합니다.

다음 섹션에서는 캐시 키를 구성하는 방법을 설명합니다.

캐시 키 구성요소

캐시 키는 캐시된 객체가 참조되는 요청 매개변수(예: 호스트, 경로, 쿼리 매개변수) 집합입니다.

기본적으로 에지 캐시 서비스의 캐시 키는 요청의 요청 호스트, 경로, 쿼리 매개변수를 포함하며 특정 EdgeCacheService로 범위가 지정됩니다.

다음에 유의하세요.

• 캐시 키는 구성된 원본에 연결되지 않으므로 캐시를 '플러시'할 위험 없이 원본 구성을 업데이트하거나 원본을 완전히 바꿀 수 있습니다(예: 제공업체 간에 원본 스토리지를 마이그레이션할 때).
• 캐시 키는 EdgeCacheService로 제한됩니다. EdgeCacheServices마다 캐시 네임스페이스가 서로 다르므로 호스트, 경로 또는 기타 캐시 키 구성요소가 일치하더라도 프로덕션, 스테이징, 기타 테스트 환경 간에 실수로 객체를 캐시하는 것을 방지할 수 있습니다. EdgeCacheService를 삭제하면 해당 서비스의 모든 캐시된 객체가 효과적으로 무효화됩니다.
• 캐시 키는 개별 경로로 범위가 지정되지 않습니다. 여러 경로는 특히 해당 경로가 요청 헤더 또는 제외된 매개변수와 같이 캐시 키에 포함되지 않은 구성요소에서 일치하는 경우 동일한 캐시 키를 참조할 수 있습니다. 이는 여러 경로가 동일한 캐시를 공유하지만 다른 응답 헤더 또는 CORS 구성을 반환하도록 하려는 경우에 유용할 수 있습니다.
• 캐시 키에는 URL 재작성 구성이 포함되지 않습니다. 예를 들어 캐시 키는 '재작성된' 최종 요청이 아닌 사용자 대상 요청을 기반으로 합니다.
• 서명된 요청이 경로에 구성된 경우 서명된 속성은 캐시 키에 포함되지 않습니다. 요청은 edge-cache-token으로 시작하고 다음 경로 구분자('/')로 끝나는 (서명된) 쿼리 매개변수 또는 경로 구성요소가 URL의 일부가 아닌 것처럼 처리됩니다.

쿼리 매개변수 포함 또는 제외

특정 경로의 includedQueryParameters 또는 excludedQueryParameters 캐시 키 구성에 매개변수 이름을 추가하여 캐시 키에서 특정 쿼리 매개변수를 포함하거나 제외할 수 있습니다.

예를 들어 contentID 및 country 쿼리 매개변수를 포함하고 캐시 키에서 다른 모든 쿼리 매개변수를 무시하려면 다음을 사용하세요.

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

콘텐츠를 고유하게 식별하는 쿼리 매개변수를 포함하고 그렇지 않은 쿼리 매개변수는 제외해야 합니다. 예를 들어 분석 쿼리 매개변수, 재생 세션 ID, 클라이언트에만 고유한 기타 매개변수를 제외합니다. 쿼리 매개변수를 필요 이상으로 포함하면 캐시 적중률이 감소할 수 있습니다.

또는 캐시 키에 포함할 매개변수를 지정하는 대신 캐시 키에서 제외할 매개변수를 선택할 수 있습니다. 예를 들어 캐시 키에서 클라이언트별 재생 ID와 타임스탬프 정보를 제외하려면 다음을 구성합니다.

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

특정 경로의 경우 includedQueryParameters 또는 excludedQueryParameters 중 하나를 지정할 수 있습니다.

쿼리 매개변수가 요청 전체에서 콘텐츠를 고유하게 식별하는 데 사용되지 않는 경우 경로의 캐시 키에서 모든 쿼리 매개변수를 삭제할 수 있습니다. 다음과 같이 excludeQueryString을 true로 설정하면 됩니다.

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

경로에 서명된 요청이 사용 설정된 경우 서명에 사용되는 쿼리 매개변수가 쿼리 문자열에 포함되지 않으며 포함된 경우 무시됩니다. 캐시 키에 서명된 매개변수를 포함하면 각 사용자 요청이 효과적으로 고유하게 되며 각 요청이 원본에서 제공되어야 합니다.

쿼리 매개변수 정렬

쿼리 매개변수(쿼리 문자열)는 캐시 적중률을 향상시키기 위해 기본적으로 정렬됩니다. 클라이언트가 쿼리 매개변수 순서가 다른 동일한 캐시된 객체를 재정렬하거나 요청할 수 있기 때문입니다.

예를 들어 쿼리 매개변수 b=world&a=hello&z=zulu&p=paris 및 p=paris&a=hello&z=zulu&b=world는 캐시 키가 파생되기 전에 a=hello&b=world&p=paris&z=zulu로 정렬됩니다. 이렇게 하면 두 요청 모두 동일한 캐시된 객체에 매핑되므로 원본에 대한 불필요한 요청(및 응답)을 방지할 수 있습니다.

각각 고유한 값을 가진 쿼리 매개변수 키의 인스턴스가 여러 개 있는 경우 매개변수는 전체 값을 기준으로 정렬됩니다(예: a=hello는 a=world보다 먼저 정렬됨). 정렬을 중지할 수 없습니다.

헤더 포함

헤더 이름은 대소문자를 구분하지 않으며 Media CDN에 의해 소문자로 변환됩니다.

다음 헤더는 캐시 키에 포함될 수 없습니다.

• access-control-로 시작하는 모든 헤더
• sec-fetch-로 시작하는 모든 헤더
• x-amz-로 시작하는 모든 헤더
• x-goog-로 시작하는 모든 헤더
• x-media-cdn-로 시작하는 모든 헤더
• accept-encoding
• accept
• authorization
• cdn-loop
• connection
• content-md5
• content-type
• cookie
• date
• forwarded
• from
• host
• if-match
• if-modified-since
• if-none-match
• origin
• proxy-authorization
• range
• referer
• referrer
• user-agent
• want-digest
• x-csrf-token
• x-csrftoken
• x-forwarded-for

캐시 키에 HTTP 메서드를 포함하려면 특수 헤더 이름 :method를 사용합니다.

쿠키 포함

쿠키 이름은 대소문자를 구분합니다.

대문자 또는 소문자의 변형으로 edge-cache-로 시작하는 쿠키는 캐시 키에 사용할 수 없습니다.

재검증, 제거, 만료

Media CDN을 비롯한 콘텐츠 전송 네트워크는 가장 인기 있는 콘텐츠를 사용자에게 최대한 가깝게 캐시하여 작동합니다.

Media CDN의 광범위한 스토리지와 원본 보호 덕분에 인기가 없는 콘텐츠도 제거할 필요가 있습니다. 하루에 적은 횟수로 액세스되는 콘텐츠는 결국 제거될 수 있습니다.

• 구성된 TTL에 도달하는 캐시된 응답은 즉시 제거되지 않을 수 있습니다. 인기 콘텐츠의 경우 Media CDN은 헤더가 변경되지 않았는지 확인하기 위해 HEAD 요청을 원본에 실행하여 캐시된 응답이 최신 버전인지 재검증합니다. 경우에 따라 Media CDN은 대신 이러한 요청 헤더 If-None-Match 및 If-Modified-Since 중 하나 또는 모두를 사용하여 요청을 원본에 보냅니다. 이 경우 올바르게 구성된 원본은 캐시에 해당 응답의 '최신' 복사본이 있는 경우 본문 바이트 없이 HTTP 304(수정되지 않음) 응답을 반환해야 합니다.
• max-age 또는 s-maxage 캐시 지시문을 설정하거나 TTL 재정의를 사용하여 높은 TTL 값(예: 30일)을 지정하는 응답은 전체 TTL 동안 캐시에 저장되지 않을 수 있습니다. 특히 자주 액세스하지 않는 경우 객체가 전체 기간 동안 캐시에 저장된다는 보장은 없습니다.

제거율이 높으면 응답을 고유하게 식별하지 않는 매개변수를 제외하도록 캐시 키를 구성했는지 확인해야 합니다.

기타 고려사항

캐싱과 관련하여 다음 고려사항도 적용될 수 있습니다.

Vary 헤더

Vary 헤더는 클라이언트의 요청 헤더에 따라 응답이 달라짐을 나타냅니다. 응답에 Vary 헤더가 있는 경우 헤더가 캐시 키 설정으로 구성된 헤더 중 하나 또는 다음 값 중 하나를 지정하지 않는 한 Media CDN은 이를 캐시하지 않습니다.

• Accept: 클라이언트가 허용하는 미디어 유형을 나타내는 데 사용됩니다.
• Accept-Encoding: 클라이언트가 허용하는 압축 유형을 나타내는 데 사용됩니다.
• Available-Dictionary: 압축에 사용 가능한 사전의 해시를 제공하는 데 사용됩니다.
• Origin/X-Origin: 일반적으로 교차 출처 리소스 공유에 사용됩니다.
• X-Goog-Allowed-Resources: Google Cloud 조직 액세스 제한을 지원합니다.
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: 메타데이터 요청 헤더를 가져오는 데 사용됩니다.

Media CDN은 헤더 값을 캐시 키의 일부로 사용하여 응답에 Vary 헤더가 포함된 응답을 캐시합니다. 응답의 Vary 헤더에 여러 값이 있으면 캐시 키가 확정되도록 사전순으로 정렬됩니다.

Media CDN은 지정된 캐시 키에 대해 최대 100개의 변이를 캐시하고 이 한도를 초과하는 변이를 캐시에서 무작위로 제거합니다. 지정된 URL 또는 캐시 태그에 대해 캐시를 명시적으로 무효화하면 모든 변이가 무효화됩니다.

캐시 우회

일치하는 요청 시 의도적으로 캐시를 우회하도록 경로에 BYPASS_CACHE 캐시 모드를 구성할 수 있습니다. 이는 중요하지 않은 일부 트래픽에 대해 캐시를 우회하거나 원본 연결을 디버그해야 하는 경우에 유용할 수 있습니다.

API 백엔드와 같은 동적 응답을 제공해야 하는 경우에는 외부 애플리케이션 부하 분산기를 구성하는 것이 좋습니다.

의도치 않은 원본 부하를 방지하기 위해 일반적으로 디버깅 시나리오로 제한하여 사용하는 것이 좋습니다. 캐시를 우회할 때 이그레스되는 트래픽은 인터넷 이그레스 요율에 따라 가격이 책정됩니다.

캐시 무효화

캐시 무효화를 참조하세요.

바이트 범위 요청

Media CDN은 RFC 7233에 정의된 대로 단일 부분 HTTP 범위 요청을 지원합니다.

또한 Media CDN은 범위 요청을 사용하여 원본에서 더 큰 응답을 가져옵니다. 이렇게 하면 Media CDN이 청크를 개별적으로 캐시할 수 있으며 캐시하기 위해 전체 객체를 한 번에 가져올 필요가 없습니다.

• 1MiB보다 큰 객체는 각각 최대 2MiB의 바이트 범위 요청('청크')으로 가져옵니다.
• 원본에서 바이트 범위를 지원하지 않으므로 최대 1MiB의 응답은 가져올 수 있습니다.
• 바이트 범위가 원본에서 지원되지 않는 경우 이보다 큰 응답은 제공되지 않습니다.

바이트 범위 요청의 원본 지원은 다음에 따라 결정됩니다.

• HTTP 상태 코드 200(OK) 또는 206(Partial Content).
• 유효한 Content-Length 또는 Content-Range 응답 헤더.
• 응답 검사기(ETag 또는 Last-Modified).

각 '청크'(바이트 범위)에 대한 개별 원본 채우기 요청은 개별 로그 항목으로 로깅되고 해당 상위 클라이언트 요청과 연결됩니다. jsonPayload.cacheKeyFingerprint에서 요청을 일치시켜 이러한 요청을 그룹화할 수 있습니다.

로깅되는 항목에 대한 자세한 내용은 Cloud Logging 문서를 참조하세요.

개방형 범위 요청

Media CDN은 응답이 원본에 의해 닫힐 때까지(예: 원본이 모든 바이트를 전송 중 작성할 때까지) 또는 타임아웃될 때까지 원본에 대해 요청을 열린 상태로 유지하는 '개방형' Range 요청(예: Range: bytes=0-이 포함된 요청)을 지원합니다.

개방형 바이트 범위는 일반적으로 Apple의 지연 시간이 짧은 HLS 세그먼트를 요청하는 클라이언트에서 사용합니다. 각 CMAF 청크가 전송 중 작성되면 CDN은 해당 청크를 캐시하여 클라이언트에게 전달할 수 있습니다.

DASH와의 상호 운용성이 필요하지 않은 경우와 같은 다른 경우에는 미디어 재생목록이 각 청크를 나타내는 바이트를 플레이어에 표시합니다.

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

EdgeCacheOrigin.timeouts.readTimeout 구성 값을 사용하여 Media CDN이 읽기 간에 대기하는 시간을 구성할 수 있습니다. 일반적으로 목표 기간의 배수(예: 2배)로 구성해야 합니다.

다음 단계

• 고급 라우팅을 검토하세요.
• 서로 다른 원본에 연결하는 방법을 알아보세요.
• 서비스의 TLS(SSL) 인증서 설정하기
• 콘텐츠 액세스를 인증하도록 서명된 요청 구성하기