Incident Library

IL-0553 CircleCI · 2026-10-06database

워크플로 조율 서비스의 데이터베이스에서 트랜잭션 로그 볼륨이 차서 CircleCI 파이프라인과 잡이 멈추고 몇 시간 동안 늦게 시작했다

CircleCI 의 워크플로 조율 서비스는 모든 파이프라인, 워크플로, 잡의 상태를 추적하고 준비된 잡을 실행 플릿에 넘긴다. UI 에 보이는 잡 데이터와 작업이 끝났을 때 보내는 알림과 커밋 상태도 이 서비스가 만든다. 이 서비스의 상태를 담는 데이터베이스는 모든 변경을 전용 저장 볼륨의 트랜잭션 로그에 먼저 쓰고 그 로그를 계속 보관 처리해 공간을 다시 쓴다. 보관 처리가 밀려 볼륨이 차면 데이터베이스는 쓰기를 받지 않는다. 데이터베이스는 테이블마다 내부 기록을 유효하게 유지하는 autovacuum 유지 보수 작업을 주기적으로 돌리는데, 아주 큰 테이블에서는 이 작업이 테이블의 모든 페이지를 읽고 트랜잭션 로그를 대량으로 쓴다.

2026년 10월 6일 12시 40분쯤 가장 큰 테이블 몇 개의 autovacuum 이 트랜잭션 로그를 보관 처리 속도보다 빠르게 쓰기 시작했고 로그 볼륨이 차오르기 시작했다. 엔지니어들은 10시 2분부터 울리던 짧은 오류 알림을 전에도 본 비슷한 알림으로 보고 런북대로 대응했다. 13시 30분부터 조율 서비스가 느려지고 여러 서비스의 알림이 함께 울렸으며, 14시 54분에 장애를 선언했다. 엔지니어들은 느려진 원인이 anti-wraparound autovacuum 이라는 것을 찾아냈다. 이 작업은 취소하면 데이터베이스가 자동으로 다시 시작하기 때문에, 엔지니어들은 작업이 빨리 끝나도록 설정을 바꿨다.

15시 43분에 트랜잭션 로그 볼륨이 거의 찼다. 데이터베이스가 읽기 전용이 되는 것을 막으려고 엔지니어들은 로그를 여유 공간이 많은 데이터베이스의 주 저장 볼륨으로 옮기기로 했다. 옮기는 동안 데이터베이스가 내려가야 했고, 15시 48분부터 16시 38분까지 50분 동안 조율 서비스가 아무 작업도 처리하지 못했다. 엔지니어들은 그동안 대체 데이터베이스를 준비했지만 원래 데이터베이스가 먼저 돌아와 그대로 썼다. 로그와 일반 데이터가 같은 저장소를 쓰게 되자 데이터베이스는 평소의 절반쯤 되는 속도로 작업을 처리했다. 엔지니어들은 유지 보수 작업이 더 시작되지 않도록 데이터베이스 파라미터를 바꿨고, 데이터 손실 위험을 안고 옮겨 갈 수 있는 서비스 전체 스택도 준비했지만 옮기지 않기로 했다.

18시 19분에 엔지니어들이 쓰기마다 저장소를 기다리는 시간을 줄이는 데이터베이스 설정을 바꾸자 처리 속도가 돌아왔다. 잡을 실행 플릿에 넘기는 시스템에 데이터베이스와 서버 용량을 더해 밀린 작업을 빨리 처리했고, 19시 55분쯤 새 잡이 제때 시작했다. 밀린 작업이 실행 플릿에 몰려 일부 Docker 잡이 용량이 늘 때까지 기다렸고, 20시 30분에 잡 시작 시간이 정상으로 돌아왔다. 20시 32분에 상태 페이지 공지를 모니터링 단계로 바꾸고 21시 19분에 장애를 종료했다. 잡 3,500개쯤이 시작하지 못했고, CircleCI 는 어떤 잡도 두 번 실행한 증거를 찾지 못했다.

심각도
–
영향 범위
Creating pipelines and starting workflows and jobs on CircleCI was delayed from 15:30 to 20:30 UTC and stopped from 15:48 to 16:38 UTC; pipelines triggered from 16:02 UTC failed; UI data, notifications and commit status updates were delayed; about 3,500 jobs failed to start
영향 사용자
CircleCI customers
지역
–
감지까지
5m
복구까지
7h

증상

