Media CDN은 세분화된 수준에서 특정 에지 구성 및 원본에 트래픽을 매핑할 수 있는 고급 HTTP 라우팅 기능을 제공합니다.
경로 규칙 구성
Media CDN 서비스의 경로 규칙을 구성합니다.
콘솔
Google Cloud 콘솔에서 Media CDN 페이지로 이동합니다.
경로 규칙을 구성하려는 서비스의 세부정보 페이지를 열려면 서비스 이름을 클릭합니다.
수정 모드로 전환하려면 수정 버튼을 클릭합니다.
라우팅 섹션으로 이동하려면 다음을 클릭합니다.
호스트 규칙을 1개 이상 지정하세요. 호스트 규칙 추가를 클릭합니다. 그런 후 다음 작업을 수행합니다.
호스트의 경우 일치할 호스트를 하나 이상 지정합니다.
설명에 호스트 규칙에 대한 간단한 설명을 입력합니다.
또는 호스트 규칙을 수정하려면 화살표를 클릭하여 펼칩니다.
경로 규칙을 1개 이상 지정하세요. 라우팅 규칙 추가를 클릭합니다.
또는 경로 규칙을 수정하려면 각 행에서 수정을 클릭합니다.
라우팅 규칙 수정 창의 우선순위에서 경로 우선순위의 값을 설정합니다.
설명: 규칙 목록에서 규칙을 식별하는 데 도움이 되는 간단한 설명을 입력합니다.
일치 섹션에서 일치 조건을 하나 이상 지정합니다. 일치 조건 추가를 클릭합니다. 그런 후 다음 작업을 수행합니다.
- 검색 유형에서 경로 일치 옵션을 선택합니다.
경로 일치의 경우 이름, 경로 또는 템플릿을 지정합니다. 와일드 카드 패턴 일치를 사용하는 것이 좋습니다.
필요한 경우 경로 값의 대소문자 구분 사용 설정도 선택합니다.
(선택사항) 헤더 일치 및 쿼리 매개변수 일치를 선택합니다. 그런 다음 관련 버튼을 클릭하여 헤더와 쿼리 매개변수를 추가합니다. 각각의 경우 이름, 일치 유형, 값을 지정합니다.
자세한 내용은 헤더 및 쿼리 매개변수 일치를 참고하세요.
일치 조건을 저장하려면 완료를 클릭합니다.
기본 작업에 다음 옵션 중 하나를 선택합니다.
원본에서 가져오기: 요청을 특정 출처로 전달하려면 이 옵션을 선택한 다음 출처를 선택합니다.
URL 리디렉션: 요청을 리디렉션하려면 이 옵션을 선택합니다. 그런 다음 리디렉션 유형, 경로, 상태 코드를 지정합니다.
원하는 경우 모든 응답을 HTTPS로 리디렉션하거나 쿼리를 삭제하는 옵션을 선택합니다.
고급 구성을 클릭합니다.
헤더 작업 섹션에서 항목 추가를 클릭합니다.
작업 유형을 선택한 다음 헤더를 이름 및 값 쌍으로 지정합니다. 그런 다음 완료를 클릭합니다.
라우팅 작업 섹션에서 항목 추가를 클릭합니다.
작업 유형과 관련 옵션을 지정합니다. 그런 다음 완료를 클릭합니다.
HTTP 메서드 필터링의 경우 HTTP 메서드 필터링 맞춤설정을 선택합니다.
그런 다음 출처에 프록시할 HTTP 메서드를 선택합니다.
경로 규칙을 저장하려면 저장을 클릭합니다.
서비스에 대한 변경사항을 저장하려면 서비스 업데이트를 클릭합니다.
gcloud 및 YAML
YAML 파일로 미디어 CDN 구성을 내보냅니다.
gcloud edge-cache services export명령어를 사용합니다.gcloud edge-cache services export SERVICE_NAME \ --destination=FILENAME.yaml다음을 바꿉니다.
SERVICE_NAME: 서비스 이름FILENAME: YAML 파일의 이름
이 페이지의 섹션에 설명된 대로 필요한 구성으로 YAML 파일을 업데이트합니다.
서비스를 업데이트하려면 YAML 파일에서 미디어 CDN 구성을 가져옵니다.
gcloud edge-cache services import명령어를 사용합니다.gcloud edge-cache services import SERVICE_NAME \ --source=FILENAME.yaml
게재된 요청
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이 특정 시나리오에서 URL의 여러 표현을 단일 표준 표현으로 결합하는 방법을 설명합니다.
경로 정규화는 동일한 콘텐츠를 나타내는 요청 URL의 수를 줄이고 정규화된 경로를 예상하는 원본의 원본 오류를 완화하여 캐시 적중률을 직접 향상시킬 수 있습니다.
수신 요청은 다음 기준에 따라 정규화됩니다.
- 연속된 슬래시 여러 개가 단일 슬래시로 병합됩니다. 예를 들어
/videos///12345/manifest.mpdURL 경로는/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
Strict-Transport-Security 헤더를 응답 헤더로 설정하여 클라이언트가 항상 HTTPS를 통해 직접 연결하도록 지시할 수도 있습니다.
서드 파티 스토리지 백엔드 사용
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) 인증서 설정하기
- 콘텐츠 액세스를 인증하도록 서명된 요청 구성하기