Knative 운영 실전: KPA는 무엇을 보고 파드를 늘리는가

서버리스를 쿠버네티스 위에서 한다는 것

웹 서비스의 트래픽은 일정하지 않습니다. 평소에는 한가하다가 특정 시점에 몰리고 이내 가라앉죠. 그런 워크로드에 고정된 수의 서버를 늘 띄워 두는 것은 낭비입니다. 요청이 있을 때 필요한 만큼만 쓰자는 발상이 서버리스이고, 쿠버네티스 위에서 그 발상을 구현하는 대표적인 오픈소스가 Knative입니다.

다만 모든 것을 올릴 수 있는 구조는 아닙니다. Knative의 기본 구성은 0까지 축소하도록 되어 있어서(문서의 기본 ConfigMap에서 enable-scale-to-zero가 true) 파드는 언제든 사라질 수 있고, 그 안의 메모리 상태도 함께 사라집니다. 상태는 애플리케이션 바깥에 두어야 하죠. 그래서 실무에서는 무상태 계층과 상태보존 계층을 처음부터 나눠 운영합니다. 웹과 애플리케이션은 Knative로 민첩하게, 데이터베이스와 캐시는 표준 쿠버네티스의 StatefulSet과 복제로 안정적으로 두는 식입니다. 이 계층 분리는 공식 문서가 규정한 것이 아니라 운영에서 굳어진 배치입니다.

첫째, KPA는 CPU가 아니라 요청 흐름을 본다

일반적인 쿠버네티스 오토스케일링과 Knative의 오토스케일링은 무엇을 보고 판단하는가에서 갈립니다. knative.dev 공식 문서는 두 오토스케일러를 이렇게 구분해요. KPA는 "스케일 투 제로 기능을 지원한다", "CPU 기반 오토스케일링은 지원하지 않는다". 반대로 HPA는 "스케일 투 제로 기능을 지원하지 않는다", "CPU 기반 오토스케일링을 지원한다".

그러면 KPA는 무엇으로 판단할까요. 문서는 KPA가 "시간 기반 창에 걸쳐 집계된 지표(동시성 또는 초당 요청 수)에 따라 동작한다"고 밝힙니다. 문서의 기본 ConfigMap에도 동시성 목표와 초당 요청 수 목표가 나란히 들어 있어요. 어느 쪽이든 CPU는 아니죠.

기준값도 기본 오토스케일러 ConfigMap에 있습니다. 파드당 동시성 목표 기본값은 100, 목표 사용률은 0.7이에요. 문서의 리비전(Revision) 예시에는 autoscaling.knative.dev/target 어노테이션이 등장하고요. 뒤에 나올 감당할 수 있는 양은 이런 목표값과 파드 수로 정해지는 양을 말합니다. 참고로 KPA는 Serving 코어의 일부라 설치 즉시 기본으로 켜져 있고, 클래스 기본값은 kpa.autoscaling.knative.dev예요. HPA로 바꾸려면 autoscaling.knative.dev/class 어노테이션으로 지정합니다.

값을 넣는 자리부터 짚고 가겠습니다. 전역 설정은 knative-serving 네임스페이스의 config-autoscaler ConfigMap이고, 리비전별 설정은 어노테이션이에요. 둘 다 있으면 리비전 설정이 전역 설정을 덮어씁니다. 여기서 실수하기 쉬운 지점이 하나 있습니다. 문서는 서비스나 컨피규레이션으로 리비전을 만들 때 어노테이션을 리비전 템플릿에 넣어야 한다고 안내합니다. 단일 리비전의 최상위 metadata에 넣으면 다른 리비전으로 전파되지 않고 오토스케일링 설정에도 적용되지 않는다고 명시해요. 리비전별로 지정할 수 있는 값은 spec.template.metadata.annotations 자리에 들어가고요. 다만 아래에서 다룰 값 중에도 전역에서만 잡는 것이 섞여 있으니 항목마다 따로 짚겠습니다.

신호를 만드는 것은 queue-proxy입니다. 문서는 "모든 경우에 queue-proxy는 요청 경로에 남는다"고 밝히면서, 이 컴포넌트가 "오토스케일러를 위해 동시 요청 수를 측정한다"고 설명해요. 다만 특히 액티베이터가 요청 경로에서 빠졌을 때 그렇다고 덧붙입니다. 신호원이 하나만은 아니에요. 문서는 용량이 없는 리비전으로 요청이 라우팅되면 액티베이터가 요청을 지연시키고 "추가 용량이 필요하다고 오토스케일러에 신호를 보낸다"고 설명합니다.

