이 문서에서는 Traffic Director 배포를 위한 고급 트래픽 관리를 구성하는 방법에 대한 정보를 제공합니다.
고급 트래픽 관리를 구성하기 전
Traffic Director 및 필요한 모든 VM 호스트 또는 GKE 클러스터 구성을 포함하여 Traffic Director 설정의 안내를 따릅니다. 필요한 Google Cloud 리소스를 만듭니다.
- 대상 HTTP 프록시를 사용하면 이 문서에 설명된 모든 기능을 사용할 수 있습니다.
- 대상 gRPC 프록시를 사용하면 일부 기능을 사용할 수 있습니다.
- 대상 TCP 프록시를 사용하면 고급 트래픽 관리 기능을 사용할 수 없습니다.
자세한 내용은 Traffic Director 기능 및 고급 트래픽 관리를 참조하세요. 고급 트래픽 관리로 VM 기반 프록시리스 gRPC 서비스 설정에는 엔드 투 엔드 설정 가이드가 포함됩니다.
트래픽 분할 설정
여기에서는 다음과 같이 설정되었다고 가정합니다.
- Traffic Director 배포에는
review-url-map
이라는 URL 맵이 있습니다. - URL 맵은 모든 트래픽을 기본 백엔드 서비스로 사용되는
review1
이라는 하나의 백엔드 서비스로 보냅니다. - 트래픽의 5%를 새 버전의 서비스로 라우팅하려고 합니다. 이 서비스는 백엔드 서비스
review2
와 연결된 NEG의 백엔드 VM 또는 엔드포인트에서 실행됩니다. - 호스트 규칙도, 경로 일치자도 사용되지 않습니다.
트래픽 분할을 설정하려면 다음 단계를 따르세요.
Console
Cloud Console에서 Traffic Director 페이지로 이동합니다.
라우팅 규칙 맵 만들기를 클릭합니다.
라우팅 규칙 맵 이름을 입력합니다.
프로토콜 메뉴에서 HTTP를 선택합니다.
기존 전달 규칙을 선택합니다.
라우팅 규칙에서 고급 호스트, 경로 및 라우팅 규칙을 선택합니다.
경로 일치자에서 서비스 간 트래픽 분할을 선택합니다.
YAML 뷰 버튼을 클릭합니다.
경로 일치자 상자에 다음 설정을 추가합니다.
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
완료를 클릭합니다.
만들기를 클릭합니다.
gcloud
gcloud export
명령어를 사용하여 URL 맵 구성을 가져옵니다.gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
review-url-map-config.yaml
파일에 다음 섹션을 추가합니다.hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
URL 맵을 업데이트합니다.
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
새 버전에 만족하면 두 서비스의 가중치를 점차적으로 조정하고 최종적으로 모든 트래픽을 review2
에 전송할 수 있습니다.
회로 차단 설정
회로 차단을 통해 클라이언트 요청으로 인해 백엔드에 과부하가 발생하지 않도록 실패 임곗값을 설정할 수 있습니다. 요청이 설정한 한도에 도달하면 클라이언트가 새 연결 허용 또는 추가 요청 전송을 중지하여 백엔드를 복구할 시간을 줍니다.
따라서 회로 차단은 백엔드에 과부하를 발생시키지 않고 클라이언트에 오류를 반환하여 연쇄적 장애를 방지합니다. 이렇게 하면 일부 트래픽을 제공하면서도 자동 확장을 통해 용량을 늘려 트래픽 급증을 처리하는 것과 같은 과부하 상황 관리를 위한 시간을 확보할 수 있습니다.
다음 예시에서는 회로 차단기를 다음과 같이 설정합니다.
- 연결당 최대 요청 수: 100
- 최대 연결 수: 1,000
- 대기 중 최대 요청 수: 200
- 최대 요청 수: 1,000
- 최대 재시도 수: 3
회로 차단을 설정하려면 다음 단계를 따르세요.
Console
- Cloud Console에서 Traffic Director 페이지로 이동합니다.
- 업데이트할 백엔드 서비스의 이름을 클릭합니다.
- 수정을 클릭합니다.
- 고급 구성을 클릭합니다.
- 회로 차단기에서 사용 설정 체크박스를 선택합니다.
- 수정 을 클릭합니다.
- 연결당 최대 요청 수에
100
을 입력합니다. - 최대 연결 수에
1000
을 입력합니다. - 최대 대기 요청 수에
200
을 입력합니다. - 최대 요청 수에
1000
을 입력합니다. - 최대 재시도 수에
3
을 입력합니다. - 저장을 클릭합니다.
- 저장을 클릭합니다.
gcloud
gcloud export
명령어를 사용하여 백엔드 서비스 구성을 가져옵니다. 여기서 BACKEND_SERVICE_NAME은 백엔드 서비스의 이름입니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
BACKEND_SERVICE_NAME.yaml 파일을 다음과 같이 업데이트합니다.
affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group:https://www.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/zones/<var>ZONE</var>/instanceGroups/<var>INSTANCE_GROUP_NAME</var> maxUtilization: 0.8 circuitBreakers: maxConnections: 1000 maxPendingRequests: 200 maxRequests: 1000 maxRequestsPerConnection: 100 maxRetries: 3 connectionDraining: drainingTimeoutSec: 300 healthChecks: - https://www.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/global/healthChecks/<var>HEALTH_CHECK_NAME</var> loadBalancingScheme: INTERNAL_SELF_MANAGED localityLbPolicy: ROUND_ROBIN name: <var>BACKEND_SERVICE_NAME</var> port: 80 portName: http protocol: HTTP sessionAffinity: NONE timeoutSec: 30 ```
백엔드 서비스 구성 파일을 다음과 같이 업데이트합니다.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
다음 회로 차단기 예시는 장바구니 서비스에 백엔드로 인스턴스 그룹 1개가 있는 사용 사례입니다. 회로 차단기 설정은 다음에 대한 제한을 나타냅니다.
- 연결당 최대 동시 요청 수
- 최대 동시 연결 수
- 최대 대기 중 요청 수
- 최대 동시 요청 수
- 최대 동시 재시도 수
이 회로 차단 예시를 설정하려면 다음 단계를 따르세요.
Console
- Cloud Console에서 Traffic Director 페이지로 이동합니다.
- 업데이트할 백엔드 서비스의 이름을 클릭합니다.
- 수정을 클릭합니다.
- 고급 구성을 클릭합니다.
- 회로 차단기에서 사용 설정 체크박스를 선택합니다.
- 수정 을 클릭합니다.
- 연결당 최대 요청 수에
100
을 입력합니다. - 최대 연결 수에
1000
을 입력합니다. - 최대 대기 요청 수에
200
을 입력합니다. - 최대 요청 수에
20000
을 입력합니다. - 최대 재시도 수에
3
을 입력합니다. - 저장을 클릭합니다.
- 저장을 클릭합니다.
gcloud
gcloud export
명령어를 사용하여 백엔드 서비스 구성을 내보냅니다. 여기서 BACKEND_SERVICE_NAME은 백엔드 서비스의 이름입니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
HTTP_COOKIE
를 기준으로 세션 어피니티 설정
고급 트래픽 관리를 사용하면 제공된 쿠키를 기반으로 세션 어피니티를 구성할 수 있습니다. HTTP_COOKIE 기반 세션 어피니티를 구성하려면 다음 안내를 따르세요.
HTTP_COOKIE
를 사용하여 세션 어피니티를 설정하려면 다음 안내를 따르세요.
Console
Cloud Console에서 Traffic Director 페이지로 이동합니다.
업데이트할 백엔드 서비스의 이름을 클릭합니다.
수정
을 클릭합니다.고급 구성을 클릭합니다.
세션 어피니티에서 HTTP 쿠키를 선택합니다.
지역 부하 분산 정책에서 링 해시를 선택합니다.
HTTP 쿠키 이름 필드에
http_cookie
를 입력합니다.HTTP 쿠키 경로 필드에
/cookie_path
를 입력합니다.HTTP 쿠키 TTL 필드에
100
을 입력합니다.최소 링 크기 필드에
10000
을 입력합니다.저장을 클릭합니다.
gcloud
gcloud export
명령어를 사용하여 백엔드 서비스 구성을 내보냅니다. 여기서 BACKEND_SERVICE_NAME은 백엔드 서비스의 이름입니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
다음과 같이
YAML
파일을 업데이트합니다.sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 30 minimumRingSize: 10000
백엔드 서비스 구성 파일을 다음과 같이 가져옵니다.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
이상점 감지 설정
이상점 감지는 부하 분산 풀에서의 비정상 호스트 제거를 제어합니다. Traffic Director는 NEG에서 비정상 백엔드 VM 또는 엔드포인트를 제거하는 기준과 백엔드 또는 엔드포인트가 트래픽을 다시 수신할 수 있는 정상 상태의 기준을 정의하는 정책 집합을 사용하여 이를 수행합니다.
다음 예시에서 백엔드 서비스에는 백엔드로 인스턴스 그룹 1개가 있습니다. 이상점 감지를 설정하면 이상점 감지 분석이 1초마다 실행하도록 지정됩니다. 엔드포인트가 5번 연속으로 5xx
오류를 반환하면 처음 30초 동안 부하 분산 대상에서 제거됩니다. 동일한 엔드포인트의 실제 제거 시간은 '30초 x 제거 횟수'입니다.
이상점 감지는 백엔드 서비스 리소스에 설정됩니다.
Console
Cloud Console에서 Traffic Director 페이지로 이동합니다.
서비스 이름을 클릭합니다.
수정
을 클릭합니다.고급 구성을 클릭합니다.
이상점 감지 체크박스를 선택합니다.
수정
을 클릭합니다.연속 오류를
5
로 설정합니다.간격을
1000
밀리초로 설정합니다.기본 제거 시간을
30000
밀리초로 설정합니다.저장을 클릭합니다.
저장을 클릭합니다.
gcloud
gcloud export
명령어를 사용하여 백엔드 서비스 구성을 내보냅니다. 여기서 BACKEND_SERVICE_NAME은 백엔드 서비스의 이름입니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
다음과 같이
YAML
파일을 업데이트하고 your_service_name은 백엔드 서비스 이름으로 바꿉니다.name: your_service_name loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $[INSTANCE_GROUP_URL] healthChecks: - $[HEALTH_CHECK_URL] port: 80 portName: http protocol: HTTP outlierDetection: consecutiveErrors: 5, interval: seconds: 1, nanos: 0 baseEjectionTime: seconds: 30, nanos: 0 ````
백엔드 서비스 구성 파일을 다음과 같이 가져옵니다.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
지역 부하 분산 정책 설정
지역 부하 분산 정책을 사용하여 Traffic Director가 제공하는 지역별 가중치 및 우선순위에 따라 부하 분산 알고리즘을 선택합니다. 예를 들어 정상 엔드포인트 간에 가중치가 적용된 라운드 로빈을 수행하거나 일관된 해싱을 수행할 수 있습니다.
다음 예시에서 백엔드 서비스에는 백엔드로 인스턴스 그룹 1개가 있습니다. 지역 부하 분산 정책이 RING_HASH
로 설정됩니다.
Console
Cloud Console에서 Traffic Director 페이지로 이동합니다.
서비스 이름을 클릭합니다.
수정
을 클릭합니다.고급 구성을 클릭합니다.
트래픽 정책의 지역 부하 분산 정책 메뉴에서 링 해시를 선택합니다.
저장을 클릭합니다.
gcloud
gcloud export
명령어를 사용하여 백엔드 서비스 구성을 내보냅니다. 여기서 BACKEND_SERVICE_NAME은 백엔드 서비스의 이름입니다.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
BACKEND_SERVICE_NAME.yaml 파일을 다음과 같이 업데이트합니다.
name: shopping-cart-service loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $[INSTANCE_GROUP_URL] healthChecks: - $[HEALTH_CHECK_URL] port: 80 portName: http protocol: HTTP localityLbPolicy: RING_HASH ````
백엔드 서비스 구성 파일을 다음과 같이 가져옵니다.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
지역 부하 분산 정책의 작동 방식에 대한 자세한 내용은 backendService 리소스에 대한 문서를 참조하세요.
MetadataFilter
일치를 기반으로 구성 필터링 설정
MetadataFilters
는 전달 규칙과 HttpRouteRuleMatch
로 사용 설정됩니다.
이 기능을 사용하여 특정 제어 규칙 또는 라우팅 규칙을 제어하면 제어 영역이 노드 메타데이터가 metadatafilter 설정과 일치하는 프록시에만 전달 규칙 또는 라우팅 규칙을 전송합니다. MetadataFilters
를 지정하지 않는 경우 규칙이 모든 Envoy 프록시로 전송됩니다.
이 기능을 사용하면 단계적 구성 배포를 쉽게 수행할 수 있습니다.
예를 들어 forwarding-rule1
이라는 전달 규칙을 만들면 노드 메타데이터에 'app: review'및 'version: canary'가 포함된 Envoy에만 푸시됩니다.
아래 단계에 따라 MetadataFilters
를 전달 규칙에 추가합니다.
전달 규칙에 MetadataFilter
를 추가하려면 다음 단계를 따르세요.
gcloud
gcloud export
명령어를 사용하여 전달 규칙 구성을 가져옵니다.gcloud compute forwarding-rules export forwarding-rule1 \ --destination=forwarding-rule1-config.yaml --global
forwarding-rule1-config.yaml
파일을 업데이트합니다.metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'canary'
gcloud import
명령어를 사용하여forwarding-rule1-config.yaml
파일을 업데이트합니다.gcloud compute forwarding-rules import forwarding-rule1 \ --source=forwarding-rule1-config.yaml --global
다음 안내를 사용하여 Envoy를 시작하기 전에 Envoy에 노드 메타데이터를 추가합니다. 문자열 값만 지원됩니다.
a. VM 기반 배포의 경우 bootstrap_template.yaml에서 메타데이터 섹션에 다음을 추가합니다.
app: 'review' version: 'canary'
b. Google Kubernetes Engine 기반 또는 Kubernetes 기반 배포의 경우 trafficdirector_istio_sidecar.yaml의 env 섹션에 다음을 추가합니다.
- name: ISTIO_META_app value: 'review' - name: ISTIO_META_version value: 'canary'
메타데이터 필터링을 사용하는 예시
여러 프로젝트가 동일한 공유 VPC 네트워크에 있고 각 서비스 프로젝트의 Traffic Director 리소스가 동일한 프로젝트의 프록시에 표시되도록 하려면 다음 안내를 따르세요.
공유 VPC 설정은 다음과 같습니다.
- 호스트 프로젝트 이름:
vpc-host-project
- 서비스 프로젝트:
project1
,project2
project1
및project2
에서 xDS 호환 프록시를 실행하는 백엔드 인스턴스 또는 엔드포인트가 있는 백엔드 서비스
project1
을 격리하도록 Traffic Director를 구성하려면 다음 안내를 따르세요.
gcloud
다음 메타데이터 필터를 사용하여
project1
에 모든 전달 규칙을 만듭니다.metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels - name: 'project_name' value: `project1 - name: 'version' value: 'production'
project1
의 인스턴스 또는 엔드포인트에 배포된 프록시를 구성할 때 부트스트랩 파일의 노드 메타데이터 섹션에 다음 메타데이터를 포함합니다.project_name: 'project1' version: 'production'
project2
에 이미 배포된 프록시가 첫 번째 단계에서 생성된 전달 규칙을 수신하지 않았는지 확인합니다. 이렇게 하려면project2
에서 프록시를 실행하는 시스템에서project1
의 서비스에 액세스해 보세요. Traffic Director 구성이 올바르게 작동하는지 확인하는 방법에 대한 자세한 내용은 구성 확인을 참조하세요.
모든 프록시에서 사용할 수 있도록 설정하기 전에 프록시 하위 집합에서 새 구성을 테스트하려면 다음 단계를 따르세요.
gcloud
다음 노드 메타데이터로 테스트에 사용하는 프록시를 시작합니다. 테스트에 사용하지 않는 프록시에는 이 노드 메타데이터를 포함하지 마세요.
version: 'test'
테스트할 새 전달 규칙마다 다음 메타데이터 필터를 포함합니다.
metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'version' value: 'test'
테스트 프록시로 트래픽을 전송하여 새 구성을 테스트하고 필요한 경우 변경합니다. 새 구성이 올바르게 작동하면 테스트하는 프록시만 새 구성을 수신합니다. 나머지 프록시는 새 구성을 수신하지 않으며 이를 사용할 수 없습니다.
새 구성이 제대로 작동하는지 확인한 후 연결된 메타데이터 필터를 삭제합니다. 이렇게 하면 모든 프록시가 새 구성을 수신할 수 있습니다.
문제 해결
구성된 라우팅 규칙 및 트래픽 정책에 따라 트래픽이 라우팅되지 않으면 이 정보를 사용하여 문제를 해결합니다.
증상
- 문제가 되는 규칙보다 상위 규칙의 서비스로 전송되는 트래픽이 증가했습니다.
- 특정 라우팅 규칙에 대한 4xx 및 5xx HTTP 응답 횟수가 예기치 않게 증가했습니다.
해결 방법: 라우팅 규칙이 우선순위에 따라 해석되므로 각 규칙에 할당된 우선순위를 검토합니다.
라우팅 규칙을 정의할 때 우선순위가 높은(즉, 우선순위 번호가 낮은) 규칙이 후속 라우팅 규칙에 의해 라우팅된 트래픽을 의도하지 않게 라우팅하지 않는지 확인합니다. 다음 예시를 참조하세요.
첫 번째 라우팅 규칙
- 라우팅 규칙 일치 pathPrefix = '/shopping/'
- 리디렉션 작업:
service-1
백엔드 서비스로 트래픽 전송 - 규칙 우선순위: 4
두 번째 라우팅 규칙
- 라우팅 규칙 일치 regexMatch = '/shopping/cart/ordering/.*'
- 리디렉션 작업:
service-2
백엔드 서비스로 트래픽 전송 - 규칙 우선순위: 8
이 경우 '/shopping/cart/ordering/cart.html' 경로가 포함된 요청은 service-1
로 라우팅됩니다. 두 번째 규칙이 일치하더라도 첫 번째 규칙에 우선순위가 있으므로 무시됩니다.