Anthos Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

부하 분산 API의 고급 트래픽 관리 개요

이 문서는 Cloud Service Mesh 및 서비스 메시 개념에 관해 중급 및 고급 수준의 지식을 갖추고 Cloud Service Mesh 배포에서 트래픽을 관리하는 방법을 결정 및 구성하는 메시 또는 플랫폼 관리자와 서비스 개발자를 대상으로 합니다. 이 문서는 서비스 라우팅 API가 아닌 부하 분산 API에만 적용됩니다. Cloud Service Mesh 배포에 서비스 라우팅 API가 사용되는 경우 고급 트래픽 관리 개요를 참조하세요.

Cloud Service Mesh는 트래픽 처리 방법을 세부적으로 제어할 수 있는 고급 트래픽 관리 기능을 제공합니다. Cloud Service Mesh에서는 다음 사용 사례가 지원됩니다.

하나 이상의 서비스에 대한 요청의 세분화된 트래픽 라우팅
가중치 기반 트래픽 분할로 여러 서비스에 트래픽 분산
하나의 디버깅 서비스에 요청을 보내고 다른 서비스로 사본을 전송되는 트래픽 미러링 정책
부하 분산 향상을 위해 서비스의 백엔드 간에 세분화된 트래픽 분산

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

대상 HTTP 프록시를 사용하여 HTTP 요청을 보내도록 Envoy 프록시를 구성하면 이 문서의 모든 기능을 사용할 수 있습니다.
Cloud Service Mesh와 함께 프록시리스 gRPC 서비스 또는 애플리케이션을 사용하면 일부 기능을 사용할 수 없습니다.
대상 TCP 프록시를 사용하여 TCP 요청을 보내도록 Envoy 프록시를 구성하면 대상 TCP 프록시 구성에 URL 맵이 없으므로 이러한 기능을 하나도 사용할 수 없습니다.

자세한 내용은 기능 페이지를 참조하세요.

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

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

아웃바운드 요청의 특성에 따라 다음을 수행하도록 라우팅 규칙 맵을 구성합니다.
1. 요청이 라우팅될 백엔드 서비스를 선택합니다.
2. 원하는 경우 추가 작업을 수행합니다.
대상 서비스가 선택된 후에 백엔드 및 엔드포인트에 트래픽이 분산되는 방식을 제어하도록 백엔드 서비스를 구성합니다.

필터링 구성

Cloud Service Mesh의 핵심 책임 중 하나는 전달 규칙, 대상 프록시, URL 맵에서 구성 정보를 생성한 다음 이 정보를 Cloud Service Mesh 클라이언트(예: Envoy 프록시 및 gRPC 애플리케이션)로 전송하는 것입니다. Cloud Service Mesh는 클라이언트에게 동작 방식과 트래픽 라우팅 방법을 알려주는 구성 정보를 전송하여 서비스 메시를 제어합니다. Cloud Service Mesh는 컨트롤 플레인입니다.

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

고급 기능이지만 다음 예시는 필터링 구성이 도움이 되는 경우를 보여줍니다.

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

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

Cloud Service Mesh 클라이언트는 연결되면 부트스트랩 파일의 정보를 Cloud Service Mesh에 제공합니다.
이 정보에는 Envoy 프록시 및 gRPC 애플리케이션을 배포할 때 부트스트랩 파일에서 지정하는 메타데이터 필드 콘텐츠가 포함되며 이 콘텐츠는 키-값 쌍의 형식을 따릅니다.
전달 규칙에 메타데이터 필터를 추가할 수 있습니다. 전달 규칙에 연결된 전체 구성이 필터링됩니다.
URL 맵에서 메타데이터 필터를 추가할 수 있습니다. 메타데이터 필터는 경로별 라우팅 기준에 적용됩니다.
Cloud Service Mesh는 메타데이터 필터 조건과 일치하는 메타데이터를 제공하는 클라이언트에만 구성을 공유합니다.

Envoy에 대해 메타데이터 필터를 구성하는 방법은 MetadataFilter 일치에 따라 구성 필터링 설정을 참조하세요.

트래픽 라우팅 및 작업

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

다음 섹션에서는 라우팅 규칙 맵에서 설정할 수 있는 고급 트래픽 관리 기능을 설명합니다.

요청 처리

클라이언트가 요청을 전송하면 요청은 다음 단계에 설명된 대로 처리됩니다.

다음과 같이 요청이 특정 라우팅 규칙 맵에 일치합니다.
- Envoy를 사용하는 경우:
  - 요청의 대상 IP 주소와 포트는 모든 라우팅 규칙 맵에 있는 IP 주소 및 전달 규칙의 포트와 비교합니다. 부하 분산 스키마 INTERNAL_SELF_MANAGED를 갖는 전달 규칙이 있는 라우팅 규칙 맵만 고려합니다.
  - 요청과 일치하는 전달 규칙은 URL 맵을 참조하는 대상 HTTP 또는 gRPC 프록시를 참조합니다. 이 URL 맵에는 라우팅 및 작업에 사용되는 정보가 포함됩니다.