같은 문서에 queue-proxy의 다른 역할도 나와요. 요청된 경우 containerConcurrency 하드 리밋을 구현하고, 파드가 종료될 때 새 요청은 거부하되 기존 요청은 계속 처리하는 우아한 종료를 담당하며, 사용자 컨테이너 바깥에서 HTTP 지표와 트레이스를 보고해 인프라가 더한 지연을 따로 측정할 수 있게 하죠. 기동 중에는 사용자 컨테이너를 Kubelet보다 촘촘히 프로브해 더 일찍 요청을 받게 만들고요. 판단 신호가 다르면 관측의 축도 달라집니다. CPU와 메모리만 보고 있으면 KPA가 왜 지금 그만큼의 파드를 띄웠는지 설명할 수 없죠.

둘째, 안정 모드와 패닉 모드가 거동을 가른다

KPA에는 두 개의 모드가 있습니다. 문서의 표현을 그대로 옮기면 "안정 모드는 일반적인 운영에 사용되고, 패닉 모드는 기본적으로 훨씬 짧은 창을 가지며 트래픽이 폭증할 때 리비전을 빠르게 확장하는 데 사용된다"입니다.

기본값이 중요합니다. 안정 창은 "기본값 60초"이고 설정 가능 범위는 6초에서 1시간까지예요. 리비전별 어노테이션 키가 stable-window가 아니라 autoscaling.knative.dev/window라는 점은 헷갈리기 쉬운 지점이고요.

패닉 진입 기준은 "기본 설정 200.0은 트래픽이 현재 레플리카가 감당할 수 있는 양의 두 배로 높아지면 패닉 모드가 시작된다는 뜻"이라고 명시돼 있습니다. 이때 창이 얼마나 줄어드는지도 나옵니다. "값 10.0은 패닉 모드에서 창이 안정 창 크기의 10퍼센트가 된다는 뜻"이며 기본값이 10.0입니다. 안정 창이 60초라면 패닉 창은 6초가 되는 셈이죠. 두 값 모두 조정할 수 있습니다. 패닉 창은 1.0에서 100.0, 패닉 임계는 110.0에서 1000.0 범위이고, 임계가 100이면 항상 패닉 모드라 100보다 커야 한다고 문서는 덧붙입니다.

패닉 모드에는 안전장치가 하나 붙어 있습니다. 문서는 "패닉 모드를 사용할 때 리비전은 출렁임을 피하기 위해 축소하지 않는다"고 적어 두었어요. 급하게 늘린 파드를 곧바로 줄여 다시 부족해지는 상황을 막는 장치입니다.

빠져나오는 조건도 명시돼 있습니다. 안정 창 기간 동안 빠르게 반응할 이유가 없었다면 오토스케일러가 패닉 모드를 떠나죠. 그 뒤 줄어드는 속도에도 상한이 있습니다. 문서는 한 번의 평가 주기에서 줄일 수 있는 비율을 max-scale-down-rate로 두고 기본값을 2로, 곧 한 주기에 N에서 N의 절반까지로 제한한다고 설명해요. 확장 쪽 기본값은 1000으로 사실상 열려 있고요. 급증 때 늘어난 파드는 사라지되 단계적으로 사라진다는 뜻이죠. 이 두 값은 전역 설정만 가능하고 리비전 어노테이션은 없습니다. 그리고 어느 쪽이든 레플리카 하나만큼의 변화는 비율과 무관하게 항상 허용된다고 문서는 적어 두었어요.

셋째, 콜드 스타트는 최소 파드 수로 줄인다

서버리스의 약점은 콜드 스타트입니다. knative.dev는 이 상황을 직접 설명해요. 트래픽이 적거나 없을 때 HTTP 라우터는 요청을 액티베이터로 보내고, 액티베이터는 들어오는 요청의 버퍼 또는 큐 역할을 합니다. 용량이 없는 리비전으로 요청이 라우팅되면 액티베이터가 요청을 지연시키고 오토스케일러에 추가 용량이 필요하다고 신호를 보내죠. 그리고 요청을 처리하려고 새 파드를 띄워야 한다면, 문서는 그것을 "콜드 스타트라고 부른다"고 적습니다.

줄이는 방법은 단순합니다. 최소 파드 수를 1 이상으로 두어 따뜻한 파드를 남기는 것이죠. 문서는 autoscaling.knative.dev/min-scale을 두고 "각 리비전이 가져야 할 최소 레플리카 수를 통제한다"고 설명하고, 기본값을 "스케일 투 제로가 활성화되고 KPA 클래스를 쓰면 0, 그렇지 않으면 1"이라고 밝힙니다. 기본 상태에서는 0까지 내려가니 이 값을 명시적으로 올려야 하죠. 다만 없어지는 것은 0에서 올라올 때의 콜드 스타트뿐입니다. 문서가 정의한 콜드 스타트는 "요청을 처리하려고 새 파드를 띄워야 하는" 상황이므로, 따뜻한 파드 하나가 감당하지 못해 1에서 N으로 늘어나는 순간에는 그대로 발생합니다.

