스로틀링 패턴

애플리케이션 인스턴스, 개별 테넌트 또는 전체 서비스에서 사용할 수 있는 리소스를 제한합니다. 이렇게 하면 시스템이 갑작스러운 부하나 지속적인 부하 상황에서도 정상적으로 작동할 수 있고 서비스 수준 목표(SLO)를 충족할 수 있습니다.

컨텍스트 및 문제점

클라우드 애플리케이션의 로드는 활성 사용자 및 해당 활동에 따라 시간에 따라 달라집니다. 업무 시간 동안 더 많은 사용자가 로그인하고 시스템은 매월 말에 계산 비용이 많이 드는 분석을 실행합니다. 갑작스런 버스트도 발생합니다. 처리 수요가 사용 가능한 용량을 초과하면 시스템이 느려지거나 실패합니다. 시스템에 합의된 서비스 수준이 있는 경우 해당 오류는 SLO를 위반합니다.

여러 전략은 애플리케이션의 비즈니스 목표에 따라 다양한 부하를 처리합니다. 한 가지 전략은 프로비전된 리소스를 현재 수요와 일치시키고 비용을 제어하는 자동 크기 조정입니다. 그러나 새 리소스를 프로비전하는 데는 시간이 걸리고 비용이 추가됩니다. 용량 증가 또는 예산을 초과하는 수요는 리소스 적자를 만듭니다.

해결 방법

자동 크기 조정의 대안은 사용량이 해당 한도를 초과할 때 리소스 사용을 제한하고 요청을 제한하는 것입니다. 워크로드는 자체 리소스 사용을 모니터링하고 사용량이 임계값을 초과할 때 하나 이상의 사용자의 요청을 제한합니다. 시스템은 계속 작동하며 해당 SLO를 충족합니다.

스로틀링은 단일 승인 결정이 아니라 제어 루프입니다. 시스템에는 인프라 사용률, 애플리케이션 상태 및 주별 카운터의 세 가지 계층에서 대기 시간이 짧은 신호가 필요합니다. 지속적으로 채도를 측정하고, 잘 정의된 경계에서 제한을 적용하고, 트래픽 패턴이 변경되면 해당 제한을 조정합니다. 오버로드는 완성도가 높은 시스템에서 감지하고 복구하는 정상적인 운영 모드입니다. 스로틀링은 워크로드에 자기 보호 기능을 제공합니다.

시스템은 다음과 같은 여러 스로틀링 또는 관련 전략을 적용할 수 있습니다.

  • 주체별 속도 제한: 정의된 창에서 구성된 속도를 이미 초과한 사용자의 요청을 거부합니다. 이 전략을 사용하려면 시스템이 각 요청을 하나의 보안 주체에 귀속시키고, 해당 보안 주체를 기준으로 리소스 사용량을 측정해야 합니다. 다중 테넌트 워크로드의 경우 각 테넌트의 사용량 측정을 참조하세요.

  • 점진적 기능 축소: 필수 기능에 충분한 리소스가 있도록 비필수 기능을 끄거나 기능을 제한합니다. 이 전략은 가용성에 대한 응답 완전성을 거래합니다. 예를 들어 비디오 스트리밍 애플리케이션은 더 낮은 해상도로 떨어질 수 있습니다.

  • 부하 평준화: 큐를 사용하여 작업 볼륨 을 부드럽게 합니다. 다중 테넌트 환경에서 평준화는 모든 테넌트의 성능을 감소시킵니다. 테넌트에 다른 SLA(서비스 수준 계약)가 있는 경우 높은 가치의 테넌트에 대한 프로세스 작업이 즉시 수행되고 백로그가 완화될 때까지 우선 순위가 낮은 작업을 유지합니다. 우선 순위 큐 패턴을 사용하거나 각 우선 순위 계층에 대해 별도의 엔드포인트를 노출하여 이 방법을 구현합니다.

  • 우선 순위 기반 지연: 우선 순위가 낮은 애플리케이션 또는 테넌트 대신 작업을 연기합니다. 작업을 일시 중단하거나 제한하고 나중에 다시 시도하도록 테넌트에 지시하는 예외를 반환합니다.

  • 아웃바운드 속도 제한: 외부 종속성이 실패하거나 오류를 반환할 때 고유한 아웃바운드 호출을 제한합니다. 홍수 로그를 중지하고 비정상 종속성에 대한 재시도 비용을 방지하기 위해 기내 요청 수를 낮춥니다. 종속성이 복구된 후 일반 요청 흐름을 복원합니다. 예를 들어 NServiceBus 는 이 기능을 구현합니다.

