{"id":"IL-0552","org":"CircleCI","date":"2025-01-21","docs":[],"title":{"en":"CircleCI's archival database ran out of storage, slowing workflow and job starts and the display of workflows in the UI","ko":"보관 데이터베이스의 저장 공간이 차서 CircleCI 워크플로 시작이 늦어지고 UI에서 워크플로가 잘 보이지 않았다"},"domain":["database"],"impact":{"scope":"Starting and cancelling workflows and jobs on CircleCI was slow and the CircleCI UI had trouble showing workflows; Linux machine jobs then queued (Pipelines & Workflows and CircleCI UI)","users":"CircleCI customers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The storage alert on the archival database did fire, but the database filled much faster than forecast, so there was little time to act before customers were affected. Because the workflows service called the archival service synchronously, a problem in the archival database slowed the whole workflows service.","ko":"보관 데이터베이스의 문제를 알리는 알림은 울렸지만, 데이터베이스가 예측보다 훨씬 빨리 차서 고객 영향이 나기 전에 대응할 시간이 거의 없었다. 워크플로 서비스가 보관 서비스를 동기로 호출하기 때문에 보관 쪽 문제가 워크플로 전체의 지연으로 번졌다."},"related":[],"sources":[{"url":"https://status.circleci.com/incidents/ym5vldzgvxv5","kind":"official-status","archived":"https://web.archive.org/web/20250911125351/https://status.circleci.com/incidents/ym5vldzgvxv5"}],"summary":{"en":"CircleCI's workflows service calls the archival service synchronously when it archives workflows. A code change to a function in the archival service's database on 16 January 2025 unintentionally made the database write an excessive number of log messages, and the database filled far faster than CircleCI had forecast. At about 23:00 UTC on 21 January an alert warned that the database was almost out of free storage. Halting a blue/green deployment at 23:09 to free a logical replication slot did not help. When the database reached capacity, calls from the workflows service timed out, the workflows queue grew from 23:26, and customers saw delays from 23:50. Another team scaled up the event consumer that processes the queue at 23:44, and the team on the database promoted a read replica to a standalone primary at 23:55. The workflows queue was back to normal by 00:03.\n\nAt about the same time, Linux machine jobs began to queue because provisioning instances with CircleCI's cloud provider returned errors; the provider was investigating increased API error rates on the provisioning endpoint in that region. Requests began to be fulfilled around 00:32, but the volume of requests met rate limiting, which lengthened the impact. Queues were normal at 00:56 UTC and the incident was resolved at 01:26 UTC. After the incident the database function was changed to stop the excessive logging.","ko":"2025년 1월 16일에 CircleCI 의 보관 데이터베이스 안 함수 하나를 고친 코드 변경이 의도치 않게 로그 메시지를 대량으로 만들었고, 이 데이터베이스의 저장 공간이 예측보다 훨씬 빨리 찼다. 1월 21일 23시 UTC쯤 저장 공간이 거의 없다는 알림이 울렸다. 팀은 23시 9분에 블루/그린 배포를 멈춰 논리 복제 슬롯을 비웠지만 데이터베이스는 회복하지 않았다.\n\n워크플로를 조율하는 서비스가 보관 서비스를 동기로 호출하기 때문에, 보관 데이터베이스가 용량 한계에 닿자 호출이 타임아웃되고 워크플로 서비스 전체가 느려졌다. 23시 26분부터 워크플로 대기열이 늘어 워크플로와 잡의 시작과 취소가 느려지고 UI에서 워크플로를 보기 어려워졌다. 거의 같은 시각에 요청량 알림이 따로 울려, 팀이 지연을 보관 데이터베이스 문제와 연결하는 데 시간이 걸렸다. 다른 팀이 23시 44분에 대기열을 처리하는 이벤트 소비자를 증설했고, 데이터베이스를 맡은 팀이 23시 55분에 읽기 복제본을 독립된 주 인스턴스로 승격했다. 0시 3분에 워크플로 대기열이 정상으로 돌아왔다.\n\n같은 무렵 클라우드 사업자의 프로비저닝 엔드포인트에서 API 오류율이 올라 Linux 머신 잡이 뒤 단계의 대기열에 쌓였다. 요청은 0시 32분쯤 처리되기 시작했지만 몰린 요청량 때문에 속도 제한이 걸려 영향이 길어졌다. 대기열은 0시 56분에 정상 수준으로 돌아왔고, 추가 영향이 없음을 확인한 뒤 1시 26분에 장애를 종료했다. 사고 뒤 조사에서 함수 변경이 원인으로 밝혀졌고, CircleCI 는 그 함수를 고쳤다."},"trigger":{"en":"A code change to a function in the archival database on 16 January 2025 unintentionally made it write an excessive number of log messages, and the database filled its storage.","ko":"1월 16일에 보관 데이터베이스의 함수 하나를 고친 코드 변경이 의도치 않게 로그 메시지를 지나치게 많이 만들어 냈다."},"severity":"unknown","symptoms":["high-latency","intermittent-timeouts","log-flood","node-disk-full","cloud-api-rate-limited"],"timeline":{"detected_after":null,"resolved_after":"1h 6m"},"date_kind":"incident","detection":{"en":"An automated alert at about 23:00 UTC warned that the archival database was almost out of free storage, before customers were affected. The growing workflows queue was not linked to it at first because a separate alert about request volume fired at about the same time.","ko":"23시쯤 보관 데이터베이스의 남은 저장 공간이 거의 없다는 자동 알림이 울렸다. 같은 시각에 요청량 알림이 따로 울려 팀은 워크플로 지연을 곧바로 이 문제와 연결하지 못했다. 그 알림이 해결된 뒤에도 대기열이 늘자 다른 팀이 조사에 나섰다."},"components":["database","ci-system"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Scaled up the event consumer that processes the workflows queue at 23:44 UTC","ko":"23시 44분에 워크플로 대기열을 처리하는 이벤트 소비자를 증설했다."}},{"text":{"en":"Promoted a read replica of the archival database to a standalone primary at 23:55 UTC","ko":"23시 55분에 문제가 난 보관 데이터베이스의 읽기 복제본을 독립된 주 인스턴스로 승격했다."}}],"action_items":[{"text":{"en":"Fix the database function so it no longer writes an excessive number of log messages","ko":"로그 메시지를 지나치게 많이 만들던 데이터베이스 함수를 고쳤다."}},{"text":{"en":"Add a max duration to the workflows retry policy for archiving so it fails earlier than the default timeout","ko":"워크플로 보관 호출의 재시도 정책에 최대 지속 시간을 두어 기본 타임아웃보다 일찍 실패하게 하고, 보관 서비스에 문제가 생겨도 워크플로 서비스가 받는 영향을 줄인다."}},{"text":{"en":"Move workflow archival to an event-based model that decouples it from the workflows service","ko":"장기적으로 워크플로 보관 과정을 이벤트 기반 방식으로 바꿔 두 서비스를 떼어 놓는다."}},{"text":{"en":"Add forecast and anomaly monitoring for databases that alerts on unusual activity before it reaches critical levels","ko":"데이터베이스에 예측 모니터링과 이상 탐지 모니터링을 더해, 이상한 움직임이 위험 수준에 닿기 전에 알림을 받는다."}}],"contributing":["delayed-effect-change","blast-radius-too-wide","overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"At about 23:00 UTC on 21 January 2025, an automated alert reported that the CircleCI database instance holding archived data was almost out of free storage space. From 23:50 UTC customers saw slow starts and cancellations of workflows and jobs, and delays and difficulty viewing workflows in the CircleCI UI, although pipelines for a specific project could still be viewed.\n\nThe first action on the database did not help. At 23:09 the team halted a blue/green deployment on the database to free a logical replication slot, suspecting the slot was the cause, but the database did not recover.\n\nThe workflows service calls the archival service synchronously, so when the archival database reached capacity those calls began timing out and the workflows queue grew from 23:26. The growth was not linked to the archival database at first, partly because a separate alert about request volume fired at about the same time. When the queue kept growing after that other issue resolved, a second team investigated workflows. After the queue recovered at 00:03, Linux machine jobs queued because provisioning instances with the cloud provider returned errors, and the volume of requests then ran into rate limiting until queues were normal at 00:56.","ko":"2025년 1월 21일 23시 UTC쯤, 보관 데이터를 담는 데이터베이스 인스턴스의 남은 저장 공간이 거의 없다는 자동 알림이 울렸다. 23시 26분부터 워크플로 대기열이 늘면서 워크플로와 잡의 시작과 취소가 느려지고 UI에서 워크플로를 보기 어려워졌다.\n\n워크플로를 조율하는 서비스는 보관 서비스를 동기로 호출한다. 보관 서비스의 데이터베이스가 용량 한계에 닿자 이 호출이 타임아웃되기 시작했고, 그 때문에 워크플로 서비스 전체의 성능이 떨어졌다.\n\n팀은 처음에 논리 복제 슬롯이 원인일 수 있다고 보고 23시 9분에 이 데이터베이스의 블루/그린 배포를 멈춰 슬롯을 비웠다. 그러나 데이터베이스는 회복하지 않았다.\n\n팀은 워크플로 지연을 곧바로 보관 데이터베이스 문제와 연결하지 못했다. 거의 같은 시각에 요청량과 관련된 다른 알림이 따로 울렸기 때문이다. 그 문제가 해결된 뒤에도 대기열이 계속 늘자 다른 팀이 워크플로 쪽을 조사하기 시작했다.\n\n워크플로 대기열은 0시 3분에 정상으로 돌아왔지만, 거의 같은 때부터 Linux 머신 잡이 뒤 단계의 대기열에 쌓이기 시작했다. 클라우드 사업자에 보낸 인스턴스 프로비저닝 요청이 오류를 냈고, 요청이 다시 처리되기 시작한 뒤에도 몰린 요청량 때문에 속도 제한에 걸렸다."},"updated_at":"2026-11-14T12:34:20.253500Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0552","org_slug":"circleci"}