게이트웨이 트래픽 관리

이 페이지에서는 게이트웨이 트래픽 관리의 작동 방법을 설명합니다.

개요

Google Kubernetes Engine(GKE) 네트워킹은 Cloud Load Balancing을 기반으로 합니다. Cloud Load Balancing을 통해 단일 애니캐스트 IP 주소가 전역 트래픽 관리를 제공합니다. Google 트래픽 관리는 전역 및 리전별 부하 분산, 자동 확장, 용량 관리를 통해 균일화되고 안정적이며 낮은 지연 시간의 트래픽 분산을 제공합니다. GKE 사용자는 GKE 게이트웨이 컨트롤러를 사용해서 선언적인 Kubernetes 네이티브 방식으로 Google의 전역 트래픽 관리 제어 기능을 활용할 수 있습니다.

클러스터 간 트래픽 스필오버를 시도하려면 용량 기반 부하 분산 배포를 참조하세요. 트래픽 기반 자동 확장을 시도하려면 부하 분산기 트래픽 기반 자동 확장을 참조하세요.

트래픽 관리

부하 분산, 자동 확장, 용량 관리는 트래픽 관리 시스템의 기초입니다. 이러한 요소들을 종합하여 시스템 부하가 균일화되고 안정화됩니다.

  • 부하 분산은 위치, 상태, 여러 부하 분산 알고리즘에 따라 백엔드 포드 간에 트래픽을 분산시킵니다.
  • 자동 확장은 더 많은 트래픽을 흡수할 수 있도록 워크로드 복제본을 확장해서 더 많은 공간을 만듭니다.
  • 용량 관리는 애플리케이션 가용성이나 성능에 영향을 주지 않고 트래픽이 용량이 있는 백엔드로 오버플로될 수 있도록 서비스 사용률을 모니터링합니다.

목적에 따라 이러한 기능을 여러 방식으로 조합해서 사용할 수 있습니다. 예를 들면 다음과 같습니다.

  • 비용이 낮은 Spot VM을 활용하려는 경우에는 지연 시간이 있더라도 Spot VM 간에 트래픽이 고르게 분산되도록 최적화해야 할 수 있습니다. GKE는 가능할 때마다 Spot VM이 항상 최대한 활용되도록 부하 분산 및 용량 관리를 사용해서 용량에 따라 리전 간에 트래픽을 오버플로합니다.
  • 초과 프로비저닝이 발생하더라도 사용자 지연 시간을 최적화하기 위해서는 여러 리전에 GKE 클러스터를 배포하고 부하가 늘어날 때마다 동적으로 용량을 늘릴 수 있습니다. GKE는 트래픽을 다른 리전으로 오버플로할 필요가 없도록 부하 분산 및 자동 확장을 사용해서 트래픽이 급증할 때 포드 수를 자동 확장합니다. 리전 용량이 증가하므로 가능한 한 사용자에게 가까운 위치에서 로드를 완전히 처리할 수 있습니다.

다음 다이어그램은 부하 분산, 자동 확장, 용량 관리가 함께 어떻게 작동하는지 보여줍니다.

부하 분산, 자동 확장, 용량 관리 다이어그램

이 다이어그램은 gke-us 클러스터의 워크로드에 문제가 발생한 것을 보여줍니다. 부하 분산 및 상태 점검으로 활성 연결이 드레이닝되고 트래픽이 그 다음으로 가장 가까운 클러스터로 리디렉션됩니다. gke-asia의 워크로드에 포함된 용량보다 많은 트래픽이 수신되므로 로드를 gke-eu로 흘립니다. gke-eu는 gke-us 및 gke-asia에서의 이벤트로 인해 일반적인 것보다 많은 로드가 발생합니다. 따라서 gke-eu가 자동 확장을 통해 트래픽 용량을 늘립니다.

Cloud Load Balancing에서 트래픽 관리를 수행하는 방법은 전역 용량 관리를 참조하세요.

트래픽 관리 기능

