day-log

처음엔 KEDA 버그를 의심했다지난 금요일 오후, 대시보드를 열었다가 눈을 의심했다. SQS 큐 depth는 0인데 워커 파드가 40대씩 떠 있었다. minReplicaCount 는 2로 잡아뒀는데 왜 안 내려가지?KEDA를 SQS와 붙여 쓰는 팀이라면 한 번쯤 겪는 함정인 것 같아 정리해둔다.우리 팀은 이미지 후처리 워커를 EKS에서 KEDA로 굴린다. SQS 큐 depth 기반으로 스케일 아웃/인 시키는 흔한 구조다. 큐가 비면 minReplicaCount인 2대까지 내려가야 하는데, 그날은 40대에서 요지부동이었다. kubectl describe scaledobject를 찍어보니 metricValue가 계속 큰 값으로 나왔다.근데 SQS 콘솔에서 큐 depth는 진짜 0이다. Approximate ..

우리가 깐 구성지난주 화요일 새벽에 알림이 울렸다. 정확히는 알림이 안 울려서 문제였다. 이미지 변환 워커가 SQS 큐의 메시지를 잘 먹고 있는 줄 알았는데, 다음 날 아침에 보니 "어제 업로드한 썸네일이 안 나와요"라는 CS 티켓이 17건 쌓여 있었다. SQS DLQ에 들어간 것도 아니고 그냥 큐 어디에도 없었다. 처리는 안 됐는데 사라졌다는 게 가장 큰 문제였다.원인은 KEDA였다. 정확히는 KEDA가 잘못한 건 아닌데, scaleToZero를 너무 공격적으로 설정한 우리 팀이 잘못했다. 이 글은 그 이야기다.배경부터 정리하면, 우리 팀은 이미지 변환 파이프라인을 KEDA + SQS로 운영하고 있다. 사용자가 이미지를 업로드하면 S3 트리거가 SQS로 메시지를 보내고, 워커 파드가 그걸 받아서 리사이..

KEDA SQS scaler에서 새벽에 만난 함정지난주 토요일 새벽 3시쯤이었다. 핸드폰 진동 한 번에 눈이 떠졌다. SQS DLQ 누적 알림. 큐 메시지가 12,000개 쌓여 있었고, 컨슈머 파드는 정확히 한 개. 분명 KEDA로 ScaledObject 걸어놨고, 두 달 동안 잘 돌던 워크로드인데 왜 안 늘어났을까. 멘탈이 좀 흔들렸다.그래서 뭐가 문제였나상황부터 정리하자. 우리 팀이 운영하는 컨슈머는 이미지 후처리(리사이즈 + 메타데이터 추출)를 하는 파이썬 워커다. SQS에서 메시지 꺼내서 S3 거쳐 DynamoDB 업데이트하는 평범한 패턴. KEDA 2.16으로 SQS scaler 붙여놨고 설정은 이랬다.apiVersion: keda.sh/v1alpha1kind: ScaledObjectmetada..

지난달에 SQS 기반 워커 파드를 KEDA로 옮겼다. HPA의 CPU 메트릭만으로는 큐가 쌓일 때 늦게 반응하는 게 계속 거슬려서, 큐 길이로 직접 스케일하는 게 자연스러워 보였다. KEDA는 2.19가 최근에 떨어졌고(2026-02), SQS scaler에 scaleOnDelayed 같은 옵션도 정리돼 있어서 큰 고민 없이 시작했는데, 정작 일주일 동안 새벽에 두 번 호출되고 나서야 정신을 차렸다. 그 과정 정리.시작은 정상이었다워크로드는 단순하다. 외부 이벤트 → SQS → 워커 파드(Go 단일 바이너리)가 메시지 하나씩 받아 처리. 평소엔 큐가 비어 있고, 1시간 단위로 큐가 수만 건씩 쌓이는 burst 패턴이다. 한 메시지 처리에 평균 2초, P99 8초.처음 달았던 ScaledObject는 거의..