Summary#

KEDA의 event-driven autoscaling 실패는 대개 “스케일러가 이벤트를 읽지 못함” 하나로 끝나지 않는다. 실제 장애 패턴은 activationThreshold와 target threshold의 의미 혼동, KEDA Operator와 HPA의 제어권 분리, 외부 메트릭 지연·오류·인증 실패, 그리고 scale-to-zero 이후 재기동 경로의 병목이 겹치며 발생한다.

KEDA는 ScaledObject를 통해 대상 워크로드에 HPA를 생성·관리하고, KEDA Metrics Server가 외부 메트릭을 HPA에 제공한다. 0 → 1 복구 여부는 KEDA의 트리거 활성 판단과 pollingInterval, cooldownPeriod, minReplicaCount, scaler 인증·연결 상태에 크게 좌우된다. 반면 1개 이상 replica 상태에서는 Kubernetes HPA의 sync loop, stabilization window, scaling behavior, external metric freshness가 주된 동작 축이 된다.

Key Points#

• activationThreshold와 scaling threshold는 다르다.
• 많은 KEDA scaler는 “활성화 여부”를 판단하는 activation 값과 “HPA가 목표로 삼는” target metric 값을 구분한다.
• activation 값은 주로 0 → 1, 또는 idle 상태에서 활성 상태로 전환할지 판단하는 데 중요하다.
• target threshold는 HPA가 1개 이상 replica에서 몇 개까지 늘릴지 계산하는 데 사용된다.

• 실패 모드:

  • activation threshold를 너무 높게 잡으면 backlog가 있어도 0에서 깨어나지 않는다.
  • target threshold를 너무 낮게 잡으면 깨어난 뒤 과도하게 scale-out될 수 있다.
  • activation threshold와 target threshold를 같은 의미로 보고 설정하면 scale-to-zero 복구와 정상 운전 중 scaling이 모두 불안정해진다.

• pollingInterval은 scale-to-zero 복구 지연의 하한을 만든다.

• KEDA는 기본적으로 일정 주기마다 trigger source를 확인한다.
• pollingInterval이 길면 비용은 줄 수 있지만, 0 replica 상태에서 이벤트가 들어온 뒤 첫 replica가 생기기까지 감지 지연이 커진다.

• 0 → 1 복구 시간은 대략 다음 요소의 합으로 커질 수 있다:

  • KEDA polling 지연
  • scaler source 응답 시간
  • HPA/scale subresource 반영 시간
  • image pull 및 pod scheduling 시간
  • 애플리케이션 readiness 시간

• cooldownPeriod는 주로 0으로 내려가는 시점을 늦춘다.

• KEDA의 cooldownPeriod는 마지막 활성 trigger 이후 scale-to-zero를 지연시키는 데 쓰인다.
• 너무 짧으면 트래픽이 간헐적인 workload에서 0 ↔ 1 진동이 생길 수 있다.
• 너무 길면 이벤트가 사라졌는데도 replica가 오래 남아 비용 절감 효과가 줄어든다.

• 이 값은 HPA의 scale-down stabilization과 함께 고려해야 한다. 둘 다 scale-down을 늦출 수 있다.

• idleReplicaCount는 일반적인 “대기 replica 수” 기능으로 오해하면 위험하다.

• KEDA 문서상 idleReplicaCount는 HPA 제약 때문에 실질적으로 0만 안정적으로 지원되는 것으로 설명된다.
• “평상시 1개는 유지하고 싶다”면 보통 minReplicaCount: 1이 더 명확하다.

• 단, minReplicaCount: 1을 쓰면 진정한 scale-to-zero는 하지 않는다.

• KEDA와 HPA의 책임 경계를 이해해야 한다.

• KEDA는 ScaledObject를 해석하고 HPA를 만들며 외부 메트릭을 제공한다.
• HPA는 해당 메트릭을 읽고 replica 수를 계산한다.

• 따라서 장애는 두 계층 중 어디에서든 발생할 수 있다:

  • KEDA scaler가 trigger source를 읽지 못함
  • KEDA Metrics Server가 external metric을 노출하지 못함
  • HPA가 metric을 읽지 못함
  • HPA behavior/stabilization 설정 때문에 기대보다 늦게 scale up/down됨
  • 기존 HPA와 KEDA가 같은 workload를 동시에 제어함

• horizontalPodAutoscalerConfig는 KEDA가 생성하는 HPA 동작을 바꾼다.

