day-log

지난주 화요일 새벽 2시쯤이었나. 알림이 울렸다. 특정 서비스의 P99 레이턴시가 800ms를 넘긴다는 알람이었다. 노드 16대짜리 프로덕션 클러스터에서, 특정 결제 API 파드가 30초 간격으로 8개에서 22개, 다시 10개, 또 25개... 이런 식으로 계속 오르락내리락 하고 있었다.솔직히 처음엔 트래픽 스파이크인 줄 알았다. 근데 그라파나 대시보드를 열어보니 그건 아니었다. RPS는 완만하게 오르는 중이었다. 그런데 파드 수가 미친 듯이 진동하고 있었다. 이게 바로 HPA flapping이다. 이론으로만 알던 걸 새벽 2시에 만나게 되니 정말 반가웠다(반갑지 않았다).처음엔 임계값을 만졌다가장 먼저 시도한 건 CPU targetAverageUtilization을 60에서 75로 올린 것이었다. "임..

배경: 기본 동작이 왜 종종 실무에 안 맞는가오늘 다룰 건 하나다. HorizontalPodAutoscaler(HPA) behavior 필드. 이거 모르는 사람 의외로 많아서 짧게 정리해둔다.우리 팀 클러스터에서는 오전 10시부터 트래픽이 슬금슬금 올라오는 서비스가 하나 있다. 점심 직후에 잠깐 훅 떨어졌다가 오후에 다시 올라온다. 그런데 HPA를 별다른 설정 없이 켜두면 12시 30분쯤 replica가 4→2로 급격히 떨어졌다가, 13시가 되면 또 CPU가 튀면서 부랴부랴 다시 올린다. 이게 하루에 두세 번씩 반복되니 pod 재기동이 잦아지고 P99가 흔들린다.원인은 기본 stabilization window. 지금 HPA v2 기본값은 scaleDown이 300초, scaleUp이 0초다. 5분짜리 ..

Kafka consumer를 K8s에서 돌리다 보면 결국 한 번은 마주치는 질문이 있다. "왜 lag이 쌓이는데 파드는 안 늘어나지?" HPA에 CPU 기준 스케일링을 걸어봐야 소용없다. consumer는 대부분 I/O bound라 lag이 폭증해도 CPU는 40%대에서 안정적일 수 있다.이 글은 KEDA(Kubernetes Event-Driven Autoscaler)를 실제 운영 환경에 붙일 때 알아야 할 것들을 정리한 가이드다. 공식 문서에 잘 나온 기본 설치법이 아니라, 실무에서 자주 밟는 함정 중심으로 썼다. KEDA 2.15 기준.HPA 대신 KEDA를 쓰는 이유기본 HPA는 CPU/메모리, 그리고 custom metrics API를 통한 임의 지표까지 지원한다. 그럼 왜 굳이 KEDA를 별도로..

오늘 알게 된 건 아니고, 얼마 전부터 팀 내부에서 오토스케일링 튜닝하다가 정리한 팁이다. 근데 이거 모르는 분들이 의외로 꽤 있어서 짧게 남긴다.HPA behavior 필드는 v2에서 나온 뒤로 GA 된 지가 좀 됐는데, 아직도 기본값 그대로 쓰는 팀이 많더라. 그 중에서도 stabilizationWindowSeconds가 특히 문제다.뭐가 문제였냐면트래픽이 규칙적으로 확 튀었다가 3-4분 안에 원상복구되는 서비스가 하나 있다. 이벤트 배너 서비스인데, CPU가 순간 60%까지 튀고 30초쯤 지나면 20% 아래로 떨어진다.HPA 기본 설정으로 놔뒀더니 이런 흐름이 반복됐다:트래픽 스파이크 → 5개 → 12개로 스케일 업30초 뒤 트래픽 원상복구5분 뒤 (기본 downscale stabilization ..

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

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