고급 트래픽 관리 개요

Traffic Director는 트래픽 처리 방법을 세부적으로 제어할 수 있는 고급 트래픽 관리 기능을 제공합니다. Traffic Director에서 지원하는 사용 사례는 다음과 같습니다.

  • 하나 이상의 서비스에 대한 요청의 세분화된 라우팅
  • 리디렉션 및 헤더 변환과 같은 요청 및 응답 기반 작업
  • 부하 분산 향상을 위해 서비스의 백엔드 간에 세분화된 트래픽 분산

이러한 고급 트래픽 관리 기능을 사용하면 가용성 및 성능 목표를 충족할 수 있습니다. 이러한 사용 사례에 Traffic Director를 사용할 때의 이점 중 하나는 애플리케이션 코드를 수정할 필요 없이 트래픽 관리 방법을 업데이트할 수 있다는 점입니다.

사용 사례

고급 트래픽 관리는 많은 사용 사례를 해결합니다. 이 섹션에서는 몇 가지 개략적인 예시를 설명합니다.

고급 트래픽 관리 구성고급 트래픽 관리로 VM 기반의 프록시리스 gRPC 서비스 설정 가이드에서 샘플 코드를 포함한 더 많은 예시를 확인할 수 있습니다.

맞춤설정을 위한 세분화된 트래픽 라우팅

요청 매개변수에 따라 서비스로 트래픽을 라우팅할 수 있습니다. 예를 들어 이 기능을 사용하여 Android 사용자에게 보다 맞춤화된 환경을 제공할 수 있습니다. 다음 다이어그램에서 Traffic Director는 일반 서비스가 아닌 Android 서비스에 user-agent:Android 헤더가 포함된 요청을 보내도록 서비스 메시를 구성합니다.

Android에 설정된 user-agent 헤더 기반 라우팅(확대하려면 클릭)
Android에 설정된 user-agent 헤더 기반 라우팅(확대하려면 클릭)

더 안전한 배포를 위한 가중치 기반 트래픽 분할

기존 프로덕션 서비스의 새 버전을 배포하는 것은 위험할 수 있습니다. 테스트가 테스트 환경으로 전달된 후에도 모든 사용자가 바로 새 버전으로 라우팅하는 것을 원하지 않을 것입니다.

Traffic Director를 사용하면 여러 서비스에 트래픽을 분산할 수 있도록 가중치 기반 트래픽 분할을 정의할 수 있습니다. 예를 들어 트래픽의 1%를 새 버전의 서비스로 전송하고 모든 것이 작동하는지 모니터링한 다음 새 서비스로 이동하는 트래픽의 비율을 점차적으로 확대할 수 있습니다.

Traffic Director 가중치 기반 트래픽 분할(확대하려면 클릭)
Traffic Director 가중치 기반 트래픽 분할(확대하려면 클릭)

디버깅을 위한 트래픽 미러링

문제를 디버깅할 때 프로덕션 트래픽의 복사본을 디버깅 서비스로 보내는 것이 유용할 수 있습니다. Traffic Director를 사용하면 요청을 한 서비스에 전송하고 해당 요청의 사본을 다른 서비스에 전송하도록 요청 미러링 정책을 설정할 수 있습니다.

Traffic Director 트래픽 미러링(확대하려면 클릭)
Traffic Director 트래픽 미러링(확대하려면 클릭)

성능 향상을 위한 세분화된 부하 분산

애플리케이션 특성에 따라 서비스의 백엔드에 트래픽이 분산되는 방식을 세부 조정하면 성능 및 가용성을 개선할 수 있습니다. Traffic Director를 사용하면 필요에 따라 트래픽이 분산되도록 고급 부하 분산 알고리즘을 적용할 수 있습니다.

다음 다이어그램은 이전 다이어그램과 비교하여 대상 백엔드 서비스(프로덕션 서비스)와 이 백엔드 서비스의 백엔드(가상 머신 1, 가상 머신 2, 가상 머신 3)를 모두 보여줍니다. 고급 트래픽 관리를 사용하면 대상 백엔드 서비스를 선택하는 방식과 대상 서비스의 백엔드 간에 트래픽을 분산하는 방식을 모두 구성할 수 있습니다.