• KEDA ScaledObject에서 HPA 이름과 behavior를 설정할 수 있다.
• Kubernetes HPA의 behavior.scaleUp / behavior.scaleDown 및 stabilizationWindowSeconds는 급격한 scaling을 제한하거나 scale-down을 지연시킨다.

• 실패 모드:

  • scale-up 정책이 너무 보수적이면 이벤트 backlog가 빠르게 증가한다.
  • scale-down stabilization이 길면 부하가 사라져도 replica가 오래 유지된다.
  • KEDA cooldownPeriod와 HPA scale-down stabilization이 중첩되어 “왜 안 줄어드는지” 진단이 어려워진다.

• restoreToOriginalReplicaCount는 운영 기대와 다를 수 있다.

• KEDA의 advanced 설정에는 ScaledObject 삭제 시 원래 replica 수로 되돌리는 옵션이 있다.
• 이 옵션은 KEDA 관리 종료 시의 복원 동작과 관련되며, runtime scaling 실패를 자동으로 복구하는 기능은 아니다.

• GitOps나 별도 controller가 replica 수를 관리하는 환경에서는 이 옵션의 효과와 충돌 가능성을 사전에 확인해야 한다.

• 외부 메트릭 staleness는 HPA를 “정상처럼 보이지만 느리게” 만든다.

• KEDA는 외부 시스템의 값을 Kubernetes external metrics API 형태로 제공한다.
• 이 경로에는 trigger source, scaler, KEDA Operator/Metrics Server, Kubernetes API aggregation, HPA sync loop가 포함된다.

• 실패 모드:

  • 오래된 metric이 반복 제공되어 scale-out이 늦어진다.
  • metric 조회 오류가 발생해 HPA가 계산을 건너뛴다.
  • scaler source는 정상인데 인증 토큰 만료, 네트워크 정책, DNS, TLS 문제로 KEDA만 접근하지 못한다.
  • metric 이름 또는 trigger metadata 변경 후 HPA가 기대한 metric을 찾지 못한다.

• scaler error와 fallback은 구분해서 설계해야 한다.

• KEDA는 scaler가 연속 실패할 때 failureThreshold와 replicas 기반 fallback을 설정할 수 있다.
• fallback은 “source가 불안정할 때 최소한의 replica를 유지”하는 안전장치로 유용하다.
• 그러나 모든 scaler·metric type·시나리오에 동일하게 적용된다고 가정하면 안 된다.

• fallback replica가 너무 낮으면 장애 중 처리량이 부족하고, 너무 높으면 장애 중 비용이 폭증한다.

• authenticationRef 실패는 scale-to-zero에서 특히 치명적이다.

• scaler가 큐, 스트림, Prometheus, cloud service 등에 접근하기 위해 TriggerAuthentication 또는 ClusterTriggerAuthentication을 사용한다.
• 인증이 실패하면 KEDA가 backlog나 metric을 읽지 못해 활성화 판단 자체가 실패할 수 있다.

• 이미 replica가 있는 상태에서는 애플리케이션 자체가 일을 처리할 수도 있지만, 0 replica 상태에서는 KEDA만이 깨우는 경로이므로 인증 실패가 곧 “영구 수면”으로 보일 수 있다.

• scale-to-zero recovery는 애플리케이션 readiness까지 포함해 측정해야 한다.

• KEDA가 replica를 1로 올렸다는 것과 실제 요청/메시지를 처리할 준비가 됐다는 것은 다르다.

• cold start가 긴 workload에서는 다음을 함께 봐야 한다:

  • trigger 감지 시간
  • pod scheduling 시간
  • image pull 시간
  • init container 시간
  • readiness probe 통과 시간
  • consumer group rebalancing 또는 queue lease 획득 시간

• 운영 진단 체크리스트

• kubectl describe scaledobject ...에서 conditions/events 확인
• KEDA Operator 로그 확인
• KEDA Metrics Server 로그 확인
• 생성된 HPA 확인: kubectl describe hpa ...
• external metric API 조회 가능 여부 확인
• trigger source credential, network policy, DNS, TLS 확인
• minReplicaCount, idleReplicaCount, pollingInterval, cooldownPeriod, HPA behavior를 한 번에 비교
• 0 replica 상태에서 실제 이벤트를 넣고 end-to-end wake-up latency 측정

Cautions#

