사례3건
3건 중 1~3번째
- 증상
blue/green 전환은 22:08 UTC 에 끝났다. 22:17 에 워크플로 서비스의 지연이 커졌고, 10분 재시도를 다 쓴 작업이 버려지며 오류가 났다. 고객은 워크플로와 작업을 시작하거나 취소할 때 지연과 실패를 겪었고 UI 에서 워크플로를 보기 어려웠다.
- 촉발
22:00 UTC 무렵 워크플로를 맡는 서비스의 데이터베이스를 blue/green 배포로 업그레이드했고, 22:08 에 전환이 끝났다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
22:17 UTC 에 워크플로 서비스의 지연이 커지고 10분 재시도를 다 쓴 작업이 버려지며 오류가 나는 것을 확인했다.
- 조치
- 22:30 UTC 에 모든 워크플로 파드가 올바른 데이터베이스에 연결하도록 파드를 재시작했다.
- 22:41 에 새 데이터베이스의 모든 쿼리가 디스크에서 읽히는 것을 보고 곧바로 데이터베이스 크기를 키우고 업무에 꼭 필요하지 않은 데이터베이스 작업을 껐다.
- 23:00 에 통계 테이블을 다시 만드는 동안 데이터베이스가 회복할 여유를 주려고 워크플로 서비스를 파드 하나로 줄였다.
- 23:19 에 옛 데이터베이스의 쓰기를 다시 켜고 옛 데이터베이스를 다시 주 데이터베이스로 되돌리기로 했다. 이 작업은 23:29 에 끝났다.
- 후속 조치
- blue/green 데이터베이스 배포 절차에서 메이저 버전이 바뀔 때마다 analyze 절차를 돌리도록 바꿨다.
- 부하가 걸린 데이터베이스에서 analyze 명령을 돌려도 성능이 더 나빠지지 않는다는 것을 시험으로 확인했다. 앞으로 복구할 때 참고하도록 이 결과를 적어 둔다.
- 다음 마이그레이션 전에 자동 테스트와 수동 확인 지점을 절차 곳곳에 더해 blue/green 전환 전에 문제를 찾아 해결한다.
- 증상
2025년 1월 21일 23시 UTC쯤, 보관 데이터를 담는 데이터베이스 인스턴스의 남은 저장 공간이 거의 없다는 자동 알림이 울렸다. 23시 26분부터 워크플로 대기열이 늘면서 워크플로와 잡의 시작과 취소가 느려지고 UI에서 워크플로를 보기 어려워졌다.
- 촉발
1월 16일에 보관 데이터베이스의 함수 하나를 고친 코드 변경이 의도치 않게 로그 메시지를 지나치게 많이 만들어 냈다.
- 원인
- 구성 요소
- 기여 요인
- 감지
23시쯤 보관 데이터베이스의 남은 저장 공간이 거의 없다는 자동 알림이 울렸다. 같은 시각에 요청량 알림이 따로 울려 팀은 워크플로 지연을 곧바로 이 문제와 연결하지 못했다. 그 알림이 해결된 뒤에도 대기열이 늘자 다른 팀이 조사에 나섰다.
- 조치
- 23시 44분에 워크플로 대기열을 처리하는 이벤트 소비자를 증설했다.
- 23시 55분에 문제가 난 보관 데이터베이스의 읽기 복제본을 독립된 주 인스턴스로 승격했다.
- 후속 조치
- 로그 메시지를 지나치게 많이 만들던 데이터베이스 함수를 고쳤다.
- 워크플로 보관 호출의 재시도 정책에 최대 지속 시간을 두어 기본 타임아웃보다 일찍 실패하게 하고, 보관 서비스에 문제가 생겨도 워크플로 서비스가 받는 영향을 줄인다.
- 장기적으로 워크플로 보관 과정을 이벤트 기반 방식으로 바꿔 두 서비스를 떼어 놓는다.
- 데이터베이스에 예측 모니터링과 이상 탐지 모니터링을 더해, 이상한 움직임이 위험 수준에 닿기 전에 알림을 받는다.
- 교훈
보관 데이터베이스의 문제를 알리는 알림은 울렸지만, 데이터베이스가 예측보다 훨씬 빨리 차서 고객 영향이 나기 전에 대응할 시간이 거의 없었다. 워크플로 서비스가 보관 서비스를 동기로 호출하기 때문에 보관 쪽 문제가 워크플로 전체의 지연으로 번졌다.
- 증상
2021-11-08 18:50 UTC 배포 직후 오류와 알림이 바로 들어왔고, 모든 executor 에서 고객 작업이 "not running" 상태로 막혔다.
- 촉발
18:50 UTC 에 분배 서비스의 PostgreSQL 데이터베이스에서 필드 타입을 바꾸는 배포를 내보냈다. 이 스키마 변경은 하위 호환되지 않았다.
- 원인
- 구성 요소
- 기여 요인
- 감지
18:50 UTC 배포 직후 분배 실패와 관련된 오류와 알림이 바로 보였다.
- 조치
- 오류와 알림을 보고 곧바로 변경을 롤백했다. 롤백 뒤에는 두 배포 사이에 쓰인 데이터를 읽지 못해 분배가 계속 실패했다.
- 분배 시스템이 그 필드를 무시하게 하는 수정을 빠르게 만들고 빌드해 직접 배포했다.
- 몰려들 작업에 대비해 주 컴퓨트 클러스터를 직접 늘렸다. 이 수동 확장은 CircleCI 장애 대응 절차의 표준 단계다.
- 작업 큐가 줄어 정상 처리가 이어지는 것을 잠시 지켜본 뒤 장애를 해결로 처리했다.
- 후속 조치
- 같은 장애가 다시 나지 않도록 테스트 전략의 빈틈을 찾아 고친다.
- 비슷한 배포가 시스템의 모든 작업에 영향을 주지 않도록, 분배 서비스가 예상하지 못한 데이터를 만났을 때의 동작을 바꾼다.
- 예상하지 못한 장애가 났을 때 더 빨리 복구할 수 있게 한다.
이 3건에서 가장 많이 나오는 구성 요소: 데이터베이스, CI 시스템. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.