게이트웨이, HTTPRoute, 서비스, 정책 리소스는 GKE의 트래픽 관리를 위한 제어를 제공합니다. GKE 게이트웨이 컨트롤러는 이러한 리소스를 모니터링하는 컨트롤 플레인입니다.

GKE에서 서비스를 배포할 때 사용할 수 있는 트래픽 관리 기능은 다음과 같습니다.

  • 서비스 용량: 포드가 자동 확장되거나 트래픽이 다른 사용 가능한 클러스터로 오버플로되기 전에 서비스가 받을 수 있는 트래픽 용량을 지정하는 기능입니다.
  • 트래픽 기반 자동 확장: 초당 수신되는 HTTP 요청을 기반으로 서비스 내에서 포드를 자동 확장합니다.
  • 멀티 클러스터 부하 분산: 여러 GKE 클러스터 또는 여러 리전 간에 호스팅되는 서비스로 부하 분산하는 기능입니다.
  • 트래픽 분할: 백엔드 간에 수행되는 명시적인 가중치 기반 트래픽 분산입니다. 트래픽 분할은 GA의 단일 클러스터 게이트웨이에서 지원됩니다.

트래픽 관리 지원

사용 가능한 트래픽 관리 기능은 배포하는 GatewayClass에 따라 달라집니다. 지원 기능의 전체 목록은 GatewayClass 기능을 참조하세요. 다음 표에서는 트래픽 관리를 위한 GatewayClass 지원을 요약해서 보여줍니다.

GatewayClass 서비스 용량 트래픽 자동 확장 멀티 클러스터 부하 분산 트래픽 분할1
gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-gxlb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-rilb-mc
gke-l7-gxlb-mc
1 트래픽 분할은 GA의 단일 클러스터 게이트웨이에서 지원됩니다.

전역, 리전 및 영역 부하 분산

서비스 용량, 위치, 상태는 모두 부하 분산기가 특정 백엔드로 보낼 수 있는 트래픽의 양을 결정하는 데 영향을 줍니다. 부하 분산 결정은 전역 부하 분산기에 대한 전역 수준과 리전 부하 분산기에 대한 리전 수준으로 시작해서 다음 수준에서 수행됩니다.

  • 전역: 정상 용량 백엔드가 있는 클라이언트에 가장 가까운 Google Cloud 리전으로 트래픽이 전송됩니다. 리전에 용량이 있는 한 가장 가까운 트래픽을 모두 수신합니다. 리전에 용량이 없으면 용량이 있는 그 다음으로 가장 가까운 리전으로 초과 트래픽이 오버플로됩니다. 자세한 내용은 전역 부하 분산을 참조하세요.
  • 리전: 부하 분산기에 의해 특정 리전으로 트래픽이 전송됩니다. 트래픽은 영역에서 사용 가능한 제공 용량에 비례해서 영역 간에 부하 분산됩니다. 자세한 내용은 리전 부하 분산을 참조하세요.
  • Zonal: 특정 영역에 대해 트래픽이 결정된 후 부하 분산기가 해당 영역 내의 백엔드 간에 트래픽을 고르게 분산합니다. 기존 TCP 연결 및 세션 지속성 설정이 보존되므로, 이후 요청은 백엔드 포드가 정상인 한 동일한 백엔드로 전송됩니다. 자세한 내용은 영역 부하 분산을 참조하세요.

전역 부하 분산 및 트래픽 오버플로

고유 클러스터에서 다음 개념을 시도하려면 용량 기반 부하 분산을 참조하세요.

정상 조건에서는 트래픽이 클라이언트에 가장 가까운 백엔드로 전송됩니다. 트래픽이 클라이언트에 가장 가까운 Google 접속 지점(PoP)에서 종료되고, 네트워크 지연 시간으로 결정된 대로 가장 가까운 백엔드에 도달할 때까지 Google 백본을 순회합니다. 리전의 백엔드에 남은 용량이 없으면 용량이 있는 정상 백엔드를 포함하는 그 다음으로 가장 가까운 클러스터로 트래픽이 오버플로됩니다. 영역 내에서 백엔드 포드 중 50% 미만이 비정상이면 구성된 용량에 관계없이 트래픽이 다른 영역 또는 리전으로 점차적으로 장애 조치됩니다.

