원본 개요

Media CDN을 사용하면 콘텐츠가 Google Cloud 내에서 호스팅되거나 다른 클라우드 또는 온프레미스에서 호스팅되는지 여부에 관계없이 원본 인프라에서 콘텐츠를 가져올 수 있습니다.

각 구성에는 하나 이상의 원본을 연결할 수 있습니다. 원본 구성은 Media CDN에 인프라에 연결하는 방법, 장애 조치 시기와 방법, 재시도, 타임아웃, 연결 시 사용할 프로토콜을 알려줍니다.

원본의 특성은 다음과 같습니다.

호스트 및 경로별로 출처를 정의할 수 있으므로 단일 EdgeCacheService 리소스가 매니페스트, 동영상 세그먼트, 기타 정적 콘텐츠 등을 포함하는 여러 출처에 매핑할 수 있습니다.
HTTP/2, HTTPS, 암호화되지 않은 HTTP/1.1을 통해 원본에 도달할 수 있습니다.
재시도 및 장애 조치 동작은 원본별로 구성되며, 연결 실패와 같은 심각한 오류 시 서비스에서 장애 조치를 수행하거나 HTTP 404 Not Found 또는 HTTP 429 Too Many Requests 응답을 기반으로 재시도하도록 허용할 수 있습니다.
Media CDN 뒤에 있는 외부 애플리케이션 부하 분산기를 원본으로 구성하여 Google Cloud 또는 온프레미스 내부의 비공개 리소스에 연결할 수 있습니다.
리디렉션 팔로우 동작은 원본별로 구성됩니다. Media CDN이 다른 원본 서버로의 리디렉션을 따르도록 사용 설정할 수 있습니다.

원본 요구사항

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만 지원하는 경우 각 원본에 대해 프로토콜 필드를 명시적으로 설정할 수 있습니다.

원본 보호

Media CDN은 가능한 한 캐시 채우기를 적극적으로 최소화하도록 설계된 심층 계층 에지 인프라를 제공합니다.

캐싱 인프라에는 다음과 같은 세 가지 기본 레이어가 있습니다.

딥 에지 캐시: 서비스 제공업체 네트워크 내에서 대부분의 트래픽과 오프로드를 처리합니다.
Google의 피어링 에지: 수천 개의 ISP에 연결되어 있으며 에지 캐시의 중간 계층 캐시 역할을 합니다. 특정 ISP 내에 에지 캐시가 없는 경우, 사용자 대상 캐시 역할을 합니다.
롱테일 캐시: 다른 다운스트림 캐시가 원본 이전 단계에서 채우는 Google 네트워크 내의 캐시입니다. 이러한 캐시는 상당한 팬인을 지원하고, 상당한 캐시 스토리지 용량을 가지며, 원본 실드 역할을 합니다.

이 토폴로지 개요는 다음과 같습니다.

모든 캐싱 레이어는 원본 부하를 더 줄이기 위해 축소 요청(또는 병합)을 지원합니다. 관찰된 실제 대규모의 워크로드를 기반으로:

95% 이상의 캐시 채우기 작업은 캐시 채우기 비용과 지연 시간을 줄이기 위해 해당 리전 내의 전용 롱테일 캐시 노드를 사용합니다.
원본과 Google의 자체 에지 인프라 사이의 캐시 채우기는 전적으로 Google의 전역 비공개 백본 네트워크를 통해 이루어지므로, 캐시 채우기 지연 시간이 줄어들고 신뢰성이 향상되며, 두 가지 모두 실시간 스트리밍 워크로드에 유용합니다.
캐시는 상호 유리한 경우 서로 채우기를 수행하여 캐시 채우기 비율을 더욱 낮춥니다.
Media CDN은 캐시에 상당한 스토리지 용량을 가지고 있으므로 인기가 낮은 롱테일 콘텐츠의 경우에도 제거율을 최소화합니다.

고객은 캐시 구성, 사용자 부하, 워크로드(예: 실시간 및 주문형), 사용자 분포, 리전에서 사용자에게 제공하는 롱테일 콘텐츠 양(총 코퍼스 크기)에 따라 서로 다른 오프로드 비율을 확인할 수 있습니다.

축소 요청

축소 요청은 동일한 캐시 키에 대한 여러 사용자 기반 캐시 채움 요청을 에지 노드별 단일 원본 요청으로 축소합니다.

원본 보호와 함께 사용하면 원본 로드 및 이그레스 대역폭 요구사항이 더욱 줄어들며 Media CDN의 기본 동작입니다.

축소된 요청에는 클라이언트용 요청과 캐시 채우기 요청(축소됨)이 모두 로깅됩니다. 축소된 세션의 리더는 원본 채우기 요청을 수행하는 데 사용됩니다. 즉, 원본에서 해당 클라이언트의 헤더(사용자 에이전트 포함)만 확인합니다.

