URL 맵 개요

Google Cloud HTTP(S) 부하 분산기 및 Traffic Director는 URL 맵이라는 Google Cloud 구성 리소스를 사용하여 백엔드 서비스 또는 백엔드 버킷으로 요청을 라우팅합니다.

예를 들어 외부 HTTP(S) 부하 분산기를 사용하면 단일 URL 맵을 사용하여 URL 맵에 구성된 규칙에 따라 요청을 다른 대상으로 라우팅할 수 있습니다.

  • https://example.com/video 요청은 하나의 백엔드 서비스로 이동합니다.
  • https://example.com/audio 요청은 다른 백엔드 서비스로 이동합니다.
  • https://example.com/images 요청은 Cloud Storage 백엔드 버킷으로 이동합니다.
  • 다른 호스트 및 경로 조합에 대한 요청은 기본 백엔드 서비스로 이동합니다.

URL 맵은 다음 Google Cloud 제품과 함께 사용됩니다.

사용할 수 있는 URL 맵 리소스에는 전역 및 리전이라는 두 가지 유형이 있습니다. 사용하는 리소스 유형은 제품의 부하 분산 스킴에 따라 다릅니다.

제품 부하 분산 스키마 URL 맵 리소스 유형 지원되는 목적지
외부 HTTP(S) 부하 분산기 EXTERNAL 전역, 외부 백엔드 서비스, 백엔드 버킷
내부 HTTP(S) 부하 분산기 INTERNAL_MANAGED 리전, 내부 백엔드 서비스
Traffic Director INTERNAL_SELF_MANAGED 전역, 내부 백엔드 서비스

모든 제품에서 모든 URL 맵 기능이 제공되는 것은 아닙니다. 내부 HTTP(S) 부하 분산 및 Traffic Director와 함께 사용되는 URL 맵은 여러 고급 트래픽 관리 기능도 지원합니다. 이러한 차이점에 대한 자세한 내용은 고급 트래픽 관리를 참조하세요.

URL 맵 작동 방식

요청이 부하 분산기에 도달하면 부하 분산기는 URL 맵에 정의된 규칙에 따라 특정 백엔드 서비스 또는 백엔드 버킷으로 요청을 라우팅합니다.

백엔드 서비스는 애플리케이션 또는 마이크로서비스의 인스턴스인 백엔드 컬렉션을 나타냅니다. 백엔드 버킷은 일반적으로 이미지와 같은 정적 콘텐츠를 호스팅하는 데 사용되는 Cloud Storage 버킷입니다.

외부 HTTP(S) 부하 분산기, 내부 HTTP(S) 부하 분산기, Traffic Director의 경우 가능한 목적지는 다음과 같습니다.

또한 외부 HTTP(S) 부하 분산기는 다음을 지원합니다.

예를 들어 다음과 같은 설정이 있다고 가정해 봅시다.

  • 하나의 IP 주소:
    • 조직을 향한 모든 요청은 동일한 IP 주소 및 동일한 부하 분산기로 이동합니다.
    • 요청 URL을 기반으로 다른 백엔드 서비스로 트래픽이 전달됩니다.
  • 두 개의 도메인:
    • example.net은 학습 동영상을 호스팅합니다.
    • example.org은 조직 웹사이트를 호스팅합니다.
  • 네 개의 서버 집합:
    • 조직 웹사이트를 호스팅합니다(백엔드 서비스: org-site).
    • 전체 학습 동영상 웹사이트를 호스팅합니다(백엔드 서비스: video-site).
    • 고화질(HD) 학습 동영상을 호스팅합니다(백엔드 서비스: video-hd).
    • 일반 화질(SD) 학습 동영상을 호스팅(백엔드 서비스: video-sd)합니다.

