사례4건

4건 중 1~4번째

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

   CircleCI2026

   증상

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

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

   촉발

   10월 6일 12시 40분쯤 데이터베이스의 가장 큰 테이블 몇 개에서 돌던 정기 유지 보수 작업인 anti-wraparound autovacuum 이 평소 작업량과 겹치면서, 데이터베이스가 트랜잭션 로그를 보관 처리하는 속도보다 빠르게 로그를 썼다.

   원인

   용량 한계

   구성 요소

   데이터베이스PostgreSQL vacuumCI 시스템

   기여 요인

   초기 신호 무시한계 경보 부재단일 장애점

   감지

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

   조치

   • anti-wraparound autovacuum 이 빨리 끝나도록 설정을 바꿨다. 이 작업은 취소하면 데이터베이스가 자동으로 다시 시작하기 때문이었다.
   • 트랜잭션 로그 볼륨이 거의 차자 데이터베이스가 읽기 전용이 되지 않도록 로그를 여유 공간이 많은 데이터베이스의 주 저장 볼륨으로 옮겼다. 옮기는 동안 데이터베이스가 50분 동안 내려갔다.
   • 유지 보수 작업이 더 시작되지 않도록 데이터베이스 파라미터 몇 가지를 조사해 바꿨다.
   • 18시 19분에 쓰기마다 저장소를 기다리는 시간을 줄이는 데이터베이스 설정을 바꿔 처리 속도를 되살렸다.
   • 밀린 작업을 빨리 처리하려고 잡을 실행 플릿에 넘기는 시스템에 데이터베이스와 서버 용량을 더했다.

   후속 조치

   • 트랜잭션 로그 볼륨이 얼마나 찼는지와 보관 처리가 얼마나 밀렸는지에 알림을 건다.
   • 이 두 상태를 일으키는 데이터베이스 유지 보수 작업에도 알림을 걸어 더 일찍 대응한다.
   • 시끄럽거나 지나치게 민감한 알림이 실제 문제를 가리지 않도록 모든 알림을 다시 살핀다.
   • 데이터베이스의 autovacuum 이 얼마나 자주, 얼마나 공격적으로 도는지를 조정한다.
   • 큰 테이블들의 크기를 시간에 따라 추적해 안전한 한계 안에 두게 한다.
   • 트랜잭션 로그 하나에 모든 쓰기가 몰리는 병목을 없앤다. 서비스를 각자 트랜잭션 로그를 가진 여러 데이터베이스 인스턴스로 나누는 방법과, 쓰기를 여러 노드에 나누는 분산 데이터베이스로 옮기는 방법을 검토한다.
   • 다른 시스템들이 재시도 끝에 포기하지 않고 조율 서비스가 회복할 때까지 기다리도록 동작을 바꾼다.
   • 긴 장애 동안 상태 페이지 공지가 구체적인 영향과 시각을 더 일찍 담도록 지침을 고친다.

   교훈

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

   사례 보기
2. IL-0356 Railway 에 호스팅된 모든 도메인으로 오는 새 연결이 5분 동안 HTTP 404 를 받았다

   Railway2026

   증상

   2026-09-30 07:35 UTC 무렵부터 Railway 에 호스팅된 모든 도메인이 새 연결에 HTTP 404 not found 를 냈다. 경로 조회가 실패하기 시작하자 곧바로 내부 알림이 울려 당직 대응팀이 소집됐다.

   서비스 중단DNS 조회 실패

   촉발

   07:29 에 병합된 라우팅 제어 플레인 변경을 배포할 때, 파이프라인 설정의 오류로 스키마 변경 파이프라인과 새 라우팅 서비스 배포 파이프라인이 동시에 돌았다. 두 파이프라인이 경쟁하다가 새 라우팅 서비스가 스키마 변경보다 먼저 모든 리전에 올라왔다.

   원인

   배포 결함

   구성 요소

   네트워크 컨트롤 플레인데이터베이스CI 시스템

   기여 요인

   안전하지 않은 실패 동작단계적 배포 부재과도한 영향 범위

   감지

   경로 조회가 실패하기 시작하자 곧바로 내부 알림이 울려 당직 대응팀이 소집됐다.

   조치

   • CI 시스템이 스키마 변경을 적용했고, 라우팅 서비스가 조회를 재시도하면서 도메인 라우팅이 곧바로 정상으로 돌아왔다.

   후속 조치

   • 배포 파이프라인을 하나로 합쳐 마이그레이션 롤아웃이 차례대로 돌게 하고, 병합 전에 배포 순서와 피해 범위를 검사한다.
   • 블루/그린 롤아웃에서 바이너리마다 작성 당시의 스키마 버전을 검증하고, 맞는 데이터베이스 스키마가 갖춰질 때까지 서비스가 운영에 올라가지 않게 한다.
   • 새 구성 요소인 분산 제어 플레인에 리전별 샤드 단위 롤아웃을 더해 앞으로는 피해를 샤드 안에 가둔다.

   사례 보기