동일한 캐시 키를 공유하지 않는 요청은 축소될 수 없습니다.

원본 연결

다음 섹션에서는 Media CDN이 원본에 연결하는 방법, HTTP 요청이 수행되는 방법, 요청을 인증하는 방법을 설명합니다.

지원되는 원본 및 프로토콜

Media CDN은 다음을 포함하여 공개적으로 연결 가능한 HTTP 엔드포인트를 원본으로 직접 지원합니다.

Identity and Access Management 서비스 계정을 통한 비공개 버킷을 포함한 Cloud Storage 버킷
외부 애플리케이션 부하 분산기
AWS Signature Version 4를 사용하는 비공개 버킷을 포함한 Amazon S3 호환 버킷
Azure Blob Storage와 같은 공개적으로 사용 가능한 기타 객체 스토리지
공개 VM 또는 온프레미스 호스트와 같이 공개적으로 사용 가능한 웹 서버

원본에 대한 연결은 보안 터널 및 Google의 글로벌 백본 네트워크를 통해 이루어집니다.

다음 표에서는 지원되는 원본 프로토콜을 자세히 설명합니다.

프로토콜	지원됨	SSL(TLS) 필요
HTTP/2	예(기본값)	예
HTTPS(TLS 사용 HTTP/1.1)	예	예
HTTP/1.1	예	아니요

Media CDN은 기본적으로 HTTP/2(h2)를 사용하여 원본에 연결합니다. HTTP/2 및 HTTPS에는 모두 공개적으로 신뢰할 수 있는 유효한 TLS(SSL) 인증서가 필요합니다. 유효한 인증서는 Public Certificate Authority에서 서명하고 원본으로 전송된 호스트 이름과 일치하는 주체 대체 이름이 있는 만료되지 않은 인증서입니다.

참고:

원본이 HTTP/2를 지원하지 않는 경우 명시적으로 프로토콜을(원본별 기준) HTTP(HTTP/1.1) 또는 HTTPS(TLS를 통한 HTTP/1.1)로 설정할 수 있습니다.
HTTPS 또는 HTTP/1.1을 원본 프로토콜로 구성할 때 Media CDN은 대체 프로토콜(예: HTTP/2)을 협상하지 않습니다. 마찬가지로 HTTP/2를 구성할 때 원본 연결 동작을 명시하기 위해 연결이 HTTP/1.1로 돌아가지 않습니다.
Media CDN은 프로토콜에 따라 올바른 포트(HTTP의 경우 포트 80 또는 HTTPS 및 HTTP/2의 경우 포트 443)를 자동으로 사용합니다.

원본 요청 헤더

원본에 연결할 때 Media CDN은 기본적으로 클라이언트 요청의 Host 헤더를 사용합니다.

다음 표에서는 다양한 구성 시나리오에서 원본이 수신 요청에서 확인하는 내용을 설명합니다.

클라이언트 요청	`EdgeCacheService.hostRewrite`	`EdgeCacheOrigin.hostRewrite`	originAddress	호스트 헤더 / 원본의 TLS SNI
media.example.com	없음	없음	backend.example.com	media.example.com
media.example.com	service.example.com	없음	backend.example.com	service.example.com
media.example.com	없음	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	backend.example.com	origin.example.com
media.example.com	service.example.com	origin.example.com	gs://vod-content-bucket	버킷 이름에 따라 자동으로 설정

기본 원본과 모든 장애 조치 원본이 동일한 routeRule 또는 hostRewrite 구성을 공유하는 경우 동일한 호스트 헤더가 표시됩니다.

Cloud Storage 버킷을 원본으로 사용할 때는 Cloud Storage 버킷에서 대체 호스트 헤더 값이 지원되지 않으므로 모든 hostRewrite 설정이 무시됩니다. 호스트 헤더는 버킷 이름을 기준으로 자동으로 설정됩니다.

요청의 TLS SNI(서버 이름 표시) 값(HTTP/3, HTTP/2, HTTPS 요청의 경우)은 원본에 전송된 호스트 헤더와 동일한 값으로 설정됩니다.

경로별 구성을 위한 호스트 헤더 재작성에 대한 자세한 내용은 서비스 경로 구성을 참조하세요. 원본별 재정의 작업 설정에 대한 자세한 내용은 다음 리디렉션 없는 원본 장애 조치를 참조하세요.

장애 조치 및 제한 시간

다음 섹션에서는 이러한 구성 옵션을 설명합니다.

