day-log

SLO는 깨졌는데 burn rate 알림은 안 울렸다

지난 화요일 오전, 한 사용자한테 문의가 들어왔다. "결제 콜백이 가끔 실패한다"고. 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..

지난주 수요일 새벽이었다. 새벽 2시쯤 자다가 슬랙 멘션 알림에 깼다. "어제 오후 4시부터 지금까지 로그가 안 보여요." 운영팀 야간 담당자였다. 휴대폰 화면 밝기에 눈이 시리면서도 멘탈은 이미 깨어버린 상태. 우리 클러스터는 노드 80대 규모에 Loki 3.7.x를 미러 모드로 돌리고 있었고, 하루에 1.5TB 정도의 로그를 받는다. 그게 7시간 동안 사라졌다는 얘기다.솔직히 처음엔 좀 의심했다. "진짜 7시간 동안 아무도 모를 수가 있나?" 근데 확인해보니 진짜였다. Grafana에서 last 24h로 보면 오후 4시 지점에서 갑자기 라인이 뚝 끊겨 있었다. 그래프가 그렇게 정직하게 끊긴 건 처음 봤다.ingester pod 상태부터 봤다가장 먼저 한 일은 ingester pod의 상태 확인이었다...

처음엔 외부 API를 의심했다새벽 3시 12분. 슬랙 알림이 한 번에 17개 쌓였다. P99 외부 API 호출 latency가 평소 80ms에서 4초까지 튀었다. 처음엔 SaaS 벤더 쪽 장애인가 싶었는데, 우리 쪽 다른 서비스들도 다 같이 느려지고 있었다. 멘탈이 한번 나가고, 노트북을 켰다.결론부터 말하면 CoreDNS NXDOMAIN 폭주였다. 솔직히 DNS 문제는 항상 의심해야 한다는 걸 머리로는 알았는데, 실제로 새벽에 당해보니 또 한 번 새겼다. 우리 팀이 운영하는 EKS 클러스터, 노드 38대, 워크로드 약 400개 정도 되는 규모다.알림 내용은 단순했다. httpClient.get 호출 P99가 폭증 중이라는 거. 외부 결제 SaaS 호출이 대부분이라 벤더 status 페이지부터 봤다. 다..

지난 화요일 새벽이었다. 4시 12분에 휴대폰이 부르르 울렸다. PagerDuty.vault-prod cluster: all nodes sealed침대에서 일어나면서 머릿속이 멍했다. 보통 vault가 sealed 상태로 돌아가는 일은 없다. unseal key는 사람이 들고 있지도 않다 — auto-unseal로 AWS KMS에 위임해놨으니까. 그런데 sealed라니. 노트북을 열면서 솔직히 멘탈이 좀 나갔다.첫 30분: 뭐가 죽었는지조차 몰랐다처음엔 vault 자체 이슈인 줄 알았다. 컨테이너가 OOM이라도 났나 싶어서 노드부터 확인했다. CPU도 메모리도 멀쩡했다. Pod도 다 running이었고. 그런데 vault status를 때려보면 매번 같은 응답이 돌아왔다.Sealed: trueTotal ..

지난주 화요일 새벽 3시쯤이었다. 슬랙 oncall 채널에 "그라파나 대시보드 일부 패널이 No data로 뜬다"는 핑이 올라왔다. 자다가 받은 알림이라 멘탈이 좀 나간 상태에서 노트북을 열었는데, 진짜로 우리 결제 서비스 P99 레이턴시 그래프가 새벽 1시 47분부터 약 한 시간 동안 비어 있었다.문제는 Prometheus 자체는 멀쩡했다는 거다. up{} 메트릭도 정상이고 로컬 쿼리도 잘 됐다. 그런데 Thanos를 통해 보던 장기 보관 대시보드에서만 그 구간이 통째로 비어 있었다. 결론부터 말하면 remote_write 큐가 막혀서 WAL에서 읽기가 블록됐고, 그 사이에 들어온 샘플들이 일부 누락됐다. 이게 내가 새벽 4시까지 깨어 있었던 이유다.처음 의심한 것들 (다 틀렸음)가장 먼저 의심한 건 ..