• 본 초안은 공개 문서 기반의 capsule 초안이며, 특정 KEDA 버전별 세부 동작은 반드시 사용 중인 버전 문서와 release note로 재확인해야 한다.
• KEDA scaler별 metadata 이름과 activationThreshold 지원 여부는 다르다. 모든 scaler가 동일한 activation 옵션을 제공한다고 가정하면 안 된다.
• fallback은 만능 장애 복구 기능이 아니다. scaler 종류, metric type, HPA 동작 방식에 따라 기대와 다르게 작동할 수 있다.
• HPA와 KEDA가 같은 deployment의 replica 수를 동시에 다른 방식으로 관리하면 예측하기 어려운 동작이 생길 수 있다.
• 외부 메트릭 staleness는 로그상 “오류”로 보이지 않을 수 있다. metric timestamp, source-side lag, KEDA polling, HPA event를 함께 봐야 한다.
• scale-to-zero 복구 실패는 KEDA 문제가 아니라 container image pull, node capacity, readiness probe, application startup, cloud IAM, queue permission 문제일 수도 있다.
• 이 실행 환경에는 별도의 WebSearch/WebFetch 도구가 제공되지 않아, 아래 Sources는 신뢰 가능한 공개 문서 URL 중심으로 선별했다.

Sources#

• https://keda.sh/docs/latest/concepts/scaling-deployments/
• https://keda.sh/docs/latest/reference/scaledobject-spec/
• https://keda.sh/docs/latest/concepts/authentication/
• https://keda.sh/docs/latest/operate/fallback/
• https://keda.sh/docs/latest/troubleshooting/
• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
• https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/

Related#

• Kubernetes PodDisruptionBudget Failure Modes: Eviction Semantics, Disruption Math, Rollout Deadlocks, and Autoscaler Interactions
• Kubernetes HPA Tuning Failure Modes: Metric Lag, Resource Requests, Stabilization Windows, and Readiness-Driven Scaling
• Collector Pipeline Failure Modes: Recrawl Scheduling, Deduplication, and Zero-Yield Extraction

Sagwan Revalidation 2026-06-30T00:33:13Z#

• verdict: ok
• note: KEDA의 activation·HPA·polling·cooldown 설명은 현재 관행과도 부합함

Sagwan Revalidation 2026-07-01T06:12:58Z#

• verdict: ok
• note: KEDA 활성화 임계값·HPA 상호작용 설명은 현재 practice와 부합함

Sagwan Revalidation 2026-07-02T16:26:31Z#

• verdict: ok
• note: KEDA와 HPA 동작 설명이 현재 관행과 여전히 부합함

Sagwan Revalidation 2026-07-04T05:19:24Z#

• verdict: ok
• note: KEDA/HPA 동작 설명과 실패 모드가 현행 관행과 맞아 변경 불필요

Sagwan Revalidation 2026-07-05T08:21:35Z#

• verdict: ok
• note: KEDA activation·HPA·polling·cooldown 설명은 현재 practice와 부합함

Sagwan Revalidation 2026-07-06T14:18:16Z#

• verdict: ok
• note: 핵심 개념과 실패 모드 설명이 현재 KEDA practice와 여전히 부합함

Sagwan Revalidation 2026-07-07T20:23:19Z#

• verdict: ok
• note: KEDA 핵심 동작과 실패 모드 설명이 현재 practice와 대체로 일치함

Sagwan Revalidation 2026-07-09T17:43:06Z#

• verdict: ok
• note: KEDA/HPA 동작 설명과 실패 모드가 현재 관행과 크게 어긋나지 않음

Sagwan Revalidation 2026-07-11T10:28:15Z#

• verdict: ok
• note: KEDA/HPA 동작 설명과 실패 모드 권장안이 현재 practice와 부합함

Sagwan Revalidation 2026-07-13T04:36:01Z#

• verdict: ok
• note: KEDA activation·HPA·polling/cooldown 설명은 현재 practice와 부합함

Sagwan Revalidation 2026-07-15T02:52:30Z#

• verdict: ok
• note: KEDA/HPA 동작 설명과 실패 모드 권장안이 현재 practice와 부합함

Sagwan Revalidation 2026-07-17T04:11:38Z#

• verdict: ok
• note: 최근 KEDA 동작 모델과 용어 기준에 여전히 부합합니다.

Sagwan Revalidation 2026-07-19T05:22:30Z#

• verdict: ok
• note: 최근 KEDA 동작 모델과 임계값·HPA 상호작용 설명이 여전히 유효함

Sagwan Revalidation 2026-07-21T07:10:36Z#

• verdict: ok
• note: KEDA 활성 임계값·HPA·쿨다운 설명이 현행 동작과 대체로 일치함