다음 차트에서는 A, B 및 C라는 세 가지 기능을 사용하는 애플리케이션에 대해 시간 경과에 따른 리소스 사용(메모리, CPU, 대역폭 및 기타 요인의 조합)을 보여 줍니다. 기능은 특정 작업 집합을 수행하는 구성 요소, 복잡한 계산을 수행하는 코드 조각 또는 메모리 내 캐시와 같은 서비스를 제공하는 요소와 같은 특정 기능 영역입니다.

세 명의 사용자를 대신하여 실행되는 애플리케이션의 시간에 대한 리소스 사용을 보여 주는 그래프입니다.

차트는 누적 영역형 차트입니다. 기능 A의 줄 아래 영역에는 기능 A에서 사용하는 리소스가 표시되고, 기능 A와 기능 B 줄 사이의 영역에는 기능 B가 사용하는 리소스가 표시되고, 기능 B와 기능 C 줄 사이의 영역에는 기능 C에서 사용하는 리소스가 표시됩니다. 기능 C의 줄은 스택의 맨 위에 있으므로 시간 경과에 따른 총 시스템 리소스 사용량도 보여 줍니다.

차트는 점진적인 기능 저하를 보여줍니다. T1 시간 직전에 총 리소스 사용량이 임계값에 접근하여 사용 가능한 용량이 소진될 위험이 있습니다. 기능 B는 기능 A 또는 기능 C보다 덜 중요하므로 시스템에서 기능 B를 해제하고 리소스를 해제합니다. T1과 T2 사이에 기능 A와 기능 C는 정상적으로 계속됩니다. T2 시점이 되면 총 리소스 사용량이 기능 B를 다시 켤 수 있을 만큼 감소합니다.

자동 확장, 점진적 성능 저하, 스로틀링을 결합하면 애플리케이션의 응답성을 유지하고 SLA를 준수할 수 있습니다. 수요가 계속 높을 것으로 예상되는 경우, 시스템이 수평 확장되는 동안 스로틀링은 안정성을 유지합니다. 확장이 완료되면 시스템은 전체 기능을 복원합니다.

다음 차트는 시간 경과에 따른 총 리소스 사용량과 스로틀링이 오토스케일링 및 기타 보완 제어 기능과 어떻게 함께 작동하는지를 보여 줍니다.

스로틀링과 자동 확장을 결합했을 때의 효과를 보여 주는 그래프입니다.

T1 시 시스템은 소프트 한도에 도달하여 규모 확장이 시작됩니다. 새 리소스가 정시에 도착하지 않으면 수요가 기존 리소스를 소진할 수 있으며 시스템이 실패할 수 있습니다. 스로틀링은 스케일 아웃 중에 초과 요청을 거부해 리소스 사용량을 엄격한 한도 이하로 유지한 다음, 새 용량이 가동되면 해당 제한을 해제합니다.

Tip

Edge 컨트롤과 스로틀링 패턴은 각기 다른 문제를 해결합니다. Azure DDoS Protection 및 WAF(웹 애플리케이션 방화벽) 속도 제한 규칙과 같은 에지 컨트롤은 네트워크 경계에서 실행되고 애플리케이션에 도달하기 전에 볼륨 또는 악성 트래픽을 삭제합니다. 스로틀링 패턴은 애플리케이션 내부에서 실행되며 애플리케이션에서 정의한 한도에 따라 정상 트래픽을 조절합니다. 두 계층을 함께 사용합니다. DDoS 보호는 합법적인 사용자가 서비스를 오버로드하는 것을 막지 않으며 애플리케이션 제한은 대량 공격을 흡수하지 않습니다.

