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로 메시지를 보내고, 워커 파드가 그걸 받아서 리사이..

지난주에 HPA behavior 필드를 손댄 적이 있다. 정확히 말하면 손댄 게 아니라, 누군가 친절하게 PR로 올려준 "스케일 다운 빠르게 하자"는 변경을 별생각 없이 머지한 게 시작이었다. 그날 오후부터 P99 레이턴시가 평소 80ms에서 320ms를 찍었고, 새벽 1시쯤 알람이 한 번 더 울리고 나서야 우리 팀은 이게 비용 최적화가 아니라 자해였다는 걸 인정했다.이 글은 그 삽질 회고다. 비슷한 PR 들어오면 한 번만 더 생각해 보시라는 의미에서 적어둔다.사건의 시작서비스는 API 트래픽이 출퇴근 시간대에 몰리는 전형적인 패턴이다. 노드 12대짜리 EKS 클러스터에서 Deployment 3개가 HPA로 묶여 있었고, 평소 replica가 8~30 사이를 왔다 갔다 했다. 비용을 줄이려면 트래픽이 빠..

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

처음에 의심한 것들지난주 새벽 2시 반에 알람이 울렸다. P99 레이턴시 알람이었는데, 한두 번이면 그냥 무시하고 자고 다음 날 보겠지만 같은 알람이 5분 간격으로 계속 울렸다. 누워서 폰만 보다가 결국 노트북을 열었다.원인은 Karpenter였다. v1.0으로 올리고 한 달 정도 됐는데, 이 시점에 처음으로 큰 사고가 터졌다. 자려고 누웠다가 새벽 5시까지 깨어 있었던 그 밤 이야기를 정리해두려고 한다.알람이 P99 latency였으니까 당연히 애플리케이션을 먼저 봤다. 그런데 백엔드 트레이스를 까보니 응답 자체는 빠른데, 가끔 한 노드의 모든 파드가 동시에 사라지는 패턴이 보였다. terminated 이벤트가 5분에 한 번씩 떴다.처음엔 spot interruption인 줄 알았다. 우리 서비스 노드..

지난달에 결국 Karpenter로 갈아탔다. 팀에서 반년 넘게 "다음 분기에 해야지" 하며 미뤄왔던 숙제였는데, 예상대로 쉽지 않았다. 이 글은 자랑이 아니라 그냥 기록이다. 비슷한 고민 하는 분들에게 조금이라도 도움이 됐으면 해서 적는다.Karpenter가 v1.0 GA 찍은 지도 벌써 한참 됐고, 최근에는 OCI provider까지 GA 나오면서 더 이상 "AWS 전용 실험 프로젝트" 소리는 못 듣는 상황이다. 그래도 막상 프로덕션에 올려보면 문서에 안 나오는 함정이 꽤 있다.왜 옮겼나솔직히 Cluster Autoscaler(CAS)가 못 쓸 물건은 아니다. 노드 18대 규모에서 몇 년을 잘 돌았다. 문제는 배치 잡 비중이 커지면서부터였다.우리 팀은 데이터 파이프라인 일부가 Kubernetes Job..