day-log

며칠 전에 팀 신입한테 SLO 세팅을 맡겼는데, 결과물이 좀 아쉬웠다. Availability SLO 99.9% 걸어놓고 burn rate 알람을 하나만 만들어놨더라. 1시간 윈도우에 14.4x 넘으면 알람. 이거 흔한 실수라서 짧게 정리해둔다.왜 하나면 부족한가burn rate 알람 하나만 두면 두 가지 중 하나 문제가 무조건 생긴다.윈도우를 짧게 잡으면 (예: 5분/1시간) — 트래픽 스파이크 한 번에 알람을 뜬다. 새벽에 CDN이 잠깐 흔들려서 5분간 에러율 튀었다? 알람 온다. 근데 실제로는 15분 후에 자동 복구됐다. 오탐이다. 이런 게 반복되면 팀이 알람을 무시하기 시작한다.윈도우를 길게 잡으면 (예: 6시간/3일) — 진짜 큰 장애가 났는데 알람이 늦게 온다. 30분간 API가 완전히 죽어 ..

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

노드 drain 걸었는데 특정 파드가 계속 evict 안 되고 남아 있던 적, 다들 한 번쯤 있을 거다. 반대로 drain 명령 하나로 서비스가 순간적으로 다 내려가서 알람이 우수수 뜬 경험도. 이 두 상황 사이의 균형을 잡아주는 게 PodDisruptionBudget(PDB)인데, 막상 실무에서 어떻게 세팅해야 할지는 문서만 봐서는 잘 안 잡힌다.우리 팀도 노드 수십 대짜리 EKS 클러스터에서 Karpenter로 consolidation을 돌리면서 몇 번 삽질을 했다. PDB 하나 잘못 걸어서 consolidation이 몇 시간씩 멈춰 있던 적도 있고. 그래서 지금 팀 안에서 굳어진 룰 위주로 정리해본다.minAvailable vs maxUnavailable, 뭘 쓸까이거 은근히 헷갈리는데, 결론부터 ..

지난 화요일 새벽에 사고가 하나 있었다. 결제 API의 error rate가 슬금슬금 올라가고 있었는데, 우리가 그렇게 자랑하던 multi-window multi-burn-rate alert는 새벽 5시가 다 되어서야 울렸다. CS팀이 먼저 알아챈 걸 사후에 확인했다. 그 시간까지 error budget의 30% 가까이가 이미 타버린 상태였다.사실 이 alert 룰은 팀 내부에서 두 달 전에 큰 리팩터링을 마쳤던 것이라 더 뼈아팠다. Google SRE 워크북에 나온 그 표를 그대로 옮겨놓고, PromQL도 두 번 세 번 리뷰했었다. 근데 왜 안 울렸을까.룰은 정석대로였다우리가 쓰던 fast burn 알람은 이런 모양이었다.- alert: PaymentApiErrorBudgetBurnFast expr:..

오늘 알게 된 건데, 이거 모르고 쓰는 분이 꽤 많더라. absent() 함수. Prometheus에서 "메트릭이 사라졌을 때" 알람 거는 그 함수 말이다.뭐가 문제냐면우리 팀이 최근에 배치 job 상태를 감시하려고 이런 룰을 넣었다.- alert: JobMetricMissing expr: absent(batch_job_last_success_timestamp) for: 5m문제는 이거다. 배치가 서버 2대에 떠 있고, 한쪽 서버만 죽었을 때 이 알람이 안 울린다. absent()는 "메트릭 전체가 사라졌을 때"만 1을 반환한다. 나머지 한 서버가 살아있으면 시리즈는 여전히 존재하니까 조용하다. 근데 우리는 인스턴스 단위로 놓치고 싶지 않았다.unless가 답인 경우이럴 땐 unless를 쓴다.- a..

