Envoy를 사용하여 고급 트래픽 관리 구성

이 문서에서는 Traffic Director 배포를 위한 고급 트래픽 관리를 구성하는 방법에 대한 정보를 제공합니다.

시작하기 전에

고급 트래픽 관리를 구성하기 전에 Envoy로 Traffic Director 설정 준비의 안내를 따릅니다. 여기에는Traffic Director 및 모든 가상 머신(VM) 호스트 또는 필요한 Google Kubernetes Engine(GKE) 클러스터를 구성하는 방법 등이 나와 있습니다. 필요한 Google Cloud 리소스를 만듭니다.

고급 트래픽 관리 기능의 사용 가능 여부는 선택한 요청 프로토콜에 따라 다릅니다. 이 프로토콜은 대상 HTTP 또는 HTTPS 프록시, 대상 gRPC 프록시 또는 대상 TCP 프록시 리소스를 사용하여 라우팅을 구성할 때 구성됩니다.

대상 HTTP 프록시 및 대상 HTTPS 프록시를 사용하면 이 문서에 설명된 모든 기능을 사용할 수 있습니다.
대상 gRPC 프록시를 사용하면 일부 기능을 사용할 수 있습니다.
대상 TCP 프록시를 사용하면 고급 트래픽 관리 기능을 사용할 수 없습니다.

자세한 내용은 Traffic Director 기능 및 고급 트래픽 관리를 참조하세요. 엔드 투 엔드 설정 가이드는 프록시리스 gRPC 서비스로 고급 트래픽 관리 구성을 참조하세요.

트래픽 분할 설정

여기에서는 다음과 같이 설정되었다고 가정합니다.

Traffic Director 배포에는 review-url-map이라는 URL 맵이 있습니다.
URL 맵은 모든 트래픽을 기본 백엔드 서비스로 사용되는 review1이라는 하나의 백엔드 서비스로 보냅니다.
트래픽의 5%를 새 버전의 서비스로 라우팅하려고 합니다. 이 서비스는 백엔드 서비스 review2에 연결된 네트워크 엔드포인트 그룹(NEG)의 백엔드 VM 또는 엔드포인트에서 실행 중입니다.
호스트 규칙도, 경로 일치자도 사용되지 않습니다.

트래픽 분할을 설정하려면 다음 단계를 따르세요.

Console

Google Cloud Console에서 Traffic Director 페이지로 이동합니다.

Traffic Director로 이동
라우팅 규칙 맵을 클릭합니다.
라우팅 규칙 맵 만들기를 클릭합니다.
라우팅 규칙 맵 만들기 페이지에서 이름을 입력합니다.
프로토콜 메뉴에서 HTTP를 선택합니다.
기존 전달 규칙을 선택합니다.
라우팅 규칙에서 고급 호스트, 경로 및 경로 규칙을 선택합니다.
호스트 및 경로 일치자에서 호스트 및 경로 일치자 추가를 클릭합니다. 그러면 트래픽을 분할하도록 구성할 수 있는 새로운 경로 일치자가 추가됩니다.

경로 일치자 필드에 다음 설정을 추가합니다.

    - 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

완료를 클릭합니다.
저장을 클릭합니다.

새 버전에 만족하면 두 서비스의 가중치를 점차적으로 조정하고 최종적으로 모든 트래픽을 review2에 전송할 수 있습니다.

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 페이지로 이동합니다.

Traffic Director로 이동
업데이트할 백엔드 서비스의 이름을 클릭합니다.
수정을 클릭합니다.
고급 구성을 클릭합니다.
회로 차단기에서 사용 설정 체크박스를 선택합니다.
수정을 클릭합니다.
1. 연결당 최대 요청 수에 100을 입력합니다.
2. 최대 연결 수에 1000을 입력합니다.
3. 최대 대기 요청 수에 200을 입력합니다.
4. 최대 요청 수에 1000을 입력합니다.
5. 최대 재시도 수에 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/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
   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/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
 loadBalancingScheme: INTERNAL_SELF_MANAGED
 localityLbPolicy: ROUND_ROBIN
 name: BACKEND_SERVICE_NAME
 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개가 있는 사용 사례입니다. 회로 차단기 설정은 다음에 대한 제한을 나타냅니다.

연결당 최대 요청 수: 100
최대 연결 수: 1,000
대기 중 최대 요청 수: 200
최대 요청 수: 20,000
최대 재시도 수: 3

회로 차단 예시를 설정하려면 다음 단계를 따르세요.

Console

Cloud Console에서 Traffic Director 페이지로 이동합니다.

Traffic Director로 이동
업데이트할 백엔드 서비스의 이름을 클릭합니다.
수정을 클릭합니다.
고급 구성을 클릭합니다.
회로 차단기에서 사용 설정 체크박스를 선택합니다.
수정을 클릭합니다.
1. 연결당 최대 요청 수에 100을 입력합니다.
2. 최대 연결 수에 1000을 입력합니다.
3. 최대 대기 요청 수에 200을 입력합니다.
4. 최대 요청 수에 20000을 입력합니다.
5. 최대 재시도 수에 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/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
   maxUtilization: 0.8
 circuitBreakers:
   maxConnections: 1000
   maxPendingRequests: 200
   maxRequests: 20000
   maxRequestsPerConnection: 100
   maxRetries: 3
 connectionDraining:
   drainingTimeoutSec: 300
 healthChecks:
   -  https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
 loadBalancingScheme: INTERNAL_SELF_MANAGED
 localityLbPolicy: ROUND_ROBIN
 name: BACKEND_SERVICE_NAME
 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