Traffic Director 부하 분산(확대하려면 클릭)
Traffic Director 부하 분산(확대하려면 클릭)

고급 트래픽 관리의 작동 방식

Traffic Director를 설정할 때 사용하는 라우팅 규칙 맵과 백엔드 서비스 리소스를 사용하여 고급 트래픽 관리를 구성합니다. Traffic Director는 결과적으로 설정된 고급 트래픽 관리 정책을 적용하도록 Envoy 프록시와 프록시리스 gRPC 애플리케이션을 구성합니다.

개략적으로 다음을 수행합니다.

  1. 아웃바운드 요청의 특성에 따라 다음을 수행하도록 라우팅 규칙 맵을 구성합니다.

    1. 요청이 라우팅될 백엔드 서비스를 선택합니다.

    2. 원하는 경우 추가 작업을 수행합니다.

  2. 대상 서비스가 선택된 후에 백엔드 및 엔드포인트에 트래픽이 분산되는 방식을 제어하도록 서비스(백엔드 서비스)를 구성합니다.

트래픽 라우팅 및 작업

Traffic Director에서 라우팅 규칙 맵은 전달 규칙, 대상 프록시, URL 맵 리소스의 조합을 나타냅니다. 라우팅 및 작업과 관련된 모든 고급 트래픽 관리 기능은 URL 맵을 사용하여 구성됩니다.

라우팅 규칙 맵에서 다음과 같은 고급 트래픽 관리 기능을 설정할 수 있습니다.

요청 처리

