Media CDN은 트래픽을 세분화된 수준에서 특정 에지 구성 및 원본에 매핑할 수 있는 고급 HTTP 라우팅 기능을 제공합니다.
게재된 요청
Media CDN 구성에는 EdgeCacheService
리소스의 라우팅 섹션에 정의된 경로 집합이 포함됩니다.
이러한 경로는 (최소한) 호스트를 기준으로 요청을 일치시킵니다. 트래픽이 원본으로 전달되는 방법에 대한 자세한 내용은 HostRule
및 PathMatcher
를 참조하세요.
각 경로는 자체 CDN 구성, 재작성, 리디렉션, CORS 정책, 커스텀 HTTP 헤더, 원본 매핑을 정의할 수 있습니다.
경로는 원본을 공유할 수 있습니다.
예를 들어 매니페스트 요청을 특정 원본으로 라우팅하고 단기 캐시 TTL 및 음성 캐싱 정책을 정의할 수 있습니다. 세그먼트 요청은 특정 매니페스트 유형 또는 사용자를 구분하기 위해 헤더 및 쿼리 매개변수를 사용하여 다른 원본으로 분할될 수 있습니다.
다음 예시에서는 media.example.com
호스트의 특정 헤더, 쿼리 매개변수, 경로 프리픽스와 일치하는 요청을 라우팅하는 방법을 보여줍니다.
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 origin: staging-live-origin matchRules: - prefixMatch: /vod/ headerMatches: - headerName: "x-staging-client" presentMatch: true queryParameterMatches: - name: "live" exactMatch: "yes" routeAction: cdnPolicy: defaultTtl: 5s
경로 일치
Media CDN은 전체(완전), 프리픽스, 와일드 카드 경로 일치를 지원합니다. 경로 일치를 호스트, 헤더, 쿼리 매개변수 기반 일치와 결합하여 세분화된 요청 라우팅 규칙을 구성할 수 있습니다.
다음은 URL 경로에서 일치시키는 세 가지 방법입니다.
필드 | 설명 | 예 |
---|---|---|
matchRules[].fullPathMatch
|
fullPathMatch 조건은 쿼리 문자열이 포함되지 않은 전체 URL 경로와 일치합니다. 해당하는 경우 후행 슬래시를 지정해야 합니다.
|
일치 규칙이
|
matchRules[].prefixMatch
|
prefixMatch 조건은 URL 경로 프리픽스와 일치합니다. 동일한 문자열로 시작하는 URL이 일치합니다.
|
일치 규칙이 |
matchRules[].pathTemplateMatch
|
pathTemplateMatch 조건은 와일드 카드 연산자를 지원하므로 복잡한 URL 패턴과 경로 세그먼트를 일치시키고 URL을 재작성하기 위해 이름이 지정된 변수를 캡처할 수 있습니다.
|
일치 규칙이
더 많은 예시는 패턴 일치 섹션을 참조하세요. |
자세한 내용은 MatchRule
의 API 사양을 참조하세요.
예를 들어 /stream/
으로 시작하는 모든 요청을 일치시키려면 다음과 유사한 라우팅 규칙을 만듭니다.
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: - prefixMatch: /stream/
이 예시에서는 일치 규칙에 후행 슬래시를 명시적으로 포함합니다.
media.example.com/stream/id/1234/hls/manifest.m3u8
에 대한 요청이 이 경로와 일치합니다.media.example.com/stream-eu/id/4567/hls/manifest.m3u8
에 대한 요청은 이 경로와 일치하지 않습니다.
두 번째 사례에서 다른 경로 또는 포괄 경로가 구성되지 않은 한 Media CDN은 HTTP 404
오류를 반환합니다.
유사한 프리픽스를 사용하는 경로의 우선순위 작동 방식에 대한 안내는 경로 우선순위 및 순서 섹션을 참조하세요.
패턴(와일드 카드) 일치
패턴 일치를 사용하면 와일드 카드 구문을 사용하여 부분 URL과 서픽스(파일 확장자)를 포함하여 URL의 여러 부분을 일치시킬 수 있습니다.
또한 pathTemplateMatch
필드에서 하나 이상의 경로 구성요소를 이름이 지정된 변수와 연결한 후 pathTemplateRewrite
필드에서 URL을 재작성할 때 해당 변수를 참조할 수 있습니다. 이렇게 하면 요청이 원본으로 전송되기 전에 URL 구성요소를 재정렬하고 삭제할 수 있습니다.
다음 예시는 서로 다른 두 URL 서픽스에서 일치시키는 방법을 보여줍니다.
# EdgeCacheService.routing.pathMatchers[] routeRules: - priority: 1 description: "Match video segments" matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: prod-video-storage
지원되는 구문은 다음과 같습니다.
연산자 | 일치 | 예 |
---|---|---|
*
|
다음 경로 구분자(/ )까지 단일 경로 구성요소와 일치합니다.
|
/videos/*/*/*.m4s 는 /videos/123414/hls/1080p5000_00001.m4s 와 일치합니다.
|
**
|
0개 이상의 경로 세그먼트와 일치합니다. 존재하는 경우 마지막 연산자여야 합니다. |
/**.mpd 는 /content/123/india/dash/55/manifest.mpd 와 일치합니다.
|
{name} or {name=*}
|
하나의 경로 세그먼트와 일치하는 이름이 지정된 변수.
다음 경로 구분자 |
/content/{format}/{lang}/{id}/{file}.vtt 는 /content/hls/en-us/12345/en_193913.vtt 와 일치하고 format="hls" , lang="en-us" , id="12345" , file="en_193913" 을 변수로 캡처합니다.
|
{name=videos/*}
|
둘 이상의 경로 세그먼트와 일치하는 이름이 지정된 변수. videos/* 와 일치하는 경로 구성요소는 이름이 지정된 변수로 캡처됩니다.
|
/videos/{language=lang/*}/* 는 /videos/lang/en/video.m4s 와 일치하고 경로 변수 language 를 lang/en 값으로 채웁니다.
|
{name=**}
|
0개 이상의 경로 세그먼트와 일치하는 이름이 지정된 변수. 존재하는 경우 마지막 연산자여야 합니다. |
|
참고:
- URL을 재작성하지 않는 경우 더 간단한
*
및**
연산자를 사용합니다. - 변수를 사용하여 경로 구성요소를 캡처할 때 변수로 캡처되지 않은 URL 부분은 후속
pathTemplateRewrite
에서 참조할 수 없습니다. 예시를 보려면 경로 변수 캡처 섹션을 참조하세요. - 동일한 경로의
pathTemplateMatch
에 없는 후속pathTemplateRewrite
의 변수는 참조할 수 없습니다. - 변수는 대소문자를 구분하며
{FORMAT}
,{forMAT}
,{format}
은 서로 다른 변수와 값을 나타냅니다. - 일치 하나에 최대 10개의 연산자(와일드 카드 또는 변수)를 지정할 수 있습니다.
pathTemplateMatch
및pathTemplateRewrite
필드는 255자(영문 기준)를 초과할 수 없습니다.
예: 파일 확장자 일치
다음 예시는 모든 경로 구성요소를 서픽스까지 일치시키는 와일드 카드 연산자의 일반적인 사용 사례를 보여줍니다.
이 경우 다음을 수행합니다.
- 매니페스트 원본에서
.m3u8
및.mpd
로 끝나는 동영상 매니페스트(재생목록)를 가져와 응답에 5초의 짧은 TTL을 적용합니다(정기적으로 변경되기 때문임). - 세그먼트 원본에서
.ts
과.m4s
로 끝나는 동영상 세그먼트를 가져와 이 응답에 1일의 더 긴 TTL을 적용합니다.
이 접근 방식은 SSAI(서버 측 광고 삽입) 또는 DAI(동적 광고 삽입) 서비스를 사용할 때, 그리고 매니페스트가 몇 초마다 업데이트되는 라이브 동영상에 주로 사용됩니다.
다음 구성은 이를 지원하도록 Media CDN 라우팅을 구성하는 방법을 보여줍니다.
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # the first route only matches video manifests - priority: 1 matchRules: - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments - pathTemplateMatch: "/**.mpd" origin: manifest-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 5s # the second route matches video segments, fetches them # from a separate origin server, caching them for a longer # duration (1 day). - priority: 2 matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: segment-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 86400s
예시: 경로 변수 캡처
다음 예시에서는 이름이 지정된 변수를 사용하여 하나 이상의 경로 구성요소를 설명하는 방법을 보여줍니다.
이러한 변수는 pathTemplateRewrite
에서 사용하여 요청이 원본으로 전송되기 전에 경로를 재작성하거나 복잡한 pathTemplateMatch
자체 설명을 만들 수 있습니다.
routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: # Matches a request of "/us/en/hls/123139139/segments/00001.ts" - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}" origin: my-origin routeAction: urlRewrite: # Rewrites to "/123139139/hls/segments/00001.ts" pathTemplateRewrite: "/{id}/{format}/{file}"
구체적으로는 다음과 같습니다.
- 각
{name}
변수는 단일 경로 세그먼트를 캡처합니다. 경로 세그먼트는 URL 경로에서/
('슬래시') 쌍 사이의 모든 문자입니다. {name=**}
변수는 나머지 모든 경로 세그먼트를 캡처합니다. 여기에서는segments/00001.ts
및master.m3u8
모두와 일치합니다.- 동일한 경로의
pathTemplateRewrite
에서pathTemplateMatch
에서 캡처한 변수 일부를 다시 참조합니다.{country}
및{lang}
변수는 원본의 디렉터리 구조와 일치하지 않으므로 명시적으로 생략합니다.
이 예시에서는 다음 작업이 수행됩니다.
/us/en/hls/123139139/segment_00001.ts
의 수신 요청 URL은pathTemplateMatch
와 일치하며 원본으로 전송되기 전에/123139139/hls/segment_00001.ts
로 재작성됩니다./us/123139139/master.m3u8
의 수신 요청 URL은pathTemplateMatch
와 일치하지 않고 HTTP404 (Not Found)
응답을 수신합니다./br/es/dash/c966cbbe6ae3/subtitle_00001.vtt
의 수신 요청 URL도pathTemplateMatch
와 일치하며 원본으로 전송되기 전에/c966cbbe6ae3/dash/subtitle_00001.vtt
로 재작성됩니다.
와일드 카드 일치가 URL 재작성과 상호 운용되는 방식에 대한 자세한 내용은 재작성 섹션을 참조하세요.
호스트 일치
각 서비스는 여러 호스트 이름에서 일치시킬 수 있으며 각 호스트 이름 집합에는 자체 경로 그룹이 포함됩니다(경로 일치자라고 함). 일반적인 경우 서비스의 모든 호스트 이름은 단일 호스트 목록 및 단일 경로 일치자가 있는 단일 공유 경로 집합에 매핑됩니다.
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # list of routes for the configured hosts - priority: 999 matchRules: - prefixMatch: / origin: DEFAULT_ORIGIN
일치하지 않는 호스트에는 기본 HTTP 404
페이지가 제공됩니다. 호스트를 수락하려면 와일드 카드 문자 *
를 hostRules[].hosts[]
항목으로 포함할 수 있습니다.
경로 그룹을 정의할 수도 있습니다(예: 국가별 또는 실시간이나 주문형으로 그룹화). 서비스마다 단일 보안 정책이 있으므로 일반적으로 보유한 시장(지역) 또는 워크로드당 하나의 서비스를 사용하는 것이 좋습니다.
참고:
- 포트가 포함된 호스트(또는 HTTP/2
:authority
) 헤더는 구성된 호스트와 암시적으로 일치합니다. 포트를 명시적으로 지정할 필요가 없습니다. - HTTP를 통한 요청의 경우
*.vod.example.com
의hostRules[].hosts[]
항목이us.vod.example.com
및us.vod.example.com:80
와 일치합니다. - 요청이 HTTPS (TLS)를 통해 전송된 경우
*.vod.example.com
의hostRules[].hosts[]
항목이us.vod.example.com:443
와 일치합니다.
자세한 내용은 HostRule
의 API 사양을 참조하세요.
헤더 및 쿼리 매개변수 일치
특정 헤더 및 쿼리 매개변수 이름은 물론 헤더 값(프리픽스, 서픽스 또는 일치검색)의 존재를 기준으로 일치시키도록 경로를 구성할 수 있습니다.
쿼리 매개변수 및 헤더 일치는 논리적 'AND'입니다. 즉, 요청이 모든 쿼리 매개변수, 헤더 키(및 지정된 경우 값)와 일치하여 지정된 경로와 일치해야 합니다.
예를 들어 특정 헤더 필드 이름과 헤더 값이 있는 요청을 alternate-origin
이라는 원본으로 라우팅하려면 routeRules[].matchRules[].headerMatches[]
내에서 일치 조건을 구성합니다.
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: alternate-origin matchRules: - prefixMatch: "/videos/" headerMatches: - headerName: "x-device-name" exactMatch: "roku"
이 예시에서 URL 시작 부분에 /videos/
및 x-device-name: roku
헤더가 있는 요청은 이 경로와 일치합니다. 이 헤더 이름이 없거나 값이 다른 요청은 이 경로와 일치하지 않습니다.
자세한 내용은 HeaderMatch
의 API 사양을 참조하세요.
마찬가지로 쿼리 매개변수와 일치시키려면 다음과 같이 queryParameterMatches
를 하나 이상 지정합니다.
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: eu-live-origin-prod matchRules: - prefixMatch: "/videos/" queryParameterMatches: - name: "playback_type" exactMatch: "live" - name: "geo" exactMatch: "eu"
이 예시에서는 https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu
의 클라이언트 요청이 이 경로와 일치합니다.
자세한 내용은 QueryParameterMatcher
의 API 사양을 참조하세요.
포괄 (기본값) 경로 정의
기본적으로 Media CDN은 요청이 구성된 경로와 일치하지 않으면 HTTP 404 (Not Found)
오류를 반환합니다.
포괄 경로를 구성하려면 지정된 pathMatcher
(경로 모음)에 대해 다음을 수행합니다.
- 가장 낮은 우선순위 (가장 높은 숫자)로
routeRule
을 만듭니다. 예를 들어 가능한 가장 낮은 경로 우선순위인 999입니다. /
의 프리픽스 일치로matchRule
을 구성합니다(모든 요청 경로와 일치).- 경로에서
origin
또는urlRedirect
중 하나를 구성합니다.
예를 들어 일치하지 않는 모든 요청을 my-origin
이라는 기본 원본으로 전달하는 포괄 경로를 구성하려면 다음과 같이 priority: 999
및 /
의 matchRules[].prefixMatch
를 사용하여 새 경로를 만듭니다.
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 999 origin: my-origin matchRules: - prefixMatch: /
선택적으로 원본을 가져오기 전에 URL을 재작성하거나 요청을 원본에 '있는 그대로' 전송하는 대신 기본 페이지(예: 방문 페이지)로 리디렉션할 수 있습니다.
경로 우선순위 및 순서
routeRules[]
배열의 각 경로에는 연결된 priority
가 있어야 합니다.
보다 구체적인 경로는 높은 우선순위(더 작은 숫자)로 설정되어야 합니다. 우선순위가 1인 /stream/
프리픽스와 일치하는 경로는 우선순위가 5인 보다 구체적인 /stream/live/eu/
경로가 모든 요청과 일치하지 않도록 합니다.
- 우선순위가 가장 높은 경로는 '1'이고 가장 낮은 경로는 '999'입니다.
- 우선순위가 같은 routeRules를 두 개 이상 구성할 수 없습니다. 각 규칙 우선순위를 1~999(포함) 사이의 숫자로 설정해야 합니다.
- 포괄 경로를 정의하면 일치하지 않는 모든 요청을 기본 원본으로 전송하거나 방문 페이지 또는 엔드포인트로 리디렉션할 수 있습니다.
다음 예시에서는 /live/
경로의 우선순위가 더 높기 때문에 /live/us/
경로가 일치하지 않음을 확인할 수 있습니다.
routeRules: - priority: 1 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "U.S based live streams" matchRules: # This would never be matched, as the /live/ prefixMatch at priority 1 # would always take precedence. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
이 문제를 해결하기 위해 더 구체적인(더 긴) 경로를 더 높은 우선순위로 배치합니다.
routeRules: - priority: 1 description: "U.S based live streams" matchRules: # The more specific (longer) match is at a higher priority, and now # matches requests as expected. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
이렇게 하면 보다 구체적인 경로가 요청과 정확하게 일치할 수 있습니다. /live/eu/
프리픽스가 붙은 요청은 여전히 우선순위 2로 /live/
경로로 이동합니다.
메서드 필터링
기본적으로 Media CDN은 GET
, HEAD
, OPTIONS
메서드만 원본으로 프록시하고 원본을 수정할 수 있는 메서드를 필터링합니다.
미리보기에서는 원본으로 프록시 처리할 메서드를 지정하여 특정 라우팅 규칙에 대해 이 기본 동작을 재정의할 수 있습니다. Media CDN은 GET
, HEAD
, OPTIONS
외에도 PUT
, POST
, DELETE
, PATCH
를 지원합니다.
라우팅 규칙에 대한 메서드 집합 지원을 구성하려면 각 메서드에 allowed_methods
값이 있는 routeMethods
섹션을 지정합니다.
routeRules: - priority: 5 description: "Video uploads" routeMethods: allowedMethods: ["PUT", "POST", "OPTIONS"] matchRules: - pathTemplateMatch: "/uploads/**.ts" origin: prod-video-storage - priority: 10 description: "Video serving" routeMethods: allowedMethods: ["GET", "HEAD"] matchRules: - pathTemplateMatch: "/videos/**.ts" origin: prod-video-storage
미리보기에서 Media CDN에서 v1alpha1 Network Services API를 사용하여 이 구성을 업데이트하고 볼 수 있습니다.
또는 gcloud alpha edge-cache services export
명령어와 gcloud alpha edge-cache services import
명령어를 사용하여 서비스 구성 YAML 파일을 업데이트할 수 있습니다.
경로 정규화
경로 정규화는 Media CDN이 특정 시나리오에서 URL의 여러 표현을 단일 표준 표현으로 결합하는 방법을 설명합니다.
경로 정규화는 동일한 콘텐츠를 나타내는 요청 URL의 수를 줄이고 정규화된 경로를 예상하는 원본의 원본 오류를 완화하여 캐시 적중률을 직접 향상시킬 수 있습니다.
수신 요청은 다음 기준에 따라 정규화됩니다.
- 연속된 슬래시 여러 개가 단일 슬래시로 병합됩니다. 예를 들어
/videos///12345/manifest.mpd
URL 경로는/videos/12345/manifest.mpd
로 정규화됩니다. - 경로 세그먼트는 RFC 3986 섹션 6.2.2.3에 따라 정규화됩니다.
예를 들어 경로
/a/b/c/./../../g
는 RFC 3986에 정의된 "점 세그먼트 삭제" 알고리즘에 따라/a/g
로 정규화됩니다. 이 정규화는 캐시를 확인하거나 요청을 원본으로 전달하기 전에 수행됩니다. - 요청은 백분율 인코딩으로 정규화되지 않습니다. 예를 들어 백분율 인코딩 슬래시 문자(
%2F
)가 있는 URL은 인코딩되지 않은 형식으로 디코딩되지 않습니다.
URL은 대소문자를 구분하며 대소문자를 정규화하지 않습니다. 대부분의 URL에는 서명된 요청 토큰이 있는 URL을 포함하여 대소문자를 구분하는 base64 인코딩이 포함되어 있습니다.
재작성 및 리디렉션
다음 섹션에서는 요청을 재작성하고 리디렉션을 구성하는 방법에 대한 예시를 제공합니다.
요청 URL 재작성
Media CDN은 호스트 및 경로 재작성을 지원합니다. 재작성하면 원본으로 전송된 URL이 변경되고 필요에 따라 호스트와 경로를 수정할 수 있습니다. 호스트 및 경로 재작성은 경로 수준에서 수행되므로 경로, 쿼리 매개변수, 요청 헤더를 포함하여 모든 일치자를 기준으로 다시 작성되는 특정 요청을 정의할 수 있습니다.
자세한 내용은 RouteAction.UrlRewrite
의 API 사양을 참조하세요.
다음은 요청을 재작성하는 세 가지 방법입니다.
필드 | 설명 |
---|---|
urlRewrite.pathPrefixRewrite
|
경로를 재작성하여 요청과 일치하는
단일 라우팅 규칙에 |
urlRewrite.pathTemplateRewrite
|
단일 라우팅 규칙에 |
urlRewrite.hostRewrite
|
요청이 원본 서버로 전송되기 전에 호스트를 다시 작성합니다. |
참고:
- 재작성된 URL은 캐시 키를 변경하지 않습니다. 캐시 키는 클라이언트가 보낸 요청 URL을 기반으로 합니다.
- 경로 일치 및 서명된 요청 검증 후 재작성이 수행됩니다. 경로가 다른 일치 규칙과 다시 일치되지 않습니다.
예시: 경로 프리픽스 삭제
예를 들어 클라이언트 요청 URL을 /vod/videos/hls/1234/abc.ts
에서 /videos/hls/1234/abc.ts
로 다시 작성하려면(경로에서 /vod
삭제) pathPrefixRewrite
기능을 사용합니다.
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/vod/videos/" routeAction: urlRewrite: pathPrefixRewrite: "/videos/"
pathPrefixRewrite
는 matchRules[].prefixMatch
에서 일치하는 전체 경로 구성요소를 pathPrefixRewrite
값으로 바꾸는 방식으로 작동합니다.
호스트 이름을 재작성하려면(예: cdn.example.com
을 my-bucket.s3.us-west-2.amazonaws.com
으로 재작성) 다음을 구성하면 됩니다.
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/videos/" routeAction: urlRewrite: hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"
이 경우 원본 요청 URL은 cdn.example.com/videos/*
에서 my-bucket.s3.us-west-2.amazonaws.com/videos/*
로 변경됩니다.
단일 경로 내에서 호스트 및 경로 재작성을 모두 결합할 수도 있습니다.
예시: 변수를 사용하여 URL 재작성
pathTemplateMatch
및 pathTemplateRewrite
를 사용하여 수신 요청 URL의 일부를 다시 작성하려면 변수 캡처 섹션을 참조하세요.
요청 리디렉션
Media CDN은 세 가지 유형의 리디렉션을 지원합니다.
- 호스트 리디렉션: 호스트(도메인)만 리디렉션하며 경로 및 쿼리 매개변수는 변경되지 않습니다.
- 경로 리디렉션: 경로 전체를 바꿉니다.
- 경로 프리픽스 리디렉션: 일치하는 프리픽스만 바꿉니다.
리디렉션은 기본적으로 HTTP 301 (Moved Permanently)
로 설정되지만 경로별로 다른 리디렉션 상태 코드를 반환하도록 구성할 수 있습니다.
다음 구성은 https://cdn.example.com/on-demand/*
를 방문하는 사용자를 https://cdn.example.com/streaming/*
로 리디렉션하는 프리픽스 기반 리디렉션의 예시입니다.
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 matchRules: - prefixMatch: "/on-demand/" urlRedirect: # The prefix matched in matchRules.prefixMatch is replaced # by this value prefixRedirect: "/streaming/" redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307
이 예시에서는 리디렉션을 임시 리디렉션으로 변경하여 클라이언트(예: 브라우저)가 캐싱하지 못하도록 합니다. 가까운 미래에 변경될 것으로 예상되는 경우에 유용할 수 있습니다.
지원되는 redirectResponseCode
값은 다음 표에 나와 있습니다.
리디렉션 응답 코드 | HTTP 상태 코드 |
---|---|
MOVED_PERMANENTLY_DEFAULT |
HTTP 301(영구 이전) |
FOUND |
HTTP 302(발견됨) |
SEE_OTHER |
HTTP 303(다른 항목 참조) |
TEMPORARY_REDIRECT |
HTTP 307(임시 리디렉션) |
PERMANENT_REDIRECT |
HTTP 308(영구 리디렉션) |
참고:
- 경로는 트래픽을 원본으로 전달하거나 클라이언트에 리디렉션을 반환할 수 있습니다.
origin
필드와urlRedirect
필드를 동시에 설정할 수는 없습니다. - HTTPS로 리디렉션되는 경로를 사용하려면 하나 이상의 SSL 인증서가 서비스에 연결되어 있어야 합니다.
자세한 내용은 RouteRule.UrlRedirect
의 API 사양을 참조하세요.
모든 요청을 HTTPS로 리디렉션
모든 요청을 HTTP 대신 HTTPS로 리디렉션하려면 모든 클라이언트 요청을 HTTPS로 자동 리디렉션하도록 각 서비스를 구성하면 됩니다. HTTP를 통해 연결하는 클라이언트는 'http://' 대신 'https://'를 사용하여 동일한 URL로 설정된 Location
헤더와 함께 HTTP 301 (Permanent Redirect)
응답을 보냅니다.
gcloud
gcloud edge-cache services update MY_SERVICE \ --require-tls
Request issued for: [MY_SERVICE] Updated service [MY_SERVICE].
이 명령어는 requireTls
가 true
로 설정된 서비스 설명을 반환합니다.
name: MY_SERVICE requireTls: true
또한 클라이언트가 항상 HTTPS를 통해 직접 연결하도록 Strict-Transport-Security 헤더를 응답 헤더로 설정할 수도 있습니다.
서드 파티 스토리지 백엔드 사용
Media CDN은 AWS S3 스토리지 버킷, Azure Blob Storage 및 기타 스토리지 제공업체 등 Google Cloud 외부에서 공개적으로 연결 가능한 HTTP 엔드포인트에 대한 연결을 지원합니다. 이는 멀티 클라우드 아키텍처를 사용하거나 아직 Storage Transfer Service를 사용하여 Cloud Storage로 데이터를 마이그레이션하지 않은 경우에 유용할 수 있습니다.
AWS S3에서 가상 호스팅 버킷을 구성하는 최소한의 원본 구성:
name: MY_S3_ORIGIN originAddress: BUCKET-NAME.s3.REGION.amazonaws.com
EdgeCacheService
리소스에 구성된 호스트 이름과 일치하는 버킷 이름을 사용하지 않는 경우 이 원본과 연결된 경로에 호스트 재작성도 구성해야 합니다. 그렇지 않으면 원본에서 가져올 때 클라이언트 요청에서 설정한 호스트 헤더가 사용됩니다.
예를 들어 경로 프리픽스가 /legacy/
인 모든 요청을 외부 버킷에 매핑하려면 hostRewrite
와 pathPrefixRewrite
를 모두 구성하여 원본 요청에서 이 프리픽스를 제외하면 됩니다.
routeRules: - description: legacy backend matchRules: - prefixMatch: "/legacy/" routeAction: urlRewrite: hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com pathPrefixRewrite: / cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s
원본 요청에서 호스트 헤더가 설정되는 방식에 대한 자세한 내용은 원본 요청 헤더 문서를 참조하세요.
교차 출처 리소스 공유(CORS)
교차 출처 리소스 공유(CORS)는 교차 출처 요청을 안전하게 수행하기 위한 브라우저 중심 접근 방식입니다.
CORS 정책을 사용하면 경로별 정책을 기반으로 Access-Control-Allow-Origins
같은 CORS 헤더를 자동으로 설정할 수 있습니다.
CORS 구성
Media CDN을 사용하면 EdgeCacheService
의 경로에 CORS 정책을 정의할 수 있습니다.
CORS 정책은 공통 HTTP 헤더 집합으로 이러한 규칙을 정의합니다. 응답에 Access-Control-Allow-Origin
, Access-Control-Max-Age
, Access-Control-Allow-Headers
같은 공통 CORS 헤더를 설정할 수 있습니다. 이러한 헤더를 사용하면 웹사이트의 프런트엔드에서 다른 도메인(원본)에 호스팅될 수 있는 Media CDN 서비스에 교차 출처 호출을 수행할 수 있으며 사용자가 허용하지 않는 교차 출처 요청을 방지할 수 있습니다.
예를 들어 player.example.com
과 api.example.com
은 (브라우저 측면에서) 서로 다른 출처이며, 프런트엔드 애플리케이션이 api.example.com
에 다음 재생목록을 가져오도록 요청하거나 관련 콘텐츠 목록을 새로 고칠 수 있습니다. 마찬가지로 player.example.com
에서 동영상 재생목록 및 동영상 세그먼트를 가져오기 위해 cdn.example.com
에 도달해야 할 수 있습니다. cdn.example.com
은 정상 상태이고 player.example.com
이 allowed origin
이라는 사실과 다른 규칙(허용된 헤더, 쿠키를 포함할 수 있는지 여부)을 표시해야 합니다.
또 다른 예로 stream.example.com
을 출처 및 CORS 요청의 X-Client-ID
헤더로 허용하려는 경우 다음과 같이 경로에 corsPolicy
를 구성하면 됩니다.
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
corsPolicy
는 EdgeCacheService 내의 routing.pathMatchers[].routeRules[].routeAction.corsPolicy
에 구성됩니다. 각 routeRule
은 필요에 따라 서로 다른 corsPolicy
를 정의하거나 전혀 정의할 수 없습니다.
corsPolicy
값을 정의하고 이름이 같은 경로에서 responseHeadersToAdd
필드를 사용하여 커스텀 응답 헤더도 설정하면 커스텀 응답 헤더가 우선 적용되며 corsPolicy
값 대신 사용됩니다.
원본 응답이 HTTP 헤더를 설정했고 corsPolicy
값이 설정된 경우 corsPolicy
값이 대신 사용됩니다. 잘못된 헤더 값을 클라이언트에 보내거나 의도치 않게 더 많은 권한이 허용되는 정책을 설정하지 않도록 값을 축소하거나 결합하지 않습니다.
특수 {origin_request_header}
는 클라이언트 요청의 Origin
HTTP 헤더로 채워집니다. 이는 경로에서 Access-Control-Allow-Origin
헤더에 대한 커스텀 응답 헤더 값으로 설정할 수 있습니다.
자세한 내용은 RouteAction.CORSPolicy
의 API 사양을 참조하세요.
CORS 정책 필드
다음 표에서는 CORS 정책에 포함된 필드를 설명합니다.
필드 | 설명 | 예 |
---|---|---|
allowOrigins |
브라우저 환경에서 교차 출처 요청을 수행할 수 있는 출처를 지정하는
예를 들어 동영상 콘텐츠가 |
Access-Control-Allow-Origins: https://stream.example.com
|
maxAge |
브라우저 클라이언트가 CORS 프리플라이트 요청에 대한 응답을 캐시해야 하는 기간을 초 단위로 지정하는 일부 브라우저는 최댓값(86,400초)이 지정되더라도 이 기간을 2시간 이하로 제한합니다. |
Access-Control-Max-Age: 7200
|
allowMethods |
리소스에 액세스할 수 있는 HTTP 메서드를 지정하는 기본적으로 Media CDN은 |
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
|
allowHeaders |
CORS 요청에서 전송할 수 있는 헤더를 결정하는 교차 출처를 요청할 때 동영상 콘텐츠의 일부 응답 헤더에 액세스해야 하는 경우 동영상 플레이어에서 종종 필요합니다. |
Access-Control-Allow-Headers: Content-Type, If-Modified-Since,
Range, User-Agent
|
exposeHeaders |
클라이언트 측 JavaScript에서 액세스할 수 있는 헤더를 결정하는 콘텐츠 교차 출처를 요청할 때 동영상 콘텐츠의 특정 응답 헤더에 액세스해야 하는 경우 동영상 플레이어에서 종종 필요합니다. |
Access-Control-Expose-Headers: Date, Cache-Status, Content-Type,
Content-Length
|
allowCredentials |
클라이언트 측 JavaScript가 사용자 인증 정보가 포함된 요청에 대한 응답을 검사할 수 있도록 하는 false로 설정하면 이 헤더가 생략됩니다. |
Access-Control-Allow-Credentials: true
|
disabled |
corsPolicy 를 삭제하지 않고 사용 중지합니다. 프리플라이트 OPTIONS 요청은 원본으로 프록시됩니다.
|
해당 사항 없음 |
corsPolicy 예시
다음 구성 예시에서는 기본적인 corsPolicy
구성을 보여줍니다.
routeRules: - priority: 1 matchRules: - prefixMatch: /stream/ routeAction: cdnPolicy: defaultTtl: 3600s corsPolicy: allowOrigins: - "https://stream.example.com" - "https://stream-staging.example.com" maxAge: 86400s # some browsers might only honor up to 7200s or less allowMethods: - "GET" - "HEAD" - "OPTIONS" allowHeaders: - "Content-Type" - "If-Modified-Since" - "Range" - "User-Agent" exposeHeaders: - "Content-Type" - "Content-Length" - "Date"
라우팅 문제 해결
일부 요청이 일치하는 결과를 가져오지 않거나 오류를 반환하지 않으면 다음을 확인하세요.
- 경로에는
prefixMatch
,fullPathMatch
또는pathTemplateMatch
중 정확히 하나가 정확히 정의된matchRule
이 있어야 합니다. 이러한 필드 중 하나를 포함하지 않으면 API가 오류를 반환합니다. - 각 경로의
priority
가 올바르게 설정되었는지 확인합니다. 보다 구체적인(더 긴) 경로에 더 짧고 광범위한 경로 일치보다 높은 우선순위를 부여해야 합니다. - 기본적으로
GET
,HEAD
,OPTIONS
요청만 지원됩니다. 미리보기에서 다른 메서드에 대한 지원을 구성하려면 경로 메서드를 참조하세요. 특정 경로에 대해 사용 설정되지 않은 메서드는 HTTP405 (Method Not Allowed)
오류와 함께 거부됩니다. GET
요청에서 요청 본문이 허용되지 않기 때문에 본문이 있는 HTTPGET
요청 또는 트레일러가 있는 요청은 HTTP400
오류와 함께 거부됩니다.- 쿼리 매개변수 및 헤더 일치는 논리적 'AND'입니다. 즉, 요청이 모든 쿼리 매개변수 및 헤더 키(및 지정된 경우 값)와 일치하여 지정된 경로와 일치해야 합니다.
다음 단계
- 캐싱 구성 문서를 검토하세요.
- 서로 다른 원본에 연결하는 방법을 알아보세요.
- 서비스의 TLS(SSL) 인증서를 설정하세요.
- 콘텐츠 액세스를 인증하도록 서명된 요청을 구성하세요.