Incident Library
적용된 필터 구성 요소데이터베이스증상간헐적 타임아웃조직Buildkite모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례1건

1건 중 1~1번째

  1. 증상

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

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

이 사례에서 가장 많이 나오는 구성 요소: 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1