내부 애플리케이션 부하 분산기에 대한 트래픽 관리 설정

이 문서에서는 특정 사용 사례에 트래픽 관리를 사용하는 예시를 다룹니다. 다른 많은 사용 사례가 있을 수 있습니다.

이 문서에는 다음과 같은 부하 분산기의 예시가 포함되어 있습니다.

  • 리전 외부 애플리케이션 부하 분산기
  • 리전 내부 애플리케이션 부하 분산기
  • 리전 간 내부 애플리케이션 부하 분산기

리전별 외부 애플리케이션 부하 분산기와 리전별 내부 애플리케이션 부하 분산기 비교. 리전별 부하 분산기의 트래픽 관리 구성과 관련해 리전별 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 문서는 관계, 제한 및 카디널리티에 관한 시맨틱을 포함한 전체 필드 목록을 제공합니다.

Google Cloud Console에서 YAML 예시에 액세스

Google Cloud 콘솔에서 YAML 예시에 액세스하려면 다음 안내를 따르세요.

  1. Google Cloud 콘솔에서 부하 분산 페이지로 이동합니다.

    부하 분산으로 이동

  2. 부하 분산기 만들기를 클릭합니다.
  3. 마법사의 단계를 완료하여 리전 내부 애플리케이션 부하 분산기를 만듭니다.
  4. 라우팅 규칙 구성에서 고급 호스트, 경로, 라우팅 규칙을 선택합니다.
  5. 호스트 및 경로 일치자 추가를 클릭합니다.
  6. 코드 도움말 링크를 클릭합니다.

경로 일치자 YAML 예시 페이지가 나타납니다.

트래픽을 단일 서비스에 매핑

모든 트래픽을 단일 서비스에 전송합니다. 자리표시자를 바꿔야 합니다.

    defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

두 서비스 간 트래픽 분할

둘 또는 여러 서비스 간에 트래픽을 분할합니다. 자리표시자를 바꿔야 합니다.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
           weight: 5

URL 리디렉션 구성

다음 예시에서는 구성 가능한 3xx 응답 코드를 반환합니다. 이 예시는 또한 적절한 URI로 Location 응답 헤더를 설정하여 리디렉션 작업에 지정된 대로 호스트와 경로를 바꿉니다.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/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: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: regions/REGION/backendServices/BACKEND_SERVICE_2

요청된 URL 재작성

선택한 백엔드 서비스에 요청을 전송하기 전에 URL의 호스트 이름 부분이나 URL의 경로 부분 또는 둘 다 재작성할 수 있습니다. 자리표시자를 바꿔야 합니다.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: 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: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

경로 제한 시간 지정

선택한 경로의 제한 시간을 지정합니다. 제한 시간은 요청이 완전히 처리된 시간부터 응답이 완전히 처리될 때까지 계산됩니다. 제한 시간에는 모든 재시도 횟수가 포함됩니다. 자리표시자를 바꿔야 합니다.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 500000000

결함 주입 구성

높은 지연 시간, 서비스 과부하, 서비스 장애, 네트워크 파티션 나누기 등의 장애를 시뮬레이션하는 요청을 제공할 때 의도적으로 오류를 발생시킬 수 있습니다. 이 기능은 장애를 시뮬레이션하면서 서비스의 복원력을 테스트하는 데 유용합니다.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: 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: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: 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: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: 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: 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

트래픽 분할 설정: 세부 단계

이 예시에서는 다음 단계를 설명합니다.

  1. 서비스별로 고유한 템플릿을 만듭니다.

  2. 위에서 만든 템플릿에 대한 인스턴스 그룹을 만듭니다.

  3. 트래픽 분산을 95%/5%로 설정하는 라우팅 규칙을 만듭니다.

  4. 트래픽 분할 비율이 대략 구성과 일치함을 보여주는 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

  1. gcloud compute url-maps export 명령어를 사용하여 기존 URL 맵을 내보냅니다.

    gcloud compute url-maps export regional-lb-map \
  --destination=regional-lb-map-config.yaml \
  --region=us-west1

  2. regional-lb-map-config.yaml URL 맵 파일을 파일 끝에 추가하여 업데이트합니다.

    hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: regions/us-west1/backendServices/green-service
          weight: 95
        - backendService: regions/us-west1/backendServices/blue-service
          weight: 5

  3. gcloud 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로 전송된 요청이 예상대로 분할되는지 확인합니다.