트래픽 오버플로는 다음 조건에서만 발생합니다.

  • 멀티 클러스터 게이트웨이를 사용 중입니다.
  • 멀티 클러스터 게이트웨이로 관리되는 여러 클러스터에 동일한 서비스가 배포되어 있습니다.
  • 한 클러스터에서 트래픽이 서비스 용량을 초과하지만, 다른 클러스터에서는 그렇지 않은 방식으로 서비스 용량이 구성되어 있습니다.

다음 다이어그램은 트래픽 오버플로를 사용해서 전역 부하 분산이 작동하는 방법을 보여줍니다.

트래픽 오버플로를 사용하는 전역 부하 분산

다이어그램에서:

  • 멀티 클러스터 게이트웨이가 store 서비스에 대해 전역 인터넷 부하 분산을 제공합니다. 이 서비스는 us-west1 및 europe-west1의 2개의 GKE 클러스터에 배포되어 있습니다. 각 클러스터는 2개의 복제본을 실행합니다.
  • 각 서비스는 max-rate-per-endpoint="10"으로 구성되어 있습니다. 즉, 각 서비스는 각 클러스터에서 2개 복제본 * 10 RPS = 20 RPS의 총 용량을 갖습니다.
  • 북미 지역의 Google PoP는 6 RPS를 수신합니다. 모든 트래픽이 us-west1의 GKE 클러스터인, 용량이 있는 가장 가까운 정상 백엔드로 전송됩니다.
  • 유럽 PoP에는 30 누적 RPS가 수신됩니다. 가장 가까운 백엔드는 europe-west1에 있지만 용량이 20 RPS뿐입니다. us-west1의 백엔드에 초과 용량이 있기 때문에 총 16 RPS를 수신하고 각 포드에 8 RPS를 분산할 수 있도록 10 RPS가 us-west1로 오버플로됩니다.

트래픽 오버플로 방지

트래픽 오버플로는 성능이나 가용성에 영향을 줄 수 있는 애플리케이션 용량을 초과하지 않도록 방지하는 데 도움이 됩니다.

하지만 트래픽을 오버플로하지 않아야 할 수 있습니다. 예를 들어 지연 시간에 민감한 애플리케이션은 훨씬 멀리 있는 백엔드로 트래픽을 오버플로하는 이점이 없을 수 있습니다.

트래픽 오버플로를 방지할 수 있는 방법은 다음과 같습니다.

  • 단일 클러스터에서만 서비스를 호스팅할 수 있는 단일 클러스터 게이트웨이만 사용합니다.
  • 멀티 클러스터 게이트웨이를 사용하더라도 여러 클러스터에 배포된 애플리케이션의 복제본을 개별 서비스로 배포할 수 있습니다. 게이트웨이 관점에서 이 방식은 멀티 클러스터 부하 분산을 지원하지만, 클러스터 간 서비스의 모든 엔드포인트를 집계하지 않습니다.
  • 꼭 필요하지 않은 한 트래픽 용량이 실질적으로 초과되지 않도록 서비스 용량을 충분히 높은 수준으로 설정합니다.

리전 내 부하 분산

리전 내에서 트래픽은 사용 가능한 백엔드 용량에 따라 영역 간에 분산됩니다. 여기에서는 오버플로를 사용하는 대신 각 영역에서 서비스 용량에 직접 비례해서 부하 분산을 수행합니다. 모든 개별 흐름이나 세션이 항상 일관적인 단일 백엔드 포드로 전송되고 분할되지 않습니다.

다음 다이어그램은 리전 내에서 트래픽이 분산되는 방법을 보여줍니다.

리전 내 트래픽 분산