3. IL-0244 EKS 서브넷의 라우팅 테이블 연결이 사라져 live 클러스터의 Cloud Platform 서비스에 접근할 수 없었다

   UK Ministry of Justice2024

   증상

   2024년 9월 20일 11:24 에 live 클러스터 서비스를 감시하는 Pingdom 에서 우선순위 높은 알림이 울렸고, 사용자들은 서비스 주소를 찾을 수 없다고 알려 왔다.

   서비스 중단네트워크 도달 불가리소스 삭제

   촉발

   11:21 에 infrastructure-vpc-live-1 파이프라인의 일시 정지를 풀자, 팀이 미처 알아보지 못한 채 대기열에 있던 PR 이 자동으로 실행돼 EKS 서브넷 라우팅 테이블 연결을 지웠다.

   원인

   운영 실수

   구성 요소

   TerraformCI 시스템VPC 라우팅 테이블과 방화벽 규칙

   기여 요인

   파괴적 변경 보호 장치 부재

   감지

   11:24 에 live 클러스터 서비스를 감시하는 Pingdom 이 Cloud Platform 팀에 우선순위 높은 알림을 보냈다. 11:26 부터는 사용자들이 #ask 채널에 서비스를 쓸 수 없다고 알려 왔다.

   조치

   • 11:32 에 Cloud Platform 팀이 로컬에서 terraform apply 를 다시 실행해 서브넷 라우팅 테이블 연결을 다시 만들었고, 서비스를 쓸 수 있게 됐다.

   후속 조치

   • 인프라 파이프라인을 멈추고 다시 켜는 절차를 검토하고 고쳐, 팀원 모두가 파이프라인을 멈추고 다시 켰을 때의 영향을 알게 한다.
   • 인프라를 손으로 고치는 동안 대기열의 PR 실행을 멈출 방법을 찾는다.
   • 인프라 파이프라인의 plan 작업과 apply 작업을 더 잘 격리할 방법을 찾는다.

   사례 보기
4. IL-0467 Prow 빌드 클러스터의 노드 업그레이드 중 Boskos 파드가 크래시 루프에 빠져 GCP 프로젝트가 필요한 테스트 작업이 9시간 넘게 모두 실패했다

   Kubernetes project2019

   증상

   Boskos 에서 GCP 프로젝트를 받아야 하는 Prow 테스트 작업이 밤사이 전부 실패했다. kubernetes/kubernetes 의 모든 PR 에 필수인 pull-kubernetes-e2e-gce 가 계속 실패해서 PR 을 하나도 병합할 수 없었다.

   컨테이너 재시작 반복서비스 중단

   촉발

   Prow 클러스터를 쿠버네티스 1.11 에서 1.13 으로 올리는 노드 업그레이드 중 23:04 에 Boskos 파드 하나가 돌던 노드가 drain 됐다. 새 노드에서 다시 만들어진 Boskos 파드는 StatefulSet 스펙에 적힌 새 이미지로 시작했는데, 이 이미지에 버그가 있었다.

   원인

   배포 결함

   구성 요소

   CI 시스템노드 풀

   기여 요인

   늦게 드러난 변경미검증 가정단일 장애점한계 경보 부재업무 종료 직전에 시작한 변경

   감지

   알림은 울리지 않았다. Boskos 대시보드에는 실패가 뚜렷하게 보였지만 이를 잡는 알림이 없었다. 사용자들이 02:50 에 GitHub 로, 05:16 과 06:27 에 Slack 으로 장애를 알렸고, 담당자는 07:16 에 일어나 Slack 의 보고를 보고서야 알았다.

   조치

   • 버그를 찾은 뒤 고친 Boskos 이미지를 새로 빌드해 배포했고, Boskos 는 곧바로 살아났다.
   • 장애 동안 반납되지 않고 열린 채로 남은 GCP 프로젝트들을 그 뒤 몇 분에 걸쳐 정리했다.

   후속 조치

   • Boskos 설정을 고쳐 배포하면 실제로 파드가 교체되게 한다.
   • Boskos 배포를 자동화한다.
   • Boskos 상태를 지켜보는 알림을 개선한다.

   교훈

   팀은 당직자가 오후 6시까지만 있는 날 오후 5시가 넘어 10시간짜리 배포를 시작하지 말았어야 했다고 보았다. 배포는 실제로 무언가가 바뀌었는지 확인할 수 있게 지켜봐야 하고, 그럴 수 없으면 아예 하지 않아야 한다고 정리했다. Boskos 의 StatefulSet 은 업데이트하도록 설정되어 있지 않아서 배포해도 아무것도 바뀌지 않았다. 12월의 변경은 한 번도 시험되지 않은 것으로 보였다. Prow 의 다른 부분과 달리 Boskos 는 손으로 배포해서 실수할 여지가 컸다. 담당자가 대응을 시작한 뒤로는 문제를 비교적 빨리 풀었다.

   사례 보기

원인별3