Kubernetes HPA 설계, 웹 API는 정말 CPU-Only가 표준일까?

 

Kubernetes에서 애플리케이션 스케일링을 설계할 때 가장 많이 쓰는 네이티브 오토스케일러가 HPA(Horizontal Pod Autoscaler)입니다.

하지만 실제 운영 환경에서는, 스케일링 지표로 무엇을 선택해야 하는가가 장애 안정성과 비용 효율을 좌우합니다.

운영 엔지니어들 사이에서는 “대부분 웹 API는 CPU-Only로 scaling한다”는 주장도 있고, “메모리도 트래픽에 따라 늘어난다”고 말하는 경우도 있습니다.

이 글에서는 이런 논쟁의 핵심을 짚고, 최근 업계 표준 흐름과 함께 올바른 설계 레이어 분리 원칙을 정리해봅니다.

---

1. “HPA 설계를 CPU-Only로 하는 게 좋은 선택인가?” 라는 질문의 본질

클러스터 운영자라면 한 번쯤 이런 질문을 해봤을 거예요.

“Kubernetes HPA 설정할 때 메모리 기준을 제거하는 게 좋은가?”

이 질문이 중요한 이유는 메모리 지표가 실제 부하의 원인을 설명하는 직접적인 트리거인가를 판단해야 하기 때문입니다.

많은 경우 웹 API는 요청이 늘어도 메모리 평균 점유율이 즉시 증가하지 않기 때문에, 메모리를 scaling trigger로 넣으면 노이즈 증가 → 불필요한 Pod scale-out → 비용 상승으로 이어질 수 있습니다.

하지만 “CPU-Only”라는 말은 메모리를 완전히 고려하지 않는다는 뜻이 아니라, HPA의 스케일링 트리거로 메모리를 사용하지 않는다는 의미에 가깝습니다.

---

2. 최근 실무 가이드에서의 공통적 결론

최근 실무 글과 가이드는 다음을 공통적으로 지적합니다.

• HPA의 CPU 메트릭은 트래픽 증가와 직접 비례하는 경우가 많아서 웹 API scaling에 가장 예측 가능한 trigger로 사용됩니다.
• 메모리 기반 HPA는 반응이 늦거나 scaling 시점이 부정확할 수 있고, 메모리 변화가 부하 원인과 직접 선형 관계가 아닌 경우가 많습니다.
• 따라서 스케일링이 중요한 latency-sensitive 서비스에서는 CPU + Custom Metric(Queue, QPS, Latency 등 원인 지표) 조합이 더 현실적이며,
• 메모리는 scaling의 기준이 아니라 워크로드 설계(Request/Limit) 레이어에서 보장하는 것이 더 적합한 디자인이라는 설명이 많습니다.

이로 미뤄볼 때 “CPU 중심 HPA가 일반적”이라는 큰 흐름은 맞지만,

HPA metric에서 memory를 제거한다고 해서 자동으로 memory도 같이 scaling되는 개념은 아닙니다.

메모리는 파드 설계값으로 보장되는 리소스일 뿐, 스케일링의 트리거가 아니었어요.

---

3. 그렇다면 트래픽이 늘어나면 메모리는 정말 안 늘어날까?

여기서 나온 핵심 질문이 하나 더 있습니다.

“트래픽이 많아지면 보통 웹 API는 CPU 부하만 증가하나? 메모리는 증가 안 함?”

정답은 증가 방식이 다르다 입니다.

• CPU는 아래 작업이 트래픽과 비례해서 즉시 올라갑니다:
  • HTTP 파싱, TLS 암호화, JSON 직렬화, 비즈니스 로직 실행, 네트워크/DB 응답 처리
• 메모리는 보통 다음 형태로 변합니다:
  • Baseline 메모리는 트래픽이 없어도 이미 컨테이너가 기동하면서 확보됩니다.
    • 예: FastAPI(파이썬 런타임 + 라이브러리 로딩)
    • Spring Boot(JVM + Heap + GC + DI)
    • Node.js(V8 엔진 + 모듈 로딩)
    • NGINX(worker buffer + 프로세스)
  • 트래픽에 의한 메모리 증가가 있다면 대부분:
    • 커넥션 수 증가에 따른 점진적 증가
    • 객체 생성/Payload 파싱에 따른 순간 스파이크
    • GC가 있는 언어에서는 회수 후 평균 안정
  • API 요청은 대부분 short-lived라 메모리가 누적되지 않는 경우가 훨씬 많습니다.

즉,

트래픽 증가 → CPU 즉각 상승, 메모리는 완만 증가 또는 요청 순간 spike만 발생 → 회수(GC, 요청 종료) → 평균 안정 유지

이 구조가 대부분의 stateless 웹 API의 현실입니다.

---

4. 업계 표준 설계 원칙 — 레이어를 분리하라

트래픽과 메모리 spike 장애 대응을 하나의 레이어에서 해결하려 하면 흔히 실패합니다.

그래서 최근 팀들이 선택하는 3-레이어 분리 표준은 다음과 같습니다.

웹 API 기준

레이어	목적
HPA / KEDA 등 (파드 수평 확장 레이어)	스케일링 트리거 정의	✅ CPU, QPS, Queue Lag, Event
Pod Resource 설계 레이어	OOM 방어, 초기값 보장	✅ Memory request & limit
Node AutoScale 레이어	노드 용량 확보	✅ Karpenter, CA, NodePool 등

Memory는 오토스케일의 trigger가 아니라, 파드의 안정적 실행을 보장할 설계 리소스에 둡니다.

---

5. KEDA와의 관계 — HTTP/Queue 중심 scaling이 필요하면 KEDA가 더 설득력 있음

일반 웹 API뿐 아니라,

메시지 큐, 스트림, HTTP burst request의 원인 자체를 스케일링 기준으로 삼고 싶을 때는

Kubernetes CRD인 ScaledObject, ScaledJob을 제공하는 KEDA가 Pod scale의 직접적 근거가 됩니다.

• Kafka consumer lag
• AWS SQS queue length
• Prometheus custom metric
• Cron / Job event trigger
• HTTP Add-on QPS 기반 scaling
• Scale-to-Zero 지원

이런 기준은 메모리보다 훨씬 스케일 원인 설명에 직접적입니다.

특히 트래픽 변동과 비용 효율이 같은 테이블에서 논의되어야 하는 FinOps 컨텍스트에서 강합니다.

---

6. 결론: 웹 API 환경이라면? CPU 중심 + 메모리는 설계 레이어에서 챙긴다

✅ 웹 API에서 HPA를 CPU 중심으로 하는 것은 최근 실무에서 가장 일반적인 선택

✅ 메모리를 HPA 트리거에서 제거해도 scaling 동작에는 영향이 없다 — 원래 트리거만 빠진 것

✅ 메모리 피크 장애 대응은 HPA가 아니라 request/limit 설계, VPA 관찰, 앱 튜닝 레이어에 둔다

✅ 트래픽 증가 시 CPU는 즉각 증가, 메모리는 완만 증가 또는 스파이크 후 회수되는 구조가 대부분

그래서 답하면 이렇게 됩니다.

“일반적인 웹 API라면 CPU 기반 스케일링이 가장 예측 가능하고 설득력 있는 trigger, 메모리는 Pod 설계로 보장하고 VPA로 관찰하는 구조가 사실상 업계의 표준에 가깝다.”