- 프록시리스 gRPC를 사용하는 경우:
  - xds 이름 변환 스키마를 사용하는 gRPC 클라이언트는 채널 URI의 호스트 이름을 확인하기 위해 DNS 조회를 수행하지 않습니다. 대신 이러한 클라이언트는 Cloud Service Mesh에 LDS 요청을 전송하여 대상 URI의 hostname[:port]을 확인합니다.
  - 부하 분산 스키마 INTERNAL_SELF_MANAGED가 있는 전달 규칙의 포트만 대상 URI(예: xds:///example.hostname:8080)의 포트와 비교됩니다. 전달 규칙의 IP 주소는 사용되지 않습니다. 대상 URI에 포트가 지정되지 않은 경우 포트의 기본값은 80입니다.
  - 요청과 일치하는 전달 규칙은 URL 맵을 참조하는 대상 gRPC 프록시를 참조합니다. 이 URL 맵에는 라우팅 및 작업에 사용되는 정보가 포함됩니다.
  - 요청과 일치하는 전달 규칙이 두 개 이상이면 대상 URI의 hostname[:port]와 일치하는 호스트 규칙이 포함된 URL 맵이 라우팅 및 작업에 사용됩니다.
적절한 URL 맵이 결정되면 URL 맵을 평가하여 대상 백엔드 서비스를 결정하고 원하는 경우 작업을 적용합니다.
대상 백엔드 서비스를 선택한 후 백엔드 서비스 리소스의 구성에 따라 이 대상 백엔드 서비스의 백엔드 또는 엔드포인트 간에 트래픽이 분산됩니다.

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

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

Cloud Service Mesh는 간소화된 라우팅 스키마와 고급 스키마를 지원합니다. 단순 스키마에서 호스트 및 경로(선택사항)를 지정합니다. 요청의 호스트 및 경로를 평가하여 요청을 라우팅해야 할 서비스를 결정합니다.

요청 호스트는 URL의 도메인 이름 부분입니다. 예를 들어 URL http://example.com/video/의 호스트 부분은 example.com입니다.
요청의 경로는 호스트 이름을 따르는 URL의 부분입니다. 예를 들어 URL http://example.com/video/의 경로 부분은 /video입니다.

다음으로 구성된 라우팅 규칙 맵의 호스트와 경로를 기반으로 단순 라우팅을 설정합니다.

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

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

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

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

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

고급 라우팅 및 작업

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

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

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

고급 라우팅

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

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

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

추가 일치 조건과 headerMatches 및 queryParameterMatches에 대한 자세한 내용은 urlMaps REST API 페이지를 참조하세요.

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

HTTP 기반 애플리케이션 gRPC 기반 애플리케이션

	HTTP 기반 애플리케이션	gRPC 기반 애플리케이션
HTTP 호스트와 gRPC 호스트 비교	호스트는 애플리케이션이 호출하는 URL의 도메인 이름 부분입니다. 예를 들어 URL `http://example.com/video/`의 호스트 부분은 `example.com`입니다.	호스트는 클라이언트가 채널 URI에서 특정 서비스에 연결하는 데 사용하는 이름입니다. 예를 들어 채널 URI `xds:///example.com`의 호스트 부분은 `example.com`입니다.
HTTP 경로와 gRPC 경로 비교	경로는 호스트 이름 다음에 오는 URL 부분입니다. 예를 들어 URL `http://example.com/video`에서 경로 부분은 `/video`입니다.	경로는 HTTP/2 요청의 `:path` 헤더에 있으며 `/SERVICE_NAME/METHOD_NAME`과 같습니다. 예를 들어 `Example` gRPC 서비스에서 `Download` 메서드를 호출하면 `:path` 헤더의 콘텐츠가 `/Example/Download`와 같이 표시됩니다.
기타 gRPC 헤더(메타데이터)		gRPC는 gRPC 클라이언트와 gRPC 서버 간의 메타데이터 전송을 지원하여 RPC 호출에 대한 추가 정보를 제공합니다. 이 메타데이터는 HTTP/2 요청에서 헤더로 전달되는 키-값 쌍의 형식을 따릅니다.

HTTP 호스트와 gRPC 호스트 비교

호스트는 애플리케이션이 호출하는 URL의 도메인 이름 부분입니다.

예를 들어 URL http://example.com/video/의 호스트 부분은 example.com입니다.

호스트는 클라이언트가 채널 URI에서 특정 서비스에 연결하는 데 사용하는 이름입니다.

예를 들어 채널 URI xds:///example.com의 호스트 부분은 example.com입니다.

HTTP 경로와 gRPC 경로 비교

경로는 호스트 이름 다음에 오는 URL 부분입니다.

예를 들어 URL http://example.com/video에서 경로 부분은 /video입니다.

경로는 HTTP/2 요청의 :path 헤더에 있으며 /SERVICE_NAME/METHOD_NAME과 같습니다.

예를 들어 Example gRPC 서비스에서 Download 메서드를 호출하면 :path 헤더의 콘텐츠가 /Example/Download와 같이 표시됩니다.

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

작업

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

작업	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 요청을 적용하는 데 필요한 설정을 처리합니다.

작업과 그 작동 방식에 대한 자세한 내용은 urlMaps REST 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 가상 머신(VM) 인스턴스일 수 있습니다.

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

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

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

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

다양한 트래픽 분산 옵션과 그 작동 방식에 대한 자세한 내용은 backendServices REST API 페이지를 참조하세요.

사용 사례

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

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

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

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

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

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

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

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

Cloud Service Mesh 가중치 기반 트래픽 분할(확대하려면 클릭)

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

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

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

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

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

다음 단계

URL 맵에 대한 자세한 내용은 URL 맵 개요 및 URL 맵 사용을 참조하세요.
메시 외부에서 메시 내로 트래픽을 전달하려면 메시의 인그레스 트래픽을 참조하세요.
사이드카 프록시 배포로 기능을 설정하려면 Envoy를 사용한 고급 트래픽 관리 구성을 참조하세요.
프록시리스 gRPC 배포로 기능을 설정하려면 프록시리스 gRPC 서비스로 고급 트래픽 관리 구성을 참조하세요.