kubectl이 갑자기 Too Many Requests를 뱉기 시작하면 대부분 첫 반응은 비슷하다. "누가 또 apiserver 두들기고 있냐." 그리고 나서 metrics를 보면 특정 컨트롤러가 리스트 요청을 폭주하고 있거나, 새 오퍼레이터가 배포되면서 watch를 무한 재연결하고 있거나 그런 식이다.근데 그때 이런 의문이 든다. 왜 kubelet의 상태 업데이트는 여전히 잘 되는데 내 kubectl은 막힐까? 왜 어떤 요청은 큐잉되고 어떤 요청은 즉시 429가 뜰까? 이 뒤에는 API Priority and Fairness — 줄여서 APF — 라는 녀석이 돌아가고 있다. 사실 v1.29에서 GA된 지 좀 됐는데, 실제로 이걸 튜닝하거나 내부를 뜯어본 사람은 생각보다 적다. 최근에 EKS 컨트롤 플레..

지난주 화요일 새벽 2시 반쯤이었다. 온콜 알림이 왔고, Prometheus 인스턴스 두 대가 연달아 OOM으로 죽었다는 내용이었다. 눈을 비비고 노트북을 열었는데, Grafana는 이미 죽어 있었다. 데이터 소스가 죽었으니 당연한 일이었다. 그 다음 두 시간 반 동안 내가 겪은 얘기다.처음엔 그냥 재시작하면 될 줄 알았다당시 우리 스택은 이랬다. 노드 24대 EKS 클러스터, kube-prometheus-stack으로 배포한 Prometheus 두 대 HA 구성, 메모리 리소스 리밋은 각각 16GB. 평상시 series 개수는 대략 480만 정도. 리텐션 15일. remote_write로 장기 저장소에 밀어넣고 있었다.일단 재시작. WAL replay가 시작됐는데, 이게 도무지 끝나지가 않았다. 평소엔..

지난주 화요일 새벽 두 시, 휴대폰이 울렸다. P0 알람. 결제 API의 P99 레이턴시가 1.2초를 넘기고 있었고, 50x 비율이 3분 동안 8%까지 올라갔다 떨어졌다. 잠이 확 깼다.대시보드를 열어보니 노드가 한꺼번에 세 대가 빠지고 있었다. 우리 클러스터는 노드 24대 규모인데, Karpenter consolidation이 동시에 세 대를 cordoning + draining 중이었다. Pod Disruption Budget도 걸어뒀고, terminationGracePeriodSeconds도 충분히 잡아뒀는데도 결제 서비스 두 개 인스턴스가 같은 노드에 몰려 있던 게 문제였다. 새벽 2시는 트래픽이 낮긴 해도 결제는 0이 아니다. 일본/동남아 유저들이 깨어 있다.왜 새벽에 한꺼번에 빠졌나Karpen..

지난 화요일 오전, 한 사용자한테 문의가 들어왔다. "결제 콜백이 가끔 실패한다"고. PM이 슬랙에 던진 메시지였는데, 솔직히 그때까지 우리는 아무 알림도 못 받은 상태였다. SLO 대시보드를 켰다. 99.5% 목표인 가용성 SLI가 99.1%까지 떨어져 있었다. error budget이 이미 절반 가까이 타들어간 상태였다.근데 burn rate 알림은 조용했다. 한 번도 안 울렸다.우리가 깔아둔 알림 구성Google SRE 워크북에 나오는 multi-window multi-burn-rate 패턴 그대로였다. 페이지(긴급) 알림은 1시간 윈도우 + 5분 윈도우 둘 다 14.4배 burn rate를 넘기면 발사. 티켓(완만) 알림은 6시간 + 30분 윈도우에 6배 burn rate. 표준 구성이다.- al..

OpenTelemetry Collector를 운영하다 보면 refused_spans, enqueue_failed, OOMKilled 같은 시그널을 한 번쯤은 본다. 다들 "memory_limiter 처음에 두면 된다"고 말하지만, 정작 메모리가 한계에 닿았을 때 collector 내부에서 무슨 일이 일어나는지는 의외로 흐릿하게 알고 있는 경우가 많다. 나도 처음엔 그랬다. 어느 날 traces 파이프라인이 갑자기 데이터를 흘리기 시작해서 메트릭을 파보다가, 그때서야 batch와 queue, retry가 메모리 한계 앞에서 어떻게 상호작용하는지 본격적으로 파악하게 됐다.이 글은 그 흐름을 정리한 노트다. 2026년 2월 즈음 oneuptime이나 dash0 쪽에서 모범 사례 가이드가 다시 한번 정리됐는데,..