다이어그램에서:

  • 서비스가 리전별 GKE 클러스터에 배포됩니다. 서비스에는 영역 간에 고르게 배포되는 4개 포드가 있습니다. 3개 포드는 영역 A에 있고 1개 포드는 영역 B에 있습니다. 영역 C에는 포드가 없습니다.
  • 이 서비스는 max-rate-per-endpoint="10"으로 구성되었습니다. 영역 A는 총 용량이 30 RPS이고, 영역 B는 10 RPS, 영역 C는 포드가 없으므로 0 RPS입니다.
  • 이 게이트웨이는 여러 클라이언트에서 총 16 RPS 트래픽을 수신합니다. 이 트래픽은 각 영역의 남은 용량에 비례해서 영역 간에 분산됩니다.
  • 개별 소스 또는 클라이언트에서의 트래픽 흐름은 세션 지속성 설정에 따라 단일 백엔드 포드로 일관적으로 부하 분산됩니다. 트래픽 분산은 여러 소스 트래픽 흐름 간에 분할되므로 모든 개별 흐름이 분할되지 않습니다. 따라서 백엔드 간에 트래픽을 세부적으로 분산하려면 최소한의 소스 또는 클라이언트 다양성이 필요합니다.

예를 들어 수신 트래픽이 16 RPS에서 60 RPS로 급증하면 다음 시나리오 중 하나가 발생합니다.

  • 단일 클러스터 게이트웨이를 사용하는 경우에는 이 트래픽이 오버플로되는 다른 클러스터 또는 리전이 없습니다. 수신 트래픽이 총 용량을 초과하더라도 상대적인 영역별 용량에 따라 트래픽이 계속 분산됩니다. 그 결과 영역 A는 45 RPS를 수신하고 영역 B는 15 RPS를 수신합니다.
  • 여러 클러스터 간에 서비스가 분산된 멀티 클러스터 게이트웨이를 사용하는 경우에는 전역 부하 분산 및 트래픽 오버플로에 설명된 대로 다른 클러스터 및 다른 리전으로 트래픽이 오버플로될 수 있습니다. 영역 A가 30 RPS를 수신하고, 영역 B가 10 RPS를 수신하고, 20 RPS가 또 다른 클러스터로 오버플로됩니다.

영역 내 부하 분산

트래픽이 영역으로 전송된 다음 해당 영역 내의 모든 백엔드 간에 고르게 분산됩니다. HTTP 세션은 세션 어피니티 설정에 따라 지속됩니다. 백엔드를 사용할 수 없게 된 경우를 제외하고, 기존 TCP 연결은 다른 백엔드로 이동하지 않습니다. 즉, 제한된 용량으로 인해 새 연결이 오버플로되더라도 장기적으로 지속되는 연결은 계속 같은 백엔드 포드로 연결됩니다. 부하 분산기는 새 연결보다 기존 연결을 우선적으로 유지합니다.

서비스 용량

서비스 용량을 사용하면 한 서비스에서 포드별 초당 요청(RPS) 값을 정의할 수 있습니다. 이 값은 서비스가 수신할 수 있는 평균적인 포드별 최대 RPS를 나타냅니다. 이 값은 서비스에서 구성할 수 있으며 트래픽 기반 자동 확장 및 용량 기반 부하 분산을 결정하기 위해 사용됩니다.

요구사항

서비스 용량에 대한 요구사항 및 제한사항은 다음과 같습니다.

  • 트래픽 기반 자동 확장 또는 멀티 클러스터 게이트웨이를 사용하는 경우에만 부하 분산에 영향을 줍니다. 이러한 기능을 사용하지 않으면 서비스 용량이 네트워크 트래픽에 영향을 주지 않습니다.

서비스 용량 구성

서비스 용량을 구성하려면 networking.gke.io/max-rate-per-endpoint 주석을 사용해서 서비스를 만듭니다. 다음 매니페스트는 최대 RPS가 있는 서비스를 기술합니다.

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

RATE_PER_SECOND는 이 서비스에서 단일 포드가 수신해야 하는 초당 최대 HTTP/HTTPS 요청으로 바꿉니다.

