Incident Library

IL-0548 Buildkite · 2026-05-20kubernetesawsobservability

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

Buildkite 는 운영 워크로드의 컴퓨팅 기반을 AWS Fargate 에서 AWS EKS 로 옮기고 있었다. 서비스는 안정성을 확인하며 작은 묶음으로 옮겼다.

15:42 부터 17:33 사이에 EKS 의 Prometheus 서버가 쓰려는 메모리가 실행 중인 호스트의 메모리보다 많아졌다. 오토스케일링으로 Prometheus 가 추적하는 파드 수가 늘었고, 그만큼 Prometheus 서버의 메모리 요구량이 커졌다. 호스트가 Prometheus 서버 프로세스를 죽였고 쿠버네티스 컨트롤 플레인이 곧 다시 띄웠다. 그사이 애플리케이션 오토스케일링에 쓰는 지표가 없어 영향을 받은 서비스들이 확장되지 않았고, 그 결과 지연이 생겼다. Prometheus 는 재시작 직후 다시 호스트 메모리를 넘었고 같은 순환이 되풀이됐다.

당번 팀은 미리 마련한 문서를 따라 영향을 받은 서비스의 부하를 Fargate 로 되돌렸다. 대부분의 고객은 16:49 부터 완전히 회복됐다. 지연 동안 백로그가 크게 쌓인 일부 고객은 손으로 더 확장해야 했고, 17:33 에 모든 고객이 완전히 회복됐다. Buildkite 는 그 뒤 이 서비스들을 모두 다시 EKS 로 옮겼고, 이번 장애에서 부딪힌 한계를 훨씬 넘는 규모까지 확장이 잘 되는 것을 확인했다.

심각도
–
영향 범위
Elevated latency in notification delivery (GitHub commit status, email, Slack and webhook notifications), build dispatch and metrics services
영향 사용자
A subset of Buildkite customers
지역
–
감지까지
–
복구까지
1h 51m

증상

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

15:42 부터 EKS 의 Prometheus 서버가 쓰려는 메모리가 실행 중인 호스트의 메모리보다 많아졌다. 호스트가 Prometheus 서버 프로세스를 죽였고 쿠버네티스 컨트롤 플레인이 곧 다시 띄웠지만, Prometheus 는 재시작 직후 다시 호스트 메모리를 넘었고 같은 일이 되풀이됐다.

Prometheus 가 내려가 있는 동안 애플리케이션 오토스케일링에 쓰는 지표가 없었다. 그래서 영향을 받은 서비스들이 확장되지 않았고, 그 결과 지연이 생겼다.

상태 페이지는 17:06 UTC 에 알림 지연이 일부 고객에게만 있다고 알렸다. 영향을 받은 알림은 GitHub Commit Status Notifications, Email Notifications, Slack Notifications, Webhook Notifications 였다.

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

원인

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

감지

–

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: Prometheus, 컨테이너 메모리 한도, 노드 풀. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.