이 문서에서는 특정 사용 사례에 트래픽 관리를 사용하는 예시를 다룹니다. 다른 많은 사용 사례가 있을 수 있습니다.
이 문서에는 전역 외부 애플리케이션 부하 분산기의 예시가 포함되어 있습니다.
전역 외부 애플리케이션 부하 분산기는 EXTERNAL_MANAGED 부하 분산 스키마와 전역 부하 분산 구성요소(예: 전달 규칙, URL 맵, 백엔드 서비스)를 사용합니다.
기본 애플리케이션 부하 분산기의 트래픽 관리에 대한 자세한 내용은 기본 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.
리전 외부 애플리케이션 부하 분산기의 트래픽 관리에 대한 자세한 내용은 리전 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.
이 페이지에서 설명하는 고급 라우팅 기능 외에도 특정 애플리케이션 부하 분산기는 서비스 확장 프로그램과 통합되어 서비스 확장 프로그램 콜아웃을 구성함으로써 부하 분산 데이터 경로에 커스텀 로직을 삽입할 수 있습니다.
시작하기 전에
트래픽 관리의 작동 방식을 이해해야 합니다. 자세한 내용은 전역 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.
트래픽 관리 구성 및 테스트
선택한 구성 환경 내에서 YAML 구성을 사용하여 트래픽 관리를 설정합니다. URL 맵과 백엔드 서비스 각각에 자체 YAML 파일이 있습니다. 원하는 기능에 따라 URL 맵 YAML 파일, 백엔드 서비스 YAML 파일 또는 두 파일을 모두 작성해야 합니다.
이러한 YAML 파일을 작성하는 데 도움이 필요한 경우 이 페이지의 예시와 Cloud Load Balancing API 문서를 사용하면 됩니다.
Google Cloud 콘솔은 지원되지 않습니다.
전역 URL 맵 API 및 전역 백엔드 서비스 API 문서는 관계, 제한사항, 카디널리티와 관련된 시맨틱스를 포함한 전체 필드 목록을 제공합니다
URL 맵에 구성 테스트를 추가하여 URL 맵에서 요청을 의도한 대로 라우팅하도록 할 수 있습니다. 다양한 URL 맵 규칙으로 실험하고 맵에서 트래픽을 적절한 백엔드 서비스나 백엔드 버킷으로 라우팅하는지 확인하기 위해 필요한 만큼 테스트를 실행할 수 있습니다. 자세한 내용은 URL 맵에 테스트 추가를 참조하세요. 실제로 맵을 배포하지 않고 URL 맵의 새 변경사항을 테스트하려면 URL 맵 구성 유효성 검사를 참조하세요.
트래픽을 단일 서비스에 매핑
모든 트래픽을 단일 서비스에 전송합니다. 자리표시자를 바꿔야 합니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
두 서비스 간 트래픽 분할
둘 또는 여러 서비스 간에 트래픽을 분할합니다. 자리표시자를 바꿔야 합니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: global/backendServices/BACKEND_SERVICE_2
weight: 5
URL 리디렉션 구성
다음 예시에서는 구성 가능한 3xx 응답 코드를 반환합니다. 이 예시는 또한 적절한 URI로 Location 응답 헤더를 설정하여 리디렉션 작업에 지정된 대로 호스트와 경로를 바꿉니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
urlRedirect:
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
redirectResponseCode: FOUND
stripQuery: True
트래픽 미러링
선택한 백엔드 서비스로 요청을 전달하는 것 외에 동일한 요청을 파이어 앤 포겟(fire-and-forget) 방식으로 구성된 미러링 백엔드 서비스에 전송합니다. 부하 분산기는 미러링된 요청을 보내는 백엔드의 응답을 기다리지 않습니다. 미러링은 백엔드 서비스의 새 버전을 테스트하는 데 유용합니다. 또한 미러링을 사용하면 프로덕션 버전이 아닌 백엔드 서비스의 디버그 버전에서 프로덕션 오류를 디버깅할 수 있습니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: global/backendServices/BACKEND_SERVICE_2
트래픽 미러링은 다음과 같은 경우에만 지원됩니다.
- 두 백엔드 서비스 모두 인스턴스 그룹 백엔드가 있습니다. 다른 백엔드 유형은 지원되지 않습니다.
- HTTP 요청에 본문이 없습니다.
요청의 특정 부분에만 미러링을 구성할 수 없습니다. 가중치가 적용된 여러 백엔드 서비스 간에 트래픽을 분할하는 경우에도 미러링 백엔드 서비스는 모든 요청을 수신합니다. 그러나 커스텀 헤더를 사용하여 원래 요청을 처리하는 데 사용된 백엔드 서비스를 기록할 수 있습니다. 다음 예시에서는 x-weighted-picked-backend라는 커스텀 헤더를 모든 클라이언트 요청에 추가합니다. 헤더 값에는 원래 요청을 제공한 백엔드 서비스의 이름을 사용합니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 95
headerAction:
requestHeadersToAdd:
- headerName: x-weighted-picked-backend
headerValue: BACKEND_SERVICE_1
replace: True
- backendService: global/backendServices/BACKEND_SERVICE_2
weight: 5
headerAction:
requestHeadersToAdd:
- headerName: x-weighted-picked-backend
headerValue: BACKEND_SERVICE_2
replace: True
requestMirrorPolicy:
backendService: global/backendServices/BACKEND_SERVICE_3
요청된 URL 재작성
선택한 백엔드 서비스에 요청을 전송하기 전에 URL의 호스트 이름 부분이나 URL의 경로 부분 또는 둘 다 재작성할 수 있습니다. 자리표시자를 바꿔야 합니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
urlRewrite:
hostRewrite: "new-host-name.com" # Omit to keep the requested host
pathPrefixRewrite: "/new-path/" # Omit to keep the requested path
요청 재시도
부하 분산기가 실패한 요청을 재시도하는 조건, 재시도 전 부하 분산기가 대기하는 시간, 최대 재시도 허용 횟수를 구성합니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
경로 제한 시간 지정
선택한 경로의 제한 시간을 지정합니다. 제한 시간은 요청이 완전히 처리된 시간부터 응답이 완전히 처리될 때까지 계산됩니다. 제한 시간에는 모든 재시도 횟수가 포함됩니다. 자리표시자를 바꿔야 합니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
timeout:
seconds: 30
nanos: 0
결함 주입 구성
높은 지연 시간, 서비스 과부하, 서비스 장애, 네트워크 파티션 나누기 등의 장애를 시뮬레이션하는 요청을 제공할 때 의도적으로 오류를 발생시킬 수 있습니다. 이 기능은 장애를 시뮬레이션하면서 서비스의 복원력을 테스트하는 데 유용합니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 0
percentage: 25
abort:
httpStatus: 503
percentage: 50
CORS 구성
교차 출처 리소스 공유(CORS) 요청을 적용하기 위한 설정을 처리하도록 CORS 정책을 구성합니다.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
weight: 100
corsPolicy:
allowOrigins: [ "http://my-domain.com" ]
allowMethods: [ "GET", "POST" ]
allowHeaders: [ "Authorization", "Content-Type" ]
maxAge: 1200
allowCredentials: true
요청 및 응답 헤더 추가 및 삭제
백엔드 서비스에 요청을 보내기 전에 요청 헤더를 추가하고 삭제합니다. 또한 백엔드 서비스에서 응답을 수신한 후 응답 헤더를 추가하거나 삭제합니다.
headerName 및 headerValue의 유효한 값에는 제한이 있습니다.
자세한 내용은 커스텀 헤더 작동 방식을 참조하세요.
defaultService: global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: global/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: global/backendServices/BACKEND_SERVICE_1
headerAction:
requestHeadersToAdd:
- headerName: header-1-name
headerValue: header-1-value
replace: True
requestHeadersToRemove:
- header-2-name
- header-3-name
responseHeadersToAdd:
- headerName: header-4-name
headerValue: header-4-value
replace: True
responseHeadersToRemove:
- header-5-name
- header-6-name
이상점 감지 구성
NEG에서 비정상 백엔드 VM 또는 엔드포인트를 제거하는 기준과 백엔드 또는 엔드포인트에서 트래픽을 다시 수신하기에 충분할 정도로 정상임을 판단하는 기준을 지정합니다. 자리표시자를 바꿔야 합니다.
loadBalancingScheme: EXTERNAL_MANAGED
localityLbPolicy: RANDOM
name: global/backendServices/BACKEND_SERVICE_1
outlierDetection:
baseEjectionTime:
nanos: 0
seconds: 30
consecutiveErrors: 5
consecutiveGatewayFailure: 3
enforcingConsecutiveErrors: 2
enforcingConsecutiveGatewayFailure: 100
enforcingSuccessRate: 100
interval:
nanos: 0
seconds: 1
maxEjectionPercent: 50
successRateMinimumHosts: 5
successRateRequestVolume: 100
successRateStdevFactor: 1900
트래픽 분할 설정: 세부 단계
이 예시에서는 다음 단계를 설명합니다.
서비스별로 고유한 템플릿을 만듭니다.
위에서 만든 템플릿에 대한 인스턴스 그룹을 만듭니다.
트래픽 분산을 95%/5%로 설정하는 라우팅 규칙을 만듭니다.
트래픽 분할 비율이 대략 구성과 일치함을 보여주는 curl 명령어를 전송합니다.
여기에서는 다음과 같이 설정되었다고 가정합니다.
대상 프록시 및 전달 규칙이 URL 맵(
global-lb-map)과 함께 생성되었습니다.URL 맵은 모든 트래픽을 기본 백엔드 서비스인
red-service라는 하나의 백엔드 서비스로 전송합니다.트래픽 중 5%를
blue-service로, 나머지 95%를green-service로 전송하는 대체 경로를 설정합니다경로 일치자가 사용됩니다.
Cloud Shell이나 bash가 설치된 다른 환경을 사용 중이어야 합니다.
서비스 정의
다음 bash 함수는 인스턴스 템플릿과 관리형 인스턴스 그룹을 포함하는 백엔드 서비스를 만듭니다.
이 안내에서는 HTTP 상태 점검(global-lb-basic-check)이 생성되었다고 가정합니다. 자세한 내용은 다음 페이지 중 하나를 참조하세요.
- Compute Engine 백엔드로 전역 외부 애플리케이션 부하 분산기 설정
- 백엔드 버킷으로 전역 외부 애플리케이션 부하 분산기 설정
- 하이브리드 연결로 전역 외부 애플리케이션 부하 분산기 설정
- Cloud Run, App Engine 또는 Cloud Functions로 전역 외부 애플리케이션 부하 분산기 설정
function make_service() {
local name="$1"
local region="$2"
local zone="$3"
local network="$4"
local subnet="$5"
local subdir="$6"
www_dir="/var/www/html/$subdir"
(set -x; \
gcloud compute instance-templates create "${name}-template" \
--region="$region" \
--network="$network" \
--subnet="$subnet" \
--tags=allow-ssh,load-balanced-backend \
--image-family=debian-10 \
--image-project=debian-cloud \
--metadata=startup-script="#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
sudo mkdir -p $www_dir
/bin/hostname | sudo tee ${www_dir}index.html
systemctl restart apache2"; \
gcloud compute instance-groups managed create \
"${name}-instance-group" \
--zone="$zone" \
--size=2 \
--template="${name}-template"; \
gcloud compute backend-services create "${name}-service" \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--health-checks=global-lb-basic-check \
--global \
gcloud compute backend-services add-backend "${name}-service" \
--balancing-mode='UTILIZATION' \
--instance-group="${name}-instance-group" \
--instance-group-zone="$zone" \
--global)
}
서비스 생성
red, green 및 blue의 세 가지 서비스를 만드는 함수를 호출합니다. red 서비스는 / 요청에 대해 기본 서비스 역할을 합니다. green 및 blue 서비스는 각각 트래픽의 95% 및 5%를 처리할 수 있도록 모두 /prefix에서 설정됩니다.
make_service red us-west1 us-west1-a lb-network backend-subnet "" make_service green us-west1 us-west1-a lb-network backend-subnet /prefix make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix
URL 맵 만들기
콘솔
- Google Cloud 콘솔의 부하 분산 페이지로 이동합니다.
부하 분산으로 이동 - global-lb-map 링크를 클릭합니다.
- 수정 을 클릭합니다.
새 라우팅 규칙 구성
- 라우팅 규칙에서 고급 호스트, 경로 및 경로 규칙을 선택합니다.
- 새 호스트 및 경로 일치자에서 서비스를
red-service로 설정하여 기본 작업을 만듭니다. - 완료를 클릭합니다.
- 호스트 및 경로 일치자 추가를 클릭합니다.
- 호스트 필드에 부하 분산기 전달 규칙의 IP 주소를 입력합니다.
다음 YAML 콘텐츠를 경로 일치자 상자에 붙여넣습니다.
defaultService: global/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: global/backendServices/green-service weight: 95 - backendService: global/backendServices/blue-service weight: 5완료를 클릭합니다.
업데이트를 클릭합니다.
gcloud
gcloud compute url-maps export명령어를 사용하여 기존 URL 맵을 내보냅니다.gcloud compute url-maps export global-lb-map \ --destination=global-lb-map-config.yaml \ --global
global-lb-map-config.yamlURL 맵 파일을 파일 끝에 추가하여 업데이트합니다.hostRules: - hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: global/backendServices/green-service weight: 95 - backendService: global/backendServices/blue-service weight: 5gcloud compute url-maps import명령어를 사용하여 URL 맵을 업데이트합니다.gcloud compute url-maps import global-lb-map \ --global \ --source=global-lb-map-config.yaml
구성 테스트
구성을 테스트하려면 먼저 앞에서 설정한 부하 분산기의 IP 주소에 대한 요청이 기본 red 구성에서 처리되는지 확인해야 합니다.
그런 다음 FORWARDING_RULE_IP_ADDRESS/prefix로 전송된 요청이 예상대로 분할되는지 확인합니다.
HTTP_COOKIE를 기준으로 세션 어피니티 설정
트래픽 제어를 사용하면 제공된 쿠키를 기준으로 세션 어피니티를 구성할 수 있습니다. red-service라는 백엔드 서비스에 HTTP_COOKIE 기반 세션 어피니티를 구성하려면 다음 지침을 따르세요.
gcloud compute backend_services export명령어를 사용하여 백엔드 서비스 구성을 가져옵니다.gcloud compute backend-services export red-service \ --destination=red-service-config.yaml \ --global다음과 같이
red-service-config.yaml파일을 업데이트합니다.sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 0 minimumRingSize: 10000red-service-config.yaml파일에서 다음 줄을 삭제합니다.sessionAffinity: NONE
백엔드 서비스 구성 파일을 업데이트합니다.
gcloud compute backend-services import red-service \ --source=red-service-config.yaml \ --global
문제 해결
구성된 라우팅 규칙 및 트래픽 정책에 따라 트래픽이 라우팅되지 않으면 이 정보를 사용하여 문제를 해결합니다.
로깅 및 모니터링에 대한 자세한 내용은 외부 HTTP(S) 로깅 및 모니터링을 참조하세요.
증상
- 문제가 되는 규칙보다 상위 규칙의 서비스로 전송되는 트래픽이 증가했습니다.
- 특정 라우팅 규칙에 대한 4xx 및 5xx HTTP 응답 횟수가 예기치 않게 증가했습니다.
해결책: 라우팅 규칙의 순서를 확인합니다. 라우팅 규칙은 지정된 순서대로 평가됩니다.
URL 맵 내 라우팅 규칙은 지정된 순서에 따라 평가됩니다. 이 방법은 경로 규칙이 가장 긴 프리픽스 일치 항목을 기준으로 평가되는 방식과 다릅니다. 경로 규칙의 경우 전역 외부 애플리케이션 부하 분산기는 단일 경로 규칙만 선택합니다. 하지만 라우팅 규칙을 사용하면 둘 이상이 적용될 수 있습니다.
라우팅 규칙을 정의하는 경우 원래는 후속 라우팅 규칙에 따라 라우팅되어야 하는 트래픽이 목록의 상단에 있는 규칙에 따라 의도치 않게 라우팅되지 않는지 확인해야 합니다. 잘못 전송된 트래픽을 수신하는 서비스는 요청을 거부하므로 라우팅 규칙의 서비스에 수신되는 트래픽 양이 줄어들거나 전혀 수신되지 않을 수 있습니다.