day-log

큐가 갑자기 쌓일 때 HPA(CPU 기반)는 거의 도움이 안 된다. 워커 파드의 CPU는 정작 한가한데 메시지는 계속 쌓이는 상황, 한 번쯤 겪어봤을 것이다. 이런 경우엔 큐 길이 자체를 메트릭으로 써야 한다. KEDA가 그걸 표준화해준다.이 글은 RabbitMQ 컨슈머를 KEDA로 스케일링할 때 실제로 챙겨야 하는 설정들을 정리한 가이드다. KEDA 2.17 기준이고, 운영하면서 한 번씩 발 걸렸던 항목 위주로 적었다.왜 HPA만으로는 부족한가전형적인 큐 워커는 메시지 하나 처리에 I/O 대기가 많다. 외부 API 콜, DB 조회, S3 업로드 같은 것들. 이런 워커는 CPU가 30%만 찍혀도 큐는 만 건씩 쌓일 수 있다. CPU 50%를 임계로 HPA를 걸어두면 영원히 안 늘어난다.큐 길이를 직접 보..

우리가 깐 구성지난주 화요일 새벽에 알림이 울렸다. 정확히는 알림이 안 울려서 문제였다. 이미지 변환 워커가 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는 거의..