비용이 덜 드는 중간 선택지도 있어요. 문서는 scale-down-delay를 두고 "새 요청이 들어올 때 콜드 스타트 대가를 피하려고 컨테이너를 일정 시간 유지하는 데 쓸 수 있다"고 설명하며, 최소 파드 수와 달리 낮은 동시성이 지연 기간 내내 유지되면 결국 축소된다고 밝힙니다. 기본값은 0초이고 KPA에서만 지원해요. 0에서 올라올 때 한 번에 몇 개를 띄울지는 autoscaling.knative.dev/activation-scale로 정하고 기본값은 1이에요. 다만 문서는 리비전이 이 규모에 한 번 도달하고 나면 값이 무시되며, 실제 트래픽이 더 작은 규모를 필요로 하면 그 뒤로 축소된다고 밝힙니다. 상시 유지 수단이 아니라는 뜻이죠.

반대쪽 경계도 같이 잡아야 합니다. 문서는 상한을 max-scale로 두고 기본값을 "0, 곧 무제한"이라고 밝혀요. 상한을 열어 두면 확장 폭이 클러스터 여력에 그대로 의존하게 됩니다. 여력과 하위 시스템 한계를 기준으로 autoscaling.knative.dev/max-scale을 명시하는 편이 안전하죠. 클러스터에 max-scale-limit이 걸려 있다면 이야기가 달라집니다. 문서는 이 전역 키가 설정되면 새로 만들어지는 리비전에 대해 전역이든 리비전이든 그 값을 넘는 max scale을 허용하지 않는다고 밝힙니다. 값이 양수일 때 그 값을 넘는 max scale은 허용되지 않고, 무제한을 뜻하는 0도 여기 포함된다고 적어 두었어요. 상한 정책이 도입되면 기본값 그대로 새 리비전을 올리는 순간 막힌다는 뜻이죠.

여기에 경로 설계가 하나 더 붙습니다. target burst capacity는 이름 그대로 버스트 용량이에요. 문서는 이 값을 "Knative 애플리케이션이 버퍼링 없이 감당할 수 있는 트래픽 버스트의 크기를 정하는 설정"이라고 정의하고, 감당하기에 너무 큰 버스트가 오면 "리비전을 보호하기 위해" 액티베이터가 요청 경로에 배치된다고 설명합니다. 액티베이터는 "파드로 요청이 전달되는 속도를 조절"하는 역할도 합니다.

값의 의미는 이렇습니다. "0은 액티베이터가 0으로 축소된 경우에만 경로에 있다는 뜻이고, 마이너스 1은 액티베이터가 항상 경로에 있다는 뜻"이며 기본값은 200이에요. 그 외의 정수라면 "리비전 규모와 부하에 따라 액티베이터가 경로에 있을 수 있다"고 문서는 적습니다. 즉 기본값에서는 상시 경유가 아니라 조건부입니다.

따뜻한 파드를 늘 두는 구성이라면 이 값을 0으로 내려 평상시 경유를 없애는 선택지가 있습니다. 다만 대가를 알고 가야 합니다. 최소 파드 수를 1로 두고 target burst capacity까지 0으로 내리면 파드가 0이 되는 일이 없으므로 액티베이터는 어떤 경우에도 경로에 들어오지 않아요. 따뜻한 파드 하나가 감당하지 못하는 스파이크가 와도 버퍼도 속도 조절도 없이 그대로 받게 된다는 뜻이죠. 버스트 보호가 사라지는 것입니다.

문서는 0으로 둘 때 인그레스 로드밸런싱이 적용된다고 밝히면서 "인그레스 게이트웨이 로드밸런싱에는 추가 설정이 필요하다"는 주석도 답니다. 값을 내리기 전에 이 설정부터 확인해야 하죠. 어느 값이 안전한지 문서가 서열을 매기지는 않지만, 지연에 극도로 민감하고 스파이크 폭이 예측 가능한 워크로드가 아니라면 기본값 200을 유지하는 편이 무난하다는 것이 저희 판단입니다.

0으로 내려가는 조건도 문서에 있습니다. KPA 추가 설정 문서는 마지막 레플리카가 안정 창 전체 기간 동안 트래픽이 없었을 때만 제거된다고 적고, 스케일 바운드 문서는 같은 내용을 "대부분의 경우"로 적어 두었어요. 안정 창이 60초라면 마지막 파드가 사라지기까지 최소 그만큼은 조용해야 한다는 뜻이죠.

넷째, 배포와 관측을 함께 설계한다