클라이언트 VM 만들기

자세한 내용은 연결 테스트를 위해 영역에 VM 인스턴스 만들기를 참조하세요.

FORWARDING_RULE_IP_ADDRESS로 요청 보내기

  1. ssh를 사용하여 클라이언트에 연결합니다.

    gcloud compute ssh global-lb-client-us-west1-a \
   --zone=us-west1-a

  2. 다음 명령어를 실행합니다.

    for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
   RESULTS=
   for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1
   IFS=':'
   echo "***"
   echo "*** Results of load balancing to $LB_IP: "
   echo "***"
   for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
   echo
done
결과 확인
***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

FORWARDING_RULE_IP_ADDRESS/PREFIX로 요청 보내기

요청을 FORWARDING_RULE_IP_ADDRESS/PREFIX로 전송한 후 트래픽 분할을 기록합니다.

for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP/PREFIX: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done
결과 확인
***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

카나리아 설정을 통해 /PREFIX 요청 중 95%가 green 서비스로, 나머지 5%가 blue 서비스로 전송됩니다.

트래픽 제어를 사용하면 제공된 쿠키를 기준으로 세션 어피니티를 구성할 수 있습니다. red-service라는 백엔드 서비스에 HTTP_COOKIE 기반 세션 어피니티를 구성하려면 다음 지침을 따르세요.

  1. gcloud compute backend-services export 명령어를 사용하여 백엔드 서비스 구성을 가져옵니다.

    gcloud compute backend-services export red-service \
    --destination=red-service-config.yaml \
    --region=us-west1

  2. 다음과 같이 red-service-config.yaml 파일을 업데이트합니다.

    sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
 httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 500000000
 minimumRingSize: 10000

  3. red-service-config.yaml 파일에서 다음 줄을 삭제합니다.

    sessionAffinity: NONE

  4. 백엔드 서비스 구성 파일을 업데이트합니다.

    gcloud compute backend-services import red-service \
    --source=red-service-config.yaml \
    --region=us-west1

문제 해결

구성된 라우팅 규칙 및 트래픽 정책에 따라 트래픽이 라우팅되지 않으면 이 정보를 사용하여 문제를 해결합니다.

로깅 및 모니터링에 대한 자세한 내용은 내부 HTTP(S) 로깅 및 모니터링을 참조하세요.

증상

  • 문제가 되는 규칙보다 상위 규칙의 서비스로 전송되는 트래픽이 증가했습니다.
  • 특정 라우팅 규칙에 대한 4xx 및 5xx HTTP 응답 횟수가 예기치 않게 증가했습니다.

해결책: 라우팅 규칙의 순서를 확인합니다. 라우팅 규칙은 지정된 순서대로 평가됩니다.

URL 맵 내 라우팅 규칙은 지정된 순서에 따라 평가됩니다. 이 방법은 경로 규칙이 가장 긴 프리픽스 일치 항목을 기준으로 평가되는 방식과 다릅니다. 경로 규칙의 경우 내부 애플리케이션 부하 분산기는 1개의 경로 규칙만 선택하지만 라우팅 규칙을 사용할 경우 2개 이상의 규칙이 적용될 수 있습니다.

라우팅 규칙을 정의하는 경우 원래는 후속 라우팅 규칙에 따라 라우팅되어야 하는 트래픽이 목록의 상단에 있는 규칙에 따라 의도치 않게 라우팅되지 않는지 확인해야 합니다. 잘못 전송된 트래픽을 수신하는 서비스는 요청을 거부하므로 라우팅 규칙의 서비스에 수신되는 트래픽 양이 줄어들거나 전혀 수신되지 않을 수 있습니다.

다음 단계