문제 및 고려 사항

이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.

  • 스로틀링 결정은 초기에 내리세요. 스로틀링은 전체 시스템에 영향을 미치는 아키텍처적 결정입니다. 나중에 개조하는 것은 비용이 많이 듭니다.

  • 스로틀링 한도를 가장 먼저 포화되는 구성 요소에 맞추세요.

    요청 속도는 제한하기에 가장 친숙한 차원이지만 실제 병목 상태는 종종 동시 진행 중인 요청, 큐 깊이, CPU 또는 메모리 사용률 또는 다운스트림 종속성의 자체 제한입니다. 초당 요청 수 제한은 팬아웃 지점에서 동시성이 병목인 시스템을 보호하지 못합니다.

    게이트웨이, 서비스, 파티션 또는 다운스트림 종속성과 같은 각 제한 적용 경계에서 먼저 포화되는 대상을 식별하고 해당 차원에 대한 제한을 설정합니다. 팬아웃 지점의 동시성 제한 보호에 대해서는 스로틀링을 보완하는 Bulkhead pattern을 참조하세요.

  • 의도적으로 제한 알고리즘을 선택합니다. 보호하려는 구성 요소의 허용 오차에 맞추세요.

    알고리즘 동작 방식 및 최적의 적합성
    토큰 버킷 구성된 크기까지 버스트를 지원하고 안정적인 리필 속도를 적용합니다. 순간적인 급증을 흡수해야 하는 게이트웨이에 사용합니다.
    새는 버킷 일정한 속도로 내보낸다. 안정적인 수신 속도가 필요한 백 엔드에 사용합니다.
    고정 창 구현은 간단하지만 윈도우 경계에서 연속 버스트를 허용합니다.
    슬라이딩 윈도우 상태 정보를 더 많이 필요로 하는 대신, 고정 윈도우의 윈도우 경계 문제를 완화합니다.

  • 제한에 영향을 미치는 사람을 결정합니다. 지역 게이트웨이와 같은 거친 경계에서의 제한은 일부 사용자만 부하를 구동할 때 관련 없는 많은 사용자에게 영향을 줄 수 있습니다.

  • 한 제한이 여러 노드에 걸쳐 있을 때 카운터가 상주하는 위치를 결정합니다. 동일한 호출자가 여러 복제본에 도달하면 로컬 카운터는 빠르지만 언더카운트입니다. Redis와 같은 공유 저장소의 중앙 집중식 카운터는 모든 요청을 볼 수 있지만 각 결정에 대기 시간을 추가합니다. 글로벌 속도를 근사화하려면 복제본 간에 제한을 나누고 주기적으로 조정합니다.

  • 스로틀링 결정을 빠르게 내리세요. 시스템은 상승하는 부하를 감지하고, 반응하고, 부하가 완화된 후 정상으로 돌아가야 합니다. 이 프로세스에는 지속적인 성능 계측이 필요합니다.

  • 붕괴 직전에 몰려서가 아니라, 미리 부하를 차단하세요. 구성 요소가 포화 상태에 이른 뒤에야 요청을 거부하는 스로틀은 호출자에게 역압이 걸리기 전에 대기 시간이 급증하게 합니다.

    사용률이 하드 제한에 가까워지면 증가하는 요청 비율을 거부하기 시작합니다. 조기 거부는 호출자에게 요청을 줄이도록 신호를 보내고, 갑작스러운 제한이 흔히 유발하는 지연 시간 붕괴를 방지합니다. SLO를 기준으로 p99 지연 시간을 주요 트리거로 사용합니다. p99는 이미 임계치를 넘었는데도 평균 사용률은 정상으로 보일 수 있습니다.

    요청의 가치를 구분할 수 있다면, 가치가 낮거나 재시도하기 쉬운 작업부터 우선적으로 버리세요. 자세한 내용은 우선 순위 큐 패턴을 참조하세요.

  • 임시 거부가 제한의 결과인 경우 클라이언트에 알리는 상태 코드를 반환합니다.

    • HTTP 429(요청이 너무 많음): 호출자가 정의된 창에 대해 구성된 요청 속도를 초과합니다.
    • HTTP 503(서비스를 사용할 수 없음): 서비스는 예기치 않은 부하 급증으로 인해 현재 요청을 처리할 수 없습니다.

    클라이언트가 Retry-After 재시도 전략을 선택할 수 있도록 HTTP 헤더를 포함합니다. 호출자가 추측하는 대신 의도적으로 다시 시도할 수 있는 충분한 컨텍스트를 반환합니다. 예를 들어 호출자가 초과하는 제한의 이름을 지정하거나, 영향을 받는 범위를 명확히 지정하거나, 성공할 속도를 제안합니다. 설명할 수 없는 거부는 발신자가 적응하는 데 도움이 되지 않습니다.

  • 의존성의 과부하 신호를 흡수하지 말고 전파하세요. 호출자의 요청 속도를 제한하는 서비스는 자체 다운스트림 종속 서비스로부터 받는 스로틀링 응답도 준수해야 합니다. 서비스가 조용히 재시도하거나 일반적인 HTTP 500(내부 서버 오류) 응답을 반환해 다운스트림의 429 또는 503 상태 응답을 숨기면, 호출 측은 요청 속도를 낮출 수 없고 재시도는 증폭되며 과부하가 다시 업스트림으로 연쇄 전파됩니다. 다시 시도 Storm 안티패턴이 이 실패 모드를 설명합니다. 호출 체인 전체가 함께 부하를 줄일 수 있도록 업스트림 호출자에게 역압을 전파하세요.

  • 거부 비용이 그것이 막아 주는 작업 비용보다 더 적게 들게 하십시오. 요청을 거부하려면 인증, 심층 구문 분석 또는 복잡한 정책 평가가 필요한 경우 거부된 요청의 홍수가 여전히 시스템을 포화시킬 수 있습니다. 요청 파이프라인에서 가능한 한 빨리 거부하고 부하를 테스트하여 거부 경로 자체를 테스트합니다.

  • 스로틀링으로 자동 스케일링에 필요한 충분한 시간을 벌 수 없는 경우에 대비하세요. 새 용량이 온라인 상태가 되는 것보다 수요가 더 빠르게 증가하는 경우 제한된 시스템조차도 실패할 수 있습니다. 해당 결과가 허용되지 않는 경우 더 큰 용량 예약을 유지하고 보다 적극적인 자동 크기 조정을 구성합니다.

  • 캐싱을 스로틀링의 대체 수단으로 사용하지 마세요. 캐시는 원본의 평균 부하를 낮추지만 최대 부하를 바인딩하지는 않습니다. 모든 캐시 미스는 오리진 서버로 그대로 전달되고, 트래픽이 많은 상황에서 요청이 많은 키가 만료되면 여러 호출자가 이를 다시 채우려고 동시에 몰릴 수 있습니다. 캐싱을 사용해 평상시 부하를 줄이고, 스로틀링으로 최악의 경우를 제한합니다. 자세한 내용은 Cache-Aside 패턴을 참조하세요.

  • 서로 다른 작업은 일반적으로 동일한 실행 비용이 들지 않으므로 리소스 비용을 정규화하세요. 예를 들어 읽기 작업의 경우 제한 한도가 더 높고 쓰기 작업의 경우 더 낮을 수 있습니다. 작업당 비용을 무시하면 용량이 소진되고 공격 벡터가 생성됩니다.

  • 스로틀링 구성을 런타임에 변경할 수 있게 합니다. 비정상적인 부하가 도착하면 배포 없이 제한을 조정해야 합니다. 인시던트 발생 중에는 배포는 느리고 위험합니다. 외부 구성 저장소 패턴은 런타임에 변경할 수 있도록 구성을 외부화합니다.

  • 정적 제한 대신 적응형 제한을 고려합니다. 일부 스로틀링 SDK는 대기 시간이나 큐 길이 신호에 반응하여 제한값이 실제 구성 요소 상태를 반영하도록 합니다. 항상 적응형 리미터를 설정된 최대값과 함께 사용하세요.

  • 워크로드가 진화함에 따라 한도를 다시 검토합니다. 적응형 리미터는 SLO 변경, 종속성 용량 변경 또는 작업당 비용 변동과 같은 모든 종류의 드리프트를 추적할 수 없습니다. 해당 입력을 기준으로 정기적인 운영자 검토를 예약하세요.

