day-log

트레이스 샘플링을 tail 기반으로 돌리면 늘 만나는 문제가 있다. Collector 메모리가 훅훅 튀어 오른다. num_traces를 조금만 크게 잡아도 OOMKilled를 반복하고, 반대로 줄이면 span drop이 쌓인다. 우리 팀도 얼마 전까지 gateway 뒤에 붙은 tail-sampling collector 4대가 매일 새벽마다 OOM으로 재시작되는 걸 보고 있었다.이 글은 그 상황을 정리한 실무 가이드다. 최근에 OpenTelemetry Collector 쪽에서 나온 변화도 짚는다. 사실 이번 달(2026년 7월) Elastic이 upstream에 기여한 span-ingest 샘플링과 Pebble 기반 tail storage extension이 머지되면서 메모리 65%까지 줄었다는 리포트가 ..

지난 화요일 새벽 3시쯤이었다. 알람이 울렸다. P99 latency가 400ms를 넘겼다는 알림. 자다 깨서 노트북을 열었을 때 제일 먼저 든 생각은 "또 뭐가 문제냐"였다.우리 EKS 클러스터는 노드 40대 정도 되고, 트래픽이 특별히 튀지도 않았다. Grafana에서 애플리케이션 CPU도 여유롭고, DB 지표도 정상. 근데 왜 느려졌지? 한참 파고 나서야 원인이 나왔다. DNS였다. CoreDNS 파드는 CPU 20%도 안 쓰고 있는데 DNS 응답이 느렸다. 좀 어이가 없었다.처음엔 CoreDNS 스케일업을 의심했다당연히 첫 반응은 "CoreDNS 파드 수 늘려야겠다"였다. 그런데 grafana를 보니 CoreDNS 자체는 문제가 없었다. coredns_dns_request_duration_seco..

SLO를 도입하고 나면 대부분 다음 관문에서 걸린다. "그래서 알림을 어떻게 쏘지?"에러 예산이 30일 기준으로 계산되니까 30일치를 보고 알림을 쏘면 너무 느리고, 5분만 보고 쏘면 배포 중 살짝 튀는 것에도 오작동한다. Google SRE 워크북에 있는 "multi-window multi-burn-rate" 패턴을 그대로 갖다 쓰긴 하는데, 이게 왜 이 조합인지, 내부에서 무슨 일이 벌어지는지는 대충 넘어가는 경우가 많다. 우리 팀도 그러다. 최근에 알림 튜닝을 다시 하면서 정리한 내용을 풀어본다.번-레이트라는 지표가 사실은 뭘 계산하는가번-레이트(burn rate)는 이름이 살짝 오해를 부른다. "얼마나 빨리 타고 있냐"인데, 기준선이 뭔지가 모호하다. 정확히는 이거다.번-레이트 = (관측 윈도우의..

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

트레이스 저장 비용이 슬금슬금 오르기 시작한 게 지난 분기부터였다. 우리 팀은 마이크로서비스 40여 개에서 초당 8만 스팬 정도를 뽑아내고 있었는데, 벤더 청구서가 예산의 두 배를 찍은 걸 보고 "샘플링을 진지하게 다시 봐야겠다"는 결론에 도달했다.Head sampling은 이미 걷어냈다. 어차피 랜덤으로 10% 남기는 방식은 정작 봐야 할 P99 지연이나 에러 트레이스를 놓치기 일쑤였다. 그래서 tail sampling으로 갈아탔는데, 처음 도입할 때는 "결정을 뒤로 미룬다" 정도의 개념만 알고 시작했다가, 운영하면서 그 안에서 벌어지는 일들이 훨씬 복잡하다는 걸 알게 됐다. 이 글은 그때 내가 코드를 뜯어보며 정리한 노트에 가깝다.Decision Wait의 의미와 함정Tail sampling proc..

Karpenter 얘기는 이제 새롭지 않다. AWS re:Invent 때마다 나오고, 트위터에서도 마이그레이션 후기가 쏟아진다. 얼마 전 Salesforce가 1,000개 넘는 EKS 클러스터를 Karpenter로 옮겼다는 소식도 있었고. 그런데 우리 팀은 좀 늦게 결정한 편이다. 작년에 Cluster Autoscaler(이하 CA)에서 Karpenter로 넘겼고, 반년 정도 운영해봤다. 결론부터 말하면 이득은 있었다. 다만 처음 예상했던 이유들과는 조금 달랐다.왜 넘어갔나원래 이유는 명확했다. 노드 스케일링이 느리다. CA는 ASG 기반이라 unschedulable 파드가 생기면 → CA가 감지 → ASG desired capacity 조정 → EC2 프로비저닝 → kubelet join. 이 사이클이..

요즘 팀 슬랙에 EKS 노드 스케일 아웃 후 파드가 Running까지 도달하는 데 걸리는 시간 얘기가 자주 올라온다. GPU 노드에 20GB짜리 추론 이미지를 올려야 하는데, 이미지 pull에만 3분 넘게 걸린다. 트래픽 스파이크가 오고 나서야 노드가 뜨기 시작하면 사실상 늦다.이 문제 해결책으로 몇 년 전부터 계속 언급되는 게 lazy pulling이다. 이미지 전체를 미리 받지 않고, 컨테이너가 실제로 파일을 요청할 때만 해당 range를 원격 registry에서 가져다가 마운트해주는 방식. 개념은 단순한데 내부 동작이 꽤 재밌어서 이번에 SOCI(Seekable OCI) snapshotter 코드를 좀 뜯어봤다. 정리해둔다.OCI 이미지가 어떻게 생겨먹었길래 lazy pulling이 되는가우선 왜 ..

문제 상황오늘 알게 된 건 아니고, 최근에 신규 팀원한테 알림 튜닝 인수인계하다가 "이 함수 처음 봐요"라는 말을 들었다. 생각해 보니 나도 예전에 absent()랑 헷갈려서 쓰다가 알람을 놓친 적이 있었다. 짧게 정리해 둔다.Prometheus 알림 대부분은 "값이 얼마 이상이면 발동"이다. 근데 실제 사고는 오히려 "메트릭 자체가 안 오는" 순간에 터진다. exporter 프로세스가 죽었거나, 파드가 재시작되면서 라벨이 살짝 바뀌었거나, scrape job이 config reload 때 조용히 빠졌거나.이럴 때 up == 0만 걸어두면 반쯤은 놓친다. up은 scrape target이 등록돼 있어야 값이 있는 거고, target이 아예 discovery에서 사라지면 up{job="X"} 시리즈 자체가..

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를 별도로..