max-rate-per-endpoint 값은 서비스에서 포드 수에 따라 서비스에 대해 동적 용량을 만듭니다. 총 서비스 용량 값은 다음 수식에 설명된 것처럼 max-rate-per-endpoint 값에 복제본 수를 곱하여 계산됩니다.

Total Service capacity = max-rate-per-endpoint * number of replicas

자동 확장 처리가 서비스 내에서 포드 수를 수직 확장하면 그에 따라 서비스의 총 용량이 계산됩니다. 서비스가 0개 포드로 축소되면 용량이 0이 되고 부하 분산기로부터 트래픽을 수신하지 않습니다.r.

서비스 용량 및 독립형 NEG

독립형 NEG를 사용할 때 서비스 용량을 구성할 수도 있지만 이 경우에는 max-rate-per-endpoint 주석을 사용하지 않습니다. 독립형 NEG를 사용할 때는 백엔드 서비스 리소스에 NEG를 추가할 때 max-rate-per-endpoint가 수동으로 구성됩니다. gcloud compute backend-services add- backend 명령어를 사용할 때 --max-rate-per-endpoint 플래그는 각 NEG에 대해 용량을 개별적으로 구성할 수 있습니다.

이 기능은 다음과 같은 워크플로에 유용할 수 있습니다.

독립형 NEG를 사용해서 서비스 용량을 구성할 때 기능적인 차이는 없습니다. 트래픽 자동 확장 및 트래픽 스필오버가 모두 지원됩니다.

서비스 용량 결정

max-rate-per-endpoint 값을 결정하기 위해서는 애플리케이션 성능 특성과 부하 분산 목표에 대한 이해가 필요합니다. 애플리케이션 성능 특성을 정의할 때는 다음과 같은 전략이 도움이 될 수 있습니다.

  • 서비스 용량 없이 구성된 경우 테스트 및 프로덕션 환경 모두에서 애플리케이션을 관찰합니다.
  • Cloud Monitoring을 사용해서 트래픽 요청과 성능 서비스 수준 목표(SLO) 사이에 상관관계를 만듭니다.
  • 애플리케이션에 대해 성능 SLO를 정의합니다. '불량' 또는 '불안정' 성능으로 고려하는 대상에 따라 다음 중 하나 이상일 수 있습니다. 다음 항목 모두 Cloud Monitoring 부하 분산기 측정항목에서 수집할 수 있습니다.
    • 응답 오류 코드
    • 응답 또는 총 지연 시간
    • 백엔드 비정상 또는 다운타임
  • 테스트 및 프로덕션 환경 모두에서 애플리케이션의 트래픽 로드를 관찰합니다. 테스트 환경에서는 트래픽이 증가할 때 여러 성능 측정항목에 어떤 영향을 주는지 확인할 수 있도록 요청 부하를 늘려서 애플리케이션에 스트레스를 줍니다. 프로덕션 환경에서는 실제 트래픽 패턴 수준을 관찰합니다.

기본 서비스 용량

GKE 리소스에 연결된 모든 서비스에는 주석을 사용하여 명시적으로 구성되지 않은 경우에도 기본 서비스 용량이 구성되어 있습니다. 자세한 내용은 기본 서비스 용량을 참조하세요.

다음 표에서는 이러한 기본 용량에 대해 설명합니다.

부하 분산 리소스 유형 기본 max-rate-per-endpoint
인그레스(내부 및 외부) 1 RPS
게이트웨이(모든 GatewayClasses) 100,000,000 RPS
MultiClusterIngress 100,000,000 RPS

트래픽 기반 자동 확장

트래픽 기반 자동 확장은 포드 자동 확장을 위해 부하 분산기의 트래픽 신호를 고유하게 통합하는 GKE 기능입니다. 트래픽 기반 자동 확장은 단일 클러스터 게이트웨이에서만 지원됩니다.

트래픽 기반 자동 확장을 사용하려면 부하 분산기 트래픽 기반 자동 확장을 참조하세요.

