내부 HTTP(S) 부하 분산기에 대한 트래픽 관리 설정

이 가이드에는 내부 HTTP(S) 부하 분산 트래픽 관리 설정을 위한 예시가 포함되어 있습니다. 이 문서에서는 특정 사용 사례에 트래픽 관리를 사용하는 예시를 보여줍니다. 다른 많은 사용 사례가 있을 수 있습니다.

시작하기 전에

트래픽 관리 구성

Cloud Console, gcloud 또는 Cloud Load Balancing API를 사용하여 트래픽 관리를 구성할 수 있습니다. 선택한 구성 환경 내에서 YAML 구성을 사용하여 트래픽 관리를 설정합니다. URL 맵과 백엔드 서비스 각각에 자체 YAML 파일이 있습니다. 원하는 기능에 따라 URL 맵 YAML, 백엔드 서비스 YAML 또는 둘 다를 작성해야 합니다.

이러한 YAML 파일을 작성하는 데 도움이 되는 리소스는 다음과 같습니다.

Cloud Console에서 YAML 예시 액세스

Cloud Console에서 YAML 예시에 액세스하려면 다음을 수행합니다.

  1. Google Cloud Console의 부하 분산 페이지로 이동합니다.
    부하 분산 페이지로 이동
  2. HTTP(S) 부하 분산에서 구성 시작을 클릭합니다.
  3. VM 사이에서만 분산을 선택합니다. 이 설정은 부하 분산기가 내부용이라는 의미입니다.
  4. 계속을 클릭합니다.
  5. 라우팅 규칙 구성에서 고급 호스트, 경로, 라우팅 규칙을 선택합니다.
  6. 호스트 및 경로 일치자 추가를 클릭합니다.
  7. 코드 도움말 링크를 클릭합니다.

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

URL 맵 YAML 예시

URL 맵에 단일 항목이 허용됨

단일 서비스

모든 트래픽을 단일 서비스에 전송 []으로 표시된 변수를 바꿉니다.

defaultService: regions/[region]/backendServices/[backend-service1]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: [url-map-name]
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100

트래픽 분할

여러 서비스 간 트래픽을 분할합니다. []으로 표시된 변수를 바꿉니다.

defaultService: regions/[region]/backendServices/[backend-service1]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: [url-map-name]
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /prefix
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: regions/[region]/backendServices/[backend-service1]
        weight: 95
      - backendService: regions/[region]/backendServices/[backend-service2]
        weight: 5

URL 리디렉션

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      urlRedirect:
        hostRedirect: [REDIRECT_HOST]
        pathRedirect: [REDIRECT_PATH]
        redirectResponseCode: FOUND
        stripQuery: True

URL 맵에 여러 항목이 허용됨

트래픽 미러링

선택한 백엔드 서비스로 요청을 전달하는 것 외에 동일한 요청을 '파이어 앤 포겟(fire-and-forget)' 방식으로 구성된 미러링 백엔드 서비스에 전송합니다. 부하 분산기는 미러링된 요청을 보내는 백엔드의 응답을 기다리지 않습니다. 미러링은 백엔드 서비스의 새 버전을 테스트하는 데 유용합니다. 또한 미러링을 사용하면 프로덕션 버전이 아닌 백엔드 서비스의 디버그 버전에서 프로덕션 오류를 디버깅할 수 있습니다. []으로 표시된 변수를 바꿉니다.

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        requestMirrorPolicy:
          backendService: regions/[region]/backendServices/[backend-service2]

URL 재작성

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        urlRewrite:
          hostRewrite: [REWRITE_HOST]
          pathPrefixRewrite: [REWRITE_PATH]

재시도 요청

부하 분산기가 실패한 요청을 재시도하는 조건, 재시도 전 부하 분산기가 대기하는 시간, 최대 재시도 허용 횟수를 구성합니다. []으로 표시된 변수를 바꿉니다.

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        retryPolicy:
          retryConditions: 502, 504
          numRetries: 3
          perTryTimeout:
            seconds: 1
            nanos: 50

제한 시간

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        timeout:
          seconds: 30
          nanos: 100

장애

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        faultInjectionPolicy:
          delay:
            fixedDelay:
              seconds: 10
              nanos: 20
            percentage: 25
          abort:
            httpStatus: 503
            percentage: 50

CORS

교차 출처 리소스 공유(CORS) 요청을 적용하기 위해 내부 HTTP(S) 부하 분산 설정을 처리하도록 CORS 정책을 구성합니다. []으로 표시된 변수를 바꿉니다.

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        corsPolicy:
            allowOrigins: my-domain.com
            allowMethods: GET, POST
            allowHeaders: Authorization, Content-Type
            maxAge: 1200
            allowCredentials: True

헤더

백엔드 서비스에 요청을 보내기 전에 요청 헤더를 추가하고 제거합니다. 또한 백엔드 서비스에서 응답을 수신한 후 응답 헤더를 추가하거나 삭제합니다. []으로 표시된 변수를 바꿉니다.

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      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

백엔드 서비스 YAML 예시

이상점 감지

NEG에서 비정상 백엔드 VM 또는 엔드포인트를 제거하는 기준과 백엔드 또는 엔드포인트에서 트래픽을 다시 수신하기에 충분할 정도로 정상임을 판단하는 기준을 지정합니다. []으로 표시된 변수를 바꿉니다.

kind: compute#backendService
loadBalancingScheme: INTERNAL_MANAGED
localityLbPolicy: RANDOM
name: regions/[region]/backendServices/[backend-service1]
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]

회로 차단

