고급 트래픽 관리 개요
이 문서는 Cloud Service Mesh 및 서비스 메시 개념에 관해 중급 및 고급 수준의 지식을 갖추고 Cloud Service Mesh 배포에서 트래픽을 관리하는 방법을 결정 및 구성하는 메시 또는 플랫폼 관리자와 서비스 개발자를 대상으로 합니다.
Cloud Service Mesh는 트래픽 처리 방법을 세부적으로 제어할 수 있는 고급 트래픽 관리 기능을 제공합니다. Cloud Service Mesh에서는 다음 사용 사례가 지원됩니다.
- 하나 이상의 서비스에 대한 요청의 세분화된 트래픽 라우팅
- 가중치 기반 트래픽 분할로 여러 서비스에 트래픽 분산
- 하나의 디버깅 서비스에 요청을 보내고 다른 서비스로 사본을 전송되는 트래픽 미러링 정책 트래픽 미러링은
TCPRoute또는TLSRoute리소스에서 지원되지 않습니다. - 부하 분산 향상을 위해 서비스의 백엔드 간에 세분화된 트래픽 분산
이러한 고급 트래픽 관리 기능을 사용하면 가용성 및 성능 목표를 충족할 수 있습니다. 이러한 사용 사례에 Cloud Service Mesh를 사용할 때의 이점 중 하나는 애플리케이션 코드를 수정할 필요 없이 트래픽 관리 방법을 업데이트할 수 있다는 점입니다.
Cloud Service Mesh 서비스 메시의 트래픽 관리에는 다음 리소스가 사용됩니다.
Mesh리소스는 서비스 메시를 식별하고 트래픽 전달 및 정책 적용을 담당하는 구성요소를 나타냅니다.Mesh리소스는 또한 트래픽 가로채기 포트를 식별합니다.Gateway리소스는 중간 프록시를 식별하며 IP 주소:포트 쌍 목록에서 리슨하고, 트래픽을 전달하고, 정책을 적용하는 구성요소를 나타냅니다.Route리소스는 여러 유형 중 하나일 수 있으며 메시에 대한 트래픽 라우팅 정보를 포함합니다.Route리소스는 클라이언트가 백엔드 서비스로 트래픽을 라우팅하는 데 사용할 수 있는 호스트 이름과 포트를 식별합니다. 다음은Route리소스의 여러 유형입니다.HTTPRoute는 Envoy 프록시를 사용하는 메시에서만 사용할 수 있습니다.HTTPRoute리소스를 사용하여 HTTP 요청을 전송하도록 Envoy 프록시를 구성할 때는 이 문서의 모든 기능을 사용할 수 있습니다.TCPRoute는 Envoy 프록시를 사용하는 메시에서만 사용할 수 있습니다.TLSRoute는 Envoy 프록시를 사용하는 메시에서만 사용할 수 있습니다.GRPCRoute는 Envoy 사이드카 프록시 및 프록시리스 gRPC를 사용하는 메시에서 사용할 수 있습니다. Cloud Service Mesh와 함께 프록시리스 gRPC 서비스 또는 애플리케이션을 사용하면 이 문서에 설명된 일부 기능을 사용할 수 없습니다.
- 백엔드 서비스는
Route리소스와 연결됩니다.
구성
고급 트래픽 관리를 구성하려면 Cloud Service Mesh를 설정할 때 사용하는 동일한 Route 및 백엔드 서비스 리소스를 사용합니다.
Cloud Service Mesh는 결과적으로 설정된 고급 트래픽 관리 정책을 적용하도록 Envoy 프록시와 프록시리스 gRPC 애플리케이션을 구성합니다.
개략적으로 다음을 수행합니다.
- 서비스 메시를 식별하도록
Mesh리소스를 구성합니다. 아웃바운드 요청의 특성에 다라 다음을 수행하도록
Route리소스를 구성합니다.요청이 라우팅될 백엔드 서비스를 선택합니다.
원하는 경우 추가 작업을 수행합니다.
대상 서비스가 선택된 후에 백엔드 및 엔드포인트에 트래픽이 분산되는 방식을 제어하도록 백엔드 서비스를 구성합니다.
트래픽 라우팅 및 작업
Cloud Service Mesh에서 트래픽은 Mesh 리소스, Route 리소스, 백엔드 서비스 리소스의 값에 따라 라우팅됩니다. 라우팅 및 작업과 관련된 모든 고급 트래픽 관리 기능은 Route 객체를 사용하여 구성됩니다.
다음 섹션에서는 Route 객체에서 설정할 수 있는 고급 트래픽 관리 기능에 대해 설명합니다.
요청 처리
클라이언트가 요청을 전송하면 요청은 다음 단계에 설명된 대로 처리됩니다.
요청은 다음과 같이 특정
Route리소스와 비교됩니다.- Envoy를 사용하는 경우:
- 각
HTTPRoute또는GRPCRoute리소스의hostnames필드에 따라 HTTP 요청의 호스트 헤더를 비교해서 요청에 올바른Route리소스를 선택합니다.HTTPRoute및GRPCRoute리소스에만hostnames필드가 포함됩니다. - IP 주소를 비교해서
TCPPRoute를 사용하여 TCP 트래픽을 라우팅합니다. - SNI 및 ALPN은
TLSRoute를 사용하는 TLS 패스 스루에 사용됩니다. HTTPRoute및GRPCRoute리소스는Mesh와 연결됩니다. 또는Gateway에 고유한 호스트 이름이 있어야 합니다. 호스트 이름이 충돌하는 여러 경로를 연결하려고 시도하면 구성이 거부됩니다.- 마찬가지로
TCPRoute의IP:Port필드가 고유해야 합니다. 그렇지 않으면 구성이 거부됩니다. - 마찬가지로 SNI 및 ALPN이
TLSRoute에 대해 고유해야 합니다. a.example.com및*.example.com과 같은 겹치는 호스트 이름이 있으면 요청이 경로를 보다 세부적으로 비교합니다.
- 각
- 프록시리스 gRPC를 사용하는 경우:
- 프록시리스 gRPC 클라이언트는
xds이름 변환 스키마를 사용합니다. Cloud Service Mesh에 요청을 전송하여 대상 URI에서hostname[:port]를 확인합니다. GRPCRoute응답의 포트만 대상 URI의 포트(예:xds:///example.hostname:8080)와 비교됩니다. 대상 URI는GRPCRoute의hostnames필드에 있는 문자열과 정확하게 일치해야 합니다.
- 프록시리스 gRPC 클라이언트는
- Envoy를 사용하는 경우:
Route리소스에는 추가 라우팅 정보 및 규칙이 포함될 수 있습니다.대상 백엔드 서비스를 선택한 후 백엔드 서비스 리소스의 구성에 따라 이 대상 백엔드 서비스의 백엔드 또는 엔드포인트 간에 트래픽이 분산됩니다.
두 번째 단계는 다음 호스트 및 경로에 기반한 단순 라우팅 섹션에서 설명합니다. 세 번째 단계는 고급 라우팅 및 작업에서 설명합니다.
호스트 및 경로에 기반한 단순 라우팅
Cloud Service Mesh는 간소화된 라우팅 스키마와 고급 스키마를 지원합니다. 단순 스키마에서 호스트 및 경로(선택사항)를 지정합니다. 요청의 호스트 및 경로를 평가하여 해당 요청이 라우팅된 백엔드 서비스를 결정합니다.
- 요청 호스트는 URL의 도메인 이름 부분입니다. 예를 들어 URL
http://example.com/video/의 호스트 부분은example.com입니다. - 요청의 경로는 호스트 이름을 따르는 URL의 부분입니다. 예를 들어 URL
http://example.com/video/의 경로 부분은/video입니다.
다음으로 구성된 라우팅 규칙 맵의 호스트와 경로를 기반으로 단순 라우팅을 설정합니다.
- 전역
Mesh HTTPRoute또는GRPCRoute
대부분의 구성은 HTTPRoute에서 수행됩니다. 초기 라우팅 규칙 맵을 만든 후에는 HTTPRoute 리소스만 수정하면 됩니다.
가장 간단한 규칙은 기본 서비스를 사용하여 와일드 카드(*) 호스트 규칙 및 경로 일치자만 지정하는 기본 규칙입니다. 기본 규칙을 만든 후 다른 호스트 및 경로를 지정하는 규칙을 추가할 수 있습니다. 아웃바운드 요청은 이러한 규칙에 따라 다음과 같이 평가됩니다.
요청의 호스트(예:
example.com)가HTTPRoute의 호스트 이름과 일치하는 경우:RouteRule이 그 다음으로 평가됩니다.RouteRule은 트래픽을 비교하고 트래픽이 일치할 때 트래픽을 라우팅하는 방법을 지정합니다.- 각
RouteRule컨테이너에는 요청 경로에 따라 평가되는 하나 이상의 경로 비교가 포함됩니다. - 일치 항목이 발견되면
RouteAction에 지정된 서비스로 요청이 라우팅됩니다.
HTTPRoute의 리소스 필드 및 작동 방법은 네트워크 서비스 API 참고 리소스를 참조하세요.
고급 라우팅 및 작업
요청의 호스트 및 경로를 기반으로 요청을 라우팅하는 것보다 더 많은 작업을 수행하려면 고급 규칙을 설정하여 요청을 라우팅하고 작업을 수행할 수 있습니다.
개략적으로 고급 라우팅 및 작업은 다음과 같이 작동합니다.
- 단순 라우팅과 마찬가지로 요청의 호스트는
HTTPRoute또는GRPCRoute에서 구성하는 호스트 규칙과 비교됩니다. 요청의 호스트가 호스트 이름과 일치하면HTTPRoute또는GRPCRoute가 평가됩니다. - 경로를 선택한 후 작업을 적용할 수 있습니다.
고급 라우팅
고급 라우팅은 위에서 설명한 단순 라우팅과 비슷하지만 추가적인 일치 조건을 지정할 수 있습니다. 예를 들어 헤더 이름이 프리픽스 또는 서픽스 등을 기준으로 정확하게 일치하거나 일부만 일치하는 경우 규칙이 요청의 헤더와 일치하도록 지정할 수 있습니다. 헤더 이름을 정규 표현식과 비교하여 평가하거나 헤더 유무를 확인하는 다른 기준에 따라 규칙을 일치시킬 수 있습니다.
추가 일치 조건과 headerMatches 및 queryParameterMatches에 대한 자세한 내용은 network services REST API 페이지를 참조하세요.
호스트, 경로, 헤더, 쿼리 매개변수를 일치 조건과 결합하면 정확한 트래픽 관리 요건에 맞는 매우 정교한 규칙을 만들 수 있습니다. 자세한 내용은 다음 표를 참고하세요.
| HTTP 기반 애플리케이션 | gRPC 기반 애플리케이션 | |
|---|---|---|
| HTTP 호스트와 gRPC 호스트 비교 | 호스트는 애플리케이션이 호출하는 URL의 도메인 이름 부분입니다. 예를 들어 URL |
호스트는 클라이언트가 채널 URI에서 특정 서비스에 연결하는 데 사용하는 이름입니다. 예를 들어 채널 URI |
| HTTP 경로와 gRPC 경로 비교 | 경로는 호스트 이름 다음에 오는 URL 부분입니다. 예를 들어 URL |
경로는 HTTP/2 요청의 예를 들어 |
| 기타 gRPC 헤더(메타데이터) | gRPC는 gRPC 클라이언트와 gRPC 서버 간의 메타데이터 전송을 지원하여 RPC 호출에 대한 추가 정보를 제공합니다. 이 메타데이터는 HTTP/2 요청에서 헤더로 전달되는 키-값 쌍의 형식을 따릅니다. |
작업
Cloud Service Mesh를 사용하면 요청을 처리할 때 Envoy 프록시 또는 프록시리스 gRPC 애플리케이션이 수행하는 작업을 지정할 수 있습니다. Cloud Service Mesh를 사용하여 다음 작업을 구성할 수 있습니다.
| 작업 | API 필드 이름 | 설명 |
|---|---|---|
| 리디렉션 | redirect |
구성 가능한 3xx 응답 코드를 반환합니다. 또한 적절한 URI로 Location 응답 헤더를 설정하여 리디렉션 작업에 지정된 대로 호스트와 경로를 바꿉니다.
|
| URL 재작성 | urlRewrite |
선택한 백엔드 서비스에 요청을 전송하기 전에 URL의 호스트 이름 부분이나 URL의 경로 부분 또는 둘 다 재작성할 수 있습니다. |
| 헤더 변환 | requestHeaderModifier/responseHeaderModifier |
백엔드 서비스에 요청을 보내기 전에 요청 헤더를 추가하거나 제거합니다. 또한 백엔드 서비스에서 응답을 수신한 후 응답 헤더를 추가하거나 삭제할 수 있습니다. |
| 트래픽 미러링 | requestMirrorPolicy |
선택한 백엔드 서비스로 요청을 전달하는 것 외에 동일한 요청을 파이어 앤 포겟(fire-and-forget) 방식으로 구성된 미러링 백엔드 서비스에 전송합니다. 부하 분산기는 미러링된 요청을 보내는 백엔드의 응답을 기다리지 않습니다. 미러링은 백엔드 서비스의 새 버전을 테스트하는 데 유용합니다. 또한 미러링을 사용하면 프로덕션 버전이 아닌 백엔드 서비스의 디버그 버전에서 프로덕션 오류를 디버깅할 수 있습니다. |
| 가중치 기반 트래픽 분할 | weightDestination.serviceName |
일치하는 규칙의 트래픽을 개별 백엔드 서비스에 할당된 사용자 정의 가중치에 맞게 여러 백엔드 서비스에 배포할 수 있습니다. 이 기능은 스테이징 배포 또는 A/B 테스팅을 구성하는 데 유용합니다. 예를 들어 트래픽 중 99%는 안정적인 애플리케이션 버전이 실행되는 서비스에 전송하고 나머지 1%는 해당 애플리케이션이 최신 버전이 실행되는 별도의 서비스에 전송하도록 라우팅 작업을 구성할 수 있습니다. |
| 재시도 | retryPolicy |
부하 분산기가 실패한 요청을 재시도하는 조건, 재시도 전 부하 분산기가 대기하는 시간, 최대 재시도 허용 횟수를 구성합니다. |
| 제한 시간 | timeout |
선택한 경로의 제한 시간을 지정합니다. 제한 시간은 요청이 완전히 처리된 시간부터 응답이 완전히 처리될 때까지 계산됩니다. 제한 시간에는 모든 재시도 횟수가 포함됩니다. |
| 결함 주입 | faultInjectionPolicy |
높은 지연 시간, 서비스 과부하, 서비스 장애, 네트워크 파티션 나누기 등의 장애를 시뮬레이션하는 요청을 제공할 때 의도적으로 오류를 발생시킬 수 있습니다. 이 기능은 장애를 시뮬레이션하면서 서비스의 복원력을 테스트하는 데 유용합니다. |
| 보안 정책 | corsPolicy |
교차 출처 리소스 공유(CORS) 정책은 CORS 요청을 적용하는 데 필요한 설정을 처리합니다. |
작업 및 작동 방식에 대한 자세한 내용은 네트워크 서비스 API 페이지를 참조하세요.
각 라우팅 규칙에서 다음 경로 작업 중 하나를 지정할 수 있습니다.
- 트래픽을 단일 서비스로 라우팅(
destination.serviceName) - 여러 서비스 간 트래픽 분할(
destination.weight) - 리디렉션 URL(
redirect)
또한 앞에서 언급한 라우팅 작업 중 하나를 다음 라우팅 작업(Google Cloud 콘솔에서 부가 작업이라고 함) 중 하나 이상과 결합할 수 있습니다.
- 요청 또는 응답 헤더 조작(
requestHeaderModifier/responseHeaderModifier) - 트래픽 미러링(
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) 트래픽을 다시 수신하기에 충분할 정도로 정상으로 간주되는 경우 백엔드 또는 엔드포인트를 다시 추가할 기준을 지정합니다. 서비스와 관련된 상태 점검에서 백엔드 또는 엔드포인트가 정상으로 간주되는지 결정합니다. |
다양한 트래픽 분산 옵션과 작동 방법에 대한 자세한 내용은 다음 문서를 참조하세요.
사용 사례
고급 트래픽 관리는 많은 사용 사례를 해결합니다. 이 섹션에서는 몇 가지 개략적인 예시를 설명합니다.
샘플 코드를 포함한 더 많은 예시는 Envoy로 고급 트래픽 관리 구성 및 프록시리스 gRPC 서비스로 고급 트래픽 관리 구성에서 찾을 수 있습니다.
맞춤설정을 위한 세분화된 트래픽 라우팅
요청 매개변수에 따라 서비스로 트래픽을 라우팅할 수 있습니다. 예를 들어 이 기능을 사용하여 Android 사용자에게 보다 맞춤화된 환경을 제공할 수 있습니다. 다음 다이어그램에서 Cloud Service Mesh는 일반 서비스 대신 Android 서비스로 user-agent:Android 헤더가 포함된 요청을 보내도록 서비스 메시를 구성합니다.
Android에 설정된 user-agent 헤더 기반 라우팅(확대하려면 클릭)더 안전한 배포를 위한 가중치 기반 트래픽 분할
기존 프로덕션 서비스의 새 버전을 배포하는 것은 위험할 수 있습니다. 테스트가 테스트 환경으로 전달된 후에도 모든 사용자가 바로 새 버전으로 라우팅하는 것을 원하지 않을 것입니다.
Cloud Service Mesh를 사용하면 여러 서비스에 트래픽을 분산할 수 있도록 가중치 기반 트래픽 분할을 정의할 수 있습니다. 예를 들어 트래픽의 1%를 새 버전의 서비스로 전송하고 모든 것이 작동하는지 모니터링한 다음 새 서비스로 이동하는 트래픽의 비율을 점차적으로 확대할 수 있습니다.
디버깅을 위한 트래픽 미러링
문제를 디버깅할 때 프로덕션 트래픽의 복사본을 디버깅 서비스로 보내는 것이 유용할 수 있습니다. Cloud Service Mesh를 사용하면 요청을 한 서비스에 전송하고 해당 요청의 사본을 다른 서비스에 전송하도록 요청 미러링 정책을 설정할 수 있습니다.
성능 향상을 위한 세분화된 부하 분산
애플리케이션 특성에 따라 서비스의 백엔드에 트래픽이 분산되는 방식을 세부 조정하면 성능 및 가용성을 개선할 수 있습니다. Cloud Service Mesh를 사용하면 필요에 따라 트래픽이 분산되도록 고급 부하 분산 알고리즘을 적용할 수 있습니다.
다음 다이어그램은 이전 다이어그램과 비교하여 대상 백엔드 서비스(프로덕션 서비스)와 이 백엔드 서비스의 백엔드(가상 머신 1, 가상 머신 2, 가상 머신 3)를 모두 보여줍니다. 고급 트래픽 관리를 사용하면 대상 백엔드 서비스를 선택하는 방식과 대상 서비스의 백엔드 간에 트래픽을 분산하는 방식을 모두 구성할 수 있습니다.
Cloud Service Mesh를 사용하는 부하 분산에 대한 자세한 내용은 고급 부하 분산 개요를 참조하세요.
다음 단계
- 메시 외부에서 메시 내로 트래픽을 전달하려면 메시의 인그레스 트래픽을 참조하세요.