이 패턴을 사용하는 경우

다음 패턴을 사용합니다.

  • 시스템을 SLO 범위 내에서 유지하기 위해

  • 단일 테넌트가 애플리케이션 리소스를 독점하지 못하도록 합니다.

  • 갑작스러운 작업 증가를 처리합니다.

  • 시스템에 필요한 최대 리소스 수준을 제한합니다.

  • 높은 그리드 탄소 강도의 기간 동안 낮은 값 컴퓨팅을 줄이기 위해.

워크로드 디자인

워크로드 설계에서 스로틀링 패턴을 사용하여 Azure Well-Architected Framework 핵심 원칙에서 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.

핵심 요소 이 패턴으로 핵심 목표를 지원하는 방법
안정성 설계 결정을 통해 워크로드가 오작동에 대한 복원력을 높일 수 있으며 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 할 수 있습니다. 오작동으로 이어질 수 있는 리소스 소모를 방지하기 위해 제한을 디자인합니다. 이 패턴을 정상적인 성능 저하 계획에서 제어 메커니즘으로 사용할 수도 있습니다.

- RE:07 자기 보존
보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. 시스템의 자동화된 남용으로 인해 발생할 수 있는 리소스 소모를 방지하기 위해 제한을 디자인할 수 있습니다.

- SE:06 네트워크 컨트롤
- SE:08 강화 리소스
비용 최적화는 워크로드의 투자 수익률을 유지하고 개선하는 데 중점을 둡니다. 적용된 제한은 비용 모델링을 알리고 애플리케이션의 비즈니스 모델에 직접 연결할 수 있습니다. 또한 리소스 크기 조정에 고려될 수 있는 사용률에 명확한 상한을 적용합니다.

