사례11건

11건 중 1~5번째

1. IL-0548 EKS 의 Prometheus 가 거듭 죽으며 Buildkite 의 알림 전달과 빌드 디스패치가 지연됐다

   Buildkite2026

   증상

   일부 Buildkite 고객에게 알림 전달, 빌드 디스패치, 지표 서비스의 지연이 커졌다. 상태 페이지에는 2026년 5월 20일 16:40 UTC 에 모든 고객의 알림 지연을 조사한다는 글이 올라왔다.

   지연 시간 증가OOMKilled모니터링 중단오토스케일러 오동작

   촉발

   오토스케일링으로 Prometheus 가 추적하는 파드 수가 늘었고, 그만큼 Prometheus 서버의 메모리 요구량이 커졌다.

   원인

   용량 한계

   구성 요소

   Prometheus컨테이너 메모리 한도노드 풀

   기여 요인

   리소스 요청과 한도 미설정

   조치

   • 당번 팀이 미리 마련한 문서를 따라 영향을 받은 서비스의 부하를 Fargate 로 되돌렸고, 대부분의 고객이 16:49 부터 완전히 회복됐다.
   • 지연 동안 백로그가 크게 쌓인 일부 고객의 처리 규모를 손으로 더 늘렸고, 17:33 에 모든 고객이 완전히 회복됐다.

   후속 조치

   • 시스템 노드의 크기를 키웠다.
   • Prometheus 서버가 더 많은 제품 부하를 감당하도록 requests 와 limits 를 높였다.
   • 새 EKS 리소스 전부를 검토해 빠진 requests 와 limits 를 채웠다. EKS 가 뜻하지 않은 리소스 경합을 막으려면 이 정보가 모두 있어야 한다.
   • 다음 장애에서 근본 원인을 빨리 찾도록 EKS 파드와 노드 상태의 관측 수단과 모니터를 더했다.

   사례 보기
2. IL-0042 OpenSearch 디스크가 가득 찬 동안 fluent-bit 가 로그를 처리하지 못해 Elasticsearch 와 OpenSearch 에 애플리케이션 로그가 들어오지 않았다.

   UK Ministry of Justice2024

   증상

   14:27 에 사용자가 #ask-cloud-platform 채널로 Kibana 에 13:45 부터 로그가 들어오지 않는다고 알려 왔다.

   모니터링 중단

   촉발

   OpenSearch 의 디스크 공간이 바닥나 인덱스 쓰기가 막혔다.

   원인

   용량 한계

   구성 요소

   텔레메트리 에이전트Elasticsearch 와 OpenSearch

   기여 요인

   한계 경보 부재

   감지

   원문은 처음 감지된 시각을 12:10 으로 적었다. 이때 cp-live-app-logs 에서 ClusterIndexWritesBlocked 경보가 시작됐다. 팀이 실제로 문제를 알게 된 것은 14:27 에 사용자가 #ask-cloud-platform 채널로 Kibana 에 13:45 부터 로그가 들어오지 않는다고 알려 왔을 때였다.

   조치

   • 14:59 에 fluent-bit 컨테이너를 모두 rollout restart 했다. 로그가 잠깐 일부 흘렀지만 같은 오류가 다시 났다.
   • OpenSearch 디스크 공간을 8000 에서 12000 으로 늘렸다.
   • 근본 원인을 조사하는 동안 임시 조치로 fluent-bit 가 OpenSearch 로 로그를 보내지 않게 설정했다.

   후속 조치

   • OpenSearch 와 Elasticsearch 의 인덱스 날짜 문제를 살핀다.
   • Elasticsearch 와 OpenSearch 에 우선순위 높은 경보를 만든다.
   • OpenSearch 를 live 로깅에 다시 넣는다.
   • fluent-bit 의 “failed to flush chunk” 오류를 조사한다.

   사례 보기