회로 차단을 통해 클라이언트 요청으로 인해 백엔드에 과부하가 발생하지 않도록 장애 임곗값을 설정할 수 있습니다. 요청이 설정한 한도에 도달하면 부하 분산기가 새 연결 허용 또는 추가 요청 전송을 중지하여 백엔드를 복구할 시간을 줍니다. 따라서 회로 차단은 백엔드에 과부하를 발생시키지 않고 클라이언트에 오류를 반환하여 연쇄적 장애를 방지합니다. 이렇게 하면 일부 트래픽을 제공하면서도 자동 확장을 통해 용량을 늘려 트래픽 급증을 처리하는 것과 같은 과부하 상황 관리를 위한 시간을 확보할 수 있습니다.

연결당 요청 수와 백엔드 서비스에 대한 연결 볼륨의 상한선을 설정합니다. 또한 대기 중인 요청 수 및 재시도 횟수를 제한합니다. []으로 표시된 변수를 바꿉니다.

kind: compute#backendService
loadBalancingScheme: 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 맵(l7-ilb-map)과 함께 생성되었습니다.
  • 전달 규칙의 주소는 10.1.2.99입니다.

    자세한 안내는 Compute Engine VM에 내부 HTTP(S) 부하 분산 설정을 참조하세요.

  • URL 맵은 모든 트래픽을 기본 백엔드 서비스인 red-service라는 하나의 백엔드 서비스로 전송합니다.

  • 트래픽 중 5%를 blue-service로, 나머지 95%를 green-service로 전송하는 대체 경로를 설정합니다

  • 경로 일치자가 사용됩니다.

  • Cloud Shell이나 bash가 설치된 다른 환경을 사용 중이어야 합니다.

서비스 정의

다음 bash 함수는 인스턴스 템플릿과 관리형 인스턴스 그룹을 포함하는 백엔드 서비스를 만듭니다.

이 안내에서는 HTTP 상태 확인(l7-ilb-basic-check)이 생성되었다고 가정합니다. 자세한 안내는 Compute Engine VM에 내부 HTTP(S) 부하 분산 설정을 참조하세요.

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-9 \
    --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=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-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 서비스는 / 요청에 대해 기본 서비스 역할을 합니다. greenblue 서비스는 각각 트래픽의 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 맵 만들기

Console

  1. Google Cloud Console의 부하 분산 페이지로 이동합니다.
    부하 분산 페이지로 이동
  2. l7-ilb-map 링크를 클릭합니다.
  3. 수정 을 클릭합니다.

새 라우팅 규칙 구성

  1. 라우팅 규칙에서 고급 호스트, 경로 및 경로 규칙을 선택합니다.
  2. 새 호스트 및 경로 일치자에서 서비스red-service로 설정하여 기본 작업을 만듭니다.
  3. 완료를 클릭합니다.
  4. 호스트 및 경로 일치자 추가를 클릭합니다.
  5. 호스트 필드에 10.1.2.99를 입력합니다. 부하 분산기 전달 규칙의 IP 주소입니다.
  6. 다음 YAML 콘텐츠를 경로 일치자 상자에 붙여넣고 [PROJECT_ID]를 프로젝트 ID로 바꿉니다.

    defaultService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/red-service
    name: matcher1
    routeRules:
    - priority: 2
      matchRules:
        - prefixMatch: /prefix
      routeAction:
        weightedBackendServices:
          - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/green-service
            weight: 95
          - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/blue-service
            weight: 5
    
  7. 완료를 클릭합니다.

  8. 업데이트를 클릭합니다.

gcloud

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

    gcloud compute url-maps export l7-ilb-map \
      --destination=l7-ilb-map-config.yaml \
      --region=us-west1
    
  2. l7-ilb-map-config.yaml URL 맵 파일을 파일 끝에 추가하여 업데이트하고 [PROJECT_ID]를 프로젝트 ID로 바꿉니다.

    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    pathMatchers:
    - defaultService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/red-service
      name: matcher1
      routeRules:
      - priority: 2
        matchRules:
          - prefixMatch: /prefix
        routeAction:
          weightedBackendServices:
            - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/green-service
              weight: 95
            - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/blue-service
              weight: 5
    
  3. gcloud compute url-maps import 명령어를 사용하여 URL 맵을 업데이트합니다.

    gcloud compute url-maps import l7-ilb-map \
       --region=us-west1 \
       --source=l7-ilb-map-config.yaml
    

구성 테스트

구성을 테스트하려면 먼저 10.1.2.99/(앞에서 설정한 부하 분산기의 IP 주소)에 대한 요청이 기본 red 구성에서 처리되는지 확인해야 합니다.

그런 다음 10.1.2.99/prefix로 전송된 요청이 예상대로 분할되는지 확인합니다.

클라이언트 VM 만들기

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

10.1.2.99로 요청 전송

SSH로 클라이언트에 연결합니다.

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

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

for LB_IP in 10.1.2.99; 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 10.1.2.99:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

10.1.2.99/prefix로 요청 전송

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

for LB_IP in 10.1.2.99; 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 10.1.2.99/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 기반 세션 어피니티를 구성하려면 다음 지침을 따르세요.

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: 30
     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 맵 내 라우팅 규칙은 지정된 순서에 따라 평가됩니다. 이 방법은 경로 규칙이 가장 긴 프리픽스 일치 항목을 기준으로 평가되는 방식과 다릅니다. 경로 규칙의 경우 내부 HTTP(S) 부하 분산은 1개의 경로 규칙만 선택하지만 라우팅 규칙을 사용할 경우 2개 이상이 규칙이 적용될 수 있습니다.

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