day-log

Loki 스트림 폭발로 새벽 3시에 알람 받은 날

지난주 금요일 새벽 3시, 폰이 미친 듯이 울렸다. LokiIngesterMemoryHigh 알람. 눈이 번쩍 떠졌다.솔직히 이 알람이 처음 뜬 건 아니었다. 근데 그날은 좀 달랐다. ingester 파드 12개 중 4개가 OOMKilled로 계속 재시작 중이었고, 그 사이에 유입되던 로그는 500 에러 뱉으면서 다 흘려 보내고 있었다. 팀 슬랙에 사고 채널 만들고 노트북 열었을 땐 이미 5분치 로그가 유실된 상태였다.원인은 결국 stream 카디널리티Loki 운영해본 사람은 알겠지만, "카디널리티"는 반쯤 저주 같은 단어다. 라벨 하나 잘못 붙이면 몇 시간 뒤에 클러스터가 죽는다. 우리 팀도 그걸 알고 있었고, 그래서 애초에 라벨 조합을 5~6개로 제한하는 룰이 있었다.문제는 그 룰이 깨진 게 아니었다..

지난주에 관측성 파이프라인이 새벽에 두 번 죽었다. 슬랙 알람이 4시 47분에 왔고, 눈 뜨자마자 노트북 열어서 로그부터 봤다. OTel Collector가 OOM으로 재시작을 반복하고 있었다. 이번 글은 그 삽질을 정리한 회고다. 결론부터 말하면 tail sampling 튜닝을 잘못했고, 트래픽 스파이크와 겹치면서 폭탄이 터졌다.상황우리 팀은 대략 40개 서비스에서 스팬을 뽑아 OpenTelemetry Collector 게이트웨이 → tail sampling 전용 Collector → 백엔드(Tempo)로 흘려보내고 있다. 게이트웨이는 15대, 샘플링 Collector는 6대. 각각 c6i.xlarge. 사고 당일 트래픽은 평소 대비 2.3배쯤 튀었다. 프로모션 이벤트가 있었는데 관측성 팀은 그 스케줄..

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

DR 훈련 하다가 죽을 뻔한 이야기. 지난달에 우리 팀은 서울 리전 → 도쿄 리전 Kafka 클러스터 사이 MirrorMaker 2(MM2) 페일오버를 실제로 눌러봤다. 스테이징에서 몇 번 성공했고, 문서에도 "consumer group offset은 자동 translation 된다"라고 되어 있으니까 마음이 편했다.결론부터 말하면, 우리는 특정 컨슈머 그룹에서 메시지 4만 건을 재처리했다. idempotent하게 짜놓은 게 그나마 다행이었지, 안 그랬으면 리포트 팀이 한 달치 데이터를 다시 만들었어야 했다. 그리고 그 원인이 대부분 "offset translation을 너무 믿었다"에서 시작한다.액티브-패시브인데 왜 lag가 음수로 뜨죠우리 구성은 이렇다. 서울(source) → 도쿄(target) 단..

지난달 새벽 2시 43분에 알람이 울렸다. Redis primary 노드가 죽었다는 알람이었는데, 문제는 Sentinel이 자동 failover를 안 해줬다는 거였다. 5분 정도 쳐다보다가 결국 손으로 promote 시켰다. 서비스는 그 사이 캐시 미스 폭탄으로 DB 커넥션 풀이 다 터졌고, 우리 팀 슬랙에는 "왜 자동 failover가 안 되냐"는 질문이 5개쯤 쌓였다.이 글은 그 원인을 찾아가는 과정과, 결국 뭐가 문제였는지에 대한 회고다.처음 봤을 때우리 구성은 이랬다. Redis 6.2에 primary 1대, replica 2대, Sentinel 3대. Sentinel은 Redis 노드와 같은 VM에 얹혀있었다 (사실 이게 나중에 원흉으로 밝혀진다). quorum은 2로 설정돼 있어서 이론상 Se..

지난주 화요일 새벽 3시 12분, 폰이 울렸다. 사내 슬랙 챗봇이 coredns_cache_misses_total 급증을 감지해서 온콜을 깨웠다. 처음엔 흔한 오탐이겠거니 하고 눈을 감으려다가, 대시보드를 열어보니 정말로 뭔가 이상했다. 클러스터 전체 파드에서 DNS 실패 로그가 초당 수천 건씩 쏟아지고 있었다.노드 24대, 파드 2100여 개가 돌고 있는 EKS 1.30 클러스터였다. 평소에도 CoreDNS는 조용한 편이라서 크게 신경 쓰던 컴포넌트는 아니었는데, 이날 이후로 우리 팀의 DNS 관측 표준이 완전히 바뀌었다.처음 본 지표먼저 CoreDNS 메트릭을 봤다. 평소 P99 응답 시간이 3ms 언저리에서 놀던 게 갑자기 800ms까지 튀어 있었다. 그리고 coredns_dns_responses_..

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

지난주 화요일 새벽 4시쯤, 알림이 두 개 연달아 왔다. 하나는 pod pending 알림, 하나는 P99 레이턴시 알림. 눈이 번쩍 떠져서 노트북을 켰다.우리 팀은 몇 달 전부터 Karpenter를 v1.x로 올려두고 spot-to-spot consolidation을 활성화해서 쓰고 있다. 비용은 확실히 줄었다. 근데 그 새벽에는 대가를 치렀다. 노드 12대 중 7대가 30분 사이에 인터럽트를 받으면서 순차적으로 죽었고, 그 와중에 Karpenter는 계속 새 spot을 붙였다 떼기를 반복하고 있었다.처음에는 그냥 spot 인터럽트인 줄 알았다AWS spot은 원래 죽는다. 그건 알고 시작한 거니까. 그래서 처음에는 "아 오늘 그 존이 좀 빡센가 보다" 하고 넘어갈 뻔했다. 근데 로그를 보니 이상했다...

지지난 주에 우리 팀이 운영하는 결제 도메인 클러스터에서 Vault 토큰 관련 알람이 30분 가까이 폭주했다. P99 레이턴시도 같이 튀었고, 무엇보다 새벽 2시였다. 결론부터 말하면 Vault Agent injector가 만든 sidecar가 init 컨테이너가 이미 받아둔 토큰을 재사용한다고 믿고 있었는데, 실제로는 그렇지 않아서 매번 다시 인증을 시도하다가 Vault 서버 쪽 rate limit에 걸린 사건이었다.좀 더 풀어서 적어둔다. 같은 함정 밟는 분 있을지도 모르니까.어떻게 발견했는가알람은 단순했다. vault-agent 컨테이너에서 permission denied와 429 too many requests가 번갈아 찍히고 있었다. 처음에는 정책(vault policy) 문제인가 싶었다. 그런..

지난주 화요일 새벽 3시 12분. 폰이 진동했다. PagerDuty다.알림 내용은 단순했다. "checkout-api 50x error rate spike". 처음에는 트래픽 이슈인가 싶었는데, 그래프를 열어보니 패턴이 이상했다. 트래픽은 평소 새벽 수준 그대로인데 5xx만 튀고 있었다. P99 레이턴시도 2초를 넘기고 있었다.결론부터 말하면 Karpenter consolidation 정책을 잘못 건드린 게 원인이었다. WhenEmptyOrUnderutilized를 그대로 두고 consolidateAfter를 30초로 줄였더니, 새벽 트래픽이 잠깐 빠질 때마다 노드가 통째로 갈리면서 stateful한 워크로드들이 같이 흔들렸다.우리가 뭘 바꿨길래며칠 전에 비용 최적화 한답시고 NodePool 설정을 손봤..