day-log

세 함수, 한 줄 요약Prometheus 쓰다 보면 반드시 한 번은 헷갈리는 게 rate, increase, irate 세 함수다. 이거 모르는 분 꽤 많더라. 알림 튜닝하다가 값이 이상해서 파본 적이 있는데, 이번 기회에 정리해둔다.rate(x[5m]): 지정한 구간(5분) 동안의 초당 평균 증가율. 부드럽게 완만해진다.increase(x[5m]): 지정한 구간 동안의 총 증가량. 그냥 얼마 늘었냐.irate(x[5m]): 구간 내 마지막 두 샘플만 보고 계산한 순간 증가율. 뾰족하게 튄다.사실 내부적으로는 increase(x[5m])는 rate(x[5m]) * 300 이랑 같다. rate가 좀 더 근본이다.실무에서 언제 뭘 쓰나알림(Alerting)에는 무조건 rate. irate로 알림 걸면 순간 ..

지난주 새벽에 겪은 이야기다. 프로덕션 EKS 두 개 중 한 쪽에서 신규 파드가 시크릿을 못 읽는다는 알림이 왔다. 처음엔 대수롭지 않게 봤는데, 결국 External Secrets Operator(ESO) 전체 sync가 멈춰 있는 상태였다. 우리 팀이 ESO를 IRSA + AWS Secrets Manager 조합으로 3년 넘게 쓰고 있는데, 이런 식으로 죽는 건 처음이었다.증상은 조용했다관측 가능한 신호가 애매했다. kubectl get externalsecret -A 를 찍으면 상태는 죄다 SecretSyncedError 였다. 근데 컨트롤러 파드는 살아 있고, CPU도 정상이고, 리더 election 로그도 잘 남고 있었다. Prometheus에서 externalsecret_sync_calls_e..

작년 여름부터 팀 회의 때마다 반복해서 나오는 주제가 있다. "우리도 Valkey로 옮겨야 하지 않을까요?" 처음에는 라이선스 이슈 정도로 가볍게 봤는데, 2026년이 되니 이야기가 좀 달라졌다. AWS ElastiCache 기본값이 Valkey로 바뀌고, Aiven이 15,000대 서버를 옮겼다는 얘기까지 들리니 무시하기 어려워졌다.우리 팀은 캐시 클러스터 40여 대, 세션 스토어 12대, 그리고 실시간 랭킹용 소규모 Redis 몇 개를 굴리고 있다. 각각의 워크로드가 조금씩 달라서 하나의 결론을 내기가 애매했다. 이 글은 그동안 실무자로서 두 진영을 비교하면서 정리한 내용이다. 결론부터 말하면 "무조건 갈아타야 한다"도 아니고 "굳이?"도 아니다.라이선스, 이게 진짜 이슈였다Redis 7.2까지는 B..

지난주에 OTel Collector가 메모리를 계속 먹다가 OOMKilled로 재시작되는 사고를 겪었다. 클러스터 전체 트레이스가 5분 단위로 뚝뚝 끊기는데, 그 시점 대시보드는 그냥 흰 도화지였다. 새벽 2시에 페이지가 울렸고, 눈을 뜨자마자 "batch processor" 4글자가 머리에 떠올랐다. 왜 하필이면 걔였는지, 지금 돌아보면 뻔한 이유가 있었지만 당시엔 한참을 헤맸다.우리 팀은 OTel Collector를 Deployment 3replica로 돌리고 있다. Ingress-nginx, 애플리케이션 SDK, kube-state-metrics에서 오는 트레이스/메트릭/로그를 모아 Tempo, Prometheus, Loki로 흘려보낸다. 트래픽 자체는 초당 스팬 8만개 정도. 그리 크지 않다. 그..

에러버짓 정책, 이렇게 굴리면 실제로 돌아간다SLO 문서에 에러버짓 계산식은 그럴싸하게 적어놨는데, 정작 소진되면 뭘 어떻게 할지가 애매한 팀이 많다. 우리도 그랬다. "예산 다 쓰면 릴리스 중단"이라고 위키에 한 줄만 적어놓고 반년을 흘려보냈다.문제는 어느 서비스가 어느 만큼 태워야 진짜로 손 놓아야 하는지, 그 기준이 팀마다 제각각이었다는 거다. PM은 "이번 스프린트만 넘기자"고 하고, SRE는 "지금 안 멈추면 안 된다"고 하고, 개발자는 "내 코드 아닌데 왜 내가 멈추냐"고 하고. 결국 정책이 없으면 매번 논쟁만 반복된다.이 글은 최근 몇 달간 우리 팀에서 굴려보고 나름 안정화된 에러버짓 정책의 뼈대를 정리한 것이다. Google SRE Workbook 얘기가 아니라 진짜 로컬 환경에서 어떻게 ..

