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·Java는 lagThreshold: 3, 상대적으로 처리가 더 걸리는 Python·C++·C#는 5. 즉 처리가 빠른 언어일수록 더 민감하게(낮은 임계값) 확장

정정 메모: 이 임계값은 yaml에 고정값으로 설정한 것이고, "목표 대기시간 ÷ 평균 처리시간"으로 런타임에 자동 산정하는 로직이 구현돼 있는 것은 아니다. (그 계산식은 임계값을 정할 때의 설계 근거로 활용)

결과

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