3. IL-0044 kube-prometheus-stack 업그레이드 뒤 Prometheus 가 WAL 재생 중 메모리를 50Gi 넘게 써서 시작할 때마다 OOMKilled 로 죽었다

   Saifeddine Rajhi2024

   증상

   kube-prometheus-stack 헬름 차트를 업그레이드하는 중에 여러 파드가 Ready 가 되지 않았다. 그중 prometheus-prometheus-operator-prometheus-0 파드는 3/4 Running 상태였고 최근에 OOMKilled 로 종료된 기록이 있었다.

   OOMKilled프로브 실패모니터링 중단

   촉발

   kube-prometheus-stack 헬름 차트를 업그레이드하던 중 Prometheus 가 시작하면서 WAL 을 재생했고, 이 과정에서 메모리 사용량이 메모리 제한을 넘었다.

   원인

   용량 한계

   구성 요소

   Prometheus컨테이너 메모리 한도

   기여 요인

   한계 미인지여유 용량 부재

   감지

   팀은 kube-prometheus-stack 헬름 차트를 업그레이드하던 중 Prometheus 파드를 포함한 여러 파드가 Ready 가 되지 않는 것을 보았다. kubectl describe pod 와 Prometheus 로그로 OOMKilled 를 확인했다.

   조치

   • Prometheus 파드에 kubectl exec 로 들어가 promtool tsdb analyze . 를 실행해 haproxy_server_http_responses_total 처럼 카디널리티가 높은 지표를 찾았다.

   후속 조치

   • WAL 재생 중 메모리 오버헤드가 10% 에서 15% 정도의 허용 범위 안에 있는지 확인하고, Prometheus 를 메모리 제한에 가깝게 운영하지 않는다.
   • Prometheus 의 저장, 스크레이프, remote write 설정을 정기적으로 최적화하고, 최적화가 들어간 새 릴리스로 업그레이드한다.
   • OOM 크래시 루프에서 자동으로 복구하는 장치를 만든다. 예를 들어 OOM 이벤트가 나면 WAL 을 자동으로 지운다.
   • 메모리 사용량이 일정 기준을 넘으면 스크레이프를 멈추는 강제 스크레이프 제한을 둔다.

   교훈

   Prometheus 를 메모리 제한에 가깝게 운영하면 WAL 재생 중의 작은 오버헤드로도 OOM 이 난다. 가비지 컬렉션은 들쭉날쭉하고 카디널리티나 쿼리는 갑자기 늘 수 있으므로 메모리에 여유를 둔다. Prometheus 메모리 문제의 상당 부분은 카디널리티에서 온다. Prometheus 가 떠 있지 않을 때는 promtool tsdb analyze 로 카디널리티가 높은 지표를 찾는다. 메모리 제한만 올려서는 답이 되지 않았다. 메모리가 치솟는 것은 재생 단계뿐이었기 때문이다.

   사례 보기
4. IL-0046 계획된 재시작 뒤 Prometheus 가 WAL 을 다 읽기 전에 startupProbe 에 걸려 재시작을 반복했고 지표가 빠졌다

   UK Ministry of Justice2024

   증상

   2024-04-15 12:32 에 계획된 Prometheus 변경을 적용한 뒤 Prometheus 를 쓸 수 없게 되었다. 팀은 prometheus 파드가 여러 번 재시작한 것을 보았다. 그동안 Cloud Platform 에는 모니터링이 없었고 지표가 빠졌다.

   모니터링 중단프로브 실패

   촉발

   계획된 변경으로 Prometheus 를 재시작했는데 그때 WAL 수가 평소보다 많아, WAL 다시 읽기가 startupProbe 기본 허용 시간인 15분 안에 끝나지 않았다.

   원인

   용량 한계

   구성 요소

   Prometheus

   기여 요인

   기본 설정 방치한계 미인지

   감지

   계획된 Prometheus 변경 뒤 팀이 prometheus 파드가 여러 번 재시작한 것을 보고 알았다. 처음 감지한 시각은 2024-04-15 12:32 였다.

   조치

   • startupProbe 허용 시간을 기본값 15분에서 30분으로 늘려 WAL 다시 읽기가 끝날 때까지 기다리게 했다.

   후속 조치

   • 팀은 계획된 Prometheus 재시작을 WAL 수가 적을 때 해서 재시작 시간을 줄이는 방안을 논의했다.
   • Prometheus 의 기본 CPU 와 메모리 요청값을 최대 사용량에 맞춰 설정했다.
   • 운영 환경의 WAL 수를 재현하는 테스트 환경을 만든다.
   • memory-snapshot-on-shutdown 과 auto-gomaxprocs 기능 플래그를 검토한다.
   • WAL 파일을 다른 위치의 원격 저장소에 두는 방법을 검토한다.
   • 운영과 같은 구성의 블루그린 Prometheus 를 만들어 운영에 적용하기 전에 변경을 시험하는 방안을 알아본다.
   • Amazon Managed Prometheus 를 간단히 조사한다.

   사례 보기
5. IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.

   DFDS2024

   증상

   2024-03-13 10:01 UTC 에 쿠버네티스 노드 하나가 NotReady 상태가 됐다. 그때 노드에 잡힌 requests 는 CPU 78%, 메모리 82% 였다. 10:03 에 Slack 으로 알림이 왔고, 10:05 에 알림을 보고 조사를 시작했다.

   노드 NotReady컨테이너 재시작 반복OOMKilled모니터링 중단

   촉발

   Hangfire 로 작업을 실행하는 개발 컨테이너가 Grafana Agent 가 메모리를 많이 쓰고 있던 노드에 배치됐고, 작업이 OOM 으로 실패하며 CrashLoopBackOff 를 반복했다.

   원인

   용량 한계

   구성 요소

   텔레메트리 에이전트컨테이너 메모리 한도데이터베이스

   기여 요인

   과도한 영향 범위리소스 요청과 한도 미설정수동 조치 악화모니터링 사각지대

   감지

   10:03 UTC 에 Slack 으로 알림이 왔고, 10:05 에 알림을 확인하고 조사를 시작했다. 두 번째 노드는 15:03 에 Slack 알림이 왔고 15:09 에 확인했다. 탐지까지 걸린 시간은 4분이었다.

   조치

   • 10:22 에 EC2 인스턴스를 비정상으로 표시해 새 노드를 띄웠다.
   • 10:30 에 NotReady 노드를 cordon 하고 강제로 drain 했고, 10:36 에 그 EC2 인스턴스를 종료했다.
   • 13:02 에 네임스페이스에서 LimitRange 를 지우고 Grafana Agent 파드를 재시작했다.
   • 14시대에 문제의 개발 컨테이너를 0개로 줄였고, 몇 분 뒤 EC2 네트워크 트래픽이 정상으로 돌아왔다.
   • 두 번째 NotReady 뒤 15:15 에 개발 컨테이너를 다시 0개로 줄였고, 15:18 에 새 노드가 추가됐다.
   • 15:19 에 개발 컨테이너를 맡은 팀에 메일을 보냈고, 15:52 에 그 팀이 문제를 확인하고 수정 중이라고 답했다.

   후속 조치

   • grafana-agent 를 모니터링 노드 그룹으로 옮긴다.
   • 클러스터 전체 대역폭이 정해 둔 기준에 닿으면 알림을 보낸다.
   • grafana-agent Helm 차트에 메모리 한도를 걸 수 있는지 조사한다.
   • grafana-agent 의 메모리 사용량을 조사한다.
   • grafana-agent 에 PVC 를 써야 하는지 Grafana 지원팀에 묻는다.
   • 보존 기간을 제한한 채 노드 로그를 Loki 로 보내는 방안을 검토한다.
   • 쿠버네티스 노드 문제를 조사할 때 확인할 자주 쓰는 지표와 로그 쿼리를 위키 페이지로 만든다.

   교훈

   포스트모템에서 나온 후속 조치를 끝까지 챙겨야 한다. CloudWatch 에서 어떤 지표가 쓸모 있는지가 팀에 제대로 공유되지 않아 진단과 조사가 어려웠다.

   사례 보기

원인별1