이 문서에서는 특정 사용 사례에 트래픽 관리를 사용하는 예시를 다룹니다. 다른 많은 사용 사례가 있을 수 있습니다.
이 문서에는 다음과 같은 부하 분산기의 예시가 포함되어 있습니다.
- 리전 외부 애플리케이션 부하 분산기
- 리전 내부 애플리케이션 부하 분산기
- 리전 간 내부 애플리케이션 부하 분산기
리전별 외부 애플리케이션 부하 분산기와 리전별 내부 애플리케이션 부하 분산기 비교. 리전별 부하 분산기의 트래픽 관리 구성과 관련해 리전별 URL 맵 API 및 리전별 백엔드 서비스 API 문서에서는 관계, 제한사항, 카디널리티와 관련된 시맨틱스를 포함한 전체 필드 목록을 제공합니다.
이 두 부하 분산기는 다음과 같이 부하 분산 스키마에서만 차이가 있습니다.
- 리전별 외부 애플리케이션 부하 분산기는
EXTERNAL_MANAGED를 사용합니다. - 리전별 내부 애플리케이션 부하 분산기는
INTERNAL_MANAGED를 사용합니다.
리전별 내부 애플리케이션 부하 분산기와 리전 간 내부 애플리케이션 부하 분산기 비교. 트래픽 관리 구성의 경우 다음을 수행합니다.
리전별 내부 애플리케이션 부하 분산기는 리전별 URL 맵 API를 사용하고, 리전별 백엔드 서비스 API 문서에서는 관계, 제한사항, 카디널리티와 관련된 시맨틱스를 포함한 전체 필드 목록을 제공합니다.
리전 간 내부 애플리케이션 부하 분산기는 전역 URL 맵 API를 사용하고 전역 백엔드 서비스 API 문서는 관계, 제한사항, 카디널리티와 관련된 시맨틱스를 포함한 전체 필드 목록을 제공합니다.
이 페이지에서 설명하는 고급 라우팅 기능 외에도 지원되는 애플리케이션 부하 분산기는 서비스 확장 프로그램과 통합되어 부하 분산 데이터 경로에 커스텀 로직을 삽입할 수 있습니다.
시작하기 전에
트래픽 관리의 작동 방식을 이해해야 합니다. 자세한 내용은 리전 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참고하세요.
트래픽 관리 구성
선택한 구성 환경 내에서 YAML 구성을 사용하여 트래픽 관리를 설정합니다. URL 맵과 백엔드 서비스 각각에 자체 YAML 파일이 있습니다. 원하는 기능에 따라 URL 맵 YAML 파일, 백엔드 서비스 YAML 파일 또는 두 파일을 모두 작성해야 합니다.
이러한 YAML 파일을 작성하는 데 도움이 필요한 경우 이 페이지의 예시와 Cloud Load Balancing API 문서를 사용하면 됩니다.
Google Cloud 콘솔은 지원되지 않습니다.리전 내부 애플리케이션 부하 분산기와 리전 외부 애플리케이션 부하 분산기의 경우 리전별 URL 맵 API 및 리전별 백엔드 서비스 API 문서에서는 관계, 제한사항, 카디널리티와 관련된 시맨틱스를 포함한 전체 필드 목록을 제공합니다.
트래픽을 단일 서비스에 매핑
모든 트래픽을 단일 서비스에 전송합니다. 자리표시자를 바꿔야 합니다.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
두 서비스 간 트래픽 분할
둘 또는 여러 서비스 간에 트래픽을 분할합니다. 자리표시자를 바꿔야 합니다.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
weight: 5
URL 리디렉션 구성
다음 예시에서는 구성 가능한 3xx 응답 코드를 반환합니다. 이 예시는 또한 적절한 URI로 Location 응답 헤더를 설정하여 리디렉션 작업에 지정된 대로 호스트와 경로를 바꿉니다.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: URL_MAP_NAME
hostRules:
- hosts:
- "HOST TO REDIRECT FROM" # Use * for all hosts
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
defaultUrlRedirect:
hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
stripQuery: True
트래픽 미러링
선택한 백엔드 서비스로 요청을 전달하는 것 외에 동일한 요청을 파이어 앤 포겟(fire-and-forget) 방식으로 구성된 미러링 백엔드 서비스에 전송합니다. 즉, 부하 분산기는 미러링된 요청을 보내는 백엔드의 응답을 기다리지 않습니다. 요청 미러링은 백엔드 서비스의 새 버전을 테스트하는 데 유용합니다. 또한 미러링을 사용하면 프로덕션 버전이 아닌 백엔드 서비스의 디버그 버전에서 프로덕션 오류를 디버깅할 수 있습니다.
기본적으로 미러링된 백엔드 서비스는 원래 트래픽이 가중치가 적용된 여러 백엔드 서비스 간에 분할되는 경우에도 모든 요청을 수신합니다. 선택적 mirrorPercent 플래그를 사용하여 미러링할 요청의 비율을 0과 100.0 사이의 값으로 지정하여 요청의 일부만 수신하도록 미러링된 백엔드 서비스를 구성할 수 있습니다.
비율 기반 요청 미러링은 미리보기 상태입니다.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
mirrorPercent: 50.0
트래픽 미러링을 사용할 때는 다음 제한사항에 유의하세요.
- 트래픽 미러링은 두 백엔드 서비스 모두 관리형 인스턴스 그룹, 영역 NEG 또는 하이브리드 NEG 백엔드를 사용하는 경우에 지원됩니다. 인터넷 NEG, 서버리스 NEG, Private Service Connect 백엔드에서는 지원되지 않습니다.
- 미러링된 백엔드 서비스에 대한 요청은 Cloud Logging 및 Cloud Monitoring의 로그 또는 측정항목을 생성하지 않습니다.
요청된 URL 재작성
선택한 백엔드 서비스에 요청을 전송하기 전에 URL의 호스트 이름 부분이나 URL의 경로 부분 또는 둘 다 재작성할 수 있습니다. 자리표시자를 바꿔야 합니다.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/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: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
경로 제한 시간 지정
선택한 경로의 제한 시간을 지정합니다. 제한 시간은 요청이 완전히 처리된 시간부터 응답이 완전히 처리될 때까지 계산됩니다. 제한 시간에는 모든 재시도 횟수가 포함됩니다. 자리표시자를 바꿔야 합니다.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
timeout:
seconds: 30
nanos: 500000000
결함 주입 구성
높은 지연 시간, 서비스 과부하, 서비스 장애, 네트워크 파티션 나누기 등의 장애를 시뮬레이션하는 요청을 제공할 때 의도적으로 오류를 발생시킬 수 있습니다. 이 기능은 장애를 시뮬레이션하면서 서비스의 복원력을 테스트하는 데 유용합니다.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
faultInjectionPolicy:
delay:
fixedDelay:
seconds: 10
nanos: 500000000
percentage: 25
abort:
httpStatus: 503
percentage: 50
CORS 구성
교차 출처 리소스 공유(CORS) 요청을 적용하기 위한 설정을 처리하도록 CORS 정책을 구성합니다.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
corsPolicy:
allowOrigins: my-domain.com
allowMethods: GET, POST
allowHeaders: Authorization, Content-Type
maxAge: 1200
allowCredentials: True
요청 및 응답 헤더 추가 및 삭제
백엔드 서비스에 요청을 보내기 전에 요청 헤더를 추가하고 삭제합니다. 또한 백엔드 서비스에서 응답을 수신한 후 응답 헤더를 추가하거나 삭제합니다.
또한 리전별 외부 애플리케이션 부하 분산기 및 내부 애플리케이션 부하 분산기는 커스텀 헤더에서 변수 사용을 지원합니다. 커스텀 헤더 값(headerValue) 필드에 이후 해당 요청별 값으로 번역되는 하나 이상의 변수를 지정할 수 있습니다. 지원되는 헤더 값 목록은 URL 맵에서 커스텀 헤더 만들기를 참조하세요.
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
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: LOAD_BALANCING_SCHEME
localityLbPolicy: RANDOM
name: projects/PROJECT_ID/regions/REGION/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
region: region/REGION
회로 차단 구성
회로 차단을 통해 클라이언트 요청으로 인해 백엔드에 과부하가 발생하지 않도록 장애 임곗값을 설정할 수 있습니다. 요청이 설정한 한도에 도달하면 부하 분산기가 새 연결 허용 또는 추가 요청 전송을 중지하여 백엔드를 복구할 시간을 줍니다. 따라서 회로 차단은 백엔드에 과부하를 발생시키지 않고 클라이언트에 오류를 반환하여 연쇄적 장애를 방지합니다. 이렇게 하면 일부 트래픽을 제공하면서도 자동 확장을 통해 용량을 늘려 트래픽 급증을 처리하는 것과 같은 과부하 상황 관리를 위한 시간을 확보할 수 있습니다.
연결당 요청 수와 백엔드 서비스에 대한 연결 볼륨의 상한선을 설정합니다. 또한 대기 중인 요청 수 및 재시도 횟수를 제한합니다.
loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
localityLbPolicy: RANDOM
affinityCookieTtlSec: 0
backends:
- balancingMode: UTILIZATION
capacityScaler: 1.0
group: region/REGION/instanceGroups/INSTANCE_GROUP
maxUtilization: 0.8
circuitBreakers:
maxConnections: 1000
maxPendingRequests: 200
maxRequests: 1000
maxRequestsPerConnection: 100
maxRetries: 3
connectionDraining:
drainingTimeoutSec: 0
healthChecks:
- region/REGION/healthChecks/HEALTH_CHECK
트래픽 분할 설정: 세부 단계
이 예시에서는 다음 단계를 설명합니다.
서비스별로 고유한 템플릿을 만듭니다.
위에서 만든 템플릿에 대한 인스턴스 그룹을 만듭니다.
트래픽 분산을 95%/5%로 설정하는 라우팅 규칙을 만듭니다.
트래픽 분할 비율이 대략 구성과 일치함을 보여주는 curl 명령어를 전송합니다.
여기에서는 다음과 같이 설정되었다고 가정합니다.
- 리전은
us-west1입니다. 대상 프록시 및 전달 규칙이 URL 맵(
regional-lb-map)과 함께 생성되었습니다.URL 맵은 모든 트래픽을 기본 백엔드 서비스인
red-service라는 하나의 백엔드 서비스로 전송합니다.트래픽 중 5%를
blue-service로, 나머지 95%를green-service로 전송하는 대체 경로를 설정합니다경로 일치자가 사용됩니다.
Cloud Shell이나 bash가 설치된 다른 환경을 사용 중이어야 합니다.
서비스 정의
다음 bash 함수는 인스턴스 템플릿과 관리형 인스턴스 그룹을 포함하는 백엔드 서비스를 만듭니다.
이 안내에서는 HTTP 상태 확인(regional-lb-basic-check)이 생성되었다고 가정합니다. 자세한 내용은 리전별 외부 애플리케이션 부하 분산기 설정을 참고하세요.
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=LOAD_BALANCING_SCHEME\
--protocol=HTTP \
--health-checks=regional-lb-basic-check \
--health-checks-region="$region" \
--region="$region"; \
gcloud compute backend-services add-backend "${name}-service" \
--balancing-mode='UTILIZATION' \
--instance-group="${name}-instance-group" \
--instance-group-zone="$zone" \
--region="$region")
}
서비스 생성
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 맵 만들기
gcloud
gcloud compute url-maps export명령어를 사용하여 기존 URL 맵을 내보냅니다.gcloud compute url-maps export regional-lb-map \ --destination=regional-lb-map-config.yaml \ --region=us-west1
regional-lb-map-config.yamlURL 맵 파일을 파일 끝에 추가하여 업데이트합니다.hostRules: - hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: projects/PROJECT_ID/regions/us-west1/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/green-service weight: 95 - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/blue-service weight: 5gcloud compute url-maps import명령어를 사용하여 URL 맵을 업데이트합니다.gcloud compute url-maps import regional-lb-map \ --region=us-west1 \ --source=regional-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 \ --region=us-west1다음과 같이
red-service-config.yaml파일을 업데이트합니다.sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 500000000 minimumRingSize: 10000red-service-config.yaml파일에서 다음 줄을 삭제합니다.sessionAffinity: NONE
백엔드 서비스 구성 파일을 업데이트합니다.
gcloud compute backend-services import red-service \ --source=red-service-config.yaml \ --region=us-west1
문제 해결
구성된 라우팅 규칙 및 트래픽 정책에 따라 트래픽이 라우팅되지 않으면 이 정보를 사용하여 문제를 해결합니다.
로깅 및 모니터링에 대한 자세한 내용은 외부 HTTP(S) 로깅 및 모니터링을 참조하세요.증상
- 문제가 되는 규칙보다 상위 규칙의 서비스로 전송되는 트래픽이 증가했습니다.
- 특정 라우팅 규칙에 대한 4xx 및 5xx HTTP 응답 횟수가 예기치 않게 증가했습니다.
해결책: 라우팅 규칙의 순서를 확인합니다. 라우팅 규칙은 지정된 순서대로 평가됩니다.
URL 맵 내 라우팅 규칙은 지정된 순서에 따라 평가됩니다. 이 방법은 경로 규칙이 가장 긴 프리픽스 일치 항목을 기준으로 평가되는 방식과 다릅니다. 경로 규칙의 경우 내부 애플리케이션 부하 분산기는 1개의 경로 규칙만 선택하지만 라우팅 규칙을 사용할 경우 2개 이상의 규칙이 적용될 수 있습니다.
라우팅 규칙을 정의하는 경우 원래는 후속 라우팅 규칙에 따라 라우팅되어야 하는 트래픽이 목록의 상단에 있는 규칙에 따라 의도치 않게 라우팅되지 않는지 확인해야 합니다. 잘못 전송된 트래픽을 수신하는 서비스는 요청을 거부하므로 라우팅 규칙의 서비스에 수신되는 트래픽 양이 줄어들거나 전혀 수신되지 않을 수 있습니다.