원본 개요

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

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

오리진에는 다음과 같은 기능이 있습니다.

• 출처는 호스트별 및 경로별로 정의할 수 있으므로 단일 EdgeCacheService 리소스가 매니페스트, 동영상 세그먼트, 기타 정적 콘텐츠를 포함하는 여러 출처에 매핑될 수 있습니다.
• 원본은 HTTP/2, HTTPS, 암호화되지 않은 HTTP/1.1을 통해 연결할 수 있습니다.
• Media CDN만 원본에 액세스할 수 있도록 특정 Google IP 주소만 허용하도록 방화벽 규칙을 구성할 수 있습니다.
• 재시도 및 장애 조치 동작은 원본별로 구성되며, 연결 실패와 같은 심각한 오류 시 서비스에서 장애 조치를 수행하거나 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은 가능한 한 캐시 채우기를 적극적으로 최소화하도록 설계된 심층 계층 에지 인프라를 제공합니다.

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

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

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

Media CDN은 제한된 키 집합과 전역 위치를 사용하여 기본적으로 원본 보호를 제공합니다. 기본 원본 보호는 원본이 아닌 최종 사용자의 위치를 기반으로 작동합니다. 이는 최종 사용자와 원본 서버가 동일한 리전에 있는 경우와 전역 원본 서버가 여러 리전에 있는 경우에 효과적이며 강력한 오프로드 이점을 제공합니다.

유연한 보호

오리진이 한 지역에 중앙 집중화되어 있지만 사용자가 전 세계에 분포되어 있는 시나리오에서 사용자 위치를 기반으로 하는 기본 오리진 보호 동작은 다음과 같은 방식으로 최적이 아닐 수 있습니다.

• 기본 실드 위치가 중앙 집중식 원본과 지리적으로 멀리 떨어져 있는 경우 캐시 누락의 지연 시간 증가
• 캐시 채우기 요청을 집중하는 대신 여러 전역 기본 실드 위치에 분산하여 오리진 오프로드 감소

유연한 차폐를 사용하면 일반적으로 중앙 집중식 원본에 가까운 원본 차폐를 위한 단일의 특정 지리적 리전을 구성하여 이러한 제한사항을 극복할 수 있습니다. 그러면 유연한 차폐가 구성된 리전에 있거나 그 근처에 있는 차폐 캐시를 통해 모든 캐시 채우기 요청을 라우팅합니다. 이렇게 하면 지역에 초점을 맞춘 캐시를 통해 오리진으로 부하가 통합됩니다.

중앙 집중식 원본과 동일한 지리적 리전에서 유연한 보호 리전을 구성하면 다음을 최적화할 수 있습니다.

• 실드 레이어의 캐시 적중률
• 원본 오프로드
• 캐시 부적중 및 캐시할 수 없는 콘텐츠의 지연 시간
• 성능 안정성

유연한 보호는 Media CDN에 구성된 모든 원본 유형과 호환됩니다.

축소 요청

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

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

• 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의 글로벌 백본 네트워크를 통해 이루어집니다.

다음 표에는 지원되는 출처 프로토콜이 자세히 나와 있습니다.

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 헤더를 사용합니다.

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

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

Cloud Storage 버킷은 대체 호스트 헤더 값을 지원하지 않으므로 Cloud Storage 버킷을 원본으로 사용하는 경우 hostRewrite 설정이 무시됩니다. 호스트 헤더는 버킷 이름을 기반으로 자동으로 설정됩니다.

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

경로별 구성을 위해 호스트 헤더를 재작성하는 방법에 대한 자세한 내용은 서비스 경로 구성을 참고하세요. 출처별 재정의 작업을 설정하는 방법에 관한 자세한 내용은 리디렉션 없이 출처 장애 조치를 참고하세요.

원본이 Media CDN에서 트래픽을 수신하도록 허용

콘텐츠에 대한 무단 액세스 위험을 줄이려면 출처에서 IP 허용 목록을 사용하여 Google이 외부 출처로 요청을 전송하는 데 사용하는 특정 IP 주소 범위를 제외한 모든 IP 주소에 대한 액세스를 차단하세요. 이렇게 하면 Media CDN만 원본 서버에 연결할 수 있습니다.

다음 표에는 방화벽 규칙에 필요한 소스 IP 주소 범위가 요약되어 있습니다.

다음 URL을 사용하여 업데이트된 Google 할당 IP 주소 범위를 포함하는 JSON 파일에 액세스합니다.

https://www.gstatic.com/ipranges/mediacdn.json

장애 조치 및 제한 시간

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

• 제한 시간: 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에 대해 구성됩니다.

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

다음 예를 고려하세요.

• 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은 Origin C에 최대 3번 연결을 시도하여 성공적인 연결을 위해 최대 10초 (maxAttemptsTimeout 제한)를 허용합니다.

원본 재시도 요청

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

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

각 출처의 retryConditions는 재시도를 트리거하는 오류 유형을 지정합니다.

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

장애 조치 동작

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

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

원본 장애 조치 권장사항

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

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

다음 단계

• 원본 구성
• 비공개 Amazon S3 호환 버킷을 원본으로 사용
• 서비스 경로 구성