원본 구성

Media CDN의 원본은 다양한 방법으로 구성할 수 있습니다. 이 페이지에서는 원본을 구성하는 방법을 보여줍니다.

Cloud Storage 버킷을 원본으로 구성

Media CDN은 Cloud Storage 버킷을 콘텐츠의 백엔드로 지원합니다. 각 서비스는 호스트, 경로, 기타 요청 속성에 대한 경로를 구성하여 여러 버킷을 참조할 수 있습니다.

Cloud Storage 버킷은 원본 리소스를 만들 때 gs://my-bucket과 같은 버킷 URL을 원본 주소로 사용하여 구성됩니다.

콘솔

Google Cloud 콘솔에서 Media CDN 원본 페이지로 이동합니다.

원본으로 이동
원본 만들기를 클릭합니다.
원본의 이름을 입력합니다. 예를 들면 cloud-storage-origin입니다.
선택사항: 설명을 입력합니다.
원본 주소의 경우 Google Cloud Storage 버킷 선택을 선택합니다.
Cloud Storage 버킷을 찾아서 선택합니다.
Cloud Storage의 경우 기본 프로토콜 및 포트 설정을 유지합니다.
(선택사항) 원본 요청 헤더 재정의가 클라이언트가 전송하거나 경로 수준 헤더 작업에 의해 조작되는 헤더보다 우선 적용되도록 하려면 다음을 수행합니다.
1. 원본 재정의 사용 설정을 선택합니다.
2. 헤더 섹션에서 이름-값 쌍을 하나 이상 추가하여 헤더를 지정합니다.
선택사항: 이 원본에 연결할 수 없는 경우가 발생할 경우 시도할 장애 조치 원본을 선택합니다. 나중에 이 필드를 업데이트할 수 있습니다.
리디렉션 조건을 선택합니다.
재시도 조건을 선택합니다.
최대 시도 횟수의 경우 이 원본에서 캐시를 채우는 최대 시도 횟수를 선택합니다.
선택사항: 다음 제한 시간 값을 지정합니다.
1. 연결 제한 시간의 경우 원본 연결이 설정될 때까지 대기하는 최대 기간을 선택합니다.
2. 응답 제한 시간의 경우 응답이 완료될 때까지 허용되는 최대 기간을 선택합니다.
3. 읽기 제한 시간의 경우 단일 HTTP 연결 또는 스트림의 읽기 간에 대기하는 최대 기간을 선택합니다.
선택사항: 라벨 추가를 클릭하고 키-값 쌍을 하나 이상 지정합니다.
원본 만들기를 클릭합니다.

gcloud

gcloud edge-cache origins create 명령어를 사용합니다.

gcloud edge-cache origins create ORIGIN \
    --origin-address=ADDRESS

다음을 바꿉니다.