Knative는 서비스에 변경이 생길 때마다 리비전을 만듭니다. 공식 문서는 리비전을 "각 변경에 대한 애플리케이션 코드와 설정의 특정 시점 스냅샷"이라고 정의해요. 한 가지 주의할 표현이 있습니다. 문서는 리비전이 "일반적으로 불변"이라고 하면서도, ConfigMap이나 Secret처럼 변경 가능한 쿠버네티스 리소스를 참조하는 경우와 리비전 기본값 변경으로 바뀔 수 있는 경우를 예외로 명시합니다. 완전 불변이라고 단정할 수는 없다는 뜻이죠. 다만 문서는 기본값 변경으로 인한 변형이 "일반적으로 구문상의 것이지 의미상의 것은 아니다"라고 덧붙입니다.

배포는 트래픽 스펙, 곧 트래픽 분할로 처리합니다. 문서는 traffic 스펙을 설정해 고정된 리비전들에 트래픽을 나눌 수 있다고 설명하고, 점진 전환 절차는 별도의 Route 리소스를 갱신하는 형태로 보여 줘요. 그리고 "태그를 사용해 대상 URL을 만드는" 방법을 별도로 안내해요. 한 스펙 안에서 여러 리비전에 percent를 나눠 배분하고, 특정 리비전에 tag를 붙이면 그 버전만 가리키는 주소가 생겨 운영 트래픽과 분리해 검증할 수 있습니다. 비율을 점진적으로 옮기는 방식과 검증 후 한 번에 전환하는 방식 모두 같은 스펙 위에서 나오죠. 로드밸런서 계층에서 같은 일을 하는 방식은 블루그린과 카나리 글에서 다뤘습니다.

마지막이 관측입니다. 앞서 본 것처럼 KPA는 CPU가 아니라 요청 흐름으로 판단하므로 일반 자원 지표만으로는 거동을 알 수 없어요. knative.dev 관측 문서는 Knative가 지표 내보내기에 OpenTelemetry를 쓴다고 밝히고 Prometheus 스택 구성, 지표 수집 활성화, Grafana 대시보드 가져오기를 순서대로 안내합니다. OpenTelemetry가 다루는 신호 자체는 옵저버빌리티와 모니터링 글에서 정리했습니다.

여기서 놓치면 안 되는 문장이 하나 있어요. 지표 내보내기는 기본적으로 꺼져 있습니다. 켜지 않으면 대시보드를 열어도 아무것도 보이지 않죠. 켜는 자리는 config-observability ConfigMap이고 metrics-protocol을 prometheus로 바꿉니다. 문서는 여기에 더해 Serving 컨트롤 플레인 지표를 걷으려면 ServiceMonitor와 PodMonitor를 적용하라며 serving-monitors.yaml 적용까지 안내해요. 문서는 이 구성 자체가 예시이며 지원은 best-effort라는 점도 명시합니다.

무엇을 봐야 하는지는 판단 신호에서 나옵니다. KPA가 동시성이나 초당 요청 수로 판단하니 그 두 지표를 축으로 두고, 오토스케일러가 의도한 파드 수와 실제 파드 수를 나란히 보는 것이 출발점이에요. 구체적인 지표 이름은 문서의 Metrics Reference에서 확인하면 됩니다. 이 조합은 공식 문서가 규정한 권장 대시보드가 아니라 운영 판단이고요.

한 가지 덧붙이면, 시간 기반 사전 확장이 필요할 때 KEDA를 떠올리기 쉽습니다. KEDA의 Cron 스케일러는 timezone을 IANA 표준 시간대 값으로, start와 end를 cron 표현식으로 지정하고 "스케줄 시작과 종료 사이에 리소스를 확장할 레플리카 수"를 desiredReplicas로 잡는 구조예요.

문서는 이 스케일러가 지정한 시간 구간에서 확장할 뿐 반복 스케줄에 따라 워크로드를 확장하는 도구는 아니라고 선을 긋습니다. 큐 소비자나 배경 작업이라면 KEDA가 어울린다는 것이 저희 판단이고요. 다만 HTTP 요청 경로만 다루는 서비스에서 단지 예약 확장을 위해 도구를 하나 더 들이는 것이 맞는지는 따져볼 문제입니다. 이벤트 전에 최소 파드 수를 미리 올려 두는 것으로 해결되는 경우도 있습니다. 얼마나 앞서 올릴지는 이미지 크기와 기동 시간에 달려 있어 서비스마다 다르니, 실제 기동 시간을 재서 정하는 편이 맞습니다.

정리하면 Knative 운영은 판단 신호를 이해하는 일에서 시작합니다. CPU가 아니라 요청 흐름을 보고, 두 개의 창으로 평상시와 폭증을 다르게 다루며, 최소 파드 수와 액티베이터 경로로 콜드 스타트를 조율하는 것이죠. 여기 정리한 기본값과 동작은 knative.dev 공식 문서가 기준이고, 계층 분리나 사전 확장 같은 배치는 운영 판단입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)