지난주 목요일 새벽 2시 47분. 알림 톡이 울려서 핸드폰을 봤더니 ArgoCD에서 동시에 11개 애플리케이션의 sync가 Degraded로 떨어졌다는 메시지였다. 처음엔 또 누군가가 이미지 태그를 잘못 박았겠지 싶었다. 새벽에 배포 멘션이 와있던 팀이 두 팀이었고, 자동 sync wave가 한꺼번에 돌고 있었으니까.그런데 콘솔을 열어보니 좀 이상했다. Pod 이벤트에 ImagePullBackOff가 줄줄이 떠있는데, 에러 메시지가 익숙하지 않았다.Failed to pull image ".dkr.ecr.ap-northeast-2.amazonaws.com/svc-foo:v1.42.0":rpc error: code = Unknown desc = failed to pull and unpack image:fai..

처음에 의심한 것들지난주 새벽 2시 반에 알람이 울렸다. P99 레이턴시 알람이었는데, 한두 번이면 그냥 무시하고 자고 다음 날 보겠지만 같은 알람이 5분 간격으로 계속 울렸다. 누워서 폰만 보다가 결국 노트북을 열었다.원인은 Karpenter였다. v1.0으로 올리고 한 달 정도 됐는데, 이 시점에 처음으로 큰 사고가 터졌다. 자려고 누웠다가 새벽 5시까지 깨어 있었던 그 밤 이야기를 정리해두려고 한다.알람이 P99 latency였으니까 당연히 애플리케이션을 먼저 봤다. 그런데 백엔드 트레이스를 까보니 응답 자체는 빠른데, 가끔 한 노드의 모든 파드가 동시에 사라지는 패턴이 보였다. terminated 이벤트가 5분에 한 번씩 떴다.처음엔 spot interruption인 줄 알았다. 우리 서비스 노드..

지난주 화요일 새벽 2시 47분알림이 울렸다. 캐시 레이어 P99가 평소 8ms 수준에서 4초까지 튀었다는 것이다. 멘탈이 나갔다. 침대에서 노트북을 펴는데 손이 약간 떨렸다.원인은 Redis Cluster slot resharding이었다. 평소처럼 야간 저트래픽 시간대에 노드 두 대를 추가하고 슬롯을 옮기는 작업이 돌아가고 있었는데, 이게 그냥 평범하게 끝나지 않았다. 몇 시간 동안 로그와 메트릭을 뒤지면서 알게 된 것들을 정리해둔다.우리 환경24노드 Redis Cluster (마스터 12, 레플리카 12). EKS 위에서 StatefulSet으로 운영 중이고, 키 수는 약 1.2억개, 메모리는 노드당 평균 28GB. 샤드 수가 늘어 일부 노드가 메모리 한계에 다다라서 노드를 추가하기로 했다. 새 노..

지난주 화요일 새벽이었다. EKS 클러스터 1.32 → 1.33 업그레이드를 돌리는 중이었는데, 노드 드레인이 4시간째 안 끝나고 있다는 슬랙 알림을 받았다. 새벽 3시였고, 솔직히 처음엔 드레인이 원래 좀 오래 걸리니까 그러려니 했다. 4시간이라는 숫자를 본 순간 멘탈이 한 번 흔들렸다.평소 같으면 워커 노드 한 대 드레인하는 데 길어야 10분 정도였다. 그런데 이번엔 한 노드에 박혀서 안 빠지는 파드가 있었고, 그 파드 하나가 전체 업그레이드 파이프라인을 막고 있었다. 결국 원인은 PDB(PodDisruptionBudget) 하나였다. 짧게 말하면 그렇고, 길게 말하면 우리 팀의 PDB 관리 방식 전체가 문제였다.처음 발견한 증상노드를 cordon하고 drain을 돌렸는데 이런 메시지가 계속 떴다.e..

지난주 화요일 새벽 2시였다. 핸드폰이 울렸다. 처음엔 무시했다. 두 번째 울렸을 때 눈이 번쩍 떠졌다. 화면에는 loki-write Pod 절반이 OOMKill로 죽고 있다는 알림이 떠 있었다. 멘탈이 나갔다.우리 팀이 Loki를 도입한 건 2년 전이고, 그동안 큰 사고는 없었다. 노드 40대 정도 클러스터에서 하루에 약 1.2TB 로그가 들어오는 규모다. 그런데 그날 밤 갑자기 인덱스가 비정상적으로 커지면서 ingester가 메모리를 다 잡아먹었다. 새벽 4시까지 PC 앞에 있었다. 이 글은 그때 무슨 일이 있었고, 결국 어떻게 푼 건지에 대한 회고다.사고 시작 — 시리즈 수가 갑자기 30배처음 본 건 Grafana에 띄워둔 Loki 자체 모니터링 대시보드였다. loki_ingester_memory_..