2026년 10월 6일 13시 30분 UTC부터 CircleCI 의 워크플로 조율 서비스가 느려져 일부 파이프라인과 잡이 이따금 조금씩 늦게 시작했다. 15시 30분부터는 지연이 계속 이어졌고 일부 잡이 실패하기 시작했다.

그 전인 10시 2분부터 모니터링이 조율 서비스의 오류 알림을 짧게 여러 번 냈다. 알림은 매번 15분쯤 안에 저절로 풀렸다. 엔지니어들은 비슷한 짧은 알림을 전에도 봤고 다른 이상 신호도 없어서 매번 런북대로 대응했다. 알림을 덜 민감하게 만드는 작업도 시작했다.

13시 35분에 모니터링이 다시 알림을 냈고, 이번에는 여러 다른 서비스의 관련 알림이 함께 울렸다. 인프라 엔지니어들이 런북대로 일부 알림을 정리했지만 14시 30분쯤 알림이 다시 울렸고, 더 조사한 뒤 14시 54분에 장애를 선언했다.

15시 48분부터 16시 38분까지 조율 서비스는 어떤 작업도 처리하지 못했다. 고객은 파이프라인을 트리거할 수는 있었지만 워크플로와 잡은 하나도 시작되지 않았고, 16시 2분부터 새로 트리거한 파이프라인은 실패했다.

데이터베이스가 돌아온 16시 38분부터 18시 19분까지 조율 서비스는 평소의 절반쯤 되는 속도로 작업을 처리했다. 잡은 시작까지 수십 분을 기다렸고 가장 길게는 50분쯤 기다렸다. 상태 페이지는 시작 시간이 한때 평균 40분쯤까지 늘었고 아주 적은 수의 워크플로는 1시간 넘게 기다렸다고 적었다.

CircleCI UI 에 잡, 워크플로, 파이프라인 데이터가 나타나기까지 최대 15분이 걸렸다. 외부로 나가는 알림과 웹훅, 버전 관리 서비스로 보내는 커밋 상태 갱신도 늦어졌다. 알림과 웹훅은 19시쯤까지 보통 1분쯤 늦게 나갔다.

밀린 작업이 실행 플릿으로 넘어가자 19시 49분부터 20시 30분까지 큰 리소스 클래스의 Docker 잡이 용량이 늘어나는 동안 최대 10분쯤 기다렸다. 상태 페이지는 20시 5분쯤 대기 시간이 2xlarge gen2 에서 최대 8분쯤, xlarge gen2 에서 6분쯤, 다른 몇몇 리소스 클래스에서 5분 미만이었다고 적었다.

증상 지연 시간 증가서비스 중단처리량 저하노드 디스크 가득 참

원인

원인 용량 한계

구성 요소 데이터베이스PostgreSQL vacuumCI 시스템
기여 요인 초기 신호 무시한계 경보 부재단일 장애점
촉발
10월 6일 12시 40분쯤 데이터베이스의 가장 큰 테이블 몇 개에서 돌던 정기 유지 보수 작업인 anti-wraparound autovacuum 이 평소 작업량과 겹치면서, 데이터베이스가 트랜잭션 로그를 보관 처리하는 속도보다 빠르게 로그를 썼다.

감지

10시 2분부터 모니터링이 조율 서비스의 오류 알림을 짧게 여러 번 냈지만 매번 저절로 풀렸다. 13시 35분에 여러 다른 서비스의 관련 알림과 함께 다시 울렸고, 14시 30분쯤 알림이 다시 울리자 더 조사한 뒤 14시 54분에 장애를 선언했다. 트랜잭션 로그 볼륨이 얼마나 찼는지와 보관 처리가 얼마나 밀렸는지를 보는 알림은 없었다. 상태 페이지에는 15시 58분에 공지를 올렸고 16시 20분에 주요 장애로 올렸다.

조치

후속 조치

교훈

CircleCI 는 여러 알림이 함께 울린 것을 더 일찍 알아챘어야 했다고 밝혔다. 모니터링은 느려진 것을 잡았지만 트랜잭션 로그 볼륨이 찬 정도와 보관 처리가 밀린 정도에는 알림이 없었다. 조율 서비스의 모든 쓰기가 데이터베이스 하나와 트랜잭션 로그 하나를 거치기 때문에, 그 로그가 밀리자 모든 파이프라인, 워크플로, 잡이 함께 느려졌다. 일부 잡은 다른 시스템들이 재시도 끝에 포기해서 실패했다. 고객들은 초기 상태 페이지 공지에 세부 내용이 부족했다고 알려 왔다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, PostgreSQL vacuum, CI 시스템. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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