클라이언트가 요청을 보내면 요청은 다음과 같이 처리됩니다.

  1. 요청을 특정 라우팅 규칙 맵에 매칭합니다. 이 일치 항목은 다음과 같이 만들어집니다.
    1. Envoy를 사용하는 경우:
      1. 요청의 대상 IP 주소와 포트는 모든 라우팅 규칙 맵에 있는 IP 주소 및 전달 규칙의 포트와 비교합니다. 부하 분산 체계 INTERNAL_SELF_MANAGED가 있는 전달 규칙이 있는 라우팅 규칙만 고려합니다.
      2. 요청과 일치하는 전달 규칙은 URL 맵을 참조하는 대상 HTTP 또는 gRPC 프록시를 참조합니다. 이 URL 맵에는 라우팅 및 작업에 사용되는 정보가 포함됩니다.
    2. 프록시리스 gRPC를 사용하는 경우:
      1. 대상 gRPC 프록시를 참조하는 전달 규칙을 만들 때 0.0.0.0 IP 주소만 사용할 수 있으므로 요청의 IP 주소는 무시됩니다. 부하 분산 체계 INTERNAL_SELF_MANAGED가 있는 전달 규칙이 있는 라우팅 규칙만 고려합니다.
      2. 대상 URI(예: xds:///foo.myservice:8080)의 포트는 부하 분산 스키마가 INTERNAL_SELF_MANAGED인 전달 규칙의 포트와 비교합니다. 전달 규칙의 IP 주소는 사용하지 않습니다.
      3. 요청과 일치하는 전달 규칙은 URL 맵을 참조하는 대상 gRPC 프록시를 참조합니다. 이 URL 맵에는 라우팅 및 작업에 사용되는 정보가 포함됩니다.
  2. 적절한 URL 맵이 결정되면 URL 맵을 평가하여 대상 백엔드 서비스를 결정하고 원하는 경우 작업을 적용합니다.
  3. 대상 백엔드 서비스를 선택한 후 백엔드 서비스 리소스의 구성에 따라 이 대상 백엔드 서비스의 백엔드 또는 엔드포인트 간에 트래픽이 분산됩니다.

두 번째 단계는 다음 호스트 및 경로에 기반한 단순 라우팅 섹션에서 설명합니다. 세 번째 단계는 고급 라우팅 및 작업에서 설명합니다.

호스트 및 경로에 기반한 단순 라우팅

Traffic Director는 간소화된 라우팅 스키마와 고급 스키마를 지원합니다. 작업을 비롯한 고급 라우팅 스키마에 대해서는 다음 섹션인 고급 라우팅 및 작업에 설명되어 있습니다. 단순 스키마에서 호스트 및 경로(선택사항)를 지정합니다. 요청의 호스트 및 경로를 평가하여 요청을 라우팅해야 할 서비스를 결정합니다.

  • 요청 호스트는 URL의 도메인 이름 부분입니다. 예를 들어 URL http://example.com/video/의 호스트 부분은 example.com입니다.
  • 요청 경로는 URL에서 호스트 이름 다음 부분입니다. 예를 들어 http://example.com/video에서 /video입니다.
호스트 및 경로에 기반한 단순 라우팅 설정

호스트 및 경로에 기반한 단순 라우팅은 다음으로 구성된 라우팅 규칙 맵에 설정됩니다.

  • 전역 전달 규칙
  • 대상 HTTP 프록시 또는 대상 gRPC 프록시
  • URL 맵

대부분의 구성은 URL 맵에서 실행되며, 초기 라우팅 규칙 맵을 만든 후에는 일반적으로 라우팅 규칙 맵의 URL 맵 부분만 수정하면 됩니다. 이 다이어그램에서 경로 규칙은 다음 다이어그램과 비슷한 작업을 수행합니다.

호스트 및 경로 리소스에 기반한 라우팅(확대하려면 클릭)
호스트 및 경로 리소스에 기반한 라우팅(확대하려면 클릭)

가장 간단한 규칙은 기본 서비스를 사용하여 와일드 카드(*) 호스트 규칙 및 경로 일치자만 지정하는 기본 규칙입니다. 기본 규칙을 만든 후 다른 호스트 및 경로를 지정하는 규칙을 추가할 수 있습니다. 아웃바운드 요청은 이러한 규칙에 따라 다음과 같이 평가됩니다.

요청의 호스트(예: example.com)가 호스트 규칙과 일치하는 경우:

  1. 경로 일치자를 다음으로 평가합니다.
  2. 각 경로 일치자에는 요청의 경로와 비교하여 평가하는 하나 이상의 경로 규칙이 포함됩니다.
  3. 일치하는 항목이 확인되면 요청이 경로 규칙에 지정된 서비스로 라우팅됩니다.
  4. 각 경로 일치자에는 호스트 규칙은 일치하지만 경로 규칙은 일치하지 않을 경우 요청이 라우팅되는 기본 서비스가 포함됩니다.

지정한 호스트 규칙과 요청이 일치하지 않으면 해당 요청이 기본 규칙에 지정된 서비스로 라우팅됩니다.

URL 맵 리소스의 필드와 필드 작동 방식에 대한 자세한 내용은 urlMaps REST API 페이지를 참조하세요.

고급 라우팅 및 작업

요청의 호스트 및 경로를 기반으로 요청을 라우팅하는 것보다 더 많은 작업을 수행하려면 고급 규칙을 설정하여 요청을 라우팅하고 작업을 수행할 수 있습니다.

고급 라우팅(확대하려면 클릭)
고급 라우팅(확대하려면 클릭)

개략적으로 고급 라우팅 및 작업은 다음과 같이 작동합니다.

  1. 단순 라우팅과 마찬가지로 요청의 호스트는 URL 맵에서 구성하는 호스트 규칙과 비교합니다. 요청의 호스트가 호스트 규칙과 일치하면 호스트 규칙의 경로 일치자를 평가합니다.
  2. 경로 일치자에는 요청과 비교하여 평가하는 하나 이상의 경로 규칙이 포함됩니다.
    1. 이러한 라우팅 규칙은 특정한 일치 조건(예: 프리픽스 일치)에 따라 요청 속성(호스트, 경로, 헤더, 쿼리 매개변수)을 매칭하여 우선순위로 평가합니다.
  3. 라우팅 규칙이 선택되면 작업이 적용될 수 있습니다. 기본 작업은 요청을 단일 대상 서비스로 라우팅하는 것이지만 다른 작업도 구성할 수 있습니다.
고급 라우팅

고급 라우팅은 위에서 설명한 단순 라우팅과 비슷하지만, 아래 설명과 같이 규칙 우선순위 및 추가 일치 조건을 지정할 수 있다는 점이 다릅니다.

고급 라우팅을 사용하면 각 규칙에 고유한 우선순위를 지정해야 합니다. 이 우선순위에 따라 라우팅 규칙을 평가하는 순서가 결정됩니다. 값이 낮은 우선순위가 값이 높은 우선순위보다 우선 적용됩니다. 요청이 규칙과 일치하면 규칙이 적용되고 다른 규칙은 무시됩니다.

고급 라우팅도 추가 일치 조건을 지원합니다. 예를 들어 헤더 이름이 프리픽스 또는 서픽스 등을 기준으로 정확하게 일치하거나 일부만 일치하는 경우 규칙이 요청의 헤더와 일치하도록 지정할 수 있습니다. 헤더 이름을 정규 표현식과 비교하여 평가하거나 헤더 유무를 확인하는 다른 기준에 따라 일치시킬 수 있습니다.

호스트, 경로, 헤더, 쿼리 매개변수를 우선순위 및 일치 조건과 결합하면 정확한 트래픽 관리 요건에 맞는 매우 정교한 규칙을 만들 수 있습니다.

HTTP 호스트와 gRPC 호스트 비교

HTTP 기반 애플리케이션을 작성하는 경우 호스트는 애플리케이션이 호출하는 URL의 도메인 이름 부분입니다. 예를 들어 URL http://example.com/video/의 호스트 부분은 example.com입니다.

gRPC 기반 애플리케이션을 작성하는 경우 호스트는 클라이언트가 채널 URI에서 특정 서비스에 연결하는 데 사용하는 이름입니다. 예를 들어 채널 URI xds:///example.com의 호스트 부분은 example.com입니다.

HTTP 경로와 gRPC 경로 비교

HTTP 기반 애플리케이션을 작성하는 경우 경로는 URL에서 호스트 이름 다음 부분입니다(예: http://example.com/video/video).

gRPC 기반 애플리케이션을 작성하는 경우 경로는 HTTP/2 요청의 :path 헤더에 있고 /SERVICE_NAME/METHOD_NAME/과 같습니다. 예를 들어 Example gRPC 서비스에서 Download 메서드를 호출하면 :path 헤더의 콘텐츠는 /Example/Download와 같이 표시됩니다.

기타 gRPC 헤더(메타데이터)

gRPC는 gRPC 클라이언트와 gRPC 서버 간의 메타데이터 전송을 지원하여 RPC 호출에 대한 추가 정보를 제공합니다. 이 메타데이터는 HTTP/2 요청에서 헤더로 전달되는 키-값 쌍의 형식을 따릅니다.

작업

Traffic Director를 사용하면 요청을 처리할 때 Envoy 프록시 또는 프록시리스 gRPC 애플리케이션이 수행하는 작업을 지정할 수 있습니다. Traffic Director를 사용하여 다음 작업을 구성할 수 있습니다.

작업(API 필드 이름) 설명
리디렉션(urlRedirect) 구성 가능한 3xx 응답 코드를 반환합니다. 또한 적절한 URI로 Location 응답 헤더를 설정하여 리디렉션 작업에 지정된 대로 호스트와 경로를 바꿉니다.
URL 재작성(urlRewrite) 선택한 백엔드 서비스에 요청을 전송하기 전에 URL의 호스트 이름 부분이나 URL의 경로 부분 또는 둘 다 재작성할 수 있습니다.
헤더 변환(headerAction) 백엔드 서비스에 요청을 보내기 전에 요청 헤더를 추가하고 제거합니다. 또한 백엔드 서비스에서 응답을 수신한 후 응답 헤더를 추가하거나 삭제할 수 있습니다.
트래픽 미러링(requestMirrorPolicy) 선택한 백엔드 서비스로 요청을 전달하는 것 외에 동일한 요청을 파이어 앤 포겟(fire-and-forget) 방식으로 구성된 미러링 백엔드 서비스에 전송합니다. 부하 분산기는 미러링된 요청을 보내는 백엔드의 응답을 기다리지 않습니다.

미러링은 백엔드 서비스의 새 버전을 테스트하는 데 유용합니다. 또한 미러링을 사용하면 프로덕션 버전이 아닌 백엔드 서비스의 디버그 버전에서 프로덕션 오류를 디버깅할 수 있습니다.
가중치 기반 트래픽 분할(weightedBackendServices) 일치하는 규칙의 트래픽을 개별 백엔드 서비스에 할당된 사용자 정의 가중치에 맞게 여러 백엔드 서비스에 배포할 수 있습니다.

이 기능은 스테이징 배포 또는 A/B 테스팅을 구성하는 데 유용합니다. 예를 들어 트래픽 중 99%는 안정적인 애플리케이션 버전이 실행되는 서비스에 전송하고 나머지 1%는 해당 애플리케이션이 최신 버전이 실행되는 별도의 서비스에 전송하도록 라우팅 작업을 구성할 수 있습니다.
재시도(retryPolicy) 부하 분산기가 실패한 요청을 재시도하는 조건, 재시도 전 부하 분산기가 대기하는 시간, 최대 재시도 허용 횟수를 구성합니다.
제한 시간(timeout) 선택한 경로의 제한 시간을 지정합니다. 제한 시간은 요청이 완전히 처리된 시간부터 응답이 완전히 처리될 때까지 계산됩니다. 제한 시간에는 모든 재시도 횟수가 포함됩니다.
결함 주입(faultInjectionPolicy) 높은 지연 시간, 서비스 과부하, 서비스 장애, 네트워크 파티션 나누기 등의 장애를 시뮬레이션하는 요청을 제공할 때 의도적으로 오류를 발생시킬 수 있습니다. 이 기능은 장애를 시뮬레이션하면서 서비스의 복원력을 테스트하는 데 유용합니다.
보안 정책(corsPolicy) 교차 출처 리소스 공유(CORS) 정책은 CORS 요청을 적용하는 데 필요한 설정을 처리합니다.

작업과 그 작동 방식에 대한 자세한 내용은 URL 맵 API 참조를 확인하세요.

각 라우팅 규칙에서 다음 라우팅 작업 중 하나를 지정할 수 있습니다(Google Cloud Console에서는 '기본 작업'이라고 함).

  • 트래픽을 단일 서비스로 라우팅(service)
  • 여러 서비스 간 트래픽 분할(weightedBackendServices)
  • 리디렉션 URL(urlRedirect)

또한 앞에서 언급한 라우팅 작업 중 하나를 다음 라우팅 작업(Google Cloud Console에서 '부가 작업'이라고 함) 중 하나 이상과 결합할 수 있습니다.

  • 요청/응답 헤더 조작(headerAction)
  • 트래픽 미러링(requestMirrorPolicy)
  • URL 호스트/경로 재작성(urlRewrite)
  • 실패한 요청 재시도(retryPolicy)
  • 제한 시간 설정(timeout)
  • 트래픽 비율에 결함 도입(faultInjectionPolicy)
  • 교차 출처 리소스 공유(CORS) 정책 추가(corsPolicy)

작업은 특정 라우팅 규칙과 연결되어 있으므로 Envoy 프록시 또는 프록시리스 gRPC 애플리케이션은 처리 중인 요청을 기반으로 다른 작업을 적용할 수 있습니다.

서비스의 백엔드 간에 트래픽 분산

요청 처리의 설명처럼 클라이언트는 아웃바운드 요청을 처리할 때 먼저 대상 서비스를 선택합니다. 대상 서비스를 선택하면 요청을 수신할 백엔드/엔드포인트를 파악해야 합니다.

백엔드 간에 트래픽 분산(확대하려면 클릭)
백엔드 간에 트래픽 분산(확대하려면 클릭)

위의 다이어그램에서는 규칙이 간소화되었습니다. 이는 일반적으로 호스트 규칙, 경로 일치자, 하나 이상의 경로 또는 라우팅 규칙입니다. 대상 서비스는 (백엔드) 서비스입니다. 백엔드 1, ..., 백엔드 n은 실제로 요청을 수신하고 처리합니다. 이러한 백엔드는 서버 측 애플리케이션 코드를 호스팅하는 Compute Engine 가상 머신일 수 있습니다.

기본적으로 요청을 처리하는 클라이언트는 용량이 있는 가장 가까운 정상 백엔드로 요청을 전송합니다. 특정 백엔드의 과부하를 방지하기 위해 라운드 로빈 부하 분산 알고리즘을 사용하여 대상 서비스의 다른 백엔드에 후속 요청의 부하를 분산합니다. 하지만 경우에 따라 이러한 동작을 더 세밀하게 제어해야 할 수 있습니다.

부하 분산, 세션 어피니티, 백엔드 보호

각 서비스에 다음과 같은 트래픽 분산 정책을 설정할 수 있습니다.

정책(API 필드 이름) 설명
부하 분산 모드(balancingMode) 대상 서비스가 선택된 후 네트워크 엔드포인트 그룹 또는 관리형 인스턴스 그룹을 선택하는 방법을 제어합니다. 동시 연결, 요청 비율 등을 기준으로 부하를 분산하도록 분산 모드를 구성할 수 있습니다.
부하 분산 정책(localityLbPolicy) 네트워크 엔드포인트 그룹 또는 관리형 인스턴스 그룹 내의 백엔드 간에 트래픽을 분산하는 데 사용되는 부하 분산 알고리즘을 설정합니다. 다양한 알고리즘(예: 라운드 로빈, 최소 요청 등) 중에서 선택하여 성능을 최적화할 수 있습니다.
세션 어피니티(sessionAffinity) 세션 어피니티는 백엔드가 정상이고 용량이 있는 한 특정 클라이언트의 요청을 동일한 백엔드로 전송합니다. Traffic Director는 4가지 세션 어피니티 옵션, 즉 클라이언트 IP 주소, HTTP 쿠키 기반, HTTP 헤더 기반, 생성된 쿠키 어피니티(Traffic Director에서 자체 생성)를 지원합니다.
일관된 해시(consistentHash) HTTP 헤더, 쿠키 또는 기타 속성을 기반으로 소프트 세션 어피니티를 제공하는 데 사용할 수 있습니다.
회로 차단기(circuitBreakers) 백엔드 서비스 연결량 및 연결당 요청의 상한값을 설정합니다.
이상점 감지(outlierDetection) (1) 관리형 인스턴스 그룹 또는 네트워크 엔드포인트 그룹에서 비정상 백엔드 또는 엔드포인트를 삭제하고 (2) 트래픽을 다시 수신하기에 충분할 정도로 정상으로 간주되는 경우 백엔드 또는 엔드포인트를 다시 추가할 기준을 지정합니다. 백엔드/엔드포인트가 정상으로 간주되는지 여부는 서비스와 연결된 상태 확인에 따라 결정됩니다.

다양한 트래픽 분산 옵션과 그 작동 방식에 대한 자세한 내용은 백엔드 서비스 API 참조를 확인하세요.

필터링 구성

Traffic Director의 핵심 책임 중 하나는 구성을 생성하여 이 구성을 다양한 Traffic Director 클라이언트(예: Envoy 프록시 또는 gRPC 애플리케이션)로 전송하는 것입니다. Traffic Director는 클라이언트에게 수행해야 하는 작업을 알리는 구성을 전송하여 서비스 메시를 제어합니다. Traffic Director는 제어 영역입니다.

Traffic Director에서 구성을 만들거나 업데이트하면 Traffic Director가 이 구성을 클라이언트가 이해할 수 있는 언어로 변환합니다. 기본적으로 Traffic Director는 이 구성을 모든 클라이언트와 공유합니다. 경우에 따라 특정 구성을 수신하는 Traffic Director 클라이언트를 맞춤설정할 수 있습니다. 다시 말해 구성을 특정 클라이언트로 필터링할 수 있습니다.

이는 고급 기능이지만 다음 예시는 필터링 구성이 유용할 수 있는 경우를 보여줍니다.

  • 조직에서 공유 VPC 네트워킹 모델을 사용하고 있고 여러 팀에서 여러 서비스 프로젝트에 Traffic Director를 사용하고 있습니다. 구성을 다른 서비스 프로젝트에서 격리하려면 특정 Traffic Director 클라이언트가 구성의 하위 집합만 수신하도록 구성을 필터링할 수 있습니다.
  • Traffic Director에서 구성한 라우팅 규칙 및 서비스가 매우 많아서 Traffic Director 클라이언트에 대량의 구성을 보내지 않기를 원합니다. 크고 복잡한 구성을 사용하여 아웃바운드 요청을 평가해야 하는 클라이언트는 간소화된 구성만 사용해서 요청을 평가해야 하는 클라이언트보다 성능이 떨어질 수 있습니다.

구성 필터링은 메타데이터 필터 개념을 기반으로 합니다.

  1. Traffic Director 클라이언트는 연결되면 부트스트랩 파일의 정보를 Traffic Director로 제공합니다.
  2. 이 정보에는 Envoy 프록시 또는 gRPC 애플리케이션을 배포할 때 부트스트랩 파일에서 지정하는 메타데이터 필드 콘텐츠가 포함되며 이 콘텐츠는 키-값 쌍의 형식을 따릅니다.
  3. 라우팅 규칙 맵에서 구성하는 전달 규칙 또는 라우팅 규칙에 메타데이터 필터를 추가할 수 있습니다.
  4. 이러한 리소스에 메타데이터 필터를 추가하면 Traffic Director는 메타데이터 필터 조건과 일치하는 메타데이터를 제공하는 클라이언트와만 구성을 공유합니다.

전달 규칙에 메타데이터 필터를 적용할 수 있습니다. 이 경우 일치하는 메타데이터를 제공하는 Traffic Director 클라이언트와만 라우팅 규칙 맵 및 관련 서비스를 공유합니다.

또는 특정 라우팅 규칙에 메타데이터 필터를 적용할 수 있습니다. 이 경우 Traffic Director는 일치하는 메타데이터를 제공하는 Traffic Director 클라이언트와만 특정 라우팅 규칙 및 관련 서비스를 공유합니다. 메타데이터 필터를 구성하는 방법에 대한 자세한 내용은 MetadataFilter 일치를 기반으로 구성 필터링 설정을 참조하세요.

세션 어피니티

이 예시에서는 세션 어피니티를 사용 설정하는 방법을 보여줍니다.

  1. 관리형 인스턴스 그룹 또는 네트워크 엔드포인트 그룹을 구성한 후에는 세션 어피니티로 새로운 백엔드 서비스를 만듭니다.

    gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
    --health-checks=HEALTH_CHECK \
    --protocol=TCP \
    --session-affinity=CLIENT_IP \
    --global
    
  2. PORT를 포트로 바꿔 새 전달 규칙을 만듭니다.

   gcloud beta compute forwarding-rules create td-vm-forwarding-rule 
--global
--load-balancing-scheme=INTERNAL_SELF_MANAGED
--address=[VIP]
--address-region=us-central1
--target-tcp-proxy=td-vm-proxy
--ports PORT
--network default

이제 Traffic Director가 전달 규칙에 지정된 VIP의 트래픽을 관리형 인스턴스 그룹의 여러 백엔드로 부하 분산하도록 구성되었습니다.

제한사항

  • 이 문서에서 설명하는 일부 기능은 Traffic Director를 사용하는 프록시리스 gRPC 서비스에 대해 구성할 수 없습니다. 지원되는 기능은 라우팅 및 트래픽 관리, 부하 분산, Traffic Director 기능의 기타 표를 참조하세요.

  • Traffic Director가 포함된 프록시리스 gRPC 애플리케이션에 적용되는 추가 제한사항은 개요 가이드의 제한사항 섹션을 참조하세요.

다음 단계