트래픽 기반 자동 확장의 이점은 다음과 같습니다.

  • CPU 또는 메모리 제한이 엄격하지 않은 애플리케이션은 CPU 또는 메모리 사용량에 반영되지 않는 용량 제한이 있을 수 있습니다.
  • 경우에 따라 트래픽 또는 초당 요청 수(RPS)는 페이지 조회 수 또는 일일 활성 사용자(DAU)와 같은 앱 사용량 및 비즈니스 측정항목에 따라 조정되므로 이해하기 쉬운 측정항목입니다.
  • 트래픽은 지행 지표인 CPU 또는 메모리와 비교되는 순간적인 수요를 나타내는 선행 지표입니다.
  • CPU, 메모리, 트래픽 자동 확장 측정항목을 조합해서 용량이 적절히 프로비저닝되었는지 확인하기 위해 여러 차원을 사용하는 총체적인 애플리케이션 자동 확장 방법을 얻을 수 있습니다.

다음 다이어그램은 트래픽 기반 자동 확장의 작동 방법을 보여줍니다.

트래픽 기반 자동 확장

다이어그램에서:

  • 서비스 소유자가 배포에 대한 서비스 용량 및 대상 사용률을 구성합니다.
  • 게이트웨이가 store 서비스로 전달되는 클라이언트 트래픽을 수신합니다. 게이트웨이가 GKE 포드 자동 확장 처리로 사용률 원격 분석을 전송합니다. 사용률은 포드에 구성된 용량으로 나눈 개별 포드로 수신되는 실제 트래픽과 동일합니다.
  • GKE 포드 자동 확장 처리는 구성된 대상 사용률에 따라 포드를 확장 또는 축소합니다.

자동 확장 동작

다음 다이어그램에서는 부하 분산기를 통해 10 RPS를 수신하는 애플리케이션에서 트래픽 기반 자동 확장이 작동하는 방식을 보여줍니다.

10 RPS를 사용하는 트래픽 기반 자동 확장

다이어그램에서 서비스 소유자는 저장소 서비스 용량을 10 RPS로 구성했습니다. 즉, 각 포드가 최대 10 RPS를 수신할 수 있습니다. averageUtilization으로 구성된 HorizontalPodAutoscaler는 70으로 설정되었습니다. 즉, 대상 사용률이 포드당 10 RPS의 70%입니다.

자동 확장 처리는 다음 등식을 달성하기 위해 복제본 확장을 시도합니다.

replicas = ceiling[ current traffic / ( averageUtilization * max-rate-per-endpoint) ]

다이어그램에서 이 등식은 다음과 같이 계산됩니다.

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

트래픽 10 RPS로 2개 복제본이 발생합니다. 각 복제본은 6 RPS를 받고, 이것은 대상 사용률 7 RPS보다 낮습니다.

트래픽 분할

트래픽 분할에는 가중치라고 부르는, 서비스로 전송되는 HTTP 요청의 비율을 정의하는 명시적 비율이 사용됩니다. HTTPRoute 리소스를 통해 서비스 목록에 가중치를 구성할 수 있습니다. 서비스 간 상대적 가중치에 따라 서비스 간 트래픽 분할을 정의합니다. 이것은 출시를 수행하거나 변경사항을 테스트할 때 또는 긴급 상황에 트래픽을 분할하는 데 유용합니다.

다음 다이어그램에서는 예시 트래픽 분할 구성을 설명합니다.

트래픽 분할 구성

다이어그램에서:

  • 서비스 소유자는 트래픽 90%를 store-v1로, 10%를 store-v2로 분할하는 규칙에 따라 단일 경로에 대한 2개 서비스를 구성합니다.
  • 게이트웨이가 저장소 애플리케이션의 URL로 이동하는 클라이언트로부터 트래픽을 수신하고 구성된 규칙에 따라 트래픽이 분할됩니다. 트래픽의 90%는 store-v1로, 10%는 store-v2로 라우팅됩니다.