- CO:02 비용 모델
- CO:12 크기 조정 비용
성능 효율성은 크기 조정, 데이터 및 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족 하는 데 도움이 됩니다. 시스템이 수요가 많은 경우 이 패턴은 성능 병목 현상으로 이어질 수 있는 혼잡을 완화하는 데 도움이 됩니다. 소란스러운 이웃 문제를 사전에 방지하는 데 사용할 수도 있습니다.

- PE:02 용량 계획
- PE:05 크기 조정 및 분할

이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.

예시

다음 다이어그램은 다중 테넌트 시스템에서의 스로틀링을 보여줍니다.

다중 테넌트 애플리케이션의 스로틀링을 보여 주는 다이어그램.

여러 테넌트 조직의 사용자가 클라우드 호스팅 애플리케이션에 액세스하여 설문 조사를 작성하고 제출합니다. 애플리케이션에는 각 테넌트의 사용자가 요청을 제출하는 속도를 모니터링하는 계측이 포함되어 있습니다.

한 테넌트에서 사용자가 다른 테넌트에 있는 사용자의 응답성 및 가용성을 저하시키는 것을 방지하기 위해 애플리케이션은 단일 테넌트가 제출할 수 있는 초당 요청 속도를 제한합니다. 애플리케이션이 이 한도를 초과하는 요청을 차단합니다.

다음 단계:

  • Last updated on