제한 시간: Media CDN이 원본에 연결하거나 요청에 응답할 때까지 기다리는 시간을 결정합니다.
재시도: Media CDN이 원본 HTTP 요청을 원본에 재시도할지 여부와 재시도 조건을 결정합니다.
장애 조치: 첫 번째 원본을 사용할 수 없거나 특정 상태 코드를 반환하는 경우 Media CDN에서 장애 조치 원본에 연결을 시도할지 여부를 결정합니다.

원본 제한 시간

제한 시간을 사용하면 원본 재시도 및 장애 조치 동작이 트리거되고 후속 클라이언트 장애 조치를 트리거할 수 있는 시기를 구성할 수 있습니다.

다음은 Media CDN에서 지원하는 구성 가능한 제한 시간을 설명합니다.

connectTimeout 및 maxAttemptsTimeout은 Media CDN이 사용 가능한 응답을 찾는 데 걸리는 시간을 제한합니다.

두 제한 시간 모두 원본이 헤더를 반환하고 장애 조치 또는 리디렉션을 사용할지 여부를 결정하는 데 걸리는 시간을 포함합니다. connectTimeout은 각 원본 시도에 독립적으로 적용되며, maxAttemptsTimeout에는 장애 조치 및 리디렉션을 포함하여 모든 원본 시도 전반에서 연결에 필요한 시간이 포함됩니다. 리디렉션이 발생하면 원본에 연결하려는 추가 시도로 계산되며 구성된 원본에 대해 설정된 maxAttempts에 포함됩니다.

Media CDN에 리디렉션 또는 장애 조치 원본에서와 같은 비리디렉션 응답이 발생하면 readTimeout 및 responseTimeout 값이 적용됩니다. 리디렉션 원본은 리디렉션이 발생한 EdgeCacheOrigin에 대해 구성된 connectTimeout, readTimeout, responseTimeout 값을 사용합니다.
responseTimeout 및 readTimeout은 스트리밍 응답이 수행될 수 있는 시간을 제어합니다. Media CDN에서 업스트림 응답을 사용할 것으로 결정한 후에는 connectTimeout 또는 maxAttemptsTimeout이 중요하지 않습니다. 이제부터는 readTimeout 및 responseTimeout이 적용됩니다.

Media CDN은 각 EdgeCacheOrigin에 설정된 maxAttempts에 관계없이 모든 원본에서 최대 4번의 원본 시도를 수행합니다. Media CDN은 기본 EdgeCacheOrigin에서 maxAttemptsTimeout 값을 사용합니다. 시도당 제한 시간 값(connectTimeout, readTimeout, responseTimeout)은 각 시도의 EdgeCacheOrigin에 대해 구성됩니다.

다음 표에서는 제한 시간 필드에 대해 설명합니다.

필드	기본값	설명
connectTimeout	5초	Media CDN이 응답 사용 가능 여부를 확인할 때까지 Media CDN이 원본에 대해 요청을 시작하는 데 걸리는 최대 시간입니다. 실제로 `connectTimeout`에는 요청을 만들고, DNS 조회를 수행하고, HTTP 상태 코드를 포함하는 응답 헤더를 가져와서 TLS 핸드셰이크, TCP/QUIC 연결 설정을 수행하는 데 걸리는 시간이 포함됩니다. 제한 시간은 1초~15초 사이의 값이어야 합니다.
maxAttemptsTimeout	15초	클라이언트에 오류를 반환하기 전에 장애 조치 출처를 포함한 모든 출처의 연결 시도에 소요되는 최대 시간입니다. 응답이 반환되기 전 제한 시간에 도달하면 HTTP 504가 반환됩니다. 제한 시간은 1초~30초 사이의 값이어야 합니다. 이 설정은 장애 조치 원본을 포함하여 모든 원본 연결 시도의 총 기간을 정의하여 클라이언트가 콘텐츠 스트리밍을 시작할 때까지 기다리는 최대 시간을 결정합니다. 첫 번째 `maxAttemptsTimeout` 값만 사용되고, 첫 번째 값은 제공된 경로에 대해 구성된 원본에 따라 정의됩니다.
readTimeout	15초	단일 HTTP 응답의 읽기 작업 사이에 기다리는 최대 기간입니다. `readTimeout`은 `responseTimeout`에 따라 최대 값이 결정됩니다. HTTP 응답의 모든 읽기 작업은 `responseTimeout`으로 설정된 마감 시한까지 완료해야 합니다. 제한 시간은 1초~30초 사이의 값이어야 합니다. 응답이 완료되기 전에 이 제한 시간에 도달하면 응답이 잘리고 로깅됩니다.
responseTimeout	30초	응답이 완료될 때까지 허용하는 최대 기간입니다. 제한 시간은 1초~120초 사이의 값이어야 합니다. 기간은 첫 번째 본문이 수신된 시간으로부터 측정됩니다. 응답이 완료되기 전에 이 제한 시간에 도달하면 응답이 잘리고 로깅됩니다.