ORIGIN: 새 원본의 이름
ADDRESS: 버킷 이름(예: gs://my-bucket)

이는 버킷이 멀티 리전, 이중 리전, 리전인지 여부에 관계없이 동일합니다.

서비스를 구성할 때 VOD 콘텐츠를 하나의 버킷으로 라우팅하고 라이브 스트리밍 콘텐츠를 두 번째 버킷으로 라우팅할 수 있습니다. 이는 워크플로마다 관리하는 팀이 서로 다른 경우에 유용합니다. 캐시 채우기 지연 시간을 줄이려면 마찬가지로 eu-media.example.com 리전을 EU에 있는 멀티 리전 Cloud Storage 버킷으로 라우팅하고 us-media.example.com 리전(또는 경로, 헤더, 쿼리 매개변수 일치)을 미국에 있는 스토리지 버킷으로 라우팅하면 됩니다.

지연 시간이 짧은 라이브 스트리밍과 같이 쓰기 지연 시간이 중요한 경우에는 사용자와 최대한 가까운 위치에 리전 Cloud Storage 엔드포인트를 구성할 수 있습니다.

요청 인증

요청이 Media CDN에서 발생하는지 확인하려면 지원되는 다음 접근 방식 중 하나를 사용합니다.

연결 IP 주소가 Media CDN의 캐시 채우기 범위에 있는지 검증합니다. 이러한 범위는 모든 고객이 공유하지만 원본에 연결할 때 항상 EdgeCacheService 리소스에서 사용합니다.
원본에서 검증하는 토큰 값(예: 임의의 16바이트 값)이 포함된 커스텀 요청 헤더를 추가합니다. 그러면 원본에서 이 값이 포함되지 않은 요청을 거부할 수 있습니다.

원본 프로토콜 구성

HTTPS(TLS 사용 HTTP/1.1) 또는 HTTP/1.1(TLS 미사용)만 지원하는 원본의 경우 다음을 수행하여 protocol 필드를 명시적으로 설정합니다.

콘솔

Google Cloud 콘솔에서 Media CDN 원본 페이지로 이동합니다.

원본으로 이동
원본을 선택하고 수정을 클릭합니다.
프로토콜의 경우 HTTPS 또는 HTTP를 선택합니다. HTTP의 경우 포트를 80으로 지정합니다.
원본 업데이트를 클릭합니다.

gcloud

gcloud edge-cache origins update 명령어를 사용합니다.

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

원본이 HTTP/2를 지원하는 경우 프로토콜을 명시적으로 설정할 필요가 없습니다.

비공개 Cloud Storage 버킷 구성

Media CDN은 인터넷에 연결할 수 있는 모든 HTTP 또는 HTTPS 엔드포인트에서 콘텐츠를 가져올 수 있습니다. 경우에 따라 Media CDN이 콘텐츠를 가져오도록 허용하고 무단 액세스를 방지하기 위해 인증을 요구할 수 있습니다. Cloud Storage는 IAM 권한을 통해 이를 지원합니다.

Cloud Storage 원본의 경우 다음을 수행합니다.

Media CDN 서비스 계정에 원본으로 사용하는 Cloud Storage 버킷에 대한 objectViewer IAM 권한을 부여합니다.
allUsers 권한을 삭제합니다.
선택사항: allAuthenticatedUsers 권한을 삭제합니다.

Cloud Storage 버킷의 권한을 변경하려면 스토리지 관리자 IAM 역할이 필요합니다.

Media CDN 서비스 계정은 Media CDN 프로젝트에서 소유하므로 프로젝트의 서비스 계정 목록에 표시되지 않습니다.

서비스 계정은 다음과 같은 형식을 사용하며 명시적으로 허용되는 프로젝트의 Media CDN 리소스에 대한 액세스 권한만 부여합니다.

service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com

Media CDN에 버킷에 대한 액세스 권한을 부여하려면 서비스 계정에 objectViewer 역할을 부여합니다.

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
--member=serviceAccount:service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com \
--role=roles/storage.objectViewer

gcloud storage buckets remove-iam-policy-binding 명령어를 사용하여 지정된 버킷의 allUsers 역할에 부여된 권한을 삭제합니다. 예를 들어 버킷이 allUsers에 objectViewer 역할을 부여하는 경우 다음 명령어를 사용하여 부여를 삭제합니다.

gcloud storage buckets remove-iam-policy-binding gs://BUCKET \
--member=allUsers --role=roles/storage.objectViewer

공개 액세스 권한이 삭제되었는지 검증하려면 시크릿 모드 브라우저 창을 열고 https://storage.googleapis.com/BUCKET/object.ext을 사용하여 버킷 객체에 액세스해 봅니다.

한 프로젝트 내의 EdgeCacheService 리소스가 다른 프로젝트의 Cloud Storage 버킷에 액세스하도록 허용하려면 해당 프로젝트의 Media CDN 서비스 계정에 스토리지 버킷에 대한 액세스 권한을 부여하면 됩니다.

이렇게 하려면 service-PROJECT_NUM@gcp-sa-mediaedgefill.iam.gserviceaccount.com의 PROJECT_NUM가 액세스 권한이 필요한 EdgeCacheService 리소스가 있는 프로젝트의 프로젝트 번호여야 합니다. 특히 프로젝트의 Media CDN 환경(예: 개발, 스테이징, 프로덕션)이 서로 다르고 별도의 프로젝트에 동영상 또는 미디어 애셋이 포함된 경우 여러 프로젝트에 이 작업을 반복할 수 있습니다.

해당 경로에 서명된 요청을 사용 설정하지 않고 Cloud Storage 원본에 대한 액세스 권한을 보호할 수 있습니다.

비공개 Cloud Storage를 구성해도 Media CDN에서 직접 캐시된 콘텐츠에 액세스할 수 있습니다. 개별 사용자에게 서명된 요청을 실행하는 방법은 서명된 요청을 참조하세요.

외부 애플리케이션 부하 분산기를 원본으로 구성

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

예를 들어 온프레미스 인프라에 다시 연결하기 위해 Media CDN 또는 Cloud Service Mesh에서 관리하는 Envoy 프록시 그룹 뒤에 라이브 스트리밍 패키지 프로그램을 구성할 수 있습니다.

부하 분산기를 사용하면 다음을 위한 백엔드를 구성할 수 있습니다.

Compute Engine VM 인스턴스 그룹
네트워크 엔드포인트 그룹(Compute Engine VM 및 Google Kubernetes Engine 클러스터 포함)
서버리스 네트워크 엔드포인트 그룹(Cloud Run, App Engine, Cloud Run Functions)

동영상 매니페스트 제공을 위한 외부 애플리케이션 부하 분산기 원본과 세그먼트 스토리지를 위한 Cloud Storage 원본을 결합하는 아키텍처는 두 원본이 서로 다른 경로에 매핑된다는 점에서 다음과 유사합니다.

외부 애플리케이션 부하 분산기를 원본으로 구성하려면 부하 분산기의 전달 규칙을 가리키는 IP 주소 또는 공개 호스트 이름으로 원본 리소스를 만들어야 합니다. 공개 호스트 이름(도메인 이름)은 SSL(TLS) 인증서와 최신 HTTP 버전(HTTP/2 및 HTTP/3)에 필요하므로 이 이름을 사용하는 것이 좋습니다.

또한 다음 사항을 확인해야 합니다.

부하 분산기에 EdgeCacheService 리소스에 사용되는 호스트 이름과 일치하는 경로가 있거나 부하 분산기가 원본으로 구성된 경로에 대해 urlRewrite.hostRewrite를 구성했는지 확인합니다.
부하 분산기에 이러한 호스트 이름에 대해 공개적으로 신뢰할 수 있는 SSL(TLS) 인증서가 구성되어 있는지 확인합니다.

예를 들어 부하 분산기의 전달 규칙을 가리키는 공개 도메인 이름이 origin-packager.example.com이면 originAddress가 이 이름으로 설정된 원본을 만들어야 합니다.

콘솔

Google Cloud 콘솔에서 Media CDN 원본 페이지로 이동합니다.

원본으로 이동
원본 만들기를 클릭합니다.
원본의 이름을 입력합니다. 예를 들면 load-balancer-origin입니다.
선택사항: 설명을 입력합니다.
원본 주소에 대해 FQDN 또는 IP 주소 지정을 선택합니다.
Google Cloud 부하 분산기의 FQDN 또는 IP 주소를 입력합니다.
선택사항: 이 원본에 연결할 수 없는 경우가 발생할 경우 시도할 장애 조치 원본을 선택합니다. 나중에 이 필드를 업데이트할 수 있습니다.
재시도 조건을 선택합니다.
최대 시도 횟수의 경우 이 원본에서 캐시를 채우는 최대 시도 횟수를 선택합니다.
선택사항: 다음 제한 시간 값을 지정합니다.
1. 연결 제한 시간의 경우 원본 연결이 설정될 때까지 대기하는 최대 기간을 선택합니다.
2. 응답 제한 시간의 경우 응답이 완료될 때까지 허용되는 최대 기간을 선택합니다.
3. 읽기 제한 시간의 경우 단일 HTTP 연결 또는 스트림의 읽기 간에 대기하는 최대 기간을 선택합니다.
선택사항: 라벨 추가를 클릭하고 키-값 쌍을 하나 이상 지정합니다.
원본 만들기를 클릭합니다.

gcloud

gcloud edge-cache origins create 명령어를 사용합니다.

gcloud edge-cache origins create LB_ORIGIN \
    --origin-address=LB_ADDRESS

다음을 바꿉니다.

LB_ORIGIN: 원본의 이름
LB_ADDRESS: FQDN 또는 IP 주소(예: origin-packager.example.com)

전달 규칙의 IP 주소를 원본 주소로 사용하거나 부하 분산기에 연결된 SSL 인증서가 없는 경우 프로토콜을 HTTP로 설정하여 암호화되지 않은 연결로 대체할 수 있습니다. 개발 또는 테스트에만 이 작업을 수행하는 것이 좋습니다.

원본 장애 조치 구성

다음 섹션에서는 원본 장애 조치 동작을 구성하는 방법을 보여줍니다.

리디렉션이 없는 원본 장애 조치

다음은 기본 장애 조치 EdgeCacheOrigin 구성입니다.

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

Media CDN은 장애 조치 원본을 시도하기 전에 경로의 기본 원본을 최대 3회 재시도합니다. 이 구성에서 Media CDN은 기본 원본을 3회 시도한 후 FAILOVER_ORIGIN에 대한 단일 요청을 시도합니다. 장애 조치 원본도 성공적으로 응답하지 않으면 Media CDN은 전체 원본 응답을 반환하거나 상태 코드가 수신되지 않으면 HTTP 502 Bad Gateway 응답을 반환합니다.

캐시 채우기 지연 시간은 재시도 횟수 및 장애 조치 이벤트 횟수에 따라 증가합니다. 원본 제한 시간 값(예: connectTimeout)을 늘리면 과부하되거나 사용량이 많은 원본 서버가 응답할 때까지 대기하는 시간이 늘어나므로 캐시 채우기 지연 시간에 추가로 영향을 미칩니다.

다음 예시에서는 MY_ORIGIN에 채우기 요청을 보내는 구성을 보여줍니다. 이 구성으로 인해 Media CDN은 연결 오류(예: DNS, TCP, TLS 오류), 원본의 HTTP5xx 응답 또는 HTTP 404 Not Found 발생 시 재시도합니다. 두 번 시도 후 FAILOVER_ORIGIN으로 장애 조치됩니다.

구성된 원본 전반에서 최대 4회 시도합니다(원래 시도 후 최대 3회까지 재시도할 수 있음). 원본별로 maxAttempts 값을 구성하여 장애 조치를 시도하기 전에 재시도 횟수를 결정할 수 있습니다.

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
failoverOrigin: FAILOVER_ORIGIN
# what conditions trigger a retry or failover
retryConditions:
- CONNECT_FAILURE
- HTTP_5xx # any HTTP 5xx response
- NOT_FOUND # retry on a HTTP 404
timeout:
  maxAttemptsTimeout: 10s # set a deadline for all retries and failover

리디렉션을 사용하는 원본 장애 조치

예를 들어 다음 EdgeCacheOrigin 리소스를 구성했고 EdgeCacheService 리소스의 경로가 캐시 채우기에 PrimaryOrigin을 사용하도록 구성되었다고 가정해 보겠습니다.

name: PrimaryOrigin
originAddress: "primary.example.com"
maxAttempts: 2
failoverOrigin: "SecondaryOrigin"
retryConditions: [CONNECT_FAILURE]
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

name: SecondaryOrigin
originAddress: "secondary.example.com"
maxAttempts: 3
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

이 예시에서 Media CDN이 캐시 채우기를 수행하면 Media CDN은 PrimaryOrigin의 구성을 읽고 그에 따라 응답합니다.

Media CDN이 원본에 연결하기 위한 시도 #1로 primary.example.com에 연결한다고 가정해 보겠습니다. primary.example.com이 성공적인 응답을 반환하면 Media CDN은 캐시 채우기에 해당 응답을 사용합니다.

primary.example.com이 HTTP 302 Found Redirect를 Location: b.example.com에 반환한다고 가정해 보겠습니다. 그런 다음 원본에 연결하기 위한 시도 #2로 Media CDN은 b.example.com으로의 리디렉션을 따릅니다. 이 경우 Media CDN은 다음을 수행합니다.

b.example.com이 성공적인 응답을 반환하면 Media CDN은 캐시 채우기에 해당 응답을 사용합니다.
b.example.com이 리디렉션 또는 실패 응답을 반환하면 Media CDN은 구성된 SecondaryOrigin으로 장애 조치됩니다. 이 예시에서는 PrimaryOrigin이 2회 maxAttempts에 대해 구성되기 때문입니다.

Media CDN이 SecondaryOrigin으로 장애 조치되면 Media CDN은 SecondaryOrigin 구성을 사용하고 secondary.example.com에 연결하려고 시도합니다. 이는 원본에 연결하기 위한 시도 #1이고 전체적으로는 시도 #3입니다.

이 경우 Media CDN은 다음을 수행합니다.

secondary.example.com이 성공적인 응답을 반환하면 Media CDN은 캐시 채우기에 해당 응답을 사용합니다.
secondary.example.com이 HTTP 302 Found Redirect를 Location: c.example.com에 반환하면 Media CDN은 c.example.com에 연결하려고 시도합니다. 이 예시에서 이는 SecondaryOrigin에 대한 시도 #2이고 전체적으로는 시도 #4입니다.

c.example.com에 연결하려고 시도할 때 성공적인 응답이 반환되면 Media CDN은 캐시 채우기에 해당 응답을 사용합니다. Media CDN이 따르도록 구성된 리디렉션이 반환되면 Media CDN은 원본에 연결하려는 최대 시도 횟수를 모두 소진했으므로 HTTP 502 Bad Gateway 오류를 반환합니다. Media CDN은 EdgeCacheOrigin 구성에 관계없이 모든 원본 전반에서 최대 4회 시도합니다. 마지막으로 Media CDN이 c.example.com에 연결하지 못하면 Media CDN은 504 Gateway Timeout 응답 또는 502 Bad Gateway 응답을 반환합니다.

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

원본 리디렉션을 사용하여 구성

Media CDN은 리디렉션 응답을 클라이언트에 직접 반환하는 대신 캐시 채우기 중에 원본에서 내부적으로 반환한 다음 리디렉션을 지원합니다. Media CDN이 원본 리디렉션을 따르도록 구성된 경우 Media CDN은 리디렉션된 응답을 캐시하고 클라이언트에 반환하기 전에 리디렉션 위치에서 콘텐츠를 검색합니다. Media CDN은 도메인 간 리디렉션을 따릅니다.

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

다음 원본 리디렉션을 사용 설정하려면 EdgeCacheOrigin 리소스에 다음 구성을 추가합니다.

name: MY_ORIGIN
originAddress: "DOMAIN_NAME"
maxAttempts: 2
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

Media CDN은 리디렉션에 지정된 프로토콜을 사용하여 모든 서버에 연결합니다. Media CDN이 리디렉션될 수 있는 모든 서버가 필요한 프로토콜을 지원하는지 확인합니다. 특히 프로토콜이 HTTPS, HTTP/2 또는 HTTP/3으로 설정된 경우 Media CDN은 안전하지 않은 리디렉션을 따르기 위해 HTTP/1.1 연결로 대체하지 않습니다. 리디렉션된 원본으로 전송된 호스트 헤더는 리디렉션된 URL과 일치합니다. Media CDN은 최종 응답을 반환하거나 재시도 또는 장애 조치 조건을 평가하기 전에 EdgeCacheOrigin 시도당 단일 리디렉션을 따릅니다.

redirectConditions 설정은 Media CDN이 각 원본의 리디렉션을 따르도록 하는 HTTP 응답 코드를 지정합니다.

조건	설명
MOVED_PERMANENTLY	응답 코드 HTTP `301`의 리디렉션을 따릅니다.
FOUND	응답 코드 HTTP `302`의 리디렉션을 따릅니다.
SEE_OTHER	응답 코드 HTTP `303`의 리디렉션을 따릅니다.
TEMPORARY_REDIRECT	응답 코드 HTTP `307`의 리디렉션을 따릅니다.
PERMANENT_REDIRECT	응답 코드 HTTP `308`의 리디렉션을 따릅니다.

원본별 호스트 재작성 또는 헤더 수정 구성

원본에 원본별 호스트 재작성 또는 헤더 수정이 필요한 경우 다음 originOverrideAction 구성 예시를 사용하여 설정합니다.

name: FAILOVER_ORIGIN
originAddress: "FAILOVER_ORIGIN_HOST"
originOverrideAction:
  urlRewrite:
    hostRewrite: "FAILOVER_ORIGIN_HOST"
  headerAction:
    requestHeadersToAdd:
    - headerName: "Authorization"
      headerValue: "AUTH-KEY"
      replace: true

originOverrideAction.hostRewrite 설정은 이 원본을 가리키는 경로에 구성된 기존 헤더 재작성보다 우선합니다.

특정 원본에서 요청한 고유한 원본별 헤더 requestHeadersToAdd를 사용할 수 있습니다. 일반적인 사용 사례에서는 정적 Authorization 헤더가 추가됩니다. 이러한 헤더 조작은 원본 요청 중에 실행되므로 원본별로 추가된 헤더는 동일한 필드 이름의 기존 헤더를 바꾸거나 여기에 추가됩니다. 기본적으로 Media CDN은 기존 헤더에 추가합니다. 기존 헤더를 바꾸려면 headerAction.replace를 true로 설정합니다.

경로별로 요청 헤더를 설정하는 방법은 커스텀 헤더 설정을 참조하세요.

원본 문제 해결

원본이 예상대로 작동하지 않는 경우 원본 문제 해결 방법을 확인하세요.

원본 구성

Cloud Storage 버킷을 원본으로 구성

콘솔

gcloud

요청 인증

원본 프로토콜 구성

콘솔

gcloud

비공개 Cloud Storage 버킷 구성

외부 애플리케이션 부하 분산기를 원본으로 구성

콘솔

gcloud

원본 장애 조치 구성

리디렉션이 없는 원본 장애 조치

리디렉션을 사용하는 원본 장애 조치

원본 리디렉션을 사용하여 구성

원본별 호스트 재작성 또는 헤더 수정 구성

원본 문제 해결

다음 단계