`HTTP_COOKIE`를 기준으로 세션 어피니티 설정

고급 트래픽 관리를 사용하면 제공된 쿠키를 기반으로 세션 어피니티를 구성할 수 있습니다.

HTTP_COOKIE를 사용하여 세션 어피니티를 설정하려면 다음 단계를 따르세요.

Console

Cloud Console에서 Traffic Director 페이지로 이동합니다.

Traffic Director로 이동
업데이트할 백엔드 서비스의 이름을 클릭합니다.
수정을 클릭합니다.
고급 구성을 클릭합니다.
세션 어피니티에서 HTTP 쿠키를 선택합니다.
지역 부하 분산 정책에서 링 해시를 선택합니다.
1. HTTP 쿠키 이름 필드에 http_cookie를 입력합니다.
2. HTTP 쿠키 경로 필드에 /cookie_path를 입력합니다.
3. HTTP 쿠키 TTL 필드에 100을 입력합니다.
4. 최소 링 크기 필드에 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초를 곱한 만큼입니다.

백엔드 서비스 리소스에 이상점 감지를 설정하려면 다음 단계를 따르세요.

Console

Cloud Console에서 Traffic Director 페이지로 이동합니다.

Traffic Director로 이동
서비스 이름을 클릭합니다.
수정을 클릭합니다.
고급 구성을 클릭합니다.
이상점 감지 체크박스를 선택합니다.
수정을 클릭합니다.
1. 연속 오류를 5로 설정합니다.
2. 간격을 1000밀리초로 설정합니다.
3. 기본 제거 시간을 30000밀리초로 설정합니다.
저장을 클릭한 후 다시 저장을 클릭합니다.

gcloud

gcloud export 명령어를 실행하여 백엔드 서비스 구성을 내보냅니다. BACKEND_SERVICE_NAME을 백엔드 서비스의 이름으로 바꿉니다.
```
gcloud compute backend-services export BACKEND_SERVICE_NAME \
    --destination=BACKEND_SERVICE_NAME-config.yaml --global
```

다음과 같이 YAML 파일을 업데이트하고 BACKEND_SERVICE_NAME은 백엔드 서비스 이름으로 바꿉니다.

name: BACKEND_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 페이지로 이동합니다.

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 리소스에 대한 문서를 참조하세요.

`MetadataFilters` 일치를 기반으로 구성 필터링 설정

MetadataFilters는 전달 규칙과 HttpRouteRuleMatch로 사용 설정됩니다. 이 기능을 사용하여 특정 제어 규칙 또는 라우팅 규칙을 제어하면 제어 영역이 노드 메타데이터가 메타데이터 필터 설정과 일치하는 프록시에만 전달 규칙 또는 라우팅 규칙을 전송합니다. MetadataFilters를 지정하지 않는 경우 규칙이 모든 Envoy 프록시로 전송됩니다.

이 기능을 사용하면 단계적 구성 배포를 쉽게 수행할 수 있습니다. 예를 들어 노드 메타데이터에 app: review 및 version: canary가 포함된 Envoy로만 푸시할 forwarding-rule1이라는 전달 규칙을 만듭니다.

전달 규칙에 MetadataFilters를 추가하려면 다음 단계를 따르세요.

gcloud

gcloud export 명령어를 실행하여 전달 규칙 구성을 가져옵니다.

gcloud compute forwarding-rules export forwarding-rule1 \
    --destination=forwarding-rule1-config.yaml \
    --global

전달 규칙 삭제:

gcloud compute forwarding-rules delete forwarding-rule1 \
    --global

forwarding-rule1-config.yaml 파일을 업데이트합니다.

다음 예시에서는 MATCH_ALL 메타데이터 필터를 만듭니다.

 metadataFilters:
 - filterMatchCriteria: 'MATCH_ALL'
   filterLabels:
   - name: 'app'
     value: 'review'
   - name: 'version'
     value: 'canary'

다음 예시에서는 MATCH_ANY 메타데이터 필터를 만듭니다.

 metadataFilters:
 - filterMatchCriteria: 'MATCH_ANY'
   filterLabels:
   - name: 'app'
     value: 'review'
   - name: 'version'
     value: 'production'

forwarding-rule1-config.yaml 파일에서 모든 출력 전용 필드를 삭제합니다. 자세한 내용은 gcloud compute forwarding-rules import에 대한 문서를 참조하세요.

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에서 metadata 섹션에 다음을 추가합니다.
```
   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로 라우팅됩니다. 두 번째 규칙이 일치하더라도 첫 번째 규칙에 우선순위가 있으므로 무시됩니다.

다음 단계

Traffic Director 구성 문제를 해결하려면 Envoy를 사용하는 배포 문제 해결을 참조하세요.

Envoy를 사용하여 고급 트래픽 관리 구성

시작하기 전에

트래픽 분할 설정

Console

gcloud

회로 차단 설정

Console

gcloud

회로 차단 예시

Console

gcloud

HTTP_COOKIE를 기준으로 세션 어피니티 설정

Console

gcloud

이상점 감지 설정

Console

gcloud

지역 부하 분산 정책 설정

Console

gcloud

MetadataFilters 일치를 기반으로 구성 필터링 설정

gcloud

메타데이터 필터링 예시

gcloud

gcloud

문제 해결하기

다음 단계

`HTTP_COOKIE`를 기준으로 세션 어피니티 설정

`MetadataFilters` 일치를 기반으로 구성 필터링 설정