사례3건

3건 중 1~3번째

1. IL-0470 알림 처리 워커가 모자라 Buildkite 알림 전달이 두 차례 늦어졌다

   Buildkite2026

   증상

   2026-05-28 20:01 UTC 부터 알림 처리 워커가 모자라 Buildkite 의 알림 전달 지연이 늘었다. 내부 큐 지연 모니터링이 이를 잡았다.

   지연 시간 증가오토스케일러 오동작

   촉발

   EKS 의 오토스케일링이 쓰는 Prometheus 서비스의 저장 공간이 다 찼다. 그래서 큐가 쌓이는 동안 EKS 위의 알림 처리 워커 일부가 제대로 늘지 못했다.

   원인

   용량 한계

   구성 요소

   Prometheus

   기여 요인

   한계 경보 부재부분 배포롤백 무효미검증 가정수동 조치 악화

   감지

   팀은 내부 큐 지연 모니터링으로 장애를 알아챘다. 공개 상태 페이지에는 20:20 UTC 에 첫 공지가 올라왔다.

   조치

   • 영향받은 워크로드를 EKS 에서 이전의 ECS 인프라로 옮기기 시작했다.
   • ECS 서비스가 전체 부하를 바로 받지 못해 엔지니어가 장애 중에 스케일링 설정과 워커 수를 손으로 조정했다.
   • 두 번째 지연은 롤백을 마저 끝내고 남은 ECS 서비스를 늘려 해소했다.
   • Prometheus 저장 공간을 늘리고, 같은 변경을 인프라 코드에도 반영했다.

   후속 조치

   • Prometheus 저장 공간이 바닥나 오토스케일링에 영향을 주기 전에 알림이 오도록 모니터링을 더한다.
   • 특정 종류의 오류에서 GitHub 알림 재시도가 되풀이되어 알림 지연을 늘리는 동작을 고친다.
   • EKS 에서 ECS 로 되돌리는 롤백 절차를 보강해, 롤백 전과 도중에 옮겨 갈 쪽의 용량, 오토스케일링 설정, 트래픽 이동을 확인하게 한다.
   • KEDA 와 Karpenter 를 비롯해 EKS 컨트롤 플레인이 의존하는 다른 구성 요소를 검토하고, CPU, 메모리, 저장 공간 할당이 운영 부하에 맞는지 확인한다.
   • 앞으로 EKS 로 옮기는 순서와 속도를 다시 따져, 고객에게 중요한 워크로드는 더 천천히 옮기고 안정될 시간을 분명히 둔다.
   • 고객 단위로 알림 전달 지연을 보는 모니터링을 개선해 고객에게 영향을 주는 회귀를 더 일찍 잡는다.
   • 어떤 알림 종류가 고객의 스케줄링이나 CI 의 핵심 경로에 있는지 검토한다. 그런 알림에는 더 엄격한 지연 기준, 별도 큐, 일반 알림 작업보다 구체적인 모니터링 경보가 필요한지 따진다.
   • 알림 지연이 고객의 작업 흐름에 영향을 줄 것 같으면 상태 페이지를 더 일찍 갱신한다.
   • 상태 페이지에 영향받은 내부 서비스만이 아니라 고객이 겪는 영향을 분명하게 적는다.
   • 장애를 다 파악하기 전이라도 심각한 CI 영향을 알려 오는 고객의 문의가 내부에서 빨리 올라가도록 에스컬레이션 경로를 개선한다.

   교훈

   Buildkite 는 롤백 경로가 이번 상황을 다 다루지 못해 복구가 예상보다 오래 걸렸다고 보았다. 알림 지연의 영향은 고객이 알림을 CI 와 배포 흐름에 어떻게 쓰는지에 따라 다르게 나타난다. Buildkite 는 공개 상태 페이지가 고객이 겪는 영향을 제때 분명하게 보여 주지 못했다고 밝혔다.

   사례 보기
2. 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 파드와 노드 상태의 관측 수단과 모니터를 더했다.

   사례 보기
3. IL-0547 Buildkite 의 Agent API, REST API, GraphQL 이 annotations 테이블 쿼리 타임아웃으로 4시간 가까이 저하됐다

   Buildkite2025

   증상

   2025년 11월 10일 04:48 UTC 부터 Buildkite 의 Agent API 가 대부분의 고객에게 심하게 저하됐고, REST API, GraphQL, Web UI 도 오류율이 오르고 느려졌다.

   간헐적 타임아웃데이터베이스 과부하오류율 상승지연 시간 증가

   촉발

   2025년 11월 10일 04:48 UTC 에 Pipelines 제품의 annotations 를 저장하는 테이블에서 인덱스 하나를 지우는 데이터베이스 마이그레이션이 적용됐다. 대신할 인덱스가 이미 있었지만 트래픽이 많은 일부 쿼리가 새 인덱스를 타지 않았다.

   원인

   배포 결함

   구성 요소

   데이터베이스

   기여 요인

   리뷰 누락단계적 배포 부재

   감지

   04:53 UTC 에 annotations 테이블 쿼리의 타임아웃으로 인덱스 삭제의 영향이 감지됐다.

   조치

   • 바로 지운 인덱스를 다시 만들기 시작해 05:30 UTC 까지 데이터베이스 샤드의 절반쯤에서 끝냈고, 서비스 일부가 돌아왔다.
   • 나머지 샤드의 부하를 줄이려고 애플리케이션 사용자의 annotations 테이블 읽기·쓰기 권한을 잠시 뺐다.
   • Postgres 의 max_parallel_maintenance_workers 를 늘려 인덱스 생성 속도를 크게 올렸다.
   • 07:50 UTC 부터 08:43 UTC 까지 읽기·쓰기 권한을 뺀 상태에서 나머지 샤드의 인덱스를 다시 만들었고, Agent API, REST API, GraphQL 의 지연과 오류율이 평소 수준으로 돌아왔다.
   • 일관되지 않은 상태로 남은 에이전트를 풀어 주고 잡 상태를 정리했다. 스스로 회복하지 못한 경우는 손으로 처리했고 11:56 UTC 에 끝났다.

   후속 조치

   • 코드 리뷰 때 위험한 마이그레이션을 짚어 주는 내부 도구가 인덱스 삭제도 다루도록 넓혔다. 이 도구는 인덱스를 지우는 마이그레이션을 배포하기 전에 그 인덱스가 더는 필요 없는지 엔지니어가 확인하게 한다.
   • 지금은 데이터베이스 마이그레이션이 모든 샤드에 동시에 적용된다. 위험도가 높은 마이그레이션은 단계적으로 적용해 영향 범위를 좁히고, 문제가 생기면 더 빨리 복구할 수 있게 한다.
   • 인덱스를 만들거나 지울 때의 분석을 개선하려고 HypoPG 같은 도구를 검토한다.
   • pganalyze 의 인덱스 사용 데이터를 개발 흐름에서 더 잘 보이게 해, 엔지니어가 그 데이터를 보고 인덱스 변경을 결정하게 한다.
   • 일부 에이전트의 일관되지 않은 상태를 풀 때 쓴 수작업 정리를 자동화해, 비슷한 문제에서 시스템이 스스로 회복하게 한다.

   교훈

   Buildkite 는 이 장애가 주로 데이터베이스 마이그레이션 하나에서 비롯됐고, 그 마이그레이션이 검토 과정의 빈틈을 드러냈다고 밝혔다.

   사례 보기

원인별2