컨테이너 이미지를 pull하고 시작할 때, 표면적으로는 그냥 kubectl apply 한 방이면 끝나는 것처럼 보인다. 근데 사실 그 아래에서는 containerd가 snapshotter라는 놈을 통해 파일시스템 레이어를 조립하고 마운트하는 꽤 정교한 과정이 돌아간다. 대부분은 overlay2를 그냥 쓰고 지나가지만, 몇 달 전부터 우리 팀에서 콜드스타트 지연을 잡느라 stargz-snapshotter를 검토하면서, 이 계층이 실제로 뭘 하고 있는지 다시 파헤쳐볼 일이 생겼다.지난 2월에 stargz 관련 lazy pulling이 다시 주목받으면서 관련 글이 여럿 올라왔는데, 대부분 "빠르다"에서 멈춰 있다. 사실 내부적으로 뭐가 바뀌는지 짚어봐야 언제 써야 하는지 판단할 수 있다. 그래서 이번 글에서는..

session pooling에서 transaction pooling으로 갈아탄 지 이틀째 되던 날 새벽 2시 반, 폰이 울렸다. 결제 API의 P99가 800ms를 넘겼다는 알람. 침대에서 노트북을 여는 순간 이미 뭐가 원인인지 짐작이 갔다. prepared statement 다.왜 갈아탔나우리 팀에서 PgBouncer는 오래전부터 session pool로 돌고 있었다. 백엔드가 Django였고, connection이 세션 내내 유지되는 게 편했다. 그런데 최근 서비스가 커지면서 DB 커넥션 수가 감당이 안 됐다. RDS 앞단 PgBouncer에 client는 3천이 넘게 붙는데 server 커넥션은 200~300 정도로 억제하고 싶었다. session pooling에서는 client 한 명이 붙어있는 ..

새벽 2시에 알림이 울렸다. 배포 파이프라인이 Error acquiring the state lock을 뱉고 멈춰 있었다. 락 ID를 들고 DynamoDB 콘솔에 들어가 강제로 항목을 지우고, 파이프라인을 재실행. 익숙한 절차였다. 근데 그날따라 이 절차가 어이없게 느껴졌다.우리 팀은 Terraform 1.11 무렵부터 S3 backend + DynamoDB 락을 써 왔다. 몇 년 잘 돌던 조합이다. 그런데 올봄에 팀 내부 논의 끝에 DynamoDB 락 테이블을 정리하기로 했다. 이유는 두 가지였다. 하나는 Terraform과 OpenTofu 양쪽 다 S3 네이티브 락을 밀고 있고 DynamoDB 방식이 사실상 deprecated가 됐다는 것. 다른 하나는 우리 조직에 IaC state가 40개 넘게 흩..

작년 이맘때만 해도 우리 팀은 Cluster Autoscaler(CAS)만 썼다. 노드 그룹 5개 정도로 쪼개놓고, 크기 별로 알아서 스케일링되게 두는 방식. 나쁘지 않았다. 진짜로. 근데 클러스터가 200노드를 넘어가고, 배치 잡이랑 온라인 워크로드가 같은 클러스터에서 뒤섞이기 시작하면서 이야기가 달라졌다.이 글은 두 오토스케일러를 놓고 실무에서 어떤 게 다르고, 우리는 왜 결국 Karpenter로 갈아탔는지 정리해본 것이다. Karpenter 홍보글은 아니고, CAS가 여전히 낫다고 판단한 지점도 같이 적어둔다.구조가 근본적으로 다르다CAS는 "노드 그룹을 스케일한다". Karpenter는 "필요한 노드를 직접 만든다". 이거 한 줄이 사실상 전부다.CAS는 EKS 노드 그룹이든 GKE 노드 풀이든,..

오늘 삽질하다가 알게 된 건데, cancel-in-progress: true 이거 그냥 다 켜두면 안 된다. 우리 팀에서도 몇 달 전에 이거 때문에 한 번 크게 데었다. PR 워크플로우에서는 문제 없이 잘 돌던 설정을 main 브랜치 배포 워크플로우에까지 그대로 붙여놨더니, 연달아 커밋이 두 번 들어왔을 때 앞선 배포가 중간에 잘려버리고 뒤 커밋만 배포됐다. 그 사이에 이미 헬름 릴리즈는 1단계까지 올라가 있었고. 정확히는 ArgoCD sync가 반쪽만 돈 상태였는데, 이걸 새벽에 알림 보고 복구하느라 한참 걸렸다.group 스코프를 어디로 잡을지가 핵심기본 패턴은 이거다.concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-p..