다음 사항을 목표로 합니다.

  • org-site 백엔드 서비스로 이동하기 위한 example.org에 대한 요청(또는 example.net이 아닌 다른 도메인)
  • video-site 백엔드 서비스로 이동하기 위한 더 구체적인 경로와 일치하지 않는 example.net에 대한 요청
  • video-hd 백엔드 서비스로 이동하기 위한 example.net/video/hd/*에 대한 요청
  • video-sd 백엔드 서비스로 이동하기 위한 example.net/video/sd/*에 대한 요청

/video/*--path-rule/video/test1, /video/test2 등과 같은 URI와 일치합니다. 하지만 이 경로 규칙은 /video 경로와 일치하지 않습니다.

부하 분산기가 URL에서 /../ 로 요청을 수신하면 부하 분산기는 302 리디렉션으로 응답합니다. 예를 들어 http://example.net/video/../abc에 대한 요청을 보내면 부하 분산기는 이 요청을 http://example.net/abc로 변환하고 URL 맵 구성에 따라 처리합니다. 이 302 리디렉션은 Cloud Logging에 로깅되지 않습니다.

URL 맵을 사용하면 이러한 유형의 호스트 및 경로 기반 라우팅을 설정할 수 있습니다.

백엔드 서비스 설정 예시(확대하려면 클릭)
백엔드 서비스 설정 예시(확대하려면 클릭)

이름 지정

각 URL 맵에는 이름이 있습니다. Google Cloud Console을 사용하여 HTTP(S) 기반 부하 분산기를 만들면 URL 맵에 이름이 지정됩니다. 이 이름은 부하 분산기의 이름과 동일합니다. gcloud 명령줄 도구 또는 API를 사용하는 경우 URL 맵에 커스텀 이름을 정의할 수 있습니다.

URL 맵 구성요소

URL 맵은 URL에 대한 요청을 백엔드 서비스 또는 백엔드 버킷으로 보내는 Google Cloud 구성 리소스 집합입니다. 이를 위해 URL 맵은 처리하는 각 URL의 호스트 이름경로 부분을 사용합니다.

  • 호스트 이름은 URL의 도메인 이름 부분입니다. 예를 들어 URL http://example.net/video/hd의 호스트 이름 부분은 example.net입니다.
  • 경로는 호스트 이름 및 포트 번호(선택사항) 다음에 오는 URL 부분입니다. 예를 들어 URL http://example.net/video/hd의 경로 부분은 /video/hd입니다.
기본 URL 맵을 사용하는 부하 분산기 구성(확대하려면 클릭)
기본 URL 맵을 사용하는 부하 분산기 구성(확대하려면 클릭)

다음 다이어그램은 서로 연관된 부하 분산 구성 객체의 구조를 보여줍니다.

어떤 백엔드 서비스 또는 백엔드 버킷이 들어오는 요청을 수신할지 다음 URL 맵 구성 매개변수를 사용하여 제어합니다.

  • 기본 백엔드 서비스 또는 기본 백엔드 버킷. URL 맵을 만들 때는 기본 백엔드 서비스 또는 기본 백엔드 버킷 중 하나만 지정해야 합니다. 이 기본값은 해당되는 호스트 규칙이 있는 경우를 제외하고 호스트 이름을 포함하는 URL에 대해 Google Cloud가 요청을 보낼 백엔드 서비스 또는 버킷을 나타냅니다.

  • 호스트 규칙(hostRules). 호스트 규칙은 하나 이상의 연결된 호스트 이름으로 전송된 요청을 단일 경로 일치자(pathMatchers)로 보냅니다. URL의 호스트 이름 부분은 호스트 규칙에 구성된 호스트 이름 집합과 정확하게 일치합니다. URL 맵 호스트 및 경로 규칙에서 호스트를 생략하면 규칙은 요청된 모든 호스트를 일치시키게 됩니다. http://example.net/video/hd에 대한 요청을 경로 일치 프로그램으로 보내려면 최소한 호스트 이름 example.net을 포함하는 단일 호스트 규칙이 필요합니다. 같은 호스트 규칙이 다른 호스트 이름에 대한 요청을 처리할 수도 있지만, 동일한 경로 일치자로 전달할 것입니다.

    요청을 다른 경로 일치자에게 전달하려면 다른 호스트 규칙을 사용해야 합니다. 한 URL 맵 내의 두 호스트 규칙은 동일한 호스트 이름을 포함할 수 없습니다.

    호스트 규칙에 와일드 카드 문자 *를 지정하여 모든 호스트 이름을 일치시킬 수 있습니다. 예를 들어 URL http://example.org, http://example.net/video/hd, http://example.com/audio에 대해 *를 호스트 규칙에 지정하여 세 개의 호스트 이름 example.org, example.net, example.com이 일치될 수 있습니다. 호스트 이름 일부를 와일드 카드 문자 *와 일치시킬 수도 있습니다. 예를 들어 *.example.net 호스트 규칙은 foo.example.netbar.example.net 호스트 이름과 일치합니다.

    • 포트 번호. 호스트 규칙 매개변수를 사용하여 포트 번호를 지정할 수도 있습니다. 예를 들어 포트 8080에 대한 example.net 요청을 전달하려면 호스트 규칙을 example.net:8080으로 설정합니다.
  • 경로 일치자(pathMatchers). 경로 일치자는 호스트 규칙에서 참조하는 구성 매개변수입니다. URL의 경로 부분과 요청을 처리할 백엔드 서비스 또는 백엔드 버킷 간의 관계를 정의합니다. 경로 일치자는 다음 두 요소로 구성됩니다.

    • 경로 일치자 기본 백엔드 서비스 또는 경로 일치자 기본 백엔드 버킷. 각 경로 일치자에 대해 기본 백엔드 서비스 또는 기본 백엔드 버킷 중 하나를 반드시 지정해야 하지만, 둘 다 지정할 수는 없습니다. 이 기본값은 호스트 이름이 경로 일치자와 연관된 호스트 규칙에 일치하는 동시에 URL 경로가 경로 일치자의 어떤 경로 규칙과도 일치하지 않는 URL에 대해 Google Cloud가 요청을 보낼 백엔드 서비스 또는 버킷을 나타냅니다.

    • 경로 규칙. 각 경로 일치자에 대해 URL 경로를 단일 백엔드 서비스 또는 백엔드 버킷에 매핑하는 키-값 쌍이 경로 규칙을 하나 이상 지정할 수 있습니다. 다음 섹션에는 경로 규칙이 작동하는 방식에 대한 자세한 정보가 포함되어 있습니다.

작업 순서

요청된 URL의 지정된 호스트 이름과 경로의 경우 Google Cloud는 URL 맵에 구성된 대로 다음 절차를 사용하여 올바른 백엔드 서비스 또는 백엔드 버킷으로 요청을 보냅니다.

  • URL 맵에 URL 호스트 이름을 위한 호스트 규칙이 없는 경우, Google Cloud는 URL 맵의 기본 백엔드 서비스 또는 기본 백엔드 버킷으로 요청을 전달합니다.

  • URL 맵에 URL 호스트 이름을 포함하는 호스트 규칙이 있는 경우 해당 호스트 규칙이 참조하는 경로 일치자는 다음과 같이 참조됩니다.

    • 경로 일치자가 URL 경로와 정확히 일치하는 경로 규칙을 포함할 경우 Google Cloud는 해당 경로 규칙의 백엔드 서비스 또는 백엔드 버킷으로 요청을 전달합니다.

    • 경로 일치자가 URL 경로와 정확하게 일치하는 경로 규칙을 포함하지 않지만 경로가 /*로 끝나고 프리픽스가 URL 경로의 가장 긴 부분과 일치하는 경로 규칙을 포함하는 경우, Google Cloud는 해당 경로 규칙의 백엔드 서비스 또는 백엔드 버킷으로 요청을 전달합니다. 예를 들어 두 경로 일치자 규칙 /video/hd/movie1/video/hd/*를 포함하는 URL 맵에 대해 URL이 정확하게 일치하는 경로 /video/hd/movie1을 포함할 경우, 해당 경로 규칙에 일치됩니다.

    • 앞의 조건이 모두 참이 아닐 경우 Google Cloud는 정의에 따라 경로 일치자의 기본 백엔드 서비스 또는 기본 백엔드 버킷으로 요청을 전달합니다.

경로 일치자 제약

경로 일치자 및 경로 규칙에는 다음과 같은 제약이 있습니다.

  • 경로 규칙은 슬래시 문자(/) 다음에만 와일드 카드 문자(*)를 포함할 수 있습니다. 예를 들어 경로 규칙에서 /videos/*/videos/hd/*는 유효하지만 /videos*/videos/hd*는 아닙니다.

  • 경로 규칙은 정규 표현식 또는 하위 문자열 일치를 사용하지 않습니다. 예를 들어 /videos/hd 또는 /videos/hd/*에 대한 경로 규칙은 /video/hd-abcd 경로가 있는 URL에 적용되지 않습니다. 그러나 /video/*에 대한 경로 규칙은 해당 경로에 적용됩니다.

  • 경로 일치자(및 URL 맵 일반)은 Apache LocationMatch 지시문과 같은 기능을 제공하지 않습니다. /videos/hd-abcd/videos/hd-pqrs와 같이 공통 프리픽스를 갖는 동적 URL 경로를 생성하는 애플리케이션이 있고, 이 경로에 대한 요청을 각각 다른 백엔드 서비스에 보내야 하는 경우 URL 맵을 사용하여 이를 수행하지 못할 수도 있습니다. 동적 URL이 몇 개만 포함된 간단한 경우에는 제한된 경로 규칙 집합으로 경로 일치자를 만드는 것이 가능할 수도 있습니다. 보다 복잡한 경우에는 백엔드에서 경로 기반 정규 표현식 일치를 수행해야 합니다.

호스트 이름은 단일 호스트 규칙만 참조할 수 있고 호스트 규칙은 단일 경로 일치자만 참조할 수 있습니다. 그러나 단일 호스트 규칙은 복수의 호스트 이름을 처리할 수 있으며 복수의 호스트 규칙은 단일 경로 일치자를 참조할 수 있습니다. 따라서 각 고유 URL은 하나의 백엔드 서비스 또는 백엔드 버킷으로만 전달됩니다.

  • Google Cloud는 URL의 호스트 이름 부분을 사용하여 단일 호스트 규칙 및 참조된 경로 일치자를 선택합니다.

  • 경로 일치자에서 동일한 경로에 대해 둘 이상의 경로 규칙을 만들 수 없습니다. 예를 들어 /videos/hd에 대한 요청은 둘 이상의 백엔드 서비스 또는 백엔드 버킷으로 전달될 수 없습니다. 백엔드 서비스는 여러 영역 및 리전에서 백엔드 인스턴스 그룹 또는 백엔드 네트워크 엔드포인트 그룹을 가질 수 있으며, Multi-Regional Storage 클래스를 사용하는 백엔드 버킷을 만들 수 있습니다.

URL 맵 및 프로토콜

대상 HTTP 프록시 및 대상 HTTPS 프록시가 모두 URL 맵을 참조하는 경우 동일한 URL 맵, 호스트 규칙, 경로 일치자를 사용하여 클라이언트가 제출한 HTTP 및 HTTPS 요청을 둘 다 처리할 수 있습니다.

다음 가이드에 표시된 대로 URL 맵을 사용하여 리디렉션을 구성할 수 있습니다.

가장 간단한 URL 맵

가장 간단한 URL 맵은 기본 백엔드 서비스 또는 기본 백엔드 버킷만 포함합니다. 호스트 규칙도, 경로 일치자도 없습니다. 기본 백엔드 서비스 또는 기본 백엔드 버킷 중 하나(사용자 지정)가 요청된 모든 URL을 처리합니다.

기본 백엔드 서비스를 정의하면 Google Cloud는 백엔드 서비스 구성에 따라 백엔드 인스턴스 그룹 또는 백엔드 NEG에 요청을 보냅니다.

기본값을 제외한 규칙이 없는 URL 맵(확대하려면 클릭)
기본값을 제외한 규칙이 없는 URL 맵(확대하려면 클릭)

외부 HTTP(S) 부하 분산기가 있는 URL 맵 워크플로 예시

다음 예시는 URL 맵의 작업 순서를 보여줍니다. 이 예시에서는 외부 HTTP(S) 부하 분산기의 URL 맵을 구성합니다. 개념적 단순성을 위해 백엔드 서비스만 사용하지만 백엔드 버킷을 대신 사용할 수도 있습니다. 외부 HTTP(S) 부하 분산기의 다른 구성요소를 만드는 방법은 외부 HTTP(S) 부하 분산기 만들기를 참조하세요.

내부 HTTP(S) 부하 분산기의 URL 맵 및 기타 구성요소를 만드는 방법에 대한 예시는 내부 HTTP(S) 부하 분산 설정 준비를 참조하세요.

다음 예시에서 설명하는 각 백엔드 서비스에는 외부 체계가 있으며 HTTP, HTTPS 또는 HTTP/2 프로토콜을 사용합니다.

  1. 부하 분산기의 URL 맵을 만들고 기본 백엔드 서비스를 지정합니다. 이 예시에서는 video-org-url-map라는 기존 백엔드 서비스를 참조하는 org-site이라는 URL 맵을 만듭니다.

    gcloud compute url-maps create video-org-url-map \
        --default-service=org-site
    
  2. 다음 특성을 사용하여 video-matcher라는 경로 일치자를 만듭니다.

    • 기본 백엔드 서비스인 video-site는 기존 백엔드 서비스입니다.
    • 정확한 URL 경로인 /video/hd 또는 URL 경로 프리픽스 /video/hd/*에 대한 요청을 video-hd라는 이름의 기존 백엔드 서비스에 전달하는 경로 규칙을 추가합니다.
    • 정확한 URL 경로인 /video/sd 또는 URL 경로 프리픽스 /video/sd/*에 대한 요청을 video-sd라는 이름의 기존 백엔드 서비스에 전달하는 경로 규칙을 추가합니다.
    gcloud compute url-maps add-path-matcher video-org-url-map \
        --path-matcher-name=video-matcher \
        --default-service=video-site \
        --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
    
  3. 경로 일치자 video-matcher를 참조하는 호스트 이름 example.net에 대한 호스트 규칙을 만듭니다.

    gcloud compute url-maps add-host-rule video-org-url-map \
        --hosts=example.net \
        --path-matcher-name=video-matcher
    

video-org-url-map URL은 다음과 같이 표시됩니다.

gcloud compute url-maps describe video-org-url-map
creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

video-org-url-map 맵은 요청된 URL을 다음과 같은 방식으로 백엔드로 전달합니다.

경로 규칙, 경로 일치자, 호스트 규칙이 표시된 URL 맵(확대하려면 클릭)
경로 규칙, 경로 일치자, 호스트 규칙이 표시된 URL 맵(확대하려면 클릭)

다음 표에서는 앞의 다이어그램에 표시된 요청 처리를 설명합니다.

호스트 이름 URL 경로 선택된 백엔드 서비스 선택 이유
호스트 이름:
example.org
example.net제외한 모든 호스트 이름
모든 경로 org-site 호스트 이름이 URL 맵의 호스트 규칙에 없으므로 요청이 URL 맵의 기본 백엔드 서비스로 전달됩니다.
호스트 이름:
example.net
/video
/video/examples
video-site /video/또는 /video/*에 대한 경로 규칙이 없으므로 요청이 기본 백엔드 서비스로 이동합니다. example.net에 대한 호스트 규칙이 경로 일치자를 참조하지만 해당 경로 일치자에는 이러한 경로에 적용할 경로 규칙이 없습니다.
호스트 이름:
example.net
/video/hd
/video/hd/movie1
/video/hd/movies/movie2
/video/hd/*로 시작하는 다른 URL
video-hd example.net에 대한 호스트 규칙은 /video/hd와 일치하거나 /video/hd/*로 시작하는 URL 경로에 대한 요청을 video-hd 백엔드 서비스에 전달하는 경로 규칙을 갖는 경로 일치자를 참조합니다.
호스트 이름:
example.net
/video/sd
/video/sd/show1
/video/sd/shows/show2
/video/sd/*로 시작하는 다른 URL
video-sd example.net에 대한 호스트 규칙은 /video/sd와 일치하거나 /video/sd/*로 시작하는 URL 경로에 대한 요청을 video-sd 백엔드 서비스에 전달하는 경로 규칙을 갖는 경로 일치자를 참조합니다.

URL 리디렉션

URL 리디렉션은 한 URL에서 다른 URL로 도메인 방문자를 리디렉션합니다.

기본 URL 리디렉션은 수신 요청의 특정 패턴과 일치하도록 설정되지 않습니다. 예를 들어 기본 URL 리디렉션을 사용하여 모든 호스트 이름을 원하는 호스트 이름으로 리디렉션할 수 있습니다.

다음 테이블에서 볼 수 있듯이 URL 리디렉션을 만드는 방법은 여러 가지입니다.

메서드 구성
URL 맵의 기본 URL 리디렉션 최상위 수준 defaultUrlRedirect
경로 일치자의 기본 URL 리디렉션 pathMatchers[].defaultUrlRedirect[]
경로 일치자의 경로 규칙 URL 리디렉션 pathMatchers[].pathRules[].urlRedirect
경로 일치자의 라우팅 규칙 URL 리디렉션 pathMatchers[].routeRules[].urlRedirect

defaultUrlRedirect 또는 urlRedirect 내에서 pathRedirect는 항상 다음과 같이 작동합니다.

  • 전체 요청 경로가 지정한 경로로 바뀝니다.

defaultUrlRedirect 또는 urlRedirect 내에서 prefixRedirect의 작동 양상은 사용 방식에 따라 다릅니다.

  • defaultUrlRedirect를 사용하는 경우 일치 경로는 항상 /이므로 prefixRedirect가 프리픽스 앞에 추가됩니다.
  • 만약 사용자가 경로 일치자의 라우팅 규칙이나 경로 규칙 내에서 urlRedirect를 사용하는 경우, 요청된 경로가 경로 규칙 또는 라우팅 규칙에 정의된 대로 어떻게 일치하는지를 기준으로 prefixRedirect가 프리픽스로 교체됩니다.

리디렉션의 예시

다음 표에서는 리디렉션 구성의 몇 가지 예시를 제공합니다. 오른쪽 열에는 기본 URL 리디렉션의 API 구성이 표시됩니다.

구성 기본 URL 리디렉션을 사용하여 수행
HTTP-to-HTTPS 리디렉션

http://host.name/path
에서
https://host.name/path 로 리디렉션

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
           
HTTP-to-HTTPS + 호스트 리디렉션

http://any-host-name/path
에서
https://www.example.com/path 로 리디렉션

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
          
HTTP-to-HTTPS + 호스트 리디렉션 + 전체 경로 리디렉션

http://any-host-name/path
에서
https://www.example.com/newPath 로 리디렉션

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
           
HTTP-to-HTTPS + 호스트 리디렉션 + 프리픽스 리디렉션

http://any-host-name/originalPath
에서
https://www.example.com/newPrefix/originalPath 로 리디렉션

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              prefixRedirect: "/newPrefix"
            

다음 예시에서는 각 API 리소스에 주석을 추가합니다.

kind: compute#urlMap
name: web-map-http
defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
  },
  "defaultUrlRedirect": {
    "redirectResponseCode": enum,
  }

전체 엔드 투 엔드 예시는 다음 페이지를 참조하세요.

고급 트래픽 관리

모든 제품에서 모든 URL 맵 기능이 제공되는 것은 아닙니다. URL 맵은 내부 HTTP(S) 부하 분산 및 Traffic Director와 함께 사용하여 여러 가지 고급 트래픽 관리 기능을 지원하지만, 이들 중 모두가 외부 HTTP(S) 부하 분산에서 지원되는 것은 아닙니다.

다음 테이블에서 제품별로 사용 가능한 URL 맵 기능을 확인할 수 있습니다. 각 제품에는 트래픽 관리의 작동 방식을 설명하는 전용 주제가 있으며 각 사용 사례에 대한 샘플 URL 맵이 포함되어 있습니다.

제품 URL 맵 기능 및 트래픽 관리 가이드
외부 HTTP(S) 부하 분산 부하 분산기의 기능: 라우팅 및 트래픽 관리

외부 HTTP(S) 부하 분산기의 트래픽 관리 개요

내부 HTTP(S) 부하 분산 부하 분산기의 기능: 라우팅 및 트래픽 관리

내부 HTTP(S) 부하 분산기의 트래픽 관리 개요

내부 HTTP(S) 부하 분산기의 트래픽 관리 설정

Traffic Director Traffic Director의 기능: 라우팅 및 트래픽 관리

고급 트래픽 관리 개요

고급 트래픽 관리 구성

API 및 Cloud SDK 참조

Cloud Console 외에도 API 및 Cloud SDK를 사용하여 URL 맵을 만들 수 있습니다.

API

REST API를 통해 URL 맵으로 작업할 때 사용할 수 있는 속성 및 메서드에 대한 설명은 다음을 참조하세요.

제품 API 문서
외부 HTTP(S) 부하 분산 urlMaps
내부 HTTP(S) 부하 분산 regionUrlMaps
Traffic Director urlMaps

Cloud SDK

Cloud SDK의 gcloud 명령줄 도구는 다음을 참조하세요.

고급 트래픽 관리의 경우는 YAML 파일을 사용하고 gcloud compute url-maps import 명령어로 가져오세요.

다음 단계