다음 예를 고려하세요.

Origin A는 '/segments/'에 대한 요청과 일치하고, maxAttemptsTimeout 값이 5s, maxAttempts 값이 1, failover_origin 값이 Origin B입니다. connectTimeout 값의 기본값은 5s입니다. Origin A에 연결을 시도하고 잘못된 TLS 인증서로 인해 1초 내에 실패하면 Origin B에 성공적으로 연결할 수 있는 시간이 4초 남습니다.
Origin C는 '/manifests/*에 대한 요청과 일치하고, maxAttemptsTimeout 값이 10s이고, maxAttempts 값이 3이며, failover_origin이 구성되지 않았습니다. connectTimeout 값의 기본값은 5s입니다. Media CDN은 최대 3회까지 Origin C에 연결을 시도하며, 성공적인 연결을 위해 최대 10초(maxAttemptsTimeout 한도)가 허용됩니다.

원본 재시도 요청

Media CDN은 원본 재시도를 지원하므로 원본에 대한 실패한 요청을 재시도할 수 있습니다. 장애 조치 원본(구성된 경우)이 시도되기 전에 현재 원본을 재시도할 수 있는 횟수를 지정할 수 있습니다.

Media CDN은 구성된 maxAttempts 값(기본값: 1)까지 기본 원본에 도달하려고 시도합니다.
Media CDN은 실패하고 사용자에게 HTTP 502 Bad Gateway 오류를 반환하기 전에 최대 3회까지 원본 연결을 재시도합니다. 여기에는 3개 한도로 계산되는 모든 장애 조치 원본 연결이 포함됩니다.
원본 리소스를 구성할 때 originAddress 필드를 사용한 후 failoverOrigin(선택사항)을 사용하여 기본 원본을 구성할 수 있습니다. failoverOrigin은 다른 원본 리소스를 가리킵니다.

각 원본의 retryConditions는 재시도를 트리거하는 실패 유형을 지정합니다.

조건	기본값	설명
CONNECT_FAILURE	✔️	실패 시 재시도에는 라우팅, DNS 및 TLS 핸드셰이크 오류, TCP/UDP 시간 초과가 포함됩니다.
HTTP_5XX		HTTP `5xx` 상태 코드에서 재시도합니다.
GATEWAY_ERROR		`5xx`와 비슷하지만 상태 코드 `502`, `503`, `504`에만 적용됩니다.
RETRIABLE_4XX		`409` 및 `429`를 포함하여 재시도할 수 있는 `4xx` 상태 코드를 재시도합니다.
NOT_FOUND		HTTP `404` 상태 코드에서 재시도합니다.
FORBIDDEN		HTTP `403` 상태 코드에서 재시도합니다.

원본 간에 활성 상태 점검, 라운드 로빈, 부하 인식 조정이 필요한 경우 외부 애플리케이션 부하 분산기를 기본 원본으로 구성할 수 있습니다.

장애 조치 동작

다음 표에서는 장애 조치의 작동 방식과 클라이언트에서 관찰되는 응답을 설명합니다.

시나리오	장애 조치 구성됨	사용자에게 표시되는 상태
Media CDN에서 원본에 연결을 시도하지만 두 번의 시도(기본 설정) 후에도 HTTP 응답을 받지 못합니다.	아니요	HTTP `502 Bad Gateway`
Media CDN이 기본 원본에 연결을 시도하지만 연결에 실패합니다(TLS 핸드셰이크 오류). 구성된 장애 조치 원본에 대해 작업을 시도하면 HTTP `404` 오류가 반환됩니다.	예	HTTP `404 Not Found`
Media CDN이 기본 원본 및 장애 조치 원본 모두에 연결을 시도하지만 HTTP 상태 코드를 수신하지 못합니다.	예	HTTP `502 Bad Gateway`

Media CDN이 HTTP 404 Not Found 또는 HTTP 429 Too Many Requests 오류와 같이 구성된 retryConditions와 일치하는 상태 코드를 수신하고 이후의 재시도 및 장애 조치 원본 요청이 계속 실패하는 경우, HTTP 원본 시도가 소진되면 클라이언트에 502 Bad Gateway 오류가 반환됩니다.

원본 장애 조치 권장사항

장애 조치 또는 부하 분산을 위해 여러 원본을 구성할 때는 미디어 콘텐츠와 Vary, ETag, Last-Modified 헤더 동작이 원본 간에 일관되는지 확인합니다.

신뢰하고 제어할 수 있는 출처에 대해서만 원본 리디렉션을 구성하는 것이 좋습니다. 각 원본이 EdgeCacheService에서 제공하는 콘텐츠를 생성하므로 리디렉션 체인의 모든 원본을 신뢰할 수 있는지 확인하세요.