TL;DR — 제출이 몰릴 때 채점 대기열이 쌓이는데, CPU/메모리 기반 오토스케일은 이미 쓴 자원만 보여 대기열(미처리 수요)을 제때 못 읽는다. KEDA로 제어지표를 Kafka Consumer Lag로 바꿔, 언어별 채점 워커를 미처리 적재량에 따라 수평 확장했다.

배경

• 프로젝트/기능: CodeQuest 채점 파이프라인. 서버가 제출을 Kafka submission-* 토픽으로 보내면 언어별 채점 워커(C·C++·C#·Java·Python)가 소비·채점
• 환경: Kubernetes, Kafka, KEDA
• 왜 문제였나: 수업·과제 마감처럼 제출이 특정 시간에 몰릴 때 채점 대기가 길어짐

문제 (증상)

• 제출 폭주 시 채점 대기열이 쌓여 결과 확인이 느려짐
• CPU/메모리 기반 HPA는 이미 발생한 자원 소모만 반영 → 아직 처리 안 된 수요(대기열)를 제때 감지 못 해 확장이 늦음

원인 분석

• 채점 워커의 진짜 부하 지표는 CPU가 아니라 큐에 쌓인 미처리 메시지 수(Consumer Lag)
• Lag은 "앞으로 해야 할 일"을 직접 나타내므로, 자원 사용률보다 선행적으로 부하를 보여줌

해결

KEDA ScaledObject로 언어별 채점 워커를 Kafka Consumer Lag 트리거로 수평 확장.

triggers:
  - type: kafka
    metadata:
      consumerGroup: csharp-judge-group
      topic: submission-CS
      lagThreshold: "5"          # 파티션당 lag이 임계값 초과하면 확장
minReplicaCount: 1
maxReplicaCount: 10
pollingInterval: 15            # 15초마다 lag 폴링
cooldownPeriod: 60
# scaleUp: 30초당 최대 3파드, scaleDown: 60초당 1파드

• 언어별(C·CPP·CS·Java·Python)로 각각 ScaledObject 구성, consumerGroup·topic 분리
• 임계값은 언어별로 정적 차등 설정 — 건당 처리가 짧은(컴파일이 빠른 C, JVM 콜드스타트를 제거해 케이스당 60ms 수준까지 빨라진 Java) C·Java는 lagThreshold: 3, 상대적으로 처리가 더 걸리는 Python·C++·C#는 5. lagThreshold는 파드당 허용 대기 메시지 수이고 확장 규모는 파드 수 = ceil(lag ÷ threshold)로 정해진다. 목표 대기 1s를 기준선으로 잡되, 빠른 언어는 파드를 한 대 늘렸을 때 대기열이 그만큼 빠르게 소진되므로 더 일찍(낮은 임계값) 확장시키고, 느린 언어는 파드를 늘려도 소진이 더뎌 과확장을 피하도록 임계값을 완화했다

정정 메모: 이 임계값은 yaml에 고정값으로 설정한 것이고, "목표 대기시간 ÷ 평균 처리시간"으로 런타임에 자동 산정하는 로직이 구현돼 있는 것은 아니다. (그 계산식은 임계값을 정할 때의 설계 근거로 활용 — 목표 대기 1s, C 기준 테스트케이스당 60ms로 제출 1건이 약 0.3s이므로 1s ÷ 0.3s ≈ 3)

결과

• 미처리 작업량(lag)에 비례해 워커가 수평 확장되어 채점 대기 적체 완화
• 자원 사용률이 아닌 수요(lag) 기반이라 부하 급변에 더 빨리 반응