트래픽 분할은 동일 클러스터에 있는 서비스 간에 지원되며 다른 클러스터의 서비스 간에도 지원됩니다.

  • 서비스 간 트래픽 분할: 애플리케이션 버전 출시를 위한 트래픽 분할에 사용됩니다. 트래픽 분할 예시를 사용하면 개별 배포 2개(store-v1 및 store-v2)가 사용되며 각 배포에는 고유 서비스 store-v1 및 store-v2가 포함됩니다. 가중치는 store-v2가 완전 출시될 때까지 점진적으로 트래픽을 전환하도록 두 서비스 간에 구성됩니다.

  • ServiceImports 간 트래픽 분할: 유지보수, 마이그레이션, 긴급 상황을 위해 특정 클러스터에 대한 트래픽 전환에 사용됩니다. ServiceImports는 멀티 클러스터 서비스를 나타내며, 여러 클러스터의 여러 서비스 간에 트래픽 분할을 가능하게 해줍니다. 게이트웨이를 사용한 파란색-녹색 멀티 클러스터 라우팅 연습에서는 클러스터 간 트래픽 분할을 보여줍니다.

가중치와 용량 비교

가중치와 용량은 둘 다 트래픽이 서로 다른 서비스로 전송되는 방식을 제어합니다. 효과가 비슷하지만 작동 방식이 다르고 사용 사례도 다릅니다. 이 두 가지는 여러 목적에 따라 함께 사용될 수 있습니다.

가중치

가중치는 명시적인 트래픽 제어 방식입니다. 가중치는 수신되는 트래픽 및 백엔드 사용률에 관계없이 정확한 트래픽 비율을 정의합니다. 트래픽 분할 예시에서는 store-v2가 초과 용량이거나 모든 복제본이 실패하더라도 트래픽의 10%가 여전히 store-v2에 할당되어, 트래픽이 삭제될 수 있습니다. 이것은 가중치가 사용률 또는 상태에 따라 트래픽 비율을 변경하지 않기 때문입니다.

가중치가 적합한 사용 사례는 다음과 같습니다.

  • 출시를 위해 서비스의 여러 버전 간 트래픽 전환
  • 명시적 트래픽 분할을 사용하여 서비스를 수동으로 온보딩
  • 긴급 또는 유지보수 목적으로 백엔드 집합 외부로 트래픽 전환

용량

용량은 암시적인 트래픽 제어 방식입니다. 용량은 수신되는 트래픽의 양, 백엔드 사용률, 트래픽의 소스 위치에 종속되므로 트래픽 비율을 간접적으로 정의합니다. 용량은 서비스에 내제된 속성이며 일반적으로 자주 업데이트되지 않습니다.

용량이 적합한 사용 사례는 다음과 같습니다.

  • 트래픽 급증 시 백엔드 초과 사용 방지
  • 트래픽과 관련된 자동 확장 비율 제어

트래픽 오버플로를 위한 서비스 용량 구성이 항상 원하는 결과를 가져오는 동작은 아닐 수 있습니다. 전역 부하 분산 예시를 고려해보세요. 서비스 용량은 트래픽을 오버플로해서 백엔드가 초과 사용되지 않도록 보호하지만, 요청이 더 멀리 떨어진 리전을 경유하므로 오버플로된 요청의 지연 시간이 늘어날 수 있습니다.

애플리케이션이 초과 사용에 대해 심하게 민감하지 않으면 트래픽이 다른 리전으로 오버플로되지 않도록 서비스 용량을 매우 높게 구성할 수 있습니다. 애플리케이션의 가용성 또는 지연 시간이 초과 사용에 민감한 경우에는 초과 사용된 백엔드에서 과도한 트래픽을 흡수하는 것보다 다른 클러스터 또는 리전으로 트래픽을 오버플로하는 것이 더 나을 수 있습니다. 애플리케이션의 서비스 용량 구성 방법은 서비스 용량 결정을 참조하세요.

다음 단계